<<20-09-2019>>
00:06:20*lritter quit (Ping timeout: 246 seconds)
00:23:12*abm quit (Quit: Leaving)
00:25:28*treeform quit (Remote host closed the connection)
00:44:12*doesntgolf quit (Ping timeout: 245 seconds)
01:10:44FromGitter<gogolxdong> GLFM is based on opengl，you can use Vulkan to build a cross-platform GUI
01:11:48leorizefor GUI building OGL would be much easier
01:11:57leorizeiirc you'd need to build your own pipeline in vulkan
01:12:03leorizeand that's overkill for GUI usage
01:15:13*endragor joined #nim
01:45:22*laaron quit (Remote host closed the connection)
02:04:03*exelotl quit (Ping timeout: 245 seconds)
02:05:54*thomasross joined #nim
02:10:10*laaron joined #nim
02:13:59*laaron quit (Client Quit)
02:15:43*laaron joined #nim
02:21:54FromGitter<arnetheduck> on package managers, here's go's take: https://github.com/golang/go/wiki/Modules
02:37:22*dddddd quit (Remote host closed the connection)
02:55:27*rockcavera quit (Remote host closed the connection)
03:05:53*chemist69 quit (Ping timeout: 246 seconds)
03:08:12*chemist69 joined #nim
03:16:18FromGitter<arnetheduck> interesting thoughts in there on managing a thriving eco-system of independent libraries
04:13:18*laaron quit (Remote host closed the connection)
04:16:21*laaron joined #nim
04:23:31*laaron quit (Remote host closed the connection)
04:26:25*laaron joined #nim
04:42:59FromGitter<kdheepak> --outdir:DIR doesn't seem to work anymore?
04:44:47FromGitter<kdheepak> It seems I have an older nim. Trying to upgrade now
04:45:33*laaron quit (Remote host closed the connection)
04:49:21FromGitter<kdheepak> When I run this: ⏎ ⏎ ```nim c --outdir:temp --threads:on --app:lib --out:mymodule.so mymodule.nim``` ⏎ ⏎ I don't see any temp folder [https://gitter.im/nim-lang/Nim?at=5d845a51ab4244767bcfdffa]
04:49:47*nsf joined #nim
04:51:14leorizeI wouldn't rely on --outdir
04:53:33leorizeit's better in your case to just use `--out:temp/mymodule.so` instead
05:01:53*laaron joined #nim
05:02:37*laaron quit (Remote host closed the connection)
05:05:25FromGitter<kdheepak> Thanks!
05:05:35*laaron joined #nim
05:16:41*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
05:17:23*laaron joined #nim
05:48:16*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
05:50:54*laaron joined #nim
06:16:38*narimiran joined #nim
06:17:50*solitudesf-- joined #nim
06:21:03*PMunch joined #nim
06:21:04*solitudesf-- quit (Read error: Connection reset by peer)
06:21:55*solitudesf joined #nim
06:33:22FromGitter<zacharycarter> If anyone is aware of any Nim related opportunities, I'm looking again 🙂
06:34:22*livcd joined #nim
06:50:31*PMunch quit (Remote host closed the connection)
06:50:47*PMunch joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:35*gmpreussner joined #nim
07:08:06*krux02 joined #nim
07:10:47*Vladar joined #nim
07:11:02PMunchHmm, this async stuff with hard sleeps is really confusing
07:12:11PMunchIt works in chronos, but its implementation have deviated too far from the stdlib asyncdispatch that it's a bit tough to tell what exactly makes this difference..
07:14:28Zevvand there you have it
07:14:41PMunchHave what?
07:15:11Zevvthe chronos thing again :/
07:16:21*ng0 joined #nim
07:19:44PMunchHaha, I just wanted to check if it had the same issue
07:20:00PMunchI have no horse in this race, if you would call it that
07:21:38*alexander92 joined #nim
07:21:52PMunchHmm, tried to roll back chronos to a much earlier commit to see if the changes were small enough for me to easily see the difference
07:22:17PMunchAnd it has a completely different issue :P
07:25:27PMunchWith stdlib asyncdispatch: http://ix.io/1VYc, with old chronos: http://ix.io/1VYa, with current chronos: http://ix.io/1VYd, and the code I use to test this: http://ix.io/1VKv/nim, the only difference between the tests is to change the import.
07:30:45Araqping shashlick
07:31:38*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
07:32:19*laaron joined #nim
07:35:00shashlickSup
07:41:18*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
07:42:07*laaron joined #nim
07:52:50Araqshashlick, we want a new Nimble release, asap
07:52:57Araqlook at my PRs please
07:57:44alexander92Zevv, i have another pro linux question
07:58:49PMunchYay, found the fault in asyncdispatch and a way to easily fix it :)
07:59:11Zevvalexander92: here
08:02:22ZevvPMunch: congrats!
08:04:01shashlickHey @Araq, am on the road until next week
08:04:39shashlickI understand fixes but why do you care about nimble release? Nim is pinning to a commit right
08:04:48alexander92Zevv sorry
08:05:16alexander92is it possible that something "hides" from me info from /proc/id/maps ? e.g. i see only `/` as binary path for stuff
08:05:36nc-x[m]shashlick: Araq does not want to release 1.0 without new release of nimble
08:06:10*ng0_ joined #nim
08:06:29Zevvwhat is "stuff" in this case?
08:07:17*leorize quit (Remote host closed the connection)
08:07:21shashlickwhen is 1.0 scheduled?
08:08:14Araqtoday *cough*
08:08:24*ng0 quit (Ping timeout: 260 seconds)
08:08:37shashlickWow okay
08:08:42alexander92Zevv: programs ran in docker with other permissions
08:08:45shashlickI had texted about this earlier
08:08:59shashlickBut anyway, looks like we don't have time
08:09:19Zevvalexander92: ah, with docker other magic happens; stuff runs in other namespaces, SELinux might be involved
08:09:27shashlickThere's been no new features in nimble recently, but was hoping to fix more bugs and stabilize
08:09:37shashlickBefore 1.0
08:10:13PMunchWait really? 1.0 is scheduled for today?
08:10:23PMunchI haven't even had time to bake a cake!
08:10:24Araq--passNim is a new feature, shashlick
08:10:43Zevvwhat?! 1.0! today! Does Araq even know?!
08:10:47alexander92oh man, good thing i didnt rebase my patches until today
08:11:39*leorize joined #nim
08:11:43alexander92PMunch, at least you know it before going to the army
08:11:45narimiranitshappening.gif
08:11:55shashlick@Araq is that in Nim or nimble, don't see any recent changes in nimble
08:12:13shashlickRelated to passNim
08:12:15PMunchalexander92, that's true, but I'm not leaving until Wednesday
08:13:19PMunchHmm, just updated to the latest devel to try my asyncdispatch fix before I make a PR, and I'm unable to run my example: http://ix.io/1VYy
08:13:58AraqPMunch, Time is not an int
08:14:55PMunchYeah I know, but this isn't something I've touched..
08:15:07narimiranPMunch: i remember seeing a similar error when i tried to bisect some (very) old commits
08:15:21PMunchThat is the entire error message by the way, so no idea where it comes from..
08:15:50narimiranthere was a change in times.nim module, but i have no idea why are you seeing it *now*
08:16:59*sammich quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
08:17:23PMunchI fixed that issue (doing .int64 on the low(CTime) and high(CTime) parts), but now I'm faced with a similar issue: http://ix.io/1VYA
08:17:53shashlickokay it has been around for a few months now for passNIm
08:18:04*sammich joined #nim
08:19:42PMunchAfter fixing those issues there are more of the same: http://ix.io/1VYC
08:20:12narimiranPMunch: stupid question: are you using 0.20.2 or newer?
08:20:26PMunchdevel updated about a minute ago
08:20:51PMunchAnd that repo was pulled minutes ago with a one-liner fix in asyncdispatch applied to it
08:21:00*leorize quit (Ping timeout: 260 seconds)
08:21:00*ng0_ quit (Ping timeout: 260 seconds)
08:21:00*laaron quit (Ping timeout: 260 seconds)
08:21:48PMunchOh, weird.. Running this with the devel version of asyncdispatch works..
08:22:27alexander92Araq, so current todo things
08:22:28alexander92would just go into 1.1
08:23:13alexander92?
08:23:45narimiranalexander92: https://github.com/nim-lang/Nim/milestone/2
08:26:01alexander92so https://github.com/nim-lang/Nim/milestone/4
08:26:02alexander92ok
08:26:54alexander92but what happens with `do` etc
08:27:03PMunchHmm, pulling the devel branch, building it, and running "choosenim ." makes it work fine
08:27:33PMunchIs "choosenim update devel" not the same as "git checkout devel && ./koch boot && choosenim ."?
08:29:23shashlick@Araq - I can merge both PRs, both look good
08:29:33shashlickbut is @dom96 on board with 0.11.0
08:30:07nc-x[m]is 1.0 really today?
08:30:09shashlickwon't we need a readme
08:30:16shashlickchangeme
08:30:19shashlickugh changelog
08:35:10*laaron joined #nim
08:36:23Araqalexander92, yeah, into 1.1
08:37:01livcdwhen is v1 going to get released ? :-)
08:38:24*leorize joined #nim
08:38:25Araqwe are preparing the last steps and then you should test it this weekend
08:38:33Araqand then we'll release on monday
08:39:24shashlicki understand on one hand, but why bump nimble to 0.11.0 instead of 0.10.4 for a bunch of bug fixes
08:39:39Araqbecause 0.10.4 was too buggy for me
08:39:43*ng0_ joined #nim
08:40:22shashlickno, current release is 0.10.2, so we can bump to 0.10.4
08:40:53narimiranlivcd, nc-x[m]: today's devel (with some more commits coming in later today) is—if after testing nothing showstopping is found—what will be v1.0 on monday
08:41:02livcdrelease on monday 13:00 or 15:00
08:42:54narimiranso my personal wish/request to everybody who can would be: update to the latest devel and test it over the weekend
08:43:52nc-x[m]narimiran, araq: 👍🏻
08:45:37PMunchhttps://github.com/nim-lang/Nim/pull/12221 the fix for asyncdispatch for those at home following along
08:46:26*disruptek quit (Ping timeout: 240 seconds)
08:47:04Zevvsweet
08:47:18*snooptek quit (Ping timeout: 258 seconds)
08:48:16nc-x[m]btw, won't the deprecated stuff be removed for 1.0?
08:49:08*disruptek joined #nim
08:50:41PMunchOh cool, then I have time to test all my packages over the weekend to make sure it's ready for v1 :)
08:51:13*PMunch looks at number of packages
08:51:25PMunchThat should be, interesting..
08:51:58*ng0_ is now known as ng0
08:52:00narimirannc-x[m]: as i said: current devel (including deprecations) will be v1.0
08:52:23narimiranas for why: look at julia 0.7 --> julia 1.0 deprecation fiasco
08:56:02nc-x[m]but didn't the deprecation guidelines (dunno where i read that) say that deprecated stuff will be removed after 2 major nim releases. and i think (not sure) that there are stuff that were deprecated much before that which are not yet removed.
08:56:29Araqnc-x[m], we are going through every stdlib module...
08:56:40Araqbut I'm sure we'll miss these things, so ... report it please
08:56:54nc-x[m]anyways no big deal. its just that compiling nim (and nimble?) show too many deprecated warnings
08:57:01*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
08:57:08nc-x[m]Araq: 👍🏻
08:57:41*laaron joined #nim
09:06:11alexander92but what happens
09:06:14alexander92with the do syntax
09:06:21alexander92i remember there were plans for deprecating
09:06:29alexander92which seems like one of the major possible breaking changes
09:06:35alexander92which would be good to be before 1.0
09:09:12leorizedid I hear that right, 1.0 soon?
09:09:25narimiranalexander92: it is part of the experimental manual: https://nim-lang.github.io/Nim/manual_experimental.html#do-notation
09:09:39narimiran"Unless otherwise indicated, these features are not to be removed, but refined and overhauled."
09:11:54leorizeare any of you still hiding nim.nvim bugs from me? :P I need to iron them all out before Nim 1.0
09:17:05*navin joined #nim
09:17:05*Trustable joined #nim
09:26:07*Vladar quit (Remote host closed the connection)
09:34:07FromGitter<arnetheduck> @Araq I saw somewhere that you think statement-based ast would be easier for `nlvm` - why is that?
09:36:13*NimBot joined #nim
09:39:54*Perkol joined #nim
09:44:59Araqwhat?
09:48:01FromGitter<arnetheduck> https://github.com/nim-lang/Nim/milestone/4 - `Rewrite expression based ASTs into statement based ASTs as both C++ and JavaScript are statement based languages. In order to support all control flow constructs, some form of goto is probably needed for this. NVLM will benefit from this. `
09:54:09*navin quit ()
09:57:21Araqarnetheduck: oh yeah, not sure I still hold this opinion but the idea was basically
09:57:59Araqto transform 'let x = if cond: a else: b' into 'if cond: x = a else: x = b' because backends benefit from this
09:58:46Araqcurrently it is done by vmgen, cgen, jsgen but it could be an AST to AST transformation
09:58:56PMunchHmm, is there a way to manually yield an async procedure?
09:58:56Araqand then the backends would be simpler
09:59:13PMunchI tried to use poll() and drain() but they don't appear to do what I expect them to do..
10:00:06PMunchOh wait, poll(1) does almost what I wanted
10:02:49PMunchAh, `await sleepAsync(0)` works even better for what I was trying to achieve
10:03:09PMunchThat isn't the best though.. Can potentially create a lot of timers..
10:03:20PMunchOr I guess it would only create one at a time..
10:08:29FromGitter<arnetheduck> hm, so examples like that will lead to worse codegen in `llvm` - for example there are now two `x` meaning double the stack space - this must be optimized away by running code flow analysis which is slow and bad. basically, that's a lossy transformation - if anything, I'd actually like the AST to be fully expression-based - it's a bit of a mess now with `ifexpr` vs `ifstmt` and both behaving as expressions depending
10:08:30FromGitter... on template expansions and the like.. there's a number of irregular AST's that the cgen swallows because of how it deals with `TLoc` that's really hard to analyze.. for example, there are cases of `nkAsgn` where the right hand side is a statement (list) that must be evaluated which is really weird.. likewise that ... [https://gitter.im/nim-lang/Nim?at=5d84a51dc77f285fb1aef896]
10:11:47FromGitter<arnetheduck> or maybe not double in that case because the x would sit uninitialized for a while, but it applies to liveness analysis which is trivial to generate in the expression case, but requires analysis in a statement-based world
10:18:36*clyybber joined #nim
10:21:32clyybberarnetheduck: I agree, I also find that you can't rely on ifStmt vs ifExpr and the distinction is basically useless as we don't have it for other AST Nodes either(like case). It gets worse when discardable comes into play.
10:21:34*abm joined #nim
10:25:12clyybberarnetheduck: So to fix AST inconsistencies without breaking bootstrapping, Araq started working on this: https://github.com/nim-lang/Nim/tree/araq-nodekinds-by-string-comparisons
10:28:45FromGitter<arnetheduck> yeah, but almost worse than that is that there are statements where you would expect an expression (like in `nkAsgn`) and the only reason it works is basically that the ast is never checked as long as the cgen spits out something that seems to work..
10:43:48leorizedisruptek, narimiran, Zevv: I've pushed some new commits to nim.nvim's refactoring, please check them out
10:44:21leorizemost notably are tweaks to when the semantic highlighter will be triggered
10:44:44leorizeit should not be triggered as often now
10:44:58narimirantranslation? :)
10:45:19narimirani.e. what do i need to look for?
10:45:23*clyybber quit (Quit: Quit)
10:45:34leorizecheck if everything still works :P
10:45:39leorizeesp. the highlighter
10:46:11leorizeI've tweaked a bit to make sure that the highlighter won't trigger when there aren't any changed text
10:47:38leorizealso, apparently no one noticed that the 'only available to files on disk' message has gone :P
10:49:08leorizeplease let me know if everything still works correctly by weekend :)
10:49:24leorizeI would like to merge refactoring to master before Nim 1.0
10:51:30*alexander92 quit (Ping timeout: 258 seconds)
10:59:04*endragor quit (Remote host closed the connection)
10:59:16*navin joined #nim
10:59:36*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
11:01:50*laaron joined #nim
11:03:21*navin quit (Remote host closed the connection)
11:13:42*dddddd joined #nim
11:14:10FromGitter<mratsim> But is Nim 1.0 scheduled?
11:14:36narimiranhuh? read the logs from this morning
11:15:57PMunchmratsim: https://irclogs.nim-lang.org/20-09-2019.html#08:40:53
11:16:42PMunchAnd the answer to this: https://irclogs.nim-lang.org/20-09-2019.html#08:37:01
11:19:02*navin joined #nim
11:23:39*navin quit (Ping timeout: 250 seconds)
11:26:35*navin joined #nim
11:27:28*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
11:27:56*laaron joined #nim
11:37:56*rockcavera joined #nim
11:48:17*navin quit (Remote host closed the connection)
11:49:15*navin joined #nim
11:51:23*gangstacat quit (Ping timeout: 276 seconds)
11:53:46*Perkol quit (Remote host closed the connection)
12:01:09*gangstacat joined #nim
12:03:33*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
12:08:17*laaron joined #nim
12:16:06*thomasross quit (Ping timeout: 246 seconds)
12:19:25*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
12:20:19*alexander92 joined #nim
12:20:57*laaron joined #nim
12:24:33*laaron quit (Client Quit)
12:25:30*laaron joined #nim
12:32:09*Kaivo joined #nim
12:33:22*thomasross joined #nim
12:37:13*navin quit (Remote host closed the connection)
12:37:50*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
12:39:10*laaron joined #nim
12:39:39lqdev[m]so hyped for 1.0
12:39:58PMunchChoo choo!
12:40:06lqdev[m]mainly because my mates will stop saying Nim's not even out of 1.0 yet lol
12:41:55*laaron quit (Client Quit)
12:42:30FromGitter<Vindaar> Damn, seems like I will miss the release of 1.0, cause I'll be on vacation for 3 weeks from Sunday on
12:42:43*laaron joined #nim
12:44:48lqdev[m]I'm on yesterday's devel, I'm gonna test during the weekend
12:46:14*laaron quit (Client Quit)
12:46:27lqdev[m]one gripe I have is the way unused imports are handled; they basically ignore exports. say you have module a with the type A, then you have module b which imports a and exports A, if you import b and use A there'll still be an unused warning
12:47:08lqdev[m]this has been an issue for the entirety of 0.20.99 devel for me
12:47:53*laaron joined #nim
12:48:08Zevvlqdev[m]: when defined(nimHasUsed): {.used.}
12:48:41lqdev[m]that works with imports?
12:48:55lqdev[m]I tried some time ago and it didn't work
12:49:02lqdev[m]there was a parse error
12:49:25Zevvthere was if you only do {.used.}
12:49:34Zevvthus the when defined(nimHasUsed)
12:49:51lqdev[m]that's verbose
12:50:03ZevvI have similar problems because these modules do not export anything, but run some toplevel code instead
12:50:09ZevvI'm not too fond of it, but it works for me for now
12:50:10*laaron quit (Client Quit)
12:50:16lqdev[m]I wonder what prevents this issue from being solved properly though?
12:50:23Zevvtime, probably
12:50:38ZevvI guess the definition of 'used' is the problem here
12:51:22lqdev[m]seems like it, but it's been so long since this issue started being a thing that this could've been fixed long ago. I guess there were more important matters
12:52:01lqdev[m]still, that doesn't make 1.0 that much worse :)
12:52:42*laaron joined #nim
12:53:50*laaron quit (Client Quit)
12:55:44*laaron joined #nim
12:56:05*lritter joined #nim
13:04:00*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
13:06:31*laaron joined #nim
13:08:00*laaron quit (Client Quit)
13:09:46*laaron joined #nim
13:20:50*navin joined #nim
13:22:05*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
13:24:24*laaron joined #nim
13:26:30alexander92what
13:26:58alexander92i wonder what would be the people top questions/stuff asked for
13:28:46PMunchHmm, when using locks/channels/other blocking stuff with threadpool, that will block the entire thread that it runs on right?
13:29:41*Vladar joined #nim
13:31:02FromGitter<mratsim> Blocking blocks the entire thread
13:31:32*a_b_m joined #nim
13:31:35FromGitter<mratsim> Locks or sync IO
13:32:01*a_b_m quit (Read error: Connection reset by peer)
13:32:13FromGitter<mratsim> Channels, they block if buffer is full or if they are unbuffered
13:32:20PMunchYeah yeah, I know
13:32:24PMunchI wonder if implementing something similar to what asyncdispatch does, but extend it to include locking and channels, and make it run on multiple threads would be a good idea.
13:33:04FromGitter<mratsim> I don't think so
13:33:52FromGitter<mratsim> For multithreaded IO, it's interesting
13:34:07PMunchSo essentially something like `if not tryLock(theLock): threadAwait theLock`, and then having the dispatcher queue that process up until the lock is freed
13:35:15FromGitter<mratsim> If you use locks, it's because you need low-level tinkering with threads, spawning a new threads automatically will create impredictable behavior and needs of workarounds
13:35:33*abm quit (Ping timeout: 265 seconds)
13:35:48*alexander92 left #nim ("WeeChat 2.4")
13:36:08*Skaruts joined #nim
13:36:14PMunchHmmm
13:36:15*PMunch quit (Remote host closed the connection)
13:36:16FromGitter<mratsim> Channels: just use buffered channels with trySend, tryRecv that return a bool
13:42:48Skarutshey guys, I've never delved into pointers in Nim, so I don't quite understand them, and now I was looking at the source code for libtcod_nim and I found objects being defined like
13:42:52Skaruts`Map* = ptr MapObj`
13:43:03Skarutsdoes this mean I have to destroy them manually?
13:43:37*navin quit (Ping timeout: 250 seconds)
13:45:39Skarutsto complete the above: `MapObj* {.bycopy.} = object`
13:45:40FromGitter<mratsim> Yes
13:46:00AraqSkaruts, depends on the wrapper
13:46:01FromGitter<mratsim> Or wrap them in an object with a destructor
13:46:09FromGitter<mratsim> Or a ref with a finalizer
13:48:23SkarutsI've no clue what any of that even is...
13:48:42Skarutsthe lib's samples don't seem to destroy anything
13:48:44Skarutshttps://github.com/Vladar4/libtcod_nim/blob/4b2efc7832838647b370e0dc7d27490d722d8265/samples112/samples.nim
13:49:12Skarutsnot in the way I know, at least, like `destroy MyObject`
13:50:09Skaruts(correction, I suppose I know what a destructor is, if it's anything like a destructor in C++)
13:50:23Zevvyeah, but in nim its just not that, really
13:55:43Skarutsso basically I'd have to wrap the entire lib
13:58:00*laaron quit (Remote host closed the connection)
13:58:37*Trustable quit (Remote host closed the connection)
13:58:44Skarutswell, maybe the lib has destructors, if this is it:
13:58:47Skarutshttps://github.com/Vladar4/libtcod_nim/blob/4b2efc7832838647b370e0dc7d27490d722d8265/src112/fov.nim#L61
14:01:44*nsf quit (Quit: WeeChat 2.5)
14:02:50Skarutsis there some way to find out if my program is leaving memory leaks behind when closed?
14:03:20Skarutsor during execution
14:03:59Zevvif on linux, use valgrind
14:04:09Zevvclang and gcc have sanitizer options to do checking for you
14:04:11Skarutshmm, I'm on windows
14:09:07FromGitter<zacharycarter> Dr Memory
14:18:00FromGitter<arnetheduck> generally doesn't work with nim though, due to the gc
14:21:10*Skaruts quit (Remote host closed the connection)
14:22:42Zevvaraq, why is it you consider auto items/pairs a mistake?
14:23:54disruptekleorize: as an example of broken syntax highlighting, open https://github.com/disruptek/openapi/blob/master/src/openapi/codegen.nim and jump to the bottom of the file, eg. `G`
14:26:29disrupteki consider auto items/pairs a mistake because it's implicit semantics based on hidden rules.
14:29:57*Skaruts joined #nim
14:34:42*navin joined #nim
14:35:50Skarutsgives me a few "possible leaks"
14:36:24Zevvdisruptek: but where does that start and where does it and. Isn't that what an higher level language is about?
14:37:18*alexander92 joined #nim
14:38:08disrupteklet me put it to you like this: i know how to determine/override the magical semantics of python's __foo__ calls. not so with nim. but i'm willing to admit that could be simply because 1) there's no docs, or 2) i haven't read them, or 3) the semantics are obvious if you know where to look.
14:39:49disruptekuntil i am confident that i understand a feature, i try not to rely on it. that's why most of my nim code is pretty trivial. that's a shame, but again, the fault could be all due to my ignorance.
14:39:56ZevvWell the docs are in the manual section 'Implict items/pairs invocations', and *overriding* is something you just might not want to do
14:40:28Zevvthe manual is pretty clear on the semantics imho
14:40:50disruptekif the only implicit calls are `items` and `pairs`, i would just as soon remove them for simplicity and explicitness.
14:41:30disrupteki fully expected that there'd be other examples.
14:41:31alexander92this is a good idea, disruptek
14:41:37alexander92but it's a matter of language design
14:41:58Zevvthe old discussion, sugar or no sugar
14:42:03alexander92on the other hand it makes it harder to use for loops , as now they only work directly with stuff
14:42:09alexander92that the compiler knows about
14:42:30alexander92and items for all user defined types: this might be a good thing, but it's really subjective imo
14:42:42alexander92but iirc there are others
14:42:50alexander92you can write `.` and `()` macros
14:43:07alexander92when we were working on py2nim, we tried to model many of those __slot__ methods to nim equivalents
14:43:14*laaron joined #nim
14:44:15disruptekwhen you cannot type the `foo` in `for foo in bar:` then which is getting invoked? `pairs()` or `items()`?
14:44:33disrupteki really wish i could `for foo: FooType in bar:`.
14:44:42alexander92i'd guess it doesn't matter
14:44:51alexander92what i'd expect is items if its for a
14:44:54Zevv"when [...] the for loop has exactly 1 variable, the for loop expression is rewritten to items(e)"
14:44:58alexander92pairs if its for a,b
14:45:08alexander92disruptek, this sounds like return type overloading
14:45:45disruptekno, the workaround is to define a proc `bif` and then `for foo in bar: foo.bif`; you get the type checking you want.
14:46:00disruptek"it doesn't matter" is the most accurate statement, afaict.
14:46:07alexander92disruptek, example is also
14:46:09alexander92https://github.com/metacraft-labs/py2nim_deprecated/tree/master/tests/python
14:46:21alexander92and https://github.com/metacraft-labs/py2nim_deprecated/blob/master/tests/nim/call.nim
14:48:23disruptekZevv: the problem is that i want to typecheck my tuple return type destructuring from `pairs()`, and i don't know how to do that otherwise.
14:48:39alexander92overriding is a good point
14:48:55alexander92disruptek you can do for (a, b) in ..
14:49:05alexander92ah sorry, i misread tuple
14:49:11*navin quit (Remote host closed the connection)
14:49:29alexander92no, it is `tuple` .. nvm
14:49:45*navin joined #nim
14:49:48leorizedisruptek: templates are not evaluated until they're used
14:50:00leorizeso nimsuggest won't highlight them (should be fixed ofc)
14:50:14leorizealso template name are never highlighted for some reason
14:51:12disruptek`for temp: MyTempTuple in getTemperatures.pairs: echo temp.inF; echo temp.inC` is superior to `for (inF, inC) in getTemperatures():`; does that make sense?
14:51:38leorizeSkaruts: windows cleanup resources once your program closes
14:51:43leorizelike every sane os :P
14:51:44disruptekleorize: they work fine for me most of the time. eg. from logging, `warn`, `info`, etc. are all highlighted as templates.
14:51:57leorizeonce you use them they will highlight
14:52:05leorizeone of the nimsuggest quirks
14:52:25alexander92but why? why is MyTempTuple temp?
14:52:30disruptekweirdly, i rarely need to highlight identifiers that i don't use. 😜
14:52:35alexander92ah, temperature, not temp
14:52:42Zevvoooh leorize do inline-red-letters-error-messages inside my vim source just like cdecl
14:53:32Zevvno clangd that is
14:53:34alexander92well, i am not sure i get your usecase disruptek, that's the same as "a: MyTempTuple = call()"
14:53:44leorizeZevv: you mean that annotation thingy?
14:53:51leorizedoesn't ALE already do it?
14:53:56disruptekalexander92: nah, my example is for loop iteration.
14:53:57*navin quit (Ping timeout: 246 seconds)
14:53:59Zevvale?
14:54:06alexander92but it is the same principle
14:54:15alexander92you invoke something with a return type
14:54:17leorizeZevv: it's a linter plugin
14:54:21Zevvah oh
14:54:22disruptekexactly, and yet you cannot type-check that interim variable `temp`.
14:54:24leorizehas nim support
14:54:32alexander92but it can have only one possible type
14:54:37leorizeif it doesn't do that then I'll consider adding the annotation thingy
14:54:47ZevvI would *hate* that :)
14:54:51disruptekthe order of the tuple fields could be reversed accidentally.
14:55:00disruptekor, i could misremember the order of the values.
14:55:01Zevvall these letters in my editor that I didn't type there myself!
14:55:28disruptekfor (inC, inF) in getTemperatures(): -- where is the bug?
14:55:32alexander92wbut .. dis
14:55:36alexander92ops*
14:55:42alexander92but disruptek
14:55:47alexander92this is true for all possible usages
14:55:50alexander92of tuples
14:55:56disrupteknope.
14:55:57alexander92var (inc, inf) = getTempCall()
14:56:00alexander92where is the bug
14:56:01leorizeZevv: do you have pics? :P I'd like to see how that annotating thingy looks like
14:56:46disruptekvar foo: MyTupleType = getTempCall() # avoid future bug
14:57:00Zevvleorize: http://zevv.nl/div/redletters.png
14:57:05disruptekwhere is your defensive programming wrt my for loop?
14:57:25alexander92but while you write your own code, you know if getTempCall returns MyTupleType
14:57:44alexander92i dont understand why would you need to repeat that info
14:57:46alexander92on the callsite
14:58:00alexander92a bit like var i: int = parseInt
14:58:04disruptekbecause i want to assert that the type i'm about to work with is correct.
14:58:09leorizefor t in getTemperatures(): when not t is MyTupleType: {.error: "t is not the type that I like".} :P
14:58:10alexander92good
14:58:15alexander92in this case, can't one
14:58:20alexander92yes, do something like this ^
14:58:34*abm joined #nim
14:58:44leorizeyou can always do this as well:
14:58:55leorizefor t in getTemps(): let t: MyTupleType = t
14:59:00disruptekgreat, you guys think that a hidden invocation of `pairs()` is "sugar" but i should be putting in compile-time `when` statements in all my loops... makes sense!
14:59:13*disruptek 🙄
14:59:23alexander92but this is just bizarre
14:59:27alexander92i dont understand
14:59:33alexander92why do you need to assert that
14:59:42alexander92why dont you need to do
14:59:46disruptekbecause depending on what the type is, a call might vary.
14:59:48alexander92var i: int = parseInt("e")
15:00:01alexander92ok, i can see it in some cases, but not in most loops
15:00:06disruptek`for bar in bif: echo $bar` -- which $ am i invoking? any idea?
15:00:59disruptekanyway... i will continue to specify tuple types in my code and simple invoke procs with those types on each iteration. solves my problem using simple constructs that already exist in the language.
15:01:10FromGitter<arnetheduck> as long as they all follow the agreed-upon semantic for `$`, does it matter?
15:01:13alexander92well, then something like "typeAssert t is MyTupleType"
15:01:18disruptekabsolutely it matters.
15:01:20alexander92seems also simple
15:01:28leorizeZevv: eh, that doesn't look really nice
15:01:38lqdev[m]leorize: protip: `notin` is a thing
15:01:45Zevvnot at all. That's why I said I would *hate* that :)
15:01:47leorizedisruptek: did you see my obviously simpler version? :P
15:01:51lqdev[m]s/notin/isnot
15:02:17leorizelet t: MyTupleType = t
15:02:21leorizeput that in the for loop
15:02:28leorizeit will shadow the actual t variable
15:02:31leorizeproblem solved
15:02:41disrupteksure.
15:03:00disrupteki guess i find `for t: MyTupleType in bar:` easier to read. maybe it's just me.
15:03:43alexander92it is a bit easier to read indeed
15:04:23alexander92and one can argue it's similar to var t: T = ..
15:04:43alexander92you can always open a RFC
15:05:18*navin joined #nim
15:07:33*laaron quit (Remote host closed the connection)
15:08:07*rockcavera quit (Remote host closed the connection)
15:08:17*nif quit (Quit: ...)
15:08:26*nif joined #nim
15:09:28*navin quit (Ping timeout: 245 seconds)
15:10:22disrupteki will implement it as a macro. what would you call it?
15:10:54leorizeexplicit()?
15:11:15leorizefor t: MyType in explicit(iterator(object))
15:11:27leorizeyour biggest problem would be the `:` next to `t` though
15:11:29disruptekno, the typed for.
15:11:42disruptekthe syntax is macro-able, so it's trivial.
15:12:19leorizefor loop macros can rewrite the for loop
15:12:26disruptekit'll be like `typedFor t: MyTupleType in bar:`
15:13:27*navin joined #nim
15:13:28disruptekor maybe it should be like `for t in bar of MyTupleType:`
15:13:42disruptekor maybe it should be like `for t in bar.pairs of MyTupleType:`
15:16:47*abm quit (Remote host closed the connection)
15:17:16*abm joined #nim
15:17:26leorize!eval for (t: int) in [0, 1, 2]: discard
15:17:28NimBotCompile failed: /usercode/in.nim(1, 8) Error: expected: ')', but got: ':'
15:17:44leorizelooks like the parser won't let this pass :P
15:17:48*navin quit (Ping timeout: 245 seconds)
15:18:17disrupteki'm thinking `each t in bar.pairs of MyTupleType:` but i kinda hate to eat up the lucrative `each` identifier.
15:22:59FromGitter<alehander42> !eval typedfor t: M in bar
15:23:00NimBotCompile failed: /usercode/in.nim(1, 1) Error: undeclared identifier: 'typedfor'
15:23:11FromGitter<alehander42> it would pass
15:23:19FromGitter<alehander42> for is different of typedFor
15:24:52leorize!eval for t in int(items([0,1])): discard
15:24:53NimBotCompile failed: /usercode/in.nim(1, 19) Error: attempting to call routine: 'items'
15:25:42disruptekit's easier to just write the macro. all it has to do is juggle some nodes around.
15:28:22*alexander92 quit (Ping timeout: 268 seconds)
15:34:44*lqdev[m] uploaded an image: image.png (1KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/NePXMxkbxNAqJNdfpOGJhqmI >
15:34:51lqdev[m]treeform: am I doing something wrong?
15:35:00lqdev[m]the space seems way too big
15:35:08lqdev[m]also there's some keming present in certain strings
15:35:26*lqdev[m] uploaded an image: image.png (1KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/LDdCWQoRZGqWasryzAjSluFa >
15:35:29lqdev[m]eg. here ↑
15:37:23lqdev[m]also, how can I make the text look sharper? it looks really blurry everywhere
15:40:07lqdev[m]man, I don't know if I like this text rendering
15:42:18lqdev[m]don't get me wrong, it's amazing you created a whole typography library all on your own, but the results are kind of disappointing after seeing so much of FT-rendered text
15:42:39lqdev[m]…and to think all of this effort went just to support text boxes
15:43:32disruptekholy shit, it worked first time.
15:44:04disruptekthis is hilarious. what an incredible language.
15:45:59disruptekhttps://gist.github.com/disruptek/89f2979b58901cd5d90057b4b02a5647
15:48:28*theelous3 joined #nim
15:58:10FromGitter<mratsim> @lqdev I don't know treeform lib but I know that font rendering is all kinds of broken easily. Between subpixel rendering with RGB to mimic a vibrant black or whatever, aliasing, ligatures, monospace, glyphs interpolation for some sizes (or SVG for big one).
15:58:34FromGitter<mratsim> I remember installing forks of freetype often in the paste also for proper Cleartype font rendering
16:01:45lqdev[m]all I want is nice, smooth font rendering without all this RGB crap (since it's a pain to implement)
16:05:13lqdev[m]also for some reason, a pure Nim library added weight to my executable
16:05:28lqdev[m]somehow, treeform's library is bigger than freetype
16:05:32lqdev[m]I don't even want to know how
16:19:26*matlock joined #nim
16:35:27*Cthalupa quit (Ping timeout: 245 seconds)
16:36:43*Cthalupa joined #nim
16:48:16*matlock quit (Read error: Connection reset by peer)
16:49:41*vsantana joined #nim
17:13:32*navin joined #nim