May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] new gettext package

by StÃ©phane Ducasse

Excellent! We should decide if we want to maintain it or not. Then we can create a package for it. Stef On May 7, 2010, at 4:17 PM, Hilaire Fernandes wrote: > I have uploaded a new version of the gettext package. I have removed a few classes used for the itnernal translator. So now, only gettext based catalog messages is used. > > Philipp, I have added a String>>translateTo: aLocale you can used from Seaside application. > > If we agree on that protocole, we can have in Pharo-Cire two String messages defined as follow: > > String>>translated > "answer the receiver translated to the default language" > ^ NaturalLanguageTranslator translate: self > > String>>translatedTo: localeID > "answer the receiver translated to the given locale id" > ^ NaturalLanguageTranslator translate: self toLocale: localeID > > > Then a dummy class NaturalLanguageTranslator withn two class messages: > > NaturalLanguageTranslator class>>translate: aString > ^ aString > > NaturalLanguageTranslator class>>translate: aString toLocale: localeID > ^ aString > > > NaturalLanguageTranslator class is redefined in the Gettext package. > > It should be possible to simplify the whole protocole after removing the LanguageEditor. This one is totaly unused, and it does not make sense to me to use Smalltalk to translated string, there are better third party tool to do that. Can I remove the LanguageEditor? > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 8, 2010

Re: [Pharo-project] Newbie: How to load and use HTTP parser

by StÃ©phane Ducasse

On May 7, 2010, at 5:07 PM, Andrei Stebakov wrote: > Hi > > Sent this message to the Pharo-users group, but no response for a couple of days, so trying it here ;) > > I have a simple task of parsing some html content in Pharo (loading an html page using HTTPSocket and retrieving useful info from it). > Having browsed for an html parser in my current one-click Pharo 1.0 image, I couldn't find one. > How do I find/download a (the) HTML parser? I know that there is a HTML. Check the squeaksource package HTML. If it works let us know else it should be fixed for 1.0 we should publish it in Metacello format > What's the general routine of discovering and installing packages in Pharo? I believe in Squeak there was a menu to explore and download packages, I couldn't find it in Pharo though. We are in the process of building an infrastructure for that. > > > Thank you, > Andrei > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 8, 2010

[Pharo-project] could we start to organize MetacelloRepository?

by StÃ©phane Ducasse

Hi Dale and others I would like to have a Pharo1.0 folder in the MetacelloRepository and ideally all the configurationOf... inside should work for Pharo 1.0. How can we proceed to get that. In the future we should also have a process to avoid that we get junk inside. any idea (I was thinking about an hudson server that would validate the configuration automatically) Stef

May 8, 2010

Re: [Pharo-project] is MVC package somewhere?

by StÃ©phane Ducasse

> Hi, > AFAIK, MVC was removed from Pharo 1.1... I wonder where is the extracted package. You can find some parts in the pharo repository. Now it will not be working. Ideally we would like to have a MVC package loading and working in Pharo but not at the price of isMorphic everywhere and Smalltalk at: #MVCClass ifAbsent:... Stef

May 8, 2010

Re: [Pharo-project] infinite loop when Locale changed

by StÃ©phane Ducasse

On May 7, 2010, at 7:20 PM, Hilaire Fernandes wrote: > What is the use to call StrikeFont localeChanged. > It is provocing an infinite loop when Locale is changed > it comes from the StrikeFont localeChanged message > > What is supposed to do StrikeFont localeChanged ? > > Hilaire > > > Locale class>>localeChanged > #(#ParagraphEditor) do: [ :key | Smalltalk globals at: key ifPresent: [ :class | class initialize ] ]. > StrikeFont localeChanged. > Project localeChanged > May be to load ohter fonts for chinses japanese support? > > http://code.google.com/p/pharo/issues/detail?id=2391 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 8, 2010

Re: [Pharo-project] another fun case for Linked>>add:

by StÃ©phane Ducasse

Thanks for the info :) >> yeah, i think its protocol could have two entry points: >> - #add: for adding an object to list >> - #addLink: for linking a link to list >> >> so, that, #add: always creates a new instance of ValueLink , without >> asking object to do #asLink >> and then sends #addLink: , which does the rest. > I don't quite see the appeal in an approach which both has a more complicated protocol, and is backwards-incompatible. > > Cheers, > Henry > > PS. We DID consider other possible solutions before deciding to add "yet another" as... method to Object >

May 8, 2010

Re: [Pharo-project] another fun case for Linked>>add:

by Henrik Johansen

Den 8. mai 2010 kl. 01.20 skrev Igor Stasenko <siguctua(a)gmail.com>: > On 8 May 2010 02:07, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com > > wrote: >> 2010/5/8 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> As Nicolas described, linkedlists certainly have their usecases. >>> >>> I think you might be blurring cause and effect when using is only >>> used in >>> process handling, as an argument why the easier-to-use, no >>> noticeable >>> performance overhead (but slightly more complex implementation >>> wise) version >>> should be reverted. >>> >>> Cheers, >>> Henry >>> >> >> Personnally, I like a LinkedList being able to hide the Link the way >> Dictionary hides the Association. >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117262.html >> http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html >> > > yeah, i think its protocol could have two entry points: > - #add: for adding an object to list > - #addLink: for linking a link to list > > so, that, #add: always creates a new instance of ValueLink , without > asking object to do #asLink > and then sends #addLink: , which does the rest. I don't quite see the appeal in an approach which both has a more complicated protocol, and is backwards-incompatible. Cheers, Henry PS. We DID consider other possible solutions before deciding to add "yet another" as... method to Object > >> Nicolas >> >>> Den 8. mai 2010 kl. 00.06 skrev Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>> 2010/5/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>> 2010/5/7 Igor Stasenko <siguctua(a)gmail.com>: >>>>>> >>>>>> On 7 May 2010 23:47, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>>> >>>>>>>> He had the idea that it would be nice to be able to add any >>>>>>>> object to >>>>>>>> a LinkedList, instead of just Link subclasses. (IIRC, 'like >>>>>>>> you can in Ruby' >>>>>>>> ;)) >>>>>>>> >>>>>>>> So we added ValueLink as the common pattern for "A link with >>>>>>>> an object >>>>>>>> in it", which is now the default if you add an object which >>>>>>>> itself is not a >>>>>>>> link. >>>>>>>> >>>>>>>> Makes it much more convenient to actually use a LinkedList, >>>>>>>> ref. f.ex. >>>>>>>> the Stack implementation. >>>>>>> >>>>>>> LinkedList is used internally by the process scheduler to handle >>>>>>> processes, I don't think that it is ment to be used as a public >>>>>>> collection class. For probably all applications it is slower >>>>>>> and uses >>>>>>> more memory than an OrderedCollection. >>>>>>> >>>>>> +1. >>>>>> OrderedCollection's addLast/removeFirst/removeLast, is enough >>>>>> to use >>>>>> them as lists. >>>>>> >>>>>> About performance, i am little concerned. >>>>>> Linked lists is good , that is costs you a constant time for >>>>>> each new >>>>>> element you adding. >>>>>> While for OrderedCollections it vary depending on container >>>>>> state. In >>>>>> most cases, it costs you as little as for linked lists, but when >>>>>> contained is not big enough to hold all elements - then it has >>>>>> to grow >>>>>> and consuming a lot more time comparing to adding a previous >>>>>> element. >>>>>> >>>>> >>>>> Yes, LinkedList is most interesting when you add:after:/remove: in >>>>> between... >>>>> OrderedCollection also isn't at best when used as FIFO because >>>>> repeted >>>>> addLast/removeFirst will trigger a makeRoomAtLast. >>>>> It might be better to handle a cyclic index. >>>>> For example, I would maintain firstIndex and size in inst vars: >>>>> >>>>> addLast:anObject >>>>> array size > size ifFalse: [self grow]. >>>>> array atWrap: firstIndex + size put: anObject. >>>>> size := size + 1. >>>>> ^anObject >>>>> >>>>> removeFirst >>>>> | firstObject | >>>>> self emptyCheck. >>>>> firstObject := array at: firstIndex. >>>>> array at: firstIndex put: nil. >>>>> firstIndex := firstIndex \\ array size + 1. >>>>> size := size - 1. >>>>> ^firstObject >>>>> >>>>> grow >>>>> | grown end | >>>>> grown := Array new: array size + self growSize. >>>>> end := (firstIndex + size - 1 min: array size) - firstIndex + 1. >>>>> grown replaceFrom: 1 to: end with: array starting at: firstIndex. >>>>> grown replaceFrom: end +1 to: size with: array startingAt; 1. >>>>> array := grown >>>> >>>> Oops, forgot >>>> firstIndex := 1 >>>> >>>>> >>>>> Of course, you still pay the grow... >>>>> >>>>> Nicolas >>>>> >>>>>>> Lukas >>>>>>> >>>>>>> -- >>>>>>> Lukas Renggli >>>>>>> www.lukas-renggli.ch >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>

May 7, 2010

Re: [Pharo-project] another fun case for Linked>>add:

by Ralph Boland

> +1. > OrderedCollection's addLast/removeFirst/removeLast, is enough to use > them as lists. > > About performance, i am little concerned. > Linked lists is good , that is costs you a constant time for each new > element you adding. > While for OrderedCollections it vary depending on container state. In > most cases, it costs you as little as for linked lists, but when > contained is not big enough to hold all elements - then it has to grow > and consuming a lot more time comparing to adding a previous element. > Given that the amortized cost is still O(1) per add or remove when using OrderedCollections I think the cost of the grows can be ignored unless the OrderedCollections are so large as to cause memory or memory management problems or if your algorithm is real time and cannot tolerate the occasional slowdown during a grow operation. In the latter situation I ask: why are you using an automatic garbage collected language such as Smalltalk? I expect the performance of OrderedCollections used as stacks or queues to be good compared to linked lists. Regards, Ralph Boland -- Quantum Theory cannot save us from the tyranny of a deterministic universe but it does give God something to do

May 7, 2010

Re: [Pharo-project] another fun case for Linked>>add:

by Igor Stasenko

On 8 May 2010 02:07, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/5/8 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> As Nicolas described, linkedlists certainly have their usecases. >> >> I think you might be blurring cause and effect when using is only used in >> process handling, as an argument why the easier-to-use, no noticeable >> performance overhead (but slightly more complex implementation wise) version >> should be reverted. >> >> Cheers, >> Henry >> > > Personnally, I like a LinkedList being able to hide the Link the way > Dictionary hides the Association. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117262.html > http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html > yeah, i think its protocol could have two entry points: - #add: for adding an object to list - #addLink: for linking a link to list so, that, #add: always creates a new instance of ValueLink , without asking object to do #asLink and then sends #addLink: , which does the rest. > Nicolas > >> Den 8. mai 2010 kl. 00.06 skrev Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >> >>> 2010/5/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>> 2010/5/7 Igor Stasenko <siguctua(a)gmail.com>: >>>>> >>>>> On 7 May 2010 23:47, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>> >>>>>>> He had the idea that it would be nice to be able to add any object to >>>>>>> a LinkedList, instead of just Link subclasses. (IIRC, 'like you can in Ruby' >>>>>>> ;)) >>>>>>> >>>>>>> So we added ValueLink as the common pattern for "A link with an object >>>>>>> in it", which is now the default if you add an object which itself is not a >>>>>>> link. >>>>>>> >>>>>>> Makes it much more convenient to actually use a LinkedList, ref. f.ex. >>>>>>> the Stack implementation. >>>>>> >>>>>> LinkedList is used internally by the process scheduler to handle >>>>>> processes, I don't think that it is ment to be used as a public >>>>>> collection class. For probably all applications it is slower and uses >>>>>> more memory than an OrderedCollection. >>>>>> >>>>> +1. >>>>> OrderedCollection's addLast/removeFirst/removeLast, is enough to use >>>>> them as lists. >>>>> >>>>> About performance, i am little concerned. >>>>> Linked lists is good , that is costs you a constant time for each new >>>>> element you adding. >>>>> While for OrderedCollections it vary depending on container state. In >>>>> most cases, it costs you as little as for linked lists, but when >>>>> contained is not big enough to hold all elements - then it has to grow >>>>> and consuming a lot more time comparing to adding a previous element. >>>>> >>>> >>>> Yes, LinkedList is most interesting when you add:after:/remove: in >>>> between... >>>> OrderedCollection also isn't at best when used as FIFO because repeted >>>> addLast/removeFirst will trigger a makeRoomAtLast. >>>> It might be better to handle a cyclic index. >>>> For example, I would maintain firstIndex and size in inst vars: >>>> >>>> addLast:anObject >>>> Â array size > size ifFalse: [self grow]. >>>> Â array atWrap: firstIndex + size put: anObject. >>>> Â size := size + 1. >>>> Â ^anObject >>>> >>>> removeFirst >>>> Â | firstObject | >>>> Â self emptyCheck. >>>> Â firstObject := array at: firstIndex. >>>> Â array at: firstIndex put: nil. >>>> Â firstIndex := firstIndex \\ array size + 1. >>>> Â size := size - 1. >>>> Â ^firstObject >>>> >>>> grow >>>> Â | grown end | >>>> Â grown := Array new: array size + self growSize. >>>> Â end := (firstIndex + size - 1 min: array size) - firstIndex + 1. >>>> Â grown replaceFrom: 1 to: end with: array starting at: firstIndex. >>>> Â grown replaceFrom: end +1 to: size with: array startingAt; 1. >>>> Â array := grown >>> >>> Oops, forgot >>> Â firstIndex := 1 >>> >>>> >>>> Of course, you still pay the grow... >>>> >>>> Nicolas >>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 7, 2010

Re: [Pharo-project] another fun case for Linked>>add:

by Nicolas Cellier

2010/5/8 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > As Nicolas described, linkedlists certainly have their usecases. > > I think you might be blurring cause and effect when using is only used in > process handling, as an argument why the easier-to-use, no noticeable > performance overhead (but slightly more complex implementation wise) version > should be reverted. > > Cheers, > Henry > Personnally, I like a LinkedList being able to hide the Link the way Dictionary hides the Association. http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117262.html http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html Nicolas > Den 8. mai 2010 kl. 00.06 skrev Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com>: > >> 2010/5/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>> 2010/5/7 Igor Stasenko <siguctua(a)gmail.com>: >>>> >>>> On 7 May 2010 23:47, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>> >>>>>> He had the idea that it would be nice to be able to add any object to >>>>>> a LinkedList, instead of just Link subclasses. (IIRC, 'like you can in Ruby' >>>>>> ;)) >>>>>> >>>>>> So we added ValueLink as the common pattern for "A link with an object >>>>>> in it", which is now the default if you add an object which itself is not a >>>>>> link. >>>>>> >>>>>> Makes it much more convenient to actually use a LinkedList, ref. f.ex. >>>>>> the Stack implementation. >>>>> >>>>> LinkedList is used internally by the process scheduler to handle >>>>> processes, I don't think that it is ment to be used as a public >>>>> collection class. For probably all applications it is slower and uses >>>>> more memory than an OrderedCollection. >>>>> >>>> +1. >>>> OrderedCollection's addLast/removeFirst/removeLast, is enough to use >>>> them as lists. >>>> >>>> About performance, i am little concerned. >>>> Linked lists is good , that is costs you a constant time for each new >>>> element you adding. >>>> While for OrderedCollections it vary depending on container state. In >>>> most cases, it costs you as little as for linked lists, but when >>>> contained is not big enough to hold all elements - then it has to grow >>>> and consuming a lot more time comparing to adding a previous element. >>>> >>> >>> Yes, LinkedList is most interesting when you add:after:/remove: in >>> between... >>> OrderedCollection also isn't at best when used as FIFO because repeted >>> addLast/removeFirst will trigger a makeRoomAtLast. >>> It might be better to handle a cyclic index. >>> For example, I would maintain firstIndex and size in inst vars: >>> >>> addLast:anObject >>> Â array size > size ifFalse: [self grow]. >>> Â array atWrap: firstIndex + size put: anObject. >>> Â size := size + 1. >>> Â ^anObject >>> >>> removeFirst >>> Â | firstObject | >>> Â self emptyCheck. >>> Â firstObject := array at: firstIndex. >>> Â array at: firstIndex put: nil. >>> Â firstIndex := firstIndex \\ array size + 1. >>> Â size := size - 1. >>> Â ^firstObject >>> >>> grow >>> Â | grown end | >>> Â grown := Array new: array size + self growSize. >>> Â end := (firstIndex + size - 1 min: array size) - firstIndex + 1. >>> Â grown replaceFrom: 1 to: end with: array starting at: firstIndex. >>> Â grown replaceFrom: end +1 to: size with: array startingAt; 1. >>> Â array := grown >> >> Oops, forgot >> Â firstIndex := 1 >> >>> >>> Of course, you still pay the grow... >>> >>> Nicolas >>> >>>>> Lukas >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> www.lukas-renggli.ch >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 7, 2010