[ANN] Squeak 4.2

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

[ANN] Squeak 4.2

Chris Muller-4
I'd like to call Squeak 4.2 finally officially released now.  I posted
the first maintenance "fix" to the squeak42 repository the other day,
so our process for applying maintenance updates has been tested, in
case we should need any more.  I'm still waiting for final web-site
updates from Janko, but I see no reason to postpone announcing any
longer.

Thanks so much to Levente, Igor, Andreas and many others who
contributed.  Our development process seems to be working, and that
deserves credit for us having ended up with a pretty good release this
time.  It will be nice to have 4.2 behind us in terms of future
development.

Cheers!
  Chris

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Casey Ransberger-2
Congratulations Chris! It's one thing to ship a Smalltalk application... but it's something else entirely to ship Smalltalk:)

I have this weird feeling of de ja vous...

I thought your handling of the release was exquisite, especially with regard to getting the trunk unlocked as soon as it was possible. Much less clumsy than what I did for 4.0 :) and really a lot more work too. Thanks for taking care of the community!



On Feb 11, 2011, at 10:49 AM, Chris Muller <[hidden email]> wrote:

> I'd like to call Squeak 4.2 finally officially released now.  I posted
> the first maintenance "fix" to the squeak42 repository the other day,
> so our process for applying maintenance updates has been tested, in
> case we should need any more.  I'm still waiting for final web-site
> updates from Janko, but I see no reason to postpone announcing any
> longer.
>
> Thanks so much to Levente, Igor, Andreas and many others who
> contributed.  Our development process seems to be working, and that
> deserves credit for us having ended up with a pretty good release this
> time.  It will be nice to have 4.2 behind us in terms of future
> development.
>
> Cheers!
>  Chris
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Levente Uzonyi-2
In reply to this post by Chris Muller-4
On Fri, 11 Feb 2011, Chris Muller wrote:

> I'd like to call Squeak 4.2 finally officially released now.  I posted
> the first maintenance "fix" to the squeak42 repository the other day,
> so our process for applying maintenance updates has been tested, in
> case we should need any more.  I'm still waiting for final web-site
> updates from Janko, but I see no reason to postpone announcing any
> longer.

Great, thanks. I think we shouldn't add too much maintenance fixes. We
should keep the Trunk "release ready" instead. :)

>
> Thanks so much to Levente, Igor, Andreas and many others who
> contributed.  Our development process seems to be working, and that
> deserves credit for us having ended up with a pretty good release this

About the developement process: I think we should clean the Inbox ASAP, to
let future contributions flow in and motivate people to keep contributing.
There's some 8+ months old stuff there which should be merged to the
Trunk. So, I think Core developers should increase their activity and
start merging/discussing Inbox contributions. We should keep it clean
in the future.


Levente

> time.  It will be nice to have 4.2 behind us in terms of future
> development.
>
> Cheers!
>  Chris
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Igor Stasenko
In reply to this post by Chris Muller-4
On 11 February 2011 19:49, Chris Muller <[hidden email]> wrote:

> I'd like to call Squeak 4.2 finally officially released now.  I posted
> the first maintenance "fix" to the squeak42 repository the other day,
> so our process for applying maintenance updates has been tested, in
> case we should need any more.  I'm still waiting for final web-site
> updates from Janko, but I see no reason to postpone announcing any
> longer.
>
> Thanks so much to Levente, Igor, Andreas and many others who
> contributed.  Our development process seems to be working, and that
> deserves credit for us having ended up with a pretty good release this
> time.  It will be nice to have 4.2 behind us in terms of future
> development.
>

Congratulations!
A lot cool things happening these days! :)

> Cheers!
>  Chris
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Chris Muller-3
In reply to this post by Levente Uzonyi-2
> About the developement process: I think we should clean the Inbox ASAP, to
> let future contributions flow in and motivate people to keep contributing.

+1

We should also condense the sources file and remove deprecated
methods.  We're early in the cycle, this is a good time to "break"
code still using 3.9Deprecated methods.


> There's some 8+ months old stuff there which should be merged to the Trunk.
> So, I think Core developers should increase their activity and start
> merging/discussing Inbox contributions. We should keep it clean in the
> future.

I agree about trying to remember to keep on top of it.  Except
"cleanliness" should not be the factor; we should merge to make a
better Squeak, not a cleaner Inbox.  :)



>
> Levente
>
>> time.  It will be nice to have 4.2 behind us in terms of future
>> development.
>>
>> Cheers!
>>  Chris
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Levente Uzonyi-2
On Sat, 12 Feb 2011, Chris Muller wrote:

>> About the developement process: I think we should clean the Inbox ASAP, to
>> let future contributions flow in and motivate people to keep contributing.
>
> +1
>
> We should also condense the sources file and remove deprecated
> methods.  We're early in the cycle, this is a good time to "break"
> code still using 3.9Deprecated methods.

IMHO condensing should be done before the release. It's not possible to
tell a 4.2 image to use a different sources file without changing it.
For 4.3 it doesn't worth condensing now, because we will do further
changes, which would generate cruft in the file (compared to condensing
before the release).

>
>
>> There's some 8+ months old stuff there which should be merged to the Trunk.
>> So, I think Core developers should increase their activity and start
>> merging/discussing Inbox contributions. We should keep it clean in the
>> future.
>
> I agree about trying to remember to keep on top of it.  Except
> "cleanliness" should not be the factor; we should merge to make a
> better Squeak, not a cleaner Inbox.  :)
That's the basic idea, but if the Inbox is not clean enough, then
some people won't use it, just like Mantis. Long pending contributions
discourage contributors. And we need the contributions of non-core
developers, because core developers are not very active nowadays.

I've got the following idea about keeping the Inbox clean:
We define a time limit for keeping a contribution in the Inbox. Something
like 1-2 weeks. If there's no activity about that contribution for this
long, then we open a ticket for it on Mantis and move it to the Treated
Inbox. The ticket would
- contain the name and comment of the mcz
- be attached to the ticket of the next release
so the contribution would remain in our sight.


Levente

>
>
>
>>
>> Levente
>>
>>> time.  It will be nice to have 4.2 behind us in terms of future
>>> development.
>>>
>>> Cheers!
>>>  Chris
>>>
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Chris Muller-3
>> I agree about trying to remember to keep on top of it.  Except
>> "cleanliness" should not be the factor; we should merge to make a
>> better Squeak, not a cleaner Inbox.  :)
>
> That's the basic idea, but if the Inbox is not clean enough, then some
> people won't use it, just like Mantis. Long pending contributions discourage
> contributors. And we need the contributions of non-core developers, because
> core developers are not very active nowadays.
>
> I've got the following idea about keeping the Inbox clean:
> We define a time limit for keeping a contribution in the Inbox. Something
> like 1-2 weeks. If there's no activity about that contribution for this
> long, then we open a ticket for it on Mantis and move it to the Treated
> Inbox. The ticket would
> - contain the name and comment of the mcz
> - be attached to the ticket of the next release
> so the contribution would remain in our sight.

Please don't do that.  The way to clean the Inbox is to push through
the work of reviewing, discussing and either accepting or rejecting.
Simply moving items "out of sight" does not clean the "situation", in
fact it actually makes the situation worse because now we have half of
our unreviewed contributions in the Inbox and half in Mantis.  I just
don't see myself going out to Mantis to review "expired"
contributions.  It's like a black hole, digging something out of there
requires manual effort, vs. simply selecting it right in the image and
diffing it.

I'm just saying, contributors should be able to expect that their
items in the Inbox will be handled based solely on the merits of the
change, not based on time-limits or how many other items are in the
Inbox.  Losing good contributions that people made, who expect the
InBox process to work a certain way; THAT would be a good way to
discourage contributions.  To keep it clean, I think we just gotta do
the work..

Regards,
  Chris

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Levente Uzonyi-2
On Sat, 12 Feb 2011, Chris Muller wrote:

>>> I agree about trying to remember to keep on top of it.  Except
>>> "cleanliness" should not be the factor; we should merge to make a
>>> better Squeak, not a cleaner Inbox.  :)
>>
>> That's the basic idea, but if the Inbox is not clean enough, then some
>> people won't use it, just like Mantis. Long pending contributions discourage
>> contributors. And we need the contributions of non-core developers, because
>> core developers are not very active nowadays.
>>
>> I've got the following idea about keeping the Inbox clean:
>> We define a time limit for keeping a contribution in the Inbox. Something
>> like 1-2 weeks. If there's no activity about that contribution for this
>> long, then we open a ticket for it on Mantis and move it to the Treated
>> Inbox. The ticket would
>> - contain the name and comment of the mcz
>> - be attached to the ticket of the next release
>> so the contribution would remain in our sight.
>
> Please don't do that.  The way to clean the Inbox is to push through
> the work of reviewing, discussing and either accepting or rejecting.
> Simply moving items "out of sight" does not clean the "situation", in
> fact it actually makes the situation worse because now we have half of
> our unreviewed contributions in the Inbox and half in Mantis.  I just
> don't see myself going out to Mantis to review "expired"
> contributions.  It's like a black hole, digging something out of there
> requires manual effort, vs. simply selecting it right in the image and
> diffing it.
I guess the root of the problem is that Mantis is not being used by the
community. During the developement of 4.2 we resolved ~90 Mantis issues.
I hope it will be more for 4.3, because there are 898 not resolved left.

>
> I'm just saying, contributors should be able to expect that their
> items in the Inbox will be handled based solely on the merits of the
> change, not based on time-limits or how many other items are in the
> Inbox.  Losing good contributions that people made, who expect the
> InBox process to work a certain way; THAT would be a good way to

That's right, but this didn't happen for months. My idea is not about the
existing stuff in the Inbox, but future contributions. The time limit
could motivate
- the core developers to review and integrate the contributions
- the contributors to open discussions about their code.


Levente

> discourage contributions.  To keep it clean, I think we just gotta do
> the work..
>
> Regards,
>  Chris
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Edgar De Cleene
In reply to this post by Levente Uzonyi-2



On 2/12/11 9:41 PM, "Levente Uzonyi" <[hidden email]> wrote:

> IMHO condensing should be done before the release. It's not possible to
> tell a 4.2 image to use a different sources file without changing it.
> For 4.3 it doesn't worth condensing now, because we will do further
> changes, which would generate cruft in the file (compared to condensing
> before the release).

What about a 4.2.1 release with the last minute enhancements and new 4.2
sources ?
Some Squeakers don't wish wait several months :=)

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

laza
In reply to this post by Chris Muller-4
2011/2/11 Chris Muller <[hidden email]>
I'd like to call Squeak 4.2 finally officially released now.

The all-in-one package most likely will crash on linux systems at some point because of the UUID bug. Maybe this should be repackaged without the UUID plugin.

Alex

 


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

David T. Lewis
On Tue, Feb 15, 2011 at 11:08:30AM +0100, Alexander Lazarevi?? wrote:
> 2011/2/11 Chris Muller <[hidden email]>
>
> > I'd like to call Squeak 4.2 finally officially released now.
> >
>
> The all-in-one package most likely will crash on linux systems at some point
> because of the UUID bug. Maybe this should be repackaged without the UUID
> plugin.

+1

I think that deleting the UUID plugin (so.UUIDPlugin) for both Cog and
SqueakVM would probably be a good idea for the all-in-one package.

Background on the issue: http://bugs.squeak.org/view.php?id=7358

Dave


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Levente Uzonyi-2
In reply to this post by laza
On Tue, 15 Feb 2011, Alexander Lazarević wrote:

> 2011/2/11 Chris Muller <[hidden email]>
>
>> I'd like to call Squeak 4.2 finally officially released now.
>>
>
> The all-in-one package most likely will crash on linux systems at some point
> because of the UUID bug. Maybe this should be repackaged without the UUID
> plugin.

If you have a VM-OS combination that crashes because of the UUID bug, you
could give this version of the plugin a try:
http://leves.web.elte.hu/squeak/so.UUIDPlugin
Details about the changes in this plugin are available here:
http://bugs.squeak.org/view.php?id=7358#14053


Levente

>
> Alex
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Eliot Miranda-2


2011/2/15 Levente Uzonyi <[hidden email]>
On Tue, 15 Feb 2011, Alexander Lazarević wrote:

2011/2/11 Chris Muller <[hidden email]>

I'd like to call Squeak 4.2 finally officially released now.


The all-in-one package most likely will crash on linux systems at some point
because of the UUID bug. Maybe this should be repackaged without the UUID
plugin.

If you have a VM-OS combination that crashes because of the UUID bug, you could give this version of the plugin a try: http://leves.web.elte.hu/squeak/so.UUIDPlugin
Details about the changes in this plugin are available here: http://bugs.squeak.org/view.php?id=7358#14053

and if you try this with Cog you should also try renaming it to UUIDPlugin.so before concluding that it does or does not work (since Cog might no longer load plugins with a leading so. but definitely does load those with a trailing .so).
 



Levente


Alex






Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

laza
In reply to this post by Levente Uzonyi-2
Levente,

thanks for the workaround. This helps indeed with the crashing UUID plugin.

Find below the system trace of three VM runs and some bare comments starting with #
The test environment is easy to setup even on a windows machine. Get VirtualBox for Windows and an Ubuntu Installer/LiveCD, boot and download the all-in-one package.

Thanks,
 Alex

1) With original external UUID plugin

# look for the plugin
open("/lib/UUIDPlugin", O_RDONLY)       = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/cmov/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/sse2/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/UUIDPlugin", O_RDONLY)   = -1 ENOENT (No such file or directory)
munmap(0x77412000, 59038)               = 0
# found it
open("/home/laza/Desktop/Squeak 4.2 All-in-One.app/Contents/Linux-i686/lib/squeak/4.4.7-2357/so.UUIDPlugin", O_RDONLY) = 7
# load it
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\5\0\0004\0\0\0"..., 512) = 512
fstat64(7, {st_mode=S_IFREG|0644, st_size=3868, ...}) = 0
mmap2(NULL, 6556, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7, 0) = 0xbda000
mmap2(0xbdb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 7, 0) = 0xbdb000
close(7)                                = 0
gettimeofday({1298320504, 96952}, NULL) = 0
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 7
fcntl64(7, F_GETFD)                     = 0
fcntl64(7, F_SETFD, FD_CLOEXEC)         = 0
getuid32()                              = 1000
# BANG
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77da000
# [smalltalk stack trace]
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(3137, 3137, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT (core dumped) +++

2) Witout external UUID plugin

# look for the plugin
open("/lib/UUIDPlugin", O_RDONLY)       = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/cmov/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/sse2/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/UUIDPlugin", O_RDONLY)   = -1 ENOENT (No such file or directory)
munmap(0x77412000, 59038)               = 0
open("/home/laza/Desktop/Squeak 4.2 All-in-One.app/Contents/Linux-i686/lib/squeak/4.4.7-2357/so.UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/laza/Desktop/Squeak 4.2 All-in-One.app/Contents/Linux-i686/lib/squeak/4.4.7-2357/so.UUIDPlugin", 0xbfd4726c) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=59038, ...}) = 0
mmap2(NULL, 59038, PROT_READ, MAP_PRIVATE, 7, 0) = 0x77412000
close(7)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libUUIDPlugin.so", O_RDONLY) = -1 ENOENT (No such file or directory)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
open("/usr/lib/i686/cmov/libUUIDPlugin.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/libUUIDPlugin.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/sse2/libUUIDPlugin.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libUUIDPlugin.so", O_RDONLY) = -1 ENOENT (No such file or directory)
# did not find any plugin
munmap(0x77412000, 59038)               = 0
lstat64("/dev/urandom", {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
open("/dev/urandom", O_RDONLY)          = 7
fstat64(7, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfd48f44) = -1 EINVAL (Invalid argument)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb775b000
fstat64(7, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
# and runs fine

3) With the new plugin

# look for the plugin
open("/lib/UUIDPlugin", O_RDONLY)       = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/cmov/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/sse2/UUIDPlugin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/UUIDPlugin", O_RDONLY)   = -1 ENOENT (No such file or directory)
munmap(0x774e2000, 59038)               = 0
# found it
open("/home/laza/Desktop/Squeak 4.2 All-in-One.app/Contents/Linux-i686/lib/squeak/4.4.7-2357/so.UUIDPlugin", O_RDONLY) = 7
# load it
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\7\0\0004\0\0\0"..., 512) = 512
fstat64(7, {st_mode=S_IFREG|0644, st_size=19595, ...}) = 0
mmap2(NULL, 8448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7, 0) = 0x395000
mmap2(0x396000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 7, 0) = 0x396000
close(7)                                = 0
mprotect(0x396000, 4096, PROT_READ)     = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGSEGV, {0x395af0, [], 0}, {0x8073f20, [SEGV], SA_RESTART}, 8) = 0
gettimeofday({1298321642, 103642}, NULL) = 0
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 7
fcntl64(7, F_GETFD)                     = 0
fcntl64(7, F_SETFD, FD_CLOEXEC)         = 0
getuid32()                              = 1000
# BANG
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
# caught it
rt_sigaction(SIGSEGV, {0x8073f20, [SEGV], SA_RESTART}, NULL, 8) = 0
munmap(0x395000, 8448)                  = 0
lstat64("/dev/urandom", {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
open("/dev/urandom", O_RDONLY)          = 8
fstat64(8, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
# and runs fine



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Squeak 4.2

Levente Uzonyi-2
On Mon, 21 Feb 2011, Alexander Lazarević wrote:

> Levente,
>
> thanks for the workaround. This helps indeed with the crashing UUID plugin.
>
> Find below the system trace of three VM runs and some bare comments starting
> with #
> The test environment is easy to setup even on a windows machine. Get
> VirtualBox for Windows and an Ubuntu Installer/LiveCD, boot and download the
> all-in-one package.

Great, thanks for the feedback. Which Ubuntu version did you use?


Levente

>
> Thanks,
> Alex

snip