- Pharo-dev - lists.pharo.org

Build process of Pharo image

by Hilaire Fernandes

Hello, I have a question regarding the way the Pharo image is technically and socially built. One of the Pharo aim is to be a small and clean environment one can use to develop and build dedicated application. Dedicated tools as Metacello and Gofer are developed for this purpose. Many architecture and dev tools are developed and replacing the old ones: spec, nautillus, etc. Now from the my peripheral point of view, it looks like these tools are carved in the image, breaking the idea of a small and clean core image; making difficult to build dedicated application image. My question: why those tools were not developed to be loadable in a Pharo? Thanks Hilaire -- Dr. Geo http://drgeo.eu

April 5, 2014

Re: [Pharo-dev] [pharo3 issues] down to 17 issues

by Marcus Denker

On 04 Apr 2014, at 18:22, MartinW <wm(a)fastmail.fm> wrote: > When i add a new bug to the issue tracker it is automatically tagged as "fix > if time". Am i supposed to change this label to higher priority if i think > it's appropriate - Yes! > or is someone reviewing new entered bugs and assigning > priorities to them? That too, but there is no automatism. People look at the tracker and check and change/sort, and over time some consensus is found what status an issue should have. (it would be nice to have more people looking at the tracker from time to time to help with this) > Anyway here's the bug: https://pharo.fogbugz.com/f/cases/13175/ > I put it higher so we do not forget to merge it withthe other duplicated reports. Marcus

April 5, 2014

Re: [Pharo-dev] ConfigurationOfMongoTalk load?

by Norbert Hartl

Strange! I downloaded a fresh image and could load it just. Can you tell what the error is saying? It is hard to help without information. Norbert > Am 04.04.2014 um 23:28 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: > > sorry yeah itâs a fresh image, latest version: > 30814 > > I can only load it using bleedingEdge > > > > >> On Apr 4, 2014, at 4:50 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Loads fine in a fresh 3.0 image for me. How did you load it? You should give some version numbers along with the problem! >> >> Norbert >> >>> Am 04.04.2014 um 21:30 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: >>> >>> #load complains about no defined stable* >>> >>> should I load bleeding edge or development? >>> >>> BTW they sound like the same thing, whatâs the difference between those branches? >>> >>> >>> >>> *suggestion: even if itâs beta or alpha I would make a stable just to set a foundation that does not confuses the users > >

April 5, 2014

Re: [Pharo-dev] ConfigurationOfMongoTalk load?

by Sebastian Sastre

On Apr 4, 2014, at 8:21 PM, Ben Coman <btc(a)openInWorld.com> wrote: > I strongly disagree with defining #stable when its not. This completely breaks trust in #stable. Alternatively, it might be good that when #load complains about missing #stable, it suggests the other tags that are defined. > cheers -ben I get your point. Then what would make sense is to fallback to a #beta or #alpha release right? Right now weâre falling back to an exception that would be understood only by the ConfigurationOf priesthood. We need as much gentle starts of high return and good practices as possible guysâ¦ >>> bleeding edge or development? >>> >>> BTW they sound like the same thing, whatâs the difference between those branches?

April 5, 2014

Re: [Pharo-dev] ConfigurationOfMongoTalk load?

by Ben Coman

April 5, 2014

Re: [Pharo-dev] font folder on win7

by Ben Coman

April 5, 2014

Re: [Pharo-dev] ConfigurationOfMongoTalk load?

by Sebastian Sastre

sorry yeah itâs a fresh image, latest version: 30814 I can only load it using bleedingEdge On Apr 4, 2014, at 4:50 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Loads fine in a fresh 3.0 image for me. How did you load it? You should give some version numbers along with the problem! > > Norbert > > Am 04.04.2014 um 21:30 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: > >> #load complains about no defined stable* >> >> should I load bleeding edge or development? >> >> BTW they sound like the same thing, whatâs the difference between those branches? >> >> >> >> *suggestion: even if itâs beta or alpha I would make a stable just to set a foundation that does not confuses the users >> >> > >

April 4, 2014

Re: [Pharo-dev] Lock-free Atomic Counter ?

by Igor Stasenko

On 4 April 2014 22:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Apr 2014, at 19:29, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 4 April 2014 18:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Just for the sake of discussion, you try to prevent interruptions by > using assignments, right ? But you still need #== which seems like a > (potential) message send, which brings us back to the other arguments in > this thread. Furthermore, the dummy value must be different for each of the > processes/threads entering, no ? > > > > dummy is placeholder used solely to detect that counter is 'locked' via > #== comparison.. > > can be any object not really matters if you share it among processes or > not, > > since it carries no state. > > > > #== , whileTrue: .. as well as any other message sends potentially is > subject of being interrupted.. but there's nothing wrong with it, as long > as two assignments (in a row) > > don't have chance to be interrupted. > > All this is quite interesting (and makes my head hurt), maybe we should > implement this as a helper class in the image, along side the other lock > free stuff ? > > i don't know.. do you think it shall be part of some 'atomics' library? >From other side, for same problem there can be many different solutions.. For instance, if you need to uniquely identify an object, what can be simpler than just using that object (identity)? And simplest way to obtain unique object, which nobody can read/write to, is to allocate a new one.. and as long as you don't give a reference to it, it is free from any concurrency caveats.. -- Best regards, Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 807595: 30813

by Sven Van Caekenberghe

On 04 Apr 2014, at 16:37, GitHub <noreply(a)github.com> wrote: > 13114 Broken PharoTheme > https://pharo.fogbugz.com/f/cases/13114 > > 12966 FileLocator does not support adding extension with , > https://pharo.fogbugz.com/f/cases/12966 > > 13151 Fix side bar buttons > https://pharo.fogbugz.com/f/cases/13151 Ah, Pharo looks normal again, sanity restored ;-) Thx !

April 4, 2014

Re: [Pharo-dev] Lock-free Atomic Counter ?

by Sven Van Caekenberghe

On 04 Apr 2014, at 19:29, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 April 2014 18:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Just for the sake of discussion, you try to prevent interruptions by using assignments, right ? But you still need #== which seems like a (potential) message send, which brings us back to the other arguments in this thread. Furthermore, the dummy value must be different for each of the processes/threads entering, no ? > > dummy is placeholder used solely to detect that counter is 'locked' via #== comparison.. > can be any object not really matters if you share it among processes or not, > since it carries no state. > > #== , whileTrue: .. as well as any other message sends potentially is subject of being interrupted.. but there's nothing wrong with it, as long as two assignments (in a row) > don't have chance to be interrupted. All this is quite interesting (and makes my head hurt), maybe we should implement this as a helper class in the image, along side the other lock free stuff ? > On 03 Apr 2014, at 01:34, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > so, lock-free counter can be something like: > > > > atomicIncr > > | oldValue | > > > > [ > > oldValue := self atomicSwapCounterWithDummy. > > oldValue == dummy ] whileTrue: [ Processor yield ]. > > > > ^ counter := oldValue + 1 > > > > > > atomicSwapCounterWithDummy > > | old | > > old := counter. > > counter := dummy. > > ^ old > > > > so you use dummy to block anyone from setting the new value unless you set it. > > dummy can be any object (not a number in your care), > > and lastly, once you assign a new value, you effectively release a "lock" > > :) > > > > Processor yield is mainly attempt to avoid busy-waiting. > > > > > > > > On 3 April 2014 01:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > > > On 3 April 2014 00:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > Is it possible to have a simple lock-free atomic counter in Pharo 3.0 ? > > > > nextId > > ^ idCounter := idCounter + 1 > > > > Or is it still possible that two process entering this code can mess things up ? > > > > #+ is a message send. So technically, if you will be interrupted at the point of > > returning a result from it, then somebody else could run #nextId without notice, > > as result you will get 2 processes returning same value from #nextId. > > (and increasing numbers of concurrent processes will produce even more surprising results :) > > > > I vaguely remember a discussion about that long ago... > > > > assignment is atomic.. the one which i use in atomic queue impl., but it is hidden, undocumented VM implementation detail :) e.g.: > > > > oldA := a. > > a := newA. > > .. > > actually can be any series of it, as long as nothing else there (no message sends) > > > > x:= a. > > y:=b. > > z := c. > > w := e. > > > > will be performed atomically. > > > > > > TIA, > > > > Sven > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko.

April 4, 2014