trillion_exabyte has quit [Ping timeout: 256 seconds]
trillion_exabyte has joined #ocaml
trillion_exabyte has quit [Ping timeout: 264 seconds]
trillion_exabyte has joined #ocaml
Serpent7776 has joined #ocaml
bartholin has joined #ocaml
olle has joined #ocaml
<Leonidas>
anadon: I'm just pointing out that some tools (I think pkg-config) at least quote the paths instead of escaping the :
<discocaml>
<kayceesrk> This can potentially be done as in other language runtimes. Install a signal handler that fires every 20ms. Perform the Yield effect from the callback. Sounds doable on paper, but I don't think it is safe to do effects from callbacks (as I'd expect there to be C frames between the callback and the fiber that you want to preempt). If we want to make this work, we need some work in the compiler.
chiselfuse has quit [Remote host closed the connection]
<discocaml>
<limp.biskit> does ocaml need preemptive multitasking?
deadmarshal_ has joined #ocaml
<discocaml>
<kayceesrk> Some applications may. The compiler is unopinionated here.
<discocaml>
<limp.biskit> for those sorts of jobs i would probably pool domains and trust my OS scheduler not to perform badly
<discocaml>
<kayceesrk> This won't work.
<discocaml>
<kayceesrk> If your cooperative fiber does not give up control, your other fiber, on the same domain may never get a chance to run
<discocaml>
<dinosaure> For my perspective, it's long standing issue that we discover again with Git and HTTP (I explained the issue here: https://blog.osau.re/articles/lwt_pause.html) but I prefer to be, as the compiler, unopinionated (as you said 🙂 ). It's hard to figure out if it's fit for all cases
<discocaml>
<kayceesrk> Again, not every scheduler needs to be preemptively scheduled.
<discocaml>
<kayceesrk> > For my perspective, it's long standing issue that we discover again with Git and HTTP
<discocaml>
<kayceesrk> Do you mean the lack of preemption is a long-standing issue or do you mean if you have preemptive multi-threading, it is known to be problematic?
<discocaml>
<limp.biskit> preemptive scheduling has been quite stable for me across a couple languages, but then again i don’t do the amount of cpu bound processing that would lead to issues
<discocaml>
<limp.biskit> anything preemptive certainly would be terrifying to see in miou or eio
<discocaml>
<dinosaure> the lack of preemption, I remember myself talk about that years ago about lwt. It starts to become problematic when you compose multiple libraries which uses lwt: you are not sure that they coop together well
<hannes>
a thought experiment: if the compiler would be able to do function-entry tracing (similar to dtrace/ebpf) and insert for each function call a callback (performance can't be too bad since in linux & freebsd they ship it in production), this could be used (apart from tail-calls, which may need to also emit some trace points) as something to use for preemptive scheduling
<discocaml>
<dinosaure> My intuition would be to present the problem and show the levers to the user when faced with such a situation (like a tutorial for example 🙃 ).
<discocaml>
<limp.biskit> hannes doesn’t the GC already function like that
<discocaml>
<dinosaure> (a yield into `caml_call_gc` :D)
<hannes>
thing is, these trace points would be independently useful for debugging / flame charts / profiling...
<discocaml>
<.armael.> I know the compiler already inserts poll-points in the code ; couldn't these also be used to call a user-definable hook that would call Yield (the hook would be installed by the scheduler library)?
olle has left #ocaml [#ocaml]
<discocaml>
<.armael.> I guess the implementation using signals you were mentioning @kayceesrk is the same idea (since poll points check for signals (?)), but I'm wondering if it could be made more direct
<discocaml>
<.armael.> (and IIUC this currently won't work because the compiler doesn't actually allow you to perform effects in signal handlers/poll points; how hard would it be to lift this restriction?)
<discocaml>
<dinosaure> actually, Miou can handle signals, we just add a "fake task" into our scheduler when we receive a signal registered
<discocaml>
<dinosaure> so we can imagine that it's actually possible to implement the @kayceesrk's idea but a more direct way to emit an effect on a poll point will be useful. However, it requires that the scheduler should not have any poll points
wingsorc has joined #ocaml
<discocaml>
<limp.biskit> hannes after trying to make an eio application clean shutdown the debugging aspect is actually much more interesting to me..
<discocaml>
<kayceesrk> Yes. That's the idea.
<discocaml>
<kayceesrk> It is indeed a challenge to perform an effect at a signal handler. But I understand that ctrl+c is implemented as a signal handler raising an exception. So some support is there. Needs a bit more cleverness to support effects I think.
<companion_cube>
I'm not clear on how you redirect the signal to the appropriate thread/domain though
<discocaml>
<kayceesrk> Indeed, this is a challenge. Runtimes like GHC and Go have the schedulers in the runtime. So essentially, they don't need to worry about the scheduler not having poll points.
patrick is now known as Guest6340
Guest6340 has quit [Killed (copper.libera.chat (Nickname regained by services))]
patrick_ has joined #ocaml
jabuxas has joined #ocaml
gzar has joined #ocaml
<discocaml>
<kayceesrk> > <companion_cube> I'm not clear on how you redirect the signal to the appropriate thread/domain though
<discocaml>
<kayceesrk> Yeah. that's another challenge. Currently IIUC, in POSIX systems, the C signal handler can run on any thread that does not block the signal. The C signal handler just records a signal, which is frequently checked by OCaml (incl at safe points). Any OCaml domain can run the OCaml callback for the signal handler. We don't have a notion of pinning the handler or sending signals to a particular domain (yet).
YuGiOhJCJ has quit [Ping timeout: 260 seconds]
YuGiOhJCJ has joined #ocaml
szkl has joined #ocaml
dstein64 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<companion_cube>
Yeah exactly
<companion_cube>
I hate signals :p
dstein64 has joined #ocaml
gzar has quit [Ping timeout: 240 seconds]
malte has quit [Ping timeout: 255 seconds]
<discocaml>
<guiprofissa_> Hi, I wish oCam had an update that would allow us to do lives, it would be great!
<discocaml>
<guiprofissa_> Hi, I wish oCam had an update that would allow us to do lives, it would be great!
malte has joined #ocaml
malte has quit [Ping timeout: 240 seconds]
<anadon>
Leonidas: Sure, but you have to split it out to be able to quote it in the first place. Look at the spec for PATH.
malte has joined #ocaml
jabuxas has quit [Ping timeout: 240 seconds]
<discocaml>
<darrenldl> anadon: your text reminded me i did not handle a similar matter properly at all, ha
<discocaml>
<darrenldl> is it worth the effort to fix it hm
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
* mbuf
Reminder: OCaml Twitch stream today, Wednesday, May 22, 2024 1530 GMT | 1630 CEST | 2000 IST https://www.twitch.tv/shakthimaan
trillion_exabyte has quit [Ping timeout: 256 seconds]
trillion_exabyte has joined #ocaml
<discocaml>
<vinwin008> hard to install ocaml
<discocaml>
<vinwin008> I'll just wait for official release
<discocaml>
<shakthimaan.> Which operating system are you using, and what steps are you following to install OCaml?
<discocaml>
<vinwin008> Windows
troydm has joined #ocaml
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
troydm has joined #ocaml
szkl has quit [Quit: Connection closed for inactivity]
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
<discocaml>
<limp.biskit> is wsl2 suitable for you?
ocra8 has joined #ocaml
mbuf has quit [Quit: Leaving]
troydm has quit [Ping timeout: 264 seconds]
Tuplanolla has joined #ocaml
szkl has joined #ocaml
troydm has joined #ocaml
<anadon>
For splitting PATH, I'm thinking the following and I don't know how to translate this into Ocaml. Stream PATH into a unicode char split -> merge each "\" with the following character into a string -> merge tokens until a matching split token is matched, then drop that token, emit the string, and continue until all input has been consumed.
<dh`>
are you asking how to implement String.split_on_char?
<anadon>
More the stream operations downstream from that.
<anadon>
*downstream
thizanne` is now known as thizanne
<dh`>
I am guessing from the mention of "\" that you're on windows and trying to implement "C:\WINDOWS\SYSTEM" -> ("C", true, ["WINDOWS"; "SYSTEM"])
<dh`>
is that right?
<anadon>
No. I am on Linux handling the PATH environmental variable and need to handle when ":" is escaped with "\".
<dh`>
or are you trying to implement "C:\WINDOWS\SYSTEM;C:\BIN;D:\BIN" -> ["C:\WINDOWS\SYSTEM"; "C:\BIN"; "D:\BIN"]?
<dh`>
oh, I see
<dh`>
ok, you can do that by split first but it'll be easier and make more sense to write your own split that honors the escapes
<anadon>
Thus what I have written above.
<dh`>
right, so basically you want to implement String.split_on_char except with fancier delimiter logic
<dh`>
and I assume from the way you're asking that you don't just want me to tell you the answer but want a hint first
<anadon>
Due to Unicode, it must still split on characters as the first step.
<dh`>
try thinking of what you need to do as fold_left on the characters on the string
<anadon>
I'm asking it the most direct way I can. No one has given me much to work with so far.
<dh`>
that is not actually the case, but it doesn't really change anything
<dh`>
suppose first that you're staring from a list of chars
<dh`>
write the fold_left that splits on ":" but ignores "\:"
<dh`>
or rather, ignores "\\" followed by ":"
<dh`>
the state machine you need is pretty simple
<dh`>
once you have that you can figure out how to get from a string to a list of char
<dh`>
then afterwards you can merge the two pieces of code if you want
<discocaml>
<aaronchristianson9068> Having a problem with first class modules. trying to solve it with abstract types. Not quite working.
<discocaml>
<aaronchristianson9068> ```let count (type a) (module M: Map.S with type key = a) (keys: a list) =
<discocaml>
<aaronchristianson9068> let add1 map key =
<discocaml>
<aaronchristianson9068> M.update key (function None -> Some 1 | Some n -> Some (n + 1)) map in
<discocaml>
<aaronchristianson9068> the last line is highlighted and has this message: This expression has type int M.t
<discocaml>
<aaronchristianson9068> but an expression was expected of type 'a
<discocaml>
<aaronchristianson9068> The type constructor M.t would escape its scope
<discocaml>
<aaronchristianson9068> Ah, not supposed to post code in this channel. Sorry. Should I repost this in #beginners?
<discocaml>
<aaronchristianson9068> I guess it's something to do with `int Map.t` vs `'a Map.t`, but yeah, don't quite see a fix.
<discocaml>
<limp.biskit> I still don't really see, aside from not wanting to pull in Re or Str, why a simple regexp would not work
YuGiOhJCJ has joined #ocaml
waleee has joined #ocaml
cr1901_ is now known as cr1901
<dh`>
re the count thing, it looks like you're trying to avoid putting it in a functor so it can operate on maps with arbitrary keys
<dh`>
and I don't think you can avoid that by abusing first-class modules (though I would be happy to hear I'm wrong)
<discocaml>
<deepspacejohn> @aaronchristianson9068 I believe this issue is that type constructors can't be used in first class modules, e.g. type `foo` can work but type `'a foo` won't.
<discocaml>
<barconstruction> Is it ok to update an opam package without changing the version number just to expand the dependency version requirements
<discocaml>
<barconstruction> If the code has not changed.
<discocaml>
<aaronchristianson9068> @dh that is indeed the goal.
<discocaml>
<deepspacejohn> module types with type constructors (like `Map.S`) aren't friendly to FCMs due to that limitation. One solution would be to define a module/module type that has a monomorphic map type.
<discocaml>
<deepspacejohn> but either way, if you're returning a value of type `M.t` from the function, then you'll need to use a locally abstract type for that too instead of just for the keys.
szkl has quit [Quit: Connection closed for inactivity]
<discocaml>
<aaronchristianson9068> I think I see what you mean about the monomorphic map type, but I'm not totally sure how to get there. The goal is polymorphism over keys, but the values should always be `int`.
vb has joined #ocaml
<discocaml>
<deepspacejohn> you can define a module type like `sig type t type value type key val add: key -> value -> t -> t end`
<discocaml>
<deepspacejohn> and then `key` `value` and `t` can each be bound to a locally abstract type.
<dh`>
that's not going to help much
<dh`>
the fundamental problem with maps is that you need compare on the keys, so it can't just be a type, it needs an operation as well
<dh`>
and without typeclasses, that means a module, and that makes the map itself inherently a functor
<dh`>
and so if you want to add more map ops, you need another functor
<discocaml>
<deepspacejohn> yeah I don't think it's a very practical solution, but it's how you can get it to type check.
<dh`>
it's all kind of ironic because Stdlib.compare is also magically polymorphic
<dh`>
(just not polymorphic enough to actually work for this purpose)
<discocaml>
<deepspacejohn> but you would then implement it as e.g. `type t = my_type My_map.t type value = m_type type key = My_map.key`
<discocaml>
<aaronchristianson9068> I'm going to study this. 😅
<discocaml>
<deepspacejohn> There's _probably_ a better solution to what your problem, but this technically works 🙂
<discocaml>
<aaronchristianson9068> I think it makes sense to me, at least.
Serpent7776 has quit [Ping timeout: 264 seconds]
<discocaml>
<aaronchristianson9068> I'm always kind of confused when OCaml can't infer something that I can infer mentally, but I guess this is because I really don't know how its type inference works.
<discocaml>
<deepspacejohn> first-class modules and locally abstract types kind of break inference. And they aren't compatible with polymorphic type constructors.
<discocaml>
<deepspacejohn> IIRC that incompatibility is related to OCaml not supporting higher-kinded polymorphism, which is a bigger theoretical problem.
littlestz has joined #ocaml
bartholin has quit [Quit: Leaving]
littlestz has quit [Remote host closed the connection]
jabuxas has joined #ocaml
trillion_exabyte has quit [Ping timeout: 268 seconds]
trillion_exabyte has joined #ocaml
<discocaml>
<limp.biskit> got my library building for the first time without a hard dependency on eio or unix woo