[fonc] Maru: deprecating eval.c
Hi, I was wondering how much interest is out there to create an alternative version of Maru's emit.l that emits bytecode for a tiny C-based VM. In my mind, we'd generate a single portable C file, which would interpret an embedded data array representing the compiled program. If such a emitvm.l existed, then we could do away with the hand-written eval.c and make changes only to eval.l, and regenerate eval.c from there. Is that in line with your plans for the project, Ian? Thanks, -- Michael FiG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Maru virtualisation and traps
Hi Ian, Would you be interested in merging (future, currently vapourware) patches to bring something akin to the COLA kernel abstraction to Maru? Would you like this kind of thing as a user-contributed module, or incorporated as a core feature? For those who haven't read the paper: http://www.vpri.org/pdf/m2009007_COLA_kern.pdf The intent will be eventually to virtualise all functionality that can affect resource usage (i.e. security holes, denial of service, infinite loops, allocations). Here is how I imagine it working. For efficiency, the traps would be stored as a flat vector of functions each with their own unique integer ID offset rather than a single function taking arbitrary arguments and a data array as in the paper. This tradeoff makes trap numbers more valuable (and potentially exhaustible), but at least they can be dynamically allocated so that they are only present if your code actually uses them. The bootstrap trap vector will contain just one trap number: ;; Trap to allocate a new trap number. (define TRAP_NEW_TRAP_NUMBER 1) To fully virtualise and close off all trap number exhaustion denial-of-service attacks, that trap can be replaced for a locked-down version that just throws an error. The other primitives are: ;; Invoke a trap identified by a function stored in the current trap ;; vector at offset TRAPNUM (trap TRAPNUM ARG...) (apply-trap TRAPNUM ARGS) ;; Create a new trap vector, inheriting from the current trap vector ;; and override the new vector with the non-nil trap entries in VECTOR ;; Run (apply FUN ARGS), and when finished, restore the prior trap vector (apply-with-traps VECTOR FUN ARGS) For bootstrap, I can imagine something like this: ;; Virtualised exit function. (define TRAP_EXIT (trap TRAP_NEW_TRAP_NUMBER)) ;; Set up the vector for first virtualisation (let ((boot-traps (new-array 0))) (array-at-set boot-traps TRAP_EXIT exit) (define-function subr_exit (args env) (let ((status (and (is long (k_car args)) (get_long (k_car args) (trap TRAP_EXIT status))) ;; Enter the virtualised environment... (apply-with-traps boot-traps main argv)) Thoughts? -- Michael FiG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
Hi, John Nilsson j...@milsson.nu writes: So my fix is to make the separation a hidden thing, which means the program needs to be represented in something that allows such hidden things (and I don't think Unicode control characters is the way to go here). Why not crib a hack from JavaDoc and make your nested syntax embedded in comments in the host language? -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: t-shirt attempt
Hi Chris... I finally had some time to address the points you made in you reply. Chris Warburton chriswa...@googlemail.com writes: If I understand correctly then there's the potential for ambiguities to arise if we differentiate WRT 2 different objects, and we're calling the same method on both. Actually, there isn't. The 'bind' operator takes a closure as its first argument, and generates a new closure where the specified formal parameter (named by the second argument) is bound to the value in the third argument: NewMethod = bind(OldMethod, 'OldMethodArgN', Value); The 'explicit' operator is also unambiguous. It takes a binding from the closure's lexical environment and turns it into an explicit argument: NewClosure = explicit(OldClosure, 'OldClosureLexVar'); I'm changing my mind on things here: the NewClosure should always take the old lexical variable as the first argument (not as the explicitly named N in Nth argument). If a different ordering is needed, the caller can construct a wrapper method for it. As for the other direction, I've personally been thinking about a similar method of automatically abstracting functions. Rather than injecting new arguments, we generate a separate, more generic function from which we can reconstruct the original function by specifying the arguments. I think this would be a lot harder to use in practice without a lot of reflective capabilities. How would we anticipate the number or types of the arguments? I think the parallels with your notion of more-implied = derivative and more- explicit = antiderivative is interesting, and would value people's thoughts. Me too! Thanks a lot for writing back, this is indeed interesting to me, -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: t-shirt attempt
I just wanted to say thanks for the note, Chris. I'll reply publically when I have a chance to digest it! -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Re: t-shirt attempt
Hi,
Ian Piumarta piuma...@speakeasy.net writes:
It's an interesting take on calculus of programming! (I'm not sure
you can really call it differentiation since the function you're
differentiating isn't continuous, and I'm not sure what a tangent
might mean to a piece of code, and even then you might have to call it
partial differentiation as there are often other independent variables
that you could have chosen. But I digress.)
That is a good point. It's probably better to define and name new
operators.
There are clear parallels between your differentiation and simple
macro expansion. [...] Actually, maybe what you are doing is more
like partial evaluation (in the derivative direction)
Yes you're right, it is partial evaluation. If I generalize what I said
earlier a little bit, we should be able to move any formal parameter
from the argument list into the method's lexical environment.
I'd suggest that kernels can optionally offer a symbol named '_' to
represent themselves as a value.
So what I called d.meth(..., Arg, ...)
-
dArg
is better written in Sandstone code as a binding of Arg to the kernel
.method2(...): bind(.meth(..., Arg, ...), 'Arg', _);
or more generally, for any value:
.method2(...): bind(.meth(..., Arg, ...), 'Arg', Value);
is like writing:
.method2(Arg1, Arg2): {
Arg = Value;
... body ...
};
and partial abstraction (or whatever the opposite of evaluation is
called, in the integrative direction).
Maybe explicit, to move a binding from the lexical environment into a
formal parameter?
integral(.meth(...), {prim1, prim2})
goes away, to be replaced by a construct to make a lexical name into an
explicit parameter:
.method2(..., ArgI, ...): explicit(.meth(...), '_', I);
These definitions make for a much saner implementation that needs only
create a new method binding with a different lexical environment and
formal parameters list. No modification of the code body needs to be
made.
The search for the meaning of eval is definitely a worthy one.
I've been thinking of the meaning of eval more and more as a property
of the environment, completely outside the physical statement of the
program and independent of any intrinsic mechanisms of an
implementation.
The environment determines entirely the semantics of
the program: it's a partial function between representation and
meaning. For compilation, which is a sequence of your
[binds] or something similar, each step in the sequence is
the environment partially evaluating the representation to get the
next lower level of abstraction... until you reach machine code.
There's a lot in common with kernels here, but maybe orthogonal to
them.
What I'm calling a kernel is a simple generalization of the kernel
idea you and I developed last time I was in LA. I've moved all the
compiler/interpreter functionality into a kernel which chooses how to
evaluate/compile the method, choosing to hide or make portions of itself
available via the syntax.
The above bind/escape methods are ways of exposing the kernel's ability
to compile to methods within the language.
Instead of searching for more powerful or more primitive
behaviours, the environments are mappings between more or less
abstract representations of (hopefully) the same behaviour.
In the sane case. In an less sane case, I consider the kernel interface
as a generic way of traversing the code of a method as a data structure.
The evaluator in the tiny Lisp-like thing that I posted a couple of
months ago (called Maru) works exactly this way. The partial function
aspect isn't explained in detail in the paper, but the key is to put
the evaluators and applicators arrays in the environment; the rest
follows easily from that.
I'm not sure I like that idea, but I'll have to see how you implemented
it. I had fun with a system called Pliant (http://fullpliant.org/) that
was highly reflective in that way, but caused phase problems when trying
to cross-compile code because the compiler was an ambient authority and
fully first-class.
I wonder if it's possible to integrate binary code to get the
original source? It would save an awful lot of tedious back pointers
to intermediate structures and parser rules. I'm going to have to
think about this some more.
I'm not sure about that. I think the sweet spot would be to find a
compact but lossless binary representation (of Sandstone, of course) and
run compilers, interpreters, debuggers, and decompilers on it. I
consider Sandstone to be my answer to UNCOL or ANDF... it is a data
representation format that happens to support object methods in a
compact notation, but leaves all interpretation completely up to the
kernel.
Thanks for your comments,
--
Michael FIG mich...@fig.org //\
http://michael.fig.org/\//
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman
Re: [fonc] English language literacy software?
Hi Frederick, Thanks for the links. My favourite was the information about twext... it looks really cool. -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] English language literacy software?
Hi all, This is tangentially related to the broad ideas of computer and mathematics literacy that Alan has, and so I would like to ask the list for your opinions and advice. (If you have things to share that are not related to computing, please reply to me privately.) My wife, Susana, works at an agency that helps immigrant families from all over the world settle in Canada. They are currently looking for software or online resources to help improve literacy for youth (and possibly younger children), sometimes teaching EAL (English as an Additional Language) from square one. Susana and I saw some connection with VPRI, as at least some of the children have little past exposure to computers, and that literacy is not about a specific language, but about solidifying new knowledge with experimentation and creative expression. I've admired Kim's handbook that guides math learners through Squeak-based experiments. Is there an approach embracing this model (computer as an empty world for performing experiments, not as a multiple-choice quiz automator) with exercises involving language? To give some political context, the conventional advice currently on the table is to license Rosetta Stone for children. Do you see better alternatives? Does this belong in the scope of FONC? Thanks, -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] microscopes/telescopes
Hi Paul, Thanks for your detailed post. It's inspiring me to share a little about my current work and understanding of VPRI's general approach (though, again, I should remind folks that I don't represent VPRI even though I had the pleasure of working closely with Ian in the past). You've cited too many references for me to absorb right now, but it is definitely convincing me that once I've bootstrapped my Perl-based language lab (much inspired by the latest things I saw Ian working on, as well as OMeta, but with closer links to Knuth's attribute grammars than to PEGs proper, and much less effort because I can do portable coroutines via Perl 5's Coro library) I should use it to bootstrap a Javascript version. An important lesson I learned from Ian and ANTLR was that the grammar's description should capture as much information as possible but not specify actions, so that different clients can use the same grammar for different purposes. A language lab is defined by its default syntaxes, whether human or computer-readable. I have aspirations for creating a simple, compact, extensible syntax that people love enough to support on many computer systems, both as a programming language and as a communication protocol (and no, it won't be XML or sexprs). The software involved is bootstrapping an interpreter library on each platform, and giving it access to as many target primitives as possible. To survive as a communication protocol, it needs to use an object-capability model of some sort because sandboxing leads to insanity. With first-class grammars for describing arbitrary languages/protocols/data structures/agent network configurations, a microscope/telescope app that dynamically utilizes such descriptions is not far away. Each new platform we port to effectively becomes a platform we can run on, analyze, and extend. A generic stage 0 interpreter/compiler lab for the default language would be able to specialize into a stage 1 lab for any language by statically attaching bootstrap code to a specific grammar. Non-lab applications could be the byproduct of asking a lab to compile other inputs. So, in short, I think we need exactly one level of abstraction above the Semantic Web in order to make a true end run in the convergence game. Legacy systems of all sorts need to be described and preserved, not rewritten and rearchitected in a standards-compliant way. BINGO! (For everybody playing Programming Language Buzzword Bingo with my post.) For those interested in the Perl implementation of my Ocean language lab, it's a self-replicating single file whose embedded grammar descriptions you can edit and run to bootstrap your own Perl-based lab, interpret a script written in the lab's supported languages, or play around with a REPL. I'll be posting here when I get it to the point of being clean enough for others to use. Thoughts? -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] precise gc
Hi, [Sorry for not replying earlier... this got lost in my inbox somewhere.] John Leuner je...@subvert-the-dominant-paradigm.net writes: It's not clear to me how you can distinguish between an object pointer and an integer at garbage collection time? I assume your figure language is not typed (doesn't have a type checker), Yes, you're correct. unless you're able to use the C type checker for that? No, I can only use the C type checker for early-bound bootstrap calls, since everything is late-bound either through Figure's multimethod bind or an untyped ccall. Besides the stack frames, can you distinguish between integers and object pointers in heap allocated objects? Every gc root is either a tagged integer (low bit set, a la Cola) or a pointer to an object with a header that was allocated by the runtime. The header specifies the allocated size, garbage collector metadata, and multimethods that the object participates in. Each list of multimethods begins with a special method that specifies the object's debug name and a function that folds over the object's tagged/pointer elements (but not the opaque pointers allocated outside of Figure, or raw C integers). So, an object can use whatever encoding it wants to for its data, so long as the fold function decodes the pointers correctly. This is exploited to properly type the object representing the registers of the VM, which may contain raw C integers and pointers as well as tagged integers or object pointers. The incremental garbage collector calls each root object's fold with a function that adds white objects to the greylist, then folds over and blackens each greyed object until there are none remaining. Then, the sweep phase frees all the old whitelisted objects, then invokes any destructors for the newly whitelisted objects. Hope that explains things a bit better, -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] precise gc
[Unlike John, I don't have a blog, so I'm going to send this to the
list. I hope to help influence COLA's future, and so I'm posting
things here as I learn them.]
Hi,
I noticed that both Church-State and the current COLAs depend on
Boehm's libgc for conservative collection. I have long been pondering
a design for an ultra-simple precise mark-sweep GC with an ABI and
macros that don't put too much burden on a C programmer (since I am a
C programmer, and will probably stay that way for a while).
My design for Figure has been to create a meta-machine (I'm not sure I
can call it a virtual machine), which is calling convention compatible
with the platform's C environment. The idea is to unify the language
that describes low-level calls (i.e. any arbitrary C primitive or
function call) with the language for high-level calls (prototype
multiple dispatch).
In trying to reconcile these issues, I've been forced to make several
mechanical transformations to my C sources, until I've evolutionarily
discovered a style that supports the ABI. That style includes
reifying stack frames and a single return register, so that there is a
clear path for the GC to trace. The way I've chosen to do this is to
pass a single pointer to every high-level call (and as much of the
mid-level runtime as possible), without imposing any burden on
functions that are called below. This also means that there are no
global variables in Figure (well, just one, but I'll get rid of that
one after I finish writing this e-mail).
The ABI for a typical piece of code looks like this:
/* Think of Gut as the high-level object type system. */
typedef void *Gut;
struct _Figure
{
[...]
KSFrame *frame;
/* This is the return pseudoregister. Every function puts Gut
results in here so that the precise garbage collector can find
them, no matter what program state. */
union
{
/* This is a union only so the callee can avoid tedious
typecasting. */
ptrdiff_t i;
Gut p;
GutFun f;
} x;
/* This is nonzero iff X should be traced by the precise GC. */
int x_is_gcroot;
};
Where KSFrame is:
struct _KSFrame
{
KSFrame *caller;
#ifndef NDEBUG
/* Current source location. */
char *file;
char *func;
int line;
#endif
[more high-level call information, such as object states and selves...]
};
I've annotated this function to try to explain better:
static void
skin_parse(Figure *f, GushInput *in)
{
int c;
/* Create a new frame, called ks, and link it into Figure's call
stack (f-frame). Declare before and quote as objects that
need to be traced by the precise GC. */
ks_enter(f, GushInput *before; Gut quote;);
/* Make a high-level call to skin_parse_spaces (imported into the
current module). */
gut_call(f, skinParseSpaces, in);
/* Clone the input stream. */
gut_clone(f, in);
/* Assign the cloned pointer to the before temporary. */
ks.before = f-x.p;
/* Read from the input stream. */
gut_call(f, read, in);
gut_raw_integer(f, f-x.p);
c = f-x.i;
if (c == '(')
gut_call(f, skinParseList, in);
else if (c == ')')
/* Signal a condition, which is a restartable exceptions. */
gush_error(f, ks.before, skin, too many close parentheses);
else if (c == '.')
gush_error(f, ks.before, skin, unexpected improper list separator);
else if (c == '')
gut_call(f, skinParseString, in);
else if (c == '-' || isdigit(c))
{
/* Restore the state of the input stream from the cloned copy. */
*in = *ks.before;
/* Parse the number. */
gut_call(f, skinParseNumber, in);
}
else if (c == '\'')
{
/* Implement syntactic quote sugar. */
gut_name(f, quote);
/* Save a reference to the quote symbol. */
ks.quote = f-x.p;
/* Parse the next object. */
gut_call(f, skinParse, in);
/* Create a pair out of that object and the empty list. */
gut_pair(f, f-x.p, f-gut-empty_list);
/* Add the quote symbol. */
gut_pair(f, ks.quote, f-x.p);
}
else
{
/* Restore the input state. */
*in = *ks.before;
/* Call the name parser. */
gut_call(f, skinParseName, in);
}
/* Pop the stack frame without modifying the return register.
(Take the result of the last call as the value. */
ks_leave(f);
}
There are other ks_*leave* macros that allow setting of the return
register, and marking it as a gc root or a raw value.
You can see that this creates a much more asm-like flow. There are
very few expressions, just statements (nearly every function returns
void).
Next on my agenda is actually implementing the mark-sweep collector,
and after that, multithreading! Whoopie!
As usual, the state of things is at:
http://michael.fig.org/figure.c
Figure.sln and Figure.vcproj are also there for the VC++ enthusiasts
(but not yet tested for this latest iteration). There is only dlopen
to port to new platforms, everything else is ANSI.
That's all for now,
--
Michael FIG
[fonc] Re: precise gc
Michael FIG mich...@fig.org writes: As usual, the state of things is at: http://michael.fig.org/figure.c Figure.sln and Figure.vcproj are also there for the VC++ enthusiasts (but not yet tested for this latest iteration). There is only dlopen to port to new platforms, everything else is ANSI. BTW, I've updated the source to make the VC++ build work again. Have fun, -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Output streams vs. values
Hi,
Tony Garnock-Jones tonygarnockjo...@gmail.com writes:
In short, the communication between the two programs would be
messages about speculative output (and about begins, commits, and
rollbacks), not messages carrying committed output.
This is really an interesting idea! Here are some details I've worked
out:
struct Buffer
{
SEMAPHORE_T new_buffer_or_rollback;
void **data;
size_t len;
struct Buffer *next;
};
struct Transaction
{
SEMAPHORE_T new_buffer_or_subtransaction;
struct Buffer *first, *last;
struct Transaction *parent, *child;
};
To create a new transaction, an empty Buffer is assigned to tx-first
and tx-last (this provides a sentinel object for readers to block
on), tx-parent is the parent transaction and tx-parent-child = tx.
Of course, this means that only a single writer can have a published
transaction via the tx-child link, though there shouldn't be any
limits on having multiple other writers use private transactions.
A semaphore on Buffer blocks the transaction's reader until more data
is available (i.e. another Buffer has been atomically appended), or
the transaction is rolled back. A semaphore on Transaction is raised
when more output is added to this transaction or a published
subtransaction is begun.
I don't think there's a reason to provide an explicit commit message
to the reader: they just read the transaction that they're interested
in, which may be the toplevel transaction if they only want to see
toplevel commits.
So, regular readers would walk the toplevel transaction's tx-first
list, and wait on the buf-new_buffer_or_rollback semaphore when
they reach buf-next == 0. Speculative readers would do the same, but
monitor the tx-new_buffer_or_subtransaction semaphore and descend
into tx-child when there is a subtransaction.
When transactions commit, we just do a compare-and-swap to get
subtx-parent-last-next = subtx-first, and subtx-parent-last =
subtx-last. When they rollback, we set all the transaction's buffers
to len = 0 and next = 0, raising buf-new_buffer_or_rollback, so
that readers know there's a rollback, and set subtx-first =
subtx-last = 0 so that writers can rollback instead of commit,
subtx-parent-child = 0.
I'm implementing this in Figure now for all of its output streams (the
repl was asymmetric before now; input was done through buffers that
could be rolled back by resetting the World pointer, but output was
direct to stdout). It's a little more encapsulated than described
above, because any per-object semaphores and the functions that use
them are stored in closures corresponding to methods on each
individual Transaction and Buffer, not in visible struct members (I'm
insistent on making Figure independent of the underlying concurrency
mechanism).
This is getting fun! Thanks for the reply,
--
Michael FIG mich...@fig.org //\
http://michael.fig.org/\//
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Figure (help with streaming parsers)
Hi, John Leuner je...@subvert-the-dominant-paradigm.net writes: Can you elaborate on how you see parsing and multiprocessing working together? Why do you need a parser to produce a stream of values? It's not that I need a parser to produce a stream (Figure streams are independent of parsers), so much as using streams to connect parsers allows them to take advantage of multiprocessing. Other code can send and receive messages via these buffered streams in different ways (such as mailboxes or queues). BTW, the work you've been doing lately on Church-State looks quite cool. I'm trying to dig into it more now. Have a good day, -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Figure (help with streaming parsers)
Hi, Alessandro Warth alexwa...@gmail.com writes: All you would need to add to OMeta in order to support streamed output (if I haven't completely misunderstood your question) is a new kind of semantic action that adds a new value to the end of the output stream. Thanks, you described exactly what I'm looking for. p.s. I think that one of Ian's parser frameworks had / has support for streamed output, but I don't know any details, so it may or may not work in the way I've described here. jolt2.5 (some files that Ian sent me) had an invoke rule (RULE) to execute another parser and parse its output, but it wasn't done asynchronously, and the relationship between the parsers was fixed at grammar definition time. He may have done something other than that, but that's the closest I've seen to streaming. -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Figure (help with streaming parsers)
Hi all, I'm writing to ask Alex, Ian, or anybody else about a good way of extending OMeta or another grammar system to include optional streamed output. I've been experimenting with Figure, a small runtime environment written in C that has some similar sensibilities as COLA, but with the following different features: * Preferred single inheritance, with fallbacks to prototype delegation with separate self/state values (like libid's split between stateful_self and self). * Prototype multiple dispatch (see Saltzman and Aldrich) for high-level functions dispatched via a symbolic name followed by tagged arguments. Low-level functions are calls made with an integer as the head of a list and any arbitrary arguments (which don't need to be well-formed objects). * World argument to every high-level function reifies stack information, current object model, fundamental data types, any thread-specific information, etc. * Lisp-like signalled conditions with restarts allows for implementing exceptions or other unusual control flow (one frame signals a condition, any number of intervening frames offer possible actions in response, and an outer frame decides what to do). * Optional early binding allows lexical scoping and bypasses multiple dispatch for optimization or compiling down to zero-runtime code. * Aside from external threading libraries used explicitly by other components (such as pthreads, pth, libcoro, etc), multiprocessing is implemented by arranging parsers as a pipeline and invoking them with a specific scheduler. This requires a small extension to OMeta or Ian's new grammars to allow a grammar's production to return a stream of values (which reduces to a list if the caller expects a single value instead of a stream). I'm currently working on the grammar and scheduling features. I intend to implement the garbage collector as another parser pipeline. I'm quite interested in working on this system until it bootstraps and then merging anything useful with John's Church-State and/or COLA. If you would like to play with the system as it exists so far, it's currently available at: http://michael.fig.org/figure.c It's short on documentation, but there's a few pithy comments in it. Have fun, -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Ocean core language
Hi, Colin Putney [EMAIL PROTECTED] writes: On 16-Sep-08, at 6:16 AM, Aaron Gray wrote: But it's not that at all. I'm implementing runtime dynamic typing for a statically typed system i.e. verification, not optimization. 'for' or 'on top of ' or 'underneath' ? The normal C static typing will be only in the source language. The dynamic typing is underneath, at runtime. If I understand correctly, he's basically extending C. So it's adding runtime type information and the ability to reflect on it to a system that already has static, manifest typing. That ought to be easier than type inference. That's exactly correct. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Ocean core language
Hi, John Leuner [EMAIL PROTECTED] writes: In my Church/State implementation I have implemented a low-level (C like) language and a seperate high-level language (in COLA style). Sounds interesting. I'll have to look at what you have again (I believe yours was the Common Lisp bootstrap implementation?) and get some more ideas. I'm interested to see if you can achieve the mixture of dynamism and C compatibilty within the same source language. Yes, that's a key goal I'm trying to accomplish. I guess time will tell. What language will you write your compiler in? Will you use C for the runtime? I would like to make Ocean self-hosting, and I think the fastest way to do that would be to implement it using jolt3's codegen (once it lands). Metaprogramming and static compilation are probably the first features to be worked out, so that the rest can be bootstrapped from there. On another note, have you been following Ian's work on jolt3? Do you have any updates or insights to add to your earlier summary? I haven't looked at the latest batches of commits yet. I'm on vacation this weekend, but I expect by next Tuesday that I'll look at jolt3 again (maybe with an eye towards doing some architectural spikes for Ocean). Cheers, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Ocean core language
Hi, [Kjell, I'll respond to your comment later... I still need to think on it for a while.] John Leuner [EMAIL PROTECTED] writes: You talk about oop pointers and runtime metadata, is this just used for safety and GC, or do you plan to implement OOP features like dynamic dispatch? That was an item that was missing from my original laundry list: * Prototype multiple dispatch Supports late-bound ad hoc polymorphism. http://tunes.org/~eihrul/talk.pdf p.19 There is no such thing as object methods or functions, rather everything is a multimethod and function names are selectors. Function pointers are simply variables that contain a selector. Multimethods all are called with an implicit first argument that is the present module object, which delegates to any number of other objects representing parent namespaces (such as a library's internal members, a current program space, or shared OS state such as a filesystem root). Variables are stored as members of the module object or any object along its delegation chain. Do you intend your implementation to be source compatible with C? Yes, except for requiring the layout keyword and disallowing unsafe pointer operations, Ocean should be able to compile GNU C. To me the usefulness of a language like C rests on the fact that there is no runtime overhead (for accessing structures or pointer arithmetic) and this is enabled by requiring the programmer to provide static type information. It seems mismatched to have both static and dynamic type information? I neglected another important aspect of Ocean: The full ABI is not compatible with standard C (and, indeed, will not link with standard C object files). Disabling certain features will yield different, incompatible ABIs, which will be more efficient but less powerful than the full ABI. Ocean is designed so that disabling all Ocean-specific features will produce a C program with no additional runtime overhead, and compatible with the operating system's default ABI. All code linked to produce a program, including all its library dependencies, must be compiled with the same ABI. Because Ocean is both a compiler and interpreter, it can be used as a plain-old-C interpreter with whatever degree of safety you choose, depending on the enforced ABI. In other words, Ocean is designed to be a proper superset of C, which only needs layout annotations to be able to run with full memory safety. C programmers should be able to use Ocean like Purify or Valgrind to help find memory bugs. Then, the idea is that C programmers can start playing with the more dynamic features gradually. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] delMDSOC - the MDSOC kernel
Hi, Michael Haupt [EMAIL PROTECTED] writes: please experiment and let us know what you think. :-) Very interesting! This is a lot of work, and will take some time to understand and analyze. I'd be most interested in finding out if there were any particular difficulties you had to work around that could lead to improvements in future versions of jolt. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] BitC
I've been perusing the BitC documentation, and note that they are gearing up for a major release. Here is the current language specification: http://www.bitc-lang.org/docs/bitc/spec.html They are much closer to the ML side of things than the Lisp side (though they also have a sexp syntax), so they are mainly concerned with providing low-level performance within the context of type safety. In any event, their ideas may be interesting, especially those of features for separate compilation. Maybe somebody else on this list more familiar with BitC can share some impressions? -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 64-bit? was: fonc on ubuntu.
Hi,
Ian Piumarta [EMAIL PROTECTED] writes:
Hmm, Mac OS has a /usr/lib/readline that doesn't provide the above
function. (It looks like a wrapper around the BSD editline
library.)
I did the below patch chunk to funcion/objects/_debug.c, which does
the trick for Tiger. Whatever works for you should be fine, though.
Readline is an, ahem, interesting beast to work with.
Methinks it's time to reconsider the whole readline dependency.
Perchance it is.
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
@@ -511,6 +516,9 @@ static char *argumentGenerator(const char *text, int state)
static char **debugCompletion(const char *text, int start, int end)
{
+#ifndef RL_READLINE_VERSION
+# define rl_completion_matches completion_matches
+#endif
return rl_completion_matches(text, start ? argumentGenerator :
commandGenerator);
}
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] New GIT repositories
Hi, I've updated the instructions at http://vpri.org/fonc_wiki/index.php/Sources to reflect the new repositories I've just finished setting up. Note that the old ones (cola.git, cola-patches.git) are obsolete, mostly because I screwed up git-svn, and now as per the discussion on this list, I'm maintaining cola-patches.git as separate branches in the new ocean.git repository. Please do give ocean.git a try, and let the list know if it fails you in any way. I really do want to be responsive to any changes you need, and get them merged into ocean so that everybody who uses it can test them and improve them to eventually be merged upstream into COLA proper. The next thing I'll be working on myself is 64-bit support (by the kindness of Karl Robillard offering part-time access to an x86_64 box). Have fun, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] git users?
Hi, Krzysztof Kowalczyk [EMAIL PROTECTED] writes: Don't you have this problem in both cases? If the changes are independent, it shouldn't matter whether they are in the form of a patch file or in git (in which case they can be extracted as patches). The problem that I have is of interleaved changes. I work for a little on patch A, then patch B, then patch A again, but A and B should be kept separate so that they can be easily reviewed. A and B may or may have dependencies on one another. Of course it all depends on what form Ian would find convenient - Yes, that's ultimately the deciding factor. I think it's up to me or somebody else to find out what that workflow really is/should be. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] git
Hi, Steve Folta [EMAIL PROTECTED] writes: I'm not gonna rewrite your script, but maybe these rough equivalences (sometimes very rough) can point you in the right direction: Thanks Steve, I think I've got something working without Cogito now. Felix Rabe [EMAIL PROTECTED] writes: Krzysztof Kowalczyk wrote: I'm on Windows, using Cygwin version of git. I don't think cogito even exists there. Straight git would be much preferred. +1 for straight git, though I don't run any Microsoft software +myself. The guilt scripts are still necessary for managing my patches, but that shouldn't be much of a burden for cygwin/msys users. I think it would be preferrable for one central place to mirror using git-svn, and the other git users cloning from that place. For testing, I'd suggest people use git://fig.org/cola.git as the place to look for the SVN import. If/when Ian adopts Git, I would gladly help move this repo to VPRI. I've written up instructions for GIT on the Wiki: http://vpri.org/fonc_wiki/index.php/Sources -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] git users?
Hi, If anybody out there actually uses my GIT repos to fetch COLA and/or compile it with my build fixes, could you let me know? I'm interested to see if the people who encouraged me to use it will benefit from it, or if it was just the famous GIT evangelism at work. :P Again, the repository info can be found at: http://vpri.org/fonc_wiki/index.php/Sources My patches should work as advertised: they get COLA to build where Ian's SVN trunk still has a few errors in it. Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] the miracles [was: My visit to VPRI]
Hi, Thiago Silva [EMAIL PROTECTED] writes: Is there anything that could be shared/discussed about the miracles at this point? I really would like to know what is known about them (and what is not), possible directions for experimentation, etc. Any thoughts? Actually, I don't know much about this topic either. I've mostly got my head buried in the idst code. However, would somebody at VPRI like to say something about this? -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] public Mailman archives [was: wiki and communication]
Karl Robillard [EMAIL PROTECTED] writes: Can the mailing list archive be made public so we can link to posts there? I think the main reason this has not yet been done is to avoid spam harvesters. I didn't see any obvious way to configure Mailman to hide addresses (I looked in the Mailman FAQ). Do any of you out there know how to do so? -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] PATCH: id/libid.c: _sendv() handle _sendv() as arguments.
Hi, Kurt Stephens [EMAIL PROTECTED] writes: This little bit of GNU CPP trickery allows the _sendv() macro in id/libid.c to be used as arguments to itself. Interesting! I'll keep this around in case it comes in handy. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] can't build on osx
Hi, Dethe Elza [EMAIL PROTECTED] writes: 1. A pointer on the web with current working instructions labelled Start Here Ultimately, that's what the wiki should be. I think the problem here is that nobody who both knows Id well enough and also has compiled it on OSX has also written up their experiences there. I should be able to get to it someday, but I'm new to my Mac (I have 10.4), and haven't tried compiling Id on it yet. 3. Get the bootstrap to the point where typing make does the right thing, or at least ./configure;make That's what should happen now. I know for a fact that Ian's main build machine is his Mac, so it should Just Work, and if it doesn't, please report problems here. Once I can run COLA successfully on my Mac and Windows boxen, I will put up better instructions including patches for those who want to run something more bleeding edge than the last official stable release, but hopefully still working (i.e. I intend to maintain something for COLA analogous to Debian's testing branch, since I need it to do my own development). That's what Ocean is supposed to be, but it isn't quite there yet. 4. (for OS X) have a dmg or zip with a working system (or installer) downloadable Yes, that would be nice. Thanks again for the help in getting started. Once I've confirmed that I do have a working system, I will try to update the wiki page with the steps needed. That would be great! Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 64-bit? was: fonc on ubuntu.
Hi, Nathan Cain [EMAIL PROTECTED] writes: I was only ever able to build on x86_64 using -m32 everywhere [BTW, would you happen to have a patch that you could put up on http://vpri.org/fonc_wiki/index.php/Linux_x86_64 ?] The 4-byte word assumption is built in pretty deeply to Jolt (not so much into idc). I see just a few places in libid that need to be changed, and I'm pretty sure that libgc works correctly with 64 bits. I would be interested in acquiring or somehow otherwise getting access to an x86_64 machine, to work on a port to that architecture, if anybody wants to help me with this. Once I bring my Ocean branch back up-to-date with Ian's tree (he's on Subversion -r422, and I haven't updated since -r410), I'd be ready to tackle something like that. Such a port would also help with making the next idst independent of word size (such as removing the hardcoded 4's and 32's). This would be especially useful in conjunction with static compilation to build binaries for smaller embedded systems (I have access to a specialized 8-bit Motorola HC11 that I'd like to try out). Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 64-bit? was: fonc on ubuntu.
[EMAIL PROTECTED] writes: You can use qemu (http://bellard.org/qemu/) to emulate a 64b system on your 32b one. Thanks, I'll check that out. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] 64-bit? was: fonc on ubuntu.
Hi, Colm Kennedy [EMAIL PROTECTED] writes: getting the exact same message compiling using ubuntu as listed on the wiki for fedora 8. Do you mean the x86_64 architecture? I don't think idst has been tested there, and will probably need some changes to work properly (the function/ directory definitely will). -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] My visit to VPRI
Hi all, I had an opportunity to visit VPRI on Monday and Tuesday, and I just wanted to write a little field trip report to the list so that you understand a little more of the big picture of the STEPS project. I expect that this information will all be really obvious for people who have actually worked with some of the folks at VPRI. Also, as always, you should remember that I don't speak for VPRI itself: I'm just a volunteer contributor who is interested in what is going on with STEPS. I met many of the people listed on http://vpri.org/html/people/team.html What I understood is that the researchers are encouraged to go out in all directions (of course, there are also deadlines to be able to demonstrate an aspect of the system to an interested third party). Even if there are failures, and many throwaway prototypes, they are looking for the miracles that are expected to bridge the gap between the computer hardware and the user experience with powerful and reusable ideas. Another interesting thing is that it's really only Ian who is working on the low-level stuff. The majority of the user interface experimentation is being done in Squeak and Javascript. I would love to encourage the developers to release some of those cool demos, but that's up to them. It really looks like the next version of Jolt (in progress) will be a serious contender to use as the basis of all the other experiments. Ian and I spent a number of hours on Tuesday hashing out the details for the next Jolt compiler, both the programming interface and the implementation. It will handle the cases of dynamic compiling (when you directly load a source file into the running Jolt), and static compilation (when you load some portions, such as syntax, but compile the rest into a binary file) including cross-compilation. Ian also redesigned the Id object model to make it simpler and more flexible, which drastically reduced the size of libid. All this means it will be feasible to implement libid in Jolt and port idc to use Jolt as its backend. There have been some questions about nomenclature. One thing I learned is that the IS system referred to in the yearly report that was published is the same COLA/Jolt/idst that Ian has committed to Subversion. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] incorrect string literal quasiquotation in jolt2
Hi, The following crashes Jolt2: (syntax test-quasiquote (lambda (node compiler) (let ((expr `(printf hello world\n))) [StdOut print: expr] [StdOut cr] expr))) (test-quasiquote) The output is: (#printf (104 101 108 108 111 32 119 111 114 108 100 10)) I can see from function/jolt2/boot.k that quasiquote doesn't handle constant strings correctly, so they get treated as if they are a list of integers (because they are vectors too). I don't know how to fix this right now given the tools in the current Jolt2 parser. Are there any suggestions? -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] working on a C grammar
Hi, Ian Piumarta [EMAIL PROTECTED] writes: In my experience, parsing C is fairly easy but pre-processing real- world .c and .h files into something you can then parse is a nightmare. I guess I'll start with CPP then. I found a BSD-licensed preprocessor that looks really good: mcpp.sourceforge.net Thanks for the other pointers (and also to Robert and Aaron), -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Jolt2 grammar questions
Hi Ian (since I think you're the only person who can answer), I'm trying to parameterize a Jolt2 grammar so that it can vary based on runtime function calls. What I would like is similar functionality to OMeta's semantic predicates. Here's a snippet from the grammar to illustrate the situation: // Not necessarily the best syntax, but is chosen to mean that // doTrigraphs matches iff [self trigraphsEnabled] evaluates // to nonzero. doTrigraphs =? [self trigraphsEnabled] // This is a backslash trigraph. trigraphBs = '??/' - '$\\ // This matches either a regular backslash, or a trigraph version // if [self trigraphsEnabled] evaluates to nonzero. backslash= '\\' | doTrigraphs trigraphBs BTW, a somewhat related question: what are the '=' and '=' grammar operators? I tried understanding them, but there are no examples, and the code was not obvious. Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] working on a C grammar
Hi all, I was wondering if any of you out there have a freely licensed PEG for C? I'm interested in combining it with a C preprocessor grammar to start interpreting (or compiling via Slink) some C code. With a little work, this would be extensible to handle Id code, and then we'd be one step closer to bootstrap. If not, I have at least a decent BNF reference at http://ivs.cs.uni-magdeburg.de/~puma/UsersManual/HTML/node12.html though I would rather start from something that has all the operator precedences completed in PEG format. Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial update
Hi, Michael Haupt [EMAIL PROTECTED] writes: just a brief notice that my COLA tutorial (Implementing Brainfuck in COLA) is available in an updated version. The update does not bring anything fundamentally new, just enhancements, mostly in terms of accuracy. Would you be able to share something like a diff or wdiff of the paper so that we could see what has changed? Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] idc for windows platform
Hi, Aaron Gray [EMAIL PROTECTED] writes: va_start( ap, rcv); _c = (struct __closure *) _libid-bind( msg, _r); ret = (_c-method)( (oop) _c, _r, _r, ap); va_end( ap); This changes the calling convention... the ap argument does not pass the remaining arguments on the stack, it passes a pointer to them, so they wouldn't be usable as named parameters. I think using the __VA_ARGS__ macro is best for MSVC, as per the reference Krzysztof posted. Too bad it was introduced in Visual C++ 2005... I only have access to 2003. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Jolt, statics?
Hi, Alessandro Warth [EMAIL PROTECTED] writes: (define f (let ((x 0)) (lambda () (... (set x (+ x 1)) ... which I think is pretty nice - i.e., easy for the programmer to write, and confines x in f, just as you'd expect. I wonder if this already works with Michael FIG's patch... No, my dynamic-closure.patch is only for creating BlockClosure objects, and they become invalid once the closed-over variables go out of scope (since the variables live on the stack). I do have an idea for implementing proper closures, though. I'd introduce two new syntax elements: stack-lambda would be like lambda except it can capture lexical variables even if they aren't GlobalVariables. The name is to remind you that once any of the captured variables are popped off the stack, all hell will break loose if you try to use the closure again. It would be really nice to have an alloca (hint, hint) to implement this feature without any memory leaks or dependence on a garbage collector. heap-lambda would be more clever (bletcherous?). When it is used, it would discover which lexically captured variables are not allocated on the heap, then the enclosing lambdas and lets would detect these variables and recompile themselves by moving those variables to the heap (whether as an anonymous global, as x in Alessandro's example above, or an indirection to a GC_alloc'ed storage location). I'm not sure whether to just fail compilation if the second pass results in different captured variables, or to keep iterating until the compilation succeeds. This is clever because it would give a way for the user to specify closures with no garbage collection overhead (stack-lambda or heap-lambda with only anonymous globals). It's a bletcherous hack because it uses multiple compiler passes. I'll work on trying these out over the next few days, as time permits. I surely don't know if this idea qualifies as a cool closure implementation that Ian was hoping for. The idea of multiple compiler passes makes me somewhat nauseous, but I don't see any other way to implement heap-lambda short of abandoning stack frames entirely and allocating everything on the garbage-collected heap (a la Scheme). Michael (Haupt): would Alessandro's construct satisfy your needs? If so, then under my proposal it would look like: (define f (let ((x 0)) ;; first stack-allocated, then forced into heap storage (heap-lambda () (... (set x (+ x 1)) ... Let me know if this would work for you, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: build error - missing -lpthread
K. K. Subramaniam [EMAIL PROTECTED] writes: AFAIK, the -pthread is equivalent to -D_REENTRANT=1 -lpthread. But it has spotty support across different systems, so an explicit definition is recommended for portable code. Try, Okay, thanks. I'll update my patch accordingly (and add support for gc7.0, now that it's in Subversion). -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: build error - missing -lpthread
Hi,
Also FWIW, I have a few more obvious nits that are needed to get SVN
-r397 to build. I think the object/boot/configure patch in this one
is a better approach, as -pthread needs to be added to the GCC flags
for compiling as well as linking to do the right thing.
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
Build environment enhancements.
diff -r 796e7ba8aa58 function/examples/cairo/Makefile
--- a/function/examples/cairo/Makefile Mon Mar 03 20:16:46 2008 -0600
+++ b/function/examples/cairo/Makefile Tue Mar 11 02:30:35 2008 -0600
@@ -1,10 +1,11 @@ JOLT = ../../jolt-burg/main
JOLT = ../../jolt-burg/main
+CAIROINC = $(patsubst %,-J%,$(wildcard /usr/include/cairo) $(wildcard /usr/local/include/cairo))
test : cairolib.so .FORCE
$(JOLT) boot.k main.k
cairolib.so : cairolib.st
- idc -J/usr/local/include/cairo -I../../objects -s $
+ idc $(CAIROINC) -I../../objects -s $
clean : .FORCE
rm -f *~ *.so *.o
diff -r 796e7ba8aa58 function/examples/jcanvas/Makefile
--- a/function/examples/jcanvas/Makefile Mon Mar 03 20:16:46 2008 -0600
+++ b/function/examples/jcanvas/Makefile Tue Mar 11 02:30:35 2008 -0600
@@ -1,10 +1,11 @@ JOLT = ../../jolt-burg/main
JOLT = ../../jolt-burg/main
+CAIROINC = $(patsubst %,-J%,$(wildcard /usr/include/cairo) $(wildcard /usr/local/include/cairo))
test : _cairo.so cairo.so .FORCE
$(JOLT) boot.k main.k
IDC = ../idc -O
-IDFLAGS = -g -k -I../../objects -J/usr/local/include/cairo
+IDFLAGS = -g -k -I../../objects $(CAIROINC)
%.so : %.st
$(IDC) $(IDFLAGS) -s $ -o $@
diff -r 796e7ba8aa58 function/jolt-burg/Makefile
--- a/function/jolt-burg/Makefile Mon Mar 03 20:16:46 2008 -0600
+++ b/function/jolt-burg/Makefile Tue Mar 11 02:30:35 2008 -0600
@@ -58,7 +58,7 @@ tidy : .FORCE
-rm -f *.o *.d *~ .gdb* *.stackdump *.o.c main.c
clean : tidy
- -rm -f $(FILES) jolt.a main$(OBJEXT) CodeGenerator-local.st
+ -rm -f $(FILES) jolt.a main$(OBJEXT) main.sysgc$(OBJEXT) CodeGenerator-local.st
-rm -f bench-id bench-c
distclean spotless : clean
diff -r 796e7ba8aa58 function/objects/ProfiledMethod.st
--- a/function/objects/ProfiledMethod.st Mon Mar 03 20:16:46 2008 -0600
+++ b/function/objects/ProfiledMethod.st Tue Mar 11 02:30:35 2008 -0600
@@ -7,14 +7,16 @@ ProfiledMethod : Object ( _method count
ProfiledMethod new
{
-oop clone= (oop)malloc(sizeof(oop) + sizeof(*self)) + 1;
+void *mem= malloc(sizeof(oop) + sizeof(*self));
+oop clone= ((oop *)memory)[1];
clone-_vtable[-1]= self-_vtable[-1];
_return(clone);
}
ProfiledMethod delete
{
-free(v_self - 1);
+void *mem= ((oop *)v_self)[-1];
+free(mem);
}
ProfiledMethod release
@@ -118,7 +120,7 @@ StaticBlockClosure statisticalProfile
StaticBlockClosure statisticalProfile
[
| methods |
-self perform: #profilerTick every: 0.01.
+self perform: #profilerTick every: 0.01 0.5.
self value.
self perform: nil every: 0.
methods := ProfiledMethods.
@@ -129,7 +131,7 @@ Object profilerTick
Object profilerTick
[
| _mi mi |
-{ if (!(v__mi= _libid-methodAt(1))) { _return(0); } }.
+{ printf(tick!\n); if (!(v__mi= _libid-methodAt(1))) { _return(0); } }.
mi := ProfiledMethod withMethod_: _mi.
mi increment.
]
diff -r 796e7ba8aa58 object/boot/configure
--- a/object/boot/configure Mon Mar 03 20:16:46 2008 -0600
+++ b/object/boot/configure Tue Mar 11 02:30:35 2008 -0600
@@ -80,7 +80,7 @@ done
TARGET=${TARGET:-`sh ./boot/config.guess`}
-GCDIR=${GCDIR:-gc-7.0}
+GCDIR=${GCDIR:-gc6.7}
ppc () {
OFLAGS=${OFLAGS:--O}
@@ -174,7 +174,7 @@ linux () {
linux () {
CC=${CC:-cc}
PREFIX=${PREFIX:-/usr/local/lib/idc/$TARGET/}
-CFLAGS=${CFLAGS:--g -Wall -Wreturn-type -Werror -D_GNU_SOURCE=1 -Wno-unused-value}
+CFLAGS=${CFLAGS:--g -Wall -Wreturn-type -Werror -D_GNU_SOURCE=1 -Wno-unused-value -pthread}
LDFLAGS=${LDFLAGS:--export-dynamic}
LDLIBS=${LDLIBS:--ldl -lm}
CCFLAGS_O=${CCFLAGS_O:--c}
diff -r 796e7ba8aa58 object/examples/Makefile
--- a/object/examples/Makefile Mon Mar 03 20:16:46 2008 -0600
+++ b/object/examples/Makefile Tue Mar 11 02:30:35 2008 -0600
@@ -14,7 +14,7 @@ clean : .FORCE
rm -f *~
-$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) clean ); done'
-spotless : .FORCE
+distclean spotless : .FORCE
rm -f *~
-$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) spotless ); done'
diff -r 796e7ba8aa58 object/examples/ignore/Makefile
--- a/object/examples/ignore/Makefile Mon Mar 03 20:16:46 2008 -0600
+++ b/object/examples/ignore/Makefile Tue Mar 11 02:30:35 2008 -0600
@@ -5,7 +5,7 @@ all : $(PROGRAM)
all : $(PROGRAM)
run : all
- ./$(PROGRAM)
+ -./$(PROGRAM)
% : %.st
$(IDC) $
diff -r 796e7ba8aa58 object/examples/x11/Makefile
--- a/object/examples/x11/Makefile Mon Mar 03 20:16:46 2008 -0600
+++ b/object/examples/x11/Makefile Tue Mar 11 02:30:35 2008 -0600
@@ -23,6 +23,6 @@ clean : tidy .FORCE
clean : tidy .FORCE
rm -f $(PROGRAM) $(LIBS) *.exe
[fonc] [PATCH 02 of 10] Add Mercurial infrastructure
# HG changeset patch # User Michael FIG [EMAIL PROTECTED] # Date 1205294755 21600 # Node ID ca2035cc829b7713e7ab21aa5c58ca68ea0ffd33 # Parent be2e135a45e9246acd6f80c176722cc953c5296c Add Mercurial infrastructure. diff -r be2e135a45e9 -r ca2035cc829b push-ocean --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/push-oceanTue Mar 11 22:05:55 2008 -0600 @@ -0,0 +1,17 @@ +#! /bin/bash +# qpush - Put the current repository up for the public +# Michael FIG [EMAIL PROTECTED], 2007-10-29 +webroot=/var/www/root/ocean +set -e +if test -d $webroot; then + current=`hg qtop` + hg qpop -a + hg push $webroot + (cd .hg/patches hg push $webroot/.hg/patches) + hg qgoto $current +else + hg qclone . $webroot +fi +cd $webroot hg update +(cd .hg/patches hg update) +(cd doc make || :) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] [PATCH 04 of 10] Documentation fixes
# HG changeset patch
# User Michael FIG [EMAIL PROTECTED]
# Date 1205294755 21600
# Node ID 7c2c8bd7432dfea8252251565251fc0d200a4f28
# Parent 1434c5b13b91fdd9c6326e578f3722ea966e6c09
Documentation fixes.
diff -r 1434c5b13b91 -r 7c2c8bd7432d function/jolt-burg/Compiler.st
--- a/function/jolt-burg/Compiler.stTue Mar 11 22:05:55 2008 -0600
+++ b/function/jolt-burg/Compiler.stTue Mar 11 22:05:55 2008 -0600
@@ -628,7 +628,7 @@ Compiler xQuote: expr
Compiler xQuote: expr
[
| literal |
-expr size == 2 ifFalse: [self errorAgumentCount: expr].
+expr size == 2 ifFalse: [self errorArgumentCount: expr].
literal := expr second.
(literal isSmallInteger or: [literal isNil]) ifFalse: [CompilerLiterals
addLast: literal].
^CNSTP4 new arg: literal
@@ -919,7 +919,7 @@ Compiler xEvaluate: form
Compiler errorUndefined: aSymbol [ self error: 'undefined: ', aSymbol ]
Compiler errorSyntax: form [ self error: 'syntax error: ', form
printString ]
-Compiler errorArgumentCount: form [ self error: 'wrong number of
aguments: ', form printString ]
+Compiler errorArgumentCount: form [ self error: 'wrong number of
arguments: ', form printString ]
Compiler errorLoop: form [ self error: 'no loop: ', form
printString ]
diff -r 1434c5b13b91 -r 7c2c8bd7432d function/objects/BlockClosure.st
--- a/function/objects/BlockClosure.st Tue Mar 11 22:05:55 2008 -0600
+++ b/function/objects/BlockClosure.st Tue Mar 11 22:05:55 2008 -0600
@@ -1,4 +1,4 @@
- BlockClosure.st -- defferred execution of code
+ BlockClosure.st -- deferred execution of code
Copyright (c) 2006, 2007 Ian Piumarta
All rights reserved.
diff -r 1434c5b13b91 -r 7c2c8bd7432d object/id/libid.c
--- a/object/id/libid.c Tue Mar 11 22:05:55 2008 -0600
+++ b/object/id/libid.c Tue Mar 11 22:05:55 2008 -0600
@@ -568,7 +568,7 @@ __libid_bind: \n
jne __t1\n // tagged
testl %eax, %eax \n
je __t0\n // nil
- movl-4(%eax), %edx \n // edx = recevier.vtable
+ movl-4(%eax), %edx \n // edx = receiver.vtable
__tok:movl4(%esp), %ecx \n // ecx =
selector
movl%edx, %eax \n // eax = vtable
shll$2, %eax\n // eax = vtable 2
@@ -604,7 +604,7 @@ __libid_bind:
\n // r3= selector,
bne __t1\n // tagged
cmpwi r4, 0 \n
beq __t0\n // nil
- lwz r5, -4(r4) \n // r5 =
recevier.vtable
+ lwz r5, -4(r4) \n // r5 =
receiver.vtable
__tok:slwir6, r5, 4 \n // r6 =
vtable 4 (2+2)
srawi r7, r3, 1 \n // r7 =
selector 1 (3-2)
xor r6, r6, r7 \n // r6 = (vtable
2) ^ (selector 3)
diff -r 1434c5b13b91 -r 7c2c8bd7432d object/st80/BlockClosure.st
--- a/object/st80/BlockClosure.st Tue Mar 11 22:05:55 2008 -0600
+++ b/object/st80/BlockClosure.st Tue Mar 11 22:05:55 2008 -0600
@@ -23,7 +23,7 @@ StaticBlockClosure : Object ( _function
StaticBlockClosure : Object ( _function _arity ) { pragma: type
staticClosure StaticBlockClosure }
I represent an optimised closure that has no free references or
- nonlocal returns. I am idenpotent, and therefore allocated once by
+ nonlocal returns. I am idempotent, and therefore allocated once by
the compiler during initialisation and thereafter treated as a
literal.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] [PATCH 06 of 10] Update Makefiles to be more friendly
# HG changeset patch # User Michael FIG [EMAIL PROTECTED] # Date 1205294804 21600 # Node ID b7517504cb7a4214bae5023bdbed29de9b5c9aff # Parent 8a3813f99822fcde13411357637dda3d9dc8ff01 Update Makefiles to be more friendly. diff -r 8a3813f99822 -r b7517504cb7a Makefile --- a/Makefile Tue Mar 11 22:05:55 2008 -0600 +++ b/Makefile Tue Mar 11 22:06:44 2008 -0600 @@ -1,33 +1,36 @@ SUBDIRS = object function SUBDIRS = object function all : .FORCE - $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) ); done' + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) ); done' + +run : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) run ); done' dist : .FORCE - $(SHELL) -ec '( cd dist; $(MAKE) dist )' + $(SHELL) -ec '( cd dist $(MAKE) dist )' install : .FORCE - $(SHELL) -ec '( cd object; $(MAKE) install )' + $(SHELL) -ec '( cd object $(MAKE) install )' dist-src : .FORCE - $(SHELL) -ec '( cd dist; $(MAKE) dist-src )' + $(SHELL) -ec '( cd dist $(MAKE) dist-src )' config : .FORCE - $(SHELL) -ec '( cd object; $(MAKE) config )' + $(SHELL) -ec '( cd object $(MAKE) config )' win32 : .FORCE $(MAKE) TARGET=i686-pc-mingw32 tidy : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) tidy ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) tidy ); done' clean : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) clean ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) clean ); done' distclean spotless : .FORCE -rm -f *~ - -$(SHELL) -c 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) distclean ); done' + -$(SHELL) -c 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) distclean ); done' .FORCE : diff -r 8a3813f99822 -r b7517504cb7a function/Makefile --- a/function/Makefile Tue Mar 11 22:05:55 2008 -0600 +++ b/function/Makefile Tue Mar 11 22:06:44 2008 -0600 @@ -1,18 +1,21 @@ SUBDIRS = objects jolt-burg SUBDIRS = objects jolt-burg all : .FORCE - $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) ); done' + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) ); done' tidy : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) tidy ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) tidy ); done' clean : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) clean ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) clean ); done' + +run test : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) run ); done' distclean spotless : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) spotless ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) spotless ); done' .FORCE : diff -r 8a3813f99822 -r b7517504cb7a function/examples/Makefile --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/function/examples/MakefileTue Mar 11 22:06:44 2008 -0600 @@ -0,0 +1,21 @@ +SUBDIRS = cairo jcanvas libjolt peg prag-parse profile regexp select slotnames struct tcp x-drawing x-event + +all : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) ); done' + +tidy : .FORCE + rm -f *~ + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) tidy ); done' + +clean : .FORCE + rm -f *~ + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) clean ); done' + +run test : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) run ); done' + +distclean spotless : .FORCE + rm -f *~ + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) spotless ); done' + +.FORCE : diff -r 8a3813f99822 -r b7517504cb7a function/examples/cairo/Makefile --- a/function/examples/cairo/Makefile Tue Mar 11 22:05:55 2008 -0600 +++ b/function/examples/cairo/Makefile Tue Mar 11 22:06:44 2008 -0600 @@ -1,11 +1,12 @@ JOLT = ../../jolt-burg/main JOLT = ../../jolt-burg/main +IDC = ../idc CAIROINC = $(patsubst %,-J%,$(wildcard /usr/include/cairo) $(wildcard /usr/local/include/cairo)) -test : cairolib.so .FORCE +run test : cairolib.so .FORCE $(JOLT) boot.k main.k cairolib.so : cairolib.st - idc $(CAIROINC) -I../../objects -s $ + $(IDC) $(CAIROINC) -I../../objects -s $ clean : .FORCE rm -f *~ *.so *.o diff -r 8a3813f99822 -r b7517504cb7a function/examples/jcanvas/Makefile --- a/function/examples/jcanvas/MakefileTue Mar 11 22:05:55 2008 -0600 +++ b/function/examples/jcanvas/MakefileTue Mar 11 22:06:44 2008 -0600 @@ -1,7 +1,7 @@ JOLT = ../../jolt-burg/main JOLT = ../../jolt-burg/main CAIROINC = $(patsubst %,-J%,$(wildcard /usr/include/cairo
[fonc] [PATCH 00 of 10] From svn.397 to Ocean
Hi all, I've updated the following experimental patches for COLA svn -r397 (the patch set is codenamed Ocean). As always, the order of the patches matters (the later ones depend on earlier). The most important patch is struct-send-fixes.patch, which completely eliminates bind and bind2, and gets all the examples working again. You can also see the embryonic wiki page http://vpri.org/fonc_wiki/Sources for instructions on how to use Mercurial if you want to help develop these or other patches more conveniently than with Subversion. Have fun, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] [PATCH 07 of 10] Enforce explicit operator precedence around math-like selectors
# HG changeset patch
# User Michael FIG [EMAIL PROTECTED]
# Date 1205294807 21600
# Node ID 95b3d71eb60519b5293bbef50b17f12aab6bdca0
# Parent b7517504cb7a4214bae5023bdbed29de9b5c9aff
Enforce explicit operator precedence around math-like selectors.
diff -r b7517504cb7a -r 95b3d71eb605 function/objects/IdentitySet.st
--- a/function/objects/IdentitySet.st Tue Mar 11 22:06:44 2008 -0600
+++ b/function/objects/IdentitySet.st Tue Mar 11 22:06:47 2008 -0600
@@ -125,7 +125,7 @@ IdentitySet widen
IdentitySet widen
[
StdOut nextPutAll: 'WIDEN '; print: self size; space; print: lists size +
1 * 2 - 1; cr.
-lists := (self new: lists size + 1 * 2 - 1) addAll: self; lists.
+lists := (self new: (lists size + 1) * 2 - 1) addAll: self; lists.
]
IdentitySet deepen: list at: listOffset
diff -r b7517504cb7a -r 95b3d71eb605 object/examples/Makefile
--- a/object/examples/Makefile Tue Mar 11 22:06:44 2008 -0600
+++ b/object/examples/Makefile Tue Mar 11 22:06:47 2008 -0600
@@ -1,5 +1,5 @@ SUBDIRS = avl dispatch echo forward hw i
SUBDIRS= avl dispatch echo forward hw ignore interp libs1 libs2 libs3
parse \
- prototype reflect serialise slots sqvm system this traits typename weak
x11
+ precedence prototype reflect serialise slots sqvm system this traits
typename weak x11
all : .FORCE
test ! -f ../stage2/clean-examples || $(MAKE) clean
diff -r b7517504cb7a -r 95b3d71eb605 object/examples/ignore/Makefile
--- a/object/examples/ignore/Makefile Tue Mar 11 22:06:44 2008 -0600
+++ b/object/examples/ignore/Makefile Tue Mar 11 22:06:47 2008 -0600
@@ -5,6 +5,7 @@ all : $(PROGRAM)
all : $(PROGRAM)
run : all
+ @echo Expect failure:
$(IDC) -exec ./$(PROGRAM) || :
% : %.st
diff -r b7517504cb7a -r 95b3d71eb605 object/examples/precedence/Makefile
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/object/examples/precedence/Makefile Tue Mar 11 22:06:47 2008 -0600
@@ -0,0 +1,23 @@
+IDC = ../idc
+
+all : good bad
+
+run : all
+ $(IDC) -exec ./good
+
+bad : bad.st
+ @echo Expect failure:
+ if $(IDC) bad.st; then exit 1; else exit 0; fi
+
+% : %.st
+ $(IDC) $
+
+tidy: .FORCE
+ rm -f *~
+
+clean : tidy .FORCE
+ rm -f good bad *.exe
+
+spotless : clean .FORCE
+
+.FORCE :
diff -r b7517504cb7a -r 95b3d71eb605 object/examples/precedence/bad.st
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/object/examples/precedence/bad.st Tue Mar 11 22:06:47 2008 -0600
@@ -0,0 +1,5 @@
+{ import: st80 }
+
+[
+(2 + 3 * 8) print. '\n' put.
+]
diff -r b7517504cb7a -r 95b3d71eb605 object/examples/precedence/good.st
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/object/examples/precedence/good.stTue Mar 11 22:06:47 2008 -0600
@@ -0,0 +1,7 @@
+{ import: st80 }
+
+[
+(2 + (3 * 8)) print. '\n' put.
+(3 * 8 + 2) print. '\n' put.
+((2 + 3) * 8) print. '\n' put.
+]
diff -r b7517504cb7a -r 95b3d71eb605 object/examples/sqvm/File.st
--- a/object/examples/sqvm/File.st Tue Mar 11 22:06:44 2008 -0600
+++ b/object/examples/sqvm/File.st Tue Mar 11 22:06:47 2008 -0600
@@ -63,7 +63,7 @@ File read: array startingAt: index size:
[
^(0 index and: [index + size - 1 = array size])
ifTrue: [(SmallInteger value_: (self _read_: array _elements
-at_: (index - 1 * array
elementSize) _integerValue
+at_: ((index - 1) * array
elementSize) _integerValue
size_: (size * array
elementSize) _integerValue))
// array elementSize]
ifFalse: [self errorNoSuchElement]
@@ -79,7 +79,7 @@ File write: array startingAt: index size
[
^(0 index and: [index + size - 1 = array size])
ifTrue: [(SmallInteger value_: (self _write_: array _elements
- at_: (index - 1 * array
elementSize) _integerValue
+ at_: ((index - 1) * array
elementSize) _integerValue
size_: (size * array
elementSize) _integerValue))
// array elementSize]
ifFalse: [self errorNoSuchElement]
diff -r b7517504cb7a -r 95b3d71eb605 object/idc/CCodeGenerator.st
--- a/object/idc/CCodeGenerator.st Tue Mar 11 22:06:44 2008 -0600
+++ b/object/idc/CCodeGenerator.st Tue Mar 11 22:06:47 2008 -0600
@@ -639,7 +639,7 @@ CCodeGenerator implementType: typeNode
gen: ' return '; gen: name; genl: '; }';
gen: 'static struct __slotinfo *'; genType: name method: '_slots'; gen:
'(oop _closure, oop '; genVariable: 'self'; gen: ') {';
gen: ' static struct __slotinfo info[]= {'.
-typeNode slots doWithIndex: [:slot :index | self gen: ' { ', slot, ', ';
gen: (index - 1 * 4) printString; gen: ', 4 },'].
+typeNode slots doWithIndex: [:slot :index | self gen: ' { ', slot, ', ';
gen: ((index - 1
[fonc] alloca
Hi Ian, Could you please point me in the right direction to go about getting alloca into jolt-burg? I've gotten the Pepsi side of things to work with only bindv (excising bind and bind2), but I don't have a nice way to make the Jolt side work unless I can allocate struct __sends on the stack. I will gladly post the Pepsi patch (if anybody is interested), but be forwarned that it breaks Jolt completely. Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] New Tech Report from VPRI
Hi all, Joshua Gargus [EMAIL PROTECTED] writes: VPRI has published Steps Toward the Reinvention of Programming on their website (http://vpri.org/html/writings.htm). It's a synopsis of the work that they've done over the last year; as you might expect, a lot of it involves COLA. It's well worth the read! Agreed... it's a very interesting state-of-the-project report. A few questions that arose in my mind as I was reading: 1) Is the current state of IS what we see in function/jolt-burg, or is there some other more developed system? 2) There seems to be some hints that there is a particular concurrency model that is being considered. Would somebody care to elaborate on this? 3) How can I, as a member of the general public who likes hacking on things, best help further the goals of the project? Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] trunk broken
Hi, I think you forgot to check in function/doc/parser.html.in Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error compiling Pepsi on Leopard with Xcode 3 GCC
Hi, Watt Poosanguansit [EMAIL PROTECTED] writes: I am just too new to this to really get around the error of idc1 not found. I would appreciate any help. Your problem actually occurs above that point, around here: ./if_mach POWERPC DARWIN as -arch ppc -DLARGE_CONFIG -o mach_dep.o ./powerpc_darwin_mach_dep.s Starting command FATAL:/usr/bin/../libexec/gcc/darwin/ppc/as: I don't understand 'D' flag! make[2]: *** [mach_dep.o] Error 1 make[1]: [../gc6.7/gc.a] Error 2 (ignored) Looking into object/gc6.7/powerpc_darwin_mach_dep.s, there are no references to LARGE_CONFIG, so I would assume that it's just an error for the gc6.7 Makefiles to pass -DLARGE_CONFIG (indeed, the lowercase .s files are not supposed to be preprocessed; by convention only .S files are). You could hack around it by doing something like this: $ cd object/gc6.7 $ ./if_mach POWERPC DARWIN as -arch ppc -o mach_dep.o ./powerpc_darwin_mach_dep.s then, rerun the `make' and see if that helps. I don't have access to that platform though, so somebody else might offer better advice. Google turned up nothing for me. Good luck, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Trying the brainfuck tutorial
Hi, Mathieu,
Mathieu Suen [EMAIL PROTECTED] writes:
Svn version is 376.
I did not use the tutorial for the time being. I am just trying out
some script
Here the script:
%{
(define putchar (dlsym 'putchar'))
%}
(putchar 65)
I'm not sure exactly what you're wanting to do. You are aware that
PEG is only needed to create parsers, and that the script you have
above doesn't contain any PEG rules (which is why, I suspect, the PEG
compiler crashes)?
Also, your (dlsym 'putchar') uses the wrong quotes for Jolt: you need
(dlsym putchar). The Jolt and Pepsi syntaxes are only slightly
related (you can quote Jolt integers, strings, and lists to get Pepsi
constructs, as described in the Coke manual, below).
If you are just testing out Jolt, you could try something like this,
in a file called t.k, for example:
(define putchar (dlsym putchar))
(putchar 65)
which on my system does the following:
[EMAIL PROTECTED]:~/ocean/function/jolt-burg$ ./main boot.k t.k
; loading: boot.k
; loading: quasiquote.k
; loading: syntax.k
; loading: number.k
; loading: debug.k
; loading: object.k
[EMAIL PROTECTED]:~/ocean/function/jolt-burg$
^-- here is your output character.
Have a look at the Jolt documentation, featured at
http://piumarta.com/software/cola/coke.html
Other than that, feel free to ask more questions on this list.
Good luck,
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Available patches for COLA svn-376
Hi Hans, SainTiss [EMAIL PROTECTED] writes: Okay... if you download the patches, have a look in function/examples/threading. Ok, I will have a look, and let you know if I get it running. That'd be great! I still have to implement the code that actually allocates and uses the locks, which is a fairly major showstopper, but you can at least see a stupid test in which I add a method to a vtable while another thread is using it. If you come up with any test cases, that would be great. I need ways of stressing the system to help give confidence to the lock-free vtables and the metaobject locking mechanism as well. BTW, are you a Windows or a Pthreads user? I'm a pthreads user; does that make a difference in usage? It does't have any Windows support yet (still haven't bothered to get COLA working on my Windows XP box), so you're in luck. After I implemented the (beginnings of the) object tracing facility used to allocate the locks, I read that that's the way that some Smalltalks (but not Squeak) do #become:. I was wrong. It turns out Squeak *does* use their object-trace facility, but they changed the interface to #become: to improve performance so that all the objects of a class could be replaced with a single method call. I chose read-write locks because they can give better performance at the cost of 25% more memory per lock (8 words as opposed to 6 for mutexes on i386/Linux Pthreads). My eventual goal is a drop-in, pay-as-you-go software transactional memory, but locking is easier initially. Ok, sounds cool. was there an intuitivity argument involved as well? Well, kinda, if you consider my own intuition to be an intuitivity argument. ;) Seriously, though... I expect that COLA will have to support many different threading models, and probably simultaneously too. So, I'm just trying to guess what fundamental features applications are going to need. After that, I hope that peer review and real applications will determine the direction of growth. Thanks, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Available patches for COLA svn-376
SainTiss [EMAIL PROTECTED] writes: Just a quick note to indicate that, personally, I'd be most interested in the multithreading part. Okay... if you download the patches, have a look in function/examples/threading. BTW, are you a Windows or a Pthreads user? Actually, is the strategy you're pursueing atm a well-known one? Or did you come up with it yourself for the particular COLA object model? For now, I'm using much the same strategy that .NET uses: one lock installed in each object for applications to use. However, COLA allows me to pay for this overhead only if the application explicitly asks for threading. After I implemented the (beginnings of the) object tracing facility used to allocate the locks, I read that that's the way that some Smalltalks (but not Squeak) do #become:. I chose read-write locks because they can give better performance at the cost of 25% more memory per lock (8 words as opposed to 6 for mutexes on i386/Linux Pthreads). My eventual goal is a drop-in, pay-as-you-go software transactional memory, but locking is easier initially. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Available patches for COLA svn-376
Hi, all... I've been testing the following COLA patches for the past few weeks, and want to know if anybody's interested in development along these lines. Feedback would be good, because that will help determine where I put my energy. You can find instructions on how to download and install these unofficial patches from: http://vpri.org/fonc_wiki/index.php/Sources Here are the patch names (in dependency order), and their descriptions: libjolt-fixups.patch: Get libjolt working again. mercurize.patch: Add Mercurial infrastructure. makefile.patch: Build environment enhancements. doc-fixes.patch: Documentation fixes. gcc-is-picky.patch: Fix errors caused by picky compilers (notably late 3.x GCC). friendly-make.patch: Update Makefiles to be more friendly. explicit-precedence.patch: Enforce explicit operator precedence around math-like selectors. jolt-libid-primitive.patch: Export only _libid as a Jolt primitive. message-send-descriptors.patch: Change ABI to use __send structures. send-argument_count.patch: Add #argument_count to the idc-generated send structure. thread-objects.patch: Create per-thread objects that hang off of struct __send to store thread-specific data. dynamic-closure.patch: Define (dynamic-closure ...) to allow Jolt to create dynamically-scoped BlockClosures. per-object-metadata.patch: Add a new meta object before the vtable. multithreading-madness.patch (work in progress): Implement threading in a Jolt test program by dynamically installing a read-write lock in each object, and updating the _libid multithreading primitives for pthreads. I'll probably break the multithreading-madness.patch up into smaller pieces: one for the object trace mechanism (which works, but is not yet complete), one for a pthreads-only test, and one for a windows threading test. A nice side-effect of the object trace mechanism is that it may lay the foundation for precise GC in the future. The multithreading patch uses lock-free algorithms for all the libid.c reads (such as _vtable lookups), and per-object write locks for updates. By also putting the method cache in the per-thread object, I'm hoping that the most heavily-used code (namely _libid-bind) won't be a bottleneck. The main reason I'm working on multithreading-madness is that there was a comment on Lambda the Ultimate which suggested that COLA would only be appropriate for single-threaded programming. I'm wanting to add these features sooner rather than later so that they will mature alongside the compiler (since, as we all know, Threads Cannot Be Implemented As A Library(TM)). Have fun! -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] bind and lookup
Eric Normand [EMAIL PROTECTED] writes: Bind and lookup both select the method to use based on the method selector, which is basically the message name. Bind is a fixed point in the language, and lookup is not. However, it is inside of bind that method selection is decided, ie, that a method is selected based on the name of the message. This quote from Ian, written to this list on 2007-11-02, in a thread called Re: [fonc] Comment on LtU may answer your question: Ian Piumarta writes: The object model is the simplest that could be used to bootstrap some of the ideas. Limiting the dispatch to discriminating on the first argument is a severe limitation that has to be dealt with soon (it's already causing problems). Fixing this is part of a larger generalisation and unification of the roles of object, message name, and function that is planned but not yet implemented. In particular, message/function names and selectors should be distinct objects -- with selectors and types(/classes/whatever) having equal influence in determining and encapsulating behaviour. Selectors will be involved in determining the code emitted for their own call sites, subsuming the generic function-like behaviour you mention, bringing message dispatch and function application together as a single operation with no limits to the complexity of binding, dispatch and application mechanisms involved. Hope that helps, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] idc for windows platform
Hi, I'm answering this not because I'm an expert, but because I think a quick pointer in the right direction might be all you need to get going. Alejandro F. Reimondo [EMAIL PROTECTED] writes: now I am trying to build idc compiler under windows platform to make some work on it (the sourcecode I've read looks portable)... I don't think this is documented anywhere except by noticing that some of the files' last modified stamps refer to cygwin.piumarta.com. So, I'd hazard the guess that the way to make Cola compile under Windows is to install Cygwin, and use its unix-like environment to do the building. You can find Cygwin at: http://www.cygwin.com/ Look for the Install Cygwin now icon at the left, which is just a link to: http://www.cygwin.com/setup.exe Good luck, and please do let the list know if you're successful or if you ran into any snags. I'll be following the same road pretty soon once I get the features I want working under Linux. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Extensible object metadata
Hi Ian, In working on a patch to support multithreading throughout libid, Pepsi and Jolt, I had to make a distinction between the vtables (which are shared by all objects in a given clone family) and other metadata that may be per-object (such as locks, STM versioning data, debug information, etc). I took some hints from your plan of adding another word before functions to make them both proper objects and have further attributes. Generalizing that, I've introduced struct __meta, which contains all the metadata that libid needs for basic operation (such as the _vtable pointer). My proposed oop layout looks like: | ...more metadata | +--+ | struct __meta| | | | | +--+ | METAMETA-PTR | an oop describing the metadata +==+ | ...members | --- oop points here Similar to _vtable_vtable, the terminal _metameta oop looks like: | ...more metadata | ++ | struct __meta | || || ++ | METAMETA-PTR |\ ++| Points to self | METADATA-SIZE | --/ ++ | ...more members| Just like the struct __send design, this allows for users to extend an object's metadata with whatever they want. [Now if only that magical ASCII-art parser could convert that diagram into a fully-working implementation! ;)] METADATA-SIZE is the first member of every derivative of _metameta in order to compute the beginning of objects allocated using that metameta object without invoking the message send runtime. I had a good reason for that before, but I can't remember what it was. :P I'm going ahead and experimenting with this design; it will merge with my struct __send patch, since it touches many of the same pieces. Unless there are changes to the design, I hope that we can finally land these on the mainline. My multithreading changes are somewhat mixed in with all this. The architecture I have is independent of threading model: the user configures _libid with the model of their choice. However, in doing the changes, I greatly cleaned up my former struct __send patch, and stuffed a lot of libid's state into a per-thread data structure that hangs off of struct __send (as you and I were alluding to earlier). Again, the _thread object is user-extensible, if people want their own fast-access thread-specific data. After all of this (which should also implement sendargument_count outside of libid, as an addition made by Pepsi and Jolt), I still want to make the changes to function/ so that redundant methods that have noisy keywords with arbitrary limits (such as value, value:, value:value:, value:value:value:, etc) are replaced by a single method with anonymous variadic arguments (value ...). Anyway, please let me know what you think, and happy holidays to everybody out there (best regards also to those of you who don't celebrate)! -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Avoiding math precedence ambiguities
Hi, all...
In light of the recent discussions about math precedence, I've created
a patch to implement my suggestion. Confronted with the following
code:
2 + 3 * 8.
my modified idc aborts with:
bad.st:4: ambiguous arithmetic expression; use explicit parentheses near '*'
However, it compiles without warning for the following:
2 + (3 * 8).
3 * 8 + 2.
(2 + 3) * 8.
There were a handful of .st files that relied on the st80-style
non-precedence, which I added explicit parentheses to.
If this patch (or something morally equivalent) is accepted to the
mainline, I believe we can finally close the precedence discussion. I
hope. ;P
Have fun,
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
Enforce explicit operator precedence around math-like selectors.
diff -r f4fccae99d24 function/objects/IdentitySet.st
--- a/function/objects/IdentitySet.st Tue Dec 11 23:40:12 2007 -0600
+++ b/function/objects/IdentitySet.st Tue Dec 11 23:51:23 2007 -0600
@@ -125,7 +125,7 @@ IdentitySet widen
IdentitySet widen
[
StdOut nextPutAll: 'WIDEN '; print: self size; space; print: lists size + 1 * 2 - 1; cr.
-lists := (self new: lists size + 1 * 2 - 1) addAll: self; lists.
+lists := (self new: (lists size + 1) * 2 - 1) addAll: self; lists.
]
IdentitySet deepen: list at: listOffset
diff -r f4fccae99d24 object/examples/Makefile
--- a/object/examples/Makefile Tue Dec 11 23:40:12 2007 -0600
+++ b/object/examples/Makefile Tue Dec 11 23:51:23 2007 -0600
@@ -1,5 +1,5 @@ SUBDIRS = avl dispatch echo forward hw i
SUBDIRS = avl dispatch echo forward hw ignore interp libs1 libs2 libs3 parse \
- prototype reflect serialise slots sqvm system this traits typename weak x11
+ precedence prototype reflect serialise slots sqvm system this traits typename weak x11
all : .FORCE
test ! -f ../stage2/clean-examples || $(MAKE) clean
diff -r f4fccae99d24 object/examples/ignore/Makefile
--- a/object/examples/ignore/Makefile Tue Dec 11 23:40:12 2007 -0600
+++ b/object/examples/ignore/Makefile Tue Dec 11 23:51:23 2007 -0600
@@ -5,6 +5,7 @@ all : $(PROGRAM)
all : $(PROGRAM)
run : all
+ @echo Expect failure:
$(IDC) -exec ./$(PROGRAM) || :
% : %.st
diff -r f4fccae99d24 object/examples/precedence/Makefile
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/object/examples/precedence/Makefile Tue Dec 11 23:51:23 2007 -0600
@@ -0,0 +1,23 @@
+IDC = ../idc
+
+all : good bad
+
+run : all
+ $(IDC) -exec ./good
+
+bad : bad.st
+ @echo Expect failure:
+ if $(IDC) bad.st; then exit 1; else exit 0; fi
+
+% : %.st
+ $(IDC) $
+
+tidy: .FORCE
+ rm -f *~
+
+clean : tidy .FORCE
+ rm -f good bad *.exe
+
+spotless : clean .FORCE
+
+.FORCE :
diff -r f4fccae99d24 object/examples/precedence/bad.st
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/object/examples/precedence/bad.st Tue Dec 11 23:51:23 2007 -0600
@@ -0,0 +1,5 @@
+{ import: st80 }
+
+[
+(2 + 3 * 8) print. '\n' put.
+]
diff -r f4fccae99d24 object/examples/precedence/good.st
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/object/examples/precedence/good.st Tue Dec 11 23:51:23 2007 -0600
@@ -0,0 +1,7 @@
+{ import: st80 }
+
+[
+(2 + (3 * 8)) print. '\n' put.
+(3 * 8 + 2) print. '\n' put.
+((2 + 3) * 8) print. '\n' put.
+]
diff -r f4fccae99d24 object/examples/sqvm/File.st
--- a/object/examples/sqvm/File.st Tue Dec 11 23:40:12 2007 -0600
+++ b/object/examples/sqvm/File.st Tue Dec 11 23:51:23 2007 -0600
@@ -63,7 +63,7 @@ File read: array startingAt: index size:
[
^(0 index and: [index + size - 1 = array size])
ifTrue: [(SmallInteger value_: (self _read_: array _elements
- at_: (index - 1 * array elementSize) _integerValue
+ at_: ((index - 1) * array elementSize) _integerValue
size_: (size * array elementSize) _integerValue))
// array elementSize]
ifFalse: [self errorNoSuchElement]
@@ -79,7 +79,7 @@ File write: array startingAt: index size
[
^(0 index and: [index + size - 1 = array size])
ifTrue: [(SmallInteger value_: (self _write_: array _elements
- at_: (index - 1 * array elementSize) _integerValue
+ at_: ((index - 1) * array elementSize) _integerValue
size_: (size * array elementSize) _integerValue))
// array elementSize]
ifFalse: [self errorNoSuchElement]
diff -r f4fccae99d24 object/idc/CCodeGenerator.st
--- a/object/idc/CCodeGenerator.st Tue Dec 11 23:40:12 2007 -0600
+++ b/object/idc/CCodeGenerator.st Tue Dec 11 23:51:23 2007 -0600
@@ -640,7 +640,7 @@ CCodeGenerator implementType: typeNode
gen: ' return '; gen: name; genl: '; }';
gen: 'static struct __slotinfo *'; genType: name method: '_slots'; gen: '(oop _closure, oop '; genVariable: 'self'; gen: ') {';
gen: ' static struct __slotinfo info[]= {'.
-typeNode slots doWithIndex: [:slot :index | self gen: ' { ', slot, ', '; gen: (index - 1 * 4) printString; gen: ', 4 },'].
+typeNode slots doWithIndex: [:slot :index | self gen: ' { ', slot
[fonc] friendly-make.patch
Hi, all... This patch adds more consistent handling of Makefile targets. First of note, it handles object/ a bit better by forcing a 'make clean' of the examples when necessary, and rebuilding stage2 if stage1 changes (and stage1 if boot changes, and stage3 if stage2 changes). It also introduces an '-exec' flag to idc: -exec - execute a compiled program when idc is not installed This flag is used to set the environment variables needed to run idc-generated programs without installing the runtime to the system directories. The usage is 'idc [-option ...] -exec PROGRAM [ARG]...', and, specifically, it is sensitive to the -B flag. Using -exec liberally in the Makefiles allows you to do 'make run' from the toplevel directory and have the entire project build and all the examples execute for your viewing pleasure without having to install anything. Search for '***' in the output to see if any errors happened. Have fun, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// Update Makefiles to be more friendly. diff -r c25547efbe21 Makefile --- a/Makefile Thu Dec 06 06:22:48 2007 -0600 +++ b/Makefile Thu Dec 06 06:24:58 2007 -0600 @@ -1,33 +1,36 @@ SUBDIRS = object function SUBDIRS = object function all : .FORCE - $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) ); done' + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) ); done' + +run : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) run ); done' dist : .FORCE - $(SHELL) -ec '( cd dist; $(MAKE) dist )' + $(SHELL) -ec '( cd dist $(MAKE) dist )' install : .FORCE - $(SHELL) -ec '( cd object; $(MAKE) install )' + $(SHELL) -ec '( cd object $(MAKE) install )' dist-src : .FORCE - $(SHELL) -ec '( cd dist; $(MAKE) dist-src )' + $(SHELL) -ec '( cd dist $(MAKE) dist-src )' config : .FORCE - $(SHELL) -ec '( cd object; $(MAKE) config )' + $(SHELL) -ec '( cd object $(MAKE) config )' win32 : .FORCE $(MAKE) TARGET=i686-pc-mingw32 tidy : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) tidy ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) tidy ); done' clean : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) clean ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) clean ); done' distclean spotless : .FORCE -rm -f *~ - -$(SHELL) -c 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) distclean ); done' + -$(SHELL) -c 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) distclean ); done' .FORCE : diff -r c25547efbe21 function/Makefile --- a/function/Makefile Thu Dec 06 06:22:48 2007 -0600 +++ b/function/Makefile Thu Dec 06 06:24:58 2007 -0600 @@ -1,18 +1,21 @@ SUBDIRS = objects jolt-burg SUBDIRS = objects jolt-burg all : .FORCE - $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) ); done' + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) ); done' tidy : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) tidy ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) tidy ); done' clean : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) clean ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) clean ); done' + +run test : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) run ); done' distclean spotless : .FORCE rm -f *~ - -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir; $(MAKE) spotless ); done' + -$(SHELL) -ec 'for dir in $(SUBDIRS) examples; do ( cd $$dir $(MAKE) spotless ); done' .FORCE : diff -r c25547efbe21 function/examples/Makefile --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/function/examples/Makefile Thu Dec 06 06:24:58 2007 -0600 @@ -0,0 +1,21 @@ +SUBDIRS = cairo jcanvas libjolt peg prag-parse profile regexp select slotnames struct x-drawing x-event + +all : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) ); done' + +tidy : .FORCE + rm -f *~ + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) tidy ); done' + +clean : .FORCE + rm -f *~ + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) clean ); done' + +run test : .FORCE + $(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) run ); done' + +distclean spotless : .FORCE + rm -f *~ + -$(SHELL) -ec 'for dir in $(SUBDIRS); do ( cd $$dir $(MAKE) spotless ); done' + +.FORCE : diff -r c25547efbe21 function/examples/cairo/Makefile --- a/function/examples/cairo/Makefile Thu Dec 06 06:22:48 2007 -0600 +++ b/function/examples/cairo/Makefile Thu Dec 06 06:24:58 2007 -0600 @@ -1,11 +1,12 @@ JOLT = ../../jolt-burg/main JOLT = ../../jolt-burg/main +IDC = ../idc CAIROINC = $(patsubst %,-J%,$(wildcard /usr/include/cairo) $(wildcard /usr/local/include/cairo)) -test : cairolib.so .FORCE - $(JOLT) boot.k main.k +run test : cairolib.so .FORCE + $(IDC) -exec $(JOLT) boot.k main.k
[fonc] send-argument_count.patch
Hi,
Attached is a patch to derive a _send family from the libid __send
object, which adds a new member: argument_count. In idc-generated
files, this member is automatically set to the number of arguments
(not including the receiver) using the _send_argc(NUM) macro before
calling _send or _super. This family is local to a given idc
compilation unit, so that in the grand scheme it will be easier to
move to per-calling-site send object layouts.
In doing so, I noticed that idc's send objects can be constructed by
looking up _libid-import(__send) (which Jolt does implicitly in
function/objects/_object.st), so there's no reason to have the
_libid-send_vtable entry I introduced in
message-send-descriptors.patch... I've removed it.
The work on the function/* end of things was a lot simpler since the
foundations for dynamic send objects were already put in place by the
message-send-descriptors.patch, and there were only two places to
update with argument_count information: the send syntax first defined
in boot.k, then overridden in object.k.
Please do use this patch as an example of how to exploit the send
object in both the idc compiler and jolt-burg runtimes. I think it's
not that difficult a read for a unidiff of ~700 lines.
There's also one embarrassing mistake I fixed here that I introduced
with message-send-descriptors.patch: _objectdoesNotUnderstand: would
recursively blow the stack if it was called by object/stage2/idc1. To
fix it, see the STAGE1 comment in object/st80/_object.st.
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
Add #argument_count to the idc-generated send structure.
diff -r 231417544182 function/examples/libjolt/jolt.h
--- a/function/examples/libjolt/jolt.h Thu Dec 06 06:27:52 2007 -0600
+++ b/function/examples/libjolt/jolt.h Thu Dec 06 06:28:57 2007 -0600
@@ -58,9 +58,10 @@ static struct __libid *_libid= 0;
static struct __libid *_libid= 0;
#define _send_out_decl() \
- struct { oop _vtable; struct __send send; } _send_out_struct \
- __attribute__ ((unused))= { _libid-send_vtable }
+ struct { oop _vtable; struct __send send; oop argument_count; } \
+ _send_out_struct __attribute__ ((unused))= { _send_out_vtable }
#define _send_out (_send_out_struct.send)
+#define _send_argc(ARGC) do { _send_out_struct.argument_count= (oop)(ARGC 1 | 1); } while (0)
#define _send(MSG, RCV, ARG...) ({ \
@@ -79,6 +80,20 @@ static struct __libid *_libid= 0;
(*_m)(_send_out, ##ARG); \
})
+
+static oop _send_out_vtable= 0;
+static oop _send_out__argument_count(struct __send *send)
+{
+ struct { struct __send send; oop argument_count; } *_self = (void *)send-state;
+ return _self-argument_count;
+}
+
+
+struct t__object
+{
+ oop _vtable[0];
+};
+
extern oop __id__init__libjolt(void);
static void *__libjolt_ref= __id__init__libjolt;
@@ -87,12 +102,19 @@ oop __id__init__(struct __libid *__libid
if (_libid) return;
if (!(_libid= __libid)) { fprintf(stderr, init _libid %p\n, __libid); abort(); }
+ /* Set up the flavour of _send_out object we use for this file. */
+ oop _send_out_proto= _libid-proto(_libid-import(__send));
+ _libid-method(_send_out_proto, _libid-intern(argument_count), (_imp_t)_send_out__argument_count);
+ _send_out_vtable= _send_out_proto-_vtable[-1];
+
_send_out_decl();
+ _send_argc(2);
_send(_libid-intern(_import:),
_libid-_object,
libjolt,
__id__init__libjolt);
+ _send_argc(0);
return _send(_libid-intern(initialise),
_libid-import(Jolt));
}
diff -r 231417544182 function/jolt-burg/boot.k
--- a/function/jolt-burg/boot.k Thu Dec 06 06:27:52 2007 -0600
+++ b/function/jolt-burg/boot.k Thu Dec 06 06:28:57 2007 -0600
@@ -109,52 +109,55 @@
;; Allocate and free _send_out structures on the heap until we can do
;; stack allocations.
-(define malloc-send
+(define _send (import _send))
+(define new-send
(lambda ()
-(let ((_send_out_struct (malloc (* 5 sizeof-long
+(let ((_send_out_struct (malloc
+ (* 6 sizeof-long ;; [_send sizeof]
(let ((_send_out (+ _send_out_struct sizeof-long)))
- (set-long@ _send_out (- 0 1) (long@ _libid 35)) ;; send_vtable
+ (set-long@ _send_out (- 0 1)
+ (long@ _send (- 0 1))) ;; [_send _vtable]
_send_out
-(define free-send
+(define delete-send
(lambda (_send_out)
(let ((_send_out_struct (- _send_out sizeof-long)))
(free _send_out_struct
(define _bind
- (lambda (_send_out selector receiver)
-;; _send_out-receiver = receiver
+ (lambda (_send_out selector receiver argument_count)
+;; [_send_out receiver: receiver]
(set-long@ _send_out 0 receiver)
-;; _send_out-selector = selector
+;; [_send_out selector: selector]
(set-long@ _send_out 2 selector)
-;; _libid-bind(_send_out, _send_out-receiver)
+;; [_send_out argument_count: argument_count]
+(set-long@ _send_out 4 argument_count)
+;; { _libid-bind(_send_out, _send_out-receiver
Re: [fonc] Compilation problem: undefined reference to `GC_malloc'
Hi, Antoine...
Antoine van Gelder [EMAIL PROTECTED] writes:
Patch attached which switches libjolt to use _libid-* style calls as
well as a Makefile fix for the awk script which was causing Michael's
syntax errors.
Great!
I took your patch and added some minor improvements (attached):
* Use ../idc, so that libjolt will build with the newly-compiled idc
instead of the installed one.
* Implement and use the 'idc -C CPPFLAGS' option to get the path to
the include directory instead of hardcoding it.
* Declare _local_init to be the right type instead of casting it.
Thanks for getting this working again,
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
diff -r 80d0db8bd40d function/examples/libjolt/Makefile
--- a/function/examples/libjolt/Makefile Thu Nov 22 18:42:15 2007 -0600
+++ b/function/examples/libjolt/Makefile Thu Nov 22 19:29:19 2007 -0600
@@ -1,4 +1,4 @@ IDC = idc -k # -O
-IDC = idc -k # -O
+IDC = ../idc -k # -O
OBJECTS = ../../objects
MPINT = ../../objects/mpint
JOLT = ../../jolt-burg
@@ -11,6 +11,7 @@ OBJEXT_SO = .so
LDFLAGS = $(shell $(IDC) -C LDFLAGS)
LDLIBS = $(shell $(IDC) -C LDLIBS)
+CPPFLAGS = $(shell $(IDC) -C CPPFLAGS)
JOLT_OBJ_FILES = $(filter-out $(JOLT)/readline.o, $(wildcard $(JOLT)/*.o))
JOLT_BOOT_FILES = boot.k quasiquote.k syntax.k number.k object.k
@@ -50,7 +51,7 @@ test : jest$(OBJEXT) .FORCE
#
boot.h : $(JOLT_BOOT_FILES)
cat $(JOLT_BOOT_FILES) | \
- awk 'BEGIN {RS = \(define herald.*contents\]\)\)\)\)} {print $$0}' | \
+ awk 'BEGIN {RS = \(define herald.*contents\\]\\)\\)\\)\\)} {print $$0}' | \
grep -Ev '^(;|$$)' | \
sed -e 's/;//g' -e 's/;.*$$//' -e 's/\\//g' -e 's//\\/g' | \
awk '{print \, $$0, \}' | \
@@ -61,8 +62,8 @@ libjolt.o : boot.h
libjolt.o : boot.h
libjolt.a : libjolt.o
- ld -r libjolt.o $(OBJECTS)/*.o $(MPINT)/*.o $(JOLT_OBJ_FILES) $(OBJ)/gc.a \
- $(OBJ)/libid.o -o [EMAIL PROTECTED]
+ ld -r libjolt.o $(OBJECTS)/*.o $(MPINT)/*.o $(JOLT_OBJ_FILES) \
+ $(OBJ)/libid.o $(OBJ)/gc.a -o [EMAIL PROTECTED]
ar rsc [EMAIL PROTECTED] [EMAIL PROTECTED]
rm [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
@@ -73,11 +74,11 @@ install: libjolt.a
cp jolt.h /usr/include
test-libjolt : libjolt.a .FORCE
- gcc -o $@ [EMAIL PROTECTED] $(LDFLAGS) libjolt.a $(LDLIBS)
+ gcc $(CPPFLAGS) -o $@ [EMAIL PROTECTED] $(LDFLAGS) libjolt.a $(LDLIBS)
./$@
jest : jest.c libjolt.a jolt.h
- gcc -o $@ [EMAIL PROTECTED] $(LDFLAGS) libjolt.a $(LDLIBS)
+ gcc $(CPPFLAGS) -o $@ [EMAIL PROTECTED] $(LDFLAGS) libjolt.a $(LDLIBS)
tidy : .FORCE
-rm -f *.o *.d *~ .gdb* *.stackdump *.o.c boot.h
diff -r 80d0db8bd40d function/examples/libjolt/jolt.h
--- a/function/examples/libjolt/jolt.h Thu Nov 22 18:42:15 2007 -0600
+++ b/function/examples/libjolt/jolt.h Thu Nov 22 19:29:19 2007 -0600
@@ -50,67 +50,51 @@ typedef struct t__object *oop;
typedef oop (*_imp_t)(oop _thunk, oop receiver, ...);
-struct __closure
-{
- _imp_t method;
- oop data;
-};
-
-static oop (*_local_intern )(const char *string)= 0;
-static oop (*_local_import )(const char *name)= 0;
-static struct __closure *(*_local_bind)(oop selector, oop receiver)= 0;
-static oop _local_object= 0;
+#include id/id.h
+static struct __libid *_libid= 0;
#define _send(MSG, RCV, ARG...) ({ \
register oop _r= (RCV); \
- struct __closure *_c= (struct __closure *)_local_bind((MSG), _r); \
+ struct __closure *_c= (struct __closure *)_libid-bind((MSG), _r); \
(_c-method)((oop)_c, _r, _r, ##ARG); \
})
#define _super(TYP, MSG, RCV, ARG...) ({\
register oop _r= (RCV); \
- struct __closure *_c= (struct __closure *)_local_bind((MSG), (TYP)); \
+ struct __closure *_c= (struct __closure *)_libid-bind((MSG), (TYP)); \
(_c-method)((oop)_c, _r, _r, ##ARG); \
})
-
-static oop s__5fimport_= 0;
-static oop s_initialise= 0;
-static oop s_size_5f_value_5f_= 0;
-
-static oop v_String= 0;
-static oop v_Jolt= 0;
extern oop __id__init__libjolt(void);
static void *__libjolt_ref= __id__init__libjolt;
-oop __id__init__(void)
+oop __id__init__(struct __libid *__libid)
{
- if (_local_object) return;
- {
-dlhandle_t global= dlopen(0, RTLD_LAZY);
-_local_object= *(oop *)dlsym(global, _libid_object);
-_local_intern= dlsym(global, _libid_intern);
-_local_import= dlsym(global, _libid_import);
-_local_bind= dlsym(global, _libid_bind);
-dlclose(global);
- }
- s__5fimport_ = _local_intern(_import:);
- s_initialise = _local_intern(initialise);
- s_size_5f_value_5f_ = _local_intern(size_:value_:);
- _send(s__5fimport_, _local_object, libjolt, __id__init__libjolt);
- v_String= _local_import(String);
- v_Jolt= _local_import(Jolt);
- return _send(s_initialise, v_Jolt);
+ if (_libid) return;
+ if (!(_libid= __libid)) { fprintf(stderr, init _libid %p\n, __libid); abort(); }
+
+ _send(_libid-intern(_import:),
+_libid-_object,
+libjolt,
+__id__init__libjolt
Re: [fonc] Error compiling latest SVN
../stage1/idc -B../stage1/ -O -I../st80 -k -c CCodeGenerator.st -o ../stage2/CCodeGenerator.o BlockClosure does not understand 'encoder' I suspect you need to clear out stage[12]. Try 'make spotless' in idst/object. Argh. Mea culpa. It was some leftover brokenness from my own attempt at variadic arguments. Reverting those changes fixed everything. Sorry to waste your time, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] nested environments in Jolt
Hi, I'm trying to nest environments in my Jolt code as I would in Scheme (but there I'd use a 'let*' instead of just 'let'): (define test (lambda (foo) (let ((bar 1) (bot (lambda () (set bar 3 (printf bar is %d\n bar) (set bar 2) (printf bar is %d\n bar) (bot) (printf bar is %d\n bar (test) I'd want to see: bar is 1 bar is 2 bar is 3 However, this code produces a compile-time error: Object.st:138 Object error: Compiler.st:917 Compiler errorUndefined: Compiler.st:704 ? [] Object.st:84 UndefinedObject ifNil: Compiler.st:195 Compiler lookupVariable:ifAbsent: Compiler.st:704 Compiler setVariable:from: Compiler.st:697 Compiler xSet: Compiler.st:337 Compiler performSyntax:with: Compiler.st:306 Compiler translateExpression: Compiler.st:269 Expression translate: [...] undefined: bar Upon investigation, the error is caused by the reference to 'bar' in the innermost lambda. How do I construct a closure in Jolt that can bind to variables that are local to the function in which the closure was created? I'd like this in order to implement a useful callback function (which modifies the state of its lexical environment, regardless of its caller). I don't want to use global variables due to multithreading concerns. Thanks for any help you can offer, -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Variadic Pepsi methods
Ian Piumarta [EMAIL PROTECTED] writes:
On Jun 20, 2007, at 8:20 AM, Michael FIG wrote:
I could really use variadic methods. I seem to recall they were being
discussed earlier, but I can't find an archive.
These haven't worked for a while. The Parser does still recognise
'...' at the end of a method pattern but the Encoder doesn't
implement the method required to deal with it. If you can think of a
nice syntax to represent 'the next unnamed variadic argument' (i.e.,
the thing that would be translated as 'va_arg(ap, oop)') I'd happily
reinstate it.
I would suggest a simple change from the existing code: just introduce
the following for methods that have ... at the end of their
arguments:
va_list nextArgument;
va_start(nextArgument, v_lastNamedArg);
[...]
then, before every return in the function, put:
va_end(nextArgument);
It's fine to have the user be the one to do:
{ v_myvar = va_arg(nextArgument, oop); }
Unfortunately there's no easy way to implement the equivalent C code
inside curlies, since the va_list would go out of scope at the
closing '}' of its declaration.
Yeah. As long as the compiler manages the va_list, then I think it's
okay for the user to invoke the va_* macros directly.
Thanks,
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Opengl tiny example with Pepsi
Hi,
Claudio Campos [EMAIL PROTECTED] writes:
I fixed it, I replaced the include file directives in my pepsi code:
{ include /usr/include/w32api/GL/glut.h }
{ include /usr/include/w32api/GL/gl.h }
{ include /usr/include/w32api/GL/glu.h }
A better way is to keep the sources as they were, and add
-J/usr/include/w32api to your idc command line.
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] wrapping an iteration function
Hi,
The library I'm currently writing an OO interface for (libmono) has an
iteration construct that is used something like this:
MonoMethod m;
gpointer iter = NULL;
while ((m = mono_class_get_methods (klass, iter))) {
// Do stuff with m.
}
Ideally, I'd like to change this interface so that it can be used from
Pepsi something like this:
class whileTrueWithMethod: [ :method | Do stuff with method. true. ]
implemented as:
MonoClass whileTrueWithMethod: methodBlock
[
| iter iterp |
FIXME: For some reason v_iterp isn't available.
{ v_iterp = (oop)v_iter; }.
{ ((oop *)_state1)[2] = (oop)v_iter; }.
[| method |
method := MonoMethod _new: (libmono mono_class_get_methods : _ptr : iterp);
and: (methodBlock value: method)] whileTrue.
]
Please let me know if there's a better (more idiomatic) way to do this
kind of iteration. I'd also like to fix the FIXME: the v_iterp symbol
isn't available to the C code maybe because it's captured by the block
closure.
I'm a little stuck as to how I could use this method from Jolt. It
looks like I should construct a callback with lambda, then convert it
to a BlockClosure, but I don't understand what all the arguments to
BlockClosure function_:arity_:outer:state:nlr_ should be.
[BTW, thanks, Ian, for the replies to my other questions. I'll just
go on implementing the libmono wrappers I need ad hoc until the great
C include file parser is done, and I'll go without variadic arguments
until I figure out enough about exactly how I want to use them.]
--
Michael FIG [EMAIL PROTECTED] //\
http://michael.fig.org/\//
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
