<< 30-04-2024 >>
00:00:01FromDiscord<Elegantbeef> Atleast with clang `bf16` has no native support
00:00:16FromDiscord<Elegantbeef> https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point assuming this is to be believed
00:54:12*pmp-p quit (Ping timeout: 256 seconds)
00:57:08*pmp-p joined #nim
01:38:55FromDiscord<cattokomo> how can i use Android NDK for building Nim program?
01:57:55FromDiscord<Elegantbeef> @cattokomo you can call `nim c -c --nimOut:somePath`
01:58:01FromDiscord<Elegantbeef> Then compile that using android ndk
02:39:19FromDiscord<planetis_m> In reply to @grumblygibson "Was looking for float16": I only have converters to contribute: https://github.com/planetis-m/dumpster/blob/master/half.nim
04:29:25*krux02_ quit (Quit: Leaving)
05:58:55*dtomato quit (Quit: The Lounge - https://thelounge.chat)
06:04:31Amun-Ra__fp16 is supported in both gcc and clang
06:04:43*dtomato joined #nim
06:05:31FromDiscord<Elegantbeef> Right whether it's supported vs. whether operations use dedicated hardware is the important thing
06:05:54FromDiscord<Elegantbeef> Seemingly the right type to import would be `_Float16`
06:06:14Amun-Raclang truncates/etends every operation of f16, it's not just a conversion from/to
06:06:17Amun-Raextends*
06:31:32*PMunch joined #nim
06:48:04*rockcavera quit (Remote host closed the connection)
07:04:55*redj quit (Ping timeout: 245 seconds)
07:30:46*oz quit (Remote host closed the connection)
07:31:01*ox joined #nim
07:32:39*Lord_Nightmare quit (Quit: ZNC - http://znc.in)
07:32:59*Lord_Nightmare joined #nim
07:49:33PMunchAnyone feeling particularly bored and in need of a project?
07:49:57PMunchI really want an Itanium -> Nim demangler
07:57:07*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
07:57:31*SchweinDeBurg joined #nim
07:59:11Amun-Rawhoa
07:59:14FromDiscord<Phil> No, double me up and give me a never tiring brain so I can tackle like half the things I want to do
07:59:46Amun-RaI like these kinds of projects but I'm pretty busy with mine :>
08:09:07PMunchYeah normally I'd do it myself, looks like a fun little thing to do
08:09:17PMunchWhat're you working on Amun-Ra?
08:09:30PMunch@Phil, I assume you're still playing with reactive stuff?
08:11:25Amun-RaPMunch: slowly finishing my image/anim viewer/converter
08:12:32Amun-RaI started writing way too many features
08:13:27FromDiscord<Phil> In reply to @PMunch "<@180601887916163073>, I assume you're": Yes, Stuck at a new point
08:14:58FromDiscord<Phil> This time it's how observables should contain their values as callbacks to execute instead of a value... Which I run into significant problems on
08:16:15FromDiscord<Phil> Because if you subscribe to a cold observable that you called map on before, now you need to figure out how to get the observable to forward values to the mapped observable so it can forward them to your subscription but only to that and not all the others
08:17:16PMunchHmm, I'm not up to speed on my reactive lingo so not quite sure what any of that meant..
08:34:43FromDiscord<Elegantbeef> @Phil To explain this to me observables are mostly just map procedures with a value and there is a chain of these?
08:37:38FromDiscord<odexine> In essence, yeah
08:40:49FromDiscord<Elegantbeef> Pmunch looking at itanium's table, oh boy is it fun! https://itanium-cxx-abi.github.io/cxx-abi/abi-mangling.html
08:41:32FromDiscord<Elegantbeef> Luckily for Nim's generated symbols you would not need a lot of those
08:43:46PMunchYeah Nim uses a small subset of these
08:45:41FromDiscord<Elegantbeef> Think it just uses a few primitives `_T` and `_F`
08:50:24PMunchThis is the entry point to Nims mangler: https://github.com/nim-lang/Nim/blob/d09c3c0f58eb9f1f4cf07fa98a9686aa19778f16/compiler/ccgtypes.nim#L58-L69
08:50:52PMunchOf course those encodeX sprawl out a bit
09:04:29FromDiscord<jmgomez> In reply to @PMunch "I really want an": not sure if this is what you are looking for but there is `c++filt`
09:05:48FromDiscord<Elegantbeef> I imagine the issue is going to be `::` and `<>`
09:09:08FromDiscord<jmgomez> the rule is more and less `::` means Nim module and `<>` is a generic type
09:09:56FromDiscord<Elegantbeef> Yea probably can do a `.mutlireplace({"::" : ".", "<": "[", ">", : "]"})`
09:12:48*disso-peach quit (Quit: Leaving)
09:57:31PMunchYes that would bring you close at least
09:57:51PMunchI did notice that destructors get a bit of a strange name
09:58:05PMunchAnd of course the `eq` prefix to types that start with `=`
09:58:41PMunchBut I'm not sure if it's safe to demangle those, what if I had a proc named `equals` for example, I don't want that to be demangled as `=uals`
10:03:18FromDiscord<jmgomez> Yeah, they use the already existing Nim mangle "rules" for names. Defined in `mangleutils` `mangle`
10:05:53*beholders_eye joined #nim
10:32:55*xet7 joined #nim
10:42:40PMunchRight, but it's not a proper two-way function
10:43:43PMunch`equal?` would turn into `equalqmark_` which would then turn back into `=ual?`
10:44:54PMunchSo the question remains, should we even try to demangle names, or only signatures
10:45:40*xet7 quit (Ping timeout: 260 seconds)
10:56:37FromDiscord<nnsee> it's a bit of a shame the mangling is lossy
11:04:57PMunchYeah, it's a bit unfortunate
11:05:31PMunchNow I wonder what happens if I define both `=ual?` and `equal?` in my code with the same signature
11:06:08*xet7 joined #nim
11:07:02PMunchAh, it has a uniqueness counter thingy at the end
11:22:03FromDiscord<jmgomez> You can just do signatures as the names are still readable. You can also postprocess the C gen file and retrieve the Nim name using the line directives (or adding a PR that outputs it to the cgen if a flag is present or just in debug mode)
11:32:18FromDiscord<pmunch> C gen file?
11:33:33FromDiscord<jmgomez> yeah, the Nim compiler output. The ones in the nimcache
11:35:02FromDiscord<pmunch> Oh right.. I'd rather not parse those 😛
11:49:34*xet7 quit (Ping timeout: 246 seconds)
11:56:27*ntat joined #nim
12:01:58*xet7 joined #nim
12:13:20*SchweinDeBurg quit (Read error: Connection reset by peer)
12:13:43*SchweinDeBurg joined #nim
12:23:32*modev joined #nim
12:24:10*modev quit (Client Quit)
13:00:16*xet7 quit (Ping timeout: 268 seconds)
13:03:50FromDiscord<Phil> In reply to @PMunch "Hmm, I'm not up": It's fine, when I'm not on the go I'll whip up an example
13:04:38FromDiscord<Phil> In reply to @Elegantbeef "<@180601887916163073> To explain this": Kiiiind of.↵But also the value is a callback function that forwards one or multiple values to the next member of the chain
13:05:14FromDiscord<Phil> Which member of the chain you define as input param
13:05:54FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=iwTFTnsdWpNh
13:07:16FromDiscord<Phil> Subscriber is an observer which contains 3 callback functions: ↵Next (pushes a new value into this member of the chain) ↵Error(used when an error occurred somewhere along the way) ↵Complete (used when next was called for the last time)
14:04:37*PMunch quit (Quit: Leaving)
14:46:21*ox is now known as oz
14:52:54FromDiscord<nocturn9x> so
14:53:03FromDiscord<nocturn9x> is there a specific reason why the compiler would not produce a stacktrace
14:53:06*xet7 joined #nim
14:53:07FromDiscord<nocturn9x> even when _explicitly told to_
14:53:51FromDiscord<nocturn9x> because it just feels like the compiler is borked at this point
14:53:59FromDiscord<nocturn9x> what is even the point of having an option if it doesn't work
14:54:04FromDiscord<nocturn9x> (edit) "work" => "_work_"
15:04:55FromDiscord<mratsim> In reply to @nocturn9x "is there a specific": even after recompiling it with stacktraces?
15:05:03FromDiscord<nocturn9x> yes
15:05:10FromDiscord<nocturn9x> `--stackTrace --lineTrace` does exactly nothing
15:05:19FromDiscord<nocturn9x> on segfault it just prints "no stack trace available"
15:05:24FromDiscord<nocturn9x> yes thanks very useful
15:05:39FromDiscord<nocturn9x> for context, I'm using two threads
15:05:50FromDiscord<nocturn9x> I'm reasonably sure the crash is occurring not in the main thread
15:06:22FromDiscord<nocturn9x> I have a proc with a `{.cast(gcsafe).}` body because that's the only way it'll ever make nim's thread analysis shut up
15:07:11FromDiscord<nocturn9x> because it's accessing a global variable (only ever reading, never writing) through several abstraction layers
15:07:31FromDiscord<nocturn9x> unfortunately the contents of the global variable are not easily computed at compile time like with most other things
15:07:43FromDiscord<nocturn9x> (edit) "things" => "constant globals I have"
15:18:14FromDiscord<jviega> If it's a null dereference, Nim does not provide a stack trace no matter what.
15:19:07FromDiscord<nocturn9x> it doesn't provide it even if I import `std/segfaults`
15:19:12FromDiscord<nocturn9x> which should turn it into an exception
15:20:48FromDiscord<jviega> In my (non-windows) experience, it does not do it no matter what. I've never taken the time to look into why; if the signal isn't masked, it should be no big deal to handle
15:21:10FromDiscord<jviega> If you're masking the signal then that's obviously always going to be an issue
15:23:56FromDiscord<nocturn9x> I'm not masking it
15:24:40FromDiscord<jviega> Right, and if it's a null pointer deref it still isn't going to work, for whatever reason I don't know. If it's not, then something else is going on
15:28:44FromDiscord<nocturn9x> it's a segfault, it doesn't mean it's necessarily a null pointer deref
15:29:06FromDiscord<nocturn9x> nim segfaults on things that are definitely not null pointer derefs, like overflows
15:29:32FromDiscord<nocturn9x> it may just be an implementation detail of how panics work internally, but it sure as hell ain't helpful
15:30:39*coldfeet joined #nim
15:31:35FromDiscord<jviega> I don't know any other reason you wouldn't be getting a stack trace. Dunno if those flags work or not; compile w/ `-d:debug`
15:32:00FromDiscord<nocturn9x> compiling with debug mode on changes the behavior completely and makes the code too slow to trigger the issue in the first place
15:32:03FromDiscord<nocturn9x> so that is not an option
15:32:26FromDiscord<jviega> Yeah, Nim debug code tends to be ungodly slow :/
15:32:58FromDiscord<jviega> I feel like there might be a flag somewhere that overrides --stackTrace, dunno.
15:34:08FromDiscord<nocturn9x> sent a long message, see https://pasty.ee/BMjDtbOWssRZ
15:34:11FromDiscord<nocturn9x> this is the nim.cfg
15:34:45FromDiscord<nocturn9x> I've tried with -d:release, without LTO, without clang, without any --passC option, nothing seems to work
15:36:28FromDiscord<jviega> What platform?
15:36:55FromDiscord<nocturn9x> x86-64, Linux
15:38:14FromDiscord<jviega> Crap I was going to try to repo, but just realized I am meeting someone for lunch in 5 mins. If you need it when I'm back I can do so
15:38:29FromDiscord<nocturn9x> I'll greatly appreciate the help for sure
15:38:40FromDiscord<nocturn9x> Whenever you can of course
15:39:13FromDiscord<nocturn9x> the issue is this occurs very intermittently when running several parallel instances of the program with cutechess, so it's not like it's easy to reproduce either
15:41:39FromDiscord<Phil> sent a long message, see https://pasty.ee/rhleHDMEAoIw
15:41:56FromDiscord<Phil> (edit) "https://pasty.ee/CIftoSlksdMj" => "https://pasty.ee/xRWUwpchXSKU"
15:42:11FromDiscord<Phil> Oh wow, that message dropped by Kate
15:42:17FromDiscord<Phil> (edit) "Kate" => "late"
15:43:29*ntat quit (Quit: Leaving)
15:58:33*lucerne quit (Quit: Ping timeout (120 seconds))
15:59:57*lucerne joined #nim
16:05:21*coldfeet quit (Remote host closed the connection)
16:14:52*ntat joined #nim
16:15:53FromDiscord<nocturn9x> I was able to nail the issue down to an atomic
16:16:00FromDiscord<nocturn9x> apparently the `load` segfaults
16:16:02FromDiscord<nocturn9x> no idea why or how
16:20:04FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=EMwuioXulqTK
16:20:05*coldfeet joined #nim
16:20:09FromDiscord<nocturn9x> so yeah nim's own stuff is exploding.
16:38:23FromDiscord<nocturn9x> I'm trying to see if using atomic ARC or -d:useMalloc changes anything
16:44:50FromDiscord<juancarlospaco> looks like a realloc on a nil
17:14:05*beholders_eye quit (Ping timeout: 245 seconds)
17:55:49FromDiscord<marioboi3112> can i run nim anywhere where you can run C?
17:59:33FromDiscord<@jeff-ciesielski-57e3f30d40f3a6e> With appropriate compiler options\: Yes↵(@marioboi3112)
18:00:15FromDiscord<polylokh_39446> not quite. You can compile C on platforms without atomics for example. If you search the github you'll find old issues about building it on OpenBSD. That's probably no longer a problem, but that same kind of thing can come up with weird platforms.
18:01:04FromDiscord<polylokh_39446> the useful answer is probably: strictly, no, but practically, yes.
18:01:26FromDiscord<marioboi3112> In reply to @@jeff-ciesielski-57e3f30d40f3a6e "With appropriate compiler options\:": can you please elaborate more when you mean by "appropriate compiler options"?
18:01:46FromDiscord<polylokh_39446> for example, there's an option to get you around missing atomics.
18:01:51FromDiscord<marioboi3112> In reply to @polylokh_39446 "not quite. You can": i see
18:03:38FromDiscord<marioboi3112> so the majority of machines, including consoles (PS, XBOX, etc), should be able to run nim, or atleast the compiled code from nim
18:07:17FromDiscord<polylokh_39446> how practical or convenient that is will vary. iOS used to limit the languages that could be used for apps, which meant you could develop apps for it in Nim but then not be able to honestly publish them on the store. That kind of stuff can happen. Nim's useful on my RISCV DevTerm, it's very portable, but if you have specific targets you should confirm that you can build for them.
18:07:59FromDiscord<marioboi3112> In reply to @polylokh_39446 "how practical or convenient": ok what about specifically android and consoles then
18:10:39FromDiscord<polylokh_39446> AFAIK consoles have C++ toolchains that Nim is probably good at working with with its C++ backend, but I don't know about them. Maybe github will have some example projects. Android and iOS (what I just mentioned was a historical limitation, not a current one) you can do, but you'll probably want a shim in Kotlin or Swift for the UI.
18:15:16FromDiscord<marioboi3112> In reply to @polylokh_39446 "AFAIK consoles have C++": i would need to use kotlin or swift for the UI, cause if you take nitter as an example it has decent UI, made in nim, and also works on mobiles
18:15:54FromDiscord<marioboi3112> (edit) "UI," => "UI?"
18:19:00FromDiscord<polylokh_39446> sent a long message, see https://pasty.ee/ZZONjzwKRyxI
18:19:21FromDiscord<polylokh_39446> (edit) "https://pasty.ee/iVGPTuWommVp" => "https://pasty.ee/ifzuLPIaRjJv"
18:19:42FromDiscord<polylokh_39446> (edit) "https://pasty.ee/hFEAjRqMhVRx" => "https://pasty.ee/FCFlkJYukwct"
18:20:45FromDiscord<polylokh_39446> but you really can do most of the work in Nim. It's not just a lie like people recommending Clojure (multiple-second startup times for hello world) or Scala (it seems to work until you blow through dalvik limitiations and nothing works anymore)
18:23:09FromDiscord<polylokh_39446> here's someone dodging the shim: <https://github.com/akavel/hellomello>
18:23:20FromDiscord<marioboi3112> In reply to @polylokh_39446 "the issue isn't 'need',": i see
18:25:12FromDiscord<marioboi3112> In reply to @polylokh_39446 "here's someone dodging the": interesting
18:31:42*rockcavera joined #nim
19:04:06FromDiscord<z3ntl3> 🫡
19:36:30*ntat quit (Quit: Leaving)
19:50:44FromDiscord<.lisuwu_> @Robyn [She/Her] and Elegantbeef, wanted to update on things:↵I've got it working, the key was `--os:standalone -d:useMalloc`, and I've decided to go back to 1.6.20 to get that annoying setjmp away from me, but now it works, thanks again! https://media.discordapp.net/attachments/371759389889003532/1234955112573698139/image.png?ex=66329d13&is=66314b93&hm=55ec18402e6a9975d22ae64cb829f18ce9bac508a9d3a63ba274116b33362c41&
19:56:40*coldfeet quit (Remote host closed the connection)
20:35:30FromDiscord<ElegantBeef> @.lisuwu_ `--os:any` is meant to be used over `standalone` and you really shouldn't need to use 1.6 so you probably should make a github issue
20:36:05FromDiscord<.lisuwu_> In reply to @elegantbeef "<@351656397257310212> `--os:any` is meant": the fix is on devel, it's just i can't really be asked to compile the compiler
20:36:56FromDiscord<.lisuwu_> (edit) "devel," => "devel already," | "compiler" => "compiler↵`--os:any` generates C code that includes stdlib and stdio which i don't really want to bother writing support for when it shouldn't even generate things like that"
20:48:28FromDiscord<Robyn [She/Her]> In reply to @.lisuwu_ "<@524288464422830095> and Elegantbeef, wanted": Eyyy, it's progress!
21:00:43*rockcavera quit (Remote host closed the connection)
21:05:18*rockcavera joined #nim
21:09:31FromDiscord<saint.___.> Y Y
22:58:42*oprypin quit (Quit: Bye)
22:58:51*oprypin joined #nim
23:00:01*marcus quit (Remote host closed the connection)
23:00:42*marcus joined #nim
23:50:26*redj_ joined #nim
23:53:43FromDiscord<amarevite> sent a long message, see https://pasty.ee/WkYznVWlHYtN