00:00:00 | * | luis__ joined #nim |
00:00:01 | FromDiscord | <treeform> why stop at int128, why not int256? |
00:11:47 | * | ptdel quit (Ping timeout: 240 seconds) |
00:17:39 | FromDiscord | <Elegant Beef> why stop at int256, make int 1024 |
00:18:56 | FromDiscord | <Elegant Beef> or alternatively just wrap the big int library |
00:19:28 | FromDiscord | <Elegant Beef> i mean libgmp |
00:20:10 | FromDiscord | <Elegant Beef> 2^37bits |
00:20:14 | FromDiscord | <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:47 | FromDiscord | <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:07 | FromDiscord | <Elegant Beef> Easy make it sci notiation with a param being the leading decimas |
01:08:12 | FromDiscord | <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:18 | FromDiscord | <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:19 | FromDiscord | <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:23 | FromDiscord | <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:55 | leorize | use devel for csize_t |
01:52:09 | FromDiscord | <Elegant Beef> ah |
01:52:10 | FromDiscord | <Elegant Beef> ok |
01:53:13 | * | dadada_ quit (Ping timeout: 272 seconds) |
01:53:35 | * | dadada_ joined #nim |
01:54:16 | FromDiscord | <clyybber> @Elegant Beef Ah damnit. I switched it to csize_t because I was getting sick of deprecation warnings |
01:54:25 | FromDiscord | <clyybber> and Im always on devel |
01:54:45 | FromDiscord | <clyybber> You can also just use the previous commit |
01:55:01 | FromDiscord | <Elegant Beef> or i can just use #head π |
01:55:20 | FromDiscord | <clyybber> Go ahead :D |
01:55:53 | FromDiscord | <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:22 | FromDiscord | <clyybber> sometuple = tuple[some: sometype] |
01:56:38 | FromDiscord | <Elegant Beef> yea i got it |
01:56:41 | FromDiscord | <Elegant Beef> I just had to check the docs |
01:56:42 | FromDiscord | <clyybber> You can also use the object syntax I think |
01:56:46 | FromDiscord | <clyybber> Aight |
01:56:57 | FromDiscord | <clyybber> gotta get some sleep |
01:57:02 | FromDiscord | <clyybber> nite |
01:57:16 | FromDiscord | <Elegant Beef> Buh bye |
01:57:24 | FromDiscord | <Elegant Beef> Ill be sure to annoy you more |
01:59:55 | FromDiscord | <Elegant Beef> Is `cast[Type](val) the same as (Type)Val`? |
02:00:37 | * | dddddd quit (Remote host closed the connection) |
02:02:27 | FromDiscord | <clyybber> nah |
02:02:35 | FromDiscord | <clyybber> tho in some cases yeah |
02:02:49 | FromDiscord | <clyybber> basically cast will reinterpret the bitpattern |
02:02:54 | FromDiscord | <clyybber> c style cast |
02:03:10 | FromDiscord | <clyybber> and (Type)Val isnt really nims syntax |
02:03:16 | FromDiscord | <Elegant Beef> Ok so the other is more C# like and attempts to get the other object type |
02:03:17 | FromDiscord | <Elegant Beef> Ok so the other is more C# like and attempts to get the other object type? |
02:03:28 | FromDiscord | <clyybber> Type(Val) is what you want |
02:03:32 | FromDiscord | <Elegant Beef> I mean i tried it from my C# knowledge and it worked π |
02:03:37 | FromDiscord | <clyybber> or Val,Type |
02:03:45 | FromDiscord | <clyybber> or Val.Type |
02:03:55 | FromDiscord | <clyybber> haha yeah it works |
02:04:45 | FromDiscord | <clyybber> Anyways the second thing way in your example will convert |
02:04:59 | FromDiscord | <clyybber> like from uint to int its with range checks |
02:05:18 | FromDiscord | <clyybber> its the more high level safe way |
02:05:27 | FromDiscord | <clyybber> and you can overload it |
02:05:36 | FromDiscord | <Elegant Beef> yea im only using it on primitive types so when i get to more advanced objects we'll see |
02:05:53 | FromDiscord | <Elegant Beef> i know for ints you can specify the type using a single quote |
02:06:01 | FromDiscord | <clyybber> ye |
02:06:19 | FromDiscord | <clyybber> good night |
02:06:28 | FromDiscord | <Elegant Beef> is it truely this time π |
02:06:29 | FromDiscord | <Elegant Beef> Buh bye |
02:07:16 | FromDiscord | <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:19 | disruptek | clyybber: yep, i haven't even created a d2s.nim file. |
03:04:27 | * | gangstacat quit (Quit: Δis!) |
03:12:34 | FromDiscord | <4984> does nim have full UFCS or am i missing something? |
03:12:44 | disruptek | it does. |
03:13:12 | FromDiscord | <4984> enato |
03:13:14 | FromDiscord | <4984> nenato |
03:13:22 | disruptek | there's a corner case in templates, but everywhere that matters... |
03:13:48 | FromDiscord | <4984> ive wanted to learn nim for so long but gotten confused at syntax each time |
03:13:59 | disruptek | ah; don't sweat it. |
03:14:11 | disruptek | it's just a luxury. |
03:14:22 | FromDiscord | <4984> nim is a luxury? |
03:14:35 | disruptek | sure, but especially the syntax. |
03:14:57 | disruptek | i'd be happy if i had the same semantics with a shitty syntax. |
03:15:01 | disruptek | the syntax is just icing. |
03:15:51 | FromDiscord | <4984> the more of nim i learn the more it reminds me of other languages |
03:16:22 | FromDiscord | <4984> like at first i was like "oh its the crystal of python" |
03:16:49 | disruptek | right, that's the common comparison. |
03:16:53 | FromDiscord | <4984> now i actually need something to do |
03:17:05 | disruptek | the difference is, with nim you don't give anything up. |
03:17:24 | FromDiscord | <4984> crystal's gc is a mess |
03:17:29 | disruptek | it's lisp that's as raw and thermonuclear as c. |
03:18:04 | FromDiscord | <4984> i wish more languages would abandon libc |
03:18:21 | disruptek | it will happen when speed starts to matter again. |
03:18:59 | disruptek | the semantics of other languages will slow them down. they will need to shed weight. |
03:19:42 | FromDiscord | <4984> and in the end two stood, both with UFCS, good compilers, and sane templates |
03:19:53 | FromDiscord | <4984> i just find my nim code is a bit smaller |
03:21:37 | disruptek | i 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:49 | disruptek | unfair to say, i should say. |
03:22:17 | FromDiscord | <4984> you think it could be optimized much more? |
03:22:45 | disruptek | that'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:00 | disruptek | and that's why i'm here. π |
03:23:25 | FromDiscord | <4984> i can't really see GC's lasting too far ahead |
03:23:48 | * | jwm224 quit (Ping timeout: 248 seconds) |
03:23:59 | disruptek | i think we will get more of a containerized kernel. |
03:24:49 | FromDiscord | <4984> whatever we get i dont want libc to have any part in it |
03:25:15 | disruptek | that's what i mean. |
03:26:51 | disruptek | the whole way we build software has to change. |
03:28:36 | * | rockcavera quit (Read error: Connection reset by peer) |
03:28:40 | disruptek | to do that, we have to be able to transition our thinking to the forest from the trees. |
03:28:55 | FromDiscord | <4984> what does that mean!? |
03:29:17 | disruptek | we have to be able to compose software with a lisp-like system. |
03:29:37 | FromDiscord | <4984> lisp has major issues |
03:29:52 | disruptek | "lisp"? |
03:30:16 | FromDiscord | <4984> well what way to mean "lisp-like" |
03:30:36 | disruptek | lisp π |
03:30:41 | * | rockcavera joined #nim |
03:30:41 | * | rockcavera quit (Changing host) |
03:30:41 | * | rockcavera joined #nim |
03:30:44 | disruptek | what are the major issues? |
03:31:26 | FromDiscord | <4984> well i dont know CL |
03:31:38 | FromDiscord | <4984> but in scheme i know a bunch as in gc, no return |
03:31:39 | FromDiscord | <4984> and such |
03:32:24 | disruptek | i just mean lisp as in the fundamental lambda-based programming system. |
03:32:44 | FromDiscord | <4984> thats not lisp |
03:32:49 | FromDiscord | <4984> thats lambda calculus |
03:33:26 | disruptek | yes. |
03:33:46 | disruptek | that'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:48 | disruptek | why 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:45 | FromDiscord | <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:16 | disruptek | how often? |
04:38:17 | FromDiscord | <Fern & Simula (They/Them)> currently? always |
04:38:32 | FromDiscord | <Fern & Simula (They/Them)> one sec and ill set up a paste |
04:38:35 | * | dadada_ joined #nim |
04:38:41 | disruptek | wow. |
04:39:35 | FromDiscord | <Fern & Simula (They/Them)> the while loop on line 17 never finishes https://play.nim-lang.org/#ix=2bGc |
04:41:50 | disruptek | you probably used up your python invocations for the day. |
04:42:21 | FromDiscord | <Fern & Simula (They/Them)> i must've |
04:42:31 | FromDiscord | <Fern & Simula (They/Them)> the weird part is inim has the same problem... but only once |
04:42:35 | FromDiscord | <Fern & Simula (They/Them)> which is why i set up the loop |
04:42:42 | disruptek | looks like you're not on windows. hmm. |
04:42:58 | FromDiscord | <Fern & Simula (They/Them)> nope, fedora |
04:44:03 | disruptek | i guess i don't use execProcess. it's very similar to startProcess? |
04:45:14 | FromDiscord | <Fern & Simula (They/Them)> i was thinking that might be the issue, so i'm just manually working with startProcess hayha |
04:45:32 | disruptek | my guess is that your system is so warm that it's closing the stream before it even finishes the output. |
04:45:52 | FromDiscord | <Fern & Simula (They/Them)> that's what i'm thinking |
04:45:53 | disruptek | ie. it knows the program is dead and doesn't empty the output buffer. |
04:45:56 | FromDiscord | <Fern & Simula (They/Them)> because it *was* working |
04:46:32 | disruptek | i do the right thing in golden. |
04:46:37 | disruptek | !repo golden |
04:46:38 | disbot | https://github.com/disruptek/golden -- 9golden: 11a benchmark for compile-time and/or runtime Nim π 15 15β 0π΄ |
04:46:53 | disruptek | but it might be a little different from what you're doing. |
04:47:20 | FromDiscord | <Fern & Simula (They/Them)> i'll take a look, thank you! |
04:47:35 | disruptek | execCmdEx is a simpler one; i do capture in bump |
04:47:38 | disruptek | !repo bump |
04:47:38 | disbot | https://github.com/disruptek/bump -- 9bump: 11a tiny tool to bump nimble versions π» 15 13β 1π΄ 7& 1 more... |
04:49:18 | FromDiscord | <Fern & Simula (They/Them)> if i `open` a filehandle returned from `outputHandle`, should i close that file, or no? |
04:49:33 | FromDiscord | <Fern & Simula (They/Them)> trying to make sure i understand the documentation |
04:49:47 | disruptek | i have no idea. |
04:50:13 | disruptek | i think you can close it prematurely and it costs nothing to do so. |
04:50:18 | disruptek | ie. no ill-effects. |
04:50:50 | FromDiscord | <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:57 | FromDiscord | <Fern & Simula (They/Them)> i think so, just not quite certain |
04:51:15 | disruptek | i don't know, but that sounds like i'm wrong. |
04:52:20 | disruptek | i 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:55 | FromDiscord | <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:52 | FromDiscord | <Fern & Simula (They/Them)> yeah, working directly with the process fixed it haha |
04:57:27 | disruptek | what did you use? |
04:59:38 | disruptek | treeform: 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:37 | FromGitter | <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:58 | Araq | read https://nim-lang.org/docs/manual_experimental.html#aliasing-restrictions-in-parameter-passing |
10:07:01 | FromGitter | <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:41 | Araq | aliasing is hard but we'll get there. Nim follows Ada's footsteps which has Spark for verification |
10:28:23 | FromDiscord | <mratsim> did you see the SAW link I posted the other day btw? |
10:32:40 | Araq | not really |
10:34:34 | * | krux02 joined #nim |
10:40:45 | FromDiscord | <mratsim> Formal verification for C: https://saw.galois.com/, based on Z3 https://github.com/GaloisInc/saw-script |
10:47:54 | Araq | Error: 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:54 | Araq | error: invalid argument '-std=gnu++11' not allowed with 'C' |
10:48:23 | Araq | tired of this, gonna revert this linenoise patch |
10:49:52 | FromDiscord | <clyybber> Araq, timotheecour: I feel particularily dumb rn, what is the problem with using uint/int as the hash themselves? |
10:50:02 | FromDiscord | <clyybber> It can't collide and its just a cast |
10:50:07 | FromDiscord | <clyybber> So what am I missing? |
10:51:08 | Araq | the bitmasking operation we do. |
10:51:23 | Araq | we mask the integer so that it fits the underlying seq |
10:51:36 | FromDiscord | <clyybber> Ah |
10:51:37 | FromDiscord | <clyybber> I see |
10:51:39 | Araq | because we don't provide space for 4 billion entries in the seq. |
10:51:43 | Araq | and that makes all the difference. |
10:51:45 | FromDiscord | <clyybber> Yeah |
10:51:48 | FromDiscord | <clyybber> Ok, thanks |
11:25:26 | FromDiscord | <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:59 | kaiyin | I'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:31 | kaiyin | I don't understand where the `x` came from? |
11:58:50 | FromDiscord | <Rika> https://github.com/mratsim/Arraymancer/blob/master/src/tensor/higher_order_applymap.nim#L45 |
11:59:43 | Zevv | it's injected by the template |
11:59:55 | Zevv | bad hygiene |
11:59:59 | FromDiscord | <Rika> yeah |
12:00:18 | FromDiscord | <Rika> *whistles* i totally don't do that *whistles* |
12:10:41 | * | Kaivo joined #nim |
12:13:20 | * | dddddd joined #nim |
12:27:42 | Zevv | I do that. It keeps things fresh and exciting |
12:31:15 | FromDiscord | <Lantos> is there a way to have leading underscores in type defs? |
12:31:25 | FromDiscord | <Lantos> or special chars? |
12:32:02 | FromDiscord | <Lantos> type |
12:32:03 | FromDiscord | <Lantos> me = object |
12:32:03 | FromDiscord | <Lantos> _name: string |
12:32:34 | FromDiscord | <Rika> no |
12:32:36 | FromDiscord | <clyybber> nope |
12:32:40 | FromDiscord | <clyybber> why do you want it? |
12:32:54 | FromDiscord | <Rika> i've seen someone use "pFieldName" for private fields |
12:32:59 | FromDiscord | <clyybber> Maybe it works when you encase it with ` ` |
12:33:11 | * | fanta1 quit (Quit: fanta1) |
12:33:11 | FromDiscord | <clyybber> but I don't think so " ` " |
12:33:18 | FromDiscord | <clyybber> ^ |
12:33:25 | FromDiscord | <Rika> i dont think it would work anyway |
12:33:26 | FromDiscord | <Lantos> trying to map bson to objects and ofc bson has _id as meta |
12:33:33 | FromDiscord | <clyybber> just call it id |
12:33:36 | FromDiscord | <clyybber> I guess |
12:33:44 | FromDiscord | <Rika> or bsonIdMeta or so |
12:34:10 | FromDiscord | <Rika> calling it just id would cause issues; what if the user also had an id field? |
12:35:56 | FromDiscord | <Lantos> yeah |
12:36:00 | FromDiscord | <Lantos> thats why |
12:36:20 | FromDiscord | <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:00 | FromDiscord | <Rika> @Lantos idea; anything the user creates, append a word to it. that way you dont get collisions |
12:40:11 | FromDiscord | <Rika> not sure if that works actually but its just an idea |
12:41:59 | FromDiscord | <clyybber> call it us_id? |
12:42:06 | FromDiscord | <clyybber> us as in underscore |
12:51:38 | * | Guest79300 quit (Ping timeout: 240 seconds) |
12:53:28 | FromDiscord | <OyeGamer> Follow nim.programmer on Instagram. |
12:53:38 | * | dadada_ joined #nim |
12:54:49 | FromDiscord | <Rika> i dont think you should advertise here |
12:58:00 | Yardanico | I wonder what's the point in posting tech stuff in instagram, it's simply made for another thing |
13:02:39 | FromDiscord | <Rika> i personally dont use instagram, but knowing facebook i prolly have an instagram account |
13:04:07 | Yardanico | well I have both fb/ig accounts but I don't use them at all xD |
13:10:07 | FromDiscord | <Lantos> When you write a document to the mongodb, meta info is auto appended. |
13:10:07 | FromDiscord | <Lantos> Eg |
13:10:08 | FromDiscord | <Lantos> { "Book": { "name": "Nim in action", "author":"Dominik P"}} |
13:10:08 | FromDiscord | <Lantos> |
13:10:08 | FromDiscord | <Lantos> Becomes |
13:10:08 | FromDiscord | <Lantos> { "Book": { "name": "Nim in action", "author":"Dominik P", "_id":{"$osd":"fheinxeuhscbwkiche"}}} |
13:10:15 | Yardanico | pls don't paste like this :P |
13:12:37 | FromDiscord | <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:38 | Araq | what does Affiliation mean? |
14:15:01 | Araq | context: applying for a talk at a conference |
14:15:54 | Zevv | if you are part of or connected to some organization or company |
14:16:48 | Araq | ah ok |
14:18:58 | Zevv | where will you be talking |
14:20:09 | Araq | if I'm accepted, Berlin, July, Rebase 2020 |
14:33:21 | * | dadada_ is now known as dadada |
14:37:33 | FromDiscord | <clyybber> Araq: I have ported ryu. |
14:37:45 | FromDiscord | <clyybber> Its still pretty unnimified but its getting there |
14:37:49 | * | Xatenev left #nim (#nim) |
14:38:14 | FromDiscord | <clyybber> I also ported the generic variant which works for float32 and float64 up to floatXX |
14:38:22 | FromDiscord | <clyybber> but I need uint128 support |
14:38:48 | FromDiscord | <clyybber> Since this has a chance of getting into the stdlib, should I use status bigint library? |
14:38:59 | FromDiscord | <clyybber> I would like to, since it actually supports uint128 |
14:39:11 | FromDiscord | <clyybber> as opposed to the Int128 thats in the compiler |
14:42:30 | Araq | go for it |
14:42:57 | FromDiscord | <clyybber> ok nice |
14:43:00 | Araq | but omg it means ryu will add to the code size |
14:43:24 | FromDiscord | <clyybber> wdym? |
14:43:35 | FromDiscord | <clyybber> I ported the generic variant because its smaller and more elegant |
14:43:57 | FromDiscord | <clyybber> or was that an imitation of krux? |
14:45:48 | * | sentreen quit (Quit: sentreen) |
14:47:26 | FromGitter | <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:08 | FromDiscord | <clyybber> hmm |
14:57:57 | disruptek | ugh, please don't do that. |
14:58:09 | disruptek | just let leorize work magic. |
14:58:19 | FromDiscord | <clyybber> ? |
14:58:27 | FromDiscord | <clyybber> maybe I can manage without |
14:58:36 | FromDiscord | <clyybber> I mean, its gonna be an array of uint64 then tho |
14:58:55 | FromDiscord | <clyybber> and I can just implement the ops I need |
14:59:11 | disruptek | the 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:21 | FromDiscord | <clyybber> yeah |
14:59:28 | FromDiscord | <clyybber> so? |
14:59:35 | FromDiscord | <clyybber> the algorithms ryu uses need big ints |
14:59:37 | disruptek | i think leorize is working on that tiny version. |
14:59:41 | FromDiscord | <clyybber> no way around it |
15:00:11 | disruptek | sure, but we do have int128 in the compiler already. |
15:00:30 | FromDiscord | <clyybber> we could replace that with stint too |
15:00:49 | FromDiscord | <clyybber> of course we could also add unsigned support to Int128 |
15:00:57 | disruptek | to what end? |
15:00:58 | FromDiscord | <clyybber> it should be relatively easy I guess |
15:01:07 | FromDiscord | <clyybber> disruptek: To what end what? |
15:01:08 | disruptek | this was never a priority. |
15:01:19 | FromDiscord | <clyybber> what exactly? |
15:01:29 | disruptek | disruptech. |
15:01:33 | disruptek | disruption of the tech. |
15:01:38 | FromDiscord | <clyybber> ? |
15:02:08 | disruptek | the reason this finally "had" to happen was float identity or lossless roundtrip in json serialization. |
15:02:17 | FromDiscord | <clyybber> yeah |
15:02:43 | disruptek | that goal can be met without turning the compiler on its head. |
15:02:52 | disruptek | or creating a political situation with bigints. |
15:03:23 | disruptek | let's do the thing, learn a thing, move on. |
15:03:30 | disruptek | stint will always be on the table. |
15:03:45 | FromDiscord | <clyybber> Ugh |
15:03:50 | FromDiscord | <clyybber> We can use d2s and f2s sure |
15:03:50 | disruptek | well shit, man. |
15:03:55 | disruptek | users have to step up. |
15:03:59 | FromDiscord | <clyybber> I'm trying to make it nimmy tho |
15:04:13 | disruptek | did you look at leorize's version? |
15:04:53 | FromDiscord | <clyybber> there is nothing |
15:05:01 | FromDiscord | <clyybber> it only classifies floats yet |
15:05:14 | disruptek | oh, maybe he stopped working on it. |
15:05:59 | disruptek | okay, my opinion: put uint128 into int128 and call it good. |
15:06:24 | disruptek | you 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:34 | FromDiscord | <clyybber> I just fear that int128 will have more bugs |
15:10:42 | FromDiscord | <clyybber> which would really suck |
15:11:24 | disruptek | then write a test or two. it's tiny. |
15:12:46 | disruptek | what did you come up with on that pragma macro problem? |
15:13:04 | FromDiscord | <clyybber> tiny as in 600 LOC? |
15:13:18 | FromDiscord | <clyybber> disruptek: Nothing, didn't look into it yet :p |
15:13:33 | disruptek | 600 loc does not impress me. |
15:14:10 | disruptek | maybe you should do a wc on stint before you whine about 600 loc. π |
15:14:56 | disruptek | this is already technical debt. no good reason not to make it pass some tests, too. |
15:14:56 | * | paxis joined #nim |
15:15:04 | FromDiscord | <clyybber> stint has 1400 |
15:15:41 | FromDiscord | <clyybber> but it also works at compile time |
15:15:52 | FromDiscord | <clyybber> I don't care which one I use |
15:15:55 | FromDiscord | <clyybber> as long as it works |
15:16:19 | FromDiscord | <clyybber> maybe I'll just nimify the float32 and float64 variants |
15:16:23 | FromDiscord | <clyybber> and not use int128 |
15:16:42 | disruptek | that's what i thought we were doing. |
15:17:34 | leorize | what are y'all working on? |
15:18:22 | * | disruptek runs off. |
15:19:10 | FromDiscord | <clyybber> disruptek: Nah, I ported the generic variant too |
15:19:21 | FromDiscord | <clyybber> And since its less code duplication |
15:19:27 | FromDiscord | <clyybber> I thought getting this into the stdlib |
15:19:37 | FromDiscord | <clyybber> instead of seperate float32 and float64 variants |
15:20:19 | leorize | the only thing I concerned about c-ryu is that it's kinda a black box |
15:20:32 | leorize | though I'm understanding parts of it thanks to the paper now |
15:21:43 | * | dddddd quit (Ping timeout: 260 seconds) |
15:27:48 | disruptek | leorize: did you port all the tests or just some? |
15:28:21 | leorize | I'm not working on it atm, will do tmr :) |
15:28:43 | disruptek | maybe clyybber did them all. |
15:28:52 | FromDiscord | <clyybber> yeah |
15:28:58 | FromDiscord | <clyybber> I ported all of them |
15:29:06 | FromDiscord | <clyybber> not the benchmarks yet |
15:29:07 | FromDiscord | <clyybber> tho |
15:29:24 | FromDiscord | <clyybber> there: https://github.com/Clyybber/nimryu/ |
15:31:23 | disruptek | well, if i can help, let me know. i don't mean to rain on the parade. |
15:31:41 | disruptek | i just think we have a pretty good compiler and i'd rather work on something that needs a better story. |
15:32:06 | disruptek | three people porting an existing c lib is not that thing, imo. |
15:32:17 | FromDiscord | <clyybber> yeah |
15:32:17 | FromDiscord | <clyybber> but you stopped |
15:32:40 | FromDiscord | <clyybber> I will do the job until the end |
15:32:47 | FromDiscord | <clyybber> no worries |
15:32:53 | disruptek | well, in fairness, i was blocked by the int128 bug. |
15:33:26 | Araq | disruptek, it was fixed though, but I agree |
15:33:33 | FromDiscord | <clyybber> that excuse has been dropped :p |
15:33:38 | disruptek | yep. |
15:33:38 | Araq | too many people seem to work on ryu now |
15:33:38 | * | dadada quit (Ping timeout: 240 seconds) |
15:33:48 | Araq | I need clyybber for scope-based destruction |
15:33:51 | FromDiscord | <clyybber> yeah, let me be the chosen-one π |
15:33:57 | FromDiscord | <clyybber> Araq: Ah |
15:33:58 | FromDiscord | <clyybber> Haha |
15:33:58 | Araq | it's a clusterfuck of complexity :-( |
15:34:29 | FromDiscord | <clyybber> Araq: Wouldn't it be simpler to call injectdestructors for each scope? |
15:34:29 | disruptek | it's not supposed to be trivial. π |
15:34:32 | FromDiscord | <clyybber> Instead of handling the scopes in injectdestructor |
15:34:46 | FromDiscord | <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:38:40 | Araq | yeah |
15:40:32 | Araq | what we also need is lent/sink inference |
15:40:41 | Araq | sink inference is rather simple |
15:40:41 | * | paxis quit (Quit: Client exiting) |
15:40:55 | * | Guest84067 is now known as dadada |
15:41:23 | Araq | you check for the pattern someLocation = parameter |
15:41:27 | FromDiscord | <clyybber> You mean sink inference as in what I proposed? |
15:41:42 | FromDiscord | <clyybber> Like no explicit sink annotations needed anymore for args? |
15:41:43 | * | madprops left #nim ("Leaving") |
15:41:46 | Araq | and if the proc has no forward declaration, you can make the parameter a 'sink' |
15:42:08 | dadada | are there charts/diagrams somewhere on how all parts of nim are interlinked? |
15:42:14 | Araq | originally I though about a naming scheme for 'sink' |
15:42:17 | dadada | especially the compiler has me interested |
15:42:20 | * | madprops joined #nim |
15:42:25 | FromDiscord | <clyybber> dadada: Yardanico posted a graph here once |
15:42:29 | FromDiscord | <clyybber> a few days ago |
15:42:38 | dadada | I can you through all the files line by line, but the abstract top down view is what would be more welcoming |
15:42:41 | FromDiscord | <clyybber> We mean the same thing right? |
15:42:46 | FromDiscord | <clyybber> Making sink implicit? |
15:43:26 | Araq | dadada, there is https://nim-lang.org/docs/intern.html |
15:43:47 | * | paxis joined #nim |
15:44:12 | Araq | it uses an architecture most common in the literature, the parser calls the lexer and builds an AST |
15:44:22 | Araq | the AST is sem'checked in two phases |
15:44:33 | Araq | and then the code generators see it and produce code |
15:44:51 | Araq | read ast.nim and main.nim |
15:44:59 | Araq | as a starting point |
15:45:21 | Araq | main.nim does setup the passes over the AST |
15:46:48 | FromDiscord | <clyybber> argh, I always forget, can we return in blocks? |
15:47:04 | FromDiscord | <clyybber> block expressions that is |
15:47:24 | FromDiscord | <clyybber> Araq: Ping, do you mean making sink implicit in parameters? |
15:48:46 | Araq | yes |
15:49:09 | FromDiscord | <clyybber> Nice |
15:49:36 | FromDiscord | <clyybber> Araq: But still allow for explicit sink params, right? |
15:49:46 | FromDiscord | <clyybber> To override the default |
15:49:53 | FromDiscord | <clyybber> for closures and stuff |
15:49:59 | FromDiscord | <clyybber> and for backwards compatibility I guess |
15:50:19 | FromDiscord | <clyybber> and for owned refs |
15:50:24 | FromDiscord | <clyybber> or similar linear types |
15:51:36 | FromDiscord | <clyybber> Araq: I can fully dedicate myself to destructor stuff in a week or so |
15:51:55 | FromDiscord | <clyybber> porting ryu is not really taking any time |
15:51:58 | FromDiscord | <clyybber> its just a few seds |
15:52:01 | FromDiscord | <clyybber> sed calls |
15:52:08 | FromDiscord | <clyybber> so I do it while learning :d |
15:57:46 | dadada | you know this? https://github.com/StefanSalewski/gintro |
15:59:03 | FromDiscord | <clyybber> whom are you asking? |
15:59:11 | FromDiscord | <clyybber> I know it |
15:59:13 | FromDiscord | <clyybber> theres also https://github.com/trustable-code/NiGui |
16:04:32 | Araq | sure, explicit 'sink' will remain |
16:04:47 | Araq | so there are two competing designs: |
16:05:19 | Araq | 1. sink annotations based on proc names. we know []=, add take sink parameters |
16:05:31 | Araq | and that [] produces a lent T |
16:05:45 | Araq | 2. sink parameter inference based on the proc body |
16:05:54 | Araq | I dunno what will work better |
16:06:12 | Araq | (2) is more standard in computer science |
16:07:09 | FromDiscord | <clyybber> Araq: I vote for 2 |
16:07:13 | krux02 | Araq: I don't like the "based on the name" part at all. |
16:07:25 | FromDiscord | <clyybber> But I'm not sure why we should do the inference based on the proc body |
16:07:34 | FromDiscord | <clyybber> Araq: We could just do it a bit like generics |
16:07:52 | * | floppydh quit (Quit: WeeChat 2.7) |
16:07:59 | FromDiscord | <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:14 | FromDiscord | <clyybber> For closures and function pointers there will be a default |
16:08:17 | dadada | I created a project using nimble init |
16:08:27 | dadada | but then in its default state it doesn't build |
16:09:15 | disruptek | what could be built? |
16:10:20 | Araq | krux02, I would only enable it for the stdlib where the naming scheme is defacto enforced anyway |
16:10:40 | Araq | other code would need to opt-in |
16:10:50 | Araq | it's the simplest thing that can possibly work :P |
16:11:12 | Araq | clyybber: I don't understand how you can do it without looking at the proc body |
16:11:53 | krux02 | I really don't like the hole idea of semantics for the computer encoded in the name. |
16:12:13 | FromDiscord | <clyybber> Araq: Why would you need to look at the procs body? |
16:12:26 | FromDiscord | <clyybber> You would just generate variants of the proc on demand |
16:12:31 | FromGitter | <kaushalmodi> dadada: If you init the project as a library, it won't build |
16:12:39 | FromGitter | <kaushalmodi> init it as app or hybrid |
16:13:02 | krux02 | Names 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:21 | krux02 | And that only works, because it is enforce 100% through all of the code. |
16:13:35 | FromDiscord | <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:21 | disruptek | we talked about dispatch on sink before. |
16:15:05 | FromDiscord | <clyybber> I'm only using this metaphor to get my idea across |
16:15:26 | disruptek | i agree that naming seems like a strange place to add a semantic, since naming is constrained by unrelated requirements. |
16:16:24 | FromDiscord | <clyybber> Araq: I remember last time I proposed this you said it would cause code bloat |
16:17:18 | FromDiscord | <clyybber> But if we cap it it should be fine I think |
16:19:23 | FromDiscord | <clyybber> In theory it introduces 2^n variants where n is the amount of params |
16:20:13 | FromDiscord | <clyybber> which is bad code bloat |
16:20:17 | dadada | disruptek: 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:03 | dadada | kaushalmodi: okay, thanks |
16:21:15 | FromDiscord | <clyybber> but in practice I think we can discard the distinctions for parameters based on some heuristics |
16:21:44 | dadada | there's no web scraping lib for nim yet? |
16:22:44 | Araq | clyybber: looks like a bad idea |
16:23:01 | Araq | for example, assume an 'add' without sink annotation |
16:23:22 | Araq | and we compile s.add notLastReadHere(x) |
16:23:41 | Araq | and then later |
16:23:46 | Araq | s.add lastUse(x) |
16:24:02 | Araq | --> 2 instantiations of 'add' produced |
16:24:07 | FromDiscord | <clyybber> Yeah |
16:24:19 | Araq | one of which is pointless as it can be done as s.add copyof(x) |
16:24:36 | FromDiscord | <clyybber> But copyof introduces a copy |
16:24:51 | FromDiscord | <clyybber> Which could be potentially expensive |
16:24:57 | FromDiscord | <clyybber> No? |
16:25:16 | Araq | no for the simple reason that your non-sink add variant also does the copy too |
16:25:25 | Araq | it's simply code bloat though |
16:27:12 | Araq | for the same reason we do not support overloading based on 'sink T', I never found a case where it made sense |
16:27:19 | FromDiscord | <clyybber> Araq: Hmm, right |
16:27:22 | Araq | there is no polymorphism at work here |
16:27:33 | Araq | parameters are either always sink or they are not |
16:27:38 | FromDiscord | <clyybber> Araq: Then why do we not have everything sink? |
16:27:52 | Araq | come on, didn't watch my talk? :P |
16:28:02 | FromDiscord | <clyybber> I did, I think |
16:28:13 | FromDiscord | <clyybber> But my head is "full" |
16:28:20 | Araq | echo x # er, pass a copy of 'x' to 'echo'? wtf |
16:28:29 | * | ftsf quit (Ping timeout: 272 seconds) |
16:28:47 | Araq | using sink for non-sink parameters is a performance killer |
16:29:02 | Araq | as much as not using sink for where it's required |
16:29:10 | FromDiscord | <clyybber> hmm |
16:29:26 | Araq | inference based on a proc body is really simple though |
16:29:35 | Araq | the patterns to look for are |
16:29:49 | Araq | someDest = parameter |
16:29:53 | Araq | and |
16:29:56 | lqdev[m] | every time I work with methods, I wonder what's the damn point of all these method lock level warnings |
16:30:02 | Araq | passedToSink(parameter) |
16:30:16 | Araq | that's it, trivial to do in sempass2.nim |
16:30:40 | Araq | all you need to watch out for is if the proc was used already before we have seen its body |
16:30:40 | lqdev[m] | like, afaik, lock levels have something to do with threading? but my program's not multithreaded and --threads:off |
16:31:10 | FromDiscord | <clyybber> Araq: Thats really cool. |
16:32:18 | Araq | lqdev[m], preventing deadlocks at compile-time is a killer feature though and --threads:on should be the default in 2020 *cough* |
16:32:19 | FromDiscord | <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:32:29 | Araq | yeah |
16:33:05 | FromDiscord | <clyybber> Araq: So there are a few procs from which we infer it "upwards" |
16:33:08 | FromDiscord | <clyybber> thats really cool |
16:33:22 | FromDiscord | <clyybber> I really like it |
16:33:44 | * | Kaivo quit (Quit: WeeChat 2.7) |
16:33:48 | lqdev[m] | Araq: what does the lock level have to do with deadlocks? sorry but I'm not really into threaded programming |
16:34:21 | FromDiscord | <clyybber> You don't get deadlocks when your locklevels are correct |
16:34:22 | FromDiscord | <clyybber> basically |
16:34:37 | * | jakob0094 joined #nim |
16:34:44 | Araq | lqdev[m], right now it's only a burden but Nim prevents both data races and deadlocks at compile-time |
16:35:09 | Araq | it was never explored well though because of the bad thread-local heaps |
16:35:38 | Araq | which killed most efforts to multi-thread anything in Nim |
16:37:11 | * | nsf joined #nim |
16:37:12 | jakob0094 | hi people! Is there an easy way to hash ref objects? can i just use hash(unsafeAddr obj)? |
16:37:38 | Araq | do not hash 'unsafeAddr' |
16:37:50 | Araq | it's usually a stack address and volatile |
16:37:51 | * | marmotini_ quit (Read error: Connection reset by peer) |
16:38:04 | Araq | compute the hash based on the pointer's value instead |
16:38:16 | Araq | hash(cast[int](myref)) |
16:38:41 | jakob0094 | ah, thank you |
16:39:39 | jakob0094 | is 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:32 | disruptek | what are you trying to do poorly? |
16:41:58 | jakob0094 | identity hashmaps |
16:42:07 | disruptek | ecs? |
16:42:46 | Araq | jakob0094, we don't have a moving GC. it's a good point though |
16:42:51 | jakob0094 | no, i'm implementing the epa algorithm for collision detection. i need to track faces, vertices and edges by identity |
16:43:14 | disruptek | i think an id field makes more sense. |
16:44:04 | Araq | I agree with disruptek |
16:44:06 | disruptek | do you want it to work or do you want clever bugs? |
16:44:08 | jakob0094 | yes, you are right. should have thought about that |
16:46:08 | * | sentreen joined #nim |
16:49:45 | * | zickzackv joined #nim |
16:54:00 | Araq | lqdev[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:44 | disruptek | treeform: i wish we had a way to publish working google api tests with a harmless set of credentials. |
17:00:48 | lqdev[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:43 | Araq | your library shouldn't use 'method' :P |
17:01:53 | Araq | for extension points use proc vars |
17:02:33 | disruptek | wise words. |
17:02:49 | Araq | but don't take me too seriously, I live in a different world |
17:03:27 | disruptek | not in this case. |
17:03:32 | lqdev[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:58 | FromDiscord | <clyybber> minecraft? |
17:04:05 | disruptek | Araq: are you interested in the gittyup cpp failure? |
17:04:10 | lqdev[m] | nope, processing |
17:04:12 | disruptek | unrelated to exceptions. |
17:04:12 | FromDiscord | <clyybber> Araq: You are not the only one |
17:04:26 | lqdev[m] | never got into minecraft modding. |
17:04:27 | FromDiscord | <clyybber> I had to use lambdas instead of methods too |
17:04:31 | FromDiscord | <clyybber> for my framegraph |
17:04:37 | FromDiscord | <clyybber> lqdev[m]: Ah processing is cool |
17:04:49 | FromDiscord | <clyybber> Thought about building something similar in nim |
17:06:01 | lqdev[m] | might be a cool idea to add a Nim mode to processing ;) |
17:09:21 | FromDiscord | <clyybber> processing is inherently java, no? |
17:09:30 | FromDiscord | <clyybber> so not sure how that would work |
17:09:38 | FromDiscord | <clyybber> maybe with graal |
17:09:58 | leorize | processing does have a js and python target |
17:13:29 | FromDiscord | <clyybber> oh |
17:13:31 | FromDiscord | <clyybber> nice |
17:14:11 | FromDiscord | <Rika> imagine a python target on nim |
17:14:13 | FromDiscord | <Rika> god, no |
17:14:21 | FromDiscord | <Rika> never mind, ignore what i said |
17:16:26 | * | marmotini_ joined #nim |
17:18:54 | disruptek | done. |
17:22:36 | FromDiscord | <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:36 | FromDiscord | <sveri> This is the most minimal example I was able to put together: https://pastebin.com/f0i4TtT5 |
17:22:37 | FromDiscord | <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:37 | FromDiscord | <sveri> Any ideas what is wrong? |
17:36:50 | disruptek | --threads:on |
17:37:58 | FromDiscord | <sveri> disruptek: I have threads on. I run on windows with the latest nim version if that is of any help |
17:39:18 | disruptek | httputils.nim would help. |
17:40:47 | FromDiscord | <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:43 | disruptek | how do i run your ab test? |
17:43:32 | FromDiscord | <Recruit_main_70007> does nim have ownership checking? |
17:43:43 | disruptek | ~arc |
17:43:44 | disbot | arc: 11a new memory manager for Nim; see https://forum.nim-lang.org/t/5734 -- disruptek |
17:44:24 | FromDiscord | <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:39 | disruptek | yeah, i just want to repro your command-line. |
17:44:43 | FromDiscord | <sveri> if you just open it multiple times in a browser you will see the same |
17:46:33 | disruptek | works for me on linux. |
17:46:47 | FromDiscord | <clyybber> @Recruit_main_70007 Yeah |
17:46:49 | disruptek | are you running runServer() and not start()? |
17:46:52 | FromDiscord | <clyybber> With --newruntime |
17:47:02 | FromDiscord | <clyybber> For now the idea is on hold tho |
17:48:33 | FromDiscord | <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:33 | FromDiscord | <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:06 | disruptek | sveri: yes. |
17:50:01 | * | nsf quit (Quit: WeeChat 2.7) |
17:50:53 | FromDiscord | <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:10 | FromDiscord | <sveri> I get that mostly servers run on linux, but it would be nice to have it working on windows too. |
17:51:20 | disruptek | i doubt it; i'd probably call them on the phone. |
17:51:52 | disruptek | i think their investment in github is more strategic than practical. |
17:52:32 | disruptek | perhaps with a couple exceptions here and there; things like powershell (?) or whatever. |
17:52:54 | FromDiscord | <sveri> Hm, I am not sure if you are honest right now or not? π |
17:53:29 | FromDiscord | <sveri> *serious |
17:53:40 | * | zickzackv joined #nim |
17:56:50 | dadada | so many great python libraries that you can't use natively in nim |
17:58:02 | FromDiscord | <sveri> disruptek: thanks for trying to reproduce this π |
17:59:11 | disruptek | np |
17:59:48 | dadada | just imagine if nim had python's popularity ... one can dream, right |
18:00:10 | FromDiscord | <Recruit_main_70007> one day |
18:00:45 | disruptek | start today. |
18:01:07 | disruptek | don't be afraid to write some nim. |
18:02:13 | dadada | disruptek: am not |
18:06:12 | FromDiscord | <Rika> the macros i make scare me |
18:07:01 | FromDiscord | <clyybber> @sveri disrupteks tongue has pierced his cheek a long time ago |
18:07:47 | FromDiscord | <clyybber> @Rika the macros I don't make are scarier |
18:08:28 | FromDiscord | <clyybber> I'd rather have a scary macro than a file that is empty when piped through uniq |
18:08:29 | FromDiscord | <clyybber> :p |
18:19:36 | FromDiscord | <Rika> it's going to be a maintenance nightmare though won't it? |
18:19:40 | FromDiscord | <Recruit_main_70007> macros scare me in general |
18:19:59 | disruptek | empty files are rarely a maintenance nightmare, ime. |
18:20:23 | FromDiscord | <Rika> ime? in my epeneien? |
18:21:34 | disruptek | experience. i've experienced the maintenance of so, so many empty files. |
18:23:21 | FromDiscord | <Kingherring> for this valentines day, I am in love with Nim |
18:24:41 | leorize[m] | do you bring gifts? |
18:25:30 | FromDiscord | <Rika> disruptek is it really maintenance if theres nothing to maintain |
18:25:53 | FromDiscord | <Elegant Beef> > disrupteks tongue has pierced his cheek a long time ago |
18:26:00 | disruptek | are you saying i'm too incompetent to maintain empty files? |
18:26:15 | disruptek | let me have my wins, ffs. |
18:26:22 | FromDiscord | <Elegant Beef> That's an implication that disruptek is tongue and cheek |
18:26:33 | FromDiscord | <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:41 | FromDiscord | <Elegant Beef> And he disobeys poes law |
18:26:50 | FromDiscord | <Kingherring> @disruptek are you saying my love for Nim is not enough for you? |
18:26:59 | disruptek | is that the one about masturbation and chili peppers? |
18:27:09 | * | zama joined #nim |
18:27:18 | FromDiscord | <Elegant Beef> No it's the one about insincerty being undetectable on the internet without indication |
18:27:19 | FromDiscord | <Rika> yeah i dont know why i bothered trying to be serious |
18:27:33 | disruptek | these files are seriously empty. |
18:28:22 | FromDiscord | <Rika> "program something that prints itself", aka a quine-but-not-really-as-quines-need-to-have-content |
18:28:39 | disruptek | contents remain undetectable on the internet. i guess i need a cat. |
18:29:10 | disruptek | ln -s /dev/null program.that.prints.itself |
18:29:26 | FromDiscord | <Elegant Beef> I write all my code in using tabs/spaces that converts from morse code |
18:29:51 | FromDiscord | <Elegant Beef> It's the most useful obfuscsation method |
18:30:05 | disruptek | morse code? keep swinging, slugger. |
18:30:15 | FromDiscord | <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:45 | FromDiscord | <clyybber> @Elegant Beef https://github.com/belamenso/v |
18:35:35 | FromDiscord | <Rika> why |
18:35:46 | FromDiscord | <Rika> that's deffo unary isnt it |
18:36:47 | * | dadada quit (Ping timeout: 260 seconds) |
18:38:28 | FromDiscord | <clyybber> > why |
18:38:37 | FromDiscord | <clyybber> we should stop asking why |
18:38:43 | * | dadada joined #nim |
18:38:50 | FromDiscord | <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:39 | FromDiscord | <Elegant Beef> V is still better than python |
18:58:00 | FromDiscord | <Elegant Beef> strongly typed, with dynamic typing, *pukes* |
18:58:25 | FromDiscord | <clyybber> this is not V |
18:58:30 | FromDiscord | <clyybber> this is a nim macro |
18:58:40 | FromDiscord | <clyybber> this is not V-lang |
18:58:46 | FromDiscord | <Elegant Beef> i know |
18:59:00 | FromDiscord | <Elegant Beef> im saying using v would be better than using python |
18:59:59 | FromDiscord | <clyybber> certainly not for quick shell like scripts |
19:00:35 | * | sagax quit (Ping timeout: 268 seconds) |
19:02:20 | FromDiscord | <Elegant Beef> You underestimate my dislike of python π |
19:02:31 | FromGitter | <nixfreakz_twitter> Opinon: What do you people use for programming methodology , Bottom-up or Top-down |
19:02:53 | FromGitter | <nixfreakz_twitter> I trying to figure what works best for me |
19:04:26 | disruptek | then why are you asking us? |
19:04:39 | FromDiscord | <clyybber> bottom-down |
19:04:44 | FromDiscord | <clyybber> story of my life |
19:06:21 | FromGitter | <nixfreakz_twitter> great question , because getting others feedback help me figure out an issue, even if it relevant or not |
19:08:11 | disruptek | what's the problem you're having? |
19:09:39 | * | JustASlacker joined #nim |
19:10:35 | Araq | nixfreakz_twitter: neither, start with data modelling |
19:10:49 | Araq | the data then guides your algorithms |
19:11:39 | Araq | code is usually overrated, data lasts longer than code |
19:12:14 | FromDiscord | <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:41 | FromDiscord | <treeform> <disruptek> "treeform: ping", what? |
19:13:03 | * | dddddd joined #nim |
19:13:28 | disruptek | asked and answered, i guess. π |
19:14:50 | * | tefter quit (Ping timeout: 240 seconds) |
19:15:20 | FromDiscord | <treeform> ok... |
19:15:51 | disruptek | google is moving to swagger-3 and i'm not (yet). so ima hold off switching to quickjwt until then. |
19:16:03 | FromDiscord | <treeform> wut? |
19:16:26 | FromDiscord | <treeform> What is swagger-3? I just had a bunch of pain learning about jwt... |
19:16:51 | disruptek | openapi 3 is different from openapi 2 (aka swagger). |
19:17:36 | disruptek | i'm realizing that if something i wrote isn't worth someone else exploiting, then it's not worth me maintaining. |
19:18:06 | FromDiscord | <treeform> that is true, I mostly write stuff for myself. |
19:18:54 | FromGitter | <nixfreakz_twitter> data modeling , interesting |
19:20:15 | FromGitter | <nixfreakz_twitter> hmm isn't data modeling more for , say you are implementing a database in your code? |
19:23:02 | disruptek | nah. |
19:23:11 | disruptek | don't overthink it. |
19:24:51 | * | rockcavera quit (Remote host closed the connection) |
19:25:11 | FromDiscord | <sveri> Oh that brings back nightmares. I just evaluated openapi 3.0, which is the successor to swagger 2.0, at work. |
19:25:11 | FromDiscord | <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:53 | FromDiscord | <treeform> I still have nightmares about WSDL and Apache Axis ... |
19:26:56 | disruptek | yes, it's a major pita. |
19:27:35 | FromDiscord | <treeform> I remember I was to consume WSDL api from python. Python does not have good WSDL support. |
19:27:51 | FromGitter | <Varriount> Syntactically, it's close to Pascal |
19:27:59 | FromDiscord | <treeform> I think I ended up generating all of the XML by hand and sending it through. |
19:28:15 | FromGitter | <Varriount> Goodness gracious, timotheecour is quite productive... |
19:29:32 | FromDiscord | <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:35 | disruptek | i used to generate the ebay apis from a wsdl file that was like, i dunno, 10meg. |
19:29:58 | disruptek | had to hand-edit it first due to circular references unsupported by python wsdl parser. |
19:31:47 | * | rockcavera joined #nim |
19:32:47 | disruptek | the 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:21 | disruptek | not a big deal for one api, but pretty unsatisfying for supporting thousands of apis at once. |
19:36:09 | * | sagax joined #nim |
19:36:17 | FromGitter | <nixfreakz_twitter> @Araq - Do you use UML or something similar to sketch out your data ? |
19:36:50 | FromDiscord | <sveri> I see, pain is everywhere |
19:37:07 | FromDiscord | <treeform> nixfreakz_twitter, I am about 99.999% Araq does not use UML. |
19:37:20 | FromDiscord | <treeform> Because 99.9 of programmers don't use UML. |
19:37:47 | Araq | nixfreakz_twitter: depends on your use cases, but starting with Nim's "type" section helps |
19:38:03 | Araq | I would suggest JSON if it offered a schema |
19:38:13 | Araq | or maybe SQL |
19:38:29 | FromGitter | <nixfreakz_twitter> Ok thanks for the info |
19:40:14 | Araq | for NimForum I started with the SQL model and maybe dom96 cursed me for it |
19:40:39 | Araq | but IME it worked out well |
19:41:48 | Araq | and 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:03 | FromGitter | <nixfreakz_twitter> does it make sense to use a data model when creating , say commandline tools ? |
19:42:26 | FromGitter | <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:03 | Araq | "commandline tool" only means it will lack a UI. |
19:43:13 | Araq | what tool are you working on? |
19:45:20 | FromDiscord | <Elegant Beef> I've got to ask, would something like interfaced ever be added as a nim module? |
19:45:32 | Araq | but 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:00 | FromDiscord | <Elegant Beef> Obviously the more recent one isnt licensed properly but just interested in interfaces in languages π |
19:46:06 | Araq | <Elegant Beef>: yes |
19:46:39 | FromGitter | <nixfreakz_twitter> Nothing in particular more for parsing out data , instead of using grep, awk, bash, rg and so on |
19:46:40 | FromDiscord | <Elegant Beef> Ah ok cool |
19:47:02 | FromDiscord | <Elegant Beef> I mean is it a oneoff thing? |
19:47:04 | Araq | after https://github.com/nim-lang/RFCs/issues/192 we might embrace interfaces and pattern matching |
19:47:06 | disbot | β₯ outplace and chaining ; snippet at 12https://play.nim-lang.org/#ix=2bIT |
19:47:26 | FromDiscord | <Elegant Beef> If so i dont really think spending all that time on it is worth it |
19:47:38 | FromDiscord | <Elegant Beef> But i mean look what i did for my silly rofi cmd thing |
19:47:39 | FromDiscord | <Elegant Beef> π |
19:47:51 | FromDiscord | <Elegant Beef> Also Araq, i did properly style it |
19:47:52 | FromDiscord | <Elegant Beef> so be merry |
19:47:53 | FromDiscord | <Elegant Beef> π |
19:48:22 | FromDiscord | <Elegant Beef> Also sweet |
19:48:28 | Araq | I don't understand |
19:48:50 | FromDiscord | <Elegant Beef> The oneoff thing and spending the time was to nixfreakz |
19:48:59 | Araq | but I'm always polite, it's just that most don't realize |
19:49:16 | FromDiscord | <Elegant Beef> I was the schmuck that used pascal cased functions |
19:49:43 | FromDiscord | <Elegant Beef> after cleaning it up i decided, eh wth and properly style the nim files to the camel cased standard |
19:49:54 | Araq | don't worry about it |
19:50:05 | FromDiscord | <Elegant Beef> I wasnt, i was more joking around |
19:51:08 | FromGitter | <nixfreakz_twitter> <Araq> I don't understand > me? |
19:51:30 | Araq | no. |
19:51:42 | Araq | I didn't understand Elegant Beef |
19:51:54 | FromGitter | <nixfreakz_twitter> ok |
19:52:09 | Araq | nixfreakz_twitter: maybe study nimgrep's source code |
19:52:37 | FromGitter | <nixfreakz_twitter> yep you told me about that before , and that was great. |
19:54:08 | FromDiscord | <Elegant Beef> @clyybber i've got to ask, what 3D format do you intend to use for your engine? |
19:54:12 | dadada | Araq: 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:24 | FromDiscord | <clyybber> @Elegant Beef I don't intend on going 3D :p |
19:54:30 | FromDiscord | <Elegant Beef> Ah |
19:54:33 | FromDiscord | <Elegant Beef> Well damn |
19:54:50 | FromDiscord | <Elegant Beef> Was thinking of making a gltf2 importer π |
19:54:53 | Araq | dadada, sure |
19:55:10 | dadada | Araq: good, because I like it a little more that way :D |
19:55:10 | Araq | but I now prefer ',' over '.' |
19:55:11 | FromDiscord | <Elegant Beef> But it's hard to have an importer when you cant check if the model imported properly ;D |
19:55:12 | FromDiscord | <clyybber> @Elegant Beef https://github.com/zacharycarter/gltf.nim |
19:55:18 | FromDiscord | <Elegant Beef> god damn it |
19:55:25 | FromDiscord | <Elegant Beef> Leave something for the little guy! |
19:55:29 | FromDiscord | <clyybber> haha |
20:01:16 | dadada | Araq: 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:22 | dadada | lines, and with indention you'd also add structure/readability |
20:02:20 | dadada | Araq: 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:25 | FromDiscord | <exelotl> lol I bound the same gltf library just a few days before https://gist.github.com/exelotl/3cf6c15e4ac2c93f2274c48352808c1b |
20:03:47 | FromDiscord | <Elegant Beef> God damn you people |
20:03:49 | FromDiscord | <Elegant Beef> π |
20:04:08 | FromDiscord | <clyybber> lol |
20:04:26 | FromDiscord | <exelotl> but after doing so I came to the conclusion that Nim would benefit from a native one anyways |
20:04:37 | FromDiscord | <Elegant Beef> I mean i was thinking doing it natively |
20:04:48 | FromDiscord | <Elegant Beef> it's an open standard |
20:04:49 | FromDiscord | <clyybber> ~motd is google before work |
20:04:49 | disbot | motd: 11Join a non-Nim project with the goal of exposing that community to Nim. Do it now! |
20:04:49 | disbot | motd: 11google before work |
20:04:56 | Yardanico | lmao |
20:05:27 | FromDiscord | <Elegant Beef> If i googled before doing anything i'd probably have 0 code ever written |
20:06:43 | FromDiscord | <exelotl> so yeah I say go for it @Elegant Beef |
20:07:02 | FromDiscord | <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:03 | FromDiscord | <Elegant Beef> π |
20:07:15 | FromDiscord | <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:31 | FromDiscord | <Elegant Beef> You put a lot of faith in my coding abillity |
20:07:36 | FromDiscord | <Elegant Beef> π |
20:08:00 | Araq | <Elegant Beef>: please give us an entity component library that doesn't suck |
20:08:08 | Araq | I think that's still missing |
20:08:13 | FromDiscord | <Elegant Beef> Add interfaces, and that's a deal |
20:08:18 | FromDiscord | <Elegant Beef> π |
20:08:28 | Araq | interfaces kill your performance for this anyway |
20:08:39 | Araq | you need to find a better solution |
20:08:58 | FromDiscord | <Elegant Beef> Huh, a better solution than interfaces for modular code? |
20:09:26 | FromDiscord | <clyybber> yes |
20:09:43 | FromDiscord | <Elegant Beef> Composition is good though |
20:10:00 | FromDiscord | <clyybber> ecs is composition |
20:10:10 | FromDiscord | <clyybber> but not necessarily oo |
20:10:20 | FromDiscord | <clyybber> and if you want performance |
20:10:24 | FromDiscord | <clyybber> definitely not oo |
20:10:26 | * | zama quit (Ping timeout: 240 seconds) |
20:10:47 | FromDiscord | <exelotl> @Elegant Beef do you specifically mean the "runtime polymorphism" kind of interfaces? |
20:10:49 | FromDiscord | <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:58 | FromDiscord | <Elegant Beef> Yea C# like interfaces |
20:11:14 | FromDiscord | <clyybber> unitys ecs is fine |
20:11:33 | FromDiscord | <Elegant Beef> I mean it's unity, so you say that but it's probably half assed in someway and needs work |
20:11:57 | FromDiscord | <exelotl> unity's ecs would be fine if the language had macros like us x) |
20:12:06 | FromDiscord | <exelotl> it's very boilerplatey |
20:12:07 | FromDiscord | <Elegant Beef> Hell their production ready URP doesnt even allow custom post process effects |
20:12:25 | FromDiscord | <clyybber> > unity's ecs would be fine if the language had macros like us x) |
20:12:26 | Araq | fwiw I started an ECS |
20:12:37 | FromDiscord | <clyybber> - exelotl : happy little macro |
20:12:39 | Araq | but it never went anywhere |
20:12:45 | FromDiscord | <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:44 | FromDiscord | <Elegant Beef> I mean seems to me an ECS isnt too hard |
20:14:07 | FromDiscord | <clyybber> its an array |
20:14:12 | FromDiscord | <clyybber> *seq |
20:14:13 | FromDiscord | <Elegant Beef> Well table list |
20:14:19 | FromDiscord | <Elegant Beef> table of id, to list of components |
20:14:45 | FromDiscord | <clyybber> the way you select entities is the key |
20:14:49 | FromDiscord | <clyybber> to success and failure |
20:14:52 | FromDiscord | <clyybber> in terms of performance |
20:15:24 | FromDiscord | <Elegant Beef> what do you mean? Wouldnt a table be rather performant for this? |
20:15:44 | FromDiscord | <Elegant Beef> actually can we have seqs of seqs in nim? |
20:15:54 | FromDiscord | <clyybber> of course |
20:16:03 | FromDiscord | <Elegant Beef> That removes the has op, then can have a set holding the id pools |
20:16:05 | FromDiscord | <Elegant Beef> or a queue rather |
20:16:19 | FromDiscord | <Elegant Beef> is there a setqueue? π |
20:16:27 | FromDiscord | <clyybber> yeah |
20:16:29 | FromDiscord | <Elegant Beef> im certainly going to make this in my idea now |
20:16:29 | FromDiscord | <clyybber> intset |
20:16:31 | FromDiscord | <clyybber> + seq |
20:16:32 | FromDiscord | <clyybber> maybe |
20:16:36 | FromDiscord | <clyybber> or table |
20:16:41 | FromDiscord | <clyybber> or whatever you want it to be |
20:16:51 | FromDiscord | <Elegant Beef> well table has the hash func which will be more expensive then just accessing the seq |
20:16:59 | FromDiscord | <Elegant Beef> for large numbers atleast |
20:17:28 | FromDiscord | <clyybber> yeah |
20:17:32 | FromDiscord | <clyybber> and its a better idea |
20:17:39 | FromDiscord | <clyybber> to have a proc that gives you new ids |
20:17:45 | FromDiscord | <clyybber> and reuses old ones |
20:17:49 | FromDiscord | <Elegant Beef> Well i say have a queue |
20:17:51 | FromDiscord | <clyybber> if they are not used anymore |
20:18:04 | FromDiscord | <Elegant Beef> que ue up x number of ints at start, when you need more add x more |
20:18:07 | FromDiscord | <Elegant Beef> queue up x number of ints at start, when you need more add x more |
20:18:22 | FromDiscord | <Elegant Beef> When you delete an object remove it's id from the seq and readd to queue |
20:18:31 | FromDiscord | <clyybber> yeah |
20:18:31 | FromDiscord | <Elegant Beef> which is where a setqueue comes in handy |
20:18:52 | FromDiscord | <clyybber> replace queue with intset |
20:18:54 | FromDiscord | <Elegant Beef> Im sure you guys will tear apart my code when i write it |
20:19:27 | * | Vladar quit (Quit: Leaving) |
20:19:30 | FromDiscord | <Elegant Beef> I dont mean that in a self deprecating way |
20:19:32 | Araq | one ingredient is an ID mechanism that is a tuple of (incremental int, generation) |
20:19:47 | FromDiscord | <clyybber> @Elegant Beef pulled beef |
20:20:03 | FromDiscord | <clyybber> Araq: Why generation? |
20:20:24 | Araq | so you can mask out the generation to access component[x] directly |
20:20:44 | Araq | clyybber: to keep track of deleted entities in a most effective way |
20:20:53 | FromDiscord | <Elegant Beef> That doesnt matter |
20:21:02 | FromDiscord | <Elegant Beef> when you delete an entity you clear it's list of components |
20:21:18 | FromDiscord | <Elegant Beef> when you delete a component you remove it from the entity seq |
20:21:26 | FromDiscord | <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:41 | FromDiscord | <Elegant Beef> the components store their index got from add component |
20:21:43 | FromDiscord | <Elegant Beef> for easy access |
20:21:53 | Araq | depends 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:07 | FromDiscord | <exelotl> but that was before {.this:self.} got canned :( |
20:22:08 | FromDiscord | <Elegant Beef> Well when i write mine and share it im sure you can assualt it |
20:22:13 | FromDiscord | <Elegant Beef> Well when i write mine and share it im sure you can assault it |
20:22:16 | Araq | because it enables "weak" references |
20:22:35 | FromDiscord | <Elegant Beef> yea idk what that is |
20:22:48 | Araq | exelotl: it's only deprecated :P |
20:22:50 | FromDiscord | <Elegant Beef> I just try to write clean non redundant code |
20:22:56 | Araq | it's still a thing |
20:22:57 | FromDiscord | <Elegant Beef> "only deprecated" |
20:23:15 | Araq | but we're getting 'with' see my RFC |
20:23:40 | Araq | there is also 'cascade' and others as Nimble packages |
20:25:12 | FromDiscord | <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:37 | FromDiscord | <clyybber> sure |
20:25:47 | FromDiscord | <exelotl> yep |
20:26:23 | FromDiscord | <exelotl> Araq: oh yeah do methods still use dispatch trees? |
20:27:12 | FromDiscord | <clyybber> they use strings |
20:27:17 | FromDiscord | <clyybber> lol |
20:28:04 | FromDiscord | <exelotl> :thonk: |
20:31:03 | Araq | hey |
20:31:19 | Araq | you want better DLL support, you're getting better DLL support |
20:31:31 | Araq | and what are a couple of strstr calls among friends? |
20:32:04 | Araq | PRs are always welcome though |
20:34:26 | FromDiscord | <clyybber> Araq: If one dll has a type different from the other one but named the same it will not work right? |
20:35:06 | Araq | the names are derived from the module name and the nimble package iirc |
20:36:54 | jakob0094 | i 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:24 | jakob0094 | but it allows arbitrary objects as components and does not copy components when looping over them |
20:37:29 | Araq | it's all about optimization though, otherwise you're better off with plain old seqs of objects |
20:37:30 | * | ptdel joined #nim |
20:37:40 | FromDiscord | <Elegant Beef> Question didnt i see a method to iterate over a range lilke [x..y] or something? |
20:38:27 | jakob0094 | well, 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:15 | jakob0094 | involves casting pointers to vars though, which is probably horrible |
20:40:23 | FromDiscord | <clyybber> @Elegant Beef literally x..y |
20:40:32 | FromDiscord | <clyybber> for bruh in x..y: |
20:40:46 | FromDiscord | <Elegant Beef> i thought it was supposed to be in [] |
20:40:52 | FromDiscord | <Elegant Beef> so i was like this is just slicing nothing |
20:42:05 | FromDiscord | <clyybber> nah |
20:42:16 | FromDiscord | <clyybber> .. is the range constructor |
20:42:22 | FromDiscord | <clyybber> or however you call it |
20:42:31 | FromDiscord | <clyybber> @Elegant Beef you can do |
20:42:49 | FromDiscord | <clyybber> for e in someseq[x..y]: |
20:43:05 | FromDiscord | <clyybber> because you can index strings/seqs/arrays using slices/ranges |
20:43:25 | FromDiscord | <Elegant Beef> yea i got that |
20:43:53 | FromDiscord | <exelotl> wow I didn't know you could do that |
20:44:50 | disruptek | yes you did. |
20:44:58 | FromDiscord | <Recruit_main_70007> how can i make all my 4 space width tabs 2 spaced in vscode? |
20:45:17 | FromDiscord | <Elegant Beef> bottom right |
20:45:17 | FromDiscord | <Elegant Beef> https://cdn.discordapp.com/attachments/371759389889003532/677978691745349671/unknown.png |
20:45:34 | FromDiscord | <Elegant Beef> Also how do uploaded images work for IRC, they dont do they? |
20:45:52 | disruptek | especially not the ones discord produces. |
20:45:57 | FromDiscord | <Elegant Beef> Or does it send the discord upload url |
20:46:12 | FromDiscord | <Elegant Beef> *it should send the discord upload url* π |
20:46:14 | Yardanico | yes |
20:46:21 | Yardanico | it does that |
20:46:33 | FromDiscord | <Elegant Beef> Why would disruptek lie to me |
20:46:40 | disruptek | it just doesn't get rendered usefully in the browser. |
20:48:07 | FromDiscord | <clyybber> crtl + is my spirit ~~animal~~ key combination |
20:49:35 | disruptek | that used to be spelled animal^H^H^H^H^H^Hkey |
20:51:45 | FromGitter | <Varriount> Elegant Beef: Didn't you know? disruptek is the embodiment of helpful chaos. It's all there in the name. |
20:52:01 | disruptek | this, pretty much. |
20:52:23 | disruptek | i'm suffering from solitudesfitis today though. |
20:52:26 | FromDiscord | <Elegant Beef> Most of my comments about disruptek are insincere |
20:52:32 | FromDiscord | <Elegant Beef> I know why he'd lie to me |
20:55:26 | * | rockcavera quit (Remote host closed the connection) |
20:59:17 | FromDiscord | <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:33 | FromDiscord | <Elegant Beef> I have spent too much time in C# |
20:59:36 | FromDiscord | <Elegant Beef> π |
21:00:02 | FromDiscord | <oz> There are worst languages. |
21:00:16 | FromDiscord | <Elegant Beef> I mean i like C# so yea |
21:00:23 | FromDiscord | <Elegant Beef> But im using imports like namespaces |
21:00:26 | disruptek | that ndepend demo was impressive. |
21:00:48 | disruptek | shows some value of such semantics... |
21:01:57 | FromDiscord | <Elegant Beef> I guess in nim 1 object per file doesnt work |
21:02:47 | Zevv | That's a recurring pain that will never go away. Every Nim project I do I run into that problem |
21:02:52 | Zevv | how the hell do I split my files |
21:03:00 | disruptek | maybe 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:16 | Zevv | You are soooo meta |
21:03:16 | disruptek | i never have this problem. |
21:03:32 | disruptek | to me it's just layers all the way down. |
21:03:34 | Zevv | no because your files are all empty, right? |
21:03:56 | disruptek | you know that was an early winner of one of those programming contests. |
21:04:20 | Zevv | the quine? |
21:04:42 | FromDiscord | <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:04:56 | disruptek | yeah |
21:05:05 | disruptek | wait, what? |
21:05:08 | FromDiscord | <Elegant Beef> or i can just learn to use nim |
21:05:32 | disruptek | i heard exposed bodies. |
21:05:41 | disruptek | i always get in trouble for bringing up porn in here. |
21:05:50 | disruptek | so, i'm glad this time it was you, first. |
21:06:11 | FromDiscord | <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:21 | disruptek | anyway, why can't we talk about porn? |
21:06:29 | disruptek | i feel like you are all fairly tasteful. |
21:06:34 | disruptek | let me hear your tastes. |
21:06:36 | Araq | stop it |
21:06:51 | Araq | this is where I have to draw the line |
21:07:00 | * | disruptek π’ |
21:07:34 | FromDiscord | <Elegant Beef> disruptek to be even more disrupting you were supposed to say "Why would you insult beef's logic like that" |
21:07:34 | disruptek | you are allowed to import as many files as you want. |
21:07:41 | disruptek | just import your types. |
21:07:48 | FromDiscord | <Elegant Beef> |
21:07:48 | FromDiscord | <Elegant Beef> https://cdn.discordapp.com/attachments/371759389889003532/677984359017611324/unknown.png |
21:08:09 | disruptek | i should say, /just/ import your types. |
21:08:30 | FromDiscord | <Elegant Beef> Huh |
21:08:34 | FromDiscord | <Elegant Beef> There are functions also |
21:08:37 | Zevv | Right - often I end up with a lot of all of the types in one file |
21:08:46 | FromDiscord | <Elegant Beef> Yea which i dislike coming from C# |
21:08:50 | FromDiscord | <Elegant Beef> 1 class per file is the norm |
21:08:52 | disruptek | there are functions, also? |
21:08:55 | Zevv | but mutual recursion in two files is also tricky |
21:09:08 | FromDiscord | <Elegant Beef> well there is the constructor |
21:09:18 | FromDiscord | <Elegant Beef> and will be some base functions for entities |
21:09:37 | Zevv | https://i.imgflip.com/2x3fuf.jpg |
21:09:43 | FromDiscord | <Elegant Beef> I mean i could put them in the ecs file, but that's weird for my brain |
21:09:44 | disruptek | well, maybe they can go there. maybe they cannot. obviously, if they depend on ecs, they cannot. |
21:09:59 | disruptek | yes, this is a weird-brain problem. |
21:10:13 | disruptek | picture chains, venn diagrams, whatever works. |
21:10:24 | FromDiscord | <Elegant Beef> I know i *can* drop them in ECS but since they're functions on entity |
21:10:30 | FromDiscord | <Elegant Beef> it makes no sense to put them there |
21:10:56 | FromDiscord | <Elegant Beef> Well just to progress im going to put them there and cry |
21:10:59 | FromDiscord | <Elegant Beef> Oh and i cry! |
21:11:15 | disruptek | there's no such thing as "functions on entity". |
21:11:38 | FromDiscord | <Elegant Beef> I mean it's a constructor |
21:11:43 | FromDiscord | <Elegant Beef> It creates an entity |
21:11:50 | FromDiscord | <Elegant Beef> So it makes sense to be in the in the entity class |
21:12:01 | disruptek | oop is not a thing. |
21:12:12 | disruptek | when you see oop, i want you to think `oops`. |
21:12:15 | disruptek | ya dig? |
21:12:20 | FromDiscord | <Elegant Beef> lol |
21:12:23 | FromDiscord | <Elegant Beef> OOP isnt a thing |
21:12:24 | FromDiscord | <Elegant Beef> Nice |
21:12:30 | FromDiscord | <Elegant Beef> Then why am i even making objects |
21:12:32 | FromDiscord | <Elegant Beef> π |
21:12:38 | disruptek | i do not know. |
21:13:14 | Zevv | 'object' is a bit of a misnomer |
21:13:19 | disruptek | i no longer believe that oop is even a useful mental model. |
21:13:28 | disruptek | too limiting. |
21:13:29 | FromDiscord | <Elegant Beef> I know they're techincally structs in this case |
21:15:57 | disruptek | the way i want to write software: |
21:16:09 | disruptek | i want to have an over-the-shoulder view of my program. |
21:16:11 | FromDiscord | <oz> But calling them strucs would scare oop programmers away. :) |
21:16:29 | FromDiscord | <oz> But calling them structs would scare oop programmers away. :) |
21:16:33 | disruptek | i want to make a machine to do the work. then i want knobs and dials and buttons on it. |
21:17:09 | disruptek | instead of telling the computer what to do, i want to tell it how to do what i want. |
21:20:18 | FromDiscord | <Elegant Beef> Why even have programmers |
21:20:23 | FromDiscord | <Elegant Beef> Just have the computer do everything |
21:20:27 | FromDiscord | <Elegant Beef> problem solve |
21:20:32 | FromDiscord | <Elegant Beef> ML a nim writer |
21:20:35 | disruptek | yeah, that sounds good. |
21:21:10 | FromDiscord | <treeform> Was `dumpHeapInstances` function removed? How to get it back? |
21:21:28 | disruptek | crap, i just linked this but i forget the footnote. |
21:21:41 | disruptek | i think you have the name wrong. also, remember you need a define set. |
21:22:03 | disruptek | ~dumpnumberofinstances |
21:22:04 | disbot | dumpNumberOfInstances: 11add a -d:nimTypeNames at compilation and call `dumpNumberOfInstances()` at runtime. -- disruptek |
21:23:25 | disruptek | what i'm saying is, i need to build a little distance between me and the task my code is performing. |
21:23:49 | disruptek | i need to create a separation. in that space i will put some basic introspection, logging, monitoring, i/o, and so on. |
21:24:12 | disruptek | that's where we'll lay in the cloud stuff, etc. this is our "kernel". |
21:24:18 | FromDiscord | <Elegant Beef> how does one override a parent's procedure? |
21:24:21 | FromDiscord | <treeform> disruptek thanks! Is this new? |
21:24:30 | disruptek | not as far as i know. |
21:25:06 | disruptek | i do it in golden and my grok tools but i guess i haven't tested it in awhile. |
21:25:27 | disruptek | beef: what's a parent? |
21:25:34 | FromDiscord | <treeform> I guess I had --d:nimTypeNames in my nim file because -d:release used to remove stack traces... |
21:25:45 | FromDiscord | <treeform> but when I started a new project it was not there |
21:25:57 | FromDiscord | <Elegant Beef> a parent object |
21:25:58 | disruptek | aha, yeah; that'll do it. |
21:26:12 | FromDiscord | <Elegant Beef> or do variables only get inherited |
21:26:13 | disruptek | parent type? inheritance? |
21:26:17 | FromDiscord | <Elegant Beef> Yes |
21:26:28 | FromDiscord | <Elegant Beef> I assume only variables are inherited |
21:26:55 | disruptek | methods are used for that, but this is really an area where you should watch your step. |
21:26:58 | disruptek | assume nothing. |
21:27:15 | disruptek | and constantly ask yourself if you wouldn't be better served by a case object. |
21:27:26 | FromDiscord | <Elegant Beef> case object? |
21:27:33 | disruptek | variant type? |
21:27:39 | FromDiscord | <Elegant Beef> uhh |
21:27:43 | FromDiscord | <Elegant Beef> yes that's english |
21:27:52 | FromDiscord | <treeform> disruptek, oh and I do want dumpHeapInstances, that's what dumpNumberOfInstances calls. |
21:28:10 | disruptek | ooh, i didn't even know it was a thing, i think. |
21:28:31 | disruptek | or maybe i decided i wanted whatever the other one does. i dunno. |
21:28:32 | Zevv | does that still exist with --gc:arc? |
21:28:44 | FromDiscord | <treeform> I don't think so. |
21:28:47 | disruptek | i don't know. |
21:29:16 | Zevv | we better first fix all the leaks before we add that back in, otherwise people will complain |
21:29:19 | Zevv | about leaks |
21:29:25 | FromGitter | <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:31 | FromGitter | <kaushalmodi> that's a serious regression |
21:29:42 | FromDiscord | <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:57 | FromDiscord | <treeform> How would I debug memory use with arc hmm... |
21:30:00 | nisstyre | what are these headers in the nim binary for? "0000000000000000 l df *ABS* 0000000000000000 stdlib_osproc.nim.c" |
21:30:13 | nisstyre | I've never seen "*ABS*" before |
21:30:20 | disruptek | kaushalmodi: did it regress from devel to devel? |
21:30:25 | nisstyre | don't see it here either, is it custom? https://github.com/corkami/pics/blob/master/binary/elf101/elf101.pdf |
21:30:38 | nisstyre | Is it for debugging purposes or something? |
21:30:41 | FromGitter | <kaushalmodi> that last downloaded stable I have handy is 1.0.2, and it works fine using that |
21:31:11 | FromGitter | <kaushalmodi> disruptek: Yes, it regressed from devel to devel |
21:31:19 | disruptek | no, 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:51 | disruptek | or, what's the latest you know it to work? |
21:31:59 | FromGitter | <kaushalmodi> may be it broke in last month.. |
21:32:07 | FromGitter | <kaushalmodi> a dumb search reveals this: https://github.com/nim-lang/Nim/pulls?q=is%3Apr+is%3Aclosed+exportc+sort%3Aupdated-desc |
21:32:19 | FromGitter | <kaushalmodi> so looks like few PR's related to exportc happened |
21:32:29 | * | JustASlacker quit (Ping timeout: 272 seconds) |
21:32:39 | FromDiscord | <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:41 | FromDiscord | <treeform> |
21:32:41 | FromDiscord | <treeform> https://cdn.discordapp.com/attachments/371759389889003532/677990623671877682/unknown.png |
21:32:44 | nisstyre | I guess the correct term is "Section" not "header" |
21:32:47 | FromGitter | <kaushalmodi> this looks like the culprit: https://github.com/nim-lang/Nim/pull/13199 |
21:32:50 | disbot | β₯ compiler/ccgtypes: hide exportc proc unless it has dynlib ; snippet at 12https://play.nim-lang.org/#ix=2bJn |
21:32:57 | disruptek | your buddy timothee has been busy. |
21:33:42 | disruptek | how did you figure that out so fast? |
21:33:59 | * | solitudesf quit (Ping timeout: 246 seconds) |
21:34:15 | disruptek | hmm, this was pretty well-reasoned, so we need to figure this out. |
21:34:24 | FromGitter | <kaushalmodi> this is the simplest example: http://ix.io/2bJo/nim |
21:34:30 | disruptek | yeah; i remember this. |
21:34:41 | FromGitter | <kaushalmodi> the C side of SystemVerilog now fails to "see" that exported `hello` proc |
21:34:58 | * | letto quit (Quit: Konversation terminated!) |
21:35:15 | FromGitter | <kaushalmodi> opening an issue .. but don't know how to prove that this is broken |
21:35:24 | FromGitter | <kaushalmodi> as it needs someone to have a SystemVerilog compiler |
21:35:28 | FromGitter | <kaushalmodi> still opening it in any case |
21:35:43 | disruptek | this is a really tricky question. |
21:36:37 | Zevv | treeform: 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:42 | disruptek | i mean, you can prove it by trying to link against it. |
21:36:58 | disruptek | if you can link it, great. we're exporting it. |
21:37:21 | disruptek | your use-case could demand a toggle for this elision, though. |
21:37:56 | FromGitter | <kaushalmodi> disruptek: I have never written in C (so "linking" it will take me some time to figure out) |
21:38:52 | disruptek | i haven't done it, but i expect you can just gcc x.c -o x othernim.o |
21:39:37 | FromGitter | <kaushalmodi> let me look at `nm` outputs between the two .so's |
21:39:57 | disruptek | ah, good idea. |
21:41:55 | FromGitter | <kaushalmodi> woot! |
21:41:58 | FromGitter | <kaushalmodi> I have proof |
21:42:05 | FromGitter | <kaushalmodi> (https://files.gitter.im/nim-lang/Nim/MFAR/image.png) |
21:42:35 | disruptek | wow, that's a great regression to fix. |
21:42:45 | disruptek | nice job. |
21:45:27 | disruptek | maybe we can do introspection by just wrapping types with a macro. |
21:46:26 | disruptek | the macro will bulk up objects and produce other types automatically. |
21:46:58 | disruptek | the we just have an operator to read this data out with the "naked" type used for dispatch. |
21:47:46 | disruptek | like -> or something. |
21:49:06 | disruptek | foo->name, foo->["somename"] |
21:49:28 | * | jakob0094 quit (Quit: Leaving) |
21:50:00 | disruptek | it's not crazy, right? |
21:52:38 | * | mal`` quit (Quit: Leaving) |
21:54:04 | FromGitter | <Varriount> @kaushalmodi Yikes, that's a bad bug |
21:56:48 | FromDiscord | <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:26 | FromDiscord | <treeform> I think am seeing chunks nim gets from the OS... but what is this other memory that os reports? |
21:58:43 | FromDiscord | <Elegant Beef> <https://github.com/beef331/nimcs> here it's hideous |
21:58:44 | FromDiscord | <Elegant Beef> π |
21:58:52 | FromDiscord | <Elegant Beef> Was fun to write though |
21:58:59 | disruptek | the memory doesn't go back to the os, necessarily. |
21:59:05 | FromDiscord | <Elegant Beef> And certainly should use something else to make components |
21:59:15 | FromDiscord | <Elegant Beef> macros most likely |
21:59:41 | FromDiscord | <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:03 | Araq | probably loaded libs |
22:00:04 | FromDiscord | <Elegant Beef> 99% certain it'd break on removal of items cause sequences are weird |
22:00:18 | disruptek | yeah. i expect there's a ton. |
22:01:24 | disruptek | !repo nimcs |
22:01:26 | disbot | https://github.com/beef331/nimcs -- 9nimcs: 11Nim ECS 15 0β 0π΄ |
22:01:38 | FromDiscord | <Elegant Beef> But why |
22:01:40 | disruptek | now we know what to recommend. π |
22:01:55 | FromDiscord | <Elegant Beef> Did you even look at the code? |
22:02:03 | FromDiscord | <Elegant Beef> It's 100% certainly going to explode |
22:02:10 | disruptek | yep. |
22:02:15 | FromDiscord | <Elegant Beef> Remove 1 item and it dies |
22:02:26 | disruptek | removal is a 2.0 feature. |
22:02:45 | FromDiscord | <Elegant Beef> there are no dynamically sized arrays that dont shrink on removal is there |
22:02:53 | disruptek | of course. |
22:03:04 | disruptek | linked lists are a thing. |
22:03:14 | disruptek | okay, not an array, technically. |
22:03:26 | FromDiscord | <treeform> Araq, disruptek you are probably right I found this: |
22:03:27 | FromDiscord | <treeform> |
22:03:27 | FromDiscord | <treeform> https://cdn.discordapp.com/attachments/371759389889003532/677998365073735710/unknown.png |
22:03:38 | FromDiscord | <treeform> does not give me mem break out though |
22:03:51 | FromDiscord | <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:56 | FromDiscord | <Elegant Beef> so the indicies dont get moved around |
22:04:08 | disruptek | 38mb for a gui app strikes me as remarkably lightweight. |
22:04:18 | FromDiscord | <treeform> I want to be able to say look electron uses 1GB while fidget uses only 5M to do the same thing... |
22:04:23 | disruptek | if you think that's a lot, i'm hugely impressed by your fidget. |
22:04:30 | FromDiscord | <treeform> I want it to use less! |
22:04:46 | FromDiscord | <treeform> I stripped down electron app is only like 80MB |
22:04:55 | disruptek | okay, but you cannot treeshake the libs that you don't build. |
22:04:57 | FromDiscord | <treeform> 38 is not that much better then 80 |
22:05:12 | FromDiscord | <Elegant Beef> what's a sharedlist? |
22:05:16 | Araq | well it's a factor of 2 |
22:05:52 | disruptek | honestly, i'm staggered that electron could be only 80mb. |
22:05:59 | disruptek | that's blowing my mind right now. |
22:06:06 | Araq | and 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:33 | Araq | and yeah the 80MB for electron sound wrong to me too |
22:07:20 | FromDiscord | <treeform> http://roryok.com/blog/2017/08/electron-memory-usage-compared-to-other-cross-platform-frameworks/ |
22:07:31 | FromDiscord | <treeform> This guy had it at 68.9MB |
22:07:35 | FromDiscord | <treeform> I had it at 80MB |
22:07:39 | Araq | anyhow, maybe it's the textures you keep around for Unicode rendering |
22:07:43 | FromDiscord | <treeform> electron is not as bloated as we all think... |
22:07:48 | FromDiscord | <treeform> It makes it harder to win! |
22:08:14 | disruptek | c'mon, 20mb for ie11? |
22:08:19 | FromDiscord | <treeform> Araq, I only render the Unicode when I need too. |
22:08:45 | FromDiscord | <treeform> In this app the texture atlas is empty. |
22:08:46 | leorize[m] | @kaushalmodi: use {.dynlib.} if you want a symbol to be exported |
22:08:59 | FromDiscord | <treeform> And its also counted in the 5MB that nim reports... |
22:09:11 | disruptek | i have a hard time taking someone seriously who says their web browser is only consuming 20mb while rendering a page. |
22:09:13 | FromDiscord | <treeform> Nim thinks I only using 5MB |
22:09:32 | FromDiscord | <treeform> disruptek, rendering a page with a single <h1> Hello world on it |
22:09:34 | disruptek | maybe i'm the idiot, though. |
22:09:55 | FromDiscord | <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:02 | FromDiscord | <Elegant Beef> cheek* |
22:10:29 | disruptek | pick the smallest possible set of units. put them in a file. |
22:10:37 | disruptek | create a new file that imports the first. |
22:10:43 | disruptek | goto 1. |
22:11:10 | FromDiscord | <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:23 | FromDiscord | <treeform> Mabye IE 11 did not have time to accumulate cruft. |
22:11:38 | disruptek | i mean, you might be right. |
22:11:53 | disruptek | i could be showing my age. |
22:12:08 | * | mal`` joined #nim |
22:13:53 | Araq | I have 23 tabs open and 40 Chrome processes |
22:14:05 | Araq | taking up 3GB |
22:14:31 | Araq | maybe <h1>Hello world</h1> isn't the best benchmark for its overhead |
22:14:38 | FromDiscord | <treeform> But the tabs have Images and text. |
22:14:50 | FromDiscord | <treeform> Images are huge when unpacked for the GPU to use. |
22:15:09 | disruptek | i run a -march=native build of chromium and all its dependencies, from scratch, according to my hardware and available software. |
22:15:35 | FromDiscord | <treeform> I don't know if 23 Fidget programs full of images and text could beat that? |
22:15:47 | disruptek | it's wickedly fast and still takes a few gigs of memory. |
22:15:50 | FromGitter | <kaushalmodi> leorize[m]: I'll need to change a lot of code for that |
22:15:56 | Araq | 3 tabs of my VSCode take up 300MB |
22:16:02 | FromGitter | <kaushalmodi> so I need to replace `{.exportc.}` with `{.dynlib.}`? |
22:16:19 | FromGitter | <kaushalmodi> or `{.exportc.}` with `{.exportc, dynlib.}`? |
22:16:32 | Araq | the latter if you build an .so |
22:16:41 | FromGitter | <kaushalmodi> ok.. trying that out |
22:17:04 | disruptek | just shared memory is 150meg for chromium. |
22:17:14 | leorize[m] | @kaushalmodi: perks is that it will work on windows |
22:17:40 | FromGitter | <kaushalmodi> leorize: Thanks! That worked! |
22:17:51 | leorize[m] | no, exportc and dynlib |
22:17:52 | FromGitter | <kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e471c90d56ddb68a4a6befe] |
22:18:39 | leorize[m] | yea, the no dynlib but things are exported was a bug |
22:19:00 | leorize[m] | the spec said you need dynlib, but didn't enforce that on *nix |
22:19:33 | leorize[m] | though probably I should PR in a changelog too, given how users might not notice this |
22:19:53 | FromGitter | <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:01 | FromGitter | <kaushalmodi> it will be a pretty serious breaking change |
22:20:16 | FromGitter | <kaushalmodi> It should be in bold or something |
22:20:28 | Araq | agreed |
22:20:41 | Araq | and leorize[m] is right, now it works as it was supposed to work :-) |
22:20:58 | disruptek | nice. |
22:22:56 | * | letto joined #nim |
22:23:03 | FromDiscord | <treeform> I think I can lower the memory use by not using openGL. But using platform native CPU only drawing commands. |
22:23:15 | FromDiscord | <Elegant Beef> hey i now have adding and removing |
22:23:21 | FromDiscord | <Elegant Beef> π |
22:24:05 | FromDiscord | <Elegant Beef> Well 0 clue how performant this is |
22:24:33 | Araq | treeform: fwiw my NimEdit had comparable overhead with "Aporia" (a GTK application) too |
22:24:45 | FromGitter | <kaushalmodi> Araq, leorize[m]: Thanks. Thankfully this change is backward compatible too |
22:24:46 | Araq | around 20MB |
22:25:02 | FromGitter | <kaushalmodi> now I need to `sed` few dozen files .. |
22:25:04 | Araq | and I blamed SDL2 |
22:25:17 | FromDiscord | <Elegant Beef> apparently writing roughly 4,000,000 strings to the console takes some time |
22:25:22 | Araq | kaushalmodi: use nimgrep instead |
22:25:50 | FromDiscord | <Elegant Beef> Well with 400k it takes a second roughly per tick |
22:25:53 | leorize[m] | @Elegant Beef: that's pretty much expected |
22:26:03 | FromDiscord | <Elegant Beef> That was more of a joke then anything |
22:26:22 | FromGitter | <kaushalmodi> Araq: I never used nimgrep because I am comfortable with sed and rg |
22:26:23 | FromDiscord | <Elegant Beef> Not like i have a very viable test of this ecs considering i lack something to run it in |
22:26:30 | FromGitter | <kaushalmodi> will have a look at that soon |
22:29:16 | FromDiscord | <Elegant Beef> So for the components, i think using a macro to make them makes more sense but idk |
22:32:00 | disruptek | probably, yeah. |
22:32:05 | * | jjido joined #nim |
22:33:07 | FromDiscord | <treeform> Araq, wow GTK + SDL + your app is only 20MB? |
22:33:15 | FromGitter | <kaushalmodi> leorize: So when would one use just `.exportc.`? |
22:33:42 | FromGitter | <kaushalmodi> If the symbol doesn't get exported when just that pragma is used, when what's the point? |
22:33:50 | FromGitter | <kaushalmodi> s/when/then |
22:34:27 | leorize[m] | I do know an use case for the compiler codegen |
22:34:56 | FromGitter | <kaushalmodi> ok (that's out of my reach then :) ) |
22:35:08 | leorize[m] | compiler procs are exportc-ed then called via codegen by inlining the exported name |
22:35:52 | FromDiscord | <treeform> Araq, Nimx is also 35mb... |
22:36:03 | FromDiscord | <treeform> I need to figure out how to get it to only 20mb. |
22:36:10 | FromDiscord | <treeform> get my thing* |
22:36:27 | * | solitudesf- quit (Ping timeout: 272 seconds) |
22:36:55 | disruptek | treeform: how does this 35mb compare to other nim guis? |
22:39:43 | FromGitter | <kaushalmodi> leorize[m]: I couldn't help think.. shouldn't exportc implicitly do dynlib too? |
22:40:02 | FromGitter | <kaushalmodi> for the few cases where that should not happen, that's where you require a second pragma |
22:40:37 | FromGitter | <kaushalmodi> now I have a huge diff of 200+ changes that changes `{.exportc.}` to `{.exportc, dynlib.}` |
22:40:53 | disruptek | argh. π |
22:43:06 | leorize[m] | @kaushalmodi: that doesn't sound too bad, though adding yet another pragma might not be too appealing |
22:44:34 | FromDiscord | <clyybber> disruptek: (lol)[https://github.com/ulfjack/ryu/blob/master/third_party/double-conversion/test/cctest/gay-shortest-single.h] |
22:46:10 | FromGitter | <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:34 | FromGitter | <kaushalmodi> essentially default exportc to do global exports as before and introduce a new pragma to specify local exports |
22:46:44 | disruptek | what am i looking at? |
22:46:56 | * | marmotini_ quit (Remote host closed the connection) |
22:47:34 | disruptek | a crappy c header? |
22:47:56 | FromDiscord | <clyybber> a funny file name |
22:48:04 | FromDiscord | <clyybber> at least when you are 10-yo |
22:48:13 | disruptek | ah |
22:48:26 | disruptek | gay is the author of another algo. |
22:48:38 | disruptek | isn't he? |
22:48:47 | FromDiscord | <clyybber> yeah, think so |
22:48:54 | disruptek | you think he's gay? |
22:49:41 | FromGitter | <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:44 | disbot | β₯ [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:12 | FromDiscord | <clyybber> disruptek: Fo ssure |
22:54:38 | FromDiscord | <clyybber> disruptek: Btw, I'm porting ryus table generation code to nim |
22:54:44 | FromDiscord | <clyybber> so we can generate the tables at compile time |
22:55:19 | disruptek | this is the generic version, right? |
22:55:22 | Araq | btw my concern for code size was serious |
22:55:33 | FromDiscord | <clyybber> disruptek: Nope |
22:55:51 | FromDiscord | <clyybber> Araq: Ok, I'm still doing this. Maybe I get it managable |
22:55:52 | Araq | would be a shame to add 4kb for $myfloat |
22:55:56 | FromDiscord | <clyybber> Yeah |
22:55:58 | FromDiscord | <clyybber> I agree |
22:56:42 | disruptek | that's why the one that goes in has to be the nim one. |
22:56:57 | FromDiscord | <clyybber> hmm |
22:57:16 | FromDiscord | <clyybber> maybe its best we port a non-microoptimized to hell algorithm |
22:57:22 | FromDiscord | <clyybber> that accomplishes the same task |
22:57:29 | disruptek | that's what leorize is doing. |
22:57:37 | FromDiscord | <clyybber> no? |
22:57:43 | disruptek | afaik, yes. |
22:57:43 | FromDiscord | <clyybber> or is he |
22:57:52 | disruptek | i've tried to explain this. |
22:57:55 | FromDiscord | <clyybber> I thought he was trying to reimplement ryu from scratch |
22:58:03 | disruptek | he is. |
22:58:23 | disruptek | he's trying to create the idiomatic implementation. |
22:58:42 | FromDiscord | <clyybber> glhd :p |
22:58:48 | FromDiscord | <clyybber> *glhf |
22:58:56 | FromDiscord | <Elegant Beef> good luck have dumb is nicer |
22:59:05 | disruptek | well; because it has to slot into the compiler. |
22:59:15 | FromDiscord | <clyybber> get low high dumb |
22:59:41 | FromDiscord | <clyybber> disruptek: I know. I'm working on nimifying it too |
22:59:52 | FromDiscord | <clyybber> And I can remove the tables in this version too |
23:00:01 | FromDiscord | <clyybber> and replace them by runtime calculations |
23:00:06 | disruptek | okay. sorry if i gave you the wrong idea. |
23:00:09 | FromDiscord | <clyybber> its still gonna be faster than what we have I think |
23:00:24 | FromDiscord | <clyybber> disruptek: ? What wrong idea? |
23:00:51 | disruptek | i mean about what we were trying to do with the ports. |
23:00:56 | FromDiscord | <clyybber> Ah sure |
23:01:11 | FromDiscord | <clyybber> I think its just easier working from messy but working to clean and working |
23:01:26 | FromDiscord | <clyybber> I'm a cleanup guy |
23:01:32 | FromDiscord | <clyybber> it makes me feel all cozy |
23:01:43 | FromDiscord | <clyybber> maybe I should be janitor |
23:01:49 | FromDiscord | <Elegant Beef> You be the janitor and ill be the guy that dumps the cola on the ground |
23:02:01 | FromDiscord | <clyybber> haha |
23:02:02 | FromDiscord | <Elegant Beef> My shitty ECS for instance π |
23:02:12 | FromDiscord | <Elegant Beef> Go add macros and make it clean |
23:02:14 | disruptek | i 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:19 | FromDiscord | <Elegant Beef> Ill be here with more cola |
23:03:14 | * | marmotini_ joined #nim |
23:03:15 | FromDiscord | <clyybber> disruptek: Why do you think we can beat ulfjack? |
23:03:44 | disruptek | that's not the point. |
23:04:01 | disruptek | the point is an idiomatic impl that meets the needs of the compiler and runtime. |
23:04:11 | FromDiscord | <clyybber> yeah |
23:04:24 | disruptek | no one wants to have to touch this code for a long time. |
23:04:38 | FromDiscord | <clyybber> its not like you can't arrive at an idiomatic implementation with my approach |
23:04:42 | disruptek | so let's make it so dead stupid nim that it never needs fixing. |
23:04:48 | FromDiscord | <clyybber> in fact that *is* what I am trying to do |
23:05:18 | disruptek | okay; but you have to admit that you're starting from the wrong end of the field. |
23:05:27 | FromDiscord | <clyybber> no |
23:05:40 | FromDiscord | <clyybber> I'll show you :p |
23:05:52 | disruptek | you're on. |
23:06:02 | FromDiscord | <clyybber> better than hacking at it just to overfit to the tests |
23:06:31 | * | zickzackv quit (Ping timeout: 260 seconds) |
23:06:37 | FromDiscord | <clyybber> its also more fun |
23:06:46 | FromDiscord | <clyybber> detecting complicated patterns |
23:06:50 | FromDiscord | <clyybber> and simplifying them |
23:07:04 | disruptek | yes, those patterns may not be a means to the idiomatic ends. |
23:07:15 | disruptek | you could be optimizing a quirk of the c impl that doesn't exist in nim. |
23:07:27 | disruptek | so you're wasting your time, or misvaluing it at least. |
23:07:39 | FromDiscord | <clyybber> we'll see |
23:07:51 | disruptek | in any event, you're thinking about the problem with the wrong abstractions. |
23:08:00 | disruptek | ie. the ones we care about are the nim ones. |
23:08:05 | disruptek | but you're mired in c. |
23:08:12 | * | marmotini_ quit (Ping timeout: 265 seconds) |
23:08:35 | FromDiscord | <clyybber> C vs Nim semantics don't change a single thing about maths |
23:08:57 | disruptek | no, but the point is not math. |
23:09:06 | FromDiscord | <clyybber> but thats whats behind the curtains |
23:09:08 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzzβ¦) |
23:09:11 | disruptek | the point is to paint a picture using the same palette. |
23:09:17 | FromDiscord | <clyybber> everything else is just fluff |
23:09:56 | FromDiscord | <clyybber> disruptek: No you change the palette |
23:10:09 | FromDiscord | <clyybber> then you notice with the new palette some faces are now the same color |
23:10:11 | disruptek | i hate that. |
23:10:13 | FromDiscord | <clyybber> then you join them |
23:10:18 | FromDiscord | <clyybber> in the end |
23:10:36 | FromDiscord | <clyybber> you are left with the bare minimum differently colored faces required to get the idea across |
23:11:23 | disruptek | you're assuming that their solution is part of the same graph of ours. |
23:11:30 | FromDiscord | <clyybber> well |
23:11:34 | FromDiscord | <clyybber> they wrote a paper |
23:11:36 | disruptek | that's just immediately, obviously, wrong. |
23:11:38 | FromDiscord | <clyybber> they proved it correct |
23:11:55 | disruptek | yes, but how we arrive at the same "correct" result is our problem. |
23:12:16 | FromDiscord | <clyybber> they proved the implementation correct |
23:12:18 | disruptek | we might benefit from writing more nim as if it's an advertisement for the language. |
23:12:19 | FromDiscord | <clyybber> not the specification |
23:13:16 | disruptek | it 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:38 | FromDiscord | <clyybber> how do you verify that contract? |
23:13:40 | FromDiscord | <clyybber> through tests |
23:13:55 | disruptek | fine. |
23:14:01 | disruptek | so what? |
23:14:03 | FromDiscord | <clyybber> and I do not want to change the underlying math |
23:14:51 | disruptek | look, when you practice animal taxidermy and the animals are still alive and sway their legs and shit... |
23:15:05 | FromDiscord | <clyybber> ok so your point |
23:15:07 | FromDiscord | <clyybber> is |
23:15:12 | FromDiscord | <clyybber> start with a broken implementation |
23:15:14 | FromDiscord | <clyybber> lol |
23:15:14 | disruptek | you learn pretty quick that it helps to sew the leg on wear a previous leg was already pre-existing. |
23:15:31 | disruptek | these bits mate up nice. |
23:15:44 | FromDiscord | <clyybber> eh |
23:15:47 | disruptek | we need hot nim-on-nim action here. |
23:16:15 | FromDiscord | <clyybber> we need nim based on existing working code and maths |
23:16:18 | FromDiscord | <clyybber> and algorithms |
23:16:24 | FromDiscord | <clyybber> which are proven to be correct |
23:16:26 | disruptek | which just means passing tests. |
23:16:30 | FromDiscord | <clyybber> not nim based on overfitting tests |
23:16:41 | FromDiscord | <clyybber> disruptek: No, because the tests don't test everything |
23:16:56 | FromDiscord | <clyybber> also I think its easier to arrive at the desired outcome by going top-down |
23:17:00 | FromDiscord | <clyybber> rather than bottom-up |
23:17:02 | disruptek | i think i can take my chances on this one. |
23:17:37 | disruptek | you forget that i've seen the code, maybe. |
23:28:38 | leorize[m] | well it's certainly possible to create idiomatic ryu from c-ryu |
23:28:46 | * | sekao joined #nim |
23:29:10 | leorize[m] | my nim-ryu is a sort of personal research project so I could grasp the inner workings of floats better |
23:29:39 | leorize[m] | a nice looking and documented implementation is just a side effect |
23:36:38 | disruptek | i think i finally understand convertors. |
23:36:46 | * | marmotini_ joined #nim |
23:37:06 | disruptek | they give you a way to grandfather an interface used by an earlier type. |
23:37:26 | disruptek | so you can evolve your types without losing functionality. |
23:39:26 | * | abm joined #nim |
23:43:16 | disruptek | is type versioning a good idea? |
23:43:23 | * | sekao quit (Remote host closed the connection) |
23:52:33 | Araq | it has "type" in it, so yeah |
23:53:16 | FromGitter | <gogolxdong> How to make nlvm targeting x86? |
23:54:49 | Araq | no idea |
23:57:33 | dom96 | Araq, have you ever looked into any emscripten segfaults? |