<begonzo>
because the node "see" the child...the child "see" the parent....
<begonzo>
oh
<derdon>
type 'a btree = Empty | Node of 'a * 'a btree * 'a btree;;
<xavierbot>
type 'a btree = Empty | Node of 'a * 'a btree * 'a btree
<begonzo>
but in this example there isn't the parent
<derdon>
so what?
<begonzo>
one minute
<begonzo>
so...imagine to have some functions (in,out,local vars)....one of each can call another one...and so on
<begonzo>
A calls B and C, B calls C and D, C calls D and D is leaf
<begonzo>
i have to build a calls tree...based on these functions...and i have to know the parent also..because for each var i must write the complete name until the root....
<begonzo>
if D contains 'x'
<begonzo>
it can be A.B.C.D.x or A.C.D.x
<begonzo>
i can have more calls for a function..they are distinct
<orbitz>
you don't need a reference to the parent for that
chenyu468 has joined #ocaml
<begonzo>
if i write a ref to the parent ocaml does infinitive loop
<begonzo>
in fact, if you do it in the shell you can see that ocaml writes a lot of rows... and overloads
<derdon>
begonzo: you have exactly one root?
<begonzo>
yes one root
<begonzo>
only one
<derdon>
and the root knows that it has no parents?
<begonzo>
yes...with a flag or something else
<orbitz>
he doens't need to track the parent to dow hat he wants by how he decribedit
<begonzo>
the root no but the internal nodes yes
<orbitz>
what?
<orbitz>
all you want to do is track the path you took to get to the node leaf you are at, you can just track it while you perform the call
<begonzo>
ehm maybe i can't undestand that you wrote :P sorry i don't know english very well
<begonzo>
i want to track the right path from a leaf to root
<begonzo>
they can be more of one
<begonzo>
in my example C is child of A but of B also
<orbitz>
so just keep track of what nodes you saw on teh way
<begonzo>
yes
<begonzo>
i work with lustre language..that is done of a lot of these functions(called "nodes")
<begonzo>
i wrote the parser...
<begonzo>
and i have to do it too
<begonzo>
i though that i can save not the "pointer" of the parent but only a integer ID...
<begonzo>
and write a function that,based on a node return a parent knowing the id...
<orbitz>
trace path = function Node (_, l, r) -> trace (l::path) l | Empty -> print path
<begonzo>
but a node can have one,two,a lot of children
<begonzo>
not only two
<orbitz>
so modify trace to support that
<orbitz>
trace isn't even ocmplete it's just to show you how to do it
<begonzo>
the problem isn't printing the trace...but building the tree
<begonzo>
i scan my structure returned by the parser....and each time i find a node call i have to add node information....and so on
<orbitz>
my example trace allows for that
chenyu468 has quit []
<begonzo>
but your example (if i understand) is top-down... i need a bottom-up algorithm..because i must write the complete name of all the variables of all nodes. so i start from them
<orbitz>
what?
<orbitz>
just reverse 'path' when you wan tot use it...
<gildor>
Camarade_Tux: DESTDIR s a variable prepended to each installed target file
<gildor>
it should not take into account the path itself
<gildor>
(need to go, see you in 1 hour)
seafood has joined #ocaml
<begonzo>
thanks but maybe i undestood how i have to do.....
<Camarade_Tux>
I was thinking $(DESTDIR)$(libdir)/libfoo.a
<Camarade_Tux>
bah
<Camarade_Tux>
gildor: I was thinking that in "$(DESTDIR)$(libdir)/libfoo.a", libdir could be \some\thing instead of C:\some\thing (but I haven't thought a lot about it, I'm in a very very bad mood right now)
<begonzo>
orbitz was right....i can trace the path in top-down way.....
<begonzo>
thank you
<begonzo>
i do.....
lvillani has joined #ocaml
ikaros has joined #ocaml
seafood has quit [Quit: seafood]
seafood has joined #ocaml
Yoric has joined #ocaml
Shoggoth has joined #ocaml
begonzo has quit [Ping timeout: 252 seconds]
lvillani has quit [Quit: Leaving]
Shoggoth has quit [Quit: Ex-Chat]
joewilliams_away is now known as joewilliams
<gildor>
Camarade_Tux: the problem is to change the meaning of DESTDIR for a specific platform
<gildor>
Camarade_Tux: some people can expect this behavior and even use it
<gildor>
Camarade_Tux: I am thinking of generalizing DESTDIR to desttr function
<gildor>
Camarade_Tux: desttr: string -> string
<gildor>
in the case of DESTDIR, desttr s = (Sys.getenv "DESTDIR")^s
<gildor>
this way you don't change what DESTDIR means and you provide a more general scheme for stagged install
ulfdoz has quit [Ping timeout: 246 seconds]
yakischloba has joined #ocaml
komar_ has quit [Quit: WeeChat 0.2.6]
komar_ has joined #ocaml
seafood has quit [Quit: seafood]
smimou has joined #ocaml
Yoric has quit [Quit: Yoric]
alp_ is now known as Alpounet
Alpounet is now known as alpounet
enthymeme has joined #ocaml
seafood has joined #ocaml
seafood has quit [Quit: seafood]
thieusoai has joined #ocaml
elehack has joined #ocaml
kaustuv has joined #ocaml
<kaustuv>
Is LablGL maintained and are there any plans to update it to recent versions of OpenGL?
kaustuv_ has joined #ocaml
kaustuv has quit [Ping timeout: 265 seconds]
smimou has quit [Ping timeout: 246 seconds]
kaustuv_ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
smimou has joined #ocaml
joewilliams is now known as joewilliams_away
dark has joined #ocaml
smimou has quit [Ping timeout: 246 seconds]
xavierbot has quit [Ping timeout: 258 seconds]
rwmjones has quit [Ping timeout: 276 seconds]
ftrvxmtrx has joined #ocaml
thrasibule has joined #ocaml
rwmjones has joined #ocaml
rwmjones has quit [Ping timeout: 276 seconds]
drk-sd has joined #ocaml
pimmhogeling has quit [Remote host closed the connection]
rwmjones has joined #ocaml
pimmhogeling has joined #ocaml
heyhey has joined #ocaml
heyhey has left #ocaml []
rwmjones has left #ocaml []
ccasin has joined #ocaml
<elehack>
thelema, I'm looking at making Batteries buildable with ocamlbuild.
<elehack>
and looking at build/myocamlbuild.ml for some help; have you seen or hunted down any information on copyright on the sample code in the Gallium wiki? I've pinged the OCaml mailing list once or twice, but received no reply.
slash_ has quit [Quit: Lost terminal]
slash_ has joined #ocaml
<thelema>
I don't know copyright on that, but the build/myocamlbuild (and other infrastructure in the project tree) should be fair game to build off
<thelema>
that - gallium wiki
<elehack>
ok.
Submarine has quit [Quit: Leaving]
ygrek has quit [Ping timeout: 245 seconds]
ikaros has quit [Ping timeout: 246 seconds]
<thelema>
elehack: thanks for fixing @raises
<thelema>
todo: put these annotations on all functions
seafood has joined #ocaml
seafood has quit [Client Quit]
ikaros has joined #ocaml
ikaros has quit [Remote host closed the connection]
yakischloba has quit [Quit: Leaving.]
yakischloba has joined #ocaml
yakischloba has quit [Client Quit]
npouillard has quit [Read error: Operation timed out]
npouillard has joined #ocaml
<elehack>
thelema, agreed. that dovetails nicely with another thing that I'm thinking would be good prior to 2.0... a careful interface audit to make sure everything makes sense and is properly documented.
<elehack>
they can be in a "things to do in a careful read-through of mli files" task some day.
<thelema>
yup.
<thelema>
I'd like to drop some of the junk from batteries for 2.0 - removing the current argument handling libraries(!) and maybe other cruft
<elehack>
that would probably also be good.
<elehack>
do we have these things documented anywhere yet? or should we start a 2.0 page on the github wiki?
<elehack>
on the Pervasives note I just added: as with the bug recently discussed about open_out, I am of the persuasion that all BatPervasives functions appearing in Inria's Pervasives should be source-compatible with Inria's to minimize nasty surprises.
sepp2k1 has quit [Quit: Leaving.]
<thelema>
Does anyone want anything other than 100% source compatibility?
<elehack>
Not that I know of.
<elehack>
I just haven't seen it explicitly stated as a goal anywhere.
<thelema>
fair enough.
<thelema>
In the short term, I agree it's necessary to do this, but I don't consider it a goal, more of a means.
<thelema>
In the long term, with batteries being the defacto stdlib, we may surpass INRIA's pervasives.
<thelema>
well, more likely other modules in the stdlib.
<thelema>
hmm...
<thelema>
but that's a long time from now.
<elehack>
yeah. and we can also just deprecate the things in Inria's pervasives that are most likely to cause problems, e.g. by saying that new code should do I/O with the IO module.
<thelema>
We'll have to implement seekable I/O to match Pervasives to BatPervasives
<elehack>
true.
<elehack>
that can be a problem with the polymorphic I/O stuff :-S
<thelema>
there's a patch for pre-aaa batteries. It'll take some work to apply properly to current batteries
<elehack>
Another option would be not overriding the Inria I/O functions to be IO-compatible; this would allow easy access to the seekable IO, and it's easy enough to make an IO.{input,output} from a legacy channel.
yakischloba has joined #ocaml
<thelema>
I have initial objections to this, but on reflection, this might be the best way. Althought it'd be a 2.0 change.
struktured has quit [Quit: Laptop suspended.]
<elehack>
It would be a 2.0. And it does have downsides - there would then be 2 different sets of I/O types running around with different capability sets. But legacy I/O is faster, too, and I've written code where that matters.
struktured has joined #ocaml
<thelema>
We won't remove it from Legacy.*
<elehack>
For sure, and right now my program where it matters is importing it from Legacy.
<elehack>
so performance isn't a strong argument.
<thelema>
which is the way I'd like to have people doing it. Maybe our current solution is a fair enough way to go forward, and 99% compatibility is good enough.
<elehack>
At 99%, is seeking the thing you are thinking of being in the 1% missing?
* thelema
plans to add a Batteries_labels toplevel interface which provides labeled functions everywhere
<thelema>
yes.
jeddhaberstro has joined #ocaml
Amorphous has quit [Ping timeout: 246 seconds]
<elehack>
seekable I/O is also still available w/ file descriptors, so it's not like the functionality would be entirely missing.
<orbitz>
thelema: hopefully my label program will maek that painless once i ge ta chance ot write it!