Re: [Caml-list] lag when using typerex
Le mercredi, 9 mai 2012 à 13:24, Joel Reymont a écrit : I'm using Carbon Emacs (not Aquamacs!) on the Mac and simple editing is lagging. Deleting too. Yes it's not only on aquaemacs, I reported that a few months ago : https://github.com/OCamlPro/typerex/issues/2#issuecomment-4537263 I did follow Daniel's suggestions but TypeRex is still lagging. No need to keep keys pressed, simply hitting the delete key or typing does it. Strange, here with emacs 23.4.1 from http://emacsformacosx.com/ (which seems down at the moment) and the config I posted there's no lag. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] lag when using typerex
Is it just me or is there a significant lag when using TypeRex in Emacs? This is particularly noticeable when deleting by using the backspace key. Here, the lag was due to auto complete mode. Don't invoke it automatically. That's what I have : (add-to-list 'load-path /Users/dbuenzli/.emacs.d/auto-complete-mode) (require 'auto-complete-config) (add-to-list 'ac-dictionary-directories /Users/dbuenzli/.emacs.d/auto-complete-mode/ac-dict) (ac-config-default) (global-set-key (kbd S-tab) 'auto-complete) (setq ac-auto-start nil) I want immediate menu pop-up ;;(setq ac-auto-show-menu 0.) Short delay before showing help ;;(setq ac-quick-help-delay 0.3) Number of characters required to start (nil to disable) ;;(setq ac-auto-start 0) Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] lag when using typerex
In fact there is another source of lag on osx, syntax highlighting. https://github.com/OCamlPro/typerex/issues/2#issuecomment-4537263 I just use ocaml's emacs-mode for that, see the full dump of my config below, Best, Daniel ;; Typerex mode ;; Loading TypeRex mode for OCaml files (add-to-list 'load-path /Users/dbuenzli/.emacs.d) (add-to-list 'auto-mode-alist '(\\.ml[iylp]? . typerex-mode)) (add-to-list 'interpreter-mode-alist '(ocamlrun . typerex-mode)) (add-to-list 'interpreter-mode-alist '(ocaml . typerex-mode)) (autoload 'typerex-mode typerex Major mode for editing Caml code t) ;; TypeRex mode configuration (setq ocp-server-command /usr/local/bin/ocp-wizard) (setq-default indent-tabs-mode nil) (setq ocp-auto-complete t) ;(setq ocp-theme caml_like) ;(setq ocp-syntax-coloring t) ;; Work around slow syntax highligthing. (setq ocp-syntax-coloring nil) (setq load-path (cons ~/.emacs.d/caml-mode load-path)) (if window-system (require 'caml-font)) (add-hook 'typerex-mode-hook 'caml-font-set-font-lock) ; OCaml identing style ;(setq typerex-in-indent 0) (setq typerex-let-always-indent nil) (setq typerex-with-indent 0) (setq typerex-function-indent 0) (setq typerex-fun-indent 0) (setq typerex-type-indent 0) (setq typerex-if-then-else-indent 0) Le mardi, 8 mai 2012 à 13:10, Daniel Bünzli a écrit : Is it just me or is there a significant lag when using TypeRex in Emacs? This is particularly noticeable when deleting by using the backspace key. Here, the lag was due to auto complete mode. Don't invoke it automatically. That's what I have : (add-to-list 'load-path /Users/dbuenzli/.emacs.d/auto-complete-mode) (require 'auto-complete-config) (add-to-list 'ac-dictionary-directories /Users/dbuenzli/.emacs.d/auto-complete-mode/ac-dict) (ac-config-default) (global-set-key (kbd S-tab) 'auto-complete) (setq ac-auto-start nil) I want immediate menu pop-up ;;(setq ac-auto-show-menu 0.) Short delay before showing help ;;(setq ac-quick-help-delay 0.3) Number of characters required to start (nil to disable) ;;(setq ac-auto-start 0) Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] TypeRex: indenting let open Mod in
Le mardi, 8 mai 2012 à 23:25, Joel Reymont a écrit : Is there a way to get this layout with TypeRex? I don't think so, I have the same problem; and that's just one example of a wrong identation pattern with typerex. It is unfortunately based on the completely broken tuareg-mode (which for reasons that are unknown to me seems to be preferred by many ocaml programmers to the better mode provided by the distribution). A reimplementation of the indentation engine is however planned : https://github.com/OCamlPro/typerex/issues/10#issuecomment-4132259 Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] lag when using typerex
Le mardi, 8 mai 2012 à 23:49, Joel Reymont a écrit : What's the point of using TypeRex then? * Refactoring tools (renaming). * Jumping from a name to its definition. * Name autocomplete and its documentation. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] PEC ver. 1.1
Le jeudi, 19 avril 2012 à 10:59, Satoshi Ogasawara a écrit : If I understand correctly sending [v] to [e] immediately during update cycle are violate the semantics because it cause more than one values on one event at the same time. Yes. Using React, let e, sender = E.create () in let e' = E.map (fun x - Queue.add q (fun () - sender 1); x + 1) e in let e'' = E.map (fun x - Queue.add q (fun () - sender 2); x + 1) e in does this code violate the semantics of events? Yes. It has the same problem. Let's start with : let e, sender = E.create () in let e' = E.map (fun x - Queue.add q (fun () - sender 1); x + 1) e in Since the thunk is delayed to be executed after the update cycle we *could* say that an occurence of [e] at time [t] defines the occurence of [e] at time [t + dt]. Note however that this is a bad idea, the right way to solve these problems is to use fixed point operators, see [1]. Now this is all fine, during the update cycle, which is made under a synchrony hypothesis (i.e. it takes no time, see [2]), we are defining the occurence of [e] at time [t + dt] as being 1. So far so good. But now we change the program and add let e, sender = E.create () in let e' = E.map (fun x - Queue.add q (fun () - sender 1); x + 1) e in let e'' = E.map (fun x - Queue.add q (fun () - sender 2); x + 1) e in This is not fine at all, during the update cycle, which again, takes no time, i.e. everything therein happens simultaneously at time [t], we are defining the occurence of [e] at time [t + dt] as being 1 and 2 at the same time. A schizophrenic event which obviously violates the semantics of events since an event must have at most one occurence at any given time [t]. So basically when you allow feedback from primitive events to primitive events you have to be very careful. Maybe that's needed in practice, again, I don't have enough experience to assert that, but if you do it you should make sure that the semantics of events is not violated. If so, PEC is also unsound. I'd like to know PEC is unsound or not. PEC may not be unsound as a whole. However the idea that you can just send to primitive events during update cycles and not bother is unsound with respect to the semantics of events as soon as you send two different values to the same primitive event. To prevent glitches, PEC distinct one update cycle to another by time identity. And calculated results are cached for same update cycle. Update order is straight forward. Just follow from leaf to primitive source event. It's not problem because only one primitive value changes at one update cycle. Right. But you still have to maintain some kind of mapping between the primitive event and the leaves they may influence to know which ones to update when the corresponding primitive event occurs. Do you store that in the primitive event itself or do you use a global data structure ? While I'm not very fond of the sub/unscribe part I think it's an interesting implementation and may try, once I get some time, to adapt it to React to see what we can get from it (I also think that the resulting implementation could be much simpler). One can in fact argue that using React you also have to do the same manual management by having to keep reference on leaf events to avoid them being gc'd. The difference is that PEC trusts the client to perform unsubscribes correctly to avoid leaks while React allows not to bother about that at all (but Weak pointers have their cost). Besides it may be the case that in practice sub/unsuscribe calls are not that plentyfull; I would count one subscribe and no unsubscribe in the breakout.ml example of React's distribution. Best, Daniel [1] http://erratique.ch/software/react/doc/React.E.html#VALfix [2] http://erratique.ch/software/react/doc/React#simultaneity -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] PEC ver. 1.1
Le jeudi, 19 avril 2012 à 12:31, Daniel Bünzli a écrit : While I'm not very fond of the sub/unscribe part I think it's an interesting implementation and may try, once I get some time, to adapt it to React to see what we can get from it (I also think that the resulting implementation could be much simpler). In fact, if I really understood what you are doing, I think there is a performance problem with your approach. Suppose we have the following configuration where L is a subscribed leaf event, that depends on N events that eventually lead to the primitive events P1 ... PN : L | \ ... \ ° ° ° | \ ... \ ° ° ° | \ ... \ ... ...... |\\ P1 P2 ... PN If P1 occurs then you start walking back from L, but you don't know where P1 is so you have to walk down every branch until you find P1 and then walk back from there up to L to make the update. Contrast this with (weak) forward pointers: you just start from P1 and walk *once* up to L. Is that correct ? Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] PEC ver. 1.1
Le mercredi, 18 avril 2012 à 03:59, Satoshi Ogasawara a écrit :
What's the semantics if you send two different values to an event during an
update cycle ?
They fires two different event if you send two different value to an event
even if same update cycle. Events send are stored in an event queue,
and they will be poped by 'run' function just like GUI event loop.
Ok. I would just like to point out that you can do exactly the same with React.
However React doesn't integrate that functionality, the client has to implement
it. Mainly for two reasons.
1) Thread-safety and compositionality. React has no global data structure.
2) Semantic issues. As soon as primitive events are triggered by other
primitive events you run into the problem of multiple occurences of the same
event during an update cycle. Now given the synchrony hypothesis of update
cycles (an update cycle is instantaneous), this is a violation of the semantics
of events (an event has at most one occurence at any given time t). And then
people ask you if you can somehow manage the order of updates in an update
cycle and then you are not doing FRP anymore, you are doing RP. By loosing the
F you also loose compositionality and the equational reasoning tools provided
by the denotational semantics of events.
I'm not sure how that's different from react. If an event has no dependents
(by which I understand your subscribed), react doesn't hold any pointer
either.
React constructs 'heap' to hold dependency graph inside the library.
let e' = map (fun x - x + 1) e, the e' and e are weakly pointed by the heap.
PEC doesn't have heap structure in the library. This is a difference.
This difference is important if you want to translate the OCaml event
combinator to javascript because javascript doesn't have weak pointer.
To be precise React constructs a heap only during an update cycle. Now I guess
you must have some kind of similar data structure encoded since if you don't
update your events in topological order of the dependency graph, you'll have
glitches and again violate the semantics of events.
Regarding the absence of Weak usage I'm curious in how you manage the garbage
collections of events that depend on others.
How is that different from react's E.switch/S.switch ?
Almost same except all signals are created though react's S.switch at
initializing.
It's convenient to design library for dynamic event driven systems. For
example,
let me assume a signal of window size property.
type window = {
size : (int * int) signal;
}
If you want to change the dependency of window.size after initialize the
window
keeping signals depends on the size unchanged, there is no way except making
switch
event at initializing.
type window = {
size : (int * int) signal;
size_switch_event : (int * int) event event;
}
I feel it's not convenient. So I decided to embedded the swith_event to
inside of signals.
Best,
Daniel
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] PEC ver. 1.1
Le mercredi, 18 avril 2012 à 13:44, Satoshi Ogasawara a écrit : But PEC dose not violate good semantics either. PEC treats only one event at any given time t. Please see blow code. I don't think your code shows the problem I'm talking about. module E = Pec.Event.Make (Pec.EventQueue.DefaultQueueM) (Pec.EventQueue.DefaultQueueI) open Printf let _ = let e, sender = E.make () in let e' = E.map (fun x - sender 2; x + 1) e in (* during update cycle, send 2. *) Here add : let e'' = E.map (fun x - sender 3; x + 1) e in and now what should the value of e be in the next update cycle ? All the options you have (keep only the first call to sender, keep only the last call to sender, keep both and execute one after the other) break the functional and compositional nature of FRP because it violates the semantics of events. To write event driven systems such like GUI sometimes needs a event-event chain without real-user actions. Sending events during update cycle is something unavoidable. I don't have enough experience to assert that's really the case. However if that's needed I suspect that the way to resolve conflicts that break the semantics, should they arise, is actually very specific to the problem domain and shouldn't rely on anything related to the order of updates during the update cycle. The only thing I'm saying here is that your first message made it sound like PEC solved a problem of React (You can send a value to event during update cycle.). It's not a problem of React it's a problem of interfacing FRP with your application domain. And React can perfectly be adapted to use the same unsound solution that PEC seems to use by adding the sender calls in a thunk queue and dequeing after the end of the update cycle. Yes, weak-pointer-less implementation is one of my purpose. The key point is that dependency of events are represented by nested variants. That doesn't really answer my question (or at least I don't understand what it means). Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Non-blocking IO interface design
Just a word on naming. I have now gathered all functions specific to `Manual sources and destinations in a Manual submodule by renaming as follows: Codec.decode_src - Codec.Manual.src Codec.encode_dst - Codec.Manual.dst Codec.encode_dst_rem - Codec.Manual.dst_rem The new names are as short and seem as clear to me. Maybe even clearer since the name of the module suggests it should only be used with `Manual sources and destinations. It also makes it easier for non-`Manual users to skip these functions and their documentation. The sample code at http://erratique.ch/repos/nbcodec/ was updated accordingly. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Non-blocking IO interface design
Anil, Thanks for the analysis. The I/O loop is being called twice for the non-blocking version, as it receives the `Await signal, does the Unix syscall, and then jumps into decode_src. Presumably a full non-blocking version would have to register with a select handler if it gets an EAGAIN at this point, Yes. In terms of the number of system calls, the non-blocking one is more efficient, as it uses a 16KB buffer versus the 4K reads done by the blocking version. Yes, the 4K reads are a limitation of pervasives channels. For each mechanism I used the largest buffer that the OCaml runtime uses. Looking at the two decoders in src/se.ml, it looks like the non-blocking one allocates closures on every loop, which the blocking one doesn't. This is so it can store the continuation in d.k for the next loop. Yes, that's a side effect of writing in continuation passing style in general since continuations are often partially applied functions. So to summarise, instead of storing a continuation closure, it would probably be better to explicitly store the state in d.k to minimise allocation? Maybe, but keep in mind that s-expressions are very simple to parse. It may be obvious in this case but depending on what you decode defining/storing the state may become complex. Cps is an easy and general way to solve the problem while keeping the whole thing reasonably readable. But do you maybe see another pattern that I don't ? The library looks very useful by the way: I have exactly the same issue with several Lwt-only protocol libraries we're developing at the moment. Would love to use yours before the first release of them to make them more independent of the underlying I/O mechanism... That would be nice, I'm glad if you can somehow reuse the pattern. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Non-blocking IO interface design
Hello, This is problematic : https://github.com/williamleferrand/xmlm http://ambassadortothecomputers.blogspot.com/2010/08/mixing-monadic-and-direct-style-code.html To solve this problem I'm looking for a simple interface design to make my IO modules compatible with monadic concurrency libraries (lwt, async, [insert your own here]) and event based loops (select(2), poll(2), etc.). The design should have the following properties: 1. Unified interface for blocking and non-blocking mode. 2. The existence of the non-blocking mode should not significantly impact blocking mode users. 3. Input possible from in_channel, string, refillable fixed-size string buffer (non-blocking mode). 4. Output possible to out_channel, Buffer.t, flushable fixed-size string buffer (non-blocking mode). 5. No third-party IO libraries/paradigms so that the module can adapt to the one the user chooses. 6. Reasonably efficient. I looked for some time into Haskell's enumerators, pipes and other conduits but I eventually came back to a more ad-hoc approach that abstracts as follows. I'll gladly take any feedback you may have. Suppose we want to IO streams of value of `type t`. For example xmlm's signals (lexemes as they should be called) if you are familiar with that. For input (decoding) we begin with a type for input sources, decoders and a function to create them. type src = [ `Channel of in_channel | `String of string | `Manual ] type decoder val decoder : src - decoder A [`Manual] source means that the client will provide the decoder with chunks of bytes to decode at his own pace. The function for decoding is : val decode : decoder - [ `Await | `End | `Error of e | `Yield of t ] [decode d] is : - [`Await] iff [d] has a [`Manual] input source and awaits for more input. The client must use [decode_src] (see below) to provide it. - [`Yield v], if a value [v] of type [t] was decoded. - [`End], if the end of input was reached. - [`Error e], if an error [e] occured. If you are interested in a best-effort decoding, you can still continue to decode after the error. For [`Manual] sources the function [decode_src] is used to provide the byte chunks to read from : val decode_src : decoder - string - int - int - unit [decode_src d s k l] provides [d] with [l] bytes to read, starting at [k] in [s]. This byte range is read by calls to [decode] with [d] until `Await is returned. To signal the end of input call the function with [l = 0]. That's all what is needed for input. Just a note on the `Error case. Decoders should report any decoding errors with [`Error] to allow standard compliant decodings. However at that point they should give the opportunity to the client to continue to perform a best effort decoding. In that case [decode] should always eventually return [`End] even if [`Error]s were reported before. I think best-effort decoding on errors is a good thing: I was annoyed more than once with xmlm simply failing with `Malformed_char_stream on files produced by legacy software that gave invalid UTF-8 encodings for funky characters. Rather than fail and block the client at that point it's better to report an error and let it continue if it wishes so by replacing the invalid byte sequence with U+FFFD. For output (encoding) we begin with a type for output destinations, encoders and a function to create them. type dst = [ `Channel of out_channel | `Buffer of Buffer.t | `Manual ] type encoder val encoder : dst - encoder A [`Manual] destination means that the client will provide to the decoder the chunks of bytes to encode to at his own pace. The function for encoding is : val encode : encoder - [ `Await | `End | `Yield of t ] - [ `Ok | `Partial ] [encode e v] is - [`Partial] iff [e] has a [`Manual] destination and needs more output storage. The client must use [encode_dst] (see below) to provide it and then call [encode e `Await] until [`Ok] is returned. - [`Ok] when the encoder is ready to encode a new [`Yield] or [`End]. Raises [Invalid_argument] if a [`Yield] or [`End] is encoded after a [`Partial] encode (this is done to prevent the encoder from having to bufferize [`Yield]s). For [`Manual] destinations the function [encode_dst] is used to provide the byte chunks to write to : val encode_dst : encoder - string - int - int - unit [encode_dst e s k l] provides [e] with [l] bytes to write, starting at [k] in [s]. This byte range is written by calls to [encode] with [e] until [`Partial] is returned. To know the remaining number of non-written free bytes in [s] the function [encode_dst_rem] can be used: val encode_dst_rem : encoder - int [encoder_dst_rem e] is the remaining number of non-written, free bytes in the last buffer provided with [encode_dst]. A well-behaved encoder should always fill all the bytes it is given, except for the buffer that encodes the `End. One note on [`Manual] destinations, encoding [`End] always returns [`Partial]. The client
Re: [Caml-list] exn vs option
Le jeudi, 5 avril 2012 à 11:05, Goswin von Brederlow a écrit :
If you are writing a module then consider providing both flavours for
functions, one with exceptions and one with options. Even if you only do
something like this:
I don't think it's a rule that should be applied consistently, I don't like
libraries that provide tons of convenience functions, too many names. If you
stick with the option type (or variant cases) the user can quickly wrap the
function if it needs an exception (or vice-versa but I prefer it that way since
it's then documented by the function signature and is in my opinion better
behaved in general).
However in the particular case of finding something in a data structure where
the user could be confronted with a situation where he can prove that the datum
will be found I think it's justified to provide both flavours. For these cases,
in my own code I settled on the following pattern :
val find : 'a t - key - 'a option
(** [find d k] is the value bound to [k] in [d], if any. *)
val get : 'a t - key - 'a
(** [get d k] is like {!find} but raises [Invalid_argument] if [k] is not
bound in [d]. *)
Best,
Daniel
P.S. [Invalid_argument] is used for programming errors. This pattern expresses
an opinion about using exceptions.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
Le vendredi, 9 mars 2012 à 12:56, Gerd Stolpmann a écrit : You can call it KISS, but I would call it short-sighted. This has nothing to do with bureaucracy. Imagine a package has also some utilities to install (and feeled every second package has). You just don't want to have to include tons of bin/ directories into your PATH. It does not scale well, but just slows down your system. If you actually took time to have a look the systems I mentioned, they symlink executables in the regular/expected directories in /usr/local. No short-sighting here, sorry, but of course you may have to question some of your pre-conceptions about package management. There are just different sets of principles, and they have their pros and cons. The simplicity argument is not always the striking one. Well in my opinion these system solve problems that are known to be complex (like having multiple versions of the same library) in a conceptually very simple and understandable way. That's really funny how you interpret this, but I guess this is just a matter of perspective. findlib does not support subdirectories just because I wanted to keep it lean, and to avoid adding features it does not need for its core job. And the core job is to drive the compiler with the right flags, and not to provide a container for storing files. Ah, I thought findlib was a library manager for Objective Caml. A library without documentation is useless. Frankly, beyond your initial objection, what are the costs and implications of allowing `ocamlfind install` to install files in package subdirectories ? I totally understand your point that you want to have a system that makes it easy to hack around (it's clearly no fun with the complex guys). Fundamentally that's not the point, what I want a system that is simple to understand and fix when it breaks. Having easy things like `ocamlfind remove package` removes everything that package installed is part of such a system for me, aswell as simple concepts like everything that this package installed is located in that directory. However, I'm really wondering why docs are your first concern here? Good documentation and easy access to it makes me productive. I'm sure a lot of other people like to be productive. The real hacker does not need docs :-) I never pretended to be a real hacker... I don't need to show-off, I'm rather limited and actually enjoy simple solutions to complex problems. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
Le vendredi, 9 mars 2012 à 17:26, Edgar Friendly a écrit : http://oasis.ocamlcore.org/dev/odb/ Ah missed that. Maybe you should mention the link in the README.md (searching for odb ocaml on the web brings me directly to github). While I agree it'd be nice to just parse oasis files, they're not nearly as trivial to parse as the k=v format. If you can write a small enough parser with no external deps, I'll add it to odb and use its info to supplement the packages file. May happen, or not. Thanks, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
Le jeudi, 8 mars 2012 à 22:27, Sylvain Le Gall a écrit : Let say that if you just use $htmldir, it will help whatever packaging system that cooperate with oasis to enforce it in the future. In fact it is possible to not say anything at all, just don't mention InstallDir, oasis doesn't complain. That allows to abstract away the document's final destination and let the underlying body of code that installs choose what's best. So that's what I have : Document reference Title: Xmlm's documentation and module reference Format: html Index: Xmlm.html Install: true DataFiles: doc/*.html, doc/*.css Document distribution Title: Xmlm's distribution information files Install: true DataFiles: README CHANGES Maybe a kind of enumerated Kind: field could give more information about the nature of the documents. That said, oasis still seems to be a little bit schizophrenic about installation: on one hand it shouldn't install, on the other hand it seems to offer fields to perform installation duties. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
Le vendredi, 9 mars 2012 à 20:11, Sylvain Le Gall a écrit : Document reference Title: Xmlm's documentation and module reference Format: html Index: Xmlm.html Install: true DataFiles: doc/*.html, doc/*.css Document distribution Title: Xmlm's distribution information files Install: true DataFiles: README CHANGES Maybe a kind of enumerated Kind: field could give more information about the nature of the documents. That said, oasis still seems to be a little bit schizophrenic about installation: on one hand it shouldn't install, on the other hand it seems to offer fields to perform installation duties. I am probably off-topic, because I don't understand by what you mean by on one hand it shouldn't install, on the other hand it seems to offer fields to perform installation duties. ? I was meaning in general. If oasis is supposed to be descriptive (in the sense here you have an executable, here you have a library, here you have documentation), why does it have a field like InstallDir for documents ? Why do we have something like XCustomInstall: cp XYZ; I mean understand why we have it, but shouldn't its usage be discouraged ? Now the Document sections I wrote above don't do anything for now but it seems to me that 1) It has the info for a potential downstream packager e.g. cp `oasis query Doc(reference)` $WHEREWEPUTTHATINOURDISTRIB 2) It has the info for the thing I choose to manage the oasis -install I hope that one day, that 2) will be able to its thing and push it at the right place (being it inside sitelib or not !). Isn't that a better approach than using XCustomInstall or InstallDir ? Should I do it differently ? Maybe the only thing that is missing in an agreement like you have for SourceRepository: this, head. to better caracterize the actual bits of documentation that are being described (b.t.w I added a Document samples with DataFiles:examples/*.ml) But maybe what you miss here, is that it is meant to build documentation. Yes, if eventually there's a system that is able to integerates these odocl why not. For now I don't see any advantage and I prefer to distribute them statically. One reason is that since all my documentation is in inside the .mlis I think its nice if someone just want to have a look at the docs that he doesn't need to build anything (e.g. if the lib has many deps). Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
E.g setting Type: ocamlbuild + a couple of field to tell that your doc will be extracted from some libraries/module and build using ocamldoc + ocamlbuild: Document api-ounit Title: API reference for OUnit Type: ocamlbuild (0.2) BuildTools+: ocamldoc XOCamlbuildLibraries: oUnit XOCamlbuildPath: src/ In fact I may change my mind about that (since I already publish docs on the web). Two questions : 1) In the manual under the library section it's written : Define an OCaml library. OCaml API is generated using `ocamldoc` applied to `Modules` with `BuildDepends` required flags. is that outdated info ? because in that case I don't even need to define a section like you do above. 2) In both cases how can I pass arguments to ocamldoc (I need to give it a -charset utf-8). Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
Le jeudi, 8 mars 2012 à 09:31, Sylvain Le Gall a écrit : The main change of .cmo - .cma is that toplevel expression are only evaluated if you open the module. open, like the construct, I thought open was just about syntax ? You mean use or invoke a function ? This can be a problem if your .cmo are used in a plugin way (i.e. toplevel expression register the content of your library) and that you don't open it. Nevertheless I think it's best for users to avoid the change. Is that Object section still due for 0.3 ? Otherwise is there a way to hack around ? setup.ml will be enough for me ;-) But I am biased. For distribution, I'm fine with that aswell. For developement setup.ml takes too much time to invoke (adds an overhead of 0.5s on my system). 4) I'm really not interested in oasis trying to generate my _tags and myocamlbuild.ml files. Is it ok to substitute my own or does setup.ml rely on these ? You can substitute your own. There should be no problem. Don't hesitate to open a feature request to explain the reason why and your solution. I don't promise it will be implemented, but it is worth understanding the reason. First, all my modules don't need an myocamlbuild.ml, second since ocaml 3.12 it is now very easy to express findlib dependencies in _tags files. Third, I don't want to have to sweep through hundreds of generated lines of code (458 for myocamlbuild.ml) of useless configuration stuff when something goes wrong. Avoid bureaucracy at all costs. We already discuss this CHANGES file stuff. I still didn't have the time to work on that, but it is something that I want. In future version there should be something like that. Use 'PostCleanCommand: rm XYZ' DataFiles should do that. You may not have the tarball anymore when you want to uninstall things. That's certainly not a good approach. Concerning installing this using ocamlfind, I am a little more skeptical. We use standard cp to install in /usr/share/doc. I don't know a lot of libraries that install their documentation in /usr/lib, probably because there are packaging rules against that. I completely disagree with that. I think we already had this discussion. This monolithic view may be suitable for system level packaging system like debian. But I think its wrong to take this approach here. What I need as a developer, is an ocaml specific packaging system that is able to move much quicker than the system level package system and if possible in which you also may install more than one version of a library. The only clean approach that seems to work well when you want that is that every package installs in its own (versioned) prefix and symlink *if needed* in the regular system directories (see gnu stow, gobolinux or homebrew on osx). It also makes it *damn simple* to understand who installs what and to hack and understand the system when it breaks. For me helping downstream packaging should not be the first goal of a system like oasis. From my developer's point of view downstream packaging is only usefull to help you to install the base (the language and the language specific package system) and then you should install what you need by using the language specific package system. Here again I think homebrew takes the right approach, they don't repackage any gem, python egg or perl module, they piggyback on the strength of these individual system and let the developers manage them letting them resort to homebrew only when they need dependencies that are outside the scope of the language specific system (C libraries etc.). So my proposal would be to let ocamlfind manage all that and agree on a few directories. I'm not proficient enough in ocamlfind but I guess it won't be able to support multiple versions. But at least if we can be sure that `ocamlfind remove pkg`, removes everything a package installed, documentation included it would be nice. For me it would be enough to stick the CHANGES, README right into ocamlfind's package directories. $SITELIB/pkg/META $SITELIB/pkg/_oasis $SITELIB/pkg/README $SITELIB/pkg/CHANGES $SITELIB/pkg/share/html/*.html $SITELIB/pkg/share/examples/ etc. Having standard like this could also help efforts like typerex (or even ocamlfind) to know where to lookup for documentation data. Now oasis is the place to enforce such a standard. I realize that this no good. I probably should code a plugin Static, to have Type: Static and use the data you fill in Document section to install. This is not a long job. Could you open a bug about that, so that it will remind me to do it ? Here you have. https://forge.ocamlcore.org/tracker/index.php?func=detailaid=group_id=54atid=291 That is a bug. I have similar problem with the Pack: when generating _tags with capitalized module name. I installed ocaml on a mac yesterday to find the right solution. It will be shipped with oais 0.3.0~rc3. But this part
Re: [Caml-list] odb questions
Le jeudi, 8 mars 2012 à 14:29, Edgar Friendly a écrit : For myself, when I want to remove something installed by odb, I usually just nuke my whole ~/.odb directory and reinstall the packages I want to keep. I like your down to earth approach ! Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] oasis packaging questions
Le jeudi, 8 mars 2012 à 17:09, Jérémie Dimino a écrit : Note that in general it is better to install a cma/cmxa, even if your library has only one module. The reason is that when building an executable, cmo/cmx files passed on the command line are always linked, while unused units of cma/cmxa files are not (unless you specify -linkall). Okay, but is there a reasonable case (beyond sloppy dependency tracking) where you'd like to link against a *single module* library while not wanting to use it ? Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] oasis packaging questions
Le jeudi, 8 mars 2012 à 17:58, Jérémie Dimino a écrit : This may happen if you are using a subset of a multi-modules library which use a single-module one. Not completely unlikely I agree. I'll go with the cma then. Thanks, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
I don't think I'll be able to integrate the Object section in 0.3. I am really planning to release it soon. For me you can forget about it. Jérémie convinced me that even for single module libraries cma is better (see discussion on list). I just had a quick look at your git repository and I don't think there will be a difference for user if it is a .cma (as long as they use ocamlfind). I also think so. Never try autoconf ;-) Never did ! Always scared me away. OK, so first of all you are talking about the odb/GODI/oasis-db level. OASIS itself is not meant to handle that directly. There will be a plugin oasis-db that will allow you to do oasis install xmlm and oasis uninstalll xmlm and fetch the source from http://oasis.ocamlcore.org but this is the future and this won't be the core oasis system. You can have a look at odb that allow you to already do that after having uploaded your package to http://oasis.ocamlcore.org. Concerning the ocamlfind install + documentation. I understand you but it is technically not feasible right now (AFAIK). Simple fact: ocamlfind cannot install files in subdirectories. Ok interesting fact. This raises a few comments/questions. 1) You tell me that's none of oasis business. But setup.ml sports a -install option so you actually deal with installing things (even if its via ocamlfind). More than that the examples I saw for Document sections are along the lines of copying things to a specific $htmldir so oasis seems to deal with that... At least that's the place where *something* should happen so that the right info gets to the right place. 2) How does godi et al. handle documentation ? I know for sure that odb doesn't do anything about it. 3) Would ocamlfind consider extending its approach to be able to install files in subdirectories ? I really think that easy access to README, CHANGES and other bits like ocamldoc generated doc is paramount in a good package system since you don't get to see the tarballs anymore. I try to do my best and spend long hours on the documentation of the things I distribute (doesn't mean it's perfect, I sometimes don't understand what I wrote myself...), I want them to be somehow easily accessible (and easily destroyable). Can't we agree on something at that level ? Best, Daniel P.S. Btw. setup.ml -install should maybe also install the _oasis files. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
Le jeudi, 8 mars 2012 à 22:27, Sylvain Le Gall a écrit : It does it the right way ;-) The I'm going to vomit files across your whole file system so that you need another bureaucratic tool/database too keep track of what I did whenever you want to remove me way. Sure if you're looking for a business model and more bureaucracy that's the way to do it the right way. The key insight in things like gnu stow or homebrew is that this tool/database already exists, it's the file system itself, KISS principle. And this simplicity also allows you to deal very easily with multiple version installs of the same package. I would probably object to have html documentation in the $SITELIB of findlib. To me that seems to be an ideological objection (debian related I guess), I don't see any technical objection. KISS should be applied here: I installed that package in that directory anything related to it is in that single directory. I think a CHANGES/README is light enough to be in $SITELIB as well. CHANGES and README light, html heavy ? For one thing keep it at least consistent either you choose to put nothing in SITELIB or everything. I don't want to have to lookup two different places for documentation. To be honest, if it was the only problem I have to solve, I'll be happy to spend hours on that. I don't think it's a good idea for the whole system to underestimate the importance of documentation. But all this need to be more widely discuss (with OCamlPro for TypeRex, Maxence for .odoc/Cameleon, Gerd for ocamlfind and the rest of the community to have a real agreement on this point). I'm all for it, but now that I'm in these things I want to move forward. So what should I write something like this (currently) nop ? Document xmlm Title: Xmlm documentation and module reference Format: html Index: Xmlm.html Install: true InstallDir: $docdir DataFiles: CHANGES README doc/*.html, doc/*.css Or should I make another Document for CHANGES README ? Well _oasis can also go there, even though it will be a little bit a duplicate with META... It also has much more information in a machine readable format. Like the home page of the project, the maintainers, maybe even the repos etc. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: oasis packaging questions
Le jeudi, 8 mars 2012 à 23:26, Sylvain Le Gall a écrit : Do you think it make sense to include this at the beginning of setup.ml ? I just don't see myself using setup.ml during developement, I use a light (funny to quote Gabriel Scherer) shell script that has a few targets and falls back to ocamlbuild if nothing matches. That way if I quickly want to compile something (e.g. type checking a module) I can just ./build module.cmo. Want to test something, just create test.ml and invoke ./build test.native. If I had to use setup.ml I would first have to write a lot of things into that _oasis file only to remove them later. But setup.ml seems perfectly fine to me as a standard build script for distribution, keep the focus on that. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] odb questions
Hello, A few questions about odb. 1) Is it possible to specify in ~/.odb/packages a remote packages file (instead of just individual remote packages) ? 2) How does odb find out and manage dependencies ? How can I list them before installing a package ? 3) Are multiple versions of the same package supported (à la homebrew on osx) ? 4) Is something like odb install -file package.tbz possible ? The use case for 4) is both for testing and so that I can instruct my users once they have downloaded a tbz and went through the README that they can just install it with that command (provided they have installed other deps). Daniel P.S. I think odb should use a odb cmd scheme. Instead of just installing on odb pkg. The former scheme has better scaling opportunities. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
Le mercredi, 7 mars 2012 à 15:37, Edgar Friendly a écrit : Not at the moment, but this is an interesting idea. The only support for remote packages is the querying of oasis-db. The protocol is nearly trivial, so you're welcome to make your own server (can be just a plain web server serving static text files) and set the odb repository URL to it. Okay. Would be nice to have the support in the tool and documentation on how to make your own package source (basically GET on a ~/.odb/packages file ?). Package distribution should be distributed. The other end of this is handled by odb's metadata that specifies things like where to get the source code, dependencies, installation requirements, and other useful information for installing. There are two sources for this metadata: 1) oasis-db by http 2) packages files locally. The packages files are parsed on startup, if odb needs info about a package not in this cache, it queries oasis-db for the metadata. By 2) you mean what is described in Local packages here : https://github.com/thelema/odb ? Because the syntax for specifiying deps is not documented. I like the idea of printing deps without installing, and it should be pretty easy to implement. It'd probably suffice to just print the whole metadata; it's quite readable. Maybe metadata + dependency check will satisfy your needs? Why not ? This is supported in two ways. First through environment variables that basically switch between different ocaml installations / ocamlfind root paths. Odb relies on findlib to manage libraries, and it supports this through tweaking install paths. The other way is to have packages batteries1 and batteres2 that both install different versions of batteries, and as long as they register in findlib with the names batteries1 and batteries2, odb will treat them as different. IMHO a package should be identified by a name and version. It's planned to be able to give a full package info on the command line, so this would be more like: odb tarball=package.tbz deps=odn,batteries That would be nice. The current way to do testing is to put a line in your local packages file (two locations that are scanned for one: ~/.odb and the odb script dir), and use the info there for testing. Okay but how do I specify deps ? I'm sure I can quickly find out but I want you to update the docs... Except I don't intend odb to scale. Pity. It's hovering right around 500 lines of code, and if I can keep it around that size, I'll be happy. That's indeed a good thing, aswell as no deep deps. But hey, setup.ml is around 10x more (which makes it unusable for dev. btw.) you still have some way to go. I don't intend odb to ever have a `odb remove foo` command, nor an `odb update`. Maybe I'll have an `odb upgrade`, but I'm happy leaving this as `odb --upgrade`. Odb's goal is to be an 80% solution, and it was that a while ago, I think. It's approaching 90%, and I'm going to try to avoid it feature creeping to 100%. Oddities should be handled by the package installers themselves or the metadata repository as much as possible, leaving pretty little work for odb. Pity. I like odb's down to earth approach. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
Le mercredi, 7 mars 2012 à 16:58, Edgar Friendly a écrit : IMHO a package should be identified by a name and version. I've been thinking about this for a long time, and the full consequences of this involve not only deep changes to odb internals, but also expose the code to a ton more edge cases that need to be handled, as well as possibly some NP-hard problems of resolving version dependencies. Odb may go this way if needed, but the current practice of having a single string as the package identifier is sufficient for my use, so... Yes, I understand that. I fear there's dependency hell waiting around the corner, but maybe this can be mitigated by implementing that idea of being able to easily specify your own package source in ~/.odb/packages. Well, in fact you can already do that locally by crafting your own ~/.odb/packages file. So maybe your approach is the right balancing act between usability and complexity. You're more than welcome to fork and build a better odb. I may even steal any good ideas you have and put them back in my odb. :) If I get too annoyed with too much time on my hands (i.e. very unlikely) I may eventually do that. Thanks for the answers and the tool, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] oasis packaging questions
Hello, I'd like to support oasis in the various packages I distribute. Here are a few questions (using oasis v0.3.2~rc2). 1) All the packages I distribute are made of a single module. For now these were just installed as .cmo .cmx .cmxs. Now it seems oasis forces me to create a .mllib even if I have only one module. Is that correct ? 2) Will the change in 1) have any impact for downstream packagers and is setup.ml enough for them ? 3) The META plugin doesn't seem to generate the directives for plugins [1], is that right ? Does setup.ml support cmxs generation at all ? 4) I'm really not interested in oasis trying to generate my _tags and myocamlbuild.ml files. Is it ok to substitute my own or does setup.ml rely on these ? 5) One of the disadvantages of things like odb is that you may miss valuable information like a CHANGES file, proper documentation or sample programs. These are also things you actually would like to remove when you do a ocamlfind remove. Is there any general agreed on strategy for packages ? Best I think would be to install that along in the package directory with ocamlfind, it makes it relatively easy/evident to lookup. 6) Regarding 5) I tried to define documentation as follows : Document xmlm Title: Xmlm documentation and module reference Format: html Index: Xmlm.html Install: true InstallDir: $htmldir/xmlm DataFiles: README CHANGES doc/*.html, doc/*.css but ocaml setup -install doesn't seem to install it. Of course this is also certainly a wrong strategy since it would install it in some directory that wouldn't be removed by ocamlfind remove. So how do we achieve that ? 7) ocaml setup -install seems to install the modules' .mli, .cmi and .cmx by finding them in _build capitalizing the filenames even though they are not (cf. [2]). That works on my case insensitive filesystem, but it mustn't work on others, the original files are not capitalized !? Is that a bug ? Thanks, Daniel [1] http://groups.google.com/group/fa.caml/browse_thread/thread/460ba4d505e29c62 [2] ocaml setup.ml -install I: Installing findlib library 'xmlm' I: Running command '/usr/local/bin/ocamlfind install xmlm src/META _build/src/Xmlm.cmx _build/src/Xmlm.cmi _build/src/xmlm.a _build/src/xmlm.cmxa _build/src/xmlm.cma src/Xmlm.mli' Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.mli Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.cma Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.cmxa Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.a Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.cmi Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.cmx Installed /usr/local/lib/ocaml/site-lib/xmlm/META -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] TypeRex release 1.0.0 candidate 1
I love it. This fulfills so many of my wishes. Thank you. Anyway, would it be possible to include, in the distribution a theme matching the mode of OCaml's distribution ? Here's a workaround : (setq ocp-syntax-coloring nil) ; Hack to get caml-mode color scheme (setq load-path (cons ~/.emacs.d/caml-mode load-path)) (if window-system (require 'caml-font)) (add-hook 'typerex-mode-hook 'caml-font-set-font-lock) Disregarding the menu showing the possible completions, is it significantly different from 'dabbrev-expand ? Is it module-aware, couldn't for example complete the symbols from List.* ? Problem gone, it is module aware. Not type aware (maybe in the future according to Thomas), however if you wait a little bit it will tell you the type of the selected completion. I did however disable automatic completion (annoying anyway), it sometimes hangs my typing. That did it for me (shift tab to invoke auto completion) : (add-to-list 'load-path ~/.emacs.d/auto-complete-mode) (setq ocp-auto-complete t) (global-set-key (kbd S-tab) 'auto-complete) (setq ac-auto-start nil) Here [1] are things ocamlbuild users should know and here's [2] an ocp-env script. Best, Daniel [1] https://github.com/OCamlPro/typerex/issues/8 [2] https://github.com/OCamlPro/typerex/issues/6#issuecomment-4126540 -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Fwd: Re: [Batteries-devel] browsing the code while reading the doc
Le mercredi, 15 février 2012 à 10:55, Gerd Stolpmann a écrit : Before you start writing a total new custom formatter (which probably breaks with every major OCaml version because of new syntactic elements), consider to extend/override the standard formatter. It seems then that the best option for everyone would be to have a good standard formatter in the distribution per se. These days css is on the verge of becoming Turing complete (if not already) and if the right data's here a little bit of javascript may cater most needs. However currently, the html generated by the standard formatter is invalid and the content littered with presentational elements (e.g. br) or inconsistent markup which makes it a nightmare to process and style with css. Best, Daniel P.S. With respect to the original request, I once asked to turn ocamldoc into a full html code browser. But the wish was not granted : http://caml.inria.fr/mantis/view.php?id=4443 -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] state of native dynlink on os x
Can't precisely answer your questions but : to understand what is the state of things on os x. According to this message http://alan.petitepomme.net/cwn/2008.10.21.html natdynlink does not work on 10.5 and above. At least here it does work without problems on 10.6.8. with this [1] config. Best, Daniel [1] ocamlc -config version: 3.12.0 standard_library_default: /usr/local/lib/ocaml standard_library: /usr/local/lib/ocaml standard_runtime: /usr/local/bin/ocamlrun ccomp_type: cc bytecomp_c_compiler: gcc -fno-defer-pop -no-cpp-precomp -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT bytecomp_c_libraries: -lcurses -lpthread native_c_compiler: gcc -D_FILE_OFFSET_BITS=64 -D_REENTRANT native_c_libraries: native_pack_linker: ld -r -arch x86_64 -o ranlib: ranlib cc_profile: -pg architecture: amd64 model: default system: macosx asm: as -arch x86_64 ext_obj: .o ext_asm: .s ext_lib: .a ext_dll: .so os_type: Unix default_executable_name: a.out systhread_supported: true -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Functional GUI programming: looking for good practices
Le mardi, 14 février 2012 à 11:02, Philippe Veber a écrit : In other words, am I allowed to call a primitive in a lifted function? No. This is documented here [1]. One way to side-step the issue is to put these updates in a queue and execute them after the update cycle ended. Best, Daniel [1] http://erratique.ch/software/react/doc/React#update -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Functional GUI programming: looking for good practices
Le mardi, 14 février 2012 à 12:52, Adrien a écrit :
Quite often, doing so does not make a lot of sense.
Suppose that you have a signal A. An external event triggers an update which
will create A1. But during that update, you trigger another update which
will create A2. Now, how does your signal change? Is A2 going to be the next
value of A or is will it be A1?
Yes it doesn't make any sense at all.
An update cycle is made under a synchrony hypothesis, everything therein
happens simultaneously, at the same time t. The semantics of a signal (resp.
event) [1] is a *function* from time to a value (resp. optional value). There's
no way a signal (resp. event) can have two different values for the same time
t, this should raise a red flag. Besides by definition two primitive events
cannot (should not, since the system cannot enforce it) occur at the same time
t [2].
When in doubt, it helps to get back to the semantics to see if your interfacing
mechanic to react actually respects FRP's semantics. And if it doesn't and you
can't fix it, I wouldn't try to use react for the problem.
Best,
Daniel
P.S. to Philipe
I'm not exactly sure what you problem is. But if you are trying to define a
signal that somehow depends on itself, make sure you did understand the
{E,S}.fix combinators [3]. I'm sure I had to use it once or twice to define the
(very primitive) UI of the breakout.ml example from the distribution.
[1] http://erratique.ch/software/react/doc/React#sem
[2] http://erratique.ch/software/react/doc/React#simultaneity
[3] http://erratique.ch/software/react/doc/React#recursion
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] SQL engine in OCaml with client side cache
Le dimanche, 29 janvier 2012 à 10:56, Diego Olivier Fernandez Pons a écrit : Therefore I thought I could add a cache on the client side, meaning an in-memory SQL database that would receive a big block of data from the server and work on it till the client writes a query that needs some data that is not available locally in which case it would request it from the server, etc. I haven't found anything like that ready-to-use, so I was considering reengineering existing OCaml code (database + web) and maybe compile it to JavaScript. I have control on the client so I can afford installing an OCaml runtime if needed albeit impractical though. If you can afford to install recent browsers, on the javascript side. Webdatabase [1] would have made your day but the spec has been withdrawn. It seems work along these lines was pursued in IndexedDB [2] but it may be a little bit early to use it. If the dataset is not too huge and your queries are simple enough you may be able to hack a thin layer on top of webstorage [3]. But beware that this gives you no more than a persisent hashtable and I have no indication of the kind of performance you'd get. The advantage is that this is a candidate recommandation. Note, I have used neither of those. Just know their existence. Best, Daniel [1] http://www.w3.org/TR/webdatabase/ http://caniuse.com/#search=websql [2] http://www.w3.org/TR/IndexedDB/ http://caniuse.com/#search=indexed [3] http://www.w3.org/TR/webstorage/ (http://www.w3.org/TR/webstorage/#storage) http://caniuse.com/#search=webstorage -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Examples where let rec is undesirable
Sorry Richard I should have elaborated a bit more. I guess there are a couple of examples in the literature, but one of them comes to my mind, consider the following code snippet: let fd = Unix.open myfile1 ... in let fd = Unix.open myfile2 ... in ... (some code) Unix.close fd This causes a file descriptor leak that is hard to detect statically in general. If you mean detect statically by a _program_, then this makes absolutely no difference. A static analyzer could alpha rename the term so that each name is unique or work with De Bruijn indexes without changing the complexity of the problem. If you mean detect statically by a _programmer_ then yes, variable shadowing can be a good tool to write obfuscated code. As a rule of thumb, I think it's better to give different conceptual objects different variable names, which also improves self-documentation. Agreed. (I'm sure also got caught at least once by something like your first example). Within nested scopes, all objects declared with a let-binding are usually distinct conceptually. Not necessarily. I think what Łukasz mentions about incrementally transformed values and cognitive burden is very true and in these cases I wouldn't consider name recycling a bad style. One example is working with a purely functional datastructure like Set.t where you need to perform a few applications before getting to the only value you are interested in. The alternative would be to simply not name the intermediate results, it may be possible but sometimes writing the sequence of application explicitly by a serie of lets makes the presentation and the code clearer [1]. Best, Daniel [1] Somewhat related is point-free style programming of which haskellers are very fond of. A little bit of it is nice, but I think it sometimes makes the cognitive burden too high. There's a balance between conciseness and readability. Somehow programmers are obsessed by the former at the detriment of the latter, but a good balance is needed. This example (from this [2] wikipedia page) speaks for itself : mf criteria operator list = filter criteria (map operator list) vs mf = (. map) . (.) . filter I'm sure we all agree the former is easier to grasp. [2] http://en.wikipedia.org/wiki/Point-free_programming -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Let-less syntax for coreML
The underlying question is how to make ML mainstream which is what the Am I the only one to be very, very, very, tired of this question ? There's an obvious thing missing in the list of what has been tried. Well-done and maintained libraries you can use for about any programming task you have at hand -- but I highly doubt this will make ML mainstream either, I'm just defending my own interest. IIRC you used to be a library designer, please stop fiddle with the syntax of the language. Library design is also language design. Pick a missing OCaml library you'd have interest in implementing (e.g. a good interface to imap protocol but you may not be interested in that) and fill in the void with a great, modular and tasteful implementation. Best, Daniel P.S. If you think syntax is the main answer to the question above maybe you should have a chat with users of mainstream programming languages. In my experience, you'll soon see that their tastes and philosophical view points on programming are rather different than yours (which may be due to ignorance, lack of education and marketing influence but that's rather presumptuous for me to say). -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
oasis (was Re: [Caml-list] Let-less syntax for coreML)
On 4 January 2012 13:18, Yaron Minsky ymin...@janestreet.com wrote: I think the biggest thing the community can do to improve OCaml is not to tweak around with language design. It's to improve the library packaging situation. Oasis seems to be the effort in this direction that has the most momentum, so I think pushing Oasis to become every bit as good as Hackage and Cabal is really the place to get maximum leverage. Agreed, and all my packages will eventually support oasis. This was planned about half a year ago but I was told it would be simpler for me to wait for oasis-db 0.1.0~alpha3 but somehow that never materialized. I see two problems with oasis right now : 1) It seems Sylvain doesn't have much time to work on the system. Oasis tries to solve (IMHO too) many problems and is therefore a significant piece of software. This means it is less easy to contribute to and if Sylvain doesn't work on it, the project grinds to a halt. I think Sylvain, in order to gain acceptance maybe tried to be too inclusive feature-wise w.r.t. to dev practices -- not to mention that as a debian packager he also had ideas to save time there. It is perfectly understandable but it may have had some perverse effects on the complexity of the system. If I may, I would like to suggest to Sylvain that development of the oasis and oasis-db should entirely focus on the infrastructure needed so that a reasonable and useful set of packages are able to work with something like odb.ml. To give an example, oasis-db as the human browsable website is a very nice plus (e.g. I do enjoy browsing on hackage), but it is a significant piece of work and IMHO just shouldn't be a priority. By showing us that something like odb.ml actually solves the problems we have as ocaml developers --- quickly install this (high-quality of course) lib to help me write my program --- I'm sure the supposedly stubborn library devs would be willing to change and standardize their practice around those mandated by oasis and this could lead to a simpler system (vs. trying to please everyone). Just give us something that you have enough confidence in and tell us, this is usable now, use it, it may have limitations, but it already helps. And after iterate on that to eventually get to the big, planned system -- or not. 2) The current documentation is useless. When I did the _oasis file for cmdliner I had to find what the actual value of OASISformat should be by trial/error... The documentation provides a high-level description of all the available fields for _oasis files but it doesn't precisely describe their _syntax_ (types !) and their _effect_. It also doesn't describe how the system works from an architectural perspective. We need a good manual -- and please not a wiki. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: how could the community help with Oasis-DB; towards a CPAN for OCaml?
I tried to use Oasis on one of my projects. I got stuck at the very begining. I am on MacOS, there is no binary installer, and no instructions for MacOS users. It told me a bunch of dependencies were unsatisfied when I tried to compile. Agreed. Installing the dependencies on osx is just too painful. But as I said before on this list, instead of providing binary installers, I think it would be much more productive for users and oasis devs to be able to bootstrap oasis provided with a raw ocaml install and a reasonably posix compliant unix system (let's pretend I didn't follow the discussion on ocaml for windows). Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] Argot: 1.0 release
Hello, A few comments on the design. Overall much better than ocaml's current stylesheet and completely web 2.0 correct. But. One problem of web 2.0 correct interfaces is that they are a little bit patronizing, and don't show enough data. The information density is too low. Do you really half of my screen to communicate me the name of the module I'm currently looking at ? Overall I find the spacing to be too loose. I want to see more information on a screenful. Much more can be shown, while retaining the ability to rapidly skim from one definition to the other and without cramping the design. Another thing is the fixed-width layout. The width of the page is too wide. First the lines are too long which causes a readability issue: it makes it hard to read from one line to the other --- depends on the font but beyond approx. 80 chars per line it becomes hard for continuous reading. Second I personally never work on 27-inch displays. With the current design I cannot put my browser window next to emacs and read the doc without a horizontal scroll bar. The design grid should be fluid, within reasonable limits (cf. css's min-width, max-width and if you want to go wild, media queries to use different style sheets for different devices widths, a few techniques and pointers here [1]). Finally do something with css' *:target selector it's useful when you link to anchors that are at the bottom of a page or on a page that is too small to scroll. E.g. : http://erratique.ch/software/cmdliner/doc/Cmdliner.Arg.html#VALpair The goal is to be able to browse it locally (it's a bit awkward to have to run a webserver to read documentation). Yes. The searching tools are quite limited currently, To me the search tools are not so useful. Usually I know in which module I want to lookup a function. To get there quickly I use my OS file search --- thanks to ocamldoc generating one file per module --- and then the incremental search of my browser. Of course this is quite different of indexing e.g. the symbols directly but it works well in practice. But having been recently forced out of emacs into a proprietary IDE to be *able* to work on a project written in a programmingLanguageWithAbsurdlyLongNamingConventions, one thing I actually became very fond of is type aware autocompletion and the ability to browse from a symbol in my code directly to the page where its documented. The former may be complex to implement without compiler support but I'm sure the latter is not. My elisp skills are however too limited for me to implement that myself but I'd love to have that in ocaml's emacs mode. Regarding search by type, I wonder if people actually use this for useful reasons or if it's just out of curiosity or for the cool hack factor -- and sure it's cool. I mean there's not enough semantics in types to tell you what a function will do, and since we curry it is not always clear in which order we will argument. Best, Daniel [1] http://www.alistapart.com/articles/responsive-web-design/ -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] Argot: 1.0 release
I do agree that there is often not enough semantics in OCaml types, but please notice that the order of arguments and whether the function is currified is not relevant. Indeed, doing type search up to isomorphisms allows to get rid of these details, Ha. I slipped the up to isomorphisms part. Quite cool indeed. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Re: Jump-to-definition and type-aware completion for Caml (was : Argot 1.0 release)
Thanks for all the links. Beware that all those projects tend to be built as patches to the ocaml distribution, which means difficult deployment (which means few users, which means few maintenance, which means bitrot). That's the problem. I tend not to rely too much beyond what is provided by the standard distribution. You may also have a look at the various attempts at integrating OCaml with Java IDEs (Oca'IDE, Ocaml Development Tools, etc.). Well I'm really not fond of IDEs. I usually find them very invasive and bureaucratic and I'm not productive in them. So far emacs is the only system that works really well for me (it's also an IDE that works everywhere, even in the terminal). But I have to admit that some IDEs provide features that I would like to have in the emacs modes I use. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Jump-to-definition and type-aware completion for Caml (was : Argot 1.0 release)
If you do not trust me (and you should not :-) ) I trust no one anyway... The problem is more what Gabriel perfectly captured by : Beware that all those projects tend to be built as patches to the ocaml distribution, which means difficult deployment (which means few users, which means few maintenance, which means bitrot). Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Cross-platform cpu count
It won't - Sys.os_type returns Cygwin and getconf isn't in Cygwin either - http://cygwin.com/ml/cygwin/2010-12/msg00435.html (actually, it may be now - I haven't upgraded my Cygwin in a while - but it'll be a recent addition) Ok thanks. Apparently it may eventually [1]. Personally, even for something where it's unimportant, I'd be nervous relying on an environment variable (which can be edited...) I'm even more nervous about calling command line tools. The right way would be to use sysconf(3) or systcl(3), but Sys or Unix doesn't provide them. Best, Daniel [1] http://www.mail-archive.com/cygwin-patches@cygwin.com/msg05220.html -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Cross-platform cpu count
Hello, Can anybody confirm me that the following code works on cygwin : let cpu_count () = try match Sys.os_type with | Win32 - int_of_string (Sys.getenv NUMBER_OF_PROCESSORS) | _ - let i = Unix.open_process_in getconf _NPROCESSORS_ONLN in let close () = ignore (Unix.close_process_in i) in try Scanf.fscanf i %d (fun n - close (); n) with e - close (); raise e with | Not_found | Sys_error _ | Failure _ | Scanf.Scan_failure _ | End_of_file | Unix.Unix_error (_, _, _) - 1 Thanks, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Great Renaming
Now implemented here aswell : http://ocamlunix.forge.ocamlcore.org/ Btw. would it be possible to mention that link on this : http://caml.inria.fr/resources/doc/index.en.html page ? Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
