Jedai has quit [Read error: 104 (Connection reset by peer)]
Philonous has joined #ocaml
ppsmimou has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
Mr_Awesome has quit [kornbluth.freenode.net irc.freenode.net]
jlouis has quit [kornbluth.freenode.net irc.freenode.net]
Amorphous has quit [kornbluth.freenode.net irc.freenode.net]
Amorphous has joined #ocaml
jlouis has joined #ocaml
Mr_Awesome has joined #ocaml
ppsmimou has joined #ocaml
mfp has joined #ocaml
Amorphous has quit [SendQ exceeded]
Nafai has joined #ocaml
Amorphous has joined #ocaml
Palace_Chan has joined #ocaml
Amorphous has quit [kornbluth.freenode.net irc.freenode.net]
ppsmimou has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
Mr_Awesome has quit [kornbluth.freenode.net irc.freenode.net]
jlouis has quit [kornbluth.freenode.net irc.freenode.net]
Amorphous has joined #ocaml
jlouis has joined #ocaml
Mr_Awesome has joined #ocaml
ppsmimou has joined #ocaml
mfp has joined #ocaml
tvn1981_0 has joined #ocaml
struktured_ has joined #ocaml
Philonous1 has joined #ocaml
Palace_Chan has quit ["Palace goes to sleep"]
Philonous has quit [Read error: 113 (No route to host)]
struktured_ has quit [Read error: 60 (Operation timed out)]
seafood has joined #ocaml
apples` has quit ["Leaving"]
seafood has quit []
apples` has joined #ocaml
johnnowak has joined #ocaml
johnnowak has quit [Client Quit]
seafood has joined #ocaml
jeddhaberstro has quit []
mishok13 has joined #ocaml
<flux>
mfp, regarding relational: File "example1.ml", line 113, characters 27-29:This expression has type < exec : ?expect:Postgresql.result_status list -> string -> < error : string; status : Postgresql.result_status; .. >; .. >but is here used with type #Postgresql.connection Types for method exec are incompatible
<flux>
(latest version from git (2008-02-05))
<flux>
ah, a simple fix to the exec_sql's type
<flux>
I was just scared away by camlp4 ;)
apples` has quit [Read error: 104 (Connection reset by peer)]
|Jedai| has quit [Read error: 110 (Connection timed out)]
bluestorm has joined #ocaml
ygrek_ has joined #ocaml
filp has joined #ocaml
<flux>
I also added findlib support, seems to work with example1.ml
Mr_Awesome has quit ["aunt jemima is the devil!"]
itewsh has joined #ocaml
Camarade_Tux has joined #ocaml
DroneZilla has joined #ocaml
tvn1981_0 has quit ["Leaving"]
DroneZilla has quit []
Kerris4 has joined #ocaml
ulfdoz has joined #ocaml
velco has joined #ocaml
Yoric[DT] has joined #ocaml
<flux>
apparently caml-types.el doesn't quite support the configuration where .annot-files end up in the _build-directory
<Yoric[DT]>
hi
<flux>
but the workaround is simple: rm *.annot; make; cp _build/*.annot . ;-)
<det>
I wonder if anyone would be interested in 7zip bindings
<Camarade_Tux>
det, I already started some :D
<det>
I have about 50% done bindings
<Camarade_Tux>
Yoric[DT], hi
<det>
because all I needed in my application was to list the files
<Camarade_Tux>
det, but to be sure, lzma or 7zip ?
<det>
just 7zip
<det>
as in 7zip does the lzma transparently
<Camarade_Tux>
yep, same approach ;)
<det>
how much progress have you made ?
<Camarade_Tux>
I've been surprised to see that all the bindings around were for lzma, never 7zip...
dabd has joined #ocaml
<Camarade_Tux>
det, I currently extract files
<det>
ahh, that is more than me
<det>
although, I think I can get feature parity with camlzip in an hour or 2
<det>
you used the code from the 7zip SDK ?
<Camarade_Tux>
and the extraction function take another function as parameter which lets you rename a file (extraction to different path) or ask the user when several name collides
<bluestorm>
Yoric[DT]: random thought from the reading of your blog article
<Camarade_Tux>
det, lzma_sdk
<Yoric[DT]>
bluestorm: yes?
<bluestorm>
we may benefit from a standard set of infix operators for application/composition
<det>
you handle the 7zip container in pure ocaml ?
<Yoric[DT]>
bluestorm: we have it
<bluestorm>
hm
<Yoric[DT]>
bluestorm: extPervasives.mli
<bluestorm>
ah btw.
kig has joined #ocaml
<det>
let (|>) a b = b a
<det>
would be very nice to have in the standard top level
<bluestorm>
mfp, do you have particularily good ressources for learning git (i've used darcs a bit)
<det>
I think F# has it
<Camarade_Tux>
det, nope, 7zip does, I tried but did not succeed with bitstring and in the lzma_sdk, the files in C/Archive/7z/ do
<bluestorm>
if you're busy, don't bother, i'll pick one of the brazillions of introductions on the net
<det>
That is exactly what I do
<kig>
anyone have experience in using ocaml to do gui work (thinking of gtk, cairo, maybe opengl)
<det>
Camarade_Tux, how do you open files? From Ocaml and then passed to C or from C ?
* Camarade_Tux
just saw the ocaml source code used let (++) a b = b a but that doesn't matter much
<bluestorm>
det: the problem are operator associativity/precedence, and getting everybody to agree
<bluestorm>
Camarade_Tux: isn't it let (++) f g x = f (g x) ?
<Yoric[DT]>
det: we have that one.
<det>
Yoric[DT], in Batteries ?
<Yoric[DT]>
(and yes, there's the matter of associativity/precedence)
<Camarade_Tux>
bluestorm, I think that's for (+++) ;)
<Camarade_Tux>
det, currently there is something non-optimal but you can open an Unix.file_descr in ocaml and then in your C part use fdopen() to get the type you need
<flux>
nice, its user name already has the first name right
<bluestorm>
kig: thanks
<Camarade_Tux>
let (++) x f = f x
<Camarade_Tux>
let (+++) (x, y) f = (x, f y)
marmotine has joined #ocaml
* Yoric[DT]
is currently re-testing the gzip/gunzip bindings.
<det>
Camarade_Tux, ahh, my code passes 2 closures to the C code that implement read and seek
<det>
Camarade_Tux, so, it can work on anything, including something like ExtLib generic IO
<Camarade_Tux>
det, that's something I hadn't thought of
<Camarade_Tux>
I wanted that capability btw
<det>
I can post my code somewhere, if you are interested
<det>
I will try to finish my bindings in the nest few days as well, I think.
<det>
next*
<det>
(right now I just have open/list with same interface as camlzip)
<Camarade_Tux>
I'd like to have the 7zip bindings share the IO interface
<Camarade_Tux>
what features do you want ?
<det>
camlzip parity
<det>
just with 7zip container instead
<Camarade_Tux>
okay, I have to check camlzip's interface but at least we're probably not going to do the same work twice :p
<Yoric[DT]>
Well, whenever it's finished, don't forget to package it and inform us :)
<Camarade_Tux>
Yoric[DT], of course :p
<det>
I'm not interested in any kind of high level extract functionality
Mr_Awesome has joined #ocaml
<Camarade_Tux>
det, I need them because I need to be able to rename files, specifically, I need to be able to extract a/b/c/d/e as c/d/e
<Camarade_Tux>
det, when you're done, make a package or just put the files together and I'll try to put both our work in the same package :)
<Camarade_Tux>
compression will take longer however...
<det>
what do you mean
<det>
implementing ?
<det>
looking at the 7zip test example, compression and decompression seemed to be a couple of under 10 line C loops
<det>
can probably just copy them almost verbatim
<Camarade_Tux>
det, I mean implementing compression
<Camarade_Tux>
probably not by ourselves (that would be too slow I think) but compressing with lzma and wrapping the results in the proper headers
<det>
7zip handles all that
<Camarade_Tux>
det, I haven't found a way to bind to that
<det>
did you look at 7zMain.c
<Camarade_Tux>
I haven't found an *easily* accessible function
<det>
I expect it to be very very easy
<Camarade_Tux>
I don't see compression there...
<det>
ahh, yeah, I only see decompression: SzAr_Extract
<Camarade_Tux>
I understood that this was not meant to be available
<det>
why ?
<det>
SDK only targets handling of 7z and not creation ?
<Camarade_Tux>
det, it handles creation of lzma files, not of 7z ones
<Camarade_Tux>
but afaik 7z is just lzma + headers + compression filter
<det>
ok, shouldn't be too hard then
<_zack>
Camarade_Tux: I'm jumping in an old message, but now in Batteries we have an interface which is presumed to become *common* to all compression back-ends
<_zack>
you should have a look at that for IO integration
<Camarade_Tux>
_zack, yep, I plan to have that interface ;)
<_zack>
but it's only in batteries git right now, no API docs on the web yet
<flux>
I take it those compression interfaces support also in-memory compression?
<_zack>
not yet, but it is planned
<Yoric[DT]>
Well, now that the doc generation re-works, we'll have the API doc soonish.
<Camarade_Tux>
det, I thought it was the same as the extlib one
<flux>
how about compressing multiple blocks with a shared dictionary or other shared pool of startup knowledge?
<Yoric[DT]>
_zack: have you been able to reproduce the gzip/gunzip bug mentioned by thelema?
<_zack>
flux: that starts to be too specific
<_zack>
Yoric[DT]: mentioned where?
<flux>
for example for compressing stuff like lists of words while still being able to uncompress any one of them
<Camarade_Tux>
det, I got stuck when writing the header part however, I'll have to ask Richard Jones one or two things, especially wrt to parsing a list (or something that looks like a list)
<Yoric[DT]>
_zack: Bug tracker.
<_zack>
Yoric[DT]: uh ?
<flux>
I believe atleast gzip's interface supports that
<_zack>
there was just one bug there, reported by me, and according to your comments fixed with the last put
* thelema
notices yoric promises unicode vs string compatibility - I guess that's my cue to get back to work on that
<Yoric[DT]>
thelema: where is that?
<Yoric[DT]>
gildor: yep
<thelema>
Yoric[DT]: git commit C6B8BF12 - in VERSION
<Yoric[DT]>
Ah, that :)
<Yoric[DT]>
Well, I can move this to Alpha 3 if it's not ready.
* Yoric[DT]
thought that was finished.
<thelema>
getting there. It's a bit of a pain to do reverse character searching through ropes.
<thelema>
btw, do you use [gitk --all]?
<Yoric[DT]>
thelema: just checked on your pdf, works for me.
<thelema>
hmmm...
<Yoric[DT]>
I have the same md5sum for GNU gzip, GNU gunzip / GNU gzip, Batteries gunzip / Batteries gzip, GNU gunzip / Batteries gzip, Batteries gunzip.
<gildor>
if you want to see bugs and report new one
<mfp>
_zack: added gzip & gunzip to the mix, all 9 combinations OK
<_zack>
mfp: wow, good job, thanks a lot
<Yoric[DT]>
thanks
<_zack>
gildor: well, at my place, you would have been replying that "ocaml-fileutils should be hosted on forge.ocamlcore.org" :-D
<_zack>
SCNR
<gildor>
_zack: ocaml-fileutils was hosted there years before ocamlcore.org ;-)
<gildor>
but I am thinking to migrate
<gildor>
(forge.ocamlcore.org is such a nice place)
<_zack>
lol
<Yoric[DT]>
:)
* Yoric[DT]
is preparing the release.
itewsh has joined #ocaml
<hcarty>
Yoric[DT]: Does using Batteries require switching completely away from ExtLib, since it embeds its own version?
<Yoric[DT]>
Having both in one project should work, but that's not recommended.
zbrown has quit [Read error: 104 (Connection reset by peer)]
zbrown has joined #ocaml
<thelema>
hcarty: batteries should replace extlib quite completely.
<hcarty>
thelema: That's what I would expect. I'm just trying to see how difficult the switch will be since, for example, Enum.t for ExtLib is different as far as OCaml is concerned than Enum.t for Batteries.
<Camarade_Tux>
gildor, does fileutils provide basename/dirname ?
<gildor>
yes
<thelema>
true, yoric did add some extra stuff into enum - but if you switch the whole project over, it should work.
<gildor>
(one of the fileutils problem is that its documentation is awful, I have reworked that to make things more easily findable)
<hcarty>
I need to dig through what Batteries provides in its Standard library as well - I think there are some clashes with things I have defined locally
vixey has joined #ocaml
<hcarty>
Like ( --- ) which I was using for floating point enums ... (1.0, 0.1) --- 2.0
<hcarty>
Is this information listed in the Batteries documentation?
<Camarade_Tux>
gildor, hehe, I was looking inside FileUtil, not FilePath ;)
<thelema>
hcarty: you want a list of the symbols you've defined that clash with batteries?
<thelema>
if you open batteries first, your symbols will take precedence.
<hcarty>
thelema: A list of what is exported by default from Batteries
<hcarty>
The documentation does not seem to cover the Standard module
<hcarty>
Or, the docs on the web do not seem to at least
<thelema>
the docs on the web are old.
<Yoric[DT]>
hcarty: it should be source-to-source compatible.
<Yoric[DT]>
with Enum, that is
<Yoric[DT]>
The new documentation will cover Standard.
<Yoric[DT]>
(well, the new documentation does cover Standard -- it's just not published yet)
<Yoric[DT]>
_zack: speaking of which, where do you wish us to put the documentation?
<_zack>
Yoric[DT]: meaning?
<_zack>
in the website you mean?
<Yoric[DT]>
Yep
<_zack>
ah, I don't care, currently the "website" is just a single .php file, put it wherever you want, then we will add links to it
<Yoric[DT]>
ok
<_zack>
the old layout was good
<_zack>
but I've no idea about how the directory placement in htdocs/ interacts with the forge doc manager
<_zack>
(if it does)
apples` has joined #ocaml
<Yoric[DT]>
No, it doesn't.
<Yoric[DT]>
You just choose a url in the doc manager.
<_zack>
ah, ok
<_zack>
then create a dir doc/ and that's it
<_zack>
in fact, I don't see the need of having batteries version name in the doc manager entries
<_zack>
we can keep just one entry "api reference" and update the version within the doc
<Yoric[DT]>
Fair enough.
<Yoric[DT]>
Well, maybe when we reach post-release 1, we'll need that again.
<Yoric[DT]>
But for now, that shouldn't matter.
<_zack>
yup, for batteries 2020 we will need a full versioning of API docs like Java currently have :-P
<Yoric[DT]>
:)
* Yoric[DT]
is trying to find out exactly how he can customize configure.ac to install to the GODI documentation directory.
* Yoric[DT]
would prefer writing that code in OCaml :)
<_zack>
--with-docroot=DIR
<_zack>
ah, I see
<_zack>
you want a default set automatically for GODI vs Debian
<_zack>
I thought about that, but I didn't know how to detect GODI
<_zack>
if you tell me the semantics you want to achieve I can implement that
<_zack>
Yoric[DT]: ^^^
<hcarty>
Yoric[DT]: If you are interested, the verify (bool -> exn -> unit) function I asked about yesterday is pasted here: http://ocaml.pastebin.com/m14da9488
<hcarty>
Along with a ( |? ) operator which I have found useful for handling default values for option types
<hcarty>
I use those functions most often for function argument checks. I'm not sure where they would go in Batteries though, if they are of interest
rwmjones_ has quit ["Closed connection"]
madara has joined #ocaml
psnively has joined #ocaml
psnively has quit [Remote closed the connection]
* thelema
wonders if an enum.(=) function would be useful
<flux>
mfp, is there a way to do an outer join in relational?
<flux>
perhaps it needs OUTER LEFT PRODUCT, OUTER RIGHT PRODUCT and OUTER FULL PRODUCT..
<flux>
(each have different type implications)
Anarchos has quit ["Vision[0.8.5-0418]: i've been blurred!"]
apples` has quit ["Leaving"]
bzren has joined #ocaml
<flux>
I'm not sure how the types would go then :)
<thelema>
flux: just some option types for LEFT and RIGHT products, no?
<flux>
thelema, yes
<flux>
thelema, but have you looked at relational?
apples` has joined #ocaml
<thelema>
nope
<thelema>
first time hearing of it, I think.
<flux>
well, this is an explanation of the associated constructor: Product of exists 'b 'bb 'c 'cc 'b1 'c1. ('b, 'bb) relation * ('b1 -> 'a) * ('b1 -> b) * ('c, 'cc) relation * ('c1 -> 'a) * ('c1 -> 'c)
<Yoric[DT]>
hcarty: I'll take a look.
<Yoric[DT]>
_zack: no, I don't think automatic GODI vs Debian detection would be a good idea.
<Yoric[DT]>
You can be under Debian and use GODI.
<flux>
thelema, relational is a package for doing compiler-verified relational algebra and generate sql queries out of that
<thelema>
ick.
<_zack>
Yoric[DT]: so, what are you missing from configure.ac?
<Yoric[DT]>
Well, I've added a Makefile.in patch to the GODI package, which just skips the whole directory detection.
<flux>
there's also the thing that writing a new layer can result in more work to be done and more code to be maintained
<thelema>
unlike your sql generator, which is simple and requires no maintenance
<flux>
when you put in a new query, you need to modify that new layer to guarantee safety
<flux>
but the sql generator stays same
code17 has quit ["Leaving."]
<thelema>
and your diverse set of clients all are forced to use the sql generator?
<flux>
these were distinct matters
<flux>
diverse set of clients can use any way they can to access the database ;)
<thelema>
we're busy conflating them.
<flux>
diverse client set = either database procedures or abstraction layer?
<flux>
(= means 'requires' in that context)
<thelema>
depends on what they need.
<flux>
I haven't touched my sql generator for ages, albeit it's much simpler ("select * from foo where a = ?0, b = ?1" [0, Int 42; 1, String "foo"])
<Yoric[DT]>
_zack: can you remind me how I'm supposed to set my default browser under Debian?
<thelema>
if you can do just stored procedures, do taht. otherwise, use a simple abstraction generator.
<flux>
and although relational also can need maintaining, I think it's mostly because it isn't mature yet
<Yoric[DT]>
Ah, update-alternatives.
<_zack>
update-alternatives --configure NAME, with NAME being one of "x-www-browser" and "www-browser"
<flux>
well, as I said, I use server-side smarts only a bit. for example I maintain a histogram of events automatically.
<flux>
I can just insert or delete an event and the counters get updated wherever they need to be
code17 has joined #ocaml
<flux>
and that works among the set of clients, without having a separate daemon constructing all the queries that access the relevant tables :)
<thelema>
and in small amounts, that's great. When your database is doing the work, and your client just displays the results - that's probably over the line.
<flux>
that's quite a bit too tight coupling for my taste
<flux>
well, apparently we aren't in a full disagreement ;)
<thelema>
as for generating a histogram, I'm of the school that you should keep log-style info in the DB, and generate the counters on demand
<_zack>
Yoric[DT]: regarding the browser issue, I'd like to change the API
<flux>
there are sufficiently many events to make it take too long to do on-demand
<_zack>
the compile time setting should be the default
<thelema>
the problem for me isn't tight coupling, it's misuse of the DB. "business logic" goes in your app.
<_zack>
but one should be able to change the browser string even after installation
<Yoric[DT]>
In alpha 2?
<_zack>
rationale: it is a per-user setting, rather than a per-system one
<Yoric[DT]>
Mmmhhh...
<Yoric[DT]>
Fair enough.
<Yoric[DT]>
Let's put that for alpha 3.
<_zack>
Yoric[DT]: it's as easy as exporting a string ref, or adding a set_browser method
<thelema>
flux: then accumulate the old events on idle, so that one only has to count the new ones.
<Yoric[DT]>
s/method/function
<Yoric[DT]>
but yes
<_zack>
yup
<Yoric[DT]>
I still believe that should wait for alpha 3.
<_zack>
well, your call, I just wanted to share the thought with you
<_zack>
no objection
<Yoric[DT]>
Rationale: I have uploaded the tarball for alpha 2 already :)
<_zack>
LOL
<thelema>
Yoric[DT]: :)
<_zack>
.oO( Yoric[DT] knows how to be convincing )
<flux>
thelema, I also want to know about the most recent events
<Yoric[DT]>
_zack: can you put this as a Task for Alpha 3?
<flux>
so although I could choose to trigger the histogram maintenance on-demand, I always need to have the results ready fast
<_zack>
Yoric[DT]: yup
<Yoric[DT]>
In the meantime, testing the GODI package.
<Yoric[DT]>
Which will take 15+ minutes, so I'l off to buy some dinner.
<Yoric[DT]>
So you in a bit.
<thelema>
flux: ? yes, pre-process over 1 week ago (or whatever timeframe is easy to count) and merge that with freshly counted new data.
<flux>
it's not that fast to gather the data even for a couple hours
madara has left #ocaml []
<flux>
(the histogram is per-hour)
<thelema>
ok, then preprocess every hour.
<flux>
that would be doable. however, I'm not sure what I'm winning here.
<thelema>
how many events are we talking about that it's slow to process a couple hours?
<thelema>
you win in per-query complexity = live response time
<flux>
thelema, do you refer to update queries?
<flux>
thelema, because select-queries are quite simple already
<thelema>
whatever triggers a histogram update
<flux>
well, you are correct that it would indeed speed it up, although it'd need to be benchmarked
<flux>
now that I think of it there shouldn't be more than a few thousand events per hour
<flux>
usually the per-hour values are requested for a 24-hour timespan at a time
<flux>
even if I were to siwtch to using a log, I'd probably write to it from a trigger ;)
<thelema>
heh.
<thelema>
don't many DBs make it easy to keep a transaction log?
<flux>
I'm using postgresql. I'd rather now rely on the text-based log for constructing that, though, so I would use a trigger to construct a log to a separate table.
<flux>
now->not
<thelema>
ok
<mfp>
flux: there's currently no support for outer joins in relational, since they deviate from the relational model
<mfp>
the type machinery required for such outer joins could be quite scary
<mfp>
Smerdyakov: typed relational algebra in OCaml using heavy camlp4 code generation, so I suppose you won't find it that interesting :)
Philonous has quit [Remote closed the connection]
<Smerdyakov>
Yes, you should use Ur instead. :)
<mfp>
I have a couple Qs about Ur, should I go to #ur?
<Smerdyakov>
Sure.
<mfp>
k
* mfp
switches
mbishop has quit [Read error: 131 (Connection reset by peer)]
mbishop has joined #ocaml
itewsh has quit [Remote closed the connection]
<Yoric[DT]>
Testing GODI package v4.
tomh has joined #ocaml
_JusSx_ has quit ["leaving"]
<Yoric[DT]>
flux: remind me, you're the author of this implementation of typed relational databases, aren't you?
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
<flux>
yoric[dt], I am not :)
<flux>
yoric[dt], mfp is
<flux>
mfp, hmm, that does seem to reduce its usefulness.. but is there a way to express set substraction in the relational model?
<mfp>
set union and set difference belong to the primitive operations in relational algebra
<mfp>
but SQL deviates from it :/
<flux>
and mapping those to sql is difficult?
<mfp>
flux, it should be possible to add some explicit OUTER_JOIN construct (as opposed to implicit joins with cartesian product + selection), but I fear it'd involve a fair amount of code generation
<mfp>
Have you seen the code it generates to enforce the correctness of the queries? It's quite ugh.
<flux>
:)
<flux>
I haven't taken a deep look. I've seen some quite long functions though.
<flux>
but, once you make it work, you don't need to touch it, right?-)
<mfp>
I essentially need to check that type 'a is a subtype of 'b, and do it by using polymorphic variants for 'a and 'b
<flux>
simply write the proof in coq and extract the solution? ..
<mfp>
then enforce this by generating functions extensively over the different constructors
<mfp>
with some type annotations
<mfp>
e.g. function `A -> 1 | `B -> 1 is [< `A | `B ] -> int; I can use that [< ] along with a type annotation to make sure the subtyping relation holds
<mfp>
yes, it should be easier to express directly with something more powerful than OCaml
<Smerdyakov>
I think I might know a candidate. ;)
<vixey>
is that before or after you implement subtyping and proof all the metatheory? :)
<Yoric[DT]>
flux, mfp: my bad :)
<Smerdyakov>
Yoric[DT], have you seen my Ur demo?
<Yoric[DT]>
mfp: just a quick absolutely-not-theoretical question.
<Yoric[DT]>
mfp: is it implemented as in-line syntax or as a quotation system?
<mfp>
inline
<Yoric[DT]>
Smerdyakov: looks interesting.
<mfp>
display_rel db (SELECT [User_age > (Some 18)] users)
sporkmonger has quit []
<Yoric[DT]>
mfp: I tend to believe that it would be more useful either as a quotation system or with some "switch" to turn it on.
<Yoric[DT]>
And I don't mean a command-line switch.
<Yoric[DT]>
Say [with SQL do display_rel db (SELECT [User_age > (Some 18)] users)].
<Yoric[DT]>
Don't you think?
<mfp>
hmm how is that better?
<Yoric[DT]>
Smerdyakov: quite interesting.
<mfp>
it allows you to use that keyword in another syntax extension,
<Yoric[DT]>
mfp: well, it's slightly less contagious.
tp76 has joined #ocaml
<mfp>
but I don't think too many others use such keywords
<Yoric[DT]>
It won't prevent you from using SELECT as a constructor or as a keyword from another extension.
<Yoric[DT]>
Well, it could be a module signature.
<Yoric[DT]>
That is, the name of a module signature.
<mfp>
true
<mfp>
the syntax extension is invasive in that regard
<Yoric[DT]>
Smerdyakov: how comes it doesn't use garbage-collection? Does it have regions or something such?
<Smerdyakov>
Yoric[DT], yes.
<Smerdyakov>
Yoric[DT], also, most values are stack- or register-allocated.
<Yoric[DT]>
Nice.
<Yoric[DT]>
I've been trying to implement regions for OCaml.
<Yoric[DT]>
I believe it's feasible (well, I have the beginning of a prototype on paper).
<Yoric[DT]>
But it's a pain.
<Smerdyakov>
There are some great tricks you can play with them in a pure language.
<Smerdyakov>
For instance, any expression of type [unit] can go in a region.
<Yoric[DT]>
The keyword being "pure" :)
<Smerdyakov>
And I guess I don't really mean "pure language," but just that effects are very restricted. Such expressions access SQL databases and write page output in Ur.
<Smerdyakov>
But neither of these leaves around persistent heap stuff.
<Yoric[DT]>
Interesting.
TypedLambda has left #ocaml []
<Yoric[DT]>
I like very much the idea of regions (well, as it turns out, I reinvented them a while ago in pi-calculus).
<Yoric[DT]>
Although making them transparent is certainly painful.
<Smerdyakov>
It's pretty easy for Ur/Web. Even just using one global region tends to work fine.
<Yoric[DT]>
_zack: for GODI, the detection of the directory for top.ml doesn't quite work.
<flux>
smerdyakov, how does the concept of applications servers fit into ur/web? all data persistence is via the SQL server?
<Smerdyakov>
flux, and cookies.
<Smerdyakov>
flux, and other mechanisms that may be added via the FFI.
<_zack>
Yoric[DT]: the alternative I've to propose is adding a --enable-godi argument for configure which explicitly request GODI-specific configuration
<Yoric[DT]>
The problem is that this doesn't integrate too nicely with the GODI installer.
<Yoric[DT]>
Or at least with godiva.
sporkmonger has joined #ocaml
<Yoric[DT]>
Mmmhhh....
<Yoric[DT]>
Actually, it could.
<_zack>
of that I know nothing, but I'd be surprised if the batteries GODI package can be told to pass a specific option to configure
<_zack>
s/can/can't/
<Yoric[DT]>
But I'll need to understand how GODI's conf-* packages work.
* Yoric[DT]
will return.
<_zack>
Yoric[DT]: ok, tell me if you want me to add the --enable-godi switch
* Yoric[DT]
has returned.
<Yoric[DT]>
_zack: well, we'll think about it for Alpha 3.
sporkmonger has quit [Client Quit]
<flux>
mfp, is there a way to do SELECT CURRVAL('foo_foo_seq')?
<mfp>
nope; I'd thought of allowing arbitrary (textual) SQL expressions along with a sort of "witness" (indicating the tables + columns it refers to, etc.) to ensure there are no silent breaks as the schema changes
<flux>
mfp, do you have hope that the currently employed model (with static checking) will work even after all sort of useful features are hacked in?-)
<mfp>
I think the language will necessarily remain relatively restricted; the "witness" approach would give the flexibility needed for the corner cases
<mfp>
the outer joins, etc. sound doable (albeit hard, maybe)
<mfp>
but to be honest I'm not planning to spend time on this for now
<flux>
I have one toy project to play with, perhaps I will find some time to implement stuff I need for that
<Smerdyakov>
mfp, do you work with OCaml for a living?
<mfp>
the type-safe option that gives the most flexibility is PG'OCaml
<flux>
it doesn't give the capability to build queries
<mfp>
Smerdyakov: I'm developing stuff in OCaml that will hopefully pay bills in the future
mishok13 has quit [Read error: 110 (Connection timed out)]
<flux>
I might be heavily tempted to switch to a runtime-checked model at some point, but my library has 0 syntax candy so it can get quite tiresome to use it
<Smerdyakov>
mfp, what about ATM?
<mfp>
atm., it doesn't :)
<flux>
good night
<mfp>
good idea :)
jlouis has joined #ocaml
<Kerris4>
why is recursion explicit in OCaml?
<Kerris4>
as in, why is "let rec" required for a function that calls itself?
<Kerris4>
namespace issue?
<Smerdyakov>
I often write code like [let n = n + 1 in ...].
kig has quit [Read error: 110 (Connection timed out)]
det has joined #ocaml
<_zack>
Yoric[DT]: I'm adding to the "candidate for inclusion" tracker the libraries listed in the doc
apples` has quit ["Leaving"]
bzren has quit []
marmotine has quit ["mv marmotine Laurie"]
jeddhaberstro has joined #ocaml
rogo has joined #ocaml
velco has quit ["Ex-Chat"]
<Yoric[DT]>
_zack: ok
thelema has quit [Read error: 60 (Operation timed out)]
_zack has quit ["Leaving."]
ygrek has quit [Remote closed the connection]
<Kerris4>
comprehension not included in OCaml by default? :<
<Yoric[DT]>
Nope.
<Yoric[DT]>
There's a little list comprehension as a Camlp4 module provided with OCaml.
<Yoric[DT]>
And we'll add much more stuff with Batteries Alpha 3.
<Kerris4>
I'll be getting my Apple machine in two weeks, but for now I'm stuck with someone's Windows machine
<Kerris4>
don't want to mess with it too much
* Yoric[DT]
sympathizes.
* Camarade_Tux
sympathizes too
<Kerris4>
I can get by for the time being by writing OCaml on/in F#, my tutor has been hinting rather strongly that I should look into F#
<Camarade_Tux>
which shows we still need complete ocaml packages for windows
<Camarade_Tux>
and reminds me I should finish that ocaml livecd, especially since it's nearly complete (at last !)
<vixey>
Kerris4: yuck, F# sucks
<Kerris4>
vixey: I'm new to both, don't know much about their respective pros and cons.
<vixey>
Kerris4: I'm just extremely biased without any real investigation or argument
<vixey>
Kerris4: I don't like that it's very similar to ocaml .. but now I wonder, would there be legal problems with them writing a new ocaml compiler or something?