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

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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50525 Home: https://github.com/pharo-project/pharo-core

Jan. 13, 2016

[pharo-project/pharo-core] 9ce126: 50525

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9ce126f8096197e06ecc4f1ee8d137da354db91b https://github.com/pharo-project/pharo-core/commit/9ce126f8096197e06ecc4f1e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-13 (Wed, 13 Jan 2016) Changed paths: M BaselineOfQualityAssistant.package/BaselineOfQualityAssistant.class/instance/api projectSpec/baseline_.st M ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/symbolic versions/stable_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v2%5F2%5F2_.st M ConfigurationOfRenraku.package/ConfigurationOfRenraku.class/instance/symbolic versions/stable_.st A ConfigurationOfRenraku.package/ConfigurationOfRenraku.class/instance/versions/v0%5F9%5F3_.st M Morphic-Widgets-Basic.package/ThreePhaseButtonMorph.class/instance/testing/wantsSteps.st A QualityAssistantRecording.package/QAEventCollector.class/class/class initialization/initialize.st A QualityAssistantRecording.package/QAEventCollector.class/class/events/recordAnnouncement_.st A QualityAssistantRecording.package/QAEventCollector.class/class/initialize-release/unload.st A QualityAssistantRecording.package/QAEventCollector.class/class/instance creation/uniqueInstance.st A QualityAssistantRecording.package/QAEventCollector.class/instance/initialization/initialize.st R QualityAssistantRecording.package/QAEventCollector.class/instance/initialization/linkToReSystemAnnouncer_.st R Renraku.package/ReSystemAnnouncer.class/class/cleanup/cleanUp.st M Renraku.package/ReSystemAnnouncer.class/class/instance creation/uniqueInstance.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50524.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50525.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50524.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50525.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50525 17367 ThreePhaseButtonMorph + subclasses has unnessecary stepping https://pharo.fogbugz.com/f/cases/17367 17377 QualityAssistant v2.2.2 https://pharo.fogbugz.com/f/cases/17377 http://files.pharo.org/image/50/50525.zip

Jan. 13, 2016

Re: [Pharo-dev] .filetree file?

by Thierry Goubier

Le 13/01/2016 01:48, Mariano Martinez Peck a Ã©crit : > Hi Alex, > > I was wondering the same just minutes ago. I wonder if GitFileTree could > do this for us? Well, it looks like a bug. It normally writes and commit it by itself, but it seems that, in certain conditions, it gets written and committed without the expected values with the first package commit, then rewritten (without being committed). I'll have a look. Thierry > > > On Sun, Jul 5, 2015 at 7:03 PM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > Ok, thanks! > > Alexandre > > > > On Jul 6, 2015, at 12:02 AM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > > > > >> On 05 Jul 2015, at 23:57, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > >> > >> Hi! > >> > >> When using Filetree, there is this file .filetree in the git folder. > >> What should I do with it? add it to the repository or ignore it? > > > > You have to add it. It contains meta information. > > > >> cheers, > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 13, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

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] I will rename FFI-NB to UnifiedFFI

by Ben Coman

> 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. 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? > > 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