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

Re: [Pharo-project] Pharo 2.0beta One-click download link gives 404 error

by H. Hirzel

Hello Camillo Thank you for the link to the bug entry. https://code.google.com/p/pharo/issues/detail?id=7315 I hope that it can be fixed soon. Regards Hannes On 1/27/13, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > H. Hirzel wrote >> The download link from >> http://www.pharo-project.org/pharo-download/beta-2-0 >> >> gives a 404 error. > > That reminds me... fixed the Jenkins and inbox/pharo feed links at > http://www.pharo-project.org/community > > > > -- > View this message in context: > http://forum.world.st/Pharo-2-0beta-One-click-download-link-gives-404-error… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 4, 2013

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

by Lawson English

dare I mention Craig Latta's Spoon project which explicitly is meant to solve this issue? L On 2/3/13 1:42 PM, Igor Stasenko wrote: > On 3 February 2013 20: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. >> 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. >> > +1. From a first sight, it looks like we are missing features to > support such cases (like having two > different versions of same class because of dependencies), but if we > look at results of having this, > it is apparent that it will serve as a source of confusion, and while > in perfect cases this will work fine, > i would hate knowing that my project, in order to function properly, > requires two different versions > of same class (or package) and avoid this at all costs. > > I think this problem stems from having a proprietary code, which you > cannot control or change, > but since in pharo we don't have such 'frozen & closed' code, all the > problems with dependencies > can be solved in more traditional manner: by fixing them :) > >> Miguel >> > > -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

Feb. 4, 2013

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

by Frank Shearar

On 3 February 2013 20:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 3 February 2013 20: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. >> 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. >> > > +1. From a first sight, it looks like we are missing features to > support such cases (like having two > different versions of same class because of dependencies), but if we > look at results of having this, > it is apparent that it will serve as a source of confusion, and while > in perfect cases this will work fine, > i would hate knowing that my project, in order to function properly, > requires two different versions > of same class (or package) and avoid this at all costs. It's a nice idea, to avoid this kind of situation at all costs. The problem is, you can't. > I think this problem stems from having a proprietary code, which you > cannot control or change, > but since in pharo we don't have such 'frozen & closed' code, all the > problems with dependencies > can be solved in more traditional manner: by fixing them :) Well, no, unless you write all your libraries yourself. Noone, especially not people trying to deliver software in a commercial context, can afford to write everything themselves. You'll have to use other people's libraries. Now sure, you can talk to the library authors, and encourage them to all use the same version of Foo or whatever, but it's not actually something you can avoid "at all costs". So we might as well think about how to actually deal with the problem. frank >> Miguel >> > > > > -- > Best regards, > Igor Stasenko. >

Feb. 3, 2013

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

by Marcus Denker

On Feb 3, 2013, at 9:31 PM, 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. > I went back to a very old guid to find one that does not crashâ¦ I think it is just from before the ssl was fixed (this is why we need a working buildâ¦ without we can not do anything)

Feb. 3, 2013

Re: [Pharo-project] seaside.gemstone.com/ss/metacello Error 500

by Sven Van Caekenberghe

On 03 Feb 2013, at 21:51, Camillo Bruni <camillobruni(a)gmail.com> wrote: > When I export the whole pharo sources I get infrequent error 500 responses on > http://seaside.gemstone.com/ss/metacello > > ----------------------------------------------------------------------------- > MCRepositoryError: Could not access http://seaside.gemstone.com/ss/metacello:ZnHttpUnsuccessful: 500 Internal Server Error > [0mMCHttpRepository>>loadAllFileNames in Block: [:exception | (exception className beginsWith: 'Zn...etc... > BlockClosure>>cull: > MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] > BlockClosure>>ensure: > MethodContext(ContextPart)>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > ZnHttpUnsuccessful(Exception)>>signal > ZnClient>>handleResponse > ZnClient>>executeWithRedirectsRemaining: > ... > ----------------------------------------------------------------------------- > > is that a know problem, or do I just run into a strange image? 'occasional' is never good ;-) Can you see anything useful in the response from the server ?

Feb. 3, 2013

[Pharo-project] seaside.gemstone.com/ss/metacello Error 500

by Camillo Bruni

When I export the whole pharo sources I get infrequent error 500 responses on http://seaside.gemstone.com/ss/metacello ----------------------------------------------------------------------------- MCRepositoryError: Could not access http://seaside.gemstone.com/ss/metacello:ZnHttpUnsuccessful: 500 Internal Server Error [0mMCHttpRepository>>loadAllFileNames in Block: [:exception | (exception className beginsWith: 'Zn...etc... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ZnHttpUnsuccessful(Exception)>>signal ZnClient>>handleResponse ZnClient>>executeWithRedirectsRemaining: ... ----------------------------------------------------------------------------- is that a know problem, or do I just run into a strange image?

Feb. 3, 2013

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

by Igor Stasenko

On 3 February 2013 21:33, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > 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). good to know that it is not because a problem in plugin. :) -- Best regards, Igor Stasenko.

Feb. 3, 2013

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

by Camillo Bruni

On 2013-02-03, at 21:39, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Feb 3, 2013, at 9:35 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> - Pharo-2.0-Kernel >> - CogDroid > > why this two are not pharo? because we do not maintain them? > I think they are important for us who maintains them, that is indeed the question. If they turn red, who can fix them? - Pharo 2.0 Kernel is basically red - CogDroid is red as well Did I ever hear any complaints? No, so they are not used nor maintained by us! => they go on pharo-contributions where they can grow until they are stable Everything under https://ci.inria.fr/pharo has to be green, otherwise it is bad publicity. Stuff under pharo-contribution can have any state, preferably green of course, but we do not care. Of course if we have people in our team that volunteer to run and fix the builds I am happy to keep them under /pharo. But otherwise it's just additional work

Feb. 3, 2013

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

by Igor Stasenko

On 3 February 2013 20: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. > 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. > +1. From a first sight, it looks like we are missing features to support such cases (like having two different versions of same class because of dependencies), but if we look at results of having this, it is apparent that it will serve as a source of confusion, and while in perfect cases this will work fine, i would hate knowing that my project, in order to function properly, requires two different versions of same class (or package) and avoid this at all costs. I think this problem stems from having a proprietary code, which you cannot control or change, but since in pharo we don't have such 'frozen & closed' code, all the problems with dependencies can be solved in more traditional manner: by fixing them :) > Miguel > -- Best regards, Igor Stasenko.

Feb. 3, 2013

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

by Esteban Lorenzano

On Feb 3, 2013, at 9:35 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > - Pharo-2.0-Kernel > - CogDroid why this two are not pharo? because we do not maintain them? I think they are important for us

Feb. 3, 2013