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

[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

[pharo-project/pharo-core] 192736: 30791

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 192736e9d416abc4b939b2492fc23e7d5d7e8232 https://github.com/pharo-project/pharo-core/commit/192736e9d416abc4b939b249… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-03-07 (Fri, 07 Mar 2014) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/classRecategorized_.st A OpalCompiler-Core.package/OCSourceCodeChanged.class/README.md A OpalCompiler-Core.package/OCSourceCodeChanged.class/definition.st A OpalCompiler-Core.package/OCSourceCodeChanged.class/instance/accessing/newSourceCode.st A OpalCompiler-Core.package/OCSourceCodeChanged.class/instance/accessing/newSourceCode_.st M OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/openMenuIn_.st R OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/substituteVariableNamed_.st A OpalCompiler-Core.package/OCUndeclaredVariableWarning.class/instance/correcting/substituteVariable_atInterval_.st M OpalCompiler-Core.package/OpalCompiler.class/instance/public access/compile.st R OpalCompiler-Core.package/extension/RBVariableNode/instance/substituteVariableNamed_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script444.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30791.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/extension/PluggableMenuSpec/instance/addToMenuModel_.st M Spec-MorphicAdapters.package/MorphicMenuAdapter.class/instance/private/buildWidgetPopup.st Log Message: ----------- 30791 13043 losing menu title when building menus with spec https://pharo.fogbugz.com/f/cases/13043 12954 Workspace Undeclared variable change broken: missing TextMorphForEditView>>#setText: https://pharo.fogbugz.com/f/cases/12954 13049 Dragging and dropping a class to another package fails: #MNU receiver of includesCategory: is nil https://pharo.fogbugz.com/f/cases/13049 http://files.pharo.org/image/30/30791.zip

March 7, 2014

[pharo-project/pharo-core]

by GitHub

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

March 7, 2014

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

by roberto.minelli＠usi.ch

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. 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

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

by Frank Shearar

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] TWM and 3.0: icons/themes, UpdatingMenuMorph

by phil＠highoctane.be

On Fri, Mar 7, 2014 at 8:17 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > On 06 Mar 2014, at 12:05, phil(a)highoctane.be wrote: > > And of course, the TWMUI Theme doesn't work at all anymore... > > Is there some info about how the new theming works in 3.0? > > > What have been removed are UIManager creation methods (I would have prefer > to have them deprecated we could still do it). > newColumns and others, if I remember correctly > Now for the theming I do not think it changed. > > I have had a look and Morphic-Menus appear to have been removed and we now have Morphic-Base-Menus. All classes in Morphic-Menus appear to be in there, except UpdatingMenuMorph. As I was getting the class back in my 3.0 image, I noticed that drag and drop of classes to other packages led to a #MNU: *https://pharo.fogbugz.com/default.asp?13049 <https://pharo.fogbugz.com/default.asp?13049>* ... and deprecation warnings are nice but not with little windows all over... :-p Putting the UpdatingMenuMorph makes TWM works again. As TWM is the only user of this one, I suggest to put the class in TWM with a TWM prefix. Okay? Phil > TIA > Phil > > > > > On Thu, Mar 6, 2014 at 12:00 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> I am trying to get TWM to work in 3.0 >> >> I use the Metacello config flag "trick" to make it load 2.x things. >> >> Now, things do load but there is the deprecation warnings about the way >> icons are handled. >> >> e.g. >> >> deleteSnapshotIcon >> ^ dock theme smallDeleteIcon. >> >> gives a warning. >> >> I looked into the code and now, we are supposed to do: >> >> Smalltalk ui smallDeleteIcon. >> >> Well, I changed the things that needed to be changed and then hit: >> >> newMenu: aSelector icon: aForm help: aString >> ^ MenuItemMorph new >> contents: ''; >> subMenu: (UpdatingMenuMorph new updater: self updateSelector: >> aSelector); >> icon: aForm; >> setBalloonText: aString. >> >> Where Updating MenuMorph appears to be gone in 3.0 >> >> What am I supposed to use as a replacement? >> >> TIA >> >> Phil >> >> >> > >

March 7, 2014