| 00:00:02 | * | junland quit (Quit: %ZNC Disconnected%) |
| 00:02:49 | * | junland joined #nim |
| 00:22:22 | * | abm joined #nim |
| 00:32:03 | * | abm quit (Ping timeout: 248 seconds) |
| 00:41:01 | * | MrAxilus[m] left #nim ("Kicked by @appservice-irc:matrix.org : Idle kick: User has been idle for 30+ days.") |
| 00:42:31 | * | lqdev[m] quit (Quit: Idle kick: User has been idle for 30+ days.) |
| 01:18:28 | FromGitter | <Varriount> @bevo009 No idea |
| 01:32:44 | * | chimez joined #nim |
| 01:34:13 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 01:35:14 | * | laaron joined #nim |
| 01:41:47 | * | chimez quit (Ping timeout: 244 seconds) |
| 01:47:04 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 01:48:00 | * | laaron joined #nim |
| 03:18:05 | leorize[m] | shashlick: only the latest pre release of neovim can run nim.nvim |
| 03:39:32 | shashlick | 0.3.8 won't work? |
| 03:52:06 | shashlick | nope, crashes in pre-release also |
| 03:55:57 | leorize | I used this one: https://github.com/neovim/neovim/releases/tag/nightly |
| 04:03:51 | shashlick | yep, no luck on windows, it crashes |
| 04:04:12 | shashlick | g d works nicely, even autocomplete works but crashes pretty fast |
| 04:19:04 | leorize[m] | weird, guess it'll take sometimes until windows neovim is stable enough |
| 04:20:17 | * | dddddd quit (Remote host closed the connection) |
| 04:32:01 | shashlick | ya, crashes for random stuff, buffer delete, etc. |
| 04:33:10 | leorize | there's also gO and :NimReferences as newly added features |
| 04:33:44 | leorize | guess it's (potentially) a reason to port nim.nvim to vim8 :p |
| 04:34:04 | leorize | not that vim-lsp + nimlsp hasn't provided that feature |
| 05:04:04 | zacharycarter | morning |
| 05:09:31 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 05:09:55 | * | hoijui joined #nim |
| 05:11:38 | zacharycarter | shashlick: I think if you re-approach feud once the new runtime is working - you won't have these issues with threads |
| 05:12:03 | zacharycarter | although with plugins / nimrtl and hcr I can't say |
| 05:14:05 | * | laaron joined #nim |
| 05:14:32 | shashlick | well, i have a few options - ditch it altogether since dll support is not there at all |
| 05:14:53 | shashlick | a stable new runtime is at least a few months away even best case |
| 05:15:03 | shashlick | and i've been burned badly by living on the edge |
| 05:15:38 | shashlick | second option is to throw out dlls altogether and make one big binary |
| 05:16:21 | shashlick | which means no more plugins, scripting, what have you |
| 05:16:25 | zacharycarter | you could use nimscript |
| 05:16:30 | zacharycarter | like I am |
| 05:16:48 | zacharycarter | nimble does this and so does the editor Araq built (nimedit) |
| 05:17:21 | shashlick | well, i removed nimscript from nimble since it is a pain keeping it in sync with the compiler dependency |
| 05:17:31 | shashlick | now nimble just runs nim e behind the scenes |
| 05:17:43 | shashlick | c2nim has its own copy of the compiler code (what's required) |
| 05:18:09 | shashlick | so i'm not a fan of building in nimscript since the compiler is a moving target |
| 05:18:34 | shashlick | which brings me to lua and co, and i'm least interested in doing that |
| 05:18:37 | zacharycarter | I guess it's not that painful for me - when a new version of Nim comes out I just copy the stdlib for that version into my project |
| 05:18:58 | Araq | actually, the compiler APIs are ok since 0.20 or so, however Nimble had to be "buildable" by 0.18 or something |
| 05:19:09 | zacharycarter | well, there's - https://github.com/jangko/razcal - which looks interesting |
| 05:19:13 | Araq | and so it was full of 'when' statements |
| 05:19:28 | shashlick | Araq - are you back from vacation? |
| 05:19:44 | Araq | yeah |
| 05:19:54 | shashlick | i need your thoughts on this before i throw in the towel |
| 05:20:09 | Araq | don't throw in the towel please :-) |
| 05:20:30 | shashlick | so ever since 0.20.x, the plugin system i built for feud (text editor) doesn't work anymore |
| 05:21:01 | shashlick | i suspect it is because the dll's gc's are messing up the main exe's gc |
| 05:21:18 | shashlick | even with boehm, this is happening, so i suspect it was because i got lucky in 0.19.x |
| 05:21:34 | Araq | ok. well we fixed the DLL support quite a bit for HCR |
| 05:21:37 | shashlick | effectively, i cannot use nim dlls from a nim exe and pass objects back and forth |
| 05:22:00 | shashlick | and nimrtl doesn't work either, since i am using threads as well |
| 05:23:00 | Araq | huh? |
| 05:23:18 | shashlick | docs claim that nimrtl doesn't support threads |
| 05:23:26 | shashlick | and i did try it out but it crashed just the same |
| 05:23:34 | shashlick | i get gcasserts with standard gc |
| 05:23:58 | Araq | bah, I thought we fixed that years ago :P |
| 05:24:15 | Araq | and forgot to update the docs... |
| 05:24:30 | shashlick | build is a bit more stable with 32-bit but doesn't work at all with 64-bit |
| 05:25:32 | shashlick | but i've spent 2 months fighting with 0.20.x |
| 05:25:52 | shashlick | anyway, if you have any ideas, i'm all ears |
| 05:26:03 | Araq | well I was away for 2 weeks, so how is that possible? |
| 05:26:16 | Araq | you are on Windows, right? |
| 05:26:19 | shashlick | ever since 0.20.x came out |
| 05:26:21 | shashlick | yes Windows |
| 05:26:37 | zacharycarter | wb btw Araq |
| 05:26:52 | shashlick | i've been trying to port to it since then - i started the SharedSeq project to avoid the seq[string] across threads |
| 05:26:58 | zacharycarter | I thought you had been on vacation, but didn't want to sound dumb by welcoming you back when you'd been here all along :P |
| 05:28:37 | Araq | I couldn't code much but I got the foundation for "incremental compilation" |
| 05:28:58 | zacharycarter | sweet! |
| 05:29:28 | Araq | so far the design works out, bugs are easy to fix. However, it always starts with the very easy bugs so ... |
| 05:29:55 | zacharycarter | :P |
| 05:30:31 | shashlick | anyway, got to go to bed and am on vacation for 10 days, but if you have any thoughts on how to get feud stable, let me know |
| 05:31:09 | Araq | well, we shall fix threads with DLLs, can't be hard |
| 05:31:24 | shashlick | how about multiple GCs? |
| 05:31:32 | Araq | what do you mean? |
| 05:31:52 | shashlick | passing objs managed by GC in main exe to dll procs which have its own GC |
| 05:32:18 | shashlick | nimrtl crashes just the same |
| 05:35:24 | leorize[m] | nimrtl manages the gc in dll situations |
| 05:36:32 | Araq | I'm afraid I don't understand, but have some sleep please |
| 05:38:17 | Araq | shashlick: also, I thought removing the compiler dep from Nimble means Nimble builds are faster and Nimble becomes easier to develop with faster iteration times |
| 05:38:21 | Araq | :-) |
| 05:40:09 | shashlick | That too absolutely |
| 05:40:26 | shashlick | Will talk later |
| 05:40:31 | shashlick | Welcome back |
| 05:42:40 | FromGitter | <arnetheduck> welcome back Araq ;) for ast nodes, which of n.sons[^1], n[^1] and n.lastSon is the preferred one? ie is ast meant to behave like a seq or was that just an experiment? |
| 05:44:40 | Araq | I don't know, I like 'n.lastSon' best for the planned "packed AST" refactoring |
| 05:46:44 | FromGitter | <arnetheduck> what's the packed ast refactoring? |
| 05:46:56 | zacharycarter | krux02 - you know what would be awesome? a version of your pattern matching lib for the vm :) |
| 05:47:19 | zacharycarter | one that works with PNodes instead of NimNodes |
| 05:49:44 | FromGitter | <arnetheduck> bummer, I find lastson the ugliest, mostly because it's not generic |
| 05:50:00 | Araq | arnetheduck: a different IR, optimized for few allocations, few pointers, easy to mmap() |
| 05:50:33 | Araq | but it's a year away. so ok, just use n[^1], we can always detect the pattern later |
| 05:50:47 | FromGitter | <arnetheduck> a smallseq would fix 90% mallocs |
| 05:51:57 | Araq | probably but how do you write a recursive smallseq? is that even possible |
| 05:52:28 | * | solitudesf joined #nim |
| 05:52:29 | Araq | ah never mind, |
| 05:52:44 | Araq | it works if you keep the PNode a 'ref' |
| 05:53:10 | FromGitter | <arnetheduck> yup |
| 05:55:34 | FromGitter | <arnetheduck> I sometimes wonder though if llvm devs regret their pointer-heavy IR |
| 05:58:01 | * | Trustable joined #nim |
| 06:00:36 | Araq | how does llvm do memory management anyway? never found good docs about it |
| 06:00:44 | Araq | pool based allocation? |
| 06:03:23 | zacharycarter | I'm using `parser.parseString` to implement a `setResult` for a type I defined. Is there a way to include identifiers in the string and have their values interpolated? |
| 06:04:37 | zacharycarter | ah I can just use strformat cool |
| 06:05:21 | Araq | ok...? I think you don't want parser.parseString |
| 06:05:34 | Araq | I use ast.newTree but I agree that it can suck |
| 06:05:50 | zacharycarter | hmm okay |
| 06:07:06 | FromGitter | <arnetheduck> mostly smallvector/malloc + linked lists.. but they also have a few instances of some pretty custom bit scheme that uses low bits of pointers for special stuff (because alignment) |
| 06:10:10 | * | nsf joined #nim |
| 06:29:28 | FromGitter | <Riderfighter> Hello everyone |
| 06:35:27 | * | solitudesf quit (Ping timeout: 245 seconds) |
| 06:36:57 | zacharycarter | hi Riderfighter :) |
| 06:37:11 | zacharycarter | hmm - if I"m using ast.newTree - how do I make a new ident node? |
| 06:38:33 | zacharycarter | oh - newIdentNode - nevermind |
| 06:40:05 | * | laaron quit (Remote host closed the connection) |
| 06:48:07 | * | nif_ quit (Quit: ...) |
| 06:48:16 | * | nif joined #nim |
| 06:49:27 | * | laaron joined #nim |
| 06:50:41 | * | laaron quit (Client Quit) |
| 06:51:08 | * | laaron joined #nim |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:04:38 | * | gmpreussner joined #nim |
| 07:06:19 | zacharycarter | what am I supposed to provide for TLineInfo when messing with AST nodes in setResult in the VM |
| 07:07:22 | Araq | some n.info you might already have |
| 07:07:27 | Araq | it doesn't matter much |
| 07:07:58 | zacharycarter | okay thanks |
| 07:12:32 | * | laaron quit (Remote host closed the connection) |
| 07:14:12 | * | laaron joined #nim |
| 07:16:57 | FromGitter | <mratsim> @Araq @arnetheduck Recursive SmallVector? Anyway, I have small vectors as a recurrent need for Tensor Metadata so you can use that: https://github.com/numforge/laser/blob/master/laser/dynamic_stack_arrays.nim#L6-L19 |
| 07:18:44 | FromGitter | <arnetheduck> a smallvec can grow beyond its static size by falling back on heap |
| 07:22:09 | * | solitudesf joined #nim |
| 07:22:13 | FromGitter | <mratsim> ah right, well not in my case so :p |
| 07:22:52 | FromGitter | <arnetheduck> then it's not a smallvec ;) |
| 07:23:23 | FromGitter | <mratsim> btw, I think there is an issue with intsets, AFAIK they are used pervasively, but everywhere I saw intset used in my codebases, including nimbus, intset operations were a bottleneck |
| 07:23:51 | FromGitter | <mratsim> pervasively in the compiler* |
| 07:25:21 | FromGitter | <arnetheduck> when it comes top optimization, the nim compiler often sees the trees but not the forest :) |
| 07:26:38 | FromGitter | <mratsim> Besides ropes, I didn't notice any data structure optimization in teh past years. |
| 07:27:20 | FromGitter | <arnetheduck> and ropes are usually not that good of an idea, too much pointer chasing.. hopefully they'll go away |
| 07:28:25 | FromGitter | <mratsim> I'm curious iwith @narimiran experiments with cityhash/xxhash/murmurhash to see if they allow HashSets of ints to completely overtake intsets |
| 07:29:10 | FromGitter | <arnetheduck> google has a bunch of hash sets like that, sparse and not.. I'd probably look there for inspiration |
| 07:31:40 | * | Trustable quit (Remote host closed the connection) |
| 07:36:31 | FromGitter | <mratsim> I wonder if one day, there will be so much Nim code on Google/StackOverflow that people will start copy-pasting Nim code instead of actually developing code (like what's done in Entreprise Java). Would that be what success looks like :D |
| 07:36:50 | * | nsf quit (Quit: WeeChat 2.4) |
| 07:38:05 | FromGitter | <Riderfighter> I think that would surpass success :D |
| 08:09:01 | * | nsf joined #nim |
| 08:15:38 | FromGitter | <Varriount> @mratsim integer sets specifically, or bit sets in general? |
| 08:15:58 | FromGitter | <mratsim> intsets, I don't think we have bitsets in the stdlib |
| 08:16:18 | FromGitter | <mratsim> I never used the builtins bitfield, even in C I don't think people are using those |
| 08:17:22 | FromGitter | <Varriount> Ah good. I was about to say, if bit sets are proving to be a ubiquitous bottleneck, then we have quite a large problem. |
| 08:19:25 | leorize[m] | @mratsim isn't the `set[T]` a bitset? |
| 08:20:12 | leorize[m] | at least that's how it's implemented |
| 08:20:40 | FromGitter | <mratsim> ah right you meant the builtin sets |
| 08:21:16 | FromGitter | <mratsim> no they are fast except for `contains` when you can have more than 10 elements I guess |
| 08:21:40 | FromGitter | <mratsim> because you need to iterate over each. |
| 08:22:32 | FromGitter | <mratsim> I was thinking of that when you saif bitset: https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-bitsize-pragma |
| 08:28:32 | * | krux02_ quit (Remote host closed the connection) |
| 09:10:52 | zacharycarter | hmm there has to be a better way than using newTree - I have a node tree that is over 3000 lines to build |
| 09:13:22 | zacharycarter | Araq: any ideas on how I might ease this ^ |
| 09:20:39 | Zevv | zacharycarter: what is your code? |
| 09:21:06 | Zevv | .OC |
| 09:24:02 | zacharycarter | well - there's a struct in nuklear that I'm trying to include in an object I'm using in the VM |
| 09:24:34 | zacharycarter | I need to implement a custom setResult for that type, but the nuklear struct when passed into astalgo.debug ends up taking up most of 3000 lines |
| 09:25:20 | zacharycarter | it would suck very much / probably not be worth trying to construct it using newTree - https://gist.github.com/zacharycarter/d8c445d5204573d6c4508a001690ac8a |
| 09:25:31 | zacharycarter | might be enough of a deterrant to consider using lua / moonscript instead of nimscript if there's no easy way |
| 09:25:43 | zacharycarter | considering I'll probably have quite a few types to do this for |
| 09:26:28 | Zevv | oh you're in deeper then i thought :/ I assumed you were merely doing macro stuff |
| 09:28:01 | FromGitter | <Riderfighter> gosh I feel so advanced right now, I just made a proc that looks like `proc testT: uint16|int16|byte () =` |
| 09:28:04 | FromGitter | <alehander42> eh in this case if parseString works for you, i think its fine |
| 09:28:26 | FromGitter | <alehander42> @Riderfighter much generics :P |
| 09:28:29 | zacharycarter | I can try with parseString - I'll see if I can get that work - it was working with a simple example |
| 09:28:36 | zacharycarter | Zevv: nope :P |
| 09:28:59 | Zevv | zacharycarter: i tried to go there once, but didn't like it too much. never went back |
| 09:29:05 | FromGitter | <Riderfighter> @alehander42 generics are actually so nice |
| 09:29:47 | Zevv | riderfighter: its just duck typing for typed languages :) |
| 09:30:57 | FromGitter | <Riderfighter> Zevv: I'm actually so hyped right now because of it, I don't usually use cool stuff like this :D |
| 09:34:50 | FromGitter | <Riderfighter> I've been working hard to make my KDF look and feel like it's made by the nimcrypto lib guy and I'm ngl with this syntax nobody will even feel a difference haha :D |
| 09:37:44 | * | stefanos82 joined #nim |
| 09:39:20 | Zevv | riderfigher: url? |
| 09:41:29 | FromGitter | <Riderfighter> For which, my current thing or the nimcrypto guy lib? |
| 09:47:20 | FromGitter | <Riderfighter> well nimcrypto is here https://github.com/cheatfate/nimcrypto |
| 09:47:26 | FromGitter | <Riderfighter> im still working on my thing |
| 09:47:31 | FromGitter | <Riderfighter> I'll send a snippet in a sec |
| 09:48:33 | * | MH026 quit (Remote host closed the connection) |
| 09:50:15 | Zevv | yeah I know nimcrypto. But I was wondering how your code looked to mimic that :) |
| 09:51:25 | FromGitter | <Riderfighter> haha |
| 09:51:27 | FromGitter | <Riderfighter> well uhm |
| 09:52:24 | FromGitter | <Riderfighter> i'm still trying my best, so bear with me but here is my current implementation(https://dsh.re/e13d6) I'm trying my best to support their stuff and make it have similar syntax/overloads |
| 09:52:34 | * | clyybber joined #nim |
| 09:53:37 | FromGitter | <Riderfighter> I just broke that snippet, so ignore all the errors |
| 09:58:15 | Zevv | What is the common thing sha1|sha2|keccak|blake2|ripemd all share? |
| 09:58:48 | FromGitter | <Riderfighter> Probably HashType |
| 09:58:50 | FromGitter | <Riderfighter> :P |
| 09:58:52 | Zevv | right :) |
| 09:59:12 | FromGitter | <Riderfighter> I'm still debugging haha |
| 09:59:13 | Zevv | proc evpKDF[T: HashType]() |
| 10:00:39 | Zevv | and: no copyMem on js backend |
| 10:01:01 | FromGitter | <Riderfighter> oh |
| 10:01:03 | FromGitter | <Riderfighter> uhhh |
| 10:01:15 | FromGitter | <Riderfighter> var keyOut, var ivOut it is ! |
| 10:01:29 | FromGitter | <arnetheduck> key insight for any hashing function API is that they reduce variable-length data to a fixed size output |
| 10:01:45 | FromGitter | <arnetheduck> unlike say compression or encryption |
| 10:02:28 | * | lqdev[m] joined #nim |
| 10:02:50 | FromGitter | <Riderfighter> Wait I just realized is `HashType` even a command thing for sha1|sha2|keccak|blake2|ripemd, I don't actually see them inherit it |
| 10:03:15 | FromGitter | <Riderfighter> all are based off their own context which is an object |
| 10:04:52 | FromGitter | <Riderfighter> w/e I gotta go for right now I'll try and solve that later |
| 10:05:01 | FromGitter | <Riderfighter> Thank you guys for the insight :D |
| 10:08:28 | Zevv | and fromHex($hash.finish()) is kind of taking the long road |
| 10:20:29 | clyybber | Hey Araq, you're back? Did you see my comment https://github.com/nim-lang/Nim/pull/11248 ? |
| 10:21:00 | clyybber | To make =move work, the object and tuple constructors have to be reworked |
| 10:21:26 | * | dddddd joined #nim |
| 10:26:03 | FromDiscord_ | <Avatarfighter> Zevv: that is noted, I’ll fix it when I get home |
| 10:27:04 | * | Vladar joined #nim |
| 10:46:21 | * | sagax quit (Ping timeout: 244 seconds) |
| 10:49:27 | FromGitter | <zacharycarter> I think parseString could work for producing custom setResult procs, but the other direction might be problematic for objects with a lot of fields. |
| 10:49:50 | FromGitter | <zacharycarter> Might be a killer |
| 10:50:01 | FromGitter | <zacharycarter> For the nimscript idea |
| 10:51:47 | * | krux02 joined #nim |
| 10:53:17 | FromGitter | <zacharycarter> Maybe there is a way to use macros for this? I don't know... |
| 10:53:41 | FromGitter | <zacharycarter> I'm more than open to suggestions |
| 11:58:46 | FromGitter | <mratsim> @SolitudeSF workaround your macro/generic issue: https://github.com/nim-lang/Nim/issues/11877#issuecomment-517997076 |
| 12:00:33 | solitudesf | ah, i saw that i have symbols and replaced some of them, but gave up since it didnt seem crucial. |
| 12:00:35 | solitudesf | thanks |
| 12:00:52 | solitudesf | is this a duplicate then? |
| 12:02:05 | FromGitter | <mratsim> My bug is a RFC, yours is either "WORKS as intended" or a bug |
| 12:03:21 | FromGitter | <mratsim> i.e. when you do getImpl on a generic proc, Nim instantiate it and gives you symbols instead of just giving you idents |
| 12:03:44 | FromGitter | <mratsim> so the question is: is that intended? |
| 12:17:27 | * | clyybber quit (Quit: WeeChat 2.5) |
| 12:18:29 | * | lritter joined #nim |
| 12:49:23 | FromGitter | <zacharycarter> Zevv - the VM isn't too scary once you understand a few things, but if I have to manually parse and construct PNode trees to be able pass objects I define, it's probably a hard no. |
| 13:10:06 | Zevv | I'm already having a hard time getting macros to do what I want, it seems I'm doing on-the-edge stuff and I already hit all kind of limitations or issues |
| 13:16:23 | * | JnR joined #nim |
| 13:18:24 | JnR | whyyyy Is it so hard to integrate Nim and Python with Nimpy? |
| 13:19:49 | JnR | i mean I don't know much about Nim but the library looked very easy to implement Nim scripts |
| 13:22:41 | zacharycarter | I'll wait to decide what to do until Araq or Krux02 or someone is around who is more familiar with the VM than I am |
| 13:23:14 | zacharycarter | I just don't think it's going to be feasible to add a proc for parsing / constructing a PNode for every type in Nuklear |
| 13:27:09 | krux02 | I am around |
| 13:27:21 | krux02 | I am just having a Sunday though |
| 13:27:37 | FromGitter | <zacharycarter> no worries - enjoy your Sunday I can ask later |
| 13:27:47 | krux02 | Zevv: can you sum up what your goal is then? |
| 13:28:21 | lqdev[m] | zacharycarter: maybe I should work on rod a little more 🤔 |
| 13:29:40 | krux02 | lqdev: don't take it personal, but I don't believe in yet another scripting language. |
| 13:29:56 | krux02 | The problem with programming languages is not, the more languages you have the better it is. |
| 13:30:11 | krux02 | People what one language that scales from small to big problems. |
| 13:30:23 | krux02 | People don't know that they want that, but that is what they want. |
| 13:30:56 | FromGitter | <zacharycarter> I just want some form of hot reloading |
| 13:31:02 | FromGitter | <zacharycarter> that works - however I can achieve that - I'd be happy |
| 13:31:05 | krux02 | I am also not sure if embedding the nimvm as a scripting language is what you want to do either. |
| 13:31:35 | FromGitter | <zacharycarter> well - it was working until I had to start defining custom get and setResult procs for objects with lots of fields |
| 13:31:48 | krux02 | I also want hot code reloading. There was a project to provide hot code reloading to native Nim. Did you try that? |
| 13:32:00 | krux02 | I did not work on that, and I don't know how it actually works. |
| 13:32:06 | krux02 | I think that is a real problem. |
| 13:32:26 | krux02 | But it would be very valuable for me, if you could just share your story. |
| 13:32:43 | FromGitter | <zacharycarter> I did and I ran into this issue in short order - https://github.com/nim-lang/Nim/issues/11718 |
| 13:32:44 | krux02 | Just tell what you tried how you approached it, and where it failed. |
| 13:32:51 | lqdev[m] | krux02: rod is nothing more than a hobby project to learn how programming language design and implementation |
| 13:33:51 | krux02 | lqdev: ok |
| 13:33:59 | FromGitter | <zacharycarter> that was the first thing I tried - so then I considered using lua / moonscript - and then I remembered the embedded nimscript project - so I tried that out and it worked with a simple object and a custom get / setResult |
| 13:34:30 | FromGitter | <zacharycarter> and then today it hit me that I'd be working with objects with lots of fields and that it's not a scaleable approach |
| 13:35:46 | krux02 | what exactly is the environment that you want to have scriptable? |
| 13:36:48 | FromGitter | <zacharycarter> I want my game play code / editor to be able to be scripted and call into a Nim API that the engine exposes |
| 13:37:00 | FromGitter | <zacharycarter> so that I can iterate on game code quickly |
| 13:37:04 | krux02 | I don't know if it helps, but I once implemented the bare bone command interpreter here: https://github.com/krux02/opengl-sandbox/blob/master/examples/console.nim |
| 13:37:43 | krux02 | it is not a programming language at all, but it allows you to type commands and bind them to functions in Nim (without return values). |
| 13:37:48 | FromGitter | <zacharycarter> well - yeah something like that would be cool too |
| 13:37:55 | FromGitter | <zacharycarter> but I think it's too simple for my needs |
| 13:37:56 | krux02 | This is very much to what bash is. |
| 13:39:08 | krux02 | in a game environment you don't want to have return values, because when you do commands with mouse/keyboard all those commands work on state changes alone |
| 13:40:39 | krux02 | the problem why I can't give you proper feedback to solve your problem is, I don't understand your problem domain. If you could explain to me a bit more clearly what turn around times you try to optimize, I might be able a bit better to help you. |
| 13:41:08 | FromGitter | <zacharycarter> I basically want to be have my engine reload game code on the fly |
| 13:41:21 | krux02 | Currently I think hot code reloading in Nim is a nice experimental feature, that you can try out if you want. But I don't bevieve that it is stable. |
| 13:41:23 | FromGitter | <zacharycarter> and I know a number of eninges do this - some use shared libraries / dlls |
| 13:41:35 | krux02 | what game code are you talking about? |
| 13:41:37 | FromGitter | <zacharycarter> yeah - I did try it and I ran into that issue I linked to |
| 13:41:38 | krux02 | level scripts? |
| 13:41:42 | krux02 | or is it game logic? |
| 13:41:46 | FromGitter | <zacharycarter> game logic |
| 13:41:46 | krux02 | is is physics stuff? |
| 13:41:54 | FromGitter | <zacharycarter> no the physics stuff would be baked into the engine |
| 13:42:22 | FromGitter | <zacharycarter> for instance - here's an engine that has a python scripting system |
| 13:42:31 | FromGitter | <zacharycarter> https://github.com/eduard-permyakov/permafrost-engine |
| 13:42:51 | FromGitter | <zacharycarter> so I wanted to do something very similar with Nim HCR or Nimscript |
| 13:42:55 | FromGitter | <zacharycarter> but I don't think either are quite there yet |
| 13:43:47 | krux02 | what type of stuff is scriptable in python there? |
| 13:44:16 | FromGitter | <zacharycarter> starting a new game, loading a map, setting shader uniform values, etc |
| 13:44:31 | FromGitter | <zacharycarter> basically whatever you want to expose as an API to Python |
| 13:44:46 | FromGitter | <zacharycarter> but mostly just things that someone would need to author an editor or game with the engine |
| 13:45:10 | krux02 | that all is doable with my command interpreter as well, except that you don't really have a programming language, just commands (not even loops) |
| 13:45:56 | krux02 | you problem with a scripting language is, that you can only see from that enine what you expose. |
| 13:45:58 | krux02 | Nothing else. |
| 13:46:14 | krux02 | No matter if you have nimscript or lua or my command interpreter etc. |
| 13:46:27 | FromGitter | <zacharycarter> yes but that's okay - I'm fine with that |
| 13:46:59 | krux02 | my command interpreter works in a way that you have a macro that you would apply with the pragma syntax to functions |
| 13:47:14 | krux02 | proc add(arg1: int; arg2: int): void {.interpreterCommand.} |
| 13:47:32 | * | JnR left #nim ("Leaving") |
| 13:47:43 | krux02 | then the macros does everything necessary to make that function available in the interpreter |
| 13:47:44 | Araq | zacharycarter: a macro to translate a T into a PNode is feasible |
| 13:47:47 | * | JnR joined #nim |
| 13:48:01 | FromGitter | <zacharycarter> Araq: hmm - that sounds promising |
| 13:48:05 | * | clyybber joined #nim |
| 13:48:22 | FromGitter | <zacharycarter> krux02: I will take a closer look at the console source file |
| 13:49:04 | FromGitter | <zacharycarter> I'll take a stab at a macro for a simple example this evening |
| 13:50:23 | Araq | eq__qdqSn882Av3rQxYVfnQyMg((&colontmpD_), TM_mDIVXahtYVExBX9bJLnfz0Q_76);T2_.f = colontmpD_; |
| 13:50:32 | krux02 | I think much simpler than that source code isn't possible. |
| 13:50:48 | Araq | clyybber: could instead be: |
| 13:51:09 | Araq | eq__qdqSn882Av3rQxYVfnQyMg((&T2_.f), TM_mDIVXahtYVExBX9bJLnfz0Q_76); |
| 13:51:46 | Araq | the C backend does inplace construction and maybe the destructor lifting for object constructors should do that too |
| 13:54:07 | Araq | but I don't understand the problem itself really... obviously the problem is in the line 'T2_.f = colontmpD_;' since it violates all the rules |
| 14:16:23 | * | JnR left #nim ("Leaving") |
| 14:17:38 | Zevv | krux02: Im on mobile currently, but I'll get back to you. |
| 14:21:08 | * | NimBot joined #nim |
| 14:24:06 | FromGitter | <mratsim> @JnR: nimpy should abstract away all the difficulties of wrapping Python and let you focus on the specific problem domain |
| 14:32:54 | clyybber | Araq: Exactly |
| 14:34:29 | Araq | clyybber: can we get some benchmarks please? if =move is worse than =sink performance-wise, it seems better to patch =sink further and adapt the spec |
| 14:34:34 | clyybber | Araq: The problem is how to communicate that we want to do eq__...(&T2.f, TM_...) to the backend |
| 14:34:57 | Araq | oh you produce an AST that doesn't have nkObjConstr |
| 14:35:04 | Araq | simple. :P |
| 14:35:28 | clyybber | Araq: Ok so essentially generate an empty nkObjConstr and then assign all the fields manually? |
| 14:35:54 | krux02 | mratsim: don't talk about abstracting things away. Abstraction always breaks at some point. |
| 14:35:57 | Araq | maybe. or maybe no noObjConstr at all. but as I said, before =move is bug-free, we need some numbers |
| 14:36:31 | FromGitter | <mratsim> @krux02 what you are saying is that we should go back to the 01111000110101 era? |
| 14:36:31 | clyybber | Araq: Sure, didn't have much time lately. What existing test do you think could best be turned into a aussagekraeftigen benchmark |
| 14:36:39 | clyybber | forgot the english word for it :p |
| 14:36:49 | Araq | lol |
| 14:36:56 | Araq | "meaningful"? |
| 14:37:03 | clyybber | ah yes |
| 14:37:15 | Araq | the strutils tests can be timed |
| 14:37:58 | krux02 | @mratsim: what I mean is is, abstractions are good, but don't overestimate them. The things that you abstract away are never really away. They always stay there under the hood. And sometimes it shows. |
| 14:38:10 | krux02 | so in my opition it is better to talk about automation. |
| 14:38:22 | FromGitter | <mratsim> you're right |
| 14:38:30 | krux02 | wrapper code generation is automated. |
| 14:38:32 | clyybber | Araq: Ha, thats ironic. tnewruntime_strutils is one of the few tests that still segfault :p |
| 14:38:52 | Araq | bummer |
| 14:39:39 | Araq | well I'm getting nervous, =move was *simpler* than =sink on paper |
| 14:40:00 | krux02 | Araq: about that Object node. I think it is about time that we try to implement an object value representation for them nimvm that does not rely on nimnode. |
| 14:40:15 | krux02 | A representation that uses the correct layout |
| 14:40:44 | krux02 | offsetof, alignof, sizeof it is all there. |
| 14:40:52 | krux02 | It can be used to layout the object correctly. |
| 14:41:01 | krux02 | It will make pointers at compile time just work. |
| 14:41:08 | krux02 | unions will work |
| 14:41:13 | krux02 | case objects will work |
| 14:42:30 | clyybber | Araq: Well, injectdestructors got a bit simpler, the C backend has to deal with new challenges though. Like downcasting while retaining mutability |
| 14:42:59 | Araq | I thought it's a full day of work |
| 14:43:09 | Araq | like, 8 hours of work for me |
| 14:43:09 | krux02 | clyybber: when you say downcasting, what do you mean? Because nim got the names for down/up casting mixed up. |
| 14:43:28 | Araq | and now you've been working on this for months already |
| 14:43:52 | clyybber | I know, its the exact opposite of cpp's meaning. I mean casting an object to a class it has inherited from |
| 14:43:53 | FromGitter | <mratsim> objectnode sounds good |
| 14:44:20 | krux02 | ✔ |
| 14:44:32 | FromGitter | <mratsim> btw I would love to try the newruntime for multithreading but I can't compile a hello world :/ |
| 14:44:54 | clyybber | mratsim: Did you try just putting a discard infront of the quit? |
| 14:45:44 | FromGitter | <mratsim> it's in Nim compiler though, and there seems to be other issues https://forum.nim-lang.org/t/5069 "unpaired dealloc" |
| 14:46:36 | FromGitter | <mratsim> if "Hello WOrld" doesn't compile in a couple days and I have finished my PoC by then I'll have a look before rewriting it |
| 14:50:25 | Araq | dunno what you're talking about, I ported the newruntime to work with --threads:on |
| 14:53:32 | clyybber | Araq: This is the issue: https://github.com/nim-lang/Nim/issues/11844 |
| 15:05:50 | clyybber | bbl |
| 15:05:51 | * | clyybber quit (Quit: WeeChat 2.5) |
| 15:12:27 | disruptek | not having pointers at compile-time is a major bummer. |
| 15:12:57 | Araq | krux02: it's not scheduled |
| 15:13:24 | disruptek | wb Araq 😉 |
| 15:13:32 | Araq | you don't have to convince me about its merits |
| 15:13:58 | Araq | you have to convince me about "it's really not much work and can count as a bugfix" :P |
| 15:15:35 | FromGitter | <mratsim> I want to at least have a fast uuid generator at compile-time to distinguish between instances of ref object and use it as the compile-time hash of ref objects. |
| 15:17:08 | FromGitter | <Riderfighter> wb Araq 👋 |
| 15:19:40 | * | sagax joined #nim |
| 15:41:42 | krux02 | Araq: well using the correct memory layout in the nimvm does fix bugs. For example it does fix the bug that a type tagged as union will actually work as expected. Currently the unionness is ignored at compile time which already caused bugs in my code. |
| 15:42:44 | krux02 | btw, in the time where you were away I evaluated a few command line tools for github issues because at this point in time I am really tired of the web frontend. |
| 15:43:03 | leorize | is the {.union.} pragma actually used outside of C FFI? |
| 15:43:11 | zacharycarter | I use it |
| 15:43:18 | krux02 | the best I came accross so far is this one: https://github.com/stephencelis/ghi |
| 15:43:27 | disruptek | krux02: did you play with `hub`? |
| 15:43:40 | krux02 | I did play with hub. But it did not solve my problems. |
| 15:43:50 | disruptek | what's your main pain point? |
| 15:44:08 | krux02 | handling github issues. |
| 15:44:28 | krux02 | sorting them, finding relevant ones. tagging them. finding issues by content |
| 15:45:03 | disruptek | is ghi stable or merely unsupported? the last commit was almost 3 years ago. |
| 15:45:40 | krux02 | the web interface takes around 1000 times longer for everything that I want to do. |
| 15:45:54 | krux02 | disruptek, ghi seems stable to me. |
| 15:46:16 | krux02 | just because there are no commits anymore doesn't mean it is dead. Maybe it is just finished. |
| 15:46:32 | krux02 | you know sometimes you want to solve a problem and move on. |
| 15:46:38 | disruptek | that's what i'm asking. thanks for the link. |
| 15:47:05 | krux02 | hub doesn't seem for me like it wants to solve a problem. Thats why it is still actively developed. |
| 15:47:21 | leorize | well iirc github got a brand new api now |
| 15:47:31 | krux02 | who cares? |
| 15:47:56 | leorize | they have been deprecating several old apis so... |
| 15:47:56 | * | vesper11 joined #nim |
| 15:48:37 | leorize | I wouldn't count too much on an unmaintained product to remain functional in the future |
| 15:48:48 | krux02 | yea, that is the problem with being dependend on SaaS. |
| 15:49:05 | krux02 | What I really want is an offline version of all github issues. |
| 15:49:44 | krux02 | I want to download all of them and have an offline search. Offline commenting. Offline tagging, everything. And then in the end you can push all your comments to github. |
| 15:50:03 | krux02 | ghi doesn't do that. But it remove a little bit of the pain that I have with the web API. |
| 15:50:22 | krux02 | sorry I don't mean API, I mean user interface |
| 15:50:40 | * | laaron quit (Remote host closed the connection) |
| 15:50:40 | * | zacharycarter quit (Ping timeout: 244 seconds) |
| 15:51:52 | disruptek | the api changes aren't something to worry about. |
| 15:52:39 | krux02 | I also took a look at the graphSQL api for github. And therefore also on graphSQL. |
| 15:54:33 | krux02 | At first sight, I think graphSQL has potential. But then I met the state of web tooling. It is just horrible. I don't understand how people can work with such shitty and unreliable garbage. |
| 15:55:30 | disruptek | i think i'm too old for that stuff. i tried to hack it for a few years. it's pretty painful. |
| 15:56:56 | krux02 | I think the entire WEB software stack is complications and slowness everywhere. |
| 15:57:34 | disruptek | well, even if you build something relatively simple and clean, if not performant, someone will change something somewhere and you're screwed. |
| 15:57:50 | disruptek | the ecosystem is a dumpster fire. all day, every day. |
| 15:58:00 | dom96 | krux02, do you mean GraphQL? |
| 15:58:09 | disruptek | yeah. |
| 15:58:10 | krux02 | dom96 |
| 15:58:11 | krux02 | yes |
| 15:58:22 | krux02 | sorry got that wrong |
| 15:58:30 | dom96 | ahh, thought there might be some other technology out there called that |
| 15:58:59 | krux02 | disruptek, not just dumpster. |
| 15:59:53 | krux02 | I think the real problem why such tools as the web technology stack exist are, because building blocks in programming language don't have a price tag attached to them. |
| 16:00:11 | shashlick | @krux02 please take a look at tissue |
| 16:00:23 | krux02 | tissue? |
| 16:00:35 | shashlick | https://github.com/genotrance/tissue |
| 16:00:50 | shashlick | It will help with some of your needs |
| 16:01:35 | shashlick | Also, I get all my github notifications into slack - make it easier to manage |
| 16:02:05 | shashlick | I could add gitter support and we could have a third channel for issue monitoring |
| 16:02:33 | disruptek | the issue isn't that dev isn't noisy enough. |
| 16:02:45 | krux02 | I don't want github notifications in slack. I think it is better to respond to all of them once a day. This instant notifaction thing is really disrupting the workflow. |
| 16:03:28 | krux02 | Notifications when something is important is a good thing. But I have the feeling that there might be one person that then might declare everything as important. |
| 16:07:09 | shashlick | Well I'm able to monitor and participate very easily |
| 16:07:36 | shashlick | Not just github but also forum |
| 16:10:00 | disruptek | what's the compile-time write-a-blob proc akin to the read-a-blob `slurp`? |
| 16:15:35 | FromGitter | <mratsim> @krux02 I don't think anyone with repo/tag access is spamming issues as high-priority or showstopper |
| 16:15:55 | FromGitter | <mratsim> @disruptek, there is no compile-time write |
| 16:16:06 | disruptek | yeah, it makes me sad. |
| 16:16:14 | FromGitter | <mratsim> but you can you staticExec + the shell echo > |
| 16:16:29 | disruptek | i would rather patch the compiler. |
| 16:16:38 | FromGitter | <mratsim> not sure we want to make it easy for people to bork their filesystem |
| 16:17:32 | disruptek | it's fine; i don't really care if no one uses my code. |
| 16:17:51 | FromGitter | <mratsim> you are spoiled by Nim compile-time capabilities, soon you won't be able to use any other language |
| 16:18:05 | disruptek | actually, i'm infuriated by nim compile-time. |
| 16:18:20 | disruptek | just because i want to operate on a nimnode, that proc becomes compile-time? |
| 16:18:25 | krux02 | disruptek, what is your biggest problem? |
| 16:18:29 | disruptek | i cannot quote do outside of compile-time? |
| 16:18:40 | krux02 | ah |
| 16:18:40 | disruptek | it seems it's too damned hard to compose nim in runtime. |
| 16:18:43 | krux02 | I get it. |
| 16:18:55 | krux02 | that is something where lisp is ahead of Nim. |
| 16:19:01 | disruptek | frustrating in the extreme, since my input may only be available in runtime. |
| 16:19:33 | disruptek | anyway, i am figuring it out. it's my lesson to learn. |
| 16:19:42 | krux02 | disruptek, I guess you have to ship with the Nim compiler then. |
| 16:19:50 | FromGitter | <mratsim> Well, Nim is a compiled language so you can't do code generation at runtime |
| 16:19:57 | disruptek | but, if i cannot output the code i craft, it cannot be consumed by "mere mortal" development tools as simple source code. |
| 16:20:00 | disruptek | and that's a non-starter. |
| 16:20:12 | krux02 | mratsim: you can do code generation at runtime, if you ship with the compiler. |
| 16:20:19 | disruptek | i'm trying to write a program to generate code. i don't care if i cannot run it. |
| 16:20:21 | disruptek | wtf. |
| 16:20:36 | * | masterdonx quit (Disconnected by services) |
| 16:20:43 | FromGitter | <mratsim> in my case I will write a LLVM Jit backend |
| 16:20:51 | * | masterdonx joined #nim |
| 16:21:02 | FromGitter | <mratsim> for my runtime codegen Nim |
| 16:21:07 | FromGitter | <mratsim> needs* |
| 16:21:15 | * | masterdonx quit (Disconnected by services) |
| 16:21:25 | * | masterdonx joined #nim |
| 16:22:26 | krux02 | mratsim: I totally get your problem, since I had it in the past with scala. But I am afraid to tell you that the focus of the developers right now is to fix existing bugs. Nim is currently not ready to be written for an LLVM backend. |
| 16:22:55 | krux02 | I just think that with the current developrs active in Nim, we don't have enough man power to support that. At least not right now. |
| 16:22:57 | FromGitter | <mratsim> oh I'm not complaining, I will write it myself |
| 16:23:03 | krux02 | ok |
| 16:23:29 | FromGitter | <mratsim> it's for a small DSL for tensor and image processing so I don't need to support full-blown generic language codegen |
| 16:23:59 | krux02 | The next thing that I am worried about is future maintenance. |
| 16:24:17 | krux02 | Nim is a constantly evolving Langugae. a backend might be outdated faster that you might expect. |
| 16:24:54 | FromGitter | <mratsim> I'm using my own AST, thi is the codegen for NimNode: https://github.com/numforge/laser/blob/master/laser/lux_compiler/backend/lux_codegen.nim#L23-L97 |
| 16:24:58 | FromGitter | <mratsim> so it's really small |
| 16:25:40 | krux02 | ok |
| 16:25:44 | FromGitter | <mratsim> basically: literals, arithmetic operations including simd, for loops |
| 16:26:26 | FromGitter | <mratsim> the hard part will be multithreading |
| 16:26:37 | FromGitter | <mratsim> hence my interest into multithreading runtime at the moment |
| 16:28:14 | * | masterdonx quit (Quit: ZNC - http://znc.in) |
| 16:28:43 | krux02 | I really dislike to do multithreading. For me it feels like building on quicksand, because processors or processor cores are neither completely distinct nor are they completely sharing everythihg. It is this mixture of shared cache and non-sharedness that is arbitrarily different between all processors that scares me to build anything for it. |
| 16:29:10 | krux02 | I do like MPI though, here everything is non shater, it is all completely separaeted. I know what I am dealing with. |
| 16:29:59 | krux02 | I also like GPU programming, at least in openGL, because I don't need to care about shared or nonshared. |
| 16:30:56 | krux02 | you know what I mean. |
| 16:31:21 | FromGitter | <mratsim> yes I understand |
| 16:31:40 | FromGitter | <mratsim> parallelizing for NUMA is a huge pain for example |
| 16:31:53 | FromGitter | <mratsim> because sockets don't share memory |
| 16:32:19 | krux02 | I heared lectures about it, there are programs that are slow because they constantly invalidate each others cache. So the multithreaded program is even slower than the single core program. |
| 16:32:38 | krux02 | Then there is the shared chache that you better use to be fast, but you never know where it starts. |
| 16:32:38 | FromGitter | <mratsim> even hyperthreading is a pain because you might run out of L1 cache because 2 threads that access different data are put on the same core |
| 16:32:58 | krux02 | yea |
| 16:33:22 | FromGitter | <mratsim> yep, had that (false-sharing/cache stomping) quite often in arraymancer |
| 16:33:58 | FromGitter | <mratsim> it's easy to reproduce, just do an shared array of ints, and update each from a different thread |
| 16:34:13 | FromGitter | <mratsim> if you didn't pad to 64 bytes it will be slower than single-threaded |
| 16:34:28 | krux02 | Good people always tell to pick your battles wisely. Pick the battles that you can win. Multithreaded programming is just a battle I prefer not to pick. There is so much out there that doesn't need multithreading, I am happy to focus on just that. |
| 16:34:50 | FromGitter | <mratsim> In my case, it's absolutely needed so ... |
| 16:35:35 | krux02 | but that also means that I can't give you advise in multithreaded programming. I can only give you advise in how to avoid doing it. |
| 16:35:42 | FromGitter | <mratsim> Regarding MPI, I'm implementing a paper that uses channel for thread synchronization instead of shared memory so it has nice safety properties |
| 16:36:16 | krux02 | yea that sounds like how mpi works |
| 16:37:03 | krux02 | but as far as I got into MPI it didn't have threads it only had processes. |
| 16:37:28 | FromGitter | <mratsim> yes MPI is for multi-machine distribution |
| 16:37:57 | FromGitter | <mratsim> at the workstation level you need another multithreading scheme, often OpenMP or Intel TBB in scientific omputing |
| 16:38:28 | krux02 | I don't know about Intel TBB |
| 16:38:45 | krux02 | Initially I thought that OpenMP is cool, because it was so simple to use. |
| 16:39:06 | FromGitter | <mratsim> I wonder what def- is doing now, he wanted to mentor someone to implement MPI in Nim: https://github.com/nim-lang/Nim/wiki/GSoC-2015-Ideas#mpi-support |
| 16:39:32 | krux02 | Then I found out that the overhad to create those processes for a for loop is over the budget that you have to render a frame in a game engine. There my interest for OpenMP dwindled |
| 16:40:27 | FromGitter | <mratsim> well, like you said a hour before, it's a leaky abstraction |
| 16:41:10 | krux02 | it is also what I said about web programming before. |
| 16:41:30 | krux02 | When you write a function call in any programming language, thet function call should have a price tag attached to it. |
| 16:41:42 | FromGitter | <mratsim> you need to know how heavy your computation is to split it because OpenMP will assume that all iterations are balanced workload |
| 16:42:04 | krux02 | but even the abstraction of a price doesn't always work. |
| 16:42:36 | FromGitter | <mratsim> in many cases single threaded is faster than starting a parallel section in OpenMP (like if you only do an addition or a copy vs an exponential) |
| 16:43:16 | krux02 | a floating point operation takes I don't know how long, but I think 7 cycles to complete. But that doesn't mean you have to wait 7 cycles. The FPU can take an input value every cycle. |
| 16:43:21 | FromGitter | <mratsim> This one is a good study of that: https://github.com/zy97140/omp-benchmark-for-pytorch |
| 16:44:06 | krux02 | so just putting the amount of cycles for an operation doesn't tell the whole story. |
| 16:44:27 | FromGitter | <mratsim> depending on your CPU and the operation you might need between 1k to 80k elements in your array to make multithreading worthwhile |
| 16:44:28 | FromGitter | <Riderfighter> i just |
| 16:44:31 | FromGitter | <Riderfighter> oh gosh |
| 16:44:41 | FromGitter | <Riderfighter> I just optimized the kdf so hard |
| 16:46:50 | krux02 | writing fast single threaded code is easy if you know what you need to take care of. It will then also run pretty fast on any CPU. Writing fast multithreaded stull is super hard. |
| 16:46:56 | krux02 | stuff |
| 16:47:00 | krux02 | not stull |
| 16:53:51 | FromGitter | <Riderfighter> so it turns out I implemented a really old version of the openssl kdf |
| 16:54:07 | FromGitter | <Riderfighter> I just yoinked the newer code and this bad boi is look pretty good! |
| 17:00:07 | * | abm joined #nim |
| 17:01:20 | FromGitter | <zacharycarter> Debating internally between attempting to write these macros vs just ditching nimscript for lua |
| 17:02:30 | krux02 | zacharycarter: I you just want to get things done, I think lua might be the faster solution. |
| 17:02:52 | krux02 | it has been a successful scripting language for years, Even though I never liked it. |
| 17:09:45 | FromGitter | <zacharycarter> Yeah, that's what I'm leaning towards |
| 17:13:36 | * | Vladar quit (Remote host closed the connection) |
| 17:15:19 | FromGitter | <Riderfighter> well this is a first https://dsh.re/26327 |
| 17:18:43 | krux02 | @zacharycarter: What you can also do is not to have a scripting language at all. For example you can make sure that all gamestate can be automatically serialized and restored. Then yuo just recompile the project and restart it. |
| 17:19:07 | krux02 | When you don't have too much data that needs to be serialized, this might solve all your needs. |
| 17:19:18 | krux02 | that I what I would try to go for. |
| 17:20:08 | krux02 | I am actively working to throw out complexity and super slow things from the compiler. So you would get support from me if you would detect things in the compiler that are slowing the compilation unnecessarily down. |
| 17:20:28 | krux02 | general purpose serialization is also no magic. |
| 17:22:08 | FromGitter | <zacharycarter> I've run into those before |
| 17:23:48 | krux02 | if you can report them, please do. |
| 17:24:21 | FromGitter | <haxscramper_gitlab> How I can do map (or equvalient opeartion) on built-in set type? I have set of styles (from *terminal* module) and want to convert them into ansi escape sequences without checking if each value is present in set. |
| 17:33:33 | * | hoijui quit (Ping timeout: 250 seconds) |
| 17:35:04 | FromGitter | <zacharycarter> Krux02: I think this might make lua slightly more tolerable - https://moonscript.org/ |
| 17:40:21 | FromGitter | <haxscramper_gitlab> Turns out `toSeq` can convert `set[T]` to `seq[T]` so it is possible to do `toSeq(styles).mapIt(ansiStyleCode(it)).join` |
| 17:51:14 | krux02 | @zacharycarter: I would probably start with just LUA. I really like to keep my technology stack low. |
| 17:52:44 | Araq | disruptek, 'static: writeFile(...)' works |
| 17:57:18 | FromGitter | <zacharycarter> Yeah, I agree, but if moonscript ends up making Lua more ergonomic without a lot of fuss I wouldn't mind adding it. |
| 17:58:17 | Araq | Lua: Requires translation from Lua's data model to the native packed representation |
| 17:58:23 | FromGitter | <zacharycarter> There is also https://github.com/jangko/razcal which would provide a decent reference |
| 17:58:25 | Araq | NimScript: The same. |
| 17:58:32 | krux02 | maybe you have more experience with lua than me. I never used it. I just decided that I would not like the language as it is. But when I looked at moonscript, it did not look like it would fix the parts of lua that I don't like about it. |
| 17:58:40 | Araq | no benefits are visible to me |
| 17:59:19 | Araq | I have used Lua extensively and I consider it almost unusable thanks to its 'nil' handling |
| 17:59:39 | Araq | you can give me a LuaJIT that is 5x faster than native Nim and I still wouldn't use it. |
| 17:59:42 | FromGitter | <zacharycarter> I just am scared of how much of a time investment getting Nimscript to the point of being able to work for the API I want will take |
| 18:00:34 | FromGitter | <zacharycarter> I'll try to write a couple of macros tonight to go to a PNode and from one to a simple type def and see how long it takes |
| 18:00:57 | FromGitter | <zacharycarter> Are there any helpers in regards to compile time reflection? |
| 18:01:47 | Araq | just write the macro already. it's not like you don't have to do the exact same thing with Lua, or most other scripting systems |
| 18:02:28 | Araq | in other words, Lua doesn't play nice with struct Point { int x, y; } either |
| 18:03:05 | krux02 | (not a recommendation) I would probably try to use guile as a scripting language. Because I don't know it and I heared good things about it. |
| 18:03:34 | FromGitter | <zacharycarter> Okay I will give it a go |
| 18:04:18 | FromGitter | <zacharycarter> Guile, like scheme guile? |
| 18:04:22 | krux02 | yes |
| 18:04:46 | FromGitter | <zacharycarter> I didn't realize it was emeddable |
| 18:04:48 | krux02 | I use emacs-lisp for emacs, and so far I don't see much wrong with a scheme/lisp as a scripting language. |
| 18:05:02 | krux02 | it is built to be embedded |
| 18:05:07 | FromGitter | <zacharycarter> I do like chicken scheme |
| 18:05:11 | krux02 | but it is (gpl) |
| 18:05:17 | FromGitter | <zacharycarter> Ah interesting |
| 18:06:12 | krux02 | there are other scheme and lisp things. But I don't really want to nitpick about details. Because you want to have your heavy stuff done in Nim not the scripting language. |
| 18:06:23 | FromGitter | <zacharycarter> Yes |
| 18:06:27 | krux02 | A scripting language is hard to debug. |
| 18:06:56 | krux02 | you don't have the tools available that you have for all your other code. |
| 18:07:01 | FromGitter | <zacharycarter> Nimscript is my ideal so I'll invest a few hours / days trying to get it working |
| 18:07:56 | krux02 | yes, try to get it working, but I would recommend you to stay away from value types. try to find an interface to your engine that doesn't need to pass back and forth value types. |
| 18:08:17 | Araq | my ideal is "hot code reloading" |
| 18:08:17 | krux02 | they are annoying to deal with in scripting engiens. |
| 18:08:49 | Araq | scripting languages simply suck, never been productive in any of them, most don't even check for typos |
| 18:09:29 | krux02 | Araq: I already mentioned it, but I also like the idea to recompile everything, but save the state for the program in a reliable and fast way so you have hot program reloading. |
| 18:15:47 | stefanos82 | Araq: I'm going to mention something interesting I have found with meson that is related to hot reloading, but not sure how accurate comparison can be; it's using .dat files for caching certain parsing steps *I think*, I'm not entirely sure as I cannot see their contents clearly, but it compiles like a bullet. |
| 18:25:52 | FromGitter | <zacharycarter> Yes I would like hot code reloading as well but I think there are still kinks there |
| 18:30:37 | * | Trustable joined #nim |
| 18:30:48 | shashlick | Coming late into the conversation |
| 18:31:25 | shashlick | Hcr means you need to ship Nim with your app |
| 18:31:38 | Araq | no |
| 18:32:02 | Araq | it's in fact, one of the few options that allow you to not ship a scripting env |
| 18:32:40 | shashlick | So does it support taking the dlls from the nimcache folder, the main app binary and that's it? |
| 18:32:48 | shashlick | I don't need to ship Nim or the source? |
| 18:34:54 | * | Jesin quit (Quit: Leaving) |
| 18:35:19 | shashlick | Second bigger question is whether it is stable enough for me to use it with threads and exchange data between main app and dll and get decent stack traces |
| 18:35:58 | shashlick | Cause I've had many issues just using app:lib and debugging has been impossible even with Nim gdb |
| 18:37:00 | FromGitter | <zacharycarter> I ran into this issue and it seems related to nimrtl https://github.com/nim-lang/Nim/issues/11718 so I think there are still problems to iron out. The feature is very much experimental I think |
| 18:39:47 | FromGitter | <zacharycarter> It wasn't easy to debug that issue either, but then again I'd never used Dr Memory before when I tried. |
| 18:40:17 | FromGitter | <deech> https://github.com/nim-lang/Nim/pull/11341/files is finally up. It fixes a few issues with assigning and passing compile time parameters at runtime. |
| 18:40:24 | * | Jesin joined #nim |
| 18:40:48 | shashlick | Considering I don't have any memory analysis tools I can use, it is extremely frustrating trying to debug |
| 18:41:49 | shashlick | When your ref object suddenly becomes empty or filled with stuff you put in an allocShared blob somewhere else, you have to wonder |
| 18:42:20 | shashlick | Or have no recourse when you get a gcassert |
| 18:42:21 | * | Jesin quit (Remote host closed the connection) |
| 18:45:50 | disruptek | krux02: you might like the concept of fennel: https://fennel-lang.org/ -- it's lua with lisp syntax, macros. |
| 18:46:00 | * | Jesin joined #nim |
| 18:50:59 | disruptek | Araq: thanks, i was searching for a static writeFile but i guess i didn't look hard enough. |
| 18:51:10 | Araq | shashlick: HCR is for development, in the end you can always build the .exe the old way |
| 18:54:00 | * | hoijui joined #nim |
| 18:57:57 | * | stefanos82 quit (Ping timeout: 245 seconds) |
| 19:01:24 | FromGitter | <zacharycarter> I don't want to speak for shashlick, but I think he was aiming for a plug-in architecture which has never been straightforward to achieve with Nim's memory model. Regardless of the architecture's merits, the per-process GC makes it not so straightforward |
| 19:04:08 | Araq | I know |
| 19:04:19 | Araq | HCR is not for plugins |
| 19:11:31 | * | stefanos82 joined #nim |
| 19:29:03 | * | hoijui quit (Quit: Leaving) |
| 19:34:47 | shashlick | Ultimately, I need some engine - dll was cool cause it was fast. Can't call it a script engine but using dlls is even more common in app devel. I'd say that has to be solved before anything else. |
| 19:37:03 | shashlick | If I cannot use Nim from Nim, that's weird cause it's so easy to use C/C++ or any other language that can generate a compatible dll |
| 19:37:30 | disruptek | it could be me, but most of what i see published as nimble packages designed for simple inclusion in source would be more appropriate as shared libraries. |
| 19:38:25 | * | nsf quit (Quit: WeeChat 2.4) |
| 19:38:54 | shashlick | Ya i was thinking about that as well - using Nim as a scripting engine should be like Lua or others where you just pull a dll into your distro |
| 19:39:16 | FromGitter | <zacharycarter> the problem with that is that each Nim dll has its own GC |
| 19:39:31 | FromGitter | <zacharycarter> and each GC is not aware of other GC's that might be present |
| 19:39:31 | disruptek | yeah, it's a problem. |
| 19:39:38 | shashlick | That's exactly what I'm grumbling about |
| 19:40:01 | * | drewr quit (Ping timeout: 276 seconds) |
| 19:40:09 | shashlick | In addition, there's no way to debug those dlls since you don't get any stack traces for that code |
| 19:40:19 | shashlick | You do for the main app only |
| 19:40:28 | FromGitter | <zacharycarter> well that's a problem with plug architectures in general |
| 19:40:32 | FromGitter | <zacharycarter> they are notoriously difficult to debug |
| 19:40:39 | FromGitter | <Riderfighter> I'm probably uniformed by the possibility of this but, can't you disable the GC in the dlls when compiling? |
| 19:40:56 | shashlick | Well then you can forget about long running stuff |
| 19:41:04 | shashlick | Cause you will eat up ram in no time |
| 19:41:08 | FromGitter | <zacharycarter> sure - but then you need to manually allocate and deallocate all of the memory |
| 19:41:13 | disruptek | well, what's probably trickier is getting the low-level compat we enjoy now working with a clever plugin architecture. |
| 19:41:33 | FromGitter | <Riderfighter> Ah that thanks sense on why disabled the GC is bad lol Thank you guys :D |
| 19:41:39 | shashlick | If you avoid the entire stdlib then you can turn the gc off |
| 19:41:45 | shashlick | But then why use Nim in the first place |
| 19:42:41 | FromGitter | <zacharycarter> there is no real panacea here - Nim is probably the most mature of the languages that provide an alternative to C |
| 19:42:53 | FromGitter | <zacharycarter> unless you factor in scheme implementations |
| 19:43:10 | shashlick | Well so my goal is to use Nim more than build a text editor |
| 19:43:15 | FromGitter | <zacharycarter> Nim also has the advantage of good C++ interop which Zig / Odin / Kit lack |
| 19:43:46 | FromGitter | <zacharycarter> Rust is probably more battle-tested than Nim - but you have to deal with all of Rusts warts and complexities |
| 19:43:58 | shashlick | So if building it was more important, I'd just have used Lua or something |
| 19:43:58 | FromGitter | <zacharycarter> and you don't have a GC |
| 19:43:58 | disruptek | you could probably have a nim shared lib built with support for multiple backends. |
| 19:44:19 | krux02 | Nim also has it's own shares of unnecessary complexities. |
| 19:44:24 | krux02 | Bind many types |
| 19:44:35 | shashlick | Effectively I have to either have a single binary or use rpc |
| 19:45:01 | shashlick | When almost everyone else uses shared libs |
| 19:45:31 | FromGitter | <zacharycarter> I figured that if you could live w/ Bohem than a plugin architecture would work without issue |
| 19:45:43 | FromGitter | <zacharycarter> but I guess your experience is different shashlick since you mentioned you tried that |
| 19:46:34 | FromGitter | <zacharycarter> I figured with boehm that nimrtl didn't even factor in |
| 19:46:49 | * | ng0 joined #nim |
| 19:47:18 | shashlick | I was living with boehm but that doesn't work anymore on 0.20.x |
| 19:47:25 | Zevv | krux02: you asked me about my macro problems - when would you have some time? |
| 19:47:39 | shashlick | I tried nimrtl as well |
| 19:48:18 | shashlick | I removed all my crazy pointer and ref code as well to make sure, also the shared mem across threads |
| 19:48:19 | krux02 | now |
| 19:48:45 | krux02 | Zevv, ↑ |
| 19:48:52 | shashlick | https://github.com/genotrance/shared - plug |
| 19:49:05 | Zevv | sweet. I'll try to explain, but if I'm rambling just say so, then it might be better to recreate the problem in a smaller setting |
| 19:50:11 | Zevv | krux02: in npeg, I have a macro that eats a Nim code block which containts my PEG grammer. The Nim AST is parsed and translate into an IR language which does the parsing, and the third step compiles this IR into a state machine running the code. |
| 19:50:44 | Zevv | What I would now like to do is add more composibility to the PEG definitions, basically I want to define peg grammers and be able to reuse those, offering some kind of import mechanism. |
| 19:51:56 | Zevv | For this, I need to pull apart my code: the grammars need to be stored somewhere so I can refer to them and reuse them later. |
| 19:52:08 | krux02 | that reminds me a lot to what emacs does with `rx' |
| 19:52:38 | Zevv | but I'm not able to get stuff "outside" my macro - my IR uses object variants which I can't store in a const, and NimNodes also can not survive outside the macro they are passed through |
| 19:53:01 | * | abm quit (Quit: Leaving) |
| 19:53:24 | Zevv | so I'm looking for some example code which does these kind of things to get inspiration from |
| 19:53:30 | krux02 | in emacs there is the rx procedure to define regular expressions with lisp syntax (not the regular expression syntax). |
| 19:54:05 | Zevv | just looked it up, it seems kind of similar |
| 19:54:45 | krux02 | the interesting part is the library part |
| 19:55:39 | disruptek | Zevv: can't you render the nimnode and write it to a file? |
| 19:55:54 | Zevv | disruptek: render to what? |
| 19:55:58 | disruptek | a string? |
| 19:56:11 | krux02 | don't write nimnodes to a file, Nim does not have a reliable way to do that. |
| 19:56:25 | Zevv | well, I could 'repr' it into Nim code, right? |
| 19:56:26 | krux02 | I also don't get what that solves. |
| 19:56:31 | Zevv | right :) |
| 19:56:34 | disruptek | what do you mean by "unreliable"? |
| 19:56:58 | krux02 | disruptek, when I mean is, when you write a symbol, you won't be able to read it back. |
| 19:57:09 | disruptek | why not? |
| 19:57:22 | krux02 | a symbol is not serializable. |
| 19:57:45 | Zevv | so as a first step, I am looking to split my macro into two parts: one takes the DSL, and returns some kind of data structure. The second eats this data structure, and generates the Nim code. If I have this, I should be able to do other things with this data inbetween. But I'm not able to take it 'outside'. |
| 19:58:23 | disruptek | this is exactly the problem i have. and you're telling me i cannot, in any way, compile-time or runtime, compose nim and write it to a file for later use. |
| 19:58:54 | Zevv | My end goal is to be able to ship a library of reusable grammers, so users can easilly build their grammars on top of existing blocks. Grammars are stored internally as lists of IR, which I want to compose and compile to Nim later on. |
| 19:59:10 | Zevv | disruptek: hmm so we're in the same boat here? Doe you have a description on IRC somewhere of what you're doing? |
| 19:59:24 | krux02 | disruptek, if you write nimNode into a file to parse it at a later stage, you have to be aware that this process is lossy. |
| 19:59:59 | disruptek | i'm taking openapi yaml (which is really json) which describes an api, and turning it into nim code that implements that api. there's a repo that holds thousands of such apis. |
| 20:00:12 | Zevv | ah yes I remember |
| 20:00:21 | krux02 | you can serialize int float string identifier and all nimnodes that are just defined by a kind and its children. But symbol is not (de)serializable. |
| 20:00:30 | disruptek | what kinda lossiness are we talking about? |
| 20:01:27 | krux02 | when you have a symbol, lets say `$`, you can save that it is `$`, maybe even ``system.`$` `` |
| 20:01:35 | krux02 | but you won't be able to store exactly what symbol it is. |
| 20:01:53 | krux02 | there are many `$` symbols in system.nim |
| 20:02:32 | disruptek | yeah, i think i'm okay with not having direct semantic save; i just need syntactic save. |
| 20:03:32 | disruptek | the problem zevv will have is that he'll want to be able to recompose; i can just generate new output when my code changes, which he'll need to maintain some portability. |
| 20:03:56 | disruptek | s/which/while/ |
| 20:04:02 | krux02 | Zevv: the way that emacs-lisp handles it with rx is different. It does not store any variables. `rx` just defines internally the symbols that you are allowed to use for the DSL. Then you can extend this dsl by defining your own dsl, for example nim-rx where you can use symbols such as ``nim-ident``, or ``nim-literal``. |
| 20:04:50 | krux02 | basically this is inheritance is you want to call it that way (it does not really inherit) |
| 20:06:42 | Zevv | this is what I have now, I define some small atomics like posix character classes (Graph, XDigit, AlNum), and I could add bigger parts like URL or IP address matching like this as well. But it does not scale and is not flexible. I would like to be more extendible so I could for example provide a nimble package that offers npeg patterns for a specific purpose. |
| 20:07:07 | Zevv | So make it extendable and 'pluggable', and ideally, even multi-layer extanble. so import A which imports B and C should work |
| 20:07:40 | krux02 | yea the rx macro system is single inheritance only I think. |
| 20:07:51 | Zevv | internally this is trivial for me, my IR has a symbol table which is used for inlining or calls, which are resolved at "link" time. I just can't find a way to do the bookkeeping at the Nim side |
| 20:08:36 | krux02 | But are you sure you really need this deep level of composability? |
| 20:09:04 | Zevv | "need" and "would be totally awesome" are not the same things |
| 20:09:13 | Zevv | so, no :) |
| 20:09:25 | krux02 | yea, I would recommend that you focus on gitting it working. |
| 20:09:43 | krux02 | For that one you can put everything in one module. That will probably also make it easier to maintain. |
| 20:09:58 | krux02 | It is not easy to change something that is distributed accross multiple modules. |
| 20:10:38 | disruptek | maybe you don't need inheritance per se, maybe you want patterns to be able to ask/answer their capabilities as a series of strings, say. |
| 20:11:08 | Zevv | problem is that I even can not get that to work properly. The PEG rules I now offer as 'library' I need to compose "by hand", as I can not generate these from my NimNode DSL - same problem, no way to pull that out of the macro. |
| 20:11:25 | disruptek | pattern.provides() => ["url", "uri"] and pattern.depends() => ["string"] or w/e. |
| 20:12:03 | disruptek | because your logic is inextricable with the data, right? |
| 20:12:36 | Zevv | not sure if I grasp your question, but I think the answer is 'right' |
| 20:12:59 | Zevv | https://github.com/zevv/npeg/blob/master/INTERNALS.md, example on the bottom, might explain things a bit |
| 20:13:12 | Zevv | (Very incomplete document btw) |
| 20:13:14 | FromGitter | <Riderfighter> i've never seen that word used for real haha |
| 20:15:30 | disruptek | that lisp module cannot arrive in nim fast enough. |
| 20:16:16 | Zevv | anyway, my naive try was to get the IR out of the macro using `quote do`, but that runs into all kind of problems - error messages telling me about 'unusable fields' called "data", which I do not have in my code. VM's not being able to store object variants in consts, etc. So I'm clearly not on the right path. |
| 20:16:27 | FromGitter | <zacharycarter> weird - trying to debug the issue I reported regarding nim HCR and even if I comment out all of the calls to the function being complained about and then run all of the gcc commands that the compiler logs - I still get the error |
| 20:16:34 | FromGitter | <zacharycarter> I must be doing something incorrectly |
| 20:16:44 | FromGitter | <Riderfighter> mood |
| 20:17:05 | FromGitter | <Riderfighter> What is the advantage of HCR? |
| 20:17:47 | FromGitter | <Riderfighter> I've never had a project big enough to be a pain to recompile so I assume its to save time from recompiling? |
| 20:18:13 | disruptek | Zevv: i don't see why that case statement couldn't be represented by data, but more pointedly, i don't understand why it couldn't be represented by nim. |
| 20:18:19 | krux02 | Riderfighter, it is not just compiling, it is also startup time of the program. |
| 20:18:34 | disruptek | i'm really having doubts about nim today. |
| 20:18:36 | Zevv | Riderfighter: and most important: your code keeps state. So you can change the code while it is running |
| 20:18:47 | FromGitter | <Riderfighter> Oh that sounds really nice |
| 20:18:49 | Zevv | disruptek: I feel you |
| 20:18:55 | krux02 | Imagine you have loading times of 15 minutes and compilation times of 3 hours. |
| 20:19:26 | FromGitter | <Riderfighter> I'm imagining that I would stop developing at that point lol |
| 20:19:32 | krux02 | when you can compile just something small that doesn't need to restart the engine or recompile everything, that is what you want to do. |
| 20:19:37 | disruptek | more often, it's the case that you want to swap some logic without losing state. |
| 20:19:54 | krux02 | and then you also have to restore the state where you left off last time |
| 20:20:06 | disruptek | maybe it takes 3hrs to get the app into a state where you can usefully test logic. |
| 20:20:07 | FromGitter | <Riderfighter> that sounds so nice jeez |
| 20:20:21 | FromGitter | <zacharycarter> it's extremely useful when you want faster iteration |
| 20:20:39 | krux02 | probably it is not 3hrs, but yea you get the point |
| 20:20:43 | FromGitter | <zacharycarter> having to re-compile a large code base for let's say a game just because you changed some game logic |
| 20:20:47 | Zevv | krux02: so, before I go for a nap, any advise or ideas how I should approach my problem? |
| 20:20:52 | FromGitter | <Riderfighter> I take back all I said, I'm straight up drooling rn |
| 20:21:21 | krux02 | btw for old retro games, cheats were introduced to be able to get to the part of the game that you want to test faster. |
| 20:21:29 | krux02 | there was no hot code reloading |
| 20:22:07 | FromGitter | <Riderfighter> You know what's a pain to debug other than nim dlls apparently, mods for unity games |
| 20:22:35 | FromGitter | <Riderfighter> I can't even attach a debugger to my mod and it breaks on an event in game that I don't even interact with |
| 20:23:03 | FromGitter | <Riderfighter> But thankfully nim is nicer to me :P |
| 20:24:06 | * | clyybber joined #nim |
| 20:24:49 | FromGitter | <deech> @zacharycarter In what sense is Nim the most mature alternative to C? |
| 20:25:09 | FromGitter | <zacharycarter> Rust is an alternative to C++ right? |
| 20:25:16 | FromGitter | <zacharycarter> and I said discount scheme |
| 20:25:24 | FromGitter | <Riderfighter> Does anyone have any criticism/suggestions they could give to my module by chance? https://dsh.re/93980 |
| 20:25:50 | FromGitter | <zacharycarter> so of the new breed of modern systems programming languages that aim to offer alternatives to C - what else is there? |
| 20:25:56 | FromGitter | <deech> But even so D as Better C seems to be farther along right now. |
| 20:26:05 | FromGitter | <zacharycarter> perhaps |
| 20:26:14 | FromGitter | <deech> There's ATS. |
| 20:26:20 | FromGitter | <zacharycarter> I haven't heard of ATS before |
| 20:26:43 | FromGitter | <zacharycarter> looks interesting |
| 20:26:49 | FromGitter | <deech> I don't recommend doing putting it into prod. or anything but it's a pretty intriguing language ... |
| 20:27:16 | FromGitter | <deech> Why do you discount Zig? |
| 20:27:52 | FromGitter | <zacharycarter> I like Zig a lot - it's not that I discount it - it's just it's a lot further from a 1.0 release than Nim is - not that that really means anything, after all versions are relative |
| 20:27:58 | FromGitter | <zacharycarter> but it's still missing things like coroutines |
| 20:28:43 | FromGitter | <deech> Interesting. Why are coroutines needed for a C alternative? |
| 20:29:06 | FromGitter | <zacharycarter> I suppose they're not - but apparently they're blocking a lot of development and are the #1 priority to implement in the Zig world atm |
| 20:29:35 | FromGitter | <zacharycarter> I was told this a couple of days ago when inquiring about a Zig issue that had been blocking me for a while |
| 20:29:47 | FromGitter | <deech> Didn't know, thanks! I'd be interested in seeing how they resolve that without retrofitting some kind of Rust like borrow checker. |
| 20:29:57 | FromGitter | <zacharycarter> let me try to find the issue |
| 20:30:28 | FromGitter | <mratsim> > *<Araq>* HCR is not for plugins ⏎ Uh, I thought that was one of the main appeal ⏎ Same for REPL |
| 20:30:37 | FromGitter | <zacharycarter> https://github.com/ziglang/zig/issues/2377 |
| 20:31:19 | FromGitter | <arnetheduck> coroutines are what make `go` fly.. aka cooperative concurrency.. can't implement well in C really (without specific compiler support, not sure any c compilers support it) |
| 20:31:36 | FromGitter | <mratsim> > *<Zevv>* so as a first step, I am looking to split my macro into two parts: one takes the DSL, and returns some kind of data structure. The second eats this data structure, and generates the Nim code. If I have this, I should be able to do other things with this data inbetween. But I'm not able to take it 'outside'. ⏎ ⏎ That's what I'm doing for my own DSL compiler so that I will be able to enable compile-time |
| 20:31:36 | FromGitter | ... Nim code generation or runtime JIT code generation |
| 20:32:17 | FromGitter | <mratsim> @arnetheduck https://github.com/sustrik/libmill |
| 20:33:20 | FromGitter | <mratsim> data structure is here and seems to use setjmp: https://github.com/sustrik/libmill/blob/master/cr.h |
| 20:33:25 | FromGitter | <arnetheduck> yeah, like we discussed the other day, the register allocation will be wasteful.. also, in C it's pretty easy to bypass the scheduler - `go` and other languages can gate it at the compiler level |
| 20:33:29 | FromGitter | <mratsim> on Windows you can use the builtin fibers AFAIK |
| 20:33:40 | krux02 | Araq: is there a way to declare a magic proc as global state dependent? |
| 20:34:10 | FromGitter | <mratsim> but continuation support in Nim would help beyond coroutines, even for multithreading there are some schemes that require stack saving/restoring |
| 20:34:22 | FromGitter | <deech> @zacharycarter Interesting, thanks for the link! Still don't see how it will work without GC or thread/closure local heaps or a borrow checker. |
| 20:34:38 | FromGitter | <arnetheduck> fibers have the same issue - too much register traffic etc |
| 20:35:00 | FromGitter | <zacharycarter> @deech - no problem - maybe that's why it's taking so long :P |
| 20:35:26 | krux02 | I am implementing a proc in macros.nim with no argument that returns some information about the macro context it is being evaluated in. |
| 20:37:42 | Araq | krux02, proc foo() {.magic, sideEffect.} ? |
| 20:38:23 | FromGitter | <deech> @zacharycarter I know of at least one anecdote where Nim coroutines caused GC memory blowup. IMO there's lots of work to do before Nim can be called mature, but I believe once there people will be able to write some pretty fast memory-friendly easy to maintain apps. It's a simple matter of funding. :) |
| 20:39:20 | * | huuskes joined #nim |
| 20:39:24 | Araq | there is always a way to mess up memory |
| 20:40:27 | shashlick | So what's the next step? Keep the dlls but use rpc instead to avoid the gc mixup? |
| 20:40:38 | krux02 | Araq: well that could work, but it does not have a side effect, it just depends on context |
| 20:40:47 | krux02 | I try it |
| 20:40:55 | Araq | on what context? |
| 20:41:09 | FromGitter | <zacharycarter> yeah - it'd be great if Nim had more monies |
| 20:41:20 | shashlick | Or hope that nimrtl will be get improved |
| 20:41:46 | shashlick | My main problem with Nim is that I'm always doing something beyond what's advertised |
| 20:41:50 | FromGitter | <zacharycarter> okay - I give up on trying to debug this HCR issue - when you comment out every line referencing the method being complained about in the generated C code and you still get an error - I'm not sure what else to do :P |
| 20:42:42 | FromGitter | <zacharycarter> you'll probably run into that frustration with any non-mainstream language tbh |
| 20:42:57 | krux02 | Araq: it doesn't seem to work. |
| 20:43:17 | FromGitter | <zacharycarter> I think if you want something that's more stable and not C/C++ - Rust is your best bet |
| 20:43:24 | FromGitter | <zacharycarter> but Rust has issues too |
| 20:43:27 | krux02 | The problem is, the proc is already evaluated in semExpr(), but this may not happen. |
| 20:43:37 | shashlick | @zacharycarter just to create and use dlls? |
| 20:43:56 | shashlick | I'm not going to try rust, that's like asking a python guy to like ruby |
| 20:44:10 | krux02 | it there a way tell the compiler that this proc should not be substituted by it's result during semEXpr? |
| 20:44:30 | Araq | krux02, why would you need that? |
| 20:45:03 | FromGitter | <zacharycarter> Nim can create and use dlls fine - it's just problematic when it comes to the GC - which makes the ability to do so somewhat moot |
| 20:45:09 | krux02 | I write getCallstieLineinfo() |
| 20:45:50 | krux02 | in semMacroCall, I set that lineinfo, and then in vm I just read the lineinfo from the context. |
| 20:45:54 | krux02 | pretty easy |
| 20:45:57 | FromGitter | <zacharycarter> but then again - there aren't many folks who have tried building apps with a shared library plugin architecture using Nim - and those who have and failed probably moved on to another language |
| 20:46:22 | FromGitter | <zacharycarter> I think the GC is a trade off - it makes life easier and at the same time more difficult - not only for users I imagine but also for language developers |
| 20:46:38 | krux02 | problem: getCallsiteLineinfo is evaluated during the semchecking phase of the macro definition. |
| 20:47:10 | Araq | well ok, Nim sucks at "shared library plugin architectures". So let's fix it |
| 20:47:37 | Araq | but just how often do you need to bring it up here? |
| 20:47:44 | shashlick | Araq the question I'm asking, perhaps indirectly, is how |
| 20:48:05 | shashlick | What do I do with a gcassert |
| 20:48:36 | FromGitter | <mratsim> Rust was a very frustrating experience for me |
| 20:48:48 | shashlick | Obviously something is wrong, but is it my code or something else |
| 20:48:55 | FromGitter | <zacharycarter> I'm not a fan either |
| 20:49:12 | FromGitter | <mratsim> the simple fact that it lacked static int was a showstopper (and now they have it but it's apparently very buggy) |
| 20:49:27 | FromGitter | <Riderfighter> What's kind of cool about Rust is that there is an os based off it |
| 20:49:44 | FromGitter | <mratsim> dom96 has a nimkernel AFAIK |
| 20:49:50 | krux02 | Rust has a hype by now. |
| 20:49:56 | krux02 | That is very good for Rust. |
| 20:49:56 | Araq | sorry, nimkernel doesn't count |
| 20:50:12 | FromGitter | <Riderfighter> https://www.redox-os.org here is what I need by the os |
| 20:50:16 | FromGitter | <Riderfighter> its actually really cool |
| 20:51:02 | Araq | yeah, but you will be able to use Nim on redox-os, so *shrug* |
| 20:51:02 | FromGitter | <zacharycarter> meh |
| 20:51:02 | FromGitter | <mratsim> ah yeah, it's more than just a toy kernel |
| 20:53:09 | Araq | I usually stop reading after "Unix-like" but it's cool nonetheless |
| 20:54:35 | FromGitter | <Riderfighter> I'm honestly impressed by what's being achieved w rust |
| 20:54:43 | FromGitter | <Riderfighter> not that I'd actually use it though |
| 20:54:46 | FromGitter | <zacharycarter> well Rust had mozilla behind it |
| 20:55:00 | FromGitter | <zacharycarter> so It's not *too* surprising |
| 20:55:07 | FromGitter | <Riderfighter> yeah, that definitely helped it gain traction |
| 20:55:13 | FromGitter | <zacharycarter> well it helped it gain money |
| 20:55:40 | FromGitter | <zacharycarter> there are some shitty things about Rust though - like one thing I can think of is that there is only a single default allocator per process |
| 20:55:47 | FromGitter | <zacharycarter> and everything running within that process has to use that allocator |
| 20:55:59 | FromGitter | <zacharycarter> even if you want to provide your own custom allocator - everything has to use it |
| 20:56:14 | FromGitter | <zacharycarter> within that process anyway |
| 20:56:45 | FromGitter | <Riderfighter> yeah that's pretty limiting |
| 20:57:01 | disruptek | it qualifies as a better c, imo, but i don't code in c anymore, either. |
| 20:57:10 | FromGitter | <zacharycarter> I still like C very much |
| 20:57:30 | disruptek | i'm too lazy to read c. |
| 20:57:32 | FromGitter | <zacharycarter> and I can even stand C++ 11 / 14 |
| 20:57:50 | FromGitter | <zacharycarter> Nim actually is the reason I'm comfortable with C now |
| 20:58:05 | disruptek | whahuh? |
| 20:58:12 | FromGitter | <Riderfighter> I was looking at languages the other day, for shits and giggles and then I thought to myself "you ever love C so much you thought about making a second version"? http://c2lang.org |
| 20:58:18 | FromGitter | <zacharycarter> I've ported a lot of C code to Nim |
| 20:59:11 | disruptek | i guess that makes sense. |
| 20:59:29 | FromGitter | <zacharycarter> okay - how is this possible - I've commented out every single reference to `failedAssertImpl_W9cjVocn1tjhW7p7xohJj6A` in the generated C code - yet when I compile the application with GCC and run it I still get ```Error: unhandled exception: key not found: failedAssertImpl_W9cjVocn1tjhW7p7xohJj6A [KeyError]``` |
| 20:59:32 | disruptek | i hack it here and there, but i just don't want to look at it. |
| 20:59:52 | disruptek | are you sure your cache isn't in play here? |
| 21:00:08 | FromGitter | <zacharycarter> I'm working inside the nimcache folder and commenting out the cod ethere |
| 21:00:12 | FromGitter | <zacharycarter> and running GCC against it |
| 21:00:57 | FromGitter | <zacharycarter> ooo I think I might know why |
| 21:01:33 | * | Trustable quit (Remote host closed the connection) |
| 21:02:30 | FromGitter | <Riderfighter> oh what the heck C2 isn't a deadlang |
| 21:02:48 | FromGitter | <Riderfighter> I just went on their github and there is an update from 11 days ago |
| 21:04:03 | Araq | C2 already exists, it's called Modula 2 |
| 21:04:10 | FromGitter | <Riderfighter> psh |
| 21:04:17 | clyybber | Araq: Ok, I benchmarked =move with this code: http://ix.io/1QCK |
| 21:04:22 | FromGitter | <Riderfighter> http://c2lang.org = the real C2 |
| 21:05:27 | clyybber | =move is 8% slower on average with tests done with only --newruntime, -d:release, -d:danger, and -d:useMalloc |
| 21:05:53 | Araq | 8% ?! |
| 21:06:23 | FromGitter | <mratsim> slower than a copy? |
| 21:06:24 | disruptek | who cares? does it work? |
| 21:06:34 | Araq | 8% is unacceptable |
| 21:06:38 | clyybber | Well, I have some optimization ideas |
| 21:06:41 | FromGitter | <mratsim> is it on trivial types or for seq/strings? |
| 21:06:54 | clyybber | mratsim: seq/strings |
| 21:06:56 | disruptek | yeah, but does it work? |
| 21:07:01 | clyybber | it doesn't change trivial types |
| 21:07:05 | clyybber | disruptek: Yeah |
| 21:07:12 | disruptek | nice. :-D |
| 21:07:18 | Araq | clyybber, are the alloc counts identical? |
| 21:07:24 | clyybber | Araq: Yeah |
| 21:08:04 | Araq | ok, I'll change the spec to use =sink and deal with self-assignments in the rewriting rules |
| 21:08:57 | clyybber | I have some ideas for optimization though. |
| 21:09:08 | Araq | sure, so do I |
| 21:09:19 | FromGitter | <Varriount> Araq: How go things? |
| 21:09:31 | clyybber | I think doing the object/tuple construction correctly will probably improve things |
| 21:09:50 | Araq | strutils tests don't construct many objects though |
| 21:09:58 | Araq | maybe I misremember |
| 21:11:49 | clyybber | Araq: Does danger pass O3 to the c compiler? |
| 21:12:08 | clyybber | Araq: I sent the benchmark code. |
| 21:12:10 | Araq | I hope so |
| 21:13:33 | clyybber | Araq: How will you deal with it? Introduce copies whenever it can not be statically determined that it won't be a self-assign? |
| 21:13:51 | Araq | yeah |
| 21:14:07 | Araq | plus we simply forbit silly code like 'x = x' |
| 21:14:13 | Araq | *forbid |
| 21:17:38 | Araq | Varriount: https://github.com/nim-lang/Nim/pull/11881 is all I did in my holidays |
| 21:18:09 | FromGitter | <Varriount> Araq: Nice, what holidays? |
| 21:18:22 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 21:18:24 | Araq | summer holidays |
| 21:18:46 | FromGitter | <Varriount> Anything German-specific? |
| 21:19:23 | clyybber | Araq: Interestingly with -d:useMalloc it is only 3% slower |
| 21:19:27 | FromGitter | <Varriount> The only German holiday I can remember is the one that's similar to Halloween in the US |
| 21:19:36 | FromGitter | <Varriount> Well, and Oktoberfest |
| 21:22:45 | Araq | clyybber, 3% sounds more realistic but 3% is 3% |
| 21:23:30 | Araq | and having to care for silly super-rare self-assignments within =sink or =move sucks |
| 21:24:12 | FromGitter | <mratsim> add restrict to the language :P |
| 21:25:52 | clyybber | Araq: Maybe we should try the branch based approach we discussed some time ago. |
| 21:26:20 | FromGitter | <mratsim> something akin to a functional persistent data structure? |
| 21:27:20 | Araq | clyybber, what do you mean? |
| 21:29:24 | clyybber | Araq: Using the CFG to skip destructor injections where they are not needed (when we can statically prove that the branch leading here has variable a moved). So that we insert destructors at the end of branches rather than procs. |
| 21:29:44 | clyybber | At the time you said it would cause issues with exception safety |
| 21:30:14 | clyybber | But I did not really understand how it would. |
| 21:31:59 | Araq | no, I said it's very hard to implement |
| 21:32:19 | Araq | oh and yeah |
| 21:32:54 | Araq | proving these things is harder with the implicit exceptions that inject 'returns' |
| 21:33:46 | FromGitter | <zacharycarter> commenting out - https://github.com/nim-lang/Nim/blob/devel/lib/system/assertions.nim#L38 - fixes that HCR issue |
| 21:33:53 | FromGitter | <zacharycarter> but what causes it in the first place - I have no idea |
| 21:35:11 | * | gokr joined #nim |
| 21:35:24 | gokr | Good evening folks |
| 21:36:11 | gokr | So... trying to use the "ui" nimble package - but... I don't understand it. It says that it downloads C sources for libui (and statically compiles) but I don't see it |
| 21:36:27 | clyybber | Araq: Ah ok. Those implicit exceptions are branches in the end, so the CFG should represent them correctly right? |
| 21:36:31 | clyybber | Does it ATM? |
| 21:37:26 | Araq | it does |
| 21:37:40 | Araq | it also knows about .raises: [] |
| 21:37:44 | clyybber | Then there should be no problem, right? |
| 21:38:04 | Araq | not from a technical point of view |
| 21:38:30 | Araq | but my guess is that it causes the optimization to be disappointing for most real world code |
| 21:39:03 | FromGitter | <Riderfighter> I got a sort of only the fly file encryption working :D |
| 21:39:07 | Araq | gokr, it uses a git submodule thingie |
| 21:39:39 | gokr | Araq: Aha, ok... (hi btw!) |
| 21:39:43 | Araq | hi |
| 21:40:51 | gokr | Ok, got it. I also had some funky error about resources.o on my virtual Win10 |
| 21:41:22 | FromGitter | <zacharycarter> the problem with the HCR bug I posted seems to be in using assert - I will update the issue |
| 21:41:30 | FromGitter | <zacharycarter> if I remove the asserts from my code - everything works as expected |
| 21:41:44 | FromGitter | <zacharycarter> so I think I've unblocked myself with Nim HCR - I just will avoid usage of assert |
| 21:42:03 | * | nif quit (Quit: ...) |
| 21:42:12 | Araq | maybe it's the 'raise' statement? |
| 21:42:12 | * | nif joined #nim |
| 21:42:22 | Araq | test it please |
| 21:42:36 | Araq | assert could also use quit() |
| 21:42:48 | Araq | and then you can use assert, it's such a useful thing |
| 21:43:10 | FromGitter | <zacharycarter> well I tried replacing the implementation of `failedAssertImpl` with `discard` |
| 21:43:26 | FromGitter | <zacharycarter> the only thing I found that worked was commenting out line 38 in `assertions.nim` |
| 21:43:34 | FromGitter | <zacharycarter> which calls `failedAssertImpl` |
| 21:43:44 | FromGitter | <zacharycarter> and replacing that call with a `discard` |
| 21:44:35 | FromGitter | <zacharycarter> however - when I do this and keep the asserts - my program still produces unexpected output |
| 21:44:38 | FromGitter | <zacharycarter> so something more sinister is lurking |
| 21:45:41 | FromGitter | <zacharycarter> or at least it produces different output with the omission of `--hotCodeReloading:on` |
| 21:45:58 | FromGitter | <zacharycarter> (the output I expect) |
| 21:47:32 | * | solitudesf quit (Ping timeout: 245 seconds) |
| 21:54:51 | FromGitter | <zacharycarter> replacing the implementation of `failedAssertImpl` - all the `Hide(...)(...)` stuff with a call to `quit()` makes the program run w/o crash but the output is still not right |
| 21:55:36 | disruptek | now you want correct output, too? pffbt. |
| 21:56:11 | FromGitter | <zacharycarter> :P last test - going to see if not calling `failedAssertImpl` at all and just calling quit(1) produces the expected output - if that's the case I think we can blame `failedAssertImpl` and perhaps the mixin |
| 21:56:16 | FromGitter | <zacharycarter> and nim hcr not liking them |
| 21:56:37 | FromGitter | <zacharycarter> and if that doesn't work then it's something to do with `assertImpl` |
| 21:57:04 | FromGitter | <zacharycarter> okay yeah - it's got something to do with `assertImpl` |
| 21:57:14 | FromGitter | <zacharycarter> not playing nice with NimHCR |
| 21:57:25 | FromGitter | <zacharycarter> maybe the dr memory output in the issue will help to point out why |
| 21:59:55 | FromGitter | <zacharycarter> this works - ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d47555b26e2732446184742] |
| 22:00:02 | FromGitter | <zacharycarter> :P |
| 22:00:54 | Araq | string concats? |
| 22:01:35 | FromGitter | <zacharycarter> I think it doesn't like `when enabled` |
| 22:01:48 | FromGitter | <zacharycarter> even if I remove the static qualifier from enabled |
| 22:01:53 | FromGitter | <zacharycarter> it still doesn't like `when enabled` |
| 22:02:24 | FromGitter | <zacharycarter> I mean - this is simple enough to work around though - just define your own assert impl |
| 22:02:50 | FromGitter | <zacharycarter> or define a separate one for Nim HCR - but I don't know how you would then regard the compile time assert on / off flag |
| 22:03:27 | FromGitter | <zacharycarter> and it also brings up the question - is any static check like this going to cause the same issue |
| 22:03:52 | Araq | the question is "what the heck are you doin'?" |
| 22:04:11 | Araq | static[bool] is just a type |
| 22:04:14 | FromGitter | <zacharycarter> :P the issue is here: https://github.com/nim-lang/Nim/issues/11718 |
| 22:04:19 | Araq | HCR doesn't care about types |
| 22:04:40 | FromGitter | <zacharycarter> right - and that's why I think the issue is with `when enabled` |
| 22:05:32 | FromGitter | <zacharycarter> when that check is present the output produced doesn't match the expected output that is produced when the `hotCodeReloading:on` switch is omitted |
| 22:06:40 | * | ldlework quit (Quit: co'o ro do) |
| 22:07:02 | * | ldlework joined #nim |
| 22:08:11 | * | gokr quit (Ping timeout: 268 seconds) |
| 22:08:55 | FromGitter | <zacharycarter> happy now though I can go back to using hcr :D |
| 22:11:20 | Araq | until the next bug that we don't understand |
| 22:11:38 | Araq | but hey, you can always not use system.& :P |
| 22:12:32 | FromGitter | <zacharycarter> haha |
| 22:13:00 | FromGitter | <zacharycarter> I wish I was smarter / could figure out the root cause of these things but I'm for now relegated to the end user realm |
| 22:13:03 | FromGitter | <zacharycarter> maybe one day that will change |
| 22:14:30 | shashlick | @zacharycarter once you are good, can you please share how you used hcr? |
| 22:14:40 | shashlick | I still need to figure out what I'll do next |
| 22:15:01 | FromGitter | <zacharycarter> sure - I'll probably throw away the nimscript stuff I had going tomorrow and go back to using HCR |
| 22:15:03 | FromGitter | <Riderfighter> One day I hope that I'll be able to repay all of those who have helped me :D |
| 22:16:21 | shashlick | Hopefully this vacation will pull me out of my funk |
| 22:16:25 | shashlick | Later folks |
| 22:16:43 | FromGitter | <zacharycarter> vacations are good for that |
| 22:16:50 | FromGitter | <zacharycarter> be safe and have fun! |
| 22:17:19 | FromGitter | <Riderfighter> have fun! |
| 22:19:51 | Araq | shashlick, do you also use Linux, occasionally? |
| 22:24:45 | FromGitter | <zacharycarter> yeah - getting rid of the `system.&` calls fixes the crash but still not the expected output |
| 22:24:47 | FromGitter | <Riderfighter> I believe that he got off :L |
| 22:26:34 | FromGitter | <zacharycarter> anyway - bedtime |
| 22:26:48 | FromGitter | <Riderfighter> cya! |
| 22:27:07 | FromGitter | <zacharycarter> ngiht |
| 22:29:36 | FromGitter | <Riderfighter> I guess on that note I might as well head off too. Thank you everyone for the help today! |
| 22:29:42 | FromGitter | <mratsim> good night |
| 22:33:17 | * | vivus joined #nim |
| 22:52:43 | * | sagax quit (Ping timeout: 246 seconds) |
| 23:04:28 | * | stefanos82 quit (Quit: Quitting for now...) |
| 23:23:13 | * | krux02_ joined #nim |
| 23:27:07 | * | krux02 quit (Ping timeout: 245 seconds) |
| 23:28:33 | * | sagax joined #nim |
| 23:35:45 | * | lritter quit (Ping timeout: 268 seconds) |
| 23:48:36 | * | vivus quit (Remote host closed the connection) |