- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Path >> fullName should not be the same as printString

by stepharo

so how can we make progress? Stef Le 14/10/16 Ã 14:57, Damien Pollet a Ã©crit : > While we're at it, canonicalizing paths at creation time seems wrong > also: > > First because those two expressions do not return the same thing: > Path from: 'a/b/c/../d' > Path * / 'a' / 'b' / 'c' / '..' / 'd' > > Second because if c happens to be a symlink, then the operating system > will not find the same thing as Pharo. The semantics is that you > follow the symlink first, and follow .. in the directory you end up > in. So that goes to the parent of the actual directory pointed to by > the symlink, not back one level in the path. > > On 14 October 2016 at 13:59, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > All this already works (although maybe not perfectly in edge > cases). Consider: > > 'file:///C:/Users/tempfile.txt' asUrl. > > 'file:///C:/Users/tempfile.txt' asUrl asFileReference. > > FileLocator C / 'Users' / 'tmpfile.txt'. > > Where the last two are identical. > > Note that relative file URLs do not exist. > > > On 14 Oct 2016, at 13:28, Gabriel Cotelli <g.cotelli(a)gmail.com > <mailto:g.cotelli@gmail.com>> wrote: > > > > At least Chrome uses this: > > > > file:///C:/Users/tempfile.txt > > > > On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure > <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>> wrote: > > On 10/13/2016 10:35 AM, Damien Pollet wrote: > > Could you give an example what the file:// URLs look like when > they contain a drive letter? > > > > I'm afraid I don't have any Windows machines handy to see what > Internet Explorer does, but as far as I can tell an absolute URL > compliant with RFC 3986 might look something like > > > > file:/c:/foo/bar > > > > A relative URL that fits the URL syntax would be > > > > file:c:/foo/bar > > > > But I'm finding it difficult to tell precisely how RFCs 1738 and > 3986 currently interact. > > > > The discussion in this proposed RFC is somewhat interesting: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02 > <https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02>, > as it directly addresses Windows file naming. In appendix B.2, it says > > > > "When mapping a DOS- or Windows-like file path to a URI, use the > drive > > letter (e.g. "c:") as the first path segment. Some > implementations leave the leading slash off before the drive > letter. " > > > > and appendix C.1 deals with DOS file paths. > > > > > > I hope this is more helpful than it is confusing. > > > > Regards, > > > > -Martin > > > > > > > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 15, 2016

Re: [Pharo-dev] [ANN] New release of iceberg

by stepharo

+ 1 This is on my todo :) Le 13/10/16 Ã 20:37, Tudor Girba a Ã©crit : > Hi Nicolas, > > Great work! > > I will test it again. I kindly ask everyone else to follow the call and test this release. Ideally, create a repository on GitHub and play with it. > > It is important to get this piece as stable as possible to make Git part of the default Pharo experience. > > Cheers, > Doru > > >> On Oct 13, 2016, at 2:25 PM, Nicolas Passerini <npasserini(a)gmail.com> wrote: >> >> Hi, we are releasing a new version of Iceberg, with several new features and bugfixes. I would't yet say that is 100% production ready, but it is close, so I want to invite you to test it and provide feedback. >> >> You can install it by doing: >> >> Metacello new >> baseline: 'Iceberg'; >> repository: 'github://npasserini/iceberg'; >> load. >> >> More installation instructions and documentation can be found at https://github.com/npasserini/iceberg. >> >> Some of the new features in this version are: >> - Allow to commit several packages together in the same commit. >> - Show diffs for incoming and outgoing commits (i.e. before push/pull you can browse the difference between the remote and the local versions). >> - New History view allows to see any commit in any branch and compare it to the current loaded version. >> - Better support for interacting code loaded outside Iceberg (smaltalkhub, filetree, gitfiletree, etc). >> - From the diff view, revert changes or browse them (i.e. open a Nautilus on the changed class/method). >> - Automatically update presentations on code / repository changes. >> - Integration with Metacello, i.e. after installing Iceberg you do something like >> >> Metacello new >> >> >> baseline: 'TaskIt' >> ; >> >> repository: 'github://sbragagnolo/taskit' >> ; >> load. >> >> >> (By default) it will be loaded using iceberg (there is a setting to avoid it if you prefer traditional behavior. >> >> - Improved handling of git errors. >> - Improved performance for several operations. >> - Improved documentation. >> - ... and several bug fixes and other minor improvements (please look at https://github.com/npasserini/iceberg/milestone/7?closed=1 for more details). >> >> >> Please do not hesitate to contact me if you have any doubts. > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > >

Oct. 15, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sven Van Caekenberghe

AFAIU, Fuel is not capable working across versions, let alone over the non-spur/spur divide. It's a let down, but it is by design (to optimise for absolute speed). > On 15 Oct 2016, at 05:46, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Eliot Miranda-2 wrote >> Is that character code legal unicode? > > No, but that turned out to be a red herring! > > This simple experiment seems to show a fundamental problem when serializing > in 4.0 (non-spur) and materializing in 5.0 (spur): > > FileStream forceNewFileNamed: filename do: [:aFile | > FLSerializer newDefault > serialize: ($e) on: aFile binary ] . > > FLMaterializer materializeFromFileNamed: filename. > > Doing the serialization and materialization in the same 4.0 image works, but > materializing in a 5.0 image throws an error (a different one this time - > "MessageNotUnderstood: receiver of ""adaptToNumber:andSend:"" is nil") > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4918909.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 15, 2016

Re: [Pharo-dev] [squeak-dev] Re: large images

by John Brant

The time I was talking about was the time to quit the image without saving. This time seems to be dependent on the size of the image. For example, a 100MB image quits almost immediately, but a couple GB one takes 5 or so seconds and my 7GB one was taking ~15 seconds. John Brant On 10/14/2016 05:34 PM, David T. Lewis wrote: > Hi, > > Let's measure where the time is going before we fix it. I have saved V3 images > of that size and more, and it takes a very long time to write the image file > independent of any GC or finalization actions that need to happen. We should > measure this on a large Spur image save, but I suspect that the dominant factor > will turn out to be the time that it takes to flush all those gigabytes out > to storage. Garbage collection and finalization actions might be just round-off > error. > > Dave > > > On Fri, Oct 14, 2016 at 08:29:13AM -0700, Eliot Miranda wrote: >> Hi Both, >> >> let me try again :-/ >> >>> On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Nice! >>> >>> I put Eliot in CC :). >>> >>> @Eliot: John was playing with some large images and I asked him if he could save/load to see what happens. The report is below. Nice job :). >>> >>> Doru >>> >>> >>>> On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> wrote: >>>> >>>> I loaded my model (6.8GiB on linux), saved the image (7.2GB), and started the image. It all worked. It took a few minutes to load the image, but it worked. It takes ~15 seconds to quit an image that large. I'm not sure what quit is doing, but it appears to be dependent on the image size. >> >> Regrettably the squeak vm does a full gc on snapshot, and then, unavoidably, it does a scan of all contexts in the heap, changing any with machine code pcs to have bytecode pcs so that the image can be restarted on a different version/platform. It then writes the heap segments to the file. >> >> I guess the scan could be folded into the gc. This is a long time to wait! >> >> The gc makes sense only as a way of voiding new space; image loading is simplified only having to load old space segments. It does /not/ make sense semantically because and finalization actions it triggers cannot be responded to until after the snapshot. >> >> Instead, it makes much more sense for the image to invoke a full gc immediately prior to snapshot, and drain the finalization queue (something I guess will happen implicitly due to finalization process priority). This means that expected finalization activities such as flushing and closing output files will actually take place. The existing architecture effectively throws these actions away. >> >> Both squeak and pharo communities could do well to discuss this and agree on an approach. >> >> >>>> >>>> >>>> John Brant >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >

Oct. 15, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

Eliot Miranda-2 wrote > Is that character code legal unicode? No, but that turned out to be a red herring! This simple experiment seems to show a fundamental problem when serializing in 4.0 (non-spur) and materializing in 5.0 (spur): FileStream forceNewFileNamed: filename do: [:aFile | FLSerializer newDefault serialize: ($e) on: aFile binary ] . FLMaterializer materializeFromFileNamed: filename. Doing the serialization and materialization in the same 4.0 image works, but materializing in a 5.0 image throws an error (a different one this time - "MessageNotUnderstood: receiver of ""adaptToNumber:andSend:"" is nil") ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4918909.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 15, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Mariano Martinez Peck

On Fri, Oct 14, 2016 at 1:26 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I serialized an object graph with lots of Chinese characters in Pharo 4.0. > I > have been able to rematerialize it back into Pharo 4.0. However, when I try > to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive > #value: in Character class failed" from `Character class>>#value: > 1310876005`. The only difference immediately apparent is the VM (both via > Launcher; details below). > > More generally, I'm interested in debugging techniques for Fuel. How would > I > drill down and isolate the problem? > > There is some info here: http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging?_… > Thanks! > > 5.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > > VS. > > 4.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/Resources/vm/40/ > Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM- > Bug-for-Chinese-Characters-tp4918883.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Oct. 15, 2016

Re: [Pharo-dev] [squeak-dev] Re: large images

by David T. Lewis

Hi, Let's measure where the time is going before we fix it. I have saved V3 images of that size and more, and it takes a very long time to write the image file independent of any GC or finalization actions that need to happen. We should measure this on a large Spur image save, but I suspect that the dominant factor will turn out to be the time that it takes to flush all those gigabytes out to storage. Garbage collection and finalization actions might be just round-off error. Dave On Fri, Oct 14, 2016 at 08:29:13AM -0700, Eliot Miranda wrote: > Hi Both, > > let me try again :-/ > > > On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Nice! > > > > I put Eliot in CC :). > > > > @Eliot: John was playing with some large images and I asked him if he could save/load to see what happens. The report is below. Nice job :). > > > > Doru > > > > > >> On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> wrote: > >> > >> I loaded my model (6.8GiB on linux), saved the image (7.2GB), and started the image. It all worked. It took a few minutes to load the image, but it worked. It takes ~15 seconds to quit an image that large. I'm not sure what quit is doing, but it appears to be dependent on the image size. > > Regrettably the squeak vm does a full gc on snapshot, and then, unavoidably, it does a scan of all contexts in the heap, changing any with machine code pcs to have bytecode pcs so that the image can be restarted on a different version/platform. It then writes the heap segments to the file. > > I guess the scan could be folded into the gc. This is a long time to wait! > > The gc makes sense only as a way of voiding new space; image loading is simplified only having to load old space segments. It does /not/ make sense semantically because and finalization actions it triggers cannot be responded to until after the snapshot. > > Instead, it makes much more sense for the image to invoke a full gc immediately prior to snapshot, and drain the finalization queue (something I guess will happen implicitly due to finalization process priority). This means that expected finalization activities such as flushing and closing output files will actually take place. The existing architecture effectively throws these actions away. > > Both squeak and pharo communities could do well to discuss this and agree on an approach. > > > >> > >> > >> John Brant > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Every thing has its own flow." > > > > > > > > > >

Oct. 15, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Martin Dias

Hi Sean, You can debug the answer of #serialize:, which has information. If you suspect of certain objects you could configure the serializer before serialization with #when:substituteBy: to filter them or something like that. Martin On Fri, Oct 14, 2016 at 1:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Sean, > > > > On Fri, Oct 14, 2016 at 9:26 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> I serialized an object graph with lots of Chinese characters in Pharo >> 4.0. I >> have been able to rematerialize it back into Pharo 4.0. However, when I >> try >> to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive >> #value: in Character class failed" from `Character class>>#value: >> 1310876005`. The only difference immediately apparent is the VM (both via >> Launcher; details below). >> > > Spur allows 30-bit unsigned character codes, so the max character code is > 1073741823, or 16r3FFFFFFF. So your character value is out of range. > Character class>>#value: reds better commentary. The limit cannot be > raised; there are only 30 bits available for immediate character values. > Is that character code legal unicode? > > More generally, I'm interested in debugging techniques for Fuel. How would >> I >> drill down and isolate the problem? >> >> Thanks! >> >> 5.0 VM: >> Virtual Machine >> --------------- >> /Applications/Pharo.app/Contents/MacOS/Pharo >> CoInterpreter VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> https://github.com/pharo-project/pharo-vm.git Commit: >> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >> >> Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< >> VMMaker versionString https://github.com/pharo-project/pharo-vm.git >> Commit: >> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >> CoInterpreter VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> >> VS. >> >> 4.0 VM: >> Virtual Machine >> --------------- >> /Applications/Pharo.app/Contents/Resources/vm/40/Pharo.app/ >> Contents/MacOS/Pharo >> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> https://github.com/pharo-project/pharo-vm.git Commit: >> 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 >> >> Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< >> VMMaker versionString https://github.com/pharo-project/pharo-vm.git >> Commit: >> 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 >> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Spur-VM- >> Bug-for-Chinese-Characters-tp4918883.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Oct. 14, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Eliot Miranda

Hi Sean, On Fri, Oct 14, 2016 at 9:26 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I serialized an object graph with lots of Chinese characters in Pharo 4.0. > I > have been able to rematerialize it back into Pharo 4.0. However, when I try > to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive > #value: in Character class failed" from `Character class>>#value: > 1310876005`. The only difference immediately apparent is the VM (both via > Launcher; details below). > Spur allows 30-bit unsigned character codes, so the max character code is 1073741823, or 16r3FFFFFFF. So your character value is out of range. Character class>>#value: reds better commentary. The limit cannot be raised; there are only 30 bits available for immediate character values. Is that character code legal unicode? More generally, I'm interested in debugging techniques for Fuel. How would I > drill down and isolate the problem? > > Thanks! > > 5.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > > VS. > > 4.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/Resources/vm/40/ > Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM- > Bug-for-Chinese-Characters-tp4918883.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- _,,,^..^,,,_ best, Eliot

Oct. 14, 2016

Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

I serialized an object graph with lots of Chinese characters in Pharo 4.0. I have been able to rematerialize it back into Pharo 4.0. However, when I try to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive #value: in Character class failed" from `Character class>>#value: 1310876005`. The only difference immediately apparent is the VM (both via Launcher; details below). More generally, I'm interested in debugging techniques for Fuel. How would I drill down and isolate the problem? Thanks! 5.0 VM: Virtual Machine --------------- /Applications/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 VS. 4.0 VM: Virtual Machine --------------- /Applications/Pharo.app/Contents/Resources/vm/40/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 14, 2016