"Lic. Edgar J. De Cleene" edgardec2001@yahoo.com.ar wrote:> But remains problems with SVI what I can't solve.

...

From documentation , could be a Mac specific problem.

And what about 500 + packages what exist today ? All works ?

I think what all agree what Squeak is a moving target , but I wish move to slow speed...

Have you tried, Edgar, to use Services + RB extensions? If that works, then RB per se may be come unimportant.

Where should information like this be reported? I'm sure 3.8's managers would like to have info on the status of major packages. Is Mantis the place? How about success reports? Maybe we should do this on the swiki?

One thing to keep in mind, is that it may make sense to have a freeze in order to support external packages catching up. I've been littered recently by posts from Debian telling me how to get my packages into the next release of Debian if they aren't already in. Irrelevant to me--I can read the bug tracker and see that my packages are working fine--but it's useful in general.

I know that at some point we have to draw the line. IMHO, RB is at least of borderline importance. It's a major bragging point of Squeak, and it's an application that uses text-as-code. It would be a shame to ship without one of our best applications, and it would be worrisome that if RB doesn't work then other applications using text-as-code might not work either.

But it's a hard decision, and I understand that we can't just sit here waiting forever. Some people would rather have 3.8 released even if RB does not work. This is something the general community will have to decide.

Finally, I don't buy the "moving target" excuse. Linux is a moving target as well, but Debian is very careful with its releases and manages to ship with thousands of working packages. New releases tend to be *more* reliable. To make this happens requires a basic management approach -- something that is perhaps unnatural to coders? What I mean is, you have to decide wthat you want, measure your progress towards it, and deal with it whenever your measurements suggest that something is behind schedule. The solutions are not generally hard, but you have to know where you are going and know what your progress is towards it.

-Lex

I'm glad to hear that RB works with just a small change.

"Lic. Edgar J. De Cleene" edgardec2001@yahoo.com.ar wrote:

By the way , you begin to prepare Universes for 3.8 ?

I'd like to but I'm terribly busy this summer. My tentative plan is to skip 3.8 and do another one for 3.9. Also, there is a packages team now that is talking about replacing the universes process one day; if they beat me to the punch then great!

In the meantime, the development universe is open for updates, and right now that universe is tracking 3.8. Generally the development universe has dependencies and has stuff that is more likely to load, while SqueakMap has the newest published version of everything. Post code to each of these as appropriate.

If anyone is interested enough in this to put in the 10-20 hours required to produce a 3.8 package set, then email me and I can help you with any infrastructure you need. Or, of course, just do it yourself without asking -- all the software and information is online and freely available.

As I only have modem connection I manage to have SqueakMap working without connection (useful if you loaded packages some time and wish try other image build ).

Universes caches packages in the filesystem, but not the map itself -- the map would have to be reloaded in each image. To get the map caching, the simplest approach would be to have Squeak going through a caching HTTP proxy such as Squid. Or, make a modem connection for just long enough to download the map.

-Lex

Edger,

I could solve loading problems by simple doing AbstractString := String, so this issue is solved. (Could be a simpler one , easy to add to image).

But, let's fix the package...

I send mail about this.

Yes. I saw it afterwards. Thanks!

But remains problems with SVI what I can't solve.

...

From documentation , could be a Mac specific problem.

And what about 500 + packages what exist today ? All works ?

Probably not. But, the problem was the early adaptors; I'd suspect that majority of packages weren't not tyring to follow the old string hierachy.

Still, we need to check these packages and update if necessary.

-- Yoshiki

Hi folks!

I have been waiting for the final 3.8 release to be made so that I could write a new report about the "state" of what is going on. That report will still have to wait a day or two so that I can take a closer look at 3.8 (because the zip is not what I expected, and I have emailed Michael about it), but I wanted to respond a bit here.

"Lic. Edgar J. De Cleene" edgardec2001@yahoo.com.ar wrote:

Yoshiki

...

Probably not. But, the problem was the early adaptors; I'd suspect that majority of packages weren't not tyring to follow the old string hierachy.

Still, we need to check these packages and update if necessary.

-- Yoshiki

I saw the "official" 3.8 final announces. Sounds like "we know still too many bugs , but declare final anyway"

No, not really. The 3.8 has been delayed quite a bit already due to several factors and I think Michael decided it was time to put down the foot. I have good hopes for the release, even if the recent big changes (m17n) has created issues. But such is life, we need to move forward.

And I do not wish repeat the Big Bang warning what send a long time ago. All as I see is divergence . 3.8.x ? Are you serious?

Yes, what Michael meant is that with 3.8 we will take greater care in backporting important fixes so that 3.8 can be gradually "fixed". Post release fixes hasn't been used much in earlier releases, but this time we have prepared a bit for them - for example, the final image should ask the user when started the first time if he/she wants to load updates.

Note: The zip uploaded and mentioned by Michael is... not the final Full (or Basic) image AFAICT. Not sure if Michael made a mistake or if this "pre-loaded" image is something different.

Said something and not keep decision. (nothing was removed from this release and converted to SqueakMap package for loading).

We never said that we would do that for 3.8. 3.8 is meant to be the "last" fat release.

Someone with power decides changes the rules and "the rest of us" suffer.

No. Michael is release boss for 3.8, he calls the shots - but AFAIK no "rules" has changed.

Unfortunately Michael has been very busy lately with other things, but I have confidence in that 3.8 will be released properly during the following days.

Sorry If one more time I should wear the Advocatus Diaboli togue.

Edgar

regards, Göran

Edger,

Sounds like "we know still too many bugs , but declare final anyway"

"We know some bugs, and we expect some unknown bugs exist, expecially in the external packages. But, the base image has been tested in various projects and the base line seems to work ok. So let's have an official release. With or without the official release, we'll be fixing problems anyway, and with the official release, we'd expect more people use it and get bugs fixed faster."

-- Yoshiki

Now that squeak have more translations available how do we manage them?

How can we get the french translation into 3.8 because now there is english, deutsch and espagnol? We would like to be able to avoid to have yet another custom image for french.

This is really important for us the french: in fact for our users. :) May be in the future we will have so much languages that it make senses to separate them but for now it would be nice to have everything packed. As translation seems to be project based we got even have the same tools in french, english spanish...in different projects :)

Stef

I think that this is not a good solution. We cannot afford complex solution with the number of people actually doing something. We have to have a process to remove local and propose distribution with all the languages or shrink version with only english.

Stef

=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:

...

How can we get the french translation into 3.8 because now there is english, deutsch and espagnol? We would like to be able to avoid to have yet another custom image for french.

Good question -- it is awkward! I have already been asked about adding a Debian package with an image pre-set to German, but I have said no so far because it increases the archive size by over 10 megabytes for each such language and each version we want to support.

One solution for dealing with this would be for Squeak to pick up locale information from the OS. I'm sure every desktop OS around these days has some way to inform applications of what language it would like to use. So we could define a VM primitive for "prefered language" and have an "automatic" setting at the image level that consults this primitive. For oddball platform that do not supply locale information, the VM can read it from some Squeak-specific configuration file.

This way, we can distribute just one image, but everyone will see it rendered in their own language.

Lex

Most of that spec sounds good, although it is overkill for the question at hand the language by itself would work. All we need is a stupid primLanguage function that has a fallback to an image-level preference. This might make a great hacking session on #squeak some time if you can gather VM hackers for at least two platforms.

Regarding the spec, though, the timezone interface sounds fishy. It is reporting an offset, but the offset changes over time. So, (a) you have to call the offset primitive every time you want to do any timezone computation, and (b) even then there is a race condition, and the offset might change between the time you query it and the time you use it. Sure you will usually win this race, but is it a good idea to *design* an unavoidable race condition into the spec?

It seems better to go to one of two extremes. Either have the VM handle timezones, and thus the "DateAndTime now" primitive returns a time plus its offset to UTC, or have full timezone support in the image instead of trying to do it halfway. David Lewis has done work on this latter angle if you want to go in that direction.

-Lex

On Jun 5, 2005, at 9:09 PM, Lex Spoon wrote:

Most of that spec sounds good, although it is overkill for the question at hand the language by itself would work. All we need is a stupid primLanguage function that has a fallback to an image-level preference. This might make a great hacking session on #squeak some time if you can gather VM hackers for at least two platforms.

Ok, and that will never happen.

Mike's proposal is out there for at least 8 months, and nobody as yet has done a better proposal, yet argue against it.

This is the typical thing in the Squeak community: Not doing the practical next step, because "something better" could be done. That will then never be implemented, thus then nothing happens.

Marcus

As I mentioned just a couple of days ago, LocalePlugin already exists to that spec. A new VMMaker including it will be available shortly.

tim

would it be possible to have also the new method compiled format that you did and that we are waiting since ages... :)

Stef

tim

Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: RIW: Re-Invent Wheel

Mike's proposal is out there for at least 8 months, and nobody as yet has done a better proposal, yet argue against it.

Actually, this proposal was discussed between Mike, John Mac, Ian and me to make sure it can be implemented relatively easily.

This is the typical thing in the Squeak community: Not doing the practical next step, because "something better" could be done. That will then never be implemented, thus then nothing happens.

The practical next step here would be to find some time to actually implement it. I'm kinda guilty here because the discussion of the locale plugin coincided with my move to Palo Alto and it just got dropped then on my part.

Cheers, - Andreas

On Tue, Jun 07, 2005 at 09:56:22PM -0700, Andreas Raab wrote:

Hi Lex,

<snip>

...

Regarding the spec, though, the timezone interface sounds fishy. It is reporting an offset, but the offset changes over time. So, (a) you have to call the offset primitive every time you want to do any timezone computation, and (b) even then there is a race condition, and the offset might change between the time you query it and the time you use it. Sure you will usually win this race, but is it a good idea to *design* an unavoidable race condition into the spec?

I disagree. I think you're going way beyound what's likely and reasonable here. Contrary to my cell phone (which actually determines the time zone it is in when I leave the plane and turn it back on) I have yet to see a laptop or desktop which does that. Because of that the question whether there is a race condition or not is irrelevant, plain and simple. Even if the time zone *does* change, and even if the machine *did* determine whether it is in a new time zone or not, reacting to this change is nothing that has any sort of realtime constraints. In reality, all people I've met on airplanes use either the start or the destination time zone and don't care one iota about intermediate time zones. (btw, we *did* consider this question when we talked about the interface and considered it irrelevant)

Andreas, the potential race condition is present because the TZ offset changes as a function of time for any given timezone, not because the timezone itself may be changed (which of course is also possible). Specifically, the value of the offset changes at daylight savings time transitions (and leap second transitions if you wanted to be really picky about it).

You are correct that this is of little practical consequence, but I think that Lex's point is that it is a shame to do this wrong when it would be just as easy to do it right.

FWIW, my own personal opinion is carry on as planned. The timezone offset primitive is useful, and it's better to get it almost right than to leave it completely wrong for another five years.

Dave

p.s. A minor nit in case this is not yet fully implemented: Timezone offsets should be reported in units of seconds (or minutes), rather than hours. There is no need to use a float to handle this. I can't think of any specific case where this would be a problem, but it seems possible that using a float could introduce numeric precision issues e.g. when comparing two times for equality.

The widely used timezone tables represent the offset in units of seconds, while some (maybe obsolete) gettimeofday() implementations use minutes. We should use seconds, and have the primitives answer integer values rather than floats.