<hcarty>
My (very limited) experience with OCaml web programming is that it's easier than C, not as easy as Perl
<hcarty>
Tac-Tics: The ocamlnet library also has some cgi/fcgi routines
2007-09-30
<hcarty>
But, then, camlidl generated code does not seem to at all
<hcarty>
My understanding from the manual is that all code should use it...
<hcarty>
Some example code in the manual uses it, some does not
<hcarty>
When do you need to use the CAMLparam macros in the C interface?
2007-09-29
<jdavis_>
hcarty: Oh, ok.
<hcarty>
jdavis_: You can call ocaml routines from C, but I don't know about embedding the VM and/or toplevel. I'm sure it's possible, but it may take some extra work.
2007-09-24
<essiene>
hcarty: yeah i know.. but sometimes i got a syntax error i didn't know how to solve... i found that putting the ;; seemed to quieten the compiler :-/
<hcarty>
essiene: For reference, you don't need the ;; to end a function
2007-09-20
<hcarty>
EliasAmaral: I think that is what cothreads is meant to provide, along with the ability to switch implementations without changing the source code
2007-09-18
<hcarty>
m3ga: I haven't been able to find a sf mirror which actually has the file
2007-09-15
<hcarty>
The documentation seems to indicate that it's possible, but "ocamlbuild foo.top" says that there are no rules to build that target
<hcarty>
What is the method for building a custom toplevel with ocamlbuild?
2007-09-14
<hcarty>
mr_hugo: You could try Pervasives.stdout
2007-09-09
<hcarty>
Seems to be working for me now... maybe it was just a server blip
<hcarty>
I can't get the site(s) to load fully, but this OCaml-Java project looks to be quite interesting
<hcarty>
So it would probably be possible
<hcarty>
flux: I don't think you could (easily) use to two simultaneously, but I think part of the focus of camlp5 is to be able to use pre-3.10.0 extensions on 3.10+
2007-09-04
<hcarty>
Unfortunately the .{} is more complicated since it can be any of Bigarray.Array[123] or Genarray depending on the number of dimensions given
<hcarty>
pango: Wow... that's an interesting trick
2007-08-24
<hcarty>
Can ocamlp3l and Cothreads can do the same? I haven't tested either of those.
<hcarty>
It was a quick experiment on my part, so I don't remember the details. But the raytracing example they have was able to utilize all 8
<hcarty>
Yes, when run with the correct options
<hcarty>
TFK: I have compiled JoCaml on an 8 processor system and run some of the example programs which come with it
2007-08-22
<hcarty>
The wrapped function takes a void* argument. I think the problem is there.
<hcarty>
Oh, nevermind...
<hcarty>
flux or Tetsuo: Have you seen this before?
<hcarty>
Another camlidl issue - gcc is complaining about camlidl-created variables being declared as void
<hcarty>
I don't know if this is the best way, but it can be set at the interface and/or individual function level with (long|int)_default(...)
<hcarty>
Tetsuo: Thanks, I'll give it a shot
<hcarty>
Do you know of a way to force an array to be an array of int32 values?
<hcarty>
Ok, thank you
<hcarty>
Would you recommend just copying over any required #defines, etc, manually?
<hcarty>
The line in question starts __extension__ ... and defines a __int64_t typedef
<hcarty>
Or anyone else using camlidl, for that matter...
<hcarty>
flux: Have you ever received this error from camlidl: File /usr/include/bits/types.h, line 50, column 0: syntax error
2007-08-20
<hcarty>
thruspa: ;; isn't usually needed outside of the toplevel from what I've seen/understand
2007-08-19
<hcarty>
Yes... I'll likely use at least parts of it in my grad research, but I'm not sure how much others will care with Scilab/Octave/etc already out there
<hcarty>
So it has OCaml's benefits
<hcarty>
The main benefit I see in Psilab is that it's really just a collection of OCaml modules
<hcarty>
e
<hcarty>
That would be my personal reasons for us
<hcarty>
Yes, I think so
<hcarty>
bluestorm: I'm not sure if it's still in use
<bluestorm>
hcarty: what's Psilab ?
<hcarty>
Only updated such that it will compile with gcc 4.x... it is still using its own OCaml 3.01 copy
<hcarty>
Is anyone here interested in a (slightly) updated Psilab tarball?
2007-06-06
<hcarty>
gunark: I haven't used the fftw bindings, but that may be some C wrapper function that is part of the fftw bindings
2007-05-24
<hcarty>
flux: Thank you for your help earlier with my segfault issue. That fixed a problem I've had for quite a while now.
<hcarty>
Any ideas on what might cause a simple OCaml program to segfault when compiled to native code but not bytecode?
<hcarty>
Unless one is a scientist or mathematician
<hcarty>
Well, perhaps outside of science and math that's true
<hcarty>
Unless all of the load is in a few heavy number-crunching routines. Then I'm guessing that better handling of such abstractions would matter significantly less.
<hcarty>
Smerdyakov: Well, I think your background is a little more suited to a detailed analysis of the situation
<Smerdyakov>
hcarty, my understanding is that it has to do with no program analysis in the OCaml compiler!
<hcarty>
I am not a compiler or language expert, but my understanding is that a lot of it has to do with the extras OCaml provides
<hcarty>
slacker403: Depending on the operation(s) being performed and the programming methods used I think that is pretty normal
2007-05-22
<hcarty>
Smerdyakov: Yes, quite :-)
<hcarty>
and 1L is Int64
<hcarty>
Yep, it is
<hcarty>
mrvn: I think 1l is Int32
2007-05-20
<hcarty>
It doesn't have much on the 3.10 updates though
<hcarty>
elean: I've toyed around with similarly simple OCaml CGI under a Debian + Apache system and it worked
<hcarty>
Is the OCaml 3.10 release final now? It looks like it is on the site, but I haven't seen anything on the list(s)
2007-05-11
<hcarty>
flux: Very true re: wrappers. The C interface is a large part of what drew me to OCaml
<hcarty>
In which case it just becomes a painful necesary evil.
<flux>
hcarty, they need to be quite large libraries, writing wrappers isn't that difficult
<hcarty>
flux: Unless you have to interface with libraries written 10s of years ago...
<hcarty>
mrvn: Doesn't Str have something like that? Is Str.split what you want?
<hcarty>
LeCamarade: There's always ExtLib
2007-05-04
<hcarty>
That can be saved and "#use"d from the toplevel as-is
<hcarty>
mrvn: If you're interested, here's what I've come up with in a self-contained example: http://rafb.net/p/YN0upt86.html
<hcarty>
If I break up the bigarrayfun type in to a few types it looks like I may be able to make this work
<hcarty>
So I'm probably losing some step in the complexity
<hcarty>
mrvn: let apply baf = apply_f (baf.f, ...) doesn't seem to work either. But, as postalchris said, I think this is an issue of having a long type list
<hcarty>
mrvn: I'll give it a shot
<mrvn>
hcarty: you could probaly do let apply baf = apply_f (baf.f, baf.f, baf.f, baf.f, ....)
<hcarty>
Yes... I think I'm going to stick with the apply (f,f,f,f,f,f,f) method for the time being
<postalchris>
hcarty: the problem is that you have a function w/ cross-dependencies on 5 or 6 types. This is do-able, but it's just mind-numbingly complex...
<hcarty>
"This expressions has type int32 but is used with type int"
<hcarty>
mrvn: That ends up with problems when you include Int32 and Float* in the apply function though
<hcarty>
mrvn: Ah, ok. Odd, but that makes sense.
<hcarty>
postalchris: I'm trying to find a function which can be applied given the code you pasted
<mrvn>
hcarty: in the later cas you have different functions and each gets applied to only one type.
<hcarty>
Which confuses the heck out of me given that the apply (f,f,f,f,f...) method works
<postalchris>
hcarty: but you don't need to explicitly define a function of type 'a foo -> 'b, you just write it such that it doesn't force a choice for 'a or 'b...
<postalchris>
hcarty: I too am finding the OCaml is a bit squidgy about these function types...
<hcarty>
Or applying.. whatever the proper terminology is
<hcarty>
Yes, when calling app_to_bigarray
<hcarty>
Just using something like Bigarray.Genarray.get doesn't work, it gives me the "...is less general than..." error
<hcarty>
mrvn: Sorry, I don't think I was clear. From here: http://rafb.net/p/ldONta57.html I don't know how to write a bigarrayfun
<hcarty>
The leading 'a is the part I don't know/understand
<hcarty>
postalchris: How would I define a function 'a foo -> t -> 'a? Syntax-wise.
<hcarty>
It was a syntax issue ... I didn't know how to use the "." and didn't find anything in the manual about it
<hcarty>
postalchris: Excellent! Thank you very much.
<hcarty>
mrvn: I ran in to that same problem yesterday
<hcarty>
I think so. I'm still relatively new to OCaml though, so it's taking me some time to trudge through it
<postalchris>
hcarty: well, your application is much more complicated that the list example, but isn't what you want something like "type 'a bigarrayfun = { f : 'b 'c . ('b, 'c, Bigarray.c_layout) Bigarray.Genarray.t -> 'a }" ?
<hcarty>
It's a little ways down the page, "wrapping parameterized types"
<hcarty>
I'll be working on that today for a while
<hcarty>
postalchris: Yes, though I'm not sure how to apply it to my case
<postalchris>
hcarty: you catch the existential type parameter post on caml-list?
2007-05-03
<hcarty>
pango: I'll have to read that section of the manual 3 or 4 more times and toy with small example problems.
<pango>
hcarty: they're often used where templates would be used in some other languages (but they rely on polymorphism)
<hcarty>
I'm heading home for the day. Thank you all for your help and time!
<pango>
hcarty: functors are function in the module space (= functions that take module(s) and return a module)
<hcarty>
pango: Is the idea behind the functor approach to keep the matches when you don't know the type at compile time, but be able to clean them up for cases where you do?
<hcarty>
pango: Do you have any pointers to examples? Implementing functors has been a difficult hurdle for me.
<pango>
7 in the case of hcarty, if I count well
<hcarty>
postalchris: Thanks, I was thinking of doing the same
<postalchris>
hcarty: I just sent this out to the caml-list. It seems we can all agree this behavior is too weird not to seek out an explanation.
<hcarty>
The last thing I heard about that was that you can only push the type inferencing to be more restrictive, not less. But I don't remember the source, so I don't know its accuracy.
<hcarty>
or, fs. Whatever is the proper plural there.
<hcarty>
Across all f's
<hcarty>
mrvn: No, the inferred type is the same then
<mrvn>
hcarty: can you add an "let apply f = apply (f,f,f,f,f,f,f,f,f)" below that?
<hcarty>
postalchris: Thanks! Your apply works for my case as well. Not ideal, but better.
<hcarty>
mrvn: I don't understand it either. I've been struggling with it and finally gave in to lots of ugly matches
<hcarty>
postalchris: Cool. I'll give that a shot. It would clean things up greatly, even if it it's not completely ideal
<hcarty>
postalchris: I don't have a generic apply which works, sadly
<postalchris>
hcarty: I've bumped into this problem recently too. OCaml can't deal with parameterized types across a match like this. What is your version that works?
<hcarty>
I get the same error
<hcarty>
But oddly enough, if f is defined within apply then the problem goes away
<hcarty>
mrvn: How would I apply the Hdf.t type for that? I can paste my current definition.
<mrvn>
hcarty: Define a Hdf.apply : ('a Hdf.t -> 'b Hdf.t) -> 'a Hdf.t -> 'b Hdf.t
<hcarty>
mrvn: Yes, I don't like the constant matching over all of those types.
<mrvn>
hcarty: Thet "match a with" is really ugly but I can't think of an ocaml way to do this without matching.
<hcarty>
mrvn: That's what I thought. I struggled with this for a long while trying to find a prettier way.
<hcarty>
k
<hcarty>
When the data is read from the file on dis
<hcarty>
But for some instances the type really won't be known until runtime
<hcarty>
If it has to be in separate interfaces then that's ok with me
<hcarty>
I'd like to support both
<hcarty>
mrvn: It depends
<hcarty>
mrvn: Nice, thanks. I'll give that a shot.
<hcarty>
I'm trying to clean it all up now and do things more cleanly and properly
<mrvn>
hcarty: Why not an find ('d -> 'a -> 'd) -> 'd -> ('a, 'b, 'c) Bigarray.Genarray.t -> 'd?
<hcarty>
It's a round-about way of doing things, but as I said it was done in a rush and while I was learning OCaml.
<hcarty>
mrvn: re: contents - After creating the bigarray, I pass that back to C-land and then pass its data pointer to the appropriate HDF library function
<hcarty>
mrvn: re: f - I used that so I could pass in min or max for this case
<mrvn>
hcarty: and the contents of the bigarray?
<hcarty>
This has been put together piece by piece and in quite a rush up to this point, so I was passing a string ("INT8", "FLOAT32", etc) back to OCaml and then matching that to a Bigarray type
<mrvn>
hcarty: That is what I would do. How else would you pass the values to ocaml?
<hcarty>
mrvn: Would I have to allocate the Bigarray in the C-portion of the library to do this?
<mrvn>
hcarty: Then passing the Bigarray on should be enough. No need for the Hdf type anymore.
<hcarty>
The HDF C library tells me (via some integer constant) what type the data has. I use that to allocate a Bigarray of the proper type and size.
<hcarty>
mrvn: Can that be checked in OCaml then? How would I represent that in the interface?
<hcarty>
mrvn: It is. But the bigarray has to be created at some point.
<mrvn>
hcarty: The Hdf.Int8 (or whatever) has to match the Bigarray kind. Isn't that stored in the Bigarray?
<hcarty>
mrvn: let new_a = ... is just to reshape the Bigarray to 1D from nD.
<hcarty>
mrvn: Nothing. I was just looking for some ideas on a possibly better way of implementing it.
<mrvn>
hcarty: What is the problem with the code you pasted?
<hcarty>
For example, one current use is aggregation of a few data sets. A section of every data entry in each HDF file is pulled and written to a new tile.
<hcarty>
malc_: mrvn: The type may not be known until run-time
<malc_>
hcarty: erm.. you interrogate your original array with Bigarray.Genarray.kind and use that afterwards
<mrvn>
hcarty: Doesn't the calling side know the type?
<hcarty>
I may be missing something, but I haven't found a way to make that generic without the method I'm using
<hcarty>
malc_: My plan is to make it possible to have a generic data reading function which picks the appropriate type depending on which field is read from the file
<malc_>
hcarty: btw. i wonder why you need all this tagging (in light of Bigarray.X.kind)?
<mrvn>
hcarty: Bigarray has a function to ask for the number of dimension and so on and with that you can easily write an bigarray_fold
<pango>
hcarty: the use of functors won't make your sum type go away
<hcarty>
I do appreciate the tips. I'm still quite new to OCaml.
<hcarty>
Now that I can respect!
<hcarty>
Thanks for the elitism over a silly mistake though
<hcarty>
Drop-down menu selections are overrated
<hcarty>
malc_: Yes :-) That's just a temporary placeholder. I used it, then realized that it's already defined elsewhere.
<hcarty>
That match ... command in the paste shows the file types that are currently usable.
<malc_>
hcarty: one day redefinition of @ will bite you
<hcarty>
Satellite data sets in my case
<hcarty>
This is all for and related to the HDF library, which is a library for reading/writing large binary files.
<hcarty>
I wouldn't mind using them, but I'm not sure how I would since the data type isn't known until it's read from disk
<hcarty>
pango: I have, but to be honest they're still a bit opaque to me
<pango>
hcarty: I guess Hdf.get checks the constructor of its first argument ? That must kill performance
<hcarty>
I don't mind having separate functions for ints vs floats. I'm just trying to work out the logic and it's more than my brain wants to tackle this evening it seems.
<hcarty>
pango: The values will be ints or floats
<hcarty>
pango: Sorry, yeah - I suppose that wasn't very clear :-) Just wondering about a recursive fold_left-like approach.
<pango>
hcarty: unless you know properties about the values in your array, the only way I know to find min and max values is to scan the whole array, keeping smallest and biggest values as you go...
<pango>
hcarty: what's the question ? :)
<hcarty>
I could reshape it to a 1D bigarray, but it's wrapped in a variant type so that could become very verbose
<hcarty>
It's getting late and my head isn't wrapping around this problem very effectively.
<hcarty>
Specifically I'm looking to find max and min values in a Bigarray .. so the program will know the dimensions at run time but not compile time
<hcarty>
Does anyone here have some pointers on finding a special value (min, max, whatever) within an array of arbitrary dimensions?
2007-04-30
<ita>
hcarty: not needed *grin*
<hcarty>
The lack of toplevel support is also unfortunate
2007-04-29
<hcarty>
lucca: You're welcome. I hope it works for you.
<lucca>
hcarty: thanks!
<hcarty>
That has a backup/extra copy of most, if not all, of the Godi-required files
<hcarty>
Smerdyakov: My apologies -- I started typing in the wrong window
<hcarty>
tree_: Don't mind him. Ask away.
2007-04-27
<hcarty>
The "do_something" function takes orders of magnitude longer with x coming from a variant type than it does with a Bigarray created and passed in directly
<hcarty>
Sure, I'll make a small example and put it on a paste site
<hcarty>
The result seems to be killing performance in untouched code, so I'm a little concerned by this
<hcarty>
I'm in the middle of moving a library over to using variant types containing various Bigarray types rather than the user having to define and pass in a Bigarray
<hcarty>
Is this normal? Does a performance hit from variant types carry along with everything touched by it/them?
<hcarty>
I'm extracting a Bigarray from a value with a variant type, and actions on the extracted Bigarray are very slow compared to a raw Bigarray
2007-04-24
<benny99>
hcarty: oh
<benny99>
hcarty: hm... maybe I should try to implement a merge sort or something, because insertion sort is not really the sort for functional languages ?
<hcarty>
benny99: But that's a good point - lists are immutable in OCaml, while arrays are not
<hcarty>
mrvn: benny99 had the question, but thanks
<mrvn>
hcarty: you can't insert into a list so you have to always copy the full list. List.fold_left is your best option then.
<hcarty>
I can't help with that one, but someone may have an answer - sometimes it can take a few hours, but the answers are usually quite good when they come.
<benny99>
hcarty: yeah, have been thre, but I didn't find libref :Z
<benny99>
hcarty: you meant List.tl (List.hd l) ;P
<hcarty>
Sorry, I mean List.hd (List.tl l)
<hcarty>
benny99: I don't know if this is the best way, but: List.hd (List.hd l)
<benny99>
hcarty: ok, so I start with an easy one
<hcarty>
benny99: If you start a discussion, people may join in. Things tend to be quiet around here until someone asks a question.
2007-04-05
<hcarty>
Curses... another HDF-hopeful and I missed them
2007-03-27
<hcarty>
theneb: In general, I think the material available online is your best bet
2007-03-23
<hcarty>
cmvjk: I think it is
2007-03-22
<hcarty>
I'm currently using variant types and pattern matches, and it looks like functors will make for cleaner code
<hcarty>
Since the data can be in many formats (at least everything that Bigarrays support) there is a large range of types to implement
<hcarty>
This is for an OCaml wrapper for the HDF library, so the primary goal is reading/writing large data sets
<hcarty>
malc_: Ok, I understand
<malc_>
hcarty: well with C++ when you instantiate template with a praticular type you effectively are getting new code specialized for this type, current ocaml implementation can not do it, so there's a cost of maintaing separate compilation
<hcarty>
malc_: Somewhat, at about an undergrad CS course level
<malc_>
hcarty: are you familiar with c++ templates?
<hcarty>
malc_: I apologize, I don't know what you mean by specialization. Do you have a reference, or some extra context I can use to look up the term?
<malc_>
hcarty: there's no specialization whatsoever, the impact can be judged by this fact alone
<hcarty>
love-pingoo: Ok, thanks. The code in question works with various Bigarray types, and from asking around previously it seems that variant types and functors are my two options for implementing this
<love-pingoo>
hcarty: it shouldn't be too bad
<hcarty>
But I'm concerned by some of the speed issues I've seen advertised here and elsewhere
<hcarty>
I think I'm close to figuring out how to use them, and they have the potential to clean up my code significantly
<hcarty>
What level of performance hit is involved when using functors in OCaml? Where and when do these hits occur?
<hcarty>
Best of luck with it
<hcarty>
That's unfortunate
<hcarty>
So just looking for ideas :-)
<hcarty>
I'm working on a C-library binding as well, and while it works in bytecode/toplevel, native code segfaults
<hcarty>
Ah, ok. Understood.
<hcarty>
cmvjk: May I ask what the first segfault problem was?