<orbitz>
drats that doens't cover what i thoguht it would
<ikatz>
hmm... i just tried to replicate the problem with a bare minimum of code and it worked fine
<ikatz>
let me check this out for a bit and come back with a better problem description
jeremiah has quit [Read error: 110 (Connection timed out)]
<ikatz>
ok this is the problem i am seeing
<ikatz>
say i have "mytype.ml" and "main.ml"
<orbitz>
i won't say that
<ikatz>
say uncle!
<ikatz>
ok
<orbitz>
please sir may i have another
<ikatz>
mytype.ml is "module Mytype = struct type threeDim = { x: float; y: float; z: float} end"
<orbitz>
so you have Mytype.Mytype.threeDim ?
<ikatz>
main.ml is "include Mytype let _ = let vect = {x = 1; y = 2; z = 3} in vect.x"
<ikatz>
well...
<ikatz>
if i remove the "module Mytype" and "end", main.ml works fine
<ikatz>
also, pretend that i wrote floats instead of ints for x, y, and z...
<ikatz>
so, is it just that you should never put type declarations inside a module?
<orbitz>
wha tif you do open Mytype?
<ikatz>
same thing
<ikatz>
Unbound record field label x
<orbitz>
what if you do open Mytype.Mytype ?
<ikatz>
Unbound module Mytype.Mtype
<ikatz>
that's what's confusing me the most
<orbitz>
wha tif you do
<orbitz>
module M = Mytype
<orbitz>
in the REPL
<ikatz>
oops... fixed
<orbitz>
?
<ikatz>
i tried to include "Mytype.Mtype" instead of "Mytype.Mytype" (missing "y")
<orbitz>
silly man
<orbitz>
does that solve your type issue?
<ikatz>
definitely
<orbitz>
its a crap solution though
<orbitz>
cuz it imports everythign
<ikatz>
well... i just tried it with includ
<ikatz>
that seems to work, the original problem was my typo
<orbitz>
i generally make consructors of my own anyways, not sure if tha tis the best way to do it
<orbitz>
myt maek Mytype.make
<orbitz>
or .create
<ikatz>
hmmm
<ikatz>
not a bad idea i guess
<orbitz>
unless tehr ei sa good reason for htem to be playing wih the type directly
yminsky_ has joined #ocaml
<ikatz>
so then you just do let foo = Mytype.make () with x = 3. ?
<orbitz>
if your record type is immutable, jus tmake Mytype.make a varaible
<orbitz>
if you need values, make make a funciton which takes them
<ikatz>
i can tell from your advise that i am probably writing this program in a weird way
<orbitz>
i'm not an ocaml expert so my advice could be poop
<ikatz>
ok :)
<orbitz>
you can poke around teh stdlib to get an idea of how it does this stuff
<ikatz>
yeah
<ikatz>
if this wasn't a throwaway school project i would take the time to do it nicer
<ikatz>
but i need to get this working by friday AM
<orbitz>
psh, it's monday!
<ikatz>
tuesday night
<ikatz>
little late to be starting a final project :)
<orbitz>
what's it do?
<ikatz>
AI project... planning the movements of a group of autonomous vehicles
<ikatz>
(simulated)
<ikatz>
they have a battery life that runs out... and the charging area is away from the guard area
<ikatz>
and they have some constraints on staying connected to their neighbors
<ikatz>
i'm working on the gui part right now
<ikatz>
hence the x y z
<ikatz>
man... you can tell i'm tired, that description sucked
<ikatz>
the vehicles have to watch one area but can only recharge in a separate area... so the trick is to plan the paths for the "changing of the guard"
<orbitz>
do you have to use hot keywrods like 'dynamic programming' to solve that?
<ikatz>
limited-horizon A* search
AxleLonghor1 has joined #ocaml
AxleLonghor1 has left #ocaml []
shortcircuit_ has joined #ocaml
shortcircuit has quit [Nick collision from services.]
shortcircuit has joined #ocaml
yminsky_ has quit []
shortcircuit has quit [Remote closed the connection]
shortcircuit_ has quit [Client Quit]
shortcircuit_ has joined #ocaml
<yangsx>
I've recompiled Stefano's debian packaging of core for amd64 and installed, but using it at the toplevel gives me a warning "Reference to undefined global 'Condition'"
<yangsx>
does anyone know where I can find the Condition module?
<ikatz>
not sure
<ikatz>
on my toplevel if i do "module C = Condiiton;;" i get the same erorr
<ikatz>
gentoo/i686
<ikatz>
what command gives you the error?
<yangsx>
I use #use "topfindj" and then #require "core"
<yangsx>
s/topfindj/topfind/
<ikatz>
use topfind works for me
<ikatz>
but i get "No such package: core" :(
shortcircuit_ has quit [Remote closed the connection]
hsuh has quit ["well bye"]
shortcircuit has joined #ocaml
mfp has quit [Read error: 104 (Connection reset by peer)]
<orbitz>
you probably need ot use ocamltop to create an interpreter with the threads lib
<flux>
ikatz, after #use "topfind";; do #thread;;?
<orbitz>
the thing is you need to make sure you specify if youa re usgin thread or vmthread
<orbitz>
i'm nto sure hwo to do that
goalieca_lappy has quit ["leaving"]
mfp has joined #ocaml
olleolleolle has joined #ocaml
Demitar has quit [Read error: 110 (Connection timed out)]
al-maisan has joined #ocaml
olleolleolle has quit []
Snark_ has joined #ocaml
Snark_ is now known as Snark
nuncanada has quit [Read error: 110 (Connection timed out)]
nuncanada has joined #ocaml
mbishop has quit [Read error: 113 (No route to host)]
mbishop has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
<gildor_>
ertai: ping
<palomer>
WOOT, it works!
olleolleolle has joined #ocaml
ikaros has joined #ocaml
al-maisan has quit [Remote closed the connection]
filp has joined #ocaml
Yoric[DT] has joined #ocaml
al-maisan has joined #ocaml
olleolleolle has left #ocaml []
Yoric[DT] has quit ["Ex-Chat"]
rby_ has joined #ocaml
rby_ is now known as rby
OChameau has joined #ocaml
seafood_ has quit []
RagDoll has joined #ocaml
<flux>
hm, just came to me: a trick to prevent accidental < and > (..and =): just put a functional value into your record..
<flux>
it's a shame one can't define that for your own types, unless they come from the C world
hkBst has joined #ocaml
jonafan_ has joined #ocaml
munga has joined #ocaml
jonafan has quit [Read error: 110 (Connection timed out)]
yangsx has quit [Read error: 110 (Connection timed out)]
jlouis has joined #ocaml
Linktim has joined #ocaml
jdrake has quit [Read error: 110 (Connection timed out)]
<al-maisan>
Linux u804 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
<al-maisan>
u804: core-0.5.0 $ ocamlc -v
<al-maisan>
The Objective Caml compiler, version 3.10.0
<al-maisan>
Standard library directory: /usr/lib/ocaml/3.10.0
Demitar has joined #ocaml
* Yoric[DT]
has seen something along these lines on the mailing-list.
<hcarty>
al-maisan: You need to get the other packages from the Jane St. site and install them first
<hcarty>
bin_prot is one of the packages
<al-maisan>
hcarty: ah, I see.
<al-maisan>
Thanks!
<hcarty>
Sure thing. I had the same problem when I tried to install Core
RobertFischer has joined #ocaml
<al-maisan>
hmm, when bulding bin-prot I run into the following error:
<al-maisan>
ld: nat0.o: No such file: No such file or directory
<al-maisan>
Error during partial linking
<hcarty>
There is a specific order everything has to be built in. Did you build type-conv first? I think everything else requires that.
<al-maisan>
hcarty: yes, I did build type-conv .. (make install)
<mfp>
has anybody compared bin-prot to Marshal speed-wise?
pango has quit [Remote closed the connection]
pango has joined #ocaml
Linktim_ has joined #ocaml
olleolleolle has left #ocaml []
Linktim- has joined #ocaml
rodge has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
AxleLonghorn has joined #ocaml
AxleLonghorn has left #ocaml []
<flux>
what does binprot do?
<flux>
the only thing I've learned about it is that it doesn't support both endianesses.. (sp?)
nuncanada has quit ["Leaving"]
<mfp>
type-safe marshalling with a binary protocol
<flux>
oh, ok, that's nice
<flux>
does it come with a syntax extension or just do it magic like marshal?
<mfp>
extension
<flux>
can you specify field-specific encodings?
<flux>
just wondering if it's any good to interface with already-existing binary protocols
<mfp>
I believe you cannot
<flux>
ok, so it's for fast clustering or something
<flux>
perhaps persistence
<mfp>
I've written a small extension myself that achieves something similar
<flux>
hm, I suppose sexplib could be ported to support any kind of encoding system..
<mfp>
type foo = .... with safe_marshal
<flux>
but otherwise, sexplib rules a lot.
<mfp>
it just computes a "type id" and saves it along with a hash of the marshalled data, then checks when deserializing, making Marshal.* ops safe
<flux>
so it uses Marshal underneath?
<mfp>
yes
<mfp>
but it's safe, since it checks both the type ID and that the data hasn't been corrupted
<mfp>
can be used for the same things as bin-prot, I guess, so I was wondering how bin-prot compared against Marshal in terms of speed
<flux>
should be pretty much the same, assuming the ids are calculated compile time?
<mfp>
speed and compactness being the main reasons to choose a binary protocol instead of e.g. sexplib or json-static
<flux>
and no undue copying is performed
<mfp>
the IDs are computed at module init time
<flux>
yeah, they have their use too.. luckily I don't have such needs, sexp has the advantage of being accessible with socat :)
<hcarty>
mfp: Is it safe across OCaml releases?
Linktim_ has quit [Read error: 110 (Connection timed out)]
<flux>
I've basically standardized info s-expressions as an IPC protocol, wrote a c++-library (with "pattern matching") for it too
<flux>
s/info/into/
<mfp>
hcarty: only to the same extent as Marshal
<hcarty>
I think that would be one benefit of bin-prot. The format should be stable across releases.
<mfp>
yes
<mfp>
has Marshal changed often in the past?
<mfp>
the manual only says "The format for the byte sequences is compatible across all machines for a given version of Objective Caml."
<mfp>
so I guess one benefit of Marshal is that it doesn't have an endianness issues :P
<hcarty>
Very true :-)
<mfp>
there are few references to Marshal in Changes
<mfp>
the most recent ones are: marshalling of objects in 3.08
<mfp>
3.04: - Pervasives.output_value and Marshal.to_* : improved hashing strategy for internal data structures, avoid excessive slowness on quasi-linearly-allocated inputs.
nysin has joined #ocaml
<mfp>
I guess the 3.04 one breaks compat (?)
RagDoll has quit ["Quitte"]
<mfp>
3.04 was released in late 2001, so, assuming that there's not something missing in Changes, the format hasn't changed in at least 6 years
<hcarty>
It would be nice if there were that kind of stability
Snark has quit [Remote closed the connection]
flux has quit [leguin.freenode.net irc.freenode.net]
bluestorm has joined #ocaml
Snark has joined #ocaml
flux has joined #ocaml
flx has joined #ocaml
flux has quit [Connection reset by peer]
flx is now known as flux
<Yoric[DT]>
Ok, first patch submitted to ExtLib.
<RobertFischer>
Yoric[DT]: And there was much rejoicing.
* Yoric[DT]
is rejoicing already.
<hcarty>
I don't know if this should go in ExtLib, Batteries or anywhere, but perhaps an Unsafe wrapper library would be useful?
<hcarty>
So open Unsafe would make Array.get in to Array.unsafe_get, etc
<bluestorm>
hmm
<hcarty>
This would, I think, be most useful with open ... in or Unsafe.( ... )
<bluestorm>
so the people wanting performance without much thinking would say "i open Unsafe and everything magically get faster" ? i don't buy it
<hcarty>
bluestorm: I don't think it is much worse than having -unsafe as a compilation option
<bluestorm>
(does -unsafe actually do something ?)
<hcarty>
If anything I think it is better, since it allows one to easily limit the scope of the unsafe functions
<hcarty>
Yes, it makes array.(index) mean Array.unsafe_(get|set) rather than Array.(get|set)
<hcarty>
Same with strings I believe
<hcarty>
So it turns off bounds checking for array.(i) and string.[i]
<hcarty>
I looked through the OCaml camlp4 syntax a year or so ago to see how that worked
<hcarty>
Just a thought though.
<hcarty>
let module Array = UnsafeArray in ... would probably work as well, so no syntax extension is required to limit the scope like this.
ikaros_ has joined #ocaml
ikaros has quit [Read error: 110 (Connection timed out)]
<orbitz>
with 'open' can you bring specific functions/datatypes from a module into the current scope or is it all or nothing?
<hcarty>
And it looks like Zheng Li beat me to a release :-) Hooray! Less work for me...
<hcarty>
orbitz: I believe it's all or nothing
<hcarty>
Though you could probably write a camlp4 extension to effectively bring only certain functions in to scope
<hcarty>
open Foo with [bar1; bar; bar3] or something like that
<hcarty>
Which would translate to let bar1 = Foo.bar1 let bar2 = Foo.bar2 let bar3 = Foo.bar3
<bluestorm>
from Foo open bar1 and bar2 and bar3 ?
<orbitz>
beign able to include or exclude would be cool
<orbitz>
maye i'll try to learn camlp4 for that and hope i dont' shoot myself inteh foot
<hcarty>
bluestorm: from Foo import bar1 and bar2 and bar3 perhaps?
<bluestorm>
sounds like python :-'
* orbitz
things the 'and' is a bit to verbose there
<hcarty>
Oh no!
<hcarty>
Forget I ever mentioned it
<bluestorm>
:D
<bluestorm>
but you have to be careful not to add too much new keywords
<orbitz>
open Foo include (bar1, bar2, bar3) or open Foo exclude (bar1, bar2, bar3)
<bluestorm>
(hm, exclude seems quite difficult to do syntaxically)
<flux>
well, commas would be so non-ocamlish
<orbitz>
not in tuple context...
<hcarty>
bluestorm: Yes, so perhaps open Foo with ... since open and with are already keywords?
<flux>
it's not really a tuple there?
<flux>
rather, a list
<flux>
and ocaml uses ; as a list separator
<bluestorm>
"open Foo with .." gives the idea that you open Foo _and_ add behavior after that
<hcarty>
Very good point
<bluestorm>
"in Foo open ..." would be better
<bluestorm>
(although "in" has a bit of "scope locality" taste)
<orbitz>
with Foo open ..
<flux>
hm, what is wrong with open Foo in expr, as implemented by pa_openin, or am I misunderstanding the issue?
<flux>
it's analoguous to let foo = 42 in .. which also brings something to scope (a binding 'foo' in this case)
<orbitz>
flux: i want to bring in only specific functions inot the current scope
<bluestorm>
flux: hcarty would like to import specific functions only
<flux>
open Foo(a; b) in expr then would be a logical next step?
<flux>
however I'm not sure how that can be implemented as a syntax extension neatly
<orbitz>
i think exclusion would be nice too
<flux>
I would think exclusion is bug-prone
<hcarty>
orbitz: I think bluestorm is right. Exclusion would be significantly more difficult to implement.
<orbitz>
yeah probably
<flux>
if the module you've imported gets added a new function, code can change elsewhere
<hcarty>
Inclusion does not require camlp4 to know anything about the module
<orbitz>
hcarty: and probaly not nearly as useful
<hcarty>
Exclusion does
<flux>
hcarty, what kind of transformation would you do?
<hcarty>
flux: For inclusion?
<flux>
hcarty, yeah
<hcarty>
What I wrote before:
<flux>
oh, right, just search/replace the symbol?
<hcarty>
Which would translate to let bar1 = Foo.bar1 let bar2 = Foo.bar2 let bar3 = Foo.bar3
<hcarty>
So camlp4 could remain completely ignorant of the contents of Foo
<orbitz>
at the top of the module
<hcarty>
If you try to import a function which does not exist in Foo, it would be a post-camlp4 compile time error
<orbitz>
open Module match [bar1; bar2; bar3]
<orbitz>
what about 'sig'? it kind of makes sense. you want to open a module but give it a new signature in doing so
<orbitz>
if you feel ok with your sig not being a true signature block
<bluestorm>
hmm
<orbitz>
open Module sig [bar1; bar2; bar3]
<flux>
open Module : sig val bar1; val bar2; end in would be very ocamlish, if not a bit syntax heavy
<flux>
and it could be surprising to the user how the block would not be a true signature
<bluestorm>
if that helps, you can already do include (List : sig val length : 'a list -> int)
pango has quit [Remote closed the connection]
<bluestorm>
... end
<flux>
bluestorm, yeah, but you cannot 'inherit' signatures
<flux>
it would be a nice feature in the language ;-)
<orbitz>
i'm ok with understanding that 'sig' there is really more of an abstract homage to what is goign on and not a true signature, but perhaps it's a slippery slope
<orbitz>
i think the idea of using 'sig' there in some way makes sense for what is being accomplished.
pango has joined #ocaml
al-maisan has quit ["Leaving."]
<Yoric[DT]>
hcarty: actually, Batteries should end up containing relatively little code.
<Yoric[DT]>
Most of the code I've written so far is going to end up submitted to ExtLib.
<Yoric[DT]>
And since thelema and I have agreed to share code, that's also true for Community Caml.
<Yoric[DT]>
So if you wish to submit Unsafe, either ExtLib, CoCa or Batteries should be fine.
<hcarty>
Yoric[DT]: Ok, thanks.
<Yoric[DT]>
Batteries will mostly be composed of glue between existing libraries.
petchema has quit [Remote closed the connection]
filp has quit ["Bye"]
petchema has joined #ocaml
<gildor_>
Yoric[DT]: sorry for the delay concerning git repository on forge
<gildor_>
Yoric[DT]: i am working on it
<Yoric[DT]>
No problem.
<Yoric[DT]>
No hurry.
<gildor_>
Yoric[DT]: but i wish to have something that integrate well with the forge
<Yoric[DT]>
I can understand that.
<gildor_>
unfortunately when you will want to use fully the git extension of the forge, you'll have to abandon SVN
<gildor_>
because you can only have one SCM per project
<bluestorm>
it fail on the extension compilation ?
<bluestorm>
(i thought it was a camlp4-time problem)
<rwmjones>
I don't know where the failure is, except it appears to happen when ocamlc.opt tries to allocate 34 GB
<rwmjones>
this happens when compiling camomile
<rwmjones>
but we've not got a nice small test case
* rwmjones
will post to caml-list
<flux>
would be a bug in the compiler, not camlp4, unless camlp4 produces something unreasonable?
<Yoric[DT]>
just compiling the stuff does not seem to cause any problem for me.
<bluestorm>
(just compiling the code you gave in http://pastebin.com/m4c0b1572 with your command line is perfectly fine on my computer)
<bluestorm>
(3.10.1)
<Yoric[DT]>
3.10.1 too
<rwmjones>
Yoric[DT], bluestorm, run the command over and over again (at least 100 times before I'd think you didn't have a problem)
<bluestorm>
ok
<Yoric[DT]>
ok
<rwmjones>
for i in `seq 1 100` ... :-)
<Yoric[DT]>
In progress :)
<petchema>
or for ((I=1; I <= 100; I++)) ...
<Yoric[DT]>
110, so far, so good
<Yoric[DT]>
190, so far, so good
<bluestorm>
(same)
<Yoric[DT]>
250, so far, so good
<Yoric[DT]>
should I continue ?
<rwmjones>
hmmmm .. wonder if it's a fedora thing
* Yoric[DT]
restarts with seq 1 2000.
<rwmjones>
unless you're running on a machine with > 34 GB of physical RAM, I guess you can stop :-)
<Yoric[DT]>
:)
<Yoric[DT]>
ok
<rwmjones>
for me it's about 1 in 10
<bluestorm>
cosmic rays :-'
<rwmjones>
the bug reporter says 1 in 3 for him
<Yoric[DT]>
I'm using Ubuntu, 2.6.22-14-generic SMP.
<rwmjones>
back in a bit
OChameau has quit ["Leaving"]
Linktim- has quit [Remote closed the connection]
Linktim- has joined #ocaml
<rwmjones>
Yoric[DT], not sure I understood your pm'd question
<rwmjones>
but
<rwmjones>
i'd rather we dropped UTF8 from extlib
<rwmjones>
& people who want to use camomile, should use it
<Yoric[DT]>
The problem is for people who want to submit patches to Camomile.
Linktim- has quit [Read error: 104 (Connection reset by peer)]
<Yoric[DT]>
If the maintainer is not responsive, it's problematic.
Linktim has joined #ocaml
smimou has quit [Read error: 110 (Connection timed out)]
smimou has joined #ocaml
filp has joined #ocaml
<rwmjones>
Yoric[DT], well we'll fork it, that's what open source is all about .. however it's not that stage yet, we need to find out if it's really true that upstream is non-responsive
rwmjones is now known as rwmjones_afk
<Yoric[DT]>
fair enough
<Yoric[DT]>
I haven't seen any e-mail from Yoriyuki Yamagata since april 2007, though.
* Yoric[DT]
is pushing for Berke to insist.
<jonafan>
unicode support is kinda important
det has quit [Read error: 110 (Connection timed out)]
Linktim_ has joined #ocaml
ygrek has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
LordMetroid has quit ["Leaving"]
<flux>
is there iconv support?
<flux>
(in the batteries lib, or in camomile)
<Yoric[DT]>
Not in batteries [yet].
<Yoric[DT]>
iirc, Camomile has that.
<Yoric[DT]>
It's a reimplementation, though.
<flux>
I suppose that has an advantage of working in windows with less fuzz..
<flux>
actually with my nntp2rss I'm still using perl's MIME::Words and Text::Iconv, works great :-)
<Yoric[DT]>
:)
RobertFischer has joined #ocaml
vpalle has joined #ocaml
al-maisan has joined #ocaml
OChameau has joined #ocaml
al-maisan has quit ["Leaving."]
jdrake has joined #ocaml
jdrake has quit [Read error: 110 (Connection timed out)]
jdrake has joined #ocaml
rodge has quit ["Leaving."]
nysin has quit ["Leaving"]
pango has quit [Remote closed the connection]
Snark has quit [Read error: 113 (No route to host)]
pango has joined #ocaml
bluestorm has quit [Remote closed the connection]
Linktim_ has quit [Remote closed the connection]
vpalle_ has joined #ocaml
hkBst has quit ["Konversation terminated!"]
vpalle has quit [Read error: 110 (Connection timed out)]
filp has quit ["Bye"]
ikaros_ has quit ["segfault"]
Yoric[DT] has quit [Remote closed the connection]
r0bby has quit [Connection timed out]
ygrek has quit [Remote closed the connection]
flux has quit [leguin.freenode.net irc.freenode.net]