FW: [Pharo-project] Command Line AWS S3 Upload/Download Tool using Pharo Smalltalk

> From: Sven Van Caekenberghe <[hidden email]>
> Reply-To: <[hidden email]>
> Date: Fri, 9 Dec 2011 16:58:45 +0100
> To: Pharo List <[hidden email]>
> Subject: [Pharo-project] Command Line AWS S3 Upload/Download Tool using Pharo
> Smalltalk
>
> Command Line AWS S3 Upload/Download Tool using Pharo Smalltalk
>
> This is a little story about a tool that I needed and that I finally
> implemented in Pharo Smalltalk. I think it is quite nice and elegant and might
> be useful to others too. Also, I think it is important to share little hacks
> like this to show that what you can do is almost unlimited (as many others
> have shown in all kinds of projects).
>
> This is a bit long, so if you're not interested, please ignore.
>
> Amazon S3 is a web service interface to store and retrieve any data from
> anywhere that is highly scalable, reliable, secure, fast, inexpensive. [
> http://aws.amazon.com/s3/ ] [ http://en.wikipedia.org/wiki/Amazon_S3 ]
>
> I needed a client to interface with S3 from Linux to store and retrieve
> archives and backups up to 100s of Mb large. Although I had already written a
> client for this web service in Pharo some time ago, I thought it would not be
> good enough for these amounts of data. Furthermore, it had no command line
> interface. So I Googled and found s3cmd. This installed easily and quickly in
> Ubuntu. Uploading/downloading some small test files went OK. However,
> uploading large files gave all kinds of strange errors, even though I was
> doing this from EC2 directly on the Amazon network. I don't know Python so I
> was not capable of debugging the tool.
>
> But I do know Smalltalk and had the basic code already. [ Zinc-AWS in
> http://www.squeaksource.com/ZincHTTPComponents ]
>
> What was missing was a solution to do streaming uploads and downloads so that
> these huge files would not be taken into memory all at once and a command line
> interface. Turns out both were quite easy and elegant to implement.
>
> I added the following methods to ZnAWSS3Client:
>
> downloadFile: filename fromBucket: bucket
> "Do a streaming download of the key filename from bucket,
> creating it as a file with that name in the current directory."
>
> | streaming response |
> streaming := self httpClient streaming.
> self httpClient streaming: true.
> response := self at: bucket -> filename.
> self httpClient streaming: streaming.
> response isSuccess ifFalse: [ ^ ZnHttpUnsuccessful signal ].
> FileStream
> fileNamed: filename
> do: [ :stream | response entity writeOn: stream ].
> ^ response
>
> The #streaming option of the underlying ZnClient is toggled on for this
> request and reset later to its previous value after the request. The #at: does
> the actual request, returning a ZnStreamingEntity that is then written to a
> file. When a streaming entity writes itself to another stream it will actually
> do a streaming copy (one buffer at a time in a loop) for an efficient
> download.
>
> uploadFile: filename withMd5: md5 inBucket: bucket
> "Do a streaming upload of the file filename to bucket.
> When md5 is notNil, use it to validate the ETag of the response."
>
> | entry size mimeType fileStream entity response |
> entry := FileDirectory root directoryEntryFor: filename.
> size := entry fileSize.
> mimeType := ZnMimeType forFilenameExtension: (FileDirectory extensionFor:
> filename).
> fileStream := FileDirectory root readOnlyFileNamed: filename.
> mimeType isBinary ifTrue: [ fileStream binary ].
> (entity := ZnStreamingEntity type: mimeType length: size)
> stream: fileStream.
> self at: bucket -> entry name put: entity.
> (md5 notNil and: [ (md5 sameAs: self eTag) not ])
> ifTrue: [ self error: 'Uploaded ETag does not equal supplied MD5' ].
> ^ self httpClient response
>
> Here the streaming entity is created based on an existing file, the mime type
> coming from the extension. Then, #at:put: is used to do the upload. Again,
> when the streaming entity writes itself to the socket stream it will actually
> do a streaming copy (one buffer at a time in a loop), for an efficient upload.
>
> Amazon S3 delivers MD5 hashes (ETags) that can be used to check the integrity
> of uploads/downloads. ZnAWSS3Client uses these when its #checkIntegrity option
> is true using MD5>>#hashMessage:, though not using the streaming option of
> HashFunction. Since it would be a lot of work to make that possible, I opted
> for externally supplied MD5 hashes using Linux's md5sum utility.
>
> Next, I took a clean Pharo 1.3 image and the standard Pharo built CogVM and
> loaded the following to create a server image:
>
> Gofer new
>  squeaksource: 'XMLSupport';
>  package: 'ConfigurationOfXMLSupport';
>  load.
> (Smalltalk at: #ConfigurationOfXMLSupport) perform: #loadDefault.
>
> Gofer new
>  squeaksource: 'ZincHTTPComponents';
>  package: 'Zinc-HTTP';
>  package: 'Zinc-AWS';
>  load.
>
> Gofer new
>  squeaksource: 'ADayAtTheBeach';
>  package: 'NonInteractiveTranscript';
>  load.
>
> The glue code for each tool consists of a Linux shell script and a Smalltalk
> startup script. This is a tool for personal use, error handling could be a bit
> better regarding wrong invocations.
>
> #!/bin/bash
> echo S3 Download $*
> script_home=$(dirname $0)
> script_home=$(cd $script_home && pwd)
> image=$script_home/pharo-t3.image
> script=$script_home/s3-download.st
> bucket=$1
> file=$2
> vm=$script_home/bin/CogVM
> options="-vm-display-null -vm-sound-null"
> echo $vm $options $image $script $bucket $file
> $vm $options $image $script $bucket $file
>
> NonInteractiveTranscript stdout install.
> [
>
> | args bucket filename |
> args := Smalltalk commandLine arguments.
> bucket := args first.
> filename := args second.
>
> (ZnAWSS3Client new)
>  accessKeyId: 'AAAAXXYYZZ5HGQZ77EQ';
>  secretAccessKey: 'AAAA+D9n7gabcdefghSfevY/mH6KWsvMAcsjzzzz';
>  checkIntegrity: false;
>  downloadFile: filename fromBucket: bucket;
>  close.
>
> Transcript show: 'OK'; cr; endEntry.
>
> ] on: Error do: [ :exception |
>
> Smalltalk logError: exception description inContext: exception
> signalerContext.
> Transcript show: 'FAILED'; cr; endEntry.
>
> ].
> SmalltalkImage current quitPrimitive.
>
> #!/bin/bash
> echo S3 Upload $*
> script_home=$(dirname $0)
> script_home=$(cd $script_home && pwd)
> image=$script_home/pharo-t3.image
> script=$script_home/s3-upload.st
> bucket=$1
> file=$2
> file_dir=$(dirname $file)
> file_name=$(basename $file)
> file=$(cd $file_dir && pwd)/$file_name
> vm=$script_home/bin/CogVM
> options="-vm-display-null -vm-sound-null"
> compute_md5="md5sum $file"
> md5=`$compute_md5`
> echo $vm $options $image $script $bucket $file $md5
> $vm $options $image $script $bucket $file $md5
>
> NonInteractiveTranscript stdout install.
> [
>
> | args bucket filename md5 |
> args := Smalltalk commandLine arguments.
> bucket := args first.
> filename := args second.
> md5 := args third.
>
> (ZnAWSS3Client new)
>  accessKeyId: 'AAAAXXYYZZ5HGQZ77EQ';
>  secretAccessKey: 'AAAA+D9n7gabcdefghSfevY/mH6KWsvMAcsjzzzz';
>  checkIntegrity: false;
>  uploadFile: filename withMd5: md5 inBucket: bucket;
>  close.
>
> Transcript show: 'OK'; cr; endEntry.
>
> ] on: Error do: [ :exception |
>
> Smalltalk logError: exception description inContext: exception
> signalerContext.
> Transcript show: 'FAILED'; cr; endEntry.
>
> ]
> SmalltalkImage current quitPrimitive.
>
> Both tools are very similar: the shell scripts uses the VM to start the right
> image after massaging some of the arguments.
> The Smalltalk script retrieves arguments, instanciates and invokes the tool to
> do its job. NonInteractiveTranscript is used with the #stdout option to write
> OK or FAILED. In the case of failure a PharoDebug.log is written.
> #quitPrimitive is used for a fast exit (not marking the changes file). Since
> then I learned from Igor that #quitPrimitive accepts an exit value so it would
> be possible to do away with the OK/FAILED writing to stdout and just rely on
> the exit value for an even better integration with *nix.
>
> Uploading/downloading files of 100s of Mb went flawless and was more than fast
> enough (network IO bound anyway). Repeatably starting/stopping a VM with a
> 20Mb image is totally acceptable and fast as well.
>
> A big thanks to everybody who is working on all the little details all the
> time to make things like this possible !
>
> Sven
>
>

> **
>
>
> #OtroParaLaListaInterminable
> Como ven sigo atentamente lo que pasa en Pharo
> Alguien sigue WebClient y Zinc como para que tire opinión ?
>
> Por ahora necesito mas que eso y algunos ya saben que mis trabajos en
> progreso son con Kom + HV2 + external .js
>
> Meterme con Celeste (va informe aparte) fue por necesidad.
> Anduvo linda la minicharlita con el ruso ?
> No sean timidos, a ver si la próxima nos enganchamos con alguien mas
>
> ------ Forwarded Message
> > From: Sven Van Caekenberghe <[hidden email]>
> > Reply-To: <[hidden email]>
> > Date: Fri, 9 Dec 2011 16:58:45 +0100
> > To: Pharo List <[hidden email]>
> > Subject: [Pharo-project] Command Line AWS S3 Upload/Download Tool using
> Pharo
>
> > Smalltalk
> >
> > Command Line AWS S3 Upload/Download Tool using Pharo Smalltalk
> >
> > This is a little story about a tool that I needed and that I finally
> > implemented in Pharo Smalltalk. I think it is quite nice and elegant and
> might
> > be useful to others too. Also, I think it is important to share little
> hacks
> > like this to show that what you can do is almost unlimited (as many
> others
> > have shown in all kinds of projects).
> >
> > This is a bit long, so if you're not interested, please ignore.
> >
> > Amazon S3 is a web service interface to store and retrieve any data from
> > anywhere that is highly scalable, reliable, secure, fast, inexpensive. [
> > http://aws.amazon.com/s3/ ] [ http://en.wikipedia.org/wiki/Amazon_S3 ]
> >
> > I needed a client to interface with S3 from Linux to store and retrieve
> > archives and backups up to 100s of Mb large. Although I had already
> written a
> > client for this web service in Pharo some time ago, I thought it would
> not be
> > good enough for these amounts of data. Furthermore, it had no command
> line
> > interface. So I Googled and found s3cmd. This installed easily and
> quickly in
> > Ubuntu. Uploading/downloading some small test files went OK. However,
> > uploading large files gave all kinds of strange errors, even though I was
> > doing this from EC2 directly on the Amazon network. I don't know Python
> so I
> > was not capable of debugging the tool.
> >
> > But I do know Smalltalk and had the basic code already. [ Zinc-AWS in
> > http://www.squeaksource.com/ZincHTTPComponents ]
> >
> > What was missing was a solution to do streaming uploads and downloads so
> that
> > these huge files would not be taken into memory all at once and a
> command line
> > interface. Turns out both were quite easy and elegant to implement.
> >
> > I added the following methods to ZnAWSS3Client:
> >
> > downloadFile: filename fromBucket: bucket
> > "Do a streaming download of the key filename from bucket,
> > creating it as a file with that name in the current directory."
> >
> > | streaming response |
> > streaming := self httpClient streaming.
> > self httpClient streaming: true.
> > response := self at: bucket -> filename.
> > self httpClient streaming: streaming.
> > response isSuccess ifFalse: [ ^ ZnHttpUnsuccessful signal ].
> > FileStream
> > fileNamed: filename
> > do: [ :stream | response entity writeOn: stream ].
> > ^ response
> >
> > The #streaming option of the underlying ZnClient is toggled on for this
> > request and reset later to its previous value after the request. The
> #at: does
> > the actual request, returning a ZnStreamingEntity that is then written
> to a
> > file. When a streaming entity writes itself to another stream it will
> actually
> > do a streaming copy (one buffer at a time in a loop) for an efficient
> > download.
> >
> > uploadFile: filename withMd5: md5 inBucket: bucket
> > "Do a streaming upload of the file filename to bucket.
> > When md5 is notNil, use it to validate the ETag of the response."
> >
> > | entry size mimeType fileStream entity response |
> > entry := FileDirectory root directoryEntryFor: filename.
> > size := entry fileSize.
> > mimeType := ZnMimeType forFilenameExtension: (FileDirectory extensionFor:
> > filename).
> > fileStream := FileDirectory root readOnlyFileNamed: filename.
> > mimeType isBinary ifTrue: [ fileStream binary ].
> > (entity := ZnStreamingEntity type: mimeType length: size)
> > stream: fileStream.
> > self at: bucket -> entry name put: entity.
> > (md5 notNil and: [ (md5 sameAs: self eTag) not ])
> > ifTrue: [ self error: 'Uploaded ETag does not equal supplied MD5' ].
> > ^ self httpClient response
> >
> > Here the streaming entity is created based on an existing file, the mime
> type
> > coming from the extension. Then, #at:put: is used to do the upload.
> Again,
> > when the streaming entity writes itself to the socket stream it will
> actually
> > do a streaming copy (one buffer at a time in a loop), for an efficient
> upload.
> >
> > Amazon S3 delivers MD5 hashes (ETags) that can be used to check the
> integrity
> > of uploads/downloads. ZnAWSS3Client uses these when its #checkIntegrity
> option
> > is true using MD5>>#hashMessage:, though not using the streaming option
> of
> > HashFunction. Since it would be a lot of work to make that possible, I
> opted
> > for externally supplied MD5 hashes using Linux's md5sum utility.
> >
> > Next, I took a clean Pharo 1.3 image and the standard Pharo built CogVM
> and
> > loaded the following to create a server image:
> >
> > Gofer new
> > squeaksource: 'XMLSupport';
> > package: 'ConfigurationOfXMLSupport';
> > load.
> > (Smalltalk at: #ConfigurationOfXMLSupport) perform: #loadDefault.
> >
> > Gofer new
> > squeaksource: 'ZincHTTPComponents';
> > package: 'Zinc-HTTP';
> > package: 'Zinc-AWS';
> > load.
> >
> > Gofer new
> > squeaksource: 'ADayAtTheBeach';
> > package: 'NonInteractiveTranscript';
> > load.
> >
> > The glue code for each tool consists of a Linux shell script and a
> Smalltalk
> > startup script. This is a tool for personal use, error handling could be
> a bit
> > better regarding wrong invocations.
> >
> > #!/bin/bash
> > echo S3 Download $*
> > script_home=$(dirname $0)
> > script_home=$(cd $script_home && pwd)
> > image=$script_home/pharo-t3.image
> > script=$script_home/s3-download.st
> > bucket=$1
> > file=$2
> > vm=$script_home/bin/CogVM
> > options="-vm-display-null -vm-sound-null"
> > echo $vm $options $image $script $bucket $file
> > $vm $options $image $script $bucket $file
> >
> > NonInteractiveTranscript stdout install.
> > [
> >
> > | args bucket filename |
> > args := Smalltalk commandLine arguments.
> > bucket := args first.
> > filename := args second.
> >
> > (ZnAWSS3Client new)
> > accessKeyId: 'AAAAXXYYZZ5HGQZ77EQ';
> > secretAccessKey: 'AAAA+D9n7gabcdefghSfevY/mH6KWsvMAcsjzzzz';
> > checkIntegrity: false;
> > downloadFile: filename fromBucket: bucket;
> > close.
> >
> > Transcript show: 'OK'; cr; endEntry.
> >
> > ] on: Error do: [ :exception |
> >
> > Smalltalk logError: exception description inContext: exception
> > signalerContext.
> > Transcript show: 'FAILED'; cr; endEntry.
> >
> > ].
> > SmalltalkImage current quitPrimitive.
> >
> > #!/bin/bash
> > echo S3 Upload $*
> > script_home=$(dirname $0)
> > script_home=$(cd $script_home && pwd)
> > image=$script_home/pharo-t3.image
> > script=$script_home/s3-upload.st
> > bucket=$1
> > file=$2
> > file_dir=$(dirname $file)
> > file_name=$(basename $file)
> > file=$(cd $file_dir && pwd)/$file_name
> > vm=$script_home/bin/CogVM
> > options="-vm-display-null -vm-sound-null"
> > compute_md5="md5sum $file"
> > md5=`$compute_md5`
> > echo $vm $options $image $script $bucket $file $md5
> > $vm $options $image $script $bucket $file $md5
> >
> > NonInteractiveTranscript stdout install.
> > [
> >
> > | args bucket filename md5 |
> > args := Smalltalk commandLine arguments.
> > bucket := args first.
> > filename := args second.
> > md5 := args third.
> >
> > (ZnAWSS3Client new)
> > accessKeyId: 'AAAAXXYYZZ5HGQZ77EQ';
> > secretAccessKey: 'AAAA+D9n7gabcdefghSfevY/mH6KWsvMAcsjzzzz';
> > checkIntegrity: false;
> > uploadFile: filename withMd5: md5 inBucket: bucket;
> > close.
> >
> > Transcript show: 'OK'; cr; endEntry.
> >
> > ] on: Error do: [ :exception |
> >
> > Smalltalk logError: exception description inContext: exception
> > signalerContext.
> > Transcript show: 'FAILED'; cr; endEntry.
> >
> > ]
> > SmalltalkImage current quitPrimitive.
> >
> > Both tools are very similar: the shell scripts uses the VM to start the
> right
> > image after massaging some of the arguments.
> > The Smalltalk script retrieves arguments, instanciates and invokes the
> tool to
> > do its job. NonInteractiveTranscript is used with the #stdout option to
> write
> > OK or FAILED. In the case of failure a PharoDebug.log is written.
> > #quitPrimitive is used for a fast exit (not marking the changes file).
> Since
> > then I learned from Igor that #quitPrimitive accepts an exit value so it
> would
> > be possible to do away with the OK/FAILED writing to stdout and just
> rely on
> > the exit value for an even better integration with *nix.
> >
> > Uploading/downloading files of 100s of Mb went flawless and was more
> than fast
> > enough (network IO bound anyway). Repeatably starting/stopping a VM with
> a
> > 20Mb image is totally acceptable and fast as well.
> >
> > A big thanks to everybody who is working on all the little details all
> the
> > time to make things like this possible !
> >
> > Sven
> >
> >
>
> ------ End of Forwarded Message
>
>  
>

>
>
> Muy bueno este post, este Sven la tiene clara con la web, realmente.
>
> No se compararlos a Zinc con WebClient, pero a primera vista la ventaja de
> Zinc es que viene default en la imagen 1.3 de Pharo y parece que está
> activamente mantenido.
>
> Aunque WebClient anda muy bien también.
>
> Yo tendría que adaptar XMLRPC para que use Zinc, como ves no sos el único
> que tiene una lista interminable..... :)
>
> Lo que mas me gusta de Rusia es el frio...........como odio las
> temperaturas superiores a 22 grados!!!!!
>
> Miro el pronóstico de los días que vienen y me amargo...Edgar, vamos a
> encarar una mudanza en masa de Smalltalkers anticalor a algún lado más
> piola?
>
>
> 2011/12/9 Edgar J. De Cleene <[hidden email]>
>
>
>>
>> #OtroParaLaListaInterminable
>> Como ven sigo atentamente lo que pasa en Pharo
>> Alguien sigue WebClient y Zinc como para que tire opinión ?
>>
>> Por ahora necesito mas que eso y algunos ya saben que mis trabajos en
>> progreso son con Kom + HV2 + external .js
>>
>> Meterme con Celeste (va informe aparte) fue por necesidad.
>> Anduvo linda la minicharlita con el ruso ?
>> No sean timidos, a ver si la próxima nos enganchamos con alguien mas
>>
>> ------ Forwarded Message
>> > From: Sven Van Caekenberghe <[hidden email]>
>> > Reply-To: <[hidden email]>
>> > Date: Fri, 9 Dec 2011 16:58:45 +0100
>> > To: Pharo List <[hidden email]>
>> > Subject: [Pharo-project] Command Line AWS S3 Upload/Download Tool using
>> Pharo
>>
>> > Smalltalk
>> >
>> > Command Line AWS S3 Upload/Download Tool using Pharo Smalltalk
>> >
>> > This is a little story about a tool that I needed and that I finally
>> > implemented in Pharo Smalltalk. I think it is quite nice and elegant
>> and might
>> > be useful to others too. Also, I think it is important to share little
>> hacks
>> > like this to show that what you can do is almost unlimited (as many
>> others
>> > have shown in all kinds of projects).
>> >
>> > This is a bit long, so if you're not interested, please ignore.
>> >
>> > Amazon S3 is a web service interface to store and retrieve any data from
>> > anywhere that is highly scalable, reliable, secure, fast, inexpensive. [
>> > http://aws.amazon.com/s3/ ] [ http://en.wikipedia.org/wiki/Amazon_S3 ]
>> >
>> > I needed a client to interface with S3 from Linux to store and retrieve
>> > archives and backups up to 100s of Mb large. Although I had already
>> written a
>> > client for this web service in Pharo some time ago, I thought it would
>> not be
>> > good enough for these amounts of data. Furthermore, it had no command
>> line
>> > interface. So I Googled and found s3cmd. This installed easily and
>> quickly in
>> > Ubuntu. Uploading/downloading some small test files went OK. However,
>> > uploading large files gave all kinds of strange errors, even though I
>> was
>> > doing this from EC2 directly on the Amazon network. I don't know Python
>> so I
>> > was not capable of debugging the tool.
>> >
>> > But I do know Smalltalk and had the basic code already. [ Zinc-AWS in
>> > http://www.squeaksource.com/ZincHTTPComponents ]
>> >
>> > What was missing was a solution to do streaming uploads and downloads
>> so that
>> > these huge files would not be taken into memory all at once and a
>> command line
>> > interface. Turns out both were quite easy and elegant to implement.
>> >
>> > I added the following methods to ZnAWSS3Client:
>> >
>> > downloadFile: filename fromBucket: bucket
>> > "Do a streaming download of the key filename from bucket,
>> > creating it as a file with that name in the current directory."
>> >
>> > | streaming response |
>> > streaming := self httpClient streaming.
>> > self httpClient streaming: true.
>> > response := self at: bucket -> filename.
>> > self httpClient streaming: streaming.
>> > response isSuccess ifFalse: [ ^ ZnHttpUnsuccessful signal ].
>> > FileStream
>> > fileNamed: filename
>> > do: [ :stream | response entity writeOn: stream ].
>> > ^ response
>> >
>> > The #streaming option of the underlying ZnClient is toggled on for this
>> > request and reset later to its previous value after the request. The
>> #at: does
>> > the actual request, returning a ZnStreamingEntity that is then written
>> to a
>> > file. When a streaming entity writes itself to another stream it will
>> actually
>> > do a streaming copy (one buffer at a time in a loop) for an efficient
>> > download.
>> >
>> > uploadFile: filename withMd5: md5 inBucket: bucket
>> > "Do a streaming upload of the file filename to bucket.
>> > When md5 is notNil, use it to validate the ETag of the response."
>> >
>> > | entry size mimeType fileStream entity response |
>> > entry := FileDirectory root directoryEntryFor: filename.
>> > size := entry fileSize.
>> > mimeType := ZnMimeType forFilenameExtension: (FileDirectory
>> extensionFor:
>> > filename).
>> > fileStream := FileDirectory root readOnlyFileNamed: filename.
>> > mimeType isBinary ifTrue: [ fileStream binary ].
>> > (entity := ZnStreamingEntity type: mimeType length: size)
>> > stream: fileStream.
>> > self at: bucket -> entry name put: entity.
>> > (md5 notNil and: [ (md5 sameAs: self eTag) not ])
>> > ifTrue: [ self error: 'Uploaded ETag does not equal supplied MD5' ].
>> > ^ self httpClient response
>> >
>> > Here the streaming entity is created based on an existing file, the
>> mime type
>> > coming from the extension. Then, #at:put: is used to do the upload.
>> Again,
>> > when the streaming entity writes itself to the socket stream it will
>> actually
>> > do a streaming copy (one buffer at a time in a loop), for an efficient
>> upload.
>> >
>> > Amazon S3 delivers MD5 hashes (ETags) that can be used to check the
>> integrity
>> > of uploads/downloads. ZnAWSS3Client uses these when its #checkIntegrity
>> option
>> > is true using MD5>>#hashMessage:, though not using the streaming option
>> of
>> > HashFunction. Since it would be a lot of work to make that possible, I
>> opted
>> > for externally supplied MD5 hashes using Linux's md5sum utility.
>> >
>> > Next, I took a clean Pharo 1.3 image and the standard Pharo built CogVM
>> and
>> > loaded the following to create a server image:
>> >
>> > Gofer new
>> > squeaksource: 'XMLSupport';
>> > package: 'ConfigurationOfXMLSupport';
>> > load.
>> > (Smalltalk at: #ConfigurationOfXMLSupport) perform: #loadDefault.
>> >
>> > Gofer new
>> > squeaksource: 'ZincHTTPComponents';
>> > package: 'Zinc-HTTP';
>> > package: 'Zinc-AWS';
>> > load.
>> >
>> > Gofer new
>> > squeaksource: 'ADayAtTheBeach';
>> > package: 'NonInteractiveTranscript';
>> > load.
>> >
>> > The glue code for each tool consists of a Linux shell script and a
>> Smalltalk
>> > startup script. This is a tool for personal use, error handling could
>> be a bit
>> > better regarding wrong invocations.
>> >
>> > #!/bin/bash
>> > echo S3 Download $*
>> > script_home=$(dirname $0)
>> > script_home=$(cd $script_home && pwd)
>> > image=$script_home/pharo-t3.image
>> > script=$script_home/s3-download.st
>> > bucket=$1
>> > file=$2
>> > vm=$script_home/bin/CogVM
>> > options="-vm-display-null -vm-sound-null"
>> > echo $vm $options $image $script $bucket $file
>> > $vm $options $image $script $bucket $file
>> >
>> > NonInteractiveTranscript stdout install.
>> > [
>> >
>> > | args bucket filename |
>> > args := Smalltalk commandLine arguments.
>> > bucket := args first.
>> > filename := args second.
>> >
>> > (ZnAWSS3Client new)
>> > accessKeyId: 'AAAAXXYYZZ5HGQZ77EQ';
>> > secretAccessKey: 'AAAA+D9n7gabcdefghSfevY/mH6KWsvMAcsjzzzz';
>> > checkIntegrity: false;
>> > downloadFile: filename fromBucket: bucket;
>> > close.
>> >
>> > Transcript show: 'OK'; cr; endEntry.
>> >
>> > ] on: Error do: [ :exception |
>> >
>> > Smalltalk logError: exception description inContext: exception
>> > signalerContext.
>> > Transcript show: 'FAILED'; cr; endEntry.
>> >
>> > ].
>> > SmalltalkImage current quitPrimitive.
>> >
>> > #!/bin/bash
>> > echo S3 Upload $*
>> > script_home=$(dirname $0)
>> > script_home=$(cd $script_home && pwd)
>> > image=$script_home/pharo-t3.image
>> > script=$script_home/s3-upload.st
>> > bucket=$1
>> > file=$2
>> > file_dir=$(dirname $file)
>> > file_name=$(basename $file)
>> > file=$(cd $file_dir && pwd)/$file_name
>> > vm=$script_home/bin/CogVM
>> > options="-vm-display-null -vm-sound-null"
>> > compute_md5="md5sum $file"
>> > md5=`$compute_md5`
>> > echo $vm $options $image $script $bucket $file $md5
>> > $vm $options $image $script $bucket $file $md5
>> >
>> > NonInteractiveTranscript stdout install.
>> > [
>> >
>> > | args bucket filename md5 |
>> > args := Smalltalk commandLine arguments.
>> > bucket := args first.
>> > filename := args second.
>> > md5 := args third.
>> >
>> > (ZnAWSS3Client new)
>> > accessKeyId: 'AAAAXXYYZZ5HGQZ77EQ';
>> > secretAccessKey: 'AAAA+D9n7gabcdefghSfevY/mH6KWsvMAcsjzzzz';
>> > checkIntegrity: false;
>> > uploadFile: filename withMd5: md5 inBucket: bucket;
>> > close.
>> >
>> > Transcript show: 'OK'; cr; endEntry.
>> >
>> > ] on: Error do: [ :exception |
>> >
>> > Smalltalk logError: exception description inContext: exception
>> > signalerContext.
>> > Transcript show: 'FAILED'; cr; endEntry.
>> >
>> > ]
>> > SmalltalkImage current quitPrimitive.
>> >
>> > Both tools are very similar: the shell scripts uses the VM to start the
>> right
>> > image after massaging some of the arguments.
>> > The Smalltalk script retrieves arguments, instanciates and invokes the
>> tool to
>> > do its job. NonInteractiveTranscript is used with the #stdout option to
>> write
>> > OK or FAILED. In the case of failure a PharoDebug.log is written.
>> > #quitPrimitive is used for a fast exit (not marking the changes file).
>> Since
>> > then I learned from Igor that #quitPrimitive accepts an exit value so
>> it would
>> > be possible to do away with the OK/FAILED writing to stdout and just
>> rely on
>> > the exit value for an even better integration with *nix.
>> >
>> > Uploading/downloading files of 100s of Mb went flawless and was more
>> than fast
>> > enough (network IO bound anyway). Repeatably starting/stopping a VM
>> with a
>> > 20Mb image is totally acceptable and fast as well.
>> >
>> > A big thanks to everybody who is working on all the little details all
>> the
>> > time to make things like this possible !
>> >
>> > Sven
>> >
>> >
>>
>> ------ End of Forwarded Message
>>
>>
>
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> Promoter http://www.arsol.biz
> ============================================
>
>  
>

> Hola gente.
> Recontra interesante Zinc. Yo lo vengo siguiendo en la lista de Pharo y es
> impresionante como avanza. Sin dudas (y hasta donde entiendo) Zinc es mucho
> mas general [1] que WebClient [2].
> Otra diferencia clave creo que es que WebClient tiene implementado de manera
> estable e integrado https, mientras que Zinc tiene una implementación de
> externa (Zodiac [3]) pero es beta aún. Ambos usan el plugin SqueakSSL que esta
> sin mantener hace tiempo y tiene algunos problemas creo que con los
> certificados [4].
> Otra diferencia (y ventaja creo) es que Zinc esta mucho mas diseñado para ser
> extendido que WebClient (usa patrones Factory y esas cosas), lo que en algo
> tan general como una librería HTTP te permite adaptar algo según tus
> necesidades específicas.
>
> [1] Our long term goals are very ambitious: we want to reach the level of
> functionality, scope, architectural clarity and maturity of the Apache HTTP
> Components library.
> http://zn.stfx.eu/zn/
> [2] WebClient and WebServer are simple, compact, and easy to use HTTP client
> and server implementations for Squeak.
> http://www.squeaksource.com/WebClient.html
> [3] http://zdc.stfx.eu/
> [4] http://forum.world.st/WebClient-SqueakSSL-https-td2301818.html
>
> Un pequeño resumen, sin garantía de veracidad ;)

> **
>
>
> Y cada uno tiene su opinion, para eso esto es un bar.
> Pero creo que hay que tener claro los objetivos.
> Si lo que uno quiere es ganar plata, mejor se pone un puesto de choripan a
> la salida de la cancha.
> Si los numeros mandan, entonces Smalltalk en cualquiera de sus variantes
> no tiene sentido.
> No salgamos nunca del mundo Windoze (no compraste una Mac bastante cara ?)
> Como ya dije muchas veces, aca en la zona contratan a los alumnos que
> apenas saben tipear y les pagan para hacer Cobol, DB, PL/1.
> Yo pongo mi granito de arena, en este caso resucitando Celeste.
> Si se van todos a Pharo, no interesa.
> Hay gente grosa que esta y hay gente de Pharo que ya se empezo a dar
> cuenta que tambien es un engendro (Lukas el principal)
> A los que les interesa que su trabajo sea conocido, lo hacen para los dos
> forks.
> Lamento por Juan que nadie le de mucha bola a Cuis, pero se encerro solo
> en su mundo.
> A mi no me da el cuero para seguir tres forks y que cada vez que tengo que
> hacer algo chiquito tenga que aprender todo de nuevo.
> La razon de estar en Squeak es la compatibilidad.
> Si solo te interesa el web, bárbaro, usa Pharo.
> No sea que a medida que “avance” te des cuenta que tambien tenes que re
> pensar todo otra vez
>
> Edgar
>
>
>
>  
>

> **
>
>
> > Digo si somos tan buenos, y creo que si, que Smalltalk es diferencial,
> porque
> > el resto de los techies del mundo no lo consideran asi (Y hablo más que
> nada
> > del entorno de las startups o grandes compañías de Internet. Si producir
> en
> > Smalltalk te permite como mínimo el doble de productividad que en un
> lenguaje
> > convencional, porque los grandes no ven eso...? POrque no aprovechan esa
> > ventaja que les permitiría mucho menores costos?
>
> No se si somos tan buenos y repito, que nos importa si "las grandes
> compañias " , lo usen o no?.
>
>

> Si estamos convencidos que es mejor...
>
> Lo que me parece es que Smalltalk no es para todos.
> Apple se tomo el trabajo de re hacer Unix con Objective C, creo que por
> esto
> y para estar de algun modo a mitad de camino.
> Y poder reusar codigo.
> Otra vez la compatibilidad hacia atras
>
>  
>

>
>
>
> El 10 de diciembre de 2011 08:43, Edgar J. De Cleene
> <[hidden email] <mailto:[hidden email]>> escribió:
>
>     > Digo si somos tan buenos, y creo que si, que Smalltalk es
>     diferencial, porque
>     > el resto de los techies del mundo no lo consideran asi (Y hablo
>     más que nada
>     > del entorno de las startups o grandes compañías de Internet. Si
>     producir en
>     > Smalltalk te permite como mínimo el doble de productividad que
>     en un lenguaje
>     > convencional, porque los grandes no ven eso...? POrque no
>     aprovechan esa
>     > ventaja que les permitiría mucho menores costos?
>
>     No se si somos tan buenos y repito, que nos importa si "las grandes
>     compañias " , lo usen o no?.
>

> **
>
>
> El 10/12/2011 13:50, Germán Arduino escribió:
>
>
>
>
>
>  El 10 de diciembre de 2011 08:43, Edgar J. De Cleene <
> [hidden email]> escribió:
>
>>
>>  > Digo si somos tan buenos, y creo que si, que Smalltalk es
>> diferencial, porque
>> > el resto de los techies del mundo no lo consideran asi (Y hablo más que
>> nada
>> > del entorno de las startups o grandes compañías de Internet. Si
>> producir en
>> > Smalltalk te permite como mínimo el doble de productividad que en un
>> lenguaje
>> > convencional, porque los grandes no ven eso...? POrque no aprovechan esa
>> > ventaja que les permitiría mucho menores costos?
>>
>>  No se si somos tan buenos y repito, que nos importa si "las grandes
>> compañias " , lo usen o no?.
>>
>>
> Pero debería importar. Java, tendrá todas las cosas malas que queráis,
> pero a día de hoy, es el lenguaje de programación más usado y extendido en
> el mundo empresarial. Sabemos que no es por méritos propios, pero ahí está.
> Smalltalk, se conoce poco, se conoce como algo de hace 30 años (como si
> nombras Cobol o Fortran),  y que siempre tuvo un precio prohibitivo, y a
> día de hoy, ninguna opción opensource es viable. Además, Java se estudia en
> la universidad. Smalltalk al parecer se estudia en Argentina, pero por
> ejemplo, en España, creo que Smalltalk, como mucho, se nombra en historia
> de programación y ya está, lo demás, es C/C++ y Java prácticamente (creo
> que en Cataluña si hay un catedrático que dá Smalltalk, pero es una
> excpeción, y aparte, viven en su mundo y en su idioma como si de otro pais
> se tratara). Ésto, también repercute como dices en los costos. Para
> encontrar un programador experimentado en Smalltalk, has de buscar mucho, y
> pagarle lo que pida, mientras un becario en Java cobrando una miseria, sale
> de debajo de las piedras.
>
> Algunos me conocéis y sabéis que llevo tras Squeak varios años, y nunca me
> puse en serio más allá de probar cosas y hacer un seguimiento del proyecto,
> pero, sobre todo, porque en mi opinión, por mucho que duela decirlo, por
> muy productivo que pueda ser Smalltalk, del lado OpenSource, no está
> preparado para el mundo empresarial (y yo no tuve tiempo de dedicarle, mi
> parte de culpa también tengo). Obviamente, VA Smalltalk (que lo veo
> carísimo) o VisualWorks o Dolphin (que sólo va en Windows), si serán
> entornos para producción y demostrado está (creo), pero las
> implementaciones opensource no. Pharo parece que quiso cambiar algo ésto, y
> para hacer alguna cosa en el mundo web puede servir, pero para aplicaciones
> empresariales y aburridas (mercado que aún muchos clientes es el que
> desean), a día de hoy Smalltalk está muy verde (y lo seguirá estando), ya
> que, si no me equivoco, el 80% al menos de sus "usuarios" lo usan para
> investigación, o como juguete, no para "trabajar". Además, también hay que
> tener en cuenta, que muchos programadores, no quieren, o no están
> interesados en tocar código de la VM, o del corazón del entorno,
> simplemente, quieren heredar y trabajar, cosa, que por ejemplo, no hace
> falta en Java, pero es casi obligatorio en Squeak/Pharo, ya que la
> instalación de un simple paquete, puede comenzar a lanzar errores que o
> sabes como funciona todo por dentro, o no sabes solucionar, y como no hayas
> grabado antes de instalar, te deja la imágen coja con una instalación a
> medias.
>
> Luego está la fragmentación, hay gente que prefiere Squeak, mientras el
> mayor número se movieron a Pharo, porque querían un Squeak un poco más
> enfocado a empresas. Ambos, cada vez están más distantes el uno del otro y
> es más dificil tener paquetes compatibles (por lo leido), y al final, ni
> uno, ni otro.
> Al programador empresarial medio, le dá igual si Squeak/Pharo tiene un
> cliente IRC integrado, o un framework para músicos, porque eso no vende.
>
> Para el mercado empresarial hace falta acceso a motores de reporting,
> BBDD, estabilidad tanto en ejecución, como en diseño etc... Smalltalk
> requiere un conocimiento amplio del lenguaje (perdón), y del core del
> entorno para poder trabajar con él, para poder diseñarte lo que te falte,
> algo que en otros entornos no es tan necesario, programas y ya está, y
> muchos pensarán "para qué perder el tiempo, si luego no voy a poder
> contratar a nadie". Y al cliente final, le dá igual si tu programa lo
> hiciste en uno u otro lenguaje, lo que le importa es que funcione.
>
> Hay mucha gente buena en el mundo Smalltalk, (Germán, Chris Muller, Edgar,
> y un montón de nombres que me dejo en el tintero, y espero me perdonen) y
> también hay mucha gente fragmentada entre Pharo y Squeak, y de todos, la
> inmensa mayoría simplemente está por hobby, o educación, por lo que todo lo
> que estamos tratanto, le dá igual, porque al fin y al cabo, el uso que se
> le dá es de "juguete", sin uso en el mercado empresarial. Aún así, el
> número de gente involucrada en Smalltak, es ínfimo.
>
> A mi, me gustaría retomar Smalltalk. Cuando consiga sacar tiempo, volveré
> a ponerme con ello, y me gustaría que llegara el momento de decidir migrar
> mi proyecto actual, pero por desgracia, no sé si ese momento llegará.
>
> La pregunta no sería, "si smalltalk es más productivo, por qué ...", la
> pregunta es: "la comunidad smalltalk quiere/puede adaptarse a lo que pide
> el mercado comercial?"
>
>  
>

> **
>
>
> El 10/12/2011 13:50, Germán Arduino escribió:
>
>
>
>
>
>  El 10 de diciembre de 2011 08:43, Edgar J. De Cleene <
> [hidden email]> escribió:
>
>>
>>  > Digo si somos tan buenos, y creo que si, que Smalltalk es
>> diferencial, porque
>> > el resto de los techies del mundo no lo consideran asi (Y hablo más que
>> nada
>> > del entorno de las startups o grandes compañías de Internet. Si
>> producir en
>> > Smalltalk te permite como mínimo el doble de productividad que en un
>> lenguaje
>> > convencional, porque los grandes no ven eso...? POrque no aprovechan esa
>> > ventaja que les permitiría mucho menores costos?
>>
>>  No se si somos tan buenos y repito, que nos importa si "las grandes
>> compañias " , lo usen o no?.
>>
>>
> Pero debería importar. Java, tendrá todas las cosas malas que queráis,
> pero a día de hoy, es el lenguaje de programación más usado y extendido en
> el mundo empresarial. Sabemos que no es por méritos propios, pero ahí está.
> Smalltalk, se conoce poco, se conoce como algo de hace 30 años (como si
> nombras Cobol o Fortran),  y que siempre tuvo un precio prohibitivo, y a
> día de hoy, ninguna opción opensource es viable. Además, Java se estudia en
> la universidad. Smalltalk al parecer se estudia en Argentina, pero por
> ejemplo, en España, creo que Smalltalk, como mucho, se nombra en historia
> de programación y ya está, lo demás, es C/C++ y Java prácticamente (creo
> que en Cataluña si hay un catedrático que dá Smalltalk, pero es una
> excpeción, y aparte, viven en su mundo y en su idioma como si de otro pais
> se tratara). Ésto, también repercute como dices en los costos. Para
> encontrar un programador experimentado en Smalltalk, has de buscar mucho, y
> pagarle lo que pida, mientras un becario en Java cobrando una miseria, sale
> de debajo de las piedras.
>
> Algunos me conocéis y sabéis que llevo tras Squeak varios años, y nunca me
> puse en serio más allá de probar cosas y hacer un seguimiento del proyecto,
> pero, sobre todo, porque en mi opinión, por mucho que duela decirlo, por
> muy productivo que pueda ser Smalltalk, del lado OpenSource, no está
> preparado para el mundo empresarial (y yo no tuve tiempo de dedicarle, mi
> parte de culpa también tengo). Obviamente, VA Smalltalk (que lo veo
> carísimo) o VisualWorks o Dolphin (que sólo va en Windows), si serán
> entornos para producción y demostrado está (creo), pero las
> implementaciones opensource no. Pharo parece que quiso cambiar algo ésto, y
> para hacer alguna cosa en el mundo web puede servir, pero para aplicaciones
> empresariales y aburridas (mercado que aún muchos clientes es el que
> desean), a día de hoy Smalltalk está muy verde (y lo seguirá estando), ya
> que, si no me equivoco, el 80% al menos de sus "usuarios" lo usan para
> investigación, o como juguete, no para "trabajar". Además, también hay que
> tener en cuenta, que muchos programadores, no quieren, o no están
> interesados en tocar código de la VM, o del corazón del entorno,
> simplemente, quieren heredar y trabajar, cosa, que por ejemplo, no hace
> falta en Java, pero es casi obligatorio en Squeak/Pharo, ya que la
> instalación de un simple paquete, puede comenzar a lanzar errores que o
> sabes como funciona todo por dentro, o no sabes solucionar, y como no hayas
> grabado antes de instalar, te deja la imágen coja con una instalación a
> medias.
>
> Luego está la fragmentación, hay gente que prefiere Squeak, mientras el
> mayor número se movieron a Pharo, porque querían un Squeak un poco más
> enfocado a empresas. Ambos, cada vez están más distantes el uno del otro y
> es más dificil tener paquetes compatibles (por lo leido), y al final, ni
> uno, ni otro.
> Al programador empresarial medio, le dá igual si Squeak/Pharo tiene un
> cliente IRC integrado, o un framework para músicos, porque eso no vende.
>
> Para el mercado empresarial hace falta acceso a motores de reporting,
> BBDD, estabilidad tanto en ejecución, como en diseño etc... Smalltalk
> requiere un conocimiento amplio del lenguaje (perdón), y del core del
> entorno para poder trabajar con él, para poder diseñarte lo que te falte,
> algo que en otros entornos no es tan necesario, programas y ya está, y
> muchos pensarán "para qué perder el tiempo, si luego no voy a poder
> contratar a nadie". Y al cliente final, le dá igual si tu programa lo
> hiciste en uno u otro lenguaje, lo que le importa es que funcione.
>
> Hay mucha gente buena en el mundo Smalltalk, (Germán, Chris Muller, Edgar,
> y un montón de nombres que me dejo en el tintero, y espero me perdonen) y
> también hay mucha gente fragmentada entre Pharo y Squeak, y de todos, la
> inmensa mayoría simplemente está por hobby, o educación, por lo que todo lo
> que estamos tratanto, le dá igual, porque al fin y al cabo, el uso que se
> le dá es de "juguete", sin uso en el mercado empresarial. Aún así, el
> número de gente involucrada en Smalltak, es ínfimo.
>
> A mi, me gustaría retomar Smalltalk. Cuando consiga sacar tiempo, volveré
> a ponerme con ello, y me gustaría que llegara el momento de decidir migrar
> mi proyecto actual, pero por desgracia, no sé si ese momento llegará.
>
> La pregunta no sería, "si smalltalk es más productivo, por qué ...", la
> pregunta es: "la comunidad smalltalk quiere/puede adaptarse a lo que pide
> el mercado comercial?"
>
>  
>