00:00:02 | FromDiscord | <Rika> but im not sure of the `=destroy` one |
00:02:03 | * | brainproxy joined #nim |
00:03:52 | zacharycarter | yeah you can destroy things in Nim whenever you want by calling `=destroy` |
00:04:02 | zacharycarter | and you can defer it if you want to as well I'm pretty sure |
00:04:10 | zacharycarter | and you can write custom destructors |
00:04:13 | zacharycarter | so what's the beef? |
00:04:34 | zacharycarter | in all seriousness beef looks cool but way less mature than Nim |
00:04:43 | zacharycarter | and I don't like IDEs |
00:04:50 | FromDiscord | <Rika> Beef is a developing open source, statically-typed programming language, designed and developed by Brian Fiete (one of PopCap founders), whose syntax is mainly derived from C# programming language and targeted for high-performance execution. |
00:04:52 | FromDiscord | <Rika> 😛 |
00:05:42 | skrylar[m] | the universe is trying to keep me honest tho :p any temptation i had for beef died with making several attempts to get it to work, and me not wanting to debug llvm dependencies |
00:06:22 | * | brainproxy quit (Ping timeout: 246 seconds) |
00:08:01 | zacharycarter | Red looks interesting |
00:09:04 | zacharycarter | but no x86-64 support yet |
00:09:57 | skrylar[m] | i liked red until they became a buttcoin |
00:14:32 | skrylar[m] | weird. i tried hcr on windows again and in 0.20 it doesn't crash on aftercodereload, but it also doesn't work |
00:14:47 | zacharycarter | I wouldn't use hcr |
00:14:58 | skrylar[m] | or rather hasmodulechanged doesn't work, but aftercodereload does. |
00:15:10 | zacharycarter | if you want to hot reload - do what I did and use cr.h and look at frag |
00:15:16 | zacharycarter | all the code is there |
00:16:02 | skrylar[m] | no idea why devel crashes and 0.20 works except for `has_module_changed` |
00:16:21 | FromDiscord | <KingDarBoja> PopCap? Plants vs Zombies company right-? |
00:16:29 | zacharycarter | no idea |
00:16:31 | skrylar[m] | yes. successful casual games place |
00:16:51 | skrylar[m] | beef has a lot of weird memory stuff because memory fragmentation is a big deal for AAA-devs |
00:16:58 | * | brainproxy joined #nim |
00:17:26 | zacharycarter | wait - do they develop beef? |
00:17:33 | skrylar[m] | the ex-head dev does |
00:17:36 | zacharycarter | ah |
00:17:47 | * | dadada quit (Ping timeout: 256 seconds) |
00:17:51 | skrylar[m] | i suspect thats also why append allocators exist |
00:18:27 | zacharycarter | some of these features just don't make sense to me |
00:18:34 | skrylar[m] | because they make an instance claim a variable size, and any beef object can be forced to the stack with `scope` |
00:18:42 | zacharycarter | like leak detection in real time - there are already tools for this |
00:19:01 | zacharycarter | custom allocators w/ manual memory management I mean is that even something to brag about? |
00:19:20 | skrylar[m] | they are AAA devs. so, yes |
00:19:33 | zacharycarter | mixing optimization levels is cool I guess but if you're debugging the app just make a debug build? |
00:19:51 | skrylar[m] | eh you'll understand someday i guess |
00:20:08 | zacharycarter | what will I understand? |
00:21:13 | skrylar[m] | AAA devs have more problems than indie devs on pc's do. they can't just tell people to buy more ram for their xbox. so stuff like memory fragmentation is a reality in their world |
00:21:23 | skrylar[m] | which is why custom allocators and arenas are a thing for them |
00:21:34 | zacharycarter | I wasn't talking about memory fragmentation |
00:21:48 | zacharycarter | I was talking about realitime leak detection and custom allocators - like you can do this with C/C++ already |
00:21:51 | skrylar[m] | mixed optim happens over there too :\ |
00:22:00 | zacharycarter | which you also have to manually allocate memory for |
00:22:18 | zacharycarter | hell you can write custom allocators with Nim too |
00:22:31 | skrylar[m] | ey probably mentions it because so many new langs are GC, so he has to say "look, no GC" |
00:22:38 | zacharycarter | I guess |
00:23:05 | skrylar[m] | defer is nicec |
00:24:42 | skrylar[m] | he may do okay when they get the rough edges out of the tooling. i can see it being an easier sell to disgruntled unity users "hey its still C#, but it compiles." since a lot of people wanted ... C#, on bare metal |
00:25:03 | zacharycarter | well they won't want to use it if they have to manually manage memory |
00:25:19 | zacharycarter | they don't have to do that in C# |
00:25:36 | skrylar[m] | i dunno. gamedev tend to fight the gc anyway |
00:26:00 | zacharycarter | yeah but not unity users haha |
00:26:01 | skrylar[m] | ours with the incremental mode turned on is nice |
00:27:08 | skrylar[m] | haven't tested doing custom allocs in nim yet though. ex. the items that live in a custom allocator for a single frame part |
00:27:35 | * | dadada joined #nim |
00:27:35 | skrylar[m] | janet does have an API for this where you can ask for scratch space |
00:27:58 | * | dadada is now known as Guest42873 |
00:30:27 | zacharycarter | I guess the difference is you won't be able to use the stdlib in Nim with custom allocators |
00:30:32 | zacharycarter | I don't know if that's the case with beef or not |
00:31:11 | zacharycarter | but lots of people don't use C++'s stdlib |
00:31:22 | zacharycarter | so I think this is fine |
00:31:58 | zacharycarter | I like Nim's flexibility - if I want to use a custom allocator / manual memory management in certain situations I am free to do so |
00:32:06 | zacharycarter | and then in other areas of my program I can rely on the stdlib |
00:32:10 | * | covidian is now known as ii |
00:32:11 | * | ii is now known as covidian |
00:32:18 | zacharycarter | just like I can in C++ |
00:32:27 | zacharycarter | but I have the benefit of ARC / the GC |
00:32:37 | * | brainproxy quit (Ping timeout: 246 seconds) |
00:32:42 | skrylar[m] | some of those get annoying when strings implicitly call stdlib stuff and you are trying to go gcless |
00:32:48 | skrylar[m] | D had this problem |
00:33:06 | zacharycarter | write your own string impl then |
00:33:33 | skrylar[m] | I'm sure someone did |
00:33:43 | leorize | I'm pretty sure nim strings don't implicitly call anything |
00:33:55 | leorize | but I'm not following the conversation so :P |
00:34:07 | skrylar[m] | string concat does iirc |
00:34:36 | leorize | ahhh you're talking about custom allocators |
00:35:34 | zacharycarter | yeah |
00:35:50 | zacharycarter | just don't use any of Nim's memory management if you want to use custom allocators |
00:35:55 | zacharycarter | pretend Nim is C and you're fine |
00:36:28 | skrylar[m] | i do tend to separate the init from alloc for that reason but.. eh. |
00:37:04 | leorize | it's not too hard to write your own string implementation either, now that we have enough type hooks for basically everything |
00:37:20 | skrylar[m] | nothing sells users on a toolchain like "write it yourself" ;) |
00:38:01 | leorize | specialize use cases require specialize tooling :P |
00:51:42 | * | Guest42873 quit (Ping timeout: 260 seconds) |
00:56:56 | * | brainproxy joined #nim |
00:57:26 | * | dadada__ joined #nim |
01:02:47 | * | brainproxy quit (Ping timeout: 260 seconds) |
01:06:28 | yumaikas | Question: Is there a known way to make async/thread safe globals? |
01:07:21 | yumaikas | (I'd be fine with a mutex or the like, just wondering if there's a way to do that and convince the compiler it's safe) |
01:11:51 | * | brainproxy joined #nim |
01:13:37 | zacharycarter | yumaikas: do you mean the global is using GC'd memory? |
01:14:12 | yumaikas | zacharycarter: If there's a way to eval a function once, and then let the global be constant, that would work too |
01:14:47 | yumaikas | (Basically, a nim version of C#'s Lazy<T> would be ideal) |
01:14:56 | zacharycarter | yeah but is the global using GC'd memory or is the memory manually allocated / allocated on the stack? |
01:15:26 | yumaikas | zacharycarter: it'd be in global scope. I'm assuming that's GC'd? |
01:15:27 | yumaikas | https://github.com/yumaikas/tabulaScripta/blob/master/webConfig.nim |
01:15:29 | disruptek | {.gcsafe.} |
01:15:48 | yumaikas | Example of things that I want to do, in some form |
01:15:58 | yumaikas | -----------------------------------------------------------^ |
01:16:22 | zacharycarter | what type is the variable? |
01:16:43 | yumaikas | string/int, in most cases |
01:16:47 | zacharycarter | int is fine |
01:16:49 | zacharycarter | string is not |
01:17:04 | zacharycarter | you could move the string to the thread but the original reference to the string would become unusable |
01:17:08 | zacharycarter | if you're using `--gc:arc` |
01:17:36 | yumaikas | I'm not planning on using arc, due to this being a webapp, where non-arc would probably be a better fit |
01:18:04 | zacharycarter | otherwise look at this issue" https://github.com/nim-lang/RFCs/issues/142 |
01:18:47 | * | avatarfighter quit (Ping timeout: 240 seconds) |
01:18:49 | * | brainproxy quit (Ping timeout: 246 seconds) |
01:21:27 | * | dadada__ quit (Ping timeout: 260 seconds) |
01:24:55 | * | dadada__ joined #nim |
01:30:35 | * | covidian is now known as ii |
01:30:36 | * | ii is now known as covidian |
01:30:39 | * | ryan_ joined #nim |
01:31:19 | yumaikas | Hrm.... |
01:31:38 | * | yumaikas is trying to think of how that'd interact with a multithreaded jester impl |
01:32:56 | * | Tlongir quit (Ping timeout: 256 seconds) |
01:33:58 | FromGitter | <Willyboar> disruptek i am here if you need feedback for your game :P |
01:34:32 | yumaikas | dom96: Do you have any recommendations on how to handel global/config type things in jester? |
01:34:44 | * | chapl quit (Remote host closed the connection) |
01:35:45 | FromDiscord | <Zed> disruptek's making a game?? what sort? |
01:36:02 | FromGitter | <Willyboar> I dont know yet |
01:36:18 | FromDiscord | <Zed> lol |
01:36:33 | FromGitter | <Willyboar> maybe is a secret |
01:38:11 | yumaikas | dom96: Or do you just live with globals giving memory access warnings? |
01:38:22 | * | avatarfighter joined #nim |
01:39:20 | * | brainproxy joined #nim |
01:40:34 | * | avatarfighter quit (Client Quit) |
01:40:41 | * | avatarfighter joined #nim |
01:41:14 | * | ryan_ is now known as jiblet |
01:41:18 | * | jiblet is now known as tjiblet |
01:45:52 | * | chemist69 quit (Ping timeout: 265 seconds) |
01:47:37 | * | chemist69 joined #nim |
01:47:46 | * | Hideki joined #nim |
01:48:09 | * | Hideki is now known as Guest45730 |
02:10:48 | * | mono joined #nim |
02:13:10 | * | monokrom quit (Ping timeout: 256 seconds) |
02:21:47 | * | muffindrake quit (Ping timeout: 240 seconds) |
02:23:51 | * | NimBot joined #nim |
02:24:18 | * | mono quit (Remote host closed the connection) |
02:24:22 | * | muffindrake joined #nim |
02:33:49 | zacharycarter | yumikas: jester uses httpbeast which relies on multiple threads - maybe look into its implementation |
02:34:17 | zacharycarter | ultimately if memory is accessed by threads and it's allocated on the heap, it's access needs to be synchronized |
02:34:41 | zacharycarter | and remember Nim's default GC uses a thread local heap so threads can't access eachother's heap |
02:35:03 | zacharycarter | so you need to either pass pointers and ensure lifetimes of allocations or you need to use channels |
02:35:18 | zacharycarter | or you can manually manage memory and allocated from the shared heap |
02:35:43 | zacharycarter | or use `--gc:arc` / `--gc:orc` which will eventually become the default memory management solution for Nim |
02:37:05 | zacharycarter | yumaikas ^ sorry I misspelled your handle |
02:49:25 | * | Guest45730 quit (Ping timeout: 264 seconds) |
02:50:39 | * | dadada__ quit (Ping timeout: 256 seconds) |
02:53:00 | * | dadada joined #nim |
02:53:23 | * | dadada is now known as Guest69279 |
02:57:07 | skrylar[m] | huh. well a logfmt module went a lot faster than i thought |
03:05:17 | * | rockcavera quit (Remote host closed the connection) |
03:06:58 | * | zacharyc1rter quit (Ping timeout: 246 seconds) |
03:06:59 | * | zacharycarter quit (Ping timeout: 246 seconds) |
03:10:32 | * | brainproxy quit (Ping timeout: 260 seconds) |
03:13:25 | skrylar[m] | i suppose telemtry would be the same as defer ... macro to bolt on to functions or blocks, have it just write the enter/exit calls |
03:16:07 | * | Hideki joined #nim |
03:16:31 | * | Hideki is now known as Guest31078 |
03:16:52 | * | Guest69279 quit (Ping timeout: 256 seconds) |
03:24:39 | disruptek | i hate defer. |
03:25:14 | FromDiscord | <Rika> why? |
03:25:41 | disruptek | !rfc try scope author:disruptek |
03:25:42 | disbot | https://github.com/nim-lang/RFCs/issues/218 -- 3try/except scope -- should it be a thing? |
03:27:33 | * | dadada__ joined #nim |
03:35:16 | * | brainproxy joined #nim |
03:46:15 | * | zacharyc1rter joined #nim |
03:46:16 | * | zacharycarter joined #nim |
03:50:07 | * | avatarfighter quit (Ping timeout: 244 seconds) |
03:50:42 | * | dadada__ quit (Ping timeout: 256 seconds) |
03:52:14 | * | dddddd quit (Remote host closed the connection) |
03:54:49 | * | thomasross quit (Ping timeout: 264 seconds) |
03:57:30 | * | dadada joined #nim |
03:57:53 | * | dadada is now known as Guest99744 |
04:06:01 | * | supakeen quit (Quit: WeeChat 1.9.1) |
04:06:17 | * | tjiblet is now known as tjiblet_thebless |
04:06:41 | * | supakeen joined #nim |
04:06:49 | shashlick | @leorize took your advice on the ABI issue, see my last comment |
04:10:40 | * | zacharycarter quit (Ping timeout: 246 seconds) |
04:11:01 | * | zacharyc1rter quit (Ping timeout: 246 seconds) |
04:12:25 | * | Guest31078 quit (Remote host closed the connection) |
04:14:11 | * | Hideki joined #nim |
04:14:35 | * | Hideki is now known as Guest3009 |
04:17:59 | * | narimiran joined #nim |
04:18:49 | * | Guest3009 quit (Ping timeout: 264 seconds) |
04:21:10 | * | Guest99744 quit (Ping timeout: 246 seconds) |
04:21:19 | * | avatarfighter joined #nim |
04:25:07 | Yardanico | Guess it was easier than I expected (compiling Nim for KolibriOS) https://i.imgur.com/IiJUw2G.png |
04:25:10 | Yardanico | os:any ftw |
04:25:52 | Yardanico | now need to port the simplest GUI example from C to Nim :P |
04:25:54 | * | avatarfighter quit (Remote host closed the connection) |
04:26:01 | * | avatarfighter joined #nim |
04:27:33 | * | dadada__ joined #nim |
04:28:49 | Yardanico | oh, I don't even have to use makefiles now, can do it fully with nim.cfg |
04:35:45 | * | waleee-cl quit (Quit: Connection closed for inactivity) |
04:36:53 | Yardanico | https://i.imgur.com/6BVHzyN.png |
04:36:55 | Yardanico | https://i.imgur.com/nLI6wYh.png |
04:37:15 | Yardanico | although I still need to do "objdump hello -O binary" manually after that |
04:40:46 | FromDiscord | <Avahe> @Elegant Beef So I accidentally fixed an issue with maim which I thought had to do with xatoms, but didn't. What application were you using to test fullscreen requests? |
04:41:48 | * | Hideki joined #nim |
04:42:11 | * | Hideki is now known as Guest96857 |
04:48:32 | FromDiscord | <Never Listen To Beef> Firefox/chrome |
04:50:25 | Prestige | Cool, thanks |
04:51:49 | * | dadada__ quit (Ping timeout: 264 seconds) |
04:57:30 | * | dadada joined #nim |
04:57:54 | * | dadada is now known as Guest74398 |
04:58:06 | * | Guest96857 quit (Remote host closed the connection) |
05:08:25 | Yardanico | new day, new bug reports :P https://github.com/nim-lang/Nim/issues/14240 |
05:08:28 | disbot | ➥ [ARC] C compiler error with dynlib pragma calling a proc ; snippet at 12https://play.nim-lang.org/#ix=2kY9 |
05:21:23 | * | Guest74398 quit (Ping timeout: 256 seconds) |
05:27:29 | * | dadada__ joined #nim |
05:44:40 | * | hoijui joined #nim |
05:53:31 | Prestige | @Elegant Beef got it working for a couple browsers but firefox seems to be doing something different with atoms |
05:55:34 | * | Hideki joined #nim |
05:55:58 | * | Hideki is now known as Guest73608 |
06:04:08 | FromDiscord | <Never Listen To Beef> Interesting |
06:04:14 | FromDiscord | <Never Listen To Beef> I dont get a fullscreen property |
06:04:20 | FromDiscord | <Never Listen To Beef> So i guess i do something wrong |
06:07:54 | dadada__ | can I get a value from every proc/func/expr, even if the expression doesn't return something, ie. void type, pseudo code: let valOrVoid = funcReturnsValOrVoid() |
06:08:12 | Yardanico | "let valOrVoid" there's your problem |
06:08:18 | Yardanico | variables can only have one type ;) |
06:08:23 | Yardanico | unless you're in a generic proc of course |
06:08:25 | Yardanico | or something like that |
06:09:32 | dadada__ | I know, I'm looking for a workaround, doesn't need to be beautiful |
06:09:45 | Yardanico | well I don't understand on what do you need it for :P |
06:13:18 | * | Guest73608 quit (Remote host closed the connection) |
06:13:32 | dadada__ | probably can use https://nim-lang.org/docs/system.html#compiles%2Cuntyped |
06:13:35 | dadada__ | to make the workaround |
06:13:45 | Yardanico | well yeah but the variable still only can have one type in most contexts |
06:13:49 | Prestige | @Elegant Beef still need to figure out why ff is sending different atoms.. vivaldi is sending the correct atoms but it doesn't seem to launch properly at all (invisible ui and errors in the console) |
06:14:06 | Yardanico | I would've recommended compiles if you explained better :P |
06:14:07 | Prestige | I'll link my current branch when I push so you can see what I did |
06:14:08 | FromDiscord | <Never Listen To Beef> Yea idk im putting my wm on brak for a bit |
06:14:14 | FromDiscord | <Never Listen To Beef> break* |
06:14:19 | Prestige | Oh ok |
06:14:43 | FromDiscord | <Never Listen To Beef> I've got issues with gnome software |
06:14:46 | FromDiscord | <Never Listen To Beef> well GTK stuff |
06:15:13 | FromDiscord | <Never Listen To Beef> Also im glad math contains Tau |
06:15:17 | FromDiscord | <Never Listen To Beef> Im happy for tau |
06:16:14 | Prestige | Tau? |
06:16:17 | Yardanico | yeah and my mathexpr lib uses and exposes it to the user :P https://github.com/Yardanico/nim-mathexpr/blob/master/src/mathexpr.nim#L230 |
06:16:27 | FromDiscord | <Never Listen To Beef> Yea tau is the best circle constant |
06:16:40 | Yardanico | Prestige: https://en.wikipedia.org/wiki/Turn_(angle)#Tau_proposals |
06:18:26 | FromDiscord | <Rika> wow. that sucks, i always did think tau was more intuitive than pi |
06:18:30 | FromDiscord | <Rika> when it came to circles |
06:18:37 | Prestige | Oh, neat |
06:19:09 | * | solitudesf joined #nim |
06:22:46 | FromDiscord | <Never Listen To Beef> Yea tau is, considering it's a direct degrees/360 to get it to a tau ration |
06:22:56 | FromDiscord | <Never Listen To Beef> ratio* |
06:23:17 | FromDiscord | <Rika> ayy, client.py of slider (an osu (the game) utility library) has been fully translated now |
06:23:17 | FromDiscord | <Rika> https://cdn.discordapp.com/attachments/371759389889003532/707477569695645716/unknown.png |
06:23:24 | * | PMunch joined #nim |
06:24:05 | Prestige | @Elegant Beef if you're interested anyway: https://github.com/avahe-kellenberger/nimdow/commit/1a9cfd1cc8c2b818a7812cade141dc8735ccffab |
06:25:32 | FromDiscord | <Never Listen To Beef> So wait you get proper fullscreen properties inside the property change event? |
06:26:12 | Prestige | That's the next step I suppose, atm I'm just listening for ClientMessages |
06:26:26 | FromDiscord | <Never Listen To Beef> Oh |
06:26:28 | FromDiscord | <Never Listen To Beef> That's a thing?! |
06:26:39 | Prestige | Read this: https://github.com/avahe-kellenberger/nimdow/issues/12 I made a summary |
06:26:40 | disbot | ➥ Fullscreen windows are not respected |
06:27:24 | FromDiscord | <Never Listen To Beef> I dont get why we have client messages and property changes |
06:27:44 | Prestige | Idk but it's probably one of the reasons Wayland exists lol |
06:27:48 | FromDiscord | <Never Listen To Beef> Lol |
06:29:52 | voltist | Anybody got any idea why `1/(1-exp(-(V-v2)/ka))` would give drastically different results to equation 4 in https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0218738&type=printable |
06:30:33 | FromDiscord | <Rika> what page is equation 4 |
06:30:36 | Prestige | Can you put it on play.nim-lang.org for us lazy folk? |
06:30:41 | FromDiscord | <Rika> 5? |
06:30:58 | voltist | Could it be that I have to write those ones as 1.0 to make the nim get it? |
06:31:08 | voltist | Yeah I'll put a sample up |
06:31:13 | voltist | It's on page 5 |
06:31:14 | FromDiscord | <Rika> no, / is float div |
06:31:32 | * | brainproxy quit (Ping timeout: 272 seconds) |
06:31:50 | FromDiscord | <Rika> it should be the same, what are you getting from eq.4 |
06:32:03 | narimiran | voltist: put in the comments what do you get from a calculator, so we can see the difference |
06:33:07 | voltist | I'll have to look through the paper to find one of the points the equation was fitted to in order to do a proper comparison |
06:33:24 | voltist | Because the nim playground won't do graphs |
06:36:41 | FromDiscord | <Rika> afaik nim playground has popular packages installed |
06:37:22 | Yardanico | well not a lot |
06:43:41 | voltist | https://play.nim-lang.org/#ix=2gcb |
06:43:53 | voltist | Does that work? I've never used nim playground before |
06:44:12 | Yardanico | try to patse again |
06:44:15 | Yardanico | it seems to be the wrong link |
06:44:30 | Yardanico | http://ix.io/2gcb is not nim :D |
06:44:32 | voltist | No it's right |
06:44:41 | narimiran | copy-paste in your own browser before pasting a link here ;) |
06:44:41 | Yardanico | ? |
06:44:58 | voltist | https://play.nim-lang.org/#ix=2kYw |
06:45:05 | voltist | That should work |
06:45:05 | * | Hideki joined #nim |
06:45:19 | narimiran | yeah, that one is better :) |
06:45:42 | * | Hideki is now known as Guest16626 |
06:45:54 | voltist | This could just be a case of me missreading and typing it in wrong, but I haven't been able to find any mistakes yet |
06:46:24 | * | Guest16626 quit (Remote host closed the connection) |
06:46:47 | narimiran | my calculator gives the same value as nim |
06:47:15 | voltist | Weird |
06:47:53 | narimiran | for first case |
06:49:08 | narimiran | for the second one i get waaaay different result |
06:49:24 | Yardanico | because it should be + and not |
06:49:24 | narimiran | oh no wait |
06:49:25 | Yardanico | - |
06:49:33 | narimiran | no, my parentheses were wrong |
06:49:37 | Yardanico | ah wait nvm |
06:49:42 | narimiran | the same result in both cases |
06:50:08 | narimiran | voltist: are you sure that your article didn't use lower-precision floats so the article is wrong(er)? |
06:50:30 | voltist | I doubt it |
06:50:46 | voltist | More likely they just haven't labelled things right |
06:52:41 | voltist | I'm comparing it to the red line (m subscript infinity) on the top left chart on here: https://ndownloader.figshare.com/files/15665561/preview/15665561/preview.jpg |
06:59:29 | * | sagax joined #nim |
07:01:06 | PMunch | Where do you get ka and vh from? |
07:01:17 | * | brainproxy joined #nim |
07:03:43 | * | idf joined #nim |
07:04:14 | voltist | https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0218738 -> supplementary information -> second document |
07:05:54 | voltist | Top section |
07:06:04 | voltist | First section* |
07:06:06 | voltist | SHL1 |
07:06:28 | voltist | The figure I get is pretty whacky: https://liamsc.com/figure.png |
07:07:35 | PMunch | Aren't their voltages measured in mV though? |
07:07:47 | PMunch | According to the label on the graph |
07:08:31 | voltist | Yep |
07:08:53 | voltist | But I'm working entirely in mV so it shouldn't matter |
07:09:19 | * | Vladar joined #nim |
07:10:17 | * | chemist69 quit (Ping timeout: 260 seconds) |
07:10:47 | * | chemist69 joined #nim |
07:10:54 | PMunch | I still don't see where you get ka and vh from.. |
07:12:07 | voltist | ka is k subscript a |
07:12:18 | PMunch | Ah, nvh found the document you were talking about |
07:12:26 | voltist | And VH is "V subscript 0.5" |
07:12:28 | voltist | Yeah |
07:15:27 | PMunch | What is vh.. It's given as 11.2 (-6.8) which is weird.. |
07:15:32 | * | jwm224 quit (Ping timeout: 260 seconds) |
07:17:19 | * | jwm224 joined #nim |
07:22:40 | voltist | Thats the variation I cover in the snippet on nim playground |
07:22:55 | voltist | Either way, it produces weird results |
07:23:37 | PMunch | Yes, I can't get it to give anything close to that table.. |
07:23:59 | FromDiscord | <Rika> is that calculated or empirical :thonk: |
07:24:57 | voltist | What could be calculated or empirical? |
07:26:07 | FromDiscord | <Rika> no clue, its been a few weeks since ive read a published work |
07:36:09 | voltist | Yeah this is really weird |
07:36:15 | * | hoijui quit (Ping timeout: 256 seconds) |
07:36:40 | voltist | It seems the equation and parameters they gave don't at all describe what they show |
07:44:06 | * | Hideki joined #nim |
07:44:30 | * | Hideki is now known as Guest53364 |
07:45:09 | dadada__ | is there any standard way to catch stuff that is going to stdout in a variable instead |
07:45:18 | dadada__ | like a macro stdoutTo var: |
07:45:49 | dadada__ | writing unit tests currently, and it could be useful there |
07:46:35 | * | Guest53364 quit (Remote host closed the connection) |
07:49:35 | FromGitter | <Vindaar> @voltist: it really doesn't make any sense. It can't be `1 / (1 - e^-x)`, because that as a singularity at 0, which their function obviously doesn't have. I'd be pretty surprised if they had such a typo in it, but the function they plot is `1 / (1 + e^-x)`(in contrast to h_inf which is `1 / (1 + e^x)`). |
07:50:35 | FromGitter | <Vindaar> but maybe I'm just still too tired and can't think properly... :) |
07:50:59 | FromDiscord | <Yardanico> @dadada__ I don't think so, although I guess you could shadow echo and/or `stdout` in your macro/template |
07:52:34 | voltist | @Vindaar It is very weird |
07:58:09 | FromGitter | <Vindaar> in addition they talk about "boltzmann-like functions". To be honest, I don't know the term boltzmann function for something like this. But googling brings up a boltzmann sigmoid: https://www.graphpad.com/guides/prism/7/curve-fitting/reg_classic_boltzmann.htm and that's also what I said above |
07:59:50 | voltist | So you think they accidentally swapped one of the symbols around? |
08:00:06 | FromGitter | <eagledot> Could somebody be please able to look at this . |
08:00:07 | voltist | Also thanks for the link |
08:00:18 | FromGitter | <eagledot> https://play.nim-lang.org/#ix=2kYM |
08:01:46 | FromGitter | <eagledot> It is crashing with default gc used and giving different results with arc.Only works everytime if i donot use any gc. ⏎ I posted this yesterday also.I am stuck on this donot know what am i doing wrong or is it NIM bug. |
08:01:55 | FromGitter | <Vindaar> @voltist: I have no idea. I've seen all sorts of craziness in papers, but something so obvious in so many different places seems fishy. I'd have to properly read what they're writing. Can take a look later. Gotta be in a meeting now |
08:03:07 | voltist | @Vindaar Ok, cya round |
08:03:57 | * | avatarfighter quit (Ping timeout: 260 seconds) |
08:06:32 | * | fredrikhr joined #nim |
08:30:39 | * | ftsf quit (Ping timeout: 256 seconds) |
08:31:27 | * | D_ quit (Ping timeout: 240 seconds) |
08:35:02 | * | D_ joined #nim |
08:44:37 | * | Hideki joined #nim |
08:45:02 | * | Hideki is now known as Guest82747 |
08:48:45 | voltist | @Vindaar Hmmm, putting their values into that general Boltzmann sigmoid doesn't work either. Unfortunately they haven't published the code for their simulation, so we can't check that |
08:54:42 | FromGitter | <Vindaar> this is what I get for different ka: |
08:54:44 | FromGitter | <Vindaar> (https://files.gitter.im/nim-lang/Nim/3JOq/activation.png) |
08:55:15 | FromGitter | <Vindaar> V_h is just the position at which m_inf = 0.5 |
08:55:58 | PMunch | @eagledot, where does it crash? |
08:56:05 | PMunch | Do you get any stack trace? |
08:56:52 | PMunch | Can you share the test4.wav file so we can try the code? |
08:56:57 | PMunch | Is this a minimal sample? |
08:57:08 | voltist | @Vindaar That seems reasonable |
08:58:14 | voltist | As you say, the consistently contradictory equation in the paper is strange |
08:58:49 | FromGitter | <Vindaar> @voltist: code I used: https://play.nim-lang.org/#ix=2kYZ |
08:59:15 | * | Guest82747 quit (Ping timeout: 260 seconds) |
09:01:12 | FromGitter | <Vindaar> would be interesting to extract data points from the plot they show, fit this function and see what the resulting fit parameters would be for vh, ka |
09:01:34 | voltist | Yeah |
09:02:32 | FromGitter | <eagledot> it just says out of memory with default |
09:02:44 | FromGitter | <eagledot> https://gitlab.com/eagledot/webrtcvad-nim ⏎ Everything is in there |
09:03:29 | voltist | I might contact the authors and inquire about the apparent mistake |
09:03:40 | voltist | Once I'm sure that we aren't just missing something |
09:03:42 | * | krux02 joined #nim |
09:04:51 | dom96 | yumaikas, yeah, global with threadvar if you want to use threads |
09:05:28 | * | hoijui joined #nim |
09:06:15 | PMunch | Not sure how the Nim GC handles stuff like this: https://gitlab.com/eagledot/webrtcvad-nim/-/blob/master/webrtcvad_nim.nim#L100 |
09:07:27 | FromGitter | <eagledot> what do you mean?? ⏎ How should i change it?? |
09:07:50 | PMunch | And does new even work with regular object types? I thought that was supposed to only work for ref types.. |
09:08:24 | Yardanico | !eval type A = object; echo typeof(new(A)) |
09:08:25 | FromDiscord | <Recruit_main707> it doesnt, does it? |
09:08:27 | NimBot | ref A |
09:08:34 | Yardanico | it creates a reference to an object |
09:08:54 | PMunch | Huh, so it creates it on the heap and gives you a reference when you do that? |
09:08:56 | PMunch | Didn't know |
09:09:05 | Yardanico | neither did I, but I really don't use new() |
09:09:19 | PMunch | But what he does, casts it to a ptr and returns that ptr, that doesn't work right? |
09:09:29 | Yardanico | yeah I don't think that it's correct |
09:09:33 | PMunch | Or it works, but it would trip up the GC |
09:09:46 | voltist | @Vindaar It's also strange that the V0.5 of their plots seems very different from their parameters |
09:09:48 | Yardanico | right now I'm trying to hack the copied jsgen backend to output processed nim AST as Nim code :P |
09:10:08 | FromDiscord | <Recruit_main707> !eval type A = object; var a: A = A(); echo(typeof(a)) |
09:10:11 | NimBot | A |
09:10:15 | Yardanico | yeah that's not a reference |
09:10:21 | PMunch | eagledot, basically what you want to do is to return simply a vadObj or a ref vadObj and then use .addr to get a pointer that you can pass to the C stuff |
09:10:21 | FromDiscord | <Recruit_main707> i know :p |
09:11:04 | PMunch | (And may I suggest reading the NEP1? This code is a bid hard to read) |
09:12:40 | FromGitter | <eagledot> Ok:) ⏎ Will try that. ⏎ I am a newbie just trying to make it work:) |
09:17:22 | FromGitter | <eagledot> Can u confirm that was the only error.Could u run it? |
09:17:33 | PMunch | Sorry, I haven't tried it |
09:21:48 | PMunch | Okay, did the changes and tested it. Seems to run, but not sure if it does what it is supposed to do :P |
09:23:07 | * | covidian is now known as ii |
09:23:08 | * | ii is now known as covidian |
09:24:17 | PMunch | eagledot: http://ix.io/2kZ9 |
09:26:10 | FromGitter | <eagledot> I think it is working:) ⏎ was Stuck on it for two days. ⏎ Seems like `new ` was not a great idea? |
09:27:44 | PMunch | Well, the problem here is that you create a garbage collected object (new(vadObj)) then just get a pointer to that and leave the reference behind. So the garbage collector comes around, sees that no-one is referring to the object, and cleans it up. |
09:27:46 | PMunch | More or less |
09:30:07 | FromGitter | <eagledot> I get it...but i think i tried first using reference as a pointer on a sample code .Seemed to work that's why i used ,didnot know it would trip the gc so bad!! |
09:31:02 | dadada__ | Error: unhandled exception: sempass2.nim(396, 19) `b[j].kind == nkType` [AssertionError] |
09:31:10 | dadada__ | potential compiler bug` |
09:31:11 | dadada__ | ? |
09:31:30 | dom96 | any assertion failure in the compiler is a bug |
09:31:48 | FromGitter | <eagledot> But i understand now that i returned only the pointer disturbing the normal way. |
09:33:25 | PMunch | eagledot, the reference object isn't really the issue: http://ix.io/2kZc |
09:33:30 | PMunch | As you can see that also works fine |
09:33:53 | PMunch | But just discarding the reference object in favour of a ptr to the object doesn't work |
09:33:59 | PMunch | Because Nim now thinks you're not using it |
09:34:06 | * | Trustable joined #nim |
09:34:06 | FromDiscord | <Recruit_main707> dadada: i think its not, i remember something about this, i feel its how macros should work, but its not, this is how i do it: https://play.nim-lang.org/#ix=2kZd maybe its the same case as yours |
09:34:52 | Yardanico | modifying the AST in macros usually is not good |
09:35:02 | Yardanico | it's much better/safer to create new AST nodes in macros and returns these instead |
09:35:13 | Yardanico | i mean modifying the AST you got as arguments |
09:35:14 | FromGitter | <eagledot> Yes i understand more clearly now. Thanks:) |
09:35:23 | dadada__ | Recruit_main707: did you really mean me? |
09:36:02 | PMunch | You could also use the system/ansi_c module to use malloc directly, and then free it yourself manually later on. But of course then you're back to C style manual memory management |
09:37:09 | FromGitter | <eagledot> Yes I used malloc when i couldnot figure out. ⏎ If i create something in a function and doesnot return it then it means gc can collect that ? |
09:37:15 | FromDiscord | <Recruit_main707> yes, node kinds sometimes dont match ehst you would intuitively think |
09:37:29 | PMunch | eagledot, yes |
09:39:00 | PMunch | Of course if they are created on the stack they will be automatically cleaned up when the stack frame pops. If they are on the heap then the references will go out of scope when the stack frame pops and the GC will be able to free them. |
09:39:14 | PMunch | This might help a bit: https://peterme.net/nim-types-originally-a-reddit-reply.html |
09:39:26 | * | covidian left #nim ("don’t bother even trying") |
09:42:41 | FromGitter | <eagledot> OK.Yes. ⏎ I saw your talk . ⏎ Then read it. ⏎ I understand a quite bit about stacks and heaps...but i this case i was in doubt that gc will not free this and takes care even if i am casting..Well i was wrong:) [https://gitter.im/nim-lang/Nim?at=5eb28690f0377f16316d6a8b] |
09:44:01 | FromGitter | <eagledot> I was hoping more from the talks for running nim from microcontrollers and IOt..but nonetheless enjoyed it. |
09:44:25 | FromGitter | <eagledot> on* |
09:45:38 | PMunch | I want to do more on the topic |
09:45:54 | PMunch | But it's a bit limited how much fun you can go through during a 20 minute talk |
09:47:26 | FromGitter | <eagledot> Well,if you have more resources for running nim on microcontrollers or can let me know if develop more on this topic.Please let me know. ⏎ I found nim quite fascinating after knowing enough python and C. |
09:51:56 | PMunch | Not so much in terms of resources unfortunately.. |
09:52:03 | * | mjsir911 quit (Remote host closed the connection) |
09:52:15 | PMunch | But that's just because I haven't found the time to write all of it down yet :P |
09:52:20 | * | mjsir911 joined #nim |
09:57:32 | * | Hideki joined #nim |
09:57:54 | * | Hideki is now known as Guest99522 |
10:03:28 | FromDiscord | <EdgyNerd> what's the best garbage collector if I want more performance and don't really care about memory usage (as long as there isn't any leaks)? |
10:03:37 | FromDiscord | <Recruit_main707> arc |
10:03:46 | FromDiscord | <Recruit_main707> if you use async, orc |
10:03:50 | Yardanico | if you don't have cycles, compare default vs arc |
10:03:55 | Yardanico | if you do, default (refc) vs orc |
10:04:11 | Yardanico | arc is still sometimes slower than the default GC, but it's really better since it's deterministic |
10:05:46 | PMunch | EdgyNerd, the one that performs best when you benchmark you code |
10:06:15 | FromDiscord | <clyybber> @EdgyNerd memory regions :p |
10:06:28 | FromDiscord | <clyybber> Or essentially, arc but use your own refs |
10:07:21 | FromDiscord | <clyybber> If you don't care about memory usage, you can do arena allocation |
10:07:38 | FromDiscord | <clyybber> Useful for games |
10:08:03 | FromDiscord | <clyybber> Since you can just do whatever you want in a frame/tick and only free at the end of the frame/tick |
10:09:30 | FromDiscord | <clyybber> If you simply use objects more and have an updateTick proc, then stack allocation will do fine |
10:09:58 | FromDiscord | <clyybber> arena allocation is a bit like stack allocation but independent from the stack |
10:10:19 | FromDiscord | <clyybber> But you don't need to care about all this, just use arc or boehm or the default gc :) |
10:13:34 | FromDiscord | <EdgyNerd> just tested them all, they're all basically the same (within 0.08 seconds) |
10:13:45 | FromDiscord | <clyybber> \o/ |
10:13:47 | FromDiscord | <EdgyNerd> apart from boehm which is 0.1 seconds slower |
10:13:48 | dom96 | clyybber: what guarantee do you have that the `free` won't take too long? :P |
10:13:59 | dom96 | what you really want is Nim's amazing soft real-time GC |
10:14:47 | Yardanico | @EdgyNerd can you try with -d:boehmNoIntPtr just for fun? |
10:14:52 | FromDiscord | <clyybber> dom96: I don't have any, but a single free at the end of the frame is simpler than a full blown GC |
10:15:10 | * | brainproxy quit (Ping timeout: 260 seconds) |
10:15:18 | FromDiscord | <clyybber> And if you use a simple bump allocator |
10:15:21 | dom96 | clyybber: it'll never be a single free though, you'll always have many different objects to free |
10:15:38 | FromDiscord | <clyybber> dom96: If you use a bump allocator then its a single free |
10:15:48 | FromDiscord | <clyybber> You would free all at once |
10:15:57 | * | liblq-dev joined #nim |
10:16:07 | liblq-dev | does Nim have any limit on a proc's parameter count? |
10:16:09 | dom96 | cool, can we implement that in Nim? |
10:16:21 | FromDiscord | <clyybber> dom96: Sure |
10:16:30 | FromDiscord | <EdgyNerd> -d:boehmNoIntPtr is 1.5 seconds slower |
10:16:37 | FromDiscord | <EdgyNerd> @ Yardanico |
10:16:40 | Yardanico | ah ok |
10:17:29 | Yardanico | liblq-dev: lemme try :P |
10:17:38 | PMunch | liblq-dev, good question. I guess it might depend on the OS? |
10:17:39 | FromDiscord | <mratsim> @EdgyNerd performance depends on the application, if you optimize for throughput it's Boehm or markandsweep, if you optimize for latency it's the default GC |
10:18:14 | liblq-dev | like, the largest amount of params I ever had was 15 which is not that much considering it's really just a constructor |
10:18:19 | FromDiscord | <clyybber> dom96: Actually its pretty much already there: https://github.com/nim-lang/Nim/blob/devel/lib/system/gc_regions.nim |
10:18:26 | FromDiscord | <mratsim> if you now the max memory reserved, just use an Arena |
10:18:51 | dom96 | clyybbeer: ahh yes, I remember that. There was an idea that Araq had to free memory after every request for http servers |
10:18:53 | dom96 | which could work |
10:18:54 | FromDiscord | <Recruit_main707> why do slices use gced memory? |
10:19:13 | FromDiscord | <mratsim> they own their memory |
10:19:24 | FromDiscord | <mratsim> use `toOpenArray` instead (yeah it sucks) |
10:19:43 | FromDiscord | <clyybber> dom96: Yeah, nowadays it is possible to implement it via =destroy hooks in arc |
10:19:57 | FromDiscord | <mratsim> but there are comment in multiple RFCs related to openarray as value types to change slicing to return openarray instead of seq |
10:20:32 | FromDiscord | <Recruit_main707> isnt toOpenArray slow? |
10:20:49 | FromDiscord | <clyybber> no |
10:20:53 | dom96 | mratsim: is zah on holiday? Haven't been able to get in touch with him over gitter |
10:21:06 | FromDiscord | <clyybber> dom96: Try telegram |
10:21:18 | FromDiscord | <clyybber> he was active yesterday I think |
10:21:25 | FromDiscord | <EdgyNerd> also, --gc:regions is 4.5x slower for some reason |
10:21:44 | dom96 | clyybber: don't know his username |
10:21:47 | FromDiscord | <mratsim> toOpenArray is basically moving a pointer + length |
10:22:03 | FromDiscord | <mratsim> He is on the Nim FOSDEM groups 😉 |
10:22:27 | FromDiscord | <clyybber> dom96: I'll ping you on telegram |
10:24:58 | Yardanico | liblq-dev: doesn't seem so |
10:25:32 | Yardanico | well it depends on the C compiler too |
10:25:48 | Yardanico | by the C standard the C compiler should allow for at least 256 arguments iirc |
10:25:59 | Yardanico | https://i.imgur.com/99lTPRt.png |
10:26:05 | * | Guest99522 quit (Remote host closed the connection) |
10:26:09 | PMunch | dom96, he was here yesterday according to the IRC logs |
10:26:23 | PMunch | Oh wait |
10:26:27 | PMunch | Not zah.. |
10:27:03 | Yardanico | the compiled C file loogs amazing |
10:27:05 | Yardanico | looks* https://gist.github.com/Yardanico/1147d47c20d9c47a9df170d5e0c81c70 |
10:27:15 | FromDiscord | <mratsim> 256 arguments seem ... excessive ... |
10:27:18 | FromDiscord | <clyybber> liblq-dev: Why though? |
10:27:35 | liblq-dev | idk, I was asking out of curiosity |
10:27:44 | Yardanico | lemme try to add the 4th letter |
10:27:44 | PMunch | Haha, that looks amazing |
10:27:56 | PMunch | Imagine finding that in some project |
10:28:16 | Yardanico | nim https://gist.github.com/Yardanico/6adb800ca7419a7351ef4fe7ab6e39d4 |
10:28:29 | Yardanico | poor github gave up on trying to highlight the first line |
10:29:36 | Yardanico | I think I went a little overboard |
10:29:44 | Yardanico | the nim source file is 724kb |
10:29:58 | Yardanico | let's see if the compiler crashes or not |
10:30:27 | Yardanico | vscode kinda gives up |
10:30:54 | Yardanico | oh right nim compiler gave up too, it doesn't show the colon number anymore |
10:31:04 | Yardanico | but it still reports if there are keywords, let's see if I can fix them all |
10:31:49 | Yardanico | poor poor vscode |
10:31:50 | * | dddddd joined #nim |
10:31:57 | Yardanico | vscode froze, nice |
10:32:13 | FromDiscord | <kodkuce> hmm i wish micro head plugin for nim 😦 |
10:32:25 | PMunch | Haha, what script are you using to generate these Yardanico? |
10:32:36 | FromDiscord | <Recruit_main707> can we use nim slp w/ visual studio?? |
10:32:43 | FromDiscord | <Recruit_main707> lsp* |
10:32:49 | PMunch | Why not? |
10:33:02 | FromDiscord | <Recruit_main707> its just that i dont know how it works :p |
10:34:02 | FromDiscord | <Recruit_main707> no highlight though 🤔 |
10:35:55 | Yardanico | PMunch: it actually worked 0_0 |
10:36:03 | PMunch | What? |
10:36:05 | Yardanico | both nim compiler and C compiler somehow compiled it |
10:36:10 | Yardanico | lemme count number of arguments |
10:36:13 | PMunch | With all four letter combinations? |
10:36:21 | Yardanico | not all |
10:36:28 | PMunch | I guess the answer is "don't worry about it" |
10:36:48 | Yardanico | 123 thousand |
10:36:50 | Yardanico | XDDDDDDD |
10:37:06 | Yardanico | and nim compiler actually handles that perfectly fne |
10:37:24 | Yardanico | lemme try exportc |
10:37:43 | Yardanico | still works |
10:38:06 | FromDiscord | <Recruit_main707> can you use them though |
10:38:21 | Yardanico | yes |
10:38:25 | FromDiscord | <Recruit_main707> nim op |
10:38:28 | Yardanico | I'm using the random argument and returning it |
10:38:58 | FromDiscord | <Recruit_main707> finally all the people that need to pass 123 thousand arguments to their functions can code |
10:39:27 | PMunch | Haha :P |
10:39:33 | PMunch | Okay that is pretty amazing |
10:39:38 | PMunch | Do you have your script? |
10:39:45 | PMunch | I want to try 5 letters |
10:40:32 | Yardanico | yeah I'll improve it a bit and share |
10:41:02 | Yardanico | but it's inefficient anyway |
10:46:08 | PMunch | 5 letters, the nim source file comes out to 102M |
10:46:19 | PMunch | Compiling.. |
10:46:35 | Yardanico | PMunch: https://play.nim-lang.org/#ix=2kZu |
10:46:46 | Yardanico | seems like collect + newSeqOfCap made it much faster |
10:47:19 | Yardanico | I only use lowercase because case insensitivity ;) |
10:47:40 | PMunch | Well look at you Mr. fancypants :P |
10:47:50 | Yardanico | I get 80mb with all lowercase for 5 letters |
10:47:53 | Yardanico | trying to compile |
10:47:59 | PMunch | This is the script I'm using: http://ix.io/2kZv |
10:48:04 | Yardanico | nim compiler uses 900mb ram |
10:48:12 | Yardanico | 1gb |
10:48:18 | Yardanico | its still growing XD |
10:48:43 | Yardanico | 1.2gb |
10:48:54 | Yardanico | I think at this point the C compiler may fail |
10:49:11 | PMunch | 1882Mb here atm |
10:49:26 | Yardanico | 1.4gb |
10:49:37 | PMunch | 2Gb |
10:49:42 | Yardanico | lol |
10:49:52 | PMunch | I'm going to run out of RAM at this rate.. |
10:50:01 | * | brainproxy joined #nim |
10:50:06 | Yardanico | I have plenty of ram left :P |
10:50:18 | PMunch | This poor machine only have 8Gb |
10:50:23 | PMunch | But I've got 8 more in the mail |
10:50:28 | Yardanico | nice |
10:50:46 | Yardanico | 1.6gb, seems to grow slow |
10:50:57 | PMunch | Yeah.. |
10:51:04 | PMunch | Mine is at 2.3Gb now |
10:51:28 | Yardanico | I couldn't find info on most allowed number of arguments in GCC |
10:51:47 | PMunch | 2.4Gb |
10:51:49 | narimiran | i have no idea what two of you are doing, but it seems like you're having a blast :) |
10:52:05 | PMunch | Haha, we're trying to see how many arguments you can have in a Nim procedure |
10:52:10 | Yardanico | narimiran: compiling a 80mb nim file with a single proc which has A LOT of arguments |
10:52:19 | narimiran | :D |
10:52:21 | Yardanico | yeah my compiler at 1.9gb now |
10:52:21 | PMunch | Currently trying all five letter (lowercase) combinations of arguments |
10:52:28 | PMunch | Mine is 102M |
10:52:38 | PMunch | I wonder why mine is so much bigger.. |
10:52:48 | PMunch | Do you not have spaces between your commas? |
10:52:56 | Yardanico | I have spaces |
10:52:58 | PMunch | 2.7Gb here |
10:53:01 | Yardanico | data.join(", ") |
10:53:02 | FromDiscord | <kodkuce> lol |
10:53:31 | Yardanico | well nim compiler seems flexlible enough |
10:53:37 | Yardanico | PMunch: but did you account for keywords? |
10:53:40 | Yardanico | :D |
10:53:45 | PMunch | Nah, I put them all in `` |
10:53:49 | Yardanico | ah lol |
10:53:50 | Yardanico | that's smart |
10:53:52 | PMunch | ;) |
10:54:00 | * | PMunch taps forehead |
10:54:02 | Yardanico | btw https://github.com/nim-lang/Nim/pull/14241 |
10:54:03 | disbot | ➥ make `from` an operator |
10:54:09 | PMunch | Or temple rather.. |
10:54:39 | PMunch | Can't open that until I'm done |
10:54:43 | Yardanico | xd |
10:54:48 | PMunch | My browser has a few too many tabs open |
10:54:49 | Yardanico | 2.2gb ram now |
10:55:01 | PMunch | Currently at 3Gb |
10:55:05 | Yardanico | wtf |
10:55:14 | Yardanico | will it ever end |
10:55:22 | PMunch | Who knows |
10:55:33 | PMunch | I wonder how far along it is |
10:56:55 | PMunch | brb |
10:58:00 | Yardanico | well it takes 7 secs to compile (including the C step) a 3.5mb file |
10:59:13 | dom96 | hehe, I tried to obfuscate Nim's C code using my obfuscator and it crashed |
11:01:50 | * | lritter joined #nim |
11:02:18 | FromDiscord | <Recruit_main707> its already pretty obfuscated |
11:02:21 | FromDiscord | <Recruit_main707> :P |
11:04:12 | Yardanico | well not really |
11:04:19 | Yardanico | if you compile --gc:arc -d:danger it'll be pretty clean |
11:04:27 | PMunch | Damn it.. |
11:05:31 | Yardanico | https://github.com/nim-lang/Nim/commit/b8e6ea7547344389b5e45c3af249fee9642f028e nice |
11:05:44 | Yardanico | bit slices |
11:06:08 | PMunch | When I generated the file I ran it with `nim c -r test > outp.nim` |
11:06:16 | Yardanico | PMunch: yeah I did that at first too |
11:06:34 | PMunch | And Nim sometimes outputs the CC: test.nim line into the file when you do that.. |
11:06:38 | PMunch | Not always, but sometimes |
11:06:45 | Yardanico | hahaha I understand |
11:06:49 | PMunch | But it had in this case, and it crashed.. |
11:06:53 | Yardanico | rip |
11:07:20 | Yardanico | my PC crashed because I launched the second one with 20mb nim file but for some reason my RAM usage spiked to 100% and OOM doesn't work well on Linux :P |
11:07:29 | Yardanico | OOM killer* |
11:07:54 | * | abm joined #nim |
11:08:59 | * | dadada__ quit (Ping timeout: 260 seconds) |
11:10:31 | PMunch | Hahaha |
11:10:47 | PMunch | Mine is getting back up there, currently at 2.3Gb memory |
11:10:48 | * | dadada joined #nim |
11:11:12 | * | dadada is now known as Guest45332 |
11:18:07 | PMunch | 3.4Gb |
11:18:12 | FromDiscord | <Recruit_main707> PMunch, can you help me setting up lsp for vs? |
11:18:17 | PMunch | Sure |
11:18:18 | FromDiscord | <Recruit_main707> i case you know that is |
11:18:30 | PMunch | Huh? |
11:18:47 | FromDiscord | <Recruit_main707> i was not sure if you knew how to do it in vs |
11:18:50 | PMunch | Just let me grab some lunch first, I'm getting quite hungry |
11:18:56 | FromGitter | <sealmove> Hey, I have a seq[byte] and I want to be able to read various integer lengths. Currently I do this: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ But it's most likely inefficient. How do I involve casts correctly? [https://gitter.im/nim-lang/Nim?at=5eb29d200b23797ec065c96c] |
11:19:56 | FromGitter | <sealmove> My type being: ⏎ ⏎ ``` BitStream = ref object ⏎ data: seq[byte] ⏎ pos: int``` [https://gitter.im/nim-lang/Nim?at=5eb29d5c3d58de7a38f9aa61] |
11:22:52 | PMunch | Holy moly! It jubped to 7.3G |
11:23:01 | Yardanico | PMunch: yeah probably that's why my PC died |
11:23:21 | federico3 | Yardanico: try oomd |
11:23:28 | PMunch | 11.1G virtual.. |
11:23:35 | Yardanico | well virtual is virtual |
11:23:42 | Yardanico | apps can use 20TB of virtual memory with no problem |
11:23:43 | PMunch | At this rate it'll fill my swap as well.. |
11:25:38 | * | brainproxy quit (Ping timeout: 260 seconds) |
11:26:56 | PMunch | It's gone down to 7.1Gb now |
11:27:07 | Yardanico | inb4 C compiler segfaults |
11:27:27 | PMunch | Haha yeah |
11:27:50 | * | Hideki joined #nim |
11:28:13 | * | Hideki is now known as Guest99814 |
11:29:47 | Yardanico | "Error: internal error: environment misses: mixNumOpened" huh |
11:29:57 | Yardanico | guess a yet another arc-related bug, need to investigate more :P |
11:31:51 | Yardanico | yeah nice I reproduced it |
11:31:53 | Yardanico | :DD |
11:32:15 | PMunch | Hmm, now it's just chilling at 15% CPU but at 7Gb memory consumption.. |
11:32:57 | PMunch | And the file in cache isn't growing, so it doesn't appear to do io |
11:35:29 | PMunch | @Recruit_main707, you wanted help setting up nimlsp? |
11:36:53 | FromDiscord | <Recruit_main707> ye, i asked it in offtopic so that i dont fill this channel with dumb questions |
11:38:29 | PMunch | Ah you, pinged me with the wrong name :P |
11:39:16 | * | Guest99814 quit (Ping timeout: 256 seconds) |
11:42:21 | * | gangstacat quit (Ping timeout: 244 seconds) |
11:43:13 | PMunch | Hmm, the compiler just quit with error code 137 |
11:43:17 | PMunch | No explanation.. |
11:44:07 | Yardanico | that's SIGKILL |
11:44:13 | PMunch | If anyone with some spare RAM wants to give it a go: http://ix.io/2kZJ |
11:44:17 | Yardanico | probably OOM killed it |
11:44:20 | Yardanico | OOM killer* |
11:44:35 | PMunch | Yeah I'm guessing so |
11:46:56 | * | hoijui quit (Quit: Leaving) |
11:55:36 | FromDiscord | <kodkuce> i have 16gb can test if want |
11:56:00 | FromDiscord | <kodkuce> just giv me script |
11:56:56 | FromDiscord | <kodkuce> tough free gives me Mem: 13Gi 676Mi 11Gi 51Mi 1.1Gi 12Gi duno why it reports 13 insted 16 |
11:57:05 | * | brainproxy joined #nim |
11:57:31 | PMunch | kodkuce http://ix.io/2kZJ |
11:57:43 | PMunch | Compile that, and run it with output to another Nim file |
11:57:47 | PMunch | Then compile and run that Nim file |
12:00:19 | FromDiscord | <kodkuce> nim c >> tada.txt ? |
12:00:24 | FromDiscord | <kodkuce> any flags or just this |
12:00:46 | FromDiscord | <kodkuce> flags/args arc danger ... ? |
12:01:42 | FromDiscord | <kodkuce> with run? |
12:03:14 | FromDiscord | <kodkuce> nim c -r > report.txt |
12:03:19 | FromDiscord | <kodkuce> ok will run it like this |
12:03:52 | FromDiscord | <kodkuce> hmm it finished wtf |
12:03:58 | Yardanico | that's just creating the file |
12:04:05 | Yardanico | now you need to "nim c -r report.txt" |
12:04:36 | FromDiscord | <kodkuce> to run it or to ouput it again to somwere? |
12:04:59 | * | PMunch quit (Ping timeout: 260 seconds) |
12:05:04 | FromDiscord | <kodkuce> i change it to report.nim cuz beh |
12:05:06 | FromDiscord | <kodkuce> anyway |
12:05:29 | FromDiscord | <kodkuce> ok will run it now |
12:06:01 | * | supakeen quit (Quit: WeeChat 1.9.1) |
12:06:45 | * | supakeen joined #nim |
12:06:50 | FromDiscord | <kodkuce> its running duno if i should have used > so terminal output does not slowdown |
12:06:59 | FromDiscord | <kodkuce> anyway atm 800mbs |
12:10:56 | * | PMunch joined #nim |
12:11:12 | FromDiscord | <kodkuce> is there some multythread option fo compiling |
12:11:28 | FromDiscord | <kodkuce> my cpu usage only 14% and i have broswer opend |
12:11:52 | PMunch | --parallelBuild |
12:12:02 | PMunch | With a number of processors |
12:12:10 | PMunch | But it default to 0 which is auto-detect |
12:12:21 | FromDiscord | <kodkuce> oh , duno if should restart now just reached 1.7 GB |
12:12:35 | * | rockcavera joined #nim |
12:12:37 | Yardanico | PMunch: that won't help |
12:12:43 | Yardanico | nim compiler itself is single-threaded |
12:12:55 | PMunch | Oh, that is only for passing to the C compiler? |
12:13:16 | FromDiscord | <kodkuce> nim compile time sux 😄 |
12:13:33 | Yardanico | PMunch: yeah |
12:13:52 | FromDiscord | <kodkuce> ok i go cook something to eat |
12:14:23 | Yardanico | be careful |
12:14:32 | Yardanico | you might hit 100% ram usage |
12:16:36 | FromDiscord | <mratsim> The nim compiler speed is OK though, much faster than C++ or Rust |
12:17:19 | FromDiscord | <mratsim> The slow things are generics, especially recursive (but they are still OK), and concepts |
12:18:58 | dom96 | what about macros? Anyone did any benchmarks? |
12:19:46 | * | Trustable quit (Remote host closed the connection) |
12:20:22 | FromDiscord | <mratsim> I didn't but macro that don't involve types (getTypeInst in particular) are fast |
12:20:41 | Araq | dom96: IME macros are fine, the VM is good. but of course you can run arbitrarily complex code inside a macro |
12:20:50 | FromDiscord | <mratsim> the main issue with macros is that they tend to make nimsuggest run to 100%CPU ... |
12:21:03 | FromDiscord | <kodkuce> 2.4 GB 😦 |
12:21:22 | * | PMunch quit (Ping timeout: 246 seconds) |
12:21:48 | FromDiscord | <mratsim> Arraymancer needed 3GB of RAM to compile with the whole suite in 0.20 after adding complex supports, now it's back to 1.2GB iirc on 1.2 |
12:22:16 | FromDiscord | <kodkuce> anyway Nim has incremental compiler right so its not issue like in C++ where you w8 forewer |
12:22:27 | FromDiscord | <mratsim> it's not implemented |
12:22:34 | FromDiscord | <kodkuce> oh 😦 |
12:22:36 | FromDiscord | <clyybber> @kodkuce Not yet |
12:22:40 | FromDiscord | <clyybber> But we are still faster :p |
12:22:46 | FromDiscord | <mratsim> way faster |
12:23:02 | dom96 | we should really write an article explaining this |
12:23:06 | FromDiscord | <clyybber> @kodkuce So no, nim compiler is not slow, but your generated code is crazy :) |
12:23:21 | FromDiscord | <clyybber> of course slow is subjective, so.. |
12:23:25 | dom96 | most people assume that since we have two compilers effectively that we have the slowness of C++ and whatever speed Nim has |
12:23:37 | dom96 | but I assume that we actually generate C++ that compiles quickly |
12:23:49 | FromDiscord | <mratsim> I'm surprised someone managed to generate code crazier than zero-functional, npegs or the macro I have in Arraymancer/Laser |
12:24:00 | FromDiscord | <kodkuce> i know this is crazy test i did not have any copiler slownest issue at least for my simple stuff, duno how would it be on big project |
12:24:15 | FromDiscord | <kodkuce> anyway hope incremental will be a thing 1 day |
12:24:47 | FromDiscord | <kodkuce> it really sux week ago i compiled godot head to w8 20 mins |
12:24:48 | Yardanico | @mratsim nim-regex macro is also pretty "interesting" :P |
12:25:02 | FromDiscord | <mratsim> I hope the compiler doesn't try to recompile files added via {.compile: "foo.c".} over and over. That's one thing that is slow |
12:25:04 | Yardanico | @kodkuce enough with jokes :P |
12:26:11 | FromDiscord | <kodkuce> 2.7gb |
12:28:35 | * | monokrom joined #nim |
12:30:17 | Araq | mratsim: it doesn't do that, it uses checksums on the .c files to see if they changed |
12:30:39 | Araq | however, it puts the object files into nimcache/ and nimcache is project specific |
12:32:37 | * | brainproxy quit (Ping timeout: 264 seconds) |
12:33:29 | shashlick | Araq how about compiling Nim stdlib files in a global namespace, that way those are only recompiled occasionally |
12:34:04 | FromDiscord | <clyybber> shashlick: But we also have dead code elminiation |
12:34:14 | FromDiscord | <clyybber> The generated C files aren't the same most of the time |
12:34:19 | Araq | shashlick: the stdlib is one thing, external .c files another |
12:34:39 | Araq | there is no reason why we don't use nimcache/external for all external .c files |
12:34:45 | * | PMunch joined #nim |
12:35:18 | shashlick | Ah dead code |
12:37:31 | Araq | dead code and also generics, use a fresh Table and see tables.nim.c grow :P |
12:38:12 | shashlick | Thinking about https://github.com/nimterop/nimterop/issues/205 |
12:38:13 | disbot | ➥ using zig to generate cross platform wrappers |
12:39:00 | * | thomasross joined #nim |
12:39:59 | Araq | shashlick: why not instead copy "zig"'s idea, use clang to parse the C(++) code |
12:40:14 | Araq | (it's not like nobody else had this idea before...) |
12:40:54 | shashlick | The clang ast? |
12:41:28 | FromDiscord | <kodkuce> wtf it stoped before it reached full mem |
12:41:32 | FromDiscord | <kodkuce> Hint: report [Processing] |
12:41:32 | FromDiscord | <kodkuce> /home/me/Downloads/NimTest/report.nim(1, 1) Error: undeclared identifier: 'CC' |
12:41:44 | Yardanico | yes |
12:41:52 | Yardanico | because your file contained output from nim itself too |
12:42:15 | FromDiscord | <kodkuce> hmm what what |
12:42:44 | * | PMunch quit (Ping timeout: 256 seconds) |
12:42:50 | FromDiscord | <kodkuce> did i do something wronk? |
12:42:57 | Yardanico | kinda |
12:44:40 | * | lritter quit (Quit: Leaving) |
12:46:56 | FromDiscord | <clyybber> Yardanico: Yay, my fix works for the return case too now :D |
12:47:01 | Yardanico | nice :) |
12:47:12 | Yardanico | I'm in the process of minimizing another crash with --gc;arc (ICE in the compiler) |
12:50:18 | * | lritter joined #nim |
12:52:09 | Yardanico | ok done :P |
12:55:45 | * | PMunch joined #nim |
12:58:36 | Yardanico | hmm |
12:59:08 | FromDiscord | <clyybber> oh nice :D |
12:59:35 | Yardanico | actually it might be not a bug, but just a fact that destructors don't support -d:nimOldCaseObjects or something |
13:00:03 | FromDiscord | <kodkuce> so hmm |
13:00:13 | FromDiscord | <kodkuce> should i rerun or what |
13:00:20 | FromDiscord | <kodkuce> if you need me still |
13:00:51 | Yardanico | https://github.com/nim-lang/Nim/issues/14244 not sure if this is supposed to compile at all |
13:00:54 | disbot | ➥ [ARC] ICE when changing the discriminant of a return value ; snippet at 12https://play.nim-lang.org/#ix=2l06 |
13:01:07 | Yardanico | I wasn't able to make an example without object variants |
13:01:19 | Yardanico | I mean it fails at runtime with default GC and asks to add -d:nimOldCaseObjects |
13:04:03 | * | sunwukong joined #nim |
13:07:58 | * | zacharyc1rter joined #nim |
13:07:58 | * | zacharycarter joined #nim |
13:08:38 | * | hoijui joined #nim |
13:13:16 | * | brainproxy joined #nim |
13:14:56 | dom96 | shashlick, I don't get it, what does Zig buy here? |
13:14:58 | * | hoijui quit (Ping timeout: 272 seconds) |
13:15:08 | zacharyc1rter | ooo Zig talk |
13:15:36 | Yardanico | dom96: I think it's about using zig to cross-compile the libraries themselves |
13:15:46 | Yardanico | ah no |
13:15:52 | Yardanico | I didn't understand |
13:16:37 | shashlick | So nimterop relies on the build tools and preprocessor doing their thing and cleaning up the headers |
13:16:43 | Araq | and then what, this is all so stupid. so yeah, here is a Windows binary for you that I built on my Linux machine. Does it work for you? - Nope, it crashes, now what? - Oh, I think I don't support Windows then, sorry |
13:17:13 | shashlick | See https://github.com/nimterop/nimterop/blob/master/README.md#why-nimterop |
13:17:22 | Araq | and that my friends is the new hot shit in 2020 when you can setup a CI to build and test (!) on every major OS |
13:17:42 | shashlick | His idea is to use zig so that it can be done across many platforms |
13:18:25 | disruptek | honestly, i would rather leverage as much outside tech as possible. |
13:18:36 | Yardanico | good morning disruptek |
13:18:38 | Araq | his "idea" amounts to spam. |
13:18:40 | disruptek | parsing C++ is not a competitive advantage. |
13:18:54 | shashlick | It still doesn't address the fact that libraries often depend on the presence of other libraries |
13:18:55 | disruptek | howdy, folks. |
13:19:25 | FromGitter | <zacharycarter> I cross compiled from MacOS to Windows but I didn't use zig and the windows binary worked |
13:19:32 | FromGitter | <zacharycarter> so you don't need Zig for this, just a cross compilation toolchain |
13:19:39 | FromGitter | <zacharycarter> I'd rather install that than LLVM and Zig |
13:19:46 | shashlick | And cmake and similar do a lot of package detection as well which will won't be covered |
13:19:47 | disruptek | i would rather target zig. |
13:20:11 | Yardanico | @zacharycarter well the point with zig is that it's all already precompiled with static binaries for you |
13:20:13 | Yardanico | just easier to use |
13:20:24 | FromGitter | <zacharycarter> is it? |
13:20:25 | Yardanico | so you don't have to install llvm separately and whatnot |
13:20:28 | Yardanico | yes |
13:20:32 | Yardanico | you download a single archive |
13:20:40 | disruptek | why not have a whole community of developers implement and support our backend? |
13:20:44 | FromGitter | <zacharycarter> yeah but then I have to learn how to use Zig |
13:20:50 | Yardanico | ? |
13:20:55 | Yardanico | wdmy |
13:20:57 | Yardanico | wdym* |
13:21:06 | Yardanico | "zig cc" acts *almost* like clang |
13:21:10 | FromGitter | <zacharycarter> if I just download a Zig binary I still have no idea of it's cl interface |
13:21:11 | * | disruptek limps off for coffee. |
13:21:11 | shashlick | It's a convenience factor of being able to run the library thru cmake and the preprocessor on one configuration |
13:22:03 | shashlick | export CC="zig cc" is all that's needed |
13:22:28 | dom96 | bah, of course, because the header files that nimterop generates are OS specific |
13:23:27 | shashlick | They are os, compiler and package specific |
13:24:22 | Araq | disruptek: I'd use c2nim and maybe replace its parser by libclang |
13:24:49 | Araq | nothing else really works and our ecosystem *needs* the quality of hand written wrappers |
13:24:59 | dom96 | Araq: I literally wrote a Uni dissertation which uses libclang in a Nim program |
13:25:28 | Araq | it's just my opinion, of course, but this idea that having 20 fragile wrappers instead of 5 good ones seems madness to me |
13:25:33 | dom96 | I've had my eye on reusing my wrapper to generate C/C++->Nim wrappers. |
13:26:22 | dom96 | I can open source it if someone wants to give it a shot |
13:26:44 | Araq | Yardanico: I don't care about this "almost like", if we support it, me must ensure it keeps working. |
13:27:00 | Araq | and I don't want another factor of 2 for our CI matrix |
13:27:02 | dom96 | `zig cc` is literally a C compiler |
13:27:12 | dom96 | I don't see what is "almost like" about it |
13:27:16 | Araq | yeah, an *unsupported* one. |
13:27:22 | zacharyc1rter | wait but if you change the compiler assembler and linker wouldn't nimterop use those instead? |
13:27:47 | zacharyc1rter | isn't there a way to override and say nimteorp work for this specific os / arch? |
13:28:36 | shashlick | Yes that's my whole point |
13:28:53 | shashlick | I delegate to cmake to discover and configure |
13:29:00 | shashlick | I delegate to the preprocessor |
13:29:13 | zacharyc1rter | so this is specifically a cmake issue? |
13:29:20 | zacharyc1rter | if you're not using nimterop with cmake it doens't matter? |
13:29:51 | shashlick | Nimterop only processes headers after all that is done |
13:30:03 | zacharyc1rter | also you can pass options to CMAKE |
13:30:04 | shashlick | That makes the wrapper platform specific |
13:30:09 | zacharyc1rter | liek `set(CMAKE_SYSTEM_NAME Linux) |
13:30:09 | zacharyc1rter | set(CMAKE_SYSTEM_PROCESSOR arm) |
13:30:15 | shashlick | But I don't see why it makes it fragile |
13:30:18 | Araq | please (and I'm getting mad here), please understand why in the real world Super Mario Brothers 10 doesn't run on FreeBSD. |
13:30:54 | Araq | hint: it's not because the devs cannot setup a cross compiler... |
13:30:57 | dom96 | shashlick that sounds extremely more fragile than a known-to-work wrapper that is committed to git |
13:31:14 | dom96 | if I have to depend on cmake of all things then I really do not have a lot of trust in the software |
13:31:32 | zacharyc1rter | a lot of projects use cmake though |
13:31:33 | Araq | it's because you then need to support the software commercially on an OS no gamer is interested in |
13:31:38 | shashlick | C library authors rely on such tools |
13:31:39 | dom96 | Why can't nimterop generate a wrapper ala c2nim's? |
13:31:56 | dom96 | shashlick there is a reason I avoid building my own libraries with a passion |
13:32:26 | dom96 | and use pre-built binaries whenever I can |
13:32:27 | dom96 | Pretty sure most people are like this |
13:32:28 | Araq | dom96: I don't anymore but I upload my DLLs to github now |
13:32:29 | FromDiscord | <mratsim> C++ libraries are successful despite cmake, not thanks to ... |
13:32:47 | FromDiscord | <clyybber> shashlick: I'm currently trying building nimph and I'm getting this: /home/clyybber/.cache/nim/nimterop/cPlugins/nimterop_790929175.nim(1, 24) Error: cannot open file: nimterop/plugin |
13:32:48 | FromDiscord | <clyybber> [AssertionDefect] [AssertionDefect] |
13:32:54 | FromDiscord | <mratsim> Compiling any C++ library that depends on Cmake requires booking a weekend for that |
13:33:01 | FromDiscord | <mratsim> even popular ones like OpenCV |
13:33:05 | FromDiscord | <clyybber> shashlick: Do I need to compiler plugin too? |
13:33:08 | shashlick | Clyybber that's fixed in head |
13:33:14 | FromDiscord | <clyybber> I am on head |
13:33:18 | FromDiscord | <clyybber> I just git cloned |
13:33:26 | zacharyc1rter | mratsim that's not true, come on |
13:33:37 | shashlick | Nimterop head? |
13:33:43 | zacharyc1rter | usually compiling with cmake involves `mkdir .build && cd .build && cmake .. & make |
13:33:49 | FromDiscord | <clyybber> shashlick: Yeah, on the default branch |
13:33:59 | zacharyc1rter | maybe a make install |
13:34:12 | FromDiscord | <clyybber> shashlick: I didn't use nimble build tho |
13:34:17 | FromDiscord | <clyybber> But instead nim c |
13:34:19 | FromDiscord | <clyybber> to compile toast |
13:34:23 | FromDiscord | <clyybber> And that worked fine |
13:34:34 | FromDiscord | <clyybber> Do I also need to compile nimterop/plugin.nim? |
13:34:40 | dom96 | zacharyc1rter: mratsim is completely right |
13:34:45 | zacharyc1rter | C++'s build tool scene is a nightmare in general and CMake isn't that offensive |
13:35:07 | zacharyc1rter | no, he's not... you're bashing CMake when in reality all of the project generators are annoying |
13:35:40 | FromDiscord | <clyybber> generators generating files for other generators is indeed crazy |
13:35:52 | Araq | the only problem with cmake is that generates a makefile. it's like somebody wrote a dependency graph analysis in 1970 and everybody is too scared to simply re-implement it. I did it in Python, was under 100 lines of code |
13:35:53 | FromDiscord | <clyybber> So yeah, at least CMake is simpler than a lot of the other stuff |
13:35:58 | zacharyc1rter | I'm not advocating that CMake is ther ight tool |
13:36:08 | zacharyc1rter | but this is what almost every C++ project generator does |
13:36:14 | zacharyc1rter | premake, cmake GENie, etc... |
13:36:24 | Araq | but at least cmake runs on Windows without cygwin crap |
13:36:33 | zacharyc1rter | CMake is simply the most widely used one |
13:36:35 | FromDiscord | <mratsim> 2 days trying to get OpenCV to compile and link properly |
13:36:36 | FromDiscord | <mratsim> https://cdn.discordapp.com/attachments/371759389889003532/707586616381800499/unknown.png |
13:36:38 | zacharyc1rter | if it was premake you'd all be complaininga bout that |
13:37:20 | FromDiscord | <mratsim> and then 6 months later, CXX11 ABI changes or whatever, I couldn't link with openexr |
13:37:38 | * | gangstacat joined #nim |
13:37:38 | FromDiscord | <clyybber> shashlick: Any idea? |
13:37:51 | zacharyc1rter | well that's C++'s fault |
13:37:59 | shashlick | Sorry laptop crashed and phone is lagging |
13:38:04 | shashlick | Brb |
13:38:39 | Araq | there was literally a single cmake setup that lead me build Z3 |
13:38:39 | FromDiscord | <mratsim> I also lots of issues due to those "findCUDA" "findFFMPEG" etc scripts |
13:38:46 | FromDiscord | <mratsim> it's really awful |
13:38:50 | zacharyc1rter | okay those are annoying I'll give it that |
13:38:55 | zacharyc1rter | the CMake modules |
13:39:10 | Araq | oh yeah, the scripts are much worse than anything I've ever added to koch.nim :P |
13:39:36 | zacharyc1rter | but I still think that you guys are trashing CMake when every other C++ build tool is just as bad |
13:39:45 | zacharyc1rter | and if you want something that makes CMake better use fips |
13:39:49 | Araq | cmake is better than most |
13:39:58 | FromDiscord | <clyybber> make is best, fite |
13:40:43 | shashlick | This is no different than folks complaining about nimble, choosenim or even nim for not solving every scenario perfectly. |
13:41:05 | * | hoffentlichja joined #nim |
13:41:12 | zacharyc1rter | I guess I missed where this all started |
13:41:21 | shashlick | My point is that this is how the C/C ecosystem works today, I just don't see the point in circumventing them and doing it in some nth unsupported way |
13:41:29 | zacharyc1rter | I came in around the point Zig started to be brought up I guess? |
13:42:13 | shashlick | fact of the matter is that every C/C++ project that is cross platform has to deal with discovery |
13:42:45 | shashlick | nim does that discovery for us so we can happily sit and write mostly cross platform code without effort |
13:44:19 | dom96 | zacharyc1rter I didn't interpret it as bashing cmake, I interpreted it as bashing needing to compile any big C project. It's always a nightmare no matter what make you use |
13:44:46 | Araq | shashlick: and nimterop fights Nim's design, but we don't have to discuss it yet again |
13:45:16 | shashlick | i don't think it fights nim's design at all, it is a practical way to make these libraries available to the user base |
13:45:45 | dom96 | The fact is that Nim has been designed to work with DLLs |
13:45:58 | shashlick | even for DLLs, you need a wrapper |
13:46:02 | dom96 | And doing so side-steps the C ecosystem |
13:46:02 | Araq | it's practical for you but the end user experience is bad, ask disruptek |
13:46:05 | dom96 | which is a great thing |
13:46:20 | shashlick | disruptek had problems because he avoids nimble |
13:46:20 | dom96 | so I do not want to bring in a package that will bring that whole ecosystem into my build |
13:46:35 | Araq | shashlick: well we can let him answer |
13:46:44 | FromDiscord | <clyybber> I think you meant me? |
13:46:48 | shashlick | i fixed his bug by discovering nim configuration with nim dump |
13:47:01 | shashlick | clyybber: you on irc? |
13:47:26 | FromDiscord | <clyybber> nope, currently not |
13:47:31 | FromDiscord | <clyybber> are you in offtopic? |
13:47:40 | shashlick | gitter? |
13:47:49 | FromDiscord | <clyybber> yeah, or irc doesn't matter |
13:47:53 | FromDiscord | <clyybber> its bridged |
13:48:16 | shashlick | can you join https://gitter.im/nimterop/Lobby we can see what the issue is without cluttering #nim |
13:48:23 | FromDiscord | <clyybber> sure |
13:48:47 | Araq | Yardanico: https://forum.nim-lang.org/t/6295 how much does it speed the Nim compiler? |
13:48:51 | shashlick | long story short, people have issues all the time and you fix them |
13:48:52 | Araq | *speed up |
13:49:03 | disruptek | it's one thing or another. why not sidestep the issues with a smarter design? |
13:49:10 | Araq | shashlick: the issues are a symptom of an underlying systemic issue |
13:49:21 | disruptek | i'm the most expert user of my software and i have problems with it /ALL THE TIME/. |
13:49:38 | shashlick | that could very well be the case |
13:50:04 | shashlick | in this case, it is a choice to accelerate with leverage instead of reimplementing everything |
13:50:22 | Yardanico | Araq: I didn't test it with the compiler yet - what's the good nim project for the PGO run? compiler itself? |
13:51:28 | Araq | shashlick: I completely agree and I've tried to outline the way to a good nimterop |
13:51:47 | shashlick | yes and it's been a crawl to get there |
13:52:35 | Araq | I'm sorry |
13:52:50 | shashlick | it may never get done or be perfect but that's not my goal, it is to enable quick wrappers when users ask |
13:52:56 | Araq | Yardanico: or compile arraymancer |
13:53:00 | Yardanico | ah right |
13:53:17 | shashlick | maintaining top quality wrappers requires talent and a lot of patience - it is not a glamorous job |
13:53:41 | FromDiscord | <clyybber> Actually it just requires c2nim and some perl to patch it up :p |
13:54:01 | Yardanico | disruptek: stream today or not? |
13:55:22 | Yardanico | I'll try with the compiler itself first just to test |
13:55:57 | shashlick | clyybber: try wrapping large cross platform projects |
13:56:10 | shashlick | you can definitely make a one time wrapper |
13:56:26 | disruptek | i stream every day, all day. |
13:56:44 | FromDiscord | <mratsim> https://pldi20.sigplan.org/program/program-pldi-2020 |
13:56:44 | FromDiscord | <mratsim> |
13:56:44 | FromDiscord | <mratsim> Some stuff on MT solver and verified ranges |
13:56:48 | FromDiscord | <mratsim> SMT* |
13:57:34 | shashlick | anyway, the point is not to obsolete c2nim or something, it is to offer choice |
13:57:42 | FromDiscord | <clyybber> shashlick: I am wrapping vulkan |
13:58:08 | shashlick | ultimately I want the user to succeed in his project, not create some wrapping masterpiece |
13:58:09 | FromDiscord | <clyybber> shashlick: Yeah, you are right, but thats also kind of the problem I guess; It wont obsolete c2nim |
13:58:20 | FromDiscord | <clyybber> And for example with awr's cpu package I can't choose |
13:58:28 | shashlick | that never was the goal, c2nim can convert C to nim outright |
13:58:31 | FromDiscord | <clyybber> Or with nimph |
13:58:34 | Araq | shashlick: I don't mind obsoleting c2nim, I'm not married to the software. but the replacement should be better ;-) |
13:58:55 | shashlick | your issues with nimph aren't due to wrapping |
13:59:08 | shashlick | it is since you don't want to use nimble |
13:59:09 | FromDiscord | <clyybber> They are due to nimterop |
13:59:25 | FromDiscord | <clyybber> Because it's too complex IMO |
13:59:32 | Araq | that's simply not true, I don't mind running 'nimble install nimph' and it didn't work for me |
13:59:32 | disruptek | he can't build nimph because of nimble? 🤣 |
13:59:34 | shashlick | again, that's like asking for perfection |
13:59:51 | disruptek | does the bootstrap work or not? |
13:59:52 | Araq | 'nimble install nimph' is a pretty basic command |
14:00:02 | shashlick | it works for me |
14:00:17 | Araq | well I got it to work too, eventually |
14:00:43 | shashlick | but that's cause all the fixes are in #head and not tagged yet |
14:00:55 | Araq | now I cannot use it because 'nim dump' because 10x slower and nimph is too slow now (just kidding, disruptek ) |
14:01:08 | disruptek | do you need a replacement for `bump` that works better for your use-case, shashlick? |
14:01:09 | shashlick | its like asking for zero bugs, as all developers here, i don't see how that should discourage usage altogether |
14:02:07 | Araq | shashlick: we're not asking for zero bugs, we're asking for a development process that makes the bugs easier to spot, rather than hidden in layers beyond our comprehension |
14:02:46 | disruptek | it's not even a code issue, it's an environment issue. |
14:02:53 | disruptek | too many assumptions. |
14:03:44 | Araq | I ask for a bike and rather than giving me a bike with a broken tire, you give me a broken bike factory |
14:05:18 | disruptek | i'm still getting reproducable crashes in compiler code in nimph. |
14:05:29 | Yardanico | ok so with default nim build "time nim c -d:danger --hints:off -w:off --compileOnly tests/tests_cpu.nim" (arraymancer) takes ~3.7-3.8 seconds |
14:05:35 | Yardanico | now gonna build nim with PGO+LTO and try again |
14:05:38 | PMunch | Hmm, what does the "dynlib" pragma actually do? |
14:05:56 | Araq | Yardanico: btw -d:danger --panics:on the new way to get fastest code |
14:06:05 | Yardanico | I know, but we want a fair comparison right? :P |
14:06:18 | Yardanico | I mean I'll use -d:release for the compiler |
14:06:24 | FromDiscord | <mratsim> dynlib is for dynamically linking 😉 |
14:06:29 | disruptek | also, it's compiler code that is compiling system module and running nimscript. |
14:06:36 | Araq | Yardanico: sure, but you can use -d:danger --panics:on for both runs |
14:06:44 | Yardanico | hmm, right |
14:07:01 | Araq | oh er |
14:07:12 | Araq | you don't run the compiler under arc so it doesn't matter, sorry |
14:07:26 | Yardanico | well there's still difference between -d:release and -d:danger I guess |
14:07:27 | disruptek | it's harmless. |
14:07:43 | Araq | why can't we run the Nim compiler under arc? what is everybody doing all day long? discussing silly tool chains? |
14:07:50 | Araq | :P |
14:08:00 | FromDiscord | <clyybber> Araq: Maybe we'll get there today :D |
14:08:07 | FromDiscord | <clyybber> Let me try |
14:08:08 | * | brainproxy quit (Read error: Connection reset by peer) |
14:08:15 | Yardanico | well I opened 3 new arc-related bugs today :P |
14:08:45 | FromDiscord | <mratsim> does createThread works with arc now? |
14:08:54 | disruptek | yes. |
14:08:57 | * | brainproxy joined #nim |
14:09:28 | FromDiscord | <clyybber> Heh, nevermind, still get errors |
14:10:29 | Araq | well you need to fix the move optimizer |
14:11:22 | Yardanico | "SIGSEGV: Illegal storage access. (Attempt to read from nil?)" :D guess I'll build with -d:release after all |
14:11:49 | Yardanico | the compiler seems to either crash or say some gibberish about illformed AST |
14:11:58 | Yardanico | it's gone crazy with lto+pgo+danger |
14:14:40 | Yardanico | maybe PGO optimizes too much stuff? anyway will try with -d:release now |
14:15:08 | disruptek | i guess i need to stream earlier for danny's benefit. |
14:17:40 | dom96 | nim-lang.org should have a "live now" section |
14:17:45 | dom96 | anyone want to implement one? |
14:18:12 | FromDiscord | <clyybber> should it? |
14:19:10 | Araq | Yardanico: gah, that's nasty so PGO breaks the Nim compiler? |
14:19:13 | Yardanico | so with -d:release with lto+pgo tests_cpu from arraymancer takes around 0.2s less to compile :P (--compileOnly), building nim itself takes 0.6s less time |
14:19:24 | Yardanico | Araq: maybe PGO just messed up that one time, with -d:release now it's fine |
14:19:42 | Yardanico | and doing "time ~/testsp/compiler/nim c -d:release --compileOnly -w:off --hints:off compiler/nim.nim" is ~0.5s faster (3.9s vs 4.4s) |
14:19:59 | Araq | wow |
14:20:04 | Araq | that's pretty good |
14:20:31 | Araq | can we store this profiling info somewhere? is it platform agnostic? |
14:21:07 | Yardanico | hmm, I don't really know, need to search or ask someone who knows clang well :P |
14:21:39 | Araq | create a pull request and see if it breaks our builds :P |
14:22:01 | Yardanico | well I'm using clang's LTO+PGO, I don't know if it's available on the CI |
14:22:25 | Araq | the CI uses clang on OSX at least |
14:22:27 | Yardanico | for GCC it seems to be harder since GCC outputs the profiling data in the ~/.cache/nim/project directory |
14:22:36 | Yardanico | and clang just does it in current dir |
14:22:52 | Yardanico | but I'll try |
14:23:38 | Araq | er, sorry, just forget about it, the Nim compiler changes all the time |
14:23:57 | Yardanico | well nightlies maybe can make use of LTO+PGO I guess? |
14:24:04 | Araq | true |
14:25:11 | FromDiscord | <mratsim> still no channels in arc :/ https://github.com/nim-lang/Nim/issues/13936 |
14:25:12 | disbot | ➥ Simple channels with --gc:arc |
14:25:34 | Araq | but wow 3.9s vs 4.4s is quite a speedup. many would heavily refactor the compiler to get that |
14:25:44 | Araq | (myself included) |
14:26:58 | Yardanico | yeah, and especially the fact that I used the profile data the arraymancer tests_cpu, not from building the compiler |
14:27:23 | * | hoijui joined #nim |
14:27:34 | Yardanico | from the * |
14:27:53 | * | tane joined #nim |
14:29:05 | Yardanico | even when building my simple mathexpr lib (the repl example) it takes 60ms less (510ms vs 570ms) |
14:35:18 | * | NatashaOakl joined #nim |
14:37:39 | * | NatashaOakl quit (Client Quit) |
14:48:07 | disruptek | ~stream |
14:48:07 | disbot | stream: 11https://twitch.tv/disruptek (live video/audio) and mumble://uberalles.mumbl.io/ (live voice chat) -- disruptek |
14:48:27 | disruptek | unfunner stuff. |
14:52:16 | * | pydsigner left #nim ("Leaving") |
15:06:20 | stefantalpalaru | Is there any known memory leak involving tables with tuples as keys? Like this one: https://github.com/status-im/nim-beacon-chain/blob/621c2e38a6f073c1c4bb9cf2e6b430796490a6ef/beacon_chain/beacon_node_types.nim#L137 |
15:07:38 | Araq | stefantalpalaru: no |
15:10:32 | * | couven92 joined #nim |
15:14:37 | * | fredrikhr quit (Ping timeout: 264 seconds) |
15:24:18 | dom96 | can we get a wrapper for this? https://microsoft.github.io/microsoft-ui-xaml/ |
15:28:49 | * | letto quit (Read error: Connection reset by peer) |
15:29:33 | Yardanico | Araq: results for compilation time of arraymancer's tests_cpu and compiler with -d:danger and -d:danger + PGO |
15:29:34 | Yardanico | https://gist.github.com/Yardanico/e5ef5130b43f3d4e6f8c308ee910c1c3 |
15:29:59 | Yardanico | 3.64s 4s vs 3.22s 3.27s |
15:31:38 | * | s4mu3lbk joined #nim |
15:36:12 | oz | dom96: just compile to JS and use "React Native for Windows". :> |
15:37:56 | * | sunwukong quit (Quit: Leaving) |
15:37:57 | liblq-dev | does offsetOf return the byte offset of a field in an object? |
15:38:26 | liblq-dev | there's no docs for it in system.nim |
15:38:28 | * | fredrik92 joined #nim |
15:41:47 | * | couven92 quit (Ping timeout: 240 seconds) |
15:53:57 | * | theelous3 joined #nim |
16:08:54 | * | s4mu3lbk quit (Remote host closed the connection) |
16:09:14 | FromGitter | <awr1> hello all |
16:10:22 | Yardanico | github announced github discussions |
16:10:29 | Yardanico | basically forums in the repositories |
16:12:59 | * | s4mu3lbk joined #nim |
16:18:17 | dom96 | nice, so they're finally following their "social" mission |
16:18:36 | Yardanico | example https://github.com/zeit/next.js/discussions |
16:21:47 | dom96 | cool, some pretty awesome features |
16:22:14 | dom96 | Guess we can shut down the Nim forum :P |
16:24:54 | * | brainproxy quit (Quit: WeeChat 2.8) |
16:27:00 | FromGitter | <awr1> now i can finally get rickrolled on github |
16:30:15 | Zevv | how does one enable that? |
16:30:53 | Yardanico | I don't think you can yet |
16:30:57 | Zevv | right |
16:30:58 | Yardanico | but I guess it'll be open beta soon |
16:32:31 | FromGitter | <Conlaoch> Dang it awr1... now I'm gonna have that tune stuck in my head for a couple hours... |
16:33:45 | FromGitter | <awr1> https://github.com/nim-lang/Nim/pull/14247 can someone merge this when it passes CI? thanks |
16:33:46 | disbot | ➥ Fix runnable examples for bitops (should fix CI) |
16:37:42 | narimiran | @awr1 ping me when it is green |
16:39:57 | * | waleee-cl joined #nim |
16:42:02 | FromGitter | <kaushalmodi> For a closed source project, few days back, I compiled it with `--gc:arc` and it compiled fine. Today I get this error: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ It does not give a deeper backtrace. ... [https://gitter.im/nim-lang/Nim?at=5eb2e8da3d58de7a38fab92f] |
16:42:32 | FromGitter | <kaushalmodi> How can I get a report-worthy backtrace? |
16:42:45 | Yardanico | oh yeah I know the error |
16:42:47 | Yardanico | I already reported it |
16:42:55 | Yardanico | lemme give you the issue link |
16:42:58 | FromGitter | <kaushalmodi> The project compiled and compiles fine without `--gc:arc`. |
16:43:00 | * | ptdel joined #nim |
16:43:08 | Yardanico | https://github.com/nim-lang/Nim/issues/14236 |
16:43:10 | Yardanico | that's the one |
16:43:11 | disbot | ➥ [ARC] ICE with static objects ; snippet at 12https://play.nim-lang.org/#ix=2l1f |
16:43:46 | Yardanico | stack trace helps but by a bit, the best way is to always make a short example to reproduce ;) |
16:44:06 | Yardanico | check, maybe you use nim-regex yourself |
16:44:12 | Yardanico | you can workaround it by not using the nfa macro |
16:44:33 | Yardanico | -d:forceRegexAtRuntime for nim-regex |
16:45:41 | * | Trustable joined #nim |
16:50:51 | * | samuelb_ joined #nim |
16:50:52 | * | s4mu3lbk quit (Read error: Connection reset by peer) |
16:51:16 | * | samuelb_ is now known as s4mu3lbk |
17:08:57 | * | ertp07 joined #nim |
17:13:01 | FromGitter | <kaushalmodi> Yardanico: I need the stack trace to understand what part of that huge project is breaking :) |
17:13:16 | FromGitter | <kaushalmodi> Just those 2 lines lead me nowhere |
17:13:28 | FromGitter | <kaushalmodi> *2 lines of those error messages |
17:13:31 | Yardanico | well you'll only be able to get the compiler stacktrace anyway |
17:13:33 | Yardanico | use ./koch temp c |
17:13:39 | Yardanico | or whatever your backend is |
17:14:03 | FromGitter | <kaushalmodi> My project uses cligen and cligen uses regex so probably it's caused by regex |
17:14:14 | Yardanico | try with -d:forceRegexAtRuntime |
17:17:11 | * | fredrik92 is now known as fredrikhr |
17:18:29 | FromDiscord | <queersorceress> is there a way to force the `dynlib` pragma to rely on a dlopen call rather than forcibly linking a library to the resulting binary? |
17:20:14 | FromDiscord | <queersorceress> i'm running into an issue where a third party library wraps the stdlib's db_[mysql|postgres|sqlite] and i only use sqlite, but the binary that gets built is wanting all three libraries to be linkable at run-time |
17:21:03 | FromDiscord | <queersorceress> so i want to short-cut it and while i could probably do some magic with linker scripts and rewriting symbols, i really don't want to do that if an easier solution exists |
17:22:38 | FromDiscord | <Solitude> its already using dlopen |
17:23:26 | FromDiscord | <Solitude> so there is no easy way to conditionally load a library at runtime |
17:23:52 | FromDiscord | <EdgyNerd> I tried using the go garbage collector, but got the error 'could not load: libgo.so', where do I get that file? |
17:23:54 | * | avatarfighter joined #nim |
17:24:28 | Yardanico | @EdgyNerd gccgo |
17:24:30 | Yardanico | you need that |
17:26:02 | * | luis_ joined #nim |
17:30:22 | * | avatarfighter quit (Ping timeout: 260 seconds) |
17:30:27 | FromDiscord | <SolarOmni> Okay so I'm really rusty with Nim and haven't used it in like 2 years, it seems to have changed a bit. But anyway, I can't remember the flags for the compiler and I can't seem to find them in the manual. Can anyone tell me how to use set where the executable is exported to? |
17:30:56 | luis_ | Hi guys, how do I set nimble to generate a windows binary? |
17:31:07 | luis_ | Where do I set the binary type? |
17:31:32 | leorize | SolarOmni: --out:/path/to/where/you/want |
17:31:33 | Yardanico | luis_: nim uses the c compiler, so you need to have a cross-compiler from your platform to windows |
17:31:48 | FromDiscord | <SolarOmni> Thanks leorize |
17:32:31 | zacharyc1rter | just use Zig |
17:32:41 | Yardanico | ^^^ |
17:32:50 | Yardanico | use zig to cross-compile nim for windows |
17:32:52 | Yardanico | ez |
17:33:08 | FromDiscord | <EdgyNerd> I installed gccgo and it still doesn't work for some reason |
17:33:19 | FromGitter | <kaushalmodi> Yardanico: After I using that define to enable regex at runtime, I see: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5eb2f4df9f0c955d7daa2985] |
17:33:30 | Yardanico | nice |
17:33:37 | Yardanico | now minify it and create a bug report ;) |
17:33:44 | Yardanico | oh its glob\ |
17:33:47 | FromGitter | <kaushalmodi> yeah |
17:33:48 | Yardanico | hmmm |
17:33:55 | Yardanico | https://github.com/citycide/glob ? |
17:34:01 | FromGitter | <kaushalmodi> yes |
17:34:37 | FromGitter | <kaushalmodi> I will see if can reproduce that error in a minimal example |
17:35:15 | FromGitter | <kaushalmodi> but that error is different from that earlier "unhandled exception: ccgexprs.nim(777, 11) `ty.kind in {tyTuple, tyObject}` [AssertionDefect]" |
17:35:23 | FromGitter | <kaushalmodi> I don't know if and how they are related |
17:35:32 | * | avatarfighter joined #nim |
17:36:38 | Yardanico | yeah I can replicate it |
17:36:41 | Yardanico | lemme try to make a repro |
17:36:43 | Yardanico | so I can report it |
17:36:50 | luis_ | thanks |
17:36:52 | FromGitter | <kaushalmodi> yes! This gives me the same error: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5eb2f5b4adb0ec5c2beb042c] |
17:37:29 | FromGitter | <kaushalmodi> Do we need another report so that nim would give more info than just "unhandled exception: ccgexprs.nim(777, 11) ty.kind in {tyTuple, tyObject} [AssertionDefect]"? |
17:37:48 | Yardanico | I already have it in the issue I linked |
17:38:07 | Yardanico | but these two are separate issues, one is internal compiler error, other is codegen, although they're maybe related , but probably not |
17:48:51 | * | SaraSweet joined #nim |
17:50:09 | FromGitter | <kaushalmodi> I added this to that issue thread for packages not working with arc: https://github.com/nim-lang/Nim/issues/14224#issuecomment-624795102 |
17:50:12 | disbot | ➥ Libraries which don't work with ARC ; snippet at 12https://play.nim-lang.org/#ix=2l1L |
17:50:32 | Yardanico | well you don't need to add that |
17:50:42 | Yardanico | this crash is related to nim-regex and I already reported it separately |
17:51:00 | Yardanico | https://github.com/nim-lang/Nim/issues/14236 is literally this issue |
17:51:01 | disbot | ➥ [ARC] ICE with static objects ; snippet at 12https://play.nim-lang.org/#ix=2l1f |
17:51:02 | Yardanico | from nim-regex |
17:51:30 | * | SaraSweet quit (Client Quit) |
17:51:32 | Yardanico | and if you look at https://github.com/nim-lang/Nim/issues/14224 I actually opened it because of nim-regex :) |
17:51:34 | disbot | ➥ Libraries which don't work with ARC ; snippet at 12https://play.nim-lang.org/#ix=2l1L |
17:54:48 | FromGitter | <kaushalmodi> ok :) |
17:55:03 | Yardanico | and this bug with glob seems to be in nim-regex too, but it's different |
17:55:08 | Yardanico | related to inline iterators again |
17:55:22 | Yardanico | like https://github.com/nim-lang/Nim/issues/14219 but that PR didn't fix it |
17:55:23 | disbot | ➥ ARC codegen bug with inline iterators ; snippet at 12https://play.nim-lang.org/#ix=2gcb |
17:55:32 | Yardanico | I mean that PR doesn't fix this problem |
18:08:22 | Yardanico | @kaushalmodi you should use ./koch temp |
18:08:35 | Yardanico | clone nim compiler git repo (--depth=1) will work |
18:08:47 | Yardanico | and do ./koch temp c --gc:arc otherarguments path/to/your/file.nim |
18:09:01 | Yardanico | If the release version of the compiler will have stack traces enabled it'll be MUCH slower |
18:09:18 | Yardanico | I tested and it makes the compiler ~3x slower even with -d:release --stackTrace:on --lineTrace:on |
18:09:43 | FromGitter | <kaushalmodi> You said that it will show stacktrace only in the compiler, so I didn't pursue that; I do have `koch` as I build from git. Trying it out .. |
18:10:09 | Yardanico | well wdym "only in the compiler", if you mean where it crashed in the code - there's no such thing |
18:10:18 | Yardanico | I don't think nim compiler has that at all |
18:10:25 | Yardanico | if it actually *crashes*, it crashes |
18:11:03 | FromGitter | <kaushalmodi> ok, I thought we can know which user Nim file the compiler was attempting to compile before it crashed |
18:13:23 | Yardanico | @kaushalmodi and I know a temporary fix to solve your codegen issue |
18:13:38 | Yardanico | in nim-regex nodematch.nim line 116 remove {.inline.} pragma |
18:14:04 | Yardanico | then it actually works |
18:18:24 | * | ptdel quit (Remote host closed the connection) |
18:19:38 | * | ptdel joined #nim |
18:19:40 | FromGitter | <kaushalmodi> I did this: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ and recompiled that glob snippet, but still the same crash [https://gitter.im/nim-lang/Nim?at=5eb2ffbcadb0ec5c2beb2a80] |
18:19:57 | Yardanico | which crash? |
18:20:07 | Yardanico | do you run it with -d:forceRegexAtRuntime ? |
18:20:27 | FromGitter | <kaushalmodi> ugh, no |
18:20:30 | Yardanico | well you nee to |
18:20:31 | Yardanico | :P |
18:20:33 | Yardanico | *need |
18:20:57 | FromGitter | <kaushalmodi> yep, confirm your fix :) |
18:21:05 | FromGitter | <kaushalmodi> *I confirm |
18:21:06 | Yardanico | well I need to reproduce it now |
18:21:09 | Yardanico | with a shorter example |
18:21:18 | Yardanico | it's something to do with inline and inline iterators |
18:24:04 | * | ptdel quit (Remote host closed the connection) |
18:25:19 | * | ptdel joined #nim |
18:33:00 | FromGitter | <Willyboar> I just saw httpbeast is no.1 in web frameworks benchmark |
18:33:16 | * | NimBot joined #nim |
18:33:32 | FromGitter | <Willyboar> This is very cool |
18:40:36 | FromGitter | <Willyboar> But we lack web frameworks to kick their a** totally |
18:50:05 | * | s4mu3lbk quit (Remote host closed the connection) |
18:56:25 | * | avatarfighter quit (Ping timeout: 240 seconds) |
18:58:26 | * | s4mu3lbk joined #nim |
19:00:19 | * | avatarfighter joined #nim |
19:01:54 | FromGitter | <waghanza> their is also `jester` and `rosencrantz` (pending in https://github.com/the-benchmarker/web-frameworks/issues/335) |
19:01:54 | disbot | ➥ Introduce rosencrantz |
19:02:07 | Yardanico | jester uses httpbeast |
19:02:27 | FromGitter | <waghanza> yep and is from the same author |
19:02:35 | Yardanico | yes |
19:03:52 | FromGitter | <Willyboar> I really want to see rosencrantz results |
19:04:17 | FromGitter | <waghanza> i'll be glad to reviw any PR |
19:04:35 | FromGitter | <Willyboar> there are more |
19:04:43 | FromGitter | <Willyboar> whip is fast too |
19:05:10 | FromGitter | <Willyboar> it uses httpbeast too |
19:06:27 | * | hoijui quit (Quit: Leaving) |
19:07:27 | * | luis_ quit (Ping timeout: 240 seconds) |
19:13:58 | * | s4mu3lbk quit (Remote host closed the connection) |
19:14:29 | FromDiscord | <queersorceress> @Solitude turns out it was simplier than i thought it would be; i was mistaken on one of the dynlibOverride names, so with that plus one linker flag i was able to circumvent the issue entirely. |
19:18:40 | * | exelotl joined #nim |
19:18:54 | * | ertp07 quit (Ping timeout: 240 seconds) |
19:29:15 | dom96 | Willyboar: :o |
19:29:57 | dom96 | It's #3 it seems |
19:30:06 | dom96 | beaten by a JS framework lol |
19:30:22 | FromGitter | <waghanza> any contribution for https://github.com/the-benchmarker/web-frameworks |
19:31:02 | FromGitter | <waghanza> disclaimer : this version is not really accurate (I mean I use a local docker), I'm working on a cloud version (backed by digitalocean) |
19:31:19 | FromGitter | <Willyboar> you can beat them @dom96 |
19:31:21 | FromGitter | <Willyboar> :PP |
19:31:25 | FromGitter | <waghanza> ;-) |
19:31:29 | * | avatarfighter quit (Ping timeout: 244 seconds) |
19:31:37 | dom96 | the differences are so small that I don't really see much point :P |
19:32:16 | dom96 | honestly, the top 25 are fast enough. |
19:32:24 | FromGitter | <Willyboar> hm crystal lucky drop a lot for a crystal framework |
19:32:43 | FromGitter | <waghanza> tep strange |
19:32:51 | dom96 | thanks for getting httpbeast in there waghanza |
19:32:58 | FromDiscord | <queersorceress> if it can load web pages for a user when requested, i think that is considered "fast enough" 😛 |
19:33:03 | * | ertp07 joined #nim |
19:33:07 | FromGitter | <waghanza> you're welcome ❤️ r |
19:34:36 | FromDiscord | <dom96> oooh https://github.com/features/codespaces |
19:34:42 | FromDiscord | <dom96> I hope Nim is supported |
19:35:00 | Yardanico | well if they support extensions and you can add your own binaries - yes |
19:35:17 | FromGitter | <Willyboar> !!! Looks Great |
19:36:32 | FromGitter | <Willyboar> I suppose any VS extension will work |
19:36:41 | Yardanico | well Nim extension requires nimsuggest |
19:36:47 | Yardanico | for autocompletion and stuff |
19:36:55 | Yardanico | otherwise you'll just have simple syntax highlighting |
19:40:21 | dom96 | Nim support would require at least the compiler |
19:40:37 | dom96 | if you can get the compiler onto these online editors then you can surely get nimsuggest |
19:41:04 | FromGitter | <Willyboar> When will be available? |
19:41:23 | FromDiscord | <queersorceress> if the compiler can be built to a JS target rather than a C target, then that probably would be much easier to make happen |
19:41:50 | Yardanico | that's not exactly easy |
19:42:06 | Yardanico | with wasm it's much more feasible |
19:42:37 | Yardanico | btw reported 4 arc bugs, enough for today I guess :p |
19:42:47 | Yardanico | I mean today's total count :P |
19:43:12 | FromDiscord | <Recruit_main707> good job |
19:43:18 | Yardanico | you can help too |
19:43:22 | FromDiscord | <Recruit_main707> Araq is probably very happy about this |
19:43:29 | Yardanico | just test random libs/apps in nim with arc |
19:43:30 | Yardanico | ez |
19:43:41 | FromDiscord | <Recruit_main707> first make my things work |
19:50:07 | FromGitter | <Willyboar> I just test arc with whip and with arc is 7-10% faster |
19:51:31 | * | ertp07 quit (Read error: Connection reset by peer) |
19:53:11 | * | ertp07 joined #nim |
19:55:51 | * | Jesin quit (Quit: Leaving) |
19:58:23 | * | arecaceae quit (Remote host closed the connection) |
19:58:42 | * | arecaceae joined #nim |
20:01:14 | * | Jesin joined #nim |
20:04:06 | * | narimiran quit (Ping timeout: 272 seconds) |
20:06:21 | * | luis_ joined #nim |
20:06:22 | * | luis_ quit (Remote host closed the connection) |
20:08:24 | PMunch | https://play.nim-lang.org/#ix=2l3Y |
20:08:25 | PMunch | Hmm |
20:09:27 | FromGitter | <kaushalmodi> I have an internal CLI app.. is it possible to update the app executable by itself? |
20:09:28 | PMunch | So is there a way to tell Nim about a const that doesn't involve copying the variable value? |
20:09:28 | * | Jesin quit (Quit: Leaving) |
20:09:53 | PMunch | kaushalmodi, what do you mean? Do you want to run it and it will update itself? |
20:10:45 | FromDiscord | <Never Listen To Beef> If so on linux you can just fetch the new version overtop the old one, on windows you'd need to move the old one, then fetch and delete the old one |
20:10:49 | FromGitter | <kaushalmodi> I am thinking like "when user runs the self update subcommand, download the latest version from my const download url, quit the app and then overwrite itself in the "post quit phase or something" " |
20:11:00 | FromGitter | <kaushalmodi> Just curious |
20:11:01 | Yardanico | yeah that should be possible |
20:11:08 | dom96 | choosenim does this |
20:11:09 | Yardanico | some apps do this |
20:11:11 | PMunch | Definitely doable |
20:11:19 | FromGitter | <kaushalmodi> So what is that "post quit phase"? |
20:11:20 | dom96 | but it fails on Windows IIRC |
20:11:26 | dom96 | because it just overwrites itself |
20:11:27 | FromDiscord | <Never Listen To Beef> Well you have to do what i said on windows |
20:11:41 | FromGitter | <kaushalmodi> On Linux, I get Oserror |
20:11:41 | PMunch | Are you allowed to move a running program though? |
20:11:46 | dom96 | Might be worth creating a package that makes this nice and easy across all platforms |
20:11:47 | FromDiscord | <Never Listen To Beef> Move the file then fetch and then remove the original |
20:11:53 | leorize | PMunch: a const that doesn't involve copying the value? |
20:12:16 | FromDiscord | <Never Listen To Beef> On windows it's a file that is loaded into shared memory, so it can be moved safely afaik |
20:12:17 | * | Guest45332 is now known as dadada |
20:12:19 | FromGitter | <kaushalmodi> How do I remove the original while it is running? |
20:12:33 | dom96 | you don't |
20:12:47 | dom96 | the usual solution is to download to myapp.exe.update |
20:12:52 | PMunch | Yeah, let's say that there is a `const int VERSION` in the C file. I want to wrap this in Nim, but I don't want to copy the value that is assigned to VERSION, I want it to be whatever the file I link it with is. |
20:12:54 | FromDiscord | <Never Listen To Beef> You create a small batch file and invoke that whilst you kill the app inside the batch wait for it to end 😄 |
20:13:18 | dom96 | Actually, I dunno, google how they do it :P |
20:13:29 | FromGitter | <kaushalmodi> Yeah, plan B is to deploy an update script |
20:13:32 | leorize | PMunch: var VERSION {.importc, header: "the_header_that_defines_it.h".} |
20:13:40 | leorize | oh you need to specify the type to |
20:13:45 | dom96 | and please create a package out of this so I can use it in choosenim |
20:13:46 | PMunch | But that is a var |
20:13:47 | * | Jesin joined #nim |
20:13:58 | leorize | PMunch: you can't importc a const |
20:14:15 | leorize | const is strictly nim compile-time |
20:14:20 | PMunch | I know |
20:14:21 | leorize | and let requires initialization :P |
20:14:25 | PMunch | But a let would work |
20:14:42 | PMunch | If Nim would allow me to not give it a value when nodecl is defined |
20:14:58 | leorize | you should really just copy the value over to nim |
20:15:48 | leorize | @kaushalmodi: I haven't tried this again, but IIRC you can move the executable that's running |
20:15:53 | PMunch | That might be hard if it is in a large tree of C macros/conditions |
20:15:55 | leorize | then replace it with the other |
20:16:37 | leorize | PMunch: found a way to make it immutable |
20:16:42 | leorize | make it a template or proc |
20:16:46 | leorize | use {.emit.} :P |
20:17:04 | PMunch | But apparently `let TEST {.importc, nodecl.}: cint = 0` works |
20:17:24 | PMunch | Hmm, a template with {.emit.} would work as well |
20:17:40 | PMunch | Annoying if you need to do many of them though.. |
20:17:54 | leorize | whip up a generator for them |
20:17:55 | liblq-dev | is fields()/fieldPairs() guaranteed to yield all fields in the correct order? |
20:18:00 | leorize | or template-generating templates :P |
20:18:03 | PMunch | Curiously `let TEST {.importc, nodecl.}: cint = default(cint)` doesn't work |
20:18:08 | PMunch | It tries to assign 0 to TEST |
20:18:17 | leorize | liblq-dev: yes, but it doesn't "yield" the fields per-se |
20:18:20 | leorize | it unrolls the loop |
20:18:24 | leorize | so careful with that |
20:18:33 | liblq-dev | I know, that's what I want |
20:18:53 | liblq-dev | I was just wondering if I need a macro to preserve the exact order they are declared in an object |
20:19:01 | leorize | now that for loop macros are a thing maybe we can reimplement those things outside of the compier |
20:19:02 | leorize | compiler* |
20:19:56 | PMunch | Oh right, I forgot about for loop macros |
20:19:59 | FromGitter | <kaushalmodi> leorize: I'll try moving the executable |
20:20:06 | PMunch | A feature I've yet to abuse :P |
20:24:45 | FromGitter | <kaushalmodi> leorize: It works!!! |
20:25:05 | FromGitter | <kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5eb31d2014b48f0698b33997] |
20:26:10 | leorize | nice :) |
20:26:10 | * | s4mu3lbk joined #nim |
20:27:13 | FromGitter | <kaushalmodi> Thanks :) This is a sweet feature.. no need to tell folks to curl and change perms |
20:32:03 | * | s4mu3lbk quit (Remote host closed the connection) |
20:35:23 | PMunch | https://github.com/nim-lang/Nim/issues/14253 |
20:35:26 | disbot | ➥ Assignment to `default` leads to assignment for `nodecl` ; snippet at 12https://play.nim-lang.org/#ix=2l45 |
20:43:03 | leorize | on 1.2.0 that one looks even weirder |
20:43:22 | leorize | Error: identifier expected, but got '[EOF]' |
20:43:27 | PMunch | leorize, my error? |
20:43:44 | leorize | yea, check the playground |
20:44:30 | PMunch | Oh, that is from a stray ` at the end of line 3 |
20:44:34 | PMunch | I have edited it out already |
20:51:04 | PMunch | IMO the fix should be to make all assignments create an assignment in C. But let should be able to use `nodecl` and/or `importc` (doesn't nodecl imply importc? in a way) and not have to assign a value. |
20:51:41 | PMunch | But I should really get to bed |
20:51:48 | PMunch | See ya! |
20:51:49 | * | PMunch quit (Quit: leaving) |
21:02:35 | FromDiscord | <queersorceress> i thought emit was deprecated\ |
21:03:08 | Yardanico | wdym? |
21:03:29 | Yardanico | it won't be deprecated as long as nim has any of its current backends |
21:05:02 | * | ehmry quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
21:05:06 | FromDiscord | <queersorceress> https://nim-lang.org/docs/macros.html#emit.t%2Cstatic%5Bstring%5D |
21:05:18 | Yardanico | thats macros.emit |
21:05:23 | Yardanico | not the emit pragma |
21:11:18 | FromDiscord | <Avahe> @Elegant Beef Trying out propertynotify events now, were you getting any wm state changes? I am not |
21:16:59 | * | ehmry joined #nim |
21:17:28 | FromDiscord | <Never Listen To Beef> Nope |
21:18:26 | FromDiscord | <Avahe> I actually am getting an error on this call you are doing: https://github.com/beef331/goodwm/blob/master/src/goodwm.nim#L595 |
21:20:41 | FromDiscord | <Avahe> You are probably just ignoring the error I think.. you're giving a pointer to an array but it should be a pointer to a cstring |
21:21:40 | FromDiscord | <Avahe> Oh jk that is correct because it is an array of longs. Hm, wonder what's happening |
21:26:02 | * | chemist69 quit (Ping timeout: 260 seconds) |
21:27:03 | * | chemist69 joined #nim |
21:33:43 | * | filcuc joined #nim |
21:36:07 | * | ptdel quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
21:40:50 | Prestige | I'm attempting to call XGetErrorText https://tronche.com/gui/x/xlib/event-handling/protocol-errors/XGetErrorText.html which takes a cstring as an out param, and I also need to specify the size (sort of like a buffer to fill). How should I go about doing this in nim? |
21:41:25 | Prestige | If I don't init the cstring nothing is returned, but if I fill the string I get an Illegal storage access error |
21:42:23 | Prestige | Unless I'm doing it correctly and there just isn't an error message, lol |
21:47:00 | FromGitter | <awr1> working on a C++ thing again, trying to mess with C++ macros makes me long deeply for nim templates |
21:47:44 | * | tane quit (Quit: Leaving) |
21:47:58 | FromDiscord | <Never Listen To Beef> @Avahe what file is the error method in? |
21:48:12 | FromDiscord | <Never Listen To Beef> Ah nvm |
21:48:56 | FromDiscord | <Avahe> I fixed the XChangeProperty part, I was just doing something dumb |
21:49:07 | * | Winterfury quit () |
21:49:25 | FromDiscord | <Avahe> but am now onto trying to get XGetErrorText to work |
21:50:30 | * | filcuc quit (Ping timeout: 260 seconds) |
21:53:20 | FromDiscord | <Avahe> Need a nim guru to take a look, not sure how this is supposed to work with cstring |
21:55:22 | FromGitter | <awr1> do you know the size of the buffer or not |
21:55:26 | FromDiscord | <Never Listen To Beef> The C method takes a char array, so i dont exactly know |
21:55:39 | FromDiscord | <Never Listen To Beef> Well you pass it a buffer and it returns the size with the changed buffer |
21:55:47 | * | solitudesf quit (Ping timeout: 260 seconds) |
21:55:53 | FromDiscord | <Avahe> I don't, it seems I just need to declare a buffer with some arbitrary size and pass it in |
21:56:04 | FromGitter | <awr1> if you don't know the size of the output, you will need to allocate a cstring of a certain "large size" |
21:56:15 | * | Vladar quit (Quit: Leaving) |
21:56:53 | FromDiscord | <Avahe> Is there a way to declare a string with some size rather than filling " ... "? like char[255]? |
21:57:09 | FromGitter | <awr1> i did something like this for a PR recently |
21:57:25 | FromGitter | <awr1> https://github.com/nim-lang/Nim/pull/13950/files#diff-bf62676d6697cd4a45cd6e35f6b5468cR35 |
21:57:26 | disbot | ➥ added extended msg for failed library loads w/ incorrect DLL formats |
21:57:45 | Yardanico | @Avahe it really depends on what do you need that for |
21:57:57 | FromGitter | <awr1> this is with a stack allocation, fyi |
21:58:57 | FromGitter | <awr1> but you can do `var msg: array[1000, char]` for a stack alloc or `var msg = cast[cstring](alloc0(1000))` |
21:59:02 | FromGitter | <awr1> for a heap one |
21:59:20 | FromGitter | <awr1> and then `dealloc` the underlying pointer. |
22:01:02 | Prestige | looking like I'll have to do that latter since the param specifies a cstring |
22:01:02 | FromGitter | <awr1> `var cMsg :array[1000, char]; XGetErrorText(display, code, cast[cstring](addr cMsg[0]), cMsg.len); let msg = $cast[cstring](addr cMsg[0])` |
22:01:13 | Prestige | oh maybe that |
22:01:20 | FromGitter | <awr1> you can get a cstring from both |
22:01:31 | FromGitter | <awr1> get address to the first ele and cast it |
22:02:17 | FromGitter | <awr1> `msg` will allocate a normal nim `string` |
22:02:21 | FromGitter | <awr1> via $ |
22:02:25 | Prestige | That worked, thanks! |
22:02:41 | FromGitter | <awr1> glad to hear |
22:03:25 | * | s4mu3lbk joined #nim |
22:06:22 | FromDiscord | <mratsim> I hate generic sigmatch bug |
22:06:22 | FromDiscord | <mratsim> https://cdn.discordapp.com/attachments/371759389889003532/707714906748878878/unknown.png |
22:06:31 | liblq-dev | why are types in generic procs not bound from declaration site? |
22:07:05 | * | abm quit (Quit: Leaving) |
22:07:39 | liblq-dev | I have this generic proc https://github.com/liquid600pgm/aglet/blob/master/src/aglet/gl.nim#L304 |
22:07:53 | liblq-dev | and I'm trying to call it from a macro |
22:07:59 | liblq-dev | but I'm getting undeclared field errors |
22:08:09 | liblq-dev | I have to import the `gl` module from my main module which is bad |
22:08:32 | FromDiscord | <mratsim> use bindSym instead of ident in your macro |
22:08:42 | FromGitter | <awr1> ^ this |
22:08:54 | * | vegai quit (Ping timeout: 240 seconds) |
22:09:10 | * | vegai joined #nim |
22:09:42 | liblq-dev | but it's not a problem with the macro |
22:09:57 | liblq-dev | look at this https://github.com/liquid600pgm/aglet/blob/master/src/aglet/arraybuffer.nim#L57 |
22:10:14 | liblq-dev | where'd I even use bindSym? |
22:11:32 | * | monokrom quit (Remote host closed the connection) |
22:11:58 | FromGitter | <awr1> your issue is the `quote do:` |
22:12:04 | FromGitter | <awr1> you need to make a call from scratch |
22:12:26 | FromGitter | <awr1> `quote do:` i believe is untyped so it won't perform symbol binding |
22:12:59 | liblq-dev | dang it, and there I was hoping I could make my code shorter |
22:14:51 | FromDiscord | <Rika> is it a good idea to import the compiler just to use int128 |
22:14:56 | leorize | Prestige: you can declare a string with the size you need then use it as a buffer |
22:14:57 | disruptek | yep. |
22:15:23 | disruptek | DOOOOOIT |
22:15:40 | liblq-dev | @awr1 doesn't work |
22:15:40 | disruptek | MOAR MOAR MOAR |
22:15:50 | leorize | liblq-dev: just bindsym then quote it in? |
22:15:56 | liblq-dev | as I said the error occurs in vertexAttrib not the macro |
22:15:57 | FromGitter | <awr1> you could maybe do that too |
22:16:03 | FromGitter | <awr1> what is your code |
22:16:07 | Prestige | leorize: in another way than awr1 said? |
22:16:13 | leorize | yea |
22:16:24 | leorize | var str = newString(size_here) |
22:16:27 | liblq-dev | @awr1 just sent it… https://github.com/liquid600pgm/aglet/blob/master/src/aglet/gl.nim#L304 |
22:16:30 | leorize | str.cstring is your buffer |
22:16:32 | Prestige | oh nice, thanks |
22:16:34 | Prestige | I was afk |
22:16:40 | FromGitter | <awr1> ah i didn't think of that |
22:16:45 | leorize | remember to setLen() after you got the correct size |
22:17:01 | FromGitter | <awr1> no i meant for the macro |
22:17:08 | liblq-dev | I can't just use `bind` in the proc |
22:17:14 | liblq-dev | because it only works for templates |
22:17:35 | liblq-dev | what I'm getting is: /home/daknus/Coding/Nim/aglet/src/aglet/gl.nim(306, 35) Error: undeclared field: 'GlUint' for type system.int [declared in /home/daknus/.choosenim/toolchains/nim-1.2.0/lib/system/basic_types.nim(2, 3)] |
22:17:46 | FromDiscord | <Recruit_main707> !eval echo("i dont think so") |
22:17:49 | NimBot | i dont think so |
22:18:02 | FromDiscord | <Rika> someone else answer me T_T |
22:18:11 | FromDiscord | <Rika> disruptek says ok but i dont trust that dude |
22:18:17 | disruptek | wtf |
22:18:19 | FromGitter | <awr1> i mean what did you change here |
22:18:20 | FromGitter | <awr1> https://github.com/liquid600pgm/aglet/blob/master/src/aglet/arraybuffer.nim#L66 |
22:18:33 | leorize | Rika: it's ok, as long as the compiler version is new enough |
22:18:36 | liblq-dev | @awr I made it construct the AST using basic procs like newCall etc |
22:18:43 | FromDiscord | <clyybber> @Rika IMO no |
22:18:52 | disruptek | don't listen to clyybber. |
22:18:53 | FromDiscord | <clyybber> Just copy the Int128 file |
22:19:03 | disruptek | import the whole thing. |
22:19:16 | FromDiscord | <clyybber> Oh key |
22:19:24 | leorize | we should move int128 into fusion |
22:19:33 | disruptek | the compiler needs it. |
22:20:08 | * | lritter quit (Quit: Leaving) |
22:20:24 | FromGitter | <awr1> "disruptek says ok but i dont trust that dude" |
22:20:28 | FromGitter | <awr1> disruptek is a secret agent /s |
22:20:51 | FromDiscord | <clyybber> If int128 gets added to the stdlib it must be made more convinient to use |
22:20:53 | disruptek | rika is a secret asian. |
22:21:14 | FromGitter | <awr1> int128 should probably get added imo |
22:21:58 | * | s4mu3lbk quit (Remote host closed the connection) |
22:22:00 | FromGitter | <awr1> it's a weird point of contention because it isn't super well supported in C but there is def. a desire for it |
22:23:52 | FromGitter | <awr1> @liblq-dev did you use `newCall(bindSym("vertexAttrib"), ...` etc. |
22:24:04 | liblq-dev | yes |
22:25:37 | disruptek | i'm just finishing up a PR to add int130 to fusion. |
22:26:12 | disruptek | should enough integers to last me through june. |
22:27:20 | FromGitter | <awr1> hm |
22:27:33 | FromGitter | <awr1> this is weird |
22:28:50 | FromGitter | <awr1> shot in the dark: you may want to try `GlUint(index)` and `GlSizei(stride)` |
22:30:21 | liblq-dev | @awr1 well, that seems to have worked |
22:30:53 | FromGitter | <awr1> may want to raise an issue then |
22:33:41 | FromGitter | <awr1> i feel like i have maybe encountered this issue, that the compiler sometimes doesn't like method syntax for converting to user defined types |
22:35:48 | federico3 | https://github.com/FedericoCeratto/nim-httpauth/issues/5 urgh |
22:35:49 | disbot | ➥ postgres and mysql shared libs required even when not used |
22:36:22 | * | couven92 joined #nim |
22:36:30 | * | fredrikhr quit (Disconnected by services) |
22:36:36 | * | couven92 is now known as fredrikhr |
22:39:25 | skrylar[m] | that looks like a way higher effort wrapper than the one i use. lol |
22:40:16 | liblq-dev | skrylar[m]: are you talking about aglet? |
22:40:31 | skrylar[m] | correct |
22:40:54 | liblq-dev | well my philosophy is to create a wrapper that does not make you deal with low-level C state machine cruft |
22:41:32 | FromGitter | <awr1> i have a minimal example |
22:41:37 | FromGitter | <awr1> im gonna make an issue |
22:41:55 | skrylar[m] | i just have a very thin layer for things like mapping gl types to distinct ints and then unifying the procs on top of that |
22:42:09 | skrylar[m] | everything is 'use' mostly because bind was already a keyword |
22:42:28 | liblq-dev | I named binding-related stuff 'use', too |
22:42:42 | liblq-dev | but it's meant to be hidden away from the end user |
22:43:51 | liblq-dev | I'm mainly inspired by the API design from glium, but I decided to add some cool features that weren't possible there because of safety and all that Rust stuff |
22:44:50 | liblq-dev | well anyways I'm out for today. good night everyone |
22:44:54 | * | liblq-dev quit (Quit: WeeChat 2.8) |
22:44:56 | skrylar[m] | gnight |
22:48:55 | FromGitter | <awr1> https://github.com/nim-lang/Nim/issues/14254 |
22:48:57 | disbot | ➥ Cross-module refusal of method call syntax for type conversion in generic ; snippet at 12https://play.nim-lang.org/#ix=2l4Q |
22:51:56 | * | idf quit (Ping timeout: 272 seconds) |
23:04:01 | Prestige | Is there a whitespace trimming proc for strings? I haven't found anything |
23:05:29 | FromDiscord | <Yardanico> strip or unindent depending on what you mean |
23:06:10 | Prestige | Thanks |
23:12:55 | Prestige | Looks like that isn't how I should go about finding the "real size" of the filled string.. string returning 1024 instead of the length of the message I received |
23:15:26 | * | s4mu3lbk joined #nim |
23:19:55 | FromDiscord | <Rika> what're you trying to do |
23:19:57 | Prestige | This is what's happening https://play.nim-lang.org/#ix=2l57 |
23:20:21 | Prestige | trying to get the length of the actual string contents so I can reduce errorMessage to a proper length |
23:22:43 | Prestige | @Rika for context the function on line 2 has errorMessage as an out param |
23:24:16 | FromDiscord | <Rika> i know |
23:24:27 | FromDiscord | <Rika> are you sure its not supposed to be a ptr cstring |
23:24:34 | FromDiscord | <Rika> or a ptr char |
23:25:40 | Prestige | I mean the call is working and I get the message back just fine, but len(errorMessage) is still 1024 and I want to reduce it once it's been partially filled |
23:25:42 | FromGitter | <awr1> try maybe |
23:26:07 | FromGitter | <awr1> `errorMessage.setLen(errorMessage.cstring.len)` |
23:26:44 | FromDiscord | <Rika> try echoing just the strip |
23:26:51 | FromDiscord | <Rika> and then repr that too |
23:27:04 | Prestige | ah errorMessage.cstring.len is what I needed, thanks |
23:31:19 | * | s4mu3lbk quit (Remote host closed the connection) |
23:48:52 | * | krux02 quit (Remote host closed the connection) |
23:56:49 | * | ftsf joined #nim |