Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
On 5/16/2011 12:34, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
Do us all a favor and leave out these derogatory comments. They are *not* helpful.
Thanks, - Andreas
On 16 May 2011 17:16, Andreas Raab andreas.raab@gmx.de wrote:
On 5/16/2011 12:34, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
Do us all a favor and leave out these derogatory comments. They are *not* helpful.
:) Well, i can't resist putting it like that, because i lost like 1 hour trying to understand why it was broken again. And only then found that Mariano omitted workaround when refactoring code.
Its definitely needs to be fixed, but i was focused on another problem (which also needs to be fixed) , and i'm not in the mood of fixing MultiByte..errStream before i can do anything with problem i wanted to solve.
Thanks, - Andreas
On 5/17/2011 9:27, Igor Stasenko wrote:
On 16 May 2011 17:16, Andreas Raabandreas.raab@gmx.de wrote:
On 5/16/2011 12:34, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
Do us all a favor and leave out these derogatory comments. They are *not* helpful.
:) Well, i can't resist putting it like that, because i lost like 1 hour trying to understand why it was broken again.
I understand what you mean but the thing you need to learn is that there's a big difference between a muttered curse and a public comment. A check-in comment that is being reposted in archived mailing lists is something that people read. Treating your fellow developers without respect is a great way of ensuring difficult relationships in the future. Nobody likes being called names, or derogatory comments about their code, not you, not me, not anyone. There is no reason to call MultiByteFileStream MultiByteCrapStream other than an intentional insult to the original author(s). Insulting people in a public forum is a great way to destroy relationships. Just ask your boss.
Cheers, - Andreas
And only then found that Mariano omitted workaround when refactoring code.
Its definitely needs to be fixed, but i was focused on another problem (which also needs to be fixed) , and i'm not in the mood of fixing MultiByte..errStream before i can do anything with problem i wanted to solve.
Thanks,
- Andreas
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
It's not crap, just broken. I'll integrate the fix for it into Squeak soon. If you're impatient you can fix it yourself, or use something else.
Levente
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote:
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
I don't understand why it patching the UTF8Converter and turns it into line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
I'll integrate the fix for it into Squeak soon. If you're impatient you can fix it yourself, or use something else.
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere. But then again, it means time, which i haven't because i was focused on completely different problem.
On Tue, 17 May 2011, Igor Stasenko wrote:
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote:
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
Tests can greatly decrease the chance of breaking it.
I don't understand why it patching the UTF8Converter and turns it into line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
The reason is performance, and the implementation is transparent. It also simplifies MultiByteFileStream.
I'll integrate the fix for it into Squeak soon. If you're impatient you can fix it yourself, or use something else.
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere.
CrLfFileStream is not used, since Squeak 3.x. References to it should be rewritten to use FileStream instead. Using binary mode to work around a bug is bad idea, fixing the bug is the way to go.
But then again, it means time, which i haven't because i was focused on completely different problem.
I'll upload my fix to Squeak Trunk this week. Applying the changes to Pharo probably won't work out of the box, because IIRC some issues were solved differently in the past.
Levente
-- Best regards, Igor Stasenko AKA sig.
On 17 May 2011 13:50, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote:
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
Tests can greatly decrease the chance of breaking it.
yes, i submitted a test yesterday. http://code.google.com/p/pharo/issues/detail?id=4236
it written in a way to reproduce an issue when running on any system (not just Windows).
I don't understand why it patching the UTF8Converter and turns it into line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
The reason is performance, and the implementation is transparent. It also simplifies MultiByteFileStream.
what about clarity? The problem is that this code is so optimized that it is no longer transparent. It is opaque for my eyes. I cannot fix it, because it looks very brittle and it is hard to get what it does, with all those branches, ifNotNils etc etc in almost every method there.
And i cannot be sure if my fix won't break something else, because there is no clear separation of concerns:
- use UTF8Converter for utf8 conversion and NOTHING else. - and let stream to filter input and replace cr character(s) to whatever it wants them to be
And what about simplification?
Do you think this is how a _simple_ method should look like?
nextPut: aCharacter aCharacter isInteger ifTrue: [ ^ super nextPut: aCharacter ]. (wantsLineEndConversion == true and: [ lineEndConvention notNil ]) "#doConversion is inlined here" ifTrue: [ aCharacter = Cr ifTrue: [ converter nextPutAll: (LineEndStrings at: lineEndConvention) toStream: self ] ifFalse: [ converter nextPut: aCharacter toStream: self ]. ^aCharacter ]. ^ self converter nextPut: aCharacter toStream: self
4 branches.. while i, by following your premise, would expect a single line here:
nextPut: aCharacter ^ converter nextPut: aCharacter toStream: self
because if you decided to delegate line ends conversion to converter (for whatever reason) , then you don't have to do anything outside of it.
I'll integrate the fix for it into Squeak soon. If you're impatient you can fix it yourself, or use something else.
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere.
CrLfFileStream is not used, since Squeak 3.x. References to it should be rewritten to use FileStream instead. Using binary mode to work around a bug is bad idea, fixing the bug is the way to go.
But why you stating false statements? CrLfFileStream is used, at least by VMMaker. And i was never took a deep look on a file streams to clearly say if it still used or can be removed.
So, can you clarify, can we deprecate and then completely remove CrLfFileStream from image and fix all references to it with FileStream instead? Because i like putting useless cra.. (err stuff) into trash bin.
But then again, it means time, which i haven't because i was focused on completely different problem.
I'll upload my fix to Squeak Trunk this week. Applying the changes to Pharo probably won't work out of the box, because IIRC some issues were solved differently in the past.
i'm not sure.
Levente
On Tue, 17 May 2011, Igor Stasenko wrote:
On 17 May 2011 13:50, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote:
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
Tests can greatly decrease the chance of breaking it.
yes, i submitted a test yesterday. http://code.google.com/p/pharo/issues/detail?id=4236
it written in a way to reproduce an issue when running on any system (not just Windows).
I also have some tests which cover more cases.
I don't understand why it patching the UTF8Converter and turns it into line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
The reason is performance, and the implementation is transparent. It also simplifies MultiByteFileStream.
what about clarity? The problem is that this code is so optimized that it is no longer transparent. It is opaque for my eyes. I cannot fix it, because it looks very brittle and it is hard to get what it does, with all those branches, ifNotNils etc etc in almost every method there.
MultiByteFileStream is not clean yet, but it will be.
And i cannot be sure if my fix won't break something else, because there is no clear separation of concerns:
- use UTF8Converter for utf8 conversion and NOTHING else.
- and let stream to filter input and replace cr character(s) to
whatever it wants them to be
And what about simplification?
Do you think this is how a _simple_ method should look like?
nextPut: aCharacter aCharacter isInteger ifTrue: [ ^ super nextPut: aCharacter ]. (wantsLineEndConversion == true and: [ lineEndConvention notNil ]) "#doConversion is inlined here" ifTrue: [ aCharacter = Cr ifTrue: [ converter nextPutAll: (LineEndStrings at: lineEndConvention) toStream: self ] ifFalse: [ converter nextPut: aCharacter toStream: self ]. ^aCharacter ]. ^ self converter nextPut: aCharacter toStream: self
4 branches.. while i, by following your premise, would expect a single line here:
nextPut: aCharacter ^ converter nextPut: aCharacter toStream: self
because if you decided to delegate line ends conversion to converter (for whatever reason) , then you don't have to do anything outside of it.
Exactly. What I also have in my mind is to remove the #isBinary checks from the TextConverters and put them back to MultiByteFileStream, where they belong to IMHO.
I'll integrate the fix for it into Squeak soon. If you're impatient you can fix it yourself, or use something else.
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere.
CrLfFileStream is not used, since Squeak 3.x. References to it should be rewritten to use FileStream instead. Using binary mode to work around a bug is bad idea, fixing the bug is the way to go.
But why you stating false statements? CrLfFileStream is used, at least by VMMaker. And i was never took a deep look on a file streams to clearly say if it still used or can be removed.
It's not a false statement, print it: CrLfFileStream new. In Squeak CrLfFileStream is deprecated and if I'm not mistaken the same is true in Pharo.
So, can you clarify, can we deprecate and then completely remove CrLfFileStream from image and fix all references to it with FileStream instead? Because i like putting useless cra.. (err stuff) into trash bin.
See above.
Levente
But then again, it means time, which i haven't because i was focused on completely different problem.
I'll upload my fix to Squeak Trunk this week. Applying the changes to Pharo probably won't work out of the box, because IIRC some issues were solved differently in the past.
i'm not sure.
Levente
-- Best regards, Igor Stasenko AKA sig.
On 17 May 2011 16:14, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 17 May 2011 13:50, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote:
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.org wrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
Tests can greatly decrease the chance of breaking it.
yes, i submitted a test yesterday. http://code.google.com/p/pharo/issues/detail?id=4236
it written in a way to reproduce an issue when running on any system (not just Windows).
I also have some tests which cover more cases.
I don't understand why it patching the UTF8Converter and turns it into line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
The reason is performance, and the implementation is transparent. It also simplifies MultiByteFileStream.
what about clarity? The problem is that this code is so optimized that it is no longer transparent. It is opaque for my eyes. I cannot fix it, because it looks very brittle and it is hard to get what it does, with all those branches, ifNotNils etc etc in almost every method there.
MultiByteFileStream is not clean yet, but it will be.
And i cannot be sure if my fix won't break something else, because there is no clear separation of concerns:
- use UTF8Converter for utf8 conversion and NOTHING else.
- and let stream to filter input and replace cr character(s) to
whatever it wants them to be
And what about simplification?
Do you think this is how a _simple_ method should look like?
nextPut: aCharacter aCharacter isInteger ifTrue: [ ^ super nextPut: aCharacter ]. (wantsLineEndConversion == true and: [ lineEndConvention notNil ]) "#doConversion is inlined here" ifTrue: [ aCharacter = Cr ifTrue: [ converter nextPutAll: (LineEndStrings at: lineEndConvention) toStream: self ] ifFalse: [ converter nextPut: aCharacter toStream: self ]. ^aCharacter ]. ^ self converter nextPut: aCharacter toStream: self
4 branches.. while i, by following your premise, would expect a single line here:
nextPut: aCharacter ^ converter nextPut: aCharacter toStream: self
because if you decided to delegate line ends conversion to converter (for whatever reason) , then you don't have to do anything outside of it.
Exactly. What I also have in my mind is to remove the #isBinary checks from the TextConverters and put them back to MultiByteFileStream, where they belong to IMHO.
IMO stream wrappers is a way to go. because implementation is much more cleaner and concise, and you don't have protocol duplication and double-dispatch like
nextPut: -> nextPut: toStream: -> basicNextPut:
but that means even more work to whoever would like to do that, up to the point, that i think it would be easier to drop everything altogether and start using XTreams (with some compatibility extras to support existing protocols) but quickly migrate code to new ones.
I'll integrate the fix for it into Squeak soon. If you're impatient you can fix it yourself, or use something else.
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere.
CrLfFileStream is not used, since Squeak 3.x. References to it should be rewritten to use FileStream instead. Using binary mode to work around a bug is bad idea, fixing the bug is the way to go.
But why you stating false statements? CrLfFileStream is used, at least by VMMaker. And i was never took a deep look on a file streams to clearly say if it still used or can be removed.
It's not a false statement, print it: CrLfFileStream new. In Squeak CrLfFileStream is deprecated and if I'm not mistaken the same is true in Pharo.
The problem is that you cannot safely remove it because external projects referencing it. You saying that it was deprecated years ago. So, why it not removed already, so people won't get stuck with it again and again, but instead fix references to it and use FileStream instead.
So, can you clarify, can we deprecate and then completely remove CrLfFileStream from image and fix all references to it with FileStream instead? Because i like putting useless cra.. (err stuff) into trash bin.
See above.
Levente
But then again, it means time, which i haven't because i was focused on completely different problem.
I'll upload my fix to Squeak Trunk this week. Applying the changes to Pharo probably won't work out of the box, because IIRC some issues were solved differently in the past.
i'm not sure.
Levente
-- Best regards, Igor Stasenko AKA sig.
On Tue, 17 May 2011, Igor Stasenko wrote:
On 17 May 2011 16:14, Levente Uzonyi leves@elte.hu wrote:
snip
Exactly. What I also have in my mind is to remove the #isBinary checks from the TextConverters and put them back to MultiByteFileStream, where they belong to IMHO.
IMO stream wrappers is a way to go. because implementation is much more cleaner and concise, and you don't have protocol duplication and double-dispatch like
nextPut: -> nextPut: toStream: -> basicNextPut:
but that means even more work to whoever would like to do that, up to
That's my longer term plan: replace MultiByteFileStream and MultiByteBinaryOrTextStream with MultiByteStream, which could wrap a stream and a text converter.
the point, that i think it would be easier to drop everything altogether and start using XTreams (with some compatibility extras to support existing protocols) but quickly migrate code to new ones.
But someone has to implement a compatibility wrapper first, which won't be easy.
snip
It's not a false statement, print it: CrLfFileStream new. In Squeak CrLfFileStream is deprecated and if I'm not mistaken the same is true in Pharo.
The problem is that you cannot safely remove it because external projects referencing it. You saying that it was deprecated years ago. So, why it not removed already, so people won't get stuck with it again and again, but instead fix references to it and use FileStream instead.
AFAIK VMMaker already requires a compatibility package in Pharo 1.3. Add CrLfFileStream to that package and the problem is solved.
I'll upload my fix to Squeak Trunk this week. Applying the changes to Pharo probably won't work out of the box, because IIRC some issues were solved differently in the past.
i'm not sure.
I uploaded my code to the Squeak Inbox, so you can check it out. It doesn't cover everything, but it's a good start.
Levente
Hi Levente,
On Tue, May 17, 2011 at 7:14 AM, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 17 May 2011 13:50, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote:
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.orgwrote:
Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
==================== Summary ====================
Name: CMakeVMMaker-StasenkoIgor.104 Author: StasenkoIgor Time: 16 May 2011, 10:33:56 am UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b Ancestors: CMakeVMMaker-IgorStasenko.103
workaround the MultiByteCrapStream, which converting line endings twice on windows.
It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
Tests can greatly decrease the chance of breaking it.
yes, i submitted a test yesterday. http://code.google.com/p/pharo/issues/detail?id=4236
it written in a way to reproduce an issue when running on any system (not just Windows).
I also have some tests which cover more cases.
I don't understand why it patching the UTF8Converter and turns it into line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
The reason is performance, and the implementation is transparent. It also simplifies MultiByteFileStream.
what about clarity? The problem is that this code is so optimized that it is no longer transparent. It is opaque for my eyes. I cannot fix it, because it looks very brittle and it is hard to get what it does, with all those branches, ifNotNils etc etc in almost every method there.
MultiByteFileStream is not clean yet, but it will be.
And i cannot be sure if my fix won't break something else, because there is no clear separation of concerns:
- use UTF8Converter for utf8 conversion and NOTHING else.
- and let stream to filter input and replace cr character(s) to
whatever it wants them to be
And what about simplification?
Do you think this is how a _simple_ method should look like?
nextPut: aCharacter aCharacter isInteger ifTrue: [ ^ super nextPut: aCharacter ]. (wantsLineEndConversion == true and: [ lineEndConvention notNil ]) "#doConversion is inlined here" ifTrue: [ aCharacter = Cr ifTrue: [ converter nextPutAll: (LineEndStrings at: lineEndConvention) toStream: self ] ifFalse: [ converter nextPut: aCharacter toStream: self ]. ^aCharacter ]. ^ self converter nextPut: aCharacter toStream: self
4 branches.. while i, by following your premise, would expect a single line here:
nextPut: aCharacter ^ converter nextPut: aCharacter toStream: self
because if you decided to delegate line ends conversion to converter (for whatever reason) , then you don't have to do anything outside of it.
Exactly. What I also have in my mind is to remove the #isBinary checks from the TextConverters and put them back to MultiByteFileStream, where they belong to IMHO.
I'll integrate the fix for it into Squeak soon.
If you're impatient you can fix it yourself, or use something else.
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere.
CrLfFileStream is not used, since Squeak 3.x. References to it should be rewritten to use FileStream instead. Using binary mode to work around a bug is bad idea, fixing the bug is the way to go.
But why you stating false statements? CrLfFileStream is used, at least by VMMaker. And i was never took a deep look on a file streams to clearly say if it still used or can be removed.
It's not a false statement, print it: CrLfFileStream new. In Squeak CrLfFileStream is deprecated and if I'm not mistaken the same is true in Pharo.
I'm just trying to eliminate the explicit references to CrLfFileStream in the Cog VMMaker, but I've hit a snag. e.g. there's this idiom:
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := CrLfFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
that I'd like to replace with
VMMaker class methods for utilities newFileStream "Always output files in unix lf format. A single format is friendlier to e.g. external version control systems. The Microsoft and old MacOS classic C compilers all accept lf format files."
^MultiByteFileStream new lineEndConvention: #lf; yourself
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := VMMaker newFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
but only class-side methods understand forceNewFileNamed:, and hence one would have to write
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := MultiByteFileStream forceNewFileNamed: fileName. f lineEndConvention: #lf. f nextPutAll: s. f close
which is a tad tedious and distributed. I could have a set of convenience methods in VMMaker class, forceNewFileStream: oldFileStream etc. There could be subclasses of MultiByteFileStream purely for instance creation (MultiByteLfFileStream et al). Or...? Any thoughts?
best, Eliot
So, can you clarify, can we deprecate and then completely remove CrLfFileStream from image and fix all references to it with FileStream instead? Because i like putting useless cra.. (err stuff) into trash bin.
See above.
Levente
But then again, it means time, which i haven't because i was focused
on completely different problem.
I'll upload my fix to Squeak Trunk this week. Applying the changes to Pharo probably won't work out of the box, because IIRC some issues were solved differently in the past.
i'm not sure.
Levente
-- Best regards, Igor Stasenko AKA sig.
On 17 May 2011 20:27, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Levente,
On Tue, May 17, 2011 at 7:14 AM, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 17 May 2011 13:50, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote:
On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.org wrote:
> > Igor Stasenko uploaded a new version of CMakeVMMaker to project VM > Maker: > http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz > > ==================== Summary ==================== > > Name: CMakeVMMaker-StasenkoIgor.104 > Author: StasenkoIgor > Time: 16 May 2011, 10:33:56 am > UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b > Ancestors: CMakeVMMaker-IgorStasenko.103 > > workaround the MultiByteCrapStream, which converting line endings twice > on > windows.
It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
Tests can greatly decrease the chance of breaking it.
yes, i submitted a test yesterday. http://code.google.com/p/pharo/issues/detail?id=4236
it written in a way to reproduce an issue when running on any system (not just Windows).
I also have some tests which cover more cases.
I don't understand why it patching the UTF8Converter and turns it into line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
The reason is performance, and the implementation is transparent. It also simplifies MultiByteFileStream.
what about clarity? The problem is that this code is so optimized that it is no longer transparent. It is opaque for my eyes. I cannot fix it, because it looks very brittle and it is hard to get what it does, with all those branches, ifNotNils etc etc in almost every method there.
MultiByteFileStream is not clean yet, but it will be.
And i cannot be sure if my fix won't break something else, because there is no clear separation of concerns:
- use UTF8Converter for utf8 conversion and NOTHING else.
- and let stream to filter input and replace cr character(s) to
whatever it wants them to be
And what about simplification?
Do you think this is how a _simple_ method should look like?
nextPut: aCharacter aCharacter isInteger ifTrue: [ ^ super nextPut: aCharacter ]. (wantsLineEndConversion == true and: [ lineEndConvention notNil ]) "#doConversion is inlined here" ifTrue: [ aCharacter = Cr ifTrue: [ converter nextPutAll: (LineEndStrings at: lineEndConvention) toStream: self ] ifFalse: [ converter nextPut: aCharacter toStream: self ]. ^aCharacter ]. ^ self converter nextPut: aCharacter toStream: self
4 branches.. while i, by following your premise, would expect a single line here:
nextPut: aCharacter ^ converter nextPut: aCharacter toStream: self
because if you decided to delegate line ends conversion to converter (for whatever reason) , then you don't have to do anything outside of it.
Exactly. What I also have in my mind is to remove the #isBinary checks from the TextConverters and put them back to MultiByteFileStream, where they belong to IMHO.
I'll integrate the fix for it into Squeak soon. If you're impatient you can fix it yourself, or use something else.
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere.
CrLfFileStream is not used, since Squeak 3.x. References to it should be rewritten to use FileStream instead. Using binary mode to work around a bug is bad idea, fixing the bug is the way to go.
But why you stating false statements? CrLfFileStream is used, at least by VMMaker. And i was never took a deep look on a file streams to clearly say if it still used or can be removed.
It's not a false statement, print it: CrLfFileStream new. In Squeak CrLfFileStream is deprecated and if I'm not mistaken the same is true in Pharo.
I'm just trying to eliminate the explicit references to CrLfFileStream in the Cog VMMaker, but I've hit a snag. e.g. there's this idiom: InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name." | f | f := CrLfFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close. that I'd like to replace with VMMaker class methods for utilities newFileStream "Always output files in unix lf format. A single format is friendlier to e.g. external version control systems. The Microsoft and old MacOS classic C compilers all accept lf format files." ^MultiByteFileStream new lineEndConvention: #lf; yourself InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name." | f | f := VMMaker newFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close. but only class-side methods understand forceNewFileNamed:, and hence one would have to write
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name." | f | f := MultiByteFileStream forceNewFileNamed: fileName. f lineEndConvention: #lf. f nextPutAll: s. f close which is a tad tedious and distributed. I could have a set of convenience methods in VMMaker class, forceNewFileStream: oldFileStream etc. There could be subclasses of MultiByteFileStream purely for instance creation (MultiByteLfFileStream et al). Or...? Any thoughts?
But why you want to explicitly control line ends? Because if you do it like that its not too different to what i have proposed: use a stream in binary mode and deal with line ends inside VMMaker and don't bother with what MultiByteFileStream provides in this regard.
best, Eliot
On Tue, May 17, 2011 at 12:51 PM, Igor Stasenko siguctua@gmail.com wrote:
On 17 May 2011 20:27, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Levente,
On Tue, May 17, 2011 at 7:14 AM, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 17 May 2011 13:50, Levente Uzonyi leves@elte.hu wrote:
On Tue, 17 May 2011, Igor Stasenko wrote:
On 16 May 2011 20:21, Levente Uzonyi leves@elte.hu wrote: > > On Mon, 16 May 2011, squeak-dev-noreply@lists.squeakfoundation.orgwrote: > >> >> Igor Stasenko uploaded a new version of CMakeVMMaker to project VM >> Maker: >>
http://www.squeaksource.com/VMMaker/CMakeVMMaker-StasenkoIgor.104.mcz
>> >> ==================== Summary ==================== >> >> Name: CMakeVMMaker-StasenkoIgor.104 >> Author: StasenkoIgor >> Time: 16 May 2011, 10:33:56 am >> UUID: 68959e6f-18b1-304c-a3de-2b84a1f2c93b >> Ancestors: CMakeVMMaker-IgorStasenko.103 >> >> workaround the MultiByteCrapStream, which converting line endings
twice
>> on >> windows. > > It's not crap, just broken.
Well, i don't know better wording for seeing the mess in this implementation. It contains too much bells and whistles and therefore its very easy to break it.
Tests can greatly decrease the chance of breaking it.
yes, i submitted a test yesterday. http://code.google.com/p/pharo/issues/detail?id=4236
it written in a way to reproduce an issue when running on any system (not just Windows).
I also have some tests which cover more cases.
I don't understand why it patching the UTF8Converter and turns it
into
line-ending converter.. as to me, UTF8Converter have nothing to do with line ends, and such abuse of text converters should be strictly prohibited.
The reason is performance, and the implementation is transparent. It
also
simplifies MultiByteFileStream.
what about clarity? The problem is that this code is so optimized that it is no longer transparent. It is opaque for my eyes. I cannot fix it, because it looks very brittle and it is hard to get what it does, with all those branches, ifNotNils etc etc in almost every method there.
MultiByteFileStream is not clean yet, but it will be.
And i cannot be sure if my fix won't break something else, because there is no clear separation of concerns:
- use UTF8Converter for utf8 conversion and NOTHING else.
- and let stream to filter input and replace cr character(s) to
whatever it wants them to be
And what about simplification?
Do you think this is how a _simple_ method should look like?
nextPut: aCharacter aCharacter isInteger ifTrue: [ ^ super nextPut: aCharacter ]. (wantsLineEndConversion == true and: [ lineEndConvention notNil
])
"#doConversion is inlined here" ifTrue: [ aCharacter = Cr ifTrue: [ converter nextPutAll:
(LineEndStrings at:
lineEndConvention) toStream: self ] ifFalse: [ converter nextPut: aCharacter
toStream: self ].
^aCharacter ]. ^ self converter nextPut: aCharacter toStream: self4 branches.. while i, by following your premise, would expect a single line here:
nextPut: aCharacter ^ converter nextPut: aCharacter toStream: self
because if you decided to delegate line ends conversion to converter (for whatever reason) , then you don't have to do anything outside of it.
Exactly. What I also have in my mind is to remove the #isBinary checks
from the TextConverters and put them back to MultiByteFileStream, where they belong to IMHO.
> I'll integrate the fix for it into Squeak soon. > If you're impatient you can fix it yourself, or use something else. >
Well, i can't use something else, because its VMMaker which using CrLfFileStream for producing source files output. Maybe it worth to just use FileStream in binary mode and deal with line ends internally, to not leave chance for clever text streams to interfere.
CrLfFileStream is not used, since Squeak 3.x. References to it should
be
rewritten to use FileStream instead. Using binary mode to work around
a bug
is bad idea, fixing the bug is the way to go.
But why you stating false statements? CrLfFileStream is used, at least by VMMaker. And i was never took a deep look on a file streams to clearly say if it still used or can be removed.
It's not a false statement, print it: CrLfFileStream new. In Squeak
CrLfFileStream is deprecated and if I'm not mistaken the same is true in Pharo.
I'm just trying to eliminate the explicit references to CrLfFileStream in
the Cog VMMaker, but I've hit a snag. e.g. there's this idiom:
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name." | f | f := CrLfFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close. that I'd like to replace with VMMaker class methods for utilities newFileStream "Always output files in unix lf format. A single format is friendlier to e.g. external version control systems. The Microsoft and old MacOS classic C compilers all accept lf format
files."
^MultiByteFileStream new lineEndConvention: #lf; yourself InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name." | f | f := VMMaker newFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close. but only class-side methods understand forceNewFileNamed:, and hence one
would have to write
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name." | f | f := MultiByteFileStream forceNewFileNamed: fileName. f lineEndConvention: #lf. f nextPutAll: s. f close which is a tad tedious and distributed. I could have a set of
convenience methods in VMMaker class, forceNewFileStream: oldFileStream etc. There could be subclasses of MultiByteFileStream purely for instance creation (MultiByteLfFileStream et al). Or...? Any thoughts?
But why you want to explicitly control line ends?
Because all the C compilers I use to build VMs (and have built VMs with) have accepted lf line endings. There is therefore no need and no point in producing source in anything other than lf line ends.
Because if you do it like that its not too different to what i have proposed: use a stream in binary mode and deal with line ends inside VMMaker and don't bother with what MultiByteFileStream provides in this regard.
Seems to be unnecessarily reinventing the wheel.
cheers, Eliot
best, Eliot
-- Best regards, Igor Stasenko AKA sig.
On 17 May 2011 23:10, Eliot Miranda eliot.miranda@gmail.com wrote:
But why you want to explicitly control line ends?
Because all the C compilers I use to build VMs (and have built VMs with) have accepted lf line endings. There is therefore no need and no point in producing source in anything other than lf line ends.
Is MSVC works fine with such line endings as well? Because the main issue with line endings in C is multi-line macros i.e.:
#define foo line1\ line2 ... \ line3
and if compiler don't detects line ends correctly, then you will have syntax errors. For the rest of cases, i think there is no strict dependency on that , and line ends treated just like any other white-space characters (space, tab etc) without any compilation issues.
(Btw that's why i don't like a Python where white space characters are used as a part of syntax, because depending on running platform and which text editor you using, your mileage could vary.. And so, instead of spending time on what you really want to do, you spending time on making parser/compiler to be pleased with inputs you providing. As to me this is too 70's approach, but not 2010's ;) ).
Because if you do it like that its not too different to what i have proposed: use a stream in binary mode and deal with line ends inside VMMaker and don't bother with what MultiByteFileStream provides in this regard.
Seems to be unnecessarily reinventing the wheel.
A kind of, but consider that for this reinvention in CMakeVMMaker there are just a single method, which is responsible for that:
fixLineEndsOf: string ^ string copyReplaceAll: String cr with: String crlf
and of course for non-windows it has a different implementation:
fixLineEndsOf: string ^ string copyReplaceAll: String cr with: String lf
and then its used like this:
write: aContents toFile: aFileName
"write a file to current output directory (buildDir). use line end convention appropriate for config platform"
| bldDir | bldDir := self buildDir. bldDir isString ifTrue: [ bldDir := FileDirectory on: (FileDirectory fullPathForURI: bldDir) ]. bldDir assureExistence. bldDir forceNewFileNamed: aFileName do: [:stream | stream nextPutAll: (self fixLineEndsOf: aContents) ].
This allows me to control output explicitly without relying on clever logic which tries to detect line ends convention based on which platform you running. Because in configs i can be explicit, since i know beforehand where these configs will be used - on Mac, Unix or Windows etc.
And because you are also want to explicitly use lf, i think that reinvention which takes 1 method to implement is worth it, because it providing certain guarantees of what output you will get and be future-proof, no matter what 'improvements' we will have in this area tomorrow :) And i think you already spent more time on it, trying to fit VMMaker's feets into new shoes, while you can spend time to simply implement 1 method and be done with it :)
cheers, Eliot
On Tue, May 17, 2011 at 2:48 PM, Igor Stasenko siguctua@gmail.com wrote:
On 17 May 2011 23:10, Eliot Miranda eliot.miranda@gmail.com wrote:
But why you want to explicitly control line ends?
Because all the C compilers I use to build VMs (and have built VMs with)
have accepted lf line endings. There is therefore no need and no point in producing source in anything other than lf line ends.
Is MSVC works fine with such line endings as well?
Yes, that's what I said. The VisualWorks VM has had line-feed line-endings for decades compiled with MSVC, and Mac's cr-based development tool (whose name escapes me for the moment).
Because the main issue with line endings in C is multi-line macros i.e.:
#define foo line1\ line2 ... \ line3
and if compiler don't detects line ends correctly, then you will have syntax errors.
I don't think so. Either in assembling the macro or in expanding it carriage-returns and line-feeds are eliminated and so in C, AFAIA, it is impossible to embed a line-feed or carriage-return character in a C macro.
For the rest of cases, i think there is no strict dependency on that , and line ends treated just like any other white-space characters (space, tab etc) without any compilation issues.
(Btw that's why i don't like a Python where white space characters are used as a part of syntax, because depending on running platform and which text editor you using, your mileage could vary.. And so, instead of spending time on what you really want to do, you spending time on making parser/compiler to be pleased with inputs you providing. As to me this is too 70's approach, but not 2010's ;) ).
Because if you do it like that its not too different to what i have proposed: use a stream in binary mode and deal with line ends inside VMMaker and don't bother with what MultiByteFileStream provides in this regard.
Seems to be unnecessarily reinventing the wheel.
A kind of, but consider that for this reinvention in CMakeVMMaker there are just a single method, which is responsible for that:
fixLineEndsOf: string ^ string copyReplaceAll: String cr with: String crlf
and of course for non-windows it has a different implementation:
fixLineEndsOf: string ^ string copyReplaceAll: String cr with: String lf
and then its used like this:
write: aContents toFile: aFileName
"write a file to current output directory (buildDir). use line end convention appropriate for config platform" | bldDir | bldDir := self buildDir. bldDir isString ifTrue: [ bldDir := FileDirectory on: (FileDirectoryfullPathForURI: bldDir) ]. bldDir assureExistence.
bldDir forceNewFileNamed: aFileName do: [:stream | stream nextPutAll: (self fixLineEndsOf:aContents) ].
This allows me to control output explicitly without relying on clever logic which tries to detect line ends convention based on which platform you running. Because in configs i can be explicit, since i know beforehand where these configs will be used - on Mac, Unix or Windows etc.
As I've said repeatedly there's no need to produce anything other than lf-endings on all these platforms.
And because you are also want to explicitly use lf, i think that reinvention which takes 1 method to implement is worth it, because it providing certain guarantees of what output you will get and be future-proof, no matter what 'improvements' we will have in this area tomorrow :) And i think you already spent more time on it, trying to fit VMMaker's feets into new shoes, while you can spend time to simply implement 1 method and be done with it :)
Six of one and half a dozen of the other. What I have works fine without adding a buffering step, which is no small issue when the interpreter is nigh on a megabyte. I think I'll stick with what I have thanks. .
cheers, Eliot
-- Best regards, Igor Stasenko AKA sig.
On 18 May 2011 00:06, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, May 17, 2011 at 2:48 PM, Igor Stasenko siguctua@gmail.com wrote:
On 17 May 2011 23:10, Eliot Miranda eliot.miranda@gmail.com wrote:
But why you want to explicitly control line ends?
Because all the C compilers I use to build VMs (and have built VMs with) have accepted lf line endings. There is therefore no need and no point in producing source in anything other than lf line ends.
Is MSVC works fine with such line endings as well?
Yes, that's what I said. The VisualWorks VM has had line-feed line-endings for decades compiled with MSVC, and Mac's cr-based development tool (whose name escapes me for the moment).
Because the main issue with line endings in C is multi-line macros i.e.:
#define foo line1\ line2 ... \ line3
and if compiler don't detects line ends correctly, then you will have syntax errors.
I don't think so. Either in assembling the macro or in expanding it carriage-returns and line-feeds are eliminated and so in C, AFAIA, it is impossible to embed a line-feed or carriage-return character in a C macro.
yeah.. sorry i actually meant to tell that if you output a macro into a file which has a following: #define foo line1<cr><lf><lf> line2 ... \
instead of
#define foo line1<cr><lf> line2 ... \
or #define foo line1<lf> line2 ... \
then you will have problems. But if this a "normal" C code, putting extra line ends somewhere in the middle of file does't causing any problems. i.e.:
void main()<cr><lf> {
and
void main()<cr><lf><lf> {
will be compiled absolutely identically (if we don't take a debug information into account, of course ;).
For the rest of cases, i think there is no strict dependency on that , and line ends treated just like any other white-space characters (space, tab etc) without any compilation issues.
(Btw that's why i don't like a Python where white space characters are used as a part of syntax, because depending on running platform and which text editor you using, your mileage could vary.. And so, instead of spending time on what you really want to do, you spending time on making parser/compiler to be pleased with inputs you providing. As to me this is too 70's approach, but not 2010's ;) ).
Because if you do it like that its not too different to what i have proposed: use a stream in binary mode and deal with line ends inside VMMaker and don't bother with what MultiByteFileStream provides in this regard.
Seems to be unnecessarily reinventing the wheel.
A kind of, but consider that for this reinvention in CMakeVMMaker there are just a single method, which is responsible for that:
fixLineEndsOf: string ^ string copyReplaceAll: String cr with: String crlf
and of course for non-windows it has a different implementation:
fixLineEndsOf: string ^ string copyReplaceAll: String cr with: String lf
and then its used like this:
write: aContents toFile: aFileName
"write a file to current output directory (buildDir). use line end convention appropriate for config platform"
| bldDir |
bldDir := self buildDir.
bldDir isString ifTrue: [ bldDir := FileDirectory on: (FileDirectory fullPathForURI: bldDir) ]. bldDir assureExistence.
bldDir forceNewFileNamed: aFileName do: [:stream | stream nextPutAll: (self fixLineEndsOf: aContents) ].
This allows me to control output explicitly without relying on clever logic which tries to detect line ends convention based on which platform you running. Because in configs i can be explicit, since i know beforehand where these configs will be used - on Mac, Unix or Windows etc.
As I've said repeatedly there's no need to produce anything other than lf-endings on all these platforms.
And because you are also want to explicitly use lf, i think that reinvention which takes 1 method to implement is worth it, because it providing certain guarantees of what output you will get and be future-proof, no matter what 'improvements' we will have in this area tomorrow :) And i think you already spent more time on it, trying to fit VMMaker's feets into new shoes, while you can spend time to simply implement 1 method and be done with it :)
Six of one and half a dozen of the other. What I have works fine without adding a buffering step, which is no small issue when the interpreter is nigh on a megabyte. I think I'll stick with what I have thanks. .
Yeah. No problem. Just as a remark: i were forced to do that, because i cannot rely on flaky stuff, because even if today i will fix that in one image, it doesn't means that this fix will automagically and instantaneously spread over all VMMaker images over the world. And to ensure correct behavior, i had to do it like that.
On Tue, 17 May 2011, Eliot Miranda wrote:
snip
I'm just trying to eliminate the explicit references to CrLfFileStream in the Cog VMMaker, but I've hit a snag. e.g. there's this idiom:
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := CrLfFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
I prefer the *fileNamed:do: versions, because they give less work for the finalization process:
FileStream forceNewFileNamed: fileName do: [ :file | file nextPutAll: s ].
that I'd like to replace with
VMMaker class methods for utilities newFileStream "Always output files in unix lf format. A single format is friendlier to e.g. external version control systems. The Microsoft and old MacOS classic C compilers all accept lf format files."
^MultiByteFileStream new lineEndConvention: #lf; yourself
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := VMMaker newFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
but only class-side methods understand forceNewFileNamed:, and hence one would have to write
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := MultiByteFileStream forceNewFileNamed: fileName. f lineEndConvention: #lf. f nextPutAll: s. f close
which is a tad tedious and distributed. I could have a set of convenience methods in VMMaker class, forceNewFileStream: oldFileStream etc. There could be subclasses of MultiByteFileStream purely for instance creation (MultiByteLfFileStream et al). Or...? Any thoughts?
Or pass everything to the method of VMMaker:
InterpreterPlugin class >> #storeString: s onFileNamed: fileName
VMMaker newFileWith: #forceNewFileNamed: named: fileName do: [ :file | file nextPutAll: s ].
VMMaker class >> #newFileWith: creatorSelector named: filename do: aBlock
| file | file := MultiByteFileStream perform: creatorSelector with: filename. ^[ file lineEndConvention: #lf. aBlock value: file ] ensure: [ file close ].
If you find #newFileWith:named:do: too long, then you can still add convenience methods which all send this one, e.g.:
VMMaker class >> #forceNewFileNamed: filename do: aBlock
^self newFileWith: #forceNewFileNamed: named: filename do: aBlock
Subclassing is also possible, but you can't override #initialize yet, because FileStream and subclasses don't use it (#new doesn't sent it). The changes I just pushed to the Inbox also fix this.
Levente
best, Eliot
snip
On 17.05.2011 20:27, Eliot Miranda wrote:
I'm just trying to eliminate the explicit references to CrLfFileStream in the Cog VMMaker, but I've hit a snag. e.g. there's this idiom:
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := CrLfFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
that I'd like to replace with
VMMaker class methods for utilities newFileStream "Always output files in unix lf format. A single format is friendlier to e.g. external version control systems. The Microsoft and old MacOS classic C compilers all accept lf format files."
^MultiByteFileStream new lineEndConvention: #lf; yourself
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := VMMaker newFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
but only class-side methods understand forceNewFileNamed:, and hence one would have to write
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := MultiByteFileStream forceNewFileNamed: fileName. f lineEndConvention: #lf. f nextPutAll: s. f close
which is a tad tedious and distributed. I could have a set of convenience methods in VMMaker class, forceNewFileStream: oldFileStream etc. There could be subclasses of MultiByteFileStream purely for instance creation (MultiByteLfFileStream et al). Or...? Any thoughts?
best, Eliot
I'd suggest wrappingthe *fileNamed:do: protocol in a new class, state in the class comment that it's only purpose is to ensure all VM files are written with consistent line endings, and use that class' methods exclusively elsewhere. Doesn't even need to be a subclass really:
VMFileStream class >> forceNewNamed: fileName do: aBlock ^FileStream forceNewFileNamed: fileName do: [:fs | fs lineEndConvention: #lf. aBlock value: fs]
Basically, reintroduce a variant of CRLFFileStream for use specifically in the VM :)
Cheers, Henry
On Wed, May 18, 2011 at 10:40:25AM +0200, Henrik Sperre Johansen wrote:
On 17.05.2011 20:27, Eliot Miranda wrote:
I'm just trying to eliminate the explicit references to CrLfFileStream in the Cog VMMaker, but I've hit a snag.
Hi Eliot,
I don't know if you have done anything further on this, but the attached is a trivial replacement for CrLfFileStream that can be used in VMMaker to get rid of the CrLfFileStream dependency and produce <lf> line terminators in the generated sources.
I tried this in VMMaker, changing the references from CrLfFileStream to CCodeFileStream, and it seems fine for all the source code generation.
Let me know what approach you are taking and I'll add the same to VMMaker classic.
HTH, Dave
e.g. there's this idiom:
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := CrLfFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
that I'd like to replace with
VMMaker class methods for utilities newFileStream "Always output files in unix lf format. A single format is friendlier to e.g. external version control systems. The Microsoft and old MacOS classic C compilers all accept lf format files."
^MultiByteFileStream new lineEndConvention: #lf; yourself
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := VMMaker newFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
but only class-side methods understand forceNewFileNamed:, and hence one would have to write
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := MultiByteFileStream forceNewFileNamed: fileName. f lineEndConvention: #lf. f nextPutAll: s. f close
which is a tad tedious and distributed. I could have a set of convenience methods in VMMaker class, forceNewFileStream: oldFileStream etc. There could be subclasses of MultiByteFileStream purely for instance creation (MultiByteLfFileStream et al). Or...? Any thoughts?
best, Eliot
I'd suggest wrappingthe *fileNamed:do: protocol in a new class, state in the class comment that it's only purpose is to ensure all VM files are written with consistent line endings, and use that class' methods exclusively elsewhere. Doesn't even need to be a subclass really:
VMFileStream class >> forceNewNamed: fileName do: aBlock ^FileStream forceNewFileNamed: fileName do: [:fs | fs lineEndConvention: #lf. aBlock value: fs]
Basically, reintroduce a variant of CRLFFileStream for use specifically in the VM :)
Cheers, Henry
On Sat, May 21, 2011 at 7:44 AM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 18, 2011 at 10:40:25AM +0200, Henrik Sperre Johansen wrote:
On 17.05.2011 20:27, Eliot Miranda wrote:
I'm just trying to eliminate the explicit references to CrLfFileStream in the Cog VMMaker, but I've hit a snag.
Hi Eliot,
I don't know if you have done anything further on this,
yes, I added a single method cuxz there's really only the one case, forceNewFileNamed:. So just one more thing to merge when we get to it :)
but thanks!
but the attached is a trivial replacement for CrLfFileStream that can be used in VMMaker to get rid of the CrLfFileStream dependency and produce <lf> line terminators in the generated sources.
I tried this in VMMaker, changing the references from CrLfFileStream to CCodeFileStream, and it seems fine for all the source code generation.
Let me know what approach you are taking and I'll add the same to VMMaker classic.
HTH, Dave
e.g. there's this idiom:
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := CrLfFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
that I'd like to replace with
VMMaker class methods for utilities newFileStream "Always output files in unix lf format. A single format is friendlier to e.g. external version control systems. The Microsoft and old MacOS classic C compilers all accept lf format files."
^MultiByteFileStream new lineEndConvention: #lf; yourself
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := VMMaker newFileStream forceNewFileNamed: fileName. f nextPutAll: s. f close.
but only class-side methods understand forceNewFileNamed:, and hence one would have to write
InterpreterPlugin class methods for translation storeString: s onFileNamed: fileName "Store the given string in a file of the given name."
| f | f := MultiByteFileStream forceNewFileNamed: fileName. f lineEndConvention: #lf. f nextPutAll: s. f close
which is a tad tedious and distributed. I could have a set of convenience methods in VMMaker class, forceNewFileStream: oldFileStream etc. There could be subclasses of MultiByteFileStream purely for instance creation (MultiByteLfFileStream et al). Or...? Any thoughts?
best, Eliot
I'd suggest wrappingthe *fileNamed:do: protocol in a new class, state in the class comment that it's only purpose is to ensure all VM files are written with consistent line endings, and use that class' methods exclusively elsewhere. Doesn't even need to be a subclass really:
VMFileStream class >> forceNewNamed: fileName do: aBlock ^FileStream forceNewFileNamed: fileName do: [:fs | fs lineEndConvention: #lf. aBlock value: fs]
Basically, reintroduce a variant of CRLFFileStream for use specifically in the VM :)
Cheers, Henry
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Eliot Miranda -
Henrik Sperre Johansen -
Igor Stasenko -
Levente Uzonyi -
squeak-dev-noreply＠lists.squeakfoundation.org