DO NOT REPLY [Bug 14984] - XSLTC compiltation error : Branch target offset too large for short

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 14984] - XSLTC compiltation error : Branch target offset too large for short

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-xalan/c/src/XalanDOM XalanDOMString.cpp

dbertoni2002/12/02 18:24:20 Modified:c/src/XalanDOM XalanDOMString.cpp Log: Fixed recursive call in non-namespace aware build. Revision ChangesPath 1.30 +1 -1 xml-xalan/c/src/XalanDOM/XalanDOMString.cpp Index: XalanDOMString.cpp ==

cvs commit: xml-xalan/c/samples/XPathWrapper TestDriver.cpp XPathWrapper.hpp

dbertoni2002/12/02 16:59:43 Modified:c/samples/XPathWrapper TestDriver.cpp XPathWrapper.hpp Log: Fixed typedef. Revision ChangesPath 1.12 +1 -1 xml-xalan/c/samples/XPathWrapper/TestDriver.cpp Index: TestDriver.cpp =

cvs commit: xml-xalan/c/src/XalanTransformer XercesDOMWrapperParsedSource.cpp XercesDOMWrapperParsedSource.hpp

dbertoni2002/12/02 16:47:06 Modified:c/src/XalanTransformer XercesDOMWrapperParsedSource.cpp XercesDOMWrapperParsedSource.hpp Log: Fixed typedefs. Revision ChangesPath 1.8 +5 -5 xml-xalan/c/src/XalanTransformer/XercesDOMWrapperParsedSou

Re: The organization of xml.apache.org

Ted Leung wrote: 4. Some option that hasn't been thought of yet. Based initially on the reorg discussions, and then a number of F2F discussions at ApacheCon, I am planning on proposing something radical within Jakarta, but it applies equally well here. I provided some foreshadowing for this

cvs commit: xml-xalan/c/src/Include PlatformDefinitions.hpp

dbertoni2002/12/02 16:28:09 Modified:c/src/Include PlatformDefinitions.hpp Log: New macro. Revision ChangesPath 1.19 +5 -0 xml-xalan/c/src/Include/PlatformDefinitions.hpp Index: PlatformDefinitions.hpp =

cvs commit: xml-xalan/c/src/XSLT StylesheetExecutionContextDefault.cpp

dbertoni2002/12/02 16:27:53 Modified:c/src/XSLT StylesheetExecutionContextDefault.cpp Log: Fixed problem with non-namespace aware compilers. Revision ChangesPath 1.106 +1 -1 xml-xalan/c/src/XSLT/StylesheetExecutionContextDefault.cpp Index: StylesheetExecutio

cvs commit: xml-xalan/c/src/XSLT XalanTemplate.cpp

dbertoni2002/12/02 16:23:10 Modified:c/src/XSLT XalanTemplate.cpp Log: Fixed macros. Revision ChangesPath 1.46 +3 -3 xml-xalan/c/src/XSLT/XalanTemplate.cpp Index: XalanTemplate.cpp === RCS

cvs commit: xml-xalan/c/src/XercesParserLiaison XercesDocumentBridge.cpp

dbertoni2002/12/02 15:51:22 Modified:c/src/XercesParserLiaison XercesDocumentBridge.cpp Log: Fixed cast. Revision ChangesPath 1.29 +1 -1 xml-xalan/c/src/XercesParserLiaison/XercesDocumentBridge.cpp Index: XercesDocumentBridge.cpp =

Re: SGI STL

I don't think it will work. I tried 3 years ago with no luck. However, you can use STLport, which is a much better choice if you need to use a different STL. Dave

DO NOT REPLY [Bug 15006] - copy21 testcases fails in trax.dom flavor

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 15006] - copy21 testcases fails in trax.dom flavor

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 15006] New: - copy21 testcases fails in trax.dom flavor

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-xalan/test test.properties

dmarston2002/12/02 13:19:08 Modified:test test.properties Log: New idkey31 has correct result, if anyone cares. Revision ChangesPath 1.85 +2 -1 xml-xalan/test/test.properties Index: test.properties =

cvs commit: xml-xalan/test/tests/conf-gold/idkey idkey51.out idkey49.out idkey31.out

dmarston2002/12/02 13:17:11 Modified:test/tests/conf-gold/idkey idkey51.out idkey49.out idkey31.out Log: Convert to processor-independent form. String compares happen internally. Revision ChangesPath 1.2 +1 -3 xml-xalan/test/tests/conf

cvs commit: xml-xalan/test/tests/conf/idkey idkey51.xsl idkey31.xsl idkey49.xml idkey49.xsl idkey49a.xml idkey49c.xml idkey51.xml idkey31.xml

dmarston2002/12/02 13:16:22 Modified:test/tests/conf/idkey idkey51.xsl idkey31.xsl idkey49.xml idkey49.xsl idkey49a.xml idkey49c.xml idkey51.xml idkey31.xml Log: Convert to processor-independent form. String compares happen internally

The organization of xml.apache.org

Hello all,   At ApacheCon I had a number of great discussions with people from all over the ASF.  One of the many topics of discussion was around the organization of the ASF.  I'm going to try to summarize the organization discussion below.   It seems that there are 2 major issues:   1. The

Re: [VOTE] conf test restructuring

Shane Curcuru wrote: >While I hate to invent partial solutions that will need re-work later, >I also want to make sure we are focusing on the same goal. Ensuring >that the xml-xalan project is of high quality and is very standards >compliant is a goal I think we all agree on. If we're *also*

DO NOT REPLY [Bug 14965] - Empty comments causes ArrayIndexOutOfBoundsException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [VOTE] conf test restructuring

Re: Dave's comments and multi-dimensionality: Given that either 1) it's only a small number of tests, or 2) it will become very multi-dimensional with different processors, options, languages, etc. etc.; do we want to either: -- agree on basic principles to get the job done for existing committer

Re: [VOTE] conf test restructuring

Dave wrote: The problem is that the naming scheme will become multi-dimensional. We want to accommodate not just multiple processors, but various options about encoding and serializing. A single processor may be able to produce numbered or named entities, possibly with a different policy for diffe

DO NOT REPLY [Bug 14999] - Every namespace node must have different generate-id() value

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 14999] - Every namespace node must have different generate-id() value

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [VOTE] conf test restructuring

> >3) Possibly for those cases that can't be handled by (2), use a file > >naming convention, like axes01-xalanc.xml. >BTW, this should have been axes01-xalanc.out. Same as Shane's proposal. The problem is that the naming scheme will become multi-dimensional. We want to accommodate not just

DO NOT REPLY [Bug 14999] New: - Every namespace node must have different generate-id() value

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [VOTE] conf test restructuring

> >3) Possibly for those cases that can't be handled by (2), use a file > >naming convention, like axes01-xalanc.xml. BTW, this should have been axes01-xalanc.out. Same as Shane's proposal. -scott David Marston/Cambridge/IBM <[EMAIL PROTECTED]> wrote on 12/02/2002 08:42:33 AM: > > > > > Sc

DO NOT REPLY [Bug 14778] - "Memory Leak" in XalanJ2

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: conf test restructuring

[I tried to send this on Thursday, and it never got to the mail server. Apologies if a duplicate shows up eventually.] Henry Zongaro wrote: >However, within the acceptance cluster, aren't we likely to run into >a situation in which the way a processor handles a particular feature >changes from

Re: [VOTE] conf test restructuring

Scott Boag writes: >It's not totally clear if these would be a complete reproduction of >the so-called gold files, or just the deltas (maybe I didn't read >carefully enough... from paragraph 2 I think you mean just the >deltas). Since "deltas" implies differences over time in this context, I d

Re: conf test restructuring

>However, within the acceptance cluster, aren't we likely to run into >a situation in which the way a processor handles a particular feature >changes from one release to another? We could. Some of our past behavior might not be the result of a complete and consistent design rationale, and thus

Re: [VOTE] conf test restructuring

[I tried to send this on Thursday, and it never got to the mail server. Apologies if a duplicate shows up eventually.] Scott Boag writes: >It's not totally clear if these would be a complete reproduction of >the so-called gold files, or just the deltas (maybe I didn't read >carefully enough...

Re: [VOTE] conf test restructuring

Hi Shane, I like the idea of using a file-naming convention to separate different processor's output. I was thinking of a slight variation to your proposal. What if we arbitrarily picked the output of one of the processors and gave it just the extension .out, and then any processor's which differ

cvs commit: xml-xalan/java/src/org/apache/xalan/xsltc/compiler/codemodel CmAssignmentExpr.java CmBinaryExpr.java CmBlockStmt.java CmBooleanExpr.java CmBooleanType.java CmBreakStmt.java CmCastExpr.java CmCharExpr.java CmCharType.java CmClassDecl.java CmClassType.java CmCompilationUnit.java CmConditionalExpr.java CmContinueStmt.java CmDeclaration.java CmDoWhileStmt.java CmDoubleExpr.java CmDoubleType.java CmEmptyExpr.java CmEmptyStmt.java CmExprStmt.java CmExpression.java CmForStmt.java CmIfStmt.java CmImportDecl.java CmInstanceOfExpr.java CmIntegerExpr.java CmIntegerType.java CmLabeledStmt.java CmMethodCallExpr.java CmMethodDecl.java CmModifier.java CmNameExpr.java CmNewArrayExpr.java CmNewInstanceExpr.java CmNode.java CmNullExpr.java CmOperator.java CmPackageDecl.java CmParameterDecl.java CmPostUnaryExpr.java CmPreUnaryExpr.java CmReturnStmt.java CmStatement.java CmStringExpr.java CmStringType.java CmSynchronizedStmt.java CmThrowStmt.java CmTryCatchStmt.java CmType.java CmVariableDecl.java CmVariableRefExpr.java CmVariableStmt.java CmVisitor.java CmWhileStmt.java JavaCmVisitor.java Test.java

santiagopg2002/12/02 08:49:44 Added: java/src/org/apache/xalan/xsltc/compiler/codemodel Tag: xslt20 CmAssignmentExpr.java CmBinaryExpr.java CmBlockStmt.java CmBooleanExpr.java CmBooleanType.java CmBreakStmt.java Cm

cvs commit: xml-xalan/java/src/org/apache/xalan/xsltc/compiler/codemodel - New directory

santiagopg2002/12/02 08:47:51 xml-xalan/java/src/org/apache/xalan/xsltc/compiler/codemodel - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] conf test restructuring

First, thanks to Gordon and everyone else who's taking an interest in our testing work! One of Xalan's strengths has been our strict compliance to XSLT and other specs, helped by our public testing suite. My votes now that I've recovered from my turkey holiday: -1 to using tags in CVS. This is

DO NOT REPLY [Bug 14778] - "Memory Leak" in XalanJ2

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

SGI STL

Dear list, I wonder whether the XALAN can be compiled with the SGI STL(v 3.2)? On Microsoft Platform, I was compiling the samples, and everything went fine until I added the path og the SGI STL headers to the include path. Has anyone tried this, is it doable? Thank y

DO NOT REPLY [Bug 14984] - XSLTC compiltation error : Branch target offset too large for short

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Bug in TransformerIdentityImpl?

Hi, I'm just trying to find some problems in the latest Java version of Xalan: when the TransformerIdentityImpl is used, output properties are ignored when they are set by setOutputProperties(). We are heavily beaten by this problem in Cocoon. I think this lies in the code of the setOutputPropert