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

[Pharo-project] Origins [poll] Summary

by Miguel CobÃ¡

Jan. 8, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by Guillermo Polito

As long as we don't remove HTTPSocket from scratch until two versions from now I see no problem :). On Fri, Jan 7, 2011 at 6:54 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Jan 7, 2011, at 20:10 , Sven Van Caekenberghe wrote: > > > > > On 07 Jan 2011, at 13:58, StÃ©phane Ducasse wrote: > > > >> I was just reading the code with olivier auverlot. > >> I would love to have a small if possible replacement to the HTTPSocket. > > > > There really is a lot of cleanup to do. > > > > The key/core replacement of HTTP client functionality is done, but > HTTPSocket does so much stuff in such bizar ways that it will require a > concerted effort of many people to clean it up. > > I guess that a lot of stuff isn't needed anymore and hence doesn't need to > be reimplemented (?). We could deprecate such methods (or just delete them) > and if later we figure some are really needed we can put them back again. > I've quickly browser the references to HTTPSocket in PharoCore and there are > not too many complicated ones, as far as I can tell. > > Adrian >

Jan. 8, 2011

Re: [Pharo-project] [Moose-dev] Re: What feature you want to see in Mondrian

by Alexandre Bergel

Ok... I will see what can be done Alexandre On 7 Jan 2011, at 20:23, Tudor Girba wrote: > Here are my wishes in order of preferences: > > http://code.google.com/p/moose-technology/issues/detail?id=437 > http://code.google.com/p/moose-technology/issues/detail?id=398 > http://code.google.com/p/moose-technology/issues/detail?id=450 > http://code.google.com/p/moose-technology/issues/detail?id=113 > > :) > > Cheers, > Doru > > > On 7 Jan 2011, at 21:26, Alexandre Bergel wrote: > >> Hi! >> >> I am willing to spend some time on Mondrian the coming weeks. I would like to know what are the feature/issue what are the most pressing for you? >> >> http://code.google.com/p/moose-technology/issues/list?can=2&q=Mondrian&cols… >> >> Lazy edges? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 8, 2011

Re: [Pharo-project] [Vm-dev] Problem restarting contexts in Cog 2341

by Eliot Miranda

Hi All, find new VMs in VM.r2342/<http://www.mirandabanda.org/files/Cog/VM/VM.r2342/> (SimpleStackBasedCogit) and VM.r2343/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> ( StackToRegisterMappingCogit). 2343 seems fine but I appear to have introduced a regression into 2342. The 2343 VMs fix both of the bugs mentioned by Matthew and Yoshiki: This now evaluates to nil as intended: | a | a := false. [a ifFalse: [Error signal]] on: Error do: [:ex | a := true. ex retry] This no longer provokes a must-be-boolean error: BooleanArrayUser new loop1 As usual I'm very grateful for you pounding on these (ok, at least the 2343 VM :) ). best Eliot On Fri, Jan 7, 2011 at 10:10 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Matthew, Hi Yoshiki, > > > thanks very much for this. I have a fix which I should be able to roll > out this evening or tomorrow. The problem was that the run-time code that > assigns inst vars of contexts was not preserving the register holding the > receiver although the code generator thought it was. So in > MethodContext>>#privRefresh a subsequent reference to a context inst var > failed because the register assumed to be holding the context got trashed. > There was another bug which caused the code generator's "simulation stack" > (its main optimization data structure) to be off by one for context inst var > assigns. Hopefully these two fixes will fix Yoshiki's bug also. Yoskhiki, > do you have a more reliable way of reproducing that bug? > > best > Eliot > > On Thu, Jan 6, 2011 at 6:40 PM, Matthew Fulmer <tapplek(a)gmail.com> wrote: > >> >> On Thu, Jan 06, 2011 at 09:27:14PM -0500, Matthew Fulmer wrote: >> > >> > In Cog release 2341, as distributed at >> > http://www.mirandabanda.org/files/Cog/VM/VM.r2341/ >> > >> > this causes an MNU. It should evaluate to true: >> > >> > | a | a := false. [a ifFalse: [Error signal]] on: Error do: [:ex | a := >> true. ex retry] >> >> actually it should evaluate to nil >> >> -- >> Matthew Fulmer (a.k.a. Tapple) >> > >

Jan. 8, 2011

[Pharo-project] Issue 3520 in pharo: Workspaces do not recognize previously evaluated temps

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3520 by sean.p.denigris: Workspaces do not recognize previously evaluated temps http://code.google.com/p/pharo/issues/detail?id=3520 Pharo image: Pharo-core Pharo core version: Pharo1.2beta Latest update: #12294 Virtual machine used: Mac 4.2.5 Steps to reproduce: 1. Type "window := SystemWindow new openInWorld." in a workspace. 2. DoIt that line 3. An "Unknown variable" dialog pops up This is a workflow-killer.

Jan. 8, 2011

[Pharo-project] aligning morphs

by Tudor Girba

Hi, I would need help with understanding the magic behind alignment in Morphic. Take the example from below. Could anyone help me with what I should do to have the morph stretch all the way horizontally? | scroll window morph | scroll := ScrollPane new. scroll fillStyle: (SolidFillStyle color: Color blue); vResizing: #spaceFill; hResizing: #spaceFill. morph := PanelMorph new. morph fillStyle: (SolidFillStyle color: Color yellow); changeTableLayout; listDirection: #topToBottom; vResizing: #shrinkWrap; hResizing: #spaceFill; layoutInset: 10. morph addMorphBack: (SimpleButtonMorph new width: 200; height: 200). scroll scroller addMorph: morph. window := SystemWindow new. window addMorph: scroll fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)). window openInWorld Cheers, Doru -- www.tudorgirba.com "Every thing should have the right to be different."

Jan. 8, 2011

Re: [Pharo-project] announcements and weak references

by Tudor Girba

Thanks. I will take a look. Cheers, Doru On 7 Jan 2011, at 18:08, Lukas Renggli wrote: > 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." >> >> >> >> > -- www.tudorgirba.com "Don't give to get. Just give."

Jan. 7, 2011

Re: [Pharo-project] [Moose-dev] What feature you want to see in Mondrian

by Tudor Girba

Here are my wishes in order of preferences: http://code.google.com/p/moose-technology/issues/detail?id=437 http://code.google.com/p/moose-technology/issues/detail?id=398 http://code.google.com/p/moose-technology/issues/detail?id=450 http://code.google.com/p/moose-technology/issues/detail?id=113 :) Cheers, Doru On 7 Jan 2011, at 21:26, Alexandre Bergel wrote: > Hi! > > I am willing to spend some time on Mondrian the coming weeks. I would like to know what are the feature/issue what are the most pressing for you? > > http://code.google.com/p/moose-technology/issues/list?can=2&q=Mondrian&cols… > > Lazy edges? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

Jan. 7, 2011

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

by csrabak＠bol.com.br

Em 07/01/2011 18:17, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: 2011/1/7 : [snipped] > > I would like to elaborate on your half million question Â« Is it > > really what makes the message ambiguous ? Â» > > If you attempt your example in plain Pharo image > > > > #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. > > You get a MNU > > ByteString(Object)>>doesNotUnderstand: #- > > Array(SequenceableCollection)>>copyFrom:to: . . . > > So what would be your point: > > 1) copyFrom:to: is not 'polymorphic enough' for Pharo Smalltalk > > ideal of a dynamic language? > > 2) the message name is to be changed to copyFromIndex: start > > toIndex: end? > > 3) some other concoction I missed? > Here is what I mean: I agree that #copyFrom: is ambiguous and could > be renamed, with all deprecation precautions. I will take this as meaning "I agree that Object>>copyFrom: is ambiguous..." If I misunderstood you, please feel free to correct. OTHO, as it is not explicitly written, I would like to understand your stance on having this method name as a shorcut to copyFrom: start to: (self size). > But concerning #copyFrom:to: I think this name is a non issue for > code readability. Which I also agree, and add that it helps to keep the API as unambiguous as it gets. > I decided to play advocatus diaboli just to push > a bit absurdness of this ubuesque thread. It may sound like because we're thinking only in our crib space. The OP brought a point which converges with other threads in this mailing list about the difficulties an [Smalltalk] aficionado incurs when trying to show Smalltalk to people who already know present technology languages and environments. > In Smalltalk, you have to > trust what you read, and to me (aString copyFrom: 2 to: aString size > - 3) is obviously a copy, and arguments are obviously indices, what > else could it be ? I do agree 100% on this. However, there is a rub: aComplicatedName copyFrom: pocnu to: kraja. What can they be? As Smalltalk is dynamic even if you could see the |pocnu kraja| . . . you'll probably would need to see the implementers of the code that attribute values to these (say) local variables. And to avoid lengthy and unnecessary follow ups on this: I don't see any problem on this, because Smalltalk (and Pharo in particular) makes this easy enough to do. > So no, I don't suggest to drop the copy though > it's not strictly necessary, nor to append an Index to the name. Great! ;-) > Who never browsed senders of such message in squeaksource code base > could have such a foolish idea. Again I think this is a reasoning that only can be explained due being too comfy in our crib: Put this stub of code in a book (especially if the dead tree variety) and claim that it is only a 'browsing of sender' away and you will understand WHY the whole thread is not that much "ubuesque" as it seemed at first... > For writing code, we can't just guess an API, so this is a non > issue too. I can't guess the name, it could be > #copyFromStartIndex:toStopIndex: or just #from:to:, no way the API > will fit everyone's brain. Right we should not guess, but it is not the whole story. There is some ergonomics in a well designed interface of the APIas put in the issue tracker. Names should be as consistent as possible and be concurrent to present programming practices. This will ease the way people learn and think in the programming language. > For writing code we have these > alternatives: > - Open a Browser and browse the collection classes learn idioms from > - reading other code learn idioms from a tutorial or a help system > - type a keyword in a message finder, or some receiver arguments and > expected results. All these actions will clearly disambiguate the > semantic of copyFrom:to: arguments. We can tolerate some level of > ambiguity when the send sites will disambiguate. The semantics of copyFrom:to: are not the issue. The issue as is written in the issue tracker _and_ the subject line is the semantics of copyFrom: > As for homogeneity, I don't propose anything but statu quo. I > understand (aString first: 3) as well as extending (aString first), > and I can reasonnably guess it will answer a copy too, why the hell > would this innocent message change aString state ? I agree with the later, but not with the former: could aString first return a String or Character? > Does (aString first) do ? > So no, I don't need to add a copy prefix to this > message, and no i don't really care for a higher homogeneity. > If we change a few missnamed selectors here and there, that's OK, > but if we change a large amount of Kernel messages with many > senders, it's a recipee for Pharo rejection, because we would make > developer's life a hell for no valid reason. Or not! There is no reason why a newer "kernel" be created and if the usage of it be so compelling or productive or practical or ....<put your favorite marketing word> that it takes over the present state of affairs in the usage of Smalltalk, why not!? -- Cesar Rabak

Jan. 7, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by Adrian Lienhard

On Jan 7, 2011, at 20:10 , Sven Van Caekenberghe wrote: > > On 07 Jan 2011, at 13:58, StÃ©phane Ducasse wrote: > >> I was just reading the code with olivier auverlot. >> I would love to have a small if possible replacement to the HTTPSocket. > > There really is a lot of cleanup to do. > > The key/core replacement of HTTP client functionality is done, but HTTPSocket does so much stuff in such bizar ways that it will require a concerted effort of many people to clean it up. I guess that a lot of stuff isn't needed anymore and hence doesn't need to be reimplemented (?). We could deprecate such methods (or just delete them) and if later we figure some are really needed we can put them back again. I've quickly browser the references to HTTPSocket in PharoCore and there are not too many complicated ones, as far as I can tell. Adrian

Jan. 7, 2011