-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sending #cr
to a String instantiation stream does not put the #cr
Character
#335
Comments
Yes that does indeed look like a base GemStone bug ... I'll submit an internal bug report... |
Before I submit a bug report, I would like to know more details about your platform and GemStone version. |
We use GemStone/S v3.4.5 on AlmaLinux 9.1 through 9.4, but the example output I gave was produced using the included ‘Dockerfile’, so using v3.6.3 on Ubuntu 20.04. I’m not sure what you mean about it not being viable, is it just that only older versions are supported? |
GsDevkit_home depends upon a 32 bit pharo vm and 20.04 might be the last ubuntu version that GsDevKit_home runs properly ... GsDevKit_stones is the intended replacement, but I haven't had enough "free" time to completely finish the work (i.e., provide the full set of functionality available in GsDevKit_home). With that said, GsDevKit_stones provides about 75% of the GsDevKit_home functionality, with the noticeable exception that it lacks the upgradeImage script and a replacement for the tODE GUI ... The upgradeImage script is planned, but requires a partial rewrite of the support library and scripts ... Rowan 3 is intended to be the replacement for the tODE GUI, but it is not ready (this is where I've been spending my time). If you have questions or comments, I suggest you ask questions on the GLASS mailing list or the GemStone Smalltalk ... there are a number of folks on those lists (including myself) who have started using GsDevKit_stones and there is at least one person who has updated his version of GsDevKit_home to eliminate the use of the 32 bit Pharo vm and you can find his mail in the archives. |
Sending
#cr
to a String instantiation stream given by#streamContents:
unexpectedly puts an#lf
rather than#cr
Character as demonstrated by the example in the Dockerfile given below:I’m mostly adding this issue for reference; the behavior of
#cr
on Stream putting an#lf
Character does seem to be intentional as some subclasses, such as AppendStream and WriteStreamPortable, have an override for#cr
that puts a#cr
Character instead. A question though is whether such an override shouldn’t also apply to the streams that#streamContents:
uses.Dockerfile:
The text was updated successfully, but these errors were encountered: