<Smerdyakov>
I'm submitting to PLDI 2005, though, so maybe next time. :)
<Smerdyakov>
I'll definitely be at POPL 2005.
<mfurr>
I'm also submitting to pldi, but don't think I'll make it out to popl this year
<Smerdyakov>
Have you heard of TLDI?
kinners has joined #ocaml
<mfurr>
yes, although I'm not very familiar with the proceedings... I see you've published there :)
<Smerdyakov>
Well, not yet, but I'll be presenting at the next version, which is colocated with POPL 2005.
<mfurr>
I'm pretty sure my advisor, Jeff Foster, will be there though, so feel free to say hi to him
<Smerdyakov>
I know him a bit. He presented at the summer school where I met Polyvios and David Greenfieldboyce. He also graduated from my research group a year or so before I started here.
<mrvn>
re
<mrvn>
mfurr: I see, you only read in the basic key: value so far.
<mrvn>
karryall: With implode/explode it is simpler to pattern match or strip away leading chars.
<mrvn>
vincenz: An entry of Debians Sources file. It's an rfc822 formated header.
mfurr_ has joined #ocaml
<mfurr_>
this is ridiculous, this is the 3rd new class B subnet my cable modem has been assigned to in the past 24hours
<mrvn>
mfurr: Any intentions of making the parser interpret the structure of the Packages/Sources files and fill out a more usefull record?
<monochrom>
The Internet is expanding! Inflating even!
<monochrom>
Every 24 hours, three new class B subnets are created!
<mfurr_>
monochrom: I am not amused
<monochrom>
In a year we would have enough class B subnets for everyone in the world!
<mfurr_>
mrvn: not at the moment, I'm only using string comparisons for what I'm doing....
<mfurr_>
I would love to put together a general purpose debian parser library at some point though
* mrvn
too, including all the dependencies stuff.
<mrvn>
I'm writing a new wanna-build for the debian-amd64 buildd that is more intelligent than the old one.
<mfurr_>
I started doing that a while ago and that's what started that parser
<mfurr_>
what kind of things are you adding to it?
<mrvn>
primarily Build-Depends checking.
<mfurr_>
My original goal was to build a more robust schedular
<mfurr_>
that was starvation free
<mfurr_>
and could automatically trigger rebuilds when reverse-depends were updated...
<mrvn>
The triggering is already there in the old one. But the setting of Build-Depends isn't.
<mfurr_>
also, I wanted to have it group packages by their build-deps so to minimize the interbuild package installs/removals
ianxek has quit ["Leaving"]
<mrvn>
yep, me too. But that it not so important for amd64. Its idle most of the time anyway.
<mrvn>
I have planned for the buildd script to only install/purge the difference in packages between successive builds but I haven't implemented that yet (missing a good parser and all).
mfurr has quit [Read error: 110 (Connection timed out)]
<mfurr_>
yeah, some more sugary regex's would help a lot there
<mrvn>
I thought of using a priority queue for the needs-build queue. The priority of the package is calculated as 'a * (b + time)' where a and b are influenced by the priority, urgency, number of Build-depends and reverse build-depends, number of archs with build failure
<mfurr_>
sounds good. I was originally thinking of having multiple queues with different priorities...
<mrvn>
yeah, but then one queue can starve the others.
<mfurr_>
so that say, security updates would be in a queue which disallowed priority inversion....yes
GreyLensman has left #ocaml []
<mfurr_>
but other queues would allow inversion
<mrvn>
inversion?
<mfurr_>
priority inversion
<mrvn>
you mean security would be fifo but other queues not?
<mfurr_>
so a low priority queue (say optional or extra) could outscore a required or base queue
<mfurr_>
no queue would be fifo
<mfurr_>
each queue would have a priority weight associated with it....
<mfurr_>
security would be high, required might be medium, everything else would be low (or something)
<mfurr_>
things in the low priority queue could possibly displace things in the medium queue if they were getting starved
<mrvn>
I think using something like a*(b+time) in a single queue is best. security builds can get a big headstart (b) so they start further up in the queue and a large speed (a) so they overtake others.
<mfurr_>
sounds reasonable
<mrvn>
And the time prevents starving.
vezenchio has quit ["None of you understand. I'm not locked up in here with you. YOU are locked up in here with ME!"]
<mfurr_>
but it would be nice if say machine A was building a package which had build deps W X Y Z and then a new package comes along which also has build deps W X Y Z, then it would be beneficial to schedule the new pacakge immediately
<mfurr_>
it could also be beneficial to keep track of how long a build takes, so as to schedule short jobs first
<mrvn>
A optional package (e.g. a=1) would have to be twice as old as a base package (e.g. a=2) but it would get build.
<mfurr_>
I'd be interested to see how the algorithm performs... everything I've said is just based on my intuition and I don't know how well it would actually work
<mrvn>
mfurr_: yep. and more importantly correlate build time/requirements with the buildd. Don't build XFree on the 64MB ram system, use the 512MB one.
<mrvn>
mfurr_: A totally different thing I might try is to build packages against the same Build-Depends on all archs.
<mrvn>
Say foo on i386 is build with libbla 1.0 and then libbla 1.1 is uploaded. foo on all other archs would always be before libbla 1.1 then.
<mfurr_>
another idea is that (if a buildd is idle) try building a package with all posible subsets of build-deps
<mrvn>
urgh, no way.
<mfurr_>
lol... I was originally calling my tool "QA-builder" :)
<mrvn>
Use the atimes to find all used packages and match it against the Build-Depends.
<mfurr_>
not all POSSIBLE subsets, but if a pkg depends on (X|Y) try with X, and then try with Y
<mrvn>
But idle buildds could rebuild sarge packages against sarge.
<mrvn>
mfurr_: Ahh, yes. That would be nice.
<mfurr_>
there's just soo much an idle buildd could do :)
<mfurr_>
now all we need is a small army of m68k boxen
<mrvn>
Another new thing is that the buildd gets told if it should build with "-b" or "-B", i.e. with or without _all.deb packages.
<mfurr_>
definately
<mfurr_>
it would be really nice (as often suggested) to be able to build arch: all packages
<mrvn>
Another thing: The buildd has to check in every now and then and say that it is still building a package. If it doesn't check in the package gets rescheduled after a while.
<mfurr_>
yes
<mrvn>
mfurr_: How long does your lexx/yacc parser take to parse a Packages file from main?
<mfurr_>
less than a second
<mfurr_>
(without doing anything else)
<mrvn>
Good. But the "without doing anything else" will be the problem I guess.
<mrvn>
My wanna-build is not threaded but can handle multiple sockets. But each single action (like 'take package') has to be short or it won't be smooth.
<mfurr_>
I don't think it will be terrible... especially since its only once(?) a day
<mrvn>
If I scan in 15000 packages and update the database with all the Depends, rev Depends and all that it will probably take a while.
<mfurr_>
You should be able to make the 'take' op be quite fast... especially with a heap
<mrvn>
Not to mention it would (currently) create a 15Mb string holding the packages file first.
<mrvn>
Everything below a second is fine anyway.
<mrvn>
Above a minute would probably lead to connection timeouts.
<mfurr_>
but the en masse updates should be infrequent. and the 'take' and put-back ops shouldn't change the state that much
<mrvn>
No, I only worry about the daily update. The rest is small stuff.
<mfurr_>
so do the updates in a seperate thread and have the socket code tell the buildds to piss off for 120 seconds
<mrvn>
Currently I update through a helper that pipes a package header at a time into a socket. The wanna-build will only parse max 4K on a socket before moving on to the next in a round-robin. That should schedule it finely enough.
<mfurr_>
that would definately work too
<mfurr_>
I'm glad someone is finally rewriting this in a proper language instead of the atrosity that was the previous version ;-)
<mrvn>
I just can't have it buffer all packages and then do a big update, it only schedules on the reads.
<mfurr_>
makes sense
<mrvn>
Yeah, in ocaml I can do a "Hashtbl.fold (fun key pkg list -> if (criterium pkg) then pkg::list else list) all_packages" and that stuff.
<mfurr_>
I think I've figured out how to do really efficient updates of Packages/Sources files without having to keep a bazillion .diff's lying around
<mrvn>
how?
<mfurr_>
(which is what I'm working on now)
<mfurr_>
observation 1) Packages files are stored in sorted order
<mfurr_>
2) if you send a client a new stanza, it can figure out where it place it in the file
<mrvn>
[bad]
<mfurr_>
?
<mrvn>
number 1 is bad.
<mfurr_>
why?
<mrvn>
Makes it hard to find new entries.
<mrvn>
Think about this: Sort entries by date, newest entry first.
<mfurr_>
That is just how things are currently
<mrvn>
If you have a Packages file you can download the new file until you find a stanza you already have. Then you are done.
<mfurr_>
don't need to do all that
<mfurr_>
all the client has to do is send the timestamp from the last Release file it downloaded
<mfurr_>
Then, the server keeps a list of each package and when it was last updated
<mrvn>
Replacing the old stanzas with new ones is easy. Whats left are removed stanzas. Not much harm keeping them a while.
<mfurr_>
that's a trivial extension to handle
<mrvn>
mfurr_: timestamps would need special servers. We only have ftp/http servers now.
<mfurr_>
no, the timestamp in the signed Release file is all that is needed
<mfurr_>
ah I see
<mfurr_>
yes, you need a new kind of server
<mfurr_>
/ daemon
<mrvn>
The beauty of sorting by date is that you change ftp-master and apt-get and it works. And old apt-get also works.
<mrvn>
The drawback is that package deletions won't update.
<mrvn>
Also rsyncing the Packages file would be quite efficient since never updating packages would all drift to the end and always match.
<mfurr_>
you can do much better than a generic rsync algorithm... there is too much structure in the Packages file which can be exploited
<mrvn>
You could do a 2-stage download: 1. download new stanzas and update Packages file, 2. rsync Packages file.
<mrvn>
I was thinking about using rsync on stanzas instead of blocks. each checksumm would cover one stanza.
<mrvn>
That would improve it too.
<mfurr_>
I think that even that much rsyncing would kill a mirror though
<mrvn>
Not if the client does the computations.
<mfurr_>
I'd be interested in seeing how much load the server still has to do in that situation too
<mrvn>
The server gets a Packages.cksum file with "md5sum size" per stanza. The client downloads that, computes all byte ranges it needs to fetch and downloads just those with http.
mfurr_ is now known as mfurr
<mrvn>
That would also work with any http mirror.
<mrvn>
The client could even decide to get the Packages.bz2 or the updates depending on size.
<mfurr>
I think you'd run into problems with the .bz2 versions though....
<mfurr>
it uses something like 900k blocks for the encoding
<mrvn>
The bz2 would be the complete file.
<mrvn>
Like when you didn't update sid over the summer holidays.
<mrvn>
Downloading the changes of the Packages file would be uncompressed so it can be bigger than the bz2.
<mfurr>
oh I see what you're saying. I don't think it would take even that long
<mrvn>
Unless, and this gets realy complicated for the client, you download chunks from the gz and fill in the blanks from the local uncompressed Packages by recompressing it.
<mfurr>
20% of the packages of been updated this month and I think that would be larger than an entire .bz2
<mrvn>
But that would probably waste too much cpu and time for round robins.
<mfurr>
I don't know if you can do that with .gz... you'd also need to get the various headers placed through the file to figure out exactly what to get
<mrvn>
mfurr: If you do it in 2 stages with stanzas sorted by date you can download the Packages.gz for all the new stanzas.
<mrvn>
And the second stage then the checksums and uncompressed.
<mrvn>
(which should be just removing old stanzas)
<mfurr>
yeah maybe.
cjohnson has quit [Read error: 110 (Connection timed out)]
<mrvn>
Since I controll the scripts on debian-amd64 I think I will make it sort the Packages file by age, if I can figure out how to do it simple in shell, and then write a client to update the Packages.
<mfurr>
in shell? good luck :)
<mrvn>
Or write a script that downloads the Packages file daily and creates a age sorted Packages file in my local mirror or something.
<mrvn>
Once I have a Packages parser in ocaml that shouldn't be too hard.
<mfurr>
I'd be interested to hear how things go
<mrvn>
Make a assoc list of "name * package" from the old Packages file, read in the new Packages file. For each stanza in the new file with higher version than the old one remove old entry, add new entry at front, output stanzas.
<mrvn>
That should be just a screenfull of code if at all.
<mfurr>
I find things like ocamlmakefile way too simplistic for most projects
<mfurr>
this gives me a bootstrap which doesn't take too much work to adapt to a new project
<mfurr>
although I've been meaning to look at the build system the meta-prl guys put together
<mfurr>
(omake or something...)
<Smerdyakov>
You should see the SML/NJ CM.
<mfurr>
why's that?
* mfurr
is always interested in a better make
<Smerdyakov>
Because it's almost flawless. It's hard to imagine anything easier.
<Smerdyakov>
You just specify which source files are in your project.
<mfurr>
does it handle .c files (Does sml even have a foreign function interface?)
<Smerdyakov>
Yes and yes.
* mfurr
goes and looks
<Smerdyakov>
SML is ahead of OCaml in terms of serious compiler support now, I think.
<Smerdyakov>
That wasn't the case a few years ago.
<mrvn>
What about having multiple binaries?
<Smerdyakov>
SML/NJ doesn't generate separate binaries. I wasn't necessarily recommending the tool itself, but the approach.
<mrvn>
no linking of units to one file?
<Smerdyakov>
It does that, but the result is a heap file. It doesn't run on its own.
<mrvn>
But if you have multiple binaries you have to say which sources belong into which binary.
<Smerdyakov>
The SML/NJ CM also has mechanisms for defining libraries by specifying lists of source files and lists of signatures and structures to export.
<Smerdyakov>
For that, you would have a separate .cm file for each, I suppose.
<mrvn>
That would be easy in ocaml. Specify the ml files, export any mli files.
<Smerdyakov>
Hardly.
<Smerdyakov>
You don't always want all your structures to be visible in the library.
<Smerdyakov>
Like utility modules.
<mrvn>
they wouldn't have a mli file, or?
<Smerdyakov>
I like to give every structure a specified signature.
<mrvn>
Then you need an internal mli and an external one.
<Smerdyakov>
Or you could just choose which entities to export!
<mrvn>
:) or a keyword for it
<Smerdyakov>
SML also doesn't have this ridiculous idea of ".mli files."
<Smerdyakov>
The module system is not connected to the file system in any way.
<Smerdyakov>
Which means no need to have "Map.Make" instead of just "MapFn".
<mrvn>
You need the mli for cyclic depends between compilation units.
<Smerdyakov>
The base OCaml compiler doesn't support cyclic dependencies, does it?
<mrvn>
no realy need but that is how the compiler works.
<mrvn>
Smerdyakov: sure it does.
<Smerdyakov>
OK. I don't think I've ever used modules with cyclic dependencies.
<Smerdyakov>
At any rate, the issue I'm talking about is completely orthogonal to that.
<Smerdyakov>
You can just as well maintain separate files that explicitly define signatures, and other files that define modules that explicitly constrain themselves with those signatures.
<mrvn>
Sometimes it would be nice if you could have files without adding the name to the namespace.
<Smerdyakov>
Sure. And that issue is nonexistent in SML.
<mrvn>
On the other hand it is nice that you know where to look for a module.
<Smerdyakov>
You can even duplicate structure names in a project, if the duplicates are in libraries and are not exported by them.
<mrvn>
In ocaml you can even duplicate structures in one file and namespace.
<Smerdyakov>
Sure, but not if the structures are defined in separate files from the uses!
<mrvn>
seperate files -> seperate namespace
<Smerdyakov>
No.
<Smerdyakov>
Each file defines a module.
<Smerdyakov>
And if you use the same filename, you get global namespace clashes.
<mrvn>
which makes it a seperate namespace
<mrvn>
you mean same filename in different libraries?
<Smerdyakov>
Yes, or even in one library.
<mrvn>
I think I get what you mean
<mfurr>
alright I'm off to get some work done. Nice chatting with y'all
mfurr has quit ["must work now"]
srv has quit [Read error: 232 (Connection reset by peer)]
<mrvn>
n8
srv has joined #ocaml
monochrom has quit ["Don't talk to those who talk to themselves."]
mrsolo has joined #ocaml
mrsolo has quit [Read error: 104 (Connection reset by peer)]
mrsolo has joined #ocaml
kinners has quit ["leaving"]
velco has joined #ocaml
Herrchen has joined #ocaml
GreyLensman has joined #ocaml
GreyLensman has quit [Client Quit]
pango has quit ["Client exiting"]
pango has joined #ocaml
det_ has quit [Read error: 60 (Operation timed out)]
ita|aw is now known as ita
_velco has joined #ocaml
ita has quit [tolkien.freenode.net irc.freenode.net]
calvin_ has quit [tolkien.freenode.net irc.freenode.net]
avn has quit [tolkien.freenode.net irc.freenode.net]
hello_world has joined #ocaml
hello_world has quit [Client Quit]
hello_world has joined #ocaml
calvin_ has joined #ocaml
hello_world has quit [Client Quit]
_fab has quit []
Kevin has joined #ocaml
ita has joined #ocaml
kinners has joined #ocaml
_fab has joined #ocaml
ianxek has joined #ocaml
<vincenz>
ocamlmakefile doesn't support subdirs
<Kevin>
IMHO you can use "LIBDIRS += ../../lib" or "INCDIRS += ../../lib" .
vezenchio has joined #ocaml
Herrchen has quit ["bye"]
cmeme has quit [Broken pipe]
cmeme has joined #ocaml
kinners has quit ["leaving"]
ita is now known as ita|aw
det has joined #ocaml
mrvn_ has joined #ocaml
Kevin is now known as kevin2
mrvn has quit [Read error: 110 (Connection timed out)]
docelic has quit ["goin' homer"]
kevin2 is now known as S_kevin
S_kevin is now known as kevin_S
<vincenz>
that's just including
<vincenz>
but it doesn't create libraries
<kevin_S>
.cma files ?
<vincenz>
yeah
<vincenz>
basically I have
<vincenz>
output/output.cma
<vincenz>
types/types.cma
<vincenz>
and then I link them
<kevin_S>
So I don't know.
<_velco>
how can I separately compile signatures and structures ?
<_velco>
i.e. I do "ocamlc -c -g foo.mli"
<_velco>
and then "ocamlc -c -g foo.ml"
<_velco>
and id barfs abiut the signature in foo.mli being unbound
<kevin_S>
What is exactly the error mesg ?
<_velco>
Unbound module type TREE
<_velco>
if I put the two files in one it compiles and runs fine
<kevin_S>
HIMO the module type definition must have to be in the .ml .
<kevin_S>
But if you want to create a good interface you can "constraint" it in the .mli
<_velco>
doesn't make sense, I may want to have several implementations of the same interface
<kevin_S>
So you can make a generic module. And then redefine a new module with a new interface for each interface you want. module Tree2 : TREE2 = struct include Tree end ...
<_velco>
*sigh* I don't get it ...
<Smerdyakov>
OCaml's conflation of files and modules is a pain.
<Smerdyakov>
_velco, they can _only_ be used to constrain the corresponding .ml files.
<_velco>
bummer!
<Smerdyakov>
Lots of silly OCaml issues like this pile up, which is why I prefer SML.
<vincenz>
Smerdyakov: so... what's the difference between SML/NJ and Mlton?
<vincenz>
And how hard is it to port something from ocamlto sml
<Smerdyakov>
It's easy to port if you don't use OO.
<Smerdyakov>
SML/NJ has the best setup today for development.
<Smerdyakov>
MLton has the best setup for building efficient, standalone executables.
<Smerdyakov>
The same code will work on each if you're careful.
<Smerdyakov>
MLton will be better than SML/NJ in both categories by 2 years from now, if I understand the development schedule correctly.
<ita|aw>
ocaml came before sml, right ?
ita|aw is now known as ita
<vincenz>
where's mlton being developed (And SML/NJ)
<Smerdyakov>
ita, yes
<mellum>
But MLton runs on far less platforms, IIRC.
<Smerdyakov>
vincenz, MLton is a true Internet collaboration between people in geogrephically diverse locations.
<vincenz>
so there's no college that's taken lead of it
<Smerdyakov>
SML/NJ was mostly developed at Bell Labs.
<vincenz>
(university)
<vincenz>
oh
<Smerdyakov>
Now it's centered around U. of Chicago.
<vincenz>
I thought appel's university was in charge of an implementation
<Smerdyakov>
No. That period of time is long over.
<Smerdyakov>
He works mostly in formal methods now.
<pango>
_velco: rename tree.mli to treesig.ml and add open Treesig on top of tree.ml
<pango>
_velco: as you said you could use the same signature with several modules, so .mli/.ml naming simply don't match the functionnality you're looking for
<vincenz>
why do you need to calculate from every bird to every bird?
<vincenz>
that's just plain overkill
<vincenz>
birds don't have infinite eyes
<kevin_S>
because this is the "Boid" algorithme.
<vincenz>
so you only do boid?
<vincenz>
besides that's not true what you're saying
<kevin_S>
yep, that was enouph for 3 week of work :)
<vincenz>
boid flock towards the center of gravity
<vincenz>
and stay away from anything that's too naer
<vincenz>
so it's not quadratic
<vincenz>
it's linear
<vincenz>
calculate center of mass
<vincenz>
and then just use collision detection
<mrvn_>
vincenz: But collision needs to check the distance to every other.
<vincenz>
mrvn_: use a btree
<kevin_S>
But you have to calculate distance for the center of gravity
<oracle1_>
if I defined a class in A.ml, and it's compiling well with the mli interface. what could be the reason that file B.ml does not recognize the class defined in A.ml?
<vincenz>
kevin_S: no you don't
<oracle1_>
B.ml does open A.
<vincenz>
kevin_S: I mean yes you do
<vincenz>
and that's ONE claculation for each bird
<mrvn_>
vincenz: then you have n log(n)
<vincenz>
a) calculate point of center of gravity
<vincenz>
mrvn_: depends on the parameters, either it's much faster than o(n*n)
<vincenz>
(either..way)
<oracle1_>
Unbound class returnVarVisitor
<mrvn_>
vincenz: And you need to update the btree as it changes
<kevin_S>
vincenz: I don't know if it was a very good implementation. But at the end it work and I have a good mark (16/20) :)
<vincenz>
mrvn_: I meant a quadtree
<mrvn_>
vincenz: No, octtree I guess.
<vincenz>
...
<vincenz>
oh yeah
<vincenz>
3d
<mrvn_>
Unless you have surreal 4D birds. :)
<vincenz>
that fly back in time
<mrvn_>
You could simulate a flock of hypercubes mingling around.
<vincenz>
and having kids
<kevin_S>
"having kids" was planed in the begining but I was short in time.
<vincenz>
I meant hypercubii
<kevin_S>
C++ seg-fault suck
<ita>
bad memory management sucks too :)
<vincenz>
sadly, women don't
haakonn has quit [Read error: 110 (Connection timed out)]
ita is now known as ita|aw|we
ita|aw|we has quit ["leaving"]
monochrom has joined #ocaml
<TheDracle>
Ocaml Segfault sucks even more.
<TheDracle>
On the incredibly rare occasion one actually occurs.
<kevin_S>
You have one ?
<TheDracle>
No, somebody mentioned above how C++ segfault sucks :P
<kevin_S>
The difference is : when a C++ program compil you can easy have a seg-fault. In ocaml without using --unsafe it is hard.
<TheDracle>
Well, not if you're playing with the Marshal module :p
<kevin_S>
Try a marshal like module in C++ just for fun (If you can have fun with it he he he) .
<TheDracle>
At least it segfaults.. The problem with C++ is when it keeps going despite having overflowed the stack, or the heap, or written over a function pointer.
<TheDracle>
You should try out CINT, this abombination of an interpreter.
<TheDracle>
They use it for ROOT, and all of this physics analysis software. I mean, they actually managed to make something with less safety than C++.
<TheDracle>
It's completely insane, this is what they use for computationaly intensive numeric analysis. C++!
<kevin_S>
I don't understand what you try to tell me?
<TheDracle>
Just that it's crazy that people use C++ for something it was completely not intended for.
<kevin_S>
haaaaa
<kevin_S>
ok
<TheDracle>
let tst a = let s = Marshal.to_string a [Marshal.Closures] in Marshal.from_string s 0;; tst 3.0 5.0;;
velco has quit [Read error: 60 (Operation timed out)]
<mrvn_>
TheDracle: C++ has some realy nice features for computationaly intensive numeric.
<TheDracle>
mrvn_: Such as?
<TheDracle>
mrvn_: The fact that it will cut off floats without telling you? Automatically assume the type of a function an int without its prototype? Overwrite buffers on your stack into other numeric values?
<mrvn_>
Say you have large matrixes. You can optimize the +,-,* operators to combine multiple operations into one. e.g a=b*c+d in one big loop.
<TheDracle>
mrvn_: I work in a physics group, I see these types of errors all the time. People work for weeks just plugging crap in until they get the answer they think it sright.
<TheDracle>
Right, operator overloading is a nifty feature for doing vector mathematics and such.
<mrvn_>
Esspecialy if you want to work with spare matrixes too.
<kevin_S>
I know convert string to integer is problematic. Just to feed the troll : ["hello";Obj.magic 2];;
<TheDracle>
Heh.
<mrvn_>
kevin_S: That isn't a conversion :)
<kevin_S>
mrvn_: no but it is fun !
<TheDracle>
Fortran at least had optional bounds checking on arrays.
<mrvn_>
What is 2? Isn't that () or something?
<mrvn_>
TheDracle: bounds checking? hey, that would be slower --> off.
<Smerdyakov>
Ah. An excellent philosophical question. "What is 2?"
<kevin_S>
If I remember () is 1
<mrvn_>
No, 1 is 0.
<TheDracle>
mrvn_: Yeah, you turn it on, check to see if your program is overflowing the stack into other numerical values completely screwing up your end result, and then turn it off and run the rest of it through.
<mrvn_>
bit 0 == 1 --> integer
<Smerdyakov>
() is 0.
<TheDracle>
More than likely if it's an off by one, you're writting a byte into the float just below your buffer, or something along those lines.
<mellum>
() is 0 and 0 is 1. Therefore, () is 1.
<TheDracle>
Heh.
<mellum>
But I guess it depends on what the definition if "is" is.
<Smerdyakov>
mellum, 17.
<mrvn_>
bit pattern 1 is integer 0.
<mrvn_>
Is ["hello";Obj.magic 2] even a correct list for the GC?
<kevin_S>
no it seg-fault all time
<mrvn_>
# let a = let b = ["hello";Obj.magic 2] in ();;
<mrvn_>
val a : unit = ()
<mrvn_>
The pretty print in ocaml segfaults.
<kevin_S>
right
<kevin_S>
I search for a better one...
<mrvn_>
# let a = let b = ["hello";Obj.magic 2] in Gc.major (); Gc.major (); ();;
<mrvn_>
val a : unit = ()
<mrvn_>
GC seems to like it too.
<Smerdyakov>
The GC doesn't read dead objects.
<mellum>
Sure. The GC thinks it's a C pointer pointing outside of its heap.
<Smerdyakov>
No, the GC doesn't think it's anything. It ignores it.
<kevin_S>
b is dead in this context ? right ?
<mrvn_>
mellum: 2? pointers are divisible by for iirc.
<mrvn_>
kevin_S: no, still reachable.
<mellum>
mrvn_: but why would one want to check for that? Wastes time.
<Smerdyakov>
mrvn_, but it's _not_ reachable in some reasonable compilation strategies. I don't know what OCaml does, though.
<mrvn_>
mellum: non ints have 2 tag bits. 2 is a 10 tag.
<mellum>
mrvn_: not in Ocaml. Maybe you're thinking of emacs.
<mrvn_>
Smerdyakov: does the ocaml CLI optimize?
<Smerdyakov>
I don't know the details here.
<pango>
I think the interpreter generates bytecode internally
<TheDracle>
The ocaml interpreter doesn't JIT yet does it?
<mrvn_>
mellum: right.
<pango>
unlikely
<mrvn_>
Debians Packages files are a pain to parse. It is just impossible to write a grammar for them.
<kevin_S>
The expression ((Obj.magic (()))^"a") seem to seg-fault for all way of evalution...
<mrvn_>
kevin_S: as expected.
<kevin_S>
yep :)
<kevin_S>
let seg_fault () = ((Obj.magic (()))^"a");; (* ;) *)
<kevin_S>
faster than "exit" :p
cjohnson has quit ["The main attraction: distraction"]
<mrvn_>
Its usefull if you want to get into gdb at a certain point to check something.
pango has quit ["bbl"]
pango has joined #ocaml
srv has quit [Read error: 232 (Connection reset by peer)]
kevin_S has quit ["Quit"]
srv has joined #ocaml
velco has joined #ocaml
<velco>
suppose one has a functor "module Foo (S : SOME_SIG) = ...."
<velco>
in what file where should SOME_SIG be defined ?
<Smerdyakov>
Wherever you like. It will be visible according to the usual scoping rules.
<velco>
err, I mean "module Foo = functor (S : SOME_SIG) -> struct ... end;;
<Smerdyakov>
Same answer. :)
<velco>
same unbound module type :(
<Smerdyakov>
Where are you defining it?
<velco>
wherevr I like :)
<Smerdyakov>
You must be more specific.
<Smerdyakov>
The question is really the same as "I want to make a function call f(x). Where do I define f?".
<velco>
stack.mli contains signature STACK, stack.ml contains structure Stack and eval.mk contains the functor and a specialization
<Smerdyakov>
Move the signature to its own .ml file with no .mli file.
* Smerdyakov
leaves.
<Smerdyakov>
Always remember that .mli files introduce _no_ bindings whatsoever.
<Smerdyakov>
They just constrain .ml files.
<velco>
what does "constrain" mean ?
<mrvn_>
velco: limit. They can hide internal stuff.
<velco>
FUCK, ocaml modules are unusable
<mrvn_>
I think they are great.
<velco>
how can I separately compile signatures and stuff that uses them ?
<avlondono>
just compile the mli first
<velco>
does not work
<velco>
do I have to pass some flags to the compiler ?
<avlondono>
nope
<velco>
the same: if I mention the signature name in some other file, the compiler complains "unabound module type"
<avlondono>
you realize you're not giving any useful information to findout what you're doing wrong, do you?
<avlondono>
you have to give the full signature name, like Set.OrderedType, not just OrderedType
<avlondono>
unless you open it
<velco>
oops
<velco>
Set is the name of the file ?
<avlondono>
yep
<avlondono>
and yes, without knowing that, the modules are unusable. but that's not Ocamls fault ;-)
<avlondono>
yeah, if you don't have anything else in the ml and mli other than that stack implementation, just get rid of the module ... stuff. That's implied by the file.
<avlondono>
and that stack-sig should probably be stack.mli
<velco>
"module Eval = functor (S : stack.STACK) ->"
<velco>
what's wrong with this line? "File "eval.ml", line 1, characters 32-33:"
<avlondono>
man you should really read the manual. Stack.STACK.
<velco>
stack.ml and stack.ml are the other files, hence the "stack."
<avlondono>
modules should have uppercase in the first character.
<mrvn_>
1. loose the ;;, that is just for the CLI.
<mrvn_>
2. stack.mli has no 'module Stack : STACK'
<mrvn_>
3. kill 'module type STACK = Stack.STACK;;'
<mrvn_>
4. kill 'Stack.' in stack.ml
<mrvn_>
you might as well just kill stack.mli since everything is exported.
<mrvn_>
5. add stack.mli contents to stack.ml
<mrvn_>
actually 5) is 1b
<velco>
These are no possible, because Stack is one of many possible implementatins of STACK
<mrvn_>
You are using Stack.Stack in eval.ml so it must be exported.
<velco>
I see I can't have one interface for many implementations.
<mrvn_>
of cause you can, you do.
<velco>
+in separate files
<mrvn_>
you can but you don't have that yet.
<mrvn_>
You only have one Interface (Stack.STACK) and one implementation (Stack.Stack) in one file (stack.ml).
<velco>
I know.
<velco>
see, now I have Stack, which is an implementation of STACK with lists
<velco>
later I'd like to have, e.g. ArrayStack, which is also an implementation of STACK, but using arrays
<velco>
what file I put it in ?
<mrvn_>
Whatever file you fancy.
<mrvn_>
What file do you put "let f x = ..." in?
<velco>
soo, I put "ArrayStack : Stack.STACK = struct ..." in arraystack.ml
<mrvn_>
for example.
<velco>
and what happens? it is not visible, because it is not exported by stack.mli, right ?
<velco>
just like Stack is no exported now.
<avlondono>
no
<avlondono>
beh
<mrvn_>
It is visible in Arraystack
<mrvn_>
velco: stack.mli does not export anything. It only constrains stack.ml
<velco>
ok, and since Stack is not mentionen in stack.mli it is "constrained" ?
<velco>
Stack.Stack I mean
<mrvn_>
If you intend to have a list stack and array stack then I would put them in liststack and arraystack from the start and have stack.ml just be the interface.
<mrvn_>
Or put them all in there including the eval.
* velco
trying that ...
<avlondono>
yes, or add module Stack : STACK to the stack.mli
<avlondono>
so it will be visible, with interface STACK
<mrvn_>
velco: The easiest way for an *.mli file is to not make one, run ocamlc -i -c *.ml and then remove the parts you wan't hidden.
<mflux>
btw, how do you hide the definitions of types or can you?
<mrvn_>
You just don't put them in the mli file?
<avlondono>
type t in the sig, instead of type t = int
<avlondono>
keep them abstract
<mflux>
but I want to return them etc?
<mflux>
ok, I thought I had tried that but failed, but perhaps not then
<velco>
ok, worked finally ... ugly as hell, but appears to work ...
<mrvn_>
velco: alternatively you can build a record of closures that make up your interface.
<velco>
heh
<mrvn_>
type 'a stack = {
<mrvn_>
empty : unit -> 'a stack;
<mrvn_>
push : 'a stack -> 'a -> 'a stack;
<mrvn_>
pop : 'a stack -> 'a * 'a stack
<mrvn_>
is_empty : 'a stack -> bool;
<mrvn_>
}
avn has joined #ocaml
velco has quit ["I'm outta here ..."]
<dan2>
mrvn_: what are you using a stack for?
<mrvn_>
dan2: I'm not, that was just an example for velco
<dan2>
oh
GreyLensman has joined #ocaml
monochrom has quit ["Don't talk to those who talk to themselves."]
mrsolo has joined #ocaml
mrsolo_ has quit [Read error: 110 (Connection timed out)]