- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] lineConversion for WriteStream

by Sven Van Caekenberghe

> On 26 May 2016, at 20:20, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Well I was saving e.g. STON or XML fileâ¦ but some apps outside didn't particularly like itâ¦ even `cat` doesn't like CR. Well, STONWriter, NeoJSONWriter and NeoCSVWriter allow you to set the line end convention, you are not alone in wanting the standard unix line end. > Anyway; this is not system-breaking problem, just annoying. > > Peter > > On Thu, May 26, 2016 at 2:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 26 May 2016, at 14:06, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > > > > On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > > > In general I would say that you should write either something platform specific or you write something specific > > > > > > Except that I cannot do that because the system doesn't support neither. > > > And the fact that the default line ending is CR is just bullshitâ¦ it's 2016, not 1986. > > > > Yes, that CR is from days long gone ;-) > > > > > or #cr #lf or #crlf as needed, and/or make that last one a parameter (OSPlatform current lineEnding). > > > > I am piping unknown content into the file, thus the need for `lineEndConvention:` and the reason of this entire thread. So as I said, the system doesn't support it. > > I know I can use #lf or whatnot, but I am not creating the content, I am saving it. > > > > Peter > > Well, maybe I don't understand your use case, but if you do not know what is inside, why not save it as is, binary even, not doing any conversions ? > > >

May 26, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by Peter UhnÃ¡k

Well I was saving e.g. STON or XML fileâ¦ but some apps outside didn't particularly like itâ¦ even `cat` doesn't like CR. Anyway; this is not system-breaking problem, just annoying. Peter On Thu, May 26, 2016 at 2:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 26 May 2016, at 14:06, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > > > > On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > > > In general I would say that you should write either something > platform specific or you write something specific > > > > > > Except that I cannot do that because the system doesn't support > neither. > > > And the fact that the default line ending is CR is just bullshitâ¦ it's > 2016, not 1986. > > > > Yes, that CR is from days long gone ;-) > > > > > or #cr #lf or #crlf as needed, and/or make that last one a parameter > (OSPlatform current lineEnding). > > > > I am piping unknown content into the file, thus the need for > `lineEndConvention:` and the reason of this entire thread. So as I said, > the system doesn't support it. > > I know I can use #lf or whatnot, but I am not creating the content, I am > saving it. > > > > Peter > > Well, maybe I don't understand your use case, but if you do not know what > is inside, why not save it as is, binary even, not doing any conversions ? > > >

May 26, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60038 Home: https://github.com/pharo-project/pharo-core

May 26, 2016

[pharo-project/pharo-core] a4828b: 60038

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: a4828bfc1a54d331f362fd7c3c7fd43eeee9045c https://github.com/pharo-project/pharo-core/commit/a4828bfc1a54d331f362fd7c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-26 (Thu, 26 May 2016) Changed paths: M AST-FFI-Pharo50Compatibility.package/extension/OCASTTranslator/instance/visitPragmaNode_.st M Monticello.package/MCClassDefinition.class/instance/printing/kindOfSubclass.st A OpalCompiler-Tests.package/OCASTTranslatorTest.class/instance/testing - primitives/testExamplePrimitiveErrorModule.st A OpalCompiler-Tests.package/OCASTTranslatorTest.class/instance/testing - primitives/testExamplePrimitiveModuleError.st A OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-pragmas/examplePrimitiveErrorModule.st A OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-pragmas/examplePrimitiveModuleError.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60037.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60038.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60037.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60038.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/AbstractLayout.class/instance/testing/isCustomLayout.st M Slot.package/ObjectLayout.class/class/accessing/layoutForType_.st M Traits.package/TBehavior.class/instance/accessing/typeOfClass.st Log Message: ----------- 60038 18331 Support saving custom Layouts with Monticello https://pharo.fogbugz.com/f/cases/18331 17994 RBParserNode: allowed primitive pragma definition can not compile https://pharo.fogbugz.com/f/cases/17994 http://files.pharo.org/image/60/60038.zip

May 26, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by Sven Van Caekenberghe

> On 26 May 2016, at 14:06, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > In general I would say that you should write either something platform specific or you write something specific > > > > Except that I cannot do that because the system doesn't support neither. > > And the fact that the default line ending is CR is just bullshitâ¦ it's 2016, not 1986. > > Yes, that CR is from days long gone ;-) > > > or #cr #lf or #crlf as needed, and/or make that last one a parameter (OSPlatform current lineEnding). > > I am piping unknown content into the file, thus the need for `lineEndConvention:` and the reason of this entire thread. So as I said, the system doesn't support it. > I know I can use #lf or whatnot, but I am not creating the content, I am saving it. > > Peter Well, maybe I don't understand your use case, but if you do not know what is inside, why not save it as is, binary even, not doing any conversions ?

May 26, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by Peter UhnÃ¡k

On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > In general I would say that you should write either something > platform specific or you write something specific > > > > Except that I cannot do that because the system doesn't support neither. > > And the fact that the default line ending is CR is just bullshitâ¦ it's > 2016, not 1986. > > Yes, that CR is from days long gone ;-) > > > or #cr #lf or #crlf as needed, and/or make that last one a parameter > (OSPlatform current lineEnding). > I am piping unknown content into the file, thus the need for `lineEndConvention:` and the reason of this entire thread. So as I said, the system doesn't support it. I know I can use #lf or whatnot, but I am not creating the content, I am saving it. Peter

May 26, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by Sven Van Caekenberghe

> On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > In general I would say that you should write either something platform specific or you write something specific > > Except that I cannot do that because the system doesn't support neither. > And the fact that the default line ending is CR is just bullshitâ¦ it's 2016, not 1986. Yes, that CR is from days long gone ;-) But you can certainly do whatever you want, you have to use the right streams. Make sure you start with a binary stream, wrap it to do character encoding/decoding, use #readLine, or #cr #lf or #crlf as needed, and/or make that last one a parameter (OSPlatform current lineEnding). > On Thu, May 26, 2016 at 12:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > MultiByteFileStream is terrible (too complex) because it does too much (at once). Let's keep WriteStream simple (and even simplify it). You do not want characters that change magically. > > That being said, line end conventions can be a pain. In general I would say that you should write either something platform specific (you can fetch the EOL terminator somewhere), or you write something specific (say CRLF for web stuff), while during reading you should accept anything (that is easy to do). You know: be strict in what you produce, liberal in what you accept. > > > On 26 May 2016, at 11:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Is there a reason why only MultiByteFileStream provides lineEndConvention: and not WriteStream? > > > > The problem is that if I use MemoryStore in tests it breaks, because DiskStore and MemoryStore return different write streams. > > > > '/tmp/test.txt' asFileReference writeStream ==> "MultiByteFileStream: '/tmp/test.txt'". > > (FileSystem memory / 'test.txt') writeStream ==> "a WriteStream" > > > > Can we either: > > > > a) have `lineEndConvention:` directly in the WriteStream, or > > b) have MemoryStore return MultiByteFileStream, or > > c) both? > > > > Thanks, > > Peter > > >

May 26, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by Peter UhnÃ¡k

> In general I would say that you should write either something platform specific or you write something specific Except that I cannot do that because the system doesn't support neither. And the fact that the default line ending is CR is just bullshitâ¦ it's 2016, not 1986. On Thu, May 26, 2016 at 12:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > MultiByteFileStream is terrible (too complex) because it does too much (at > once). Let's keep WriteStream simple (and even simplify it). You do not > want characters that change magically. > > That being said, line end conventions can be a pain. In general I would > say that you should write either something platform specific (you can fetch > the EOL terminator somewhere), or you write something specific (say CRLF > for web stuff), while during reading you should accept anything (that is > easy to do). You know: be strict in what you produce, liberal in what you > accept. > > > On 26 May 2016, at 11:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Is there a reason why only MultiByteFileStream provides > lineEndConvention: and not WriteStream? > > > > The problem is that if I use MemoryStore in tests it breaks, because > DiskStore and MemoryStore return different write streams. > > > > '/tmp/test.txt' asFileReference writeStream ==> "MultiByteFileStream: > '/tmp/test.txt'". > > (FileSystem memory / 'test.txt') writeStream ==> "a WriteStream" > > > > Can we either: > > > > a) have `lineEndConvention:` directly in the WriteStream, or > > b) have MemoryStore return MultiByteFileStream, or > > c) both? > > > > Thanks, > > Peter > > >

May 26, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by Sven Van Caekenberghe

MultiByteFileStream is terrible (too complex) because it does too much (at once). Let's keep WriteStream simple (and even simplify it). You do not want characters that change magically. That being said, line end conventions can be a pain. In general I would say that you should write either something platform specific (you can fetch the EOL terminator somewhere), or you write something specific (say CRLF for web stuff), while during reading you should accept anything (that is easy to do). You know: be strict in what you produce, liberal in what you accept. > On 26 May 2016, at 11:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Is there a reason why only MultiByteFileStream provides lineEndConvention: and not WriteStream? > > The problem is that if I use MemoryStore in tests it breaks, because DiskStore and MemoryStore return different write streams. > > '/tmp/test.txt' asFileReference writeStream ==> "MultiByteFileStream: '/tmp/test.txt'". > (FileSystem memory / 'test.txt') writeStream ==> "a WriteStream" > > Can we either: > > a) have `lineEndConvention:` directly in the WriteStream, or > b) have MemoryStore return MultiByteFileStream, or > c) both? > > Thanks, > Peter

May 26, 2016

lineConversion for WriteStream

by Peter UhnÃ¡k

Is there a reason why only MultiByteFileStream provides lineEndConvention: and not WriteStream? The problem is that if I use MemoryStore in tests it breaks, because DiskStore and MemoryStore return different write streams. '/tmp/test.txt' asFileReference writeStream ==> "MultiByteFileStream: '/tmp/test.txt'". (FileSystem memory / 'test.txt') writeStream ==> "a WriteStream" Can we either: a) have `lineEndConvention:` directly in the WriteStream, or b) have MemoryStore return MultiByteFileStream, or c) both? Thanks, Peter

May 26, 2016