January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to get launcher launching Spur images?

by Blondeau Vincent

I confirm it works under W7 with Spur and not spur images. Thanks ! I think https://github.com/pharo-project/pharo-launcher/issues/1 can be closed now? Vincent > -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Stephan Eggermont > EnvoyÃ© : mercredi 13 janvier 2016 12:35 > Ã : pharo-dev(a)lists.pharo.org > Objet : Re: [Pharo-dev] How to get launcher launching Spur images? > > On 13-01-16 12:25, Blondeau Vincent wrote: > > Under Windows, this cmd is working: > > OSProcess command: $" asString, vmCommand , '" "' , imagePath, '"'. > > Does it work under Mac (with real double quotes and not 2 single quotes)? > > If no, we should do something that is platform dependent.. > > Yes, it works. Please confirm if version 87 works for you > > Stephan > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Jan. 13, 2016

Problem with gitfiletree numeration

by Mariano Martinez Peck

Hi guys, I wanted to know how you manage this situation. I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems: 1) It has an older version number but newer contents 2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? How do you normally solve this? Thanks! -- Mariano http://marianopeck.wordpress.com

Jan. 13, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Dimitris Chloupis

the ideal for me would be that Library to be an Object and returns its path via SomeFFILibrary path or SomeFFILibrary name , if it uses a environment path On Wed, Jan 13, 2016 at 1:57 PM Max Leske <maxleske(a)gmail.com> wrote: > On 13 Jan 2016, at 11:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > So, recapitulation: > > I want to introduce: > > 1) package renaming, from FFI-NB to UnifiedFFI > 2) prefix renaming, from FFI to UFFI (I will not change method prefix, > they will remain ffi* so this is maybe a problemâ¦) > 3) method renaming, from ffiLibraryName to ffiLibrary (we didnât talk > about this, but Iâm introducing it because is better name :P) > > > But isnât the answered object a string? Then I would vote for > #ffiLibraryName. Otherwise Iâd expect a âLibraryâ object. > > > I *think* #2 can be skipped, but #1 and #3 are a must. > > opinions? > > Esteban > > On 13 Jan 2016, at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 13 Jan 2016, at 03:46, Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : > > Hi > > UFFI reminds me UFO which can be translated like Unified Foreign Objects. > And objects outside image look really like unidentified flying objects. > It's just address, blob of bytes and they fly outside smalltalk world > And it has some relation to Alien name. > But maybe it is too much funny name > > > I guess we are considering... > > Prefix: UFO (shorter) > Package: Unified Foreign Objects (longer) > > Prefix: UFFI (longer) > Package: UnifiedFFI (shorter) > > I like your thinking, but I have mixed feelings. Name is cool. The > shorter prefix may be a benefit (though the "I" doesn't add much). > But it implies more semantics as an external "object" than external > blobs of memory (for example) for C libraries. > I like "Unified" because it brings together parts of several > implementations (if I understand correctly) and fixes a point of > divergence at the VM level making it harder for limited resources to > collaborate there. > So in the end I think I prefer Unified. > > > yes, I suppose you are right. > but I was not considering changing prefix from FFI to UFFI, just > repackaging as UnifiedFFI :P > > nowâ¦ probably I will do it (not many changes to adapt and probably better > for understanding in the long way). > > > cheers -ben > > P.S. As I understand it, NativeBoost performs a bit better than > UnifiedFFI, but it hindered cross-architecture compatibility - but > UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if > its technically feasible for NativeBoost to become a plug-in backend > for UnifiedFFI, that could be used is special circumstances that > super-performance is required only on supported platforms? > > > actually (though I do not test it since a couple of months) it should be > more or less compatibleâ¦ it was at the beginning, then I made some changesâ¦ > what is not compatible anymore is the vm who needs to be changed to use > executable memory. > > Alsoâ¦ yes, NativeBoost is faster (callouts, not callbacks) because you > cannot compete with ASM, but you can compite in activation time and > optimised codeâ¦ so who knows, in the future that advantage can not exist > anymore. > > cheers, > Esteban > > > > > > 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > Hi, > > People has pointed (and they are right) that the name of the new FFI > front-end is misleading. > So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for > short) is a better nameâ¦ and to keep packages prox. to regular FFI I was > thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better just > to rename them as UFFI or UnifiedFFIâ¦ > what do you think? > > Esteban > > >

Jan. 13, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Ben Coman

(cross-posted from pharo-dev) On Wed, Jan 13, 2016 at 6:32 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > So, recapitulation: > > I want to introduce: > > 1) package renaming, from FFI-NB to UnifiedFFI > 2) prefix renaming, from FFI to UFFI (I will not change method prefix, they > will remain ffi* so this is maybe a problemâ¦) Actually I suggested this without thinking it through. We should be consider cross-platform compatibility with Squeak at this low level close to image interface to the rest of the world, where its probably harder for average Joe to deal with the differences. I'm not familiar enough with either platform's FFI to comment more. cheers -ben > 3) method renaming, from ffiLibraryName to ffiLibrary (we didnât talk about > this, but Iâm introducing it because is better name :P) > > I *think* #2 can be skipped, but #1 and #3 are a must. > > opinions? > > Esteban > > On 13 Jan 2016, at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 13 Jan 2016, at 03:46, Ben Coman <btc(a)openInWorld.com> wrote: > > Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : > > Hi > > UFFI reminds me UFO which can be translated like Unified Foreign Objects. > And objects outside image look really like unidentified flying objects. It's > just address, blob of bytes and they fly outside smalltalk world > And it has some relation to Alien name. > But maybe it is too much funny name > > > I guess we are considering... > > Prefix: UFO (shorter) > Package: Unified Foreign Objects (longer) > > Prefix: UFFI (longer) > Package: UnifiedFFI (shorter) > > I like your thinking, but I have mixed feelings. Name is cool. The > shorter prefix may be a benefit (though the "I" doesn't add much). > But it implies more semantics as an external "object" than external > blobs of memory (for example) for C libraries. > I like "Unified" because it brings together parts of several > implementations (if I understand correctly) and fixes a point of > divergence at the VM level making it harder for limited resources to > collaborate there. > So in the end I think I prefer Unified. > > > yes, I suppose you are right. > but I was not considering changing prefix from FFI to UFFI, just repackaging > as UnifiedFFI :P > > nowâ¦ probably I will do it (not many changes to adapt and probably better > for understanding in the long way). > > > cheers -ben > > P.S. As I understand it, NativeBoost performs a bit better than > UnifiedFFI, but it hindered cross-architecture compatibility - but > UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if > its technically feasible for NativeBoost to become a plug-in backend > for UnifiedFFI, that could be used is special circumstances that > super-performance is required only on supported platforms? > > > actually (though I do not test it since a couple of months) it should be > more or less compatibleâ¦ it was at the beginning, then I made some changesâ¦ > what is not compatible anymore is the vm who needs to be changed to use > executable memory. > > Alsoâ¦ yes, NativeBoost is faster (callouts, not callbacks) because you > cannot compete with ASM, but you can compite in activation time and > optimised codeâ¦ so who knows, in the future that advantage can not exist > anymore. > > cheers, > Esteban > > > > > > 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > Hi, > > People has pointed (and they are right) that the name of the new FFI > front-end is misleading. > So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for > short) is a better nameâ¦ and to keep packages prox. to regular FFI I was > thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better just > to rename them as UFFI or UnifiedFFIâ¦ > what do you think? > > Esteban > >

Jan. 13, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Max Leske

> On 13 Jan 2016, at 11:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > So, recapitulation: > > I want to introduce: > > 1) package renaming, from FFI-NB to UnifiedFFI > 2) prefix renaming, from FFI to UFFI (I will not change method prefix, they will remain ffi* so this is maybe a problemâ¦) > 3) method renaming, from ffiLibraryName to ffiLibrary (we didnât talk about this, but Iâm introducing it because is better name :P) But isnât the answered object a string? Then I would vote for #ffiLibraryName. Otherwise Iâd expect a âLibraryâ object. > > I *think* #2 can be skipped, but #1 and #3 are a must. > > opinions? > > Esteban > >> On 13 Jan 2016, at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> >>> On 13 Jan 2016, at 03:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@openinworld.com>> wrote: >>> >>>> Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : >>>> >>>> Hi >>>> >>>> UFFI reminds me UFO which can be translated like Unified Foreign Objects. >>>> And objects outside image look really like unidentified flying objects. It's just address, blob of bytes and they fly outside smalltalk world >>>> And it has some relation to Alien name. >>>> But maybe it is too much funny name >>> >>> I guess we are considering... >>> >>> Prefix: UFO (shorter) >>> Package: Unified Foreign Objects (longer) >>> >>> Prefix: UFFI (longer) >>> Package: UnifiedFFI (shorter) >>> >>> I like your thinking, but I have mixed feelings. Name is cool. The >>> shorter prefix may be a benefit (though the "I" doesn't add much). >>> But it implies more semantics as an external "object" than external >>> blobs of memory (for example) for C libraries. >>> I like "Unified" because it brings together parts of several >>> implementations (if I understand correctly) and fixes a point of >>> divergence at the VM level making it harder for limited resources to >>> collaborate there. >>> So in the end I think I prefer Unified. >> >> yes, I suppose you are right. >> but I was not considering changing prefix from FFI to UFFI, just repackaging as UnifiedFFI :P >> >> nowâ¦ probably I will do it (not many changes to adapt and probably better for understanding in the long way). >> >>> >>> cheers -ben >>> >>> P.S. As I understand it, NativeBoost performs a bit better than >>> UnifiedFFI, but it hindered cross-architecture compatibility - but >>> UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if >>> its technically feasible for NativeBoost to become a plug-in backend >>> for UnifiedFFI, that could be used is special circumstances that >>> super-performance is required only on supported platforms? >> >> actually (though I do not test it since a couple of months) it should be more or less compatibleâ¦ it was at the beginning, then I made some changesâ¦ >> what is not compatible anymore is the vm who needs to be changed to use executable memory. >> >> Alsoâ¦ yes, NativeBoost is faster (callouts, not callbacks) because you cannot compete with ASM, but you can compite in activation time and optimised codeâ¦ so who knows, in the future that advantage can not exist anymore. >> >> cheers, >> Esteban >> >>> >>> >>> >>>> >>>> 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>>>> >>>>> Hi, >>>>> >>>>> People has pointed (and they are right) that the name of the new FFI >>>>> front-end is misleading. >>>>> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for >>>>> short) is a better nameâ¦ and to keep packages prox. to regular FFI I was >>>>> thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better just >>>>> to rename them as UFFI or UnifiedFFIâ¦ >>>>> what do you think? >>>>> >>>>> Esteban >

Jan. 13, 2016

Re: [Pharo-dev] How to get launcher launching Spur images?

by Nicolai Hess

2016-01-13 12:25 GMT+01:00 Blondeau Vincent <vincent.blondeau(a)worldline.com> : > > > > -----Message d'origine----- > > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > > Stephan Eggermont > > EnvoyÃ© : mercredi 13 janvier 2016 11:45 > > Ã : pharo-dev(a)lists.pharo.org > > Objet : Re: [Pharo-dev] How to get launcher launching Spur images? > > > > On 12-01-16 21:10, Stephan Eggermont wrote: > > > On 12-01-16 15:23, Ben Coman wrote: > > >> On Tue, Jan 12, 2016 at 10:03 PM, stepharo <stepharo(a)free.fr> wrote: > > >>> I loaded the stable version in Pharo 50 and I saw that it does not > > >>> have the Spur special Folder. > > >>> So I loaded the latest version of the packages from the repo and I > > >>> could not run the launcher anymore. > > >>> > > >>> So could you tell me how you did it? > > >> > > >> Err, umm... looking just now I see only one settable VM path. So it > > >> seems I did not load the latest, only the version from the Catalog. > > >> So I guess I can only run Spur images. > > > > > > That is likely. If you load a newer version you get the second path. I > > > didn't try, but that should allow you to run both also from a spur > > > launcher. In version 84 there is a change in the way the launcher is > > > started, that might be incompatible with OS-X? > > > > Ok, I checked. That launch command was incompatible with OS-X. > > I reverted the change. Please try with the latest version. > > Vincent, on what platform are you running? > > On Windows7 :) But now the command is incompatible with W7 ;) > Yes, see issue https://github.com/pharo-project/pharo-launcher/issues/1 > > It is strange because with an older version of the Pharo launcher, e.g. > PharoLauncher-Core-SeanDeNigris.76 it was this command: > OSProcess command: vmCommand , ' "' , imagePath, '"'. > And nobody had problems on Mac... > Does something changed in OSprocess? > > Under Windows, this cmd is working: > OSProcess command: $" asString, vmCommand , '" "' , imagePath, '"'. > Does it work under Mac (with real double quotes and not 2 single quotes)? > If no, we should do something that is platform dependent.. > > Vincent > > > > Stephan > > > > > > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Jan. 13, 2016

Re: [Pharo-dev] How to get launcher launching Spur images?

by Stephan Eggermont

On 13-01-16 12:25, Blondeau Vincent wrote: > Under Windows, this cmd is working: > OSProcess command: $" asString, vmCommand , '" "' , imagePath, '"'. > Does it work under Mac (with real double quotes and not 2 single quotes)? > If no, we should do something that is platform dependent.. Yes, it works. Please confirm if version 87 works for you Stephan

Jan. 13, 2016

Re: [Pharo-dev] How to get launcher launching Spur images?

by Blondeau Vincent

> -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Stephan Eggermont > EnvoyÃ© : mercredi 13 janvier 2016 11:45 > Ã : pharo-dev(a)lists.pharo.org > Objet : Re: [Pharo-dev] How to get launcher launching Spur images? > > On 12-01-16 21:10, Stephan Eggermont wrote: > > On 12-01-16 15:23, Ben Coman wrote: > >> On Tue, Jan 12, 2016 at 10:03 PM, stepharo <stepharo(a)free.fr> wrote: > >>> I loaded the stable version in Pharo 50 and I saw that it does not > >>> have the Spur special Folder. > >>> So I loaded the latest version of the packages from the repo and I > >>> could not run the launcher anymore. > >>> > >>> So could you tell me how you did it? > >> > >> Err, umm... looking just now I see only one settable VM path. So it > >> seems I did not load the latest, only the version from the Catalog. > >> So I guess I can only run Spur images. > > > > That is likely. If you load a newer version you get the second path. I > > didn't try, but that should allow you to run both also from a spur > > launcher. In version 84 there is a change in the way the launcher is > > started, that might be incompatible with OS-X? > > Ok, I checked. That launch command was incompatible with OS-X. > I reverted the change. Please try with the latest version. > Vincent, on what platform are you running? On Windows7 :) But now the command is incompatible with W7 ;) It is strange because with an older version of the Pharo launcher, e.g. PharoLauncher-Core-SeanDeNigris.76 it was this command: OSProcess command: vmCommand , ' "' , imagePath, '"'. And nobody had problems on Mac... Does something changed in OSprocess? Under Windows, this cmd is working: OSProcess command: $" asString, vmCommand , '" "' , imagePath, '"'. Does it work under Mac (with real double quotes and not 2 single quotes)? If no, we should do something that is platform dependent.. Vincent > > Stephan > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Jan. 13, 2016

Metacello: wrong version if we load twice the same configuration

by Ferlicot D. Cyril

Hi, In some Synectique images we have some problem because we load a project into an image and this project depend on another project (SynMoose) that is already in some of our images in Jenkins. The problem is that a package that we do not want is loaded. SynMoose load the stable version of Magritte3, which depend on MagritteGlamourForPharo40 1.0. The first time we load it, it fetch the version 1.0, which is right. But if we load it a second time (For example when a project depend on it), the version 1.1.0 of MagritteGlamourForPharo40 is loaded. You can see it with this script: Gofer new url: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main'; package:'ConfigurationOfMagritte3'; load. Transcript open. ConfigurationOfMagritte3 load. 3 timesRepeat: [Transcript cr]. ConfigurationOfMagritte3 load. Is it a problem of Metacello? Is it a know problem? Or is it something expected? I think that if we load 2 time the exact same version, the second should do nothing. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 13, 2016

Re: [Pharo-dev] How to get launcher launching Spur images?

by Stephan Eggermont

On 12-01-16 21:10, Stephan Eggermont wrote: > On 12-01-16 15:23, Ben Coman wrote: >> On Tue, Jan 12, 2016 at 10:03 PM, stepharo >> <stepharo(a)free.fr> wrote: >>> I loaded the stable version in Pharo 50 and I saw that it does not >>> have the >>> Spur special Folder. >>> So I loaded the latest version of the packages from the repo and I >>> could not >>> run the launcher anymore. >>> >>> So could you tell me how you did it? >> >> Err, umm... looking just now I see only one settable VM path. So it >> seems I did not load the latest, only the version from the Catalog. >> So I guess I can only run Spur images. > > That is likely. If you load a newer version you get the second path. I > didn't try, but that should allow you to run both also from a spur > launcher. In version 84 there is a change in the way the launcher is > started, that might be incompatible with OS-X? Ok, I checked. That launch command was incompatible with OS-X. I reverted the change. Please try with the latest version. Vincent, on what platform are you running? Stephan

Jan. 13, 2016