I'm too happy to see Dave working on Self......
But I'm not to happy becouse I have not a SPARC, I have not a MAC.... :-(
Somebody is thinking in port Self 4.1 to Linux/i386 or Windows???
TIA,
(|diego. gomez. deck|)
Quick question:
Is there anything in Self like the Outliner but meant more for the end user? I'm thinking of something where you could enter new values directly into the data slots, instead of using the evaluator. It would provide different editors for different 'types' of slots, and would hide implementation details. For example, you would have a drop-down list of (Rigid, Flexible, Shrink-Wrap) instead of looking in the comments for useful values for hResizing.
I've looked at Properties a little, but it seems like I want more of a'different' outliner, possibly accessed by a toggle on the current outliner. I also don't want to build a separate interface morph for each object, I am impressed by the Outliner etc and think the system could do a very nice job on its own (which could later be customized by the user).
I don't want to stop the end user from 'getting under the hood' and actively changing the world, that after all is what Self is about. But I think it may be useful to have a "I'm Using this object" view of the outliner, and a "I'm mucking around under the hood" view as well. Think boring database type objects like an Employee or a Department, where you have lots of bits of mostly textual data.
I have more vaguely formed ideas about this which I would like to share for feedback, but I don't want to blather on about it if something like this already exists.
Thanks,
Jerry Bell
Great idea! No, I don't recall seeing this before. You might try asking Randy Smith (randy@eng.sun.com).
- Dave
At 9:43 PM -0600 11/8/99, Jerry Bell wrote:
Quick question:
Is there anything in Self like the Outliner but meant more for the end user? I'm thinking of something where you could enter new values directly into the data slots, instead of using the evaluator. It would provide different editors for different 'types' of slots, and would hide implementation details. For example, you would have a drop-down list of (Rigid, Flexible, Shrink-Wrap) instead of looking in the comments for useful values for hResizing.
I've looked at Properties a little, but it seems like I want more of a'different' outliner, possibly accessed by a toggle on the current outliner. I also don't want to build a separate interface morph for each object, I am impressed by the Outliner etc and think the system could do a very nice job on its own (which could later be customized by the user).
I don't want to stop the end user from 'getting under the hood' and actively changing the world, that after all is what Self is about. But I think it may be useful to have a "I'm Using this object" view of the outliner, and a "I'm mucking around under the hood" view as well. Think boring database type objects like an Employee or a Department, where you have lots of bits of mostly textual data.
I have more vaguely formed ideas about this which I would like to share for feedback, but I don't want to blather on about it if something like this already exists.
Thanks,
Jerry Bell
-- Talk to your group with your own voice! -- http://www.egroups.com/VoiceChatPage?listName=self-interest&m=1
David Ungar Sun Microsystems Laboratories (650) 336-2618
Jerry Bell wrote:
Quick question:
Is there anything in Self like the Outliner but meant more for the end user? I'm thinking of something where you could enter new values directly into the data slots, instead of using the evaluator. It would provide different editors for different 'types' of slots, and would hide implementation details. For example, you would have a drop-down list of (Rigid, Flexible, Shrink-Wrap) instead of looking in the comments for useful values for hResizing.
One problem is that slots aren't typed in this way. But you could work around this by using annotations.
I've looked at Properties a little, but it seems like I want more of a'different' outliner, possibly accessed by a toggle on the current outliner. I also don't want to build a separate interface morph for each object, I am impressed by the Outliner etc and think the system could do a very nice job on its own (which could later be customized by the user).
There are a lot of outliner-like things in Self. Most queries return an outliner which you "open" to get the answers. But when I tried to patch an outliner for a different application (showing a tree-like structure where the "leafs" where certain kinds of morphs - a kind of hierarchical factory window) I was a bit disapointed at how easy it was to mess everything up. But I would certainly encourage you to try to adapt it to your needs.
I don't want to stop the end user from 'getting under the hood' and actively changing the world, that after all is what Self is about. But I think it may be useful to have a "I'm Using this object" view of the outliner, and a "I'm mucking around under the hood" view as well. Think boring database type objects like an Employee or a Department, where you have lots of bits of mostly textual data.
Ok, so you don't want to create an EmployeeMorph. But is putting an outliner in the hands of the user a good idea? There might be some slots that you don't want them to see/change. And the layout of an outliner is a bit limiting - you might want to have some kind of universal formMorph object instead.
I have more vaguely formed ideas about this which I would like to share for feedback, but I don't want to blather on about it if something like this already exists.
Nothing that I remember.
-- Jecel
One problem is that slots aren't typed in this way. But you could work around this by using annotations.
I was thinking along the same lines... drop special formatting morphs on (default) fields of an auto-generated morph. It gives the desired editing behavior, and behind the scenes this is recorded in annotations on the slot, so that next time an editing morph is generated the desired behavior is still there. I haven't dug deeply enough yet - can you annotate an object with arbitrary objects, or is it less general?
You can then extend this to other useful things - validation rules(this value must be > 5 and < 25), triggers (do this when this value changes) etc, all of which work uniformly - you just drop stuff onto slots.
Ok, so you don't want to create an EmployeeMorph. But is putting an outliner in the hands of the user a good idea? There might be some slots that you don't want them to see/change. And the layout of an outliner is a bit limiting - you might want to have some kind of universal formMorph object instead.
This wouldn't be exactly like an outliner, but it would share the idea that the system is quite capable of building user interfaces for arbitrary objects on its own. Of course these things could then be modified by the programmer or user, and the system would remember the enhancements via annotations.
There are things you will want to hide from users, and even from other objects. Self does not enforce any privacy, right? So maybe one day it would be nice to have a general permissions/security system in Self.
Also, I looked at propertyMorph a little more. It looks like it requires an object to implement a couple of slots to support it, and the implementation of those slots is exactly the sort of boring, repetitive code that I would like to eliminate from my life. So maybe I'll work from there and get the objects to build those slots (or the equivalent) themselves.
I'm going to play around for a few weeks and see if I can do anything interesting. It should be a good way to learn the system - I can see myself getting my first taste of mirrors very very soon...
Jerry
Jerry Bell wrote:
I was thinking along the same lines... drop special formatting morphs on (default) fields of an auto-generated morph. It gives the desired editing behavior, and behind the scenes this is recorded in annotations on the slot, so that next time an editing morph is generated the desired behavior is still there. I haven't dug deeply enough yet - can you annotate an object with arbitrary objects, or is it less general?
In theory, you should be able to use arbitrary objects, but I would be surprised if there aren't at least some placed where strings are expected. Still, these strings are very flexible (very much like mail headers) and you might get by with them.
You can then extend this to other useful things - validation rules(this value must be > 5 and < 25), triggers (do this when this value changes) etc, all of which work uniformly - you just drop stuff onto slots.
In Squeak, there was an effort in this direction (making things happen by dropping objects on one another) called MophicWrappers (I can't find a page for it, but it is available at the MathMorphs page - http://mate.dm.uba.ar/~caniglia/mathMorphs.html).
And in the Alternate Reality Kit (the father of Self) you would drop buttons on objects to add funcionality to them.
There are things you will want to hide from users, and even from other objects. Self does not enforce any privacy, right? So maybe one day it would be nice to have a general permissions/security system in Self.
Self 1.0 to 2.0 had privacy declations for slots, but these didn't work out very well. The "Us" language (sorry, I don't have any details) had a way to allow multiple viewpoints on the same object, which would probably do what you want.
I'm going to play around for a few weeks and see if I can do anything interesting. It should be a good way to learn the system - I can see myself getting my first taste of mirrors very very soon...
And I need to do an accounting program as soon as possible. I will try to adapt an outliner to do this (so you can have nested accounts and only have to look at the ones you are interested in). I'll let you know how it turns out.
-- Jecel
I'm too happy to see Dave working on Self......
Me too.
But I'm not to happy becouse I have not a SPARC, I have not a MAC.... :-(
Somebody is thinking in port Self 4.1 to Linux/i386 or Windows???
At OOPSLA, I heard the rumor that there's a company actually interested in porting SELF for Windows and/or Linux.
bye -- Stefan // I can program the universe Matthias Aust // unless the power fails...
stefan matthias aust sm-@3plus4.de wrote: original article:http://www.egroups.com/group/self-interest/?start=395 ...
At OOPSLA, I heard the rumor that there's a company actually
interested in
porting SELF for Windows and/or Linux. bye -- Stefan // I can program the universe Matthias Aust // unless the power fails...
That would be very interesting. Anything more definite to the rumor (anyone?)? I, personally, would find Linux even more interesting than Windows, though either would be interesting. Wonder if it would run under Wine or Cygwin (depending on which was the native system)? (Or possibly VMWare?)
thorsten.dittmar@daedalos.com wrote:
stefan matthias aust wrote:
At OOPSLA, I heard the rumor that there's a company actually interested in porting SELF for Windows and/or Linux.
Hi, as you know ;-) it is not only a rumor. We are interested in a Self port to Linux (in the moment not Win NT). We want to have a closer look at Self. We are currently looking for a language and development environment that we can use to write an "ideal" multiuser ide.
I would say that the current "Kansas" GUI in Self is an excelent start. In the Squeak mailing list, Alan Kay said that John Maloney felt "relieved" to go back to the traditional browsers in Smalltalk. My experience is the exact opposite - after programming in Squeak for a while it is always pure joy to be back in Self. It is a matter of taste, I guess.
There are a lot of things in Self that makes quite interesting for us. So right now we try to find out what we must do to evaluate Self.
The best thing is to try it out on a high end Sparcstation. I haven't seen it on the Mac yet (but intend to really soon).
Maybe it is cheaper to port it to Linux instead of buy a lot of new machines.
Yes - that is the best option. But it is much harder to do the port if you don't have access to a working version (which is the case of some people on the list who have worked on a port so far).
If everything works fine we will invest some money in our Self development, but this is not sure now. We will have a lot of work to do before we can be sure that Self is the right language for our plans. For example our lawyer will contact Sun (in person David and his chief) to find out, if there are some foot traps for us in the license or not.
It just says:
LICENSE:
You may use the software internally, modify it, make copies and distribute the software to third parties, including redistribution for profit, provided each copy of the software you make contains the copyright notice set forth above, the disclaimer below, and the authorship attribution below.
I have looked at all the Open Source licenses out there and this is probably the simplest and least ambiguous of all (close to the BSD one).
And BTW there are also a lot of technical questions and we must find answers for this stuff.... so we will see cu
Here is the perfect place for it!
-- Jecel
Hi,
Jecel Assumpcao Jr wrote:
I would say that the current "Kansas" GUI in Self is an excelent start. In the Squeak mailing list, Alan Kay said that John Maloney felt "relieved" to go back to the traditional browsers in Smalltalk. My experience is the exact opposite - after programming in Squeak for a while it is always pure joy to be back in Self. It is a matter of taste, I guess.
As you may know Kent Beck worked for a long time in our company, so we have some kind of XP tradition here. This is the reason why I love the Refactoring Browser very much and small lint in some way too (have not so much eXPeriences with it;-). I'm one of the old (a 10 years fellowship now) square bracket knights and I really fall in love with this language, but one of the weaknesses of Smalltalk is the home is my castle stuff (the image and my team). Envy, Team/V etc. tried to fix this problem, but to fundamental problem is that the world of the programmer (his personal image), the world of the other programmers and the world of the user (the application) normally fit not very well together. Please don't miss understand me, the image is a beautiful place to program and a lovely place to modify your tools in a way how you want to have them, but is it also the right place for the application?
There are a lot of things in Self that makes quite interesting for us. So right now we try to find out what we must do to evaluate Self.
The best thing is to try it out on a high end Sparcstation. I haven't seen it on the Mac yet (but intend to really soon).
Maybe it is cheaper to port it to Linux instead of buy a lot of new machines.
Yes - that is the best option. But it is much harder to do the port if you don't have access to a working version (which is the case of some people on the list who have worked on a port so far).
That is true. When I understand the situation correctly, there is a port for linux from Gordon. It is not finished, but maybe we find a way altogether to help him. It would be a big step for Self. If there is no other way we would try the mac port (a power book is a little bit cheaper then a sparc)
If everything works fine we will invest some money in our Self development, but this is not sure now. We will have a lot of work to do before we can be sure that Self is the right language for our plans. For example our lawyer will contact Sun (in person David and his chief) to find out, if there are some foot traps for us in the license or not.
It just says:
LICENSE:
You may use the software internally, modify it, make copies and distribute the software to third parties, including redistribution for profit, provided each copy of the software you make contains the copyright notice set forth above, the disclaimer below, and the authorship attribution below.
I have looked at all the Open Source licenses out there and this is probably the simplest and least ambiguous of all (close to the BSD one).
That is true. But maybe not enough, we will see. It depends hardly on our future plans.
And BTW there are also a lot of technical questions and we must find answers for this stuff.... so we will see cu
Here is the perfect place for it!
I hope so.
Thorsten Dittmar
Hi Thorsten,
you made a lot of good points in your last posting. I would like to add the following:
In the meantime, I got access to an ancient sparc station 10. (BTW, how do I find out how much memory it has?). I also tried to download Self 4.1 last week which did not work then.
I appreciate your commitment to Self very much. Thank you for considering supporting its further development. Please consider instead of buying a small machine on which Self already runs, buying a powerful machine for compiling the system. When I was developing on Self for Linux I pretty much overcame already the stage where I would have needed a running system for reference. Thanks to Mario's book on Sparc, I was able to figure out what's happening inside to the appropriate extent. It bugged me much more that I got really long turnaround times when recompiling the Self VM. Whenever I changed something in a header file which occurred quite frequently, I got to wait for half an hour to an hour to recompile. It takes already nearly ten minutes to load Self's symbol table into the debugger. I already upgraded my memory from 64M to 128M last January which helped a lot, nevertheless my working on Self was still strongly limited by compilation speed. Self has even a sophisticated environment for doing parallel compiles which I unfortunately had not the pleasure to take advantage of.
IMHO, doing a Linux/i386 port of Self is particularly good coice because 1) Virtually everybody can install Linux on her PC and use Self. At most she has to buy a new harddisk but not a new Computer. 2) Linux users are the right audience for Self at the current stage because they tend to have a deeper technical knowledge and can track down and fix problems by themselves. Usually, Linux users have much less inhibitions to use a debugger than Windows or Mac users.
Torsten, it would be a pleasure to meet you in person.
Gordon.
Hi,
gordon cichon gordo-@cichon.de wrote: original article:http://www.egroups.com/group/self-interest/?start=418
IMHO, doing a Linux/i386 port of Self is particularly good coice because
- Virtually everybody can install Linux on her PC and use Self.
At most she has to buy a new harddisk but not a new Computer. 2) Linux users are the right audience for Self at the current stage because they tend to have a deeper technical knowledge and can track down and fix problems by themselves. Usually, Linux users have much less inhibitions to use a debugger than Windows or Mac users.
Torsten, it would be a pleasure to meet you in person.
So what can we do? I have one maybe crazy idea, but maybe it is useful to push the linux port. We can invent a self weekend in our rooms for everybody who want to join us. We will take care for machines, food and a place to sleep and every participant take care for his knowledge and brilliance ;-)
What do you think about this?
Thorsten Dittmar
PS: This Millenium would be very nice, or not?
On Wed, 17 Nov 1999, Thorsten Dittmar wrote:
gordon cichon gordo-@cichon.de wrote:
IMHO, doing a Linux/i386 port of Self is particularly good coice because
- Virtually everybody can install Linux on her PC and use Self.
At most she has to buy a new harddisk but not a new Computer. 2) Linux users are the right audience for Self at the current stage because they tend to have a deeper technical knowledge and can track down and fix problems by themselves. Usually, Linux users have much less inhibitions to use a debugger than Windows or Mac users.
Torsten, it would be a pleasure to meet you in person.
So what can we do? I have one maybe crazy idea, but maybe it is useful to push the linux port. We can invent a self weekend in our rooms for everybody who want to join us. We will take care for machines, food and a place to sleep and every participant take care for his knowledge and brilliance ;-)
What do you think about this?
Thorsten Dittmar
PS: This Millenium would be very nice, or not?
YES!!!!! Great idea! :-))))))))
We could set up a cluster for *fast* VM compilation :-)
Let's not do Millenium for it. I gave a promise not to touch any computer and not to use any computer dependent services on 1th January 2000. Let's say either 8th-9th or 15th-16th of January.
Gordon.
Hi,
From: Gordon Cichon [mailto:gordon@cichon.de]
So what can we do? I have one maybe crazy idea, but maybe
it is useful
to push the linux port. We can invent a self weekend in our
rooms for
everybody who want to join us. We will take care for
machines, food and
a place to sleep and every participant take care for his
knowledge and
brilliance ;-)
What do you think about this?
Thorsten Dittmar
PS: This Millenium would be very nice, or not?
YES!!!!! Great idea! :-))))))))
We could set up a cluster for *fast* VM compilation :-)
Let's not do Millenium for it. I gave a promise not to touch any computer and not to use any computer dependent services on 1th January 2000. Let's say either 8th-9th or 15th-16th of January.
This dates are a little bit difficult for me.
From the 6-8 we have our international meeting and a Y2K party. On the 15th
my daughter celebrate her birthday party. What do you think about some days between 8-12. December. If this does not works I can try to reorganize the 9th-11th weekend. What a kind of hardware and software do we need? How many people what to join us? Is there somebody from the other side of the sea who want to join us??
Thorsten
Thorsten Dittmar wrote:
[We can invent a self weekend in our rooms]
my daughter celebrate her birthday party. What do you think about some days between 8-12. December. If this does not works I can try to reorganize the 9th-11th weekend. What a kind of hardware and software do we need? How many people what to join us? Is there somebody from the other side of the sea who want to join us??
If it's nearby, I'd love to join you. Although - from his webpage, I'd guess that Gordon is located in Munich while I'm at home right on the other side of Germany, Kiel. So Thorsten, where should we meet? I think, you're located in Düsseldorf, aren't you? What's about Hamburg - didn't have Daedalos an office there, too? ;-)
bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.
hi all,
stefan matthias aust sm-@3plus4.de wrote: original article:http://www.egroups.com/group/self-interest/?start=441
If it's nearby, I'd love to join you. Although - from his webpage,
I'd
guess that Gordon is located in Munich while I'm at home right on the
other
side of Germany, Kiel. So Thorsten, where should we meet? I think,
you're
located in Düsseldorf, aren't you? What's about Hamburg - didn't have Daedalos an office there, too? ;-)
not now, but if you know some good employees it is maybe a good idea :-)) I worked for more then 2 years in Hamburg and I enjoyed the time very much. But BTW my idea was to invent our meeting hear in Witten what is near to Duesseldorf (Hamburg HBF to Witten HBF 2:15 Hours). The reason for this is the infrastructur here. I got a mac yesterday and I think we will have some sun here in january and we have already some linux machines here.
Thorsten
I am sorry to have to miss this, but could work something out to be available by telephone if it would be helpful.
- Dave
At 1:11 PM +0100 11/18/99, Thorsten Dittmar wrote:
Hi,
From: Gordon Cichon [mailto:gordon@cichon.de]
So what can we do? I have one maybe crazy idea, but maybe
it is useful
to push the linux port. We can invent a self weekend in our
rooms for
everybody who want to join us. We will take care for
machines, food and
a place to sleep and every participant take care for his
knowledge and
brilliance ;-)
What do you think about this?
Thorsten Dittmar
PS: This Millenium would be very nice, or not?
YES!!!!! Great idea! :-))))))))
We could set up a cluster for *fast* VM compilation :-)
Let's not do Millenium for it. I gave a promise not to touch any computer and not to use any computer dependent services on 1th January 2000. Let's say either 8th-9th or 15th-16th of January.
This dates are a little bit difficult for me.
From the 6-8 we have our international meeting and a Y2K party. On the 15th
my daughter celebrate her birthday party. What do you think about some days between 8-12. December. If this does not works I can try to reorganize the 9th-11th weekend. What a kind of hardware and software do we need? How many people what to join us? Is there somebody from the other side of the sea who want to join us??
Thorsten
Increase your sales during the Holiday Season-Get a FREE ShopNow.com Premier Merchant Listing with your discounted purchase of the Virtual Gift Basket Listing. http://clickhere.egroups.com/click/1752
-- Easily schedule meetings and events using the group calendar! -- http://www.egroups.com/cal?listname=self-interest&m=1
David Ungar Sun Microsystems Laboratories (650) 336-2618
Hi, guys!
1. Is anyone having problems with Self 4.1.1 on SPARC? I had one report of difficulty, which I could not reproduce. As far as I know, it should work fine.
2. Compilation is pretty slow on SPARC. It is much faster under Metrowerks, or any other environment supporting precompiled header files (such as Visual C++). On my Powerbook, the whole VM recompiles in about 3 minutes.
- Dave
At 11:32 AM +0100 11/17/99, Gordon Cichon wrote:
Hi Thorsten,
you made a lot of good points in your last posting. I would like to add the following:
In the meantime, I got access to an ancient sparc station 10. (BTW, how do I find out how much memory it has?). I also tried to download Self 4.1 last week which did not work then.
I appreciate your commitment to Self very much. Thank you for considering supporting its further development. Please consider instead of buying a small machine on which Self already runs, buying a powerful machine for compiling the system. When I was developing on Self for Linux I pretty much overcame already the stage where I would have needed a running system for reference. Thanks to Mario's book on Sparc, I was able to figure out what's happening inside to the appropriate extent. It bugged me much more that I got really long turnaround times when recompiling the Self VM. Whenever I changed something in a header file which occurred quite frequently, I got to wait for half an hour to an hour to recompile. It takes already nearly ten minutes to load Self's symbol table into the debugger. I already upgraded my memory from 64M to 128M last January which helped a lot, nevertheless my working on Self was still strongly limited by compilation speed. Self has even a sophisticated environment for doing parallel compiles which I unfortunately had not the pleasure to take advantage of.
IMHO, doing a Linux/i386 port of Self is particularly good coice because
- Virtually everybody can install Linux on her PC and use Self.
At most she has to buy a new harddisk but not a new Computer. 2) Linux users are the right audience for Self at the current stage because they tend to have a deeper technical knowledge and can track down and fix problems by themselves. Usually, Linux users have much less inhibitions to use a debugger than Windows or Mac users.
Torsten, it would be a pleasure to meet you in person.
Gordon.
Need a cure for the used car blues? iMotors pre-owned cars are: priced below Blue Book; fully tested & certified; & carry a 7 day/700 mile money back guarantee. Look no further iMotors.com is here! http://clickhere.egroups.com/click/1535
-- 20 megs of disk space in your group's Document Vault -- http://www.egroups.com/docvault/self-interest/?m=1
David Ungar Sun Microsystems Laboratories (650) 336-2618
Thorsten Dittmar wrote:
[.....] Please don't miss understand me, the image is a beautiful place to program and a lovely place to modify your tools in a way how you want to have them, but is it also the right place for the application?
David Ungar put a lot of effort into the "transporter" in Self 4.0, and the Squeak people have just created "image segments" and are working on "project layers". Other Smalltalks have tried various things in the past: Jigsaw/parcels, .dll and .exe files and so on.
So I think there is a general agreement that we need something better than image+fileIns to distribute applications.
Some (rather outdated) thought I had on this subject are at:
http://www.lsi.usp.br/~jecel/persist.html
-- Jecel
So I think there is a general agreement that we need something better than image+fileIns to distribute applications.
Yes, yes, yes!
I'd like to work in an image which can be snapshotted. This saves a great deal of time. But I need a way to reconstruct everything everytime. I like the idea of workspaces (or project layers or environment whatever) which can share some objects but cannot modify itself. You might even use this for multiuser access rights. I also really like to be able to bootstrap a Self-image from nearly nothing (my system doesn't have mirrors, so I need only the lobby with nil, true, false to be hardcoded in the VM).
bye -- Stefan // I can program the universe Matthias Aust // unless the power fails...
On Tue, 16 Nov 1999, Jecel Assumpcao Jr wrote:
It just says:
LICENSE:
You may use the software internally, modify it, make copies and distribute the software to third parties, including redistribution for profit, provided each copy of the software you make contains the copyright notice set forth above, the disclaimer below, and the authorship attribution below.
I have looked at all the Open Source licenses out there and this is probably the simplest and least ambiguous of all (close to the BSD one).
Hi Jecel,
I just would like to say a few words about licensing:
There is this dicussion going on whether BSD or GPL licenses are better. This is a very broad discussion in the mean time, and there are lots of contributions to it which are far too many that I could repeat them all at this place.
I have been urged by several members of this mailing list to release Self for Linux under a BSD style license which I could not do in this case anyway because my distribustion contains gas, the GNU assembler which needs to be redistributed under GPL anyway.
Self at the current point does not have any economical importance. There is hardly anybody willing to spend money on Self today. There are hardly a few dozens of Self users today.
Nevertheless, what we share in this mailing list is the opinion that Self is a good idea. So, how could we get other people to jump onto that train and also use Self despite all the imperfectness that this system still has at present time?
I think, that we only have a chance if we work together more closely. IMHO, it does not make sense to reinvent the wheel every time over and over again. Remember, that has been told to be one of the big advantages of OO programming not having to start over from scratch every time again. So there are more than five incomplete approaches for Self implementations. What a waste of our sparse development capacity!
So, what is the difference between BSD, and GPL license? The main one for me is that a BSD license allows anybody to discontinue the free development, and make a commercial product from it without including the contributors.
Who would prevent someone coming up with a proprietary, closed Self release if Self was distributed under BSD license? When I read about your past plans for a OO "billing infrastructure", I got scary that next year I would be going to be charged for using my own code. This plan was a nightmare for privacy. And a BSD license would allow anyone to implement it.
And, I know for sure that a closed Self is not going to be a commercial success, unless your name is Microsoft. Even Sun seems to have dropped Self in favor of Java.
So, why do you need a BSD license if you like to keep Self open anyway?
Gordon.
Gordon Cichon made several wonderful comments about licensing issues and the madness of many parallel implementation efforts.
I was just commenting on the current Self 4.1 license and telling Thorsten that I can imagine no restrictions that his lawyers might complain about no matter what he intends to do with it. It even allows you to redistribute it under the GPL if you like!
When Richard Stallman first proposed the GNU project, I had already been thinking about these issues for a few years. One thing that is clear is that not everything that is legal is practical. Take the Squeak license as an example. It makes you release any modifications you make to the base system, but you can develop applications on top of it and keep the sources to yourself. Given the recent confusion about Win98/IE you might imagine what an interesting task determining where a Smalltalk ends and where an application begins will be. What happens in practice? If you release a modification to the Squeak base but it doesn't get officially adopted by the Disney people, nobody will actually use it since they will have to file it in again for each new release and you won't have time to handle the ever increasing conflicts that will crop up. In the end, even you will give up on using it and will migrate to whatever the Disney people officially adopted. So even if the license didn't make you release your changes, your only hope of making long term use of it is to release it *and* get it adopted into the official distribution.
So that (GPL-like) clause in the Squeak license has a great potential for confusion and will make someone considering commercial use of the system worried, but currently offers no real protection. That could change with improved distribution technology (breaking up the image into independent packages) or if it got adopted by someone with as much charisma as the Disney team (a Microsoft Squeak might be taken more seriously, for example) so the present complications might be worth the future protection.
I am thinking about adopting the current Self license for my own releases and hope that in practice it will be good enough. Note that I still intend to make a billing infrastructure available. If someone wants to release something without the source and/or charge for it, they should be able to. I will strongly discourage it (by my own example in my code and by always choosing to use free alternatives of other people's software) but it should be their choice. Yes, there is a serious privacy problem in this design - you have to trust the billing company. I don't see how you could end up being charged for using your own code, though.
About working together, this is a key issue. I find it funny when people say "who could have imagined that a bunch of students could create a full Unix clone" as they admire Linux. There were *many* Unix clones written in the 80s and the early 90s. The problem is that every effort did everything: the kernel, ls, grep, vi and so on. So all ended up dying before they were really usable or they were finished but never widely released. The danger that Self might follow the path of all these failed clones is very clear.
In a way, the situation today is better than it has ever been. In the past, people would look at Self and say "great idea - I'll make my next language like this!". So we got Kevo, NewtonScript, Omega, GlyphicScript, Moostrap and a bunch of others you never heard of (including my recently ressurected NeoLogo). Now we are saying "what a great idea - I'll make my own version of Self so it will run on the machines we have". So we see OpenSelf, JSelf, Self/R, mySelf and... any others? At least in your attempt to port Self 4.0, you were not "forking" the project.
One problem with the Sun Self is that it is much more like the Mozilla project than Linux. It was worked on by a small group and then unleased on the world as a very large piece of code. The effort for outsiders to understand enough of it to actually make significant changes is very great (since you didn't "grow up with the code" like the original team did). Squeak avoided this fate simply by being much smaller, since it was released in the same way as Self.
I hope I have convinced you that I agree with you that Self/R is a bad idea in nearly all regards. But I feel very strongly that the large amount of things that are done in C++ in the Sun Self is what is holding it back. The X Window problems are an example of that. My own network problems are another example (I found the bug, but was way too lazy to recompile the VM). In fact, while the Squeak way of writing things in Smalltalk and translating them to C and using an external compiler to get actual machine code is better, it still is what is holding Squeak back. Self 4 proves that Self code that be translated into good enough machine code, so I don't think we will have real progress until our Self is *in* Self. So that is what I am working on.
A port of Self 4.1 to Linux PC or Windows would really help me since people who are waiting for me to finish Self/R (there are some :-) would have a way to start coding and learning as soon as possible. I am willing to be convinced that I am wrong about what I wrote in the previous paragraph. If somebody can do that, then I'll joing the x86 porting effort and we can work together. How do other people feel about what Gordon has written?
-- Jecel
On Wed, 17 Nov 1999, Jecel Assumpcao Jr wrote:
One problem with the Sun Self is that it is much more like the Mozilla project than Linux. It was worked on by a small group and then unleased on the world as a very large piece of code. The effort for outsiders to understand enough of it to actually make significant changes is very great (since you didn't "grow up with the code" like the original team did). Squeak avoided this fate simply by being much smaller, since it was released in the same way as Self.
Hi Jecel,
first one last comment on licensing: The main difference between BSD and GPL licenses on the one side, and things like the Mozilla license, the Apple license, and Suns license is that contributors are not peers is the latter case. In this sense, the Self license is much superior to the license of Squeak and Mozilla.
I hope I have convinced you that I agree with you that Self/R is a bad idea in nearly all regards. But I feel very strongly that the large amount of things that are done in C++ in the Sun Self is what is holding it back. The X Window problems are an example of that. My own network problems are another example (I found the bug, but was way too lazy to recompile the VM). In fact, while the Squeak way of writing things in Smalltalk and translating them to C and using an external compiler to get actual machine code is better, it still is what is holding Squeak back. Self 4 proves that Self code that be translated into good enough machine code, so I don't think we will have real progress until our Self is *in* Self. So that is what I am working on.
Yes, I absolutely agree with you. Let me point out that I am not tied to porting Sunlabs Self to Linux unconditionally. Once, I offered my help to the Java/Self guys and to abandon Self/Linux in favor of it. They were not interested in cooperating with me and I did not get an answer from them. Nevertheless, if we could agree on a way to proceed, I would certainly adapt my own effort to support it.
I agree with you that the best implementation of Self would be in Self. But what exactly is Self? For me, Self is more than this angle-bracket-thing. You also defined some extensions to the Self language. I think Self is not well-defined enough to do an implementation in itself now. Ideally, at least SIC should be implemented in Self.
I think, this is logically the next step at the implementation side to lay down a framework onto which optimized compilers for different architectures can be plugged in. Just like GCC has its framework, Self could have its own, too.
It would be a nice thing to "squeakify" Self, but please correct me if I'm wrong, a squeakified Self would run so slowly that the UI would be completely unuseable. And this Mango stuff is IMO exactly the right stuff to play around extending Self grammar and semantics. I would like to keep this stuff going, and not to break it. Say, if you had an arbitrary slow interpreter of Self, say written in perl, you would find it pretty difficult if not impossible to write demanding code with it without UI. The Self language gives you so much freedom that you are completely lost without a user interface that guides you through the process.
And, IMHO I think, what holds back Squeak is that it is too old and too late, and it is not even free software. Come on, this is just another implemenation of Smalltalk-80. They are even proud of not being integrated into an windowing system. Who is today going to deploy an application that is not integrated into the windowing system?
I think, Smalltalk could have played the role that Windows plays today, i.e. the integrating framework for different applications that run on a virtual machine if ParcPlace hadn't been so jealous about its licensing policy. If they had sold Smalltalk-80 for 50 bugs, people would have used it, just like they used Windows. But that opportunity is over for a long time already. Any OO environment that likes to be used by the people must have 1) a social licensing policy, and 2) a social environment. It has to integrate into its host environment, window system, operating system, and other object models. The time of autism is over and it won't come back.
Gordon.
Gordon,
It sounds like there may have been a misunderstanding--
At 5:16 PM +0100 11/17/99, Gordon Cichon wrote:
Once, I offered my help to the Java/Self guys and to abandon Self/Linux in favor of it. They were not interested in cooperating with me and I did not get an answer from them.
If you feel that you have been rebuffed by us, that was certainly never our intention.
- Dave
At 5:16 PM +0100 11/17/99, Gordon Cichon wrote:
On Wed, 17 Nov 1999, Jecel Assumpcao Jr wrote:
One problem with the Sun Self is that it is much more like the Mozilla project than Linux. It was worked on by a small group and then unleased on the world as a very large piece of code. The effort for outsiders to understand enough of it to actually make significant changes is very great (since you didn't "grow up with the code" like the original team did). Squeak avoided this fate simply by being much smaller, since it was released in the same way as Self.
Hi Jecel,
first one last comment on licensing: The main difference between BSD and GPL licenses on the one side, and things like the Mozilla license, the Apple license, and Suns license is that contributors are not peers is the latter case. In this sense, the Self license is much superior to the license of Squeak and Mozilla.
I hope I have convinced you that I agree with you that Self/R is a bad idea in nearly all regards. But I feel very strongly that the large amount of things that are done in C++ in the Sun Self is what is holding it back. The X Window problems are an example of that. My own network problems are another example (I found the bug, but was way too lazy to recompile the VM). In fact, while the Squeak way of writing things in Smalltalk and translating them to C and using an external compiler to get actual machine code is better, it still is what is holding Squeak back. Self 4 proves that Self code that be translated into good enough machine code, so I don't think we will have real progress until our Self is *in* Self. So that is what I am working on.
Yes, I absolutely agree with you. Let me point out that I am not tied to porting Sunlabs Self to Linux unconditionally. Once, I offered my help to the Java/Self guys and to abandon Self/Linux in favor of it. They were not interested in cooperating with me and I did not get an answer from them. Nevertheless, if we could agree on a way to proceed, I would certainly adapt my own effort to support it.
I agree with you that the best implementation of Self would be in Self. But what exactly is Self? For me, Self is more than this angle-bracket-thing. You also defined some extensions to the Self language. I think Self is not well-defined enough to do an implementation in itself now. Ideally, at least SIC should be implemented in Self.
I think, this is logically the next step at the implementation side to lay down a framework onto which optimized compilers for different architectures can be plugged in. Just like GCC has its framework, Self could have its own, too.
It would be a nice thing to "squeakify" Self, but please correct me if I'm wrong, a squeakified Self would run so slowly that the UI would be completely unuseable. And this Mango stuff is IMO exactly the right stuff to play around extending Self grammar and semantics. I would like to keep this stuff going, and not to break it. Say, if you had an arbitrary slow interpreter of Self, say written in perl, you would find it pretty difficult if not impossible to write demanding code with it without UI. The Self language gives you so much freedom that you are completely lost without a user interface that guides you through the process.
And, IMHO I think, what holds back Squeak is that it is too old and too late, and it is not even free software. Come on, this is just another implemenation of Smalltalk-80. They are even proud of not being integrated into an windowing system. Who is today going to deploy an application that is not integrated into the windowing system?
I think, Smalltalk could have played the role that Windows plays today, i.e. the integrating framework for different applications that run on a virtual machine if ParcPlace hadn't been so jealous about its licensing policy. If they had sold Smalltalk-80 for 50 bugs, people would have used it, just like they used Windows. But that opportunity is over for a long time already. Any OO environment that likes to be used by the people must have 1) a social licensing policy, and 2) a social environment. It has to integrate into its host environment, window system, operating system, and other object models. The time of autism is over and it won't come back.
Gordon.
Need a cure for the used car blues? iMotors pre-owned cars are: priced below Blue Book; fully tested & certified; & carry a 7 day/700 mile money back guarantee. Look no further iMotors.com is here! http://clickhere.egroups.com/click/1535
-- Easily schedule meetings and events using the group calendar! -- http://www.egroups.com/cal?listname=self-interest&m=1
David Ungar Sun Microsystems Laboratories (650) 336-2618
On Wed, 17 Nov 1999, David Ungar wrote:
It sounds like there may have been a misunderstanding-- At 5:16 PM +0100 11/17/99, Gordon Cichon wrote:
Once, I offered my help to the Java/Self guys and to abandon Self/Linux in favor of it. They were not interested in cooperating with me and I did not get an answer from them.
If you feel that you have been rebuffed by us, that was certainly never our intention.
Dave,
no, that was absolutely not the point with it. :-) This was at an very early stage of the Linux port when I did not yet even know you. I think it was the first week of January or so.
I just wanted to do something useful, and at this time, I did not know exactly what this could be. I think, Self on Java is a good idea (especially on Hotspot :-), albeit much more difficult to get the OS environment up again), and I wanted to stay on focus within the Self effort.
To state my point more clearly: We need more focus and do one step after another, helping each other and not every single person to do just her single project only.
Gordon.
Thanks for the clarification and reassurance, Gordon. Your point is well taken.
- Dave
At 7:50 AM +0100 11/18/99, Gordon Cichon wrote:
On Wed, 17 Nov 1999, David Ungar wrote:
It sounds like there may have been a misunderstanding-- At 5:16 PM +0100 11/17/99, Gordon Cichon wrote:
Once, I offered my help to the Java/Self guys and to abandon Self/Linux in favor of it. They were not interested in cooperating with me and I did not get an answer from them.
If you feel that you have been rebuffed by us, that was certainly never our intention.
Dave,
no, that was absolutely not the point with it. :-) This was at an very early stage of the Linux port when I did not yet even know you. I think it was the first week of January or so.
I just wanted to do something useful, and at this time, I did not know exactly what this could be. I think, Self on Java is a good idea (especially on Hotspot :-), albeit much more difficult to get the OS environment up again), and I wanted to stay on focus within the Self effort.
To state my point more clearly: We need more focus and do one step after another, helping each other and not every single person to do just her single project only.
Gordon.
Increase your sales during the Holiday Season-Get a FREE ShopNow.com Premier Merchant Listing with your discounted purchase of the Virtual Gift Basket Listing. http://clickhere.egroups.com/click/1752
-- Check out your group's private Chat room -- http://www.egroups.com/ChatPage?listName=self-interest&m=1
David Ungar Sun Microsystems Laboratories (650) 336-2618
Gordon Cichon wrote:
Yes, I absolutely agree with you.
Oh. That means I will have to actually sit down and program what I have been promising all these years.
My sister has decided to use my system in her PhD project, which will have a group of high school students programming a simulation. So I had better have *some* Self running on Windows PCs by March or nasty things begin to happen.
I agree with you that the best implementation of Self would be in Self. But what exactly is Self? For me, Self is more than this angle-bracket-thing. You also defined some extensions to the Self language. I think Self is not well-defined enough to do an implementation in itself now. Ideally, at least SIC should be implemented in Self.
I have played around with some extensions (extra bytecodes for writing portable primitives, parallelism in tinySelf 1) but that doesn't mean Self 4.0 can't implement itself as it is. We need at least the NIC implemented - the Mac port shows we can get by without the SIC for a while. For those on the list not familiar with these terms, NIC is the simple compiler that generates slow code and the SIC is the more complex one that generates faster code.
I think, this is logically the next step at the implementation side to lay down a framework onto which optimized compilers for different architectures can be plugged in. Just like GCC has its framework, Self could have its own, too.
Exactly. I was looking at Ian Piumarta's paper at the VM workshop (http://www.squeak.org/oopsla99_vmworkshop/) but don't feel that is the way to go. I once saw a generic compiler backend written in C++ once that was very nice: the main classes would define everything in terms of abstract methods (generateJump(), for example) and then each CPU would get a subclass that would fill in the details be overriding these methods. Not as elegant as a declarative approach like the GCC, but it does get the job done simply and very effectively.
It would be a nice thing to "squeakify" Self, but please correct me if I'm wrong, a squeakified Self would run so slowly that the UI would be completely unuseable.
I don't know what you mean by "squeakify". If you mean to an interpreter in Self and translate it to C, you are right. It would be much worse than Squeak, in fact, unless we added some bytecodes or did a compilation to threaded code.
I want a NIC in Self that spits out X86 instructions. We can always worry about PPC/Sparc/ARM/MIPS at some unspecified date in the future :-)
And this Mango stuff is IMO exactly the right stuff to play around extending Self grammar and semantics. I would like to keep this stuff going, and not to break it. Say, if you had an arbitrary slow interpreter of Self, say written in perl, you would find it pretty difficult if not impossible to write demanding code with it without UI. The Self language gives you so much freedom that you are completely lost without a user interface that guides you through the process.
From my experience with tinySelf, things can get out of hand even
in the Self environment. But I got ten times further than in C/gdb before I ever ran into trouble. Using anything other than Self 4 for developement makes no sense (except if you are working on a port because you don't have where to run Self 4...).
But I see no need to extend the Self grammar (though we do need a parser in Self, among other things).
And, IMHO I think, what holds back Squeak is that it is too old and too late, and it is not even free software. Come on, this is just another implemenation of Smalltalk-80. They are even proud of not being integrated into an windowing system. Who is today going to deploy an application that is not integrated into the windowing system?
True, but they have their reasons and they did more than I expected on such a weak base. Now that they have created a motivated group, they are trying to go back and fix the implementation. It seems to be working.
I think, Smalltalk could have played the role that Windows plays today, i.e. the integrating framework for different applications that run on a virtual machine if ParcPlace hadn't been so jealous about its licensing policy.
There was Smalltalk/V (16 bit DOS) and the Tektronix 4004 ($15K). And I feel guilty about this as well since we could have finished the Merlin 2 by the end of 1987.
If they had sold Smalltalk-80 for 50 bugs, people would have used it, just like they used Windows.
No, Windows has much more than 50 *bugs* :-) :-)
But that opportunity is over for a long time already.
Linux proved that the OS wars can be restarted after everyone is sure they are dead.
Any OO environment that likes to be used by the people must have 1) a social licensing policy, and 2) a social environment. It has to integrate into its host environment, window system, operating system, and other object models. The time of autism is over and it won't come back.
I have some ideas about that. The first thing is to be able to map any morph to an OS window, not just worldMorphs. When you choose "move to own window", your application looks nice. But one wrong move of the mouse and suddenly half of it is gone and there is a big white area in the window. Morphs in MVC windows in Squeak have this exact same problem.
Another thing that might help Self feel more native would be to move the objects picked up by the hand to their own window on those window managers that support frameless windows. It could be made to look like it does now, except that the objects you are holding can go beyond the borders of the world you are over. Imagine dragging something from a factory window to a world when the windows are far apart to see what I mean.
So I want integration with the OS, but I want to allow Self to be the OS when it needs to (like on the machines I am building). Why do we have to choose one or the other? Oberon has both and so can we.
-- Jecel
The time of autism is over and it won't come back.
I agree.
But there's a small change for another way: embrace and extend.
Perhaps somebody knows Staroffice (from StarDivison, a German software company recently aquired by Sun)? They've a desktop which best runs fullscreen on your computer that contains everything. Now, it doesn't try to reinvent everything but actually copies and imitates the Windows start menu and the taskbar and integrates existing applications seemlessly into their desktop.
Quite a big amount of work - but at least, I'm sure some people like it or otherwise they didn't have done it. And you can always go back to normal, MS Office compatible MDI applications.
I know there're quite a few Windows shell replacement projects out there where people try to imitiate the freedom of choice you got on X with different window managers. LiteStep, one of the most popular replacements, I believe, also has a scripting language. This could, of course, also be Self, couldn't it?
But then, there's the problem, integrating with your host opration system normally works against platform independence.
bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.
Hi
From: Stefan Matthias Aust [mailto:sma@3plus4.de]
But then, there's the problem, integrating with your host opration system normally works against platform independence.
What exactly means platform independence? The different levels of independence produce a quite different amount of work and complexity. And why is platform dependence a question of the language? Yes we need something to run our development environment on a lot of different platforms, but to integrate host windows, av stuff etc. in a application has nothing to do with our language. So what we need is a general mechanism to make all this platform dependent stuff accessible for the development environment. If somebody need a native widget, it must be able for him to develop some objects to adapt this in a straight forward way.
Thorsten
On Thu, 18 Nov 1999, Jecel Assumpcao Jr wrote:
It would be a nice thing to "squeakify" Self, but please correct me if I'm wrong, a squeakified Self would run so slowly that the UI would be completely unuseable.
I don't know what you mean by "squeakify". If you mean to an interpreter in Self and translate it to C, you are right. It would be much worse than Squeak, in fact, unless we added some bytecodes or did a compilation to threaded code.
I think, the biggest adavantage of a Self interpreter would be that Self would simply run in the first place. We could then put a sophisticated compiler framework on top of it which could bootstrap itself using this interpreter.
I want a NIC in Self that spits out X86 instructions. We can always worry about PPC/Sparc/ARM/MIPS at some unspecified date in the future :-)
That's exaclty what I wanted to accomplish in Self for Linux. :-)
I think, Smalltalk could have played the role that Windows plays today, i.e. the integrating framework for different applications that run on a virtual machine if ParcPlace hadn't been so jealous about its licensing policy.
There was Smalltalk/V (16 bit DOS) and the Tektronix 4004 ($15K). And I feel guilty about this as well since we could have finished the Merlin 2 by the end of 1987.
;-)
If they had sold Smalltalk-80 for 50 bugs, people would have used it, just like they used Windows.
No, Windows has much more than 50 *bugs* :-) :-)
I was meaning Smalltalk for $50. Preinstalled, and with a word processor. That could have killed Windows.
But that opportunity is over for a long time already.
Linux proved that the OS wars can be restarted after everyone is sure they are dead.
The difference with Linux is the _LICENSE_, not the technology.
Gordon.
self-interest@lists.selflanguage.org
-
charleshixson＠earthling.net -
David Ungar -
diegogomezdeck＠consultar.com -
Gordon Cichon -
Jecel Assumpcao Jr -
Jerry Bell -
Stefan Matthias Aust -
Thorsten Dittmar -
Thorsten Dittmar
-
thorsten.dittmar＠daedalos.com