a problem with Zinc on Pharo 1.1.1

Hi,
I'm trying to execute this:

ZnClient
        get: 'http://127.0.0.1:333/analytics/feeds/data' 
        username: '[hidden email]'
        password: 'shhhh'

... on a Pharo 1.1.1 image, with latest #stable Zinc version, and I'm getting DNU on: #mimeEncode:multiLine:

ZnUtils class>encodeBase64: string
        ^ (Base64MimeConverter mimeEncode: string readStream multiLine: false) contents

is a bug, or something I have wrong?

cheers,
Esteban

Esteban,

On 26 Apr 2011, at 18:20, Esteban Lorenzano wrote:

This should get you past that problem:

---
Name: Zinc-HTTP-SvenVanCaekenberghe.145
Author: SvenVanCaekenberghe
Time: 26 April 2011, 7:01:32 pm
UUID: f9f0831d-5ffa-4a5c-a8ec-b276c9babc35
Ancestors: Zinc-HTTP-SvenVanCaekenberghe.144

fixed ZnUtils class>>#encodeBase64: to test whether Base64MimeConverter responds to #mimeEncode:multiLine:, fall back to #mimeEncode: and manually remove Character cr occurences; this should fix Pharo 1.1.1 compatibility (Thanks Esteban Lorenzano for reporting this)
---

However, full Pharo 1.1.1 compatibility is not yet up to where it was ;-)
I will try to make all tests green again later on, but it will take some time.

Regards,

Sven

On 26 Apr 2011, at 19:10, Sven Van Caekenberghe wrote:

> However, full Pharo 1.1.1 compatibility is not yet up to where it was ;-)
> I will try to make all tests green again later on, but it will take some time.

OK, Zinc now has all tests green again in Pharo 1.1.1, 1.2.1 and 1.3.

I don't understand why, but I thought MC always executed class initializations, but apparently not (or not for existing classes).
ZnMimeType initialize fixed all failed tests.

Sven

--
Mariano
http://marianopeck.wordpress.com

On 26 Apr 2011, at 20:39, Mariano Martinez Peck wrote:

> Second, I've seen that problem too. I am sure that when loading a new version of a certain package, some class side #initialize are not called. When? which ones? I have no idea.
>
> I couldn't reproduce it. Can you?

I can't figure it out either, but I haven't really looked deeply into it.

As far as I can tell it just doesn't work: I guess #initialize is only called when the class is new or maybe when its definition is changed, maybe when the #initialize method changes, but certainly not all the time when you load new(er) versions of methods of that class. Maybe that is too much to expect, I don't know, it would be handy.

So when your #initialize calls say #initializeConstants and only that method is changed, you have a problem.

Maybe somebody else knows ?

Sven