<mrvn>
In the toplevel you can also just get hold of the value and then "value;;" will pretty print it.
<Xteven>
but not from withinn a function ?
<mrvn>
nope.
thieusoai has quit ["leaving"]
<Xteven>
is there another way to find out what some variable looks like on the inside ?
<Xteven>
I'm trying to write a module for CIL, which is written in OCaml
<Xteven>
there is almost no useful documentation
<mrvn>
At runtime you can only look at the representation in memory. With that and the source you can reconstruct what the value is but it is work for complex types. Better to use the sexplib extension to get a pretty printer for the value.
<mrvn>
The sexplib does the reconstructing for you then.
<Xteven>
sadly, that looks overly complicated
munga_ has quit [Remote closed the connection]
<Xteven>
thx for the help
<mrvn>
only the first time :)
thieusoai1 has quit ["ERC Version 5.3 (IRC client for Emacs)"]
thieusoai1 has joined #ocaml
thieusoai1 has quit [Client Quit]
thieusoai has joined #ocaml
thieusoai has quit [Client Quit]
<Xteven>
mrvn: probably
<Xteven>
I guess I will have to find it out sooner or later
<Xteven>
but right now, I was struggling with the stupidest of problems and wanted to get it fixed before going to sleep
<Xteven>
1.30 am
struktured has joined #ocaml
<Xteven>
its fixed though :) I'll have a look at sexplib soon
<mrvn>
That is another thing I would change when writing a new ocaml compiler. Always (or with compiler option) create pretty print function for every data type.
<Xteven>
maybe there is a good reason for not including it
<Xteven>
I'm off to bed, cya later :)
<mrvn>
nah, just lazyness
<hcarty>
The Batteries.Print.* functions, along with the associated syntax extension, provide some very nice pretty print boilerplate.
<mrvn>
Does ocamldebug pretty print?
<hcarty>
Allowing for things like (Print.sprintf p"%{int array list option}\n" foo)
<mrvn>
hcarty: %{Foo.t}" too?
<hcarty>
I think ocamldebug gives Std.dump-like output. It's been a while since I've used it though.
<hcarty>
mrvn: Yes, as long as Foo.print_t is defined.
<mrvn>
hcarty: And that is something I would add to the compiler directly.
<mrvn>
If no such function exists generate one automatically.
<hcarty>
mrvn: That would certainly be nice.
Alpounet has joined #ocaml
Xteven has quit [Read error: 104 (Connection reset by peer)]
reid99 has quit [Connection timed out]
Proteus_ has joined #ocaml
seanmcl has joined #ocaml
thrasibule has quit [Read error: 110 (Connection timed out)]
Amorphous has quit [Read error: 145 (Connection timed out)]
Proteus_ has quit ["Leaving"]
jeddhaberstro has joined #ocaml
valross has joined #ocaml
_unK has quit [Remote closed the connection]
struktured has quit [Read error: 54 (Connection reset by peer)]
psnively has joined #ocaml
psnively has left #ocaml []
razel has quit [Read error: 110 (Connection timed out)]
tar_ has joined #ocaml
thrasibule has joined #ocaml
thieusoai1 has joined #ocaml
seanmcl has quit []
seanmcl has joined #ocaml
razel has joined #ocaml
thieusoai1 has quit [Remote closed the connection]
thieusoai1 has joined #ocaml
bohanlon has quit [SendQ exceeded]
jeddhaberstro has quit [Client Quit]
thieusoai1 has quit [Remote closed the connection]
struktured has joined #ocaml
jknick has quit ["leaving"]
tonyIII_ has joined #ocaml
tonyIII__ has quit [Read error: 104 (Connection reset by peer)]
valross has quit [Remote closed the connection]
caligula__ has joined #ocaml
seanmcl has quit []
slash_ has quit [Client Quit]
caligula_ has quit [Read error: 110 (Connection timed out)]
thrasibule has quit [Read error: 145 (Connection timed out)]
BigJ has quit [Remote closed the connection]
mihamina has joined #ocaml
tar_ has quit []
valross has joined #ocaml
Xteven has joined #ocaml
ttamttam has joined #ocaml
ttamttam has quit ["Leaving."]
ygrek has joined #ocaml
Associat0r has joined #ocaml
srisw has joined #ocaml
srisw has quit [Client Quit]
ttamttam has joined #ocaml
jcaose has joined #ocaml
smimou has joined #ocaml
<mihamina>
hi all
tonyIII_ has quit ["Leaving"]
<mihamina>
I would like to binary open an image file and send it, using netgci. I have the path of the file. how to binary open it, and calculat it's size, so that I can setup the right Content-Length option?
<mihamina>
using channels: open_in_bin opens me the file. but how to store it's binary content and calculate its size?
chachaonnaog has joined #ocaml
onigiri has quit []
<tiz>
mihamina: Both using "input" (for size, you will have to count the bytes read)
<tiz>
You can also use functions from the Unix module to get the size directly.
munga_ has joined #ocaml
_zack has joined #ocaml
Yoric has joined #ocaml
kaustuv has joined #ocaml
ua has joined #ocaml
chachaonnaog has quit ["you gotta say yes to another excess"]
animist has quit [Remote closed the connection]
animist has joined #ocaml
<_zack>
anyone knows who is the "rdouglass" working at jane street which has just announced the availability of core doc?
<_zack>
I'm trying to find an email address to contact jane street about that doc, but I found nothing thus far
<Camarade_Tux>
rdouglass@janestreet.com ?
<_zack>
Camarade_Tux: I suppose I can try that :)
<Camarade_Tux>
it's the address which sent the email I have in my inbox :P
Ched has quit [Read error: 110 (Connection timed out)]
<_zack>
Camarade_Tux: ah, cool, so it is even validated by you ;-) , thanks
<Camarade_Tux>
hehe :P
Yoric has quit []
ikaros has joined #ocaml
valross has quit [Remote closed the connection]
verte has quit ["~~~ Crash in JIT!"]
Snark has joined #ocaml
munga_ has quit [Read error: 60 (Operation timed out)]
<kaustuv>
Should I start taking a more serious look at Core?
<kaustuv>
(as in, is the API stable?)
<thelema>
kaustuv: there's two parts to core - one part is quite stable, the other is... more experimental
<thelema>
I guess that jane street is kinda conservative when it comes to core
seanmcl has joined #ocaml
seanmcl has quit []
rwmjones_lptp has quit ["This computer has gone to sleep"]
seanmcl has joined #ocaml
Submarine has joined #ocaml
<flux>
mihamina, iirc there's a function input_length or some such
<rwmjones>
thelema, there's an old mirror of the ocaml repo at http://repo.or.cz/w/ocaml.git seemingly owned by you ... any chance of updating it to track the new svn repo? apparently repo.or.cz can track SVN repos automatically
<flux>
kaustuv, so does this mean the problem isn't reproduced?
<kaustuv>
That's what it would seem.
<flux>
kaustuv, how about if you add function let mk_big () = (big 'a', big 'b') and use that?
<kaustuv>
Same result.
<flux>
hmm, actually it produces different numbers for me, but I compiled differently
<kaustuv>
I'm on ocaml 3.11.1 on x86_64
<flux>
tried it with ocamlc?
<flux>
ocamlopt indeed gives the same results, but ocamlc doesn't..
<kaustuv>
Ah, yes, I get that too. Strange.
<flux>
so a bug in ocamlrun then, perhaps?
<flux>
bug/misfeature
<flux>
or maybe optimizer has something on this
<kaustuv>
But ocamlc and ocamlopt would share the part of the compiler that, according to the Jane St. comment, performs a code transform that keeps the tuple alive.
<kaustuv>
Hmm... I wonder if the inliner is being triggered
<flux>
(my ocamlc is 3.10.2, for reference)
<flux>
-inline 0 or -inline -10000 didn't change the results
<kaustuv>
ocamlopt -dlambda and ocamlc -dlambda produce very different output. Hmm...
<kaustuv>
Interesting. ocamlc -dlambda indeed uses field 0 and field 1 to access x and y, while ocamlopt -dlambda doesn't.
<kaustuv>
Or more accurately ocamlopt both assigns the match to an immediate and projects out the first component if only that component is used.
<kaustuv>
I guess the upshot is: don't use ocamlc if you care about space leaks
<flux>
kaustuv, it appears that if I remove the clear-stuff from go1 and just do let _ = (big..) in .. it still consumes the memory
<flux>
changing that to ignore (..); makes the leak go away
<flux>
well, not leak, but..
<kaustuv>
sure, clear () was just extra paranoia on my part
<flux>
well I needed to remove clears to make it compile
<flux>
I have nothing against paranoia :)
<flux>
the point was that I didn't even give the value a name
<flux>
neither x nor y
<kaustuv>
Well, apparently all matches are given a name always if the output of -dlambda is to be believed.
<thelema>
rwmjones: I don't see anything about SVN mirroring at repo.or.cz
<rwmjones>
the spacing is all wrong because I'm just drawing each character separately
<rwmjones>
and incrementing the X position by the width of the character
rwmjones is now known as rwmjones-afk
Submarine has quit [Read error: 60 (Operation timed out)]
seanmcl has quit []
<mrvn>
rwmjones-afk: for smaller fonts antialiasing just blurs
bombshelter13__ has joined #ocaml
Yoric has quit []
Yoric has joined #ocaml
<thelema>
I'm giving up on the auto mirroring, and will just set up a cron job on my desktop to update daily
ygrek has joined #ocaml
tautologico has joined #ocaml
Snark has quit ["Ex-Chat"]
Yoric has quit [Read error: 60 (Operation timed out)]
seanmcl has joined #ocaml
_zack has quit ["Leaving."]
tautologico has quit [Read error: 145 (Connection timed out)]
Amorphous has joined #ocaml
<Camarade_Tux>
mfp: do you read the ocaml_beginners mailing-list? someone's asking for a stomp client and iirc you wrote a stomp broker, maybe you have the client too?
rwmjones_lptp has joined #ocaml
ulfdoz has joined #ocaml
ua has quit [Read error: 113 (No route to host)]
ikaros_ has joined #ocaml
Submarine has joined #ocaml
ikaros has quit [Read error: 60 (Operation timed out)]
<mfp>
Camarade_Tux: yes, actually
<mfp>
having a quick look at the code and probably uploading to github in a while
Yoric has joined #ocaml
seanmcl has quit []
ua has joined #ocaml
seanmcl has joined #ocaml
shr3kst3r has quit [Remote closed the connection]
shr3kst3r has joined #ocaml
Submarine has quit ["Leaving"]
Submarine_ has joined #ocaml
<hcarty>
mrvn: Thanks again for pointing out the flaw in my try_finally function a few days ago. I fixed it and it helped me track down a rather obscure bug I've been facing.
<Camarade_Tux>
mfp: oh, nice :)
<mrvn>
hcarty: we live to serve
<mrvn>
Maybe ocaml should have a mode where it never reuses memory. Just munmap free heaps and mmap new ones at later addresses.
<thelema>
yay, ocaml is getting warnings for use of deprecated features... I just hope we can put this to use soon
<Camarade_Tux>
thelema: ftr, which are these deprecated features?
<Camarade_Tux>
what*
<thelema>
oops, n/m - this warning existed before...
* thelema
greps the source for Deprecated (the warning type for these)
<thelema>
hmm, some things in camlp4...
jcaose has joined #ocaml
<thelema>
But it looks like very little actually uses the deprecated tag
<thelema>
I take that back - nothing uses the deprecated tag - it's *all* in comments
<thelema>
That'd be a good project for an afternoon - actually raising the deprecated warning on all the things marked deprecated
ttamttam has joined #ocaml
seanmcl has quit []
Submarine_ has quit [Read error: 110 (Connection timed out)]
Submarine_ has joined #ocaml
seanmcl has joined #ocaml
bzzbzz has quit ["Lost terminal"]
sramsay_ has joined #ocaml
* mrvn
has to write a GC for data sets bigger than ram. Any pointers?
<thelema>
Garbage collector?
<mrvn>
yep
<thelema>
I don't see the problem with collecting a data set that's bigger than ram, as long as you do it little by litt.e
<thelema>
if you want to GC a region of memory that's bigger than RAM... i.e GCing swap...
<thelema>
ick.
<mrvn>
I have a big B-Tree covering 8 TB of 4k chunks.
<mrvn>
Even a bitmap would take 256MB and the system only has 512 total and things running.
* thelema
will think about this later
<thelema>
cheers
<mrvn>
I'm thinking of splitting up the space into say 256MB chunks and then do one chunk at a time. Sort of generational GC.
<mrvn>
I also want a moving GC as it should act a defrag as well.
<mrvn>
i.e. get the leafes of the B-Tree into linear order.
infoe has quit [Read error: 60 (Operation timed out)]
<flux>
well, apparently ZFS takes loads of memory too
<flux>
maybe you could chip in and upgrade the system to one gigabyte ;)
<flux>
..if you can get memory for a system that old..
<mrvn>
It has 1G but only recognises half of it. :(
<mrvn>
flux: no. next reboot. anywhere from 6-60 month.
<Camarade_Tux>
mfp: nice, thanks :)
<flux>
mrvn, bet its kernel is old and full of holes. time to do a security upgrade!
<mrvn>
flux: firewalled, not externally reachable.
<flux>
besides the system doesn't sound like it couldn't just self-destruct within the next 6-60 months also..
<mfp>
Camarade_Tux: I added some API docs; it's quite straightforward
<flux>
(power source, condensators grown old on the mb, etc..)
<mrvn>
flux: If I had the money I would by an Atom330 board and 8 port SATA cntroler.
<mfp>
Camarade_Tux: generic, low-level (i.e., accepts custom headers) STOMP client, plus higher-level clients adapted to RabbitMQ and ActiveMQ, plus a high-level OO client with error recovery and connection/subscription management
<mrvn>
I wish more onboard chips would support sata port multiplier.
<mfp>
Camarade_Tux: simple as it is, it's more full-featured than the libs (for other langs) I saw around, which usually stop at the first, forcing you to figure out the mannerisms of the server you're talking to
<mrvn>
flux: I would love to connect 4 of those to an Atom330 but the chipset on the board I have for my desktop doesn't support port multiplier.
ulfdoz has quit [Read error: 110 (Connection timed out)]
<Camarade_Tux>
mfp: ok, good :)
<flux>
mrvn, you could put in a port-multiplier enabled adapter.. actually those come with two-port adapters.
<flux>
modeemi.fi/~flux/devices \o/. although I'm about to put the cages into separate computers, so backupping makes more sense..
mrvn has quit [Read error: 131 (Connection reset by peer)]
mrvn has joined #ocaml
<flux>
mfp, how nice of you to think other concurrency implementations
<flux>
mfp, can you provide an executive summary why Stomp might be preferable (is it even comparable?) to IRC or XMPP?
<mfp>
flux: Mq_concurrency.Posix_thread should be named Id_thread or such --- the code is not thread safe (i.e., parallel ops on the same Mq.connection or Mq_impl.mq might do bad things)
ski_ has joined #ocaml
<mfp>
flux: vs. IRC: most (all?) STOMP servers feature at least 2 delivery modes: queue (persistent, ack'ed messages) and topic (multicast, usually not persistent)
<mfp>
flux: IRC would only give you the latter per-se
<mfp>
s/IRC/a normal IRC server/
<flux>
mfp, do the quarantees hold in the event of restarted peers/servers?
<mfp>
vs. XMPP: don't know much about it, but it's way more complex than STOMP. XML, to start with.
<mfp>
flux: yes
<mfp>
flux: if a peer receives a msg and doesn't ACK it, the server can deliver it to another subscriber for that queue
<flux>
mfp, so it is targeted towards message passing between programs, more than between people?
<mfp>
yes, definitely
<flux>
ok. thanks.
<mfp>
think of task queues and such
<flux>
maybe I'll find use for it some day in future :)
<flux>
apparently it had quite a wide variety of bindings for different languages
<flux>
maybe your implementation should get hooked up too
<mfp>
the STOMP protocol is very very simple
<flux>
(linked from the page, that is)
<flux>
yes, that appeared to be their main selling point
<mfp>
it's very underspecified in fact, leaving many things implementation-dep
<mfp>
so you have all sort of ad-hoc extensions, using custom headers, on each server
<mfp>
for instance, RabbitMQ requires a rather refined dance to create a persistent queue
<flux>
does it atleast have a defined extension mechanism?
<mfp>
with ActiveMQ, OTOH, you can say that a given msg is to be persistent
<mfp>
you can add mycustomheader: whatever lines to the frame
<flux>
indeed, quite simple
<mfp>
whether it changes anything is server-dependent
<flux>
is order of message delivery guaranteed?
<mfp>
server-dependent :/
infoe has joined #ocaml
<mfp>
same as persistence, priority, etc.
<flux>
hmm, so if you require that, you need to pass serial numbers or use some other protocol over that..
<mfp>
IIRC neither ActiveMQ nor RabbitMQ guarantee that by default, but it might be possible to configure ActiveMQ to do so
<mfp>
also, I've discovered that RabbitMQ cheats when you ask for a persistent queue, as it doesn't fsync(2) when it confirms that it's saved a msg
<mfp>
it just keeps in mem and writes to disk at leisure, so it'll crash if you send too many msgs too fast
<mfp>
flux: strict order of delivery would be very slow if you are using ACKed receipts, as you wouldn't be able to have more than 1 pending ACK
<mfp>
no matter how many receivers
<mfp>
ActiveMQ and RabbitMQ allow to specify per-client max-pending counts, so you can have up to clients * max_pending msgs "on the wire", and achieve delivery rates of (tens of) thousands of messages/s
onigiri has joined #ocaml
jcaose has quit ["Leaving"]
Submarine_ has quit ["Leaving"]
willb1 has joined #ocaml
<rwmjones_lptp>
mrvn, ocaml-ancient?
willb1 is now known as willb-goatee
willb-goatee has left #ocaml []
<ygrek>
btw, are there any problems with manually setting No_scan_tag on int array?
<mrvn>
rwmjones_lptp: totaly different.
<mrvn>
I would like something so the GC does something destructive to unregistered C pointers to ocaml data so one can force a crash.
<mrvn>
like move all heaps around a big.
thieusoai1 has joined #ocaml
mishok13 has quit [Read error: 110 (Connection timed out)]
Yoric has quit []
ttamttam has quit ["Leaving."]
slash_ has joined #ocaml
thieusoai1 has quit [Remote closed the connection]
tvn2009 has joined #ocaml
seanmcl has quit []
ygrek has quit [Remote closed the connection]
tvn2009 has quit [Remote closed the connection]
valross has joined #ocaml
peddie has joined #ocaml
<infoe>
what is: external create : int -> string = "caml_create_string"
<mrvn>
A C function
<infoe>
ah
<infoe>
which C function
<mrvn>
caml_create_string
<infoe>
ok so its not a C lib its specific to ocaml
<mrvn>
no. Needs to be a ocaml specific function that takes an ocaml int and returns a ocaml string.
<mrvn>
It could call a normal C library in turn but highly doubtfull in this case.
<mrvn>
byterun/str.c
<infoe>
thanks
rstites has joined #ocaml
ikaros_ has quit ["Leave the magic to Houdini"]
mgodshall has joined #ocaml
Associat0r has quit []
DaveS has joined #ocaml
DaveS has quit ["leaving"]
mgodshall has quit ["rcirc on GNU Emacs 22.1.1"]
<thelema>
any suggestions other than sexplib (which I'm giving up on installing at the moment) for a trivial config file of a record of booleans?
<Camarade_Tux>
json?
* thelema
tries json-wheel
<thelema>
json-wheel isn't quite so pretty for records - turning them into objects or hashtables
<Camarade_Tux>
Marshal? xD
<thelema>
hmm, actually, why didn't I try that before...
<thelema>
oh yeah, because it might be nice to be able to read the config. feh, no big deal.
jeddhaberstro has joined #ocaml
<thelema>
too bad there's not a "readable" flag on marshal... hmmm...
<thelema>
blah, people would probably want some sort of safety on it if it were readable... That's probably why
slash_ has quit [Client Quit]
<Camarade_Tux>
and I wish it didn't compress, it makes compression with another algorithm much less efficient (especially lzma)
<Camarade_Tux>
atually, with lzma on data that is already compressed is completely useless
tvn2009 has joined #ocaml
<thelema>
yay, marshal for the quick fix
<Camarade_Tux>
yeah, you can still easily use something else later on :)
rwmjones_lptp has left #ocaml []
tvn2009 has quit ["Leaving"]
tvn2009 has joined #ocaml
tvn2009 has quit [Client Quit]
tvn2009 has joined #ocaml
munga_ has joined #ocaml
<monestri>
how do I check something's type?
sramsay_ has quit [Read error: 110 (Connection timed out)]
<Camarade_Tux>
you mean, at runtime?
<monestri>
yes
<Camarade_Tux>
you can't, the types aren't kept
<Camarade_Tux>
but what do you want to do with that? (ie, can we give another solution?)
rwmjones-afk has quit [Read error: 60 (Operation timed out)]