January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ConfigurationOfSeaside available

by Miguel Enrique CobÃ¡ Martinez

El mar, 26-01-2010 a las 17:14 -0800, Dale Henrichs escribiÃ³: > First load the configuration: > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside'; > load. > > Then pick the Seaside variant you want to load: > > "Seaside 2.8" > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8 Examples'. > ConfigurationOfSeaside project latestVersion load: 'Magritte'. > ConfigurationOfSeaside project latestVersion load: 'Magritte Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier'. > ConfigurationOfSeaside project latestVersion load: 'Pier Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier AddOns'. > > "Seaside 3.0" > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0'. > ConfigurationOfSeaside project latestVersion load: 'Seaside 3.0 Tests'. > ConfigurationOfSeaside project latestVersion load: 'Magritte2'. > ConfigurationOfSeaside project latestVersion load: 'Magritte2 Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier2'. > ConfigurationOfSeaside project latestVersion load: 'Pier2 Tests'. > ConfigurationOfSeaside project latestVersion load: 'Pier2 AddOns'. > > I've tested the various loads with PharoCore-1.0-10508rc2. Should work fine in Dev variants as well... > Hi Dale, first I thought that you had merged the ConfigurationOfSeaside28 and ConfigurationOfSeaside30 in a single configuration but I saw, when loading this new config, that it only references the old ones. There is a reason to do this and not to unify them in a single package? I must say that externally isn't a problem, it works perfect. Just want to know the "how-to" part of this. Maybe there is some guideline underlying here that I would like to know :) Thanks > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 28, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Adrian Lienhard

+1 On Jan 28, 2010, at 16:39 , Miguel Enrique CobÃ¡ Martinez wrote: > El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribiÃ³: >> I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. >> >> Bill > > > Yes, I know that the code is very difficult to understand, mainly > because of the primitives. They brake the understanding you have so far > when you have to switch to c code with a lot of pointers/structs/string > buffers. > > The problem here is that, now it is impossible to change the networks > subsystem of Pharo (or squeak). As Mariano said, we *need* to release > 1.0 and this bug can be a show stopper. > > Also, with due respect to the original coders of the network subsystem, > the code is really convoluted (I know that networking isn't simple), at > least to understand the fully implication of a "simple" change like > this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, > primitives and smalltalk code. So I think that is difficult to have > someone with the enough knowledge to change the code so that it works > for now. But that is how things are now. Maybe our own ignorance of the > code is what negates us a fix, but we need to left that apart and work a > solution for the *particular* problem in hand. For 1.1 we can discuss > new implementation if that is required. > > As Adrian said, there are users that need useOldNetwork true and some > others that need useOldNetwork to false. The problem is that we don't > fully understand the consequences of both changes. > > So, people, we need your help. Those who are most familiar with the > network code, please, please, take a look and suggest a solution for the > 1.0 release. *No* full rewrites, no throw code, no blaming, just a > working workaround for this. > > Regards > > Miguel Coba > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 28, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Miguel Enrique CobÃ¡ Martinez

El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribiÃ³: > I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. > > Bill Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers. The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper. Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a "simple" change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required. As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes. So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this. Regards Miguel Coba -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 28, 2010

Re: [Pharo-project] For those who use Nabble ....

by Geert Claes

Thanks, I posted a brief message on the GNU and Squeak (beginners) mailing lists. Acting upon Janko's great suggestion I also asked Nabble support to help me get the mailing lists of VisualWorks and Swazoo moved here too -- View this message in context: http://n4.nabble.com/For-those-who-use-Nabble-tp1310998p1370742.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 28, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Schwab,Wilhelm K

I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Thursday, January 28, 2010 5:00 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? El miÃ©, 27-01-2010 a las 16:01 -0600, Miguel Enrique CobÃ¡ Martinez escribiÃ³: > El miÃ©, 27-01-2010 a las 21:07 +0100, Mariano Martinez Peck escribiÃ³: > > > > > > > Add it. So that not to forget. If it is not a bug, we just close it > > and that's all. > > > > > http://code.google.com/p/pharo/issues/detail?id=1884 > > I think that get to the source of the problem. Is the change of UseOldNetwork from false to true in the last images. I added a comment (http://code.google.com/p/pharo/issues/detail?id=1884#c4) to the issue with a procedure to reproduce the problem in old images (that worked ok) and to correct the problem in the last image (that doesn't work). Can you please test it and decide if it is right to revert to the old version of NetNameRelease class>>initializeNetwork? Any comment welcome Thanks -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 28, 2010

Re: [Pharo-project] Code Formatting

by StÃ©phane Ducasse

cool answer! Thanks! On Jan 28, 2010, at 10:16 AM, Stan Shepherd wrote: > > > Mike Hales wrote: >> >> Pharo - I using the latest Pharo 1.0 release candidate (dev not core) It >> seems like the coloring, and automatic completion work right out of the >> box, >> but when I choose "format" from the code pane context menu, nothing >> happens. >> Do I need to load something else? >> > Mike, > In Pharo, it looks like format works some of the time in Omnibrowser (the > default). I haven't got to the bottom of when/how; it should probably be a > bug report. > > The pretty print in Omnbrowser2 is reliable. Do you use this (O2)? The > instructions to load are in the external projects workspace, for which there > are instructions in the welcome workspace > > > DEVImageWorkspaces openExternalProjectWorkspace > > Then > > Gofer new > squeaksource: 'MetacelloRepository'; > package:'ConfigurationOfO2'; > load. > > (Smalltalk at: #ConfigurationOfO2) perform: #loadDefault. > > Use the menu of any browser to change to a new default browser > O2PackageBrowserAdaptor. > > >> Also, if it were to work, what would I >> have to do to get a keyboard shortcut for it. >> > I think there's a problem with the shortcut at the moment, related to this > issue: > http://code.google.com/p/pharo/issues/detail?id=1312&q=shortcut&colspec=ID%… > I'll open/reopen an issue ticket for that. > http://code.google.com/p/pharo/issues/detail?id=1886&sort=-id&colspec=ID%20… > http://code.google.com/p/pharo/issues/detail?id=1886&sort=-id&colspec=ID%20… > > >> Since so many of you write so much more code than me, I imagine that there >> are simple solutions. And while we're here, I wouldn't mind some >> suggestions >> regarding how to "pimp my image" so to speak, to make the development flow >> better. >> > If you don't use the package browser of O2, you might find it saves some > clicks saving, updating to/from Monticello, also you can run tests directly > from there. > > Do you use Lint (code critics). I think of it as my pair programming > partner. There are videos at: > http://www.lukas-renggli.ch/blog/ob-rb-3 > http://www.lukas-renggli.ch/blog/ob-rb-3 > > > Hope some of this is of help, ...Stan > > > -- > View this message in context: http://n4.nabble.com/Code-Formatting-tp1312264p1343764.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 28, 2010

Re: [Pharo-project] Issue 1887: O2 copy class doesn't copy class side instance variables

by Stan Shepherd

>From the browsers, it seems that Browser works, but OBSystemBrowserAdaptor doesn't copy the class side variable either. ...Stan -- View this message in context: http://n4.nabble.com/Issue-1887-O2-copy-class-doesn-t-copy-class-side-insta… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 28, 2010

[Pharo-project] Issue 1887: O2 copy class doesn't copy class side instance variables

by Stan Shepherd

10508 dev rc + O2. Try from the browser, or evaluate: foo := Object subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Whatever'. foo addInstVarName: 'bar'. foo class addInstVarName: 'classBar'. then O2CmdCopyClass new copyClass: Foo as: 'Foo2' result:- classBar is not defined in Foo2. Works fine in OB -- View this message in context: http://n4.nabble.com/Issue-1887-O2-copy-class-doesn-t-copy-class-side-insta… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 28, 2010

Re: [Pharo-project] Pretty print doesn't work in OB [WAS] Re: [squeak-dev] Re: Code Formatting

by Lukas Renggli

> Lukas: the pretty print is not working in OB. If you take the last PharoDev, > select a method and press "format", just nothing happens. > Can you reproduce it ? Seemed to be suddenly broken, I don't understand why? Fixed in: Name: OB-Refactory-lr.195 Author: lr Time: 28 January 2010, 11:32:52 am UUID: 6dc4214d-4b67-4aff-afb3-cf49150f8715 Ancestors: OB-Refactory-lr.194 - fixed the formatting Lukas > Thanks > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 28, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 27-01-2010 a las 16:01 -0600, Miguel Enrique CobÃ¡ Martinez escribiÃ³: > El miÃ©, 27-01-2010 a las 21:07 +0100, Mariano Martinez Peck escribiÃ³: > > > > > > > Add it. So that not to forget. If it is not a bug, we just close it > > and that's all. > > > > > http://code.google.com/p/pharo/issues/detail?id=1884 > > I think that get to the source of the problem. Is the change of UseOldNetwork from false to true in the last images. I added a comment (http://code.google.com/p/pharo/issues/detail?id=1884#c4) to the issue with a procedure to reproduce the problem in old images (that worked ok) and to correct the problem in the last image (that doesn't work). Can you please test it and decide if it is right to revert to the old version of NetNameRelease class>>initializeNetwork? Any comment welcome Thanks -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 28, 2010