| 00:03:15 | * | yglukhov quit (Remote host closed the connection) |
| 00:03:49 | * | yglukhov joined #nim |
| 00:08:18 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 00:24:11 | ipjk | Because it creates seprate blocks. |
| 00:25:34 | * | radagast quit (Remote host closed the connection) |
| 00:26:06 | * | radagast joined #nim |
| 00:27:50 | FromGitter | <Quelklef> That explains why it's not complaining about redefinitions now, but how does the block return `returnproc`? |
| 00:28:03 | FromGitter | <Quelklef> *how does it return `returnproc` from inside the block? |
| 00:29:12 | * | devdri quit () |
| 00:31:20 | * | yglukhov joined #nim |
| 00:35:45 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 00:47:07 | ipjk | I figured it out |
| 00:48:32 | ipjk | Quelklef: https://pastebin.com/HWciiuvu |
| 00:48:53 | FromGitter | <Quelklef> oh, awesome! thanks1 |
| 00:49:35 | FromGitter | <Quelklef> any idea why it works? |
| 00:49:46 | ipjk | I'm not sure, but I think it was converted to something like; proc () = echo "World"() |
| 00:49:58 | FromGitter | <Quelklef> Wait, not working for multi-lined procs D: |
| 00:50:07 | FromGitter | <Quelklef> I should have specified |
| 00:50:19 | ipjk | This makes it into (proc () = echo "World")() |
| 00:51:12 | FromGitter | <Quelklef> but what it was complaining about was redefinitions |
| 00:53:10 | ipjk | You mean multi-line, like this? |
| 00:53:10 | ipjk | https://pastebin.com/F418RJF6 |
| 00:54:12 | FromGitter | <Quelklef> Wait, why was it not working for me then...? |
| 00:54:39 | ipjk | Did you put the first echo on the same line as proc () =? |
| 00:55:29 | FromGitter | <Quelklef> no, indentation is fine |
| 00:56:05 | FromGitter | <Quelklef> my usecase has also changed slightly, so I'm gonna stick with the `block` solution. Thanks, though! |
| 00:56:16 | ipjk | No worries, was fun. |
| 01:00:40 | * | ipjk quit (Read error: Connection reset by peer) |
| 01:05:51 | FromGitter | <zacharycarter> Cleaned up the Nim playground, added a cron job to take care of the cause of it going down |
| 01:06:00 | FromGitter | <zacharycarter> hopefully it's no longer an issue |
| 01:06:48 | * | yglukhov joined #nim |
| 01:10:57 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 01:24:58 | * | vivus quit (Quit: Leaving) |
| 01:25:43 | * | xkapastel joined #nim |
| 01:29:10 | skrylar | i wonder if those playground servers actually help language adoption |
| 01:31:09 | FromGitter | <honewatson> @zacharycarter thanks! |
| 01:47:58 | FromGitter | <zacharycarter> np |
| 01:48:36 | FromGitter | <zacharycarter> off topic - but does anyone here have any experience with blockchain? |
| 01:48:57 | FromGitter | <zacharycarter> or know a lot about it? |
| 01:50:17 | FromGitter | <Quelklef> you're not making a NimCoin, are you? |
| 01:51:03 | * | icebattle quit (Quit: leaving) |
| 01:51:25 | * | obadz quit (Quit: WeeChat 1.9.1) |
| 01:51:26 | FromGitter | <zacharycarter> no |
| 01:51:54 | FromGitter | <Quelklef> phew |
| 01:52:12 | FromGitter | <zacharycarter> I'm more interested in record storage |
| 01:53:06 | FromGitter | <zacharycarter> I work for carfax (no idea if you've heard of the company or not) but we have lots of data about cars. We have a hackathon coming up and I was curious about maybe storing vehicle records in a blockchain |
| 01:53:51 | FromGitter | <Quelklef> That.... Sounds interesting |
| 01:54:13 | FromGitter | <zacharycarter> one complexity right off the bat is that our records aren't immutable |
| 01:54:26 | FromGitter | <zacharycarter> so I'd probably have to use something like ethereum's smart contracts |
| 01:54:49 | FromGitter | <zacharycarter> but I really have no idea how I'd get started / how I'd approach it, that's why I was asking really |
| 01:55:02 | FromGitter | <Quelklef> already sounds like you know more than I do about this, don't think I can help : P |
| 01:55:52 | FromGitter | <zacharycarter> another idea I have for the hackathon is to leverage ML in some capacity using our data |
| 01:57:44 | FromGitter | <zacharycarter> the first idea that came to mind, and the one I'm planning on going with, unless another pops up is - building a recommendation engine that pairs a consumer to dealerships based on search history, etc... and one that takes into consideration, historical dealer inventory, and best matches a car to a dealer |
| 02:01:04 | FromGitter | <Quelklef> sounds rather pragmatic for a hackathon |
| 02:03:18 | FromGitter | <zacharycarter> well I don't really have any barnburners to show off at the moment |
| 02:04:24 | FromGitter | <zacharycarter> our company has embarrassingly done squat with ML so far |
| 02:04:32 | FromGitter | <zacharycarter> so I figure any step in that direction is a good one |
| 02:05:02 | FromGitter | <Quelklef> Oh my, it took me until now to realize you're saying "machine learning" |
| 02:05:07 | FromGitter | <Quelklef> Yeah, that sounds like an interesting idea |
| 02:05:09 | FromGitter | <Quelklef> in that case |
| 02:05:30 | FromGitter | <zacharycarter> haha :P my bad |
| 02:06:27 | FromGitter | <Quelklef> I thought you meant the programming language, oops |
| 02:06:38 | FromGitter | <Quelklef> I was like "why does your company care so much about using a specific lang..." |
| 02:08:18 | * | couven92 quit (Ping timeout: 240 seconds) |
| 02:20:44 | yunfan | hey, do you have FUSE relevant library ? |
| 02:25:16 | * | S1t1Schu joined #nim |
| 02:28:49 | * | S1tiSchu quit (Ping timeout: 248 seconds) |
| 02:31:54 | * | chemist69 quit (Ping timeout: 252 seconds) |
| 02:46:16 | * | chemist69 joined #nim |
| 02:51:57 | * | radagast quit (Quit: radagast) |
| 02:52:13 | * | radagast joined #nim |
| 02:52:58 | * | yglukhov joined #nim |
| 02:53:55 | radagast | Just Microsoft things http://imgshare.free.fr/uploads/28bfd33c7f.png |
| 02:55:38 | FromGitter | <Quelklef> surprisingly wholesome |
| 02:55:42 | FromGitter | <Quelklef> 👍 |
| 02:57:37 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 03:03:20 | skrylar | zacharycarter: i have some knowledge about it |
| 03:05:00 | skrylar | Blockchains are just a modern buzzword for transaction logs (cf. classical RDBMS books, https://teachyourselfcs.com/ has some recommendations) |
| 03:05:31 | skrylar | If you want a reference for a mutable record set, see Namecoin. If you want to see consensus without hashing or proofs, see Tindermint. |
| 03:07:50 | yunfan | skrylar: you are right, but these buzzword take us much peers than transaction does |
| 03:08:02 | FromGitter | <honewatson> > Blockchains are just a modern buzzword for transaction logs - nice definition |
| 03:08:11 | yunfan | in p2p domain, there's a cold bootup problem, isnt it? |
| 03:09:09 | skrylar | honewatson: 'tis okay. all this "noSQL" stuff is just an object database that lisp/smalltalkers used :B |
| 03:09:23 | skrylar | kind of funny how we're reinventing what already existed, was claimed is unusable, but with a new PR team is the bees knees |
| 03:10:41 | skrylar | yunfan, depends on the scope of the p2p system |
| 03:10:54 | skrylar | the real research is the proof of work and stake systems |
| 03:18:38 | yunfan | skrylar: tell me a success p2p network founded recently ? |
| 03:39:44 | shashlick | zacharycarter: interesting, I just spent the evening discussing blockchain and it's applications |
| 03:52:48 | FromGitter | <jamesalbert> I'm having an issue with websocket.nim, I've been tweeking it for the past few days with no luck. It's all described here https://github.com/niv/websocket.nim/issues/27 If someone could take a look, I have a feeling it's a bug in either websocket.nim or the net module, but I'm not sure. |
| 03:54:32 | FromGitter | <jamesalbert> I'm mostly looking for confirmation from somebody, I'm able to connect with every other websocket library and it looks like they're all sending the same request |
| 04:01:07 | * | dddddd quit (Remote host closed the connection) |
| 04:05:25 | skrylar | sometimes i wonder if you could use ML to optimize code instead of the big piles of passes |
| 04:05:31 | skrylar | my guess is "yes but it's not worth it" |
| 04:09:26 | FromGitter | <jamesalbert> rule #1 of optimization club: you do not optimize. |
| 04:11:49 | skrylar | have been working with hidden markov models lately and they have a sequence-to-sequence setup, was pondering about "code to code" using that |
| 04:16:23 | FromGitter | <jamesalbert> brings me back to college days, oh how I failed those courses :) |
| 04:16:44 | skrylar | i do okay at ML, just takes a lot of staring and errors |
| 04:19:38 | FromGitter | <jamesalbert> Yeah, a little not-hotdog clone is the closest I've come to doing anything ML |
| 04:21:05 | FromGitter | <jamesalbert> you don't by chance have any extensive knowledge of websockets, do you? ;) |
| 04:22:09 | FromGitter | <Yardanico> It seems pineapple fund wasn't fake - https://www.fsf.org/news/free-software-foundation-receives-1-million-donation-from-pineapple-fund |
| 04:22:38 | FromGitter | <Yardanico> https://pineapplefund.org/ |
| 04:34:12 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 04:35:09 | skrylar | jamesalbert: i've never used a websocket |
| 04:46:59 | FromGitter | <jamesalbert> it's all good, I can't seem to connect to this host using nim |
| 04:48:04 | FromGitter | <jamesalbert> python, bash connects fine, but not websocket |
| 04:52:00 | * | yglukhov joined #nim |
| 04:56:05 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 05:12:49 | * | tinAndi joined #nim |
| 05:18:18 | * | tinAndi quit (Ping timeout: 240 seconds) |
| 05:33:02 | * | radagast quit (Quit: radagast) |
| 05:38:38 | FromGitter | <Varriount> @jamesalbert Have you inspected the packets being sent? |
| 05:51:20 | * | yglukhov joined #nim |
| 05:55:48 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 06:04:22 | * | gokr joined #nim |
| 06:25:11 | * | cyraxjoe joined #nim |
| 06:25:18 | * | nsf joined #nim |
| 06:38:47 | * | yglukhov joined #nim |
| 06:43:31 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 06:51:10 | Araq | jamesalbert: websockets don't work for me either -.- |
| 07:43:48 | * | c0ntribut0r quit (Ping timeout: 240 seconds) |
| 07:44:55 | * | c0ntribut0r joined #nim |
| 07:45:28 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 08:00:41 | * | c0ntribut0r quit (Read error: Connection reset by peer) |
| 08:02:20 | * | c0ntribut0r joined #nim |
| 08:02:56 | * | PMunch joined #nim |
| 08:14:23 | * | Vladar joined #nim |
| 08:16:37 | * | devdri joined #nim |
| 08:17:15 | * | devdri quit (Client Quit) |
| 08:19:43 | * | PMunch quit (Quit: Leaving) |
| 08:21:19 | * | PMunch joined #nim |
| 08:25:29 | * | yglukhov joined #nim |
| 08:29:35 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 08:41:48 | FromGitter | <honewatson> @Araq Is there a Nim Software Foundation? Maybe you could get million to pay core team salaries from the pineapple fund? |
| 08:42:35 | FromGitter | <honewatson> theres still $50 million elft |
| 08:45:50 | FromGitter | <Bennyelg> :D |
| 08:46:56 | PMunch | I wonder how they choose how much the different causes get |
| 08:50:10 | Araq | no Foundation. seems to be much work to set one up. |
| 08:57:44 | yunfan | should fsf spent the money now or hold for a while ? |
| 08:57:50 | yunfan | waiting for the price rising :D |
| 09:00:52 | FromGitter | <andreaferretti> @Araq My worry - and I think other users will agree - is that when v1 is out most work will be done in the new runtime/v2 thing |
| 09:01:11 | FromGitter | <andreaferretti> While the very reason people are waiting for a v1 is to have a stable environment for a while |
| 09:01:44 | FromGitter | <andreaferretti> There should be at least a few years where v1 is promoted and made as stable as possible |
| 09:01:44 | Araq | with the trunk based model bugfixes automatically land in 1.0.x too |
| 09:02:15 | FromGitter | <andreaferretti> Yes, but it's a trust issue - why bother writing libraries and contributing to the ecosystem using a GC |
| 09:02:31 | FromGitter | <andreaferretti> knowing that it all will need to be reworked with the new model |
| 09:02:51 | FromGitter | <andreaferretti> v1 is about the promise that work done today will not be wasted |
| 09:03:08 | FromGitter | <andreaferretti> starting v2 as soon as v1 is out is the opposite of that |
| 09:03:29 | * | gmpreussner quit (Ping timeout: 248 seconds) |
| 09:03:55 | PMunch | How much of a rewrite would it be anyways? |
| 09:04:07 | PMunch | I saw you guys talking about it when I was on briefly yesterday |
| 09:04:13 | FromGitter | <alehander42> would there be a need to rework? I think most v1 code should be able to run correctly on v2, otherwise you're just writing a new language |
| 09:04:59 | PMunch | That's the impression I've gotten as well |
| 09:05:07 | FromGitter | <andreaferretti> even if it does - which is unclear today given that the destructors thing is not well specified yet |
| 09:05:12 | * | gmpreussner joined #nim |
| 09:05:18 | FromGitter | <andreaferretti> it may have performance implications |
| 09:05:34 | FromGitter | <andreaferretti> just to give an example, I read from the RFC |
| 09:05:49 | FromGitter | <alehander42> if it's mostly "v2 is even faster if you write v2-aware code", that should be fine |
| 09:05:56 | FromGitter | <andreaferretti> `Since these additions introduce many more try statements, it's wise to base this work on the C++ codegen, not the pure C codegen. Otherwise it seems unrealistic to get competitive performance.` |
| 09:06:04 | PMunch | v2s GC changes will be mostly under the hood and apart from performance heuristics changing (which only really matters in high-performance applications) there shouldn't be many changes |
| 09:06:11 | FromGitter | <andreaferretti> Just this is not a change to be made lightly |
| 09:06:29 | FromGitter | <andreaferretti> Losing the C codegen is a big change for compatibility |
| 09:06:50 | PMunch | Yeah I saw that as well, which is a bit disconcerting.. |
| 09:08:19 | miran_ | nice points, @andreaferretti! |
| 09:10:09 | GitDisc | <bahm> List comprehension is in the future module but not listed on the roadmap; is it still planned? If so, what needs to be done and how can I contribute? If not, what is an elegant alternative? |
| 09:10:37 | Araq | bahm: for loops as expressions would be better |
| 09:11:14 | miran_ | as i said yesterday, after the release of v1.0, the focus should be on (bug fixes for) v1; working on v2 should be postponed and/or not a priority. |
| 09:11:46 | Araq | andreaferretti: I could only repeat my arguments. v2 is vaporware moreso than v1 is but we need to be allowed to do experiments |
| 09:11:59 | FromGitter | <andreaferretti> of course experimenting is good |
| 09:12:10 | miran_ | otherwise, the current "i won't use nim until it hits v1" will be just transformed to "i won't use nim v1, i heard v2 is in the works, i'll wait for it" |
| 09:12:36 | FromGitter | <andreaferretti> it's just that the way things are phrased today it looks like the future of Nim is already tied to the destructor model |
| 09:12:45 | PMunch | So what we should do is just stop talking about v2? :P |
| 09:12:48 | FromGitter | <andreaferretti> which means not experimenting |
| 09:12:49 | Araq | users who don't want to use Nim always have good reasons for that |
| 09:12:57 | FromGitter | <andreaferretti> agreed |
| 09:13:10 | Araq | regardless of whether we have a plan for the future or not. |
| 09:13:11 | FromGitter | <andreaferretti> the problem is users that *do* want to use Nim :-) |
| 09:13:20 | FromGitter | <alehander42> after all I think Araq can do whatever he wants, that's his language, working on v2 seems cool, and it shouldn't scare people as far as v2 is compatible with v1 |
| 09:13:23 | miran_ | PMunch: or just focus the work on improving 1.x |
| 09:13:41 | FromGitter | <andreaferretti> Of course Araq can do whatever he likes |
| 09:13:54 | Araq | I don't understand why a clear vision for Nim can hurt it. |
| 09:13:59 | PMunch | Yeah, but we already agreed that we should be allowed to experiment with "upcoming" features |
| 09:14:10 | FromGitter | <andreaferretti> It's just that all this focus on the new model right before hitting v1 is demoralizing |
| 09:14:19 | miran_ | +1 |
| 09:14:21 | FromGitter | <alehander42> but I think it should be mostly compatible(in some aspects) and we need people to work on v1 (I guess they can be also hired with bountysource?) |
| 09:14:56 | Araq | "all this focus" is mean. easily 80% of my time is spent on the hard bugfixes. |
| 09:14:57 | miran_ | @alehander42: compatible new features should/could be part of 1.x |
| 09:15:47 | FromGitter | <andreaferretti> also, it seems like an admission of failure |
| 09:15:55 | FromGitter | <andreaferretti> yeah, we're going out with the v1 model |
| 09:16:02 | FromGitter | <andreaferretti> but it was not that good after all |
| 09:16:08 | PMunch | wasn't there some old computer comany that went out of business because the announced something like "The next version will be much faster than this one, and it's coming early next year!" so no-one bought their current product and they went out of business before they were able to release their next machine? |
| 09:16:09 | FromGitter | <andreaferretti> let us work something better in the meantime |
| 09:16:12 | FromGitter | <alehander42> of course, what I mean is "v2" doesn't have to mean "something scary which replaces v1" but "evolved version of v1" |
| 09:16:25 | FromGitter | <andreaferretti> not exactly encouraging |
| 09:16:34 | PMunch | That's the danger of being a bit too open with your roadmap :P |
| 09:16:54 | Araq | that's just the danger of a never ending release process. |
| 09:17:22 | miran_ | PMunch: i see the danger of a roadmap which looks like: now: 1.0, next: 2.0 |
| 09:17:25 | Araq | by the time v1 is out not even Araq wants it anymore, congratulations. |
| 09:17:30 | FromGitter | <alehander42> well, that can be also "v1 works quite well, but v2 should be even better at X and and at Y while still compatible", it's honestly a marketing problem, not a tech one |
| 09:17:57 | PMunch | Araq, that's true. And I support the way you work now. But for someone who haven't tried Nim before coming in here and hearing talk about a v2 before a v1 has even come out it might seem a bit unstable even in it's upcoming v1 version |
| 09:18:25 | FromGitter | <andreaferretti> the thing is, one would expect v2 to be marketed a few YEARS after v1 is out, it has been tried extensively and problems with it are clear |
| 09:18:33 | miran_ | i don't see the danger of having: 1.0, 1.0.x (bugfixes), 1.1 (new features), 1.1.1 (bugfixes), 1.2, ..., 2.0 (lots of new and breaking stuff) |
| 09:18:55 | PMunch | miran_, and I think that is "the plan" |
| 09:19:46 | FromGitter | <andreaferretti> @PMunch if that was the plan, the roadmap for v1.1 would be more clear than the on for v2 |
| 09:20:14 | miran_ | "one would expect v2 to be marketed a few YEARS after v1 is out, it has been tried extensively and problems with it are clear" --> this!!! |
| 09:20:17 | PMunch | I think people are just misunderstanding what the talk about v2 is. It's not the next version, it's just an umbrella for the stuff that won't be added to v1 (feature creep) but will probably, possibly, or maybe added to a future version (but not backported). |
| 09:20:38 | Araq | I don't see a need for a plan v1.1 |
| 09:20:50 | miran_ | Araq: that's a shame |
| 09:20:54 | PMunch | andreaferretti, problem is that the plan for v1.1 is probably "fix the bugs that crop up with v1" |
| 09:21:04 | Araq | v1.1 will add features. it's semantic versioning :-) |
| 09:21:04 | FromGitter | <andreaferretti> that is 1.0.x |
| 09:21:22 | PMunch | By the nature of it there are no new and super-exiting features with a x.1 release |
| 09:21:29 | PMunch | Oh right |
| 09:21:41 | Araq | I can tell you which features already. well no. |
| 09:21:45 | PMunch | I've gotten too used to calling Nim versions without the first number :P |
| 09:21:59 | Araq | I can tell you which will be in v2 and then can be made available for v1.1 |
| 09:22:12 | Araq | the ones that work and doesn't break things. ;-) |
| 09:22:20 | PMunch | Exactly |
| 09:22:34 | miran_ | Araq: so basically what you call "v2" is "devel"? |
| 09:22:43 | PMunch | Kinda |
| 09:22:49 | Araq | or .experimental |
| 09:22:53 | miran_ | and some of that "devel" will be in 1.1 or 1.2, and some will be in 2.0? |
| 09:23:28 | PMunch | v2 (as I understand it) is everything that works and makes the language better but can't be back-ported for compatability reasons |
| 09:23:37 | Araq | stuff is added to 2.0.x and made available to 1.1.x based on community feedback |
| 09:24:01 | miran_ | if that's the case, calling it some other name than "v2" would be much clearer and would reduce the confusion |
| 09:24:06 | Araq | stuff is removed from 2.0.x should it not work. |
| 09:24:16 | Araq | yeah that's a very good point. |
| 09:25:43 | Araq | and if v2 ends up as "useful subset of Nim without GC and depending on the C++ backend" |
| 09:26:43 | Araq | that's a good result for me. libraries can be written to be compatible with it or not. it splits the package landscape though. tough. |
| 09:26:57 | * | yglukhov joined #nim |
| 09:27:32 | FromGitter | <alehander42> those libs would be still compatible with normal Nim? |
| 09:29:01 | FromGitter | <alehander42> then it doesn't seem as such a big problem to me, it's a bit like rust without stdlib/C without glibc: e.g. if you write something specific as a kernel / optimized server etc, you know how to deal with it |
| 09:29:41 | Araq | well the library problem is a big one. libraries are more important than language features. |
| 09:30:09 | Araq | a Nim without stdlib is useful enough for me, but I doubt it will "sell" |
| 09:30:43 | euantor | There are already packages that don't work as it stands - look at the issues reported yesterday with glfw causing problems |
| 09:30:58 | euantor | No matter what happens, you'll have unmaintained and broken libraries |
| 09:31:11 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 09:31:54 | Araq | wiser is to make "v2" support all of Nim with different performance characteristics. |
| 09:32:13 | Araq | (ref becomes atomic RC'ing plus a cycle collector?) |
| 09:32:56 | * | floppydh joined #nim |
| 09:33:04 | Araq | euantor: they are unmaintained because Nim is a moving target. |
| 09:33:55 | Araq | of course this problem will always be with us |
| 09:34:01 | euantor | people also get busy and stop maintaining packages. It happens in other "stable" languages too so it's going to happen no matter what |
| 09:34:11 | Araq | of course. |
| 09:36:42 | Araq | "now that v1 is released all our efforts are spent on bug fixes" |
| 09:36:56 | PMunch | Hmm, maybe I should go through my packages and test if they still work :P |
| 09:37:00 | Araq | I can understand why people love that |
| 09:37:14 | * | yglukhov joined #nim |
| 09:37:28 | Araq | but it's more like "now that v1 is released we can have some holidays" :-) |
| 09:38:15 | Araq | and what do you do when you have holidays? work on experimental risky features, what else... |
| 09:38:19 | * | yglukhov quit (Remote host closed the connection) |
| 09:38:23 | Araq | ;-) |
| 09:38:34 | * | yglukhov joined #nim |
| 09:39:03 | euantor | I haven't yet had a release break anything beyond repair, so I'm happy with the direction things are heading so far :) |
| 09:40:13 | GitDisc | <bahm> I'm not sure I understand the full extent of the changes planned for v2, but it sounds like the design goals are different enough to warrant forking the project and calling it something else (Nim++ ^^). Of course, that's only really true if both v1 and v2 continue to be maintained/developed as with Python 2/3. |
| 09:41:03 | PMunch | Oh please, let's not do a Python 2/3 thing.. |
| 09:41:53 | Araq | C++11, C++14, C++17, Python 2/3, Java 8. |
| 09:42:05 | PMunch | It would be a shame to lose the C backend though.. |
| 09:42:14 | FromGitter | <andreaferretti> of course each language has versions |
| 09:42:20 | FromGitter | <gogolxdong> Did you release 1.0? |
| 09:42:33 | FromGitter | <andreaferretti> it's just that... well, usually they take some more time before announcing a new one :-) |
| 09:43:13 | FromGitter | <amvtek> Hi Guys, just my own 2 cents for this v2 discussion thing. |
| 09:45:40 | * | c0ntribut0r quit (Ping timeout: 252 seconds) |
| 09:45:57 | PMunch | gogolxdong, not yet |
| 09:46:36 | FromGitter | <amvtek> 1) Call v2 --> experimental so as not to decrease v1 value. |
| 09:46:52 | * | c0ntribut0r joined #nim |
| 09:47:22 | FromGitter | <amvtek> 1) Keep the C backend |
| 09:51:14 | arnetheduck | there's https://github.com/nim-lang/Nim/pull/5698 ;) |
| 09:51:34 | FromGitter | <amvtek> Right now, it looks to me we focus the effort on equalling competitor language (eg Rust) without explaining to the uninitiateds where we may already be better. |
| 09:51:36 | arnetheduck | is there a summary of the drop-c-backend discussion somewhere? |
| 09:52:28 | PMunch | arnetheduck, I don't think it's about dropping C per. se |
| 09:53:18 | PMunch | But Araq has stated that with the new no-GC stuff planned for v2(so still far off) might make the C-backend underperform because it uses try-catch much more often |
| 09:53:49 | Araq | yeah, it's about C++'s "zero cost" exception handling |
| 09:54:00 | Araq | we can get the same with the LLVM backend. |
| 09:54:47 | FromGitter | <amvtek> I see lot of value in what Nim is putting together, but as a new comer I have difficulties appreciating where it stands out. |
| 09:55:34 | PMunch | amvtek, for me what got me was probably the macro system |
| 09:56:27 | PMunch | To be able to easily wrap complex functionality into easily used interfaces is a very powerful idea |
| 09:56:28 | arnetheduck | I've been meaning to ask that btw.. is exceptions really the way to go? was thinking about implementing dwarf excepts for nlvm, but that's still far from zero cost (binary sizes, missed optimizations etc) |
| 09:57:00 | PMunch | Plus being able to write something with flexibility and ease (as with a scripting language) but still reap the benefit of a compiled language |
| 09:57:36 | FromGitter | <amvtek> We need to take what currently exists and decide which features are putting the language apart from the rest. |
| 09:57:36 | PMunch | How does C++ make "zero-cost" exceptions anyways? |
| 09:58:28 | arnetheduck | they're not zero cost.. they just cost a little less on the common, non-exception path |
| 09:58:56 | Araq | a "little"? setjmp needs to copy all register contents |
| 09:59:09 | arnetheduck | yeah, there's that |
| 09:59:28 | Araq | plus we need to make locals "volatile" because C is braindead |
| 09:59:59 | arnetheduck | that too |
| 10:00:31 | Araq | I'm currently avoiding 'try' statements as they are so expensive |
| 10:00:33 | FromGitter | <amvtek> As for me my top 3 are 1. portability (C backend! and also Javascript) 2. Type system 3. Built in Async |
| 10:01:23 | Araq | arnetheduck: Microsoft did large scale benchmarks. |
| 10:01:51 | Araq | exceptions implemented as 'if (error) goto returnBlock' vs |
| 10:02:05 | Araq | exceptions as C++ does it. |
| 10:02:28 | Araq | C++-style was 5-10% faster |
| 10:02:50 | Araq | due to better icache behaviour |
| 10:03:10 | Araq | even faster is of course 'quit' based error handling |
| 10:03:27 | livcd | I am surprised there's no malware written in Nim floating around. I bet it's a matter of time to see Mirai rewritten in Nim |
| 10:03:32 | Araq | but nobody votes for that one. |
| 10:03:33 | arnetheduck | that's interesting.. ultimately, I would get rid of them for readability reasons however.. you never know what error you're gonna get which is surprising |
| 10:04:10 | FromGitter | <amvtek> Where I believe the language is great but I am unsure how it stands compare to the competition is : 1. Memory safety (per thread heap), 2. GC approach 3. Macro system |
| 10:04:41 | arnetheduck | readability = ability to reason about the code |
| 10:04:54 | Araq | they are tracked though. |
| 10:05:07 | Araq | read the docs and see what what can throw |
| 10:05:27 | Araq | or use proc main() {.raises: [].} and see where you get |
| 10:05:44 | FromGitter | <amvtek> 1) Memory safety (? what are the plus or minus compare to Rust) |
| 10:06:37 | Araq | more of a theoretical concern right now. Nim has loopholes, we know how to fix them, we will fix them. |
| 10:07:00 | Araq | but the crashes I spend the nights with are all caused by something else |
| 10:07:24 | FromGitter | <amvtek> 1) GC approach (? plus or minus compare to Golang, D and maybe Erlang) |
| 10:08:17 | FromGitter | <amvtek> Macro system (? plus or minus compare to Rust & Lisp) |
| 10:08:50 | Araq | GC approach. many dislike the thread local heaps but it's a reasonable compromise. |
| 10:09:32 | * | skelett quit (Ping timeout: 256 seconds) |
| 10:09:59 | Araq | v2/experimental will be much better at memory sharing. |
| 10:10:06 | arnetheduck | and regarding if (error)... most embedded c++ development is done without exceptions, because of the bloat they cause |
| 10:10:42 | Araq | macro system better than anything else IMHO with more improvements yet to come. (semityped parameters) |
| 10:10:57 | arnetheduck | moving to c++ to use exceptions seems.. funny ;) |
| 10:11:25 | arnetheduck | you could probably generate c code with zero cost exceptions as well |
| 10:11:32 | Araq | how so? |
| 10:12:40 | Araq | arnetheduck: as I said, "even faster is of course 'quit' based error handling" |
| 10:13:31 | FromGitter | <amvtek> We shall clarify where we are different, where we believe we stand out and maybe vote on what are the preferred features |
| 10:15:59 | * | yglukhov quit (Remote host closed the connection) |
| 10:16:34 | * | yglukhov joined #nim |
| 10:16:44 | * | skelett joined #nim |
| 10:16:44 | * | c0ntribut0r quit (Read error: Connection reset by peer) |
| 10:17:00 | * | c0ntribut0r joined #nim |
| 10:19:38 | Araq | not sure about that. these comparisons miss the point. |
| 10:20:52 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 10:32:02 | * | mfx joined #nim |
| 10:33:40 | arnetheduck | can do `quit` for a subset of things, but you won't do that for parsing of integers from the network for example |
| 10:34:47 | * | yglukhov joined #nim |
| 10:35:13 | arnetheduck | you'll need some way to convey errors that can be handled.. and what do you pick, in a language that has exceptions and already uses them in std lib? |
| 10:36:53 | * | radagast joined #nim |
| 10:38:13 | FromGitter | <tim-st> anyone got this error before: `???(???, 0) Error: identifier expected, but found ''` ? |
| 10:38:46 | PMunch | Hmm, on the machine level why isn't a raise just implemented as a goto and catch populates a region predetermined for errors? |
| 10:38:56 | PMunch | Or rather for error handling |
| 10:41:04 | arnetheduck | that's what it is.. it's the part that establishes where the goto should go to that differs.. with setjmp, you prepare it on try entry, with dwarf, you essentially walk a stack (similar to a backtrace) based on some static data stashed away elsewhere |
| 10:42:02 | arnetheduck | it gets complicated because exceptions may traverse multiple functions or be nested etc, which makes for a very complex jump graph |
| 10:42:32 | PMunch | Hmm, that makes sense.. |
| 10:42:38 | arnetheduck | hard for the compiler to reason about when it's generating code, and hard for the programmer to reason about when they're reading |
| 10:45:48 | arnetheduck | Araq, do you have a link to that MS study? |
| 10:46:09 | * | mfx quit (Quit: Leaving) |
| 10:52:52 | arnetheduck | http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions - even compiler devs shun them |
| 10:53:42 | * | endragor joined #nim |
| 10:57:01 | FromGitter | <tim-st> I found the line now I wrote `var number: uint8: 1` instead of `var number: uint8 = 1` and the compiler couldnt trace the line |
| 10:58:23 | FromGitter | <tim-st> https://play.nim-lang.org/?gist=e548c8a6e6720e17c983c27ed46c6d96 |
| 11:00:32 | * | arnetheduck quit (Ping timeout: 256 seconds) |
| 11:05:24 | * | arnetheduck joined #nim |
| 11:05:30 | PMunch | Huh, that is a really strange bug tim-st :P |
| 11:06:07 | PMunch | By the way, you can use var number = 1'u8 as another option |
| 11:06:45 | Araq | http://joeduffyblog.com/2016/02/07/the-error-model/ |
| 11:14:49 | FromGitter | <matrixbot> `ratherAnonymous` what's the most recent verion of nim as of now? |
| 11:15:03 | FromGitter | <matrixbot> `ratherAnonymous` An article says "The library requires Nim version 0.18.0 or newer, which you can get here: https://nim-lang.org/install.html" |
| 11:15:29 | dom96 | andreaferretti's fears reflect mine |
| 11:15:32 | FromGitter | <matrixbot> `ratherAnonymous` I compiled it from github, but my version is 0.17.3 |
| 11:16:00 | dom96 | a trunk-based development model will make people fear the incoming v2 version even more |
| 11:16:19 | dom96 | ratherAnonymous: 0.17.3 is effectively 0.18.0 |
| 11:16:28 | FromGitter | <tim-st> @Araq is this not an error? Companies will keep their hands away from nimlang, if they know, that in some cases it takes the developer 15minutes to find out the line where the error came from |
| 11:17:56 | * | tinAndi joined #nim |
| 11:18:40 | * | c0ntribut0r quit (Ping timeout: 256 seconds) |
| 11:19:35 | * | c0ntribut0r joined #nim |
| 11:21:53 | Araq | „The result was the best possible configuration of the above code quality attributes: |
| 11:21:54 | Araq | No calling convention impact. |
| 11:21:54 | Araq | No peanut butter associated with wrapping return values and caller branching. |
| 11:21:55 | Araq | All throwing functions were known in the type system, enabling more flexible code motion. |
| 11:21:57 | Araq | All throwing functions were known in the type system, giving us novel EH optimizations, like turning try/finally blocks into straightline code when the try could not throw. |
| 11:21:59 | Araq | A nice accident of our model was that we could have compiled it with either return codes or exceptions. Thanks to this, we actually did the experiment, to see what the impact was to our system’s size and speed. The exceptions-based system ended up being roughly 7% smaller and 4% faster on some key benchmarks. |
| 11:22:01 | Araq | At the end, what we ended up with was the most robust error model I’ve ever used, and certainly the most performant one.“ |
| 11:22:03 | Araq | "http://joeduffyblog.com/2015/12/19/safe-native-code/ |
| 11:22:53 | Araq | tim-st: yes, Nim is doomed. because once in your lifetime it reported question marks for an obscure rare error |
| 11:23:18 | * | tinAndi quit (Ping timeout: 240 seconds) |
| 11:23:56 | FromGitter | <tim-st> Ok, but without reading this article, I know that an algorithm exists (the same that I used for error tracking) to find out the line, but it's true that it's rare (I got this error for the first time) |
| 11:24:25 | Araq | tim-st: the articles are in response to arnetheduck's question. |
| 11:24:33 | FromGitter | <tim-st> ok^^ |
| 11:24:35 | Araq | and have nothing to do with your bad error message. |
| 11:24:45 | Araq | which should be easy to fix anyway |
| 11:27:16 | FromGitter | <mratsim> I think Crystal, D and Nim need to release a common PR: "GC is not slow (if done right)": every comment on the quora thread is about GC: https://news.ycombinator.com/item?id=16270841 |
| 11:29:04 | Araq | yes, it is not slow. it uses more memory though and turns bugs into logical memory leaks. |
| 11:29:44 | Araq | and nobody ever did any study on this. |
| 11:29:56 | Araq | maybe these are easier to fix than crashes, maybe not. |
| 11:30:27 | FromGitter | <matrixbot> `ratherAnonymous` D didn't replace c++ cause noone wants to rewrite all the libraries. |
| 11:30:42 | FromGitter | <matrixbot> `ratherAnonymous` Nim can acces those libraries -> nim will replace C++ |
| 11:30:45 | FromGitter | <matrixbot> `ratherAnonymous` :D |
| 11:38:21 | radagast | D has FFI too, you know |
| 11:39:27 | radagast | Anyways. It appears that proc remove() for SinglyLinkedList is missing from the lists module https://nim-lang.org/docs/lists.html#remove,DoublyLinkedList[T],DoublyLinkedNode[T] |
| 11:39:36 | radagast | Is it intentional? |
| 11:47:26 | FromGitter | <matrixbot> `ratherAnonymous` HELP: I'm trying to download a nimble package, but I get the following error Hint: Nimble does its best to find Nim's standard library, sometimes this fails. You can set the environment variable NIM_LIB_PREFIX to where Nim's `lib` directory is located as a workaround. See https://github.com/nim-lang/nimble#troubleshooting for more info. |
| 11:47:50 | FromGitter | <matrixbot> `ratherAnonymous` I set the environment variable to this "export NIM_LIB_PREFIX=$PATH:$HOME/Nim/lib/" |
| 11:48:38 | FromGitter | <matrixbot> `ratherAnonymous` but I still get the same message |
| 11:51:18 | Araq | radagast: isn't it called 'delete' instead? |
| 11:52:44 | PMunch | ratherAnonymous, try with "export NIM_LIB_PREFIX=$HOME/Nim/lib" |
| 11:53:10 | PMunch | Don't think it searches multiple paths as it's only looking for the stdlib |
| 11:53:52 | FromGitter | <matrixbot> `ratherAnonymous` I never had to fiddle with environment variables yet. |
| 11:54:04 | FromGitter | <matrixbot> `ratherAnonymous` GNU+Linux always took care of that. lol |
| 11:54:21 | radagast | Araq: I may be looking at the wrong module but delete is for seqs, doesn't seem to exist in the module lists |
| 11:55:09 | PMunch | Why have you cloned Nim yourself by the way? |
| 11:55:26 | Araq | radagast: https://github.com/nim-lang/Nim/blob/master/lib/pure/collections/lists.nim#L262 |
| 11:55:29 | Araq | it exists. |
| 11:55:38 | Araq | but there is also compiler/lists |
| 11:55:47 | Araq | which is what the compiler uses |
| 11:56:50 | radagast | > https://github.com/nim-lang/Nim/blob/master/lib/pure/collections/lists.nim#L262 |
| 11:56:56 | radagast | Accepts doublylinkedlists |
| 11:57:07 | radagast | not slists |
| 12:00:17 | FromGitter | <matrixbot> `ratherAnonymous` On my system nimble still doesn't manage to find "system.nim" in the lib directory of the git-repository I checked out. ⏎ I now used: export NIM_LIB_PREFIX=$HOME/Nim/lib/ |
| 12:02:09 | * | yglukhov quit (Remote host closed the connection) |
| 12:02:21 | * | Snircle joined #nim |
| 12:02:29 | FromGitter | <matrixbot> `ratherAnonymous` [user@user lib]$ nimble install godot ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a71b055e217167e2c23b421] |
| 12:02:44 | * | yglukhov joined #nim |
| 12:03:39 | * | yglukhov quit (Remote host closed the connection) |
| 12:03:51 | * | yglukhov joined #nim |
| 12:12:29 | FromGitter | <dom96> ratherAnonymous: `which nim`? |
| 12:12:33 | Araq | install nimble via 'koch nimble'? |
| 12:12:54 | FromGitter | <dom96> Nice to see my brand new error message works well though :) |
| 12:13:10 | Araq | radagast: maybe because singly linked list don't support O(1) removal. |
| 12:14:17 | FromGitter | <dom96> my bet is that you have installed Nim into /usr/bin (or at least have done so previously) |
| 12:16:58 | FromGitter | <matrixbot> `ratherAnonymous` I'm basically following the instructions from this site: http://howistart.org/posts/nim/1/index.html |
| 12:16:59 | * | dddddd joined #nim |
| 12:19:57 | radagast | Araq: In https://github.com/nim-lang/Nim/blob/master/lib/pure/collections/lists.nim#L262, why aren't we adding `return` to the end of each if statement prevent further condition checking? |
| 12:22:57 | FromGitter | <matrixbot> `ratherAnonymous` I fixed my problem. I have no clue, what I did |
| 12:23:01 | FromGitter | <matrixbot> `ratherAnonymous` sorry for bothering you |
| 12:23:01 | FromGitter | <matrixbot> `ratherAnonymous` wtf |
| 12:25:00 | * | BitPuffin joined #nim |
| 12:32:44 | * | arnetheduck quit (Quit: Leaving) |
| 12:32:58 | * | arnetheduck joined #nim |
| 12:37:05 | Araq | radagast: because that would be wrong? |
| 12:37:15 | Araq | the node can the first and last at the same time |
| 12:45:49 | * | dmi0 joined #nim |
| 12:49:19 | * | leorize joined #nim |
| 12:56:58 | arnetheduck | Araq, thanks.. looks like an interesting read |
| 13:03:04 | * | yglukhov quit (Remote host closed the connection) |
| 13:03:41 | * | yglukhov joined #nim |
| 13:07:55 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 13:19:27 | * | fvs left #nim ("ERC (IRC client for Emacs 25.3.1)") |
| 13:20:57 | * | Yardanico joined #nim |
| 13:21:30 | leorize | hi |
| 13:21:52 | Yardanico | hello |
| 13:23:02 | leorize | i'm porting Nim to Haiku |
| 13:23:17 | leorize | however, I'm hitting a small issue with tests/dll/client |
| 13:24:05 | Yardanico | ah, so you want to add Haiku as a first-class OS for nim? |
| 13:24:09 | Yardanico | like linux/macos/windows? |
| 13:24:26 | Yardanico | I'm just asking because it should already work |
| 13:24:54 | leorize | I'm afraid I don't have much time to keep haiku being a first-class OS |
| 13:25:12 | Yardanico | well I mean it's already is |
| 13:25:20 | Yardanico | https://github.com/nim-lang/Nim/search?utf8=%E2%9C%93&q=haiku&type= |
| 13:25:39 | euantor | Posting the issue you're hitting and any erro message(s) might help |
| 13:25:50 | Yardanico | maybe you're using haiku with gcc 2? |
| 13:25:53 | leorize | the support is quite outdated comparing to what we support nowadays |
| 13:25:59 | Yardanico | OH |
| 13:26:02 | leorize | i'm using x86_64 |
| 13:26:03 | Yardanico | (sorry for caps) |
| 13:26:43 | leorize | Debugging shows that the test crashed due to NimTV_ being set to null |
| 13:28:17 | leorize | I traced using the C sources and found that initThreadVarsEmulation is a no-op unless you don't use nim rtl |
| 13:28:59 | leorize | which leads to the embedded NimTV_ GetThreadLocalVars to return NULL |
| 13:29:25 | leorize | causing crash in initStackBottomWith() |
| 13:32:41 | leorize | is initThreadVarsEmulation supposed to be run by libnimrtl? |
| 13:33:14 | Araq | good question. |
| 13:34:10 | Araq | can't you give Haiku real thread local storage? |
| 13:37:08 | leorize | I think we do have tls support |
| 13:37:35 | Araq | so don't enable the TLS emulation |
| 13:37:58 | leorize | except passing tlsEmulation:off doesn't change the results |
| 13:40:18 | leorize | oops, I forgot to remove the old files before re-running the tests |
| 13:41:19 | leorize | tks for help |
| 13:43:18 | * | yglukhov joined #nim |
| 13:56:03 | * | leorize quit (Quit: WeeChat 2.0.1) |
| 14:31:07 | * | Jesin quit (Quit: Leaving) |
| 14:59:13 | * | dmi0 quit (Remote host closed the connection) |
| 15:21:18 | * | c0ntribut0r quit (Ping timeout: 240 seconds) |
| 15:21:53 | * | c0ntribut0r joined #nim |
| 15:22:04 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 15:24:46 | * | Jesin joined #nim |
| 15:29:04 | * | Jesin quit (Remote host closed the connection) |
| 15:30:31 | FromGitter | <mratsim> Did someone use Halide lang for image processing? How was your experience? I'm considering writing a wrapper for it as an alternative to OpenCV. |
| 15:30:55 | * | c0ntribut0r quit (Ping timeout: 260 seconds) |
| 15:31:59 | * | endragor quit (Remote host closed the connection) |
| 15:32:18 | * | c0ntribut0r joined #nim |
| 15:36:07 | * | endragor joined #nim |
| 15:37:27 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 15:40:27 | * | endragor quit (Ping timeout: 240 seconds) |
| 15:45:12 | * | solitudesf joined #nim |
| 15:46:48 | * | arnetheduck quit (Ping timeout: 240 seconds) |
| 15:54:21 | * | Jesin joined #nim |
| 16:01:27 | * | c0ntribut0r quit (Read error: Connection reset by peer) |
| 16:02:57 | * | c0ntribut0r joined #nim |
| 16:02:58 | * | floppydh quit (Quit: WeeChat 2.0.1) |
| 16:06:52 | * | PMunch quit (Quit: Leaving) |
| 16:14:29 | trincyolo | Hi all, I'm working with someone else's NIM server and attempting to dockerise it. It all works except of the last stage: running the binary. So I just `exec` into the container and run it with `./binary` and it works. It should work ... was just wondering if this is something nim specific |
| 16:15:22 | Yardanico | trincyolo, well it shouldn't be nim specific |
| 16:15:38 | Yardanico | because nim produces normal binaries |
| 16:15:50 | Yardanico | (well, because gcc does) |
| 16:16:21 | trincyolo | okay thanks. docker just hangs at `Attaching to my_nim_bin |
| 16:17:26 | Yardanico | trincyolo, I thin this is docker related, search for in on google, there seems to be a lot of people facing the same issue |
| 16:18:24 | Yardanico | *think |
| 16:19:23 | trincyolo | thanks I am. it's just strange that my 7 other docker-compose containers don't have the issue |
| 16:21:16 | * | c0ntribut0r quit (Ping timeout: 256 seconds) |
| 16:24:36 | * | c0ntribut0r joined #nim |
| 16:28:45 | * | miran joined #nim |
| 16:34:39 | Yardanico | hooray - little, but useful! https://github.com/nim-lang/Nim/commit/60c7bbc8b7e75951b952a34051a8445592a68fc4 |
| 16:37:52 | * | yglukhov quit (Remote host closed the connection) |
| 16:38:00 | Yardanico | (it now works in vscode with nim plugin if you're wondering) |
| 16:41:10 | * | c0ntribut0r quit (Ping timeout: 240 seconds) |
| 16:41:43 | * | xkapastel joined #nim |
| 16:42:28 | * | c0ntribut0r joined #nim |
| 16:43:44 | * | yglukhov joined #nim |
| 16:48:09 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 16:48:48 | * | Trustable joined #nim |
| 17:05:50 | * | tinAndi joined #nim |
| 17:11:18 | * | tinAndi quit (Ping timeout: 240 seconds) |
| 17:13:27 | FromGitter | <tim-st> Nice! |
| 17:17:04 | FromGitter | <tim-st> When I increment a `var int` inside try except once and on the second increment it excepts, will the variable be incremented by one if passed as argument and the exception is caught? |
| 17:19:08 | FromGitter | <tim-st> https://play.nim-lang.org/?gist=b9c86211532c5e894f69cda0d2dace98 |
| 17:22:13 | miran | it seems that it will be increased |
| 17:22:35 | miran | i've run it with: `var i = 2; skip("bla'", i); echo i` |
| 17:23:04 | Yardanico | well it would be hard to rollback every operation otherwise |
| 17:24:19 | FromGitter | <tim-st> ok, thanks! |
| 17:24:26 | miran | btw, you are aware that in the example`index+1` and `index+2` are *two* numbers apart? |
| 17:25:17 | FromGitter | <tim-st> Just saw, there is a bug thanks! |
| 17:25:28 | FromGitter | <tim-st> the second one must be +1 too |
| 17:25:42 | miran | ;) |
| 17:32:06 | * | yglukhov joined #nim |
| 17:34:12 | * | PMunch joined #nim |
| 17:36:33 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 17:55:39 | * | tinAndi joined #nim |
| 17:57:25 | * | yglukhov joined #nim |
| 17:58:55 | * | fvs joined #nim |
| 18:01:03 | * | tinAndi quit (Ping timeout: 248 seconds) |
| 18:06:08 | * | gokr left #nim (#nim) |
| 18:07:28 | * | yglukhov quit (Read error: Connection reset by peer) |
| 18:08:04 | * | yglukhov joined #nim |
| 18:13:16 | * | smt joined #nim |
| 18:14:47 | * | Trustable quit (Remote host closed the connection) |
| 18:25:07 | * | devdri joined #nim |
| 18:27:49 | * | devdri quit (Client Quit) |
| 18:37:29 | * | fvs left #nim ("ERC (IRC client for Emacs 25.3.1)") |
| 18:46:52 | * | nsf joined #nim |
| 19:00:58 | * | vest joined #nim |
| 19:01:48 | GitDisc | <treeform> Hey dom, you recently changed newSelector*[T] to have the [T], but I don't know what I should stuck into the T to make it work? Do you have an example? |
| 19:02:57 | vest | what is the "nim way" of creating a copy of a tuple? I have a type defined which declares my tuple's fields and I'd like to create a copy of a var of that type such that the new var when modified will not modify the original |
| 19:06:29 | Yardanico | treeform: it means that newSelector is generic |
| 19:08:35 | GitDisc | <treeform> yes but what do I give it to make it work newSelector[int] newSelector[Socket] newSelector[SelectKey] ... I am just confused? |
| 19:08:50 | PMunch | Something like that yes |
| 19:08:58 | GitDisc | <treeform> newSelector[KPoll] ? |
| 19:09:08 | GitDisc | <treeform> I am not sure what generic would make it work? |
| 19:09:22 | PMunch | But if it's on the form newSelector[T](input: T) then it should be able to automatically detect it if you do newSelector("Hello world") |
| 19:09:29 | PMunch | As it knows that "Hello world" is a string |
| 19:10:14 | GitDisc | <treeform> I did not know that. I have a some code that uses newSelector, but now it does not work. I am just trying to fix it. |
| 19:11:21 | GitDisc | <treeform> this is the commit that made the changes: https://github.com/nim-lang/Nim/pull/6585 |
| 19:11:33 | PMunch | And what does your code look like? |
| 19:12:20 | GitDisc | <treeform> https://gist.github.com/treeform/636248572f783c128b7bf41fd50b1198 |
| 19:12:21 | PMunch | Wait, according to that it was always [T] |
| 19:13:23 | PMunch | Just change it to newSelector[TheType]() |
| 19:13:33 | GitDisc | <treeform> it looks like its supposed to be [int] |
| 19:13:48 | GitDisc | <treeform> the tests use int: https://github.com/nim-lang/Nim/blob/85ac3130aa80e784fcd84c5a38122c61f4a8860d/tests/async/tioselectors.nim#L36 |
| 19:15:25 | * | vest quit (Quit: Page closed) |
| 19:15:48 | dom96 | treeform: if you want to highlight me then use my full name, 'dom' isn't enough |
| 19:16:16 | GitDisc | <treeform> Its fine I was stuck, but when i ask for help, i get unstuck! |
| 19:16:23 | GitDisc | <treeform> works every time 😃 |
| 19:16:29 | dom96 | The T is custom user data IIRC |
| 19:16:38 | dom96 | So 'void' might work if you don't need it |
| 19:16:42 | GitDisc | <treeform> It looks like passing [int] works? |
| 19:16:50 | dom96 | you can pass whatever you want |
| 19:16:50 | GitDisc | <treeform> oh void i'll try that |
| 19:16:53 | dom96 | it's your own data |
| 19:16:59 | dom96 | that you will get back in poll |
| 19:17:30 | GitDisc | <treeform> does not look like void works |
| 19:17:53 | dom96 | that should be fixed |
| 19:18:07 | dom96 | but putting some dummy type like 'int' is fine too |
| 19:18:18 | * | yglukhov quit (Remote host closed the connection) |
| 19:18:34 | GitDisc | <treeform> yeah i think so |
| 19:18:47 | GitDisc | <treeform> i think the issue is that `registerHandle` takes 3 values and you can't pass in type void? |
| 19:19:00 | GitDisc | <treeform> you probably need a 2nd registerHandle that takes only 2 to and makes void work? |
| 19:19:02 | * | yglukhov joined #nim |
| 19:19:18 | dom96 | yeah, maybe |
| 19:19:42 | dom96 | I bet you'll end up needing this T eventually anyway :) |
| 19:20:04 | GitDisc | <treeform> you are probably right |
| 19:20:48 | dom96 | In case you need more examples, take a look at my HTTP server https://github.com/dom96/httpbeast |
| 19:22:57 | GitDisc | <treeform> I see thanks. I could not find examples on the newSelector[T] everyone used old newSelector() on the web. i will use yours. |
| 19:26:06 | dom96 | what are you working on? :) |
| 19:30:04 | * | yglukhov quit (Remote host closed the connection) |
| 19:31:55 | * | icebattle joined #nim |
| 19:35:43 | PMunch | Hmm, re(r"\s*\".*\"\s*") complains that: "(74, 52) Error: invalid character constant" |
| 19:37:31 | dom96 | you need to escape the " |
| 19:37:34 | dom96 | by doubling it |
| 19:37:38 | dom96 | that's how raw strings work |
| 19:37:53 | dom96 | but that's redundant, re"..." is the same as re(r"...") |
| 19:38:16 | PMunch | That was a simplification, I'm passing that r"" around a bit |
| 19:38:38 | GitDisc | <treeform> dom96, I am working on internal data science tools. |
| 19:39:22 | dom96 | huh, and you're using selectors? |
| 19:39:44 | PMunch | Ah, that worked dom96. My Vim Nim colour coding isn't quite correct :P |
| 19:39:52 | PMunch | So it looked like a valid string in the editor |
| 19:39:57 | GitDisc | <treeform> i am trying to use websockets, so that it can crunch numbers and return the result to an js front end. |
| 19:40:10 | GitDisc | <treeform> i am trying to use websockets, so that it can crunch numbers and return the result to a js front end. |
| 19:41:43 | GitDisc | <treeform> so far I been using polling were I hit the endpoint and "go are you ready yet?" but if I do that too much Chrome throttles and some pops up "this tab is bad, lets kill it" |
| 19:42:38 | skrylar | the last i ever derped with websockets is back when Seaside was new and they had that Comet module everyone was all proud of |
| 19:43:10 | skrylar | is it really that big of a pain in the ass? |
| 19:43:53 | GitDisc | <treeform> I love websockets. REST should die. |
| 19:44:59 | skrylar | i don't see much wrong with rest |
| 19:46:54 | * | solitudesf quit (Ping timeout: 268 seconds) |
| 19:47:00 | skrylar | Plumber was an interesting case for RPC. You shove text down a special text pipe and listeners do regex matches on it. And that's how Plan9 did inter process communication. Seemed to work well and was extremely straight forward. rest over HTTP/1.1 is just slightly more crufty than that |
| 19:47:41 | * | solitudesf joined #nim |
| 19:47:56 | skrylar | REST HTTP/1.1, STOMP and Beanstalk are probably some of the simplest ways of brokering requests /shrug |
| 19:49:32 | PMunch | Hmm, is there a generic way to write a "combine" proc for something like: (((string, string), string), string) |
| 19:50:08 | PMunch | And by generic I mean should handle (string, string), ((string, string), string), (((string, string), string), string) etc. |
| 19:52:04 | skrylar | sounds like some of the append/glue functions from haskell |
| 19:54:12 | skrylar | PMunch, if its all at compile time, you can probably get away with a function for the tuples and another for single values, and then do it recursively |
| 19:54:23 | skrylar | well probably runtime too |
| 20:00:40 | PMunch | Hmm, that might work |
| 20:03:03 | PMunch | Yup |
| 20:03:13 | * | yglukhov joined #nim |
| 20:03:16 | PMunch | proc combine(t: tuple[f1, f2: string]): string = t.f1 & t.f2 |
| 20:03:22 | PMunch | proc combine[T](t: tuple[f1: T, f2: string]): string = t.f1.combine() & t.f2 |
| 20:03:27 | PMunch | Works like a charm |
| 20:06:41 | * | Yardanico quit (Remote host closed the connection) |
| 20:10:30 | skrylar | the downside is that implementation is going to have the painter's problem |
| 20:10:44 | skrylar | ex. concatting to a concat instead of building up a buffer |
| 20:11:01 | PMunch | Yeah, it'll be fine for this though |
| 20:17:47 | * | ipjk joined #nim |
| 20:29:39 | * | yglukhov quit (Remote host closed the connection) |
| 20:32:32 | skrylar | wonder if there is a super gc someone published |
| 20:32:48 | skrylar | i've seen claims that its 'solved' now, something about generational gcs apparently |
| 20:34:07 | * | yglukhov joined #nim |
| 20:34:45 | Araq | "solved" in what sense? |
| 20:35:36 | Araq | I've worked with a hard realtime Gc with pause times in the nano seconds. |
| 20:35:56 | Araq | was a commercial JVM. |
| 20:36:11 | skrylar | https://www.eidos.ic.i.u-tokyo.ac.jp/~tau/lecture/programming_languages/presentations/2017/papers/ismm17-main18.pdf hmmm |
| 20:36:42 | Araq | minimum RAM requirements were 20MB, too much for tiny micro controllers |
| 20:37:18 | Araq | plus it only solves pause times, not provable bounded memory usages which are as important. |
| 20:37:35 | Araq | a most impressible deadend if you ask me. |
| 20:37:55 | skrylar | the best way to manage garbage is not to have garbage, of course |
| 20:38:23 | Araq | it's not the "best" vs "worse", you can't prove this shit. |
| 20:38:37 | Araq | it's "tedious, slow development" vs "impossible" |
| 20:39:16 | skrylar | at the moment i'm just looking at the incremental ones |
| 20:39:50 | skrylar | fro mprior tinkering with lisps it seems that having a GC allows you to do some more aggressive things with codegen, but then you end up paying for the collection /somewhere/ |
| 20:39:55 | * | Jesin quit (Ping timeout: 256 seconds) |
| 20:39:59 | Araq | it also didn't sell well tbh. people don't need hard realtime GCs. if you do hard realtime, it's all about provably correct stuff. |
| 20:40:44 | skrylar | yea tech is hard to sell |
| 20:42:10 | skrylar | hacking on a toy VM at the moment, fishing around to deal with threads |
| 20:42:23 | skrylar | seemingly everyone just throws their hands up and goes the global interpreter lock metho |
| 20:43:22 | Araq | gc:v2 is an incremental M&S GC for Nim |
| 20:43:37 | skrylar | incrementals are pretty good |
| 20:43:57 | Araq | it's actually all kind of stupid :-) |
| 20:43:59 | skrylar | haven't decided on stop-the-thread or separate heaps |
| 20:44:19 | Araq | lol I've grown to dislike GCs |
| 20:44:34 | * | BitPuffin quit (Remote host closed the connection) |
| 20:45:07 | Araq | incremental GC: "we don't pause the mutator for long but also cannot free anything until we marked the full heap" |
| 20:45:15 | Araq | - "yeah, I'll pass" |
| 20:45:56 | * | skrylar_ joined #nim |
| 20:46:42 | Araq | generational GC: "let's assume your objects die young..." - "I just optimized my code to avoid temporary allocations..." |
| 20:47:25 | Araq | refcounting GC: "you don't have cycles in there now, do you?" - "but, OOP!" |
| 20:48:36 | Araq | copying GC: "you don't use large objects, right? these will be expensive to copy for me, introducing all the problems I thought I could avoid" |
| 20:49:11 | Araq | - "er, I optimized my data for the caches, only large array are left in my code" |
| 20:50:14 | dom96 | hah |
| 20:50:18 | dom96 | This should be a blog post |
| 20:50:33 | dom96 | Bonus points if you could draw different GC types as little cute characters |
| 20:52:49 | * | skrylar_ quit (Ping timeout: 248 seconds) |
| 20:53:07 | * | Jesin joined #nim |
| 20:54:08 | * | c0ntribut0r quit (Ping timeout: 276 seconds) |
| 20:55:29 | Araq | maybe it should be a comic strip |
| 20:56:33 | * | yglukhov quit (Remote host closed the connection) |
| 21:05:24 | GitDisc | <treeform> I would love to see GC blog post. |
| 21:09:01 | * | yglukhov joined #nim |
| 21:14:13 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 21:19:08 | PMunch | Yeah, just a GC blogpost would be really neat |
| 21:19:17 | * | Trustable joined #nim |
| 21:21:04 | * | devdri joined #nim |
| 21:23:25 | shashlick | hey guys, know it's just been a day but am curious what we need to do to close on the branching vs trunking topic |
| 21:24:19 | PMunch | They talked about it earlier today as well shashlick |
| 21:28:10 | PMunch | Woo, my combinatorial parser appears to sorta kinda work |
| 21:30:43 | * | miran quit (Quit: Konversation terminated!) |
| 21:30:51 | shashlick | i went thru that, only thing I saw was the concern that v2 will be distracting and that there's no clear roadmap for 1.1 |
| 21:31:05 | * | Vladar quit (Quit: Leaving) |
| 21:32:42 | shashlick | I don't agree with v2 being a distraction, someone needs to think about the future and it might as well be the creator of Nim. almost everyone else can focus on 1.x and bugfixes |
| 21:37:43 | * | PMunch quit (Quit: leaving) |
| 21:47:55 | * | Trustable quit (Remote host closed the connection) |
| 22:18:57 | GitDisc | <treeform> when i do `let things = foo.bar.baz.things` where things is a seq, will it copy it or just alias it? I just don't want to type `foo.bar.baz.things` how would i do it? |
| 22:19:19 | GitDisc | <treeform> You know without any performance issues? |
| 22:20:48 | * | dddddd quit (Ping timeout: 240 seconds) |
| 22:23:00 | * | dddddd joined #nim |
| 22:26:51 | * | solitudesf quit (Ping timeout: 246 seconds) |
| 22:29:48 | Araq | currently the 'let' does not copy |
| 22:30:24 | GitDisc | <treeform> but it might in the future? |
| 22:31:34 | dom96 | You can use a `template things = foo.bar.baz.things` if you want to guarantee it won't be copied |
| 22:32:43 | * | Snircle joined #nim |
| 22:38:15 | GitDisc | <treeform> oh |
| 22:38:25 | GitDisc | <treeform> thanks |
| 22:40:04 | FromGitter | <honewatson> anyone know of a file watcher for nim? |
| 22:40:43 | FromGitter | <honewatson> watch for file changes >> run command |
| 22:41:18 | FromGitter | <Quelklef> no idea but google turned up: https://github.com/3dicc/Urhonimo/blob/master/modules/io/filewatcher.nim |
| 22:41:35 | FromGitter | <Quelklef> Oh, hey, there's https://nim-lang.org/docs/fsmonitor.html |
| 22:43:21 | FromGitter | <honewatson> thanks I was searching with nimble |
| 22:45:05 | FromGitter | <honewatson> hmmm fsmonitor only works in linux where as I need cross platform and the other requires the Urho3D game engine as a dependency |
| 22:46:00 | dom96 | honewatson: you could give wrapping the windows file watching API a go |
| 22:47:08 | dom96 | then extend fsmonitor to support it |
| 22:47:13 | dom96 | I can give you pointers if you'd like |
| 22:48:41 | GitDisc | <treeform> What is the best way to have shared cache between multiple threads (and cores) in nim? |
| 22:49:29 | GitDisc | <treeform> i am fine with using locks and never freeing it... |
| 22:50:36 | Araq | SharedTable[] |
| 22:52:00 | GitDisc | <treeform> did not know what was there |
| 22:52:01 | GitDisc | <treeform> looking |
| 22:58:20 | FromGitter | <honewatson> thanks @dom96 windows is not a strong point for me that is why I would prefer something out of the box. fsmonitor.nim doesn't appear to be in the stdlib any more |
| 22:58:32 | * | MJCaley joined #nim |
| 23:02:57 | dom96 | I guess somebody removed it without creating a Nimble package for it :\ |
| 23:02:59 | * | FromGitter quit (Remote host closed the connection) |
| 23:02:59 | * | oprypin quit (Quit: Bye) |
| 23:03:09 | shashlick | what's SharedTable? I don't see it in the docs |
| 23:03:17 | * | FromGitter joined #nim |
| 23:03:21 | * | oprypin joined #nim |
| 23:11:41 | GitDisc | <treeform> it looks like its a table that does not use GCed things so that it can be passed between threads |
| 23:11:49 | FromGitter | <honewatson> Ruby had a killer app in Rails which raised the profile so I think if we could create a killer app for Nim with documentation/promotion that could really help promote nim |
| 23:16:21 | * | Jesin quit (Quit: Leaving) |
| 23:19:49 | shashlick | SharedTable will be awesome if I could find it :( |
| 23:21:55 | skrylar | back |
| 23:22:55 | skrylar | dom96, Araq: as i was discussing briefly in meatspace, it's not so much that one GC rules all situations (they can't), but there are situations they are useful. in the current experiments i'm doing, it's mostly about livecoding |
| 23:23:13 | GitDisc | <treeform> shashlick https://github.com/nim-lang/Nim/blob/d1e10f9aa3e033414fb924e4f90736e46fde8256/lib/pure/collections/sharedtables.nim |
| 23:23:18 | shashlick | https://nim-lang.org/docs/sharedtables.html does not exist but import sharedtables works - will look at the code |
| 23:23:53 | skrylar | although it does seem that weak/strong refs and some simple ARCs are a lot easier to codegen and use less memory (although spend a lot of time doing atomic inc/dec) |
| 23:23:54 | dom96 | honewatson: of course, but the question is what should the killer app be and who will commit their valuable time to developing it? |
| 23:24:09 | skrylar | ST-80 doesn't have strong/weak refs, so blegh. although i suspect it could be made to do so |
| 23:28:18 | FromGitter | <honewatson> @dom96 I have some ideas and some ambition but of course I cannot do it on my own so I would need to think about how to document and promote the concepts. |
| 23:28:57 | * | devdri quit () |
| 23:30:15 | * | yglukhov quit (Remote host closed the connection) |
| 23:30:55 | skrylar | I'm toying around with taking the v1 approach of a GC per "thread," then making the base unit a fiber (ex. goroutine stuff), but then 1) making sure finalizers are always run, which then in turn means "big stuff" like arrays can just use shared space |
| 23:34:25 | shashlick | sharedstring and sharedtables solve so many headaches |
| 23:42:05 | * | yglukhov joined #nim |
| 23:44:27 | skrylar | killer apps are.. hmm |
| 23:45:02 | skrylar | am lately thinking success is more about cultivating supporting resources than anything else |
| 23:45:22 | skrylar | Squeak demonstrates just having a killer app (Seaside) is not enough if your offering has too many other defects |
| 23:46:10 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 23:46:35 | skrylar | from my experience i never know if the version of nim i'm using is going to work one day to the next, because there keeps being talk of pulling the GC or somethingerother |
| 23:53:40 | FromGitter | <honewatson> yeah cultivating support resources are critical |
| 23:54:35 | FromGitter | <honewatson> there is no leverage or scalability in being available in chat to answer queries. Its critical to have good documentation with stable features and stable api |
| 23:54:46 | FromGitter | <honewatson> I don't know what squeak is by the way |
| 23:55:56 | FromGitter | <honewatson> ok its a version of small talk. |
| 23:56:10 | FromGitter | <honewatson> the splash page looks like something out of the early naughties |
| 23:57:10 | FromGitter | <honewatson> seaside doesn't offer any specific benefit |
| 23:57:15 | FromGitter | <honewatson> its to generic |
| 23:57:36 | FromGitter | <honewatson> 'Sophisticated web creations' what does that even mean? |
| 23:58:04 | * | yglukhov joined #nim |
| 23:58:20 | FromGitter | <honewatson> so I think the USP of a killer app needs to be very well defined. Presentation is critical as well as documentation. |
| 23:58:46 | * | zahary_ quit (Quit: Connection closed for inactivity) |
