- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...

by Tudor Girba

Hi, The post is important for advertisement. Thanks ClÃ©ment! The work is important for our future. Thanks Eliot! Doru On Fri, Feb 7, 2014 at 7:58 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Thanks Clement for the post and a big thank you to Eliot for Spur! > Can't wait for pharo 4 running on Spur-based Cog ;-) > > Luc > > 2014-02-07 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > 2014-02-06 20:34 GMT+01:00 Sebastian Sastre <sebastian(a)flowingconcept.com> >> : >> >> Thanks for this information. >>> >>> Great post. >>> >>> So larger images would be no problem? let's say growing to 900MB? >>> >> >> I wouldn't say no problem, I would say that images up to 1 Gb should be >> usable and should behave much better than they used to due to the lack of >> full GC pauses. Now that's the theory we need to make it real and this >> summer we will see... >> >> >>> >>> >>> >>> >>> On Feb 6, 2014, at 12:48 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> >>> Hello pharoers, >>> >>> The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM >>> that some of you were interested in it, but unfortunately you were lacking >>> information about it. >>> >>> I wrote a one page article that sums up Spur's new features so every one >>> can know what will be better. There's no VM technical details here, it's >>> just about what will change for a regular pharo user. >>> >>> >>> http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me… >>> >>> Let me know if you think I forgot yet another feature. >>> >>> If you have questions, I'll try to answer, but ask Eliot, he implemented >>> Spur so he can answer your questions much better than I can :-). >>> >>> Regards, >>> >>> ClÃ©ment >>> >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 7, 2014

Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...

by Luc Fabresse

Thanks Clement for the post and a big thank you to Eliot for Spur! Can't wait for pharo 4 running on Spur-based Cog ;-) Luc 2014-02-07 ClÃ©ment Bera <bera.clement(a)gmail.com>: > 2014-02-06 20:34 GMT+01:00 Sebastian Sastre <sebastian(a)flowingconcept.com> > : > > Thanks for this information. >> >> Great post. >> >> So larger images would be no problem? let's say growing to 900MB? >> > > I wouldn't say no problem, I would say that images up to 1 Gb should be > usable and should behave much better than they used to due to the lack of > full GC pauses. Now that's the theory we need to make it real and this > summer we will see... > > >> >> >> >> >> On Feb 6, 2014, at 12:48 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Hello pharoers, >> >> The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM >> that some of you were interested in it, but unfortunately you were lacking >> information about it. >> >> I wrote a one page article that sums up Spur's new features so every one >> can know what will be better. There's no VM technical details here, it's >> just about what will change for a regular pharo user. >> >> >> http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me… >> >> Let me know if you think I forgot yet another feature. >> >> If you have questions, I'll try to answer, but ask Eliot, he implemented >> Spur so he can answer your questions much better than I can :-). >> >> Regards, >> >> ClÃ©ment >> >> >> >

Feb. 7, 2014

Re: [Pharo-dev] how does zip filesystem work?

by Tudor Girba

One more question: How do I read the contents of a file from within a zip? I try this on regular zip files created both on Mac and on Windows: zipFile := FileSystem disk workingDirectory / 'tmp.zip'. zip := (FileSystem zip: zipFile) open. (zip / 'sample.txt') readStreamDo: [ :s | s contents ] The problem is that I get an encoded stream. How do I decode it? Doru On Fri, Feb 7, 2014 at 6:34 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > And I found another problem. Even with the fix, it seems you cannot close > the zip file. For example: > > zipFile := FileSystem disk workingDirectory / 'test.zip'. > zip := (FileSystem zip: zipFile) open. > zip / 'sample.txt' > writeStreamDo: [ :stream | stream nextPutAll: 'xyz' ]. > zip close > > I think the code should be correct. > > Cheers, > Doru > > > > > On Fri, Feb 7, 2014 at 5:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Ok. >> >> I added an initial slice with the quick fix solution: >> https://pharo.fogbugz.com/f/cases/12826/Zip-FileSystem-does-not-work >> >> Could someone double check? >> >> Do we want to work more on it for Pharo 3.0? >> >> Cheers, >> Doru >> >> >> >> >> On Thu, Feb 6, 2014 at 4:37 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Yeah I know... It's all just one big hack at the moment (I'm not >>> particularly proud of #binaryReadStream either...). Again: let's hope that >>> XStreams will solve all our problems :) >>> >>> >>> On 06.02.2014, at 15:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> > >>> > On 06 Feb 2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: >>> > >>> >> No, not my bug :) >>> >> >>> >> The problem seems to be that WriteStream expects #size to be >>> implemented but MemoryFileSystemFile only knows #fileSize. Apart from that >>> I think it would work. >>> > >>> > But again, this is a problem (of the (G)Zip implementation) regarding >>> the stream API. Certain stream, like network or serial streams, cannot >>> respond to size in all conditions. >>> > >>> >> Add this to MemoryFileSystemFile (not as a final solution!): >>> >> >>> >> size >>> >> ^ bytes size >>> >> >>> >> Cheers, >>> >> Max >>> >> >>> >> On 06.02.2014, at 15:22, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >> >>> >>> Thanks, Max. >>> >>> >>> >>> Doru >>> >>> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Max Leske <maxleske(a)gmail.com> >>> wrote: >>> >>> On 06.02.2014, at 15:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> >>> >>>> I am trying to get the ZipFileSystem to work, but I cannot quite >>> manage it. >>> >>>> >>> >>>> I am doing this: >>> >>>> (FileSystem zip: >>> >>>> (FileSystem disk workingDirectory / 'sample.zip')) >>> >>>> open >>> >>>> >>> >>>> and I get an error. >>> >>>> >>> >>>> The error comes from the fact that the code uses readStreamDo: >>> which does not work anymore with binary streams. I tried to use >>> binaryReadStreamDo:, but that crashes in another place. >>> >>>> >>> >>>> I think this is a bug. Or am I doing something wrong? >>> >>> >>> >>> You shouldn't be... I'll take a look later since that would be me who >>> introduced the bug (probably). >>> >>> >>> >>>> >>> >>>> Cheers, >>> >>>> Doru >>> >>>> >>> >>>> -- >>> >>>> www.tudorgirba.com >>> >>>> >>> >>>> "Every thing has its own flow" >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> www.tudorgirba.com >>> >>> >>> >>> "Every thing has its own flow" >>> >> >>> > >>> > >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 7, 2014

Re: [Pharo-dev] how does zip filesystem work?

by Tudor Girba

And I found another problem. Even with the fix, it seems you cannot close the zip file. For example: zipFile := FileSystem disk workingDirectory / 'test.zip'. zip := (FileSystem zip: zipFile) open. zip / 'sample.txt' writeStreamDo: [ :stream | stream nextPutAll: 'xyz' ]. zip close I think the code should be correct. Cheers, Doru On Fri, Feb 7, 2014 at 5:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Ok. > > I added an initial slice with the quick fix solution: > https://pharo.fogbugz.com/f/cases/12826/Zip-FileSystem-does-not-work > > Could someone double check? > > Do we want to work more on it for Pharo 3.0? > > Cheers, > Doru > > > > > On Thu, Feb 6, 2014 at 4:37 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Yeah I know... It's all just one big hack at the moment (I'm not >> particularly proud of #binaryReadStream either...). Again: let's hope that >> XStreams will solve all our problems :) >> >> >> On 06.02.2014, at 15:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> > >> > On 06 Feb 2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: >> > >> >> No, not my bug :) >> >> >> >> The problem seems to be that WriteStream expects #size to be >> implemented but MemoryFileSystemFile only knows #fileSize. Apart from that >> I think it would work. >> > >> > But again, this is a problem (of the (G)Zip implementation) regarding >> the stream API. Certain stream, like network or serial streams, cannot >> respond to size in all conditions. >> > >> >> Add this to MemoryFileSystemFile (not as a final solution!): >> >> >> >> size >> >> ^ bytes size >> >> >> >> Cheers, >> >> Max >> >> >> >> On 06.02.2014, at 15:22, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> >> >>> Thanks, Max. >> >>> >> >>> Doru >> >>> >> >>> >> >>> On Thu, Feb 6, 2014 at 3:11 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> On 06.02.2014, at 15:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> >> >>>> I am trying to get the ZipFileSystem to work, but I cannot quite >> manage it. >> >>>> >> >>>> I am doing this: >> >>>> (FileSystem zip: >> >>>> (FileSystem disk workingDirectory / 'sample.zip')) >> >>>> open >> >>>> >> >>>> and I get an error. >> >>>> >> >>>> The error comes from the fact that the code uses readStreamDo: which >> does not work anymore with binary streams. I tried to use >> binaryReadStreamDo:, but that crashes in another place. >> >>>> >> >>>> I think this is a bug. Or am I doing something wrong? >> >>> >> >>> You shouldn't be... I'll take a look later since that would be me who >> introduced the bug (probably). >> >>> >> >>>> >> >>>> Cheers, >> >>>> Doru >> >>>> >> >>>> -- >> >>>> www.tudorgirba.com >> >>>> >> >>>> "Every thing has its own flow" >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> >> >>> "Every thing has its own flow" >> >> >> > >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 7, 2014

Re: [Pharo-dev] how does zip filesystem work?

by Tudor Girba

Ok. I added an initial slice with the quick fix solution: https://pharo.fogbugz.com/f/cases/12826/Zip-FileSystem-does-not-work Could someone double check? Do we want to work more on it for Pharo 3.0? Cheers, Doru On Thu, Feb 6, 2014 at 4:37 PM, Max Leske <maxleske(a)gmail.com> wrote: > Yeah I know... It's all just one big hack at the moment (I'm not > particularly proud of #binaryReadStream either...). Again: let's hope that > XStreams will solve all our problems :) > > > On 06.02.2014, at 15:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 06 Feb 2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: > > > >> No, not my bug :) > >> > >> The problem seems to be that WriteStream expects #size to be > implemented but MemoryFileSystemFile only knows #fileSize. Apart from that > I think it would work. > > > > But again, this is a problem (of the (G)Zip implementation) regarding > the stream API. Certain stream, like network or serial streams, cannot > respond to size in all conditions. > > > >> Add this to MemoryFileSystemFile (not as a final solution!): > >> > >> size > >> ^ bytes size > >> > >> Cheers, > >> Max > >> > >> On 06.02.2014, at 15:22, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >>> Thanks, Max. > >>> > >>> Doru > >>> > >>> > >>> On Thu, Feb 6, 2014 at 3:11 PM, Max Leske <maxleske(a)gmail.com> wrote: > >>> On 06.02.2014, at 15:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> > >>>> I am trying to get the ZipFileSystem to work, but I cannot quite > manage it. > >>>> > >>>> I am doing this: > >>>> (FileSystem zip: > >>>> (FileSystem disk workingDirectory / 'sample.zip')) > >>>> open > >>>> > >>>> and I get an error. > >>>> > >>>> The error comes from the fact that the code uses readStreamDo: which > does not work anymore with binary streams. I tried to use > binaryReadStreamDo:, but that crashes in another place. > >>>> > >>>> I think this is a bug. Or am I doing something wrong? > >>> > >>> You shouldn't be... I'll take a look later since that would be me who > introduced the bug (probably). > >>> > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Every thing has its own flow" > >>> > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >> > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 7, 2014

Re: [Pharo-dev] Fwd: working on pharo 3.0?

by Tudor Girba

It seems that the jobs do not manage to finish :( Doru On Thu, Feb 6, 2014 at 1:47 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > The ci jobs :). I didn't want to announce them (and actually i didn't do > it properly) until having them finished at some good degree. > > The ci jobs for dbxtalk will give the people doing dbxtalk so muuuuch air > (no more manual testing on 3 platforms x 5+ different database engines per > change). > + binaries available and built every day > > > > > On Thu, Feb 6, 2014 at 1:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> What was a bit secret? >> >> Doru >> >> >> On Thu, Feb 6, 2014 at 12:25 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Well, it was a bit secret, but I was starting on my free time to setup >>> some ci jobs to build automagically all the opendbx libraries + test them. >>> >>> https://ci.inria.fr/dbxtalk/ >>> >>> Now my problem is that my free time for hacking on non phd stuff -> 0 >>> lately... :/ >>> >>> >>> On Thu, Feb 6, 2014 at 12:13 PM, Torsten Bergmann <astares(a)gmx.de>wrote: >>> >>>> And Sven insist on still cutting/copying/evaluating one-liners >>>> in the age of a configuration browser where loading is just mouse >>>> clicking ;) >>>> >>>> But putting jokes aside - it would IMHO be really important to >>>> have DBXTalk running for Pharo 3.0. Without good database >>>> support one would loose any argument for Pharo in the >>>> business world... >>>> >>>> It would also be a real bonus if the necessary support DLL's/shared libs >>>> could be easily provided or installed. >>>> >>>> For instance the PUnQLite (Pharo wrapper for UnQlite NoSQL) provides >>>> the current binaries on Github https://github.com/mumez/PunQLite >>>> >>>> Or the NaCl (a binding for Crypto-Nacl library) directly downloads >>>> and installs them when you install the config (see ConfigurationOfNacl >>>> in >>>> config browser of Pharo 3.0). >>>> >>>> Easy access without much hazzle is always a plus... install, connect to >>>> the DB and go! >>>> >>>> Thx >>>> T. >>>> >>>> > Gesendet: Donnerstag, 06. Februar 2014 um 11:54 Uhr >>>> > Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >>>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>> > Cc: dbxtalk(a)googlegroups.com >>>> > Betreff: Re: [Pharo-dev] Fwd: working on pharo 3.0? >>>> > >>>> > Ah, it is just because you insist on using old school two line code >>>> ;-) >>>> > >>>> > On 06 Feb 2014, at 11:38, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> > >>>> > > Gofer new >>>> > > smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >>>> > > package: 'ConfigurationOfOpenDBXDriver'; >>>> > > load >>>> > > #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge >>>> > > >>>> > >>>> > Gofer new >>>> > smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >>>> > configurationOf: 'OpenDBXDriver'; >>>> > loadVersion: #bleedingEdge. >>>> > >>>> > Just joking, >>>> > >>>> > Sven >>>> > >>>> > >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 7, 2014

Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...

by ClÃ©ment Bera

2014-02-06 20:34 GMT+01:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > Thanks for this information. > > Great post. > > So larger images would be no problem? let's say growing to 900MB? > I wouldn't say no problem, I would say that images up to 1 Gb should be usable and should behave much better than they used to due to the lack of full GC pauses. Now that's the theory we need to make it real and this summer we will see... > > > > > On Feb 6, 2014, at 12:48 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello pharoers, > > The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM > that some of you were interested in it, but unfortunately you were lacking > information about it. > > I wrote a one page article that sums up Spur's new features so every one > can know what will be better. There's no VM technical details here, it's > just about what will change for a regular pharo user. > > > http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me… > > Let me know if you think I forgot yet another feature. > > If you have questions, I'll try to answer, but ask Eliot, he implemented > Spur so he can answer your questions much better than I can :-). > > Regards, > > ClÃ©ment > > >

Feb. 7, 2014

Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...

by Alexandre Bergel

Sounds great!!! Alexandre > Le 06-02-2014 Ã 11:48, ClÃ©ment Bera <bera.clement(a)gmail.com> a Ã©crit : > > Hello pharoers, > > The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that some of you were interested in it, but unfortunately you were lacking information about it. > > I wrote a one page article that sums up Spur's new features so every one can know what will be better. There's no VM technical details here, it's just about what will change for a regular pharo user. > > http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me… > > Let me know if you think I forgot yet another feature. > > If you have questions, I'll try to answer, but ask Eliot, he implemented Spur so he can answer your questions much better than I can :-). > > Regards, > > ClÃ©ment

Feb. 7, 2014

Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...

by Eliot Miranda

Hi Ben, On Thu, Feb 6, 2014 at 9:19 AM, <btc(a)openinworld.com> wrote: > ClÃ©ment Bera wrote: > > Hello pharoers, > > The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM > that some of you were interested in it, but unfortunately you were lacking > information about it. > > I wrote a one page article that sums up Spur's new features so every one > can know what will be better. There's no VM technical details here, it's > just about what will change for a regular pharo user. > > > http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me… > > Let me know if you think I forgot yet another feature. > > If you have questions, I'll try to answer, but ask Eliot, he implemented > Spur so he can answer your questions much better than I can :-). > > Regards, > > ClÃ©ment > > > In what way would the speed-up for Characters being immediate improve > Unicode performance, and/or would it be worthwhile having an immediate > representation of UnicodeCharacters? I found Roassal to go an order of > magnitude slower when displaying labels with Unicode (but there may be many > reasons for that) ? > WideString>>at: index "Answer the Character stored in the field of the receiver indexed by the argument." ^ Character value: (self wordAt: index). Character class>>value: anInteger "Answer the Character whose value is anInteger." anInteger > 255 ifTrue: [^self basicNew setValue: anInteger]. ^ CharacterTable at: anInteger + 1. Currently characters are non-immediate and only the first 256 are unique. So every access of a character in a wide string requires an allocation of a character. In Spur, with immediate characters there is no instantiation. Further, because characters are simpler the JIT can produce machine-code to implement the primitives for WideString at: and at:put:, so WideString>>at: and WideString>>#at:put: will be primitive. So access will be very much faster. Here are some numbers measured on my 2.2GHz Core i7 MacBook Pro running 10.6.8. In current Cog | ws | ws := 'Hello world!' asWideString. [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 2693 and | ws | ws := 'Hello world!' asWideString. ws at: 1 put: (Character value: 256). [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 6100 If you redefine WideString>>at: in Spur to read WideString>>at: index "Primitive. Answer the Character stored in the field of the receiver indexed by the argument. Fail if the index argument is not an Integer or is out of bounds. Essential. See Object documentation whatIsAPrimitive." <primitive: 63> ^ Character value: (self wordAt: index). then | ws | ws := 'Hello world!' asWideString. [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 711 and | ws | ws := 'Hello world!' asWideString. ws at: 1 put: (Character value: 256). [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 761 These numbers are very noisy because I've got two images, Safari, Chrome and other things running. But you can see that in the case where the character is > 8 bits, the Spur code is > 8 times faster. -- best, Eliot

Feb. 6, 2014

Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...

by kilon alios

ah ok , shows how little I know about GCs :D On Thu, Feb 6, 2014 at 10:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On 06 Feb 2014, at 20:49, kilon alios <kilon.alios(a)gmail.com> wrote: > > Igoooooor where are you ? :D > > I am in no hurry personally , but its great to see the VM moving towards > the right direction and see taking Pharo with it. And the other > enhancements are really nice too. > > I wonder if GC control will be given, to assign objects to different part > of the memory of the VM. So this way you can have objects that are more, or > higher prioritised garbage collected. Maybe this way, user/coder given more > freedom to customise performance. Will that be possible ? > > > nope, just object pinning. > afaik, what you ask for is not possible in any GC, because precisely the > idea is to abstract you from that :) > > > > On Thu, Feb 6, 2014 at 9:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> >> On 06 Feb 2014, at 19:51, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> thats very good news , 64 bit is rather close now which mean even more C >> libraries available for Pharo and loads of GB of memory to exploit. >> >> >> yes, but just *closer*... we'll still need the 64bits FFI :) >> >> >> >> On Thu, Feb 6, 2014 at 7:19 PM, <btc(a)openinworld.com> wrote: >> >>> ClÃ©ment Bera wrote: >>> >>> Hello pharoers, >>> >>> The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM >>> that some of you were interested in it, but unfortunately you were lacking >>> information about it. >>> >>> I wrote a one page article that sums up Spur's new features so every >>> one can know what will be better. There's no VM technical details here, >>> it's just about what will change for a regular pharo user. >>> >>> >>> http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me… >>> >>> Let me know if you think I forgot yet another feature. >>> >>> If you have questions, I'll try to answer, but ask Eliot, he implemented >>> Spur so he can answer your questions much better than I can :-). >>> >>> Regards, >>> >>> ClÃ©ment >>> >>> >>> In what way would the speed-up for Characters being immediate improve >>> Unicode performance, and/or would it be worthwhile having an immediate >>> representation of UnicodeCharacters? I found Roassal to go an order of >>> magnitude slower when displaying labels with Unicode (but there may be many >>> reasons for that) ? >>> >>> cheers -ben >>> >> >> >> > >

Feb. 6, 2014