<< 21-09-2019 >>

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:19Araqdom96: please review https://github.com/nim-lang/Nim/pull/12221
09:23:23*navin quit (Remote host closed the connection)
09:38:31dom96will do
09:39:07*navin joined #nim
09:43:38*navin quit (Ping timeout: 245 seconds)
09:53:48*krux02 joined #nim
10:02:58dom96Araq, done
10:03:00dom96got anything else?
10:06:04*Ven`` joined #nim
10:07:31dom96disruptek: you around?
10:12:07PMunchThanks for the review dom96 added some comments
10:13:43dom96PMunch, please join #fosdem19newerlangs
10:18:15lqdev[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:16lqdev[m]checked with -d:release, but I compile my executable with --opt:speed so that should have -O3 optimization in gcc
10:18:18PMunchOh 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:11gekohi
10:41:17*navin joined #nim
10:42:12leorizeo/
10:42:32gekoi have a doubt
10:44:14PMunchA doubt of what?
10:44:46gekoif my "case of" block is inside a "if" block
10:45:29*navin quit (Ping timeout: 250 seconds)
10:45:48gekoand my "if" block allows only a particular values why does it still say else is required
10:48:21PMunchBecause it doesn't check for that unfortunately
10:49:03gekowill that be fixed for consistensy
10:49:17*elrood joined #nim
10:49:26gekoor will it be made optional like modern pascal
10:55:55lqdev[m]what's the problem with adding an `else` branch to your `case` statement?
10:57:18gekoif of covers all the cases why do i need an else
10:58:31PMunchBut it doesn't cover all the cases
10:58:31lqdev[m]because the branch detection isn't so sophisticated to allow you to skip that `else`
10:59:04lqdev[m]I personally never found this to be a problem
10:59:11PMunchHmm, what is this error when running ./koch boot: Error: undeclared identifier: 'delEnv'
10:59:28PMunchhttp://ix.io/1Wbf
10:59:33lqdev[m]looks like one of the features introduced in devel
10:59:57PMunchWell this is on my branch..
11:00:11lqdev[m]from the changelog
11:00:12lqdev[m]> Added os.delEnv and nimscript.delEnv. (#11466)
11:00:36PMunchIt built just fine yesterday..
11:02:49gekohttps://play.nim-lang.org/#ix=1Wbh
11:02:57PMunchAh.. Building koch in release mode made it work fine
11:09:02*endragor joined #nim
11:10:11gekoPMunch it does cover all cases
11:12:13PMunchThe case statement doesn't
11:12:18narimirangeko: `case` is not aware of your `if` outside of it
11:12:21PMunchAnd that is what's being checked
11:13:29gekoso shouldn't this be improved
11:14:15gekoisn't this an unnecessary else case
11:16:03narimiranPRs welcome :P
11:16:06dom96geko, sure, it could be improved. But right now it doesn't rank high enough on our list of priorities.
11:17:07gekonarimiran wish i could but i lack the knowledge.
11:18:26*PMunch quit (Remote host closed the connection)
11:18:39gekodom96 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:54Zevvgeko: 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:30ZevvIf yes, I can make up one that is a bit more convoluted, and if no, why not?
12:04:52dom96Anyone have any Nimble wishes? I'm working on the new release
12:05:26Zevvoooh that's like asking if anyone wants candy, isn't it?
12:08:57Zevvwell, 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:28Zevvand that is too many 'description' in one message
12:12:32*endragor quit (Ping timeout: 245 seconds)
12:17:35navinfor ` nimble list` , if we can add different output listing format probably json/table/csv
12:21:47dom96there is a PR open for that
12:21:58Zevvjson wouldn't be too hard to do :)
12:22:06dom96personally don't think more info is needed in packages.json
12:22:36dom96anyway, do keep these ideas coming, i've gotta step out for a couple of hours :)
12:23:06dom96if 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:21FromGitter<mratsim> @dom96 task level dependencies
13:01:41FromGitter<mratsim> and also being able to pass flags like -d:foo to task
13:02:05FromGitter<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:03Zevvand 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:13ZevvI 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:08federico3https://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:38disruptekdom96: 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:44dom96mratsim: those might be tough to do in a day
14:31:08FromGitter<mratsim> @Zevv, here you go: https://pjreddie.com/static/Redmon%20Resume.pdf
14:32:14FromGitter<mratsim> I don't know how C++ devs can cope with C++ build times
14:32:39FromGitter<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:25dom96shashlick, you around?
14:55:37Zevvwhy can this not be instantiated: `var seen: Table[(int,int)]`
14:56:03Araqbecause a table needs Key, Value types, not a single tuple type
14:56:19ZevvOh daaaang I'm reading wrong
14:56:20Zevvpffff
14:56:21Zevvsilly me
14:56:51Zevvthe 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:14dom96Ahh, love cleaning out the Nimble issue tracker
15:30:21dom96so many issues that can now be closed without any code changes
15:39:47Zevvhow so?
15:40:33dom96many which have been fixed or are so old that they aren't relevant anymore
15:40:43Zevv"wontfix" -> close :)
15:41:17*laaron quit (Remote host closed the connection)
15:41:45dom96some of that too ;)
15:42:20*Kaivo joined #nim
15:43:23*laaron joined #nim
15:44:46dom96wow, I must have been really tired in some of these
15:44:55dom96Missed a word in my sentence in two separate comments
15:45:18Zevvwell who cares if you miss a
15:51:03*PMunch joined #nim
15:51:16dom96:)
15:59:51PMunchI 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:04dom96It's still very risky
16:00:31dom96the CI machines can sometimes be very slow, I would very much prefer a test whose success doesn't depend on timing
16:03:18PMunchYeah, 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:05dom96I have a hunch that there is a way to achieve this without measuring time taken
16:04:30federico3(...that's why people have dedicated bare-metal buildbots...)
16:09:58PMunchdom96, 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:33Calinoubare metal buildbots are expensive though
16:12:46*nc-x joined #nim
16:12:47PMunchWell, the test just failed again.. So it must definitely be solved somehow..
16:12:52dom96:)
16:13:00nc-xCan anybody reproduce https://github.com/nim-lang/nimble/issues/706?
16:13:19*nc-x quit (Remote host closed the connection)
16:16:34dom96I just reproduced it :)
16:18:40nc-x[m]👍🏻
16:19:30PMunchThis job can be aborted if anyone has the possibility to do so: https://ci.appveyor.com/project/dom96/nim/builds/27570866
16:20:48PMunchSame 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:55Zevvfake the lowest level os primitives so all layers above there can be tested
16:50:04dom96Yeah, that would be the ideal way to test this but sounds like a challenge to implement all this
16:50:13dom96So I've put 13 issues into this milestone: https://github.com/nim-lang/nimble/milestone/2
16:50:18dom96Might be too ambitious
16:50:42*thomasross joined #nim
16:50:48Zevvwhat timeframe are you thinking for those then?
16:51:28PMunchYay, test passed now :)
16:57:40dom96The rest of today :P
16:58:01dom96and yeah, it is already 6pm...
16:58:47*endragor quit (Remote host closed the connection)
17:00:11Zevvoh I think I just found a bug. Doing nimble init, author and description don't get quoted in the .nimble
17:00:21dom96that's been fixed
17:00:25dom96update your nimble
17:01:48Zevvah ok
17:02:12ZevvI just fixed that a second time :)
17:02:40PMunchDamn it, the travis test failed..
17:03:21PMunchI can keep increasing the sleeps to the point where the test will take a long time to run
17:03:30PMunchBut I'm not sure if that is really a good idea..
17:03:37PMunchThe test suite is slow enough as it is..
17:04:09FromGitter<de-odex> hi, new to nim (and lower level languages in general) here
17:04:47Araqdom96: so tell me the nimble commit hash to use in koch
17:04:51Araqplease
17:05:13*aEverr joined #nim
17:06:45dom96Araq, it's not ready yet, I just posted a iist of issues I'd like to fix
17:06:48dom96*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:58nc-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:35PMunchHi de-odex, welcome to Nim
17:23:06PMunchSo 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:22dom96PMunch, make it not dependent on timing
17:24:28dom96I don't know how to do it though I'm afraid
17:24:33dom96I can't look at it now, busy with Nimble
17:25:19PMunchWell 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:05FromGitter<de-odex> question, is it possible to use quote do: with a body containing a template using varargs[string, `$`]?
17:29:02Zevvdo-odex: did you try and ran into problems?
17:29:07PMunchNot entirely sure if I follow what you mean
17:29:46dom96PMunch, you need to find a way to detect your changes are working without relying on timing
17:29:55FromGitter<de-odex> quote do would interpret the `$` as a variable in the macro
17:30:05dom96maybe you can create a callback that sets some global flag in a specific order that tests your change
17:30:18dom96(or a callback + timer, or multiple callbacks + timers)
17:30:29PMunchdom96, 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:40Zevvde-odex: IIRC you can specify the quote character for a quote block
17:32:09PMunchProblem is that any timer that runs before the 500ms timeout will change the behavier of the timer and remove the bug
17:33:01PMunchHence why the two middle test cases both return in 200ms and not one in 200ms and one it 500+ ms
17:33:32FromGitter<de-odex> Zevv, uh do you know how?
17:33:38*elrood joined #nim
17:34:04Zevvwell, 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:07dom96PMunch, you can also try playing with making the `poll` timeout longer (it's 500ms by default)
17:35:57PMunchYeah, 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:25PMunchAnd the test will still run fast if everything is working as it should
17:38:18dom96you also don't need so many test cases, just the one will do
17:41:20leorizeZevv, @de-odex: quote do: <block> do: "quoting op"
17:41:32ZevvI did template myquote(bl: untyped): NimNode = quote(bl, "~~")
17:41:54leorizeIIRC you can escape the quoting character
17:42:18PMunchWell they all test slightly different scenarios
17:42:29PMunchhttps://ci.appveyor.com/project/dom96/nim/builds/27571642 <- this can be cancelled
17:42:33Zevvleorize: i think I read somewhere that's not possible. We'll see who'se right :)
17:42:55leorizewell that's how I do it in my code :P
17:43:05Zevvescaping the char?
17:43:07PMunchdom96, okay so now I've pushed a version with 3000ms poll timeout and a +-1000ms range of accepted values.
17:43:07Zevvor the double-do
17:43:12leorizedouble do :P
17:43:21leorizeescaping doesn't seem to be possible from the docs
17:43:23PMunchThe boxes would have to be crazy slow for that to break
17:43:32Zevvmyquote is cooler, because it is *my* quote
17:45:32dom96PMunch, wouldn't be surprised if that happens to be honest :)
17:46:40FromGitter<de-odex> why need a template, im only doing this once so its ok; thanks for the answer
17:46:54PMunchA 1000ms delay on something that's supposed to take at most 200ms?
17:47:06disruptekunlikely.
17:47:17FromGitter<de-odex> you can escape custom quotes afaik but not the default backticks i think
17:50:53disruptekPMunch: 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:16dom96Anyone want to clear some useless code?
17:51:18disruptekyou don't need the `and` or `or` in the test.
17:51:35dom96There 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:58PMunchdisruptek, be my guest if you can figure out how..
17:54:45dom96disruptek, if you've got a chance today please create the PRs for the httpcore stuff you want changed
17:54:51PMunchThe 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:52disrupteki 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:14PMunchYou did?
17:55:24disruptekdom96: yeah, i will have 1-2 patches for your review by tomorrow am.
17:55:39disruptekPMunch: yeah, just after you logged off irc.
17:55:54dom96disruptek, can you outline quickly what changes you are planning to make?
17:56:56PMunchAh, that explains why I didn't see it :P
17:57:55disruptekthe 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:59disruptekcombining 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:12PMunchOh right, yeah I know I don't need the `and` and `or` to provoke this
17:59:17PMunchIt was just to make the test shorter
17:59:32PMunchI initially found it when doing pretty much exactly what you are doing in your example
17:59:50disruptekyeah, i just figured it might help you limit the test a little better, but it doesn't really matter.
17:59:57dom96disruptek, combining headers how? I primarily would like to make sure httpcore isn't "unstable" in 1.0
18:00:22dom96so focus on the breaking changes
18:00:23disruptekagreed. header values, when multiples exist, should be combined with a "," eg. value1,value2.
18:01:16disruptekunless they are for Cookie, in which case we use "; ".
18:01:23Zevvshould as in SHOULD?
18:01:44*elrood quit (Remote host closed the connection)
18:01:45Zevvbecause 2616 says multiple headers with the same field-name MAY be present
18:01:57disruptek2616? link?
18:02:13Zevvhttps://tools.ietf.org/html/rfc2616
18:02:29dom96also, HttpHeaderValues is already a seq[string] so I'm not sure how that doesn't happen?
18:02:30Zevv4.2
18:02:46dom96In what situation do you get two headers of the same key with different values?
18:02:54disruptekany time you try to set the Host header.
18:03:03Zevvproxies might add headers
18:03:04disruptekthat's the most problematic example.
18:03:09dom96that's not a httpcore problem
18:03:15disruptekcorrect.
18:03:26dom96the httpclient probably adds it to the raw data it sends over the socket
18:03:32disruptekyes.
18:03:42dom96so there is nothing to break in httpcore?
18:04:05disruptekhttpcore is broken because of flakey header handling in general, as per the issue.
18:04:21dom96okay, so tell me what you want to change in it that is a breaking change
18:04:22disruptekbut, i think it can be patched so it can be stable. even if it is not technically correct.
18:04:50disruptekwell, 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:04Araq HttpHeaders* = ref object
18:05:05Araq table*: TableRef[string, seq[string]]
18:05:19Araqis a problem anyway. Firstly, it's pointlessly inefficient
18:05:20FromGitter<awr1> asdaf
18:05:28dom96I just want a TL;DR of the breaking changes that you want to introduce
18:05:28FromGitter<awr1> okay lol now text entry in gitter works
18:05:29ZevvTables support duplicate keys, right?
18:05:30*exelotl_ quit (Read error: Connection reset by peer)
18:05:33FromGitter<awr1> hello
18:05:34Araqsecondly there is no data hiding so we cannot change it
18:05:37disruptekfor 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:53disruptekawr1: noted.
18:06:07AraqHttpHeaders should be an opaque type
18:06:10dom96please explain what exactly from the API of httpcore you want changed
18:06:16Araqso that we can optimize it under the hood later on
18:06:24dom96okay, so make the `table` private
18:06:28disruptekthe second list enumerates those changes, dom96. do you really not have a browser?
18:06:39FromGitter<awr1> yeah something was wrong with the JS or something, it wasnt focusing
18:06:45FromGitter<awr1> @Zevv if you use `add()`, yes
18:06:56dom96I 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:18disruptekwell, 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:37disruptekwhat 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:51AraqHttpHeaderValues* = distinct seq[string] next problem
18:09:06Araqam I supposed to convert the 'distinct' away?
18:09:10disruptekAraq: i have that already implemented if you want a patch right now.
18:09:13Araqbecause there is no [] accessor for it
18:09:34disruptekthat's one gripe, yes.
18:09:42Araqdisruptek: I want it badly thanks :-)
18:10:02disruptekokay, let me just submit what i have and you guys can criticize it in the pr.
18:10:48dom96https://nim-lang.org/docs/httpcore.html#%5B%5D%2CHttpHeaders%2Cstring%2Cint
18:10:51dom96You can use this
18:11:29Araqhuh?
18:11:38Araqwhy does my httpcore.nim lack that one...
18:11:45disruptekhttps://github.com/nim-lang/Nim/pull/12227
18:12:19dom96meh, I guess we can have a `[]` for it
18:12:45Araqah but that's for HttpHeaders, not for HttpHeaderValues
18:12:48Araqhmmm
18:13:21*Hideki_ quit (Remote host closed the connection)
18:13:23dom96this is consistent with how Go does it btw: https://golang.org/src/net/http/header.go
18:13:32dom96their `get` returns the first value by default
18:13:57*Hideki_ joined #nim
18:14:11dom96in fact, I don't see a way to get the other values lol
18:14:32disruptekyou can get them by accessing the table directly. it's a pita, to say the least.
18:15:28dom96in any case, perfectly consistent
18:15:38*thomasross quit (Ping timeout: 240 seconds)
18:17:18disruptekZevv: 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:41disruptek7230 obsoletes 2616 btw.
18:18:50*Hideki_ quit (Ping timeout: 240 seconds)
18:19:07*narimiran quit (Ping timeout: 265 seconds)
18:22:57Araqdom96: can I make type HttpHeaders = distinct TableRef[string, seq[string]] ?
18:23:03*thomasross joined #nim
18:23:26Araqsaves one indirection at least
18:23:26dom96Araq, I think so
18:23:49disruptekif you make it opaque now, you save us from having to have a fixed type later.
18:26:16dom96just hope no critical projects access this table directly for some reason
18:26:18*tri joined #nim
18:26:29dom96but the API its got should be enough for most use cases
18:26:36disrupteksince it's the only way to access the values, it's hard not to.
18:27:02disruptekalso, 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:02disruptekmaybe we should have httpcore2616 and httpcore7230.
18:31:19dom96it's not the only way to access the values
18:31:35dom96https://nim-lang.org/docs/httpcore.html#%5B%5D%2CHttpHeaders%2Cstring%2Cint
18:31:53disruptekfor iteration it is.
18:33:16dom96true
18:33:17Araqno, there is iterator pairs
18:33:34dom96yeah, but it only gives one value
18:33:53dom96the reason it is done this way in case you're wondering is because of backwards compatibility
18:34:12Zevvdisruptek: yes, you're right, 7230 it is
18:34:45disrupteki'm not criticizing today's code, just trying to inform tomorrow's.
18:35:27disruptekon 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:51dom96sure, I understand. Just wanted to provide the historical context
18:37:06dom96So it took me around 1.5 hours to implement `nimble run`
18:37:07dom96far 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:47disruptekfor 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:57Zevvthat was my pony
19:25:15shashlick@dom96 sorry just got off a 24 hour plane trip
19:25:35shashlickI'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:58dom96shashlick, why not?
19:49:39disruptekZevv: https://github.com/disruptek/foreach
19:50:07shashlickTakes a while to stabilize unless really minor
19:50:45dom96well of course, it doesn't have to be perfect
19:50:59dom96and since I have so little time it's pretty much the main way that new features get done
19:51:12dom96in any case, the features I'm working on are behind new commands so they shouldn't cause any trouble
19:51:57shashlickOk I would prefer releasing what we have for 1.0
19:52:06shashlickCause it has had a while to become stable
19:52:36shashlickAll the new stuff can go into the next release of nimble
19:52:47shashlickWhich will take some time anyway
19:52:55shashlickOnly because this is for 1.0
19:53:45*^GaveUp^ is now known as GaveUp
19:53:58shashlickI don't mind defect fixes squeezed in last minute but ya, you know what you are doing
19:54:26Araqshashlick: that's not how it works for Nim-related stuff. 1.0 is this mystical perfect software that it's unreachable
19:56:00shashlickRegardless, there should be code freeze, test and release
19:58:33Araqand of course, we MUST follow semver until we hit 1.0 even though 0.x.y is not semver
19:58:39Araq"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:40disruptekthat'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:26Araq^ see? we don't follow semver. :D
19:59:41Araqsemver starts with version 1
20:00:29Araq„How do I know when to release 1.0.0?
20:00:29AraqIf 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:41Araqlol
20:04:45disruptekwell, all my stuff starts at 1.0.0, so pffbt. 😝
20:05:21disruptekfeels to me like nim 0.19.6 was 1.0.
20:06:01AraqI sometimes flirt with going back to 0.8.0 :D
20:06:25Araqor whatever version it was before we introduced the effect system
20:06:43disruptekjust 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:42disrupteki think 0.8.0 was when i first tried nim and it felt too toy-like then, but it coulda been me.
20:11:33Araqin retrospect introducing .tags before tackling not-nil is totally backwards :-(
20:13:06Araqoh 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:22lqdev[m]Araq: semver states they must not contain leading zeroes, doesn't that mean something like 01.2.3?
20:30:46Araqlqdev[m]: possible lol
20:32:41Araqbut the FAQ also says this:
20:32:42FromGitter<timotheecour> does anyknow know how karax dthunk work?
20:32:49Araq„How should I deal with revisions in the 0.y.z initial development phase?
20:32:49AraqThe 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:05Araqtimeotheecour: study "nativenodes.nim" carefully
20:35:26Araqit's only 20 lines but it's so easy to miss the point
20:35:56FromGitter<timotheecour> I did, but I couldn’t figure out what I’m doing wrong in https://github.com/pragmagic/karax/issues/119
20:36:58Araqis that a regression?
20:37:03FromGitter<timotheecour> no
20:37:27Araqwell karax is not supposed to check these nodes
20:37:43FromGitter<timotheecour> (the other regressions i filed are mostly due to `exponential DOM diffing` commit, but this one isnt’ a regression)
20:39:41FromGitter<timotheecour> i also tried wrapping these inside a unique `id` but it didn’t help; likewise with using `setForeignNodeId` ...
20:46:06AraqI'm looking at it but I don't understand it either
20:47:34Araqif you use this
20:47:37Araq elif a.kind == VNodeKind.dthunk:
20:47:37Araq return different
20:47:52Araqit works slightly better
20:48:40Araqwhich makes sense, we must assume a change in the native DOM nodes
20:50:23FromGitter<timotheecour> wait wait wait, how about: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d868d0fb9f8210ed5c8e32d]
20:52:24Araqhmm no, I misread your example
20:52:31Araqwith 'return different' it works for me
20:52:55Araqah your version looks good too
20:54:05*navin quit (Remote host closed the connection)
20:54:26*navin joined #nim
20:55:51FromGitter<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:45Araqyou're welcome
21:01:01*navin quit (Remote host closed the connection)
21:08:35FromGitter<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:15AraqI 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:26FromGitter<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:07FromGitter<timotheecour> (it gives incorrect results)
21:25:18Araqoh man why don't we compute the diff via dynamic programming
21:27:11FromGitter<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:52FromGitter<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:26FromGitter<timotheecour> using a big enough hash so that probability of collision = small enough in practice.
21:29:58Araqhashing in Javascript wasn't really fast when we tried it but we were concerned about this "small enough in practice"
21:31:55dom96How do I disable the new warnings for unused imports?
21:32:26Araq{.used.} pragma in the module you want to have
21:33:44FromGitter<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:08Araqnah but I don't remember the details. however, the fact that you cannot hash closures doesn't help
21:35:25dom96Araq, `import strutils {.used.}`?
21:35:45Araqdom96: that doesn't exist :P
21:36:04FromGitter<timotheecour> `used` goes inside the imported module , not the importing module
21:36:04Araqclean up your code instead
21:36:10dom96Araq, isn't there a command flag?
21:36:24Araq--warning[x]:off ?
21:36:38Araqwhere the 'x' is mentioned in the warning
21:36:43dom96okay
21:37:05Araqyou need to write more nim, you're rusty
21:37:12dom96ugh, now I remember why nimble generates the temporary .nims file beside .nimble every time it executes :(
21:37:37dom96Araq, 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:57dom96also, there was always the possibiity that you implemented these warnings in some undisableable manner
21:38:15dom96anyway, I'm making it so that Nimble doesn't remove the temp files it creates when executed with --debug
21:38:40Araqjust don't remove temp files when stuff goes wrong
21:38:51Araqand maybe never remove it, it's temp already ...
21:40:33dom96the .nims file that gets generated each time nimble runs isn't in /tmp...
21:40:47dom96also, I don't think OS' remove /tmp as often as we'd like
21:41:13dom96it's easier to implement this using --debug for now.
21:43:53Araqthat's good to know
21:44:02AraqI never saw any .nims files though
21:44:15*solitudesf- quit (Remote host closed the connection)
21:44:26Araqbut 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:24dom96yes, this bothers me too, trust me
21:46:33dom96shashlick, I can vaguely remember why this .nims file is generated beside the .nimble file, can you remind me the reasons fully?
21:48:38PMunchOkay, the tests are green now dom96: https://github.com/nim-lang/Nim/pull/12221
21:49:07dom96Araq, please review ^
21:57:31*Hideki_ joined #nim
22:00:13FromGitter<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:09dom96nope, have you tried googling around for that error message? (It comes from the OS)
22:02:02FromGitter<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:07shashlick@dom96 cause imports and files are relative to the project dir
22:09:17shashlickSince that's where the nimble file is
22:09:24shashlickSo have to run in the same place
22:09:35shashlickElse we break a whole bunch of packages
22:10:37dom96ahh yes, that sucks
22:10:45dom96nim e needs a stdin mode
22:10:54dom96and to take the CWD as the project dir
22:11:25dom96but then debugging this will be harder :(
22:28:53FromGitter<mratsim> btw, this PR has been ready for about 3 weeks: https://github.com/nim-lang/Nim/pull/11816
22:29:46FromGitter<mratsim> also @Araq, didn't you have a RFC/master plan for the future of the stdlib? I can't find it
22:34:44dom96If you guys are bored, please get the new Nimble and test `nimble run`: https://github.com/nim-lang/nimble/commit/c834faf60e1dbdd8ae46456e1fb2dc2db05e4e91
22:34:56dom96That took longer to implement than I thought :)
22:39:25Araqmratsim: never finished that RFC
22:39:58FromGitter<mratsim> I think it should be done before 1.0 and linked into the release announcement
22:40:13FromGitter<mratsim> to manage people expectations
22:46:05dom96well... that's annoying
22:46:12dom96execCmdEx hangs when executing `nim e`
22:49:21Araqmratsim: ok, maybe
22:50:18Araqbut 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:56Araqbest example is Option[T], stuff works better when everybody uses the same Option T type
22:51:00Araqgood night.
22:53:10disruptekit's saturday night, get busy toasting nim 1.0.
22:53:25dom96anybody up for a riddle?
22:53:36disrupteksure, lay it on me, boss.
22:53:42dom96https://github.com/nim-lang/nimble/pull/711
22:53:48disruptekdamnit.
22:53:58dom96Why does execCmdEx stall? :P
22:54:16disruptekyou have a strange idea of comedy, dom. :-P
22:55:01dom96wouldn't be surprised if this is macOS only too :/
22:55:36disruptekis it compile-time?
22:56:36FromGitter<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:40disrupteki wonder if this is due to the recent changes to protect against tooling staticExec'ing stuff.
22:57:19disruptekmratsim: i almost hate to ask, but what's the issue between byte != string?
22:57:49FromGitter<mratsim> binary = seq[byte], for human consumption = string
22:58:18disruptekyes, but where do they currently differ? and no hand-wavy differences, please.
22:58:20FromGitter<mratsim> bonus: unvalidated human inputs = TaintedString
22:58:37FromGitter<mratsim> they differ in type?
22:59:03disruptekso, syntax, not semantics? because only host/net endianess keeps me up nights.
22:59:23FromGitter<mratsim> it's not syntax, it's semantics
22:59:43disrupteknot if we treat strings as binary and vice-versa.
23:00:24FromGitter<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:33FromGitter<mratsim> implicitly*
23:00:35disrupteknoted.
23:00:43disrupteki'm drunk, but i'm not stupid.
23:00:59dom96might be a bit too late for this to become accepted practice
23:01:11disruptekstill, what's the practical breakage example?
23:01:20dom96strings are going to contain binary data, you can do nothing about that
23:01:23FromGitter<mratsim> I don't think so, I think it's a good time
23:01:25*nsf1 quit (Quit: WeeChat 2.5)
23:02:10disrupteki think that's nuts, honestly. it's too late to do much of anything for 1.0.
23:02:16FromGitter<mratsim> As Nim matures there will be future core API that will probably need to be revisited
23:02:25FromGitter<mratsim> I'm not saying we change for v1.0
23:02:36disrupteksure, sure, but what's your example to rile my blood lust for byte?
23:02:53FromGitter<mratsim> I'm saying we have a plan to handle future needs of the standard library
23:03:13FromGitter<mratsim> You can read more here: https://github.com/nim-lang/RFCs/issues/32
23:03:45disruptekwhy 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:54disruptekeven more so while i'm three sheets to the proverbial wind.
23:04:15disruptekbtw, do you guys actually use nimsha2?
23:04:15*nif_ quit (Quit: ...)
23:04:25*nif joined #nim
23:05:28disrupteki'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:49FromGitter<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:05FromGitter<mratsim> no we don't use nimsha2, we use nimcrypto
23:07:35disruptekfail enough, that's why i chose nimcrypto.
23:07:39disruptek^fair too.
23:08:46FromGitter<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:51disrupteki agree with that list except for databases (have no idea what exists currently), bigint, and strutils.
23:09:13disruptekokay, but we need the horrible hairy example so we can all feelsbadman.
23:09:18FromGitter<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:55disruptekwrappers 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:10FromGitter<mratsim> but it seems to be all low-level so
23:10:28disruptekmaybe ormin should move into stdlib and become a basis for something more.
23:11:10disruptekhonestly, this just doesn't feel like a good excuse to put databases on a mcarthy list.
23:11:59disruptekit'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:48FromGitter<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:48FromGitter... [https://gitter.im/nim-lang/Nim?at=5d86ae70e45b6d473233d34f]
23:13:50dom96mratsim: if you really want a distinct type for collections of bytes then you'll need to break a lot in the stdlib
23:13:54disrupteklook, 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:06disruptekyou are worried about supporting users that don't exist.
23:14:27disruptekas my accountant told me when i started my last company, worry about profits first, then we can talk about taxes.
23:14:47disruptekactually, that was three companies ago and i was profitable in the first 3 weeks, but i digress...
23:15:05FromGitter<mratsim> managing expectations is important
23:15:44disruptekhe 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:36FromGitter<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:41disruptekimo 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:06disruptekso what? you're here because nim. if you make nim equal go, you've lost the battle already.
23:17:24disrupteki mean, c'mon, man.
23:17:40disruptekyou have to bake into nim what it is that separates it or it will no longer be separated.
23:18:17FromGitter<mratsim> well, I'll do something productive instead of discussing with drunk people.
23:18:24disruptekpffbt.
23:18:39dom96hah, fair
23:19:01disrupteki mean, i won't argue _that_ point, but still... feel free to ignore my perfectly valid criticisms of your argument.
23:19:53dom96disruptek, what are these profitable companies you speak of? You don't happen to be one of those Sillicon Valley unicorns, do you?
23:20:10disruptekwhen did i say anything about a profitable company?
23:20:29dom96"actually, that was three companies ago and i was profitable in the first 3 weeks"
23:20:32disruptekoh. 3 weeks. back when i was a rare coin dealer. do you want to buy some antique gold coins?
23:20:53dom96that depends, will I need to ask my friends to buy them off me?
23:21:02disruptekwhat would be the point of that?
23:21:23disruptekyou 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:36disruptek^ intrinsic, either.
23:22:15*Hideki_ joined #nim
23:24:08disruptekthe 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:00disrupteklet 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:00disruptekokay, 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)