RE: ANN: alt-design can now be integrated??
John Austin wrote: On Wed, 2003-11-19 at 15:34, Victor Mote wrote: ANNOUNCEMENT: I have just committed a change that 1) allows LayoutStrategy to tell whether an FO Tree should be built, 2) has Driver act on this, i.e. to build an FO Tree only if LayoutStrategy indicates that this should be done. This should theoretically allow Peter's logic to be used as a LayoutStrategy within the trunk development line. What I have done is probably overly simplistic, but I will allow Peter or anyone wishing to work on that strategy tell us what additional things are needed to accommodate. To start integrating, create a subclass of LayoutStrategy, override the foTreeNeeded() method to return false, then write a format() method that does the layout work. LayoutStrategy knows its parent Document, which knows its parent Driver, so you should be able to get to all of the parsing variables that are needed. Let me know if you need help. Since configuration is still messed up, you will need to hard-code a change to Driver to get your new LayoutStrategy object created. Victor Mote Geez! I was thinking more along the lines of plugging in a few new data structures for property lookup. I am exploring the old implementation through the marvel of code grooming in order to understand it. This is not directly related to what you are doing. I realized in one of my responses to Peter yesterday that it would be easier for me to go ahead and implement the FO-Tree-less LayoutStrategy than it was to explain its theoretical possibility (again). This is an attempt to make it easier for Peter to integrate his work. If it helps you, good. If not, at least I don't think it will hurt. Don't worry, I have the time to do this right. I got a tiny improvement by playing around in some of PropertyList and PropertyListBuilder. This is just a throw-away effort of course. I did enough tracing this a.m. to realize that my 'linear behaviour' may be deeply buried. I have done this often enough that I don't expect more than marginal improvements from grooming/tweaking lines of code. [Gone are the days of PL/I and unaligned bit fields.] Before I found out about Alt-Design, I was thinking about using a HashMap with property names as keys and a class implementing some stack behaviour. Each new FO would conceptually 'push' new values on a stack for each property in it's list. A smart 'pop' would allow the entire set of properties for a FO to be popped together. Hopefully, this design would allow faster access to the current properties, without a need to search through higher 'activation records', 'stack frames', contexts or whatever you choose to call them. The observations of performance indicate that there are millions of accesses through PropertyList.get(String propertyName) which are sent one-to-one through PropertyList.get( propertyName, true, true) and thence on to PropertyList.findProperty( propertyName, true ). Combine this information with the fact that I didn't notice the performance of the corresponding put() operations on the HashMap underneath PropertyList to conclude that retrieval is much more intensive than storage in this structure. So I should optimize retrievals. That certainly sounds right to me. My plan is to get to know the internals of FOP that are 'in contact with' the existing code, then get to know the Alt-Design, then play with more and more of it until I feel comfortable integrating it. I don't expect fast-track to committer status, I would hope to work with one or two current participants and package the changes so that they 'drop in' to place. (We'll see) We're glad to have you involved here. Victor Mote
Re: ANN: alt-design can now be integrated??
On Wed, 2003-11-19 at 15:34, Victor Mote wrote: ANNOUNCEMENT: I have just committed a change that 1) allows LayoutStrategy to tell whether an FO Tree should be built, 2) has Driver act on this, i.e. to build an FO Tree only if LayoutStrategy indicates that this should be done. This should theoretically allow Peter's logic to be used as a LayoutStrategy within the trunk development line. What I have done is probably overly simplistic, but I will allow Peter or anyone wishing to work on that strategy tell us what additional things are needed to accommodate. To start integrating, create a subclass of LayoutStrategy, override the foTreeNeeded() method to return false, then write a format() method that does the layout work. LayoutStrategy knows its parent Document, which knows its parent Driver, so you should be able to get to all of the parsing variables that are needed. Let me know if you need help. Since configuration is still messed up, you will need to hard-code a change to Driver to get your new LayoutStrategy object created. Victor Mote Geez! I was thinking more along the lines of plugging in a few new data structures for property lookup. I am exploring the old implementation through the marvel of code grooming in order to understand it. Don't worry, I have the time to do this right. I got a tiny improvement by playing around in some of PropertyList and PropertyListBuilder. This is just a throw-away effort of course. I did enough tracing this a.m. to realize that my 'linear behaviour' may be deeply buried. I have done this often enough that I don't expect more than marginal improvements from grooming/tweaking lines of code. [Gone are the days of PL/I and unaligned bit fields.] Before I found out about Alt-Design, I was thinking about using a HashMap with property names as keys and a class implementing some stack behaviour. Each new FO would conceptually 'push' new values on a stack for each property in it's list. A smart 'pop' would allow the entire set of properties for a FO to be popped together. Hopefully, this design would allow faster access to the current properties, without a need to search through higher 'activation records', 'stack frames', contexts or whatever you choose to call them. The observations of performance indicate that there are millions of accesses through PropertyList.get(String propertyName) which are sent one-to-one through PropertyList.get( propertyName, true, true) and thence on to PropertyList.findProperty( propertyName, true ). Combine this information with the fact that I didn't notice the performance of the corresponding put() operations on the HashMap underneath PropertyList to conclude that retrieval is much more intensive than storage in this structure. So I should optimize retrievals. My plan is to get to know the internals of FOP that are 'in contact with' the existing code, then get to know the Alt-Design, then play with more and more of it until I feel comfortable integrating it. I don't expect fast-track to committer status, I would hope to work with one or two current participants and package the changes so that they 'drop in' to place. (We'll see) -- John Austin [EMAIL PROTECTED]
Re: ANN: alt-design can now be integrated??
John Austin wrote: On Wed, 2003-11-19 at 15:34, Victor Mote wrote: Geez! I was thinking more along the lines of plugging in a few new data structures for property lookup. I am exploring the old implementation through the marvel of code grooming in order to understand it. Don't worry, I have the time to do this right. I got a tiny improvement by playing around in some of PropertyList and PropertyListBuilder. This is just a throw-away effort of course. I did enough tracing this a.m. to realize that my 'linear behaviour' may be deeply buried. I have done this often enough that I don't expect more than marginal improvements from grooming/tweaking lines of code. [Gone are the days of PL/I and unaligned bit fields.] Before I found out about Alt-Design, I was thinking about using a HashMap with property names as keys and a class implementing some stack behaviour. Each new FO would conceptually 'push' new values on a stack for each property in it's list. A smart 'pop' would allow the entire set of properties for a FO to be popped together. Hopefully, this design would allow faster access to the current properties, without a need to search through higher 'activation records', 'stack frames', contexts or whatever you choose to call them. I initially looked at a stack based approach. It seems natural enough, given the nature of (most) inheritance. As I went along, I gradually abandoned more and more of it, and finally realised that there was nothing worthwhile left. I posted an epitaph to my stacks at this point. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
