| 00:17:44 | * | sealmove quit (Quit: WeeChat 2.5) |
| 00:19:58 | * | abm quit (Ping timeout: 268 seconds) |
| 00:46:43 | blackbeard420 | for pqexecParams() how would i go about making the cstringArray from a seq[string] and also how would i create a ptr int32 from an array of ints? |
| 00:51:22 | PMunch | The cstringArray needs some memory copying |
| 00:51:32 | PMunch | Or wait, maybe not.. |
| 00:51:44 | PMunch | But what do you mean a ptr int32 from an array of ints? |
| 00:52:00 | PMunch | Like an array of four int8s into an int32 |
| 00:55:32 | PMunch | blackbeard420 ^ |
| 00:56:04 | blackbeard420 | pqexecParams expects a pointer to the start of an array of ints in the C call for paramFormats. but im not sure how to approach that from nim |
| 00:56:23 | blackbeard420 | https://nim-lang.org/docs/postgres.html#pqexecParams%2CPPGconn%2Ccstring%2Cint32%2CPOid%2CcstringArray%2Cptr.int32%2Cptr.int32%2Cint32 |
| 01:01:39 | PMunch | Well ptr int32 is easy, that would just be a call to addr on an array of int32 |
| 01:02:41 | PMunch | Is there a reason you have a seq[string] in your code instead of a cstringArray? |
| 01:03:33 | PMunch | A cstringArray is an array of pointers to strings |
| 01:03:36 | blackbeard420 | i got the cstringArray part working by using allocCstringArray on an openarray of ints |
| 01:04:03 | blackbeard420 | but for the array of int32's its saying expression has no address |
| 01:04:25 | blackbeard420 | s/openarray of ints/openarray of string/ |
| 01:04:26 | PMunch | Ah, that's because it's not mutable probably |
| 01:04:44 | blackbeard420 | oh wow, thanks that was it |
| 01:04:47 | blackbeard420 | thanks again! |
| 01:04:49 | PMunch | :) |
| 01:04:56 | PMunch | You could also use unsafeAddr |
| 01:05:38 | PMunch | But that's well unsafe |
| 01:05:52 | PMunch | Or rather more unsafe than regular addr |
| 01:06:31 | PMunch | Because it will probably end up pointing to a position on the stack, so if your stack pops then the address will point to something else or be invalid |
| 01:10:18 | * | actuallybatman quit (Ping timeout: 272 seconds) |
| 01:33:49 | * | PMunch quit (Remote host closed the connection) |
| 01:59:45 | * | drprune joined #nim |
| 02:00:36 | drprune | What have I done wrong? |
| 02:00:37 | drprune | bin/nim c koch |
| 02:00:37 | drprune | Hint: used config file '/home/eliot/src/Nim/config/nim.cfg' [Conf] |
| 02:00:37 | drprune | Hint: used config file 'koch.nim.cfg' [Conf] |
| 02:00:37 | drprune | Hint: system [Processing] |
| 02:00:58 | drprune | Nim/lib/system.nim(207, 11) Error: undeclared identifier: 'is' |
| 02:01:29 | drprune | Using current git master |
| 02:07:02 | Tanger | drprune, did you run `sh build_all.sh` first? What OS as well>? |
| 02:09:53 | Tanger | Compiled fine on mine |
| 02:10:07 | Tanger | Running ubuntu |
| 02:14:36 | drprune | debian 9 |
| 02:15:18 | shashlick | how did you compile bin/nim |
| 02:15:31 | shashlick | and perhaps before that, how did you get the source |
| 02:16:41 | drprune | Right now I'm re-running in a clean git checkout. Back in a couple of minutes |
| 02:17:21 | shashlick | you want devel? |
| 02:22:30 | drprune | You mean I should check out devel? |
| 02:22:49 | shashlick | no i mean do you want devel or a release version? |
| 02:22:57 | shashlick | if you want release, get a tar.xz file |
| 02:23:10 | shashlick | if you want nightlies, get that tar.xz then |
| 02:23:36 | drprune | I'm just following the Compile instructions from https://github.com/nim-lang/Nim |
| 02:25:37 | * | lritter quit (Ping timeout: 244 seconds) |
| 02:27:15 | FromGitter | <Obround> How do you import a file from a sibling directory? Something like this (https://stackoverflow.com/questions/54622024/import-a-library-which-is-in-a-sibling-of-the-current-folder/) except in Nim instead of Python? |
| 02:30:49 | * | yeetcannon joined #nim |
| 02:31:38 | drprune | slashclick, I checkout out git head (v0.20), and that built fine. Strange. Will try 0.19.6 release archive for comparison.' |
| 02:32:12 | drprune | oops 19.6 release, same problem: Nim-0.19.6/lib/system.nim(207, 11) Error: undeclared identifier: 'is' |
| 02:33:42 | Tanger | Obround: You can add a config.nims file to the folder your main app runs in with `switch("path", "..")` |
| 02:34:05 | Tanger | That sets the runtime path to be a step above and you can then import from the sibling directory like that |
| 02:36:29 | shashlick | @Obround: you can also `import ".."/file` |
| 02:37:14 | shashlick | @drprune - but are you running build.sh first? |
| 02:41:19 | drprune | @slashlick, build_all.sh clones csources and runs build.sh |
| 02:43:10 | shashlick | ok so just to be clear, you downloaded the 0.19.6.tar.xz file, extracted, cd and build_all.sh? |
| 02:43:16 | drprune | @slashlick - I'm happy that 0.20.0 is building for me, from release tarball as well as git checkout. |
| 02:43:25 | drprune | yes, download and build_all.sh |
| 02:43:35 | drprune | failed for 0.19.[4,6] |
| 02:43:43 | drprune | worked for 0.20.0 |
| 02:44:03 | shashlick | can you share the link? i'll try on my machine |
| 02:44:33 | drprune | From https://github.com/nim-lang/Nim/releases |
| 02:45:27 | drprune | I'd guess it is not a common problem if more people aren't complaining by now ;) |
| 02:50:32 | shashlick | okay i see why |
| 02:50:45 | shashlick | where did you see instructions to download that archive? |
| 02:51:03 | shashlick | you are downloading v0.19.6 but are using latest csources |
| 02:51:43 | drprune | That is what build_all.sh does |
| 02:52:20 | drprune | also here: https://github.com/nim-lang/Nim, the compile instructions call for git clone, which gets master branch which is approx 0.19.6 |
| 02:52:39 | drprune | https://github.com/nim-lang/Nim |
| 02:52:39 | shashlick | you want to download https://nim-lang.org/download/nim-0.19.6.tar.xz |
| 02:52:51 | shashlick | it contains the csources snapshot for that release of nim |
| 02:52:54 | drprune | git clone https://github.com/nim-lang/Nim.git |
| 02:52:54 | drprune | cd Nim |
| 02:52:54 | drprune | # step 2 (posix) clones `csources.git`, bootstraps Nim compiler and compiles tools |
| 02:52:54 | drprune | sh build_all.sh |
| 02:53:39 | shashlick | Note: The following commands are for the development version of the compiler. |
| 02:54:04 | drprune | OK |
| 02:54:27 | shashlick | use choosenim or the link I provided instead |
| 02:55:23 | drprune | I guess the summary is that the current build instructions on github do not work, because incompatible branches of Nim and nim_csources get checked out by default. |
| 02:56:20 | drprune | build instructions are those 4 pasted lines up there. |
| 02:56:32 | drprune | Yes, I will try the official download as you suggest |
| 03:06:36 | * | actuallybatman joined #nim |
| 03:24:26 | * | fjellfras joined #nim |
| 03:27:07 | drprune | @slashlick - thanks! bye... |
| 03:27:18 | * | drprune left #nim ("Leaving") |
| 03:40:55 | shashlick | looks like `currentSourcePath` doesn't work in `nim doc` |
| 04:14:52 | * | dddddd quit (Remote host closed the connection) |
| 04:24:16 | * | nsf joined #nim |
| 04:39:10 | * | sniffdtek joined #nim |
| 04:50:20 | * | leorize joined #nim |
| 04:52:31 | * | brakmic joined #nim |
| 04:56:23 | * | brakmic_ joined #nim |
| 04:57:02 | * | brakmic__ joined #nim |
| 04:57:04 | FromGitter | <rtnlmeme-DestroyerOfDeath> If I do `nimble install nimsuggest` I get: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ should it work? [https://gitter.im/nim-lang/Nim?at=5d2d591f4f7f9e219c0061be] |
| 04:57:35 | rayman22201 | @Zevv or @Dom96, either of you guys around? I was trying to do the lazy initing of the asyncEvent that @Dom96 suggested, but I'm having issues. Even when I override the `callback=` proc for FlowVar, it calls the FutureBase version. |
| 04:57:54 | leorize | @rtnlmeme-DestroyerOfDeath you should definitely not install nimsuggest that way |
| 04:58:31 | FromGitter | <rtnlmeme-DestroyerOfDeath> @FromIRC ah ok |
| 04:59:37 | rayman22201 | which actually makes perfect sense: the async macro explicitly creates a FutureBase object, and the FlowVar is being downcast to a FutureBase (the parent class)... |
| 05:00:02 | * | brakmic quit (Ping timeout: 245 seconds) |
| 05:00:28 | * | brakmic_ quit (Ping timeout: 245 seconds) |
| 05:00:40 | leorize | @rtnlmeme-DestroyerOfDeath nimsuggest should be included in your Nim installation already, though |
| 05:01:48 | * | absolutejam joined #nim |
| 05:08:06 | FromGitter | <rtnlmeme-DestroyerOfDeath> @leorize yea, the output of `nimsuggest --version` is ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d2d5bb53be99c47865af952] |
| 05:12:58 | rayman22201 | ughh. I think this is a "nim doesn't have vtables" problem :/ |
| 05:23:20 | Zevv | rayman22201: here a bit |
| 05:23:59 | rayman22201 | let me show you an example and see what you thing. give me 2 minutes |
| 05:24:28 | Zevv | give me two hours, need to do morning chores and commute first :) |
| 05:24:40 | rayman22201 | lol. I will be asleep then :-P |
| 05:24:47 | Zevv | but it sounds like that problem indeed |
| 05:24:57 | rayman22201 | but I will post an example for you to think about |
| 05:24:59 | Zevv | where's doms discussion about that, I think i missed it |
| 05:25:10 | Zevv | https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ |
| 05:27:26 | * | brakmic__ quit () |
| 05:27:44 | rayman22201 | Dom saying good ideas: https://irclogs.nim-lang.org/14-07-2019.html#15:45:42 |
| 05:27:47 | * | brakmic joined #nim |
| 05:29:15 | rayman22201 | I skimmed the D article earlier today. It's interesting. It feels similar to newruntime actually. |
| 05:31:02 | FromGitter | <rtnlmeme-DestroyerOfDeath> fixed my issue btw. It was just an emacs (spacemacs) path issue |
| 05:36:09 | rayman22201 | @Zevv: http://ix.io/1ODd |
| 05:36:18 | rayman22201 | see my comments |
| 05:36:39 | rayman22201 | I guess I could have made it a gist. meh |
| 05:37:05 | rayman22201 | That is from the macro expansion of the async macro |
| 05:37:46 | * | krux02 joined #nim |
| 05:40:45 | * | narimiran joined #nim |
| 05:50:45 | * | yeetcannon quit (Ping timeout: 258 seconds) |
| 06:08:16 | * | solitudesf joined #nim |
| 06:19:40 | * | absolutejam quit (Ping timeout: 244 seconds) |
| 06:20:25 | Zevv | ah right doms idea is one step further, makes perfect sense |
| 06:21:37 | Zevv | oi thats indeed a nasty one, no clue how to get around this rayman22201 |
| 06:23:05 | rayman22201 | vtables fix it :-P |
| 06:23:42 | rayman22201 | I think we might not be able to apply this optimization b/c of this limitation unfortunately |
| 06:30:07 | Zevv | every time I forget about it, it comes back to bite me |
| 06:30:21 | Zevv | or you :) |
| 06:31:26 | Zevv | oh and I was wrong about that event thing losing events in the epoll selector, seems that was intended behaviori |
| 06:31:36 | Zevv | but wrong in all other implementations |
| 06:33:07 | * | actuallybatman left #nim ("ERC (IRC client for Emacs 26.2)") |
| 06:43:22 | rayman22201 | I saw that Araq said something about that, but I don't fully understand the issue. |
| 06:46:24 | skrylar[m] | i did something silly |
| 06:46:41 | * | actuallybatman joined #nim |
| 06:47:05 | skrylar[m] | discovered this `kiwix` program earlier.. offchute of the offline wikipedia stuff, now also does stack exchange and friends. anyway i poked at ripping the nim docs in to it |
| 06:49:33 | skrylar[m] | i suppose that just makes it similar to making a zeal docset. hmmh |
| 06:51:32 | * | jjido joined #nim |
| 06:54:23 | * | absolutejam joined #nim |
| 06:57:47 | rayman22201 | @Zevv: I have a maybe silly idea. The async macro could be made "smarter". It could detect that it is awaiting a flowVar and adjust the iterator return type. |
| 06:58:53 | rayman22201 | But I need to sleep now. gn 😁 |
| 06:59:02 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 06:59:22 | rayman22201 | Good morning to all of you Europeans 😝 |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:04:23 | * | gmpreussner joined #nim |
| 07:07:00 | Zevv | sweet dreams |
| 07:29:11 | * | clyybber joined #nim |
| 07:32:11 | FromGitter | <zacharycarter> well - I got a cube rendering in my project last night \o/ |
| 07:32:28 | FromGitter | <zacharycarter> now to debug the terrain rendering - btw RenderDoc is a pretty awesome program |
| 07:33:46 | Zevv | congrats zacharycarter! |
| 07:34:31 | lqdev[m] | renderdoc just crashes on me when I attempt to open a captured frame |
| 07:34:46 | FromGitter | <zacharycarter> thanks! usually once I have something rendering, I make pretty fast progress |
| 07:34:52 | lqdev[m] | I use apitrace, it fits my needs |
| 07:35:12 | FromGitter | <zacharycarter> getting something to render is the first hurdle |
| 07:35:47 | FromGitter | <zacharycarter> I'm finding it pretty easy this time around to port OpenGL API calls to BGFX API calls |
| 07:36:42 | FromGitter | <zacharycarter> I haven't used API trace before - I did use this Windows debugging program called PIX, which was also nice |
| 07:36:49 | FromGitter | <zacharycarter> but renderdoc works well fo rme |
| 07:37:28 | lqdev[m] | maybe renderdoc crashes because the version in the fedora repos is broken or something |
| 07:47:24 | * | solitudesf quit (Ping timeout: 272 seconds) |
| 07:49:43 | FromGitter | <zacharycarter> possibly |
| 07:52:25 | FromGitter | <zacharycarter> someone in the bgfx channel said it didn't work on mac - so maybe it only works on Windows? I don't know |
| 07:52:47 | FromGitter | <zacharycarter> nevermind - it says it does work on linux x64 |
| 07:53:57 | FromGitter | <arnetheduck> is it possible to create an anonymous tuple with named fields? `(a, b, c)` will create field names `Field0` etc.. |
| 08:00:34 | * | synshroud quit (Ping timeout: 248 seconds) |
| 08:03:35 | * | synshroud joined #nim |
| 08:06:46 | * | floppydh joined #nim |
| 08:11:26 | lqdev[m] | arnetheduck: what's the problem with using [0] etc? |
| 08:12:18 | FromGitter | <arnetheduck> @lqdev the same as identifying you by your location in the list of people in this channel |
| 08:13:34 | lqdev[m] | and why exactly do you need an anonymous tuple? |
| 08:13:54 | * | stefanos82 joined #nim |
| 08:15:05 | lqdev[m] | I don't think having fields named Field0 etc really solves the problem, since you're still specifying the index of the field, just in a different way |
| 08:16:06 | FromGitter | <arnetheduck> for example because they're handy when returning a subset of an object from a helper function: `func importantPart(x: SomeObject): auto = (x.a, x.b)` - it's doable now by spelling out the tuple.. the receiver of that function can the reflect on the tuple names which can be mapped to other name-requiring places, such as json or logs |
| 08:17:23 | lqdev[m] | I see |
| 08:17:39 | FromGitter | <JasperJenkins> what about `func importantPart(x: SomeObject): auto = (f1: x.a, f2: x.b)` ? |
| 08:18:04 | lqdev[m] | why not create a type like `type MyTuple = tuple[field1, field2: int]`? |
| 08:21:48 | leorize | !eval import json; echo %(1, "string) |
| 08:21:51 | leorize | !eval import json; echo %(1, "string") |
| 08:21:52 | NimBot | Compile failed: /usercode/in.nim(1, 24) Error: closing " expected |
| 08:21:55 | NimBot | Compile failed: /usercode/in.nim(1, 19) Error: type mismatch: got <tuple of (int, string)> |
| 08:22:10 | leorize | hmm, thought narimiran added tuple support to json |
| 08:22:15 | * | abm joined #nim |
| 08:22:33 | narimiran | it might have been added then removed later, i don't remember exactly |
| 08:22:52 | leorize | !eval echo (f1: 1, f2: "string") |
| 08:22:57 | NimBot | (f1: 1, f2: "string") |
| 08:23:21 | leorize | @arnetheduck ^ well you can construct named tuples this way |
| 08:23:40 | leorize | or you can actually specify out the field name in the proc signature and do everyone a favor :p |
| 08:28:05 | FromGitter | <arnetheduck> I don't want to repeat the tuple in the signature because it only ever gets used once - like mentioned, it's part of a reflection thing. repeating the names serves only to make it harder to maintain in this situation.. I'm gonna try that above syntax, thanks! (I thought I had tried it and failed, but maybe I mistyped something) |
| 08:37:22 | * | absolutejam quit (Ping timeout: 248 seconds) |
| 08:45:44 | * | absolutejam joined #nim |
| 08:54:58 | * | absolutejam1 quit (Quit: WeeChat 2.5) |
| 09:26:34 | * | Vladar joined #nim |
| 09:28:46 | * | laaron joined #nim |
| 09:30:42 | * | absolutejam quit (Ping timeout: 248 seconds) |
| 09:33:10 | * | actuallybatman quit (Ping timeout: 272 seconds) |
| 09:35:54 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 09:37:37 | * | laaron joined #nim |
| 09:41:22 | * | absolutejam joined #nim |
| 09:42:18 | * | laaron quit (Client Quit) |
| 09:42:38 | * | laaron joined #nim |
| 09:45:22 | * | arecaceae quit (Ping timeout: 246 seconds) |
| 09:52:28 | clyybber | Zevv: I was wrong yesterday actually.. The issue is in the C backend, to fix it in injectdestructors is more of a workaround, since it will generate a '(*value)', while it should actually generate 'value' to be correct |
| 09:52:41 | clyybber | It still works without errors nonetheless for some reason |
| 09:53:04 | clyybber | fixing this correctly will be *fun* :p |
| 09:54:00 | * | laaron- joined #nim |
| 09:54:04 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
| 09:56:17 | Zevv | Fun, as in "its fun to get a stapler to the forehead"? |
| 09:58:43 | * | solitudesf joined #nim |
| 09:59:12 | clyybber | yeah, fun as in https://dwarffortresswiki.org/index.php?title=DF2014:Fun&redirect=no |
| 10:01:46 | Zevv | btw, how come you did pick this whole thing up, instead of Araq doing the implementation? |
| 10:02:33 | Zevv | oh I get the dwarffortress reference now :) |
| 10:14:54 | FromGitter | <akavel> ccccccjkutjuluebljuvticcvrvhdeljfjvurkkgklfi |
| 10:15:04 | FromGitter | <akavel> sorry, that was accidental |
| 10:15:44 | FromGitter | <akavel> Guys, I wanted to ask, what's the status of hot code reloading in the C backend in Nim 0.19? |
| 10:16:20 | FromGitter | <akavel> I expected this to become semi-official with the recent release, but now that I'm searching around, I can't seem to see any mention in the official docs |
| 10:17:19 | FromGitter | <akavel> Sorry, I mean in 0.20 |
| 10:18:14 | FromGitter | <akavel> ahh |
| 10:18:16 | FromGitter | <akavel> ok |
| 10:18:25 | FromGitter | <akavel> Please disregard my question |
| 10:18:35 | FromGitter | <akavel> I mixed things up |
| 10:18:45 | FromGitter | <akavel> Google sent me to 0.19 nimc docs |
| 10:18:47 | Araq | I recently cleaned up its documentation |
| 10:18:56 | Araq | 0.20.2 will have better docs |
| 10:19:15 | FromGitter | <akavel> and I somehow had in mind that 0.19 is the recently released version, while now I see it's 0.20 |
| 10:19:18 | FromGitter | <arnetheduck> errr, so what's the https://github.com/nim-lang/Nim/blob/devel/lib/std/ folder for again? I see `editdistance`, variable length integers and new clock in there, and having trouble err... correlating them all conceptually |
| 10:19:27 | FromGitter | <akavel> and the 0.20 docs *do* have some info. |
| 10:19:41 | FromGitter | <akavel> I was just looking at the 0.19 docs and that led to confusion :( |
| 10:20:11 | Araq | arnetheduck: new stdlib modules go into there |
| 10:20:18 | FromGitter | <akavel> Gee, when Google leads you astray it's like with GPS leading you astray... |
| 10:21:14 | FromGitter | <akavel> You realize how much you got used to it, how amazingly well it usually works, yet how it's not perfect... |
| 10:21:54 | FromGitter | <zacharycarter> Zevv: I remember you saying recently that you may have figured out what was causing: https://github.com/nim-lang/Nim/issues/11718 - should I update the issue with what you found? |
| 10:21:59 | FromGitter | <zacharycarter> I can search through IRC logs to find your message |
| 10:22:21 | FromGitter | <zacharycarter> I just want to ensure that you're comfortable / sure that you think it's the cause of the issue, or at least a breadcrumb to follow |
| 10:22:33 | FromGitter | <arnetheduck> Araq, why? |
| 10:23:30 | Araq | so that 'import std / foo' doesn't clash with 'import foo' (where foo is project specific) |
| 10:24:22 | Araq | the old way of doing 'import stdmodule' is discouraged, it should be 'import std / stdmodule' |
| 10:24:50 | Araq | new modules enforce that by being in std/, the old ones are mapped into std/ so that you can use std/ consistently for every stdlib module |
| 10:25:30 | Araq | there was some RFC about it and a looooong discussion |
| 10:27:57 | FromGitter | <arnetheduck> huh. so wouldn't it be reasonable to expect the same for nimble packages then? ie `import nimblepkg/module`? I mean the problem at the root is the same - once you start using code external to your project, namespacing things becomes pretty much inevitable |
| 10:29:14 | Araq | well yes, that's what nimble enforces |
| 10:29:44 | Araq | the only exception is a single module package so that you don't have to do 'import x / x' |
| 10:30:43 | * | fjellfras quit (Quit: Leaving) |
| 10:30:48 | FromGitter | <arnetheduck> https://github.com/nim-lang/Nim/blob/devel/lib/std/varints.nim looks pretty arbitrary as well - there are many "standard" variable length integer encodings out there, why would a particular one be singled out to be included in a standard lib? |
| 10:31:34 | Araq | that's a good point but the particular implementation is both fast, simple and compatible with sqlite |
| 10:31:48 | Araq | I could have picked a better name though :- |
| 10:31:55 | Zevv | zacharycarter: not at all sure, it was late and I had some beers, but iirc it had to do with a function being declared static so it did not end up as a public symbol in de shared lib. I'd have to look into it again to be sure, though. But feel free to add something like that to the issue of course, as I'm sure it is a problem with run time linker not being able to find a function in a shared lib. |
| 10:33:03 | * | theelous3 joined #nim |
| 10:35:10 | FromGitter | <zacharycarter> okay, cool - thank you |
| 10:35:24 | FromGitter | <arnetheduck> well, it also oddly uses emit for the shifts, so it's not even generally usable (say at compile time) making it kind of unsatisfying and.. nothing special really (not even from a speed perspective).. fwiw, I only looked at it because I needed a varint decoder twice recently, and they both were incompatible with this one (protobuf and dwarf exception handling).. |
| 10:36:09 | FromGitter | <arnetheduck> for the longer term, I think it would be seriously useful to get some guidelines on what goes in std and what doesn't - like a QA mark so you can depend on the code that's in there and hope there are some guarantees surrounding it |
| 10:36:38 | Araq | the emits are because Nim lacked system.ashr back then |
| 10:36:44 | Araq | we can now remove them |
| 10:37:20 | Araq | and well varints does say "experimental" API. |
| 10:38:02 | Araq | if we do 'std / experimental / varints' then it's guaranteed to break, if we start with 'std / varints' it has a chance of not breaking anybody's code |
| 10:38:18 | Araq | individual procs can then be .deprecated: "Use X instead" |
| 10:39:23 | * | absolutejam1 joined #nim |
| 10:41:42 | FromGitter | <arnetheduck> yeah, but from a project perspective, it's a bother to have to follow all that chatter in nim std lib, and inflexible at the same time. the approach in and of itself doesn't scale - even from a PR/review perspective.. |
| 10:41:57 | * | shomodj joined #nim |
| 10:46:04 | Araq | well I know your solution -- "ship Nim without a stdlib" |
| 10:46:05 | FromGitter | <arnetheduck> using varint as an example, it seems it would be nice to have in the std lib the building blocks to build a performant varint implementation - then allow the concrete instances happen in a decentralized way |
| 10:47:05 | FromGitter | <arnetheduck> well, sort of - not without, but with a line drawn |
| 10:50:57 | Araq | well, we're also thinking about "nim cold fusion" which would be a Nim with even more stuff in it |
| 10:51:12 | Araq | Nim + a selected set of packages |
| 10:51:30 | Zevv | and then make a good cleanup of the stdlib. sqlparser, duh |
| 10:51:43 | Araq | but if we had that, we could also make a Nim with only the battle-tested stuff |
| 10:52:28 | Araq | if we have 2 different distributions, we might as well go ahead and make them both useful for the different audiences |
| 10:53:02 | FromGitter | <mratsim> cold fusion? |
| 10:53:13 | Zevv | in practice I guess the only people interested in the smaller distribution would be the compiler developers |
| 10:53:17 | FromGitter | <mratsim> Like the reactors that never get shipped? :p |
| 10:53:20 | FromGitter | <arnetheduck> well, yeah, and that makes a lot of sense, specially coupled with a policy to throw obsolete stuff out.. but it's also about managing responsibilities and maintenance. battle-tested stuff by definition needs less maintenance and causes less problems - has a better usefulness/code ratio |
| 10:53:49 | Araq | mratsim: the joke is like this "what's better than 'batteries included'?" - "Cold fusion." |
| 10:54:12 | * | dddddd joined #nim |
| 10:54:51 | FromGitter | <mratsim> depends, I'm interested in very thin wrappers over system resources to ensure control over memory, threads and allocations |
| 10:55:09 | FromGitter | <alehander42> Good joke |
| 10:55:44 | FromGitter | <alehander42> I think stuff that can run without os eg osdev order bare metal code |
| 10:55:50 | FromGitter | <arnetheduck> if the tooling and ecosystem worked fine, it would be a matter of distributing a list of extra packages to download.. to truly gain the benefits of a more dynamic development process, you'd have to keep an open mind to removing stuff from that cold fusion, or you'll just be bogged down in the same issues, just with less control |
| 10:55:55 | FromGitter | <alehander42> Would also benefit |
| 10:56:32 | Araq | arnetheduck: that doesn't work well for everybody, even assuming a perfect ecosystem. |
| 10:56:47 | Araq | some devs are behind a firewall and can only use the Nim we ship |
| 10:56:50 | Araq | no Nimble packages. |
| 10:58:03 | Araq | and also I don't like it. a web of dependencies is inherently more complex to maintain. |
| 10:59:47 | Araq | and even assuming it works well, Python started with "batteries included" and *then* got the critical mass and *then* could think about trimming it. That's not a co-incidence IMO. The "batteries included" helped Python for a decade even if some libs were bad. |
| 11:01:47 | FromGitter | <arnetheduck> yeah, but times were different then as well. ie py2 was released in year 2000 - aka before `git` |
| 11:02:58 | Araq | sure. and having hardly any stdlib at all worked well for C++ |
| 11:04:42 | Araq | fwiw I eventually switched from Lua to Python because it had a more useful library |
| 11:04:43 | * | Ivo joined #nim |
| 11:05:49 | Araq | Zevv: what's wrong with the sqlparser? |
| 11:06:47 | FromGitter | <arnetheduck> what you need is a distribution mechanism for lots of code - you don't need to be the monolithic distribution mechanism yourself. for the people that need nim behind a firewall, an equally working solution is a tool that vendors code together with their own code, with the massive advantage that it stays local to them, rather than being a burden for everyone |
| 11:08:59 | FromGitter | <arnetheduck> `py3` is moving in the direction of trimming because maybe they learned something along the way, from say.. javascript, which btw, also comes without a (meaningful) std lib |
| 11:09:18 | Araq | I know. |
| 11:09:35 | Araq | Py3 will still ship with e.g. a JSON library |
| 11:09:49 | Araq | and async |
| 11:10:06 | Araq | and os, path handling ... |
| 11:10:47 | Araq | it's not just that Nim's stdlib has modules in it that a stdlib doesn't need. |
| 11:11:05 | Araq | Nim's stdlib also has modules that it needs to have but which are of poor quality. |
| 11:11:42 | * | theelous3 quit (Ping timeout: 245 seconds) |
| 11:12:36 | FromGitter | <zacharycarter> cold fusion reminds me of that adobe product |
| 11:12:38 | FromGitter | <zacharycarter> which is turrible |
| 11:13:00 | Araq | yeah yeah, I know |
| 11:13:06 | Araq | we need a different name |
| 11:13:29 | Zevv | Araq: nothing wrong, just that is it something that should be in the stdlib |
| 11:13:43 | Araq | well no. |
| 11:14:01 | Zevv | we dont have sha256, but we do hav an sql parser :) |
| 11:14:08 | FromGitter | <arnetheduck> Zevv, should or should not? |
| 11:14:19 | Zevv | good question :) |
| 11:14:36 | FromGitter | <mratsim> ORM would be better :P |
| 11:14:56 | FromGitter | <zacharycarter> you could rename the slimmer version of nim to slimnim |
| 11:15:00 | FromGitter | <zacharycarter> and it would almost be slimjim |
| 11:15:07 | Zevv | niminal |
| 11:15:16 | FromGitter | <mratsim> unpronounceable :p |
| 11:15:24 | FromGitter | <zacharycarter> which is a delicious tube shaped meat product |
| 11:15:46 | FromGitter | <mratsim> Earthworm Nim :p |
| 11:16:08 | FromGitter | <zacharycarter> feel like we're getting somewhere |
| 11:16:14 | FromGitter | <mratsim> Sublinimal :p |
| 11:16:16 | Zevv | the other day the idea came up to base it all on nimble - create a recommended-libs metapackage, et voila |
| 11:16:33 | FromGitter | <mratsim> or plain Animal |
| 11:16:42 | FromGitter | <mratsim> Animal, your companion Nim libraries |
| 11:17:16 | FromGitter | <zacharycarter> I guess this is kind of what anaconda is for python? |
| 11:18:07 | FromGitter | <mratsim> anaconda is domain specific |
| 11:18:25 | FromGitter | <mratsim> domain collections make sense |
| 11:22:07 | FromGitter | <mratsim> in any case, the very minimal that should be in the stdlib are things that abstracts OS differences, like IO, locks, networking, ... |
| 11:22:12 | FromGitter | <arnetheduck> well, whatever it's called it would be nice if it addressed some of these scalability problems that happen beyond a certain size - if it's business-as-usual, just with a fancy name and a nice script, it doesn't really improve on the scalability status-quo |
| 11:23:13 | FromGitter | <mratsim> then there is the interface/API layers, some stuff are basic and used in many places and the stdlib should standardize on that: ⏎ ⏎ 1) streams, ⏎ 2) crypto (cough) [https://gitter.im/nim-lang/Nim?at=5d2db3a13596f56f8cea8dc0] |
| 11:23:40 | FromGitter | <mratsim> and then there is the nice to have: ⏎ ⏎ 1) bigints ⏎ 2) actual implementation of crypto [https://gitter.im/nim-lang/Nim?at=5d2db3bc3e2c7e3970951a07] |
| 11:23:48 | FromGitter | <mratsim> (for example) |
| 11:24:22 | FromGitter | <arnetheduck> crypto doesn't *really* need an api specifically.. crypto is no differerent from other forms of compression and data-moving really |
| 11:24:42 | FromGitter | <arnetheduck> a hash is just a lossy zip :) |
| 11:25:21 | FromGitter | <mratsim> the type of your inputs, the order of the argument, the type of the return value |
| 11:26:49 | FromGitter | <mratsim> if a networking lib suddenly needs to interact with some file libraries and they were using the same base hash types, it avoids unnecessary conversion |
| 11:32:21 | Araq | arnetheduck: well but what are these "scalability problems"? the way I see it you want some guarantee that you only end up using modules that are production ready |
| 11:32:38 | Araq | and with a minimal distro that would be addressed. |
| 11:33:08 | * | hohlerde joined #nim |
| 11:34:33 | hohlerde | do I need a full nim installation to use NimScript or is the bin folder sufficient? |
| 11:39:22 | Araq | depends on how you "use" it |
| 11:40:57 | hohlerde | I want to use it as bash/powershell replacement |
| 11:41:22 | Araq | 'nim e myscript.nims' should do the job then |
| 11:41:55 | hohlerde | so the nim binary is all I need? that's cool |
| 11:42:42 | Araq | well the nim binary needs to be able to find the lib/ |
| 11:43:28 | FromGitter | <arnetheduck> well, for one it's about promoting processes that encourage that development happens in parallel rather than in lock-step - you can make that more smooth with good tooling - ie git. batteries included is a crude way of expressing "this code works with that code", but the monolith approach means that "this code must be updated with that code".. take us for example, we can't update to 0.20 because of some random |
| 11:43:28 | FromGitter | ... incompatibilities, even if there are parts of 0.20 that we'd already could and would use, and could have used even before 0.20 was out - this is all well for fast-moving leaf code, but then in the std lib we'd want a stable core that defines the very most basic building blocks from which applications can be constructed ... [https://gitter.im/nim-lang/Nim?at=5d2db85ff4fe94397119fa6b] |
| 11:46:04 | FromGitter | <arnetheduck> the last point is fundamentally incompatible with sticking leaf/feature code in the std lib - the stuff is not "timeless"- it changes every season.. that's why sql is a doomed library - every vendor has their own sql and the thing keeps moving - it's a high-churn project to try to maintain it at a decent level of quality, so now you get something that's a burden on more central pieces of nim being better developed, |
| 11:46:04 | FromGitter | ... and at the same time of "low quality" because there's no reasonable way that it can be maintained in pace - specially since sql is out of fashion |
| 11:46:50 | hohlerde | Araq: true, but overall the footprint on disk is rather low. thanks. |
| 11:49:14 | Araq | arnetheduck: speaking of which. we want to release 0.20.2 this week and it would be nice if NimBus worked with it. |
| 11:49:44 | Araq | what's left to be done to accomplish it? |
| 11:54:57 | Araq | > you can make that more smooth with good tooling - ie git. batteries included is a crude way of expressing "this code works with that code" |
| 11:55:45 | Araq | as long as github allows projects to be deleted and as long as the network is involved, some physical duplication of files makes a hell lot of sense. |
| 11:57:34 | FromGitter | <arnetheduck> fair - that's what vendoring does - copy the code to your repo. even better than a std lib, because it's generally applicable to all your dependencies :) |
| 12:00:36 | Araq | ok, yes. However, there is one more argument for a cold-fusion-nim: it eliminates choice. There would be one obvious websockets implementation to use. The one we ship. |
| 12:01:51 | FromGitter | <mratsim> nimbus should take maybe a day of work to be able to run on 0.20.2 |
| 12:01:55 | FromGitter | <arnetheduck> not too sure what's left on 0.20.x tbh - it should be fairly easy to test since we have the nim version pinned with a git submodule, if you just check out https://github.com/status-im/nimbus/ |
| 12:02:12 | FromGitter | <mratsim> there is the -d:nimOldRightShift that is necessary |
| 12:02:19 | FromGitter | <mratsim> there is this annoying GCSafe: https://github.com/status-im/nim-json-rpc/issues/63 |
| 12:02:54 | FromGitter | <arnetheduck> @mratsim I dunno about that, I remember that we decided to skip it because there were some pretty serious issues, if it was just a few patches it would have been done long ago |
| 12:02:54 | FromGitter | <mratsim> there is one another, small thing iirc. |
| 12:03:20 | FromGitter | <mratsim> ah, then maybe I'm confusing beacon-chain and nimbus |
| 12:09:13 | FromGitter | <arnetheduck> choice, yes. but that's about having a mechanism for curation and saying `we recommend library x` - that's where the curated list of "good" libraries comes in. if I know that `fancy-websockets` is the recommended ws lib out there, let me upgrade it independently of my nim version.. I also believe that a distributed community can work out consensus of the highest quality implementation of a particular topic well |
| 12:09:13 | FromGitter | ... enough on its own - a bad option in the std lib is even likely delay this process |
| 12:16:35 | * | MrAxilus[m] joined #nim |
| 12:17:32 | * | nsf quit (Ping timeout: 258 seconds) |
| 12:19:32 | * | nsf joined #nim |
| 12:23:06 | Araq | well the list of curated libs is what nim-cold-fusion would be, it would bundle the curated libs in a tarball. |
| 12:24:48 | Araq | including the .git subdir, so no history is lost |
| 12:25:04 | Araq | and you can update parts individually if you need to |
| 12:25:15 | FromGitter | <alehander42> i think a cold-fusion thing might be weird, e.g. |
| 12:25:26 | FromGitter | <alehander42> what if you have two differently designed but equally ok orm-s |
| 12:25:39 | FromGitter | <alehander42> or protocol api-s |
| 12:25:39 | FromGitter | <alehander42> etc |
| 12:26:02 | Araq | then better not include it until the market decided which one to prefer |
| 12:26:05 | FromGitter | <alehander42> are they both inside, is just one chosen |
| 12:26:16 | FromGitter | <alehander42> smart |
| 12:26:21 | FromGitter | <alehander42> if its more minimal, makes sense |
| 12:26:32 | FromGitter | <alehander42> but still i agree that its good to have the mechanism |
| 12:26:33 | FromGitter | <alehander42> exposed |
| 12:26:40 | FromGitter | <alehander42> so i can generate my own "distro" |
| 12:26:46 | FromGitter | <alehander42> because the "behind firewall" argument |
| 12:27:12 | FromGitter | <alehander42> is exactly an argument for that: guy in company x might need X and Y packages which are just not inside the cold-fusion |
| 12:27:34 | FromGitter | <alehander42> so he either pushes to have them because of his usecase which is not general enough |
| 12:28:15 | FromGitter | <alehander42> or he can generate their own thing(but on the other hand, if he can download/run that, whats really stopping nimble from working: still not sure) |
| 12:30:24 | Araq | well I don't encourage you to produce your own distro. but nothing stops you from doing that |
| 12:32:23 | Araq | now the only important question is: how to name them? |
| 12:32:30 | FromGitter | <alehander42> (goes and creates nimubuntu) |
| 12:32:38 | Araq | 1. NimBattle and NimFusion |
| 12:32:57 | Araq | 2. NimCore and NimExtended |
| 12:33:14 | FromGitter | <alehander42> why not nimcore and nimfusion |
| 12:33:33 | Araq | sure, or that |
| 12:34:37 | * | solitudesf quit (Ping timeout: 245 seconds) |
| 12:35:37 | dom96 | Araq: seen this? https://news.ycombinator.com/item?id=20441519 |
| 12:35:39 | * | PMunch joined #nim |
| 12:37:56 | Araq | yeah, I read it |
| 12:38:09 | dom96 | Thoughts? |
| 12:38:35 | Araq | it repeats Rust's mistake, the heap is not lexically scoped. |
| 12:38:45 | Araq | but it's a step in the right direction |
| 12:39:35 | dom96 | cool. So I think we should write up a blog post about Nim's new runtime, but only once we're sure it works :) |
| 12:40:05 | Araq | and it's also not clear yet if Rust's way is good enough and we "only" need to educate programmers to embrace it |
| 12:40:28 | Araq | or if it's inherently too limiting for many things. |
| 12:49:43 | dom96 | I think Rust's popularity already disproves this |
| 12:50:58 | * | absolutejam1 quit (Quit: WeeChat 2.5) |
| 12:53:27 | * | laaron- quit (Remote host closed the connection) |
| 12:53:33 | * | laaron joined #nim |
| 12:57:23 | Araq | maybe. I still haven't seen UIs done with Rust's ownership system. |
| 12:57:42 | Araq | you can always use refcounting in Rust to get things done |
| 12:59:33 | FromGitter | <zetashift> There are a few UI toolkits for Rust, but using them ain't that ergonomic |
| 13:01:31 | Araq | when we discuss Rust's ownership system, it's important to focus on the ownership system. Not on what was "written in Rust" or what HN says about Rust. |
| 13:02:21 | Araq | if Rust has an ownership system and people instead use the Arc<T> everywhere in practice, it means the ownership system has failed. |
| 13:02:32 | * | couven92 quit (Quit: Client disconnecting) |
| 13:03:07 | FromGitter | <alehander42> but the question is if its possible to add just 1-2 extensions to it |
| 13:03:15 | * | Senketsu quit (Quit: WeeChat 2.5) |
| 13:03:29 | FromGitter | <kaushalmodi> nimble question: Is there a way to upgrade a nimble package and delete all old versions of that package? |
| 13:03:30 | FromGitter | <alehander42> which are enough to support similar datastructures in 80% of cases |
| 13:03:32 | FromGitter | <alehander42> or not |
| 13:03:59 | FromGitter | <kaushalmodi> right now, I cannot uninstall an old version of a package because 7 other packages depend on it |
| 13:04:24 | FromGitter | <alehander42> without runtime overhead |
| 13:09:36 | Araq | kaushalmodi: you can always 'rm' it, nimble doesn't mind |
| 13:12:00 | FromGitter | <kaushalmodi> I remember nimble getting confused if you rm'd packages |
| 13:12:13 | FromGitter | <kaushalmodi> it messed up some internal symlinks manages by nimble AFAIR |
| 13:12:22 | FromGitter | <kaushalmodi> *managed |
| 13:13:05 | Araq | rm -rf .nimble |
| 13:13:13 | FromGitter | <kaushalmodi> heh |
| 13:15:45 | narimiran | i regularly manually delete packages, and i didn't experience any problem |
| 13:16:52 | FromGitter | <kaushalmodi> ok |
| 13:17:03 | FromGitter | <kaushalmodi> I'll try that out |
| 13:17:21 | Zevv | kaushalmodi: maybe for 'nim develop' packages? |
| 13:18:13 | FromGitter | <kaushalmodi> you mean 'nimble develop', but yes, I should consider that. |
| 13:34:44 | FromGitter | <kaushalmodi> I am now adding this to my `config.nims`: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Currently the stdlib packages are gating me from using `-d:strictMode` in my compilations. [https://gitter.im/nim-lang/Nim?at=5d2dd2743b41924785ccd517] |
| 13:36:48 | Araq | what's -d:strictMode ? |
| 13:37:07 | Araq | nv |
| 13:37:12 | Araq | I can see it on gitter |
| 13:54:23 | * | xet7 quit (Quit: Leaving) |
| 13:57:54 | * | clyybber quit (Ping timeout: 272 seconds) |
| 13:58:42 | * | xet7 joined #nim |
| 14:04:33 | leorize | Araq: https://github.com/nim-lang/Nim/pull/11751 <- the issue you're fixing is #11747 not #11474 |
| 14:05:03 | Araq | lol |
| 14:17:11 | FromGitter | <wsdjeg> hello, any one use vim as default editor of nim programming language? |
| 14:17:20 | narimiran | couple of us |
| 14:17:46 | FromGitter | <wsdjeg> which nim snippets do you use? |
| 14:17:51 | narimiran | well, some of us use neovim, because of the great plugin by leorize, but you have some stubborn vim users too :) |
| 14:18:16 | PMunch | I use Vim |
| 14:18:17 | FromGitter | <wsdjeg> I am author of spacevim, I use lang#nim layer |
| 14:18:30 | PMunch | With the LSP plugin and the nimlsp server |
| 14:18:34 | narimiran | oh, then we spoke on telegram before, i think |
| 14:18:45 | Cadey | is niminst deprecated? |
| 14:19:51 | Cadey | ah it got moved to the main nim repo |
| 14:20:00 | Cadey | it should be removed from the nimble packages list |
| 14:20:25 | Araq | well yes. the nimble package is for others, the one in the main repo only for Nim itself |
| 14:20:35 | Cadey | it doesn't build anymore |
| 14:20:42 | FromGitter | <wsdjeg> what is a mose use language spesific feature when edit nim code in vim? |
| 14:22:02 | FromGitter | <wsdjeg> I hope sameone can help maintain the lang#nim layer, in current version, code runner and repl are supported, of cause syntax highlight and indent is supported. |
| 14:23:38 | shashlick | cool to hear 0.20.2 is already on its way, it's been only a month since 0.20.0 tho |
| 14:23:56 | FromGitter | <wsdjeg> the layer page is https://spacevim.org/layers/lang/nim/ |
| 14:24:22 | shashlick | anyway, @Araq - I made a c2nim PR that gets it working with 0.19.x - https://github.com/nim-lang/c2nim/pull/172 |
| 14:24:41 | * | brakmic quit (Remote host closed the connection) |
| 14:25:23 | FromGitter | <alehander42> The |
| 14:25:28 | * | brakmic joined #nim |
| 14:26:40 | * | absolutejam quit (Read error: Connection reset by peer) |
| 14:26:50 | Zevv | wsdjeg: can the nim stuff be isolated from the rest of spacevim? I like my vim pretty bare bones |
| 14:27:08 | Zevv | or is that against the philosophy of spacevim |
| 14:27:13 | * | absolutejam joined #nim |
| 14:28:40 | leorize | here's spacevim nim layer :p https://github.com/wsdjeg/vim-nim |
| 14:32:09 | leorize | looks like it's a nvim-nim fork |
| 14:44:25 | * | vlad1777d joined #nim |
| 14:48:08 | FromGitter | <brentp> I have a nim wrapper of a c library. then ABI and API of the c library is changing. Is the best way to handle this (with backwards compatibility) to have 2 separate branches? or anyone have an example of something like this? |
| 14:50:42 | * | lritter joined #nim |
| 14:51:58 | Araq | the best way then is to wrap via .header |
| 14:52:18 | Araq | so that the C compiler hopefully can detect errors and changes |
| 14:52:39 | Araq | better to compile it via C++ though, C type checking is broken beyond repair. |
| 15:00:44 | * | jmiven quit (Remote host closed the connection) |
| 15:01:25 | * | jmiven joined #nim |
| 15:01:34 | FromGitter | <brentp> you mean instead of using dynlib? the code in question is here: https://github.com/brentp/hts-nim/blob/master/src/hts/private/hts_concat.nim |
| 15:02:07 | FromGitter | <brentp> and you mean to distribute the C code with my lib? |
| 15:03:34 | disruptek | `niminal`. i love it. |
| 15:05:32 | disruptek | so, near as i can tell, the aws generated api `awsome` doesn't actually implement making calls or parsing results. everything else, sure, but not that. |
| 15:05:40 | * | absolutejam quit (Ping timeout: 272 seconds) |
| 15:05:48 | narimiran | Zevv: spacevim and 'bare bones' don't really go together ;) |
| 15:09:02 | Araq | brentp: I'm not sure. I think I do. |
| 15:20:53 | * | abm quit (Ping timeout: 245 seconds) |
| 15:27:05 | * | PMunch quit (Ping timeout: 268 seconds) |
| 15:27:24 | * | PMunch joined #nim |
| 15:31:58 | * | nsf quit (Quit: WeeChat 2.4) |
| 15:32:01 | * | solitudesf joined #nim |
| 15:32:50 | * | rockcavera quit (Remote host closed the connection) |
| 15:34:55 | * | rockcavera joined #nim |
| 15:37:09 | * | PMunch quit (Read error: Connection reset by peer) |
| 15:42:17 | FromGitter | <brentp> @Araq, ok. I'll consider it. |
| 15:48:05 | lmariscal | @dom96 opened a PR to fix the git submodules issue https://github.com/nim-lang/nimble/pull/677 |
| 15:48:12 | rayman22201 | @Araq, @dom96, did you guys see my ping or chat with @Zevv earlier today? Any thoughts? |
| 15:48:14 | lmariscal | waiting for the CI |
| 15:48:25 | dom96 | rayman22201 nope, link? |
| 15:48:37 | dom96 | lmariscal thanks, I'll try to review tonight |
| 15:49:27 | rayman22201 | https://irclogs.nim-lang.org/16-07-2019.html#04:57:35 |
| 15:51:08 | rayman22201 | Specifically this: http://ix.io/1ODd |
| 15:51:42 | * | PMunch joined #nim |
| 15:51:44 | dom96 | wat, async event losing events is expected behaviour? Zevv? |
| 15:52:21 | dom96 | yeah, we'd need to make `callback=` a method :/ |
| 15:52:49 | dom96 | hmmm |
| 15:53:44 | dom96 | That really sucks |
| 15:53:51 | dom96 | There must be a way to work around this though |
| 15:54:03 | dom96 | Araq should have some ideas |
| 15:54:43 | Araq | I don't understand why it's necessary |
| 15:55:43 | dom96 | One idea: inject `if next552035 of FlowVarBase: next552035.initAsyncEvent` |
| 15:55:56 | rayman22201 | It allows us to optimize flowVar so that it only creates an async event when you are actually using async. If are doing spawn without async, why waste an FD? |
| 15:55:59 | Araq | lazy init of AsyncEvent seems to be a terrible idea anyway |
| 15:56:08 | dom96 | but no, that won't work if someone doesn't want to use the async macro |
| 15:56:29 | dom96 | rayman22201 explains it perfectly |
| 15:57:29 | Araq | so write an AsyncEvent that is not based on a FD. |
| 15:57:49 | Araq | in other words |
| 15:58:02 | Araq | use a single AsyncEvent + a unique ID |
| 15:58:14 | rayman22201 | Zevv is doing that too in parallel to me |
| 15:58:26 | Araq | and then check for this ID, only if equal, it's a trigger you cared about |
| 15:58:47 | dom96 | It's still an extra allocation which sucks |
| 15:59:05 | Araq | it's a couple of integers, I don't see an allocation |
| 15:59:20 | dom96 | AsyncEvent is a ref, no? |
| 15:59:47 | Araq | I don't know. if it is, cache it in a .threadvar |
| 15:59:58 | * | salewski joined #nim |
| 16:00:18 | rayman22201 | It's not that terrible, just seemed like a nice optimization. |
| 16:00:29 | Araq | lazy init for events seems to be a very bad idea for reliability |
| 16:00:53 | rayman22201 | We will be fine without it. The better asyncEvent from @Zevv is much more important. |
| 16:01:50 | dom96 | conceptually it makes more sense to init the async event when the FlowVar is awaited IMO |
| 16:01:59 | dom96 | I don't understand what reliability problems this can introduce |
| 16:03:49 | * | laaron quit (Remote host closed the connection) |
| 16:05:24 | Araq | when the FlowVar is awaited it might have been completed already, it's racy |
| 16:05:26 | salewski | Do we have any hint for this guy? https://github.com/StefanSalewski/gintro/issues/51 |
| 16:05:34 | salewski | All these table impl error? |
| 16:05:41 | salewski | And Dom, do you know the nimble command to install older package version? Seems he does not know, me two. |
| 16:05:48 | salewski | nimble install gintro@"= v0.5.1" or nimble install gintro@"= 0.5.1" or nimble install gintro@"v0.5.1" |
| 16:05:54 | salewski | Over. |
| 16:06:35 | * | laaron joined #nim |
| 16:08:16 | Araq | salewski: the table impl errors are meaningless |
| 16:08:29 | salewski | OK, thanks. |
| 16:08:35 | Araq | the first error is what counts, gintro-0.5.2/gintro/gtk.nim(49761, 23) Error: undeclared identifier: 'DBusProxyClass00' |
| 16:08:58 | salewski | OK. |
| 16:09:05 | Araq | btw ... line 49761 ? |
| 16:09:38 | salewski | Yes, that is the generated gtk.nim file. I have this symbol not :-( |
| 16:10:16 | salewski | He has a different gtk version, but he should also not have it. |
| 16:10:26 | Araq | why generate it at install time? I c2nim'ed gtk2 and lived with the result :P |
| 16:10:45 | salewski | So I suggested installing older version of gintro, but can not tell him exactly how to do. |
| 16:11:43 | salewski | We have discussed thatlong time ago, is because all the various versions. Is similar to the shashlick, |
| 16:12:00 | salewski | you have discussed it with him, about his tools. |
| 16:12:08 | Araq | yes. indeed. |
| 16:12:15 | salewski | nimteropt I think. |
| 16:12:53 | salewski | Later I may provide ready made files, but on the fly generation for nimble install |
| 16:13:22 | Araq | nimteropt has very good CI coverage so I had to shut up about it. |
| 16:13:29 | salewski | generally works fine. We would need various gtk versions, 32/64 bit, win, mac, linux. |
| 16:13:50 | rayman22201 | Good point about the race conditions @Araq. That can be accounted for, but it seems like it's easier just to leave the asyncEvent in the constructor |
| 16:13:53 | salewski | This gue is the only one with problems, ... |
| 16:14:22 | Araq | the idea itself remains terrible IMO. So now everything depends on the local machine's setup. |
| 16:14:37 | narimiran | salewski: `nimble install pkgname@tag` |
| 16:14:59 | Araq | and then all you can do is "shrug, works on my machine" |
| 16:15:30 | salewski | narimmiran, thanks. will try myself and tell him. |
| 16:16:31 | Araq | "various gtk versions, 32/64 bit, win, mac, linux" -- well guess what, if you truly support all these combinations, you gotta test for them. |
| 16:16:38 | salewski | Yes, maybe I can send him a ready made file. Have suggested using another GUI package already. |
| 16:16:48 | salewski | Bye. |
| 16:16:50 | Araq | bye |
| 16:16:52 | * | salewski quit (Quit: WeeChat 2.4) |
| 16:20:55 | shashlick | @salewski - are you looking to generate wrappers? |
| 16:25:24 | * | salewski joined #nim |
| 16:26:08 | salewski | shashlick, you know i made the gintro package, the gobject-introspection based packages |
| 16:26:43 | salewski | for all that gtk related modules, high level. And before I made oldgtk with c2nim. |
| 16:27:15 | salewski | I know you were talking about making one yourself, good look. Hope it will be high level and will work |
| 16:27:27 | salewski | with new runtime fine! :-) |
| 16:27:49 | shashlick | naah, i've been stuck in c2nim/nimgen/nimterop world |
| 16:27:57 | shashlick | enabling people to build wrappers |
| 16:28:18 | shashlick | rather building wrappers that i don't use myself 🙂 |
| 16:29:17 | salewski | But maybe better make a Qt one, seems to be more popular. I know you are fast, but it is work for you for a few yeras fulltime. :-) |
| 16:29:26 | salewski | Bye. |
| 16:29:52 | shashlick | 👍 |
| 16:30:16 | * | salewski quit (Quit: WeeChat 2.4) |
| 16:32:24 | disruptek | Araq: so why not `return`? |
| 16:32:41 | disruptek | you seemed to be suggesting that you prefer not to. |
| 16:35:40 | AlexMax | w/ 12 |
| 16:39:00 | shashlick | @Araq - `nim doc` doesn't populate currentSourcePath - is this a bug that can be fixed? |
| 16:39:02 | * | theelous3 joined #nim |
| 16:39:43 | dom96 | > when the FlowVar is awaited it might have been completed already, it's racy |
| 16:39:44 | dom96 | Araq: that's something we have to check anyway |
| 16:40:21 | dom96 | When setting the callback, if the FlowVar is already complete then we just call the callback immediately |
| 16:40:34 | dom96 | No need for the AsyncEvent in that case either |
| 16:46:30 | * | sniffdtek quit (Remote host closed the connection) |
| 16:46:43 | * | theelous3 quit (Ping timeout: 245 seconds) |
| 16:46:44 | * | sniffdtek joined #nim |
| 16:52:58 | rayman22201 | That's not what we do currently. We create both the asyncEvent and set the callback in the constructor. Before the spawn ever starts. No race condition, and no need to check for completion. If the spawn completes immediately, it just immediately calls the asyncEvent.trigger, which was guaranteed to already exist. |
| 16:54:13 | * | nsf joined #nim |
| 16:55:34 | * | PMunch quit (Remote host closed the connection) |
| 16:56:16 | rayman22201 | The flowVar checks for immediate completion, just like Futures do, but we don't have to modify any of that code. By setting up the asyncEvent in the constructor, we get all that machinery for free. It all just works tm. |
| 16:57:55 | rayman22201 | We can do the optimization. But the complexity of the code change goes way up. |
| 16:59:54 | rayman22201 | This is on top of fixing the loss of type info bug, by either making the callback setter a method or modifying the async macro |
| 17:00:09 | rayman22201 | Is the extra complexity worth it? |
| 17:00:37 | Araq | btw I hate to be that guy but ... 90% of the effort comes after the initial implementation. |
| 17:01:13 | Araq | once spawn "works with" async, you need to add tests and ensure they are green on all the supported platforms |
| 17:01:21 | rayman22201 | Agreed. |
| 17:01:56 | rayman22201 | I was willing to do the optimization if it was easy. But it's obvious not so easy, so I no longer think it's worth it. |
| 17:02:14 | Araq | and you need to be able to debug this. (Which is why I'm so excited about the new runtime.) |
| 17:03:01 | * | abm joined #nim |
| 17:03:08 | dom96 | Sure. I agree that the complexity has gone too far |
| 17:03:15 | * | xace quit (Read error: Connection reset by peer) |
| 17:03:17 | dom96 | Let's fix it by fixing async events |
| 17:03:52 | rayman22201 | Yay. Go @Zevv, save the day 😝 |
| 17:08:16 | * | UNIcodeX joined #nim |
| 17:12:30 | * | absolutejam joined #nim |
| 17:13:30 | * | Trustable joined #nim |
| 17:15:43 | Zevv | sup? |
| 17:16:43 | Zevv | btw I closed the event PR, but actually I do not agree: there is a significant different behaviour between platforms, which I think is not acceptable |
| 17:17:11 | Zevv | whatever the initial semantics of the design, this is just broken and leads to surprises |
| 17:24:43 | dom96 | of course |
| 17:24:50 | dom96 | Why is losing events acceptable though? |
| 17:25:00 | dom96 | If anything your change makes most sense to me |
| 17:26:10 | dom96 | Perhaps I misunderstand what you mean by "losing events" |
| 17:26:25 | dom96 | s/losing/dropped/ |
| 17:26:42 | * | absolutejam quit (Ping timeout: 245 seconds) |
| 17:33:30 | Zevv | i have been told thats the semantics of events, and my fix makes it into a semaphore - which is the exact behaviour of the other platforms |
| 17:39:19 | * | floppydh quit (Quit: WeeChat 2.5) |
| 17:44:30 | * | absolutejam joined #nim |
| 17:45:57 | * | actuallybatman joined #nim |
| 17:50:59 | * | Trustable quit (Remote host closed the connection) |
| 18:02:21 | FromGitter | <Obround> Is there something like python's exec statement in nim? |
| 18:02:33 | * | vlad1777d quit (Ping timeout: 245 seconds) |
| 18:09:43 | * | actuallybatman quit (Ping timeout: 246 seconds) |
| 18:09:54 | * | al_ joined #nim |
| 18:26:30 | * | al_ quit (Quit: al_) |
| 18:31:17 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:31:26 | * | stefanos82 quit (Quit: Quitting for now...) |
| 18:45:58 | federico3 | see osproc |
| 18:47:34 | federico3 | ah, no exec() is something else |
| 18:48:29 | * | actuallybatman joined #nim |
| 18:55:30 | * | absolutejam quit (Ping timeout: 248 seconds) |
| 18:57:46 | Araq | Obround: you can import the Nim frontend+VM into your program, see the tcompilerapi test for details |
| 19:09:59 | FromGitter | <Obround> <Araq> -- Thanks, I ran the test and it worked :) The only thing is that I want a simpler api, like a proc that is built into some module; But if not, I think I would be fine with the tcompilerapi test:) |
| 19:10:12 | rayman22201 | the event PR I was referring to was the uniqeID fix @Zevv. The "losing events" thing is separate I thought? |
| 19:20:49 | * | absolutejam joined #nim |
| 19:21:51 | * | laaron quit (Remote host closed the connection) |
| 19:25:47 | Zevv | yes, its separate. But when sending the ID through the pipe in our "fd leak fix" the behaviour changes to match the other impls |
| 19:26:16 | Zevv | each one trigger generates exactly one event. |
| 19:27:50 | FromGitter | <kaushalmodi> added an "fmt" target to my config.nims: https://github.com/kaushalmodi/nim_config/commit/c446fba79677e85d43b7520f98f5e1f05ac6fdd5 |
| 19:27:53 | FromGitter | <kaushalmodi> works pretty well |
| 19:27:55 | FromGitter | <kaushalmodi> :) |
| 19:28:13 | FromGitter | <kaushalmodi> from anywhere in my git repo, I simply need to type "nim fmt" |
| 19:28:49 | * | sniffdtek quit (Remote host closed the connection) |
| 19:29:04 | * | sniffdtek joined #nim |
| 19:30:15 | * | jjido joined #nim |
| 19:35:51 | dom96 | Zevv, can you elaborate on the behaviour currently on Linux vs. as a semaphore? |
| 19:40:57 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:43:50 | * | fjellfras joined #nim |
| 19:45:14 | Zevv | See the snippe in pr#11728: ioselectors have SelectEvents, which you can .trigger(). On the _epoll implementation (linux default) this is implemented using eventfd(), which is basically a kernel-maintained counter. If you do 100 writes to the fd and only then handle the read end, you get only one read() result. (Nim does not use the counter value). The example snippet triggers 100 events, and counts how many |
| 19:45:20 | Zevv | events are received. On linux this is 1, on all other platforms this is 100 |
| 19:46:01 | disruptek | Araq: i hate to say it, but re.match seems to have a bug: it does not populate the var matches: openarray[string] with matches when matches is a seq, though it works fine when it's an array. |
| 19:46:21 | Zevv | cheatfate mentions in the PR that windows also acts like an event, but when I tested the windows version I also got a 100 |
| 19:47:39 | Zevv | I *did* test on wine instead of a real windows, so if anyone with a windows machine could run the snippet in https://github.com/nim-lang/Nim/pull/11728, I'd be interested in the result. |
| 19:47:59 | Zevv | And now I'll leave this for what it is until someone decides what is right and what is wrong |
| 19:49:22 | Zevv | rayman22201: so whats the plan with the async stuff? |
| 19:49:23 | dom96 | I see. In that case this makes sense, for the FlowVar use case this doesn't make a difference |
| 19:49:34 | dom96 | but this needs to be consistent |
| 19:50:05 | dom96 | hrm |
| 19:50:09 | Zevv | dom96: yes but no but yes but: the change rayman22201 and me made up will drop eventfd() and use a pipe on linux as well - changing the behaviour |
| 19:51:07 | dom96 | To be honest this doesn't make sense. I would expect an async event to be "ready" forever as soon as it is triggered once |
| 19:51:40 | dom96 | so I'm not sure your sample makes sense |
| 19:51:54 | Zevv | I'm not saying it makese sense, I'm just saying the behaviour is different and that is wrong |
| 19:51:58 | dom96 | triggering an event more than once should have no effect |
| 19:52:14 | dom96 | sure, but the behaviour you're expecting is wrong too |
| 19:52:14 | Zevv | I don't care if its either one, but it should behave the same on all platforms |
| 19:52:50 | Zevv | My assumption was that epoll was wrong because that differs from select and poll - but that assumption turned out to be wrong, the other two are at fault |
| 19:53:09 | dom96 | but maybe the way I'm thinking about it is wrong too |
| 19:53:19 | rayman22201 | So we fix the other 2? |
| 19:53:23 | dom96 | I find the idea that `select` changes the async event weird |
| 19:53:39 | Zevv | *but*: if we want to send multiple events trough one fd, we need to send the event IDs as data through the pipe. And then you can't coalesce, so one trigger gives one event |
| 19:53:46 | dom96 | the triggered status shouldn't change when the event is selected |
| 19:54:19 | Zevv | If you trigger event 1, 2, 3 and 2 again, there are 4 ints in the pipe, two of which are '2' |
| 19:54:28 | * | yeetcannon joined #nim |
| 19:54:34 | * | cyraxjoe joined #nim |
| 19:54:52 | Zevv | the read and could mitigate this by flushing the whole pipe instead of only one int (As now happens in select and poll), then make a set of all events it found, and after that call the callbacks |
| 19:54:55 | disruptek | yer blowin' my mind right now. |
| 19:55:14 | dom96 | the event numbers should probably be modelled as a set |
| 19:55:25 | rayman22201 | Right. @dom96 we have added a layer of abstraction to asyncEvent. So select is not 1 to 1 with socket reads anymore |
| 19:55:26 | dom96 | we need to come up with a proper API spec for this |
| 19:55:53 | dom96 | rayman22201, not sure what you mean by the last sentence |
| 19:56:24 | rayman22201 | Or I should say, asyncEvent triggers are not 1 to 1 with socket reads. |
| 19:57:19 | dom96 | You're saying that an async event being triggered is not the same as a socket being /readable/? |
| 19:57:38 | FromGitter | <rtnlmeme-DestroyerOfDeath> g |
| 19:58:02 | rayman22201 | 1 socket being readable = potentially many events being triggered |
| 19:58:11 | * | nsf quit (Quit: WeeChat 2.4) |
| 19:58:20 | Zevv | rayman22201: we're not making it any clearer i think :) |
| 19:58:33 | Zevv | dom96: should I elaborate here or should I write something down somewhere else? |
| 19:58:43 | rayman22201 | Damnit lol. I need a brain to brain interface 😝 |
| 19:58:52 | dom96 | if you can do it in a sentence then do it here, otherwise write something :) |
| 19:59:00 | dom96 | *...something somewhere else |
| 19:59:41 | rayman22201 | You are right that the IDs should be a set, but I think a monotonically increasing counter is enough. |
| 19:59:47 | Zevv | ok: we are talking two different issues, 1) the async events causing too many fds. 2) while fixing this, I figured the select events behave differently on the various backends |
| 20:00:30 | Zevv | it seems though that what I though was wrong - as it differed from the majority - seems to be right: N triggers result in only 1 readable-select |
| 20:01:23 | disruptek | that's the point of select. |
| 20:01:40 | dom96 | Okay, then I guess I am talking about a 3rd issue: it's weird that a single select(eventfd)/poll(eventfd)/epoll(eventfd) changes the eventfd's triggered state |
| 20:01:45 | Zevv | the "fix" we came up with for the async events changes this bahaviour - we will now make only one file descriptor, and each trigger gets an unique ID that gets written into the pipe. The read end of the pipe will now get separate data for each trigger. If you send 5 events, you get 5 uint64s in the pipe. |
| 20:02:22 | Zevv | The solution is pretty simple: instead of reading only 1 uint64 when the fd is ready, we read all N uints, put the IDs we find in a set, and when all data is flushed, only then we call the callbacks. |
| 20:02:36 | Zevv | so if event X is triggered Y times, we only call the X callback once |
| 20:03:13 | rayman22201 | +1 |
| 20:03:45 | Zevv | One issue I can think up is that the pipe can get full when too many events are triggered. *BUT* this is already the case with the poll and select implementations since those are wrong anyway. |
| 20:04:00 | dom96 | we don't use poll/select though |
| 20:04:40 | Zevv | elif defined(windows): |
| 20:04:40 | Zevv | include ioselects/ioselectors_select |
| 20:04:49 | rayman22201 | I'm pretty sure we do lol |
| 20:05:02 | dom96 | Why don't you simply use a single AsyncEvent + a set[int], trigger the AsyncEvent and add to the set when an event ID is triggered? |
| 20:05:17 | dom96 | Zevv, rayman22201: the selectors module isn't used on Windows, IOCP is |
| 20:05:28 | dom96 | (the logic for this is in asyncdispatch) |
| 20:05:50 | Zevv | pff ok I missed that one |
| 20:05:54 | dom96 | I mean, I'm sure _someone_ uses the selectors module on Windows, but it's not what backs async await |
| 20:06:15 | rayman22201 | Ok, but on Linux it's epoll. |
| 20:07:01 | Zevv | dom96: so do we send the set over the fd, or make the set shared memory? |
| 20:08:04 | dom96 | Zevv, each thread has its own selector/dispatcher anyway |
| 20:08:15 | dom96 | so you can just put it in the selector or dispatcher |
| 20:08:28 | Zevv | yeah, but it needs to be under a lock |
| 20:08:37 | rayman22201 | But the unique id must be passed across thread boundaries |
| 20:08:47 | dom96 | Why does it? Each thread has its own separate dispatcher |
| 20:08:55 | Zevv | has it? |
| 20:09:05 | dom96 | yes |
| 20:09:09 | Zevv | wtf |
| 20:09:25 | dom96 | That's how threads work in Nim, each thread gets its own heap |
| 20:09:53 | rayman22201 | Yes. But the whole point of spawn is that you need the new thread to communicate it's unique event is finished to the origin thread |
| 20:10:01 | Zevv | yes, but the whole point was that thread A can wait for a flowvar from thread B in A's async selector? |
| 20:10:21 | disruptek | these concepts aren't exclusive, guys. |
| 20:10:39 | Zevv | right! ^ |
| 20:10:53 | rayman22201 | That's exactly what we are saying |
| 20:12:16 | rayman22201 | Idk about @Zevv, but I knew that each thread gets it's own asyncdispatch. |
| 20:12:19 | dom96 | As far as I understand the flowvar gets triggered in the thread which owns the AsyncEvent |
| 20:12:24 | Zevv | I shouldn't be doing this. I decided 10 years ago that I'm not smart enough to do anything with thread or concurrency :( |
| 20:13:07 | rayman22201 | I have faith in you @Zevv |
| 20:13:23 | rayman22201 | @Dom96, really? Interesting. How is that done? |
| 20:13:39 | dom96 | I have no idea :) |
| 20:13:47 | Zevv | yeah of course each thread gets its own asyncdispatch - but a typical use case would be the main app doing async stuff, spawning a thread for some work and then receiving the flowvar from that thread in its async loop, right? |
| 20:13:58 | rayman22201 | correct |
| 20:14:07 | rayman22201 | I know flowVar has a semaphore in it. |
| 20:14:14 | rayman22201 | But the other thread has to trigger the semaphore |
| 20:14:38 | Zevv | So thread B needs to indicate to thread A that an event is ready. If there is also thread C or D, that does not change anything, but all threads need to be able to indicate these events in a set, which is a) in shared memory and under a lock or b) sent over the pipe |
| 20:15:23 | Zevv | if these threads want to do the same dance to the other side, then thread A pokes its event in the set of thread B |
| 20:16:09 | Araq | disruptek: report it properly |
| 20:16:18 | Zevv | so each thread *can* have its own selector. But other threads need to be able to indicate an event. If the individual events can not go over the pipe, we need a sharedSet |
| 20:16:35 | disruptek | Araq: aight. |
| 20:19:43 | rayman22201 | Yeah. I'm with @Zevv here. Using the pipe was a way to have to OS do the synchronization and sharing for us. |
| 20:21:18 | dom96 | I feel like we're still misunderstanding each other |
| 20:21:39 | dom96 | Main thread: let f = spawn foo() # `f` is in "main" thread |
| 20:22:01 | dom96 | await f # you use main thread's dispatcher |
| 20:22:14 | dom96 | `spawn` handles the inter-thread communication for you |
| 20:22:59 | dom96 | Araq will know how that works, but I'm 90% sure the `signal` procedure that rayman22201 modified in his PR will be run in the "Main" thread |
| 20:23:04 | dom96 | (under my example) |
| 20:23:53 | rayman22201 | that's true, but what if you modify your example to have two `spawns`. How will the "Main" thread know which `signal` to trigger? |
| 20:24:00 | Araq | I didn't really follow your discussion, sorry |
| 20:24:16 | FromGitter | <akavel> Hi! I need to emit an extra binary artifact file during *compilation* of my Nim program (from some macros). Seeing that there's `staticRead` and `staticExec`, I thought there would be a *staticWrite* too, but I don't seem to see one. Is there some way I can do that? Or am I approaching this wrong? If so, what should I do instead? |
| 20:24:22 | rayman22201 | Araq even suggested the same solution we are implementing earlier today... |
| 20:24:36 | Araq | however, please give yuriy's threadpool implementation a try |
| 20:24:46 | Araq | it doesn't use magics and is much easier to hack |
| 20:25:06 | Araq | and the stdlib's threadpool is moribund anyway |
| 20:25:53 | dom96 | rayman22201, no idea, but somehow it does, otherwise this wouldn't be GC safe |
| 20:25:58 | Araq | akavel: static: writeFile(...) should work |
| 20:26:13 | shashlick | why does parentDir() not work at compile time? |
| 20:26:20 | dom96 | Araq, how is the `signal` proc triggered for a flowvar? |
| 20:26:24 | FromGitter | <akavel> @Araq: oh, ok, thanks! |
| 20:26:43 | Araq | shashlick: I don't know |
| 20:27:24 | Araq | dom96: iirc the thread calls it when it's done with the given task |
| 20:27:37 | * | sniffdtek quit (Remote host closed the connection) |
| 20:28:01 | dom96 | Araq, yeah, and it calls it outside the spawned thread? right? |
| 20:28:08 | shashlick | Araq: actually, parentDir() works with `nim c` but not with `nim doc` |
| 20:28:11 | dom96 | it calls it from the thread that called `spawn` |
| 20:28:14 | dom96 | right? |
| 20:28:15 | shashlick | at compile time |
| 20:28:40 | * | sniffdtek joined #nim |
| 20:28:46 | Araq | shashlick: strange... maybe 'nim doc' gets some internal setting wrong |
| 20:30:02 | shashlick | okay, so it works with `/` but not with `\` |
| 20:30:34 | Araq | dom96: I don't think so. the thread that is done with the task calls 'signal' |
| 20:30:46 | Araq | or rather nimFlowVarSignal |
| 20:31:13 | FromDiscord_ | <j$> when importing the selectors module I get "../i686-w64-mingw32/bin/ld.exe: cannot find -lws2_32", has anyone run into this before? |
| 20:31:26 | Araq | then triggers the "parent" thread to wake up and to get the result |
| 20:31:52 | Araq | j$: it's a mingw problem, you use the wrong mingw version |
| 20:32:06 | dom96 | If that is the case then I don't understand how rayman22201's PR works |
| 20:32:26 | rayman22201 | yeah, it's the slave that signals, see here: https://github.com/nim-lang/Nim/blob/devel/lib/pure/concurrency/threadpool.nim#L374 |
| 20:32:28 | dom96 | if the FlowVar is in the spawned thread then there is no way the async proc can set a callback on it |
| 20:32:33 | FromDiscord_ | <j$> well Im just using the version that comes with nim |
| 20:33:12 | rayman22201 | The FlowVar is in the main thread, you are correct @dom96. But the slave has to communicate with that main thread to say that it is done. |
| 20:33:51 | * | rayman22201 remembers the social justice warrior "slave" naming scandal a few months ago >.< |
| 20:34:32 | dom96 | https://github.com/nim-lang/Nim/blob/7fac17eb5e3fc4c93093aae141db76025f3fd3b9/lib/pure/concurrency/threadpool.nim#L253 |
| 20:34:42 | dom96 | So this must be executed in the main thread |
| 20:35:07 | dom96 | ergo the async event is triggered in the main thread too |
| 20:35:21 | dom96 | so there is no need to worry about communicating across threads with pipes |
| 20:36:57 | rayman22201 | https://github.com/nim-lang/Nim/blob/9db369063c4d14d775015df8f7490d23603827f3/compiler/spawn.nim#L155 |
| 20:37:08 | rayman22201 | That is just a convenience method to hide the underlying thread communication |
| 20:37:14 | rayman22201 | which is done with a barrier |
| 20:37:25 | dom96 | yes |
| 20:37:31 | dom96 | so the communication is handled for us |
| 20:38:21 | Zevv | sorry ppl, it has been quite a day and I need to get up pretty early tomorrow - I'll leave you guys to it. I guess I'll hear from either of you if my assumptions were wrong here |
| 20:38:28 | Araq | j$ well I don't know. what we ship has been tested extensively on different machines |
| 20:38:29 | Zevv | later |
| 20:38:35 | rayman22201 | ok. sleep well! |
| 20:39:12 | * | narimiran quit (Ping timeout: 245 seconds) |
| 20:39:17 | Araq | I guess you also have some different mingw installation? |
| 20:40:38 | rayman22201 | @Dom96, wait. I might finally understand what you are saying. Instead of keeping the unique ID with the asyncEvent, keep the unique ID with the FlowVar? |
| 20:41:00 | * | shomodj joined #nim |
| 20:41:45 | rayman22201 | am I hot or cold here lol? |
| 20:42:01 | dom96 | warm I guess :) |
| 20:42:09 | rayman22201 | lol |
| 20:42:14 | dom96 | You keep the async event with the flowvar already |
| 20:42:23 | rayman22201 | That will fix FlowVars, but won't fix asyncEvents in general. |
| 20:42:25 | dom96 | so it doesn't matter whether you keep it in async event or in the flowvar |
| 20:42:52 | dom96 | I just don't think you need the pipes |
| 20:42:55 | Araq | as I said, please use the alternative threadpool impl, it's simpler |
| 20:43:04 | Araq | and simple is what you need. |
| 20:43:19 | dom96 | Araq, I think that should be a separate PR |
| 20:43:24 | rayman22201 | ignore FlowVar and threads for a minute. Right now, every newAsyncEvent creates a new fd. |
| 20:43:26 | dom96 | I doubt it'll simplify this case much |
| 20:43:30 | rayman22201 | it's not a thread problem |
| 20:43:34 | dom96 | Yes, I know |
| 20:43:34 | Araq | dom96: I'm not talking about PRs |
| 20:43:45 | Araq | you're doing a valuable experiment |
| 20:43:56 | dom96 | I'm proposing you introduce a single AsyncEvent, store it in the async dispatcher |
| 20:43:56 | Araq | the PRs should come later. |
| 20:44:12 | dom96 | store a set of eventIDs that have been triggered in this one true AsyncEvent |
| 20:44:20 | dom96 | and only create one FD for that one true AsyncEvent |
| 20:44:23 | dom96 | Does that make sense? |
| 20:44:33 | rayman22201 | ah. finally! I see now. ok |
| 20:44:57 | * | sniffdtek quit (Remote host closed the connection) |
| 20:44:58 | rayman22201 | so you have an "internalAsyncEvent" and an externally exposed asyncEvent. |
| 20:45:02 | dom96 | yes |
| 20:45:08 | dom96 | exactly :) |
| 20:45:10 | * | sniffdtek joined #nim |
| 20:45:32 | rayman22201 | when that one "fd" is triggered on select, how do you know which id was actually triggered? |
| 20:45:41 | Araq | don't think about PRs. Make it rocksolid first |
| 20:45:55 | rayman22201 | when the one "internalAsyncEvent" is triggered I mean. |
| 20:46:17 | rayman22201 | since, as you said before, asyncEvents should only ever fire once, and then never change state? |
| 20:46:59 | rayman22201 | If there are many external events for that one internal asyncEvent, then only first event will get through, and the rest will never fire. |
| 20:49:11 | shashlick | Araq - https://github.com/nim-lang/Nim/blob/devel/lib/pure/includes/osseps.nim#L21 is the problem |
| 20:49:22 | shashlick | DirSep and AltSep are both `/` in Nimdoc mode |
| 20:49:33 | shashlick | so `\` is never treated as a path separator in nim doc |
| 20:49:35 | Araq | bah |
| 20:49:37 | * | brakmic quit (Ping timeout: 245 seconds) |
| 20:49:48 | Araq | so nimscript doesn't work with nimdoc |
| 20:50:54 | shashlick | I am trying to generate docs for nimterop wrappers but since i use currentSourcePath.parentDir(), it doesn't work properly |
| 20:51:11 | shashlick | in fact, even ExeExt = "" so nothing works as expected on Windows for nim doc |
| 20:51:38 | dom96 | rayman22201, I'm sure there is a way to track this :) |
| 20:51:47 | rayman22201 | I'm sure there isn't :-P |
| 20:51:54 | rayman22201 | that is why we went the way we did |
| 20:51:56 | shashlick | why is Nimdoc a separate OS category? |
| 20:52:38 | FromGitter | <GULPF> @shashlick so the doc comments don't need to be duplicated I think |
| 20:53:15 | Araq | yes. |
| 20:53:18 | FromGitter | <GULPF> I think there was a PR to fix it, but it was rejected |
| 20:53:39 | Araq | I doubt it. |
| 20:53:57 | Araq | the PR likely had some issues :P |
| 20:54:35 | shashlick | not sure i get it, but how do you propose fixing this? osseps shouldn't be impacted by nimdoc mode |
| 20:55:02 | FromGitter | <GULPF> https://github.com/nim-lang/Nim/pull/10629 |
| 20:55:12 | rayman22201 | the problem is that currently, all the underlying select impls, and asyncdispatch accordingly, assume every event is a unique fd. this can be seen by the fact that the fd is used as the index to access the callbacks. And by the fact that for `event.user` the pipe data is completely ignored. |
| 20:55:21 | dom96 | rayman22201, what makes you so sure? |
| 20:56:14 | dom96 | A naive implementation could be a `lastTriggeredEventIDs` set[int] that is set when an AsyncEvent is triggered |
| 20:56:25 | dom96 | and then you know which events were just triggered |
| 20:57:04 | rayman22201 | wat? |
| 20:57:12 | Araq | GULPF: ok :-) |
| 20:57:38 | rayman22201 | how is `lastTriggeredEventIDs` populated? |
| 20:57:46 | Araq | fair enough. I still like 'const dirSep = selectSep('/', '\\') ## doc comment here' better |
| 20:58:42 | * | solitudesf quit (Ping timeout: 248 seconds) |
| 20:58:47 | dom96 | rayman22201, when the AsyncEvent is triggered |
| 20:59:38 | rayman22201 | actually.... yeah, ok. The trigger event can add it's id to the set. but this seems racy. |
| 21:00:08 | dom96 | okay, so think about how to make it not racy :) |
| 21:01:45 | rayman22201 | hrmmm. |
| 21:02:13 | * | fjellfras quit (Quit: Leaving) |
| 21:03:47 | shashlick | what is selectSep() |
| 21:04:33 | * | brakmic joined #nim |
| 21:05:12 | * | altarrel joined #nim |
| 21:08:00 | * | Jesin quit (Quit: Leaving) |
| 21:10:19 | rayman22201 | ok. so my back of the envelope linearizability calculations (lol) tell me that if we can guarantee the event is always added to the set before the fd write is triggered (single threaded context), no events can be lost. The worst that can happen is a noop select event. And that can be mitigated by batch signaling. |
| 21:11:10 | * | Jesin joined #nim |
| 21:11:42 | * | altarrel quit (Quit: Leaving) |
| 21:11:57 | * | altarrel joined #nim |
| 21:12:03 | rayman22201 | since the main thread always owns the asyncEvent (and can thus be the only thread that ever triggers the event). It should work out ok. |
| 21:12:14 | rayman22201 | You convinced me @Dom96 :-P |
| 21:12:18 | shashlick | okay I see the intention, but this means `nim doc` is basically broken for all OS except posix - all procs that refer to any of these consts will be using the wrong value |
| 21:12:24 | rayman22201 | but now I need to eat lunch. bbl |
| 21:12:42 | dom96 | rayman22201, :D |
| 21:13:24 | Araq | shashlick: fix it? |
| 21:14:56 | shashlick | i'll look into it - looks like no one understood the issue in the thread |
| 21:16:23 | * | altarrel quit (Client Quit) |
| 21:16:38 | * | altarrel joined #nim |
| 21:16:47 | * | altarrel quit (Client Quit) |
| 21:17:10 | * | altarrel joined #nim |
| 21:17:10 | * | altarrel quit (Client Quit) |
| 21:17:40 | * | altarrel joined #nim |
| 21:17:57 | * | altarrel left #nim (#nim) |
| 21:18:08 | * | altarrel_ joined #nim |
| 21:18:14 | disruptek | it works, champ. |
| 21:21:52 | * | jjido joined #nim |
| 21:31:09 | shashlick | https://github.com/nim-lang/Nim/issues/10630 |
| 21:34:40 | * | abm quit (Quit: Leaving) |
| 21:36:11 | * | actuallybatman quit (Quit: leaving) |
| 21:37:47 | * | actuallybatman joined #nim |
| 21:50:46 | * | altarrel joined #nim |
| 21:51:34 | * | altarrel quit (Client Quit) |
| 21:51:51 | * | altarrel joined #nim |
| 22:02:11 | FromGitter | <awr1> https://forum.nim-lang.org/t/5014 |
| 22:02:32 | FromGitter | <awr1> i saw this forum post and don't get what is meant by "reflection support = part" for nim |
| 22:02:55 | FromGitter | <awr1> i don't really see what's missing from reflection in nim |
| 22:05:31 | Araq | well in Java you can construct an object from the type name as a string and then call a method on it etc |
| 22:05:45 | Araq | in Nim you need to build the datastructures to support that |
| 22:05:59 | Araq | so you're on your own, but it's possible |
| 22:06:21 | Araq | thanks to macros. |
| 22:06:59 | * | brakmic quit (Read error: Connection reset by peer) |
| 22:07:29 | * | brakmic joined #nim |
| 22:09:32 | FromGitter | <awr1> i guess but to do that at runtime requires a VM, at which point you have to ask yourself "why" |
| 22:10:00 | disruptek | no. |
| 22:10:00 | FromGitter | <awr1> or some kind of more verbose RTTI |
| 22:10:46 | * | brakmic quit (Read error: Connection reset by peer) |
| 22:10:50 | * | brakmic_ joined #nim |
| 22:11:29 | Araq | yeah, well. most usecases for reflection are workarounds for a missing macro system |
| 22:14:07 | FromGitter | <mratsim> how is dereferencing a typedesc supposed to work, it has no address: https://github.com/nim-lang/Nim/issues/11747 ? |
| 22:14:42 | FromGitter | <awr1> there's no impl for [] on types, but theoretically it would just resolve to the underlying referrent type |
| 22:15:37 | Araq | mratsim: fixed here: https://github.com/nim-lang/Nim/pull/11751 |
| 22:16:09 | FromGitter | <awr1> does `echo sizeof(MyRefType()[])` actually perform an allocation |
| 22:16:16 | Araq | TypeHere[] is still a type |
| 22:16:31 | Araq | so you can use it in sizeof() but not in 'addr', simple. |
| 22:16:44 | Araq | awr1: I think so, yes. |
| 22:16:52 | FromGitter | <awr1> :| |
| 22:17:02 | Araq | but maybe not, lol |
| 22:17:06 | FromGitter | <mratsim> @awr1 you may be able to write that in static |
| 22:17:14 | FromGitter | <mratsim> but I think the VM will complain |
| 22:17:32 | Araq | the VM has sizeof support nowadays |
| 22:17:41 | FromGitter | <mratsim> but not dereferencing |
| 22:17:47 | FromGitter | <mratsim> does it? |
| 22:18:13 | Araq | the VM supports derefs in so far they can be supported |
| 22:18:27 | FromGitter | <awr1> shouldn't this be reflected in the docs too? |
| 22:18:32 | Araq | the VM uses a symbolic representation so bithacks don't work |
| 22:19:18 | * | Vladar quit (Remote host closed the connection) |
| 22:20:17 | FromGitter | <awr1> also @Araq i wanted you to take a look at this |
| 22:20:18 | FromGitter | <awr1> https://github.com/nim-lang/Nim/pull/11742/files |
| 22:20:24 | FromGitter | <awr1> is this too janky or is it okay |
| 22:20:51 | FromGitter | <awr1> it allows us to get away with not having to add another compiler flag (or something like that) |
| 22:24:14 | Araq | I reviewed it |
| 22:25:05 | FromGitter | <awr1> ok thanks |
| 22:26:08 | FromGitter | <kaushalmodi> Any thoughts on this: https://github.com/nim-lang/Nim/issues/11755 ? |
| 22:27:10 | FromGitter | <kaushalmodi> Currently how the if and else, case and of's get nimorettified at different columns makes the code less readable IMO |
| 22:28:01 | Araq | well I agree |
| 22:28:22 | Araq | requires yet another concept to learn for nimpretty |
| 22:28:34 | Araq | *to be learned |
| 22:28:48 | Araq | so don't expect any quick fix |
| 22:29:17 | Araq | workaround, write |
| 22:29:20 | Araq | let x = |
| 22:29:24 | Araq | case cond |
| 22:29:28 | Araq | of ... |
| 22:29:43 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:29:49 | FromGitter | <kaushalmodi> Hmm, nimpretty pulls up the case to the above line |
| 22:30:17 | FromGitter | <kaushalmodi> At least it did that when I had similar with if condition starting from the next line |
| 22:30:31 | FromGitter | <kaushalmodi> But of course, I am not expecting a quick fix. |
| 22:30:35 | Araq | can't try it right now |
| 22:31:09 | FromGitter | <kaushalmodi> Just a collective affirmation if my suggested nimpretty output does make sense |
| 22:31:50 | Araq | actually ... nimpretty could at least say "er, case/if expression, not gonna touch these until I understand them" |
| 22:33:33 | Araq | yay, new version of IUP, http://webserver2.tecgraf.puc-rio.br/iup/ |
| 22:34:33 | Araq | with new words like EXTRAPRESSCOLOR for the dyslexic among us. |
| 22:34:56 | FromGitter | <awr1> does nimpretty do hanging idents on call arguments, e.g. |
| 22:35:49 | FromGitter | <awr1> ```foo(bar, ⏎ baz)``` [https://gitter.im/nim-lang/Nim?at=5d2e51455fa7895c4313a0fe] |
| 22:37:13 | FromGitter | <kaushalmodi> > actually ... nimpretty could at least say "er, case/if expression, not gonna touch these until I understand them" |
| 22:37:18 | FromGitter | <kaushalmodi> That would be great too |
| 22:38:16 | FromGitter | <kaushalmodi> Actually, nim-mode in Emacs does the "right thing" when I hit enter after if condition or in a case expression.. it brings the cursor on the newline at my expected column |
| 22:39:35 | FromGitter | <awr1> yeah i noticed that too |
| 22:40:57 | FromGitter | <awr1> does the nim major mode use something from the python mode? |
| 22:41:13 | * | absolutejam quit (Ping timeout: 258 seconds) |
| 22:41:36 | FromGitter | <kaushalmodi> It's heavily based off python-mode |
| 22:41:55 | FromGitter | <kaushalmodi> If you do a diff between the two, you'll clearly see it. |
| 22:42:49 | FromGitter | <awr1> my only gripe with the emacs mode is the problems it has with nimsuggest |
| 22:43:53 | FromGitter | <kaushalmodi> Yeah, I don't use it |
| 22:44:03 | FromGitter | <kaushalmodi> Hippie-expand FTW |
| 22:44:04 | FromGitter | <awr1> i would use it if it worked |
| 22:44:11 | FromGitter | <awr1> it just crashes emacs |
| 22:49:40 | * | brakmic_ quit () |
| 22:53:11 | FromGitter | <kaushalmodi> When I last tried, it did not crash Emacs, it just hung up |
| 22:53:23 | FromGitter | <kaushalmodi> So you'd need to Ctrl-G out of it |
| 22:53:56 | FromGitter | <kaushalmodi> If Emacs crashes for whatever reason, you should file an Emacs bug report: M-x report-emacs-bug |
| 22:54:14 | disruptek | shashlick: do i have to do anything special to make nimterop cImport() in cpp mode versus c mode? is it enough to `nim cpp something.nim`? |
| 23:03:51 | * | xace joined #nim |
| 23:26:51 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:43:48 | * | altarrel quit (Remote host closed the connection) |
| 23:47:05 | * | sniffdtek quit (Remote host closed the connection) |
| 23:49:58 | * | krux02_ joined #nim |
| 23:52:55 | * | krux02 quit (Ping timeout: 250 seconds) |