August 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Ben Coman

On Mon, Aug 24, 2015 at 6:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I have a *very* strange bug. > > I am trying to add change these three methods in class âTemporaryVariableâ: > (I copy the new version): I'm not clear on what you mean by copy. Do you mean you copied the class to MyTemporaryVariable inside the same package? cheers -ben > > > ensureProperties > method saveTemp: self. > ^ Properties at: self ifAbsentPut: WeakKeyDictionary new > > removePropertiesIfEmpty > ^ Properties at: self ifPresent: [ :dict | > dict ifEmpty: [ > method removeSavedTemp: self. > Properties removeKey: self ] ] > > hash > > ^ (name hash > bitXor: method hash) > bitXor: (startpc ifNil: 0) > > > Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository > of Pharo5, they are shown as different. > > The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension > methods in *slot where the same thing happened, but that was fixed by putting them into *Slot. > > This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors > as local from the package Slot. > > I really have no idea what the problem could be. > > Marcus

Aug. 24, 2015

Re: [Pharo-dev] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Stephan Eggermont

On 24-08-15 00:11, Sean P. DeNigris wrote: > Tudor Girba-2 wrote >> The dependency to Glamour should go through the #stable version > > Yes, ideally. But stable doesn't contain the fixes I want, and given that > the Moose configs have no platform blocks, I assumed that Pharo 5.0-only > code would be committed preventing loading in Pharo 4.0. Again, if I'm > mistaken about any of that, I'd much rather do what you suggested. Yes, you'll need either a separate configuration, #pharo4stablerelease or platform blocks. Platform blocks are most maintainable. Stephan

Aug. 24, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium New Gold Member: Projector Software GmbH

by Sven Van Caekenberghe

Excellent news! > On 24 Aug 2015, at 12:37, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > The Pharo Consortium is very happy to announce that Projector Software GmbH > has joined the Consortium as an Gold Member. > > About > - Projector Software GmbH: http://projector.de > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org > >

Aug. 24, 2015

[ANN] Pharo Consortium New Gold Member: Projector Software GmbH

by Marcus Denker

The Pharo Consortium is very happy to announce that Projector Software GmbH has joined the Consortium as an Gold Member. About - Projector Software GmbH: http://projector.de - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Aug. 24, 2015

Strange Monticello bug: methods are not saved

by Marcus Denker

Hi, I have a *very* strange bug. I am trying to add change these three methods in class âTemporaryVariableâ: (I copy the new version): ensureProperties method saveTemp: self. ^ Properties at: self ifAbsentPut: WeakKeyDictionary new removePropertiesIfEmpty ^ Properties at: self ifPresent: [ :dict | dict ifEmpty: [ method removeSavedTemp: self. Properties removeKey: self ] ] hash ^ (name hash bitXor: method hash) bitXor: (startpc ifNil: 0) Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository of Pharo5, they are shown as different. The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension methods in *slot where the same thing happened, but that was fixed by putting them into *Slot. This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors as local from the package Slot. I really have no idea what the problem could be. Marcus

Aug. 24, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 24, 2015

[pharo-project/pharo-core] 06011e: 50265

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 06011e07ac516a5fc52a69634f8b19db6f6c3b44 https://github.com/pharo-project/pharo-core/commit/06011e07ac516a5fc52a6963… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-24 (Mon, 24 Aug 2015) Changed paths: A Kernel.package/Object.class/instance/displaying/displayString.st A Morphic-Core.package/WorldMorph.class/instance/meta-actions/buildMetaMenu_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50264.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50265.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50264.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50265.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot-Tests.package/TemporaryVariableTest.class/instance/properties/testPropertyAtPutPersistent.st A Slot-Tests.package/TemporaryVariableTest.class/instance/properties/testPropertyBlockPersistent.st A Slot-Tests.package/TemporaryVariableTest.class/instance/properties/testPropertyContextPersistent.st M Slot.package/TemporaryVariable.class/class/instance creation/name_block_.st A Slot.package/TemporaryVariable.class/class/instance creation/name_context_.st M Slot.package/TemporaryVariable.class/class/instance creation/name_method_.st A Slot.package/TemporaryVariable.class/instance/saved temps/yourselfOrSaved.st M Slot.package/extension/BlockClosure/instance/temporaryVariableNamed_.st A Slot.package/extension/CompiledMethod/instance/removeSavedTemp_.st A Slot.package/extension/CompiledMethod/instance/saveTemp_.st A Slot.package/extension/CompiledMethod/instance/savedTemps.st M Slot.package/extension/CompiledMethod/instance/temporaryVariableNamed_.st M Slot.package/extension/Context/instance/temporaryVariableNamed_.st Log Message: ----------- 50265 16175 WorldMorph ctrl+shift+click menu allows for some bad choices https://pharo.fogbugz.com/f/cases/16175 16356 Persistent properties on Temps https://pharo.fogbugz.com/f/cases/16356 16346 Add Object>>displayString https://pharo.fogbugz.com/f/cases/16346 http://files.pharo.org/image/50/50265.zip

Aug. 24, 2015

Re: [Pharo-dev] issue with large file path on windows

by Nicolai Hess

Hi HernÃ¡n Thanks for your feedback 2015-08-24 8:13 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Nicolai > > 2015-08-23 8:44 GMT-03:00 Nicolai Hess <nicolaihess(a)web.de>: > >> For those who had problems with pharo on windows and github based >> repositories, >> I built a windows vm with support for long paths: >> >> >> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >> >> >> For browsing directories with large paths (FileList or Inspect), >> you may need one additional change in the image (But I am not really sure >> about that) : >> >> DiskStore>>initialize >> super initialize. >> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. >> >> >> please test and give feedback. >> >> > Using Win 8.1, I confirm FileList tree now is reading directories beyond > 260 limit, without need to #initialize DiskStore. > > However there should be another concern with GitFileTree uncompression > because loading Aconcagua/Chalten, etc with your new VM in a directory name > with more characters, still signals File not found :( > I tried Aconcagua from Catalogbrowser in pharo 5.0 and it worked for me. Can you show what path is the base path, the working directory of your pharo package-cache/github directory. Is there something special in your path name or the disk? > > Is the VM using the "Unicode-aware API"? According to this guys > http://serverfault.com/questions/163419/window-256-characters-path-name-lim… > such Win Unicode API would let VM to use the 32767 bricks > I am not sure, we are using all file/directory operations that should use the unicode version with multibyte char (CreateFileW / FindFirstFileW / ...) > > > This wasn't as easy as I thought, and I had to make some more changes >> for the file permissions (the stat-functions don't work for files with >> long paths). >> Please test other file/folder operations. >> >> > Thank you Nicolai for your effort, I know it's hard to dive into depths > with C. > > HernÃ¡n > > >> nicolai >> >> >> >> >

Aug. 24, 2015

Re: [Pharo-dev] issue with large file path on windows

by HernÃ¡n Morales Durand

Nicolai 2015-08-23 8:44 GMT-03:00 Nicolai Hess <nicolaihess(a)web.de>: > For those who had problems with pharo on windows and github based > repositories, > I built a windows vm with support for long paths: > > > https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… > > > For browsing directories with large paths (FileList or Inspect), > you may need one additional change in the image (But I am not really sure > about that) : > > DiskStore>>initialize > super initialize. > maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. > > > please test and give feedback. > > Using Win 8.1, I confirm FileList tree now is reading directories beyond 260 limit, without need to #initialize DiskStore. However there should be another concern with GitFileTree uncompression because loading Aconcagua/Chalten, etc with your new VM in a directory name with more characters, still signals File not found :( Is the VM using the "Unicode-aware API"? According to this guys http://serverfault.com/questions/163419/window-256-characters-path-name-lim… such Win Unicode API would let VM to use the 32767 bricks This wasn't as easy as I thought, and I had to make some more changes > for the file permissions (the stat-functions don't work for files with > long paths). > Please test other file/folder operations. > > Thank you Nicolai for your effort, I know it's hard to dive into depths with C. HernÃ¡n > nicolai > > > >

Aug. 24, 2015

Re: [Pharo-dev] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Sean P. DeNigris

Tudor Girba-2 wrote > The dependency to Glamour should go through the #stable version Yes, ideally. But stable doesn't contain the fixes I want, and given that the Moose configs have no platform blocks, I assumed that Pharo 5.0-only code would be committed preventing loading in Pharo 4.0. Again, if I'm mistaken about any of that, I'd much rather do what you suggested. ----- Cheers, Sean -- View this message in context: http://forum.world.st/VoyageMongo-Could-not-resolve-GT-Inspector-GT-Inspect… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 23, 2015