October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] XMLParser & PharoExtras, XMLWriter, XPath: status?

by StÃ©phane Ducasse

Hi hernan this is great it shows up in the catalog list. https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? Now could you add the catalog metadata information to the configuration. I will improve the catalog generator to generate the missing method template. if you give me access to the repo I can also do it for you. Stef On Oct 1, 2013, at 8:23 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > El 29/09/2013 11:01, StÃ©phane Ducasse escribiÃ³: >> cool is it standalone? > > Yes > >> Could you add the catalog metadata and publish it in metarepository like that it will be documented on the catalog. >> You can take as example Soup or OSC on PharoExtras >> > > Done. I have added usage example. Let me know if anything is missing. > > Cheers, > > HernÃ¡n > >> Stef >> On Sep 29, 2013, at 12:42 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >>> Already migrated >>> >>> http://www.smalltalkhub.com/#!/~hernan/XMLPullParser >>> >>> I use it a lot to parse really big XMLs >>> >>> El 29/09/2013 7:05, StÃ©phane Ducasse escribiÃ³: >>>> It would be good to migrate this one >>>> XMLPullParser >>>> <http://pharo.gemtalksystems.com/book/LanguageAndLibraries/XML/XML-support-i…> : >>>> Supports StAX. http://www.squeaksource.com/XMLPullParser.html to >>>> smalltalkhub. >>>> Does anybody use it? >>>> >>>> On Sep 28, 2013, at 11:42 PM, HernÃ¡n Morales Durand >>>> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>>> >>>>> El 28/09/2013 14:38, phil(a)highoctane.be <mailto:phil@highoctane.be> >>>>> escribiÃ³: >>>>>> In the Pharo 20 image, I see that we do have XMLParser, XMLPullParser, >>>>>> XMLWriter and XPath listed in the configuration (new install with >>>>>> ZeroConf). >>>>>> >>>>>> I am also using Soup. >>>>>> >>>>>> That's because I am working on some OpenData and screen scraping work >>>>>> and wondered what was okay to use. >>>>>> >>>>>> Is Soup depending on these? (I have XMLReader and Writer in my image but >>>>>> don't know from where at the moment - but there are no tests, so only >>>>>> something like #Core was loaded. >>>>>> >>>>>> Also what is different between XMLParser and XMLPullParser? >>>>>> >>>>> >>>>> http://pharo.gemtalksystems.com/pier/book/LanguageAndLibraries/XML/XML-supp… >>>>> >>>>>> TIA >>>>>> Phil >>>>> >>>>> >>>> >>> >>> >> >> >> > >

Oct. 1, 2013

Re: [Pharo-dev] SlotVirus

by Pavel Krivanek

2013/10/1 Marcus Denker <marcus.denker(a)inria.fr>: > > On Oct 1, 2013, at 9:23 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Oct 1, 2013, at 9:07 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> And we should not forget to do these cleanups: we now have nearly everything double in the system: >>> -> Compiler >>> -> Inspector >>> -> Debugger >>> -> ClassBuilder >>> -> ClassOrganizer >>> -> Browserâ¦. >> >> -> Rpackage vs PackaInfo vs. SystemCategory >> -> Ring vs. PseudeClass&co vs. RBClass >> -> AST vs RB AST > > -> Url vs. ZnUrl > -> ZnMimeType vs MimeType > -> NewList vs whichever-of-the 30 classes with "List" in its name > -> FreeType vs. Bitmap fonts > -> TreeInspector vs. ObjectExplorer > > We should really clean up. > Do you remember the picture with a lighthouse starting as a rocket? I's normal for space vehicles to have doubled systems ;-) -- Pavel

Oct. 1, 2013

Re: [Pharo-dev] "as yet unclassified" protocol remains when empty

by Goubier Thierry

Hi Ben, I think it has already been noticed as a bug, so it will be corrected. Not sure there is already an issue about it, however. Regards, Thierry Le 01/10/2013 15:43, btc(a)openinworld.com a Ã©crit : > I wanted to check this was not a feature before reporting an issue. > Previously in Pharo 2.0, when the protocol "as yet unclassified" became > empty, it disappeared. > In Pharo 30434, it does not disappear when empty. > Really a small thing, but I prefer the previous behaviour. > > cheers -ben > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 1, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Henrik Johansen

On Sep 28, 2013, at 10:59 , Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the feedback guys. > > Based on the discussion I propose a different set of changes: > > 1. > shuffle > ^ self shuffleBy: Random new > > 2. > shuffled > ^ self copy shuffle > > 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) > > > I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). > > Also open for discussion is the use of Collection>>randomForPicking and Collection>>mutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. > > Cheers, > Max +1 from me on all three suggestions, as you might guess. :) As for #atRandom using Random new, the performance hit and seed quality would be much greater concerns, as the Random instance would only be used once per invocation. At this point in time there's no good alternatives to the current approach, but renaming the mutex/shared variable to reflect its singular use would be one possible improvement, I guess. Cheers, Henry

Oct. 1, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Max Leske

bump... > Thanks for the feedback guys. > > Based on the discussion I propose a different set of changes: > > 1. > shuffle > ^ self shuffleBy: Random new > > 2. > shuffled > ^ self copy shuffle > > 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to) > > > I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace). > > Also open for discussion is the use of Collection>>randomForPicking and Collection>>mutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection. > > Cheers, > Max > > > On 24.09.2013, at 02:33, btc(a)openInWorld.com wrote: > >> Nicolas Cellier wrote: >>> >>> The reason why I don't like the explicit "copy", is because this is the >>> default behaviour. >>> In place mutation is an (evil) exception. >>> I'm personnally fine with current conventions: >>> - sort, shuffle, reverse, replace: are imperative, thus you are telling >>> collection, sort yourself ! >>> - sorted clearly sounds as a sorted copy for me. >>> If ever a change was to be made, I would much prefer this to happen on >>> opposite naming, sort -> inPlaceSort, or sortYourself :) >>> It's like telling the programmer, hey - a stateful mutation is really what >>> you want, is it? >>> >> >> Conventions should encourage good programming practice. Although it makes perfect sense on hearing it, I was explicitly not aware of the convention between 'sort' and 'sorted'. For me, the small difference in letters used between the two doesn't provide a wide enough distinction. Also, regarding not mutating state, I guess I knew that in the back of my head, but it has not generally been an explicit concern of mine while programming. Convention should encourage good programming. So I like the suggestion of inPlaceSort & sortYourself. As well as being more intention revealing, the less desirable methods are made less attractive by using a longer name. Perhaps another naming convention could be mutatedSort, or mutSort as a hint that the programmer should consider using these in conjunction with mutexes, or at own risk. >> >> cheers -ben >> >> >> >>> 2013/9/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>> >>>> +1 >>>> Now I understand the point of max with the name sort/sorted because this >>>> is not explicit to me too :) >>>> I laways have to think. >>>> >>>> On Sep 23, 2013, at 6:28 PM, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> 100% agree. >>>> Do it right > do it fast. >>>> We must not turn usage of the library into something fragile for the sake >>>> of speed. >>>> We already make the code itself fragile more often than not in term of >>>> complexity (harder to understand/test/change). >>>> >>>> Especially, introduction of shared mutable states (global, class vars, >>>> singleton or any other form) should ring an alarm in reviewers head >>>> (This is some very old Squeak code in this case, so Squeakers are to >>>> blame, but we're all in same bath). >>>> >>>> >>>> >>>> 2013/9/23 Henrik Johansen <henrik.s.johansen(a)veloxit.no> >>>> >>>> >>>>> On Sep 23, 2013, at 3:33 , Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>> >>>>>>> If a user is going to modify the same object concurrently, he/she >>>>>>> >>>>> takes care of mutual exclusion. >>>>> >>>>>> Agreed. BUT: the Random object used by these methods is the same one >>>>>> >>>>> that is used by #atRandom for instance, hence the race condition. There is >>>>> no way anyone can safely use these methods without the mutex, single >>>>> threaded or not. Calls to methods using that same Random object can be all >>>>> over the place and also in the base system. >>>>> >>>>> >>>>> It seems to me an existing Random instance is used in this case mostly* >>>>> for performance. >>>>> One could argue that since the Random in this case is used for a bulk >>>>> operation, for which the object creation cost is largely amortized for >>>>> collection sizes > 20, it's acceptable to instead use Random new by >>>>> default, which wouldn't suffer from the same race conditions. >>>>> While still slower than a mutex-protected version for single-threaded >>>>> code, it would also scale correctly if the users (and vm) are actually >>>>> multi-threaded. >>>>> >>>>> [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffle] bench '208,000 per second.' >>>>> '222,000 per second.' '223,000 per second.' >>>>> [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleWithMutex] bench '188,000 per >>>>> second.' '186,000 per second.''184,000 per second.' >>>>> [#(1 2 3 4 5 6 7 8 9 10 11 12) shuffleNewRandom] bench '167,000 per >>>>> second.' '166,000 per second.' '167,000 per second.' >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> * Low seed entropy is another issue, but if purely random shuffling is a >>>>> critical requirement, one shouldn't use the default Random generator >>>>> anyways... >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >

Oct. 1, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by Nicolas Passerini

Hi Demian, I've been using your ppa for a while, but I could have the last update working. This is the information I've got: npasserini@pablitar-xps:~/Downloads$ sudo apt-get install pharo-launcher:i386 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: pharo-launcher:i386 0 upgraded, 1 newly installed, 0 to remove and 193 not upgraded. Need to get 0 B/15.3 MB of archives. After this operation, 48.0 MB of additional disk space will be used. (Reading database ... 552696 files and directories currently installed.) Unpacking pharo-launcher:i386 (from .../pharo-launcher_2013.09.27-1~ppa1~precise1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/pharo-launcher_2013.09.27-1~ppa1~precise1_i386.deb (--unpack): trying to overwrite '/usr/share/man/man1/pharo.1.gz', which is also in package pharo-vm-core:i386 2013.06.12-1~ppa1~precise1 Processing triggers for desktop-file-utils ... Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/pharo-launcher_2013.09.27-1~ppa1~precise1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Any clue? Is there any information else, that I could give you to help find out the problem? On Thu, Sep 26, 2013 at 10:58 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Thu, Sep 26, 2013 at 2:04 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > > Is this why image launching fails, or is it unrelated ? > > > open a new thread about that please. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Oct. 1, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 1 regressions found. Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 1, 2013

[update 3.0] #30438

by Marcus Denker

Oct. 1, 2013

"as yet unclassified" protocol remains when empty

by btc＠openinworld.com

I wanted to check this was not a feature before reporting an issue. Previously in Pharo 2.0, when the protocol "as yet unclassified" became empty, it disappeared. In Pharo 30434, it does not disappear when empty. Really a small thing, but I prefer the previous behaviour. cheers -ben

Oct. 1, 2013

[update 3.0] #30437

by Marcus Denker

Oct. 1, 2013