g list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
--
Sean Chittenden
s...@chittenden.org
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
, actually. Using both
of the methods you suggest require creating a DOM tree. -sc
--
Sean Chittenden
s...@chittenden.org
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
laris, and many other non-linux systems don't use pkg-config (not to
say it can't, but isn't). ruby-libxml should use xml2-config until a
sufficiently well adopted BSDL version of pkg-config is adopted and
used by most posix systems.
-sc
--
Sean Chitt
to the code too, very big win for all! -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
Not applicable to libxml, but in case anyone missed it:
http://www.ruby-lang.org/en/news/2008/08/23/dos-vulnerability-in-rexml/
-sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org
ne of those things
that people tend to like to want to do with XML libraries vs. nested
function calls w/ string concatenation. -sc
- --
Sean Chittenden
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAkixio8ACgkQTrydwWwuXha9vQCeIYz+gNj6VyPNHEIkNFnhzbUW
hfQAn0DfHUfiCiDcb
lt;<
XML::Node.new('baz')).parent!
where "parent!" recursively searches for the parent node that has a
null parent (??). I'm guessing the most common situation is going to
be finding a node in a document, then modifying it.
Preserving an easy to use syntax
27;baz')
should produce the XML:
XML::Node<<(arg) should return the argument being appended *ONLY IF*
the argument is an XML::Node, else it should return the xmlNode that
had its content modified (e.g. XML::Attributes and Strings).
That should solve this problem.
t;' ?? I think chaining objects together is a common practice and
more convenient than doing one assignment per line, so I'm biased
towards the behavior of the former (not the latter).
Arguments/discussion welcome. -sc
- --
Sean Chittenden
[EMAIL PROTECTED]
-BEGIN PGP
nguage on the planet, it is VERY difficult to figure out
for the first time! Ugh. -sc
- --
Sean Chittenden
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAkitx6IACgkQTrydwWwuXhbJ/ACeLd18kCsGW2aPx8JXVVKLoTn2
IIoAoI4rTXZ5jYtc
x27;
I didn't spend a lot of time on the operators when writing this, but I
feel pretty strongly that there should be such a distinction and it
should behave differently based on the argument's data type (not that
I'm actively using the lib atm, but...). That a useful suggestio
t oh well. Ruby ain't perfect and this, to me at least,
is perfect justification for doing what is right vs. what is
"standard." -sc
>> class F
>> def a=(b)
>> @z = b + 1
>> return @z
>> end
>> def a
>> return @z
>&
# @[EMAIL PROTECTED] @[EMAIL PROTECTED] @[EMAIL PROTECTED]
@[EMAIL PROTECTED] @[EMAIL PROTECTED] @#$#@@!!!
Ignore the "Ruby standard." -sc
- --
Sean Chittenden
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAkitvkcACgkQTrydwWwuXhaEhACdHk8MlSI+hLfji+tUVm1DMGGo
ZAgAniAAKqXGozIAyATQ
http://antoniocangiano.com/2007/02/10/top-10-ruby-on-rails-performance-tips/
One could argue, however, that using GC.start is practical if done in
tight loops. What exactly are you trying to do with your fragments?
Maybe there's a more efficient way of getting the result you're
in
7500-17840+split-mode-vertical
XPathObjects should have a custom mark function that marks their
dependent XML Document object. XPathObjects need to have that
reference in their structure. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-dev
exercise the demons or are we forced to suck
up and swallow a 400% increase in package size because of the Win32? -
sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
If you want to be considerate of the binary size, here's a q: what
compresses to near 100% efficiency:
a
Or:
Abcfefghijklnghajabhffgcggcffbhh
? -sc
--
Sean Chittenden
On Jul 17, 2008, at 6:56 PM, Charlie Savage <[EMAIL PROTECTED]> wrote:
Sean Chittenden wr
ver will. Thus
by default, I think we can get away with it. :)
No guts, no glory. Just do it. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
and think:
require 'libxml'
Should "do the right thing" and guess as best it can (ObjectSpace,
etc), while
require 'xml'
will be explicit. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxm
Do we want to distribute the benchmark scripts, or are they intended
only for admin uses?
Not sure what the intention was, but let'em go out. What's the worst
that could happen? People figure out that REXML is slow? -sc
--
Sean Chittenden
[EMAIL
n batch from a
simple script, not inside of an embedded app that does:
class Foo
include LibXML
...
end
Not saying I haven't done that a few times in a few web apps w/ other
modules, but it's less frequent for XML, IMHO. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
_
#x27;s another trick that we could use:
>> module LibXML; end
=> nil
>> b = false
=> false
>> ObjectSpace.each_object(Module) {|m| if m.name == 'LibXML'; b =
true; break; end }
=> nil
>> b
=> true
Since it's done behind a require, it shoul
it should be
LibXML::XML::Document.
Easy to fix of course, but it means everyone has to change their
custom code. Sigh.
That's why I was suggesting the XML::* by default and ability to wrap
things if required/desired. :) -sc
--
Sean Chittenden
[
7;xml'
I think LibXML::XML::* is rather redundant and a waste of keystrokes,
however, and that it should be LibXML::* and XML::*. $0.02. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
e 'ilbxml/app' # LibXML::XML::*
Where 'libxml.rb' does the include, and libxml/app ('gem', or
whatever), does not. ??
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
hat in 99%
of the cases, it should. The remaining 1% of the time, they can set
this global variable and go. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
'] bit (security), but the
rest should nab most corner cases for users. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
(ENV['RUBY_LIBXML_SHORT_PATH'].nil? ? true :
ENV['RUBY_LIBXML_SHORT_PATH'].downcase])
include LibXML
end
I think a get out of jail free card would be nice and having it
conditionalized behind an environment variable is convenient for folks
if they're in a jam. -sc
Is this code in extconf.wrong?
if CFLAGS.index(CONFIG['CCDLFLAGS'])
$CFLAGS = CFLAGS
else
$CFLAGS = CFLAGS + ' ' + CONFIG['CCDLFLAGS']
end
Isn't the if statement reversed?
Yup, it is. Is this related to that FreeBSD bug? -sc
p-toeing
around 'what if' is an endless rabbit hole. We'll adapt and find a
solution if there is a problem at some point in the future. Cool?
-sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
Note, a possible alternative is to use LibXML::XML::
I think libxml.rb could/should include LibXML if the XML namespace is
not included. Let users unfoobar their own env however they see fit
to have two conflicting XML modules. -sc
--
Sean Chittenden
[EMAIL PROTECTED
Separate scripts are more intuitive than rake tasks?
I agree with Aaron in terms of usability... though I think setup.rb
should be implemented in terms of rake tasks since setup.rb < rake
functionality. Granted that's not what exists in code -sc
--
Sean Chittenden
[EMAIL P
loader
Started
..
Finished in 0.28 seconds.
130 tests, 720 assertions, 0 failures, 0 errors
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-deve
task with --trace)
Exit 1
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
_well_formed.rb:1:in `require': no such
file to load -- libxml (LoadError)
Wild. Alright. It works for me out of the box. Is this trunk or
before the libxml.rb patch? -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel
updating
lib/libxml.rb simply because it's included by everything and I'm still
not up to speed post-gem'ification re: path/packaging.
I'll commit it for now, but I'm not entirely sure of its complete
correctness (unit tests work for me). If this breaks anyth
it'd belong in ruby if
there's a bug.
Said differently, let sleeping dogs lie and don't waste effort unless
effort needs to be expended to fix something... patches welcome. *grin*
How's that? -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
Loaded suite test
Started
.
EXPECTING: TWO ERRORS:
F
Finished in 0.874862 seconds.
1) Failure:
test_error_handler(TextParser) [/Users/sean/src/ruby-libxml/trunk/test/
tc_xml_parser.rb:198]:
expected but was
<#tc_xml_dtd.rb:59>>.
130 tests, 716 assertions, 1 failures, 0
did the File.join(...) for each open call.
Anyway, let me know if trunk works for the tests for you now. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
know why that would be... maybe on the other machine you had
your limits set higher and the GC always kicked in. The test code
uses sh -c `ulimit -n` to make sure that things run out of FDs. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
lib
#x27;m not entirely opposed to the idea... but am curious for some
example functions. :) -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
Comment By: Charlie Savage (cfis)
Date: 2008-07-10 16:17
Message:
Benjamin,
Can you try with the latest gem and see if the problem is still
occurring?
I think I committed the fix to this earlier today. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
li
uot;test.xml"
logic 0
8700
8800
Too many open filesToo many open filesI/O warning : failed to load
external entity "test.xml"
logic 0
8900
9000
9100
Too many open filesToo many open filesI/O warning : failed to load
external entity "test.xml"
logic 0
9200
9300
Too ma
) hook. *pukes* -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
pecial XML node that exists between elements. <:~/
Not ideal, and not something I agree with, but...
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
e and throw away an object needlessly
in most comparison cases. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
and that's something
that's done at make/extconf.rb time not run time. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
bility now, get it over with. There's renewed
interest and development happening at the moment, so now is absolutely
the right time. Waiting will only make things more painful. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
n exception was
the hangup and why I never committed it, iirc (easy enough to recreate
using ruby though). -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
I vote that libxml copies REXML's interface:
http://www.germane-software.com/software/rexml/doc/classes/REXML/Attributes.html
Thoughts?
Go for it - attribute support sucked hard. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
l vanish upon import. <:~] -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
?
Is there any reason to nuke 'em? -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
mp;group_id=5&atid=104
-sc
*does happy dance*
http://www.youtube.com/watch?v=HZzhmJxJg5Q
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
As you might have guessed by the recent email traffic, I've dived
into the libxml (and libxslt) ruby bindings since I need them MapBuzz.
Charlie/MapBuzz FTW! Economic incentive == progress. Glad to hear
you've been able to knock out these bugs. :~]
-sc
--
Sean Chitten
ilable for it on rubyforge
(*sends an email asking if/when*). -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
, please make a diff and post them! I
could really use it!
Do you just want to be added as a committer? I don't actually have
the rights to do that, but I'm sure Dan or trans could do it.
Off list, send me your sf.net login information and I'll add you to
the ranks.
oblem
arises
more because of the fact that we allow the C objects to be shared by
multiple ruby objects than anything else.
The easiest way forward is to copy memory/nodes like it's going out of
style and let the GC pick up the pieces. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
essentially non-
overlapping skills and rarer still, people who have cycles to spend on
the thankless job of library development. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/
hat
> I don't know... :)
Come to think of it, neither do I! ... If my feeble memory serves me
less well than it used it, it's because I wrote ruby_xml_parser.c
first and I used its namespace to stash those constants while I was
doing the API/constants mappings. :~] -sc
--
Sean Ch
gt; ruby_xml_parser.c:951
> 951 if (!NIL_P(((rx_io_data *)rxp->data)->io))
> (gdb) bt
> #0 0xb7c81813 in ruby_xml_parser_mark (rxp=0x809d980) at
> ruby_xml_parser.c:951
> #1 0xb7eed5a5 in ?? () from /usr/lib/libruby1.8.so.1.8
> #2 0x0809d980 in ?? ()
> #3 0
s mtrace which does pretty much the
> same thing. See man mtrace / info mtrace for details.
That assumes you want to be on a platform that uses glibc. :) -sc
--
Sean Chittenden
[EMAIL PROTECTED]
http://sean.chittenden.org/
___
libxml-devel mail
_time} ? Guess which gets
squeezed first. The economics of open source suck on the development
side of things. :-/ -sc
--
Sean Chittenden
[EMAIL PROTECTED]
http://sean.chittenden.org/
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://ruby
the GC is coming along,
invalidating portions of the XML document structure, and leaves a
dangling pointer. I don't know if that's what Dan fixed in the latest
rev or not, but that's the only design thing that I'm aware of that
_needs_ to get addressed. Is this stil
ce yet as I'm still testing it
out as a means of development right now, but... The concept being,
allocate haphazardly (fight the urge to be hyper meticulous), and
reconcile free(3)'ing memory later during regression testing. So far
it's saved me a ton of time and I&#x
xslt became a self
sufficient XML parser without dependencies on libxml (to the point
that I'll call it an impossibility). -sc
--
Sean Chittenden
[EMAIL PROTECTED]
http://sean.chittenden.org/
___
libxml-devel mailing list
libxml-devel@rubyforge.o
ssible files to load (libxml and libxsl).
Naw, you don't it. Way back when, that was me being anal and trying
to emulate/improve some perlisms. I'd break out the build process and
keep them as two separate packages, but 'require "libxml"' or 'require
"libxs
or it? Or can we combine the two into the single dir? I'm looking at
> doing the later, but I'm not sure how it should effect extconf.rb, and
> makes me wonder if it's even possible to have a single ext dir.
You want/need two different directories since not all systems that
ha
Nope! :) libxsl is a much simpler animal compared to libxml. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
On Sep 12, 2007, at 3:08 PM, Stephanie Collett wrote:
> Hi All,
>
> I have been using libxml to consume xml web service responses for a
> few months and it has been gre
or wish me luck.
Warnings/suggestions posted above, but your plan is as good of one as
exists - good luck! -sc
--
Sean Chittenden
[EMAIL PROTECTED]
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
> For SWIG I implemented support for mapping between C pointers and
> Ruby objects by using a Hash Table (ruby's built in one,
> st_table). That allows you to enforce a one-to-one Ruby to C
> object mapping. Do we want to do something like that here?
It doesn't exist now and I'm inclined
> My patches (to which I see you have already been pointed) are quite
> likely to help with this. They're only a band aid really though - what
> is really needed is a ground up review/redesign of the way the two
> object models are tied together as the current scheme basically
> doesn't work at all
>>> Ok, some questions:
>>>
>>> 1. Are we going to change to a new mailing list then? If so,
>>> maybe you
>>> can send an email to this list Trans?
>>
>> If possible, it would be nice to continue to use this list as it will
>> help to maintain some continuity and maybe catch some of the
>> fol
remove it
> (doesn't extconf supply it anyway if ruby was built with it)?
Optional CC flag. If the test passes, append the -Wall, if it fails,
just continue silently. Just a thought. -sc
--
Sean Chittenden
___
libxml-devel mailing list
libxml-d
entified (or as time permits), the ruby library could be
converted to C. The `require 'libxml'` line should include the .so,
but if the .so includes additional ruby files, who cares... this'll
provide an easy way for us to prototype new APIs before they get
integrated into t
sforming the assembled XML doc into HTML via XSLT.
Think forum software and the suck that is phpBB. -sc
--
Sean Chittenden
pgpWFFkyMDcdi.pgp
Description: PGP signature
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
> Is there a preferred way (for future reference) on how you'd like to
> receive api suggestions or patches? Inline in email, patches in
> code, pdfs, openoffice documents, etc..
I can't speak for Ross, but, I'm a fan of plain text emails with
bullets or diff -u'e
.. Ross is right, however, in that
Node::Set is important and shouldn't be nixed, even though most of the
folk out there won't use it once an array interface pops up. Ease of
use and REXML compatibility should be a focus, however, and eye'ing
their API and shimmying
l
> don't seem to have permissions to do that...
*blinks* You're an admin on rubyforge... not sure how that's
possible. Let me know if you're still having problems. -sc
--
Sean Chittenden
___
libxml-devel mailing list
libx
;)
> >
> > plz to be committing your code two minutes ago
>
> Phew, that's better :) Module is 'libxslt'. It's compiling and
> testing clean here, you can just run 'rake' to compile and test,
> hopefully...
Will test tonight when I get home. -sc
--
Sean Chittenden
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
ost any data for, ooh, days and I'm starting to get jittery having
> uncommitted stuff ;)
plz to be committing your code two minutes ago
--
Sean Chittenden
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
?
Nope, that's about it. I'd look for major and minor versions. Daniel
is pretty good about not breaking ABI with micro releases and think
I've done a decent job in the past with the libxml/xsl bindings. -sc
--
Sean Chittenden
___
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
all a version
check at the load of the .so to confirm that ruby's libxml/libxslt
bindings are the same as current or within a micro release.
How's that sound? -sc
--
Sean Chittenden
___
libxml-devel mailing list
libxml-devel@rubyforge.org
82 matches
Mail list logo
