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

Re: [Pharo-project] how to use "Shared smalltalk workspaces"?

by Sven Van Caekenberghe

On 14 Mar 2013, at 13:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Sven, > > I was checking http://ws.stfx.eu/ to use it as a replacement for pastebin, but I would like to just paste a chunk of code into a webbrowser instead installing the shared workspace into my image. > Is there a way to do that? > > Esteban Well, see the very last expression at the bottom: http://ws.stfx.eu/1WS4U ---- ZnClient new systemPolicy; beOneShot; url: 'http://ws.stfx.eu'; contents: Clipboard clipboardText asString; post. "Don't forget to inspect this last expression to see the new key" --- It is basically just an HTTP POST. You could even do it with curl. There is no web interface to do this though. I'll think about it. Sven PS: the code might have some bit rot in it since I didn't look at it for a long time. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 14, 2013

[Pharo-project] how to use "Shared smalltalk workspaces"?

by Esteban Lorenzano

Hi Sven, I was checking http://ws.stfx.eu/ to use it as a replacement for pastebin, but I would like to just paste a chunk of code into a webbrowser instead installing the shared workspace into my image. Is there a way to do that? Esteban

March 14, 2013

Re: [Pharo-project] rpackage transition

by Marcus Denker

Can we please first release 2.0 before we waste all our energy in useless discussions? On Mar 14, 2013, at 1:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 March 2013 11:25, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi Igor, >> >> Please, let's keep the discussion at the level of arguments. >> > > sorry.. we had conversations about that multiple times with Stef and Marcus. > And it was sounded like we came to some consensus. > But your statements actually an invitation to restart from where we come from.. > >> The original reasons for developing RPackage were: >> - to offer a first class package object in the image and to remove the >> category-string-based-solution, and >> - to get rid of Monticello-magic-mapping, and potentially offer the option >> of adding tags as an orthogonal mechanism. >> >> At this moment, we have RPackage mapped one-to-one to categories, but the >> core implementation still relies on categories. So, at the very least, we >> should find a way to remove categories and directly rely on RPackage. >> > > yes. > I was not part of development of RPackage.. and i still don't understand why > it is so hard to make it map 1:1 to MC package instead of 1:1 to category. > > Category is nothing.. it is thin air.. it is the arbitrary name chosen > by developer > which he can change at any moment. > It does not influencing anything at all (except from sorting the lists > in browser).. > > A very simple rule: when you defining new class or recategorizing it, > it will be added to package which name matching the category name (or > first parts of it).. > Does that sounds like technically impossible to implement? > > newclassCategory := 'Foo-Bugz' > packageToAddTo := packages detect:[:ea | newclassCategory beginsWith: ea name ] > ? > > I simply cannot find a good justification, why instead of doing small > change in single place, > we want to force numerous people do a lot of changes over whole world > of packages. > It doesn't sounds like a smart move. > Especially if there would be clear benefit.. But there's not. At least > i don't see one. > >> The Monticello mapping is there only for historical reasons. To eliminate it >> we need a strategy. For this, I see two options: >> - either we go with simply removing categories altogether and just relying >> on RPackages with 1-to-1 mappings to Monticello packages, >> - we introduce another mechanism (such as tags) that allows us to map >> categories on this. >> > yes this was added.. so we need last bit - make tags play role of categories. > and make MC directly interact with RPackage for loading/snapshotting stuff. > > but since we cannot make everything at once, i hope gradually we will > come there. > >> Perhaps there are other options, too. >> >> Btw, I thought that in Pharo, backward compatibility is secondary to sound >> engineering :). >> > > From machine's perspective , a package is just a collection of > objects. Machine don't needs any naming > there in order to make it run. Names are meaningful only to humans. > So, categories/tags is extra metainformation which should be kept by > package to make sure humans can understand it. > Because if going to extreme, if you strip all names away, then you > turning a package into unsorted set of objects, without any means to > distinguish one from another by developers.. > > Does that sounds like 'sound engineering'? > :) > > >> Cheers, >> Doru >> > > > -- > Best regards, > Igor Stasenko. >

March 14, 2013

Re: [Pharo-project] rpackage transition

by Igor Stasenko

On 14 March 2013 11:25, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > Please, let's keep the discussion at the level of arguments. > sorry.. we had conversations about that multiple times with Stef and Marcus. And it was sounded like we came to some consensus. But your statements actually an invitation to restart from where we come from.. > The original reasons for developing RPackage were: > - to offer a first class package object in the image and to remove the > category-string-based-solution, and > - to get rid of Monticello-magic-mapping, and potentially offer the option > of adding tags as an orthogonal mechanism. > > At this moment, we have RPackage mapped one-to-one to categories, but the > core implementation still relies on categories. So, at the very least, we > should find a way to remove categories and directly rely on RPackage. > yes. I was not part of development of RPackage.. and i still don't understand why it is so hard to make it map 1:1 to MC package instead of 1:1 to category. Category is nothing.. it is thin air.. it is the arbitrary name chosen by developer which he can change at any moment. It does not influencing anything at all (except from sorting the lists in browser).. A very simple rule: when you defining new class or recategorizing it, it will be added to package which name matching the category name (or first parts of it).. Does that sounds like technically impossible to implement? newclassCategory := 'Foo-Bugz' packageToAddTo := packages detect:[:ea | newclassCategory beginsWith: ea name ] ? I simply cannot find a good justification, why instead of doing small change in single place, we want to force numerous people do a lot of changes over whole world of packages. It doesn't sounds like a smart move. Especially if there would be clear benefit.. But there's not. At least i don't see one. > The Monticello mapping is there only for historical reasons. To eliminate it > we need a strategy. For this, I see two options: > - either we go with simply removing categories altogether and just relying > on RPackages with 1-to-1 mappings to Monticello packages, > - we introduce another mechanism (such as tags) that allows us to map > categories on this. > yes this was added.. so we need last bit - make tags play role of categories. and make MC directly interact with RPackage for loading/snapshotting stuff. but since we cannot make everything at once, i hope gradually we will come there. > Perhaps there are other options, too. > > Btw, I thought that in Pharo, backward compatibility is secondary to sound > engineering :). > >From machine's perspective , a package is just a collection of objects. Machine don't needs any naming there in order to make it run. Names are meaningful only to humans. So, categories/tags is extra metainformation which should be kept by package to make sure humans can understand it. Because if going to extreme, if you strip all names away, then you turning a package into unsorted set of objects, without any means to distinguish one from another by developers.. Does that sounds like 'sound engineering'? :) > Cheers, > Doru > -- Best regards, Igor Stasenko.

March 14, 2013

Re: [Pharo-project] Pharo on the command line

by Camillo Bruni

On 2013-03-14, at 12:54, Damir Majer <damir(a)majcon.de> wrote: > Hi NG, > > IÂ´m searching for an Pharo command line execution (like REPL). > IÂ´ve heard about coral. > > Is this still the option to go or is another Tool available in Pharo 2.0? You can have a look at the readline implmentation, AFAIK i added a simple REPL for it: http://smalltalkhub.com/#!/~dh83/readline otherwise I think coral should work under 2.0

March 14, 2013

[Pharo-project] Pharo on the command line

by Damir Majer

Hi NG, IÂ´m searching for an Pharo command line execution (like REPL). IÂ´ve heard about coral. Is this still the option to go or is another Tool available in Pharo 2.0? Cheers, Damir ----- -- Damir Majer ... be agile: www.majcon.de -- View this message in context: http://forum.world.st/Pharo-on-the-command-line-tp4676717.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 14, 2013

Re: [Pharo-project] rpackage transition

by Camille Teruel

On 14 mars 2013, at 11:25, Tudor Girba wrote: > - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, > - we introduce another mechanism (such as tags) that allows us to map categories on this. At some point last year the plan was to do both. Ensure a 1-to-1 mapping between RPackage and MCPackages and a 1-to-1 mapping between RPackage tags and categories. Then we remove categories (and mcpackages, although it is hard to force monticello to rely on rpackage in a backward compatible way).

March 14, 2013

Re: [Pharo-project] rpackage transition

by Tudor Girba

Hi Igor, Please, let's keep the discussion at the level of arguments. The original reasons for developing RPackage were: - to offer a first class package object in the image and to remove the category-string-based-solution, and - to get rid of Monticello-magic-mapping, and potentially offer the option of adding tags as an orthogonal mechanism. At this moment, we have RPackage mapped one-to-one to categories, but the core implementation still relies on categories. So, at the very least, we should find a way to remove categories and directly rely on RPackage. The Monticello mapping is there only for historical reasons. To eliminate it we need a strategy. For this, I see two options: - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this. Perhaps there are other options, too. Btw, I thought that in Pharo, backward compatibility is secondary to sound engineering :). Cheers, Doru On Thu, Mar 14, 2013 at 8:26 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 March 2013 08:00, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > > When we started with RPackage there was a debate as to the strategy > regarding the mapping. I advocated 1-to-1 mapping of categories to > RPackage, and it seems this is what we now have. > > > > The detailed plan looked as follow: > > > > --- > > Stage 1: Get RPackage in the image and pretend that it acts like a smart > cache for categories. Everything is expressed in terms of categories and > mirrored in RPackages. Tools can now be built on top of RPackage. At this > stage, no modification is needed and the new tools will work next to the > old ones. > > > > Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 > Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely > on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people > to start changing the configurations. > > > > .. and rewriting a working code. > Why i cannot have 1 package with 2 categories 'Foo-Core' and > 'Foo-Core-Bar'? > > Why we need such requirement? why developer cannot choose what > categories going into package? > Now i will be forced to fold all classes back into single category if > i want to not end up with 20 little packages > (which cannot be loaded, btw , because of dependency ..) > > To reflect, how bad it sounds to me, let me propose different publishing > order: > - all classes with same first two letters in name should go to same > package. > > Do you like it? No? Not matters.. we will force you to obey to it, > starting from tomorrow. > > > > Stage 3: Change the Monticello loading to only allow 1-to-1 > RPackage-to-MonticelloPackage. At this point, we can safely remove the > Categories. > > --- > > > > Now we passed Stage 1 which is great. At this point, everyone can work > like before, but are encouraged to create explicit Monticello packages out > of categories. Next, I would like to propose that for Pharo 3.0 we go for > Stage 2 and modify slightly Monticello publishing. > > > > Cheers, > > Doru > > > > -- > > www.tudorgirba.com > > > > "Quality cannot be an afterthought." > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- www.tudorgirba.com "Every thing has its own flow"

March 14, 2013

[Pharo-project] Pharo Download Page needs update

by Stefan Marr

Hi: Was just trying to download the latest image via [1]. However, the linked latest.zip does not contain the new .sources file. And it looks like it hasn't been part of the zip. So, would be good if the download page could link to it. Meanwhile, I took it from the all-in-one. Thanks Stefan [1] http://www.pharo-project.org/pharo-download/beta-2-0 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 14, 2013

Re: [Pharo-project] Fwd: Pharo and scaled decimals

by Marcus Denker

On Mar 14, 2013, at 9:48 AM, jannik laval <jannik.laval(a)gmail.com> wrote: > Hi, > Should we already use the new tracker ? > I don't know. But I don't want to do it twiceâ¦. > Is it possible to update the page: http://www.pharo-project.org/community/issue-tracking > It redirect to the google code issue tracker. > > Jannik > > 2013/3/14 Marcus Denker <marcus.denker(a)inria.fr> > I added this as issue 10016 to the new tracker. > > Begin forwarded message: > >> From: David Gorisek <david.gorisek(a)e-racuni.com> >> Subject: Re: Pharo and scaled decimals >>> >>> Hello all, >>> >>> I am testing Pharo and I have noticed that the Pharo compiler does not treat ScaledDecimals the same way they are treated in other Smalltalk dialects (e.g. VW, VAST, Dolphin, STX, etc.). >>> >>> For example the following is a valid code representing an instance of ScaledDecimal/FixedPoint in all other dialect. >>> >>> 1.0s + 2.0s >>> >>> In Phare the code above wont compile, it has to be written as: >>> >>> 1.0s1 + 2.0s1 >>> >>> So I have made the following quick change to make Pharo compatible with other Smalltalk dialects. Maybe this change could be included in the next version of Pharo? >>> >>> SqNumberParser>>#readScale >>> "read the scale if any (stored in instVar). >>> Answer true if found, answer false if none. >>> If scale letter is not followed by a digit, this is not considered as an error. >>> Scales are always read in base 10, though i do not see why..." >>> >>> scale := 0. >>> sourceStream atEnd >>> ifTrue: [ ^ false ]. >>> (sourceStream peekFor: $s) >>> ifFalse: [ ^ false ]. >>> scale := self nextUnsignedIntegerOrNilBase: 10. >>> scale >>> ifNil: [ >>> scale := 0. >>> (sourceStream peek ifNil: [false] ifNotNil: [ :nextChar | nextChar isLetter]) >>> ifTrue: [ >>> sourceStream skip: -1. "ungobble the s" >>> ^ false ] >>> ifFalse: [ ^ true ] ]. >>> ^ true >>> >>> >>> >>> >> >> > > > > > -- > ~~Dr. Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu >

March 14, 2013