monotonom has quit ["Don't talk to those who talk to themselves."]
skylan has joined #ocaml
cjohnson has quit [Read error: 110 (Connection timed out)]
cjohnson has joined #ocaml
yauz_ has joined #ocaml
yauz has quit [Read error: 110 (Connection timed out)]
kosmikus|away is now known as kosmikus
monotonom has joined #ocaml
GreyLensman has quit ["Leaving"]
kosmikus is now known as kosmikus|away
skylan has quit [Remote closed the connection]
skylan has joined #ocaml
vezenchio has quit ["With little power comes little responsibility"]
skylan has quit [Remote closed the connection]
Demitar has quit [Read error: 54 (Connection reset by peer)]
demitar_ has joined #ocaml
skylan has joined #ocaml
skylan has quit [Remote closed the connection]
skylan has joined #ocaml
skylan has quit [Remote closed the connection]
skylan has joined #ocaml
cjohnson has quit [Read error: 104 (Connection reset by peer)]
skylan has quit [Remote closed the connection]
skylan has joined #ocaml
kinners has joined #ocaml
Herrchen_ has joined #ocaml
Herrchen has quit [Read error: 110 (Connection timed out)]
jdrake_ has joined #ocaml
bk_ has joined #ocaml
bk_ has quit [Client Quit]
bk_ has joined #ocaml
<mflux>
jason, but, eventually, there is a hope ocaml compiler will learn more tricks and would eventually be optimize common cases of dynamic dispach into a simple function call of even inline it ;)
<mflux>
+able to
not_me2 has quit [Read error: 104 (Connection reset by peer)]
wax has joined #ocaml
kinners has quit [Read error: 110 (Connection timed out)]
wax has quit [Client Quit]
mrsolo has joined #ocaml
debona|r has joined #ocaml
bk_ has quit ["Leaving IRC - dircproxy 1.1.0"]
bk_ has joined #ocaml
debona|r has left #ocaml []
demitar_ is now known as Demitar
jdrake_ has quit ["Leaving"]
smimou has joined #ocaml
<mflux>
how "active" is ocaml's garbage collection? I'm just wondering how useful the weak pointers are for automatic memory management..
<mflux>
for example when viewing a huge file I could perhaps load all the visible lines to memory, and when invisible they would be referred only from a weak pointer array
<mflux>
b
<mflux>
but if that would lead to that only the visible lines would be in memory but the rest not, that arrangement would be of no use
<mflux>
now that I think of it there was some gc parameter that affected the behavior
jdrake has quit [Read error: 110 (Connection timed out)]
det has joined #ocaml
slashvar[lri] is now known as slashvar[ens]
<slashvar[ens]>
Yop
_fab has joined #ocaml
_fab has quit [Client Quit]
_fab has joined #ocaml
Herrchen_ is now known as Herrchen
Demitar has quit [Read error: 104 (Connection reset by peer)]
ita has joined #ocaml
Demitar has joined #ocaml
<ita>
hi all
<Herrchen>
moin
faramirr has joined #ocaml
<faramirr>
hi. what would be the caml equivalent to "#define" in c/c++ ? (i'd like to give meaningful names to integer constants representing the states of a state machine) ?
<mellum>
faramirr: type state = Foo | Bar | Baz
<faramirr>
ok thx
<ita>
faramirr: c++ equivalent is "static const int/bool .." etc
<ita>
faramirr: :)
<faramirr>
ok thx
<faramirr>
?
<Herrchen>
well the "type state = Foo | Bar | Baz" is more like "enum state = { Foo, Bar, Baz }"
<faramirr>
yeah that's what i thought
<faramirr>
that's ok for me
<Herrchen>
you can't do something like "type state = Foo | Bar | Baz;; let x : int = Foo"
<faramirr>
but just for my general culture: is there a #define equivalent?
<Herrchen>
well the advantage is btw type-checking :)
<Herrchen>
faramirr: you could use camlp4
<faramirr>
ok thx
<mflux>
how would let a = 42 differ from a #define in ocaml anyway, atleast in theory?-)
<Herrchen>
#define is preprocessor, camlp4 does preprocessing
<Herrchen>
the difference is that camlp4 does syntactic preprocessing
<Herrchen>
mflux: in theory? you can't type something like match a -> foo | _ -> bar
<mellum>
Using a preprocessor to define constants is idiotic. Just because you need to do that in C doesn't imply it would be even remotely a good idea in another language.
<faramirr>
you don't need to do that in c, there's const for constants. however, there are situations where you use #define
<faramirr>
does macros too
<mflux>
herrchen, well yes, I was considering it only for the case of a constant
<faramirr>
and has no syntactic implications
<mellum>
faramirr: You do need to do that in C, because you can't use const values as array sized
<faramirr>
?
<mellum>
s,sized,sizes,
<faramirr>
oh ok
<mellum>
Otherwise, macros are mostly used to define inline functions, which you don't need in Ocaml either because the compiler is clever enough to do inlining itself
<faramirr>
well, c compilers do that too
<mellum>
faramirr: C89 ones don't.
<mellum>
well, at least they don't have the "inline" keyword.
<faramirr>
ok ok, i just mean: modern compilers do
<faramirr>
and not just when implicitely ordered by an "inline" keyword
<faramirr>
s/implicitely/explicitely/g
<mellum>
Anyway, my point is that there is ususally no reason to use a preprocessor in Ocaml
<faramirr>
ahm sorry, i guess i must say here: match what_i_just_said with
<faramirr>
implicitely -> explicitely
<faramirr>
mellum, ok
<ita>
yeehah i finally made a working makefile for my project
<Herrchen>
well camlp4 can be very handy
<Herrchen>
if you have constructs and you want to have some shortcut notation for them
<Herrchen>
e.g. you implemented monads and now want something like the do notation of haskell
<Herrchen>
but as with most powerful tools they can be used to do very bad things
<Herrchen>
like a preprocessor exchanging the meaning of 0 and 1 or some other evil stuff
<Herrchen>
but in general if you have states you want to identify it is very wise to use "type state = State1 | State2 | ..." for other reasons than "preprocessor is evil"
<Herrchen>
ocaml ensures you get only valid values - using #define of integers in C doesn't ensure this ...
vezenchio has joined #ocaml
<ita>
the c preprocessor rocks - that's my favourite section in the iocc contest
mrsolo has quit [Read error: 60 (Operation timed out)]
jdrake has joined #ocaml
debona|r has left #ocaml []
GreyLensman has quit ["Leaving"]
whee has joined #ocaml
maihem has joined #ocaml
cjohnson has joined #ocaml
cjohnson has quit [Read error: 104 (Connection reset by peer)]
karryall has quit ["tcho"]
zigong has joined #ocaml
<mflux>
hmm.. what happens if I modify a hash in Hashtbl.iter?
<mellum>
mflux: Probably weird things
<mellum>
If for example this triggers a rehash, you'd still be walking the old version
zigong has quit [Read error: 104 (Connection reset by peer)]
<mflux>
so, in other few words, that hasn't been taken into account?-)
<Riastradh>
In other words: don't.
<cDlm>
robust iterators are difficult
<cDlm>
if you add an element to the collection, do you want to walk it ?
<Riastradh>
No, trivial. Hashtbl.iter could just lock the hash table.
<cDlm>
i meant 'robust to collection change'
<cDlm>
locking or copying the collection is cheating :)
GreyLensman has joined #ocaml
<mflux>
well, a lock would be nice, better to have defined behavior even if it meant a runtime error
<ronwalf>
have you tried?
<mellum>
mflux: that would slow down things for normal use
<mflux>
ronwalf, no
<mflux>
mellum, one flag? not likely
<mflux>
(or use count)
<mellum>
mflux: It would be a waste of time in any way. The user does something silly, so something silly happens.
<mflux>
well yes, it's very unlikely user would do that and not notice it beforehand
<Smerdyakov>
Frobnication!
<jdrake>
can ocaml load code up during runtime that could provide different set of functions for certain types of objects? (in C++-like terms it might be loading up a dll to provide you with the class from which you create your objects).
<jason>
Modules.
<jason>
Oh, you mean shared libraries.
<jdrake>
more like them yes
<mellum>
jdrake: I think you can.
<mellum>
I never needed that, though.
<jdrake>
basically it is something like having a game that is set with certain rules, like this weapon does this much damage, your maximum warp speed is this, etc. But then those being able to be replaced by the user by creating a new module.
<jdrake>
the other option is to create a language for it, (or if there is a language that is written in ocaml...)
<jason>
Maybe use python bindings.
<jdrake>
has there ever been a scripting language written in ocaml?
<jason>
I'm not sure.
<Smerdyakov>
"Scripting languages" are such a bad idea.
<jdrake>
Smerdyakov, that is definitely not true, especially just for being such a broad statement
<Smerdyakov>
I think it definitely _is_ true.
<jason>
We should write all of our shell logic in ocaml.
<Smerdyakov>
Why should a language that works for most kind of development suddenly fall flat on its face when faced with trivial tasks?
<jason>
Because it's more general than the task it's being presented with.
<jason>
It's like using a blowtorch where you need to use a lighter.
<Smerdyakov>
We have well-designed enough languages today that can adapt to such tasks.
<jdrake>
Smerdyakov, maybe it is easier to provide the user with a few text files they can modify rather then ship an entire ocaml compiler with the program
<jason>
They can, just not as effectively in my humble opinion.
<Smerdyakov>
jdrake, everyone should have an OCaml compiler installed already.
<jason>
The idea is for the script not to have to be compiled.
<jdrake>
Smerdyakov, while possibly true, humourous at least, it isn't very practical
<Smerdyakov>
jason, why?
<jason>
A extensible logical statement without need of compilation.
<jason>
Because people don't want to recompile their bash profile every time they change their X server settings.
<Smerdyakov>
How would they necessarily even _notice_ any effects of adding an extra step?
<jason>
It does what it needs to do.
<jason>
Becuase they need to open the file, edit the source code, and then recompile it?
<jason>
..
<Smerdyakov>
Why would they need to recompile it? Why can't that be done automatically as needed?
<jason>
Because it isn't done automatically as needed.
<jdrake>
jason, not always true, python does it automatically as do many mature scripting languages
<jason>
We're using Linux here.
<Smerdyakov>
I don't see the relevance.
<Smerdyakov>
I'm talking about the way things _should_ be done, not how they _are_ done now.
<jason>
jdrake: Via an interpreter statement at the beginning of the file, true.
<jason>
Then again, Python is more oriented at being a systems scripting language than Ocaml is.
<Smerdyakov>
Yet OCaml is better at being a systems scripting language!
<jdrake>
Smerdyakov, do you know if ocaml can do what I want, or bend what I need to the will of ocaml while providing the same ease
<Smerdyakov>
jdrake, what do you want?
<jason>
Smerdyakov: I'm not so sure about that. The nature of systems is imperitive.
<jason>
Right, as an afterthought. They strongly advise against actively using imperitive features commonly.
<jason>
The idea was to make it practical.
<jason>
I think Ocaml is far more suited towards getting away from all of the underlying problems that plague systems programming.
<jason>
I wouldn't want to taint the language with this type of work, or being oriented at it.
<Smerdyakov>
Nonsense. OCaml is one of the leading options today for writing the bulk of an operating system.
<jason>
I think it serves Ocaml much better to remove it from systems programming.
<monotonom>
I think it is fair to say that roughly you need states 20% of the time.
<jdrake>
this is a theoretical design right now, so bear with me. There will be classes of things such as starship hulls, components such as weapons and engines, etc. The classes will include functionality for the game engine to retrieve values from objects instantiated into the system. Such as how fast a ship can go, how far planetary scanners can see, etc. This functionality I would like to place in something loadable at ru
<jdrake>
ntime so that a user could make a new module with an entirely new ruleset.
<jason>
jdrake: There are python bindings available, I think this would be at least an option.
<Smerdyakov>
jdrake, do you expect there to be actual _programs_ for these things? Or is it just basically on par with entries in a relational database?
<jason>
Right, if you can change the functionality based on data provided, that would be much better.
<jdrake>
Smerdyakov, for the basic entries the latter is true, but actual 'programs' (functions) providing more than just data, i.e. deriving values from other values will be required.
<jdrake>
in most cases it is a fancy expression taking data from different areas of the system
<Smerdyakov>
jdrake, and you don't consider it a viable option to recompile the game when the settings change?
<jdrake>
Smerdyakov, i may not want to distribute the actual source code to the game
<mflux>
isn't Dynlink-module exactly suitable for this?
<jason>
I think Ocaml requires strict type checking when linking with a foreign piece of code. This would, I imagine, be something difficult to achieve with shared objects.
<jdrake>
mflux, that is for C code from the looks of it
<jason>
I sent him a link to that mflux.
<jdrake>
jason, ada does this quite easily from my reading
<jdrake>
Smerdyakov, i can certainly do that, but I would prefer to *eventually* have it loaded at runtime.
<mflux>
if the game is written in ocaml, it would really seem like logical approach to write the extensions in ocaml too
<jdrake>
this isn't a make or break issue with using ocaml or anything, just want to know if ocaml could do this
<jdrake>
mflux, exactly
<Smerdyakov>
jdrake, people seem to be telling you about a library you should use....