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

IDE ideas: Theseus

by Goubier Thierry

An exemple of an interactive, augmented IDE. http://alltom.com/pages/theseus/chi-2014/ Opal has the infrastructure to make code traces easier that what I used before... Now, what about adding it to the browser? 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

May 5, 2014

Re: [Pharo-dev] [Vm-dev] bug on windows ioShowDisplay for bitdepth 16/8/4 (big endian)

by Nicolai Hess

2014-04-03 17:51 GMT+02:00 karl ramberg <karlramberg(a)gmail.com>: > > I can confirm this bug on windows Cog. > > Cheers, > Karl > > > On Thu, Apr 3, 2014 at 10:11 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> 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 :) >> >> >> >> > > Someone else can reproduce this? (eliot?, nicolas? ) It is easily fixable, I think. But I am not good at inline assembler. I'll open a mantis and fogbugz report. regards Nicolai

May 5, 2014

Re: [Pharo-dev] Pharo 3 and Sound

by Tyler Sperry

Andreas Wacknitz wrote > Thatâs what I hate about Linux: nothing is stable and everybody reinvents > everything every now and then. And if the many Linux distributions use the > same > modules you can be sure that there is a race for the newest version of it. > My Solaris VM doesnât use ALSA. I tried alsa-lib for OpenSolaris from SFE > repository but itâs not needed and thus I removed the library. I got a chuckle out of your comment. "Yes," I thought, "if only Linux could be stable and refrain from reinventing things like Pharo!" More seriously, your annoyance should be aimed at Canonical who have a dreadful habit of shipping Ubuntu releases like clockwork ... releases that are almost finished. When they added PulseAudio in 2008 it was a integration disaster. Then they tried (unsuccessfully) to push the blame upstream and they were still resolving issues a year and a half later. I think it was the release just before that one where they broke printing for a lot of people. I stopped using Ubuntu when it became clear they weren't satisfied with copying the Mac look but were trying to become an open source version of Apple. The thing is, ALSA wasn't broken when they decided to "improve" it with PulseAudio. ALSA replaced OSS as the default audio driver in the kernel starting with the 2.6 releases. Not to put too fine a point on it, but ALSA has been a stable part of the Linux kernel for over a freaking decade! PulseAudio is a sound server that sits on top of ALSA, and I'm stumped why anyone would be using it unless they have a specific need for network audio. (Well, sure, they could be stuck with it because they're using Ubuntu.) If you have a serious audio application you're probably better off with JACK2 which has better latency than PulseAudio. But for ordinary office/home operations ALSA is proven and it works fine and it comes free with virtually every modern Linux. Unfortunately, Canonical likes to change things and Ubuntu is popular, so people pick it as their target for a generic Linux target. But there are plenty of Linux distributions out there are more stable, perhaps most notable in this context being Debian which uses the same packaging system as Ubuntu but with an effort not to break things in their releases. I'm not familiar with the specifics that Esteban is wrestling with, but I'd wager a beer that his work has been complicated by a Canonical screwup somewhere along the line. Tyler (A happy Arch Linux user) -- View this message in context: http://forum.world.st/Pharo-3-and-Sound-tp4757392p4757897.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 5, 2014

WhatsUp from: 2014-05-05 until: 2014-05-18

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-05-18 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

May 5, 2014

Is there a DICOM image reader in Smalltalk?

by askoh

DICOM or DCM images are widely used in medical imaging. Is there a Smalltalk image reader for that format? Thanks in advance, Aik-Siong Koh -- View this message in context: http://forum.world.st/Is-there-a-DICOM-image-reader-in-Smalltalk-tp4757893.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 5, 2014

Re: [Pharo-dev] Immutability in the VM - is it hard?

by Alexandre Bergel

Ok, thanks. It will be great to have this feature. Alexandre On May 4, 2014, at 4:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alexandre, > > > On Sun, May 4, 2014 at 1:09 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Why is immutability related to the memory management? > > It isn't. > > Are you referring to the change in the header, therefore the garbage collector has to be aware of the extra bit? > > The object representation needs to make room for the bit in the header, but the GC ignores it completely. However, the memory manager (of which the GC is a component) implements the core of e.g. the become primitive and that primitive can reasonably be expected to fail an attempt to become an immutable object. > > > Cheers, > Alexandre > > Le 04-05-2014 Ã 12:05, ClÃ©ment Bera <bera.clement(a)gmail.com> a Ã©crit : > >> Hello, >> >> Immutability needs to be implemented in the VM. It is quite some work on the current memory manager. Few people have enough skills to do this kind of changes nicely and efficiently, and none of them had enough time to do it. However, things are now moving quicker and quicker and some work and immutability has started. >> >> Right now part of the VM work is focusing the new memory manager Spur that will be released for Pharo 4. This new memory manager will feature immutability (1 bit in the object header is now reserved for this purpose). However, although immutability is required by some projects and people, it is quite far away on the To Do list right now (firstly, the new memory manager needs to work efficiently, be stable, be in production, ...). Therefore, you may have to wait for Pharo 5 (2 years from now) to have immutability in production. >> >> Best, >> Clement >> >> >> 2014-05-04 8:40 GMT-07:00 Aaron Rosenzweig <aaron(a)chatnbike.com>: >> Hello, >> >> Why is the concept of âimmutabilityâ special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it? >> >> When I read the docs for the GOODS database client it says the following: >> >> âThe GOODS client uses this immutability support for change detection.â >> >> It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically âfreeâ to detect a change in an object. >> >> Thank you, >> AARON ROSENZWEIG / Chat 'n Bike >> e: aaron(a)chatnbike.com t: (301) 956-2319 >> >> >> > > > > -- > best, > Eliot -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 4, 2014

Re: [Pharo-dev] Immutability in the VM - is it hard?

by Eliot Miranda

Hi Alexandre, On Sun, May 4, 2014 at 1:09 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Why is immutability related to the memory management? > It isn't. > Are you referring to the change in the header, therefore the garbage > collector has to be aware of the extra bit? > The object representation needs to make room for the bit in the header, but the GC ignores it completely. However, the memory manager (of which the GC is a component) implements the core of e.g. the become primitive and that primitive can reasonably be expected to fail an attempt to become an immutable object. > Cheers, > Alexandre > > Le 04-05-2014 Ã 12:05, ClÃ©ment Bera <bera.clement(a)gmail.com> a Ã©crit : > > Hello, > > Immutability needs to be implemented in the VM. It is quite some work on > the current memory manager. Few people have enough skills to do this kind > of changes nicely and efficiently, and none of them had enough time to do > it. However, things are now moving quicker and quicker and some work and > immutability has started. > > Right now part of the VM work is focusing the new memory manager Spur that > will be released for Pharo 4. This new memory manager will feature > immutability (1 bit in the object header is now reserved for this purpose). > However, although immutability is required by some projects and people, it > is quite far away on the To Do list right now (firstly, the new memory > manager needs to work efficiently, be stable, be in production, ...). > Therefore, you may have to wait for Pharo 5 (2 years from now) to have > immutability in production. > > Best, > Clement > > > 2014-05-04 8:40 GMT-07:00 Aaron Rosenzweig <aaron(a)chatnbike.com>: > >> Hello, >> >> Why is the concept of âimmutabilityâ special to VisualWorks? Is it >> something hard to add to other Smalltalk dialects such as Pharo or are >> there other reasons for not having it? >> >> When I read the docs for the GOODS database client it says the following: >> >> âThe GOODS client uses this immutability support for change detection.â >> >> It goes on to say that this is only for VisualWorks. For Pharo it says >> that it is generally slow to commit changes because the client to the OODB >> has to spent extra time detecting change detection. I guess for VisualWorks >> it is basically âfreeâ to detect a change in an object. >> >> Thank you,*Aaron Rosenzweig* / Chat 'n Bike <http://www.chatnbike.com> >> *e:* aaron(a)chatnbike.com *t:* (301) 956-2319 [image: Chat 'n Bike] [image: >> Chat 'n Bike] >> >> > -- best, Eliot

May 4, 2014

Re: [Pharo-dev] Immutability in the VM - is it hard?

by Sebastian Sastre

On May 4, 2014, at 2:17 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Just as a reference. Dolphin Smalltalk supports immutability. It is really handy for marking dirty objects during persistence. > +1 I remember using that feature there once or twice

May 4, 2014

Re: [Pharo-dev] Immutability in the VM - is it hard?

by Alexandre Bergel

Why is immutability related to the memory management? Are you referring to the change in the header, therefore the garbage collector has to be aware of the extra bit? Cheers, Alexandre > Le 04-05-2014 Ã 12:05, ClÃ©ment Bera <bera.clement(a)gmail.com> a Ã©crit : > > Hello, > > Immutability needs to be implemented in the VM. It is quite some work on the current memory manager. Few people have enough skills to do this kind of changes nicely and efficiently, and none of them had enough time to do it. However, things are now moving quicker and quicker and some work and immutability has started. > > Right now part of the VM work is focusing the new memory manager Spur that will be released for Pharo 4. This new memory manager will feature immutability (1 bit in the object header is now reserved for this purpose). However, although immutability is required by some projects and people, it is quite far away on the To Do list right now (firstly, the new memory manager needs to work efficiently, be stable, be in production, ...). Therefore, you may have to wait for Pharo 5 (2 years from now) to have immutability in production. > > Best, > Clement > > > 2014-05-04 8:40 GMT-07:00 Aaron Rosenzweig <aaron(a)chatnbike.com>: >> Hello, >> >> Why is the concept of âimmutabilityâ special to VisualWorks? Is it something hard to add to other Smalltalk dialects such as Pharo or are there other reasons for not having it? >> >> When I read the docs for the GOODS database client it says the following: >> >> âThe GOODS client uses this immutability support for change detection.â >> >> It goes on to say that this is only for VisualWorks. For Pharo it says that it is generally slow to commit changes because the client to the OODB has to spent extra time detecting change detection. I guess for VisualWorks it is basically âfreeâ to detect a change in an object. >> >> Thank you, >> AARON ROSENZWEIG / Chat 'n Bike >> e: aaron(a)chatnbike.com t: (301) 956-2319 >> >> >

May 4, 2014

Re: [Pharo-dev] Usage of should: in tests

by Nicolas Cellier

2014-05-02 10:16 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 01 May 2014, at 12:52 , Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Hi, > > I see many usage of #should: in SciSmalltalk tests that could simply be > turned into #assert: or eventually #assert:equals: > > Why wanting to use a block? > > Other than #should:raise: and #shouldnt:raise:, I don't really see the > point of #should: alone anyway... > > IMO should: should be deprecated, less is more. > > I'm possibly the author of several of these #should: sends, so don't > take it personnally ;) > > > > P.S. or is it easier to restart the block in the Debugger? > > I cross post to pharo-dev because it's a generic question, and there are > a few #should: sends in Pharo-3.0 too. > > Reading code with should:, I always imagined a trailing question mark... > > self should: [IHaveIceCreamForLunch] ? > > And even more so with should:raise: > > self should [thisPieceOfCode] raise: SomeError ? > > I dunno, you tell me! > > The potentially constructive suggestion out of that, is that, at least to > me, > assert:raises: deny:raises: sound more natural than assert:raise: when > read out loud. > > I see, an affirmative form could be: [thisPieceOfCode] shouldRaise: SomeError but we need to insert the testimony of SUnit... assert:raises: is exactly that, and makes sense > Cheers, > Henry >

May 4, 2014