3.9 Oddities
Locked
123
123
 
|
Rich Warren schrieb:
> How often is removing <lf> an issue. Often enough to not be done automatically. It took editors a lot of time to become binary-safe, most still are not. You also need UI to show which line end convention is active, and you need to provide conversion methods. > How did the <lf>'s get into the code base to begin with? They were invisible. > Unless there's a strong reason to the contrary, the editors should > follow the old CS advice. Be generous in what you accept, be strict in > what you transmit (in this case, in what you save). Indeed. Another important principle is that a visualization is invalid if it hides important details. The code editor *must* show exactly what it is editing. I agree that the LFs are ugly, but its way better than dropping them silently. > You have yet to convince me I don't have to convince you of anything. You have to convince us to change the status quo. A good implementation is very convincing ;-) > To me, this seems like a poor design decision. I think there will be a > lot of unforeseen consequences (for example, making Squeak incompatible > with windows text files). It's as compatible as it ever was. The behavior is exactly the same as in 3.8, but you now *see* that something is wrong. If in 3.8 you edit a windows CRLF file it appears fine. You press return, which inserts a CR. You save the file, and *boom*, a wrong line end in your file that other software may trip about. Like notepad. And you saw *nothing* in the Squeak editor. - Bert - |
|
|
In reply to this post by David T. Lewis
David,
> Nowadays, Squeak uses MultiByteFileStream as its default, so changing back > to to CrLfFileStream might have some bad side effects (I don't know, > but I'm mentioning it as a caution). It certainly won't work for Squeak's > multilingual support, but this may not be important for you if you > mainly work in English. CrLfFileStream is pretty much an alias of MultiByteFileStream (see CrLfFileStream class>>new). Has anybody mentioned to Rich that one of the reason is that the compiled methods hold integer indice into .changes and .sources files? -- Yoshiki |
|
|
In reply to this post by Bert Freudenberg
+ 1
Stef On 8 sept. 06, at 12:35, Bert Freudenberg wrote: > Rich Warren schrieb: > >> How often is removing <lf> an issue. > > Often enough to not be done automatically. It took editors a lot of > time to become binary-safe, most still are not. You also need UI to > show which line end convention is active, and you need to provide > conversion methods. > >> How did the <lf>'s get into the code base to begin with? > > They were invisible. > >> Unless there's a strong reason to the contrary, the editors should >> follow the old CS advice. Be generous in what you accept, be >> strict in what you transmit (in this case, in what you save). > > Indeed. Another important principle is that a visualization is > invalid if it hides important details. The code editor *must* show > exactly what it is editing. I agree that the LFs are ugly, but its > way better than dropping them silently. > >> You have yet to convince me > > I don't have to convince you of anything. You have to convince us > to change the status quo. A good implementation is very convincing ;-) > >> To me, this seems like a poor design decision. I think there will >> be a lot of unforeseen consequences (for example, making Squeak >> incompatible with windows text files). > > It's as compatible as it ever was. The behavior is exactly the same > as in 3.8, but you now *see* that something is wrong. > > If in 3.8 you edit a windows CRLF file it appears fine. You press > return, which inserts a CR. You save the file, and *boom*, a wrong > line end in your file that other software may trip about. Like > notepad. And you saw *nothing* in the Squeak editor. > > - Bert - > |
|
|
In reply to this post by Yoshiki Ohshima
Yoshiki Ohshima wrote:
> Has anybody mentioned to Rich that one of the reason is that the > compiled methods hold integer indice into .changes and .sources files? This is not a valid reason (as are all the others in my opinion). Transparent Cr/Lf handling does not prevent byte-oriented positioning which is the only requirement for indexing sources and changes file. I have advocated the use of CrLfFileStream since 1997 and nobody has ever brought a technical reason forward why this wouldn't be feasible. I still feel just as strongly as back then and it's plain incomprehensible (in particular for source code) not to do CrLf conversion upon input. Why would we *knowingly* screw up the source code with Lfs intermingled? Cheers, - Andreas |
|
|
In reply to this post by Bert Freudenberg
You guys are talking besides each other. What Rich is (rightfully)
complaining about is that in 3.9 source code *looks* screwy. The reason being that in 3.9 (the for Squeak invalid) Lf characters get displayed. Which is accurate and advantageous about having them and *not* displaying them but points out the need to do normalization of line ends instead of just ignoring them. In short: The display of Lf and other unprintables is good. Having Lfs is bad. Let's leave the good and fix the bad, e.g., normalize line ends on input. Cheers, - Andreas Bert Freudenberg wrote: > Rich Warren schrieb: > >> How often is removing <lf> an issue. > > Often enough to not be done automatically. It took editors a lot of time > to become binary-safe, most still are not. You also need UI to show > which line end convention is active, and you need to provide conversion > methods. > >> How did the <lf>'s get into the code base to begin with? > > They were invisible. > >> Unless there's a strong reason to the contrary, the editors should >> follow the old CS advice. Be generous in what you accept, be strict in >> what you transmit (in this case, in what you save). > > Indeed. Another important principle is that a visualization is invalid > if it hides important details. The code editor *must* show exactly what > it is editing. I agree that the LFs are ugly, but its way better than > dropping them silently. > >> You have yet to convince me > > I don't have to convince you of anything. You have to convince us to > change the status quo. A good implementation is very convincing ;-) > >> To me, this seems like a poor design decision. I think there will be a >> lot of unforeseen consequences (for example, making Squeak >> incompatible with windows text files). > > It's as compatible as it ever was. The behavior is exactly the same as > in 3.8, but you now *see* that something is wrong. > > If in 3.8 you edit a windows CRLF file it appears fine. You press > return, which inserts a CR. You save the file, and *boom*, a wrong line > end in your file that other software may trip about. Like notepad. And > you saw *nothing* in the Squeak editor. > > - Bert - > > |
|
|
Ok for me if someone has code for 3.10.
For now I'm more than happy that I could spot the problems. But indeed let's move > You guys are talking besides each other. What Rich is (rightfully) > complaining about is that in 3.9 source code *looks* screwy. The > reason being that in 3.9 (the for Squeak invalid) Lf characters get > displayed. Which is accurate and advantageous about having them and > *not* displaying them but points out the need to do normalization > of line ends instead of just ignoring them. In short: The display > of Lf and other unprintables is good. Having Lfs is bad. Let's > leave the good and fix the bad, e.g., normalize line ends on input. > > Cheers, > - Andreas |
|
|
In reply to this post by Yoshiki Ohshima
On Fri, Sep 08, 2006 at 01:58:50PM -0400, Yoshiki Ohshima wrote:
> David, > > > Nowadays, Squeak uses MultiByteFileStream as its default, so changing back > > to to CrLfFileStream might have some bad side effects (I don't know, > > but I'm mentioning it as a caution). It certainly won't work for Squeak's > > multilingual support, but this may not be important for you if you > > mainly work in English. > > CrLfFileStream is pretty much an alias of MultiByteFileStream (see > CrLfFileStream class>>new). Yoshiki, Thank you for the correction. This is nicely implemented. > Has anybody mentioned to Rich that one of the reason is that the > compiled methods hold integer indice into .changes and .sources files? Not until now ;) Dave |
|
|
In reply to this post by Andreas.Raab
On 9-Sep-06, at 12:44 AM, Andreas Raab wrote: > Yoshiki Ohshima wrote: >> Has anybody mentioned to Rich that one of the reason is that the >> compiled methods hold integer indice into .changes and .sources >> files? > > This is not a valid reason (as are all the others in my opinion). > Transparent Cr/Lf handling does not prevent byte-oriented > positioning which is the only requirement for indexing sources and > changes file. I have advocated the use of CrLfFileStream since 1997 > and nobody has ever brought a technical reason forward why this > wouldn't be feasible. Well as I recall it, you were employed in the thick of the team of people with control over the image for several years around that time. What were the reasons for not adopting such a filestream back then? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SCS: Spurious Cold Start |
|
|
tim Rowledge wrote:
> Well as I recall it, you were employed in the thick of the team of > people with control over the image for several years around that time. > What were the reasons for not adopting such a filestream back then? Because I was the only non-Mac user in an otherwise 100% Mac environment ;-) And for some of these things I just couldn't convince the gang that it's worthwhile (otherwise we would have also switched the yellow/blue button definitions, use local coordinates in Morphic and some other things). Cheers, - Andreas |
|
|
On 9-Sep-06, at 9:26 AM, Andreas Raab wrote: > tim Rowledge wrote: >> Well as I recall it, you were employed in the thick of the team of >> people with control over the image for several years around that >> time. What were the reasons for not adopting such a filestream >> back then? > > Because I was the only non-Mac user in an otherwise 100% Mac > environment ;-) Interesting - so the problems faced by all the unix and windows users weren't thought important. Tut-tut. > And for some of these things I just couldn't convince the gang that > it's worthwhile (otherwise we would have also switched the yellow/ > blue button definitions Never! The *only* machines that had a sensible mouse as standard along with a reasonable and compatible button usage were RISC OS ones. Well, for what it's worth I'm strongly in favour of filestreams having the capability of handling line-end translation. It worked for a long time in Smalltalk-80v2 IIRC and still does in VW. I don't care much how the implementation is done but it really ought to be the case that as user of the filestream can use 'FileStream' and whatever needs to be done is hidden. We could have it wrapping a CRLFTranslatingFileStream or a NoTranslatingFileStream or a MultibyteFileStream, or using state variable or whatever, but you simply shouldn't have to know. Tell your filestream '#binary' if you want raw bytes, #text for translated text, whatever. Just look at FileStream. I mean, really. The class comment is a disgrace. And then 'StandardFileStream' - standard how? And why are assorted font readers implemented as subclasses of CrLfFileStream? And HTMLFileStream? Euch. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: IAM: Increase Amperage Above Maximum |
|
|
tim Rowledge wrote:
>> Because I was the only non-Mac user in an otherwise 100% Mac >> environment ;-) > Interesting - so the problems faced by all the unix and windows users > weren't thought important. Tut-tut. No tut-tut. Remember, we weren't vendors. You have to look at this (and other decisions) in relation to the big fish we were trying to fry (which was NOT to build a "free Smalltalk" even though that's what it unfortunately degenerated to). >> And for some of these things I just couldn't convince the gang that >> it's worthwhile (otherwise we would have also switched the yellow/blue >> button definitions > Never! The *only* machines that had a sensible mouse as standard along > with a reasonable and compatible button usage were RISC OS ones. Well, these days the standard is pretty obvious: Windows: Right button operates the context menu MacOSX: Right button operates the context menu Gnome: Right button operates the context menu Do you see a pattern? > Just look at FileStream. I mean, really. The class comment is a > disgrace. And then 'StandardFileStream' - standard how? And why are > assorted font readers implemented as subclasses of CrLfFileStream? And > HTMLFileStream? Euch. Euch indeed. Cheers, - Andreas |
|
|
On 9-Sep-06, at 11:01 AM, Andreas Raab wrote: >>> And for some of these things I just couldn't convince the gang >>> that it's worthwhile (otherwise we would have also switched the >>> yellow/blue button definitions >> Never! The *only* machines that had a sensible mouse as standard >> along with a reasonable and compatible button usage were RISC OS >> ones. > > Well, these days the standard is pretty obvious: > Windows: Right button operates the context menu > MacOSX: Right button operates the context menu > Gnome: Right button operates the context menu > Do you see a pattern? Speaking of buttons, I guess I modify things to let people decided whatever they wish... say #Button1=red #Button2=blue #Button3=yellow #Button1Option=purple #Button1Cmd=pink #Button2Option=pastel #Button2Cmd=green #Button3Option=black #Button3Cmd=white Likely I will set things up to default to ancient macintosh pattern, unless there is an outcry, but it seems there isn't much interest. That way they can pick 'broken' windows, or non-broken windows, 3 button mice windows with furry feet, and perhaps Vista is different? Or ancient macintosh or whatever to suit their desires. -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
In reply to this post by Andreas.Raab
On Sep 8, 2006, at 9:44 PM, Andreas Raab wrote: > Yoshiki Ohshima wrote: >> Has anybody mentioned to Rich that one of the reason is that the >> compiled methods hold integer indice into .changes and .sources >> files? > > This is not a valid reason (as are all the others in my opinion). > Transparent Cr/Lf handling does not prevent byte-oriented > positioning which is the only requirement for indexing sources and > changes file. I have advocated the use of CrLfFileStream since 1997 > and nobody has ever brought a technical reason forward why this > wouldn't be feasible. I still feel just as strongly as back then > and it's plain incomprehensible (in particular for source code) not > to do CrLf conversion upon input. Why would we *knowingly* screw up > the source code with Lfs intermingled? > > Cheers, > - Andreas > This is exactly my feeling. Here's something else to mull over. It's a quote from the Java API: "There are two properties which deal with newlines. The system property, line.separator, is defined to be platform-dependent, either "\n", "\r", or "\r\n". There is also a property defined in DefaultEditorKit, called EndOfLineStringProperty, which is defined automatically when a document is loaded, to be the first occurrence of any of the newline characters. When a document is loaded, EndOfLineStringProperty is set appropriately, and when the document is written back out, the EndOfLineStringProperty is used. But while the document is in memory, the "\n" character is used to define a newline, regardless of how the newline is defined when the document is on disk." So, even Java handles this in a reasonable way. (Please note that this even applies to opening a "foreign" text file, editing it and saving. The file will have newlines saved in the original format-- everything is handled transparently). I hate to think Java is better than Squeak... -Rich- |
|
|
In reply to this post by Bert Freudenberg
On Sep 8, 2006, at 12:35 AM, Bert Freudenberg wrote: > Rich Warren schrieb: > >> How often is removing <lf> an issue. > > Often enough to not be done automatically. It took editors a lot of > time to become binary-safe, most still are not. You also need UI to > show which line end convention is active, and you need to provide > conversion methods. Maybe I asked the wrong question. Can you give me an example where automatically replacing an invalid EOL character with a proper one (eg replace <cr><lf> with <cr> or replacing a solitary <lf> with <cr>) results in a bug? Can you show me an instance where having the <lf> causes a bug in the code? The "uglified" code seems to work just fine, whether or not it has the <lf>'s. > >> How did the <lf>'s get into the code base to begin with? > > They were invisible. No, this is "why are they still in the code base?" I asked a different question. How did they get in there in the first place? I doubt people entered <lf> at the keyboard. Did they get pasted into Squeak? Were they loaded from files? It seems like line normalization should be done at the port of entry. > >> You have yet to convince me > > I don't have to convince you of anything. You have to convince us > to change the status quo. A good implementation is very convincing ;-) If you want me to agree with you, then you need to convince me. Sorry, I just assumed the first part of that sentence went without saying. If you don't care what I think, then no. You don't have to do anything. > >> To me, this seems like a poor design decision. I think there will >> be a lot of unforeseen consequences (for example, making Squeak >> incompatible with windows text files). > > It's as compatible as it ever was. The behavior is exactly the same > as in 3.8, but you now *see* that something is wrong. > > If in 3.8 you edit a windows CRLF file it appears fine. You press > return, which inserts a CR. You save the file, and *boom*, a wrong > line end in your file that other software may trip about. Like > notepad. And you saw *nothing* in the Squeak editor. Yes, this is a bug, but it's a different bug. Arguably it's a lesser bug. The number of cases where it becomes an issue (open CRLF file in Squeak, modify file in Squeak, Save file, and then open in an external editor) is a subset of the cases where 3.9 causes problems (open CRLF file in Squeak). So, 3.8 is more compatible, because at least it lets me open and read CRLF files transparently. -Rich- |
|
|
So after all of this energetic opinionating, have you bothered to
take the time to enable CrLfFileStream in your own image? It will take you about 20 keystrokes, which could doubtless be improved, but is still considerably less that it took me to to compose this note. On Sat, Sep 09, 2006 at 03:55:58PM -1000, Rich Warren wrote: > > On Sep 8, 2006, at 12:35 AM, Bert Freudenberg wrote: > > >Rich Warren schrieb: > > > >>How often is removing <lf> an issue. > > > >Often enough to not be done automatically. It took editors a lot of > >time to become binary-safe, most still are not. You also need UI to > >show which line end convention is active, and you need to provide > >conversion methods. > > Maybe I asked the wrong question. Can you give me an example where > automatically replacing an invalid EOL character with a proper one > (eg replace <cr><lf> with <cr> or replacing a solitary <lf> with > <cr>) results in a bug? > > Can you show me an instance where having the <lf> causes a bug in the > code? > > The "uglified" code seems to work just fine, whether or not it has > the <lf>'s. > > > > >>How did the <lf>'s get into the code base to begin with? > > > >They were invisible. > > No, this is "why are they still in the code base?" I asked a > different question. How did they get in there in the first place? I > doubt people entered <lf> at the keyboard. Did they get pasted into > Squeak? Were they loaded from files? It seems like line normalization > should be done at the port of entry. > > > > >>You have yet to convince me > > > >I don't have to convince you of anything. You have to convince us > >to change the status quo. A good implementation is very convincing ;-) > > If you want me to agree with you, then you need to convince me. > Sorry, I just assumed the first part of that sentence went without > saying. If you don't care what I think, then no. You don't have to do > anything. > > > > >>To me, this seems like a poor design decision. I think there will > >>be a lot of unforeseen consequences (for example, making Squeak > >>incompatible with windows text files). > > > >It's as compatible as it ever was. The behavior is exactly the same > >as in 3.8, but you now *see* that something is wrong. > > > >If in 3.8 you edit a windows CRLF file it appears fine. You press > >return, which inserts a CR. You save the file, and *boom*, a wrong > >line end in your file that other software may trip about. Like > >notepad. And you saw *nothing* in the Squeak editor. > > Yes, this is a bug, but it's a different bug. Arguably it's a lesser > bug. The number of cases where it becomes an issue (open CRLF file in > Squeak, modify file in Squeak, Save file, and then open in an > external editor) is a subset of the cases where 3.9 causes problems > (open CRLF file in Squeak). > > So, 3.8 is more compatible, because at least it lets me open and read > CRLF files transparently. > > -Rich- |
|
|
On Sep 9, 2006, at 4:14 PM, David T. Lewis wrote: > So after all of this energetic opinionating, have you bothered to > take the time to enable CrLfFileStream in your own image? > It will > take you about 20 keystrokes, which could doubtless be improved, but > is still considerably less that it took me to to compose this note. No. But there's a logical reason (or at least, a reason that seemed logical within the confines of my own mind). Previously you said... > Nowadays, Squeak uses MultiByteFileStream as its default, so > changing back > to to CrLfFileStream might have some bad side effects (I don't know, > but I'm mentioning it as a caution). It certainly won't work for > Squeak's > multilingual support, but this may not be important for you if you > mainly work in English. Which suggests that it would be somewhat risky to switch to CrlFileStream. I was worried that there might be unintended side- effects--especially on packages loaded from squeakmap, and I don't want to make things unstable. As I said earlier, it's easier (or more importantly, safer) to just go back to 3.8. However, there is also a second (and probably more important) reason (which I hinted to earlier). It sounds like 3.9 is moving rapidly towards a final release. I'm not actually sure what a gamma release is--but since most software goes from beta to rc, I guess it's pretty close to final. If 3.9 is released in its current state, then I won't be the only person who loads packages, only to be barraged with ugly boxes littering their code base. I suspect others will also find this disturbing (both from an aesthetics view and from a why-didn't- someone-fix-this-I-wonder-what-else-they-missed view). As I said elsewhere, I think its important to lower the barrier of entry for new Squeakers. It will be a lot easier to convince people to give Squeak an honest try if the code base looks clean. I hate to say it, but appearances are important. And so are first impressions. You're free to ignore everything I've said. But I do think the issue is worth thinking about, and I hope it was worth discussing. -Rich- |
|
|
SqueakCommunity activate: #enlightenedSelfInterest.
... On 9/10/06, Rich Warren <[hidden email]> wrote:
Since you appear somewhat invested in Squeak, you will likely want to explore 3.9 and since this may not get resolved to your liking, knowing whether enabling CrLfFileStream is workable would seem to be valuable. If so, 20 keystrokes is a small price to pay. ... snip ...
Fortunately the discussion isn't closed :-) I agree that it is not a good thing for the official release of Squeak to be displaying boxes - even for many(most?) existing Squeakers. However if people doing all the hard work of getting this out strongly disagree, hopefully they will find it reasonable to place a prominent notice/tip/explanation about end of line handling so that people are aware. Surely the time to do that will be much smaller than the time that will be eaten up in reasonable questions from people who didn't know. This is not an issue that will go away quietly. Laurence -Rich- |
|
|
On Sep 10, 2006, at 4:14 AM, Laurence Rozier wrote: > SqueakCommunity activate: #enlightenedSelfInterest. > > ... > > On 9/10/06, Rich Warren <[hidden email]> wrote: > On Sep 9, 2006, at 4:14 PM, David T. Lewis wrote: > > > So after all of this energetic opinionating, have you bothered to > > take the time to enable CrLfFileStream in your own image? > > It will > > take you about 20 keystrokes, which could doubtless be improved, but > > is still considerably less that it took me to to compose this note. > > No. > > But there's a logical reason (or at least, a reason that seemed > logical within the confines of my own mind). > > Since you appear somewhat invested in Squeak, you will likely want > to explore 3.9 and since this may not get resolved to your liking, > knowing whether enabling CrLfFileStream is workable would seem to > be valuable. If so, 20 keystrokes is a small price to pay. Oh, it's not the 20 keystrokes that worries me. It's the risk of putting my system into an unstable state--particularly a state that may not be immediately obvious, but may lurk in the background and leap out at the worst possible time--for example, when I'm demoing the code for my advisor. So, to use it as a production system, I would need to test it. Really run it through it's paces. And I don't have time for that right now. It's easier to either a) grit my teeth and ignore the boxes or b) go back to 3.8. However, I just wanted to say that I really do appreciate all the work everyone's done on Squeak, and I didn't ever mean to criticize the people or the effort behind this project. I have a tendency to criticize things in direct proportion to how much I like them. If something's crap, I just won't bother. But if I feel it's really close but just not quite right, I tend to really get excitable. Sorry if I ruffled any feathers. -Rich- |
|
|
In reply to this post by Andreas.Raab
On 9 sept. 06, at 20:01, Andreas Raab wrote: > tim Rowledge wrote: >>> Because I was the only non-Mac user in an otherwise 100% Mac >>> environment ;-) >> Interesting - so the problems faced by all the unix and windows >> users weren't thought important. Tut-tut. > > No tut-tut. Remember, we weren't vendors. You have to look at this > (and other decisions) in relation to the big fish we were trying to > fry (which was NOT to build a "free Smalltalk" even though that's > what it unfortunately degenerated to). I'm not sure Squeak is degenerating. At least to my perspective it is getting a system with which people will be able to develop what they want without having to patch and rewrite all the system. Our maybe naive assumptions is that with a cleaner system we can invent new worlds more rapidly and this is what we want to help creating. Stef |
|
|
In reply to this post by Andreas.Raab
On Sat, Sep 09, 2006 at 12:44:23AM -0700, Andreas Raab wrote:
> Yoshiki Ohshima wrote: > > Has anybody mentioned to Rich that one of the reason is that the > >compiled methods hold integer indice into .changes and .sources files? > > This is not a valid reason (as are all the others in my opinion). > Transparent Cr/Lf handling does not prevent byte-oriented positioning > which is the only requirement for indexing sources and changes file. I > have advocated the use of CrLfFileStream since 1997 and nobody has ever > brought a technical reason forward why this wouldn't be feasible. I > still feel just as strongly as back then and it's plain incomprehensible > (in particular for source code) not to do CrLf conversion upon input. > Why would we *knowingly* screw up the source code with Lfs intermingled? Is this something that should be done, and that just requires something to decide to do it? If so, I'll enter a Mantis report so it does not get forgotten for another 5 years. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |