- Pharo-dev - lists.pharo.org

[Pharo-project] String>>#base64Encoded
by Sven Van Caekenberghe March 23, 2011

March 23, 2011

Hi, It took me quite some time today to figure this out and it might be relevant for others too: it turns out that String>>#base64Encoded introduces newlines which you definitively do not want when doing Basic HTTP Encoding for example. The tricky part is that it works when you stay below a certain length. This can easily be solved by invoking Base64MimeConvertor with the #mimeEncode: <string> multiLine: false Zinc HTTP Components now does this consistently through ZnUtils class>>#encodeBase64: Sven

3 4

[Pharo-project] Pharo 1.2 red again
by Torsten Bergmann March 23, 2011

March 23, 2011

Pharo 1.2 is red again! DuplicatedVariableError: stylingActive is already defined in Workspace https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0

Re: [Pharo-project] test crashing the cog vm
by Marcus Denker March 23, 2011

March 23, 2011

On Mar 22, 2011, at 2:35 PM, Alexandre Bergel wrote: > I am not saying that this is feasible with the current VM. But I am doubtful that the bytecode verification can only be done in the VM. If something get wrong, why not to raise a primitiveFailed, as 1/0 will do? > Because checking all these things at runtime will make interpretation slow. > I have the impression that you give a particular status to the bytecodes. I have the feeling that we should not. Yes, to be interpretable without having to check at runtime. > I can realize a division, and time to time it get wrong (/0). But the VM does not crash. So, why if I evaluate the wrong bytecodes, the VM should crash? Because we don't want to check everything, else it is too slow. > You could have the necessary guards in the VM. Slow. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

6 15

[Pharo-project] Issue 3848 in pharo: Pressing Alt+x remove the class even if a selector is selected
by pharo＠googlecode.com March 23, 2011

March 23, 2011

Status: Accepted Owner: nicolas....@gmail.com New issue 3848 by nicolas....@gmail.com: Pressing Alt+x remove the class even if a selector is selected http://code.google.com/p/pharo/issues/detail?id=3848 What I did: - browse diffs from MC (changes) - select a new method, pres ALT+b to browse in the browser that opens, my new method is selected - pres ALT+x removed the class instead of removing the selector That was surprising... ... Fatal in my case, the class being Fraction GRR there's decidely no way to easily and selectively revert some of my changes !

1 1

[Pharo-project] Automating issue tracker update when a package is published
by Nicolas Cellier March 23, 2011

March 23, 2011

I know what I gonna hear, www.squeasource.com is already overloaded and we can't, but it would be super-nice if the Pharo issue tracker were updated automagically when a slice is commited in the inbox. Nicolas

5 4

[Pharo-project] [update 1.3] #13105
by stephane ducasse March 22, 2011

March 22, 2011

13105 ----- - Remove Arc Line Path CruverFitter.... ST-80-Path. Stef

1 0

[Pharo-project] Issue 3846 in pharo: There is no way to revert a change in a patch browser nor in Plymorph diff
by pharo＠googlecode.com March 22, 2011

March 22, 2011

Status: Accepted Owner: nicolas....@gmail.com New issue 3846 by nicolas....@gmail.com: There is no way to revert a change in a patch browser nor in Plymorph diff http://code.google.com/p/pharo/issues/detail?id=3846 When I browse my local changes versus the official Pharo repository, I'd like to have the possibility of reverting some of my changes. I can't ! The only option (Install) or (install incoming version) will just re-install my own change...

1 0

Re: [Pharo-project] Getting a functionning unstable image
by Marcus Denker March 22, 2011

March 22, 2011

On Mar 22, 2011, at 1:25 PM, StÃ©phane Ducasse wrote: > +1 > > Now condenses change should work too :) > I am slowly adopting a radical "if we don't test it, it's will brake" point of view. I now even say: If we don't test it, it *should* be broken! Because it is dead code and should be removed. Marcus >>> So it was my fault finally: it's because I was too early, and started >>> from Pharo0.x, then applied this automated condenseSources: >>> >> Oh. >>> >>> That explains why I can never upgrade from a newer image... >>> I brought my 0.x image up to 1.2 by some tricky manual MC loading >>> and/or selective loading. >>> But now, things shall be easier :) >>> >> >> Yes... the thing is that everythign that we do not test will not work. We >> do not test updating 0.x --> 1.2. It *will* be broken. >> (And there is the question if it makes sense to keep these things working. >> I vote for investing into a declarative bootstrap instead, far more important) >> >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 3

March 22, 2011

13104 ----- - Polymorph override cleaning. Part three Stef

1 0

Re: [Pharo-project] Issue 2144 in pharo: startUp and shutdown missed registered classes
by pharo＠googlecode.com March 22, 2011

March 22, 2011

Updates: Status: Closed Comment #2 on issue 2144 by marcus.d...@gmail.com: startUp and shutdown missed registered classes http://code.google.com/p/pharo/issues/detail?id=2144 just checked and I think it looks good (last inspect is empty)

1 0