15:01 <EngineerSam> Good morning.

15:16 <SeanTAllen> good morning EngineerSam

15:20 <EngineerSam> Greetings.

15:25 <EngineerSam> I am mostly wandering in because I am curious if I could be pointed to an archive or record to explain the decisions made in the language design for having divide by zero return zero. I would have thought that the numbers would have been defined as, say, 'I32' be defined as '( I32_Raw | NaN )' where "Nan" would be a primitive. In which case dividing by zero could just return NaN. Since that was not chosen as a solution, I am

15:25 <EngineerSam> Not mentioned in the language FAQ or tutorial that I could see.

15:29 <Praetonus> EngineerSam: This is mostly to avoid an expensive `match` operation on the user side. Another option would be to raise an error on div by zero but that's expensive too

15:30 <SeanTAllen> the decision was made because if you return NaN or error (in the beginning it was error), it made writing all math related code very painful. there are possible performance implications but in the end all math operations where getting wrapped in error clauses which was found to be suboptimal. no one was happy with the decision at the time but it was decided it was "the least worst" option.

15:30 <SeanTAllen> there's nothing recorded for that, it is handed to us through spoken lore

15:35 <EngineerSam> Okay, thanks. I was just curious. I figured that instead of wrapping the all the math ops in checks it would be any operation with NaN would just return NaN and it would have been up to the user to check for it -- if they wanted to. Okay.

15:49 <jemc> EngineerSam: if we had a `NaN` primitive, and the return type for mathematical operations was `(<some machine word> | NaN)`, and you need to be able to `match` on the result later, then even if you're not doing the match until the end you're still paying the performance cost of "boxing the primitive"

15:50 <EngineerSam> Okay. Just didn't know the performance cost was that high.

15:50 <jemc> that is, wrapping the machine word (which may be as small as a single byte, in the `I8` or `U8` case) in a runtime object, with a type descriptor and the other overhead that all entails

15:52 <jemc> in a related topic, we recently added a set of "unsafe" math operators that return undefined values for some set of inputs, but are as performant as possible

15:59 <EngineerSam> Anyways, thanks everyone for the explanation. Time to get back to work.

18:47 <tokenrove> it's interesting to note that division by zero on RISC-V also does not trap, but returns all bits set (and remainder by zero equals the dividend).

22:09 <aceluck> Quick question (hopefully): How do I keep my pony program from exiting? I do an ffi call that spawns a thread, and I need to wait for a callback before exiting

22:25 <aceluck> Loos like the ffi call I'm making needs to be called on the main thread, or it crashes with an assertion failure. It's being called in the main actor, but that doesn't seem to help?

22:26 <jemc> aceluck: Pony isn't going to play well with FFI libraries that try to contact pony from another thread the pony doesn't control

22:27 <aceluck> I'm trying to wrap libui, a gui library. I'm on a mac, and cocoa only allows gui functions to be called on the main thread

22:28 <jemc> I don't have much time to help you troubleshoot at the moment, but can give some general guidance

22:28 <Praetonus> aceluck: You can try building your program as a library to retain control of the main thread and the runtime termination

22:29 <jemc> I think your best bet for a clean solution is if the callback function will pass you some opaque object that you specify, as callback functions often do

22:30 <jemc> then you can use a "bare lambda" (in Pony terms) as the callback function, have the opaque object pointer be a Pony actor, and use the bare function as glue code to trigger a method call on your Pony actor

22:30 <aceluck> That makes sense

22:31 <Praetonus> jemc: I'm not sure that'll prevent the runtime from reaching quiescence

22:31 <jemc> that doesn't help (directly) with your issue of keeping the Pony application open, but I think your best bet for that would be to employ the `Timers` API to have an open recurring timer to keep your program alive, which you can cancel when you want the program to finish

22:31 <jemc> Praetonus: right, that's why I added the above note

22:32 <aceluck> I'm not yet as far as the actual callback though - just calling out to the ffi to open a window, causes it to crash with an assertion failure from cocoa, saying it needs to be called on the main thread.

22:33 <aceluck> Timers should solve the quitting issue, thanks

22:33 <aceluck> I tried running with --ponythreads=1 , but it doesn't seem to help

22:34 <Praetonus> aceluck: The main thread in a classic Pony program is used to start the runtime and then blocks until the runtime has exited

22:35 <Praetonus> You need to build as a library (with the `--library` flag on the compiler) and use C-API actors to communicate with the Pony part of the application

22:36 <Praetonus> This isn't well documented but I think we have an example somewhere. I'll try to find it

22:36 <aceluck> Praetonus: Okay, can do that I suppose. There's no way to usurp the main thread from within pony?

22:38 <Praetonus> No, you can't do that

22:38 <jemc> other than Praetonus' suggestion, I think your only other course of action would be to find out more about the "only invoked from the main thread" requirement, try to see if an alternate API is provided or if there is a way to bypass that limitation under controlled circumstances

22:38 <Praetonus> It would be an interesting feature, though

22:39 <Praetonus> Hm, I can't find that example

22:39 <aceluck> It would be useful to be able to build gui apps. Having to build it in c, then link pony in is a bit cumbersome.

22:39 <jemc> aceluck: is this the API you're dealing with? https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html

22:40 <jemc> it definitely seems like it's going to be difficult to integrate that "run loop management" API with pony, as it's filling much the same role in the application as the pony runtime does

22:40 <aceluck> jemc: Not directly. I'm trying to make an ffi wrapper around libui, which is cross platform.

22:40 <aceluck> But it calls cocoa under the hood on macos

22:41 <Praetonus> aceluck: So basically, you can annotate an actor as a C-API actor by prefixing its name with the universal FFI symbol `@`. Then, when you invoke the compiler with the `--library` flag, it will build your package as a library and will generate a C header containing bindings to your C-API actors

22:42 <aceluck> Praetonus: All right, thanks. I'll try that. However, my goal was to make some gui support for pony, and this is a showstopper really

22:43 <Praetonus> That feature hasn't had much focus put into it so it's still very rough. As a rule of thumb to avoid usability problems, your C-API behaviours should only take and return types that have direct equivalents in C

22:43 <Praetonus> i.e. numeric primitives and Pointers

22:44 <aceluck> Okay

22:44 <Praetonus> Also I'd recommend you to look at what's available in the `pony.h` header. It contains the public runtime API, with things like memory allocation and GC tracing

22:45 <jemc> aceluck: can you point me to the docs for the function you're invoking that has the "main thread" requirement?

22:46 <jemc> it really feels like it should be exposing some kind of API that doesn't have that requirement, for applications that don't want the library to manage their event loop

22:51 <aceluck> jemc: It looks like there are discussions around this on their github. Let me dig a it deeper... maybe there is a way around

23:54 <jmiven> doublec: hi! In your Bang, Hat and Arrow post, you wrote "If A is a String iso then A! would be a String trn" but if I understand correctly it should be String tag