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 |
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 > |
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 > > |
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. |
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 >> >> > > |
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. :) 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 >>> >>> >> >> > > |
>> 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 |
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. 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 > > |
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 |
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 |
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 |
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 > |
2011/2/15 Levente Uzonyi <[hidden email]> On Tue, 15 Feb 2011, Alexander Lazarević wrote: 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).
|
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 |
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 |
Free forum by Nabble | Edit this page |