00:03:09 | * | laaron quit (Remote host closed the connection) |
00:06:06 | * | laaron joined #nim |
00:18:34 | * | laaron quit (Remote host closed the connection) |
00:20:27 | * | lobo_ joined #nim |
00:22:28 | * | laaron joined #nim |
00:28:42 | * | lobo_ quit (Remote host closed the connection) |
00:30:21 | * | laaron quit (Remote host closed the connection) |
00:34:59 | * | laaron joined #nim |
00:50:43 | * | exelotl_ quit (Ping timeout: 245 seconds) |
00:55:19 | * | laaron quit (Remote host closed the connection) |
00:57:32 | * | laaron joined #nim |
01:01:29 | * | abm quit (Quit: Leaving) |
01:47:15 | * | lritter quit (Ping timeout: 240 seconds) |
01:56:56 | * | ng0_ joined #nim |
01:58:15 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
01:59:52 | * | ng0 quit (Ping timeout: 260 seconds) |
02:01:04 | * | laaron joined #nim |
02:17:15 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
02:19:29 | * | laaron joined #nim |
02:26:01 | * | endragor joined #nim |
02:31:13 | * | endragor quit (Remote host closed the connection) |
02:41:14 | * | endragor joined #nim |
02:48:32 | * | endragor quit (Remote host closed the connection) |
02:53:14 | * | tobbez joined #nim |
02:53:49 | * | endragor joined #nim |
02:54:27 | * | treeform quit (Remote host closed the connection) |
02:58:08 | * | navin joined #nim |
03:00:22 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
03:01:18 | * | laaron joined #nim |
03:01:23 | * | endragor quit (Remote host closed the connection) |
03:02:41 | * | navin quit (Ping timeout: 250 seconds) |
03:05:18 | * | chemist69 quit (Ping timeout: 245 seconds) |
03:07:31 | * | chemist69 joined #nim |
03:59:14 | * | theelous3 quit (Ping timeout: 240 seconds) |
04:04:26 | * | chemist69 quit (Ping timeout: 276 seconds) |
04:05:43 | * | chemist69 joined #nim |
04:20:23 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
04:21:14 | * | laaron joined #nim |
04:30:59 | * | laaron quit (Remote host closed the connection) |
04:33:55 | * | laaron joined #nim |
04:43:38 | * | endragor joined #nim |
04:43:51 | * | endragor quit (Remote host closed the connection) |
04:48:13 | * | narimiran joined #nim |
05:21:04 | * | Romanson joined #nim |
05:39:20 | * | dddddd quit (Remote host closed the connection) |
06:07:22 | * | navin joined #nim |
06:11:33 | * | navin quit (Ping timeout: 245 seconds) |
06:18:16 | * | solitudesf joined #nim |
06:19:12 | * | Jjp137 quit (Read error: Connection reset by peer) |
06:50:47 | * | ng0_ is now known as ng0 |
07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
07:04:16 | * | gmpreussner joined #nim |
07:36:03 | * | nsf joined #nim |
08:16:10 | * | Jjp137 joined #nim |
08:24:24 | * | Jjp137 quit (Read error: Connection reset by peer) |
08:24:26 | * | solitudesf quit (Ping timeout: 276 seconds) |
08:51:25 | * | Vladar joined #nim |
08:52:18 | * | navin joined #nim |
08:54:33 | * | navin quit (Remote host closed the connection) |
08:54:59 | * | navin joined #nim |
08:55:43 | * | Romanson quit (Quit: Connection closed for inactivity) |
08:57:50 | * | navin_ joined #nim |
09:00:11 | * | navin quit (Ping timeout: 276 seconds) |
09:06:30 | * | navin joined #nim |
09:09:32 | * | PMunch joined #nim |
09:10:09 | * | navin_ quit (Ping timeout: 250 seconds) |
09:14:54 | * | navin quit (Remote host closed the connection) |
09:18:25 | * | Trustable joined #nim |
09:18:39 | * | navin joined #nim |
09:22:19 | Araq | dom96: please review https://github.com/nim-lang/Nim/pull/12221 |
09:23:23 | * | navin quit (Remote host closed the connection) |
09:38:31 | dom96 | will do |
09:39:07 | * | navin joined #nim |
09:43:38 | * | navin quit (Ping timeout: 245 seconds) |
09:53:48 | * | krux02 joined #nim |
10:02:58 | dom96 | Araq, done |
10:03:00 | dom96 | got anything else? |
10:06:04 | * | Ven`` joined #nim |
10:07:31 | dom96 | disruptek: you around? |
10:12:07 | PMunch | Thanks for the review dom96 added some comments |
10:13:43 | dom96 | PMunch, please join #fosdem19newerlangs |
10:18:15 | lqdev[m] | treeform: it's most likely the fact I'm a complete idiot and didn't do glyph rendering properly (I only render one subpixel offset, which is a bug on my side). that doesn't explain the weird space character size, though, which seems like a typesetting bug. also, I'm not dynamically linking to FT, it's a statically compiled nimterop-based wrapper. debug build size is 2.6 MB with freetype, 3.0 MB with typography. I haven't |
10:18:16 | lqdev[m] | checked with -d:release, but I compile my executable with --opt:speed so that should have -O3 optimization in gcc |
10:18:18 | PMunch | Oh woops |
10:20:09 | * | navin joined #nim |
10:23:09 | * | Jjp137 joined #nim |
10:24:28 | * | navin quit (Ping timeout: 245 seconds) |
10:34:42 | * | owl_000 joined #nim |
10:37:31 | * | nif quit (Quit: ...) |
10:37:41 | * | nif joined #nim |
10:40:39 | * | geko joined #nim |
10:41:11 | geko | hi |
10:41:17 | * | navin joined #nim |
10:42:12 | leorize | o/ |
10:42:32 | geko | i have a doubt |
10:44:14 | PMunch | A doubt of what? |
10:44:46 | geko | if my "case of" block is inside a "if" block |
10:45:29 | * | navin quit (Ping timeout: 250 seconds) |
10:45:48 | geko | and my "if" block allows only a particular values why does it still say else is required |
10:48:21 | PMunch | Because it doesn't check for that unfortunately |
10:49:03 | geko | will that be fixed for consistensy |
10:49:17 | * | elrood joined #nim |
10:49:26 | geko | or will it be made optional like modern pascal |
10:55:55 | lqdev[m] | what's the problem with adding an `else` branch to your `case` statement? |
10:57:18 | geko | if of covers all the cases why do i need an else |
10:58:31 | PMunch | But it doesn't cover all the cases |
10:58:31 | lqdev[m] | because the branch detection isn't so sophisticated to allow you to skip that `else` |
10:59:04 | lqdev[m] | I personally never found this to be a problem |
10:59:11 | PMunch | Hmm, what is this error when running ./koch boot: Error: undeclared identifier: 'delEnv' |
10:59:28 | PMunch | http://ix.io/1Wbf |
10:59:33 | lqdev[m] | looks like one of the features introduced in devel |
10:59:57 | PMunch | Well this is on my branch.. |
11:00:11 | lqdev[m] | from the changelog |
11:00:12 | lqdev[m] | > Added os.delEnv and nimscript.delEnv. (#11466) |
11:00:36 | PMunch | It built just fine yesterday.. |
11:02:49 | geko | https://play.nim-lang.org/#ix=1Wbh |
11:02:57 | PMunch | Ah.. Building koch in release mode made it work fine |
11:09:02 | * | endragor joined #nim |
11:10:11 | geko | PMunch it does cover all cases |
11:12:13 | PMunch | The case statement doesn't |
11:12:18 | narimiran | geko: `case` is not aware of your `if` outside of it |
11:12:21 | PMunch | And that is what's being checked |
11:13:29 | geko | so shouldn't this be improved |
11:14:15 | geko | isn't this an unnecessary else case |
11:16:03 | narimiran | PRs welcome :P |
11:16:06 | dom96 | geko, sure, it could be improved. But right now it doesn't rank high enough on our list of priorities. |
11:17:07 | geko | narimiran wish i could but i lack the knowledge. |
11:18:26 | * | PMunch quit (Remote host closed the connection) |
11:18:39 | geko | dom96 may be in the future, i kind of find it distracting/stuck |
11:20:09 | * | nif quit (Quit: ...) |
11:20:20 | * | nif_ joined #nim |
11:22:14 | * | narimiran quit (Ping timeout: 268 seconds) |
11:36:30 | * | geko quit (Remote host closed the connection) |
11:37:33 | * | clyybber joined #nim |
11:47:31 | * | endragor quit (Remote host closed the connection) |
11:49:16 | * | endragor joined #nim |
11:51:29 | * | clyybber quit (Quit: WeeChat 2.6) |
11:57:02 | * | elrood quit (Remote host closed the connection) |
12:02:16 | * | navin joined #nim |
12:03:54 | Zevv | geko: this kind of proving is something the Nim authors would love to add, but this is harder then it seems. Would you still expect the compiler to catch this case, for example? https://play.nim-lang.org/#ix=1WbO |
12:04:30 | Zevv | If yes, I can make up one that is a bit more convoluted, and if no, why not? |
12:04:52 | dom96 | Anyone have any Nimble wishes? I'm working on the new release |
12:05:26 | Zevv | oooh that's like asking if anyone wants candy, isn't it? |
12:08:57 | Zevv | well, related to spips discussion on the forum; I would appreciate having more info in the package description, especially a field for a more elaborate description. The current description is a one liner showing the highlihts, but having another field for something up to 200 words with more details would be very helpful. Somewhat like apt/dpkg I guess |
12:09:04 | * | endragor_ joined #nim |
12:09:28 | Zevv | and that is too many 'description' in one message |
12:12:32 | * | endragor quit (Ping timeout: 245 seconds) |
12:17:35 | navin | for ` nimble list` , if we can add different output listing format probably json/table/csv |
12:21:47 | dom96 | there is a PR open for that |
12:21:58 | Zevv | json wouldn't be too hard to do :) |
12:22:06 | dom96 | personally don't think more info is needed in packages.json |
12:22:36 | dom96 | anyway, do keep these ideas coming, i've gotta step out for a couple of hours :) |
12:23:06 | dom96 | if someone wants to help out, take a look at the issues and let me know which you've been personally affected: https://github.com/nim-lang/nimble/issues :) |
12:27:27 | * | ofelas quit (Quit: shutdown -h now) |
12:31:28 | * | Kaivo quit (Quit: WeeChat 2.6) |
12:32:56 | * | endragor_ quit (Remote host closed the connection) |
12:33:41 | * | sagax joined #nim |
12:34:53 | * | navin quit (Remote host closed the connection) |
12:36:39 | * | navin joined #nim |
12:37:04 | * | ofelas joined #nim |
12:39:49 | * | navin quit (Remote host closed the connection) |
12:41:54 | * | navin joined #nim |
12:46:17 | * | navin quit (Ping timeout: 245 seconds) |
12:51:00 | * | endragor joined #nim |
12:56:08 | * | endragor quit (Ping timeout: 276 seconds) |
12:56:27 | * | lritter joined #nim |
12:59:23 | * | owl_000 quit (Ping timeout: 276 seconds) |
13:01:21 | FromGitter | <mratsim> @dom96 task level dependencies |
13:01:41 | FromGitter | <mratsim> and also being able to pass flags like -d:foo to task |
13:02:05 | FromGitter | <mratsim> so I can do nimble --threads:on test |
13:02:51 | * | navin joined #nim |
13:07:11 | * | navin quit (Ping timeout: 250 seconds) |
13:09:34 | * | dddddd joined #nim |
13:17:03 | Zevv | and and and I want to be able to have multiple versions of the same package and specify which version to import in my code and and and |
13:17:13 | Zevv | I want a poooonyyyy |
13:20:42 | * | endragor joined #nim |
13:26:38 | * | endragor quit (Remote host closed the connection) |
13:30:40 | * | narimiran joined #nim |
13:32:25 | * | laaron quit (Remote host closed the connection) |
13:34:02 | * | laaron joined #nim |
13:40:54 | * | Hideki_ joined #nim |
13:59:08 | federico3 | https://github.com/nim-lang/Nim/issues/3063#event-2652025953 was this added to the docs? |
14:01:18 | * | Hideki_ quit (Remote host closed the connection) |
14:02:09 | * | Hideki_ joined #nim |
14:03:15 | * | owl_000 joined #nim |
14:03:38 | disruptek | dom96: in and out today. |
14:04:53 | * | owl joined #nim |
14:07:48 | * | owl_000 quit (Ping timeout: 245 seconds) |
14:10:41 | * | theelous3 joined #nim |
14:20:40 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
14:21:06 | * | ng0 joined #nim |
14:22:03 | * | ng0 quit (Client Quit) |
14:22:58 | * | ng0 joined #nim |
14:27:59 | * | Hideki_ quit (Remote host closed the connection) |
14:28:12 | * | endragor joined #nim |
14:29:08 | * | Hideki_ joined #nim |
14:29:09 | * | Hideki_ quit (Remote host closed the connection) |
14:29:26 | * | Hideki_ joined #nim |
14:29:44 | dom96 | mratsim: those might be tough to do in a day |
14:31:08 | FromGitter | <mratsim> @Zevv, here you go: https://pjreddie.com/static/Redmon%20Resume.pdf |
14:32:14 | FromGitter | <mratsim> I don't know how C++ devs can cope with C++ build times |
14:32:39 | FromGitter | <mratsim> I think it's a conspiracy from CircleCI, Travis, Azure Pipelines and Appveyor |
14:34:03 | * | endragor quit (Remote host closed the connection) |
14:38:27 | * | owl quit (Ping timeout: 240 seconds) |
14:44:25 | dom96 | shashlick, you around? |
14:55:37 | Zevv | why can this not be instantiated: `var seen: Table[(int,int)]` |
14:56:03 | Araq | because a table needs Key, Value types, not a single tuple type |
14:56:19 | Zevv | Oh daaaang I'm reading wrong |
14:56:20 | Zevv | pffff |
14:56:21 | Zevv | silly me |
14:56:51 | Zevv | the error message actually did make sense, even |
15:02:26 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
15:03:12 | * | ng0 joined #nim |
15:10:19 | * | Ven`` quit (Quit: Textual IRC Client: www.textualapp.com) |
15:13:37 | * | krux02 quit (Remote host closed the connection) |
15:17:40 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
15:30:14 | dom96 | Ahh, love cleaning out the Nimble issue tracker |
15:30:21 | dom96 | so many issues that can now be closed without any code changes |
15:39:47 | Zevv | how so? |
15:40:33 | dom96 | many which have been fixed or are so old that they aren't relevant anymore |
15:40:43 | Zevv | "wontfix" -> close :) |
15:41:17 | * | laaron quit (Remote host closed the connection) |
15:41:45 | dom96 | some of that too ;) |
15:42:20 | * | Kaivo joined #nim |
15:43:23 | * | laaron joined #nim |
15:44:46 | dom96 | wow, I must have been really tired in some of these |
15:44:55 | dom96 | Missed a word in my sentence in two separate comments |
15:45:18 | Zevv | well who cares if you miss a |
15:51:03 | * | PMunch joined #nim |
15:51:16 | dom96 | :) |
15:59:51 | PMunch | I see that the test I created failed because of some timing issues.. I tried to make it a bit more lenient now so it should pass :) |
16:00:04 | dom96 | It's still very risky |
16:00:31 | dom96 | the CI machines can sometimes be very slow, I would very much prefer a test whose success doesn't depend on timing |
16:03:18 | PMunch | Yeah, it's not the best. But the issue is timing related, so it's kinda hard to not have it timing dependent.. |
16:03:36 | * | solitudesf joined #nim |
16:04:05 | dom96 | I have a hunch that there is a way to achieve this without measuring time taken |
16:04:30 | federico3 | (...that's why people have dedicated bare-metal buildbots...) |
16:09:58 | PMunch | dom96, if you can think of something I'm all ears. Essentially the issue is that when a timer is registered to have expired it would keep the default timeout of 500ms when it was polling for other completed events. The only difference in execution is that 500ms extra delay before the timer fires. |
16:11:33 | Calinou | bare metal buildbots are expensive though |
16:12:46 | * | nc-x joined #nim |
16:12:47 | PMunch | Well, the test just failed again.. So it must definitely be solved somehow.. |
16:12:52 | dom96 | :) |
16:13:00 | nc-x | Can anybody reproduce https://github.com/nim-lang/nimble/issues/706? |
16:13:19 | * | nc-x quit (Remote host closed the connection) |
16:16:34 | dom96 | I just reproduced it :) |
16:18:40 | nc-x[m] | 👍🏻 |
16:19:30 | PMunch | This job can be aborted if anyone has the possibility to do so: https://ci.appveyor.com/project/dom96/nim/builds/27570866 |
16:20:48 | PMunch | Same with this: https://travis-ci.org/nim-lang/Nim/builds/587871996 |
16:21:55 | * | exelotl_ joined #nim |
16:23:57 | * | Hideki_ quit (Remote host closed the connection) |
16:25:17 | * | Hideki_ joined #nim |
16:29:38 | * | Hideki_ quit (Ping timeout: 240 seconds) |
16:30:25 | * | endragor joined #nim |
16:31:04 | * | Hideki_ joined #nim |
16:47:21 | * | narimiran_ joined #nim |
16:47:36 | * | narimiran quit (Ping timeout: 246 seconds) |
16:47:38 | * | thomasross quit (Ping timeout: 240 seconds) |
16:48:41 | * | NimBot joined #nim |
16:48:55 | Zevv | fake the lowest level os primitives so all layers above there can be tested |
16:50:04 | dom96 | Yeah, that would be the ideal way to test this but sounds like a challenge to implement all this |
16:50:13 | dom96 | So I've put 13 issues into this milestone: https://github.com/nim-lang/nimble/milestone/2 |
16:50:18 | dom96 | Might be too ambitious |
16:50:42 | * | thomasross joined #nim |
16:50:48 | Zevv | what timeframe are you thinking for those then? |
16:51:28 | PMunch | Yay, test passed now :) |
16:57:40 | dom96 | The rest of today :P |
16:58:01 | dom96 | and yeah, it is already 6pm... |
16:58:47 | * | endragor quit (Remote host closed the connection) |
17:00:11 | Zevv | oh I think I just found a bug. Doing nimble init, author and description don't get quoted in the .nimble |
17:00:21 | dom96 | that's been fixed |
17:00:25 | dom96 | update your nimble |
17:01:48 | Zevv | ah ok |
17:02:12 | Zevv | I just fixed that a second time :) |
17:02:40 | PMunch | Damn it, the travis test failed.. |
17:03:21 | PMunch | I can keep increasing the sleeps to the point where the test will take a long time to run |
17:03:30 | PMunch | But I'm not sure if that is really a good idea.. |
17:03:37 | PMunch | The test suite is slow enough as it is.. |
17:04:09 | FromGitter | <de-odex> hi, new to nim (and lower level languages in general) here |
17:04:47 | Araq | dom96: so tell me the nimble commit hash to use in koch |
17:04:51 | Araq | please |
17:05:13 | * | aEverr joined #nim |
17:06:45 | dom96 | Araq, it's not ready yet, I just posted a iist of issues I'd like to fix |
17:06:48 | dom96 | *list |
17:11:27 | * | narimiran_ is now known as narimiran |
17:12:03 | * | bozaloshtsh_ joined #nim |
17:13:06 | * | lmariscal8 joined #nim |
17:13:14 | * | CcxWrk quit (Killed (cherryh.freenode.net (Nickname regained by services))) |
17:13:14 | * | CcxWrk joined #nim |
17:13:16 | * | jonafato- joined #nim |
17:13:47 | * | solitudesf- joined #nim |
17:13:58 | nc-x[m] | any windows user have any opinion on https://github.com/nim-lang/nimble/issues/551 ? |
17:14:03 | * | nsf1 joined #nim |
17:14:38 | * | oprypin_ joined #nim |
17:14:50 | * | federico3_ joined #nim |
17:16:20 | * | Zevv_ joined #nim |
17:19:04 | * | ^GaveUp^ joined #nim |
17:19:12 | * | pydsigner_ joined #nim |
17:19:17 | * | Eyess joined #nim |
17:19:50 | * | Zevv_ quit (Client Quit) |
17:20:42 | * | solitudesf quit (*.net *.split) |
17:20:42 | * | dddddd quit (*.net *.split) |
17:20:42 | * | nsf quit (*.net *.split) |
17:20:43 | * | Zevv quit (*.net *.split) |
17:20:48 | * | lmariscal quit (*.net *.split) |
17:20:48 | * | tyler569 quit (*.net *.split) |
17:20:48 | * | GaveUp quit (*.net *.split) |
17:20:48 | * | oprypin quit (*.net *.split) |
17:20:48 | * | bozaloshtsh quit (*.net *.split) |
17:20:48 | * | SunDwarf quit (*.net *.split) |
17:20:48 | * | federico3 quit (*.net *.split) |
17:20:48 | * | pydsigner quit (*.net *.split) |
17:20:48 | * | jonafato quit (*.net *.split) |
17:20:50 | * | Zevv_ joined #nim |
17:21:02 | * | pydsigner_ is now known as pydsigner |
17:21:33 | * | Zevv_ is now known as Zevv |
17:22:35 | PMunch | Hi de-odex, welcome to Nim |
17:23:06 | PMunch | So dom96 what should I do with the test to get the PR accepted? |
17:23:14 | * | tyler569 joined #nim |
17:24:02 | * | dddddd joined #nim |
17:24:02 | * | Eyess quit (Ping timeout: 240 seconds) |
17:24:22 | dom96 | PMunch, make it not dependent on timing |
17:24:28 | dom96 | I don't know how to do it though I'm afraid |
17:24:33 | dom96 | I can't look at it now, busy with Nimble |
17:25:19 | PMunch | Well I don't know how to make it not dependent on timing since it's a timing related bug.. |
17:25:33 | * | SunDwarf joined #nim |
17:26:05 | FromGitter | <de-odex> question, is it possible to use quote do: with a body containing a template using varargs[string, `$`]? |
17:29:02 | Zevv | do-odex: did you try and ran into problems? |
17:29:07 | PMunch | Not entirely sure if I follow what you mean |
17:29:46 | dom96 | PMunch, you need to find a way to detect your changes are working without relying on timing |
17:29:55 | FromGitter | <de-odex> quote do would interpret the `$` as a variable in the macro |
17:30:05 | dom96 | maybe you can create a callback that sets some global flag in a specific order that tests your change |
17:30:18 | dom96 | (or a callback + timer, or multiple callbacks + timers) |
17:30:29 | PMunch | dom96, and since I'm writing my article series on async/multithreading/etc. in Nim I really want to have this fix in 1.0 so my examples makes sense.. |
17:31:40 | Zevv | de-odex: IIRC you can specify the quote character for a quote block |
17:32:09 | PMunch | Problem is that any timer that runs before the 500ms timeout will change the behavier of the timer and remove the bug |
17:33:01 | PMunch | Hence why the two middle test cases both return in 200ms and not one in 200ms and one it 500+ ms |
17:33:32 | FromGitter | <de-odex> Zevv, uh do you know how? |
17:33:38 | * | elrood joined #nim |
17:34:04 | Zevv | well, I'm trying :) The signature is proc quote(bl: typed; op = "``"). But I'm not sure how to pass `op` *after* the code block :/ |
17:34:07 | dom96 | PMunch, you can also try playing with making the `poll` timeout longer (it's 500ms by default) |
17:35:57 | PMunch | Yeah, I guess I could replace the waitFor with a manual loop with a longer timeout and then just check if the time is within a second or something silly like that |
17:36:25 | PMunch | And the test will still run fast if everything is working as it should |
17:38:18 | dom96 | you also don't need so many test cases, just the one will do |
17:41:20 | leorize | Zevv, @de-odex: quote do: <block> do: "quoting op" |
17:41:32 | Zevv | I did template myquote(bl: untyped): NimNode = quote(bl, "~~") |
17:41:54 | leorize | IIRC you can escape the quoting character |
17:42:18 | PMunch | Well they all test slightly different scenarios |
17:42:29 | PMunch | https://ci.appveyor.com/project/dom96/nim/builds/27571642 <- this can be cancelled |
17:42:33 | Zevv | leorize: i think I read somewhere that's not possible. We'll see who'se right :) |
17:42:55 | leorize | well that's how I do it in my code :P |
17:43:05 | Zevv | escaping the char? |
17:43:07 | PMunch | dom96, okay so now I've pushed a version with 3000ms poll timeout and a +-1000ms range of accepted values. |
17:43:07 | Zevv | or the double-do |
17:43:12 | leorize | double do :P |
17:43:21 | leorize | escaping doesn't seem to be possible from the docs |
17:43:23 | PMunch | The boxes would have to be crazy slow for that to break |
17:43:32 | Zevv | myquote is cooler, because it is *my* quote |
17:45:32 | dom96 | PMunch, wouldn't be surprised if that happens to be honest :) |
17:46:40 | FromGitter | <de-odex> why need a template, im only doing this once so its ok; thanks for the answer |
17:46:54 | PMunch | A 1000ms delay on something that's supposed to take at most 200ms? |
17:47:06 | disruptek | unlikely. |
17:47:17 | FromGitter | <de-odex> you can escape custom quotes afaik but not the default backticks i think |
17:50:53 | disruptek | PMunch: why don't you just engineer it so the wrong timer finishes before the right one, in the event that the test is broken? |
17:51:16 | dom96 | Anyone want to clear some useless code? |
17:51:18 | disruptek | you don't need the `and` or `or` in the test. |
17:51:35 | dom96 | There is a bunch of initialization code in Nimble's options module which can just be removed now (since strings/seq are implicitly initialised now) |
17:53:58 | PMunch | disruptek, be my guest if you can figure out how.. |
17:54:45 | dom96 | disruptek, if you've got a chance today please create the PRs for the httpcore stuff you want changed |
17:54:51 | PMunch | The problem is not that there is a right and wrong timer, the problem is that the dispatcher would use a 500ms timeout for its next iteration even if a timer had fired |
17:54:52 | disruptek | i posted something from the playground whenever it was that you wrote your initial test. doesn't matter enough; it was just a thought to avoid complicating things. |
17:55:14 | PMunch | You did? |
17:55:24 | disruptek | dom96: yeah, i will have 1-2 patches for your review by tomorrow am. |
17:55:39 | disruptek | PMunch: yeah, just after you logged off irc. |
17:55:54 | dom96 | disruptek, can you outline quickly what changes you are planning to make? |
17:56:56 | PMunch | Ah, that explains why I didn't see it :P |
17:57:55 | disruptek | the only changes i will make are to prevent breaking http with, eg. multiple copies of headers. i think we can safely strip whitespace, ie. i think it's within our rights per the spec. most of the other changes are probably impossible without risking breakage. |
17:58:59 | disruptek | combining headers is the riskiest, but as it's per spec, i feel like it's more accurately a bugfix and only a broken server could be affected. |
17:59:12 | PMunch | Oh right, yeah I know I don't need the `and` and `or` to provoke this |
17:59:17 | PMunch | It was just to make the test shorter |
17:59:32 | PMunch | I initially found it when doing pretty much exactly what you are doing in your example |
17:59:50 | disruptek | yeah, i just figured it might help you limit the test a little better, but it doesn't really matter. |
17:59:57 | dom96 | disruptek, combining headers how? I primarily would like to make sure httpcore isn't "unstable" in 1.0 |
18:00:22 | dom96 | so focus on the breaking changes |
18:00:23 | disruptek | agreed. header values, when multiples exist, should be combined with a "," eg. value1,value2. |
18:01:16 | disruptek | unless they are for Cookie, in which case we use "; ". |
18:01:23 | Zevv | should as in SHOULD? |
18:01:44 | * | elrood quit (Remote host closed the connection) |
18:01:45 | Zevv | because 2616 says multiple headers with the same field-name MAY be present |
18:01:57 | disruptek | 2616? link? |
18:02:13 | Zevv | https://tools.ietf.org/html/rfc2616 |
18:02:29 | dom96 | also, HttpHeaderValues is already a seq[string] so I'm not sure how that doesn't happen? |
18:02:30 | Zevv | 4.2 |
18:02:46 | dom96 | In what situation do you get two headers of the same key with different values? |
18:02:54 | disruptek | any time you try to set the Host header. |
18:03:03 | Zevv | proxies might add headers |
18:03:04 | disruptek | that's the most problematic example. |
18:03:09 | dom96 | that's not a httpcore problem |
18:03:15 | disruptek | correct. |
18:03:26 | dom96 | the httpclient probably adds it to the raw data it sends over the socket |
18:03:32 | disruptek | yes. |
18:03:42 | dom96 | so there is nothing to break in httpcore? |
18:04:05 | disruptek | httpcore is broken because of flakey header handling in general, as per the issue. |
18:04:21 | dom96 | okay, so tell me what you want to change in it that is a breaking change |
18:04:22 | disruptek | but, i think it can be patched so it can be stable. even if it is not technically correct. |
18:04:50 | disruptek | well, if you have access to a web browser, the list is enumerated in some detail here: https://github.com/nim-lang/Nim/issues/12211 |
18:05:04 | Araq | HttpHeaders* = ref object |
18:05:05 | Araq | table*: TableRef[string, seq[string]] |
18:05:19 | Araq | is a problem anyway. Firstly, it's pointlessly inefficient |
18:05:20 | FromGitter | <awr1> asdaf |
18:05:28 | dom96 | I just want a TL;DR of the breaking changes that you want to introduce |
18:05:28 | FromGitter | <awr1> okay lol now text entry in gitter works |
18:05:29 | Zevv | Tables support duplicate keys, right? |
18:05:30 | * | exelotl_ quit (Read error: Connection reset by peer) |
18:05:33 | FromGitter | <awr1> hello |
18:05:34 | Araq | secondly there is no data hiding so we cannot change it |
18:05:37 | disruptek | for example, i'm not even sure that we aren't using httpcore's toString() in the default httpclient, which means we are only sending one header value. unless it's Host, for example. |
18:05:53 | disruptek | awr1: noted. |
18:06:07 | Araq | HttpHeaders should be an opaque type |
18:06:10 | dom96 | please explain what exactly from the API of httpcore you want changed |
18:06:16 | Araq | so that we can optimize it under the hood later on |
18:06:24 | dom96 | okay, so make the `table` private |
18:06:28 | disruptek | the second list enumerates those changes, dom96. do you really not have a browser? |
18:06:39 | FromGitter | <awr1> yeah something was wrong with the JS or something, it wasnt focusing |
18:06:45 | FromGitter | <awr1> @Zevv if you use `add()`, yes |
18:06:56 | dom96 | I do have a browser, I just want to get to the point quickly so I can continue working instead of reading your issue again |
18:07:18 | disruptek | well, i want to get to taking a shower and shaving my face. so forgive me for not wanting to type it all out again. |
18:08:37 | disruptek | what we do is up to you. i am happy to write code late tonight or all day tomorrow. just tell me what you want and i will inundate you with tests, etc. i just want this to be improved slightly for nim 1.0; you can bikeshed anything else for next week/month. |
18:08:51 | Araq | HttpHeaderValues* = distinct seq[string] next problem |
18:09:06 | Araq | am I supposed to convert the 'distinct' away? |
18:09:10 | disruptek | Araq: i have that already implemented if you want a patch right now. |
18:09:13 | Araq | because there is no [] accessor for it |
18:09:34 | disruptek | that's one gripe, yes. |
18:09:42 | Araq | disruptek: I want it badly thanks :-) |
18:10:02 | disruptek | okay, let me just submit what i have and you guys can criticize it in the pr. |
18:10:48 | dom96 | https://nim-lang.org/docs/httpcore.html#%5B%5D%2CHttpHeaders%2Cstring%2Cint |
18:10:51 | dom96 | You can use this |
18:11:29 | Araq | huh? |
18:11:38 | Araq | why does my httpcore.nim lack that one... |
18:11:45 | disruptek | https://github.com/nim-lang/Nim/pull/12227 |
18:12:19 | dom96 | meh, I guess we can have a `[]` for it |
18:12:45 | Araq | ah but that's for HttpHeaders, not for HttpHeaderValues |
18:12:48 | Araq | hmmm |
18:13:21 | * | Hideki_ quit (Remote host closed the connection) |
18:13:23 | dom96 | this is consistent with how Go does it btw: https://golang.org/src/net/http/header.go |
18:13:32 | dom96 | their `get` returns the first value by default |
18:13:57 | * | Hideki_ joined #nim |
18:14:11 | dom96 | in fact, I don't see a way to get the other values lol |
18:14:32 | disruptek | you can get them by accessing the table directly. it's a pita, to say the least. |
18:15:28 | dom96 | in any case, perfectly consistent |
18:15:38 | * | thomasross quit (Ping timeout: 240 seconds) |
18:17:18 | disruptek | Zevv: per 7230 section 3.2: "A sender MUST NOT generate multiple header fields with the same field name in a message ..." |
18:17:48 | * | PMunch quit (Remote host closed the connection) |
18:18:41 | disruptek | 7230 obsoletes 2616 btw. |
18:18:50 | * | Hideki_ quit (Ping timeout: 240 seconds) |
18:19:07 | * | narimiran quit (Ping timeout: 265 seconds) |
18:22:57 | Araq | dom96: can I make type HttpHeaders = distinct TableRef[string, seq[string]] ? |
18:23:03 | * | thomasross joined #nim |
18:23:26 | Araq | saves one indirection at least |
18:23:26 | dom96 | Araq, I think so |
18:23:49 | disruptek | if you make it opaque now, you save us from having to have a fixed type later. |
18:26:16 | dom96 | just hope no critical projects access this table directly for some reason |
18:26:18 | * | tri joined #nim |
18:26:29 | dom96 | but the API its got should be enough for most use cases |
18:26:36 | disruptek | since it's the only way to access the values, it's hard not to. |
18:27:02 | disruptek | also, it's debatable whether iterating over the table should yield single header: value pairs or header: value1,value2. |
18:27:09 | * | tri left #nim ("Leaving") |
18:31:02 | disruptek | maybe we should have httpcore2616 and httpcore7230. |
18:31:19 | dom96 | it's not the only way to access the values |
18:31:35 | dom96 | https://nim-lang.org/docs/httpcore.html#%5B%5D%2CHttpHeaders%2Cstring%2Cint |
18:31:53 | disruptek | for iteration it is. |
18:33:16 | dom96 | true |
18:33:17 | Araq | no, there is iterator pairs |
18:33:34 | dom96 | yeah, but it only gives one value |
18:33:53 | dom96 | the reason it is done this way in case you're wondering is because of backwards compatibility |
18:34:12 | Zevv | disruptek: yes, you're right, 7230 it is |
18:34:45 | disruptek | i'm not criticizing today's code, just trying to inform tomorrow's. |
18:35:27 | disruptek | on the other hand, if people weren't expecting to update their code for a major release, especially 1.0, i'm not sure what pre-1.0 means. |
18:36:51 | dom96 | sure, I understand. Just wanted to provide the historical context |
18:37:06 | dom96 | So it took me around 1.5 hours to implement `nimble run` |
18:37:07 | dom96 | far too long |
18:38:02 | * | thomasross quit (Read error: Connection reset by peer) |
18:38:42 | * | thomasross joined #nim |
18:44:09 | * | thomasross quit (Read error: Connection reset by peer) |
18:45:35 | * | PMunch joined #nim |
18:45:47 | disruptek | for nimble, i'd like to be able to specify a specific version requirement with "=" or "==". it was just something i assumed would work and i guess it didn't. eg. `requires "foobar = 1.2.3"`. just a minor nit, since you asked. |
18:50:15 | * | thomasross joined #nim |
18:54:21 | * | Hideki_ joined #nim |
18:56:29 | * | gangstacat quit (Quit: Ĝis!) |
18:57:45 | * | gangstacat joined #nim |
19:07:48 | * | Kaivo quit (Quit: WeeChat 2.6) |
19:10:01 | * | shashlick quit (Remote host closed the connection) |
19:10:37 | * | shashlick joined #nim |
19:16:57 | Zevv | that was my pony |
19:25:15 | shashlick | @dom96 sorry just got off a 24 hour plane trip |
19:25:35 | shashlick | I'm not a fan of adding new features few days before release |
19:25:49 | * | Yardanico joined #nim |
19:28:38 | * | Hideki_ quit (Ping timeout: 245 seconds) |
19:48:58 | dom96 | shashlick, why not? |
19:49:39 | disruptek | Zevv: https://github.com/disruptek/foreach |
19:50:07 | shashlick | Takes a while to stabilize unless really minor |
19:50:45 | dom96 | well of course, it doesn't have to be perfect |
19:50:59 | dom96 | and since I have so little time it's pretty much the main way that new features get done |
19:51:12 | dom96 | in any case, the features I'm working on are behind new commands so they shouldn't cause any trouble |
19:51:57 | shashlick | Ok I would prefer releasing what we have for 1.0 |
19:52:06 | shashlick | Cause it has had a while to become stable |
19:52:36 | shashlick | All the new stuff can go into the next release of nimble |
19:52:47 | shashlick | Which will take some time anyway |
19:52:55 | shashlick | Only because this is for 1.0 |
19:53:45 | * | ^GaveUp^ is now known as GaveUp |
19:53:58 | shashlick | I don't mind defect fixes squeezed in last minute but ya, you know what you are doing |
19:54:26 | Araq | shashlick: that's not how it works for Nim-related stuff. 1.0 is this mystical perfect software that it's unreachable |
19:56:00 | shashlick | Regardless, there should be code freeze, test and release |
19:58:33 | Araq | and of course, we MUST follow semver until we hit 1.0 even though 0.x.y is not semver |
19:58:39 | Araq | "A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes." |
19:58:40 | disruptek | that's kinda how i feel about this http stuff. to me, it's too volatile to disturb. i'd rather just band-aid it. |
19:59:26 | Araq | ^ see? we don't follow semver. :D |
19:59:41 | Araq | semver starts with version 1 |
20:00:29 | Araq | „How do I know when to release 1.0.0? |
20:00:29 | Araq | If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.“ |
20:00:41 | Araq | lol |
20:04:45 | disruptek | well, all my stuff starts at 1.0.0, so pffbt. 😝 |
20:05:21 | disruptek | feels to me like nim 0.19.6 was 1.0. |
20:06:01 | Araq | I sometimes flirt with going back to 0.8.0 :D |
20:06:25 | Araq | or whatever version it was before we introduced the effect system |
20:06:43 | disruptek | just because 0.19.6 was a kinda hard requirement in libs. seemed like if it didn't work with 0.19.6, it wasn't going to work. |
20:07:42 | disruptek | i think 0.8.0 was when i first tried nim and it felt too toy-like then, but it coulda been me. |
20:11:33 | Araq | in retrospect introducing .tags before tackling not-nil is totally backwards :-( |
20:13:06 | Araq | oh well, more stuff for my book, "the design and evolution of Nim" |
20:24:28 | * | navin joined #nim |
20:25:14 | * | sentreen quit (Quit: sentreen) |
20:28:17 | * | sentreen joined #nim |
20:30:22 | lqdev[m] | Araq: semver states they must not contain leading zeroes, doesn't that mean something like 01.2.3? |
20:30:46 | Araq | lqdev[m]: possible lol |
20:32:41 | Araq | but the FAQ also says this: |
20:32:42 | FromGitter | <timotheecour> does anyknow know how karax dthunk work? |
20:32:49 | Araq | „How should I deal with revisions in the 0.y.z initial development phase? |
20:32:49 | Araq | The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.“ |
20:35:05 | Araq | timeotheecour: study "nativenodes.nim" carefully |
20:35:26 | Araq | it's only 20 lines but it's so easy to miss the point |
20:35:56 | FromGitter | <timotheecour> I did, but I couldn’t figure out what I’m doing wrong in https://github.com/pragmagic/karax/issues/119 |
20:36:58 | Araq | is that a regression? |
20:37:03 | FromGitter | <timotheecour> no |
20:37:27 | Araq | well karax is not supposed to check these nodes |
20:37:43 | FromGitter | <timotheecour> (the other regressions i filed are mostly due to `exponential DOM diffing` commit, but this one isnt’ a regression) |
20:39:41 | FromGitter | <timotheecour> i also tried wrapping these inside a unique `id` but it didn’t help; likewise with using `setForeignNodeId` ... |
20:46:06 | Araq | I'm looking at it but I don't understand it either |
20:47:34 | Araq | if you use this |
20:47:37 | Araq | elif a.kind == VNodeKind.dthunk: |
20:47:37 | Araq | return different |
20:47:52 | Araq | it works slightly better |
20:48:40 | Araq | which makes sense, we must assume a change in the native DOM nodes |
20:50:23 | FromGitter | <timotheecour> wait wait wait, how about: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d868d0fb9f8210ed5c8e32d] |
20:52:24 | Araq | hmm no, I misread your example |
20:52:31 | Araq | with 'return different' it works for me |
20:52:55 | Araq | ah your version looks good too |
20:54:05 | * | navin quit (Remote host closed the connection) |
20:54:26 | * | navin joined #nim |
20:55:51 | FromGitter | <timotheecour> ya, we need identical when it doesn’t change; i’ll make a PR; it seems to fix 119 plus my original use case; cool thx for the hint |
20:56:45 | Araq | you're welcome |
21:01:01 | * | navin quit (Remote host closed the connection) |
21:08:35 | FromGitter | <timotheecour> sent it out; this regression (https://github.com/pragmagic/karax/issues/56) is of a similar kind but doesn’t involve dthunk ; at least for this one adding unique id’s is a workaround, but obviously not great |
21:10:29 | * | pbb quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
21:10:46 | * | pbb joined #nim |
21:12:58 | * | pbb quit (Client Quit) |
21:13:11 | * | pbb joined #nim |
21:13:49 | * | Vladar quit (Remote host closed the connection) |
21:16:31 | * | navin joined #nim |
21:19:15 | Araq | I don't understand https://github.com/pragmagic/karax/issues/56 what's wrong with a little too much redrawing? |
21:19:35 | * | sagax quit (Remote host closed the connection) |
21:20:26 | FromGitter | <timotheecour> it’s more serious than that, see the example i posted below, caused by same root cause |
21:20:27 | * | sagax joined #nim |
21:20:45 | * | navin quit (Ping timeout: 252 seconds) |
21:21:07 | FromGitter | <timotheecour> (it gives incorrect results) |
21:25:18 | Araq | oh man why don't we compute the diff via dynamic programming |
21:27:11 | FromGitter | <timotheecour> DP won’t help with other situations eg reordering (inversing order etc) ; actually I always wondered instead: why don’t we compute the diff via a hashing function (that can be user-redefined ) |
21:28:52 | FromGitter | <timotheecour> Hash(node) = compute hash by aggregating children’s hash’s nodes recursively; note that it’d use a good hash function so that if child nodes are reordered, the hash would change. |
21:29:26 | FromGitter | <timotheecour> using a big enough hash so that probability of collision = small enough in practice. |
21:29:58 | Araq | hashing in Javascript wasn't really fast when we tried it but we were concerned about this "small enough in practice" |
21:31:55 | dom96 | How do I disable the new warnings for unused imports? |
21:32:26 | Araq | {.used.} pragma in the module you want to have |
21:33:44 | FromGitter | <timotheecour> > hashing in Javascript wasn't really fast when we tried it ⏎ ⏎ that *could* be because we’re currently using hash(x)=x for numbers, which is not a good hash function, see https://github.com/nim-lang/Nim/pull/11767#issuecomment-512611465 |
21:35:08 | Araq | nah but I don't remember the details. however, the fact that you cannot hash closures doesn't help |
21:35:25 | dom96 | Araq, `import strutils {.used.}`? |
21:35:45 | Araq | dom96: that doesn't exist :P |
21:36:04 | FromGitter | <timotheecour> `used` goes inside the imported module , not the importing module |
21:36:04 | Araq | clean up your code instead |
21:36:10 | dom96 | Araq, isn't there a command flag? |
21:36:24 | Araq | --warning[x]:off ? |
21:36:38 | Araq | where the 'x' is mentioned in the warning |
21:36:43 | dom96 | okay |
21:37:05 | Araq | you need to write more nim, you're rusty |
21:37:12 | dom96 | ugh, now I remember why nimble generates the temporary .nims file beside .nimble every time it executes :( |
21:37:37 | dom96 | Araq, I remembered this, I just wanted to double check and was too lazy to look it up in the manual ;) |
21:37:49 | * | Trustable quit (Remote host closed the connection) |
21:37:57 | dom96 | also, there was always the possibiity that you implemented these warnings in some undisableable manner |
21:38:15 | dom96 | anyway, I'm making it so that Nimble doesn't remove the temp files it creates when executed with --debug |
21:38:40 | Araq | just don't remove temp files when stuff goes wrong |
21:38:51 | Araq | and maybe never remove it, it's temp already ... |
21:40:33 | dom96 | the .nims file that gets generated each time nimble runs isn't in /tmp... |
21:40:47 | dom96 | also, I don't think OS' remove /tmp as often as we'd like |
21:41:13 | dom96 | it's easier to implement this using --debug for now. |
21:43:53 | Araq | that's good to know |
21:44:02 | Araq | I never saw any .nims files though |
21:44:15 | * | solitudesf- quit (Remote host closed the connection) |
21:44:26 | Araq | but then I also never really looked, I assume Nimble puts stuff in the most inconvenient places, always. |
21:44:37 | * | solitudesf- joined #nim |
21:45:24 | dom96 | yes, this bothers me too, trust me |
21:46:33 | dom96 | shashlick, I can vaguely remember why this .nims file is generated beside the .nimble file, can you remind me the reasons fully? |
21:48:38 | PMunch | Okay, the tests are green now dom96: https://github.com/nim-lang/Nim/pull/12221 |
21:49:07 | dom96 | Araq, please review ^ |
21:57:31 | * | Hideki_ joined #nim |
22:00:13 | FromGitter | <timotheecour> @dom96 have you ever run into jester crashing with `Error: unhandled exception: Protocol wrong type for socket` ? (with this stack trace https://gist.github.com/timotheecour/1c52750c6d1b11bdd57f2707fe5ee3fb) ; it’s hard to find a reproducible example, it happens once in a while |
22:01:09 | dom96 | nope, have you tried googling around for that error message? (It comes from the OS) |
22:02:02 | FromGitter | <timotheecour> i have but it was not very enlightening... |
22:02:47 | * | Hideki_ quit (Ping timeout: 276 seconds) |
22:08:24 | * | PMunch quit (Remote host closed the connection) |
22:09:07 | shashlick | @dom96 cause imports and files are relative to the project dir |
22:09:17 | shashlick | Since that's where the nimble file is |
22:09:24 | shashlick | So have to run in the same place |
22:09:35 | shashlick | Else we break a whole bunch of packages |
22:10:37 | dom96 | ahh yes, that sucks |
22:10:45 | dom96 | nim e needs a stdin mode |
22:10:54 | dom96 | and to take the CWD as the project dir |
22:11:25 | dom96 | but then debugging this will be harder :( |
22:28:53 | FromGitter | <mratsim> btw, this PR has been ready for about 3 weeks: https://github.com/nim-lang/Nim/pull/11816 |
22:29:46 | FromGitter | <mratsim> also @Araq, didn't you have a RFC/master plan for the future of the stdlib? I can't find it |
22:34:44 | dom96 | If you guys are bored, please get the new Nimble and test `nimble run`: https://github.com/nim-lang/nimble/commit/c834faf60e1dbdd8ae46456e1fb2dc2db05e4e91 |
22:34:56 | dom96 | That took longer to implement than I thought :) |
22:39:25 | Araq | mratsim: never finished that RFC |
22:39:58 | FromGitter | <mratsim> I think it should be done before 1.0 and linked into the release announcement |
22:40:13 | FromGitter | <mratsim> to manage people expectations |
22:46:05 | dom96 | well... that's annoying |
22:46:12 | dom96 | execCmdEx hangs when executing `nim e` |
22:49:21 | Araq | mratsim: ok, maybe |
22:50:18 | Araq | but it's actually quite simple, stdlib is "old cruft" + modules the Nim compiler or testament need + modules that have common vocabulary for interop |
22:50:56 | Araq | best example is Option[T], stuff works better when everybody uses the same Option T type |
22:51:00 | Araq | good night. |
22:53:10 | disruptek | it's saturday night, get busy toasting nim 1.0. |
22:53:25 | dom96 | anybody up for a riddle? |
22:53:36 | disruptek | sure, lay it on me, boss. |
22:53:42 | dom96 | https://github.com/nim-lang/nimble/pull/711 |
22:53:48 | disruptek | damnit. |
22:53:58 | dom96 | Why does execCmdEx stall? :P |
22:54:16 | disruptek | you have a strange idea of comedy, dom. :-P |
22:55:01 | dom96 | wouldn't be surprised if this is macOS only too :/ |
22:55:36 | disruptek | is it compile-time? |
22:56:36 | FromGitter | <mratsim> I'm more interested in: how do we improve on the common vocabulary or replace it especially if API has issues: i.e. the seq[byte] vs string for all the binary stuff notably crypto |
22:56:40 | disruptek | i wonder if this is due to the recent changes to protect against tooling staticExec'ing stuff. |
22:57:19 | disruptek | mratsim: i almost hate to ask, but what's the issue between byte != string? |
22:57:49 | FromGitter | <mratsim> binary = seq[byte], for human consumption = string |
22:58:18 | disruptek | yes, but where do they currently differ? and no hand-wavy differences, please. |
22:58:20 | FromGitter | <mratsim> bonus: unvalidated human inputs = TaintedString |
22:58:37 | FromGitter | <mratsim> they differ in type? |
22:59:03 | disruptek | so, syntax, not semantics? because only host/net endianess keeps me up nights. |
22:59:23 | FromGitter | <mratsim> it's not syntax, it's semantics |
22:59:43 | disruptek | not if we treat strings as binary and vice-versa. |
23:00:24 | FromGitter | <mratsim> the point of a strong type system is to avoid those type-casting just like we avoid type casting signed int to unsigned int or to bool |
23:00:33 | FromGitter | <mratsim> implicitly* |
23:00:35 | disruptek | noted. |
23:00:43 | disruptek | i'm drunk, but i'm not stupid. |
23:00:59 | dom96 | might be a bit too late for this to become accepted practice |
23:01:11 | disruptek | still, what's the practical breakage example? |
23:01:20 | dom96 | strings are going to contain binary data, you can do nothing about that |
23:01:23 | FromGitter | <mratsim> I don't think so, I think it's a good time |
23:01:25 | * | nsf1 quit (Quit: WeeChat 2.5) |
23:02:10 | disruptek | i think that's nuts, honestly. it's too late to do much of anything for 1.0. |
23:02:16 | FromGitter | <mratsim> As Nim matures there will be future core API that will probably need to be revisited |
23:02:25 | FromGitter | <mratsim> I'm not saying we change for v1.0 |
23:02:36 | disruptek | sure, sure, but what's your example to rile my blood lust for byte? |
23:02:53 | FromGitter | <mratsim> I'm saying we have a plan to handle future needs of the standard library |
23:03:13 | FromGitter | <mratsim> You can read more here: https://github.com/nim-lang/RFCs/issues/32 |
23:03:45 | disruptek | why didn't you say so? i love hashing out 18-month old RFCs the weekend of 1.0 release while stone cold sober. |
23:03:54 | disruptek | even more so while i'm three sheets to the proverbial wind. |
23:04:15 | disruptek | btw, do you guys actually use nimsha2? |
23:04:15 | * | nif_ quit (Quit: ...) |
23:04:25 | * | nif joined #nim |
23:05:28 | disruptek | i'm just asking because i already digested this when doing some crypto recently and i couldn't make nimsha2 work to my taste. |
23:05:56 | * | solitudesf- quit (Ping timeout: 246 seconds) |
23:06:49 | FromGitter | <mratsim> Typically, what might need several incompatible API revisions and are important enough to be in stdlib IMO: ⏎ ⏎ 1) seq byte vs string ⏎ 2) streams ⏎ 3) logging ... [https://gitter.im/nim-lang/Nim?at=5d86ad09a38dae3a63951bf8] |
23:07:05 | FromGitter | <mratsim> no we don't use nimsha2, we use nimcrypto |
23:07:35 | disruptek | fail enough, that's why i chose nimcrypto. |
23:07:39 | disruptek | ^fair too. |
23:08:46 | FromGitter | <mratsim> I think the seq[byte] vs string is good first start to see if we can have a smooth transition process between incompatible APIs. |
23:08:51 | disruptek | i agree with that list except for databases (have no idea what exists currently), bigint, and strutils. |
23:09:13 | disruptek | okay, but we need the horrible hairy example so we can all feelsbadman. |
23:09:18 | FromGitter | <mratsim> databases are there: https://nim-lang.org/docs/lib.html#wrappers-database-support, I've never used them though |
23:09:24 | * | Hideki_ joined #nim |
23:09:55 | disruptek | wrappers don't much count. it sounds like you want a db api a la python, which seems like a good idea. is that what you're after? |
23:10:10 | FromGitter | <mratsim> but it seems to be all low-level so |
23:10:28 | disruptek | maybe ormin should move into stdlib and become a basis for something more. |
23:11:10 | disruptek | honestly, this just doesn't feel like a good excuse to put databases on a mcarthy list. |
23:11:59 | disruptek | it's early days. there's gonna be a lot of stuff missing. it'll get built. i'm guilty of half-baked crap, too. i don't feel guilty about it. what i release isn't terrible enough that it cannot be improved. that's the only yardstick, imo. |
23:12:48 | FromGitter | <mratsim> What I'm after is: ⏎ ⏎ 1) assume we add a hih-level API, say Ormin ⏎ 2) 2 years from now, once everyone use Ormin, we realize that there is a better way, because it's more composable and enable simpler pattern, optimizations, whatever. ⏎ 3) we want to progressively redo the API, without splitting the community, hurting development effort and without too much overhead for library users ... |
23:12:48 | FromGitter | ... [https://gitter.im/nim-lang/Nim?at=5d86ae70e45b6d473233d34f] |
23:13:50 | dom96 | mratsim: if you really want a distinct type for collections of bytes then you'll need to break a lot in the stdlib |
23:13:54 | disruptek | look, i'm old. maybe that informs my opinion. but, 2 years is no time at all. also, this isn't particularly problematic compared to producing code early. |
23:14:06 | disruptek | you are worried about supporting users that don't exist. |
23:14:27 | disruptek | as my accountant told me when i started my last company, worry about profits first, then we can talk about taxes. |
23:14:47 | disruptek | actually, that was three companies ago and i was profitable in the first 3 weeks, but i digress... |
23:15:05 | FromGitter | <mratsim> managing expectations is important |
23:15:44 | disruptek | he needs to break nothing in the stdlib, because there's really no way to build much for what he wants using what's in there. which is why it's not worth worrying about. |
23:16:36 | FromGitter | <mratsim> we will receive new users that will ask "but foo language does it like this, it's great because now I can do that, can we change it" --> if we have an idea of how to do that we only have to discuss about the merits of the new API, without burdening ourself with how to change it |
23:16:41 | disruptek | imo the right move is to go 2 years down the road and make a new api without regard to ormin or w/e. |
23:17:06 | disruptek | so what? you're here because nim. if you make nim equal go, you've lost the battle already. |
23:17:24 | disruptek | i mean, c'mon, man. |
23:17:40 | disruptek | you have to bake into nim what it is that separates it or it will no longer be separated. |
23:18:17 | FromGitter | <mratsim> well, I'll do something productive instead of discussing with drunk people. |
23:18:24 | disruptek | pffbt. |
23:18:39 | dom96 | hah, fair |
23:19:01 | disruptek | i mean, i won't argue _that_ point, but still... feel free to ignore my perfectly valid criticisms of your argument. |
23:19:53 | dom96 | disruptek, what are these profitable companies you speak of? You don't happen to be one of those Sillicon Valley unicorns, do you? |
23:20:10 | disruptek | when did i say anything about a profitable company? |
23:20:29 | dom96 | "actually, that was three companies ago and i was profitable in the first 3 weeks" |
23:20:32 | disruptek | oh. 3 weeks. back when i was a rare coin dealer. do you want to buy some antique gold coins? |
23:20:53 | dom96 | that depends, will I need to ask my friends to buy them off me? |
23:21:02 | disruptek | what would be the point of that? |
23:21:23 | disruptek | you don't buy coins for their intrisic value. actually, some do, but i don't sell that kinda dogshit. |
23:21:27 | * | Hideki_ quit (Remote host closed the connection) |
23:21:36 | disruptek | ^ intrinsic, either. |
23:22:15 | * | Hideki_ joined #nim |
23:24:08 | disruptek | the point i really want to make is this: if nim is the betamax to rust's vhs, then so be it. i'm not worried about anyone taking nim away from me, and if vhs wins and i need to switch to laserdisc from nim, fine. i'm pretty sure this community will plant a signpost telling me where to go for my fix. |
23:25:00 | disruptek | let the tech speak for itself and support efforts like newruntime and nlvm and newgc to help differentiate. |
23:26:42 | * | Hideki_ quit (Ping timeout: 245 seconds) |
23:30:00 | disruptek | okay, that's an unpopular thought, i can tell. well. wrt ormin in 2 years. here's what happens. you make ormin, you make it great, people love it, people use it. it's stable. then you make newthing because ormin doesn't do newthing. ormin becomes even more stable. newthing becomes desirable. the resources move. it's that simple. |
23:34:37 | * | disruptek 🦗🦗🦗🦗 |
23:46:04 | * | Hideki_ joined #nim |
23:47:19 | * | Hideki_ quit (Remote host closed the connection) |
23:48:42 | * | Hideki_ joined #nim |
23:53:56 | * | Hideki_ quit (Ping timeout: 276 seconds) |