Squeak 4.1 release candidate 2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Squeak 4.1 release candidate 2

Andreas.Raab
Folks -

I've prepared rc2 for testing of the 4.1 release on Squeak.org:

   http://ftp.squeak.org/trunk/4.1rc2/

If you look at the release schedule [1] you'll notice that we're
slipping a little (which I had expected). The new release candidate
includes the following changes:

* Condensed sources file. As previously mentioned, the new sources file
is a strict superset of the 4.0 sources file and preserves version
history between 4.1 and 4.0.

* Welcome notice(s). Please review in particular the welcome screen.
I've attached the welcome note below for review and improvement. If you
see anything that hasn't been mentioned but should, please let me know.
I've also revived two workspaces that I found useful in the past, one
about some of the less common UI elements and one about how to work with
Squeak.

* An updated Windows VM (4.0.2) which fixes various issues with 4.0.1.

(Ian, if you could build an updated installer I'd appreciate that)

As it stands, we're currently missing updated Unix and Mac VMs (I know
Ian has been working on it, so I'll ping him and John separately), we
still don't have all tests green, and there are still a few open issues
on Mantis [2].

If you can offer any help on any of these issues, you're extremely
welcome. I'm still hopeful that we can ship 4.1 with minimal delay but
in order to do that we need to address the pending issues, in particular
the failing tests.

And of course, please keep testing. Load your packages, run them, make
sure they work!

Cheers,
   - Andreas

[1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.html 

[2]http://bugs.squeak.org/view.php?id=7480

=======================================================================

        Welcome to Squeak - a free, open Smalltalk system.

Squeak 4.1 combines the license change occuring in the 4.0 release with
the development work that has been going on while the relicensing
process took place. Here are the highlights of the changes that resulted
in Squeak 4.1:

User Interface
--------------
We have adapted the 'face lift' look originally developed for Newspeak.
For those of us who like colored windows (quite a few as it turns out)
you can switch between uniform and colored windows in the 'Extras' menu
under 'Window Colors'.

The new menu bar makes Squeak much easier to discover than before. The
process of transitioning from the world menu is not complete yet, there
are still items that can only be accessed from the world menu (i.e., by
clicking on the desktop).

The search field integrated in the menu bar allows for direct navigation
to classes and methods - simply type in a partial class or method name
and see what happens.

A new set of inexpensive sub-pixel antialiased fonts derived from the
DejaVu fonts ('Bitmap DejaVu' in the font chooser) has been added. True
type font support has been upgraded to operate directly on files on disk
without the need to load the entire file into memory.

A new set of text editors has been added, allowing to decouple the
Morphic and MVC implementations for improved modularity. Morphic has now
regular blinking insertion point cursors instead of the (virtually
invisible) static cursor previously.

Compiler
--------
Squeak 4.1 includes the closure implementation from Cog as a
prerequisite for full Cog adoption later. With this implementation
Squeak finally has 'full' closures, allowing classic recursive examples
like the following to work:

        fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
        fac value: 5.

Support for literal ByteArray syntax has been added. Byte arrays can now
be written as #[1 2 3] instead of #(1 2 3) asByteArray  avoiding the
need for conversion.

Selectors including minus are now parsed correctly, for example 3 <- 4
is now parsed as (3) <- (4) instead of (3) < (-4). White space is no
longer allowed after an unary minus to denote a negative number literal.

Development
-----------
Syntax highlighting, based on Shout, is now included in all Squeak tools
by default. For workspaces, it can be explicitly disabled in the window
menu (entry 'syntax highlighting').

Sources and changes files are no longer limited to 32MB max size.
ExpandedSourceFileArray provides an implementation for source files of
arbitrary length, based on the CompiledMethodTrailer changes.

MessageTrace has been added, allowing senders and implementors to be
viewed without opening new windows all the time.  It utilizes a new
AlternatePluggableListMorphOfMany, which allows quick and easy
customization of the list. A quick adoption of DependencyBrowser has
been added allowing to browse dependencies between packages.

Core Libraries
--------------
Sets can now store nil just as any other collection. The collection
hierachy has been refactored to have both Set and Dictionary a subclass
of HashedCollection instead of having Dictionary a subclass of Set.
Squeak now uses a better distributed scaledIdentityHash for identity
sets and dictionaries.

StandardFilestream now performs read-buffering, dramatically speading up
some operations like "Object compileAll" (2x improvement) as well as
various other operations (scanning change lists etc).

A new traits implementation has been added. The implementation is
significantly smaller and simpler than the old version and can be
unloaded and reloaded without loss of information (i.e., traits
flattened during unload are restored during traits reloading).

A new extensible number parser hierharchy has been introduced
NumberParser and its subclasses provide support for parsing and building
numbers from strings and streams.

A new general cleanup protocol has been added. The cleanUp protocol
takes an optional argument to indicate whether we're doing an aggressive
cleanup (which involves deleting projects, change sets, and possibly
other destructive actions) or a more gentle cleanup that's only supposed
to clean out transient caches.

SystemDictionary and SmalltalkImage have been refactored. Smalltalk is
now an instance of SmalltalkImage, representing a facade for system-wide
queries and actions. SmalltalkImage contains a global environment, an
instance of SystemDictionary, which the environment used by classes.
Thus, SmalltalkImage current == Smalltalk, Object environment ==
Smalltalk globals.

Modularity
----------
The following packages have been made reloadable: ReleaseBuilder,
ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader, SMBase,
Installer-Core, VersionNumberTests, VersionNumber, Services-Base,
PreferenceBrowser, Nebraska, CollectionsTests, GraphicsTests,
KernelTests, MorphicTests, MultilingualTests, NetworkTests, ToolsTests,
TraitsTests, XML-Parser, Traits, SystemChangeNotification-Tests,
FlexibleVocabularies, EToys, Protocols, Tests, SUnitGUI. To unload all
of these, execute:

        Smalltalk unloadAllKnownPackages.

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.1 release candidate 2

Ian Trudel-2
2010/4/4 Andreas Raab <[hidden email]>:
>
> (Ian, if you could build an updated installer I'd appreciate that)

Yes, I will. It may be in few days because I wanted to complete some
features at user level but time forbade. I'll write again when it's
done.

Ian.
--
http://mecenia.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.1 release candidate 2

Chris Muller-3
In reply to this post by Andreas.Raab
> And of course, please keep testing. Load your packages, run them, make sure
> they work!

I worked on this today and, other than the minor IDE issues,
everything is looking good.  Maui seems to be considerably faster than
on 3.9 which is very nice...

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.1 release candidate 2

Juan Vuletich-4
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> Folks -
>
> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>
>   http://ftp.squeak.org/trunk/4.1rc2/
>
> ...

Is there some way to take a 4.0 image and update it to 4.1?

Thanks,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Edgar from the Ostracism Re: [squeak-dev] Squeak 4.1 release candidate 2

Edgar De Cleene



On 4/5/10 5:08 PM, "Juan Vuletich" <[hidden email]> wrote:

> Andreas Raab wrote:
>> Folks -
>>
>> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>>
>>   http://ftp.squeak.org/trunk/4.1rc2/
>>
>> ...
>
> Is there some way to take a 4.0 image and update it to 4.1?
>
> Thanks,
> Juan Vuletich

Andreas , Juan and all Squeakers.

I consider myself in Ostracism, so no mails and no discuss.

If people do not like warnings about broken code or different ways of doing,
no point in bother you.

But.

If I send mail here is about Squeak is more as one of us as individuals and
more as the new SOB.

I send some mails private about I was nominated Release Manager and several
concerns I have.

Repeat , I wish do the release.

The sources scheme is wrong.

IMHO

Let 4.0 have 4.0.1 and feed 4.0.1 with all initial steps before Closures and
freeze image here.
4.0 ends in 7159 .Say the step when Closures comes is 7200.
At this points , the life of 4.0.1 ends and new sources and empty changes
must be done.

Again I beg let 4.1 have dual way of updates.
Plain old real .cs in his updates folder as others forks like Cuis have.
Monticello via fake .cs as 3.10 or like the new trunk procedure.

May I do the release? Or must stick to my fork ?

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Andreas.Raab
Hi Edgar -

On 4/5/2010 2:11 PM, Edgar J. De Cleene wrote:
> I consider myself in Ostracism, so no mails and no discuss.

Sorry, I've never heard the term, can you explain what it means?

> If people do not like warnings about broken code or different ways of doing,
> no point in bother you.

I don't think that's true. As far as I can tell reports about broken
code generally have been responded to quickly and directly. Now is a
particularly good time report any issues because we're trying to get 4.1
done, so if you have any issues please report them!

> If I send mail here is about Squeak is more as one of us as individuals and
> more as the new SOB.
>
> I send some mails private about I was nominated Release Manager and several
> concerns I have.
>
> Repeat , I wish do the release.

I'm not sure how to respond to this without upsetting you but I'll try.

First of all, thank you for offering your help. I really do appreciate
it. However, the commitment to be a release manager comes with some
responsibilities, namely goals, milestones, and schedules. For 4.0 the
goal was relicensing, for 4.1 it is to push out all the changes that
happened during relicensing. The goals for 4.2 haven't been decided yet
but there is a great opportunity right after 4.1 goes out to bring up
some interesting ideas.

Unfortunately, after you announced your interest in being release
manager nothing visible happened. Several weeks passed during which I
had expected you to show some activity to move the next release forward
- be that gathering a release team, or coming up with a set of tasks
that need to be done, or providing even a rough time line. None of that
happened.

I think that the lack of any visible progress was partly what led to the
enthusiastic response of making a short, time-boxed 4.1 release instead
of dragging on in an unclear time frame with unclear goals. I wrote my
4.1 schedule proposal partly as an example for others to understand that
a release needs goals, milestones, and schedules. In this very message I
also asked you whether you'd like to manage the release under those
circumstances and with such a short time line. That was 18 days ago.

As I'm sure you can imagine, it's impossible to make a release in four
weeks if three of them are spent with waiting on an individual's
response to the question of whether they'd like to manage the release.
My expectation had been that if you wanted to manage that release you
would come back within less than a week to clarify your position (even
if that were only by disagreeing with the proposal). I understood your
silence to be an expression of disinterest, and consequently started to
move things forward.

Given how far ahead we are on the release track to 4.1 I think it's
unwise to change the process in the middle. Assuming all goes as
planned, we're two weeks away from 4.1 final and I think we should move
on with the release as planned. Of course, your help in the release
process is welcome.

One thing that would be really helpful is if you could formulate more of
the goals you have with managing a release. I think you're trying to do
a few things differently, but so far you haven't really told the
community what you're planning to do and why. It would be good if you
could formulate what you're trying to achieve.

In short, my take is that we should move 4.1 forward as planned with the
goal to release it in about two weeks. Your help in this process is very
welcome, there are plenty of tasks to help with, for example testing
SqueakLight or any of your other projects with 4.1 and reporting back
any issues. For 4.2 the discussion is wide open, and I'd encourage you
to formulate which changes you'd like to see take place.

> Let 4.0 have 4.0.1 and feed 4.0.1 with all initial steps before Closures and
> freeze image here.

What we can do easily is to provide an update that puts you onto the
"trunk path" so that anyone updating from 4.0 gets all the necessary
stuff to load updates from the trunk. The process itself will not be
free of some manual labor but we can simplify it by adding those few
bits initially. Is that what you're asking for?

> 4.0 ends in 7159 .Say the step when Closures comes is 7200.
> At this points , the life of 4.0.1 ends and new sources and empty changes
> must be done.
>
> Again I beg let 4.1 have dual way of updates.
> Plain old real .cs in his updates folder as others forks like Cuis have.

I don't understand the value of providing change sets separately. Given
that all the changes come in via Monticello why is using a change set an
advantage? Monticello may not be perfect but in particular when merging
distant ancestors Monticello is far superior than change sets.

Is there perhaps some other issue that you haven't mentioned and where
you see change sets as a possible solution? If so, could you elaborate
on that problem? There's a good chance that we may be able to come up
with a solution to that problem that doesn't involve producing change
sets from Monticello.

> May I do the release? Or must stick to my fork ?

These aren't your only options. You can contribute to the current
release, and you can start the discussion about the next one. There
isn't only black and white there are many shades of gray to choose from :-)

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.1 release candidate 2

Andreas.Raab
In reply to this post by Juan Vuletich-4
On 4/5/2010 1:08 PM, Juan Vuletich wrote:
> Is there some way to take a 4.0 image and update it to 4.1?

Absolutely. Download 4.0, file in the attached change set (which is what
I'd be proposing as the "final" 4.0/3.10 update) and update.

Do note that there are a few places where you need to explicitly resolve
merge conflicts, so it's not entirely automatic. Also, I've found that
depending on one's luck you may run into an issue with
Number>>readFrom:ifFail: - if that happens to you simply implement
readFrom:ifFail: as "^self readFrom:" and proceed.

If you're updating a custom image you may have more merge conflicts but
the process should work there too (it did for me in several images I
used it on for testing).

Cheers,
   - Andreas



PrepareFor311Updates.cs (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Edgar De Cleene
In reply to this post by Andreas.Raab



On 4/6/10 12:11 AM, "Andreas Raab" <[hidden email]> wrote:

> Sorry, I've never heard the term, can you explain what it means?
http://en.wikipedia.org/wiki/Ostracism
It's a nice and instructive reading, clarify my old school teachings about
Greek Athenian democracy <http://en.wikipedia.org/wiki/Athenian_democracy>.
Now Squeak have some similar IMHO
> First of all, thank you for offering your help. I really do appreciate
> it. However, the commitment to be a release manager comes with some
> responsibilities, namely goals, milestones, and schedules.

Maybe is just me, but I see all trunk as Andreas game and nobody have the
guts for say no plans, no coordination and one day we play soccer and the
next rugby.

If the name of the game is soccer , can't touch the ball with my hands :=)

Al andar se hace camino, se hace camino al andar

>For 4.0 the  goal was relicensing, for 4.1 it is to push out all the changes
that happened during relicensing.

No argue here.
We have wider audience now so it's time to care about quality.

>The goals for 4.2 haven't been decided yet
> but there is a great opportunity right after 4.1 goes out to bring up
> some interesting ideas.

I like having a .image having the best of Pharo, Squeak , Cuis and
SqueakLight.
The default image should be SqueakCore as we know today.
All packages not in Core should go to squeaksource and have one or more
Squeakers as maintainers or die.
All load of out of image packages should be via Monticello.
No loaders by default.
Any pick Gofer or Installer if need from his last version somewhere and grow
until his/her needs.

> Unfortunately, after you announced your interest in being release
> manager nothing visible happened. Several weeks passed during which I
> had expected you to show some activity to move the next release forward
> - be that gathering a release team, or coming up with a set of tasks
> that need to be done, or providing even a rough time line. None of that
> happened.

Not true and you know is not true.
If you revert your previous decision and do not want I do nothing is a
different story.
And maybe you right in play your own game as Juan play his game in Cuis and
others play the Pharo game.

Squeak have a sad historic precedent in 3.3.
I know only some about , but seems Henrik Gedenryd was ahead of his time,
Unlucky us,  he passed away, unfortunately all too young.

Squeak need SOB word about the release process.
And Squeak is not only for 42 persons who understand each only some parts of
the system each (except you).

We have wider audience now, tell loud once more time.
And we want any could made Squeak his/her home.
Meaning all should be as easier and consistent as possible.

Edgar






Reply | Threaded
Open this post in threaded view
|

Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Juan Vuletich-4
In reply to this post by Andreas.Raab
Hi folks,

Andreas Raab wrote:
> Hi Edgar -
>
> On 4/5/2010 2:11 PM, Edgar J. De Cleene wrote:
>> I consider myself in Ostracism, so no mails and no discuss.
>
> Sorry, I've never heard the term, can you explain what it means?

See http://en.wikipedia.org/wiki/Ostracism . In ancient Greece when a
political dispute was somehow resolved, the part that lost was required
to leave in exile for ten years, to avoid further confrontation, and let
the winning project be executed without hurdles. This is how Edgar feels
right now.

However, I don't think this is happening here at all. What I believe is
happening is that Edgar has a clear vision on how the release process
and released artifacts should be; but he fails to communicate it, and we
fail to understand it. So, no real discussion happens, Edgar believes
his proposals are rejected, and many would believe he never stated them
clearly.

This is my attempt to help fill the gap :)

> ... (snip)...
>>
>>
>> Again I beg let 4.1 have dual way of updates.
>> Plain old real .cs in his updates folder as others forks like Cuis have.
>
> I don't understand the value of providing change sets separately.
> Given that all the changes come in via Monticello why is using a
> change set an advantage? Monticello may not be perfect but in
> particular when merging distant ancestors Monticello is far superior
> than change sets.

Edgar is not advocating the use of change sets for building the release.
He is asking for the automatic generation of change sets from MC, as
another form of the release. I see two good uses for that. One is for
somebody updating from the previous release and wanting to study in
detail the changes that were made, perhaps for cherry picking. The other
use is to help other forks (yes, like Cuis :) ) to follow what's going
on, and integrate as appropriate.

>
> Is there perhaps some other issue that you haven't mentioned and where
> you see change sets as a possible solution? If so, could you elaborate
> on that problem? There's a good chance that we may be able to come up
> with a solution to that problem that doesn't involve producing change
> sets from Monticello.

Does that mean that producing change sets from MC is difficult or a bad
thing?

>
>> May I do the release? Or must stick to my fork ?
>
> These aren't your only options. You can contribute to the current
> release, and you can start the discussion about the next one. There
> isn't only black and white there are many shades of gray to choose
> from :-)
>
> Cheers,
>   - Andreas

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.1 release candidate 2

Juan Vuletich-4
In reply to this post by Andreas.Raab
Andreas Raab wrote:

> On 4/5/2010 1:08 PM, Juan Vuletich wrote:
>> Is there some way to take a 4.0 image and update it to 4.1?
>
> Absolutely. Download 4.0, file in the attached change set (which is
> what I'd be proposing as the "final" 4.0/3.10 update) and update.
>
> Do note that there are a few places where you need to explicitly
> resolve merge conflicts, so it's not entirely automatic. Also, I've
> found that depending on one's luck you may run into an issue with
> Number>>readFrom:ifFail: - if that happens to you simply implement
> readFrom:ifFail: as "^self readFrom:" and proceed.
>
> If you're updating a custom image you may have more merge conflicts
> but the process should work there too (it did for me in several images
> I used it on for testing).
>
> Cheers,
>   - Andreas

Thank you.

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Edgar De Cleene
In reply to this post by Juan Vuletich-4



On 4/6/10 9:04 AM, "Juan Vuletich" <[hidden email]> wrote:

> Edgar is not advocating the use of change sets for building the release.
> He is asking for the automatic generation of change sets from MC, as
> another form of the release. I see two good uses for that. One is for
> somebody updating from the previous release and wanting to study in
> detail the changes that were made, perhaps for cherry picking. The other
> use is to help other forks (yes, like Cuis :) ) to follow what's going
> on, and integrate as appropriate.

Thanks, is almost the point.
You can made real .cs coming from trunk and put this real .cs on the updates
folder.
This works until 3.8 and do not hurt any.
In fact , maybe this is used in Etoys 4.0

And I tell some times this .cs do not load or show some Monticello hide.
The other gain is many, many Squeakers was very comfortable with old plain
.cs and not with Monticello.
If we open the doors, we could have more qualified help.
And yes, is some work for any taking the Release job.

> Does that mean that producing change sets from MC is difficult
No, I solved this some time ago and send the .cs to Andreas.
In particular about the frontier, boundary, you named of some code belongs
to 4.0 (No Closures) and some code belongs to 4.1 (Closures).

And do not say we do not talk about this...

Edgar




Reply | Threaded
Open this post in threaded view
|

Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Andreas.Raab
In reply to this post by Juan Vuletich-4
On 4/6/2010 5:04 AM, Juan Vuletich wrote:
> However, I don't think this is happening here at all. What I believe is
> happening is that Edgar has a clear vision on how the release process
> and released artifacts should be; but he fails to communicate it, and we
> fail to understand it. So, no real discussion happens, Edgar believes
> his proposals are rejected, and many would believe he never stated them
> clearly.
>
> This is my attempt to help fill the gap :)

Thanks for your help. I am plainly in the camp that thinks Edgar has
never stated his ideas very clearly.

>>> Again I beg let 4.1 have dual way of updates.
>>> Plain old real .cs in his updates folder as others forks like Cuis have.
>>
>> I don't understand the value of providing change sets separately.
>> Given that all the changes come in via Monticello why is using a
>> change set an advantage? Monticello may not be perfect but in
>> particular when merging distant ancestors Monticello is far superior
>> than change sets.
>
> Edgar is not advocating the use of change sets for building the release.
> He is asking for the automatic generation of change sets from MC, as
> another form of the release. I see two good uses for that. One is for
> somebody updating from the previous release and wanting to study in
> detail the changes that were made, perhaps for cherry picking. The other
> use is to help other forks (yes, like Cuis :) ) to follow what's going
> on, and integrate as appropriate.

What I really don't understand here is why you think that it's easier to
do that with change sets rather than Monticello. I've merged lots of
systems and before Monticello this was an insanely painful process. I
found that with Monticello this became almost reasonable; still
difficult but no longer outright insane.

>> Is there perhaps some other issue that you haven't mentioned and where
>> you see change sets as a possible solution? If so, could you elaborate
>> on that problem? There's a good chance that we may be able to come up
>> with a solution to that problem that doesn't involve producing change
>> sets from Monticello.
>
> Does that mean that producing change sets from MC is difficult or a bad
> thing?

Neither. It's just work and unfortunately none of us has much spare
time. So I was wondering if there's perhaps something else you're trying
to do that could be achieved more directly without going through change
sets.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Josh Gargus
In reply to this post by Edgar De Cleene
Hi Edgar,

On Apr 6, 2010, at 4:50 AM, Edgar J. De Cleene wrote:
> The default image should be SqueakCore as we know today.

I'm looking at the SL3dot11-9579-alpha.image... is this what you mean by SqueakCore?  I'll assume so.

I'm still don't understand what you're trying to achieve, so please help me to understand...


> All packages not in Core should go to squeaksource and have one or more
> Squeakers as maintainers or die.

We have that already... anything not in trunk needs to be maintained externally or die.  Is the issue which packages should be included in Core?

When I glance at SqueakCore side-by-side with 4.1rc2, they look mostly the same.  There are some packages removed (Nebraska, SqueakMap, Tests, PreferenceBrowser, ScriptLoader, Etoys, Services, Universes, XML-Parser).

There are also some packages that are left in that maybe should be removed (MorphicExtras, ShoutCore), and even one added (Comanche).

My point is that saying "look at SqueakCore" is not a useful answer to the question "what should release 4.2 look like?".  I don't know what it means.  It doesn't explain why you made the decisions that you did, what's not finished, etc.  Why remove XML-Parser but add Comanche?  How was the decision made?  These are questions that I don't know the answer to, and cannot possibly figure out by looking at the image.  Hearing that "the default image should be SqueakCore as we know today" doesn't answer the question for me.


> All load of out of image packages should be via Monticello.
> No loaders by default.

Are you saying that we shouldn't include Gofer or Installer by default?  I don't have an opinion one way or the other.  I see that you do have an opinion, but I don't know your reasons.  Can you explain why?


> Squeak need SOB word about the release process.
> And Squeak is not only for 42 persons who understand each only some parts of
> the system each (except you).

What does this mean?  In what way is SqueakCore better for everybody that 4.1rc2 is not?  They look almost identical to me. You feel very strongly about something, but I don't know what it is.  The current situation is unsatisfactory to you, and you point at the SqueakCore image to show how things could be better.  However, when I look at SqueakCore I don't see the difference that you seem to think should be obvious.  Can you try to explain yourself more slowly and clearly, so that I can understand?


> We have wider audience now, tell loud once more time.
> And we want any could made Squeak his/her home.
> Meaning all should be as easier and consistent as possible.

Please, what are some concrete examples of how SqueakCore is easier and more consistent than 4.1?  Even better would be some general principles that we could follow to improve either SqueakCore or 4.1.

Cheers,
Josh




>
> Edgar
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Edgar from the Ostracism Re: Squeak 4.1 release candidate 2

Juan Vuletich-4
In reply to this post by Andreas.Raab
Andreas Raab wrote:

> On 4/6/2010 5:04 AM, Juan Vuletich wrote:
>> However, I don't think this is happening here at all. What I believe is
>> happening is that Edgar has a clear vision on how the release process
>> and released artifacts should be; but he fails to communicate it, and we
>> fail to understand it. So, no real discussion happens, Edgar believes
>> his proposals are rejected, and many would believe he never stated them
>> clearly.
>>
>> This is my attempt to help fill the gap :)
>
> Thanks for your help. I am plainly in the camp that thinks Edgar has
> never stated his ideas very clearly.

So, Edgar, please take more time to write your messages. Perhaps get
some of your SqueakRos friends to check and discuss them before sending.

>>>> Again I beg let 4.1 have dual way of updates.
>>>> Plain old real .cs in his updates folder as others forks like Cuis
>>>> have.
>>>
>>> I don't understand the value of providing change sets separately.
>>> Given that all the changes come in via Monticello why is using a
>>> change set an advantage? Monticello may not be perfect but in
>>> particular when merging distant ancestors Monticello is far superior
>>> than change sets.
>>
>> Edgar is not advocating the use of change sets for building the release.
>> He is asking for the automatic generation of change sets from MC, as
>> another form of the release. I see two good uses for that. One is for
>> somebody updating from the previous release and wanting to study in
>> detail the changes that were made, perhaps for cherry picking. The other
>> use is to help other forks (yes, like Cuis :) ) to follow what's going
>> on, and integrate as appropriate.
>
> What I really don't understand here is why you think that it's easier
> to do that with change sets rather than Monticello. I've merged lots
> of systems and before Monticello this was an insanely painful process.
> I found that with Monticello this became almost reasonable; still
> difficult but no longer outright insane.

Now I'm speaking just for myself. Cuis doesn't include Monticello. My
experience with Monticello has been different. I chose not to include
it. I can go in more detail, but you know Monticello's strengths and
weaknesses as well as I do. So, to integrate stuff from Squeak, I need
to create some change sets. That task could be automated and save a
little time.

>>> Is there perhaps some other issue that you haven't mentioned and where
>>> you see change sets as a possible solution? If so, could you elaborate
>>> on that problem? There's a good chance that we may be able to come up
>>> with a solution to that problem that doesn't involve producing change
>>> sets from Monticello.
>>
>> Does that mean that producing change sets from MC is difficult or a bad
>> thing?
>
> Neither. It's just work and unfortunately none of us has much spare
> time. So I was wondering if there's perhaps something else you're
> trying to do that could be achieved more directly without going
> through change sets.
>
> Cheers,
>   - Andreas

Not me.

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.1 release candidate 2

Karl Ramberg
In reply to this post by Andreas.Raab
On Mon, Apr 5, 2010 at 12:12 AM, Andreas Raab <[hidden email]> wrote:

> Folks -
>
> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>
>  http://ftp.squeak.org/trunk/4.1rc2/
>
> If you look at the release schedule [1] you'll notice that we're slipping a
> little (which I had expected). The new release candidate includes the
> following changes:
>
> * Condensed sources file. As previously mentioned, the new sources file is a
> strict superset of the 4.0 sources file and preserves version history
> between 4.1 and 4.0.
>
> * Welcome notice(s). Please review in particular the welcome screen. I've
> attached the welcome note below for review and improvement. If you see
> anything that hasn't been mentioned but should, please let me know. I've
> also revived two workspaces that I found useful in the past, one about some
> of the less common UI elements and one about how to work with Squeak.
>
> * An updated Windows VM (4.0.2) which fixes various issues with 4.0.1.
>
> (Ian, if you could build an updated installer I'd appreciate that)
>
> As it stands, we're currently missing updated Unix and Mac VMs (I know Ian
> has been working on it, so I'll ping him and John separately), we still
> don't have all tests green, and there are still a few open issues on Mantis
> [2].
>
> If you can offer any help on any of these issues, you're extremely welcome.
> I'm still hopeful that we can ship 4.1 with minimal delay but in order to do
> that we need to address the pending issues, in particular the failing tests.
>
> And of course, please keep testing. Load your packages, run them, make sure
> they work!
>
> Cheers,
>  - Andreas
>
> [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.html
> [2]http://bugs.squeak.org/view.php?id=7480
>
> =======================================================================
>
>        Welcome to Squeak - a free, open Smalltalk system.
>
> Squeak 4.1 combines the license change occuring in the 4.0 release with the
> development work that has been going on while the relicensing process took
> place. Here are the highlights of the changes that resulted in Squeak 4.1:
>
> User Interface
> --------------
> We have adapted the 'face lift' look originally developed for Newspeak. For
> those of us who like colored windows (quite a few as it turns out) you can
> switch between uniform and colored windows in the 'Extras' menu under
> 'Window Colors'.
>
> The new menu bar makes Squeak much easier to discover than before. The
> process of transitioning from the world menu is not complete yet, there are
> still items that can only be accessed from the world menu (i.e., by clicking
> on the desktop).
>
> The search field integrated in the menu bar allows for direct navigation to
> classes and methods - simply type in a partial class or method name and see
> what happens.
>
> A new set of inexpensive sub-pixel antialiased fonts derived from the DejaVu
> fonts ('Bitmap DejaVu' in the font chooser) has been added. True type font
> support has been upgraded to operate directly on files on disk without the
> need to load the entire file into memory.
>
> A new set of text editors has been added, allowing to decouple the Morphic
> and MVC implementations for improved modularity. Morphic has now regular
> blinking insertion point cursors instead of the (virtually invisible) static
> cursor previously.
>
> Compiler
> --------
> Squeak 4.1 includes the closure implementation from Cog as a prerequisite
> for full Cog adoption later. With this implementation Squeak finally has
> 'full' closures, allowing classic recursive examples like the following to
> work:
>
>        fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
>        fac value: 5.
>
> Support for literal ByteArray syntax has been added. Byte arrays can now be
> written as #[1 2 3] instead of #(1 2 3) asByteArray  avoiding the need for
> conversion.
>
> Selectors including minus are now parsed correctly, for example 3 <- 4 is
> now parsed as (3) <- (4) instead of (3) < (-4). White space is no longer
> allowed after an unary minus to denote a negative number literal.
>
> Development
> -----------
> Syntax highlighting, based on Shout, is now included in all Squeak tools by
> default. For workspaces, it can be explicitly disabled in the window menu
> (entry 'syntax highlighting').
>
> Sources and changes files are no longer limited to 32MB max size.
> ExpandedSourceFileArray provides an implementation for source files of
> arbitrary length, based on the CompiledMethodTrailer changes.
>
> MessageTrace has been added, allowing senders and implementors to be viewed
> without opening new windows all the time.  It utilizes a new
> AlternatePluggableListMorphOfMany, which allows quick and easy customization
> of the list. A quick adoption of DependencyBrowser has been added allowing
> to browse dependencies between packages.
>
> Core Libraries
> --------------
> Sets can now store nil just as any other collection. The collection hierachy
> has been refactored to have both Set and Dictionary a subclass of
> HashedCollection instead of having Dictionary a subclass of Set. Squeak now
> uses a better distributed scaledIdentityHash for identity sets and
> dictionaries.
>
> StandardFilestream now performs read-buffering, dramatically speading up
> some operations like "Object compileAll" (2x improvement) as well as various
> other operations (scanning change lists etc).
>
> A new traits implementation has been added. The implementation is
> significantly smaller and simpler than the old version and can be unloaded
> and reloaded without loss of information (i.e., traits flattened during
> unload are restored during traits reloading).
>
> A new extensible number parser hierharchy has been introduced NumberParser
> and its subclasses provide support for parsing and building numbers from
> strings and streams.
>
> A new general cleanup protocol has been added. The cleanUp protocol takes an
> optional argument to indicate whether we're doing an aggressive cleanup
> (which involves deleting projects, change sets, and possibly other
> destructive actions) or a more gentle cleanup that's only supposed to clean
> out transient caches.
>
> SystemDictionary and SmalltalkImage have been refactored. Smalltalk is now
> an instance of SmalltalkImage, representing a facade for system-wide queries
> and actions. SmalltalkImage contains a global environment, an instance of
> SystemDictionary, which the environment used by classes. Thus,
> SmalltalkImage current == Smalltalk, Object environment == Smalltalk
> globals.
>
> Modularity
> ----------
> The following packages have been made reloadable: ReleaseBuilder,
> ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader, SMBase,
> Installer-Core, VersionNumberTests, VersionNumber, Services-Base,
> PreferenceBrowser, Nebraska, CollectionsTests, GraphicsTests, KernelTests,
> MorphicTests, MultilingualTests, NetworkTests, ToolsTests, TraitsTests,
> XML-Parser, Traits, SystemChangeNotification-Tests, FlexibleVocabularies,
> EToys, Protocols, Tests, SUnitGUI. To unload all of these, execute:
>
>        Smalltalk unloadAllKnownPackages.
>
>

just judging from this text:
lots of references to outside stuff here but i don't see any links to
more info about Newspeak, shout etc.

Karl

Reply | Threaded
Open this post in threaded view
|

Corrupt sources file (was: Re: [squeak-dev] Squeak 4.1 release candidate 2)

Levente Uzonyi-2
In reply to this post by Andreas.Raab
I was about to remove the #expectedFailures from SMDependencyTest, since
it should pass now (but it fails if SqueakMap is not initialized
properly...). As a final check I decided to run the test it in the latest
beta, where it failed. When I tried to browse SMSqueakMap >> #reload to
see how it can be fixed, I got the note about the corrupted sources file,
so I think something went wrong during the latest sources/changes merging.


Levente

On Sun, 4 Apr 2010, Andreas Raab wrote:

> Folks -
>
> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>
>  http://ftp.squeak.org/trunk/4.1rc2/
>
> If you look at the release schedule [1] you'll notice that we're slipping a
> little (which I had expected). The new release candidate includes the
> following changes:
>
> * Condensed sources file. As previously mentioned, the new sources file is a
> strict superset of the 4.0 sources file and preserves version history between
> 4.1 and 4.0.
>
> * Welcome notice(s). Please review in particular the welcome screen. I've
> attached the welcome note below for review and improvement. If you see
> anything that hasn't been mentioned but should, please let me know. I've also
> revived two workspaces that I found useful in the past, one about some of the
> less common UI elements and one about how to work with Squeak.
>
> * An updated Windows VM (4.0.2) which fixes various issues with 4.0.1.
>
> (Ian, if you could build an updated installer I'd appreciate that)
>
> As it stands, we're currently missing updated Unix and Mac VMs (I know Ian
> has been working on it, so I'll ping him and John separately), we still don't
> have all tests green, and there are still a few open issues on Mantis [2].
>
> If you can offer any help on any of these issues, you're extremely welcome.
> I'm still hopeful that we can ship 4.1 with minimal delay but in order to do
> that we need to address the pending issues, in particular the failing tests.
>
> And of course, please keep testing. Load your packages, run them, make sure
> they work!
>
> Cheers,
>  - Andreas
>
> [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.html 
> [2]http://bugs.squeak.org/view.php?id=7480
>
> =======================================================================
>
> Welcome to Squeak - a free, open Smalltalk system.
>
> Squeak 4.1 combines the license change occuring in the 4.0 release with the
> development work that has been going on while the relicensing process took
> place. Here are the highlights of the changes that resulted in Squeak 4.1:
>
> User Interface
> --------------
> We have adapted the 'face lift' look originally developed for Newspeak. For
> those of us who like colored windows (quite a few as it turns out) you can
> switch between uniform and colored windows in the 'Extras' menu under 'Window
> Colors'.
>
> The new menu bar makes Squeak much easier to discover than before. The
> process of transitioning from the world menu is not complete yet, there are
> still items that can only be accessed from the world menu (i.e., by clicking
> on the desktop).
>
> The search field integrated in the menu bar allows for direct navigation to
> classes and methods - simply type in a partial class or method name and see
> what happens.
>
> A new set of inexpensive sub-pixel antialiased fonts derived from the DejaVu
> fonts ('Bitmap DejaVu' in the font chooser) has been added. True type font
> support has been upgraded to operate directly on files on disk without the
> need to load the entire file into memory.
>
> A new set of text editors has been added, allowing to decouple the Morphic
> and MVC implementations for improved modularity. Morphic has now regular
> blinking insertion point cursors instead of the (virtually invisible) static
> cursor previously.
>
> Compiler
> --------
> Squeak 4.1 includes the closure implementation from Cog as a prerequisite for
> full Cog adoption later. With this implementation Squeak finally has 'full'
> closures, allowing classic recursive examples like the following to work:
>
> fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
> fac value: 5.
>
> Support for literal ByteArray syntax has been added. Byte arrays can now be
> written as #[1 2 3] instead of #(1 2 3) asByteArray  avoiding the need for
> conversion.
>
> Selectors including minus are now parsed correctly, for example 3 <- 4 is now
> parsed as (3) <- (4) instead of (3) < (-4). White space is no longer allowed
> after an unary minus to denote a negative number literal.
>
> Development
> -----------
> Syntax highlighting, based on Shout, is now included in all Squeak tools by
> default. For workspaces, it can be explicitly disabled in the window menu
> (entry 'syntax highlighting').
>
> Sources and changes files are no longer limited to 32MB max size.
> ExpandedSourceFileArray provides an implementation for source files of
> arbitrary length, based on the CompiledMethodTrailer changes.
>
> MessageTrace has been added, allowing senders and implementors to be viewed
> without opening new windows all the time.  It utilizes a new
> AlternatePluggableListMorphOfMany, which allows quick and easy customization
> of the list. A quick adoption of DependencyBrowser has been added allowing to
> browse dependencies between packages.
>
> Core Libraries
> --------------
> Sets can now store nil just as any other collection. The collection hierachy
> has been refactored to have both Set and Dictionary a subclass of
> HashedCollection instead of having Dictionary a subclass of Set. Squeak now
> uses a better distributed scaledIdentityHash for identity sets and
> dictionaries.
>
> StandardFilestream now performs read-buffering, dramatically speading up some
> operations like "Object compileAll" (2x improvement) as well as various other
> operations (scanning change lists etc).
>
> A new traits implementation has been added. The implementation is
> significantly smaller and simpler than the old version and can be unloaded
> and reloaded without loss of information (i.e., traits flattened during
> unload are restored during traits reloading).
>
> A new extensible number parser hierharchy has been introduced NumberParser
> and its subclasses provide support for parsing and building numbers from
> strings and streams.
>
> A new general cleanup protocol has been added. The cleanUp protocol takes an
> optional argument to indicate whether we're doing an aggressive cleanup
> (which involves deleting projects, change sets, and possibly other
> destructive actions) or a more gentle cleanup that's only supposed to clean
> out transient caches.
>
> SystemDictionary and SmalltalkImage have been refactored. Smalltalk is now an
> instance of SmalltalkImage, representing a facade for system-wide queries and
> actions. SmalltalkImage contains a global environment, an instance of
> SystemDictionary, which the environment used by classes. Thus, SmalltalkImage
> current == Smalltalk, Object environment == Smalltalk globals.
>
> Modularity
> ----------
> The following packages have been made reloadable: ReleaseBuilder,
> ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader, SMBase,
> Installer-Core, VersionNumberTests, VersionNumber, Services-Base,
> PreferenceBrowser, Nebraska, CollectionsTests, GraphicsTests, KernelTests,
> MorphicTests, MultilingualTests, NetworkTests, ToolsTests, TraitsTests,
> XML-Parser, Traits, SystemChangeNotification-Tests, FlexibleVocabularies,
> EToys, Protocols, Tests, SUnitGUI. To unload all of these, execute:
>
> Smalltalk unloadAllKnownPackages.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Corrupt sources file

Andreas.Raab
On 4/6/2010 4:20 PM, Levente Uzonyi wrote:
> I was about to remove the #expectedFailures from SMDependencyTest, since
> it should pass now (but it fails if SqueakMap is not initialized
> properly...). As a final check I decided to run the test it in the
> latest beta, where it failed. When I tried to browse SMSqueakMap >>
> #reload to see how it can be fixed, I got the note about the corrupted
> sources file, so I think something went wrong during the latest
> sources/changes merging.

Strange ... no problems here. I downloaded

   http://ftp.squeak.org/trunk/4.1rc2/Squeak4.1-9885-beta.zip

from the website to verify and it worked fine.

Any chance that your extraction utility has been "smart" about replacing
CRs with CRLFs or something like that? Can you verify that
SqueakV41.sources is exactly 25,878,239 bytes? Can someone else verify
the problem? (if you do, please include your platform so we know whether
that's a platform issue or not)

Cheers,
   - Andreas

> On Sun, 4 Apr 2010, Andreas Raab wrote:
>
>> Folks -
>>
>> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>>
>> http://ftp.squeak.org/trunk/4.1rc2/
>>
>> If you look at the release schedule [1] you'll notice that we're
>> slipping a little (which I had expected). The new release candidate
>> includes the following changes:
>>
>> * Condensed sources file. As previously mentioned, the new sources
>> file is a strict superset of the 4.0 sources file and preserves
>> version history between 4.1 and 4.0.
>>
>> * Welcome notice(s). Please review in particular the welcome screen.
>> I've attached the welcome note below for review and improvement. If
>> you see anything that hasn't been mentioned but should, please let me
>> know. I've also revived two workspaces that I found useful in the
>> past, one about some of the less common UI elements and one about how
>> to work with Squeak.
>>
>> * An updated Windows VM (4.0.2) which fixes various issues with 4.0.1.
>>
>> (Ian, if you could build an updated installer I'd appreciate that)
>>
>> As it stands, we're currently missing updated Unix and Mac VMs (I know
>> Ian has been working on it, so I'll ping him and John separately), we
>> still don't have all tests green, and there are still a few open
>> issues on Mantis [2].
>>
>> If you can offer any help on any of these issues, you're extremely
>> welcome. I'm still hopeful that we can ship 4.1 with minimal delay but
>> in order to do that we need to address the pending issues, in
>> particular the failing tests.
>>
>> And of course, please keep testing. Load your packages, run them, make
>> sure they work!
>>
>> Cheers,
>> - Andreas
>>
>> [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.html
>> [2]http://bugs.squeak.org/view.php?id=7480
>>
>> =======================================================================
>>
>> Welcome to Squeak - a free, open Smalltalk system.
>>
>> Squeak 4.1 combines the license change occuring in the 4.0 release
>> with the development work that has been going on while the relicensing
>> process took place. Here are the highlights of the changes that
>> resulted in Squeak 4.1:
>>
>> User Interface
>> --------------
>> We have adapted the 'face lift' look originally developed for
>> Newspeak. For those of us who like colored windows (quite a few as it
>> turns out) you can switch between uniform and colored windows in the
>> 'Extras' menu under 'Window Colors'.
>>
>> The new menu bar makes Squeak much easier to discover than before. The
>> process of transitioning from the world menu is not complete yet,
>> there are still items that can only be accessed from the world menu
>> (i.e., by clicking on the desktop).
>>
>> The search field integrated in the menu bar allows for direct
>> navigation to classes and methods - simply type in a partial class or
>> method name and see what happens.
>>
>> A new set of inexpensive sub-pixel antialiased fonts derived from the
>> DejaVu fonts ('Bitmap DejaVu' in the font chooser) has been added.
>> True type font support has been upgraded to operate directly on files
>> on disk without the need to load the entire file into memory.
>>
>> A new set of text editors has been added, allowing to decouple the
>> Morphic and MVC implementations for improved modularity. Morphic has
>> now regular blinking insertion point cursors instead of the (virtually
>> invisible) static cursor previously.
>>
>> Compiler
>> --------
>> Squeak 4.1 includes the closure implementation from Cog as a
>> prerequisite for full Cog adoption later. With this implementation
>> Squeak finally has 'full' closures, allowing classic recursive
>> examples like the following to work:
>>
>> fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
>> fac value: 5.
>>
>> Support for literal ByteArray syntax has been added. Byte arrays can
>> now be written as #[1 2 3] instead of #(1 2 3) asByteArray avoiding
>> the need for conversion.
>>
>> Selectors including minus are now parsed correctly, for example 3 <- 4
>> is now parsed as (3) <- (4) instead of (3) < (-4). White space is no
>> longer allowed after an unary minus to denote a negative number literal.
>>
>> Development
>> -----------
>> Syntax highlighting, based on Shout, is now included in all Squeak
>> tools by default. For workspaces, it can be explicitly disabled in the
>> window menu (entry 'syntax highlighting').
>>
>> Sources and changes files are no longer limited to 32MB max size.
>> ExpandedSourceFileArray provides an implementation for source files of
>> arbitrary length, based on the CompiledMethodTrailer changes.
>>
>> MessageTrace has been added, allowing senders and implementors to be
>> viewed without opening new windows all the time. It utilizes a new
>> AlternatePluggableListMorphOfMany, which allows quick and easy
>> customization of the list. A quick adoption of DependencyBrowser has
>> been added allowing to browse dependencies between packages.
>>
>> Core Libraries
>> --------------
>> Sets can now store nil just as any other collection. The collection
>> hierachy has been refactored to have both Set and Dictionary a
>> subclass of HashedCollection instead of having Dictionary a subclass
>> of Set. Squeak now uses a better distributed scaledIdentityHash for
>> identity sets and dictionaries.
>>
>> StandardFilestream now performs read-buffering, dramatically speading
>> up some operations like "Object compileAll" (2x improvement) as well
>> as various other operations (scanning change lists etc).
>>
>> A new traits implementation has been added. The implementation is
>> significantly smaller and simpler than the old version and can be
>> unloaded and reloaded without loss of information (i.e., traits
>> flattened during unload are restored during traits reloading).
>>
>> A new extensible number parser hierharchy has been introduced
>> NumberParser and its subclasses provide support for parsing and
>> building numbers from strings and streams.
>>
>> A new general cleanup protocol has been added. The cleanUp protocol
>> takes an optional argument to indicate whether we're doing an
>> aggressive cleanup (which involves deleting projects, change sets, and
>> possibly other destructive actions) or a more gentle cleanup that's
>> only supposed to clean out transient caches.
>>
>> SystemDictionary and SmalltalkImage have been refactored. Smalltalk is
>> now an instance of SmalltalkImage, representing a facade for
>> system-wide queries and actions. SmalltalkImage contains a global
>> environment, an instance of SystemDictionary, which the environment
>> used by classes. Thus, SmalltalkImage current == Smalltalk, Object
>> environment == Smalltalk globals.
>>
>> Modularity
>> ----------
>> The following packages have been made reloadable: ReleaseBuilder,
>> ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader,
>> SMBase, Installer-Core, VersionNumberTests, VersionNumber,
>> Services-Base, PreferenceBrowser, Nebraska, CollectionsTests,
>> GraphicsTests, KernelTests, MorphicTests, MultilingualTests,
>> NetworkTests, ToolsTests, TraitsTests, XML-Parser, Traits,
>> SystemChangeNotification-Tests, FlexibleVocabularies, EToys,
>> Protocols, Tests, SUnitGUI. To unload all of these, execute:
>>
>> Smalltalk unloadAllKnownPackages.
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Corrupt sources file

Levente Uzonyi-2
On Tue, 6 Apr 2010, Andreas Raab wrote:

> On 4/6/2010 4:20 PM, Levente Uzonyi wrote:
>> I was about to remove the #expectedFailures from SMDependencyTest, since
>> it should pass now (but it fails if SqueakMap is not initialized
>> properly...). As a final check I decided to run the test it in the
>> latest beta, where it failed. When I tried to browse SMSqueakMap >>
>> #reload to see how it can be fixed, I got the note about the corrupted
>> sources file, so I think something went wrong during the latest
>> sources/changes merging.
>
> Strange ... no problems here. I downloaded
>
>  http://ftp.squeak.org/trunk/4.1rc2/Squeak4.1-9885-beta.zip
>
> from the website to verify and it worked fine.
>
> Any chance that your extraction utility has been "smart" about replacing CRs
> with CRLFs or something like that? Can you verify that SqueakV41.sources is

No.

> exactly 25,878,239 bytes? Can someone else verify the problem? (if you do,

Yes.

> please include your platform so we know whether that's a platform issue or
> not)

I could narrow down the issue a bit: It only happens if the vm is in a
read-only directory (like C:\Program Files\Squeak), otherwise it works as
expected. With with older images, both case works as expected.


Levente

>
> Cheers,
>  - Andreas
>
>> On Sun, 4 Apr 2010, Andreas Raab wrote:
>>
>>> Folks -
>>>
>>> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>>>
>>> http://ftp.squeak.org/trunk/4.1rc2/
>>>
>>> If you look at the release schedule [1] you'll notice that we're
>>> slipping a little (which I had expected). The new release candidate
>>> includes the following changes:
>>>
>>> * Condensed sources file. As previously mentioned, the new sources
>>> file is a strict superset of the 4.0 sources file and preserves
>>> version history between 4.1 and 4.0.
>>>
>>> * Welcome notice(s). Please review in particular the welcome screen.
>>> I've attached the welcome note below for review and improvement. If
>>> you see anything that hasn't been mentioned but should, please let me
>>> know. I've also revived two workspaces that I found useful in the
>>> past, one about some of the less common UI elements and one about how
>>> to work with Squeak.
>>>
>>> * An updated Windows VM (4.0.2) which fixes various issues with 4.0.1.
>>>
>>> (Ian, if you could build an updated installer I'd appreciate that)
>>>
>>> As it stands, we're currently missing updated Unix and Mac VMs (I know
>>> Ian has been working on it, so I'll ping him and John separately), we
>>> still don't have all tests green, and there are still a few open
>>> issues on Mantis [2].
>>>
>>> If you can offer any help on any of these issues, you're extremely
>>> welcome. I'm still hopeful that we can ship 4.1 with minimal delay but
>>> in order to do that we need to address the pending issues, in
>>> particular the failing tests.
>>>
>>> And of course, please keep testing. Load your packages, run them, make
>>> sure they work!
>>>
>>> Cheers,
>>> - Andreas
>>>
>>> [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.html
>>> [2]http://bugs.squeak.org/view.php?id=7480
>>>
>>> =======================================================================
>>>
>>> Welcome to Squeak - a free, open Smalltalk system.
>>>
>>> Squeak 4.1 combines the license change occuring in the 4.0 release
>>> with the development work that has been going on while the relicensing
>>> process took place. Here are the highlights of the changes that
>>> resulted in Squeak 4.1:
>>>
>>> User Interface
>>> --------------
>>> We have adapted the 'face lift' look originally developed for
>>> Newspeak. For those of us who like colored windows (quite a few as it
>>> turns out) you can switch between uniform and colored windows in the
>>> 'Extras' menu under 'Window Colors'.
>>>
>>> The new menu bar makes Squeak much easier to discover than before. The
>>> process of transitioning from the world menu is not complete yet,
>>> there are still items that can only be accessed from the world menu
>>> (i.e., by clicking on the desktop).
>>>
>>> The search field integrated in the menu bar allows for direct
>>> navigation to classes and methods - simply type in a partial class or
>>> method name and see what happens.
>>>
>>> A new set of inexpensive sub-pixel antialiased fonts derived from the
>>> DejaVu fonts ('Bitmap DejaVu' in the font chooser) has been added.
>>> True type font support has been upgraded to operate directly on files
>>> on disk without the need to load the entire file into memory.
>>>
>>> A new set of text editors has been added, allowing to decouple the
>>> Morphic and MVC implementations for improved modularity. Morphic has
>>> now regular blinking insertion point cursors instead of the (virtually
>>> invisible) static cursor previously.
>>>
>>> Compiler
>>> --------
>>> Squeak 4.1 includes the closure implementation from Cog as a
>>> prerequisite for full Cog adoption later. With this implementation
>>> Squeak finally has 'full' closures, allowing classic recursive
>>> examples like the following to work:
>>>
>>> fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
>>> fac value: 5.
>>>
>>> Support for literal ByteArray syntax has been added. Byte arrays can
>>> now be written as #[1 2 3] instead of #(1 2 3) asByteArray avoiding
>>> the need for conversion.
>>>
>>> Selectors including minus are now parsed correctly, for example 3 <- 4
>>> is now parsed as (3) <- (4) instead of (3) < (-4). White space is no
>>> longer allowed after an unary minus to denote a negative number literal.
>>>
>>> Development
>>> -----------
>>> Syntax highlighting, based on Shout, is now included in all Squeak
>>> tools by default. For workspaces, it can be explicitly disabled in the
>>> window menu (entry 'syntax highlighting').
>>>
>>> Sources and changes files are no longer limited to 32MB max size.
>>> ExpandedSourceFileArray provides an implementation for source files of
>>> arbitrary length, based on the CompiledMethodTrailer changes.
>>>
>>> MessageTrace has been added, allowing senders and implementors to be
>>> viewed without opening new windows all the time. It utilizes a new
>>> AlternatePluggableListMorphOfMany, which allows quick and easy
>>> customization of the list. A quick adoption of DependencyBrowser has
>>> been added allowing to browse dependencies between packages.
>>>
>>> Core Libraries
>>> --------------
>>> Sets can now store nil just as any other collection. The collection
>>> hierachy has been refactored to have both Set and Dictionary a
>>> subclass of HashedCollection instead of having Dictionary a subclass
>>> of Set. Squeak now uses a better distributed scaledIdentityHash for
>>> identity sets and dictionaries.
>>>
>>> StandardFilestream now performs read-buffering, dramatically speading
>>> up some operations like "Object compileAll" (2x improvement) as well
>>> as various other operations (scanning change lists etc).
>>>
>>> A new traits implementation has been added. The implementation is
>>> significantly smaller and simpler than the old version and can be
>>> unloaded and reloaded without loss of information (i.e., traits
>>> flattened during unload are restored during traits reloading).
>>>
>>> A new extensible number parser hierharchy has been introduced
>>> NumberParser and its subclasses provide support for parsing and
>>> building numbers from strings and streams.
>>>
>>> A new general cleanup protocol has been added. The cleanUp protocol
>>> takes an optional argument to indicate whether we're doing an
>>> aggressive cleanup (which involves deleting projects, change sets, and
>>> possibly other destructive actions) or a more gentle cleanup that's
>>> only supposed to clean out transient caches.
>>>
>>> SystemDictionary and SmalltalkImage have been refactored. Smalltalk is
>>> now an instance of SmalltalkImage, representing a facade for
>>> system-wide queries and actions. SmalltalkImage contains a global
>>> environment, an instance of SystemDictionary, which the environment
>>> used by classes. Thus, SmalltalkImage current == Smalltalk, Object
>>> environment == Smalltalk globals.
>>>
>>> Modularity
>>> ----------
>>> The following packages have been made reloadable: ReleaseBuilder,
>>> ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader,
>>> SMBase, Installer-Core, VersionNumberTests, VersionNumber,
>>> Services-Base, PreferenceBrowser, Nebraska, CollectionsTests,
>>> GraphicsTests, KernelTests, MorphicTests, MultilingualTests,
>>> NetworkTests, ToolsTests, TraitsTests, XML-Parser, Traits,
>>> SystemChangeNotification-Tests, FlexibleVocabularies, EToys,
>>> Protocols, Tests, SUnitGUI. To unload all of these, execute:
>>>
>>> Smalltalk unloadAllKnownPackages.
>>>
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Corrupt sources file

Levente Uzonyi-2
On Wed, 7 Apr 2010, Levente Uzonyi wrote:

> On Tue, 6 Apr 2010, Andreas Raab wrote:
>
>> On 4/6/2010 4:20 PM, Levente Uzonyi wrote:
>>> I was about to remove the #expectedFailures from SMDependencyTest, since
>>> it should pass now (but it fails if SqueakMap is not initialized
>>> properly...). As a final check I decided to run the test it in the
>>> latest beta, where it failed. When I tried to browse SMSqueakMap >>
>>> #reload to see how it can be fixed, I got the note about the corrupted
>>> sources file, so I think something went wrong during the latest
>>> sources/changes merging.
>>
>> Strange ... no problems here. I downloaded
>>
>>  http://ftp.squeak.org/trunk/4.1rc2/Squeak4.1-9885-beta.zip
>>
>> from the website to verify and it worked fine.
>>
>> Any chance that your extraction utility has been "smart" about replacing
>> CRs with CRLFs or something like that? Can you verify that
>> SqueakV41.sources is
>
> No.
>
>> exactly 25,878,239 bytes? Can someone else verify the problem? (if you do,
>
> Yes.
>
>> please include your platform so we know whether that's a platform issue or
>> not)
>
> I could narrow down the issue a bit: It only happens if the vm is in a
> read-only directory (like C:\Program Files\Squeak), otherwise it works as
> expected. With with older images, both case works as expected.

If I start the vm with administrator rights, then everything is fine.


Levente

>
>
> Levente
>
>>
>> Cheers,
>>  - Andreas
>>
>>> On Sun, 4 Apr 2010, Andreas Raab wrote:
>>>
>>>> Folks -
>>>>
>>>> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>>>>
>>>> http://ftp.squeak.org/trunk/4.1rc2/
>>>>
>>>> If you look at the release schedule [1] you'll notice that we're
>>>> slipping a little (which I had expected). The new release candidate
>>>> includes the following changes:
>>>>
>>>> * Condensed sources file. As previously mentioned, the new sources
>>>> file is a strict superset of the 4.0 sources file and preserves
>>>> version history between 4.1 and 4.0.
>>>>
>>>> * Welcome notice(s). Please review in particular the welcome screen.
>>>> I've attached the welcome note below for review and improvement. If
>>>> you see anything that hasn't been mentioned but should, please let me
>>>> know. I've also revived two workspaces that I found useful in the
>>>> past, one about some of the less common UI elements and one about how
>>>> to work with Squeak.
>>>>
>>>> * An updated Windows VM (4.0.2) which fixes various issues with 4.0.1.
>>>>
>>>> (Ian, if you could build an updated installer I'd appreciate that)
>>>>
>>>> As it stands, we're currently missing updated Unix and Mac VMs (I know
>>>> Ian has been working on it, so I'll ping him and John separately), we
>>>> still don't have all tests green, and there are still a few open
>>>> issues on Mantis [2].
>>>>
>>>> If you can offer any help on any of these issues, you're extremely
>>>> welcome. I'm still hopeful that we can ship 4.1 with minimal delay but
>>>> in order to do that we need to address the pending issues, in
>>>> particular the failing tests.
>>>>
>>>> And of course, please keep testing. Load your packages, run them, make
>>>> sure they work!
>>>>
>>>> Cheers,
>>>> - Andreas
>>>>
>>>> [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.html
>>>> [2]http://bugs.squeak.org/view.php?id=7480
>>>>
>>>> =======================================================================
>>>>
>>>> Welcome to Squeak - a free, open Smalltalk system.
>>>>
>>>> Squeak 4.1 combines the license change occuring in the 4.0 release
>>>> with the development work that has been going on while the relicensing
>>>> process took place. Here are the highlights of the changes that
>>>> resulted in Squeak 4.1:
>>>>
>>>> User Interface
>>>> --------------
>>>> We have adapted the 'face lift' look originally developed for
>>>> Newspeak. For those of us who like colored windows (quite a few as it
>>>> turns out) you can switch between uniform and colored windows in the
>>>> 'Extras' menu under 'Window Colors'.
>>>>
>>>> The new menu bar makes Squeak much easier to discover than before. The
>>>> process of transitioning from the world menu is not complete yet,
>>>> there are still items that can only be accessed from the world menu
>>>> (i.e., by clicking on the desktop).
>>>>
>>>> The search field integrated in the menu bar allows for direct
>>>> navigation to classes and methods - simply type in a partial class or
>>>> method name and see what happens.
>>>>
>>>> A new set of inexpensive sub-pixel antialiased fonts derived from the
>>>> DejaVu fonts ('Bitmap DejaVu' in the font chooser) has been added.
>>>> True type font support has been upgraded to operate directly on files
>>>> on disk without the need to load the entire file into memory.
>>>>
>>>> A new set of text editors has been added, allowing to decouple the
>>>> Morphic and MVC implementations for improved modularity. Morphic has
>>>> now regular blinking insertion point cursors instead of the (virtually
>>>> invisible) static cursor previously.
>>>>
>>>> Compiler
>>>> --------
>>>> Squeak 4.1 includes the closure implementation from Cog as a
>>>> prerequisite for full Cog adoption later. With this implementation
>>>> Squeak finally has 'full' closures, allowing classic recursive
>>>> examples like the following to work:
>>>>
>>>> fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
>>>> fac value: 5.
>>>>
>>>> Support for literal ByteArray syntax has been added. Byte arrays can
>>>> now be written as #[1 2 3] instead of #(1 2 3) asByteArray avoiding
>>>> the need for conversion.
>>>>
>>>> Selectors including minus are now parsed correctly, for example 3 <- 4
>>>> is now parsed as (3) <- (4) instead of (3) < (-4). White space is no
>>>> longer allowed after an unary minus to denote a negative number literal.
>>>>
>>>> Development
>>>> -----------
>>>> Syntax highlighting, based on Shout, is now included in all Squeak
>>>> tools by default. For workspaces, it can be explicitly disabled in the
>>>> window menu (entry 'syntax highlighting').
>>>>
>>>> Sources and changes files are no longer limited to 32MB max size.
>>>> ExpandedSourceFileArray provides an implementation for source files of
>>>> arbitrary length, based on the CompiledMethodTrailer changes.
>>>>
>>>> MessageTrace has been added, allowing senders and implementors to be
>>>> viewed without opening new windows all the time. It utilizes a new
>>>> AlternatePluggableListMorphOfMany, which allows quick and easy
>>>> customization of the list. A quick adoption of DependencyBrowser has
>>>> been added allowing to browse dependencies between packages.
>>>>
>>>> Core Libraries
>>>> --------------
>>>> Sets can now store nil just as any other collection. The collection
>>>> hierachy has been refactored to have both Set and Dictionary a
>>>> subclass of HashedCollection instead of having Dictionary a subclass
>>>> of Set. Squeak now uses a better distributed scaledIdentityHash for
>>>> identity sets and dictionaries.
>>>>
>>>> StandardFilestream now performs read-buffering, dramatically speading
>>>> up some operations like "Object compileAll" (2x improvement) as well
>>>> as various other operations (scanning change lists etc).
>>>>
>>>> A new traits implementation has been added. The implementation is
>>>> significantly smaller and simpler than the old version and can be
>>>> unloaded and reloaded without loss of information (i.e., traits
>>>> flattened during unload are restored during traits reloading).
>>>>
>>>> A new extensible number parser hierharchy has been introduced
>>>> NumberParser and its subclasses provide support for parsing and
>>>> building numbers from strings and streams.
>>>>
>>>> A new general cleanup protocol has been added. The cleanUp protocol
>>>> takes an optional argument to indicate whether we're doing an
>>>> aggressive cleanup (which involves deleting projects, change sets, and
>>>> possibly other destructive actions) or a more gentle cleanup that's
>>>> only supposed to clean out transient caches.
>>>>
>>>> SystemDictionary and SmalltalkImage have been refactored. Smalltalk is
>>>> now an instance of SmalltalkImage, representing a facade for
>>>> system-wide queries and actions. SmalltalkImage contains a global
>>>> environment, an instance of SystemDictionary, which the environment
>>>> used by classes. Thus, SmalltalkImage current == Smalltalk, Object
>>>> environment == Smalltalk globals.
>>>>
>>>> Modularity
>>>> ----------
>>>> The following packages have been made reloadable: ReleaseBuilder,
>>>> ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader,
>>>> SMBase, Installer-Core, VersionNumberTests, VersionNumber,
>>>> Services-Base, PreferenceBrowser, Nebraska, CollectionsTests,
>>>> GraphicsTests, KernelTests, MorphicTests, MultilingualTests,
>>>> NetworkTests, ToolsTests, TraitsTests, XML-Parser, Traits,
>>>> SystemChangeNotification-Tests, FlexibleVocabularies, EToys,
>>>> Protocols, Tests, SUnitGUI. To unload all of these, execute:
>>>>
>>>> Smalltalk unloadAllKnownPackages.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Corrupt sources file

Levente Uzonyi-2
On Wed, 7 Apr 2010, Levente Uzonyi wrote:

> On Wed, 7 Apr 2010, Levente Uzonyi wrote:
>
>> On Tue, 6 Apr 2010, Andreas Raab wrote:
>>
>>> On 4/6/2010 4:20 PM, Levente Uzonyi wrote:
>>>> I was about to remove the #expectedFailures from SMDependencyTest, since
>>>> it should pass now (but it fails if SqueakMap is not initialized
>>>> properly...). As a final check I decided to run the test it in the
>>>> latest beta, where it failed. When I tried to browse SMSqueakMap >>
>>>> #reload to see how it can be fixed, I got the note about the corrupted
>>>> sources file, so I think something went wrong during the latest
>>>> sources/changes merging.
>>>
>>> Strange ... no problems here. I downloaded
>>>
>>>  http://ftp.squeak.org/trunk/4.1rc2/Squeak4.1-9885-beta.zip
>>>
>>> from the website to verify and it worked fine.
>>>
>>> Any chance that your extraction utility has been "smart" about replacing
>>> CRs with CRLFs or something like that? Can you verify that
>>> SqueakV41.sources is
>>
>> No.
>>
>>> exactly 25,878,239 bytes? Can someone else verify the problem? (if you do,
>>
>> Yes.
>>
>>> please include your platform so we know whether that's a platform issue or
>>> not)
>>
>> I could narrow down the issue a bit: It only happens if the vm is in a
>> read-only directory (like C:\Program Files\Squeak), otherwise it works as
>> expected. With with older images, both case works as expected.
>
> If I start the vm with administrator rights, then everything is fine.

It's getting funny. Without administrator rights (vm in program files):
(SourceFiles at: 1) readOnlyCopy next: 100 ==>
'''Copyright (c) The individual, corporate, and institutional contributors who have collectively contr'

Without administrator rights (vm in a writeable directory):
(SourceFiles at: 1) readOnlyCopy next: 100 ==>
'''From Squeak4.1beta of 5 April 2010 [latest update: #9885] on 4 April 2010 at 4:16:30 pm''!
ely contr'

(Note that the above is correct, but wrong, the timestamp overwrote the
license.)

With administrator rights (vm in program files):
(SourceFiles at: 1) readOnlyCopy next: 100 ==>
'''From Squeak4.1beta of 5 April 2010 [latest update: #9885] on 4 April 2010 at 4:16:30 pm''!
ely contr'

In all cases the sources file, the changes file and the image was in a
writeable directory, so this must be some windows trickery.


Levente

>
>
> Levente
>
>>
>>
>> Levente
>>
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>> On Sun, 4 Apr 2010, Andreas Raab wrote:
>>>>
>>>>> Folks -
>>>>>
>>>>> I've prepared rc2 for testing of the 4.1 release on Squeak.org:
>>>>>
>>>>> http://ftp.squeak.org/trunk/4.1rc2/
>>>>>
>>>>> If you look at the release schedule [1] you'll notice that we're
>>>>> slipping a little (which I had expected). The new release candidate
>>>>> includes the following changes:
>>>>>
>>>>> * Condensed sources file. As previously mentioned, the new sources
>>>>> file is a strict superset of the 4.0 sources file and preserves
>>>>> version history between 4.1 and 4.0.
>>>>>
>>>>> * Welcome notice(s). Please review in particular the welcome screen.
>>>>> I've attached the welcome note below for review and improvement. If
>>>>> you see anything that hasn't been mentioned but should, please let me
>>>>> know. I've also revived two workspaces that I found useful in the
>>>>> past, one about some of the less common UI elements and one about how
>>>>> to work with Squeak.
>>>>>
>>>>> * An updated Windows VM (4.0.2) which fixes various issues with 4.0.1.
>>>>>
>>>>> (Ian, if you could build an updated installer I'd appreciate that)
>>>>>
>>>>> As it stands, we're currently missing updated Unix and Mac VMs (I know
>>>>> Ian has been working on it, so I'll ping him and John separately), we
>>>>> still don't have all tests green, and there are still a few open
>>>>> issues on Mantis [2].
>>>>>
>>>>> If you can offer any help on any of these issues, you're extremely
>>>>> welcome. I'm still hopeful that we can ship 4.1 with minimal delay but
>>>>> in order to do that we need to address the pending issues, in
>>>>> particular the failing tests.
>>>>>
>>>>> And of course, please keep testing. Load your packages, run them, make
>>>>> sure they work!
>>>>>
>>>>> Cheers,
>>>>> - Andreas
>>>>>
>>>>> [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.html
>>>>> [2]http://bugs.squeak.org/view.php?id=7480
>>>>>
>>>>> =======================================================================
>>>>>
>>>>> Welcome to Squeak - a free, open Smalltalk system.
>>>>>
>>>>> Squeak 4.1 combines the license change occuring in the 4.0 release
>>>>> with the development work that has been going on while the relicensing
>>>>> process took place. Here are the highlights of the changes that
>>>>> resulted in Squeak 4.1:
>>>>>
>>>>> User Interface
>>>>> --------------
>>>>> We have adapted the 'face lift' look originally developed for
>>>>> Newspeak. For those of us who like colored windows (quite a few as it
>>>>> turns out) you can switch between uniform and colored windows in the
>>>>> 'Extras' menu under 'Window Colors'.
>>>>>
>>>>> The new menu bar makes Squeak much easier to discover than before. The
>>>>> process of transitioning from the world menu is not complete yet,
>>>>> there are still items that can only be accessed from the world menu
>>>>> (i.e., by clicking on the desktop).
>>>>>
>>>>> The search field integrated in the menu bar allows for direct
>>>>> navigation to classes and methods - simply type in a partial class or
>>>>> method name and see what happens.
>>>>>
>>>>> A new set of inexpensive sub-pixel antialiased fonts derived from the
>>>>> DejaVu fonts ('Bitmap DejaVu' in the font chooser) has been added.
>>>>> True type font support has been upgraded to operate directly on files
>>>>> on disk without the need to load the entire file into memory.
>>>>>
>>>>> A new set of text editors has been added, allowing to decouple the
>>>>> Morphic and MVC implementations for improved modularity. Morphic has
>>>>> now regular blinking insertion point cursors instead of the (virtually
>>>>> invisible) static cursor previously.
>>>>>
>>>>> Compiler
>>>>> --------
>>>>> Squeak 4.1 includes the closure implementation from Cog as a
>>>>> prerequisite for full Cog adoption later. With this implementation
>>>>> Squeak finally has 'full' closures, allowing classic recursive
>>>>> examples like the following to work:
>>>>>
>>>>> fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
>>>>> fac value: 5.
>>>>>
>>>>> Support for literal ByteArray syntax has been added. Byte arrays can
>>>>> now be written as #[1 2 3] instead of #(1 2 3) asByteArray avoiding
>>>>> the need for conversion.
>>>>>
>>>>> Selectors including minus are now parsed correctly, for example 3 <- 4
>>>>> is now parsed as (3) <- (4) instead of (3) < (-4). White space is no
>>>>> longer allowed after an unary minus to denote a negative number literal.
>>>>>
>>>>> Development
>>>>> -----------
>>>>> Syntax highlighting, based on Shout, is now included in all Squeak
>>>>> tools by default. For workspaces, it can be explicitly disabled in the
>>>>> window menu (entry 'syntax highlighting').
>>>>>
>>>>> Sources and changes files are no longer limited to 32MB max size.
>>>>> ExpandedSourceFileArray provides an implementation for source files of
>>>>> arbitrary length, based on the CompiledMethodTrailer changes.
>>>>>
>>>>> MessageTrace has been added, allowing senders and implementors to be
>>>>> viewed without opening new windows all the time. It utilizes a new
>>>>> AlternatePluggableListMorphOfMany, which allows quick and easy
>>>>> customization of the list. A quick adoption of DependencyBrowser has
>>>>> been added allowing to browse dependencies between packages.
>>>>>
>>>>> Core Libraries
>>>>> --------------
>>>>> Sets can now store nil just as any other collection. The collection
>>>>> hierachy has been refactored to have both Set and Dictionary a
>>>>> subclass of HashedCollection instead of having Dictionary a subclass
>>>>> of Set. Squeak now uses a better distributed scaledIdentityHash for
>>>>> identity sets and dictionaries.
>>>>>
>>>>> StandardFilestream now performs read-buffering, dramatically speading
>>>>> up some operations like "Object compileAll" (2x improvement) as well
>>>>> as various other operations (scanning change lists etc).
>>>>>
>>>>> A new traits implementation has been added. The implementation is
>>>>> significantly smaller and simpler than the old version and can be
>>>>> unloaded and reloaded without loss of information (i.e., traits
>>>>> flattened during unload are restored during traits reloading).
>>>>>
>>>>> A new extensible number parser hierharchy has been introduced
>>>>> NumberParser and its subclasses provide support for parsing and
>>>>> building numbers from strings and streams.
>>>>>
>>>>> A new general cleanup protocol has been added. The cleanUp protocol
>>>>> takes an optional argument to indicate whether we're doing an
>>>>> aggressive cleanup (which involves deleting projects, change sets, and
>>>>> possibly other destructive actions) or a more gentle cleanup that's
>>>>> only supposed to clean out transient caches.
>>>>>
>>>>> SystemDictionary and SmalltalkImage have been refactored. Smalltalk is
>>>>> now an instance of SmalltalkImage, representing a facade for
>>>>> system-wide queries and actions. SmalltalkImage contains a global
>>>>> environment, an instance of SystemDictionary, which the environment
>>>>> used by classes. Thus, SmalltalkImage current == Smalltalk, Object
>>>>> environment == Smalltalk globals.
>>>>>
>>>>> Modularity
>>>>> ----------
>>>>> The following packages have been made reloadable: ReleaseBuilder,
>>>>> ScriptLoader, 311Deprecated, 39Deprecated, Universes, SMLoader,
>>>>> SMBase, Installer-Core, VersionNumberTests, VersionNumber,
>>>>> Services-Base, PreferenceBrowser, Nebraska, CollectionsTests,
>>>>> GraphicsTests, KernelTests, MorphicTests, MultilingualTests,
>>>>> NetworkTests, ToolsTests, TraitsTests, XML-Parser, Traits,
>>>>> SystemChangeNotification-Tests, FlexibleVocabularies, EToys,
>>>>> Protocols, Tests, SUnitGUI. To unload all of these, execute:
>>>>>
>>>>> Smalltalk unloadAllKnownPackages.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

123