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

Re: [Pharo-dev] Monticello and Fuel

by Chris Muller

> Yes, performance seems to be the main use case. Fuel files of hundreds of MB > take a long time to load and save, even if you only change a single string. > One instance where this is relevant is the Moose model. They currently use > .mse files, which use a textual representation (if Iâm not mistaken). Usman > asked me if Fuel were an option, especially for updating only parts of the > model. > > > Ok, but how could patching the file be much faster? The file has to be > parsed into something; why not the objects themselves? To me loading, > editing and red acing is patching and done as fast as Fuel can do things. > > Depending on syntax you may be able to scan for a string and replace using > eg the sed stream editor. But that'll only work for simple data like > strings. > > If you really need this to be faster have you considered > > - decomposing the Moose model into smaller individual components? > > - keeping the moose model to be saved in an image (possibly live running in > a server) and patching the model in the image and saving it This is a classic problem; as models start to get large they get harder to update. If there were some way to update the file with just the parts in memory that changed since the last save, it would perform a lot faster for the end user. Of course whatever makes models large is also what tends to make them more interesting to more users, but moves inversely to the sharability. Some kind of server is needed to serve up the fuel file and use the above to dish out whatever portions of the file needed by user for the part of the model they're accessing. When they save, only the parts of the model they changed, nothing more, are sent back to the server which performs a random-access update to the fuel file in a controlled, synchronous manner. Although, even with that I guess users could still overlay other users work very easily. Some kind of concurrency control mechanism should look at the changes being made and signal a warning if that happens.

Dec. 8, 2014

trying to download Hapa'o in a fresh Pharo image (4.0)

by sheridan＠sheridan-mahoney.com

Hello, I am trying to get Hapa'o loaded in a fresh 4.0 image, using the following command: Gofer new squeaksource: 'Spy'; package: 'ConfigurationOfSpy'; load. (Smalltalk at: #ConfigurationOfSpy) perform: #loadDefault and I run across this error: This package depends on the following classes: RBFormatter You must resolve these dependencies before you will be able to load these definitions: HapaoLineCoverage acceptAssignmentNode: acceptBlockNode:startBlockString:endBlockString: acceptCascadeNode: acceptLiteralArrayNode: acceptLiteralNode: acceptMessageNode: acceptPragmaNode: acceptReturnNode: acceptSequenceNode: acceptVariableNode: addAllText: addCoverageAtribute:isCovered: addText: coveredCondition format: ... This isn't something I'm familiar with, can someone tell me how to resolve it? Many thanks, Sheridan

Dec. 7, 2014

Code repository

by Benoit St-Jean

Hi guys! Coming back to Pharo! I was wondering, what is the preferred code repository for Pharo 3.x/4.x packages?Â SqueakSource 3 or SmalltalkHub ? tiaÂ ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

Dec. 7, 2014

Re: [Pharo-dev] [Moose-dev] [ann] gtspotter: a moldable interface for spotting objects

by Tudor Girba

Hi Sven, Exactly! :) To be relevant, we had to show how it solves existing use cases (plus a bit more :)). Next we will focus on objects that are less "code". The hard part of actually getting the interface smooth and performant was kind of done. It's play time now :). As I noted in the post, we already have some 30 extensions for handling these cases. This was actually easy. The menu is an example of how we used this concept to approach a problem that is classically dealt with in a completely different way. There are a couple of things we did not show yet. For example, we already have a simple implementation of how to make a Moose model completely browseable through this interface. But, as with the inspector, the coolest thing is that if someone has a specific need, it is even simpler than with the inspector to hook that need in the system and make it searchable. Your list is definitely exciting, and I am hoping that people will start playing a bit and discover things we otherwise would not consider. It should be easier than with the inspector (because there are less things to specify, hence less variation). And wait to see what happens when we start to combine this interface with others. For example, the interesting thing about being able to search a menu is that you can actually open any menu with a spotter, which essentially has the potential of changing the way we deal with contextual actions (all through keybindings without shortcuts). I am quite sure we are just scratching the surface of what is possible. So, let's play together :). Cheers, Doru On Sun, Dec 7, 2014 at 10:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Doru, > > One of the things/aspects that I miss a bit is the 'objects' part. In your > overall description/presentation you talk about 'objects', but right now I > would say it are mainly 'code objects' like classes & methods and friends, > and some IDE artefacts, like menus. > > What about arbitrary (user) objects ? > > Literal constants, like 123, 'some string' ? > Globals like the Transcript ? > Singletons accessible by class side accessors, like announcers ? > An evaluation functionality, just type an expression ? > Examples ? > The clipboard (contents), open windows, processes, ... > > Anyway, I am sure you get the idea ;-) > > Sven > > > On 07 Dec 2014, at 19:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi Sven, > > > > Thanks for the kind words. Indeed, having the current selection is one > of the things we should keep in mind. For that we need to go to the next > step and integrate the interface in the overall environment. This will > certainly come. > > > > Cheers, > > Doru > > > > > > > > On Sun, Dec 7, 2014 at 6:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 07 Dec 2014, at 14:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to > the Glamorous Toolkit: > > > GTSpotter, a novel interface for spotting objects. > > > > Excellent work, all around. Congratulations to the team. Thank you for > pushing things like this, for thinking differently. > > > > Yes, I want this in Pharo 4 too, ASAP (especially since the main > shortcut is different from the old one, cmd+Enter vs. shift+Enter). > > > > The presentation is again very well done too: excellent article, super > movie. You are putting the bar very high for the rest of us ;-) > > > > A suggestion/idea: would it be possible to take the current selection > anywhere and feed it into Spotter ? That way there would be very good way > to make it replace all the other shortcuts: you would get implementers, > senders, references almost for free. > > > > Sven > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 7, 2014

Re: [Pharo-dev] [Moose-dev] [ann] gtspotter: a moldable interface for spotting objects

by Sven Van Caekenberghe

Doru, One of the things/aspects that I miss a bit is the 'objects' part. In your overall description/presentation you talk about 'objects', but right now I would say it are mainly 'code objects' like classes & methods and friends, and some IDE artefacts, like menus. What about arbitrary (user) objects ? Literal constants, like 123, 'some string' ? Globals like the Transcript ? Singletons accessible by class side accessors, like announcers ? An evaluation functionality, just type an expression ? Examples ? The clipboard (contents), open windows, processes, ... Anyway, I am sure you get the idea ;-) Sven > On 07 Dec 2014, at 19:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Sven, > > Thanks for the kind words. Indeed, having the current selection is one of the things we should keep in mind. For that we need to go to the next step and integrate the interface in the overall environment. This will certainly come. > > Cheers, > Doru > > > > On Sun, Dec 7, 2014 at 6:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 07 Dec 2014, at 14:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit: > > GTSpotter, a novel interface for spotting objects. > > Excellent work, all around. Congratulations to the team. Thank you for pushing things like this, for thinking differently. > > Yes, I want this in Pharo 4 too, ASAP (especially since the main shortcut is different from the old one, cmd+Enter vs. shift+Enter). > > The presentation is again very well done too: excellent article, super movie. You are putting the bar very high for the rest of us ;-) > > A suggestion/idea: would it be possible to take the current selection anywhere and feed it into Spotter ? That way there would be very good way to make it replace all the other shortcuts: you would get implementers, senders, references almost for free. > > Sven > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Dec. 7, 2014

untypeable key combination

by Nicolai Hess

We have a class KMUntypeableSingleKeyCombination this is used for key kombinations with tab arrow backspace .... This is useful for printing key kombinations like Ctrl+TAB "space" does not use the KMUntypeableSingleKeyCombination class, therefore a short cut like Character space shift asKeyCombination looks like " Shift + " shouldn't space use this class? And I find the name a little bit misleading, what is a untypeable key? The key is typeable, otherwise we couldn't use it. Renaming the class to KMUnprintableSingleKeyCombination isn't better, because we can print this keycombination. nicolai

Dec. 7, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40403 Home: https://github.com/pharo-project/pharo-core

Dec. 7, 2014

[pharo-project/pharo-core] 172f0e: 40403

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 172f0e542d76844088db11e23938b50b3572ccd5 https://github.com/pharo-project/pharo-core/commit/172f0e542d76844088db11e2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-07 (Sun, 07 Dec 2014) Changed paths: M Morphic-Widgets-List.package/TreeListMorph.class/instance/private/addSubmorphsAfter_fromCollection_allowSorting_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script403.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40403.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40403 12027 Merge is incredibly slow with Polymorph difference tools, and unusable without https://pharo.fogbugz.com/f/cases/12027 http://files.pharo.org/image/40/40403.zip

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by Max Leske

> On 07 Dec 2014, at 19:24, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > oops, I was being dense... > > On Dec 7, 2014, at 5:14 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> >>> On 07 Dec 2014, at 04:19, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>> >>> Hi Max, >> >> Hi Eliot, >> >>> >>> On Sat, Dec 6, 2014 at 1:43 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> >>>> On 06 Dec 2014, at 04:37, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>>> >>>> >>>> >>>> On Thu, Dec 4, 2014 at 11:35 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>>> >>>> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>>> > >>>> > >>>> > >>>> > >>>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> I'm just wondering. >>>> >> >>>> >> Would it work to have a package format based on Fuel? >>>> >> >>>> > I doubt it would work cross platform. I don't know how fuel serializes WideString, LargePositiveInteger, BoxedFloat64. These differ between smalltalk platforms. The source as string solves that. Strings are written as unicode string and numbers as certain number format etc. >>>> >>>> True. Cross dialect loading isnât something we encourage to do with Fuel. >>>> >>>> @Thierry >>>> You said something about partial loading: that will never be possible with Fuel because of its pickle format. To select any partial graph you have to first read the entire file and rebuild the graph first (ok, you donât strictly have to build the graph but you still need to read the entire file). >>>> >>>> Hi Max, you misunderstand what partial loading means in this context. I designed and implemented partial loading for the Parcel system in VW, and Fuel is essentially a clean reimplementation of parcels. The idea is that one does indeed read the entire object graph, but then only the parts of the graph that mate with the current class hierarchy are installed, and the bits that don't fit are stored for later. Why? So that a component can define extensions on classes in components that may not be present. Why? So that one can maintain a single logical component in a single package instead of decomposing it into independently loadable fragments. >>> >>> Makes sense. Itâs just that I often get asked if it is possible to read / update only parts of a Fuel file, so I wanted to make it clear that that canât work. >>> >>> Right, good point. But is there a use case? For example, in effect is there a difference between being able to patch a part of a Fuel file and loading that file into an image (possibly automatically), patching the object graph and saving a new version? >> >> Yes, performance seems to be the main use case. Fuel files of hundreds of MB take a long time to load and save, even if you only change a single string. One instance where this is relevant is the Moose model. They currently use .mse files, which use a textual representation (if Iâm not mistaken). Usman asked me if Fuel were an option, especially for updating only parts of the model. > > Ah ok. Then yes, I suspect Fuel will be faster, but that patching is more complex because it can't be done in a text editor. How do they edit the .mse file? IME text editors suck on large files. What are the relative frequencies of writing, reading and editing these files? I donât think they can patch the .mse files. Thatâs exactly why they are looking for alternatives. I have no clue about the read / write frenquencies they need. Iâm CCâing this to Usman, maybe can comment on that. > > >>>> Lets take an example like Fuel itself. This may have specialised marshalling and unmarshalling extensions defined on may classes, some of which may be to do with the GUI. If we have partial loading we can load Fuel into a headless image. The extensions on the GUI classes will simply not be installed, *until* we load the GUI. Hence Fuel does not have to be decomposed every time we factor the system into subcomponents. Without partial loading Fuel must be decomposed into a series of fragments so that it can load that part that fits into the headless base, and we have to manage teh dependency to ensure the fragment that loads against the GUI is loaded when the GUI is loaded. Worse still, if we cut the GUI into two (e.g. development vs deployment tools) we have to visit the Fuel GUI component (and potentially many other component) and decompose it into two pieces. In practice this is extremely costly to maintain, verging on chaos. With partial loading things are simple. >>>> >>>> Perhaps I should have called it partial installation, but you get the idea. >>> >>> Thanks for the explanation. >>> >>>> >>>> >>>> > >>>> > Norbert >>>> > >>>> >> Would that make loading faster? >>>> >> >>>> >> Does it already exist? >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Thierry >>>> > >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>> >>> >>> >>> >>> -- >>> best, >>> Eliot

Dec. 7, 2014

Re: [Pharo-dev] Duration year

by Hilaire

Thanks. Looks interesting. Does anyone use it in production? Hilaire Le 07/12/2014 18:36, David T. Lewis a Ã©crit : > On Sun, Dec 07, 2014 at 09:30:06AM +0100, Hilaire wrote: >> Hi, >> >> What is Chalt??n please? > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-April/177938.ht… > > https://github.com/mtaborda/chalten > >> >> Hilaire >> >> Le 02/12/2014 20:53, Maximiliano Taborda a ??crit : >>> Hi all. >>> >>> The same examples using Chalt??n: >>> February twentyninth, 2012 next: 1 yearMeasure. "=> February >>> 28th, 2013" >>> March first, 2011 next: 1 yearMeasure. "=> March 1st, 2012" >>> March first, 2011 next: 12 monthsMeasure. "=> March 1st, 2012" >>> >>> Hilaire, In Chalt??n a year is a year so you don't need to care about of >>> the number of days in it. >>> >>> Regards. >>> Maxi >>> >> >> >> -- >> Dr. Geo - http://drgeo.eu >> iStoa - http://istoa.drgeo.eu >> > > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 7, 2014