January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Origins [poll]

by Guillermo Polito

Jan. 7, 2011

Re: [Pharo-project] Origins [poll]

by Diogenes Moreira

Jan. 7, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by pharo＠googlecode.com

Comment #18 on issue 3436 by cesar.rabak: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Your comments show consistency with your vision stated above about the need of an overhaul on the design of the interface (a.k.a. "API"), if you take the bulk of it. In order to sustain a civilized dialog, I need to concede you with this doubt. However, it seems to me this is flaring the judgment of proposal here: The method name has *copy* in it, hasn't? I _does_ return a *copy* of the object, doesn't? This issue #3436 is about: is it more adequate that a method called "copyFrom:" copies the state of an object or a part of one when it is a SequenceableCollection? Your other points have to be addressed elsewhere, be it in the mailing list as a preliminary discussion or as proposal here via a well formed issue. In order to avoid any doubts, my stance is that we adopt copyFrom: as an alias (or 'short cut') to "#copyFrom: start to: (self size)" in the most appropriate point of the Pharo object's hierarchy.

Jan. 7, 2011

Re: [Pharo-project] Issue 3516 in pharo: Failing tests in MetaCello

by pharo＠googlecode.com

Updates: Cc: da...(a)teleport.com Comment #1 on issue 3516 by marianopeck: Failing tests in MetaCello http://code.google.com/p/pharo/issues/detail?id=3516 (No comment was entered for this change.)

Jan. 7, 2011

Re: [Pharo-project] Issue 3516 in pharo: Failing tests in MetaCello

by Mariano Martinez Peck

I cc'ed metacello On Fri, Jan 7, 2011 at 3:34 PM, <pharo(a)googlecode.com> wrote: > Status: Accepted > Owner: marcus.denker > Labels: Milestone-1.2-DevImage > > New issue 3516 by marcus.denker: Failing tests in MetaCello > http://code.google.com/p/pharo/issues/detail?id=3516 > > Metacello.TestsReference.MetacelloReferenceTestCase.testReferenceConfig >>>> 0.0020 9 >>>> Metacello.TestsReference.MetacelloReferenceTestCase.testReferenceConfigPrintString >>>> 0.0060 9 >>>> >>> > >

Jan. 7, 2011

Re: [Pharo-project] Issue 3489 in pharo: Pharo 1.2-dev still uses Preferences in BaseSoundSystem

by pharo＠googlecode.com

Comment #11 on issue 3489 by marianopeck: Pharo 1.2-dev still uses Preferences in BaseSoundSystem http://code.google.com/p/pharo/issues/detail?id=3489 We need people helping in this front...otherwise they will never be updated :(

Jan. 7, 2011

Re: [Pharo-project] Alien + Cog VM

by Patricio Plaza

Hi Eliot, Regarding to deprecated Alien class libraries how can I get information about the changes between Pharo 1.1 and Pharo 1.2? Cheers, Patricio El 26-12-2010, a las 15:11, Eliot Miranda escribiÃ³: > > > On Sun, Dec 26, 2010 at 8:19 AM, Joachim Geidel <joachim.geidel(a)onlinehome.de> wrote: > > Hi Eliot, > > On Nov 11, 2010; 02:40am, Eliot Miranda-2 wrote: > > But I'm hoping that the ALien callouts will die the death soon. I have > > Alien callbacks integrated with the FFI and of course the ALien data > > manipulation code works fine. So if you're eager to have Alien callouts > > work see whether the above change fixes things, in which case I can > > integrate the fix. But if you're not so eager you could wait for me to > > push out the FFI changes, but that could take a few weeks. > > What exactly does "Alien callouts will die" mean? Does it mean that the > Alien class library is deprecated and will be replaced by a new version of > FFI? Or is it something else? > > It means what it says; that the callout primitives in Alien will die and all the rest will remain. FFI callouts will accept Aliens and, because they have type information, render the Alien call-outs redundant and problematic. The Alien data representation and callback facilities will be retained. > > > > I am close to releasing JNIPort for Pharo/Squeak. I am currently using Alien > for interfacing to the Java VM, and with the exception of callbacks from the > JVM to Smalltalk which come from foreign threads, everything works now on > the Squeak VM ("foreign" callbacks still crash the VM which outputs > "scheduler could not find a runnable process" to the console). > > I would be a bit unhappy if I had to dump this work and redo the interface > to the JVM, and I wouldn't be happy at all if I had to use different class > libraries for calling foreign functions depending on the VM (Cog vs. Squeak > VM). So, what's the "official" plan for Alien/FFI? > > Best regards, > Joachim Geidel > -- > View this message in context: http://forum.world.st/Alien-Cog-VM-tp3036626p3164309.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 7, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by Nicolas Cellier

All the other messages could have had the copy prepended if it was a question of homogeneitty with existing API. The fact is that they were added later than copy and copyFrom:to: Of course, we can as well remove the copy prefix, but do we really care ? Is it really what makes the message ambiguous ? If I wouldn't know about the message, my question would not be about whether or not the message triggers a copy. It would be whether the argument are elements or indices. I could expect: #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. to work like: #( 'foo' 'bar' 'baz') after: 'foo'. Nicolas 2011/1/7 <pharo(a)googlecode.com>: > > Comment #17 on issue 3436 by step...(a)stack.nl: #copyFrom: is broken > http://code.google.com/p/pharo/issues/detail?id=3436 > > Nicolas wrote: >> >> Because you have two ways to copy a string : >> - a copy of the full string >> - a partial copy from start index to stop index >> does this POV makes it clearer ? > > This does not help, as we also have a.o. > - allButFirst: > - allButLast: > - first: > - last: > -reverse: > - sortBy: > > and compare to: > - after: > - before: > - appendTo: > - sort: > > and then to: > - copyEmpty > > or even to: > - truncateWithElipsisTo: > > How am I supposed to know if I change the original vs get a copy? > > > >

Jan. 7, 2011

Re: [Pharo-project] announcements and weak references

by Lukas Renggli

As far as I remember my announcement implementation uses ActionSequence to represent the actions of an event. You just have to replace these with WeakActionSequence to get the desired behavior. Lukas -- Lukas Renggli (mobile) www.lukas-renggli.ch On 07.01.2011, at 08:10, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Stupid me: > > | x array | > x := OrderedCollection new. > array := WeakArray with: x. > x := nil. > Smalltalk garbageCollect. > array first > > ==> nil. > > Ok, this being the case the original question still remains: Is there any effort to make Announcements only use weak references? I am not much of a specialist in this, but I would be first hand interested in helping out. > > Cheers, > Doru > > > > On 7 Jan 2011, at 08:00, Lukas Renggli wrote: > >> On Friday, 7 January 2011, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>> Hi, >>> >>> Are there any plans to get Announcements use weak references? >>> >>> I saw that in the repository of Lukas, there is a WeakAnnouncer. However, here the subscriptions are still held in a regular Dictionary. >>> >>> Actually, I am not sure what is the status of weak references. I tried the following, but it does not seem to work: >>> >>> | x array | >>> x := GLMPane new. >>> array := WeakArray with: x. >>> x := nil. >>> Smalltalk garbageCollect. >>> array size >>> >>> ==> 1 >> >> Arrays never change their size, it is the value of the fisrt slot that >> changes to 0 or nil (i don't remember). >> >> Lukas >> >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "We cannot reach the flow of things unless we let go." >>> >>> >>> >>> >>> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > >

Jan. 7, 2011

Re: [Pharo-project] Issue 3519 in pharo: EventHandlerPlus

by pharo＠googlecode.com

Comment #1 on issue 3519 by stephane.ducasse: EventHandlerPlus http://code.google.com/p/pharo/issues/detail?id=3519 We should check and remove/integrate....

Jan. 7, 2011