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

Re: [Pharo-project] Finder issue?

by Benjamin

On Dec 9, 2010, at 3:17 AM, Francisco Ortiz PeÃ±aloza wrote: > Ben, > > this could somewhat related to http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg36339.ht… > right? It's related at some pointsâ¦ UIManager is definitively bad structured, and ToolSet is pretty much the same, but I think they deserve to be restructured and used. I think (but I haven't read the whole source code) that AppRegistry follow the same way. I like the idea of having multiple tools that you can dynamically plug or unplug without difficulties, so ^^ Ben > > Cheers, > Francisco > > On Wed, Dec 8, 2010 at 7:56 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com > > wrote: > > On Dec 8, 2010, at 10:45 PM, Francisco Ortiz PeÃ±aloza wrote: > >> Great! Didn't know that but what about AppRegistry? I didn't see >> much of it, don't know if its an old idea or have a bad >> implementation but would it be better to use some dynamic binding >> mechanism so given any other day someone could change the editor >> globally like MorphicTextEditor default works. >> >> hmm i think i'm missing something > > AppRegistry was a good idea ages ago, but I do not know if it could > really be useful now ... > > I'll take a look at that ^^ > > > Ben > > >> >> Thanks, >> Francisco >> >> On Wed, Dec 8, 2010 at 7:00 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com >> > wrote: >> >> On Dec 8, 2010, at 8:37 PM, Francisco Ortiz PeÃ±aloza wrote: >> >>> Hi, >>> >>> after loading last Shout on PharoCore the new Finder isn't working >>> properly. Let's see >>> >>> PluggableShoutMorph>>initialize registers Shout in AppRegistry as >>> the default MorphicTextEditor but FinderUI>>buildSourceTextArea >>> uses a PluggableTextMorph. >>> >>> I think it should be using the more dinamic MorphicTextEditor >>> default insted of the hardcoded PluggableTextMorph. Am i right? >> >> In 1.2, it was panned that PluggableTextMorph and >> PluggableShoutMorph should been merged. In fact, I've posted a fix >> to allow PluggableTextMorph to handle text styling, this way Shout >> isn't needed anymore :) >> >> >> Thank you for your review, >> >> >> Ben >> >> > >

Dec. 9, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Sven Van Caekenberghe

On 08 Dec 2010, at 15:58, StÃ©phane Ducasse wrote: > On Dec 8, 2010, at 10:48 AM, Lukas Renggli wrote: > >> Very cool framework, I like it a lot! I definitely vote to eventually >> replace HTTPSocket with Zinc HTTP Components. > > I would love that. > We plan to open 1.3 Unstable 1 of january :) > So if you have code for that let me know :) Date today >= (Date year: 2011 month: 1 day: 1) ifTrue: [ Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; package: 'Zinc-Patch-HTTPSocket'; load ]. ;-) Sven

Dec. 9, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Tudor Girba

Hi Martin, Nice project. I noticed that you have a package FuelFameExtension. Is this done for the Fame meta engine? If yes, I would be interested in testing it, especially that in the context of Moose we do load the objects significantly more often than we store them :). Cheers, Doru On 8 Dec 2010, at 17:50, Martin Dias wrote: > Hi all > > Last months I and Tristan have been working on Fuel project, an object > binary serialization tool. The idea is that objects are much more > times loaded than stored, therefore it is worth to spend time while > storing in order to have faster loading and user experience. We > present an implementation of a pickle format that is based on > clustering similar objects. > > There is a summary of the project below, but more complete information > is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel > > The implementation still needs a lot of work to be really useful, > optimizations should be done, but we'll be glad to get feedback of the > community. > > > = Pickle format = > > The pickle format and the serialization algorithm main idea, is > explained in this slides: > > http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example > > > = Current features = > > - Class shape changing (when a variable has been added, or removed, or > its index changed) > - Serialize most of the basic objects. > - Serialize (almost) any CompiledMethod > - Detection of global or class variables > - Support for cyclic object graphs > - Tests > > > = Next steps = > > - Improve version checking. > - Optimize performance. > - Serialize more kinds of objects: > -- Class with its complete description. > -- Method contexts > -- Active block closures > -- Continuation > - Some improvements for the user: > -- pre and post actions to be executed. > -- easily say 'this object is singleton'. > - Partial loading of a stored graph. > - Fast statistics/brief info extraction of a stored graph. > - ConfigurationOfFuel. > - Be able to deploy materialization behavior only (independent from > the serialization behavior) > > > = Download = > > In a Pharo 1.1 or 1.1.1 evaluate: > > Gofer new > squeaksource: 'Fuel'; > version: 'Fuel-MartinDias.74'; > version: 'FuelBenchmarks-MartinDias.4'; > load. > > > = Benchmarks = > > You can run benchmarks executing this line (results in Transcript): > > FLBenchmarks newBasic run. > > > Thank you! > Martin Dias > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Dec. 9, 2010

Re: [Pharo-project] Issue 3389 in pharo: should add SimpleMorphic in core

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 3390 Comment #1 on issue 3389 by marcus.denker: should add SimpleMorphic in core http://code.google.com/p/pharo/issues/detail?id=3389 (No comment was entered for this change.)

Dec. 9, 2010

Re: [Pharo-project] Issue 3390 in pharo: should add SimpleMorphic in core

by pharo＠googlecode.com

Comment #1 on issue 3390 by marcus.denker: should add SimpleMorphic in core http://code.google.com/p/pharo/issues/detail?id=3390 Issue 3389 has been merged into this issue.

Dec. 9, 2010

Re: [Pharo-project] Where does Regex-Core and friends live

by Lukas Renggli

> I've got a GemSource repository, but I'm actually hoping (haven't run tests > yet:) that I will be able to use Regex-Core without making any > GemStone-specific changes ... That's unlikely, because the code makes quite some absolute stream positioning like aStream position = 0, aStream position = aStream size, etc. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2010

Re: [Pharo-project] Where does Regex-Core and friends live

by Lukas Renggli

> I am porting the latest Regex to GemStone and in the interest of Pharo > compatibility, I found Regex-Core and and Regex-Tests-Core in the Pharo > repository. The latest code is in <http://source.lukas-renggli.ch/unsorted/>. It is a full port of the latest code from VisualWorks + various critical bug fixes. Except for the packaging (which is identical to VisualWorks), it should be the same as the code in Pharo. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Adrian Lienhard

On Dec 8, 2010, at 22:49 , Mariano Martinez Peck wrote: > On Wed, Dec 8, 2010 at 10:33 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Hi Martin, >> >> I took some application for which we use image segments to test Fuel >> >> - With Fuel serializing and writing to disk took 330s. File size is 16.1MB >> - With image segments saving takes 4s and the file size is 2.4MB >> > > but how are you using ImageSegment? just the primitive? because in order > to compare it to Fuel, you should write all objects, including > "outPointers". So you should use #writeForExportOn: or similar... yes, this includes outPointers serialized with reference stream and writing to disk. Adrian BTW, I was just providing the numbers that I gathered when looking at Fuel (to see whether that could be interesting for our use case to replace image segments). This was not to say that Fuel is not on the right way or anything, but I though the numbers would be interesting for Martin because they show a real-world use case with a large number of objects. I know that Fuel is in an early stage of development and it doesn't (yet?) have a primitive/plugin to speed things up.

Dec. 9, 2010

Re: [Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

by pharo＠googlecode.com

Comment #3 on issue 3391 by stephane.ducasse: BlockClosure>>assertWithDescription: sends #logFailure: http://code.google.com/p/pharo/issues/detail?id=3391 The first thing I would do is assertWithDescription: aStringOrABlock self value ifFalse: [ |value| value := aStringOrABlock value. AssertionFailure signal: value] because logFailure: in anycase write to Transcript

Dec. 9, 2010

Re: [Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

by pharo＠googlecode.com

Comment #2 on issue 3391 by stephane.ducasse: BlockClosure>>assertWithDescription: sends #logFailure: http://code.google.com/p/pharo/issues/detail?id=3391 I have no idea what would be logFailure: on Closure and I would like to avoid it.

Dec. 9, 2010