<hcarty>
gist updated with Format-friendly functions for Enum, List and Array values
<thelema>
hcarty: true, although you'd have to do the string breaking beforehand, basically losing most of what Format would help with
<hcarty>
or pp_print_as
<hcarty>
Format.print_as could be helpful too
<hcarty>
If that's provided already then it may provide a relatively nice way to implement a Perl6::Form-like interface.
<hcarty>
I'm looking through the documentation now...
<hcarty>
thelema: That sounds reasonable. Do you know if it's possible to create fixed-width boxes for Format?
<hcarty>
thelema: My enum use is usually in the form of ( -- ), ( --. ) or a few custom Calendar-based versions of the same.
<thelema>
hcarty: as for format + batIO, the issue with format is that it has some internal state. the solution in stdlib is to stash that in the output channel
<hcarty>
thelema: It looks like format could be made to play with BatIO. I don't know how difficult/useful the result would be.
<thelema>
hcarty: FWIW, I only use enum, and whenever I need anything special I List.of_enum or Array.of_enum
<hcarty>
thelema: You're right, it doesn't mix nicely with the core Batteries IO. I'm not sure how to address that.
<hcarty>
thelema: Indeed... there are a lot of these
<hcarty>
wmeyer: It really seems that way (re: formatter):-)
<thelema>
hcarty: don't forget stream
<wmeyer>
hcarty: OK, might want to do it, as someday I want to start using it.
<hcarty>
wmeyer: An Enum/Seq/LazyList tutorial and comparison would be nice
<wmeyer>
hcarty: formatter is something special
<thelema>
hcarty: yes, but it doesn't mix properly with other IO
<hcarty>
thelema: Format.std_formatter = stdout
<thelema>
hcarty: yes, but who has a format output around?
<hcarty>
The output of (pp_enum ~first:"<" ~last:">" ~sep:"; " pp_print_int std_formatter (1 -- 100)) is a bit easier to read than the printf "%a" equivalent.
<hcarty>
thelema: The main use I'd see for them is easier to read debugging output.
<thelema>
hcarty: I'm not sure about format-targeted printers
<hcarty>
thelema: But I don't use enums very often. If I do I tend to be pretty explicit to (hopefully) avoid being bitten by their mutability.
<hcarty>
thelema: I'd rather have // as Filename.concat
<hcarty>
thelema: Those are probably the last updates I'll be able to do for at least a few days. But at this point I think BatBounded at least in a useful state.
2012-09-24
<hcarty>
Ah, I understand.
<hcarty>
pippijn: Or, rather, what sounds bad?
<hcarty>
pippijn: Don't like what?
<pippijn>
hcarty: that sounds bad
<hcarty>
thelema: Did gasche as well? I remember trying one of them and thinking that the results were very nice
<hcarty>
thelema: We'll have to make sure it is!
<hcarty>
So do I :-)
<hcarty>
I'll add some more documentation and look into more convenience modules/module types before submitting another pull request.
<hcarty>
thelema: Yes, definitely on both.
<hcarty>
Right
<hcarty>
True - assumes at the type level
<hcarty>
thelema: Just as an example
<hcarty>
thelema: Yes
<hcarty>
thelema: make ~-1 = 0 : SatI10.t
<hcarty>
Agreed
<hcarty>
Maybe not so sadly... it could make the code hard to follow
<hcarty>
thelema: No, sadly not without -ppx or camlp4
<hcarty>
flux: private int, private float, etc.
<hcarty>
I do think that some convenience functors for integers and floating point values would be worth providing
<hcarty>
thelema: The ready-to-use implementation of infix operators?
<hcarty>
nickyc: Or perhaps more likely s/linked/compiled/
<hcarty>
nickyc: Undefined global 'Unix' generally means that you are trying to use the Unix module but haven't linked against it.
<hcarty>
nickyc: Suspended <> Closed - Lots of reports have been suspended but not resolved. It means something along the lines of "it's an issue, but it's minor enough that we aren't likely to work on a fix until a better idea/patch comes along"
<thelema>
hcarty: not much real connection between this and BatBounded
<thelema>
hcarty: nice
<hcarty>
thelema: Something like that would allows for code like F10.(make 5.0 + make 6.0) evaluating to nan and N10.(make 5 + make 6) evaluating to None
<hcarty>
pngl: If a function is defined against the first definition of 'type' then it (generally) won't work against a later definition unless the function is also redefined
<pngl>
hcarty: thanks, that's it.
<hcarty>
pngl: It usually happens in the toplevel when a type with the same name is defined multiple times
<hcarty>
thelema: Thanks for the feedback
<hcarty>
You've pushed some warning fixes. I'm working on others
<hcarty>
Can do
<hcarty>
stdlib does
<hcarty>
Ok, I'll remove the external of_string
<hcarty>
thelema: batInt.ml lines 99 and 110
<hcarty>
?
<hcarty>
thelema: An unrelated Batteries topic - I'm cleaning up some of the warnings in master. BatInt.of_string is defined twice - once throwing Invalid_argument and once using the default Failure exception. The documentation says that it should throw Invalid_argument. Which version should stick around
<hcarty>
I didn't want to add too much until the core bits were in place
<hcarty>
thelema: That sounds like a useful and reasonable addition
<thelema>
hcarty: as separate arguments instead of a pair? sure.
<hcarty>
wmeyer: Indeed :-)
<hcarty>
I think that keeping the default_low and default_high arguments is best though
<hcarty>
thelema: That said, the _chain function supports the more complex case, so if you are concerned about the main _of_ord function being too complex that could be a reasonable compromise.
<hcarty>
thelema: In both of those cases I don't think a sane defaults for out-of-bounds values are immediately obvious from the bounds themselves
<hcarty>
thelema: I expect to be BatBounded fairly often for both dates and floating point values
<hcarty>
thelema: This will be a common case for me :-)
<thelema>
hcarty: hmmm...
<hcarty>
A more realistic one might be type dates = Too_early | D of Date.t | Too_late
<hcarty>
type t = Invalid_low | A | B | C | Invalid_high as a contrived example
<hcarty>
Another would be if type t is not numeric.
<hcarty>
But I can see cases, like the floating point one above, where there would be two
<hcarty>
I expect that the primary use with be in one stage (2 defaults + 2 bounds -> function)
<hcarty>
thelema: Oh, I misunderstood the question
<hcarty>
No bounds = None
<hcarty>
That's something I'm still trying to decide
<hcarty>
thelema: The example I gave yesterday was the main reason for me - nan or +/- infinity for out of bounds floating point values
<hcarty>
thelema: Default values for out of bounds <> bounds
<thelema>
hcarty: ^^
<hcarty>
thelema: What do you think of having one bounds:('a bound_t * 'a bound_t) parameter for bounding_f functions?
<hcarty>
thelema: I fixed the header comment in batBounded.mli, thanks for catching the mistake
<hcarty>
thelema: For example, you may want to return nan for our of bounds float values, or +/- infinity, rather the saturating or returning None/Some (min|max)
<hcarty>
thelema: default_(low|high) is the default return value - None or Some x. min/max are the bounds to apply.
<thelema>
hcarty: why bounding_of_ord? specifically, why the two sets of bounds: default_low/high and min/max?
<thelema>
hcarty: on bounded...
2012-09-19
<larhat>
hcarty: no, i haven't found anything missing/broken yet
<hcarty>
larhat: I'm off for a while, but thanks for the feedback!
<hcarty>
larhat: I haven't had a chance to look through your repository's history yet, but is there anything missing from what I have that you've noticed? My implemenation has been tested fairly well for req/rep and pub/sub in 'real' code but not much outside of that.
<larhat>
hcarty: ok! btw, i've remove my version of lwt-zmq, because i fount your version better. and there is no reason to keep both versions.
<hcarty>
larhat: Regarding your lwt-zmq questions from the other day - I did not know about your implementation; As far as I know, Lwt_zmq.Socket.send sending outside of the context of Lwt_main.run is fine/normal but if you find out something else I'm happy to change it; There is a 'release' branch with the oasis-generated files in a ready-to-compile form
2012-09-17
<hcarty>
hnrgrgr: Thanks for the link :-)
<hcarty>
If larhat comes back or reads this in a log somewhere - The oasis-generated files are available in the 'release' branch; I had not seen camlunity/lwt_zmq; I'll look into Lwt_zmq.Socket.send
<larhat>
hcarty: btw, Lwt_zmq.Socket.send sends data immediately and returns Lwt.unit, even without Lwt_main.run. Is it ok?
2012-09-16
<larhat>
hcarty: could you please run 'oasis setup' in you lwt-zmq and include setup.ml and other stuff in repo? also, did you see https://github.com/camlunity/lwt_zmq ?
2012-09-14
<hcarty>
adrien: It has a pretty heavily customized setup.ml so a 'oasis setup' with oasis 0.3.0 didn't do the trick as it might have otherwise.
<hcarty>
thelema: "untested" in that I it builds and installs, but I haven't tested the bindings yet
<hcarty>
thelema: I have an untested patch to fix compilation of the Cairo bindings under OCaml 4.00.0
2012-09-13
<hcarty>
mfp: If you can send the full command line you used and the patch I'll take a look
2012-09-12
<mfp>
hcarty: btw., first use of ocamlbrew :) it ignored the -p /path/to/memprof-patch param I gave it (not that it would have worked anyway, since it involved a nonstd build sequence with an expected error in the middle), so I ended up building the patched ocaml manually atop ocamlbrew's structure
<hcarty>
thelema: case 1- (bounding_of_ord ~default_low:min ~default_max:max Foo.ord ~min ~max)
<hcarty>
thelema: I've put a bit of thought into a proper bounded integer module implementation. It would be a nice thing to have.
<hcarty>
thelema: bounding_of_ord could definitely be implemented using _chain. I may do that but haven't yet as I'd like to benchmark both implementations since I expect the bounding_of_ord case will cover the most common cases (out of range = min/max; out of range raises an exception)
<hcarty>
thelema: The three cases you listed are the main cases I see for this module as well. That said, the _chain function could be used for more complex purposes if someone wanted to use it that way.
<hcarty>
thelema: If default_(low|high) = Some x then x is returned by the make_exn function for out of bounds values
<hcarty>
thelema: If default_(low|high) = None then an exception is raised by the make_exn function for out of bounds values
<hcarty>
thelema: default_low = the value to return when the argument is < min; default_max = the value to return when the argument is > max
<thelema>
hcarty: maybe we should have helper functions for all three variants
<thelema>
hcarty: also, I can see three variants of the bounding module: saturating (take out of range and bring to max/min), modulo (out of range -> wrap around) and exception. Is the bounded_of_ord_chain function able to implement all three, and if so, why not implement bounding_of_ord using _chain?
<thelema>
hcarty: what's the use case?
<thelema>
hcarty: I don't understand why bounding of_ord uses two lower and upper bounds
<hcarty>
Sorry, I don't think I can help with this. Hopefully someone else can though. I'm not familiar enough with the tool to know how that translates into raw OCaml code.
<hcarty>
thelema: I've pushed some updates to my bounded branch. `u (for [u]nbounded]) replaces None for the min and max bounds. I also added some basic tests.
<hcarty>
miniwolf: Do you have an example you could show?
2012-09-11
<hcarty>
thelema: Any suggestions for a better name for the bounding_of_ord_chain function?
<hcarty>
thelema: Beyond that, it needs tests and examples and possibly moving the BoundedType module type to BatInterfaces
<hcarty>
thelema: That's a good idea - I'll make the min/max bounds required and add `inf in place of None
<hcarty>
thelema, _habnabit: You're both correct - no bounds and [/( )/] are supported
<hcarty>
thelema: https://github.com/hcarty/batteries-included/tree/bounded -- BatBounded module with a more complete implementation, including support for open and closed bounds. I want to think about the interface a bit more before making a pull request, but feedback is welcome if you get a chance before then.
<hcarty>
Drakken: rwmjones has an Int63 implementation
2012-09-06
<thelema>
hcarty had some command-line ways to use the oasis executable to query _oasis files
<f[x]>
hcarty, tbh, I didn't look at it, just know that it exists
<hcarty>
f[x]: Different defaults (everything defaults to off), different base version (4.0.1+hg), packed modules with stub functions if a particularly format isn't included
<hcarty>
There are other changes as well, primarily in the form of packing the library so that it doesn't bring in so many generic module names.
<hcarty>
thelema: imagelib in oasis-db/odb's unstable
<hcarty>
I was able to get camlimages to build with oasis, which removes my need for omake. And I'm quite happy about that.
<hcarty>
Yeah... I think I tried to hack their build system changes into something that worked for me without luck. I didn't have much time for it though.
<hcarty>
thelema: Does the latest bzr revision build under 4.00.0? I thought it didn't but I may not have tested it.
<hcarty>
Ah ok - I expect that native vs bytecode could be different. Not sure in which direction though.
<hcarty>
thelema: Out of curiosity - which version of OCaml?
<hcarty>
There were a handful of improvements to the performance of lazy values in the last year or two. However, I don't remember if they are in 3.12.x or 4.x.
<thelema>
hcarty: aha.
<hcarty>
thelema: 'oasis query -help' has more options
<hcarty>
thelema: That prints "graphics, lablgtk2"
<hcarty>
thelema: For example - oasis query -oasis _oasis 'library("imagelib").builddepends'
<hcarty>
s/fbox/box/
<hcarty>
thelema: It looks like oasis already supports querying _oasis files out of the fbox
2012-09-05
<hcarty>
n00b6502: let x, y = 1, 2 in ... also works for naming multiple values together
2012-09-04
<adrien>
hcarty: however I don't think I can include that in lablgtk2 for now
<hcarty>
adrien: I can send it over if you are interested. It doesn't do much, just providing a wrapper around the "actual" build system.
<hcarty>
adrien: I wrote a (hopefully simple) _oasis file for lablgtk2 2.16.0 so that it could be properly uploaded to oasis-db
<hcarty>
And I think the answer is the same for a record
<hcarty>
Drakken: Not for an array
<hcarty>
Drakken: I don't think so... there was discussion about this at some point.
<Drakken>
hcarty or an array
<hcarty>
Drakken: Mutable elements in a record?
<hcarty>
flux: If people want to, they could make the complaints about camlp4 look minor and insignificant when compared to the modifications done with compiler-libs :-)
2012-08-31
<hcarty>
Thanks
<hcarty>
What is that ... diagram? ... called? BNF or something like that?
<hcarty>
thelema: Thanks - I should have thought to look at the manual.
<hcarty>
Or it could be an oversight
<hcarty>
Ah, no, although perhaps that's why it's not allowed?
<hcarty>
Yes
<hcarty>
Or Foo of bar_baz_t...
<hcarty>
thelema: Yes
<thelema>
hcarty: Foo (Bar | Baz) -> is nested, i.e. Foo of (Bar | Baz), no?
<hcarty>
The second version looks ugly on one line like that, but consistent when split over multiple lines.
<hcarty>
That seems like an odd exception to the leading-pipe on matches case
<hcarty>
"match x with Foo (Bar | Baz) -> ..." works fine, but "match x with Foo ( | Bar | Baz) -> ..." does not
<hcarty>
thelema: Good idea
<thelema>
hcarty: in 'external program management', maybe remove 'omake' right before uploading it.
<hcarty>
thelema: I emailed gildor and he restarted oasis-db. I'll wait to try to upload omake again until he's around to actively restart the system.
<thelema>
hcarty: or maybe gildor broke it with his recent commits
<thelema>
hcarty: well... I see.
<hcarty>
thelema: ^^ in case you run into it
<hcarty>
I think I killed oasis-db by uploading omake
2012-08-30
<Anarchos>
hcarty yes i remeber the port to PIC-8
<hcarty>
There was a port of OCaml to some simple processor.. PIC-8 or something.
<Anarchos>
hcarty it is the assembly designed by D. Knuth :)
<hcarty>
Anarchos: Anyone with a platform running that exotic assembly and interested in OCaml. Probably not much beyond that.
<Anarchos>
hcarty do you think that if i port ocaml to an exotic assembly, it could interest someone ?
<hcarty>
ICFP/CUFP/OUD looks like an interesting mix this year
<hcarty>
thelema: Have fun at OUD. I asked too late to get a trip funded this year, but hopefully next.
<hcarty>
That's heading (dangerously?) into the world of making odb.ml into a 90% solution
<thelema>
hcarty: of course. as I said earlier, best if it was just part of oasis package
<hcarty>
thelema: An odb.ml-installable executable, of course!
<hcarty>
The topfind script may have some hints. I think it's the same across both, but I may be wrong.
<hcarty>
That sounds unpleasant.
<thelema>
hcarty: nice. now I have to figure out if I can have that code compiled by ... eww, it looks like I'll have to use the ocaml toplevel library to do this...
<hcarty>
thelema: Are you using findlib for META file parsing?
<hcarty>
wmeyer`: That's what I was hoping
<thelema>
hcarty: what I'd like is to add a tool (or some command-line options to the oasis tool) to query all findlib dependencies from an _oasis file
<hcarty>
thelema: That would likely simplify the _oasis bits and still limit odb's absolute requirements to OCaml + findlib
<hcarty>
thelema: Maybe there is a trick possible with one of the toplevel-related modules to load and use oasis-based libraries when available.
<hcarty>
thelema: That's quite nice
<hcarty>
match odb.ml with `cool -> "Yep"
<hcarty>
Harzilein: What thelema said. You can setup local repositories or install from a VCS or the lcoal file system.
<hcarty>
Harzilein: Just a bit of clarification - oasis is a build tool; oasis-db is the CPAN-like system for uploading packages; odb is a command-line client for installing packages which are available from oasis-db
<thelema>
hcarty: yes, this is why the name issue.
<hcarty>
thelema: 'odb.ml re' installs ocaml-re, but it's listed as regexp in the oasis-db web viewer
<hcarty>
GODI is a wonderful tool, but it requires all-GODI packages in order to work best.
<hcarty>
wmeyer`: thelema and gildor wrote the bulk of the tools that drive it. I just got tired of putting everything together by hand and/or going through the GODI boostrap.
<hcarty>
wmeyer`: You're welcome, I'm glad it helps
<wmeyer`>
hcarty: Thanks for ocamlbrew to be clear - it's much easier to setup a working OCaml that way :-)
<hcarty>
thelema: I agree. Could be a good item for a pull request :-)
<thelema>
hcarty: instead of 'regexp'
<hcarty>
wmeyer`: I ran into a similar RAM issue on a VM a short while ago.
<thelema>
hcarty: hmm, maybe it would have been better to name the library 're'
<wmeyer`>
hcarty: yes, thanks for it :-)
<hcarty>
wmeyer`: Excellent! I'm glad to hear it :-)
<wmeyer`>
hcarty: now it's being used in full production that is
<hcarty>
thelema: ocamlnet is updated as well, thankfully with minimal patching required
<wmeyer`>
hcarty: BTW: I tested ocamlbrew on ARM, it works (I had minor problems; e.g. the 512MB was not enough to make ocamlopt compilation happy)
<hcarty>
Indeed.
<hcarty>
thelema: ocaml-re installs nicely under OCaml 4.00.0 from oasis-db. No patching required, thankfully.
<hcarty>
27 megabytes here in the installed Batteries tree from odb, so I guess I shouldn't be so shocked.
<hcarty>
Wow
<hcarty>
Is that just for the Batteries package? Or other dependencies as well?
<hcarty>
*megabytes
<hcarty>
If installing Batteries pulls 64 megbytes down then it sounds like there may be some dependency bloat in the Debian packages...
<hcarty>
Harzilein: I haven't read the utop code but I know it uses Lwt to parse input for display and supporting context-sensitive completion in the toplevel.
<flux>
hcarty, great :)
<hcarty>
flux: It took me a lot longer to get to than I had hoped, but ZMQ is now updated in oasis-db/odb. Which is nice because it means that lwt-zmq is installable again :-)
<hcarty>
Something related to Lwt? :-)
<Harzilein>
hcarty: i'll have a look, thanks
<hcarty>
Harzilein: One of its dependencies that is
<hcarty>
Harzilein: utop or one of it's libraries may have something you can use as a reference
2012-08-29
<hcarty>
thelema: I've updated the gist for BatBounded - https://gist.github.com/3388696 - I think that is getting closer to a reasonable interface.