<< 22-09-2019 >>
00:00:02*junland quit (Quit: %ZNC Disconnected%)
00:01:21*junland joined #nim
00:15:25*Hideki_ joined #nim
00:29:52*krux02 joined #nim
00:33:55*Hideki_ quit (Remote host closed the connection)
00:37:41*dddddd quit (Remote host closed the connection)
00:37:44*Hideki_ joined #nim
00:42:40*Hideki_ quit (Ping timeout: 268 seconds)
01:05:32*Hideki_ joined #nim
01:27:20*owl joined #nim
01:40:21*Hideki_ quit (Remote host closed the connection)
01:40:39*Hideki_ joined #nim
01:53:43*rayman22201 joined #nim
01:54:07rayman22201Hi, been a while. @dom96 would you happen to still be awake?
01:54:42rayman222013 am there. probably not. damn
01:55:15rayman22201any other nim people awake right now? lol
02:28:51leorizeam I counted as nim people? :P
02:29:07rayman22201maybe. :-P
02:29:23rayman22201how good is your knowledge of the async code leorize?
02:29:48*Hideki_ quit (Remote host closed the connection)
02:31:37leorizeenough to use it :P
02:32:03*Hideki_ joined #nim
02:33:22rayman22201lol. That may not be enough
02:34:11rayman22201I am finally doing the big AsyncEvent refactor that I promised to finish a month ago... Somehow, I got into a situation where asyncDispatch is eating exceptions and I have no freaking clue why.
02:34:28rayman22201I'm deeeeeep down the rabbit hole here lol
02:34:35leorizetry --expandMacros to get the generated code?
02:34:56leorize--expandMacro I mean
02:35:08rayman22201did that. All looks good. I didn't change the macro generation anyway, so that shouldn't matter...
02:36:04rayman22201I'm printf debugging. The exception callback gets put on the callback queue correctly, then it suddenly disappears when the runloop actually goes to run it.
02:36:06rayman22201very strange
02:36:17*Hideki_ quit (Ping timeout: 246 seconds)
02:39:44leorizeis your code up somewhere? I might be able to take a look
02:41:23rayman22201Not yet. It's kind of a mess with print statements right now lol
02:42:09rayman22201I could screen share if you are up for it
02:49:37*theelous3 quit (Ping timeout: 245 seconds)
03:04:23*krux02 quit (Remote host closed the connection)
03:06:02*lritter quit (Ping timeout: 240 seconds)
03:06:58*lritter joined #nim
03:09:03disruptekexceptions in async are a mess, afaik. i think dom told me recently that they were fixed, but i honestly did not notice a change to the good.
03:09:26rayman22201They are a mess. but in his defense it's a hard problem.
03:09:57disrupteki know, but i guess what i'm saying is "fixed" is a frame of reference that may well vary even among nimmers.
03:10:39rayman22201I think that is true for most things in life. "fixed" is relative to the amount of BS you are willing to put up with.
03:10:50*Hideki_ joined #nim
03:10:53disruptekmy solution is to remove exceptions from all my code, but that's partly motivated by bugs (read: feelings) about current exception handling.
03:11:18rayman22201I can't disagree with you.
03:11:33rayman22201unfortunately I'm working on stdlib code, so I have to account for them :-(
03:24:18rayman22201I'm beginning to wonder if this is a bug, or if I fixed a bug...
03:24:22rayman22201look at this: https://github.com/nim-lang/Nim/blob/devel/tests/async/t8982.nim
03:24:48rayman22201Would expect the exception in failingAwaitable() to fire?
03:24:54rayman22201would you*
03:26:29disruptekno, because the program ends after the shorter future completes.
03:27:07*Hideki_ quit (Ping timeout: 245 seconds)
03:27:27rayman22201exactly.
03:27:42rayman22201but the test expects the exception to be thrown?
03:28:37rayman22201also, "runForever()" is an infinite loop.... if anything bad were to happen in this test (like say swallowing exceptions...) this test will just hang and run forever??
03:29:07rayman22201hrmmm.... I think this may be a bad test
03:29:07disrupteki think we spoke about exceptions earlier. 😉
03:30:03disruptekwhat are you trying to exercise?
03:30:18disrupteksorry, i guess i'm coming in late and missed the backstory.
03:31:36disruptekwhat i mean is, are you looking for different behavior?
03:32:07rayman22201This is a complete tangent. I am rewriting the AsyncEvent implementation b/c of this: https://github.com/nim-lang/Nim/pull/11724#issuecomment-522113239
03:32:16rayman22201and in the course of my rewrite, I broke this test
03:32:59rayman22201specifically, I'm doing "#2. The stdlib ioselectors needs to be fixed so that it does not eat up all of the socket fd's on your system."
03:34:16disruptekokay.
03:34:21rayman22201The more I think about it, the more I'm confused about how that test worked in the first place...
03:36:13rayman22201essentially, the future inside "failingAwaitable" was able to continue to run even though the 'or' completed....
03:36:16disruptekit's not swallowing anything.
03:36:35disruptekor, at least, it shouldn't be. it should not run because it should get torn down when main leaves scope.
03:36:57rayman22201but it does run. look at the expected output of the test
03:37:10rayman22201it does not run on my branch with the rewrite though :-P
03:37:34rayman22201the problem is, I don't know exactly why! And that scares me...
03:38:11disrupteki'm not familiar with the impl, but how/where does it deregister?
03:38:40rayman22201part of the issue here, is that Nim futures don't have a "cancel".... I think that is a huge flaw in the design... but I digress...
03:38:46disruptekmy expectation is that without a destructor mechanism...
03:39:46disruptekwow, i don't think i've ever seen these docs. i wonder how i ever managed to use this thing.
03:40:42rayman22201lol
03:41:56disruptekwell, to me, your code is correct.
03:42:41disruptekit seems like we expected the exception due to the circumstances and merely ack it and move on. but, it's obviously not ideal. the only concern i have is, can you confirm that the failableFuture is running?
03:45:10rayman22201aha! good point. It is in fact running in both cases. There is something else going on here
03:45:25rayman22201I think I know what it is too. running a test. hold on
03:45:53disruptekwell, it runs, it gets deregistered (somehow), and all is right in the world. except what?
03:48:05rayman22201It's a completely different exception. "No handles or timers registered in dispatcher."
03:48:25rayman22201an internal exception gets thrown when the async Dispatcher has nothing to dispatch
03:48:37disruptekyou mean in your code or in trunk?
03:48:48rayman22201that's in trunk.
03:49:01rayman22201but in my fork, it always has something to dispatch because I keep an internal global handle that it listens on.
03:49:13disruptekah, so that's fine.
03:49:28rayman22201It's multiplexer pattern. One real file handler -> many virtual file handles
03:49:46disruptekso, easy to complete your impl.
03:50:28rayman22201I have to fix that test, and any other test that relies on the behavior from trunk.
03:50:53rayman22201but at least I think my impl is good now. I thought I was going crazy.... thanks for your help
03:50:57disruptekthis is breaking for code in the wild.
03:51:07disrupteki mean, the test isn't the main worry, right?
03:51:29rayman22201hrmmm. true
03:52:00disruptekyour impl needs to change to not throw at count=1 or w/e semantic you detour to.
03:52:30disruptekor throw at 1. whatever. only you know how your thing works. :-D
03:52:32rayman22201yeah...
03:52:54rayman22201ugghhh.... I love when I have put bugs back in to maintain compatibility
03:52:59disruptekikr?
03:53:17disruptekwhen bugs become technical debt.
03:53:46rayman22201shhh.... while Dom is sleeping.... another reason Chronos is better :-P
03:54:06disruptekmaybe you can have a different runForever or something; a new interface.
03:54:52rayman22201nah. I'm just going to keep it bug compatible.
04:00:32disruptekwell, happy birthday, nim, and congrats.
04:02:00rayman22201Here is the shitty part... I don't know if the current api will let me easily do this :-(
04:02:27*chemist69 quit (Ping timeout: 264 seconds)
04:03:55*chemist69 joined #nim
04:07:45rayman22201well, time to add a new proc to the selectors api. Happy birthday indeed lol
04:13:49FromGitter<ShieldHero> is there a reason why repr isn't working with newruntime?
04:14:46disruptekyes.
04:15:16FromGitter<ShieldHero> what is it? D:
04:20:49disruptekof that, i'm afraid, i have no idea.
05:18:45AraqShieldHero: repr relies on the old RTTI and I replaced the RTTI subsystem by something much smaller
05:19:22*owl quit (Read error: Connection reset by peer)
05:19:49*owl joined #nim
05:21:45*bozaloshtsh_ quit (Quit: ZNC 1.7.2 - https://znc.in)
05:21:53*bozaloshtsh joined #nim
05:21:54*bozaloshtsh quit (Changing host)
05:21:54*bozaloshtsh joined #nim
05:28:14*Hideki_ joined #nim
05:31:10Zevvoi rayman22201, still stuck?
05:36:10rayman22201Hi @Zevv. I think I got it. I'm now curious about this: https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L1206
05:36:42rayman22201why should we not call other callbacks?
05:36:56Zevvpff dropping cold in, let me see what that's all about :)
05:38:18rayman22201lmao
05:38:26Zevvyeah sure :)
05:38:32rayman22201actually, I think I convinced myself it's correct
05:38:39rayman22201:-P
05:39:49rayman22201fun fact. Did you know there are no tests for AsyncEvent?
05:40:26ZevvI suspected something along that lines. It is pretty hard to efficiently test those with real time and real events.
05:40:46rayman22201I'm writing some now, and then I think I will finally be able to make a PR for this thing.
05:41:19ZevvI suggested yesterday that we should add a simulation of the lowest primitives, for example make a 'test ioselector'. That could fake time and I/O and would allow testing of all the layers above.
05:41:22rayman22201iirc you actually did a version of this fix right, but you never pushed it anywhere? or I forgot where it was anyway :-P
05:41:58Zevvhm let me check my stale branches
05:42:18rayman22201So, in my version, I actually did it at the asyncDispatch level, and not at the ioselector level. That way it's abstract enough to work with all the selector backends
05:42:52Zevvso the selector backends can now have different behaviour without anyone noticing :/
05:43:13rayman22201lol, that is the point of abstraction right :-P
05:43:44ZevvI have three branches with 'event' in the name, but none of them make sense to me now
05:44:05rayman22201lol. It's ok. I will hopefully push soon, and you can just tear my version apart in code review
05:44:20*Hideki_ quit (Remote host closed the connection)
05:44:27Zevvgood work dude
05:44:55rayman22201sorry I didn't get it in earlier :-/ work has been crazy. This is the first Saturday I have had free.
05:44:58ZevvPMunch was also bughunting async stuff the other day, the infamous 500msec thingy
05:45:29*Hideki_ joined #nim
05:45:37FromGitter<ShieldHero> was this issue fixed? ⏎ https://github.com/nim-lang/Nim/issues/3900
05:45:53rayman22201@Zevv I think I saw the PR for that come through. looked like a "fun" bug hunt...
05:46:33FromGitter<ShieldHero> when I was testing dll i never considered inheritance
05:50:17*Hideki_ quit (Ping timeout: 265 seconds)
06:12:56rayman22201apparently the locks module has a dependency on threads:on, and just doesn't tell you. instead you linker error :-)
06:13:58rayman22201locks depending on threads makes sense, but it's just weird because threadpool gives you a nice, "you must have threads:on" compiler warning
06:17:35rayman22201well, that's fixed in my branch now too
06:22:22*Hideki_ joined #nim
06:31:38*Hideki_ quit (Ping timeout: 240 seconds)
06:34:25Zevvwasn't threads:on supposed to become the default one day
06:44:53*Vladar joined #nim
06:46:14rayman22201idk, but that day is not today lol
06:47:47rayman22201I just finished puking `when compilerOption("threads")` all over my code... ugly, but necessary since async has to work in both contexts
06:49:38*narimiran joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:55*gmpreussner joined #nim
07:10:48FromGitter<arnetheduck> rayman22201, fwiw cancellation support is in chronos futures
07:11:04rayman22201I know :-)
07:12:20FromGitter<arnetheduck> and fwiw, not even interfaces need to be in stdlib - if there's a library that's dominant it can offer an extensible interface on its own without tying it to specific nim versions.. that of course requires there's good package management available so the difference in "difficulty" to start using the library is comparable to using the stdlib
07:14:15*nif quit (Quit: ...)
07:14:25*nif joined #nim
07:15:06FromGitter<arnetheduck> Araq, got a link to the smaller RTTI commit? I'm probably going to ditch stuff like `genericReset` in `nlvm`, it's really slow and I'm not sure there's really that much economy in it (specially because it prevents inlining and other tricks)
08:15:32*nsf joined #nim
08:19:19FromGitter<mratsim> when you inline you actually also get genericReset
08:19:24rayman22201@arnetheduck are you trying to tell me to stop contributing to the stdlib? lol
08:19:43FromGitter<mratsim> sometimes I used templates specifically to avoid genericReset being added at the beginning of my proc
08:22:06FromGitter<mratsim> the issue is when there are conflicting interfaces between that library and the standard library. And I'm not talking about chronos because the interface is the same, but more about streams for example
08:25:55rayman22201I don't really understand the context of @arnetheduck's interface comment?
08:29:08FromGitter<mratsim> the discussion from yesterday
08:29:47*owl quit (Ping timeout: 265 seconds)
08:29:53FromGitter<mratsim> https://irclogs.nim-lang.org/21-09-2019.html#22:29:46
08:30:53FromGitter<mratsim> irc rendering is incredibad: https://gitter.im/nim-lang/Nim?at=5d86ad09a38dae3a63951bf8]
08:36:13rayman22201thanks @mratsim
08:36:43*laaron quit (Remote host closed the connection)
08:41:08*thomasross quit (Remote host closed the connection)
08:41:31*navin joined #nim
08:41:34*thomasross joined #nim
08:52:36dom96how is that rendering bad on IRC?
08:55:21dom96rayman22201, what are you working on?
08:55:42dom96oh, you're rewriting AsyncEvent
08:55:44rayman22201the thing I promised a 3 weeks ago lol. better AsyncEvents
08:56:04dom96Will it require breakage?
08:56:10rayman22201It's pretty much done. I'm just writing tests now.
08:56:13dom96if yes then you need to get it in Nim ASAP
08:56:22dom96cool
08:56:26rayman22201No. I think it should be compatible
08:56:44dom96even better :)
08:57:06*rayman22201 crosses my fingers
08:58:29rayman22201this will make the flowVar PR work, but idk if there is enough time to get both this in, and the flowVar PR in.
08:58:54dom96if neither cause breaking changes then that's fine
08:59:30rayman22201the flowVar PR is just a new feature I guess, so sure?
09:14:53*narimiran quit (Ping timeout: 245 seconds)
09:42:38*PMunch joined #nim
10:05:26rayman22201https://github.com/nim-lang/Nim/pull/12232
10:05:34rayman22201🎉
10:08:05PMunchHmm, I get warning saying isSpaceAscii has been deprecated from v0.20, but it's not mentioned in the docs
10:09:07rayman22201is there no networkStream or socketStream in the stdlib? I thought there was?
10:12:14YardanicoAFAIK there's no such a thing, I used stringStream for my needs (for a simple android debug bridge IP scanner), but I think that it's possible to implement them without too much hassle even outside of stdlib
10:16:03rayman22201yeah. it's no problem. I just thought I saw it in the docs at one point. thanks :)
10:17:23dom96are you thinking of asyncstreams?
10:19:18rayman22201probably. It's really late for me lol
10:19:46PMunchYeah there are network and socket streams in asyncstreams I think
10:23:39shashlick@dom96 looks like you are going thru nimble like a boss
10:23:46dom96:D
10:23:58dom96Doing my best :)
10:24:32shashlickLooks like we still don't have a windows CI
10:24:36rayman22201https://nim-lang.github.io/Nim/asyncstreams.html no socket streams that I can see?
10:26:13rayman22201lol. Nim 1.0 feels like college. The weekend before the final project is due everybody is scrambling to finish their projects :-P
10:26:25dom96hah
10:27:18shashlickThat's why I am pushing back for any last minute stuff since it will surely break something
10:28:58*Hideki_ joined #nim
10:29:03shashlick@dom96 I'm looking at your changes and issue comments
10:29:11dom96that's where 1.0.2 comes in ;)
10:29:20shashlickAnything specific I could help with?
10:30:37dom96Wanna give one of the issues a go? For example this one: https://github.com/nim-lang/nimble/issues/525 (yeah, it's a new feature but it shouldn't affect anything else)
10:31:17lqdev[m]rayman22201: not me, lol
10:32:36shashlick@dom96 https://github.com/nim-lang/nimble/commit/445ecfe9461029184c1e710902262e2149a3564b#diff-1c237a28a78549fe7b135026560d6efaL90
10:33:03shashlickYou removed the code but didn't add isSuppressed - is that intentional?
10:33:22dom96yes, it's handled in displayLine now
10:34:09shashlickBut all that processing for nothing
10:34:11*Hideki_ quit (Ping timeout: 276 seconds)
10:34:13shashlickAnyway
10:36:16*krux02 joined #nim
10:36:48dom96shashlick, feel free to implement Windows CI if you're up for it, that will probably be the most impactful
10:39:11shashlick@dom96 - https://github.com/nim-lang/nimble/commit/36c4a39674c0f81baa87d930265f5903d7a32fed#diff-207d4044eeccdbc778987497fffd081eR39
10:39:26shashlickNimsOutfile is in the project directory
10:39:44shashlickIt is present in the temp folder and just copied over
10:40:03shashlickInstead you could just print the temp file location in debug mode
10:40:28shashlickElse you can end up with multiple nims files in the project dir
10:40:38dom96fair, but this is for debugging anyway
10:40:47dom96doesn't have to be perfect
10:41:39shashlickCould just print nimsFile
10:41:42shashlickhttps://github.com/nim-lang/nimble/commit/36c4a39674c0f81baa87d930265f5903d7a32fed#diff-207d4044eeccdbc778987497fffd081eR35
10:43:00shashlickEvery nimble invocation results in a unique filename since it uses the process id
10:43:50shashlickSo you run debug multiple times or run recursively, will end up with a flood
10:45:18shashlickout File contents also returned, could just print it if debug
10:45:57dom96the debug switch is for debugging, people shouldn't use it in scripts
10:47:07dom96the idea is to keep files that are used by nimble
10:47:20dom96so that I can copy and paste the command it invokes
10:47:22dom96and it'll just work
10:47:34dom96(or much more likely not work since I am debugging an issue)
10:48:31dom96so, are you able to tackle any of these issues?
10:48:37Zevv"thanks for giving it a shot :)", hehe
10:48:40dom96and/or Windows CI
10:49:13dom96it looks like I'm going to need to redirect the output of `nim e` btw
10:49:33dom96that's the only way to workaround https://github.com/nim-lang/nimble/pull/711
10:49:50dom96and it seems that stdout/stderr redirection syntax is at least consistent between windows cmd and bash
10:51:01shashlickIf it runs in the foreground why doesn't it print the error right there
10:51:15dom96yeah, it does, but it prints it in random places
10:51:17dom96that's not good UX
10:51:29shashlickWhat do you mean by random
10:51:47dom96I mean it's not in the error message that people read
10:52:01dom96You get "Failed to parse .nimble file; because nimscript eval failed with:"
10:52:05dom96and then it's just empty
10:54:13shashlickis this the part where we get package info?
10:54:22dom96I ask once again, are you able to help with any issues/Windows CI or not?
10:54:33dom96it's fine if not, just say so
10:55:21shashlicki'm reviewing your code changes right now
10:55:29shashlicki can do windows CI or issues
10:55:38PMunchHmm, going through all my packages making sure that they work with 1.0. I hit this error with binaryparse: Error: internal error: environment misses: :tmp
10:55:42shashlickwas looking into this issue you brought up
10:55:46PMunchAnyone got a clue on what that might be about
10:56:00dom96shashlick, okay, please do windows CI, i'll work through the issues
10:56:10PMunchIt is reported from a line `let ii = genSym(nskVar)` but I think the actual error occurs somewhere else
10:56:41dom96PMunch, that suggests it cannot capture whatever `:tmp` is in a closure
10:59:49PMunchHmm
11:01:30dom96Anyone want to help me out by going through my Nimble projects to make sure they work for 1.0? :)
11:02:23rayman22201So this is interesting: https://travis-ci.org/nim-lang/Nim/jobs/588053879
11:02:51rayman22201It looks like several tests that should be compiled with threads:on were not compiled with threads, and everything still worked?
11:03:32*owl_000 joined #nim
11:05:57owl_000float(num), num.float(), num.float is really convenient. though they are doing same things but give different feels. first i thought it is awkard, but it is awesome.
11:06:03rayman22201sharedlist.nim without threads:on doesn't make a lot of sense...
11:06:52Yardanico owl_000 yeah, I like UFCS a lot and miss it in other languages
11:07:36PMunchAha, figured out what the issue was (expandMacros is pretty neat by the way). The `ii` variable was used for iterating over stuff. But I used the same genSym'ed variable in both the reader and the writer, which Nim seems to now dislike
11:07:52PMunchCreated one iiRead and one iiWrite fixed the issue
11:07:59rayman22201ok. gn. It's 4am for me. Good luck before the 1.0 release everybody :-)
11:08:19*rayman22201 quit ()
11:08:21PMunchOh wow, good night ra
11:08:24owl_0007 PM HERE
11:08:30PMunchIt's 1PM here..
11:09:10Yardanico2PM here :)
11:09:34PMunchIt's a bit unfortunate though. I mean for this use case it's fine, just add a second variable. But if you needed to create lots of them, or dynamic ones, or want to reuse the same body across many procs, this probably won't work properly..
11:09:44PMunchAnd the error is really hard to understand..
11:11:31shashlick@dom96 - tests are failing on HEAD
11:14:20shashlick@dom96 - you really need to update https://nim-lang.org/choosenim/init.sh with the latest in the choosenim repo
11:14:28shashlickhttps://github.com/dom96/choosenim/blob/master/scripts/choosenim-unix-init.sh
11:21:04*navin quit (Remote host closed the connection)
11:24:01PMunchHmm, related issue to this (I think) is that if you want to forward declare a proc in two different "quote do" statements all the arguments must use the exact same identifiers..
11:24:50PMunchOtherwise you get errors with ambiguous call between the forward decl and the procedure decl
11:26:15shashlick@dom96 `--warning[UnusedImport]:off` breaks on 0.19.6 and 0.20.2
11:29:01PMunchGreat, now I get "Error: attempt to redefine `:tmp`".. It should really specify which :tmp..
11:30:26PMunchOh well, got to go
11:30:27*PMunch quit (Remote host closed the connection)
11:40:10dom96argh, I thought that might happen
11:42:13dom96it still annoys me that GitHub shows cancelled CIs as a fail
11:45:56*ng0 joined #nim
11:45:57shashlickcan you please update the choosenim init file as well, i added msys support in april
11:47:41dom96I thought I updated that already
11:48:00*Hideki_ joined #nim
11:48:31dom96updated
11:49:19shashlickawesome
11:53:15dom96oh boy, so it looks like this is a `nim e` bug
11:53:25dom96it stalls if I redirect its output to a file
11:53:26dom96even in bash
11:53:29shashlicklooks like i still need https://github.com/dom96/choosenim/commit/121133ba06b0954e058d38743a18fe1ad1f817f2 to get choosenim working in windows git bash
11:53:53shashlicklatest release binary doesn't have that fix
11:54:07shashlickwill have to use my custom build like i did for feud - https://github.com/genotrance/feud/blob/master/.travis.yml
11:54:17dom96oh, no, I'm just being stupid it looks like
11:56:11*navin joined #nim
11:57:38*thomasross quit (Remote host closed the connection)
11:58:03*thomasross joined #nim
12:00:39*navin quit (Ping timeout: 264 seconds)
12:01:51*gangstacat quit (Ping timeout: 252 seconds)
12:04:01lqdev[m]does Nim have support for filesystem events?
12:04:19lqdev[m]or is there a library for that?
12:05:36shashlickfswatch or something right
12:05:44lqdev[m]yeah
12:06:00lqdev[m]basically, something that would allow me to trigger a resource reload when a file is changed
12:07:17lqdev[m]seems like federico3 has a wrapper for that library
12:09:34dom96You should get your hands dirty and implement one that works for asyncdispatch :)
12:09:49dom96I created a linux-only module that worked with the old asyncio module we had
12:10:22dom96https://forum.nim-lang.org/t/3159
12:11:55lqdev[m]dom96: I already have enough projects I'm working on :P
12:12:01lqdev[m]maybe someday
12:13:08lqdev[m]dang it, seems like fswatch is blocking
12:13:25lqdev[m]guess I'll just implement a keyboard shortcut or dev command that'll be used for reloading
12:15:22lqdev[m]imagine Vim-like commands in a game lol
12:44:02*Perkol joined #nim
12:47:52owl_000i want to make a simple package, so that i can import it like other packages. so what should i choose in "nimble init package type", binary or library
12:48:27dom96library
12:49:07Yardanicoowl_000: binary is needed if you create a tool which will be used by itself (not from other libraries), library is for usage in other libraries, hybrid is both I think
12:50:14FromGitter<de-odex> is there a reason to want a heap allocated object (ref object) over a stack allocated one?
12:50:40Yardanicofor example if you want to pass it to other functions/have it in other objects as a reference
12:51:03Yardanicofor recursive dependencies (e.g. a Node object which has two fields of type Node)
12:51:33FromGitter<de-odex> cant you still pass stack allocated objects to functions?
12:51:35Yardanicowell, you can pass stack-allocated objects to functions as well via "var MyType" type
12:51:49Yardanico(that's if you want to modify it)
12:52:02*oculux quit (Ping timeout: 240 seconds)
12:52:06Yardanicoif you just need to read it, you can just pass it as "MyType" type
12:52:10FromGitter<mratsim> somehow I managed to "trick" Nim into generating int instead of NI32 and it breaks with the C++ backend :/: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d876e7ae45b6d473238b574]
12:53:03FromGitter<mratsim> use ref object when you want reference semantics
12:54:55*Kaivo joined #nim
13:01:21*oculux joined #nim
13:01:54*gangstacat joined #nim
13:02:07dom9610 down, 5 more to go :O
13:02:38dom96Could really use some testers, if you're around and want to test the latest Nimble release, please do so
13:05:22lqdev[m]is there a replaceAll for strings? I need to remove all whitespace from a string.
13:05:59Yardanicolqdev[m]: I think multiReplace is the closest you can get
13:07:43shashlick@dom96 - can you please use branches? if master is broken i cannot get windows CI working
13:08:32lqdev[m]Yardanico: yeah, that seems to work
13:08:42lqdev[m]I thought it'd only replace one occurrence of each word
13:08:57Yardanicoah, no, replace and multiReplace replace all occurences
13:08:57dom96shashlick, why can't you?
13:09:24lqdev[m]yeah I just checked that and that's true
13:10:12shashlickno way to tell if the break is windows specific or related to your changes
13:10:49shashlickbesides i'm working in parallel, do you really want me to sit and look at your every commit and travis run
13:11:29dom96no, what I don't understand is why you're worrying about master anyway
13:11:39dom96you should pick a commit that passed travis and get CI working off it
13:14:33shashlickdo i really need to justify not using master? anyway, its your project
13:15:01*federico3_ is now known as federico3
13:16:01dom96why would you follow a moving target?
13:16:21dom96even if I made sure to push all commits that pass travis to master who knows, they might still break windows in some way
13:17:11shashlickthat's exactly what i should focus on - master should pass all tests that exist today, not break on the existing test matrix
13:18:54dom96You should first set up a foundation, once a known good commit of Nimble works you can rebase on whatever new commits have been made on master
13:19:54dom96What is your actual approach here because I don't understand. Are you pushing Ci changes directly to master on your fork?
13:20:20shashlicki'm working on a branch which is tested on my instance of nimble on travis
13:20:48shashlickyou can do the same - if you create a branch and push, it will get tested on travis
13:21:10shashlickwhy would you use master to test
13:22:10dom96I know I can do the same. But I want to move fast today so I don't want to be creating multiple branches that I then need to keep track of.
13:22:44dom96There should be nothing wrong with master being broken for a couple of hours.
13:23:17shashlicki understand and don't want to slow you down but you can get the same effect working on one branch and push it when you are satisfied
13:23:51shashlickanyway, go ahead, i'll have to create a new branch from an older commit now to figure this out
13:24:14dom96Yes, I can, but you can also work off a known working commit
13:24:20shashlickand then afterwards, will have to again check that your passing code works on windows
13:24:55dom96And you should be doing that anyway
13:26:32shashlicki don't think you get the point but anyway, i'd rather work on getting something working
13:27:32*navin joined #nim
13:27:47dom96Even if I were to work on another branch, eventually it would end up in master and you or I would need to again check that it passes on Windows.
13:29:11shashlickbut my windows CI PR won't get merged until everything passes
13:29:31shashlickwhich means while you are moving fast, you won't have any benefit of any windows testing
13:32:55*owl_000 quit (Remote host closed the connection)
13:33:03dom96Yes, but to be honest I would rather leave all Windows-related fixes till the end.
13:33:14*owl_000 joined #nim
13:34:04*owl_000 quit (Remote host closed the connection)
13:34:28*owl_000 joined #nim
13:36:21dom96Argh, the fact that there are compiler messages mixed with messages from Nimble scripts is annoying
13:42:16*navin quit (Remote host closed the connection)
13:50:08*thomasross quit (Remote host closed the connection)
13:50:33*thomasross joined #nim
13:51:48*solitudesf joined #nim
13:57:49*elrood joined #nim
13:59:35*navin joined #nim
14:01:14owl_000 is it possible to set default value of "type object", for e.g "type RGBA = object r:,g:,b:,a:", this case i want to set a = 255
14:01:42YardanicoI don't think so, you need to set default values in a constructor
14:02:02YardanicoYou can basically give almost any name to a constructor proc, but the conventional names are newType for ref object and initType for object
14:02:28Yardanicoso you'll need to create a initRGBA or initRgba proc and write defaults values in procedure arguments here
14:03:23owl_000oh i see, then i prefer not to do for that simple things
14:03:26owl_000thanks
14:04:11Yardanicowell it'll be 1 line : proc initRGBA(r, g, b: int, a = 255): RGBA = RGBA(r: r, g: g, b: b, a: a)
14:05:04*owl_000 quit (Remote host closed the connection)
14:05:08Yardanico:(
14:05:23*navin_ joined #nim
14:05:29*owl_000 joined #nim
14:06:23*Hideki_ quit (Remote host closed the connection)
14:07:11*Hideki_ joined #nim
14:08:43*navin quit (Ping timeout: 252 seconds)
14:10:28*Perkol quit (Remote host closed the connection)
14:11:56*Hideki_ quit (Ping timeout: 276 seconds)
14:12:51*navin_ quit (Remote host closed the connection)
14:14:30*navin joined #nim
14:18:49*Hideki_ joined #nim
14:18:55lqdev[m]owl_000: creating constructors for each object is a common convention, no matter what the object is
14:19:01lqdev[m]it just has so many advantages
14:19:04*navin quit (Remote host closed the connection)
14:19:10*navin joined #nim
14:20:05*navin quit (Remote host closed the connection)
14:20:14owl_000give me link to study about it.
14:20:32*navin joined #nim
14:20:47owl_000ok i got it.
14:22:45owl_000i make a `proc newColor(rgba=(int,int,int,int)):RGBA` and another overloaded proc to handle `rgb=(3int)`
14:23:00Yardanicowhy?
14:23:34Yardanicomaybe you didn't see my message: proc initRGBA(r, g, b: int, a = 255): RGBA = RGBA(r: r, g: g, b: b, a: a)
14:23:56Yardanicoyou can have default values for proc arguments in Nim
14:24:37*theelous3 joined #nim
14:24:53*navin quit (Ping timeout: 245 seconds)
14:26:11owl_000yes, i know, but somehow my brain can't remember it. strange
14:26:48*navin joined #nim
14:27:04owl_000such a simple thing.
14:30:09*navin quit (Remote host closed the connection)
14:37:38lqdev[m]owl_000: it's not a study, it's my own experience and the experience of others
14:38:00lqdev[m]1. you can have default parameters
14:38:05lqdev[m]2. you can overload such a constructor
14:38:11lqdev[m]3. the constructor can have side effects
14:40:32*navin joined #nim
14:42:14*dddddd joined #nim
14:44:39*navin quit (Ping timeout: 250 seconds)
14:56:11*kungtotte quit (Quit: WeeChat 2.5)
14:58:48*elrood quit (Remote host closed the connection)
15:18:53*navin joined #nim
15:19:11*navin quit (Remote host closed the connection)
15:20:00*navin joined #nim
15:20:21*navin quit (Remote host closed the connection)
15:22:07*PMunch joined #nim
15:22:12*Trustable joined #nim
15:23:48PMunchHmm, trying to get my protobuf library up and running on devel. But something with macros have changed.. Before you could use "quote do" to create small snippets of code and then later glue them together. But now I just get a lot of errors saying that my variables aren't defined..
15:24:35PMunchBut that might come from the fact that I changed my genSym calls to newIdentNode to avoid another issue I was having..
15:24:55lqdev[m]can someone help me with writing a good game loop which adjusts the game speed depending on the framerate?
15:25:50lqdev[m]my current (bad) implementation is based on http://gameprogrammingpatterns.com/game-loop.html, and can be found here https://github.com/liquid600pgm/rapid/blob/master/src/rapid/gfx.nim#L954
15:26:08lqdev[m]for some reason, the game runs too slow when I unlock the framerate
15:27:50disruptekPMunch: i don't know if it's new, but you have to create idents and then backquote them in the quote do: block. i've long had a suspicion that this was unintentional, but i really dunno since i'm new to macros.
15:28:35disruptek(otherwise they get gensym'd to foo`23423432 or whatever...)
15:28:54PMunchYeah, that's the first thing I noticed as well. It's really annoying..
15:29:39disruptekyeah, just look at how verbose this is: https://github.com/disruptek/openapi/blob/master/src/openapi/codegen.nim#L1052
15:31:14*owl_000 quit (Ping timeout: 276 seconds)
15:33:50*PMunch quit (Remote host closed the connection)
15:34:18*PMunch joined #nim
15:36:55PMunchI try with genSym(nskParam, "someName") and then I get `internal error: environment misses "someName"` (although echoing out the generated code with .repr looks fine. If I change to use newIdentNode I get errors from various quote do statements saying that the "someName" is undeclared..
15:37:31PMunchdisruptek, yeah exactly.. Not pretty
15:38:55PMunchCreating the code manually without quote do works fine..
15:41:45dom96 80% complete
15:41:48dom96https://github.com/nim-lang/nimble/milestone/2
15:41:51dom96I think i'll leave it there
15:44:37PMunchHmm, there must be more to this. A small trivial example works fine..
15:45:12FromGitter<mratsim> @brentp I've merged QR Decomposition in Arraymancer
15:48:36PMunchhttps://play.nim-lang.org/#ix=1Wpz
15:48:46PMunchOkay, so the forward decl thing just doesn't work at all..
15:51:12FromGitter<de-odex> what are the constructor naming conventions?
15:51:27disrupteki do a forward decl in that same codegen file.
15:51:40Yardanico@de-odex initType for "object" types, newType for "ref object" types
15:51:57FromGitter<de-odex> ok another question
15:51:59FromGitter<de-odex> uh
15:52:08disruptekPMunch: https://github.com/disruptek/openapi/blob/master/src/openapi/codegen.nim#L1236
15:52:13FromGitter<de-odex> how do i name a proc that converts a string to an enum value
15:52:22PMunchIn thet example it works to change it to a newIdentNode by the way, but that doesn't actually work for protobuf for some reason..
15:52:35FromGitter<mratsim> @de-odex it's called parseEnum
15:52:41lqdev[m]de-odex: `parseT`?
15:52:53FromGitter<mratsim> https://nim-lang.org/docs/strutils.html#parseEnum%2Cstring
15:52:56disruptekyou can probably see that i've started removing quote do just because it seems it's ripe for overhaul and i don't want to have to worry about it.
15:52:59lqdev[m]and yeah `strutils.parseEnum` is a thing
15:53:26FromGitter<de-odex> nice thanks
15:53:47PMunchdisruptek, yeah the way it is now seems pretty broken..
15:53:49FromGitter<mratsim> @disruptek, I don't think I have a single library without quote do :/
15:54:07*Hideki_ quit (Remote host closed the connection)
15:54:20*endragor joined #nim
15:54:35disrupteki have the full range, even dropped to parseStmt when i get really lazy. probably should just use `include`.
15:55:10*Hideki_ joined #nim
15:55:23PMunchHaha, haven't quite dropped to parseStmt yet
15:56:07PMunchTried to use quote do everywhere for a while, it really makes the code more readable. But with these changes I seem to have to switch back..
15:56:26disruptekright, it gives you pause.
15:57:06PMunchHmm, I can't reproduce the bug I'm facing with protobuf though..
15:57:20PMunchAnd the codebase for it is rather complex..
15:57:56FromGitter<mratsim> wait what are the changes to quote do?
15:59:28*Hideki_ quit (Ping timeout: 245 seconds)
16:01:55*endragor quit (Remote host closed the connection)
16:18:55PMunchDon't know exactly..
16:19:06PMunchBut something has changed, and it has broken a lot of my macro code..
16:26:08shashlick@dom96 - any idea on this? https://travis-ci.org/genotrance/nimble/jobs/588137223#L411
16:28:15*narimiran joined #nim
16:33:33dom96It's probably got an .exe extension or something
16:33:40dom96check out nimble.nim:1094
16:34:29FromGitter<arnetheduck> rayman22201, contribute away ;) though generally libraries are more flexible for everyone involved (you as a dev because you can move faster, nim as a language because you don't clog the PR queue and users because they can update components individually).. ie even the nim team could develop nim / stdlib parts as separate libraries and curate parts of it that are "high-impact" to guide beginners to the right places,
16:34:29FromGitter... if the tooling was there..
16:36:46dom96arnetheduck: if you're around can you test the latest Nimble on your/Status' projects?
16:39:15FromGitter<arnetheduck> we don't use nimble any more
16:40:37shashlick@dom96 - why so many repeats? https://github.com/nim-lang/nimble/blob/master/tests/tester.nim#L942
16:40:54FromGitter<arnetheduck> we have a contraption based on makefiles and git submodules instead (both status projects and my own)
16:41:26shashlickokay never mind
16:41:43dom96shashlick, regarding https://github.com/dom96/choosenim/pull/135/files
16:41:50dom96Does getBinDir return ~/.nimble/bin?
16:42:52dom96I don't understand why needsDLLInstall would return false during an initial install when those libeasy32/ssleay32 DLLs are not in ~/.nimble/bin
16:43:16shashlickya but the code checks with findExe as well
16:43:23shashlickso the files in the local path get detected
16:43:26shashlickso it doesn't copy
16:43:30shashlicksince choosenim ships with those dlls
16:43:41dom96oooh
16:43:52shashlicki just picked two other dlls and it works now
16:44:27planetis[m]lqdev: still looking for a game loop?
16:44:33dom96yeah, but these DLLs are not required for choosenim
16:44:53shashlickthe dlls you were checking for are part of the zip
16:45:03shashlickchoosenim needs the ssl dlls to download
16:45:13dom96I know
16:45:38shashlickthen which dlls are you talking about
16:45:43*elrood joined #nim
16:45:46dom96the ones you've specified
16:45:58dom96pdcurses64 and sqlite3_32
16:46:20shashlickwell, choosenim is checking for dlls to decide whether it should download dlls.tar.gz
16:46:27shashlickwhich contains these files
16:47:03dom96I think we can just remove the findExe check to be honest
16:47:20planetis[m]try this one: https://gist.github.com/b3liever/1e9faf735b737bc67d8827646736d495
16:49:22*Hideki_ joined #nim
16:49:32shashlickwell the dlls could be in the nim bin directory too
16:49:38shashlickper the instructions on the website
16:49:43shashlickso it could be in the path
16:52:24dom96Another alternative is to just check if they're beside the running .exe
16:52:37dom96that would fix this problem too
16:52:58dom96hrm, no
16:53:05dom96they get copied beside the .exe in ~/.nimble/bin
16:54:16dom96I can't accept your PR though, it checks for DLLs that choosenim does not care about
16:54:29shashlickchoosenim is installing those dlls for Nim, not for itself
16:54:39shashlickthe DLL check is for the dlls in the dlls.tar.gz
16:54:41dom96it'll cause DLLs to be downloaded even if the SSL DLLs are present in PATH or NImble bin
16:54:49*PMunch quit (Remote host closed the connection)
16:55:04lqdev[m]planetis: yes
16:55:18lqdev[m]OK, I'll go see it
16:55:22dom96That's not the intention I had when I wrote that
16:55:24shashlickchoosenim cannot download the ssl dlls - it needs ssl to download them in the first place
16:55:35Yardanicolol
16:56:11shashlickthat's why your choosenim zip has the ssl dlls in it
16:56:18lqdev[m]planetis: well it's not quite what I'm looking for. a constant tick rate is nice but results in choppy movement, and my engine doesn't really support interpolation very well
16:56:27shashlickhttps://github.com/dom96/choosenim/blob/master/src/choosenim/download.nim#L278
16:56:56dom96but fine, in that case we should check for all DLLs inside dlls.zip
16:57:33shashlicki picked random ones which are unlikely to be on windows
16:57:38shashlickhence ncurses and sqlite
16:57:57dom96unlikely is not impossible
16:58:20shashlickhmm
16:59:18shashlickby the way, just try `nimble run` => http://ix.io/1Wqc
16:59:37planetis[m]I see, though for my game it worked fine (without cuts)
16:59:50dom96thanks, that's a bug :)
17:00:38dom96maybe if I have energy tomorrow I'll release a new choosenim too
17:04:22*hpyc9 joined #nim
17:05:38*Hideki_ quit (Ping timeout: 240 seconds)
17:07:04lqdev[m]just reading the section 'Interpolation and Prediction', I think I could implement this with a simple function
17:07:15lqdev[m]on the base sprite object
17:12:32leorizenarimiran, Zevv, disruptek: is the refactoring branch of nim.nvim doing well for you?
17:13:00leorizeI'm gonna merge it to master if there aren't any problems
17:13:00narimirando it :)
17:13:00Zevvlemme upgrade
17:13:13*NimBot joined #nim
17:14:10*bozaloshtsh quit (Quit: ZNC 1.7.2 - https://znc.in)
17:14:18*bozaloshtsh joined #nim
17:14:18*bozaloshtsh quit (Changing host)
17:14:18*bozaloshtsh joined #nim
17:16:07Zevvworked fine over the last days for me. My highlighting settings are pretty minimalistic, so not sure if that is all still ok
17:20:21leorizewell some error messages were omitted, but no one noticed :P
17:22:32ZevvI'm already happy the "killed nimsuggest" message at exit is gone :)
17:23:28leorizetechnically it's not my bug :P neovim displays the last message emitted on exit
17:24:04ZevvI have one question, but not sure if it should be a feature: if my syntax highlighting indicates there's an error, is there a way to get the error message somehow? That would save me an alt-tab-up-enter-alt-tab-wait-cycle
17:24:41leorize:make
17:24:49leorizeor use one of those automated linter plugins
17:25:06Zevvyeah, but there is already an indication of the error - does nimsuggest not tell you that somehow?
17:25:18leorizeorrr, bug me enough so I add support for nimsuggest `chk` :P
17:25:34leorizethe `highlight` command only said to highlight it as error
17:25:41Zevvnah, first concentrate on vim8 :)
17:26:17ZevvI now switched to nvim on all my machines, but it bugs me that it is slow on huge files and crashes on my at least once a week
17:26:57leorizeyou'll be missing out on the highlighting until vim9 :P
17:27:14Zevvah didn't know that.
17:27:21leorizeneovim really pressures vim to actually step up
17:27:31leorizethere's an experimental api for semantic highlighting now
17:28:26ZevvSo much for my highlighting: http://zevv.nl/div/highlight.png :)
17:29:00leorizeyou do use the red text error highlighting :P
17:29:14Zevvoh yeah I do use that. But my code *never* has errors
17:29:33Zevvit's always perfectly fine :)
17:29:52Zevvnah, nevermind me, just merge your branch, stuff works like a charm!
17:31:13leorizewriting a nice commit message rn :P
17:31:45Zevvgit commit -am "merged stuff" && git push
17:34:03*drewr quit (Ping timeout: 246 seconds)
17:37:33narimiranZevv: jesus christ man, introduce some colors in your life
17:37:57narimiranand no, your two-and-a-half colors don't count
17:41:34ZevvI like to work in a dark environment, so I can't use a light background comfortably. On black, green is the obvious choice because eyes are most sensitive to green, and monochromic green avoids chromatic aberration, especially more off-center of my glasses.
17:41:59ZevvMore importantly, I still am the coolest kid on the block because my terminal looks like the matrix
17:42:28Zevvand not like a candy shop at christmas eve
17:42:41narimirani feel personally attacked!! :P
17:42:57Zevvyou should
17:45:23disruptekis it me or is `var x {.used.}: SomeType = SomeVal` syntax a little odd?
17:45:53Zevvwhy is it? That's just where the pragmas go?
17:47:08disrupteknot on a proc.
17:48:11Zevvyou'd prever var x: SomeType = {.used.} SomeVal?
17:48:42Zevvand yet
17:48:43disrupteki expected `var x: SomeType {.used.} = ...` and got an indentation error when i tried it.
17:49:01disruptekprocs are `proc foo(): ReturnType {.pragma.} = ...`
17:49:28Zevvyeah that's what I ment of course
17:49:33disruptekright.
17:50:13Zevvit does make sense indeed, but there's probably a good reason for that. ask the boss?
17:51:32leorizenarimiran, Zevv, disruptek: please pull the latest commits from nim.nvim's master branch :)
17:52:13disruptekwoohoo
17:52:37*zedeus quit (Quit: WeeChat 2.5)
17:52:38disruptekhmm, i'm already up-to-date.
17:52:39narimirandone. i'll test it tomorrow. now it is time to relax and watch some tv series
17:52:50Zevvheu did you flatten the commits?
17:52:53disruptekwow, that's a huge git log.
17:53:13leorizeyea, I squashed 'em all
17:53:40disrupteki can't believe you're monochromatic, zevv.
17:54:02disruptekaste the rainbow12wheee
17:54:17*zedeus joined #nim
17:54:59ZevvWell, I started with highlighting when switching the nvim, but it bothered the hell out of me. I started tuning stuff down and adjusting and this is were I ended up.
17:55:07Zevvhighlighting clashes with my synesthesia
17:55:15Zevvoh no, wait, I don't have that
17:55:18disruptekah, that's a great reason to disable it.
17:55:19disruptekbwaah
17:55:20Zevvit just bugs the hell out of my I guess :)
17:56:12disrupteki find solarized to be pretty great.
17:56:42narimirani can't stand its bluish background
17:56:55leorizeZevv: you might like my rainbow vomit on top of pure black background colorscheme :P
17:57:12Zevvwhee \o/
17:57:28*snooptek joined #nim
17:57:56leorizeI used to be a solarized fan
17:58:09leorizeuntil I discovered that black background exists
18:10:06*zedeus quit (Quit: WeeChat 2.5)
18:10:16*zedeus joined #nim
18:16:36*navin joined #nim
18:22:48*ng0 quit (Ping timeout: 260 seconds)
18:32:51*gangstacat quit (Ping timeout: 246 seconds)
18:36:30disruptekcannot find any documentation for dead code elimination. searched cli, experimental section, manual search box, pragmas section. i found the syntax in the forum. the syntax passes, but i cannot provoke differenting output either in debug or release or danger modes. my code just imports other modules. >600k binary, optimized.
18:39:50*Kaivo quit (Quit: WeeChat 2.6)
18:42:34*kungtotte joined #nim
18:54:51*laaron joined #nim
19:06:13*al_ joined #nim
19:16:05FromGitter<mratsim> dead code elimination is now default
19:16:23FromGitter<mratsim> but AFAIK it doesn't do dead module elimination so you still end up with empty module files
19:25:53*navin quit (Ping timeout: 250 seconds)
19:29:42disruptekah, thanks.
19:31:20disruptekso even though it marks a module as "unused" and my entire source is "import thatmodule", it won't remove it? i guess what i'm asking is, under what circumstances does it omit something?
19:34:10disrupteki'm asking because if i import my entire api, it's already >1MM loc.
19:35:08*Ven`` joined #nim
19:35:25ZevvMM?
19:36:31Zevvhow long does that take to compile?
19:40:35*ng0 joined #nim
19:41:26disrupteki don't have the stones to find out.
19:42:52FromGitter<brentp> @mratsim cheers. I was following on git, a bit. will check it out.
19:46:50*gmpreussner quit (Ping timeout: 240 seconds)
19:50:53disruptek1186065 lines compiled; 160.284 sec total; 2.316GiB peakmem; Dangerous Release Build
19:52:36*gmpreussner joined #nim
20:03:37ZevvThat's 160 times slower then vlang
20:03:51disrupteki have a long way to go, it's true.
20:04:12ZevvThat was tongue-in-cheek
20:05:07disrupteki know. if my code is as fast as vlang, i know i'm moving in the wrong direction. 😉
20:05:56*rayman22201 joined #nim
20:12:23*nsf quit (Quit: WeeChat 2.5)
20:17:39*vegax87 joined #nim
20:21:03dom96shashlick, any progress with windows CI?
20:21:40*al_ quit (Quit: al_)
20:23:26shashlickWas debugging the nimble run bug
20:23:38shashlickOtherwise is working decent
20:24:08rayman22201testament question. Can you set the compile flags for a single test?
20:24:31shashlickhttps://github.com/nim-lang/nimble/compare/master...genotrance:winci2
20:28:02rayman22201nvm. got it
20:28:46*elrood quit (Remote host closed the connection)
20:36:11dom96cool
20:40:27*narimiran quit (Ping timeout: 245 seconds)
20:43:47rayman22201different related question now: the ci runs this `./testament/testament --nim:./bin/nim pcat lib`
20:44:18rayman22201which looks like it compiles the each lib module individually?
20:44:56rayman22201but `lib/pure/collections/sharedlist.nim` and `sharedtables.nim` both require `--threads:on`
20:45:40rayman22201This makes sense, but testament used to not complain.
20:45:55rayman22201I added extra checks here: https://github.com/nim-lang/Nim/pull/12231
20:45:58rayman22201and now it complains
20:46:58disruptek[GC] cannot register global variable; too many global variables⏎ 😢
20:49:26Zevvthat'll teach you. every global is one to many!
20:56:31rayman22201I guess the answer is just skip them? lol: https://github.com/nim-lang/Nim/blob/devel/testament/testament.nim#L561
20:56:40dom96Went through the Nimble chapter of my book. Brings back so many memories, and surprisingly it's still 100% compatible with latest Nimble :D
20:57:01rayman22201woot!
20:59:57Zevvthat's pretty sweet indeed
21:03:00*Hideki_ joined #nim
21:07:07*Hideki_ quit (Ping timeout: 245 seconds)
21:07:08dom96Tweeter (TM) still works: https://i.imgur.com/8ATgyfX.png
21:07:25dom96:D
21:07:33dom96Considering spruicing up the CSS
21:14:04rayman22201Hey @Zevv, have time to code review this? https://github.com/nim-lang/Nim/pull/12232
21:14:25rayman22201you too @Dom96, but I know you are busy with nimble stuff
21:15:43dom96oooh fancy, but yeah, I'm way too burned out to review this properly tonight :)
21:16:12rayman22201yeah, I figured. no worries :-)
21:16:37*solitudesf quit (Ping timeout: 268 seconds)
21:26:13dom96I knew putting the Nim in Action code into the test suite would pay off. All code samples I've tried so far are working fine.
21:26:27dom96There isn't even that many deprecations
21:26:44shashlick@dom96 what do you want to do with the choosenim pr?
21:27:49dom96make it check for all DLLs in the zip?
21:27:59dom96or at least the pcre + ssl DLLs
21:28:04*krux02 quit (Remote host closed the connection)
21:28:16dom96that way you'll fix the issue and there won't be risk that this will break if someone decides to remove some DLLs from the zip
21:28:59shashlickDo you want it smart enough to only copy those that are missing
21:29:24shashlickI don't think it is worth it but ya
21:30:13dom96nope
21:30:17shashlickI am 95% closer to getting libarchive done so we can add 7z and xz support to choosenim
21:30:24Zevvrayman22201: quite a diff you did there. I'd get anxiety problems for that, given there are no proper unit tests :)
21:31:20shashlickWe could also statically link the ssl libs on windows at some point
21:32:42rayman22201That's why I wrote tests to go with it! (Probably not enough, but a start)
21:33:21rayman22201I don't think there was anyway to do this as a "small" diff lol
21:33:21Zevvcan't you make a block template that locks the lock if needed, or otherwise just does the passed block? That would save repetition here and there
21:34:13rayman22201Good idea. I didn't think of that
21:34:59shashlickdid leorize merge his nim.nvim branch to master?
21:35:03Zevvhe did
21:35:20Zevvhe squashed it all, so it's only one commit
21:36:09Zevvrayman22201: I see what you solved here, but all in all the whole async stuff is getting hearier then my
21:37:59rayman22201Lol. I want you to finish that sentence @Zevv
21:39:37*Vladar quit (Remote host closed the connection)
21:39:46Zevvhairier then my Medicinal Fried Chicken.
21:40:40*ng0 quit (Ping timeout: 260 seconds)
21:42:02rayman22201Hahaha. Excellent
21:43:06ZevvIt all feels very virtual and all, but this does seem to efix the problems with our first try
21:45:19dom96shashlick, any luck with the `run` problem on Windows?
21:45:25rayman22201It's not "the most efficient" solution. But it works with all the poll back ends, is cross platform, and correct (modulo any bugs I may have missed).
21:45:26dom96I'd like to tag the release soon
21:45:28*ng0 joined #nim
21:47:43Zevvrayman22201: How would these changes affect code that does only normal fd and timer waiting, but no other event stuff?
21:47:57ZevvLike, 95% of the apps that are currently using async
21:48:59rayman22201Well, all the tests pass. The CI ran important packages on it I believe. It shouldn't affect them afaik.
21:49:25rayman22201@Zevv I agree though. I have "async fatigue" as well. Araq and Dom seem to be looking forward to this though. I didn't want to disappoint them. I felt I should at least finish this project.
21:49:39ZevvYeah, sorry for bailing out :(
21:49:58ZevvI have these flares of enthausiasm of picking up things, and then life and work comes along and I just drop it all again
21:50:01rayman22201No worries! You have been a great help!
21:50:27Zevvanyway, the work you did is not trivial, and properly reviewing isn't either
21:51:00rayman22201Story of my life. I had to shut off irc for two weeks because work got so busy. This is the first free weekend I've had.
21:52:18rayman22201I agree. I wish I could have gotten the PR finished earlier. I'm sad because It probably won't make 1.0. but oh well. Life happens. I would rather it be properly vetted.
21:52:27ZevvSame here. One of my customers had to show up with nifty new toch at some yearly big event, so that took some time
21:53:03ZevvMost important is probably to get a good idea of the impact and risk of the majority of 'normal' async users
21:53:07Zevvbut this seems pretty much safe
21:53:59shashlick@dom96 - not yet
21:55:19dom96what have you tried?
21:55:33*Zevv -> bed. laters rayman22201!
21:55:48rayman22201Gn!
21:55:48dom96did you check what `binary` is equal to? https://github.com/nim-lang/nimble/blob/master/src/nimble.nim#L1100
22:02:36*pbb quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
22:02:51*pbb joined #nim
22:04:07shashlicknot yet, need to setup on my windows machine
22:07:56dom96okay, well, I'll have to tag this in an hour before heading to bed
22:08:05dom96make a PR if you can :)
22:10:15shashlickokay cool
22:10:34*Trustable quit (Remote host closed the connection)
22:11:46shashlickupdated the choosenim PR, ptal
22:11:56*ng0 quit (Ping timeout: 260 seconds)
22:13:13shashlick`nimble run` is fixed 🙂
22:16:42shashlickon windows, binary = the nims file name
22:19:51zedeusdom96: Tweeter was the inspiration for this project https://github.com/zedeus/nitter
22:24:55*rupertdev quit (Quit: The Lounge - https://thelounge.chat)
22:30:29*Jjp137 quit (Ping timeout: 276 seconds)
22:31:01*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:34:07*Jjp137 joined #nim
22:37:06*vegax87 quit (Read error: Connection reset by peer)
22:37:34*vegax87 joined #nim
22:37:34*vegax87 quit (Changing host)
22:37:34*vegax87 joined #nim
22:42:17shashlickdom96 - found a fix for nimble run
22:52:23*Jjp137 quit (Read error: Connection reset by peer)
22:54:18*vegax87 quit (Quit: Leaving)
22:56:54*Hideki_ joined #nim
23:00:20FromGitter<mratsim> @brentp I had a look into some papers for randomized PCA, specifically Halko 2009, Martinsson 2011, Witten 2013 and Szlam 2014 (especially this one). Seems like LU Factorization is faster than QR Factorization for randomized PCA. Also I really need to implement SVD (PR coming, only the tests are missing), and I can probably reimplement normal PCA using SVD, and also review the return matrix shape.
23:00:45*lritter quit (Ping timeout: 265 seconds)
23:03:23dom96shashlick, what is it?
23:04:20dom96zedeus, oooh, that's awesome :O
23:05:44*lritter joined #nim
23:05:58dom96very stylish
23:06:31shashlickbin = ["run.exe"] but getCompilationBinary() = run without the exe
23:06:56shashlicki'm fixing it in my PR
23:07:42shashlickjust need to changeFileExt("") => ExeExt
23:08:06zedeusdom96: thanks!
23:08:16dom96shashlick, okay, i'll just cherry pick this
23:08:29shashlickgo ahead and fix it then, i'll pull your fix in
23:09:09shashlickhttps://github.com/nim-lang/nimble/blob/master/src/nimblepkg/options.nim#L523 change ("") => (ExeExt)
23:09:14shashlickam still testing it though
23:10:24dom96it makes sense
23:10:35dom96and on non-Windows ExeExt is "" so it shouldn't break things any more :)
23:10:43dom96I'm going to tag now
23:10:50shashlickhold on
23:10:55shashlicklet it run thru windows CI
23:11:10dom96I need to go now, so can't wait
23:11:22shashlicki have all your changes
23:11:36dom96We can release 0.11.2 if there is time tomorrow
23:12:04shashlicki can tag later if it passes
23:12:22shashlickanyway everyone is sleeping
23:13:02dom96Meh, it's fine. I doubt there is anything too broken on Windows
23:13:14dom96if there is we can release 0.11.2
23:13:16dom96'night
23:13:55dom96and thanks for looking into this btw :)
23:41:23FromGitter<brentp> @mratsim, that would be awesome! I just saw default looked like QR in scikit-learn
23:45:17*rockcavera joined #nim
23:53:47*Hideki_ quit (Remote host closed the connection)
23:56:00*owl_000 joined #nim