The Inbox: Installer-Core-fbs.366.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Installer-Core-fbs.366.mcz

commits-2
Frank Shearar uploaded a new version of Installer-Core to project The Inbox:
http://source.squeak.org/inbox/Installer-Core-fbs.366.mcz

==================== Summary ====================

Name: Installer-Core-fbs.366
Author: fbs
Time: 18 March 2013, 11:46:52.277 am
UUID: f665ad84-81d3-4337-8527-4c5f320ec2ab
Ancestors: Installer-Core-fbs.365

InstallerGitHub lets you install source stored in a GitHub repository. It detects FileTree repositories (through the .filetree marker file) and otherwise assumes chunk format.

It will lazily pull in WebClient, SqueakSSL and FileTree as and when necessary. Note that since GitHub uses SSL everywhere, you MUST have the SqueakSSL plugin installed in your VM to use this class.

=============== Diff against Installer-Core-fbs.365 ===============

Item was added:
+ Installer subclass: #InstallerGitHub
+ instanceVariableNames: 'user repository commitId'
+ classVariableNames: ''
+ poolDictionaries: ''
+ category: 'Installer-Core'!
+
+ !InstallerGitHub commentStamp: 'fbs 3/18/2013 11:41' prior: 0!
+ An Installer that can install code stored in GitHub repositories (either in chunk format or FileTree). Typical usage:
+
+ (Installer github
+ user: 'frankshearar' repository: 'Zippers' commitId: 'master') install!

Item was added:
+ ----- Method: InstallerGitHub class>>user:repository: (in category 'instance creation') -----
+ user: userString repository: repoString
+ ^ self basicNew
+ initializeWithUser: userString
+ repository: repoString
+ commitId: 'master'!

Item was added:
+ ----- Method: InstallerGitHub class>>user:repository:commitId: (in category 'instance creation') -----
+ user: userString repository: repoString commitId: treeishString
+ ^ self basicNew
+ initializeWithUser: userString
+ repository: repoString
+ commitId: treeishString!

Item was added:
+ ----- Method: InstallerGitHub>>basicBrowse (in category 'basic interface') -----
+ basicBrowse
+ ^ (Installer url: self gitHubUrl asString) browse!

Item was added:
+ ----- Method: InstallerGitHub>>basicInstall (in category 'basic interface') -----
+ basicInstall
+ | zip webResponse |
+ useFileIn := true.
+ webResponse := self webClientClassReference httpGet: self zipballUrl asString.
+ webResponse isSuccess ifFalse: [self error: ('Failed to download zipball ({1})' format: {webResponse printString})].
+ zip := ZipArchive new
+ readFrom: (RWBinaryOrTextStream with: webResponse content).
+ zip members
+ detect: [:member | member fileName = '.filetree']
+ ifFound: [self loadFiletreeFormatFiles: zip]
+ ifNone: [self loadChunkFormatFiles: zip]!

Item was added:
+ ----- Method: InstallerGitHub>>basicView (in category 'basic interface') -----
+ basicView
+ ^ (Installer url: self gitHubUrl) view!

Item was added:
+ ----- Method: InstallerGitHub>>commitId (in category 'accessing') -----
+ commitId
+ ^ commitId!

Item was added:
+ ----- Method: InstallerGitHub>>createTempDir (in category 'private') -----
+ createTempDir
+ | newDir |
+ "Vulnerable to a time-of-check-time-of-use race."
+ [newDir := UUID new asString.
+ FileDirectory default directoryExists: newDir]
+ whileTrue.
+ ^ FileDirectory default createDirectory: newDir!

Item was added:
+ ----- Method: InstallerGitHub>>fileTreeStReader (in category 'class references') -----
+ fileTreeStReader
+ self class environment
+ at: #MCFileTreeStReader
+ ifPresent: [:cls | ^ cls]
+ ifAbsent: [self installFileTree].
+ ^ self class environment at: #MCFileTreeStReader!

Item was added:
+ ----- Method: InstallerGitHub>>gitHubUrl (in category 'urls') -----
+ gitHubUrl
+ ^ ('https://github.com/{1}/{2}/commits/{3}' format: {user. repository. commitId}) asUrl!

Item was added:
+ ----- Method: InstallerGitHub>>initializeWithUser:repository:commitId: (in category 'initialize-release') -----
+ initializeWithUser: userString repository: repoString commitId: treeishString
+ user := userString.
+ repository := repoString.
+ commitId := treeishString.!

Item was added:
+ ----- Method: InstallerGitHub>>installFiletree (in category 'private') -----
+ installFiletree
+ Installer squeakmap
+ update;
+ install: 'FileTree (for Squeak 4.4)'!

Item was added:
+ ----- Method: InstallerGitHub>>installWebClient (in category 'private') -----
+ installWebClient
+ Installer ss project: 'WebClient';
+ install: 'WebClient-Core-ar.92.mcz'.
+ Installer ss project: 'SqueakSSL';
+ install: 'SqueakSSL-Core-ar.26.mcz'!

Item was added:
+ ----- Method: InstallerGitHub>>loadChunkFormatFiles: (in category 'private') -----
+ loadChunkFormatFiles: zip
+ | defns loader |
+ defns := (zip membersMatching: '*.st')
+ collect: [:member | MCSnapshot fromDefinitions: (MCStReader new stream: member contentStream) definitions].
+ loader := MCPackageLoader new.
+ defns
+ do: [:member | loader installSnapshot: member].
+ loader loadWithName: repository!

Item was added:
+ ----- Method: InstallerGitHub>>loadFiletreeFormatFiles: (in category 'private') -----
+ loadFiletreeFormatFiles: zip
+ "FileTree works with directories. Extract the zip contents, load the definitions, and clean up."
+ | loader tempDir |
+ tempDir := self createTempDirectory.
+ [zip extractAllTo: tempDir.
+ loader := self fileTreeStReader new.
+ loader directory: FileDirectory.
+ loader loadDefinitions.]
+ ensure: [FileDirectory default deleteDirectory: tempDir pathName].!

Item was added:
+ ----- Method: InstallerGitHub>>repository (in category 'accessing') -----
+ repository
+ ^ repository!

Item was added:
+ ----- Method: InstallerGitHub>>user (in category 'accessing') -----
+ user
+ ^ user!

Item was added:
+ ----- Method: InstallerGitHub>>user:repository: (in category 'copying') -----
+ user: userString repository: repoString
+ ^ self class user: userString repository: repoString!

Item was added:
+ ----- Method: InstallerGitHub>>user:repository:commitId: (in category 'copying') -----
+ user: userString repository: repoString commitId: treeishString
+ ^ self class
+ user: userString
+ repository: repoString
+ commitId: treeishString.!

Item was added:
+ ----- Method: InstallerGitHub>>webClientClassReference (in category 'class references') -----
+ webClientClassReference
+ self class environment
+ at: #WebClient
+ ifPresent: [:cls | ^ cls]
+ ifAbsent: [self installWebClient].
+ ^ self class environment at: #WebClient!

Item was added:
+ ----- Method: InstallerGitHub>>zipballUrl (in category 'urls') -----
+ zipballUrl
+ ^ ('https://github.com/{1}/{2}/zipball/{3}' format: {user. repository. commitId}) asUrl!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Installer-Core-fbs.366.mcz

Frank Shearar-3
On 18 March 2013 11:46,  <[hidden email]> wrote:

> Frank Shearar uploaded a new version of Installer-Core to project The Inbox:
> http://source.squeak.org/inbox/Installer-Core-fbs.366.mcz
>
> ==================== Summary ====================
>
> Name: Installer-Core-fbs.366
> Author: fbs
> Time: 18 March 2013, 11:46:52.277 am
> UUID: f665ad84-81d3-4337-8527-4c5f320ec2ab
> Ancestors: Installer-Core-fbs.365
>
> InstallerGitHub lets you install source stored in a GitHub repository. It detects FileTree repositories (through the .filetree marker file) and otherwise assumes chunk format.
>
> It will lazily pull in WebClient, SqueakSSL and FileTree as and when necessary. Note that since GitHub uses SSL everywhere, you MUST have the SqueakSSL plugin installed in your VM to use this class.

I've actually used this, and it seems to work: it's now in good enough
shape for other folk to beat on it.

Dale, if you've a moment spare, I'd particularly appreciate any
comments you might have on my use/abuse of FileTree classes.

I want to be able to pull in sources stored on GitHub without worrying
about the file system mapping someone chose to use, whether Gitocello
or Filetree or other.

(And, in particular, I'd like to keep things loose enough that I can
experiment with alternative fileout syntaxes.)

Thanks!

frank

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Installer-Core-fbs.366.mcz

Frank Shearar-3
On 18 March 2013 11:52, Frank Shearar <[hidden email]> wrote:

> On 18 March 2013 11:46,  <[hidden email]> wrote:
>> Frank Shearar uploaded a new version of Installer-Core to project The Inbox:
>> http://source.squeak.org/inbox/Installer-Core-fbs.366.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Installer-Core-fbs.366
>> Author: fbs
>> Time: 18 March 2013, 11:46:52.277 am
>> UUID: f665ad84-81d3-4337-8527-4c5f320ec2ab
>> Ancestors: Installer-Core-fbs.365
>>
>> InstallerGitHub lets you install source stored in a GitHub repository. It detects FileTree repositories (through the .filetree marker file) and otherwise assumes chunk format.
>>
>> It will lazily pull in WebClient, SqueakSSL and FileTree as and when necessary. Note that since GitHub uses SSL everywhere, you MUST have the SqueakSSL plugin installed in your VM to use this class.
>
> I've actually used this, and it seems to work: it's now in good enough
> shape for other folk to beat on it.
>
> Dale, if you've a moment spare, I'd particularly appreciate any
> comments you might have on my use/abuse of FileTree classes.
>
> I want to be able to pull in sources stored on GitHub without worrying
> about the file system mapping someone chose to use, whether Gitocello
> or Filetree or other.
>
> (And, in particular, I'd like to keep things loose enough that I can
> experiment with alternative fileout syntaxes.)

The mcz is missing something important, namely

    Installer class >> github
        ^ InstallerGitHub new

but 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

Reply | Threaded
Open this post in threaded view
|

Re: [Cuis] [squeak-dev] The Inbox: Installer-Core-fbs.366.mcz

Frank Shearar-3
Hopefully in the next round of official VM releases we'll have it
shipped as standard. Dave Lewis has taken the first steps towards
folding it into the Interpreter VM. Pharo VMs ship with it as standard
nowadays.

For the moment you have to get it here:
http://code.google.com/p/squeakssl/downloads/list

I've only looked at how to install it in the context of a
built-it-myself interpreter VM. In this case, you go into the bld/
directory you had to make as part of compiling a VM. You make a
SqueakSSL directory, and you put the so.SqueakSSL file from the
above-mentioned download (which includes binaries for Linux, Windows
and Mac).

Then you just start up the image, try install something, and (fingers
crossed), things just work. It should support installing both chunk
format repositories (like Ken's Cuis-Ropes) and FileTree format
repositories like my Control library ((Installer github user:
'frankshearar' repository: 'Control') install). The latter might well
have broken stuff; it's definitely ropier code.

frank

On 21 March 2013 19:57, Chris Muller <[hidden email]> wrote:

> Very nice.  Where to get the SSL plugin?
>
> On Thu, Mar 21, 2013 at 7:11 AM, Frank Shearar <[hidden email]> wrote:
>> On 18 March 2013 11:52, Frank Shearar <[hidden email]> wrote:
>>> On 18 March 2013 11:46,  <[hidden email]> wrote:
>>>> Frank Shearar uploaded a new version of Installer-Core to project The Inbox:
>>>> http://source.squeak.org/inbox/Installer-Core-fbs.366.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Installer-Core-fbs.366
>>>> Author: fbs
>>>> Time: 18 March 2013, 11:46:52.277 am
>>>> UUID: f665ad84-81d3-4337-8527-4c5f320ec2ab
>>>> Ancestors: Installer-Core-fbs.365
>>>>
>>>> InstallerGitHub lets you install source stored in a GitHub repository. It detects FileTree repositories (through the .filetree marker file) and otherwise assumes chunk format.
>>>>
>>>> It will lazily pull in WebClient, SqueakSSL and FileTree as and when necessary. Note that since GitHub uses SSL everywhere, you MUST have the SqueakSSL plugin installed in your VM to use this class.
>>>
>>> I've actually used this, and it seems to work: it's now in good enough
>>> shape for other folk to beat on it.
>>>
>>> Dale, if you've a moment spare, I'd particularly appreciate any
>>> comments you might have on my use/abuse of FileTree classes.
>>>
>>> I want to be able to pull in sources stored on GitHub without worrying
>>> about the file system mapping someone chose to use, whether Gitocello
>>> or Filetree or other.
>>>
>>> (And, in particular, I'd like to keep things loose enough that I can
>>> experiment with alternative fileout syntaxes.)
>>
>> The mcz is missing something important, namely
>>
>>     Installer class >> github
>>         ^ InstallerGitHub new
>>
>> but 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
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Installer-Core-fbs.366.mcz

Frank Shearar-3
In reply to this post by Frank Shearar-3
On 21 March 2013 12:11, Frank Shearar <[hidden email]> wrote:

> On 18 March 2013 11:52, Frank Shearar <[hidden email]> wrote:
>> On 18 March 2013 11:46,  <[hidden email]> wrote:
>>> Frank Shearar uploaded a new version of Installer-Core to project The Inbox:
>>> http://source.squeak.org/inbox/Installer-Core-fbs.366.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Installer-Core-fbs.366
>>> Author: fbs
>>> Time: 18 March 2013, 11:46:52.277 am
>>> UUID: f665ad84-81d3-4337-8527-4c5f320ec2ab
>>> Ancestors: Installer-Core-fbs.365
>>>
>>> InstallerGitHub lets you install source stored in a GitHub repository. It detects FileTree repositories (through the .filetree marker file) and otherwise assumes chunk format.
>>>
>>> It will lazily pull in WebClient, SqueakSSL and FileTree as and when necessary. Note that since GitHub uses SSL everywhere, you MUST have the SqueakSSL plugin installed in your VM to use this class.
>>
>> I've actually used this, and it seems to work: it's now in good enough
>> shape for other folk to beat on it.
>>
>> Dale, if you've a moment spare, I'd particularly appreciate any
>> comments you might have on my use/abuse of FileTree classes.
>>
>> I want to be able to pull in sources stored on GitHub without worrying
>> about the file system mapping someone chose to use, whether Gitocello
>> or Filetree or other.
>>
>> (And, in particular, I'd like to keep things loose enough that I can
>> experiment with alternative fileout syntaxes.)
>
> The mcz is missing something important, namely
>
>     Installer class >> github
>         ^ InstallerGitHub new
>
> but 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

Reply | Threaded
Open this post in threaded view
|

Re: [Cuis] [squeak-dev] The Inbox: Installer-Core-fbs.366.mcz

Frank Shearar-3
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 <[hidden email]> wrote:

> On Mon, 25 Mar 2013 13:48:41 +0000
> Frank Shearar <[hidden email]> 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 new
>> >
>> > but 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
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> --
> Ken [dot] Dickey [at] whidbey [dot] com

Reply | Threaded
Open this post in threaded view
|

Re: [Cuis] [squeak-dev] The Inbox: Installer-Core-fbs.366.mcz

Hannes Hirzel
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.

More on this later.

--Hannes

On 3/26/13, Frank Shearar <[hidden email]> 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 <[hidden email]> wrote:
>> On Mon, 25 Mar 2013 13:48:41 +0000
>> Frank Shearar <[hidden email]> 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 new
>>> >
>>> > but 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
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>> --
>> Ken [dot] Dickey [at] whidbey [dot] com
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

Reply | Threaded
Open this post in threaded view
|

Re: [Cuis] [squeak-dev] The Inbox: Installer-Core-fbs.366.mcz

Frank Shearar-3
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 <[hidden email]> 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.
>
> More on this later.
>
> --Hannes
>
> On 3/26/13, Frank Shearar <[hidden email]> 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 <[hidden email]> wrote:
>>> On Mon, 25 Mar 2013 13:48:41 +0000
>>> Frank Shearar <[hidden email]> 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 new
>>>> >
>>>> > but 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
>>>> [hidden email]
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>> --
>>> Ken [dot] Dickey [at] whidbey [dot] com
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Reply | Threaded
Open this post in threaded view
|

Re: [Cuis] [squeak-dev] The Inbox: Installer-Core-fbs.366.mcz

Nicolas Cellier
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 <[hidden email]>:

> 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 <[hidden email]> 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.
>>
>> More on this later.
>>
>> --Hannes
>>
>> On 3/26/13, Frank Shearar <[hidden email]> 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 <[hidden email]> wrote:
>>>> On Mon, 25 Mar 2013 13:48:41 +0000
>>>> Frank Shearar <[hidden email]> 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 new
>>>>> >
>>>>> > but 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
>>>>> [hidden email]
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>>
>>>> --
>>>> Ken [dot] Dickey [at] whidbey [dot] com
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

Reply | Threaded
Open this post in threaded view
|

[Cuis] The Inbox: Installer-Core-fbs.366.mcz

Louis LaBrunda
Hi,

Sorry for being a little off topic.

On Tue, 26 Mar 2013 14:22:07 +0100, Nicolas Cellier
<[hidden email]> 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:[hidden email] http://www.Keystone-Software.com


Reply | Threaded
Open this post in threaded view
|

Re: [Cuis] The Inbox: Installer-Core-fbs.366.mcz

Frank Shearar-3
On 26 March 2013 13:46, Louis LaBrunda <[hidden email]> wrote:

> Hi,
>
> Sorry for being a little off topic.
>
> On Tue, 26 Mar 2013 14:22:07 +0100, Nicolas Cellier
> <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

[Cuis] The Inbox: Installer-Core-fbs.366.mcz

Louis LaBrunda
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:[hidden email] http://www.Keystone-Software.com