cjeris changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/
malune__ has joined #ocaml
descender has joined #ocaml
ed-t8 has joined #ocaml
malune_ has quit [Read error: 110 (Connection timed out)]
malune__ has quit [Read error: 110 (Connection timed out)]
mikeX has quit ["leaving"]
benny has joined #ocaml
benny_ has quit [Read error: 60 (Operation timed out)]
Demitar_ has joined #ocaml
pantsd has joined #ocaml
sourcerror_ has joined #ocaml
sourcerror has quit [Read error: 110 (Connection timed out)]
Associat0r has joined #ocaml
_blackdog has quit [Remote closed the connection]
LeCamarade has joined #ocaml
desertbot has joined #ocaml
<LeCamarade>
@bot Are you alive?
<LeCamarade>
@bot
* LeCamarade
has messed with the modules and could have killed them. Taking desertbot to #ocaml-desertbot for now.
desertbot has quit [Remote closed the connection]
Smerdyakov has quit ["Leaving"]
mnemonic has quit ["leaving"]
moglum has joined #ocaml
moglum has quit []
desertbot has joined #ocaml
<LeCamarade>
@bot
<desertbot>
O, Caml.
<LeCamarade>
@uptime
<desertbot>
Uptime: 30 seconds
<mrvn>
I think the customary trigger is ! and not @
<LeCamarade>
mrvn: It can change rather easily. I was copying the one that lambdabot (of #haskell) normally uses. A module maaaay implement as many as it wants :oD
<LeCamarade>
The @bot and @uptime modules use @. I should allow ? and ! in them, as well.
<mrvn>
I wonder how difficult it would be to build an ocaml sandbox so one could let the bot execute ocaml statements.
<LeCamarade>
mrvn: It is the next on the to-do. Shouldn't be too difficult.
<LeCamarade>
I'll pass OCaml one statement at a time. If I find that too problematic, I'll write a wrapper script. It's not like we are dying for performance.
<LeCamarade>
I'm thinking of forcing evaluation of all statements that end in ;;
<LeCamarade>
So that one need not mark out statements for evaluation, but act like it is the REPL still.
<LeCamarade>
print_endline "Hello, World!";;
<LeCamarade>
<desertbot> Hello, World!
<mrvn>
The problem is that you should sandbox it properly so one can't call Unix.system "rm -rf /"
<LeCamarade>
mrvn: Yeah.
<LeCamarade>
I am thinking of opening that stuff with altered env vars and streams and permissions ... I don't know. I'll see.
<LeCamarade>
I'll be very careful, but over-limiting it may kill its utility, so I'll be thinking it over.
Submarine has quit ["Leaving"]
pantsd has quit ["Leaving."]
kolmodin has joined #ocaml
<LeCamarade>
@bot
<desertbot>
Brought to you by OCaml v3.09.2
<Associat0r>
guys can ocaml be used as a systems programming languge replacing C++?
<flux>
mrvn, I think the best approach would be to build a new toplevel, that wouldn't support 'evil' libraries
<flux>
I'm not sure how one can disable declaring extern functions though; maybe it requires more patching
<LeCamarade>
flux: Can't I just cripple the permissions of the process? (Not that I'm too sure how to get that done ...)
jlouis has quit ["Leaving"]
LeCamarade is now known as LeCamarade```
LeCamarade``` is now known as LeCamarade`Gone
malune_ has joined #ocaml
smimou has joined #ocaml
<LeCamarade`Gone>
bringert: You wrote HOJ?
pantsd has joined #ocaml
<mrvn>
Associat0r: C++ isn't a systems programming language as such
<mrvn>
)or so most people feel)
<flux>
lecamarade`gone, yeah, by using chroot
<flux>
and by using process limits
<LeCamarade`Gone>
mrvn: Better at it than C, if you avoid the fancy stuff. Just using constructors/destructors and genericity, it beats the life out of C.
<mrvn>
You can become nobody:nogroup. That limits your power a lot already. But there is still plenty evil left to do.
<flux>
mrvn, not a good idea really. ther emight already be other processes running as nobody:nogroup, and using that would allow sending signals to them
<mrvn>
LeCamarade`Gone: C is a generic assembler. Perfect for system programming.
<LeCamarade`Gone>
Yeah, I was thinking of running stuff as nobody and chrooting.
<flux>
such as kill -9 -1 (kill all processes being run by nobody)
<LeCamarade`Gone>
And not linking unix.cma
<LeCamarade`Gone>
:oD
<mrvn>
flux: "plenty evil left to do"
<LeCamarade`Gone>
Nobody really needs unix.cma for bot expressions.
<mrvn>
I would build a new toplevel without Unix, processes and file I/O.
<flux>
mrvn, how about the extern-keyword?
<mrvn>
Also maybe some limitation on the execution time of a command.
<flux>
although perhaps it is too difficult to use 'extern' if you don't have actual ocaml-backend code to use it with
<flux>
s/use/exploit/
<mrvn>
flux: how would you get the files onto the server to load? But it is probably best to drop the load command
<mrvn>
does the toplevel accept extern? What does it do with it?
<flux>
mrvn, you would use code already linked in
<mrvn>
flux: I would expect already linked in code to be already declared extern for the toplevel. For the bot that is.
<flux>
mrvn, yeah but for example libc is linked in..
<mrvn>
But if I declare for example open extern all I get is a segfault I bet.
<mrvn>
Without the proper stubs it would be hard to use the functions. You would need some Obj.magic evilness.
<flux>
hmm, actually you can't refer to libc functions
<flux>
I tried external do_unlink : string -> int = "unlink" but it says it's not available
<flux>
so I suppose it might be safe
<mrvn>
the extern keyword just doesn't make sense for the bot. leave it out.
<LeCamarade`Gone>
Ordinarily, I don't see processes running by nobody.
ed-t8 has quit [Read error: 110 (Connection timed out)]
<flux>
Obj.magic is simply: external magic : 'a -> 'b = "%identity" ?
<LeCamarade`Gone>
Not that it should be okay to nuke them.
<mrvn>
flux: Obj.magic specifically just tells the type system that the type matches no matter what it thinks. :)
<mrvn>
More generaly the Obj module would allow you to write stub code to access native C functions.
* LeCamarade`Gone
is supposed to be gone ...
<flux>
I think the external -keyword might allow something that might be surprising, and should be disabled, if possible
<mrvn>
The Obj module too as it is trivial to create a segfault with it.
<flux>
after dropping that and (many) modules (including Obj) ocaml should be quite safe
<Associat0r>
mrvn : LeCamarade`Gone so can OCaml be used a a sys language?
<mrvn>
Associat0r: sure it can. But do you think it is wise to write an OS with a garbage collector? At least when you add swap support you are in big trouble performance wise.
<Associat0r>
so no way to disable GC?
<LeCamarade`Gone>
Associat0r: It doesn't expose the bare metal enough, but maybe it can. C++ exposes it like C.
<flux>
ghc has explicit memory allocation (for using C), I can't see why similar support couldn't be used in ocaml too
<Associat0r>
and what about device drivers?
<mrvn>
LeCamarade`Gone: you would use extern C code for that
<mrvn>
Associat0r: ^^
<flux>
also there is the hOp-project, an OS written in haskell
<mrvn>
or asm directly for even finer control
<LeCamarade`Gone>
mrvn: And then you'd be using C, not OCaml.
<mrvn>
People have written OSes in Ocaml, Haskel, scheme, ml, java. For every language you will find some nut who wrote some OS in it.
<mrvn>
You won't get around using some C and/or asm. You can't access processor registers and such from ocaml.
<Associat0r>
ok thanks for the answer
<flux>
well, you can't access processor registers from C either. you can access them from a language that is extended from C, though, such as the language implemented by gcc
<mrvn>
Associat0r: I've been thinking of writing a subset of ocaml that doesn't use a GC but it is very hard or limiting.
<Associat0r>
I am using C++ but am looking for a language to replace it I was thinking about D or ocaml
<Associat0r>
I think I will go for D then
<mrvn>
Associat0r: The parts that you have in C++ you can write in ocaml as well. But you will have more there.
<LeCamarade`Gone>
Associat0r: Are device drivers on your TODO?
<Associat0r>
no but I like jack of all trade languages
<mrvn>
You need asm code to boot, to setup the cpu descriptor tables, the interrupt handler and so on.
<LeCamarade`Gone>
Associat0r: A JAck-of-all-Trades is a very, very bad idea.
<Associat0r>
I want to learn a language that I know could do it even though I won't do it
<mrvn>
The really arch specific and core stuff. After that you can go into ocaml mode if you like,.
<Associat0r>
I know some ASM
<Associat0r>
and did some gfx coding
<mrvn>
Associat0r: Do you know xen?
<Associat0r>
xen source?
<Associat0r>
that vmware kinda thing?
<mrvn>
yes.
<Associat0r>
OS level VM
<Associat0r>
never used it but heard of it
<LeCamarade`Gone>
Associat0r: Do OCaml, knowing you can write C extensions when you need them. Plus, no language should be used because you may one day need to write a bootloader.
<LeCamarade`Gone>
We'd be using ASM.
<mrvn>
I think the way to go is to write the OS for a virtualization. That way you only need to suport the virtual console, virtual disk and virtual network device and you have a fully working OS:
<LeCamarade`Gone>
Me, I think to use C for anything other OS and interpreters is wrong. Nobody needs to be managing memory like that.
<mrvn>
Plus you can run linux normaly and boot up the toy OS as virtual instances without closing your editor and such.
<Associat0r>
LeCamarade`Gone : games and simulations need deterministic mem control
<mrvn>
Associat0r: not really.
<Associat0r>
well it is not needed but is very wise todo so
<mrvn>
not at all imho
<mrvn>
I think ocaml would excell at AIs for games. The algorithms needed for AIs can be written much nicer.
<Associat0r>
true
<mrvn>
And you don't have memory leaks or segfaults in it.
<LeCamarade`Gone>
Associat0r: Games are interpreters of some, at some point, and the load is wise to put on the programmer. But the mundane stuff? No.
<mrvn>
What ocaml isn't good at I think is the graphical interface. GUIs are majorly imperative.
<LeCamarade`Gone>
mrvn: not false;;
<mrvn>
:)
<mrvn>
Associat0r: Bluepunkt did write the OS for one of their car stereos in ML and had an university proof the code for correctness. When you build a few million of the radios you don't want them to crash. Just as an example.
<Associat0r>
good
<LeCamarade`Gone>
mrvn: You know, this whole QuickCheck business ... I didn't know about it until I did Haskell, where they emphasise.
<LeCamarade`Gone>
s/\./ it./
<LeCamarade`Gone>
Now, I think it should be built into syntces and (compilers, or at least IDEs).
<mrvn>
-- MARK --
<mrvn>
slow day today
<LeCamarade`Gone>
mrvn: I like it like this.
sourcerror_ has quit [Read error: 110 (Connection timed out)]
sourcerror_ has joined #ocaml
ita|zzz is now known as ita
<LeCamarade`Gone>
I must confess I have never come to stop missing the fact that Haskell strings are Char lists, and the sheer power than gives me with strings (all of the very nifty list funcs). Never.
* LeCamarade`Gone
hates OCamls strings and their String library.
<mrvn>
Doesn't that make a.[x] rather slow?
<LeCamarade`Gone>
Maybe I'm justbrain-washed.
<LeCamarade`Gone>
mrvn: Yes, it does.
<LeCamarade`Gone>
O(l)
<mrvn>
You can alway convert strings into char lists or streams.
<LeCamarade`Gone>
For string-heavy stuff, there is Bytestring.
<mrvn>
What I miss is String.to_list and String.from_list.
<LeCamarade`Gone>
And the list functions are just an obscene display of sheer functional power. Almost like gods, each of them.
<LeCamarade`Gone>
mrvn: Exactly. And some list funcs that I don't want to keep re-inventing.
<LeCamarade`Gone>
But after a lot Haskell, I think of strings as lists (and process them thus), hence never benefitting from their imperative speed.
<mrvn>
I actualy use char lists quite often for simple toy programs. like a toy interactive calculator.
<mrvn>
Easier to do recursive parsin on char lists than on strings.
<mrvn>
s/parsin/parsing/
<LeCamarade`Gone>
mrvn: I just don't write non-recursive looping procedures, so strings become tricky.
<LeCamarade`Gone>
Self-inflicted pain.
<mrvn>
let rec loop = function i when i >= String.length s -> () | i -> do_something s.[i]; loop (i+1)
<mrvn>
or similar constructs
mikeX has joined #ocaml
_blackdog has joined #ocaml
slipstream-- has joined #ocaml
postalchris has joined #ocaml
slipstream has quit [Connection timed out]
slipstream-- has quit [Read error: 104 (Connection reset by peer)]
slipstream has joined #ocaml
Demitar_ has quit [Connection timed out]
Demitar_ has joined #ocaml
postalchris has quit [Remote closed the connection]
romanoffi has quit [Read error: 113 (No route to host)]
sp311ch3ck has joined #ocaml
sp311ch3ck has quit [Client Quit]
Demitar_ has quit ["Ex-Chat"]
Demitar has quit [Read error: 113 (No route to host)]
Demitar has joined #ocaml
ygrek has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
moglum has joined #ocaml
<LeCamarade`Gone>
@bot
<desertbot>
:o)
<LeCamarade`Gone>
@bot
<desertbot>
ACTION dances ...
postalchris has joined #ocaml
pingamy has joined #ocaml
* LeCamarade`Gone
is testing IRC actions ...
<LeCamarade`Gone>
@bot
<desertbot>
:o)
<LeCamarade`Gone>
@bot
* desertbot
db dances ...
<LeCamarade`Gone>
ita: Relax. I'm moving. :oD
<ita>
LeCamarade`Gone: :-)
<LeCamarade`Gone>
Problem is that I have to terminate the daemon tomove it to #ocaml-desertbot
<LeCamarade`Gone>
@uptime
<desertbot>
Uptime: 9 hours, 29 minutes and 16 seconds
<LeCamarade`Gone>
The troubles of debugging on the fly. :o(
LeCamarade`Gone is now known as LeCamarade
ygrek has quit [Remote closed the connection]
pango has quit [Remote closed the connection]
pango has joined #ocaml
ygrek has joined #ocaml
ita is now known as ita|afk
Associat0r has quit [Read error: 104 (Connection reset by peer)]