December 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] NativeBoost and Pharo Kernel
by Pavel Krivanek Dec. 13, 2012

Dec. 13, 2012

Hi, I would like to ask: should NativeBoost be part of the Pharo Kernel? Currently there are some minor issues like that AsmJit-Extension package takes ownership of Integer>>#&, False>>#asBit and so on. Will NativeBoost be more closely integrated with the kernel in the near future? BTW, we need to integrate http://code.google.com/p/pharo/issues/detail?id=7062 before any update that will move methods between packages. Cheers, -- Pavel

5 7

[Pharo-project] I love to see the commit log on OPAL
by StÃ©phane Ducasse Dec. 13, 2012

Dec. 13, 2012

continue this is cool :)

1 0

[Pharo-project] [update 2.0] #20435
by Marcus Denker Dec. 13, 2012

Dec. 13, 2012

20435 ----- Issue 7120: Make Print It deal better with errors in printString http://code.google.com/p/pharo/issues/detail?id=7120 Issue 7099: Integration of NewList in 2.0 (again) http://code.google.com/p/pharo/issues/detail?id=7099 Issue 7024: unify #compile:classified:withStamp:notifying:logSource: http://code.google.com/p/pharo/issues/detail?id=7024 Diff information: http://ss3.gemstone.com/ss/Pharo20/Traits-MarcusDenker.447.diff http://ss3.gemstone.com/ss/Pharo20/Text-MarcusDenker.46.diff http://ss3.gemstone.com/ss/Pharo20/NewList-MarcusDenker.11.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1306.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1267.diff

1 0

Re: [Pharo-project] [squeak-dev] FileSystem (was: About (backwards) Compatibility)
by Igor Stasenko Dec. 13, 2012

Dec. 13, 2012

a little followup.. Please, do not even try to say that FileDirectory and FileSystem is interchangeable :) Colin laid a foundation in a place where was no foundation at all. Yes, in Pharo we did some changes in order to 'make it work', polishing some rough corners, as well as writing tests and documenting the code. Without laying foundation, nobody starts to build houses.. (well, some do.. but they do not stay long). We even teach kids about that: http://en.wikipedia.org/wiki/Three_Little_Pigs -- Best regards, Igor Stasenko.

1 0

[Pharo-project] FileSystem (was: About (backwards) Compatibility)
by Igor Stasenko Dec. 13, 2012

Dec. 13, 2012

On 13 December 2012 03:59, Chris Muller <asqueaker(a)gmail.com> wrote: >>> I have no interest in chopping on the great work being done by >>> you and my other friends in Pharo, but that doesn't mean it is >>> feasible for me to use it in my business. While someone in the Pharo >>> community said FileSystem over FileDirectory is "huge", I see it as an >>> incremental API change, and close to being a matter of preference. >>> >> incremental? >> do you think you can implement a memory-based and/or git-based filesystem or >> 'remotely connected database-based file system' >> by just doing incremental changes to FileDirectory? >> good luck with such 'increments' :) > > Yes, of course those capabilities could be added simply with factoring > work and little disruption to the API. That's the promise object > technology, encapsulation. > The main problem with FileDirectory that there's no API. I can hardly call a single class as API... as to me, it is clear that file system domain is a bit more complex and in order to reflect it properly in a language you will need more that a single role (FileDirectory). So, i really doubt that you end up with 'little disruption to API'. It will be substantial. > Colin made a gorgeous domain model of an abstract FileSystem, no doubt > about it. If we switch to it in Squeak I'm sure I will be happy once > the conversion is done. I just think its worth asking, though, > whether a "core" system should provide that rich a model > out-of-the-box or instead just a bland, one-layer-above-the-primitives > lightweight model ready to be easily wrapped by the user's _own_ rich > model of a FileSystem. Is the core system suitable for tiny embedded > programs and will they want a rich model or a basic one? Maybe Spoon > will allow us to have our cake and eat it too..? > To me, design comes first. ALWAYS. All of the rest is secondary. FileSystem establishing a clear separation between conceptual model and implementation detail. The value of such improvement is hard to underestimate: users can learn fast & grasp well how to use it (and even understand better how file systems work). Moreover, it makes FileSystem nicely portable among dialects.. So, in future, if you would like to port your application to another dialect, you'll have to port FileSystem backend, instead of walking over your whole application and do patches all over the place.. Because once you have sound API, an effort to port application gravitates down to zero. Also, porting, in broad sense can mean 'porting from version X to version Y' (speaking about 'backwards compatimilimulability). API establishing a set of rules in a domain & models. The point is that domain does not changes that often, comparing to implementation. That means , if you have a good design, you can be assured that it won't require serious changes and will serve you much much longer without need to change anything in userland code. (Take a Collection protocols for example). Also, once you have such set of rules, it is much easier for people to maintain implementation code, as well as adding extra functionality if needed. Clearly, VM interfaces (such as primitives) should be not exposed to language 'as is', but always come with API. Because if you don't have rules, then you have very poor maintainability inside of system, as well as forcing users to reinvent their own wheel over and over again.. And next thing, if you would want one day to change primitives or change VM.. you will immediately hit the wall, with bloody 'backwards compatibility' sign on it. Because you will discover, that every single application implements own abstraction layer(s) (or even worse, use low-level functionality directly) on top of what you provided. So, to me, your statement looks contradictory: from one side, you are seriously concerned about backwards compatibility, but from another one, you trying to ignore/discard the facts that you cannot have good backwards compatibility without having a design and API in a first place. -- Best regards, Igor Stasenko.

1 0

[Pharo-project] FileSystem (was: About (backwards) Compatibility)
by Chris Muller Dec. 13, 2012

Dec. 13, 2012

>> I have no interest in chopping on the great work being done by >> you and my other friends in Pharo, but that doesn't mean it is >> feasible for me to use it in my business. While someone in the Pharo >> community said FileSystem over FileDirectory is "huge", I see it as an >> incremental API change, and close to being a matter of preference. >> > incremental? > do you think you can implement a memory-based and/or git-based filesystem or > 'remotely connected database-based file system' > by just doing incremental changes to FileDirectory? > good luck with such 'increments' :) Yes, of course those capabilities could be added simply with factoring work and little disruption to the API. That's the promise object technology, encapsulation. Colin made a gorgeous domain model of an abstract FileSystem, no doubt about it. If we switch to it in Squeak I'm sure I will be happy once the conversion is done. I just think its worth asking, though, whether a "core" system should provide that rich a model out-of-the-box or instead just a bland, one-layer-above-the-primitives lightweight model ready to be easily wrapped by the user's _own_ rich model of a FileSystem. Is the core system suitable for tiny embedded programs and will they want a rich model or a basic one? Maybe Spoon will allow us to have our cake and eat it too..?

1 0

Re: [Pharo-project] Nautilus and grey out text
by dimitris chloupis Dec. 12, 2012

Dec. 12, 2012

ok I understand now thank you all for the clarifications. Very exciting and powerful stuff, the more I learn about pharo and smalltalk the more I love it. ________________________________ From: Esteban Lorenzano <estebanlm(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Wednesday, 12 December 2012, 12:15 Subject: Re: [Pharo-project] Nautilus and grey out text No, just a method added to a class, and categorized with a special name: *NameOfThePackageWhereItBelongs Esteban On Dec 12, 2012, at 11:11 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: Oh I see, very clever, are those methods traits ? > > > > >________________________________ > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> >To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> >Sent: Wednesday, 12 December 2012, 11:48 >Subject: Re: [Pharo-project] Nautilus and grey out text > > >If you have got a package named MyPackage then if some class that is not part of this package has got some methods in categories named like *MyPackage(-Something) (star, package name, optional category) then this methods are bundled together with MyPackage. > > >-- Pavel > > >On Wed, Dec 12, 2012 at 10:38 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > >thanks added to my list of things to study :) >> >> >> >> >>________________________________ >> From: Sven Van Caekenberghe <sven(a)stfx.eu> >> >>To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> >>Sent: Wednesday, 12 December 2012, 11:33 >> >>Subject: Re: [Pharo-project] Nautilus and grey out text >> >> >> >>On 12 Dec 2012, at 10:25, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> >>> Thanks for the reply , by "extension" you mean inheritance ? Package A class subclasses package B class ? >> >>No, it is extension with respect to Monticello/RPackage packaging. >> >>> From: Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> >>> Sent: Wednesday, 12 December 2012, 11:19 >>> Subject: Re: [Pharo-project] Nautilus and grey out text >>> >>> If a package A adds an exteinson to a class from different package B then the extended class from package B is grayed out and all methods that are not part of the package A too. >>> >>> -- Pavel >>> >>> On Wed, Dec 12, 2012 at 10:03 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >>> I went through the Nautilus pdf and it seems to explains most of the thing but the grey out text. Any idea why some classess and methods are grey out ? >>> >>> By the way congratulation to Nautilus author and all people contributing to it , it certainly looksÂ like a big improvement over the classic system browser. >> >>-- >>Sven Van Caekenberghe >>http://stfx.eu >>Smalltalk is the Red Pill >> >> >> >> >> >> > > >

3 4

[Pharo-project] Zinc-REST
by Sven Van Caekenberghe Dec. 12, 2012

Dec. 12, 2012

There were some people asking about Zinc-REST. I took some time to improve the package (by moving some private code into it) and documented it by adding a couple of examples and unit tests. Load the group 'REST' using the latest ConfigurationOfZincHTTPComponents (NeoJSON will be loaded as a dependency). There are two examples: (1) ZnExampleSumRestCall handles REST requests for /sum For a GET request, it accepts numbers as path elements or as a query parameter. GET /sum/1/2/3 GET /sum?numbers=1,2,3 For a POST requests, it accepts a text/plain entity containing numbers. POST /sum '1,2,3' (2) ZnExampleStorageRestServerDelegate offers a REST interface on /storage/objects with CRUD operations on JSON maps. GET /storage/objects list all stored maps as a list of object-uris GET /storage/objects?key1=value1&key2=value2 as above with conjunctive condition specified POST /storage/objects <MAP> store a new map, returns the created object-uri GET /storage/object/<id> return the map stored under id DELETE /storage/object/<id> delete the map stored under id PUT /storage/object/<id> <MAP> overwrite the map stored under id with MAP Both examples are tested by matching unit tests. There is no further independent textual documentation, you'll need to know what REST style interfaces are and know about Zinc HTTP Components. Compared to Seaside-REST this solution is simpler (no Seaside dependency), a bit less declarative (no pragmas), closer to the mechanics of HTTP, not linked to automagic conversions (Magritte). But this is code that I use in production. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

2 1

[Pharo-project] Browsing hierarchy in 2.0
by Nicolas Cellier Dec. 12, 2012

Dec. 12, 2012

How do I browse hierarchy: for example that of Array? I know I can type Array browseHierarchy, select it and doIt, but I mean efficiently... Nicolas

2 2

[Pharo-project] Protecting against stack overflow ?
by Sven Van Caekenberghe Dec. 12, 2012

Dec. 12, 2012

Hi, Would it be possible to build some kind of protection against stack overflow ? This is actually the most common situation for loop/cycle that either results in an unusable image or a crash. Interrupting with CMD-. is not always possible. A possible solution could be to just limit the stack size and throw an exception. For example, in LispWorks, it goes like this: CL-USER 5 > (defun foo () (cons (random 100) (foo))) FOO CL-USER 6 > (foo) Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 7 : 1 > :bq ERROR <- RUNTIME:BAD-ARGS-OR-STACK <- LENGTH <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION Obviously, this is possible, the question is, can it be done easily and without paying an unbearable performance price ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

6 17