May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Amazon AWS S3 Monticello Mirror

by StÃ©phane Ducasse

thanks this is an excellent initiative. Marcus will love that. Stef On May 15, 2011, at 10:46 PM, Sven Van Caekenberghe wrote: > Hello, > > I did a little proof of concept: I set up an Amazon AWS S3 Monticello Mirror. > > I wrote a Smalltalk script using the Zn HTTP client, the Zinc-AWS S3 client and some pieces of MCHttpRepository and ZnMonticelloServerDelegate to copy all 273 entries of http://www.squeaksource.com/ZincHTTPComponents/ into a folder called 'ZincHTTPComponents' in an S3 bucket named 'mc-mirror'. Then I configured things a bit to make it look like a public read-only Monticello HTTP repository. > > The net result is this Monticello repository: > > MCHttpRepository > location: 'http://mc-mirror.s3-website-eu-west-1.amazonaws.com/ZincHTTPComponents/' > user: '' > password: '' > > Which works as it should on unmodified images (except that it is read-only). > With a proper DNS CNAME entry the hostname could become something more friendly. > > Next, I will try to turn this little hack into something more robust, that can also efficiently resynchronize the copy when versions are added to the original. Then, this could become the bot I talked about earlier. > > IMHO this could be a very robust fallback mechanism for SqueakSource, and even a primary one for those repositories you never commit to (which is most of them) and thus take off some the load of SqueakSource. > > Sven > >

May 15, 2011

Re: [Pharo-project] Support for stdout without OSProcess (issue 4065)

by StÃ©phane Ducasse

Thanks this is what I guessed and I opened a ticket 4233 to check that. Stef On May 15, 2011, at 11:09 PM, David T. Lewis wrote: > On Sun, May 15, 2011 at 07:06:35PM +0200, St?phane Ducasse wrote: >> david >> >> how do we use it from the image to print on stdout? >> >> Stef > > Of course I just use OSProcess ;-) But in Squeak trunk (http://source.squeak.org/trunk) > the stdio updates are in Files-ul.96 and Files-ul.97. > > Name: Files-ul.96 > Author: ul > Time: 24 January 2011, 3:45:32.858 am > UUID: d06be799-4c77-3b46-aff8-4abc589fafd3 > Ancestors: Files-mtf.95 > > Stdio support changes: > - Added stdio support code to FileStream. > - Unified API for accessing stdio streams. All users should send #stdin, #stdout and #stderr to FileStream to access the streams. > - MultiByteFileStream is used instead of CrLfFileStream. > - CrLfFileStream class >> #new is now deprecated > > Name: Files-ul.97 > Author: ul > Time: 24 January 2011, 3:59:59.143 am > UUID: 6f9985b2-9bce-a145-a3d2-276a76ce1fa7 > Ancestors: Files-ul.96 > > - removed previous stdio support code from StandardFileStream, migration is done in the preamble > > >> >> On May 15, 2011, at 6:55 PM, David T. Lewis wrote: >> >>> On Sun, May 15, 2011 at 06:44:30PM +0200, Stefan Marr wrote: >>>> Hi: >>>> >>>> What needs to be done for issue 4065? >>>> http://code.google.com/p/pharo/issues/detail?id=4065 >>>> >>>> I would like to have an easy way to provide compatibility for the RoarVM primitive RVMOperations>print: which really just dumps a string to stdout. So, ideally, I don't want to many dependencies like OSProcess in SMark. >>>> >>>> What would need to be done for that? The issue is not to verbose. >>>> Is it a missing print primitive in the VM? >>>> >>>> Thanks >>>> Stefan >>> >>> FilePlugin>>primitiveFileStdioHandles is present in both the interpreter >>> VM and Cog. It was added to the interpreter VM (SqueakSource/VMMaker) here: >>> >>> >>> Name: VMMaker-dtl.213 >>> Author: dtl >>> Time: 28 December 2010, 2:06:59 am >>> UUID: f2524f34-cfcb-46ea-80b6-81402f9a875f >>> Ancestors: VMMaker-dtl.212 >>> >>> VMMaker 4.4.4 >>> >>> Add FilePlugin>>primitiveFileStdioHandles adapted from oscog. >>> Reference Mantis 0007591: Add #primitiveFileStdioHandles to standard VM >>> >>> Notes r.e. adopting the oscog implementation of primitiveFileStdioHandles: >>> >>> Cog primitive uses "interpreterProxy topRemappableOop" which is defined for VM_PROXY_MINOR > 9 but standard VM support code is at VM_PROXY_MINOR 8 (Cog is at VM_PROXY_MINOR 11). Work around this by popping and pushing the result array rather than using topRemappableOop. >>> >>> Cog uses primitive failure return codes not yet supported in the interpreter VM. The primitive return codes need to be adopted in standard VM but this is not yet done. >>> >>> >> >

May 15, 2011

[Pharo-project] [ANN] PharoDev-1.3-13201

by Mariano Martinez Peck

Hi. IMPORTANT: This is not the final 1.3 release, it just one simple snapshot and one point. This image is based in PharoCore 1.3 13201 and includes also several fixes for the external packages like OB. Thanks to Fernando the Transcript is now much better. The image is here: https://gforge.inria.fr/frs/download.php/28547/Pharo-1.3-13201.zip And it was build by Hudson: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/150/ Nile was removed from dev image which means there are only 3 failing tests :) Best regards, -- Mariano http://marianopeck.wordpress.com

May 15, 2011

Re: [Pharo-project] Support for stdout without OSProcess (issue 4065)

by David T. Lewis

On Sun, May 15, 2011 at 07:06:35PM +0200, St?phane Ducasse wrote: > david > > how do we use it from the image to print on stdout? > > Stef Of course I just use OSProcess ;-) But in Squeak trunk (http://source.squeak.org/trunk) the stdio updates are in Files-ul.96 and Files-ul.97. Name: Files-ul.96 Author: ul Time: 24 January 2011, 3:45:32.858 am UUID: d06be799-4c77-3b46-aff8-4abc589fafd3 Ancestors: Files-mtf.95 Stdio support changes: - Added stdio support code to FileStream. - Unified API for accessing stdio streams. All users should send #stdin, #stdout and #stderr to FileStream to access the streams. - MultiByteFileStream is used instead of CrLfFileStream. - CrLfFileStream class >> #new is now deprecated Name: Files-ul.97 Author: ul Time: 24 January 2011, 3:59:59.143 am UUID: 6f9985b2-9bce-a145-a3d2-276a76ce1fa7 Ancestors: Files-ul.96 - removed previous stdio support code from StandardFileStream, migration is done in the preamble > > On May 15, 2011, at 6:55 PM, David T. Lewis wrote: > > > On Sun, May 15, 2011 at 06:44:30PM +0200, Stefan Marr wrote: > >> Hi: > >> > >> What needs to be done for issue 4065? > >> http://code.google.com/p/pharo/issues/detail?id=4065 > >> > >> I would like to have an easy way to provide compatibility for the RoarVM primitive RVMOperations>print: which really just dumps a string to stdout. So, ideally, I don't want to many dependencies like OSProcess in SMark. > >> > >> What would need to be done for that? The issue is not to verbose. > >> Is it a missing print primitive in the VM? > >> > >> Thanks > >> Stefan > > > > FilePlugin>>primitiveFileStdioHandles is present in both the interpreter > > VM and Cog. It was added to the interpreter VM (SqueakSource/VMMaker) here: > > > > > > Name: VMMaker-dtl.213 > > Author: dtl > > Time: 28 December 2010, 2:06:59 am > > UUID: f2524f34-cfcb-46ea-80b6-81402f9a875f > > Ancestors: VMMaker-dtl.212 > > > > VMMaker 4.4.4 > > > > Add FilePlugin>>primitiveFileStdioHandles adapted from oscog. > > Reference Mantis 0007591: Add #primitiveFileStdioHandles to standard VM > > > > Notes r.e. adopting the oscog implementation of primitiveFileStdioHandles: > > > > Cog primitive uses "interpreterProxy topRemappableOop" which is defined for VM_PROXY_MINOR > 9 but standard VM support code is at VM_PROXY_MINOR 8 (Cog is at VM_PROXY_MINOR 11). Work around this by popping and pushing the result array rather than using topRemappableOop. > > > > Cog uses primitive failure return codes not yet supported in the interpreter VM. The primitive return codes need to be adopted in standard VM but this is not yet done. > > > > >

May 15, 2011

[Pharo-project] Amazon AWS S3 Monticello Mirror

by Sven Van Caekenberghe

Hello, I did a little proof of concept: I set up an Amazon AWS S3 Monticello Mirror. I wrote a Smalltalk script using the Zn HTTP client, the Zinc-AWS S3 client and some pieces of MCHttpRepository and ZnMonticelloServerDelegate to copy all 273 entries of http://www.squeaksource.com/ZincHTTPComponents/ into a folder called 'ZincHTTPComponents' in an S3 bucket named 'mc-mirror'. Then I configured things a bit to make it look like a public read-only Monticello HTTP repository. The net result is this Monticello repository: MCHttpRepository location: 'http://mc-mirror.s3-website-eu-west-1.amazonaws.com/ZincHTTPComponents/' user: '' password: '' Which works as it should on unmodified images (except that it is read-only). With a proper DNS CNAME entry the hostname could become something more friendly. Next, I will try to turn this little hack into something more robust, that can also efficiently resynchronize the copy when versions are added to the original. Then, this could become the bot I talked about earlier. IMHO this could be a very robust fallback mechanism for SqueakSource, and even a primary one for those repositories you never commit to (which is most of them) and thus take off some the load of SqueakSource. Sven

May 15, 2011

Re: [Pharo-project] Support for stdout without OSProcess (issue 4065)

by Stefan Marr

Hi: On 15 May 2011, at 19:20, Stefan Marr wrote: > On 15 May 2011, at 19:06, StÃ©phane Ducasse wrote: >> david >> >> how do we use it from the image to print on stdout? > The primitive is supposed to return the file handles, and they can be used like normal files, I guess. > > See http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/154784 After filing in Eliot's change set from this mail: http://forum.world.st/Re-squeak-dev-stdio-td949485.html StandardFileStream stdout nextPutAll: 'bar'. works beautifully with http://squeakvm.org/mac/release/Squeak%205.7.4.1.zip However, there is some regression with that VM, it does not take the image on the command line. I am used to: /Applications/Squeak\ 4.2.5beta1U.app/Contents/MacOS/Squeak\ VM\ Opt Pharo-1.2.image HelloWorld /Applications/Squeak\ 5.7.4.1.app/Contents/MacOS/Squeak Pharo-1.2.image HelloWorld just opens a file dialog. I have to give the full file name. Esteban: is that a know regression? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 15, 2011

Re: [Pharo-project] [COTDC] 64 - UrlArgumentList

by laurent laffont

On Fri, May 13, 2011 at 9:29 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: UrlArgumentList > Someone use it ? No references in the image ...... Laurent. > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

May 15, 2011

Re: [Pharo-project] Support for stdout without OSProcess (issue 4065)

by Stefan Marr

On 15 May 2011, at 19:06, StÃ©phane Ducasse wrote: > david > > how do we use it from the image to print on stdout? The primitive is supposed to return the file handles, and they can be used like normal files, I guess. See http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/154784 Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 15, 2011

Re: [Pharo-project] Support for stdout without OSProcess (issue 4065)

by StÃ©phane Ducasse

david how do we use it from the image to print on stdout? Stef On May 15, 2011, at 6:55 PM, David T. Lewis wrote: > On Sun, May 15, 2011 at 06:44:30PM +0200, Stefan Marr wrote: >> Hi: >> >> What needs to be done for issue 4065? >> http://code.google.com/p/pharo/issues/detail?id=4065 >> >> I would like to have an easy way to provide compatibility for the RoarVM primitive RVMOperations>print: which really just dumps a string to stdout. So, ideally, I don't want to many dependencies like OSProcess in SMark. >> >> What would need to be done for that? The issue is not to verbose. >> Is it a missing print primitive in the VM? >> >> Thanks >> Stefan > > FilePlugin>>primitiveFileStdioHandles is present in both the interpreter > VM and Cog. It was added to the interpreter VM (SqueakSource/VMMaker) here: > > > Name: VMMaker-dtl.213 > Author: dtl > Time: 28 December 2010, 2:06:59 am > UUID: f2524f34-cfcb-46ea-80b6-81402f9a875f > Ancestors: VMMaker-dtl.212 > > VMMaker 4.4.4 > > Add FilePlugin>>primitiveFileStdioHandles adapted from oscog. > Reference Mantis 0007591: Add #primitiveFileStdioHandles to standard VM > > Notes r.e. adopting the oscog implementation of primitiveFileStdioHandles: > > Cog primitive uses "interpreterProxy topRemappableOop" which is defined for VM_PROXY_MINOR > 9 but standard VM support code is at VM_PROXY_MINOR 8 (Cog is at VM_PROXY_MINOR 11). Work around this by popping and pushing the result array rather than using topRemappableOop. > > Cog uses primitive failure return codes not yet supported in the interpreter VM. The primitive return codes need to be adopted in standard VM but this is not yet done. > >

May 15, 2011

Re: [Pharo-project] redundancy

by StÃ©phane Ducasse

OK thanks for the update. Stef > > Stef, > > GemSource is running Seaside2.6 and a very old version of the SqueakSource code. I'd rather run Seaside3.0 and Tobias' SqueakSource3 as an alternative to SqueakSource. > > And as a matter of fact, we have already started heading down that path. > > While I was on vacation we had a vm provisioned in a VMware data center for hosting a SqueakSource3 instance:) > > The plan is to run the SqueakSource3 instance as a beta for a couple of weeks to correct any load/code issues and then barring any big issues, open it up for general usage. > > I'll need a week or so to get the GemStone and SqueakSource3 installed and configured. > > When the beta is ready I'll send email to the list ... > > Dale > > > On May 14, 2011, at 12:54 AM, StÃ©phane Ducasse wrote: > >> Yes. >> So how do we do that? >> Dale can we use the ssgemstone you host? >> >> Stef >> >>>> >>> The problem is that the network operator is down... >>> >>> see http://code.google.com/p/pharo/issues/detail?id=4218 >>> >>> We should really t hink hard about redundancy... >>> >> > >

May 15, 2011