<jeff2>
flux: extlib has BitSet and UChar, but no 8-bit data type that I could see. what are some other extended standard libraries to check?
<adrien>
Mirage is a bare-metal OS that was recently announced and that has tools for such things (since it's not relying on applications and libraries that have already done the job, it had to implement them in ocaml)
<adrien>
jeff2: probably, but might be hard to get something better
<adrien>
you might use a char for 8bit but I'm actually not sure how much space it takes
<flux>
jeff2, there is jane street core
<flux>
it takes as much as an integer
<flux>
an array of chars takes less, though (AFAIK :-))
<adrien>
ok, pretty much what I expected, would have been surprised the tag would have magically disappeared :-)
<jeff2>
adrien: not too concerned about space, more semantics. flux: thanks, looking into it now. they have core_int/32/63/64/native
<jeff2>
binary_packing has unpack_Signed_8, but it unpacks to int, so I guess they don't have an int8. perhaps I could make my own type
<jeff2>
looks like I could use Biginteger.int8_unsigned_elt
ulfdoz has quit [Ping timeout: 276 seconds]
jeff2 has quit [Quit: Leaving]
Yoric has joined #ocaml
joewilliams_away is now known as joewilliams
joewilliams is now known as joewilliams_away
Yoric has quit [Quit: Yoric]
Snark has joined #ocaml
mattam has quit [Ping timeout: 245 seconds]
ikaros has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
jonafan_ has joined #ocaml
jonafan has quit [Ping timeout: 255 seconds]
srcerer_ has joined #ocaml
srcerer__ has joined #ocaml
srcerer has quit [Ping timeout: 255 seconds]
srcerer_ has quit [Ping timeout: 255 seconds]
hcube has joined #ocaml
larhat has joined #ocaml
ftrvxmtrx has joined #ocaml
rwmjones has joined #ocaml
Yoric has joined #ocaml
<avsm>
we dont represent 8 bits in mirage
<avsm>
thats usually protocol traffic, so its just referenced, via a DSL that hides away all the bit shifting in generated code
<_y_>
tonight I learned about caml_c_thread_register() and caml_c_thread_unregister(), which I thought were going to lead me to the promised land... but actually, attempting to execute this code crashes:
<_y_>
int WrapOCamlRegisterThread()
<_y_>
{
<_y_>
int i;
<_y_>
caml_leave_blocking_section();
<_y_>
i = caml_c_thread_register();
<_y_>
caml_enter_blocking_section();
<_y_>
return i;
<_y_>
}
<_y_>
am I doing something stupid here?
avsm has joined #ocaml
<_y_>
strangely enough, the following line is responsible for the crash:
<_y_>
.text:08143AA6 call ds:EnterCriticalSection ; <- crash inside here
<gildor>
_y_: what about calling caml_c_thread_register from inside the created thread ?
<_y_>
this is inside of a C thread
<mfp>
_y_: why are you calling caml_leave_blocking_section? caml_c_thread_register should be called in the new thread (which cannot have been created by Caml by def)
<_y_>
that's a good point, I'm a bit trigger-happy with the blocking sections
<gildor>
_y_: you must not call caml_leave_*_section from a C thread
<_y_>
that's not what's crashing though
<gildor>
_y_: crash can be caused by unrelated init
<gildor>
_y_: also remember to call caml_c_thread_unregister
<_y_>
yep, I've got code in there for that, but it never gets executed as the aforementioned crash occurs immediately
<gildor>
_y_: BTW registering the thread will only give you the ability to do callback
<_y_>
that's what I need
<gildor>
_y_: if your thread is pure C, no need to do this
<_y_>
the C code needs to call OCaml closures
<_y_>
basically, I have an OCaml interpreter embedded inside of a machine code disassembler, which has a custom graph-drawing interface, and I want to be able to create graph objects on the OCaml side and pass them through to the C side, where the C side calls the callbacks for various things (number of vertices, list of edges, vertex text, etc)
ski has quit [Ping timeout: 272 seconds]
mattam has joined #ocaml
<adrien>
gildor: FileUtil has no function to get the size in bytes from FileUtil.size? there's string_of_size but not int_of_size (or int64)
<adrien>
if not, I'll just use int_of_string
_y_ has quit [Ping timeout: 276 seconds]
<gildor>
adrien: byte_of_size ?
<adrien>
gildor: yes, thanks a lot, hadn't seen it :-)
<adrien>
I should have told ocamlbrowser to look for the protoype
<adrien>
+t*
mcclurmc has quit [Remote host closed the connection]
mikemc has quit [Read error: Connection reset by peer]
<kaustuv>
and place your cursor before the #, then press any input character such as space or enter, does emacs do what you would expect it to do?
<kaustuv>
apparently there are bugs about weird behaviour with character literals in tuareg.forge.ocamlcore.org, but I am not sure I like the official response
<f[x]>
ocamlmq grows memory indefinitely, after disconnected client keeps 100% cpu in gc and I can see long-long stacktraces
<f[x]>
that's probably not the correct usage, but anyway :)
<mfp>
so the pb is large queues
<mfp>
what params are you giving to ocamlmq?
<f[x]>
no params
<f[x]>
latest git
<f[x]>
why large queues? it keeps memory after all producers disconnect (and no consumers0
<f[x]>
I am never fetching anything from queues, and it should keep at most 100K msgs in ram - yes?
<f[x]>
also in logs it writes like : Flushing to disk: 1037 msgs, 1037 + 0 pending ACKS, 0 ACKS ( 0.10491s)
<f[x]>
without subscribe line - it is 0 + 0 pending acks always
<f[x]>
can you reproduce it?
<mfp>
trying
<mfp>
sent >1M so far to a queue, no pbs observed
<mfp>
oh, you subscribe without prefetch and never ACK anything
<mfp>
you're supposed to ACK reception, mem usage is O(pending ACKs)
<mfp>
each non-ACKed msg spawns in a Lwt thread that will be awaken when the ACK is received (or canceled on timeout)
<f[x]>
hm, I never fetch anything from queue, what should I ack?
<mfp>
good point
<f[x]>
aha, so when the producer disconnects the lwt threads are killed by timeout and this takes lots of time
<mfp>
here's a guess: Mq_server does not consider the conn blocked, so it tries to send
<mfp>
now, the tx window is full since you're not reading
<mfp>
so there are lots of Lwt threads blocked trying to write
<f[x]>
ok, now I got what you say - prefetch 0 is infinity, that's why mq_servers sends smth to me
<f[x]>
so half of the problem solved - this is clearly misbehaving client
<mfp>
well yes, the client is misbehaving, but the server should be able to handle that
<f[x]>
yes
<mfp>
i.e. the connection should be blocked when the TCP tx window is full
<f[x]>
prefetch 0 as infinity is a good catch :)
<mfp>
a cheap workaround is to set some arbitrary max for prefetch
<mfp>
a power of 2 to make it look meaningful ;)
<f[x]>
prefetch 1 is ok, but I mean that it is easy to misuse client api
<f[x]>
I am talking about ocaml-stomp simultaneously here
<mfp>
right
<mfp>
not sure how to detect the above condition using Lwt; maybe Lwt_io.buffered och = Lwt_io.buffer_size och?
<f[x]>
and probably ocamlmq should have some dos protection builtin - configurable limit for the number of unacked msgs global and/or per connection
<mfp>
it's not meant to be exposed to 3rd parties, though: handling client errors is one thing, protecting against active attacks is another
<f[x]>
not sure, btw it segfaulted (stack overflow)
<f[x]>
buggy code may also lead to situation when lots of msgs are left unacked
<mfp>
I'll ask on the ocsigen ML about the TCP window thing, Jérémie Dimino will know
<f[x]>
ok, thanks for help, my problem is fixed now
<mfp>
yes, max pending acks is definitely a safety net I should implement
<mfp>
but it's not quite the same as full DoS protection, that's what I meant
<mfp>
I wonder what would happen with the likes of RabbitMQ or ActimeMQ
<f[x]>
hm, 1M frames in bt, run_waiters is not tail rec? (just guessing)
<f[x]>
and there is some unix_error raised from lwt_unix_write
<mfp>
hmm hmm actually the theory I exposed above seems to be wrong, there shouldn't be multiple threads trying to write: messages are sent to a conn serially
<mfp>
but it must be trying to, otherwise it'd be a sort of prefetch=1 de facto
<mfp>
need to read this code again carefully
<mfp>
ah got it, was reading from cmd_subscribe's side, when it's actually cmd_send that matters here. On msg reception, it looks for a subscriber and sends -> this is where we end up with lots of threads.
thieusoai has quit [Quit: Leaving]
thieusoai has joined #ocaml
joewilliams_away is now known as joewilliams
thieusoai has quit [Quit: Leaving]
thieusoai has joined #ocaml
ski has joined #ocaml
wuj has joined #ocaml
larhat has quit [Quit: Leaving.]
Yoric has quit [Read error: Connection reset by peer]
Yoric has joined #ocaml
Yoric has quit [Quit: Yoric]
ztfw has joined #ocaml
Fullma has quit [Ping timeout: 264 seconds]
avsm has quit [Quit: Leaving.]
ftrvxmtrx has quit [Quit: Leaving]
jonafan_ is now known as jonafan
hcube has quit [Ping timeout: 240 seconds]
ski has quit [Ping timeout: 250 seconds]
tmaeda has quit [Ping timeout: 272 seconds]
hcube has joined #ocaml
ulfdoz has joined #ocaml
ftrvxmtrx has joined #ocaml
rks has joined #ocaml
thieusoai has quit [Quit: Leaving]
yezariaely has joined #ocaml
_andre has quit [Quit: leaving]
Snark has quit [Quit: Ex-Chat]
drunK has joined #ocaml
Yoric has joined #ocaml
snarkyboojum has left #ocaml []
little_owl has joined #ocaml
ztfw has quit [Remote host closed the connection]
_unK has joined #ocaml
drunK has quit [Read error: Operation timed out]
yezariaely has quit [Quit: Leaving.]
ulfdoz has quit [Ping timeout: 240 seconds]
ftrvxmtrx has quit [Quit: Leaving]
ftrvxmtrx has joined #ocaml
boscop_ has joined #ocaml
boscop has quit [Ping timeout: 240 seconds]
init1 has quit [Quit: Quitte]
patronus has quit [Remote host closed the connection]
patronus has joined #ocaml
Yoric has quit [Quit: Yoric]
bacam has quit [Read error: No route to host]
boscop_ is now known as boscop
Edward has joined #ocaml
wuj has quit [Ping timeout: 265 seconds]
BiDOrD_ has joined #ocaml
BiDOrD has quit [Ping timeout: 245 seconds]
rixed_ has joined #ocaml
<rixed_>
Hi! I'm trying to compile a version of the ocaml compiler with all internal Assert() macros compiled in.
<rixed_>
In other words, a compilter compiled with -DDEBUG. Is there any make file target for this ?
<rixed_>
Or am I supposed to hack config/makefile by hand ?
<kerneis>
rixed_: look into the Makefile, there might an EXTRA_DEFINES variable left for that purpose
<kerneis>
(but not all projects use it, and I never looked at OCaml Makefile)
<rixed_>
kerneis: Thanks you, Im going to try
<rixed_>
kerneis: hm, no, I cant find anything like that
<kerneis>
otherwise, you could try the ocamlbuild way (with fastworld.sh or sth like that) but look into the (scarce) documentation how to pass flags
<kerneis>
probably have to edit myocamlbuild.ml, though
<kerneis>
I must say I seldom compile ocaml, although I have some experience with building other projects which use ocaml
<kerneis>
so cannot better hints, sorry
<kerneis>
+give
<rixed_>
kerneis: Im not familiar with ocamlbuild. I will try to change the CFLAGS in byterun/Makefile then...
rudi_s has quit [Ping timeout: 265 seconds]
mattam has quit [Ping timeout: 255 seconds]
rudi_s has joined #ocaml
mattam has joined #ocaml
<hcube>
hey! has anyone experience with ocaml for multicore project?
<gildor>
hcube: I have done some application that use multicore
<hcube>
i've written a sample app in ocaml for iphone and i'm using many threads, but the app sometimes getting stuck due to runtime's master lock
joewilliams is now known as joewilliams_away
ftrvxmtrx has quit [Quit: Leaving]
<gildor>
hcube: well, if you really want to leverage multicore you need to run several processes
<gildor>
(not thread)
<gildor>
but are there more than one core on an iPhone
<gildor>
?
<hcube>
you are right
<hcube>
iphone has 1 core
<gildor>
so using many threads is probably overkilling
<gildor>
you won't get more speed
<gildor>
what are doing your thread
<hcube>
i'm using threads for downloading images
<rixed_>
gildor: (sometimes threads are not introduced for speed but because it makes the program easier to understand)
<gildor>
rixed_, hcube: yes, I know (concurrency vs paralle)
<gildor>
hcube: have a look at lwt that can help you on this topic (concurrency)
ikaros has quit [Quit: Leave the magic to Houdini]
<rixed_>
hcube: how do you download your images ? because any blocking syscall is supposed to release the master lock...
ftrvxmtrx has joined #ocaml
<hcube>
the UI is written in objective c and it runs it own thread, the logic is written in ocaml and ha it's own thread too. The UI asks ocaml for data.
<hcube>
the problem is that the UI (e.g. scrolling a list) get stock (sometimes)
<hcube>
for many secs
<rixed_>
hcube: should be allright. lwt won't bring much (it replaces system threads by lightweight threads so it switch faster between threads but apart from that, and a somewhat different API, it wont differ much I guess
<rixed_>
hcube: for many seconds ? I'd say some blocking function does not release the lock. Do you perform name resolution in ocaml ?
<hcube>
yes
<rixed_>
hcube: using which lib ?
<hcube>
should i cache it?
<hcube>
ocamlnet
joewilliams_away is now known as joewilliams
<hcube>
forget my last question
<rixed_>
I don't know ocamlnet but its event driven so I guess it should use an assynchronous name resolution lib.
<rixed_>
hcube: wait, from ocamlnet doc : "Resolvers can be both synchronous or asynchronous. Note however, that the default resolver is synchronous and simply bases on Unix.gethostbyname."
<rixed_>
hcube: I suggest you use not the default resolver :)