| 00:11:09 | noonien | is here any reason http://vpaste.net/h5pmC results in: `Error: cannot evaluate at compile time: lastField`? |
| 00:14:50 | noonien | seems like this is the issue: https://github.com/nim-lang/Nim/issues/8758 |
| 00:22:27 | * | cyberjpn joined #nim |
| 00:33:52 | * | cyberjpn quit (Ping timeout: 246 seconds) |
| 00:34:39 | FromGitter | <JasperJenkins> Make the static block into its own proc instead and call that in a static block. Generally keep ct and rt separated as much as possible. Something like this should work: http://ix.io/1Ia6/nim |
| 00:39:52 | noonien | yes, i ended up doing something like that, thanks! |
| 00:40:18 | FromGitter | <JasperJenkins> Or clean it up even more with a template: http://ix.io/1Iab/nim |
| 00:42:26 | noonien | i ended up doing something similar to this: https://github.com/nim-lang/Nim/issues/8758 |
| 00:42:36 | noonien | oops, this: http://vpaste.net/gaEKv |
| 00:53:14 | * | cyberjpn joined #nim |
| 00:54:52 | * | theelous3 quit (Ping timeout: 268 seconds) |
| 00:56:16 | * | [rg] quit (Ping timeout: 246 seconds) |
| 01:09:59 | * | [rg] joined #nim |
| 01:10:53 | * | rnrwashere joined #nim |
| 01:13:33 | * | rnrwashere quit (Remote host closed the connection) |
| 01:15:19 | * | rnrwashere joined #nim |
| 01:29:28 | shashlick | http://ducktape.blot.im/choosing-a-language-for-bioinformatics |
| 01:34:19 | * | [rg] quit (Ping timeout: 248 seconds) |
| 01:38:35 | * | cornfeedhobo quit (Quit: ZNC - https://znc.in) |
| 01:49:37 | * | cornfeedhobo joined #nim |
| 01:52:37 | * | rnrwashere quit (Remote host closed the connection) |
| 02:00:17 | * | banc quit (Quit: Bye) |
| 02:01:06 | * | rnrwashere joined #nim |
| 02:05:13 | * | rnrwashere quit (Ping timeout: 246 seconds) |
| 02:07:52 | * | cyberjpn quit (Ping timeout: 250 seconds) |
| 02:20:00 | * | deech quit (Ping timeout: 250 seconds) |
| 02:21:23 | * | banc joined #nim |
| 02:21:54 | * | dddddd quit (Remote host closed the connection) |
| 02:29:43 | * | [rg] joined #nim |
| 02:41:55 | * | cyberjpn joined #nim |
| 02:44:43 | * | Hexeratops quit (Remote host closed the connection) |
| 02:46:26 | cy1 | https://pastebin.com/KZSSHhcA identical code, identical syntax, the latter fails with Error: cannot use symbol of kind 'proc' as a 'field' |
| 02:46:31 | cy1 | That's a bug, right? |
| 02:47:27 | cy1 | oh I should say identical ASTs too |
| 02:49:12 | leorize | I saw a similar bug sometimes ago |
| 02:49:19 | leorize | you can try to look in the issue tracker |
| 02:52:47 | cy1 | https://github.com/nim-lang/Nim/issues/11091 maybe? |
| 02:57:53 | cy1 | Too bad you can't transform lists in templates, like transforming each element into an "of" branch of a case statement or something. |
| 03:06:13 | * | rnrwashere joined #nim |
| 03:12:22 | * | rnrwashere quit (Remote host closed the connection) |
| 04:11:13 | * | cyberjpn quit (Ping timeout: 246 seconds) |
| 04:15:28 | * | rnrwashere joined #nim |
| 04:19:39 | * | rnrwashere quit (Ping timeout: 248 seconds) |
| 04:20:13 | * | rnrwashere joined #nim |
| 04:21:53 | dvn | hi - can anyone point to some projects which use https://github.com/nim-lang/ui ? |
| 04:22:05 | dvn | s/some/any/g |
| 04:23:03 | * | nsf joined #nim |
| 04:24:38 | * | rnrwashere quit (Remote host closed the connection) |
| 04:27:03 | * | rnrwashere joined #nim |
| 04:32:22 | * | Intensitea joined #nim |
| 04:34:50 | * | Intensitea quit (Changing host) |
| 04:34:50 | * | Intensitea joined #nim |
| 04:43:19 | * | [rg] quit (Quit: Konversation terminated!) |
| 05:10:44 | * | narimiran joined #nim |
| 05:22:40 | * | leorize quit (Quit: WeeChat 2.3) |
| 05:42:45 | Araq | cy1, you can transform the list into a case statement via a macro |
| 05:47:48 | Araq | dvn, I used it here https://github.com/nim-lang/Nim/blob/devel/tools/downloader.nim but this is not yet alive |
| 05:53:37 | cy1 | Araq: Yeah, that probably would reduce the amount I need to go digging into an AST I just quoted... |
| 06:03:12 | * | krux02 joined #nim |
| 06:03:39 | * | solitudesf joined #nim |
| 06:09:39 | cy1 | I don't think you can make fragments of code in a macro though, like "case p.kind: makeOf(exp, flags): " etc. Have to make the whole case statement in the macro. |
| 06:11:20 | Araq | true |
| 06:15:20 | * | dddddd joined #nim |
| 06:17:47 | * | PMunch joined #nim |
| 06:28:04 | * | rnrwashere quit (Remote host closed the connection) |
| 06:28:36 | cy1 | looks like nnkOfBranch can't use a macro returning a list, to accept multiple expressions... |
| 06:28:50 | cy1 | if only there was some way to interpolate |
| 06:31:29 | cy1 | It just keeps requiring more context around the interesting part, for the macro call to be valid syntax |
| 06:31:51 | cy1 | can't make multiple expressions in an OfBranch, can't make an OfBranch, can't make a RecCase, can't make an ObjectTy, can't wrap an Asgn, so I have to go like statementlist[0][2][1][4][0].add(expr) or something |
| 06:34:13 | Zevv | cy1: If I understand you right: I do just that in npeg, take a look there. I have a list of IR, which gets expanded into a case wherea template gets expanded for each 'of' |
| 06:34:53 | Zevv | https://raw.githubusercontent.com/zevv/npeg/master/src/npeg/codegen.nim |
| 06:35:13 | Zevv | see genCode macro on the bottom |
| 06:37:43 | Zevv | let call = nnkCall.newTree(ident($i.op & "Fn")) ... cases.add nnkOfBranch.newTree(newLit(n), call) |
| 06:37:44 | cy1 | I'll take a look Zevv, thanks |
| 06:38:06 | rockcavera | is it possible to set a timeout to close an async socket? |
| 06:40:48 | cy1 | what I'm dealing with is like "of A,B,C,D,...:" where the number of expressions varies depending on the expression passed, rather than always being one or two. Could just make a bunch of redundant "of A: etc of B: etc" branches I guess... either way it can only be approached at the topmost level of statement list, AFAICT. |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:04:53 | * | gmpreussner joined #nim |
| 07:10:51 | FromGitter | <mratsim> @cy1 this might inspire you: https://www.phoronix.com/scan.php?page=news_item&px=GCC-9.1-Compiler-Released |
| 07:17:56 | Araq | "the option of dumping diagnostics/errors into JSON format" yay |
| 07:18:36 | FromGitter | <mratsim> argh it was the wrong paste |
| 07:18:50 | FromGitter | <mratsim> https://github.com/andreaferretti/patty |
| 07:18:56 | FromGitter | <mratsim> sorry :/ |
| 07:19:36 | FromGitter | <mratsim> I'm curious about that though " Fortran support in GCC has also been improved with now handling asynchronous I/O and other features. " |
| 07:20:27 | * | solitudesf quit (Ping timeout: 248 seconds) |
| 07:28:32 | * | dddddd quit (Ping timeout: 250 seconds) |
| 07:29:15 | * | dddddd joined #nim |
| 07:34:38 | FromGitter | <mratsim> I think an async await tutorial is needed: https://forum.nim-lang.org/t/4824 |
| 07:34:46 | FromGitter | <mratsim> and some recipes/cookbook |
| 07:36:18 | narimiran | yes it would be nice, but the last time i asked - nobody volunteered to write one ;) |
| 07:41:17 | PMunch | Ugh, HTML is so infuriating to work with.. |
| 07:42:46 | FromGitter | <jrfondren> I'll write that |
| 07:43:53 | FromGitter | <mratsim> @PMunch, last time Araq was infuriated at something, he wrote a PHP backend for Nim ;) |
| 07:44:51 | * | slugm joined #nim |
| 07:45:18 | Araq | no, I got paid for it |
| 07:45:30 | Araq | but I did write Karax to generate HTML ;-) |
| 07:46:16 | FromGitter | <mratsim> btw 0.20 or 0.19.6? |
| 07:48:26 | PMunch | Well the problem isn't to generate HTML, the problem is to figure out what HTML to generate |
| 07:48:29 | PMunch | https://play.nim-lang.org/index.html?tour=https%3A%2F%2Fplay.nim-lang.org%2Ftour.html |
| 07:48:59 | PMunch | ^ New tour feature |
| 07:49:09 | Araq | PMunch, ah but that's easy, a <div> nested in a <div> nested in a ... |
| 07:49:26 | PMunch | Haha, true, it's div's all the way down |
| 07:49:36 | Araq | modern HTML is divs all the way down until you get to the CSS |
| 07:49:48 | FromGitter | <jrfondren> set padding-top to zero |
| 07:50:13 | PMunch | jrfondren, on what? |
| 07:50:35 | FromGitter | <jrfondren> oh I just assumed your problem was the vertical space above the "Welcome" line |
| 07:50:51 | Araq | and the 'C' in CSS is a design mistake and so you gotta hire a "web designer" that takes months for a UI I used to click together in Delphi single-handed in an afternoon |
| 07:51:01 | PMunch | The issue I was having was that if the explanations section got too long, it would start scrolling, but the Next/Previous buttons would stay in the same spot |
| 07:51:20 | FromGitter | <jrfondren> oh yeah, that looks awful. |
| 07:53:51 | PMunch | jrfondren, yup. And the entire site completely falls apart on mobile :P |
| 07:54:40 | FromGitter | <jrfondren> probably easier just to put some clickable text in with the explanation. fixed positions are better if you want to repeatedly click them, but nobody should be doing that who's really taking the tour. |
| 07:55:20 | narimiran | @mratsim why not both? ;) |
| 07:56:26 | FromGitter | <mratsim> it was a question about the timeline as there was some talk about releasing last week |
| 07:56:57 | FromGitter | <mratsim> (not that I want to have a release right now) |
| 07:57:02 | narimiran | @mratsim 0.19.6 should come out this week. 0.20 will follow after that, hopefully when some more regressions are fixed |
| 07:57:51 | FromGitter | <mratsim> I really hope 0.20 would be a preview of 1.0, I'd really like to try custom allocators |
| 08:03:25 | PMunch | jrfonden, perhaps, but I wanted it to match the style of the editor on the right with buttons on the bottom |
| 08:05:21 | PMunch | Hmm, cloudflare seems to cache the stylesheet for quite a while |
| 08:05:24 | PMunch | That's annoying |
| 08:08:23 | FromGitter | <jrfondren> you should be able to put in a dev mode while you're working on it |
| 08:08:44 | FromGitter | <jrfondren> cloudflare has something like that, per site. |
| 08:12:22 | * | floppydh joined #nim |
| 08:12:53 | Zevv | Hey jrfondren: I still can't believe the implausible situation with the bluehost server; you weren't pulling my leg, were you? |
| 08:13:02 | FromGitter | <jrfondren> nope, totally true |
| 08:13:33 | Zevv | woha |
| 08:13:45 | FromGitter | <jrfondren> your last words were "solved, very well, good to see / good luck!" |
| 08:14:19 | Zevv | well, it does make for a nice story for beer with engineers |
| 08:16:43 | PMunch | jrfonden, well I only have access to the server behind cloudflare. So I'd need to ask dom96 to make that change. But it should be fine now I think |
| 08:16:51 | PMunch | Once the cache updates at least |
| 08:17:04 | PMunch | Still has the horrible floating buttons bar though |
| 08:20:16 | Zevv | jrfondren: anyway, I looked into the more efficient line reading into strings, but its not trivial. The string header and data are adjecent in memory, so you can't just poke the string pointer to point anywhere |
| 08:20:52 | FromGitter | <jrfondren> aye, that's what I was saying. it still might be reasonable to read directly into that buffer though. |
| 08:21:31 | Zevv | but then there's always the extra copy from the FILE * buffer into the string buffer |
| 08:22:18 | FromGitter | <jrfondren> if you getline() or something, but since the C interface sucks you could just use the syscalls or the thin wrappers like fread. |
| 08:24:19 | FromGitter | <jrfondren> with npeg you could have two buffers, read into them alternately, and then you get at least one buffer's size of string for 'backtracking' |
| 08:27:28 | * | xet7 quit (Quit: Leaving) |
| 08:28:44 | Zevv | which might still not be enough - no easiy solution there |
| 08:30:48 | FromGitter | <jrfondren> it's an additional failure condition but the user can be responsible for it, by specifying the buffer size and using this interface. don't want that, readFile and pass the entire file as a string instead. |
| 08:31:09 | FromGitter | <jrfondren> the benefit is no copies at all except for captures. |
| 08:34:06 | Zevv | true |
| 08:55:35 | Araq | why not use lexbase for it |
| 08:56:10 | Araq | line-based parsing is a stupid thing to do anyway, it's completely arbitrary and most languages have tokens that can span multiple lines |
| 09:27:03 | livcd | PMunch: i like the design! good job |
| 09:28:15 | Araq | https://medium.com/@mattklein123/crash-early-and-crash-often-for-more-reliable-software-597738dd21c5 |
| 09:29:55 | PMunch | livcd, thanks :) |
| 09:30:04 | PMunch | (Assuming you were talking about the playground) |
| 09:30:40 | * | abm joined #nim |
| 09:31:01 | livcd | PMunch: yes |
| 09:31:22 | PMunch | Did you try the tour feature? |
| 09:31:28 | PMunch | As in creating your own tour? |
| 09:31:50 | livcd | ahh |
| 09:31:53 | livcd | not that one |
| 09:41:26 | * | clyybber joined #nim |
| 09:48:00 | * | xet7 joined #nim |
| 09:53:44 | * | JappleAck quit (Quit: Closing object) |
| 09:58:23 | * | rnrwashere joined #nim |
| 10:01:10 | * | JappleAck joined #nim |
| 10:02:38 | * | rnrwashere quit (Ping timeout: 252 seconds) |
| 10:16:44 | * | lritter joined #nim |
| 10:31:37 | FromGitter | <alehander42> Araq, you can't just crash early in a lib |
| 10:33:31 | dom96 | PMunch, why the change away from Karax for the playground? |
| 10:34:05 | FromGitter | <alehander42> cy1: https://github.com/krux02/ast-pattern-matching |
| 10:34:16 | dom96 | for caching, just add ?time=123412412 into the CSS url |
| 10:34:21 | FromGitter | <alehander42> would be even better for macro usecase |
| 10:43:47 | FromGitter | <arnetheduck> Araq, lol, the mistake made at the beginning of all discussions about error handling is to call it error handling :) if you treat all errors as part of "normal" control flow (and don't consider them errors but just alternate equally important execution paths), you end up with what the article above is arguing for - no meaningless error handling and tight code that structurally enforces correctness |
| 10:45:06 | noonien | hello folks |
| 10:48:00 | noonien | i'm getting some really weird issues with imports, compiling fails depending on order of imports, some imports seem to work realy weirdly, but just sometimes. i'll try to make some test cases |
| 10:48:39 | noonien | i'm on the devel branch |
| 10:52:44 | PMunch | dom96, mostly just because I had toyed around with creating the tour of nim thing before I got involved with the playground |
| 10:53:01 | PMunch | So it was easier for me to just copy that and make some tiny changes than to get the old UI up and running again |
| 10:53:02 | dom96 | PMunch, it would be nice if you used Karax for that too ;) |
| 10:53:15 | PMunch | Well now they are merged |
| 10:53:46 | noonien | should a module export everything it uses from other modules? |
| 10:54:08 | PMunch | And I guess I should redo the thing in Karax, if for nothing else to show off it's powers, but I wanted to get things up and running fast |
| 10:54:43 | PMunch | noonien, depends. But mostly no |
| 10:56:15 | noonien | this is the first example that seems to fail: https://gist.github.com/noonien/5c37a8ca49f05e4568d1fc6c14cf75e5 |
| 10:58:54 | Araq | arnetheduck: putting '?' after function calls mindlessly is not "tight code" |
| 10:58:56 | FromGitter | <jrfondren> ok, that's just name resolution |
| 10:59:42 | dom96 | Should be a simple merge, anyone? https://github.com/nim-lang/Nim/pull/11181 |
| 10:59:57 | FromGitter | <jrfondren> it'd be better for Nim to complain about the ambiguity, I guess it can't do that over module boundaries |
| 11:00:24 | * | Vladar joined #nim |
| 11:00:33 | FromGitter | <alehander42> Araq, but how is `?` different than putting mindlessly stuff in `{.raises.}` annotations etc |
| 11:00:35 | noonien | that makes sense, but, why would it be ambigous? |
| 11:00:53 | FromGitter | <alehander42> `?` is not noise, it's very useful as it tells me exactly if a call can raise or not in a context |
| 11:01:15 | Araq | what if all calls can raise? that's the reality in my compiler... |
| 11:01:34 | Araq | how is it not noise then? |
| 11:01:38 | FromGitter | <alehander42> well it shouldn't be like this |
| 11:01:56 | FromGitter | <jrfondren> noonien: because Foo is a type constructor |
| 11:01:58 | FromGitter | <alehander42> i imagine a compiler should have a lot of "pure" functions which just process/transform stuff |
| 11:02:10 | FromGitter | <jrfondren> this works for example: `echo Foo([0.byte, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15])` |
| 11:02:27 | FromGitter | <alehander42> but yeah, i guess one can say that an error state is often the result |
| 11:02:33 | Araq | I can imagine a lot too. I don't use Haskell for a reason though. |
| 11:03:11 | dom96 | alehander42: the compiler can already tell you if a call raises or not |
| 11:03:15 | FromGitter | <jrfondren> you have two Foo()s and which wins is gettling settled by the order of your imports. |
| 11:03:16 | dom96 | That's why we have the effect system |
| 11:03:39 | noonien | jrfondren, indeed, however, i don't pass an array to it, but an int, i've not experienced nim having these types of ambiguities before, it seems to have dealt with simple resolution based on argument types just fine |
| 11:04:04 | FromGitter | <alehander42> @dom96 yes, but i currently need to see this in the function def, not on the callsite |
| 11:04:06 | FromGitter | <jrfondren> aye. clearly, it's doing that well over module boundaries. |
| 11:04:21 | FromGitter | <alehander42> it doen't matter so much for me, was just saying that `?` in an alt error system also seemed ok to me |
| 11:04:24 | dom96 | alehander42: You can see that too, in the doc gen for example |
| 11:04:39 | FromGitter | <alehander42> i am talking about callsite vs definitionsite |
| 11:04:56 | FromGitter | <alehander42> but yeah, one can also argue that good ide plugin should show this immediately inline |
| 11:04:57 | FromGitter | <jrfondren> maybe there's some specially troublesome about type constructors. After all there are tons of identically-named operators from different modules. |
| 11:05:14 | dom96 | The way the effect system works is wonderful IMO |
| 11:05:50 | dom96 | It's the best of both worlds. Want to write code quickly without caring about exceptions? Great, just don't use the raises pragma. Have some code which is critical and needs to not crash? Use the raises pragma |
| 11:06:55 | FromGitter | <jrfondren> yeah your exact same code with two procs (and one returning int vs. float, since Foo can't be returned) works fine. |
| 11:07:07 | * | xet7 quit (Ping timeout: 248 seconds) |
| 11:07:25 | FromGitter | <jrfondren> so: Nim is confused by type constructor/proc ambiguities over module boundaries. |
| 11:07:34 | FromGitter | <alehander42> btw @dom96 i wanted to ask you if you think async/await can simulate something like a nonblocking goroutine system: what i imagined was that if one has "nonblocking" effects and a pragma that lets you rewrite a function in a way that it does its io stuff in a new (light?) thread so it's not blocking as well, one can easily put that in the async event loop and use it in a similar way |
| 11:07:54 | Araq | you are exception deniers. You don't put ? after every call in Rust that can die with OOM or with an overflow error. |
| 11:08:01 | * | Snircle joined #nim |
| 11:08:06 | FromGitter | <alehander42> the problem i see is that async/await didn't really work well with flowvars iirc |
| 11:08:30 | FromGitter | <alehander42> Araq, you can't just use overflow errors as an example against every possible error handling strategy :D |
| 11:08:51 | FromGitter | <alehander42> i can say "system A deals well with 95% of the classes of errors i care for" and still like it |
| 11:09:07 | dom96 | alehander42: not sure exactly what you have in mind. If you want goroutines then you need to make sure that all blocking IO operations yield implicitly |
| 11:09:14 | dom96 | With async await it's explicit |
| 11:09:38 | dom96 | As far as FlowVars are concerned, we just need to spend some time integrating them with async |
| 11:09:44 | FromGitter | <arnetheduck> the fact that you're explicit helps you reason about the code such that there's less silly error handling and more useful error handling, on average.. you're encouraged to structure your code in such a way that there are fewer `?` overall.. then the compiler and language can help you reason about which situations can and cannot happen - the code is tight because by thinking about it you make explicit choices to add |
| 11:09:44 | FromGitter | ... or remove the error handling and encode those choices (through type) so the compiler can be useful and help you maintain what you wrote in the face of change |
| 11:10:11 | FromGitter | <jrfondren> sounds like very questionable code tbh |
| 11:10:43 | FromGitter | <alehander42> @dom96 yes, but what i imagined was that `myasync` functions will rewrite IO calls to explicit awaitable alternatives which happen in another (light)thread, at least the last part is what i think go is doing(running them in diff threads) |
| 11:11:35 | dom96 | alehander42: The Go light thread is pretty much an async proc |
| 11:11:38 | * | sz0 joined #nim |
| 11:12:25 | dom96 | Chapter 6 of my book has a pretty good explanation IIRC |
| 11:13:02 | Araq | alehander42: The overflow error is an example for what happens when the errors a system can face are prevalent |
| 11:13:45 | FromGitter | <alehander42> @dom96 well afaik when go routines block, the go scheduler runs other goroutines in different threads from its pool |
| 11:14:17 | FromGitter | <alehander42> but there was another case, but i am not sure how it worked indeed, have to read more about it |
| 11:14:42 | dom96 | yes, that's the additional bit that Go does automatically |
| 11:15:02 | FromGitter | <jrfondren> so, like Erlang, it's a model that requires elaborate runtime support. |
| 11:16:03 | FromGitter | <alehander42> so i imagined that i can do this as well: i can have wrappers around syscalls that invoke them in free threads and then yield immediately to the event loop and later finish the future after the thread |
| 11:16:31 | FromGitter | <alehander42> around io-annotated calls: see, i can use effects even here :P |
| 11:16:53 | FromGitter | <alehander42> io-/syscall annotated primitives? anyway |
| 11:17:16 | FromGitter | <jrfondren> I bet that Ada's model would be more suitable for Nim. I just don't know enough about it to support that :/ |
| 11:18:21 | FromGitter | <arnetheduck> effects are completely useless for this btw as long as there are no boundaries enforcing limits on them. the high incidence of memory and resource leaks in the Nim std lib are a symptom and a direct outcome of the language allowing people to write code like that and not helping them discover where issues might arise |
| 11:19:53 | FromGitter | <alehander42> yeah i agree that this is also relevant: if one can freely decide to not use the effect system in the stdlib, effects become less useful to all Nim code that depends on it |
| 11:20:42 | FromGitter | <alehander42> @jrfondren yeah i am just playing with the idea: i am more interested in actor model, but even less sure how would it work effectively in Nim :P |
| 11:21:18 | FromGitter | <jrfondren> https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency , ctrl-f rendezvouz. Whatever that word means is the key. |
| 11:21:50 | * | xet7 joined #nim |
| 11:21:57 | Araq | arnetheduck: there is no evidence for that. Likewise you could argue that 'discard f()' encourages to ignore errors since it's so easy to write and so we should write it as 'discard(([[f()]]))' |
| 11:22:17 | dom96 | resource leaks are a symptom of not having stable destructors |
| 11:22:20 | FromGitter | <arnetheduck> like.. consider what the pain points of nim development are, over time - maintenance is high on the list, fixing and refixing and refixing stuff (lots of "make test suite green again" commits, many resource leaks etc).. |
| 11:22:21 | FromGitter | <alehander42> i wanted to ensure that a web framework can ease having low latency for its app: so i figured having each request in its own routine/actor should be easier as then their loop isn't filled with all the other async calls, but maybe i am completely wrong |
| 11:22:32 | dom96 | (and not having a culture like Python where we write `with f as File...`) |
| 11:23:25 | FromGitter | <arnetheduck> no, discard f is excellent - it spells out that you've made an explicit choice to not consider the return value of a function and call it only for its side effects - that's all that's needed |
| 11:23:30 | dom96 | arnetheduck: Also, I'm curious which memory leaks you are referring to |
| 11:23:42 | Araq | "make tests green" has nothing to do with resource leaks |
| 11:24:15 | FromGitter | <arnetheduck> dome96, grep for `close` in std lib and you'll find 10 file handle leaks, just like that, on silly stuff like parse error |
| 11:24:43 | Araq | the leaks are bad and they are caused by 'do; undo'-like logic. Which is wrong in Go and Rust too with their abilities to 'panic' |
| 11:25:18 | Araq | it must be written like 'do; defer: undo' in every mainstream language out there. |
| 11:25:42 | Araq | you can hide the 'defer' in a destructor of course, or you can write it as a 'finally' |
| 11:25:49 | Araq | or maybe as an 'atexit' |
| 11:26:33 | dom96 | arnetheduck: I'm not asking about file handle leaks, I'm asking about memory leaks |
| 11:26:54 | noonien | what would be a solution to the import order problem? |
| 11:27:03 | dom96 | I am aware that file handle leaks are very prominent, I've caused probably the majority of them :P |
| 11:27:14 | FromGitter | <jrfondren> noonien: don't overload type constructors with procs |
| 11:27:15 | dom96 | noonien, what's the code? |
| 11:27:15 | Araq | you cannot blame exceptions when 'do; undo' is also wrong code in the languages that "lack exceptions" |
| 11:27:18 | FromGitter | <arnetheduck> well, they *are there* and there's no language tool (for now) to help you find them or even know that they happen when you're writing the code. computed effects are way too far away when writing code for them to be useful, you don't *see* them. |
| 11:27:41 | dom96 | arntheduck: so what do you suggest to fix them? |
| 11:28:15 | noonien | dom96: https://gist.github.com/noonien/5c37a8ca49f05e4568d1fc6c14cf75e5 |
| 11:28:32 | Araq | the problem is real but the analysis for their cause is simply *wrong*. |
| 11:29:07 | FromGitter | <jrfondren> noonien: for example, your exact code with the proc lower-cased works as expected |
| 11:29:49 | noonien | i understand, but i'm trying to understand if this is a bug, or expected behavior |
| 11:29:52 | FromGitter | <arnetheduck> well, when you know that parsing can fail by having the "error" - or really more accurately, the alternate control flow - explicit, you will also see that you need to do something about it. if the starting point of the code is "incorrect but convenient" and then you try to plug the leaks, it's fairly obvious what the outcome will be |
| 11:29:56 | FromGitter | <jrfondren> oh I think it's clearly a bug |
| 11:30:22 | dom96 | noonien, yeah, what jrfondren said. What error do you get? |
| 11:30:31 | dom96 | It's not clearly a bug |
| 11:30:37 | dom96 | Depends what error message you get :) |
| 11:31:01 | Araq | on other words, the following mechanisms need to be banned aside from 'raise': 'die', 'quit', 'exit', 'panic', 'terminate' including using these mechanism for Out-of-memory and integer overflows |
| 11:31:13 | noonien | `a.nim(5, 9) Error: type mismatch: got <int literal(3)> but expected 'Foo = array[0..15, byte]'` |
| 11:31:44 | noonien | it's trying to convert, instead of calling the proc, depending on which order the modules are imported |
| 11:31:53 | FromGitter | <jrfondren> no, it's trying to call the type constructor instead of the proc |
| 11:32:01 | FromGitter | <arnetheduck> you can argue that writing incorrect and convenient code is a good tradeoff for many problems though - if you're writing a script, you don't need atexit or anything, just let the OS clean up after you.. that code however will never be useful in a larger context - it's a great tradeoff for scripts and similar situations |
| 11:32:05 | noonien | the same identifier is both a type and a proc |
| 11:32:10 | Araq | there is not a single system out that does that, so 'defer undo()' remains to be required and your analysis is at best woefully incomplete |
| 11:32:16 | FromGitter | <jrfondren> `echo Foo([0.byte, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15])` is an example successful call with that code |
| 11:32:39 | dom96 | noonien, the error message could be improved, but it's not that bad. |
| 11:32:44 | noonien | depending on what order the modules are imported, the compiler decides that a call to that identifier is a type conversion of a proc call |
| 11:32:59 | noonien | jrfondren: i understand what the problem is, no need to repeat |
| 11:33:00 | dom96 | oh, but if you change the order then it works |
| 11:33:07 | FromGitter | <jrfondren> the error message could be improved, but also this exact kind of type resolution works just fine when it's two procs instead of a proc and a type constructor |
| 11:33:11 | dom96 | yeah, I'd say that's a bug |
| 11:33:34 | noonien | as i said, i'm trying to figure what the actual nim bug is, not the bug in my code |
| 11:33:44 | FromGitter | <arnetheduck> Araq, so what's better? we've already agreed that panic is likely not too bad as part of the mix :) that leaves the gray zone in between to deal with - that stuff that is not a big deal right now, but will in a month once you realize you've actually made something useful |
| 11:34:02 | noonien | one would think it's safe to assume that order of imports did not matter |
| 11:34:23 | dom96 | noonien, indeed. That's a bug. Report it |
| 11:34:50 | * | abm quit (Quit: Leaving) |
| 11:34:57 | noonien | and since nim doesn't really have namespaces, this case should not error imho |
| 11:35:08 | noonien | dom96: will do |
| 11:35:58 | dom96 | noonien, it should error, unless you disambiguate it |
| 11:36:09 | dom96 | i.e. c.Foo vs. b.Foo |
| 11:36:19 | noonien | true, but the error i gave should not be ambigous IMHO |
| 11:36:26 | noonien | the code* |
| 11:36:39 | FromGitter | <jrfondren> in this exact case I'd still not expect an error since there's no error with two procs with these signatures. |
| 11:36:53 | noonien | exactly |
| 11:38:28 | Araq | > that code however will never be useful in a larger context |
| 11:38:50 | Araq | you'd be surprised how many systems are little more than Bash scripts that are piped together |
| 11:39:17 | FromGitter | <alehander42> but why would you optimize your language for such kind of system |
| 11:39:22 | Araq | and in some way that's a poor man's Erlang with "fail early" |
| 11:40:11 | FromGitter | <alehander42> but the entire point of erlang's fail early is that it works because it happens in a runtime that autorestarts subsystems |
| 11:40:19 | FromGitter | <alehander42> it has nothing to do with a "global" fail early |
| 11:40:39 | dom96 | noonien, jrfondren: Foo(3) is ambiguous. It's either a type conversion or a call to the `Foo` proc. |
| 11:40:40 | FromGitter | <alehander42> which was one of the good comments i read to that article imho |
| 11:41:00 | FromGitter | <arnetheduck> the academic field here is behavioral economics - creating nudges that cause (globally) desirable outcomes without being indivudally constraining |
| 11:42:14 | noonien | dom96: I agree, this can be solved by either resolving the type conversion as any other proc, or provide an error that doesn't depend on order of imports |
| 11:42:31 | FromGitter | <jrfondren> dom96, you have two interpretations and one of them would error out at compile-time with a type error, and the other's OK. When it's 13 different procs, like `contains` or `$` or `add`, Nim has no trouble picking the non-error case. When one of the options is a type constructor, you get this failure. Maybe it also matters that there are module boundaries. |
| 11:42:34 | dom96 | noonien, yes, IMO it should be an error for both order of imports. |
| 11:42:59 | FromGitter | <alehander42> but i agree that in a language like nim, functions usually seem like a subsystem unit, so `raise`/`early error return` seems both like the analyzable fail-early equivalent: as they still let a function up the stack to decide what to do: run again, run something different etc |
| 11:43:31 | dom96 | jrfondren: Yes, but the fact is that this goes against convention. Making it work could end up being more confusing. It's better to give an error and make it clear that there is a conflict, and hopefully encourage the person to not name their procedures with a capital first letter |
| 11:43:41 | FromGitter | <arnetheduck> while I'm focusing on solving the logic of my problem, I want the language to safely guide me and make good choices for me so that the code doesn't end up a leaking barrel and maintenance nightmare.. later, when I'm revisiting, I want the creative freedom to break with those safe and default choices when the situation demands it.. is that too much to ask? :) |
| 11:43:54 | Araq | you cannot "nudge" me into handling the error "when it happens" simply because there is nothing to do but to propagate it upwards |
| 11:44:03 | FromGitter | <jrfondren> the convention's why the error's gone unnoticed :) |
| 11:44:45 | dom96 | jrfondren: Yes. A lot of errors go unnoticed because people write code in very similar ways. That's just how things are. |
| 11:44:47 | FromGitter | <jrfondren> well, I can't argue either way on making it a deliberate error. In that case it's just an error message problem. |
| 11:45:13 | FromGitter | <arnetheduck> of course you can - you can turn your `string` into a `Regex`, and then from that point onwards parse errors are *guaranteed* not to happen |
| 11:45:18 | dom96 | Which why new perspectives are so important for Nim, and also why newbies usually find bugs quickly :) |
| 11:45:50 | dom96 | arnetheduck: Don't we do that already? |
| 11:46:20 | noonien | i've submitted an issue: https://github.com/nim-lang/Nim/issues/11187 |
| 11:46:29 | dom96 | By the way guys, if you are seeing memory leaks in your async/await programs, you may find this useful: https://github.com/nim-lang/Nim/pull/11181 |
| 11:47:14 | FromGitter | <arnetheduck> dom96, well yes, except that you skip handling the parse error in between in the std lib, because while the "effect" system detects it, it doesn't let you, the programmer, know about it explicitly, and thus the trivial file handle leak happens |
| 11:47:23 | dom96 | I've recently been bitten by async procs being stuck waiting forever, which led to them not being garbage collected. Seeing which futures are pending is a good way to find this. |
| 11:48:43 | FromGitter | <arnetheduck> the default in the language is to let you ignore this possibility, and lo and behold, in the real world you.. surprise surprise, ignore the possibility and leak. |
| 11:48:47 | dom96 | arnetheduck: Oh, I think I agree with what Araq said here. You're getting the cause wrong. It's not the exception systems fault. It's that we don't have a clear and reliable way to state that a file handle should be closed. |
| 11:49:06 | dom96 | I don't use `defer` because it is (was?) buggy in async procs |
| 11:49:27 | dom96 | and because destructors are on the horizon. We just need to choose a convention and stick to it |
| 11:49:53 | FromGitter | <arnetheduck> defer would not help here - you would not remember to put defer there, because it's *easier* not to put it there |
| 11:50:02 | * | xet7 quit (Ping timeout: 245 seconds) |
| 11:50:31 | FromGitter | <arnetheduck> you can search for all the places in the std lib where defer is missing, for example, to patch the leaks |
| 11:51:01 | clyybber | arnetheduck: Then destructors are the solution, right? |
| 11:51:48 | Araq | arnetheduck: I don't like exceptions but if one is serious about gracefully handling e.g. out-of-memory than C++'s solution is unmatched so far by a wide margin. Yes, you need to write "exception safe" code. Yes, nobody can do it. But you know what? nobody gets 'if outOfMem: goto errorHandler' right either and at least with exceptions I don't bloat my logic by a factor of 2 |
| 11:51:49 | FromGitter | <arnetheduck> destructors help deal with some of it, yes. but they're incompatible with GC's, effectively.. |
| 11:52:13 | * | Vladar quit (Remote host closed the connection) |
| 11:52:17 | dom96 | destructors are incompatible with GCs? How so? |
| 11:52:42 | * | Vladar joined #nim |
| 11:52:58 | clyybber | they arent, but they are not deterministic, as such reliable, is what arnetheduck is probably trying to say |
| 11:52:59 | FromGitter | <arnetheduck> so when destructors come around, the std lib will either need to be retrofitted (a huge effort) or it will remain like uint support - out of tune with the language |
| 11:54:00 | FromGitter | <arnetheduck> well, destructors are about eager and deterministic resource management, while gc is about lazy and optimistic resource management.. can't have both at the same time. |
| 11:54:06 | * | vlad1777d_ joined #nim |
| 11:54:31 | FromGitter | <jrfondren> is there a way for an iterator to have some finalization code happen if the body of the iterator is left by exception? |
| 11:54:58 | clyybber | put everything in a try except? |
| 11:55:13 | FromGitter | <jrfondren> without the user having to do that |
| 11:55:18 | dom96 | jrfondren: defer |
| 11:55:24 | noonien | arnetheduck: i diasagree, that's what arena allocators are for |
| 11:55:27 | dom96 | (if it now works, which I'm unsure about) |
| 11:55:39 | clyybber | arnetheduck: It may be a huge effort, but if it fixes that problem, its what we gotta do |
| 11:56:09 | dom96 | lazy and optimistic resource management is good enough (TM) |
| 11:56:36 | dom96 | Maybe Araq's plan is to not enable destructors for GC'd objects, if so that would make me really disappointed |
| 11:56:37 | noonien | it's not exactly the same thing, obviously, but you can emulate almost any GC behavior with destructors imho |
| 11:57:24 | FromGitter | <jrfondren> ok yeah a defer in the iterator does it. interesting. |
| 11:57:47 | dom96 | but yeah, GC allocs actually have a finalizer proc that you can set |
| 11:58:11 | dom96 | And yeah, I understand, you may end up with a situation where things never get deallocated and thus the file handles don't get freed |
| 11:58:36 | FromGitter | <jrfondren> https://gist.github.com/jrfondren/aa3163e33ebe8a3d3fc4be01b8adcaf8 |
| 11:58:49 | clyybber | dom96 You could argue thats the nature of GC's lazy behaviour, and thus expected. |
| 11:59:06 | dom96 | Perhaps there is a pretty concrete example of this that's a huge showstopper. I do recall talk about abusing GC's finalizers for file handle closures, but that this was the problem. |
| 11:59:53 | dom96 | jrfondren: huh, that's interesting that it catches it when it's inside the for loop |
| 12:01:41 | noonien | for what it's worth, i like go's approach, not of panic handling, but not treating everything as an exception |
| 12:01:59 | * | xet7 joined #nim |
| 12:02:43 | FromGitter | <arnetheduck> clyybber well, the thing with a large std lib is that you need a large maintenance effort to deal with changes so that it remains relevant and up-to-date with the language.. let's see how long it takes before the `FTP` (!) client in there is updated to be destructor-friendly :) |
| 12:06:02 | FromGitter | <arnetheduck> @nooien arena allocators let you deal with memory in bulk - that seems orthogonal to eager vs lazy resource management..? |
| 12:06:24 | clyybber | arnetheduck: theres an ftp client in the stdlib? |
| 12:06:38 | * | deech joined #nim |
| 12:06:44 | FromGitter | <jrfondren> https://nim-lang.github.io/Nim/asyncftpclient.html |
| 12:06:48 | clyybber | arnetheduck: I might have underestimated the scope a bit, but it still has to be done I guess |
| 12:07:22 | FromGitter | <jrfondren> never trust a stdlib without an FTP client. |
| 12:07:55 | * | xet7 quit (Quit: Leaving) |
| 12:10:08 | FromGitter | <alehander42> now imagine 3rd party libs :D |
| 12:10:39 | FromGitter | <arnetheduck> clyybber, well, it has improved a lot :) there used to be two web servers in there, there's only one now :) |
| 12:10:50 | noonien | the nim stdlib doesn't have proper uint support, but it does have FTP support? |
| 12:12:25 | FromGitter | <arnetheduck> gotta keep your priorities straight :) arguably, uint - not so useful on their own, whereas FTP! |
| 12:12:43 | dom96 | What's not proper about Nim's uint support? |
| 12:13:09 | FromGitter | <alehander42> @arnetheduck i don't wanna burst the small-stdlib party on, but go also has http in stdlib and people love that |
| 12:13:28 | FromGitter | <alehander42> it's a complicated tradeoff |
| 12:13:29 | noonien | hehe, sorry, i was just joking, i'm pretty new to nim to comment on its stdlib |
| 12:14:19 | FromGitter | <jrfondren> I imagine what's meant here is that there're a lot more functions that work on int than that work on uint -- or int64, for example. So the solution is just writing uint versions of those procs and putting it in a module, similar to lenientops |
| 12:14:43 | dom96 | indeed |
| 12:14:44 | FromGitter | <arnetheduck> @alehander42 3rd party libs have a much more natural maintenance cycle - the stuff that's still relevant gets updated, the rest remains available as published for legacy |
| 12:15:10 | dom96 | FWIW a lot of the stuff in the stdlib is in there because Nimble become usable relatively late |
| 12:15:29 | dom96 | If I did it again I wouldn't have put async in the stdlib |
| 12:15:39 | FromGitter | <arnetheduck> go also has google and its army of engineers maintaining it - of course it makes sense for them |
| 12:15:49 | noonien | dom96: why not? |
| 12:16:06 | dom96 | Because it would be easier to evolve it outside the stdlib |
| 12:16:10 | FromGitter | <alehander42> @arnetheduck but that's the point: it's not a fundamental property of lang design, it depends on circumstances |
| 12:16:19 | dom96 | and would allow others to write their own (possibly better) implementations |
| 12:16:38 | noonien | async is a prettyimportant part of the language, i find it a horrific mistake that rust declares itself to be "fearlessly concurrent" while it doesn't provide anything in the stdlib to have actual concurrency, or hadn't for a long time |
| 12:16:40 | FromGitter | <alehander42> @dom96 on the other hand having multiple async/await with differennt quirks would suck more imo |
| 12:16:45 | dom96 | On the other hand, it's bad to --- ^ |
| 12:16:49 | livcd | hmm I am not getting code competion in Emacs |
| 12:17:09 | dom96 | what alehander42 said :) |
| 12:17:24 | dom96 | noonien, that's a good point |
| 12:17:26 | FromGitter | <alehander42> something like an " interface" which would force different impl-s to conform to the most important bits would be best |
| 12:17:40 | dom96 | Sadly Nim is also very `interface`-averse :) |
| 12:17:56 | FromGitter | <arnetheduck> @alehander42 sure - though where possible, I prefer to stimulate an environment that does not rely on a central authority to maintain its viability |
| 12:18:19 | FromGitter | <alehander42> well i hope so .. i'd expect ethereum to be central-authority-free :P |
| 12:19:36 | noonien | considering mostly everyone wants to write code that can be easily made concurrent, the language not providing concurrency on its own ends up in N concurrrency libraries, each with its own tradeoffs, leaving the user with a choice of basically what libraries can be used depending on what they depend on |
| 12:20:02 | noonien | however, having red/blue functions is also bad imho |
| 12:20:05 | FromGitter | <alehander42> on the other hand, it's a little bit of both: if you don't have many users, the ecosystem would probably not be good enough to make up for a stdlib ⏎ but if you have such a big community, naturally you'd have one or several "hubs" which will be able to maintain some central things and in this case having unified management/api design/etc for a bigger stdlib might not be too bad |
| 12:20:53 | dom96 | noonien, yeah, both have their advantages and disadvantages. Of course Status has diverged with their own async implementation which worries me :/ |
| 12:21:12 | FromGitter | <alehander42> about async: i think it's ok to have it inside, one can still write e.g. routine/actor/whatever dsl-s as 3rd party libs |
| 12:21:25 | noonien | an interesting read regarding the issue: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ |
| 12:21:35 | dom96 | yeah, that's a classic article :) |
| 12:21:44 | * | seni joined #nim |
| 12:21:55 | FromGitter | <arnetheduck> the nim language can still "recommend" a particular approach or library so as to prevent needless fragmentation - it's a matter of what your first principle is.. you can start with a distributed solution and add helpers or start with a centralized solution and try to spread it.. the latter is arguably less resilient |
| 12:22:16 | noonien | what's the difference in a recommendation and including it in the stdlib?? |
| 12:22:22 | noonien | between* |
| 12:22:40 | noonien | sorry about the double '?', keyboard acting out |
| 12:23:10 | FromGitter | <alehander42> btw dom96: can one tweak the event loop, e.g. have hooks tweaking registering futures/the order of invoking stuff etc |
| 12:23:27 | FromGitter | <alehander42> or there is not an api for that (probably doesn't make sense for most cases) |
| 12:23:35 | FromGitter | <alehander42> async event loop* |
| 12:23:43 | dom96 | alehander42: you can register callbacks on the event loop |
| 12:23:50 | dom96 | There is different layers |
| 12:24:07 | dom96 | You've got the selectors module which is used for Linux/BSD |
| 12:24:22 | dom96 | You can use that manually (I use it in httpbeast) |
| 12:24:36 | dom96 | and you can integrate it with asyncdispatch which i've done for httpbeast too :) |
| 12:24:46 | FromGitter | <arnetheduck> noonien - maintenance burden and gate keepers to start with. there's an expectation that the std lib will.. you know.. work.. and stay stable. as it grows, that becomes harder and harder to pull off, also because you expect that all moving parts are updated together.. ie implementing destructors in the language and having a std lib that doesn't use them plays poorly with expectations.. but when do you cut the |
| 12:24:46 | FromGitter | ... release? |
| 12:25:05 | dom96 | and then asyncdispatch is built on top of selectors, with IOCP in there as well for Windows support |
| 12:25:14 | * | traviss quit (Quit: Leaving) |
| 12:25:19 | dom96 | Not much there to really hook into |
| 12:25:23 | dom96 | It's just functions that return futures |
| 12:25:35 | dom96 | and a poll function that either calls selectors' poll or IOCP's |
| 12:26:06 | clyybber | |
| 12:26:33 | noonien | arnetheduck: if the language authors recommend a library, and then change their recommendetion, how is that not the same thing as changing something in the stdlib? in both cases the library becomes "the official library to use", and everyone uses it. both cases end up in severe fragmentation |
| 12:27:13 | clyybber | dom96: Did you implement asyncIO ? |
| 12:27:27 | * | traviss joined #nim |
| 12:28:38 | dom96 | clyybber, yep |
| 12:29:20 | FromGitter | <arnetheduck> noonien you can manage, release and upgrade libraries independently of the language, allowing them to keep a pace appropriate to their development phase. the recommendation is there as a curation mechanism, but it doesn't come with the same set of constraints on other aspects (distribution, gate keepers, releases etc) |
| 12:29:41 | clyybber | cool, I'm thinking about adding support for the new io_uring api in linux 5.1 |
| 12:29:58 | dom96 | clyybber, oooh, first time I'm hearing of this |
| 12:30:39 | Araq | in the end Python with batteries included is a better Python and so is Nim. It helps when the batteries don't explode though. |
| 12:30:55 | dom96 | clyybber, would be awesome if you could implement that |
| 12:31:12 | * | xet7 joined #nim |
| 12:31:16 | clyybber | dom96: I'd be glad to :) |
| 12:31:24 | FromGitter | <arnetheduck> dom96, you can't have it both ways - we can't not fork async in std lib *and* develop it at a different pace than nim.. it's not practical for us to keep up with devel but it's also not practical to have to wait 1-2 years for a bugfix to be released. |
| 12:31:27 | dom96 | We've still got a lot of things to do for async |
| 12:31:59 | dom96 | arnetheduck: why can't you keep up with devel? |
| 12:32:37 | dom96 | and in fact, it's not about that |
| 12:32:50 | dom96 | You need to contribute your changes upstream |
| 12:32:55 | dom96 | the longer you wait the more difficult it'll get |
| 12:33:19 | FromGitter | <arnetheduck> because it's too buggy most of the time, and waiting for nim developers / you to approve every patch creates an inefficient development cycle for both of us - your time and our time is wasted waiting for each other |
| 12:33:19 | clyybber | yeah I agree |
| 12:33:52 | * | traviss quit (Quit: Leaving) |
| 12:33:57 | dom96 | okay, that's fair. If you're still developing it, and making sure it's stable then I can understand you not wanting to make a PR for each little thing |
| 12:34:00 | FromGitter | <arnetheduck> we don't *need* to contribute anything - the changes are there for you to pull into the std lib at any time you like - we've had this conversation already |
| 12:35:07 | * | traviss joined #nim |
| 12:36:58 | dom96 | Of course you don't. In the end you're hurting the community by never contributing though |
| 12:37:09 | FromGitter | <alehander42> @dom96 i'll read more about it: i wanted to create a web framework based on e.g. actor model as it sounded as a fun side project to do, but i am trying to see if it makes sense |
| 12:37:11 | FromGitter | <kaushalmodi> Hello all, I am attempting to convert some toy code dealing with pointers in C to Nim, but I am getting it wrong. Can someone review this: http://ix.io/1Idm |
| 12:37:20 | * | traviss quit (Client Quit) |
| 12:37:32 | dom96 | alehander42: go for it. More web frameworks never hurt :D |
| 12:37:57 | dom96 | sounds like you want to make an http server rather than a web framework though :) |
| 12:38:00 | FromGitter | <kaushalmodi> that code compiles, but I am getting something wrong, so I get SIGUSR with running the compiled .so of that with the host application |
| 12:38:04 | FromGitter | <alehander42> @arnetheduck but do you think it's possible to make chronos / stdlib async compatible one day, so people can just choose which impl to use or the difference is bigger |
| 12:38:38 | FromGitter | <alehander42> @dom96 i wanted to focus on the framework part, but i am also interested in learning more about concurrency models |
| 12:39:33 | * | traviss joined #nim |
| 12:39:36 | dom96 | Oh nice, I didn't notice the rebrand to chronos. |
| 12:39:47 | FromGitter | <alehander42> initially i also thought that it might be easy to just reuse a c/rust server for benchmarks(as i specifically didn't want to write my own httpbeast :P) but now it's all up in the air still |
| 12:39:58 | dom96 | Just use httpbeast :D |
| 12:40:42 | dom96 | based on my cursory look chronos doesn't actually seem to be /that/ different from asyncdispatch, mainly just some bug fixes + API changes (the latter sucks IMO and isn't necessary but I didn't look closely) |
| 12:41:04 | * | traviss quit (Client Quit) |
| 12:41:45 | FromGitter | <alehander42> well i obviously like having an alternative for everything :P but if i decide to go with custom actor model impl indeed, this might also make reusing httpbeast harder |
| 12:42:06 | Araq | dom96, destructors would work with a GC, somewhat, but I am opposed to GCs nowadays and #nim would complain anyway, making my job easier |
| 12:42:46 | livcd | kaushalmodi: what can I do to make code completion work in emacs for nim ? |
| 12:42:46 | dom96 | Araq, what would #nim complain about? |
| 12:43:20 | clyybber | dom96: Are you gonna try to merge those fixes into the stdlib? |
| 12:43:45 | dom96 | clyybber, I don't think I'll have time to do that |
| 12:43:47 | Araq | the usual things, it's not perfect, the GC might call the finalizer/destructor "too late" and think about the children |
| 12:44:44 | dom96 | Araq, so you won't allow destructors for GCd objects? |
| 12:45:36 | Araq | they are mapped to a finalizer |
| 12:45:42 | FromGitter | <kaushalmodi> livcd: I use just hippie-expand |
| 12:46:07 | dom96 | Araq, sounds good |
| 12:46:08 | dom96 | bbl |
| 12:46:08 | livcd | kaushalmodi: oh ok |
| 12:47:31 | clyybber | Araq: Nice, thats exactly what I hoped you'd do |
| 12:50:09 | * | solitudesf joined #nim |
| 12:51:11 | FromGitter | <arnetheduck> @dom96 I don't get what you're trying to say - you're claiming that async should not have gone into the std lib and that it would be more efficient to maintain it outside. we're maintaining a version of async outside, giving it a lot more love and attention than it has received in the past, and going through great pains to ensure that it's still available to the community, by licensing it freely and ensuring it |
| 12:51:11 | FromGitter | ... works as well as it possibly can with nimble (though that's hard to pull off given the state of nimble).. what more would you like, exactly, that doesn't contract what you said you would have done yourself? |
| 12:53:43 | * | NimBot joined #nim |
| 12:55:22 | FromGitter | <arnetheduck> @alehander42 well, we renamed it so that we would have creative freedom in developing it without constraints.. std lib async will need to be maintained by std lib maintainers, because the conditions for us to upstream it are not there (too inefficient, different goals) |
| 12:56:14 | clyybber | zacharycarter: Hey, long time no irc |
| 12:57:48 | FromGitter | <zacharycarter> Hi clyybber :) Yeah! I had a lot going on, but I'm finally in Finland and at my new job now |
| 12:58:13 | * | hoijui joined #nim |
| 12:58:32 | FromGitter | <zacharycarter> how are you? |
| 13:00:43 | PMunch | I might've asked this before, but where in Finland are you? |
| 13:01:25 | FromGitter | <arnetheduck> @alehander42 I think the win-win situation here is that async is removed from the std lib and put in a nimble library instead - then people can choose to use that or `chronos` as they like (knowing that we're actively maintaining chronos for the next x years), allowing `nim` itself to maintain a higher quality of the batteries that remain in the std lib because there's now less to maintain |
| 13:01:31 | clyybber | zacharycarter: I'm great, how bout you? Have you been to finlands beautiful national parks yet? |
| 13:01:52 | clyybber | PMunch: Helsinki |
| 13:01:58 | clyybber | not me but zach |
| 13:03:00 | PMunch | Ah, of course |
| 13:03:04 | FromGitter | <jrfondren> there's a Helsinki-mobilization project but it's not scheduled to start until after the war. |
| 13:03:05 | FromGitter | <arnetheduck> when you look at societies building roads, you can clearly tell which ones forgot to include a maintenance budget - a programming language community is the same |
| 13:03:48 | FromGitter | <zacharycarter> I'm currently in Lauttasaari - which is part of Helsinki, but it's an island just off to the west of the main part of the city |
| 13:04:15 | FromGitter | <zacharycarter> clyybber: good to hear :) I've been to one right near my apartment. I'm hoping to have more time this weekend to explore |
| 13:05:15 | Araq | arnetheduck: it doesn't happen often I guess, but I completely agree |
| 13:06:16 | FromGitter | <arnetheduck> lol, it happens more than you think, I think.. we just don't bitch about it them :) |
| 13:06:43 | Araq | I don't understand the hate for FTP though, I use FTP to upload the Nim website, for example |
| 13:07:02 | Araq | am I old fashioned? did some other protocol take over and I didn't notice? |
| 13:07:02 | FromGitter | <jrfondren> rsync is way better |
| 13:07:40 | FromGitter | <jrfondren> and rsync over ssh is also not in the clear |
| 13:09:06 | FromGitter | <jrfondren> people still use it, but they mostly don't have to. there's just a lot of guides that tell people how to use FileZilla |
| 13:12:33 | FromGitter | <arnetheduck> yeah you're old fashioned. you're supposed to kubernetes with 30 dockers and travis and web services in the cloud nowadays |
| 13:14:46 | * | seni quit (Ping timeout: 252 seconds) |
| 13:15:09 | FromGitter | <jrfondren> nah the snake oil for moving files around is ceph. |
| 13:16:29 | * | seni joined #nim |
| 13:17:41 | noonien | @Araq ssh or http are used usually |
| 13:17:54 | noonien | or other more complicated deployment mechanisms |
| 13:18:25 | noonien | but the transport is usually http(either upload, or download) or ssh |
| 13:20:19 | FromGitter | <arnetheduck> point is, it's 2019 and you look at the std lib - it has ftp, md5 and an SQL parser, but for example practically nothing on the parallelism and multi-cpu front.. FTP is one of those unsecured relics of the past - yes, there's SFTP but the connection topology of FTP with its separate data and control streams makes it difficult to configure in modern networks so people have moved on to other protocols. thus, if I look |
| 13:20:19 | FromGitter | ... at the computer science landscape today and tomorrow, I'd rather that time and effort was spent on fixing `Channel` than fixing the FTP client |
| 13:20:21 | * | xet7 quit (Quit: Leaving) |
| 13:21:01 | FromGitter | <arnetheduck> at least, that would be more useful to me, and I believe, to the larger community of nim developers |
| 13:25:05 | * | theelous3 joined #nim |
| 13:28:03 | FromGitter | <arnetheduck> the mere presence of and FTP client in there slows down other development - there's no way around that. when you have a community the size of python, you can maybe keep up with the world and include all that stuff - but even python is moving towards a more distributed model with `pip` and `venv` - the core language devs can make a much bigger splash by nourishing an environment for others to build stuff in that |
| 13:28:03 | FromGitter | ... trying to maintain everything on their own |
| 13:32:16 | clyybber | it's always the question of wether to encourage users to build a diverse robust ecosystem (representing the computer science landscape today), or a conservative stdlib |
| 13:33:34 | FromGitter | <arnetheduck> well, let the community do the experimenting outside, and port the stable stuff back to std lib - best of both worlds :) |
| 13:33:55 | Araq | maybe there is also a middle ground. I don't need eg. htmlparser in the stdlib but I also don't want to maintain 20 different github repos, all with travis and appveyor integration, decent versioning and testing against stable Nim and Nim devel |
| 13:34:05 | FromGitter | <mratsim> Wow so much activity in the past hour |
| 13:34:46 | FromGitter | <mratsim> I think the last part Araq means, let's bring batteries to nimble/nawabs |
| 13:34:52 | FromGitter | <arnetheduck> that's actually one of the things I really like about nim - it's quite possible to build it with almost no std lib and adapt it to specific use case |
| 13:35:28 | FromGitter | <arnetheduck> that it has enough power to develop those experiments without having to fall back on changing the compiler is a big plus |
| 13:35:46 | clyybber | mratsim: Someday I'd like to hack with nawabs, maybe make it leverage git submodules for an even more simple but robust system. |
| 13:36:21 | FromGitter | <mratsim> Regarding std vs no std, Rust seem to have an excellent story w.r.t. to the serialization library, there used to be one in stdlib then Serde came along with a superior API, there was article on how to migrate and then the default ones (there was 2 different before serde) were deprecated |
| 13:36:23 | clyybber | arnetheduck: Yeah, even gameboy dev is possible with nim |
| 13:37:07 | Araq | we need a 'nimble/whatever init' that also sets up travis/appveyor and a git tag scheme |
| 13:38:07 | FromGitter | <mratsim> Concepts have the potential to bring a common interface/API for multiple libraries implementing the same thing, with whatever is agreed on being part of the stdlib concept and whatever is still uncertain being library only. |
| 13:38:16 | * | slugm quit (Remote host closed the connection) |
| 13:38:41 | FromGitter | <mratsim> @Araq, well feel free to fork: https://github.com/status-im/nimbus-launch |
| 13:39:32 | Araq | cool, I missed that one |
| 13:39:37 | FromGitter | <arnetheduck> we'd also like to have more than one library per git repo so we can monorepo the stuff we frequently develop together.. that sort of breaks the whole git tag thing |
| 13:40:21 | * | abm joined #nim |
| 13:41:09 | Araq | how so? the version only gets a little less informative |
| 13:41:26 | Araq | much like os.nim's version is Nim's version, but not a big deal, ymmv |
| 13:41:28 | FromGitter | <arnetheduck> there seems to be a distinct lack of people that *like* nim concepts as they're done now, at least judging from how much usage they get (more "I'd like to use concepts" than "I'm using concepts successfully").. I wonder if it's the quirky syntax, bugs or just unfamiliarity with their existance? |
| 13:41:54 | Araq | arnetheduck: I'll write an RFC about how 'concept' needs to be designed |
| 13:42:34 | FromGitter | <arnetheduck> well, it's another of those game-changers that would require the std lib to be adapted to be truly useful |
| 13:42:38 | FromGitter | <mratsim> I think 1. they are unfinished, VTable, 2. I'm always uneasy about the lack of constraints (and 3, compilation time :?) |
| 13:42:52 | clyybber | arnetheduck: IMO its because concepts are not used in the stdlib, and that they are buggy |
| 13:43:06 | noonien | i have managed to reproduce my second issue as well: https://github.com/nim-lang/Nim/issues/11188 |
| 13:43:10 | clyybber | but they are so powerful I use them anyways :P |
| 13:43:26 | FromGitter | <liquid600pgm> @arnetheduck myself, I don't use concepts that often just because of their bugginess |
| 13:43:49 | FromGitter | <liquid600pgm> I think they're useful, but their implementation needs to be worked on |
| 13:44:02 | noonien | it seems like symbol resolution for generic procs happens when the generic is initialized, not when it's defined |
| 13:44:09 | FromGitter | <mratsim> I'm using them in Arraymancer for neural net declaration and we're using them at Status for serialization |
| 13:44:17 | clyybber | Araq: Isn't concept already designed? Or do you mean the design of the implementation? Because I think only the implementation needs work |
| 13:44:39 | Araq | I don't agree with the current design anymore. |
| 13:44:50 | FromGitter | <mratsim> imho, generics, static, {.compileTime.} and concepts implementation needs an overhaul |
| 13:45:43 | Araq | I also don't like the syntax at all but I now also consider the design flawed. |
| 13:45:54 | clyybber | In what sense? |
| 13:46:09 | Araq | and to be fair, C++ is making all the same mistakes. |
| 13:46:36 | Araq | clyybber, a concept is a way to precisely nail down the constraints in my generic code. |
| 13:46:40 | FromGitter | <arnetheduck> re rust and serialization, yes, they have a well defined path for stuff to get included in std lib: develop outside to usefulness, intro the best parts into std lib as experimental to work out kinks, then open up to stable.. |
| 13:47:02 | FromGitter | <mratsim> and typedesc also are broken, see latest discussion: https://github.com/nim-lang/Nim/issues/11152#issuecomment-488579780 |
| 13:47:53 | Araq | clyybber, and given that, it's silly not to *typecheck* the generic code |
| 13:48:05 | Araq | not the instantiation, but the generic itself. |
| 13:48:37 | FromGitter | <mratsim> @Araq, basically I want an article of Concepts vs Traits because right now Concepts is "wide-open and good luck matching it" while Traits you have to match it or compile-time error |
| 13:48:52 | FromGitter | <arnetheduck> of course, they didn't have that path in the beginning, but now that they're maturing.. |
| 13:49:33 | Araq | if the generic proc is not type checked even in the presence of a concept, what's the point? |
| 13:50:01 | Araq | I can already use a generic underconstrainted 'T' instead and don't need to bother with a concept then |
| 13:50:41 | Araq | all that the 'concept' does is that it allows for even more overloading or something, that's not worth their inherent complexity |
| 13:51:03 | Araq | complex stuff has to be worth it. |
| 13:51:50 | FromGitter | <mratsim> So higher kinded types? :p |
| 13:52:03 | Araq | like the destructors and moves semantics, they suck, more language rules, more complexity. But if we use them to remove the freakin' GC is worth it |
| 13:53:39 | Araq | same for concepts, if we embrace them, we can use them to make generic code less quirky |
| 13:53:43 | FromGitter | <mratsim> Well, I use them to avoid inheritance in Arraymancer: https://github.com/mratsim/Arraymancer/blob/master/src/nn_dsl/dsl_types.nim#L63-L68 |
| 13:54:35 | FromGitter | <mratsim> So that user defined types can be used if they are "TrainableLayer" (and no need for GC/ref indirection) |
| 13:55:17 | Araq | terrible :-) |
| 13:55:46 | Araq | Instead of TrainableLayer[TT] you can use TT in your code and maybe a 'when compiles' check |
| 13:56:20 | FromGitter | <mratsim> when compiles is like the ugly hack when everything else fails :P |
| 13:56:59 | Araq | let me tell you a secret: the concept implementation as a hole is built upon system.compiles |
| 13:57:08 | Araq | *whole, nice typo. |
| 13:57:28 | * | PMunch quit (Remote host closed the connection) |
| 13:58:23 | FromGitter | <mratsim> well uneasiness intensifies |
| 14:00:18 | FromGitter | <arnetheduck> well, that's what concepts are, as defined now: "if all this syntax happen to compile for T, we're green" |
| 14:01:22 | Araq | there are also other problems with the idea, problems that C# and even Python share |
| 14:02:13 | Araq | I tried to conceptify 'parseutils', for example |
| 14:02:27 | Araq | proc captureBetween*(s: string, first: char, second = '\0', start = 0): string |
| 14:02:58 | Araq | ok, 's: string' becomes the new shiny 's: StringLike' |
| 14:03:07 | Araq | what does the return type become? |
| 14:03:59 | Araq | ConstructibleStringLike ? how to determine what to return? |
| 14:04:23 | Araq | should all procs that happen to return something grow a typedesc parameter? |
| 14:05:11 | FromGitter | <mratsim> s.concrete() --> that use the concrete typed passed |
| 14:05:29 | FromGitter | <mratsim> but yeah I had this issue as well when I tried to use concepts |
| 14:05:56 | FromGitter | <mratsim> well it's an non-issue if you return Error Code ;) |
| 14:06:56 | * | gmpreussner_ joined #nim |
| 14:07:13 | Araq | in general input parameters and output parameters/return values have different types, one requires only a "readonly" concept, the other some way to construct it |
| 14:07:20 | * | gmpreussner quit (Ping timeout: 255 seconds) |
| 14:08:12 | noonien | string should just be a specialization of seq[char], or array[N, char], and captureBetween should return a read-only range/slice into that initial string |
| 14:08:39 | Araq | that has its own set of problems, noonien |
| 14:09:33 | noonien | yes, they might be solved by an ownership system |
| 14:10:01 | noonien | i don't like rust's though |
| 14:10:16 | FromGitter | <liquid600pgm> I have a major concern for the ownership system: strictness |
| 14:10:30 | Araq | ok, assuming that it is THE solution, in the end many people use Python/Visual Basic because they need to "get shit done" |
| 14:10:32 | FromGitter | <liquid600pgm> if it's gonna be as strict as Rust, it will be infuriating to get used to |
| 14:11:01 | noonien | yeah, i hate writing describing logic by using types |
| 14:11:27 | Araq | and a multitude of string-like types quickly becomes what I tend to call "sophistry" |
| 14:11:37 | noonien | i'm unfamilliar with other ownership systems other than rusts, i need to look further into thos |
| 14:12:34 | Araq | in the end I don't even want 'captureBetween', I want a lexer generator or something else |
| 14:13:07 | Araq | or an optimizer that understands substr() and optimizes it away |
| 14:15:23 | noonien | does nim have any other kind of IR other than what `macros` defines? |
| 14:15:38 | noonien | if not, it would be cool to have a way to provide AST optimizations by libraries |
| 14:16:11 | Araq | we have term-rewriting macros for that |
| 14:16:25 | FromGitter | <arnetheduck> optimizer approach is kind of sad, limits it to strings |
| 14:16:51 | * | Trustable joined #nim |
| 14:16:51 | Araq | we also have a bytecode in the vm.nim and a control flow graph that I'm trying to make the new IR, but it's tough :P |
| 14:17:10 | noonien | no, i mean sommething more global, perhaps something akin to importing compile-time optimize libraries, that just contain rewriting macros |
| 14:17:50 | * | rayman22201 joined #nim |
| 14:18:17 | Araq | noonien, well be my guest and write a TR-macro library |
| 14:18:17 | noonien | the optimizations would be applied at a certain stage, without any user intervention other than importing them |
| 14:18:27 | noonien | hehe |
| 14:19:17 | FromGitter | <kaushalmodi> How do I cast in coming pointer (void \*) from C side to a proc type? |
| 14:19:25 | Araq | arnetheduck: it was meant an example for how 'concept' has its own problems |
| 14:19:47 | FromGitter | <kaushalmodi> I am trying to translate this from C to Nim: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cd042832e2caa1aa61aa27b] |
| 14:20:42 | clyybber | noonien Theres source code filters |
| 14:20:57 | clyybber | and regexes :P |
| 14:22:19 | FromGitter | <kaushalmodi> I am trying to do below as a conversion of above C code, but it doesn't compile: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cd0431bb489bb6ed7262245] |
| 14:22:46 | FromGitter | <kaushalmodi> The error I get is: ⏎ ⏎ > Error: expression cannot be cast to proc (): cint{.closure.} |
| 14:24:58 | clyybber | khaushalmodi: You gotta add {.cdecl.} afair |
| 14:25:20 | clyybber | I'm not sure if {.cdecl.} works with anon procs though |
| 14:25:32 | Araq | it does. |
| 14:25:37 | clyybber | nice |
| 14:26:20 | FromGitter | <kaushalmodi> actually I tried something by fluke and it worked! |
| 14:26:23 | * | neceve joined #nim |
| 14:26:27 | FromGitter | <kaushalmodi> someone please explain it to me: `pcp = castproc(): cint {.noconv.} (inChandle)` |
| 14:26:54 | FromGitter | <kaushalmodi> I remembered seeing `noconv` in posix.nim and I just tried it .. I read in the manual, but I didn't understand why that worked |
| 14:27:19 | noonien | hmm, can i create a repeating string of N bytes long?, something like "\0".repeat(4) |
| 14:28:10 | noonien | ah, repeat in strutils |
| 14:28:10 | FromGitter | <kaushalmodi> Araq, clyybber: `pcp = castproc(): cint {.cdecl.} (inChandle)` also worked |
| 14:28:19 | FromGitter | <kaushalmodi> but .. what does that mean? |
| 14:28:20 | clyybber | khaushalmodi: noconv is the same as cdecl except on windows |
| 14:28:44 | FromGitter | <kaushalmodi> "cdecl" enforced "C function type" vs "Nim proc type"? |
| 14:28:50 | clyybber | kaushalmodi: Yeah |
| 14:28:52 | FromGitter | <kaushalmodi> s/enforced/enforces |
| 14:28:55 | FromGitter | <kaushalmodi> hmm, ok |
| 14:28:57 | clyybber | noconv too |
| 14:29:03 | FromGitter | <kaushalmodi> I can live with that explanation :) |
| 14:29:11 | FromGitter | <kaushalmodi> thanks |
| 14:29:28 | clyybber | but windows c compilers have different calling conventions sometimes, so cdecl adds __cdecl just to be safe |
| 14:29:30 | clyybber | afaik |
| 14:31:30 | clyybber | to clarify its because msvc likes to mangle names differently than any other compiler if you dont add __cdecl |
| 14:33:12 | FromGitter | <kaushalmodi> got it |
| 14:36:04 | * | Perkol joined #nim |
| 14:47:19 | * | kapil____ joined #nim |
| 14:50:02 | * | Perkol quit (Remote host closed the connection) |
| 15:06:24 | shashlick | Will 0.19.6 use the new nimble as well? |
| 15:07:40 | noonien | hmm, how can i run 2 async procs, and wait for them to complete concurrently? |
| 15:08:29 | dom96 | await proc1() and proc2() |
| 15:08:43 | * | theelous3 quit (Ping timeout: 248 seconds) |
| 15:10:31 | noonien | https://github.com/nim-lang/Nim/blob/master/lib/pure/asyncfutures.nim#L351 nice, thanks! |
| 15:14:33 | Araq | clyybber, calling conventions are only vaguely related to name mangling. every CPU has calling convention(s) |
| 15:15:23 | Araq | for example, Java's hotspot uses a different calling convention than Linux on x86_64 |
| 15:15:50 | dom96 | arnetheduck: What I want from you is to merge your changes to asyncdispatch upstream, at least once every 6 months. I think that's fair. |
| 15:16:22 | * | Jesin quit (Quit: Leaving) |
| 15:28:28 | * | JappleAck quit (Ping timeout: 246 seconds) |
| 15:29:10 | clyybber | Araq: Oh, yeah. But in this case(mscv) it affects the name mangling too, I think. I haven't used windows for a long time, but I remember that it caused problems with crosscalling code compiled by mingw and msvc |
| 15:31:07 | * | hoijui quit (Ping timeout: 248 seconds) |
| 15:32:52 | Araq | the name mangling is a *feature* to detect bugs |
| 15:32:59 | Araq | caused by different calling conventions |
| 15:34:29 | * | Jesin joined #nim |
| 15:37:00 | clyybber | ah, that makes sense |
| 15:48:03 | * | hoijui joined #nim |
| 15:49:41 | * | rnrwashere joined #nim |
| 16:17:24 | disruptek | dom96: you want fixes propogated back to async in stdlib, but you're unwilling/unable to create those patches yourself. not even once every six months. |
| 16:17:45 | disruptek | "If I did it again I wouldn't have put async in the stdlib" |
| 16:17:56 | disruptek | "Because it would be easier to evolve it outside the stdlib" |
| 16:18:02 | disruptek | and yet... |
| 16:18:07 | dom96 | disruptek: I do not have the luxury of working full time on a Nim project |
| 16:18:49 | disruptek | i get the impression that status doesn't have the luxury of enhancing async as per your instruction, and that's why the situation is what it is. |
| 16:19:31 | disruptek | it's funny that "once per six months" is == "fulltime", and yet this is what you're asking of status. |
| 16:19:48 | disruptek | so, you don't have that luxury, but you think it's "fair" to ask that of them. :-P |
| 16:21:15 | dom96 | If they are truly too busy to do it then fair enough. I get the impression that they don't want to do it for whatever reason |
| 16:22:52 | disruptek | agreed. this won't be the first or last time nim has spawned alternatives to stdlib. hopefully, the ecosystem will grow to where stdlib solutions can be deprecated for better-supported, more performant, and featureful external libs. i think that's what we all want (except for @Araq, perhaps). |
| 16:22:53 | * | drewr quit (Quit: ERC (IRC client for Emacs 26.1)) |
| 16:23:29 | dom96 | The problem with something like async though is that you need everyone to use the same thing |
| 16:24:00 | dom96 | I did say that if I did it again I wouldn't put it in the stdlib, but that was ... probably like 4 years ago now |
| 16:24:22 | disruptek | if you think that's more important than the quality of software, then i guess you should be a proponent of deprecating async in favor of chronos, right? since neither side is willing to merge the other's changes. |
| 16:24:33 | dom96 | The situation is now different, we need to work together or we'll split the package repo into pieces |
| 16:27:01 | federico3 | but async I/O should be part of the language |
| 16:27:19 | dom96 | definitely |
| 16:27:46 | noonien | doe async not work with unittest? |
| 16:27:54 | federico3 | I wish we had some sort of "multisync" by default |
| 16:28:26 | dom96 | noonien, it does, but you might have to create async procs and call them from within unittest via `waitFor` |
| 16:29:00 | noonien | i have, the error i'm getting is: Error: undeclared identifier: 'await' |
| 16:29:14 | dom96 | then your code isn't inside an async proc |
| 16:29:17 | noonien | even though i've got `import asyncnet, asyncdispatch` |
| 16:29:41 | noonien | hhm |
| 16:29:48 | federico3 | better error msgs and better tracebacks would really help |
| 16:29:49 | noonien | do i have to have Future[void] as a return value? |
| 16:29:59 | disruptek | you can only await inside {.async.} though you can waitfor everywhere. |
| 16:30:21 | noonien | this is the line that is erroring: `proc receive() {.async.} = received = await receiver.recv(T)` |
| 16:30:28 | noonien | even though it's a proc inside a proc |
| 16:30:31 | noonien | so, a clojure i guess |
| 16:30:47 | * | nsf quit (Quit: WeeChat 2.4) |
| 16:30:54 | noonien | i'm unsure how closures works in nim yet |
| 16:33:27 | * | hoijui quit (Remote host closed the connection) |
| 16:42:47 | * | theelous3 joined #nim |
| 16:43:24 | * | Jjp137 quit (Quit: Leaving) |
| 16:44:12 | dom96 | https://user-images.githubusercontent.com/246651/57240465-6c53a500-7026-11e9-82de-51aa910838fe.png :D |
| 16:44:24 | dom96 | Prometheus ftw |
| 16:44:34 | dom96 | If you've got a leaky server app in Nim, this might help you figure out why |
| 16:46:15 | * | nimer joined #nim |
| 16:47:17 | * | rayman22201 quit (Quit: Connection closed for inactivity) |
| 16:47:25 | nimer | Hi all, i am looking for a PDF parsing library. Anything available? |
| 16:48:23 | * | nimer left #nim (#nim) |
| 16:49:03 | noonien | this is the code that seems to trigger the compile error: http://vpaste.net/5PE3B |
| 16:49:24 | noonien | not declaring the receive proc seems to not trigger the bug |
| 16:52:16 | noonien | if testSendRcv is not generic, the error does not seem to trigger |
| 16:56:27 | clyybber | nimer: I only know of nimPDF |
| 16:56:37 | clyybber | but I'm not sure if that does parsing as well |
| 16:57:36 | narimiran | clyybber: yesterday we couldn't even do `import nimpdf`, let alone parsing :D |
| 16:58:41 | clyybber | oh, well nevermind then :D |
| 16:59:11 | noonien | an even simpler repro of the same bug: http://vpaste.net/I7VD2 |
| 16:59:21 | * | rnrwashere quit (Remote host closed the connection) |
| 16:59:29 | noonien | i'm not sure this is a bug, perhaps i'm just doing something wrong |
| 17:00:00 | * | mrk joined #nim |
| 17:00:17 | mrk | hey i tried nim back in 2017 |
| 17:00:55 | mrk | had lots of wrong behavior for standard features and when i asked here people told me it was compiler bugs |
| 17:01:02 | mrk | is the language stable yet? |
| 17:01:11 | FromDiscord_ | <kodkuce> yes and no 😃 |
| 17:01:55 | FromDiscord_ | <kodkuce> normal stuff should work , but there is new run-time in works too thats atm i think in alpha stage |
| 17:02:30 | FromDiscord_ | <kodkuce> but probbaly dont take my info for granted i mostly lurk here did only some small code stuff with nim |
| 17:05:15 | narimiran | mrk: do you remember, what kinds of wrong behaviour? |
| 17:06:18 | mrk | not exactly |
| 17:06:42 | mrk | but it was standard features/functions that didnt function how they should |
| 17:06:52 | mrk | people told me they were compiler bugs |
| 17:08:26 | narimiran | then maybe it would be the best for you to try it out yourself. lots of stuff has been changed/improved in the mean time |
| 17:14:13 | * | rnrwashere joined #nim |
| 17:14:41 | noonien | hmm, can i not have var params in async procs? |
| 17:16:00 | * | drewr joined #nim |
| 17:26:53 | dom96 | narimiran: huh, why couldn't you import nimpdf? |
| 17:27:07 | narimiran | dom96: try it yourself |
| 17:27:29 | dom96 | noonien, nope. Use `FutureVar[T]` |
| 17:27:32 | narimiran | `nimble install nimPDF` and then just `import nimPDF` in some file |
| 17:27:55 | clyybber | because there is no file called nimpdf |
| 17:28:18 | clyybber | nevermind, there is |
| 17:28:32 | dom96 | narimiran: I don't see a nimpdf.nim in the package's repo |
| 17:28:35 | dom96 | https://github.com/jangko/nimpdf |
| 17:29:08 | clyybber | dom96 Inside the nimPFD folder, but he seems to forgot to set srcDir in the .nimble |
| 17:29:41 | dom96 | no, he should move nimPDF.nim into the root |
| 17:30:09 | * | mrk quit (Quit: Page closed) |
| 17:31:34 | * | nsf joined #nim |
| 17:31:43 | noonien | dom96: awesome! any examples of using FutureVar by any chance? |
| 17:32:55 | dom96 | https://github.com/nim-lang/Nim/blob/devel/tests/async/tfuturevar.nim |
| 17:33:16 | dom96 | lol why is this disabled |
| 17:33:22 | federico3 | dom96: are you exposing the status of async routines now? |
| 17:33:27 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 17:33:36 | dom96 | federico3: yep, once my PR gets merged to devel |
| 17:34:10 | federico3 | what changed your mind? |
| 17:34:27 | dom96 | federico3: hrm? What of my mind did I change? |
| 17:35:20 | federico3 | dom96: in the past I asked to give access to the futures with something like getFuturesInProgress |
| 17:36:40 | dom96 | I vaguely recall that, but I don't remember the context in which you wanted this |
| 17:37:37 | federico3 | to be able to do profiling or debug a hanging "coroutine", mostly |
| 17:38:39 | dom96 | My bad then. That's exactly why I ended up adding it |
| 17:38:58 | dom96 | I spent many hours debugging a memory leak and it turned out to be a stuck future |
| 17:40:37 | * | rnrwashere quit (Remote host closed the connection) |
| 17:44:14 | dom96 | federico3: you might want to add prometheus to your web servers and set up my prometheus package in your projects |
| 17:44:28 | federico3 | unlikely |
| 17:46:05 | dom96 | Why? |
| 17:47:13 | federico3 | for application metrics, statsd is a better fit (modulo it simplistic metric format) because it does not require an HTTP server |
| 17:47:43 | federico3 | (statsd the protocol, not the daemon itself) |
| 17:48:29 | dom96 | Right, but if you've got a HTTP server anyway? |
| 17:50:52 | federico3 | the one serving metrics to prom should have a different address and thread/coroutine |
| 17:51:35 | federico3 | (and not all my daemons use http) |
| 17:52:25 | federico3 | also you can use statsd in scripts, applications and other short-lived programs |
| 17:56:33 | * | rnrwashere joined #nim |
| 17:58:50 | disruptek | i prefer statsd, too, but you can always statsd->prometheus. |
| 18:07:39 | dom96 | can you go the other way around? :) |
| 18:08:03 | * | rnrwashere quit (Remote host closed the connection) |
| 18:09:14 | disruptek | you can prometheus->datadog; i haven't done much else with prometheus. |
| 18:09:44 | disruptek | used to use librato, which is now solarwinds or appoptics or something like that. |
| 18:12:03 | disruptek | i guess it's both those things. |
| 18:12:58 | * | rnrwashere joined #nim |
| 18:14:05 | dom96 | So this is interesting: https://twitter.com/d0m96/status/1125463625097936897 |
| 18:20:45 | FromDiscord_ | <j$> is there a way I can compile a link a dir to load dlls from? |
| 18:22:07 | FromDiscord_ | <j$> compile and* |
| 18:23:16 | * | jjido joined #nim |
| 18:24:49 | * | Trustable quit (Remote host closed the connection) |
| 18:30:11 | * | neceve quit (Remote host closed the connection) |
| 18:44:19 | clyybber | narimiran: Have you tried kakoune? |
| 18:44:29 | narimiran | clyybber: long time ago, why? |
| 18:44:51 | clyybber | SolitudeSF made nim syntax highlighting for kak |
| 18:45:00 | clyybber | it works pretty well, am using it rn |
| 18:45:29 | clyybber | and I made a wrapper for nimsuggest for kakoune in bash |
| 18:45:54 | clyybber | which broke down after some nimsuggest change :P as expected for so many regexes |
| 18:46:33 | narimiran | i'm using neovim with leorize[m]'s plugin and it works like a charm - it replaced vscode for me |
| 18:46:46 | clyybber | oh, yeah leorize's plugin is awesome |
| 18:47:19 | clyybber | ah, snap I didn't wrap nimsuggest, I "wrapped" nim check, so nothing fancy |
| 18:48:27 | livcd | what is this async vs chronos debate? |
| 18:49:31 | clyybber | chronos is evolving and developing, while async in the stdlib is not. chronos is a fork of the stdlib async |
| 18:50:07 | livcd | just that sentence alone will make people question the existence of async in the stdlib |
| 18:58:13 | clyybber | well |
| 18:58:37 | dom96 | clyybber, that statement is dangerous and will make people avoid stdlib async |
| 18:58:37 | * | rnrwashere quit (Remote host closed the connection) |
| 18:59:30 | clyybber | dom96: I didn't mean to discourage people from using stdlib async |
| 19:00:04 | * | rnrwashere joined #nim |
| 19:00:20 | dom96 | I know. I think some might read it and be discouraged though |
| 19:02:14 | dom96 | There is nothing significantly different about chronos to warrant its usage, unless you run into issues which chronos purports to solve |
| 19:18:02 | livcd | the new terminal on windows looks good |
| 19:32:53 | * | krux02_ joined #nim |
| 19:32:53 | * | solitudesf- joined #nim |
| 19:33:40 | * | Vladar quit (Remote host closed the connection) |
| 19:35:06 | * | deech_ joined #nim |
| 19:35:26 | zestyr | I'm trying to figure out a way to make a simple cache for objects. The program is a jester server that requests data and displays it, so caching that data would be preferable, but since it's multithreaded I can't find a good way to achieve this |
| 19:35:36 | * | luis__ joined #nim |
| 19:36:13 | zestyr | I tried using a table but got GC safety errors |
| 19:37:15 | * | luis__ quit (Remote host closed the connection) |
| 19:38:44 | * | dddddd_ joined #nim |
| 19:39:17 | * | rnrwashere quit (Remote host closed the connection) |
| 19:39:24 | * | cornfeedhobo quit (Ping timeout: 248 seconds) |
| 19:39:24 | * | banc quit (Ping timeout: 248 seconds) |
| 19:39:25 | * | floppydh quit (Ping timeout: 248 seconds) |
| 19:39:42 | * | solitudesf quit (Ping timeout: 248 seconds) |
| 19:39:42 | * | deech quit (Ping timeout: 248 seconds) |
| 19:39:42 | * | dddddd quit (Ping timeout: 248 seconds) |
| 19:39:42 | * | krux02 quit (Ping timeout: 248 seconds) |
| 19:39:56 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 19:40:11 | FromGitter | <jrfondren> I imagine you'd have a single thread handle all the caching, and since it's a server and what you want to do with cache is just send it to a socket, you can pass sockets to the caching thread rather than copy the cached data between threads. |
| 19:40:20 | * | banc joined #nim |
| 19:44:07 | dom96 | zestyr, would a cache per each thread work? |
| 19:44:29 | dom96 | In that case simply create a `var cache {.threadvar.}: Table[string, Blah]` |
| 19:44:43 | zestyr | could work but is suboptimal, I'm trying to reduce requests as much as possible |
| 19:44:44 | dom96 | in Nim devel the Table is initialised implicitly |
| 19:44:57 | zestyr | I'm working on an alternative twitter front-end so requests are expensive |
| 19:45:28 | shashlick | use shared memory and locks |
| 19:46:22 | dom96 | You can try this as well: https://nim-lang.org/docs/sharedtables.html |
| 19:46:33 | shashlick | i was just about to link that |
| 19:46:35 | dom96 | I would avoid passing sockets between threads |
| 19:46:48 | shashlick | or use boehm gc and party |
| 19:46:48 | zestyr | it does say this though: "Use plain old non GC'ed keys and values or you'll be in trouble" |
| 19:47:21 | zestyr | I guess I can just use int keys and non-ref objects |
| 19:47:53 | * | seni quit (Quit: Leaving) |
| 19:48:28 | shashlick | boehm handles shared memory |
| 19:48:43 | * | dddddd_ is now known as dddddd |
| 19:51:06 | * | cornfeedhobo joined #nim |
| 20:07:51 | * | solitudesf-- joined #nim |
| 20:08:24 | * | solitudesf-- quit (Client Quit) |
| 20:08:44 | * | solitudesf joined #nim |
| 20:10:26 | * | nsf quit (Quit: WeeChat 2.4) |
| 20:11:07 | * | solitudesf- quit (Ping timeout: 268 seconds) |
| 20:13:33 | * | Jesin quit (Quit: Leaving) |
| 20:18:50 | * | Jesin joined #nim |
| 20:21:27 | * | Gertm joined #nim |
| 20:28:08 | zestyr | this is giving me a headache lol, I've tried to use sharedtables in a few different ways now but either I get tons of errors or memory corruption |
| 20:29:56 | Araq | use --gc:boehm and the usual stuff |
| 20:31:06 | zestyr | by usual stuff do you mean Table? |
| 20:32:14 | Araq | yeah, use a {.gcsafe.}: block to make the compiler shut up and accept the GC is threadsafe |
| 20:36:01 | zestyr | hmm I get segfaults from times.zonedTimeFromTime and net.wrapConnectionSocket with --gc:boehm |
| 20:40:14 | Araq | huh? |
| 20:42:50 | clyybber | good night |
| 20:42:58 | * | clyybber quit (Quit: WeeChat 2.4) |
| 20:48:48 | zestyr | Araq: here's a small example http://ix.io/1Igf |
| 20:52:30 | zestyr | and here's the net segfault: http://ix.io/1Igg |
| 20:52:37 | zestyr | both work fine when not using boehm |
| 20:52:51 | Araq | zestyr, what's your OS? |
| 20:53:03 | zestyr | Linux |
| 20:53:16 | Araq | recent boehm version? |
| 20:55:46 | * | rayman22201 joined #nim |
| 20:55:54 | zestyr | 7.6.8 I think |
| 21:02:45 | Araq | works for me but I'm on Windows |
| 21:04:37 | * | narimiran quit (Ping timeout: 245 seconds) |
| 21:17:46 | * | Jjp137 joined #nim |
| 21:34:53 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:35:24 | dom96 | huh, that's super odd zestyr. Maybe you'd be adventurous enough to look into the code pointed to by these stack traces? |
| 21:39:52 | * | rnrwashere joined #nim |
| 21:40:05 | * | lritter quit (Quit: Leaving) |
| 21:42:12 | Araq | dom96, I did look, it's nothing obvious |
| 21:42:27 | Araq | can have a look tomorrow in my Linux Vm |
| 21:44:04 | * | rnrwashere quit (Ping timeout: 252 seconds) |
| 21:52:11 | * | solitudesf quit (Ping timeout: 244 seconds) |
| 22:38:24 | * | Hexeratops joined #nim |
| 23:09:21 | * | kotrcka joined #nim |
| 23:47:28 | * | krux02__ joined #nim |
| 23:49:28 | * | krux02_ quit (Ping timeout: 252 seconds) |
| 23:55:02 | * | krux02__ quit (Remote host closed the connection) |
| 23:55:12 | * | tiorock joined #nim |
| 23:55:12 | * | tiorock quit (Changing host) |
| 23:55:12 | * | tiorock joined #nim |
| 23:55:12 | * | rockcavera quit (Killed (weber.freenode.net (Nickname regained by services))) |
| 23:55:12 | * | tiorock is now known as rockcavera |
