Current TODO list

Brian T. Rice water at tunes.org
Tue Aug 17 11:54:49 PDT 2004


Hi all,

I'm finding myself with a few too many ideas and the list of things to 
implement is building up, so I thought I'd share the current list and 
hopefully get some feedback or possibly even volunteers to help or do 
themselves.

The major project is concurrency, and I'm kind of keeping that to myself 
for now, mostly as it involves a certain amount of research and too many 
design choices to spread out.

Small tasks, in no particular order:

Iteration across objects in the image:
   Squeak has a protocol for going through each object in the image, 
using "firstObject" and "nextObject", or for class-instances, 
"firstInstance" and "nextInstance" which are somewhat unreliable with 
real concurrency, but in a stream interface you get what you ask for. 
The primitives would be _ at lobby or _ at Image firstObject and 
firstUserOfTraits: and nextObjectAfter:, nextUserOfTraits:after: based 
on the pidgin code in memory.slate which is filled in by the GC 
module(s). Pidgin methods are: firstObject, firstAccessibleObject, 
accessibleObjectAfter:, initialInstanceOfMap:, nextInstanceOfMap:after:, 
initialDelegateTo:, nextDelegateTo:after: at the head of that file. This 
is pretty easy but I have a bunch of things on my mind right now and it 
would be better for someone else to learn with.

Instrospective methods on CompiledMethods, etc.:
   Finding out what selectors are sent by it, for example. Some of the 
advanced protocols depend on being able to iterate through users of a 
traits object in the image, like being able to ask for the callers of a 
message or method. (Or just collecting all the users of a traits.)

BSD Socket primitives:
   This is kind of a no-brainer, but no one's working on it that I've 
noticed. Just take the existing file code in vm/ext/ and vm/platform/ 
(and vm/platform/foo/) and write similar primitives for Slate, so that 
we can do some basic network programming.

Ability to detect the host platform and conditionalize on it:
   The core of this is really simple, just getting a string name for the 
host type. Some utilities on top to perform some basic things and to 
help us with actual robust filepath-handling would be a big help.

REPL improvements, integration with terminal.slate/vt220.slate/new code:
   I have ideas about this, but maybe someone else can handle this 
better than I can, or get some important legwork done figuring out some 
decent input-handling defaults. The parser needs to be decoupled from 
line-editing, so that lines get passed to the parser and are only 
evaluated once the parser can make sense of the whole body, and so that 
these handlers can be used.

Whew, I think that's enough for now. :)

Of course, with all of these, testing helps, and I'll gladly get the 
code incorporated into CVS and alpha tarballs to give it exposure.

If any of these sound interesting, ask questions and I will gladly fill 
in the details.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: water.vcf
Type: text/x-vcard
Size: 208 bytes
Desc: not available
Url : /archives/slate/attachments/20040817/c9aaa3c0/water.vcf


More information about the Slate mailing list