Self-interest June 1996

self-interest@lists.selflanguage.org

16 participants
15 discussions

start-up seeks development team members
by Carlo Walentiny 30 Jun '96

30 Jun '96

...reflective systems...dynamic compilation(RTCG)...persistent object stores... 3D graphics...user interface design...program visualization ...open implementation...(C++) compiler design...code generation... intermediate representations...Fresco...Interviews...Oberon...object- oriented design...meta programming...virtual reality...OpenGL ...state-of-the-art programming environments...Self 4.0...Gwydion... Do any of these topics interest you? --------------------------------------------------------------------- START-UP SEEKS DEVELOPMENT TEAM MEMBERS Location: Luxembourg Starting date: 1 September (negotiable) --------------------------------------------------------------------- Here is an opportunity to join a Luxembourg-based start-up and take part in the development of a product which will set a new standard for interactive programming environments. To get an idea of the kind of benefits this product will provide, please read http://legend.gwydion.cs.cmu.edu/gwydion/gwydion-overview.html (and maybe also browse through http://self.sunlabs.com). If you think topping Gwydion's desirable goals, and doing this for C++ (which is rather more widely used than Dylan), sounds like a commercially and intellectually interesting idea, you might want to read on. Applicants must fulfill the following five requirements: - have a good sense of humour; - be intelligent; - be fluent in C/C++; - be willing to move to Luxembourg for at least a year; - (unfortunately) be a citizen of the EU (since otherwise you will not be allowed to work in Luxembourg). Successful applicants will be offered an OK salary, as well as some equity. Above all, you will participate in a demanding, exciting and stimulating project, which offers you the possibility to work in the following areas: - reflective systems, meta programming, open implementation; - (C++) compilers (and the C++ standard), intermediate representations, retargetable (binary) code generation, dynamic compilation, implementations of Smalltalk and Self, VCODE, (incremental and interactive) programming environments design (Mjolner/Orm,...), ...; - 3D graphics, OpenGL, user interface design, virtual reality, direct manipulation, portable graphics libraries, Fresco, Interviews, constraint systems, software visualization, ...; - persistent object stores, pointer swizzling, Texas, Mneme, ... . The more you are interested in and/or know about one or several of the above areas, the better. Whether you are about to graduate, writing up your PhD, or already have work experience, I look forward to hearing from you. Carlo Walentiny

1 0

Re: self for macOS?
by vac＠indium.rmb.co.za 18 Jun '96

18 Jun '96

David Ungar wrote : >We have about half a VM port to the PowerMac. > >Sorry! > >Can you say more about your interest? Will this port be completed, or will the source be made available at a later stage ? Vincent vac(a)rmb.co.za

1 0

Re: self for macOS?
by David.Ungar＠Eng.Sun.COM 18 Jun '96

18 Jun '96

We have about half a VM port to the PowerMac. Sorry! Can you say more about your interest? At 9:48 PM 6/11/96, joubin wrote: >hello all, > >is it possible to get self for the macintosh? is it possible to obtain >sources for another platform to port to macOS? > >thank you. >______________________________________ > >joubin >joubin(a)inch.com >212.693.0509 >nyc >______________________________________ -- Dave

1 0

Re: multicasting (was: idea: slices)
by Rainer Blome 17 Jun '96

17 Jun '96

Jecel pointed out (offline) that > You could write > > selection do: [ | :element. :distance. :speed | > element moveBy: distance With: speed. > ] With: distance With: speed which is far less ugly than my code. With optional arguments, this wouldn't even require multiple methods, as long as one is content with a maximum number of arguments. Making the element argument a parent would yield what I tried in the first place. If it weren't that, to my surprise, blocks cannot have parent slots. [ | :element. | element ifTrue: 'OK' False: 'Huh?' ] value: true => 'OK'. [ | :element*. | ifTrue: 'OK' False: 'Huh?' ] value: true => Syntax error. [ | :element. environment*. | environment: element. ifTrue: 'OK' False: 'Huh?' ] value: true => Lookup error: ifTrue not found. Rainer

2 1

idea: slices (a bit long)
by Jecel Assumpcao Jr 13 Jun '96

13 Jun '96

I have a few ideas I have been meaning to post here about the future of Self. I would very much like to get the opinion of all you selfish people, but I have been hesitant to post such long messages since I know how busy everybody is. Feel free to complain if you think this kind of posting isn't a good idea. Abstract ======== Selections are a common way of indicating objects to be affected by commands in a graphical user interface. Slices are a generalization of this idea to simplify the implementation and enhance the usefulness of GUIs. Background ========== In an object oriented graphics framework, on-screen objects are normally the result of a complex structure of basic shapes combined with "wrappers" (modifier objects). If the structure can be an arbitrary graph (or limited to non cyclic ones), then a single object might control the appearance of several distinct on-screen objects. Sharing a color wrapper among three objects, for example, would insure that every time the color of one is changed the others automatically change to match. In a drawing showing several PCs connected in a network, as another example, a change to one of the PCs might make it different from the others or the change can affect all subdrawings in one swoop. In the first case the PCs would be several copies of an original drawing (three distinct nodes in the object graph) while in the second we would have a single drawing being shown on the screen with several distinct translation wrappers. This is roughly like the difference between clones and traits or classes and instances. In the object-based spirit of Self, the Morphic graphics framework doesn't work like this, but makes each object responsible for all information related to it (color, position, etc). This makes it impossible to do the kinds of operations described above. It also makes it hard to extend the functionality of the framework - rather than just adding a new rotation wrapper we would have to include a rotation copy-down slot in the basic morph and (possibly) have to rewrite many methods. On the other hand, morphic is more concrete and easier to understand than most other frameworks. One problem with traditional frameworks is that the kinds of operations that can be done on an object are defined (and limited) by its invisible structure. In the PCs example, we can either change a single part of the drawing or all instances at once, and it is not always clear by just looking at the image which one is the case. If we need to do something different from what the current structure allows, we first have to change that structure and then do the operation. Imagine that we wish to modify in the same way two instances of the drawing but leave the rest of them alone. So expected operations were made easier at the cost of making unexpected operations much harder. And the most common expected operations are handled reasonably well by morphic's embedding structure. So we need a way to make unexpected operations as easy as possible. The Idea ======== The Sinclair ZX81 Basic had a very interesting feature called "slices" (APL had a much more powerful implementation of the idea, as did other systems, but I don't recall that they gave a name to it). It allowed you to operate on a whole subset of an array in a single operation. You could clear the middle three elements in a short vector by executing A(3 to 5) = 0. The idea of working with a subset of a collection of objects is a common one in graphical user interfaces. You might select two paragraphs in a long text to change their font to a larger size or you might create a carpet morph in Kansas to move several objects at once or to dismiss them. Rather than having these kind of operations be ad hoc additions to the GUI, it might be interesting to have them be instances of a more general "slices" concept. A slice is simply a collection whose elements are a subset of the elements of another collection. So saying "slice do: [something]" is simply a convenient shorthand for doing something to some elements in the original collection but not to the others. The slice must remember what collection its elements are from in case the something you wish to do is removing them from that original collection. Actually, the elements in a slice might come from several distinct collections. Graphically, a slice is a kind of "lightweight" object. It must be very easy to create or destroy one. You might create one by just dragging the mouse across some text and destroy it by simply creating another one. You might create a slice as a result of an operation (allImplementers, for example) and it might persist until explicitly dismissed. When you pop up a menu on a slice, it creates a menu which is the intersection of the menus of all of its elements. So you can choose an operation that can be done on all the elements (make a slice that includes a drawing and some text, for example, and the menu might limit you to changing their color). It is interesting to note that the combination slices/persistent objects makes a very nice poor man's database. It has the functionality of the "find" command that all modern OSes have copied from the Mac. You can use slices to choose if a change to a slot should affect only a given object or all of its clone family (this is even more flexible than Kevo or the debugger/outliner distinction in Self 4). The ability to create and manipulate lightweight slices of objects allow one time structuring of objects and is a convenient replacement for the more static structuring of conventional graphics frameworks. It also has many non graphical applications, being an interesting addition to Self's collection "types". Problems ======== The main problem is that making operations on slices the same thing as operating on all of its elements means that doing something with the slice itself is very awkward. Imagine that the menu for a carpet morphs listed operations to be done to the elements contained in it, rather than to the carpet morph itself. We might divide operations into three types: - elements only: changing the color is a thing to be done to each of the elements, but has no real effect on the slice itself. - elements and slice: moving the elements or resizing them will obviously imply moving resizing the slice as well. - slice only: adding new elements to a slice or removing elements from it (and, maybe, asking its current size) seem to be the only operations that can be done to the slice but which shouldn't affect the elements. The problem, then is finding a reasonable way to handle the third kind of operations, both textually and graphically. -- Jecel Mattos de Assumpcao Jr Laboratorio de Sistemas Integraveis University of Sao Paulo - Brazil mailto:jecel@lsi.usp.br http://www.lsi.usp.br/~jecel/merlin.html

2 5

Solaris 2.5 x86?
by Evan Cheng 12 Jun '96

12 Jun '96

Hi, Given that Self can be compiled and run on Solaris 2.4, I wonder if it is may also compile and run on Solaris 2.5 Intel edition. Has this been attempted? Also, is the source code being distributed for academic use? Thanks, Evan ------------------------------------------------------------------ Evan Cheng evan(a)top.cis.syr.edu Dept. CIS - Syracuse University http://www.cat.syr.edu/~evan CASE Research Center (315) 423-7063 ------------------------------------------------------------------

5 17

Re: idea: slices
by keith＠uniteq.uniteq.com 12 Jun '96

12 Jun '96

How about calling them "filters"?

1 0

A very powerful efficiency hack.
by cef＠geode.geodesic.com 12 Jun '96

12 Jun '96

In working on garbage collection I discovered a very powerful efficiency hack. Let me state the original form and then generalize. We had to scan pages for pointers. Instead of taking them in simple list order I took two passes. First take each page descriptor and discover if the page is in ram. If it is then scan and mark as scanned. On the second pass scan the pages not scanned in the first pass. This eliminates all kinds of paging, compared to many difficult code hacks it is really awesome. Now the generalization. There are all kinds of collections which have a prefered order of scan for efficiency. That is you need a method which says do_quickly [some method] which applies the method to all the members in an undefined order which is assumed to be chosen for efficiency alone.

1 0

colored glasses (was: idea: slices)
by Jecel Assumpcao Jr 12 Jun '96

12 Jun '96

Charles Fiterman wrote: > > Slices connects well with another idea which I call colored glasses. > > Given colored glasses on an object your changes to the object go > to the colored glasses. To you it looks like you have changed the > object but to other viewers the object remains constant. > > [more glasses examples] While I understand the advantages of your idea, it feels too "magic" for my taste. It goes in the exact opposite direction of persistent objects where the saving of state to secondary store is invisible. Most novices have a hard time dealing with the open/save commands so I doubt they would find colored glasses very easy to grasp. > This connects well to slices. A slice is a kind of colored glasses. > Changes stop at the slice. They only go to the object at commit time. That is one way to do it. Another is to automatically commit every change and have a way to undo it for the rare cases where you need it. -- Jecel

1 0

Re: Summer internship available at Sun Labs
by mario＠Eng.Sun.COM 12 Jun '96

12 Jun '96

The Kanban group (i.e., part of the group formerly known as the Self group) at Sun Labs has an opening for a summer intern, knowledgeable in Self, to work on a project this summer involving Self and Java. Unfortunately, due to time constraints, we cannot consider engaging a non-citizen of the US who does not already possess a suitable work permit. If you are interested, please email me a resume as soon as possible. Mario Wolczko [Apologies if you got another copy of this with some junk on the end -- finger trouble on my part]. Sun Microsystems Labs., 2550 Garcia Ave, M/S UMTV 29-116, Mountain View, CA 94043, U.S.A. tel: 415 336 6022, fax: 415 969 7269.

2 1

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 June 1996