| 00:05:50 | * | madpata joined #nim |
| 00:08:08 | * | TomDotTom joined #nim |
| 00:19:49 | Yardanico | !status |
| 00:19:50 | FromDiscord | Uptime - 1 day, 5 hours, and 4 minutes |
| 00:21:32 | FromDiscord | <Yardanico> why there's only 1 letter difference in idiom vs idiot 🤔 |
| 00:21:44 | * | manjaroi3_ joined #nim |
| 00:22:24 | * | manjaroi3_ quit (Client Quit) |
| 00:25:02 | * | TomDotTom quit (Ping timeout: 265 seconds) |
| 00:27:26 | FromDiscord | <Elegant Beef> Cause some idioms are idiotic |
| 00:29:21 | FromDiscord | <Yardanico> or some idiots are idiomatic? |
| 00:29:35 | xioren | https://www.youtube.com/watch?v=mqGMhe-DX2w |
| 00:36:34 | Yardanico | xioren: https://www.youtube.com/watch?v=rg_Pam__I8o has a bit similar tone |
| 00:36:51 | Yardanico | (warning: psychedelic images in the video :P) |
| 00:37:32 | xioren | nice1 |
| 00:38:39 | * | arecacea1 quit (Remote host closed the connection) |
| 00:38:42 | Yardanico | my full playlist is https://www.youtube.com/playlist?list=PLnthTbhS8ZO9m8nkK25JYC4CIphFvHk7r and it's very random |
| 00:39:14 | * | arecacea1 joined #nim |
| 00:41:08 | xioren | will bookmark it |
| 00:50:12 | FromDiscord | <InventorMatt> is this supposed to cause an error https://play.nim-lang.org/#ix=2AYw ? |
| 00:50:37 | disruptek | yeah. |
| 00:50:45 | * | abm quit (Quit: Leaving) |
| 00:51:35 | FromDiscord | <InventorMatt> how come having a bracket parameter prevents that borrow pragma from working then? |
| 00:52:02 | disruptek | borrow works to import a proc from the source type to the distinct. |
| 00:52:13 | disruptek | your distinct type lacks a generic V in its definition. |
| 00:52:33 | disruptek | the `.` operator isn't a thing without {.experimental: "dotOperators".} |
| 00:53:14 | disruptek | also, you perform the borrow like this: proc `.`[V](x: Bar[V]; field: string) {.borrow.} |
| 00:55:59 | FromDiscord | <InventorMatt> that is causing a new error https://play.nim-lang.org/#ix=2AYx |
| 00:56:22 | FromDiscord | <InventorMatt> saying there is no symbol to borrow from |
| 00:56:32 | disruptek | yes, well there wouldn't be, right? |
| 00:57:12 | disruptek | you just defined Foo. you need to define `.`[T](x: Foo; field: string): T first. |
| 00:57:34 | disruptek | or whatever. i forget the syntax for `.`(). |
| 00:57:41 | disruptek | it's in the experimental docs. |
| 00:57:43 | disruptek | ~concepts |
| 00:57:44 | disbot | concepts: 11user-defined type classes; documented in the experimental section of the manual: https://nim-lang.org/docs/manual_experimental.html#concepts -- disruptek |
| 00:58:29 | FromDiscord | <InventorMatt> yeah, i was just following the manual for that section and was wondering why adding the bracket paramater makes it stop working versus a normal distinct type |
| 00:58:59 | disruptek | because it's meaningless without a V on the rhs. |
| 01:00:57 | FromDiscord | <InventorMatt> i'm trying to convert arraymancer tensors into fixed size matrices using distinct types and using that was my best guess for creating shapes |
| 01:02:06 | disruptek | the V is a variable that represents a type, or in the case of a static, a value. you have to use it on both sides of the assignment for it to have meaning to the compiler. |
| 01:04:07 | FromDiscord | <InventorMatt> okay, I guess my idea for it is a dead end then |
| 01:04:09 | Yardanico | I guess it's time to join the cool kids club and make my README for my github profile |
| 01:04:22 | Yardanico | s/my R/a R |
| 01:04:36 | disruptek | your idea for it isn't a dead end, but it's challenging to use static generics. |
| 01:06:24 | FromDiscord | <InventorMatt> https://play.nim-lang.org/#ix=2AYB well this was my current idea for it. |
| 01:06:42 | FromDiscord | <InventorMatt> but it seems as though I'll need to try a different approach |
| 01:07:56 | disruptek | i use some static generics here: |
| 01:07:59 | disruptek | !repo gram |
| 01:07:59 | disbot | https://github.com/disruptek/gram -- 9gram: 11Generic graphs in Nim 15 11⭐ 1🍴 7& 4 more... |
| 01:08:21 | disruptek | it's a pain in the ass, honestly. |
| 01:10:05 | * | madpata quit (Ping timeout: 240 seconds) |
| 01:11:02 | xioren | bbl |
| 01:11:04 | * | xioren quit (Quit: leaving) |
| 01:11:57 | Yardanico | didn't know github would step that low |
| 01:12:01 | Yardanico | https://i.imgur.com/qZ9mqBs.png |
| 01:12:12 | Yardanico | second command will basically forcefully rename the current branch to "main" |
| 01:12:22 | Yardanico | and they don't even mention that this will do that |
| 01:12:49 | Yardanico | that's IMO not very cool |
| 01:13:00 | disruptek | weird. it's almost like they expect you to know how to use git on github. |
| 01:13:13 | Yardanico | disruptek: well tons of people who use github don't really know how to use git |
| 01:13:18 | Yardanico | they use IDEs and github's web interface |
| 01:13:20 | Yardanico | and never touch the cli |
| 01:13:35 | Yardanico | i didn't execute that command though :) |
| 01:24:37 | * | pbb quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:26:14 | * | pbb joined #nim |
| 01:29:03 | Prestige | Yardanico: Yeah, that's kinda crazy. |
| 01:29:04 | * | pbb quit (Client Quit) |
| 01:29:17 | Yardanico | you can change it, yes, but they made it "main" by default for ALL github users |
| 01:29:26 | Yardanico | you can change it in https://github.com/settings/repositories |
| 01:29:29 | * | pbb joined #nim |
| 01:29:34 | * | pbb quit (Client Quit) |
| 01:30:40 | leorize[m] | I don't mind "main" as default, but forcing a branch name change on an established repo is kinda ass |
| 01:31:23 | Yardanico | well, it's kind of tricky as well, they don't "force" since people can use different commands, but a lot of people will just copy-paste or re-type :) |
| 01:31:43 | FromDiscord | <Avatarfighter> i wont lie what yard said is making me wonder if i know how to make a git commit from the cli |
| 01:31:52 | Yardanico | git add changed_file |
| 01:31:55 | Yardanico | git commit -m "my message" |
| 01:32:06 | FromDiscord | <Avatarfighter> *shudders* |
| 01:32:45 | * | apahl quit (Ping timeout: 272 seconds) |
| 01:34:17 | * | apahl joined #nim |
| 01:35:51 | Prestige | Git gui programs make me nervous |
| 01:36:04 | Prestige | What will the button do!? |
| 01:39:12 | * | pbb joined #nim |
| 01:42:19 | FromDiscord | <Avatarfighter> yall use git? I just zip up my projects and title it "really works this time 1a" |
| 01:42:30 | * | xioren joined #nim |
| 01:43:49 | FromDiscord | <Avatarfighter> Oh wow thats a fun project idea |
| 01:43:59 | FromDiscord | <Avatarfighter> BudgetGit incoming |
| 01:49:15 | * | user0 joined #nim |
| 02:01:31 | * | a_chou joined #nim |
| 02:25:53 | * | gmaggior quit (Quit: Leaving) |
| 02:29:09 | * | a_chou quit (Remote host closed the connection) |
| 02:39:25 | * | muffindrake quit (Ping timeout: 240 seconds) |
| 02:41:52 | * | muffindrake joined #nim |
| 02:51:01 | leorize[m] | congrats you've invented cvs |
| 02:54:34 | FromDiscord | <Kreggy> rod |
| 02:54:43 | FromDiscord | <Kreggy> https://media.tenor.com/images/78577aa3c4ea9800563c83ff894da411/tenor.gif |
| 02:54:44 | FromDiscord | <Kreggy> https://media.tenor.com/images/78577aa3c4ea9800563c83ff894da411/tenor.gif |
| 02:54:44 | FromDiscord | <Kreggy> https://media.tenor.com/images/78577aa3c4ea9800563c83ff894da411/tenor.gif |
| 02:54:45 | FromDiscord | <Kreggy> https://media.tenor.com/images/78577aa3c4ea9800563c83ff894da411/tenor.gif |
| 02:54:46 | FromDiscord | <Kreggy> https://media.tenor.com/images/78577aa3c4ea9800563c83ff894da411/tenor.gif↵https://media.tenor.com/images/78577aa3c4ea9800563c83ff894da411/tenor.gif |
| 02:54:47 | FromDiscord | <Kreggy> https://media.tenor.com/images/78577aa3c4ea9800563c83ff894da411/tenor.gif |
| 02:55:40 | FromDiscord | <j❗> nimrod :troll: :troll: :troll: :troll: |
| 02:55:43 | FromDiscord | <j❗> https://media.discordapp.net/attachments/371759389889003532/766856939082219561/image0.gif |
| 02:55:43 | FromDiscord | <j❗> https://media.discordapp.net/attachments/371759389889003532/766856940545376257/image0.gif |
| 02:55:48 | FromDiscord | <j❗> https://media.discordapp.net/attachments/371759389889003532/766856960200015872/image0.gif |
| 02:55:50 | FromDiscord | <j❗> ☹️ https://media.discordapp.net/attachments/371759389889003532/766856969112780801/image0.gif |
| 02:55:54 | FromDiscord | <j❗> nobody else |
| 02:55:55 | FromDiscord | <j❗> Is here |
| 02:56:00 | FromDiscord | <Kreggy> I am here |
| 02:56:02 | FromDiscord | <j❗> Mods dont even do shit |
| 02:56:03 | FromDiscord | <j❗> wtf |
| 02:56:03 | FromDiscord | <Kreggy> The server is dead |
| 02:56:07 | FromDiscord | <j❗> yeah wtf |
| 02:56:14 | FromDiscord | <j❗> No point |
| 03:00:15 | FromDiscord | <colonthree> nimrod |
| 03:03:48 | FromDiscord | <Yardanico> -2 |
| 03:03:58 | FromDiscord | <Elegant Beef> Now on a scale of 0-10 how dumb would it be to make a PR wit this? https://github.com/beef331/Nim/commit/328b9d7638cb65d0e4d38dc0eb2b0b4b6c575a31 |
| 03:04:22 | * | krux02 quit (Remote host closed the connection) |
| 03:14:37 | xioren | yes |
| 03:14:45 | FromDiscord | <Elegant Beef> Cheers! |
| 03:20:50 | leorize[m] | @Yardanico sometimes I wish delete relays over to IRC :P |
| 03:21:11 | FromDiscord | <Yardanico> yeah these people were weird |
| 03:21:22 | FromDiscord | <Yardanico> Maybe they enjoy finding servers and spamming on them |
| 03:22:19 | FromDiscord | <Yardanico> I should've used the bridge's commands to ban them though, missed such an opportunity for a test :) |
| 03:22:55 | leorize[m] | :P |
| 03:24:22 | Yardanico | !getlastdisc |
| 03:24:38 | Yardanico | !getlastid |
| 03:24:40 | FromDiscord | UID of Yardanico who sent/edited a message most recently on Discord is 177365113899057152 |
| 03:25:15 | leorize[m] | I wonder when will Nim get popular enough to warrant a #nim-jobs channel |
| 03:25:40 | Yardanico | we already published a status job offer in discord announcements |
| 03:25:55 | leorize[m] | that's only one company |
| 03:29:18 | leorize[m] | wow Nim is still on the second page of HN |
| 03:37:57 | FromDiscord | <Yardanico> magic |
| 03:45:49 | leorize[m] | https://forum.nim-lang.org/t/6938 |
| 03:46:01 | leorize[m] | I guess we will have to wait for Araq to answer that one :P |
| 03:46:28 | leorize[m] | why are people so dead set on "it has to specialize into something" |
| 03:46:59 | Prestige | "Yes" |
| 03:47:14 | leorize[m] | I'd say that Nim is designed to be better than anything else :P |
| 03:47:18 | Prestige | world domination! |
| 04:00:50 | FromDiscord | <PizzaFox> nim compiler should emit efficient code for all build targets right |
| 04:01:01 | FromDiscord | <PizzaFox> surely js target can be optimized to not be so slow |
| 04:02:39 | FromDiscord | <PizzaFox> most obvious things is the unnecessarily large amount of code it emits |
| 04:02:51 | leorize[m] | someone actually benchmarked that mess |
| 04:02:54 | leorize[m] | it's fast |
| 04:03:21 | FromDiscord | <PizzaFox> i can make it faster 😈 |
| 04:03:23 | FromDiscord | <Yardanico> @PizzaFox try -d:danger but really it isn't slow |
| 04:03:45 | FromDiscord | <PizzaFox> i will now begin some nonscientific auditing of nim js compilation |
| 04:04:02 | leorize[m] | https://forum.nim-lang.org/t/2991#18807 |
| 04:04:15 | leorize[m] | this result is reallly old by now, so take it with a grain of salt |
| 04:04:40 | Prestige | dang, over 3 years ago |
| 04:04:45 | FromDiscord | <PizzaFox> v8 probably has gotten a lost faster since then |
| 04:04:47 | FromDiscord | <PizzaFox> wasm too i imagine |
| 04:05:09 | leorize[m] | and the JS backend received some optimization since |
| 04:05:10 | FromDiscord | <PizzaFox> plus that was a month before firefox quantum |
| 04:05:51 | leorize[m] | spidermonkey is never gonna be fast tbh |
| 04:06:00 | FromDiscord | <PizzaFox> microsoft jscript best runtime |
| 04:06:01 | * | supakeen quit (Quit: WeeChat 2.9) |
| 04:06:09 | FromDiscord | <PizzaFox> apples webkit one is unironically crazy fast |
| 04:06:15 | FromDiscord | <PizzaFox> lemme find this regex benchmark |
| 04:06:37 | * | supakeen joined #nim |
| 04:07:06 | leorize[m] | don't know if jscore is actually faster than spidermonkey |
| 04:07:52 | leorize[m] | on linux you can use gnome web (webkit-based) to run the bench |
| 04:08:05 | leorize[m] | on windows there aren't any browser based on webkit though |
| 04:08:48 | FromDiscord | <PizzaFox> https://media.discordapp.net/attachments/371759389889003532/766875332128014366/69646362.png |
| 04:09:10 | FromDiscord | <PizzaFox> this is log scale https://media.discordapp.net/attachments/371759389889003532/766875426462498866/69646238.png |
| 04:09:11 | * | arecacea1 quit (Remote host closed the connection) |
| 04:09:35 | * | arecacea1 joined #nim |
| 04:09:47 | FromDiscord | <PizzaFox> (edit) 'this is' => '⬆️ linear and' | 'scale' => '⬇️' |
| 04:11:23 | FromDiscord | <PizzaFox> > Python is clearly the loser↵i think of this nim blog quote once again |
| 04:11:51 | leorize[m] | jscore is faster than rust what? |
| 04:12:02 | FromDiscord | <PizzaFox> for that specific regex, yes |
| 04:12:52 | FromDiscord | <Elegant Beef> 0/10 no nimscript there |
| 04:13:09 | FromDiscord | <PizzaFox> i asked the graph creator for their data |
| 04:13:11 | leorize[m] | can nim-regex match at ct? |
| 04:13:47 | FromDiscord | <Elegant Beef> No dont think so |
| 04:14:08 | FromDiscord | <Elegant Beef> It's an impure library no? |
| 04:14:19 | leorize[m] | nim-regex is pure nim |
| 04:14:32 | FromDiscord | <Elegant Beef> Ah my bad |
| 04:14:33 | leorize[m] | !repo nim-regex |
| 04:14:34 | disbot | https://github.com/nitely/nim-regex -- 9nim-regex: 11Pure Nim regex engine. Guarantees linear time matching 15 97⭐ 13🍴 7& 2 more... |
| 04:15:19 | FromDiscord | <PizzaFox> https://docs.google.com/spreadsheets/d/15k6LZjn6t_lpF4k1f5UNuFf2egLbfKwGO9gSUei4COY/edit |
| 04:15:39 | FromDiscord | <PizzaFox> csv for future generations reading the chatlogs https://media.discordapp.net/attachments/371759389889003532/766877058885615626/RegExp_Benchmarks_-_Sheet1.csv |
| 04:17:01 | leorize[m] | it's useless without the benchmark code :P |
| 04:17:17 | FromDiscord | <PizzaFox> just realized |
| 04:19:38 | FromDiscord | <PizzaFox> well the benchmarks are pretty self explanatory |
| 04:19:57 | FromDiscord | <PizzaFox> only compiled lang there is rust which is just `cargo run --release` |
| 04:21:36 | FromDiscord | <slymilano> hello gents! I have a `seq[Person]` how can I render that seq as json in jester? i hope i don't have to define my own operator 😦 |
| 04:22:33 | leorize[m] | @slymilano `import json; echo %seqHere` |
| 04:22:36 | FromDiscord | <PizzaFox> can a Person be represented in json |
| 04:23:22 | leorize[m] | ```json.`%` ``` can convert just about anything into json |
| 04:23:23 | FromDiscord | <slymilano> damn it feels good, looking great! thank you leorize |
| 04:23:33 | FromDiscord | <slymilano> import json and badabing |
| 04:27:23 | * | shinzo joined #nim |
| 04:36:25 | * | NimBot joined #nim |
| 04:39:03 | FromDiscord | <Elegant Beef> Still concerned how not do bodge arround incorrect nimscript using `evalScript` |
| 04:39:04 | * | user0 quit (Ping timeout: 272 seconds) |
| 04:53:17 | leorize[m] | Zevv saw this on HN https://news.ycombinator.com/item?id=24804223 |
| 04:54:11 | FromDiscord | <PizzaFox> looks cool |
| 05:06:10 | Zevv | toooo late |
| 05:06:24 | Zevv | I GPLed :) |
| 05:06:42 | Zevv | but it is indeed kind of what I needed the other day, thanks man |
| 05:16:16 | FromDiscord | <slymilano> Is Jester latest broken for anyone else? I'm getting build errors on my github action. https://github.com/sergiotapia/torrentinim/runs/1267664511 |
| 05:16:32 | FromDiscord | <slymilano> `/home/runner/.nimble/pkgs/jester-0.4.3/jester.nim(704, 26) Error: undeclared identifier: 'initInterval'` |
| 05:19:39 | * | solitudesf joined #nim |
| 05:23:36 | FromDiscord | <flywind> Use jester@#head if using latest Nim version. |
| 05:28:32 | FromDiscord | <slymilano> Thanks for the tip, I actually specified my nim version to 1.2.6 as opposed to `stable` |
| 05:36:51 | leorize[m] | @dom96 you should tag a new jester version |
| 05:40:04 | FromDiscord | <PizzaFox> hey guys remember that regex benchmarking thing |
| 05:40:15 | FromDiscord | <PizzaFox> idk if i am at fault here but i uhh ummm |
| 05:40:22 | FromDiscord | <PizzaFox> nim is crazy crazy slow |
| 05:41:08 | FromDiscord | <PizzaFox> https://play.nim-lang.org/#ix=2AZn |
| 05:41:11 | FromDiscord | <flywind> I remember `nim-regex` was slower than stdlib. |
| 05:41:20 | FromDiscord | <PizzaFox> using regular `re` from stdlib |
| 05:41:57 | FromDiscord | <PizzaFox> sent a code paste, see https://play.nim-lang.org/#ix=2AZo |
| 05:43:26 | FromDiscord | <PizzaFox> its literally 10x slower than python |
| 05:43:31 | FromDiscord | <PizzaFox> how is this possible |
| 05:43:39 | FromDiscord | <PizzaFox> is pcre that unoptimize |
| 05:43:41 | FromDiscord | <PizzaFox> (edit) 'unoptimize' => 'unoptimized' |
| 05:46:01 | FromDiscord | <flywind> what's your compilation flags? |
| 05:46:09 | FromDiscord | <PizzaFox> -d:release |
| 05:46:20 | FromDiscord | <PizzaFox> also i possibly am stupid 1 sec lemme perform sanity check |
| 05:47:49 | FromDiscord | <flywind> Could you benchmark more basic operation? I think your program contains lots of string allocation. |
| 05:48:21 | FromDiscord | <PizzaFox> i will make a repo shortly |
| 05:48:24 | FromDiscord | <PizzaFox> 1 sec |
| 05:49:19 | FromGitter | <jrfondren> what are you benchmarking there? I would expect a regex benchmark to run a regex against a bunch of text. |
| 05:50:03 | FromDiscord | <PizzaFox> simply wait for my repo |
| 05:50:07 | FromDiscord | <flywind> https://github.com/nitely/nim-regex/pull/58 |
| 05:50:09 | disbot | ➥ NFA macro + better NFA matcher |
| 05:50:39 | FromDiscord | <flywind> Some benchmarks between `re` and `nim-regex`. |
| 05:52:16 | FromDiscord | <flywind> https://github.com/mariomka/regex-benchmark |
| 05:52:50 | FromDiscord | <flywind> This regex benchmark shows that re is really fast in some operations. |
| 05:56:22 | FromDiscord | <nikki> is it possible to do enough flow analysis to build something like rust's borrow checker using just nim macros? even if say you have to wrap the code with the macro, or annotate parameter and return types in functions with borrowing tags (eg. returns / takes an owned vs. borrowed ref and so on) |
| 05:57:24 | FromDiscord | <nikki> (independently of how useful / effective / tractable that would be in practice, just about the possibility) |
| 05:59:24 | FromDiscord | <Elegant Beef> I believe 1.4 introduces features have borrow checking |
| 05:59:28 | FromDiscord | <Elegant Beef> (edit) 'I believe 1.4 introduces features ... have' => 'I believe 1.4 introduces featuresto' |
| 06:07:03 | FromDiscord | <PizzaFox> ok repo is here https://github.com/pizzafox/regex-bench |
| 06:07:08 | FromDiscord | <PizzaFox> for regex benchmarks |
| 06:07:12 | xioren | ./QUIT |
| 06:07:16 | * | xioren quit (Quit: leaving) |
| 06:07:31 | FromDiscord | <PizzaFox> (edit) 'benchmarks' => 'benchmarks↵unfortunately my gcc has totally fucked itself and i cant install libc anymore, so someone else please bench it' |
| 06:09:26 | * | leorize quit (Remote host closed the connection) |
| 06:10:15 | * | leorize joined #nim |
| 06:13:56 | leorize[m] | @nikki you can but it's impractical |
| 06:14:38 | leorize[m] | (not to mention the amount of bugs you might stumble along the road) |
| 06:16:18 | FromGitter | <jrfondren> PCRE isn't slow, but this is a benchmark designed to punish it. I think https://github.com/jrfondren/topsender-bench is a lot more realistic as a test, though that's old and you can't even run it without a large exim log handy. That one just runs a single reasonable regex against a bunch of text, and then reports on it. (the higher nim times there are due to an ancient defect in CountTable.sort) |
| 06:16:58 | FromGitter | <jrfondren> I ran your benchmark anyway with hyperfine and get Rust as 3.66 times faster than Python, and 666 times faster than Nim. |
| 06:16:58 | leorize[m] | looks like I'll get to try rust |
| 06:19:08 | FromDiscord | <Elegant Beef> "get to"? |
| 06:19:32 | leorize[m] | @PizzaFox nim-regex is much much faster, try that instead |
| 06:19:40 | FromDiscord | <PizzaFox> >:( |
| 06:19:42 | FromDiscord | <PizzaFox> ok |
| 06:21:18 | FromGitter | <jrfondren> it might be faster on benchmarks exactly like this, and not at all in practice. Actually I just remembed, the 30s time there is nim-regex, and although it's an ancient regex people said the same thing to me at the time. Oh just use this, it's better. |
| 06:22:40 | FromGitter | <jrfondren> if you're not building regexes at runtime from potentially abusive input then this stuff just doesn't matter at all. A regex like a?a?a?a?a?a?aaaaa is a bug. |
| 06:25:28 | leorize[m] | that's the pitfall of micro benchmarks |
| 06:30:23 | * | leorize quit (Ping timeout: 240 seconds) |
| 06:42:44 | FromDiscord | <nikki> maybe nim's compile time code stuff is a good fit for compile time construction of a regex matcher |
| 06:42:51 | FromDiscord | <nikki> that then optimizes down |
| 06:43:08 | FromDiscord | <nikki> https://github.com/hanickadot/compile-time-regular-expressions |
| 06:43:40 | FromDiscord | <nikki> ^ like this except in a lang where u can actually use the normal lang for compile time stuff in a normal way |
| 06:44:44 | leorize[m] | we have npeg for PEGs that can construct a parser at compile time |
| 06:44:46 | leorize[m] | !repo npeg |
| 06:44:47 | disbot | https://github.com/zevv/npeg -- 9npeg: 11PEGs for Nim, another take 15 120⭐ 7🍴 |
| 06:44:58 | leorize[m] | nim-regex can also do that iirc |
| 06:45:16 | * | leorize joined #nim |
| 06:45:40 | FromDiscord | <nikki> kewl |
| 06:58:54 | Zevv | kewl, right! |
| 07:10:15 | leorize[m] | hmm, there's a ~6 months gap between 1.0.0 and 1.2.0 |
| 07:10:26 | leorize[m] | and ~6 months gap between 1.2.0 and 1.4.0 |
| 07:10:33 | leorize[m] | we, uh, got a schedule now? |
| 07:13:52 | supakeen | scheduleee |
| 07:13:58 | FromDiscord | <flywind> sent a code paste, see https://play.nim-lang.org/#ix=2AZD |
| 07:14:52 | FromDiscord | <flywind> I think macros/templates doesn't like generics, I have to use `mixin`. |
| 07:15:37 | leorize[m] | it's an expected interaction |
| 07:16:12 | FromDiscord | <flywind> Is it documented? |
| 07:17:25 | FromDiscord | <flywind> But people may be not know `await` is a templates. |
| 07:17:32 | FromDiscord | <flywind> (edit) 'may be' => 'maybe' |
| 07:17:48 | FromDiscord | <flywind> It just gave: Error: undeclared identifier: 'await' |
| 07:20:35 | leorize[m] | like everything related to asyncdispatch, it's not fully documented |
| 07:21:09 | FromDiscord | <flywind> yea, I agree. |
| 07:26:35 | FromGitter | <jrfondren> s/asyncdispatch/nim/ . `let x, y = (1, 2)` has a warning, but it doesn't have documentation, and I just wrote a program to confirm that `let x, y = SomeObj(1, 2)` constructs two objects. Just before that I re-learned that re's =~ has an implicit ^ anchor, unlike other languages with the syntax, and there spent some minutes WTFing before carefully working it out in inim. The 're' docs don't spell this out. |
| 07:30:28 | leorize[m] | would you mind creating a PR/issue for `re` behavior? |
| 07:31:22 | leorize[m] | I actually never know that `let x, y = (1, 2)` is possible |
| 07:31:27 | leorize[m] | ping Araq I guess? |
| 07:31:54 | FromGitter | <jrfondren> ping him about it being possible? It has a dedicated warning. |
| 07:32:05 | FromGitter | <jrfondren> it makes sense as a generalization of `var x, y: int` |
| 07:32:36 | leorize[m] | yea but I'm not sure if the behavior when something is assigned is documented in the spec |
| 07:35:48 | FromGitter | <jrfondren> of re... it looks like I never creating anything for that. I probably talked about it here and then left it at that. It's normal to learn things about a language, so once I griped about how surprising it was I probably accepted it as something I'd learned, without noticing the oddity: that it's not normal to learn things and then not find those things documented clearly |
| 07:37:02 | FromGitter | <jrfondren> I'm writing this stuff down now. I'll see about contributing it back |
| 07:37:09 | supakeen | dom96: I updated the parseHeader PR, if that's the right way to do it I have no problem also taking a stab at how it's used in asynchttpserver/friends. |
| 07:52:20 | * | vicfred quit (Quit: Leaving) |
| 08:04:36 | FromDiscord | <acek7> oh man theres so much more organization now |
| 08:08:54 | FromDiscord | <Elegant Beef> Huh? |
| 08:09:08 | FromDiscord | <acek7> the channels are organized |
| 08:09:14 | FromDiscord | <acek7> i havent checked iin a bit |
| 08:12:44 | FromDiscord | <Elegant Beef> Ah, yea it was very disordered |
| 09:17:15 | * | Vladar joined #nim |
| 09:32:51 | * | kenran joined #nim |
| 09:36:30 | FromDiscord | <Recruit_main707> compiling with --threads:on makes the program slower when you dont use them... |
| 09:42:42 | * | hnOsmium0001 quit (Quit: Connection closed for inactivity) |
| 09:43:58 | * | arecacea1 quit (Remote host closed the connection) |
| 09:44:30 | * | arecacea1 joined #nim |
| 09:45:58 | * | Zeedox joined #nim |
| 09:50:05 | * | kenran quit (Ping timeout: 240 seconds) |
| 09:52:30 | * | nature joined #nim |
| 09:54:59 | FromGitter | <jrfondren> how much slower? |
| 10:03:11 | * | bung joined #nim |
| 10:05:12 | * | FromGitter quit (Remote host closed the connection) |
| 10:05:12 | * | oprypin quit (Quit: Bye) |
| 10:05:30 | * | oprypin joined #nim |
| 10:05:42 | * | FromGitter joined #nim |
| 10:22:08 | FromDiscord | <dom96> > @dom96 you should tag a new jester version↵@leorize[Matrix] will do |
| 10:39:14 | bung | the asyncdispatch.addRead called when start reading or after reading ? |
| 10:50:21 | FromDiscord | <dom96> when you want to do a read |
| 10:53:23 | bung | ok I get it. |
| 10:57:10 | FromDiscord | <dom96> New Jester version tagged 🙂 |
| 10:58:10 | FromDiscord | <dom96> choosenim ends up installing itself to CWD... |
| 10:58:16 | FromDiscord | <dom96> that's a pretty showstopper bug |
| 11:02:19 | FromGitter | <jrfondren> oh, choosenim also doesn't work on CentOS 6. That's end-of-lifed in a month |
| 11:20:27 | * | fredrikhr joined #nim |
| 11:21:49 | FromDiscord | <dom96> 0.7.0? or the earlier version |
| 11:22:03 | FromDiscord | <dom96> the newest version should work hopefully on anything, since it's all statically linked now |
| 11:24:00 | * | Zeedox quit (Remote host closed the connection) |
| 11:24:22 | FromGitter | <jrfondren> the one you get from `curl https://nim-lang.org/choosenim/init.sh -sSf | sh`. it definitely requires a glibc newer than 2011 edition |
| 11:24:49 | FromGitter | <jrfondren> looks like that's 0.6.0 |
| 11:26:42 | FromGitter | <jrfondren> choosenim-0.6.0_linux_amd64 . It actually still wouldn't work if it were statically linked though, because the system gcc on CentOS 6 is too old to build Nim's pregenerated C sources |
| 11:27:39 | FromGitter | <jrfondren> solution is to use a newer build system through SCL. This isn't a hit on Nim. Pretty much anything not old enough to have a CentOS 6 rpm is going to hit this. |
| 11:28:05 | FromGitter | <jrfondren> I just mentioned it because I'd just tried to use choosenim on a CentOS 6 box. |
| 11:52:30 | * | hyiltiz quit (Remote host closed the connection) |
| 11:54:40 | * | krux02 joined #nim |
| 12:01:28 | federico3 | dom96: Nimble appears to be missing in the source package on https://nim-lang.org/install_unix.html |
| 12:03:52 | FromGitter | <jrfondren> nimble's built by the './koch tools' step |
| 12:06:01 | * | supakeen quit (Quit: WeeChat 2.9) |
| 12:06:33 | * | supakeen joined #nim |
| 12:34:23 | bung | send a codepaste https://play.nim-lang.org/#ix=2B0Y how to simplely make this work, variable conn is outside of callback |
| 12:48:31 | FromDiscord | <PizzaFox> javascript and c have such similar syntax you could just use c2nim on js code right |
| 12:49:24 | FromDiscord | <PizzaFox> (edit) 'javascript and c have such similar syntax you could just use c2nim on ... js' => 'javascript and c have such similar syntax you could just use c2nim on(some)' |
| 12:54:35 | dv^_^ | int c = 2; foo(&c); how do I do this in nim? |
| 12:54:55 | ehmry | how often does this tarball change? -> https://nim-lang.org/download/nim-1.4.0.tar.xz |
| 12:55:36 | * | noonien joined #nim |
| 12:57:42 | FromGitter | <jrfondren> dv^_^: https://play.nim-lang.org/#ix=2B12 |
| 12:59:05 | dv^_^ | jrfondren: hmm ok thanks |
| 12:59:11 | supakeen | huh |
| 12:59:32 | supakeen | dv^_^: https://play.nim-lang.org/#ix=2B16 |
| 13:02:10 | dv^_^ | what about struct widget { shared_ptr<int> val; } w; shared_ptr<int> c = make_shared<int>(2); w.val = c |
| 13:02:38 | supakeen | I can't read C++, what does that do? |
| 13:02:52 | dv^_^ | basically I have a widget, and I want a pointer to some int that changes all the time |
| 13:02:56 | dv^_^ | a UI widget |
| 13:03:14 | dv^_^ | or a reference. preferably safe code |
| 13:03:30 | leorize[m] | federico3: that's my fault, I got a brainfart writing this code: https://github.com/nim-lang/nightlies/blob/43d01629621ce879ef81e130e42ff05cd6c0702e/.github/workflows/nightlies.yml#L225 |
| 13:03:38 | supakeen | I don't think that can be done safely but what jrfondren showed gets close, you can get the unsafeAddr and store it somewhere as they showed. |
| 13:04:19 | leorize[m] | federico3: that will be sorted on later patch releases |
| 13:05:03 | federico3 | urgh |
| 13:05:22 | leorize[m] | ehmry: it won't. There was an issue during release which is why it got re-released |
| 13:08:05 | * | noonien quit () |
| 13:08:14 | dv^_^ | supakeen, so what's the pattern to use if I want two variables to point to the same data safely? |
| 13:12:37 | ehmry | leorize[m]: and nimble will be no longer bundled at dist/nimble? |
| 13:13:55 | FromGitter | <jrfondren> dv^_^: https://play.nim-lang.org/#ix=2B1d |
| 13:14:15 | leorize[m] | ehmry: that's largely my fault, I'm patching it but it won't get released until the next patch release |
| 13:16:03 | ehmry | leorize[m]: ok, np |
| 13:20:22 | bung | forget my question. |
| 13:21:29 | FromGitter | <jrfondren> dv^_^: well, better example: https://play.nim-lang.org/#ix=2B1f |
| 13:21:44 | FromGitter | <jrfondren> bung, have you given up on getting an answer or did you figure it out? |
| 13:22:17 | bung | asyncdispatch Callback returns means it will not block asyncdispatch polling ? |
| 13:23:15 | bung | jrfondren first I miss param fd:AsyncFD then the compilation pass, second I change callback returns true otherwise program blocked |
| 13:24:09 | bung | I debug info ouputs to console inside callback seems works correct. |
| 13:24:11 | * | lbart quit (Read error: Connection reset by peer) |
| 13:29:07 | dv^_^ | jrfondren, hmm, thanks |
| 13:29:07 | * | lbart joined #nim |
| 13:29:08 | * | lbart quit (Changing host) |
| 13:29:08 | * | lbart joined #nim |
| 13:36:32 | bung | hmm no, it should return false , but it will cause program stucked. |
| 13:38:58 | * | Lord_Nightmare quit (Ping timeout: 260 seconds) |
| 13:45:12 | bung | my bad `If you use this function, you don't need to use asyncdispatch.send() or asyncdispatch.connect()` |
| 13:53:22 | bung | I notice addTimer when oneshot is false the callback should return false , otherwise oneshot has no meaning |
| 14:03:48 | * | lbart quit (Ping timeout: 256 seconds) |
| 14:06:22 | * | lbart joined #nim |
| 14:06:22 | * | lbart quit (Changing host) |
| 14:06:22 | * | lbart joined #nim |
| 14:14:51 | * | arecacea1 quit (Remote host closed the connection) |
| 14:15:34 | * | arecacea1 joined #nim |
| 14:26:16 | * | njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 14:26:22 | * | njoseph joined #nim |
| 14:43:20 | FromDiscord | <dom96> > dom96: Nimble appears to be missing in the source package on https://nim-lang.org/install_unix.html↵@federico3 yeah, not really my domain anymore I'm afraid |
| 14:54:46 | * | nc-x joined #nim |
| 14:55:22 | * | nc-x quit (Remote host closed the connection) |
| 15:02:15 | disruptek | bob marley sucks. |
| 15:05:14 | disruptek | c'mon, i know you're all thinking it. |
| 15:06:47 | mipri | nah I haven't thought about bob marley for almost 40 years now |
| 15:09:42 | Oddmonger | raggae sucks |
| 15:25:25 | * | FromDiscord quit (Remote host closed the connection) |
| 15:25:38 | * | FromDiscord joined #nim |
| 15:25:38 | disruptek | no, it's not reggae, it's his whiny fuckin' voice. |
| 15:26:19 | FromDiscord | <exelotl> 10 year old me agrees with you |
| 15:26:26 | disruptek | his music is boring, and that's about the worst insult i can think of. |
| 15:32:48 | * | arecacea1 quit (Remote host closed the connection) |
| 15:33:10 | Zevv | the music was all that brought me to disruptek-tv |
| 15:33:16 | Zevv | his programming was mediocre, at most |
| 15:33:19 | Zevv | but the music, man |
| 15:33:21 | Zevv | the music! |
| 15:33:44 | disruptek | maybe by the end of the year. |
| 15:33:54 | FromDiscord | <Clyybber> his song has a nice track |
| 15:33:54 | FromDiscord | <Clyybber> https://www.youtube.com/watch?v=AkXVBRV1vWo |
| 15:33:58 | FromDiscord | <Clyybber> *son |
| 15:33:59 | Zevv | what happens then |
| 15:34:52 | disruptek | i might learn how to code. |
| 15:39:12 | * | arecacea1 joined #nim |
| 15:47:32 | FromDiscord | <dom96> New choosenim finally released 🙂 |
| 15:47:40 | FromDiscord | <dom96> Everybody update via `choosenim update self` |
| 15:47:45 | disruptek | dom96: what do you make of this? |
| 15:47:48 | disruptek | https://github.com/disruptek/Nim/runs/1266970425?check_suite_focus=true#step:11:669 |
| 15:48:43 | FromDiscord | <Clyybber> the Prologue failure? |
| 15:48:59 | disruptek | well, nimble claims head is not >= 1.4.0 |
| 15:49:16 | disruptek | yes, it's prologue. |
| 15:49:23 | FromDiscord | <dom96> @shashlick you got a twitter? |
| 15:49:43 | FromDiscord | <dom96> found it |
| 15:50:52 | FromDiscord | <shashlick> Yep what about it |
| 15:51:31 | FromDiscord | <dom96> gonna tweet about new choosenim and wanted to thank you 🙂 |
| 15:52:24 | FromDiscord | <shashlick> Oh 👍 |
| 15:52:43 | disruptek | i named my 7th daughter shashlick. |
| 15:52:59 | disruptek | $deity's gift to nim. |
| 15:53:00 | stefantalpalaru | Nim-1.4 seems to have a more strict "has to be used (or discarded)" check that prevents templates from being used as rvalues. Is there a workaround? |
| 15:54:22 | FromDiscord | <shashlick> I don't use Twitter anymore except to grumble about some product every few years |
| 15:55:54 | FromDiscord | <dom96> shashlick can you test via `choosenim update self`? 🙂 |
| 15:56:16 | disruptek | that's putting the cart before the horse, isn't it? |
| 15:56:23 | FromDiscord | <dom96> just in case I missed something |
| 16:01:41 | * | Prestige quit (Ping timeout: 272 seconds) |
| 16:04:13 | * | Prestige joined #nim |
| 16:06:12 | FromDiscord | <shashlick> Will in a bit |
| 16:06:30 | FromDiscord | <Clyybber> stefantalpalaru: Do you have an example? |
| 16:08:19 | disruptek | Araq: can we gate new concepts or something? they are blocking a few projects now. |
| 16:09:06 | FromDiscord | <Clyybber> whats blocking? |
| 16:09:29 | disruptek | concepts? i dunno. |
| 16:09:43 | disruptek | i think dict is impl so i'm not sure what remained. |
| 16:09:43 | FromDiscord | <Recruit_main707> https://tenor.com/view/confused-what-nigga-please-really-loop-gif-4966361 |
| 16:10:25 | * | Lord_Nightmare joined #nim |
| 16:10:26 | disruptek | damnit discord. |
| 16:10:28 | FromDiscord | <Clyybber> hmm, what does to gate mean |
| 16:10:28 | FromDiscord | <Clyybber> lol |
| 16:10:35 | disruptek | put behind a switch. |
| 16:10:53 | FromDiscord | <Clyybber> and what needs the new concepts? |
| 16:11:16 | FromDiscord | <Vindaar> dude that gif is hella disorienting |
| 16:11:21 | disruptek | nimph, frosty, jason, i would pretty much use them everywhere. |
| 16:11:35 | FromDiscord | <Clyybber> why don't the current concepts work? |
| 16:11:47 | FromDiscord | <Clyybber> bugs, I guess, but we need reports to fix them |
| 16:11:49 | disruptek | because the compiler is dumb. |
| 16:11:57 | disruptek | we aren't fixing them afaik. |
| 16:12:41 | FromDiscord | <Clyybber> I want to |
| 16:12:59 | FromDiscord | <Clyybber> they are more universal than the new ones |
| 16:13:00 | disruptek | why? we already have a new rfc'd impl. |
| 16:13:12 | FromDiscord | <Clyybber> well, its not tested, I doubt its better |
| 16:13:15 | disruptek | iiuc, the differences are merely syntactic. |
| 16:13:47 | FromDiscord | <Clyybber> no, theres some shortcutting, which is fine, but shouldn't be tied to the new syntax |
| 16:13:56 | FromDiscord | <Clyybber> the new syntax can be accomplished by macros as well |
| 16:14:09 | FromDiscord | <Clyybber> I wrote a small prototype demonstrating it |
| 16:14:16 | disruptek | i know, that's my point. |
| 16:14:28 | FromDiscord | <Clyybber> surely frosty isn't blocked by syntax |
| 16:14:31 | disruptek | are you saying the new concepts are a subset of the old ones? |
| 16:14:36 | FromDiscord | <Clyybber> yeah |
| 16:14:51 | FromDiscord | <Clyybber> they can't replace them |
| 16:14:51 | disruptek | well, i thought we successfully argued against that. |
| 16:15:07 | disruptek | oh, the new syntax is already in? |
| 16:15:19 | disruptek | let's call the new syntax "user typeclasses". |
| 16:15:44 | FromDiscord | <Clyybber> no its not |
| 16:15:51 | FromDiscord | <Clyybber> its not in devel if you mean that |
| 16:15:54 | disruptek | right. |
| 16:16:02 | FromDiscord | <Clyybber> lets simply not have a new syntax :P |
| 16:16:07 | disruptek | well, you can run groups in nimph if you wanna see what breaks. |
| 16:16:09 | FromDiscord | <Clyybber> and instead flesh out the macro |
| 16:16:16 | disruptek | https://github.com/disruptek/nimph/blob/denimble/nimph/groups.nim |
| 16:16:34 | FromDiscord | <Clyybber> disruptek: I probably won't be able to tell what breaks because I can't be sure that its not a user error |
| 16:16:38 | FromDiscord | <Clyybber> and nimph is so big |
| 16:17:03 | FromDiscord | <Clyybber> can't you run dust on it? |
| 16:17:03 | disruptek | you're just running on file, not the whole thing. |
| 16:17:09 | FromDiscord | <Clyybber> ah ok |
| 16:17:35 | disruptek | dust might work now, if i fix it after araq's breakage. i can't remember if i impl imports for dust. |
| 16:17:56 | FromDiscord | <Clyybber> oh, so the imports are required? |
| 16:17:57 | disruptek | anyway, groups.nim is just a test of concepts. |
| 16:18:14 | FromDiscord | <dom96> Just avoid concepts tapshead.gif |
| 16:18:26 | FromDiscord | <Clyybber> just fix them tapsheadmore.gif |
| 16:18:44 | disruptek | i avoided them for a year. finally asked for the 10th time if they were safe and was told they were. |
| 16:18:58 | disruptek | as soon as i started using them, we got a new impl and i discovered how broken they are. |
| 16:19:03 | FromDiscord | <lqdev> haha! fool |
| 16:19:10 | disruptek | but i already have a bunch of stuff using them. irritating. |
| 16:19:16 | FromDiscord | <lqdev> you got hooked just like me… |
| 16:19:22 | disruptek | i know. |
| 16:19:28 | disruptek | and the crazy thing is, i knew it. |
| 16:19:31 | disruptek | i fucking knew it. |
| 16:19:32 | FromDiscord | <Clyybber> disruptek: can you minimize it to a self-contained one file thing? |
| 16:19:42 | FromDiscord | <Clyybber> I'll get to it as soon as I'll solve this bug |
| 16:19:43 | disruptek | i dunno, i'm working on mangling. |
| 16:19:50 | FromDiscord | <Clyybber> aight |
| 16:19:53 | FromDiscord | <Clyybber> no hurry |
| 16:19:53 | disruptek | we can make a date to pair it later. |
| 16:20:12 | disruptek | i gave up on araq's mangling method. |
| 16:20:19 | disruptek | it just doesn't work, "i don't care." |
| 16:20:29 | FromDiscord | <Clyybber> what is the difference |
| 16:20:36 | disruptek | no global analysis. |
| 16:20:50 | FromDiscord | <Clyybber> yours doesn't do global analysis? |
| 16:20:54 | disruptek | mine does. |
| 16:21:33 | disruptek | i will concede that it's possible that a flaw in the frontend is breaking the backend, but i just don't want this pr to touch the frontend if i can help it. |
| 16:21:59 | FromDiscord | <Clyybber> have you tracked it down,? |
| 16:22:01 | disruptek | i would rather get this working in the backend, do ic, and then reimpl the backend so that frontend flaws stay in the frontend. |
| 16:22:12 | disruptek | i wrote some shit logic to track it down, yes. |
| 16:22:16 | FromDiscord | <Clyybber> frontend flaws shouldn't stay anywhere |
| 16:22:26 | FromDiscord | <Clyybber> frontend flaws should be fixed |
| 16:22:26 | disruptek | easy for you to say. |
| 16:22:41 | disruptek | dude, have you paid any attention to how this compiler gets written? 🤣 |
| 16:23:47 | FromDiscord | <Clyybber> first we must identify the flaw |
| 16:23:58 | disruptek | well, that's what my logic does. |
| 16:24:06 | FromDiscord | <Clyybber> and what is the flaw? |
| 16:24:11 | disruptek | i realized that i could communicate better in code than in text. |
| 16:24:29 | FromDiscord | <Clyybber> i cannot read your code 🤣 |
| 16:24:38 | FromDiscord | <Clyybber> half-kidding |
| 16:24:45 | disruptek | i didn't say there was a flaw. but the logic will represent the needs of the backend according to what the frontend provides. |
| 16:25:02 | FromDiscord | <Clyybber> how can you workaround a flaw that you don't know what it is? |
| 16:25:04 | disruptek | and if we don't like what the backend requires, we can fix the frontend to provide better input. |
| 16:25:13 | FromDiscord | <Clyybber> yeah |
| 16:25:22 | disruptek | you have to understand that the mangling introduces a new spec. |
| 16:25:33 | disruptek | i don't know if the frontend adheres to that spec or not. |
| 16:25:49 | FromDiscord | <Clyybber> wheres that spec written down |
| 16:25:53 | FromDiscord | <Clyybber> or whats the gist of it? |
| 16:26:10 | disruptek | norm has a runtime crash under mangling. i don't know if this is my fault or if there's a bug in the frontend that my new spec exposes. |
| 16:26:13 | disruptek | as an example... |
| 16:26:40 | FromDiscord | <Clyybber> maybe its illegal sym sharing |
| 16:26:46 | FromDiscord | <Clyybber> or its your fault and its illegal name sharing |
| 16:26:54 | FromDiscord | <Clyybber> sharing is ~~caring~~ illegal |
| 16:27:02 | disruptek | the spec is as simple as, "know the rules of mangling. mangle symbol and types names." |
| 16:27:49 | FromDiscord | <Clyybber> no, what the spec is for the frontend to adhere to |
| 16:28:06 | * | Onionhammer quit (Quit: The Lounge - https://thelounge.chat) |
| 16:28:15 | disruptek | whatever the c compiler needs as far as types, symbols, names. |
| 16:28:30 | disruptek | i just don't know if the old mangler allowed us to exploit it somehow. |
| 16:29:06 | disruptek | ie. i get two types with the same signature and name, but different identities. should they be equal? identical? or distinct? |
| 16:30:02 | FromDiscord | <Clyybber> identical I would say |
| 16:30:36 | disruptek | what if they have the same name but different signatures? |
| 16:30:43 | FromDiscord | <Clyybber> not identical |
| 16:31:12 | disruptek | so if we give type B the name Jeff, then when type A comes along, we have to name it Jeff_1. |
| 16:31:25 | FromDiscord | <Clyybber> yes |
| 16:32:01 | FromDiscord | <Clyybber> module A could have a different jeff type then module B no? |
| 16:32:06 | disruptek | and now type A appears in a new module. and we want to call it Jeff. and by all rights we should, but we can't, because Jeff is used by type B and we need the type names to match across modules. |
| 16:32:23 | disruptek | it's this kind of bullshit. |
| 16:32:28 | FromDiscord | <Clyybber> why do we need the names to match if they aren't the same type |
| 16:32:35 | FromDiscord | <Clyybber> only happen to share their name? |
| 16:32:58 | * | Onionhammer joined #nim |
| 16:33:05 | disruptek | if the types have the same signature, they can share the same name. |
| 16:33:20 | disruptek | otherwise i'd be giving types with the same signature lots of new names. |
| 16:33:33 | FromDiscord | <Clyybber> ok |
| 16:34:23 | FromDiscord | <Clyybber> but you were talking about the case where they don't have the same signature |
| 16:34:51 | disruptek | if they don't have the same signature, then type A should be called Jeff by any naive measure. |
| 16:35:00 | disruptek | but Jeff is already used elsewhere. |
| 16:35:20 | FromDiscord | <Clyybber> why should it be called Jeff? |
| 16:35:36 | disruptek | because that's its s.name.s |
| 16:35:38 | FromDiscord | <Clyybber> If there are two jeffs and they are not equal, obviosly one needs to be renamed |
| 16:35:47 | shinzo | Does nim does efficient copying (like structural sharing or something) when creating a new copy of an object? or is just a new object created from zero? |
| 16:35:49 | disruptek | well, i said "naive" |
| 16:36:02 | disruptek | shinzo: from zero. use a ref for reference semantics. |
| 16:36:32 | disruptek | shinzo: unless you are using arc and move semantics. |
| 16:37:22 | shinzo | disruptek: Ok, want to keep the objects immutable when pasing them through functions |
| 16:37:57 | disruptek | shinzo: they will be immutable if they are value types and defined without `var` prefix in the proc signature. |
| 16:38:10 | FromDiscord | <Clyybber> disruptek: naively and correct would be to append the signature to the name |
| 16:38:17 | FromDiscord | <Clyybber> this is what current mangling does right? |
| 16:38:22 | disruptek | yes. |
| 16:39:04 | stefantalpalaru | Clyybber, this is what I vae to do to avoid a compiler error: https://gist.github.com/stefantalpalaru/3daccc359668c45267d091dd96667490 |
| 16:39:46 | shinzo | yeah, by copying them, was just curious if there was any special efficient copying being done, not a problem for me really, it's very nice that nim makes this ergonomic |
| 16:40:05 | stefantalpalaru | It looks like the variable tracking is done before template expansion, so it doesn't see that a dangling value inside the template ends up being assigned outside the template. |
| 16:40:18 | disruptek | clyybber, araq: basically, the conceipt of our new mangling design is that we could use identities. iiuc, the new identity code makes this worse. |
| 16:40:25 | FromDiscord | <Clyybber> stefantalpalaru: I have a different suspicion, could you try with https://github.com/nim-lang/Nim/commit/3f00a738dbc8319b4dd2b86bf5529c096f2dd243 reverted? |
| 16:40:31 | disruptek | shinzo: what lang are you coming from? |
| 16:41:34 | FromDiscord | <Clyybber> disruptek: Aren't signatures identities? |
| 16:41:37 | disruptek | shinzo: no copy occurs when calling a proc on an immutable object in the event the object consumes more than sizeof(pointer)*3 bytes in memory. |
| 16:41:50 | disruptek | clyybber: identities are ptype.uniqueId or psym.id |
| 16:41:56 | leorize[m] | sizeof(float) * 3 actually |
| 16:42:20 | FromDiscord | <Clyybber> disruptek: Ah, hmm. And why is that not working? |
| 16:42:21 | disruptek | that's the way i remember it but i'm not sure it's as correct. |
| 16:42:45 | disruptek | clyybber: because of our conceipt that identities are as correct as signatures. |
| 16:42:53 | disruptek | conceit, too. |
| 16:43:08 | FromDiscord | <Clyybber> ok, so identities are just a different signature impl |
| 16:43:19 | disruptek | leorize[m]: by which i mean, is it correct for the same reason, or not? |
| 16:43:20 | FromDiscord | <Clyybber> concept too |
| 16:43:37 | disruptek | yes and yes, they are different altogether. |
| 16:43:58 | FromDiscord | <Clyybber> how? |
| 16:44:21 | disruptek | although while two objects with the same identity will always share the same signature, two objects with the same signature may have varied identities. |
| 16:44:35 | disruptek | you get that, right? |
| 16:44:40 | FromDiscord | <Clyybber> yeah |
| 16:44:42 | disruptek | okay. |
| 16:44:48 | shinzo | disruptek: if no copy occurs in that case what happens then? |
| 16:45:00 | disruptek | shinzo: nothing bad. it's just an optimization. |
| 16:45:16 | FromDiscord | <Clyybber> correct me here: because signatures are based on the type itself, body etc. and identities are just handed out on each type creation? |
| 16:45:21 | disruptek | we won't permit you to mutate the object in any event. the compiler will issue an error. |
| 16:45:24 | disruptek | as it should. |
| 16:45:33 | disruptek | clyybber: right. |
| 16:45:44 | FromDiscord | <Clyybber> ok, seems simple enough |
| 16:45:44 | shinzo | disruptek: ok, good! |
| 16:45:52 | disruptek | clyybber: it is, but we got it wrong. |
| 16:45:57 | disruptek | shinzo: yeah, it's sweet. |
| 16:46:16 | FromDiscord | <Clyybber> disruptek: correct me here: did we get it wrong because aliases? |
| 16:46:22 | disruptek | no, because identities. |
| 16:46:42 | FromDiscord | <Clyybber> why is it wrong to use identites? |
| 16:47:18 | disruptek | because what the c compiler cares about is signature. that's the discriminating design property. |
| 16:47:35 | FromDiscord | <Clyybber> the c compiler cares about what we give him |
| 16:47:44 | FromDiscord | <Clyybber> if we put the signature in the name he cares |
| 16:47:47 | FromDiscord | <Clyybber> if we don't he doesn't |
| 16:48:05 | disruptek | we were trying to eliminate calculating signatures. that's how mangling was invented as a project. |
| 16:48:17 | shinzo | disruptek: weird I don't see this feature being talk about when seen discussions about nim, this "purity" part is really nice |
| 16:48:19 | disruptek | the idea was that maybe hashing all this stuff was expensive. |
| 16:48:24 | leorize[m] | fun CI stuff: https://github.com/nim-lang/Nim/pull/15610/files#diff-8d210fcad3e24ff1285a3aa6f757ef1222f3487d1867aa5b808c3623753f6c1aR620 |
| 16:48:24 | disbot | ➥ compiler: add annotations support for CI |
| 16:48:44 | FromDiscord | <Clyybber> right, so instead of using s.name.s & signature we now use s.name.s & s.id |
| 16:48:45 | disruptek | shinzo: i know. and check out the new strictFuncs stuff. |
| 16:48:50 | FromDiscord | <Clyybber> basically right? |
| 16:48:57 | disruptek | we use signatures, too. |
| 16:49:08 | disruptek | in my latest stuff, i mean. |
| 16:49:12 | FromDiscord | <Clyybber> why? |
| 16:49:24 | FromDiscord | <Clyybber> do identites not suffice? |
| 16:49:31 | disruptek | because at the entry points into mangling, we've already calculated the signature, so it's free. |
| 16:49:46 | disruptek | and we want two types with the same signature to have the same name. |
| 16:49:53 | disruptek | if they want it, i mean. |
| 16:49:54 | FromDiscord | <Clyybber> do we? |
| 16:49:58 | FromDiscord | <Clyybber> ok |
| 16:50:15 | FromDiscord | <Clyybber> do you have a snippet of nim code that demonstrates when we want them to have the same name? |
| 16:50:20 | disruptek | also you have things like pthread_mutex_t that you import from multiple places. |
| 16:50:31 | disruptek | ^ |
| 16:50:44 | FromDiscord | <Clyybber> ah, but thats importc anyways? |
| 16:50:50 | disruptek | yes. |
| 16:50:57 | disruptek | so the name is immutable. |
| 16:51:13 | FromDiscord | <Clyybber> yeah, those needn't be mangled, no? |
| 16:51:16 | disruptek | we can't go 'round with pthread_mutex_t_3 etc. |
| 16:51:20 | FromDiscord | <Clyybber> so just check for sfImportC |
| 16:51:28 | disruptek | we do. |
| 16:51:37 | disruptek | the point is, we have to record that the name is in use. |
| 16:51:50 | FromDiscord | <Clyybber> makes sense |
| 16:51:52 | disruptek | we cannot assume that the mangle is safe just because the frontend says it is. |
| 16:51:56 | FromDiscord | <Clyybber> but we don't need the signature for that |
| 16:52:11 | disruptek | true, we don't need the sig for that. |
| 16:52:36 | disruptek | how do you propose to disambiguate without the signature, though? |
| 16:52:48 | FromDiscord | <Clyybber> disambiguate what? |
| 16:53:10 | FromDiscord | <Clyybber> we don't need to disambiguate importC types |
| 16:53:17 | disruptek | how do we know if two pthread_mutex_t(s) are safe to both be importc and share the same name? |
| 16:53:30 | FromDiscord | <Clyybber> we just assume so |
| 16:53:36 | FromDiscord | <Clyybber> you are using importc after all |
| 16:53:38 | disruptek | lol |
| 16:53:48 | FromDiscord | <Clyybber> is that not how current mangling does it? |
| 16:53:49 | FromDiscord | <Clyybber> :D |
| 16:54:35 | disruptek | hmm. |
| 16:54:45 | FromDiscord | <Clyybber> regardless of wether you do TypeA {.importc: pthread_mutex.} or TypeB {....} its the same in the C code? |
| 16:55:03 | FromDiscord | <Clyybber> don't trust me on that one, best to check the code generated on current devel |
| 16:57:03 | FromDiscord | <Clyybber> ok, I checked, it doesn't mangle importc types |
| 16:57:25 | FromDiscord | <Clyybber> sent a long message, see http://ix.io/2B2q |
| 16:57:49 | FromDiscord | <Clyybber> sent a code paste, see https://play.nim-lang.org/#ix=2B2r |
| 16:58:04 | FromDiscord | <Clyybber> hmm, gotta fix the bridge |
| 16:58:36 | FromDiscord | <Clyybber> disruptek: You feel me? Both end up raw as "bruh" there is no trace of T1 or T2 in the generated code |
| 16:59:09 | disruptek | oh i was offline. |
| 16:59:27 | FromDiscord | <Clyybber> oh, should I resend? |
| 16:59:32 | disruptek | no, i got it. |
| 16:59:42 | disruptek | yes, the old code works. |
| 16:59:46 | disruptek | the new code works, too. |
| 16:59:54 | disruptek | as i said, this isn't the problem area. |
| 17:00:05 | FromDiscord | <Clyybber> ah, alright |
| 17:01:40 | FromDiscord | <Clyybber> stefantalpalaru: ping |
| 17:02:04 | disruptek | consider this, though: if i importc Jeff, then i need to record the fact that Jeff is in use and a later attempt to create a name, Jeff, should create instead Jeff_1. |
| 17:02:27 | FromDiscord | <Clyybber> yes |
| 17:02:33 | FromDiscord | <Clyybber> but not a later attempt that is also importc |
| 17:02:38 | disruptek | right. |
| 17:02:55 | FromDiscord | <Clyybber> still no need for signature here |
| 17:03:13 | disruptek | right. |
| 17:03:58 | disruptek | but i think caching whether the "owning" type is immutable or not might be worthwhile for error messages at least. |
| 17:04:19 | disruptek | i think it's a good addition, thanks. |
| 17:04:23 | FromDiscord | <Clyybber> owning as in "i came first" ? |
| 17:04:27 | disruptek | yeah. |
| 17:04:50 | FromDiscord | <Clyybber> hmm, maybe, but what kind of code would it error out for? |
| 17:04:51 | disruptek | we don't have the technology to rename yet. honestly, it's probably worth implementing. |
| 17:05:36 | disruptek | something where we attempting to importc the name after exporting it. |
| 17:05:57 | FromDiscord | <Clyybber> heh, better not error out for that one |
| 17:06:05 | FromDiscord | <Clyybber> otherwise you end up with a timothissue |
| 17:06:10 | disruptek | if i had to do this again, i would have just written a new backend. seriously. |
| 17:06:33 | disruptek | i mean, how hard could it be? |
| 17:06:52 | FromDiscord | <Clyybber> did we solve something just now? |
| 17:07:16 | disruptek | nah, but it could be an optimization. |
| 17:07:23 | FromDiscord | <Clyybber> what exactly |
| 17:07:43 | disruptek | a slightly different code path for immutable names. |
| 17:08:00 | FromDiscord | <Clyybber> an immutable name being importc or exportc? |
| 17:08:19 | disruptek | or a compiler proc, yes. |
| 17:08:31 | FromDiscord | <Clyybber> whats the optimization? |
| 17:08:50 | disruptek | we can ignore any sig-based checking or calcs or whatever. |
| 17:09:10 | FromDiscord | <Clyybber> oh, yeah. What did it do before? |
| 17:09:54 | disruptek | before? probably nothing. current code? it merely changes how the name is mangled, but all the same flow occurs otherwise. |
| 17:10:02 | disruptek | the same checks, etc. |
| 17:10:14 | FromDiscord | <Clyybber> ah |
| 17:10:36 | FromDiscord | <Clyybber> ok, I would refrain from handling errors there for now |
| 17:11:20 | disruptek | the main thing is that we need the side-effects; incrementing counters, etc. |
| 17:11:30 | disruptek | this is key to making ic work. |
| 17:11:37 | FromDiscord | <Clyybber> yeah, increment the counter for the name |
| 17:11:43 | disruptek | right. |
| 17:12:01 | FromDiscord | <Clyybber> why do we ever need the signature? |
| 17:12:12 | FromDiscord | <Clyybber> if we have the identity |
| 17:12:20 | disruptek | because let's say that we importc as our first step. |
| 17:12:24 | disruptek | so we import Jeff. |
| 17:12:46 | disruptek | that increments the Jeff counter. also, we stash id###->Jeff. |
| 17:12:47 | FromDiscord | <Clyybber> type Jeff {.importc: "Jeff".} |
| 17:12:51 | disruptek | right. |
| 17:13:03 | FromDiscord | <Clyybber> whats id###? |
| 17:13:10 | FromDiscord | <Clyybber> the identity of Jeff? |
| 17:13:13 | disruptek | yes. |
| 17:13:21 | FromDiscord | <Clyybber> where do we store that? |
| 17:13:31 | disruptek | in the same disambiguation table. string->counter |
| 17:13:37 | FromDiscord | <Clyybber> ah ok |
| 17:13:44 | FromDiscord | <Clyybber> shouldn't it be |
| 17:13:50 | FromDiscord | <Clyybber> name->counter |
| 17:13:56 | FromDiscord | <Clyybber> not identity->counter |
| 17:14:05 | disruptek | honestly? it should be two tables. |
| 17:14:20 | disruptek | one id->counter, one name->counter. |
| 17:14:28 | disruptek | but whatever. it is what it is, for now. |
| 17:14:40 | FromDiscord | <Clyybber> Ok, so right now it is id->counter? |
| 17:15:08 | disruptek | name->counter is next-available-counter |
| 17:15:08 | disruptek | id->counter is counter-we-assigned-to-that-id |
| 17:15:15 | disruptek | right now it is string->counter and we $id or $name. |
| 17:15:49 | FromDiscord | <Clyybber> ah, ok |
| 17:16:25 | disruptek | anyway, we need this side-effect because we need to know what to do when we are presented with Jeff again. |
| 17:16:34 | FromDiscord | <Clyybber> yeah |
| 17:16:36 | disruptek | like, is it the same signature? same key? |
| 17:16:43 | FromDiscord | <Clyybber> it reall should be two tables though |
| 17:16:48 | disruptek | of course. |
| 17:16:50 | FromDiscord | <Clyybber> seems dangerous to conflate the two |
| 17:17:11 | FromDiscord | <Clyybber> especially if you encounter type `124789159801` = int :p |
| 17:17:15 | disruptek | it's not dangerous, because names never start with digits and identities never start with characters. |
| 17:17:16 | leorize[m] | @euantor if you're around can you look into Nim's freebsd ci? |
| 17:17:45 | FromDiscord | <Clyybber> disruptek: yeah |
| 17:17:47 | disruptek | it's just lazy and inefficient. |
| 17:18:04 | FromDiscord | <Clyybber> ok, so if we encounter |
| 17:18:07 | euantorano | leorize[m]: sure, will do so after eating dinner |
| 17:18:08 | FromDiscord | <Clyybber> type Jeff = int |
| 17:18:19 | FromDiscord | <Clyybber> then, we check name->counter |
| 17:18:25 | disruptek | if i were to implement this again, i would use a query pattern where i could cache all the results and return complex responses. |
| 17:18:27 | FromDiscord | <Clyybber> increment it |
| 17:18:33 | FromDiscord | <Clyybber> and set id->counter |
| 17:18:52 | disruptek | first we check id->counter. |
| 17:19:03 | disruptek | second we check name->counter. |
| 17:19:15 | disruptek | third, increment it, set id->counter. |
| 17:19:15 | FromDiscord | <Clyybber> we check for the existance of id->counter right? |
| 17:19:34 | disruptek | right, we need to read it so we can combine it with the name. |
| 17:19:41 | FromDiscord | <Clyybber> so |
| 17:20:19 | FromDiscord | <Clyybber> if id->counter: #already generated, combine with name↵else:↵ inc name->counter↵ id->counter = name->counter |
| 17:20:36 | FromDiscord | <Clyybber> let me split that up |
| 17:20:40 | FromDiscord | <Clyybber> if id->counter: #already generated, combine with name |
| 17:20:44 | FromDiscord | <Clyybber> else: |
| 17:20:47 | FromDiscord | <Clyybber> inc name->counter |
| 17:20:58 | FromDiscord | <Clyybber> id->counter = name->counter |
| 17:21:08 | FromDiscord | <Clyybber> sorry for the indentation, shitcord cuts off leading spaces |
| 17:21:31 | euantorano | leorize[m]: reporting to #sr.ht - seems to be an image issue |
| 17:21:34 | FromDiscord | <Clyybber> imagine the part after the else being indented |
| 17:21:34 | disruptek | well, we inc last. name->counter holds the next-available. |
| 17:21:50 | FromDiscord | <Clyybber> ah ok |
| 17:21:56 | disruptek | same same but different. |
| 17:22:05 | FromDiscord | <Clyybber> makes sense, doesn't matter |
| 17:22:14 | leorize[m] | euantorano: sr.ht seems to break a lot :/ |
| 17:22:57 | FromDiscord | <Clyybber> disruptek: That doesn't seem to complex, when does it break? |
| 17:22:59 | disruptek | ideally, we ask any question we want, it gets turned into a query object, that object is hashed as a key to a table that yields the complex response. |
| 17:23:12 | FromDiscord | <Clyybber> too complex |
| 17:23:13 | disruptek | if no response is cached, we execute the query and cache it. |
| 17:23:19 | euantorano | leorize[m]: mostly seems to be the FreeBSD image that keeps breaking, the OpenBSD one seems more reliable. They are still in Alpha I guess 🤷♂️ |
| 17:23:42 | FromDiscord | <Clyybber> disruptek: I guess it could be done, but all the queries are the same no? "giveMeAName" |
| 17:25:03 | stefantalpalaru | Clyybber: reverting that commit got rid of the problem. |
| 17:25:36 | FromDiscord | <Clyybber> stefantalpalaru: Nice, finally a good reason to revert it |
| 17:26:20 | FromDiscord | <Clyybber> I will create a PR |
| 17:26:54 | disruptek | to me, normalizing the input and output is the complex part. having these proper objects organizes the complexity better. |
| 17:27:24 | FromDiscord | <Clyybber> stefantalpalaru: Can you leave a comment here https://github.com/nim-lang/RFCs/issues/251 ? |
| 17:27:26 | disbot | ➥ Allow return in expressions again ; snippet at 12https://play.nim-lang.org/#ix=2B2K |
| 17:29:59 | stefantalpalaru | Sure. |
| 17:30:31 | disruptek | make sure you mention me. |
| 17:31:05 | FromDiscord | <Clyybber> disruptek: So where do we fail? |
| 17:31:17 | FromDiscord | <Clyybber> And how is that logic 1300 lines? |
| 17:31:25 | FromDiscord | <Clyybber> Its mostly debug those 1300 lines right? |
| 17:31:28 | disruptek | you know me. |
| 17:31:39 | * | gmaggior joined #nim |
| 17:32:25 | FromDiscord | <Clyybber> this logic you described seems simple and sound |
| 17:32:34 | disruptek | weird, right? |
| 17:34:08 | FromDiscord | <Clyybber> solving it will require understanding it, nobody truly understands more than 100 lines of code at once |
| 17:34:16 | FromDiscord | <Recruit_main707> Araq: I did some benchmarks comparing arc vs regions, i posted everything on the forum thread |
| 17:34:34 | FromDiscord | <Clyybber> maybe its even a needle in your debugging stack thats doing somethign sneaky |
| 17:34:39 | FromDiscord | <Clyybber> like decreasing your counters |
| 17:35:01 | disruptek | recruit: please link the thread. |
| 17:35:12 | FromDiscord | <Recruit_main707> https://forum.nim-lang.org/t/6930 |
| 17:35:38 | disruptek | clyybber: well, i just pushed some progress yesterday. today i need to debug some packages, but i already know i can reproduce some non-release traps in our test suite. |
| 17:35:56 | disruptek | recruit: danke. |
| 17:37:05 | FromDiscord | <Clyybber> disruptek: Yeah, but I mean, at some point the debug code becomes a distraction not a help |
| 17:37:07 | disruptek | i will argue in favor of none and regions. |
| 17:37:19 | FromDiscord | <Clyybber> maybe its worth it to remove all of it and reduce it to a minimum working thing |
| 17:37:26 | FromDiscord | <Clyybber> and start debugging again from tehre |
| 17:37:37 | FromDiscord | <Recruit_main707> cool |
| 17:37:54 | disruptek | clyybber: this is not that time. |
| 17:40:57 | disruptek | recruit: if arc beat none then you're probably doing extra allocs that are not necessary in your handwritten code. or, nim is. |
| 17:42:10 | disruptek | it's not really fair to compare arc to regions without handling dealloc similarly; ie. not at close of scope but at close of "region". does that make sense? |
| 17:42:50 | federico3 | the formatting of https://nim-lang.org/docs/times.html is broken |
| 17:42:52 | FromDiscord | <Clyybber> yep |
| 17:43:26 | FromDiscord | <Clyybber> federico3: Its reported already AFAIK |
| 17:43:47 | FromDiscord | <Recruit_main707> disruptek, that code specifically is not written by me, its in the tests folder of nim |
| 17:43:59 | disruptek | i'm just saying. |
| 17:44:06 | FromDiscord | <Clyybber> is it written for regions? |
| 17:44:32 | FromDiscord | <Recruit_main707> nope, i adapted it, keeping everything as close as i could |
| 17:44:38 | FromDiscord | <Clyybber> I see |
| 17:45:17 | FromDiscord | <Recruit_main707> i do dealloc everything at the end as disruptek said instead of whenever it goes out of scope, |
| 17:45:39 | FromDiscord | <Clyybber> you can do the same thing for arc |
| 17:45:46 | disruptek | well, the questions are, "which can be made fastest?", "which is fastest for idiomatic nim?", i guess. |
| 17:46:14 | disruptek | i'm not sure it makes sense to compare two equal impls that aren't either optimized or idiomatic. |
| 17:46:47 | FromDiscord | <Clyybber> disruptek: But theres so many debug stuff, surely some of that is not relevant for the current problem anymore? |
| 17:50:27 | disruptek | are you asking which debug stuff is relevant? |
| 17:50:58 | FromDiscord | <Clyybber> yeah |
| 17:51:02 | disruptek | bbiab |
| 17:51:27 | FromDiscord | <Clyybber> lol |
| 18:00:20 | * | scott_tams joined #nim |
| 18:04:38 | scott_tams | I don't seem to be able to install https://github.com/pragmagic/vscode-nim |
| 18:05:12 | scott_tams | does it require the non-open-source version of VS Code? I have version 1.49.1-1 (OSS build) from the Manjaro repos |
| 18:05:47 | FromDiscord | <Clyybber> pretty sure it should work on the oss version too |
| 18:07:30 | scott_tams | code --install-extension kosz78.nim |
| 18:07:30 | scott_tams | Installing extensions... |
| 18:07:30 | scott_tams | Extension 'kosz78.nim' not found. |
| 18:07:30 | scott_tams | Make sure you use the full extension ID, including the publisher, e.g.: ms-dotnettools.csharp |
| 18:07:30 | scott_tams | Failed Installing Extensions: kosz78.nim |
| 18:07:44 | * | lritter joined #nim |
| 18:08:35 | FromDiscord | <Clyybber> hmm, mabye try nim-alt |
| 18:09:32 | scott_tams | Hmm... https://github.com/pragmagic/vscode-nim/blob/0272a0544ddf147fde98f8a8f2b624b7dcb19eb3/package.json#L44-L46 |
| 18:10:07 | scott_tams | Clyybber, do you mean `kosz78.nim-alt`? |
| 18:11:19 | scott_tams | yeah, I can't install ms-vscode.cpptools either :( |
| 18:12:00 | FromDiscord | <Clyybber> maybe try https://marketplace.visualstudio.com/items?itemName=nimsaem.nimvscode |
| 18:12:17 | FromDiscord | <Clyybber> I don't use vscode myself so this is guesswork, but this one is the most updated I think |
| 18:12:28 | FromDiscord | <Clyybber> and its written in Nim itself which is pretty neat :D |
| 18:12:40 | scott_tams | nifty |
| 18:12:47 | scott_tams | what do you use? |
| 18:14:30 | scott_tams | no, that one also depends on ms-vscode.cpptools |
| 18:15:47 | FromDiscord | <Clyybber> hmm, damn. I use kakoune |
| 18:16:16 | FromDiscord | <Clyybber> I'm pretty sure @Yardanico is using the oss version and the plugin just fine, maybe he can help you |
| 18:16:46 | FromDiscord | <Yardanico> @scott_tams I know the exact reason why you can't install it |
| 18:17:05 | FromDiscord | <Yardanico> VSCodium doesn't use the official VSCode marketplace anymore |
| 18:17:09 | Prestige | @Clyy did you move from vim to kakoune? Curious how the transition is |
| 18:17:39 | FromDiscord | <Clyybber> I started using both, but found kakoune to make more sense |
| 18:17:42 | FromDiscord | <Yardanico> But I used VSCode-oss from arch repos "code", it still uses the official marketplace |
| 18:18:01 | * | kenran joined #nim |
| 18:18:24 | scott_tams | that's very weird. I'm using the same thing, but Nim and ms-vscode.cpptools don't show up |
| 18:18:29 | FromDiscord | <Clyybber> Prestige: I think I only used vim for about a month or so before switching to kakoune |
| 18:18:31 | scott_tams | I'm trying the official binary from the AUR |
| 18:18:35 | FromDiscord | <Yardanico> are you sure that it's the same thing? |
| 18:18:52 | Prestige | Hmm okay, I might give kak a shot for a bit |
| 18:19:09 | FromDiscord | <Yardanico> Oh shoot |
| 18:19:14 | scott_tams | @Yardanico what does `code --version` give you? |
| 18:19:23 | FromDiscord | <Yardanico> They seem to have switched to OpenVSX as well @scott_tams |
| 18:19:29 | FromDiscord | <Yardanico> I mean code package in the arch repo |
| 18:19:32 | scott_tams | ah |
| 18:19:48 | FromDiscord | <Yardanico> https://github.com/archlinux/svntogit-community/blob/packages/code/trunk/product_json.diff |
| 18:21:42 | FromDiscord | <Yardanico> You can ask Nim's plugin maintainer to upload it to OpenVSX |
| 18:21:45 | FromDiscord | <Yardanico> or do that yourself :P |
| 18:22:24 | FromDiscord | <Clyybber> can't you install from folder or something like that? |
| 18:22:25 | scott_tams | it won't work, it depends on ms-vscode.cpptools which they won't take in OpenVSX because it has proprietary blobs |
| 18:22:36 | Yardanico | well I'm not sure why it depends on that |
| 18:22:44 | Yardanico | It really doesn't use any functionality from ms-vscode.cpptools |
| 18:22:51 | Yardanico | you can try to just remove that dependencyt? |
| 18:22:55 | scott_tams | maybe |
| 18:23:00 | Yardanico | and of course there are alternatives, like vscode-nim-lsp which will use nimlsp |
| 18:23:13 | Yardanico | leorize[m]: https://github.com/nim-lang/Nim/pull/15610/files is very cool! |
| 18:23:13 | disbot | ➥ compiler: add annotations support for CI |
| 18:24:32 | * | narimiran joined #nim |
| 18:37:22 | * | lbart quit (Ping timeout: 265 seconds) |
| 18:37:52 | * | Onionhammer quit (Quit: The Lounge - https://thelounge.chat) |
| 18:38:44 | * | lbart joined #nim |
| 18:42:26 | * | Onionhammer joined #nim |
| 18:43:04 | * | leorize quit (Quit: WeeChat 2.9) |
| 18:43:43 | scott_tams | When trying to build nimsaem.nim I encountered this error: Error: cannot open file: nimsuggest/sexp |
| 18:43:53 | scott_tams | I'm assuming it's because I don't know how to use nimble? |
| 18:43:55 | * | bung quit (Quit: Lost terminal) |
| 18:44:15 | * | Jesin quit (Quit: Leaving) |
| 18:45:06 | * | lbart quit (Ping timeout: 265 seconds) |
| 18:45:12 | * | kenran quit (Ping timeout: 272 seconds) |
| 18:46:12 | FromDiscord | <Yardanico> how did you install nim? |
| 18:47:38 | scott_tams | using choosenim |
| 18:47:40 | * | aenesidemus quit (Read error: Connection reset by peer) |
| 18:47:51 | * | Jesin joined #nim |
| 18:47:57 | scott_tams | (which I installed from AUR) |
| 18:49:40 | * | lbart joined #nim |
| 18:49:40 | * | lbart quit (Changing host) |
| 18:49:40 | * | lbart joined #nim |
| 18:50:53 | FromDiscord | <Yardanico> weird |
| 18:50:58 | FromDiscord | <Yardanico> try running nimble install nimsuggest |
| 18:51:15 | FromDiscord | <Yardanico> oh wait no |
| 18:52:34 | FromDiscord | <dom96> choosenim is in aur? 😮 |
| 18:55:35 | * | NimBot joined #nim |
| 18:55:44 | Yardanico | try nimble install compiler |
| 18:55:48 | Yardanico | but it's really weird |
| 18:57:08 | FromDiscord | <dom96> what is nimsaem? |
| 18:58:07 | FromDiscord | <Clyybber> @dom96 its the name the author choose to release https://github.com/saem/vscode-nim on vscode repos |
| 18:58:28 | FromDiscord | <dom96> hmmm, why does it need to be built then? |
| 18:58:56 | scott_tams | dom96 it's no longer available in my version of VSCode, I'm trying to sideload it |
| 18:59:03 | scott_tams | until it can be published to OpenVSX |
| 18:59:10 | scott_tams | See https://github.com/saem/vscode-nim/issues/8 |
| 18:59:11 | disbot | ➥ Publish to OpenVSX |
| 18:59:34 | FromDiscord | <dom96> I see, it's actually written in Nim |
| 18:59:38 | scott_tams | Yardanico nimble install compiler did the trick |
| 18:59:41 | scott_tams | yup |
| 18:59:55 | FromDiscord | <dom96> You should PR it so that it includes `compiler` as a dep in its nimble file |
| 19:00:14 | scott_tams | good idea |
| 19:01:49 | scott_tams | I'm checking out Nim after using Crystal for a couple years, very used to this kinda stuff ;) |
| 19:05:25 | FromDiscord | <dom96> cool |
| 19:16:35 | * | Mat5 joined #nim |
| 19:19:39 | Mat5 | Hello |
| 19:20:13 | scott_tams | o/ |
| 19:24:38 | Mat5 | I'm not familiar with the actual development, does there exist a decent SDL2 wrapper? |
| 19:26:24 | scott_tams | I wouldn't know, have you checked nimble.directory ? |
| 19:26:31 | disruptek | please don't add `compiler` to requirements. |
| 19:26:40 | disruptek | it's nonsensical. just add a $nim to the path. |
| 19:26:45 | disruptek | in project.nim.cfg, ideally. |
| 19:27:08 | scott_tams | Hm? Sorry, I'm new to nim, what do you mean? |
| 19:27:34 | scott_tams | `nimble install compiler` did seem to install the compiler |
| 19:27:41 | disruptek | compiler should not be installed; as a package, it's just a nonsense idea. |
| 19:28:52 | scott_tams | what do you mean? Can code not import portions of the compiler and use them as modules? |
| 19:28:56 | Yardanico | it can |
| 19:29:05 | Yardanico | disruptek: some distributions don't include nim source code in nim packages |
| 19:29:09 | Yardanico | so it needs to be in nimble reqs |
| 19:29:35 | scott_tams | well, specifically, choosenim doesn't, and that's what the web site says is the recommended way to install |
| 19:29:40 | disruptek | well, then nimble should treat it specially. if the user includes $nim and you don't have it, you'll have to install the compiler. |
| 19:30:22 | Yardanico | scott_tams: it's totally okay to put compiler in requirements |
| 19:30:23 | Yardanico | don't worry |
| 19:30:28 | Mat5 | scott_tams, no, but found it. Thanks for the link |
| 19:30:32 | disruptek | otherwise we have the situation that i need to write compiler code that can be compiled by any version of a nim compiler, but that code is applicable to any version of the compiler. in my user code, how do i know which version of the compiler code is running? |
| 19:30:37 | scott_tams | yeah, I disagree disruptek |
| 19:30:55 | disruptek | you don't have to agree, but you have to understand the problem. |
| 19:32:52 | * | Mat5 quit (Quit: Leaving) |
| 19:33:05 | scott_tams | I don't, though. The compiler executable and the modules/source code which make up the compiler are two different things |
| 19:33:24 | disruptek | they are. but the constants used to compile the code vary between versions. |
| 19:34:15 | FromDiscord | <Clyybber> disruptek: It doesn't matter normally, and it definitely doesn't if the source is newer than the compiler |
| 19:34:27 | FromDiscord | <Clyybber> *newer or just as new |
| 19:35:01 | FromDiscord | <Elegant Beef> Currently scott i'm using the nim compiler to be able to use nimscript to control applications |
| 19:35:20 | FromDiscord | <Elegant Beef> To answer your question "what do you mean? Can code not import portions of the compiler and use them as modules?" |
| 19:35:29 | disruptek | do what you want. i really don't feel like arguing this. make an rfc please. |
| 19:35:49 | FromDiscord | <Clyybber> disruptek: rfc for what? |
| 19:36:16 | FromDiscord | <dom96> having a special dependency that works magically is nonsensical |
| 19:36:21 | disruptek | for whether including the compiler is wise or preferable to $nim, and whether it should be deprecated. |
| 19:36:40 | disruptek | nim is one such dependency. also, nimph doesn't support it, because it's magical. |
| 19:36:42 | FromDiscord | <dom96> nothing wrong with adding `compiler` to the list of requirements, it allows you to lock onto a specific commit/version |
| 19:36:44 | disruptek | yet nimble does. |
| 19:37:06 | disruptek | although, nimble only supports it poorly. witness 1.0.10 versus "1.0.10" and now "1.4.0". |
| 19:38:13 | disruptek | so you're compiling early compiler code with a later version of the compiler. |
| 19:38:27 | disruptek | and i'm a library author. how am i supposed to know which version of the code i have? |
| 19:38:42 | FromDiscord | <shashlick> Compiler package can be out of sync with the nim version being used |
| 19:38:49 | disruptek | exactly. |
| 19:38:50 | FromDiscord | <shashlick> I prefer $nim |
| 19:39:01 | Yardanico | disruptek: nimble already fixed that bug |
| 19:39:13 | disruptek | Yardanico: well, Prologue is failing now. |
| 19:39:29 | Yardanico | disruptek: it's not? |
| 19:39:34 | disruptek | it only took nimskull 9 years to learn how to parse version strings. |
| 19:39:38 | Yardanico | ok ok whatever |
| 19:39:45 | Yardanico | bugs can be everywhere |
| 19:39:51 | Yardanico | even in *stable* software with version >1.0 |
| 19:39:51 | disruptek | i keep hearing this... |
| 19:39:55 | Yardanico | yes, but it's true |
| 19:40:07 | disruptek | so why do you doubt me? |
| 19:40:41 | FromDiscord | <shashlick> Stay on topic - $nim is what I use in nimterop and it works fine across multiple versions of Nim |
| 19:40:49 | disruptek | of course. |
| 19:40:56 | scott_tams | what is $nim and nimterop |
| 19:41:05 | disruptek | you and i came to the same conclusion last year, iirc. |
| 19:41:10 | disruptek | there's no other sane way to do it. |
| 19:41:17 | disruptek | $repo nimterop |
| 19:41:21 | disruptek | !repo nimterop |
| 19:41:23 | disbot | https://github.com/nimterop/nimterop -- 9nimterop: 11Nimterop is a Nim package that aims to make C/C++ interop seamless 15 218⭐ 20🍴 7& 11 more... |
| 19:41:34 | Yardanico | @shashlick the problem is that there's no guarantee that nim sources will be available |
| 19:41:34 | disruptek | uh, $nim is a path substitution you can use in paths to refer to the stdlib. |
| 19:41:51 | disruptek | Yardanico: exactly. this is the problem to solve. no other. |
| 19:41:54 | scott_tams | so like `import $nim/somepackage`? |
| 19:42:15 | disruptek | no, like --path:"$nim" |
| 19:42:23 | disruptek | not stdlib, root nim install directory. |
| 19:42:47 | disruptek | it's mostly used to allow user code to import the compiler, which is adjacent to stdlib "/lib/" |
| 19:43:42 | disruptek | but apparently absent in some installations. so instead of making packagers solve the problem that they supplied, uh, we want to muddy the waters, breaking software. |
| 19:43:43 | scott_tams | is this something the package sets up in your shell or something special to nim command line tools or...? I'm so confused |
| 19:44:10 | disruptek | --path:"$nim" is a command-line parameter. |
| 19:44:37 | disruptek | the $nim is verbatim. then the compiler parses paths and expands $variable to the contents of the variable. |
| 19:45:01 | disruptek | ...for a limited number of expansions such as $lib, $nim, $home, $project, $nimbleDir, and so on. |
| 19:45:09 | disruptek | i mostly just use $config. |
| 19:45:50 | disruptek | $nim refers to (which nim)/.., basically. |
| 19:45:52 | FromDiscord | <shashlick> @Yardanico there's no reason to act like the compiler is not part of the stdlib |
| 19:46:17 | Yardanico | @shashlick well, but I'm talking about current behaviour |
| 19:46:22 | Yardanico | it needs to be changed then |
| 19:46:32 | FromDiscord | <shashlick> Agreed |
| 19:46:34 | Yardanico | so nim *explicitly* bundles compiler src with the distribution |
| 19:46:37 | Yardanico | right now it doesn't |
| 19:46:38 | scott_tams | if I do `nim somecommand --path="$nim"` at my terminal, the dollar-sign will be picked up by my shell and reinterpreted as the value of `$nim`, which, unless my package maintainer added `$nim` as an environment variable to some configuration file (they didn't) it will be null and the output will be `nim somecommand --path=` |
| 19:46:40 | disruptek | yes, the behavior needs to be changed. |
| 19:46:45 | Yardanico | even nim's own binary releases are _without_ compiler source |
| 19:46:46 | FromDiscord | <shashlick> And compiler package should be deprecated somehow |
| 19:46:53 | disruptek | Yardanico: that's just not true. |
| 19:47:11 | FromDiscord | <shashlick> It's only distro packages to my knowledge |
| 19:47:22 | Yardanico | yeah sorry it's there with nim releases |
| 19:47:24 | disruptek | ~gitnim |
| 19:47:25 | disbot | gitnim: 11https://gitnim.com/ -- choosenim for choosey nimions -- disruptek |
| 19:47:26 | scott_tams | `which nim` would evaluate to /usr/bin/nim, which is the location of the binary, not a directory. |
| 19:47:29 | disruptek | look at any release you want. |
| 19:47:36 | scott_tams | saying `which nim`/anything is nonsensical |
| 19:47:39 | leorize[m] | `$nim` is a PITA for packager |
| 19:47:52 | FromDiscord | <nikki> if i want to use a container implemented in C, that just has an interface of ptrs and sizes, and gives me a hook for element destruction, and i want to hold nim objects that can have nim-managed ref members, in the hook do i just need to call `=destroy` on the element? eg. https://play.nim-lang.org/#ix=2B3Q works |
| 19:47:56 | disruptek | scott_tams: `which nim`/.. |
| 19:47:57 | scott_tams | leorize[m], I can only imagine! |
| 19:48:06 | scott_tams | so `/usr/bin/`? |
| 19:48:18 | disruptek | look dude, i can only supply the answer so many times. |
| 19:48:25 | disruptek | at some point you're going to have to read what i write. |
| 19:48:28 | disruptek | it's only fair. |
| 19:48:31 | disruptek | meet me halfway. |
| 19:50:02 | scott_tams | echo $vim |
| 19:50:02 | scott_tams | sh-5.0$ |
| 19:50:05 | scott_tams | Hmm..... |
| 19:50:18 | disruptek | !code pathsub |
| 19:50:19 | disbot | no results 😢 |
| 19:50:35 | disruptek | hmm.... |
| 19:50:45 | disruptek | !code pathsubs |
| 19:50:45 | disbot | https://github.com/nim-lang/Nim/blob/13e659cfec83eb3c2c3c2bbbf10d01ba59bc0d5b/compiler/modulepaths.nim -- 11compiler/modulepaths.nim 7& 3 more... |
| 19:51:13 | scott_tams | so this applies in nim code or in shell commands? |
| 19:51:35 | disruptek | it applies to configuration strings for the compiler. |
| 19:51:52 | scott_tams | oh so like in config files, like the .nimble file? |
| 19:51:55 | disruptek | eg .cfg files, .nims switch()es, and cli arguments. |
| 19:52:15 | disruptek | yes, any nimscript that imports `--`() for example. |
| 19:52:23 | * | hyiltiz joined #nim |
| 19:52:23 | * | hyiltiz quit (Changing host) |
| 19:52:23 | * | hyiltiz joined #nim |
| 19:52:27 | scott_tams | I don't see the relevance of the github link |
| 19:52:40 | disruptek | it's just whatever disbot found. |
| 19:52:55 | disruptek | it's the top hit but doesn't include the definition |
| 19:52:59 | scott_tams | what is a nimscript (is it just nim source code?) and what do you mean by `imports --()`? |
| 19:53:24 | disruptek | nimscript is nim, but compile-time only subset. |
| 19:53:32 | scott_tams | ohh ok |
| 19:53:33 | disruptek | it's just run by the vm. |
| 19:53:36 | scott_tams | "macro-land" |
| 19:53:37 | * | hnOsmium0001 joined #nim |
| 19:54:25 | disruptek | well, not necessarily macros. they are but one part of the language supported there. `--`() is a proc that knows how to invoke cli-argument syntax at compiletime. |
| 19:55:33 | scott_tams | ok...so within "nimscript"s, you can write `somecommand --path=$config` and that will yield a configuration directory |
| 19:55:46 | scott_tams | where somecommand is some sort of special proc or macro? |
| 19:56:24 | disruptek | you can write `--path="$nim"` i think. or something damn near to it. |
| 19:56:48 | disruptek | i usually use switch("path", "$nim"), let's say. |
| 19:57:00 | disruptek | i just find it less surprising to read. |
| 19:57:21 | disruptek | but i don't favor putting any config in nimscript. |
| 19:57:46 | disruptek | it's too expensive for tooling to discover. |
| 19:57:50 | FromDiscord | <nikki> a 0-init of a seq is not safe to `.add` to yet right? |
| 19:57:52 | FromDiscord | <Clyybber> not really |
| 19:58:01 | FromDiscord | <Clyybber> @nikki hmm? |
| 19:58:04 | disruptek | a 0-init? |
| 19:58:10 | FromDiscord | <Clyybber> Oh, it is. seqs are empty by default |
| 19:58:14 | disruptek | all new seqs are zerod. |
| 19:58:19 | disruptek | all memory allocs, in fact. |
| 19:58:23 | FromDiscord | <Clyybber> That is there is no nil for seqs |
| 19:58:30 | FromDiscord | <nikki> if i `alloc0` some memory that is meant for a value object that contains a seq member |
| 19:58:35 | mipri | scott_tams: https://github.com/nim-lang/Nim/blob/devel/compiler/options.nim#L666 it's only called in a few places |
| 19:58:44 | FromDiscord | <nikki> (asking cuz it'll be 0-alloced in C-land actually) |
| 19:58:45 | Yardanico | 666 |
| 19:58:53 | disruptek | yes, it will be zero'd. |
| 19:58:54 | FromDiscord | <nikki> ah nice, the 0-init is safe to add to then |
| 19:58:54 | FromDiscord | <Clyybber> @nikki it should be fine I think |
| 19:58:55 | disruptek | alloc0'd. |
| 19:59:09 | FromDiscord | <nikki> right what i meant is, is 0 bytes a safe start state for a seq to add to |
| 19:59:14 | FromDiscord | <Clyybber> disruptek: No hes asking about having a seq and initializing it to nil manually |
| 20:00:02 | disruptek | oh lemme read this again, sorry. |
| 20:00:09 | FromDiscord | <nikki> oh i guess the member is actually a ref since seq is a ref type and so i'd have to actually set it to a `newSeq` result |
| 20:00:14 | scott_tams | why would all mallocs be zeroed? doesn't that incur a significant overhead? |
| 20:00:31 | FromDiscord | <nikki> malloc (a C term) doesn't zero |
| 20:00:39 | scott_tams | I meant the Nim equivalent |
| 20:00:40 | FromDiscord | <nikki> `alloc0` (nim) zeros, so does calloc (C) |
| 20:00:43 | disruptek | because values start at zero, so... |
| 20:00:48 | scott_tams | "all memory allocs" |
| 20:01:02 | FromDiscord | <Clyybber> nim has alloc and alloc0 |
| 20:01:16 | disruptek | and realloc and... |
| 20:01:35 | scott_tams | ok |
| 20:02:14 | scott_tams | so when a seq is created, is it initially a buffer of zeroes of some arbitrary size? |
| 20:02:39 | disruptek | afaik, yes. |
| 20:02:55 | disruptek | some of this changed in the last year, though. |
| 20:02:55 | scott_tams | :/ |
| 20:04:06 | scott_tams | ayyy I've got syntax highlighting in VSCode working finally :D |
| 20:04:07 | leorize[m] | scott_tams: allocs are zero-ed for safety |
| 20:04:08 | FromDiscord | <nikki> to clarify -- did you mean to refer to the buffer of elements that a seq refers to, or the buffer for the seq itself (which would be a pointer to the element buffer, plus a size, and maybe other stuff idk) |
| 20:04:12 | leorize[m] | and it's not slow |
| 20:04:35 | FromDiscord | <Clyybber> scott_tams: An empty seq of course won't be a buffer of zeros |
| 20:04:38 | scott_tams | leorize[m], 1 why is that safer? and 2 how does it not impact performance? |
| 20:04:44 | FromDiscord | <Clyybber> It will contain as many zeros as the capacity of that seq |
| 20:04:47 | leorize[m] | if that impacts you, a variable can always be tagged with `{.noInit.}` to disable that |
| 20:04:48 | Yardanico | scott_tams: 1) because otherwise you'll have garbage info |
| 20:04:54 | disruptek | that's what he meant, clyybber. |
| 20:05:07 | FromDiscord | <Clyybber> scott_tams: Othewise you could read uninitialized memory |
| 20:05:13 | leorize[m] | scott_tams: modern architectures allow for extremely quick `memset()` |
| 20:05:13 | disruptek | well, if the seq is empty it won't be garbage. |
| 20:05:22 | Yardanico | disruptek: because it's 0-alloced |
| 20:05:25 | scott_tams | not if bounds checking is enforced? |
| 20:05:32 | disruptek | right, but we would check you. |
| 20:05:35 | FromDiscord | <nikki> well 'contains' depends on whether you meant the seq value object itself which is a buffer ptr and a capacity and a len, or the buffer containing element data |
| 20:05:46 | disruptek | if no bounds check, yes, it will be zero everywhere. |
| 20:05:53 | scott_tams | for example, a seq may have a capacity of 16 but a size of 9 (9 elements with space for 16) |
| 20:05:54 | disruptek | because we alloc0 by default. |
| 20:06:14 | leorize[m] | I'm not even sure what is being talked about rn lol |
| 20:06:21 | scott_tams | hence if bounds checking were enforced, it wouldn't matter what junk is in the remaining 7 elements |
| 20:06:31 | disruptek | i think he's worried about the overhead of alloc0 still. |
| 20:06:39 | FromDiscord | <Clyybber> oh, you mean the space between length and capacity |
| 20:06:42 | FromDiscord | <Clyybber> disruptek: shush |
| 20:06:43 | disruptek | correct, scott_tams. |
| 20:06:46 | scott_tams | yes |
| 20:06:59 | disruptek | clyybber: you shush. |
| 20:07:03 | FromDiscord | <nikki> yeah it depends on how newseq acquires the mem for the element buffer |
| 20:07:04 | scott_tams | I suppose if the CPU is designed to do this quickly then it doesn't matter |
| 20:07:09 | FromDiscord | <Clyybber> disruptek: :P |
| 20:07:15 | disruptek | it's really not a big deal. |
| 20:07:19 | FromDiscord | <nikki> i would expect / hope that it leaves it uninitialized |
| 20:07:24 | disruptek | any performance-critical code can avert the zero'ing. |
| 20:07:39 | disruptek | but, y'know, this isn't all that common a problem with nim. |
| 20:07:42 | disruptek | performance, i mean. |
| 20:07:43 | FromDiscord | <Clyybber> disruptek: its not about zeroing the part between 0 and length |
| 20:07:50 | disruptek | i know. |
| 20:08:01 | FromDiscord | <Clyybber> let me check the implementation so we can answer this |
| 20:08:09 | scott_tams | haha, I recognize that these sorts of micro-optimizations aren't generally imporant, but I find them fun to think about |
| 20:08:12 | disruptek | a seq of cap 16 is an alloc of 16 or w/e, regardless of how much it holds. |
| 20:08:39 | leorize[m] | @mratsim can tell you exactly how to micro optimize the hell out of nim :P |
| 20:08:48 | mipri | you can read the seq stuff in lib/system/seqs_v2.nim. it's all relatively readable Nim. f.e. prepareSeqAdd clearly calls allocShared0 and reallocShared0, so yeah 'uninitialized' capacity outside of the len of the seq will be zeroed |
| 20:08:52 | scott_tams | :D |
| 20:08:56 | disruptek | i'm probably 98% sure we still alloc0 seqs under arc. |
| 20:08:56 | FromDiscord | <Clyybber> Hmm, yeah |
| 20:09:19 | FromDiscord | <nikki> alloc0 for the seq value object itself |
| 20:09:21 | FromDiscord | <nikki> but the q is about the element buffer |
| 20:09:29 | disruptek | everything. |
| 20:09:36 | disruptek | just assume everything is alloc0'd. |
| 20:10:08 | disruptek | the only time i'd be less sure is, eg. a realloc. |
| 20:10:27 | FromGitter | <oal> I'm trying out nim for the first time. Is there a way to watch source files and auto re-build and run on changes? Something like a "nimble watch"? |
| 20:10:33 | FromDiscord | <Clyybber> yeah, so far seqs don't even use realloc |
| 20:10:39 | FromDiscord | <Clyybber> still we are pretty fast :D |
| 20:10:44 | disruptek | no, but strings. |
| 20:10:59 | scott_tams | that could actually be pretty useful. If the CPU/arch manages to optimize memsets of 0, it could actually improve performance to do that over bounds checking for nonzero values (i.e. pointers) because you could just JNE instead of loading the size into a register then comparing and jumping on the result |
| 20:11:24 | disruptek | obviously, the more we can tell the os about what we want, the better. |
| 20:13:06 | * | olav_ joined #nim |
| 20:13:11 | FromDiscord | <Clyybber> I should be more specific, both realloc, but the default allocator doesn't really do anything smart in realloc |
| 20:13:22 | * | olav_ is now known as oal |
| 20:13:23 | FromDiscord | <nikki> https://media.discordapp.net/attachments/371759389889003532/767118074415284244/unknown.png |
| 20:13:36 | oal | I'm trying out nim for the first time. Is there a way to watch source files and auto re-build and run on changes? Something like a "nimble watch"? |
| 20:14:00 | Yardanico | oal: we saw your message from gitter :) |
| 20:14:09 | disruptek | i think there are a couple packages that do fs notification. |
| 20:14:17 | Yardanico | I think there was something like that but I don't recall the name |
| 20:14:18 | disruptek | ask disbot. |
| 20:14:23 | oal | ah, I didn't know if they were synced :) |
| 20:14:24 | Prestige | like hcr? |
| 20:14:31 | disruptek | do it privately, and disbot'll give you 30 results. |
| 20:14:38 | Yardanico | oal: nim gitter, discord, irc, matrix are all connected together |
| 20:14:44 | Yardanico | Prestige: nah |
| 20:14:48 | disruptek | but you can only talk to disbot privately from irc. |
| 20:14:54 | Yardanico | rebuilding and restarting |
| 20:14:57 | FromDiscord | <Clyybber> !package file watch |
| 20:14:57 | disbot | disruptek hung like rhinocerous🦏 |
| 20:15:00 | Yardanico | useful for e.g. web development |
| 20:15:00 | Prestige | oh ok |
| 20:15:04 | FromDiscord | <Clyybber> lol? |
| 20:15:05 | Yardanico | for backends |
| 20:15:13 | disruptek | disbot: shush. |
| 20:15:14 | disbot | on it. 👍 |
| 20:15:17 | Prestige | lmao |
| 20:15:18 | oal | Yardanico: Neat! |
| 20:15:36 | scott_tams | oooh, you guys have matrix too? nice |
| 20:15:37 | Yardanico | for example karax has a tool like that, but for the frontend part |
| 20:15:37 | Yardanico | https://github.com/pragmagic/karax/blob/master/karax/tools/karun.nim |
| 20:15:50 | FromDiscord | <nikki> trying to find where newSeq is impl'd |
| 20:16:05 | leorize[m] | ~matrix |
| 20:16:05 | disbot | matrix: 11Nim channels on Matrix can be found at +nim:asra.gr (https://matrix.to/#/+nim:asra.gr) |
| 20:16:06 | FromDiscord | <Clyybber> are you using gc:arc? |
| 20:16:13 | leorize[m] | scott_tams: ^ |
| 20:16:39 | disruptek | how did we even get on this subject. |
| 20:16:42 | FromDiscord | <nikki> @Clyybber are you asking me? i was thinking to when i want deterministic lifetime behavior |
| 20:17:05 | FromDiscord | <Clyybber> oh, because of the newSeq impl I mean |
| 20:17:13 | Yardanico | @nikki https://github.com/nim-lang/Nim/blob/devel/compiler/ccgexprs.nim#L1361 |
| 20:17:19 | Yardanico | it calls newSeqPayload |
| 20:17:25 | Yardanico | from seqs_v2 with --gc:arc or orc |
| 20:17:29 | Yardanico | https://github.com/nim-lang/Nim/blob/devel/lib/system/seqs_v2.nim#L34 |
| 20:17:58 | FromDiscord | <nikki> hmm i guess i meant the newSeq_<mangle> in the C backend output |
| 20:18:01 | FromDiscord | <Clyybber> and otherwise it calls the newSeq procs in lib/system/* |
| 20:18:08 | FromDiscord | <nikki> it's written in nim and linked in right |
| 20:18:21 | FromDiscord | <nikki> not as much the codegen for a newSeq in nim code |
| 20:18:36 | Yardanico | @nikki they all will just call newSeqPayload with arc/orc anyway |
| 20:18:37 | disruptek | sure. |
| 20:18:58 | FromDiscord | <nikki> awesome thanks for that second one @Yardanico |
| 20:23:59 | scott_tams | what is the difference between `when` and `if`? |
| 20:24:14 | oal | when is checked compile time I think |
| 20:24:16 | disruptek | when is compile-time. |
| 20:24:22 | scott_tams | :+1: |
| 20:24:30 | disruptek | shashlick: are you busy? |
| 20:24:34 | Yardanico | @shashlick ^ |
| 20:29:09 | * | ForumUpdaterBot quit (Remote host closed the connection) |
| 20:29:17 | * | ForumUpdaterBot joined #nim |
| 20:30:58 | * | narimiran quit (Ping timeout: 272 seconds) |
| 20:32:37 | * | madpata joined #nim |
| 20:34:43 | disruptek | @shashlick nevermind, i figured it out. |
| 20:44:53 | * | oal quit (Quit: oal) |
| 20:53:41 | FromDiscord | <nikki> is there a way to say `--gc:arc` in nim playground? |
| 20:55:32 | FromDiscord | <nikki> in any case, really glad things work this way: |
| 20:55:35 | FromDiscord | <nikki> https://media.discordapp.net/attachments/371759389889003532/767128697001738250/unknown.png |
| 20:56:05 | * | lritter quit (Ping timeout: 265 seconds) |
| 20:56:19 | FromDiscord | <nikki> sorry about overuse of the world 'test' lol |
| 20:56:48 | Yardanico | @nikki no |
| 20:56:56 | Yardanico | no way to change it on playground for now |
| 20:57:12 | FromDiscord | <nikki> word. no way to tell the compiler to enable a flag in eg. a main module top-of-the-file pragma or sth |
| 20:57:14 | leorize[m] | you don't need arc for destructors to work btw |
| 20:57:19 | Yardanico | that too^ |
| 20:57:42 | FromDiscord | <nikki> leorize i found that it didn't deterministically cascande to the seq elems with arc off |
| 20:58:00 | FromDiscord | <nikki> https://media.discordapp.net/attachments/371759389889003532/767129305443467334/unknown.png |
| 20:58:02 | FromDiscord | <nikki> example with on / off ^ |
| 20:58:10 | Yardanico | yes, refc wouldn't call destroys right away |
| 20:58:15 | Yardanico | unless you call GC_fullCollect() |
| 21:00:04 | FromDiscord | <haxscramper> @nikki You can try using https://wandbox.org/ - it also has the latest nim build and supports compilation flags. There is no syntax highlighting though |
| 21:02:02 | scott_tams | nim compiles to C/C++/JS, rather than ASM or LLVM IR, correct? Is there any way to see the resulting C or C++? |
| 21:02:25 | FromDiscord | <nikki> they show up in '~/.cache/nim' for me |
| 21:02:34 | FromDiscord | <nikki> depends on that cache location on your system / nim config |
| 21:02:43 | Yardanico | you can also override that |
| 21:02:46 | Yardanico | by --nimcache:folder |
| 21:04:18 | scott_tams | yes, I see. |
| 21:07:11 | * | scott_tams quit (Quit: Leaving) |
| 21:07:27 | FromDiscord | <William_CTO> I bought the book Nim in Action. I know the book was written before the release of 1.0, but it says that nim can be complied down to Obj C, is that still true? |
| 21:07:54 | FromDiscord | <nikki> yep |
| 21:08:46 | leorize[m] | yes |
| 21:09:35 | FromDiscord | <scott> sent a code paste, see https://play.nim-lang.org/#ix=2B4b |
| 21:11:45 | leorize[m] | Nim's C is not pretty :p |
| 21:12:14 | FromDiscord | <scott> I mean, it's better than webpack/babel's JS from what I've seen |
| 21:13:21 | Zevv | is there a proc that toggles a var bool in stdlib? |
| 21:13:28 | Yardanico | lol |
| 21:13:31 | FromDiscord | <Clyybber> disruptek is working on making it prettier |
| 21:13:33 | Yardanico | i don't think so :P |
| 21:13:36 | leorize[m] | why would you need that lol |
| 21:13:45 | FromDiscord | <Clyybber> thats also why he went crazy |
| 21:13:51 | FromDiscord | <Clyybber> Zevv: lol |
| 21:13:51 | FromDiscord | <lqdev> `x = not x` you're repeating `x` twice :) |
| 21:13:52 | Zevv | this.that.someThing.bla = not this.that.someThing.bla |
| 21:13:58 | FromDiscord | <lqdev> ↑ |
| 21:13:58 | Zevv | I want this.that.someThing.bla.toggle() |
| 21:13:58 | FromDiscord | <scott> @Clyybber that makes sense 😂 |
| 21:14:21 | disruptek | x = not x |
| 21:14:23 | FromDiscord | <scott> zevv `func toggle(x: bool): bool = not x |
| 21:14:25 | FromDiscord | <scott> (edit) 'x' => 'x`' |
| 21:14:36 | FromDiscord | <lqdev> not the thing |
| 21:14:43 | Zevv | yeah sure, I have that. |
| 21:14:46 | FromDiscord | <lqdev> `proc toggle(x: var bool) = x = not x` |
| 21:14:52 | Zevv | but I was wondering if there was a default version of that in stdlib |
| 21:15:03 | disruptek | yeah, there is. |
| 21:15:03 | leorize[m] | !eval proc toggle(x: var bool) = x = not x |
| 21:15:06 | disruptek | x = not x |
| 21:15:07 | NimBot | <no output> |
| 21:15:12 | Zevv | disruptek: ready ^^ |
| 21:15:25 | Zevv | "read" I mean |
| 21:15:25 | Zevv | this.that.someThing.bla = not this.that.someThing.bla |
| 21:15:38 | mipri | grep -Pr 'proc|func' lib/|grep -P 'bool.*bool'|grep var # no output. conclusion, it's not in stdlib |
| 21:15:51 | disruptek | i know you don't like it, but you know what? |
| 21:15:53 | disruptek | you're wrong. |
| 21:16:01 | disruptek | toggle is the wrong way to do this. |
| 21:16:13 | disruptek | x = not x captures the semantic perfectly. |
| 21:17:13 | Zevv | sure. But DRY |
| 21:17:18 | FromDiscord | <scott> yeah, what disruptek said |
| 21:17:21 | Zevv | it's error prone |
| 21:17:28 | FromDiscord | <scott> It's not repeating yourself, nor error prone |
| 21:17:35 | FromDiscord | <nikki> are you doing that a lot? |
| 21:17:39 | Zevv | IT is. I need to type 'x' twice |
| 21:17:40 | FromDiscord | <nikki> toggling some bool var |
| 21:17:43 | Zevv | and 'x' is 'this.that.someThing.bla' |
| 21:17:52 | mipri | Ada 2020 added @ as a shorthand for the lefthand side of the an assignment. so there it'd be this.that.someThing = not @; |
| 21:17:53 | Zevv | Pretty often |
| 21:18:02 | Zevv | That is cool |
| 21:18:11 | FromDiscord | <scott> yeah that is pretty smart |
| 21:18:19 | Zevv | In C I always do `^= 1` |
| 21:18:24 | FromDiscord | <Clyybber> mipri: Interesting |
| 21:18:36 | FromDiscord | <scott> if you really want the convenience, write the proc. If you think it should be part of stdlib, it wouldn't be hard to make a PR I don't think |
| 21:18:49 | leorize[m] | something like that need an RFC :P |
| 21:18:50 | FromDiscord | <nikki> Zevv that only works if true == 1 |
| 21:18:59 | mipri | er, := for assignment. It's a nice way of getting around Ada not having += operators |
| 21:19:04 | FromDiscord | <nikki> but in C any non-zero is true |
| 21:19:16 | FromDiscord | <nikki> but yeah if you make sure you use 1 only it works |
| 21:19:28 | Zevv | nikki: Why do you think I'm writing Nim and not C |
| 21:19:30 | disruptek | terrible idea, honestly. |
| 21:19:31 | Zevv | :) |
| 21:19:41 | Zevv | C is full of terrible ideas. |
| 21:19:42 | disruptek | toggle() tells me absolutely nothing. |
| 21:19:43 | Zevv | I love it. |
| 21:19:54 | Zevv | whiner |
| 21:19:57 | FromDiscord | <scott> it doesn't seem like a farfetched sugar to me |
| 21:20:08 | disruptek | it doesn't tell me if it's idempotent, what type it is, whether it as side effects, etc. |
| 21:20:26 | Zevv | `toggle!`(), because I love you too |
| 21:20:32 | Zevv | and everybody loves Ruby |
| 21:20:41 | disruptek | off and on as enums that equal false and true. these are acceptable sugar. |
| 21:20:46 | disruptek | toggle() is horribad. |
| 21:20:52 | FromDiscord | <scott> can procs shout in nim? |
| 21:20:57 | disruptek | mine do. |
| 21:21:10 | FromDiscord | <nikki> i wonder why you're flipping booleans so often haha |
| 21:21:15 | disruptek | they scream, "FABULOUS!" |
| 21:21:20 | FromDiscord | <nikki> but also that the flipping isn't some reusable domain-word |
| 21:21:22 | Zevv | nikki: user interface |
| 21:21:26 | FromDiscord | <nikki> like if you had flipFlag then sure |
| 21:21:28 | Zevv | it's called a toggle button |
| 21:21:38 | FromDiscord | <nikki> why does it end up happening many places over the code |
| 21:21:43 | FromDiscord | <nikki> don't you have just one toggle button component |
| 21:21:53 | FromDiscord | <scott> lol, disruptek, methods in Ruby/Crystal which end in the exclamation mark are referred to as methods which "shout" |
| 21:21:54 | FromDiscord | <nikki> or send a var bool to the toggle button code and flip it there |
| 21:21:56 | disruptek | he wants to type less, is all. |
| 21:22:00 | Zevv | because my code is just bad |
| 21:22:11 | FromDiscord | <scott> ones that end in the question mark are said to "ask" |
| 21:22:12 | Zevv | I'm beyond shame |
| 21:22:21 | FromDiscord | <nikki> pics of code? |
| 21:22:22 | FromDiscord | <nikki> jk |
| 21:22:30 | disruptek | just template foo = some.stupid.long.shit and then you can foo = not foo like a sane person. |
| 21:22:34 | Zevv | "pics of code" |
| 21:22:41 | leorize[m] | !eval import with; var a = false; a.with: _ = not _ |
| 21:22:41 | Zevv | that's very 2020 |
| 21:22:42 | NimBot | Compile failed: /playground/nim/lib/system/fatal.nim(49, 5) Error: unhandled exception: /playground/nimble/with-0.4.0/with.nim(15, 9) `t.kind in {nnkObjectTy, nnkTupleTy}` `with` must be called with either objects or tuples. [AssertionDefect] |
| 21:22:48 | Zevv | in the old days we just used ASCII For that |
| 21:22:51 | FromDiscord | <scott> I still don't see what's wrong with tossing `func toggle(var x: bool) = x = not x`? |
| 21:23:12 | Zevv | nothing is, but disruptek |
| 21:23:15 | FromDiscord | <nikki> if you do that you can't have a long-winded discussion on discord |
| 21:23:22 | disruptek | i thought you said you agreed with me. |
| 21:23:58 | FromDiscord | <scott> Zevv, I meant in your code, not the stdlib |
| 21:24:04 | leorize[m] | !eval import with; var a = false; a.with: `=` not _ |
| 21:24:06 | NimBot | Compile failed: /playground/nim/lib/system/fatal.nim(49, 5) Error: unhandled exception: /playground/nimble/with-0.4.0/with.nim(15, 9) `t.kind in {nnkObjectTy, nnkTupleTy}` `with` must be called with either objects or tuples. [AssertionDefect] |
| 21:24:22 | leorize[m] | gah, with is limited |
| 21:24:26 | Zevv | scott: I forked my own stdlib when I forked Nim |
| 21:24:33 | Zevv | in my parallel universe, I have it alll |
| 21:24:41 | FromDiscord | <scott> leorize, just use the playground |
| 21:25:01 | leorize[m] | oh lol with is not limited |
| 21:25:08 | leorize[m] | playground has the `with` package installed |
| 21:25:22 | FromDiscord | <scott> hm? |
| 21:25:37 | FromDiscord | <scott> I was saying link to the playground instead of trying to !eval |
| 21:26:55 | leorize[m] | oh sorry I wasn't talking to you :P |
| 21:27:00 | FromDiscord | <nikki> is there some mode or something one can turn on to check that there were no mem leaks with arc? i was playing around with having manually managed memory that holds arc objects etc. |
| 21:27:00 | mipri | https://play.nim-lang.org/#ix=2B4h |
| 21:27:03 | disruptek | i want to be fat enough to wear a tool apron as a bib. |
| 21:27:07 | leorize[m] | I was referring to my statement earlier |
| 21:27:09 | mipri | it does look nicer with with |
| 21:27:11 | FromDiscord | <nikki> seems like one way is to use malloc + valgrind? |
| 21:27:20 | * | solitudesf quit (Ping timeout: 272 seconds) |
| 21:27:23 | disruptek | use valgrind. |
| 21:27:42 | disruptek | yes, with useMalloc. |
| 21:28:04 | Yardanico | @NIKKI -d:useMalloc --gc:arc |
| 21:28:13 | Yardanico | there's also some debugging arc stuff but not really only for leaks |
| 21:28:25 | leorize[m] | stdlib `with` doesn't support multiple evaluation of `_` :( https://play.nim-lang.org/#ix=2B4j |
| 21:28:38 | FromDiscord | <nikki> yay no leaks i'm so happy thanks everyone |
| 21:28:45 | FromDiscord | <not_lum> hi |
| 21:28:56 | disruptek | me too. |
| 21:29:27 | FromDiscord | <scott> oh wow, that with statement is NICE |
| 21:29:40 | FromDiscord | <scott> is that a 3rd party package or stdlib? |
| 21:29:52 | mipri | the one I used was Zevv's. didn't know about stdlib |
| 21:30:35 | mipri | https://nim-lang.org/docs/lib.html doesn't know about it either |
| 21:30:48 | leorize[m] | the one I use was stdlib |
| 21:30:53 | Yardanico | yeah that needs to be updated mipri |
| 21:31:06 | FromDiscord | <nikki> arc is cool i'm really happy |
| 21:31:16 | disruptek | it's excellent. |
| 21:31:17 | leorize[m] | https://nim-lang.org/docs/with.html |
| 21:31:29 | FromDiscord | <nikki> this is like exactly the thing needed |
| 21:31:34 | FromDiscord | <nikki> the combination of features nim has |
| 21:31:37 | disruptek | yes. |
| 21:31:50 | disruptek | well, it has very good bones. |
| 21:32:06 | disruptek | there is a lot of work to be done, but nowhere to go but up. |
| 21:32:13 | FromDiscord | <nikki> it's a good place to be in |
| 21:32:26 | FromDiscord | <nikki> also the community is pretty awesome tbh |
| 21:33:29 | * | Vladar quit (Quit: Leaving) |
| 21:34:14 | leorize[m] | Zevv: fix std/with and you can have your DRY toggle :P |
| 21:35:18 | Zevv | in my stdlib with has long been fixed |
| 21:35:35 | Zevv | one day I'll fork the universe |
| 21:35:48 | FromDiscord | <scott> why not upstream? |
| 21:35:49 | Zevv | oh look I did just that! |
| 21:35:52 | Zevv | ooh and again |
| 21:36:00 | disruptek | eh we will fix the community eventually, but the code is easier. |
| 21:40:28 | FromDiscord | <nikki> how could i build with `-d:danger` but also get `-g` on the C compilation / link? |
| 21:40:37 | FromDiscord | <nikki> i want to step through it with gdb just to learn what's happening |
| 21:40:50 | FromDiscord | <nikki> _looks at docs_ |
| 21:41:41 | FromDiscord | <nikki> oh and actually step through the C / have gdb take me to the C, not the nim |
| 21:42:02 | FromDiscord | <scott> could you build with `-d:danger`, then compile the cached C code with `gdb -g`? |
| 21:42:39 | FromDiscord | <nikki> oh totes. was jw if there was a quick way from the nim compiler commadn itself |
| 21:42:44 | FromDiscord | <lqdev> --debugger:gdb |
| 21:42:55 | FromDiscord | <Recruit_main707> ^ |
| 21:43:02 | FromDiscord | <lqdev> or --debugger:native |
| 21:43:14 | FromDiscord | <nikki> i think `--debugger:native` makes gdb show nim code on breakpoint right? |
| 21:43:21 | FromDiscord | <lqdev> yes |
| 21:43:30 | leorize[m] | `nim -g --checks:off` |
| 21:43:31 | FromDiscord | <nikki> yea i wanna actually step through the C code :0 |
| 21:43:44 | FromDiscord | <nikki> the generated C code |
| 21:44:07 | leorize[m] | if you wanna step through the C code: `--linedirs:off` |
| 21:44:13 | FromDiscord | <nikki> kk |
| 21:44:24 | mipri | nim c -d:danger --passC:-g --verbosity:2 |
| 21:44:37 | FromDiscord | <nikki> passC 😄 |
| 21:44:39 | FromDiscord | <nikki> yay |
| 21:57:09 | FromDiscord | <nikki> ok just stepped through the C of my manual alloc + arc test with gdb |
| 21:57:13 | FromDiscord | <nikki> my conclusion is that nim is awesome |
| 21:58:20 | FromDiscord | <Elegant Beef> Grats |
| 21:58:50 | FromDiscord | <scott> yeah arc is why I'm checking out nim again |
| 21:59:27 | FromDiscord | <scott> really pleasantly surpised with ergonomics too 🙂 |
| 21:59:49 | FromDiscord | <nikki> i also really like that it gens C and i can gdb thru the C and i understand how much stuff the computer would do |
| 21:59:58 | FromDiscord | <nikki> it's not actually that tractable to do the same with C++ |
| 22:00:22 | FromDiscord | <nikki> also the gen'd C just using structs for the objects |
| 22:00:45 | FromDiscord | <scott> hm, that's interesting. I kinda was viewing the C target as a negative, but that is a nice upside |
| 22:00:56 | FromDiscord | <Elegant Beef> Why is the C target a negative? |
| 22:01:07 | FromDiscord | <nikki> like there's no "hidden control flow" but it's still higher level than parsing the straight up asm, which i'd do when compiling C++ |
| 22:01:42 | FromDiscord | <scott> because I don't like the idea of targeting a text-based output. it seems more prone to confusing bugs than an intermediary bytecode like LLVM IR. |
| 22:01:51 | FromDiscord | <nikki> @scott i think C is proving to be a good IR + gives natural interop with C and other C ABI libs without resorting to eg. ffi |
| 22:02:05 | mipri | the worry with a transpiler is always that you'll have to deal with two languages |
| 22:02:13 | FromDiscord | <scott> yeah exactly |
| 22:02:20 | leorize[m] | isn't LLVM IR text also? |
| 22:02:36 | disruptek | it doesn't have to be. 😉 |
| 22:02:41 | FromDiscord | <nikki> usually you just use llvm as a library in the compiler and just generate its in memory IR repr |
| 22:02:42 | FromDiscord | <scott> sorry, I meant the bytecode that LLVM IR translates directly to |
| 22:02:56 | mipri | Nim's good on that. actually I wish it weren't so good, I'd like to emit an #include and then define some unary functions that emit C macros or such |
| 22:03:01 | disruptek | scott: the reason c is a win is embedded and maybe gpu stuff. |
| 22:03:07 | FromDiscord | <scott> like IR -> LLVM bytecode as ASM -> machine code |
| 22:03:20 | FromDiscord | <Elegant Beef> Meanwhile i'm going "Nim Vm, Nim Vm" and cheering that this method gives an portable interpreted subset 😄 |
| 22:03:39 | leorize[m] | Nim's C output is pretty structured |
| 22:03:42 | FromDiscord | <nikki> @scott with the text thing, did you mean bugs as a user of the lang, or as a compiler author |
| 22:03:50 | leorize[m] | the backend have a pseudo C AST and a renderer |
| 22:03:56 | leorize[m] | so it's pretty solid |
| 22:04:03 | FromDiscord | <nikki> i think if the compiler is well tested and stable and i trust the devs, then it ends up netting positive |
| 22:04:17 | FromDiscord | <scott> @nikki I mean the potential for an interaction of bugs in both instances as with any other transpiled language |
| 22:04:20 | disruptek | clyybber: do you want the current example of mangling that i'm working on? i can present the problem here, finally. |
| 22:04:36 | FromDiscord | <nikki> yeah i'd be curious to see concrete instances of that if / when you run into them |
| 22:05:23 | FromDiscord | <nikki> the capability for interop with C++ templates is p nice too, not sure i'd use it soon except maybe with entt |
| 22:05:30 | FromDiscord | <nikki> but i'm mostly considering flecs |
| 22:05:34 | Yardanico | well it can happen, but it's pretty rare @nikki |
| 22:05:44 | disruptek | @clyybber: ^ |
| 22:05:48 | Yardanico | i mean C compiler errors for nim-compiled C code |
| 22:06:05 | FromDiscord | <scott> probably more rare than a Crystal compiler error, that's for damn sure 😁 |
| 22:06:05 | FromDiscord | <nikki> yea that's what i was thinking. it depends on the stability of the lang i think; but nim has seemed to come far |
| 22:06:10 | FromDiscord | <Clyybber> disruptek: Yeah,! |
| 22:06:21 | leorize[m] | I'm pretty sure Nim's `shr`/`shl` still have the same undefined behavior as C |
| 22:06:25 | disruptek | okay. |
| 22:06:30 | FromDiscord | <Clyybber> leorize: Nope |
| 22:06:34 | FromDiscord | <Clyybber> They are masked |
| 22:06:43 | disruptek | so i'm working on the tjsonutils.cpp test. |
| 22:06:44 | leorize[m] | oh, krux PR went in? |
| 22:06:45 | leorize[m] | nice |
| 22:06:57 | FromDiscord | <Clyybber> I *think* so |
| 22:07:13 | FromDiscord | <nikki> i think @scott it could be that, a C repr is more high level and to do an llvm IR output you generate this high level model anyway then codegen to IR yourself too, whereas with C output you reduce that work |
| 22:07:22 | FromDiscord | <nikki> which actually means less code that can have bugs |
| 22:07:24 | FromDiscord | <Clyybber> leorize: oh, its not |
| 22:07:55 | leorize[m] | it's the sort of undefined behavior that you're unlikely to hit, so I don't worry too much |
| 22:08:10 | disruptek | due to order of generics, the $ of a ordered-key-value-pair (tuple) from tables, when comprised of string and JsonNodeObj, eg. a JObject most likely, is defined as taking an argument x with different names. |
| 22:08:21 | leorize[m] | most of C undefined behaviors has been turned into runtime & compile-time checks iirc |
| 22:08:26 | FromDiscord | <nikki> that is mostly only true it the frontend lang is similar enough to C, and it seems to be. like there's the runtime, and them the macros / static lookup stuff which you'd have to impl anyways even when targetting LLVM IR |
| 22:08:52 | disruptek | in one case, it takes tupJsonNode_std_json_3 and in another it takes OrderedKeyValuePair_std_tables. |
| 22:09:25 | disruptek | and this is a problem on c++ because c++ forms a proc symbol using the function name and the first argument typename. |
| 22:09:40 | disruptek | so we get a linking failure. |
| 22:10:10 | FromDiscord | <nikki> leorize i don't think UB captures all of the types of issues scott is talking about, maybe he was getting more at the kind of issues u see in other transpilation situations eg. babel, cljs, ... |
| 22:10:19 | FromDiscord | <nikki> which don't depend on UB in the backend lang |
| 22:11:48 | FromDiscord | <nikki> btw quick q--- if this works: |
| 22:11:54 | FromDiscord | <nikki> https://media.discordapp.net/attachments/371759389889003532/767147900282470420/image0.png |
| 22:12:09 | FromDiscord | <nikki> that means that it'll properly work for a nested spaghetti of arc objects in Elem right |
| 22:12:22 | FromDiscord | <nikki> will try some spaghetti soon i guess |
| 22:12:28 | disruptek | yum. |
| 22:12:52 | leorize[m] | yes it will |
| 22:13:03 | disruptek | i had mexican for the first time in over a year last night. |
| 22:13:14 | disruptek | and she says her sister is a redhead. go figure. |
| 22:13:29 | disruptek | it's a crazy world we live in. |
| 22:13:57 | leorize[m] | you're unlikely to surpass the amount of spaghetti within Nim's asyncdispatch :P |
| 22:14:05 | FromDiscord | <Clyybber> lol |
| 22:14:09 | Zevv | cmon fix csp then |
| 22:15:00 | disruptek | what's wrong with cps? |
| 22:15:21 | disruptek | we're not waiting on me, right? |
| 22:15:21 | FromDiscord | <nikki> did zevv actually mean csp lol |
| 22:15:27 | FromDiscord | <nikki> which is channels n thingies |
| 22:15:33 | FromDiscord | <nikki> while csp is continuations |
| 22:15:36 | disruptek | csp comes after we finish cps. |
| 22:15:41 | FromDiscord | <nikki> (edit) 'csp' => 'cps' |
| 22:15:50 | FromDiscord | <nikki> cool :0 |
| 22:16:02 | FromDiscord | <nikki> when do we get actors |
| 22:16:15 | disruptek | well, you can make actors if you want. |
| 22:16:35 | disruptek | i want csp primitives first. |
| 22:16:53 | FromDiscord | <nikki> will do |
| 22:17:17 | FromDiscord | <nikki> i've always if you take a csp graph |
| 22:17:24 | FromDiscord | <nikki> and then take its line graph or dual or sth |
| 22:17:27 | FromDiscord | <nikki> u get actors |
| 22:17:36 | FromDiscord | <nikki> (edit) 'i've always ... if' => 'i've alwaysfelt like' |
| 22:18:00 | disruptek | okay, but i personally don't think actors mesh well with the rest of nim. |
| 22:18:21 | FromDiscord | <nikki> oh yeah. i'm not saying actors mesh well with the rest of nim |
| 22:18:26 | FromDiscord | <nikki> just playin' 'round |
| 22:18:37 | disruptek | yeah, once cps works properly, we'll have a lot of options. |
| 22:18:43 | FromDiscord | <nikki> i don't write much asyncblah code usually |
| 22:18:46 | disruptek | everything is on the table. everything can be done. |
| 22:18:57 | FromDiscord | <nikki> yea seems like it. nim is p flexible |
| 22:19:20 | disruptek | !repo cps |
| 22:19:21 | disbot | https://github.com/disruptek/cps -- 9cps: 11Continuation-Passing Style for Nim 🔗 15 39⭐ 2🍴 |
| 22:19:28 | FromDiscord | <nikki> i feel like nim's syntax structure makes for way saner macros than s-exps |
| 22:19:43 | disruptek | to read, you mean? |
| 22:19:48 | FromDiscord | <nikki> yea saw that earlier disruptek and was reading thru some examples |
| 22:19:57 | FromDiscord | <nikki> yea the UX of actually using the macros |
| 22:20:45 | disruptek | it's just an easier dsl, but it's not really different. |
| 22:20:52 | disruptek | i mean, i like that. |
| 22:21:40 | FromDiscord | <haxscramper> I've spent about ~3+ years using emacs etc. and still can't really get around lisp macros, because of ergonomics. Nim macros are /much/ better compared to lisp, since you know what you are dealing with |
| 22:21:54 | disruptek | i mean, "tool bib" isn't really a thing. is that insane or what? |
| 22:22:00 | disruptek | where are all the fat people? |
| 22:22:29 | FromDiscord | <nikki> well, i think having read some nim, after having done a fair amt of lisp, it feels like i understand ppl's nim dsls quicker. it's not that different for sure but just like empirical human feelz thingies |
| 22:23:03 | FromDiscord | <haxscramper> Like this is a regular case object tree + lisp syntax is just simply **the bad** thing |
| 22:29:32 | FromDiscord | <Rythm> sent a long message, see http://ix.io/2B4D |
| 22:34:10 | * | nature quit (Quit: WeeChat 2.9) |
| 22:38:18 | FromDiscord | <Jockie Music (1)> |
| 22:42:24 | FromDiscord | <haxscramper> How to check if file `isMainModule`, except for cases where documentation is being built? Does `nim doc` create some `define` that I can check? |
| 22:42:30 | disruptek | nimdoc |
| 22:59:39 | * | madpata quit (Ping timeout: 258 seconds) |
| 23:11:38 | * | vicfred joined #nim |
| 23:37:35 | * | a_chou joined #nim |
| 23:59:29 | FromDiscord | <Clyybber> disruptek: Ha, ok. How does current mangling do it? |
