<hcarty>
I will certainly provide what feedback I can. It sounds promising.
<gildor>
hcarty: thx, if you have problems, don't hesitate to ask, this is still beta quality
<hcarty>
gildor: Congratulations on the first OASIS release! I hope to give it a shot with some small projects over the next day or two.
2010-04-04
<hcarty>
And the comment about 1970's programming
<hcarty>
oops - that was meant to be "rwmjones++ for the new xavierbot release"
<hcarty>
rwmjones
2010-03-24
<Camarade_Tux>
hcarty_: tried the toplevel with lwt?
<Camarade_Tux>
hcarty_: hmmm, here is your prize for the week's dirtiest work-around :P
2010-03-23
<hcarty>
Good night again all!
<hcarty>
Camarade_Tux and thelema: Just wanted to stop back momentarily to say that I worked around it by symlinking the system inconv.h to a directory under $HOME and adding that to C_INCLUDE_PATH. With that, ocaml-text and Lwt 2.0.0 built properly, and the Super Cool Lwt Toplevel works as advertised.
<sc30317>
thanks hcarty
<hcarty>
sc30317: Good luck with your project!
<sc30317>
see you hcarty
<thelema>
hcarty: cheers
<hcarty>
I'm off for the evening. Thank you Camarade_Tux and thelema for your help
<hcarty>
ls(w_current) is the same as writing lp w_current
<hcarty>
(lp w_current)
<hcarty>
sc30317: What Camarade_Tux said :-)
<hcarty>
sc30317: However you want. printf, print_endline, ...
<hcarty>
derdon: I do as well
<hcarty>
sc30317: Also, you should use = and not ==
<hcarty>
sc30317: And it looks like you are not using all of the elements of the list (List.tl l = [])
<hcarty>
sc30317: That looks ok, but you likely want to do something with the returned string
<hcarty>
thelema: Thanks. I thought it was something like that.
<hcarty>
I see it in pastes in here often. Probably a lack of font configuration or something of that sort.
<hcarty>
I'm not sure what the issue is. There are "highlighted I" characters.
<sc30317>
hcarty, sure
<hcarty>
sc30317: pastebin?
<hcarty>
sc30317: Probably? The formatting was a little messed up in my terminal so I'm not sure.
<sc30317>
hcarty, if I did that function like we said earlier
<hcarty>
Hard-coded "/usr/include/iconv.h" does the trick
<Camarade_Tux>
hcarty: bah =/
<hcarty>
It is certainly not by choice
<hcarty>
Camarade_Tux: Again, due to not having admin rights. I'm hoping this will change (Windows).
<hcarty>
Camarade_Tux: I am, sadly, working under Windows and connecting remotely to the dev machine. A sad state :-)
<hcarty>
-nostdinc looks like one heavy-handed possibility
<hcarty>
Camarade_Tux: Fair point. Drat.
<hcarty>
How do I override that? Short of bribing the IT folks to delete it out from whoever is using it...
<hcarty>
Or have not figured out why
<hcarty>
But I can't figure out why
<hcarty>
Camarade_Tux: After some more digging, it looks like ocaml-text is compiling against the wrong iconv.h
<Camarade_Tux>
hcarty: well, I guess ocaml-text relies on iconv functions to come with libc which will make them always available without the need for a special switch
<hcarty>
Also, though, you can match the list directly without using List.hd and List.tl
<Camarade_Tux>
hcarty: the _tags file has: <src/text.cm{,x}a>: use_libtext
<hcarty>
You almost always want to use = and <> rather than == and !=
<hcarty>
Remember that = and == are different monsters
<hcarty>
Depending on the logic flow you want
<hcarty>
sc30317: Or (List.tl l = [])
<hcarty>
sc30317: You likely want (List.tl l <> [])
<sc30317>
hcarty, can I not do this?
<hcarty>
sc30317: (1) you are comparing a function with a list
<hcarty>
A strange problem
<hcarty>
There is no mention of iconv anywhere in the ocamlbuild compilation log or make/ocamlbuild output.
<hcarty>
"it" being ocaml-text
<hcarty>
The build seems to go fine, compiling with it ("make tests" or trying lwt) fails
<hcarty>
That's what I am trying now.
<hcarty>
That's what is confusing me. As far as I know, it shouldn't be picked up. But I'm probably missing some environment variable or system configuration file.
<hcarty>
Just make + ocamlbuild
<hcarty>
No autoconf here
<hcarty>
Yes, /usr/include/iconv.h is provided by glibc here. I wonder why it is trying to link against a libiconv then.
<hcarty>
Does gcc automatically pick up LDFLAGS?
<hcarty>
Sleep well!
<hcarty>
Camarade_Tux: Thanks, I'll see what I can find out from there
<hcarty>
The system is running RHEL 5.x. There does not seem to be an official libiconv package for it.
<hcarty>
But I do have to work/develop on it
<hcarty>
No, not one I run/admin
<hcarty>
I wish I knew :-)
<hcarty>
Camarade_Tux: Sorry - yes, libiconv was installed from source (from what I understand) in /usr/local/
<hcarty>
Camarade_Tux: It was installed from source
<Camarade_Tux>
hcarty: you're sure you have the "-dev" package for libiconv?
<hcarty>
Yech... what is a decent pastebin that isn't dripping with banners?
<hcarty>
Camarade_Tux: :-) One moment, just need to get back to a pristine, original error state
<hcarty>
But I have had the same problem with OCaml + C stubs in the past. rpath and similar library path settings are difficult to get right in the generated dll*.so files.
<hcarty>
None of LD_FLAGS, LD_LIBRARY_PATH, CAML_LD_LIBRARY_PATH seem to help
<hcarty>
unfortunately
<hcarty>
thelema: I do, but it is in a non-standard location. And unforunately on a machine over which I have no administrative control
<hcarty>
Camarade_Tux: The C-stubs from ocaml-text are not linking to/find libiconv
<hcarty>
Camarade_Tux: Ah, ok. So likely an error on my part :-) I'm not sure how to use the toplevel as lwt won't build for me without a proper ocaml-text build
<hcarty>
But the linking errors I get are all from ocaml-text
<Camarade_Tux>
hcarty: how should I test the toplevel? everything built find
<hcarty>
It is
<hcarty>
Without rlwrap, etc.
<hcarty>
lwt uses it to provide a toplevel with line editing, history, completion, etc.
<hcarty>
thelema: Yes
<hcarty>
I'm getting libiconv linking errors and trying to determine if I have something misconfigured
<hcarty>
thelema: Have you tried ocaml-text on its own? (Apparently a requirement for the lwt toplevel)
<hcarty>
Or, of course, my system is broken. But I think my system is ok...
<hcarty>
Does the combination of ocaml-text + lwt build from GODI for anyone here? I would like to play with lwt's super-cool toplevel, but something in the build process seems broken.
2010-03-20
<bluestorm>
hcarty noticed that you use "let is_finished ... in if FINISH = TRUE then ..."
<bluestorm>
also, after the error hcarty noticed, there is a problem with your "w_current"
<hcarty>
That isn't a syntax error, but it will give an error (eventually)
<hcarty>
sc30317: But you aren't comparing the result of compare_vc_current
<sc30317>
hcarty, compare_vc_current_class returns true if vector_class and current_class are the same
<hcarty>
What specific error?
<hcarty>
sc30317: In your latest post, you are trying to compare a function (finish) with a boolean (true)
<hcarty>
sc30317: What error are you getting?
<sc30317>
hcarty, I am pretty sure that i am extremely close to having this right
<sc30317>
hcarty, I have looked through some documentation on this subject, it doesn't seem to help
<hcarty>
sc30317: Would some documentation/tutorial references help?
<hcarty>
I'm not sure where you would call it as I don't know what the function is supposed to do
<hcarty>
Also, you are missing an "in" at the end of what appears to be the definition of new_w
<hcarty>
You don't though
<hcarty>
finish does not call itself
<sc30317>
hcarty, because it needs to be a recursive function
<hcarty>
sc30317: Why is finish declared with "let rec"?
<hcarty>
bluestorm: Thank you for the suggestions
<hcarty>
bluestorm: I may leave both. Hiding the underlying functor application is not turning out to be as simple as I had hoped
<bluestorm>
hcarty:
<hcarty>
For example, provide Foo.Make, Foo.C_interface, Foo.Fortran_interface and/or provide Foo.C (= Foo.Make(Foo.C_interface)), Foo.Fortran (= Foo.Make(Foo.Fortran_interface))
<hcarty>
s/function/functor/
<hcarty>
There are only two possible variations for this module. Is it better to expose the functor interface to the user, or apply the functor ahead of time to the two possibilities and hide the fact that this uses a function with the module's interface?
<hcarty>
bluestorm: I used it in this case to reduce code duplication for c_layout and fortran_layout Bigarrays
<hcarty>
bluestorm: That's a good idea
<bluestorm>
hcarty: I sometimes use functors to get incompatible abstract datatypes
<hcarty>
Just completed my first real use of functors as a module writer rather than as a module consumer. Nifty stuff.
<hcarty>
flux: That is my guess
<hcarty>
Sorry for the noise. I was getting "Cannot send to channel" errors from irssi. A restart seems to have fixed it.
<hcarty>
Testing...
2010-03-14
<mrvn>
hcarty: The GC should be fixed to have a seperate heap for floats that is aligned.
2010-03-13
<hcarty>
At least for (double precision) floating point
<hcarty>
eldragon: Really? I had heard the opposite
<hcarty>
Or, rather, the Jason Hickey (Cal Tech) book
<hcarty>
mooglenorph: forge.ocamlcore.org hosts a large number of OCaml libraries
2010-02-10
<hcarty>
It was in Batteries-old, added some time during the development process there
<hcarty>
flux: Seq.* can fill in for now, with "let ( -- ) a b = Seq.init (b - a + 1) (fun i -> a + i)"
<hcarty>
Bitten again by the imperative enum! "let foo = 1 -- 10 in bar foo; baz foo"
2010-02-09
<hcarty>
thelema: I need to leave as well, but I like the idea of a Batteries.Labels (or similar) option, as well as a Batteries.Exceptionless option.
<hcarty>
One day, Batteries 2.0 will come along and save us all :-)
<hcarty>
thelema: Will PMap be kept around for 1.0.x compatibility?
<thelema>
hcarty: exactly
<hcarty>
An "include" in the .mli, dragging in ocamldoc comments with it, would be a nice thing to have.
<hcarty>
Very nice
<hcarty>
Oh - what happens to Map?
<thelema>
hcarty: umm, PMap -> Map
<hcarty>
thelema: PMap -> Map.PMap, bug fixes, tap - what else is new/planned for 1.1?
<hcarty>
thelema: Cool, thank you
<hcarty>
Should I submit a bug report/feature request?
<hcarty>
Oh well - I'll have to grab the (key, value) enum and sort on that
<hcarty>
Thanks for the clarification
<hcarty>
Looks like it - I'm just not sure I was following the logic of the enum function correctly
<hcarty>
Right
<hcarty>
Good, thank you
<hcarty>
thelema: Do you know if the keys and values functions from the BatMap modules give their results in sorted order, like in the iter and other functions?
2010-02-08
<hcarty>
flux: The Batteries.Seq/BatSeq module provides a functional, somewhat Enum-like alternative
<hcarty>
mfp: And then return a module with the result?
<mfp>
or uh both. Found this old codepaste of mine > http://ocaml.pastebin.com/m3a586d5b hcarty: you have to pack both the value and the module inside a 1st class module
<hcarty>
Hopefully there will be lots of bright, shiny new toys to try out in the months following the release of 3.12
<hcarty>
It's a scoping issue according to the error message. I wonder if there is a way around that.
<hcarty>
with "module type M_sig = sig type 'a t val map : ('a -> 'b) -> 'a t -> 'b t end"
<hcarty>
It seems that this doesn't work: "let add_one m x = let module M = (val m : M_sig) in M.map (fun i -> i + 1) x"
<Camarade_Tux>
hcarty: I think Alain Frisch sent an example on the caml list a few days again
<flux>
hcarty, you can implement PMap in terms of Map for one without relying on unsafe operations
<hcarty>
Ah, there is a trunk/test/fstclassmod.ml file which seems to use it, even if the use isn't particularly commented.
<hcarty>
flux: Well that's good to know :-)
<hcarty>
Does anyone here have a link to an example using OCaml's first class module support (still in SVN trunk)? I am curious to see what the implications of this are.
2010-02-05
<hcarty>
travisbrady: You're welcome. Hopefully the "-thread" part can be automated at some point.
<travisbrady>
hcarty: ahh, that did it, thank you. I keep forgetting the -thread bit
<hcarty>
thelema: Is there a module naming standard for Batteries now? I remember there was a decision to use Names_like_this rather than NamesLikeThis at one point, but I have been out of the loop for a few months.
<hcarty>
thelema: Yes, the Print module and related functions are wonderful in that regard. I think the syntax extension just needs a little cleanup.
<thelema>
hcarty: I really like *.print because of the ease of printing complex structures
<hcarty>
Just missing proper support for field widths IIRC
<hcarty>
Though the Print.* module + syntax is really wonderful
<hcarty>
I think I will just do without the Batteries extensions for now. I don't use them much at this point.
<hcarty>
thelema: I'm glad to help where I can
<thelema>
hcarty: thank you for helping me correct this.
<thelema>
hcarty: fix for Array's extra functions pushed to git.
<hcarty>
It worked with Batteries-old, but there was a lot more boilerplate there.
<hcarty>
I don't need/want credit. And that's a very odd result :-)
<hcarty>
thelema: No, they don't
<hcarty>
thelema: I can send a patch if desired, though I'm not sure why that line is there.
<hcarty>
Commenting out line 77 of battop.ml "fixes" the mixed syntax issue. Which is odd, since that line seems to set the syntax to standard...
<hcarty>
thelema: Ok, thanks. That makes sense.
<hcarty>
As batteries.ml does?
<hcarty>
thelema: Ok - so the BatList module structure of "open on top of stdlib List" is the Batteries Way?
<thelema>
hcarty: legacy code in batArray - for some reason we have a lot of [let foo = foo] in BatArray
<hcarty>
thelema: I don't want to report bugs without understanding the philosphy behind these decisions
<hcarty>
Is there a reason BatArray.iter exists but BatList.iter does not?
<hcarty>
thelema: But BatList.iter does not exist
<hcarty>
"# [1;2;3];;" --> "- : list int = [1; 2; 3]"
<thelema>
hcarty: the documentation lists only the functions that are provided in batteries
<hcarty>
But types are reported in revised.
<hcarty>
Input is in the normal syntax
<hcarty>
The included ocamlinit and battop.ml also seem to put the toplevel in a semi-revised syntax state
<hcarty>
It's a subtle hint :-)
<hcarty>
Batteries.List.iter exists, but batteries.ml uses "module List = struct include List include BatList end"
<hcarty>
That is my guess
<hcarty>
BatArray.iter is there
<hcarty>
Odd suddenly became less odd
<hcarty>
flux: Hmm - how odd. "module L = struct include BatList end L.iter;;" doesn't work here (Batteries 1.0.1)
<hcarty>
Judging from the documentation, I'm not sure what the intent is
<hcarty>
s/are/is/
<hcarty>
If not, then BatList.iter (and possibly other list functions) are missing
<hcarty>
thelema: Or should they both be 'include'd in a new List module?
<hcarty>
thelema: Is the Batteries module BatList meant to be a replacement for List?
2010-02-01
<hcarty>
Making the entire module a functor should work as well I think, though I'm not sure if that is less work than making the layout a required argument for the appropriate functions
<hcarty>
thelema: Same result, sadly
<hcarty>
Yes, I was hoping the easy optional argument way would work. But it looks like I need to stick with normal arguments.
<hcarty>
thelema: Ok, thanks. I'm not sure, I was hoping there was some type system magic I missed :-)
<thelema>
hcarty: I don't think you can do that - how would you recover the missing polymorphism?
<thelema>
hcarty: thank jharrop for the idea.
<hcarty>
I think this is a FAQ somewhere, but I haven't found it...
<hcarty>
thelema: That seems like a logical change
<hcarty>
Is it possible to create a function along the lines of (open Bigarray let f ?(layout = c_layout) x = Array1.create float64 layout x) and have the argument "layout" stay as "'a layout" rather than staying fixed as "c_layout layout"?
<thelema>
hcarty: thanks. I've got some changes I want to make in the Set structure for 1.1
<hcarty>
thelema: Very nice work on the refactored Batteries btw. I've been dormant for a while, but I've been toying with 1.0 a bit and the new structure seems nice.
<hcarty>
As it is, every element needs to be computed before the list can be built.
<hcarty>
Alpounet: Indeed
<hcarty>
infoe: I don't think so - IIRC the recursive call to aux would have to be on the left of the ::
2009-11-19
<mattiase>
hcarty: One strategy is doing something boring but not overly time-consuming - a 9 to 5 job - that will make you eager to do some serious hacking when you get home. Another is to find an Enlightened Employer that allows you to spend time on fun things. A third is to start one, which Yoric[DT] did.
<hcarty>
mattiase: It does, sadly, require finding someone who wants to pay you for doing what you want. You still need to chase the money, just like in academia.
<mattiase>
hcarty: If only!
<hcarty>
As Yoric[DT] mentioned - sometimes it is the best way to do what you want to do :-)
<hcarty>
Oh, I certainly have nothing against industry.
<Yoric[DT]>
hcarty: it's quite fine, thanks.
<hcarty>
How is life in industry? :-)
<hcarty>
I'm doing well, thank you. And you?
<hcarty>
Yoric[DT]: Howdy
<hcarty>
thelema: ping
2009-11-18
<hcarty>
I understand if that's the case. It looks like you have a very nice start here.
<hcarty>
thelema: Or would you prefer for all camlp4 to remain separate from aaa?
<hcarty>
thelema: Are you opposed to, at some later point, adding back the camlp4 magic pieces as optional and not-on-by-default components?
<thelema>
hcarty: I know nothing about godiva - everything non-obvious was made up.
<hcarty>
thelema: I can try with the godiva spec file as well
<hcarty>
thelema: Correct. I omake'd it directly.
<hcarty>
The camlp4'd print system is very nice, but it still needs polish
<thelema>
hcarty: I assume you didn't use godi to install it, right?
<hcarty>
thelema: .0 builds and installs cleanly here (GODI, OCaml 3.11.1, 64bit, Ubuntu 9.10)
<hcarty>
thelema: Hooray! :-)
<hcarty>
thelema: I see references to IO - is the IO system in aaa?
<hcarty>
Alpounet: Thanks for the tip
<Alpounet>
hcarty, to have the 'doc' target working you just need to do a 'mkdir hdoc' before running 'omake doc'
<hcarty>
Well, that's certainly a quick build :-)
<hcarty>
"omake all" and "omake install" for now?
<thelema>
hcarty: I appreciate any feedback on installation.
<hcarty>
I'll give it a try as well then
<hcarty>
thelema: Should aaa be installable alongside Batteries?
<thelema>
hcarty: thanks. I've still got a lot of polishing to get it anywhere near the quality of batteries
<hcarty>
thelema: Congratulations on a first release!
2009-11-14
<hcarty>
Camarade_Tux: I think that may solve the issues I was having - I don't think that copied over all of the opttoploop.* modules. With those, perhaps findlib + ocamlnat will work.
<hcarty>
flux: Yes, that is a major downside to the general findlib support in myocamlbuild.ml
<hcarty>
Alpounet: pong
<Alpounet>
hcarty, ping ?
2009-11-12
<mrvn>
hcarty: we live to serve
<hcarty>
mrvn: Thanks again for pointing out the flaw in my try_finally function a few days ago. I fixed it and it helped me track down a rather obscure bug I've been facing.
<hcarty>
mrvn: That would certainly be nice.
<mrvn>
hcarty: And that is something I would add to the compiler directly.
<hcarty>
mrvn: Yes, as long as Foo.print_t is defined.
<hcarty>
I think ocamldebug gives Std.dump-like output. It's been a while since I've used it though.
<mrvn>
hcarty: %{Foo.t}" too?
<hcarty>
Allowing for things like (Print.sprintf p"%{int array list option}\n" foo)
<hcarty>
The Batteries.Print.* functions, along with the associated syntax extension, provide some very nice pretty print boilerplate.
2009-11-11
<hcarty>
Xteven: You would either need to write one for the data structure in question, or use one of the existing automatic printers around.
<hcarty>
thelema: Sorry, wrote too soon :-)
<hcarty>
thelema: Unless they are supposed to implement their own list implementation?
<hcarty>
razel: As thelema pointed out, you can get the first element of the list and the remainder of the list a few different ways.
<hcarty>
razel: A "list" in OCaml is a linked list
<ygrek>
hcarty, everyone would use it if it existed :)