- Pharo-dev - lists.pharo.org

Re: [Pharo-project] another kid born: NBExternalEnumerationType

by Ciprian Teodorov

On Wed, Dec 12, 2012 at 7:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ciprian > > this is really cool to see how pushing and enhancing NativeBoost. > Really a cool nd warm feeling. > Tx for your energy and time. Thanks Stef... Stef > > On Dec 11, 2012, at 8:33 PM, Ciprian Teodorov wrote: > > > Hi guys, > > > > today I have commited to the NativeBoost repository a new core class, > the NBExternalEnumerationType, > > which reifies the enum declarations in C and offers a nice interface > (especially in terms of debug/inspect). > > > > To use it just subclass the NBExternalEnumeration and add an #enumDecl > method to the class side such as: > > > > Did you add this cool class comment :) > done ;) > > > NBExternalEnumeration subclass: #NBTestEnumeration > > instanceVariableNames: '' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'NativeBoost-Tests' > > > > NBTestEnumeration class>>enumDecl > > ^ {(#AAA -> 1). > > (#BBB -> 2). > > (#CCC -> 3). > > (#DDD -> 2400)} asDictionary > > > > DO NOT FORGET to call the #initialize method on your class. The rest is > automatically done ;) > > > > You can use your new enum in two ways: > > â¢ add it to a client class poolDictionaries list (see > #NBExternalEnumTests for an example), and then just write CCC in your code > -- CCC here is an item of your enum > > â¢ or you can send the name of an item to your class --- > NBTestEnumeration DDD > > The NBExternalEnumeration implements (instance and class) some more API > methods like: > > â¢ #itemAt: retrieves the item having a specific value --- > NBTestEnumeration itemAt: 2 > > â¢ #includes: checks the existence of a specific item in the enum > --- NBTestEnumeration includes: #AAA > > Having this already gives us a nice interface to working with enums. Now > I plan to improve a little bit on performance and usage scenarios: > > â¢ the possibility to accept smalltalk integers as valid > input/output for functions(or callbacks) that use enums as arguments/return. > > â¢ support the different representation types for the enum values > (int/uint) > > So that will be for now. Feel free to try it out and send me any > comments and/or improvement ideas, It will be my pleasure to improve it. > > Cheers, > > -- > > Dr. Ciprian TEODOROV > > IngÃ©nieur DÃ©veloppement CAO > > > > tÃ©l : 06 08 54 73 48 > > mail : ciprian.teodorov(a)gmail.com > > www.teodorov.ro > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 12, 2012

[Pharo-project] How to load Phoseydon and Neptuno?

by Stan Shepherd

Hi all, is there a working snippet to load these two? I've tried combinations from previous threads without success so far. Thanks, ...Stan -- View this message in context: http://forum.world.st/How-to-load-Phoseydon-and-Neptuno-tp4659102.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Chris Muller

Hi Stef, I think Pharo is really neat. I have nothing against it except for the "we are cool, you are not" attitude which I perceive at times. 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. > Now just out of curiosity do you use Pharo ;D I do not use Pharo anymore. I tried for a while but the IDE was difficult for me to work in and there was no reward for constant patching of my packages just to stay working. I saw how decisions which can have significant repercussions on low-level parts of the code-base are made with such little debate. I have business to run myself, this approach is untenable for me. Squeak's philosophy fits me just right. I will be watching Pharo with great interest. If it settles down someday, and I need to start up a brand new Smalltalk project which has no need for Magma or Maui, I will give Pharo another look. This thread is about the old debate about backward-compatibility, my position should not be surprising. On Wed, Dec 12, 2012 at 12:22 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Come on, chris. Are you getting nervous, tired, bored? Because we are cool and positive thinking :). > We are not reinventing the past, believe me - I never saw a objectecentric debugger, a bootstrapped kernel > and a lot moreâ¦.:) > > May be you did not read my FAST Pharo presentation or the ESUG one but we want to get > more business around Pharo and we are doing it. > > In addition we are creating a real company (and probably another in the future) and we are really aware about what is to really getting work done. > You know Moose is probably one of the most complex Pharo application around. > Now we do not want to live in a place where each time we open a browser on something we cry. > Why because at the end it will kill us. If we cannot innovate and go fast with Smalltalk then better > code in Java or Javascript. > > This is why we removed FileDirectory (note that camillo nicely proposed a compat package), systemEventNotifierâ¦. > > Esteban could port Pier and Seaside to Pharo 1.4 in a couple of hours. > We have pier running in 2.0. > > Now just out of curiosity do you use Pharo ;D > > Stef > > > >> If my goal is to make my computer work for ME, then I want my >> development system to maximize my leverage and minimize my effort. >> Breaking compatibility for cleaner code subverts this, as Hannes said, >> >>>> Constant input in maintenance effort is needed. >> >> I want to use my time applying Smalltalk to real-world problems, not >> API changes. >> >> A blue-plane innovation is worth breaking backward compatibility, >> reinventing the past isn't. >> >> >>>> maintaining libraries and maybe compatibility layers are very welcome. >>>> >>> Yes, and how did we ever thought we could invent the future with Squeak >>> when in reality, we could not even change a typo in a comment? >>> >>> Marcus >>> >>> >>> >>> >> >

Dec. 12, 2012

Re: [Pharo-project] Nautilus and grey out text

by Sven Van Caekenberghe

On 12 Dec 2012, at 15:32, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: > On 12 dec 2012, at 11:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 12 Dec 2012, at 11:20, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> >>> 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. >> >> Yes, Dimitris, that is the idea. But you have been warned: once you get infected it is hard to go back ;-) > > That was the understatement of the year: I went from using Smalltalk in my daily job for 15 years, to Java. Two years later and not a day goes by that I don't wish I could have carried on using Smalltalk! > > How long does it take for the infection to be cured, anyone know? If you have been programming Smalltalk for that long you are effectively incurable, infected for life, sorry to be so bold. At least you should spent all your free time doing Smalltalk, better would be to find another job or start a company to do Smalltalk. ;-) > -- > Cheers, > Peter. > >> One other thing: there is a Pharo-Users mailing list as well, it has less traffic, but the idea is that conversations like the one in this thread (how do I do this or that ? what does this or that mean ?) are better held there. >> >> http://www.pharo-project.org/community >> >> Keep on asking questions ! >> >>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> >

Dec. 12, 2012

Re: [Pharo-project] Zinc-REST

by StÃ©phane Ducasse

Thanks a lot sven :) On Dec 12, 2012, at 9:23 PM, Sven Van Caekenberghe wrote: > 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 > >

Dec. 12, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Eliot Miranda

On Tue, Dec 11, 2012 at 8:58 AM, adrians <nmanole(a)gmail.com> wrote: > > > Of course not all of what needs to be done in Pharo should be of at same > priority. It makes sense to first fix the tools one uses for fixing > everything else, so that one can speed up one's own work and at the same > time open up the possibility for others (less skilled) to help out. > > In any case I'm sorry if it seems that I'm demanding you or anyone else > should make this a higher priority. The thinking was that maybe there is > someone (Stephane D?) who, to some degree, can prioritize certain things > over others and if so, wouldn't it make sense to fix the most basic tool > that is used to help fix everything else? > > Who knows though, maybe the debugger is not often used by the experts. > On the contrary. Many experts program in the debugger (one defines a method when one gets a doesNotUnderstand:). Many experts use the debugger to explore code (running code is a powerful aid to understanding). Some experts use the simulation machinery that underlies the debugger to do things like partial evaluation for type analysis etc. > -- Adrian > > > > -- > View this message in context: > http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- best, Eliot

Dec. 12, 2012

[Pharo-project] Zinc-REST

by Sven Van Caekenberghe

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

Dec. 12, 2012

[Pharo-project] Zinc-Resource-Meta-[Core|Tests]

by Sven Van Caekenberghe

Just a quick note: the first version of Zinc-Resource-Meta-[Core|Tests] containing ZnUrl and ZnMimeType independent of / separate from / as a dependency for Zinc-HTTP is now available. ConfigurationOfZincHTTPComponents version 2.0 reflects this change (#stable for Pharo 2.x). -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 12, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

by Marten Feldtmann

On 12.12.2012 17:18, Esteban Lorenzano wrote: > IMO, that's non-sense. Well, that is a matter of view. I've done this also with Lua and VASmalltalk and I did this not because of other Smalltalkers in mind using my software, but perhaps of potential end users willing to enhance the application in a more known language. Because of this I also tried to use Rexx as an extension language, which is in my view even more suitable to be used as an embedded language - but the market decided to use Lua and not Rexx. Marten

Dec. 12, 2012

Re: [Pharo-project] About (backwards) Compatibility

by StÃ©phane Ducasse

Come on, chris. Are you getting nervous, tired, bored? Because we are cool and positive thinking :). We are not reinventing the past, believe me - I never saw a objectecentric debugger, a bootstrapped kernel and a lot moreâ¦.:) May be you did not read my FAST Pharo presentation or the ESUG one but we want to get more business around Pharo and we are doing it. In addition we are creating a real company (and probably another in the future) and we are really aware about what is to really getting work done. You know Moose is probably one of the most complex Pharo application around. Now we do not want to live in a place where each time we open a browser on something we cry. Why because at the end it will kill us. If we cannot innovate and go fast with Smalltalk then better code in Java or Javascript. This is why we removed FileDirectory (note that camillo nicely proposed a compat package), systemEventNotifierâ¦. Esteban could port Pier and Seaside to Pharo 1.4 in a couple of hours. We have pier running in 2.0. Now just out of curiosity do you use Pharo ;D Stef > If my goal is to make my computer work for ME, then I want my > development system to maximize my leverage and minimize my effort. > Breaking compatibility for cleaner code subverts this, as Hannes said, > >>> Constant input in maintenance effort is needed. > > I want to use my time applying Smalltalk to real-world problems, not > API changes. > > A blue-plane innovation is worth breaking backward compatibility, > reinventing the past isn't. > > >>> maintaining libraries and maybe compatibility layers are very welcome. >>> >> Yes, and how did we ever thought we could invent the future with Squeak >> when in reality, we could not even change a typo in a comment? >> >> Marcus >> >> >> >> >

Dec. 12, 2012