stoff has quit ["This computer has gone to sleep"]
rwmjones_lptp has quit ["This computer has gone to sleep"]
ptmahent` has joined #ocaml
smimou has joined #ocaml
seanmcl has joined #ocaml
_unK has quit [Remote closed the connection]
albacker has quit [Read error: 113 (No route to host)]
Associat0r has joined #ocaml
Associat0r has quit []
sramsay has quit [Read error: 110 (Connection timed out)]
seanmcl has quit []
tmaeda is now known as tmaedaZ
tmaedaZ is now known as tmaeda
tmaeda is now known as tmaedaZ
smimou has quit [Read error: 110 (Connection timed out)]
Associat0r has joined #ocaml
Associat0r has quit [Remote closed the connection]
toast-opt has quit []
toast-opt has joined #ocaml
stoff has joined #ocaml
stoff has quit [Client Quit]
ski_ has quit ["Lost terminal"]
ski_ has joined #ocaml
Camarade_Tux has quit [Read error: 113 (No route to host)]
Camarade_Tux has joined #ocaml
Camarade_Tux has quit [Client Quit]
Camarade_Tux has joined #ocaml
tmaedaZ has quit [Read error: 110 (Connection timed out)]
toast-opt has quit []
tmaedaZ has joined #ocaml
mbishop has quit [Read error: 60 (Operation timed out)]
Waleee has quit [Read error: 110 (Connection timed out)]
seanmcl has joined #ocaml
tmaedaZ has quit [Read error: 110 (Connection timed out)]
tmaedaZ has joined #ocaml
tmaedaZ has quit [Read error: 60 (Operation timed out)]
tmaedaZ has joined #ocaml
seanmcl has quit []
mbishop has joined #ocaml
ikaros has joined #ocaml
ygrek_ has joined #ocaml
ikaros has quit ["Leave the magic to Houdini"]
Submarine has joined #ocaml
ski_ has quit ["Lost terminal"]
ski_ has joined #ocaml
albacker has joined #ocaml
_zack has joined #ocaml
_zack is now known as zack
zack is now known as _zack
ulfdoz has joined #ocaml
Snark has joined #ocaml
yziquel has quit [Ping timeout: 180 seconds]
rwmjones_lptp has joined #ocaml
jcaose has joined #ocaml
ttamttam has joined #ocaml
<thelema>
thelema_ has joined #ocaml
tmaedaZ is now known as tmaeda
ulfdoz has quit [Read error: 110 (Connection timed out)]
thelema has quit [Read error: 110 (Connection timed out)]
smimou has joined #ocaml
rwmjones_lptp has left #ocaml []
_zack has quit ["Leaving."]
_unK has joined #ocaml
<mfp>
I'm toying with the idea of implementing a dynamic linker/loader (think ld.so)
<mfp>
there are 2 main problems with native Dynlink: you have to make sure the whole OCaml runtime is linked into the program (otherwise, primitives used by the .cmxs might be missing), and you cannot load more than one copy of a module (lest you have problems with exceptions + hard crashes)
Yoric has joined #ocaml
<mfp>
a camld dynamic loader with the full runtime and access to the cached cmxs info could solve both
<mrvn>
mfp: so make each module a library and reuse them once loaded.
<mfp>
yes, exactly
<mfp>
this is manageable if the dynamic loader works like ld.so and can automatically locate libs as needed
<mrvn>
wouldn't it be enough to have a ocaml.so for the runtime and have no module linked statically against the runtime?
<mfp>
yes
<mfp>
however, the runtime is not relocatable on Debian's packages, so you cannot build a shared lib containing it
<mrvn>
Problem I see is the cross module inlining. That means every little change means a soname change.
<mrvn>
mfp: fixable.
<mfp>
the above is no pb since you can just link it into camld statically, with -Wl,--whole-archive
<mfp>
yes
Mr_Wizard has joined #ocaml
<Mr_Wizard>
hi... is it possible to create a function, which takes an argument and applies it to itself?
<mfp>
mrvn: there's typically no inlining across lib boundaries, since .cmx files are not installed
<mrvn>
% ocaml -rectypes
<mrvn>
# let f x = x x;;
<mrvn>
val f : ('a -> 'b as 'a) -> 'b = <fun>
<Mr_Wizard>
ok, thx :)
<mrvn>
mfp: You want to not inline?
<mrvn>
Mr_Wizard: you can do the same without rectypes if you wrap it into a specific type.
<mfp>
mrvn: there's no inlining across libs if the cmx are not installed anyway, and they typically aren't
<mfp>
that would depend on the lib, I suppose
<mrvn>
Does batteries come with a cmx?
<mfp>
the cmx files are not installed atm.
<mfp>
this doesn't hurt BatInt and friends, since they use externals anyway
<mfp>
more precisely, primitives, which are always inlined
<mrvn>
Mr_Wizard: # type cont = Cont of (cont -> unit) let f x = let Cont fn = x in fn x;;
<mrvn>
type cont = Cont of (cont -> unit)
<mrvn>
val f : cont -> unit = <fun>
<mfp>
anyway, dynamic linking is no worse than static regarding inlining, and the dynamic loader could be smart enough to support multiple versions of a lib being installed (not loaded) at once
<mrvn>
mfp: The only advantage would be some shared memory for the code. Does that really matter with todays ram size?
<mrvn>
mfp: Unless you get it so that rebuilding a lib doesn't require rebuilding all apps.
<mfp>
the latter
<mfp>
"free" upgrades without recompiling when the interface doesn't change
<mfp>
this would be very useful e.g. for Debian's security updates
<mfp>
that is a significant advantage IMO
ofaurax has joined #ocaml
<Camarade_Tux>
that'd be terrific :P
<mfp>
it also gives OCaml something to brag about, a ~15KB hello world using Batteries vs. >500KB for GHC or Go/Issue9 (or 1.5MB with AAA Batteries static)
<mfp>
open BatPervasives let () = Print.printf p"Hello, %rope\n" r"world!"
<mfp>
2275869 bytes with static linking, 13330 with dynamic
<mfp>
ropes depend on camomile, which comes with huge unicode tables
<Yoric>
hi
stoff has joined #ocaml
<mrvn>
mfp: But makeing that work is a huge change
b41d3r has joined #ocaml
b41d3r has quit [Client Quit]
Mr_Wizard has left #ocaml []
<thelema_>
mfp: the unicode tables are loaded at runtime, no?
tmaeda is now known as tmaedaZ
seanmcl has joined #ocaml
<mfp>
thelema_: right, just checked and it's not because of the tables... at any rate, camomile weighs over 1MB
<thelema_>
camomile does have a lot of code.
<mfp>
it's not that huge a change if we limit dynlink to batteries + its deps; I have already a basic ld + the required OMake machinery
<mfp>
the only remaining issue is that you have to be careful not to link against the .cmxa included in AAA's cmxs
<thelema_>
really? great.
<mfp>
I have OMake functions that do this, but it can be a PITA in other systems
<thelema_>
how to control linking in ocaml - isn't the .cmxa required?
<mfp>
basically, instead of doing -package foo,bar,baz -linkpkg,
<thelema_>
mfp: well, we should find someone capable in ocamlbuild to make it work there too.
<thelema_>
omake + ocamlbuild = enough.
thelema_ is now known as thelema
<mfp>
you do -package foo,bar,baz foo.cmxa bar.cmxa whatever, and include only the .cmxa that are not included in batteries.cmxs (-package is required to set the -I options so that the .cmi are found)
* Yoric
sees interesting stuff happening.
<mfp>
I get the list of -cmxs with ocamlfind query -a-format -predicates mt,native aaa
<thelema>
hmmm...
<mfp>
then the same for the packages you want to link against, and filter out those that are already in batteries.cmxs / the dynamic loader
Submarine has quit [Read error: 110 (Connection timed out)]
<mfp>
this could be done by ocamlfind itself (meaning easy compatibility with any findlib-aware build sys), with something like -exclude-archives aaa
<mfp>
which would omit the archives included/required by aaa from the list of archives to link against, so we don't get any duplicates
<thelema>
That's a better idea than putting it in Omake/ocamlbuild
<mfp>
yes, much simpler
<mfp>
it won't scale if you want to have many shared libs, though, since you'd have to track the cmxs dependencies manually
<mfp>
at some point you need ld.so-like capabilities, like an hypothetical camld dynamic loader that resolves the dependencies at load time, as I described before
Pepe__ is now known as Pepe_
<mfp>
such a camld is not that hard to implement (see the above codepaste for the essential part, dependency info extraction from the .cmxs); the biggest change is having libs installed as .cmxs also
<mfp>
which Debian is starting to do...
<thelema>
hmmm. Real dynamic linking on ocaml... nice
<thelema>
Programs have to br written specially for dynlink, no?
<thelema>
*be
<mfp>
not really
<mfp>
the only difference is Sys.argv
<mfp>
and that all the modules in a shared lib will be initialized (w/ side effects)
<mfp>
as opposed to only those actually used, as with static linking
<thelema>
hmm, static linking avoids some side effects of module load?
<mfp>
it only includes the modules referenced by the .cmx given in the cmdline
<mfp>
the others are not linked, and thus not initialized => no side effects
<mfp>
that's why AAA's flat namespace can make executables much smaller than Batteries, since in the latter you pull in all the code once you access the Batteries module
<thelema>
of course "can" != "will" - you have to not use the Batteries module in AAA to get this improvement
<mfp>
indeed
<mfp>
btw. always wanted to ask you
<thelema>
hmm, should we recommend projects copy the batteries module into their code and comment out the unneeded parts to decrease link costs?
<mfp>
what was the rationale for having things like BatList replacing List directly, instead of something like extlib's?
<mfp>
hmm
<thelema>
I just factored it differently, putting the "include Foo; include BatFoo" into batteries.ml
<thelema>
There's probably something that's not thread safe. I can't think of what it would be.
<thelema>
I'm trying to think of the results of sharing an Enum between threads, and don't want to think too hard about it.
<thelema>
It's probably got some way of breaking horribly.
<mrvn>
anything mutable is at risk
<thelema>
yup. Enum is our big source of that.
<mrvn>
thelema: you probably get elements twice or skiped
<mrvn>
Luckily anything functional is automatically thread safe
<Yoric>
mfp: less confusing for beginners
<Yoric>
er...
<mfp>
Yoric: context?
* Yoric
obviously has problems with his IRC client.
<Yoric>
Some question about BatList vs. Extlib's approach.
<Yoric>
(sorry for the interruption)
<Yoric>
thelema: yeah, I gave up on that, too.
jcaose has quit [Read error: 110 (Connection timed out)]
<thelema>
Yoric: on making batteries thread safe?
<Yoric>
On making Enum threadsafe.
<mrvn>
have both kinds
<mfp>
thelema: I'm hacking the OMakefiles, feel like generating ExtList & friends?
bluestorm has joined #ocaml
<thelema>
mfp: sure
<thelema>
I tried hacking the omakefiles - I still don't get it.
<thelema>
actully, just four - Ext{Array,Hashtbl,List,String}
<mfp>
a simple script should do, just need to generate extXXX.ml with contents module XXX = batXXX
<mfp>
huh, thought there were more
<mfp>
no script needed then :)
<thelema>
nope, extlib is quite small compared to batteries
<mfp>
what else
<thelema>
extlibcompat.ml
<mfp>
Extlibcompat with module ExtList = ExtList etc., also including IO Enum and the other non-Ext
<mfp>
how should I name the extlib compat packages?
<thelema>
pushed
<mfp>
the one which allows to link against extlib simultaneously must be a toplevel package (cannot use the same dir as aaa since we need to hide some cmi)
<thelema>
aaa-extlibcompat
<thelema>
It doesn't have to be pretty, because it's not going to be the common case.
<mfp>
and the other one aaa.extlibporting ?
<thelema>
sure.
<mfp>
actually, there's no need for a separate package for that one
<mfp>
can just include Ext* in aaa itself
<mfp>
then you just change -package extlib to -package aaa and things work --- as long as you don't link against libs which use extlib themselves
<mfp>
am I missing anything?
<thelema>
I'm writing the docs.
<mfp>
it could be mildly confusing, though > "why BatList and ExtList?"
<thelema>
we'll have to exclude Ext* from documentation generation
<mfp>
ok, easy
<thelema>
README pushed
<mfp>
extlibcompat.ml -> should be module ExtList = ... instead of module List = ...
<thelema>
oops, I'll fix
<thelema>
forgot the extra level of indirection
<thelema>
pushed
<mfp>
do you know if ocamlfind install requires the 1st file to be META, or can I give META.extlibcompat and have it renamed to META for me?
<thelema>
you can't have it renamed
<thelema>
and it doesn't have to be the first file
<thelema>
it just has to be in there.
<mfp>
argh, then need to add a directory just to generate another META :-?
<thelema>
well, I've thought about moving build/META* to the root - would that help?
<thelema>
you could then use build/ for the extlib-compat meta
<thelema>
renaming it, copying, renaming back
<mfp>
I preferred to avoid renaming, feels a bit dirty
<thelema>
build/extlib-compat
<thelema>
/META
<mfp>
/META for aaa, and build/META for extlib-compat?
<thelema>
that's just going to cause confusion because the old META was in build/
<thelema>
well, it will, I don't see the problem with another build/ directory
<mfp>
just me being lazy; OK, I'm creating build/extlib-compat
<mfp>
extlibcompat even
<thelema>
hmm, maybe I could move the ext*.ml to build/extlib-compat
<thelema>
get them out of the nice source tree into their own folder
<thelema>
maybe batteries.ml too.
<mfp>
I'm already hiding the modules in the OMakefile as needed
<mfp>
I'd rather keep them in src/
<thelema>
ok.
<thelema>
k
<mfp>
bad news :((( #require "aaa-extlibcompat";;-extlibcompat/batteries_extlib.cma: loaded Error: Reference to undefined global `Enum'
<mfp>
seems we can't hide Enum/IO and other modules used internally
<mfp>
workaround -> rename all internal refs to BatEnum / BatIO, then provide module Enum with include BatEnum in aaa package
stoff_ has joined #ocaml
bluestorm has quit ["Leaving"]
Submarine has joined #ocaml
<thelema>
hmm. I guess I'm not opposed to that.
<thelema>
by "aaa package" do you mean batteries.ml?
<mfp>
#require "aaa" <- this one :)
<thelema>
and we don't provide it in aaa-extlibcompat?
<mfp>
right
<thelema>
This is getting kinda kludgy
<mfp>
I'm already hiding it in aaa-extlibcompat
<thelema>
I don't mind renaming all modules to BatFoo
<mfp>
but that's no good since it's referenced by other modules
<thelema>
I don't mind the compatibility later to extlib
<thelema>
Well, I guess the solution is to use BatFoo module names
<mfp>
renaming everything solves the compat problem trivially
<thelema>
and update the batteries.ml to use them
<mfp>
another solution would be to auto-generate src/extlibcompat/*.ml(i) at build time
<thelema>
I don't want a file enum.ml = "include BatEnum"
<mfp>
doing s/IO/BatIO/ and renaming IO.ml to BatIO.ml under that dir
<mfp>
then renaming is the only option
<thelema>
the solution for extlibcompat is to not have compatibility on a package level
<thelema>
and to have only the "nested" compatibility layer
<mfp>
no, that still doesn't work
<mfp>
that's what I'm doing already, hiding IO, Enum, etc.
<mfp>
but other modules such as BatList still refer to Enum, and you get Error: Reference to undefined global `Enum'
stoff has quit [Read error: 110 (Connection timed out)]
<thelema>
Ok, I'm planning on breaking compatibility between -package extlib and -package aaa
<mfp>
if you load extlib before, you get "the files .... disagree over interface Enum"
<thelema>
the only way to have extlib compatibility will be to put "open Extlibcompat" at the top of your extlib-using source files
<mfp>
what do we gain?
<thelema>
aaa becomes usable in parallel with extlib
<thelema>
extlib users can add the magic incantation "open extlibcompat" at the top of their source files, and that file will use aaa's replacements for extlib modules
<mfp>
I see, with no separate aaa-extlibcompat package
<thelema>
yes.
<mfp>
then what about aaa.noextlibcompat, for convenience ;-)
<mfp>
with aliases for IO...
<thelema>
so that you can use Enum without the Bat prefix?
<thelema>
aliases where?
<mfp>
yes
<mfp>
IO.ml -> include BatIO
<thelema>
If we're going to do that, we're going to do it the original way, not this backwards way.
<thelema>
if we're going to do that, we'll generate those for ... :( drat, we can't.
<thelema>
the convenience is that you don't [open batteries]?
<mfp>
and thus don't link the whole thing, yes
<thelema>
if someone is using batteries without [open batteries], they'll have to be sensitive to the low level details of batteries.
<thelema>
The only way we have of shielding people from that is the Batteries module.
<mfp>
batteries.a takes ~2.3MB, camomile another MB
<mfp>
the more things we put under the Batteries namespace, the larger the thing becomes
<thelema>
yes, I'm not removing that option, I'm just requiring the 2 people who currently use AAA like this to do s/Enum/BatEnum/
<mfp>
I guess aliasing manually is an OK price module Enum = BatEnum
<mfp>
ok
ulfdoz has joined #ocaml
<thelema>
I guess I'll get started renaming.
<mfp>
thelema: gotta revert the last commit then, right? (no extlibcompat package anymore)
<thelema>
yup, seems like it.
<thelema>
renaming is a pain.
* thelema
starts with IO
<thelema>
hmm, omake isn't so good about showing intermediate dependencies...
<thelema>
Do not know how to build "src/IO.cmo" required for "src/batteries.cma"
<mfp>
what's the pb with that error msg?
<thelema>
it doesn't tell me what file depends on IO.
slash_ has joined #ocaml
<mfp>
it's IO itself
<mfp>
in the list of modules to build and include in batteries
<thelema>
I changed that.
<mfp>
really? hmm
<thelema>
interfaces
<thelema>
batIO
<thelema>
IOThreads
<mfp>
then make sure you remove IO.cmi
<mfp>
the file that depends on IO will not compile that way
<thelema>
yup, did that. the builds succeeded before I did [rm IO.c*]
<mfp>
and it still wants IO?
<mfp>
what does grep say?
<thelema>
of course it wants IO - all the rest of the modules have references to IO.write, etc.
<thelema>
but it doesn't give me the name of the first one I need to fix.
<thelema>
I'm using grep instead, and it works so far.
stoff_ has quit ["This computer has gone to sleep"]
<mfp>
can't you just sed s/\<IO\>/BatIO/ or such?
<thelema>
InnerIO
<thelema>
\< ?
<mfp>
\<InnerIO\> then
<mfp>
word boundary
<mfp>
don't remember if it's \< in sed (it is in vim)
<thelema>
I didn't realize sed had such.
<thelema>
perl uses \b, iirc
<mfp>
in vim :tabdo s/\<InnerIO\>/BatInnerIO/g | update or such IIRC
<mfp>
oops %s/
<mfp>
after vim -p *.ml *.mli
_zack has joined #ocaml
<mfp>
just tried it, that works like a charm; better than grep'ing for it and changing by hand
<thelema>
E173: 180 more files to edit 1,1 Top
<mfp>
vim -p
<thelema>
Maybe I should let you do this conversion - my vim-fu is weak
<thelema>
I did the two things - vim -p *.ml *.mli
<thelema>
and :tabdo %s...
<mfp>
-p opens all the files at once in diff tabs
<mfp>
how old is your vim?
<thelema>
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Sep 21 2009 11:25:46)
<mfp>
and how come you have 180 files?
<mfp>
oh, we do have 180
<mfp>
wow
<thelema>
thelema@thelema-laptop:~/batteries/src$ ls *.ml *.mli | wc 181 181 2198
<thelema>
would you mind doing this?
<mfp>
k then, will do in a while
<thelema>
Enum and IO are the two biggies.
<thelema>
I'll do the rest of the modules, and leave Enum and IO for you, mfp
<Alpounet>
Yoric, haha nice blog post :)
<mfp>
thelema: BatEnum and BatIO pushed
<thelema>
mfp: nice.
<flux>
soo... is the manual page for batteries.. bat.man?
<thelema>
flux: :P
<thelema>
That's our mascot.
<thelema>
With the toolbelt that has every tool needed.
<thelema>
hmm, now we need someone to make a logo
<flux>
batman with the 85-tool swiss army knife on the belt..
<thelema>
batman with skates that pop out of his boots.
<Alpounet>
"Want some distributed multi-channeled chat ? It's only 80 LoC with our brand new product !" :D
<Yoric>
:)
<Yoric>
Actually, iirc, it was 84 :)
ski_ has quit ["Lost terminal"]
ccasin has joined #ocaml
ikaros has quit [Read error: 54 (Connection reset by peer)]
ikaros has joined #ocaml
smimou has quit [Remote closed the connection]
smimou has joined #ocaml
<middayc>
mfp: I see xmlrpc light is based on ocamlnet 2 and it's netplex which has keep alive setting ... thanks a lot for information
Waleee has joined #ocaml
_zack has quit ["Leaving."]
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
Narrenschiff has quit []
run has quit [Remote closed the connection]
Pimm has joined #ocaml
lutter has quit ["Leaving."]
<middayc>
wasn't there some ocaml like functional language that was totally oriented for doing web-applications , I think someone here told me about it last year
<Camarade_Tux>
urweb?
<middayc>
aha, yes
<orbitz>
OPA?
<middayc>
I meant urweb but I am just reading some blogpost about OPA , but I yet have no idea what it is
<flux>
is there any actual information on OPA available? what I've picked is that it's going to somehow be commercial.. if it's driven to the extreme it could seriously make it a non-contender to current popular solutions, though
<middayc>
yes, commercial / closed techologies certanly don't get much traction on web these days .. too much alternative
<Yoric>
Well, no information available so far.
<Yoric>
There will be in a few weeks, though.
<Yoric>
(plus I'm going to post a few bits on my blog :))
<middayc>
Yoric: do you work at MLState?
<Yoric>
yep
<middayc>
nice, I'll be waiting for more info :)
<middayc>
ur/web also seems to be alive and well.. if I remember correctly there are more demos now than there were last year and last source release is just from few days back
sramsay has joined #ocaml
<middayc>
in general I don't like the all in one approach, I want sql to be sql, html html and javascript javascript , and a good server side lang.. but I try to keep options open
<flux>
middayc, even if you got static verification of everything?
<flux>
although I can understand that it can be a problem for people to throw everything they've learned away to use a new platform
<middayc>
yes that is one reason .. I can go to new language or program in multiple because the "peripherials" are still the same .. but it's not only that , it gives me fully open hands and full power of all of them, sql / js / html / css ..
<middayc>
for example I know where javascript will be or how css will be defined.. and I hate ORM's as SQL seems a nice DSL for relational databases and various ORM-s just poor things trying to replicate it
<middayc>
I don't know about static verification ... I suppose that must be nice but I haven't yet tried it to see how development changes if you are assured that things click together .. thats why I am keeping an open mind
<middayc>
I know most people don't agree with me.. at least with ORM-s
<flux>
well, pgocaml is great atleast :)
<flux>
but it does have its quirks
<flux>
but it's great to be able to for example modify database schema and have your compiler tell you where to fix
<Yoric>
middayc: well, SQL is a nice DSL for relational databases. The only problem is that quite often, non-relational data needs to be shoehorned into relational databases. At this point, SQL becomes the problem, not the solution.
<middayc>
I haven't yet tried orm-s in a functional language .. I suppose it might be a little better. My theory is that ORM are nice for simple queries, but I have no problem with sql for simple queries either, for very complex queries where you go to the edge of what you can express with sql usually orm-s are 10x more complex
<middayc>
and sql is pretty much sql .. you just look at the docs for some specifics, while there are millions of orm-s
<flux>
middayc, where I've found SQL abstractions nice is when you indeed have many complicated queries, which could easily use each other as components
<flux>
middayc, and for example one could safely construct dynamic search expressions per user input
<flux>
middayc, but I don't like Object Relational Mapping, unless the objects one is talking about are relations..
<middayc>
yes, I am sure there are good sides to orm-s, I also don't know that much orm-s , the ones I looked at in python, php and ruby I didn't like ..
<middayc>
Yoric, there is whole bunch of noSQL databases which might fit for that cases.. yes, I agree that for nonrelational data SQL is an owerkill (if you just need key:value) or not suited, for tree shaped data for example
thrasibule has joined #ocaml
<middayc>
one trivial example that doesn't work like I want in ORM-s I've seen is "update some set cnt = cnt + 1 where id = 101;" .. most orm-s do "get(101)" to get the whole object, then modify the value cnt and "save" whole object back
<Yoric>
Well, that's definitely an issue we're working on.
<middayc>
some orm's even made people get all rows of something into and array, then count the elements of array to get the number isntead of using "count()" in sql
<middayc>
(well these were really stupid)
Submarine has quit ["Leaving"]
<middayc>
orm-s have some benefits, this is just a personal preference of mine with which almost nobody agrees , so I am not saying OPA or Ur/Web aproaches arent well oriented approaches
<Yoric>
But I tend to believe that this is an issue with SQL databases, not ORMs.
<Yoric>
Ur/Web is relational.
<Yoric>
OPA isn't.
<middayc>
I was just the other day thinking of making some simple precompiler to remove some of the noise out of JS , I use it's functional side a lot so it's noisy writing those "function () { return .. }"
stoff has joined #ocaml
<middayc>
then I thought if I precompiled I would also have to do some checking for correctness.. then I realized those I would get to something like ocaml.. which also has "compilation to javascript" and I didn't like it when I saw it :)
<middayc>
because of my ideas (JS should be JS) that I mentioned before
<middayc>
:)
<middayc>
so I basically denounced my own arguments ..
albacker has quit [No route to host]
albacker has joined #ocaml
<middayc>
but there is important thing there... I know browser's API and dom .. if that ocaml->js will make me code like there is no dom or like this isn't a webapp I will need to learn some lib specific rules and I am sure I will hit the wall where I won't be able to do something that I could naturally do in normal browser dom/js
ygrek_ has quit [Remote closed the connection]
<middayc>
wow.. I see there is ocamlnet 3 comming out
Snark has quit ["Ex-Chat"]
Narrenschiff has joined #ocaml
<middayc>
sorry, I am a little confused right now with dynamic languages so I can't reason about static languages ... can you create a list of functions in ocaml?
<middayc>
I mean a list as a datastructure List
<middayc>
since functions are first class I suppose you can, so the real question is do they all have to have the same type signature?
<mrvn>
yes
<middayc>
yes to the first or second?
<mrvn>
both
<mrvn>
# [(+);(-);( * ); (/)];;
<middayc>
hm
<mrvn>
- : (int -> int -> int) list = [<fun>; <fun>; <fun>; <fun>]
<mrvn>
# [(+); fun x -> x];;
<mrvn>
Error: This expression has type int but an expression was expected of type int -> int
<middayc>
aha , so they don't have to be the same functions .. only the signature matters
<mrvn>
Would be quite pointless if they had to be the same function
sporkmonger has joined #ocaml
<middayc>
yes, probably .. I said I am a little confused about it all
<mrvn>
# let a = [(+);(-);( * ); (/)];;
<mrvn>
val a : (int -> int -> int) list = [<fun>; <fun>; <fun>; <fun>]
<middayc>
I created something like a simple actor "framework" in rebol now I started to think if I could create the same in ocaml, but I realized I don't fully get the staticness of it
ccasin has quit [Read error: 110 (Connection timed out)]
<mrvn>
You need to make your actors to all have the same type, e.g. unit - unit
ccasin has joined #ocaml
<middayc>
but isn't unit like null ?
<mrvn>
so?
<mrvn>
Think of it as delaying the evaluation of the actor.
<middayc>
I was thinking of implementig actors like functions that take some arguments and return a function to call on next run + arguments for it (this can be the same or controll can switch to another function)
<mrvn>
That would be continuations then
<middayc>
yes, like faking continuations
<middayc>
so in my case these functions would need to have arguments and I suppose they couldn't be all the same
<middayc>
unless I have many lists for all kinds of functions/actors
<middayc>
I mean for all that are in the current program
<mrvn>
type cont = Cont of (unit -> cont)
<mrvn>
type cont = Cont of (unit -> cont)
<mrvn>
# let rec actor x y () = Printf.printf "%d + %d = %d\n" x y (x+y); Cont (actor (x+1) (y+2));;
<mrvn>
val actor : int -> int -> unit -> cont = <fun>
<middayc>
does ocaml have continuations?
<mrvn>
# let rec loop actor = function 0 -> () | x -> let Cont actor = actor () in loop actor (x-1);;
<mrvn>
val loop : (unit -> cont) -> int -> unit = <fun>
<mrvn>
# loop (actor 1 1) 5;;
<mrvn>
1 + 1 = 2
<mrvn>
2 + 3 = 5
<mrvn>
...
<mrvn>
You can use the above or use continuation passing style with closures.
<middayc>
hm.. I am rather new in OCaml (and I haven't played with it in a while) so I will have to take some time to process your code
Narrenschiff has quit [Read error: 110 (Connection timed out)]
<middayc>
thanks a lot for it ? just one question .. if this is possible with ocaml, why hasn't anyone made it already ?
<middayc>
the first ? should be ! :)
<mrvn>
The probelm is that your actor would have type unit -> (unit -> 'a) as 'a. type unit -> 'a where 'a is again unit -> 'a. That is called a recursive type and you have to wrap that explicitly into a constructor like the cont type.
<mrvn>
Lots of people have used it.
<middayc>
I will study your code and see what I can do with this , thanks
slash_ has quit [Client Quit]
Alpounet has quit [Read error: 104 (Connection reset by peer)]
<mrvn>
middayc: you might want to start with something simpler.
Alpounet has joined #ocaml
<middayc>
it was simple to do in rebol , here it looks more like science , I don't even know what your line about recursive type actually means
<middayc>
I am not bashing ocaml by this, I know things can't be the same in a dynamic interpreted (not even bytecoded) language and ocaml
<mrvn>
# let actor = let x = ref 1 in fun () -> Printf.printf "Actor was called %d times\n" !x; incr x;;
<mrvn>
val actor : unit -> unit = <fun>
<mrvn>
# actor (); actor (); actor ();;
<mrvn>
Actor was called 1 times
<mrvn>
This way might be simpler
<mrvn>
Actor was called 2 times
<mrvn>
Actor was called 3 times
<mrvn>
middayc: the recursive type here means that part of the type of the function is the type of the whole function.
<mrvn>
middayc: specifically the return value of the function being the function itself.
<mrvn>
You can have recursive types like that with "ocaml -rectypes": # let rec actor () = actor;;
<mrvn>
val actor : unit -> 'a as 'a = <fun>
<middayc>
yes, I get that if function returns itself type recurses indefinitely, but I don't know what that means ... I have to do some more reading (probably a lot more)
<mrvn>
It is generaly just something you don't want and want the compiler to complain. So by default no rectypes.
<middayc>
ok, thanks a lot for your help
maskd has joined #ocaml
valross has joined #ocaml
ttamttam has quit ["Leaving."]
ikaros_ has joined #ocaml
yziquel has joined #ocaml
<yziquel>
http://paste.lisp.org/display/91247 I'd need to allocate such a C structure in OCaml, but the garbage collector should not be moving it. Can this be implemented?
jcaose has quit [Read error: 110 (Connection timed out)]
<mrvn>
yziquel: just allocate it in C and define it as abstract type in ocaml.
<yziquel>
mrvn: a malloc?
<mrvn>
sure
<yziquel>
mrvn: cool.
<mrvn>
The GC only moves things inside its heap.
<mrvn>
or make it a custom type with finalizer.
<yziquel>
mrvn: the point is that this structure is allocated on the stack of a C function, and i'm translating the function to OCaml.
<mrvn>
stack? That would only have the lifetime of the function
<yziquel>
mrvn: yes. exactly. that's the point.
<mrvn>
That is verry dangerous. Better to put it on the heap
<yziquel>
mrvn: but that's a chained list, all of them in stacks of functions that call themselves. I cannot have the GC move them around.