- Pharo-dev - lists.pharo.org

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

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

by Esteban Lorenzano

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) 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 Esteban Lorenzano

> 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] [Ann] ReadWriteLock

by Denis Kudriashov

Thank you Ben for links 2016-01-13 4:31 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > These two read together provide a balanced view. > > ReaderWriterLock vs Monitor > http://www.interact-sw.co.uk/iangblog/2004/04/26/rwlockvsmonitor > > When to use the ReaderWriterLock > https://www.interact-sw.co.uk/iangblog/2004/05/12/rwlock > > cheers -ben > > On Wed, Jan 13, 2016 at 6:27 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > Hi Denis, all, > > > > I'm sorry for asking basic questions, but... > > > > I thought of this a little and I failed to see the advantage > > of using ReadWriteLock over monitor / mutex. What's the goal > > of ReadWriteLock? I mean - when should I use it rather than > > monitor / mutex? What practical advantage would it have? > > > > Best, Jan > > > > > > On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote: > >> Hi. > >> > >> I implemented small package ReadWriteLock http://smalltalkhub.com/mc/ > >> Pharo/ReadWriteLock/main. > >> > >> Gofer it > >> smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > >> configurationOf: 'ReadWriteLock'; > >> loadStable > >> > >> It is reentral read write lock which described in > >> https://en.wikipedia.org/wiki/Readersâwriter_lock. From the article: > >> > >> > An ReadWriteLock allows concurrent access for read-only operations, > >> > while write operations require exclusive access. This means that > >> > multiple threads can read the data in parallel but an exclusive > >> > lock is needed for writing or modifying data. When a writer is > >> > writing the data, all other writers or readers will be blocked > >> > until the writer is finished writing. > >> Public API and Key Messages > >> > >> - lock := ReadWriteLock new > >> - lock criticalRead: aBlock > >> - lock criticalWrite: aBlock > >> > >> Implementation based on two semaphores and readers counter. > >> > >> Main difficulty is carefully handle process termination during > >> execution of critical sections. This problem described in > >> Semaphore>>critical: comment. Same approach is used here. But > >> synchronisation logic around two semaphores for reading and writing > >> complicates things very much. No simple way to decompose logic on > >> multiple methods because information about process interruption > >> become hidden. > >> From the Semaphore comment: > >> > The main trick is assignment right before we go into the wait > >> > primitive (which is not a real send and therefore not interruptable > >> > either). So after we can check that waiting is happen or not. > >> Tests are implemented only for lock scenarios. No tests for described > >> termination process cases. It is not really clear how to write it. > >> I will be appreciate if people review code. Maybe you will suggest > >> simplifications. It is always difficult to implement concurrent > >> code. > >> > >> Best regards, > >> Denis > > > >

Jan. 13, 2016

Re: [Pharo-dev] ifError: implementation is bad

by Guillermo Polito

> On 12 ene 2016, at 8:53 p.m., stepharo <stepharo(a)free.fr> wrote: > > > +1111^1111111 >> >> We should make a list. Some that should be easy: >> >> - Delay should be splitted > why? First, I mean Delay, not processes. Processes are required for executing code, delays are not. I believe that Delay is not a language kernel concern. It is an important concern but not a Kernel one. Also, - the biggest it is the Kernel package, the more difficult it is to analyze dependencies (because everything depends on kernel so who would care, no?) - I could imagine little images that do not contain delay, because they do not use it. Of course, it is not the typical Pharo distribution but it is a possible case. I only say that having it in a separate package is worth it. Check senders of wait, you will see that the usages inside the kernel are really few: mainly BlockClosures implementing things like #valueAndWait and Delay tests. > >> - Chronology should be splitted >> >> One more complicated: >> >> - InstructionClient and InstructionStream should be splitted >> >> And then, we should also review the API of basic objects >> >> Object methods size => 385 >> Integer methods size => 182 >> ... > >

Jan. 13, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Jan Vrany

Denis,Â yes, I read it, but I could not find answers there.Â Ben, thanks! The second article suggests that readers may do blocking operations inside read-critical sections such as IO. If the critical section may block, then I see the advantage. I always thought doing a blocking operation in a critical section is no-no so I haven't considered that case...Thanks!Â Best, Jan On Wed, 2016-01-13 at 11:31 +0800, Ben Coman wrote: > These two read together provide a balanced view. > > ReaderWriterLock vs Monitor > http://www.interact-sw.co.uk/iangblog/2004/04/26/rwlockvsmonitor > > When to use the ReaderWriterLock > https://www.interact-sw.co.uk/iangblog/2004/05/12/rwlock > > cheers -ben > > On Wed, Jan 13, 2016 at 6:27 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > wrote: > > Hi Denis, all, > > > > I'm sorry for asking basic questions, but... > > > > I thought of this a little and I failed to see the advantage > > of using ReadWriteLock over monitor / mutex. What's the goal > > of ReadWriteLock? I mean - when should I use it rather than > > monitor / mutex? What practical advantage would it have? > > > > Best, Jan > > > > > > On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote: > > > Hi. > > > > > > I implemented small package ReadWriteLock http://smalltalkhub.com > > > /mc/ > > > Pharo/ReadWriteLock/main. > > > > > > Gofer it > > > Â Â Â Â Â Â smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > > > Â Â Â Â Â Â configurationOf: 'ReadWriteLock'; > > > Â Â Â Â Â Â loadStable > > > > > > It is reentral read write lock which described in > > > https://en.wikipedia.org/wiki/Readersâwriter_lock. From the artic > > > le: > > > > > > > An ReadWriteLock allows concurrent access for read-only > > > > operations, > > > > while write operations require exclusive access. This means > > > > that > > > > multiple threads can read the data in parallel but an exclusive > > > > lock is needed for writing or modifying data. When a writer is > > > > writing the data, all other writers or readers will be blocked > > > > until the writer is finished writing. > > > Public API and Key Messages > > > > > > - lock := ReadWriteLock new > > > - lock criticalRead: aBlock > > > - lock criticalWrite: aBlock > > > > > > Implementation based on two semaphores and readers counter. > > > > > > Main difficulty is carefully handle process termination during > > > execution of critical sections. This problem described in > > > Semaphore>>critical: comment. Same approach is used here. But > > > synchronisation logic around two semaphores for reading and > > > writing > > > complicates things very much. No simple way to decompose logic on > > > multiple methods because information about process interruption > > > become hidden. > > > From the Semaphore comment: > > > > The main trick is assignment right before we go into the wait > > > > primitive (which is not a real send and therefore not > > > > interruptable > > > > either). So after we can check that waiting is happen or not. > > > Tests are implemented only for lock scenarios. No tests for > > > described > > > termination process cases. It is not really clear how to write > > > it. > > > I will be appreciate if people review code. Maybe you will > > > suggest > > > simplifications. It is always difficult to implement concurrent > > > code. > > > > > > Best regards, > > > Denis > > > >

Jan. 13, 2016