- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Couchbase client

by Chris Cunningham

I've used this one in Pharo (at least, on Pharo 2.0): http://www.squeaksource.com/SCouchDB.html -cbc On Tue, Mar 18, 2014 at 3:48 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > Is there a Couchbase client for Pharo? > > If it there is one it isn't listed in the clients list > (http://www.couchbase.com/communities/all-client-libraries) > > Regards! > > Esteban A. Maringolo > >

March 19, 2014

Couchbase client

by Esteban A. Maringolo

Is there a Couchbase client for Pharo? If it there is one it isn't listed in the clients list (http://www.couchbase.com/communities/all-client-libraries) Regards! Esteban A. Maringolo

March 18, 2014

Removing tools

by Pavel Krivanek

Hi, this is an initial attempt to produce an image without development tools. Currently it leaves Workspace and Transcript in the image, has no obsolete classes and six Undeclared. The image size is still quite big, 16.1 MB. Tested on #30798. Do not forget to share your improvements ;-) Cheers, -- Pavel

March 18, 2014

Re: [Pharo-dev] WhatsUp from: 2014-03-17 until: 2014-03-31

by Max Leske

On 18.03.2014, at 15:13, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 17/03/2014 22:49, Max Leske a Ã©crit : >> >>> - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION >> >> - annoy Esteban some more with libgit2 >> - get other people to work on LibGit > > This is the project we should look at? > > http://smalltalkhub.com/#!/~StefanMarr/LibGit/commits Yes, thatâs the one. Itâs still pretty unstable so I donât recommend that you look at it yet. That should change in the next couple of days though (as might the location of the repository actuallyâ¦). Iâll keep you posted and will let you know once it makes sense for others to work on it. Max > >> - move the repository to the FileSystem-Git-Dev team >> - get fetch / pull working >> - try to get the LibGit build working with Moose > > 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 >

March 18, 2014

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

by Pharo4Stef

On 18 Mar 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. No this is wrong. > 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. No they should not > So 12419 is not a bug to me, it's a feature. No this is a bug. > > 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

[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