| 00:04:05 | * | Hideki_ joined #nim |
| 00:08:22 | * | Hideki_ quit (Ping timeout: 245 seconds) |
| 00:12:04 | FromGitter | <awr1> i find in attempting to create these sorts of grand design projects you will usually come across some specific issue about the language that you kinda would like to see fixed |
| 00:12:46 | FromGitter | <awr1> although i think the potential for this is waning as the language has been slowly but surely maturing |
| 00:14:31 | shashlick | @awr1: which projects are you talking about? |
| 00:15:38 | FromGitter | <awr1> i meant kind of in a general sense (i'm working on a game engine currently) but also out of observations i've seen with like the status team |
| 00:17:39 | FromGitter | <awr1> but i mean, you've worked on nimgen so it's quite possible you've had that feeling too |
| 00:17:46 | shashlick | i relate - every nim project i have worked on, i have run into roadblocks |
| 00:18:54 | * | abm quit (Quit: Leaving) |
| 00:21:00 | shashlick | in my case i've mostly built projects to make the Nim ecosystem better so my roadblocks are perhaps less frustrating because they improve Nim overall |
| 00:22:52 | shashlick | but i know I was extremely frustrated for feud, the text editor, and that was for my personal toolkit |
| 00:23:04 | shashlick | i cannot imagine what it would be like if there was $$$ involved |
| 00:24:38 | ryukoposting | howdy |
| 00:25:04 | FromGitter | <awr1> hello |
| 00:25:10 | shashlick | which brings me back to wanting to improve the Nim ecosystem - it's hamster wheel |
| 00:25:18 | shashlick | long time @ryukoposting - what's up |
| 00:26:04 | ryukoposting | not much, sorry for disappearing lol |
| 00:26:35 | FromGitter | <awr1> also @deech it's been mentioned a thousand times but the current lack of cyclic import becomes an issue for programs once they attain a certain size and scope |
| 00:26:36 | ryukoposting | it's been a very busy few months, seems like a lot has happened while I'm gone! |
| 00:26:53 | FromGitter | <awr1> not always, but it is common enough |
| 00:27:19 | shashlick | what stands out the most @ryukoposting? |
| 00:27:58 | ryukoposting | well, the push to go stable soon is the big one |
| 00:29:35 | FromGitter | <awr1> it would be funny if nim stabilizes and finalizes its spec before rust does |
| 00:31:00 | FromGitter | <awr1> unfortunately rust has a lot more manpower than us... |
| 00:32:36 | FromGitter | <awr1> for some reason i always get colds in the summer and not the winter |
| 00:38:08 | * | lmariscal1 joined #nim |
| 00:39:12 | * | lmariscal1 quit (Client Quit) |
| 01:00:21 | * | CirclingTheVoid quit (Quit: leaving) |
| 01:05:22 | * | joshbaptiste quit (Ping timeout: 244 seconds) |
| 01:17:16 | skrylar[m] | woo. got my nim simplex optimizer to work kinda |
| 01:32:34 | * | joshbaptiste joined #nim |
| 02:02:48 | * | Tanger quit (Ping timeout: 258 seconds) |
| 02:04:58 | * | Tanger joined #nim |
| 02:31:39 | * | rockcavera joined #nim |
| 03:30:08 | * | laaron quit (Remote host closed the connection) |
| 03:31:12 | * | laaron joined #nim |
| 03:33:34 | * | chemist69 quit (Ping timeout: 276 seconds) |
| 03:35:00 | * | chemist69 joined #nim |
| 04:07:19 | FromGitter | <zacharycarter> (https://files.gitter.im/nim-lang/Nim/JcKz/image.png) |
| 04:07:36 | FromGitter | <zacharycarter> think I got some decent looking terrain now boyz |
| 04:14:55 | FromGitter | <zacharycarter> now to add texture splatting |
| 04:45:13 | * | rockcavera quit (Remote host closed the connection) |
| 04:48:36 | * | fjellfras joined #nim |
| 04:52:02 | * | nsf joined #nim |
| 05:00:30 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 05:01:13 | * | laaron joined #nim |
| 05:02:10 | * | Jjp137 quit (Quit: Leaving) |
| 05:04:31 | * | Jjp137 joined #nim |
| 05:27:17 | * | cyberjpn joined #nim |
| 05:31:39 | * | narimiran joined #nim |
| 05:32:02 | Zevv | wow thats pretty sweet zacharycarter! |
| 05:33:43 | Zevv | looks like NASA footage |
| 05:40:29 | * | absolutejam1 joined #nim |
| 05:42:48 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 05:42:50 | * | laaron- joined #nim |
| 05:44:11 | FromGitter | <zacharycarter> Once I texture it, it will look a lot better. Thanks! |
| 06:22:44 | * | Mister_Magister quit (Excess Flood) |
| 06:23:15 | * | Mister_Magister joined #nim |
| 06:24:40 | * | absolutejam1 quit (Ping timeout: 244 seconds) |
| 06:25:19 | * | sagax quit (Read error: Connection reset by peer) |
| 06:26:01 | Zevv | pretty cool as it is already, I like the sand/snow look with the rocks sticking through |
| 06:34:34 | * | alex92 joined #nim |
| 06:35:11 | * | krux02 joined #nim |
| 06:38:09 | alex92 | Araq, so what's left of 1.0 |
| 06:38:12 | alex92 | before 1.0 |
| 06:38:43 | Araq | QA |
| 06:39:05 | Araq | and promotion material |
| 06:42:21 | alex92 | hm |
| 06:42:35 | alex92 | and what about newruntime |
| 06:43:22 | alex92 | i wonder if there are any small tasks to ponder on |
| 06:45:47 | Araq | you could fix newruntime bugs |
| 06:45:56 | Araq | https://github.com/nim-lang/RFCs/issues/168 here, now was that so hard ... |
| 06:46:14 | Araq | Concepts done right (IMHO) |
| 06:51:20 | * | hoijui joined #nim |
| 06:53:01 | Araq | and compare it to https://nim-lang.org/docs/manual_experimental.html#concepts :P |
| 06:55:05 | alex92 | hm, i'll take a look at the async issues |
| 06:58:03 | * | gangstacat quit (Quit: Ĝis!) |
| 06:59:46 | * | PMunch joined #nim |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:00:25 | * | leorize quit (Remote host closed the connection) |
| 07:00:59 | * | leorize joined #nim |
| 07:04:47 | * | gmpreussner joined #nim |
| 07:06:00 | * | cyberjpn quit (Ping timeout: 244 seconds) |
| 07:09:00 | * | cyberjpn joined #nim |
| 07:16:19 | * | absolutejam1 joined #nim |
| 07:17:32 | * | Mister_Magister quit (Ping timeout: 245 seconds) |
| 07:20:03 | * | solitudesf joined #nim |
| 07:22:35 | * | floppydh joined #nim |
| 07:24:56 | * | nc-x joined #nim |
| 07:25:25 | nc-x | Araq: is the concepts RFC for 1.0 or later? |
| 07:28:07 | * | Mister_Magister joined #nim |
| 07:28:59 | * | nc-x quit (Remote host closed the connection) |
| 07:41:34 | * | solitudesf quit (Quit: Leaving) |
| 07:41:55 | * | solitudesf joined #nim |
| 07:45:00 | * | ng0 joined #nim |
| 07:47:56 | Araq | 1.x, probably 1.3 but this schedule needs to be fleshed out, currently my plan is: |
| 07:48:11 | Araq | 1.1: incremental compilation (cause every Nim user benefits) |
| 07:48:16 | Araq | 1.2: new runtime |
| 07:48:28 | Araq | 1.3: type-check generics aka concepts |
| 07:49:17 | * | nc-x joined #nim |
| 07:49:28 | * | couven92 joined #nim |
| 07:49:32 | Araq | nc-x, read the logs please |
| 07:50:47 | nc-x | Well, I would put IC later. I haven't used many projects where compilation is annoyingly slow. And newruntime and concepts would basically be defining how libraries (and other projects) are written, so they should be higher priority IMO. |
| 07:56:51 | PMunch | When using complex macros compile-times can shoot up quickly |
| 07:57:19 | PMunch | I've definitely had projects where compile-time was starting to become annoying (compared to normal Nim compile-times, still fairly fast) |
| 07:58:42 | PMunch | But I agree that library design would be influenced by the two others.. |
| 08:02:43 | skrylar[m] | fast compilation matters in weird ways |
| 08:04:17 | * | nc-x quit (Remote host closed the connection) |
| 08:07:03 | skrylar[m] | the lisp/smalltalk thing of paying for compiles in short steps when you make each function is kinda nice, since you never get sacked with waiting too much to iterate, but i dunno how likely we'll ever see that level in the wild |
| 08:18:40 | * | hoijui quit (Ping timeout: 264 seconds) |
| 08:20:24 | * | cyberjpn quit (Ping timeout: 244 seconds) |
| 08:21:18 | * | absolutejam1 quit (Ping timeout: 245 seconds) |
| 08:21:57 | * | hoijui joined #nim |
| 08:32:04 | Araq | 1.3 doesn't allow many new things, it's about restricting generics |
| 08:35:52 | Araq | and I have an alternative for 1.2 |
| 08:35:57 | Araq | so 1.1 is most important |
| 08:36:48 | * | arecaceae quit (Remote host closed the connection) |
| 08:37:12 | * | arecaceae joined #nim |
| 08:38:05 | lqdev[m] | can't wait for 1.1 then |
| 08:38:31 | lqdev[m] | compiling planet overgamma is a pain in the butt since it takes like 6 seconds until I see a window |
| 08:39:09 | * | nc-x joined #nim |
| 08:40:09 | * | absolutejam1 joined #nim |
| 08:40:16 | nc-x | Well, just don't forget to add "cyclic imports" and "removal of requirement of forward declaration" to the 1.x schedule and I am happy 😁 |
| 08:41:13 | PMunch | Huh, never heard of planet overgamma before. Looks cool :) |
| 08:42:04 | * | hoijui quit (Ping timeout: 264 seconds) |
| 08:42:47 | * | nc-x quit (Remote host closed the connection) |
| 08:45:06 | alex92 | i like IC too |
| 08:45:46 | alex92 | how would you remove formward decl: i guess macros really make this difficult? |
| 08:45:46 | * | laaron- quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 08:46:20 | * | laaron joined #nim |
| 08:49:02 | * | Vladar joined #nim |
| 08:49:05 | * | sagax joined #nim |
| 08:52:45 | Araq | nc-x we need IC before attempting to do these things so that we can measure if everything still works out with an inherently slower compilation setup |
| 08:55:58 | * | couven92 quit (Quit: Client disconnecting) |
| 08:56:26 | * | couven92 joined #nim |
| 09:04:48 | * | hoijui joined #nim |
| 09:10:05 | alex92 | but why |
| 09:11:57 | Araq | because recursive dependencies change the game |
| 09:12:04 | * | hoijui quit (Ping timeout: 264 seconds) |
| 09:12:08 | alex92 | do we need to expand macros or something for forward decl? we can just pre-pass the direct proc definitions and resolve them and require forward for macros |
| 09:12:14 | alex92 | sorry, can't remember the logic |
| 09:12:35 | alex92 | ah i wonder about the forward proc decl-s, can't remember why is it complicated |
| 09:13:05 | Araq | oh forward decls are different |
| 09:13:14 | Araq | I spoke about recursive module dependencies |
| 09:13:46 | Araq | but removing forward decls might also have an impact on the IC implementation, it's wise to work on IC first IMO |
| 09:14:28 | alex92 | hm, but if we ignore IC for a moment |
| 09:14:34 | alex92 | does the simplish pre-pass thing work |
| 09:14:42 | alex92 | as an algorithm |
| 09:16:11 | Araq | what do you mean? 'reordering'? |
| 09:16:20 | Araq | it's used extensively without trouble |
| 09:16:25 | Araq | afaict |
| 09:16:37 | Araq | but it's not the same thing as getting rid of forward decls |
| 09:16:53 | alex92 | well, doesn't it leave only cases where |
| 09:17:00 | alex92 | macro-s generate proc definitions |
| 09:17:08 | alex92 | i wouldn't call it reordering |
| 09:17:16 | alex92 | more like "predeclaring" |
| 09:35:19 | * | solitudesf quit (Ping timeout: 244 seconds) |
| 09:35:41 | * | Araq shrugs |
| 09:36:18 | Araq | not every proc is produced by a macro, most aren't. a design that is explicit what works and what doesn't is good enough |
| 09:36:50 | * | solitudesf joined #nim |
| 09:38:03 | Araq | but it's not really important is it? it doesn't keep you from writing good Nim code. Cyclic imports are more important for most people who complain about these things |
| 09:39:32 | livcd | Araq: do you have some features of Nim that might disappear / get removed due to whatever reasons |
| 09:40:08 | Araq | livcd, as I said, I only know about 'do' |
| 09:40:40 | Araq | well there is '.this' but it's already deprecated |
| 09:40:42 | * | leorize_ joined #nim |
| 09:40:49 | livcd | i did not even know about do :-) |
| 09:41:23 | alex92 | i just hope `using` stays |
| 09:41:23 | Araq | but there would be an RFC process and a migration period etc yada yada |
| 09:41:53 | alex92 | otherwise i'd love to see async newruntime, but not sure how much work is left for this |
| 09:42:15 | alex92 | of course, that's after-1.0 |
| 09:42:19 | Araq | the 'shr' change and '-d:danger' things are things that had no RFC and we got blamed for it. and rightly so |
| 09:42:47 | Araq | and this has ended, you want a change, at least write an RFC |
| 09:42:50 | alex92 | i have a lot of `do`, but i guess i can write a tool to automate porting that |
| 09:43:46 | Araq | just relax |
| 09:44:01 | Araq | we need to offer an alternative before we can deprecate it |
| 09:44:01 | * | leorize quit (Ping timeout: 260 seconds) |
| 09:44:01 | alex92 | i am very relaxed about it |
| 09:44:04 | alex92 | i like writing tools |
| 09:44:07 | Araq | :-) |
| 09:44:12 | alex92 | just trying to find a reason for it :P |
| 09:45:06 | alex92 | well, iirc `a do ()` is just `a(.. , () => same stuff)` or `a(.. , proc(..) = .. )` |
| 09:48:47 | alex92 | we can RFC a `dont` .. you write a dont (): echo 0 and nim doesnt execute such code while calling `a` |
| 09:49:12 | Araq | funny. |
| 09:49:26 | Araq | (it was a joke, right?) |
| 09:49:31 | alex92 | i was already ashamed while writing it |
| 09:49:42 | alex92 | it was supposed to be one .. :D |
| 09:49:57 | alex92 | ok, back to work |
| 09:54:08 | * | ofelas quit (Quit: shutdown -h now) |
| 09:55:35 | * | NimBot joined #nim |
| 09:55:38 | * | leorize_ is now known as leorize |
| 10:08:06 | FromGitter | <AmberSaber> Hint: used config file '/usr/local/Cellar/nim/0.20.2/nim/config/nim.cfg' [Conf] ⏎ Hint: system [Processing] ⏎ Hint: widestrs [Processing] ⏎ Hint: io [Processing] ⏎ Hint: greetings [Processing] ... [https://gitter.im/nim-lang/Nim?at=5d76248550508949d3029ec3] |
| 10:09:43 | Araq | dunno |
| 10:11:02 | alex92 | run the failing clang command and see the output :( |
| 10:27:47 | * | lnx joined #nim |
| 10:45:30 | * | Romanson joined #nim |
| 11:05:21 | * | absolutejam1 quit (Ping timeout: 268 seconds) |
| 11:20:20 | * | cyberjpn joined #nim |
| 11:21:46 | FromGitter | <AmberSaber> I fix it |
| 11:21:55 | Araq | how? |
| 11:21:58 | FromGitter | <AmberSaber> It can works |
| 11:23:47 | FromGitter | <AmberSaber> I modified some system configurations, causing clang to fail to link to header files |
| 11:26:37 | alex92 | well done! |
| 11:30:53 | FromGitter | <AmberSaber> I will study nim in September. I didn't intend to learn it. But with the Chinese official website, this makes more people like me look more confident. |
| 11:32:31 | livcd | AmberSaber are you chinese ? |
| 11:32:44 | federico3 | do you have problems fetching libraries from GitHub? |
| 11:33:38 | livcd | well I had because of corporate firewall |
| 11:36:59 | FromGitter | <AmberSaber> There are some Chinese people here, but they have enough programming experience and their English reading level is not bad. I am very poor in these two aspects. |
| 11:40:36 | * | gangstacat joined #nim |
| 11:41:36 | * | absolutejam1 joined #nim |
| 11:46:13 | * | absolutejam1 quit (Ping timeout: 246 seconds) |
| 11:54:45 | * | dddddd joined #nim |
| 11:55:07 | * | fjellfras quit (Quit: Leaving) |
| 12:01:19 | * | hoijui joined #nim |
| 12:04:10 | * | absolutejam1 joined #nim |
| 12:05:06 | federico3 | livcd: how so? |
| 12:08:48 | * | absolutejam1 quit (Ping timeout: 245 seconds) |
| 12:13:52 | FromGitter | <AmberSaber> The firewall is to protect those fools, their minds are easily brainwashed by outside information. |
| 12:14:12 | FromGitter | <AmberSaber> Firewall is never a problem |
| 12:15:29 | FromGitter | <AmberSaber> China has a population of 1.4 billion, which means there are too many fools. |
| 12:15:40 | * | absolutejam1 joined #nim |
| 12:16:43 | FromGitter | <AmberSaber> Like Hong Kong’s 7 million people, millions of them are stupid. |
| 12:17:10 | alex92 | please, no political "analysis" here |
| 12:17:57 | alex92 | if you really want to go into such topics, there is #nim-offtopic |
| 12:18:18 | narimiran | even there, political topics can only cause trouble |
| 12:20:57 | * | Kaivo joined #nim |
| 12:21:03 | FromGitter | <AmberSaber> Yes, I don't like to talk about politics, but there are always people who use the firewall to cause controversy. |
| 12:28:22 | FromGitter | <AmberSaber> Living is always difficult, but things are always getting better, not worse. There are difficulties, but there is always a way to solve it. Discussing a firewall is a political mapping. |
| 12:28:44 | livcd | I think you misunderstood |
| 12:30:49 | FromGitter | <AmberSaber> Stop this topic, forget it, let me do something else now. |
| 12:31:04 | Araq | https://www.zdnet.com/article/cobol-turns-60-why-it-will-outlive-us-all/ |
| 12:32:16 | Zevv | well, its only four times older then nim :) |
| 12:32:56 | alex92 | we need e |
| 12:33:37 | alex92 | typo, sorry |
| 12:34:00 | narimiran | Zevv: and it will be only less and less! :P |
| 12:37:40 | * | rockcavera joined #nim |
| 12:37:43 | * | narimiran quit (Read error: Connection reset by peer) |
| 12:39:15 | * | dddddd quit (Ping timeout: 244 seconds) |
| 12:40:02 | Zevv | true :) |
| 12:40:16 | * | hoijui quit (Ping timeout: 264 seconds) |
| 12:40:18 | * | narimiran joined #nim |
| 12:40:54 | * | dddddd joined #nim |
| 12:41:40 | FromGitter | <zacharycarter> so we just need to put more Nim programs in the cloud |
| 12:41:43 | FromGitter | <zacharycarter> and then Nim will never die |
| 12:42:03 | FromGitter | <zacharycarter> also would help if we could figure out a way to clone Araq a few times |
| 12:46:11 | Araq | haven't you noticed? I stopped programming, I'm only writing specs and RFCs for you to implement |
| 12:46:19 | * | Araq is kidding |
| 12:46:38 | Araq | but the idea has some merit ... hmmm |
| 12:47:03 | alex92 | we also write RFC-s for you to implement |
| 12:47:10 | alex92 | so it's just a loop |
| 12:47:56 | Araq | but I don't implement the RFCs :P |
| 12:48:08 | alex92 | and we don't implement your RFC-s :P |
| 12:48:09 | FromGitter | <zacharycarter> I propose a RFC to talk about implementing RFCs |
| 12:48:13 | federico3 | zacharycarter: in the cloud? It's more volatile than anything else |
| 12:48:15 | FromGitter | <zacharycarter> or not implementing them |
| 12:48:18 | alex92 | and in the end only timothee and krux implement stuff |
| 12:48:22 | alex92 | while we all bikeshed |
| 12:48:22 | disruptek | if i get time to code today, i expect to have native nim cloud apis for amazon finished. i need to add signing for azure and google apis, but it shouldn't be difficult. 😉 |
| 12:48:40 | FromGitter | <zacharycarter> federico3: the article basically said that since COBOL applications are moving to the cloud, they will outlvie us |
| 12:48:50 | FromGitter | <zacharycarter> so i was just making fun at that |
| 12:49:06 | alex92 | zacharycarter, we got to the "lets do a conf" stage |
| 12:49:45 | alex92 | can you host us |
| 12:51:13 | FromGitter | <zacharycarter> conference? where? |
| 12:51:27 | alex92 | in finland |
| 12:51:30 | FromGitter | <zacharycarter> probably the best place to have a Nim conf at this point seems to be China |
| 12:51:45 | alex92 | if you host us , all 20 of us |
| 12:51:48 | livcd | but only if you can live with the firewall :-) |
| 12:52:07 | FromGitter | <zacharycarter> yeah - only firewall lovers may attend |
| 12:52:20 | FromGitter | <zacharycarter> I mean, you guys can stay in my apartment |
| 12:52:22 | alex92 | i am not sure if they will let us thru the border check physical wall first :P |
| 12:52:53 | FromGitter | <zacharycarter> but someone will probably end up sharing a bed with my dog |
| 12:53:08 | disruptek | hong kong sounds nice. |
| 12:53:10 | FromGitter | <zacharycarter> and as far as where the conference is held, I don't have many resources besides my apartment |
| 12:53:26 | FromGitter | <zacharycarter> this is starting to sound like the most depressing conference ever |
| 12:54:01 | alex92 | finland has many lakes |
| 12:54:07 | FromGitter | <zacharycarter> this is true |
| 12:54:16 | alex92 | but no, i would prefer souther europe |
| 12:54:24 | FromGitter | <zacharycarter> we could probably just like take over an island near Helsinki |
| 12:54:28 | FromGitter | <zacharycarter> and no one would notice |
| 12:54:31 | alex92 | its warm, easy to access and the food is tasty |
| 12:54:36 | alex92 | oh, does it have islands? |
| 12:54:36 | FromGitter | <zacharycarter> because there are so damn many of them |
| 12:54:42 | alex92 | but greece have like 500 |
| 12:55:00 | alex92 | disruptek, it sounds disrupting! |
| 12:55:20 | FromGitter | <zacharycarter> Helisnki has like 300+ |
| 12:55:23 | FromGitter | <zacharycarter> but not 500 |
| 12:55:24 | alex92 | wat |
| 12:55:39 | alex92 | amazing |
| 12:55:43 | narimiran | Croatia also has plenty of islands, and it is closer to the western/central Europe than Greece :P |
| 12:55:51 | FromGitter | <zacharycarter> definitely don't come to Finland for the food |
| 12:55:55 | FromGitter | <zacharycarter> the food here is bad |
| 12:56:23 | alex92 | i like croatia, never been there, sounds like a balkan superpower |
| 12:56:36 | alex92 | dont you have a lot of fish zachar |
| 12:57:26 | FromGitter | <zacharycarter> Everyone loves salmon here - like Salmon soup is everywhere |
| 12:57:42 | * | nif quit (Quit: ...) |
| 12:57:45 | FromGitter | <zacharycarter> and I think Finns also love picked / fermented herring |
| 12:57:51 | * | nif joined #nim |
| 12:57:51 | FromGitter | <zacharycarter> I'll take a hard pass on both |
| 12:58:59 | FromGitter | <zacharycarter> I feel kind of dirty working on the feature I'm working on at work |
| 12:59:05 | FromGitter | <zacharycarter> like my soul needs to take a shower or something |
| 12:59:18 | FromGitter | <zacharycarter> adding lootboxes to the game |
| 12:59:38 | alex92 | uh why do they need it |
| 12:59:49 | FromGitter | <zacharycarter> so we can get people addicted to our game and make more money of course |
| 13:00:39 | alex92 | ugh |
| 13:00:48 | alex92 | capitalism |
| 13:01:40 | FromGitter | <zacharycarter> I'm just glad I don't have to make the decision whether they get added or not. I'm just the sap that gets to implement them |
| 13:04:04 | FromGitter | <zacharycarter> there's a really good South Park episode about this topic :P |
| 13:14:23 | Zevv | so how are the textures coming |
| 13:26:27 | FromGitter | <zacharycarter> they haven't started yet :P still at work |
| 13:26:37 | FromGitter | <zacharycarter> will start on them this evening I guess |
| 13:26:46 | FromGitter | <zacharycarter> probably just going to use world machine to generate them for now |
| 13:32:00 | * | hoijui joined #nim |
| 13:38:46 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 13:38:54 | * | hoijui quit (Ping timeout: 268 seconds) |
| 13:40:15 | PMunch | zacharycarter, are you dissing Salmon soup? |
| 13:40:42 | FromGitter | <zacharycarter> what? I would never do such a thing! /throws up at the thought of it |
| 13:41:00 | FromGitter | <zacharycarter> actually, joking aside, it doesn't sound THAT terrible |
| 13:41:06 | FromGitter | <zacharycarter> but fishy soup, I just don't know |
| 13:41:43 | PMunch | It's super good :) |
| 13:41:53 | FromGitter | <zacharycarter> I will at least try it before I leave Finland |
| 13:42:12 | PMunch | Norway is a huge producer of salmon, and we eat quite a bit of it |
| 13:42:22 | PMunch | A nice creamy salmon soup, yum! |
| 13:43:24 | FromGitter | <zacharycarter> I do like reindeer - I've discovered that much since getting over here |
| 13:43:34 | PMunch | Oh yeah, that's super tasty as well |
| 13:43:45 | FromGitter | <zacharycarter> poor Rudolph |
| 13:44:01 | PMunch | Haha, you don't eat the red-nosed ones |
| 13:44:06 | FromGitter | <zacharycarter> :P |
| 13:45:41 | PMunch | You should try the pickled fish as well, it's really good :) |
| 13:45:51 | FromGitter | <zacharycarter> now you're pushing it haha |
| 13:46:14 | PMunch | Haha, I haven't even gotten to the good ones yet |
| 13:46:28 | PMunch | Here in Norway we have all sorts of weird fish dishes |
| 13:48:17 | * | ZORR0W joined #nim |
| 13:49:23 | FromGitter | <zacharycarter> something about Scandinavia.... |
| 13:56:07 | Zevv | Do people here abuse tuples for multiple assignments? I find myself often typing things like ` var (fg, bg) = (fgDefault, bgDefault)` |
| 13:57:01 | * | floppydh quit (Quit: WeeChat 2.5) |
| 13:57:17 | * | floppydh joined #nim |
| 13:57:33 | PMunch | Zevv, I've never seen that being used before :P |
| 13:58:00 | Zevv | oh :) |
| 14:00:21 | * | lkw quit (Quit: ZNC 1.7.3 - https://znc.in) |
| 14:00:35 | * | laaron joined #nim |
| 14:01:17 | lqdev[m] | Zevv: too much Lua :P |
| 14:02:09 | Zevv | I love it :) |
| 14:02:25 | Zevv | I'd even more love it if I could drop the parentheses! |
| 14:05:28 | * | PMunch quit (Remote host closed the connection) |
| 14:05:48 | * | ng0 quit (Ping timeout: 260 seconds) |
| 14:06:12 | * | ng0 joined #nim |
| 14:06:43 | * | absolutejam1 quit (Ping timeout: 245 seconds) |
| 14:09:38 | * | lnx quit (Quit: leaving) |
| 14:09:53 | ldlework | I use tuples in C# but not for simply renaming two variables. |
| 14:10:40 | * | hoijui joined #nim |
| 14:10:54 | * | absolutejam1 joined #nim |
| 14:14:29 | Zevv | its not renaming, its assignment: var (a, b) = (42, "foobar") |
| 14:14:56 | shashlick | why do C/C++ libraries give random names to the compiled .so and .a files |
| 14:18:56 | * | lkw joined #nim |
| 14:26:21 | * | cgfuh joined #nim |
| 14:27:37 | Zevv | how do you mean, random names? |
| 14:28:08 | Zevv | the symbols in the file, or really the file names? |
| 14:35:05 | disruptek | Zevv: tuple destructuring... i use it sparingly; i'm not sure i trust destructuring without names, because tuples feel like objects in nim versus, say, python. |
| 14:35:43 | disruptek | btw, i just played with duc for the first time last night. cute! but, ncurses mode crashes for me for some reason. |
| 14:39:15 | disruptek | i guess what i really mean is that i'm not sure when and why to use tuples, unlike in python. i use them because they are the most minimally complex type that i need, but their semantics still seem hit-and-miss. |
| 14:40:04 | leorize | I just use tuple when I need the deconstruction semantics of it |
| 14:40:13 | alex92 | i use them when i dont really care for the object |
| 14:40:20 | alex92 | e.g. i just use it in one place |
| 14:40:23 | alex92 | in a big structure |
| 14:40:24 | shashlick | @Zevv - zlib compiles to libz.a and libz.so in Linux but on Windows, it uses libzlibstatic.a on Windows |
| 14:40:27 | alex92 | and i dont really want to name it |
| 14:41:46 | disruptek | so why don't tuples have a `len()`? |
| 14:41:50 | leorize | shashlick: it's a mingw thing |
| 14:42:31 | leorize | on *nix the naming convention of library starts with `lib` |
| 14:42:51 | shashlick | libXYZ.[a/so] is reasonable |
| 14:42:52 | disruptek | they don't have a `fields()` and they don't have a `high()`, a `low()`, but we can access them with integer indices... i don't really get it. |
| 14:42:55 | shashlick | predictible |
| 14:43:04 | shashlick | bit libzlib => libz isn't convenient either |
| 14:43:07 | leorize | windows don't share that naming convention though |
| 14:43:19 | leorize | pretty sure you can patch things around to make it output libz |
| 14:43:45 | shashlick | ya i am improving getHeader in nimterop - needs to be generic enough to find all these random names |
| 14:44:16 | leorize | disruptek: maybe you can add them? :P |
| 14:44:28 | leorize | it seems like that all of those stuff are implementable with a macro |
| 14:45:26 | disruptek | i looked into implementing high/low and there was some kind of breakdown that gave me a good argument against it. |
| 14:50:04 | disruptek | i guess it's a lightweight stack-only multivalue for return type, primarily? i'm just guessing at the motivation... |
| 14:52:33 | * | Romanson quit (Quit: Connection closed for inactivity) |
| 14:54:19 | alex92 | i guess it doesnt really make sense |
| 14:54:26 | alex92 | because you know how long they are |
| 14:54:29 | alex92 | when you write the code |
| 14:54:41 | alex92 | except if you write a generic function using only `tuple` |
| 14:57:54 | * | cyberjpn quit (Ping timeout: 258 seconds) |
| 14:58:21 | alex92 | proc len(b: tuple): int = |
| 14:58:22 | alex92 | return b.type.arity |
| 14:58:27 | alex92 | with import typetraits |
| 14:58:30 | alex92 | gives you len |
| 14:58:50 | alex92 | i guess you can define high / low too |
| 14:58:53 | alex92 | similarly |
| 14:59:28 | disruptek | fair point. so, i guess i should submit that pr. |
| 14:59:45 | alex92 | underrated module: typetraits |
| 14:59:53 | alex92 | if its really ct-only, it should be fine |
| 15:00:01 | alex92 | yeah |
| 15:00:03 | * | nrmrn joined #nim |
| 15:00:14 | alex92 | i dont know: the core team decides |
| 15:01:39 | * | nrmrn left #nim (#nim) |
| 15:01:56 | * | lqdev[m] uploaded an image: image.png (4KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/ZYZZfROsbkDzKzfOVDxkNtgE > |
| 15:02:04 | lqdev[m] | I don't know why but I find this amusing |
| 15:03:29 | FromGitter | <awr1> nice work @zacharycarter ! |
| 15:03:32 | FromGitter | <awr1> where is the heightmap from |
| 15:05:03 | * | couven92 quit (Ping timeout: 245 seconds) |
| 15:06:09 | * | couven92 joined #nim |
| 15:07:00 | disruptek | that was useful, glad i brought it up. i've definitely changed my style wrt tuples now. |
| 15:07:43 | disruptek | ie. i won't use them without names and types. |
| 15:08:31 | * | floppydh quit (Quit: WeeChat 2.5) |
| 15:09:14 | Araq | the only good tuple is one without field names ;-) |
| 15:09:37 | * | fredrik92 joined #nim |
| 15:10:48 | FromGitter | <awr1> somewhere a C programmer is yelling in the distane: "named tuples? back in my day we called those 'structs'" |
| 15:13:07 | FromGitter | <arnetheduck> I know this might be heresy to some, but `nimbus` is talking over libp2p to a `rust` program :) https://twitter.com/paulhauner/status/1170952290469122048 |
| 15:13:25 | * | couven92 quit (Ping timeout: 246 seconds) |
| 15:16:48 | disruptek | how can i achieve a type-check like this: `for kv: KeyValueTuple in something.pairs: echo "key: " & kv.key`? should i just raise a compile-time error? |
| 15:20:39 | leorize | just let the compiler do the type check? |
| 15:20:58 | disruptek | right, but how? |
| 15:21:13 | leorize | I don't think I quite understand your problem |
| 15:21:20 | shashlick | how do you do a default initialized proc param |
| 15:21:43 | FromGitter | <mratsim> proc foo(x = default(int)) = |
| 15:22:01 | leorize | only in nim >= 0.20 |
| 15:22:06 | disruptek | the convention is `for k, v in something.pairs:` -- if i want to pass $k to something, it could be any number of types. how can i clamp it down? |
| 15:22:42 | shashlick | proc abc(xyz: proc(def) = ???) |
| 15:22:42 | leorize | `when k is type`? |
| 15:22:53 | disruptek | then, that's what i meant by manually. |
| 15:23:13 | narimiran | re tuples: i use them regularly for Cartesian coordinates. should i really switch to objects? why? |
| 15:23:36 | leorize | how often do you destruct those tuples? |
| 15:23:42 | disruptek | s/then/yeah/ |
| 15:24:21 | leorize | disruptek: I'm still not sure of what you're trying to do... |
| 15:24:24 | leorize | any example? |
| 15:24:24 | narimiran | leorize: the usage is often just `p.x`, `p.y` |
| 15:24:27 | disruptek | sure. |
| 15:25:06 | * | absolutejam1 quit (Ping timeout: 244 seconds) |
| 15:25:48 | narimiran | and if i have `seq[Point]`, i just do `sp.add (x, y)`, which i cannot do if i had use objects |
| 15:26:17 | leorize | you can `sp.add Point(x: x, y: y)` :P it's longer but it works |
| 15:26:36 | narimiran | yeah, i know i can do that, but i don't see any benefit in that |
| 15:26:57 | leorize | the biggest advantage would be better type checking |
| 15:27:16 | narimiran | are there any performance differences, or why are tuples usually no-go? |
| 15:27:17 | leorize | if you don't need that then you can just stick with tuple |
| 15:27:39 | leorize | type checking is the biggest argument against 'em |
| 15:27:56 | leorize | any perf differences would have probably been sorted out long ago |
| 15:28:22 | leorize | objects no longer have RTTI embedded by default anymore, so they are as fast as tuples can be |
| 15:29:24 | Zevv | \o/ http://zevv.nl/div/t.png |
| 15:29:35 | narimiran | ok, i guess i'll continue to use tuples in the case like above. and i'll continue to hear from others that objects are better than tuples, and i shouldn't use tuples :) |
| 15:30:09 | leorize | objects are better than tuples and you shouldn't use tuples :) |
| 15:30:22 | Zevv | deprecate tuples then! |
| 15:30:40 | leorize | Zevv: ooh, what's that? |
| 15:30:58 | leorize | a new way to write peg? :P |
| 15:31:07 | Zevv | npeg debug output |
| 15:31:22 | Zevv | ascii rendered. I'm so proud :) |
| 15:31:41 | leorize | that's dope |
| 15:32:20 | Zevv | so much time in my life I could spend on useful things instead. walking in the woods, playing with the ducks, talking to the squirrels |
| 15:40:23 | * | fredrik92 quit (Ping timeout: 268 seconds) |
| 15:42:13 | disruptek | leorize: https://gist.github.com/disruptek/2141003dc7e129fabec8bf50ad41a9da |
| 15:43:09 | disruptek | i'm so impressed by that output, zevv. i hadn't given it much thought, but i didn't have the first clue of where to begin to render that. |
| 15:43:30 | disruptek | bbiab |
| 15:47:07 | * | solitudesf quit (Ping timeout: 245 seconds) |
| 15:48:38 | leorize | disruptek: wouldn't the type of the pairs iterator let you know which type is that? |
| 15:53:42 | Zevv | disruptek: funny how few code it is, it's just boxes in boxes in boxes |
| 15:56:08 | * | solitudesf joined #nim |
| 16:00:47 | FromGitter | <yglukhov> Araq: there's an annoyance with '#' chars getting into .c filenames. It makes it hard/impossible to work with such files with make at al. Can we fix it? |
| 16:02:04 | FromGitter | <yglukhov> the '#' come from the package dir name in nimble packages like 'foo-\#head' |
| 16:04:32 | * | absolutejam1 joined #nim |
| 16:05:52 | leorize | disruptek: does the `master` branch work better than `refactoring` or it's just your pc having a rough time at that point? |
| 16:07:00 | * | hoijui quit (Ping timeout: 252 seconds) |
| 16:10:48 | Araq | yglukhov: consider it done |
| 16:11:13 | FromGitter | <yglukhov> Awesome, thanks! |
| 16:11:36 | * | Trustable joined #nim |
| 16:12:03 | leorize | wouldn't some quoting fixes the problem? |
| 16:25:26 | * | theelous3 joined #nim |
| 16:25:54 | * | hoijui joined #nim |
| 16:26:12 | disruptek | Zevv: hopefully more a testament to your design work than my naivety! |
| 16:26:43 | * | alex92 quit (Ping timeout: 245 seconds) |
| 16:27:06 | * | absolutejam1 quit (Ping timeout: 244 seconds) |
| 16:27:08 | disruptek | leorize: the type of the pairs iterator won't matter; ie. that proc could return ("foo", "bar") or ("bar", "foo") and my code won't be any wiser. |
| 16:27:38 | FromGitter | <yglukhov> leorize: well, if I'm plugging an Android.mk to android ndk build system, and it's all fine in my Android.mk, and later in deep in the android build system it all gets messed up, what should I escape? :). Point is, even if it could be escaped, I think most build systems will never consider for such edge case. |
| 16:27:43 | disruptek | btw, master doesn't seem to run out of files but i still have periodic freezes. |
| 16:27:52 | * | ZORR0W quit (Ping timeout: 268 seconds) |
| 16:28:08 | leorize | do you have any other plugins activated? |
| 16:28:17 | leorize | they might be a problem as well |
| 16:28:28 | disruptek | any idea on how to identify? |
| 16:28:42 | disruptek | nimsuggest is only using a few hundred meg of memory, fwiw. |
| 16:28:54 | Cadey | can you import nim code from a nimble script? |
| 16:29:09 | * | ZORR0W joined #nim |
| 16:29:14 | * | nsf quit (Quit: WeeChat 2.5) |
| 16:29:31 | leorize | evidence that nim.nvim is vastly superior than VSC right there lol |
| 16:29:48 | leorize | anyhow, ususally I'd use nvim's :profile |
| 16:30:03 | disruptek | i know, it's silly that a 300meg seems reasonable for this. |
| 16:31:48 | leorize | the problem with nvim :profile is that it doesn't correctly deal with async functions |
| 16:32:14 | disruptek | that's what has confused me; i really didn't think my editor could get blocked. |
| 16:32:15 | Araq | Cadey, yes, you can |
| 16:32:28 | leorize | but you can try it regardless |
| 16:34:19 | leorize | :prof start bottleneck.log |
| 16:34:26 | leorize | :prof func * |
| 16:34:45 | leorize | after you've done with your long editing session |
| 16:34:47 | leorize | :prof stop |
| 16:35:58 | leorize | note that you have to do this or else it won't write down the profiling data |
| 16:36:04 | leorize | disruptek: ^ |
| 16:36:43 | disruptek | noted, thanks for the howto. ;-) |
| 16:38:01 | disruptek | it could be gitgutter, i guess. i will know more once i trim out some runtime and profile it. |
| 16:38:27 | leorize | watch out for async procs though |
| 16:39:29 | leorize | they won't have their `execution count`, and the runtime will be huge, but that's just due to how often they execute |
| 16:40:05 | shashlick | what are potentially the top 5 C/C++ libraries of interest in the Nim community |
| 16:41:03 | narimiran | disruptek: can you share the list of the plugins you use in neovim? |
| 16:41:16 | disruptek | sure. |
| 16:42:12 | disruptek | https://gist.github.com/disruptek/b40d588a8cacd22313484dc94e4d8b1d |
| 16:43:30 | narimiran | and the problem is slowness/stuttering? |
| 16:44:00 | disruptek | periodic input freezes for a few seconds. |
| 16:44:01 | leorize | I'd blame having both syntastic and ale :P |
| 16:44:06 | narimiran | yep, had that before |
| 16:44:20 | narimiran | and my blame guess goes to deoplete |
| 16:44:31 | disruptek | well, those are both off, so we'll see. |
| 16:46:10 | narimiran | i remember those situations getting on my nerves, i decided to remove all plugins and then enable them one by one, until i had minimum number of plugins that gave me just enough of the functionality. i probably now use 40% less plugins than back then |
| 16:46:16 | disruptek | i mean, i don't run all of these. if i move away from a module, i don't necessarily remove the tree; i'll just -x it so i can bring it back in without editing anything. |
| 16:46:59 | narimiran | and gitgutter is currently enabled for me, and i don't have these hiccups |
| 16:48:22 | disruptek | cool, that helps. i hated to give that up even for an hour. |
| 16:49:08 | narimiran | yeah, start with disabling powerline/airline - i'm sure you can live without them :) |
| 16:49:39 | leorize | i got lazy setting them up and I lived without them since :P |
| 16:55:47 | disruptek | thing is, i think it's only on buffer writes. but, we'll see if disabling most stuff changes behavior. |
| 16:57:41 | disruptek | shashlick: good question, what have you come up with so far? |
| 17:06:14 | shashlick | i'm trying to make getHeader robust - so far i've gotten liblzma and zlib working with it |
| 17:06:20 | shashlick | i want more test cases to add |
| 17:06:27 | * | absolutejam1 joined #nim |
| 17:07:56 | disruptek | search github for `embedded`, choose C or C++ language, sort by stars. |
| 17:13:58 | disruptek | i guess the solution tuples is to have `proc fun(y: TupleTypeFoo) = discard; for x in foo.pairs: x.fun` |
| 17:17:37 | * | abm joined #nim |
| 17:18:23 | disruptek | updated solution: https://gist.github.com/disruptek/2141003dc7e129fabec8bf50ad41a9da |
| 17:18:48 | shashlick | @disruptek - library seems to give more interesting matches - https://github.com/search?l=C&o=desc&q=library&s=stars&type=Repositories |
| 17:19:19 | disruptek | i would love some kind of embedded db i could build on. |
| 17:20:12 | disruptek | shashlick: dear imgui? |
| 17:31:13 | FromGitter | <brentp> I am using `countSetBits` heavily in some code. I get a major (~4X) speedup using `--passC:"-mpopcnt"` compared to the same code and workload without that flag. Is this expected? |
| 17:31:42 | * | absolutejam1 quit (Ping timeout: 245 seconds) |
| 17:35:52 | shashlick | @disruptek - there's one being maintained here - https://github.com/nimgl/nimgl/blob/master/src/nimgl/imgui.nim |
| 17:36:31 | disruptek | yeah, i couldn't remember. well, that's great. :-) |
| 17:39:12 | FromGitter | <zacharycarter> @awr1 thanks! it's from the BGFX example: https://github.com/bkaradzic/bgfx/blob/master/examples/runtime/textures/dmap.png |
| 17:39:38 | FromGitter | <zacharycarter> shouldn't be hard to generate my own though I would imagine |
| 17:51:31 | Zevv | brentp: it is not surprising, popcnt is doing just that |
| 17:52:27 | Zevv | although I'd expect it to automatically deduce it should use popcnt. That is your platform? |
| 17:52:39 | FromGitter | <brentp> I just figured that instruction was common (old) enough that I wouldn't need any march stuff. |
| 17:53:10 | Zevv | well, Nim does not hardcode that instruction, but it has fast paths for common compiler intrinsics |
| 17:53:36 | Zevv | builtin_popcnt32() etc, but there are some checks to see if your platform supports that. Thus my question, what is your platform? |
| 17:54:12 | FromGitter | <brentp> gcc 5.X on linux |
| 17:54:26 | Zevv | hm that should be just fine. let me see if I can reproduce |
| 17:55:44 | Zevv | right, reproducable indeed |
| 17:56:10 | Zevv | 6.4 times faster |
| 17:56:44 | disruptek | that kind of a speedup could be a breaking change. 😛 |
| 17:56:47 | FromGitter | <brentp> `useGCC_builtins` is defind for me too. |
| 17:57:13 | FromGitter | <mratsim> popcnt flag is for Pentium 4+ |
| 17:57:14 | FromGitter | <brentp> out of curiosity, how'd you reproduce? |
| 17:57:16 | Zevv | yeah, I checked and it actually uses the intrinsic. But maybe gcc is not allowed to emit unless the mpopcnt is specified |
| 17:57:30 | Zevv | http://ix.io/1UGo |
| 17:57:44 | FromGitter | <mratsim> I think most old CPU have pop count but the hardware flag was not exposed since pentium 4 |
| 17:57:59 | Zevv | nim c -d:danger t.nim && time ./t && nim c -d:danger --passC:-mpopcnt t.nim && time ./t |
| 17:58:04 | FromGitter | <mratsim> Also nice article: https://vaibhavsagar.com/blog/2019/09/08/popcount/ |
| 17:58:11 | FromGitter | <mratsim> you need -d:release in there as well |
| 17:58:26 | FromGitter | <brentp> cheers. |
| 17:58:56 | Zevv | -march=native is always nice |
| 17:59:50 | FromGitter | <brentp> I am implementing this: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3025716/ I had it as naive loops, converting to bitops+popcnt makes it ~30X faster for 600 samples. |
| 18:00:11 | FromGitter | <brentp> yeah. I first found the speedup with march=native. then figured it was popcnt that was making the difference. |
| 18:00:41 | Zevv | mratsim: ah that was on HN today :) |
| 18:00:49 | * | alex92 joined #nim |
| 18:01:31 | Zevv | brentp: but still, interesting that gcc does not dare to emit that by default. We should consider adding a note to the countSetBits() docs |
| 18:01:53 | FromGitter | <brentp> yeah, I saw that same thing @mratsim, which prompted my recent dev here: https://github.com/brentp/somalier/blob/popcount/src/somalierpkg/bitset.nim#L38-L52 |
| 18:01:57 | FromGitter | <mratsim> atually it’s in x86 only since Nehalem so 2009? |
| 18:02:19 | FromGitter | <brentp> @Zevv sounds good |
| 18:06:45 | * | fjellfras joined #nim |
| 18:09:44 | * | rockcavera quit (Remote host closed the connection) |
| 18:15:05 | FromGitter | <zacharycarter> I wish there was something easier than world machine to generate a splat map for this heightfield |
| 18:16:21 | * | rockcavera joined #nim |
| 18:19:58 | FromGitter | <yglukhov> Araq: recent nim produces c files like `..@..@[email protected]@pkgs@x11-#head@[email protected]` (note the leading dots). That's something undesired as well :) |
| 18:21:13 | FromGitter | <yglukhov> in fact what is the reason to prepend "..@..@[email protected]@pkgs@" whereas it could be just x11? |
| 18:26:27 | * | wildtrees joined #nim |
| 18:27:09 | leorize | to support that fancy multiple nimble package version feature? |
| 18:27:25 | * | wildtrees quit (Max SendQ exceeded) |
| 18:30:29 | * | nif quit (Quit: ...) |
| 18:30:38 | * | nif joined #nim |
| 18:35:27 | * | hoijui quit (Ping timeout: 245 seconds) |
| 18:40:07 | FromGitter | <yglukhov> huh? Is it even considered to be supported now? I thought it's not gonna happen in the nearest time. |
| 18:41:14 | Araq | modules of the same name within the same nimble package are supported now |
| 18:41:45 | Araq | (there is at least one bug left, of course... *Sigh*) |
| 18:42:08 | * | alex92 quit (Ping timeout: 245 seconds) |
| 18:42:33 | FromGitter | <yglukhov> right, i know that. but why this long prefix? it should be the inner-path to disambiguate, which there is I think. but the prefix doesn't seem to be needed |
| 18:44:45 | Araq | I don't know either |
| 18:44:51 | Araq | need to investigate |
| 18:45:03 | Zevv | zacharycarter: world machine? |
| 18:50:26 | FromGitter | <zacharycarter> https://www.world-machine.com/ |
| 18:51:03 | FromGitter | <awr1> world machine is cool, i've used it before |
| 18:52:33 | * | vesper11 quit (Ping timeout: 245 seconds) |
| 18:53:56 | FromGitter | <awr1> @mratsim "I think most old CPU have pop count but the hardware flag was not exposed since pentium 4" |
| 18:53:59 | FromGitter | <awr1> the final word in detecting ISA extension coverage: execute newer instructions and capture potential SIGILL :P |
| 18:54:17 | * | thomasross joined #nim |
| 18:57:46 | * | ZORR0W quit (Ping timeout: 246 seconds) |
| 18:59:57 | * | rockcavera quit (Remote host closed the connection) |
| 19:00:00 | * | absolutejam1 joined #nim |
| 19:11:47 | * | rockcavera joined #nim |
| 19:11:48 | * | Arrrrrr joined #nim |
| 19:12:37 | Arrrrrr | So, I have a stupid question: what about passing -DNDEBUG when assertions are disabled? |
| 19:13:53 | Arrrrrr | I mean, should it be defined in the general nim.cfg? |
| 19:14:23 | * | rockcavera quit (Remote host closed the connection) |
| 19:17:27 | Araq | why? Nim's assertions are not C's assertions |
| 19:19:59 | Arrrrrr | But they server the same goal. I don't know much C, recently I got into looking what information is packed into the binary and found out that the full path appeared there, including my name. I had no idea how to remove that until I learned about assert.h |
| 19:20:34 | Arrrrrr | Not a big deal, but got me thinking that, since they are roughly the same (C asserts and nim asserts), maybe the could be both disabled at the same time. |
| 19:24:34 | FromGitter | <akavel> Hi! A newbie question: I have a function `foo` generating a hierarchy of nested `ref object`-s; I am writing a test for the function, but `check foo() == Hierarchy(of: Nested(obje: Cts))` fails, because == comparison on ref objects returns false for distinct objects (IIUC). How can I do a "deep equal" comparison on them? Should I redefine the == operator on each ref object in the hierarchy? |
| 19:30:00 | * | absolutejam1 quit (Ping timeout: 244 seconds) |
| 19:30:06 | * | absolutejam2 joined #nim |
| 19:30:40 | FromGitter | <awr1> normally i would suggest `foo()[] == Hierarchy(of: Nested(obje: Cts))[]` but i have a feeling that won't work, because you need to compare the whole tree |
| 19:33:06 | FromGitter | <awr1> what you may end up having to do is recursion, where the base case has no children. |
| 19:33:17 | * | nif quit (Quit: ...) |
| 19:33:26 | * | nif joined #nim |
| 19:34:49 | FromGitter | <akavel> @awr1 For the recursion I would need to compare field by field anyway, no? as the fields containing `ref object`s will always be different anyway, so x[] == y[] won't work anyway, I suppose? |
| 19:35:50 | FromGitter | <mratsim> implement == for your objects |
| 19:35:58 | FromGitter | <mratsim> ref object* |
| 19:36:00 | FromGitter | <awr1> if you don't want to compare field by field make the data contained within the hierarchy type a special object type of its own |
| 19:36:07 | FromGitter | <awr1> and then check that recursively |
| 19:37:50 | FromGitter | <akavel> @awr1 No, can't do, the syntax of the hierarchy is aimed at ease of writing, adding artificial nesting would make it much uglier |
| 19:38:36 | FromGitter | <akavel> @mratsim ok, thanks; maybe for objects will be actually enough, then I could do x[] == y[] and hopefully it would work? |
| 19:38:39 | Araq | akavel: it's better to use a different name, usually, like 'equals' or some new operator like '==*' |
| 19:39:01 | FromGitter | <akavel> Araq: Ok, thanks! |
| 19:39:03 | FromGitter | <awr1> you can use a macro to generate getters for the data so that you don't have to type `hierarchy.data.someField`, rather just `hierarchy.someField` |
| 19:39:08 | FromGitter | <awr1> *getters + setters |
| 19:40:15 | FromGitter | <awr1> alternatively you can just do what you were doing previously and iterate through the fields |
| 19:40:19 | FromGitter | <akavel> @awr1 If Araq says equals, so it will be ;) and actually this will potentially make it more reusable for other tests, at different levels of the hierarchy. |
| 19:40:26 | FromGitter | <awr1> and test each |
| 19:40:50 | FromGitter | <akavel> Thanks everybody! |
| 19:41:19 | * | vesper11 joined #nim |
| 19:42:13 | * | fjellfras quit (Quit: Leaving) |
| 19:57:59 | * | Arrrrrr quit (Remote host closed the connection) |
| 20:18:53 | Zevv | Is there a way to profile compile-time code, and some hints for performance tuning? |
| 20:23:20 | * | alex92 joined #nim |
| 20:23:30 | FromGitter | <alehander42> @akavel i think you shouldn't redefine it |
| 20:23:33 | FromGitter | <alehander42> for each ref |
| 20:23:38 | FromGitter | <alehander42> just overload it for T |
| 20:23:40 | FromGitter | <alehander42> and reuse == |
| 20:23:46 | FromGitter | <alehander42> and again for ref T |
| 20:23:54 | FromGitter | <alehander42> but i might be mistaken? |
| 20:24:08 | FromGitter | <alehander42> e.g. equals[T] .. |
| 20:24:50 | FromGitter | <alehander42> equals(a: ref T, b: ref T) ? |
| 20:28:14 | * | rockcavera joined #nim |
| 20:32:30 | skrylar[m] | i did recently abuse some comparison operators for building constraint objects |
| 20:35:30 | * | absolutejam3 joined #nim |
| 20:36:07 | * | absolutejam2 quit (Ping timeout: 246 seconds) |
| 20:37:08 | FromGitter | <alehander42> oh, how did it look! |
| 20:37:52 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 20:39:08 | * | Ven`` joined #nim |
| 20:50:22 | * | nsf joined #nim |
| 20:50:33 | * | narimiran quit (Ping timeout: 258 seconds) |
| 20:57:39 | * | nsf quit (Quit: WeeChat 2.5) |
| 20:58:20 | * | Trustable quit (Remote host closed the connection) |
| 20:59:03 | * | krux02 quit (Remote host closed the connection) |
| 21:01:21 | * | nif quit (Quit: ...) |
| 21:01:30 | * | nif joined #nim |
| 21:09:31 | * | btop joined #nim |
| 21:12:52 | * | solitudesf quit (Ping timeout: 246 seconds) |
| 21:25:58 | FromGitter | <mratsim> @Zevv, compile-time code? like you are running compute intensive code in the VM? |
| 21:42:41 | * | Kaivo quit (Quit: WeeChat 2.5) |
| 21:48:47 | * | cornfeedhobo quit (Ping timeout: 245 seconds) |
| 21:54:38 | * | absolutejam3 quit (Ping timeout: 245 seconds) |
| 22:01:28 | * | ng0 joined #nim |
| 22:05:03 | * | cornfeedhobo joined #nim |
| 22:08:19 | * | a_b_m joined #nim |
| 22:11:40 | * | abm quit (Ping timeout: 246 seconds) |
| 22:13:10 | * | absolutejam3 joined #nim |
| 22:14:09 | * | Vladar quit (Remote host closed the connection) |
| 22:15:03 | * | alex92 quit (Ping timeout: 268 seconds) |
| 22:24:11 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:24:46 | * | Ven`` joined #nim |
| 22:24:58 | * | Ven`` quit (Client Quit) |
| 22:25:09 | * | absolutejam3 quit (Ping timeout: 244 seconds) |
| 22:47:16 | * | skrylar[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/ILBbCNPnyhOzdyFtKKOfwBDk > |
| 22:48:23 | skrylar[m] | theres some procs so trying to add/sub will wrap variables in terms, comparing terms creates the constraint object, which might also flip the terms / rearrange them based on what the simplex can actually solve, and then when added it does the rest |
| 22:48:48 | skrylar[m] | non-linear stuff it just won't let you do, because you can't anyway |
| 22:49:14 | FromGitter | <gogolxdong> Hongkong is unstable right now, probably will last. |
| 22:59:38 | * | btop quit (Ping timeout: 245 seconds) |
| 23:15:18 | * | ZORR0W joined #nim |
| 23:35:41 | * | Jjp137 quit (Read error: Connection reset by peer) |
| 23:36:15 | * | Jjp137 joined #nim |
| 23:39:06 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 23:39:31 | * | MightyJoe quit (Ping timeout: 246 seconds) |
| 23:39:50 | * | cyraxjoe joined #nim |
| 23:43:53 | rockcavera | How do I import this package if it has same name as a standard package? |
| 23:43:58 | rockcavera | https://nimble.directory/pkg/random |
| 23:51:47 | * | a_b_m quit (Quit: Leaving) |
| 23:52:08 | * | abm joined #nim |
){kind=link}
