Self-interest December 2010

self-interest@lists.selflanguage.org

20 participants
31 discussions

Re: [self-interest] have to get this off my heart
by ungar＠mac.com 28 Dec '10

28 Dec '10

On Dec 27, 2010, at 11:03 AM, Jecel Assumpcao Jr. wrote: > All of my least favorite Self features have the same cause - strings or > numbers where objects would work better. Certainly annotations are a > more "proper" way of doing what was a "pun" in Self 1 and 2 using parent > priorities, but I would be happier if these annotations were full Self > objects instead of strings that have to be parsed in wierd way to > extract the information we need from them. > The string part was an easy implementation way to save space. Sure storing objects would have been nicer. In fact they were changed back and forth to objects in a way that was transparent. Annotations were meant to be functional, so you could replace them but not change them in place. That saves a lot of space. Remember that every slot in every point object conceptually had its own annotation. > > Another place with this problem is the parameters of fail blocks. In > fact, this made Ole Agesen's application extraction scheme a lot less > useful since primitive handling code always had to include fancy string > methods. Replacing this parsing with a small set of exception objects > would be a huge improvement, in my opinion. > Not sure what you mean here about Ole's extractor. IMNSO, exceptions were a botch invented in languages without blocks. I never liked the fact that control could invisibly branch off. For instance, in a long method with exceptions, containing A; B; C;, you cannot count on B being executed if A is executed. At least with fail blocks you can see the branch in the return symbol in the block. I know that others like exceptions. To me they are like iterators, both were workarounds for languages without blocks that became enshrined in our culture. I prefer blocks. But that's just me. > > The layout stuff in Morphic used to (I haven't looked since 1995) encode > stuff like left/middle/right as 1, 2 or 3. This required lots of tests > that would go away if simple alignment objects were used instead. > > > About the annotations, in my tinySelf 0 I just had a special constant > slot with the value for the object annotation, but never did come up > with a good scheme for the slot annotations. > That would allow object annotations to be accessed without reflection, a change from what I considered to be the appropriate base-level semantics. It is simpler, though. It violates my preferred model of object encapsulation. > > -- Jecel > >

2 1

Re: [self-interest] have to get this off my heart
by Jan-Paul Bultmann 27 Dec '10

27 Dec '10

On Dec 27, 2010, at 8:03 PM, Jecel Assumpcao Jr. wrote: > All of my least favorite Self features have the same cause - strings or > numbers where objects would work better. Certainly annotations are a > more "proper" way of doing what was a "pun" in Self 1 and 2 using parent > priorities, but I would be happier if these annotations were full Self > objects instead of strings that have to be parsed in wierd way to > extract the information we need from them. > > Another place with this problem is the parameters of fail blocks. In > fact, this made Ole Agesen's application extraction scheme a lot less > useful since primitive handling code always had to include fancy string > methods. Replacing this parsing with a small set of exception objects > would be a huge improvement, in my opinion. > > The layout stuff in Morphic used to (I haven't looked since 1995) encode > stuff like left/middle/right as 1, 2 or 3. This required lots of tests > that would go away if simple alignment objects were used instead. > That should go on the bug tracker in my opinion. Jecel would you be so kind :)? > > About the annotations, in my tinySelf 0 I just had a special constant > slot with the value for the object annotation, but never did come up > with a good scheme for the slot annotations. > Yeah, that was my first idea too, simply add a meta* slot or something like that, but slot annotations would have to be put in a dictionary then, with the selectors as keys wich means redundancy. > > -- Jecel > Cheers > >

1 0

Filing Out A Composite Morph?
by Josh Flowers 27 Dec '10

27 Dec '10

Does Self support filing out composited morphs? I composited a number of morphs to create an irc chat UI, but I'm having troubles writing it out. I turned an instance of the morph into a prototype; added it to a module; setup the copy-down slots to Copydown parent: 'rowMorph', Copydown selector: 'copyRemoveAllMorphs'... and I think that's about it. The module files out and in without errors, but when I try and create an instance of the prototype I get an error message about 'rawMorphs' being missing. I can fix this by manually setting the irc morph's copy-down attributes (they don't seem to copy over as part of the file-in/out process) but then the original submorphs don't exist. Besides having trouble describing the problem - am I doing something wrong?

5 16

Btw...
by Russell Allen 27 Dec '10

27 Dec '10

At 92 messages so far, this has been the busiest month on the mailing list since November 1999! Onwards and upwards :) Russell

1 0

deep copy
by Jan-Paul Bultmann 27 Dec '10

27 Dec '10

hey, no deep copy functionality there? cheers Jan

4 8

Re: [self-interest] Re: Klein, ARM and Self Hardware
by Jan-Paul Bultmann 16 Dec '10

16 Dec '10

On Dec 16, 2010, at 4:43 AM, Jecel Assumpcao Jr. wrote: > Jan-Paul Bultmann wrote: > > Yeah, running on the ipad would be rad, but is impossible. > > That's why I like the touchbook, its open source hardware. > > On Dec 15, 2010, at 11:10 PM, Michael Latta wrote: > > > Also note that any talk about porting to iOS will hit a security wall. > > > They do not allow dynamically generated code for security reasons. > > > They use the noexecute bit on all data pages and only static signed > > > code gets into an executable page. If you want to run on iOS you > > > need the option to generate static code that can be signed. > > You can't have any kind of programming language in the app store, so I > don't think there would be a way to distribute Self even if it were just > a simple interpreter. See Squeak, Etoys and Scratch and their adventures > on the iPad. > > I think Jan's suggestion of the Touchbook or similar is the way to go. > > > > [Klain can run on a Self VM for a processor it doesn't support] > > Yea but the DebugServer xcodeproject is made for PPC and needs > > a bit of modification first, I thought that it was mainly developed on > > an intel mac first :). > > Right - I had forgotten the DebugServer. > > > While I love the idea of custom self hardware, and like the design > > of the RISC42, it might be more practical for the start to use > > something that is easier to set up (I don't think many users will be > > able to do their FPGA :) while everybody with the spare buck for a > > beagleboard could start right off). > > I agree 100%. Those were projects I was interested in, not that I would > recommend other people work on. I see them as interesting from a > historical perspective. Since my projects using conventional processors > are much better documented, here is a brief outline of my Self > processors: > > 1990-1991: various dataflow style designs that were dropped in favor of > a modified Sparc when the data from the Self project became available. > This chip was easy to configure as an embedded controller, a node for a > parallel machine or as a low cost children's computer. > > 1991: after the above project was cancelled as "not academic enough" by > my boss, I came up with a radical concept that some 8 years later > evolved into RNA (http://www.merlintec.com:8080/hardware/19). This was > immediately rejected by my boss. > > mid 1990s: a vague idea called "Snow White and the Dwarves" would have a > large processor implementing adaptive compilation in hardware with a > bunch of simple processors only capable of running fully optimized code. > The idea was that many passes of only local optimizations can get you > the same effect as more global optimizations. > > 1998-2001: Tachyon was a VLIW MOVE processor (4 moves of 16 bits each > per clock cycle, plus 6 more moves in special loop processors) with > 768KB of high speed external memory as an instruction and data cache. > The main memory would only hold bytecodes, so the compiler had the job > of reloading the instruction cache. > > 2001-2007: Plurion had several simple stack processor, each with its own > cache (the internal memory of FPGAs became much larger starting with the > Virtex II). This didn't need the really fancy compilation techniques > that Tachyon wouldn't work without. > > 2007-2008: RISC42 was optimized as the target of an adaptive compiler, > while Plurion was more like a fast interpreter. > > > When doing custom hardware I would maybee even do something > > radically different. Say 1000 primitive Cores with moderate cache > > for each one and no ram. > > This is on our roadmap for SiliconSqueak - a wafer scale device using an > older 250nm technology to fit 16 thousand processors, each with a large > local cache, into a $500 supercomputer. > Cool thing :D I think massive core parallelism suits a prototype based language better, since you can load an entire object into the core and dont worry about shard methods, it's all there, it might be duplicated across the system, but thats a small price to pay, since memory is cheap and latency is expensive. (kevo would fit this even better) > > When self was then retrofittet with some bits of the actor model, > > Have you seen my tinySelf 1 experiments? > > http://www.merlintec.com/lsi/tiny.html#rel1 > Yea I really like it. It seems to be based on the actor model right? It's not explicitly stated, but lazy locks( aka futures) and asynchronous message sends are pretty much all that is to a-m :D > > Or David Ungar's current work? > > http://www.stefan-marr.de/tag/roarvm/ > Not yet, looks interesting. > > > we could simply load one object per core and let them communicate > > via message passing :D so skipping ram entirely would bring a > > performance boost that would make the "slow" message passing worth > > it. But thats a story for another day (and my personal dream cpu so...;)). > > Once you have the objects living in their own processors and exchanging > actual messages over some communications network, you could replace some > of these objects with dedicated hardware blocks and the rest of the > system would not notice (except for some increase in performance). > Yea once you have enough cores you can specialize, by letting some do floating point only and some do integer only. Hardwiring entire objects seems reasonable too :) > Reinaldo Silveira took the first step in this direction with his PhD > thesis on using Self as a hardware description language (unfortunately > the text is in Portuguese, but even just the pictures are interesting): > > http://www.merlintec.com/download/selfHDL.pdf > > He didn't continue this work, which would involve generating the > hardware instead of just simulating it and then converting "normal" Self > objects into SelfHDL. > While I like the Idea of everything done in Self, I think hardware is not practical. We can have such a open security model, like message passing, and nonexistent typing, because we can fix the system when something goes wrong. Simply use the rad debugger and off you go. When designing hardware you want to do it right the first place. Therefore I think hardware design should be made with a language like Haskell, where you can proof the crap out of the system :D > > > I love the merlin :D I really think it could massively reform education. > > But I think we could be better off using of the shelf parts (and the > > touchbook looks a bit like the merlin :)), so we can focus on the things > > that are "easy" and that users will feel an impact from. > > Sure, but the best way to impact people is to run on the machines they > already have (some kind of PC, most likely). On the other hand, if Klein > runs on the bare hardware then it will be too complicated for people to > install it beside their current operating system. One option is to use a > virtual machine (in the sense of Qemu or VirtualBox) and another is to > run on hardware cheap enough that people won't mind too much buying an > extra machine. I would agree that the Touchbook is an example of this. > > -- Jecel > >

1 0

Re: [self-interest] Re: Klein, ARM and Self Hardware
by Jim Wise 16 Dec '10

16 Dec '10

"Jecel Assumpcao Jr." <jecel(a)merlintec.com> writes: > You can't have any kind of programming language in the app store, so I > don't think there would be a way to distribute Self even if it were just > a simple interpreter. See Squeak, Etoys and Scratch and their adventures > on the iPad. This policy has been loosened for interpreters, although relatively few people have taken advantage of this (MIT Scratch has not come back to the app store, for instance, but there is a limited Scheme interpreter and a C-64 Basic emulator, both previously banned). But that doesn't help apps which attempt to generate executable code, either through pre-comilation or JIT compilation, for the reasons Michael points out. -- Jim Wise jwise(a)draga.com

1 0

Re: [self-interest] Re: Klein, ARM and Self Hardware
by Michael Latta 16 Dec '10

16 Dec '10

Also note that any talk about porting to iOS will hit a security wall. They do not allow dynamically generated code for security reasons. They use the noexecute bit on all data pages and only static signed code gets into an executable page. If you want to run on iOS you need the option to generate static code that can be signed. Michael On Dec 15, 2010, at 2:35 PM, Jecel Assumpcao Jr. wrote: > Jan-Paul Bultmann wrote on Wed, 15 Dec 2010 20:20:23 +0100 >> On Dec 15, 2010, at 7:33 PM, Adam wrote: >>> If I remember correctly, Klein doesn't have an x86 assembler or >>> compiler. It has a Sparc assembler, and a PowerPC assembler and >>> compiler. (The Apple transition to Intel happened right around the >>> time when Klein was being cancelled at Sun.) > > That is what I remember too, but weren't there at least some stubs for > x86 or 68000 processors? I would have to look at it again... yeah, just > a i386 stub. > >> Oh noes, that would explain why I can't get it to build... 10.6 >> dropped Rosetta. > > That shouldn't matter. What processor the Self VM used to support Klein > uses has not relation to what processor Klein itself understands since > you could consider Klein to be a cross compiler. > >> So when we want to use it on a platform that is not only used in >> SuperComputers today we have to go the arm or 86 way. And I would >> then choose the ARM due to simplicity in the Assembler. (A Sparc >> laptop would be rad though :D). > > I think at some point Self was running on the Sun SPARCstation Voyager, > which is pretty close to a laptop. And there used to be a Sparc laptop > from a company called Tadpole. > > About the general issue of Self hardware, however, it is important to > remember that the major reason why the language failed to become more > popular was that it required you to buy a very specific computer to run > it on. My most expensive investment to date was exactly a Sun Ultra 5 > machine in 1998 just to be able to use Self at home instead of depending > on the university. The Mac version in 2000 changed things, but this was > also a machine that few people had and by then the reputation of Self as > unavailable was hard to reverse. > > Now if you are talking about gathering a group of people to restart the > development of Klein then it makes perfect sense to have all the > programmers use the same hardware as their initial target in order not > to waste time on porting issues in the begining. > > Most people on this list are probably very tired of hearing about this, > but since we have newcomers I should mention that I worked on Self > specific hardware from 1998 to 2008. At that point I joined a group of > people who were already investing in Squeak Smalltalk so I changed the > focus of my designs. But I still feel that my unimplemented RISC42 > processor would be a great target for Klein: > > http://www.merlintec.com:8080/hardware/RISC42/ > > Note that at the board level, I use programmable logic (FPGAs) to > implement my SiliconSqueak processor. This means that the boards could > have RISC42 instead. Or even the Leon3, which is a very robust open > source implementation of Sparc. > > -- Jecel > > > > ------------------------------------ > > Yahoo! Groups Links > > >

2 1

Re: [self-interest] Re: Klein, ARM and Self Hardware
by Jan-Paul Bultmann 15 Dec '10

15 Dec '10

On Dec 15, 2010, at 10:35 PM, Jecel Assumpcao Jr. wrote: > Jan-Paul Bultmann wrote on Wed, 15 Dec 2010 20:20:23 +0100 > > On Dec 15, 2010, at 7:33 PM, Adam wrote: > > > If I remember correctly, Klein doesn't have an x86 assembler or > > > compiler. It has a Sparc assembler, and a PowerPC assembler and > > > compiler. (The Apple transition to Intel happened right around the > > > time when Klein was being cancelled at Sun.) > > That is what I remember too, but weren't there at least some stubs for > x86 or 68000 processors? I would have to look at it again... yeah, just > a i386 stub. > > > Oh noes, that would explain why I can't get it to build... 10.6 > > dropped Rosetta. > > That shouldn't matter. What processor the Self VM used to support Klein > uses has not relation to what processor Klein itself understands since > you could consider Klein to be a cross compiler. > Yea but the DebugServer xcodeproject is made for PPC and needs a bit of modification first, I thought that it was mainly developed on an intel mac first :). > > > So when we want to use it on a platform that is not only used in > > SuperComputers today we have to go the arm or 86 way. And I would > > then choose the ARM due to simplicity in the Assembler. (A Sparc > > laptop would be rad though :D). > > I think at some point Self was running on the Sun SPARCstation Voyager, > which is pretty close to a laptop. And there used to be a Sparc laptop > from a company called Tadpole. > > About the general issue of Self hardware, however, it is important to > remember that the major reason why the language failed to become more > popular was that it required you to buy a very specific computer to run > it on. My most expensive investment to date was exactly a Sun Ultra 5 > machine in 1998 just to be able to use Self at home instead of depending > on the university. The Mac version in 2000 changed things, but this was > also a machine that few people had and by then the reputation of Self as > unavailable was hard to reverse. > True we should not make it hard for people to get hands on self. But I think the task of getting Klein to work, must not result in dropping everything else :) > > Now if you are talking about gathering a group of people to restart the > development of Klein then it makes perfect sense to have all the > programmers use the same hardware as their initial target in order not > to waste time on porting issues in the begining. > > Most people on this list are probably very tired of hearing about this, > but since we have newcomers I should mention that I worked on Self > specific hardware from 1998 to 2008. At that point I joined a group of > people who were already investing in Squeak Smalltalk so I changed the > focus of my designs. But I still feel that my unimplemented RISC42 > processor would be a great target for Klein: > > http://www.merlintec.com:8080/hardware/RISC42/ > > Note that at the board level, I use programmable logic (FPGAs) to > implement my SiliconSqueak processor. This means that the boards could > have RISC42 instead. Or even the Leon3, which is a very robust open > source implementation of Sparc. > While I love the idea of custom self hardware, and like the design of the RISC42, it might be more practical for the start to use something that is easier to set up (I don't think many users will be able to do their FPGA :) while everybody with the spare buck for a beagleboard could start right off). When doing custom hardware I would maybee even do something radically different. Say 1000 primitive Cores with moderate cache for each one and no ram. When self was then retrofittet with some bits of the actor model, we could simply load one object per core and let them communicate via message passing :D so skipping ram entirely would bring a performance boost that would make the "slow" message passing worth it. But thats a story for another day (and my personal dream cpu so...;)). I love the merlin :D I really think it could massively reform education. But I think we could be better off using of the shelf parts (and the touchbook looks a bit like the merlin :)), so we can focus on the things that are "easy" and that users will feel an impact from. cheers Jan > > -- Jecel > >

2 1

Re: [self-interest] Anyone have a copy of Kevo?
by Russell Allen 15 Dec '10

15 Dec '10

This is something I've wanted to do for a while as I think it would make the system much easier. Finding what a string can do is messy if I have to open half a dozen outliners for traits. I actually stumbled across the 'Kevo' mode at some point but it didn't look finished - the system ground to a halt with much garbage collection happening when I tried it. Russell > On Mon, 13 Dec 2010 18:20:23 -0800, David Ungar wrote: >> FWIW, there was once and may still be a Kevo mode in the Self >> outliner.It changed the presentation to include parent slots >> under a special category. > > I have never seen that, but the outliners have so many options that I > bet it would take days to explore them all (trying to get the look of > the Self movie is an interesting experience, for example). > > One feature slightly related to Kevo and that is easy to miss is that > editing a method in the debugger is different than editing the same > method in an outliner. In the first case all clones of the methods are > changed to match while in the second the method in the object becomes > different from the clones. > > -- Jecel > >

1 1

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 December 2010