Squeakfoundation January 2002

squeakfoundation@lists.squeakfoundation.org

33 participants
38 discussions

licensing redux
by Mark Mullin 15 Feb '02

15 Feb '02

Just finished an article http://www.wired.com/news/technology/0,1282,50037,00.html about how the Mono project has adopted the X11 licensing terms. The downside of "custom versions" could be offset by having some kind of branding at the organizational level. For the record, our attitude as a company is that we do benefit from what Squeak brings us, therefore when it comes to software we create that does not involve our core business but provides a service we need, it's in our best interests to cough it up. Someone else might pick it up and run with it, and we just admitted we'd rather be a consumer than a producer. However, we do want to protect our virtual reality core, it's our real asset and how we make money. I think the Squeak world can support the uneasy peaceful coexistance of free and commercial solutions in the same space; from our perspective we think Alice is very very nice. But we also think we can make our living on a more sophisticated package for a smaller audience, but for that the license needs to protect us as well as Squeak. So I put in my vote for the concerns that have been addressed by Mono and wonder if anyone has any comments on the X11 license, since I spent grand total of 5 minutes looking at it and IANAL. Mark

8 14

urrrghh - ask for lawyer
by Mark Mullin 31 Jan '02

31 Jan '02

The comment about sleeping lions is well taken, but I've worked with apple legal before, when they had their own building and were really mean (and overfed, happily :-) I'd wait till all the heavies on this board weigh in for a concensus, but we do have a lawyer with some time he owes us and a lot of experience with our software and protecting it. I think he could probably do the job for us as a community, I'd volunteer him for the trenches if there is community interest, with the goal being absolute clarification (given legalese) of what's a hands off integration relationship with squeak, i.e. solid protection for plugin apps that do not have any squeak side modifications that aren't open sourced. In my own case, protect my plugin and let me keep my copyright on my unique grammar for communicating with my plugin, I'll even cough up _all_ my squeak side code, base platform or pure application. If you're amenable or opposed to this idea, send me a note. I'll tabulate results for a few days and then repost them, and everybody can pitch in and bitch :-) This is presupposing I'm not murdered on .dev for casting aspersions at iterator loop speeds....... Regards Mark -----Original Message----- From: squeakfoundation-admin(a)lists.squeakfoundation.org [mailto:squeakfoundation-admin@lists.squeakfoundation.org]On Behalf Of squeakfoundation-request(a)lists.squeakfoundation.org Sent: None To: squeakfoundation(a)lists.squeakfoundation.org Subject: Squeakfoundation digest, Vol 1 #94 - 10 msgs Send Squeakfoundation mailing list submissions to squeakfoundation(a)lists.squeakfoundation.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.squeakfoundation.org/listinfo/squeakfoundation or, via email, send a message with subject or body 'help' to squeakfoundation-request(a)lists.squeakfoundation.org You can reach the person managing the list at squeakfoundation-admin(a)lists.squeakfoundation.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Squeakfoundation digest..." Today's Topics: 1. Re: What I would like to promote (Bijan Parsia) 2. RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Mark Mullin) 3. Re: What I would like to promote (Dan Ingalls) 4. Re: RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Cees de Groot) 5. AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Andreas Raab) 6. Re: What I would like to promote (Dan Ingalls) 7. AW: [Squeakfoundation]What I would like to promote (Andreas Raab) 8. Re: AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Cees de Groot) 9. Re: AW: [Squeakfoundation]What I would like to promote (Cees de Groot) 10. Re: AW: [Squeakfoundation]What I would like to promote (goran.hultgren(a)bluefish.se) --__--__-- Message: 1 Date: Wed, 30 Jan 2002 08:25:14 -0500 (EST) From: Bijan Parsia <bparsia(a)email.unc.edu> To: squeakfoundation(a)lists.squeakfoundation.org Subject: Re: [Squeakfoundation]What I would like to promote Reply-To: squeakfoundation(a)lists.squeakfoundation.org On Wed, 30 Jan 2002, ducasse wrote: > > Yes. Celeste mostly, at the moment. It really needs to be split up, and > > some of the classes it depends upon (E.g., MailDB) need, themselves to be > > refactored. > > > So celeste could be a good testbed for a refactoring process. Have you > approach the celeste users and the people taking care of it. There have been rumbles on the squeak-dev list from time to time ;) > Could you set > up a war plan to clean celeste? I think so. Celeste is also interesting because it has a lot of functionality that even non-Celeste users might want. For example, sometimes you want to compose and send an email message from Squeak, but *don't* want to be a full fledged Celeste user. (E.g., mailing changesets/bugs/etc. to the list). There are a variety of Celeste UIs, etc. > It would be good to extract celeste from the squeak image, do a call for > tests and lead a refactoring efforts. This way we could: > - have a better celeste > - learn in the process Yep. And gain a few things in the process. Celeste's persistence mechanism is a tad primative...but useful! If it can be made so that the *interface* is relatively stable, but the storage backend and filter/query process were registerable, well, that would rule :) > I think that Celeste is "well" separated from the core so this could be > interesting to try. Yes. Cheers, Bijan Parsia. --__--__-- Message: 2 From: "Mark Mullin" <mark(a)vibrant3d.com> To: <squeakfoundation(a)lists.squeakfoundation.org> Date: Wed, 30 Jan 2002 10:32:22 -0500 Subject: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Reply-To: squeakfoundation(a)lists.squeakfoundation.org OK, Cees seems to know whereof he speaks, he certainly calls our concerns out clearly, I'm off to read the GNU Library license again. I'd be curious if anyone has already clarified it's application to the reverse situation, i.e. our VR engine is fundamentally a (great big fat badtempered) plugin library for Squeak. We have no problem giving away any changes we make to squeak or any non-VR code, we just want to protect our copyrights on our core library plugin. Anyone seen how the LGPL has been applied to this, say in creating 3rd party commercial libraries for gnu compilers. Re the death of IP in general, Cees, I'd tend to agree, software patents show how low we are sinking. On the other hand, one needs to make a living. And in general, if you give it away and ask them to pay if it works, you starve. Mark --__--__-- Message: 3 Date: Wed, 30 Jan 2002 07:49:09 -0800 To: squeakfoundation(a)lists.squeakfoundation.org From: Dan Ingalls <Dan(a)SqueakLand.org> Subject: Re: [Squeakfoundation]What I would like to promote Reply-To: squeakfoundation(a)lists.squeakfoundation.org > > >> Yes. Celeste mostly, at the moment. It really needs to be split up, and >> some of the classes it depends upon (E.g., MailDB) need, themselves to be >> refactored. > > >So celeste could be a good testbed for a refactoring process. Have you >approach the celeste users and the people taking care of it. Could you set >up a war plan to clean celeste? > >It would be good to extract celeste from the squeak image, do a call for >tests and lead a refactoring efforts. This way we could: > - have a better celeste > - learn in the process > >I think that Celeste is "well" separated from the core so this could be >interesting to try. I agree. If you look at changeSet #3746, ... ----------------- Introduces a new image partitioning tool that is essentially a local version of majorShrink. The idea is to pick some application like Scamper, or some cluster like all the 3D classes, and remove it, and also remove everything that is solely referred to by it. The way it works is: Record all unsent messages and unused classes at the outset Mark the application or cluster as removed Note all *newly* unreferenced methods and unused classes and iteratively remove them as well For example, the expression Smalltalk reportClassAndMethodRemovalsFor: #(Celeste Scamper MailMessage) reports 63 classes and 155 other messages that can be removed. Also, introduces a new method, fileOutAndRemove:... that will take such results, build a changeSet from them, fileOut everything that is about to be removed, and then remove all of the classes and related messages as well. For the above example, this method produces a 290k fileOut, and saves about 104k from the system. More importantly, if you fileIn the changeSet afterward, the system returns to approximately its former size, and you can run Scamper again. It's a way to fileOut a package that never existed. ------------------- So a year ago, that group and that method (for which there is now equivalent code in modules) worked perfectly as a module a year ago. - Dan --__--__-- Message: 4 To: squeakfoundation(a)lists.squeakfoundation.org From: cg(a)home.cdegroot.com (Cees de Groot) Subject: Re: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Date: 30 Jan 2002 17:23:47 +0100 Organization: cdegroot.com Reply-To: squeakfoundation(a)lists.squeakfoundation.org Mark Mullin <mark(a)vibrant3d.com> said: >I'd be curious if anyone has already clarified it's application to the >reverse situation, i.e. our VR engine is fundamentally a (great big fat >badtempered) plugin library for Squeak. That centers around "If the Modified Software contains modifications, overwrites, replacements, deletions, additions, or ports to new platforms of: (1) [class lib], or (2) any part of the virtual machine, then [you have to share the source]. I would not call a plugin library an addition to the virtual machine - the VM is for me the SLANG stuff plus the platform glue, and I think that that's what is meant in the license. I *think* that Apple did not mean to call a plugin library an addition to the virtual machine. However, a bad-tempered lawyer at Apple *could* construe your plugin library to be an addition to the virtual machine. Given the track record of big companies' legal teams smelling profit, blood, or just fun, I'd get a statement from Apple "we don't consider the vibrant 3D plugin as a blahblahblah"... (even though I always had A's in business school for Law: I.A.N.A.L.) -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B --__--__-- Message: 5 From: "Andreas Raab" <Andreas.Raab(a)gmx.de> To: <squeakfoundation(a)lists.squeakfoundation.org> Subject: AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Date: Wed, 30 Jan 2002 19:21:36 +0100 Reply-To: squeakfoundation(a)lists.squeakfoundation.org > I would not call a plugin library an addition to the virtual > machine - the VM is for me the SLANG stuff plus the platform glue, > and I think that that's what is meant in the license. At the time the license was written, there was no such concept as a Squeak VM plugin. However, one of my major motivations for doing the VM plugins was in particular to be able to "access" proprietary code. In other words, a plugin is nothing but an optimized FFI interface (it really is). That's my way of thinking about it and I don't believe that anyone would consider some function called through FFI being an "addition to" the virtual machine. > I *think* that Apple did not mean to call a plugin library an addition > to the virtual machine. However, a bad-tempered lawyer at > Apple *could* construe your plugin library to be an addition > to the virtual machine. That reminds of a recent conversation with a lawyer. Asking "okay, so how can make this issue airtight" the response was "Heck, you are talking about law here! There is no such thing as 'airtight' in law. Companies can sue you and they _will_ sue you no matter what you do." > Given the track record of big companies' > legal teams smelling profit, blood, or just fun, I'd get a > statement from Apple "we don't consider the vibrant 3D plugin > as a blahblahblah"... Actually, having a number of companies ask for their permission might just raise their interest. Don't wake sleeping lions... Cheers, - Andreas --__--__-- Message: 6 Date: Wed, 30 Jan 2002 11:07:34 -0800 To: squeakfoundation(a)lists.squeakfoundation.org From: Dan Ingalls <Dan(a)SqueakLand.org> Subject: Re: [Squeakfoundation]What I would like to promote Reply-To: squeakfoundation(a)lists.squeakfoundation.org ducasse <ducasse(a)iam.unibe.ch> wrote... >I think that Celeste is "well" separated from the core so this could be >interesting to try. Hi Stef - I've been reflecting more on this since responding to your message. I completely defer to you and Henrik on which way to go, but I see a choice here: Either we... Find various small things that are pretty modular and do them first Or we... Take various big chunks that are pretty modular and do them first. By "big chunks", I'm thinking along the lines of the various discardX methods in SystemdDictionary (like all of 3D, all of networking, etc). So this would mean instead of doing Celeste, we do all of Networking as a chunk. Then *later* we refine this and break networking down into Celeste, Scamper, IRC, HTML, PWS, etc. I just have the feeling that it might not be much harder to draw isolation lines around the big chunks than it is around the little ones, and the payoff might be higher, in that it might *soon* be possible for mere mortals to perform their own versions of majorShrink, and have it really work. As I say, I'm happy to go with whatever you guys decide, but I did want to call attention to the choice, and have you make a conscious decision. - Dan --__--__-- Message: 7 From: "Andreas Raab" <Andreas.Raab(a)gmx.de> To: <squeakfoundation(a)lists.squeakfoundation.org> Subject: AW: [Squeakfoundation]What I would like to promote Date: Thu, 31 Jan 2002 00:04:20 +0100 Reply-To: squeakfoundation(a)lists.squeakfoundation.org Dan, Personally, I'm in for some of the larger chunks first. Why? Well, for one thing it's going to test out the framework in some areas that'll really benefit all of us. Secondly, it's perhaps not as easy to define the boundaries for an application like Celeste (some people have already pointed out that some of the stuff Celeste is doing might be of interest for other apps so a careful definition of boundaries is important). Thirdly, having fast and "big" results (like the ability to cut out and load stuff like Wonderland and 3D) will convince people that we're _seriously_ talking about modularity and encourage them to build their own designs into their frameworks. Just my =80.02, - Andreas > -----Urspr=FCngliche Nachricht----- > Von: squeakfoundation-admin(a)lists.squeakfoundation.org=20 > [mailto:squeakfoundation-admin@lists.squeakfoundation.org] Im=20 > Auftrag von Dan Ingalls > Gesendet: Mittwoch, 30. Januar 2002 20:08 > An: squeakfoundation(a)lists.squeakfoundation.org > Betreff: Re: [Squeakfoundation]What I would like to promote >=20 >=20 > ducasse <ducasse(a)iam.unibe.ch> wrote... > >I think that Celeste is "well" separated from the core so=20 > this could be > >interesting to try. >=20 > Hi Stef - >=20 > I've been reflecting more on this since responding to your=20 > message. I completely defer to you and Henrik on which way=20 > to go, but I see a choice here: >=20 > Either we... > Find various small things that are pretty modular and do them first >=20 > Or we... > Take various big chunks that are pretty modular and do them first. >=20 > By "big chunks", I'm thinking along the lines of the various=20 > discardX methods in SystemdDictionary (like all of 3D, all of=20 > networking, etc). So this would mean instead of doing=20 > Celeste, we do all of Networking as a chunk. Then *later* we=20 > refine this and break networking down into Celeste, Scamper,=20 > IRC, HTML, PWS, etc. >=20 > I just have the feeling that it might not be much harder to=20 > draw isolation lines around the big chunks than it is around=20 > the little ones, and the payoff might be higher, in that it=20 > might *soon* be possible for mere mortals to perform their=20 > own versions of majorShrink, and have it really work. >=20 > As I say, I'm happy to go with whatever you guys decide, but=20 > I did want to call attention to the choice, and have you make=20 > a conscious decision. >=20 > - Dan > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation >=20 >=20 --__--__-- Message: 8 To: squeakfoundation(a)lists.squeakfoundation.org From: cg(a)home.cdegroot.com (Cees de Groot) Subject: Re: AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Date: 31 Jan 2002 08:33:29 +0100 Organization: cdegroot.com Reply-To: squeakfoundation(a)lists.squeakfoundation.org Andreas Raab <Andreas.Raab(a)gmx.de> said: >[...]. That's my way of thinking about it and I don't believe that >anyone would consider some function called through FFI being an >"addition to" the virtual machine. >[...] >Actually, having a number of companies ask for their permission might >just raise their interest. Don't wake sleeping lions... > Maybe it'd be an idea if SqC would ask Apple for a clarification here. I think it is a very important issue that we can make clear (in terms that a lawyer will accept) what is and what isn't allowed in the area of proprietary extensions - if you want to make a product a success, you need to be prepared for companies wanting to earn money with it. The plugin bit seems to be a big hole in the license... (or maybe it would be enough to strike the term 'plugin' and call it 'fastFFI' ;-)) You may be right with your remark about now waking sleeping lawyers. I may be right with my remark about better being safe than sorry. WANL (we are not lawyers). IMHO, the fact that this arouses questions that I feel we cannot answer is a bug that should be fixed. -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B --__--__-- Message: 9 To: squeakfoundation(a)lists.squeakfoundation.org From: cg(a)home.cdegroot.com (Cees de Groot) Subject: Re: AW: [Squeakfoundation]What I would like to promote Date: 31 Jan 2002 08:34:14 +0100 Organization: cdegroot.com Reply-To: squeakfoundation(a)lists.squeakfoundation.org Andreas Raab <Andreas.Raab(a)gmx.de> said: >Personally, I'm in for some of the larger chunks first. > Add my vote to that. -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B --__--__-- Message: 10 Date: Mon, 28 Jan 2002 11:01:10 +0100 Subject: Re: AW: [Squeakfoundation]What I would like to promote To: squeakfoundation(a)lists.squeakfoundation.org From: goran.hultgren(a)bluefish.se Reply-To: squeakfoundation(a)lists.squeakfoundation.org cg(a)home.cdegroot.com (Cees de Groot) wrote: > Andreas Raab <Andreas.Raab(a)gmx.de> said: > >Personally, I'm in for some of the larger chunks first. > > > Add my vote to that. Another vote too. By the way - I have voting capability on SqueakDot now, so I added this one, and I have already voted for me, Cees and Andreas - vote here: http://marvin.bluefish.se:8080/squeakdot This is what I referred to as the "Cell Splitting Approach". :-) regards, Göran --__--__-- _______________________________________________ Squeakfoundation mailing list Squeakfoundation(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation End of Squeakfoundation Digest

2 1

Brainstormin'
by Maarten Maartensz 31 Jan '02

31 Jan '02

Hello, Having signed onto this list some weeks ago because of something Dan Ingalls wrote on the developers list, I have a general question and a few general remarks (distilled from 6 months of learning about Squeak). Question: What IS the purpose of the Squeak Foundation maillist? Remark A: Get Squeak into regular university-courses! I am a 51 year old mathematical philosopher with wide interests and too little time and not enough health to spend more than a few hours a day on Squeak, and also with VERY little taste for "socializing" by e-mail. I have given a rather extensive part of my own site to Squeak, but this generates little traffic, probably because (a) my own opinions and formulations concerning most things are not safely average and (b) there are far fewer people seriously concerned with Squeak and Smalltalk than the people seriously concerned with Squeak and Smalltalk would like and do suggest (as I learned over the past half year). The ONE way to get Squeak REALLY going - it would seem to me - is to put one's academic enthusiasms on Squeak's maillist into something academically real and functional: TRY TO GET SQUEAK TO BE PART OF THE ACADEMIC CURRICULUM IN YOUR UNIVERSITY! After all: It IS Open Source; it IS marvellous; it IS fun; and lots of students might learn to program in it quite fast and quite easily - IF ONLY there is a regular curriculum, WITH good courses, good documentation, recent books, CDs with recent versions and lots of good documentation, examples etc. So I would recommend that academics concerned with Squeak seriously contemplate the question how to get Squeak into the normal university courses, especially in top-universities, like Yale and MIT in the U.S., and to have it included in the standard courses offered in computing, together with GOOD, COMPLETE, UP TO DATE documentation (fit for non-hacking types, with less than 16 hours a day available for learning to hack a flakily documented totally different computing language rapidly developed by some dedicated hackers who are FAR better at writing good code than writing good documentation of it). For by far the best way to get Squeak going for non-developers and non-hackers is to give Squeak a place inside the universities and academic world; to make it known, popular and teach it; and to get intelligent people working with it - and especially intelligent people NOT specializing in "computer science" but in some real science like physics, chemistry, biology or mathematics. And as long as this does not happen, Squeak is bound to remain an effort by a few handfuls of enthusiast hacking types, that remains almost unconnected to "the Real World of C and Java", that are taught in very many universities (and indeed seem to me mostly a waste of time, for nearly anyone, especially anyone not concerned with writing commercial applications but with doing real science - but this one cannot prove without Squeak being present in regular university courses next to C and Java). In short: It seems to me very unlikely to get a major new computing language as Squeak indeed is (being Smalltalk + Morphic) going in a major way without getting it taught in standard courses in universities. So if there is ONE thing "the Squeak community" should try, next to developing Squeak, it is to give it a firm footing inside the academic world and inside ordinary courses in computing and programming. (And even if most developers have graduated, by far the best way to get a market going for Squeak-related matter is by having it taught in universities. It might even get some developers an academic job!) Remark B: Put some really good general documentation together, maintain it and update it regularly! Regardless of what people tend to suggest on the developers list - where one is fondly referred to "the Swiki" and it is generally suggested everything to learn Squeak or Smalltalk is plentifully and easily available on the net - the fundamental problem of Squeak-as-is (from the point of view of an intelligent, curious non-hacker, with other interests than hacking, and not infinitely or plentifully supplied with time and energy) is this: There IS NO good documentation on Squeak (for non-hacking types without a Ph.D. in computing plus 16 hours a day to spend on hacking). Period. (And I am not going to change my mind on this after 5 months of spending a lot of energy on what there IS, that got me somewhat disgruntled if only because of the money and time spend on getting time and again random jottings of random people on random aspects of random versions of mostly past Squeaks. Those who say there IS must have rather radically different notions on what good documentation is, and apparently tend to be severely dedicated hacking types with a university-job in computing, having little else to do than learning all manner of little known languages, and telling others this is o so very easy and all documentation to do so is o so plentifully available. Well: It's not easy and it's not available, or if it is most of it is in fact for dedicated specialists only, and besides most of what one finds is outdated and doesn't work in a recent Squeak.) Remark C: "Internet communities" are mostly would-be: Get some real people together! Personally, I do not believe "an internet community" is a community of real people, since real people are far more than occasional bitstreams, and the real world tends to be made (and unmade) by actual groups of real persons really meeting face-to-face. (Meeting a person and freely talking you can size them up. Reading and writing e-mails usually only gives you a bitstream format + some information, usually partial, incomplete, and biased.) Once again, the basic way of getting Squeak going outside the developers list is to have it taught in real universities by real people to real people, and to develop real communities on this basis rather than as mere bitstreams. Regards, Maarten. ------------------------------------------ Maarten Maartensz. Homepage: http://www.xs4all.nl/~maartens/ ------------------------------------------

13 41

RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs
by Mark Mullin 31 Jan '02

31 Jan '02

OK, Cees seems to know whereof he speaks, he certainly calls our concerns out clearly, I'm off to read the GNU Library license again. I'd be curious if anyone has already clarified it's application to the reverse situation, i.e. our VR engine is fundamentally a (great big fat badtempered) plugin library for Squeak. We have no problem giving away any changes we make to squeak or any non-VR code, we just want to protect our copyrights on our core library plugin. Anyone seen how the LGPL has been applied to this, say in creating 3rd party commercial libraries for gnu compilers. Re the death of IP in general, Cees, I'd tend to agree, software patents show how low we are sinking. On the other hand, one needs to make a living. And in general, if you give it away and ask them to pay if it works, you starve. Mark

3 3

RE: [Squeakfoundation]Brainstormin'
by Withers, Robert 29 Jan '02

29 Jan '02

Hi Mark, I suppose I'll join in the discussion, briefly, discussing enhancement adoption issues, relating to quality. maintenance, and commitment. Mostly I lurk on this list, as I feel I can't add much value to the discussion. I am excited about where it is going, however. > -----Original Message----- > From: squeakfoundation-admin(a)lists.squeakfoundation.org > [mailto:squeakfoundation-admin@lists.squeakfoundation.org]On Behalf Of > Mark Guzdial > Sent: Tuesday, January 29, 2002 2:50 PM > To: squeakfoundation(a)lists.squeakfoundation.org > Subject: Re: [Squeakfoundation]Brainstormin' > > > At 2:25 PM -0800 1/28/02, Dan Ingalls wrote: > >1. Decisions about code quality for lots of the stuff that goes > >into the system. This has actually been relaxed a lot in the last > >year, as we have let more in through the more SqF-style harvesting > >process. > > > >2. Decisions about what should and should not go into the image. > > > >3. Decisions about what Squeak "is" -- what are its strengths, how > >it should be "positioned" and presented, who are its likely > >customers, and what will make it most immediately appealing and > >useful to them. > <snip> > Bug fixes are easy -- just harvest them and patch them in. > Enhancements, especially big ones, need to be made carefully. I hope > that as decisions get made to put new things in, the decisions are > made while considering whether we can afford to KEEP the new things > in, i.e., is the developer promising to stick around and keep it > going. I don't mean to slight the developers of Linda, Connectors, > etc. I just think that maintaining the enhancement belongs on the > decision criteria list. I totally agree (partially in my de facto role of developer/maintainer of Linda) Two quick points I want to make regarding what you have said here. First, I believe that a majority of these enhancements will be in the form of external modules. While quality and commitment still needs to be high for these, they don't directly affect the core system, so they can be managed independently of the core system. For those enhancements that extend the core system or that require enhancements to the core system, much more careful consideration should be given, unless our new module system can do scoped shape changes of core classes. Second, the proof is in the pudding, er..the tests. All enhancements should come with a robust set of tests for it's features and collaborations. A quality test suite is never finished, but continuously evolved and extended. Requiring a test suite for each enhancement would give the community to rank the quality of an offering, as well as document the interfaces for maintenance. This becomes especially important should owners decide to do other things with their copious time. To really make this work, a decision about the fundamental core of the Squeak should be made and backed up with test cases. This core has been identified as including object, blocks, collections, magnitude, dependencies, multicast events, metaprotocol and classes, and probably a few others. Rob

2 1

RE: [Squeakfoundation]Brainstormin'
by Withers, Robert 29 Jan '02

29 Jan '02

Luciano Notarfrancesco wrote: > Withers, Robert wrote: > > > > >To really make this work, a decision about the fundamental > core of the Squeak should be made and backed up with test > cases. This core has been identified as including object, > blocks, collections, magnitude, dependencies, multicast > events, metaprotocol and classes, and probably a few others. > > > Is there any official decision on this? I don't think so, but prior excavations seem to settle on this as the minimal functional set (PocketSmalltalk, etc) > I guess Exceptions and Streams will have to be included too. yep, good ones. > It would be nice to leave the Compiler out as a module, together with > development tools. Yes, although how one could pull in the compiler later is an interesting exercise. Image segments would work. Rob

1 0

New mailing list request for Bellesqueak
by Paul Fernhout 29 Jan '02

29 Jan '02

Cees- I would like to request a new mailing list and Wiki for a Squeak-inspired project called "Bellesqueak". This is a ground up project inspired by Squeak, intended to learn from Squeak's strengths and weaknesses including licensing issues. It is not an effort to modify Squeak itself (although Squeak may be used as scaffolding and a tool to develop Bellesqueak). For reference, see this earlier related thread: "Operating procedures for a "burn the diskpacks" list?" http://lists.squeakfoundation.org/pipermail/squeakfoundation/2001-June/0002… By the way, the earlier mailing list charter proposed there was reviewed by Richard Stallman and Eben Moglen (the FSF's lawyer) and the feeling was (like Cees said in that earlier thread) the best thing was to get people to sign papers initially or eventually, so I have added that provision in the charter below. The Bellesqueak mailing list charter is to be as follows: === The intent of the Bellesqueak list is to support a community process which creates, discusses, uses, and maintains a cross-platform computing environment and knowledge management system inspired by Squeak Smalltalk called Bellesqueak. The focus of Bellesqueak will be on transparency, robustness, and complexity management -- to support the doing of good deeds such as education, sustainable development, and ensuring humanity survives Vernor Vinge's Singularity in some form. The entire system will be built from the ground up in a public way, with all code for the core submitted through this Bellesqueak mailing list and subject to the Bellesqueak license. The license of all discussions and code contributions and other content made to this list will be under the modified BSD license without the advertising clause (so don't contribute postings or code here if you don't want your effort to be under this license or if they legally can't be put under this license). URL links posted to the list pointing to work under other licenses shall not be construed to mean those other works are under the Bellesqueak license, and it is acceptable on the list to discuss other works compatible with or derived from Bellesqueak, even if the other works themselves are not under the same license (remembering that all contributions to the list itself including such discussions are under the Bellesqueak license). At some point, significant contributors to this list may be asked to a sign a document along the lines stating their contributions are original (or otherwise made with permission) and are allowed by any employers and are submitted under this license, and at some point all future mailing list participants may be asked to sign such a document in order to contribute or continue contributing to the mailing list. To be clear, no code may be taken directly from Squeak and submitted to the Bellesqueak list without permission from the original authors to put it under the Bellesqueak license. Note that clearly defined modules developed by others under licenses easily compatible with the Bellesqueak license (like the MIT X license or in the public domain) may from time to time be accepted into the Bellesqueak project at the discretion of the community. Likewise, for scaffolding, Bellesqueak may at times rely on a variety of tools or libraries which may or may not be under the Bellesqueak license, and in those cases the licensing distinctions of such components must be clearly noted. For purposes of managing the future of Bellesqueak, I (Paul Fernhout) hereby declare myself "benevolent Beau for as long as I wish" :-) [For a definition of Beau see: http://www.ceder.net/def/beaubelle.php3 ] of the Bellesqueak community mailing list and claim ownership of the Bellesqueak trademark (like Linus Torvalds claims ownership of Linux) with my intent being to ensure the quality of whatever is called "Bellesqueak". Naturally, anyone may at any time take the contents of the Bellesqueak system or mailing list and, respecting the license, fork it under a new name if they have significantly divergent opinions of how it should proceed. The Bellesqueak code and posting reuse license text is as follows: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ==== FYI Bellesqueak's impetus relates to the "Belling the cat of complexity" thread: http://squeak.cs.uiuc.edu/mail/squeak/msg04562.html Please also note that for those wishing to deride this effort, feel free to call it "Paultalk". ;-) Also, I would appreciate it if discussion in this request thread confines itself to whether Cees or possibly by extension the Squeak Foundation should allow such a list to be made or supported based on the stated aims and the charter and license, as opposed to a discussion in and of themselves of the merit of the project, or the choice of license, or whether it is needed, or whether it will produce anything of value, etc. -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

7 12

Re: [Squeakfoundation]Brainstormin'
by goran.hultgren＠bluefish.se 29 Jan '02

29 Jan '02

Dan Ingalls <Dan(a)SqueakLand.org> wrote: [MEGA SNIP] > It's my hope that having a module system into the release will help greatly to reduce the conflicts currently inherent in satisfying different parts of our shared agenda. That's why I want to cut this short ;-) Yes, yes, yes! :-) When, how, where? We need a decision on this. Don't make me repeat what you said at OOPSLA... ;-) And all the decisions about the "image" that I snipped would become much easier to deal with when we have modules. Then I think SqF could have some kind of "voting process" or something in order to decide which modules should be marked as "base" modules. A proposal would be that a base module, in order to even be considerable as a base module, SHOULD minimally: 1. Be licensed under SqueakL (and possibly other licenses in parallell) 2. Have ONE person responsible as "custodian/maintainer/integrator" (as in Debian, personal responsibility is good). Associated helpers are of course welcome too. 3. Be able to coexist with all other base modules. You should be able to load a "full" base image with all the base modules. 4. Be available as official master from a central repository at SqF. 5. Follow the same versioning scheme that all other base modules follow. Whatever scheme that will be! Different schemes have been discussed in depth and Henrik has more details on different approaches. :-) ...anything else? regards, Göran

2 1

Re: [Squeakfoundation]New mailing list request for Bellesqueak (CSOTD included!)
by goran.hultgren＠bluefish.se 29 Jan '02

29 Jan '02

cg(a)home.cdegroot.com (Cees de Groot) wrote: > Given the fact that you're asking the SqF for resources, whazzisgottado with > Squeak, except from being inspired by it and stuff? I'm all in favor of > handing out mailing lists etcetera to anyone who does things that are > interesting (you might, for example, ask Cees de Groot instead of SqF), but > I'm not sure that your project is aligned with the stated goal of the SqF, and > therefore whether it is justifiable to burden future SqF administrators with > this project. > > What does the rest of the list think? Ok, a few simple personal points: 1. If SqF want's to be a good "buddy" with other projects that in some way touch upon Squeak then fine. But that would probably be something that SqF needs to declare openly as an intent. Of course, hosting a mailinglist is a small thing after all, so personally I am ok with it. 2. If Cees (in person) would like to be a good buddy then hey! Go ahead! :-) 3. If SqF for some reason thinks that this might be a project that Squeak can benefit from then I would like to remind you that GPL isn't "compatible" with SqueakL which means that "base Squeak" can not incorporate any code coming out from such a project into the Squeak image. I did not read Paul's postings in full detail so I might have missed something about his licensing strategy. But I think he clearly stated that he wanted to be able to "raid" both GPL and BSD based sources which would place "Bellesqueak" in GPL land without possibility of dual licensing (correct me if I am wrong). Do note though that this doesn't mean that applications written in a GPLd tool normally (depends on linking, and yes, given an image model like in Squeak an app might very well not be able to be GPLd) needs to be under GPL themselves. Well, just a few thoughts. And finally with a cherry smiley on top - there are too many words in these postings... Paul? Code talks. ;-) regards, Göran PS <CSOTD>"How to open up a workspace with text from a file (silly how long it took me to get this right):" (Workspace new contents: ((FileStream oldFileNamed: 'ws.txt') contentsOfEntireFile)) openLabel: 'My workspace' </CSOTD> DS

4 3

Re: [Squeakfoundation]New mailing list request for Bellesqueak (CSOTD included!)
by goran.hultgren＠bluefish.se 28 Jan '02

28 Jan '02

Bijan Parsia <bparsia(a)email.unc.edu> wrote: > --On Monday, January 28, 2002 10:27 AM +0100 goran.hultgren(a)bluefish.se > wrote: > > > Ok, a few simple personal points: > > > > 1. If SqF want's to be a good "buddy" > > Agreed. > > > 2. If Cees (in person) would like to be a good buddy then hey! Go ahead! > > :-) > > He's *my* good buddy :) > > > 3. If SqF for some reason thinks that this might be a project that > > Squeak can benefit from then I would like to remind you that GPL isn't > > "compatible" with SqueakL which means that "base Squeak" can not > > incorporate any code coming out from such a project into the Squeak > > image. > > This isn't true. They could dual licence. Since Paul seems intent on > getting clear title (or clear licencing) to incorporated code, there will > already be a mechanism for interacting with authors. Yes, dual licensing is a plausible way, as I also noted below. > > I did not read Paul's postings in full detail so I might have missed > > something about his licensing strategy. But I think he clearly stated > > that he wanted to be able to "raid" both GPL and BSD based sources which > > would place "Bellesqueak" in GPL land without possibility of dual > > licensing (correct me if I am wrong). > > Raided GPL code would need to go back to the original authors for > relicencing to get put in normal Squeak. Hmm. Only if you wanted to Yes. Here in lies the problem. "Raiding" sounded as being able to pick and not ask. If you need to ask for another license I would use another word. :-) > distribute it? There's no problem is you just want to load it up in your > own image. But that wouldn't help "base Squeak" as I called it. :-) Whatever, we are all in agreement I guess! > <CSOTD>"OK, I'm finalling doing one of these. This uses ImageSegments to > help figure out memory consumption of your objects:" > > String streamContents: [:strm | > (ImageSegment new copyFromRootsForExport: Browser allInstances) > printSpaceAnalysisOn: strm] > </CSOTD> Hehe! Go, go... regards, Göran

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation January 2002