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

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

by Martin Dias

On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> I have to concur, something very strange is wrong. >> >> #50265 >> >> Load Zinc-Tests-SvenVanCaekenberghe.231 from >> http://mc.stfx.eu/ZincHTTPComponents >> >> ZnEntityTests>>#testUnspecifiedEncoding should have today as latest >> version and it simply does not (the code is wrong too), I can't imagine how >> that is possible. >> >> And this is with loading code ... seems quite dangerous. >> > > Fun: copying Zinc-Tests-SvenVanCaekenberghe.231 to a filetree repo, then > loading from the filetree is correct, at least > for ZnEntityTests>>#testUnspecifiedEncoding > > #50265 > > Strange. Once the MCDefinitions are loaded (repository type dependent, > that), the code path is repository-independent, no? > Strange. Does this happen for all changed methods, or only some of them?

Aug. 24, 2015

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

by Thierry Goubier

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I have to concur, something very strange is wrong. > > #50265 > > Load Zinc-Tests-SvenVanCaekenberghe.231 from > http://mc.stfx.eu/ZincHTTPComponents > > ZnEntityTests>>#testUnspecifiedEncoding should have today as latest > version and it simply does not (the code is wrong too), I can't imagine how > that is possible. > > And this is with loading code ... seems quite dangerous. > Fun: copying Zinc-Tests-SvenVanCaekenberghe.231 to a filetree repo, then loading from the filetree is correct, at least for ZnEntityTests>>#testUnspecifiedEncoding #50265 Strange. Once the MCDefinitions are loaded (repository type dependent, that), the code path is repository-independent, no? Thierry > > > On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > > > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > I'm trying on 50264, and, yes, there is something strange: > > > > Monticello diff only picks up two of the changes, instead of three. > > > > Ok, by reformatting, ended up with exactly the same code for one of them > :( > > > > Saved in the package cache and I have everything saved. > > > > Some suspicious/wrong data in your image? > > > > Thierry > > > > > > Thierry > > > > > > 2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > 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

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

by Thierry Goubier

2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I have to concur, something very strange is wrong. > > #50265 > > Load Zinc-Tests-SvenVanCaekenberghe.231 from > http://mc.stfx.eu/ZincHTTPComponents > > ZnEntityTests>>#testUnspecifiedEncoding should have today as latest > version and it simply does not (the code is wrong too), I can't imagine how > that is possible. > > And this is with loading code ... seems quite dangerous. > Ok. Copying in a filetree repo Zinc-Tests-SvenVanCaekenberghe.231 nets me this code testing testUnspecifiedEncoding | json bytes entity | json := '{"text":"Der Weg zur HÃ¶lle ist mit guten VorsÃ¤tzen gepflastert."}'. entity := ZnEntity with: json type: ZnMimeType applicationJson setCharSetUTF8. bytes := entity asByteArray. ZnDefaultCharacterEncoder value: ZnUTF8Encoder new during: [ entity := ZnEntity readFrom: bytes readStream usingType: ZnMimeType applicationJson andLength: nil. self assert: entity contents equals: json. entity := ZnEntity with: json type: ZnMimeType applicationJson. self assert: entity encoder equals: ZnUTF8Encoder new ] and that timestamp: "testUnspecifiedEncoding" : "SvenVanCaekenberghe 8/24/2015 14:30", But, yes, loading in the image nets me an older version: 5/4/2014, is that what you have? Looks like the MC side is correct (i.e. there is a correct MCMethodDefinition in the system). Has something changed related to code or methods comparisons recently? Thierry > > > On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > > > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > I'm trying on 50264, and, yes, there is something strange: > > > > Monticello diff only picks up two of the changes, instead of three. > > > > Ok, by reformatting, ended up with exactly the same code for one of them > :( > > > > Saved in the package cache and I have everything saved. > > > > Some suspicious/wrong data in your image? > > > > Thierry > > > > > > Thierry > > > > > > 2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > 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

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

by Nicolai Hess

2015-08-24 13:34 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > And If you want to review the changes: > > > https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… > > > 2015-08-23 13:44 GMT+02: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. >> >> 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. >> >> >> nicolai >> >> >> >> > > Thank you Henrik, for looking at this > + #define CONVERT_MULTIBYTE_TO_WIDECHAR_PATH(buffer, size, > fileNameString, fileNameLength) { \+ buffer = (WCHAR*)alloca((size+4+1)* > sizeof(WCHAR));\+ buffer[0] = L'\\';buffer[1] = L'\\'; buffer[2] = L'?'; > buffer[3] = L'\\';\+ MultiByteToWideChar(CP_UTF8, 0, fileNameString, > fileNameLength, buffer + 4, size);\+ buffer[size + 4] = 0;\+ size += 4;} > > > - Is an alloca version really worth it for the potential problems? > It is what Marcel used for the long path support in the squeak vm (I would have copy and paste the whole change, but I couldn't find the appropriate change for directory functions). > - Also, LONG_PATH_PREFIX_SIZE is defined above in the header, should > probably use this instead of 4 in the last two lines? > Yes > - The comment on lines 111/164/265/381, while not modified, are somewhat > incorrect, null-terminated C-string indicates UTF8, which we are converting > from, not into. > Right, I ll chang that > > I'm curious what the "\\?\" prefix does to hasCaseSensitiveDuplicate > (adding a new ? segment to the path), but I cba to understand that code, > and considering > int caseSensitiveFileMode = 0; > if(!caseSensitiveFileMode) return 0; > > I guess it doesn't really matter. > Yes, I tried to make this change in a way that does not break the case sensitive duplicate check, but even without my change, enabling the caseSenstiveFileMode makes the windows vm unusable. So, at least, it is no worse. > > Otherwise, looks good to me! > > Cheers, > Henry >

Aug. 24, 2015

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

by Sven Van Caekenberghe

I have to concur, something very strange is wrong. #50265 Load Zinc-Tests-SvenVanCaekenberghe.231 from http://mc.stfx.eu/ZincHTTPComponents ZnEntityTests>>#testUnspecifiedEncoding should have today as latest version and it simply does not (the code is wrong too), I can't imagine how that is possible. And this is with loading code ... seems quite dangerous. > On 24 Aug 2015, at 13:30, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > I'm trying on 50264, and, yes, there is something strange: > > Monticello diff only picks up two of the changes, instead of three. > > Ok, by reformatting, ended up with exactly the same code for one of them :( > > Saved in the package cache and I have everything saved. > > Some suspicious/wrong data in your image? > > Thierry > > > Thierry > > > 2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > 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

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

by Norbert Hartl

Great!! Norbert > Am 24.08.2015 um 12:37 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > > 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

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

by phil＠highoctane.be

It is nice to see the types of projects. Phil Le 24 aoÃ»t 2015 12:56, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > 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

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

by Henrik Johansen

> On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > And If you want to review the changes: > > https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… <https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo…> > > > 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@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… <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. > > 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. > > > nicolai > > > > + #define CONVERT_MULTIBYTE_TO_WIDECHAR_PATH(buffer, size, fileNameString, fileNameLength) { \ + buffer = (WCHAR*)alloca((size+4+1)*sizeof(WCHAR));\ + buffer[0] = L'\\';buffer[1] = L'\\'; buffer[2] = L'?'; buffer[3] = L'\\';\ + MultiByteToWideChar(CP_UTF8, 0, fileNameString, fileNameLength, buffer + 4, size);\ + buffer[size + 4] = 0;\ + size += 4;} - Is an alloca version really worth it for the potential problems? - Also, LONG_PATH_PREFIX_SIZE is defined above in the header, should probably use this instead of 4 in the last two lines? - The comment on lines 111/164/265/381, while not modified, are somewhat incorrect, null-terminated C-string indicates UTF8, which we are converting from, not into. I'm curious what the "\\?\ <smb://?/>" prefix does to hasCaseSensitiveDuplicate (adding a new ? segment to the path), but I cba to understand that code, and considering int caseSensitiveFileMode = 0; if(!caseSensitiveFileMode) return 0; I guess it doesn't really matter. Otherwise, looks good to me! Cheers, Henry

Aug. 24, 2015

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

by Thierry Goubier

2015-08-24 13:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > I'm trying on 50264, and, yes, there is something strange: > > Monticello diff only picks up two of the changes, instead of three. > Ok, by reformatting, ended up with exactly the same code for one of them :( Saved in the package cache and I have everything saved. Some suspicious/wrong data in your image? Thierry > > Thierry > > > 2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> 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

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

by Thierry Goubier

I'm trying on 50264, and, yes, there is something strange: Monticello diff only picks up two of the changes, instead of three. Thierry 2015-08-24 12:05 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > 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