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

Re: [Pharo-project] ODBC additions; very early GUI layer

by StÃ©phane Ducasse

Yeap. After alain we should try to find a way to publish on that since I know really little frameworks using MVP (except dolphin). I gave you the only paper I could find. but a nice MVP framework for pharo would be immensely cool. Stef On Jan 13, 2010, at 9:58 AM, Alain Plantec wrote: > Schwab,Wilhelm K a Ã©crit : >> I put two packages in PharoTaskForces. >> >> To any and all interested parties, I've added catalog methods to the existing ODBC wrapper. See the extension methods in ODBCConnection. You will have to excuse some gratuitous selectors that make my Dolphin ODBC code feel a little less unwelcome than it otherwise might. >> >> Gary, please take a quick look at the GUI package, in particular the TreeModel. Try >> >> TreePresenter example. >> >> I plan to make analogs to the staples from Dolphin's MVP framework: text, lists, trees, images. Value adapters will appear "soon." The handling of view resources will be a challenge. >> > super! please go on > Alain >> The usual caveats about backups appply, just in case. >> >> Bill >> >> >> _______________________________________________ >> 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. 13, 2010

Re: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent

by Igor Stasenko

Kill them , please. :) I dreaming about the time, when every method in Object will have a very strong reasons to stay there. 2010/1/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > hold on :) > we will kill a lot of them one at a time with a nice chainsaw :) > > Stef > > On Jan 13, 2010, at 8:58 AM, Lukas Renggli wrote: > >> And #defaultColor and #inform: and #modelSleep and #modelWakeUp and >> #modelWakeUpIn: and ... >> >> 2010/1/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> argh....... >>> May be not putting everything in Object would help. >>> >>> Stef >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=1802 Stef On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote: > Lukas Renggli a Ã©crit : >> I suggest everybody to have a quick look at VW: >> - they have #copy and #postCopy as we do >> - they have #shallowCopy that is used from #copy as we do >> - they have #dcopy (what a horrible name) that is implemented in a >> similar way to what I suggested for #deepCopy >> >> There is nothing else. >> > yes, I think we should adopt this with (dcopy -> deepCopy). > Alain >> Lukas >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

any bunch of cool tests before hacking? On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote: > Lukas Renggli a Ã©crit : >> I suggest everybody to have a quick look at VW: >> - they have #copy and #postCopy as we do >> - they have #shallowCopy that is used from #copy as we do >> - they have #dcopy (what a horrible name) that is implemented in a >> similar way to what I suggested for #deepCopy >> >> There is nothing else. >> > yes, I think we should adopt this with (dcopy -> deepCopy). > Alain >> Lukas >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

+1 I cannot imagine that they got dcopy (amazingly bad name) Stef On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote: > Lukas Renggli a Ã©crit : >> I suggest everybody to have a quick look at VW: >> - they have #copy and #postCopy as we do >> - they have #shallowCopy that is used from #copy as we do >> - they have #dcopy (what a horrible name) that is implemented in a >> similar way to what I suggested for #deepCopy >> >> There is nothing else. >> > yes, I think we should adopt this with (dcopy -> deepCopy). > Alain >> Lukas >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

Argh yes you are right so we just removed one of them.... There was one which copy but not the dependents or I do know what So we will have to squash some of them. >>>> check squeak 3.8 or related. > > I see the same methods starting with veryDeep as in Pharo 1.1. > > > Levente > >> >>> >>> >>> Levente >>> >>>>>>> - #copy is the normal copy operation. It should be used by default and >>>>>>> never overridden. It calls #postCopy that can be overridden to have >>>>>>> class specific copy semantics. >>>>>>> >>>>>>> - #shallowCopy does a shallow copy. It should never be overridden and >>>>>>> only be used if you want to get these very specific semantics. >>>>>>> >>>>>>> - #deepCopy does a deep copy. It should never be overridden and only >>>>>>> be used if you want to get these very specific semantics. >>>>>>> >>>>>>> - #clone comes from eToys and Morphic (AFAIK). It implements some >>>>>>> other copy semantics than #copy. I don't think that anybody should >>>>>>> call this method, other than code that depends on this particular copy >>>>>>> behavior. >>>>>> >>>>>> we should copy that in Object class comment and all the methods >>>>>> >>>>>> >>>>>> where do you see that it is morphic related for me clone is only implemented >>>>>> on character, Boolean, Object, SMalltInt symbol, UndefinedObject >>>>> >>>>> Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. >>>>> Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility. >>>>> >>>>> #clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying. >>>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>>> >>>>>>> This is exactly the same problematic as with #=. There can't be just >>>>>>> one #=. Other clients might consider other things when comparing >>>>>>> objects. >>>>>>> >>>>>>> Lukas >>>>>>> >>>>>>> -- >>>>>>> Lukas Renggli >>>>>>> http://www.lukas-renggli.ch >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. 13, 2010

Re: [Pharo-project] Network tests - Pharo vs. Squeak

by Adrian Lienhard

Hi Bill, If I remember correctly the consensus was to enable the useOldNetwork setting (at least in 1.0 and until the new implementation works reliably). Somehow we forgot to do that. Wouldn't that solve the problem? Cheers, Adrian On Jan 12, 2010, at 23:27 , Schwab,Wilhelm K wrote: > Hello all, > > I was recently reminded of network problems, such as a need to force the use of the "old network" on at least some Linux machines, and that I have had mixed results on Windows (not sure what is causing grief there, but suspects include 2k3 vs. xp, bad network setup in general and ipv6 in particular). > > So far, I have only one useful method that establishes a connection queue, then uses SocketStream to connect to is as locahost, enters a loop on #getConnectionOrNil, and then finally does some I/O. As I said, results are mixed. > > Another test that needs to be done is split the client and server across a real network. I can do that (perhaps subject to weird constraints) between win2k, 2k3 and Linux. I tend to think of Linux as the client, but I might be able to flip that around. > > My expectation (I can't believe I'm typing this<g>) is that Squeak will perform better than Pharo, only because of the "new network" changes, which I believe to be the cause of the problems. > > I envision something like a friendly root kit: get each machine to download both Pharo and Squeak, and install a small .mcz into each image. The idea is to allow many of us to try this on different networks and platforms, and to merge the results. > > For remote testing, there would probably need to be a server class with start/stop methods, and the client side test methods would hopefully log what they can. On successful remote conversation, the client should be able to automatically log details about the server, having read the details over the network. > > Suggestions on how to build this would be greatly appreciated. Can it all be done with Sunit, or is that asking too much? > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] Undo/Redo [was: Re: Object Buffer (implementation tryout)]

by Serge Stinckwich

2010/1/13 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Er yes, that would be because it works? There is some 2.0 video at http://sophiecommons.blip.tv/ which appears to work. > > The old site is at Â http://sophieproject.cntv.usc.edu/, open site at http://opensophie.com/ > > We could have used media like below 2 years ago. > > At ESUG I'm sure someone remarked why don't folks doing presentations at smalltalk conferences use Sophie? Advertisement problem ? -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Jan. 13, 2010

Re: [Pharo-project] ODBC additions; very early GUI layer

by Alain Plantec

Schwab,Wilhelm K a Ã©crit : > I put two packages in PharoTaskForces. > > To any and all interested parties, I've added catalog methods to the existing ODBC wrapper. See the extension methods in ODBCConnection. You will have to excuse some gratuitous selectors that make my Dolphin ODBC code feel a little less unwelcome than it otherwise might. > > Gary, please take a quick look at the GUI package, in particular the TreeModel. Try > > TreePresenter example. > > I plan to make analogs to the staples from Dolphin's MVP framework: text, lists, trees, images. Value adapters will appear "soon." The handling of view resources will be a challenge. > super! please go on Alain > The usual caveats about backups appply, just in case. > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Jan. 13, 2010

Re: [Pharo-project] Problem with Inspector [WAS] Fwd: [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Frederic Pluquet

It is a hard problem to solve. To update the tree after a "Do it", the current process is forked: the problem is a problem of synchronisation between the update processes and the UI process... Two closed requests updating the tree creates two processes, working together on the same UI. I need to find an other way to perform the tree update. An idea anybody ? FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Wed, Jan 13, 2010 at 9:40 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I forgot to cc Frederic :) > > 2010/1/12 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> >> >> 2010/1/12 Serge Stinckwich <serge.stinckwich(a)gmail.com> >> >>> Thank you for your good work Mariano. I use your image for my >>> development right now. The inspector is crashing in unexpected ways. >>> >>> Just try : #(1 2 3 4 5 6 7 9 10) inspect. >>> and in the panel below on the right, just evaluate for example : 3+7 with >>> CTRL-D >>> several times. After a while, the following screen appears. >>> >>> >> >> Thanks Serge for the report. I could reproduce it even in my first cmd d >> to 3 +7 >> >> I created the issue: http://code.google.com/p/pharo/issues/detail?id=1783 >> >> I cc Frederic as it seems to be a problem with the inspector. >> >> Cheers >> >> Mariano >> >> >>> 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> > Hi Folks/Beta-Testers! >>> > >>> > I have prepare a new PharoDev image. This image, has same differences >>> with >>> > the previous ones that you should know: >>> > >>> > 1) This is the first Dev image I ever prepare. I adapt to Mac OS >>> Damien's >>> > bash scripts to build them and I also cleanup all the Squeak stuff from >>> > those bash scripts. So, maybe there are some problems. Forgive me if >>> this is >>> > the case. I would like you to check, not only the Image in itself but >>> also >>> > the zip. The package.txt, changelog, the fonts, etc. >>> > >>> > 2) This image puts TrueType fonts again. We won't put StrikeFonts or >>> DejaVu >>> > package until there is big bug with them. We know those fonts are >>> faster, >>> > but still a bit buggy. If you fix those issues, cool! >>> > >>> > 3) This image DOES NOT include O2. I know there are a lot of people who >>> use >>> > it (mostly in Moose), but unfortunately, this was a decision taken. O2 >>> > depends and overrides OB making this more unstable sometimes. The same >>> as >>> > the TrueType, we will put O2 again when this can be perfectly load in a >>> > PharoCore image without anything about OB. >>> > Sorry, but we rather affect only O2 users and not all. If you want >>> packages >>> > support, then help in O2 development. >>> > >>> > 4) In previous Dev images only tests from PharoCore were included. Now, >>> it >>> > also includes the tests from the external packages loaded. >>> > >>> > 5) This image was build using Metacello configurations. If you want, >>> compare >>> > the installScript.st from this image to the previous one. >>> > >>> > 6) There is no Web image this time. If you want to install Seaside >>> 2.8.4 >>> > evaluate: >>> > >>> > Gofer new >>> > squeaksource: 'MetacelloRepository'; >>> > package: 'ConfigurationOfSeaside28'; >>> > load. >>> > >>> > (Smalltalk at: #ConfigurationOfSeaside28) load >>> > >>> > And if you want Seaside 3.0 evaluate: >>> > >>> > Gofer new >>> > squeaksource: 'MetacelloRepository'; >>> > package: 'ConfigurationOfSeaside30'; >>> > load. >>> > >>> > (Smalltalk at: #ConfigurationOfSeaside30) loadLatestVersion >>> > >>> > However, I am not sure if this is perfectly working in Pharo. >>> > >>> > >>> > >>> > Ok .... Here is the link: >>> > >>> https://gforge.inria.fr/frs/download.php/25156/pharo1.0-10505-rc1dev10.01.1… >>> > >>> > I will wait a couple of days now and I will also start to use this >>> image for >>> > my development. If there are issues, report them. If we have big >>> issues, >>> > this image is not release. On the other hand, if it works well, we >>> release >>> > it. >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> >>> >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>> Smalltalkers do: [:it | All with: Class, (And love: it)] >>> http://doesnotunderstand.org/ >>> >>> _______________________________________________ >>> 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. 13, 2010