Self-interest June 1993

self-interest@lists.selflanguage.org

3 participants
7 discussions

Re: unix chdir
by urs＠cs.stanford.edu 19 Jun '93

19 Jun '93

> I am considering just removing xlibPrim.wrappers.c from the basic > build since I'm using the dynamically linked stuff. Is there an overview > document on how the Makefiles are organized? > There are some hints in the doc subdirectory, but not too much about make...essentially, to add/remove a source file you have to change the source directory's Makefile (e.g. prims/Makefile) and add/remove dependencies in the top-level includeDB (*not* the copies in sun4/debug etc.). Then make lists and everything should work. Essentially, make lists constructs a makefile, and it uses the information from the source directory makefiles and from the includeDB to figure out which .o files to build and in what order. Hope that helps, -Urs

1 0

looking for benchmark programs
by urs＠cs.stanford.edu 18 Jun '93

18 Jun '93

For my upcoming thesis I'm looking for a Few Good Programs to use as benchmarks for the new Self compiler. To qualify, your program should - be reasonably large (at least several hundred lines) - be reasonably reproducible (no user input etc.) - preferably not use signals, processes, or X - take around 5 seconds to run (on a SS-10, excluding initialization, with warm code cache) In exchange for providing me with a benchmark, you'll get - complete guaranteed immortality by virtue of being mentioned in at least one (1) paragraph of my thesis - my eternal gratefulness - and, quite possibly, a better and faster Self system! If you've written a Self program that might fit the above criteria, please let me know. Thanks! -Urs

1 0

unix chdir
by MCR＠physics.carleton.ca 18 Jun '93

18 Jun '93

Due to strangeness in various places, possibly emacs related, my Self doesn't always start up with the right current directory. Sometimes _DirPath fixes it, sometimes not. Suggestion for the next release: unix chdir: 'foo' I added it to unixPrimTemplates, and recompiled, and I'm happy now. I am considering just removing xlibPrim.wrappers.c from the basic build since I'm using the dynamically linked stuff. Is there an overview document on how the Makefiles are organized?

1 0

Algebra Assistant demo and Self documentation.
by MCR＠physics.carleton.ca 06 Jun '93

06 Jun '93

a) I just dropped a snapshot (not a _WriteSnapshot!) of my code in ~/contrib for James. If nothing else it provides some possibly good examples. It does open an X window, btw. b) What did you guys use to generate the Self documentation? Specifically, I am asking about the object diagrams. For some reason I think you used Microsoft Word... I am a latex person, but I'm not having much luck getting something nice out of xfig. (I've got the pictex macros too now)

1 0

Re: How expensive is building canonical strings?
by R James Noble 03 Jun '93

03 Jun '93

> It's probably not blindingly fast but fast enough to handle a few > thousands of events per seconds I've used this to do mouse-sensitive buttons using X - when your cursor is over a button, the button is highlighted. I found it was usually fast enough, modulo environmental effects (scavenging, GC, recompilation, swapping, paging, anyone else using the machine, or any other self thread doing anything). These tend to swamp a single string canonicalise or perform! I was going to try real point-by-point mouse tracking but didn't get round to it. I guess the solution to this is to buy one of them new-fangled multiprocessor suns, and then parallelise the Self threads, the compiler, and the GC... kjx

1 0

Re: How expensive is building canonical strings?
by urs＠cs.stanford.edu 02 Jun '93

02 Jun '93

> In eventWater dispatch, it uses sendTo: With: > The receiving is a string built up by putting a ':' at the end of the > event name. > [...] > I'm wondering how expensive this type of run-time look up is. > It just seems to me that building a string, and making it canonical > (which presumably involves searching through the equivalent of the > `atom table') could be quite an expensive thing to happen for every event. It's probably not blindingly fast but fast enough to handle a few thousands of events per seconds. If the selector is relatively constant (i.e. you're performing 'foo:' several times in a row) the perform is actually very fast. So the answer is "yes it's probably slow but it hasn't ever been a problem for us so far". (In any case, the _Perform is probably slower than the canonicalization.) But you point to a real problem: in 2.0.1 it's hard to tell where the time goes since there are no real profiling tools. However, we've made good progress on this issue - our current system has a source-level profiler that could tell you exactly how much time you spent in the string canonicalization or in the concatenation. > p.s. while I've got your attention: putting '.' at the end of statements > in a _RunScript'ed file doesn't work. This is really annoying when converting > code from simple statements into a method. Someone said this might be fixed > in 2.0 when I mentioned it in 1.1, but nothing has changed. If someone wants to > point me towards the appropriate C parser files I'd appreciate it. I think that > Parser::testDone has to be willing to eat '.' tokens while looking for ACCEPT, > but I'm far from certain from a cursory glance at the code. Yes, we forgot to fix this in 2.0.1, sorry about that. The right place to fix it would be readExpr() in parser.c. After the line e = parser.parseExpr(t, true); insert t = scanner->get_token(); // eat extra period at end of expr if (t->type != '.') scanner->push_token(t); -Urs

1 0

How expensive is building canonical strings?
by MCR＠physics.carleton.ca 01 Jun '93

01 Jun '93

In eventWater dispatch, it uses sendTo: With: The receiving is a string built up by putting a ':' at the end of the event name. I'm wondering how expensive this type of run-time look up is. The fastest way is probably a case statement (which would reduce to pointer comparisons for canonical strings), with specific method lookups there. I see the problem with maintenance in this case though. Alternately, maybe the event could have a `dispatchTo:' method that does the right thing. It just seems to me that building a string, and making it canonical (which presumably involves searching through the equivalent of the `atom table') could be quite an expensive thing to happen for every event. I'm not sure at all how much time is spent doing this, probably not much compared to actually handling the event, but if you are just discarding that event anyway... p.s. while I've got your attention: putting '.' at the end of statements in a _RunScript'ed file doesn't work. This is really annoying when converting code from simple statements into a method. Someone said this might be fixed in 2.0 when I mentioned it in 1.1, but nothing has changed. If someone wants to point me towards the appropriate C parser files I'd appreciate it. I think that Parser::testDone has to be willing to eat '.' tokens while looking for ACCEPT, but I'm far from certain from a cursory glance at the code.

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