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

Re: [Pharo-project] pharo-contribution CI server

by Camillo Bruni

looks like I managed to get all jenkins plugin up and running. I will migrate all non-pharo jobs to https://ci.inria.fr/pharo-contribution/ tomorrow. Mainly this includes: - Rizel - Phobos - Pharo-2.0-Kernel - CogDroid On 2013-02-03, at 20:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Great! > > Cheers, > Doru > > > On Feb 3, 2013, at 7:51 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I just create a new jenkins instance >> >> https://ci.inria.fr/pharo-contribution/ >> >> The goal is to keep https://ci.inria.fr/pharo as clean and green as possible. >> Everything that is experimental and not explicitly supported by the pharo code team >> should go to the pharo-contribution server. >> >> I hope to finish the setup this evening. >> >> best >> cami > > -- > www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > >

Feb. 3, 2013

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

by Camillo Bruni

On 2013-02-03, at 21:31, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 3 February 2013 14:39, Camillo Bruni <camillobruni(a)gmail.com> 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 > > hmm.. is it missing from build, or it not works properly? > because i remember i was adding it. it was missing from the build (only under linux).

Feb. 3, 2013

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

by Igor Stasenko

On 3 February 2013 14:39, Camillo Bruni <camillobruni(a)gmail.com> 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 hmm.. is it missing from build, or it not works properly? because i remember i was adding it. -- Best regards, Igor Stasenko.

Feb. 3, 2013

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

by Frank Shearar

On 3 February 2013 19:53, Miguel Moquillon <miguel.moquillon(a)gmail.com> wrote: > Le 03/02/2013 19:27, Denis Kudriashov a Ã©crit : >> 2013/2/3 Miguel Moquillon <miguel.moquillon(a)gmail.com >> <mailto:miguel.moquillon@gmail.com>> > >> >> 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/ >> <http://openjdk.java.net/projects/jigsaw/>). > >> >> Miguel >> >> >> I know about this. But let's talk about pharo. Now pharo can't do >> this. You can't have two versions of same package at same time in >> image. So how we can implement it? And do this is really important? > > > IMHO, it is not important and should be avoided because it is error-prone > (what is the actual version used by the objects?). This can even be a > nightmare with a lot of dependencies when an error occurs. That means that you have to be _extremely_ careful about what libraries you use, because you might well end up having different parts of your application depending on different versions of some library used by various libraries you use. The Metacello docs call this the "diamond dependency" problem. The thing with selector namespaces is that, at least as far as I'm aware, it's an open research problem. The classboxes work, if I recall correctly, pointed out several shortcomings in their approaches. Unless one moved ownership of methods from classes to packages, and ended up with a system looking a lot like Clojure...? At any rate, it's clearly not a simple thing or we'd have already done it. frank > Don't forget: keep things simple (it is always more easily to build too more > complex systems). > Having a program depending on a package in two different versions at the > same time in an image is in my opinion a design error. And if your program > depends on some tiers-party packages that depend on a different version of a > same package, then you should decide for the more recent one (or according > to other heuristic) and fix, if needed, the dependency in the others > packages. This is more easy to do with Pharo than with Java. > Even in Java, we take care to avoid these situations by using a dependency > exclusion with Maven. > > Miguel >

Feb. 3, 2013

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

by Miguel Moquillon

Le 03/02/2013 19:27, Denis Kudriashov a Ã©crit : > 2013/2/3 Miguel Moquillon <miguel.moquillon(a)gmail.com > <mailto:miguel.moquillon@gmail.com>> > > 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/ > <http://openjdk.java.net/projects/jigsaw/>). > > Miguel > > > I know about this. But let's talk about pharo. Now pharo can't do > this. You can't have two versions of same package at same time in > image. So how we can implement it? And do this is really important? IMHO, it is not important and should be avoided because it is error-prone (what is the actual version used by the objects?). This can even be a nightmare with a lot of dependencies when an error occurs. Don't forget: keep things simple (it is always more easily to build too more complex systems). Having a program depending on a package in two different versions at the same time in an image is in my opinion a design error. And if your program depends on some tiers-party packages that depend on a different version of a same package, then you should decide for the more recent one (or according to other heuristic) and fix, if needed, the dependency in the others packages. This is more easy to do with Pharo than with Java. Even in Java, we take care to avoid these situations by using a dependency exclusion with Maven. Miguel

Feb. 3, 2013

Re: [Pharo-project] Object macpal protocol

by Marcus Denker

On Feb 3, 2013, at 5:07 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > can anyone explain? :D > experiments from before e-toys. Mostly strange stuff. Marcus

Feb. 3, 2013

Re: [Pharo-project] pharo-contribution CI server

by Tudor Girba

Great! Cheers, Doru On Feb 3, 2013, at 7:51 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I just create a new jenkins instance > > https://ci.inria.fr/pharo-contribution/ > > The goal is to keep https://ci.inria.fr/pharo as clean and green as possible. > Everything that is experimental and not explicitly supported by the pharo code team > should go to the pharo-contribution server. > > I hope to finish the setup this evening. > > best > cami -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

Feb. 3, 2013

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

by Denis Kudriashov

2013/2/3 Camillo Bruni <camillobruni(a)gmail.com> > Have a look at ClassBoxes: > > http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf > > I think they come pretty close to what you have in mind. > Thank's for link. I think classboxies can be good basis to implement my requirement. Separated classbox per package version can be solution. Interesting how performance can be improved here? 25% is big penalty

Feb. 3, 2013

[Pharo-project] pharo-contribution CI server

by Camillo Bruni

I just create a new jenkins instance https://ci.inria.fr/pharo-contribution/ The goal is to keep https://ci.inria.fr/pharo as clean and green as possible. Everything that is experimental and not explicitly supported by the pharo code team should go to the pharo-contribution server. I hope to finish the setup this evening. best cami

Feb. 3, 2013

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

by Denis Kudriashov

2013/2/3 Miguel Moquillon <miguel.moquillon(a)gmail.com> > 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/ <http://openjdk.java.net/projects/jigsaw/>). > > Miguel > I know about this. But let's talk about pharo. Now pharo can't do this. You can't have two versions of same package at same time in image. So how we can implement it? And do this is really important?

Feb. 3, 2013