- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] <quote author="Sean P. DeNigris"> I think the tree nodes should be based on name-matching and not only per-package. For example: </quote> In 4.0, let's query the Metacello configurations to find out exactly what packages belong to which project and categorize from there, but until then, I think this is already an improvement:

by Goubier Thierry

Le 03/04/2014 01:03, Igor Stasenko a Ã©crit : > cool > +1 > > but that means we need a resident configs in image, which IMO is a plus. > right now we don't. You can cope with a pre-existing classification for stuff already in the image, and configs for the additional stuff. Works. A touch is the ability to customize and save your classification. It would be very nice to see it working from one of the unloaded images (with configs to reload all the additional stuff). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 3, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Goubier Thierry

Le 02/04/2014 22:51, Pharo4Stef a Ã©crit : > > On 02 Apr 2014, at 13:31, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 02/04/2014 08:12, Tudor Girba a Ã©crit : >>> The language itself is less interesting for me, but what makes it stand >>> out is that it has a coherent and robust philosophy behind and >>> phenomenal goals to reach. In Pharo, we have the luxury of building on >>> top of coherent and robust philosophy (even if different from the >>> Wolfram one) and we should try as much as possible to keep our eyes on >>> phenomenal goals that seem unreachable. >> >> I see two barriers in the current Pharo to be able to reach that: >> >> - Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to "this is the way Nautilus does it", and "no worry about changing it, Nautilus developpers are the same guy" which ends up being very painful for someone outside that core group. > > I agree but who is writing doc beside me and sven? Not me :( > Do you think that this is easy to write doc on something that you did not write. > For Rpackage this is not that complex and you do not want to document the part that glue inside announcement and other. Well, yes and no. Any exposure to RPackage and you understand that you have to know about the glue. Trust me on that one ;) >> - GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that "conservatism" in GUI. > > You cannot clean Morphic without removing experimental stuff. > Once we will have a better morphic then we can be more adventurous. You probably did not spend enough time in morphic if > you do not think that Iâm right. :) Now this is clear that Roassal is a bit reinventing Morphic to some extend but this is like that. Morphic itself is still (how many years since Self we are at now?) experimental. Big chunks of what made Morphic what it is are gone from Pharo. Even Pharo by example requires loading extensions. And in normal, business GUI stuff, Morphic capabilities are underused and get in the way. Now, there is Alain Plantec work. That will be interesting... Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 3, 2014

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

by Igor Stasenko

extra note about yielding: - if i remember correctly, it yields on same priority level, letting other process (if any) at same priority level to take control. and if there's none, then it is NOP. so, if counter incr. used by processes with different priority it is better to replace it with 1 ms sleep. or.... if you don't care, about busy waiting.. you can just don't put anything :) On 3 April 2014 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 3, 2014

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

by Igor Stasenko

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.

April 3, 2014

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

by Eliot Miranda

Hi Sven, On Wed, Apr 2, 2014 at 3:11 PM, 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 ? > OK, but it's a real hack ;-). In the current Interpreter, Stack and Cog VMs this will work fine up to 63-bits because non-failing primitives are not suspension points in the VM /except/ for the Semaphore primitives. If the counter is initialized to 0, at first, there won't even be a send since either the interpreter will evaluate special selector #+ on SmallInteger without performing a send, or machine code will evaluate the inlined code for SmallInteger #+ without doing a send. Once the counter overflows into LargePositveInteger but is within 63-bits, there will be sends but these will always be of primitive 21 (LargePositiveInteger>>#+ uses primitive 21, which does 64-bit /signed/ arithmetic but nothing larger, hence works up to 63-bit LargePositiveIntegers). Once beyond 63 bits the primitive will fail and there will be a suspension point in LargePositiveInteger>>#+ before it calls Integer>>#+, which will call digitAdd:. You should be able to test this. Try evaluating this one: | counter proc | counter := 0. proc := [[counter := counter + 1. true] whileTrue] newProcess. proc priority: Processor activePriority - 1. proc resume. [(Delay forSeconds: 1) wait. proc suspendedContext method ~~ thisContext method ifTrue: [proc suspend. self halt]] repeat Now try and evaluate this one: | counter proc | counter := 1 bitShift: 64. proc := [[counter := counter + 1. true] whileTrue] newProcess. proc priority: Processor activePriority - 1. proc resume. [(Delay forSeconds: 1) wait. proc suspendedContext method ~~ thisContext method ifTrue: [proc suspend. self halt]] repeat The second one halts almost immediately. You can fix this by changing LargePositiveInteger>>#+ to use the primitive frm the large integer arithmetic plugin, which will not fail until it runs out of memory. So if you really /must/ go this route you /can/ get away with it. But on your own head be it ;-) > I vaguely remember a discussion about that long ago... > > TIA, > > Sven > -- best, Eliot

April 3, 2014

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

by Igor Stasenko

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.

April 3, 2014

Re: [Pharo-dev] <quote author="Sean P. DeNigris"> I think the tree nodes should be based on name-matching and not only per-package. For example: </quote> In 4.0, let's query the Metacello configurations to find out exactly what packages belong to which project and categorize from there, but until then, I think this is already an improvement:

by Igor Stasenko

cool +1 but that means we need a resident configs in image, which IMO is a plus. right now we don't. On 2 April 2014 15:56, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Sean, > > I got a simple version of your configuration querying idea working. > > Regards, > > Thierry > > > Le 24/01/2014 03:11, Sean DeNigris a Ã©crit : > >> > I think the tree nodes should be based on name-matching and not only >> >> per-package >> I should've appended: "as a compromise for the time being"... >> >> In 4.0, imagine this killer combination: >> - Declare high-level logical categories a la AltBrowser (e.g. UI). This >> really nails the 7+/-2 sweet spot >> - For external projects, query the Metacello configurations to find out >> exactly what packages belong to which project and group accordingly; >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- Best regards, Igor Stasenko.

April 3, 2014

Re: [Pharo-dev] Bug in ZnUTF8Encoder

by Igor Stasenko

On 2 April 2014 14:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Igor, > > Great catch ! How did you stumble upon this one ? > > Just showing Max (my new room mate) to implement utf-8 encoding using Virtual CPU DSL, and using your code as an example. And ya, my sharp eye with perfect precision immediately detected the problem.... (hope it sounds arrogant enough) ;) Frankly, i don't know. What i think is, that i seen comparison with powers of two numbers in my life so many times, that i trained to automatically see if it correct or not. :) > Anyway, it shows that unless you really test all boundaries explicitly, > silly one-off errors like that manage to survive for quite some time. I > added a unit test doing just that. > > Fixed upstream: > > === > Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.31 > Author: SvenVanCaekenberghe > Time: 2 April 2014, 2:14:36.890651 pm > UUID: 3f6ae285-2973-4451-833b-16afbd0658d3 > Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.30 > > Fixed a one-off error in ZnUTF8Encoder>>#nextPut:toStream (thanks Igor > Stasenko) > === > Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.18 > Author: SvenVanCaekenberghe > Time: 2 April 2014, 2:15:51.938152 pm > UUID: c7048056-52ae-484f-a466-7d537f66690a > Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.17 > > Fixed a one-off error in ZnUTF8Encoder>>#nextPut:toStream (thanks Igor > Stasenko) > > Added ZnCharacterEncoderTests>>#testUTF8Boundaries > === > > Thanks again, > > Sven > > On 02 Apr 2014, at 13:18, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > nextPut: character toStream: stream > > ... > > code < 65535 ifTrue: [ > > ... > > > > should be > > > > code < 65536 ifTrue: [ > > > > because 3-byte encoding can fit 16 bits, which is range > > 0...65535 > > but not > > 0...65534 > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

April 3, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Alexandre Bergel

I have followed the discussion from very far. But thank you guys for considering this important font problem. I will offer some beers at esug, I promise :-) Alexandre On Apr 2, 2014, at 7:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 2 April 2014 14:46, J.F. Rick <self(a)je77.com> wrote: > Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem. > > send me your image , pls. > (and provide doit to reproduce problem, i will try it on my linux box) > > Cheers, > > Jeff > > > -- > Best regards, > Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 3, 2014

Lock-free Atomic Counter ?

by Sven Van Caekenberghe

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 ? I vaguely remember a discussion about that long ago... TIA, Sven

April 3, 2014