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

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by Carla F. Griggio

Nope! I should learn how to do that :P I'll try to do it this week. On Tue, Sep 24, 2013 at 9:04 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi Carla, > > this is cool ! Is there a ready Pharo + Mars image built by jenkins server > ? > > Cheers, > > Laurent > > > On Tue, Sep 24, 2013 at 4:42 AM, Carla F. Griggio <carla.griggio(a)gmail.com > > wrote: > >> Hi everyone! >> I want to let you know that I've just posted a screencast in my blog >> about the new Mars Package Browser and Test Runner<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…> >> . >> These examples are not really intended as being the definitive package >> browser or test runner, but to start experiencing how is it to build a real >> application using Mars and to showcase some widgets. Anyway, it's cool :) >> The Package browser is not so different to the system browser example I >> showed before, but the Test Runner is definitely my favorite example so far. >> >> I give more details in the screencast<http://www.youtube.com/watch?v=RlBr42uaqxE>and the blog >> post<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…>. >> Any feedback is appreciated! >> >> Cheers, >> Carla. >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> >

Sept. 24, 2013

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by laurent laffont

Hi Carla, this is cool ! Is there a ready Pharo + Mars image built by jenkins server ? Cheers, Laurent On Tue, Sep 24, 2013 at 4:42 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Hi everyone! > I want to let you know that I've just posted a screencast in my blog about > the new Mars Package Browser and Test Runner<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…> > . > These examples are not really intended as being the definitive package > browser or test runner, but to start experiencing how is it to build a real > application using Mars and to showcase some widgets. Anyway, it's cool :) > The Package browser is not so different to the system browser example I > showed before, but the Test Runner is definitely my favorite example so far. > > I give more details in the screencast<http://www.youtube.com/watch?v=RlBr42uaqxE>and the blog > post<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…>. > Any feedback is appreciated! > > Cheers, > Carla. > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >

Sept. 24, 2013

Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)

by Marcel Taeumel

Hi! :) I am just trying out a tool thus querying the SmalltalkHub instance at smalltalkhub.com via its REST interface. Unfortunately, it just stopped responding when I tried to fetch all MC file listings in a query. It now gives a 502. Sorry for that. :-/ Best, Marcel P.S.: I only wanted to retrieve this list once having it cached locally. But the query did not finish even once... <http://forum.world.st/file/n4709948/smalltalkhub-browser.png> -- View this message in context: http://forum.world.st/Smalltalkhub-REST-API-a-k-a-Sorry-if-I-broke-it-tp470… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Pharo Wiki cleanup

by Camillo Bruni

In my attempt to make the contribution process for Pharo a bit simpler I cleaned up the fogbugz wikis which where left a bit unmaintained. There are now 5 important top-level categories: Welcome Page: https://pharo.fogbugz.com/default.asp?W41 Documentation: https://pharo.fogbugz.com/default.asp?W69 Changelog: https://pharo.fogbugz.com/default.asp?W2 Wishlist: https://pharo.fogbugz.com/default.asp?W50 Responsibilities: https://pharo.fogbugz.com/default.asp?W66 I removed old cruft that was documenting long gone features of ancient pharo versions ;). I would be more than happy to get some feedback and improve these websites gradually.

Sept. 24, 2013

New Mars examples: Package Browser and Test Runner

by Carla F. Griggio

Hi everyone! I want to let you know that I've just posted a screencast in my blog about the new Mars Package Browser and Test Runner<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…> . These examples are not really intended as being the definitive package browser or test runner, but to start experiencing how is it to build a real application using Mars and to showcase some widgets. Anyway, it's cool :) The Package browser is not so different to the system browser example I showed before, but the Test Runner is definitely my favorite example so far. I give more details in the screencast<http://www.youtube.com/watch?v=RlBr42uaqxE>and the blog post<http://marsonpharo.wordpress.com/2013/09/24/marspackagebrowser-and-marstest…>. Any feedback is appreciated! Cheers, Carla.

Sept. 24, 2013

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

by btc＠openinworld.com

Sept. 24, 2013

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

by btc＠openinworld.com

Sept. 24, 2013

slow RPackageOrganizer >> packageNamed:

by Camillo Bruni

@Esteban what is the reason we have to do a case-ignored check for looking up a package in #packageNamed:? seems unnecessary slow to me :/, maybe we can add a #packageNamedIgoreCase: ?

Sept. 23, 2013

Re: [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

by Nicolas Cellier

Isn't Eliot just implementing this feature, having a segment of non relocatable objects? 2013/9/23 Igor Stasenko <siguctua(a)gmail.com> > > > > On 23 September 2013 21:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 23 September 2013 16:23, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> Hi Jan, >>> >>> I think I will add the ByteArray accessor to NBExternalAddress today >>> or tomorrow since I need it as well for another project. >>> >>> hmm, reading from memory into bytearray can be done with memory copy: >> >> inputs: address , offset , size to read >> >> newAddress := NBExternalAddress value: address value + offset. >> buffer := ByteArray new: size. >> NativeBoost memCopy: newAddress to: buffer size: size. >> >> same way, writing, just swap the source and destination: >> >> newAddress := NBExternalAddress value: address value + offset. >> buffer "is given from somewhere". >> NativeBoost memCopy: buffer to: newAddress size: size. >> >> but as Jan noted, you cannot tell to write starting at specified offset >> from/to bytearray, e.g.: >> >> copy from: address to: buffer + someOffset >> neither: >> copy from: buffer + someOffset to: someAddress >> >> this where we need to introduce special 'field address' type, so you can >> construct it like this: >> >> offsetAddress := buffer nbAddressAt: offset. >> >> so then you can use it to pass to any function, which expects address, >> like memory copy >> or any foreign function. >> >> Since objects are moving in memory, we cannot calculate address of field >> before hand: >> >> address := NBExternalAddress value: someObject address + offset. >> >> because if GC will happen, after computing such address and its actual >> use, >> you will read/write to wrong location. >> > > ** after computing and *before* actual use ** > > >> Thus we should keep oop + offset up to the point of passing it to >> external function, under >> controllable conditions, that guarantee there's no GC is possible. >> >> >> Things would be much simpler if we could have pinning, isnt? :) > > >> -- >> Best regards, >> Igor Stasenko. >> > > > -- > Best regards, > Igor Stasenko. >

Sept. 23, 2013

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

by Nicolas Cellier

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? 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... >> >> >> > >

Sept. 23, 2013