Squeak-dev February 2009

squeak-dev@lists.squeakfoundation.org

108 participants
131 discussions

[Election] Campaigning period until sunday!
by Göran Krampe 23 Feb '09

23 Feb '09

Hi all! As you probably are aware the 22nd of february just passed and we have a finalized candidate list of 11 candidates: Jecel Assumpcao Jr Ken Causey Edgar J. De Cleene Bert Freudenberg Matthew Fulmer Craig Latta David Mitchell Brent Pinkney Andreas Raab Randal L. Schwartz Igor Stasenko (alphabetic order, nothing else) ...from now until sunday the 28th the campaigning continues/heats up. I invite and encourage all candidates to post their "platform" for being elected and let the discussion flow. There will be no formal Q&A as we had last year. Again, for all info regarding the election, see: http://wiki.squeak.org/squeak/6116 regards, Göran

2 1

Re: [squeak-dev] election and my views (part 2)
by Igor Stasenko 23 Feb '09

23 Feb '09

2009/2/23 Jecel Assumpcao Jr <jecel(a)merlintec.com>: > An issue that I didn't mention in my first email but about which the > community is very divided is how much effort should be spent on playing > nicely with the rest of the computing world. On one extreme you have > SqueakNOS which tries not to depend on anything about the hardware, at > the other extreme you have Huemul Smalltalk (I have never understood its > relation, if any, to Squeak) where the focus is using as much of other > people's work as possible. > > http://sourceforge.net/projects/squeaknos/ > http://www.guillermomolina.com.ar/huemul/ > > Besides Squeak, I also enjoy using many other Smalltalks (though I > haven't done so in many years) such as VisualWorks, Smalltalk X, > Dolphin, Smalltalk MT, GNU Smalltalk, Little Smalltalk, Self, Smalltalk > Express (free version of Smalltalk V/Win) and so on. Some of the nicest > ones owe a lot to their tight integration with the underlying platform > (Windows, in the three cases I am talking about) and it is obvious to me > while many people long for the same thing in Squeak. You get to leverage > the work of a lot more people and get advantages, such as full use of > hardware acceleration, "for free". Squeak VM also leveraging a huge amount of work "for free" :) Take in account a GCC compiler tools (can anyone guess how many million lines of code buried there? ). And this "for free" having own price, like inability to express VM in terms of smalltalk, hence slang invented with cool multiple pages of code for a simple methods.. ;) > > But to me the most valueable characteristic of Squeak is its "runs > everywhere" feature. So my support for being friendly with other > software systems goes only as far possible without sacrificing > universality. In other words, any improvement to Squeak which would kill > off SqueakNOS won't get my vote. Full disclosure: my project is even > more radical than SqueakNOS (I don't even feel the need to play nice > with popular hardware) and I do intend to make money on it. But my vote > in this regard would not be on my own behalf since I already have to > deal with a lot of stuff like this and adding a few more wouldn't be a > big deal for me. > > In my previous email, I mentioned that having all those old images which > still run allows us enough backwards compatibility that we can move > boldly forward. That is in part due to how isolated Squeak has been. > Most other applications I still have from the same time frames no longer > run on my current Linux installation. > > Speaking of moving boldly forward, this doesn't mean we should ignore > other Smalltalks. I am participating in the new ANSI (no longer ANSI...) > standard effort and would like to see it become easier to move code > around. > > -- Jecel > > > -- Best regards, Igor Stasenko AKA sig.

1 0

Re: [squeak-dev] election and my views (part 2)
by Jecel Assumpcao Jr 23 Feb '09

23 Feb '09

An issue that I didn't mention in my first email but about which the community is very divided is how much effort should be spent on playing nicely with the rest of the computing world. On one extreme you have SqueakNOS which tries not to depend on anything about the hardware, at the other extreme you have Huemul Smalltalk (I have never understood its relation, if any, to Squeak) where the focus is using as much of other people's work as possible. http://sourceforge.net/projects/squeaknos/ http://www.guillermomolina.com.ar/huemul/ Besides Squeak, I also enjoy using many other Smalltalks (though I haven't done so in many years) such as VisualWorks, Smalltalk X, Dolphin, Smalltalk MT, GNU Smalltalk, Little Smalltalk, Self, Smalltalk Express (free version of Smalltalk V/Win) and so on. Some of the nicest ones owe a lot to their tight integration with the underlying platform (Windows, in the three cases I am talking about) and it is obvious to me while many people long for the same thing in Squeak. You get to leverage the work of a lot more people and get advantages, such as full use of hardware acceleration, "for free". But to me the most valueable characteristic of Squeak is its "runs everywhere" feature. So my support for being friendly with other software systems goes only as far possible without sacrificing universality. In other words, any improvement to Squeak which would kill off SqueakNOS won't get my vote. Full disclosure: my project is even more radical than SqueakNOS (I don't even feel the need to play nice with popular hardware) and I do intend to make money on it. But my vote in this regard would not be on my own behalf since I already have to deal with a lot of stuff like this and adding a few more wouldn't be a big deal for me. In my previous email, I mentioned that having all those old images which still run allows us enough backwards compatibility that we can move boldly forward. That is in part due to how isolated Squeak has been. Most other applications I still have from the same time frames no longer run on my current Linux installation. Speaking of moving boldly forward, this doesn't mean we should ignore other Smalltalks. I am participating in the new ANSI (no longer ANSI...) standard effort and would like to see it become easier to move code around. -- Jecel

1 0

Which Mondrian ?
by Cédrick Béler 23 Feb '09

23 Feb '09

Hi, As I need to draw a PERT diagram, I decided to give Mondrian a try. I had a version (ported by Lukas [1]) used in OB which I started to use and read doc (code doc :) ). And I saw that Alexandre (Bergel) is working on improving another version [2]. So, which one to use (knowing that I use OB) ? I think there are differences... Thanks -- Cédrick [1] http://source.lukas-renggli.ch/mondrian [2] http://www.squeaksource.com/Mondrian

1 0

[Ann] LevelPlayingField update
by Keith Hodges 23 Feb '09

23 Feb '09

Dear All, the nice folks at pbwiki.com have offered us the opportunity to upgrade to version 2 of their software. Unfortunately for us this upgrade is not optional, and breaks all of LevelPlayingField. Just to prove how nice they really are they gave us just 1 month of notice. To be fair I talked with their technical support reps and they attempted to be very helpful. However the new flashy html based editor really isnt good for our simple scripts. So as of now, LevelPlayingField is no longer using installer.pbwiki.com for web hosted scripts. Our account does have have 20Gb of file space which is still quite useful. Installer now has a secondary package Installer-Scripts, a facility for providing default answers to requests like so: Installer install: 'Packages'. Invocation is still via the usual means command line usage: 1. squeak old.image http://installer.pbwiki.com/f/LPF.st SmalltalkImage save=new.image workspace usage: 2. HTTPSocket httpFileIn: 'installer.pbwiki.com/f/LPF.st'. universe usage: 3. Installer universe install: 'Monticello15'. "(or Monticello16)" regards Keith

4 6

Re: [Pharo-project] What about #ifNotNil and #ifNotNilDo:
by Keith Hodges 22 Feb '09

22 Feb '09

>> >>> Hi, >> >>> >> >>> is there a way to get the #ifNotNilDo: behavior to write compatible >> >>> Squeak and Pharo code? >> >>> >> >>> >> > >> >> -> do not use ifNotNilDo: >> -> use ifNotNil: without the > argument. >> >> The real fix of course would be for Squeak adopting > the optinal args >> changeset >> (this is from 2007...) > > The Author class is another > > incompatibility issue that I expect to have to address via LPF. Are > > there any more? > Thousands. Literally. > > I am highly skeptical about LPF. > > Marcus Hello Marcus, I don't think that you understand, LPF is only about providing a leg up for the older code, a migration path for fundamental stuff, like Monticello. You appear to have adopted the view that LPF ( http://installer.pbwiki.com/LevelPlayingField ) is supposed to make the whole image up to the same level for everyone. It isn't, it works for what it was intended to do, that is to provide Installer/MC/MCC/Sake/Packages/PackageInfo for all images. In this case, I do hope that Pharo hasn't made thousands of changes which prevent code from loading and compiling in Squeak. That is the issue that ifNotNil: [ :a | ] and Author raises, Syntax errors on loading. I am sure that LPF can help there in the majority of cases. Most projects are built in layers, the fundamental layers, once ported may support other layers across all images. LPF is primarily about loading code across images. Getting that code to work is another problem entirely which LPF may help with, but is not expected to solve. Perhaps a concrete example might help illustrate what the issues really are: You guys developed your Monticello for 3.9, and it wasn't compatible with 3.8, 3.8 code loaded into 3.9 but not the other way around, and the 3.9 Monticello implementation itself was never designed to be loaded in 3.8. In short the 3.8 Monticello became dead to innovation (a fork by default rather than by design), and unmaintained overnight, as did a lot of 3.8 code. This is the issue that LPF was designed to address. The purpose of LPF is to help prevent projects getting completely stuck on one image, particularly to enable projects stuck in 3.8 to move to 3.10. When you want to port a large commercial project from one image to another you want to support your existing users in the old image at the same time as working on the next version in the new base image.. You want to continue to manage your packages simply without having to keep two separate branches. MC in 3.9 would not save mcz files that would load into 3.8, and this fact alone was a real barrier to moving things forward. The new 3.11 development process, aims to address this. Tools, fixes, and API's that may be included in 3.11, will be developed and usable in 3.10. So both the current user base in 3.10, and the early adopters in 3.11 are able to use identical API's and Tools, and migration is both possible and probable. The traditional approach that Pharo is using produces a new image, developed by a new team as a complete break from the past, and everyone is forced to code to a moving target. This is the process that squeak has been using since before the flood, and it is this process that I have identified as the problem. (I accept that I may be wrong) I myself haven't adopted Pharo, not because you aren't making good changes, or making things better, but because your development process guarantees that there will be problems down the line. Not only do you make it difficult for me to port my current deployments to Pharo with anything other than a step change, since that is your avowed intent. But also Pharo 2 will inevitably be incompatible with Pharo1 and so on, due to the process. I thank the pharo team for performing lots of useful research on behalf of the squeak community, I expect that we will be able to adopt most of your innovations, but this will take time, and will be carefully considered, with the backward compatabiity issue in mind. regards Keith

1 0

election and my views
by Jecel Assumpcao Jr 22 Feb '09

22 Feb '09

Before deciding how I should do something, I like to step back and think about why I should be deciding in the first place. In the case of this year's election, the most basic issue is that there are three things of great value associated with the name "Squeak": 1) the software 2) the community 3) the brand recognition The software itself has its good points and its flaws, and it would be nice if it could be improved. Since Squeak has always been fully open source (the license issues didn't change that fact) anyone can change anything about it that they like. Community is very important to me and can easily outweigh technical details. When I wanted to install a Unix clone on my PC back in 1994, BSD was superior to Linux but the latter had a larger and more active community and, as I guessed it would, this let it evolve more rapidly. There are many very different groups that are part of the Squeak community and any individual or group can do whatever they want. At one point in time there were more people using the SmallLand fork of Squeak than the official one. And there always should be an "official" one. What the name Squeak actually means should be decided by the community as a whole. We could have a direct democracy and have a vote for any issue related to the name (like I said above, any other issue can be decided by random individuals and so they should "vote with their feet" instead), but this would take up too much of everyone's time. An alternative is a representative democracy where you vote for some people and then they vote for the issues in your name. This will work well if you can either guess how your representatives will vote on each issue (which is why I am writing this - so people can see whether I think like they do or not), but often you just have a general trust in your representative to do "the right thing". This is important since discussions among the leadership themselves or with other people in the community might make them change their minds (see 4.0/5.0 plans this year for what I think is a positive example of this process in action). What kinds of issues should the leadership be deciding on? Obviously, in any releation to entities outside the community (creating a foundation or associating with the SFC, hiring hosting for "official" Squeak websites, making some deal with SugarLabs) as well as parts of the community itself (EToys users, Croquet, Sophie, Seaside/Aida, previous developers whose code we wanted to relicense) there should be some person or group of people who have the authority to speak for the whole group. Given that the community was formed around a technical object, it is no wonder that technical issues are often our highest priority. One option would be for the leadership to initiate projects to improve Squeak. Another would be for them to accept proposals and "bless" some of them. Yet a third choice would be for them to limit themselves to selecting some finished improvement and declare that to be the next official Squeak. My own preference is to have mostly the third path with some very rare deviations into the second option, which unless I am mistaken is the current situation. The third path has caused us problems in the past: people hesitate to commit to some project if there is the danger that it will be "rejected" when it is done. Adding an exception framework to Squeak is a good example of this. Getting the last few details right in a project takes far more work than the rest of the project and many people feel they need official support before it is worth doing that extra work. On the other hand, there are many wonderful plans and half-finished projects lying around. Betting the Squeak brand on them would have had very painful results. Even with this far more limited role, there is a lot of room for deciding how fast or slowly the official Squeak should evolve. In this regard, I take backwards compatiblity very seriously but given that older versions of Squeak continue to be available even as newer ones are released, I don't think that radical changes should be ruled out. I am in favor of adding Traits to Squeak and adopting the Spoon stuff, for example. I am typing this in a Squeak 3.9 image while chatting on IRC using a Squeak 3.8 image and developing VM stuff in a 3.10.2 one. I still run 2.x images as needed and very rarely even 1.x ones. Not everyone knows me, so here is a short history. I got interested in Smalltalk when I read the famous August 1981 issue of Byte magazine and started working on Smalltalk computers (initially with the Motorola 68000 chip) in 1984. Brazil is far from Xerox PARC, of course, so I had at most one or two articles a year as my community. Starting in 1988 I was able to chat with Smalltalkers around the world (first with the BIX - Byte Information eXchange service, then with the BITNET and finally through the Internet). When the Self dialect of Smalltalk was created I become very interested in that and was a very active participant in that community. Since, as Mario Wolczko said, "Self is like Smalltalk, only more so!" I was puzzled that some Smalltalkers had such a negative reaction to it. This was the early 1990s when most Smalltalkers worked in financial institutions and came from Cobol backgrounds and were too scared of C to try C++, so I just assumed that their idea of Smalltalk was different than mine due to this. When Self was first killed at Sun, John Maloney invited me to the new Squeak community that was starting up. The early days were very exciting and being familiar with Squeak as it existed in a given date didn't mean you had a clue of what it would be like a month later. All projects slow down considerably as they mature, of course. So a few years later it seemed like Squeak was stuck in the same place while Slate was zooming forward at unbelievable speed. And so on. Given how fast Squeak was changing back in 1998 and how much energy the community had, I sent a few emails to see what the reaction would be to adding some Self-like features to Squeak and makes some other radical changes. I was surprised at how negative some people were ("if I wanted to program in Self I wouldn't be using Squeak" was expressed by several people) and certainly didn't wish to take the community where it didn't want to go (I still don't) and so dropped the subject. I remained a participant in the Squeak community but worked on my own Smalltalk (until last september, when my project became based on Squeak). What I would like to see is a better integration between all projects that use Squeak. I wrote above that we can count to the old images to partly handle the needed backwards compatiblity (specially if some extra care is put into them, like Keith's Level Playing Field efforts). On the other hand, I am counting on Viewpoints Research to handle the radically different future. So for "official Squeak" I want to see a middle ground where we move nicely forward without leaving anyone behind. Though I wrote that I don't think it is the role of the leaders accept wild plans or half finished projects, this doesn't mean that I can't have my own wild plans. Here is an example of something that would help groups work together even while moving in different directions: http://wiki.squeak.org/squeak/584 As a leader I wouldn't vote for what is just text and drawings. But I am trying to get some funding to get this "Chunky Squeak" implemented. That is also not the role of a leader. if/when it is actually working and can be tested against any alternatives that bring us similar advantages, then I would be very happy to vote for including it into the Squeak roadmap. Cheers, -- Jecel

1 0

Google Summer of Code 2009
by askoh 22 Feb '09

22 Feb '09

Hi: Giovanni Corriga, the GSOC 2007 and 2008 administrator, has asked me to be the administrator for GSOC 2009. My experience with the The Squeak Project GSOC 2008 was excellent and I believe the open source smalltalk community has benefited a lot from his efforts. Thanks Giovanni. Thanks to those who helped him too. I will be using much of what he has set up. So this is the start of my work: 1) How do I get a username and password to edit the wiki http://wiki.squeak.org/squeak 2) GSOC also needs a backup administrator. Please let me know. 3) What is the best way to get the word out and "meet" centrally? More later. All the best, Aik-Siong Koh -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-2009-tp22108681p22108681.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

10 29

New smalltalk website and Smalltalk activities in Barcelona
by Jordi Delgado 22 Feb '09

22 Feb '09

Hi, My name is Jordi Delgado and I am an associate professor at the Software Dept. of the Technical University of Catalonia (http://www.lsi.upc.edu/~jdelgado). I have translated to Catalan prof. Ducasse's book on the Botsinc system and I have been giving Botsinc and Smalltalk courses for almost a year now. The Smalltalk course is now a free elective course in our undergraduate Computer Science degree at the Barcelona School of Informatics. You can find information on our activities in the new smalltalk site: http://smalltalk.cat though the *entire site* is in catalan, not english. However, it is pretty easy to deduce what we are talking about. The main purpose of the smalltalk.cat site is to keep in touch with the local (small) smalltalk community. The site is quite simple, but good enough for the purpose it was designed for. It is powered by Pier 1.0 and Squeak. We have a quarterly course on Smalltalk based on SBE (http://smalltalk.cat/poos) at the Barcelona School of Informatics (http://www.fib.upc.edu), and also, for free, at a living lab called Citilab (http://citilab.eu). The Citilab course is open to everybody at no cost, only with the pre-requisite of some programming experience. And the course is identical to the one given in the university. Thus, here in Barcelona anyone can learn Smalltalk, it is free. The slides I use in my lectures are mainly translations of the open-source SBE course by Prof. Oscar Nierstrasz. I used Squeak to create them, mainly to impress the students (but with a result clearly inferior to what you get with Powerpoint, Keynote or Sophie). We also have a weekly seminar on Smalltalk with former students of the course (see http://smalltalk.cat/gts). BTW if any smalltalker comes to Barcelona and wants to get in touch with us, feel free to contact us. That's all, just to let you know we exist. Bests, Jordi PS: I am sending this to several smalltalk lists. Please, accept my apologies if you are receiving more than one copy of this message.

6 6

Mondrian help
by Raymond Asselin 22 Feb '09

22 Feb '09

I try to use Mondrian to analyse a small appl I'm working on... I want to generate Uml like diagram on my appl.. It's working with MOUmlClass example: 'myPackage' . My question: In Mondrian how to eliminate easily the display of accessors method of each class of my package. In my code I did what follow to eliminate the test-classes but don't know how to access methods categorised as 'accessing' ? "I want to strip all classes used for tests, except a class named XPTest that I want to be in the group'" exceptClass := theClasses select:[ :cl | cl asString = 'XPTest']. theClasses := theClasses reject:[ :cl | cl asString endsWith: 'Test']. theClasses := theClasses , exceptClass. "Now I want to eleminate all access methods " Any help ? Raymond

16 27

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

Jump to page: