- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] Adding hudson links from pharo webpage?

by Schwab,Wilhelm K

I would not have thought to put it there, but it's a good idea. I think there should also be a link on the download section?? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Tudor Girba [tudor.girba(a)gmail.com] Sent: Friday, January 07, 2011 1:53 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Adding hudson links from pharo webpage? Currently, the link is here: http://pharo-project.org/community Cheers, Doru On 7 Jan 2011, at 19:22, Mariano Martinez Peck wrote: > Now that hudson seems to be working fine, I think it is a good moment to link hudson links from the pharo website. > > cheers > > mariano -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Adrian Lienhard

On Jan 7, 2011, at 10:15 , Johan Brichau wrote: > > On 07 Jan 2011, at 09:05, StÃ©phane Ducasse wrote: > >> I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport). >> I would favor push metacello so that in one click people can load what they want. > > +1 +1 I would also be rather conservative with regard to adding packages that are not developer tools. If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore). It appears to me that preloading packages like XML is just points out that a good package manager is missing. Cheers, Adrian

Jan. 7, 2011

[Pharo-project] What feature you want to see in Mondrian

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 7, 2011

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

by Nicolas Cellier

2011/1/7 <csrabak(a)bol.com.br>: > Em 07/01/2011 15:10, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: > > You make excellent points Nicolas! > > >> 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 Â ? > > I think we should, as the removal would have ripple effects in production code. > Our reasoning should be some sort of ROI on it. > >> Is it really what makes the message ambiguous ? > > I would argue that the presence of 'copy' suffix makes them _less_ ambiguous as > far as the methods in question effectively do a copy on the receiver. > >> Â 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. > > You mean that once you have removed the 'copy' prefix or as the method names stand right now (and I mean for the ones this issue number is about)? > >> Â I could expect: >> Â #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. >> Â to work like: >> Â #( 'foo' 'bar' 'baz') after: 'foo'. > > 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? > > > HTH > > -- > Cesar Rabak > > Here is what I mean: I agree that #copyFrom: is ambiguous and could be renamed, with all deprecation precautions. But concerning #copyFrom:to: I think this name is a non issue for code readability. I decided to play advocatus diaboli just to push a bit absurdness of this ubuesque thread. 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 ? So no, I don't suggest to drop the copy though it's not strictly necessary, nor to append an Index to the name. Who never browsed senders of such message in squeaksource code base could have such a foolish idea. 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. 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. 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 ? 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. Nicolas

Jan. 7, 2011

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

by csrabak＠bol.com.br

Em 07/01/2011 16:43, pharo(a)googlecode.com escreveu: > Comment #19 on issue 3436 by step...(a)stack.nl: #copyFrom: is broken > http://code.google.com/p/pharo/issues/detail?id=3436 > Nicolas wrote: > > 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 ? > It is one of the ambigueties. The ambiguity is of course a thing we have to qualify. The Collection hierarchy of Smalltalk uses Integers for indices for accessing elements. This is something you need to learn to be able to use these classes. > > > 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. > > - does it return a copy or change self does it return a collection Well the word 'copy' seems to indicate the it doesn't change self, if it did, we should open another issue and search for a fix. The other part of the enthymeme of yours must be pointed out to practicality and the sensible thing to do. The return would most of the time be the most appropriate collection given the intent of the extraction done by the method. Pathological cases should be issued and discussed for a fix. > - or an element are arguments elements or indices There is a limit on the 'non knowledge' you can [not] have in order to use the methods of a determined class. In Pharo you have as a last recourse the browsing of the method implementation itself. > should be reflected in the naming of the method, if one wants to > avoid having to read the implementation/comments. There should be a balance between the three. Otherwise you'll end up with too verbose API ("interface") for doing the daily chores, and people will frown and stop using the language. Even with OCompletion and friends, the most common operations should strive to have short method names and be relatively mnemonic for people who get trained in the environment/technology/language. > Currently, every method having copy in its name has to be examined > closely, to be able to decide what behavior should be > expected. Once we get evidence on this we could proceed. Do you have any case to show us? > Overriding semantics is less than helpful, as that leads > to more confusion. As long as there is no clear naming convention, > it is better to add new method names than to overlay new behavior on > existing ones. No. We have a history and production code to live with as well. In extremis your suggestion is better accomplished with a proposal for a new, parallel, hierarchy of classes with a 'better' interface, which put in the ecosystem should show if its benefits make developers to change to it instead of the present one. my 0.019999... -- Cesar Rabak

Jan. 7, 2011