- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Debugging code with morphic leads to freezes and a weird message

by StÃ©phane Ducasse

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] Sticky morph after progress morph use

by StÃ©phane Ducasse

Hi hilaire we do not know (at least I do not know what happened with the old progress bar). Now in 2.0 it is fixed (yes I know that you need a 1.4 version). Stef On Jun 24, 2012, at 12:14 PM, Hilaire Fernandes wrote: > Hello, > > With Pharo 1.4 I already reported about it, but when I build a drgeo > image then do a small clean up like this: > > === clean up ==== > FreeTypeFontProvider unload. > ScriptLoader new cleanUpForProduction. > StrikeFont cleanUp. > > (MCPackage named: 'Announcements-Help') unload. > (MCPackage named: 'FileSystem-Tests-Disk') unload. > (MCPackage named: 'FileSystem-Tests-Memory') unload. > (MCPackage named: 'FileSystem-Tests-Core') unload. > (MCPackage named: 'FileSystem-Tests-AnsiStreams') unload. > (MCPackage named: 'Metacello-Help') unload. > (MCPackage named: 'Regex-Help') unload. > RecentMessageList cleanUp. > Smalltalk removeEmptyMessageCategories. > Smalltalk garbageCollect > ==== end of clean up === > > > Then, in the cleaned image, in any place where the progress morph is > used, at the end of the progress process, a shaded morph (the background > of the progress morph) remains on screen like a big smelling peace of > shit - screenshot. > > What cleaning I should not do? > > Thanks > > Hilaire > > > -- > Dr. Geo -- http://www.drgeo.eu > <progress-morph-background-like-a-smelling-peace-of-shit.jpg>

June 25, 2012

Re: [Pharo-project] fulltext method search

by Camillo Bruni

On 2012-06-25, at 09:54, phil(a)highoctane.be wrote: > Ok, removed it. So now, I see a "method indexing" progress bar popping for > a while repeatedly :-). > > Well, it works. And I tried it out: > > "this is an instantaneous (~2ms!) search over all method sources" > Search default matchSentence: 'Convert to a String with Characters' > {(ByteArray>>#asString "a CompiledMethod(108265472)")} > > I am looking into how to integrate this with Spotlight [which is really > fantastic and improves productivity a lot!] (I guess I'll do another > binding like Ctrl-Enter instead of Shift-Enter). So, how do you get the > results? Is there a quick way to open the browser on a given CompliedMethod > right away? (Ah! So much to learn.... Sound is working nicely now BTW, got > a couple clues!) AS you saw the #searchSentence: returns a list of possible method matches. l := Search default matchSentence: 'copyFrom:to:' SystemNavigation default browseMessageList: l name: 'Messages with the string "copyFrom:to:"' - Since it is really an early hack, I don't support case sensitive searching. I wonder though if that is really necessary... Since the results are not fully exact (e.g. some false positives are here and there..) - Integration with system announcements is missing (I do not add new methods to the index..) - the code is rather messy (half of it is still in uncategorized :S) - no test coverage yet :D (bad cami, bad cami!!)

June 25, 2012

Re: [Pharo-project] FIleSystemStreams

by Camillo Bruni

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

[Pharo-project] FIleSystemStreams

by Sven Van Caekenberghe

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. 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 ? 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 ? Sven

June 25, 2012