Hi All,
it has been a while for me, so apologies in advance if this is known/stupid/...
I have not worked on at AspectMaps in a looooong time, and now I am assessing (heh) the effort of getting it up to date to the latest version of Moose. (Last working version is for 4.3) It has been going reasonably well, but now I have encountered something in the custom importer that has me stumped. Any pointers on how to resolve this would be most helpful.
FAMIXStructuralEntity>>declaredType: throws a DNU because it ends up sending #structuresWithDeclaredType to the ByteString 'method' when executing FMMultiValueLink class>>on: update: from: to: The only guys that understand that messages are FAMIXType instances. This is weird to me because there is no obvious relation between 'method' and any FAMIXType instances.
Can anybody point me to a solution?
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
The problem seems to be that you are passing a string instead of a FAMIXType to the declaredType:. Is there a reason for that?
Doru
On Tue, Jun 18, 2013 at 9:56 PM, Johan Fabry jfabry@dcc.uchile.cl wrote:
Hi All,
it has been a while for me, so apologies in advance if this is known/stupid/...
I have not worked on at AspectMaps in a looooong time, and now I am assessing (heh) the effort of getting it up to date to the latest version of Moose. (Last working version is for 4.3) It has been going reasonably well, but now I have encountered something in the custom importer that has me stumped. Any pointers on how to resolve this would be most helpful.
FAMIXStructuralEntity>>declaredType: throws a DNU because it ends up sending #structuresWithDeclaredType to the ByteString 'method' when executing FMMultiValueLink class>>on: update: from: to: The only guys that understand that messages are FAMIXType instances. This is weird to me because there is no obvious relation between 'method' and any FAMIXType instances.
Can anybody point me to a solution?
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
The not very helpful reply is "because all the code worked in 4.3". what I need to figure out is whether this bug I have now is caused here or if there is something going wrong upstream. From your reply I guess this is the latter. So I need to know (ideally) what changes to FAMIX between 4.3 and 4.8 could have caused this to happen.
On Jun 20, 2013, at 4:24 PM, Tudor Girba tudor@tudorgirba.com wrote:
The problem seems to be that you are passing a string instead of a FAMIXType to the declaredType:. Is there a reason for that?
Doru
On Tue, Jun 18, 2013 at 9:56 PM, Johan Fabry jfabry@dcc.uchile.cl wrote: Hi All,
it has been a while for me, so apologies in advance if this is known/stupid/...
I have not worked on at AspectMaps in a looooong time, and now I am assessing (heh) the effort of getting it up to date to the latest version of Moose. (Last working version is for 4.3) It has been going reasonably well, but now I have encountered something in the custom importer that has me stumped. Any pointers on how to resolve this would be most helpful.
FAMIXStructuralEntity>>declaredType: throws a DNU because it ends up sending #structuresWithDeclaredType to the ByteString 'method' when executing FMMultiValueLink class>>on: update: from: to: The only guys that understand that messages are FAMIXType instances. This is weird to me because there is no obvious relation between 'method' and any FAMIXType instances.
Can anybody point me to a solution?
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Hi,
4.3 is rather long time ago, and it is likely that indeed the opposite relation was added afterwards. However, declaredType: should have always receive a type, not a string. So, the error comes from the place in your code in which you are storing a string in declaredType.
Cheers, Doru
On Fri, Jun 21, 2013 at 7:55 PM, Johan Fabry jfabry@dcc.uchile.cl wrote:
The not very helpful reply is "because all the code worked in 4.3". what I need to figure out is whether this bug I have now is caused here or if there is something going wrong upstream. From your reply I guess this is the latter. So I need to know (ideally) what changes to FAMIX between 4.3 and 4.8 could have caused this to happen.
On Jun 20, 2013, at 4:24 PM, Tudor Girba tudor@tudorgirba.com wrote:
The problem seems to be that you are passing a string instead of a
FAMIXType to the declaredType:. Is there a reason for that?
Doru
On Tue, Jun 18, 2013 at 9:56 PM, Johan Fabry jfabry@dcc.uchile.cl
wrote:
Hi All,
it has been a while for me, so apologies in advance if this is
known/stupid/...
I have not worked on at AspectMaps in a looooong time, and now I am
assessing (heh) the effort of getting it up to date to the latest version of Moose. (Last working version is for 4.3) It has been going reasonably well, but now I have encountered something in the custom importer that has me stumped. Any pointers on how to resolve this would be most helpful.
FAMIXStructuralEntity>>declaredType: throws a DNU because it ends up
sending #structuresWithDeclaredType to the ByteString 'method' when executing FMMultiValueLink class>>on: update: from: to: The only guys that understand that messages are FAMIXType instances. This is weird to me because there is no obvious relation between 'method' and any FAMIXType instances.
Can anybody point me to a solution?
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
OK, thanks for the info!
It feels like I am now paying the price for a quick hack that we did a looooong time ago to avoid needing to lookup a type based on incomplete/hard to find information … oh well, I guess this was bound to happen at some time ;-)
On Jun 21, 2013, at 2:54 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
4.3 is rather long time ago, and it is likely that indeed the opposite relation was added afterwards. However, declaredType: should have always receive a type, not a string. So, the error comes from the place in your code in which you are storing a string in declaredType.
Cheers, Doru
On Fri, Jun 21, 2013 at 7:55 PM, Johan Fabry jfabry@dcc.uchile.cl wrote:
The not very helpful reply is "because all the code worked in 4.3". what I need to figure out is whether this bug I have now is caused here or if there is something going wrong upstream. From your reply I guess this is the latter. So I need to know (ideally) what changes to FAMIX between 4.3 and 4.8 could have caused this to happen.
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
-
Johan Fabry -
Tudor Girba