- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Serge Stinckwich

2011/12/29 Benoit St-Jean <bstjean(a)yahoo.com>: > I was wondering what is planned regarding packages available on SqueakSource > and Pharo.Â More and more packages can't load in Pharo and it gets more and > more frustrating not being able to load anything without having to > add/modify methods/classes all over the place so those packages can load > properly in Pharo.Â Are we looking at a Pharo-only kind of SqueakSource in > the future ? > > Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every > package is adding more complexity than what is needed.Â I know backward > compatibility was thrown away from the start to avoid compromises in Pharo > but how do we take care of the fact that as each day passes, less and less > stuff from SqueakSource is usable in Pharo ? This is not a direct reply to your concerns, but maybe Pharo should stick to this convention regarding the semantic versioning in the future: http://semver.org/ This implies that a public API should be established clearly and maybe this is not for tomorrow ;-) I wondering if the conformity check to this specification could be automatically done in Pharo. I guess yes because we have access to all the code with MC. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Dec. 30, 2011

Re: [Pharo-project] PharoDBX: CogVM vs. OneClickVM

by Mariano Martinez Peck

On Fri, Dec 30, 2011 at 8:52 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > I tried PharoDBX with the Pharo 1.3 one click > and the provided VM was not able to find the DLLs for > OpenDBX on windows. > > When I used the latest CogVM from Eliot with the same > image it worked. > > Is this already known yes. Pharo one click vm is old and FFI is broken in there. > or did others experience this > as well? > yes > > Thx > T. > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > -- Mariano http://marianopeck.wordpress.com

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Frank Shearar

On 30 December 2011 09:49, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 29 December 2011 15:44, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >>> > I was wondering what is planned regarding packages available on >>> > SqueakSource >>> > and Pharo.Â More and more packages can't load in Pharo and it gets more >>> > and >>> > more frustrating not being able to load anything without having to >>> > add/modify methods/classes all over the place so those packages can load >>> > properly in Pharo.Â Are we looking at a Pharo-only kind of SqueakSource >>> > in >>> > the future ? >>> > >>> > Besides, having to handle platform specific (i.e. Pharo vs Squeak) for >>> > every >>> > package is adding more complexity than what is needed.Â I know backward >>> > compatibility was thrown away from the start to avoid compromises in >>> > Pharo >>> > but how do we take care of the fact that as each day passes, less and >>> > less >>> > stuff from SqueakSource is usable in Pharo ? >>> > >>> The recipe is simple: maintenance. >>> >>> If you really care, spend time maintaining packages you using. >>> If nobody cares to maintain the software, it is dead. >>> It is only a matter of time for it to get broken. >>> We cannot give any guarantee that something which worked fine 10 years >>> ago will keep working today, >>> without keeping everything unchanged. >>> >>> If you have a garden and planted a rose there, do you expect that 5 >>> years later it will still grow there, without you taking care of it? >> >> >> >> Igor, I think he is not criticizing that. What he points out is not the lack >> of maintenance but a clear way of knowing which project/packages are >> expected to work or not in Pharo. If you take a random package/project from >> SS there is no way to know that. Having a Pharo catalog/certified >> packages/projects would help here. >> > > Well, it is just another side of same problem. > If package maintainer wants its package to work without problems with Pharo, > usually, he takes care of everything, from checking if it works with > latest pharo up to > mentioning where and how it can be loaded/used. > And if people don't care about their stuff, it is just rots and dies. > > Any attempts to do that externally (by people who don't maintain own > projects directly) are futile and counterproductive. > Because it is fine, you can spend couple of hours verifying that some > software works ok today, > "certify" it and list it in some "catalogue". But then tomorrow > something will be changed and again package will be broken/stop > working > properly. > So unless you maintaining your software continuously, there's no other > way to guarantee that it works and will keep working in future. > Remember the SqueakMap and Universe? They meant to solve same problem. > But you cannot solve it automatically, > because putting a package into list of certified packages does not > guarantees that if today it works, it will keep working tomorrow. Well, that's _half_ true. If Foo 1.0 loads in Pharo 1.3 today, then it should load in Pharo 1.3 tomorrow, because both "Foo 1.0" and "Pharo 1.3" point to immutable chunks of code. And of course they must be immutable, because otherwise your versioning's useless. Otherwise, sure, to keep Foo 1.1-dev working against Pharo's HEAD requires maintenance, right up until 1.4 enters code freeze. Once 1.4 is released, Foo 1.2 can be released, and you can safely know - because your catalogue (i.e., SqueakMap) tells you so - that Foo 1.2 can load cleanly and work correctly in Pharo 1.4. And so on. frank > I seen numerous complaints about that in Universe, when people were > really annoyed that package is listed in it, but cannot be loaded > and so on. As a result, nobody using Universe today. > > >> Cheers > > > > -- > Best regards, > Igor Stasenko. >

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Igor Stasenko

On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 29 December 2011 15:44, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >> > I was wondering what is planned regarding packages available on >> > SqueakSource >> > and Pharo.Â More and more packages can't load in Pharo and it gets more >> > and >> > more frustrating not being able to load anything without having to >> > add/modify methods/classes all over the place so those packages can load >> > properly in Pharo.Â Are we looking at a Pharo-only kind of SqueakSource >> > in >> > the future ? >> > >> > Besides, having to handle platform specific (i.e. Pharo vs Squeak) for >> > every >> > package is adding more complexity than what is needed.Â I know backward >> > compatibility was thrown away from the start to avoid compromises in >> > Pharo >> > but how do we take care of the fact that as each day passes, less and >> > less >> > stuff from SqueakSource is usable in Pharo ? >> > >> The recipe is simple: maintenance. >> >> If you really care, spend time maintaining packages you using. >> If nobody cares to maintain the software, it is dead. >> It is only a matter of time for it to get broken. >> We cannot give any guarantee that something which worked fine 10 years >> ago will keep working today, >> without keeping everything unchanged. >> >> If you have a garden and planted a rose there, do you expect that 5 >> years later it will still grow there, without you taking care of it? > > > > Igor, I think he is not criticizing that. What he points out is not the lack > of maintenance but a clear way of knowing which project/packages are > expected to work or not in Pharo. If you take a random package/project from > SS there is no way to know that. Having a Pharo catalog/certified > packages/projects would help here. > Well, it is just another side of same problem. If package maintainer wants its package to work without problems with Pharo, usually, he takes care of everything, from checking if it works with latest pharo up to mentioning where and how it can be loaded/used. And if people don't care about their stuff, it is just rots and dies. Any attempts to do that externally (by people who don't maintain own projects directly) are futile and counterproductive. Because it is fine, you can spend couple of hours verifying that some software works ok today, "certify" it and list it in some "catalogue". But then tomorrow something will be changed and again package will be broken/stop working properly. So unless you maintaining your software continuously, there's no other way to guarantee that it works and will keep working in future. Remember the SqueakMap and Universe? They meant to solve same problem. But you cannot solve it automatically, because putting a package into list of certified packages does not guarantees that if today it works, it will keep working tomorrow. I seen numerous complaints about that in Universe, when people were really annoyed that package is listed in it, but cannot be loaded and so on. As a result, nobody using Universe today. > Cheers -- Best regards, Igor Stasenko.

Dec. 30, 2011

Re: [Pharo-project] TWM bug when deleting a snapshot

by laurent laffont

I've looked at this and I'm still not sure how to handle snapshots navigation in an "intuitive" way. Actually how it works (assume an initial state S0): - when you create a new snapshot (TWMWorldRecorder>>snapshot) the new snapshot is on top, this one is OK. Let's call it snapshot S1 - now go back / left arrow (TWMWorldRecorder>>backward) *without moving any window*, easy we go to S0. Go forward, we're at S1. - now move a window and go back. As I don't want to loose the current state, an automatic snapshot (S2) is created so we can go back to current state later. This behavior is not intuitive I think (do two things) but often I forgot to do the snapshot before going backward.... so with this done automatically nothing is lost. (winner-mode in Emacs has this behavior). - go to S3. Then move some windows and delete. If automatically TWM restore last snapshot, we loose current state..... At least, automatic restore on delete is easy: TWMWorldRecorder >>deleteCurrentSnapshot (self snapshots size = 1) not ifTrue: [ self snapshots remove: self currentSnapshot. self currentPosition: self currentPosition - 1. self restoreCurrentSnapshot. "<--- add this line" ] Experimentations still neeeded...... Another idea is to have TWMWorldRecorder plugged to announcements so each time a window move / appear / disappear it creates automatically a snapshot.... Cheers, Laurent On Thu, Dec 29, 2011 at 4:57 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Snapshots are cool! > > But try this: > 1. create two snapshots > 2. navigate to the last one > 3. delete it > > Although it is shown removed from the list (i.e. "1/1"), you are not > automatically navigated back to the first one. You stay on the deleted one, > and when you navigate back to the first with the arrow, the deleted one > reappears in the list (i.e. "1/2") > > Sean > > -- > View this message in context: > http://forum.world.st/TWM-bug-when-deleting-a-snapshot-tp4243197p4243197.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 30, 2011

Re: [Pharo-project] TextLint usage for German text?

by Damien Cassou

Hi, On Fri, Dec 23, 2011 at 4:20 PM, Franz Josef Konrad <franzl(a)fjkonrad.de> wrote: > Has somebody used TextLint to analyze German Text? I don't know of anyone. > I haven't found any hint in this direction. If there is no adaption for > German available, do you think it can be done easily? A lot of rules are for English only (with hardcoded words such as 'however', 'and'...). > I had a short look to the source code and saw that one of the key points of > TextLint is to recognize the type of a word (noun, verb, etc.). This is done > by building a dictionary of words that comes from the English Wiktionary. I'm sure how large is the part of TextLint that relies on word typing. I would say it's not a big one but I can be wrong. > From a first and naive view I would guess this can be done also for German > and the rules could be adopt to German styling rules. Most rules should be rewritten and can not be adapted to German. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 30, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by laurent laffont

Now TWM 1.3 uses KeyMapping 2.1. Laurent On Thu, Dec 29, 2011 at 11:01 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Oh yeah. I always do the same stupid mistake u.u . I have to start using > metacello browser d: > > Thanks! A new configuration with both (recovered) 2.0 and 2.1 versions is > in MetacelloRepository. > > Guille > > > On Wed, Dec 28, 2011 at 9:54 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> >> Sean P. DeNigris wrote >> > >> > In Pharo 1.3, I get "MetacelloProjectSpecLoadError: No version found for >> > '2.0' of ConfigurationOfKeymapping" >> > >> >> It looks like Keymapping's version 2.1 overwrote 2.0. If that's what >> happened, the attached fileout is fixed, but Guillermo can you check it? >> >> http://forum.world.st/file/n4241451/ConfigurationOfKeymapping.st >> ConfigurationOfKeymapping.st >> >> -- >> View this message in context: >> http://forum.world.st/TWM-doesn-t-work-without-keymappins-and-keymappings-d… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >

Dec. 30, 2011

Re: [Pharo-project] PharoDBX: CogVM vs. OneClickVM

by Milan Mimica

Isn't the VM in OneClick package also Cog? On 30 December 2011 08:52, Torsten Bergmann <astares(a)gmx.de> wrote: > I tried PharoDBX with the Pharo 1.3 one click > and the provided VM was not able to find the DLLs for > OpenDBX on windows. > > When I used the latest CogVM from Eliot with the same > image it worked. > > Is this already known or did others experience this > as well? > > Thx > T. > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > -- Milan Mimica http://sparklet.sf.net

Dec. 30, 2011

Re: [Pharo-project] Classes referenced in code string

by Lukas Renggli

This is the rest of the code: ast := RBParser parseExpression: 'Object new. String new'. ast annotateInClass: UndefinedObject. (ast allChildren select: [ :each | each isVariable and: [ each variableBinding isLiteralBinding ] ]) collect: [ :each | each variableBinding binding value ] --> an OrderedCollection(Object String) #variableBinding returns the object knowing all details about the variables. It is only available after you annotated the AST with #annotateInClass:. Lukas On 30 December 2011 08:56, Lukas Renggli <renggli(a)gmail.com> wrote: > On 30 December 2011 01:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Lukas Renggli wrote >>> >>> Can be easily done with RB: You parse it (RBParser parseExpression: >>> aString) and do a semantic analysis (see the tests in AST-Tests-Semantics >>> for examples). >>> >> >> Thanks, Lukas! How did I know that you would answer ;-) >> >> I got that far, but couldn't figure out what to pass to annotateInClass:. >> Not calling it, or passing nil both lead to errors. > > Yes, you need to call it. It tells the AST in what context (to what > class "self" should refer to) it is used. For a workspace expression > where "self" refers to "nil" you have to pass in "UndefinedObject". > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch

Dec. 30, 2011

Re: [Pharo-project] Classes referenced in code string

by Lukas Renggli

On 30 December 2011 01:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Lukas Renggli wrote >> >> Can be easily done with RB: You parse it (RBParser parseExpression: >> aString) and do a semantic analysis (see the tests in AST-Tests-Semantics >> for examples). >> > > Thanks, Lukas! How did I know that you would answer ;-) > > I got that far, but couldn't figure out what to pass to annotateInClass:. > Not calling it, or passing nil both lead to errors. Yes, you need to call it. It tells the AST in what context (to what class "self" should refer to) it is used. For a workspace expression where "self" refers to "nil" you have to pass in "UndefinedObject". Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 30, 2011