I'm trying to do a minimal cleanup on how compiled methods access
source as stage one of getting towards a new compiled method format. So far it has been somewhat painful due in no small part to the horrors of how many bits of code explicitly assume the sources being in files. I've moved all the source pointer stuff from the 'stick some extra bytes at the end of the method' approach to a 'have a proper oop in properties' one. This is nicer and will allow us to have 256Mb sources and changes files. Given the apparent propensity for the changes file to get overloaded with doit text (see recent mails on that problem) this might be quite useful! With further cleanups we can get away from the nasty assumption about files and use well encapsulated source accessors instead of excapsulated ones. Right now I'm trying to do some cleanup of all the peripheral grunge to do with this change. For example the users of #trailer, #generate: etc. So far as I can work out new methods are compiled with a default trailer of #(0 0 0 0) and then the source pointer is set shortly after; this is easy to change. It looks like assorted recompiles use a shortcut of grabbing the old CM trailer bytes and passing those to #generate: directly. That I can change to grab source pointer and set in new CM instance. The question I need to feel I have a good answer to is whether anyone is doing other nasty things with method trailers? I hope not, I think not, but I'm not sure not. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: DO: Deadstart Operator |
On 14 oct. 06, at 02:30, tim Rowledge wrote: > I'm trying to do a minimal cleanup on how compiled methods access > source as stage one of getting towards a new compiled method format. Cool please keep doing that!!!!! > So far it has been somewhat painful due in no small part to the > horrors of how many bits of code explicitly assume the sources > being in files. > > I've moved all the source pointer stuff from the 'stick some extra > bytes at the end of the method' approach to a 'have a proper oop in > properties' one. This is nicer and will allow us to have 256Mb > sources and changes files. Given the apparent propensity for the > changes file to get overloaded with doit text (see recent mails on > that problem) this might be quite useful! With further cleanups we > can get away from the nasty assumption about files and use well > encapsulated source accessors instead of excapsulated ones. > > Right now I'm trying to do some cleanup of all the peripheral > grunge to do with this change. For example the users of #trailer, > #generate: etc. So far as I can work out new methods are compiled > with a default trailer of #(0 0 0 0) and then the source pointer is > set shortly after; this is easy to change. It looks like assorted > recompiles use a shortcut of grabbing the old CM trailer bytes and > passing those to #generate: directly. That I can change to grab > source pointer and set in new CM instance. > > The question I need to feel I have a good answer to is whether > anyone is doing other nasty things with method trailers? I hope > not, I think not, but I'm not sure not. I hope not :) |
In reply to this post by timrowledge
On Fri, Oct 13, 2006 at 05:30:05PM -0700, tim Rowledge wrote:
> encapsulated source accessors instead of excapsulated ones. Excapsulation? Excellent word; it actually sounds like a rather appealing design feature. I think I'll try putting this into a powerpoint and see if I can use it to help sell a proposal of some sort. I should think that any pitch that claims a high level of excapulation, supported by metrics and a pyramid-shaped conceptual diagram, would be a real winner. Dave p.s. At least one other person has thought of this before: http://www.mail-archive.com/cfcdev@.../msg07200.html |
Free forum by Nabble | Edit this page |