Hi Ken,
Installer is a Squeak utility for loading code. It can install code from changesets and other things, and I recently extended it to allow it to install code hosted on GitHub. A wrinkle was that GitHub only uses SSL, and for the current Squeak VMs that entails additional setup (an additional plugin).
Seeing as I'm interested in your work, I used your code as a guinea pig :).
I didn't expect all the tests to fail - I _am_ loading Cuis code into Squeak, after all. I was just surprised to see _all_ the tests fail, and upon investigation found a number of places where Cuis Strings and Characters use non-Squeak methods. Again, this isn't unexpected. So I wondered, before I delve too deeply into the drift, if perhaps somewhere there was a document that summarised the changes.
frank
On 26 March 2013 04:18, Ken Dickey Ken.Dickey@whidbey.com wrote:
On Mon, 25 Mar 2013 13:48:41 +0000 Frank Shearar frank.shearar@gmail.com wrote:
Frank,
Sorry, I have not been following this discussion and am unsure of the context.
Tests fail for mcz, SSL, GitHub, Cuis-Ropes ??
With respect to the latter, I basically ported most of the Cuis Strings API into Ropes. I have not looked at Squeak in some time, so can't really comment on code drift.
Cheers,
-KenD
The mcz is missing something important, namely
Installer class >> github ^ InstallerGitHub newbut with that in place, and with an SSL plugin installed (the published binaries are 32 bit only; they don't work in an Interpreter built on a 64 bit machine), you can:
(Installer github user: 'KenDickey' repository: 'Cuis-Ropes) install
frank
I should add that in Squeak most of the tests fail. This is likely because of drift between Cuis' and Squeak's String API. Is it possible to find a document somewhere summarising the changes? If so, I'll craft a Cuis-Compatibility package for Squeak.
Thanks!
frank
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-- Ken [dot] Dickey [at] whidbey [dot] com
Yes, a document that summarizes the changes between Cuis and Squeak, is something we need soon. Cuis has advanced very nicely recently and at least for certain fields of application it can be considered the leading Squeak variant when comparing Squeak, Pharo and Cuis.
Regarding compatibility between Squeak and Cuis. What I have seen so far is that there are not all that many issues regarding non-GUI classes. CR/LF is an issue. I have started doing a Cuis-compatibility layer for Squeak. So far it is quite thin. I.e. I manage to develop in Squeak and file in the mcz file into Cuis 4.1. As long as I do not use GUI classes it is fine.
--Hannes
On 3/26/13, Frank Shearar frank.shearar@gmail.com wrote:
Hi Ken,
Installer is a Squeak utility for loading code. It can install code from changesets and other things, and I recently extended it to allow it to install code hosted on GitHub. A wrinkle was that GitHub only uses SSL, and for the current Squeak VMs that entails additional setup (an additional plugin).
Seeing as I'm interested in your work, I used your code as a guinea pig :).
I didn't expect all the tests to fail - I _am_ loading Cuis code into Squeak, after all. I was just surprised to see _all_ the tests fail, and upon investigation found a number of places where Cuis Strings and Characters use non-Squeak methods. Again, this isn't unexpected. So I wondered, before I delve too deeply into the drift, if perhaps somewhere there was a document that summarised the changes.
frank
On 26 March 2013 04:18, Ken Dickey Ken.Dickey@whidbey.com wrote:
On Mon, 25 Mar 2013 13:48:41 +0000 Frank Shearar frank.shearar@gmail.com wrote:
Frank,
Sorry, I have not been following this discussion and am unsure of the context.
Tests fail for mcz, SSL, GitHub, Cuis-Ropes ??
With respect to the latter, I basically ported most of the Cuis Strings API into Ropes. I have not looked at Squeak in some time, so can't really comment on code drift.
Cheers,
-KenD
The mcz is missing something important, namely
Installer class >> github ^ InstallerGitHub newbut with that in place, and with an SSL plugin installed (the published binaries are 32 bit only; they don't work in an Interpreter built on a 64 bit machine), you can:
(Installer github user: 'KenDickey' repository: 'Cuis-Ropes) install
frank
I should add that in Squeak most of the tests fail. This is likely because of drift between Cuis' and Squeak's String API. Is it possible to find a document somewhere summarising the changes? If so, I'll craft a Cuis-Compatibility package for Squeak.
Thanks!
frank
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-- Ken [dot] Dickey [at] whidbey [dot] com
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
That's great news, Hannes!
Obviously I really wouldn't mind seeing String/Character shims in particular :)
frank
On 26 March 2013 09:34, H. Hirzel hannes.hirzel@gmail.com wrote:
Yes, a document that summarizes the changes between Cuis and Squeak, is something we need soon. Cuis has advanced very nicely recently and at least for certain fields of application it can be considered the leading Squeak variant when comparing Squeak, Pharo and Cuis.
Regarding compatibility between Squeak and Cuis. What I have seen so far is that there are not all that many issues regarding non-GUI classes. CR/LF is an issue. I have started doing a Cuis-compatibility layer for Squeak. So far it is quite thin. I.e. I manage to develop in Squeak and file in the mcz file into Cuis 4.1. As long as I do not use GUI classes it is fine.
--Hannes
On 3/26/13, Frank Shearar frank.shearar@gmail.com wrote:
Hi Ken,
Installer is a Squeak utility for loading code. It can install code from changesets and other things, and I recently extended it to allow it to install code hosted on GitHub. A wrinkle was that GitHub only uses SSL, and for the current Squeak VMs that entails additional setup (an additional plugin).
Seeing as I'm interested in your work, I used your code as a guinea pig :).
I didn't expect all the tests to fail - I _am_ loading Cuis code into Squeak, after all. I was just surprised to see _all_ the tests fail, and upon investigation found a number of places where Cuis Strings and Characters use non-Squeak methods. Again, this isn't unexpected. So I wondered, before I delve too deeply into the drift, if perhaps somewhere there was a document that summarised the changes.
frank
On 26 March 2013 04:18, Ken Dickey Ken.Dickey@whidbey.com wrote:
On Mon, 25 Mar 2013 13:48:41 +0000 Frank Shearar frank.shearar@gmail.com wrote:
Frank,
Sorry, I have not been following this discussion and am unsure of the context.
Tests fail for mcz, SSL, GitHub, Cuis-Ropes ??
With respect to the latter, I basically ported most of the Cuis Strings API into Ropes. I have not looked at Squeak in some time, so can't really comment on code drift.
Cheers,
-KenD
The mcz is missing something important, namely
Installer class >> github ^ InstallerGitHub newbut with that in place, and with an SSL plugin installed (the published binaries are 32 bit only; they don't work in an Interpreter built on a 64 bit machine), you can:
(Installer github user: 'KenDickey' repository: 'Cuis-Ropes) install
frank
I should add that in Squeak most of the tests fail. This is likely because of drift between Cuis' and Squeak's String API. Is it possible to find a document somewhere summarising the changes? If so, I'll craft a Cuis-Compatibility package for Squeak.
Thanks!
frank
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-- Ken [dot] Dickey [at] whidbey [dot] com
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Cuis did chose to not support unicode for simplicity and stick to 8-bits chars (CP-1252 ? iso-8859-L1 ? iso-8859-L15 ?). Squeak/Pharo cannot afford this choice. So there will be a few differences here and there.
For line-ending, Cuis could provide a simplified version of nextLine linesDo: etc... based only on CR For the displaying of LF, CR, or any other non printable ASCII that should be generalized and an option available in Squeak too.
Nicolas
2013/3/26 Frank Shearar frank.shearar@gmail.com:
That's great news, Hannes!
Obviously I really wouldn't mind seeing String/Character shims in particular :)
frank
On 26 March 2013 09:34, H. Hirzel hannes.hirzel@gmail.com wrote:
Yes, a document that summarizes the changes between Cuis and Squeak, is something we need soon. Cuis has advanced very nicely recently and at least for certain fields of application it can be considered the leading Squeak variant when comparing Squeak, Pharo and Cuis.
Regarding compatibility between Squeak and Cuis. What I have seen so far is that there are not all that many issues regarding non-GUI classes. CR/LF is an issue. I have started doing a Cuis-compatibility layer for Squeak. So far it is quite thin. I.e. I manage to develop in Squeak and file in the mcz file into Cuis 4.1. As long as I do not use GUI classes it is fine.
--Hannes
On 3/26/13, Frank Shearar frank.shearar@gmail.com wrote:
Hi Ken,
Installer is a Squeak utility for loading code. It can install code from changesets and other things, and I recently extended it to allow it to install code hosted on GitHub. A wrinkle was that GitHub only uses SSL, and for the current Squeak VMs that entails additional setup (an additional plugin).
Seeing as I'm interested in your work, I used your code as a guinea pig :).
I didn't expect all the tests to fail - I _am_ loading Cuis code into Squeak, after all. I was just surprised to see _all_ the tests fail, and upon investigation found a number of places where Cuis Strings and Characters use non-Squeak methods. Again, this isn't unexpected. So I wondered, before I delve too deeply into the drift, if perhaps somewhere there was a document that summarised the changes.
frank
On 26 March 2013 04:18, Ken Dickey Ken.Dickey@whidbey.com wrote:
On Mon, 25 Mar 2013 13:48:41 +0000 Frank Shearar frank.shearar@gmail.com wrote:
Frank,
Sorry, I have not been following this discussion and am unsure of the context.
Tests fail for mcz, SSL, GitHub, Cuis-Ropes ??
With respect to the latter, I basically ported most of the Cuis Strings API into Ropes. I have not looked at Squeak in some time, so can't really comment on code drift.
Cheers,
-KenD
The mcz is missing something important, namely
Installer class >> github ^ InstallerGitHub newbut with that in place, and with an SSL plugin installed (the published binaries are 32 bit only; they don't work in an Interpreter built on a 64 bit machine), you can:
(Installer github user: 'KenDickey' repository: 'Cuis-Ropes) install
frank
I should add that in Squeak most of the tests fail. This is likely because of drift between Cuis' and Squeak's String API. Is it possible to find a document somewhere summarising the changes? If so, I'll craft a Cuis-Compatibility package for Squeak.
Thanks!
frank
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-- Ken [dot] Dickey [at] whidbey [dot] com
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Cuis mailing list Cuis@jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Hi,
Sorry for being a little off topic.
On Tue, 26 Mar 2013 14:22:07 +0100, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
For line-ending, Cuis could provide a simplified version of nextLine linesDo: etc... based only on CR For the displaying of LF, CR, or any other non printable ASCII that should be generalized and an option available in Squeak too.
IMHO a single character line-end of LF (line feed) makes more sense than a CR (carriage return). They both date back to when type writers, TTYs and printers actually had carriages. A carriage return, returned the carriage, allowing to over type/print the line, like for underlining. A line feed made a new line. If we are to drop one of these two (stop using CR, LF - and I think we should when/where we can) then we should keep LF and drop CR.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
On 26 March 2013 13:46, Louis LaBrunda Lou@keystone-software.com wrote:
Hi,
Sorry for being a little off topic.
On Tue, 26 Mar 2013 14:22:07 +0100, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
For line-ending, Cuis could provide a simplified version of nextLine linesDo: etc... based only on CR For the displaying of LF, CR, or any other non printable ASCII that should be generalized and an option available in Squeak too.
IMHO a single character line-end of LF (line feed) makes more sense than a CR (carriage return). They both date back to when type writers, TTYs and printers actually had carriages. A carriage return, returned the carriage, allowing to over type/print the line, like for underlining. A line feed made a new line. If we are to drop one of these two (stop using CR, LF - and I think we should when/where we can) then we should keep LF and drop CR.
The important part isn't so much which line separator you prefer as the method name. With common names, packages could could happily use whatever line ending that fork used.
Does any OS actually use CR anymore? OS X and all the Unices use LF, Windows and the Internet (as in HTTP, and all protocols based on it) use CRLF.
frank
Hi Frank,
The important part isn't so much which line separator you prefer as the method name. With common names, packages could happily use whatever line ending that fork used.
Agreed, I just didn't want to see CR (by itself) chosen over LF.
Does any OS actually use CR anymore? OS X and all the Unices use LF, Windows and the Internet (as in HTTP, and all protocols based on it) use CRLF.
I think you are right again. It would be nice if windows dropped CR as well but that may be very hard to do without making a big mess.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
squeak-dev@lists.squeakfoundation.org
-
Frank Shearar -
H. Hirzel -
Louis LaBrunda -
Nicolas Cellier