- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo 1.0 release plan

by Adrian Lienhard

Hi everyone, Last week in Bern, Marcus, Stef, and I have been discussing a plan for a first release of Pharo. Overall, the goal is to produce a valuable, stable "product" within reasonable time. Is there anything important we missed? Any suggestions? FUNCTIONAL REQUIREMENTS -------------------------------------------- Integrate Polymorph Integrate TrueType Main EToys removal Refactor Traits API NON-FUNCTIONAL REQUIREMENTS -------------------------------------------- All tests green License clean (check OLPC changes) First consistent version of the website (work in progress) INFRASTRUCTURE -------------------------------------------- Increase efficiency of producing new updates (work in progress) Prepare second update stream to maintain released version TENTATIVE SCHEDULE -------------------------------------------- Going beta in January Release of version 1.0 in February Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

Nov. 2, 2008

[Pharo-project] Rio's very minor dependency upon Null removed

by Keith Hodges

for nullphobics see subject Keith

Nov. 2, 2008

[Pharo-project] [ANN] update 10129

by Adrian Lienhard

- delete unused vars in Morphic (Lukas R.) - fix loop of linked list test (Damien P.) Adrian ___________________ http://www.adrian-lienhard.ch/

Nov. 2, 2008

Re: [Pharo-project] Infinite loop in new Collection Tests

by Damien Pollet

On Sat, Nov 1, 2008 at 8:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > damien so may be we should have > valueAt: or elementAt: Good idea, that would reinforce the parallel with Dictionary. > Now may be we should have different tests. > This is important to get the tests green since this is a goal of pharo 1.0 Well, it's easy to have green tests, just comment out the assertions. Or remove the broken code. I mean, there is a problem with how that class behaves, compared to the other collections. > On Nov 1, 2008, at 5:11 PM, Damien Pollet wrote: > >> On Sat, Nov 1, 2008 at 3:57 PM, nicolas cellier <ncellier(a)ifrance.com> >> wrote: >>> >>> While running TestRunner, i noticed this: >>> >>> LinkedListTest>>testTAdd does an infinite loop. >> >> yes, this is fixed in the next commit in PharoInbox. >> >>> Anyway, I find LinkedList is NOT a generic Collection but rather a single >>> not reusable hack for Process. >> >> Exactly. The tests do not loop anymore, but now some fail because >> LinkedList is not polymorphic with other SequenceableCollections, e.g >> you cannot do LinkedList new add: 42 because it expects instances of >> Link as elements. >> >>> This is regularly bugging newcomers, and I would recommend an evolution >>> toward something like >>> >>> http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html >> >> Great! I will have a look at that. >> >>> That is, Link should be a transparent-implementation-defined-intermediate >>> not visible via standard add:/remove:/do: messages. >>> User should not have to provide a Link, but only the value. >> >> Well I think there should be a linked-list-specific protocol for >> dealing with links, either via link objects or by delegation through >> LinkedList. But this should not overlap with the >> SequenceableCollection protocol. >> >>> Only LinkedList specialized messages like addLink: removeLink: linksDo: >>> should deal with user provided Link for more advanced features. >>> Think of Dictionary and Association. A user can use Dictionary with: at: >>> / >>> at:put: without knowing about Association. >> >> Exactly >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 1, 2008

[Pharo-project] SLICE-Object-isTransparent-GwenaelCasaccio.2?

by Adrian Lienhard

Hi Gwenael, In PharoInbox there is the following slice, but I don't know which issue it corresponds to (please always add the issue number in the slice comment or file name)? Cheers, Adrian Name: SLICE-Object-isTransparent-GwenaelCasaccio.2 Author: GwenaelCasaccio Time: 31 October 2008, 2:45:20 pm UUID: fdf5a312-c557-4c5d-a071-50f6369ae8c4 Ancestors: SLICE-Object-isTransparent-GwenaelCasaccio.1 Remove isTransparent from Object and add lazy initialization for the accessors topLeftColor, bottomRightColor of the class SimpleBorder ___________________ http://www.adrian-lienhard.ch/

Nov. 1, 2008

Re: [Pharo-project] Infinite loop in new Collection Tests

by StÃ©phane Ducasse

damien so may be we should have valueAt: or elementAt: Now may be we should have different tests. This is important to get the tests green since this is a goal of pharo 1.0 Ste On Nov 1, 2008, at 5:11 PM, Damien Pollet wrote: > On Sat, Nov 1, 2008 at 3:57 PM, nicolas cellier > <ncellier(a)ifrance.com> wrote: >> While running TestRunner, i noticed this: >> >> LinkedListTest>>testTAdd does an infinite loop. > > yes, this is fixed in the next commit in PharoInbox. > >> Anyway, I find LinkedList is NOT a generic Collection but rather a >> single >> not reusable hack for Process. > > Exactly. The tests do not loop anymore, but now some fail because > LinkedList is not polymorphic with other SequenceableCollections, e.g > you cannot do LinkedList new add: 42 because it expects instances of > Link as elements. > >> This is regularly bugging newcomers, and I would recommend an >> evolution >> toward something like >> http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html > > Great! I will have a look at that. > >> That is, Link should be a transparent-implementation-defined- >> intermediate >> not visible via standard add:/remove:/do: messages. >> User should not have to provide a Link, but only the value. > > Well I think there should be a linked-list-specific protocol for > dealing with links, either via link objects or by delegation through > LinkedList. But this should not overlap with the > SequenceableCollection protocol. > >> Only LinkedList specialized messages like addLink: removeLink: >> linksDo: >> should deal with user provided Link for more advanced features. >> Think of Dictionary and Association. A user can use Dictionary >> with: at: / >> at:put: without knowing about Association. > > Exactly > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2008

Re: [Pharo-project] mac menus in Pharo

by John M McIntosh

On Nov 1, 2008, at 5:04 AM, Adrian Lienhard wrote: > To integrate these changes, you could just give us a change set (I > assume the current Unnamed changeset in the image contains all > relevant changes already), and we will then deal with MC. > > Adrian Ffenestri-b-2-WindowProxies Ffenestri-b-3-MultiHostWindows-Sunits Ffenestri-b-4-Events-Morphic HostMenus-Base HostMenus-Events HostMenus-Mac-SUnits HostMenus-Fixes-1 HostMenus-PostLoad-Changes See pharo10124WithMacMenus.2.image which I've placed on the idisk. I've made some changes one of the issues was using TheWorldMenu new, versus World worldMenu which seemed to fix the problem with some Preference menu cmds not doing anything. I note some menu lines are missing in the Preference menu, these are specialized toggled menu items. If someone wants to fiddle with those it requires a bit more integration to toggle the mac menu state as you change the state of the global, email me for details. Lastly I fixed the host menus test -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 1, 2008

Re: [Pharo-project] Infinite loop in new Collection Tests

by Damien Pollet

On Sat, Nov 1, 2008 at 3:57 PM, nicolas cellier <ncellier(a)ifrance.com> wrote: > While running TestRunner, i noticed this: > > LinkedListTest>>testTAdd does an infinite loop. yes, this is fixed in the next commit in PharoInbox. > Anyway, I find LinkedList is NOT a generic Collection but rather a single > not reusable hack for Process. Exactly. The tests do not loop anymore, but now some fail because LinkedList is not polymorphic with other SequenceableCollections, e.g you cannot do LinkedList new add: 42 because it expects instances of Link as elements. > This is regularly bugging newcomers, and I would recommend an evolution > toward something like > http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html Great! I will have a look at that. > That is, Link should be a transparent-implementation-defined-intermediate > not visible via standard add:/remove:/do: messages. > User should not have to provide a Link, but only the value. Well I think there should be a linked-list-specific protocol for dealing with links, either via link objects or by delegation through LinkedList. But this should not overlap with the SequenceableCollection protocol. > Only LinkedList specialized messages like addLink: removeLink: linksDo: > should deal with user provided Link for more advanced features. > Think of Dictionary and Association. A user can use Dictionary with: at: / > at:put: without knowing about Association. Exactly -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 1, 2008

Re: [Pharo-project] Infinite loop in new Collection Tests

by StÃ©phane Ducasse

a link should also have some state :) StackLink is ok for that. On Nov 1, 2008, at 3:57 PM, nicolas cellier wrote: > While running TestRunner, i noticed this: > > LinkedListTest>>testTAdd does an infinite loop. > > This is because: > self collection first == self element > > since the test does: > self collection add: self element > > this results in: > self collection firstLink next next == firstLink > > and consequently any loop will loop infinitely... It seems to me that this is bug of damien P. so he will probably fix that. Stef > > > My base image is not well equipped with a Trait-aware Browser, so i > let this one to Trait experts. > > > Anyway, I find LinkedList is NOT a generic Collection but rather a > single not reusable hack for Process. > This is regularly bugging newcomers, and I would recommend an > evolution toward something like http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html > > That is, Link should be a transparent-implementation-defined- > intermediate not visible via standard add:/remove:/do: messages. > User should not have to provide a Link, but only the value. > Only LinkedList specialized messages like addLink: removeLink: > linksDo: should deal with user provided Link for more advanced > features. > > Think of Dictionary and Association. A user can use Dictionary with: > at: / at:put: without knowing about Association. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2008

[Pharo-project] Infinite loop in new Collection Tests

by nicolas cellier

While running TestRunner, i noticed this: LinkedListTest>>testTAdd does an infinite loop. This is because: self collection first == self element since the test does: self collection add: self element this results in: self collection firstLink next next == firstLink and consequently any loop will loop infinitely... My base image is not well equipped with a Trait-aware Browser, so i let this one to Trait experts. Anyway, I find LinkedList is NOT a generic Collection but rather a single not reusable hack for Process. This is regularly bugging newcomers, and I would recommend an evolution toward something like http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html That is, Link should be a transparent-implementation-defined-intermediate not visible via standard add:/remove:/do: messages. User should not have to provide a Link, but only the value. Only LinkedList specialized messages like addLink: removeLink: linksDo: should deal with user provided Link for more advanced features. Think of Dictionary and Association. A user can use Dictionary with: at: / at:put: without knowing about Association. Nicolas

Nov. 1, 2008