<< 25-02-2024 >>
00:01:33FromDiscord<im__cynical> ight
00:01:34FromDiscord<im__cynical> ty
00:11:08FromDiscord<JJ> what is an "out" type?
00:11:10FromDiscord<Robyn [She/Her]> No worries!
00:11:23FromDiscord<JJ> the keyword is reserved and it does appear to be, like, a thing but it's not in the manual
00:11:25FromDiscord<Robyn [She/Her]> In reply to @omentic "what is an "out"": An 'out' type? Never heard that before
00:11:31FromDiscord<Elegantbeef> It's a thing
00:11:36FromDiscord<Elegantbeef> Out is definitive assignment `var`
00:11:44FromDiscord<JJ> definitive assignment?
00:11:45FromDiscord<Elegantbeef> To be used with `strictdefs`
00:11:53FromDiscord<Robyn [She/Her]> Still makes no sense to me
00:11:54FromDiscord<Elegantbeef> Yes you must assign the out parameter
00:11:57FromDiscord<Elegantbeef> It's C style `out`
00:12:09FromDiscord<JJ> huh icic
00:12:11FromDiscord<Elegantbeef> Araq really wants definitive assignment to be the norm
00:12:18FromDiscord<Robyn [She/Her]> I don't know C either so that's useless to me-
00:12:34FromDiscord<Elegantbeef> Cool I explained what it was
00:12:43FromDiscord<Elegantbeef> "you must assign the out parameter"
00:13:10FromDiscord<JJ> any performance improvements over just returning?
00:13:24FromDiscord<Elegantbeef> Nope it's just static analysis
00:13:33FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=HHTBUpDsbDvI
00:13:38FromDiscord<Elegantbeef> Yes
00:13:49FromDiscord<Elegantbeef> I mean it hard codes NVRO so that's a 'plus'
00:13:57FromDiscord<Robyn [She/Her]> Hm... Why would you ever need that? NVRO?
00:14:10FromDiscord<Elegantbeef> It's a more descriptive `var` and that's really it
00:14:26FromDiscord<Robyn [She/Her]> Ah okay that makes some sense to me then
00:14:27FromDiscord<Elegantbeef> you might have a `proc doStuff(i: out int): T`
00:14:42FromDiscord<Elegantbeef> Araq does want to use it in nonsensical places so that'll be fun
00:15:14FromDiscord<Elegantbeef> https://github.com/nim-lang/Nim/pull/23261#discussion_r1469385999 context for that
00:19:13FromDiscord<Robyn [She/Her]> Ah, oh well
01:00:02*nazgulsenpai quit (Quit: ZNC 1.8.2 - https://znc.in)
01:00:26FromDiscord<Robyn [She/Her]> Anyone know the best way to do non-blocking code with std/net (without diving into threads just yet)?
01:00:45FromDiscord<Elegantbeef> Selectorfs
01:01:30FromDiscord<Elegantbeef> selectors\
01:02:00FromDiscord<Robyn [She/Her]> Thought so, thanks o7
01:02:08FromDiscord<Robyn [She/Her]> Trying to help my friend get adjusted to Nim so-
01:02:18FromDiscord<Robyn [She/Her]> She comes from C-
01:02:59*nazgulsenpai joined #nim
01:04:00FromDiscord<odexine> not a lot of people who use c minus
01:04:03FromDiscord<odexine> :baqua:
01:04:33NimEventerNew thread by ggb-sw1: How does one deal with void pointers between Nim and C?, see https://forum.nim-lang.org/t/11079
01:04:46arkanoidso you know how can I sto nim from appending "async traceback" string to all my exception messages?
01:04:49arkanoid*stop
01:05:12arkanoidI mean this https://github.com/nim-lang/Nim/blob/37ed8c84801a850b91b86f777ae2a4a2e022cd47/lib/pure/asyncfutures.nim#L348
01:05:40FromDiscord<Elegantbeef> define release 😛
01:05:53FromDiscord<Robyn [She/Her]> In reply to @odexine "<:baqua:746617285057314928>": :p
01:07:16FromDiscord<morgan> so i'm using sokol, and trying to figure out why i'm getting errors that come from the c code that's actually doing the heavy lifting. i've tried adding some debugging to the validation code, but no changes seem to be applied, so is nim compiling it once and then caching the result? how can i override that?
01:08:04FromDiscord<Elegantbeef> `-f`
01:09:02FromDiscord<morgan> 👍
01:09:11arkanoidElegantBeef, that's sad!
01:09:26arkanoidI need debug, but also my own exception messages
01:09:47FromDiscord<Elegantbeef> I mean make a PR for `asyncDebugMessages` or w/e
01:10:49FromDiscord<morgan> In reply to @Elegantbeef "`-f`": ok yep that worked, and now to figure out why its not getting the size of the data i'm giving it
01:11:03FromDiscord<Elegantbeef> Likely that you're interop is wrong
01:11:05FromDiscord<Elegantbeef> your\
01:11:34FromDiscord<Elegantbeef> Ensure you're not using the incorrect integer sizes
01:11:40FromDiscord<Elegantbeef> `int` in Nim != `int` in C
01:13:49FromDiscord<morgan> well the c code is getting 0 for the size
01:13:55FromDiscord<morgan> and there's a nim wrapper already
01:14:03FromDiscord<morgan> which im using
01:14:27FromDiscord<morgan> its getting passed thru a few functions before there
01:14:46FromDiscord<morgan> and all the docs are in the code which is.... annoying
01:21:41FromDiscord<morgan> so in the example i copied from, some functions (from c) modified the buffer after creating it, and i couldn't figure out what it was doing that i wasn't, but after copying code from a different example that creates the buffers in a different way, it works
01:23:47FromDiscord<morgan> i of course get a new error
01:23:58FromDiscord<morgan> but the sizes the c code gets are correct, which is nice
01:59:46FromDiscord<Robyn [She/Her]> When you slice a string in Nim, or you get a character at a certain index, does it copy it?
02:00:09FromDiscord<Elegantbeef> "get a character" of course that copies a character is a value type
02:00:14FromDiscord<Elegantbeef> If you do `a[b..c]` yes it copies
02:00:21FromDiscord<Elegantbeef> but if you do a proper slice and do `a.toOpenArray(b, c)` no
02:02:23FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef ""get a character" of": Makes sense
02:10:59FromDiscord<luna4> Is there any is function similar to `strchr` from c in nim?
02:11:13FromDiscord<Elegantbeef> What it do
02:13:49FromDiscord<Robyn [She/Her]> `char strchr( char str, int ch );` this is the definition in C++
02:13:58FromDiscord<Robyn [She/Her]> > A string in C++ is a type of object that represents a collection (or sequence) of different characters… With the help of the c++ strchr() function, we can check whether a character is present in the string or not. The strchr() function in c++ is present in the <cstring> standard library file.
02:14:20FromDiscord<Elegantbeef> So just contains 😄
02:14:24FromDiscord<Robyn [She/Her]> sent a long message, see https://pasty.ee/VVlQEirggiSg
02:15:16FromDiscord<Robyn [She/Her]> In reply to @luna4 "Is there any is": Seems like `find` is your direct equivalent
02:15:35FromDiscord<Robyn [She/Her]> !eval echo("abc".find('c'))
02:15:41NimBot2
02:16:45FromDiscord<luna4> I see, strchr is very useful because it gives you a pointer to the part of the string it finds the first character
02:17:04FromDiscord<Robyn [She/Her]> If you don't need the index, as Beef said, `contains` is fine! (Also `'c' in "abc"` is sugar for `"abc".contains('c')`)
02:17:19FromDiscord<luna4> So you can do a little bit of trickery and \0 it to do a fast substring
02:17:31FromDiscord<Robyn [She/Her]> Why would you need to add a null byte?
02:17:42FromDiscord<luna4> To do a substring
02:18:00FromDiscord<Robyn [She/Her]> In Nim, strings are null terminated when you do `myString.cstring`, but since Nim strings store the length, you don't need a cstring usually :p
02:18:07FromDiscord<luna4> Oh
02:18:10FromDiscord<luna4> Nevermind then
02:18:17FromDiscord<sOkam! 🫐> Was there a way to specify the module a function is coming from when using dot syntax? 🤔↵something like: `thing().module.otherthing()`↵I think I remember seeing it somewhere, but can't recall how
02:18:21FromDiscord<luna4> I would need the index then yup find is useful
02:18:22FromDiscord<Robyn [She/Her]> It's pretty neat, right? :)
02:18:43FromDiscord<Elegantbeef> The module name is always the start of a dotexpr
02:18:56FromDiscord<luna4> In reply to @chronos.vitaqua "It's pretty neat, right?": It is, it's very similar to std::string and i have broken code because of that
02:19:04FromDiscord<sOkam! 🫐> In reply to @Elegantbeef "The module name is": so they cannot be nested?
02:19:09FromDiscord<Elegantbeef> Module names do not work with UFCS
02:19:16FromDiscord<sOkam! 🫐> kk
02:19:20FromDiscord<Robyn [She/Her]> In reply to @luna4 "It is, it's very": Fair!
02:20:35FromDiscord<Elegantbeef> You can always use `cstring` and pretend the year is 1982 if you want
02:22:56FromDiscord<luna4> I'm very used to c so its always an option
02:23:44FromDiscord<Elegantbeef> You can always just write Nim instead, wild concept 😄
02:24:10FromDiscord<ajusa> In reply to @Elegantbeef "You can always use": Or 1995!
02:24:22FromDiscord<Robyn [She/Her]> Don't scare away the newcomers, Beef, you always do this :P
02:24:24FromDiscord<Elegantbeef> Sorry we buffer overflowed we don't know the year anymore
02:24:59FromDiscord<ajusa> I always forget that cstring isn't "C style string", but instead "compatible string"
02:25:48FromDiscord<luna4> In reply to @Elegantbeef "You can always just": I kinda need to learn it first
02:25:57FromDiscord<luna4> I can just go back to c also
02:26:38FromDiscord<luna4> In reply to @ajusa "I always forget that": In c++ is the same, theres also ctime, that also means compatible time
02:27:04FromDiscord<Elegantbeef> Well Nim has that pesky JS backend
02:27:12FromDiscord<Elegantbeef> Which also has sstring
02:27:15FromDiscord<Elegantbeef> cstring\
02:32:56FromDiscord<Elegantbeef> Anyway to be slightly less obnoxious Nim does not deal with pointers as such any api that returns a pointer in C likely is done with an integer or not replicated in Nim without going to "unsafe" APIs
02:45:39*disso-peach joined #nim
02:58:28arkanoidis there a reason why xmltree returns nil in case of missing child instead of raising an exception?
03:01:49FromDiscord<zumi.dxy> In reply to @chronos.vitaqua "In Nim, strings are": some other languages omit the zero terminator and just have a pointer and length right?↵I think either way Nim still has the zero terminator so a string to cstring conversion is just taking the pointer to the data and calling it a day
03:03:00FromDiscord<Elegantbeef> Other languages that are silly omit it 😄
03:03:49FromDiscord<Elegantbeef> If you want C interop you want to have that null terminator there
03:09:19*disso-peach quit (Quit: Leaving)
04:16:32*azimut quit (Ping timeout: 255 seconds)
04:17:19FromDiscord<cineration> Does anybody know how to use the `punchThrough` proc in the `netty` library? I just can't figure out how to actually punch a hole 😂. Once I negotiate the ip/port with the server do I have one of the clients act as a server and do the `punchThrough` from the designated "server" before trying to connect from the designated "client"?
04:26:17FromDiscord<saint._._.> What is sokol?
04:27:06FromDiscord<saint._._.> https://github.com/floooh/sokol
04:27:14FromDiscord<saint._._.> Is it for 3d stuff?
04:38:24FromDiscord<Elegantbeef> If you set it up
05:12:41FromDiscord<morgan> In reply to @saint._._. "What is sokol?": it's a medium level abstraction over graphics apis
05:13:16FromDiscord<morgan> high level being like stuff to draw pixels, draw triangles, draw shapes, draw images, etc, and low level being the graphics apis directly
05:13:23FromDiscord<morgan> so some abstraction
05:13:35FromDiscord<morgan> but not focused on the high level stuff
05:13:42FromDiscord<morgan> so you can do what you want directly
05:14:51FromDiscord<morgan> like i have textures, mesh data, and shaders, and i switched from opengl (in c++ with juce, im basically completely switching everything) because all the stuff to tell it how to process those things was constantly just rakes laying all over ready for me to step on and smack me in the face
05:40:05FromDiscord<sOkam! 🫐> `proc thing [T :string]() :T= ...`↵Is there a way to instantiate this type of generic automatically without saying `thing[string]()`?
05:40:47FromDiscord<sOkam! 🫐> _(I know it only has a single type atm, which makes the generic redundant, but it will have more eventually)_
05:41:38FromDiscord<sOkam! 🫐> I think I'm just trying to find a way to make the return type dictate the generic instantiation 🤔
05:43:11FromDiscord<Elegantbeef> The return type cannot change the generic parameters
05:43:39FromDiscord<Elegantbeef> I believe you can do `[T: string = string]`
05:43:56FromDiscord<sOkam! 🫐> oh to give it a default? that could be handy
05:44:12FromDiscord<Elegantbeef> It might explode in your face as I don't think it's intended design
05:44:56FromDiscord<sOkam! 🫐> sadly it doesn't instantiate with that 😦
05:45:11FromDiscord<sOkam! 🫐> it works when specifying it, but not when omitted
05:46:11FromDiscord<Elegantbeef> you can do `proc thing(t: typedesc = string)`
05:49:26FromDiscord<sOkam! 🫐> `Error: type mismatch: got 'string' for 'string' but expected 'typedesc'` 😔
05:49:40FromDiscord<sOkam! 🫐> oh, you mean inside the type
05:49:49FromDiscord<sOkam! 🫐> (edit) "type" => "args"
05:51:10FromDiscord<sOkam! 🫐> doesn't solve the return type idea, but I guess it could be a bit cleaner for the default case
05:51:27FromDiscord<Elegantbeef> "return type idea"?
05:53:14FromDiscord<sOkam! 🫐> in `echo thing()` the echo call should dictate the type↵because I might be calling for other versions that return a different type
05:53:30FromDiscord<Elegantbeef> Not in Nim we don't have return type inference
05:53:47FromDiscord<sOkam! 🫐> yeah i understood, that's why i said "the return type idea is not solved" but its a bit cleaner
06:05:50*rockcavera quit (Remote host closed the connection)
06:05:50FromDiscord<saint._._.> In reply to @morganalyssa "like i have textures,": Oh cool, are you writing some vst stuff with nim? I’m super interested in that
06:07:54FromDiscord<morgan> In reply to @saint._._. "Oh cool, are you": yea i'm working on a plugin, i've wanted to use nim for that for ages and someone recently released a c library for that that im gonna wrap at some point, and opengl giving me tons of trouble was a good kick in the butt to try (worked but i was sending textures every update, and i couldn't get it to work with any of the changes i needed to make to change that)
06:08:41FromDiscord<saint._._.> Are you using juce? Or iplug2 ?
06:08:53FromDiscord<saint._._.> There’s no way to hand roll everything in nim is there?
06:09:17FromDiscord<morgan> i was using juce
06:09:40FromDiscord<morgan> there's no pure nim options, but i should be able to wrap cplug and use that
06:09:50*rockcavera joined #nim
06:10:54FromDiscord<morgan> and then combine that with sokol for graphics, also not pure nim but a decent wrapper made by the dev (tho no docs in the source, while the c header is where all the docs are, so kinda annoying to figure out what stuff does)
06:11:19FromDiscord<morgan> pure nim would be nice but anything to not use c++ lmao
06:17:06FromDiscord<morgan> i'm working on graphics first because that was the issue that i was struggling with
06:17:08FromDiscord<sOkam! 🫐> ugly as hell, but at least it works like I expected (minus the T as an argument, but it is what it is) https://media.discordapp.net/attachments/371759389889003532/1211195153235181648/image.png?ex=65ed5063&is=65dadb63&hm=54269a53be3964421796c274d0b322a5ae7c78f3d374391a3724b28ae247e97c&
06:18:25FromDiscord<sOkam! 🫐> In reply to @morganalyssa "there's no pure nim": you should be able to wrap that new vst protocol with nim no issues. can't remember the name, but its pure C
06:18:47FromDiscord<morgan> well yea i could handle various plugin apis myself
06:18:51FromDiscord<morgan> and i might do that someday
06:19:18FromDiscord<morgan> but using cplug would move things along a bit faster for now
06:19:56FromDiscord<sOkam! 🫐> @morgan the one I mean is `clap`
06:20:20FromDiscord<sOkam! 🫐> I believe, now im not sure anymore
06:20:50FromDiscord<morgan> yea something that was suggested to me was to use clap along with vst3 and au wrappers
06:54:01*advesperacit joined #nim
07:04:36FromDiscord<saint._._.> In reply to @morganalyssa "yea something that was": So there are vst3 wrappers for clap? Interesting
07:04:56FromDiscord<morgan> yeah i havent looked into the wrappers tho
07:05:19FromDiscord<saint._._.> I’ll look more into clap could be interesting
07:16:45FromDiscord<morgan> ugh im having to use lldb to figure out why its crashing :pain:
07:21:14*advesperacit quit ()
07:22:35NimEventerNew thread by termer: What is `-d:nimNetLite`?, see https://forum.nim-lang.org/t/11080
07:23:39*advesperacit joined #nim
07:35:49*junaid_ joined #nim
07:55:43*ntat joined #nim
09:35:33FromDiscord<itr_> sent a long message, see https://pasty.ee/zmITtVdTFBNM
09:37:30FromDiscord<Elegantbeef> How do you intend on storing the original state?
09:38:10FromDiscord<Elegantbeef> You're sorta describing transactional logic, but that's not done for memory cause you have to store the before state somehow
09:47:26FromDiscord<Elegantbeef> You can just use defer
10:13:29FromDiscord<ezquerra> This is probably a pretty basic question, but does casting to the same type (e.g. doing `float(x)` when `x` is already a `float`) have any runtime cost? I assume not?
10:13:50FromDiscord<nnsee> casts have no runtime cost at all
10:14:40FromDiscord<nnsee> like most things wrt typing, it's a compile time concept only
10:20:29FromDiscord<Elegantbeef> Well `type(x)` is type conversion and can have overhead
10:20:37FromDiscord<ezquerra> Well, I guess that casting might have a cost if it's not the same representation in memory? e.g. casting to float from int?
10:20:39FromDiscord<Elegantbeef> `cast[type](x)` is a C cast and has no overhead
10:20:52FromDiscord<nnsee> In reply to @Elegantbeef "Well `type(x)` is type": true
10:21:00FromDiscord<Elegantbeef> float and int are the same representations 😄
10:21:08FromDiscord<ezquerra> Bad example
10:21:24FromDiscord<Elegantbeef> The compiler sorta prevents bad casts
10:21:28FromDiscord<Elegantbeef> But cast is just reinterpretation
10:21:43FromDiscord<Elegantbeef> Stop calling type conversions casts and be merry
10:22:11FromDiscord<nnsee> oh i didn't even notice that example
10:22:17FromDiscord<nnsee> it's still way too early for me, sorry
10:22:30FromDiscord<ezquerra> OK then, let me rephrase my original question: does type converting to the same type have a cost? From your replies I'd say it does not, right?
10:22:46FromDiscord<Elegantbeef> It does not correct
10:22:52FromDiscord<ezquerra> Thank you! 🙂
10:22:56FromDiscord<Elegantbeef> `float(x)` is redundant but what would the runtime check do
10:24:00FromDiscord<ezquerra> I have some generic code that needs to convert the input to some specific type (which can be the same type as the input or not), hence my original question 🙂
10:24:57FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=qCIPUzCChDRQ
10:30:27FromDiscord<ezquerra> I didn't notice any warnings? I had an error when I did not explicitly convert the input to float for some operation down the line. I wanted to avoid having to do that `when X isnot SomeFloat` so I wondered if I could just do always do `float(val)` without any cost...
10:30:56FromDiscord<Elegantbeef> `float(someFloat)` will produce a warning
10:31:41FromDiscord<Elegantbeef> Or atleast other types do
10:32:48FromDiscord<Elegantbeef> Ah it's a hint Hint\: conversion from string to itself is pointless [ConvFromXtoItselfNotNeeded]
10:37:06*Guest23 joined #nim
10:45:16*Guest23 quit (Quit: Client closed)
10:55:26*junaid_ quit (Remote host closed the connection)
11:09:54Amun-Rathat's the safest conversion one can get
11:15:16*junaid_ joined #nim
11:23:20*gooba quit (Remote host closed the connection)
11:37:40*gooba joined #nim
12:03:37*jmdaemon quit (Ping timeout: 255 seconds)
12:05:26FromDiscord<saint.___.> @morgan https://github.com/free-audio/clap-wrapper
12:05:27FromDiscord<saint.___.> Seems interesting
12:05:40FromDiscord<saint.___.> Would be cool to do a full nim wrapping of clap and then just using that
12:05:50FromDiscord<saint.___.> Would be nice not to have to use juce or iplug2
12:26:06*gooba quit (Remote host closed the connection)
12:30:28*Guest64 joined #nim
12:31:12*Guest64 quit (Client Quit)
12:32:04*gooba joined #nim
13:08:03*azimut joined #nim
13:36:33*ntat quit (Remote host closed the connection)
13:36:54*ntat joined #nim
13:42:25*disso-peach joined #nim
14:21:21FromDiscord<rongcuid> Turns out the nim formatter still breaks lines across brackets
14:25:02FromDiscord<Robyn [She/Her]> In reply to @rongcuid "Turns out the nim": Have you tried `nph`?
14:25:47FromDiscord<rongcuid> Yeah it works better.
14:26:16FromDiscord<Robyn [She/Her]> That's good then, you just don't like the style it's enforcing then, I'm guessing?
14:30:17FromDiscord<rongcuid> I like most of the styles enforced by the default formatter, except something like this:
14:30:32FromDiscord<rongcuid> sent a code paste, see https://play.nim-lang.org/#pasty=uZsKxjGQWTUL
14:34:06FromDiscord<Robyn [She/Her]> Yeah that looks gross
14:34:28FromDiscord<Robyn [She/Her]> Hopefully someone here knows how to stop that?
15:35:51FromDiscord<kiloneie> is it possible to do this ? `template test(name: untyped or string) =`
15:38:03FromDiscord<takemichihanagaki3129> sent a code paste, see https://play.nim-lang.org/#pasty=srkABNIXJYcG
15:44:00NimEventerNew thread by enaaab460: Single line ref seq[int] assignment, see https://forum.nim-lang.org/t/11083
15:53:22FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=cxDwxhWvlTCx
16:16:08*def- quit (Quit: -)
16:16:19*def- joined #nim
16:17:27FromDiscord<takemichihanagaki3129> In reply to @demotomohiro "https://nim-lang.org/docs/system.html#unlikely.t%2C": Yes, I know. But does I need the `else`? Let's say I'm returning a value.↵I don't actually need the `else`, and I can unindent my code-block, but I'm in doubt about if the optmization will work...
16:17:32FromDiscord<takemichihanagaki3129> (edit) "optmization" => "optimization"
16:19:15FromDiscord<takemichihanagaki3129> sent a code paste, see https://play.nim-lang.org/#pasty=zoXURrcvCPaA
16:19:38FromDiscord<takemichihanagaki3129> Has the second one the same opitmization?
16:19:57Amun-Ralikely/unlikely doesn't need else branch
16:20:13Amun-Rayou just point whether given condition likely to happen or not
16:21:31FromDiscord<takemichihanagaki3129> In reply to @Amun-Ra "likely/unlikely doesn't need else": Thanks!
16:25:14Amun-Rausing (un)likely makes really sense when given condition is run maaany times
16:25:57Amun-Raotherwise speed profit is going to be unnoticeable
16:29:47*def- quit (Quit: -)
16:29:58*def- joined #nim
17:09:40*disso-peach quit (Quit: Leaving)
17:50:34*tc424 quit (Ping timeout: 255 seconds)
17:50:49*tc424 joined #nim
18:08:37*lucasta joined #nim
18:30:04*def- quit (Quit: -)
18:31:42*def- joined #nim
18:40:12*def- quit (Quit: -)
18:40:44*def- joined #nim
18:43:46*def- quit (Client Quit)
19:06:00*def- joined #nim
19:06:11*lucasta quit (Quit: Leaving)
19:30:48*def- quit (Quit: -)
19:53:36*def- joined #nim
19:59:07*krux02 joined #nim
20:00:04*def- quit (Quit: -)
20:02:39*def- joined #nim
20:05:22*nazgulsenpai quit (Ping timeout: 264 seconds)
20:06:11*nazgulsenpai joined #nim
20:06:57*def- quit (Client Quit)
20:11:14*def- joined #nim
20:11:14*def- quit (Client Quit)
20:12:26*def- joined #nim
20:13:32FromDiscord<deech4592> How do you build Nim on Windows with the Visual Studio C/C++ compiler? The Windows batch file build script hardcodes `gcc`.
20:15:31rockcaveradeech4592 you need to compile c_sourcev2 for vcc. For this you need a Nim compiler.
20:15:35*def- quit (Client Quit)
20:16:11rockcaverabut if you already have a Nim compiler, it pays to bootstrap using --cc:vcc
20:17:31FromDiscord<deech4592> That's a shame I was hoping to fully bootstrap.
20:18:08*def- joined #nim
20:18:24FromDiscord<deech4592> (edit) "bootstrap." => "bootstrap, I have a C/C++ compiler in my path, that should be enough. In any case, I appreciate the response."
20:18:36rockcaverabooting from C source is distributed to be with gcc
20:19:16FromDiscord<deech4592> Interesting. Is the generated code using some gcc specific extensions?
20:19:55rockcaveraoverflow checks are done by default with bultin gcc
20:20:13rockcaverabuiltin
20:21:43*jmdaemon joined #nim
20:24:18FromDiscord<Robyn [She/Her]> What's the use of `likely` and `unlikely`? I don't understand how the branch prediction works so would appreciate an explanation
20:25:15FromDiscord<Robyn [She/Her]> In reply to @rockcavera "overflow checks are done": I wonder if there's a way to turn off these specifics so that a plain C compiler could build Nim from scratch
20:32:50rockcaveraRobyn I don't know
20:37:11FromDiscord<Robyn [She/Her]> Nim did use to support tinycc, right? Maybe that's a possibility?
20:44:01FromDiscord<.bobbbob> just wondering, is having a json configuration file, loading it at startup in a sort of config.nim, then loading the keys into global lets so that other files can import config.nim and use them, and to also check that the keys actually exist right away, Okay™️?
20:44:57FromDiscord<Elegantbeef> It still does support TCC just do `--threads:off`
20:45:49FromDiscord<rakgew> tcc also nice with inim \:-D
20:49:33*junaid_ quit (Remote host closed the connection)
21:05:42rockcaveraRobyn I used to do some PRs to keep Nim working with tcc on Windows. But araq informed that it intends to maintain only gcc, clang and vcc
21:06:15rockcaverabut as far as I know, it is still possible to use tcc with --threads:off
21:10:20*rockcavera quit (Remote host closed the connection)
21:12:03*junaid_ joined #nim
21:13:34*rockcavera joined #nim
21:16:40*droidrage joined #nim
21:18:28*junaid_ quit (Remote host closed the connection)
21:40:42arkanoidwhat is the point of using tcc?
21:40:51arkanoidit is just speed, or something else?
21:52:26*lucasta joined #nim
21:52:48*lucasta quit (Remote host closed the connection)
21:55:39*ntat quit (Quit: Leaving)
21:56:11*rockcavera quit (Remote host closed the connection)
21:58:11FromDiscord<jakraes> What is the performance cost of abstractions/inheritance and using method instead of proc in Nim? Is it that bad?
21:58:35FromDiscord<Robyn [She/Her]> In reply to @rockcavera "Robyn I used to": Ah fair enough
21:58:42FromDiscord<Robyn [She/Her]> In reply to @arkanoid "it is just speed,": Yeah just speef
21:58:45FromDiscord<Robyn [She/Her]> Speed
21:58:56*rockcavera joined #nim
22:09:06FromDiscord<Elegantbeef> OOP generally is slower due to pointer indirection whilst the overhead of methods might not be high it depends what you're doing↵(@jakraes)
22:09:18FromDiscord<Elegantbeef> Methods prevent inline aswell so smaller methods spend more time doing less
22:10:03FromDiscord<Elegantbeef> The less you rely on runtime polymorphism the better optimised the code can be
22:11:58FromDiscord<Robyn [She/Her]> In reply to @chronos.vitaqua "What's the use of": Hey Beef, can you explain `unlikely` and `likely` to?
22:12:09FromDiscord<Elegantbeef> Don't use them there we go
22:12:36FromDiscord<.bobbbob> Im super confused, I've had a project with prologue that's been working fine, but all of the sudden Ive been getting compile time type mismatch errors where addRoute doesnt recognize the route functions as being the right type even though I changed nothing with them, why would this be happening?
22:12:54FromDiscord<Elegantbeef> Did you change your compiler version?
22:13:01FromDiscord<Elegantbeef> Did you update the package and not pin it properly?
22:13:25FromDiscord<Elegantbeef> Robyn it's just that we have a branch predictor and we can say "just assume this is true" and it makes it the more likely prediction which can make code faster
22:13:40FromDiscord<Elegantbeef> For the vast majority of code you can just ignore it as it likely causes more harm than good
22:13:42FromDiscord<.bobbbob> I updated the compier a few weeks ago and it was working fine, the package hasnt been updated in over a year
22:14:15FromDiscord<Elegantbeef> For instance termer throws likely and unlikely around without any actual benchmarking which can lead to worst performing code
22:17:45FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Robyn it's just that": That seems ineffective in most cases
22:17:46arkanoidI'm spending way more time than expected trying to extract connected client address-port in prologue
22:17:57arkanoidthe api is obscure
22:18:43FromDiscord<.bobbbob> sent a code paste, see https://play.nim-lang.org/#pasty=JwfAgprfrCYr
22:18:47arkanoidjust look at the import mess https://github.com/planety/prologue/blob/devel/src/prologue/core/beast/request.nim
22:19:33FromDiscord<.bobbbob> In reply to @arkanoid "I'm spending way more": I think ctx.request.hostName is the clients ip address if that's what you're asking
22:20:46arkanoidctx.request.hostName returns empty
22:22:13FromDiscord<.bobbbob> oh if I remember correctly it works if you have the prolouge server behind nginx (or something) with proxy_set_header Host $host;
22:22:47FromDiscord<.bobbbob> aka "works on my machine 🙂 "
22:22:50arkanoidwhat? prologue owns the listening sockets, so prologue knows the source ip
22:24:19FromDiscord<.bobbbob> yeah its weird they dont have a straightforward way to get the ip like jester (or any web framework)
22:24:44FromDiscord<.bobbbob> https://github.com/planety/prologue/issues/217
22:47:56*advesperacit quit ()
22:51:24FromDiscord<Elegantbeef> @.bobbbob they expect arrays no?
22:52:45FromDiscord<.bobbbob> No it can be a single function, like I said it's been working, I changed some stuff I thought was unrelated so it must somehow have to do with that
22:53:12FromDiscord<Elegantbeef> I mean all the mismatches are on `openArray` or `Option[T]`
22:54:45*qwestion joined #nim
22:56:26FromDiscord<.bobbbob> sent a code paste, see https://play.nim-lang.org/#pasty=dTfPwsnqzAsD
22:56:54FromDiscord<Elegantbeef> Tag yours GCsafe and see what errors
23:00:32FromDiscord<.bobbbob> yep I got error not GC safe because I was trying to use a global variable created with let (which is what I was mentioning earlier). Is there a way to do that and keep it gcsafe? Because I'd like to load those at runtime but have them globally accessible
23:00:47FromDiscord<Elegantbeef> `{.cast(gcSafe.}: #code here`
23:01:07FromDiscord<.bobbbob> what at the let?
23:01:14FromDiscord<Elegantbeef> At the usage
23:03:52FromDiscord<.bobbbob> Do you mean in the function declaration? like this?↵proc index(ctx: Context) {.async, cast(gcsafe).} =
23:04:00FromDiscord<Elegantbeef> No
23:04:08FromDiscord<Elegantbeef> Inside your proc where you access the let
23:04:51FromDiscord<.bobbbob> oh well that's super lame because it totally defeats the point of even having those global constants since they were to make the code cleaner
23:10:27FromDiscord<.bobbbob> I dont really get why an async function can't access a global let variable since it should be constant right?
23:22:53FromDiscord<Elegantbeef> `let` can still be mutated using unsafe operations
23:23:36FromDiscord<Elegantbeef> Whether that's the reason idk
23:25:09FromDiscord<leorize> I think it's just "globals bad" for that analysis in particular