DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-22 09:10 --- Applied. Futher comments from xml-dev: http://marc.theaimsgroup.com/?l=fop-dev&m=107308498806385&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=107445625709662&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=107434372324847&w=2
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-20 07:33 --- Glen, yes please skip that change to InlineStakingLM. The change avoid a NPE when generating the docbook example I've used for timing but I have never analysed the problem so I doubt the change is the correct fix.
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-20 02:05 --- Created an attachment (id=10016) current status of patch (down to about 4900 lines from 6200).
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873
[PATCH] abandoning code-generated Property.Maker
--- Additional Comments From [EMAIL PROTECTED] 2004-01-20 02:03 ---
Finn,
You have a change that doesn't appear relevant to this bug in
InlineStackingLayoutManager.java:
Index: src/java/org/apache/fop/layoutmgr/InlineStackingLayoutManager.java
===
@@ -292,6 +292,10 @@
// Reset state variables
clearPrevIPD(); // Clear stored prev content dimensions
}
+// I don't have a clue if this is right.
+if (childLC == null) {
+childLC = new LayoutContext(lc);
+}
// We only do this loop more than once if a childLM returns
// a null BreakPoss, meaning it has nothing (more) to layout.
Should we skip this change?
Thanks,
Glen
Re: [PATCH] abandoning code-generated Property.Maker
Worked great--thanks! Glen --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > Glen Mazza wrote: > > > > select="document(propfile)//property[not(@type='generic')]" > > /> ) > ... > > I am not an XSLT guru--offhand, does anyone know > of a > > simple way to get the interfaces to appear > > alphabetically? > > It ought to be > > > > > Substitute in the xsl:sort's select whatever is the > sort key. > > J.Pietschmann > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: [PATCH] abandoning code-generated Property.Maker
Glen Mazza wrote: ) ... I am not an XSLT guru--offhand, does anyone know of a simple way to get the interfaces to appear alphabetically? It ought to be Substitute in the xsl:sort's select whatever is the sort key. J.Pietschmann
Re: [PATCH] abandoning code-generated Property.Maker
Team, I moved the 64 or so property value interfaces from separate autogenerated files to Constants.java yesterday. The work is not perfect--there are still a few linkages to (autogenerated) generic enumerations (I will fix these after we apply Finn's latest properties patch), a couple of interfaces conflicted name-wise with already existing classes (I just commented those interfaces out--we can forgo those). Also, for classes not implementing Constants, a Constants.InterfaceName.PropertyValue name ends up needing to be used--but for these, we can also easily revert to Constants.PropertyValue. These interfaces are just meant to be a developer convenience, not something required. One (minor) thing I would like to fix though, is that the interfaces are not appearing in alphabetical order in Constants.java (Java [1], XSLT source [2]) (in the XSLT, under the Enumeration Interfaces comment: // Enumeration Interfaces ) [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/Constants.java?rev=1.4&view=auto [2] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/codegen/constants.xsl?rev=1.2&view=auto I am not an XSLT guru--offhand, does anyone know of a simple way to get the interfaces to appear alphabetically? It's not that big a deal, but there might be something very obvious I've missed, a simple change to get them in alpha order. Thanks, Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: [PATCH] abandoning code-generated Property.Maker
--- Finn Bock <[EMAIL PROTECTED]> wrote: > > The patch does not unnest the Property.Maker class. > It doesn't matter > all that much to me, but if it is considered a good > idea it is easy to do. > Ooops...I think I had misread the code there. Actually, hold off on this then. > > Should the values of the constants still be globally > unique, or just > unique within each inner-interface? I would say > globally unique since it > would be easier to add a int->string method > somewhere for debugging. > Absolutely--still globally unique, and I have no intention of changing the interfaces' internal value definitions--they will still be equal to Constants.this and Constants.that. If the interfaces still prove later to not be that helpful, we can get rid of them and just switch to the same-named constant. I look into doing making the changes on this issue now. > > I think you have mentioned this a couple of times > before, but I didn't > understand it back then either. Perhaps I just > doesn't understand what > part of our code you consider Renderer and Area > Tree. Because I can't > find any references to properties or propertyList in > the area package or > in the pdf and ps renderer. > Maybe nothing in fo.Area needs conversion; very little with the renderers (except RTFRenderer, because it doesn't use an area tree. I remember needing to convert a few of the properties there from Strings->ints.) I thought we had made some property requests in PDFRenderer and AWTRenderer, but I may be wrong there. But this is a minor issue, after we tackle this patch. Glen __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
From that perspective, yes, of course. On 17.01.2004 14:55:03 Andreas L. Delmelle wrote: > > -Original Message- > > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > > > > > > > > I'm indifferent whether you go forward with this or not. I personally > > think it's unnecessary. > > > > Unnecessary, yes, for those who are familiar enough with the code. I think > however, this proposal would make the sources as a whole a bit easier to > understand for interested developers who want to aid in writing > patches/bugfixes. Perhaps this is more of a key-argument in this case than > mere coding-convenience? Jeremias Maerki
RE: DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
> -Original Message- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > > > I'm indifferent whether you go forward with this or not. I personally > think it's unnecessary. > Unnecessary, yes, for those who are familiar enough with the code. I think however, this proposal would make the sources as a whole a bit easier to understand for interested developers who want to aid in writing patches/bugfixes. Perhaps this is more of a key-argument in this case than mere coding-convenience? Cheers, Andreas
Re: DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
Code-completion works for me today as I simply run "ant codegen" and include the build/gensrc directory in the list of source directories in my IDE. That was one of the reasons why I changed the build to generate the gensrc directory and why I moved the sources from src to src/java for HEAD: To make it easier to build FOP within an IDE without the need for running the Ant build every time, thus improving build speed a lot. I'm indifferent whether you go forward with this or not. I personally think it's unnecessary. On 17.01.2004 02:05:05 Glen on bugzilla wrote: > I'd like to have them retained, but put into (1) file, actually, just added to > the Constants interface (as inner interfaces), say adding about 600 lines in > that interface for them all. (I can modify the XSLT code to accomplish that.) > We get rid of those 45 files, and they will be no longer autogenerated with > each build (but, as with the current Constants.java, we retain the XSLT to re- > generate it when we like.) > > Reason why? I *think*, over the long-term, it is much more programmer-friendly > because many/most developers use IDE's with code-complete. I.E., you type in > the property value interface name, hit the ".", and then you automatically see > the 5-7 values relevant for that property. This saves the programmer the > headache of looking at the spec each time for which prop values you need to > code against, or trying to recall from a huge Constants list the actual values > you need, and also making sure all the property options have been coded > against. I think it will be a nice sanity-saver for coders. If not, we can > always excise them later from Constants.java. > > Thoughts on this? Jeremias Maerki
Re: [PATCH] abandoning code-generated Property.Maker
On bugzilla, Glen wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker > Please give me a couple of days to comment--say 48 hours. My initial thoughts are "I like what I see", esp. since appeared to you appeared to unnest the Property.Maker, which looks good, but I'd like to study the code further. The patch does not unnest the Property.Maker class. It doesn't matter all that much to me, but if it is considered a good idea it is easy to do. One difference we have, I can work on, is that I'm not yet ready to get rid of all those interfaces. The current interface implementation is awful and useless--code-generated, separated into 45 different files, not visible while one is coding, etc., etc. I'd like to have them retained, but put into (1) file, actually, just added to the Constants interface (as inner interfaces), say adding about 600 lines in that interface for them all. (I can modify the XSLT code to accomplish that.) We get rid of those 45 files, and they will be no longer autogenerated with each build (but, as with the current Constants.java, we retain the XSLT to re- generate it when we like.) Should the values of the constants still be globally unique, or just unique within each inner-interface? I would say globally unique since it would be easier to add a int->string method somewhere for debugging. Reason why? I *think*, over the long-term, it is much more programmer-friendly because many/most developers use IDE's with code-complete. I.E., you type in the property value interface name, hit the ".", and then you automatically see the 5-7 values relevant for that property. This saves the programmer the headache of looking at the spec each time for which prop values you need to code against, or trying to recall from a huge Constants list the actual values you need, and also making sure all the property options have been coded against. I think it will be a nice sanity-saver for coders. If not, we can always excise them later from Constants.java. Thoughts on this? +1 The only other issue right now--not necessarily related to your patch--is that I'd like us, where possible, to start abstracting the propertyList away from the Layout and Renderers, possibly also the Area Tree. I think you have mentioned this a couple of times before, but I didn't understand it back then either. Perhaps I just doesn't understand what part of our code you consider Renderer and Area Tree. Because I can't find any references to properties or propertyList in the area package or in the pdf and ps renderer. (This was an idea originally put forth by Victor a few weeks back, to general agreement on the list.) FObj already has a getProperty() function which just wraps its internal propertyList.getProperty()--and it's already used in a dozen or so places. Instead of layoutManager calling prop = propList.getProperty() left and right, it will be prop = fObj.getProperty(). This will give us some freedom in how we implement properties without needing to make changes to other parts of our code (i.e., we can even get rid of propertyList.) regards, finn
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-17 01:05 --- Please give me a couple of days to comment--say 48 hours. My initial thoughts are "I like what I see", esp. since appeared to you appeared to unnest the Property.Maker, which looks good, but I'd like to study the code further. Everything looks good though. [Sorry for the delays this week--I was held up on other things--also was sending some emails to W3C trying to understand which properties can be specified to which FO. See http://lists.w3.org/Archives/Public/xsl- editors/2004JanMar/] One difference we have, I can work on, is that I'm not yet ready to get rid of all those interfaces. The current interface implementation is awful and useless--code-generated, separated into 45 different files, not visible while one is coding, etc., etc. I'd like to have them retained, but put into (1) file, actually, just added to the Constants interface (as inner interfaces), say adding about 600 lines in that interface for them all. (I can modify the XSLT code to accomplish that.) We get rid of those 45 files, and they will be no longer autogenerated with each build (but, as with the current Constants.java, we retain the XSLT to re- generate it when we like.) Reason why? I *think*, over the long-term, it is much more programmer-friendly because many/most developers use IDE's with code-complete. I.E., you type in the property value interface name, hit the ".", and then you automatically see the 5-7 values relevant for that property. This saves the programmer the headache of looking at the spec each time for which prop values you need to code against, or trying to recall from a huge Constants list the actual values you need, and also making sure all the property options have been coded against. I think it will be a nice sanity-saver for coders. If not, we can always excise them later from Constants.java. Thoughts on this? The only other issue right now--not necessarily related to your patch--is that I'd like us, where possible, to start abstracting the propertyList away from the Layout and Renderers, possibly also the Area Tree. (This was an idea originally put forth by Victor a few weeks back, to general agreement on the list.) FObj already has a getProperty() function which just wraps its internal propertyList.getProperty()--and it's already used in a dozen or so places. Instead of layoutManager calling prop = propList.getProperty() left and right, it will be prop = fObj.getProperty(). This will give us some freedom in how we implement properties without needing to make changes to other parts of our code (i.e., we can even get rid of propertyList.) Thanks, Glen
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 17:57 --- Created an attachment (id=9981) A unified diff against HEAD
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 16:58 --- A new revision of the patch where the functionality of corresponding and compound properties are placed in seperate files. As a result, the main Property.Maker class becomes smaller and easier to understand. Performance is 4.5% faster with this patch, mostly due to the caching of the default values of subproperties. The main path through the code is shorter for non-compound properties and the same for compound properties and properties with corresponding. Functionally the patch is neutral, so the it gets the same result. There are some places in the patch marked with TODO where a solution to minor bugs in the existing code has been added as comments. With this revision I think the patch is ready to go in.
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-02 23:23 --- Never mind--I was typing this up while you were typing up your FOP-DEV email. Thanks for the explanations.
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-02 23:16 --- You should have no complaints from anyone on reducing the amount of automatic code generation we use. But just to confirm though, *not only* would the generation of the 250 or so Maker classes we have, one for each property, be stopped--but also, we would no longer be having those classes at all either, correct? (I.e., FOP 1.0 goes down from 915 classes or so to roughly 700?)--That would be fantastic! Also, leaving out the time saving as a result of moving off Strings, etc., i.e., all the time benefits of the previous huge patch, what is the performance loss/gain as a result of *this* change? (Hopefully) negligable? Thanks, Glen
DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker --- Additional Comments From [EMAIL PROTECTED] 2004-01-02 23:01 --- Created an attachment (id=9777) A unified diff against HEAD
DO NOT REPLY [Bug 25873] New: - [PATCH] abandoning code-generated Property.Maker
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25873 [PATCH] abandoning code-generated Property.Maker Summary: [PATCH] abandoning code-generated Property.Maker Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This patch disable the code generation of the property maker classes and instead creates instances of the base maker types and configures them with setter methods. The patch is *not* intended to be committed as is, but as meant as inspiration. In addition to the stated change of property maker classes, the patch also contain many of the bug fixes I've submitted recently.
