| 00:07:12 | FromGitter | <zetashift> Anybody know why this if branch isn't being reached? https://gist.github.com/zetashift/65b6a89f8cf322682ab01e7aac1878b4#file-genmap-nim-L27 |
| 00:07:51 | FromGitter | <zetashift> I should rectify my v1 statement the commit says: The API is reasonably stable and version 1 should arrive anytime soon ⏎ now. |
| 00:07:58 | FromGitter | <zetashift> mah bad |
| 00:28:04 | FromGitter | <zetashift> huh moving the if-statement out of the genMap block solved it I wonder why |
| 00:30:01 | * | vlad1777d quit (Ping timeout: 246 seconds) |
| 00:37:10 | * | d10n-work joined #nim |
| 01:28:20 | * | craigger quit (Ping timeout: 272 seconds) |
| 01:29:46 | * | craigger joined #nim |
| 01:31:35 | * | xet7 quit (Remote host closed the connection) |
| 01:43:15 | * | vivus quit (Remote host closed the connection) |
| 02:12:24 | FromGitter | <gogolxdong> Can ECMAScript6 module be imported into Karax? |
| 02:13:31 | FromGitter | <Varriount> Araq: It's a very interesting paper. |
| 02:37:08 | * | Ven`` quit (Ping timeout: 245 seconds) |
| 02:40:28 | FromGitter | <zacharycarter> @gogolxdong I don't see why not |
| 02:40:36 | FromGitter | <zacharycarter> you'd need to use babel or something |
| 02:41:22 | * | Tyresc quit (Quit: WeeChat 2.4-dev) |
| 02:53:53 | FromGitter | <gogolxdong> ah, thanks, I'm novice at web frontend. will check how babel works. |
| 03:00:34 | * | banc quit (Quit: Bye) |
| 03:01:18 | * | craigger quit (Ping timeout: 244 seconds) |
| 03:01:23 | FromGitter | <gogolxdong> Nim targets javascript1.5 which corresponding to EMACScript 5th , right? |
| 03:01:33 | * | craigger joined #nim |
| 03:03:52 | FromGitter | <zacharycarter> no |
| 03:04:06 | FromGitter | <zacharycarter> I think Nim targets ECMAScript 2 or 3 |
| 03:05:03 | FromGitter | <gogolxdong> Components of Google material design is written in at least ES6 version according to its syntax, `babel index.js --presets es2015` converts it to ES5? |
| 03:06:03 | FromGitter | <zacharycarter> it's ES3 |
| 03:06:24 | FromGitter | <zacharycarter> Nim's JS backend I mean |
| 03:06:35 | FromGitter | <zacharycarter> I'm not sure re: the babel question |
| 03:06:47 | FromGitter | <zacharycarter> I assume so though |
| 03:07:15 | FromGitter | <gogolxdong> yeah, it's ES3. |
| 03:09:12 | FromGitter | <gogolxdong> Does this mean higher version module than ES3 cannot be imported directly? |
| 03:16:34 | * | banc joined #nim |
| 03:20:21 | FromGitter | <zacharycarter> it can as long as you're using babel during your build process |
| 03:25:48 | FromGitter | <gogolxdong> ok |
| 03:28:06 | FromGitter | <zacharycarter> keep in mind - Nim, to my knowledge, has no `import "foo";` syntax aka ES6 import syntax |
| 03:30:33 | FromGitter | <zacharycarter> so you'll have to do something like - `proc importModule(moduleName: cstring): JsObject = {.importcpp: "import '#'")` |
| 03:30:37 | FromGitter | <zacharycarter> something like that... |
| 03:32:23 | * | dddddd quit (Remote host closed the connection) |
| 03:34:06 | FromGitter | <gogolxdong> How to check which tool is using during build process? |
| 03:37:47 | * | Ven`` joined #nim |
| 03:38:10 | * | Cthalupa quit (Ping timeout: 272 seconds) |
| 03:39:09 | * | Cthalupa joined #nim |
| 04:33:58 | * | kapil____ joined #nim |
| 04:36:34 | * | btbytes joined #nim |
| 04:44:10 | * | Cthalupa quit (Ping timeout: 250 seconds) |
| 04:46:16 | * | Cthalupa joined #nim |
| 04:52:45 | * | Cthalupa quit (Read error: No route to host) |
| 04:52:57 | * | Cthalupa joined #nim |
| 04:56:09 | * | d10n-work quit (Quit: Connection closed for inactivity) |
| 05:08:52 | * | Ven`` quit (Ping timeout: 250 seconds) |
| 06:03:34 | * | Vladar joined #nim |
| 06:13:22 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 06:47:52 | * | nsf joined #nim |
| 06:49:47 | FromGitter | <Varriount> Araq: Are pointers in Nim tagged? |
| 06:56:06 | * | narimiran joined #nim |
| 07:14:06 | * | Cthalupa quit (Ping timeout: 250 seconds) |
| 07:16:30 | * | Cthalupa joined #nim |
| 07:16:46 | * | vlad1777d joined #nim |
| 07:43:40 | * | hoijui joined #nim |
| 08:41:10 | FromGitter | <gogolxdong> Is preset-es2015 the oldest babel can set? |
| 08:44:45 | * | ChristianWitts joined #nim |
| 08:53:04 | Araq | varriount: no. |
| 08:55:20 | FromGitter | <timotheecour> hi @araq I’d really appreciate if you could either merge or provide feedback on my PR’s, so I can unblock the other ones I’m working on |
| 08:56:32 | FromGitter | <timotheecour> (only the green ones on which the last comment is from me) |
| 08:57:22 | Araq | for 2 to 3 days now I wanted to release 0-19 but I'm constantly distracted by the PR queue |
| 08:57:23 | FromGitter | <timotheecour> I have new ones coming up and it’s really difficult to have to maintain so many different un-merged branches |
| 08:58:01 | Araq | not too mention that I should work on the v1 stuff. |
| 08:58:52 | Araq | this is not effective. |
| 08:58:56 | FromGitter | <timotheecour> honestly I don’t care much whether my PRs end up in 0.19 or some other version, all I’d wish for is that they can be merged so I can reduce my local unmerged branches |
| 08:59:22 | Araq | obviously they don't end up in 0.19 |
| 08:59:35 | FromGitter | <timotheecour> i meant 0.19.X |
| 09:01:20 | Araq | take this one for example: https://github.com/nim-lang/Nim/pull/10070 |
| 09:01:36 | Araq | I don't understand what any of this has to do with 'static T in a tuple' |
| 09:02:11 | Araq | so now I need to follow some test case to understand why, essentially replicating your work. |
| 09:02:14 | FromGitter | <timotheecour> i can explain: `var t: T` made a test fail |
| 09:04:18 | FromGitter | <timotheecour> could post-commit audits (instead of pre-commit review) ever be an option? with assumption that: PR author that commits agrees to fix whatever was in post-commit review comments |
| 09:05:06 | FromGitter | <timotheecour> so as to make review process more efficient both for reviewers as well as PR author |
| 09:06:44 | Araq | well it would also help if you would work on more important issues and watch your diffs. Sorry to be this blunt. |
| 09:07:29 | Araq | I don't appreciate code rewrites that suit the OP's style better, the compiler and stdlib set a style |
| 09:08:32 | Araq | more on topic, so what if $ for tuples produces Field0 names, at this point $ has become a debugging tool |
| 09:08:51 | * | nc-x joined #nim |
| 09:09:44 | Araq | system.nim has the most exported and private symbol of all modules in the entire Nim compiler codebase |
| 09:10:20 | Araq | if that's not bloated, I dunno what is. and now we get isNamedTuple(). Who asked for this feature? |
| 09:10:30 | FromGitter | <timotheecour> well it’s been raised in prior posts. (not just by me) that `“Field0”` etc is implementation detail and shouldn’t be exposed; furthermore, IIRC you were the one that suggested that tuple to json should only work for named tuples, so that PR also helps with that thanks to isNamedTuple |
| 09:10:48 | Araq | yeah I know the history of this feature |
| 09:11:36 | FromGitter | <timotheecour> I also have ideas on how to un-bloat system.nim, that’s an orthogonal topic that can be done independently |
| 09:12:31 | Araq | here is what others do: |
| 09:12:37 | * | nc-x quit (Client Quit) |
| 09:12:49 | Araq | - they report bugs. |
| 09:13:00 | Araq | - they create patches that fix bugs. |
| 09:13:13 | Araq | here is what you do: |
| 09:14:17 | Araq | - you find a travis bug, report it to the Nim repo, dream up a feature for Nim that could perhaps deal with a somewhat related problem |
| 09:14:48 | Araq | and write a PR adding 100 lines of code to testament |
| 09:15:18 | FromGitter | <timotheecour> I’ve reported a number of actualy nim bugs, and fixed a number of actual nim bugs / regressions (whether these were proposed by someone else or myself) |
| 09:15:33 | Araq | Code lines have a real and ongoing cost. |
| 09:15:42 | Araq | features have a real and ongoing costs. |
| 09:17:47 | Araq | and yes you also do highly appreciated work. |
| 09:21:30 | Araq | we have 1495 open issues |
| 09:21:54 | Araq | 242 opened by you, https://github.com/nim-lang/Nim/issues/created_by/timotheecour |
| 09:24:14 | Araq | 16% of all open issues |
| 09:25:57 | Araq | the oldest from you is "there is no Nim man". |
| 09:26:07 | FromGitter | <timotheecour> I’ve also 170 megred PRs (with 60 of them having ‘fixed’ in title) |
| 09:27:38 | Araq | sure but I think it's fair I ignore PRs from you that don't address any of 242 opened issues by you |
| 09:32:39 | narimiran | good morning guys. if i may: |
| 09:33:28 | Araq | and it never ceases to amaze me how every feature from C++ and C# is worth copying but for the love of god we can't copy from them what made successful, a development model that starts at version 1. |
| 09:33:46 | narimiran | 1. releasing 0.19.2 should be priority (not sidetracked by other issues/PRs) as this would be the best new year present for the most of nim users |
| 09:35:21 | narimiran | 2. @timotheecour your contributions are appreciated, i think everybody can agree on that. but we should really work on closing all those issues |
| 09:37:14 | FromGitter | <timotheecour> regarding opening issues: when I encounter an issue, reporting it (after dedupping) is IMO the right thing to do (yes, there’s a gray area here too). The number of open issues is not the ulimate metric I think matters most (some projects keep it to < 10 with a bot, I think that’s not a good idea), it's just being honest about state of a project. What matters is whether the issues (whether reported or not) are |
| 09:37:14 | FromGitter | ... fixed, and how usable is the project |
| 09:38:24 | Araq | if you report 16% of bugs in a project that others used successfully to ship software with this says something about your workflow moreso than about the state of Nim |
| 09:39:41 | * | nc-x joined #nim |
| 09:39:45 | Araq | not everybody is on a holy quest to eliminate all 'for' loops from his programs, others prefer to write code in order to ship a product. |
| 09:40:04 | FromGitter | <timotheecour> not sure I follow here either; nim is usable and has been for a long time; doens’t mean it can’t be improved; and ppl care about different things in their workflow. |
| 09:41:05 | nc-x | yeah bugs encountered in any workflow is a bug whatsoever. |
| 09:41:18 | Araq | I shifted the topic btw, I'm not talking about you personally |
| 09:41:30 | nc-x | and any and every contribution is appreciated |
| 09:42:10 | nc-x | the problem wrt slow merging of PRs can only be solved IMO by having more number of trusted and knowledgeable contributors |
| 09:42:37 | nc-x | I think there has been a lot of discussion on this topic many times previously |
| 09:42:41 | Araq | I disagree, sorry. |
| 09:43:04 | Araq | We need to ship something stable and PRs can affect stability. |
| 09:43:31 | nc-x | yeah for that we need a release schedule kind of thing |
| 09:43:38 | nc-x | new release every 6 months |
| 09:43:47 | nc-x | last two months no new feature |
| 09:43:55 | nc-x | only bugs and regression fixes |
| 09:43:57 | Araq | and yes we have talked many times about this, in the end not much changed, new features are added, old bugs remain open |
| 09:44:34 | nc-x | i think golang has this kind of schedule |
| 09:44:56 | nc-x | rust instead gates every new feature and releases it first into nightly, then beta, then stable |
| 09:46:06 | nc-x | > new features are added, old bugs remain open |
| 09:46:48 | nc-x | many times that happens because the new feature is a quality of life improvement for some workflows and it was relatively easy to implement |
| 09:48:27 | FromGitter | <timotheecour> Araq, you’ve broken the build a few times (by direct merge instead of runing CI suite via PR), and that’s an acceptable tradeoff because it speeds up development (such breakages typically fixed quickly); likewise, any new feature or bugfix is a potential regression, that’s just nature of software. I much prefer move fast and break things (and fix fast afterwards) than move slow and discourage PR contributions |
| 09:49:46 | FromGitter | <timotheecour> (within bounds of having green PR’s only, which is a big sanity check) |
| 09:50:09 | Araq | ok, it's good that you disagree with me |
| 09:50:22 | Araq | how about this: |
| 09:50:48 | Araq | we push the priority of "test for regressions by testing nimble packages" to "asap" |
| 09:51:24 | Araq | so that the "CI is green" becomes more acceptable for quality ensurance |
| 09:52:09 | FromGitter | <timotheecour> are you talkign about my RFC https://github.com/nim-lang/Nim/issues/8638 ? |
| 09:52:38 | Araq | yes, but this idea came up from lots of people |
| 09:54:10 | FromGitter | <timotheecour> just changed it to `high priority`; I agree that issue is super important, and can help with addressing that if I have spare cycles |
| 09:54:48 | Araq | yeah and here is the thing ;-) |
| 09:54:57 | Araq | you obviously have some spare cycles. |
| 09:55:45 | Araq | no offense, but that's what I said already, "please work on more pressing things" |
| 09:56:32 | nc-x | araq, is removing need for forward declaration in the roadmap for 1.0? |
| 09:56:52 | Araq | obviously not but tbh |
| 09:57:19 | Araq | the language would work better without this, it affects generic methods and also now destructors |
| 09:57:44 | Araq | great care must be taken that it keeps code like |
| 09:57:56 | Araq | when not declared(foo): proc foo ... |
| 09:58:07 | * | vlad1777d quit (Ping timeout: 240 seconds) |
| 09:58:08 | Araq | as it works now |
| 09:58:19 | nc-x | also whats your opinion on removing include file and adding go/java like packages? |
| 09:58:43 | Araq | don't remove 'include', I love it |
| 09:59:04 | nc-x | because the included file generally doesn't import a lot of things but depends on the file including it to do the imports. |
| 09:59:07 | Araq | but a concept like "module is actually a dir of .nim files" could work out |
| 09:59:11 | nc-x | So nimsuggest chokes badly |
| 09:59:11 | FromGitter | <timotheecour> on projects that I own, it’s a lot easier to make deeper contributions (eg that require refactorings etc); for Nim, it’s harder for ppl like me, that are outside of core team (you, dom66, krux) to make such deeper contributions; so I contribute the stuff that I need and that affects me most that are within reasonable complexity bounds. |
| 09:59:46 | Araq | nc-x, nimsuggest understands include files |
| 09:59:48 | nc-x | Also, does anyone know where lemonboy went? |
| 09:59:58 | nc-x | I was loving his contributionsp |
| 10:00:34 | nc-x | araq: not if you opened just the included file? because as i said it does not contain the required imports |
| 10:00:49 | Araq | nc-x, that is a nimsuggest configuration problem |
| 10:00:50 | * | stefanos82 joined #nim |
| 10:00:56 | nc-x | similarly nim check also fails for these files with symbol not defined |
| 10:01:01 | nc-x | IIRC |
| 10:01:04 | Araq | obviously. |
| 10:01:09 | narimiran | nc-x: +1 for lemonboy |
| 10:01:22 | Araq | the solution is to give your tools the real entry point, not the inlcude file |
| 10:02:16 | nc-x | I dunno. Opening the nim source code in vscode gives 90% of the source code in red color and mostly broken nimsuggest |
| 10:02:27 | Araq | fix the vscode plugin |
| 10:02:54 | nc-x | which editor do you use? |
| 10:03:01 | Araq | vscode |
| 10:03:20 | nc-x | you don't have such issues with red? |
| 10:03:32 | nc-x | or do you not use the plugin |
| 10:03:42 | Araq | I disabled it |
| 10:04:12 | FromDiscord_ | <exelotl> Ahh I was also wondering about this, so it's an issue with the plugin, not something that can be fixed with a config file? |
| 10:04:24 | nc-x | Well I tried debugging the plugin but on windows at least vscode gets stuck at building and never finishes |
| 10:04:29 | nc-x | Araq: okay |
| 10:04:50 | * | ChristianWitts quit (Ping timeout: 250 seconds) |
| 10:05:26 | Araq | on OSX I cannot change the color scheme because of file permission bullshit |
| 10:05:49 | Araq | software never works ;-) |
| 10:06:16 | FromDiscord_ | <exelotl> Gotta love software |
| 10:06:23 | nc-x | btw on github the label osx is spelled wrongly as ox |
| 10:07:29 | FromGitter | <timotheecour> assuming something like https://github.com/nim-lang/Nim/issues/8638 is implemented, would that change in any way velocity of PR review cycle? |
| 10:08:57 | Araq | that remains to be seen, probably, but it would change the quality of the Nim releases |
| 10:09:15 | FromGitter | <timotheecour> (assuming a PR is green for Nim’s CI + nimble - wide CI) |
| 10:09:28 | nc-x | that would lead to a for sure CI timeout (if you run it for every commit) |
| 10:09:34 | Araq | it definitely helps in convincing me that it doesn't break code |
| 10:09:46 | narimiran | nc-x: it would be run in a separate repo (by federico3?) |
| 10:10:01 | nc-x | rust guys usually run a similar tool manually on their own machines IIRC |
| 10:10:54 | FromGitter | <timotheecour> ya, travis/appveyor isn’t the only option (could be tested on AWS instances for eg) |
| 10:11:41 | nc-x | narimiran: wrong commit got backported |
| 10:12:04 | nc-x | https://github.com/nim-lang/Nim/commits/version-0-19 |
| 10:12:10 | nc-x | 6th commit from top |
| 10:12:25 | narimiran | nc-x: your? |
| 10:12:29 | nc-x | Undefine some symbols and globalOptions when processing nimscript ( |
| 10:12:29 | nc-x | yes |
| 10:12:45 | narimiran | hmmm, let me see what/why happened |
| 10:12:48 | Araq | these are essential for Nimscript |
| 10:12:54 | nc-x | instead if you want to backport nimscript fixes, you need to do the commits by araq |
| 10:12:54 | Araq | I may have requested these |
| 10:13:19 | nc-x | Araq: but you fixed them later by manually adding when defined(nimscript) or similar |
| 10:13:30 | nc-x | so those commits need to be backported IMO |
| 10:13:33 | nc-x | not my hacks |
| 10:13:37 | nc-x | ;) |
| 10:13:58 | narimiran | it had [backport] tag |
| 10:15:51 | Araq | yeah, my bad |
| 10:16:23 | narimiran | should i revert it then? |
| 10:16:30 | Araq | yup |
| 10:17:04 | nc-x | https://github.com/nim-lang/Nim/commits/devel?after=bcbe317d177e9a22856e8dd6c0ad1e20436b913a+69 |
| 10:17:25 | nc-x | you'll hve to look through here to find araq's commits fixing those issues properly |
| 10:18:10 | nc-x | Also most probably some other commits need to be reverted or added because travis is red on that branch |
| 10:18:24 | * | FromGitter quit (Remote host closed the connection) |
| 10:18:44 | * | FromGitter joined #nim |
| 10:19:00 | narimiran | tests/stdlib/tos.nim — this one fails |
| 10:19:10 | narimiran | expression 'walkDirRec("walkdir_test", {pcFile}, {pcDir}, relative = true)' cannot be called |
| 10:19:36 | nc-x | maybe revert the walkdir commit (its near the top) and try running the CI |
| 10:20:27 | * | nc-x quit (Quit: Page closed) |
| 10:20:38 | narimiran | nc-x: yeah, i had some merge conflicts when i backported it. let us try without it and see what happens |
| 10:39:47 | * | rokups joined #nim |
| 11:06:54 | narimiran | woohoo, 0.19 branch is passing CI (cc nc-x, Araq) |
| 11:15:42 | * | rect0x51 joined #nim |
| 11:18:12 | * | ChristianWitts joined #nim |
| 11:22:31 | rect0x51 | Does Nim have tagged unions? Enums are ordinals so they seem different. |
| 11:25:28 | rect0x51 | Maybe the an object with the {.union.} pragma? Is that type-checked to ensure the correct field is being used every time? |
| 11:26:14 | FromGitter | <alehander42> you are looking for case objects |
| 11:27:22 | FromGitter | <alehander42> probably |
| 11:27:43 | FromGitter | <alehander42> you can also use `{.union.}` |
| 11:28:14 | FromGitter | <alehander42> but people usually want algebraic types, if you really want exactly a union, `{.union.}` should generate it indeed |
| 11:28:32 | FromGitter | <alehander42> (case objects <=> algebraic types `{.union.}` union) |
| 11:29:15 | * | Ven`` joined #nim |
| 11:34:33 | * | rect0x51 quit (Ping timeout: 246 seconds) |
| 11:34:55 | * | rect0x51 joined #nim |
| 11:48:24 | rect0x51 | alehander42: Hmm, it seems algebraic data types is not Nim's strong point... For example: https://forum.nim-lang.org/t/904 Do you think Nim could benefit from an alternative implementation? Or are case objects good enough? |
| 12:00:10 | FromGitter | <alehander42> they are widely used, often one needs to tweak the `==` anyway, so this is not usually a problem in practice |
| 12:00:29 | FromGitter | <alehander42> however I think it's possible to write a more general `==` |
| 12:01:18 | FromGitter | <alehander42> i wouldn't work on another implementation, they are *the* adt construct |
| 12:02:47 | FromGitter | <alehander42> if you really want, you can open an issue for `==` specifically (keep in mind, you can also use pattern matching/`case` in most cases) |
| 12:04:49 | rect0x51 | It seems this is yet another case of <simple primitives> + <good macros>. But yes, maybe a good `==` is a good idea; maybe I'll work on it. |
| 12:05:07 | * | ChristianWitts quit (Ping timeout: 246 seconds) |
| 12:17:14 | * | Notkea quit (Read error: Connection reset by peer) |
| 12:17:44 | * | Notkea joined #nim |
| 13:01:15 | * | dddddd joined #nim |
| 13:15:56 | * | seni joined #nim |
| 14:15:18 | FromGitter | <alehander42> thanks! |
| 14:15:55 | FromGitter | <alehander42> make sure to check out https://github.com/andreaferretti/patty/ or https://github.com/alehander42/gara too: patty provides a `variantp` macro which generates a case object/==/$ etc |
| 14:16:09 | FromGitter | <alehander42> gara should eventually incorporate it too , but : TODO :( |
| 14:18:04 | FromDiscord_ | <DarkArctic> hey, so i had a question about how overload resolution works. i have a parameter that is an exact type match in my overloaded proc, but it still wants to use a generic proc. is that they expected want overload resolution works? i have an example in case i don't make sense: https://gist.github.com/mjcaley/695207ec3cdc70ade84c7d7715d83a8f |
| 14:24:07 | Araq | the spec agrees with you, it's a bug |
| 14:24:58 | Araq | but it's also bad style, use your own procs |
| 14:26:41 | * | btbytes joined #nim |
| 14:32:52 | * | MyMind joined #nim |
| 14:33:03 | * | Sembei quit (Ping timeout: 246 seconds) |
| 14:35:18 | * | Tyresc joined #nim |
| 14:37:46 | FromDiscord_ | <DarkArctic> ya that's what i decided to do in the end. i'll open an issue anyways. thanks! |
| 14:39:00 | * | Vladar quit (Remote host closed the connection) |
| 14:42:12 | Araq | thank you too |
| 14:44:53 | FromGitter | <alehander42> hm |
| 14:46:33 | Araq | alehander42: Code like 'if x < s.len and s[x]' doesn't work well with my approach, it's better to use a control flow graph |
| 14:46:40 | Araq | just fyi |
| 14:46:57 | FromGitter | <alehander42> i forgot what i wanted to say |
| 14:48:14 | FromGitter | <alehander42> in my nilcheck branch I think I deal with it without cfg, but it might seem a little non-elegant |
| 14:48:50 | Araq | with a cfg stuff like 'if x == nil: return' is more difficult to handle |
| 14:50:20 | Araq | and IMHO the algorithm should be smart enough so that the obvious cases "just work" |
| 14:51:03 | Araq | features are better when they are not annoying to use ;-) |
| 14:51:05 | FromGitter | <alehander42> basically i have a checkCondition which returns a new env and e.g. for Infix mAnd invokes checkCondition(n[1] .. originalEnv) ⏎ checkCondition(n[2] .. envAftern1) and returns the env after n[2] |
| 14:51:31 | FromGitter | <alehander42> so e.g. if not x.isNil and x.b: works |
| 14:54:23 | FromGitter | <alehander42> (because we do ⏎ originalEnv ⏎ if (not x.isNil and x.b): code=> ⏎ in originalEnv: not x.isNil => Env1: x {Safe} ⏎ in Env1: x.b => no change ... [https://gitter.im/nim-lang/Nim?at=5c2a2d9f2863d8612bb8d7dd] |
| 14:56:27 | FromGitter | <alehander42> so I think this should kinda work with bounds too: right sides of infix and would be checked in the env after their left side so x would be in {0 ..< s.len} ? |
| 14:57:43 | * | endragor joined #nim |
| 14:58:42 | Araq | you can always make it work without a cfg but with a cfg it's cleaner IMO |
| 14:59:43 | FromGitter | <alehander42> well it's several lines of mutual recursion, nothing too bad |
| 14:59:59 | FromGitter | <alehander42> i think the best thing about cfg is that usually you have less cases to deal with |
| 15:00:31 | Araq | yeah, you map all the syntactic artificial complexity to a condensed format |
| 15:00:37 | FromGitter | <alehander42> exactly |
| 15:00:50 | * | Ven` joined #nim |
| 15:01:18 | Araq | and I often wonder if macros would be better served with CFGs, not trees |
| 15:02:48 | FromGitter | <alehander42> CFG as input? |
| 15:03:19 | Araq | yeah as the IR everything uses |
| 15:04:21 | FromGitter | <alehander42> this would be a more confusing IR than the AST for the end user IMO |
| 15:04:46 | Araq | indeed |
| 15:05:05 | Araq | but you can offer a super powerful API for it, like "ensure for all paths" |
| 15:05:27 | FromGitter | <alehander42> well, I see it more like a complementary "level" for macros |
| 15:05:36 | FromGitter | <alehander42> in the same way one can have reader/tokenlevel macros |
| 15:05:44 | Araq | or "call stopProfile() for every possible exit" |
| 15:05:54 | FromGitter | <Clyybber> with CFG you mean context free language? |
| 15:06:03 | Araq | no "control flow graph" |
| 15:06:09 | FromGitter | <Clyybber> oh :D |
| 15:06:16 | FromGitter | <Clyybber> feel dumb now. |
| 15:07:12 | Araq | "every usage of 'x' need to be dominated by a definition of 'x'", lots of things that are better with a CFG |
| 15:07:16 | FromGitter | <alehander42> so e.g. you can have `macro a(b: <NimNode>)` `tokenmacro a(b: <seq[NimToken]>)` `cfgmacro a(b: <NimCFG>)` |
| 15:10:38 | Araq | 'tokenmacro' is a heresy |
| 15:11:10 | FromGitter | <alehander42> @Clyybber no, you're right, it's not nice that the abbreviations are the same, easy to confuse |
| 15:11:18 | Araq | and cfgmacro can actually be done in today's Nim but you need a toCfg and fromCfg operation |
| 15:11:20 | FromGitter | <alehander42> @Araq well, just giving it as a conceptual example |
| 15:11:23 | Araq | and fromCfg is hard |
| 15:12:26 | FromGitter | <alehander42> fromCfg(NimCfg) -> AST ? |
| 15:12:31 | Araq | yeah |
| 15:13:42 | FromGitter | <alehander42> why? isn't it possible to map it to a very simplistic ast with just if-s and simple statements |
| 15:14:22 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:14:23 | Araq | depends on what the CFG supports. remember that Nim has no 'goto' |
| 15:14:34 | FromGitter | <Clyybber> I guess a cfg would also make destructors more easy. One just checks that there is a post-dominator that destroys the variable. |
| 15:16:00 | Araq | Clybber: we use a CFG internally for destructors and moves ;-) |
| 15:16:06 | FromGitter | <Clyybber> Oh, nice |
| 15:16:19 | * | btbytes joined #nim |
| 15:16:52 | Araq | it's a 4 instruction CFG, it makes me proud |
| 15:17:10 | Araq | only has 'def, use, goto, fork' instructions |
| 15:17:45 | FromGitter | <Clyybber> what does fork do? |
| 15:17:48 | FromGitter | <alehander42> Araq, well, some goto-like patterns can be mapped to higher level loops |
| 15:18:31 | Araq | fork L1 # goto L1 or the instruction following this 'fork' instruction |
| 15:19:09 | FromGitter | <alehander42> i think locally all? can be mapped to while .. continue # instead of goto and break in the end if goto is local to the function |
| 15:19:26 | FromGitter | <alehander42> but several labels might be less obvious |
| 15:19:30 | Araq | yeah you can do that, alehander42 but it's messy |
| 15:19:32 | FromGitter | <Clyybber> @Araq Thats really elegant |
| 15:19:42 | FromGitter | <Clyybber> Your CFG |
| 15:20:32 | Araq | alehander42: and what's the point, recomputing what the programmer already gave you for free |
| 15:20:47 | FromGitter | <alehander42> Araq, well that's life, you need a tradeoff |
| 15:21:05 | FromGitter | <alehander42> the other option is to somehow have special CFGonly ast nodes |
| 15:21:12 | FromGitter | <alehander42> but this would complicate the other passes? |
| 15:21:35 | Araq | we have these btw, they are undocumented and most passes ignore their existance |
| 15:21:44 | Araq | nkGotoState and friends |
| 15:21:58 | Araq | required for the iterator transformations |
| 15:23:56 | * | vivus joined #nim |
| 15:24:09 | * | Vladar joined #nim |
| 15:27:21 | FromGitter | <alehander42> that is true |
| 15:27:37 | FromGitter | <alehander42> but doesn't this break iterators? the fact that passes don't deal with them |
| 15:33:15 | Araq | usually the math works out, nkGotoState doesn't invalidate the facts you would derive from the AST's control flow otherwise |
| 15:34:01 | Araq | but tbh that is mostly wishful thinking, need to think it through |
| 15:34:30 | Araq | but most passes run before the lowerings to nkGotoState happen |
| 15:37:58 | * | ChristianWitts joined #nim |
| 15:39:37 | FromGitter | <alehander42> and btw why do you dislike reader macros so much |
| 15:40:01 | Araq | because in triple quoted strings they don't mess up the highlighters |
| 15:40:26 | Araq | and a lot of effort went into Nim's parser and syntax for better or worse |
| 15:40:53 | Araq | I don't want to use your lispy DSL that you felt like writing ;-) |
| 15:43:17 | * | hoijui quit (Read error: Connection reset by peer) |
| 15:47:00 | rect0x51 | So is this CFG interesting mostly for destructors? Or does it serve an even greater purpose? |
| 15:47:04 | FromGitter | <alehander42> fair enough |
| 15:49:37 | * | d10n-work joined #nim |
| 15:50:57 | * | endragor quit (Remote host closed the connection) |
| 15:51:43 | Araq | rect0x51, no. I will refine it though and use it for different things |
| 15:53:48 | rect0x51 | Araq: You seem pretty focused to the destructors idea, do you want to eventually make --newruntime the default? |
| 15:53:56 | rect0x51 | That would be awesome! |
| 15:54:28 | Araq | yes. That plan hasn't changed for quite some time now |
| 15:55:01 | rect0x51 | :) |
| 15:55:11 | Araq | the compiler itself will likely to use the GC for years to come though, but that doesn't affect much other Nim code |
| 15:56:17 | FromGitter | <alehander42> well, the stdlib has to work with the new runtime, I guess this would take some work |
| 15:58:56 | Araq | the stdlib doesn't use cyclic data structures |
| 15:59:01 | rect0x51 | From what I understand it will be very novel though... I mean the only similar thing happens in Rust, but this is far better since the compiler adapts to your code instead of you adapting (and having to explain stuff) to the compiler. I also believe it's worth it, keep up the good work! Anyway, I won't take up any more of your time, see you! |
| 15:59:18 | Araq | thanks :-) |
| 16:01:31 | * | rect0x51 quit (Quit: WeeChat 2.3) |
| 16:25:16 | * | Ven` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:25:43 | * | thomasross quit (Remote host closed the connection) |
| 16:26:04 | * | thomasross joined #nim |
| 16:27:40 | * | ChristianWitts quit (Ping timeout: 272 seconds) |
| 16:29:22 | * | rokups quit (Quit: Connection closed for inactivity) |
| 16:49:35 | * | shashlick joined #nim |
| 16:52:05 | * | ChristianWitts joined #nim |
| 17:06:38 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 17:40:03 | * | Ven`` quit (Ping timeout: 268 seconds) |
| 17:40:42 | * | xet7 joined #nim |
| 17:44:23 | * | NimBot joined #nim |
| 17:48:02 | * | seni quit (Quit: Leaving) |
| 18:12:03 | FromGitter | <Clyybber> Araq: Is your move optimizer ready? |
| 18:15:36 | Araq | Clyybber: it's pretty stable afaik |
| 18:16:07 | Araq | http://nim-lang.org/download/nim-0.19.2.tar.xz please test |
| 18:16:37 | Araq | https://nim-lang.org/download/nim-0.19.2-x32.zip |
| 18:16:41 | Araq | https://nim-lang.org/download/nim-0.19.2-x64.zip |
| 18:16:56 | FromGitter | <Clyybber> I'm on devel. |
| 18:17:02 | shashlick | Awesome |
| 18:17:08 | shashlick | Will update and try out |
| 18:17:23 | Araq | still dealing with the website updates |
| 18:17:24 | FromGitter | <Clyybber> Araq: So https://github.com/nim-lang/Nim/pull/9340 can be merged now? |
| 18:17:39 | Araq | nah :-) |
| 18:18:09 | Araq | yeah well, the thing is: The move "optimizer" currently only works for user defined =sink |
| 18:18:38 | Araq | but it's REALLY not far away.... |
| 18:18:41 | Araq | :P |
| 18:18:50 | FromGitter | <Clyybber> Nice :D |
| 18:19:11 | Araq | btw it's not an optimizer, its required by the spec... C++17 style |
| 18:20:36 | FromGitter | <Clyybber> So https://github.com/nim-lang/Nim/issues/2314 is gonna be solved soon? |
| 18:22:42 | Araq | yup |
| 18:23:09 | Araq | yay, stuff that we add actually improves the language. |
| 18:26:33 | narimiran | oooh, 0.19.2 is here! nice! |
| 18:26:56 | * | Ven`` joined #nim |
| 18:27:02 | narimiran | Araq: if you don't mention that 0.19.2 is anagram for 2019, i will be very disappointed!! :) |
| 18:28:26 | shashlick | So is it fair to stop testing 0.18.0 and treat stable - 1 as 0.19.0? Or should we test 0.18.0 and 0.19.2 |
| 18:29:09 | ldlework | narimiran: hehe |
| 18:29:16 | Araq | I would test 0.19.2 and 0.18.0 until 0.18 becomes a burden |
| 18:29:36 | Araq | no need to throw it out just yet, but also no need to keep maintaining it |
| 18:30:05 | shashlick | sounds good |
| 18:30:21 | shashlick | I'd go even older if testing was faster |
| 18:30:48 | Calinou | is there a stdlib method to get a file's basename (i.e. stripped from its directory path)? |
| 18:31:05 | shashlick | extractFilename I think |
| 18:31:15 | Calinou | I found it, thanks |
| 18:31:19 | Calinou | I was looking in the wrong module :) |
| 18:33:37 | * | vivus quit (Remote host closed the connection) |
| 18:36:05 | Calinou | "Splits a filename into (dir, filename, extension). dir does not end in DirSep. extension includes the leading dot." |
| 18:36:16 | Calinou | looks like it should be "name", not "filename" (on 0.19.0) |
| 18:36:27 | Calinou | otherwise I get a build error as filename can't be found in the tuple |
| 18:36:34 | shashlick | ok both nimgen and nimterop now test 0.19.2 |
| 18:36:35 | Araq | interesting |
| 18:42:11 | * | kapil____ joined #nim |
| 18:43:57 | FromGitter | <Clyybber> Araq: Do you have an idea on how to solve https://github.com/nim-lang/Nim/issues/4774 ? |
| 18:47:26 | Araq | Clyybber: no idea, I would simply tinker with the compiler until it "sort of" works and let the CIs ensure correctness. |
| 18:47:41 | Araq | yeah, correctness by testing, sue me |
| 18:48:03 | FromGitter | <Clyybber> ** test driven development ** |
| 18:48:12 | FromGitter | <Clyybber> at its best :P |
| 18:49:04 | * | nc-x joined #nim |
| 18:49:48 | nc-x | araq: i can fix it by removing this early return https://github.com/nim-lang/Nim/blob/ab72d68ec80300ebd0629c5174a78c73f28fc729/compiler/semexprs.nim#L407-L409 |
| 18:50:06 | nc-x | but then the mentioned bug T is void will or |
| 18:50:10 | nc-x | *occur |
| 18:50:13 | nc-x | whatever that ii |
| 18:50:16 | nc-x | *is |
| 18:50:37 | nc-x | the only way i see forward is to fix the T is void bug differently |
| 18:50:43 | Araq | the void type is motivated by this example: |
| 18:51:15 | Araq | Table[T, void] is usually a nice implementation of Set[T] |
| 18:51:45 | Araq | that means void fields in objects should be valid but have no runtime representation, they should be optimized out |
| 18:52:10 | Araq | how much you need to do |
| 18:52:14 | FromGitter | <zacharycarter> @Clyybber - the pbr rendering related code is getting quite large - https://github.com/zacharycarter/zeal/tree/master/src/zealpkg |
| 18:52:32 | Araq | when T isnot void: field: T in object decls I cannot remember |
| 18:52:46 | Araq | pbr? |
| 18:52:49 | FromGitter | <Clyybber> Araq: https://github.com/nim-lang/Nim/issues/9825 is not a showstopper anymore I guess. And I assume deech's observation is just due to the compiler being smart? |
| 18:52:53 | nc-x | okay so i get it now. but what is this doing https://github.com/nim-lang/Nim/blob/ab72d68ec80300ebd0629c5174a78c73f28fc729/compiler/semexprs.nim#L407-L409 |
| 18:52:56 | FromGitter | <Clyybber> Araq: Physicall based rendering |
| 18:53:38 | nc-x | zacharycarter: nice |
| 18:53:43 | FromGitter | <zacharycarter> thanks |
| 18:54:00 | FromGitter | <zacharycarter> https://github.com/zacharycarter/zeal/blob/master/src/zealpkg/pipeline.nim#L40 |
| 18:54:26 | FromGitter | <zacharycarter> is the pipeline building procedure - and this is where most of the work has been put into |
| 18:54:53 | FromGitter | <zacharycarter> all of these steps - but I imagine I still have several weeks of coding ahead of me before I will have something finished - maybe less, but there is a ton of implementation left to do still |
| 18:54:54 | nc-x | clyybber: that issue makes me remember that i wanted to ask Araq if the gc:v2 not working issue should be considered a priority for v1 or not |
| 18:54:56 | FromGitter | <Clyybber> @zacharycarter Nice, thats neatly organized |
| 18:55:27 | FromGitter | <zacharycarter> thanks - I hope to do a better job and not have a engine_types module - but for now it works |
| 18:55:41 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:56:13 | FromGitter | <Clyybber> nc-x: gc:v2 is supposed to replace the current default in the future, right? |
| 18:56:33 | Araq | no, gc:v2 is abandoned |
| 18:56:38 | nc-x | idk, but it has not been working since a very long time |
| 18:56:38 | FromGitter | <Clyybber> Oh |
| 18:56:59 | nc-x | remove/deprecate the switch and close the issue then? |
| 18:57:21 | Araq | yeah. but don't remove gc2.nim please |
| 18:58:26 | nc-x | Okay. I will send the PR tomorrow if I get time. Or if someone else wants to do it, they can. |
| 18:59:40 | * | ChristianWitts quit (Ping timeout: 272 seconds) |
| 19:00:36 | FromGitter | <Clyybber> @zacharycarter meanwhile my pipline creation looks like this: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ :P [https://gitter.im/nim-lang/Nim?at=5c2a675437975e7ca952a542] |
| 19:01:06 | FromGitter | <zacharycarter> hehe |
| 19:01:38 | FromGitter | <Clyybber> And I have to create a pipeline layout firsts :D |
| 19:01:47 | FromGitter | <Clyybber> and a renderpass |
| 19:01:59 | FromGitter | <Clyybber> tho tbf the code for that is fairly small |
| 19:02:08 | FromGitter | <Clyybber> but vulkan code really is verbose af |
| 19:02:09 | FromGitter | <zacharycarter> yeah - I have barely started on render pass code |
| 19:02:17 | FromGitter | <zacharycarter> Vulkan is, for sure |
| 19:02:24 | FromGitter | <Clyybber> me neither, but my renderpass is pretty simple |
| 19:02:28 | narimiran | time to do my relationship-duties and go to a new year "party". see you guys next year :) |
| 19:02:37 | FromGitter | <Clyybber> see ya |
| 19:02:45 | FromGitter | <zacharycarter> happy new year narimiran! have fun! |
| 19:02:50 | FromGitter | <Clyybber> happy new year |
| 19:02:55 | FromGitter | <zacharycarter> be safe! |
| 19:03:57 | FromGitter | <Clyybber> gotta search for my cat, because shes scared af from all the boom |
| 19:04:48 | FromGitter | <zacharycarter> oophh - that hasn't started here yet |
| 19:04:53 | Calinou | how do I get the stdout from a process started with osproc.startProcess()? |
| 19:04:55 | FromGitter | <zacharycarter> but I know the dogs are going to go nutso |
| 19:05:01 | Calinou | (execProcess() starts a shell, so I'd rather avoid it if possible) |
| 19:05:07 | * | nc-x quit (Ping timeout: 256 seconds) |
| 19:05:08 | FromGitter | <Clyybber> its started two days ago in my neighbourhood :P |
| 19:05:18 | FromGitter | <Clyybber> but now its getting pretty loud |
| 19:05:28 | Calinou | I have yet to hear fireworks here |
| 19:05:39 | FromGitter | <Clyybber> but ill restrain myself from shooting fireworks till its midnight |
| 19:07:04 | * | narimiran quit (Remote host closed the connection) |
| 19:07:08 | FromGitter | <zacharycarter> well I know for a fact my dog is going to be hating life soon - because my mom brought a bunch down with her their house at the beach, which I'm staying at for the holiday |
| 19:07:23 | FromGitter | <zacharycarter> her dog doesn't like them either - not sure why she insists |
| 19:07:34 | * | zachk joined #nim |
| 19:07:35 | FromGitter | <zacharycarter> either way - it looks like we'll be blowing shit up tonight |
| 19:07:41 | Calinou | I found https://github.com/nim-lang/Nim/issues/7999 from a quick search |
| 19:07:44 | FromGitter | <zacharycarter> tis the American way |
| 19:07:59 | Calinou | shooting fireworks is an easy way to lose fingers, beware |
| 19:08:05 | Araq | "kref_put - decrement refcount for object." |
| 19:08:08 | Calinou | and keep in mind particles can be dangerous if you have asthma too |
| 19:08:19 | FromGitter | <zacharycarter> we rig them up with safety fuse first |
| 19:08:35 | Araq | „@release: pointer to the function that will clean up the object when the |
| 19:08:35 | Araq | last reference to the object is released. |
| 19:08:35 | Araq | This pointer is required, and it is not acceptable to pass kfree |
| 19:08:37 | Araq | in as this function. If the caller does pass kfree to this |
| 19:08:39 | Araq | function, you will be publicly mocked mercilessly by the kref |
| 19:08:41 | Araq | maintainer, and anyone else who happens to notice it. You have |
| 19:08:43 | Araq | been warned.“ |
| 19:09:03 | Araq | ^ put to decref an RC. But omg operator overloading is sooooooo baddddd |
| 19:09:26 | Araq | and **why** can't I pass kfree as the 'release' parameter. |
| 19:10:47 | Araq | why is the correlation between "Unix hacker" and "dyslexic" so high... |
| 19:11:00 | FromGitter | <Clyybber> hahaha :D |
| 19:12:12 | FromGitter | <Clyybber> Calinou: Those rome fires (dunno if thats how they are called), you can hold in your hand. |
| 19:13:40 | FromGitter | <Clyybber> you can do pretty cool fights with them. |
| 19:14:00 | FromGitter | <Clyybber> even better when alternative ammo is snow, but it didn't snow here |
| 19:17:16 | * | rect0x51 joined #nim |
| 19:17:29 | FromGitter | <zacharycarter> roman candles haha |
| 19:17:44 | FromGitter | <Clyybber> Ah yeah, thats how they are called |
| 19:17:45 | FromGitter | <zacharycarter> we used to strap them to the top of remote control trucks and have battles with them |
| 19:17:50 | FromGitter | <zacharycarter> try to shoot each other with them |
| 19:17:57 | FromGitter | <Clyybber> its f ing fun |
| 19:18:01 | FromGitter | <zacharycarter> agreed |
| 19:18:23 | FromGitter | <Clyybber> modern reenactment of harry potter |
| 19:19:13 | * | Ven`` quit (Ping timeout: 245 seconds) |
| 19:20:27 | shashlick | @zacharycarter: now that you are back with nim, what are you doing for an extension language |
| 19:23:14 | Calinou | anyway, I finished porting my small Python script to Nim |
| 19:23:39 | * | btbytes joined #nim |
| 19:24:12 | Calinou | Python: https://gist.github.com/Calinou/3fab908ea02439a3c7c469cc351a471d |
| 19:24:12 | Calinou | Nim: https://gist.github.com/Calinou/51080f331d3d1836f01db1b686b1bac2 |
| 19:24:27 | Calinou | any idea how it could be made shorter/better? It'll fail silently if ImageMagick reports an error due to how I used startProcess() |
| 19:24:45 | Calinou | (it seems using the poUsePath property uses a shell anyway, so my initial goal is moot) |
| 19:25:09 | Calinou | (how do I avoid shell injection in this case?) |
| 19:27:08 | rect0x51 | does NimScript use a VM? |
| 19:27:18 | FromGitter | <Clyybber> Yes |
| 19:27:26 | rect0x51 | Oh, that's awesome!! |
| 19:27:34 | FromGitter | <Clyybber> Araq: https://github.com/nim-lang/Nim/issues/9825 seems to be fixed |
| 19:28:13 | Araq | shashlick: I thought about it and I think we can give 'nim e' more operations like stdin.readline quite easily |
| 19:28:32 | Araq | without making it available for compile-time code |
| 19:29:52 | shashlick | that will be cool, right now, all options to use nim as is come to a dead end |
| 19:31:54 | * | kungtotte quit (Remote host closed the connection) |
| 19:32:08 | shashlick | i can agree that compiler shouldn't sit and wait for stdin but i can think of many cool things that would be possible if we allowed more capabilities in the VM |
| 19:32:37 | FromGitter | <Varriount> Araq: Hm, I've been reading that GC paper. The theory looks correct, however the overhead is quite expensive - three counters and two booleans for each object, and two booleans for each reference. |
| 19:32:54 | shashlick | plus if you were considering ffi at some point, that means you are cool making the VM more capable in some sense |
| 19:33:40 | Araq | hey, "dead end" is a strong word, compiler as an API is pretty slick IMO |
| 19:33:54 | Araq | though I can understand you want to avoid it |
| 19:34:18 | rect0x51 | Araq: You really meant what you answered me in forum... about Nim adressing those who want to use 1 language for EVERYTHING. I love it! |
| 19:34:41 | shashlick | i think that's mainly cause I am a Nim dev and already have Nim installed |
| 19:35:02 | shashlick | but in general, i want to build an infrastructure that allows any scripting language to interact with the editor |
| 19:35:08 | shashlick | like weechat |
| 19:35:43 | shashlick | stdin/out is simple but ugly nonetheless |
| 19:36:02 | shashlick | i'd go with an ipc option but nimscript cannot do any such thing |
| 19:36:35 | * | kungtotte joined #nim |
| 19:38:09 | FromGitter | <zacharycarter> shashlick: I don't have one - I'm hedging my bets on HCR eventually arriving for Nim |
| 19:38:35 | FromGitter | <Varriount> @zacharycarter HCR? |
| 19:38:39 | FromGitter | <zacharycarter> hot code reloading |
| 19:39:16 | FromGitter | <zacharycarter> if HCR does not arrive - I suppose luajit is the best we will get |
| 19:39:19 | Araq | HCR is one thing, incremental compilation another |
| 19:39:27 | FromGitter | <Varriount> Oh, that thing that's really tricky to do in non-interpreted languages. |
| 19:39:35 | Araq | and IC is coming |
| 19:39:41 | FromGitter | <zacharycarter> well - there's a grant that's WIP for it |
| 19:39:55 | Araq | indeed but I don't know its current state |
| 19:39:55 | FromGitter | <zacharycarter> https://github.com/nim-lang/Nim/issues/8927 |
| 19:40:11 | FromGitter | <zacharycarter> it seems like he's made a lot of progress |
| 19:40:12 | Araq | zahary said milestone one will be reached which iirc |
| 19:40:25 | Araq | means most of what people want will be there |
| 19:40:33 | FromGitter | <zacharycarter> works for me |
| 19:43:07 | FromGitter | <Clyybber> @zacharycarter Luajit is crazy |
| 19:43:18 | FromGitter | <zacharycarter> yeah it is - wonderful project |
| 19:43:21 | FromGitter | <Clyybber> crazy good, but also crazy impossible to understand |
| 19:43:49 | FromGitter | <Clyybber> also Mike Pall is not actively working on it anymore |
| 19:43:59 | FromGitter | <zacharycarter> yeah - heard about that |
| 19:44:11 | FromGitter | <Clyybber> @zacharycarter Raptorjit is promising though |
| 19:44:15 | FromGitter | <zacharycarter> still probably the best option |
| 19:44:21 | FromGitter | <Clyybber> Its basically luajit cleaned up |
| 19:44:36 | FromGitter | <Clyybber> and only for x86_64 |
| 19:44:44 | FromGitter | <zacharycarter> ah |
| 19:44:55 | FromGitter | <Clyybber> The main dev is currently in the process of rewriting the VM in C |
| 19:45:10 | FromGitter | <Clyybber> and making it 96 bit in the process |
| 19:45:22 | Araq | 96bit? |
| 19:47:05 | FromGitter | <Clyybber> https://github.com/raptorjit/raptorjit/pull/199 |
| 19:50:06 | rect0x51 | what is special about luajit/raptorjit, compared to other JIT-compilers? (if that's an easy question...) |
| 19:50:26 | FromGitter | <Clyybber> Araq: Its 32 bit type info, and 64 bit value |
| 19:50:46 | FromGitter | <Clyybber> rect0x51: Its fast as fuck |
| 19:51:20 | FromGitter | <Clyybber> Also luajit has parts that are incomprehensibe for normal mortal beings |
| 19:51:26 | rect0x51 | Clyybber: :D that covers it in 4 words |
| 19:51:38 | FromGitter | <Clyybber> :D |
| 19:52:07 | rect0x51 | btw thinking of new year, when is Nim's anniversary? also stupid question but... does the crown symbolizes something particular? |
| 19:53:50 | Araq | I looked at luajit fwiw |
| 19:54:10 | Araq | but it's incomprehensible, mostly because I don't understand the entry points |
| 19:55:34 | shashlick | Araq: let me know how to do the stdin piece and i'll create a PR |
| 19:56:42 | Zevv | I've hear Mike Pall is actually a robot from outer space. |
| 19:57:11 | Araq | I've heard he is a team of people |
| 19:57:12 | FromGitter | <Clyybber> You are correct! |
| 19:57:24 | FromGitter | <Clyybber> Oh, I dunno about a team of people |
| 19:57:32 | FromGitter | <Clyybber> but he certainly is a robot |
| 19:58:08 | Zevv | he came from the same solar system as Fabrice Bellard |
| 19:58:12 | FromGitter | <Clyybber> unfortunately a robot which ran out of sponsorships |
| 19:58:18 | Zevv | hhaha |
| 19:59:45 | FromGitter | <Clyybber> And this bad boy is responsible for `nim c -r` |
| 20:01:48 | FromGitter | <Clyybber> https://github.com/LuaJIT/LuaJIT/issues/45 |
| 20:03:11 | shashlick | Araq: git ls-remote https://github.com/nim-lang/Nim version-0-19-2 is not working |
| 20:03:51 | shashlick | was version-0-19 the 0.19.2 branch? |
| 20:04:03 | shashlick | i think that's what @kaushalmodi was testing in nightlies, along with devel |
| 20:05:19 | rect0x51 | Clyybber: HAHAHHAHAHAHAHA!! |
| 20:07:10 | deansher | rect0x51: Presumably the crown is from Nim's original name, Nimrod -- a biblical king |
| 20:08:58 | rect0x51 | deansher: ohh, I forgot to lookup the meaning of the old name, (facepalm) this was so obvious! |
| 20:09:37 | deansher | 🙂 |
| 20:16:24 | rect0x51 | Have to go, happy new year to you all! |
| 20:19:33 | shashlick | why is nightlies PR not testing travis? https://github.com/nim-lang/nightlies/pull/11 |
| 20:19:51 | * | rect0x51 quit (Quit: WeeChat 2.3) |
| 20:20:04 | FromGitter | <Clyybber> Happy new year |
| 20:21:52 | shashlick | my fault, never mind |
| 20:35:39 | * | btbytes quit (Quit: Textual IRC Client: www.textualapp.com) |
| 20:43:46 | shashlick | looks like appveyor is broken on nightlies - is there any intention of getting it working or is it unnecessary? |
| 20:50:54 | Araq | we want to fix travis to build the windows zips |
| 20:58:25 | * | Jesin quit (Quit: Leaving) |
| 21:08:00 | * | natrys joined #nim |
| 21:08:21 | * | Senketsu joined #nim |
| 21:11:44 | * | Jesin joined #nim |
| 21:23:11 | * | Snircle joined #nim |
| 21:31:11 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 21:51:49 | shashlick | i am working on it |
| 22:19:36 | shashlick | just installing 0.19.2 locally - great day today, first sustaining release for Nim |
| 22:20:03 | shashlick | tell all your friends who keep asking for stability or 1.0 |
| 22:20:37 | Araq | we had bugfix releases in the past though |
| 22:20:38 | * | kapil____ joined #nim |
| 22:20:47 | Araq | but thank you for the kind words :-) |
| 22:20:58 | shashlick | but those were still just devel right |
| 22:21:43 | Araq | right but it's unclear how far we will keep the 0-19 line |
| 22:22:07 | Araq | as I said, ideally the 0-20 line will become v1 |
| 22:22:20 | shashlick | doesn't matter - we now have a way to keep devel moving while providing stability |
| 22:23:11 | Araq | the cherrypicking works ok, we'll ask Narimiran in a couple of months |
| 22:23:25 | Araq | what he thinks. he is doing the work, after all |
| 22:23:38 | shashlick | no doubt, big hat tip for his hard work |
| 22:24:15 | Araq | but yeah, we didn't do this before, that's new. |
| 22:24:27 | Araq | and it's also what Python does. |
| 22:25:13 | shashlick | so do you still need appveyor in nightlies? now that travis has windows also |
| 22:26:27 | Araq | no, as I said |
| 22:26:35 | Araq | we try to make travis win work instead |
| 22:26:49 | Araq | however, producing both 32 and 64 bit variants is a challenge, I guess |
| 22:27:29 | shashlick | could be done with a matrix i guess |
| 22:32:09 | shashlick | ok, the pcre64.dll issue is fixed i think |
| 22:32:37 | shashlick | let's see if it goes all the way thru |
| 22:37:26 | shashlick | Araq: what's the deal with testing 0.19.2 in nightlies? can we turn that off now that it has been released? or will we continue on for 0.19.3 |
| 22:37:57 | Araq | 0.19 is a branch, maybe we'll have 0.19.4 |
| 22:38:06 | Araq | leave it on please |
| 22:38:16 | shashlick | ok cause the code doesn't do anything once it builds |
| 22:38:36 | shashlick | https://travis-ci.org/nim-lang/nightlies/jobs/473958567 |
| 22:38:53 | Araq | ideally we port much of this to Nim and make travis run a Nim program |
| 22:39:11 | Araq | because this is untestable and unmaintainable |
| 22:39:30 | Araq | bash commands in a yaml file, fuck me |
| 22:39:36 | shashlick | 🙂 |
| 22:40:00 | shashlick | windows build failed for another reason - https://api.travis-ci.org/v3/job/473958564/log.txt |
| 22:40:54 | shashlick | probably cause koch tools wasn't run so nimble never got checked out |
| 22:43:23 | shashlick | can you accept my PR? then I can continue on to fix the next issue in a separate PR |
| 22:43:30 | shashlick | or perhaps give me access so that i can continue working on this |
| 22:44:17 | * | Vladar quit (Remote host closed the connection) |
| 22:45:30 | Araq | sure thing, one sec |
| 22:46:04 | shashlick | so what's the goal of nightlies? to do a full nim build + csources, docs and winrelease/xz |
| 22:46:09 | shashlick | then upload to github |
| 22:50:55 | Araq | yeah but csources is not required |
| 22:51:28 | Araq | what's your github account again? genocide ? |
| 22:51:31 | shashlick | well, you need csources to build nim |
| 22:51:33 | shashlick | haha genotrance |
| 22:51:39 | Araq | lol |
| 22:51:41 | Araq | sorry |
| 22:51:44 | shashlick | np |
| 22:52:49 | Araq | HAPPY NEW YEAR! |
| 22:52:51 | Araq | bbs |
| 23:01:44 | * | stefanos82 quit (Remote host closed the connection) |
| 23:05:47 | FromGitter | <alehander42> маожаожаож |
| 23:29:01 | * | nsf quit (Quit: WeeChat 2.3) |
| 23:45:22 | * | xet7 quit (Remote host closed the connection) |
| 23:48:13 | * | gangstacat quit (Remote host closed the connection) |
| 23:56:00 | * | natrys quit (Quit: natrys) |
| 23:59:32 | Araq | shashlick: still awake? |