<< 12-12-2024 >>
00:28:02*attah quit (Ping timeout: 272 seconds)
00:28:30*attah joined #nim
00:42:18*attah quit (Ping timeout: 252 seconds)
00:43:04*attah joined #nim
00:50:10*attah_ joined #nim
00:50:16*attah quit (Ping timeout: 252 seconds)
00:50:45*attah_ is now known as attah
01:08:47FromDiscord<.throwstar> staticRead doesnt seem to account for new lines
01:16:46FromDiscord<demotomohiro> `staticRead` should read the file as is.↵Maybe it is windows's crlf things.
01:18:17FromDiscord<.throwstar> Im on linux
01:22:18FromDiscord<demotomohiro> https://play.nim-lang.org/#pasty=ZgiwlDty↵`staticRead` reads new lines.
01:22:46FromDiscord<.throwstar> Oh I meant in the output it doesnt account for them
01:22:50FromDiscord<.throwstar> At least for js
01:22:56FromDiscord<.throwstar> sent a code paste, see https://play.nim-lang.org/#pasty=YOQkvYSh
01:27:06FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=ygGrHfND
01:31:29FromDiscord<demotomohiro> parameter without `var` is immutable. You should add var if you want to change it.
01:32:22FromDiscord<.throwstar> Doesnt really matter for me, it all happens at compile time anyway
01:35:54*_________ quit (Ping timeout: 246 seconds)
01:37:01*_________ joined #nim
01:38:21FromDiscord<Elegantbeef> Demo you could do `str: sink string` and return the mutate string
01:38:36FromDiscord<Elegantbeef> mutated\
01:43:34FromDiscord<k0ts> This whole exchange is so confusing to me. Account for newlines means replace them with spaces? Why not just strutils.replace?
01:46:27FromDiscord<.throwstar> newlines arent escaped in output leading to broken code https://media.discordapp.net/attachments/371759389889003532/1316581904912486452/image.png?ex=675b91f3&is=675a4073&hm=38d8fbdd953d88e6c5ed613ae13fa5b6c5ceaf80e7d961b23497e50d497d164e&
01:46:36FromDiscord<.throwstar> Also i didnt know .replace was a thing
01:46:45FromDiscord<demotomohiro> @ElegantBeef I forgot about `sink` parameter.
03:14:59*rockcavera quit (Remote host closed the connection)
03:32:07*krux02 quit (Remote host closed the connection)
03:41:55FromDiscord<.tokyovigilante> If I pass a Nim object as a pointer through a C function, then cast it back to the object type in a callback, can I change the object's variables and have those changes reflected back in the initial object?
03:42:42FromDiscord<.tokyovigilante> Concretely, I'm using libcurl, and have a request object tracking the download state, I want to attach the response headers to that object when they come back in the relevant libcurl callback
03:42:54FromDiscord<demotomohiro> Yes, as long as that Nim object alives.
03:43:50FromDiscord<.tokyovigilante> Thanks, it doesn't seem to work for me currently though
03:45:20FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=gKXPSmEa
03:46:09FromDiscord<.tokyovigilante> This is called each time a header is recieved and I'm appending the header to the request object (which has a header `Table`) but if I dump out the request object at the end of the function, it only shows the current one
03:47:48FromDiscord<.tokyovigilante> presumably the `var request` object is a copy which is discarded, should I be just using `cast` every time I want to access the object inside `data`?
03:49:20FromDiscord<demotomohiro> Is `Request` ptr or ref type?
03:50:47FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=VxzldNhk
03:55:32FromDiscord<.tokyovigilante> Yup an object type. Thanks that make sense
04:34:50FromDiscord<Array 🇵🇸🇸🇩🇸🇾🇨🇩> its been 1y since jester's last commit sad
04:34:57FromDiscord<Array 🇵🇸🇸🇩🇸🇾🇨🇩> its been exactly 1y since jester's last commit sad
04:36:31FromDiscord<odexine> do not expect it to be maintained by the same developer or to be transferred
04:37:05FromDiscord<odexine> the dev of that left the community in a non-friendly sense (im not good at english right now)
05:24:56FromDiscord<Array 🇵🇸🇸🇩🇸🇾🇨🇩> oh really? i did not know↵(@odexine)
05:25:10FromDiscord<Array 🇵🇸🇸🇩🇸🇾🇨🇩> i wasnt expecting it but i could only hope lol↵(@odexine)
05:54:49*SchweinDeBurg quit (Quit: WeeChat 4.5.0-dev)
05:55:14*SchweinDeBurg joined #nim
07:00:34FromDiscord<nnsee> In reply to @.throwstar "newlines arent escaped in": why would staticRead escape anything? it reads a file byte by byte
07:03:12FromDiscord<nnsee> In reply to @.throwstar "newlines arent escaped in": this seems more like a codegen bug than anything to do with staticRead although I'm not sure how this could happen
07:03:50FromDiscord<nnsee> are strings with newlines simply broken in the js backend?
07:10:51FromDiscord<Elegantbeef> @nnsee We'll never know they did not provide a min repro
07:19:07*GreaseMonkey quit (*.net *.split)
07:19:07*nils` quit (*.net *.split)
07:19:08*fallback quit (*.net *.split)
07:19:09*m5zs7k quit (*.net *.split)
07:19:11*khazakar quit (*.net *.split)
07:19:16*m5zs7k_ joined #nim
07:24:17*GreaseMonkey joined #nim
07:24:18*nils` joined #nim
07:24:18*fallback joined #nim
07:24:18*khazakar joined #nim
07:28:24*m5zs7k_ is now known as m5zs7k
08:44:53Amun-Raoh, I miss all the drama (@dom)
09:05:53FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=nIklyekC
09:05:59FromDiscord<nocturn9x> genuinely, truly, seriously fuck nim threads.
09:06:05FromDiscord<nocturn9x> (`bestMove` runs in a separate thread)
09:06:33FromDiscord<nocturn9x> this was run with `-d:debug`, `--debugger:native` and `--passC:"-fno-omit-frame-pointer -g3`
09:06:37FromDiscord<nocturn9x> and yet I still get nothing
09:06:38FromDiscord<nocturn9x> WHY
09:22:41ehmrythreads are always bad, it's not just a nim thing
09:41:51FromDiscord<Elegantbeef> I know writing my hot code reload I get a tonne of hard to debug errors due to corrupting memory in one way or another
09:42:49FromDiscord<nnsee> hey beef, do you have a new keyboard
09:42:51FromDiscord<Elegantbeef> Similar levels of "Well how the fuck do I even start"
09:43:14FromDiscord<Elegantbeef> I didn't make a spelling mistake so I have a new keyboard?
09:45:07FromDiscord<nocturn9x> In reply to @ehmry "threads are always bad,": nono
09:45:10FromDiscord<nocturn9x> let's not kid ourselves
09:45:17FromDiscord<nocturn9x> threads are annoying to work with
09:45:20FromDiscord<nocturn9x> but in nim it's a fucking travesty
09:45:32ehmrythreads make stuff slow
09:45:39FromDiscord<nocturn9x> that is not my problem
09:45:47FromDiscord<nocturn9x> my problem is threads fucking with tracebacks
09:45:54FromDiscord<Elegantbeef> The fact that Nim threads cannot be stack allocated or moved is funny
09:46:06FromDiscord<nnsee> In reply to @Elegantbeef "I didn't make a": no, you've just been spelling things weirdly lately
09:46:21FromDiscord<Elegantbeef> Heh
09:46:22FromDiscord<nnsee> In reply to @Elegantbeef "I know writing ": for example, there are two double spaces in this sentence
09:46:43FromDiscord<Elegantbeef> Double spaces are me editing the sentence and not noticing the extra space when typing
09:46:44FromDiscord<nocturn9x> I've been trying to debug some random crashes in my engine
09:46:49FromDiscord<nocturn9x> and I can't get systemd to dump a fucking core file
09:46:53FromDiscord<nocturn9x> the tracebacks are useless
09:46:58FromDiscord<nocturn9x> and I can't reproduce the crash
09:47:08FromDiscord<nnsee> you don't need systemd for the coredump
09:47:08FromDiscord<nocturn9x> what am I supposed to do, pray to the gods that the solution comes to me in my sleep?
09:47:14FromDiscord<Elegantbeef> Did you mark the procedures `{.raises: [].}` it'll reduce some headaches
09:47:16FromDiscord<nocturn9x> In reply to @nnsee "you don't need systemd": it's in a service
09:47:25FromDiscord<nocturn9x> In reply to @Elegantbeef "Did you mark the": what does that do exactly
09:47:36FromDiscord<nocturn9x> also, context: I use `--panics:on` (it's faster)
09:47:48FromDiscord<Elegantbeef> Forces you to handle all the exceptions a thread may raise so you do not get ughness
09:48:05FromDiscord<nocturn9x> this is segfaulting
09:48:09FromDiscord<nocturn9x> it's not an exception
09:48:09FromDiscord<nocturn9x> lol
09:48:18FromDiscord<nnsee> In reply to @nocturn9x "it's in a service": irrelevant, you can simply do `echo "/tmp/core.%e.%p.%t" | sudo tee /proc/sys/kernel/core_pattern` and get it to dump coredumps in /tmp
09:48:21FromDiscord<Elegantbeef> Oh I know I was just providing some help
09:48:26FromDiscord<nnsee> this is a kernel feature, unrelated to systemd
09:48:29FromDiscord<nocturn9x> In reply to @nnsee "irrelevant, you can simply": you think I haven't tried?
09:48:34FromDiscord<nocturn9x> it works fine for simple standalone programs
09:48:40FromDiscord<nocturn9x> but the engine is ran as a subprocess of a subprocess
09:48:44FromDiscord<nocturn9x> and it doesn't dump shit.
09:48:57FromDiscord<nocturn9x> In reply to @Elegantbeef "Oh I know I": thanks, btw
09:49:03FromDiscord<nocturn9x> I'm just very very very very frustrated right now
09:49:10FromDiscord<Elegantbeef> Also if that was built as debug you should get more in your stacktrace
09:49:18FromDiscord<nocturn9x> yeah, and yet
09:49:20FromDiscord<nocturn9x> I don't
09:49:25FromDiscord<Elegantbeef> `-d:debug` isn't a thing
09:49:33Amun-Rannsee: yes and no
09:49:43FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=coBQZcbz
09:49:46FromDiscord<nocturn9x> this is what I get
09:49:47FromDiscord<nocturn9x> lol
09:49:50FromDiscord<nocturn9x> useless as shit
09:50:04FromDiscord<Elegantbeef> That's a release stacktrace
09:50:07FromDiscord<nocturn9x> no it's not.
09:50:07Amun-Ranocturn9x: there's systemd-coredump in debian, the part of that behemoth that allows you to inspect cores
09:50:10FromDiscord<nocturn9x> I'm telling you
09:50:11FromDiscord<nnsee> In reply to @nocturn9x "you think I haven't": no need to get sassy
09:50:15FromDiscord<Elegantbeef> It certainly is
09:50:17FromDiscord<nocturn9x> sorry, I'm just pissed off
09:50:18FromDiscord<nnsee> i'm just trying to help
09:50:21FromDiscord<nocturn9x> In reply to @Elegantbeef "It certainly is": dudeù
09:50:23FromDiscord<nocturn9x> (edit) "dudeù" => "dude"
09:50:32FromDiscord<nocturn9x> let me be excruciatingly clear
09:50:33FromDiscord<Elegantbeef> A full stack trace includes the file path
09:50:38FromDiscord<nocturn9x> that was generated in debug mode.
09:50:40FromDiscord<nnsee> that being said i don't understand why it being a subprocess matters, the core dump should be generated regardless
09:50:45FromDiscord<nnsee> unless you have some weird limits set up
09:50:48FromDiscord<Elegantbeef> `--stackTrace:on --lineTrace:on`
09:50:50FromDiscord<Elegantbeef> There is no debug mode
09:50:57FromDiscord<nocturn9x> I had those on
09:51:01FromDiscord<nocturn9x> I'll try again
09:51:06FromDiscord<nocturn9x> but it failed before
09:51:22FromDiscord<nocturn9x> so you're saying `-d:debug --stackTrace:on --lineTrace:on` and I assume `--debugger:native` as well?
09:51:25FromDiscord<Elegantbeef> Just making sure you do not have `-d:release` or `-d:danger`
09:51:36FromDiscord<nnsee> @nocturn9x is there a link to your code somewhere so i can try it out?
09:51:40FromDiscord<Elegantbeef> `--debugger:native` is for using attached debuggers
09:51:48FromDiscord<Elegantbeef> So if you're just expecting Nim stacktraces it doesn't matter
09:51:52FromDiscord<nocturn9x> In reply to @nnsee "<@523555920265871380> is there a": https://git.nocturn9x.space/nocturn9x/heimdall
09:51:56FromDiscord<nocturn9x> In reply to @Elegantbeef "So if you're just": gotcha
09:52:06FromDiscord<nocturn9x> In reply to @nocturn9x "https://git.nocturn9x.space/nocturn9x/heimdall": it is a very large project btwù
09:52:08FromDiscord<nocturn9x> (edit) "btwù" => "btw"
09:52:10FromDiscord<nocturn9x> ~5.5kLOC
09:52:10Amun-Rannsee: I installed systemd-coredump and my debian now dumps cores
09:52:17Amun-Raargh
09:52:20FromDiscord<nocturn9x> I have coredumpctl
09:52:22FromDiscord<nocturn9x> it does dump cores
09:52:22Amun-Ranocturn9x: ^
09:52:25FromDiscord<nocturn9x> it just doesn't do it for the engine
09:52:32FromDiscord<Elegantbeef> I like the name due to it being a Stargate asgard character 😄
09:52:32FromDiscord<nocturn9x> I don't know why
09:52:34FromDiscord<nnsee> In reply to @Amun-Ra "<@961485620075720734>: I installed systemd-coredump": yes, because your coredump pattern is set to pipe to systemd-coredump
09:52:38FromDiscord<nnsee> because debian does that
09:52:40FromDiscord<nocturn9x> even when I run the script
09:52:43FromDiscord<nocturn9x> it does not dump them
09:52:51FromDiscord<nnsee> but you absolutely don't need it, you can simply change the pattern
09:52:52FromDiscord<nocturn9x> I don't know what to tell you lmao
09:53:04FromDiscord<nocturn9x> In reply to @nnsee "but you absolutely don't": I did, and it dumps cores for programs I start and kill manually
09:53:07FromDiscord<nocturn9x> still doesn't do it for my engine
09:53:11FromDiscord<nocturn9x> not sure what to tell you 🤷
09:53:30FromDiscord<nnsee> I will have a look
09:53:34FromDiscord<nnsee> cloning the project now
09:53:39FromDiscord<nocturn9x> the flow is my bash script calls a python script, which starts a program called cutechess which is a game manager
09:53:39FromDiscord<nnsee> how do I trigger the bug?
09:53:41FromDiscord<nocturn9x> cutechess will start processes of the engine
09:53:46FromDiscord<nocturn9x> In reply to @nnsee "how do I trigger": that's the point
09:53:48FromDiscord<nocturn9x> I have no fucking clue
09:53:49FromDiscord<nocturn9x> lol
09:53:53FromDiscord<nocturn9x> if I did I wouldn't be here lmao
09:54:00FromDiscord<nocturn9x> I can only make it happen if I run tests at very low time control
09:54:04FromDiscord<nocturn9x> but I can get no information about it
09:54:15FromDiscord<nocturn9x> and it doesn't happen on my local machine either, just on my servers
09:54:21FromDiscord<Elegantbeef> Not to be annoying, but looking at the make file did you remove the flags for `-d:danger` when you made the "debug" build?
09:54:23Amun-Rannsee: oh, you're right, I haven't noticed that change
09:54:31FromDiscord<nocturn9x> In reply to @Elegantbeef "Not to be annoying,": there is a `debuggable` branch
09:54:47FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=zFXpHoKu
09:54:57FromDiscord<nnsee> well that's something i haven't seen before https://media.discordapp.net/attachments/371759389889003532/1316704834149417072/image.png?ex=675c046f&is=675ab2ef&hm=fe285996b5638de9ef6dc1f927effa1f0b58c59f601f943cb9ee0986a1e12958&
09:54:59FromDiscord<nocturn9x> In reply to @Elegantbeef "Not to be annoying,": wait, actually
09:55:07FromDiscord<nocturn9x> In reply to @nnsee "well that's something i": forgot to migrate them to LFS yeah
09:55:16FromDiscord<nocturn9x> In reply to @Elegantbeef "Not to be annoying,": fuck you're right
09:55:20FromDiscord<nocturn9x> the makefile still has -d:danger
09:55:21FromDiscord<nocturn9x> bruhù
09:55:22FromDiscord<nocturn9x> (edit) "bruhù" => "bruh"
09:55:33FromDiscord<nocturn9x> the software I use to run tests doesn't do nimble build
09:55:36FromDiscord<nocturn9x> it only uses it for dependencies
09:55:42FromDiscord<nocturn9x> so that would explain the unhelpful traceback
09:55:57FromDiscord<nocturn9x> let me try and change that
09:56:28FromDiscord<Elegantbeef> No `-d:debug` has bit me before aswell
09:56:38FromDiscord<nocturn9x> no the thing is
09:56:41FromDiscord<nocturn9x> I did add `-d:debug`
09:56:46FromDiscord<nocturn9x> it definitely reads it from the nim.cfg
09:56:52FromDiscord<nocturn9x> the problem is there's _also_ -d:danger
09:56:55FromDiscord<Elegantbeef> Spent quite a long time trying to find where the hell my opengl log was
09:56:57FromDiscord<nocturn9x> so that fucks things up for sure
09:57:09FromDiscord<nocturn9x> I am
09:57:10FromDiscord<nocturn9x> so stupid
09:57:12FromDiscord<Elegantbeef> Right, but I just mean that you'd expect `-d:debug` to force a debug build
09:57:30FromDiscord<Elegantbeef> You'd also expect `-d:debug` to be set if no optimisation flag is defined
09:57:47FromDiscord<nocturn9x> In reply to @Elegantbeef "Right, but I just": yeah this is why I think nim's system is a bit flawed
09:58:00FromDiscord<nocturn9x> as in, I would expect at the very least a warning if debug/release/danger are used together
09:58:06FromDiscord<nocturn9x> would expect them to be mutually exclusive
09:58:29FromDiscord<Elegantbeef> well really they shouldn't be a define and an opt flag and then it's more sensible
09:58:49FromDiscord<nocturn9x> yep
09:58:50FromDiscord<nocturn9x> agreed
10:00:26FromDiscord<Elegantbeef> Anywho you can use the `--stackTrace:on --lineTrace:on` for if you want to have useful stack traces in release builds
10:00:52FromDiscord<Elegantbeef> It'll be more bloaty and can leak information, but it's more helpful in a crash on a remote client
10:01:45FromDiscord<nocturn9x> In reply to @Elegantbeef "Anywho you can use": that still does almost nothing with -d:danger afaik
10:01:50FromDiscord<nocturn9x> never tried with release tho
10:02:05FromDiscord<Elegantbeef> It should produce an identical result to danger
10:04:00FromDiscord<odexine> it does, as long as the flags come after the --define
10:04:19FromDiscord<nocturn9x> wait so `-d:danger` _unsets_ them?
10:04:22FromDiscord<odexine> yes
10:04:23FromDiscord<nocturn9x> I mean it makes sense
10:04:28FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=bjpuRabq
10:04:31FromDiscord<Elegantbeef> Just to confirm
10:04:47FromDiscord<nocturn9x> gotcha
10:05:25FromDiscord<Elegantbeef> There is also `excessiveStackTrace` if you want the file path aswell
10:06:04FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=pFRtDpWV
10:06:16FromDiscord<nocturn9x> I see
10:06:43FromDiscord<Elegantbeef> Arguably the bloat is worth the diagnostic information
10:07:20FromDiscord<nocturn9x> honestly getting a call stack at all would already be wonderful
10:29:14*tokyovigilante quit (Ping timeout: 252 seconds)
10:32:30*tokyovigilante joined #nim
10:35:51FromDiscord<nocturn9x> SUCCESS!!!!!!!
10:36:00FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=ktRrOxfv
10:36:41FromDiscord<odexine> Congratulations
10:36:51FromDiscord<odexine> Headache #1 over
10:37:00FromDiscord<odexine> On to the next headache 😂
10:41:50FromDiscord<nocturn9x> I can easily fix that
10:41:55FromDiscord<nocturn9x> assuming this is truly the issue
10:45:07FromDiscord<nocturn9x> aaaand of course it's not
10:47:00FromDiscord<nocturn9x> or maybe I just didn't fix the issue idk
10:47:02FromDiscord<nocturn9x> I'll test again
10:59:20*Batzy left #nim (https://quassel-irc.org - Chat comfortably. Anywhere.)
11:13:14Amun-Ranice!
11:19:29FromDiscord<nocturn9x> problem
11:19:31FromDiscord<nocturn9x> I'm getting this
11:19:48FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=ZUbmCRzy
11:19:52FromDiscord<nocturn9x> however this isn't possible
11:20:14FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=eONpKvrf
11:20:25FromDiscord<nocturn9x> but that's impossible, the total value of all scores is 16384
11:20:29FromDiscord<nocturn9x> so at best it could be 16384 3
11:20:35FromDiscord<nocturn9x> definitely not enough to either over or underflow...
11:21:08FromDiscord<nocturn9x> I feel like these are just random crashes stemming from memory corruption...
11:21:10FromDiscord<nnsee> might be worth echoing the score in the loop
11:21:26FromDiscord<nnsee> just to double verify
11:21:27FromDiscord<nocturn9x> In reply to @nocturn9x "I feel like these": ^
11:21:42FromDiscord<nocturn9x> I got another one just now
11:21:46FromDiscord<nocturn9x> sent a code paste, see https://play.nim-lang.org/#pasty=vuVcvBGK
11:22:02FromDiscord<nocturn9x> again this, which is impossible because I have an `if ply >= MAX_DEPTH: return`...
11:22:23FromDiscord<nocturn9x> ah, no wait, I pushed the wrong fix
11:22:24FromDiscord<nnsee> does smell a bit like memory corruption
11:22:26FromDiscord<nocturn9x> it should be depth not ply
11:22:28FromDiscord<nocturn9x> me is moron
11:22:29FromDiscord<nocturn9x> again
11:23:16FromDiscord<odexine> 5kloc melting your brain
11:23:21FromDiscord<nocturn9x> let's see if it still happens with the updated fix
11:23:24FromDiscord<nocturn9x> In reply to @odexine "5kloc melting your brain": fr
11:27:09FromDiscord<nocturn9x> yeah it still crashes
11:27:11FromDiscord<nocturn9x> sigh
11:27:18FromDiscord<nocturn9x> fuck.
11:31:12FromDiscord<nocturn9x> how do I debug this 😭
11:32:01Amun-Raany particular reason to use 16-bits?
11:32:46Amun-RaI mean, unless you need arithmetic to be slower on modern architectures ;)
11:34:31FromDiscord<nocturn9x> they're not actually 16 bit
11:34:34FromDiscord<nocturn9x> they're int32s
11:34:41FromDiscord<nocturn9x> the value is just constrained to 16 bits
11:34:58FromDiscord<nocturn9x> it uses a formula so that the value is within +/-16384
11:36:13Amun-Rak
11:51:07FromDiscord<nocturn9x> what could be causing the memory corruption?
11:51:15FromDiscord<nocturn9x> the issue seems to disapper if I don't use `createThread`
11:51:17FromDiscord<nocturn9x> so that may be it
11:51:23FromDiscord<nocturn9x> (edit) "disapper" => "disappear"
11:51:39FromDiscord<nocturn9x> I could retest that actually
11:56:57FromDiscord<nocturn9x> well that's not it at least
11:57:04FromDiscord<nocturn9x> seems like it still happens even if I don't spawn a new thread
11:57:31FromDiscord<nocturn9x> well that's... reassuring at least?
11:58:51FromDiscord<nocturn9x> no idea what the issue is tho
11:59:53FromDiscord<nocturn9x> does anything in this function look weird to anyone here? <https://git.nocturn9x.space/nocturn9x/heimdall/src/branch/master/heimdall/heimdallpkg/search.nim>
11:59:59FromDiscord<nocturn9x> something that could segfault/overflow/whatever?
12:08:34FromDiscord<fabric.input_output> damn bro that's a lot of code
12:11:54*Goodbye_Vincent1 joined #nim
12:13:40FromDiscord<nocturn9x> 🤷
12:14:31FromDiscord<nocturn9x> In reply to @nocturn9x "the line here is": I keep getting overflow errors here
12:14:43FromDiscord<nocturn9x> @tsoj you don't happen to have any ideas do you
12:20:18FromDiscord<tsoj> i have lots of ideas
12:20:54FromDiscord<tsoj> specifically for your problem i don't have any though
12:21:00FromDiscord<nocturn9x> lol
12:21:01FromDiscord<tsoj> i can take a look at it later today
12:21:07FromDiscord<nocturn9x> thanks <3
12:21:11FromDiscord<nocturn9x> would appreciate
13:08:18FromDiscord<demotomohiro> You use unsafe features like `ptr` or `noinit`. And if you have problems that you cannot fix yourself, you would better to avoid using them even if your code slower.↵If you still want to use unsafe things, you might need to learn low level things (assembly, C, data structure of Nim types) until you can understand how your code works in low level and use unsafe feature correctly.
13:16:08Amun-Raand newMoveList name is misleading
13:16:55Amun-Radoes noinit make sense when not used in variable declaration?
13:17:48Amun-RaI mean var foo {.noinit.}: Foo is fine but var foo {.noinit.} = initFoo() is weird
13:42:24*beholders_eye joined #nim
14:04:25*hovsater left #nim (#nim)
14:40:29*ntat joined #nim
15:20:04FromDiscord<.throwstar> In reply to @nnsee "why would staticRead escape": It works fine when its a multiline string but not if I get it with staticRead so I assumed the issue was there
15:28:32FromDiscord<.throwstar> I will note that the `"`s are escaped but not the newlines
15:50:48*def- quit (Ping timeout: 252 seconds)
15:50:59*def- joined #nim
15:56:00*syl_ joined #nim
15:57:02*syl quit (Ping timeout: 252 seconds)
16:38:04*nils` quit (Ping timeout: 260 seconds)
16:38:46FromDiscord<k0ts> I cannot reproduce this
16:44:50*disso-peach quit (Quit: Leaving)
17:24:47*nils` joined #nim
17:50:48*krux02_ joined #nim
18:02:11FromDiscord<nnsee> In reply to @.throwstar "It works fine when": can you post more of your code for context
18:15:17FromDiscord<.throwstar> Ok I looked into it more and it was more specific than I thought
18:15:59FromDiscord<.throwstar> Im running a bash script that edits the output as an `after build:` task in the nimble file
18:17:18FromDiscord<.throwstar> When this script is run in a normal terminal it properly outputs the newlines as `'\n'` but when its run as an `exec` in a `nims` it actually puts a new line in the output
18:17:28FromDiscord<.throwstar> Thats weird
18:17:43FromDiscord<.throwstar> (edit) "`nims`" => "`.nims` file"
18:18:21FromDiscord<solitudesf> thats crazy
18:18:26FromDiscord<.throwstar> Indeed
18:22:40FromDiscord<.throwstar> sent a code paste, see https://play.nim-lang.org/#pasty=KiWkDJmU
18:23:03FromDiscord<.throwstar> (edit) "https://play.nim-lang.org/#pasty=UrjnbXrv" => "https://play.nim-lang.org/#pasty=RPhWPanZ"
18:37:33*beholders_eye quit (Ping timeout: 252 seconds)
18:49:03*beholders_eye joined #nim
20:15:10*FromDiscord quit (Remote host closed the connection)
20:15:23*FromDiscord joined #nim
20:16:36*beholders_eye quit (Ping timeout: 276 seconds)
20:48:06FromDiscord<nocturn9x> so as it turns out
20:48:10FromDiscord<nocturn9x> there was an issue in my logic
20:48:15FromDiscord<nocturn9x> crashes are gone now
20:55:41FromDiscord<Elegantbeef> @nocturn9x I have to meme at you and say I heard the threads say "Fucking Matt"
20:59:30*beholders_eye joined #nim
21:29:25*beholders_eye quit (Ping timeout: 248 seconds)
21:41:31FromDiscord<.bobbbob> It's like a spider, threads are more scared of you then you are of them
21:41:42FromDiscord<.bobbbob> That's why they act up so much
21:43:43*rockcavera joined #nim
21:49:31FromDiscord<aintea> Threads are useless, just buy a higher clock speed one core only CPU and don't run anything else on your machine (not even an OS)
21:58:33*ntat quit (Quit: Leaving)
22:01:44FromDiscord<nocturn9x> In reply to @Elegantbeef "<@523555920265871380> I have to": 😂😭
22:14:04FromDiscord<System64 ~ Flandre Scarlet> If I statically link my Nim program with glibc, my program is lgpl?
22:14:30FromDiscord<Elegantbeef> Why would you statically link glibc
22:14:55FromDiscord<Elegantbeef> Target the oldest glibc you want to support either manually, with zigcc, or target musl
22:15:06FromDiscord<nnsee> _how_ would you statically link glibc
22:15:13FromDiscord<Elegantbeef> Very carefully
22:15:35FromDiscord<nnsee> i'm fairly certain you can't
22:15:46FromDiscord<nnsee> it won't let you
22:15:55FromDiscord<nnsee> unless you remove name resolution entirely
22:16:02FromDiscord<Elegantbeef> Not with that attitude, but yes it's clearly a misunderstanding of how glibc works
22:16:08FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Target the oldest glibc": wait, zigcc doesn't use glibc?
22:16:16FromDiscord<nnsee> it uses musk
22:16:20FromDiscord<nnsee> musk, even
22:16:23FromDiscord<System64 ~ Flandre Scarlet> 🤣
22:16:25FromDiscord<nnsee> m
22:16:26FromDiscord<nnsee> u
22:16:29FromDiscord<nnsee> sl
22:16:41FromDiscord<Elegantbeef> You can target glibc and musl with zigcc
22:16:50FromDiscord<nnsee> wait you can??
22:17:07FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "You can target glibc": and what if I want to cross-compile to Windows?
22:17:10FromDiscord<Elegantbeef> zigcc has old versions of glibc so you can target it and it has the older version of glibc as your lowend
22:17:31FromDiscord<Elegantbeef> `--cc:clang --clang.exe:zigcc --clang.linkerexe:zigcc --passC="-target x86_64-linux-gnu.2.16" --passL="-target x86_64-linux-gnu.2.16"`
22:17:40FromDiscord<Elegantbeef> You can use zigcc still
22:17:41FromDiscord<Elegantbeef> Or you can use mingw
22:17:48FromDiscord<Elegantbeef> I prefer the latter as it's easier with nim
22:17:50FromDiscord<System64 ~ Flandre Scarlet> I use mingw for Windows
22:17:56FromDiscord<System64 ~ Flandre Scarlet> (edit) "I use mingw for Windows ... " added "cross-compilation"
22:18:03FromDiscord<System64 ~ Flandre Scarlet> but isn't my program LGPL now?
22:18:19FromDiscord<Elegantbeef> No?
22:18:48FromDiscord<Elegantbeef> LGPL is by it's nature not viral for dynamic linking
22:18:51FromDiscord<Elegantbeef> You're thinking of GPL
22:19:05FromDiscord<Elegantbeef> static linking of a GPL program would make it GPL
22:19:08FromDiscord<System64 ~ Flandre Scarlet> But what if I statically link glibc in mingw?
22:19:19FromDiscord<System64 ~ Flandre Scarlet> (edit) "in" => "with"
22:19:29FromDiscord<Elegantbeef> Static linking of lgpl is viral
22:19:36FromDiscord<Elegantbeef> But you're not static linking glibc with mingw afaik
22:19:48FromDiscord<System64 ~ Flandre Scarlet> What does mingw use?
22:20:03FromDiscord<Elegantbeef> Windows libraries
22:20:28FromDiscord<System64 ~ Flandre Scarlet> Oh
22:25:01FromDiscord<System64 ~ Flandre Scarlet> And what about Clang?
22:25:57FromDiscord<Elegantbeef> Build a program and use `ldd`
22:29:08FromDiscord<System64 ~ Flandre Scarlet> Oh, I can use musl so maybe there is a way to tall Nim to use Musl instead of glibc
22:29:19FromDiscord<nocturn9x> yes
22:29:22FromDiscord<nocturn9x> I did that in the past
22:29:24FromDiscord<nocturn9x> works pretty well
22:29:32FromDiscord<nocturn9x> don't actually remember how though
22:29:47FromDiscord<nocturn9x> nim only depends on _any_ libc, which is nice
22:29:54*termer quit (Read error: Connection reset by peer)
22:29:56FromDiscord<Elegantbeef> change the compiler and linker to a musl binary
22:29:59*termer_ joined #nim
22:30:28FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "change the compiler and": so I need to use another compiler?
22:30:43FromDiscord<nocturn9x> well gcc is naturally going to use glibc
22:30:45FromDiscord<nocturn9x> since, you know
22:30:46FromDiscord<Elegantbeef> or zig
22:30:49FromDiscord<nocturn9x> it's the GNU compiler
22:30:53FromDiscord<nocturn9x> and it's the GNU C library
22:31:08FromDiscord<System64 ~ Flandre Scarlet> Alright so I need to use the Zig compiler
22:31:14FromDiscord<nocturn9x> yeah use zigcc
22:31:21FromDiscord<nocturn9x> works great for cross compilation as well
22:31:25FromDiscord<Elegantbeef> You don't need to
22:31:27FromDiscord<Elegantbeef> you can also use a musl compiler
22:31:34FromDiscord<System64 ~ Flandre Scarlet> Which one?
22:31:41FromDiscord<Elegantbeef> > works great for cross compilation as well↵Until you run into the hellscape that is dependency hell
22:31:49FromDiscord<Elegantbeef> The musl compiler in your package repository?
22:32:03FromDiscord<Elegantbeef> There is one musl C compiler
22:32:15FromDiscord<System64 ~ Flandre Scarlet> clang?
22:32:26FromDiscord<Elegantbeef> No.... musl
22:32:56FromDiscord<System64 ~ Flandre Scarlet> Oh!
22:34:41FromDiscord<nnsee> the musl compiler is a wrapper around gcc
22:35:34FromDiscord<System64 ~ Flandre Scarlet> also supports C++?
22:35:48FromDiscord<Elegantbeef> https://scripter.co/nim-deploying-static-binaries/ will help a tinge
22:37:04FromDiscord<Elegantbeef> `--cc:clang --clang.exe:zigcc --clang.linkerexe:zigcc --passC="-target x86_64-linux-musl" --passL="-target x86_64-linux-musl"` for if you use zigcc and the nimble zigcc package`--gcc.exe=musl-gcc --gcc.linkerexe=musl-gcc --app:lib --passL:"-static"` if you use musl directly
22:37:12*tiorock joined #nim
22:37:12*rockcavera is now known as Guest59
22:37:12*Guest59 quit (Killed (copper.libera.chat (Nickname regained by services)))
22:37:12*tiorock is now known as rockcavera
22:38:24FromDiscord<System64 ~ Flandre Scarlet> xlib.h errors, OOF
22:38:49FromDiscord<Elegantbeef> Welcome to needing all your packages for musl aswell
22:39:03FromDiscord<Elegantbeef> This is why people generally target an older glibc
22:39:16*tiorock joined #nim
22:39:16*rockcavera is now known as Guest2936
22:39:16*tiorock is now known as rockcavera
22:39:23FromDiscord<System64 ~ Flandre Scarlet> Would be easier I guess↵Through a chroot or something
22:39:49FromDiscord<Elegantbeef> Or just zigcc
22:40:26FromDiscord<System64 ~ Flandre Scarlet> now Zigcc only being availlable trough Snap in Ubuntu-based distros
22:42:26*Guest2936 quit (Ping timeout: 244 seconds)
23:00:40*oisota quit (Quit: Ping timeout (120 seconds))
23:01:00*oisota joined #nim
23:18:09FromDiscord<System64 ~ Flandre Scarlet> Well, I can't figure out how it works