pyon has quit [Read error: Connection reset by peer]
dotfelix has joined #ocaml
thomasga has joined #ocaml
fraggle_ has quit [Remote host closed the connection]
ollehar has quit [Ping timeout: 252 seconds]
fraggle_ has joined #ocaml
tlockney_away is now known as tlockney
thomasga has quit [Quit: Leaving.]
struktured has joined #ocaml
studybot has quit [Read error: Connection reset by peer]
nikki93 has quit [Remote host closed the connection]
dotfelix has quit [Quit: Leaving...]
nikki93_ has joined #ocaml
malo has quit [Quit: Leaving]
angerman_ has quit [Ping timeout: 265 seconds]
angerman has joined #ocaml
q66 has quit [Quit: Leaving]
zpe has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
studybot has joined #ocaml
struktured has quit [Ping timeout: 240 seconds]
fraggle_laptop has quit [Remote host closed the connection]
studybot has quit [Remote host closed the connection]
thomasga has joined #ocaml
thomasga has quit [Ping timeout: 250 seconds]
studybot_ has joined #ocaml
clog has joined #ocaml
zpe has joined #ocaml
philtor has joined #ocaml
zpe has quit [Ping timeout: 265 seconds]
angerman has quit [Quit: Gone]
yacks has joined #ocaml
tlockney is now known as tlockney_away
axiles has joined #ocaml
thomasga has joined #ocaml
thomasga has quit [Ping timeout: 255 seconds]
shinnya has quit [Ping timeout: 246 seconds]
shinnya has joined #ocaml
angerman has joined #ocaml
ygrek has joined #ocaml
nikki93 has quit []
zpe has joined #ocaml
shinnya has quit [Remote host closed the connection]
zpe has quit [Ping timeout: 250 seconds]
racycl___ has quit [Quit: ZZZzzz…]
philtor has quit [Ping timeout: 240 seconds]
nikki93 has joined #ocaml
araujo has quit [Ping timeout: 252 seconds]
Kakadu has joined #ocaml
WraithM has joined #ocaml
araujo has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
Simn has joined #ocaml
zpe has joined #ocaml
zpe has quit [Ping timeout: 250 seconds]
manizzle has joined #ocaml
siddharthv is now known as siddharthv_away
WraithM has quit [Ping timeout: 240 seconds]
bunzen has quit [Ping timeout: 245 seconds]
avsm has joined #ocaml
zpe has joined #ocaml
bunzen has joined #ocaml
dotfelix has joined #ocaml
avsm has quit [Quit: Leaving.]
dotfelix has quit [Client Quit]
bunzen has quit [Ping timeout: 250 seconds]
bunzen has joined #ocaml
dotfelix has joined #ocaml
ddosia1 has joined #ocaml
siddharthv_away is now known as siddharthv
Arsenik has joined #ocaml
avsm has joined #ocaml
ggole has joined #ocaml
fraggle_ has quit [Ping timeout: 265 seconds]
dotfelix has quit [Quit: Leaving...]
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
avsm has quit [Client Quit]
fraggle_ has joined #ocaml
eizo has joined #ocaml
fraggle_ has quit [Ping timeout: 252 seconds]
S1100100` has joined #ocaml
srcerer_ has joined #ocaml
Sim_n has joined #ocaml
mrvn_ has joined #ocaml
ygrek_ has joined #ocaml
lopex has quit [Ping timeout: 265 seconds]
LU324_ has joined #ocaml
skchrko_ has joined #ocaml
teiresias has quit [Ping timeout: 265 seconds]
__marius___ has quit [Ping timeout: 265 seconds]
srcerer has quit [Ping timeout: 265 seconds]
alex_nx has quit [Ping timeout: 265 seconds]
ygrek has quit [Ping timeout: 265 seconds]
mrvn has quit [Ping timeout: 265 seconds]
Simn has quit [Ping timeout: 265 seconds]
adrien_o1w has joined #ocaml
bacam_ has joined #ocaml
dnm has quit []
patronus has joined #ocaml
ninegrid_ has joined #ocaml
alex_nx has joined #ocaml
ikaros has joined #ocaml
rand000 has joined #ocaml
meteo has joined #ocaml
meteo is now known as Guest57376
maufred_ has joined #ocaml
diginux_ has joined #ocaml
mbac_ has joined #ocaml
gustav__ has joined #ocaml
rsnous has joined #ocaml
lopex has joined #ocaml
__marius____ has joined #ocaml
squiggnet_ has joined #ocaml
asmanur_ has joined #ocaml
amiller- has joined #ocaml
teiresias has joined #ocaml
shalicke_ has joined #ocaml
kerneis has quit [Quit: leaving]
S1100100` has quit [*.net *.split]
araujo has quit [*.net *.split]
wwilly has quit [*.net *.split]
squiggnet has quit [*.net *.split]
penryu has quit [*.net *.split]
zarul has quit [*.net *.split]
keen______ has quit [*.net *.split]
maufred has quit [*.net *.split]
mfp has quit [*.net *.split]
Averell has quit [*.net *.split]
asmanur has quit [*.net *.split]
gustav_ has quit [*.net *.split]
nicoo has quit [*.net *.split]
mbac has quit [*.net *.split]
osnr has quit [*.net *.split]
shalicke has quit [*.net *.split]
diginux has quit [*.net *.split]
zebr has quit [*.net *.split]
shalicke_ is now known as shalicke
kerneis has joined #ocaml
skchrko has quit [*.net *.split]
S11001001 has quit [*.net *.split]
ninegrid has quit [*.net *.split]
adrien_oww has quit [*.net *.split]
bacam has quit [*.net *.split]
patronus_ has quit [*.net *.split]
LU324 has quit [*.net *.split]
Guest12333 has quit [*.net *.split]
amiller has quit [*.net *.split]
tane has joined #ocaml
jonludlam_afk is now known as jonludlam
ollehar has joined #ocaml
vpm has quit [Ping timeout: 252 seconds]
nicoo has joined #ocaml
mrvn_ is now known as mrvn
angerman has quit [Remote host closed the connection]
wwilly has joined #ocaml
michael_lee has joined #ocaml
angerman has joined #ocaml
zarul has joined #ocaml
zarul has quit [Changing host]
zarul has joined #ocaml
mfp has joined #ocaml
zebr has joined #ocaml
Averell- has joined #ocaml
penryu has joined #ocaml
keen______ has joined #ocaml
Averell- has quit [Max SendQ exceeded]
maattdd__ has joined #ocaml
araujo has joined #ocaml
Averell- has joined #ocaml
Thooms has joined #ocaml
Nahra has quit [Ping timeout: 252 seconds]
thomasga has joined #ocaml
Sim_n is now known as Simn
maattdd__ has quit [Ping timeout: 245 seconds]
bacam_ is now known as bacam
Thooms has quit [Ping timeout: 245 seconds]
Nahra has joined #ocaml
Nahra has quit [Remote host closed the connection]
divyanshu has joined #ocaml
Nahra has joined #ocaml
Nahra has quit [Remote host closed the connection]
dsheets has joined #ocaml
contempt has quit [Remote host closed the connection]
Thooms has joined #ocaml
thomasga has quit [Quit: Leaving.]
contempt has joined #ocaml
cdidd has quit [Remote host closed the connection]
nikki93 has quit [Remote host closed the connection]
cdidd has joined #ocaml
nikki93 has joined #ocaml
thomasga has joined #ocaml
Thooms has quit [Ping timeout: 250 seconds]
thomasga has quit [Client Quit]
thomasga has joined #ocaml
thomasga has quit [Ping timeout: 276 seconds]
Hannibal_Smith has joined #ocaml
Thooms has joined #ocaml
Thooms has quit [Client Quit]
nikki93 has quit [Remote host closed the connection]
thomasga has joined #ocaml
thomasga has quit [Ping timeout: 252 seconds]
studybot_ has quit [Remote host closed the connection]
nikki93 has joined #ocaml
bindump has joined #ocaml
gasche has quit [Ping timeout: 252 seconds]
thomasga has joined #ocaml
nikki93 has quit [Ping timeout: 245 seconds]
thomasga has quit [Ping timeout: 240 seconds]
rand000 has quit [Ping timeout: 246 seconds]
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
bindump has quit [Quit: Page closed]
thomasga has joined #ocaml
ollehar has quit [Ping timeout: 252 seconds]
Thooms has joined #ocaml
ollehar has joined #ocaml
nikki93 has joined #ocaml
contempt has quit [Read error: Connection reset by peer]
thomasga has quit [Ping timeout: 245 seconds]
nikki93 has quit [Ping timeout: 276 seconds]
contempt has joined #ocaml
tane has quit [Quit: Verlassend]
thomasga has joined #ocaml
Hannibal_Smith has quit [Quit: Sto andando via]
yacks has quit [Ping timeout: 245 seconds]
studybot_ has joined #ocaml
yacks has joined #ocaml
studybo__ has joined #ocaml
_andre has joined #ocaml
studybot_ has quit [Ping timeout: 240 seconds]
ygrek_ has quit [Ping timeout: 276 seconds]
thomasga has quit [Quit: Leaving.]
zpe has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
siddharthv is now known as siddharthv_away
contempt has quit [Remote host closed the connection]
nikki93 has joined #ocaml
contempt has joined #ocaml
Guest57376 has quit [Quit: Leaving]
nikki93 has quit [Ping timeout: 252 seconds]
contempt has quit [Read error: Connection reset by peer]
contempt has joined #ocaml
ZenoArrow has joined #ocaml
yacks has quit [Ping timeout: 276 seconds]
thomasga has joined #ocaml
<ZenoArrow>
Hola amigos. I was looking to start building a website, using Ocaml on the server side, do you have any hosting recommendations?
<mrvn>
mirage uses mirage
<companion_cube>
it's on amazon e3, isn't it?
<companion_cube>
or s3
thomasga has quit [Client Quit]
<whitequark>
aws
nikki93 has joined #ocaml
<ZenoArrow>
mirage or aws, I see.
<adrien>
ocsigen too
nikki93 has quit [Ping timeout: 276 seconds]
<whitequark>
I mean, mirage runs on aws
<ZenoArrow>
My plan was to find a host that could run Ocsigen Server, but Mirage looks interesting too.
malc_ has joined #ocaml
<ZenoArrow>
I had considered Microsoft BizSpark because it's free (sort of), and I think RedHat OpenStack might have a free tier as well.
<ZenoArrow>
Are there any performance figures for Mirage?
vpm has joined #ocaml
<mrvn>
you think you will overload it?
<companion_cube>
ZenoArrow: the paper that introduces mirage shows very high performance
<companion_cube>
but then I don't know how hard it is to build a complex website on top of mirage
<NoNNaN>
companion_cube: is mirage considered production ready ?
<companion_cube>
I don't know, ask Anil
<companion_cube>
there are also people related to ocsigen here
<ZenoArrow>
For what I was planning, Mirage just needs to handle the web server requests and integrate with a SQL DB. Was planning on using Varnish as a front end cache, something like jingoo for HTML templates, and Postgres for the DB.
<mrvn>
ZenoArrow: it has sqlite
<ZenoArrow>
mrvn: That's okay, I can connect to Postgres using a different Ocaml library/
<ZenoArrow>
Very interested in Mirage now. Reading through what I can do with it.
<flux>
you probably need a native postgresql interfacing library (pgocaml is one)
<mrvn>
might need some patching to work with mirages tcp stack.
<flux>
what, doesn't everyone write modules that have functorized the tcp stack ;-)
<mrvn>
And then you have one VM for the cache, one VM for mirage and one VM for postgresql. Does it realy make sense then?
<flux>
it might
<flux>
VMs are the new applications
<mrvn>
For mirage they plan to run 10000 VMs on a host.
<flux>
I believe VMs exist only because operating systems suck at virtualizing
<NoNNaN>
not in virtualization, isolation
<flux>
well, yes
<NoNNaN>
and separation
<mrvn>
In the begining we had hardware task switching, then we went to software and now we go back to hardware VM switching.
<mrvn>
the circle closes
<def-lkb>
… or we try to get around ill-designed abstractions
<flux>
"I want george to have his own network interface.. Better give him the whole machine."
<whitequark>
mrvn: when did we go to software task switching?
thomasga has joined #ocaml
<mrvn>
flux: that's what we have cgroups for in linux
angerman_ has joined #ocaml
<mrvn>
whitequark: a long time ago. hardware task switching on x86 is slower than in software.
<whitequark>
mrvn: ah, you mean that
<flux>
mrvn, cgroups are quite a recent feature
malc_ has left #ocaml []
<mrvn>
flux: yes they are
nikki93 has joined #ocaml
<whitequark>
mrvn: I wonder if VM switching is done in the same way
<flux>
how about "I want george to be able to test drivers on that particular PCI-card without" ;-)
<whitequark>
(not sure how hypercall interface looks like internally)
jonludlam is now known as jonludlam_afk
<flux>
but I suppose it's all matter of implementing cgroup support Everywhere
<ZenoArrow>
Docker's getting quite popular now, that's based on lxc containers, wonder how they handle resource sharing.
<whitequark>
ZenoArrow: they don't afaik
<flux>
hmm, or not. it doesn't really have a way to allow people loading isolated drivers.
<flux>
go go hurd!
<mrvn>
whitequark: totaly different
<whitequark>
ew, microkernels
<ZenoArrow>
whitequark: Ah, right.
angerman has quit [Ping timeout: 240 seconds]
<flux>
whitequark, what's ew about them? other than slightly lower performance and difficulties in development.
<whitequark>
you don't need microkernels if you have a memory-safe language with sane communication primitives.
<flux>
how big of a hack is FUSE and with what performance?
<whitequark>
e.g. rust
<mrvn>
flux: microkerneles don't have to be slow.
<whitequark>
flux: FUSE is HORRIBLE.
<flux>
whitequark, and FUSE is what we get without microkernels :)
<mrvn>
flux: fuse isn't that much of a hack and quite fast and getting faszer
<whitequark>
it's a disaster. nothing with FUSE ever works properly.
<mrvn>
whitequark: oh come on. works just fine
<whitequark>
even without considering the fact that all remote FS emulation through fuse leaks ridiculously bad
<flux>
well, it's a lot better than it used to be
jonludlam_afk is now known as jonludlam
<flux>
and sshfs is quite nice
<whitequark>
mrvn: use sshfs on public wifi or something
<mrvn>
whitequark: so?
<whitequark>
or even mount something on the other side of planet
<whitequark>
^S → my editor is hung for [1 second; +inf]
<NoNNaN>
ssh connection fails at modest packet loss
studybo__ is now known as studybot
<mrvn>
going around the world is slow. Not a problem of fuse.
<flux>
whitequark, I doublt fuse is at fault there.
<NoNNaN>
if you have unreliable connection, you'll better of using a channel that have error correction
<whitequark>
it is a problem of people retrofitting fs interface over things which cannot and should not be exported with an fs interface
<mrvn>
sftp protocol is also bad for this.
<whitequark>
and fuse enables that
<whitequark>
in fact, fuse is used almost exclusively for that
<flux>
whitequark, yet why did you want to use it?
<mrvn>
whitequark: you used it. you are one of those people
<flux>
it's the same problem with nfs
<flux>
and nfs is darn convenient
<NoNNaN>
whitequark: take a look at plan9, everything is a file..
<whitequark>
it is also used to write shitty userspace drivers instead of good kernelspace ones by lowering input barrier, e.g. the mtp driver on linux is implemented in python, and it doesn't work, and you can't get your files off your Android phone.
<whitequark>
flux: mrvn: nfs should be killed as well.
<mrvn>
And the fact that you can use sshfs around the world just shows how good fuse is.
<def-lkb>
NoNNaN: the problem is FUSE-fs are expected to stick to some loose interpretation of posix semantics
steshaw has quit [Quit: Connection closed for inactivity]
<def-lkb>
plan9 can get around that
<flux>
whitequark, fine. so how should I manage files on my file server? always log in via ssh and do the stuff? use a custom application for it?
<mrvn>
def-lkb: fuse FS are supposed to stick to the linux VFS semantic.
<whitequark>
flux: rsync
<flux>
rsync can do hard links?
<def-lkb>
mrvn: what about BSDs fuse?
<mrvn>
flux: yes
<flux>
rsync can do cp --reflink=always?
<mrvn>
def-lkb: BSD semantic. which I think is the same.
<NoNNaN>
rsync is far from optimal for large (100GB+) files..
<flux>
how about replacing a find .. | xargs -pipeline with rsync
<whitequark>
NoNNaN: sshfs isn't exactly optimal for 100GB+ files either
<mrvn>
NoNNaN: why?
<whitequark>
unless you have a 10GE network and the server is five meters from you
<flux>
I've used mplayer over sshfs just fine
<NoNNaN>
whitequark: ssh is just a transport channel
<flux>
maybe not 100G files, but still quite large
<mrvn>
whitequark: sshfs doesn't care about file size.
<def-lkb>
I use mplayer over sshfs every day
<whitequark>
flux: I'm not complaining about sshfs, nfs and the like because I'm a purist. I'm complaining because I've tried to use them for years and it's painful enough I stopped using them whatsoever
<NoNNaN>
mrvn: due the small block sizes, it convert your seq io to random io
<def-lkb>
just pass a reasonable -cache value
<flux>
sometimes I sshfs to my home computer to access some CAD files
<companion_cube>
I'd rather use sftp
<flux>
instead the better option is to rsync everything? or maybe open the cad file, determine its dependencies, copy them one-by-one to local host and then run the cad?
nikki93 has quit [Ping timeout: 250 seconds]
<mrvn>
NoNNaN: 1) No it doesn't, 2) only where it saves bandwith, 3) blocksize is configurable with -B
<whitequark>
mrvn: true, but the fact that you probably use sshfs over network and software doesn't in general expect FS to be accessed over the network is what's the problem here.
<flux>
(the dependency-resolving-step is recursive)
<mrvn>
whitequark: no. That is totaly transparent.
<flux>
file systems can fail just as well as can network file systems
<whitequark>
network is always unreliable. local FS is always reliable (unless your disk fails, in which case it breaks just as horribly)
<mrvn>
whitequark: it's the same as using a slow USB stick.
<flux>
mrvn, you shouldn't do that
<flux>
mrvn, instead, simply dd the image first to a hard drive
<whitequark>
software is not prepared for a filesystem taking any more than a few ms to respond.
<flux>
preferably tmpfs
<flux>
then mount the image via loopback
<flux>
once you're done, you can rsync the image back to the usb stick
<mrvn>
whitequark: bollocks
<whitequark>
load a file into your favorite editor via nfs, pull out the plug, try to save it.
<flux>
well I think I would agree on that statement in general, for software that cares about latencies (=few)
<companion_cube>
I guess that if you write every IO with Lwt, your software should be relatively resilient to slow FS
<whitequark>
then try to recover from that without rebooting your (linux) system.
<mrvn>
whitequark: load a file into an editor and smash your keyboard into the monitor. Try to edit it.
<NoNNaN>
mrvn: actially, it does, check it yourself with strace/ltrace, and does not allow large (multible MB) blocksize...
<flux>
whitequark, umount -l (for lazy) isnice
<whitequark>
flux: doesn't work
<adrien>
14:58 whitequark : load a file into your favorite editor via nfs, pull out the plug, try to save it.
<adrien>
that's not about I/O per se
<whitequark>
mrvn: unlike what you're suggesting, nfs server failing is an incredibly common thing
<adrien>
it's because the system call is stuck
<whitequark>
for example, I just recently tried to use nfs over wifi
<mrvn>
NoNNaN: anything above 64k becomes slower in my experience.
<whitequark>
it doesn't fucking work
<adrien>
and userspace does not mess with kernel space
<flux>
there is also the intr-option
<whitequark>
your neighbor starts to download GoT or something, and your nfs server is gone, and the only thing that works is reboot
<adrien>
whitequark: nfsv4 with tcp?
<whitequark>
flux: doesn't work.
<whitequark>
adrien: I think nfsv3
<adrien>
well, try with nfsv4 and tcp :P
<adrien>
(and have fun with kerberos)
<flux>
well, nfs fails for me so rarely that I don't really need to use those
<mrvn>
whitequark: the only reason why my nfs server would fail is when some hardware dies. Same as a local filesystem.
<whitequark>
adrien: right, that's the reason I didn't use nfsv4--never figured out how to do kerberos auth
<whitequark>
mrvn: key word: "your". it might work for your particular use case. it's not a solution which works for a myriad more use cases, just as common.
<mrvn>
whitequark: and with NFS you can do a failover and use a backup server instead of the broken one. So it even more reliable than a local fs.
<flux>
I would agree that I would probably not choose to use nfs over a mobile network. though, I've done it at times.
<mrvn>
whitequark: it all depends on how you use it. Just like you can shoot yourself with a gun.
<mrvn>
flux: over wifi you realy want to use sshfs instead. nsf isn't encrypted at all.
<flux>
mrvn, well over vpn of course
<whitequark>
wifi is encrypted itself
<NoNNaN>
mrvn: the optimal block size is depend on storage type and network bandwidth and latency, try use it on 10+ disk storage (GB/sec seq bandwidth, but a few KB/sec random bandwidth) and gigabit network
<flux>
otherwise it's a firewalling nightmare
<whitequark>
well, a private one
<flux>
but I meant that the actual transport itself is a relatively unreliable mobile phone network
<mrvn>
NoNNaN: yes. I did. and anything aboce 64k blocks doesn't improve performance on the FS.
<whitequark>
mrvn: exactly, and what I'm saying is that nfs is not a solution for accessing some files on another machine you have
<whitequark>
it's a solution for a corporate network over ethernet when someone else set up two blades with failover
<flux>
whitequark, but the purpose is not simply 'accessing' said files but letting a program access them
<mrvn>
NoNNaN: one assumption in rsync is that you have fast disks and slow networking. So doing it between 2 servers with 40MB/s infiniband interconnect might not be the best use case.
<flux>
and programs typically deal only with filesystems
<whitequark>
flux: sure, that's what I meant
ollehar1 has joined #ocaml
<mrvn>
whitequark: The problem with NFS is that, despite how terrible it is, it works TOO well.
<whitequark>
the perfect way of sharing files across several machines is something like dropbox, i.e. a program which watches over your *local* copy and synchronizes it somehow
<whitequark>
(dropbox itself is a nightmare for several other reasons, including but not limited to: privacy, no conflict resolution, randomly disappearing files, etc)
<flux>
there are some clustering filesystems that work on the same premises
<flux>
not nice when you have huge files
<whitequark>
yes, you better be able to say "don't synchronize this right now"
<whitequark>
but this deals with pretty much all the other problems of nfs/sshfs/etc. it doesn't matter how good your network is, at all
<flux>
you could implement exactly the same via the file system interface, no?
<whitequark>
hm?
<flux>
you save in 'vi', if network is down it only stores to a pending synchronization copy
<mrvn>
whitequark: that emidiatly runs into a split brain situation. unaceptable.
<flux>
of course, eventually you get to resolve synchornization conflicts
<mrvn>
flux: in fuse you can do that
<whitequark>
mrvn: yeah, it's better to lock up anything that opened the files in a way that you can't even kill the processes without rebooting
<whitequark>
solving split brains is hard, let's go shopping^W^Whang itself
<whitequark>
flux: in theory that sounds well, there's a program out there which does this (iirc, spideroak)
<flux>
don't fuse-mounts usually stop IO when you kill the corresponding fuse process?
<mrvn>
whitequark: if you configure it to block till it has saved the data then you get that behaviour. You can also configure it so you can kill the app and loose your data. That is your choice.
<whitequark>
flux: last message applies to nfs
<mrvn>
whitequark: Don't complain when you shoot yourself in the foot with your own gun.
<whitequark>
mrvn: what I'm saying is that neither of your options are acceptable
<whitequark>
a program must *never* hang on filesystem IO, period.
<mrvn>
whitequark: then don't use nfs. It's not git.
<flux>
well, it could simply return an error to the program if the connection is down
<whitequark>
if something you did makes it hang, what you did is broken
<flux>
file system IO interface can provide errors just fine.
<mrvn>
flux: it does with -o soft
<mrvn>
whitequark: and all filesystem IO hangs.
divyanshu has quit [Quit: Computer has gone to sleep.]
<flux>
mrvn, I think you need to drop down the timeouts a bit with that as well to work nicely in whitequark's scenario?
nikki93 has joined #ocaml
<flux>
and perhaps consider failure in a bigger picture than just a single IO operation
<mrvn>
whitequark: 99.9% of software would break if filesystem IO wouldn't hang despite POSIX totaly alowing for that.
<flux>
that is, have 'we are in failure' mode
<whitequark>
flux: continuing about spideroak. it uses FUSE. in theory that works well, but if you try to store e.g. configs there, you run into initialization order problems which are just as nasty. I'm convinced you must use a local checkout instead.
<whitequark>
mrvn: hangs for unbounded time, I mean.
<whitequark>
mrvn: local FS IO can hang for unbounded time if your hardware is broken. that's lots of orders of magnitude more rare than network failures.
<mrvn>
whitequark: local FS IO can hang for unbounded time if your local FS is busy.
tnguyen has joined #ocaml
<flux>
whitequark, is it fuse's or shiperoak's fault?
<whitequark>
mrvn: still insignificant compared to network failures
<mrvn>
whitequark: what you want is an FS with offline support. so use one.
<whitequark>
flux: fuse's; you need to load something before you get access to your files, and thus you run into race conditions on startup.
<flux>
you can have multiple local file systems, some can fail while others don't
<mrvn>
whitequark: It's like take an apple and complain that it isn't orangy enough.
<flux>
seems to me it's pretty catastrophic as well. but I grant you that network errors are typically more likely.
<whitequark>
mrvn: well, you were claiming that it's orangy enough for you :p
<flux>
I'm considering running cephfs at home (mostly due to curiosity)
<mrvn>
whitequark: yes. It does what I want it to do. If I want something else then I pick a different filesystem.
<flux>
I suppose I'm not locked to the file system interface, though, as cephfs is only a layer on the distributed object storage
<flux>
but the filesystem interface really seems the most convenient for using it!
<mrvn>
whitequark: I don't claim NFS is shit just because it doesn't do what it never was designed for and never promised to do.
ygrek_ has joined #ocaml
nikki93 has quit [Ping timeout: 240 seconds]
<flux>
if other interfaces were as convenient or even more convenient, why do we even have local file systems? just have an app for everything..
ZenoArrow has quit [Ping timeout: 240 seconds]
<whitequark>
another thing that works really poor is the FUSE helper for amazon s3... amazon has horrible latencies. I don't understand why it even was written, it's unusable.
<mrvn>
flux: in a microkernel a FS is just a service like any other
contempt has quit [Remote host closed the connection]
<mrvn>
whitequark: is that FUSEs fault that amazon is slow?
<flux>
mrvn, yes. I actually originally mentioned microkernels and then mentioned fuse :)
<mrvn>
whitequark: Hey, I have this great sports car. But it total crap. When I put water in the tank it doesn't run at all.
<flux>
maybe the fuse interface suggests that the client must request for things like access date when doing ls -l
<flux>
and doing that individually for objects in the s3 storage might be slow
<flux>
might be that the fuse s3 app is doing that inefficiently
<whitequark>
mrvn: what I'm saying is, I have never seen a FUSE adapter that works well. literally none of those I have tried. then, however perfect the implementation of FUSE could be, it's still crap as a concept: the things it enables aren't worth doing.
<flux>
(the previous is my topmost guess)
<mrvn>
flux: fuse now has readdirplus, like nfs.
<flux>
I think most often people do stuff with fuse that solves their problem
<flux>
and then stop :)
<mrvn>
and then whitequark comes and uses it totaly different and complains.
<whitequark>
FUSE adapters probably work well in a perfect world where WiFi doesn't have collisions, networks don't timeout and servers respond instantaneously.
yacks has joined #ocaml
<whitequark>
for anything else, the abstraction breaks miserably.
<mrvn>
whitequark: not at all. it still works just as promised.
<mrvn>
whitequark: if your wifi is broken then blame your wifi. not fuse.
nikki93 has joined #ocaml
<adrien>
fuse is very often used for local accesses (single machine)
<whitequark>
networks are always broken, by design.
ygrek_ has quit [Client Quit]
<mrvn>
and a proper network filesystem knows that and reconnects and retries.
<whitequark>
I don't care if the spikes on the handle are done exactly to their specifications, I care that my hand bleeds
<whitequark>
and the networks here are even quite good, I don't want to know what folks on satellite links feel
<kerneis>
well networks everywhere are killed by bufferbloat
<mrvn>
They feel nothing. works just fine.
<mrvn>
probably better than the laser link with the tree growing into the line.
tnguyen has quit [Quit: tnguyen]
<flux>
the conclusion here is: we should write a new asynchronous error-tolerant/error-reporting data access interface in ocaml and rewrite the apps of the worls to use it.
<flux>
you can start now, I'll monitor progress :)
<mrvn>
flux: with offline support and all knwoing AI to resolve split brain problems.
<whitequark>
flux: I am, though it uses a local checkpoint to avoid rewriting apps of the world.
nikki93 has quit [Ping timeout: 245 seconds]
<whitequark>
I don't tend to rant without applying at least some effort to solving the problem ;)
<whitequark>
*local checkout
divyanshu has joined #ocaml
<mrvn>
I wonder what github would say if I would trop 16TB into a git repository in 1MB chunks.
<whitequark>
they cap the size of repos at, I think, 200M by default
<whitequark>
it's a soft limit; you can mail them and they'll raise it. But not to 16TB, I'm sure
<flux>
hmm, git would work fine as a Venti storage backend
<whitequark>
git sucks at storing huge files.
<whitequark>
especially often updated ones
<NoNNaN>
mrvn: no problem, github will send a hefty invoice for the service
<flux>
someone(TM) should write an interface for storing files that can make use of all the freely available systems able to store information
contempt has joined #ocaml
<flux>
with desired redundancy level
<flux>
and then you could.. tadah :) write a fuse file system adapter for it!
* whitequark
slowly turns red
whitequark is now known as redquark
<adrien>
:D
<mrvn>
flux: including youtube videos and picpaste services?
<flux>
mrvn, sure, why not
<flux>
bonus points if the data is always readable unless encrypted
<flux>
so videos of text file should actually be frames containing the text!
<mrvn>
flux: too obvious. take videos of cute cats and encrypt the data in subchannels
<mrvn>
wait, someone already did that
<flux>
mrvn, that could be the steganography-mode
<redquark>
the bitrate is ridiculously low, even worse if you want to remain not easily detectable
<flux>
probably ten years ago, while still studying at uni, I was thinking of a ssh-based storage system
<redquark>
you'd need gigabytes of cat videos to encode megabytes of data
<flux>
actually I even started writing it a bit, probably in c++ so obviously I never finished it
<redquark>
well, it's not like we're short on cat videos.
redquark is now known as whitequark
<mrvn>
redquark: there are terrabytes of cat videos.
<flux>
the point was that I would be able to give it ssh hosts and it would copy itself (the server part) to the host and start itself as a content server
<flux>
and then I would have a single image view of all the content at home
<whitequark>
flux: just make it autodiscover ssh hosts
<flux>
some sort of redundancy scheme was also in my mind
<whitequark>
e.g. those with weak root passwords...
<flux>
but nowadays I have sufficient storage so it doesn't seem that useful :)
<flux>
I also thought that the server could remove itself after the session detaches and the data could be encrypted
nikki93 has joined #ocaml
lostcuaz has joined #ocaml
<whitequark>
what's the difference between extlib and extlib-compat?
lostcuaz_ has joined #ocaml
lostcuaz_ has quit [Read error: Connection reset by peer]
divyanshu has quit [Quit: Computer has gone to sleep.]
nikki93 has quit [Ping timeout: 252 seconds]
rgrinberg has quit [Ping timeout: 250 seconds]
Hannibal_Smith has joined #ocaml
<topher>
Hello, I'm new to ocaml and I was wondering if this was a good place to ask questions of that nature?
<whitequark>
sure
<mrvn>
why don't you ask your questions and judge the answeres yourself?
S11001001 has joined #ocaml
S11001001 has quit [Changing host]
S11001001 has joined #ocaml
<topher>
I was more concerned with this being an appropriate place to pose those types of questions rather than the type of response I'd receive
<whitequark>
just ask :)
<whitequark>
we'll tell you if the questions are inappropriate.
<companion_cube>
well it's a good place to ask whether it's a good place to ask whether it's a good place...
<ygrek>
yeah, and the question so far lead to what conclusion?
rgrinberg has joined #ocaml
<companion_cube>
it's a coconclusion
<ygrek>
it is probably not the best place to ask whether it is a best place etc
rgrinberg has quit [Client Quit]
nikki93 has joined #ocaml
tlockney_away is now known as tlockney
nikki93 has quit [Ping timeout: 240 seconds]
olauzon has joined #ocaml
yacks has quit [Ping timeout: 240 seconds]
nikki93 has joined #ocaml
Thooms has quit [Read error: Connection reset by peer]
topher has left #ocaml []
Thooms has joined #ocaml
nikki93 has quit [Ping timeout: 240 seconds]
nikki93 has joined #ocaml
nikki93 has quit [Ping timeout: 252 seconds]
jonludlam is now known as jonludlam_afk
rand000 has joined #ocaml
Thooms has quit [Quit: WeeChat 0.3.8]
nikki93 has joined #ocaml
nikki93 has quit [Ping timeout: 240 seconds]
passiveobserver has quit [Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!]
<_obad_>
"Bytes are represented by the OCaml type [char]" O_O
passiveobserver has joined #ocaml
<_obad_>
at least they should provide a "byte" alias as a path to unicode imho
Enjolras has joined #ocaml
Averell- has quit [Quit: .]
averell has joined #ocaml
<whitequark>
I think char will always represent a byte, it would cause too much breakage otherwise
<whitequark>
upgrading languages to support unicode is a horrible, horrible problem
averell is now known as Averell
<ggole>
Breaking pervasive assumptions is a hell of a thing to do, yeah
<ggole>
And of course unicode is a mess as well
<def-lkb>
yes, enough to be handled at the library level, not inside the langage
<whitequark>
I disagree, Unicode should be the one and only string type in a language, and UTF-8 the only representation
<ggole>
How'd it work out last time something was the one true string type?
nikki93 has joined #ocaml
<whitequark>
ggole: there never was before
<ggole>
ascii was for a lot of people
<whitequark>
even more people used shift-jis at the same time
<whitequark>
or maybe not shift-jis, some other asian encoding with the similar implementation
<whitequark>
Big9? I think Big9.
<def-lkb>
but then you want to index by codepoint, offset, rune, … in this string type? too much things are variable, sticking to a fixed 8-bit character type and build abstractions above seems saner to me
<whitequark>
def-lkb: it only seems saner to you because all your life you've only encountered latin1.
<whitequark>
you are a minority in that regard. most people can't afford to build abstractions over someone's broken latin1 foundation.
<companion_cube>
whitequark: when you design a new language I agree, utf8 everywhere
<ggole>
I wonder how an abstract Text type would work
<companion_cube>
but the change for OCaml would be too high
<companion_cube>
too complicated
<whitequark>
companion_cube: it pains me to agree here
<ggole>
No characters
<whitequark>
ggole: well, in Unicode characters aren't that useful anyway
<companion_cube>
for instance, if you have utf8 everywhere, then String.get disappears
<def-lkb>
whitequark: so yes, no text type defined at the language level
racycle has joined #ocaml
<ggole>
What do you do with strings?
<whitequark>
that's absurd, working with text is one of the most basic tasks a language has to do
<whitequark>
I mean, what, no stdio handling too?
<whitequark>
no file handling?
<companion_cube>
text is made to be interpolated, printed and read
<def-lkb>
everything provided by libraries. It is complex enough to define an acceptable interface that you don't want to impose it at a low-level
<_obad_>
my point was that String -> Bytes is alrady gonna break a lot of stuff, might as well fix the unicode situation while we're at it
<ggole>
I meant, string literals
<whitequark>
_obad_: you risk slowing adoption of 4.02 even further, i.e. Python 2.7 has had its support extended to 2020 (!!)
<companion_cube>
_obad_: but the new Bytes is opt-in
<whitequark>
mostly because Unicode breaking changes are so invasive
<_obad_>
well more like the old string is opt out no?
<companion_cube>
same thing?
<def-lkb>
whitequark: stdio… you have no guarantees that your input will be correct utf-8. As far as the runtime is concerned, process I/O as raw arrays of byte
<companion_cube>
indeed
<_obad_>
yeah.. :) I meant opt-in.
<companion_cube>
low level IO should still manipulate arrays of bytes
<companion_cube>
then, conversion/validation to Text
<companion_cube>
(with the necessary error handling)
<whitequark>
def-lkb: no, as a user, I don't care about runtime. I care about an easy way to manipulate text, because almost everything you do involves handling text in some way
<whitequark>
starting with filesystem paths.
<_obad_>
I think we could afford to have String handling UTF-8 *encoding*; but it doesn't have to know anything about code points / unicode
gasche has joined #ocaml
<whitequark>
not providing a standard way to manipulate text is like not providing arithmetics and saying that "well, libraries can be made for that".
<_obad_>
and we can keep a dinky Char.uppercase/lowercase for latin1 equivalents
<whitequark>
it's absurd
<def-lkb>
whitequark: but then as a user you'll be happy to rely on a library
<whitequark>
no, I'm not, it's a horrible interface
<_obad_>
the major problem is random access
<def-lkb>
It's much easier to agree on an interface for arithmetic than for arbitrary text related operations
<_obad_>
set strings as utf8, remove random access, replace with iterator/fold. done.
<companion_cube>
replace strings with ropes
<companion_cube>
profit
<def-lkb>
… rope sounds like bloat at this level.
<whitequark>
if you want a good interface, you also need to include the Unicode database, to allow iterating graphemes
contempt has quit [Ping timeout: 246 seconds]
<_obad_>
nooooooooooooooooooooooo
<_obad_>
last time I copied some files to run ocaml on an embedded system, the camomile database was taking 4 megabytes
<_obad_>
just because I was using lambda-term
<companion_cube>
def-lkb: well, rope_of_string should only add a variant
<companion_cube>
and then concatenation is cheaper
<whitequark>
_obad_: tiny embedded systems require special handling anyway, and non-tiny already have a LOT of flash
<whitequark>
it's largely a non-issue today
<_obad_>
erm 4 megabytes is half the size of a recent linux kernel. what do I need the unicode database for anyway?
<mrvn>
what people call embedded today are just small form factors of normal desktops
<whitequark>
_obad_: handling user-visible text sanely
<whitequark>
mrvn: smartphones (or the damn rpi) aren't really embedded
<mrvn>
whitequark: that was my point
<_obad_>
whitequark: ok... and still what do you need to know about codepoints? as long as you're not rendering them...
<whitequark>
you still have "true" embedded targets in areas where power consumption is really strict, though
<whitequark>
_obad_: as I've said: if it touches user-visible text, it should deal in graphemes
<whitequark>
"éo"[0] should display "é", not "e".
jwatzman|work has joined #ocaml
<_obad_>
whitequark: well é is a single codepoint, so utf8 is enough for that
<whitequark>
if it performs any kind of validation or matching against a database, it must be able to perform NFC/NFKC
<Enjolras>
;topic
<whitequark>
_obad_: it's not
<whitequark>
it's a LATIN SMALL LETTER E and a COMBINING ACUTE ACCENT
<_obad_>
but there is a single codepoing that does the same thing, no?
<gasche>
I think most people know that unicode handling could be better in OCaml
<gasche>
we're short on contributions to make it better
<whitequark>
_obad_: for é, there is, for other characters there isn't
<gasche>
the Camomile author recently worked on a lighter library to ease static-data-size concerns
<whitequark>
_obad_: note also two things: 1) some systems, e.g. Mac OS X, always send text as decomposed
<def-lkb>
multiple encodings are possible for unicode é I think
<gasche>
(recently: at most a couple years ago)
<whitequark>
_obad_: 2) if you get decomposed text, you need NFKC to get it back to composed state, which implies an unicode database
<_obad_>
whitequark: fine. now, why do you need to do "éo".[0] anyway
<gasche>
in practice it looks like most users of OCaml don't care much about good text support
<companion_cube>
+1 _obad_
<whitequark>
_obad_: companion_cube: if you compare composed text and decomposed text, it's a potential security issue if the text comes from an untrusted input.
<whitequark>
for example.
<_obad_>
maybe passwords shouldn't allow unicode?
<whitequark>
if your embedded device has a webserver (a lot of them do today) and handles user input (same), it needs to handle unicode properly
<whitequark>
no, it's not about password
<whitequark>
it's about things like performing access control based on paths and then passing data to something that normalizes text itself
<_obad_>
so the problem boils down to multiple representations
<ggole>
Not quite: things like upper and lowercase become complicated too.
<whitequark>
well, not just that, to perform any sensible operations with UTF-8 text (including concatenation!) you need the database
<_obad_>
ggole: yeah but what I'm saying is that that kind of business shouldn't be in a base library. it belongs in a human text library along with lemmatization etc.
<ggole>
Human text?
<ggole>
You mean, text? :)
<gasche>
or maybe it should be possible to users of the base library to not link against the database if their programs don't use those features
<_obad_>
yeah... you deal with human languages... then open Human
<_obad_>
you deal with chimpanzees... open Chimpanzee
<gasche>
I think "text" means user-facing text, all the time
rgrinberg has quit [Client Quit]
<_obad_>
let's say you write an ocaml version of some unix tool, like cp.
<gasche>
(and I would oppose "human languages" to "programming languages" that actually also require proper Unicode handling)
<whitequark>
gasche: it's probably possible to structure the library in the way that the small part (dealing with UTF-8 encoding, ensuring that UTF-8 is always valid inside the datatype) can be in the base library
<ggole>
But user-facing text is not clearly separable. There are things like filenames that are "user facing", but which need to be programmatically manipulated.
<whitequark>
gasche: but the big parts (databases that deal with graphemes) could be linked separately
<_obad_>
ggole: but all you need is (a) split/combine paths and (b) add/remove suffixes
rgrinberg has joined #ocaml
<_obad_>
if you have dangling COMBINING ACUTE ACCENT at the end of your pathnames... well
<whitequark>
gasche: so that if you don't like the grapheme manipulation parts, you could leave them out and get left with only the barebones install
<gasche>
indeed
<whitequark>
_obad_: (talking about human languages) JavaScript identifiers allow word-constituent characters
<gasche>
like unix/bigarray/graphics can be "left out"
<whitequark>
parsing JavaScript (or Java for that matter) requires an Unicode database.
contempt has joined #ocaml
<ggole>
And Haskell, and emacs lisp, etc
<gasche>
but if you insist that your language must be usable on small embedded targets, you probably want aggressive "I don't include what I don't use" guarantees that also concern stuff *inside* the base library
<companion_cube>
whitequark: why do you need a database to perform concatenation?
<whitequark>
source *is* human-facing text.
<companion_cube>
if both strings are well formed
<whitequark>
companion_cube: because combining marks should be ordered in a particular way
<whitequark>
companion_cube: hm, not sure about database, but it is not in general safe to just concatenate two valid UTF-8 strings. they may need postprocessing
<whitequark>
perhaps you could avoid the database; I need to check the standard to verify that
<companion_cube>
well you may merge things, yes
<_obad_>
if path1 and path2 are valid unix paths, is path1 ^ "/" ^ path2 a valid unix path, or not?
<_obad_>
and how does the kernel do it
<whitequark>
it works for paths, because "/" is not a combining character
<companion_cube>
_obad_: well you should do it in a system independant way if possible
<whitequark>
kernel only interprets / and \x00 specially
<ggole>
The kernel avoids all interpretation other than / and \0
<mrvn>
_obad_: the path could be too long
<_obad_>
and extensions? "."
<whitequark>
no
<whitequark>
no kernel I'm aware of cares about "."
<_obad_>
I know, but is path1 ^ ".so" valid if path1 is valid?
<whitequark>
Windows does a bunch of funky stuff; "COM", "\\\\?" and some others are special
<whitequark>
_obad_: ^ ".so" is valid too.
<_obad_>
and to decompose a path into its constituents,do we need anything besides basic utf-8 decoding?
<whitequark>
no.
<whitequark>
however, more complex processing (like prepending "foo_" to a basename) will.
<mrvn>
by the way: paths are not utf-8. They can easily contain illegal utf-8 sequences.
<whitequark>
i.e. x.ml → foo_x.ml.
<_obad_>
so why is adding foo_ complicated but not adding foo/ ?
<whitequark>
mrvn: not everywhere. on Windows paths must be valid Unicode I believe
<_obad_>
is _ special?
<whitequark>
_obad_: the basename could start with a combining character
<mrvn>
whitequark: and then someone inserts an USB stick where they aren't.
<_obad_>
but then what happens when we add "/" before it?
<_obad_>
>> A Unicode-conformant process could declare that it does not interpret combining marks, in which case, for it, <0041 0301> is a sequence of <0041> plus an uninterpreted character.
<whitequark>
hmm, good find
<_obad_>
so we could have the stdlib be unicode-conformant, but non-interpreting
<whitequark>
you still need a list of combining characters for that, but it eases processing
<whitequark>
I admit there's a good argument to refusing to process various obscure combining stuff in the pathnames and the like. if you can do it while remaining conformant, it's probably a good idea.
<ZenoArrow>
Sorry, I'm just catching the tail end of this conversation, but I'm interested in Unicode support in OCaml. From what I've heard OCaml doesn't support Unicode out of the box, what's the easiest way to add support?
<tautologico>
camomile I guess
<ZenoArrow>
Thanks tautologico, I'll check it out.
<gasche>
it seems that a lot of people write their GUI in some other languages (Python, C#, Javascript or, if you thought it couldn't get worse, Elisp and Vimscript), and defer the background work to OCaml
<gasche>
it makes sense to handle the textual stuff in the frontend as well
<whitequark>
gasche: webpages.
<whitequark>
well, that, and backend work frequently involves text too--I'd say almost always
<_obad_>
uutf etc. look nice but do we really need utf16{le,be}?
<gasche>
long-term I'm all for good libraries to work together directly from OCaml side etc.
<whitequark>
_obad_: it's not a significant hurdle to support anyway
<adrien>
gasche: I am currently writing my GUI in C and Win32
<gasche>
and getting Unicode right is probably easier than getting GUI right
<gasche>
(probably)
<adrien>
just in case anyone had doubts
<adrien>
it's awful
<gasche>
:]
<whitequark>
adrien: no .NET/
<whitequark>
*?
<whitequark>
seems like .NET is the microsoft's answer to all your GUI needs for quite some time
<adrien>
whitequark: not on bare windows and possibly old versions
<adrien>
plus it's only a .o in my ocaml program
<adrien>
so .net wouldn't fit
<whitequark>
and with XP out of the question (recent chrome and ff don't work on XP, I think), you have quite recent .net to care about
<adrien>
XP isn't completely out for me
<adrien>
soo but not yet
<whitequark>
it should :p
<adrien>
I wish
<adrien>
but in any case I can't use .net because I wouldn't be able to build it
<whitequark>
adrien: well, you'd do it other way. -output-obj and link it from .net
<whitequark>
(or do it as I will: use e.g. zmq and communicate with libraries native to either part)
<tautologico>
if I had to use .NET I think I'd go with F# instead of trying to fit OCaml in
<gasche>
whitequark, how is your "llvm backend hangover summary" document going?
<adrien>
whitequark: but the software should run on linux too
<adrien>
and not with wpf
<gasche>
(not that talking about .NET GUIs is not terribly interesting)
<whitequark>
gasche: didn't touch it so far
<whitequark>
I'll revisit it after I fix this ctypes issue, it's the last letter in my inbox :p
<whitequark>
(almost)
<tautologico>
did you run into the same problems as the previous attempts?
<whitequark>
tautologico: mostly different ones
<whitequark>
adrien: hm, what's the problem with linux/
<whitequark>
I mean, do you currently run your win32 gui through libwine? that sounds horrible
<adrien>
no WPF there
<whitequark>
and otherwise you'd write a native GUI either way
<adrien>
no, the gui doesn't exist on linux
<whitequark>
ok, so?
<tautologico>
adrien: Gtk# works reasonably well on windows, linux and os x, if you don't care about a full native GUI
<adrien>
-output-obj would require two different startups
<adrien>
one for windows and one for linux
<whitequark>
yes
<adrien>
tautologico: but that depends on GTK+ ;-)
<whitequark>
well, on linux you'd probably just use Lablgtk or something
<adrien>
whitequark: getting complicated
<whitequark>
adrien: it's really not, you just have one extra ocamlopt invocation
<tautologico>
I guess my two preferred solutions for cross-platform GUIs these days would be using Gtk# if on F# or a 0MQ-based solution on OCaml, as whitequark said
<adrien>
but it would be different depending on the platform and that's fairly annoying to do with ocamlbuild
<whitequark>
adrien: hm? just a simple myocamlbuild.ml rule
<whitequark>
with an if Sys.os_type = "..."
<whitequark>
tautologico: yeah. personally I'll have to write seven native GUIs for this project
<whitequark>
win32, cocoa-osx, cocoa-iphone, gtk, qt, android, web
<whitequark>
every single one is horrible in their own special way
<whitequark>
(in no particular order)
<adrien>
I don't call any myocamlbuild rule "simple" :P
* whitequark
can't live without flag ["ocaml"; "compile"] (S[A"-short-paths"; A"-w"; A"@5@8@10@11@12@14@23@24@26@29"]);
Arsenik has quit [Remote host closed the connection]
Cyanure has joined #ocaml
<whitequark>
a healthy dose of self-flagellation is what keeps the code clean.
<gasche>
I got short_paths through "ocamlbuild -documentation"
jao has quit [Changing host]
jao has joined #ocaml
<gasche>
sadly parametrized flags do not appear in -documentation yet
<whitequark>
calling that "documentation" is a bit of a stretch :D
<gasche>
I'm interested in pull requests to improve its output
<whitequark>
I have no idea how
malo has joined #ocaml
<gasche>
listing parametrized tags could help
<gasche>
then one could add an optional paramter to the pflag call (or a different call) to let plugin users provide a text to describe the effect of the parametrized flag
<ggole>
What's short-paths? I'm guessing it's new in 4.01?
<gasche>
(because currently there's only an OCaml function that you can't print)
<gasche>
yes
<gasche>
it prints short types when it can
<gasche>
eg. String instead of StringSet.t
<ggole>
Ah.
* ggole
approves
nikki93 has quit [Remote host closed the connection]
ollehar1 has quit [Ping timeout: 252 seconds]
<_obad_>
yey! nice one
boogie has joined #ocaml
* whitequark
sighs
<whitequark>
ctypes are so gnarly inside
<adrien>
woooooooooooooooooooo
<adrien>
got a window \o/
<adrien>
looks like windows 3.1
<whitequark>
not even 95? odd
<whitequark>
although there is a certain dialog even in win7 that looks like windows 3.1, literally
michael_lee has quit [Remote host closed the connection]
<adrien>
:)
jwatzman|work has quit [Quit: jwatzman|work]
olauzon has quit [Quit: olauzon]
maattdd__ has joined #ocaml
olauzon has joined #ocaml
<whitequark>
hmm, do I understand it correctly that < and > in [<...] and [>...] are essentially variance annotations?
<gasche>
they're not variance annotations, but syntactic sugar for polymorphism over a row variable
<whitequark>
right
rgrinberg has quit [Quit: Leaving.]
rgrinberg has joined #ocaml
maattdd__ has quit [Ping timeout: 240 seconds]
<ggole>
whitequark: that paper I suggested yesterday has some of the details
<whitequark>
ggole: I'm reading it right now, hence the question
<ggole>
...most of which I've forgotten since reading it
<ggole>
Oh, righto
<gasche>
"Simple Type Inference for Structural Polymorphism" is the right one, maybe it's the one ggole pointed
<whitequark>
I was looking at how the return type would have [< ...] and arguments (used in matching) would use [> ...]
<whitequark>
and that reminded me of variance. but of course, variance is a different thing
<ggole>
No, it was Programming with Polymorphic Variants
<gasche>
Programming ... is better if you want to get a programmer's feeling of how to use polymorphic variants
<gasche>
it doesn't have any of the theory, though
<gasche>
you're probably right to recommend "Programming"
<ggole>
Hmm, haven't read that one
* ggole
grows his paper stash by a little more
<gasche>
knowing the theory of polymorphic variants is actually not very important
<gasche>
(because most of the expressive stuff you may want to do with row polymorphism is hidden for historic reasons in OCaml)
<Drup>
historic reasons ?
<whitequark>
which expressive stuff?
<Drup>
whitequark: you can't write a function of type : [> `A | x ] -> x
<Drup>
(x being a poly var type)
<whitequark>
hmmm
<whitequark>
why would I want to? :D
<Drup>
whitequark: let f = function `A -> return something t | (#t as x) -> x"
<gasche>
basically open variants (those with > and/or < ) are polymorphic types that can be instantiated by types that may not have more cases than those listed in the < part, and must have the cases listed in the >
<Drup>
whitequark: "removing" the `A by making it a t, but not touching the t
<gasche>
closed variants [ `A of .. | `B of ... | ... ] are just a closed list of possible cases, and must be worked with using subtyping
<gasche>
Drup, historical because at the time Jacques didn't think the extra expressivity would be worth the perceived complexity
<Drup>
ok
ZenoArrow has joined #ocaml
<gasche>
in the last few years, a part of the user community of typed languages has been more and more vocal about asking for complex type system features
<gasche>
at the time were most of OCaml was designed, there was the idea that it's much better to keep thing simples for the user instead of pleasing type-system enthusiasts
<gasche>
(that point of view also explains some of the restrictions in the object system)
<whitequark>
not a bad idea
<Drup>
gasche: my opinion is that row polymorphism > subtyping, for stuff like that
<Drup>
but I can understand the concern
<ggole>
Mmm, my model for polymorphic variants for a while was "write code and then add :> if it complains"
<gasche>
back in the day, people thought that generics was a complex feature that would scare real programmers off
keen_______ has joined #ocaml
<ggole>
Not that I understand them properly now.
<whitequark>
gasche: oh, that explains Go :]
<gasche>
users have been gradually better-educated about these things
<Drup>
gasche: that didn't prevent functors :D
keen______ has quit [Ping timeout: 255 seconds]
<Anarchos>
i have no problem with complex type features as soon as i can still code with simple constructions as before.
<whitequark>
it's more of a problem when a community is built around using contrived methods
<whitequark>
something something boost, for example
<gasche>
I think there is interesting research to be done about layering languages of various complexity with proper formal guarantees
<ggole>
I've heard stories about boost::spirit error messages
<gasche>
the problem is that these sort of things are rather hard to "sell" to the community
<whitequark>
gasche: I believe it's more an UI issue than a formal semantics one
<gasche>
there is both, and I'm of the opinion that semantics should inform the UI work
<whitequark>
I mean, it's nice when you have a soundness proof, but not if the feature is too complex to be actually usable
nikki93 has quit [Remote host closed the connection]
<gasche>
(also I'm more interested in the formal aspect, so it's what I would rather work on)
<ggole>
Requiring proofs probably helps keep things simple though
<ggole>
SML was pretty spartan
<companion_cube>
as long as you can start writing things in the language without knowing all its complicated features, having an advanced type system should be fine
thomasga has quit [Quit: Leaving.]
<whitequark>
I like how most of the OCaml avoids delving into depths of insufferable abstractions; functors are an easy way to set up a problem you can't solve
<whitequark>
GADTs even more so.
<whitequark>
I say about GADTs that I understand the motivation behind them but I still really hate to work with them. kind of like C++, don't you think? :]
<gasche>
then don't use them :p
<ggole>
I've butted heads with GADTs a few times, and always regretted it
<whitequark>
gasche: I try not to. but right now I try to write a patch for ctypes
<ggole>
It'd be nice if you could go halfway, with the ability to say "this GADT value can have any leg"
<whitequark>
And it is not easy in no small part due to GADTs
<ggole>
(Not sure how that would actually work.)
<whitequark>
jeremy yallop suggested a (sorry if you're reading it) rather contrived system for representing various kinds of pointers with GADTs
<whitequark>
the reasoning behind is sensible, but I really hate going through large swathes of interfacing code that dissects GADTs and changing them in subtly different way
<whitequark>
ways*
<whitequark>
it's true though that without GADTs, ctypes wouldn't be possible at all. I don't doubt their value. I just hate touching them at all
<flux>
I'm burning minutes here but with only 13% of my cpu in use :)
nikki93 has joined #ocaml
nikki93 has quit [Remote host closed the connection]
ustunozg_ has joined #ocaml
<rgrinberg>
flux: concurrency and parallelism aren't the same thing
<rgrinberg>
the scheduler is waiting for the disk or the network so why should it thrash your cpu?
<rgrinberg>
oh nvm i thought your first comment was in the context of the async one
<rgrinberg>
oops
zpe has joined #ocaml
nikki93 has joined #ocaml
Nuki has joined #ocaml
oriba_ has joined #ocaml
tlockney_away is now known as tlockney
oriba has quit [Ping timeout: 240 seconds]
<mrvn>
I have one slide to fill with a few buzz words to explain what OCaml is. Suggestions?
axiles has quit [Remote host closed the connection]
_andre has quit [Quit: leaving]
nikki93 has quit [Remote host closed the connection]
ustunozg_ has quit [Remote host closed the connection]
rand000 has joined #ocaml
metasyntax has quit [Quit: Leaving]
ollehar has joined #ocaml
gasche has joined #ocaml
<gasche>
Drup, I don't think there is a paper about destructive substitutions
WraithM has joined #ocaml
<gasche>
I don't think optional fields are a beautiful feature
<Drup>
I didn't say beautiful, it's useful.
<Drup>
huum, I remember a paper motivating destructive substitutions
<gasche>
maybe Norman Ramsey
<_obad_>
mrvn: what's the target audience
<gasche>
Drup, "Towards a Calculus of Signatures", Norman Ramsey, 2001
<gasche>
but that's only a motivation from a user point of view
<gasche>
there is no description of the actual semantics (which is where things get tricky for the OCaml module system)
<Drup>
ok
dnm has joined #ocaml
olauzon has quit [Quit: olauzon]
S11001001 has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
Thooms has quit [Quit: WeeChat 0.3.8]
Kakadu has quit [Quit: Konversation terminated!]
saml has quit [Quit: Leaving]
manizzle has quit [Quit: Leaving]
manizzle has joined #ocaml
manizzle is now known as WeLoveCP
rgrinberg has quit [Quit: Leaving.]
saml has joined #ocaml
saml has quit [Client Quit]
Nuki has quit [Ping timeout: 240 seconds]
Hannibal_Smith has quit [Quit: Sto andando via]
ggole has quit []
Rotacidni has joined #ocaml
<Rotacidni>
About alpha-conversion and constructor. Can I consider constructors are something perform alpha-conversion in lambda-calculus?
<Rotacidni>
and constants for beta-reduction?
<gasche>
Rotacidni, I don't see the relation between constructors and alpha-conversion
WeLoveCP is now known as manizzle
<mrvn>
Rotacidni: constructor as in "Foo (1, 2)"?
<gasche>
(also: constructors don't beta-reduce, but also giving parameters to them doesn't reduce)
Nuki has joined #ocaml
<mrvn>
constructor are (hopefully soon first class) functions
<Drup>
mrvn: from a semantic point of view, no.
<Rotacidni>
Thanks. I know alpha conversion has no relation with types, but constructor is creating a type name.
<mrvn>
Drup: people are working on makeing "type t = Foo of int * int" have a "val Foo : int -> int -> t"
<Drup>
that's not what I said.
<gasche>
I released a Camlp4 extension to do just that about 6 years ago
<Drup>
you're talking usability and typing
<Drup>
Rotacidni is talking semantic
<nicoo>
mrvn: 1) Who is working on that ? 2) This would be eviiiiiiiiiiil (because uncurried constructors vs. curried functions with the same name)
<gasche>
(except it was called _Foo for obvious sanity reasons)
<nicoo>
I guess adding curried constructors would be cleaner, but would make for a bigger patch :(
<gasche>
(and it had _field access functions as well)
<mrvn>
nicoo: 1) check the channel logs and google, 2) functions can't be upper case
manizzle is now known as WeLoveCP
<Drup>
I'm pretty much reading everything on this chan and I missed that :|
<mrvn>
nicoo: currie vs. uncurried is a break though
<def-lkb>
+_+
<nicoo>
mrvn: Not begining with uppercase doesn't really fix anything about 2 ; it still violates POLA
<nicoo>
mrvn: Can't uncurried constructors be added without breaking backwards compat ? (Of course, in « type t = Foo of int * int », Foo would still be curried ; you could have something like « type t = Foo : int -> int -> t » (hopefully, something less different from the current situation))
<nicoo>
def-lkb: ?
WeLoveCP is now known as manizzle
<nicoo>
mrvn: Also, like Drup, I read most stuff that goes on here, and I still missed it ^^
* nicoo
goes grep the log
<mrvn>
nicoo: I'm sure they thought of something that integrates nicely. Check last years logs.
<mrvn>
Been quite a while since the idea came up last.
manizzle is now known as WeLoveCP
<mrvn>
type t = Foo : int -> int -> t looks like a GADT though.
<mrvn>
(except GADTs, like other constructors, aren't curried. Only one argument allowed)
<def-lkb>
curried constructors might be fine for sum types where arity is known
<nicoo>
mrvn: Yes, I was “inspired” by the Coq syntax (and so were GADTs, I guess), but it's not something I would be happy with
<def-lkb>
but how would that apply to polymorphic variant?
<nicoo>
mrvn: And yes, I know GADT constructors are uncurried
<mrvn>
def-lkb: how does that matter? type 'a t = Foo : 'a -> 'a -> 'a t
<nicoo>
def-lkb: It wouldn't, I guess ; by any means, having a projection function magically associated to polyvariants sounds somewhat crazy
WraithM has quit [Ping timeout: 240 seconds]
<mrvn>
The GADT syntax would easily allow extending it to curried constructors.
<def-lkb>
(ok, just syntactically looking at the number of applied arguments, and eta-expanding as usual)
Simn has quit [Quit: Leaving]
<nicoo>
mrvn: Yup
<gasche>
polymorphic variants take tuples as parameters
<gasche>
(anyway)
WeLoveCP is now known as manizzle
<mrvn>
gasche: type t = `Foo : int -> float -> t
<mrvn>
polymorphic GADT :)
<def-lkb>
gasche: right
<def-lkb>
gasche: so, is anybody working on an implementation ?
<nicoo>
mrvn: Why would you want to allow *that* ? o_O
WraithM has joined #ocaml
<gasche>
def-lkb, of consructors as functions? not as far as I know, but that doesn't mean no one is
<mrvn>
nicoo: because type t = [ `Foo of int * float ] doesn't allow for currying.
<mrvn>
hmm, curried functors would allow some new matchings too: type t = Foo : int -> float -> t, match x with Foo 1 -> ... | Foo 2 -> ...
<def-lkb>
ok, fine (I can't see how to make this backward compatible, this would be nice though)
<mrvn>
def-lkb: I would probably break and reuse the GADT syntax. Changes the memory representation of existing GADTs but that should break only few codes.
<gasche>
I think we have other cats to whip, or fishes to fry
<nicoo>
def-lkb: I can have a stab at a proposal for fun (if I find some spare time and a unicorn), so that gasche and you (if you are willing to read it) can rip it to shreds.
<def-lkb>
agree
<mrvn>
nicoo: if you have spare time could you implement prefix subtyping for records?
<mrvn>
type r1 = { x:int; } type r2 = { x:int; y:int; } and then allow r2 :> r1
<gasche>
I think nicoo that there are better things to do with your time
<nicoo>
mrvn: Would that even be possible, given the memory representation of records ?
<gasche>
this one is almost certain to be forgotten
<mrvn>
nicoo: totaly. YOu can just Obj.magic it.
<nicoo>
gasche: Unfortunately, hance the “spare time and a unicorn” part.
<mrvn>
nicoo: you could even have functions f : { x:int; .. } as 'a -> { x:int; ..
<nicoo>
mrvn: Ah, I get the “prefix” part, now; I'm not an expert, but I doubt it would be a good idea (except if you like breaking code by reordering the order of field declarations)
<mrvn>
nicoo: you could even have functions f : { x:int; .. } as 'a -> 'a
<gasche>
nicoo, this is minor, but I commented on your Map/Set example pull requests
<mrvn>
nicoo: reordering is not allowed. Only shortening of a record
<gasche>
note that row polymorphism, contrarily to coercions, can allow reordering
<mrvn>
gasche: but if you allow reordering, like in objects, then you need an extra indirection
<mrvn>
and full row polymorphism needs runtime types.
<nicoo>
mrvn: Yes, that's what I meant: it means you can break your codebase (fails to compile) because somewhere, the order of fields in a type declaration was changed. Also, making record types order-sensitive might break a lot of existing code (since .ml and .mli might suddenly disagree, for exemple)
<mrvn>
nicoo: aeh, .ml and .mli have to agree I think.
<gasche>
to be fair record types are already order-sensitive if you use them through the C API
<def-lkb>
nicoo: record types are order-sensitve
<nicoo>
gasche: Ah? I missed that (might be because my SPAM filter has gone rogue and I haven't put back all the false positive in the right places yet)
<mrvn>
module M : sig type r = { x:int; y:int } end = struct type r = { y:int; x:int; } end;;
<mrvn>
Fields number 1 have different names, y and x.
<nicoo>
gasche: Great, thanks
<mrvn>
nicoo: a proposed syntax is also to have type r2 = { r1 with y:int; } to extend an existing record.
<nicoo>
def-lkb, mrvn : Ah, didn't know that ; thanks.
Cyanure has quit [Remote host closed the connection]
zpe has quit [Remote host closed the connection]
maattdd__ has joined #ocaml
zpe has joined #ocaml
araujo has joined #ocaml
araujo has quit [Changing host]
araujo has joined #ocaml
WraithM has joined #ocaml
dotfelix has joined #ocaml
zpe has quit [Ping timeout: 252 seconds]
philtor has joined #ocaml
gasche has quit [Ping timeout: 276 seconds]
jao has quit [Ping timeout: 252 seconds]
WraithM has quit [Ping timeout: 240 seconds]
rand000 has quit [Quit: leaving]
dotfelix has quit [Ping timeout: 276 seconds]
dotfelix has joined #ocaml
dotfelix has quit [Client Quit]
boogie has quit [Remote host closed the connection]
Rotacidni has quit [Ping timeout: 250 seconds]
WraithM has joined #ocaml
maattdd__ has quit [Ping timeout: 240 seconds]
philtor has quit [Ping timeout: 245 seconds]
darkf has joined #ocaml
ollehar has quit [Ping timeout: 252 seconds]
oriba_ has quit [Quit: oriba_]
rgrinberg has joined #ocaml
eizo_ has quit [Ping timeout: 240 seconds]
ikaros has quit [Quit: Ex-Chat]
boogie has joined #ocaml
madroach has quit [Ping timeout: 252 seconds]
<Vaur>
hi
madroach has joined #ocaml
<Vaur>
I doing a project for school in ocaml and I'm currently working on the documentation generated by ocamldoc
<Vaur>
I've been searching on internet by couldn't find a lot about it
<Vaur>
so what's the good practice with ocamldoc ?
NoNNaN has quit [Remote host closed the connection]
NoNNaN has joined #ocaml
<companion_cube>
Vaur: I'd suggest you use ocamlbuild
<companion_cube>
and then, write a .odocl file with all the modules whose documentation you want
zpe has joined #ocaml
boogie has quit [Remote host closed the connection]
Rotacidni has joined #ocaml
zpe has quit [Ping timeout: 240 seconds]
<Vaur>
companion_cube: humm I'm a bit confuse I was told to use ocamldoc because it will generate the doc automaticly with the comments that are in my .mli files (which is the what is happening right now when I do make doc )
<Vaur>
is it bad ?
<companion_cube>
oh, if your makefile already does it, then what is the problem? :)