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

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

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

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 |

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

On Fri, Oct 14, 2016 at 1:26 PM, Sean P. DeNigris 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

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

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

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

Hi Sean, On Fri, Oct 14, 2016 at 9:26 AM, Sean P. DeNigris 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

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

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:

Re: [Pharo-dev] About icon: and iconNamed:

> On 14 Oct 2016, at 16:26, Denis Kudriashov wrote: > > > 2016-10-14 16:06 GMT+02:00 Esteban Lorenzano >: > yes, that was me providing a compatibility/traduction layer :) > you will find a couple more of them in the

Re: [Pharo-dev] About icon: and iconNamed:

2016-10-14 16:06 GMT+02:00 Esteban Lorenzano : > yes, that was me providing a compatibility/traduction layer :) > you will find a couple more of them in the image. I call them > “normalisation methods”: they are meant to translate names into something > we can interpret…

Re: [Pharo-dev] About icon: and iconNamed:

yes, that was me providing a compatibility/traduction layer :) you will find a couple more of them in the image. I call them “normalisation methods”: they are meant to translate names into something we can interpret… there is also some like that in the menu building if I remember well :P

Re: [Pharo-dev] About icon: and iconNamed:

Oh!!! I just found this method: iconNamed: aSymbol ifNone: aBlock self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. "Trying the old way" ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ self icons at: (aSymbol allButLast: 4) asSymbol ifPresent: [ :icon | ^

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

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

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

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

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

At least Chrome uses this: file:///C:/Users/tempfile.txt On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure 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

Re: [Pharo-dev] About icon: and iconNamed:

2016-10-13 20:27 GMT+02:00 stepharo : > Denis > > You can have a look the changes I did. There is more work to be done but I > started. > > https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 > Done. New slice committed

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

Hi Hernán, thank you for your report. It would be even nicer if you could report it at https://github.com/npasserini/iceberg/issues I think we might not be far from having Iceberg working on Pharo 5.0. Even we have our tests running on Pharo 6.0 and 5.0 in travis (