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

Re: [Pharo-project] Xtreams?

by Stefan Schmiedl

On Mon, 12 Jan 2009 20:40:02 +0100 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Never heard before. That's what I thought when I was told about StateReplicationProtocol (SRP), found on sourceforge, IIRC. > Is the VW package invoking the Java Xtreams package? brrr... I don't think so, it might be two different implementation of an "Xtreams" idea, or just a random name clash. > Stefan do you have an idea why this would be so fast compared to the > other approaches. hmm... "if we can see farther today, it's because we're standing on the shoulders of giants"? I'd guess it's good design and good programming. s.

Jan. 12, 2009

Re: [Pharo-project] [MC] [ANN] Sourcetalk

by Mariano Martinez Peck

Excelents both documents. I really like them! I am one of the SqueakDBX team and one reason I really hate monticello is that when every time I want to save (commit) it commits full package. This is very annoying, So, I would really like to use Moncticello2 and SourceTalk. In addition, I also should use the monticello to monticello2 exporter. My question is, is this three things stable enough ? Should we start using it or should we wait for more stable releases? Thanks for the help, Mariano On Fri, Jan 9, 2009 at 12:11 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > The complete documentation on Sourcetalk of Andrea Quadri is now > online. This includes technical documentation and a users guide: > > http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?query=Quadri<http://www.iam.unibe.ch/%7Escg/cgi-bin/scgbib.cgi?query=Quadri> > > Cheers, > 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 >

Jan. 12, 2009

[Pharo-project] [ANN] 10205

by StÃ©phane Ducasse

- New Diff tools - More collection tests - Collections categories as packages (level one) Next - category as packages collections level two - mike network refactoring (I hope it loads). - bugs, watchit and others etoy removal

Jan. 12, 2009

[Pharo-project] Merging tool and class var

by nicolas cellier

Hello all, The new monticello merging tool looks very nice. However, it's hard to tell whether the change is related to instance side or class side. Try with Multilingual-adrian_lienhard.47 which does exclusively class side changes... The change of class inst var appears like an unchanged definition of class. And methods are not indicated as class methods. I wonder what happens if a method with same name is changed both in instance and class side... Nicolas

Jan. 12, 2009

Re: [Pharo-project] Xtreams?

by StÃ©phane Ducasse

Never heard before. Is the VW package invoking the Java Xtreams package? Stefan do you have an idea why this would be so fast compared to the other approaches. >> does anybody have any experience or opinion about the Xtreams >> framework? Haven't looked at it yet, saw it mentioned here >> http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&pri… >> >> and it seems to have a Java impementation as well. > > > I have not really used it, but a while ago I compared various > serialization frameworks (BOSS, SRP, SIXX) in VisualWorks, > see http://www.parcplace.net/list/vwnc-archive/0805/msg00186.html > > Michael Lucas-Smith then privately asked me to try and run > the code with the then-current version of Xtreams. I had to > (trivially) patch unmarshalling for Sets and then ran some > tests comparing the three binary serializers BOSS, SRP, Xtreams. > The numbers below each block are the results reported by > printing the invocations four times in a row each. > > > |td| > ObjectMemory garbageCollect. > td := TestData new. > Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesBos ]] > 8339 8387 8328 8631 > > |td| > ObjectMemory garbageCollect. > td := TestData new. > Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesSrp ]] > 1969 1995 1953 1958 > > |td| > ObjectMemory garbageCollect. > td := TestData new. > Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesXtreams ]] > 1113 1086 1089 1089 > > |td dump| > ObjectMemory garbageCollect. > td := TestData new. > dump := TestData new saveToBytesBos. > Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesBos: > dump ]] > 2405 2465 2372 2491 > > |td dump| > ObjectMemory garbageCollect. > td := TestData new. > dump := TestData new saveToBytesSrp. > Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesSrp: > dump ]] > 2228 2247 2278 2282 > > |td dump| > ObjectMemory garbageCollect. > td := TestData new. > dump := TestData new saveToBytesXtreams. > Time millisecondsToRun: [10000 timesRepeat: [ td > loadFromBytesXtreams: dump ]] > 1817 1845 1861 1838 > > HTH, > s. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 12, 2009

Re: [Pharo-project] Very strange behavior with MC

by StÃ©phane Ducasse

excellent! Stef On Jan 12, 2009, at 6:34 PM, Adrian Lienhard wrote: > ok, I uploaded a new image, created starting at 10164 and updated to > 10204. > > https://gforge.inria.fr/frs/download.php/14204/Pharo0.1Core-10204.zip > > Adrian > > On Jan 11, 2009, at 22:49 , Adrian Lienhard wrote: > >> I created a new 10203 image starting from 10164. >> As expected, it does not have the Monticello setting enabled. >> >> Stef, how can I upload that image to gforge? >> >> Adrian >> >> On Jan 9, 2009, at 17:20 , Adrian Lienhard wrote: >> >>> Yes, I can do it on the weekend. >>> Adrian >>> >>> On Jan 9, 2009, at 17:07 , StÃ©phane Ducasse wrote: >>> >>>> >>>> On Jan 9, 2009, at 4:26 PM, Adrian Lienhard wrote: >>>> >>>>> No I didn't. >>>>> >>>>> But maybe we better recreate an image from the last version that >>>>> didn't have this setting? I don't think it was introduced by a >>>>> change >>>>> because in my images that I updated myself the setting was not >>>>> changed. >>>> >>>> Ok so may be we should redo a new core starting from the version >>>> you >>>> mentioned was >>>> not having such behavior. Do you do it? >>>> >>>> Stef >>>> >>>>> >>>>> >>>>> Adrian >>>>> >>>>> On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: >>>>> >>>>>> adrian >>>>>> >>>>>> did you use the cleaning expression of alex in your release? >>>>>> >>>>>> Stef >>>>>> >>>>>> On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: >>>>>> >>>>>>> Dear List, >>>>>>> >>>>>>> I dug in the Monticello melting-pot to find where the strange >>>>>>> behavior >>>>>>> some of you are encountering comes from. >>>>>>> >>>>>>> **The problem** >>>>>>> The bug come from the "diffy versions". MC tries to save in >>>>>>> PharoInbox >>>>>>> a "diffy" version of your package. As far as I understood, a >>>>>>> "diffy" >>>>>>> version is a version of your package that contains just a delta >>>>>>> from >>>>>>> an ancestor. In theory this looks nice, but for some reasons it >>>>>>> behaves incorrectly (the zip file is not probably created, it >>>>>>> cannot >>>>>>> be decompressed) >>>>>>> >>>>>>> **How to solve it** >>>>>>> Recently (since 10183), the http repository for PharoInbox is >>>>>>> set >>>>>>> to >>>>>>> store version in a diffy mode. You can identity http repository >>>>>>> that >>>>>>> are set that way: >>>>>>> MCHttpRepository allInstances select: [:mc | mc >>>>>>> alwaysStoreDiffs] >>>>>>> >>>>>>> The problem I mentioned in my previous email disappear symply by >>>>>>> doing >>>>>>> (MCHttpRepository allInstances select: [:mc | mc >>>>>>> alwaysStoreDiffs]) >>>>>>> do: [:mc | mc doNotAlwaysStoreDiffs] >>>>>>> >>>>>>> After having executed the last snippet, storing packages in >>>>>>> PharoInbox >>>>>>> will not appear empty. >>>>>>> >>>>>>> What is left to be done, is why this diffy mechanism does not >>>>>>> work >>>>>>> as >>>>>>> expected. But I feel that we should not use it anyway since the >>>>>>> ancestor link is not alway kept and is incorrectly handled >>>>>>> (e.g., >>>>>>> cross-repository ancestors) and MC2 is now in the pipeline. >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: >>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I just save a new version in PharoInbox, but this version >>>>>>>> appears >>>>>>>> to >>>>>>>> be empty. I checked on squeaksource [*]. >>>>>>>> In Pharo, it seems that two files are being saved (. >>>>>>>> 143(142).mcd >>>>>>>> and .143.mcz) [**]. >>>>>>>> when I browse .143(142).mcd I see all the content (probably >>>>>>>> because >>>>>>>> it is local to my machine). >>>>>>>> When I browse .143.mcz it is empty. >>>>>>>> >>>>>>>> What this .mcd file is about? >>>>>>>> I am not the only one to experience this. Anyone had an idea >>>>>>>> what's >>>>>>>> going on? >>>>>>>> I haven't closely followed the list of changes that were >>>>>>>> included >>>>>>>> in >>>>>>>> Pharo. >>>>>>>> >>>>>>>> Alexandre >>>>>>>> >>>>>>>> [*] http://bergel.eu/EmptyVersion.png >>>>>>>> [**] http://bergel.eu/TwoSavedVersions.png >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. 12, 2009

Re: [Pharo-project] GUI editor, etc.

by Gary Chambers

Polymorph-Magritte is on SqueakSource now, usual place (under the Polymorph project). Let me know how you get on. Additionally we have a small package (just a couple of methods) for using Polymorph-Magritte with the Units package if anyone is interested. Regards, Gary. ----- Original Message ----- From: GARY CHAMBERS To: Pharo-project(a)lists.gforge.inria.fr Sent: Friday, January 09, 2009 11:34 AM Subject: Re: [Pharo-project] GUI editor, etc. We have a package that provides Polymorph support for Magritte, as used in our ReportBuilder. I'm sure it would be no problem to get it released into SqueakSource :-) Regards, Gary ------------------------------------------------------------------------------ From: Bill Schwab <BSchwab(a)anest.ufl.edu> To: pharo-project(a)lists.gforge.inria.fr Sent: Friday, 9 January, 2009 4:16:55 AM Subject: [Pharo-project] GUI editor, etc. Hello all, There was some recent mention of GUI frameworks and/or an editor. For fear of losing the idea, I will just throw this out now while I am thinking of it. I submit that one needs both a drag/drop graphical tool, and a programmatic capability. The graphical approach works well for many/most uses. Programmatic construction is very helpful for creating views to match RDB schemas, etc. Magritte might be of help in both scenarios, especially the programmatic side. We might get a lot out of simply "telling Magritte about Polymorph." So far at least, we seem to be using code, not data structures, to assemble views. That would make the graphical tool something that should work like I _think_ WindowBuilder does/did. My recollection is that it executed code to construct objects and then had the modified objects write code to recreate themselves. I fear we need to be careful about looking at the code to see how it works. Perhaps a little controversial, Tweak strikes me (please feel free to disagree/correct as appropriate) as using compiler/language changes to do things that can be (and so far, I would argue should be) accomplished by composition of objects with the language as-is. What Tweak shows as events in code browsers, I would prefer to see listed in a graphical tool editor. I'm pretty sure I recall WindowBuilder doing a nice job of that too. The toothpicks holding my eyes open are about to snap. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 _______________________________________________ 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. 12, 2009

Re: [Pharo-project] Xtreams?

by Stefan Schmiedl

On Mon, 12 Jan 2009 18:33:33 +0100 "Michael Rueger" <m.rueger(a)acm.org> wrote: > Hi all, > > does anybody have any experience or opinion about the Xtreams > framework? Haven't looked at it yet, saw it mentioned here > http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&pri… > > and it seems to have a Java impementation as well. I have not really used it, but a while ago I compared various serialization frameworks (BOSS, SRP, SIXX) in VisualWorks, see http://www.parcplace.net/list/vwnc-archive/0805/msg00186.html Michael Lucas-Smith then privately asked me to try and run the code with the then-current version of Xtreams. I had to (trivially) patch unmarshalling for Sets and then ran some tests comparing the three binary serializers BOSS, SRP, Xtreams. The numbers below each block are the results reported by printing the invocations four times in a row each. |td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesBos ]] 8339 8387 8328 8631 |td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesSrp ]] 1969 1995 1953 1958 |td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesXtreams ]] 1113 1086 1089 1089 |td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesBos. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesBos: dump ]] 2405 2465 2372 2491 |td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesSrp. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesSrp: dump ]] 2228 2247 2278 2282 |td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesXtreams. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesXtreams: dump ]] 1817 1845 1861 1838 HTH, s.

Jan. 12, 2009

[Pharo-project] BTree gones ?

by Hilaire Fernandes

Can you confirm. I need it for Magma. Is this one suitable http://www.squeaksource.com/BTree.html ? Hilaire -- http://blog.ofset.org/hilaire

Jan. 12, 2009

Re: [Pharo-project] Xtreams?

by Lukas Renggli

There is an OMeta implementation for Squeak (http://www.cs.ucla.edu/~awarth/ometa/OMeta.sar) There are several PEG implementations on SqueakSource (http://www.squeaksource.com/AdvancedProgramming, http://www.squeaksource.com/PEG, ...). I've also written a Packrat parser framework (http://source.lukas-renggli.ch/petit) that I am using excessively as a tool for my research. It supports memoization (for speed) and left recursion (for convenience), though not as sophisticated as in OMeta. I've written a complete Smalltalk grammer, that produces the same AST as the parsers of the new compiler and refactoring browser do. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 12, 2009