- Pharo-dev - lists.pharo.org

[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

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

by Max Leske

On 07.03.2014, at 09:37, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 07/03/2014 09:25, Max Leske a Ã©crit : >> >>> >>> I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. >> >> Is it on Smalltalkhub? Iâd like to take a look if you let me. > > It's on github :) I should have knownâ¦ :) > > https://github.com/ThierryGoubier/AltBrowser/tree/pharo3.0/Alt-Browser.pack… > > and the git interface lives inside gitfiletree, at: > > https://github.com/dalehenrich/filetree/blob/issue_124/repository/Monticell… > > Also available via ConfigurationOfGitFileTree. > > I'd be especially interested to know if, the way you're planning to do it, will allow to: > > - Better track methods among class renames, package renames, ownership in packages and so on: mine I think get the commits for all versions of a method right, but is limited in its ability to find them through renames (since each version path name may be different from the current one). Ummmmâ¦ Iâll have to see about thatâ¦ ^^ But Iâll definitely let you know. > > - 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. > > 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 Goubier Thierry

Le 07/03/2014 09:25, Max Leske a Ã©crit : > >> >> I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. > > Is it on Smalltalkhub? Iâd like to take a look if you let me. It's on github :) https://github.com/ThierryGoubier/AltBrowser/tree/pharo3.0/Alt-Browser.pack… and the git interface lives inside gitfiletree, at: https://github.com/dalehenrich/filetree/blob/issue_124/repository/Monticell… Also available via ConfigurationOfGitFileTree. I'd be especially interested to know if, the way you're planning to do it, will allow to: - Better track methods among class renames, package renames, ownership in packages and so on: mine I think get the commits for all versions of a method right, but is limited in its ability to find them through renames (since each version path name may be different from the current one). - And be able to rebuild package version history via the VCS history, as I do now in gitfiletree. 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 Max Leske

On 07.03.2014, at 09:08, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 06/03/2014 23:01, Max Leske a Ã©crit : >> >> On 06.03.2014, at 22:14, Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>> wrote: >>> the tail wags the dog. if the diff facilities in things like git were >>> well-designed they'd be pluggable and allow one to parse files into >>> meaningful chunks. > > Can be done for git diffing and large files, so no need to push the blame on git. We just need someone to write the tools in Smalltalk. > >>> But why do you need command-line diff tools? >> >> We donât. Diffing has nothing to do with this (or only little). But if a >> method has its own file, then the hash of that method will be stable as >> long as it is unchanged, regardless of the number of commits it is >> referenced by. This makes it very easy to identify the changes that have >> been made to a particular method. How these changes are *visualized* is >> a different matter (and I would like to have a nice GUI for that too). > > I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. Is it on Smalltalkhub? Iâd like to take a look if you let me. > > 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 Max Leske

On 07.03.2014, at 09:01, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 06/03/2014 17:30, Max Leske a Ã©crit : >> >> >> That is only partly true: >> - packs will be generated when objects are transferred over the network (this may be partial packs) >> - packs can be force generated by using âgit gcâ >> - packs will be periodically created / updated to reduce size on disk > > Are you free, when fetching a git repository, to decide whether to pack or not or is the source repository in charge of that? Network transfer is always packed. > > Past a certain point, you can expect all/most of your small files (and small deltas) to be packed, no? No, unless you impelement something like post hook to force âgit gcâ. New / changed objects will be stored as loose objects. If you consider a large repository, than maybe âthe larger partâ of all objects may be packed (objects that are only read) but that very much depends on the usage of the repository (e.g. if you have to compile stuff there will be tons of new objects every time). > >> But: the main storage form (and the fastest for access) are loose objects (i.e. single files) > > But you have to support both storage form to be able to read a git repository. Yes. Thatâs a bit of a downside. But it makes things interesting :) > >> Just for completeness :) > > You known certainly more about that than I do :) Well, I should, considering the amount of time Iâve spent with Git (and itâs totally useless âthis is an excerpt from the IRC where Linus explains how Git really worksâ documentationâ¦) :p Max > > 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 Max Leske

On 07.03.2014, at 08:38, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > I hope that somebody will have a look at the newspeak library that abstract from the back-end storage because this is an interesting idea. Noted. > >> >> >> On Thu, Mar 6, 2014 at 12:18 PM, 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. >> >> the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks. >> >> But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems. >> >> The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO. >> >> >> 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 ... >> >> 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 >> >> >> >> >> -- >> best, >> Eliot >

March 7, 2014