Release

release@lists.squeakfoundation.org

59 discussions

Mac release broken? ClassBinding>>objectForDataStream
by Huw Lloyd 03 Dec '15

03 Dec '15

For both 4.6 & 5.0 on the mac, saving a project generates the following error: "NotImplemented: ClassBinding or a superclass should implement objectForDataStream." The comments in the method suggest this shouldn't have been released to a stable version: "It's not yet clear how serialization should work in the presence of environments". Problem 2 is that if I then "abandon" the error messge, the workspace is then flooded with "MessageNotUnderstood" error boxes. Is "environments" something experimental that should be switched off? Best, Huw

1 1

Fork Proposal: Cuis & Killer Apps.
by Overcomer Man 05 Sep '11

05 Sep '11

I suggest a new fork or possibly a new orientation for the next Squeak release: Adopt Cuis as the core image and focus on killer applications to attract new Smalltalk users. Thousands of downloads are recorded on CNet for simple apps like a voice recorder. They could all be using and learning Smalltalk. Same for many other applications. That would help make Smalltalk popular again. Recently I found Squeak / Cuis contains many Sound classes. So I wrote up an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3. Squeak has so much unfinished half starts at programs, why not adopt Juan's work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code. Another example, Roxio is a million dollar software company making a video recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support. Another example, Solid Works is a 3D object drafting program that is simple and gets many thousands of users away from AutoDesk. Can Smalltalk deliver most or all of that function with a FFI to openGL and some programming? Certianly! Finally, the one complaint I've heard on the job about Smalltalk is it's slow. I recently added several thousand classes and find simply clicking on the class in a browser is now slow to respond. When end-users, not programmers, can type at 80 words a minute and more in a C app. or they can be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM was a good improvement, now try to solve the speed issues in the image. Thanks, Kirk Fraser

2 1

I wish retake old good practice
by Edgar J. De Cleene 10 Mar '10

10 Mar '10

Folks; I the past we have the release(a)lists.squeakfoundation.org for discuss about the release process. I friendly invite all wishing discuss plans, give feedback, etc to join the list. In particular , I wish talk about my fork SL3dot11 and how this could be 4.2 SqueakCore. For this I move to http://ftp.squeak.org/Experiments/ all I using now. And pick Experiments because I know my ways is not business as usual. All with deeper Smalltalk, be kind with me. Y recuerden que aca abajo del mundo no nos gusta matar mosquitos con un cañon. Preferimos matar dragones con una gomera. And remember in the Wild South we don¹t like kill mosquitoes with a cannon. We prefer slay dragons with a rubber. Edgar

1 0

[support@nabble.com: Nabble forum scheduled for deletion]
by Matthew Fulmer 08 Nov '09

08 Nov '09

Hmm. nobody is using this list it seems ----- Forwarded message from Nabble <support(a)nabble.com> ----- From: Nabble <support(a)nabble.com> To: tapplek(a)gmail.com Date: Sun, 8 Nov 2009 09:08:26 -0800 (PST) Subject: Nabble forum scheduled for deletion Dear Nabble user: Your forum "Squeak - Release" has been inactive for 120 days, so it has been scheduled for deletion in another 7 days. To prevent this forum from being deleted, you can post a message to the forum or edit the forum. The forum is here: http://old.nabble.com/Squeak---Release-f32847.html If you want to have this forum migrated to the new Nabble2 system, please contact Nabble Support: http://n2.nabble.com/Nabble-Support-f1.html The differences between the old and new systems are described here: http://n2.nabble.com/Differences-between-Nabble1-and-Nabble2-tp3925029p3925… Regards, Nabble Support ----- End forwarded message ----- -- Matthew Fulmer (a.k.a. Tapple)

1 0

Re: [Release] The role of Bob, Installer & Co.
by Andreas Raab 11 Jul '09

11 Jul '09

Keith Hodges wrote: > You really dont get it do you... I think that's pretty obvious by now, isn't it. What I'm trying to do is to enable developers to work together. I can't possibly imagine why anyone would be so violently against that, so clearly I'm not getting the point. I think our main practical difference is that you "abso-bloody-lutely" want people to go through Mantis. Which is okay, you can use Mantis for anything you'd like. But I myself, and other developers who understand the MC workflow, would rather collaborate that way. If Bob can't support workflows that use collaboration through shared MC repositories then it's not suited for the task of image building. And if it does support these workflows, then I don't understand why we're even having this discussion. Cheers, - Andreas

5 44

Re: [Release] Philosophical Discussion - The updates button is useless - discuss
by edgar De Cleene 09 Jul '09

09 Jul '09

--- El jue 9-jul-09, Keith Hodges <keith_hodges(a)yahoo.co.uk> escribió: >> >>Our target audience is not the end users, or even the individual >>programmer, it is the builder of interesting customised images, so they >>would be capable of using a less than single click solution. >>If this is the case then the builder of the customised image will have >>detailed knowledge of how he configured the image he published, and the >>update stream might be useful to him for passing on emergency fixes to >>his own users. >>Keith I think we need more people doing Squeak , not less people. Maybe it's me , but frankly i don't understand why we waste time and do not have nothing useful for another person who not was Keith. I can't wish start again Formula One tales, but now Squeak bacomes like this days Formula One. Because wrong polythics and unclear rules most powerfuls teams like Ferrari, BMW, McLaren , Toyota was behind newcomers less powerful teams. So SOB take actions now. I continue working in the SqueakLightII and MinimalMorphic images. This days i learning a lot from EToys 4.0 and Cuis. Also from John on Ipod related stuff. Claim having the most advanced Squeak and have videos to prove it. Do not claim is suited to all, free of bugs or being good Smalltalk. Tryng to synch with any Andreas decide. Meet me on irc or in Skype as edgardec. Edgar ____________________________________________________________________________________ ¡Viví la mejor experiencia en la web! Descargá gratis el nuevo Internet Explorer 8 http://downloads.yahoo.com/ieak8/?l=ar

2 1

Re: [Release] The role of Bob, Installer & Co.
by Andreas Raab 05 Jul '09

05 Jul '09

Keith Hodges wrote: > Andreas' proposal is to throw every package within the kernel and the > image as a whole out to be treated as an "external package" to be hacked > on by any approved person who fancies a go. Really, the fundamental idea of the proposal to have a shared repository where I can collaborate with other Squeak developers on core packages. > The result can be viewed and used by anyone by publishing to MC and > subscribing via an updates mechanism. Correct. > The image will probably be a bit unstable for a bit, but we cant go to > the extent of breaking it ever, because we are not distibuting a new > image, just updates, everything must continue to work seamlessly. Not necessarily. If there is a need to distribute a new image, we can certainly do that. I'm just not in favor of requiring a new image any time you want to do anything. Keep in mind that in previous messages I've pointed out Bob's role in building images based on the trunk packages. That's useful because people can fetch the latest version for playing with it which is right in line with the idea of reducing hurdles since the need to go through a lengthy update process can be just as bothersome as the need to download a new image every week. In short: Updates and images go hand in hand. Yes, there will be images, and I would like Bob to play a role in building these automatically (say on a weekly basis). > Everything has to be done in small evolutionary steps as required by an > updates mechanism. There is no mechanism for removing things from the > image, or for changing the image structure. You will have to clear out > stale package references, repository references from your image > yourself. All of this can be done automatically. Removals and doIts can be deployed (for example) via package preambles/postscripts and since the MCM update mechanism can be instructed to load precisely those version with the scripts attached to it you can utilize the process in a similar manner as preambles/postscripts in change sets. > Then it is supposedly up to Bob to take these packages as an **input** > putting the image into an unpredictable state. Actually, you start with some base image (like the previous release) which I think we can agree on as being called stable. Then you run the package updater process just like any client would. Not much difference to a SakeTask (which could be produced from the MCM automatically) and it leaves the image in a no more unpredicable state than loading any other code would. > Then Bob is expected to apply some fixes from mantis which were perhaps > submited a year ago and were definitely not targeted at the image in > which bob has to get them to work. Bob then uploads the resulting > packages up to the trunk repo, > Bob is now an automated contributor to the single trunk repository. That's the point where I would hope that Bob can help us to drastically reduce the turnaround times. A fix produced a year ago should not stall for a year in Mantis. If Bob identifies the fix within a week or two, if Bob can prove that the fix doesn't break an existing test and does allow the provided tests to run then there should be little need to wait for a year. The point being that Bob's stamp of approval can help us screen tests that "look ready" much, much faster. > Bob also helps out by running tests in the hope that at some point in 2 > years time, we get to a point where all the enthusiastic contributors to > trunk have calmed down and have arrived at a reasonably stable working > image. At which point a release will be asssembled manually by someone, > probably Andreas, who will manually update the versions number, and > manually ftp the new image up to ftp.squeak.org or publish an mcm for > people to use. Something along those lines, yes. I think that having an ongoing release team would be useful, for example to work out which demos should be included, how the contents is presented, which extra parts (fonts, media, etc) to include and so on. Cheers, - Andreas

2 1

The role of Bob, Installer & Co.
by Andreas Raab 05 Jul '09

05 Jul '09

Folks - I just had a very good (off-list) discussion where it was brought to my attention that one might look at the proposal from the point of view that it replaces Installer, Bob & Co. in situ and that there is no role for these tools in the proposed process. Nothing could be further from the truth. What I am imagining goes along these lines: Consider Bob running daily/weekly builds and then checks if any new fixes have appeared on Mantis. If there is anything new, it loads the fix, runs the tests inside the image, runs the tests attached to the bug. If this works out Bob puts his "stamp of approval" on the fix or commits it directly to the repository. In effect, Bob becomes our main harvester doing all the boring integration stuff that we can reasonably automate. This is actually quite similar to what Bob does today - except that Bob isn't producing an image but rather commits to the trunk. In any case, from my perspective there is a lot of room for Bob and Installer - be that in providing up-to-date images from weekly builds, running automated test suites, and so on. I have no intention to get rid of Bob and Installer. I hope that with Keith's help we can make maximum use of both since these are valuable tools in a successful software development project. Cheers, - Andreas

3 4

3.11 liaison change
by Andreas Raab 03 Jul '09

03 Jul '09

Folks - You might (or might not ;-) have noticed this but due to some internal reshuffling of responsibilities [1] I am now the "official" board liaison for the 3.11 release. Randal remains the contact for 4.0 since it's so intrinsically connected to relicensing but I'm trying to help out since he would otherwise have too many responsibilities all at once. I've been looking at the archives but since there wasn't too much communication I am not sure how I can best help. Please let me know what you'd like help with - I can be anything from coder, to tester, to whip, help communicate, or whatnot. Your choice ;-) I still feel somewhat uncomfortable defining when exactly we would consider 3.11 "done" and how far along we are in that process. I would very much like to try to come to a schedule which we can communicate and work towards so I'd appreciate any help you can provide. Cheers, - Andreas [1]http://squeakboard.wordpress.com/2009/04/03/meeting-report-for-422009/

5 25

02Jul Diary
by Keith Hodges 03 Jul '09

03 Jul '09

Simplifying Sake/Packages so that it is better placed to be the definitive (declarative) database of what works where. Today I have been fixing up Sake/Packages so that it can run Seaside29 package definitions. So now Bob can build Seaside29 images using Sake/Packages (try that in universes) cheers Keith - Plans for this coming week... Get auto testing running Build dev images Finally get around to generating a public build of 3.11

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Release