Re: [ANN] Ruby 1.8.7-p248 released.
Joel VanderWerf
> * ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p248.tar.gz
Does not build in cygwin 1.7. (This is the first time I've tried to
build any 1.8.7 in any cygwin, so I can't say if the problem is new.)
The most recent releases of 1.8.6 and 1.9.1 build ok in cygwin 1.7.
Here is the error with ruby-1.8.7-p248 under cygwin 1.7 (on windows 7
x86-64):
$ gcc -g -O2 -DRUBY_EXPORT -I. -I. -c eval.c
eval.c:211: error: conflicting types for '_longjmp'
/usr/include/machine/setjmp.h:335: error: previous declaration of
'_longjmp' was here
eval.c:211: error: conflicting types for '_longjmp'
/usr/include/machine/setjmp.h:335: error: previous declaration of
'_longjmp' was here
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with:
/managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure --verbose
--program-suffix=-3 --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs
--without-x --enable-libgcj --disable-java-awt --with-system-zlib
--enable-interpreter --disable-libgcj-debug --enable-threads=posix
--enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Seems like it might be related to:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/23340
http://redmine.ruby-lang.org/issues/show/1388
Thanks, and happy holidays to you too!
Ed Howland
Thanks for the update. This is kind of a sniggly little bug, but can
really smack you in the face if you are doing any XML parsing and
working with outside vendors, like with REST web services.
The REXML library has a bug parsing the xml declaration standalone
attribute. It requires a space between the '=' and the value of the
attribute.
<?xml version="1.0 standalone= "no" ?>
<?xml version="1.0 standalone="no" ?>
The latter is valid XML as well as the former, but does not parse
correctly in REXML.
It is documented in Trac Ticket #152 for the REXML Trac Wiki. This
has been open for more than 20 months. I saw it on another ticket, but
at the moment I can't find that one.
I submitted a patch and a comment with some RSpec tests to demonstrate
the issue. It exists in
ruby-1.8.7-p174, ruby-1.8.7-p248, ruby-1.9.1-p376 : ruby 1.9.1p376
and ruby 1.9.1p243.
In my case, i was dealing with the U.S. government and the
requirements were strict XML. It is any easy bug to work around/patch,
once you find it, but annoying, nonetheless.
Any chance, this small fix can get incorporated into another round of
bug fixes? 20 months is a long time to leave a defect like this open
w/o even assigning it.
Thanks,
Ed
Happy Holidays to you too!
--
Ed Howland
http://greenprogrammer.wordpress.com
http://twitter.com/ed_howland
Ed Howland
I hate to be nit picky about this, but can the
REXML::docu,emt$stand_alone? predicate return true for "yes" and false
for "no". At the moment it returns the string value of the xml
declaation attribute. If the intent is to report the value as a string
as the documentation suggests, then the method should just be named
'standalone' or 'stand_alone' if you wish. More like version and
encoding. Appending the '?' makes it look like a predicate. This fails
to work in unit testing and cases like RSpec.
doc = REXML::Document.new('<?xml version="1.0" standalone= "no" ?><root />')
doc.should_not be_stand_alone
produces
1)
'REXML::Document should not be stand_alone' FAILED
expected stand_alone? to return false, got "no"
Note, a DSL custom matcher is easily written. (I have changed the
predicate to standalone? to avoid confusion, and because IMO, it shoud
be named like the attribute it self, and who wants to look at the
documentation to have to figure out why it isn't just named like the
other attributes.)
pec::Matchers.define :be_standalone do |expected|
match do |actual|
actual.stand_alone? == 'yes'
end
failure_message_for_should do |actual|
"expected that #{actual}.stand_alone? should == 'yes'"
end
failure_message_for_should_not do |actual|
"expected that #{actual}.stand_alone? should == 'no'"
end
description do
"be a standalone document"
end
end
Merry Christmas!
Ed
[1] XML Spec:standalone http://www.w3.org/TR/REC-xml/#sec-rmd
Aaron Patterson
> Hi,
>
> Thanks for the update. This is kind of a sniggly little bug, but can
> really smack you in the face if you are doing any XML parsing and
> working with outside vendors, like with REST web services.
>
> The REXML library has a bug parsing the xml declaration standalone
> attribute. It requires a space between the '=' and the value of the
> attribute.
>
> <?xml version="1.0 standalone= "no" ?>
>
> <?xml version="1.0 standalone="no" ?>
>
> The latter is valid XML as well as the former, but does not parse
> correctly in REXML.
>
> It is documented in Trac Ticket #152 for the REXML Trac Wiki. This
> has been open for more than 20 months. I saw it on another ticket, but
> at the moment I can't find that one.
Can you send a link? I didn't see this ticket in redmine. I'll take a
look if there is a link. Thanks!
--
Aaron Patterson
http://tenderlovemaking.com/
Ed Howland
http://trac.germane-software.com/rexml/ticket/152
I am new to this, so if it would work faster to use Redmine to report
this, then I am willing to do so. REXML seemed to be being tracked on
the Trac wiki at germane-software.com. Searching for REXML on Redmine
[1] yields 0 results, so that led me to believe issue tracking for
that standard library was at the above URL.
Also, this issue affects both release branches: 1.9 and 1.8. If I do
post an issue in Redmine, should I post it multiple times for each
branch?
Please inform.
Thanks
Ed
[1] REXML search on Redmine: http://redmine.ruby-lang.org/search?q=rexml
--
Aaron Patterson
> Sorry Aaron, here is the link:
> http://trac.germane-software.com/rexml/ticket/152
>
> I am new to this, so if it would work faster to use Redmine to report
> this, then I am willing to do so. REXML seemed to be being tracked on
> the Trac wiki at germane-software.com. Searching for REXML on Redmine
> [1] yields 0 results, so that led me to believe issue tracking for
> that standard library was at the above URL.
I think using redmine will result in faster response. Currently, rexml
is considered unmaintained by ruby core. Since no one is an official
maintainer, *bugs* filed on redmine will likely get fixed. However,
feature requests like changing the stand_alone? method may not.
> Also, this issue affects both release branches: 1.9 and 1.8. If I do
> post an issue in Redmine, should I post it multiple times for each
> branch?
No. Just file the ticket for 1.9. I'm happy to commit bug fix patches
that come with tests. I only have permission to commit to trunk though,
so you'll have to lobby the release managers to get it backported.
Hope that helps!
Also, have you considered using something like nokogiri?
Ed Howland
On Sun, Dec 27, 2009 at 5:57 PM, Aaron Patterson >
> I think using redmine will result in faster response. Currently, rexml
> is considered unmaintained by ruby core. Since no one is an official
> maintainer, *bugs* filed on redmine will likely get fixed. However,
> feature requests like changing the stand_alone? method may not.
>
I understand. It is too bad that the maintenance has atrophied for
REXML. It is probably the first XML lib new users to Ruby encounter
(in the Pickaxe book, for example). Pity it can't be updated.
My patch fixes a definate (albeit minor) bug. I'm happy to let the
name of the stand_alone? method stand for backward compatiblity
reasons. As I mentioned or meant to mention, I grabbed the fix from
another ticket at the Trac Wiki for REXML, but I can't find that
ticket now, so I used #152 which was the same issue. The patch is one
line of code (one character actually).
> No. Just file the ticket for 1.9. I'm happy to commit bug fix patches
> that come with tests. I only have permission to commit to trunk though,
> so you'll have to lobby the release managers to get it backported.
>
I'll be glad to submit it to 1.9. Will RSpec tests do or should I
convert them to Test::Unit? (This being my first time on Ruby
Redmine), Should the test demonstrate the bug, then after the patch
runs with only success?
Thanks,
> Hope that helps!
It certainly does.
>
> Also, have you considered using something like nokogiri?
Nokogiri is the dude! I think the XML parsing is pretty smooth,
although I haven't had much of a chance to play with it much. This
problem qas based on an issue that came up when I wrote a custom
matcher for RSpec that matches XML strings. It defines a function
called 'be_functionally_eql' as in:
my_xml.should be_functionally_eql(expected_xml)
.. where the two XML's can have varying degrees of 'whiteness'. It
then uses RSpec's difference output to highlight the exact node(s)
that are different. Of course, it immediately failed on the first
line because of the bug in the standalone attribute.
Cheers and Happy New Year!
Ed
Aaron Patterson
> Thanks for the response Aaron.
>
> On Sun, Dec 27, 2009 at 5:57 PM, Aaron Patterson >
> > I think using redmine will result in faster response. �Currently, rexml
> > is considered unmaintained by ruby core. �Since no one is an official
> > maintainer, *bugs* filed on redmine will likely get fixed. �However,
> > feature requests like changing the stand_alone? method may not.
> >
>
> I understand. It is too bad that the maintenance has atrophied for
> REXML. It is probably the first XML lib new users to Ruby encounter
> (in the Pickaxe book, for example). Pity it can't be updated.
>
> My patch fixes a definate (albeit minor) bug. I'm happy to let the
> name of the stand_alone? method stand for backward compatiblity
> reasons. As I mentioned or meant to mention, I grabbed the fix from
> another ticket at the Trac Wiki for REXML, but I can't find that
> ticket now, so I used #152 which was the same issue. The patch is one
> line of code (one character actually).
>
>
> > No. �Just file the ticket for 1.9. �I'm happy to commit bug fix patches
> > that come with tests. �I only have permission to commit to trunk though,
> > so you'll have to lobby the release managers to get it backported.
> >
>
> I'll be glad to submit it to 1.9. Will RSpec tests do or should I
> convert them to Test::Unit? (This being my first time on Ruby
> Redmine), Should the test demonstrate the bug, then after the patch
> runs with only success?
The tests in Ruby use minitest, so converting to Test::Unit is most
helpful. But if you just submit code that reproduces the bug along with
your patch that fixes the bug, I'll make sure a test gets added. :-)