| 00:00:08 | FromGitter | <awr1> RE: the sublime text clone thing/aporia thing from earlier: you will generally not raise anyone's attention by building another sublime text clone when it seems that vs code has already swayed everyone's interest in that arena. if you want to get people interested in an editor rn i would reckon it should aim to be mouseless from the get go, in the vein of emacs+vim (UI-based, not terminal-based) with the intent of |
| 00:00:08 | FromGitter | ... overcoming their faults that they have accrued from age |
| 00:01:42 | disruptek | that's an interesting thought, but how does atom fit in to your thinking? |
| 00:02:00 | FromGitter | <awr1> atom is basically a sublime clone |
| 00:02:11 | disruptek | indeed, but can you not drive it with the keyboard? |
| 00:02:14 | FromGitter | <awr1> VS code is more or less "souped up atom" |
| 00:03:09 | FromGitter | <awr1> you will find vim/emacs emulation plugins in all of these editors but after using it for a while it will become quite apparent that these editors were not really built with that philosophy in mind |
| 00:03:43 | disruptek | i guess i'm having trouble seeing how an oss editor that is ui-based but not mouse-based is competitive with, say, atom. |
| 00:06:16 | shashlick | Then you will like feud |
| 00:06:29 | FromGitter | <kaushalmodi> @awr1 it doesn't take half pane. |
| 00:06:36 | shashlick | Which has no gui elements |
| 00:06:54 | shashlick | It has a cli ux |
| 00:07:16 | FromGitter | <kaushalmodi> I am using ivy/counsel (as you see in the gif on my blog) |
| 00:07:39 | shashlick | But my main motivation is to make it lean and fast, not a slob that is electron |
| 00:08:50 | FromGitter | <kaushalmodi> @awr1 technically Emacs emulation is not possible ;) |
| 00:09:05 | FromGitter | <kaushalmodi> The "Emacs emulation" is just a bunch on key bindings |
| 00:09:18 | FromGitter | <kaushalmodi> But Emacs is much much more than that |
| 00:13:41 | shashlick | @kaushalmodi - some of your work is captured here - https://github.com/nimterop/nimterop/wiki/Wrappers |
| 00:13:53 | shashlick | Thanks for being a nimterop customer :) |
| 00:15:10 | FromGitter | <kaushalmodi> Thanks :). Though https://github.com/kaushalmodi/nim-systemverilog-dpic is a collection of snippets using the svdpi wrapper. |
| 00:15:38 | FromGitter | <kaushalmodi> Many thanks to you for nimterop and the awesome support! |
| 00:15:58 | disruptek | shashlick, you embarrass us with your contributions. |
| 00:17:04 | FromGitter | <awr1> i use emacs w/ spacemacs, it's nice but you can tell they've encountered growing pains |
| 00:20:25 | disruptek | today's hack: https://github.com/disruptek/i3ipc |
| 00:22:58 | shashlick | Thanks folks |
| 00:51:41 | * | rockcavera quit (Remote host closed the connection) |
| 01:04:40 | leorize | disruptek: why tabs :( |
| 01:05:05 | leorize | also since your tab size is 4, https://github.com/disruptek/i3ipc/blob/master/i3ipc.nim#L219-L223 |
| 01:11:05 | FromGitter | <kayabaNerve> 4 is the proper space for tabs. |
| 01:12:37 | * | tefter quit (Remote host closed the connection) |
| 01:12:47 | * | noonien quit (Quit: Connection closed for inactivity) |
| 01:16:32 | leorize | for historical reasons, every tab is rendered as 8 spaces by default |
| 01:30:10 | * | rockcavera joined #nim |
| 01:38:00 | FromGitter | <kayabaNerve> Anyone familiar with choosenim online? |
| 01:40:53 | FromDiscord_ | <Sybe> What are languages I should be interested in but aren't |
| 01:45:48 | * | ng0_ joined #nim |
| 01:48:12 | * | ng0 quit (Ping timeout: 260 seconds) |
| 01:56:56 | * | ng0_ quit (Quit: Alexa, when is the end of world?) |
| 01:57:43 | * | laaron- quit (Remote host closed the connection) |
| 02:02:13 | disruptek | my tab size is 3, but that's a perfect illustration of the point of tabs. |
| 02:03:12 | * | laaron joined #nim |
| 02:03:36 | disruptek | sybe: what languages aren't you interested in? |
| 02:04:53 | FromDiscord_ | <Sybe> Well “””newer””” languages: Nim and Zig mostly |
| 02:05:18 | disruptek | well, nim is definitely one that you should be interested in and aren't. |
| 02:05:28 | disruptek | any others you aren't interested in? |
| 02:05:51 | disruptek | clojure is pretty groovy. groovy, not so much. |
| 02:10:30 | FromGitter | <awr1> dhall if you want to include non-turing complete languages |
| 02:11:33 | FromGitter | <awr1> https://github.com/disruptek/i3ipc/blob/master/i3ipc.nim#L221 nice hanging indent :P |
| 02:12:22 | disruptek | yeah, well, it's not my fault that 1) nimpretty is too buggy to use, and 2) github doesn't let the user (or the author) configure their tab rendering. |
| 02:12:24 | FromDiscord_ | <Sybe> Oof |
| 02:12:30 | FromDiscord_ | <Sybe> I misread that |
| 02:12:43 | FromDiscord_ | <Sybe> I read “what languages are you interested in” |
| 02:12:52 | FromDiscord_ | <Sybe> Not “aren’t” |
| 02:13:13 | disruptek | oh, well, you wrote "aren't"; hence my confusion. |
| 02:13:19 | leorize | disruptek: use spaces, problem solved |
| 02:13:26 | disruptek | no, that's just dumb. |
| 02:13:36 | leorize | you can't expect to tell everyone to use 3 spaced tabs in their editor |
| 02:13:44 | disruptek | the whole point of tabs is to less us write identical code and render it according to taste. |
| 02:13:46 | FromGitter | <awr1> that's kind of the reason i prefer spaces tbh, because of things like that hanging indents. would rather read things as they look as the author's screens |
| 02:13:51 | disruptek | s/less us/let us/g |
| 02:14:01 | FromGitter | <awr1> even if they don't conform to the standard nim 2-space canon |
| 02:14:50 | leorize | the thing is that you are confined to how the one who write the code render their tabs |
| 02:15:08 | leorize | if you use 2 space tabs, then you might tab 3-4 times to get the indent you want |
| 02:15:42 | leorize | but since my editor is 8 space tabs by default, I see a long line of whitespace instead |
| 02:15:46 | disruptek | that's ridiculous. |
| 02:16:10 | FromGitter | <awr1> i feel like when you complain that github won't let you configure tab length, you've defeated your own point |
| 02:16:13 | disruptek | i thought you used vim? |
| 02:16:40 | leorize | vim uses 8 space tabs by default |
| 02:16:47 | disruptek | i feel like when you criticize someone's choice of tabs over spaces, you defeat the point of reading their code. ;-) |
| 02:17:06 | disruptek | it's like 3 keypresses to swap all the leading whitespace. |
| 02:17:16 | disruptek | and there's always !retab. |
| 02:17:18 | FromDiscord_ | <Sybe> I am interested in: Zig and nim. |
| 02:17:18 | FromDiscord_ | <Sybe> I am not interested in: Crystal, Elm, Pony and Rust |
| 02:17:39 | FromGitter | <awr1> https://youtu.be/SsoOG6ZeyUI |
| 02:17:47 | leorize | but I don't clone code and read them. Sometimes I read them on the web |
| 02:18:11 | disruptek | what a bummer, dude. |
| 02:18:37 | disruptek | it sounds like you have a problem with github. |
| 02:20:14 | leorize | well I'd say that vim is not well equipped to deal with not 8 space tabs |
| 02:20:38 | disruptek | dude. |
| 02:20:46 | disruptek | you just watched me write this code this morning. in vim. |
| 02:20:53 | disruptek | what's going on here? |
| 02:20:53 | leorize | the hanging indent is an example of that |
| 02:20:58 | disruptek | of what? |
| 02:21:06 | leorize | your tabstop is 3 |
| 02:21:17 | disruptek | the only people who have a problem with this are folks reading my code in github. are you kidding me right now? |
| 02:21:41 | leorize | I mean that the tabs are not generated deterministically |
| 02:21:54 | disruptek | i already pushed a version w/o the hanging indent. |
| 02:22:08 | disruptek | "tabs are not generated deterministically". |
| 02:22:31 | leorize | vim generate tabs based on shiftwidth and tabstop |
| 02:22:56 | disruptek | sounds fairly deterministic to me, but what do i know? i never even went to college. |
| 02:23:10 | disruptek | except to teach, i mean. |
| 02:24:26 | disruptek | anyway, keep your fingers crossed. maybe i will see the light some day. until then, this code is not suitable for consumption in any event -- it doesn't parse replies as i'd like. |
| 02:24:53 | leorize | well it'd mean that if your tabstop = 3, the generated indent to display 8 spaces -> 5 tabs + 3 spaces |
| 02:25:27 | disruptek | how do you get 8 from 5*3 + 3? |
| 02:25:34 | leorize | sorry, 16 :P |
| 02:25:43 | disruptek | i'm still struggling. |
| 02:26:03 | leorize | nim.nvim decides that you need 16 spaces there for optimal reading |
| 02:26:16 | disruptek | ah, so it's bug in nim.nvim? |
| 02:26:24 | leorize | nvim translate that to tabs + spaces based on your shiftwidth and tabstop |
| 02:26:28 | leorize | no, this is how vim works |
| 02:26:47 | disruptek | i have no idea what you're on about. i spaced that hanger by hand. |
| 02:27:27 | FromGitter | <awr1> in an ideal world github would have nimpretty/clang-format/who knows what built in to whatever the person's preferences are so no one would complain |
| 02:27:48 | disruptek | you wouldn't think it'd be so difficult. |
| 02:28:29 | FromGitter | <awr1> i don't follow the official nim style perfectly in my own personal code |
| 02:28:32 | disruptek | sybe: what about erlang? |
| 02:28:59 | disruptek | when i work on other nimmers' code, i use spaces. |
| 02:29:16 | leorize | https://www.reddit.com/r/vim/wiki/tabstop |
| 02:29:26 | leorize | ^ this kinda sums up the tabstop setting |
| 02:30:09 | FromGitter | <awr1> personally not a huge fan of the rule on vertical alignment |
| 02:30:12 | FromGitter | <awr1> in NEP-1 or w/e |
| 02:30:22 | disruptek | it's funny that you think any of us need an explanation, when if we hadn't configured those settings, we'd have a very hard time producing code free of tabs (or free of spaces). |
| 02:30:31 | * | a_b_m quit (Read error: Connection reset by peer) |
| 02:31:11 | disruptek | in my opinion, nim should have a formatter that is good enough that it can be enabled by default, everywhere, without any optional settings. |
| 02:31:45 | FromGitter | <awr1> which is what nimpretty is supposed to be |
| 02:32:07 | disruptek | yeah, it's not that efforts haven't been made. |
| 02:32:46 | disruptek | leorize: look up the %retab! command in vim. |
| 02:32:54 | leorize | I know that one |
| 02:33:00 | leorize | it's not the point |
| 02:33:03 | disruptek | as long as we're sharing pointed vim commands as if we're a couple of clueless idiots. |
| 02:33:13 | disruptek | what is the point? |
| 02:33:37 | disruptek | you read 350 lines of code and your criticism is over a hanging indent that renders like shit on github. |
| 02:33:43 | disruptek | i mean, gimme a break, man. :-P |
| 02:34:33 | disruptek | i love the way nesm turned out. it coulda been a little better, but it's great, so thanks again for that. |
| 02:34:41 | disruptek | pretty damned clean. |
| 02:44:45 | leorize | I'd say this is what I hate about using tabs: http://ix.io/1PFn/nim |
| 02:45:08 | leorize | inconsistency between writers |
| 02:45:37 | leorize | :retab will do the fixing magic, just that not everyone uses vim (even though they should :P, but that's an another story) |
| 02:46:02 | disruptek | i guess nimpretty should do the write thing. shame it doesn't. |
| 02:46:25 | disruptek | $DEITY gave us tabs, and then $HESHEIT took them away! |
| 02:53:43 | leorize | there was elastic tabstop that is rather interesting, but never made it to mainstream iirc |
| 02:55:03 | disruptek | what'll really bake your noodle is that i only switched back to tabs when i picked up nim. |
| 02:56:08 | disruptek | all my python and coffeescript is slowly getting converted to tabs each time i open it up in vi. :-P |
| 02:56:38 | leorize | you switched to tabs in a space-only language, nice :P |
| 02:56:46 | disruptek | it's like the neverending story here, all the spaces just flying away into nothingness. |
| 02:57:17 | leorize | and don't mix tabs in python please, I've seen crazy problems with that |
| 02:57:23 | disruptek | i did it just to attract the ire of those who can find no other criticisms of a newbie's code. |
| 02:57:39 | disruptek | oh, it's a disaster in python, truly. |
| 02:59:35 | leorize | my only criticisms are: multiple imports instead of one, and tabs :p |
| 03:00:22 | leorize | oh and if you're not planning to make enum with holes, their `int` counterpart runs from 0 by default |
| 03:00:26 | disruptek | i won't do a single import because i want to see patches add/remove import lines as opposed to making me parse the changes therein, but, i note your concern. why is it an issue? |
| 03:00:45 | disruptek | i numbered the enum because the int values are significant to the server. |
| 03:00:53 | disruptek | i thought i had a comment in there about that? |
| 03:01:10 | leorize | nope? |
| 03:02:04 | leorize | multiple import is just a matter of taste |
| 03:03:31 | leorize | I personally use an import for stdlib modules, one for 3rd party, and one for stuff in the same project |
| 03:03:39 | disruptek | the compositor concept has to go away; it's inaccurate. it'll just be handles/sockets. |
| 03:04:10 | leorize | I guess you can add destructors to them to make them more useful |
| 03:04:20 | disruptek | i use blank lines to separate stdlib imports, third parties, and local stuff. even more verbose, i know. |
| 03:04:38 | disruptek | sockets don't have destructors? |
| 03:04:51 | leorize | nothing in the stdlib have destructors atm |
| 03:05:08 | disruptek | do you use i3/sway? |
| 03:05:16 | leorize | I use both |
| 03:05:54 | disruptek | the only reason i wrote this was to replace my kitty (term) hack and do opacity on focus changes, but i cannot figure out the syntax for the ipc command issuance. |
| 03:06:07 | disruptek | i'm just guessing, of course, and i could look at the code, but... do you know? |
| 03:06:33 | leorize | nope, sounds like a sway-only thing |
| 03:06:40 | disruptek | it boggles my mind that we cannot do surface scaling with a tool like this in wayland. |
| 03:06:41 | leorize | i3 doesn't have a compositor afaict |
| 03:07:23 | disruptek | sure, but wayland didn't invent pixel shaders; i think that stuff is available in the X world. |
| 03:07:57 | leorize | I use compton which can do the opacity thing to every window :P |
| 03:08:09 | leorize | how's opacity being done for your term then? |
| 03:08:17 | leorize | done by the terminal or by the compositor? |
| 03:08:36 | disruptek | right, as can sway. i just want to change it with some nim code instead of using keyboard bindings. |
| 03:08:52 | disruptek | my terminal is done with a separate ipc-speaking hack i made. |
| 03:09:14 | disruptek | (kitty has its own socket) |
| 03:09:57 | leorize | keyboard bindings? I thought that stuff is automated by default or am I missing something here? |
| 03:11:10 | disruptek | some terminals may allow you to do that, but the author of kitty has made it clear that kitty will not. so i wrote my hack. but i wanna automate the same stuff with other windows, and i think i'd rather deprecate my kitty hack in favor of a more general solution in the compositor. |
| 03:13:19 | leorize | sway/contrib/inactive-windows-transparency.py :P |
| 03:13:32 | FromGitter | <awr1> ive had problems with wayland before |
| 03:13:39 | leorize | should be easy enough to rewrite in Nim |
| 03:13:57 | disruptek | yeah, but it won't integrate nicely with my nim stuff. although, i guess i could read it and see the syntax. |
| 03:14:17 | FromGitter | <awr1> i just use gnome 3 lol |
| 03:14:18 | disruptek | oh, i did. that's why i'm confused. :-P |
| 03:14:48 | leorize | awr1: you're missing on the amazing world of tiling |
| 03:14:49 | disruptek | wayland is great. ridiculously fast. |
| 03:14:57 | FromGitter | <awr1> i've tried tiling before |
| 03:15:10 | disruptek | notion was a great tiling wm in the X days. |
| 03:15:22 | disruptek | and ion before it. |
| 03:15:52 | FromGitter | <awr1> and came to the conclusion that emacs is enough of a tiling WM for me |
| 03:16:23 | leorize | don't use gnome, use emacs |
| 03:16:31 | FromGitter | <awr1> or exwm lol |
| 03:17:30 | disruptek | i've come to the conclusion that if i'd been born a little later, i'd be using emacs today. |
| 03:17:42 | disruptek | i keep trying to switch but something always breaks it for me. |
| 03:17:42 | leorize | all they need now is a kernel so emacs can be called an os |
| 03:18:23 | * | lritter quit (Ping timeout: 245 seconds) |
| 03:18:29 | FromGitter | <awr1> doesn't RMS just use linux in fbdev and emacs |
| 03:19:23 | disruptek | he only uses GNU Linux. ;-) |
| 03:19:32 | disruptek | or herd, the nutjob. |
| 03:19:45 | FromGitter | <awr1> he uses linux-libre |
| 03:19:49 | disruptek | hurd, too. |
| 03:20:19 | leorize | I've tried emacs before, but I don't like how it kills your pinky finger with all those keys, and it starts slow as hell |
| 03:20:58 | disruptek | there are vi bindings for it, and the rest of the pinky stuff can be rebound. |
| 03:21:18 | FromGitter | <awr1> that is why i use spacemacs |
| 03:21:22 | disruptek | to me, the attraction is having a proper fp lang on-board. |
| 03:21:23 | FromGitter | <awr1> (which leverages evil-mode) |
| 03:21:40 | leorize | tried, but I can't live in emacs and nvim startup speed is decent |
| 03:21:51 | leorize | (esp. since I'm using a hdd) |
| 03:21:55 | FromGitter | <awr1> spacemacs is just a better vim to me |
| 03:22:09 | disruptek | it's pretty nice. |
| 03:22:30 | disruptek | org mode might also be reason enough to switch, tbh. |
| 03:23:17 | FromGitter | <awr1> i did a lot of my schoolwork in org mode |
| 03:23:28 | FromGitter | <kaushalmodi> Org mode! |
| 03:23:33 | disruptek | oh shoot! |
| 03:23:37 | leorize | spacemacs looks like a monolithic beast to me |
| 03:23:49 | disruptek | leorize: what kinda hardware are you on? |
| 03:24:01 | disruptek | you're not in a bunker built in the '80s, are you? |
| 03:24:10 | disruptek | i'll come get you, dude. |
| 03:24:11 | leorize | an old and cheap laptop |
| 03:24:11 | disruptek | it's safe. |
| 03:24:26 | * | lritter joined #nim |
| 03:43:21 | FromGitter | <Obround> How do you get the current line number in Nim? |
| 03:47:51 | leorize | instantiationInfo(0) I think |
| 03:49:11 | FromGitter | <Obround> That doesn't seem to work; This is what it returns: `(filename: "???", line: 0, column: -1)` |
| 03:49:36 | leorize | https://play.nim-lang.org/#ix=1PFI |
| 03:51:15 | FromGitter | <Obround> Oh, Thanks :D |
| 03:57:11 | FromGitter | <Obround> But how do you get the line from where the template is called? |
| 03:58:03 | shashlick | missed all that spaces / tabs fun |
| 03:58:22 | * | laaron quit (Remote host closed the connection) |
| 04:00:35 | * | laaron joined #nim |
| 04:00:58 | disruptek | shashlick: it'll come 'round again; it always does. :-) |
| 04:01:47 | shashlick | some things are just not worth the effort in my mind |
| 04:08:24 | leorize | Obround: instantiationInfo gets you that data |
| 04:13:42 | FromGitter | <syhpoon> Hey guys! ⏎ I've found some weird issue while working on my project, probably generics-related. ⏎ After reducing the code to the minimum, this is what I've got: ⏎ ⏎ run.nim: ... [https://gitter.im/nim-lang/Nim?at=5d3bcf76a9200c2428056cd1] |
| 04:14:19 | FromGitter | <syhpoon> ```nim -v ⏎ Nim Compiler Version 0.20.2 [Linux: amd64] ⏎ Compiled at 2019-07-17``` [https://gitter.im/nim-lang/Nim?at=5d3bcf9b071bb025dffa2edd] |
| 04:16:16 | * | dddddd quit (Remote host closed the connection) |
| 04:16:31 | leorize | yea, change Future -> R and you can remove asyncdispatch |
| 04:16:45 | leorize | looks like a bug to me |
| 04:16:48 | kungtotte | I think every language should make an effort to produce something like gofmt or Python's black and create a culture of having everyone use that before checking their code in. One authoriative way of formatting the code so it all looks the same. Relying on people manually following a style guide is madness. |
| 04:17:07 | disruptek | ^ right. |
| 04:17:09 | kungtotte | This way people can mix tabs and spaces any way they want when writing their code, but it all gets checked in uniformly. |
| 04:17:26 | leorize | a lot of work is being poured into nimpretty atm |
| 04:17:33 | disruptek | nimpretty will get there, but it's not there yet. |
| 04:17:41 | * | shashlick quit (Remote host closed the connection) |
| 04:17:52 | leorize | nimpretty is also rather lax for some cases |
| 04:18:20 | * | shashlick joined #nim |
| 04:20:59 | FromGitter | <syhpoon> @leorize, sorry, not sure I fully got it. I need to construct a sequence of futures |
| 04:21:21 | leorize | it's a bug, and I was telling you how to simplify the test case :P |
| 04:21:59 | FromGitter | <syhpoon> oh, but if I remove Future the code compiles :) |
| 04:22:10 | leorize | https://play.nim-lang.org/#ix=1PFR |
| 04:22:20 | leorize | ^ that's my extremely simplified test case |
| 04:22:51 | leorize | can you file an issue for this? |
| 04:23:08 | FromGitter | <syhpoon> yup, will do, thanks! |
| 04:25:07 | FromGitter | <syhpoon> any workarounds maybe in the meantime? |
| 04:25:30 | FromGitter | <syhpoon> untile the bug is fixed that is |
| 04:30:08 | leorize | syhpoon: https://play.nim-lang.org/#ix=1PFY |
| 04:32:37 | FromGitter | <syhpoon> Nice! So it's related to nested generic types, I assume. |
| 04:32:41 | FromGitter | <syhpoon> Thank you! |
| 04:34:36 | FromGitter | <syhpoon> jfyi: https://github.com/nim-lang/Nim/issues/11838 |
| 04:37:09 | * | NimBot joined #nim |
| 04:46:04 | FromGitter | <zacharycarter> can c2nim handle C++ templates? |
| 04:46:14 | FromGitter | <zacharycarter> it seems to stumble on something like - `template<UnsignedInt, class T> class Array;` |
| 05:02:59 | * | krux02 joined #nim |
| 05:11:14 | * | nsf joined #nim |
| 05:14:16 | shashlick | Not really |
| 05:23:59 | Araq | it does. A bit. |
| 05:46:40 | * | solitudesf joined #nim |
| 06:48:06 | * | adeohluwa joined #nim |
| 06:55:20 | FromGitter | <bevo009> Hi there, noob query...is anyone here skilled with strformat? |
| 06:57:09 | leorize | just ask :) |
| 06:57:59 | FromGitter | <bevo009> I'm trying to replicate C++ fmt in Nim if possible like so: ⏎ ```fmt::print("The number {} is {:.3f} to {} places", "pi", 3.14159, 3)``` ⏎ => The number pi is 3.142 to 3 places ⏎ ⏎ I'm stuck on line #d, inserting precision, ... [https://gitter.im/nim-lang/Nim?at=5d3bf5f77e00fc4ace58a1d1] |
| 06:59:16 | leorize | the problem is that the `&` operator is activated before `%` take charge |
| 06:59:46 | leorize | something like this will do: `fmt("The number $1 is {$2:.3f} to $3 places" % ["pi", $3.14159, $3])` |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:00:42 | leorize | !eval import strformat, strutils; echo fmt("The number $1 is {$2:.3f} to $3 places" % ["pi", $3.14159, $3]) |
| 07:00:44 | NimBot | Compile failed: /usercode/in.nim(1, 79) Error: string formatting (fmt(), &) only works with string literals |
| 07:00:57 | leorize | @bevo009: not possible |
| 07:01:49 | FromGitter | <bevo009> thanks, yeah I tried that already |
| 07:02:25 | leorize | !eval import strutils; echo "The number $1 is {$2:.3f} to $3 places" % ["pi", formatFloat(3.14159, precision = 3), $3] |
| 07:02:28 | NimBot | The number pi is {3.14:.3f} to 3 places |
| 07:02:56 | leorize | !eval import strutils; echo "The number $1 is $2 to $3 places" % ["pi", formatFloat(3.14159, precision = 4), $3] |
| 07:03:00 | NimBot | The number pi is 3.142 to 3 places |
| 07:03:29 | leorize | @bevo009 ^ guess that's how you should do it |
| 07:04:45 | * | gmpreussner joined #nim |
| 07:05:06 | FromGitter | <bevo009> You legend! |
| 07:05:33 | FromGitter | <bevo009> A little verbose, but it works |
| 07:07:19 | FromGitter | <bevo009> oh precision=4 gives 3 places (4 total) |
| 07:08:01 | FromGitter | <bevo009> How would I do printf-style precision, just for the places? |
| 07:08:52 | * | adeohluwa quit (Ping timeout: 246 seconds) |
| 07:09:49 | leorize | places + 1? |
| 07:09:55 | leorize | !eval import strutils; echo "The number $1 is $2 to $3 places" % ["pi", formatFloat(33.14159, precision = 4), $3] |
| 07:09:57 | * | clyybber joined #nim |
| 07:09:58 | NimBot | The number pi is 33.14 to 3 places |
| 07:10:05 | leorize | ah, not that nice then |
| 07:10:35 | * | absolutejam4 joined #nim |
| 07:10:57 | clyybber | Araq: You still here? |
| 07:11:19 | leorize | !eval import strutils; echo "The number $1 is $2 to $3 places" % ["pi", formatFloat(33.14159, ffDecimal, 4), $3] |
| 07:11:22 | NimBot | The number pi is 33.1416 to 3 places |
| 07:11:33 | leorize | @bevo009: there you to^ |
| 07:11:34 | leorize | go* |
| 07:13:25 | FromGitter | <bevo009> beautiful |
| 07:13:35 | FromGitter | <bevo009> Thanks loerize! |
| 07:13:43 | FromGitter | <bevo009> *leorize |
| 07:15:46 | FromGitter | <bevo009> !eval import strutils; echo "The number $1 is $2 to $3 places" % ["pi", formatFloat(3.14159, ffDecimal, 3), $3] |
| 07:15:49 | NimBot | The number pi is 3.142 to 3 places |
| 07:16:07 | FromGitter | <bevo009> Just testing the NimBot :) |
| 07:17:08 | FromGitter | <Riderfighter> Hello everyone 👋 |
| 07:17:31 | leorize | o/ |
| 07:22:33 | * | absolutejam4 quit (Ping timeout: 245 seconds) |
| 07:23:49 | FromGitter | <bevo009> So I saved that last !eval as a comment, and Nim highlights it red ⏎ Does #! have a special meaning in Nim? |
| 07:24:43 | leorize | #! is the interpreter sign in most *nix system |
| 07:25:07 | leorize | your editor probably just highlight it due to that |
| 07:25:14 | FromGitter | <bevo009> vscode |
| 07:25:43 | leorize | #! used to be the source code filter mark as well, but that changed |
| 07:26:30 | leorize | I'm not sure how up-to-date is the vscode extension |
| 07:26:37 | FromGitter | <bevo009> cool, I didn't think Nim used shebangs |
| 07:28:30 | leorize | nowadays `#!` doesn't mean anything to Nim |
| 07:29:21 | FromGitter | <bevo009> handy if you want to highlight a particular comment though :) |
| 07:29:41 | leorize | Araq's way of doing that is: `discard "comment"` |
| 07:30:19 | * | adeohluwa joined #nim |
| 07:47:14 | FromDiscord_ | <Sybe> Are there discord bot api extensions for nim? |
| 07:49:13 | * | adeohluwa quit (Remote host closed the connection) |
| 07:49:20 | leorize | https://nimble.directory/search?query=discord |
| 07:50:35 | FromDiscord_ | <Sybe> neato |
| 07:52:55 | * | nsf quit (Quit: WeeChat 2.4) |
| 08:06:15 | * | ng0 joined #nim |
| 08:15:10 | Araq | clyybber: be quick |
| 09:13:05 | clyybber | Ugh, missed again. If you are still here, this is what I wrote: https://irclogs.nim-lang.org/25-07-2019.html#08:07:56 |
| 09:42:26 | FromGitter | <mratsim> @dom96 what about nim-metrics? |
| 09:42:40 | dom96 | https://github.com/status-im/nim-metrics/issues/10 |
| 09:44:09 | FromGitter | <mratsim> Ah I see |
| 09:54:14 | FromGitter | <Riderfighter> hello dom96! |
| 09:54:23 | dom96 | hey Riderfighter! |
| 09:57:34 | Zevv | hmm, where was this official stuff-to-do-before-1.0 list? |
| 09:59:31 | dom96 | there is a milestone on github |
| 10:01:50 | Zevv | ah right, thanks |
| 10:06:26 | FromGitter | <Riderfighter> o/ Zevv! |
| 10:22:14 | Zevv | oi |
| 10:26:09 | Zevv | dom96: been overthinkin this whole async discussion, and I changed my mind: chronos is cool and all, but you made a lot of valid points: a lot of the issues with async1 have been addressed, API compatiblity truly matters, and there is just FUD going around. We should keep track of what they are doing to see if any of their fixes would apply to the stdlib, and just let them be. |
| 10:26:54 | Zevv | I'd like to continue the work on the flowvar/await stuff with rayman22201, if he's still in |
| 10:26:58 | dom96 | Agree completely. |
| 10:27:06 | Zevv | rayman22201: you here by chance? |
| 10:27:30 | dom96 | Btw, some more FUD happening here: https://forum.nim-lang.org/t/5048 |
| 10:29:31 | leorize | well you'd need to address them :P |
| 10:30:06 | Zevv | well, there are also valid points in there. But having these mudfights in public does not help anybody. |
| 10:30:20 | dom96 | Yeah, I'm going to. Need to get some actual work done first though :P |
| 10:31:21 | dom96 | And sure, I agree that cancellation is important. Not important enough to use Chronos though |
| 10:32:31 | FromGitter | <Riderfighter> that forum thread feels passive aggressive once chronos gets involved lol |
| 10:33:07 | Zevv | But these discussions popping up in the forum every time soneone asks *anything* about async is not ok. What could we do to avoid that? |
| 10:33:34 | FromGitter | <Riderfighter> I guess no aggressive advertising of packages would probably be a good start |
| 10:33:59 | leorize | use moderation and split it to an another thread? |
| 10:34:05 | leorize | if nimforum supports that |
| 10:34:51 | Zevv | I bet cheatfate is just a good human being doing what he things is the Right Thing from his perspective, but it would be nice if he could see our point of view and not jump in every time |
| 10:35:36 | leorize | @Riderfighter: that's actually better nowadays, chronos original name was asyncdispatch2 |
| 10:35:47 | dom96 | leorize: sadly not supported, but I did design things with this feature in mind, so implementing it shouldn't be too difficult |
| 10:37:37 | FromGitter | <Riderfighter> I'm sure the people who talk about Chronos are doing good it for the good of all nim programmers, but it's just the way they are trying to talk about it in forum threads that is unhealthy and that is honestly not ok :L |
| 10:38:09 | * | dddddd joined #nim |
| 10:38:35 | Zevv | just to get my picture complete - cheatfate is doing chronos, and mratsim is a user of chronos in the same company, something like that? |
| 10:38:47 | dom96 | Zevv, yep |
| 10:39:06 | dom96 | cheatfate is employed by Status and mostly works on Chronos (AFAIK) |
| 10:39:20 | FromGitter | <Riderfighter> What's Status? |
| 10:39:22 | Zevv | what is mratsims viewpoint on all this? |
| 10:40:33 | leorize | @Riderfighter: status.im |
| 10:40:45 | FromGitter | <Riderfighter> Thank you! |
| 10:41:11 | FromGitter | <Riderfighter> btw I hope no one takes anything I say in a wrong way, I don't mean any harm :) |
| 10:41:11 | leorize | they're using Nim to create one of the first implementation of Etherium 2.0 |
| 10:41:48 | FromGitter | <Riderfighter> Nimbus right? |
| 10:42:01 | leorize | yea |
| 10:42:16 | * | stefanos82 joined #nim |
| 10:42:19 | FromGitter | <Riderfighter> Yeah I was looking at that repo yesterday and it was really cool haha |
| 10:42:24 | Zevv | @mratsim you here? |
| 10:42:38 | FromGitter | <mratsim> yep |
| 10:43:39 | Zevv | cool. I'm trying to figure a way to get this whole problem properly going - it's 50% technical and 50% people stuff it seems. And I'm not too good at people stuff. |
| 10:43:57 | FromGitter | <Riderfighter> What are you working on Zevv? |
| 10:44:03 | FromGitter | <Riderfighter> I like people stuff. :) |
| 10:44:04 | FromGitter | <mratsim> Well, I guess it was my fault for mentionning chronos in the first place |
| 10:44:42 | FromGitter | <Riderfighter> Nah @mratsim you're fine, conflicting ideologies almost always provides the pathway for healthy growth |
| 10:44:44 | Zevv | well nevermind that, it is just that we need a way out of this. I personally changed my mind overnight, it's not simple stuff. But it is currently block things. |
| 10:45:00 | dom96 | IMO it's fair to mention Chronos, as long as you include a disclaimer that explains the risk of using it to our community. |
| 10:45:10 | Zevv | I was working with rayman22201 on these flowvar things, and we both just kind of dropped out because of motivational issues. Which is a shame. |
| 10:45:21 | FromGitter | <mratsim> sounds good |
| 10:45:46 | FromGitter | <mratsim> by the way regarding FlowVar, the author of the channel based work stealing sent me his code for his thesis |
| 10:46:05 | Zevv | There is quite some work to do on async*, that is true. I have been through various levels of the implementation and there simply is some cruft in there. But that's the way software works. |
| 10:46:18 | FromGitter | <mratsim> so I guess I'll work a bit more on Nim multithreading and see if I can come up with a couple of alternative implementations |
| 10:46:42 | FromGitter | <Riderfighter> would anyone be interested in writing a clientless botting framework for a game with me, although I must warn you that I'm not the strongest nim coder :) |
| 10:46:44 | Zevv | mratsim: cool! (but lets discuss that later :-dubble-parenthis-close |
| 10:47:25 | Zevv | But one thing I'd like to fix first, which is this constant brining up of 'use chronos' if people ask things about async. Because that is truly demotivating :/ |
| 10:47:53 | FromGitter | <Riderfighter> Its not just demotivating its just aggressive advertising :L |
| 10:48:11 | FromGitter | <Riderfighter> Its unhealthy for both packages imo |
| 10:48:14 | Zevv | We simple do not have people working on this full time, so we simply *can not* compete. But we don't have to. "Good enough" is also good enough. |
| 10:48:52 | Zevv | Yesterday I brought up the idea of creating some kind of common API or glue layer, but it seems that chronos and stdlib just are too far apart for that. |
| 10:49:12 | FromGitter | <mratsim> Mmmh, I don't agree, competing packages are fine. It's a question of attitude. ⏎ ⏎ There are like 3 different protobuf packages or even 2 different array library packages |
| 10:49:40 | Zevv | I don't know cheatfate well, but from my only personal communication with him I know he has pretty strong opinions :) |
| 10:49:41 | FromGitter | <mratsim> Different visions can coexist, and actually should for a healthy ecosystem |
| 10:49:50 | Zevv | mratsim: ^ |
| 10:49:54 | FromGitter | <Riderfighter> ^ I agree with this 100% |
| 10:50:19 | Zevv | and really: having chronos pointing out the flaws of async is a good thing - that shows us what to work on |
| 10:50:27 | FromGitter | <Riderfighter> ^ |
| 10:50:33 | dom96 | Competing with the standard library does not lead to a healthy ecosystem |
| 10:50:38 | FromGitter | <mratsim> so just like dom said, it's about managing expectations. I.e. you can use chronos but you risk not being able to use other packages based on standard library asyncdispatch |
| 10:50:43 | Zevv | but I hope we, or someone, can have a chat with cheatfate to ask him to give us some slack. |
| 10:51:50 | FromGitter | <mratsim> @dom96, yes but there should be a process to promote evolution of the standard library. I am extremely disatisfied with the state of the crypto lib in the sandard library for example |
| 10:52:09 | Zevv | mratsim: I'm 100% with you on this |
| 10:52:32 | Zevv | I do not want to reach out to a pool of variable-quality external nimbles for my sha256 |
| 10:52:33 | FromGitter | <Riderfighter> speaking of crypto, anyone know if there is an ARC4/RC4 lib ? |
| 10:52:34 | FromGitter | <mratsim> otherwise we just pile up technical debt |
| 10:53:02 | Zevv | mratsim: part of the problem is that stdlib work is not really sexy. It's plumbing and you smell of shit at the end of the day |
| 10:53:19 | dom96 | Yes, but this is where we get into arguing whether evolution is necessary. The current async await implementation is already the third of networking in the stdlib, there is a point where you have to say "this is good enough, it's time to stop" |
| 10:53:24 | Zevv | I would hate for npeg to go into the stdlib - it is *my* personal cool project! |
| 10:53:30 | dom96 | *the third iteration |
| 10:54:08 | FromGitter | <mratsim> that's true. But another thing to take into account is that Status libraries will be audited and be used in production with lots of financial and reputation loss potential. |
| 10:54:41 | dom96 | Fine, so use them. But don't encourage our community to use them. It hurts us long term. |
| 10:54:42 | Zevv | mratsim: right, very true. But I can't find a solution to leverage that in the nim community without breaking stuff. |
| 10:54:44 | FromGitter | <mratsim> I.e. this will be a tremendous marketing advantage in the future |
| 10:55:13 | Zevv | Status' goals are not necissarily Nim's goals - if Nim would rely on chronos and status decides to make a big change, they will just do that, and we face the same issue again in a few years. |
| 10:56:34 | FromGitter | <mratsim> But dom96, you often said that you lack time, and it seems like you are spread thin on many projects like nimble, the nimforum and others. We have a vested interest to make the Nim async story the best possible, the expertise to carry it on and also the financial resources to secure it. |
| 10:57:10 | Zevv | mratsim: also all very true. But what do you propose then? |
| 10:57:58 | dom96 | Yes, this is all true. I would argue that you should have worked within the confines of the stdlib from the beginning |
| 10:58:38 | dom96 | Are you going to reimplement more of the stdlib too? Just because it allows you to break it and move fast? |
| 10:58:41 | FromGitter | <mratsim> I think we need a RFC and/or forum discussion. There are 2 areas of the standard library we can maintain: ⏎ ⏎ 1) crypto ⏎ 2) async [https://gitter.im/nim-lang/Nim?at=5d3c2e61ef58b93a8867c77d] |
| 11:00:42 | Zevv | Nexit-referenums :/ |
| 11:01:36 | FromGitter | <mratsim> @dom96, no we don't, what we do is having a staging repo here: https://github.com/status-im/nim-stew ⏎ ⏎ We keep the stdlib backports like atomics or bitops (because we are on 0.19.6 still). ⏎ And also small utilities that might be good candidate for stdlib in the future [https://gitter.im/nim-lang/Nim?at=5d3c2f108aab922429ccb211] |
| 11:02:13 | dom96 | mratsim: So you do work within the confines of the stdlib for everything else, why is async special? |
| 11:02:16 | FromGitter | <Riderfighter> ~~Ignore me but imo I think that it would be nice to have two different async libs to choose from, since I might not want to have another dependency in my program~~ |
| 11:03:17 | dom96 | Riderfighter: it is nice in some ways, but very bad in others. Libraries like async need majority buy in to be useful. Otherwise you'll have libraries that are only compatible with one which will suck big time. |
| 11:03:32 | FromGitter | <mratsim> It's special because it's non-trivial and we had blocker bugs when chronos was started |
| 11:03:40 | dom96 | In fact, that's why forking async is the worst possible thing |
| 11:03:50 | FromGitter | <mratsim> also if you look we reimplemented bitops2 completely in nim-stew |
| 11:03:52 | dom96 | Forking other stdlib modules is fine, but async is effectively a platform |
| 11:04:03 | Zevv | it's not "the worst possible thing", it is just a pragmatic solution chosen by people who had a problem at that time |
| 11:04:15 | Zevv | shit happens. |
| 11:04:28 | dom96 | No, it's the worst possible stdlib module you could fork |
| 11:04:31 | dom96 | That's what I mean |
| 11:04:35 | dom96 | And that is true |
| 11:05:09 | FromGitter | <mratsim> I think threadpools are in the same class |
| 11:05:21 | Zevv | doesn't matter, because it is in the past. |
| 11:05:48 | FromGitter | <Riderfighter> its not really my place to try and encourage the altering of the standard lib, I put faith in the main contributors of the stdlib |
| 11:05:54 | Zevv | How do we get this going again? RFC's is cool, but prepare for a heated and long discussion with possible no outcome |
| 11:05:56 | dom96 | mratsim: Yes, except that far fewer libraries depend on threadpool. |
| 11:06:31 | Zevv | Does our benevolent dictator has opinions about this matter? That would count for a majority share of the votes for me, personally |
| 11:06:44 | FromGitter | <mratsim> he is in vacation |
| 11:06:48 | dom96 | Zevv, I think the best approach might be to have someone who's impartial to lead the discussion, perhaps yourself |
| 11:07:36 | Zevv | I hate to take that kind of responsibilities and my attention span is pretty short, but if that would help, I can do that |
| 11:07:41 | dom96 | And leading the discussion includes (re)moving posts that are going off-topic and anything else you need to do keep the conversation on track |
| 11:07:54 | dom96 | That's the only way I can see it working |
| 11:08:13 | FromGitter | <Riderfighter> Do you guys know if there is a specific person that handles the nim-lang site or if its handled through pull requests on a github? |
| 11:08:13 | dom96 | But the way I see it there are two options: |
| 11:08:18 | FromGitter | <mratsim> I think we should create a fresh topic or a Github RFC, and redirect further conversation to those |
| 11:08:29 | dom96 | Either Status agrees to contribute async changes into the stdlib and get rid of Chronos |
| 11:08:49 | dom96 | or, I (and others) agree to break the async API in the stdlib and adopt Chronos |
| 11:08:54 | Zevv | #1 not gonne happen, you know that |
| 11:09:05 | dom96 | #2 isn't gonna happen either |
| 11:09:17 | dom96 | And frankly I think there are stronger reasons for it |
| 11:09:35 | Zevv | but where is option #3 then? |
| 11:09:46 | Zevv | @mratsim: true. |
| 11:10:07 | FromGitter | <Riderfighter> #3 would probably be mutual package coexistence if I were to guess |
| 11:10:08 | FromGitter | <mratsim> And a couple of important questions: ⏎ ⏎ 1) Can we create a thin layer on top of either to expose the same functionality as the other ⏎ 2) If we migrate to one implementation, what does the migration path look like [https://gitter.im/nim-lang/Nim?at=5d3c3110840e287180552924] |
| 11:11:53 | Zevv | ok plan: if a few closely-involved people could agree on an initial RFC or forum post which states the issue and sub-issues. Prepare this behind doors, and then throw it out. In the issue we clearly state that we intend to moderate the discussion so that people can not complain if they see their posts removed. |
| 11:12:10 | * | Vladar joined #nim |
| 11:12:21 | Zevv | When is araq due back |
| 11:12:29 | leorize | IMO the biggest problem currently is differences between how cheatfate and dom think async should work |
| 11:12:41 | dom96 | Zevv, in like a week |
| 11:12:41 | leorize | and/or be implemented |
| 11:13:01 | FromGitter | <mratsim> 3rd solution is to use libuv :P |
| 11:13:32 | dom96 | 3rd solution is to zielmicha's library |
| 11:13:35 | Zevv | leorize: sure, but that's life, and people should get over it. Like said above: the fact that chronis exists makes it clear that stdlib is lacking. So use that as something positive to help the evolution of the stdlib. |
| 11:13:39 | FromGitter | <Riderfighter> sorry if restating my question is a bad but do you guys know if there is a specific person that handles the nim-lang site or if its handled through pull requests on a github? |
| 11:13:57 | leorize | nim-lang.org is on github iirc |
| 11:13:57 | FromGitter | <mratsim> pull requests |
| 11:14:03 | Zevv | Riderfighter: I believe that is narimiran, right? |
| 11:14:12 | FromGitter | <mratsim> https://github.com/nim-lang/website |
| 11:14:26 | * | charybdis joined #nim |
| 11:14:30 | FromGitter | <Riderfighter> thank you Zevv and @mratsim |
| 11:15:03 | dom96 | > the fact that chronis exists makes it clear that stdlib is lacking. |
| 11:15:14 | Zevv | no? |
| 11:15:15 | dom96 | Just because something exists doesn't prove that the alternative is lacking |
| 11:15:25 | Zevv | ok, "lacking for someone": |
| 11:15:58 | Zevv | that's evolution of technology for you; otherwise we would all still be hacking away hex opcodes on punchards, right |
| 11:16:00 | dom96 | Fair |
| 11:16:36 | Zevv | dom96: do you happen to know if araq even *has* an opinion about this kind of stuff? |
| 11:17:08 | * | charybdis quit (Read error: Connection reset by peer) |
| 11:18:09 | dom96 | He definitely agrees that adopting Chronos for v1 is too late |
| 11:18:28 | dom96 | or at least did the last time I spoke with him about it |
| 11:18:31 | Zevv | yah, I guess I remember him saying that |
| 11:19:30 | Zevv | cheatfate does not do irc or any other chat, right? |
| 11:20:11 | leorize | he used to do gitter iirc |
| 11:20:57 | leorize | @cheatfate: ping |
| 11:30:37 | Zevv | I don't see him in any of my logs of 2018 or 2019 |
| 11:30:55 | FromGitter | <Riderfighter> Would anyone be interested in making a clientless botting framework for a game or two with me, I have almost all parts of the games reversed protocol wise and the two games I have both use different base protocols, one is TCP and the other is UDP lmk if you're interested :) |
| 11:31:37 | dom96 | Riderfighter: might be worth trying to ask in the forum :) |
| 11:32:05 | FromGitter | <Riderfighter> Yeah I'll definitely ask there, but you never know if someone in one of the chats might be interested |
| 11:33:22 | FromDiscord_ | <djazz> I'm trying to make a wxWebView with https://github.com/PMunch/wxnim but i get some weird errors. Have anyone used wxWidgets before? |
| 11:34:45 | FromDiscord_ | <djazz> tried `let browser = cnew constructWxWebView()` but it doesnt work |
| 11:34:58 | FromGitter | <mratsim> just ping @PMunch |
| 11:35:46 | Araq | I used wxWidgets, I wrote the initial impl. |
| 11:36:05 | FromGitter | <Riderfighter> wait wxWidgets has something that can run html/css/js? |
| 11:36:07 | Araq | Zevv: I'm in contact with cheatfate fwiw |
| 11:36:17 | FromGitter | <Riderfighter> Hello Araq 👋 |
| 11:36:22 | FromDiscord_ | <djazz> yes, wxwidgets can run html/css |
| 11:36:24 | FromDiscord_ | <djazz> and js |
| 11:36:31 | Araq | I'll likely off within 5 minutes |
| 11:36:41 | FromDiscord_ | <djazz> it uses whatever web engine the platform uses |
| 11:36:48 | Araq | most 3rd world countries have better wifi... |
| 11:37:02 | FromGitter | <Riderfighter> Ugh I used up all 100Gb of my cell plan yesterday |
| 11:37:05 | FromDiscord_ | <djazz> on gtk3 its webkit, and i guess on windows its some IE/Edge thing |
| 11:37:11 | FromGitter | <Riderfighter> i'm getting speeds that are slower than 2G right now |
| 11:38:00 | Araq | so ... as I said, chronos is not for v1 of Nim's stdlib |
| 11:38:12 | FromGitter | <Riderfighter> Thank you djazz for talking about wxnim :) |
| 11:38:54 | FromDiscord_ | <djazz> in C++ I create a webview with `wxWebView::New(this, wxID_ANY, "url here")` |
| 11:39:24 | FromDiscord_ | <djazz> in C++ I create a webview with `wxWebView::New(parentFrame, wxID_ANY, "url here")` |
| 11:40:18 | Araq | and in the longer run... is it really so hard to make both play nice together? |
| 11:41:21 | leorize[m] | @djazz https://github.com/PMunch/wxnim/blob/06aebbc0d4f3335190f7af16a2dedfad3ab0cf78/private/webview.nim |
| 11:41:28 | leorize[m] | that file should have what you need |
| 11:41:38 | FromDiscord_ | <djazz> yeah im looking at it atm |
| 11:42:09 | FromDiscord_ | <djazz> wxNew seems like its what I need, but not sure how to call the right "wxNew"? |
| 11:42:37 | leorize[m] | supply the right params and it should just work |
| 11:44:01 | FromDiscord_ | <djazz> o, it worked |
| 11:45:29 | FromDiscord_ | <djazz> `let browser = wxNew(parentFrame, wxID_ANY, "https://djazz.se")` |
| 11:47:44 | FromDiscord_ | <djazz> guess i can set `:ptr WxWebView` to make it more explicit |
| 11:48:44 | dom96 | Araq, the API couldn't be further from what we have in the stdlib: https://github.com/status-im/nim-chronos/blob/master/tests/testserver.nim |
| 11:51:29 | FromDiscord_ | <djazz> would be nice to make it with genui syntax |
| 11:52:54 | leorize[m] | i've noticed that you can't dispose pointers created via wxnim :/ |
| 12:07:42 | * | adeohluwa joined #nim |
| 12:08:54 | * | adeohluwa quit (Remote host closed the connection) |
| 12:12:02 | dom96 | aww yeah. My thrift library works on both the JS backend and the C backend :D |
| 12:12:17 | FromGitter | <Riderfighter> what is thrift if I may ask? |
| 12:12:43 | dom96 | binary communication protocol |
| 12:12:58 | FromGitter | <Riderfighter> Do you have a link by chance? |
| 12:13:09 | FromGitter | <Riderfighter> I'm interested haha |
| 12:14:08 | dom96 | https://en.wikipedia.org/wiki/Apache_Thrift |
| 12:14:28 | FromGitter | <Riderfighter> sweet, thank you! |
| 12:14:34 | FromGitter | <Riderfighter> I wasn't sure if that was it lol |
| 12:14:35 | Zevv | dom96: doing some writeupping: is chronos originally a clean fork? Or was it partly clean start? |
| 12:19:29 | * | nif_ quit (Quit: ...) |
| 12:19:38 | * | nif joined #nim |
| 12:27:19 | FromDiscord_ | <djazz> pretty cool! |
| 12:27:19 | FromDiscord_ | <djazz> https://cdn.discordapp.com/attachments/371759389889003532/604651022895284234/Screenshot_20190727_142650.png |
| 12:43:01 | dom96 | Zevv, AFAIK it's a fork |
| 12:43:06 | Zevv | right |
| 12:56:35 | * | nsf joined #nim |
| 12:56:44 | Zevv | @dom96, @mratsim, @rayman22201: https://github.com/zevv/nim-async-issue. Any feedback appreciated |
| 12:57:54 | Zevv | on a practical note: how would I even be able to do moderation? |
| 12:58:47 | * | clyybber quit (Quit: WeeChat 2.5) |
| 12:59:25 | FromGitter | <mratsim> I think we should use Github PR for commenting |
| 12:59:48 | FromGitter | <mratsim> but the text is already committed |
| 13:00:04 | Zevv | no this is just a quick personal repo for sharing here |
| 13:00:08 | FromGitter | <mratsim> Maybe comment directly on the commit? https://github.com/zevv/nim-async-issue/commit/5b81cfd5783bf65a597b9e6d4be896dcd44b8517 |
| 13:00:11 | FromGitter | <mratsim> ah ok |
| 13:00:33 | Zevv | this is just closed here to get the PR questions setup, not to discuss them |
| 13:00:58 | Zevv | so am I asking the right questions, and does the background store make sense |
| 13:01:24 | Zevv | and I'm not sure on how to specific to be here on references. Does it really make sens to point to these forum threads? |
| 13:02:10 | FromGitter | <mratsim> Yes threads and IRC and bugs make sense |
| 13:02:46 | Zevv | I feel a bit bad I have not spoken to cheatfate on this, I hope you are a bit of representative for him |
| 13:04:34 | * | sealmove joined #nim |
| 13:07:41 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 13:08:51 | * | laaron joined #nim |
| 13:19:08 | FromGitter | <mratsim> Awesome work, I forwarded your repo don't worry |
| 13:22:21 | dom96 | Zevv, nice. Sounds good. |
| 13:22:45 | Zevv | sweet. I'll wait for cheatfate to give his comments and then we find a place to discuss it. |
| 13:23:11 | Zevv | mratsim: you made clear that the point is not to *discuss* there, right? |
| 13:23:36 | sealmove | @dom96! hi, can you help me with forum account? |
| 13:23:44 | dom96 | sealmove, sure, what's your nick? |
| 13:24:16 | sealmove | sealmove. i deleted it because i couldn't activate it, and now i get "hash ident error" when i try to re-create it. |
| 13:25:20 | dom96 | You might need to clear cookies for forum.nim-lang.org |
| 13:25:46 | dom96 | do you get this when creating a new account? Have you tried using a different nickname? |
| 13:26:05 | sealmove | i haven't tried different name. wow, if it's cookies i'll be embarassed |
| 13:28:14 | FromGitter | <mratsim> @Zevv, the point is to have the standard library/chronos discussion in it's own thread and re-rail the thread from yesterday to the original poster question |
| 13:29:14 | Zevv | right |
| 13:29:28 | sealmove | @dom96: nop, same issue. when I click "Create account" it says "Unknown error" but DOES send me an e-mail with an activation link. Then when I click the "Activate" button in the link, it says "Invalid ident hash". |
| 13:29:54 | dom96 | can you log in? |
| 13:30:10 | dom96 | are you registering as sealmove? |
| 13:30:16 | sealmove | yes |
| 13:30:26 | sealmove | i can't log in |
| 13:30:37 | sealmove | since i deleted the account in order to re-make it |
| 13:30:47 | sealmove | before that i could log in but not post (not activated) |
| 13:31:37 | dom96 | I'd have to mess with the DB to fix this I think, can you register with a different nick? |
| 13:33:04 | sealmove | :( |
| 13:35:28 | sealmove | I don't care if it takes months to be fixed, but I really want this name. Thanks for taking a look in any case. |
| 13:35:51 | dom96 | just create one sealmove_ for now and create an issue in NimForum's github |
| 13:35:57 | dom96 | We will be able to rename it later |
| 13:36:27 | FromGitter | <mratsim> @Zevv I've added 2 issues about questions/discussions that I think are closely related to the current async discussion and may lead to a new async-like stdlib/fork split. |
| 13:36:51 | sealmove | @dom96: thanks! |
| 13:37:13 | FromGitter | <mratsim> Not sure if we should ask them at the same time or not, that might be overwhelming but I think it's something to keep in mind. |
| 13:39:43 | Zevv | mratsin: thanks |
| 13:39:45 | dom96 | I don't think we should, those are off-topic |
| 13:40:29 | Zevv | yeah, these are quite broad subjects in themselves. |
| 13:41:28 | FromGitter | <mratsim> I don't think they are off-topic. |
| 13:41:51 | Zevv | no, but we shouldn't let this thing get too big |
| 13:41:57 | FromGitter | <mratsim> Rust used to have several serialization API in their stdlib, until they landed on serde |
| 13:42:23 | FromGitter | <mratsim> yes I agree it's big topics |
| 13:52:25 | leorize | Zevv: you could have used a gist instead :P |
| 13:53:18 | leorize | also "noo ne" |
| 13:57:30 | Zevv | fixed, thanks |
| 13:57:49 | Zevv | yeah I tried a gist but then it messed up the formatting and I could'nt see how to change the file type and I just want to type in my editor |
| 13:57:54 | Zevv | so there's reasons for you :) |
| 13:58:25 | Zevv | so my plan: I wait for cheatfate, give him a day or two. I do not way for araq, and then I post this thing on the Nim RFC repo. |
| 13:59:26 | * | srqx joined #nim |
| 14:00:05 | * | srqx quit (Client Quit) |
| 14:00:44 | * | onionhammer joined #nim |
| 14:08:35 | * | lritter quit (Quit: Leaving) |
| 14:13:07 | dom96 | sounds good |
| 14:20:31 | * | gangstacat joined #nim |
| 14:25:14 | * | adeohluwa joined #nim |
| 14:42:49 | * | adeohluwa quit (Ping timeout: 246 seconds) |
| 15:05:42 | * | adeohluwa joined #nim |
| 15:07:43 | * | snifftek quit (Remote host closed the connection) |
| 15:11:23 | FromGitter | <rishavs> in nim, how do I insert a char into a string? ⏎ I am trying this; ⏎ ⏎ ```var text = "" ⏎ for i in 0..file_length-1: ⏎ text.insert(fileContent[i])``` [https://gitter.im/nim-lang/Nim?at=5d3c699b2136933a87fe960e] |
| 15:13:35 | * | adeohluwa quit (Ping timeout: 258 seconds) |
| 15:13:49 | dom96 | !eval echo("foo".insert('c')) |
| 15:13:51 | NimBot | Compile failed: /usercode/in.nim(1, 11) Error: type mismatch: got <string, char> |
| 15:13:58 | dom96 | !eval echo("foo".insert($'c')) |
| 15:14:00 | NimBot | Compile failed: /usercode/in.nim(1, 11) Error: type mismatch: got <string, string> |
| 15:14:10 | Zevv | woohoo! |
| 15:14:14 | dom96 | !eval import strutils; echo("foo".insert('c')) |
| 15:14:16 | NimBot | Compile failed: /usercode/in.nim(1, 28) Error: type mismatch: got <string, char> |
| 15:14:19 | Zevv | nim gol |
| 15:14:20 | Zevv | f |
| 15:15:05 | dom96 | !eval var x = "foo"; x.insert($'c'); echo(x) |
| 15:15:08 | NimBot | cfoo |
| 15:15:21 | dom96 | no overload to insert a char, so you need to convert to string with `$` |
| 15:15:31 | Zevv | Well, let's add that right away then, shall we |
| 15:17:38 | FromGitter | <rishavs> Thanks! |
| 15:18:44 | * | nsf quit (Quit: WeeChat 2.4) |
| 15:18:58 | * | laaron quit (Remote host closed the connection) |
| 15:19:30 | FromGitter | <rishavs> btw, why do we differentiate between a char and a string? |
| 15:19:47 | Zevv | we're not. But there is just no proc defined in the stdlib that takes a char. |
| 15:20:03 | Zevv | dom96: can it go in system next to the (string,string), or should I put it in strutlils? |
| 15:21:01 | FromGitter | <rishavs> Zevv, I meant that clearly char and string are two different types. I am interested in language design and wanted to understand why did nim go that route? |
| 15:21:03 | dom96 | it would be weird to put it in strutils IMO |
| 15:21:16 | Zevv | dom96: right, that's what though |
| 15:21:23 | dom96 | but Araq might have a problem with system growing |
| 15:21:34 | Zevv | let him reject the PR then |
| 15:21:37 | dom96 | :) |
| 15:21:58 | dom96 | He's on holiday, I can merge stuff while he's away :P |
| 15:22:07 | Zevv | rishavs: A char and string are just two distinct types: a char is basically a C char, or a number ranged 0..255 |
| 15:22:19 | Zevv | and a string is basically the same as a seq[char] |
| 15:23:54 | Zevv | wtf. Slice assigning with indices in reverse order does an insert?! what crap API is that |
| 15:25:57 | federico3 | any suggestion for fast json parsers in Nim? |
| 15:26:33 | Zevv | araqs packedjson |
| 15:29:30 | FromGitter | <kaushalmodi> !eval var x = "foo"; x.insert($'c'); echo x |
| 15:29:32 | NimBot | cfoo |
| 15:29:49 | FromGitter | <kaushalmodi> !eval var x = "foo"; x.add($'c'); echo x |
| 15:29:52 | NimBot | fooc |
| 15:30:04 | FromGitter | <kaushalmodi> ^ use add to append |
| 15:31:51 | FromGitter | <rishavs> Thanks Kaushal |
| 15:32:19 | FromGitter | <mratsim> why do you use insert instead of add? |
| 15:32:38 | FromGitter | <mratsim> ah didn't see Kaushal comment |
| 15:33:33 | FromGitter | <mratsim> @federico3 if you work with static types, you can also give nim-json-serialization a spin |
| 15:33:44 | Zevv | dom96: https://github.com/nim-lang/Nim/pull/11840 |
| 15:36:10 | FromGitter | <kaushalmodi> @rishavs kinda related: https://scripter.co/notes/nim/#representing-one-type-in-another |
| 15:37:21 | shashlick | Plug on the whole async discussion - forks and reimplements are a valuable feature of open source |
| 15:37:37 | shashlick | There's nothing new in this and every community has to go thru it |
| 15:38:20 | shashlick | It will be best to stick to the technical merits thru negotiations |
| 15:38:57 | dom96 | Zevv, there must be a more efficient implementation than just $c |
| 15:38:59 | shashlick | Expecting code to live forever is unrealistic, stdlib or 3rd party |
| 15:40:01 | shashlick | I look forward to a successful rfc and merge but if not, that's fine too - the community will be just fine |
| 15:40:44 | shashlick | And it will be best to understand the pros and cons of each clearly so if both survive then the community can be guided accordingly |
| 15:41:02 | Araq | the problem is that it creates a split, you can't support both async models in an support library |
| 15:41:02 | Araq | well ... that's the assumption anyway |
| 15:41:05 | Araq | afaict nobody even tried to do just that. There is always 'when defined' |
| 15:41:11 | Araq | and 'when declared' |
| 15:41:31 | Araq | so technically it IS possible, feasible, I don't know |
| 15:43:08 | Araq | tell clybber that I updated the spec |
| 15:43:37 | Araq | and it was always supposed to be read in this way, no bug here. |
| 15:43:40 | FromGitter | <mratsim> @zevv, @dom96, the fastest is to setLen(x.len + 1), copy c at position i and then copyMem the rest |
| 15:44:20 | Araq | if that's the fastest way you should file a bug report, 'add' is supposed to be as fast as your solution |
| 15:44:48 | FromGitter | <mratsim> insert is in the middle, add is always at the tail |
| 15:44:52 | federico3 | thanks Zevv and mratsim. Actually I don't need full json [de]serialization, only a parser that modifies a json stream on the fly |
| 15:45:16 | Araq | there is the parsejson stdlib module |
| 15:45:47 | Araq | used by both json.nim and packedjson.nim, it's basically a tokenizer |
| 15:49:04 | federico3 | thanks Araq |
| 15:49:26 | Araq | mratsim: if you prepend much, it's usually possible and better to append and then reverse inplace afterwards |
| 15:50:16 | shashlick | Well there is vim and neovim which splits the vim community - is arguable whether it is good or bad but there are people on either side |
| 15:50:42 | shashlick | Neovim people aren't going to ask non vim people to try them out |
| 15:51:06 | shashlick | So there's nothing new here but communities learning from each other and not getting distracted is ideal |
| 15:51:41 | shashlick | Ideally cheatfate and dom96 can come up with a healthy next step |
| 15:52:22 | Araq | uhm let's say that's really unlikely |
| 15:52:46 | Araq | but having competing implementations is not a bad thing, it's a good sign IMO |
| 15:53:11 | Araq | an alternative Nim implementation would also be welcome |
| 15:53:43 | * | nif quit (Quit: ...) |
| 15:53:51 | dom96 | Those aren't equivalent at all |
| 15:53:53 | * | nif joined #nim |
| 15:54:03 | dom96 | An alternative Nim implementation will still compile your Nim code |
| 15:54:13 | Araq | well yes, that's true |
| 15:55:32 | Araq | but I fear the current API put us into a corner and is hard to optimize further |
| 15:55:41 | leorize | Zevv: I think you should try to avoid a string allocation in the insert(var string, char, Natural) version |
| 15:55:57 | shashlick | Whatever the analogy, the market will adjust and be fine |
| 15:56:19 | FromGitter | <mratsim> the issue is the cost of adjusting |
| 15:56:44 | FromGitter | <mratsim> that might mean a fair share of library developers and/or users paying transition costs |
| 15:56:56 | shashlick | Nothing is free |
| 15:57:25 | shashlick | There's costs even if chronos didn't exist |
| 15:57:35 | shashlick | Breaking changes are inevitable |
| 15:57:48 | FromGitter | <mratsim> and that's true for all API strongly or loosely defined or undefined in the standard lib (i.e. crypto, serialization, streams) |
| 15:57:59 | Araq | gotta go again |
| 15:58:04 | Araq | bye |
| 15:58:17 | FromGitter | <mratsim> Hence my 2 additional issues: https://github.com/zevv/nim-async-issue/issues |
| 15:58:31 | FromGitter | <mratsim> --> how to fork replace in the stdlib ⏎ --> what is its role |
| 15:59:04 | leorize | I'd say if chronos could provide an asyncdispatch-compatible API, then we can lower the barrier of entry to the stdlib |
| 15:59:06 | FromGitter | <mratsim> I.e. like in biology, it should evolve to adapt with the times |
| 16:02:37 | leorize | I'd say a nice stdlib fork is https://github.com/xzfc/ndb.nim |
| 16:02:45 | leorize | really easy to migrate to |
| 16:03:34 | leorize | iirc Araq said if that package can also provides the rest of db_* family, then they could replace the stdlib version |
| 16:06:35 | rayman22201 | Sorry. @zevv pinged me but I was asleep on my side of the planet. Just getting caught up. |
| 16:06:41 | FromGitter | <mratsim> The discussion will be the same if they change the API |
| 16:06:59 | dom96 | shashlick, the cost in this case is in terms of friction for newcomers. Why would someone use Nim when its ecosystem is so fragmented? |
| 16:07:57 | rayman22201 | It's not just newcomers. It's a big library ecosystem cost. |
| 16:08:25 | FromGitter | <mratsim> and blog posts/documentation which we are sorely lacking |
| 16:09:07 | rayman22201 | @zevv said it well. "is not a good thing given the fundamental layer at which these libraries operate" |
| 16:09:30 | rayman22201 | Arguably async is more fundamental than a database layer. |
| 16:09:41 | FromGitter | <mratsim> yes |
| 16:10:01 | FromGitter | <mratsim> it's more comparable to someone forking the streams API |
| 16:10:15 | FromGitter | <mratsim> or multithreading |
| 16:10:19 | rayman22201 | Yes. I agree with that analogy |
| 16:11:28 | rayman22201 | On the bright side. We are lucky we can even have this discussion. Many languages have things like async and threads baked into the runtime. Nim is powerful enough to let them be libraries. |
| 16:13:07 | shashlick | Again I think we should stay with the technical merits |
| 16:13:32 | shashlick | Impact on the community is secondary since you already have two sides here |
| 16:13:35 | FromGitter | <mratsim> It also restricts your implementation. Some async or threads implementations require continuation support so you need compiler help to restore registers or something like setjmp longjmp |
| 16:14:06 | FromGitter | <mratsim> threads --> thread schedulers |
| 16:14:08 | shashlick | If we keep raising the poor community, it will become a political issue |
| 16:24:43 | dom96 | wow, just found an issue in asyncnet. Amazed it stayed there for so long without detection |
| 16:27:04 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 16:29:17 | Zevv | shashlick: feel free to comment on the PR, but dont provide answers yet, I just wan to make sure were asking the right questions |
| 16:29:28 | Zevv | dom96: well, there you have it :) |
| 16:29:57 | shashlick | @Zevv I won't claim to know anything about async |
| 16:30:34 | rayman22201 | @shashlick: too late. It's already politicial. Can't close Pandora's box once it's been opened 😝 |
| 16:30:47 | shashlick | I just feel we don't need to worry about it too much, people cannot be stopped from doing what they think is right |
| 16:31:06 | shashlick | But we can aspire to collaborate and build something better together |
| 16:31:52 | shashlick | And that can only happen with a technical deep dive and the willingness from both parties to work together |
| 16:32:08 | rayman22201 | It's the second part that is the problem. |
| 16:33:05 | shashlick | That is because one or both parties, I don't know, think the other isn't willing |
| 16:33:58 | shashlick | Plus again the idea that my code is better than yours |
| 16:34:08 | rayman22201 | important people on the issue have said that that they don't want to work together. You can't force them. |
| 16:34:13 | shashlick | Putting it rather crudely |
| 16:34:38 | shashlick | Then there is nothing to worry about, take care of your own code and move on |
| 16:34:53 | shashlick | Why to get distracted |
| 16:36:14 | shashlick | If you don't want to work together and concede on certain aspects, don't expect the other party to |
| 16:36:16 | rayman22201 | Hard not to get distracted when there is loud arguing here and on the forum 😝 |
| 16:37:57 | shashlick | Don't distract with arguing or get distracted by arguing |
| 16:38:00 | Zevv | shashlick: I like your way of thinking about this, thats about my point of view as well. |
| 16:38:24 | rayman22201 | I agree as well. |
| 16:38:50 | shashlick | Arguments without technical content are a waste of time in a technical forum |
| 16:39:06 | Zevv | right |
| 16:39:40 | Zevv | but i hate to see these discussions like recently on the forum - so Id rather see if we can get somrthing good out of this |
| 16:39:50 | shashlick | Like spaces vs tabs or vim vs emacs, it is a waste of time however fundamental you think that is |
| 16:39:55 | rayman22201 | Politics are necessary anytime humans are involved unfortunately. Unless we invent ai to write code for us, we have to find a way to motivate people to do the work. |
| 16:40:36 | shashlick | A strong opinion is a detriment if it isn't open to better ideas |
| 16:41:08 | shashlick | And a strong opinion should be backed by real data |
| 16:41:09 | rayman22201 | I agree |
| 16:41:28 | dom96 | omg, we need a nimsuggest that works desperately |
| 16:41:34 | dom96 | Can anyone find where this is defined? https://github.com/nim-lang/Nim/blob/devel/lib/pure/net.nim#L1011 |
| 16:41:40 | rayman22201 | I may write something longer on Zevvs rfc later. But I have to go no. Bbl. |
| 16:42:02 | dom96 | (And don't say openssl.nim:513) |
| 16:42:35 | rayman22201 | https://github.com/nim-lang/Nim/blob/dc38b88f7ecd2d690d22cd107388cf95122c9eb0/lib/wrappers/openssl.nim |
| 16:42:42 | rayman22201 | Lol 😆 |
| 16:43:13 | rayman22201 | It's a wrapper around the c function |
| 16:43:28 | rayman22201 | You have to go to the openssl .h file |
| 16:43:51 | FromGitter | <deech> Compile time functions are currently evaluated even when they don't typecheck: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d3c7f47840e287180575130] |
| 16:44:06 | dom96 | rayman22201, sslRead != SSLRead |
| 16:44:50 | FromGitter | <deech> compile time/run time interaction is insanely buggy and dangerous right now ... |
| 16:46:27 | rayman22201 | @dom96 are you sure? Based on the type signature it looks like it is |
| 16:46:47 | dom96 | rayman22201, 90% sure. I changed it the call to `sslRead` and got a mismatch error |
| 16:47:01 | dom96 | also, Nim is case sensitive on the first letter |
| 16:47:26 | dom96 | I did grep for SSLRead though and didn't see any definitions so I don't even know what is going on anymore |
| 16:47:46 | rayman22201 | Weird. Idk then... |
| 16:48:16 | rayman22201 | Anyway. Have to go for real now. Bbl |
| 16:48:26 | rayman22201 | Good luck! |
| 16:51:00 | FromGitter | <deech> I once again implore the powers that be to get rid of `{.compileTime.}` in favor of, eg. `static proc foo ...`. It isn't just another pragma and treating that way is making it unnecessarily difficult and annoying to get compile/runtime interaction right in the compiler. |
| 16:51:09 | dom96 | Anyway, this was subtle: https://github.com/nim-lang/Nim/pull/11841 |
| 16:52:33 | dom96 | deech: report that type checking bug on github, sounds like a VM issue. `static proc foo` vs. {.compileTime.} is just syntax, how would this help the implementation? |
| 16:54:05 | FromGitter | <deech> Because as I said `compileTime` isn't just another pragma, it broadly affects semantics and type checking, I say this as someone who's been deep diving the Nim type checker. |
| 16:57:53 | FromGitter | <deech> For that matter why even have a `static: ...` block, why not just do `block {.compileTime.}: ...`? The reason is that there was a recognition that compile time blocks and runtime blocks are very separate concepts, that same recognition should be pervasive across the all constructs. |
| 16:58:56 | FromGitter | <deech> I'd even suggest that compile time constructs should have their own namespace and maybe dedicated modules. |
| 16:59:55 | leorize[m] | dom96: iirc nimfind is the standalone nimsuggest |
| 17:00:06 | dom96 | As far as I see it this is just a syntactical design decision. Nim also does not have `public` but instead uses `*`. |
| 17:00:14 | dom96 | `static proc` just doesn't fit the language's syntax |
| 17:00:15 | FromGitter | <arnetheduck> seriously? async-vs-chronos *again*? it's very, very simple - we felt we had reason to develop a separate library - thus it comes down to two possibilities: ⏎ ⏎ a) we're incompetent ⏎ b) the status quo did not meet our requirements ⏎ ... [https://gitter.im/nim-lang/Nim?at=5d3c831fb2f4075cb8112f3d] |
| 17:02:25 | Zevv | dom96: should I rework the insert for speed? This is indeed braindead, but it was the most simple |
| 17:04:13 | dom96 | Zevv, I would say so. Things like this need to be performant. |
| 17:05:09 | Zevv | true |
| 17:05:18 | dom96 | arnetheduck: This topic will continue to reappear as long as this keeps happening: https://forum.nim-lang.org/t/5048#31684 |
| 17:05:29 | rayman22201 | @arnetheduck see the Cheatface forum posts. The mud slinging is going both ways |
| 17:05:59 | rayman22201 | That's the unhealthy part. Not the fork |
| 17:06:17 | Zevv | updated by rebase |
| 17:07:18 | Zevv | argh me and git :/ |
| 17:07:52 | rayman22201 | @Dom96 interesting openssl bug. Nice find. Did you find SSLread or was that tangential? |
| 17:08:12 | dom96 | that was tangential, I was just searching things around the net module and found that call. Still puzzled by it. |
| 17:09:24 | rayman22201 | Weird. |
| 17:09:58 | Zevv | hm why does this string insert even use a byte loop to move the tail? Does the compiler understand it's memcpy()ing there? |
| 17:10:38 | * | clyybber joined #nim |
| 17:11:04 | dom96 | rayman22201, btw, wanna accept that PR for me? Then I'll have an excuse to just merge it |
| 17:11:13 | dom96 | We really need our community to help with reviews more |
| 17:12:31 | Zevv | pff this should really memcpy |
| 17:14:02 | FromGitter | <deech> dom96, fine whatever, it's not about bikeshedding language syntax but that the situation right now is pretty bad this is just one bug of many buggy behaviors that fall out of the current design ... |
| 17:14:08 | rayman22201 | @dom96 Define accept? Lol. Just a "looks good" comment? |
| 17:14:20 | dom96 | rayman22201, precisely :D |
| 17:14:26 | rayman22201 | Sure |
| 17:14:26 | dom96 | rayman22201, omg, I found it, it's defined as SSL_Read |
| 17:14:47 | rayman22201 | Ohhhh. That makes sense |
| 17:15:24 | dom96 | deech: I'm by no means an expert on this, so I'm probably completely wrong, so don't get discouraged by my words. Feel free to create an issue for this too or a forum thread to discuss it |
| 17:15:59 | dom96 | rayman22201, and now I can no longer say "Style insensitivity never bit me" |
| 17:16:06 | rayman22201 | Lol |
| 17:16:39 | dom96 | Still not too late to get rid of it :( |
| 17:17:14 | FromGitter | <deech> dom96, re: getting rid of style sensitivity, yes please. :) |
| 17:17:16 | dom96 | But I've already been there... https://forum.nim-lang.org/t/4388 |
| 17:18:00 | clyybber | Far too late IMO |
| 17:18:05 | Zevv | well, if we're breaking thins that bad, me might as well merge Chronos in :) |
| 17:18:08 | rayman22201 | Or fix nimsuggest |
| 17:18:16 | clyybber | Zevv: Right |
| 17:18:30 | FromGitter | <deech> Either that or `nimgrep`or some other tool spits out all the places where identifiers match ... |
| 17:18:41 | clyybber | But I really think style insensitivity is a killer feature |
| 17:19:14 | dom96 | Zevv, honestly would be tempted for that :P |
| 17:19:28 | FromGitter | <deech> clyybber, I'm going to 180 and agree, but without great tooling support it is a feature that will kill the user ... |
| 17:19:54 | rayman22201 | So let's fix the tools. Tools all the things! 😁 |
| 17:20:35 | FromGitter | <deech> I've honestly come around to that for every language I work with ... |
| 17:20:46 | clyybber | deech: That I agree upon |
| 17:21:02 | dom96 | yeah.. tools are also necessary for Nim's lack of explicit namespacing |
| 17:21:55 | dom96 | but I agree with Araq that people who argue about this are conveniently ignoring the fact that even with explicit namespacing there are still cases where you don't know where a method resides |
| 17:23:49 | FromGitter | <deech> Yeah, namespaces are good, macros, templates, procs, let/var assignment all sharing one namespace is a bad default. |
| 17:25:10 | clyybber | I disagree, having different namespaces for templates procs and macros is confusing |
| 17:25:36 | clyybber | even the current division between iterator namespace and proc namespace is a problem IMO |
| 17:26:52 | FromGitter | <deech> clybber, I could see that, I'm also coming from Haskell where we don't have enough namespaces and it makes life quite annoying. |
| 17:30:02 | clyybber | btw deech, I already once tried to unite static with .compileTime. here: https://github.com/Clyybber/Nim/commit/af2676de160566482b8c25ba88457c982b11fa36 |
| 17:30:41 | FromGitter | <deech> clyybber, yes I remember. I wish it was embraced. :( |
| 17:44:25 | krux02 | @deech, iterators have their own namespace |
| 17:45:59 | krux02 | clyybber, you are right the way iterator namespaces are different than other namespaces in Nim and that in combination of the implicit iterator calling is not a good idea at all. |
| 17:47:13 | krux02 | But I don't think that a different syntax to call macros just to tell the compiler that the symbol comes from the macros namespace, is a bad thing at all. |
| 17:47:41 | krux02 | But don't worry, this is not something that would change for Nim. It is just too late for that. |
| 17:49:34 | Araq | not only that, it's also silly. Like d'oh, how would it even work? let x = foo.proc vs let x = foo.var ? |
| 17:50:03 | krux02 | no |
| 17:50:24 | krux02 | lisp has a different namespace for functions and variables. |
| 17:50:33 | Araq | well I don't care, I'm happy there is no RFC for it. |
| 17:51:18 | krux02 | you don't need to care ;) |
| 17:52:05 | Araq | just for the record: different namespaces for iterators was a design mistake |
| 17:52:30 | * | nsf joined #nim |
| 17:52:38 | krux02 | I agree on that one. |
| 17:53:04 | krux02 | but what about the implicit items/pairs call? |
| 17:53:24 | Araq | was a mistake too |
| 17:54:08 | clyybber | Araq: How would I generate such a bitwiseCopy? Make a new letSection? |
| 17:54:53 | Araq | clyybber: the idea was to use nkFastAsgn for this |
| 17:55:11 | Araq | and the C codegen needs to understand it (it already should?) |
| 17:55:19 | clyybber | Ok. I'll try |
| 17:57:59 | * | Trustable joined #nim |
| 17:58:22 | Araq | krux02: iirc there is a Lisp1 vs Lisp2 thing, one used different namespaces, the other didn't |
| 17:59:08 | clyybber | Araq: Its not too late for uniting namespaces of iterators and everything else, no? |
| 17:59:09 | Araq | https://stackoverflow.com/questions/4578574/what-is-the-difference-between-lisp-1-and-lisp-2 |
| 17:59:10 | Araq | yup, I remembered correctly :P |
| 17:59:48 | Araq | clyybber: for v1 it's definitely too late |
| 18:00:18 | Araq | for v2 it's fine but we'll have a *hard* time with system.`..` |
| 18:01:05 | clyybber | Why actually? |
| 18:01:40 | clyybber | Can't system.`..` just return a slice and in for loops the slice's items iterator will be called? |
| 18:01:45 | FromGitter | <alehander42> so guys, if i write an async gdb-mi protocol, is there a similar lib i can look |
| 18:02:07 | Araq | clyybber: ah, I forgot about this solution :P |
| 18:02:25 | Araq | its disadvantage was the poor codegen quality, but it could be detected in the Nim backend |
| 18:02:50 | clyybber | Yeah, I think so too. |
| 18:03:26 | * | tzui_ joined #nim |
| 18:03:56 | * | alexander92 joined #nim |
| 18:04:13 | * | alexander92 quit (Client Quit) |
| 18:04:46 | dom96 | why was implicit items/pairs a mistake? |
| 18:06:21 | Araq | dom96: it doesn't work well with templates/generics. We'll fix it though |
| 18:06:24 | * | tzui_ quit (Read error: Connection reset by peer) |
| 18:06:38 | Araq | but it's a weird feature interaction and could have easily be avoided |
| 18:06:54 | Araq | *been |
| 18:07:23 | * | actuallybatman joined #nim |
| 18:07:47 | Araq | and it brings us closer to Python, so *shrug*. I personally don't think it's worth it, 'for i in a' vs 'for i in mitems(a)' is not the most beautiful design |
| 18:07:54 | * | tzui_ joined #nim |
| 18:08:09 | * | tzui_ quit (Remote host closed the connection) |
| 18:08:13 | Zevv | It might be a mistake for technical reasons, but for the user point of view it is just intuitive and concise. The mitems is unfortunate, yes |
| 18:09:07 | FromGitter | <mratsim> @clyyber there is no more namespace difference between iterator and proc |
| 18:09:14 | FromGitter | <mratsim> it was removed in 0.18 iirc |
| 18:09:45 | FromGitter | <mratsim> or did I miss something? |
| 18:12:03 | Araq | I wrote an RFC about it and then abandoned the idea |
| 18:12:24 | Araq | it's like "fixing" ^1, months of work which we could also spend on incremental compilation or --newruntime or ... |
| 18:12:46 | Araq | (fixing ^1 did take months) |
| 18:13:14 | clyybber | With return type overloading for i in mitems(a) could be changed to for var i in mitems(a) I guess |
| 18:13:29 | Araq | please ... don't |
| 18:13:37 | kungtotte | What was wrong with ^1? |
| 18:13:41 | Araq | RTO is a bad idea |
| 18:13:53 | Araq | kungtotte: "only" some bugs with it |
| 18:14:09 | Araq | the compiler did it as a rewrite rule, ignoring side-effects |
| 18:14:18 | Araq | so stuff was evaluated multiple times |
| 18:14:32 | kungtotte | Ah |
| 18:14:34 | clyybber | Araq: I don't have strong feelings about it, but I guess a cut down version of it (only considering mutable/immutable) makes kind of sense |
| 18:14:37 | Araq | we did a reimplementation without compiler magic |
| 18:14:39 | clyybber | for iterators at least |
| 18:15:04 | Araq | 'for var' is also quite ugly IMO |
| 18:15:13 | Araq | but maybe it'll grow on me |
| 18:17:04 | * | tzui_ joined #nim |
| 18:17:51 | * | ng0 joined #nim |
| 18:18:10 | Araq | we should focus on the important points, threading, compile-times, stability. "destructors" is our answer for threading, "incremental compilation" is our answer for the growing compile-times, bugfixes for stability. it's been our plan for months now, it's still a good plan. |
| 18:19:09 | dom96 | nimsuggest is more important IMO |
| 18:20:32 | Araq | IC affects nimsuggest |
| 18:20:40 | clyybber | dom96: Actually, newruntime/destructors could help with nimsuggest |
| 18:20:49 | clyybber | as we could use valgrind to find the memory leaks |
| 18:21:04 | Araq | clyybber: uh, a bold claim. |
| 18:21:05 | dom96 | it's not about memory leaks, the basic functionality is broken |
| 18:21:21 | FromGitter | <deech> Araq, also compile time eval please. I am still working on it. Progress is being made but quite slow because it's a thorny problem and I have other things taking up my time right now. |
| 18:21:23 | dom96 | It needs to work out of the box in VS Code |
| 18:21:39 | Araq | the basic functionality works, but the VS plugin is evil |
| 18:21:43 | clyybber | dom96: Isn't that the problem of the VS Code extension? |
| 18:21:45 | dom96 | And yes, that might mean creating an official Nim VS code plugin |
| 18:22:10 | Araq | dom96: that's one option but I also have other ideas |
| 18:22:27 | dom96 | like what? |
| 18:22:35 | clyybber | lsp I guess |
| 18:22:50 | lqdev[m] | that was some fun http://rosettacode.org/wiki/Special:Contributions/Lqdev |
| 18:23:24 | Araq | dom96: bring IC to 'nimfind' |
| 18:24:00 | * | tzui_ quit (Read error: Connection reset by peer) |
| 18:24:05 | dom96 | Araq, huh? Incremental compilation? to `nimfind`? what does that solve? |
| 18:24:53 | Araq | there is no reason why we need this client-server setup, just pass file:line:col to 'nimfind' via a really simple plugin, nimfind gives you the information and *dies*. cannot leak, cannot be misconfigured |
| 18:25:18 | Araq | but for this nimfind must be really fast |
| 18:25:25 | Araq | and precise and that's where IC kicks in |
| 18:25:34 | dom96 | you're going back in circles |
| 18:25:37 | dom96 | this is what we had before |
| 18:25:53 | dom96 | it was too slow, so you decided to create a server |
| 18:26:04 | dom96 | What is wrong with the server setup? |
| 18:26:22 | Araq | nothing, if it worked |
| 18:26:31 | dom96 | why doesn't it work? |
| 18:27:00 | Araq | it leaks memory and we dunno where. its socket handling probably counts as "raping" the OS |
| 18:27:24 | Araq | it's complex and multi-threaded because it needs to respond quickly |
| 18:27:35 | Araq | it has more hacks inside it to make it respond quickly |
| 18:27:50 | dom96 | lol |
| 18:28:08 | Araq | and VSCode misuses it |
| 18:28:16 | clyybber | How does IC solve that? |
| 18:28:33 | dom96 | it'll cache the compilation making it faster |
| 18:28:39 | dom96 | presumably |
| 18:28:46 | Araq | yes |
| 18:29:24 | Araq | but as I said, it's only an idea |
| 18:29:28 | dom96 | and that's actually very similar to an idea I've had: just generate a large file for each .nim file containing each identifier with info about the identifier, regenerate whenever the file is modified. |
| 18:29:37 | Araq | a working LSP would be better |
| 18:29:46 | dom96 | LSP is just a protocol |
| 18:29:50 | dom96 | It doesn't fix anything |
| 18:30:01 | Araq | yes, but it does imply the server setup |
| 18:30:40 | dom96 | I've been saying this for a long time now: a good LSP implementation should manage a nimsuggest instance (along with other providers which might run faster than nimsuggest and/or offer better info) |
| 18:30:55 | dom96 | nimsuggest doesn't need to implement LSP |
| 18:31:18 | Araq | ok, so you are saying LSP on top of 'nimfind' |
| 18:31:22 | * | Kaivo quit (Quit: WeeChat 2.5) |
| 18:31:25 | Araq | yeah, could work too |
| 18:35:05 | Araq | and I gotta go again, bye |
| 18:38:14 | clyybber | bye |
| 18:39:17 | * | tzui_ joined #nim |
| 18:42:03 | * | tzui_ quit (Remote host closed the connection) |
| 18:44:54 | FromGitter | <mratsim> @kungtotte ^1 was also broken on all libraries that overloaded the array bracket accessor, you needed to use a macro to catch the symbol and rewrite it so that it didn't cause issues with your container size. |
| 18:46:00 | FromDiscord_ | <Generic> the reason vscode starts so many instances of nimsuggest is that it can't automatically tell how the nim files are related |
| 18:46:43 | FromDiscord_ | <Generic> it is possible to specify one or more project files |
| 18:47:01 | FromDiscord_ | <Generic> with this information it's possible to open only as many instances of nimsuggest as needed |
| 18:50:39 | * | bars0 joined #nim |
| 18:53:57 | * | bars0 quit (Client Quit) |
| 18:54:39 | * | bars0 joined #nim |
| 18:58:49 | * | bars0 quit (Client Quit) |
| 19:00:32 | * | bars0 joined #nim |
| 19:07:17 | * | tzui_ joined #nim |
| 19:09:52 | * | bars0 quit (Ping timeout: 246 seconds) |
| 19:12:21 | * | tzui_ quit (Quit: Mutter: http://www.mutterirc.com) |
| 19:13:06 | * | tzui_ joined #nim |
| 19:15:26 | * | tzui_ quit (Client Quit) |
| 19:28:35 | * | bars0 joined #nim |
| 19:29:25 | * | bars0 quit (Client Quit) |
| 19:38:00 | * | absolutejam4 joined #nim |
| 19:38:57 | * | bars0 joined #nim |
| 19:45:08 | * | clyybber quit (Quit: WeeChat 2.5) |
| 19:51:08 | * | Vladar quit (Remote host closed the connection) |
| 20:09:35 | FromGitter | <awr1> one of these days i need to try to make a wrapper/library around ISPC |
| 20:14:05 | * | bars0 quit (Quit: leaving) |
| 20:15:40 | * | noonien joined #nim |
| 20:17:26 | * | tzui_ joined #nim |
| 20:18:30 | * | tzui_ quit (Client Quit) |
| 20:30:06 | * | rockcavera quit (Remote host closed the connection) |
| 20:37:26 | * | jjido joined #nim |
| 20:45:17 | * | nsf quit (Quit: WeeChat 2.4) |
| 20:51:39 | * | shomodj joined #nim |
| 20:54:26 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:56:48 | * | Jesin quit (Quit: Leaving) |
| 20:58:58 | * | actuallybatman quit (Ping timeout: 258 seconds) |
| 20:59:42 | * | Jesin joined #nim |
| 21:09:12 | * | Trustable quit (Remote host closed the connection) |
| 21:15:51 | * | actuallybatman joined #nim |
| 21:21:07 | * | actuallybatman quit (Ping timeout: 246 seconds) |
| 21:32:59 | * | tzui_ joined #nim |
| 21:36:01 | * | tzui_ quit (Client Quit) |
| 21:39:27 | * | tzui_ joined #nim |
| 21:41:04 | * | stefanos82 quit (Quit: Quitting for now...) |
| 21:42:09 | Araq | Generic: nimsuggest supports that for years now |
| 21:42:12 | * | tzui_ quit (Client Quit) |
| 21:43:21 | * | tzui_ joined #nim |
| 21:44:50 | Zevv | dom96: cheatfates response has been incorporated |
| 21:45:03 | Araq | huh? |
| 21:45:16 | Araq | what does that mean? |
| 21:45:53 | Zevv | we're putting up an RFC to get out of this async mud fight; cheatfate gave his feed back on the RFC text |
| 21:46:28 | Araq | oh... link? |
| 21:46:34 | Zevv | https://github.com/zevv/nim-async-issue |
| 21:47:22 | Zevv | some responses in the issues. The repo was is not ment for discussion, just to make sure we're asking the right questions. I was planning to not ask your input because you're on holidays, but since you're here :) |
| 21:49:47 | Araq | wow, good job, thanks! |
| 21:51:08 | Araq | I've said it before, but one assumption here is that it's hard to "build" on top of both async impls at the same time |
| 21:51:33 | Araq | and while that's very likely to be true, somebody should give it a real try |
| 21:52:02 | * | tzui_ quit (Quit: Mutter: http://www.mutterirc.com) |
| 21:52:13 | dom96 | wow, some of cheatfate's claims make me really sad |
| 21:53:25 | * | tzui_ joined #nim |
| 21:53:33 | Zevv | yeah, but I'll ignore that for now :) |
| 21:53:41 | Araq | most were accurate? like ok, now we don't leak anymore, but we did for months. you cannot blame him for not being entirely up to date with everything |
| 21:54:22 | Zevv | I'm trying my best not to blame anything or anyone, just static facts, state the problem and discuss solutions. |
| 21:54:27 | dom96 | bah |
| 21:54:33 | dom96 | Do I really need to go through it point by point? |
| 21:54:36 | solitudesf | there is this package which claims support for both https://github.com/Tormund/news chronos and asyncdispatch |
| 21:54:37 | Araq | and at least one important leak was a codegen bug, so you can blame me for that |
| 21:54:52 | Zevv | dom96: I guess not, it is not about these points |
| 21:55:15 | dom96 | Araq, which do you think are accurate? |
| 21:55:27 | Araq | we had memory leaks. |
| 21:55:38 | dom96 | I feel like I need to, otherwise people will keep repeating these "facts" |
| 21:56:11 | Zevv | one extreme way to look at this whole thing is to say: cheatfate is totally right, and chronos is totally better. then *still* we can not simple drop async, so how do we continue from here? Please refrain from responding to all those individual issues, I don't think that brings us any closer. |
| 21:56:18 | Zevv | If you refute 5, a 6th will come up |
| 21:56:55 | * | tzui_ quit (Client Quit) |
| 21:57:02 | Zevv | (to be clear, I'm not saying he *is* totally right and chronos *is* totally better, I just ment "assume that someone has the opinion that...") |
| 21:57:14 | Araq | "Your server and service is not DoSed just because it is not in first line, you hiding it behind nginx." is really harsh but we also had security problems |
| 21:57:14 | * | tzui_ joined #nim |
| 21:57:56 | Zevv | I'm going for a sleep now, let's discuss tomorrow where and how to put up this as an RFC, right? |
| 21:57:59 | Araq | I reviewed asynchttpserver and found a couple and I'm not nearly an expert on this |
| 21:58:19 | dom96 | Araq, come on, no sane person runs a production system off of a HTTP server that's inside a language's stdlib |
| 21:58:38 | Araq | well, Golang's is up for the task |
| 21:58:51 | Araq | and yeah, I know it's hard |
| 21:59:00 | Araq | and a good idea to *not* to do this |
| 21:59:01 | dom96 | This is just a stupid argument |
| 21:59:55 | Araq | httpbeast also had a silly issue where there was a doAssert() you could trigger with malicious input |
| 22:00:12 | dom96 | neither of which were designed for security |
| 22:00:57 | dom96 | This is all just noise |
| 22:01:10 | Araq | oh come on, there is a difference between "not designed for security" and being careless |
| 22:01:12 | dom96 | All that matters is: asyncdispatch *is* being used in production |
| 22:01:47 | dom96 | Seriously? |
| 22:01:58 | dom96 | httpbeast was written for one thing only: to win benchmarks |
| 22:02:01 | dom96 | And it achieved that goal |
| 22:02:14 | Araq | I wasn't aware |
| 22:02:24 | Araq | and I think that's a sad goal. but ok |
| 22:02:45 | Araq | and why not "design for security"? we can and should evolve |
| 22:02:45 | dom96 | https://github.com/dom96/httpbeast#httpbeast |
| 22:03:09 | dom96 | It's right there in the readme |
| 22:03:12 | Araq | "The server is still considered experimental but it is already used by the Jester web framework" |
| 22:03:17 | * | actuallybatman joined #nim |
| 22:03:24 | Araq | doesn't scream "for benchmark games only" |
| 22:03:25 | dom96 | asynchttpserver evolved with async in the stdlib, so of course it's not perfect |
| 22:05:09 | dom96 | So no matter what, it's never good enough |
| 22:05:23 | dom96 | security now, but then "it doesn't support http 2.0" |
| 22:05:24 | * | tzui_ quit (Remote host closed the connection) |
| 22:05:43 | dom96 | There comes a time when all this crap that you think is important has absolutely no impact |
| 22:05:52 | * | solitudesf quit (Ping timeout: 245 seconds) |
| 22:06:11 | * | tzui_ joined #nim |
| 22:06:15 | Araq | well let's not get carried away |
| 22:06:55 | Araq | I can understand most of Cheatfate's points but yeah, async is used in production and not only by our own stuff |
| 22:06:58 | dom96 | Also, I'm pretty freaking disappointed that you think benchmarks are a lame reason |
| 22:07:00 | dom96 | Thanks |
| 22:07:34 | dom96 | Glad I spent my time getting Nim acknowledged for its speed |
| 22:07:47 | Araq | excuse me |
| 22:08:20 | Araq | you linked me to its official page and I pointed out it doesn't say what you said |
| 22:08:44 | dom96 | You said that before you read the readme |
| 22:08:55 | Araq | but I can also phrase it completely differently |
| 22:09:03 | * | tzui_ quit (Remote host closed the connection) |
| 22:10:06 | Araq | please stop using 'doAssert' in protocol validation code. |
| 22:10:58 | dom96 | I have no idea what you're referring to to be honest |
| 22:11:07 | Araq | and it's a "sad" goal if all httpbeast does is to win benchmarks and nothing else. That's all I meant |
| 22:12:31 | Araq | dom96: about 'doAssert', ok, well. can we discuss the more important problems? |
| 22:12:56 | dom96 | I don't honestly see the point |
| 22:13:21 | dom96 | I acknowledge there are problems, my point is that they are not severe enough to warrant spreading FUD about asyncdispatch |
| 22:13:45 | dom96 | This is evidenced by the fact that asyncdispatch has been running in production for years |
| 22:14:19 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 22:16:05 | Araq | ok, I agree. but "FUD" is a weak counter-argument when cheatfate can simply replace older issues with newer issues |
| 22:16:18 | Araq | which are still open |
| 22:16:36 | dom96 | I'm not sure what you mean |
| 22:16:47 | Araq | on the other hand, that's exactly what FUD is ... hmmm |
| 22:17:15 | dom96 | What is happening here is dangerous for our community |
| 22:17:24 | dom96 | If this was any other part of the stdlib |
| 22:17:27 | dom96 | I wouldn't care as much |
| 22:18:00 | rayman22201 | If it happened with threadpools it would be bad too |
| 22:18:15 | dom96 | Async is a platform. It's a foundation for 90% of packages. For an ecosystem that is as small as Nim's, fracturing it even more is a disaster |
| 22:18:51 | Araq | meh, don't be dramatic, this cuts both ways |
| 22:19:22 | dom96 | No, it doesn't. Async is in the stdlib |
| 22:19:29 | dom96 | Which means it's established |
| 22:21:04 | Araq | if the ecosystem builtin on top of async is still small after these years in production, maybe it's an indicator of its quality? and yes, I'm aware the same applies to Nim and I am repeating the question for Nim. |
| 22:21:42 | Araq | *built |
| 22:22:49 | Araq | but these questions are better answered by outsiders |
| 22:22:59 | rayman22201 | That is a very good and hard question |
| 22:23:07 | Araq | for example, I could tell you what Ubuntu should do. |
| 22:24:04 | dom96 | there is no single reason a software project fails to get adoption |
| 22:25:28 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:25:58 | Araq | as I said, "for new projects use Chronos, async is in maintenance mode, please also port 3rd library code" is a viable outcome for me, after having done a real analysis. I know it's a bitter pill for you to swallow |
| 22:26:18 | Araq | but I did no such "real analysis" |
| 22:26:46 | dom96 | that's crazy |
| 22:26:56 | dom96 | so you've already made this decision? |
| 22:27:12 | Araq | no! |
| 22:27:26 | Araq | I haven't |
| 22:27:40 | Araq | and afaict Chronos isn't API stable anyway |
| 22:28:00 | dom96 | Right, so why suggest it to people /already? |
| 22:28:05 | Araq | I don't |
| 22:28:18 | Araq | please read again what I just wrote |
| 22:28:22 | dom96 | I know you don't, but others do |
| 22:28:30 | Araq | you fear a community split. |
| 22:29:02 | Araq | to avoid this split, that's *one* possible official stance to take |
| 22:31:02 | dom96 | Right, but what's the time line here? |
| 22:31:12 | dom96 | If chronos isn't API stable yet, when will it be? |
| 22:31:55 | dom96 | Is it fair for some to encourage others to use it when we don't even know what chronos will become? |
| 22:32:11 | FromGitter | <mratsim> I've already said it but repeating. We have a vested interest to make the Nim async story the best possible, the expertise to carry it on and also the financial resources to secure and audit it. ⏎ ⏎ The main issue is that we might still change the API |
| 22:37:08 | * | absolutejam4 quit (Ping timeout: 245 seconds) |
| 22:37:37 | * | shomodj joined #nim |
| 22:53:30 | rayman22201 | The problem here is communication. IMO forks and third party implementations are fine. It's can be a good way to evolve the ecosystem. But right now people are sending aggressive mixed messages that make the community look bad (especially to new people trying the language). |
| 22:54:48 | * | cheatfate joined #nim |
| 22:55:28 | cheatfate | rayman22201, so you think that somebody allowed to send "aggressive mixed messages" and all others must just silently accept it? |
| 23:00:54 | Araq | am I back? |
| 23:01:06 | rayman22201 | You are also sending aggressive messages. It's on both sides. Should we just accept your side? I'm not taking a side. I'm just saying that as a community, we should, pardon my bad language, "get our shit together", especially when it comes to new users. Because it's very confusing right now. There are better ways to suggest trying Chronos than throwing mud at the stdlib. |
| 23:01:10 | rayman22201 | @cheatface |
| 23:03:11 | * | krux02_ joined #nim |
| 23:04:46 | cheatfate | rayman22201, sorry but this was just mirrored reaction on statements made by "core developer". |
| 23:05:38 | * | actuallybatman quit (Ping timeout: 248 seconds) |
| 23:06:11 | * | krux02 quit (Ping timeout: 250 seconds) |
| 23:08:51 | rayman22201 | Status has done A LOT for for nim, and I know you all want the best for the language. |
| 23:09:56 | cheatfate | I'm here only as cheatfate so please do not mention Status as part of conflict here. This is my personal conflict. |
| 23:10:23 | rayman22201 | I just want to say that I know that and I respect their position. |
| 23:12:24 | rayman22201 | I think there just needs to be better communication about this. |
| 23:14:31 | shashlick | Is there any technical reason why the chronos improvements cannot be ported into the stdlib |
| 23:17:45 | rayman22201 | As far as I understand, no. It's totally possible. |
| 23:18:06 | * | tzui__ joined #nim |
| 23:18:10 | * | tzui__ quit (Client Quit) |
| 23:19:33 | rayman22201 | But, there are a few semantic / philosophical differences between the apis, but much of it can be ported. It's more a matter of manpower. |
| 23:20:31 | shashlick | Does async have to be in the stdlib |
| 23:21:07 | rayman22201 | lol, well, Chronos proves that it does not. The beauty of Nim :-) |
| 23:23:35 | rayman22201 | the problem is not, "does it have to be", the problem is backwards compatibility. The "cat is out of the bag", it's already in the std-lib. The Nim book uses, so new people will use it, and many community libs already use it. |
| 23:24:09 | rayman22201 | It's the same problem with any library in the std-lib really. |
| 23:24:26 | rayman22201 | It's hard to change api's after they become used. |
| 23:52:46 | * | laaron joined #nim |
| 23:55:50 | * | laaron quit (Client Quit) |
| 23:58:31 | * | laaron joined #nim |
