00:00:00*luis__ joined #nim
00:00:01FromDiscord<treeform> why stop at int128, why not int256?
00:11:47*ptdel quit (Ping timeout: 240 seconds)
00:17:39FromDiscord<Elegant Beef> why stop at int256, make int 1024
00:18:56FromDiscord<Elegant Beef> or alternatively just wrap the big int library
00:19:28FromDiscord<Elegant Beef> i mean libgmp
00:20:10FromDiscord<Elegant Beef> 2^37bits
00:20:14FromDiscord<Elegant Beef> 2^37 bits
00:27:34*ptdel joined #nim
00:28:49*marmotini_ joined #nim
00:35:38*dadada quit (Ping timeout: 240 seconds)
00:38:40*dadada joined #nim
00:39:03*dadada is now known as Guest80598
00:52:25*Guest80598 quit (Ping timeout: 272 seconds)
00:53:40*dadada_ joined #nim
00:55:47FromDiscord<clyybber> I'm just making float prints nice
01:05:57*theelous3 quit (Read error: Connection reset by peer)
01:07:37*dadada_ quit (Ping timeout: 272 seconds)
01:08:07FromDiscord<Elegant Beef> Easy make it sci notiation with a param being the leading decimas
01:08:12FromDiscord<Elegant Beef> Easy make it sci notiation with a param being the leading decimals
01:08:38*dadada joined #nim
01:09:01*dadada is now known as Guest76039
01:11:03*ptdel quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
01:22:11*Guest76039 quit (Ping timeout: 260 seconds)
01:23:37*dadada_ joined #nim
01:36:50*dadada_ quit (Ping timeout: 240 seconds)
01:38:18FromDiscord<Elegant Beef> @clyybber now i get to complain to you about trying to build with your library and getting a unknown identifier csize_T
01:38:19FromDiscord<Elegant Beef> @clyybber now i get to complain to you about trying to build with your library and getting a unknown identifier csize_t
01:38:23FromDiscord<Elegant Beef> Look what you've done
01:38:35*dadada_ joined #nim
01:40:48*marmotini_ quit (Remote host closed the connection)
01:41:22*marmotini_ joined #nim
01:45:38*marmotini_ quit (Ping timeout: 240 seconds)
01:51:55leorizeuse devel for csize_t
01:52:09FromDiscord<Elegant Beef> ah
01:52:10FromDiscord<Elegant Beef> ok
01:53:13*dadada_ quit (Ping timeout: 272 seconds)
01:53:35*dadada_ joined #nim
01:54:16FromDiscord<clyybber> @Elegant Beef Ah damnit. I switched it to csize_t because I was getting sick of deprecation warnings
01:54:25FromDiscord<clyybber> and Im always on devel
01:54:45FromDiscord<clyybber> You can also just use the previous commit
01:55:01FromDiscord<Elegant Beef> or i can just use #head πŸ˜„
01:55:20FromDiscord<clyybber> Go ahead :D
01:55:53FromDiscord<Elegant Beef> The fact i dont even know how to properly make my own tuple type, is probably a good indication im going to make the shittiest game engine πŸ˜›
01:56:22FromDiscord<clyybber> sometuple = tuple[some: sometype]
01:56:38FromDiscord<Elegant Beef> yea i got it
01:56:41FromDiscord<Elegant Beef> I just had to check the docs
01:56:42FromDiscord<clyybber> You can also use the object syntax I think
01:56:46FromDiscord<clyybber> Aight
01:56:57FromDiscord<clyybber> gotta get some sleep
01:57:02FromDiscord<clyybber> nite
01:57:16FromDiscord<Elegant Beef> Buh bye
01:57:24FromDiscord<Elegant Beef> Ill be sure to annoy you more
01:59:55FromDiscord<Elegant Beef> Is `cast[Type](val) the same as (Type)Val`?
02:00:37*dddddd quit (Remote host closed the connection)
02:02:27FromDiscord<clyybber> nah
02:02:35FromDiscord<clyybber> tho in some cases yeah
02:02:49FromDiscord<clyybber> basically cast will reinterpret the bitpattern
02:02:54FromDiscord<clyybber> c style cast
02:03:10FromDiscord<clyybber> and (Type)Val isnt really nims syntax
02:03:16FromDiscord<Elegant Beef> Ok so the other is more C# like and attempts to get the other object type
02:03:17FromDiscord<Elegant Beef> Ok so the other is more C# like and attempts to get the other object type?
02:03:28FromDiscord<clyybber> Type(Val) is what you want
02:03:32FromDiscord<Elegant Beef> I mean i tried it from my C# knowledge and it worked πŸ˜„
02:03:37FromDiscord<clyybber> or Val,Type
02:03:45FromDiscord<clyybber> or Val.Type
02:03:55FromDiscord<clyybber> haha yeah it works
02:04:45FromDiscord<clyybber> Anyways the second thing way in your example will convert
02:04:59FromDiscord<clyybber> like from uint to int its with range checks
02:05:18FromDiscord<clyybber> its the more high level safe way
02:05:27FromDiscord<clyybber> and you can overload it
02:05:36FromDiscord<Elegant Beef> yea im only using it on primitive types so when i get to more advanced objects we'll see
02:05:53FromDiscord<Elegant Beef> i know for ints you can specify the type using a single quote
02:06:01FromDiscord<clyybber> ye
02:06:19FromDiscord<clyybber> good night
02:06:28FromDiscord<Elegant Beef> is it truely this time πŸ˜„
02:06:29FromDiscord<Elegant Beef> Buh bye
02:07:16FromDiscord<clyybber> hope so πŸ˜„ bb
02:08:01*dadada_ quit (Ping timeout: 268 seconds)
02:08:38*dadada joined #nim
02:09:01*dadada is now known as Guest17375
02:20:07*chemist69 quit (Ping timeout: 240 seconds)
02:22:22*chemist69 joined #nim
02:22:23*Guest17375 quit (Ping timeout: 260 seconds)
02:23:32*dadada_ joined #nim
02:31:47*ptdel joined #nim
02:40:02*luis__ quit (Quit: luis__)
02:45:19disruptekclyybber: yep, i haven't even created a d2s.nim file.
03:04:27*gangstacat quit (Quit: Ĝis!)
03:12:34FromDiscord<4984> does nim have full UFCS or am i missing something?
03:12:44disruptekit does.
03:13:12FromDiscord<4984> enato
03:13:14FromDiscord<4984> nenato
03:13:22disruptekthere's a corner case in templates, but everywhere that matters...
03:13:48FromDiscord<4984> ive wanted to learn nim for so long but gotten confused at syntax each time
03:13:59disruptekah; don't sweat it.
03:14:11disruptekit's just a luxury.
03:14:22FromDiscord<4984> nim is a luxury?
03:14:35disrupteksure, but especially the syntax.
03:14:57disrupteki'd be happy if i had the same semantics with a shitty syntax.
03:15:01disruptekthe syntax is just icing.
03:15:51FromDiscord<4984> the more of nim i learn the more it reminds me of other languages
03:16:22FromDiscord<4984> like at first i was like "oh its the crystal of python"
03:16:49disruptekright, that's the common comparison.
03:16:53FromDiscord<4984> now i actually need something to do
03:17:05disruptekthe difference is, with nim you don't give anything up.
03:17:24FromDiscord<4984> crystal's gc is a mess
03:17:29disruptekit's lisp that's as raw and thermonuclear as c.
03:18:04FromDiscord<4984> i wish more languages would abandon libc
03:18:21disruptekit will happen when speed starts to matter again.
03:18:59disruptekthe semantics of other languages will slow them down. they will need to shed weight.
03:19:42FromDiscord<4984> and in the end two stood, both with UFCS, good compilers, and sane templates
03:19:53FromDiscord<4984> i just find my nim code is a bit smaller
03:21:37disrupteki don't want to take away from the work people have done to make nim faster, but i don't think it's unfair that there is a lot of meat left on that bone.
03:21:49disruptekunfair to say, i should say.
03:22:17FromDiscord<4984> you think it could be optimized much more?
03:22:45disruptekthat's sorta the thing. i don't think you can shop for a language by looking at what it is today. you have to be thinking much longer term if you're going to make a real investment.
03:23:00disruptekand that's why i'm here. πŸ˜‰
03:23:25FromDiscord<4984> i can't really see GC's lasting too far ahead
03:23:48*jwm224 quit (Ping timeout: 248 seconds)
03:23:59disrupteki think we will get more of a containerized kernel.
03:24:49FromDiscord<4984> whatever we get i dont want libc to have any part in it
03:25:15disruptekthat's what i mean.
03:26:51disruptekthe whole way we build software has to change.
03:28:36*rockcavera quit (Read error: Connection reset by peer)
03:28:40disruptekto do that, we have to be able to transition our thinking to the forest from the trees.
03:28:55FromDiscord<4984> what does that mean!?
03:29:17disruptekwe have to be able to compose software with a lisp-like system.
03:29:37FromDiscord<4984> lisp has major issues
03:30:16FromDiscord<4984> well what way to mean "lisp-like"
03:30:36disrupteklisp 😁
03:30:41*rockcavera joined #nim
03:30:41*rockcavera quit (Changing host)
03:30:41*rockcavera joined #nim
03:30:44disruptekwhat are the major issues?
03:31:26FromDiscord<4984> well i dont know CL
03:31:38FromDiscord<4984> but in scheme i know a bunch as in gc, no return
03:31:39FromDiscord<4984> and such
03:32:24disrupteki just mean lisp as in the fundamental lambda-based programming system.
03:32:44FromDiscord<4984> thats not lisp
03:32:49FromDiscord<4984> thats lambda calculus
03:33:46disruptekthat's why it's confusing when someone says lisp.
03:33:53*muffindrake quit (Ping timeout: 246 seconds)
03:36:16*muffindrake joined #nim
03:36:32*jwm224 joined #nim
03:40:23*gangstacat joined #nim
03:41:34*tiorock joined #nim
03:41:34*tiorock quit (Changing host)
03:41:34*tiorock joined #nim
03:41:34*rockcavera quit (Killed (adams.freenode.net (Nickname regained by services)))
03:41:34*tiorock is now known as rockcavera
03:44:57*rockcavera quit (Remote host closed the connection)
03:52:04*Tanger quit (Read error: Connection reset by peer)
04:00:47*Tanger joined #nim
04:05:07*dadada_ quit (Ping timeout: 265 seconds)
04:08:37*dadada joined #nim
04:09:01*dadada is now known as Guest79630
04:16:11*LER0ever joined #nim
04:16:48disruptekwhy do i feel like we're trending.
04:22:02*Guest79630 quit (Ping timeout: 240 seconds)
04:23:32*dadada joined #nim
04:23:55*dadada is now known as Guest8250
04:30:15*ptdel quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
04:30:41*Prestige joined #nim
04:36:45FromDiscord<Fern & Simula (They/Them)> sometimes `execProcess` just never returns output for a command that always returns output. what's up with that?
04:36:50*Guest8250 quit (Ping timeout: 240 seconds)
04:37:16disruptekhow often?
04:38:17FromDiscord<Fern & Simula (They/Them)> currently? always
04:38:32FromDiscord<Fern & Simula (They/Them)> one sec and ill set up a paste
04:38:35*dadada_ joined #nim
04:39:35FromDiscord<Fern & Simula (They/Them)> the while loop on line 17 never finishes https://play.nim-lang.org/#ix=2bGc
04:41:50disruptekyou probably used up your python invocations for the day.
04:42:21FromDiscord<Fern & Simula (They/Them)> i must've
04:42:31FromDiscord<Fern & Simula (They/Them)> the weird part is inim has the same problem... but only once
04:42:35FromDiscord<Fern & Simula (They/Them)> which is why i set up the loop
04:42:42disrupteklooks like you're not on windows. hmm.
04:42:58FromDiscord<Fern & Simula (They/Them)> nope, fedora
04:44:03disrupteki guess i don't use execProcess. it's very similar to startProcess?
04:45:14FromDiscord<Fern & Simula (They/Them)> i was thinking that might be the issue, so i'm just manually working with startProcess hayha
04:45:32disruptekmy guess is that your system is so warm that it's closing the stream before it even finishes the output.
04:45:52FromDiscord<Fern & Simula (They/Them)> that's what i'm thinking
04:45:53disruptekie. it knows the program is dead and doesn't empty the output buffer.
04:45:56FromDiscord<Fern & Simula (They/Them)> because it *was* working
04:46:32disrupteki do the right thing in golden.
04:46:37disruptek!repo golden
04:46:38disbot12https://github.com/disruptek/golden -- 9golden: 11a benchmark for compile-time and/or runtime Nim πŸ† 15 15⭐ 0🍴
04:46:53disruptekbut it might be a little different from what you're doing.
04:47:20FromDiscord<Fern & Simula (They/Them)> i'll take a look, thank you!
04:47:35disruptekexecCmdEx is a simpler one; i do capture in bump
04:47:38disruptek!repo bump
04:47:38disbot12https://github.com/disruptek/bump -- 9bump: 11a tiny tool to bump nimble versions 🍻 15 13⭐ 1🍴 7& 1 more...
04:49:18FromDiscord<Fern & Simula (They/Them)> if i `open` a filehandle returned from `outputHandle`, should i close that file, or no?
04:49:33FromDiscord<Fern & Simula (They/Them)> trying to make sure i understand the documentation
04:49:47disrupteki have no idea.
04:50:13disrupteki think you can close it prematurely and it costs nothing to do so.
04:50:18disruptekie. no ill-effects.
04:50:50FromDiscord<Fern & Simula (They/Them)> `outputHandle` says "The returned FileHandle should not be closed manually as it is closed when closing the Process p." just wondering if closing the file is the same as closing the filehandle
04:50:57FromDiscord<Fern & Simula (They/Them)> i think so, just not quite certain
04:51:15disrupteki don't know, but that sounds like i'm wrong.
04:52:20disrupteki don't remember that being a problem, but i dunno. i guess we should believe the docs.
04:52:27*dadada_ quit (Ping timeout: 272 seconds)
04:52:55FromDiscord<Fern & Simula (They/Them)> i misread docs anyway, ignore me :P
04:53:38*dadada_ joined #nim
04:53:39*nsf joined #nim
04:54:52FromDiscord<Fern & Simula (They/Them)> yeah, working directly with the process fixed it haha
04:57:27disruptekwhat did you use?
04:59:38disruptektreeform: ping
05:07:07*dadada_ quit (Ping timeout: 260 seconds)
05:07:10*koltrast quit (Ping timeout: 240 seconds)
05:07:22*koltrast_ joined #nim
05:07:58*LER0ever quit (Remote host closed the connection)
05:08:37*dadada_ joined #nim
05:15:58*hax-scramper quit (Read error: Connection reset by peer)
05:16:13*hax-scramper joined #nim
05:22:16*dadada_ quit (Ping timeout: 268 seconds)
05:23:42*dadada joined #nim
05:24:04*dadada is now known as Guest44457
05:36:57*Guest44457 quit (Ping timeout: 265 seconds)
05:38:35*dadada_ joined #nim
05:53:15*dadada_ quit (Ping timeout: 272 seconds)
05:53:35*dadada_ joined #nim
06:03:43*narimiran joined #nim
06:07:49*dadada_ quit (Ping timeout: 272 seconds)
06:08:38*dadada_ joined #nim
06:15:18*hax-scramper quit (Ping timeout: 268 seconds)
06:15:34*hax-scramper joined #nim
06:21:07*marmotini_ joined #nim
06:22:23*dadada_ quit (Ping timeout: 265 seconds)
06:23:37*dadada joined #nim
06:23:59*dadada is now known as Guest81026
06:37:09*marmotini_ quit (Remote host closed the connection)
06:37:22*Guest81026 quit (Ping timeout: 265 seconds)
06:37:41*marmotini_ joined #nim
06:38:40*dadada_ joined #nim
06:39:35*tefter joined #nim
06:42:26*marmotini_ quit (Ping timeout: 268 seconds)
06:48:53*LER0ever joined #nim
06:50:01*ftsf joined #nim
06:52:47*dadada_ quit (Ping timeout: 272 seconds)
06:53:23*marmotini_ joined #nim
06:53:32*dadada_ joined #nim
06:58:11*marmotini_ quit (Ping timeout: 260 seconds)
07:07:06*dadada_ quit (Ping timeout: 268 seconds)
07:08:37*dadada_ joined #nim
07:12:37*marmotini_ joined #nim
07:21:38*dadada_ quit (Ping timeout: 240 seconds)
07:21:55*chemist69 quit (Ping timeout: 272 seconds)
07:22:19*chemist69 joined #nim
07:23:35*dadada joined #nim
07:23:59*dadada is now known as Guest94906
07:27:07*hax-scramper quit (Ping timeout: 260 seconds)
07:37:19*Guest94906 quit (Ping timeout: 268 seconds)
07:38:36*dadada_ joined #nim
07:50:14*solitudesf joined #nim
08:00:00*gmpreussner quit (Quit: kthxbye)
08:04:56*gmpreussner joined #nim
08:08:09*dadada_ quit (Ping timeout: 268 seconds)
08:08:37*dadada_ joined #nim
08:11:55*gmpreussner quit (Ping timeout: 260 seconds)
08:16:27*chemist69 quit (Ping timeout: 240 seconds)
08:20:25*chemist69 joined #nim
08:27:27*marmotini_ quit (Remote host closed the connection)
08:28:04*marmotini_ joined #nim
08:32:47*marmotini_ quit (Ping timeout: 246 seconds)
08:33:08*gangstacat quit (Ping timeout: 246 seconds)
08:47:31*Vladar joined #nim
08:52:03*floppydh joined #nim
09:00:25*d-nice2[m] quit (Quit: killed)
09:00:32*lqdev[m] quit (Quit: killed)
09:00:32*leorize[m] quit (Quit: killed)
09:00:32*skrylar[m] quit (Quit: killed)
09:00:33*Demos[m] quit (Quit: killed)
09:00:54*gangstacat joined #nim
09:10:26*dadada_ quit (Ping timeout: 240 seconds)
09:12:37*dadada joined #nim
09:13:00*dadada is now known as Guest93671
09:21:38*zama quit (Ping timeout: 240 seconds)
09:22:03*zama joined #nim
09:30:27*skrylar[m] joined #nim
09:38:09*Vladar quit (Remote host closed the connection)
09:52:37FromGitter<Varriount> Hrm, Nim's openarrays suffer from aliasing problems. I wonder if those can be solved
09:52:44*leorize[m] joined #nim
09:52:45*lqdev[m] joined #nim
09:52:45*Demos[m] joined #nim
09:52:45*planetis[m] joined #nim
09:52:45*pigmej joined #nim
09:52:45*salotz[m] joined #nim
09:52:45*BitPuffin joined #nim
09:52:45*Yardanico[m] joined #nim
09:52:46*GitterIntegratio joined #nim
09:52:46*unclechu joined #nim
09:52:50*watzon[m] joined #nim
09:52:50*oswin[m] joined #nim
09:52:51*silvernode[m] joined #nim
09:52:51*s87651[m] joined #nim
09:52:51*pqflx3[m] joined #nim
09:52:51*vycb[m] joined #nim
09:52:51*grantmwilliams joined #nim
09:52:51*d-nice2[m] joined #nim
09:52:52*hohlerde joined #nim
09:52:53*freepump[m] joined #nim
09:53:58Araqread https://nim-lang.org/docs/manual_experimental.html#aliasing-restrictions-in-parameter-passing
10:07:01FromGitter<Varriount> Araq: Huh, I was trying to look for that section earlier today, and couldn't seem to find it
10:14:39*bozaloshtsh quit (Ping timeout: 258 seconds)
10:17:20*fanta1 joined #nim
10:26:41Araqaliasing is hard but we'll get there. Nim follows Ada's footsteps which has Spark for verification
10:28:23FromDiscord<mratsim> did you see the SAW link I posted the other day btw?
10:32:40Araqnot really
10:34:34*krux02 joined #nim
10:40:45FromDiscord<mratsim> Formal verification for C: https://saw.galois.com/, based on Z3 https://github.com/GaloisInc/saw-script
10:47:54AraqError: execution of an external compiler program 'clang -c -std=gnu++11 -w -I/usr/home/build/Nim/lib -I/usr/home/build/Nim/compiler -o /usr/home/build/Nim/nimcache/d_freebsd_amd64/linenoise.c.o /usr/home/build/Nim/lib/wrappers/linenoise/linenoise.c' failed with exit code: 1
10:47:54Araqerror: invalid argument '-std=gnu++11' not allowed with 'C'
10:48:23Araqtired of this, gonna revert this linenoise patch
10:49:52FromDiscord<clyybber> Araq, timotheecour: I feel particularily dumb rn, what is the problem with using uint/int as the hash themselves?
10:50:02FromDiscord<clyybber> It can't collide and its just a cast
10:50:07FromDiscord<clyybber> So what am I missing?
10:51:08Araqthe bitmasking operation we do.
10:51:23Araqwe mask the integer so that it fits the underlying seq
10:51:36FromDiscord<clyybber> Ah
10:51:37FromDiscord<clyybber> I see
10:51:39Araqbecause we don't provide space for 4 billion entries in the seq.
10:51:43Araqand that makes all the difference.
10:51:45FromDiscord<clyybber> Yeah
10:51:48FromDiscord<clyybber> Ok, thanks
11:25:26FromDiscord<mratsim> How can you build an electron app if there is no space to ue 4 billions in element in your RAM
11:55:02*kaiyin joined #nim
11:55:59kaiyinI've reading the code in arraymancer and I found this: https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/p_shapeshifting.nim#L25
11:56:31kaiyinI don't understand where the `x` came from?
11:58:50FromDiscord<Rika> https://github.com/mratsim/Arraymancer/blob/master/src/tensor/higher_order_applymap.nim#L45
11:59:43Zevvit's injected by the template
11:59:55Zevvbad hygiene
11:59:59FromDiscord<Rika> yeah
12:00:18FromDiscord<Rika> *whistles* i totally don't do that *whistles*
12:10:41*Kaivo joined #nim
12:13:20*dddddd joined #nim
12:27:42ZevvI do that. It keeps things fresh and exciting
12:31:15FromDiscord<Lantos> is there a way to have leading underscores in type defs?
12:31:25FromDiscord<Lantos> or special chars?
12:32:02FromDiscord<Lantos> type
12:32:03FromDiscord<Lantos> me = object
12:32:03FromDiscord<Lantos> _name: string
12:32:34FromDiscord<Rika> no
12:32:36FromDiscord<clyybber> nope
12:32:40FromDiscord<clyybber> why do you want it?
12:32:54FromDiscord<Rika> i've seen someone use "pFieldName" for private fields
12:32:59FromDiscord<clyybber> Maybe it works when you encase it with ` `
12:33:11*fanta1 quit (Quit: fanta1)
12:33:11FromDiscord<clyybber> but I don't think so " ` "
12:33:18FromDiscord<clyybber> ^
12:33:25FromDiscord<Rika> i dont think it would work anyway
12:33:26FromDiscord<Lantos> trying to map bson to objects and ofc bson has _id as meta
12:33:33FromDiscord<clyybber> just call it id
12:33:36FromDiscord<clyybber> I guess
12:33:44FromDiscord<Rika> or bsonIdMeta or so
12:34:10FromDiscord<Rika> calling it just id would cause issues; what if the user also had an id field?
12:35:56FromDiscord<Lantos> yeah
12:36:00FromDiscord<Lantos> thats why
12:36:20FromDiscord<Lantos> I'll see what JohnAD has done
12:36:52*Guest93671 quit (Ping timeout: 248 seconds)
12:38:33*dadada joined #nim
12:38:57*dadada is now known as Guest79300
12:40:00FromDiscord<Rika> @Lantos idea; anything the user creates, append a word to it. that way you dont get collisions
12:40:11FromDiscord<Rika> not sure if that works actually but its just an idea
12:41:59FromDiscord<clyybber> call it us_id?
12:42:06FromDiscord<clyybber> us as in underscore
12:51:38*Guest79300 quit (Ping timeout: 240 seconds)
12:53:28FromDiscord<OyeGamer> Follow nim.programmer on Instagram.
12:53:38*dadada_ joined #nim
12:54:49FromDiscord<Rika> i dont think you should advertise here
12:58:00YardanicoI wonder what's the point in posting tech stuff in instagram, it's simply made for another thing
13:02:39FromDiscord<Rika> i personally dont use instagram, but knowing facebook i prolly have an instagram account
13:04:07Yardanicowell I have both fb/ig accounts but I don't use them at all xD
13:10:07FromDiscord<Lantos> When you write a document to the mongodb, meta info is auto appended.
13:10:07FromDiscord<Lantos> Eg
13:10:08FromDiscord<Lantos> { "Book": { "name": "Nim in action", "author":"Dominik P"}}
13:10:08FromDiscord<Lantos> Becomes
13:10:08FromDiscord<Lantos> { "Book": { "name": "Nim in action", "author":"Dominik P", "_id":{"$osd":"fheinxeuhscbwkiche"}}}
13:10:15Yardanicopls don't paste like this :P
13:12:37FromDiscord<Rika> that means the user cannot insert _id themselves no? then just make those special cases for the "postfix adder" thing
13:26:07*Vladar joined #nim
13:30:37*nsf quit (Quit: WeeChat 2.7)
13:42:22*zickzackv joined #nim
13:46:46*marmotini_ joined #nim
14:01:36*rockcavera joined #nim
14:08:29*Xatenev joined #nim
14:14:38Araqwhat does Affiliation mean?
14:15:01Araqcontext: applying for a talk at a conference
14:15:54Zevvif you are part of or connected to some organization or company
14:16:48Araqah ok
14:18:58Zevvwhere will you be talking
14:20:09Araqif I'm accepted, Berlin, July, Rebase 2020
14:33:21*dadada_ is now known as dadada
14:37:33FromDiscord<clyybber> Araq: I have ported ryu.
14:37:45FromDiscord<clyybber> Its still pretty unnimified but its getting there
14:37:49*Xatenev left #nim (#nim)
14:38:14FromDiscord<clyybber> I also ported the generic variant which works for float32 and float64 up to floatXX
14:38:22FromDiscord<clyybber> but I need uint128 support
14:38:48FromDiscord<clyybber> Since this has a chance of getting into the stdlib, should I use status bigint library?
14:38:59FromDiscord<clyybber> I would like to, since it actually supports uint128
14:39:11FromDiscord<clyybber> as opposed to the Int128 thats in the compiler
14:42:30Araqgo for it
14:42:57FromDiscord<clyybber> ok nice
14:43:00Araqbut omg it means ryu will add to the code size
14:43:24FromDiscord<clyybber> wdym?
14:43:35FromDiscord<clyybber> I ported the generic variant because its smaller and more elegant
14:43:57FromDiscord<clyybber> or was that an imitation of krux?
14:45:48*sentreen quit (Quit: sentreen)
14:47:26FromGitter<Varriount> clyybber: Well, if Ryu requires an external bigint library, then that library will also need to be added to the standard library.
14:51:08FromDiscord<clyybber> hmm
14:57:57disruptekugh, please don't do that.
14:58:09disruptekjust let leorize work magic.
14:58:19FromDiscord<clyybber> ?
14:58:27FromDiscord<clyybber> maybe I can manage without
14:58:36FromDiscord<clyybber> I mean, its gonna be an array of uint64 then tho
14:58:55FromDiscord<clyybber> and I can just implement the ops I need
14:59:11disruptekthe idea wasn't to put literal ryu in. the idea was to get the tests passing and then hew a very tiny nimish ryu for inside the compiler.
14:59:21FromDiscord<clyybber> yeah
14:59:28FromDiscord<clyybber> so?
14:59:35FromDiscord<clyybber> the algorithms ryu uses need big ints
14:59:37disrupteki think leorize is working on that tiny version.
14:59:41FromDiscord<clyybber> no way around it
15:00:11disrupteksure, but we do have int128 in the compiler already.
15:00:30FromDiscord<clyybber> we could replace that with stint too
15:00:49FromDiscord<clyybber> of course we could also add unsigned support to Int128
15:00:57disruptekto what end?
15:00:58FromDiscord<clyybber> it should be relatively easy I guess
15:01:07FromDiscord<clyybber> disruptek: To what end what?
15:01:08disruptekthis was never a priority.
15:01:19FromDiscord<clyybber> what exactly?
15:01:33disruptekdisruption of the tech.
15:01:38FromDiscord<clyybber> ?
15:02:08disruptekthe reason this finally "had" to happen was float identity or lossless roundtrip in json serialization.
15:02:17FromDiscord<clyybber> yeah
15:02:43disruptekthat goal can be met without turning the compiler on its head.
15:02:52disruptekor creating a political situation with bigints.
15:03:23disrupteklet's do the thing, learn a thing, move on.
15:03:30disruptekstint will always be on the table.
15:03:45FromDiscord<clyybber> Ugh
15:03:50FromDiscord<clyybber> We can use d2s and f2s sure
15:03:50disruptekwell shit, man.
15:03:55disruptekusers have to step up.
15:03:59FromDiscord<clyybber> I'm trying to make it nimmy tho
15:04:13disruptekdid you look at leorize's version?
15:04:53FromDiscord<clyybber> there is nothing
15:05:01FromDiscord<clyybber> it only classifies floats yet
15:05:14disruptekoh, maybe he stopped working on it.
15:05:59disruptekokay, my opinion: put uint128 into int128 and call it good.
15:06:24disruptekyou take over the ryu stuff. i will bow out and work on disruptex instead.
15:07:07*LER0ever quit (Remote host closed the connection)
15:10:34FromDiscord<clyybber> I just fear that int128 will have more bugs
15:10:42FromDiscord<clyybber> which would really suck
15:11:24disruptekthen write a test or two. it's tiny.
15:12:46disruptekwhat did you come up with on that pragma macro problem?
15:13:04FromDiscord<clyybber> tiny as in 600 LOC?
15:13:18FromDiscord<clyybber> disruptek: Nothing, didn't look into it yet :p
15:13:33disruptek600 loc does not impress me.
15:14:10disruptekmaybe you should do a wc on stint before you whine about 600 loc. πŸ˜‰
15:14:56disruptekthis is already technical debt. no good reason not to make it pass some tests, too.
15:14:56*paxis joined #nim
15:15:04FromDiscord<clyybber> stint has 1400
15:15:41FromDiscord<clyybber> but it also works at compile time
15:15:52FromDiscord<clyybber> I don't care which one I use
15:15:55FromDiscord<clyybber> as long as it works
15:16:19FromDiscord<clyybber> maybe I'll just nimify the float32 and float64 variants
15:16:23FromDiscord<clyybber> and not use int128
15:16:42disruptekthat's what i thought we were doing.
15:17:34leorizewhat are y'all working on?
15:18:22*disruptek runs off.
15:19:10FromDiscord<clyybber> disruptek: Nah, I ported the generic variant too
15:19:21FromDiscord<clyybber> And since its less code duplication
15:19:27FromDiscord<clyybber> I thought getting this into the stdlib
15:19:37FromDiscord<clyybber> instead of seperate float32 and float64 variants
15:20:19leorizethe only thing I concerned about c-ryu is that it's kinda a black box
15:20:32leorizethough I'm understanding parts of it thanks to the paper now
15:21:43*dddddd quit (Ping timeout: 260 seconds)
15:27:48disruptekleorize: did you port all the tests or just some?
15:28:21leorizeI'm not working on it atm, will do tmr :)
15:28:43disruptekmaybe clyybber did them all.
15:28:52FromDiscord<clyybber> yeah
15:28:58FromDiscord<clyybber> I ported all of them
15:29:06FromDiscord<clyybber> not the benchmarks yet
15:29:07FromDiscord<clyybber> tho
15:29:24FromDiscord<clyybber> there: https://github.com/Clyybber/nimryu/
15:31:23disruptekwell, if i can help, let me know. i don't mean to rain on the parade.
15:31:41disrupteki just think we have a pretty good compiler and i'd rather work on something that needs a better story.
15:32:06disruptekthree people porting an existing c lib is not that thing, imo.
15:32:17FromDiscord<clyybber> yeah
15:32:17FromDiscord<clyybber> but you stopped
15:32:40FromDiscord<clyybber> I will do the job until the end
15:32:47FromDiscord<clyybber> no worries
15:32:53disruptekwell, in fairness, i was blocked by the int128 bug.
15:33:26Araqdisruptek, it was fixed though, but I agree
15:33:33FromDiscord<clyybber> that excuse has been dropped :p
15:33:38Araqtoo many people seem to work on ryu now
15:33:38*dadada quit (Ping timeout: 240 seconds)
15:33:48AraqI need clyybber for scope-based destruction
15:33:51FromDiscord<clyybber> yeah, let me be the chosen-one πŸ˜„
15:33:57FromDiscord<clyybber> Araq: Ah
15:33:58FromDiscord<clyybber> Haha
15:33:58Araqit's a clusterfuck of complexity :-(
15:34:29FromDiscord<clyybber> Araq: Wouldn't it be simpler to call injectdestructors for each scope?
15:34:29disruptekit's not supposed to be trivial. 😁
15:34:32FromDiscord<clyybber> Instead of handling the scopes in injectdestructor
15:34:46FromDiscord<clyybber> Argh, that might not be possible because of break and stuff right?
15:35:19*NimBot joined #nim
15:35:38*dadada joined #nim
15:36:01*dadada is now known as Guest84067
15:37:03*kaiyin quit (Remote host closed the connection)
15:40:32Araqwhat we also need is lent/sink inference
15:40:41Araqsink inference is rather simple
15:40:41*paxis quit (Quit: Client exiting)
15:40:55*Guest84067 is now known as dadada
15:41:23Araqyou check for the pattern someLocation = parameter
15:41:27FromDiscord<clyybber> You mean sink inference as in what I proposed?
15:41:42FromDiscord<clyybber> Like no explicit sink annotations needed anymore for args?
15:41:43*madprops left #nim ("Leaving")
15:41:46Araqand if the proc has no forward declaration, you can make the parameter a 'sink'
15:42:08dadadaare there charts/diagrams somewhere on how all parts of nim are interlinked?
15:42:14Araqoriginally I though about a naming scheme for 'sink'
15:42:17dadadaespecially the compiler has me interested
15:42:20*madprops joined #nim
15:42:25FromDiscord<clyybber> dadada: Yardanico posted a graph here once
15:42:29FromDiscord<clyybber> a few days ago
15:42:38dadadaI can you through all the files line by line, but the abstract top down view is what would be more welcoming
15:42:41FromDiscord<clyybber> We mean the same thing right?
15:42:46FromDiscord<clyybber> Making sink implicit?
15:43:26Araqdadada, there is https://nim-lang.org/docs/intern.html
15:43:47*paxis joined #nim
15:44:12Araqit uses an architecture most common in the literature, the parser calls the lexer and builds an AST
15:44:22Araqthe AST is sem'checked in two phases
15:44:33Araqand then the code generators see it and produce code
15:44:51Araqread ast.nim and main.nim
15:44:59Araqas a starting point
15:45:21Araqmain.nim does setup the passes over the AST
15:46:48FromDiscord<clyybber> argh, I always forget, can we return in blocks?
15:47:04FromDiscord<clyybber> block expressions that is
15:47:24FromDiscord<clyybber> Araq: Ping, do you mean making sink implicit in parameters?
15:49:09FromDiscord<clyybber> Nice
15:49:36FromDiscord<clyybber> Araq: But still allow for explicit sink params, right?
15:49:46FromDiscord<clyybber> To override the default
15:49:53FromDiscord<clyybber> for closures and stuff
15:49:59FromDiscord<clyybber> and for backwards compatibility I guess
15:50:19FromDiscord<clyybber> and for owned refs
15:50:24FromDiscord<clyybber> or similar linear types
15:51:36FromDiscord<clyybber> Araq: I can fully dedicate myself to destructor stuff in a week or so
15:51:55FromDiscord<clyybber> porting ryu is not really taking any time
15:51:58FromDiscord<clyybber> its just a few seds
15:52:01FromDiscord<clyybber> sed calls
15:52:08FromDiscord<clyybber> so I do it while learning :d
15:57:46dadadayou know this? https://github.com/StefanSalewski/gintro
15:59:03FromDiscord<clyybber> whom are you asking?
15:59:11FromDiscord<clyybber> I know it
15:59:13FromDiscord<clyybber> theres also https://github.com/trustable-code/NiGui
16:04:32Araqsure, explicit 'sink' will remain
16:04:47Araqso there are two competing designs:
16:05:19Araq1. sink annotations based on proc names. we know []=, add take sink parameters
16:05:31Araqand that [] produces a lent T
16:05:45Araq2. sink parameter inference based on the proc body
16:05:54AraqI dunno what will work better
16:06:12Araq(2) is more standard in computer science
16:07:09FromDiscord<clyybber> Araq: I vote for 2
16:07:13krux02Araq: I don't like the "based on the name" part at all.
16:07:25FromDiscord<clyybber> But I'm not sure why we should do the inference based on the proc body
16:07:34FromDiscord<clyybber> Araq: We could just do it a bit like generics
16:07:52*floppydh quit (Quit: WeeChat 2.7)
16:07:59FromDiscord<clyybber> If a param in a call is a last read, then we call the variant where that appropriate param is a sink
16:08:14FromDiscord<clyybber> For closures and function pointers there will be a default
16:08:17dadadaI created a project using nimble init
16:08:27dadadabut then in its default state it doesn't build
16:09:15disruptekwhat could be built?
16:10:20Araqkrux02, I would only enable it for the stdlib where the naming scheme is defacto enforced anyway
16:10:40Araqother code would need to opt-in
16:10:50Araqit's the simplest thing that can possibly work :P
16:11:12Araqclyybber: I don't understand how you can do it without looking at the proc body
16:11:53krux02I really don't like the hole idea of semantics for the computer encoded in the name.
16:12:13FromDiscord<clyybber> Araq: Why would you need to look at the procs body?
16:12:26FromDiscord<clyybber> You would just generate variants of the proc on demand
16:12:31FromGitter<kaushalmodi> dadada: If you init the project as a library, it won't build
16:12:39FromGitter<kaushalmodi> init it as app or hybrid
16:13:02krux02Names were up until now and in almost all programming languages a human only thing. The only difference I know is Go where a function/member is exported, if it is written with a capital letter in the beginning.
16:13:21krux02And that only works, because it is enforce 100% through all of the code.
16:13:35FromDiscord<clyybber> Araq: Best way I can phrase it is like as if every param is a generic, that will be resolved to sink or not sink when instantiated, based on wether we pass a last read as the call argument
16:14:21disruptekwe talked about dispatch on sink before.
16:15:05FromDiscord<clyybber> I'm only using this metaphor to get my idea across
16:15:26disrupteki agree that naming seems like a strange place to add a semantic, since naming is constrained by unrelated requirements.
16:16:24FromDiscord<clyybber> Araq: I remember last time I proposed this you said it would cause code bloat
16:17:18FromDiscord<clyybber> But if we cap it it should be fine I think
16:19:23FromDiscord<clyybber> In theory it introduces 2^n variants where n is the amount of params
16:20:13FromDiscord<clyybber> which is bad code bloat
16:20:17dadadadisruptek: I've made the experience that similar tools of other langs create a default structure that runs and builds, most recently with kotlin
16:21:03dadadakaushalmodi: okay, thanks
16:21:15FromDiscord<clyybber> but in practice I think we can discard the distinctions for parameters based on some heuristics
16:21:44dadadathere's no web scraping lib for nim yet?
16:22:44Araqclyybber: looks like a bad idea
16:23:01Araqfor example, assume an 'add' without sink annotation
16:23:22Araqand we compile s.add notLastReadHere(x)
16:23:41Araqand then later
16:23:46Araqs.add lastUse(x)
16:24:02Araq--> 2 instantiations of 'add' produced
16:24:07FromDiscord<clyybber> Yeah
16:24:19Araqone of which is pointless as it can be done as s.add copyof(x)
16:24:36FromDiscord<clyybber> But copyof introduces a copy
16:24:51FromDiscord<clyybber> Which could be potentially expensive
16:24:57FromDiscord<clyybber> No?
16:25:16Araqno for the simple reason that your non-sink add variant also does the copy too
16:25:25Araqit's simply code bloat though
16:27:12Araqfor the same reason we do not support overloading based on 'sink T', I never found a case where it made sense
16:27:19FromDiscord<clyybber> Araq: Hmm, right
16:27:22Araqthere is no polymorphism at work here
16:27:33Araqparameters are either always sink or they are not
16:27:38FromDiscord<clyybber> Araq: Then why do we not have everything sink?
16:27:52Araqcome on, didn't watch my talk? :P
16:28:02FromDiscord<clyybber> I did, I think
16:28:13FromDiscord<clyybber> But my head is "full"
16:28:20Araqecho x # er, pass a copy of 'x' to 'echo'? wtf
16:28:29*ftsf quit (Ping timeout: 272 seconds)
16:28:47Araqusing sink for non-sink parameters is a performance killer
16:29:02Araqas much as not using sink for where it's required
16:29:10FromDiscord<clyybber> hmm
16:29:26Araqinference based on a proc body is really simple though
16:29:35Araqthe patterns to look for are
16:29:49AraqsomeDest = parameter
16:29:56lqdev[m]every time I work with methods, I wonder what's the damn point of all these method lock level warnings
16:30:16Araqthat's it, trivial to do in sempass2.nim
16:30:40Araqall you need to watch out for is if the proc was used already before we have seen its body
16:30:40lqdev[m]like, afaik, lock levels have something to do with threading? but my program's not multithreaded and --threads:off
16:31:10FromDiscord<clyybber> Araq: Thats really cool.
16:32:18Araqlqdev[m], preventing deadlocks at compile-time is a killer feature though and --threads:on should be the default in 2020 *cough*
16:32:19FromDiscord<clyybber> So stuff like echo won't get the sink param because the the underlying procs that use its parameter don't have sink params
16:33:05FromDiscord<clyybber> Araq: So there are a few procs from which we infer it "upwards"
16:33:08FromDiscord<clyybber> thats really cool
16:33:22FromDiscord<clyybber> I really like it
16:33:44*Kaivo quit (Quit: WeeChat 2.7)
16:33:48lqdev[m]Araq: what does the lock level have to do with deadlocks? sorry but I'm not really into threaded programming
16:34:21FromDiscord<clyybber> You don't get deadlocks when your locklevels are correct
16:34:22FromDiscord<clyybber> basically
16:34:37*jakob0094 joined #nim
16:34:44Araqlqdev[m], right now it's only a burden but Nim prevents both data races and deadlocks at compile-time
16:35:09Araqit was never explored well though because of the bad thread-local heaps
16:35:38Araqwhich killed most efforts to multi-thread anything in Nim
16:37:11*nsf joined #nim
16:37:12jakob0094hi people! Is there an easy way to hash ref objects? can i just use hash(unsafeAddr obj)?
16:37:38Araqdo not hash 'unsafeAddr'
16:37:50Araqit's usually a stack address and volatile
16:37:51*marmotini_ quit (Read error: Connection reset by peer)
16:38:04Araqcompute the hash based on the pointer's value instead
16:38:41jakob0094ah, thank you
16:39:39jakob0094is that safe to use for every gc? this will probably break if objects are moved during garbage collection
16:39:48*zickzackv quit (Remote host closed the connection)
16:41:32disruptekwhat are you trying to do poorly?
16:41:58jakob0094identity hashmaps
16:42:46Araqjakob0094, we don't have a moving GC. it's a good point though
16:42:51jakob0094no, i'm implementing the epa algorithm for collision detection. i need to track faces, vertices and edges by identity
16:43:14disrupteki think an id field makes more sense.
16:44:04AraqI agree with disruptek
16:44:06disruptekdo you want it to work or do you want clever bugs?
16:44:08jakob0094yes, you are right. should have thought about that
16:46:08*sentreen joined #nim
16:49:45*zickzackv joined #nim
16:54:00Araqlqdev[m], feel free to disable the warning though
16:55:03*zickzackv quit (Ping timeout: 260 seconds)
16:58:07*Trustable joined #nim
16:58:44disruptektreeform: i wish we had a way to publish working google api tests with a harmless set of credentials.
17:00:48lqdev[m]Araq: I know I can disable it, but adding `{.push warning[LockLevel]: off.}` and `{.pop.}` to each file that uses methods *in a library* (so I can't use nim.cfg/config.nims) quickly becomes annoying
17:01:43Araqyour library shouldn't use 'method' :P
17:01:53Araqfor extension points use proc vars
17:02:33disruptekwise words.
17:02:49Araqbut don't take me too seriously, I live in a different world
17:03:27disrupteknot in this case.
17:03:32lqdev[m]I live in a different world, too. I used java for too long so I don't know what's really "idiomatic"
17:03:58FromDiscord<clyybber> minecraft?
17:04:05disruptekAraq: are you interested in the gittyup cpp failure?
17:04:10lqdev[m]nope, processing
17:04:12disruptekunrelated to exceptions.
17:04:12FromDiscord<clyybber> Araq: You are not the only one
17:04:26lqdev[m]never got into minecraft modding.
17:04:27FromDiscord<clyybber> I had to use lambdas instead of methods too
17:04:31FromDiscord<clyybber> for my framegraph
17:04:37FromDiscord<clyybber> lqdev[m]: Ah processing is cool
17:04:49FromDiscord<clyybber> Thought about building something similar in nim
17:06:01lqdev[m]might be a cool idea to add a Nim mode to processing ;)
17:09:21FromDiscord<clyybber> processing is inherently java, no?
17:09:30FromDiscord<clyybber> so not sure how that would work
17:09:38FromDiscord<clyybber> maybe with graal
17:09:58leorizeprocessing does have a js and python target
17:13:29FromDiscord<clyybber> oh
17:13:31FromDiscord<clyybber> nice
17:14:11FromDiscord<Rika> imagine a python target on nim
17:14:13FromDiscord<Rika> god, no
17:14:21FromDiscord<Rika> never mind, ignore what i said
17:16:26*marmotini_ joined #nim
17:22:36FromDiscord<sveri> Hi, I am still trying to run async code behind multiple threads, but still fail. As far as I can tell I did everything just like in px2, but somehow only one thread is being used.
17:22:36FromDiscord<sveri> This is the most minimal example I was able to put together: https://pastebin.com/f0i4TtT5
17:22:37FromDiscord<sveri> threadid output is always the same when I try to open multiple connections at the same time (I use ab for testing).
17:22:37FromDiscord<sveri> Any ideas what is wrong?
17:37:58FromDiscord<sveri> disruptek: I have threads on. I run on windows with the latest nim version if that is of any help
17:39:18disruptekhttputils.nim would help.
17:40:47FromDiscord<sveri> I just installed that as a dependency, I assume it's this one: https://github.com/status-im/nim-http-utils/blob/master/httputils.nim
17:42:43disruptekhow do i run your ab test?
17:43:32FromDiscord<Recruit_main_70007> does nim have ownership checking?
17:43:44disbot9arc: 11a new memory manager for Nim; see https://forum.nim-lang.org/t/5734 -- 7disruptek
17:44:24FromDiscord<sveri> I use ab from apache: `ab.exe -c 5 -n 5 http://localhost:5000/`. It comes with apache-utils on ubuntu IIRC or xampp on windows.
17:44:39disruptekyeah, i just want to repro your command-line.
17:44:43FromDiscord<sveri> if you just open it multiple times in a browser you will see the same
17:46:33disruptekworks for me on linux.
17:46:47FromDiscord<clyybber> @Recruit_main_70007 Yeah
17:46:49disruptekare you running runServer() and not start()?
17:46:52FromDiscord<clyybber> With --newruntime
17:47:02FromDiscord<clyybber> For now the idea is on hold tho
17:48:33FromDiscord<sveri> disruptek: No, I run it with the start function from my `main` nim file. So it prints different thread ids on your machine?
17:48:33FromDiscord<clyybber> @Recruit_main_70007 If you want to ensure one owner for some type just define "proc \`=\`(a: var YourType, b: YourType) {.error.}"
17:49:06disrupteksveri: yes.
17:50:01*nsf quit (Quit: WeeChat 2.7)
17:50:53FromDiscord<sveri> jeez, I spent hours, but it did not cross my mind it could be an OS problem. Does it make sense to open an issue on github for this?
17:51:10FromDiscord<sveri> I get that mostly servers run on linux, but it would be nice to have it working on windows too.
17:51:20disrupteki doubt it; i'd probably call them on the phone.
17:51:52disrupteki think their investment in github is more strategic than practical.
17:52:32disruptekperhaps with a couple exceptions here and there; things like powershell (?) or whatever.
17:52:54FromDiscord<sveri> Hm, I am not sure if you are honest right now or not? πŸ˜„
17:53:29FromDiscord<sveri> *serious
17:53:40*zickzackv joined #nim
17:56:50dadadaso many great python libraries that you can't use natively in nim
17:58:02FromDiscord<sveri> disruptek: thanks for trying to reproduce this πŸ™‚
17:59:48dadadajust imagine if nim had python's popularity ... one can dream, right
18:00:10FromDiscord<Recruit_main_70007> one day
18:00:45disruptekstart today.
18:01:07disruptekdon't be afraid to write some nim.
18:02:13dadadadisruptek: am not
18:06:12FromDiscord<Rika> the macros i make scare me
18:07:01FromDiscord<clyybber> @sveri disrupteks tongue has pierced his cheek a long time ago
18:07:47FromDiscord<clyybber> @Rika the macros I don't make are scarier
18:08:28FromDiscord<clyybber> I'd rather have a scary macro than a file that is empty when piped through uniq
18:08:29FromDiscord<clyybber> :p
18:19:36FromDiscord<Rika> it's going to be a maintenance nightmare though won't it?
18:19:40FromDiscord<Recruit_main_70007> macros scare me in general
18:19:59disruptekempty files are rarely a maintenance nightmare, ime.
18:20:23FromDiscord<Rika> ime? in my epeneien?
18:21:34disruptekexperience. i've experienced the maintenance of so, so many empty files.
18:23:21FromDiscord<Kingherring> for this valentines day, I am in love with Nim
18:24:41leorize[m]do you bring gifts?
18:25:30FromDiscord<Rika> disruptek is it really maintenance if theres nothing to maintain
18:25:53FromDiscord<Elegant Beef> > disrupteks tongue has pierced his cheek a long time ago
18:26:00disruptekare you saying i'm too incompetent to maintain empty files?
18:26:15disrupteklet me have my wins, ffs.
18:26:22FromDiscord<Elegant Beef> That's an implication that disruptek is tongue and cheek
18:26:33FromDiscord<Elegant Beef> This guy has never been serious as long as i've been here πŸ˜„
18:26:37*zama quit (Ping timeout: 260 seconds)
18:26:41FromDiscord<Elegant Beef> And he disobeys poes law
18:26:50FromDiscord<Kingherring> @disruptek are you saying my love for Nim is not enough for you?
18:26:59disruptekis that the one about masturbation and chili peppers?
18:27:09*zama joined #nim
18:27:18FromDiscord<Elegant Beef> No it's the one about insincerty being undetectable on the internet without indication
18:27:19FromDiscord<Rika> yeah i dont know why i bothered trying to be serious
18:27:33disruptekthese files are seriously empty.
18:28:22FromDiscord<Rika> "program something that prints itself", aka a quine-but-not-really-as-quines-need-to-have-content
18:28:39disruptekcontents remain undetectable on the internet. i guess i need a cat.
18:29:10disruptekln -s /dev/null program.that.prints.itself
18:29:26FromDiscord<Elegant Beef> I write all my code in using tabs/spaces that converts from morse code
18:29:51FromDiscord<Elegant Beef> It's the most useful obfuscsation method
18:30:05disruptekmorse code? keep swinging, slugger.
18:30:15FromDiscord<Rika> try programming in unary
18:31:33*bozaloshtsh joined #nim
18:31:34*bozaloshtsh quit (Changing host)
18:31:34*bozaloshtsh joined #nim
18:33:45FromDiscord<clyybber> @Elegant Beef https://github.com/belamenso/v
18:35:35FromDiscord<Rika> why
18:35:46FromDiscord<Rika> that's deffo unary isnt it
18:36:47*dadada quit (Ping timeout: 260 seconds)
18:38:28FromDiscord<clyybber> > why
18:38:37FromDiscord<clyybber> we should stop asking why
18:38:43*dadada joined #nim
18:38:50FromDiscord<clyybber> when we *can*
18:39:06*dadada is now known as Guest38585
18:43:56*xet7 quit (Remote host closed the connection)
18:44:56*xet7 joined #nim
18:57:39FromDiscord<Elegant Beef> V is still better than python
18:58:00FromDiscord<Elegant Beef> strongly typed, with dynamic typing, *pukes*
18:58:25FromDiscord<clyybber> this is not V
18:58:30FromDiscord<clyybber> this is a nim macro
18:58:40FromDiscord<clyybber> this is not V-lang
18:58:46FromDiscord<Elegant Beef> i know
18:59:00FromDiscord<Elegant Beef> im saying using v would be better than using python
18:59:59FromDiscord<clyybber> certainly not for quick shell like scripts
19:00:35*sagax quit (Ping timeout: 268 seconds)
19:02:20FromDiscord<Elegant Beef> You underestimate my dislike of python πŸ˜›
19:02:31FromGitter<nixfreakz_twitter> Opinon: What do you people use for programming methodology , Bottom-up or Top-down
19:02:53FromGitter<nixfreakz_twitter> I trying to figure what works best for me
19:04:26disruptekthen why are you asking us?
19:04:39FromDiscord<clyybber> bottom-down
19:04:44FromDiscord<clyybber> story of my life
19:06:21FromGitter<nixfreakz_twitter> great question , because getting others feedback help me figure out an issue, even if it relevant or not
19:08:11disruptekwhat's the problem you're having?
19:09:39*JustASlacker joined #nim
19:10:35Araqnixfreakz_twitter: neither, start with data modelling
19:10:49Araqthe data then guides your algorithms
19:11:39Araqcode is usually overrated, data lasts longer than code
19:12:14FromDiscord<treeform> disruptek, "treeform: i wish we had a way to publish working google api tests with a harmless set of credentials." - Yeah that's hard.
19:12:41FromDiscord<treeform> <disruptek> "treeform: ping", what?
19:13:03*dddddd joined #nim
19:13:28disruptekasked and answered, i guess. πŸ˜‰
19:14:50*tefter quit (Ping timeout: 240 seconds)
19:15:20FromDiscord<treeform> ok...
19:15:51disruptekgoogle is moving to swagger-3 and i'm not (yet). so ima hold off switching to quickjwt until then.
19:16:03FromDiscord<treeform> wut?
19:16:26FromDiscord<treeform> What is swagger-3? I just had a bunch of pain learning about jwt...
19:16:51disruptekopenapi 3 is different from openapi 2 (aka swagger).
19:17:36disrupteki'm realizing that if something i wrote isn't worth someone else exploiting, then it's not worth me maintaining.
19:18:06FromDiscord<treeform> that is true, I mostly write stuff for myself.
19:18:54FromGitter<nixfreakz_twitter> data modeling , interesting
19:20:15FromGitter<nixfreakz_twitter> hmm isn't data modeling more for , say you are implementing a database in your code?
19:23:11disruptekdon't overthink it.
19:24:51*rockcavera quit (Remote host closed the connection)
19:25:11FromDiscord<sveri> Oh that brings back nightmares. I just evaluated openapi 3.0, which is the successor to swagger 2.0, at work.
19:25:11FromDiscord<sveri> While the spec itself is okay the tools around everything is just a big clusterfuck. Especially with regards to java. Jeez, after I got some stuff working turns out, my target server only supports 2.0, start over again.
19:26:53FromDiscord<treeform> I still have nightmares about WSDL and Apache Axis ...
19:26:56disruptekyes, it's a major pita.
19:27:35FromDiscord<treeform> I remember I was to consume WSDL api from python. Python does not have good WSDL support.
19:27:51FromGitter<Varriount> Syntactically, it's close to Pascal
19:27:59FromDiscord<treeform> I think I ended up generating all of the XML by hand and sending it through.
19:28:15FromGitter<Varriount> Goodness gracious, timotheecour is quite productive...
19:29:32FromDiscord<sveri> Hm, I implemented a major API from a WSDL spec and at least the java classes got generated as expected and were useable which is not the case with openapi 3.0
19:29:35disrupteki used to generate the ebay apis from a wsdl file that was like, i dunno, 10meg.
19:29:58disruptekhad to hand-edit it first due to circular references unsupported by python wsdl parser.
19:31:47*rockcavera joined #nim
19:32:47disruptekthe problem with openapi is that the tools don't produce quality output, so supporting garbage-in without garbage-out takes a lot of work.
19:34:21disrupteknot a big deal for one api, but pretty unsatisfying for supporting thousands of apis at once.
19:36:09*sagax joined #nim
19:36:17FromGitter<nixfreakz_twitter> @Araq - Do you use UML or something similar to sketch out your data ?
19:36:50FromDiscord<sveri> I see, pain is everywhere
19:37:07FromDiscord<treeform> nixfreakz_twitter, I am about 99.999% Araq does not use UML.
19:37:20FromDiscord<treeform> Because 99.9 of programmers don't use UML.
19:37:47Araqnixfreakz_twitter: depends on your use cases, but starting with Nim's "type" section helps
19:38:03AraqI would suggest JSON if it offered a schema
19:38:13Araqor maybe SQL
19:38:29FromGitter<nixfreakz_twitter> Ok thanks for the info
19:40:14Araqfor NimForum I started with the SQL model and maybe dom96 cursed me for it
19:40:39Araqbut IME it worked out well
19:41:48Araqand I think our users appreciate we don't lose their posts and the database is not seen as a "dumb" data store that needs to hidden and abstract
19:42:03FromGitter<nixfreakz_twitter> does it make sense to use a data model when creating , say commandline tools ?
19:42:26FromGitter<nixfreakz_twitter> should I use types for everything at first and build from there ?
19:43:02*Guest38585 is now known as dadada
19:43:03Araq"commandline tool" only means it will lack a UI.
19:43:13Araqwhat tool are you working on?
19:45:20FromDiscord<Elegant Beef> I've got to ask, would something like interfaced ever be added as a nim module?
19:45:32Araqbut yeah, for example modelling your command line flags as a set[enum] helps, you translate the input strings into real typed data and then you work with types and not with strings everywhere
19:46:00FromDiscord<Elegant Beef> Obviously the more recent one isnt licensed properly but just interested in interfaces in languages πŸ˜„
19:46:06Araq<Elegant Beef>: yes
19:46:39FromGitter<nixfreakz_twitter> Nothing in particular more for parsing out data , instead of using grep, awk, bash, rg and so on
19:46:40FromDiscord<Elegant Beef> Ah ok cool
19:47:02FromDiscord<Elegant Beef> I mean is it a oneoff thing?
19:47:04Araqafter https://github.com/nim-lang/RFCs/issues/192 we might embrace interfaces and pattern matching
19:47:06disbotβž₯ 3outplace and chaining ; snippet at 12https://play.nim-lang.org/#ix=2bIT
19:47:26FromDiscord<Elegant Beef> If so i dont really think spending all that time on it is worth it
19:47:38FromDiscord<Elegant Beef> But i mean look what i did for my silly rofi cmd thing
19:47:39FromDiscord<Elegant Beef> πŸ˜„
19:47:51FromDiscord<Elegant Beef> Also Araq, i did properly style it
19:47:52FromDiscord<Elegant Beef> so be merry
19:47:53FromDiscord<Elegant Beef> πŸ˜›
19:48:22FromDiscord<Elegant Beef> Also sweet
19:48:28AraqI don't understand
19:48:50FromDiscord<Elegant Beef> The oneoff thing and spending the time was to nixfreakz
19:48:59Araqbut I'm always polite, it's just that most don't realize
19:49:16FromDiscord<Elegant Beef> I was the schmuck that used pascal cased functions
19:49:43FromDiscord<Elegant Beef> after cleaning it up i decided, eh wth and properly style the nim files to the camel cased standard
19:49:54Araqdon't worry about it
19:50:05FromDiscord<Elegant Beef> I wasnt, i was more joking around
19:51:08FromGitter<nixfreakz_twitter> <Araq> I don't understand > me?
19:51:42AraqI didn't understand Elegant Beef
19:51:54FromGitter<nixfreakz_twitter> ok
19:52:09Araqnixfreakz_twitter: maybe study nimgrep's source code
19:52:37FromGitter<nixfreakz_twitter> yep you told me about that before , and that was great.
19:54:08FromDiscord<Elegant Beef> @clyybber i've got to ask, what 3D format do you intend to use for your engine?
19:54:12dadadaAraq: I mostly like your new proposal for chaining/outplace, can it also be block syntax in one line like: use w: setColor(green).setPosition(1, 2).setVisible(true)
19:54:24FromDiscord<clyybber> @Elegant Beef I don't intend on going 3D :p
19:54:30FromDiscord<Elegant Beef> Ah
19:54:33FromDiscord<Elegant Beef> Well damn
19:54:50FromDiscord<Elegant Beef> Was thinking of making a gltf2 importer πŸ˜„
19:54:53Araqdadada, sure
19:55:10dadadaAraq: good, because I like it a little more that way :D
19:55:10Araqbut I now prefer ',' over '.'
19:55:11FromDiscord<Elegant Beef> But it's hard to have an importer when you cant check if the model imported properly ;D
19:55:12FromDiscord<clyybber> @Elegant Beef https://github.com/zacharycarter/gltf.nim
19:55:18FromDiscord<Elegant Beef> god damn it
19:55:25FromDiscord<Elegant Beef> Leave something for the little guy!
19:55:29FromDiscord<clyybber> haha
20:01:16dadadaAraq: maybe we could reuse the use block for a second use case (unintended intended puns), what if w is a proc instead of an object, couldn't every line in that case be a a call to that function with different arguments? for example when setting configs you often have many lines with calls like ConfigObject.enableSetting("SettingName", true) and then you have to write ConfigObject.enableSetting( on multiple
20:01:22dadadalines, and with indention you'd also add structure/readability
20:02:20dadadaAraq: maybe something like this should be implemented under a different proposal, but I wanted something like that, and it now occured to me that "use" is a broad enough word to fit both use-cases
20:03:25FromDiscord<exelotl> lol I bound the same gltf library just a few days before https://gist.github.com/exelotl/3cf6c15e4ac2c93f2274c48352808c1b
20:03:47FromDiscord<Elegant Beef> God damn you people
20:03:49FromDiscord<Elegant Beef> πŸ˜„
20:04:08FromDiscord<clyybber> lol
20:04:26FromDiscord<exelotl> but after doing so I came to the conclusion that Nim would benefit from a native one anyways
20:04:37FromDiscord<Elegant Beef> I mean i was thinking doing it natively
20:04:48FromDiscord<Elegant Beef> it's an open standard
20:04:49FromDiscord<clyybber> ~motd is google before work
20:04:49disbot9motd: 11Join a non-Nim project with the goal of exposing that community to Nim. Do it now!
20:04:49disbot9motd: 11google before work
20:05:27FromDiscord<Elegant Beef> If i googled before doing anything i'd probably have 0 code ever written
20:06:43FromDiscord<exelotl> so yeah I say go for it @Elegant Beef
20:07:02FromDiscord<Elegant Beef> A lot of my code tends to be "Hey i made this thing", then i get told "This thing exists in this thing here" and i go "Oh but my thing is mine"
20:07:03FromDiscord<Elegant Beef> πŸ˜„
20:07:15FromDiscord<exelotl> whenever I get round to doing 3D stuff in Nim I'd probably rather use whatever you come up with than some C bindings x)
20:07:31FromDiscord<Elegant Beef> You put a lot of faith in my coding abillity
20:07:36FromDiscord<Elegant Beef> πŸ˜›
20:08:00Araq<Elegant Beef>: please give us an entity component library that doesn't suck
20:08:08AraqI think that's still missing
20:08:13FromDiscord<Elegant Beef> Add interfaces, and that's a deal
20:08:18FromDiscord<Elegant Beef> πŸ˜„
20:08:28Araqinterfaces kill your performance for this anyway
20:08:39Araqyou need to find a better solution
20:08:58FromDiscord<Elegant Beef> Huh, a better solution than interfaces for modular code?
20:09:26FromDiscord<clyybber> yes
20:09:43FromDiscord<Elegant Beef> Composition is good though
20:10:00FromDiscord<clyybber> ecs is composition
20:10:10FromDiscord<clyybber> but not necessarily oo
20:10:20FromDiscord<clyybber> and if you want performance
20:10:24FromDiscord<clyybber> definitely not oo
20:10:26*zama quit (Ping timeout: 240 seconds)
20:10:47FromDiscord<exelotl> @Elegant Beef do you specifically mean the "runtime polymorphism" kind of interfaces?
20:10:49FromDiscord<Elegant Beef> To be fair my experience with ECS, is hearing people talk about it in unity and running the otherway cause it's unity so it's not going to be ready for like 5 years
20:10:58FromDiscord<Elegant Beef> Yea C# like interfaces
20:11:14FromDiscord<clyybber> unitys ecs is fine
20:11:33FromDiscord<Elegant Beef> I mean it's unity, so you say that but it's probably half assed in someway and needs work
20:11:57FromDiscord<exelotl> unity's ecs would be fine if the language had macros like us x)
20:12:06FromDiscord<exelotl> it's very boilerplatey
20:12:07FromDiscord<Elegant Beef> Hell their production ready URP doesnt even allow custom post process effects
20:12:25FromDiscord<clyybber> > unity's ecs would be fine if the language had macros like us x)
20:12:26Araqfwiw I started an ECS
20:12:37FromDiscord<clyybber> - exelotl : happy little macro
20:12:39Araqbut it never went anywhere
20:12:45FromDiscord<Elegant Beef> You dont want me to write an ECS im daft πŸ˜„
20:13:17*arecaceae quit (Remote host closed the connection)
20:13:35*zama joined #nim
20:13:39*arecaceae joined #nim
20:13:44FromDiscord<Elegant Beef> I mean seems to me an ECS isnt too hard
20:14:07FromDiscord<clyybber> its an array
20:14:12FromDiscord<clyybber> *seq
20:14:13FromDiscord<Elegant Beef> Well table list
20:14:19FromDiscord<Elegant Beef> table of id, to list of components
20:14:45FromDiscord<clyybber> the way you select entities is the key
20:14:49FromDiscord<clyybber> to success and failure
20:14:52FromDiscord<clyybber> in terms of performance
20:15:24FromDiscord<Elegant Beef> what do you mean? Wouldnt a table be rather performant for this?
20:15:44FromDiscord<Elegant Beef> actually can we have seqs of seqs in nim?
20:15:54FromDiscord<clyybber> of course
20:16:03FromDiscord<Elegant Beef> That removes the has op, then can have a set holding the id pools
20:16:05FromDiscord<Elegant Beef> or a queue rather
20:16:19FromDiscord<Elegant Beef> is there a setqueue? πŸ˜„
20:16:27FromDiscord<clyybber> yeah
20:16:29FromDiscord<Elegant Beef> im certainly going to make this in my idea now
20:16:29FromDiscord<clyybber> intset
20:16:31FromDiscord<clyybber> + seq
20:16:32FromDiscord<clyybber> maybe
20:16:36FromDiscord<clyybber> or table
20:16:41FromDiscord<clyybber> or whatever you want it to be
20:16:51FromDiscord<Elegant Beef> well table has the hash func which will be more expensive then just accessing the seq
20:16:59FromDiscord<Elegant Beef> for large numbers atleast
20:17:28FromDiscord<clyybber> yeah
20:17:32FromDiscord<clyybber> and its a better idea
20:17:39FromDiscord<clyybber> to have a proc that gives you new ids
20:17:45FromDiscord<clyybber> and reuses old ones
20:17:49FromDiscord<Elegant Beef> Well i say have a queue
20:17:51FromDiscord<clyybber> if they are not used anymore
20:18:04FromDiscord<Elegant Beef> que ue up x number of ints at start, when you need more add x more
20:18:07FromDiscord<Elegant Beef> queue up x number of ints at start, when you need more add x more
20:18:22FromDiscord<Elegant Beef> When you delete an object remove it's id from the seq and readd to queue
20:18:31FromDiscord<clyybber> yeah
20:18:31FromDiscord<Elegant Beef> which is where a setqueue comes in handy
20:18:52FromDiscord<clyybber> replace queue with intset
20:18:54FromDiscord<Elegant Beef> Im sure you guys will tear apart my code when i write it
20:19:27*Vladar quit (Quit: Leaving)
20:19:30FromDiscord<Elegant Beef> I dont mean that in a self deprecating way
20:19:32Araqone ingredient is an ID mechanism that is a tuple of (incremental int, generation)
20:19:47FromDiscord<clyybber> @Elegant Beef pulled beef
20:20:03FromDiscord<clyybber> Araq: Why generation?
20:20:24Araqso you can mask out the generation to access component[x] directly
20:20:44Araqclyybber: to keep track of deleted entities in a most effective way
20:20:53FromDiscord<Elegant Beef> That doesnt matter
20:21:02FromDiscord<Elegant Beef> when you delete an entity you clear it's list of components
20:21:18FromDiscord<Elegant Beef> when you delete a component you remove it from the entity seq
20:21:26FromDiscord<exelotl> I don't really like structure-of-arrays style ECS but my first Nim project was an entity system which I still wanna go back to some day. It looked like this: https://gist.github.com/exelotl/93d9e463383ccfd92810b443e6971409
20:21:41FromDiscord<Elegant Beef> the components store their index got from add component
20:21:43FromDiscord<Elegant Beef> for easy access
20:21:53Araqdepends on how you do it, I've seen it done the way I described
20:21:59*JustASlacker quit (Ping timeout: 268 seconds)
20:22:07FromDiscord<exelotl> but that was before {.this:self.} got canned :(
20:22:08FromDiscord<Elegant Beef> Well when i write mine and share it im sure you can assualt it
20:22:13FromDiscord<Elegant Beef> Well when i write mine and share it im sure you can assault it
20:22:16Araqbecause it enables "weak" references
20:22:35FromDiscord<Elegant Beef> yea idk what that is
20:22:48Araqexelotl: it's only deprecated :P
20:22:50FromDiscord<Elegant Beef> I just try to write clean non redundant code
20:22:56Araqit's still a thing
20:22:57FromDiscord<Elegant Beef> "only deprecated"
20:23:15Araqbut we're getting 'with' see my RFC
20:23:40Araqthere is also 'cascade' and others as Nimble packages
20:25:12FromDiscord<Elegant Beef> I guess in nim the equivlent of a public static class is just a nim file with functions eh?
20:25:24*JustASlacker joined #nim
20:25:37FromDiscord<clyybber> sure
20:25:47FromDiscord<exelotl> yep
20:26:23FromDiscord<exelotl> Araq: oh yeah do methods still use dispatch trees?
20:27:12FromDiscord<clyybber> they use strings
20:27:17FromDiscord<clyybber> lol
20:28:04FromDiscord<exelotl> :thonk:
20:31:19Araqyou want better DLL support, you're getting better DLL support
20:31:31Araqand what are a couple of strstr calls among friends?
20:32:04AraqPRs are always welcome though
20:34:26FromDiscord<clyybber> Araq: If one dll has a type different from the other one but named the same it will not work right?
20:35:06Araqthe names are derived from the module name and the nimble package iirc
20:36:54jakob0094i created this attempt at an ecs a while ago: https://gist.github.com/vogelj/a912a1d1e626fedc291c81c801c7996f. it uses linear search to look up components for now, because i had no need to optimize it yet
20:37:24jakob0094but it allows arbitrary objects as components and does not copy components when looping over them
20:37:29Araqit's all about optimization though, otherwise you're better off with plain old seqs of objects
20:37:30*ptdel joined #nim
20:37:40FromDiscord<Elegant Beef> Question didnt i see a method to iterate over a range lilke [x..y] or something?
20:38:27jakob0094well, this uses plain old seqs of objects, the only interesting thing is the forEachEntity macro
20:38:50*narimiran quit (Ping timeout: 240 seconds)
20:40:15jakob0094involves casting pointers to vars though, which is probably horrible
20:40:23FromDiscord<clyybber> @Elegant Beef literally x..y
20:40:32FromDiscord<clyybber> for bruh in x..y:
20:40:46FromDiscord<Elegant Beef> i thought it was supposed to be in []
20:40:52FromDiscord<Elegant Beef> so i was like this is just slicing nothing
20:42:05FromDiscord<clyybber> nah
20:42:16FromDiscord<clyybber> .. is the range constructor
20:42:22FromDiscord<clyybber> or however you call it
20:42:31FromDiscord<clyybber> @Elegant Beef you can do
20:42:49FromDiscord<clyybber> for e in someseq[x..y]:
20:43:05FromDiscord<clyybber> because you can index strings/seqs/arrays using slices/ranges
20:43:25FromDiscord<Elegant Beef> yea i got that
20:43:53FromDiscord<exelotl> wow I didn't know you could do that
20:44:50disruptekyes you did.
20:44:58FromDiscord<Recruit_main_70007> how can i make all my 4 space width tabs 2 spaced in vscode?
20:45:17FromDiscord<Elegant Beef> bottom right
20:45:17FromDiscord<Elegant Beef> https://cdn.discordapp.com/attachments/371759389889003532/677978691745349671/unknown.png
20:45:34FromDiscord<Elegant Beef> Also how do uploaded images work for IRC, they dont do they?
20:45:52disruptekespecially not the ones discord produces.
20:45:57FromDiscord<Elegant Beef> Or does it send the discord upload url
20:46:12FromDiscord<Elegant Beef> *it should send the discord upload url* πŸ˜„
20:46:21Yardanicoit does that
20:46:33FromDiscord<Elegant Beef> Why would disruptek lie to me
20:46:40disruptekit just doesn't get rendered usefully in the browser.
20:48:07FromDiscord<clyybber> crtl + is my spirit ~~animal~~ key combination
20:49:35disruptekthat used to be spelled animal^H^H^H^H^H^Hkey
20:51:45FromGitter<Varriount> Elegant Beef: Didn't you know? disruptek is the embodiment of helpful chaos. It's all there in the name.
20:52:01disruptekthis, pretty much.
20:52:23disrupteki'm suffering from solitudesfitis today though.
20:52:26FromDiscord<Elegant Beef> Most of my comments about disruptek are insincere
20:52:32FromDiscord<Elegant Beef> I know why he'd lie to me
20:55:26*rockcavera quit (Remote host closed the connection)
20:59:17FromDiscord<Elegant Beef> God damn it, trying to keep this clean but i keep running into the needing to reference functions in a file that is importing this file
20:59:33FromDiscord<Elegant Beef> I have spent too much time in C#
20:59:36FromDiscord<Elegant Beef> πŸ˜„
21:00:02FromDiscord<oz> There are worst languages.
21:00:16FromDiscord<Elegant Beef> I mean i like C# so yea
21:00:23FromDiscord<Elegant Beef> But im using imports like namespaces
21:00:26disruptekthat ndepend demo was impressive.
21:00:48disruptekshows some value of such semantics...
21:01:57FromDiscord<Elegant Beef> I guess in nim 1 object per file doesnt work
21:02:47ZevvThat's a recurring pain that will never go away. Every Nim project I do I run into that problem
21:02:52Zevvhow the hell do I split my files
21:03:00disruptekmaybe it's because i find software engineering so lame, but i'm always more interested in improving the sophistication of the craft than i am in anything else.
21:03:16ZevvYou are soooo meta
21:03:16disrupteki never have this problem.
21:03:32disruptekto me it's just layers all the way down.
21:03:34Zevvno because your files are all empty, right?
21:03:56disruptekyou know that was an early winner of one of those programming contests.
21:04:20Zevvthe quine?
21:04:42FromDiscord<Elegant Beef> I dont know if it's even possible but i feel like nim needs to be able to use some "super import" which allows the use of exposed bodies in a file without causing a recursive dependancy
21:05:05disruptekwait, what?
21:05:08FromDiscord<Elegant Beef> or i can just learn to use nim
21:05:32disrupteki heard exposed bodies.
21:05:41disrupteki always get in trouble for bringing up porn in here.
21:05:50disruptekso, i'm glad this time it was you, first.
21:06:11FromDiscord<Elegant Beef> I have ecs,entity, and component. Entity on creation wants to call a function in the ecs file, but ecs depends on Entity, so it's a wacky spaghetti of imports
21:06:21disruptekanyway, why can't we talk about porn?
21:06:29disrupteki feel like you are all fairly tasteful.
21:06:34disrupteklet me hear your tastes.
21:06:36Araqstop it
21:06:51Araqthis is where I have to draw the line
21:07:00*disruptek 😒
21:07:34FromDiscord<Elegant Beef> disruptek to be even more disrupting you were supposed to say "Why would you insult beef's logic like that"
21:07:34disruptekyou are allowed to import as many files as you want.
21:07:41disruptekjust import your types.
21:07:48FromDiscord<Elegant Beef>
21:07:48FromDiscord<Elegant Beef> https://cdn.discordapp.com/attachments/371759389889003532/677984359017611324/unknown.png
21:08:09disrupteki should say, /just/ import your types.
21:08:30FromDiscord<Elegant Beef> Huh
21:08:34FromDiscord<Elegant Beef> There are functions also
21:08:37ZevvRight - often I end up with a lot of all of the types in one file
21:08:46FromDiscord<Elegant Beef> Yea which i dislike coming from C#
21:08:50FromDiscord<Elegant Beef> 1 class per file is the norm
21:08:52disruptekthere are functions, also?
21:08:55Zevvbut mutual recursion in two files is also tricky
21:09:08FromDiscord<Elegant Beef> well there is the constructor
21:09:18FromDiscord<Elegant Beef> and will be some base functions for entities
21:09:43FromDiscord<Elegant Beef> I mean i could put them in the ecs file, but that's weird for my brain
21:09:44disruptekwell, maybe they can go there. maybe they cannot. obviously, if they depend on ecs, they cannot.
21:09:59disruptekyes, this is a weird-brain problem.
21:10:13disruptekpicture chains, venn diagrams, whatever works.
21:10:24FromDiscord<Elegant Beef> I know i *can* drop them in ECS but since they're functions on entity
21:10:30FromDiscord<Elegant Beef> it makes no sense to put them there
21:10:56FromDiscord<Elegant Beef> Well just to progress im going to put them there and cry
21:10:59FromDiscord<Elegant Beef> Oh and i cry!
21:11:15disruptekthere's no such thing as "functions on entity".
21:11:38FromDiscord<Elegant Beef> I mean it's a constructor
21:11:43FromDiscord<Elegant Beef> It creates an entity
21:11:50FromDiscord<Elegant Beef> So it makes sense to be in the in the entity class
21:12:01disruptekoop is not a thing.
21:12:12disruptekwhen you see oop, i want you to think `oops`.
21:12:15disruptekya dig?
21:12:20FromDiscord<Elegant Beef> lol
21:12:23FromDiscord<Elegant Beef> OOP isnt a thing
21:12:24FromDiscord<Elegant Beef> Nice
21:12:30FromDiscord<Elegant Beef> Then why am i even making objects
21:12:32FromDiscord<Elegant Beef> πŸ˜›
21:12:38disrupteki do not know.
21:13:14Zevv'object' is a bit of a misnomer
21:13:19disrupteki no longer believe that oop is even a useful mental model.
21:13:28disruptektoo limiting.
21:13:29FromDiscord<Elegant Beef> I know they're techincally structs in this case
21:15:57disruptekthe way i want to write software:
21:16:09disrupteki want to have an over-the-shoulder view of my program.
21:16:11FromDiscord<oz> But calling them strucs would scare oop programmers away. :)
21:16:29FromDiscord<oz> But calling them structs would scare oop programmers away. :)
21:16:33disrupteki want to make a machine to do the work. then i want knobs and dials and buttons on it.
21:17:09disruptekinstead of telling the computer what to do, i want to tell it how to do what i want.
21:20:18FromDiscord<Elegant Beef> Why even have programmers
21:20:23FromDiscord<Elegant Beef> Just have the computer do everything
21:20:27FromDiscord<Elegant Beef> problem solve
21:20:32FromDiscord<Elegant Beef> ML a nim writer
21:20:35disruptekyeah, that sounds good.
21:21:10FromDiscord<treeform> Was `dumpHeapInstances` function removed? How to get it back?
21:21:28disruptekcrap, i just linked this but i forget the footnote.
21:21:41disrupteki think you have the name wrong. also, remember you need a define set.
21:22:04disbot9dumpNumberOfInstances: 11add a -d:nimTypeNames at compilation and call `dumpNumberOfInstances()` at runtime. -- 7disruptek
21:23:25disruptekwhat i'm saying is, i need to build a little distance between me and the task my code is performing.
21:23:49disrupteki need to create a separation. in that space i will put some basic introspection, logging, monitoring, i/o, and so on.
21:24:12disruptekthat's where we'll lay in the cloud stuff, etc. this is our "kernel".
21:24:18FromDiscord<Elegant Beef> how does one override a parent's procedure?
21:24:21FromDiscord<treeform> disruptek thanks! Is this new?
21:24:30disrupteknot as far as i know.
21:25:06disrupteki do it in golden and my grok tools but i guess i haven't tested it in awhile.
21:25:27disruptekbeef: what's a parent?
21:25:34FromDiscord<treeform> I guess I had --d:nimTypeNames in my nim file because -d:release used to remove stack traces...
21:25:45FromDiscord<treeform> but when I started a new project it was not there
21:25:57FromDiscord<Elegant Beef> a parent object
21:25:58disruptekaha, yeah; that'll do it.
21:26:12FromDiscord<Elegant Beef> or do variables only get inherited
21:26:13disruptekparent type? inheritance?
21:26:17FromDiscord<Elegant Beef> Yes
21:26:28FromDiscord<Elegant Beef> I assume only variables are inherited
21:26:55disruptekmethods are used for that, but this is really an area where you should watch your step.
21:26:58disruptekassume nothing.
21:27:15disruptekand constantly ask yourself if you wouldn't be better served by a case object.
21:27:26FromDiscord<Elegant Beef> case object?
21:27:33disruptekvariant type?
21:27:39FromDiscord<Elegant Beef> uhh
21:27:43FromDiscord<Elegant Beef> yes that's english
21:27:52FromDiscord<treeform> disruptek, oh and I do want dumpHeapInstances, that's what dumpNumberOfInstances calls.
21:28:10disruptekooh, i didn't even know it was a thing, i think.
21:28:31disruptekor maybe i decided i wanted whatever the other one does. i dunno.
21:28:32Zevvdoes that still exist with --gc:arc?
21:28:44FromDiscord<treeform> I don't think so.
21:28:47disrupteki don't know.
21:29:16Zevvwe better first fix all the leaks before we add that back in, otherwise people will complain
21:29:19Zevvabout leaks
21:29:25FromGitter<kaushalmodi> I am on latest devel.. all of a sudden `{.exportc.}` has stopped working! I compile the .so using `nim c --out:libdpi_64.so --app:lib ..`, and that used to be read fine by SystemVerilog. But now it fails complaining that the symbol that it expected to be exposed in the .so is no longer found.
21:29:31FromGitter<kaushalmodi> that's a serious regression
21:29:42FromDiscord<treeform> I wrote a function dumpHeapDiff ... I call it every frame so that it can let me know which objects grew or shrank between frames.
21:29:57FromDiscord<treeform> How would I debug memory use with arc hmm...
21:30:00nisstyrewhat are these headers in the nim binary for? "0000000000000000 l df *ABS* 0000000000000000 stdlib_osproc.nim.c"
21:30:13nisstyreI've never seen "*ABS*" before
21:30:20disruptekkaushalmodi: did it regress from devel to devel?
21:30:25nisstyredon't see it here either, is it custom? https://github.com/corkami/pics/blob/master/binary/elf101/elf101.pdf
21:30:38nisstyreIs it for debugging purposes or something?
21:30:41FromGitter<kaushalmodi> that last downloaded stable I have handy is 1.0.2, and it works fine using that
21:31:11FromGitter<kaushalmodi> disruptek: Yes, it regressed from devel to devel
21:31:19disruptekno, i mean, was it working in a recent devel and now it's broken in recent devel?
21:31:41*solitudesf- joined #nim
21:31:51disruptekor, what's the latest you know it to work?
21:31:59FromGitter<kaushalmodi> may be it broke in last month..
21:32:07FromGitter<kaushalmodi> a dumb search reveals this: https://github.com/nim-lang/Nim/pulls?q=is%3Apr+is%3Aclosed+exportc+sort%3Aupdated-desc
21:32:19FromGitter<kaushalmodi> so looks like few PR's related to exportc happened
21:32:29*JustASlacker quit (Ping timeout: 272 seconds)
21:32:39FromDiscord<treeform> hmm, my next problem Nim says I am using 5MB of memory but Activity Monitor (Mac's default task manager) says I use 38mb! How to figure out where the 33MB come from!
21:32:41FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/677990623671877682/unknown.png
21:32:44nisstyreI guess the correct term is "Section" not "header"
21:32:47FromGitter<kaushalmodi> this looks like the culprit: https://github.com/nim-lang/Nim/pull/13199
21:32:50disbotβž₯ 6compiler/ccgtypes: hide exportc proc unless it has dynlib ; snippet at 12https://play.nim-lang.org/#ix=2bJn
21:32:57disruptekyour buddy timothee has been busy.
21:33:42disruptekhow did you figure that out so fast?
21:33:59*solitudesf quit (Ping timeout: 246 seconds)
21:34:15disruptekhmm, this was pretty well-reasoned, so we need to figure this out.
21:34:24FromGitter<kaushalmodi> this is the simplest example: http://ix.io/2bJo/nim
21:34:30disruptekyeah; i remember this.
21:34:41FromGitter<kaushalmodi> the C side of SystemVerilog now fails to "see" that exported `hello` proc
21:34:58*letto quit (Quit: Konversation terminated!)
21:35:15FromGitter<kaushalmodi> opening an issue .. but don't know how to prove that this is broken
21:35:24FromGitter<kaushalmodi> as it needs someone to have a SystemVerilog compiler
21:35:28FromGitter<kaushalmodi> still opening it in any case
21:35:43disruptekthis is a really tricky question.
21:36:37Zevvtreeform: Nims default allocator gets memory in large chunks from the os. Not sure how large the default is, but that might be your issue
21:36:42disrupteki mean, you can prove it by trying to link against it.
21:36:58disruptekif you can link it, great. we're exporting it.
21:37:21disruptekyour use-case could demand a toggle for this elision, though.
21:37:56FromGitter<kaushalmodi> disruptek: I have never written in C (so "linking" it will take me some time to figure out)
21:38:52disrupteki haven't done it, but i expect you can just gcc x.c -o x othernim.o
21:39:37FromGitter<kaushalmodi> let me look at `nm` outputs between the two .so's
21:39:57disruptekah, good idea.
21:41:55FromGitter<kaushalmodi> woot!
21:41:58FromGitter<kaushalmodi> I have proof
21:42:05FromGitter<kaushalmodi> (https://files.gitter.im/nim-lang/Nim/MFAR/image.png)
21:42:35disruptekwow, that's a great regression to fix.
21:42:45disrupteknice job.
21:45:27disruptekmaybe we can do introspection by just wrapping types with a macro.
21:46:26disruptekthe macro will bulk up objects and produce other types automatically.
21:46:58disruptekthe we just have an operator to read this data out with the "naked" type used for dispatch.
21:47:46disrupteklike -> or something.
21:49:06disruptekfoo->name, foo->["somename"]
21:49:28*jakob0094 quit (Quit: Leaving)
21:50:00disruptekit's not crazy, right?
21:52:38*mal`` quit (Quit: Leaving)
21:54:04FromGitter<Varriount> @kaushalmodi Yikes, that's a bad bug
21:56:48FromDiscord<treeform> Zevv, I think I am seeing the OS chunks in the nim's memory output. My hunch is that this is memory from loaded dlls... but I don't know how to see that.
21:57:26FromDiscord<treeform> I think am seeing chunks nim gets from the OS... but what is this other memory that os reports?
21:58:43FromDiscord<Elegant Beef> <https://github.com/beef331/nimcs> here it's hideous
21:58:44FromDiscord<Elegant Beef> πŸ˜„
21:58:52FromDiscord<Elegant Beef> Was fun to write though
21:58:59disruptekthe memory doesn't go back to the os, necessarily.
21:59:05FromDiscord<Elegant Beef> And certainly should use something else to make components
21:59:15FromDiscord<Elegant Beef> macros most likely
21:59:41FromDiscord<treeform> disruptek, I am not freeing any memory. I start my GUI app, nim says I use 5MB, while MacOS says I use 38MB...
22:00:03Araqprobably loaded libs
22:00:04FromDiscord<Elegant Beef> 99% certain it'd break on removal of items cause sequences are weird
22:00:18disruptekyeah. i expect there's a ton.
22:01:24disruptek!repo nimcs
22:01:26disbot12https://github.com/beef331/nimcs -- 9nimcs: 11Nim ECS  15 0⭐ 0🍴
22:01:38FromDiscord<Elegant Beef> But why
22:01:40disrupteknow we know what to recommend. πŸ‘
22:01:55FromDiscord<Elegant Beef> Did you even look at the code?
22:02:03FromDiscord<Elegant Beef> It's 100% certainly going to explode
22:02:15FromDiscord<Elegant Beef> Remove 1 item and it dies
22:02:26disruptekremoval is a 2.0 feature.
22:02:45FromDiscord<Elegant Beef> there are no dynamically sized arrays that dont shrink on removal is there
22:02:53disruptekof course.
22:03:04disrupteklinked lists are a thing.
22:03:14disruptekokay, not an array, technically.
22:03:26FromDiscord<treeform> Araq, disruptek you are probably right I found this:
22:03:27FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/677998365073735710/unknown.png
22:03:38FromDiscord<treeform> does not give me mem break out though
22:03:51FromDiscord<Elegant Beef> I mean i just need the sequence functionality without it reducing the length on removal, so when i add an element it increases to x size then stays there
22:03:56FromDiscord<Elegant Beef> so the indicies dont get moved around
22:04:08disruptek38mb for a gui app strikes me as remarkably lightweight.
22:04:18FromDiscord<treeform> I want to be able to say look electron uses 1GB while fidget uses only 5M to do the same thing...
22:04:23disruptekif you think that's a lot, i'm hugely impressed by your fidget.
22:04:30FromDiscord<treeform> I want it to use less!
22:04:46FromDiscord<treeform> I stripped down electron app is only like 80MB
22:04:55disruptekokay, but you cannot treeshake the libs that you don't build.
22:04:57FromDiscord<treeform> 38 is not that much better then 80
22:05:12FromDiscord<Elegant Beef> what's a sharedlist?
22:05:16Araqwell it's a factor of 2
22:05:52disruptekhonestly, i'm staggered that electron could be only 80mb.
22:05:59disruptekthat's blowing my mind right now.
22:06:06Araqand more than the bloat I care about the control aspect. if things go wrong, you know you can fix it as it's not built on top of millions of lines of C++ and JS code
22:06:33Araqand yeah the 80MB for electron sound wrong to me too
22:07:20FromDiscord<treeform> http://roryok.com/blog/2017/08/electron-memory-usage-compared-to-other-cross-platform-frameworks/
22:07:31FromDiscord<treeform> This guy had it at 68.9MB
22:07:35FromDiscord<treeform> I had it at 80MB
22:07:39Araqanyhow, maybe it's the textures you keep around for Unicode rendering
22:07:43FromDiscord<treeform> electron is not as bloated as we all think...
22:07:48FromDiscord<treeform> It makes it harder to win!
22:08:14disruptekc'mon, 20mb for ie11?
22:08:19FromDiscord<treeform> Araq, I only render the Unicode when I need too.
22:08:45FromDiscord<treeform> In this app the texture atlas is empty.
22:08:46leorize[m]@kaushalmodi: use {.dynlib.} if you want a symbol to be exported
22:08:59FromDiscord<treeform> And its also counted in the 5MB that nim reports...
22:09:11disrupteki have a hard time taking someone seriously who says their web browser is only consuming 20mb while rendering a page.
22:09:13FromDiscord<treeform> Nim thinks I only using 5MB
22:09:32FromDiscord<treeform> disruptek, rendering a page with a single <h1> Hello world on it
22:09:34disruptekmaybe i'm the idiot, though.
22:09:55FromDiscord<Elegant Beef> disruptek earlier you said import the type, how does one do that? Or was that you compressing your cheak with your tongue?
22:10:02FromDiscord<Elegant Beef> cheek*
22:10:29disruptekpick the smallest possible set of units. put them in a file.
22:10:37disruptekcreate a new file that imports the first.
22:10:43disruptekgoto 1.
22:11:10FromDiscord<treeform> disruptek, IE might be using some OS features not counted in the thing. I never used IE so I don't know how bloated it is. IE11 was a full rewrite though.
22:11:23FromDiscord<treeform> Mabye IE 11 did not have time to accumulate cruft.
22:11:38disrupteki mean, you might be right.
22:11:53disrupteki could be showing my age.
22:12:08*mal`` joined #nim
22:13:53AraqI have 23 tabs open and 40 Chrome processes
22:14:05Araqtaking up 3GB
22:14:31Araqmaybe <h1>Hello world</h1> isn't the best benchmark for its overhead
22:14:38FromDiscord<treeform> But the tabs have Images and text.
22:14:50FromDiscord<treeform> Images are huge when unpacked for the GPU to use.
22:15:09disrupteki run a -march=native build of chromium and all its dependencies, from scratch, according to my hardware and available software.
22:15:35FromDiscord<treeform> I don't know if 23 Fidget programs full of images and text could beat that?
22:15:47disruptekit's wickedly fast and still takes a few gigs of memory.
22:15:50FromGitter<kaushalmodi> leorize[m]: I'll need to change a lot of code for that
22:15:56Araq3 tabs of my VSCode take up 300MB
22:16:02FromGitter<kaushalmodi> so I need to replace `{.exportc.}` with `{.dynlib.}`?
22:16:19FromGitter<kaushalmodi> or `{.exportc.}` with `{.exportc, dynlib.}`?
22:16:32Araqthe latter if you build an .so
22:16:41FromGitter<kaushalmodi> ok.. trying that out
22:17:04disruptekjust shared memory is 150meg for chromium.
22:17:14leorize[m]@kaushalmodi: perks is that it will work on windows
22:17:40FromGitter<kaushalmodi> leorize: Thanks! That worked!
22:17:51leorize[m]no, exportc and dynlib
22:17:52FromGitter<kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e471c90d56ddb68a4a6befe]
22:18:39leorize[m]yea, the no dynlib but things are exported was a bug
22:19:00leorize[m]the spec said you need dynlib, but didn't enforce that on *nix
22:19:33leorize[m]though probably I should PR in a changelog too, given how users might not notice this
22:19:53FromGitter<kaushalmodi> > though probably I should PR in a changelog too ⏎ ⏎ +1 ⏎ ⏎ I was going to suggest that [https://gitter.im/nim-lang/Nim?at=5e471d0925f1d250fed8f021]
22:20:01FromGitter<kaushalmodi> it will be a pretty serious breaking change
22:20:16FromGitter<kaushalmodi> It should be in bold or something
22:20:41Araqand leorize[m] is right, now it works as it was supposed to work :-)
22:22:56*letto joined #nim
22:23:03FromDiscord<treeform> I think I can lower the memory use by not using openGL. But using platform native CPU only drawing commands.
22:23:15FromDiscord<Elegant Beef> hey i now have adding and removing
22:23:21FromDiscord<Elegant Beef> πŸ˜„
22:24:05FromDiscord<Elegant Beef> Well 0 clue how performant this is
22:24:33Araqtreeform: fwiw my NimEdit had comparable overhead with "Aporia" (a GTK application) too
22:24:45FromGitter<kaushalmodi> Araq, leorize[m]: Thanks. Thankfully this change is backward compatible too
22:24:46Araqaround 20MB
22:25:02FromGitter<kaushalmodi> now I need to `sed` few dozen files ..
22:25:04Araqand I blamed SDL2
22:25:17FromDiscord<Elegant Beef> apparently writing roughly 4,000,000 strings to the console takes some time
22:25:22Araqkaushalmodi: use nimgrep instead
22:25:50FromDiscord<Elegant Beef> Well with 400k it takes a second roughly per tick
22:25:53leorize[m]@Elegant Beef: that's pretty much expected
22:26:03FromDiscord<Elegant Beef> That was more of a joke then anything
22:26:22FromGitter<kaushalmodi> Araq: I never used nimgrep because I am comfortable with sed and rg
22:26:23FromDiscord<Elegant Beef> Not like i have a very viable test of this ecs considering i lack something to run it in
22:26:30FromGitter<kaushalmodi> will have a look at that soon
22:29:16FromDiscord<Elegant Beef> So for the components, i think using a macro to make them makes more sense but idk
22:32:00disruptekprobably, yeah.
22:32:05*jjido joined #nim
22:33:07FromDiscord<treeform> Araq, wow GTK + SDL + your app is only 20MB?
22:33:15FromGitter<kaushalmodi> leorize: So when would one use just `.exportc.`?
22:33:42FromGitter<kaushalmodi> If the symbol doesn't get exported when just that pragma is used, when what's the point?
22:33:50FromGitter<kaushalmodi> s/when/then
22:34:27leorize[m]I do know an use case for the compiler codegen
22:34:56FromGitter<kaushalmodi> ok (that's out of my reach then :) )
22:35:08leorize[m]compiler procs are exportc-ed then called via codegen by inlining the exported name
22:35:52FromDiscord<treeform> Araq, Nimx is also 35mb...
22:36:03FromDiscord<treeform> I need to figure out how to get it to only 20mb.
22:36:10FromDiscord<treeform> get my thing*
22:36:27*solitudesf- quit (Ping timeout: 272 seconds)
22:36:55disruptektreeform: how does this 35mb compare to other nim guis?
22:39:43FromGitter<kaushalmodi> leorize[m]: I couldn't help think.. shouldn't exportc implicitly do dynlib too?
22:40:02FromGitter<kaushalmodi> for the few cases where that should not happen, that's where you require a second pragma
22:40:37FromGitter<kaushalmodi> now I have a huge diff of 200+ changes that changes `{.exportc.}` to `{.exportc, dynlib.}`
22:40:53disruptekargh. πŸ™
22:43:06leorize[m]@kaushalmodi: that doesn't sound too bad, though adding yet another pragma might not be too appealing
22:44:34FromDiscord<clyybber> disruptek: (lol)[https://github.com/ulfjack/ryu/blob/master/third_party/double-conversion/test/cctest/gay-shortest-single.h]
22:46:10FromGitter<kaushalmodi> leorize[m]: from my perspective, it looks like: ⏎ ⏎ 1) most of exportc's use requires dynlib too, so may be exportc should automatically behave as if dynlib was used ⏎ 2) dynlib can then be deprecated ⏎ 3) a new pragma.. `.local.`? would then export the symbols locally instead of globally [https://gitter.im/nim-lang/Nim?at=5e47233246e99d431f790227]
22:46:34FromGitter<kaushalmodi> essentially default exportc to do global exports as before and introduce a new pragma to specify local exports
22:46:44disruptekwhat am i looking at?
22:46:56*marmotini_ quit (Remote host closed the connection)
22:47:34disrupteka crappy c header?
22:47:56FromDiscord<clyybber> a funny file name
22:48:04FromDiscord<clyybber> at least when you are 10-yo
22:48:26disruptekgay is the author of another algo.
22:48:38disruptekisn't he?
22:48:47FromDiscord<clyybber> yeah, think so
22:48:54disruptekyou think he's gay?
22:49:41FromGitter<kaushalmodi> leorize[m]: I need to sign off, but we can continue our discussion on https://github.com/nim-lang/Nim/issues/13416#issuecomment-586505903
22:49:44disbotβž₯ 3[devel regression] {.exportc.} tagged procs no longer export to compiled .so objects ; snippet at 12https://play.nim-lang.org/#ix=2bJM
22:53:12*chemist69 quit (Ping timeout: 260 seconds)
22:54:06*chemist69 joined #nim
22:54:12FromDiscord<clyybber> disruptek: Fo ssure
22:54:38FromDiscord<clyybber> disruptek: Btw, I'm porting ryus table generation code to nim
22:54:44FromDiscord<clyybber> so we can generate the tables at compile time
22:55:19disruptekthis is the generic version, right?
22:55:22Araqbtw my concern for code size was serious
22:55:33FromDiscord<clyybber> disruptek: Nope
22:55:51FromDiscord<clyybber> Araq: Ok, I'm still doing this. Maybe I get it managable
22:55:52Araqwould be a shame to add 4kb for $myfloat
22:55:56FromDiscord<clyybber> Yeah
22:55:58FromDiscord<clyybber> I agree
22:56:42disruptekthat's why the one that goes in has to be the nim one.
22:56:57FromDiscord<clyybber> hmm
22:57:16FromDiscord<clyybber> maybe its best we port a non-microoptimized to hell algorithm
22:57:22FromDiscord<clyybber> that accomplishes the same task
22:57:29disruptekthat's what leorize is doing.
22:57:37FromDiscord<clyybber> no?
22:57:43disruptekafaik, yes.
22:57:43FromDiscord<clyybber> or is he
22:57:52disrupteki've tried to explain this.
22:57:55FromDiscord<clyybber> I thought he was trying to reimplement ryu from scratch
22:58:03disruptekhe is.
22:58:23disruptekhe's trying to create the idiomatic implementation.
22:58:42FromDiscord<clyybber> glhd :p
22:58:48FromDiscord<clyybber> *glhf
22:58:56FromDiscord<Elegant Beef> good luck have dumb is nicer
22:59:05disruptekwell; because it has to slot into the compiler.
22:59:15FromDiscord<clyybber> get low high dumb
22:59:41FromDiscord<clyybber> disruptek: I know. I'm working on nimifying it too
22:59:52FromDiscord<clyybber> And I can remove the tables in this version too
23:00:01FromDiscord<clyybber> and replace them by runtime calculations
23:00:06disruptekokay. sorry if i gave you the wrong idea.
23:00:09FromDiscord<clyybber> its still gonna be faster than what we have I think
23:00:24FromDiscord<clyybber> disruptek: ? What wrong idea?
23:00:51disrupteki mean about what we were trying to do with the ports.
23:00:56FromDiscord<clyybber> Ah sure
23:01:11FromDiscord<clyybber> I think its just easier working from messy but working to clean and working
23:01:26FromDiscord<clyybber> I'm a cleanup guy
23:01:32FromDiscord<clyybber> it makes me feel all cozy
23:01:43FromDiscord<clyybber> maybe I should be janitor
23:01:49FromDiscord<Elegant Beef> You be the janitor and ill be the guy that dumps the cola on the ground
23:02:01FromDiscord<clyybber> haha
23:02:02FromDiscord<Elegant Beef> My shitty ECS for instance πŸ˜„
23:02:12FromDiscord<Elegant Beef> Go add macros and make it clean
23:02:14disrupteki think that just means you optimize the expression of an algorithm that makes less sense than a reformation of same with all-new semantics, etc.
23:02:19FromDiscord<Elegant Beef> Ill be here with more cola
23:03:14*marmotini_ joined #nim
23:03:15FromDiscord<clyybber> disruptek: Why do you think we can beat ulfjack?
23:03:44disruptekthat's not the point.
23:04:01disruptekthe point is an idiomatic impl that meets the needs of the compiler and runtime.
23:04:11FromDiscord<clyybber> yeah
23:04:24disruptekno one wants to have to touch this code for a long time.
23:04:38FromDiscord<clyybber> its not like you can't arrive at an idiomatic implementation with my approach
23:04:42disruptekso let's make it so dead stupid nim that it never needs fixing.
23:04:48FromDiscord<clyybber> in fact that *is* what I am trying to do
23:05:18disruptekokay; but you have to admit that you're starting from the wrong end of the field.
23:05:27FromDiscord<clyybber> no
23:05:40FromDiscord<clyybber> I'll show you :p
23:05:52disruptekyou're on.
23:06:02FromDiscord<clyybber> better than hacking at it just to overfit to the tests
23:06:31*zickzackv quit (Ping timeout: 260 seconds)
23:06:37FromDiscord<clyybber> its also more fun
23:06:46FromDiscord<clyybber> detecting complicated patterns
23:06:50FromDiscord<clyybber> and simplifying them
23:07:04disruptekyes, those patterns may not be a means to the idiomatic ends.
23:07:15disruptekyou could be optimizing a quirk of the c impl that doesn't exist in nim.
23:07:27disruptekso you're wasting your time, or misvaluing it at least.
23:07:39FromDiscord<clyybber> we'll see
23:07:51disruptekin any event, you're thinking about the problem with the wrong abstractions.
23:08:00disruptekie. the ones we care about are the nim ones.
23:08:05disruptekbut you're mired in c.
23:08:12*marmotini_ quit (Ping timeout: 265 seconds)
23:08:35FromDiscord<clyybber> C vs Nim semantics don't change a single thing about maths
23:08:57disruptekno, but the point is not math.
23:09:06FromDiscord<clyybber> but thats whats behind the curtains
23:09:08*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:09:11disruptekthe point is to paint a picture using the same palette.
23:09:17FromDiscord<clyybber> everything else is just fluff
23:09:56FromDiscord<clyybber> disruptek: No you change the palette
23:10:09FromDiscord<clyybber> then you notice with the new palette some faces are now the same color
23:10:11disrupteki hate that.
23:10:13FromDiscord<clyybber> then you join them
23:10:18FromDiscord<clyybber> in the end
23:10:36FromDiscord<clyybber> you are left with the bare minimum differently colored faces required to get the idea across
23:11:23disruptekyou're assuming that their solution is part of the same graph of ours.
23:11:30FromDiscord<clyybber> well
23:11:34FromDiscord<clyybber> they wrote a paper
23:11:36disruptekthat's just immediately, obviously, wrong.
23:11:38FromDiscord<clyybber> they proved it correct
23:11:55disruptekyes, but how we arrive at the same "correct" result is our problem.
23:12:16FromDiscord<clyybber> they proved the implementation correct
23:12:18disruptekwe might benefit from writing more nim as if it's an advertisement for the language.
23:12:19FromDiscord<clyybber> not the specification
23:13:16disruptekit doesn't really matter because for the purposes of this argument, we're assuming that we're implementing whatever contract their implementation suggests.
23:13:38FromDiscord<clyybber> how do you verify that contract?
23:13:40FromDiscord<clyybber> through tests
23:14:01disruptekso what?
23:14:03FromDiscord<clyybber> and I do not want to change the underlying math
23:14:51disrupteklook, when you practice animal taxidermy and the animals are still alive and sway their legs and shit...
23:15:05FromDiscord<clyybber> ok so your point
23:15:07FromDiscord<clyybber> is
23:15:12FromDiscord<clyybber> start with a broken implementation
23:15:14FromDiscord<clyybber> lol
23:15:14disruptekyou learn pretty quick that it helps to sew the leg on wear a previous leg was already pre-existing.
23:15:31disruptekthese bits mate up nice.
23:15:44FromDiscord<clyybber> eh
23:15:47disruptekwe need hot nim-on-nim action here.
23:16:15FromDiscord<clyybber> we need nim based on existing working code and maths
23:16:18FromDiscord<clyybber> and algorithms
23:16:24FromDiscord<clyybber> which are proven to be correct
23:16:26disruptekwhich just means passing tests.
23:16:30FromDiscord<clyybber> not nim based on overfitting tests
23:16:41FromDiscord<clyybber> disruptek: No, because the tests don't test everything
23:16:56FromDiscord<clyybber> also I think its easier to arrive at the desired outcome by going top-down
23:17:00FromDiscord<clyybber> rather than bottom-up
23:17:02disrupteki think i can take my chances on this one.
23:17:37disruptekyou forget that i've seen the code, maybe.
23:28:38leorize[m]well it's certainly possible to create idiomatic ryu from c-ryu
23:28:46*sekao joined #nim
23:29:10leorize[m]my nim-ryu is a sort of personal research project so I could grasp the inner workings of floats better
23:29:39leorize[m]a nice looking and documented implementation is just a side effect
23:36:38disrupteki think i finally understand convertors.
23:36:46*marmotini_ joined #nim
23:37:06disruptekthey give you a way to grandfather an interface used by an earlier type.
23:37:26disruptekso you can evolve your types without losing functionality.
23:39:26*abm joined #nim
23:43:16disruptekis type versioning a good idea?
23:43:23*sekao quit (Remote host closed the connection)
23:52:33Araqit has "type" in it, so yeah
23:53:16FromGitter<gogolxdong> How to make nlvm targeting x86?
23:54:49Araqno idea
23:57:33dom96Araq, have you ever looked into any emscripten segfaults?