dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dapz has joined #ocaml
racycle has quit [Quit: ZZZzzz…]
dapz has quit [Client Quit]
ygrek has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
Eyyub has joined #ocaml
tristero has quit [Quit: tristero]
philtor_ has quit [Ping timeout: 248 seconds]
WraithM has quit [Ping timeout: 272 seconds]
hhugo has quit [Quit: Leaving.]
darkf has quit [Read error: Connection reset by peer]
darkf has joined #ocaml
alexst has joined #ocaml
alexst has quit [Ping timeout: 240 seconds]
shinnya has quit [Ping timeout: 240 seconds]
jprakash has quit [Quit: leaving]
alexst has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
alexst has quit [Ping timeout: 248 seconds]
robink has quit [Remote host closed the connection]
robink has joined #ocaml
ygrek has joined #ocaml
philtor_ has joined #ocaml
penglingbo has joined #ocaml
robink has quit [Ping timeout: 240 seconds]
robink has joined #ocaml
distantunclebob has joined #ocaml
distantunclebob1 has joined #ocaml
alexst has joined #ocaml
distantunclebob has quit [Ping timeout: 256 seconds]
distantunclebob1 has quit [Ping timeout: 264 seconds]
distantunclebob has joined #ocaml
alexst has quit [Ping timeout: 256 seconds]
hausdorff has joined #ocaml
philtor_ has quit [Ping timeout: 240 seconds]
jao has quit [Ping timeout: 240 seconds]
tnguyen has quit [Ping timeout: 264 seconds]
tnguyen has joined #ocaml
racycle has joined #ocaml
philtor has quit [Ping timeout: 264 seconds]
alexst has joined #ocaml
alexst has quit [Ping timeout: 255 seconds]
yacks has quit [Ping timeout: 272 seconds]
yacks has joined #ocaml
clog has quit [Ping timeout: 240 seconds]
hausdorff has quit [Remote host closed the connection]
amiller_ is now known as amiller
amiller has quit [Changing host]
amiller has joined #ocaml
<BitPuffin>
where are the first class modules implemented in the compiler? trying to look at how it does the first class thingy
alpounet has joined #ocaml
hausdorff has joined #ocaml
racycle has quit [Quit: ZZZzzz…]
alexst has joined #ocaml
alexst has quit [Ping timeout: 240 seconds]
t4nk342 has joined #ocaml
siddharthv_away is now known as siddharthv
axiles has joined #ocaml
t4nk342 has quit [Ping timeout: 246 seconds]
clog has joined #ocaml
alexst has joined #ocaml
alexst has quit [Ping timeout: 240 seconds]
Eyyub has quit [Ping timeout: 240 seconds]
dapz has joined #ocaml
Hannibal_Smith has joined #ocaml
Antoine59 has quit [Ping timeout: 264 seconds]
Antoine59 has joined #ocaml
WraithM has joined #ocaml
ollehar has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
ollehar has quit [Ping timeout: 255 seconds]
alexst has joined #ocaml
alexst has quit [Ping timeout: 245 seconds]
parcs has quit [Ping timeout: 264 seconds]
eikke__ has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Hannibal_Smith has quit [Quit: Sto andando via]
parcs has joined #ocaml
Hannibal_Smith has joined #ocaml
ygrek has joined #ocaml
cago has joined #ocaml
thomasga has joined #ocaml
sgnb has joined #ocaml
thomasga has quit [Quit: Leaving.]
_0xAX has joined #ocaml
sagotch has joined #ocaml
hausdorff has quit [Remote host closed the connection]
Simn has joined #ocaml
thomasga has joined #ocaml
Kakadu has joined #ocaml
alexst has joined #ocaml
<def`>
_habnabit: open a issue on github or I'll forget about that :P
<def`>
BitPuffin: first class modules appear only in the frontend (mainly typing/*)
<def`>
BitPuffin: aftert that, they are turned into blocks (record of values, like a tuple where each field of the module is mapped to one field of the tuple) and disappear from the rest of the pipeline
<def`>
BitPuffin: the two parts dealing specifically with first class modules is packing and unpacking
<def`>
look for Pexp_pack in typing/typecore.ml and Pmod_unpack in typing/typemod.ml
alexst has quit [Ping timeout: 240 seconds]
<def`>
the rest is mostly syntax sugar. You might also be interested by coercions (grep module_coercion) which is not specific to first-class modules but turns a module from an arbitrary type to a subtype of it with the appropriate signature, and in this case is used to ensure that records generated during packing have the correct representation (otherwise, at runtime, there is no difference between first-class modules and normal modules)
<BitPuffin>
so for functions it is function pointers?
<BitPuffin>
in the block fields
<def`>
function pointers ~= not in the C-sense, it's closures
<BitPuffin>
or how does it work together with the polymorphism if it's not function pointers
<BitPuffin>
yeah okay
<def`>
which polymorphism ?
<BitPuffin>
so it's not static parameters
<BitPuffin>
the polymorphism of function parameters
<BitPuffin>
I mean static dispatch
<BitPuffin>
not static parameters
<def`>
:|
<def`>
Ocaml is parametric, there is no notion of dispatch associated to its polymorphism.
<BitPuffin>
hm
<BitPuffin>
well okay
<BitPuffin>
but it has to be some sort of dispatch going on behind the scenes
octachron has joined #ocaml
<def`>
When abstracting over a module, yeah, of course: just call the n-th field, where n is the position of the function called in the order of the signature
<BitPuffin>
and it's a closure
<BitPuffin>
so there is probably some performance overhead
<BitPuffin>
though
<BitPuffin>
maybe you can make some optimizations
<def`>
Maybe, maybe not. I feel this representation is a local optimum, and the performance overhead is completely negligible.
<BitPuffin>
well I mean there is probably performance differences between a function pointer, closure and just a static function
<def`>
(I mean… It's just one more word, while you are dealing with something really dynamic in its runtime nature (abstracting over a module)), focusing on this having an overhead is missing other problems in the design)
<def`>
But there is no such thing as function pointer in ocaml, nowhere.
<BitPuffin>
well
<BitPuffin>
I'm making kind of a systems programming ml
<BitPuffin>
so I do care about performance :P
<BitPuffin>
initially I was going to do it through parameterization, but then mrvn yelled at me
<ousado>
that's by implication saying the ocaml devs don't care about performance
<def`>
What I say is that won't bring you any kind of performance. I might of course be wrong and biased, but it's not the right objective.
<ousado>
which is nothing short of crazy
<def`>
The problem with static parametrization (generating shitload of code) is that it's not even expressive enough to be correct in all cases.
<BitPuffin>
def`: well I want to bring ml style guarantees into the area of systems programming. I will be using it personally for game engine development etc
<BitPuffin>
however I don't know if passing a bunch of function pointers around is all that great
<BitPuffin>
I mean it might be
<BitPuffin>
it's not like games aren't using function pointers behind the scenes anyways with C++ classes
<BitPuffin>
at least when they are virtual
<def`>
Be generic first, unless you wan't to restrict the language in weird ways, closures and parametric polymorphism (as in type erased) is the only way to handle all cases. Specialize only when you do need performance
<def`>
Otherwise you will have to put arbitrary restrictions (no recursion here, C++-template like staging, etc).
<BitPuffin>
oh I thought by generic first you meant do code generation first
<BitPuffin>
yeah so what I was thinking was to have both
<def`>
(sry, afk)
<BitPuffin>
basically you have type erased polymorphism but also allow parameterization when it's necessary
<def`>
But in this process you might lose regular representation, so this is quite intrusive in the rest of the code (you might have to define boundaries between generic data representation and specialized one)
<ousado>
you don't need it in the vast majority of cases
<BitPuffin>
yeah I think maybe specilization will be explicit
<ousado>
we have the same issue with the C target for haxe
<ousado>
it's not that bad
<BitPuffin>
or if the compiler is smart enough to see it as a win it could do it behind the scenes
<def`>
BitPuffin: I can't really tell anything about this article. There are way too much software engineers nowadays for any term to have a formal definition :)
<def`>
scientific term*
<BitPuffin>
yeah
<BitPuffin>
everything means so many different thing
<BitPuffin>
s
<BitPuffin>
like if you say functors
<BitPuffin>
you have to say do you mean functors as in bla? blu? or bleH?
<def`>
exactly
* def`
away
<BitPuffin>
I wonder if I can wrap pointers in some kind of maybe type. So if you free it it becomes none. That way enforcing with the type system that you deal with checking dereferences for "null". That said always checking can be wasteful so I dunno
<octachron>
BitPuffin: Have you looked at Rust? It does a lot of interesting thing with the notion of pointer and type safety.
<ousado>
or ATS
<BitPuffin>
octachron: yeah I'm drawing a lot of inspiration from rust actually. Just that rust did the horrible mistake of trying to be in the C family
<BitPuffin>
ATS?
<BitPuffin>
right now I'm only striving to get a usable 0.1 version that I can make a game in
<BitPuffin>
this means no boxes and no GC :P
<BitPuffin>
well I will probably never have a GC
<BitPuffin>
but yeah I will only have managed memory
<BitPuffin>
manually
pgomes has quit [Quit: Page closed]
pgomes has joined #ocaml
<octachron>
Making a game in your own language?.. Does it mean that you intend to write your own OpenGL bindings?
<BitPuffin>
octachron: hell yeah xD
<BitPuffin>
although, I might only bind the parts I use for the game
<BitPuffin>
I might not be calling every opengl function etc
Anarchos has joined #ocaml
divyanshu has joined #ocaml
<octachron>
A quite far-reaching objective. Good luck with that (and you will need it ).
<ousado>
BitPuffin: you might also want to look at felix
<companion_cube>
samebchase: too bad, use pattern matching then
<BitPuffin>
like I said, I'm not aiming to make a language that other people will use companion_cube. Which rust is
<companion_cube>
or another standard library :>
<BitPuffin>
ousado: felix seems pretty neat though
jludlam has joined #ocaml
<ousado>
ATS too
<companion_cube>
samebchase: "val value"
<companion_cube>
and value_exn
<samebchase>
So, when I do, open Core.Std the original OCaml stdlib 'Std' gets wiped?
<companion_cube>
awwww, opam-doc requires javascript? fuck that
<BitPuffin>
ousado: wasn't that the one that was similar to idris?
<companion_cube>
samebchase: yes
<samebchase>
companion_cube: thanks.
<companion_cube>
ATS is older than idris, and lower level
<octachron>
BitPuffin : You are also not trying to write your own kernel, which is a good point. But writing games and personal languages are two things that people seem to start a lot ... and seldom finish
<ousado>
BitPuffin: well, it's aimed at systems programming
<ousado>
but they probably learn a lot the further they get :)
<BitPuffin>
octachron: well, it's not so much that my game won't work if I use something else
<BitPuffin>
octachron: however I have greater plans that won't work in existing languages :)
<BitPuffin>
this 0.1 version of my language won't be anything near that though
<BitPuffin>
ATS sounds interesting
<BitPuffin>
will definitely draw inspiration from it
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
<companion_cube>
so what will your language do?
<BitPuffin>
octachron: It's also just my personality. I don't like using other people's game engines because I feel constrained and hate reading other people's code so open source engines wouldn't work even if they were up to snuff
<BitPuffin>
companion_cube: well one thing is to be able to use at least a subset of the language as scripting that will then automatically be able to be compiled into the release binary without code changes
Anarchos has joined #ocaml
<BitPuffin>
so prototype with lower performance and then release build with optimal performance
<BitPuffin>
and then it's stuff like when porting to other platforms being able to just port the function you use in your code base of a third party library without having to alter their headers and stuff
<BitPuffin>
basically swap out implementations
alexst has joined #ocaml
<companion_cube>
hmmm
<ousado>
sounds like dlopen to me
<BitPuffin>
dlopen requires code changes though
<BitPuffin>
unless you ifdef I guess
<BitPuffin>
but bleh
<BitPuffin>
companion_cube: also something that is extremely valuable for me is to not have to wait for the language author to get around to fixing my bugs etc would be nice. It's made worse because I hate reading other people's code. But it's even worse when even people who like reading other people's code find the codebase impossible to understand like with nimrod
AltGr has joined #ocaml
<BitPuffin>
So if I have control over most of the stack I'll only get stuck because of myself
alexst has quit [Ping timeout: 240 seconds]
<BitPuffin>
also when there is improvements I'd really like to have in the language nobody can reject it :D
<BitPuffin>
so there are many reasons
<companion_cube>
benevolent BitPuffin for life
<BitPuffin>
basically, many languages have some feature I really really want, but none of them have all
<BitPuffin>
exactly
ontologiae has quit [Ping timeout: 245 seconds]
<BitPuffin>
but yeah, my language will initially only be open source for resume reasons, not because any sane person should use it and expect me to fix bugs for them. Eventually though if the language becomes mature and I can write that big grand master plan game api I've been wanting to make to solve this whole game engines suck issue then I would start making it more appropriate for everyone
<BitPuffin>
but for now the language would never get done if other people were using it :) and I would never get a game done
<BitPuffin>
what I'm doing now is make a shitty first version of the language. Make a game and probably fix a few bugs here and there along the way. And repeat
<BitPuffin>
and it's not like i've been avoiding making my own language for quite some time now. I just don't see a better way forward :D
WraithM has quit [Ping timeout: 245 seconds]
hhugo has joined #ocaml
sagotch has quit [Remote host closed the connection]
<samebchase>
`for i = 1 to num do [...] done` in code like that, I'm getting unused var warnings for i. What's a better way of just repeating a certain computation n times.
<companion_cube>
for _i = 1 to num do ... done
sagotch has joined #ocaml
<samebchase>
ah. just like Rust. Actually the Rust method is just like OCaml.
<samebchase>
thanks.
<companion_cube>
or just use some iterator ;)
<BitPuffin>
why _i?
<companion_cube>
it means you can ignore the variable
<BitPuffin>
oh
<BitPuffin>
couldn't you just do for _ to 10 do ... done?
<BitPuffin>
I think I actually did that iirc
<BitPuffin>
or no hang on I was using the variable
<companion_cube>
might work
<ygrek>
will not currently
<companion_cube>
indeed, it expects a variable name and not a pattern
<whitequark>
"no language quite has all the features I want" is a really shitty reason to design a new one
thomasga has quit [Quit: Leaving.]
<companion_cube>
o/ whitequark
<BitPuffin>
whitequark: no? If you can't use any language without getting stopped from doing what you need to do then you need to make your own
<sagotch>
Is this issue a bug or not? A very simple example (< 25 lines with comments) here fails to compile: http://pastebin.com/MYiRpFBv
<BitPuffin>
it's like saying that it's bad buying a new computer for a certain piece of software that won't run on the machines you've already got
<whitequark>
it's never "stopped", it's always a barrier of some height. and making your own will more or less always be much higher
<BitPuffin>
and you plan to make a living on that software
<BitPuffin>
well, I don't necessarily think so if you are not making a language that will be used by others. Managing a community and fixing bugs that don't affect yourself eats time
<sagotch>
(type i and type s are probably useless in this example...)
<BitPuffin>
plus there is also more reasons
<BitPuffin>
like learning and stuff
<BitPuffin>
getting better insight to why programming languages suck
<companion_cube>
sagotch: looks like list_to_string isn't generalized enough
<companion_cube>
I don't know if it's a bug
<def`>
sagotch: you need polymorphic recursion
<def`>
in a recursive binding, it's not possible to generalize as much
<def`>
either write list_to_string separately
<def`>
(in a previous binding)
<def`>
or write: list_to string : 'a . ('a -> string) -> 'a list -> string = fun f l -> List.map f s |> String.concat ""
<sagotch>
hum
<sagotch>
I tried the second one
<sagotch>
It still failing
demonimin has quit [Ping timeout: 240 seconds]
<ousado>
BitPuffin: designing and implementing alone very likely eats more time and leads to worse results than making it a community effort
<ousado>
+it
<sagotch>
oups
alexst has joined #ocaml
<def`>
sagotch: "no" ?
<sagotch>
non sorry
<def`>
:)
<sagotch>
Okay thanks.
<sagotch>
btw, what is the meaning of the dot
<def`>
"forall"
<BitPuffin>
ousado: no it won't be a community effort
<def`>
'a 'b . … ~= forall 'a, forall 'b, …
<BitPuffin>
ah
<BitPuffin>
oh
<BitPuffin>
I read that wrong
<BitPuffin>
:)
<BitPuffin>
ousado: that's why I am making it iteratively
<BitPuffin>
ousado: and not bothering with self hosting and lame stuff like that
<sagotch>
and when do you write: type t . blabblabla? why not t . blablabla?
<def`>
sagotch: it would a bit more ambiguous
<BitPuffin>
ousado: so what I do is make a shitty, initial version of the language. Make a game using that and fix whatever bugs may show up. Then, break the hell out of the language and make another shitty version. Make another game with that. Tiny milestones, reckless with backwards compatability
alexst has quit [Ping timeout: 248 seconds]
<def`>
when reading "a b c", is it a type constructor or a potential forall binding ? you have to read the next token and check whether it is "." or not
<def`>
sagotch: but the syntax is bad, I agree :/
demonimin has joined #ocaml
<sagotch>
but with gadt you can not use `t . t gadt -> string`, but you need this `type t . ...`, what is the reason?
<def`>
sagotch: I told you, this is just syntactic.
<def`>
And the "type a" construction is reflected only at the expression level.
<ousado>
BitPuffin: I'd think that taking an existing language and modifying it to your needs is more likely to yield reasonable results
<ousado>
in a given time-frame
<BitPuffin>
ousado: you mean forking a language? or contributing
<ousado>
forking, since you don't want the community overhead
<BitPuffin>
yeah
<ousado>
but you also don't want to read code..
<BitPuffin>
however I think getting familiar with somebody elses codebase is much worse
<BitPuffin>
because there will be a long period where I am not feeling like I am making any progress
<BitPuffin>
so you get kind of depressed and give up
<ousado>
well, if it's a good code base, you can learn a lot
<BitPuffin>
sure
<BitPuffin>
I mean I will actually be reading some parts of other people's codebases
<BitPuffin>
to learn and pick up ideas on how to do stuff
<BitPuffin>
but it won't be like all of them
<BitPuffin>
mostly just grepping and asking where the implementation of something is defined
<BitPuffin>
but yeah it's also why I don't like using done game engines. I don't think it's productive to force an engine to be something it was not designed for. And the end result is a bit more bloated than I'd like
<sagotch>
def`: so, is `type` reserved for gadt? it is exactly the same behavior than writing `'a . ('a -> string) ...` but for gadts?
<ousado>
BitPuffin: designing a good language that's also very performant and (from what I've read here) almost as feature rich as ocaml is a lot of work
<ousado>
and if it's your first language, even more so
Antoine59 has quit [Ping timeout: 264 seconds]
<BitPuffin>
ousado: well the first version won't be very feature rich
<mrvn>
sagotch: 'a . ... means vor all 'a, type a . ... means for every a.
<ousado>
but you want to write a whole game in it
eikke__ has quit [Remote host closed the connection]
Hannibal_Smith has quit [Quit: Sto andando via]
<ousado>
that's nothing you really want to do in a language with a minimal feature set, I assume
<BitPuffin>
ousado: it will have functions and modules, and basic algebraic types with rudimentary pattern matching. And no way to do heap allocation other than manually managed memory.
<BitPuffin>
the modules will probably not be first class in that version even
<ousado>
ADTs with manual memory menagement?
<ousado>
*management
<BitPuffin>
yeah
<BitPuffin>
why not
<BitPuffin>
Rust does it
<Armael>
how will you handle function closures?
<ousado>
well, ATS does that too, using linear types
<sagotch>
mrvn: I do not get the difference between "for all 'a" and "for every a", it has the same meaning for me
<mrvn>
BitPuffin: because you quickyl get double free, memory leak, memory reuse and memory corruption bugs
<ousado>
why not -> debugging segfaults is nasty
<BitPuffin>
mrvn: huh?
ggole has joined #ocaml
<BitPuffin>
Armael: well, rust has closures and again, no GC. But I can't say how I'll handle everything until I actually handle it :P
hhugo has quit [Quit: Leaving.]
hhugo has joined #ocaml
<mrvn>
sagotch: "for all 'a" means the code has to work no matter what 'a is without regard what it is. "for every a" handles every case individually and specifically. That's why with a GATD the return type of a function can differ.
Antoine59 has joined #ocaml
<mrvn>
BitPuffin: with manual memory management people will screw it up
<BitPuffin>
mrvn: some people do
<BitPuffin>
but this language isn't designed for people
maattdd has joined #ocaml
<ousado>
I'd rather go for region inference or linear types in that case
<mrvn>
uhoh, skynet is designing its own language
<BitPuffin>
:P
<BitPuffin>
no I mean the language is only designed for one person
<BitPuffin>
not that I have never screwed up memory management before, but I have fixed it
<BitPuffin>
and I have learned
<BitPuffin>
really I mostly find GC a win when you are learning
<mrvn>
I would annotate types that can be heap allocated and types with garanteed and limited lifetime. The later can be default and the compiler would give an Error if it can't proof that the value does not escape its scope.
<BitPuffin>
and some nice features in some languages need it but yeah
dsheets has joined #ocaml
<BitPuffin>
mrvn: yeah that's what I'll be doing when I steal rusts boxes
<BitPuffin>
but initially I'll just have completely manual to keep things simple for the first version
dsheets has quit [Client Quit]
dsheets has joined #ocaml
<mrvn>
My idea for that is to have an allocator object with limited lifetime and you can pass that to functions needing dynamic memory. The compiler then has to proof that the values lifetime never exceeds the allocators and the allocator frees memory.
<BitPuffin>
and eventually the manual memory management might have to be explicitly inside an unsafe block or something. But not for now
<BitPuffin>
mrvn: so essentially you create a little mini GC variable
<BitPuffin>
that when it goes out of scope it gets killed and frees all its resources
<BitPuffin>
RAII GC in a box
<ousado>
that's basically region inference
<mrvn>
BitPuffin: doesn't have to be GC. the allocator could be strictly limited to a function. Like when you need to create some temporary lists and delete them before the function returns.
<ousado>
except being explicit
<mrvn>
ousado: yes. the compiler would do region interference to proof the annotations done by the user.
<BitPuffin>
mrvn: yeah, it's a function local explicit GC
<BitPuffin>
that terminates when the GC ends
<BitPuffin>
err
<BitPuffin>
function
<mrvn>
except it would never stop the world and never mark&sweep. It simply frees at the end.
<BitPuffin>
no
<BitPuffin>
ofc
<BitPuffin>
GC doesn't have to mean stop the world
<mrvn>
BitPuffin: show me one that never ever stops the world.
<BitPuffin>
for example nimrod's GC does reference counting per heap that doens't stop the world
<flux>
Erlang
<mrvn>
never ever stops the world?
<BitPuffin>
also does arc stop the world?
<BitPuffin>
mrvn: well "free" stops the world in a way doesn't it? :P
<mrvn>
BitPuffin: murky. Shouldn't stop other threads unless they call malloc/free at the same time.
<BitPuffin>
well that's what I mean
<flux>
so, it does?
<BitPuffin>
the GC in nimrod is per therad
<BitPuffin>
so it never stops another thread no
<mrvn>
Usualy even multi-core GCs sync themself against other cores. They stop the world for a bit to get ion sync.
<BitPuffin>
well it doesn't allow data sharing between threads
<BitPuffin>
unless you manually manage
<mrvn>
BitPuffin: what about values shared between threads?
<mrvn>
BitPuffin: ahh.
<whitequark>
mrvn: or as in erlang, you only have immutable data structures
<mrvn>
If you don't share data between threads then every thread is basically its own world.
<BitPuffin>
yeah
<BitPuffin>
exactly
<BitPuffin>
so no stop the world necessary
<BitPuffin>
there is channels and stuff though
<BitPuffin>
so you can copy over data
<flux>
so you pay a bit more in copying
<mrvn>
or every GC stops the world but there are many worlds.
<BitPuffin>
yeah
<flux>
and you could maybe share immutable data?
<BitPuffin>
just like "free" stops the world
<flux>
hmm, or maybe not
<BitPuffin>
flux: yeah I think so
<BitPuffin>
it will have effect tracking
<whitequark>
I'm also lost as to what kind of "game" BitPuffin is doing so manual memory management is imperative
<mrvn>
BitPuffin: free doesn't stop all threads, only can cause lock collisions
<sagotch>
mrvn: I think I finally get it, thank you.
<BitPuffin>
mrvn: no but what I mean is that free lives in each thread, so it stops the world of that free
<BitPuffin>
whitequark: the game doesn't necessarily need manual memory management but I can deal with it to have a simple initial version of my lang
<def`>
… I don't get it. free stops the world in the sense that every synchronous function stop the world until completed?
<whitequark>
BitPuffin: just slap Boehm over it and get memory safety rather cheaply
<mrvn>
def`: with stop the world I mean that no other thread can run usefull code. With free it only stops threads that happen to also run free
sagotch has quit [Remote host closed the connection]
<def`>
mrvn: ah right
<mrvn>
whitequark: Boem, like all speculative GCs, rather sucks.
<whitequark>
mrvn: more than manual MM? ;D
<BitPuffin>
manual MM is not even that hard, grow a pair ;)
<mrvn>
whitequark: yes. too much probability of taking an int/long for a pointer and leaking memory.
<def`>
BitPuffin: preferring manual management over GC is trading performance and throughput for some latency and determinism.
<whitequark>
BitPuffin: go take your condescension somewhere else
<def`>
given that a good gc can still be tweaked, it's hardly a win
<mrvn>
def`: at least single core a GC is amortized as fast as your usual malloc/free.
<BitPuffin>
whitequark: is it condescension if I think _you_ really could do manual MM? :P
<def`>
mrvn: faster :)
<whitequark>
the issue with manual MM is that (without linear types ala Rust) you're trading segfaults for a little slowdown
<mrvn>
def`: or even that. The only drawback of a GC is not being deterministic of when it frees.
<BitPuffin>
def`: you mean I get worse perf with manual MM o.O
<def`>
BitPuffin: mostly
<BitPuffin>
why?
<BitPuffin>
it depends on how you do it
<BitPuffin>
like where you allocate and where you free
<mrvn>
And you only need determinism for things like FDs. So give them a "close" function that you can manually call or let the GC call if you don't care.
<def`>
it always depend
<def`>
… that's not really an argument :P
<def`>
mrvn: latency is more of a problem
<ggole>
You can get great perf with manual allocation, but you have be careful and work at it
<BitPuffin>
if I really needed as much throughput as possible I could just allocate a big pool of memory from the start and write an internal allocator :P
<ggole>
Which is usually a waste of time.
<BitPuffin>
and get low lactency that way
<mrvn>
BitPuffin: that's what malloc/free does
<BitPuffin>
mrvn: yeah sure, but it's not deterministic
<mrvn>
BitPuffin: what? The time when YOU call close?
<BitPuffin>
what I mean is just decide that my whole process gets this amount of memory
<def`>
BitPuffin: you are not just getting more throughput, you are changing your allocation pattern. if the requirements change, the solution change of course
parcs has quit [Remote host closed the connection]
<BitPuffin>
or well there is many ways to go about it
parcs has joined #ocaml
<BitPuffin>
def`: yeah, I don't think I'd need to create an internal pool for this game, so I'm not that worried about the determinism
<mrvn>
def`: The only way to improve a GC or malloc/free is to utilize better knowledge of the allocation pattern.
<BitPuffin>
mrvn: I don't understand your question
<def`>
even with fine-tuned malloc on a realistic program, good luck beating a GC (for similar use cases)
<mrvn>
BitPuffin: what isn't deterministic?
<BitPuffin>
mrvn: mallo
<BitPuffin>
c
<mrvn>
BitPuffin: it's totaly deterministic, read the source. The problem is your allocation pattern isn't.
<BitPuffin>
well I guess it could vary from OS to OS. But usually it allocates chunks at a time so that it doesn't always have to ask the OS iirc
<BitPuffin>
so sometimes it will use uhh
<BitPuffin>
can't remember the name of the function
<ousado>
sbrk
<BitPuffin>
but the one that gets a chunk of memory from the OS :P
<flux>
I had an ocaml program which updated screen 30 fps and on each iteration, all the memory was discarded
<def`>
BitPuffin: mmap, brk, sbrk
<BitPuffin>
yea
<flux>
the GC took on the order of 40% CPU
<mrvn>
def`: It's easy if you have special knowledge. Like I will have a million 16 Byte objects that will collect over a few minutes and then all die at the same time. So I allocate 16MB and put them all in there.
agarwal1975 has quit [Quit: agarwal1975]
<flux>
with manual memory management I could have just allocated and discarded the whole buffer at a time
<flux>
with 0% overhead
<ggole>
No write barrier too
<ggole>
Handy when you are preallocating big arrays of stuff.
<mrvn>
flux: did you run Gc.minor () after every frame?
<def`>
good point for the write barrier
<whitequark>
flux: if the issue is buffers, you could, well, preallocate them
<flux>
I did GC tuning etc
<flux>
and it actualle enhanced the numbers a lot
<whitequark>
and reuse
<mrvn>
flux: yeah. if you have such specific and repeditive usage then nudgeing the GC at the right time works wonders.
<def`>
but then, your program use extremely regular data structure, not the complex arbitrary graph a GC deals with.
<flux>
and eventually it was fast enough.
<flux>
but still, much slower than it could have been with region inference gc :)
<BitPuffin>
mrvn: just like nudging free at the right time works wonders :P
alexst has joined #ocaml
<flux>
but the best thing about GC is that you don't have unspecified behavior
<flux>
so no random memory corruption etc.
<BitPuffin>
flux: I disagree, you don't know when the GC will free and stuff, so it sucks for most realtime purposes
<flux>
I wonder if I could have forked for each frame and discarded the process :)
<BitPuffin>
unless you are nimrod's GC
<BitPuffin>
or if you nudge it
<flux>
well, there are realtime purpose GCs that have bounded execution times
<BitPuffin>
but even when you nudge it it's hard
<BitPuffin>
yeah I know
ustunozgur has joined #ocaml
<flux>
but apparently they are not trivial to implement
<whitequark>
realtime GCs are hard and require a *lot* of tuning
<whitequark>
for your specific workload
ygrek has quit [Ping timeout: 240 seconds]
<whitequark>
or you could alternatively say "my only data type is a cell" a la lisp
<whitequark>
then it is easy and very efficient :p
<BitPuffin>
hmm
<ggole>
Except your program is now built out of cells
<BitPuffin>
haven't looked at how lisp does it
ygrek has joined #ocaml
<BitPuffin>
well
<BitPuffin>
not that I really care since I'll never have GC
<BitPuffin>
I'll only ever have boxed lifetime I think
<BitPuffin>
well I guess never say never
<BitPuffin>
there are things to learn from Justin Bieber amirite
<ggole>
(Common Lisp and Scheme have many other data types, so you can't get away with it anyway.)
<whitequark>
it's a cute little algorithm. a pity it's utterly inapplicable to real world
thomasga has joined #ocaml
<ggole>
That's the treadmill paper, right?
<ggole>
Yeah
<companion_cube>
flux: if literally all the memory is discarded each frame, you could call exec() ;)
<whitequark>
realtime on x86 userspace is a lie anyway
<whitequark>
you have unpredictable (due to multitasking) cache effects, OS scheduler, OS memory manager, SMM, cpufreq, ...
<BitPuffin>
but yeah hopefully I will be able to wrap pointers in some type fu that stops you from using a pointer that has been freed
<def`>
soft-realtime*
<BitPuffin>
even though I usually don't use free'd pointers :P
penglingbo has quit [Ping timeout: 240 seconds]
<BitPuffin>
whitequark: depends on the kernel
<BitPuffin>
well
<BitPuffin>
you can never get full realtime
<BitPuffin>
that's just a wet dream
<whitequark>
of course you can
<whitequark>
just not on typical x86 OSes
<BitPuffin>
or actually
<BitPuffin>
maybe that was on linux specifically that the talk I was watching once was talking about
<BitPuffin>
it was by a linux-rt guy
<samebchase>
I want to remove k values out of a hash-table, without having knowledge about the keys. What's the best way of doing this?
<whitequark>
linux-rt solves parts of that by 1) preallocating comm buffers 2) having RT tasks forcibly preempt everything and run in kernel space 3) disabling SMM and ACPI
<companion_cube>
samebchase: you mean any k values?
<whitequark>
and that's still not enough, you basically have to "measure" worst-case latency
<BitPuffin>
linux-rt will never be fully rt though
<samebchase>
any k values yeah
<companion_cube>
wow
<whitequark>
which means that it's still soft-rt
<BitPuffin>
well I don't know much about kernels
* companion_cube
doesn't see anything better than collecting all values and choosing k among them
<BitPuffin>
and I don't know much about RT operating systems
<BitPuffin>
what I know is that it means predictable
<whitequark>
it's easy to get hard-rt on something like cortex-m :p
<BitPuffin>
not super fast like some people think :P
<whitequark>
sure
<whitequark>
what I mean is that soft-rt is vague enough to be completely useless
<BitPuffin>
using linux-rt is probably quite useful when making games though
<whitequark>
really, saying that system X is soft-rt literally tells you nothing about it
<BitPuffin>
since it's very important to be able to accurately measure optimizations
<BitPuffin>
yeah
<whitequark>
BitPuffin: lol what? you keep using that word "game", I do not think it means what you think it means
<ousado>
whitequark: actually the linux audio folks will disagree about that point
<mrvn>
whitequark: So you assume every operation takes the worst time and you have your hard realtime bound.
<BitPuffin>
where do you draw the line with soft rt
<whitequark>
mrvn: the problem is that you don't have enough knowledge about your system to say what is the worst time
<whitequark>
ousado: which point?
<BitPuffin>
whitequark: huh? realtime 3d rendered virtual experiences
<ousado>
that soft-rt is vague enough to be completely useless
<mrvn>
whitequark: sure you do. every access causes a cache stall for example.
<samebchase>
companion_cube: I know how to iter over all the hash-table elts. There's no way of iter'ing over k of them?
<BitPuffin>
or do you want me to say game engine? because for me they are the same
<NoNNaN>
BitPuffin: take a look at linear typing, it's provide gcless performant code eg.: linearml binary tree is faster than optimized c solution
<mrvn>
whitequark: you will overshoot the actual time by some magnituides but you have your hard bound.
<companion_cube>
samebchase: you can iterate over the k first ones
<whitequark>
mrvn: now list me *every single reason* you can stall in a typical PC
* companion_cube
refrains from self-advertising
<BitPuffin>
NoNNaN: thanks, I will do
<samebchase>
companion_cube: one of your libs can do that?
<BitPuffin>
NoNNaN: do you know a good resource for reading about it?
<whitequark>
BitPuffin: I'm not aware of any game engine that comes even near hard-rt or even less requires kernel space
<mrvn>
whitequark: doesn't matter. there afaik is a maximum time for a memory access to finish.
<companion_cube>
samebchase: Sequence.hashtbl_keys tbl |> Sequence.take k |> Sequence.iter (fun k -> Hashtbl.remove tbl k) ?
<companion_cube>
something like this?
<BitPuffin>
whitequark: no games are soft realtime whatever that means
<mrvn>
whitequark: unless multi-core cpus can somehow starve one another.
<companion_cube>
it won't be random though
<samebchase>
companion_cube: WOW.
<companion_cube>
just the first k keys iterated on
<BitPuffin>
whitequark: but what I mean is, while designing your game engine, it is useful to be able to get somewhat accurate numbers when measuring performance
<whitequark>
mrvn: there's also pcie bus masters, and worst of all there's SMM
<samebchase>
I'll do that thanks.
<BitPuffin>
whitequark: hence using a realtime kernel might be useful
<ggole>
Why not Hashtbl.iter and raise Enough when you have k?
<whitequark>
BitPuffin: realtime kernel stops being realtime when you load 3D graphics drivers into it, though
<mrvn>
whitequark: but can they starve the cpu or is there bus time sharing?
<whitequark>
mrvn: SMM can steal control from you for an arbitrary amount of time at arbitrary points, it is not documented, and mostly it cannot be disabled
<samebchase>
could it be an older version that I'm using? I got it from OPAM
<companion_cube>
which version is it? opam info sequence
<companion_cube>
I do have Sequence.hashtbl_keys in utop, though
<samebchase>
0.4.1
<companion_cube>
it was already in this version though
isBEKaml_mobile has quit [Quit: Bye]
<BitPuffin>
NoNNaN: mincaml is not really functional though? since functions aren't first class
<BitPuffin>
or maybe they are
<BitPuffin>
just that they don't capture the environment
<companion_cube>
awww :(
<samebchase>
I have an open Core.Std;; followed by open Sequence;;
<samebchase>
at the top of the file.
<companion_cube>
if you just open utop, #require "sequence";; Sequence.hashtbl_keys;; ?
<companion_cube>
oh, right, there's Core.Sequence now I think
<BitPuffin>
to be honest I'm not even so sure about how much I'm a fan of closures. What I like about pure functions is that all the state is kept in the parameters, so it will always produce deterministic output. But when a function captures the environment then the output is dependent on the environment of that function. And then it's just as deterministic as calling a method on an object
<companion_cube>
in a file you can try module Seq = Sequence open Core.Std instead
<BitPuffin>
because in a sense the object is the environment
<companion_cube>
BitPuffin: without closures, functions like map or fold become almost useless
<samebchase>
companion_cube: okay. I'll try that
<BitPuffin>
companion_cube: no?
<BitPuffin>
I mean they are still recursive
<BitPuffin>
and they can do tail calls with they accumulators
<BitPuffin>
etc
<BitPuffin>
their*
<companion_cube>
well if you don't give a closure to map, it severly restrains the kind of things you can do with it
<BitPuffin>
companion_cube: you can still give it a function, doesnt have to be a closure
<companion_cube>
yes, but many functions you'd like to give to List.map are closures
<BitPuffin>
such as?
testcocoon has quit [Quit: Coyote finally caught me]
<companion_cube>
hmm, for instance I apply substitutions to lists of terms
<BitPuffin>
have map take an optional parameter of a tuple to pass to the mapped function :P
<companion_cube>
let apply_list subst l = List.map (apply_term subst) l
<companion_cube>
BitPuffin: that's called a closure
<companion_cube>
only you do it by hand
<companion_cube>
and it's painful
<BitPuffin>
sure, but it's not implecit
<companion_cube>
I'd rather have my usual lambda-calculus, thanks
<BitPuffin>
companion_cube: well a module and types, are objects, just that you do it by hand
<def`>
:D
alexst has joined #ocaml
<companion_cube>
no they aren't oO
<BitPuffin>
yes they are
<companion_cube>
modules don't do dynamic dispatch
<companion_cube>
nor are they supposed to do so
<BitPuffin>
a module that defines the data, and functions that process the data
<BitPuffin>
the data is the state
<BitPuffin>
the functions are the methods
<BitPuffin>
just that you take it as a parameter
<BitPuffin>
just like you would in C
<companion_cube>
"methods" implies a self-parameter
<BitPuffin>
yeah
<companion_cube>
also, modules don't have "state"
<BitPuffin>
just like in C :)
<BitPuffin>
no
<BitPuffin>
but the type it defines
<companion_cube>
in C I'd use a struct with functions inside
<BitPuffin>
is the state
<companion_cube>
a functional state? weird
<BitPuffin>
what you get when you call A.create
<def`>
a type is not a state wtf
<companion_cube>
OCaml does have objects
<companion_cube>
but modules aren't the objects
<BitPuffin>
def`: no but it contains the state
testcocoon has joined #ocaml
<BitPuffin>
it doesn't have to be state
<BitPuffin>
but it can
<BitPuffin>
so for example
<def`>
BitPuffin: that it is possible to encode a construct to another one is a relevant as saying that all turing complete languages are as expressive
<companion_cube>
if you want objects in OCaml, you have them granted. If you want closures in your hypothetical language, you have to encode them by hand
mort___ has quit [Quit: Leaving.]
<companion_cube>
that's a big difference
<BitPuffin>
module Pos type t = (int*int) let move (tx, ty) x y = (tx + x, ty +y) end
<BitPuffin>
and ofc a create function or something
alexst has quit [Ping timeout: 240 seconds]
<BitPuffin>
companion_cube: well no, what I mean is that you can emulate an object by hand in ocaml
<BitPuffin>
or in any language
<BitPuffin>
btw object doesn't have to mean dynamic dispatch
<companion_cube>
objects without dynamic dispatch are just functions+data ;)
<BitPuffin>
def`: well you don't understand what I'm arguing then. The point is that you can emulate objects "manually" even if you keep the data and functions separate, because you do it by hand. Just that the state is explicitly passed. Just like with what I said about closures they have the same dangerous property of state being implicitly passed available as well
<BitPuffin>
companion_cube: and they are still objects :)
<samebchase>
http://sprunge.us/ICKi?ocaml I'm getting strange type errors here. Can someone give me some hints as to how I can fix this?
<companion_cube>
if you want to see them as such
<companion_cube>
samebchase: aww, of course you're using Core
<companion_cube>
so it's just not the same hashtbl... -_-
<BitPuffin>
companion_cube: well you can also use an object as just data or a module by only having methods that take parameters
<BitPuffin>
anyways
<BitPuffin>
the point is
<BitPuffin>
you want to pass the data explicitly
<BitPuffin>
closures don't
<BitPuffin>
and I see that as potentially error prone
<companion_cube>
I want closures, thank you
<BitPuffin>
well why don't you like objects then? assuming you do
<BitPuffin>
n't
<companion_cube>
I don't need dynamic dispatch so modules are ok
<BitPuffin>
you obviously like state being implicitly available if you like closures
<companion_cube>
closures don't have state
<companion_cube>
they capture values
<BitPuffin>
I don't mean in ocaml
<companion_cube>
ah, in which language then?
<BitPuffin>
objects doesn't mean dynamic dispatch
<BitPuffin>
I mean in any language
<BitPuffin>
you can use objects without dynamic dispatch as well :P
<companion_cube>
I don't know that many languages that have proper closures
<companion_cube>
in languages with proper closures, I like closures
<BitPuffin>
say C++ for example, you can create a class that doesn't have virtual methods
<companion_cube>
and they don't capture "implicit state"
<samebchase>
companion_cube: oh. so there's no easy way of mixing these two libraries?
<BitPuffin>
companion_cube: the environment is implicit state
<companion_cube>
samebchase: you can use Hashtbl.iter or something like this, I guess
<companion_cube>
but it's less easy because Core has its own hashtbl basically
<companion_cube>
BitPuffin: the environnement is made of valuies
<companion_cube>
values
ygrek_ has quit [Ping timeout: 240 seconds]
<BitPuffin>
values that might be refs :)
<companion_cube>
a state that doesn't change isn't a state
<companion_cube>
a ref is still a value
<BitPuffin>
it could mutate it
<companion_cube>
that's the problem of the caller then
<ousado>
and a problem completely unrelated to closures
<BitPuffin>
so what I mean is. I write a function where I want to take a function. But I don't want it to mutate any state. However if someone sends me some function that does mutate state which I wanted to avoid
<BitPuffin>
then I'm screwed
<BitPuffin>
basically I can't control where side effects happen
<BitPuffin>
because that stupid kid Joe might write a crappy function that forces me to mutate :)
<companion_cube>
then you need an effect system, or monadic IO
<companion_cube>
but certainly not remove closures
<BitPuffin>
I don't know why it's bad to instead have some sort of sugar for what you want to pass to your function
<BitPuffin>
so that it is an explicit closure
<BitPuffin>
just that it's "expressive"
<def`>
"no"
<companion_cube>
how would that prevent Joe from mutating stuff?
<companion_cube>
what if the explicit closure captures references?
<BitPuffin>
companion_cube: I don't, but I don't want him to force me to mutate stuff
ustunozgur has quit [Remote host closed the connection]
<BitPuffin>
well then at least I'm making it more difficult for the guy :)
<companion_cube>
well if you write higher-order functions, you don't control what your functional arguments do
<companion_cube>
that's normal
<ousado>
also stupid kid joe can do anything he wants anyway
<BitPuffin>
sure
<companion_cube>
strange that you're such a control freak for a language you are going to write and usealone
<BitPuffin>
but I'm just saying that it feels just as bad as OOP
<companion_cube>
no it isn't
<companion_cube>
OOP is about tying state and functions together
<BitPuffin>
it isn't feels as bad as oop? :P
<companion_cube>
(unless you talk about the rare kind of OOP that is functional OOP)
<companion_cube>
(only met in OCaml, and maybe scala)
<ousado>
(and haxe)
<BitPuffin>
I'm talking OOP without dynamic dispatch
<companion_cube>
(maybe ^^)
<BitPuffin>
because that's lame
<def`>
BitPuffin: closing over a scope is orthogonal to OOP and languages with closure are more expressive (as in let f (x : 'a) (implicit M : T) = (x : M.t); ();;
<def`>
oops
<def`>
wrong window :D
<def`>
BitPuffin: closing over a scope is orthogonal to OOP and languages with closure are more expressive than those without
<BitPuffin>
well I agree that it is more expressive
<BitPuffin>
I'm just saying that I feel like it might have the same dangers
ustunozgur has joined #ocaml
<BitPuffin>
what I don't like about non pure functions is that it is harder to reason about, test, and proove that the output will always be correct. The implicit self parameter of methods cause this. And so does implicitly closing over a scope.
<BitPuffin>
So what I'm saying is that I am not sure I like closures, because they are not pure functions
<BitPuffin>
and not that anybody argued that they are. I am just saying why I am wary about them
<BitPuffin>
so instead it seems more proper (and efficient) to annotate which values of your environment will be available in your closure. Because then you are still pure and explicit.
<ousado>
you realize that you're saying (by implication) that haskell doesn't have closures?
<def`>
BitPuffin: closures are just a way to implement functions, it's unrelated to effects
<BitPuffin>
so here is just some bullshit syntax but say something like Something.map ~f:(fn {someval, someotherval} listitem -> listitem + someval, someotherval) list
<BitPuffin>
ousado: I don't know much haskell
sgnb has quit [Read error: Connection reset by peer]
<BitPuffin>
def`: well ignore side effects for now, I guess mega pure determinism is what I am asking for here
<ousado>
that closures are inherently impure is just wrong
<BitPuffin>
they are pure in the sense that they may not mutate. But they are not as deterministic. I mean sure you can read through thame and write a list of which variables they have available and use that to proove they have correct output
<BitPuffin>
but then you may as well look in a class for all their fields and use them to verify that they have the correct output
<BitPuffin>
but you're all biased to being in love with closures so I may as well be talking chinese right now :)
alexst has joined #ocaml
agarwal1975 has quit [Quit: agarwal1975]
huza has joined #ocaml
alexst has quit [Ping timeout: 240 seconds]
<zozozo>
parisyllabique
<zozozo>
woops
ygrek_ has joined #ocaml
agarwal1975 has joined #ocaml
divyanshu has quit [Quit: Computer has gone to sleep.]
ontologiae has joined #ocaml
maattdd has joined #ocaml
sgnb has joined #ocaml
penglingbo has joined #ocaml
darkf has quit [Quit: Leaving]
thomasga has joined #ocaml
divyanshu has joined #ocaml
<Drup>
BitPuffin: do you really want to encapsulate side effects ? :/
parcs has quit [Read error: Connection reset by peer]
alexst has joined #ocaml
ustunozgur has quit [Remote host closed the connection]
Eyyub has joined #ocaml
<adrien>
:D
shinnya has joined #ocaml
alexst has quit [Ping timeout: 240 seconds]
ustunozgur has joined #ocaml
tane has joined #ocaml
Eyyub has quit [Ping timeout: 264 seconds]
seanmcl has joined #ocaml
Anarchos has joined #ocaml
avsm has joined #ocaml
rand000 has joined #ocaml
parcs has joined #ocaml
racycle has joined #ocaml
alexst has joined #ocaml
maattdd has quit [Ping timeout: 256 seconds]
yacks has quit [Read error: Connection reset by peer]
alexst has quit [Ping timeout: 264 seconds]
yacks has joined #ocaml
<BitPuffin>
what?
racycle has quit [Quit: ZZZzzz…]
<BitPuffin>
Drup: encapsulate side effects?
rand000_ has joined #ocaml
rand000 has quit [Ping timeout: 248 seconds]
huza has quit [Ping timeout: 256 seconds]
<ousado>
how is structural subtying of objects implemented in ocaml?
<companion_cube>
you mean w.r.t typing, or implementation?
<ousado>
implementation
<ousado>
basically, how is field access determined
avsm has quit [Quit: Leaving.]
<companion_cube>
I think it's a dictionary lookup
<ousado>
ah, I see
<ousado>
thanks
wormphle1m has quit [Ping timeout: 252 seconds]
wormphlegm has joined #ocaml
tobiasBora has joined #ocaml
avsm has joined #ocaml
tobiasBora is now known as tobiasBora_
isBEKaml_mobile has joined #ocaml
tobiasBora_ is now known as tobiasBora__
tobiasBora__ has quit [Client Quit]
tobiasBora has joined #ocaml
tobiasBora has quit [Client Quit]
divyanshu has quit [Quit: Computer has gone to sleep.]
divyanshu has joined #ocaml
olauzon has joined #ocaml
mort___ has joined #ocaml
<def`>
ousado: since subtyping of values in ocaml has no runtime effects, the object carries a dictionary/hashtable of methods, with some type information being used:
<def`>
− method names are mapped to unique integers (using the same hashing scheme has polymorphic variants)
<def`>
− since we know a method will be present, the search only has to handle the positive case, and furthermore the list a method is statically known and integers are guaranteed not to colide
<ousado>
but you can have objects with a different order of fields that are coerced to the same type, right?
<def`>
so it's possible to generate reasonable efficient code. also, if I remember well, method implementations are cached at call-site
<def`>
ousado: there is no orders in objects
<def`>
you only expose methods in an ocaml object, not fields
<ousado>
oh
<ousado>
right, well, in haxe we call all of them fields
<ousado>
but it doesn't really matter, the dictionary is the mechanism I was after
<def`>
ok. in ocaml cases, every access to an object from outside goes through method
<companion_cube>
oh, it guarantees the absence of collisions? nice
<def`>
but for efficient dictionary, the implementation of guarrigues is clever, practical and efficient without making too strong assumptions (method names should not collide)
<flux>
how about method name hashes btw?
hausdorff has joined #ocaml
<flux>
ah, that's exactly what you meant, right :)
slash^ has joined #ocaml
alexst has joined #ocaml
<flux>
is it enough to not collide per type or per object or do they need to not collide globally?
<def`>
companion_cube: not of the values in the table, only method name hashes (like polymorphic variants)
<def`>
flux: per object
<ousado>
it looks like there will be a number of interesting design decisions in the haxe/C implementation
<def`>
flux: in particular, no closed world assumption is made, which is nice
<ousado>
very much looking forward to you guys taking a look at it
BitPuffin has quit [Quit: See you on the dark side of the moon!]
BitPuffin has joined #ocaml
philtor has joined #ocaml
alexst has quit [Ping timeout: 240 seconds]
<BitPuffin>
Drup: it's not reinventing the wheel if nothing offers what I want :P
<BitPuffin>
plus I've tried pretty hard for years to find a language that will do what I want :)
<BitPuffin>
so it's not unwillingness to use other peoples stuff
jao has joined #ocaml
isBEKaml_ has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
thomasga has quit [Quit: Leaving.]
philtor has quit [Ping timeout: 256 seconds]
isBEKaml has quit [Ping timeout: 240 seconds]
<Drup>
BitPuffin: I was talking about writing the parser by hand instead of using menhir
isBEKaml_ is now known as isBEKaml
isBEKaml has quit [Changing host]
isBEKaml has joined #ocaml
<BitPuffin>
Drup: ah that was more a question. I was thinking maybe mehnir was more useful for parsing data formats such as xml or json. Perhaps not programming languages
<BitPuffin>
that said writing my own parser could be a good learning experience as I have never written a parser before
<BitPuffin>
so it wouldn't be NIH, it would be research :)
<Drup>
:D
<Drup>
menhir is fine for programming languages
<Drup>
ocaml parser itself is written in ocamlyacc, which is a sub version of menhir anyway
dapz has joined #ocaml
isBEKaml has quit [Quit: leaving]
jwatzman|work has quit [Quit: jwatzman|work]
pgomes has joined #ocaml
Hannibal_Smith has quit [Quit: Sto andando via]
r0ok has joined #ocaml
olauzon has quit [Quit: olauzon]
alpounet has quit [Remote host closed the connection]
WraithM has joined #ocaml
avsm has joined #ocaml
jwatzman|work has joined #ocaml
ygrek_ has quit [Ping timeout: 255 seconds]
alexst has joined #ocaml
alexst has quit [Ping timeout: 245 seconds]
<BitPuffin>
Drup: ah I don't like svn
<BitPuffin>
just kidding
<BitPuffin>
well it's not a joke that I don't like svn
<BitPuffin>
but that you would mean svn is a stupid joke :P
slash^ has quit [Read error: Connection reset by peer]
<BitPuffin>
Drup: well I guess using a parser generator is a little bit like compiling to llvm or C. It works fine but you don't learn as much
<whitequark>
year 2050: BitPuffin started writing his game
<BitPuffin>
whitequark: take you condescension somewhere else ;)
<ousado>
BitPuffin: "plus I've tried pretty hard for years to find a language that will do what I want"
<NoNNaN>
it's a game compiler
<ousado>
that's kinda hard to believe
<BitPuffin>
ousado: why? I mean I have found languages that do a subset of what I want, but not all :D
<ousado>
well, for instance you should have known about linear types if you had "tried hard for years"
<BitPuffin>
NoNNaN: I'm not saying I can't make a game in any other language :P but the api I want to make in the future I can't make with current langs
<NoNNaN>
if you are really hardcore, write it in malborge
<NoNNaN>
;)
<BitPuffin>
ousado: I've mostly been looking at systems languages
<whitequark>
systems languages are a sweet spot for linear types
<NoNNaN>
BitPuffin: do your research, i'ts your game
<whitequark>
e.g. cyclone is old and quite well-known.
<BitPuffin>
plus a lot of that time is using the languages and see if they are up to snuff
<BitPuffin>
not just looking briefly at what ALL of them have
<BitPuffin>
but yeah I've looked at cyclone actually
<def`>
BitPuffin: and when compiling to C you actually learn a lot, you miss most of the backend work, but a lot of work has to be done upfront
<BitPuffin>
I guess the thing I'm thinking about is that it doesn't give me the intuition to look at assembly code for code that might be generated in a non optimal way
ivan\ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<BitPuffin>
NoNNaN: no I've mostly just read about it on the website
<BitPuffin>
was cyclone the one used for inferno or was that something else
<BitPuffin>
NoNNaN: ah way tim sweeney talked about cyclone? o.O
olauzon has joined #ocaml
<NoNNaN>
BitPuffin: what kind of game you want to develop ?
<BitPuffin>
NoNNaN: many kinds. The first one I will make is just a simple abstract horror game with hatching style graphics
<BitPuffin>
ie as it has been sketched by hand
<BitPuffin>
in 3d
<BitPuffin>
I also have one planned that is a multiplayer thing with realtime dynamic fracture and stuff of the environment
<BitPuffin>
that's something that's quite complex though
<BitPuffin>
so I'm putting it off
Thooms has joined #ocaml
alpounet has joined #ocaml
<BitPuffin>
also one of the first thing I'm looking for is not even the style of the language. It's just if it compiles to native code and if it has the ability to run parts of a program interpreted while prototyping and then compiled in statically for release builds
<BitPuffin>
second option eliminates all. Except maybe lisp, but none of the open source common lisp compilers can't even optimize away the compiler for release "images"
<BitPuffin>
plus lisp is statically typed unless you force it to be dynamically typed
<BitPuffin>
NoNNaN: sounds like Tim Sweeney stands behind me :D
tnguyen has quit [Quit: tnguyen]
<BitPuffin>
pff 6 threads, last time I heard it was only 2. But that could have changed recently I guess
axiles has quit [Ping timeout: 240 seconds]
alpounet has quit [Remote host closed the connection]
ollehar has quit [Ping timeout: 255 seconds]
<BitPuffin>
NoNNaN: yeah I'm actually considering playing with software rendering for this current project. Since the look is quite different from the usual stuff, fixed function pipelines are kind of a hassle. Plus it's more fun to write a software renderer :D
<BitPuffin>
(yes I might be a masochist, I know)
pgomes has left #ocaml ["Leaving"]
jwatzman|work has quit [Quit: jwatzman|work]
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
agarwal1975 has quit [Quit: agarwal1975]
jwatzman|work has joined #ocaml
alexst has joined #ocaml
Submarine has quit [Remote host closed the connection]
dapz has joined #ocaml
alpounet has joined #ocaml
alexst has quit [Ping timeout: 264 seconds]
olauzon has quit [Ping timeout: 256 seconds]
olauzon has joined #ocaml
jwatzman|work has quit [Quit: jwatzman|work]
tnguyen has joined #ocaml
gperetin has joined #ocaml
alpounet has quit [Remote host closed the connection]
alpounet has joined #ocaml
thomasga has joined #ocaml
claudiuc has joined #ocaml
jwatzman|work has joined #ocaml
alpounet has quit [Ping timeout: 256 seconds]
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
waneck has joined #ocaml
dapz has joined #ocaml
thomasga has quit [Quit: Leaving.]
wwilly has quit [Ping timeout: 264 seconds]
alexst has joined #ocaml
alexst has quit [Ping timeout: 240 seconds]
jludlam has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dapz has joined #ocaml
alpounet has joined #ocaml
jprakash has quit [Quit: leaving]
<BitPuffin>
Drup: I think the ocaml devs have probably written parsers before :) so I think I might opt for writing my own. Even if it will probably be worse :P
olauzon has quit [Ping timeout: 264 seconds]
<NoNNaN>
you should also design your own cpu
<NoNNaN>
if you like the challenges
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<NoNNaN>
and I am not joking, you could learn a lot from it (but takes lot's of time)
ggole has quit []
<BitPuffin>
NoNNaN: it did sound somewhat sarcastic. But indeed it would be fun. We need more open hardware and stuff