- Pharo-dev - lists.pharo.org

Re: [Pharo-project] clarifying PopUpMenu vs. MenuMorph

by Gary Chambers

Sounds good. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, January 26, 2010 10:00 AM Subject: [Pharo-project] clarifying PopUpMenu vs. MenuMorph > Hi all > > I was reading a bit squeak and PopUpMorph is only used in MVCUiManager. > So this reminded me that we should > - replace PopUpMenu by UIManager default... > - UIManager... uses MenuMorph > - Remove PopUpMenu > - funnel some MenuMorph usage to UIManager default. > > What the ui guys think? > > > Stef > > _______________________________________________ > 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] Monticello diff between chosen revisionsisbroken

by Gary Chambers

It is on the "wish list"... has been for some time now. Having had a look in light of recent thread I believe it will be possible. Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, January 26, 2010 12:40 PM Subject: Re: [Pharo-project] Monticello diff between chosen revisionsisbroken On Tue, Jan 26, 2010 at 8:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: gary what would be great is to have a label on top of the two methods shown I never now what I'm reading Incoming InWorkingCopy New Current would be so great! And if you do it also in the merge, it would be a dream :) Stef On Jan 25, 2010, at 7:25 PM, Gary Chambers wrote: > Yes, in this case it is a bug with Polymorph. > > Try with > > MCVersionInspector>>changes > "Open a patch morph for the changes." > > self viewChanges: self version changes > > > Hopefully no bad side-effects... > > With a bit more work it may be possible to show both versions between which the changes apply (unlike the old MC tools) ;-) > > Regards, Gary > ----- Original Message ----- > From: Gary Chambers > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, January 25, 2010 6:05 PM > Subject: Re: [Pharo-project] Monticello diff between chosen revisionsisbroken > > > MCVersionInspector>>diff > | ancestorVersion | > self pickAncestor ifNotNil: > [:ancestor | > ancestorVersion := self version workingCopy repositoryGroup versionWithInfo: ancestor. > (self version asDiffAgainst: ancestorVersion) open] > > > Regards, Gary > ----- Original Message ----- > From: Gary Chambers > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, January 25, 2010 5:50 PM > Subject: Re: [Pharo-project] Monticello diff between chosen revisionsisbroken > > Needs looking at since it is confusing. IIRC the Diff button creates a .mcd file of the changes between some versions... > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, January 25, 2010 5:34 PM > Subject: Re: [Pharo-project] Monticello diff between chosen revisionsisbroken > > > > 2010/1/25 Gary Chambers <gazzaguru2(a)btinternet.com> > The "Diff" button on the Monticello repository browser does what its balloon help says... > > 'Create an equivalent version based on an earlier release'. This is a diff version. I never use them as they can be confusing :-) > > > Ok...I never used before...but something is clear: the second ask about a version, has no sense, and even is wrong if it compares to the last version. See step 6 of Stefan. Then, we have to options: > > - Or we remove that second prompt, as it always will use the last version > - Or we change the diff implementation so that it uses the selected version instead of the last. > > What do you think ? > > Does someone really know what this "diff" should do ? > > Cheers > > Mariano > > If you want to compare two existing versions you should: > > 1. Open Monticello Browser > 2. Select a repo > 3. click open > 4. Select a revision, not the latest one > 5. Click HISTORY > > 6. chose an ancestor from the list > > > Regards, Gary > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Lukas Renggli > Sent: Sunday, January 24, 2010 12:59 PM > Subject: Re: [Pharo-project] Monticello diff between chosen revisions isbroken > > > > On Sat, Jan 23, 2010 at 9:51 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > In the current dev image (10508), Monticello is broken with respect to showing the differences of between chosen revisions. > > However, that seems to be broken already in 10496. (and maybe earlier) > > To reproduce: > > 1. Open Monticello Browser > 2. Select a repo > 3. click open > 4. Select a revision, not the latest one > 5. Click diff > 6. chose an ancestor from the list > Now you got a window 'Version: ...5' > Saying (Diff against ...2) > Here I would expect the changes button to open a window showing the changes between the chosen revisions, but it always diffs against the latest version. > > > Yes, I could reproduce the problem. Can you open a ticket ? > > Maybe Lukas Monticello guru can help us ? hahaha > > Cheers > > Mariano > > > Best > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 3956 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ------------------------------------------------------------------------------ _______________________________________________ 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] 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