I'm trying to move from 3.8 to 3.9, and I have a couple of odd problems.
In text areas, there are often odd boxes at the beginning of lines. These do not show up in 3.8. Any idea how I can get rid of them?
When I try to change the window colors, I get a ton of Error: key not found messages. I don't really need to change the window colors, but having errors on a built-in feature is a bit disturbing.
Thanks,
-Rich-
On 4 sept. 06, at 11:52, Rich Warren wrote:
I'm trying to move from 3.8 to 3.9, and I have a couple of odd problems.
In text areas, there are often odd boxes at the beginning of lines. These do not show up in 3.8. Any idea how I can get rid of them?
The "odd boxes" are bad characters that before were displayed as character space. And it helps showing when you are copying and pasting code from web page and other foreign source. Often I could not find the bugs and rewrite all the code that the students copied from pdf for example.
When I try to change the window colors, I get a ton of Error: key not found messages. I don't really need to change the window colors, but having errors on a built-in feature is a bit disturbing.
Indeed. Add a bug fix in the bug archive.
Thanks,
-Rich-
On Sep 4, 2006, at 4:03 AM, stéphane ducasse wrote:
On 4 sept. 06, at 11:52, Rich Warren wrote:
I'm trying to move from 3.8 to 3.9, and I have a couple of odd problems.
In text areas, there are often odd boxes at the beginning of lines. These do not show up in 3.8. Any idea how I can get rid of them?
The "odd boxes" are bad characters that before were displayed as character space. And it helps showing when you are copying and pasting code from web page and other foreign source. Often I could not find the bugs and rewrite all the code that the students copied from pdf for example.
They seem so prevalent. I though they might be a difference in EOL symbols between Win/Mac/Unix. Does squeak use a standard end of line character? Or does it vary based on OS. Is there a way you can adjust this setting, or automatically convert documents?
More to the point, why do they show up in 3.9 but not in 3.8?
-Rich-
On 5 sept. 06, at 07:19, Rich Warren wrote:
On Sep 4, 2006, at 4:03 AM, stéphane ducasse wrote:
On 4 sept. 06, at 11:52, Rich Warren wrote:
I'm trying to move from 3.8 to 3.9, and I have a couple of odd problems.
In text areas, there are often odd boxes at the beginning of lines. These do not show up in 3.8. Any idea how I can get rid of them?
The "odd boxes" are bad characters that before were displayed as character space. And it helps showing when you are copying and pasting code from web page and other foreign source. Often I could not find the bugs and rewrite all the code that the students copied from pdf for example.
They seem so prevalent. I though they might be a difference in EOL symbols between Win/Mac/Unix. Does squeak use a standard end of line character? Or does it vary based on OS. Is there a way you can adjust this setting, or automatically convert documents?
More to the point, why do they show up in 3.9 but not in 3.8?
because before there was no glyph for them.
Stef
-Rich-
On Sep 4, 2006, at 9:12 PM, stéphane ducasse wrote:
The "odd boxes" are bad characters that before were displayed as character space. And it helps showing when you are copying and pasting code from web page and other foreign source. Often I could not find the bugs and rewrite all the code that the students copied from pdf for example.
They seem so prevalent. I though they might be a difference in EOL symbols between Win/Mac/Unix. Does squeak use a standard end of line character? Or does it vary based on OS. Is there a way you can adjust this setting, or automatically convert documents?
More to the point, why do they show up in 3.9 but not in 3.8?
because before there was no glyph for them.
I'm sorry, but this really doesn't feel like a satisfactory answer.
I did some digging. It turns out the problem is line feeds. In the good sample I looked at, Squeak was using CR (hex 0D) to represent the end of a line. In the annoying box example, it used CR LF (hex 0D 0A).
Now, if I remember correctly, the first is the standard ASCII newline for Unix. The second is the standard ASCII newline for DOS/Windows. They're both standard EOL markers on their respective platforms (both platforms Squeak supports).
Here's my point. As a cross-platform editor, Squeak must be able to handle these transparently. Either it needs to automatically normalize everything to a single Squeak-standard newline, or it needs to accept both of these (and others, old Mac os used a third newline variant, and there may be some I'm not familiar with) in a reasonable and transparent way.
I should be able to open any ascii text file (regardless of which OS it was written on) and it should appear as it was intended-- regardless of the particular newline encoding.
Displaying the box glyphs is possibly good in some cases (for example, non-ascii codes that may inadvertently get copied from pdfs). A better solution would be to strip out any invalid characters automatically. After all, if they're invalid, they can't be doing anything constructive.
But displaying the box glyphs for standard ASCII DOS/WIN newlines feels like a big step backwards.
-Rich-
On 9/5/06, Rich Warren rwmlist@gmail.com wrote:
Now, if I remember correctly, the first is the standard ASCII newline
Behold the allmighty wikipedia: http://en.wikipedia.org/wiki/Newline
Here's my point. As a cross-platform editor, Squeak must be able to handle these transparently. Either it needs to automatically normalize everything to a single Squeak-standard newline, or it needs to accept both of these
Both approaches (accepting the 3 conventions *and* normalizing) would be best IMHO. Maybe it should normalize only when the text gets modified in another way, so as not to 'gratuitously' modify stuff.
Rich Warren schrieb:
But displaying the box glyphs for standard ASCII DOS/WIN newlines feels like a big step backwards.
It might feel like this, but it is actually a big step forward. Previously, such bad line endings went unnoticed, because you wouldn't see the bad characters. Now, when you open a text file you immediately notice it's wrong, and you can fix it.
IMHO the best thing to do would just to fix the methods that have line feeds in them now.
- Bert -
Yeap! And for me this is really important to see these boxes! in 3.10!
But displaying the box glyphs for standard ASCII DOS/WIN newlines feels like a big step backwards.
It might feel like this, but it is actually a big step forward. Previously, such bad line endings went unnoticed, because you wouldn't see the bad characters. Now, when you open a text file you immediately notice it's wrong, and you can fix it.
IMHO the best thing to do would just to fix the methods that have line feeds in them now.
- Bert -
On Tue, 05 Sep 2006 11:42:04 +0200, Rich Warren wrote: ...
Here's my point.
I do understand your point. But please don't take the following as an offense.
As a cross-platform editor, Squeak must be able to handle these transparently.
Squeak is not the editor (Java is not the editor. Algol is (was :) not the editor). Mind to talk about the tools you critisize. Not every tool is newLine sensitive...
Either it needs to automatically normalize everything to a single Squeak-standard newline, or it needs to accept both of these (and others, old Mac os used a third newline variant, and there may be some I'm not familiar with) in a reasonable and transparent way.
I should be able to open any ascii text file (regardless of which OS it was written on) and it should appear as it was intended--regardless of the particular newline encoding.
Yes, almost everybody complains, see for example
- http://www.google.com/search?q=newline+confusion
I do not believe that there is a simple solution (because then all these complaints would disappear immediately). I believe that a COMPUTER cannot "know" what I want do do (or not to do) with newLines. Perhaps I want to write newLine-compliant text on platform A for use on platform B, who knows.
Displaying the box glyphs is possibly good in some cases (for example, non-ascii codes that may inadvertently get copied from pdfs). A better solution would be to strip out any invalid characters automatically. After all, if they're invalid, they can't be doing anything constructive.
The parser could do that when accepting source code, for sure. But please do not do anything automagically when I just review source code. I would like to see *all* *bugs* *in* *their* *original* *form*.
But displaying the box glyphs for standard ASCII DOS/WIN newlines feels like a big step backwards.
AFAIK there are not so many in the 3.9 Squeak .sources and .changes files (examples are classes VersionNumber and VersionHistory).
/Klaus
-Rich-
On Sep 5, 2006, at 3:22 AM, Klaus D. Witzel wrote:
On Tue, 05 Sep 2006 11:42:04 +0200, Rich Warren wrote: ...
Here's my point.
I do understand your point. But please don't take the following as an offense.
No offense taken.
As a cross-platform editor, Squeak must be able to handle these transparently.
Squeak is not the editor (Java is not the editor. Algol is (was :) not the editor). Mind to talk about the tools you critisize. Not every tool is newLine sensitive...
In java I agree. In Squeak, I have to disagree. When I browse classes in the browser, I can also edit them. The browser is an editor. When I open text files from a file list, I can edit them. The file list is an editor. Squeak is a combination programming language/IDE/ multimedia playground. That's one of the things I love about it. One of its many roles is "text editor."
Either it needs to automatically normalize everything to a single Squeak-standard newline, or it needs to accept both of these (and others, old Mac os used a third newline variant, and there may be some I'm not familiar with) in a reasonable and transparent way.
I should be able to open any ascii text file (regardless of which OS it was written on) and it should appear as it was intended-- regardless of the particular newline encoding.
Yes, almost everybody complains, see for example
I do not believe that there is a simple solution (because then all these complaints would disappear immediately). I believe that a COMPUTER cannot "know" what I want do do (or not to do) with newLines. Perhaps I want to write newLine-compliant text on platform A for use on platform B, who knows.
There are very few newline combinations. While you may not be able to "know" in the absolute sense, you can make a reasonable assumption that would work properly for 99.999% of the cases.
This is actually a solved problem. I have many text editors on my system (BBedit and TextMate to name two) that can open text files which use any of the common newline encodings. They display the text in a reasonable manner, regardless of the encoding. At least in the case of BBedit (though I believe others as well), they save the file in the original encoding, unless you actually ask it to change the line endings.
If other systems can handle this issue seamlessly, why can't we? 3.8 handled it seamlessly? Why can't we distinguish between non-text ascii characters that cause problems for the systems (bugs) and display them as glyphs, and alternate whitespace encoding which has no effect on the system, which gets handled in the 3.8 manner?
Displaying the box glyphs is possibly good in some cases (for example, non-ascii codes that may inadvertently get copied from pdfs). A better solution would be to strip out any invalid characters automatically. After all, if they're invalid, they can't be doing anything constructive.
The parser could do that when accepting source code, for sure. But please do not do anything automagically when I just review source code. I would like to see *all* *bugs* *in* *their* *original* *form*.
Are alternate line endings bugs? If they are bugs, then the code shouldn't run and someone should fix them. Balloon3d has tonnes of line-ending boxes, but I can run 3d code fine. If they're not bugs, then the system should accept them and display them in a reasonable manner.
Maybe there should be a tool that goes through the codebase and strips all unknown glyphs from the text. I don't know. But there are a large number of classes in my system that are littered with annoying boxes (all in the original image or donwloaded from SqueakMap).
-Rich-
On Wed, Sep 06, 2006 at 09:09:27PM -1000, Rich Warren wrote:
There are very few newline combinations. While you may not be able to "know" in the absolute sense, you can make a reasonable assumption that would work properly for 99.999% of the cases.
This is actually a solved problem. I have many text editors on my system (BBedit and TextMate to name two) that can open text files which use any of the common newline encodings. They display the text in a reasonable manner, regardless of the encoding. At least in the case of BBedit (though I believe others as well), they save the file in the original encoding, unless you actually ask it to change the line endings.
If other systems can handle this issue seamlessly, why can't we? 3.8 handled it seamlessly? Why can't we distinguish between non-text ascii characters that cause problems for the systems (bugs) and display them as glyphs, and alternate whitespace encoding which has no effect on the system, which gets handled in the 3.8 manner?
Rich,
You may not be aware of CrLfFileStream, which has been part of Squeak for many years. Setting CrLfFileStream as your default file stream will do pretty much exactly what you are describing. If you want to use it, change FileStream class>>concreteStream to answer CrLfFileStream.
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.
Many people, myself included, prefer not to have Squeak do the automatic line end conversion. But it's largely a matter of personal preference, so give CrLfFileStream a try if you prefer that approach.
Dave
On Sep 6, 2006, at 11:26 PM, David T. Lewis wrote:
On Wed, Sep 06, 2006 at 09:09:27PM -1000, Rich Warren wrote:
Many people, myself included, prefer not to have Squeak do the automatic line end conversion. But it's largely a matter of personal preference, so give CrLfFileStream a try if you prefer that approach.
This is what I'm struggling to understand. What possible benefit is there in not converting line ends? Can you give me an example where converting the line ends would cause a problem?
Here's my view. Back in the dark ages, moving text files from one system to another was a nightmare. There are a number of small unix apps to deal with this very issue. Now, however, transferring text files has become transparent. Modern text editors just deal with the details. If they can handle multibyte strings and various common newline characters (or character combinations) all at the same time, why can't we?
And one more question (ok, series of related questions), if everyone else is completely set against changing the way Squeak handles newlines, what are we going to do with all the existing code that is littered with these ugly glyphs? Surely we're not going to just leave them the way they are?
How are we going to handle viewing and editing text documents-- particularly text documents that come from Windows systems? Is there a benefit to displaying the text in a way other than what the author intended? Or are we going to force people to deal with these documents outside the Squeak environment?
What happens if I want to convert an existing web site to seaside? Am I going to be forced to convert all my html documents before I can copy the parts I want and paste them into my seaside application?
I agree that we should leave alone any strange characters that have potentially ambiguous meanings. Displaying them as a default glyph seems reasonable. But, as far as I can tell, the common end of line encodings do not fall into this category.
I'm sorry if I came across too strong earlier. However, this whole issue just seems ridiculous to me. If there's a good reason for it, fine. I'd love to hear it. But, if we're creating problems in a large number of cases just to solve a few odd corner cases (or worse yet, creating problems with no benefit whatsoever), then I think its a bad trade.
-Rich-
On Thu, Sep 07, 2006 at 12:11:34AM -1000, Rich Warren wrote:
On Sep 6, 2006, at 11:26 PM, David T. Lewis wrote:
On Wed, Sep 06, 2006 at 09:09:27PM -1000, Rich Warren wrote:
Many people, myself included, prefer not to have Squeak do the automatic line end conversion. But it's largely a matter of personal preference, so give CrLfFileStream a try if you prefer that approach.
This is what I'm struggling to understand. What possible benefit is there in not converting line ends? Can you give me an example where converting the line ends would cause a problem?
I didn't say there was a problem. I said that this is my own personal preference. Which it is.
As for an example, if I want to look at a file and see if it should have <lf> removed, it's harder to do if the tools disguise the line terminators. As a matter of fact, many of the junk characters that you are seeing in Squeak crept in precisely because of people using automatic line conversion, and not noticing that the real contents of some file was incorrectly formatted. So I guess that you could count that as a problem. But really, it's just a matter of preference, so try using CrLfFileStream if you prefer that approach.
Here's my view. Back in the dark ages, moving text files from one system to another was a nightmare.
I guess if we were out of the dark ages, we would not still be using files.
Dave
Exactly
As for an example, if I want to look at a file and see if it should have <lf> removed, it's harder to do if the tools disguise the line terminators. As a matter of fact, many of the junk characters that you are seeing in Squeak crept in precisely because of people using automatic line conversion, and not noticing that the real contents of some file was incorrectly formatted. So I guess that you could count that as a problem. But really, it's just a matter of preference, so try using CrLfFileStream if you prefer that approach.
On Sep 7, 2006, at 11:18 AM, David T. Lewis wrote:
This is what I'm struggling to understand. What possible benefit is there in not converting line ends? Can you give me an example where converting the line ends would cause a problem?
I didn't say there was a problem. I said that this is my own personal preference. Which it is.
As for an example, if I want to look at a file and see if it should have <lf> removed, it's harder to do if the tools disguise the line terminators.
OK, here's a followup question. If there's no problem with <lf>, then why do we need to remove them? Does that justify uglifying the existing code base? It seems like way 3.9 handles newlines creates a lot more problems than it solves.
How often is removing <lf> an issue. Could displaying/hiding <lf> be a feature that is toggled on and off? Couldn't <lf> be automatically removed? This really doesn't seem like something humans should be wasting their time doing. This is something that should be automated.
How did the <lf>'s get into the code base to begin with? Can't they be blocked at the entry point? (of course, that doesn't deal with the existing problems--but it seems odd that Squeak would allow me to paste in invalid characters--especially if those characters cause problems).
To me, displaying bad glyphs (at least with the source code in its current shape) is a much worse problem than the issue of finding rogue <lf>'s.
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).
You have yet to convince me that being able to see <lf>'s just so we can delete them is a strong reason. For it to be a strong reason, you need to show 1) that there is a concrete benefit to removing the <lf>'s and 2) that always displaying the <lf>'s so they can be deleted by hand is the best method for dealing with them.
But really, it's just a matter of preference, so try using CrLfFileStream if you prefer that approach.
Realistically speaking, I'll probably just go back to 3.8. However, I would like to do my part to make Squeak better. Part of that includes voicing my opinion when I think things are being changed for the worse.
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). Yes, there are ways to work around the issue, but that's not the point. Not all users will know how to work around the issue. Having a reasonable default behavior is vital.
Here's my view. Back in the dark ages, moving text files from one system to another was a nightmare.
I guess if we were out of the dark ages, we would not still be using files.
Sorry, I don't understand this comment at all.
My point was that now, in the 21st century, our systems should be smart enough to open text files properly, regardless of which system they originated on. For any modern text editor, newline incompatibilities are a think of the past. They should be a thing of the past in Squeak.
Remember, this is an issue that goes well beyond the Squeak source code. There are many reasons why someone might want to open and edit text files within squeak. This change will affect all of them, and will make it much harder to use any text files that came from other sources.
Compatibility is still a good thing. But that's just my 2 cents.
-Rich-
Rich everything is possible with time and money.
OK, here's a followup question. If there's no problem with <lf>, then why do we need to remove them? Does that justify uglifying the existing code base? It seems like way 3.9 handles newlines creates a lot more problems than it solves.
How often is removing <lf> an issue. Could displaying/hiding <lf> be a feature that is toggled on and off? Couldn't <lf> be automatically removed? This really doesn't seem like something humans should be wasting their time doing. This is something that should be automated.
How did the <lf>'s get into the code base to begin with? Can't they be blocked at the entry point? (of course, that doesn't deal with the existing problems--but it seems odd that Squeak would allow me to paste in invalid characters--especially if those characters cause problems).
To me, displaying bad glyphs (at least with the source code in its current shape) is a much worse problem than the issue of finding rogue <lf>'s.
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).
You have yet to convince me that being able to see <lf>'s just so we can delete them is a strong reason. For it to be a strong reason, you need to show 1) that there is a concrete benefit to removing the <lf>'s and 2) that always displaying the <lf>'s so they can be deleted by hand is the best method for dealing with them.
But really, it's just a matter of preference, so try using CrLfFileStream if you prefer that approach.
Realistically speaking, I'll probably just go back to 3.8. However, I would like to do my part to make Squeak better. Part of that includes voicing my opinion when I think things are being changed for the worse.
But this is not worse. Because you have exactly the same problems in 3.8 but you do not see it. So for our perspective this is really worse.
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). Yes, there are ways to work around the issue, but that's not the point. Not all users will know how to work around the issue. Having a reasonable default behavior is vital.
But this was ALWAYS like that. We just display a glyph that was empty before.
Here's my view. Back in the dark ages, moving text files from one system to another was a nightmare.
I guess if we were out of the dark ages, we would not still be using files.
Sorry, I don't understand this comment at all.
My point was that now, in the 21st century, our systems should be smart enough to open text files properly, regardless of which system they originated on. For any modern text editor, newline incompatibilities are a think of the past. They should be a thing of the past in Squeak.
Sure but we do not have the time to build new editor for now. So if you want to see that happening introduce this behavior and send it to us.
Remember, this is an issue that goes well beyond the Squeak source code. There are many reasons why someone might want to open and edit text files within squeak. This change will affect all of them, and will make it much harder to use any text files that came from other sources.
Compatibility is still a good thing. But that's just my 2 cents.
-Rich-
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 -
+ 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 -
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
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 rwmlist@gmail.com 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.
... snip ...
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.
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 rwmlist@gmail.com 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-
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.
Me too. Now we tried to recompile all the code and we failed. So this will be for the next one.
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.
Stef
And one more question (ok, series of related questions), if everyone else is completely set against changing the way Squeak handles newlines, what are we going to do with all the existing code that is littered with these ugly glyphs? Surely we're not going to just leave them the way they are?
who is we? We tried but we got some problems because some packages cannot be reloaded.
How are we going to handle viewing and editing text documents-- particularly text documents that come from Windows systems? Is there a benefit to displaying the text in a way other than what the author intended? Or are we going to force people to deal with these documents outside the Squeak environment?
Better importer/exporters should do the work but someone has to code them.
What happens if I want to convert an existing web site to seaside? Am I going to be forced to convert all my html documents before I can copy the parts I want and paste them into my seaside application?
Have you tried? I guess that only css styles should be converted.
I agree that we should leave alone any strange characters that have potentially ambiguous meanings. Displaying them as a default glyph seems reasonable. But, as far as I can tell, the common end of line encodings do not fall into this category.
I'm sorry if I came across too strong earlier. However, this whole issue just seems ridiculous to me. If there's a good reason for it, fine. I'd love to hear it. But, if we're creating problems in a large number of cases just to solve a few odd corner cases (or worse yet, creating problems with no benefit whatsoever), then I think its a bad trade.
This is not that simple. We are on mac, pc, linux, unix, risc os.......
Stef
On Sep 7, 2006, at 11:58 AM, stéphane ducasse wrote:
I'm sorry if I came across too strong earlier. However, this whole issue just seems ridiculous to me. If there's a good reason for it, fine. I'd love to hear it. But, if we're creating problems in a large number of cases just to solve a few odd corner cases (or worse yet, creating problems with no benefit whatsoever), then I think its a bad trade.
This is not that simple. We are on mac, pc, linux, unix, risc os.......
Stef
Yes, I really think it is that simple. No one has given me any example to the contrary.
The text editors I'm talking about may be single-platform, but they can edit documents produced on any environment (mac, pc, linux, unix, risc os, etc.). They open the documents without problem. They display the documents correctly (and here, I define correctly as "as the original author intended". If the original author put a newline (of whatever variety) the editor displays a newline).
I don't see why displaying newlines is a problem.
-Rich-
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
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
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; tim@rowledge.org; 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; tim@rowledge.org; 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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: 3.9 Oddities Date: Sat, 09 Sep 2006 11:01:33 -0700
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).
Are you saying that squeak being open source/free is a bad thing? Smalltalk probably would have broke into the market a lot sooner if it had not cost to program in it. Squeak may wind up being the single most important thing in the history of smalltalk before all is said and done.
One just has to remember Apple vs. Microsoft. Apple said "write anything you want on our system but we get royalties on it". Microsoft said "write anything you want, no royalty costs from us". One of those two companies almost went extinct, the other contains a couple of guys who show up on the "world's richest people" list.
Are you saying that squeak being open source/free is a bad thing? Smalltalk probably would have broke into the market a lot sooner if it had not cost to program in it. Squeak may wind up being the single most important thing in the history of smalltalk before all is said and done.
One just has to remember Apple vs. Microsoft. Apple said "write anything you want on our system but we get royalties on it". Microsoft said "write anything you want, no royalty costs from us". One of those two companies almost went extinct, the other contains a couple of guys who show up on the "world's richest people" list.
Not sure :) about the reference to Apple ;)
J J wrote:
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).
Are you saying that squeak being open source/free is a bad thing?
No, I'm saying that we failed to achieve what we were aiming for. Squeak being open and free is a very good thing but I'd rather have a media authoring tool used by a huge number of kids than a "free Smalltalk" used by a diminishingly small number of programmers.
Cheers, - Andreas
Ah, I see. But do you think the number of developers using it is diminishing? I would think it is currently on the rise. At least for a while.
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: 3.9 Oddities Date: Mon, 11 Sep 2006 08:11:01 -0400
J J wrote:
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).
Are you saying that squeak being open source/free is a bad thing?
No, I'm saying that we failed to achieve what we were aiming for. Squeak being open and free is a very good thing but I'd rather have a media authoring tool used by a huge number of kids than a "free Smalltalk" used by a diminishingly small number of programmers.
Cheers,
- Andreas
All,
I normally stay out of these conversations because doing is much more important then talking (I like the tag that someone has that says: "talk less, do more" or something like that)
It seems to me that there are a number of people that have put significant time into Smalltalk that are disillusioned by the progress that has been made by other languages. (Including me, I've been doing Smalltalk for 10 years, which is not much by some people's standards but is a significant investment from where I sit)
My opinion for what it is worth is that there has been considerable support for Smalltalk, and many opportunities for the language in the past the have not panned out. Much of that was due to the high cost of entry, and the high cost of support and maintenance.
Although Squeak has been around for a while now it is not as mature as other Smalltalk projects. There is a lot that still needs to be done. I know a lot of people have made suggestions about what should be done (including me), and many people have countered with lots of reasons why they are not done. As a community, if we want to help squeak grow up, we need to find a way to move past this stage of development (call it a transition from a paid project run by very talented visionaries, to a community run development platform [that could still be used as a "media authoring tool used by a huge number of kids"]). I believe that even though it appears that the community is quite small compared to others, we can accomplish a lot with proper organization and commitment. (Look at Seaside as an example)
So my question for the community is this: Can we start a process where we decide which pieces that the community needs, and find a way to help each other achieve those goals. Can we move past this "Scratch your own itch" mentality to a more altruistic, "You scratch my back, I'll scratch yours" philosophy?
My suggestion is for us to start a proper discussion about what really needs to change, and for us to start planning those changes. We need to put a process behind what we are doing and try to commit to those changes. We need a real foundation, real projects, real support, and real progress. Once we organize ourselves then we can talk about increasing the size of our community.
Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com
[Don't bury me where the hills are green, where the water runs cold, or next to a running stream.
Don't bury me where the flowers bloom, where the trees are old, or next to my comfy room,
Don't take me from my nice warm bed, And box me up, Remember what I said.
Don't bury me, cause I'm not dead.]
From: Andreas Raab Sent: Monday, September 11, 2006 8:11 AM
J J wrote:
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).
Are you saying that squeak being open source/free is a bad thing?
No, I'm saying that we failed to achieve what we were aiming for. Squeak being open and free is a very good thing but I'd rather have a media authoring tool used by a huge number of kids than a "free Smalltalk" used by a diminishingly small number of programmers.
Cheers,
- Andreas
From: "Ron Teitelbaum" Ron@USMedRec.com Reply-To: Ron@USMedRec.com, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'The general-purpose Squeak developers list'"squeak-dev@lists.squeakfoundation.org Subject: diminishingly small number of programmers (was: 3.9 Oddities) Date: Mon, 11 Sep 2006 11:04:57 -0400
All,
So my question for the community is this: Can we start a process where we decide which pieces that the community needs, and find a way to help each other achieve those goals. Can we move past this "Scratch your own itch" mentality to a more altruistic, "You scratch my back, I'll scratch yours" philosophy?
My suggestion is for us to start a proper discussion about what really needs to change, and for us to start planning those changes. We need to put a process behind what we are doing and try to commit to those changes. We need a real foundation, real projects, real support, and real progress. Once we organize ourselves then we can talk about increasing the size of our community.
Well I am certainly on board. Once I got a little further with a few things I was planning to attack the documentation situation, but really the first step needs to be the organization, etc. you describe.
Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com
No, I'm saying that we failed to achieve what we were aiming for. Squeak being open and free is a very good thing but I'd rather have a media authoring tool used by a huge number of kids than a "free Smalltalk" used by a diminishingly small number of programmers.
Cheers,
- Andreas
I'd rather see it become a better tool for real programmers and less of a tool for kids, and I also think the number of programmers is on the rise.
On 2006 September 11 08:11, Andreas Raab wrote:
J J wrote:
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).
Are you saying that squeak being open source/free is a bad thing?
No, I'm saying that we failed to achieve what we were aiming for. Squeak being open and free is a very good thing but I'd rather have a media authoring tool used by a huge number of kids
Perhaps did not failed too badly! - I wanted to mention there must be some number of kids, who do get to playing with Squeak even without school and teachers telling them about it. I have some empirical evidence for it :) . A son of my friend (and the son's friend, they are about 12) apparently found and downloaded Squeak, built projects with it, even put together a few games so far. When I asked him if they knew about Squeak because of school, he said no, noone in school told them about Squeak. So there is some grassroot movement :)
Which brings me to another idea I wanted to mention for a while: While steering Squeak as a tool for science and math education, and media playground is good, creating games is something most kids will want to do "naturally" (maybe that should be something like "current culturally"), and interactive games must be a good gateway to Squeak. Yet until recently (last year?), there was no easy way for a Morph to be moved by keyboard arrow, which is a known and simple, although a bit backwards way of interaction; also apart from the (beautiful) car track example there are no other "visible" examples kids could use to start writing simple games. I just wanted to say, creating interactive games seems a good motivator for children to use Squeak.
Milan
than a "free Smalltalk" used by a diminishingly small number of programmers.
Cheers,
- Andreas
Milan Zimmermann puso en su mail :
Which brings me to another idea I wanted to mention for a while: While steering Squeak as a tool for science and math education, and media playground is good, creating games is something most kids will want to do "naturally" (maybe that should be something like "current culturally"), and interactive games must be a good gateway to Squeak. Yet until recently (last year?), there was no easy way for a Morph to be moved by keyboard arrow, which is a known and simple, although a bit backwards way of interaction; also apart from the (beautiful) car track example there are no other "visible" examples kids could use to start writing simple games. I just wanted to say, creating interactive games seems a good motivator for children to use Squeak.
Milan
Milan: As a game build in Squeak fan, I could be online to help any kid in any place. Only I don't know how be in touch with they. My zone time is 09:00 to 20:00 GMT (roughly) . I suppose what a IRC "squeakkids" could be created ?
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
On 2006 October 6 05:08, Edgar J. De Cleene wrote:
Milan Zimmermann puso en su mail :
Which brings me to another idea I wanted to mention for a while: While steering Squeak as a tool for science and math education, and media playground is good, creating games is something most kids will want to do "naturally" (maybe that should be something like "current culturally"), and interactive games must be a good gateway to Squeak. Yet until recently (last year?), there was no easy way for a Morph to be moved by keyboard arrow, which is a known and simple, although a bit backwards way of interaction; also apart from the (beautiful) car track example there are no other "visible" examples kids could use to start writing simple games. I just wanted to say, creating interactive games seems a good motivator for children to use Squeak.
Milan
Milan: As a game build in Squeak fan, I could be online to help any kid in any place. Only I don't know how be in touch with they. My zone time is 09:00 to 20:00 GMT (roughly) . I suppose what a IRC "squeakkids" could be created ?
Hi Edgar,
That may be good idea, although I was more or less thinking about simple games that would be put online perhaps along with simple tutorials; I think at certain age kids prefer to play with software themselves without guidance :)
Milan
Edgar
Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
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-
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
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
On Mon, Sep 04, 2006 at 07:19:16PM -1000, Rich Warren wrote:
They seem so prevalent. I though they might be a difference in EOL symbols between Win/Mac/Unix. Does squeak use a standard end of line character? Or does it vary based on OS. Is there a way you can adjust this setting, or automatically convert documents?
There is no such thing as a "standard end of line character". Certain operating systems and file systems have adopted the convention of treating <cr><lf>, <cr>, or <lf> as deliminators for file records, while many other file systems have an actual concept of "record" that does not require delimiters. Either way, there is no such thing as a standard.
The convention (nothing more, nothing less) for Smalltalk systems is to treat <cr> as a line terminator. This is "incompatible" with Micosoft conventions in the same sense that (for example) Microsoft line end conventions are "incompatible" with Unix systems and vice versa.
All of these conventions date back to teletype hardware. The <cr> means move the carriage to the full left stop position (hence position it at a "new line"). The <lf> means move the platen one line position, but don't move the carriage back to the full left position. This also can reasonably be considered to be a "new line". And of course the combination of <cr><lf> moves the tty carriage back to the full left margin position, then advances the platen to the next line.
If you send <cr><lf> to a real teletype, it really does move to the next "record" on the piece of paper. But if you were trying to conserve bytes in a data file, you might quite reasonably make the case that either <cr> or <lf> by themselves should be taken as a "new line" indicator.
The good folks who invented Unix decided to use <lf>, and the equally good folks who invented Smalltalk decided to use <cr>. The folks who adopted the Microsoft <cr><lf> convention stole the idea from CP/M or some such thing, which was probably stolen from RMX-11. But regardless of who stole what from whom, none of these conventions are in any way standard. They are conventions, no more, no less.
Dave
p.s. The above pertains to ASCII based file conventions. EBCDIC file systems have generally been record oriented from the get-go, and do not seem to engender the sort of confusion that is typical for ASCII based file systems.
On Sep 4, 2006, at 4:03 AM, stéphane ducasse wrote:
When I try to change the window colors, I get a ton of Error: key not found messages. I don't really need to change the window colors, but having errors on a built-in feature is a bit disturbing.
Indeed. Add a bug fix in the bug archive.
While I would hope that someone working on 3.9 would notice that I brought up the issue here and take the initiative to check it out, I tried to go to the squeak site and clicked on the bug reporting link. Unfortunately, I did not find any obvious way to add a bug. I guess I have to register for an account (thought that's never explicitly stated anywhere). Regardless, I don't have the time or energy to deal with it tonight. Maybe I'll get around to it later...
-Rich-
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Damien Pollet -
David T. Lewis -
Edgar J. De Cleene -
J J -
John M McIntosh -
Klaus D. Witzel -
Laurence Rozier -
Milan Zimmermann -
Ramon Leon -
Rich Warren -
Ron Teitelbaum -
stephane ducasse -
stéphane ducasse -
tim Rowledge -
Yoshiki Ohshima