Self-interest July 1996

self-interest@lists.selflanguage.org

16 participants
13 discussions

Re: Why isn't Kansas X11?
by Randall.Smith＠Eng.Sun.COM 31 Jul '96

31 Jul '96

Your guesses were correct: it seemed clearly heavier weight and complex to have each morph associated with a subwindow, (outliners can have hundreds of morphs) and things like arbitrary polygon morphs, hollow frames, line morphs, and shadow casting are awkward at best in X. However, we've had to start down this road to handle video morphs. Video morphs act almost like regular morphs, but they are at times relatively sluggish precisely because of all the subwindows you end up generating. --Randy > From rainer(a)physik3.gwdg.de Wed Jul 31 04:06:55 1996 > Date: Wed, 31 Jul 1996 12:32:03 +0200 > From: Rainer Blome <rainer(a)physik3.gwdg.de> > To: self-interest(a)self.sunlabs.com > Subject: Why isn't Kansas X11? > Content-Length: 1341 > > > Dear Kansas developers, > > I am wondering whether it is feasible to use X11 to handle the > morphs. The advantage would be integration with and use of > services of the rest of X11. > > Cons I could think of are so far: > > You want lots of relatively small windows. If X windows are > too heavy-weight, they won't do. GWM (at least) uses > subwindows to implement decorations, menus and so on, so they > can't be too heavy, or are they? > > To get arbitrary shapes, in particular `arrows', the WM must > allow undecorated, transparent windows with no border. > > The WM must communicate with the clients. If down-mouse-1, > then dragging should move the object, the object has to react > to the received X events by sending movement requests to the > WM. > > The WM must be able to handle multiple screens, in particular > share windows between screens. > > Shadows (think of the animated gas tank) might be hard to > implement and slow. > > Problems with thread and event scheduling. > > As far as I know, X11 can handle the above, at least in theory > (shared windows I'm not sure about). What were your reasons to put > morhs /in/ X windows? Is it because X lacks any other fundamentals > you needed or `just' that you wanted your system to run with an > arbitrary window manager (in particular dreaded olwm ;-)? > > > Rainer > >

1 0

WYSIWYG Editor in Self ?
by Michael.Huebner＠PrakInf.TU-Ilmenau.DE 31 Jul '96

31 Jul '96

Hi, is there anybody who wrote a WYSIWYG Editor in Self? My dream editor would be one with a LaTeX-like internal representation of the document and a WYSIWYG interface with a very intuitive interaction. The LaTeX representation should enable the easy usage of user defined constructs. To handle this in a WYSIWYG system it would be necessary to provide views behind the curtains. The interaction should be very object oriented, i.e. first select an object (or a group of objects) then get the menu of possible messages from that object(s) then select a message then provide arguments to the upcoming form then confirm/cancel the operation For undo-able argumentless messages the last 2 steps are superfluous. For very often used methods there should be short key sequences to call the method. The most today WYSIWYG systems are function oriented so it wouldn't be good to mimic their interfaces. The best thing of an editor in Self would be the possibility to extend/change the editor to the needs of the user. This should be supported by a good help facility. Emacs is a prototype for an extensible (but ASCII) editor. It has a help system with some good ideas. But there remain unfulfilled wishes. My requirements are very strong, so I would welcome for the first time a simple WYSIWYG editor which supports different formats (headings, main text, item ...). Later there could be extras like equations, tables, references, ... . I hope my ideas don't sound too silly. Michael

3 2

Re: Portable Self?
by Jecel Assumpcao Jr 31 Jul '96

31 Jul '96

ian (i.r.) woollard wrote: > > I've just started playing with Java actually. So did I - it's nice to see a system that makes Smalltalk seem fast :-) > I notice that when you want to execute Java you have to translate the > Java code into byte codes so that they can be executed. However, > there's nothing very special about the bytecodes that Java produces; > in theory they could be written in any language. The Java bytecodes could be generated from other languages, but they are rather closely coupled to the semantics of Java. > So I was thinking: Self could do with the portability that byte codes > have. Self already has bytecodes, though they are less optimized of interpretation than Java's or Smalltalk's. They are much simpler and nicer, on the other hand. > What's to stop someone producing a Self -> java bytecode > compiler? You would have to create a lot of "helper classes" that would have to be fetched with every Self applet. The speed would be terrible compared even to a naive Self interpreter. Of course, you could use Ole Agesen's static type analysis and extractor to feed an optimized Java bytecode generator, but that is hardly trivial. > The advantages are: > > - great portability > - great availability These are very tempting advantages. > - okish speed (will get much better as the byte code interpreters > improve) Interpreters won't ever get good enough, and just in time compilation simply doesn't compare to the adaptive compilation Self already has. > - making the typeless style of programming more popular Not really - Java bytecode are typed, so you have to give up that advantage of Self in order to deliver the applets. You still retain the comfort of typelessness while developing, of course. > The problems I see are: > > - interfacing to libraries (presumably not too hard) No - Self already gets along with Unix and X11 libs > - actually writing the compiler (presumably Jecels version of self is > closest to what you want) I don't think so. A lot of people have asked me about Java bytecodes so I have given this some thought (not as much as the people at Sun, of course!). The best hope would be to use a conventional Self system for development and then a special extractor and compiler to get the Java bytecodes. > - the dynamic nature of self code (e.g. potentially changing > constants/code on the fly-don't know whether Java allows this sort of > self modifying code!) Non of this could be used in the final applets, but that wouldn't be a problem in practice. Self applications can potentially create new kinds of objects on the fly, but how many do it besides the development environment? Steve Dekorte wrote: > Sounds like you'll need a Self VM in Java. > Then you don't need to worry about a Self->Java byte code compiler. > Of course it would be slow. That is another alternative, but you would need extraction to send the applets to the users anyway. So in the end, it doesn't matter what your development Self is based on. Sandor Lengyel x2495 wrote: > I am also interested in java, but it is a very slow language. Its advantage > that: > > 1. There will be Just in time Compilers. Which change the byte code into > machine code. They are not platform independent. Well, I would like to see how these compilers handle dynamic lookups before I give my opinion of them. > 2. Hardware which will be optimized for the byte code. I'll believe it when I see it. I think that a Java VM in hardware won't outperform the just-in-time compilers on other platforms but will be used to save memory instead. Mitochondrion wrote [among other things]: > I suspect the Ada project (a reference to which I could probably find if > someone wanted) worked well because of a tight mapping between Java > classes and Ada classes. Exactly. Java bytecodes have a superset of the functionality needed for Pascal or Ada, but only a subset of that needed for Self or Lisp. > Java is more than a language; it's also a national obsession, a lot of > excitement, and a lot of hype. No reason not to take advantage of the > energy! In a sense, Java is also about an increase in interest in OO > programming and in good design. You are right, which is why I feel so bad about the conclusion I have reached about this whole issue. I think that the best alternative is to port a simple Self interpreter to the same platforms Java runs on, doing it as a "plug-in" for Netscape and Explorer as well. If done correclty, this would offer enough additional functionality to justify the effort. This has the whole Java hype machine against it, of course, but it might raise some sympathy in the Smalltalk community. -- Jecel

1 0

Why isn't Kansas X11?
by Rainer Blome 31 Jul '96

31 Jul '96

Dear Kansas developers, I am wondering whether it is feasible to use X11 to handle the morphs. The advantage would be integration with and use of services of the rest of X11. Cons I could think of are so far: You want lots of relatively small windows. If X windows are too heavy-weight, they won't do. GWM (at least) uses subwindows to implement decorations, menus and so on, so they can't be too heavy, or are they? To get arbitrary shapes, in particular `arrows', the WM must allow undecorated, transparent windows with no border. The WM must communicate with the clients. If down-mouse-1, then dragging should move the object, the object has to react to the received X events by sending movement requests to the WM. The WM must be able to handle multiple screens, in particular share windows between screens. Shadows (think of the animated gas tank) might be hard to implement and slow. Problems with thread and event scheduling. As far as I know, X11 can handle the above, at least in theory (shared windows I'm not sure about). What were your reasons to put morhs /in/ X windows? Is it because X lacks any other fundamentals you needed or `just' that you wanted your system to run with an arbitrary window manager (in particular dreaded olwm ;-)? Rainer

1 0

Re: Portable Self?
by Mitochondrion 30 Jul '96

30 Jul '96

On Tue, 30 Jul 1996, ian (i.r.) woollard wrote: > ... > I notice that when you want to execute Java you have to translate the > Java code into byte codes so that they can be executed. However, > there's nothing very special about the bytecodes that Java produces; > in theory they could be written in any language. > ... I know this was done with Ada at some point, and that it worked. > The problems I see are: > > - interfacing to libraries (presumably not too hard) > - actually writing the compiler (presumably Jecels version of self is > closest to what you want) > - the dynamic nature of self code (e.g. potentially changing > constants/code on the fly-don't know whether Java allows this sort of > self modifying code!) I agree that this would be excellent, and I also agree with the problems listed above. I suspect the Ada project (a reference to which I could probably find if someone wanted) worked well because of a tight mapping between Java classes and Ada classes. Unfortunately, the mapping between Self and java would not be so clean. You can't change methods (code) on the fly. Java is very much a class-based language. You still could probably find a way to compile Self into Java. It woudn't be nearly as fast as it might be if you had the tight mapping, but it could work. And it really might help to get more people interested in Self, which would be good. (It kind of reminds me of a tradeoff in Scheme->C compilers: you can use C functions to map Scheme functions, and the C stack to map the Scheme stack, which works fine in every way EXCEPT continuations. So then you have to compile Scheme to C with a higher level of abstraction.) Java is more than a language; it's also a national obsession, a lot of excitement, and a lot of hype. No reason not to take advantage of the energy! In a sense, Java is also about an increase in interest in OO programming and in good design. Greg Travis greg(a)earthweb.com

2 1

Re: WYSIWYG Editor in Self ?
by Randall.Smith＠Eng.Sun.COM 30 Jul '96

30 Jul '96

> > Hi, > > is there anybody who wrote a WYSIWYG Editor in Self? There is no printing support in the system so the "What You Get" part of WYIWYG is currently "Nothing"! As to something to support some of your ideas below, you could start with an editorMorph, which will allow arbitrary objects in line with text in mixed fonts and colors. It is in places a somewhat complicated beast, because it tries to optimize itself to provide better performance. It was never really fast enough by the time we did our public release, so it is only used in a few places in the system. Good luck! --Randy > > My dream editor would be one with a LaTeX-like internal representation of the document > and a WYSIWYG interface with a very intuitive interaction. > The LaTeX representation should enable the easy usage of user defined constructs. > To handle this in a WYSIWYG system it would be necessary to provide views behind the curtains. > > The interaction should be very object oriented, i.e. > first select an object (or a group of objects) > then get the menu of possible messages from that object(s) > then select a message > then provide arguments to the upcoming form > then confirm/cancel the operation > > For undo-able argumentless messages the last 2 steps are superfluous. > For very often used methods there should be short key sequences to call the method. > > The most today WYSIWYG systems are function oriented so it wouldn't be good to mimic > their interfaces. > > The best thing of an editor in Self would be the possibility to extend/change the editor > to the needs of the user. This should be supported by a good help facility. > > Emacs is a prototype for an extensible (but ASCII) editor. It has a help system with > some good ideas. But there remain unfulfilled wishes. > > My requirements are very strong, so I would welcome for the first time a simple WYSIWYG > editor which supports different formats (headings, main text, item ...). > Later there could be extras like equations, tables, references, ... . > > I hope my ideas don't sound too silly. > > > Michael >

1 0

Re: Portable Self
by slengy＠ecad04.calcomp.com 30 Jul '96

30 Jul '96

>>So I was thinking: Self could do with the portability that byte codes >>have. What's to stop someone producing a Self -> java bytecode >>compiler? >>The advantages are: >>- great portability >>- great availability >>- etc >>The problems I see are: >>.. And that the byte code is so slooow. (Since interpeted) I am also interested in java, but it is a very slow language. Its advantage that: 1. There will be Just in time Compilers. Which change the byte code into machine code. They are not platform independent. 2. Hardware which will be optimized for the byte code. Because of this, Java will be a very usefull language indeed. Sandor

1 0

Portable Self?
by ian (i.r.) woollard 30 Jul '96

30 Jul '96

I've just started playing with Java actually. I notice that when you want to execute Java you have to translate the Java code into byte codes so that they can be executed. However, there's nothing very special about the bytecodes that Java produces; in theory they could be written in any language. So I was thinking: Self could do with the portability that byte codes have. What's to stop someone producing a Self -> java bytecode compiler? The advantages are: - great portability - great availability - okish speed (will get much better as the byte code interpreters improve) - making the typeless style of programming more popular The problems I see are: - interfacing to libraries (presumably not too hard) - actually writing the compiler (presumably Jecels version of self is closest to what you want) - the dynamic nature of self code (e.g. potentially changing constants/code on the fly-don't know whether Java allows this sort of self modifying code!)

1 0

Adv: Is Your Web Site A Secret?
by karen_17＠interramp.com 27 Jul '96

27 Jul '96

Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in two business days. Please respond for details. -Karen

3 2

undefinedSelector question
by Ivan Moore 25 Jul '96

25 Jul '96

Hello, Just a quick question/suggestion ... Why doesn't the 'undefinedSelector:...' run-time message include the sender as one of it's arguments? Wouldn't this allow some interesting things to be done (e.g. implementing subjectivity) (Sorry if this is a daft question/suggestion) Ivan.

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest July 1996