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

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

by Guillermo Polito

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] Debugging code with morphic leads to freezes and a weird message

by Esteban Lorenzano

nobody and everybody. the repository is open, all people with fixes are invited to commit their changes, if the want to see them integrated in the upcoming 1.4 release Esteban On Jun 25, 2012, at 1:34 PM, StÃ©phane Ducasse wrote: > It would be good to publish the fix for other OB 1.4 users (I do not know who is in charge) > > Stef > > On Jun 25, 2012, at 9:45 AM, phil(a)highoctane.be wrote: > >> Oh, okay, thanks a lot!. Lesson taken: check for implementers :) >> >> 2012/6/25 Marcus Denker <marcus.denker(a)inria.fr> >> >> On Jun 24, 2012, at 9:39 PM, phil(a)highoctane.be wrote: >> >>> While debugging actions behind buttons, I do get Project class>>spawnNewProcessIfThisIsUI: not being understood. >>> >>> This prevents from debugging interactions properly. >>> >>> And sometimes I get the dreaded "Computation Terminated" message, effectively locking me out of the image (nothing moves anymore, I've got to kill the process). >>> >>> Ideas on how to fix? This is 1.4 14438 >>> >>> >> >> #spawnNewProcessIfThisIsUI: has been moved to UIManager.... it seems that OB still calls it on Project. >> >> Marcus >> >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >> >> >> > >

June 25, 2012

Re: [Pharo-project] [update 2.0] #20158

by Pavel Krivanek

Can you, please, open an issue and write your comments there? On Mon, Jun 25, 2012 at 3:41 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Pavel Krivanek-3 wrote >> >> we have 3 new failing tests >> - KernelTests.Chronology.DateAndTimeTest.testDosEpoch >> - KernelTests.Chronology.DateAndTimeTest.testSecondsAcrossTimeZones >> - KernelTests.Chronology.DateAndTimeTest.testSqueakEpoch >> > > If we can live with these, they actually should be failing. The first one, > I'm still deciding what to do about (either change the implementation or the > test). The second two are dependent on "Issue 6089: Â Â [BUG]: Epoch handled > incorrectly", which I've been working on, but I'm still thinking through the > ramifications of my changes. If anyone wants to work together, lmk... > > Sean > > -- > View this message in context: http://forum.world.st/update-2-0-20158-tp4636308p4636542.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 25, 2012

Re: [Pharo-project] [update 2.0] #20158

by Sean P. DeNigris

Pavel Krivanek-3 wrote > > we have 3 new failing tests > - KernelTests.Chronology.DateAndTimeTest.testDosEpoch > - KernelTests.Chronology.DateAndTimeTest.testSecondsAcrossTimeZones > - KernelTests.Chronology.DateAndTimeTest.testSqueakEpoch > If we can live with these, they actually should be failing. The first one, I'm still deciding what to do about (either change the implementation or the test). The second two are dependent on "Issue 6089: [BUG]: Epoch handled incorrectly", which I've been working on, but I'm still thinking through the ramifications of my changes. If anyone wants to work together, lmk... Sean -- View this message in context: http://forum.world.st/update-2-0-20158-tp4636308p4636542.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 25, 2012

Re: [Pharo-project] [update 2.0] #20158

by Pavel Krivanek

Tests Guard report: http://code.google.com/p/pharo/wiki/TestsGuard we have 3 new failing tests - KernelTests.Chronology.DateAndTimeTest.testDosEpoch - KernelTests.Chronology.DateAndTimeTest.testSecondsAcrossTimeZones - KernelTests.Chronology.DateAndTimeTest.testSqueakEpoch -- Pavel On Sat, Jun 23, 2012 at 7:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 20158 > ----- > > - Issue 6135: Â Code completion in all tools. Thanks Sean De Nigris. > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=6135 > > - Issue 6091: Â FileReference>>extension should be after last separator. Thanks Sean De Nigris. > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=6091 > > - Issue 6086: Â Running tests with test runner is very slow due to progress bar. Tx > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=6086 > > - Issue 6092: Â Clean Chronology tests.Thanks Sean De Nigris. > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=6092

June 25, 2012

Re: [Pharo-project] FIleSystemStreams

by Henrik Sperre Johansen

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 Cheers, Henry

June 25, 2012

Re: [Pharo-project] FIleSystemStreams

by Sven Van Caekenberghe

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. On 25 Jun 2012, at 14:09, Camillo Bruni wrote: > > On 2012-06-25, at 13:56, Sven Van Caekenberghe wrote: > >> I am confused, Camillo. >> You want to remove them, OK. >> But what will #writeStreamDo: and so on then get as argument ? > > currently (2.0.158) that returns a MultiByteFileStream > >> Something new ? >> Or is there already another solution in the image ? > > basically I wanted to make sure we return the same FileDirectory / FileStream does > > the only problem so far is that the memory filestream still uses the FS streams, > which I changed in http://code.google.com/p/pharo/issues/detail?id=6132 > That will simply return a WriteStream on the internal ByteArray for now. > > >> On 25 Jun 2012, at 13:02, Camillo Bruni wrote: >> >>> Hi Sven, >>> >>> On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote: >>> >>>> All in all the switch to FileSystem is very good. File/Directory manipulation is much improved. >>>> >>>> (But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4) >>>> >>>> However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses. >>>> >>>> They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong. >>> >>> Definitely wrong... >>> Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. >>> Even worse, I think with having yet another stream implementation we completely confuse the hell out of people! >>> >>> see: http://code.google.com/p/pharo/issues/detail?id=6132 >>> >>>> Why is there a FileSystemReadStream>>#nextLine ? >>>> Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? >>>> Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ? >>> >>> obsolete I would, given that the FileSystemReadStream is going to be removed >>> >>>> Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters. >>>> >>>> Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks). >>>> >>>> Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ? >>>> >>>> What do the FileSystem hackers, Cami, Sean, et al, think about this situation ? >>> >>> :) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. >>> When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char. >> >> > >

June 25, 2012

Re: [Pharo-project] FIleSystemStreams

by Camillo Bruni

On 2012-06-25, at 13:56, Sven Van Caekenberghe wrote: > I am confused, Camillo. > You want to remove them, OK. > But what will #writeStreamDo: and so on then get as argument ? currently (2.0.158) that returns a MultiByteFileStream > Something new ? > Or is there already another solution in the image ? basically I wanted to make sure we return the same FileDirectory / FileStream does the only problem so far is that the memory filestream still uses the FS streams, which I changed in http://code.google.com/p/pharo/issues/detail?id=6132 That will simply return a WriteStream on the internal ByteArray for now. > On 25 Jun 2012, at 13:02, Camillo Bruni wrote: > >> Hi Sven, >> >> On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote: >> >>> All in all the switch to FileSystem is very good. File/Directory manipulation is much improved. >>> >>> (But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4) >>> >>> However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses. >>> >>> They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong. >> >> Definitely wrong... >> Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. >> Even worse, I think with having yet another stream implementation we completely confuse the hell out of people! >> >> see: http://code.google.com/p/pharo/issues/detail?id=6132 >> >>> Why is there a FileSystemReadStream>>#nextLine ? >>> Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? >>> Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ? >> >> obsolete I would, given that the FileSystemReadStream is going to be removed >> >>> Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters. >>> >>> Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks). >>> >>> Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ? >>> >>> What do the FileSystem hackers, Cami, Sean, et al, think about this situation ? >> >> :) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. >> When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char. > >

June 25, 2012

Re: [Pharo-project] FIleSystemStreams

by Sven Van Caekenberghe

I am confused, Camillo. You want to remove them, OK. But what will #writeStreamDo: and so on then get as argument ? Something new ? Or is there already another solution in the image ? On 25 Jun 2012, at 13:02, Camillo Bruni wrote: > Hi Sven, > > On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote: > >> All in all the switch to FileSystem is very good. File/Directory manipulation is much improved. >> >> (But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4) >> >> However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses. >> >> They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong. > > Definitely wrong... > Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. > Even worse, I think with having yet another stream implementation we completely confuse the hell out of people! > > see: http://code.google.com/p/pharo/issues/detail?id=6132 > >> Why is there a FileSystemReadStream>>#nextLine ? >> Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? >> Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ? > > obsolete I would, given that the FileSystemReadStream is going to be removed > >> Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters. >> >> Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks). >> >> Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ? >> >> What do the FileSystem hackers, Cami, Sean, et al, think about this situation ? > > :) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. > When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char.

June 25, 2012

Re: [Pharo-project] updating 2.0 is broken

by StÃ©phane Ducasse

I moved it from the inbox to the repo but it may mean that we have a bug somewhere in script loader probably when publishing package that did not come dirty. I do not have the time now to look at it. Stef On Jun 25, 2012, at 11:11 AM, Marcus Denker wrote: > > 'Could not load FileSystem-Tests-Core-SeanDeNigris.18.mcz: ZnHttpUnsuccessful: 404 Not Found' > > > http://code.google.com/p/pharo/issues/detail?id=6152 > > -- > Marcus Denker -- http://marcusdenker.de > >

June 25, 2012