| 00:02:25 | shashlick | @federico: looks like nimble directory is broken for subdir packages |
| 00:02:34 | shashlick | @timotheecour: can you give me an easy one to review đ |
| 00:04:38 | FromGitter | <timotheecour> pick from https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Atimotheecour+sort%3Aupdated-desc+is%3Aopen+repo%3Anim-lang%2Fnim :-) |
| 00:04:52 | FromGitter | <timotheecour> maybe https://github.com/nim-lang/Nim/pull/10091/files ? |
| 00:06:08 | FromGitter | <timotheecour> we shouldnât let *green* PRâs unattended like that without review⌠|
| 00:11:48 | Araq | they are not easy to review just because the CIs are green |
| 00:12:18 | Araq | besides, any PR that adds a new TODO starts in the state "meh" |
| 00:12:27 | * | ghost64 quit (Read error: Connection reset by peer) |
| 00:13:28 | Araq | always feels like "if you didn't want to implement it, why would I want to review it" |
| 00:17:08 | * | Notkea quit (Read error: Connection reset by peer) |
| 00:17:30 | * | Notkea joined #nim |
| 00:18:20 | * | ghost64 joined #nim |
| 00:33:22 | FromGitter | <timotheecour> I donât understand that point; I added a `# TODO: consider advancing `currentPos` to end of line to avoid` in https://github.com/nim-lang/Nim/pull/10091/files#diff-977ead791db7457f2732dcd58a876c5bR283 to a piece of code that already existed before that PR |
| 00:35:57 | FromGitter | <timotheecour> the TODO can be addressed in future PRâs, all i did there was document the fact that pre-existing code should be changed; IMO a sufficient condition for a PR to be accepted is if it doesnât make anything worse and makes some things better. |
| 00:36:19 | Araq | yeah, the next time don't write TODO. |
| 00:36:51 | Araq | I don't enjoy looking at code that screams at me |
| 00:37:09 | FromGitter | <timotheecour> what do u suggest instead? I like to be honest about shortcomings in code i see; an alternative is to add a new github issue |
| 00:37:37 | Araq | esp if it screams at me some irrelevant stuff that I'll do when I'm dead |
| 00:37:53 | Araq | instead: Write the comment without that TODO in allcaps |
| 00:38:29 | FromGitter | <timotheecour> so, just 'consider advancing âŚâ ? or âtodo: consider advancing âŚ' ? |
| 00:39:12 | Araq | preferably without the 'todo:' but as long as it doesn't scream it's ok ;-) |
| 00:39:24 | FromGitter | <timotheecour> Ok, will use that in future PR's |
| 00:39:41 | Araq | so ... any idea why _pthread_mutex_firstfit_unlock_slow is in that profile? |
| 00:39:53 | Araq | the compiler doesn't use threading/mutexes |
| 00:40:03 | FromGitter | <timotheecour> (i prefer `todo` since itâs searchable, but wonât put in all CAPS in future) |
| 00:40:12 | Araq | is that because of mmap()'s locks? |
| 00:41:02 | FromGitter | <timotheecour> r u referring to https://github.com/nim-lang/Nim/pull/10124 ? |
| 00:41:05 | Araq | grep for XXX in compiler/. I get 229 matches. |
| 00:41:30 | Araq | --> I never search for these in order to fix them. |
| 00:41:48 | Araq | instead I fix github bugs... |
| 00:42:20 | Araq | still it can be useful when reading the code during a debug session. |
| 00:42:28 | Araq | yeah, #10124 |
| 00:42:51 | FromGitter | <timotheecour> (and i can use XXX instead of todo if u prefer XXX) |
| 00:43:56 | FromGitter | <timotheecour> for `_pthread_mutex_firstfit_unlock_slow` ; Iâd need to use something different from `callgrind_annotate` to get a call graph instead of flat profile to see where it comes from |
| 00:46:14 | Araq | interesting that genericReset still is an issue |
| 00:46:16 | FromGitter | <timotheecour> but ya, the takeaway is that according to valgrind, `genericReset`/`genericResetAux` is the bottleneck by far |
| 00:46:38 | Araq | that's not particularly hard to fix |
| 00:47:16 | * | vlad1777d quit (Ping timeout: 246 seconds) |
| 00:47:36 | FromGitter | <timotheecour> was wondering whether we can cheat and skip init to see whether itâd speed up, to corroborate whether valgrind tells truth about it being bottleneck |
| 00:50:25 | Araq | sempass2.addTag is also expensive |
| 00:53:08 | FromGitter | <timotheecour> still need a grain of salt when interpreting results as to how well IR maps to wall time/user time in practice (but I suspect it does more so than `nim âprofiler:on` |
| 00:53:10 | FromGitter | <timotheecour> ) |
| 01:04:59 | Araq | depends on the question. --profiler:on is the best concept because it gives you a reason. what's the context of these genericReset() calls |
| 01:10:19 | * | thomasross_ joined #nim |
| 01:10:20 | * | thomasross is now known as Guest3415 |
| 01:10:20 | * | Guest3415 quit (Killed (tolkien.freenode.net (Nickname regained by services))) |
| 01:10:20 | * | thomasross_ is now known as thomasross |
| 01:11:21 | FromGitter | <timotheecour> Iâve commented on this aspect in https://github.com/nim-lang/Nim/issues/10121#issue-394748797 ; indeed it depends on the question and both callgraph and stacktrace are useful (if callgraph isnât enough), but thatâs assuming sampling strategy used in `âprofiler:on`is accurate, which we could check by comparing against valgrind + other profiler (especially sampling based on INTERRUPT instead of based on for |
| 01:11:21 | FromGitter | ... loop as done in nimprof0 |
| 01:11:23 | * | thomasross quit (Max SendQ exceeded) |
| 01:11:55 | * | thomasross joined #nim |
| 01:13:12 | * | thomasross quit (Max SendQ exceeded) |
| 01:13:41 | * | thomasross joined #nim |
| 01:15:22 | Araq | sampling is the only thing that works for profiling. profiling is not benchmarking. |
| 01:16:11 | Araq | you can benchmark different solutions after the profiling step, the profiling is to give you the dominating stack trace(s) |
| 01:16:31 | FromGitter | <timotheecour> but sampling via interrupt (as done in gprof IIRC and OSX shark profiler) is different from sampling every X loop (as done in nimprof IIUC) |
| 01:17:20 | FromGitter | <timotheecour> the latter can introduce bias, and skew results |
| 01:17:39 | Araq | true |
| 01:27:57 | FromGitter | <timotheecour> thx for the merges |
| 01:30:14 | shashlick | have there been any changes in typetraits? |
| 01:31:22 | Araq | yeah |
| 01:31:26 | shashlick | https://github.com/c-blake/cligen/issues/84 |
| 01:33:22 | Araq | timotheecour will fix it |
| 01:35:58 | shashlick | so cligen doesn't need to change? |
| 01:40:55 | Araq | nah |
| 01:41:59 | Araq | for the protocol: I said $ for typedesc is terrible. |
| 01:59:45 | * | Ven`` quit (Read error: Connection reset by peer) |
| 02:05:16 | * | thomasross quit (Killed (orwell.freenode.net (Nickname regained by services))) |
| 02:05:22 | * | thomasross joined #nim |
| 02:06:32 | * | thomasross quit (Max SendQ exceeded) |
| 02:08:24 | * | thomasross joined #nim |
| 02:53:44 | * | Tyresc quit (Quit: WeeChat 2.4-dev) |
| 03:00:35 | * | banc quit (Quit: Bye) |
| 03:13:39 | FromGitter | <timotheecour> @araq should i do a PR to revert it until a better fix is available so it doesnât block other ppl in meantime? I tried a few things (eg "export system.`$`â) but they fail with `Error: unknown trait` |
| 03:16:20 | * | banc joined #nim |
| 03:20:49 | * | zachk quit (Quit: Leaving) |
| 03:27:39 | FromGitter | <timotheecour> nevermind, seems to work, see https://github.com/nim-lang/Nim/pull/10131 (added a test case and verified that `nimble build` works in nimterop) |
| 04:26:00 | * | Cthalupa quit (Ping timeout: 250 seconds) |
| 04:27:07 | * | Cthalupa joined #nim |
| 05:08:15 | * | kapil____ joined #nim |
| 06:07:46 | shashlick | gosh can someone create a command line nim help viewer already |
| 06:11:31 | * | nsf joined #nim |
| 06:50:26 | * | dddddd quit (Remote host closed the connection) |
| 06:57:05 | * | narimiran joined #nim |
| 06:57:40 | FromGitter | <Varriount> Araq: How complete are the implementations for the sink, etc. mechanics? |
| 07:09:12 | FromDiscord_ | <exelotl> It's so darn good having there be no such thing as nil for strings and seqs |
| 07:18:27 | leorize | shashlick: nim --fullhelp | less ? |
| 07:26:22 | * | vlad1777d joined #nim |
| 08:39:01 | Araq | Varriount: 85% done, biggest problem is that --gc:destructors doesn't work yet. builtin strings and seqs are hard |
| 08:40:06 | FromGitter | <timotheecour> @araq https://github.com/nim-lang/Nim/pull/10131 |
| 08:40:23 | FromGitter | <timotheecour> (fixes regression) |
| 08:40:30 | FromGitter | <timotheecour> thx |
| 08:41:21 | Araq | good to see it was just a scoping issue |
| 08:41:38 | FromGitter | <timotheecour> ya... |
| 08:51:44 | FromGitter | <timotheecour> also https://github.com/nim-lang/Nim/pull/10119 (it was passing before i just made change to s/TODO/todo/) ; iâm trying to compare nim profiling results using 3 methods: â nimprof â Callgrind â OSX instruments (which uses sampling, unlike call grind; and unlike nimprof, the sample is interrupt based, so potentially more precise) [https://gitter.im/nim-lang/Nim?at=5c2887208dafa715c714ec00] |
| 08:52:46 | FromGitter | <timotheecour> so far OSX instruments agrees with callgrind |
| 09:00:37 | FromGitter | <timotheecour> > *<Araq>* so ... any idea why *pthread*mutex_firstfit_unlock_slow is in that profile? â â see https://github.com/nim-lang/Nim/issues/10132#issue-394857127 ; the call graph visualization shows where it comes from |
| 09:02:01 | * | stefanos82 joined #nim |
| 09:02:10 | Araq | that's not a call graph |
| 09:02:31 | Araq | genericReset never calls any Marker_tyRef_* variant |
| 09:02:49 | Araq | and markers never call IO |
| 09:24:05 | narimiran | Araq: github now has the feature to move issues to another repo â should we use that to move RFCs to a separate repo? (we tried it before manually, when there wasn't a built-in way to do it) |
| 09:25:30 | Araq | the RFC model as we have it today doesn't work well but we should move to a PEP-like process IMHO. |
| 09:26:01 | Araq | so ... don't write the RFC in github's editor, submit a markdown/RST document |
| 09:26:47 | narimiran | ..and have some kind of a template for it? (RFC has to have several sections, etc.) |
| 09:27:11 | Araq | otherwise we have the situation as today "Ok, I updated the issues, please read it again..." |
| 09:27:19 | narimiran | what about the existing RFCs? |
| 09:28:20 | Araq | I'm not a fan of document templates but it seems to work for Python |
| 09:34:10 | Araq | can we migrate the existing RFCs to markdown documents? |
| 09:36:08 | FromGitter | <zacharycarter> https://github.com/mattduck/gh2md |
| 09:36:13 | FromGitter | <zacharycarter> might be handy for ^ ? |
| 09:55:07 | * | hoijui joined #nim |
| 10:08:33 | FromGitter | <timotheecour> > that's not a call graph â â well I think itâs a call graph, but thereâs indeed something add about `genericReset` never calls any `MarkertyRef*` ; it seems mostly correct apart from oddity like this, and still is useful; could be a valgrind bug which iâll try to report; added more details + text-version of call graph here: https://github.com/nim-lang/Nim/issues/10132#issue-394857127 |
| 10:16:36 | FromGitter | <timotheecour> @araq ok so nimprof doesnât reveal actual important bottlenecks such as zeroMem which confirms my suspicion that itâs biased since it only looks at nim loops and doesnât use interrupts, so totally misses memset + friends => see https://github.com/nim-lang/Nim/issues/10132#issuecomment-450550921 |
| 10:19:27 | Araq | nimprof is awesome |
| 10:19:56 | Araq | initIntSet causes the genericReset |
| 10:20:28 | Araq | and matches calls initIntSet, probably could reuse the int set |
| 10:22:39 | Araq | we need a test for nimprof though to keep it from bit rotting |
| 10:25:16 | FromGitter | <timotheecour> but nimprof could sample differently, right? say another process that queries for a stacktrace every x millisecs |
| 10:25:23 | * | vlad1777d quit (Ping timeout: 268 seconds) |
| 10:25:55 | * | hoijui quit (Ping timeout: 268 seconds) |
| 10:27:04 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 10:31:49 | Araq | sure but it screams "unreliable" to me |
| 10:33:51 | Araq | signal handlers and the eternal question of signal handler safety |
| 10:34:52 | FromGitter | <timotheecour> well thatâs how sampling profilers work IIUC; in any case itâs not same as ârecovering from segfault inside a signal handlerâ, the state is well defined |
| 10:36:28 | Araq | things you can do in a signal handler: set a global flag that you probe outside of the signal handler. nothing else. |
| 10:36:49 | Araq | you can then inject code to poll this flag everywhere. |
| 10:36:58 | Araq | which is what nimprof already does |
| 10:37:10 | Araq | --> causes the same biases |
| 10:37:19 | * | hoijui joined #nim |
| 10:37:33 | Araq | well ok, not really because then it's timing based |
| 10:39:09 | FromGitter | <timotheecour> Well ya, and it avoids the issue with `memset` being invisible to nimprof |
| 10:39:27 | * | kinkinkijkin joined #nim |
| 10:39:37 | FromGitter | <timotheecour> (which turns out to be a major bottleneck , as Iâve proved) |
| 10:43:02 | Araq | yeah but I can't optimize memset |
| 10:43:43 | Araq | so that's a mostly meaningless result, unless you can tell me where the memsets come from |
| 10:44:40 | Araq | there, I optimized initIntSet, compilation times down by 0.5s |
| 10:48:19 | FromGitter | <timotheecour> i know, memset is already optimized as good as it can (eg AVX etc), but a faithful profiler should reveal this bottleneck and reflect it in parentâs total time; I donât think nimprof does or can with current strategy |
| 10:49:20 | * | kinkinkijkin quit (Remote host closed the connection) |
| 10:50:20 | * | kinkinkijkin joined #nim |
| 10:50:21 | FromGitter | <timotheecour> > unless you can tell me where the memsets come from â â I can from reading the call graphs (modulo that bug) or from reading OSXâs sampling profile; number 1 source of memset is from genericReset |
| 10:51:04 | Araq | and once the genericReset is optimized it will be just the memset() call left |
| 10:53:48 | FromGitter | <dom96> Narimiran: Araq: migrating all of the existing RFCs |
| 10:53:49 | FromGitter | <timotheecour> > there, I optimized initIntSet, compilation times down by 0.5s â â if thatâs true, thatâs great (would amount ot 10%); not sure how you measured though |
| 10:53:54 | * | kinkinkijkin quit (Remote host closed the connection) |
| 10:54:05 | FromGitter | <dom96> Into a formal format will be very painful |
| 10:54:32 | FromGitter | <timotheecour> ugh, Dâs DIPS are a disaster of bureaucracy |
| 10:54:34 | narimiran | @dom96 for us or for people who want to write them? ;) |
| 10:55:34 | * | kinkinkijkin joined #nim |
| 10:55:38 | FromGitter | <alehander42> yeah, I am also not sure about the RFC-s: some of the existing ones are simple and the fact one can post them, get a "yes this makes sense" and merge code for them in 1-2 days is very nice |
| 10:55:42 | FromGitter | <timotheecour> please letâs not reproduce that model; however, I do agree that maintaining a structured doc (in markdown, please) instead of github can help (maybe in a git repo, where others can send PRs against an RFC) |
| 10:55:49 | narimiran | @dom96 what is your opinion about current RFCs? should they be transferred to a new repo? |
| 10:56:03 | narimiran | (question for others too) |
| 10:56:52 | FromGitter | <timotheecour> i think some complex RFCâs warrant structured (maybe version controlled) doc, but many don't |
| 10:57:18 | FromGitter | <alehander42> I agree with @timotheecour |
| 11:02:23 | Araq | timotheecour: it is in devel, try for yourself |
| 11:02:26 | Araq | however |
| 11:02:48 | Araq | my measurement was done on this laptop which is running out of battery and disk space |
| 11:03:09 | Araq | and has widely different results from run to run |
| 11:03:45 | FromGitter | <timotheecour> well ya, i was trying it from devel, but couldnât repro that 0.5 sec speedup yet |
| 11:04:11 | FromGitter | <timotheecour> unrelated note; (maybe??) nim build broke in past 1 hour ish: see https://github.com/nim-lang/Nim/issues/10133 |
| 11:04:48 | Araq | everything I merged was green |
| 11:04:59 | Araq | but probably PRs interact with each other |
| 11:05:16 | FromGitter | <timotheecour> `nim c -r testament/tester.nim r tests/enum/tenumfieldpragma.nim` to repro |
| 11:05:51 | FromGitter | <alehander42> @Araq about the mutation not invalidating a.len, I am not sure I get it: it should not invalidate it, but it should change the "static length set" â â if a.len >= 2: â a.delete(1, 1) â echo a[1] # this might be an error [https://gitter.im/nim-lang/Nim?at=5c28a68f8dafa715c715a3b9] |
| 11:06:29 | * | kapil____ joined #nim |
| 11:06:46 | * | kinkinkijkin quit (Quit: Leaving) |
| 11:09:29 | * | kinkinkijkin joined #nim |
| 11:10:17 | FromGitter | <alehander42> ```code paste, see link``` |
| 11:10:47 | FromGitter | <alehander42> maybe just signifying this in signatured can deal with all of the mutation "changes" tho |
| 11:10:55 | FromGitter | <alehander42> (mutation of length, not an element) |
| 11:13:56 | FromGitter | <timotheecour> ok sent out https://github.com/nim-lang/Nim/pull/10134 hope it fixes CI failure |
| 11:21:59 | * | Vladar joined #nim |
| 12:05:10 | Araq | alehander42: how it works / will work: |
| 12:05:28 | Araq | if a.len >= 2 # push onto knowledge stack that 'a.len >= 2' |
| 12:05:57 | Araq | a.delete(1, 1) # pop all entries from stack that contain 'a' because a is passed to a 'var T' |
| 12:06:48 | Araq | mutations in the source code cause mutations in our knowledge base |
| 12:08:11 | Araq | we don't track that afterwards a.len >= 1, we reject the 'a.len >= 2' proposition instead |
| 12:17:55 | * | leorize quit (Ping timeout: 250 seconds) |
| 12:18:38 | * | OrganicAnywhere joined #nim |
| 12:19:20 | * | leorize joined #nim |
| 12:36:06 | * | xet7 joined #nim |
| 12:53:48 | * | dddddd joined #nim |
| 12:57:28 | FromGitter | <alehander42> so in this case a[0] and a[1] would both be warning/errors as we erased our a.len knowledge at that point? |
| 12:58:51 | FromGitter | <alehander42> maybe that's simpler indeed, I thought capturing this in your hypothetical `{.require ..len .}` would be a more general solution tho, as you wouldn't need to hardcode knowledge of `add`/`delete`/etc |
| 12:59:25 | Araq | yup, both a[0] and a[1] are invalid after a.delete(...) |
| 13:00:18 | FromGitter | <arnetheduck> if you're on linux, `perf record --call-graph` will capture call graphs and show origin of call.. with `perf top` you can even follow your program live and see where the hotspots are.. |
| 13:00:25 | * | OrganicAnywhere quit (Ping timeout: 252 seconds) |
| 13:01:04 | Araq | but I'm beginning to understand how Spark works and NimZ3 will eventually exist |
| 13:01:20 | * | vlad1777d joined #nim |
| 13:02:05 | FromGitter | <arnetheduck> apache spark? |
| 13:02:21 | Araq | Ada Spark. |
| 13:04:11 | Araq | https://github.com/Z3Prover/z3 |
| 13:09:58 | Araq | Z3 supports both "unbounded integer" arithmetic as well as "bit vectors" |
| 13:11:15 | Araq | but the primary reason you cannot prove the absense of overflows is that programmers are not aware of overflows and almost all code out there simply can overflow. You cannot prove it correct because it isn't. |
| 13:13:51 | * | nsf quit (Quit: WeeChat 2.3) |
| 13:14:46 | FromGitter | <arnetheduck> yeah, that's true. but what I'm after is more subtle - a bound or expression that tells me up to which point it's correct. *when* the grains of sand become a heap. |
| 13:17:24 | FromGitter | <arnetheduck> it's specially true for general applications and random mindlessly written code, but we have the advantage that the state transition in particular is isolated - one can afford to be rigorous there.. |
| 13:18:16 | FromGitter | <alehander42> So, if you have 2 int args and int result and function f you want to know for which ranges of args the result is valid ? |
| 13:18:32 | FromGitter | <alehander42> Sorry, I don't know the prehistory of your problem |
| 13:25:56 | FromGitter | <arnetheduck> yeah, something like that.. I have `uint64` coming in, a bunch of expressions (`a*3 < b*2`) - what's the safe bound on the incoming value of `a` in that case? `high(uint64)/3` - and so it goes on.. for every expression, you can build up better bounds so in the end, you can tell that your code is overflow-free up to X |
| 13:39:23 | FromGitter | <bluenote10> Hi! Any spontaneous ideas what could cause an internal error in `filename: "semexprs.nim", line: 406, column: 19` (latest devel)? I was trying to migrate godot-nim to 0.19, but I'm now stuck with this compiler crash and it is hard to find what is causing it (or come up with a minimal example) because the auto-generated godot bindings are huge. |
| 13:39:39 | FromGitter | <bluenote10> The full traceback is here: https://github.com/pragmagic/godot-nim/pull/42#issuecomment-450560842 |
| 13:40:14 | * | xet7 quit (Ping timeout: 250 seconds) |
| 13:47:02 | * | xet7 joined #nim |
| 13:48:54 | * | stef joined #nim |
| 13:50:07 | stef | Hi. Is it possible to run the tests without kock (without recompiling the tester exe)? |
| 13:54:33 | * | OrganicAnywhere joined #nim |
| 13:55:54 | leorize | stef: run the tester directly |
| 13:56:06 | leorize | it's testament/tester |
| 13:56:25 | stef | I tried, but I can't figure out the syntax |
| 13:56:56 | stef | Also I wonder why the documentation suggests to run using koch |
| 13:57:30 | leorize | testament/tester all <-- runs all tests |
| 13:57:53 | leorize | because koch will recompile testament and nim compiler automatically |
| 13:58:11 | stef | ohh... I first cd-ed into testament and then run ./tester, that's why it failed. Thanks! |
| 14:12:53 | stef | hmm... so all the koch commands basically are: <build the compiler> + <do something else>? |
| 14:13:40 | leorize | most of the time, yes |
| 14:13:46 | leorize | you can read koch source itself |
| 14:13:52 | leorize | it's pretty clear and easy to understand |
| 14:15:25 | stef | Great, I will. Btw what's the first place to look to start understanding the codebase? (if that's an easy question...) |
| 14:16:44 | leorize | https://nim-lang.github.io/Nim/intern.html |
| 14:16:51 | leorize | ^ that should do good |
| 14:19:37 | * | Ven`` joined #nim |
| 14:21:02 | stef | leorize: Of course i will read the documentation (manual, intern etc). Was just wondering about specific files, but I guess I'll figure it out. |
| 14:22:19 | dom96 | bluenote10: have you tried compiling with --verbosity:4? It might show you where in your code that error shows up |
| 14:27:28 | * | xet7 quit (Ping timeout: 250 seconds) |
| 14:29:54 | FromGitter | <bluenote10> @dom96 cool thanks, I think I just found the issue... Will probably open an issue to discuss it |
| 14:35:59 | FromGitter | <bluenote10> I'm not sure if this is a known issue or if it is actually supposed to work: https://github.com/nim-lang/Nim/issues/10136 |
| 14:36:32 | dom96 | Not sure either, but definitely an issue nonetheless |
| 14:38:52 | * | OrganicAnywhere quit (Ping timeout: 252 seconds) |
| 14:43:08 | * | xet7 joined #nim |
| 15:02:09 | * | stef quit (Quit: WeeChat 2.3) |
| 15:05:33 | FromGitter | <zacharycarter> I think no matter where the RFCs exist - there's going to be some sort of live-revision process happening |
| 15:05:51 | FromGitter | <zacharycarter> I'm not sure what the conversion to markdown and getting them off of github does |
| 15:06:18 | FromGitter | <zacharycarter> besides preserving them if github were to disappear |
| 15:09:07 | FromGitter | <alehander42> @arnetheduck well you need to generate some range of var-ranges, e.g. â [a in [X, Y] b in [X1, Y1]] â [a in [X2, Y2] b in [X3, Y3]] â or directly â [a in [X, Y] b in f(a boundaries)] [https://gitter.im/nim-lang/Nim?at=5c28df9293cce97d3bbe9a31] |
| 15:09:39 | FromGitter | <alehander42> or just a very conservative [a in [X, Y] for all kinds of b, b in [X1, Y1] for all kinds of a] |
| 15:24:19 | * | nsf joined #nim |
| 15:27:13 | * | kinkinkijkin quit (Remote host closed the connection) |
| 15:32:26 | FromGitter | <zacharycarter> https://github.com/SanderMertens/bake |
| 15:34:51 | FromGitter | <zacharycarter> another build system to not use for C/C++ \o/ |
| 15:35:17 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 15:36:22 | FromGitter | <zacharycarter> does anyone have any experience with - https://mesonbuild.com/ and Nim? |
| 15:37:00 | FromGitter | <zacharycarter> I have C++ dependencies for my project, and it's a pain to instruct people how to compile them for their platform |
| 15:37:18 | FromGitter | <zacharycarter> wondering if it might be worth it to find a build system that can handle C++ and Nim as well |
| 15:37:50 | FromGitter | <zacharycarter> I guess I could just use genie (premake) since the C++ projects are already using it |
| 15:38:14 | FromGitter | <zacharycarter> and just have genie invoke the Nim compiler |
| 15:38:31 | FromGitter | <zacharycarter> I don't know... I don't have a good answer for this |
| 15:39:50 | FromGitter | <zacharycarter> I guess I'll just let people worry about building them |
| 15:39:58 | FromGitter | <zacharycarter> on their own I mean |
| 15:44:38 | * | Tyresc joined #nim |
| 15:45:22 | * | natrys joined #nim |
| 15:50:56 | FromGitter | <deech> What are the case object and comment field features? https://forum.nim-lang.org/t/4500 |
| 15:50:57 | * | kinkinkijkin joined #nim |
| 15:55:20 | leorize | comment field is basically exposing doc comments to the AST afaict |
| 15:56:25 | leorize | case objects are just object variants I believe? |
| 15:56:54 | * | kinkinkijkin quit (Remote host closed the connection) |
| 15:57:23 | * | kinkinkijkin joined #nim |
| 15:57:23 | FromGitter | <Clyybber> They are equivalent to unions in C afaik |
| 16:02:05 | * | thumbs_scum quit (Ping timeout: 268 seconds) |
| 16:03:32 | FromGitter | <alehander42> not really, they're more similar to algebraic types(but still not the same) |
| 16:04:09 | FromGitter | <alehander42> the shared subparts of the case objects are represented with unions in the c backend |
| 16:07:36 | * | natrys quit (Quit: natrys) |
| 16:09:20 | Araq | bluenote: both 0.19 and devel affected? |
| 16:10:04 | * | thumbs_scum joined #nim |
| 16:12:04 | Araq | the bullet point about 'case objects' is about fixing their memory safety holes |
| 16:12:49 | Araq | I recently found an alternative solution to this problem by studying Modula 2 more carefully. :P |
| 16:16:02 | FromGitter | <bluenote10> Araq: I didn't verify, but I assume 0.19 as well. The change linked in the issue is from August and 0.19 was released in September, right? |
| 16:18:04 | Araq | internalAssert c.config, lhsType.base.kind != tyNone |
| 16:18:04 | Araq | if c.inGenericContext > 0 and lhsType.base.containsGenericType: |
| 16:18:04 | Araq | # BUGFIX: don't evaluate this too early: ``T is void`` |
| 16:18:04 | Araq | return |
| 16:18:29 | Araq | ^ seems we can move this check into the 'if' and let later phases sort it out |
| 16:23:13 | FromGitter | <bluenote10> yes, the linked PR also had a discussion about that, mentioning that the path wasn't triggered so far. So we could use that as test case |
| 16:23:35 | FromGitter | <bluenote10> isn't a showstopper for the godot bindings anyway, there was a simple work-around ;) |
| 16:26:18 | * | krux02 joined #nim |
| 16:28:16 | * | Trustable joined #nim |
| 16:29:51 | Araq | alright |
| 16:29:58 | Araq | anything else blocking godot? |
| 16:30:20 | krux02 | hello |
| 16:30:36 | FromGitter | <zacharycarter> o/ |
| 16:31:59 | * | nc-x joined #nim |
| 16:32:27 | Araq | hi |
| 16:32:43 | nc-x | Araq: can you please merge https://github.com/nim-lang/Nim/pull/10135, it makes devel green |
| 16:35:04 | FromGitter | <bluenote10> Araq: No, I only hit this issue as well, but also with a straightforward workaround: https://github.com/nim-lang/Nim/issues/7375 |
| 16:36:09 | FromGitter | <bluenote10> Everything compiles now on latest devel and I get a shared lib... I only haven't figured out how to properly load it in Godot, but that's most likely because I'm using it for the first time ;) |
| 16:36:49 | * | nc-x quit (Client Quit) |
| 16:37:36 | * | btbytes joined #nim |
| 16:43:09 | * | kinkinkijkin quit (Quit: Leaving) |
| 16:45:22 | shashlick | leorize: regarding Nim help, I was referring to the manual and proc documentation |
| 16:45:36 | shashlick | Having twenty tabs open in the browser is a nuisance |
| 16:55:03 | leorize | shashlick: links to the rescue :P |
| 16:55:05 | leorize | or w3m |
| 16:55:30 | FromGitter | <alehander42> i used to have like 40-50 tabs all the time |
| 16:55:35 | shashlick | I know someone mentioned a command line client to read the docs |
| 16:55:36 | FromGitter | <alehander42> and these days i have up to 9-10 max |
| 16:55:47 | FromGitter | <alehander42> i guess i learned to manually GC them all the time |
| 16:56:07 | FromGitter | <alehander42> with periodical full dealloc :D |
| 16:56:59 | shashlick | Was hoping to use Nimscript as an extention language but cannot interact with the running process at all |
| 16:57:51 | shashlick | Either have to extend nimscript or build in compiler |
| 16:59:16 | FromGitter | <bluenote10> current number of open tabs: 537 will close some next year ;) |
| 17:04:12 | krux02 | 4 to 5 tabs here |
| 17:04:17 | krux02 | that is healthy |
| 17:04:33 | krux02 | you know you can close tabs and open the same website later again? |
| 17:05:26 | FromGitter | <alehander42> yeah, I agree that history/bookmarks are underrated |
| 17:05:54 | krux02 | just history |
| 17:06:05 | FromGitter | <alehander42> but on the other hand I often have 300-400 tabs in sublime, so I can see the problem |
| 17:06:12 | krux02 | you can visit everything that was open once |
| 17:06:22 | krux02 | and you can search in it |
| 17:06:35 | shashlick | Tabs are not scalable |
| 17:06:37 | krux02 | no need to keep anything open for "later" |
| 17:06:39 | FromGitter | <alehander42> history doesn't have priority: i might have visited X 500 times, but not remembering the exact article title |
| 17:06:47 | FromGitter | <alehander42> bookmarks give you a bit of priority |
| 17:06:53 | krux02 | tabs don't have priority either |
| 17:07:02 | FromGitter | <alehander42> i am arguing for history/bookmarks too |
| 17:07:34 | krux02 | history has priority. Anything recent has priority, anything far away in the past is far away in the past. |
| 17:07:46 | shashlick | I'm not implementing tabs in the editor I'm writing |
| 17:07:51 | FromGitter | <alehander42> meh, can't agree, bookmarking is useful |
| 17:08:03 | FromGitter | <bluenote10> I also go down to like 5 from time to time, but I have to say it still works surprisingly well for me... would have guessed it's like 50 tabs or so ;) |
| 17:08:14 | FromGitter | <alehander42> for stuff like sublime: I'd implement tab "collection": after a while if a tab hasn't been used AND it's saved, close it |
| 17:08:29 | FromGitter | <alehander42> and make that configurable |
| 17:13:37 | shashlick | Anyway, nothing like running a command in the terminal and getting the exact proc as a result |
| 17:13:49 | shashlick | In the terminal most of the time |
| 17:14:55 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzzâŚ) |
| 17:15:49 | shashlick | Or integrate the search into the editor eventually |
| 17:17:14 | * | Ven`` quit (Read error: Connection reset by peer) |
| 17:17:30 | * | Ven`` joined #nim |
| 17:19:24 | * | btbytes joined #nim |
| 17:28:01 | FromGitter | <arnetheduck> @alehander42 indeed - and it looks like a very systematic problem that I'm pretty sure people have looked into already :) |
| 17:30:03 | * | kinkinkijkin joined #nim |
| 17:34:10 | Araq | shashlick, I can guide you how to make stdin.readline work from Nimscript but I hesitate to add it to the compiler |
| 17:49:10 | * | jjido quit (Quit: Connection closed for inactivity) |
| 17:49:59 | * | kinkinkijkin quit (Quit: Leaving) |
| 18:00:01 | * | Vladar quit (Remote host closed the connection) |
| 18:11:03 | * | nc-x joined #nim |
| 18:12:41 | nc-x | I think someone should review/merge the PR's/Guest posts for the website |
| 18:12:44 | nc-x | https://github.com/nim-lang/website/pulls |
| 18:12:59 | nc-x | Some of the PR's are unreviewed |
| 18:13:26 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzzâŚ) |
| 18:14:41 | FromGitter | <deansher> Seems like maybe it's a law of Nim linguistics that one cannot stash a type and use it in a declaration later. For example, here's one of many permutations I've tried. Can anyone tell me either that it *is* a law (and ideally why!) or how to do it? â â ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c290b10f6166a3027934165] |
| 18:17:03 | * | Pisuke joined #nim |
| 18:17:08 | * | MyMind quit (Ping timeout: 250 seconds) |
| 18:17:37 | * | nc-x quit (Ping timeout: 256 seconds) |
| 18:22:23 | Araq | var mytypes {.compileTime.}: seq[NimNode] |
| 18:22:56 | Araq | macro insert(t: typed) = mytypes.add t |
| 18:23:27 | Araq | though I don't see why you would do that. types work better when they describe the invariants in your program |
| 18:29:23 | FromGitter | <deansher> :-) Thanks! |
| 18:32:33 | FromGitter | <deansher> @Araq Agreed, but I'm working around a different issue. Simplified from last night to highlight that issue: â â I am working on a macro package that will allow a user to declare a "field" in module A and then use it from module B. A field has an identifier, a fully qualified name, and a type. The fully qualified name is constructed from the module name and the identifier. (This is inspired by Clojure's namespaced |
| 18:32:33 | FromGitter | ... maps.) I am trying to figure out what underlying Nim thing I can export from module A and reference in module B to represent the field. â â The field declaration macro could separately define a type and a const tuple in module A, but then that's not a single thing that the programmer can think of as the field for imp ... [https://gitter.im/nim-lang/Nim?at=5c290f418dafa715c7182937] |
| 18:32:38 | shashlick | Araq: I can certainly make a custom build of nim with the capabilities I need in nimscript but I think its important to consider making this standard so that more folks can use nim as a script engine |
| 18:33:21 | shashlick | I understand your reservations but there's a difference between Nim as a compiler and Nim as a script engine |
| 18:33:52 | shashlick | and even otherwise, having an expanded feature set in the VM makes macros and compile time that much more powerful |
| 18:34:16 | shashlick | in fact, likewise with FFI support in the VM |
| 18:34:41 | shashlick | but I want to understand your concerns before grumbling any further |
| 18:53:58 | Araq | shashlick, my motivation is easy to understand: I don't want a compiler that suddenly stops and asks me stuff on stdin |
| 18:54:36 | Araq | just because somebody put let installDir = prompt("installation dir?") in a 'static' section |
| 18:56:51 | shashlick | but that blocks legitimate use cases in nimscript where I could use pipes |
| 18:57:15 | shashlick | and let's just say that if someone did something like that, you wouldn't use the package đ |
| 18:57:57 | Araq | how would I know? |
| 19:00:13 | shashlick | you'd use it once and then throw it out I guess |
| 19:02:12 | Araq | please tell me instead what you wanna "pipe" into your nimscript |
| 19:03:02 | shashlick | so like I said before, I want to use nim as a script engine without building it all in |
| 19:03:25 | shashlick | so the idea was to kick off a nim e script.nims and then talk back and forth with stdin/stdout |
| 19:04:16 | shashlick | this way, you could write plugins in any language and just use this simple interface |
| 19:05:00 | shashlick | but that's my use case, you could just as well imagine writing simple nim scripts that as part of a bunch of pipe commands |
| 19:05:09 | shashlick | ls | nim e process.nims |
| 19:35:01 | * | Vladar joined #nim |
| 19:36:19 | FromGitter | <Varriount> Araq: How did you come across that paper on Garbage Collection? |
| 19:58:05 | * | ChristianWitts joined #nim |
| 20:00:30 | Araq | shashlick, hmm I think this should be done with a nimscript.exe |
| 20:01:15 | Araq | Varriount: Google search on "reference counting with cycle detection" or similar |
| 20:01:26 | Araq | and going through all the papers it brought up :P |
| 20:02:09 | * | vivus joined #nim |
| 20:11:28 | shashlick | that would mean yet another binary with the full compiler in it |
| 20:16:37 | * | endragor joined #nim |
| 20:21:48 | * | ChristianWitts quit (Ping timeout: 272 seconds) |
| 20:23:34 | * | endragor quit (Ping timeout: 268 seconds) |
| 20:24:09 | * | endragor joined #nim |
| 20:28:23 | FromGitter | <timotheecour> @araq 2 questions: â â 1) not sure what youâre suggesting in this review comment: https://github.com/nim-lang/Nim/pull/10070#discussion_r244528070 â 2) see https://github.com/nim-lang/Nim/pull/10070#discussion_r244544490 [https://gitter.im/nim-lang/Nim?at=5c292a66ab910e7d3af89345] |
| 20:32:20 | * | endragor quit (Ping timeout: 250 seconds) |
| 20:32:42 | * | endragor joined #nim |
| 20:38:28 | * | nsf quit (Quit: WeeChat 2.3) |
| 20:50:20 | * | Ven`` quit (Ping timeout: 244 seconds) |
| 20:52:28 | * | krux02 quit (Remote host closed the connection) |
| 20:53:22 | * | krux02 joined #nim |
| 21:09:02 | * | shashlick quit (Remote host closed the connection) |
| 21:29:07 | * | Ven`` joined #nim |
| 21:43:11 | * | btbytes joined #nim |
| 21:49:44 | * | Vladar quit (Remote host closed the connection) |
| 22:00:19 | * | Trustable quit (Remote host closed the connection) |
| 22:01:51 | * | krux02 quit (Remote host closed the connection) |
| 22:02:28 | * | narimiran quit (Ping timeout: 250 seconds) |
| 22:11:02 | FromGitter | <zetashift> Oh wow karax v1 was released? I didn't even know |
| 22:12:59 | * | endragor quit (Remote host closed the connection) |
| 22:16:49 | * | Sembei joined #nim |
| 22:17:08 | * | Pisuke quit (Ping timeout: 244 seconds) |
| 22:41:25 | dom96 | Wow, really? A v1 with not even a forum thread? |
| 22:59:29 | * | nsf joined #nim |
| 23:14:50 | * | hoijui quit (Ping timeout: 250 seconds) |
| 23:23:49 | * | flyx quit (Quit: ZNC - http://znc.in) |
| 23:24:04 | * | flyx joined #nim |
| 23:32:49 | * | nsf quit (Quit: WeeChat 2.3) |
| 23:41:30 | * | stefanos82 quit (Remote host closed the connection) |
| 23:47:19 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzzâŚ) |
| 23:54:24 | * | whaletechno joined #nim |