I have a pharo 6.1 image (based on the Moose 6.1 image) containing a small application. I would like to distribute this without the source code.
When I run the application with the changes file present all is fine. When running with the changes file removed, it mostly works ok but apparently the functionality for e.g. creating png (linked to Cairo?) is not available. The log file is attached. Now looking a bit further into this I observed that in fact all the 6.1 images I work with seem to have this same problem, e.g. when displaying Roassal
graphs they display the red windows with crosses. Is this option to run without a changes files supposed to work in 6.1 (on windows)? What should I do to make it work? (noticed that there is no setting
anymore for this) Hans PharoDebug.log (12K) Download Attachment |
Hi Hans,
Did you see (read the class comment) of NoPharoFilesOpener and NoChangesLog ? Sven > On 13 Nov 2018, at 16:19, Baveco, Hans <[hidden email]> wrote: > > I have a pharo 6.1 image (based on the Moose 6.1 image) containing a small application. I would like to distribute this without the source code. When I run the application with the changes file present all is fine. When running with the changes file removed, it mostly works ok but apparently the functionality for e.g. creating png (linked to Cairo?) is not available. The log file is attached. > > Now looking a bit further into this I observed that in fact all the 6.1 images I work with seem to have this same problem, e.g. when displaying Roassal graphs they display the red windows with crosses. > > Is this option to run without a changes files supposed to work in 6.1 (on windows)? What should I do to make it work? (noticed that there is no setting anymore for this) > > Hans > <PharoDebug.log> |
Still, in Pharo6 the absense of changes and sources files means also that FFI calls cannot be done. UFFI uses the method source code to map arguments, and if no source code is available, FFI calls cannot be resolved. This is solved in Pharo7 thanks to Vincent Blondeau by embedding argument names into the method (and thus not requiring source code anymore). If you need it, you can take the FFICompilerPlugin class + (RBMethodNode>>ensureCachedArgumentNames) from Pharo7 and try to backport them on your Pharo6 installation. On Tue, Nov 13, 2018 at 4:29 PM Sven Van Caekenberghe <[hidden email]> wrote: Hi Hans,
|
Ok, thanks for this crucial information! Would backporting be as simple as filing out the class and the single method
from Pharo7 and filing in in Pharo6.1 ? (probably not) I could also move y application to Pharo 7, but sofar I haven’t been able to load Roassal2 in Pharo 7 (32bit). Any information
on how to achieve this (on windows)? No Moose 7.0 image with Roassal preloaded available either, AFAIK... Hans From: Guillermo Polito <[hidden email]>
Still, in Pharo6 the absense of changes and sources files means also that FFI calls cannot be done. UFFI uses the method source code to map arguments, and if no source code is available, FFI calls cannot be resolved. This is solved in Pharo7 thanks to Vincent Blondeau by embedding argument names into the method (and thus not requiring source code anymore). If you need it, you can take the FFICompilerPlugin class + (RBMethodNode>>ensureCachedArgumentNames) from Pharo7 and try to backport them on your Pharo6 installation. On Tue, Nov 13, 2018 at 4:29 PM Sven Van Caekenberghe <[hidden email]> wrote:
--
|
Hi Hans, On Wed, Nov 14, 2018 at 2:56 PM Baveco, Hans <[hidden email]> wrote:
While not completely sure, I think they actually could work. Maybe you found in the way a couple of other methods to backport, but I think that it should not be that difficult. This is the original issue that fixed this in Pharo7: And here the PR with the fix: There are a couple of more changes there, but not so many. |
Hi, You may want to look at https://github.com/VincentBlondeau/Cruiser that contains all the actions needed to perform a clean packaging (Still in dev though). The only issue is that it works for Pharo 7 only and you’ll need to backport changes (I can help you on that). Some changes are related to new VM primitives so you have to use the current stable one (which should also running the Pharo 6.1 images). Don’t hesitate to ask me if you need advices or help on this. I could try to make the tool work on Pharo 6, but it could be incomplete especially on the FFI and stdio part. HTH, Cheers, Vincent From: Pharo-users <[hidden email]> On Behalf Of Guillermo Polito Hi Hans, On Wed, Nov 14, 2018 at 2:56 PM Baveco, Hans <[hidden email]> wrote:
While not completely sure, I think they actually could work. Maybe you found in the way a couple of other methods to backport, but I think that it should not be that difficult. This is the original issue that fixed this in Pharo7: And here the PR with the fix: There are a couple of more changes there, but not so many. attachment0 (501 bytes) Download Attachment |
In reply to this post by Hans Baveco
Have you seen https://ci.inria.fr/moose/job/moose-7.0/ ? Roassal is loaded on it. Vincent From: Pharo-users <[hidden email]> On Behalf Of Baveco, Hans Ok, thanks for this crucial information! Would backporting be as simple as filing out the class and the single method from Pharo7 and filing in in Pharo6.1 ? (probably not) I could also move y application to Pharo 7, but sofar I haven’t been able to load Roassal2 in Pharo 7 (32bit). Any information on how to achieve this (on windows)? No Moose 7.0 image with Roassal preloaded available either, AFAIK... Hans From: Guillermo Polito <[hidden email]> Still, in Pharo6 the absense of changes and sources files means also that FFI calls cannot be done. UFFI uses the method source code to map arguments, and if no source code is available, FFI calls cannot be resolved. This is solved in Pharo7 thanks to Vincent Blondeau by embedding argument names into the method (and thus not requiring source code anymore). If you need it, you can take the FFICompilerPlugin class + (RBMethodNode>>ensureCachedArgumentNames) from Pharo7 and try to backport them on your Pharo6 installation. On Tue, Nov 13, 2018 at 4:29 PM Sven Van Caekenberghe <[hidden email]> wrote:
--
attachment0 (501 bytes) Download Attachment |
Thanks for the link! I could download the moose-7.0 image and changes files. However, to run it a specific version of
the sources files (Pharo7.0-32bit-facd684.sources) seems to be required. Where could that be found? Hans From: [hidden email] <[hidden email]>
Have you seen
https://ci.inria.fr/moose/job/moose-7.0/ ? Roassal is loaded on it. Vincent From: Pharo-users <[hidden email]>
On Behalf Of Baveco, Hans Ok, thanks for this crucial information! Would backporting be as simple as filing out the class and the single method
from Pharo7 and filing in in Pharo6.1 ? (probably not) I could also move y application to Pharo 7, but sofar I haven’t been able to load Roassal2 in Pharo 7 (32bit). Any information
on how to achieve this (on windows)? No Moose 7.0 image with Roassal preloaded available either, AFAIK... Hans From: Guillermo Polito <[hidden email]>
Still, in Pharo6 the absense of changes and sources files means also that FFI calls cannot be done. UFFI uses the method source code to map arguments, and if no source code is available, FFI calls cannot be resolved. This is solved in Pharo7 thanks to Vincent Blondeau by embedding argument names into the method (and thus not requiring source code anymore). If you need it, you can take the FFICompilerPlugin class + (RBMethodNode>>ensureCachedArgumentNames) from Pharo7 and try to backport them on your Pharo6 installation. On Tue, Nov 13, 2018 at 4:29 PM Sven Van Caekenberghe <[hidden email]> wrote:
--
|
In reply to this post by Vincent.Blondeau
Hi Vincent,
Indeed your Cruiser tool proved very useful! It showed me how to implement some absolutely required aspects of packaging,
in pharo 6.1 (i.e. the NoDebugger trick). I tried also to get this independence of FFI of the sources working, by simply filing in the attached code (from P7) into
P6.1. However this didn’t appear to do the job – maybe some additional actions are required (recompiling things?)? Hans From: [hidden email] <[hidden email]>
Hi, You may want to look at
https://github.com/VincentBlondeau/Cruiser that contains all the actions needed to perform a clean packaging (Still in dev though). The only issue is that it works for Pharo 7 only and you’ll need to backport changes (I can help you on that). Some changes are related to new VM primitives so you have to use the current stable one (which should also
running the Pharo 6.1 images). Don’t hesitate to ask me if you need advices or help on this. I could try to make the tool work on Pharo 6, but it could be incomplete especially on the FFI and stdio part. HTH, Cheers, Vincent From: Pharo-users <[hidden email]>
On Behalf Of Guillermo Polito
Hi Hans, On Wed, Nov 14, 2018 at 2:56 PM Baveco, Hans <[hidden email]> wrote:
While not completely sure, I think they actually could work. Maybe you found in the way a couple of other methods to backport, but I think that it should not be that difficult. This is the original issue that fixed this in Pharo7: And here the PR with the fix: There are a couple of more changes there, but not so many. FFICompilerPlugin.st (7K) Download Attachment RBMethodNode-ensureCachedArgumentNames.st (448 bytes) Download Attachment CompilationContext class-addDefaultTransformationPlugin.st (448 bytes) Download Attachment CompilationContext class-defaultTransformationPlugins.st (502 bytes) Download Attachment |
In reply to this post by Hans Baveco
You are welcomed! Here: https://ci.inria.fr/moose/job/moose-7.0/ws/Pharo7.0-32bit-facd684.sources But that is not the way it should be, I changed the Jenkins config to include the missing file. Try to download it again it is in the last build. Vincent From: Baveco, Hans <[hidden email]> Thanks for the link! I could download the moose-7.0 image and changes files. However, to run it a specific version of the sources files (Pharo7.0-32bit-facd684.sources) seems to be required. Where could that be found? Hans From: [hidden email] <[hidden email]> Have you seen https://ci.inria.fr/moose/job/moose-7.0/ ? Roassal is loaded on it. Vincent From: Pharo-users <[hidden email]> On Behalf Of Baveco, Hans Ok, thanks for this crucial information! Would backporting be as simple as filing out the class and the single method from Pharo7 and filing in in Pharo6.1 ? (probably not) I could also move y application to Pharo 7, but sofar I haven’t been able to load Roassal2 in Pharo 7 (32bit). Any information on how to achieve this (on windows)? No Moose 7.0 image with Roassal preloaded available either, AFAIK... Hans From: Guillermo Polito <[hidden email]> Still, in Pharo6 the absense of changes and sources files means also that FFI calls cannot be done. UFFI uses the method source code to map arguments, and if no source code is available, FFI calls cannot be resolved. This is solved in Pharo7 thanks to Vincent Blondeau by embedding argument names into the method (and thus not requiring source code anymore). If you need it, you can take the FFICompilerPlugin class + (RBMethodNode>>ensureCachedArgumentNames) from Pharo7 and try to backport them on your Pharo6 installation. On Tue, Nov 13, 2018 at 4:29 PM Sven Van Caekenberghe <[hidden email]> wrote:
--
attachment0 (501 bytes) Download Attachment |
Free forum by Nabble | Edit this page |