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

[ANN] ArchLinux pharo-vm / pharo-launcher packages

by Laurent Laffont

Hi ArchLinux users, you can now install pharo vm on Arch with: $ yaourt pharo-vm-latest then $ pharo /path/to/your/image There's also a pharo-launcher package that depends on pharo-vm: $ yaourt pharo-launcher then $ pharo-launcher or use your favorite desktop main menu and click on the Pharo icon AUR entries: https://aur.archlinux.org/packages/pharo-vm-latest/ https://aur.archlinux.org/packages/pharo-launcher/ PKGBUILDs are versionned on https://github.com/lolgzs/pharo-aur Thanks for testing ! Regards, Laurent

March 18, 2014

Re: [Pharo-dev] pharo sound should be working

by Nicolai Hess

Yes! That works. 2014-03-18 9:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Nicolai, can this be your problem? > > btw... I can give a try to pulse module, but now now, and not for pharo3... > time time time (and you know... it would be an enhancement, not a bug fix... so > is for pharo4 :) ) > > Esteban > > On 18 Mar 2014, at 09:43, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > > Begin forwarded message: > > *From: *xavier MESSNER <xmessner(a)gmail.com> > *Subject: **Re: [Pharo-dev] pharo sound should be working* > *Date: *17 Mar 2014 22:12:30 GMT+1 > *To: *StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Salut StÃ©phane, > > Les modifications apportÃ©es corrigent le problÃ¨me. Le son fonctionne > correctement mais uniquement si le serveur sonore Pulseaudio n'est pas > dÃ©marrÃ©, ce qui n'est pas le cas pour les distributions modernes ou > orientÃ©es desktop. Pour avoir du son j'ai dÃ» dÃ©sactiver pulseaudio. > > Voici comment j'ai procÃ©dÃ©. > > Dans ~/.pulse/client.conf > > autospawn = no > > Cela permet de ne pas relancer le service en automatique > > Ensuite > > killall pulseaudio > > Maintenant je suis dans une configuration "idÃ©ale" et j'ai pu rejouer la > mÃ©lodie de pacman :) > > Seulement, si le serveur de son pulseaudio est lancÃ© j'ai cela qui > apparaÃ®t dans la console > > sound_Start(default) > soundStart: snd_add_pcm_handler: Fonction non implantÃ©e > sound_Start(default) > soundStart: snd_add_pcm_handler: Fonction non implantÃ©e > > Je suis bien parti de la derniÃ¨re version de la vm disponible comme demanÃ©. > A mon avis lorsqu'on utilise pulseaudio, il y a conflit avec la vm qui > elle veut utiliser alsa. > > Xavier. > > > 2014-03-17 20:03 GMT+01:00 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> xavier peux-tu reessayer? >> >> >> Begin forwarded message: >> >> *From: *Esteban Lorenzano <estebanlm(a)gmail.com> >> *Subject: **Re: [Pharo-dev] pharo sound should be working* >> *Date: *17 Mar 2014 15:45:06 GMT+1 >> *To: *Pharo Development List <pharo-dev(a)lists.pharo.org> >> *Reply-To: *Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> can you check with the latest vm now? >> >> btw... you need to install: >> >> sudo apt-get install libasound2-plugins:i386 >> >> in order to prevent warnings. >> >> On 15 Mar 2014, at 00:03, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> 2014-03-14 21:43 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> Hi, >>> >>> so I committed some changes to allow soundplugin to work on the pharovm. >>> can you please download and test in your platforms? >>> >> >> Works on windows >> >> >> >>> >>> (remember, in linux you need libasound2 dependency installed) >>> >> >> it does not work on linux Ubuntu 12.04.2 LTS >> (I have installed libasound2). >> >> Why don't we include the pulse config again and build the vm-sound-pulse >> module as well? >> As I described it in the issue 12493, vm-sound-oss is buildable too. But >> current >> linux distribution don't provide the older OSS sound system. >> (it worked for me with ubuntu 10.04 but not with 12.04) >> >> >>> >>> cheers, >>> Esteban >>> >>> >> >> >> > > >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Eliot Miranda

Hi ClÃ©ment, On Tue, Mar 18, 2014 at 9:02 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Hello, > > For blockClosures it is normal, block closure arguments have always been > assignable since smalltalk-80. We could add a warning to discourage it, but > we cannot forbid it, or we will not be able to load lots of frameworks and > libraries that use it. So 12419<https://pharo.fogbugz.com/default.asp?12419> is > not a bug to me, it's a feature. > > For methods it is a bug, thanks for noticing. I will check. > Well, in VW and Squeak it is disallowed, but there is a flag one can set to allow it. I think it best to disallow. One can always rewrite the code, and indeed create an automatic rewriter, The pattern is quite simple, and was applied to the Smalltalk-80 V2 code base when VisualWorks' predecessor ObjectsWorks 2.3 moved to ObjectWorks 2.4 which had proper closures: someMethod [:blockTemp| ... blockTemp := <expr> ... => someMethod | blockTemp | [:blockTempx| blockTemp := blockTempx. ... blockTemp := <expr> ... One would occasionally see this pattern also: someMethod | blockTemp | [:blockTemp| ... ] blockTemp := <expr> ... => someMethod | blockTemp | [:blockTempx| blockTemp := blockTempx. ... ] blockTemp := <expr> ... So disallowing it and providing a rewriting tool is an option. But I think the flag is best, with its default setting being to ban assignments to block arguments. HTH > > > > 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > > similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> >> block arguments should be read only >> >> >> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: >> >> Indeed, I can compile: >>> >>> C>>foo: arg >>> ^ arg := 3 >>> >>> And 'C new foo: 1' returns 3... >>> >>> >>> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > extent: newExtent >>> > >>> > vertical >>> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >>> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >>> > >>> > super extent: newExtent >>> > >>> > Can you verify it? Arguments should be not assignable. >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> >>> >>> >> > -- best, Eliot

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Eliot Miranda

On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Why arguments should be read only? > They are just temporary variables with an initial value. > Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also. 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> >> block arguments should be read only >> >> >> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: >> >> Indeed, I can compile: >>> >>> C>>foo: arg >>> ^ arg := 3 >>> >>> And 'C new foo: 1' returns 3... >>> >>> >>> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > extent: newExtent >>> > >>> > vertical >>> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >>> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >>> > >>> > super extent: newExtent >>> > >>> > Can you verify it? Arguments should be not assignable. >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> >>> >>> >> > > -- best, Eliot

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Nicolas Cellier

2014-03-18 18:47 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > 2014-03-18 18:31 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > >> On 18.03.2014, at 18:17, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> >> On 18 mars 2014, at 17:02, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Hello, >> >> For blockClosures it is normal, block closure arguments have always been >> assignable since smalltalk-80. >> >> >> I never noticed, that's a weird 'feature'. >> >> We could add a warning to discourage it, but we cannot forbid it, or we >> will not be able to load lots of frameworks and libraries that use it. So >> 12419 <https://pharo.fogbugz.com/default.asp?12419> is not a bug to me, >> it's a feature. >> >> >> You mean that there exist code out there that rely on being able to store >> in an argument? >> >> > Yes there are code like that, we encountered them in Opal's regression > tests (I don't remember exactly but they are in Pharo, Moose or/and > seaside). > > Squeak did allow that once upon a time, everything you allow is used (accidentally or not). It's rare but may prevent loading old packages... I'm pretty sure that some VMMaker modules did have the problem in the past... > As Christophe said, arguments are temporary variables with an initial > value for block closures (and right now for methods too, but it's a > officially bug). Perhaps it is not a bug to allow that for methods. It's > another feature. > > It's bad for debugging because we cannot simply restart the progam counter at beginning of the method then... So there's more to loose than win with such feature IMO. The expected behavior is the same as block closures: > > MyClass>>foo > | t | > (self example: t) logCr. > ^ t > > MyClass>>example: arg > arg := 1. > ^ arg > > When evaluating MyClass new foo, 1 is logged on the transcript but the > return value is nil, because an argument is a temporary variable with an > initial value. > > On the bug tracker we noted to add a setting for these cases. That's the > solution anyway... > A richer interface is to raise (signal) an exception, and parameterize the defaultAction with such setting, or catch the exception in some tool - allways fail - allways succeed - ask user interactively whether to turn success on while loading this package or abort - ask user interactively method by method (not very user friendly ! expert mode only) - automatically fix the method (rename arg and copy it to a temp in preamble) - etc... >> Always assume the worst case scenario :p >> >> >> >> For methods it is a bug, thanks for noticing. I will check. >> >> >> >> >> 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> >>> block arguments should be read only >>> >>> >>> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: >>> >>> Indeed, I can compile: >>>> >>>> C>>foo: arg >>>> ^ arg := 3 >>>> >>>> And 'C new foo: 1' returns 3... >>>> >>>> >>>> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> > extent: newExtent >>>> > >>>> > vertical >>>> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >>>> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >>>> > >>>> > super extent: newExtent >>>> > >>>> > Can you verify it? Arguments should be not assignable. >>>> > >>>> > -- >>>> > Best regards, >>>> > Igor Stasenko. >>>> >>>> >>>> >>> >> >> >> >

March 18, 2014

Re: [Pharo-dev] RPackageOrganizer >> unregisterPackageNamed:

by Esteban Lorenzano

package management and classes are orthogonal: you can have a class in the system outside the package structure. so yes.. removing a class from system will certainly remove them from package structureâ¦ but not the opposite: unregistering a package is just that: unregistering a package (the classes will remain). rpackage api needs to be revisited (yet once again) un pharo4â¦ but for now, is like that :) Esteban On 18 Mar 2014, at 18:34, Ben Coman <btc(a)openinworld.com> wrote: > RPackageOrganizer has protocol 'public registration' with methods: #registerPackageNamed: and #unregisterPackageNamed: > > So I presume I am free to evaluate the following as separate steps)... > > 1. RPackageOrganizer default registerPackageNamed: 'MyTest'. > "-->package is created okay" > > 2. Object subclass: #MyTestClass > instanceVariableNames: '' > classVariableNames: '' > category: 'MyTest'. > "-->class is created okay" > > 3. RPackageOrganizer default unregisterPackageNamed: 'MyTest'. > "-->package disappears okay" > > 4. RPackageOrganizer default registerPackageNamed: 'MyTest'. > "-->package created okay" > > 5. Object subclass: #MyTestClass > instanceVariableNames: '' > classVariableNames: '' > category: 'MyTest'. > "-->class does not appear" > > However if I go... > 6a. Smalltalk removeKey: #MyTestClass . > > 6b. Object subclass: #MyTestClass > instanceVariableNames: '' > classVariableNames: '' > category: 'MyTest'. > > "-->then the class does appear" > > Should I need to be cleaning up manually per step 6a? > > cheers -ben >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by ClÃ©ment Bera

2014-03-18 18:31 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > On 18.03.2014, at 18:17, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 18 mars 2014, at 17:02, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > For blockClosures it is normal, block closure arguments have always been > assignable since smalltalk-80. > > > I never noticed, that's a weird 'feature'. > > We could add a warning to discourage it, but we cannot forbid it, or we > will not be able to load lots of frameworks and libraries that use it. So > 12419 <https://pharo.fogbugz.com/default.asp?12419> is not a bug to me, > it's a feature. > > > You mean that there exist code out there that rely on being able to store > in an argument? > > Yes there are code like that, we encountered them in Opal's regression tests (I don't remember exactly but they are in Pharo, Moose or/and seaside). As Christophe said, arguments are temporary variables with an initial value for block closures (and right now for methods too, but it's a officially bug). Perhaps it is not a bug to allow that for methods. It's another feature. The expected behavior is the same as block closures: MyClass>>foo | t | (self example: t) logCr. ^ t MyClass>>example: arg arg := 1. ^ arg When evaluating MyClass new foo, 1 is logged on the transcript but the return value is nil, because an argument is a temporary variable with an initial value. On the bug tracker we noted to add a setting for these cases. That's the solution anyway... > Always assume the worst case scenario :p > > > > For methods it is a bug, thanks for noticing. I will check. > > > > > 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> >> block arguments should be read only >> >> >> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: >> >> Indeed, I can compile: >>> >>> C>>foo: arg >>> ^ arg := 3 >>> >>> And 'C new foo: 1' returns 3... >>> >>> >>> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > extent: newExtent >>> > >>> > vertical >>> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >>> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >>> > >>> > super extent: newExtent >>> > >>> > Can you verify it? Arguments should be not assignable. >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> >>> >>> >> > > >

March 18, 2014

RPackageOrganizer >> unregisterPackageNamed:

by Ben Coman

RPackageOrganizer has protocol 'public registration' with methods: #registerPackageNamed: and #unregisterPackageNamed: So I presume I am free to evaluate the following as separate steps)... 1. RPackageOrganizer default registerPackageNamed: 'MyTest'. "-->package is created okay" 2. Object subclass: #MyTestClass instanceVariableNames: '' classVariableNames: '' category: 'MyTest'. "-->class is created okay" 3. RPackageOrganizer default unregisterPackageNamed: 'MyTest'. "-->package disappears okay" 4. RPackageOrganizer default registerPackageNamed: 'MyTest'. "-->package created okay" 5. Object subclass: #MyTestClass instanceVariableNames: '' classVariableNames: '' category: 'MyTest'. "-->class does not appear" However if I go... 6a. Smalltalk removeKey: #MyTestClass . 6b. Object subclass: #MyTestClass instanceVariableNames: '' classVariableNames: '' category: 'MyTest'. "-->then the class does appear" Should I need to be cleaning up manually per step 6a? cheers -ben

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Max Leske

On 18.03.2014, at 18:17, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 18 mars 2014, at 17:02, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, >> >> For blockClosures it is normal, block closure arguments have always been assignable since smalltalk-80. > > I never noticed, that's a weird 'feature'. > >> We could add a warning to discourage it, but we cannot forbid it, or we will not be able to load lots of frameworks and libraries that use it. So 12419 is not a bug to me, it's a feature. > > You mean that there exist code out there that rely on being able to store in an argument? Always assume the worst case scenario :p > >> >> For methods it is a bug, thanks for noticing. I will check. >> >> >> >> >> 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> similiar to issue 12419 block arguments should be read only >> >> >> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: >> >> Indeed, I can compile: >> >> C>>foo: arg >> ^ arg := 3 >> >> And 'C new foo: 1' returns 3... >> >> >> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > extent: newExtent >> > >> > vertical >> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >> > >> > super extent: newExtent >> > >> > Can you verify it? Arguments should be not assignable. >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> >> >> >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Camille Teruel

On 18 mars 2014, at 17:02, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > For blockClosures it is normal, block closure arguments have always been assignable since smalltalk-80. I never noticed, that's a weird 'feature'. > We could add a warning to discourage it, but we cannot forbid it, or we will not be able to load lots of frameworks and libraries that use it. So 12419 is not a bug to me, it's a feature. You mean that there exist code out there that rely on being able to store in an argument? > > For methods it is a bug, thanks for noticing. I will check. > > > > > 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > similiar to issue 12419 block arguments should be read only > > > 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: > > Indeed, I can compile: > > C>>foo: arg > ^ arg := 3 > > And 'C new foo: 1' returns 3... > > > On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > extent: newExtent > > > > vertical > > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] > > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. > > > > super extent: newExtent > > > > Can you verify it? Arguments should be not assignable. > > > > -- > > Best regards, > > Igor Stasenko. > > > >

March 18, 2014