- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] .filetree file?

by Mariano Martinez Peck

Hi Alex, I was wondering the same just minutes ago. I wonder if GitFileTree could do this for us? On Sun, Jul 5, 2015 at 7:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Ok, thanks! > > Alexandre > > > > On Jul 6, 2015, at 12:02 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 05 Jul 2015, at 23:57, Alexandre Bergel <alexandre.bergel(a)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 Denis Kudriashov

Hi. I am going to bed now. Do you look at wikipedia link? 12 ÑÐ½Ð². 2016 Ð³. 11:29 PM Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Jan Vrany" <jan.vrany(a)fit.cvut.cz> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > 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] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Esteban Lorenzano

no, Iâm quite sure they are bugs :) I also believe the other tools do not have accept/cancel visible (they are in contextual menus), so maybe they should be there. Esteban > On 12 Jan 2016, at 23:24, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > Accept and Cancel buttons shouldn't be there > or should not act on if the codepane hasn't changed. > (every press on "accept" writes a new method version, although the contents didn't changed - tested on > Latest update: #50524 ) > > Most (all?) other tools don't have Accept/Cancel buttons. > > - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' > - is "stackTop" now gone ? I thought you wanted to add it to the stack ? > - thisContext is gone as well ? > - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon > is a dropdown menu with label "Bytecode" (since when do we put buttons in the title pane? > - the evaluator pane is shown as "dirty", as it does not make a difference if we > accept the text in this pane, there shouldn't be a dirty indicator. > - you can not use the inspector pane to change inst var values > - there is no way to refresh the inspector pane > > I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but > features. > > > nicolai > >

Jan. 12, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Jan Vrany

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. 12, 2016

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: > the GTDebugger. As this is a significant change that might affect your > workflow, here is some background information to help you deal with the > change. > > First, you should know that the change is not irreversible and it is > easily possible to disabled the new debugger through a setting. However, > please do take the time to provide us feedback if something does not work > out for you. We want to know what can be improved and we try to react as > fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 ) Most (all?) other tools don't have Accept/Cancel buttons. - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' - is "stackTop" now gone ? I thought you wanted to add it to the stack ? - thisContext is gone as well ? - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon is a dropdown menu with label "Bytecode" (since when do we put buttons in the title pane? - the evaluator pane is shown as "dirty", as it does not make a difference if we accept the text in this pane, there shouldn't be a dirty indicator. - you can not use the inspector pane to change inst var values - there is no way to refresh the inspector pane I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but features. nicolai

Jan. 12, 2016