2013-07-31

<hcarty> Specifically to have the subprocesses of an OCaml process killed when the parent OCaml process is killed.
<hcarty> Is there a prctl binding/wrapper for OCaml?

2013-07-30

<hcarty> travisbrady: For what it's worth, when I've run into that I've found the authors respond quickly to issues on github.
<hcarty> rks`: That would be nice
<rks`> hcarty: yes, that's what we were trying to avoid
<hcarty> travisbrady: But the default/auto-indentation still comes from vim. I need to explictly tell vim to use ocp-indent.
<hcarty> travisbrady: I'm using merlin + ocp-indent as separate plugins and it works (mostly) well.
<def-lkb_> hcarty: you're welcome :)
<hcarty> def-lkb_, rks`: Thank you both
<hcarty> def-lkb_: That works! And gives me a list at the bottom of the window.
<def-lkb_> hcarty: try after setting :let g:syntastic_auto_loc_list=1
<hcarty> rks`: vim 7.3, syntastic is 3.0.0 I think
<rks`> hcarty: which version of syntastic/vim are you using?
<hcarty> def-lkb_: Using merlin 1.1 + vim + syntastic, is it possible to jump to errors? :lnext/:lprev say that there is no location list.

2013-07-17

<hcarty> The opam package doesn't install the C stubs .so and from what I can see the upstream source doesn't either.
<hcarty> Can you use the ancient library from the toplevel or bytecode in general?

2013-07-12

<hcarty> gasche: I am not going to be able to spend any time on the Ord-related feature requests I made for Batteries over the next week or few.

2013-07-11

<AltGr> hcarty: if you set OCP_DEBUG=1 and run from the command-line you might be able to get more information
<AltGr> hcarty: well you're welcome, thanks for reporting
<hcarty> AltGr: Thanks for taking time to look into the ocaml-top bug. I'll see if I can find out anything else which may be causing/triggering the problem.

2013-07-10

<hcarty> Although from what I've seen, everything is better with merlin.
<hcarty> gasche: From what I've seen, ocaml-top + merlin would be quite a wonderful beginner's tool.
<AltGr> hcarty: thanks for testing and reporting !
<hcarty> AltGr: Ok, I'll make a bug report once I'm at the offending computer again. Thank you for looking into the problem.
<AltGr> hcarty: I would be glad if you could report your issue at https://github.com/OCamlPro/ocaml-top/issues/new, so that we can keep track
<AltGr> hcarty: I finally got a win 8 set up
<hcarty> AltGr: That sounds like no fun at all.
<AltGr> hcarty: process management on Windows is a mess, and to make it worse it seems that it changes between versions...
<AltGr> hcarty: some problems have been reported with win8
<hcarty> AltGr: To be more precise - the buttons in the GUI stop responding.
<hcarty> AltGr: For what it's worth, I did not have this problem with ocaml-top under Ubuntu + opam
<hcarty> AltGr: ocaml-top stops responding for me after running code once. This is under Windows 8, OCaml 4.00.1 using the installer recommended on the ocaml-top site.
<rks`_> AltGr: ping hcarty
<hcarty_> This is with the ocaml-top recommended Windows installer for OCaml (installing the 'OCaml' portion only) on a 64bit Windows 8 installation and ocaml-top 1.0.0.
<hcarty_> Has anyone here had success with ocaml-top and Windows 8? I'm trying it out as a potential demo for some colleagues but the ocaml-top interface becomes unresponsive after running any code.

2013-07-02

<hcarty> ygrek: Maybe not so useful, but this does work: class z = let a = (module String : String_sig) in object method length s = let module S = (val a) in S.length s end;;
<hcarty> ygrek: That seems like it's worth asking about on the mailing list
<hcarty> gasche: The spell checking is a nice addition in 4.01 - thank you for that
<hcarty> But I do go browse around now and then for fun :-)
<hcarty> gasche: I've been tempted to track SVN commits automatically (RSS or otherwise) but I haven't taken the time to set that up yet.
<hcarty> It's significantly less interesting without extension-points. I was hoping for fun things like a let-finally syntax and camlp4-free lwt support.
<hcarty> gasche: Ah, I thought the two were tied.
<hcarty> gasche: Speaking of development - is -ppx going to be in 4.01.x in some form or is it being held until later?
<hcarty> The interesting ones I see anyway. It's a nice way to track what's going on in the language without being in the inner circle.
<hcarty> gasche: Not all of them, just the interesting ones :-)
<gasche> impressive dedication, hcarty :]
<hcarty> gasche: I think this is the link, although I'm not sure how to tell now that Google Reader is gone - http://caml.inria.fr/mantis/issues_rss.php?project_id=1
<hcarty> gasche: Why do you ask?
<hcarty> gasche: I can find the link if you'd like
<hcarty> gasche: I don't, but I have an RSS feed
<gasche> hcarty: do you have a script to automatically monitor all mantis issues?
<hcarty> gasche, toolslive: I agree at this point. >0.1s seconds makes sense in the detach case but not 7s.
<gasche> hcarty: I would ten to agree with toolslive's viewpoint that if sub-0.1 monolithic computations result in order-of-magnitude overseelping time, it's probably a defect in Lwt's scheduling technique
<hcarty> toolslive: Then something around detach or working with separate processes may be necessary.
<hcarty> It's more of less fully cooperative-ized. I'm not sure why the detach approach didn't work though.
<hcarty> toolslive: That version finishes each test in (slightly more than) 0.1 seconds
<hcarty> toolslive: http://vpaste.net/85hUr
<hcarty> toolslive: Thanks. I'll take a look later. I don't know that I'll be able to offer a solution but I'd like to know what the underlying cause is.
<toolslive> hcarty: I've put up my new version (with Lwt_preemptive.detach)
<hcarty> toolslive: Can you update the gist? That does seem much too long.
<toolslive> hcarty: spinning waste_cycles off in an Lwt_preemptive detach helps 'a bit' the sleep of 0.1s awakes only 3s later.
<hcarty> toolslive: I agree that the result is surprising, but it seems to be consistent with how I understand Lwt's scheduling.
<hcarty> toolslive: That's a good question that I don't know the answer to. I expect it's <0.1 seconds though, possibly by a few orders of magnitude.
<hcarty> flux: There was something in the most recent ocamlpro update
<hcarty> My understanding is that those pieces need to be modified to be cooperative or spun off into Lwt_preemptive threads.
<hcarty> Again, waste_cycles is not cooperative
<hcarty> They only work for cooperative code
<hcarty> So you can end up with 12 of those running sequentially
<hcarty> toolslive: Not in waste_cycles itself
<toolslive> hcarty: that thing is cooperative. there are plenty of binds there....
<hcarty> toolslive: I think the waste_cycles loop would need to be made cooperative.
<hcarty> toolslive: I tried running it and got times ranging from >10s to <1s. But again I'm not terribly surprised. If each thread's waste_cycles call ends up running sequentially then it could easily take 7+ seconds.
<toolslive> hcarty I've added output of a sample run to the gist.
<hcarty> toolslive: Is that too surprising? Each of the waste_cycles loops could end up running sequentially.
<toolslive> hcarty: yes it does. but only for a small amount of time.
<hcarty> toolslive: If I'm reading the code correctly.
<hcarty> toolslive: waste_cycles will block anything else from running.
<hcarty> The development/review/etc. process is closed. The library itself seems nice, but the development seems more like regular code dumps of someone's internal tool than a community project.
<toolslive> hcarty: here it is: https://gist.github.com/toolslive/5908501
<hcarty> gasche: That's my concern as well, from a user perspective.
<hcarty> gasche: I've wondered that too. I think there is, but I'm not sure if the cost is worth it.
<hcarty> Ah, that's unfortunate. Is the example available somewhere to look at?
<hcarty> toolslive: What problems?
<hcarty> def-lkb: Is it possible to use merlin + vim + syntastic to jump to error locations? :lnext tells me that there is no location list.
<hcarty> toolslive: I asked about Lwt's future after its main developer went to Jane Street and started working on Async. I was assured that Lwt is not going away.

2013-06-30

<ollehar> gasche: yes, the point of hcarty's arguments would be that the update cost is only dependent of the fields being updated
<gasche> I'm not sure the discussion with hcarty at the end is accurate
<hcarty> gasche: BatMap.S.Labels.compare has a labeled, non-optional cmp function. In that case do you think cmp is best (also used by equal in the same module) or ord? Or the ord function could be left out of the Labels sub-module.
<hcarty> Then I think the two could share a signature
<hcarty> gasche: Or, better - add ord to S
<hcarty> gasche: S.ord vs S.compare
<hcarty> gasche: And unrelated to this - thanks for the pointer to pflag in the ocamlbuild sources. I had been working from http://nicolaspouillard.fr/ocamlbuild/html/Signatures.PLUGIN.html previously and didn't realize the API had expanded so much.
<hcarty> MakeOrd doesn't seem too bad, but SOrd seems like a difficult name to interpret.
<hcarty> BatMap.MakeOrd and .SOrd? Or .Ord.S and .Ord.Make? Or something else for the functors?
<hcarty> Option.compare and similar functions could be 'fixed' when Batteries 3 comes along.
<hcarty> I'm ok with that as it nudges the user to consider something other than polymorphic comparison.
<hcarty> Option.compare takes ?cmp
<hcarty> s/depending/depends/
<hcarty> gasche: I guess it depending on whether we would need to use the current module's ord function in another function which takes an ?ord argument.
<hcarty> gasche: On the plus side, there are new warnings in 4.01.0 about that kind of shadowing :-) But that was part of my concern as well.
<gasche> hcarty: I haven't thought much about the issue, but my first reaction is that ?ord is probably a better choice
<hcarty> gasche: On that front - should ?cmp still be used when an optional ord function can be provided? ?ord seems like a logical alternative but I don't know if the shared type/function/parameter name is acceptable.
<hcarty> gasche: I spent a bit of time on that feature request (Ord-ready Map/Set/...). I can try to get a proper pull request together in time for release preparation.

2013-06-28

<hcarty> The threads bug still exists in 4.01.0+dev. Bug report filed. With luck (where luck = someone who knows what they're doing has time to fix it) a fix will make it into 4.01.0.
<hcarty> ygrek: Not released but it's been branched from trunk
<hcarty> On 4.00.1 this gives "ocamlfind: Error from package `threads': Missing -thread or -vmthread switch"
<hcarty> To test: http://vpaste.net/G5F4r
<hcarty> Does someone have easy access to a recent 4.01.0 OCaml install with findlib? I think I found a bug in 4.00.1's ocamlbuild + ocamlfind and I'd like to check if it's fixed in 4.01.0 before reporting.

2013-06-25

<hcarty> adrien_oww: Physical presence isn't required for the actual activity, but it may help encourage people who are at the meeting to take part.
<hcarty> gasche: Physical presence may help keep things focused. Or prevent focus... it should be fun either way.
<hcarty> gasche: You keep mentioning sprints - maybe something should be organized around the OUD meeting in September?

2013-06-24

<hcarty> kaustuv: Yeah, I think that's the one
<hcarty> kaustuv: This is one, but I think there are other more complete options: https://github.com/toyvo/ocaml-pretty
<hcarty> kaustuv: There is pprint or something close to that... I don't remember the exact name.

2013-06-20

<gasche> hcarty: not all ocamlbuild users use OASIS, so I think it's better to have the useful plugin developped separately

2013-06-19

<hcarty> ollehar: Go for it. It's not the most eloquent description but if it's helpful you're welcome to use it.
<hcarty> If 'field' is a giant array of data which needs to be copied to avoid mutation then mutation will be faster.
<hcarty> But, again, the contents of 'field' and how it is being updated may affect the relative cost of a functional update vs mutation.
<hcarty> Because everything other than 'field' is shared between old_record and new_record. new_record has the same contents (physically the same) as old_record aside from field.
<hcarty> ollehar: If you do a functional update on the OCaml record (let new_record = { old_record with field = modified_field_value }) then the 'cost' of the update is low.
<hcarty> ollehar: That likely depends on the specifics of the object/record and the type of update being performed.
<hcarty> oasis could be a nice way to circumvent ocamlbuild's lack of support for external modules in a myocamlbuild.ml. I wonder if it it would be too ugly to have oasis inline external files into its generated myocamlbuild.ml. That could simplify the maintenance and composition process when several extensions are involved.
<hcarty> Then again, oasis makes all of this a bit redundant. I should find the time to submit all of this as a proper oasis patch to add support for these features.
<hcarty> Then everyone will be happy and peaceful bliss will settle over the multitude of OCaml build tools.
<hcarty> And in some magical future we'll be able to have a myocamlbuild.ml that looks like: "let () = Rpath.dispatch (); Static_link.dispatch (); Other_custom_plugin.dispatch ()"
<hcarty> gasche: Thank you! That's exactly what I'm looking for. When I wrote that snippet I ended up trying to implement pflag by hand. I need to dig more deeply into the sources next time.
<gasche> hcarty: it's the "pflag" function in the PLUGIN module type (ocamlbuild/signatures.mli)
<gasche> hcarty: I... don't know
<hcarty> gasche: I have a simple rpath plugin here - https://gist.github.com/hcarty/5198467 - and it would be nice/cool to be able to extend it to support something like '<**.*>: rpath(/some/path)' in _tags.
<hcarty> gasche: Is it possible to define custom parameterized tags with ocamlbuild?

2013-06-17

<hcarty> let poor_joke = To continue to be relevant, Batteries will need to include some critical, currently missing components (https://ocaml.janestreet.com/ocaml-core/latest/doc/core/Time.Zone.html#VALfind_office)
<hcarty> eikke: Indeed!
<hcarty> gasche, thelema: If RWO and the OCaml Platform going Core + Async, do you have any thoughts on what this means for Batteries?

2013-06-14

<hcarty> adrien: Not the male/female balance, but the generally exclusive attitude.
<hcarty> gasche: Yes, I plan on submitting patches. I wanted to enter the requests so I don't forget.
<adrien> hcarty: I see no occurence of brogramming before a decade ago
<gasche> hcarty: would you provide patches for the Ord stuff?
<hcarty> adrien: The term, yes. But not the sentiment.
<hcarty> adrien: I'm not sure there is a time since programming began that predates brogramming, at least the exclusive club aspect.

2013-05-28

<def-lkb> hcarty: thx for merlin 1.1, as asmanur said there is the :Reload command. besides, the vim-mode automatically reload interfaces if :make is called from vim
<hcarty> asmanur: That's what I was looking for - thank you very much.
<asmanur> hcarty: did you try :Reload ?
<hcarty> Regardless of the answer to that question, merlin 1.1 is a wonderful update!
<hcarty> def-lkb: Is there a way to foce merlin to reset from a vim session? I modified a module M in foo.ml and merlin isn't picking up the change in bar.ml (under a separate vim instance) until I restart vim.

2013-04-30

<hcarty> Thank you both
<hcarty> Drup: The 'almost' part concerned me :-) But it shouldn't hurt to try.
<hcarty> orbitz: Thanks. I haven't used that module before, but a unit Lwt_pool.t seems like it would serve my needs well (limit the number of external processes run at once with Lwt_process)
<hcarty> Is it reasonable to use Lwt_pool as a way of limiting the number of threads used for a particular purpose in Lwt?

2013-04-25

<hcarty> A way to make package B pretend to be package A for dependency resolution purposes would be nice though
<hcarty> smondet: Thanks for the suggestion!
<hcarty> smondet: Ok, so I would need to locally/separately repackage the libfoo as libfoo-just-the-lib and keep that repackaged version and the wrapper version in sync with upstream changes
<smondet> hcarty: you can do that with 3 packages: you can have a package libfoo that depends on libfoo-dev OR libfoo-just-the-lib
<hcarty> thomasga: Does opam provide a mechanism to say that package A can work in place of package B? As an example, libfoo.1.0.0 and libfoo-dev.snapshot where the -dev package says it 'provides' libfoo for other packages.

2013-04-23

<hcarty> 

2013-04-18

<hcarty> 'ls -lrt' lets you know what's been updated recently. ls, again, is good.
<hcarty> You're welcome - I'm happy to now know what an applicative functor is in the Haskell world :-)
<chris2> hcarty: searching for applicative functors yields mostly module-level results ;)
<chris2> hcarty: thanks!
<hcarty> chris2: http://blog.0branch.com/from-functor-to-applicative - found this in a search
<hcarty> thomasga: Thanks for the aspcud tip. I am using opam on RHEL/CentOS in this case so I'll have to try master/wait for the next release.
<thomasga> hcarty: indeed, the heuristic should be better now (and if you are on debian, I would advise to try 'apt-get install aspcud` which is a far better solver than the one in OPAM, although the one in master should be fine for most of the cases)
<hcarty> thomasga: I don't know if this is a packaging issue or opam issue.
<hcarty> thomasga: I have had issues with ocamlnet under opam. When I tried to upgrade from 3.6.0 to 3.6.3 opam said it had removed all of the ocamlnet modules but ocamlfind complained about some of the packages still existing when it tried to install 3.6.3.
<hcarty> rks_: Indeed
<hcarty> thomasga: I haven't tried master but I think from our previous discussions that it has been fixed there.
<hcarty> thomasga: 1.0.0
<thomasga> hcarty: do you have dependency bugs in master or in 1.0.0 ?
<rks_> hcarty: second that
<hcarty> gasche: The modified error message through on caml-list is an example of hostility toward changes. I would love to see error messages which are more human friendly but there was immediate animosity toward a proposed change to provide that.
<hcarty> opam still has some significant dependency handling bugs but it already makes it a matter of a few commands to go from no OCaml to latest stable + the libraries and tools you want.
<hcarty> We're part way there with opam - on non-Windows platforms (?) it's now fairly easy to get up and running with the latest OCaml release.
<hcarty> Not everyone will want to
<hcarty> Making those easy install methods the 'normal' way to get OCaml is importnat too so everyone can take advantage of the latest and greatest
<hcarty> ggole: That is a big barrier and part of why making it easy to install new versions of OCaml is so important
<hcarty> I'm very happy at the moment with OCaml 4.00.1 + opam + Batteries as a core but that combination is only recently available. It will take some time for these tools to become widely used and accepted.
<hcarty> The idea of an OCaml platform is neat, but it's so vague at this point (OCaml + opam + <is there anything else required?>) that it can be equal parts exciting and worrisome as an observer.
<hcarty> gasche: For existing users there are a handful which range in significance. Uncertainty over camlp4 is one issue, particularly with -ppx coming.
<hcarty> flux: In a perfect world ocp-indent, merlin and similar tools would provide a toolkit used by any editor to support OCaml
<hcarty> flux: There are, but they don't seem to be as stable or feature-rich as the vim and emacs support
<hcarty> gasche: For someone new to the language, saying 'Yeah, use vim or emacs!' is probably not helpful.
<hcarty> gasche: I think the most significant pain point in OCaml varies depending on the user you'r talking about
<gasche> hcarty: we're not far from it
<hcarty> gasche: Like gofmt?
<hcarty> gasche: I don't know what the correct method is for handling this - I've seen your comments on the list :-) - but for example Perl + CPAN does well with this in my experience.
<hcarty> gasche: If Batteries is going to split, names could be a problem
<hcarty> gasche: I think the original, external opam repository for merlin pulled from git master
<hcarty> And merlin is a wonderful, non-core tool
<hcarty> Trying a project like merlin before opam would have been prohibitive enough that I likely wouldn't have tried it pre-opam, for example.
<hcarty> It's certainly easier now to take advantage of external effort now
<gasche> hcarty: I'm willing to make effort to get more contributions to the global OCaml ecosystem
<hcarty> gasche: To comment on the discussion from a while ago - There has been a lot of noise about how hard it is to get contributions accepted in OCaml. I expect that reputation prevents many from trying. For Batteries the barrier may just be that people don't need a lot more than it provides.

2013-03-29

<hcarty> thomasga1: I apologize - this was already reported (https://github.com/OCamlPro/opam/issues/565)
<hcarty> thomasga1: "opam remove core" gives that message, as does "opam remove all-of-the-other-janest-core-related-libs"
<hcarty> thomasga1: I had installed Jenga to see what it was and now I'm trying (without luck) to remove it.
<hcarty> thomasga1: opam won't let me uninstall core or anything that depends on it. I get a message saying "The package core.109.15.00 is in conflict with core.109.15.01."

2013-03-27

<thelema> hcarty: nice; I'll pay attention to what comes of this.
<hcarty> thelema: I'd certainly like to see it happen.
<hcarty> thelema: I can submit a ticket on Mantis to see if rpath and static linking could be included upstream.

2013-03-26

<thelema_> hcarty: any chance it will be pushed upstream?
<hcarty> I don't know how the magic of static vs dynamic linking varies from one platform to the next
<hcarty> Only tested on Linux - I'm not too surprised I guess
<tonyg> hcarty: thanks!
<hcarty> thelema_: ^^ an update to the rpath plugin from the other day
<hcarty> tonyg: That gist has rpath pieces as well - you really only need 7 of those lines for the static linking piece
<hcarty> tonyg: I made a small myocamlbuild.ml to support a "static" tag - https://gist.github.com/hcarty/5198467

2013-03-21

<hcarty> thomasga: Thanks :-)
<thomasga> hcarty: it's fixed (and won't happen again)
<hcarty> thomasga: You're welcome - I'm glad it's not a broken installation on my end.
<hcarty> thomasga: I submitted a bug but wonder if this is an error on my end - https://github.com/OCamlPro/opam/issues/551
<hcarty> thomasga: ping

2013-03-19

<hcarty> Which kind of makes sense from the documentation.
<hcarty> Yeah, it still sticks link.rpath in as an ocaml(opt|c) argument
<hcarty> But that may have been when the custom rule was still in place... I'll try again
<hcarty> thelema: Last time I tried that ocamlbuild tried to pass link.rpath to ocaml*
<hcarty> It's still missing a way to say that things should be rebuilt if the link.rpath file changes.
<thelema> hcarty ah, this looks nicer.
<hcarty> thelema: Simplified per your suggestions, and a bit further after noticing the 'string_list_of_file' function provided by ocamlbuild.
<hcarty> But one is enough for everything I need at the moment.
<hcarty> I wanted to see if it was reasonably easy to provide multiple .rpath files for multiple compilation targets (foo.rpath => foo.native; bar.rpath => bar.native)
<hcarty> Not within the 20 minutes I gave myself to spend on it anyway.
<hcarty> But I wasn't able to figure out how to convince ocamlbuild to process the rule without doing anything else with the .rpath file.
<hcarty> The rpath definition is where it is because I originally tried to do this as a rule definition.
<hcarty> thelema_: I agree with both organizational suggestions, thanks.
<hcarty> I wrote a small ocamlbuild plugin to include rpath information from a file. Any suggestions for improvements? https://gist.github.com/hcarty/5198467
<hcarty> The bindings look reasonably clean, at least on the surface
<hcarty> So from this we can determine... clearly there is a link between the drinking water around where you grew up and interest in EFL! :-)
<hcarty> adrien: Since you've mentioned wanting OCaml EFL bindings often :-)
<hcarty> adrien: Were you aware of https://forge.ocamlcore.org/projects/ocaml-efl/

2013-03-11

<hcarty_> AltGr: Thanks!
<hcarty_> AltGr: 1.0.1 here
<hcarty_> AltGr: That seems likely!
<hcarty_> I want consistently matched open/close delimiters
<rks_> but that doesn't seem coherent hcarty_ :-'
<hcarty_> I would probably want that indented one level from the closing function )
<hcarty_> I would still want the closing ) lined up
<rks_> but hcarty_, let's say then
<hcarty_> rks_: That's how it is indented elsewhere by ocp-indent
<hcarty_> rks_: Yes
<rks_> hcarty_: you want it aligned with L ?
<hcarty_> rks_: The closing )
<hcarty_> thomasga: Thanks
<thomasga> (report from hcarty_)
<hcarty_> thomasga: Do you have any insight into the future of oasis vs obuild vs ocp-build vs Jane St's to-be-released build tool? I fear build tool fatigue :-)
<hcarty_> The offending code: http://vpaste.net/IupDE
<hcarty_> Are there any ocp-indent folks here? I have a bug in the latest version from opam but I'm not sure if it's been fixed/reported yet.
<hcarty_> thomasga: :-)
<thomasga> hcarty: obuild is much better :p
<hcarty_> avsm: What is your opinion on oasis vs obuild? I see that you have both implemented for cohttp.

2013-03-08

<thomasga> hcarty: thx, I finally manage to generate a tempory .mllib file
<hcarty> thomasga: If b.ml references the module A then I expect you wouldn't need to specific 'a.cmo' as one of the build targets.
<hcarty> thomasga: I can load the resulting b.cma in the toplevel and have access to modules A and B
<hcarty> thomasga: That's with no references between a.ml or b.ml
<hcarty> thomasga: Sorry, rather - `ocamlbuild -mods a,b a.cmo b.cma` works here
<hcarty> thomasga: `ocamlbuild -mods a,b a.cma` works here

2013-03-06

<rixed> hcarty: indeed
<hcarty> rixed: s/arrays/records/ maybe?
<hcarty> OCaml's type checking for objects is static (structural typing as you mentioned)
<hcarty> So in that definition, yes a statically checked type relationship would be more typesafe.
<hcarty> According to the limited reading I've done, the two are pretty similar. The informal difference seems to be that duck-typing has checks at runtime.
<hcarty> More than...?
<hcarty> ollehar: Objects are duck-type-like
<ollehar> hcarty: but objects are structural typed, right?
<hcarty> ollehar: Objects allow for subtyping and you can do some subtyping with first class modules.
<hcarty> ollehar: This is may only be partially correct wrt the official reason - Records have a fixed structure, both externally (code) and internally (runtime).

2013-03-05

<hcarty> That may help? I'm mostly guessing though.
<hcarty> companion_cube: Bench.config.samples <- some_number_smaller_than_1000
<hcarty> A similar dump_init could be used to dump to immutable structures
<hcarty> Something to dump a set of values from the given indices into a settable data structure.
<hcarty> And a friend suggested a to_x (dump?) function like ('a, 'b, [> `r ]) IndexMap.t -> 'a array -> ('c -> int -> 'b -> unit) -> 'c -> unit
<hcarty> Indeed! With the appropriate application of (x)map it could provide that as-is.
<companion_cube> hcarty: hey, it can also provide such a good interface for caching functions
<hcarty> Once I get a chance to write a test or two I'll send a post to batteries-devel
<hcarty> companion_cube: IndexMap now supports read-only, write-only, and read-write indexes.

2013-03-04

<hcarty> If I can find the link
<hcarty> If it is then you can try it out in the browser...
<hcarty> companion_cube: Is that the same project which put up a working tryocaml toplevel?
<hcarty> Along with read/write
<hcarty> companion_cube: It may make sense to provide write-only as well as read-only support in IndexMap.
<hcarty> for a map which also requires a reverse map function.
<hcarty> The name could be pinched for IndexMap
<hcarty> companion_cube: How do you apply the mapping function to a "set" call?
<hcarty> fasta: You can't access Foo (of foo.ml) without compiling foo.ml -> foo.cm* first.
<companion_cube> hcarty: I still don't get the problem with map and mutable structures
<hcarty> s/a function/functions to/
<hcarty> companion_cube: For now the map function only works on immutable structures. A map_mutable function could be added with a function map over set and get.
<hcarty> companion_cube: I pushed an update with mutability support
<hcarty> Or map can only be applied to immutable indexes
<hcarty> There may need to be two map functions. map_mut and map_immut.
<hcarty> let map index f = { index with get = (fun i -> f (index.get i)); set = (fun i x -> ???) }
<hcarty> Nope
<hcarty> let map index f = { index with ... set = (fun i x -> index.set i (f x)) }
<hcarty> Ah, never mind. I was mixing up the code in my head.
<hcarty> companion_cube: Not the module/data structure :-)
<hcarty> companion_cube: No, sorry - the function map
<companion_cube> hcarty: it only makes sense for mutable containers