<hcarty>
"slow things down" -- for some (simple?) cases, using "Module.(something)" with openin in an expression is slower than using "something" directly. I'm guessing due to inlining or some kind of optimizations which don't work across module bounds?
<hcarty>
bluestorm: Indeed. pa-do provides functions to do this in a cleaner manner
<hcarty>
The point is to allow Complex.(x.re) to act as x.Complex.re, without using pa_openin-like functionality which could potentially slow things down in some cases
<hcarty>
This is in the context of numeric.ml in pa-do
<hcarty>
Zombie Smerdyakov walks the Earth! Oh no!
2008-08-13
<hcarty>
bluestorm: I'm heading out for now, but assuming I have time I will take you up on your offer for help
<hcarty>
I emailed the developers to ask if "x |> g |> f" --> "f (g x)" is outside of the scope of pa-do. If not, then I will submit a feature request for that as well.
<hcarty>
I had errors, ignored them, and then got what looked like a legitimate pa-do generated error :-)
<bluestorm>
hcarty: my brief and probably innacurate tests showed that trying to use pa_do in the topfind-enhanced toplevel with no further indication inevitably lead to an error
<hcarty>
A brief, though possibly inaccurate, test in the toplevel indicates that using Foo.(bar) under pa-do when no overloading is defined for the module Foo will give an error
<hcarty>
Yes, I was amazed at how quickly they responded with an implementation
<bluestorm>
hcarty: i guess that mean it is the default
<hcarty>
I think it may just be the default for modules with overloading enabled
<hcarty>
bluestorm: Does that mean that openin is enabled by default?
<bluestorm>
hcarty was asking about using camlp4 to inline simple operators (in his case function composition)
<hcarty>
mbishop: It should be ready to use now
<hcarty>
I think the .cma has extra information in it to help with such things
<mbishop>
hcarty: well, it didn't error
<hcarty>
mbishop: Can you #load the .cma?
<mbishop>
hcarty: yeah, I don't know why, the C code for that function looks ok to me
<hcarty>
mbishop: That looks like it is a problem with linking/loading the C portion of the library
<hcarty>
Or, perhaps term is reasonable there
<hcarty>
s/term/name/
<hcarty>
Foo.(bar) -- what is the proper term for "bar"? An expression?
<hcarty>
I agree
<hcarty>
bluestorm: Ok, I'll submit another feature request for that
<bluestorm>
hcarty: yes i do
<hcarty>
bluestorm: Do you think it is worth requesting the ability to enable openin globally? I think having it set on a module-by-module basis may become difficult to follow.
<hcarty>
wolgo: let ( & ) f x = f x in print_endline & string_of_int 1;; or something along those lines
<hcarty>
bluestorm: I think it is on a module-by-module basis though. I may ask for a way to turn it on globally.
<bluestorm>
hcarty: good
<hcarty>
bluestorm: I did, and it has been added, at least in some form
<bluestorm>
hcarty: did you suggest them the "open in" behavior ?
<hcarty>
twobitwork: ocamlfind does
<bluestorm>
hcarty: yeah
<hcarty>
bluestorm: pa_infix probably can... I think that may be one of the more useful applications of the extension.
<hcarty>
mbishop: Or you can use compiler directives to tell ocaml(c|opt) where the library files are
<hcarty>
mbishop: You can #load the .cmo directly in the toplevel
<bluestorm>
hcarty: pa_infix can probably already do that
<hcarty>
bluestorm: How difficult would it be to make an extension to translate "f $ g x" or "x |> g |> fto "f (g x)" to avoid the function overhead? I've read complaints about the overhead, but have not tested its impact..
<bluestorm>
hcarty: moreover, this is bad style imho
<mbishop>
hcarty: have you used it? I don't know how to properly install it (I have the cmx/cma/o files built, just not sure where to put them to get ocaml to recognize it)
<hcarty>
mbishop: Possibly? I think I mentioned that it exists
<mbishop>
hcarty: was it you who talked about uintlib yesterday?
<hcarty>
vixey: The Jane St. OSP Delimited Overloading project has a pa_infix module which is supposed to allow that. But vanilla OCaml does not.
<hcarty>
Beyond f (g x)
<hcarty>
twobitwork: There is no built in syntax or operator
<hcarty>
Sorry, that was meant for landonf
<hcarty>
mfp: I did briefly, but didn't like the generated interface
<Smerdyakov>
hcarty, definitely "yes" to the first question, and maybe "yes" to the second.
<hcarty>
Smerdyakov: I agree (I think) -- When you say "should be avoidable," do you mean being able to avoid common boilerplate through better languages? Or something more?
<Smerdyakov>
hcarty, another way of saying it is that most software development today should be avoidable.
<jdh30>
hcarty: That was a polite way of saying "you may have no practical knowledge of software development and, therefore, no idea what is really needed".
<Smerdyakov>
hcarty, I mean anything that developers spend lots of time doing
<hcarty>
I'm not a PL researcher, so your ideas of problems in software development may be very different from mine
<hcarty>
Smerdyakov: I may not understand what you mean by "problems in software development"
<Smerdyakov>
hcarty, I don't understand. Why are you classifying language design and implementation as fundamentally different from most programming that goes on today, in terms of what is "production" and what is "consumption"?
<hcarty>
Smerdyakov: So a world of all producers and no consumers?
<Smerdyakov>
hcarty, from this perspective, people not interested in developing language technology are headed the way of the dinosaurs.
<Smerdyakov>
hcarty, my basic viewpoint is that most problems in software development should be solved by designing and implementing new languages.
<hcarty>
Hopefully someone with such interests will blow us all away soon :-)
<Smerdyakov>
hcarty, the profit opportunity exists independently of subjective interest.
<hcarty>
Smerdyakov: It's only an appealing opportunity for those who have an interest in designing languages
<Smerdyakov>
hcarty, old version at http://laconic.sf.net/ -- lacks 2 out of 3 magical properties I described. :P
<hcarty>
Smerdyakov: Where are these wonder-languages?
<mbishop>
hcarty: no, but last time I needed them it wasn't out (in fact, neither was the forge :P)
<hcarty>
It only covers unsigned int32 and unsigned int64 types, but may be helpful if you need them
<hcarty>
mbishop: Have you tried the uint64 library on the forge?
<jdh30>
hcarty: indeed.
<hcarty>
jdh30: Understandable. I haven't run in to a problem there, at least not one single precision floats would solve. That hardly means the problems don't exist :-)
<jdh30>
hcarty: anything where storage or performance are a concern.
<hcarty>
jeddhaberstro_: What do you want to use single precision floats for?
<hcarty>
Sys.interactive, I believe
<twobitwork>
hcarty: ahh, I'll look for it, thanks
<hcarty>
function
<hcarty>
twobitwork: There is a funciton in the stdlib which tells you if the code is running in the toplevel or not
<gildor>
hcarty, twobitwork: the package is about to be uploaded in debian
<hcarty>
Fluid dynamics, optics, radiative transfer are large components
<hcarty>
Definitely a physical science...
<hcarty>
jdh30: Atmospheric science here
<jdh30>
hcarty: thanks. i never tried very hard to get it to work but I just wrote a tutorial article about fork-based parallelism so I should probably cover camlp3l at some point.
<hcarty>
jdh30: I've been able to get the example program to work, and done some sequential-mode playing around in the toplevel
<hcarty>
ocamlp3l is a set of libraries on top of OCaml, while JoCaml is a modification of OCaml itself
<hcarty>
twobitwork and flux: ocamlp3l is another
2008-08-11
<hcarty>
bluestorm: Unless you use pa_infix from the pa-do project to change the associativity :-)
2008-08-07
<hcarty>
It is very useful. I am using it on a CentOS 4 system and a CentOS 5 system without any major complaints
<hcarty>
I've done both on CentOS 5, and both methods seem to work reasonably well
<hcarty>
godi might be a simpler method than backporting the Fedora OCaml rpms
<hcarty>
bitstring started as a camlp4 3.10.0+ extension as far as I know
<hcarty>
nDuff: I'm pretty sure bitstring uses the new camlp4, released with OCaml 3.10.0+
2008-08-05
<tvn1981a>
hcarty: yeh I'll try that
<hcarty>
tvn1981a: I havne't used the Digest module, but I would guess that you want to Digest.to_hex function
<hcarty>
mfp: Thanks for mentioning the "noalloc" and "float" FFI tags. I may not ever use them, but it's nice to know they are there...
2008-08-03
<hcarty>
Anarchos: Then, using ocaml-java, you can have a jvm running ocaml running a jvm...
<hcarty>
flux: Module.(expr) would act like pa_openin was used in (expr), in addition to the rest of the pa_do translation
<hcarty>
I'm writing up a feature request for the forge tracker now
<hcarty>
bluestorm: I certainly agree
<bluestorm>
hcarty: i don't think so
<hcarty>
Of course, all of this syntax manipulation can get quite messy...
<hcarty>
Yes, I think it seems messy otherwise
<hcarty>
I've found Foo.(...) to be quite useful, particularly when accessing record fields to avoid a.Foo.x + b.Foo.y and similar
<hcarty>
I may make a feature request
<hcarty>
_do could be modified to do that as well
<hcarty>
I may have to change the syntax of the extension I've been using... Module.(...) has acted like pa_openin. With pa_do it means something different. Though I suppose pa
<bluestorm>
hcarty: hm
<hcarty>
Hopefully programmer restraint will kick in at some point
<hcarty>
I like that it is possible, but I agree that it has the potential for horribly unreadable code
<bluestorm>
hcarty: i have mixed feelings about breaking the OCaml fixity/precedence conventions
<hcarty>
pa_do certainly looks nice. And pa_infix look like a useful result from the project as well
<hcarty>
I haven't gone through the irssi log yet... there has been a lot of activity over the last 12 hours
<hcarty>
bluestorm: Cool, thanks
<bluestorm>
hcarty: hey, i was looking for you some hours ago, to tell you about the pa-do project
<hcarty>
bluestorm: Are the final reports for the projects available somewhere? They don't seem to be on the Jane St. OSP site
2008-07-31
<hcarty>
Sorry, .cmxa
<hcarty>
palomer: No -I, just unix.cma
2008-07-30
<hcarty>
flux: Hence the "may be" :-)
<flux>
hcarty, more efficient than for c = 0 to 42 do ar.(c) <- ar.(c) + 1 done? well, could be, but only because Array.mapi can get rid of bounds checking? (well, they also do different things..)
<hcarty>
For certain definitions of "reasonably performant"
<hcarty>
flux: It probably depends on how the vector or matrix is represented. If a and b have type 'a array then it may be reasonably performant to use Array.mapi (...) a b
<hcarty>
Philonous: Those are relatively easily handled with either a syntax extension or defining new operators
<hcarty>
One benefit is that (+) always does what you say, as does (+.), without any implicit casts
<hcarty>
Philonous: There is no function or operator overloading in OCaml
<hcarty>
I've read through the manual, but I have not found anything that works for me
<hcarty>
Is is possible to tell ocamlfind to call pkg-config using the linkopts META option, or otherwise?
<hcarty>
a "linkopts" line in the META file looks like it may be the way to go, but I'm not sure about that.
<hcarty>
I'm working on properly building the OCaml PLplot interface as part of the main PLplot source tree. The OCaml bindings are compiled against the not-yet-installed C library, which makes the "-custom" option somewhat ineffective. Any suggestions on the proper way to handle this?
2008-07-03
<RobertFischer>
hcarty: Yeah. That'd be awesome as the defining feature of 4.x.
<hcarty>
Maybe if/when 4.x rolls around
<hcarty>
But if JoCaml is maintained then it could probably be more efficient and cleaner.
<hcarty>
Yes, I've been worried for the same reason. The biggest benefit that I see with camlp3l over JoCaml is that it's a library on top of vanilla OCaml, rather than a change to the compiler.
<RobertFischer>
hcarty: That'd be nifty. I'm a bit nervous about it not being supported long-term....but it's definitely something to look at.
<hcarty>
RobertFischer: It seems interesting at least. You can run a program sequentially or distributed with the same code from what I understand.
<RobertFischer>
hcarty: Yeah, I didn't know about camlp3l
<hcarty>
processing, that is
<hcarty>
camlp3l does distributed computing
<hcarty>
CoThreads and camlp3l share a developer
<hcarty>
It's a distributed framework. I'm not sure how comparable it is with JoCaml wrt process communication
<RobertFischer>
hcarty: That has an equivalent to JoCaml's process communication?
<hcarty>
May help with the "interprocess stuff", though I've only used it briefly to toy with its tests
<hcarty>
RobertFischer: camlp3l is, according to the authors, going to be maintained
<hcarty>
flux: the ml2008.pdf writeup goes over some of the shortcomings and benefits
<hcarty>
The happy, huggable Smerdyakov is back! Hooray!
<hcarty>
s/then/than/
<hcarty>
match x with b::tl -> ... rather then the let
<hcarty>
You would need another match to avoid warnings
<hcarty>
Throw an exception
<letrec>
hcarty: what does let b::tl = x do if x is the empty list?
<hcarty>
letrec: Would something like this work? match l with a::x -> let b::tl = x in tl
2008-07-01
<hcarty>
I tried OVT, but it only supported some very basic functions, so I just wrapped the PLplot library and have been using that
<hcarty>
Some Cairo-based graphics in OCaml
<hcarty>
OCaml Visualization Toolkit
<hcarty>
I saw a little activity on the OVT Google Code site
<hcarty>
I don't know if any of last year's summer projects are maintained
<hcarty>
ls
2008-06-19
<hcarty>
flux: Not always, but it can be a useful check. And sometimes easier than generating them by hand and continually updating them.
<hcarty>
Mostly a laziness issue at this point, but as code starts to grow it would be nice to have the local dependencies decided automatically
<hcarty>
bluestorm: Yes, I would certainly want to use ocamlfind doing it my self. ocamlbuild potentially has the benefit of picking up the required local .ml files in the right order automatically
<hcarty>
I can figure out the dependencies to do it by hand, but some ocamlbuild would be much easier and nice to have for the future
<hcarty>
Is there a way to get ocamlbuild to produce an .mli from a .ml?
<hcarty>
Thanks
<hcarty>
bluestorm: Oh, that's much nicer...
<hcarty>
I've been using ~-1
<hcarty>
I've been using OCaml for a while, but I haven't really used the 'a option type very much before now
<hcarty>
I
<hcarty>
I have a list is numbers, and want to find the smallest, returning None if the list is empty and (Some smallest) if the list isn't empty. Is this the right way to use option types here? http://pastebin.com/d58a224fc
<hcarty>
+/ and friends are already used in the Num module, which is the only real reason I suggest them
<hcarty>
Sorry for the redundancy there...
<hcarty>
I think it might be worth changing. I've been using a Module.( "Module is opened in here" ) syntax extension for some code, and after playing around with (+) vs (+.) vs (+/) I think it may be worth changing
<hcarty>
Yoric[DT]: What is/was the reason for using +., -., etc for operators in Batteries, rather than +/, -/, etc or some other extra character? Isn't masking floating point math just as bad as masking integer math?
<hcarty>
Yoric[DT]: Thanks for the open vs include results. That is good to know.
<hcarty>
IIRC
<hcarty>
No, it uses open Module
<hcarty>
Yoric[DT]: Ok, thanks. I'm just curious, wondering what what affect making a pa_includein camlp4 extension vs pa_openin camlp4 extension would have
<Yoric[DT]>
hcarty: according to my measurements, none.
<hcarty>
Is there a performance difference between using "open Foo" vs "include Foo"?
2008-06-18
<hcarty>
Yes, it's a pretty exciting and ambitious group of projects
<hcarty>
Jeff_123: The Jane St. OCaml Summer Project
<hcarty>
I'm hoping that they pull it off - if so it could be very handy
<hcarty>
I wrote a simple camlp4 extension to do it, and Zheng Li did as well
<hcarty>
orbitz: There is something like that already, though not to the extent of the SoC project
<hcarty>
Associat0r: g'caml has some sort of operator overloading support. I don't know its current state though. let first = intersection_indices.(0) in
2008-06-17
<hcarty>
bluestorm: Nice, thanks
<Flice>
hcarty: thanks
<hcarty>
let round x = floor (x +. 0.5)
<hcarty>
Flice: There is no round function in the stdlib
<hcarty>
Jason Hickey's book has some good information on both the OO and module system
<hcarty>
That said, there are trade offs. For some code, using OCaml's OO makes adding new functionality easier. For other code, the module system is easier.
<hcarty>
The types can become rather long and complex when working with the object system in OCaml.
<hcarty>
chessguy: The OO in OCaml is very handy and nice to work with in my opinion. There are those who use it quite often. However, for many tasks, the module system is easier and/or cleaner.
<hcarty>
I think there was some chatter on the mailing list about it being possible, with camlp4 3.10+, to do the same thing using camlp4. I don't know if anything has started with that.
<Yoric[DT]>
hcarty: is it ?
<hcarty>
No camlp4
<hcarty>
twt is done as a separate preprocessor, from what I understand
2008-06-12
<hcarty>
Ack, again... sorry
<hcarty>
ls
2008-06-11
<hcarty>
struk_atwork: As I suspected :-)
<hcarty>
ls
2008-06-09
<rwmjones>
hcarty, yes
<hcarty>
I have a GODI-compiled 3.11+devsomething on a system, but not in front of me
<hcarty>
rwmjones: Is that ~the latest CVS revision?