On Nov 27, 2007, at 3:26 PM, Dan Janowski wrote:
I see the merit in this kind of approach but it cannot conflict with
the libxml work flow. I.e.:
instead of XML::Document.parse(xml) => Document
XML::Parser.parse(xml) => Document
If you want to update the patch for the current code base, I am
I see the merit in this kind of approach but it cannot conflict with
the libxml work flow. I.e.:
instead of XML::Document.parse(xml) => Document
XML::Parser.parse(xml) => Document
If you want to update the patch for the current code base, I am
willing to apply and eval it.
Dan
On Nov 27, 2
On Nov 27, 2007, at 3:08 PM, Dan Janowski wrote:
> The handling of encoding is not coherent in the extension, as my
> last patch on the topic illustrates. While I have no doubt that
> there are issues to resolve, in this particular instance I do not
> get the result you do.
>
> Anyone wanti
The handling of encoding is not coherent in the extension, as my last
patch on the topic illustrates. While I have no doubt that there are
issues to resolve, in this particular instance I do not get the
result you do.
Anyone wanting to look at the way encoding is handled is welcome to
mak
I see patch #7758 hasn't been worked on or updated since submission
(long ago):
http://rubyforge.org/tracker/index.php?func=detail&aid=7758&group_id=494&atid=1973
This seems like a great idea and the new parse method solves
eliminates the need for part of the patch I submitted (#15807). Is
hello,
I get segmentation fault when add the cloned/copied node to other
node,
script to problem reproduction below,
segv appears when use clone and copy methods,
what's interesting, with clone segv is thrown in div1.child_add(c)
line (see script)
but when use copy I get it in printf root stateme
There is a serious inconsistency when "round tripping" XML containing
UTF-8 characters. If you output the document to a string after parsing
you get the UTF-8 back out, if you just grab a node and convert to a
string you get UTF-8 characters substituted with entities:
utf8test.rb:
require '
On Nov 27, 2007, at 11:05 AM, Dan Janowski wrote:
> The method mapping was transposed and is fixed in svn #220
>
> See if that works now.
It's working great now. Thanks!
--Paul
> On Nov 27, 2007, at 10:17, Paul Dlug wrote:
>
>>
>> On Nov 26, 2007, at 9:34 PM, Dan Janowski wrote:
>>
>>> Hi,
>>
The method mapping was transposed and is fixed in svn #220
See if that works now.
Dan
On Nov 27, 2007, at 10:17, Paul Dlug wrote:
>
> On Nov 26, 2007, at 9:34 PM, Dan Janowski wrote:
>
>> Hi,
>>
>> You are at least half correct. xmlSubstituteEntitiesDefaultValue has
>> nothing to do with DTD. H
Patch applied, svn #219. Note that 'p' of the .find result will not
result in the xml segment that it used to in 0.3.8. The .find now
returns an XPath::Object type and it has no to_s method defined. You
can get the same effect by using .to_a on XPath::Object.
I had not looked closely enough
I think I have a related bug that your patch doesn't fix. If I have a
document with a DTD declaration specifying a namespace and an
identical document without it the XPath expression finds the node in
the document w/o DTD but not with the DTD. The attached test case
illustrates the problem,
On Nov 26, 2007, at 9:34 PM, Dan Janowski wrote:
> Hi,
>
> You are at least half correct. xmlSubstituteEntitiesDefaultValue has
> nothing to do with DTD. However, while the _get method you have
> illustrated here makes reference to the wrong variable, the _set
> method does not suffer the same pr
On Nov 27, 2007, at 6:42 AM, Dan Janowski wrote:
> Last night I could not see what could BE and LE stand for?! Well, of
> course, Big Endian and Little Endian. When there is no lead in to
> indicate, the encoding can specify.
That's what the byte order mark is for. When we were battling unicode
Last night I could not see what could BE and LE stand for?! Well, of
course, Big Endian and Little Endian. When there is no lead in to
indicate, the encoding can specify.
Dan
On Nov 27, 2007, at 05:08, Tim Perrett wrote:
>> A few other notes about UTF-16 specifically; UTF-16 will result in
So, this should be the patch.
Index: ext/xml/ruby_xml_xpath.c
===
--- ext/xml/ruby_xml_xpath.c(revision 218)
+++ ext/xml/ruby_xml_xpath.c(working copy)
@@ -76,9 +76,9 @@
}
else {
// tuples of prefix/uri
-
Interesting stuff. Just changed back to utf-16, and using doc.dump I
see the byte order mark and the rest of the xml - result :)
Cheers guys
Tim
On 27 Nov 2007, at 04:39, Dan Janowski wrote:
> I have modified Document#to_s to permit the inclusion of a second
> encoding argument (didn't know t
16 matches
Mail list logo
