<tsuyoshi>
I wonder if I kind of wasted my time creating an unsigned type
<tsuyoshi>
I could just wrap Big_int with some range checks
<tsuyoshi>
since for this particular application, speed of arithmetic is not important
<tsuyoshi>
gah.. I think that would be better
<tsuyoshi>
I could get rid of a lot of c that way
coucou747 has joined #ocaml
Philonous1 has joined #ocaml
Philonous has quit [Connection timed out]
travisbemann has joined #ocaml
coucou747 has quit [Read error: 60 (Operation timed out)]
mbishop has quit [Read error: 60 (Operation timed out)]
marmotine has quit ["mv marmotine Laurie"]
seafood has joined #ocaml
coucou747 has joined #ocaml
Snark has joined #ocaml
mbishop has joined #ocaml
seafood has quit [Connection timed out]
seafood has joined #ocaml
Associat0r has joined #ocaml
<Camarade_Tux>
wow, that guy (tsuyoshi's link) really scares me :o
Linktim has joined #ocaml
Snark has quit [Read error: 113 (No route to host)]
Jeff_123 has joined #ocaml
<Jeff_123>
join #erlang
<Jeff_123>
doh!
<flux>
mbishop, I suppose one wouldn't really need language support, camlp4 should come to the rescue?
* Jeff_123
grumbles
Linktim_ has joined #ocaml
travisbemann is now known as travis|away
bluestorm has joined #ocaml
Linktim has quit [Read error: 113 (No route to host)]
Linktim has joined #ocaml
netx has quit [Read error: 110 (Connection timed out)]
Axioplase has quit ["leaving"]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
coucou747 has joined #ocaml
Linktim_ has quit [Read error: 110 (Connection timed out)]
itewsh has joined #ocaml
asmanur has joined #ocaml
Linktim_ has joined #ocaml
guillem_ has joined #ocaml
Yoric[DT] has joined #ocaml
Linktim_ has quit ["Quitte"]
Linktim has quit [Read error: 110 (Connection timed out)]
Linktim has joined #ocaml
Snark has joined #ocaml
<Yoric[DT]>
hi
<bluestorm>
Yoric[DT]: the -0 release was a good idea :]
<Yoric[DT]>
Thanks:)
<bluestorm>
i asked myself yesterday, what's your position about Core ?
Associat0r has quit []
<Yoric[DT]>
"Need to investigate"
<bluestorm>
(this is a mean political question; actually i'm interested in your position about the nice modular things they have such as Comparable and the like)
<Yoric[DT]>
I have nothing against core, actually.
<Yoric[DT]>
My essential problem is that they have modules with the same name as ExtLib.
<bluestorm>
:p
<Yoric[DT]>
And that means that we can't link both projects in one program :(
<bluestorm>
hm
<bluestorm>
is it not possible to pack the libraries in a super module ?
<Yoric[DT]>
I've tried that and it didn't work.
<bluestorm>
ah
<bluestorm>
but iirc Core is designed to directly replace the OCaml stdlib, so it's quite invasive indeed
<bluestorm>
(do you intend Batlib to run with -nostdlib ?)
<bluestorm>
ah
<Yoric[DT]>
If it works, yeah.
<bluestorm>
another thing i think you should specify, is the possible depencies between the Batlib modules
<bluestorm>
i'm afraid that without a policy regarding this, we could someday be led to a circular dependency situation
<Yoric[DT]>
mmmhhh....
<Yoric[DT]>
Fair enough.
<Yoric[DT]>
I kind of hoped that I could push that problem onto GODI :)
<bluestorm>
:p
netx has joined #ocaml
<Yoric[DT]>
bluestorm: if you have some time, would you take the time to try and get a -nostdlib to work?
<bluestorm>
hm
<bluestorm>
i'm totally incompetent regarding those things
<bluestorm>
but, why not
<bluestorm>
Yoric[DT]: yesterday, i tried to generate a dot file from ocamldoc (because i like those little things with arrows), but ocamlbuild is a severe limitation in that area
<Yoric[DT]>
From Batteries or unrelated?
<Yoric[DT]>
But yeah, ocamlbuild and ocamldoc don't play that nicely together.
<bluestorm>
from batteries
<bluestorm>
i think it should be fixable, because ocamlbuild has a built-in html generation available
<bluestorm>
but hacking ocamlbuild is a bit too divergent for now :-'
<bluestorm>
(and, apart from those little things, it is a nice tool)
<Yoric[DT]>
Yep.
<bluestorm>
btw., it could be nice to host the -0 html documentation somewhere
<bluestorm>
it's easy to build but people could be interested in a quick overview
<bluestorm>
(i can upload it in bluestorm.info if you're interested)
<Yoric[DT]>
Good idea.
<Yoric[DT]>
There's some space on the Forge for it, too.
<Yoric[DT]>
I'll try and do that after lunch.
seafood has quit []
hkBst has joined #ocaml
<bluestorm>
btw , gildor : someone noticed that there is no OCaml section in the "Code Snippets" page
<Yoric[DT]>
(putting it in two places won't hurt, though)
<bluestorm>
i think a bit of specialization of those forge pages could help
<bluestorm>
Yoric[DT]: i'm actually trying to figure how to use the forge ftp space
<Yoric[DT]>
ok
<Yoric[DT]>
Gottago, though.
<Yoric[DT]>
See you later.
seafood has joined #ocaml
ttamttam has joined #ocaml
ttamttam has left #ocaml []
tomh_-_ has joined #ocaml
Associat0r has joined #ocaml
guillem_ has quit [Remote closed the connection]
Amorphous has quit ["shutdown"]
<gildor>
bluestorm: ok
<Proteus>
have any of you heard of the Haxe project? It's a comprehensive web programming language/framework/vm written entierly in Ocaml. It's quite impressivel
<bluestorm>
yes i have
<gildor>
its from nicolas cannasse et al
<bluestorm>
Nicolas Canasse is also involved in Extlib
<Proteus>
yrsh
<Proteus>
yeah
<Proteus>
an, I didn't know that
<bluestorm>
and xml-light
<Proteus>
or that
<bluestorm>
wich i use sometimes because it's nice and simple
<Proteus>
damned impressieve work though. It looks profressional.
<bluestorm>
haxe is quite impressive as a blend of mainstream languages and MLish features
<Proteus>
yeah
<Proteus>
I haven't tried it out yet, but it looks quite intriguiging
<bluestorm>
it generally lacks marketing and documentation
<Proteus>
sadly, that's an endemic problem with open source projects
<bluestorm>
and i'm not sure he really succeeded at hiding the specificities of the uner-the-hood languages used (php, flash, etc.); not sure it's an issue though
<bluestorm>
Proteus: actually, the games motion-twin creates with Haxe are quite popular in France
<Proteus>
I wish I was in France :(
<bluestorm>
gildor: do you know how i can get an ftp access to the ftp space of a project ?
<bluestorm>
bluestorm@batteries.forge.ocamlcore.org leads me to something that looks like a personal space
<bluestorm>
(bluestorm@forge.ocamlcore.org points to the same place)
<bluestorm>
with an "incoming" folder, wich is not on ftp://batteries.forge.ocamlcore.org/pub/batteries/
<gildor>
bluestorm: let me try
<Proteus>
can haxe and ocsigen be elegantly miexed?
<Proteus>
mixed
<bluestorm>
Proteus: probably not
<gildor>
bluestorm: lftp forge.ocamlcore.org
<gildor>
cd pub/batteries
<Proteus>
bluestorm, figured as much
<bluestorm>
gildor: but then i don't have write access, do I ?
<gildor>
no you don't
<bluestorm>
i'd like to upload documentation there
<gildor>
use scp
<bluestorm>
hm
<bluestorm>
Permission denied (publickey).
<gildor>
have you updated your SSH key ?
<gildor>
of your account
<bluestorm>
hm
<bluestorm>
probably not, i'll check that, thank
<bluestorm>
s
<gildor>
you need to have one that don't suffer ssh vulnerability problem
<bluestorm>
i'll upload them on the forge ftp when i get write access
<Yoric[DT]>
It's a link to bluestorm.info, is that it?
<bluestorm>
yes it is
<bluestorm>
i'll replace it with a batteries.forge.ocamlcore link when possible
<Yoric[DT]>
ok
<Yoric[DT]>
I'm sending that on the mailing-list.
<Yoric[DT]>
Unless you want to do so.
<bluestorm>
hm
<bluestorm>
i'm not sure it's necessary
<bluestorm>
hm
<bluestorm>
it might actually be nice as a follow-up of your annoucement, you're right
<bluestorm>
but you should give the url of the forge access, not the hard bluestorm.info one, so that it's resilient to change and future versions :]
<Yoric[DT]>
Yep.
<Yoric[DT]>
Sent.
<mfp>
"Many readers will already know that the OCaml programming language is widely used in the finance industry. What many people do not know is that workers in the finance industry often live on the bread line and, consequently, they have no choice but to find ways to obtain essential items cost effectively." lol
<Yoric[DT]>
Where's that from?
<mfp>
jdh via planet.ocamlcore.org
<Yoric[DT]>
Nice.
Linktim has quit [Read error: 110 (Connection timed out)]
<mfp>
it could hardly be more gratuitous
<bluestorm>
hm
<mfp>
wonder what the "ingenious gambles made by workers in the finance industry helping to drive down the prices of essential European goods" are (where essential goods = OCaml for Scientists haha)
<bluestorm>
btw., have you seen the "unit" feature of the last F# release ?
<bluestorm>
they claim it's useful to physicists and finance workers
<mfp>
what does it do?
<bluestorm>
well
<bluestorm>
basically they have an unit inference in the type system
<Yoric[DT]>
Nice.
<Yoric[DT]>
I wanted to implement that in OCaml, a few years ago.
<bluestorm>
so that 1.<kg> / 1.<s> = 1.<kg/s> or something like that
<Yoric[DT]>
Never quite got around to doing it.
Linktim has joined #ocaml
<Yoric[DT]>
(especially since you have no equational theories in the type system)
<Yoric[DT]>
Well, it's disappointing.
<Yoric[DT]>
Plenty of people look at the blog entry on Batteries.
<Yoric[DT]>
But no comments, neither on the blog, or reddit or on the mailing-list :(
<mfp>
don't expect much from proggit
<bluestorm>
hm
<bluestorm>
your "what's up with batteries" post had some effect
<Yoric[DT]>
Yep.
<Yoric[DT]>
That's why I'm disappointed for the next post :)
<bluestorm>
well, you shouldn't expect immediate reaction : there is code to try and play with and that takes some time
<mfp>
it was mostly because dons posted there
<mfp>
I observed something interesting yesterday
<mfp>
I sent orpc's link, and got easily +8 or so (15/7) in the morning
<mfp>
then it was downvoted in anger to -4 in the afternoon
<Yoric[DT]>
Why?
<mfp>
I don't know if it was downvoted by those who are sick of functional prog links or by those who prefer non-strict semantics :-P
Linktim_ has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
:)
Linktim_ has joined #ocaml
im_alone has quit [Read error: 110 (Connection timed out)]
im_alone has joined #ocaml
<Yoric[DT]>
ertai: ping
itewsh has quit [Read error: 113 (No route to host)]
<Yoric[DT]>
(I have a question regarding the use of OCamlBuild modules from outside myocamlbuild.ml)
Linktim has quit [Read error: 110 (Connection timed out)]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
<Yoric[DT]>
Now, let's hope that ExtLib will accept our upstream patches.
<Yoric[DT]>
Because that's something of a show-stopper.
rwmjones has joined #ocaml
<Yoric[DT]>
hi rwmjones
Proteus has quit [Read error: 104 (Connection reset by peer)]
Proteus has joined #ocaml
<rwmjones>
Yoric[DT], afternoon!
<rwmjones>
Yoric[DT], sorry, it'll have to wait a bit -- wife calling
<Yoric[DT]>
:)
itewsh has joined #ocaml
<bluestorm>
Yoric[DT]: actually
<Yoric[DT]>
Yes?
<bluestorm>
i'm considering splitting your enum patch in parts
<bluestorm>
hm
<bluestorm>
while doing that i discovered that the destructive behavior of Enum can be really daunting
<Yoric[DT]>
That's why there's also a Lazy List :)
<bluestorm>
yes but i hear you want to use Enum as a default collection structure
<Yoric[DT]>
collection structure as in the default manner of going from one data structure to another, yes
<bluestorm>
is there any advantage of destructive collections over functional ones ?
<Yoric[DT]>
Well, traversal is typically easier.
<bluestorm>
(having a default is a good idea imho, it could avoid the datastructure creep eg. in your comprehension extension)
<bluestorm>
hm
<Yoric[DT]>
And yes, the comprehension extension will eventually be rewritten with Enum.
<bluestorm>
i'm a bit afraid of having a standard whose behavior does not feel natural
<Yoric[DT]>
What would you use?
<Yoric[DT]>
Unfolding?
<bluestorm>
for example, your "take" function behave strangely
<bluestorm>
if you create a stream sb by taking the 10 first elements of sa, when you read sb, sa element get discarded
<Yoric[DT]>
Well, I attempted to conserve the notations introduced in extList.
<bluestorm>
if you mean the function name, they're nice
<bluestorm>
what i find unpredicable is the destructive behavior
<Yoric[DT]>
Well, think of enumerations as beefed-up streams.
<Yoric[DT]>
Consuming them is the natural thing to do.
<Yoric[DT]>
If you don't want to consume, switch to lazy lists, it's just one function call away.
<bluestorm>
is there an efficiency advantage of the destructive behavior over the waiting-for-the-GC lazy-list approach
<bluestorm>
?
<bluestorm>
hm
<bluestorm>
i can see a reason for choosing a destructive collection as the common collection structure
<Yoric[DT]>
Well, yes.
<bluestorm>
you can easily build a destructive collection from a non-destructive one, while the reverse would create unsound elements
<Yoric[DT]>
For large data structures, waiting-for-the-GC may be a very bad idea.
<Yoric[DT]>
How so?
<bluestorm>
hm
<bluestorm>
i mean, lazily
<Yoric[DT]>
You just copy the elements of the destructive collection into the non-destructive collection as needed.
<Yoric[DT]>
Yes, lazily.
<Yoric[DT]>
That's exactly what I do in LazyList.of_enum .
<bluestorm>
hm, right
<Yoric[DT]>
I do fix a bug along the lines of what you just said.
<Proteus>
I know this is off the crrent toppic and please excuse me for asking a rather newbie question, but what what ocaml functions are the least performant compared to, sau, C - when ocamlopt is used. I'm working on a game engine and it would be immesnlsy useful ito know this. Now, I know I could write some sciript to figure tihs out and I'm speaking very generally, but i'm hoping I can save a good chnuk of time by asking you fine fellows before
<Proteus>
I get deep into archetecure/implementation.
<Proteus>
and yes, I'm aware that this isn't excatly comparing apples to apples
<bluestorm>
hm
<bluestorm>
what kind of ocaml functions are you talking about ?
<bluestorm>
stdlib functions ?
<bluestorm>
Proteus: you could probably begin with a pure ocaml code, then profile, see where your bottleneck is, and then optimize those parts (possibly replacing functions with C versions), right ?
<bluestorm>
that sounds the saner things to do
<bluestorm>
+like
<bluestorm>
Proteus: int computations can be slower as ints are boxed, but you probably won't notice that
<tsuyoshi>
? ints are not boxed
<Yoric[DT]>
Sometimes, they are.
<Proteus>
I was informened on this channel the other night that goign from ocaml to C is pretty lightweight. I'd like to create a module, library, dynamically linked what have you to call some workhorse algorithms - bluestorm, quaternion manipulation for example, or goign through a giant mesh and auto-building quad stripes, et.
<tsuyoshi>
when are ints boxed?
<bluestorm>
tsuyoshi: i was considering Int32 and Int64
<tsuyoshi>
oh
<bluestorm>
wich are often needed when communicating with C-side functions
<bluestorm>
but you're right, that was misleading
<bluestorm>
Proteus: native ocaml ints are not boxed
<Jeff_123>
you can access caml's ints from c, Val_int() I think.
<Smerdyakov>
Proteus, if you have any concerns about performance, you should be using SML, not OCaml. I hear the SML compilers don't generate good floating point instructions; that seems to be about the only advantage that OCaml has there.
<Jeff_123>
eg MLTon I'm guessing.
<Proteus>
also, I can generate ai in ocaml, but for the run time, it'd make a lot of sense for the spiking neural networks, markov chains, etc, to be based of low-level c routines
<bluestorm>
Proteus: why so ?
<Proteus>
well, for example
<bluestorm>
if you haven't done a performance comparison yet, you should not optimize prematurely
<Smerdyakov>
Proteus, I think it would be worth writing C and SML versions and comparing performance with the C compiler you use and with MLton.
<bluestorm>
you would be surprised
<Jeff_123>
ya, it's not a safe bet to assume that calling c code will always be faster
<Proteus>
Jeff_123, of course not
ygrek has joined #ocaml
<bluestorm>
Yoric[DT]: i think i may have been a bit too alarmed, i'll get used to the Enum interface
<Yoric[DT]>
good:)
<Smerdyakov>
I had a fun example where MLton-compiled SML was significantly faster than "equivalent" GCC-compiled C.
<bluestorm>
i didn't noticed at first, but the motto "without clone, everything is shared" seems reliable enough
<Proteus>
but some of the reference algoritms have been refined for decades
<bluestorm>
-d
<Proteus>
I had a prof who was big of SML. Mostly for formal analysis though
<tsuyoshi>
if you already have it written in c, then there is usually little point rewriting it
<bluestorm>
Yoric[DT]: that said, i think Enum is poorly documented
<Yoric[DT]>
Well, feel free to contribute additional documentation.
<Yoric[DT]>
I think it would be a good idea actually, since it's so central.
<bluestorm>
having the first sentence beginning with "Enumerations are entirely functional" is quite evil :D
<Smerdyakov>
Proteus, it's fallacious to conclude from that that SML isn't a great choice for practical programming.
<Proteus>
I'm not
<Jeff_123>
SML is ok, but I'm not enjoying ml-lex and ml-yacc one bit.
<Proteus>
no no, let me elaborate
* rwmjones
is back .. Yoric[DT] ?
<Proteus>
from what I've seen I really prefer ocaml to sml
<Yoric[DT]>
rwmjones: Actually, I was just saying "hi".
<Smerdyakov>
Jeff_123, what problems are you having?
<Yoric[DT]>
I'm willing to discuss ExtLib but there was no hidden ulterior motive.
<Jeff_123>
specifically that it's a pain to look up an error in a generated parser and then find the place it came from in the parser spec.
<Jeff_123>
it doesn't preserve line numbers like ocamlyacc
<Smerdyakov>
Jeff_123, yeah, that is definitely a pain. However, at least for my development cycle, that cost is negligible.
Associat0r has quit [Read error: 104 (Connection reset by peer)]
marmotine has joined #ocaml
kig has joined #ocaml
<Proteus>
to answer the question of 'why', while I really like ocaml so far, consider the runtie for a spiking neural net. the way i've designed it is increadibly, increadibly simple. SNNs in the past have focused on biological accuracy, when even though it's a powerful technique, it's uncessarily complex and impractical for real time work. Basically all of the traits which make SNN so powerful can be approximated with compuationally simple algebra (a
<Proteus>
s opposed to a lot of calc). Now, between CUDA, many-core processors, and SSEx extensiosn I can do a lot of parallel operations but even so I'm still a little squezed in cycles for real-time AI code. My AI system doesn't just control bots but can modify geometry, events, and sound (and all other combinations between those three). So, creating a SNN is hard, training a SNN is hard, but running it is theoretically very simple. You have a neur
<Proteus>
on, which is just a state machien - action potential is calculated by asking 'how long has it been since my last spike', 'what is the strength of this spike', 'what sort of neuron am I', then reset the action potential and (maybe) send spikes out to connected neurons with the appropriate strength and delay, etc. Doing this in a high level language like ocaml seems like overkll, especially when everything is done with algebra and reuires as
<Proteus>
much paralellism as possible with as small a footprit as possible for the graph and for each individal neuron
<rwmjones>
Yoric[DT], can you not compress the attachments, makes it much harder to deal with the patches
<Yoric[DT]>
Ok.
<Yoric[DT]>
The list rejected my latest un-compressed attempt, though.
<Proteus>
does that make sense? I'm exhausted
<Yoric[DT]>
(it was more than 40k, it seems)
Smerdyakov has quit ["BRB"]
<Proteus>
anwyay, there are several areas like this where I'd like to manipulate/create/etc. in ocaml doing the runtimein ocaml just doesnt seem appropriate
<Jeff_123>
then don't, i guess?
<rwmjones>
Yoric[DT], I'll see if I can get the list limit raised
<Yoric[DT]>
thanks
<Yoric[DT]>
(it wasn't a strong rejection, rather a moderation, but I considered compression an easy way out)
Smerdyakov has joined #ocaml
<Proteus>
Jeff_123, I'm newish to ocaml, I don't really know what it is capable of
<Proteus>
that's why asked for thoughts on my plan
<Smerdyakov>
Proteus, what do you mean by "what it is capable of"?
<Jeff_123>
you mentioned SSE instructions and CUDA. AFAIK caml doesn't work directly with those.
<Proteus>
Smerdyakov, that was ambiguous, sorry. What I ment was: ocaml->c isn't an elegant solution, I wondered if my approach was wrong
<Proteus>
or if there were any good alternative solutions
<Smerdyakov>
Proteus, I think it's obvious that you should pick a few of your core performance-intensive algorithms and run some comparison experiments that at least include 100%-OCaml implementations.
<rwmjones>
who the heck is adubey? he's listed as the owner of ocaml-lib-devel ...
<Proteus>
To anyone's knowledge, has ocaml been used in a real-time simulation or game
<Proteus>
?
<Smerdyakov>
OCaml drives all the interesting stuff at Jane Street Capital.
<Smerdyakov>
It seems fair to classify real-time algorithmic trading as "real-time simulation."
<rwmjones>
Proteus, do you mean a real real-time game? I wrote a silly 3D "game"
<Camarade_Tux>
Proteus, yes, ocaml is actually even used to drive a real-time machine
<bluestorm>
i think this behavior is more interesting as it allows one to "get the first counterexample"
asmanur has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
interesting
<Yoric[DT]>
Good idea.
<rwmjones>
Proteus, I'd advise against using swig or any other automated tool ... they generally suck
<Proteus>
rwmjones, unfortunate
<Yoric[DT]>
rwmjones: I was considering an additional change to Enum.
<Yoric[DT]>
While enumerations are quite good for forward traversal, they are generally useless for going backwards.
<Yoric[DT]>
Now, a number of data structures required two way traversal (e.g. arrays, trees).
<Yoric[DT]>
What do you think would be best: a new module RevEnum (or Cursor, or something such) with the ability to transform into a "reversible" enum?
Philonous1 has quit ["Leaving."]
<Proteus>
rwmjones, are there any tricks to speed up the process of binding a large library?
Philonous has joined #ocaml
<Yoric[DT]>
Or adding one optional argument [?backwards] to enum constructors which would let people create reversible enumerations?
Camarade_Tux_ has joined #ocaml
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
Camarade_Tux_ is now known as Camarade_Tux
<bluestorm>
Yoric[DT]: what would a reversible enumeration look like ?
<bluestorm>
(is that not a zipper ?)
<Yoric[DT]>
Well, that's the idea.
<bluestorm>
how would the destructive behavior interact with that ?
<Yoric[DT]>
I'm not sure.
<Yoric[DT]>
But Enumerations are so close to Cursors (or zippers or whatever) that it seems like a shame to have two distinct modules.
Jeff_123 has quit []
<Camarade_Tux>
quick question : I have a data structure on disk (a tree) and need to read it and make relatively small changes, I can use Marshal.to/from_channel but this implies I'll have to write the whole datastructure on disk while I just want to make a small update, does anyone have a sexier solution ?
<Camarade_Tux>
(the data structure updates destructively)
Proteus has quit [Read error: 54 (Connection reset by peer)]
Proteus has joined #ocaml
<bluestorm>
Yoric[DT]: i think you'll need to make something quite different from enum
<bluestorm>
that is, you'd have a "next" and a "prev" function, and maybe no "clone"
<Yoric[DT]>
Yes, you're probably right.
<Yoric[DT]>
afk
seafood has quit []
<bluestorm>
btw, i think we could eventually use Reins if you're interested in more advanced data-structures for Batlib
Linktim has quit ["Quitte"]
<Yoric[DT]>
Indeed.
<Yoric[DT]>
It's not GODI-fied, though.
seafood has joined #ocaml
<bluestorm>
that should not prove so difficult as it's pure-ocaml with little external dependencies
<Yoric[DT]>
Sure.
<Yoric[DT]>
I just don't want us to end up maintaining it.
im_alone has quit [Read error: 104 (Connection reset by peer)]
im_alone has joined #ocaml
Linktim_ has quit [Read error: 110 (Connection timed out)]
im_alone_ has joined #ocaml
ygrek has quit [Remote closed the connection]
coucou747 has joined #ocaml
im_alone__ has joined #ocaml
Associat0r has joined #ocaml
seafood has quit []
rwmjones has quit [Read error: 113 (No route to host)]
hsuh has joined #ocaml
im_alone has quit [Read error: 110 (Connection timed out)]
Linktim has joined #ocaml
im_alone_ has quit [Connection timed out]
<bluestorm>
Yoric[DT]: i'm not sure from_loop is a very good idea : it's basically unfold raising No_more_elements instead of using options, wich (is ugly and) disrupt the "privacy policy" regarding No_more_elements (only "next", "make" and "from" should raise it) : we could extend that policy to from_loop but i don't think it's worth it
<bluestorm>
(err, only "make" and "from" should take a "next" function raising it)
<Yoric[DT]>
Well, this is a variant on [next].
<Yoric[DT]>
And [from_loop] is a variant on [from].
<bluestorm>
i understand that
<Yoric[DT]>
Now, I agree that [from_loop] is not the most interesting function in the module.
<bluestorm>
but for some reason the Extlib people try to restrict the use of No_more_element in their API
<bluestorm>
and from_loop is maybe not important enough to justificate an extension of the use they're so cautious about
<Yoric[DT]>
fair enough
<bluestorm>
(seq is a nice sugar, and i think from_while may be helpful in some cases, but i think we could drop from_loop without too much damage)
<Yoric[DT]>
Fair enough.
<Yoric[DT]>
Now, you write that on the mailing-list :)
<bluestorm>
:]
<bluestorm>
i'm still splitting patches
<bluestorm>
(and awfully slow at it)
<bluestorm>
but i'll post in a few minutes
<Yoric[DT]>
Well, I'm proof-reading a PhD.
<Yoric[DT]>
So no more patches for me before a few hours.
<Yoric[DT]>
But don't forget your earlier patch, it's a good idea.
delamarche has joined #ocaml
asmanur has joined #ocaml
asmanur has quit [Client Quit]
ygrek has joined #ocaml
<coucou747>
papa coupe le cable
coucou747 has quit ["bye ca veut dire tchao en anglais"]
<Yoric[DT]>
?
jderque has left #ocaml []
asmanur has joined #ocaml
pango_ has quit [Remote closed the connection]
Linktim_ has joined #ocaml
Proteus has quit [Client Quit]
pango_ has joined #ocaml
coucou747 has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
Linktim has joined #ocaml
marmotine has quit ["mv marmotine Laurie"]
Linktim_ has quit [Read error: 110 (Connection timed out)]
<Camarade_Tux>
why isn't (^) syntactic sugar for String.concat "" ... ? The number of argument is not the same but it should be workable
<Smerdyakov>
Because there should be a damned good reason for baking anything into the compiler.
<Smerdyakov>
As things stand, nothing about string concatenation is in the compiler, as far as I know.
<Smerdyakov>
(^) is an infix operator like any other.
<bluestorm>
if you mean the implementation : ^ implementation is much simpler that String.concat's, and it's in Pervasives so should not depend on String
<Camarade_Tux>
by looking at the source, I guess it's indeed to keep Pervasives independant from String, in pervasives.ml you can see that (^) defines functions that are defined in string.ml too (namely string_length, string_create, string_blit)
<bluestorm>
well they're external so the implementation is reused anyway
<Camarade_Tux>
it's not long of course but it still shows they wanted the modules to be clearly separated
<mrvn>
Doesn't string depend on Pervaisves somewhere?
<Camarade_Tux>
well, yes, my sentence could have been better ;)
<mrvn>
And then Pervasives can not use anything from String
<Camarade_Tux>
and oen of the dependancy : "if ofs < 0 || len < 0 || ofs > length s - len"
<Camarade_Tux>
*one
<Camarade_Tux>
we'd been doomed if Pervasives depended on String (but I like how there's a String module defined inside Pervasives solely for String.get ;) )
<mrvn>
Avoids the cyclic dependency.
itewsh has quit ["KTHXBYE"]
<mrvn>
I still don't get why I can't have a cyclic dependency provided I have *.mli files.
<bluestorm>
you mean, non-cyclic .mli with cyclic implementations ?
<mrvn>
bluestorm: yes.
Linktim_ has joined #ocaml
Jedai has joined #ocaml
<asmanur>
mrvn: because ocaml need to initialize (compute direct values such as let () = print_endline "foo") of dependencies before initializing the module
delamarche has quit []
<mrvn>
So the compiler would have to ensure that direct values are not forming a cycle and specify the correct init order. Tricky.
<mrvn>
(and it would need the *.ml files for that)
<Yoric[DT]>
mmmhhhh.... download statistics seem out of order
<Yoric[DT]>
That's reassuring.
Linktim has quit [Read error: 110 (Connection timed out)]
<bluestorm>
ertai: i'm unsure about something concerning the functorial layer of camlp4
<bluestorm>
most people tend to go the easy root and use PreCast
<bluestorm>
in most cases i could, especially if i consider included their code into a common repository that i would maintain, add the functor myself
<bluestorm>
so the question is : is it worth it ? is it worth pushing this change upstream ?
<bluestorm>
i have myself an idea of the usefulness of those functors (resilient to the grammar change, mostly), but that's not documented anywhere that i know of
<bluestorm>
do you have an opinion on this ?
<bluestorm>
( s/root/route/, arg.)
<mfp>
hmmm the OCaml downvote in full effect again Batteries release 0 went from +5 or so with a couple dozen votes to the current -2, and somebody just downvoted it from -1 to -2 despite it appearing in neither "what's new" nor "hot"
<Yoric[DT]>
:/
<Camarade_Tux>
I definitely want geographical stats for reddit
<mfp>
OCaml is clearly being downvoted in the US as they wake up
delamarche has joined #ocaml
<bluestorm>
mfp: :D
delamarche has quit [Client Quit]
Linktim_ has quit [Read error: 110 (Connection timed out)]
Snrrrub has joined #ocaml
sporkmonger has joined #ocaml
asmanur has quit [Read error: 110 (Connection timed out)]
<im_alone__>
hi, are there Markov libs or Neural libs in OCaml?
<im_alone__>
in the example of cart-pole problem, after being trained for the Markov Decision Process. The resulted stationary controller, can it be again trained for Artificial Neural Network to reduce the size of the stationary controller?
<ertai>
bluestorm: the functorial level have two uses
<ertai>
bluestorm: the first one is to be able to apply them not only on the current ocaml grammar as in dynamic loading but to be able to compose language extension in a library like fashion
<bluestorm>
hm
<ertai>
the second use is to delay the effect of mutating the grammar so that one can pack many extensions and dynamically choose which one to use.
<bluestorm>
with the current unspoken standard to put the registration code in the same file as the functor, this would probably require a hack
<bluestorm>
ah
<ertai>
yes but just for the global default grammar of camlp4, that is mutated in all cases.
<ertai>
bluestorm: it's like switching from <<e[g]>> to let f g = <<e[g]>>;; f g
<ertai>
the global <<g>> is still mutated, but there is still the f function that one can reuse.
<bluestorm>
hm
<bluestorm>
but if i wanted to compose several extension and present them as only one, then i should not register that "big-extension" if the individual ones have been registered at link time, should I ?
<ertai>
no you won't be able to do that, to have real packaging facilities one need to separate the default registration from the functor definition.
<hcarty>
bluestorm: I think pa-do may allow for some sort of units sugar, like the F# feature you mentioned earlier. I don't know the details of the F# feature though, so this may not be comparable.
asmanur has quit ["leaving"]
asmanur has joined #ocaml
asmanur has quit [Client Quit]
asmanur has joined #ocaml
Linktim has joined #ocaml
jeddhaberstro has joined #ocaml
pango_ has quit [Remote closed the connection]
pango_ has joined #ocaml
code17 has quit ["Leaving."]
ygrek has quit [Remote closed the connection]
Snark has quit ["Ex-Chat"]
asmanur has quit [Remote closed the connection]
delamarche has joined #ocaml
asmanur has joined #ocaml
delamarche has quit [Client Quit]
bluestorm has quit [Remote closed the connection]
Myoma has quit ["This computer has gone to sleep"]
delamarche has joined #ocaml
Axioplase has joined #ocaml
Myoma has joined #ocaml
guillem_ has joined #ocaml
hkBst has quit [Read error: 104 (Connection reset by peer)]
hsuh has quit [Read error: 110 (Connection timed out)]
maattd has joined #ocaml
delamarche has quit []
itewsh has joined #ocaml
itewsh has quit [Client Quit]
Linktim has quit [Read error: 110 (Connection timed out)]