June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Encodings, Charsets, converters... streams?

by Denis Kudriashov

Hello. What is responsibility of environments (russian, japanese) classes. Why its needed? Why converter classes not enough? For example, I can write russian text at workspace without setting any specific russian environment. I only need specific fonts for this. 2012/6/25 Guillermo Polito <guillermopolito(a)gmail.com> > Hi guys, > > I'm trying to understand the Multilingual packages to get things a bit > more reorganized. This way we can start to have a simpler and > understandable kernel. So, > > - We have all environments(greek, chinese, japanese, korean, russian...) > in the same package. Each environment has it's associated charset, and > text converter, which are in different packages. Also, each text converter > has a table of conversions between unicode and the encoding. But all > converters are together, and all charsets are together. > > What about putting related things together? I mean, japanese converter > with japanese environment with japanese charset in one package. Same with > russian, korean, chinese... Does it make sense? This way we should be > able to unload one of them if we do not really need it. > > - MultiByteFileStream and MultiByteBinaryOrTextStream are inside > Multilingual-TextConversion? Even, they do the same on top of a file or a > memory stream of bytes (or they say so in the comment :^D )... > > What about merging them? using a decorator? They have a lot in common... > :/ Put them in a different package? > > - Just curious. ImmPlugin is working or shipped with vms? Not for macos, > because there is no macos implementation. Then, the class comment says: > > *"On Windows, the plugin is not provided in the shipped VM's, and its > current whereabouts are uncertain. > > On Unix, the only implemented behaviour is setting the position when > over-the-spot precomposition of characters is the current mode. > > In the VM, the mode is chosen to the first available valid mode returned > by the X Server, so whether this is actually relevant at all depends on the > X Server.*" > > So, does someone use it and see value on keeping it? > > > Guille >

June 25, 2012

Re: [Pharo-project] Problem with Monticelo package and corrupted sourcecode/zip

by Sean P. DeNigris

Mariano Martinez Peck wrote > > Sean asked me if the package contained non-asci characters..and yes, it > has > widestrings directly in the literal of a method (this is on purpose). > The method is #testWideString > testWideString contains wide characters. But the write is not failing inside testWideString because zip writing is buffered in 4096 byte chunks, so it fails at the beginning of that buffer write (in testTimestamp). If I remove the wide char literals from TestWideString, and resave the package, I can unzip it and file in source.st The write logic is in ZipArchiveMember>>copyDataWithCRCTo: ... data := self readRawChunk: (4096 min: readDataRemaining). aStream nextPutAll: data. ... When #readRawChunk: returns a WideString, all hell breaks loose. I don't know what the solution is, but at least we found the problem... -- View this message in context: http://forum.world.st/Problem-with-Monticelo-package-and-corrupted-sourceco… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 25, 2012

Re: [Pharo-project] Problem with Monticelo package and corrupted sourcecode/zip

by Mariano Martinez Peck

Thanks to the effort of SeanDiNigris, we continue trying to find out the problem. Sean asked me if the package contained non-asci characters..and yes, it has widestrings directly in the literal of a method (this is on purpose). The method is #testWideString Dale Henrichs told me there could be some problems with WideStrings and Gemstone in the ss3. So far I didn't find anyone...but now it seems we do? i think this problem was forever..and the unziping from the OS fails, but somehow the unziping from Monticello does work? Any ideas? Thanks! On Mon, Jun 25, 2012 at 9:17 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Can you try to file-in the uncompressed file? Or at least look if the > file is complete. Because I discovered this issue when trying to load > Fuel tests into the Pharo Kernel (the download and unzip of the > package is done directly by Pharo) and I had no problem with unzip of > this file on Linux but the resultant file was not complete and the > loading finished with syntax error. > > -- Pavel > > On Sun, Jun 24, 2012 at 11:58 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > I downloaded it, renamed the .mcz as a .zip and used the unarchiver on > it. > > No issue. > > > > 3271 lines in source.st > > > > OSX Lion over here. > > > > Was able to get it back from my 1.4 on CogVM and browse the downloaded > > package. > > > > Seems to be a OS X related issue. Rebooting a Mac may be rare, but may > > help... Network problems? Sometimes my NAS needs a kick in the butt.. > > > > Phil > > > > 2012/6/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> > >> Hi guys. I have a problem and I don't understand. If you download > >> FuelTests-MarianoMartinezPeck.269 from http://ss3.gemstone.com/ss/Fueland > >> try to unzip it, in my MacOSX I have an error saying the fie is > corrupted. > >> If I proceed anyway, and I open the .st it is CUT in the middle (it > does not > >> finish properly). I thought it was a problem with Traits (because > FuelTest > >> has traits), but I tried other packages even with traits and they are > fine. > >> Then I thought that that version of the package could be corrupted, but > I > >> went several versions ago in history and same problem. Then thoguht it > was > >> Monticello problem. I went to Pharo 2.0 20020 and again, same problem. > >> > >> So I am lost. I remember something about the zip compression problem in > >> Monticello.... could this be related? > >> > >> thanks > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > > -- > > Philippe Back > > Dramatic Performance Improvements > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | > > Web: http://philippeback.eu | Blog: http://philippeback.be > > > > High Octane SPRL > > rue cour Boisacq 101 > > 1301 Bierges > > Belgium > > -- Mariano http://marianopeck.wordpress.com

June 25, 2012

Re: [Pharo-project] LanguageEnvironment>>#setUsePangoFlag

by Fernando Olivero

I would remove it, it's a reminisce of Sophie surely. They used to have Pango and Cairo bindings. Fernando On Mon, Jun 25, 2012 at 5:16 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > And this method is funny :) because with a clean startup list it does not work: > > LanguageEnvironment>>initialize > Â Â "LanguageEnvironment initialize" > > Â Â Smalltalk addToStartUpList: LanguageEnvironment after: DiskStore. > Â Â Smalltalk addToStartUpList: DiskStore after: LanguageEnvironment. > > Even better, the language environment initialize does not need DiskStore... so Maybe we can simplify it a lot. > > On Mon, Jun 25, 2012 at 4:26 PM, Guillermo Polito <guillermopolito(a)gmail.com<mailto:guillermopolito@gmail.com>> wrote: > Hi! > > is that hook used by anybody? Â The only implementor does ^self... Â And that method has no changed since 2009. >

June 25, 2012

Re: [Pharo-project] LanguageEnvironment>>#setUsePangoFlag

by Guillermo Polito

And this method is funny :) because with a clean startup list it does not work: LanguageEnvironment>>initialize "LanguageEnvironment initialize" Smalltalk addToStartUpList: LanguageEnvironment after: DiskStore. Smalltalk addToStartUpList: DiskStore after: LanguageEnvironment. Even better, the language environment initialize does not need DiskStore... so Maybe we can simplify it a lot. On Mon, Jun 25, 2012 at 4:26 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi! > > is that hook used by anybody? The only implementor does ^self... And > that method has no changed since 2009. >

June 25, 2012

Re: [Pharo-project] FIleSystemStreams

by StÃ©phane Ducasse

On Jun 25, 2012, at 2:48 PM, Henrik Sperre Johansen wrote: > On 25.06.2012 14:21, Sven Van Caekenberghe wrote: >> I think I understand: in a way you go backwards to have better compatibility now. >> I will have to download a later 2.0 image. >> Thx. >> > For some context, an earlier discussion: > http://forum.world.st/Is-the-plan-to-replace-FileStream-by-FSStream-td43948… > > I'm glad Camillo is making progress! :D Yes but he needs help because he should work on a nativeBoost paper :) Camillo I would like to have the time to read it. Stef > > Cheers, > Henry >

June 25, 2012

Re: [Pharo-project] Where is the PBE VM?

by StÃ©phane Ducasse

thanks damien. Stef > >> Maybe the solution is simply to pick one and make it the most prominent >> download link on the PBE web page, either demoting or entirely eliminating >> the image-only/latest-Pharo links > > ok, pharobyexample.org now has a link to the one click image. > > Best, > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry >

June 25, 2012

[Pharo-project] LanguageEnvironment>>#setUsePangoFlag

by Guillermo Polito

Hi! is that hook used by anybody? The only implementor does ^self... And that method has no changed since 2009.

June 25, 2012

Re: [Pharo-project] Encodings, Charsets, converters... streams?

by Guillermo Polito

http://code.google.com/p/pharo/issues/detail?id=6154 http://code.google.com/p/pharo/issues/detail?id=6155 On Mon, Jun 25, 2012 at 4:08 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > BTW, in case people keep quiet, I'll start opening issues :) > > > On Mon, Jun 25, 2012 at 4:02 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi guys, >> >> I'm trying to understand the Multilingual packages to get things a bit >> more reorganized. This way we can start to have a simpler and >> understandable kernel. So, >> >> - We have all environments(greek, chinese, japanese, korean, russian...) >> in the same package. Each environment has it's associated charset, and >> text converter, which are in different packages. Also, each text converter >> has a table of conversions between unicode and the encoding. But all >> converters are together, and all charsets are together. >> >> What about putting related things together? I mean, japanese converter >> with japanese environment with japanese charset in one package. Same with >> russian, korean, chinese... Does it make sense? This way we should be >> able to unload one of them if we do not really need it. >> >> - MultiByteFileStream and MultiByteBinaryOrTextStream are inside >> Multilingual-TextConversion? Even, they do the same on top of a file or a >> memory stream of bytes (or they say so in the comment :^D )... >> >> What about merging them? using a decorator? They have a lot in common... >> :/ Put them in a different package? >> >> - Just curious. ImmPlugin is working or shipped with vms? Not for macos, >> because there is no macos implementation. Then, the class comment says: >> >> *"On Windows, the plugin is not provided in the shipped VM's, and its >> current whereabouts are uncertain. >> >> On Unix, the only implemented behaviour is setting the position when >> over-the-spot precomposition of characters is the current mode. >> >> In the VM, the mode is chosen to the first available valid mode returned >> by the X Server, so whether this is actually relevant at all depends on the >> X Server.*" >> >> So, does someone use it and see value on keeping it? >> >> >> Guille >> > >

June 25, 2012

Re: [Pharo-project] Encodings, Charsets, converters... streams?

by Guillermo Polito

BTW, in case people keep quiet, I'll start opening issues :) On Mon, Jun 25, 2012 at 4:02 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi guys, > > I'm trying to understand the Multilingual packages to get things a bit > more reorganized. This way we can start to have a simpler and > understandable kernel. So, > > - We have all environments(greek, chinese, japanese, korean, russian...) > in the same package. Each environment has it's associated charset, and > text converter, which are in different packages. Also, each text converter > has a table of conversions between unicode and the encoding. But all > converters are together, and all charsets are together. > > What about putting related things together? I mean, japanese converter > with japanese environment with japanese charset in one package. Same with > russian, korean, chinese... Does it make sense? This way we should be > able to unload one of them if we do not really need it. > > - MultiByteFileStream and MultiByteBinaryOrTextStream are inside > Multilingual-TextConversion? Even, they do the same on top of a file or a > memory stream of bytes (or they say so in the comment :^D )... > > What about merging them? using a decorator? They have a lot in common... > :/ Put them in a different package? > > - Just curious. ImmPlugin is working or shipped with vms? Not for macos, > because there is no macos implementation. Then, the class comment says: > > *"On Windows, the plugin is not provided in the shipped VM's, and its > current whereabouts are uncertain. > > On Unix, the only implemented behaviour is setting the position when > over-the-spot precomposition of characters is the current mode. > > In the VM, the mode is chosen to the first available valid mode returned > by the X Server, so whether this is actually relevant at all depends on the > X Server.*" > > So, does someone use it and see value on keeping it? > > > Guille >

June 25, 2012