- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Alien, ODBC, Cog and VM crash

by Luc Fabresse

Hi Benoit, I am not sure that the squeaksource page is up to date. Try this: (ConfigurationOfAlien project version: 'default') load: {'All'. 'Win32'} Cheers, #Luc 2011/12/10 Benoit St-Jean <bstjean(a)yahoo.com> > Hi everyone, > > I'm trying to load Alien in "Pharo 1.3 OneClick" and "Pharo 1.4 > Unstable". A few problems. > > 1) Trying to load only win32 specifics (by executing "ConfigurationOfAlien > loadWin32" as told on squeaksource) pops a message telling me that > Alien-Example is a prerequesite. > 2) When loading ConfigurationOfAlien (without going specific by executing "ConfigurationOfAlien > loadWin32", just executing" (Smalltalk globals classNamed: > 'ConfigurationOfAlien') perform:#loadLatestVersion." as told on > squeaksource, it works fine until I try to load ODBC from squeaksource. At > this poing, the image hangs for a while until the VM bombs! > > It bombs after a while after executing : > > MCHttpRepository > location: 'http://www.squeaksource.com/ODBC' > user: '' > password: '' > > Any idea? Anyone has tried to use ODBC & Alien with Pharo > 1.3 and was > successful ? > > Screenshot and crash dump attached. > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > >

Dec. 10, 2011

[Pharo-project] Waiting for deferred UI messages

by Sean P. DeNigris

testSimulateRightClick | workspace menu sem | workspace := Workspace open. [ morph := World submorphThat: [ :m | m model == workspace ] ifNone: [ nil ]. (Delay forMilliseconds: 100) wait. morph isNil ] whileTrue. WorldState addDeferredUIMessage: [ morph simulateRightClick ]. [ "execution gets stuck in this loop" menu := World submorphThat: [:m | m isKindOf: MenuMorph ] ifNone: [ nil ]. (Delay forMilliseconds: 100) wait. menu isNil ] whileTrue. self assert: menu isNil not. menu delete. When running from OB, the above deferred message block never gets evaluated. Execution loops forever in the last block. I thought that the delay would give the UI an opportunity to process it. How do I modify this to work? Thanks. Sean -- View this message in context: http://forum.world.st/Waiting-for-deferred-UI-messages-tp4179541p4179541.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 10, 2011

[Pharo-project] Alien, ODBC, Cog and VM crash

by Benoit St-Jean

Hi everyone, I'm trying to load Alien in "Pharo 1.3 OneClick" and "Pharo 1.4 Unstable".Â A few problems. 1) Trying to load only win32 specifics (by executing "ConfigurationOfAlien loadWin32" as told on squeaksource) pops a message telling me that Alien-Example is a prerequesite. 2) When loading ConfigurationOfAlien (without going specific by executing "ConfigurationOfAlien loadWin32", just executing"(Smalltalk globals classNamed: 'ConfigurationOfAlien') perform:#loadLatestVersion." as told on squeaksource, it works fine until I try to load ODBC from squeaksource.Â At this poing, the image hangs for a while until the VM bombs! It bombs after a while after executing : MCHttpRepository Â Â Â location: 'http://www.squeaksource.com/ODBC' Â Â Â user: '' Â Â Â password: '' Any idea?Â Anyone has tried to use ODBC & Alien with Pharo > 1.3 and was successful ? Screenshot and crash dump attached. Â ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

Dec. 10, 2011

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Levente Uzonyi

On Sat, 10 Dec 2011, Mariano Martinez Peck wrote: > On Sat, Dec 10, 2011 at 12:09 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Fri, 9 Dec 2011, Schwab,Wilhelm K wrote: >> >> Ok, but I have never failed to be impressed by how much trouble even >>> green threads can cause. Meaning no disrespect, if I had a repeatable >>> failure scenario, I would make the switch to a mutex just in case. If for >>> no other reason, Semaphore>>critical: makes assumptions about what is and >>> is not interruptible. I don't have to so much as play dumb here (it comes >>> naturally at the vm level), but I can't help wondering about the validity >>> of the assumptions, the correctness of the code, and all the more so given >>> our move to Cog. >>> >> >> Is there a reason *not* to use Mutex in such situations? We have multiple >> users telling us there is a problem. >> >> Mutex is broken, so you better not use it. :) >> >> > Why? where? what should I use instead? It's semaphore can get more than one signal somehow. Details here: http://bugs.squeak.org/view.php?id=6830 . I have no answer for your third question. :) Levente > > >> >> Levente >> >> >> >> ______________________________**__________ >> From: pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>[ >> pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>] >> on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >> Sent: Friday, December 09, 2011 1:33 PM >> To: Pharo-project(a)lists.gforge.**inria.fr<Pharo-project(a)lists.gforge.inria.fr> >> Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image? >> >> On 09.12.2011 16:59, Schwab,Wilhelm K wrote: >> >>> I would be very curious about what happens if you replace the >>> socket-related mutual exclusion semaphores with mutexes. >>> >> For the semaphore in question here, there is no recursion going on in >> any of the critical sections. >> So the answer to that would be absolutely nothing. >> >> Cheers, >> Henry >> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 10, 2011

Re: [Pharo-project] GZipWriteStream crashing my VM when serializing ?

by John McIntosh

Mmm I recall a problem from long ago where the buffer passed into the zip call was not big enough to store the results. If you pass in a small chunk of data, why the buffer to hold the results and the decode data is bigger than the buffer going in. So the two sizes, input and output are? On Fri, Dec 2, 2011 at 4:41 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. We are doing some experiments with Fuel and GZip streams... Now I > have a beatiful test like this: > > testMethodContextThisContext > > Â Â Â | materializedContext context | > Â Â Â context := thisContext copy. > Â Â Â materializedContext := self resultOfSerializeAndMaterialize: context. > > and it crashes like crazy. From the VM crash stack, I can see: > > > Smalltalk stack dump: > 0xbff66ba4 M GZipWriteStream(DeflateStream)>deflateBlock 447551436: a(n) > GZipWriteStream > 0xbff66bc8 M GZipWriteStream(DeflateStream)>nextPutAll: 447551436: a(n) > GZipWriteStream > 0xbff66be4 M GZipWriteStream(DeflateStream)>next:putAll:startingAt: > 447551436: a(n) GZipWriteStream > 0xbff66c08 M FLBufferedWriteStream>flushBuffer 448048664: a(n) > FLBufferedWriteStream > 0xbff66c20 M FLBufferedWriteStream>nextBytesPutAll: 448048664: a(n) > FLBufferedWriteStream > 0xbff66c40 M FLBufferedWriteStream>nextStringPut: 448048664: a(n) > FLBufferedWriteStream > 0xbff66c5c M FLByteStringCluster>serialize:on: 448054196: a(n) > FLByteStringCluster > 0xbff66c7c M FLByteStringCluster(FLPrimitiveCluster)>serializeInstance:with: > 448054196: a(n) FLByteStringCluster > 0xbff66ca0 M [] in > FLByteStringCluster(FLIteratingCluster)>serializeInstances: 448054196: a(n) > FLByteStringCluster > 0xbff66cc8 M IdentitySet(Set)>do: 451711680: a(n) IdentitySet > 0xbff66ce4 M FLByteStringCluster(FLIteratingCluster)>serializeInstances: > 448054196: a(n) FLByteStringCluster > 0xbff66d00 M > FLByteStringCluster(FLIteratingCluster)>serializeInstancesStepWith: > 448054196: a(n) FLByteStringCluster > 0xbff66d1c M FLSerialization>clusterInstancesStepOf: 448053428: a(n) > FLSerialization > 0xbff66d38 M [] in FLSerialization>instancesStep 448053428: a(n) > FLSerialization > 0xbff66d58 M OrderedCollection>do: 449989736: a(n) OrderedCollection > 0xbff66d74 M FLSerialization>instancesStep 448053428: a(n) FLSerialization > 0xbff66d8c M FLSerialization>run 448053428: a(n) FLSerialization > 0xbff66db0 I [] in FLSerializer>defaultSerialization 447550464: a(n) > FLSerializer > 0xbff66dd8 M [] in FLSerializer>serialize:on: 447550464: a(n) FLSerializer > 0xbff66df8 M BlockClosure>ensure: 448052884: a(n) BlockClosure > 0xbff66e18 M FLSerializer>serialize:on: 447550464: a(n) FLSerializer > 0xbff66e3c M [] in > FLMethodContextSerializationTest(FLSerializationTest)>serialize: 447235380: > a(n) FLMethodContextSerializationTest > 0xbff66e60 M [] in GZipWriteStream class(PositionableStream class)>on:do: > 419845144: a(n) GZipWriteStream class > 0xbff66e80 M BlockClosure>ensure: 448048616: a(n) BlockClosure > 0xbff66ea0 M GZipWriteStream class(PositionableStream class)>on:do: > 419845144: a(n) GZipWriteStream class > 0xbff66ec4 M [] in FLGZipStrategy>writeStreamDo: 447550896: a(n) > FLGZipStrategy > 0xbff66ee0 M FLByteArrayStreamStrategy>writeStreamDo: 447550884: a(n) > FLByteArrayStreamStrategy > 0xbff66efc M FLGZipStrategy>writeStreamDo: 447550896: a(n) FLGZipStrategy > 0xbff66f18 M > FLMethodContextSerializationTest(FLSerializationTest)>serialize: 447235380: > a(n) FLMethodContextSerializationTest > 0xbff66f34 M > FLMethodContextSerializationTest(FLSerializationTest)>resultOfSerializeAndMaterialize: > 447235380: a(n) FLMethodContextSerializationTest > 0xbff66f58 M FLMethodContextSerializationTest>testMethodContextThisContext > 447235380: a(n) FLMethodContextSerializationTest > > > any idea of where I should start to look at? > > Thanks > > > -- > Mariano > http://marianopeck.wordpress.com > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd.Â http://www.smalltalkconsulting.com ===========================================================================

Dec. 10, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 94 - AnnouncementSet

by Sean P. DeNigris

Igor Stasenko wrote > > which is pretty useless IMO. > The collaborative book says: If you want to register the same action for multiple events, simply create an AnnouncementSet using a comma: > > Parent>>initialize > super initialize. > self session announcer on: AddChild, RemoveChild do: [:it | self > changeChild: it child] -- View this message in context: http://forum.world.st/Re-Pharo-users-COTDC-94-AnnouncementSet-tp4178427p417… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 10, 2011

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

by Mariano Martinez Peck

Looks awesome. Thanks for sharing and congrats. On Fri, Dec 9, 2011 at 4:58 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > 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 > > > -- Mariano http://marianopeck.wordpress.com

Dec. 10, 2011

Re: [Pharo-project] [ANN] Magma 1.3

by Mariano Martinez Peck

On Thu, Dec 8, 2011 at 11:08 PM, Chris Muller <ma.chris.m(a)gmail.com> wrote: > I am very pleased to announce the immediate availability of Magma 1.3. > The following detail the major improvements to 1.3 over 1.2: > > Serializer Upgrade > ==== > BlockClosures (Contexts and CompiledMethods too, of course), can now > be stored in the database, even with references to inst-vars, self, > temps or globals. > Excellent. I will take a look. Proxy Transparency > ==== > A new extension to the WriteBarrier should now alleviate the need to > send #yourself to primitive arguments! Primitives which require > arguments are now overridden in the anonymous subclass so that the > arguments will automatically be ensured to be fully-reified for the > super call. > > I would like to take a look to this. In which primitives you need to send #yourself for example? This is because otherwise the VM will fail / crash because it expects the parameters of a primitive to be of a certain type rather than a proxy ? Which are those subclases you mention that override the primitive methods? Thanks and congrats for the release. -- Mariano http://marianopeck.wordpress.com

Dec. 9, 2011

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Mariano Martinez Peck

On Sat, Dec 10, 2011 at 12:09 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 9 Dec 2011, Schwab,Wilhelm K wrote: > > Ok, but I have never failed to be impressed by how much trouble even >> green threads can cause. Meaning no disrespect, if I had a repeatable >> failure scenario, I would make the switch to a mutex just in case. If for >> no other reason, Semaphore>>critical: makes assumptions about what is and >> is not interruptible. I don't have to so much as play dumb here (it comes >> naturally at the vm level), but I can't help wondering about the validity >> of the assumptions, the correctness of the code, and all the more so given >> our move to Cog. >> > > Is there a reason *not* to use Mutex in such situations? We have multiple > users telling us there is a problem. > > Mutex is broken, so you better not use it. :) > > Why? where? what should I use instead? > > Levente > > > > ______________________________**__________ > From: pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>[ > pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>] > on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] > Sent: Friday, December 09, 2011 1:33 PM > To: Pharo-project(a)lists.gforge.**inria.fr<Pharo-project(a)lists.gforge.inria.fr> > Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image? > > On 09.12.2011 16:59, Schwab,Wilhelm K wrote: > >> I would be very curious about what happens if you replace the >> socket-related mutual exclusion semaphores with mutexes. >> > For the semaphore in question here, there is no recursion going on in > any of the critical sections. > So the answer to that would be absolutely nothing. > > Cheers, > Henry > >> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 9, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 94 - AnnouncementSet

by Igor Stasenko

which is pretty useless IMO. there is no any performance benefit for using groups over single ones. On 9 December 2011 23:54, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm a group of announcements. I can be used to register action to a group of announcement instead of enumerating them one by one. > > > On Dec 9, 2011, at 10:46 PM, sean(a)clipperadams.com wrote: > >> 93 classes done >> 802 classes remaining >> Continuing in Announcements... >> >> Today: Â AnnouncementSet >> >> >> 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 >> >> p.s. this message was sent from a pharo image. Did you know you could easily do that?! >> > > -- Best regards, Igor Stasenko.

Dec. 9, 2011