April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] af5386: 30809

by Sean P. DeNigris

GitHub wrote > 13143 Integrate Versionner 2.7 > ... > Which include these:... Great job! Thanks, Christophe (and Marcus for integrating so quickly) :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-af5386-30809-tp4752340p47524… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 3, 2014

bug on windows ioShowDisplay for bitdepth 16/8/4 (big endian)

by Nicolai Hess

There is still something wrong with byte/word swap in windows ioShowDisplay code attached are two screenshots squeak 4.5 image with cogvm from http://files.pharo.org/vm/cogmt/win/ pharo 30793 image with latest vm from http://files.pharo.org/vm/pharo/win/ showing this bug after setting the Display depth to 16 (Display newDepth:16) sqwin32window.c has three variants for doing the byte_swap/word_swap on bitdepths with big endian to convert to lsb This one is active and causes this error. # if __GNUC__ >= 3 # define BYTE_SWAP(w) __asm__("bswap %0" : "=r" (w) : "r" (w)) # define WORD_SWAP(w) __asm__("roll $16, %0" : "=r" (w) : "r" (w)) This one would work # else # define BYTE_SWAP(w) __asm__("bswap %%eax" : "=eax" (w) : "eax" (w)) # define WORD_SWAP(w) __asm__("roll $16, %%eax" : "=eax" (w) : "eax" (w)) This one, of course, works too # else # define BYTE_SWAP(w) w = (w << 24) | ((w & 0xFF00) << 8) | ((w >> 8) & 0xFF00) | (w >> 24) # define WORD_SWAP(w) w = (( (unsigned)(w) << 16) | ((unsigned) (w) >> 16)) This one is not there but would work (at least with gcc > 4.5 # define BYTE_SWAP_MY(w) __asm__("bswap %0" : "+r" (w)) # define WORD_SWAP_MY(w) __asm__("roll $16, %0" : "+r" (w)) But actually I don't know assembler and/or the gcc inline code syntax, so I don't know what is wrong with the first version :) Nicolai btw, you can not test this bug with the current squeak 4.5 all in on image, as it uses a rather old vm. Third screenshot: using the latest stable pharo-vm, it looks much more wrong, as there was another(?) bug that is fixed already(?) - i don't know :)

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 Sean P. DeNigris

Igor Stasenko wrote > cool Yes, very! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Re-Nautilus-Package-Tree-tp4738896p4752462.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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 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 2, 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 2, 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 2, 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 2, 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 2, 2014