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

Re: [Pharo-project] Future "Modules system"

by Denis Kudriashov

2013/2/3 Frank Shearar <frank.shearar(a)gmail.com> > On 3 February 2013 15:42, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2013/2/3 Frank Shearar <frank.shearar(a)gmail.com> > >> > >> >> For java example libA.jar uses SharedClass.methodA and libB.jar uses > >> >> SharedClass.methodB. But #methodA exists only in version deployed as > >> >> libS-a.jar. And #methodB exists only in version deployed as > libS-b.jar. > >> >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are > >> >> defined explicitly in their classpathes. So libA.jar knows nothing > >> >> about > >> >> libS-b.jar and v.v. And that's why your java programm can works at > same > >> >> time with libA.jar and libB.jar. They will use different versions of > >> >> same > >> >> class. > >> > >> No they won't, unless you have separate class loaders. What will > >> happen is you will get one version of a class or another. > > > > > > Of course to get my java example working you should load classes from > libA > > and libB by separated class loaders. > > In pharo there is no way to make it work. And this is what I want to > discuss > > here. > > But it's complicated and fragile to have separate classloaders, and a > nightmare to debug. The Java people actively avoid this, for instance > in JBoss installations. > If your program interracts with multiple external systems by their provided libraries you can't avoid such dependencies problem. So in some level of your application you should work with class loaders. Maybe your "environment framework" hides it. > > Take a look at Colin Putney's Environments work in Squeak 4.5. It > provides a, well, environment in which you can load classes such that > you can avoid the name clash problem. _Right now_ that's all it does, > but it'll likely do more in the future. > I know about Colin Putney's Environments. And I like it very much. But initially his work solves competelly ortogonal problem. Interesting how it can be reused to load separated versions of same package. But as I know Environments not supports selector namespaces which I think required to totally support what I proposed: loading any version of project with no influence on rest system behaviour. > > Gilad Bracha et al's work in Newspeak is the real way to go, I reckon. > (Environments could be a first step in that direction.) Newspeak uses > fully parameterised modules, which are first class entities. In fact > they really are (stateless) classes. However, Newspeak supports inner > classes. > As Environment's what they call modules is completelly ortogonal to my requirement. > > >> frank > >> > >> >> What it means in context of pharo? > >> >> > >> >> In pharo we have configurations which manage dependencies of > projects. > >> >> But > >> >> you can't use at same time projectA and projectB which depend on > >> >> different > >> >> versions of projectS (when they both use same SharedClass from > projectS > >> >> like in java example). If you load projectA last you will get > >> >> SharedClass > >> >> with only methodA. If you load projectB last you will get SharedClass > >> >> with > >> >> only methodB. So projectA and projectB can't works correctly at same > >> >> time. > >> >> My example very simple. It includes just single class differencies. > It > >> >> can > >> >> be more complicated and java world is good example for this. > >> >> > >> >> So my global question is how it can be solved in pharo? Do you have > >> >> some > >> >> plan for this? > >> >> > >> >> I can't remember something similar in pharo vision docs. But maybe > what > >> >> Stephane called "modules system" is exactly about this? I mean what > >> >> Stephane always opposes in namespaces/environment discussions. And I > >> >> think > >> >> that this problem is ortogonal to namespaces/environments support. Do > >> >> you > >> >> agree? Do you know about such reseach in smalltalk? > >> >> > >> >> Little conclusion about such module system (if we can named it such > >> >> way?) > >> >> and what it is required from pharo: > >> >> > >> >> - ability to get in image different versions of same package. > >> >> - separated class (global) dictionaries (multiple Smalltalk's) per > >> >> package > >> >> version. Maybe it can be named Module. So let's think about Module as > >> >> unique Package+Version pair which contains all globals specific to > this > >> >> version and all dependent other Modules. > >> >> - each Module knows it dependencies from other Modules, This > >> >> information > >> >> can be retreived from configuration. > >> >> - each method and class should know from which project version > (module) > >> >> it > >> >> was loaded. > >> >> - inside any methods compiler should resolve class names based on > >> >> Module > >> >> dependencies information. Compiler should lookup actual class objects > >> >> from > >> >> module dependencies hierarchy. So no global Smalltak for compiler. > But > >> >> Smalltalk can be stay in system as default core Module. > >> >> - If you want to use class which presents in two loaded versions of > >> >> same > >> >> package you should resolve conflict manually. Such action should add > >> >> dependency to Module of your code. > >> >> - Module can't have dependencies of two Modules of same package. It > >> >> means > >> >> that code of your project can use only version of some dependant > class. > >> >> I > >> >> think it is essential restriction of Modules system. > >> >> > >> >> Main thing which Module system can get to us is ability to safelly > load > >> >> any > >> >> versions of our projects and use it. It is not matter how old this > >> >> code. > >> >> System just loads old version of pharo core for example. Existed > pharo > >> >> core > >> >> will continue works correctly. > >> >> > >> >> So what you think about it? > >> >> > >> >> Best regards, > >> >> Denis > >> > > >> > > >> > > > >

Feb. 3, 2013

Re: [Pharo-project] Future "Modules system"

by Miguel Moquillon

And the Java people are preparing to throw away the classloaders mechanism with Jigsaw that will be in Java 9. (The classloading is a brittle and error-prone mechanism.) The aim of jigswa is to design and implement a new module system for the Java SE platform and to apply that sysÂtem to the platÂform itÂself and to the JDK (more information in the project homepage http://openjdk.java.net/projects/jigsaw/) Miguel Le 03/02/2013 18:03, Frank Shearar a Ã©crit : > On 3 February 2013 15:42, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> 2013/2/3 Frank Shearar <frank.shearar(a)gmail.com> >>>>> For java example libA.jar uses SharedClass.methodA and libB.jar uses >>>>> SharedClass.methodB. But #methodA exists only in version deployed as >>>>> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. >>>>> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are >>>>> defined explicitly in their classpathes. So libA.jar knows nothing >>>>> about >>>>> libS-b.jar and v.v. And that's why your java programm can works at same >>>>> time with libA.jar and libB.jar. They will use different versions of >>>>> same >>>>> class. >>> No they won't, unless you have separate class loaders. What will >>> happen is you will get one version of a class or another. >> >> Of course to get my java example working you should load classes from libA >> and libB by separated class loaders. >> In pharo there is no way to make it work. And this is what I want to discuss >> here. > But it's complicated and fragile to have separate classloaders, and a > nightmare to debug. The Java people actively avoid this, for instance > in JBoss installations. > > Take a look at Colin Putney's Environments work in Squeak 4.5. It > provides a, well, environment in which you can load classes such that > you can avoid the name clash problem. _Right now_ that's all it does, > but it'll likely do more in the future. > > Gilad Bracha et al's work in Newspeak is the real way to go, I reckon. > (Environments could be a first step in that direction.) Newspeak uses > fully parameterised modules, which are first class entities. In fact > they really are (stateless) classes. However, Newspeak supports inner > classes. > >>> frank >>> >>>>> What it means in context of pharo? >>>>> >>>>> In pharo we have configurations which manage dependencies of projects. >>>>> But >>>>> you can't use at same time projectA and projectB which depend on >>>>> different >>>>> versions of projectS (when they both use same SharedClass from projectS >>>>> like in java example). If you load projectA last you will get >>>>> SharedClass >>>>> with only methodA. If you load projectB last you will get SharedClass >>>>> with >>>>> only methodB. So projectA and projectB can't works correctly at same >>>>> time. >>>>> My example very simple. It includes just single class differencies. It >>>>> can >>>>> be more complicated and java world is good example for this. >>>>> >>>>> So my global question is how it can be solved in pharo? Do you have >>>>> some >>>>> plan for this? >>>>> >>>>> I can't remember something similar in pharo vision docs. But maybe what >>>>> Stephane called "modules system" is exactly about this? I mean what >>>>> Stephane always opposes in namespaces/environment discussions. And I >>>>> think >>>>> that this problem is ortogonal to namespaces/environments support. Do >>>>> you >>>>> agree? Do you know about such reseach in smalltalk? >>>>> >>>>> Little conclusion about such module system (if we can named it such >>>>> way?) >>>>> and what it is required from pharo: >>>>> >>>>> - ability to get in image different versions of same package. >>>>> - separated class (global) dictionaries (multiple Smalltalk's) per >>>>> package >>>>> version. Maybe it can be named Module. So let's think about Module as >>>>> unique Package+Version pair which contains all globals specific to this >>>>> version and all dependent other Modules. >>>>> - each Module knows it dependencies from other Modules, This >>>>> information >>>>> can be retreived from configuration. >>>>> - each method and class should know from which project version (module) >>>>> it >>>>> was loaded. >>>>> - inside any methods compiler should resolve class names based on >>>>> Module >>>>> dependencies information. Compiler should lookup actual class objects >>>>> from >>>>> module dependencies hierarchy. So no global Smalltak for compiler. But >>>>> Smalltalk can be stay in system as default core Module. >>>>> - If you want to use class which presents in two loaded versions of >>>>> same >>>>> package you should resolve conflict manually. Such action should add >>>>> dependency to Module of your code. >>>>> - Module can't have dependencies of two Modules of same package. It >>>>> means >>>>> that code of your project can use only version of some dependant class. >>>>> I >>>>> think it is essential restriction of Modules system. >>>>> >>>>> Main thing which Module system can get to us is ability to safelly load >>>>> any >>>>> versions of our projects and use it. It is not matter how old this >>>>> code. >>>>> System just loads old version of pharo core for example. Existed pharo >>>>> core >>>>> will continue works correctly. >>>>> >>>>> So what you think about it? >>>>> >>>>> Best regards, >>>>> Denis >>>> --

Feb. 3, 2013

Re: [Pharo-project] Object macpal protocol

by Ben Coman

Camillo Bruni wrote: > can anyone explain? :D > > > perhaps http://old.sigchi.org/bulletin/1998.2/spohrer.html#HDR6

Feb. 3, 2013

Re: [Pharo-project] preparing Pharo spring of friday

by Sean P. DeNigris

StÃ©phane Ducasse wrote > Friday we have a sprint and we should organize a bit before so I would > like to know who outside rmod plan to come? I'd like to play again remotely... don't forget me this time ;-) -- View this message in context: http://forum.world.st/preparing-Pharo-spring-of-friday-tp4667276p4667342.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 3, 2013

Re: [Pharo-project] Future "Modules system"

by Frank Shearar

On 3 February 2013 15:42, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/2/3 Frank Shearar <frank.shearar(a)gmail.com> >> >> >> For java example libA.jar uses SharedClass.methodA and libB.jar uses >> >> SharedClass.methodB. But #methodA exists only in version deployed as >> >> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. >> >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are >> >> defined explicitly in their classpathes. So libA.jar knows nothing >> >> about >> >> libS-b.jar and v.v. And that's why your java programm can works at same >> >> time with libA.jar and libB.jar. They will use different versions of >> >> same >> >> class. >> >> No they won't, unless you have separate class loaders. What will >> happen is you will get one version of a class or another. > > > Of course to get my java example working you should load classes from libA > and libB by separated class loaders. > In pharo there is no way to make it work. And this is what I want to discuss > here. But it's complicated and fragile to have separate classloaders, and a nightmare to debug. The Java people actively avoid this, for instance in JBoss installations. Take a look at Colin Putney's Environments work in Squeak 4.5. It provides a, well, environment in which you can load classes such that you can avoid the name clash problem. _Right now_ that's all it does, but it'll likely do more in the future. Gilad Bracha et al's work in Newspeak is the real way to go, I reckon. (Environments could be a first step in that direction.) Newspeak uses fully parameterised modules, which are first class entities. In fact they really are (stateless) classes. However, Newspeak supports inner classes. >> frank >> >> >> What it means in context of pharo? >> >> >> >> In pharo we have configurations which manage dependencies of projects. >> >> But >> >> you can't use at same time projectA and projectB which depend on >> >> different >> >> versions of projectS (when they both use same SharedClass from projectS >> >> like in java example). If you load projectA last you will get >> >> SharedClass >> >> with only methodA. If you load projectB last you will get SharedClass >> >> with >> >> only methodB. So projectA and projectB can't works correctly at same >> >> time. >> >> My example very simple. It includes just single class differencies. It >> >> can >> >> be more complicated and java world is good example for this. >> >> >> >> So my global question is how it can be solved in pharo? Do you have >> >> some >> >> plan for this? >> >> >> >> I can't remember something similar in pharo vision docs. But maybe what >> >> Stephane called "modules system" is exactly about this? I mean what >> >> Stephane always opposes in namespaces/environment discussions. And I >> >> think >> >> that this problem is ortogonal to namespaces/environments support. Do >> >> you >> >> agree? Do you know about such reseach in smalltalk? >> >> >> >> Little conclusion about such module system (if we can named it such >> >> way?) >> >> and what it is required from pharo: >> >> >> >> - ability to get in image different versions of same package. >> >> - separated class (global) dictionaries (multiple Smalltalk's) per >> >> package >> >> version. Maybe it can be named Module. So let's think about Module as >> >> unique Package+Version pair which contains all globals specific to this >> >> version and all dependent other Modules. >> >> - each Module knows it dependencies from other Modules, This >> >> information >> >> can be retreived from configuration. >> >> - each method and class should know from which project version (module) >> >> it >> >> was loaded. >> >> - inside any methods compiler should resolve class names based on >> >> Module >> >> dependencies information. Compiler should lookup actual class objects >> >> from >> >> module dependencies hierarchy. So no global Smalltak for compiler. But >> >> Smalltalk can be stay in system as default core Module. >> >> - If you want to use class which presents in two loaded versions of >> >> same >> >> package you should resolve conflict manually. Such action should add >> >> dependency to Module of your code. >> >> - Module can't have dependencies of two Modules of same package. It >> >> means >> >> that code of your project can use only version of some dependant class. >> >> I >> >> think it is essential restriction of Modules system. >> >> >> >> Main thing which Module system can get to us is ability to safelly load >> >> any >> >> versions of our projects and use it. It is not matter how old this >> >> code. >> >> System just loads old version of pharo core for example. Existed pharo >> >> core >> >> will continue works correctly. >> >> >> >> So what you think about it? >> >> >> >> Best regards, >> >> Denis >> > >> > >> >

Feb. 3, 2013

[Pharo-project] Object macpal protocol

by Camillo Bruni

can anyone explain? :D

Feb. 3, 2013

Re: [Pharo-project] Future "Modules system"

by Denis Kudriashov

2013/2/3 Frank Shearar <frank.shearar(a)gmail.com> > >> For java example libA.jar uses SharedClass.methodA and libB.jar uses > >> SharedClass.methodB. But #methodA exists only in version deployed as > >> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. > >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are > >> defined explicitly in their classpathes. So libA.jar knows nothing about > >> libS-b.jar and v.v. And that's why your java programm can works at same > >> time with libA.jar and libB.jar. They will use different versions of > same > >> class. > > No they won't, unless you have separate class loaders. What will > happen is you will get one version of a class or another. > Of course to get my java example working you should load classes from libA and libB by separated class loaders. In pharo there is no way to make it work. And this is what I want to discuss here. > frank > > >> What it means in context of pharo? > >> > >> In pharo we have configurations which manage dependencies of projects. > But > >> you can't use at same time projectA and projectB which depend on > different > >> versions of projectS (when they both use same SharedClass from projectS > >> like in java example). If you load projectA last you will get > SharedClass > >> with only methodA. If you load projectB last you will get SharedClass > with > >> only methodB. So projectA and projectB can't works correctly at same > time. > >> My example very simple. It includes just single class differencies. It > can > >> be more complicated and java world is good example for this. > >> > >> So my global question is how it can be solved in pharo? Do you have some > >> plan for this? > >> > >> I can't remember something similar in pharo vision docs. But maybe what > >> Stephane called "modules system" is exactly about this? I mean what > >> Stephane always opposes in namespaces/environment discussions. And I > think > >> that this problem is ortogonal to namespaces/environments support. Do > you > >> agree? Do you know about such reseach in smalltalk? > >> > >> Little conclusion about such module system (if we can named it such > way?) > >> and what it is required from pharo: > >> > >> - ability to get in image different versions of same package. > >> - separated class (global) dictionaries (multiple Smalltalk's) per > package > >> version. Maybe it can be named Module. So let's think about Module as > >> unique Package+Version pair which contains all globals specific to this > >> version and all dependent other Modules. > >> - each Module knows it dependencies from other Modules, This information > >> can be retreived from configuration. > >> - each method and class should know from which project version (module) > it > >> was loaded. > >> - inside any methods compiler should resolve class names based on Module > >> dependencies information. Compiler should lookup actual class objects > from > >> module dependencies hierarchy. So no global Smalltak for compiler. But > >> Smalltalk can be stay in system as default core Module. > >> - If you want to use class which presents in two loaded versions of same > >> package you should resolve conflict manually. Such action should add > >> dependency to Module of your code. > >> - Module can't have dependencies of two Modules of same package. It > means > >> that code of your project can use only version of some dependant class. > I > >> think it is essential restriction of Modules system. > >> > >> Main thing which Module system can get to us is ability to safelly load > any > >> versions of our projects and use it. It is not matter how old this code. > >> System just loads old version of pharo core for example. Existed pharo > core > >> will continue works correctly. > >> > >> So what you think about it? > >> > >> Best regards, > >> Denis > > > > > >

Feb. 3, 2013

Re: [Pharo-project] latest linux nb cog with SSL

by Camillo Bruni

well, a lot of complaining does not work well with not working :P On 2013-02-03, at 15:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks Camillo > You are doing an amazing amount of work. > > Stef > > On Feb 3, 2013, at 2:39 PM, Camillo Bruni wrote: > >> apparently the nativeboost build never featured a working SSL plugin under linux :/. >> >> => I manually changed [1] to include the SSL plugin >> => The Pharo-SSL-Tests should now properly pass under linux >> >> [1] http://pharo.gforge.inria.fr/ci/vm/nbcog/linux/nbcog-linux-latest.zip > >

Feb. 3, 2013

Re: [Pharo-project] Nautilus shortcuts

by Esteban Lorenzano

anyway, I will make the new keybindings optional before release 2.0 (so you can choose between new ones/old ones) On Feb 3, 2013, at 3:56 PM, Ben Coman <btc(a)openInWorld.com> wrote: > fair enough. I'll see how it goes. > > Camillo Bruni wrote: >> we will introduce the old shortcuts again with a setting, until then you have to learn them by heart ;). >> Most shortcuts are base on an action prefix + a suffix for the item you want to act on, it's not that difficult (but yes, more difficult than before): >> >> prefix: X => removing >> suffxin: M => Method >> T => Protocol >> C => Class >> P => Package >> >> so in that scheme alt-x alt-x doesn't make any sense ;) >> >> >> On 2013-02-03, at 07:00, Ben Coman <btc(a)openInWorld.com> wrote: >> >>> It appears in Nautilus that I've lost the <Alt-x> shortcut for deleting a method, and this has been replaced by a double-keystroke <Alt-x, Alt-m> which on first take I find a bit awkward. Probably I would adapt, however it would be easier to adapt to <Alt-x, Alt-x>. Would that be possible to have out of the box? >>> >>> >> >> >> >> > >

Feb. 3, 2013

Re: [Pharo-project] Nautilus shortcuts

by Ben Coman

fair enough. I'll see how it goes. Camillo Bruni wrote: > we will introduce the old shortcuts again with a setting, until then you have > to learn them by heart ;). > > Most shortcuts are base on an action prefix + a suffix for the item you want > to act on, it's not that difficult (but yes, more difficult than before): > > prefix: X => removing > suffxin: > M => Method > T => Protocol > C => Class > P => Package > > so in that scheme alt-x alt-x doesn't make any sense ;) > > > On 2013-02-03, at 07:00, Ben Coman <btc(a)openInWorld.com> wrote: > >> It appears in Nautilus that I've lost the <Alt-x> shortcut for deleting a method, and this has been replaced by a double-keystroke <Alt-x, Alt-m> which on first take I find a bit awkward. Probably I would adapt, however it would be easier to adapt to <Alt-x, Alt-x>. Would that be possible to have out of the box? >> >> > > > >

Feb. 3, 2013