Hi,
I can't find the InFAMIX C-to-mse tool anymore
(http://www.intooitus.com/products/infamix is answering an access denied
error). I would like to see what is generated for code with pointers to
functions such as:
int
f(int a) {
return a+1;
}
int
g(int a) {
return a+2;
}
int
main() {
int a = 5;
int (*func)(int) = g;
a = (*func)(a);
printf("%d\n", a);
return EXIT_SUCCESS;
}
Best
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Hello
Sice I am still playing with composite shapes, I found another problem, in
addition to incorrect behavior of calling update onto it.
This time I found that composite shapes do not send callbacks in lots of
cases. Example:
| compo ellipse |
compo := ((RTBox new size: 50; color: Color red; yourself) + RTBox new)
element.
compo @ RTDraggable.
ellipse := RTEllipse new size: 20; color: Color blue; element.
TRConstraint stick: ellipse below: compo.
(RTView new) add: compo; add: ellipse; open.
When I drag the composite shape, ellipse does not move, although it should.
Jan
--
View this message in context: http://forum.world.st/Roassal-TRCompositeShape-not-sending-callbacks-tp4814…
Sent from the Moose mailing list archive at Nabble.com.
Hello
We use Roassal on Pharo 4, but we ran across another compatibility issue.
On Pharo 4, MouseWheelEvent class got a little rework. It does not use
symbols #up and #down as direction anymore, not even via accessors.
TRMouseWheelEvent copies this direction, so because RTZoomableView looks for
these symbols, it is no longer working on Pharo 4 (mouse wheel now just
moves camera, but does not change scale).
More info about this Pharo 4 change you might find here:
http://forum.world.st/MouseWheelEvent-direction-in-Pharo-4-tp4806863p480686…
I tried to make few changes to make it compatible in both Pharo 3 and 4.
One option is just adding two methods into TRMouseWheelEvent which convert
Pharo 4 direction to Pharo 3 direction, so only interface change is when
creating TRMouseWheelEvent, usage of this event is absolutely same.
http://www.mediafire.com/download/es70j9dko45da2b/mouseWheel_pharo3like.zip
Second option is to rework TRMouseWheelEvent in the same way MouseWheelEvent
got changed, so they will have same usage on Pharo 4, but it means even
interface of TRMouseWheelEvent changes and everything that asks for its
direction has to be changed, too.
http://www.mediafire.com/download/38lwuwr1eauuur0/mouseWheel_pharo4like.zip
Third option is to use your own solution instead of mine.
And last solution might be just ignoring it and not trying to be compatible
with both Pharo versions.
Jan Blizničenko
--
View this message in context: http://forum.world.st/Roassal2-Pharo-4-MouseWheelEvent-compatibility-tp4806…
Sent from the Moose mailing list archive at Nabble.com.
Hello.
I want to load mse file (238 MB) into Moose image and I want to download even bigger files in the future. But the image crashed during the loading.
I tried to increase the size of image by adding the memory from command line ( --memory 4092; and even --memory 4190208), however the amount of “Space left” didn’t change.
Is there any way to solve this?
Best regards,
Natalia
Hello,
I am currently trying to use Infamix to parse Java, and don't understand
how exactly I'm supposed to include external JARs in the parsing process.
In the moose book page dedicated to the tool it's written to simply place
them in a subfolder (/xxx/project/src/lib) of the target directory
(/xxx/project/src/). This didn't work for me.
Is there an extra command line flag (other than lang/path/mse) that I can
use to fix the problem?
Thanks in advance.
Cheers,
Andrea Caracciolo
_____________________________
Software Composition Group
University of Bern
Hi,
Consider a piece of code:
Class MyClass
{
public String method A()
{
String a;
}
}
In the code above, there is a relationship between the method A and the
return type String. As per my understanding, this relationship is
represented with declaredType in FAMIXBehaviouralEntity.
Currently, this relationship is represented as a simple link (see
FAMIXType>>declaredType) between the two entities but not as a
FAMIXAssociation. Hence, when iterating over all the links/associations
between two entities, we have to specifically take into account this
special case. Currently, MooseChef helps in computing this information but
one should know that there are other links on top of associations:
TDependencyQueries>>queryIncomingDependencies
"Associations + typeDeclaractions"
^ self queryAllIncomingAssociations
addAll: self queryIncomingTypeDeclarations;
yourself
Another and more uniform solution would be to modify declaredType by
creating an additional reference. For example, a trivial solution can be:
declaredType: aType
declaredType := FMMultivalueLink on: self
update: #behavioursWithDeclaredType
from: self declaredType
to: aType.
self mooseModel ifNotNil: [self mooseModel add: (FAMIXReference new source:
self; target: self declaredType) ]
This change will be transparent for the current tools.
Please provide your feedback.
Usman
Hi,
apparently RTLabelled (or rather TRConstraint) doesn't respect bezier line
(not unexpected), and thus probably also all non-straight-line elements
(RTMultiLine, RTSomethingGradientLine, maybe others). I am now working on a
solution for our heavily modified dynamic multiline, so maybe the solution
would be applicable also for the lines in roassal.
Example:
~~~~~~~~~~~~~~~
| v shape edge els |
v := RTView new.
shape := RTEllipse new size: 10; color: (Color purple alpha: 0.3).
els := (shape elementsOn: (1 to: 3)) @ RTDraggable.
v addAll: els .
RTHorizontalLineLayout on: v elements.
v elements first translateBy: -50 @ 50.
v elements last translateBy: 150 @ 100.
edge := (RTBezierLine new controllingElements: v elements) edgeFrom: els
first to: els last.
v add: edge.
edge @ (RTLabelled new text: 'a text').
^ v
~~~~~~~~~~~~~~~~
Peter
