Hadaka has quit [Read error: 60 (Operation timed out)]
Hadaka has joined #ocaml
slash_ has quit [Client Quit]
onigiri has quit [Client Quit]
tmaedaZ is now known as tmaeda
thrasibule has joined #ocaml
Modius_ has joined #ocaml
Modius has quit [Read error: 104 (Connection reset by peer)]
willb has joined #ocaml
bzzbzz has joined #ocaml
Hadaka has quit [Read error: 104 (Connection reset by peer)]
Hadaka has joined #ocaml
kaustuv has joined #ocaml
Hadaka_ has joined #ocaml
Hadaka has quit [Read error: 104 (Connection reset by peer)]
Hadaka_ is now known as Hadaka
Lomono has joined #ocaml
Lomono has left #ocaml []
Lomono has joined #ocaml
Lomono has left #ocaml []
dyaso has joined #ocaml
mjs22 has joined #ocaml
mjs22 has quit []
jlouis has quit [Read error: 110 (Connection timed out)]
mjs22 has joined #ocaml
jlouis has joined #ocaml
jeddhaberstro has joined #ocaml
Yoric[DT] has joined #ocaml
jeddhaberstro has quit [Client Quit]
Yoric[DT] has quit ["Ex-Chat"]
dyaso has quit [Read error: 110 (Connection timed out)]
mjs22 has quit []
smimou has joined #ocaml
caligula__ has joined #ocaml
f[x] has joined #ocaml
_zack has joined #ocaml
caligula_ has quit [Read error: 110 (Connection timed out)]
sramsay has joined #ocaml
sramsay has quit [Remote closed the connection]
bluestorm has joined #ocaml
dyaso has joined #ocaml
<pveber>
lazard: ledit is an alternative to rlwrap though it seems less sophisticated (supports history though). I'll also have a look at rlwrap, seems in more active development than ledit
f[x] has quit [Read error: 145 (Connection timed out)]
<flux>
bluestorm, it is sort of annoying that the default values of the table cannot be used..
Yoric[DT] has joined #ocaml
<Yoric[DT]>
Hi
<Yoric[DT]>
Has anyone seen Arnaud Spiwack recently?
<flux>
I suppose I could define the table twice, one with the default value fields omitted :)
<flux>
but that's a bit too inflexible
<bluestorm>
flux: ok, I'll work on that
<bluestorm>
I'm also considering reverting to a phantom type distinction between "table" and "views", instead of a type one
<bluestorm>
(that would probably somewhat break existing code so I have to decide before going 1.0)
<flux>
bluestorm, that would be nice
<flux>
btw, insert doesn't seem to work the way you think it works
<bluestorm>
oh ?
<flux>
or maybe it does, but
<flux>
INSERT INTO document ((SELECT 0 AS origin, '' AS title)); -- will fill columns in order
<flux>
not the named columns
<flux>
so if I have a different order in the table definition, it will break too
<flux>
(my document-table is CREATE TABLE document ( document SERIAL PRIMARY KEY, created TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP, title TEXT NOT NULL DEFAULT '', origin INTEGER REFERENCES origin NOT NULL DEFAULT 0 ); )
<flux>
and I have let document_no_defaults_tbl = <:table< document ( title text NOT NULL, origin integer NOT NULL ) >>
<bluestorm>
oh, I see
<bluestorm>
hm
<bluestorm>
the easiest way to work around that would be to ask table descriptions the numeric offset of each column in the real table
<bluestorm>
I'm not sure it's sound though
<flux>
can't use the names?
<bluestorm>
hm
<flux>
insert into document (origin, title) as select ..
<flux>
uh, scrapt the 'as '
<bluestorm>
lemme check the doc
gim_ is now known as gim
<bluestorm>
oh yes
<flux>
yeah, this seems to work: INSERT INTO document(origin, title) ((SELECT 0 AS origin, '' AS title));;
<bluestorm>
I for some idiot reason thought that named columns was restricted to the VALUES syntax
<flux>
(I didn't know about that tuple-insertion syntax)
<flux>
don't worry, I'm still highly impressed by the library overall, even if it still has work left :)
<bluestorm>
(the main thing pushing me towards a phantom-types distinction between table and views is the possibility that user register using the pa_descr mechanism actual SQL views, wich are not insertable)
<flux>
can't you add yet-another phantom type to differentiate between those?
<bluestorm>
that's the idea, but once you have that phantom distinction, the actual view/table distinction can probably go away
<bluestorm>
(and I think that would be quite benefic to the overall ease of use)
<flux>
happily I've worked around my current issues so I can proceed hacking
smimou has quit ["bli"]
leadnose has joined #ocaml
tmaeda is now known as tmaedaZ
f[x] has joined #ocaml
<wysek>
what testing framework/tool do you recommend?
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
<bluestorm>
wysek: -linkpkg is needed when producing an executable, for simple .cmo productions (-c) you don't need it
<bluestorm>
(no linking involved)
<wysek>
does -o option imply -linkpkg?
<wysek>
because in another project I have
<wysek>
CC=ocamlfind ocamlc -package sem -cclib -lpthread -g
<wysek>
and then I use $(CC) -c mostly
<wysek>
and -o for few executables
<bluestorm>
I only use -o for executables, and in that case the answer is yes
<bluestorm>
but maybe you can use "-o foo.cmo", I'll check
<wysek>
sorry
<Camarade_Tux>
you need -o for .cma files iirc
<wysek>
I use $(CC) -c -o $@
<wysek>
and the same but without -c for executables
<bluestorm>
well, add -linkpkg to you executable-command
<wysek>
as I said it works, but I'm curious why I didn't had to add -linkpkg to this project
<bluestorm>
maybe the "sem" package doesn't link anything ?
dyaso has quit [Read error: 110 (Connection timed out)]
<flux>
bluestorm, you got your second bug, the project must be gaining some ground!
<flux>
;)
<bluestorm>
wow :]
<bluestorm>
and that's an easy one, let's show some reactivity !
<flux>
ooh, I finally wrote my first non-trivial statement without any error in the first try..
<bluestorm>
flux: should I allow a final ';' for comp_items ?
<flux>
bluestorm, I suppose it wouldn't hurt. and it would not be fully against ocaml either, because at present they just produce obscure errors or work ok..
<bluestorm>
camlp4 code for that is uglier than the usual "LIST0 .. SEP ';'", but let's do it
<bluestorm>
(but I _won't_ allow a final "," in ORDER BY clauses :-p )
<flux>
:)
<flux>
you also don't nede to allow a final , in pa_descr :)
_zack has quit ["Leaving."]
<bluestorm>
flux: pushed
<flux>
seems to work
<bluestorm>
that's also what I though
<bluestorm>
t
<flux>
another thing is that offsets seem to get messed up at some point.. but I don't have a decent test case for it.
<flux>
so I'll try to make one at some point and submit that
<bluestorm>
offsets ?
<bluestorm>
(i've had a bug where the fields order got reordered during type unification, maybe that's something similar ?)
<flux>
no, I mean
<flux>
when I get errors during compile, emacs takes me to slightly wrong places
<bluestorm>
oh
<flux>
or when I ask type information, it gives slightly bad hlighlighting
<bluestorm>
'locations' is the dedicated camlp4 term
<flux>
right
<bluestorm>
you could probably send me an not-so-decent test case
<flux>
I suppose it doesn't matter that one needs multiple files for this to compile. the file I'm seeing this is however 120 lines long..
<bluestorm>
hm, the fix would probably only need local informations, so I could do with a long file
<bluestorm>
(or basically quoting a few lines around the error with ASCII marks around the given locations and the wished locations could be enough)
<flux>
actually now that I fixed my errors it works fine. could it be that it happens only in error situations?
<flux>
I need to revert to my buggy version perhaps :)
<bluestorm>
hm
<bluestorm>
there are some upstream camlp4 bugs. wrt. antiquotations locations
<bluestorm>
you might have run into those
<flux>
I'll try to find some nice easily testable bug, it's not that urgent
<flux>
bluestorm, hey, the bug is still open :-)
Ched has quit [Read error: 148 (No route to host)]
<flux>
observe docArch.ml and the annotated file, and see that page_fs has the wrong type in the main-function
<bluestorm>
ok
<flux>
(when it is an argument to process_incoming)
<flux>
actually I'm not 100% sure it's due to that extension :-o, because I'm doing other funky stuff there also
<flux>
anyway, the annotated source says: ((page_fs:int32 list):?format:string -> int32 -> string) - which makes no sense
Yoric[DT] has joined #ocaml
<bluestorm>
flux: it seems ./annotator -source docArch.ml -annot ... doesn't produce an annotated file
<bluestorm>
(on my computer)
<flux>
bluestorm, it produces output?
<bluestorm>
hm
<flux>
and requires the original ml-file and the .annot-file as inputs
<bluestorm>
yes
<flux>
but it doesn't produce any output?
<bluestorm>
i tested it on a simple source
<bluestorm>
on your docArch it only annotates ^/
<bluestorm>
(so yet it produces output, but mostly the unchanged source)
<flux>
hmm
<flux>
I wonder, did they change the annot file format at any point? I'm on 3.10
<bluestorm>
was the "(x, )" on line 12 intentional ? i had to remove the comma to get the annot file
<bluestorm>
oh that's a possibility
<flux>
it wasn't intentional, funny how it compiles though :)
<flux>
doesn't work on toplevel though :-o
<bluestorm>
well it didn't compile in my place
<flux>
likely a fixed bug
<bluestorm>
or perhaps you were using an older .annot from a previously successful compilation ?
<flux>
my annot files seem to have updated in a useful way since that bug
hkBst has joined #ocaml
<bluestorm>
flux: regarding your NEXTVAL() hack, you could also probably use PG'OCaml higher-level syntax
<bluestorm>
(is that "current_timestamp" function useful ? I can add it)
<flux>
bluestorm, yeah, but it'd be yet another language extension, and macaque is going to eventually obsolete the trick anyway?
<flux>
bluestorm, I use current_timestamp because that's a default value of a column; support for default values would supercede it
<bluestorm>
ok
<bluestorm>
flux: I'm not sure macaque will ever get feature parity wrt. PG'OCaml, and find it comfortable to think that "in case, user can always revert to PG'OCaml locally" :-'
<bluestorm>
also : I looked at annotator.ml and it does not gracefuly support new 3.11 annotations
<bluestorm>
(that is, it fails as soon as it finds one, instead of ignoring it)
<bluestorm>
we could probably fix it more or less uglily, but maybe there is an up-to-date upstream version somewhere ?
<flux>
bluestorm, yes, it indeed is comfortable. I've found situations with PG'OCaml which have required rewriting the query verbatim, but slightly different, which sucks..
<flux>
so for me macaque can even be a superset ;)
<flux>
I think that version was copy-pasted from someone on this channel, who had pasted it into a pastebin
<flux>
so I don't think it's being heavily maintained :)
<flux>
ah, (* pango pasted this to freenode/#ocaml *)
Asmadeus has quit ["brb"]
<bluestorm>
hm
Asmadeus has joined #ocaml
<bluestorm>
he also apparently supposed that all types in the .annot file would fit in one line
Mechant_Tux has joined #ocaml
<bluestorm>
wich is a gross underestimation for macaque-using projects
<flux>
:)
<flux>
so .annot-files have a line length limitation then?
<bluestorm>
hm
<bluestorm>
I suppose it's rather than types are pretty-printed
<bluestorm>
(and I was wrong, he actually supports multi-line)
<flux>
actually I think I've been wrong to blame macaque on those offsets :/
<flux>
it looks like my emacs is confused by tabs
Camarade_Tux has quit [Read error: 145 (Connection timed out)]
<bluestorm>
(corrected the output, apparently the location ending behaviour was changed)
Amorphous has joined #ocaml
Lomono has joined #ocaml
Lomono has left #ocaml []
tmaedaZ is now known as tmaeda
dyaso has joined #ocaml
julm has quit ["couic"]
<bluestorm>
flux: sequences description and operations pushed
<thelema>
Is there any way to have a "list" type like this: ('a, ('b, ('c, 'd)))?
<bluestorm>
currently only `currval` and `nextval` are supported, I'm considering adding `setval` but that would require a bit of work as I don't have any other unit-returing operators for now
<bluestorm>
thelema: I don't think so, but you can use product types for that purpose
<flux>
thelema, it might be, if you use polymorphic recursive functinos tricks. but I don't remember how my experiments ended up..
<flux>
thelema, I suppose one could construct/deconstruct similar objects with the functional unparsing-tricks
<thelema>
I'm trying to have a tree type where the type of the levels of the tree (including its height) is encoded in the type of the tree
<thelema>
bluestorm: I don't see how to use product types for that purpose
<thelema>
well, maybe a static heirarchy of them...
<bluestorm>
thelema: if you try to encode tree length at the type level, you will run into the polymorphic recursion limitation
<flux>
ooh, six new shiny patches
<thelema>
can't have polymorphic recursion?
<thelema>
apparently I didn't pay enough attention to the mailing-list entries on polymorphic recursion
<thelema>
hmm, apparently I can use records to do this...
<flux>
polymorphic recursion can also be ahcieved through recursive modules
<thelema>
that seems much more heavyweight
<thelema>
or maybe not. I'll investigate it sometime.
<maxote>
hi guys, is practical the use of MetaOCaml for building an interpreter written in it?
<thelema>
It's apparently a more complex subject than it needs to be.
<Camarade_Tux>
sigh, one day I'll be able to write at least a part of my web browser ='(
<flux>
bluestorm, can I extend the set of types pa_descr supports?
<flux>
bluestorm, I mean, in an application-specific fashion
<flux>
for example by providing a new Table_type-module?
<bluestorm>
hm
<bluestorm>
that's not possible right now, and would require signification changes in the implementation
<bluestorm>
however, I have considered adding a "serialisation" feature
<flux>
bluestorm, it would be useful (more safety guarantees) to be able define new types for for example table keys etc
<bluestorm>
that would allow to relate others Caml types to the existing hardcoded datatypes, by providing conversion functions
<flux>
bluestorm, for example now have tons of integer-keys, where some are compatible but some aren't
<bluestorm>
flux: I think that is included in the limited feature I'm considering
<bluestorm>
the idea is that you don't add sql-side types, but provide conversion functions to known types, and then get the good caml-side types
<flux>
that would be sufficient; ideally macaque would support all postgresql types natively
<flux>
although, it is possible to add postgresql types also
<bluestorm>
well macaque currently support *almost* all PG'OCaml-supported types
<flux>
perhaps those are cases rare enough not to warrant specific support for it; you can always modify the source..
<flux>
I wonder how many PG-types stay unsupported
<bluestorm>
(I haven't made bytea available because I wasn't sure what the intended input/output escaping is)
<bluestorm>
if you want to add support for more sql types (geolocation etc.), I think adding them upstream (eg. in PG'OCaml) would be a better first step
<flux>
ideally macaque support code would somehow automatically from from PG'Ocaml :)
<flux>
s/from/flow/
<bluestorm>
enabling a PG'OCaml type in Macaque is not very difficult (there is a difference though : PG'OCaml directly sends data to the SQL server, while Macaque use the SQL frontend and thus must care about proper input escaping syntax and such)
smimou has joined #ocaml
<bluestorm>
ertai: how hard would it be to add support for (possibly limited) parametrized rules to Camlp4 ?
dyaso has quit [Read error: 110 (Connection timed out)]
marteo has joined #ocaml
thrasibule has quit ["No Ping reply in 90 seconds."]
thrasibule has joined #ocaml
harlos has joined #ocaml
th1_ has quit [Remote closed the connection]
th1_ has joined #ocaml
tmaeda is now known as tmaedaZ
Yoric[DT] has quit ["Ex-Chat"]
slash_ has joined #ocaml
peddie has joined #ocaml
_zack has quit ["Leaving."]
sramsay has joined #ocaml
rwmjones has quit ["Leaving"]
BiD0rD has joined #ocaml
BiDOrD has quit [Read error: 110 (Connection timed out)]
Yoric[DT] has joined #ocaml
<thelema>
I thought the following type was legal, but ocaml complains it's cyclic: type network_tree = router * network_tree list
<thelema>
ah, it's explained in chapter 24 of ... the o'reilly book
<thelema>
hmm, how to enable -rectypes through ocamlbuild
<bluestorm>
yes it's cyclic :]
<bluestorm>
type network_tree = Tree of router * network_tree list
<bluestorm>
(or add -rectypes)
<bluestorm>
I would rather advise you to add an explicit constructor
<bluestorm>
if your type is to be public (exported outside the module boundaries), module user will have to use -rectypes themselves
<bluestorm>
and this is considered bad practice as it leads to a weakening of error messages and error detection by the compiler
jeddhaberstro has joined #ocaml
<thelema>
gotcha.
<bluestorm>
but I guess a "-cflag -rectypes" could do the job
<thelema>
out of curiosity, that's not trivial to put into _tags, is it? I'd have to modify my myocamlbuild.ml file to do so, right?
<bluestorm>
yes you have, no it's not "not trivial"
<bluestorm>
it's actually rather easy
<bluestorm>
hm
<bluestorm>
they might even be an existing tag, let me see
<bluestorm>
yes, there is a "rectypes" tag thelema
<thelema>
ah, great. I'll keep that in mind if I need one.
<thelema>
where's the list of the predefined tags? (other than the source)
<bluestorm>
I looked into the source
<thelema>
ah, ok. what file?
<flux>
:-)
<bluestorm>
cd .../ocamlbuild
<bluestorm>
grep rectypes -R .
<bluestorm>
actually
<thelema>
heh.
<bluestorm>
ocaml_specific.ml is usually what you're looking for
<thelema>
/lazyweb off
<thelema>
thanks
<thelema>
hmm, I wonder if the term lazyirc means anything yet
sramsay has quit [Remote closed the connection]
Alpounet has joined #ocaml
Pepe_ has quit [Read error: 110 (Connection timed out)]
onigiri has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
Asmadeus has quit ["Lost terminal"]
Asmadeus has joined #ocaml
julm has joined #ocaml
slash_ has quit [Read error: 54 (Connection reset by peer)]
slash_ has joined #ocaml
<f[x]>
thelema, list of predefined tags -- ocamlbuild -documentation
bluestorm has quit [Read error: 113 (No route to host)]
bluestorm has joined #ocaml
ulfdoz has joined #ocaml
willb has joined #ocaml
Smerdyakov has joined #ocaml
marteo has quit [Read error: 110 (Connection timed out)]
marteo has joined #ocaml
<Smerdyakov>
Does anyone know how many pounds I will want to have on hand in cash when I arrive at ICFP in Edinburgh? :)
<Yoric[DT]>
:)
<Smerdyakov>
Yoric[DT], I'll be at your DEFUN tutorial.
<Yoric[DT]>
I'm kind of nervous about that tutorial.
<Smerdyakov>
Are you nervous because it's an unusual kind of talk/audience?
ulfdoz has quit [Read error: 145 (Connection timed out)]
<Yoric[DT]>
yep
<Smerdyakov>
Well, perhaps your nervousness is not based on rational cause, but I'm sure the audience will be very friendly in any case, and it's unlikely that anything will go wrong if you just tell it like it is. :)
<Yoric[DT]>
:)
<Smerdyakov>
Code demos of systems that are actually cool are so easy to do when you have 45 minutes. It would actually be hard to screw such a thing up.
_andre has quit ["Lost terminal"]
Pepe__ has joined #ocaml
<Yoric[DT]>
Might also be because
<Yoric[DT]>
* 45 minutes is a long time
<Yoric[DT]>
* I'm not quite ready yet
<Yoric[DT]>
* I have lots of work until DEFUN, both days and nights
<Yoric[DT]>
* I'm already quite tired.
<Yoric[DT]>
Still, it should be fun.
<det>
Smerdyakov, I think that is a personal issue, have you tried dieting?
f[x] has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
det :)
<Yoric[DT]>
Well, night everyone.
Yoric[DT] has quit ["Ex-Chat"]
Smerdyakov has quit ["Leaving"]
marteo has quit [Read error: 110 (Connection timed out)]
marteo has joined #ocaml
bombshelter13_ has quit []
slash_ has quit [Read error: 104 (Connection reset by peer)]
Alpounet has quit ["Leaving"]
<ertai>
bluestorm: I don't really know
<bluestorm>
ok
<ertai>
changing the parsing algorithm is too hard in the current state
<bluestorm>
hm
<bluestorm>
but camlp4 rules are represented in a data structure, right ?
<ertai>
ight
<ertai>
right
<bluestorm>
s/represented/reified/
<ertai>
both indeed
<bluestorm>
would it be possible to parametrize that data structure production on some of the component rules ?
<ertai>
EXTEND ... syntax desugar to function calls to build a data structure
<bluestorm>
eg. some whay of coding LIST foo SEP blah ourselves
<bluestorm>
-h
<ertai>
maybe
<ertai>
but it would require changes to the core algo
<ertai>
and that's the problem
<ertai>
plus the fact that since stream parser (really expressives) were there before
<ertai>
I can conclude that the limited support for parameterized rules in camlp4 is a real limitation of the algo/structures
<ertai>
otherwise it would have been already done
<bluestorm>
ok
<ertai>
However I consider myself a bit defeatist about the parsing algo of camlp4
<bluestorm>
hm
<bluestorm>
do you mean that I could be better than you think, or that it is worse than people think ? :p
<bluestorm>
*It could
<ertai>
I think it's worse than people think
<ertai>
but there are also better guys than me at understanding camlp4 algo
<bluestorm>
hm
<ertai>
at least Jerome Vouillon fixed two very hard bugs (for me to find) in one afternoon
<bluestorm>
:D
<ertai>
however he wrotes the debugger :)
slash_ has joined #ocaml
thrasibule has quit ["No Ping reply in 90 seconds."]
thrasibule has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
hkBst has quit [Remote closed the connection]
thrasibule has quit ["No Ping reply in 90 seconds."]
thrasibule has joined #ocaml
lutter has quit ["Leaving."]
thrasibule_ has joined #ocaml
lutter has joined #ocaml
thrasibule has quit [Read error: 104 (Connection reset by peer)]
Narrenschiff has joined #ocaml
duplo has quit [Read error: 113 (No route to host)]
marteo has quit ["Debian GNU/Hurd is Good."]
Narrenschiff has quit []
nodie has joined #ocaml
bluestorm_ has joined #ocaml
bluestorm has quit [Read error: 104 (Connection reset by peer)]
dyaso has joined #ocaml
bluestorm_ has quit [Remote closed the connection]