Re: [Caml-list] Incremental linking
Dawid Toton wrote: I have lot of modules and they are compiled to native code. So I have .cmx and .o files and want to link them faster. Is is possible to make linking an associative operation acting on modules? [...] Documentation of ld says that files produced with --relocatable can be used as intermediate partially linked files. Can something like this be done with object code produced by ocamlopt? Yes. "ocamlopt -pack" actually calls "ld -r" underneath to consolidate several compilation units in a single .cmx/.o file. "ld -r" will resolve references between these compilation units. Gerd Stolpmann wrote: Well, you can link several .cmx files (and their accompanying .o files) to a .cmxa file (and an accompanying .a file): ocamlopt -a From a linking standpoint, "ocamlopt -a" is equivalent to "ar": it does not resolve any references, just concatenates individual .cmx/.o files in a single .cmxa/.a file. That can still speed up linking a bit, since reading one big .a file is faster than reading a zillion small .o files. Generally speaking, I'm somewhat surprised that linking time is an issue for Dawid. Modern Unix linkers are quite fast, and the additional link-time work that OCaml does is small. Let us know if you manage to narrow the problem. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
On Wed, Sep 30, 2009 at 01:00:15AM +0200, Mikkel Fahnøe Jørgensen wrote:
> In line with what Yaron suggests, you can use a combinator parser.
>
> I do this to parse json, and this parser could be adapted to xml by
> focusing on basic syntax and ignoring the details, or you could
> prefilter xml and use the json parser directly.
>
> See the Fleece parser embedded here:
>
> There is also the object abstraction that dives into an object
> hierarchy after parsing, see the Objects module. The combination of
> these two makes it quite easy to work on structured data, but 3 lines
> only come after some xml adaptation work - but you can see many
> one-liner json access in the last part of the file.
>
> http://git.dvide.com/pub/symbiosis/tree/myocamlbuild_config.ml
>
> Otherwise there is xmlm which is self-contained in single xml file,
> and as I recall, has some sort of zipper navigator. (I initially
> intended to use it before deciding on the json format):
>
> http://erratique.ch/software/xmlm
It's interesting you mention xmlm, because I couldn't write
the code using xmlm at all.
The discussion here has got quite theoretical, but it's not helping
me to write the original 3 lines of Perl in OCaml.
my $p = XML::XPath->new (xml => $xml);
my @disks = $p->findnodes ('//devices/disk/source/@dev');
push (@disks, $p->findnodes ('//devices/disk/source/@file'));
My best effort, using xml-light, is around 40 lines:
http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=ocaml/examples/viewer.ml;h=ef6627b1b92a4fff7d4fa1fa4aca63eeffc05ece;hb=HEAD#l322
Rich.
--
Richard Jones
Red Hat
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
> The discussion here has got quite theoretical, but it's not helping
> me to write the original 3 lines of Perl in OCaml.
>
> my $p = XML::XPath->new (xml => $xml);
> my @disks = $p->findnodes ('//devices/disk/source/@dev');
> push (@disks, $p->findnodes ('//devices/disk/source/@file'));
>
> My best effort, using xml-light, is around 40 lines:
>
> http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=ocaml/examples/viewer.ml;h=ef6627b1b92a4fff7d4fa1fa4aca63eeffc05ece;hb=HEAD#l322
>
Galax is (or was ??) an XQuery implementation in ocaml
and XPath 2.0 is included in XQuery... so maybe you can use it...
the site does not seem to respond now:
http://www.galaxquery.org/
but there is a debian package:
http://upsilon.cc/~zack/blog/posts/2008/02/galax_in_debian/
> Rich.
>
> --
> Richard Jones
> Red Hat
>
> ___
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
2009/9/30 Richard Jones : > On Wed, Sep 30, 2009 at 01:00:15AM +0200, Mikkel Fahnøe Jørgensen wrote: >> In line with what Yaron suggests, you can use a combinator parser. > It's interesting you mention xmlm, because I couldn't write > the code using xmlm at all. If you can manage to convert an xml document into a json like tagged tree structure, then a simple solution like module Value = struct 56 type value_type = 57Object of (string * value_type) list 58 | Array of value_type list 59 | String of string 60 | Int of int 61 | Float of float 62 | Bool of bool 63 | Null 64end 65 .. 665 let get_object v = match v with Object x -> x 666 | _ -> fail "json object expected" .. 685 let pattern_path value names = 686 let rec again value = function 687 | "*" :: names -> List.iter (fun (n, v) -> try again v names 688 with Invalid_argument _ | Not_found -> ()) (get_object value) 689 | name :: names -> again (List.assoc name (get_object value)) names 690 | [] -> raise (Found value) 691 in try again value names; raise Not_found with Found value -> value 692 combined with a path split function 22let split c s = 23 let n = String.length s in 24 let rec again i lst = 25begin try let k = String.rindex_from s i c in 26 again (k - 1) ((if i = k then "" else (String.sub s (k + 1) (i - k))) :: lst) 27 with _ -> (String.sub s 0 (i + 1)) :: lst 28end 29 in again (n - 1) [] will do almost exactly what you are asking for - notice the "*" searches broadly in all subtrees. You can add your own xpath like functions as you discover a need for them. I believe that the xmlm examples has a tree transformation operation that would easily be adapted to produce a json like tree, if modified a little. let out_tree o t = let frag = function | E (tag, childs) -> `El (tag, childs) | D d -> `Data d in Xmlm.output_doc_tree frag o t > My best effort, using xml-light, is around 40 lines: If you spend those 40 lines on a layer on top of a lightweight xml parser, you might get away with 3 lines the next time. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
Hi, Ocamlduce has been mentioned before in this thread, but I didn't catch the reason why it has been discarded as a solution. Is it because you don't want to carry the extra (large) dependency, or is there some other reason? And on the subject of simple XML parsers for Ocaml, there's also the aptly named Simplexmlparser from the Ocsigen project [1]. It's about as spartan as one can conceive, yet sufficient for a large subset of XML extraction tasks. Cheers, Dario Teixeira [1] http://ocsigen.org/docu/1.2.0/Simplexmlparser.html ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] JIT & HLVM, LLVM
Mikkel Fahnøe Jørgensen a écrit : > A function can push other functions to the global queue. This in > effect creates a continuation, and the concept is similar to > continuation passing style or LWT threads, *but requires no > continuation arguments to drag around*. Could you elaborate? Best regards, -- Stéphane ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
On Wed, Sep 30, 2009 at 04:05:03AM -0700, Dario Teixeira wrote: > Hi, > > Ocamlduce has been mentioned before in this thread, but I didn't catch > the reason why it has been discarded as a solution. Is it because you > don't want to carry the extra (large) dependency, or is there some other > reason? Actually the reason is that I thought it wasn't available for 3.11.1, but I just checked the website and it is, and ocamlduce does seem to be the obvious solution for this problem. (However I'll need to try and see if I can come up with the equivalent code). > And on the subject of simple XML parsers for Ocaml, there's also the > aptly named Simplexmlparser from the Ocsigen project [1]. It's about > as spartan as one can conceive, yet sufficient for a large subset of > XML extraction tasks. > > [1] http://ocsigen.org/docu/1.2.0/Simplexmlparser.html Thanks - but if I understand that page correctly, then isn't it just parsing XML into a tree? Rich. -- Richard Jones Red Hat ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Why don't you use batteries?
09/03/2009 04:05 PM, Edgar Friendly: 8) Other (please explain) Some hints (I just saw it in my INBOX, I dont agree nor disagree): http://www.itworld.com/open-source/78643/how-attract-more-people-your-open-source-project -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34 ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] JIT & HLVM, LLVM
First, sorry for the rough post (it was late), I see some typos and slightly more confusing mistakes, but hopefully not too bad, or please ask. >> A function can push other functions to the global queue. This in >> effect creates a continuation, and the concept is similar to >> continuation passing style or LWT threads, *but requires no >> continuation arguments to drag around*. > Could you elaborate? Yes, I'm probably not the best to explain continuation passing style, but I'll give it a shot. In OCaml you do not have continuations, but you do have partial evaluation. This means the function let sum a b = a + b can be called partially like let sum_creator a = sum a This won't execute the sum code, but will have it pending until we get the last argument b. In this sense the sum_creator function is a sleeping thread waiting to execute. We can combine several functions in this way to get a complex calculation which won't evaluate until the continuation argument b is supplied. For example we can create a complex boolean expression combining several primitive and / or functions that take a variable x as argument. The entire expression is suspended until x is given, and in principle the OR subexpressions could execute in parallel. We can also build parse expressions where it is not a variable x, but the rest of the input string that is missing. Instead of evaluating a sum or boolean expression, the function could do something else, like filling a buffer from a socket. The k argument does not need to be used at all, we just use it to avoid computation before we need it. We can use this to create threads by having an extra dummy argument that we will call k. We don't really need k we just need the expression to not evaluate before we say so. This is the continuation being dragged (passed) around. (In monadic stream parsers, the k continuation is replaced by io state which is dragged around, and contrary to k it provides useful information. These parsers allow parsing to sleep when the input stream dries up temporarily, and the parsers can explore several parse paths concurrently (useful for error reporting), so there is an analog to concurrent threads consuming i/o). A function can also return a recursive call to itself supplying new state such as bytes left to read, or a partial call to another function, in both cases supplying new state information, but failing to supply to the k argument such that "the next task to execute" is returned instead of actually executing this task. A now it starts to get complex, but you get a hold of an entire tree of partially evaluated functions that are parked waiting for the last argument. A clean way to put one function after another so they execute in sequence as dependent tasks is to use a monadic bind operation: http://ocsigen.org/docu/last/Lwt.html#VALbind But this requires the function to be designed in a clean way and conform to certain monadic rules, and getting it wrong creates a mess in the type errors. What we effectively achieve is a lot of functions queued up on a the call stack in the form of closures allocated to hold the partially evaluated parameters. Now, we might as well just push a closure onto a queue instead of on the call stack. This avoid a lot of complexity in the function type design, and we get a lot more flexibility in how we dispatch the tasks (arguably we could do the same or possibly more, in continuation passing style, but it will give you a headache). We might loose some type safety by using queues, but I'm sure one could dream up some queue type system to enforce certain conditions. More importantly, it is much simpler to understand a closure on a queue, than continuation passing style. And finally, with queues you have an elegant way of extending this to multiple OS threads (or ocaml green threads), although again this is also doable in continuation passing style. Someone could probably argue that a queue is also just a continuation state or something, but we a dealing with making threaded abstractions that are easy to use and implement, not mathematical equivalence relations. 2009/9/30 Stéphane Glondu : > Mikkel Fahnøe Jørgensen a écrit : >> A function can push other functions to the global queue. This in >> effect creates a continuation, and the concept is similar to >> continuation passing style or LWT threads, *but requires no >> continuation arguments to drag around*. > > Could you elaborate? > > > Best regards, > > -- > Stéphane > > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
On Wed, Sep 30, 2009 at 12:57:23PM +0100, Richard Jones wrote:
> On Wed, Sep 30, 2009 at 04:05:03AM -0700, Dario Teixeira wrote:
> > Hi,
> >
> > Ocamlduce has been mentioned before in this thread, but I didn't catch
> > the reason why it has been discarded as a solution. Is it because you
> > don't want to carry the extra (large) dependency, or is there some other
> > reason?
>
> Actually the reason is that I thought it wasn't available for 3.11.1,
> but I just checked the website and it is, and ocamlduce does seem to
> be the obvious solution for this problem. (However I'll need to try
> and see if I can come up with the equivalent code).
Do any cduce developers want to give me a clue here? It would seem
like I need something along these lines:
let devs = match xml with
| {{ [[[]]] }} -> dev
| {{ [[[]]] }} -> file in
However according to the compiler, devs has type . In any case,
I think I may need either the map or map* operator, since I want to
match all, not just the first one.
Rich.
--
Richard Jones
Red Hat
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
OCamlduce (Alain correct me if I am wrong) basically maintains two
separate type systems side by side (the Xduce one and the Ocaml one).
This is done in order to make Ocamlduce maintainable by keeping a
clear separation. As a result you have to explicitly convert values
between type systems using {:...:}. These casts are type safe but do
lead to some work at runtime.
Also note that ocaml's string are Latin1 and not String in the XML world. So:
let devs = match xml with
| {{ [[[]]] }} -> {:dev:}
| {{ [[[]]] }} ->
{:file:} in
Should work (I'm rusty and have nothing to check handy).
Till
On Wed, Sep 30, 2009 at 8:59 AM, Richard Jones wrote:
> On Wed, Sep 30, 2009 at 12:57:23PM +0100, Richard Jones wrote:
>> On Wed, Sep 30, 2009 at 04:05:03AM -0700, Dario Teixeira wrote:
>> > Hi,
>> >
>> > Ocamlduce has been mentioned before in this thread, but I didn't catch
>> > the reason why it has been discarded as a solution. Is it because you
>> > don't want to carry the extra (large) dependency, or is there some other
>> > reason?
>>
>> Actually the reason is that I thought it wasn't available for 3.11.1,
>> but I just checked the website and it is, and ocamlduce does seem to
>> be the obvious solution for this problem. (However I'll need to try
>> and see if I can come up with the equivalent code).
>
> Do any cduce developers want to give me a clue here? It would seem
> like I need something along these lines:
>
> let devs = match xml with
> | {{ [[[]]] }} -> dev
> | {{ [[[]]] }} -> file in
>
> However according to the compiler, devs has type . In any case,
> I think I may need either the map or map* operator, since I want to
> match all, not just the first one.
>
> Rich.
>
> --
> Richard Jones
> Red Hat
>
> ___
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
On Mon, Sep 28, 2009 at 01:17:45PM +0100, Richard Jones wrote:
> I need to do some relatively simple extraction of fields from an XML
> document. In Perl I would use xpath, very specifically if $xml was an
> XML document[1] stored as a string, then:
>
> my $p = XML::XPath->new (xml => $xml);
> my @disks = $p->findnodes ('//devices/disk/source/@dev');
> push (@disks, $p->findnodes ('//devices/disk/source/@file'));
I've just realized that this thread can look a bit ridiculous, at least
for people used to other languages where XPath implementations can even
be found in the language standard library (the best solutions we have
thus far are: a 40-line xml-light solution, the need to use a modified
version of the OCaml compiler [yes, I know, it is compatible, but still
...], Galax with unreachable homepage, ...).
So, I was wondering, has anybody ever tried to develop an XPath
implementation on top of, say, PXP? The original announcement page of
PXP (now archived) mentions "rumors" about people which, back then, were
developing it. Has anything ever been released?
At first glance, it doesn't seem to exist any specific typing problem,
at least with XPath 1.0, since the PXP node interface is already common
for all node types. Sure XPath 2.0, when static typing is in use, can be
better integrated with the language, but that's probably already
happening in Galax.
[ Cc-ing the PXP mailing list ]
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] JIT & HLVM, LLVM
Mikkel Fahnøe Jørgensen a écrit : > But this requires the function to be designed in a clean way and > conform to certain monadic rules, and getting it wrong creates a mess > in the type errors. Actually, I find the typing discipline enforced by the monadic abstraction very helpful (and elegant). > Now, we might as well just push a closure onto a queue instead of on > the call stack. This avoid a lot of complexity in the function type > design, and we get a lot more flexibility in how we dispatch the tasks > (arguably we could do the same or possibly more, in continuation > passing style, but it will give you a headache). This sounds like a narrow (and C-ish) way to tackle things. The bind operator is about composition of threads, not scheduling. > More importantly, it is much simpler to understand a closure on a > queue, than continuation passing style. What you call the "call stack" is orthogonal to your "queues of closures": one is about combining results of threaded computations whereas the other is just spawning threads and relying on some external mechanism to schedule them. In other words, I think both can be used together, and achieve different purposes. Best regards, -- Stéphane ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
On Wed, Sep 30, 2009 at 09:33:07AM -0400, Till Varoquaux wrote:
> OCamlduce (Alain correct me if I am wrong) basically maintains two
> separate type systems side by side (the Xduce one and the Ocaml one).
> This is done in order to make Ocamlduce maintainable by keeping a
> clear separation. As a result you have to explicitly convert values
> between type systems using {:...:}. These casts are type safe but do
> lead to some work at runtime.
>
> Also note that ocaml's string are Latin1 and not String in the XML world. So:
>
> let devs = match xml with
>| {{ [[[]]] }} -> {:dev:}
>| {{ [[[]]] }} ->
> {:file:} in
>
> Should work (I'm rusty and have nothing to check handy).
I tried variations on the above, but couldn't get it to work.
ocamlduce is very fond of a mysterious error called "Error: Subtyping
failed", which is very difficult for me to understand, and therefore
must be absolutely impossible for someone not used to strong typing.
This is where I'm heading at the moment (sorry, my previous
example missed a level inside ), so:
let xml = from_string xml in
prerr_endline (Ocamlduce.to_string xml);
let devs = {{ map [xml] with
| [[[_]]]
| [[[_]]] -> [s]
| _ -> [] }} in
prerr_endline (Ocamlduce.to_string devs);
+1 : this compiles
-1 : it doesn't work, devs is empty
This is what the first prerr_endline prints:
[
[ 'CentOS5x32' ]
[ '2ce397d9-1931-feb1-8ad8-15f22c4f18af' ]
[ '524288' ]
[ '524288' ]
[ '1' ]
[ [ 'hvm' ] [ ] ]
[ [ ] [ ] [ ] ]
[ ]
[ 'destroy' ]
[ 'restart' ]
[ 'restart' ]
[
[ '/usr/bin/qemu-kvm' ]
[
[ ]
[ ]
]
[
[ ]
[ ]
[ ]
]
[ [ ] [ ] ]
[
[ ]
[ ]
]
[ ]
[ ]
[ [ ] ]
]
]
and what the second prerr_endline prints:
""
Rich.
--
Richard Jones
Red Hat
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
If I am not mistaken you are selecting a domain whose first child is a
device node whose only child is disk node ...
instead of:
[[[_]]]
you should aim for something in the vein of:
[_* ( ((|
_)* |_)* _*]
Till
On Wed, Sep 30, 2009 at 10:01 AM, Richard Jones wrote:
> On Wed, Sep 30, 2009 at 09:33:07AM -0400, Till Varoquaux wrote:
>> OCamlduce (Alain correct me if I am wrong) basically maintains two
>> separate type systems side by side (the Xduce one and the Ocaml one).
>> This is done in order to make Ocamlduce maintainable by keeping a
>> clear separation. As a result you have to explicitly convert values
>> between type systems using {:...:}. These casts are type safe but do
>> lead to some work at runtime.
>>
>> Also note that ocaml's string are Latin1 and not String in the XML world. So:
>>
>> let devs = match xml with
>> | {{ [[[]]] }} -> {:dev:}
>> | {{ [[[]]] }} ->
>> {:file:} in
>>
>> Should work (I'm rusty and have nothing to check handy).
>
> I tried variations on the above, but couldn't get it to work.
> ocamlduce is very fond of a mysterious error called "Error: Subtyping
> failed", which is very difficult for me to understand, and therefore
> must be absolutely impossible for someone not used to strong typing.
>
> This is where I'm heading at the moment (sorry, my previous
> example missed a level inside ), so:
>
> let xml = from_string xml in
> prerr_endline (Ocamlduce.to_string xml);
>
> let devs = {{ map [xml] with
> | [[[_]]]
> | [[[_]]] -> [s]
> | _ -> [] }} in
> prerr_endline (Ocamlduce.to_string devs);
>
> +1 : this compiles
> -1 : it doesn't work, devs is empty
>
> This is what the first prerr_endline prints:
>
> type="kvm"
> id="2">[
> [ 'CentOS5x32' ]
> [ '2ce397d9-1931-feb1-8ad8-15f22c4f18af' ]
> [ '524288' ]
> [ '524288' ]
> [ '1' ]
> [ [ 'hvm' ] [ ] ]
> [ [ ] [ ] [ ] ]
> [ ]
> [ 'destroy' ]
> [ 'restart' ]
> [ 'restart' ]
> [
> [ '/usr/bin/qemu-kvm' ]
> type="block"
> device="disk">[
> [ ]
> [ ]
> ]
> type="network">[
> [ ]
> [ ]
> [ ]
> ]
> [ [ ] [ ] ]
> type="pty"
> tty="/dev/pts/7">[
> [ ]
> [ ]
> ]
> [ ]
> [ ]
> [ [ ] ]
> ]
> ]
>
> and what the second prerr_endline prints:
>
> ""
>
> Rich.
>
> --
> Richard Jones
> Red Hat
>
> ___
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
Am Mittwoch, den 30.09.2009, 15:39 +0200 schrieb Stefano Zacchiroli:
> On Mon, Sep 28, 2009 at 01:17:45PM +0100, Richard Jones wrote:
> > I need to do some relatively simple extraction of fields from an XML
> > document. In Perl I would use xpath, very specifically if $xml was an
> > XML document[1] stored as a string, then:
> >
> > my $p = XML::XPath->new (xml => $xml);
> > my @disks = $p->findnodes ('//devices/disk/source/@dev');
> > push (@disks, $p->findnodes ('//devices/disk/source/@file'));
>
> I've just realized that this thread can look a bit ridiculous, at least
> for people used to other languages where XPath implementations can even
> be found in the language standard library (the best solutions we have
> thus far are: a 40-line xml-light solution, the need to use a modified
> version of the OCaml compiler [yes, I know, it is compatible, but still
> ...], Galax with unreachable homepage, ...).
>
> So, I was wondering, has anybody ever tried to develop an XPath
> implementation on top of, say, PXP? The original announcement page of
> PXP (now archived) mentions "rumors" about people which, back then, were
> developing it. Has anything ever been released?
No. However, there is a little XPath evaluator in SVN:
https://godirepo.camlcity.org/svn/lib-pxp/trunk/src/pxp-engine/pxp_xpath.ml
I have never found the time to complete it, and to add some syntax
extension for painless use. But maybe somebody wants to take this over?
Gerd
> At first glance, it doesn't seem to exist any specific typing problem,
> at least with XPath 1.0, since the PXP node interface is already common
> for all node types. Sure XPath 2.0, when static typing is in use, can be
> better integrated with the language, but that's probably already
> happening in Galax.
>
> [ Cc-ing the PXP mailing list ]
>
> Cheers.
>
--
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany
g...@gerd-stolpmann.de http://www.gerd-stolpmann.de
Phone: +49-6151-153855 Fax: +49-6151-997714
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
Richard Jones wrote:
let devs = {{ map [xml] with
| [[[_]]]
| [[[_]]] -> [s]
| _ -> [] }} in
The following should work:
let l = {{ [xml] }} in
let l = {{ map l with l -> l | _ -> [] }} in
let l = {{ map l with l -> l | _ -> [] }} in
let l = {{ map l with l -> l | _ -> [] }} in
let l = {{ map l with _
| _-> s
| _ -> [] }} in
...
let () =
let l = {{ [xml] }} in
let l = {{ (((l.(_)) / .(_)) / .(_)) / }} in
let l = {{ map l with _
| _ -> s
| _ -> [] }} in
..
This uses the constructions e/ and e.(t) as described in the manual.
That said, using OCamlDuce for this kind of XML data-extraction seems
just crazy to me.
Cheers,
Alain
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
On Wed, Sep 30, 2009 at 04:51:01PM +0200, Alain Frisch wrote:
> Richard Jones wrote:
> > let devs = {{ map [xml] with
> >| [[[_]]]
> >| [[[_]]] ->
> >[s]
> >| _ -> [] }} in
>
> The following should work:
>
> let l = {{ [xml] }} in
> let l = {{ map l with l -> l | _ -> [] }} in
> let l = {{ map l with l -> l | _ -> [] }} in
> let l = {{ map l with l -> l | _ -> [] }} in
> let l = {{ map l with _
> | _-> s
> | _ -> [] }} in
> ...
>
> let () =
> let l = {{ [xml] }} in
> let l = {{ (((l.(_)) / .(_)) / .(_)) / }} in
> let l = {{ map l with _
> | _ -> s
> | _ -> [] }} in
> ..
Thanks Alain. My latest attempt was similar to your version 1 above,
and it works :-)
Now my code looks like your version 2:
let xml = from_string xml in
let xs = {{ [xml] }} in
let xs = {{ (((xs.(_)) / .(_)) / .(_)) / }} in
let xs = {{ map xs with
| _
| _ -> [s]
| _ -> [] }} in
{: xs :}
(plus the boilerplate for interfacing xml-light and CDuce).
We're getting close to the xpath/perl solution (8 lines vs 3 lines),
with some added type safety and the possibility of validating the XML.
On the other hand, the code is hard to understand. It's not clear to
me what the .( ) syntax means, nor why there is an apparently trailing
/ character.
> This uses the constructions e/ and e.(t) as described in the manual.
>
> That said, using OCamlDuce for this kind of XML data-extraction seems
> just crazy to me.
I have some comments:
(A) "Subtyping failed" is a very common error, but is only mentioned
briefly in the manual. I have no idea what these errors mean, so they
should have more explanation. Here is a simple one which was caused
by me using a value instead of a list (but that is not at all obvious
from the error message):
Error: Subtyping failed Latin1 <= [ Latin1* ]
Sample:
[ Latin1Char ]
(B) I think the interfacing code here:
http://yquem.inria.fr/~frisch/ocamlcduce/samples/expat/
http://yquem.inria.fr/~frisch/ocamlcduce/samples/pxp/
http://yquem.inria.fr/~frisch/ocamlcduce/samples/xmllight/
should be distributed along with ocamlduce.
Rich.
--
Richard Jones
Red Hat
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
On Wed, Sep 30, 2009 at 04:49:37PM +0200, Gerd Stolpmann wrote:
> No. However, there is a little XPath evaluator in SVN:
> https://godirepo.camlcity.org/svn/lib-pxp/trunk/src/pxp-engine/pxp_xpath.ml
Cool, and you have even already implemented all of the XPath 1.0
standard library!
> I have never found the time to complete it, and to add some syntax
> extension for painless use. But maybe somebody wants to take this
> over?
If I'm not mistaken, more than a syntax extension that evaluator needs a
parser from concrete syntax to the abstract syntax you've already
implemented. Once you have that, I don't think there is really a need of
any syntax extension, what would be wrong in using it as follows:
let nodes = xpath_eval ~xpath:(xpath "/foo/bar[2]/@baz") tree in
let nodes2 = xpath_eval ~expr:"/foo/bar[2]/@baz" in
...
we already use regexps this way and is more than handy. Or am I missing
something here?
I don't have energy to volunteer myself, but I duly note that Alain's
old XPath implementation already contains a parser that can be reused
(whereas the lexer should be changed, as already observed; most likely
the lexer should be ported to Ulex).
All in all, it is probably just a matter of integration work (modulo the
limitations of the current evaluator, of course).
Any volunteer? :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
Richard Jones wrote: On the other hand, the code is hard to understand. It's not clear to me what the .( ) syntax means, nor why there is an apparently trailing / character. From the manual: If the x-expression e evaluates to an x-sequence, the construction e/ will result in a new x-sequence obtained by taking in order all the children of the XML elements from the sequence e. For instance, the x-expression [[ 1 2 3 ] 4 5 [ 6 7 8 ] ]/ evaluates to the x-value [ 1 2 3 6 7 8 ]. If the x-expression e evaluates to an x-sequence, the construction e.(t) (where t is an x-type) will result in a new x-sequence obtained by filtering e to keep only the elements of type t. For instance, the x-expression [[ 1 2 3 ] 4 5 [ 6 7 8 ] ].(Int) evaluates to the x-value [ 4 5 ]. I have some comments: (A) "Subtyping failed" is a very common error, but is only mentioned briefly in the manual. I have no idea what these errors mean, so they should have more explanation. Here is a simple one which was caused by me using a value instead of a list (but that is not at all obvious from the error message): Error: Subtyping failed Latin1 <= [ Latin1* ] Sample: [ Latin1Char ] The error tells you that Latin1 is not a subtype of [ Latin1* ]. It probably means that you are trying to use a value of type Latin1 where a value of type [ Latin1* ] is expected. (B) I think the interfacing code here: http://yquem.inria.fr/~frisch/ocamlcduce/samples/expat/ http://yquem.inria.fr/~frisch/ocamlcduce/samples/pxp/ http://yquem.inria.fr/~frisch/ocamlcduce/samples/xmllight/ should be distributed along with ocamlduce. There was a GODI package that includes them. It would be ok to put these files in the distribution without compiling them (otherwise it would create a dependency on more OCaml packages). It's up to Stéphane Glondu, the new maintainer of OCamlDuce. Cheers, Alain ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] JIT & HLVM, LLVM
On Wednesday 30 September 2009 02:08:06 Mikkel Fahnøe Jørgensen wrote: > 2009/9/27 Jon Harrop : > > On Sunday 27 September 2009 20:23:13 kche...@math.carleton.ca wrote: > >> If Grand Central Dispatch makes its way > >> into *nix... > > > > Incidentally, what exactly (technically) is Grand Central and how does it > > relate to existing alternatives and the state-of-the-art? I Googled it > > but failed to find anything useful... > > Grand Central Dispatch... Thanks for the explanation! This seems to be attacking the same problem as Cilk and the TPL but my immediate impression (based entirely upon your description) is that Cilk and the TPL are probably better foundations. Using one work stealing deque per core is much more efficient than the work sharing queue you described for two reasons: 1. Less global syncronization. 2. Subtasks are likely to be executed on the core that spawned them, which improves cache efficiency. The parallel "for" loop you described is similar to the TPL's and leaves a lot to be desired. Specifically, you want to execute clusters of consecutive tasks on the same core for two reasons: 1. Using the same core improves cache efficiency because the end of one task is often spatially related to the start of the next, e.g. parallel quicksort, linear algebra or image processing. 2. Executing clusters of tasks amortizes the cost of queueing tasks. The former is easily solved with the Cilk/TPL design by using recursive subdivision instead of the index sharing scheme you described because subtasks are likely to be executed on the same core. However, that will not work with a work sharing queue because subtasks are executed on random cores. Moreover, a trivial extension to this higher-order function allows you to pass in another function that describes the complexity of each task. This allows the recursive function to more intelligently subdivide the given range into clusters of variable-complexity tasks with similar total running times. This is the technique I use in our commercial F# libraries but I have not seen it described elsewhere. Cilk and the TPL also just rely upon the programmer to make tasks sufficiently complex that the time spent queueing and dequeueing them is insignificant. I solved this problem by injecting run-time profiling code (with global synchronizations per cluster of tasks) to measure the proportion of the time being spent spawning rather than executing tasks and then use exponential backoff to increase the cluster size until a sufficiently small proportion of the time is spent spawning. Again, I have not seen this technique described elsewhere. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] xpath or alternatives
I hope this is germane, I am very new to Ocaml. Do these help at all? http://packages.debian.org/sid/libxml-light-ocaml-dev http://tech.motion-twin.com/xmllight.html I expect it wouldn't be to difficult to write a wrapper around libxml http://xmlsoft.org/index.html -Jordan ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Re: Compiling 3.11.1 with MinGW/Windows
Matías, I have a problem where the shortcuts the cygwin installer creates aren't recognized by windows. If you go to your bin/ directory and copy gcc-3.exe to gcc.exe (replacing the shortcut), perhaps that will help. Jeff ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] JIT & HLVM, LLVM
2009/9/30 Stéphane Glondu : > Mikkel Fahnøe Jørgensen a écrit : > Actually, I find the typing discipline enforced by the monadic > abstraction very helpful (and elegant). For some purposes - for example filtering and transforming large data sets, but perhaps less so for ad hoc tasks like background reporting - although of course it can be done. >> Now, we might as well just push a closure onto a queue instead of on >> the call stack. This avoid a lot of complexity in the function type >> design, and we get a lot more flexibility in how we dispatch the tasks >> (arguably we could do the same or possibly more, in continuation >> passing style, but it will give you a headache). > > This sounds like a narrow (and C-ish) way to tackle things. The bind > operator is about composition of threads, not scheduling. Perhaps, but sometimes this makes it easier to get things done, especially for people not trained in the use of monads. Yes, bind makes sure that one task is not scheduled at the same time, or before, another task. > What you call the "call stack" is orthogonal to your "queues of > closures": one is about combining results of threaded computations > whereas the other is just spawning threads and relying on some external > mechanism to schedule them. Well - yes and no. In general, monads are about combining results, but they are also used for thread control where you do not rely on the results. But it highlights an interesting point: queues does nothing to help you communicate computation results, in parallel or not. Neither does a monad based thread library. But a map-reduce monadic setup very much does combine results and can also be made to schedule for parallel execution which is very elegant, but not a good match for more ad-hoc concurrent tasks. > In other words, I think both can be used together, and achieve different > purposes. I agree. It was not my intention to say that monads are bad in any way, and indeed many of our daily collection types are very useful monads with abstractions that make them easy to use. But since monads tend to spread all over the code, I think they should not be used as a solution to everything, and this is basically what I meant by "dragging continuations around". Regards, Mikkel ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] JIT & HLVM, LLVM
> Using one work stealing deque per core is much more efficient than the work > sharing queue you described for two reasons: > > 1. Less global syncronization. > > 2. Subtasks are likely to be executed on the core that spawned them, which > improves cache efficiency. You could also create larger task chunks or schedule multiple tasks on a serial queue to obtain some benefits of cache coherency. I'm not saying that this is a better way than the one suggest. Another issue is latency vs. throughput. If you have a lot of short transactions like in a trading system, you want things done now, not more efficiently in a while, then you'd rather add more cores to the system and wasting some. > The parallel "for" loop you described is similar to the TPL's and leaves a lot > to be desired. Specifically, you want to execute clusters of consecutive > tasks on the same core for two reasons: umm yes - it just a convenience for getting things done I suppose, but again, you could split the loop into nested loops to increase granularity. But in relation to my other recent post, there are also map-reduce for addressing these issues which work well across network nodes. > The former is easily solved with the Cilk/TPL design by using recursive > subdivision instead of the index sharing scheme you described because > subtasks are likely to be executed on the same core. I also wondered why GCD insisted on starting indices in order and even waste time syncing on the index counter since there is no guarantee of execution order, other than than start time. I guess it would be easy to modify GCD with a different scheduler - it is about 10 lines of code in the library, and you could set a property on a queue to suggest a preferred scheduler. However, I think the benefit of the current approach is exactly to ensure that as many early indices as possible run in parallel - which you might want for low latency. Another issue that concerns me more is how serial queues when more work is added to the queue. If the tasks keeps eating on the serial queue, it might starve other more important work, unless the serial queue takes a break - of course the thread is preempted, but it will not give priority to older concurrent tasks still waiting to be pulled from the global concurrent queue. Again I think this is easily fixed, and I might have not understood this fully. For high performance computing of many similar computations like pixel processing, I think one should also have a look at OpenCL, and possibly some map reduce top layer that can distribute work to multiple nodes - such a layer could be built with GCD without relying heavily on GCD for anything other than coordination. Again, here latency is important - the sooner you can ship off work to OpenCL (which feeds work to graphic coprocessors) the more work gets done rather than having work lining up on the same core to ensure GCD maximizes its own cpu cache. This also applies to network communication: if you can send data sooner, the other end can start computing earlier, and especially if risk delays. So there is an argument both ways - I think GCD is more intended for systems programming than number crunching (or raytracing :-) I think one should also remember that GCD is a programming abstraction, and that there are many ways to implement it, and as time progress some changes could be made. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] overbld -- OCaml / MinGW / Win32
Hello. I have an OCaml / MinGW / Win32 build system that I've described in the post http://caml.inria.fr/pub/ml-archives/caml-list/2009/09/1e88034bf03350ad0488a20dce729f79.en.html For now, it is a mercurial repository with http pull access with url http://gdsfh.dyndns.org:8000/ (so you can clone repository with $ hg clone http://gdsfh.dyndns.org:8000/ overbld command) Some build/install documentation can be found in files /INSTALL and /doc/mingw-msys-setup.txt. The status is "it works for me", and I'm interested in any patches, fixes, improvements and comments. The license is not included in repo, so I'm stating the license here. This project should be used only for personal needs, without any distribution, and you must accept this: 1. overbld scripts are distributed under gpl/bsd license. 2. you should not violate any "package"'s license found at /src/package/orig/ directory, 3. nobody can distribute the default binary builds of overbld, because overbld scripts build ocaml with my own patches by default. 4. this "license" can be modified later, when it will be possible to build binary packages that comply every "package"'s license. 5. this "license" or the distribution will be fixed as soon as possible, if it doesn't comply any of packages' license. 6. when there will be any good enough license, it will be placed in file /LICENSE in the overbld repository, and this "license" (in the caml-list) will lose any meaning. Despite of the numerous patches, every "packages"'s sources in this repository are not modified, the sources can be found at /src/package/orig. The license is very far from the useful one, but I don't know what the acceptable license could be used here for this kind of project. Repository hosting is not fast -- it's my own home host, 256kbit/s outgoing only. I haven't found any acceptable hosting for this kind of project. freehg.org is buggy with heavy downtimes, bitbucket.org won't host such a big repository, google-code asks me for a license, and.. you see, I don't know what a license there should be. I haven't found any other good enough public mercurial hosting. Any ideas? ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] overbld -- OCaml / MinGW / Win32
Hi, On 30 Вер 2009, at 23:30, dmitry grebeniuk wrote: Repository hosting is not fast -- it's my own home host, 256kbit/s outgoing only. I haven't found any acceptable hosting for this kind of project. freehg.org is buggy with heavy downtimes, bitbucket.org won't host such a big repository, google-code asks me for a license, and.. you see, I don't know what a license there should be. I haven't found any other good enough public mercurial hosting. Any ideas? http://code.google.com/hosting/createProject Now they allow to choose version control system. -- Mykola Stryebkov Blog: http://mykola.org/blog/ Public key: http://mykola.org/pubkey.txt fpr: 0226 54EE C1FF 8636 36EF 2AC9 BCE9 CFC7 9CF4 6747 ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
