Squeak-dev July 2009

squeak-dev@lists.squeakfoundation.org

126 participants
195 discussions

[ANN][Dev-Images] July 2009 versions
by Damien Cassou 06 Jul '09

06 Jul '09

Hi, I've just uploaded new dev and web images based on Squeak3.9.1-7075, Squeak3.10.2-7179 and Pharo0.1-10371. More information and download: http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev Pharo-based images can be downloaded at: http://pharo-project.org/pharo-download Download statistics at http://damiencassou.dabbledb.com/publish/dev-imagesdownloads Changes in this version: --------------------------- - Pharo images are based on version 10371 - New version of OCompletion for Pharo - Lots of bug fixes in Seaside, Pier and Magritte Contained packages: ------------------------ This image contains the following packages (some packages are only in the squeak-web image): Aida version 5.6 Algernon version 1.2 AST version 164 AutomaticMethodCategorizer version 0.25 AutomaticMethodCategorizerOB version 0.2 DynamicBindings version 2.7 eCompletion version 0.102 eCompletion-Traits version 0.1 eCompletionOmniBrowser version 0.5 Installer version 4.3 Installer-Core version 4.3.313 Installer-Formats version 4.3.3 Installer-Scripts version 4.3.8 KomHttpServer version 7.0.45 KomServices version 1.19 Magritte-Model version 1.1.1.349 Magritte-Seaside version 1.1.1.302 Magritte-Tests version 1.1.1.153 OB-Enhancements version 0.328 OmniBrowser version 0.447 OmniBrowser-Algernon version 0.5 OmniBrowser-Full version 0.27 OmniBrowser-Morphic version 0.88 OmniBrowser-Refactory version 145 OmniBrowser-Regex version 0.18 OmniBrowser-Standard version 0.406 Pier version current Pier-Blog version 1.1.1.117 Pier-Documents version 1.1.1.15 Pier-EditorEnh version 1.1.1.48 Pier-Model version 1.1.1.328 Pier-Seaside version 1.1.1.419 Pier-Security version 1.1.1.141 Pier-Tests version 1.1.1.137 Polymorph EventEnhancements version 1.1 Polymorph Geometry version 1.1 Polymorph TaskbarIcons version 1.0 Polymorph ToolBuilder version 1.3 Polymorph Tools Diff version 1.3 Polymorph Widgets version 1.4 Refactoring Core version 48 Refactoring Spelling version 5 RoelTyper version 0.60 RSRSS2 version 2.8.4.12 Scriptaculous version 2.8.4.250 ScriptManager version 0.6 Seaside version 2.8.4.591 Seaside-Adapters-Core version pmm.2.mcz Seaside-Adapters-Swazoo version 9 Seaside-Squeak-Adapters version pmm.3.mcz SeasideAdaptersCompatibility version pmm.1.mcz Shout version 3.15-tween.72 ShoutWorkspace version 1-tween.4 SmaCC runtime version 13 Sport version 2.31 Squeak dev packages version 0.28 Squeak web packages version 0.2 SUnit-improved version 4.0.118 SUnitGUI-improved version 4.0.50 Swazoo version 2.1 Universes version 52 Universes OmniBrowser version 0.38 VBRegex version 1.9 YAXO version 14 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

1 0

Re: Squeak Forks Popularity & Trends Estimate
by Andreas Raab 06 Jul '09

06 Jul '09

Nevin - Now that's a -5 troll if I've ever seen one. Please, everyone let's not get into pointless "oh, my god, the sky is falling" discussions. At Squeak.org we got our work carved out for us. Here is what we need to concentrate on: Fix our processes, enable contributions, discuss strategy. Part of that strategy discussion obviously needs to include positioning but there is really no point in dwelling about who is the most popular Squeak in town. Cheers, - Andreas

5 7

Squeak Forks Popularity & Trends Estimate
by Nevin Pratt 06 Jul '09

06 Jul '09

There's no right or wrong answer to the following three questions. And, every response is meaningful, because it helps reveal the general sense of direction that the community is feeling. *********************** Question #1: Of the various Squeak forks (such as Croquet, Pharo, etc.), what is your feeling of their relative popularities at this point in time, and how does that compare with the current popularity of the base Squeak distribution? Question #2: This is related to the above-- what is your feeling of the relative popularity *trend* of each of the forks, and how does that compare with your feeling of the *trend* of the future popularity of the base Squeak distribution? Question #3: What is your justification for your answers to the above two questions? ************************ I'll begin with my own answers... ...I'm beginning to feel like the Pharo fork currently now has maybe 50% or more of the popularity of the base Squeak distro, and I'm beginning to feel like Pharo is headed to become the dominant distribution in the future, surpassing the original Squeak distro. And I base that feeling on several observations: 1. The email traffic comparison on the "Pharo-project" email list compared to the email traffic on "The general-purpose Squeak developers list", and the observed trend in such traffic. 2. The number of developers posting on the Pharo-project email list. 3. The specific developers posting on the Pharo-project email list (known Squeakers who have contributed heavily to Squeak in the past). 4. The fact that Seaside development has moved to Pharo. At one time I wondered if Croquet would become the dominant Squeak fork, for the simple reason that it had a business organization "officially" supporting it, similar to what Squeak had in the Disney days. But now I think I would bet my money on Pharo. What do you think? And why? Also, remember, there's certainly nothing wrong with several "dominant" forks existing. But of those, one of them will still be the most popular overall. And I'm curious about thoughts of which one that is, and which one that will become, and why you think so. Nevin

2 1

Replacing Transcript>>#show: by Keith' logging considered harmful
by Klaus D. Witzel 05 Jul '09

05 Jul '09

Keith, I understand your response but would like to make clear some of the obvious consequences. Let's say that the Kitchen Sinkers Guild[tm] registers interest in your logging and attempts to replace Transcript>>#show: by your work. They first start with (Smalltalk at: #Transcript put: ProtoObject basicNew) because they always wanted to try out what happens then. After the huge outcry in the community they then know that they got all possible attention and change that to (Smalltalk at: #Transcript put: KeithLogging basicNew) initialize. Of course they implement the old Transcript protocol in class KeithLogging as convenience methods. So things get released :) Then after a while, people complain that every time they do world -> windows -> find a transcript, that KeithLogging no longer works :( This report creates a flood of reponses from people asking to protect world menu from unauthorized changes and Seldom On Board members have to step in and assign to a team the responsibility for reorganizing world menu access. The new team proposes something based on Spoon's imprinting mechanism but un-fortunately have to postpone implementation because of lack of time of some of their members :( But in one of their messages, the world menu access team forgot to scrub the DS acronym and another guy chims in and (unwillingly, as usual) starts a debate on refactoring world menu access with DeltaStream recording, because then his streams can be distributed to other forks as well. He's not sure if 80% of the needs are covered but suggests to give it a try anyways. This guy talks soo often about itches and scratches that some lurkers begin to reveal their identity in squeak-dev and begin with voicing their concerns about the Scratch user interface, and that Smalltalk is probably doomed if nothing will ever be done against the wrong colors and unchangable buttons in Scratch. This all creates such deluge of messages in squeak-dev that Seldom On Board members get really concerned and make a new announcement: that the community server has been, already and successfully, moved over to an iPhone, and that Squeak community is the first online community running all their community services on a single iPhone. When asked what that would be good for (except the fame and fun of it) the Seldom On Board members suddenly arrange for another unplanned meeting and write up a manifesto which declares that now the rest of the world can get an iPhone contract *together* with Squeak community membership, and that that is the obvious way for inventing the future. Meanwhile the world menu access team has hacked up some methods but due to incompatability with the new iPhone community server (or was it the iPhone shop policy) the project is abandoned :( After a long period during which the world -> windows -> find a transcript problem got no attention at all, someone contributes a method which asks the user what s/he really wants: a Transcript or the KeithLogging instance. Without any further debate this gets released. ------- Keith, I hope that in the above you can easily see that your proposal is infeasible. Sorry for no better news. /Klaus -- "If at first, the idea is not absurd, then there is no hope for it". Albert Einstein

6 7

SSL problems talking to google data
by C. David Shaffer 05 Jul '09

05 Jul '09

Using: SSL-rww.4 (and .3) Cryptography-RJT.10 Squeak 3.10.2-7179-basic I'm trying to perform an OAuth authentication against google data. The first URL I need to contact is: |https://www.google.com/accounts/OAuthGetRequestToken Unfortunately opening an SSL socket to this URL produces a socket in the "Closed" state even before any HTTP request information can be sent: socket := SSLSocket newConnection: 'www.google.com'|| port: 443. (Delay forMilliseconds: 500) wait. socket prints a SSLSocket - Closed I've successfully used my OAuth code against IBM's Jazz/JFS server so I know that the SSL in my image is "mostly working." I'm only guessing that something is going wrong during the SSL handshake but I don't know how to debug it. David |

3 3

Deprecation policy
by Ken Causey 05 Jul '09

05 Jul '09

I would like to suggest that we develop a formal deprecation policy. It could be as simple as deprecate in one release, remove in the next. I just think we need to be consistent about it and remove no individual methods without following it. How this relates to the idea of repackaging and removing whole categories of classes, I'm not so sure. Ken

3 4

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

05 Jul '09

> > Bob is not a taskmaster who controls the image, demeaning our > jobs to just submitting changesets for his approval. We, the > community, build the image, and bob relieves us of the drudgery > of making sure the packages load order is reproducable, and from > waiting 5 hours for the unit tests to finish. > Not at all. You the community, pick the release designer, the team leader. The team leader sets the goals, "right we are going to load all the collections fixes in this release, and we are going to improve the Network package." We have a month. The team leader writes a task for bob... PackagesSqueak315 latest: 'Network'. Installer mantis select: [ :ea |( ea category = 'Collections') & (ea status = "resolved") & (fixedIn = '3.15') Bob runs that task every day for a month, and you get to see the test results and the output image. You also get the dev image the full image and the minimal image, and the seaside image and the magmaserver if you want it. So you can all hack on network for a month, and Bob generates and tests the result. However... this is silly... you dont really want the release team to be hacking away on Network while you are still making a release. So two months earlier... you announce, we want to improve Network, who wants to help.... the Network improvement team leader writes a task for Bob which does the following. Installer sf project: 'NetworkImprovements'; install: 'Network'. So now the Network improving team get to hack away on their "trunk" project for a couple of months, meanwhile bob is doing the testing for them, and publically showing everyone how brilliant the new refactored network package is. So now fast forward 2 months to Release 3.15.... the task that the teamleader defines is exactly the same, except, the work has already been done, with interfaces specified and documented (in your dreams) and tested for two months before hand. So now he announces the goals as "we are going to load all the collections fixes in this release, and we are going to integrate the improved Network package, that is to migrate the kernel image to use the new features of the Network packkge wherever possible. But one enterprising member of the NetworkImproving team has forseen this and so had spent a day working on porting the kernel over to use the new Networking package. He knew that if he could publish this changes in a way that the release team could use they would at least try them out. His options are... CS/DS or, if he has a copy of 3.14 release handy, he could do all the hacking and publish a complete new set of MC packages, that include his change. The least useful option of the three is the MC one, because it doesnt help any other fork to adopt the new network package. am I making any sense? (he says tempting fate) Keith >

1 0

where is FFI now ?
by Mariano Martinez Peck 05 Jul '09

05 Jul '09

I cannot find it in http://source.squeakfoundation.org/trunk/ neither in http://source.squeakfoundation.org/ Please, I need FFI! Thanks in advance, Mariano

2 3

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

2 1

http://source.squeak.org/trunk is now at 3.10.2
by Andreas Raab 04 Jul '09

04 Jul '09

Folks - Just as a short update the repository at http://source.squeak.org/trunk is now at 3.10.2. I have copied the original packages from 3.10 and created commits from the deltas that were in 3.10.2. I would appreciate if some of you could test the update process by doing the following: * Download the "original" 3.10 release at http://ftp.squeak.org/3.10/Squeak3.10-7159-basic.zip * Point Monticello to http://source.squeak.org/trunk and load the latest version of MonticelloConfigurations to ensure you have the needed fixes for the next step. * Execute the following doIt: MCMcmUpdater updateFromRepositories: #( 'http://source.squeak.org/trunk' ) Sit back, fetch a cup of coffee, read the newspaper, relax ;-) A little while later the process should complete and you should be in the same state as the 3.10.2 release. In addition, your version has been updated so that the next time you can just go to the World menu, Help, and choose "update code from server" (or use the Squeak flap) and you will update automatically from source.squeak.org (thanks Edgar!). The next step will be integrating the fixes that are already marked for 3.11. I did a quick test and it looks like Installer is the ticket here but unfortunately, I ran into some issues with the actual fixes so this will have to wait just a little while longer. (I'm hoping I'll get around to most of it on the weekend) Cheers, - Andreas

11 25

Jump to page: