- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Support for git in Pharo

by Goubier Thierry

Le 07/03/2014 09:52, Max Leske a Ã©crit : >> - And be able to rebuild package version history via the VCS history, as I do now in gitfiletree. > > Yes, that is something that should be possible. > > To be honest, those thoughts are a bit too far in the future at the moment. First, I want to have Git plumbing running, then Iâll see about the rest. That was certainly the advantage of my solution: easy plumbing, left me the time to: use it, and plan good uses of it. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 7, 2014

Re: [Pharo-dev] Support for git in Pharo

by Dale Henrichs

Frank, Yeah, for browsing Smalltalk repos on github itself, I figured that an Amber app would be the way to go ...then you could have a "real" code browser with senders implementers, etc.... and the same code could run in a pharo image to browse unloaded repos from github or disk ... Just a simple matter of putting tooling in place:) Dale On Fri, Mar 7, 2014 at 1:34 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 6 March 2014 20:18, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > wrote: > > Stephan, > > > > The reason that we have the granularity of a file per method is to > leverage > > git's history/tracking facilities on a per method basis. > > > > At this level of granularity, you can move a method around in the package > > structure and git will maintain the method modification history because > git > > treats these as a file rename and git is very good at tracking file > renames > > ... > > > > So you can use "blame" to view a line by line history of the method > > modifications ... > > > > If one starts clumping methods into files, then you lose all method > history > > when it moves from one clump to another ... > > Another huge strength with versioning per method (and one of the main > reasons I don't complain too loudly about the uselessness of GitHub in > viewing code when doing this) is also that you never ever have to try > merge two methods that two different commits have put in the same > place, and the diff algorithm has decided to _interleave_ the methods. > Fun times! > > frank > > > Dale > > > > > > > > On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >> > >> Max wrote > >> >In my opinion there are other factors, like readability, maintenance > etc, > >> > that are maybe more important than speed. > >> > >> I'm not totally convinced. The readability from the outside is limited > by > >> having one file per method. > >> Mainstream tooling assumes one file per class. The emails from github to > >> this list are a good example > >> of the usability problems that leads to. I don't want to suggest > switching > >> to a larger granularity, as that > >> leads to another set of problems. > >> > >> My point was more if we could mostly avoid the source view, and directly > >> work with the archive. > >> Why is working with single files fastest? > >> > >> Stephan > > > > > >

March 7, 2014

Re: [Pharo-dev] What happened with petitmarkdown?

by Stephan Eggermont

ClÃ©ment wrote >Camillo moved all his repo on github and deleted the ones from smalltalkhub. Hmm. I strongly prefer immutability for source code repositories. And a link to older/newer repos. Stephan

March 7, 2014

Re: [Pharo-dev] What happened with petitmarkdown?

by ClÃ©ment Bera

Hey, Camillo moved all his repo on github and deleted the ones from smalltalkhub. 2014-03-07 8:10 GMT+01:00 Damien Cassou <damien.cassou(a)gmail.com>: > Try on github > On Mar 6, 2014 1:27 PM, "Stephan Eggermont" <stephan(a)stack.nl> wrote: > >> Camillo, >> >> While fixing some ci builds, I noticed that at least some of your >> smalltalkhub >> repositories are empty (petitmarkdown, ast-interpreter). What happened >> with the code? ast-interpreter I could find back, but petitmarkdown not. >> >> Stephan >> >> >>

March 7, 2014

[pharo-project/pharo-core] b3065f: 30792

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: b3065f4660c4d171cd5b87f426cad38658f3ff64 https://github.com/pharo-project/pharo-core/commit/b3065f4660c4d171cd5b87f4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-03-07 (Fri, 07 Mar 2014) Changed paths: A OpalCompiler-Core.package/IRInterpreter.class/instance/instructions/storeInstVar_.st M OpalCompiler-Core.package/IRMethod.class/instance/optimizing/removeEmptyStart.st A OpalCompiler-Core.package/IRPrinter.class/instance/instructions/storeInstVar_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script445.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30792.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30792 13053 Sync image with repo https://pharo.fogbugz.com/f/cases/13053 13002 StoreInstVar: is missing in IRPrinter https://pharo.fogbugz.com/f/cases/13002 13003 Opal cannot optimize twice an IRMethod https://pharo.fogbugz.com/f/cases/13003 http://files.pharo.org/image/30/30792.zip

March 7, 2014

[pharo-project/pharo-core]

by GitHub

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

March 7, 2014

Re: [Pharo-dev] Is there some shared memory space?

by roberto.minelli＠usi.ch

On Mar 7, 2014, at 12:24 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 07.03.2014, at 11:55, roberto.minelli(a)usi.ch wrote: > >> Hi guys, >> >> I am experiencing a very strange problem that makes me think there is some shared memory problem with Pharo. >> >> Here are the steps that lead to the problem: >> - I have an image, I do something (i.e., materializing objects with Fuel) >> - I encounter a problem and a debugger pops up with a âself error: something" >> - I close the debugger >> - I close the image > > Do you save the image? If so, are you saving references to the already materialized objects? Of course, I did not save the image. Otherwise Iâd have understood the behavior. > >> - I reopen the image >> - I fix the bug (i.e., commenting the self error) >> - I re-run the same thing as in the first step >> - An OutOfMemory error appears. >> >> Any clue? >> >> Thanks, >> Roberto > >

March 7, 2014

Re: [Pharo-dev] Is there some shared memory space?

by Max Leske

On 07.03.2014, at 11:55, roberto.minelli(a)usi.ch wrote: > Hi guys, > > I am experiencing a very strange problem that makes me think there is some shared memory problem with Pharo. > > Here are the steps that lead to the problem: > - I have an image, I do something (i.e., materializing objects with Fuel) > - I encounter a problem and a debugger pops up with a âself error: something" > - I close the debugger > - I close the image Do you save the image? If so, are you saving references to the already materialized objects? > - I reopen the image > - I fix the bug (i.e., commenting the self error) > - I re-run the same thing as in the first step > - An OutOfMemory error appears. > > Any clue? > > Thanks, > Roberto

March 7, 2014

Re: [Pharo-dev] [Fuel] Unexpected stream version 19

by Max Leske

On 07.03.2014, at 11:25, roberto.minelli(a)usi.ch wrote: > Hi Max, > > Thanks for the answer in the first place. Besides the âunexpected streamâ, I am also experiencing some weird behavior about memory consumption. > > I have a folder with 70 fuel files, ranging from few kb to 40MB. Each file represents a development session with some of my objects inside. > I have a method that scans that directory, with sub-directories, and materializes all the objects in the image. > > Until last month, this worked like a charm but now, every time I launch it I got an OutOfMemory problem with the VM. Thatâs not goode. I have no idea where that could come from though. Could I get my hands on one of those files that work with 1.9.1 but not with 1.9.3? > > Do you have any idea how this is possible? I tried to increase heap size, pass the âmemory option to the VM, force garbage collection but the problem persists. I also tried to load the old Fuel (1.9.1), the version I was using to export. Still no luck. > > Thanks in advance for any help, > Roberto > > I am experiencing something really wired > On Mar 6, 2014, at 5:33 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Weâve been discussing that and are evaluating different approaches to solving this problem. We are pretty sure (but canât guarantee) that there are no format differences between 1.9 and 1.9.3. So feel free to remove the error and continue. It will probably work (just expect that it might not). >> >> Cheers, >> Max >> >> On 06.03.2014, at 17:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Well, https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3 was just integrated. Why Fuel is so picky about minor versions, and if that matters, I don't know. >>> >>> On 06 Mar 2014, at 17:14, roberto.minelli(a)usi.ch wrote: >>> >>>> Hi, >>>> >>>> I just run into an error while materializing an object with Fuel. Unexpected stream version 19 should be 193. >>>> >>>> Do you have any idea why? I noticed that the fuel #stable version is now 1.9.3 instead of 1.9.1 which was the version I used for export. When I loaded Fuel 1.9.1 despite getting some errors, I managed to import my objects. >>>> >>>> Do you guys have an idea why? >>>> >>>> Thanks in advance, here is the stack trace. >>>> >>>> Roby >>>> >>>> FLMaterializer>>verifyVersionFrom: >>>> FLMaterializer>>materializeFrom: >>>> FLMaterializer class>>materializationFromFileNamed: in Block: [ :aFileStream | self newDefault materializeFrom: ...etc... >>>> StandardFileStream class(FileStream class)>>detectFile:do: in Block: [ anotherBlock value: file ] >>>> BlockClosure>>ensure: >>>> StandardFileStream class(FileStream class)>>detectFile:do: >>>> StandardFileStream class(FileStream class)>>oldFileNamed:do: >>>> FLMaterializer class>>materializationFromFileNamed: >>>> FLMaterializer class>>materializeFromFileNamed: >>>> DFPharoMenu class>>importSessionFromFuelPath: >>>> DFPharoMenu class>>importAllSessionsFromFolder in Block: [ :bar | ... >>>> BlockClosure>>cull: >>>> Job>>run in Block: [ result := block cull: self ] >>>> BlockClosure>>on:do: >>>> Job>>run in Block: [ ... >>>> BlockClosure>>ensure: >>>> Job>>run >>>> MorphicUIManager(UIManager)>>displayProgress:from:to:during: >>>> ByteString(String)>>displayProgressAt:from:to:during: >>>> DFPharoMenu class>>importAllSessionsFromFolder >>>> DFPharoMenu class>>menuCommandOn: in Block: [ self importAllSessionsFromFolder ] >>>> BlockClosure>>cull: >>>> ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... >>>> BlockClosure>>ensure: >>>> CursorWithMask(Cursor)>>showWhile: >>>> ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >>>> ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: >>>> ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: >>>> MouseButtonEvent>>sentTo: >>>> ToggleMenuItemMorph(Morph)>>handleEvent: >>>> >>>> >>>> >>>> >>> >>> >> >> > >

March 7, 2014

Is there some shared memory space?

by roberto.minelli＠usi.ch

Hi guys, I am experiencing a very strange problem that makes me think there is some shared memory problem with Pharo. Here are the steps that lead to the problem: - I have an image, I do something (i.e., materializing objects with Fuel) - I encounter a problem and a debugger pops up with a âself error: something" - I close the debugger - I close the image - I reopen the image - I fix the bug (i.e., commenting the self error) - I re-run the same thing as in the first step - An OutOfMemory error appears. Any clue? Thanks, Roberto

March 7, 2014