Self-interest December 2011

self-interest@lists.selflanguage.org

17 participants
12 discussions

Re: [self-interest] persistent objects (was: goals)
by baltasarq 22 Dec '11

22 Dec '11

Hi, there! > On the other hand, saving objects to a single database file could be a > reasonable option if that is what you want to do. The Transporter code > might be a good starting point. The main complication is converting > binary references (pointers) to text. Pointer swizzling. The lack of this mechanism means that Self lacks of true persistence capabilities, apart from dumping everything in a snapshot. -- Baltasar (baltasarq(a)gmail.com http://baltasarq.info/)

3 4

Re: [self-interest] goals (was: dynamic deoptimization)
by Casey Ransberger 14 Dec '11

14 Dec '11

Top post: nested interpreters makes me think about OMeta. Just a thought. On Dec 12, 2011, at 3:28 PM, "Jecel Assumpcao Jr." <jecel(a)merlintec.com> wrote: > Thorsten Dittmar wrote: > > > I'm interested in general , to get self more selfish. If we would be able to > > manifest the principles of self even more accurate and more evident, that > > would be something great. For that reason I thought that the Klein VM would > > be one of the right steps. > > It is a very good idea to be able to use what we have learned. That is > how we got Self in the first place, and before that Smalltalk-80 from > -78/-76 and those from -72/-74. Commercialization from Smalltalk-80 as > it was, so the lessons from Ark couldn't be applied. > > Klein tried to implement the stuff learned after Self 1, 2 and 3 and > then Squeak. My main problem with that project is that it uses > generative coding (think macros) to get more done with less but this is > done in a system that is unaware of this. So you get generated code side > by side with hand written stuff and it takes a very long time to figure > out which is which if you weren't the one who created them in the first > place. This also tends to create many copies of the same stuff (made > worse by the fact that there are several parallel experiments in the > same code) and it takes a while to figure out which ones are used where. > > Since Klein has not been touched since 2006, my own strategy will be to > try to include what I can learn (and have already learned) from it in a > new system. My PhD project is to implement a self sustained system in a > way that is understandable by generating code from nested interpreters > (which are easy to write and understand) with partial evaluation (even > if a mostly faked one, like in Pypy where tracing does the job a partial > evaluator would do). One way a system can be defined in itself is > through reflection - meta-objects. That leads to the problem of an > infinite tower of interpretation, but as I just said nested interpreters > are exactly what I hope my system will be able to handle. > > The metric to measure the success of my PhD project will be how much of > Klein's funcionality it will have compared with how much smaller it will > be to do it. > > The language I have been using is Squeak in order to play nice with > several projects that are interesting to me. But I think it might be > better to include more options, like Self 4 and some even simpler > version. > > -- Jecel > >

4 5

Re: [self-interest] persistent objects (was: goals)
by Russell Allen 14 Dec '11

14 Dec '11

On 14.12.2011 05:07, Baltasar wrote: >> > But you don't need a snapshot to work from Self. You can build worlds easily > > > from the Github source tree, and can edit your programs easily in your favourite > > > text editor, if you want. > > > > ... but as far as I understand, you cannot launch, say, a Self Browser which is not > > inside a snapshot. And you cannot save the state of an application for future > > executions without a snapshot, which plays the role of the persistent store. Sure you can! Build your world from the source tree with: 'worldBuilder.self' _RunScript start morphic with: desktop start and open your outliner with: desktop worlds first addMorph: (selfObjectModel newOutlinerFor: (reflect: 'Hello, World!') InWorld: desktop worlds first) No snapshots required. As for saving state, just do it the same way you would in Java, Python, Ruby etc etc. Create a file and dump your important state into it in whatever format you feel like. :) Russell

1 0

Re: [self-interest] dynamic deoptimization (was: ARM?)
by baltasarq 14 Dec '11

14 Dec '11

Hi, there ! > This is *really* hard to so and I don't know which VMs beside the Self > one can do it. One reason why most VMs don't do it is simply that it is > hard to miss something that you have never had. Just like the industry > thought for decades that garbage collection was a needless complication, > the debugging environments most people are used to have that limitation > but there is nobody demanding that it be fixed. I am not sure I completely understand this. Say that I create a debug mode, in which the bytecode is interpreted, and that I offer a callback that is executed after each instruction in the VM is executed. Say that the code is JIT'ed only in the release mode. Wouldn't that eliminate the need to that dynamic deoptimization? -- Baltasar (baltasarq(a)gmail.com http://baltasarq.info/)

5 5

Re: [self-interest] goals (was: dynamic deoptimization)
by baltasarq 14 Dec '11

14 Dec '11

Hi, there! > My main problem with that project is that it uses > generative coding (think macros) to get more done with less but this is > done in a system that is unaware of this. So you get generated code side > by side with hand written stuff and it takes a very long time to figure > out which is which if you weren't the one who created them in the first > place. This also tends to create many copies of the same stuff (made > worse by the fact that there are several parallel experiments in the > same code) and it takes a while to figure out which ones are used where. It seems that the experimental features of Self are getting in the way, again and again. I still think that a "simpler" (in terms of less experimental) Self is needed, name it an interpreter or maybe just a cleanup of the existing code. > Personally I'd like to try baking SQLite into the VM and making snapshots actual databases including the saved objects. That gives us easy versioning and ability to create baked in object databases, while still retaining a single file snapshot with all its advantages, including the advantage that a wide variety of third party tools could read it in a pinch. Yep, probably this is offtopic, but for me, the need of working in a so-called snapshot is, by far, the worst feature of Self. -- Baltasar (baltasarq(a)gmail.com http://baltasarq.info/)

5 6

Direct memory & CPU access
by David Goehrig 13 Dec '11

13 Dec '11

Last night I was playing around with adapting a simple compiler I've written for x86, PowePC, AVR32, and ARM to Self, and had code generation working nicely. BUT the memory object gave me no way to poke my raw byte code to and address, and I had no obvious way to transfer that address to the instruction pointer of the CPU from within Self (short of extending the VM). At that point I decided sleep was more important and went to bed. The code this came from was a C program I used to bootstrap programs in the field, ship a new program in a lispy language, and compile it to native, fork() then jump to the new code, and return the parent process to waiting for a new program. For kicks one weekend, I wrote the main program loop in the lispy language, hand compiled the Linux & Mac OS calls to perform the read() and fork(), and had a self hosting system. Having a tethered environment wherein you can extend and break the SelfVM from inside self seems like it should already exist, so does anyone know if it does? I would have thought that is a prerequisite for Klein. If we were to turn the glove inside out, maybe the problem is we don't have a low enough level of abstraction modeled in the current Self system (for memory, CPU, pci, etc) to make Klein simpler. -=-=- dave(a)nexttolast.com -=-=-

2 1

Re: [self-interest] parent arguments
by Jan-Paul Bultmann 13 Dec '11

13 Dec '11

Sounds like differential inheritance to me. :? Cheers Jan On Dec 13, 2011, at 01:23 AM, Jecel Assumpcao Jr. wrote: > Here is a language feature which I thought we had discussed before, but > a quick search in this list's archives seems to indicate that we > haven't. > > Officially Self has something that I am calling "parent arguments" in > this email. We tell that story that when a lookup finds a method as some > slot's value, we clone that method object transforming it into an > activation object by changing some of its slots. This includes adding a > special argument slot called "self" which is set to the receiver of the > message. This slot not only behaves like an argument, but it also > behaves like a parent (which is why it is indicated as :self* in our > drawings) and allows the method to access all the slots in the receiver. > > There is a similar scheme to explain how blocks work, though the > :<lexicalParent>* slot doen't have a name that is visible through normal > message passing (in practice :self* doesn't either since "self" in the > source text is parsed into a special bytecode instead of as a send one). > > Of course, this isn't at all how things are actually implemented. But it > is the story we tell about the language. > > I was wondering if it wouldn't be interesting to have this as a real > feature of Self. Any object could have a parent argument slot and that > would get filled in with another object whenever it was cloned. So > > w: myWrapper cloneWith: model. > > would do essentially what we can now do with > > w: myWrapper clone. w mParent: model. > > This alternative supposes that myWrapper includes a parent data slot > called mParent. The difference is that this data slot can be reassigned > to some other object at any time while the proposed parent argument slot > can't be changed (not counting reflection) during that object's > lifetime. My idea is that this captures an interesting usage pattern > better than assignable parent slots. > > -- Jecel > >

2 1

Re: [self-interest] dynamic deoptimization (was: ARM?)
by Michael Latta 13 Dec '11

13 Dec '11

Good point. Another is exception handling itself. It is hard to debug when stack frames are unwound by exceptions. But, if the semantic is to add a stack frame for the exception handler, it gets easier to debug. Having the ui spawn threads rather than a single event loop also makes quite a difference. It would be good to summarize the features of self lacking in current environments, both as marketing and project guidance. Michael On Dec 10, 2011, at 2:58 PM, "Jecel Assumpcao Jr." <jecel(a)merlintec.com> wrote: > Baltasar, > > imagine that you give me a 10 line function in C and ask me to translate > it into Lisp. If you demand that my version keep track of the > intermediate state at the end of each of the ten lines, I will not be > able to do a very good job. If, on the other hand, you allow me to do > anything I want as long as the input arguments are the same and the > result is the same then I can create very good code. > > So in Self we defined some "safe points", like when messages are sent or > on the backward branches of loops which have no sends in them and only > demand that the code generated by the optimizing compiler make the state > match what we would expect from the bytecodes at these safe points. What > the code does between these points is its own problem. > > What happens if some exception, like a division by zero, occurs between > the safe points? We should go into the debugger, but now we have a > problem: the state of the optimized code can't be understood in terms of > the bytecodes! The solution adopted in Self is to sort of run the > optimization process in reverse, a deoptimization, that can recreate the > state we would have had if we had run the bytecodes from the last safe > point up to where the exception happened. > > This is *really* hard to so and I don't know which VMs beside the Self > one can do it. One reason why most VMs don't do it is simply that it is > hard to miss something that you have never had. Just like the industry > thought for decades that garbage collection was a needless complication, > the debugging environments most people are used to have that limitation > but there is nobody demanding that it be fixed. > > -- Jecel > > > > ------------------------------------ > > Yahoo! Groups Links > > >

5 6

Re: [self-interest] parent arguments
by Russell Allen 13 Dec '11

13 Dec '11

On 13.12.2011 11:23, Jecel Assumpcao Jr. wrote: > Here is a language feature which I thought we had discussed before, > but > a quick search in this list's archives seems to indicate that we > haven't. > > Officially Self has something that I am calling "parent arguments" > in > this email. We tell that story that when a lookup finds a method as > some > slot's value, we clone that method object transforming it into an > activation object by changing some of its slots. This includes > adding a > special argument slot called "self" which is set to the receiver of > the > message. This slot not only behaves like an argument, but it also > behaves like a parent (which is why it is indicated as :self* in our > drawings) and allows the method to access all the slots in the > receiver. > > There is a similar scheme to explain how blocks work, though the > :* slot doen't have a name that is visible through normal > message passing (in practice :self* doesn't either since "self" in > the > source text is parsed into a special bytecode instead of as a send > one). > > Of course, this isn't at all how things are actually implemented. > But it > is the story we tell about the language. > > I was wondering if it wouldn't be interesting to have this as a real > feature of Self. Any object could have a parent argument slot and > that > would get filled in with another object whenever it was cloned. So > > w: myWrapper cloneWith: model. > > would do essentially what we can now do with > > w: myWrapper clone. w mParent: model. > > This alternative supposes that myWrapper includes a parent data slot > called mParent. The difference is that this data slot can be > reassigned > to some other object at any time while the proposed parent argument > slot > can't be changed (not counting reflection) during that object's > lifetime. My idea is that this captures an interesting usage pattern > better than assignable parent slots. Is this a pattern that you're using a lot? I'm not sure how often I change an objects parents except at a meta-level through outliners? Russell > > -- Jecel > > > > Links: > ------ > [1] mailto:jecel@merlintec.com?subject=Re%3A%20parent%20arguments > [2] > mailto:self-interest@yahoogroups.com?subject=Re%3A%20parent%20arguments > [3] > > http://groups.yahoo.com/group/self-interest/post;_ylc=X3oDMTJwNjhtN2NrBF9TA… > [4] > > http://groups.yahoo.com/group/self-interest/post;_ylc=X3oDMTJlamZwaXRrBF9TA… > [5] > > http://groups.yahoo.com/group/self-interest/message/2793;_ylc=X3oDMTM0OGk1b… > [6] > > http://groups.yahoo.com/group/self-interest/members;_ylc=X3oDMTJmNWM1Y29rBF… > [7] > > http://groups.yahoo.com/group/self-interest;_ylc=X3oDMTJlNTBjZnBoBF9TAzk3Mz… > [8] > > http://global.ard.yahoo.com/SIG=15ov15o44/M=493064.14543979.14562481.132984… > [9] > > http://groups.yahoo.com/;_ylc=X3oDMTJkMDM3aHNqBF9TAzk3MzU5NzE0BGdycElkAzExM… > [10] > > mailto:self-interest-traditional@yahoogroups.com?subject=ChangeDeliveryFormat:Traditional > [11] > mailto:self-interest-digest@yahoogroups.com?subject=EmailDelivery:Digest > [12] > mailto:self-interest-unsubscribe@yahoogroups.com?subject=Unsubscribe > [13] http://docs.yahoo.com/info/terms/

1 0

parent arguments
by Jecel Assumpcao Jr. 13 Dec '11

13 Dec '11

Here is a language feature which I thought we had discussed before, but a quick search in this list's archives seems to indicate that we haven't. Officially Self has something that I am calling "parent arguments" in this email. We tell that story that when a lookup finds a method as some slot's value, we clone that method object transforming it into an activation object by changing some of its slots. This includes adding a special argument slot called "self" which is set to the receiver of the message. This slot not only behaves like an argument, but it also behaves like a parent (which is why it is indicated as :self* in our drawings) and allows the method to access all the slots in the receiver. There is a similar scheme to explain how blocks work, though the :<lexicalParent>* slot doen't have a name that is visible through normal message passing (in practice :self* doesn't either since "self" in the source text is parsed into a special bytecode instead of as a send one). Of course, this isn't at all how things are actually implemented. But it is the story we tell about the language. I was wondering if it wouldn't be interesting to have this as a real feature of Self. Any object could have a parent argument slot and that would get filled in with another object whenever it was cloned. So w: myWrapper cloneWith: model. would do essentially what we can now do with w: myWrapper clone. w mParent: model. This alternative supposes that myWrapper includes a parent data slot called mParent. The difference is that this data slot can be reassigned to some other object at any time while the proposed parent argument slot can't be changed (not counting reflection) during that object's lifetime. My idea is that this captures an interesting usage pattern better than assignable parent slots. -- Jecel

1 0

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