Hi guys,
I am using the last MooseConfig 1.28 from the bern Store on Visual Works.
I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method:
------------- modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) ))
-------------
Did anybody encounter anything like this? If so, is there a patch for it?
Thanks, Mircea.
Hi Mircea,
Yes, we encountered this before. The problem is due to a bug introduced in the RB traversal of VW 7.6. I will try to dig up the solution (it was in the VW mailing list and in this one just after 7.6 was introduced last year).
Cheers, Doru
On 20 May 2009, at 15:00, Mircea Lungu wrote:
Hi guys,
I am using the last MooseConfig 1.28 from the bern Store on Visual Works.
I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method:
modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) ))
Did anybody encounter anything like this? If so, is there a patch for it?
Thanks, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Hi Mircea,
Ok, I found the problem report (if want to search for it look for RBParser in the subject of mails, either on this on the vwnc mailing list).
I packaged the fix in the PatchForRBParserInVW76 package. It contains one override of the offending method.
Cheers, Doru
On 20 May 2009, at 16:02, Tudor Girba wrote:
Hi Mircea,
Yes, we encountered this before. The problem is due to a bug introduced in the RB traversal of VW 7.6. I will try to dig up the solution (it was in the VW mailing list and in this one just after 7.6 was introduced last year).
Cheers, Doru
On 20 May 2009, at 15:00, Mircea Lungu wrote:
Hi guys,
I am using the last MooseConfig 1.28 from the bern Store on Visual Works.
I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method:
modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) ))
Did anybody encounter anything like this? If so, is there a patch for it?
Thanks, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both matter."
Thanks Doru, you're a wizard :)
m.
On May 20, 2009, at 8:20 PM, Tudor Girba wrote:
Hi Mircea,
Ok, I found the problem report (if want to search for it look for RBParser in the subject of mails, either on this on the vwnc mailing list).
I packaged the fix in the PatchForRBParserInVW76 package. It contains one override of the offending method.
Cheers, Doru
On 20 May 2009, at 16:02, Tudor Girba wrote:
Hi Mircea,
Yes, we encountered this before. The problem is due to a bug introduced in the RB traversal of VW 7.6. I will try to dig up the solution (it was in the VW mailing list and in this one just after 7.6 was introduced last year).
Cheers, Doru
On 20 May 2009, at 15:00, Mircea Lungu wrote:
Hi guys,
I am using the last MooseConfig 1.28 from the bern Store on Visual Works.
I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method:
modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) ))
Did anybody encounter anything like this? If so, is there a patch for it?
Thanks, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both matter."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I saw that the AR for 7.7 to fix this bug was done.
Stef
On May 20, 2009, at 10:34 PM, Mircea Lungu wrote:
Thanks Doru, you're a wizard :)
m.
On May 20, 2009, at 8:20 PM, Tudor Girba wrote:
Hi Mircea,
Ok, I found the problem report (if want to search for it look for RBParser in the subject of mails, either on this on the vwnc mailing list).
I packaged the fix in the PatchForRBParserInVW76 package. It contains one override of the offending method.
Cheers, Doru
On 20 May 2009, at 16:02, Tudor Girba wrote:
Hi Mircea,
Yes, we encountered this before. The problem is due to a bug introduced in the RB traversal of VW 7.6. I will try to dig up the solution (it was in the VW mailing list and in this one just after 7.6 was introduced last year).
Cheers, Doru
On 20 May 2009, at 15:00, Mircea Lungu wrote:
Hi guys,
I am using the last MooseConfig 1.28 from the bern Store on Visual Works.
I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method:
modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) ))
Did anybody encounter anything like this? If so, is there a patch for it?
Thanks, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both matter."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Indeed. But I guess we would have to wait until we get a new release to get the fix.
Cheers, Doru
On 21 May 2009, at 09:47, Stéphane Ducasse wrote:
I saw that the AR for 7.7 to fix this bug was done.
Stef
On May 20, 2009, at 10:34 PM, Mircea Lungu wrote:
Thanks Doru, you're a wizard :)
m.
On May 20, 2009, at 8:20 PM, Tudor Girba wrote:
Hi Mircea,
Ok, I found the problem report (if want to search for it look for RBParser in the subject of mails, either on this on the vwnc mailing list).
I packaged the fix in the PatchForRBParserInVW76 package. It contains one override of the offending method.
Cheers, Doru
On 20 May 2009, at 16:02, Tudor Girba wrote:
Hi Mircea,
Yes, we encountered this before. The problem is due to a bug introduced in the RB traversal of VW 7.6. I will try to dig up the solution (it was in the VW mailing list and in this one just after 7.6 was introduced last year).
Cheers, Doru
On 20 May 2009, at 15:00, Mircea Lungu wrote:
Hi guys,
I am using the last MooseConfig 1.28 from the bern Store on Visual Works.
I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method:
modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) ))
Did anybody encounter anything like this? If so, is there a patch for it?
Thanks, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both matter."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
sure what you did is the right thing to do.
Stef
On May 21, 2009, at 10:08 AM, Tudor Girba wrote:
Indeed. But I guess we would have to wait until we get a new release to get the fix.
Cheers, Doru
On 21 May 2009, at 09:47, Stéphane Ducasse wrote:
I saw that the AR for 7.7 to fix this bug was done.
Stef
On May 20, 2009, at 10:34 PM, Mircea Lungu wrote:
Thanks Doru, you're a wizard :)
m.
On May 20, 2009, at 8:20 PM, Tudor Girba wrote:
Hi Mircea,
Ok, I found the problem report (if want to search for it look for RBParser in the subject of mails, either on this on the vwnc mailing list).
I packaged the fix in the PatchForRBParserInVW76 package. It contains one override of the offending method.
Cheers, Doru
On 20 May 2009, at 16:02, Tudor Girba wrote:
Hi Mircea,
Yes, we encountered this before. The problem is due to a bug introduced in the RB traversal of VW 7.6. I will try to dig up the solution (it was in the VW mailing list and in this one just after 7.6 was introduced last year).
Cheers, Doru
On 20 May 2009, at 15:00, Mircea Lungu wrote:
Hi guys,
I am using the last MooseConfig 1.28 from the bern Store on Visual Works.
I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method:
modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) ))
Did anybody encounter anything like this? If so, is there a patch for it?
Thanks, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They both matter."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Guys (in Bern),
How are you? I hope everything is ok. With Diego (cc in this email) we are trying to download the package Moose-Development from the UniBeStore. Unfortunately our 15000 km far from Bern :) are not an advantage for us (we tried from different connections: univ, private from our home, but we are stuck when we tried to load the package). Two solutions come to my mind: 1) How different is the moose version published in the distribution of VW NC from the version in developement in Bern? If no big differences, we can work with that one
2) Second option: we need a caritative soul :) that loads moose-development in a clean image and upload the image (with moose-development) temporarily in a website where we can download it ...
Anyway, we are open to suggestions to our nice problem ... :)
thanks for any tip or information ...
Cheers,
Gabi
Ciao Gabriela,
Did you try to load Moose Config? I remember that at one point I tried to load MooseDevelopment itself and it seemed to take a very long time.
Alternatively, you can download the latest image of Softwarenaut, you will have also the latest version of Moose Development included (as it they are loaded by Moose Config 1.28). You find it at http://www.inf.unisi.ch/phd/lungu/softwarenaut/download/resources/snaut-3.3....
Cheers, Mircea.
On May 21, 2009, at 4:25 PM, Gabriela Arevalo wrote:
Hi Guys (in Bern),
How are you? I hope everything is ok. With Diego (cc in this email) we are trying to download the package Moose-Development from the UniBeStore. Unfortunately our 15000 km far from Bern :) are not an advantage for us (we tried from different connections: univ, private from our home, but we are stuck when we tried to load the package). Two solutions come to my mind:
- How different is the moose version published in the distribution of
VW NC from the version in developement in Bern? If no big differences, we can work with that one
- Second option: we need a caritative soul :) that loads
moose-development in a clean image and upload the image (with moose-development) temporarily in a website where we can download it ...
Anyway, we are open to suggestions to our nice problem ... :)
thanks for any tip or information ...
Cheers,
Gabi _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Mircea: there's a different problem in Argentina: latency. Does VW really make connections for each file it tries to download? The network over there goes at around 50kb/s but even then I do remember Moose to take about 3 hours to install on an empty image. And then I was told to reinstall it every day ...
No to make it workable they should have their own synced version over there I think; or like you said, through image sharing rather than by using the repo.
On (21/05/09 23:05), Mircea Lungu wrote:
From: Mircea Lungu mircea.lungu@lu.unisi.ch To: "arevalo@iam.unibe.ch" arevalo@iam.unibe.ch, Related to the development of Moose and other related tools moose-dev@iam.unibe.ch Cc: Diego Kogan diegokogan@gmail.com Subject: [Moose-dev] Re: Help to access to Moose-Development Date: Thu, 21 May 2009 23:05:24 +0200
Ciao Gabriela,
Did you try to load Moose Config? I remember that at one point I tried to load MooseDevelopment itself and it seemed to take a very long time.
Alternatively, you can download the latest image of Softwarenaut, you will have also the latest version of Moose Development included (as it they are loaded by Moose Config 1.28). You find it at http://www.inf.unisi.ch/phd/lungu/softwarenaut/download/resources/snaut-3.3....
Cheers, Mircea.
On May 21, 2009, at 4:25 PM, Gabriela Arevalo wrote:
Hi Guys (in Bern),
How are you? I hope everything is ok. With Diego (cc in this email) we are trying to download the package Moose-Development from the UniBeStore. Unfortunately our 15000 km far from Bern :) are not an advantage for us (we tried from different connections: univ, private from our home, but we are stuck when we tried to load the package). Two solutions come to my mind:
- How different is the moose version published in the distribution of
VW NC from the version in developement in Bern? If no big differences, we can work with that one
- Second option: we need a caritative soul :) that loads
moose-development in a clean image and upload the image (with moose-development) temporarily in a website where we can download it ...
Anyway, we are open to suggestions to our nice problem ... :)
thanks for any tip or information ...
Cheers,
Gabi _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
The main problem is not the latency, but is a corrupt DB entry of the CodeFoo bundle. It's a long story :).
Enough to say that if you even try to browse CodeFoo from the Published Items, you will get an infinite loop. So, because I am not knowledgeable enough to patch the DB, the workaround is found in the HackToLoadCodeFooInVW76 package from the SCG Store. This basically patches the read from the DB to not take into account the faulty data.
By mistake this was indeed not a prerequisite of MooseDevelopment, but only in Moose Config, and that is why loading Moose Config worked but loading directly MooseDevelopment took forever :).
Anyway, I fixed it now (added the needed prerequisite to MooseDevelopment). Please try again and let me know if it works.
Cheers, Doru
On 23 May 2009, at 11:20, Toon Verwaest wrote:
Mircea: there's a different problem in Argentina: latency. Does VW really make connections for each file it tries to download? The network over there goes at around 50kb/s but even then I do remember Moose to take about 3 hours to install on an empty image. And then I was told to reinstall it every day ...
No to make it workable they should have their own synced version over there I think; or like you said, through image sharing rather than by using the repo.
On (21/05/09 23:05), Mircea Lungu wrote:
From: Mircea Lungu mircea.lungu@lu.unisi.ch To: "arevalo@iam.unibe.ch" arevalo@iam.unibe.ch, Related to the development of Moose and other related tools moose-dev@iam.unibe.ch Cc: Diego Kogan diegokogan@gmail.com Subject: [Moose-dev] Re: Help to access to Moose-Development Date: Thu, 21 May 2009 23:05:24 +0200
Ciao Gabriela,
Did you try to load Moose Config? I remember that at one point I tried to load MooseDevelopment itself and it seemed to take a very long time.
Alternatively, you can download the latest image of Softwarenaut, you will have also the latest version of Moose Development included (as it they are loaded by Moose Config 1.28). You find it at http://www.inf.unisi.ch/phd/lungu/softwarenaut/download/resources/snaut-3.3....
Cheers, Mircea.
On May 21, 2009, at 4:25 PM, Gabriela Arevalo wrote:
Hi Guys (in Bern),
How are you? I hope everything is ok. With Diego (cc in this email) we are trying to download the package Moose-Development from the UniBeStore. Unfortunately our 15000 km far from Bern :) are not an advantage for us (we tried from different connections: univ, private from our home, but we are stuck when we tried to load the package). Two solutions come to my mind:
- How different is the moose version published in the
distribution of VW NC from the version in developement in Bern? If no big differences, we can work with that one
- Second option: we need a caritative soul :) that loads
moose-development in a clean image and upload the image (with moose-development) temporarily in a website where we can download it ...
Anyway, we are open to suggestions to our nice problem ... :)
thanks for any tip or information ...
Cheers,
Gabi _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Being happy is a matter of choice."
-
Gabriela Arevalo -
Mircea Lungu -
Stéphane Ducasse -
Toon Verwaest -
Tudor Girba