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

[Pharo-project] Zinc problem

by Norbert Hartl

As Zinc is now part of pharo may I assume that bug reports belong to the pharo tracker? I've discovered a problem in Zinc. If you execute this piece of code | client entity | client := ZnNeoClient new. entity := client applicationFormUrlEncodedEntity. entity at: 'testkey' put: 'Ã¶'. Transcript show: 'entity type: ', entity contentType printString; cr. Transcript show: 'encoded body: ', (String streamContents: [:stream| entity writeRepresentationOn: stream ]) You'll get (in pharo #13315) entity type: application/x-www-form-urlencoded;charset=iso-8859-1 encoded body: testkey=%C3%B6 As you can see the content type contains latin-1 as encoding while the body is utf-8 encoded. The utf-8 encoding comes from ZnUtils class>>writeQueryFields:on: that uses encodeForHTTP which uses utf-8 by default. Norbert

Dec. 5, 2011

Re: [Pharo-project] [Pharo-users] [pharo-users] Can't Load Magma in Pharo 1.3

by Mariano Martinez Peck

On Mon, Dec 5, 2011 at 8:22 AM, jtuchel <jtuchel(a)objektfabrik.de> wrote: > Hi Mariano, > > thanks a lot for your tip. So it seems like method > ConfigurationOfMaClientServer>>#version13: needs to be updated. It loads > V4.4.0 of OSProcess. > > spec > project: 'MaBase' with: '1.0'; > project: 'OSProcess' with: '4.4.0'. > > So there is the next question: A look at ConfigurationOfOSProcess reveals > that version440 loads package OSProcess-dtl.59 , as of today, the latest > version on squeak source is OSProcess-dtl.66.mcz. > > How can I find out which one between 59 and 66 is the right one? Or maybe I > Only their developers know. > shouldn't worry about it, but look at ConfigurationOfOSProcess instead... > But searching for ConfigurationOfOSProcess on Squeaksource doesn't bring up > any results. The problem is so well know that we should find a name for it..... it is simple: the guys who do the project, do not do/maintain the Metacello configurations. > So should I be using the MonticelloBrowser to look at > MetacelloRepository? > > Yes, you can. > I tried it on http:://www.squeaksource.com/MetacelloRepository and > surprisingly found out that I have the very latest version of > ConfigurationOfOSProcess loaded: ConfigurationOfOSProcess-mt.17 > > So it seems both ConfigurationOfOSProcess and > ConfigurationOfMagmaClientServer (and therefor I guess all dependent > configurations) need an update... > > Welcome to the real world: nobody updates the configurations. Not even when the load doesn't work. In the case of Magma and OSProcess nor of their developers did/maintain the configurations. I am not saying they shuld. everybody do as much as they can/want, I am just explaining you why it has not been updated. > Coming from Envy I find this whole Metacello stuff both a big improvement > over Monticello and a bit low level. But maybe the last one is just a > question of re-educating myself ;-) > >From my point of view, the problem is not the tool, but how people use it. > Still I am a bit puzzled about what I could do to make Magma load cleanly > into Pharo 1.3, other than fixing that one line in the debugger on every > load. Being an envy user, seeing a debugger during load leaves a bit of a > bitter taste in my throat, because chances are you are going to face > problems that stem from the broken atomicity of a load... > yes... > > But most of all: thanks for the pointers. I have learned a bit more about > Metacello today, which is a good thing! > Read the chapter if you want to know more about the tool itself :) > > Joachim > > > > -- > View this message in context: > http://forum.world.st/Re-Pharo-users-pharo-users-Can-t-Load-Magma-in-Pharo-… > Sent from the Magma mailing list archive at Nabble.com. > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > -- Mariano http://marianopeck.wordpress.com

Dec. 5, 2011

[Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Stefan Marr

Hi: I got here a Monticello package that does not properly load using the Metacello configuration. The image freezes and cmd+. does not pop up a debugger anymore. However, if I extract the source.st contained in the package and file it in manually, it does not freeze the image. I belief that I once saw with appropriate Transcript>>#show that something caused an infinite loop. There are dependencies in overrides I do on kernel classes. They seem to be properly resolved in the source.st file. Is there a way to force Monticello/Metacello to fall back on the included source instead of using the binary snapshot? (I guess that is going wrong for some reason). 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

Dec. 5, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Martin Dias

I forgot to say that I am working on a recent Pharo 1.3. And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream . MartÃn On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I get a SubscriptOutOfBounds error when I evaluate: > > | aStream zipStream | > > aStream := ByteArray new writeStream binary. > zipStream := GZipWriteStream on: aStream. > zipStream nextStringPut: ''. > zipStream nextStringPut: ''. > zipStream close. > aStream close. > aStream := aStream contents readStream binary. > zipStream := GZipReadStream on: aStream. > zipStream nextString. > zipStream nextString. > zipStream close. > aStream close. > > The error doesn't happen when I put just one string (instead of two). > > Do you see something wrong in the code? Should I report a bug? > > Thanks, > MartÃn >

Dec. 5, 2011

[Pharo-project] [update 1.4] #14246

by Marcus Denker

14246 ----- Issue 4998: ContextPart>>#runUntilErrorOrReturnFrom: http://code.google.com/p/pharo/issues/detail?id=4998 (reverted) -- Marcus Denker -- http://marcusdenker.de

Dec. 5, 2011

Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass

by Marcus Denker

>>>>>> >>>>>> I'm stuck too, and the Debugger is currently unusable in Pharo 1.4 (I >>>>>> just can't step overâ¦) >>>>> >>>>> Strange. Because I use it. >>>>> Do you have a scenario that we can focus on to fix the problem you see. >>>>> >>>>> So with Camillo, we found that reverting the change of Eliot (that we added for testing...) helps: http://code.google.com/p/pharo/issues/detail?id=4998 I will do that revert in 14246 (And no, we should not have added the change. But than, how can one test without testing?) -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

Dec. 5, 2011

Re: [Pharo-project] could you test the attached?

by Marcus Denker

Hi, With this change set, we get an error when doing the following: In the workspace do a "debug it" on this code: Transcript show: Class name then two times "step over" --> Subscript out of bounds error. Without the change it works. On Wed, Nov 16, 2011 at 8:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > Â Â I've found a bug inÂ ContextPart>>#runUntilErrorOrReturnFrom: that in a > certain rare circumstance causes the method to peel back too much of the > stack. Â This method is used in the debugger (e.g. completeStep: et al) but > also in Process termination. Â So it is right at the heart of the system. > Â I'm loath to simply commit it Â I'd really appreciate y'all testing with the > fix and reporting any changes you see. Â It does not affect the trunk test > suite (there is a test, WeakSetInspectorTest, which is unreliable, but apart > form that no observed effects). Â So, brave souls, please try with the > attached and see if you come to grief or not. > -- > thanks, > Eliot > -- -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

Dec. 5, 2011

[Pharo-project] A possible bug in GZip streams

by Martin Dias

Hi, I get a SubscriptOutOfBounds error when I evaluate: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close. The error doesn't happen when I put just one string (instead of two). Do you see something wrong in the code? Should I report a bug? Thanks, MartÃn

Dec. 5, 2011

Re: [Pharo-project] Keymapping & OB conflict (was Re: Chasing Browsers)

by Lukas Renggli

Ok, then it must be something else. I don't know why this Keymapping thing, but it is unlikely to work with OB if it was not written for OB. As I said, OB managed its keybindings itself. Lukas On 5 December 2011 03:51, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Lukas Renggli wrote >> >> OB. This means, if you select the method and press Cmd+n it should >> > > Bummer, Cmd-n with a method name selected in OB system browser still brings > up the non-chasing senders browser. > > -- > View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Lukas Renggli www.lukas-renggli.ch

Dec. 5, 2011

Re: [Pharo-project] A possible bug in GZip streams

by Martin Dias

(I am working on Pharo 1.3) On Mon, Dec 5, 2011 at 2:16 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I get a SubscriptOutOfBounds error when I evaluate: > > | aStream zipStream | > > aStream := ByteArray new writeStream binary. > zipStream := GZipWriteStream on: aStream. > zipStream nextStringPut: ''. > zipStream nextStringPut: ''. > zipStream close. > aStream close. > aStream := aStream contents readStream binary. > zipStream := GZipReadStream on: aStream. > zipStream nextString. > zipStream nextString. > zipStream close. > aStream close. > > The error doesn't happen when I put just one string (instead of two). > > Do you see something wrong in the code? Should I report a bug? > > Thanks, > MartÃn >

Dec. 5, 2011