--- [EMAIL PROTECTED] wrote: > Mike -- > > Thats a lot of metadata. Sounds like maybe the metadata is primary > and the bytecode is secondary, in which case perhaps what you > really want is a (metadata) tree decorated with bytecode rather than > a (bytecode) array decorated with metadata.
Fair enough. good point! > Of course, the most natural candidate for the metadata would be the > annotated (file & line, etc.) parse tree, or some approximation to it > after compilation-related transformations. OK that sounds fine. My current problems with the graphs of meta-data are the speed of loading. I would like to use something like what you are talking about with the mmap. Also, dot.net IL has tons of meta-data, very very much of it. > > I can imagine a process that loads the tree, and linearizes the > bytecode with the metadata consisting of backpointers to nodes of > the tree, either in band as escaped noop-equivalent bytecode or > out of band in an offset-pointer table. Sure, a zippper (Reihverschluss ;) concept. > > With a suitable amount of forethought on the tree representation, > you should be able to have good flexibility while still having enough > standardization on how tree-emitting compilers represent typical > debug-related metadata (file, line, etc.) that debuggers and other > tools could be generic. OK. Well the current rdf format that I have is ok, so that brings me back to the idea of using rdf.... Redland supports a bdb, which also supports fast loading, but is not platform independant. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
