Re: Building FOP Trunk with Any - BUILD FAILED
It looks suspiciously like this guy:
C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xml
(Line 353 btw)
It would be nice to see what is actually being passed into the
eventResourceGenerator task.
bonekrusher wrote:
Peter,
Which file is this?
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
Phil
Peter B. West wrote:
bonekrusher wrote:
I will test this out later today on my home PC. I get a different set of
errors on different machines.
In the mean time I ran a new svn check out (as you suggested) on my work
PC
and got the same original error message e.g.
BUILD FAILED
C:\foptrunk2\trunk\build.xml:353: java.io.IOException:
java.io.FileNotFoundExcep
tion:
file:\C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xm
l (The filename, directory name, or volume label syntax is incorrect)
So its seems I have two different problems. I thought I might be doing
something fundamentally wrong, but I was able to build FOP 0.94.
As Jeremias suggested, I will try to download the trunk again from my
home
PC. I don't want to confuse the error reports from one machine to
another
as they appear to be different.
Well, it's incorrect URL syntax. Presumably
${build.gensrc.dir}/org/apache/fop/events/event-model.xml
(see line 353) is being passed in as a file path, not a URL.
Put
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
In any case, it seems to be getting converted into a badly formed file:
URL within the ant task.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: java.nio.CharBuffer
Andreas Delmelle wrote:
On Jul 14, 2008, at 18:15, Andreas Delmelle wrote:
snip /
Just quickly ran Jeremias' test-app myself, and on Apple JVM (1.5), the
difference is +/-300ms for a million iterations, but not very
consistent. Sometimes StringBuffer operates slightly faster, other times
it's CharBuffer that wins. I guess the backing implementations are very
closely related anyway, so it's not all that surprising.
It would most definitely be a huge overkill if it is /only/ used for
simple String concatenation. In the context of catching SAX characters()
events, I think the penalty is bound to be limited (maybe even on the
contrary: see below). That is, I don't think I've ever seen a parser
that reports characters one at a time (which would make the current
implementation using CharBuffer very slow). Most SAX parsers report the
characters in reasonably large chunks (as much as possible).
Just for fun, make it:
...
private static final char[] prefix = {' ', 'm', 'y', 'V', 'a', 'l', 'u',
'e', '='};
...
public String runCharBuffer() {
CharBuffer buf = CharBuffer.allocate(1024);
for (int i = 0; i STEPS; i++) {
buf.put(prefix).put(Integer.toString(i).toCharArray());
}
return buf.rewind().toString();
}
...
On my end, this runs noticeably faster than when passing Strings (almost
20%). When switching StringBuffer.append() to use char[] parameters, it
runs a tiny bit slower than with Strings... No idea if this also holds
for the Sun, IBM or Apache implementations.
Qua flexibility, the API for a CharBuffer (optionally) offers the
possibility to get a reference to the backing array. For StringBuffer,
we'd have to do something like: sb.toString().toCharArray(), and IIC,
this always yields an independent copy of the StringBuffer's array, not
the array itself. (Note that this obviously also has its drawbacks;
sometimes, you just /need/ an independent copy...)
Come 1.5, you get StringBuilder.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: Building FOP Trunk with Any - BUILD FAILED
Thanks Peter.
C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xml
This file is missing.
Peter B. West wrote:
It looks suspiciously like this guy:
C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xml
(Line 353 btw)
It would be nice to see what is actually being passed into the
eventResourceGenerator task.
bonekrusher wrote:
Peter,
Which file is this?
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
Phil
Peter B. West wrote:
bonekrusher wrote:
I will test this out later today on my home PC. I get a different set
of
errors on different machines.
In the mean time I ran a new svn check out (as you suggested) on my
work
PC
and got the same original error message e.g.
BUILD FAILED
C:\foptrunk2\trunk\build.xml:353: java.io.IOException:
java.io.FileNotFoundExcep
tion:
file:\C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xm
l (The filename, directory name, or volume label syntax is incorrect)
So its seems I have two different problems. I thought I might be doing
something fundamentally wrong, but I was able to build FOP 0.94.
As Jeremias suggested, I will try to download the trunk again from my
home
PC. I don't want to confuse the error reports from one machine to
another
as they appear to be different.
Well, it's incorrect URL syntax. Presumably
${build.gensrc.dir}/org/apache/fop/events/event-model.xml
(see line 353) is being passed in as a file path, not a URL.
Put
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
In any case, it seems to be getting converted into a badly formed file:
URL within the ant task.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
--
View this message in context:
http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18462574.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Building FOP Trunk with Any - BUILD FAILED
bonekrusher wrote: Hi, Thanks Peter. C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xml This file is missing. That file is created by the build process. I think Peter was talking about how the build process references the file internally. snip/ Chris
Re: java.nio.CharBuffer
On Jul 15, 2008, at 09:16, Peter B. West wrote: Andreas Delmelle wrote: snip / Come 1.5, you get StringBuilder. Yep, this indeed becomes /the/ weapon of choice for building strings (in single-threaded context), if that's the goal. For FOText, I don't think that is the goal. We're simply buffering accumulating characters there, and in that case, a CharBuffer seems much more appropriate (even in Java 1.5+). Not sure what explains the drop in performance in Sun Java 1.6 though... For Harmony, I guess the implementation has not yet been optimized. Understandable, especially if CharBuffer is not commonly used. Cheers Andreas
DO NOT REPLY [Bug 45390] PDF Extensions - Prototype
https://issues.apache.org/bugzilla/show_bug.cgi?id=45390 Andreas L. Delmelle [EMAIL PROTECTED] changed: What|Removed |Added Attachment #22249|0 |1 is obsolete|| --- Comment #1 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-07-15 14:29:23 PST --- Created an attachment (id=22261) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22261) Updated patch Added minimal support for subdictionaries and boolean entries, so the following now becomes possible: pdf:dictionary type=catalog xmlns:pdf=http://xmlgraphics.apache.org/fop/extensions/pdf; pdf:entry name=PageMode type=nameFullScreen/pdf:entry pdf:dictionary type=normal name=ViewerPreferences pdf:entry name=HideToolbar type=booleantrue/pdf:entry pdf:entry name=HideWindowUI type=booleantrue/pdf:entry pdf:entry name=FitWindow type=booleantrue/pdf:entry pdf:entry name=CenterWindow type=booleantrue/pdf:entry pdf:entry name=NonFullScreenPageMode type=nameUseThumbs/pdf:entry /pdf:dictionary /pdf:dictionary -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
