<sagax>
uff, how to debug code? because do it with some `print_*` it's very hard
<sagax>
I just try to understand the code better
powerbit has joined #ocaml
Haudegen has joined #ocaml
<vsiles>
sagax: ocamldebug ?
<sagax>
may be, will try
<freyr69>
Ocamldebug is nearly useless
<freyr69>
Print is fine if you know the codebase
<freyr69>
GDB+repl+tests do the trick
<freyr69>
Hopefully GDB/LLDB experience would be improved significantly in 4.09
monstasat has joined #ocaml
kakadu_ has quit [Remote host closed the connection]
<monstasat>
Hi! when I inherit from a class (i will name it `parent`) which is also inherited from another class (i will name it `origin`), can I call the method of origin without calling the method of parent in the resulting class?
ziyourenxiang has quit [Quit: Leaving]
nikivi has quit [Quit: ZNC is awesome]
keep_learning has quit [Quit: Ping timeout (120 seconds)]
<monstasat>
with the explanation of the desired inheritance result
<sagotch>
Hello. Is there a way to marshal trivial functions like `let f i = [|"a";"b"|].(i)` such as it can be read in another program?
cantstanya has quit [Remote host closed the connection]
cantstanya has joined #ocaml
xorpse has joined #ocaml
ollehar has joined #ocaml
<freyr69>
monstasat: keep a reference to the parent.
fantasticsid has joined #ocaml
fantasticsid has quit [Client Quit]
fantasticsid has joined #ocaml
loli has quit [Ping timeout: 240 seconds]
fantasticsid has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
orbifx has joined #ocaml
loli has joined #ocaml
Birdface has joined #ocaml
<vsiles>
freyr69: ocamldebug is crap but there are some ui to make it better (emacs, red, ...)
Birdface has quit [Ping timeout: 240 seconds]
dhil has joined #ocaml
Birdface has joined #ocaml
dexter has left #ocaml [#ocaml]
loli has quit [Ping timeout: 250 seconds]
Haudegen has quit [Remote host closed the connection]
loli has joined #ocaml
asymptotically has joined #ocaml
silver has joined #ocaml
ggole has joined #ocaml
sagotch has quit [Quit: Leaving.]
kroot_ has joined #ocaml
jbrown has quit [Ping timeout: 250 seconds]
<freyr69>
vsiles: it works with bytecode only, I think that's the main problem
loli has quit [Ping timeout: 244 seconds]
q9929t has joined #ocaml
pierpal has quit [Remote host closed the connection]
jao has joined #ocaml
loli has joined #ocaml
q9929t has quit [Quit: q9929t]
sagotch has joined #ocaml
nojb[m] has joined #ocaml
<vsiles>
freyr69: true
<Armael>
sagotch: not really AFAIK. I guess your best bet is to define the AST of such functions, and serialize that
<Armael>
(and you'd write an interpreter function for the AST)
nojb_[m] has joined #ocaml
<sagotch>
I could, but as I am marshiling an AST for runtime execution optimization, I think that it's not worth it to bother optimixing that part. It would not be as trivial as regular marshaling, that's why I was hoping for some special for trivial function not depending on the local environment :)
dhil has quit [Ping timeout: 244 seconds]
<freyr69>
sagotch: What do you want to achieve? Semi-manual code optimizations like loop unrolling?
<sagotch>
I have HUGE i18n function, and I am trying to inline call to this function so I would not need to have the whole data loaded in memory in the server
<sagotch>
Some keys take arguments (Like in a printf format), so I cannot inline the result at compilation time, but I would like to inline a function taking missing arguments which would be applied by AST interpreter
<sagotch>
In short, I want to write a `Tfun of (?kwargs:kwargs -> tvalue -> tvalue)` value with my compiler, and read it back in my server.
<freyr69>
sagotch: then if the receiving program is also in OCaml you could use standard marshal, or serialize it to json using ppx_deriving_yojson
<freyr69>
Though standard marshal is working only for the programs compiled with the same compiler, so I would stick to json
<freyr69>
same version*
<sagotch>
Hum... maybe that I misunderstood the doc
<octachron>
You cannot serialize functions like that? Marshalling function and reading back only works from within the same program
<sagotch>
"In this case, the output of marshaling can only be read back in processes that run exactly the same program, with exactly the same compiled code"
<sagotch>
Yes, octachron that is what I thought
<octachron>
Since you are doing i18n could you not serialize format "strings"?
<sagotch>
The value of "!languages" is associated to _de_1
<sagotch>
the nth argument depends on runtime value
loli has quit [Ping timeout: 268 seconds]
AnAverageHuman has joined #ocaml
jbrown has joined #ocaml
<octachron>
On this lone example, marshalling the array seems much simpler? Otherwise, marshalling a small DSL Ast is indeed an option
FreeBirdLjj has joined #ocaml
loli has joined #ocaml
<sagotch>
I'll probably try the small DSL indeed
Mayoi is now known as erkin
OhCamel has joined #ocaml
OhCamel has quit [Quit: Page closed]
MK__ has joined #ocaml
<cemerick>
speaking of the limits of Marshal...`from_channel` appears to segfault when loading data marshaled when a subject type has a field added to it. Is this expected?
<Drup>
Marshal should only be used when you are sure about everything: you need to be sure that the source is trustable and that the message is exactly the type you expect
<Drup>
If you are not sure, use json/xml/whatever
<MK__>
I'm looking at assembly representation of a pattern-matching statement. However, looks like there is a difference in the numbers in OCaml and in assembly. Is there any good documentation on how the translation works?
<ggole>
MK__: an ocaml int n is represented as 2*n + 1
<ggole>
This is done so that the GC can tell what is an int and what is a pointer.
<MK__>
Ah! Interesting
<MK__>
Can you explain it a bit more?
<ggole>
There's a nice section of value representations in RWO, if you are interested in that kind of thing
<ggole>
If you are comfortable reading assembly, you should be able to see how it works
<MK__>
Doesn't that mean, the max value of an integer in OCaml is almost half compared to, for instance, C?
<ggole>
It can also be helpful to look at the compiler's intermediate forms, with -d<foo> (run ocamlc --help) to see the list
<ggole>
Yes
<ggole>
If you need native width integers, they are provided in the Int32/64 modules.
<cemerick>
Drup: clearly! :-) Just putting e.g. the version number of the essential library containing the types in question at the head of each marshaled file of data will be a reasonable safeguard.
<cemerick>
Marshal seems to be the sole option for serializing data with cycles though, so other options aren't.
<MK__>
Is there any performance difference in using Int32/64 vs native ints?
<Armael>
yes, Int32/64 values are boxed
<MK__>
And how does GC handles Int32/64 types?
<ggole>
Yes, the 32/64 bit ints are (usually) boxed and are quite slow
monstasat has quit [Quit: Leaving]
<Drup>
cemerick: cycles are tricky indeed. iirc, sexp handle them. I think one of the binary serializer (binprot/protobuf/binio) also does
<ggole>
Sometimes the compiler is smart enough to unbox them, in which case they are about the same speed.
<cemerick>
protobufs don't, and bin_prot doesn't
<cemerick>
eh, "JSON but faster" isn't really the value prop I'm after. Marshal will do just fine
loli has quit [Ping timeout: 240 seconds]
<companion_cube>
what do you mean, sexp handles cycles?
<companion_cube>
(at Drup)
loli has joined #ocaml
<Drup>
doesn't the janestreet version handle cycles ?
<companion_cube>
I never heard of that, how do they do it? how do they represent the cycles?
<ggole>
I don't think Jane St's sexps allow cycles
<ggole>
Common Lisp does, though
<ggole>
eg, #1=(foo #1 #1)
<companion_cube>
because it's not S-expressions but lisp?
<Drup>
companion_cube: aren't s-expressions just lisp values ? :3
<companion_cube>
no, they're text representation
<companion_cube>
lisp values are memory blocks
dhil has joined #ocaml
<ggole>
That's the textual representation of sharing in Lisp
* cemerick
thinks, "oh no, the ML-ers are talking about lisp" ;-D
<Drup>
cemerick: it's the privilege of PLT nerds to talk about any language they like, including the ones they don't want to use :3
<ggole>
Of course the actual conses that result from reading that are memory blocks that point at each other
<companion_cube>
ggole: oh ok, the reader accepts this directly?
<ggole>
Yes.
<companion_cube>
nice,it's like a µ binding
<cemerick>
Drup: for sure, with the inevitable caveat that the hot takes on things outside of one's typical tribe are often wrong
<ggole>
And the printers will emit it if you ask nicely
<companion_cube>
sadly I don't see how it would work with deriving
<Drup>
cemerick: ah, but the goal is not always to criticize, but often to take the good bits in other things (like here, for instance) ;)
<companion_cube>
detecting cycles is hard
<cemerick>
quite
<Drup>
(sometimes the goal is definitely to troll tho, but eh)
<ggole>
Yeah, I think you need eq-tables for it to work, and OCaml doesn't have those.
<companion_cube>
cemerick: bu-bu-but lisp is untyped :((
<Drup>
ggole: well, that's not exactly true ...
<cemerick>
companion_cube: if that was intentional, well done :-D
<ggole>
Drup: you might be able to use tables from C, if the work was done all at once with no GCs
<companion_cube>
intentionally a bad hot take? :P
<cemerick>
super-steamy
<companion_cube>
ggole: that's the issue, it's not very deriving-esque :D
<cemerick>
the filthiest lisp serialization mechanism is v8 heap snapshots for your clojurescript app
<companion_cube>
you could have marshal that prints S-expressions, but it'd still have to be in C
<Drup>
ggole: 1) there is always gregoire Henry's work
<def`>
also, I use more C stubs to better control allocations
<Drup>
I need to remember to reference the one in grenier then. I only remember that one
<ggole>
def`: nice, I've often wanted such tables
<Drup>
maybe I should try to implement Eliom's serialization with it
<ggole>
Usually you can hack in an id field or something for types you are defining yourself, but that's not always possible
<Drup>
And compare speed
<def`>
Drup: I have an implementation of marshal that use a similar table. The overhead of graph marking compared to using blue bit is around ~2.5x
<Drup>
that's ... very reasonable
<def`>
yep, that's just the overhead of marking, not of the actual copy
<Drup>
(in particular, it's lower than triggering a GC, disabling compaction, walking through the structure while replacing lot's of stuff, and then marshal :D)
<ggole>
Presumably that will be even more reasonable if multicore lands
<Drup>
(yes, this is what eliom does)
<def`>
This implementation is definitely not multicore safe, but MCGC comes with its own implementation of marshal.
<def`>
That might help pushing eq-table in the standard library.
<ggole>
Does it use eq-tables under the hood?
<def`>
Yes.
<ggole>
Well, exposing them seems pretty reasonable.
<def`>
Some words of caution: as far as I remember, yes.
<ggole>
Right, right.
jbrown has quit [Ping timeout: 268 seconds]
<Drup>
I remember stephen saying something similar to me
jbrown has joined #ocaml
MK__ has quit [Ping timeout: 256 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
gaze__ has joined #ocaml
loli has quit [Ping timeout: 272 seconds]
ollehar has quit [Ping timeout: 268 seconds]
loli has joined #ocaml
marvin2 has joined #ocaml
nicoo has quit [Remote host closed the connection]
nicoo has joined #ocaml
freyr69 has quit [Remote host closed the connection]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 268 seconds]
tane has joined #ocaml
FreeBirdLjj has joined #ocaml
jao has quit [Ping timeout: 246 seconds]
TC01 has quit [Ping timeout: 250 seconds]
AnAverageHuman has quit [Ping timeout: 256 seconds]
orbifx has quit [Quit: WeeChat 2.3]
loli has quit [Ping timeout: 246 seconds]
FreeBirdLjj has quit [Remote host closed the connection]