<< 26-01-2016 >>
00:05:15*vendethiel quit (Ping timeout: 240 seconds)
00:07:52*Matthias247 quit (Read error: Connection reset by peer)
00:11:27*vendethiel joined #nim
00:12:54*buMPnet quit (Read error: Connection reset by peer)
00:18:40*desophos quit (Ping timeout: 250 seconds)
00:27:46*Varriount-Laptop quit (Ping timeout: 240 seconds)
00:32:12*lompik joined #nim
00:37:05M-maxFlyx: touché
00:55:26*vendethiel quit (Ping timeout: 240 seconds)
00:56:15*jaco60 quit (Ping timeout: 260 seconds)
00:59:24*vendethiel joined #nim
01:11:14*desophos joined #nim
01:22:23*vendethiel quit (Ping timeout: 276 seconds)
01:24:06*vendethiel joined #nim
01:45:46*vendethiel quit (Ping timeout: 250 seconds)
01:46:00*xet7 quit (Quit: Leaving)
01:49:07*vendethiel joined #nim
01:49:58*gokr quit (Quit: Leaving.)
01:51:05*onionhammer joined #nim
02:02:29*Varriount-Laptop joined #nim
02:10:23*vendethiel quit (Ping timeout: 264 seconds)
02:14:35*vendethiel joined #nim
02:34:50*brson quit (Ping timeout: 260 seconds)
02:36:33*apotheon quit (Ping timeout: 250 seconds)
02:37:18*vendethiel quit (Ping timeout: 256 seconds)
02:38:04*apotheon joined #nim
02:43:17*vendethiel joined #nim
02:50:44*Demon_Fox joined #nim
03:03:55*vendethiel quit (Ping timeout: 240 seconds)
03:54:29*kniteli quit (Ping timeout: 276 seconds)
04:13:46*Varriount-Laptop quit (Ping timeout: 240 seconds)
04:21:51*Varriount-Laptop joined #nim
04:42:51*vendethiel joined #nim
05:04:36*vendethiel quit (Ping timeout: 265 seconds)
05:10:42*brson joined #nim
05:10:43*vendethiel joined #nim
05:26:06*Varriount-Laptop quit (Ping timeout: 240 seconds)
05:32:24*vendethiel quit (Ping timeout: 250 seconds)
05:47:08*vendethiel joined #nim
05:51:11*lompik quit (Ping timeout: 264 seconds)
05:54:04*desophos_ joined #nim
05:57:50*desophos quit (Ping timeout: 260 seconds)
06:01:35*desophos_ quit (Ping timeout: 240 seconds)
06:03:14*darkf joined #nim
06:03:42*desophos joined #nim
06:06:45*Varriount-Laptop joined #nim
06:08:48*vendethiel quit (Ping timeout: 250 seconds)
06:15:36*ephja joined #nim
06:45:09*Varriount-Laptop quit (Read error: Connection reset by peer)
06:58:38*Demon_Fox quit (Quit: Leaving)
07:20:56*desophos quit (Read error: Connection reset by peer)
07:21:46*brson quit (Ping timeout: 256 seconds)
07:32:29*vendethiel joined #nim
07:44:39*gokr joined #nim
07:54:15*vendethiel quit (Ping timeout: 265 seconds)
08:15:21*vendethiel joined #nim
08:15:40*darkf_ joined #nim
08:16:58*darkf quit (Ping timeout: 265 seconds)
08:20:42*darkf_ is now known as darkf
08:22:53*yglukhov joined #nim
08:33:03*Arrrr joined #nim
08:59:58*vendethiel quit (Ping timeout: 250 seconds)
09:08:17*coffeepot joined #nim
09:13:32*Trustable joined #nim
09:19:32*coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
09:21:17*coffeepot joined #nim
09:26:47*vendethiel joined #nim
09:54:56*Arrrrr joined #nim
09:56:06*Arrrr quit (Ping timeout: 240 seconds)
10:10:30*vendethiel quit (Ping timeout: 245 seconds)
10:11:42*jaco60 joined #nim
10:23:36*urb joined #nim
10:24:14urbIf all a proc does is call a different proc, does the compiler optimize that away?
10:25:47*vendethiel joined #nim
10:26:30coffeepoturb: good question, I'd expect it'd depend on the back end compiler but interesting to see if anyone else has comment. Incidentally, you can always use a template for a more 'inline' proc, depending on the proc of course.
10:28:35dom96urb: does that proc get called?
10:28:36reactormonkurb, the C compiler should do that for you I'd expect
10:29:01dom96because if it does then I don't see why it would be optimised away
10:31:29urbcoffeepot: oh, didn't even think of the template solution. Have to get used to having those available. In this case, I'm mostly asking out of curiosity
10:32:25urbdom96: I don't quite understand what you're saying...
10:32:59Araq_urb: the C backend optimizes it away
10:33:10dom96Maybe i'm misunderstanding the scenario
10:34:47urbAraq_: ok, thanks!
10:37:37urbdom96: I was just referring to defining a proc which just passes its arguments to a different proc, so I'd basically just be renaming it. I was curious if the compiler gets rid of one proc call there.
10:38:03dom96I see.
10:38:32dom96Thank you for clarifying.
10:45:07*exebook joined #nim
10:46:45*vendethiel quit (Ping timeout: 245 seconds)
10:49:59*urb quit (Quit: Page closed)
10:51:49*vendethiel joined #nim
11:01:58*gokr quit (Quit: Leaving.)
11:10:25*RG92 joined #nim
11:13:26*vendethiel quit (Ping timeout: 240 seconds)
11:14:48*gokr joined #nim
11:19:53*RG92 left #nim (#nim)
11:21:15*coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
11:21:45*coffeepot joined #nim
11:24:49*Salewski joined #nim
11:29:35SalewskiI am using gvim, which displays error generally fine. But for this "var c: char; echo c > 4" no error is displayed in gvim, but compiler displays error of course. I thought that gvim plugin used the compiler to display error?
11:30:39Araq_Salewski: sorry I don't use gvim, no idea
11:30:53*nchambers is now known as nnttcc
11:34:11SalewskiAraq: A more important question: arithmetic operation between different float types are allowed, but operation between int type and float type not. Why? Efficiency seems to be not the reason? I dont care much for this, but I know some people who like 2.0 + 3 just to work!
11:34:33*nnttcc is now known as nchambers
11:35:49Salewski(var a = 2; b = 3.0; echo a + b)
11:40:40Araq_ints can be 64 bits and so can have values that double cannot represent precisely
11:40:44SalewskiAnd I really wonder if allowed operations between operands of different float type are a good idea.
11:40:59Araq_and we don't have implicit conversations which lose information
11:41:07Araq_*conversions lol
11:51:43*vendethiel joined #nim
11:59:38Araq_oh my god, somebody needs to do something about db_odbc
11:59:46Araq_coffeepot: where are you?
12:00:03Araq_it's your module, go through the list of PRs and review/merge them
12:00:21coffeepotAraq_ uk
12:00:42Araq_congrats, seems to be a popular module :-)
12:00:49Araq_too bad it doesn't work.
12:00:52coffeepotactually speaking of odbc i'm just in the process of publishing mine in nimble
12:01:10coffeepoti didn't write db_odbc
12:01:36coffeepoti have my own odbc implementation that doesn't use the db_ architecture
12:01:48Araq_oh aha
12:02:06Araq_well it would be nice if you could review it anyway.
12:02:57coffeepotsure, i'll have a look. Obviously everyone should just use mine though because it's actually typed instead of using strings :D
12:05:14*test joined #nim
12:05:16Araq_how do you do the typing?
12:05:28Araq_I am working on an ORM building on top of the db* modules
12:05:38*test is now known as Guest3817
12:06:43*Guest3817 quit (Client Quit)
12:10:33coffeepothere's my repo https://github.com/coffeepots/odbc (test module under private/tryodbc.nim). The fetch row is here https://github.com/coffeepots/odbc/blob/master/odbc.nim#L99 and the actual casting is done here https://github.com/coffeepots/odbc/blob/master/odbcparams.nim#L149
12:12:06Araq_what is SQLData?
12:12:53coffeepotsqlData: https://github.com/coffeepots/odbc/blob/master/odbctypes.nim#L21
12:12:55*Salewski quit ()
12:12:55*vendethiel quit (Ping timeout: 260 seconds)
12:13:31Araq_ of dtNull: nullVal*: string
12:13:36Araq_interesting.
12:13:37coffeepotyeah i know :P
12:13:41coffeepotthe reason is
12:14:02coffeepotit would allow to define a value that represents null like "<null>" or whatever
12:14:32coffeepotof course you don't check the string value ever because you use isNull, which checks the variant branch
12:14:33coffeepotiirc
12:15:06coffeepotthe null type could be anything tbh
12:16:59coffeepotthe code architecture isn't what i'd call perfect, but I much prefer how it's used than the db_* modules personally
12:17:21coffeepotand it can handle varbinary as seq[byte]
12:18:04*RG92 joined #nim
12:19:05coffeepotalso it doesn't use text substitution for parameters o_O, it uses proper odbc params - and you can name them and define their prefix, plus you can use the same param multiple times in the same query and it sorts it out for you
12:19:38coffeepotimho it's vastly better than db_* but of course they're only 'starter' db modules I guess
12:20:09coffeepothaving said that I've not used it anything but simple work projects so far so there are probably bugs
12:21:13coffeepoton simple benchmarks i get faster performance than delphi's dbexpress and firedac so i'm happy with that so far.
12:21:59coffeepotas you can see by my comments there are some relatively easy performance improvements that could be made if required
12:23:37coffeepotand looking at it now, i like how it also converts the field types for you if possible
12:25:11coffeepotI did contemplate restructuring it to allow hooks for other databases but that's a fair bit of work I'd imagine
12:28:31yglukhovAraq: is there a way to explicitly free memory allocated by gc?
12:31:06*vendethiel joined #nim
12:38:44*zaquest joined #nim
12:40:30*RG92 quit (Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030])
12:44:46*RG92 joined #nim
12:52:28*vendethiel quit (Ping timeout: 265 seconds)
12:54:07*BitPuffin joined #nim
12:56:35*vendethiel joined #nim
12:59:14*BitPuffin quit (Ping timeout: 250 seconds)
13:00:28*arnetheduck joined #nim
13:02:42*e_deep2 quit (Read error: Connection reset by peer)
13:06:13*BitPuffin joined #nim
13:19:35*vendethiel quit (Ping timeout: 240 seconds)
13:21:37*coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
13:22:01*coffeepot joined #nim
13:23:41*junw joined #nim
13:38:47*vendethiel joined #nim
13:41:00*exebook quit (Remote host closed the connection)
13:46:36*exebook joined #nim
13:48:53*lompik joined #nim
13:59:15*vendethiel quit (Ping timeout: 240 seconds)
14:08:34*lg_ joined #nim
14:24:15*derka joined #nim
14:24:16derkaim
14:24:27derkaHi guys
14:31:01Araq_yglukhov: not really and it wouldn't be fast anyway
14:31:26*arnetheduck quit (Ping timeout: 240 seconds)
14:31:33yglukhovAraq: is refcounting gc ready to test?
14:32:23Araq_there is only v2 of the collector which means the cycle collector is faster and adheres to deadlines
14:33:02Araq_but it's not ready yet and my focus is instead on making async use multiple cores under the hood
14:33:49yglukhovI'm currently using default gc, and it seems like there's out of memory problem on Android (which im not 100% sure about). We're using a lot of big temp buffers. so i wanted to make sure they are deleted in time somehow...
14:35:03Araq_you can set them to nil and call GC_collect
14:47:30*lompik quit (Ping timeout: 260 seconds)
14:48:30coffeepotI must say, coming from a non-GC language, it was weird to find that seq and table have no clear proc, and instead I just assign a new seq! I *think* that's what I should be doing!
14:49:11Araq_no, x.clear is x.setLen(0)
14:50:14coffeepotAlright, noted :) Will do that instead
14:51:06Araq_but yeah, a clear for tables would be nice.
14:52:58coffeepotmight make a pr for this: proc clear[T]*(s: seq[T]) = s.setLen(0)
14:53:29coffeepottables might be a bit more involved though
14:56:04Araq_it's clear*[T] btw
14:56:23coffeepotoops :)
14:56:50*bozaloshtsh quit (Ping timeout: 260 seconds)
15:09:53Arrrrryes, a clear would come handy
15:10:09ArrrrrAnd also isEmpty = len(s) == 0
15:11:16coffeepotArrrr: yeah, seems simple but helps make clearer code imo
15:11:33*Jesin quit (Quit: Leaving)
15:12:00*derka quit (Quit: derka)
15:12:22coffeepotthis would, of course, mean adding something to system.nim :-O
15:12:27*derka joined #nim
15:15:54dom96hi derka
15:16:02derkadom96: hi how r u
15:16:17dom96good
15:16:20derkagreat
15:16:41*derka quit (Client Quit)
15:23:51*coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
15:24:11*coffeepot joined #nim
15:27:00*NimBot joined #nim
15:33:43*aziz joined #nim
15:36:45*derka joined #nim
15:42:13*derka quit (Quit: derka)
15:44:22coffeepoti take it you can't squash commits on the git website?
15:47:13*derka joined #nim
15:48:51*derka quit (Client Quit)
15:51:31*derka joined #nim
15:51:37*gokr quit (Quit: Leaving.)
15:51:46*gokr joined #nim
15:52:45*brson joined #nim
16:02:10*derka quit (Ping timeout: 245 seconds)
16:03:53gokrNow I understand why people started commenting on my article about Nim: https://news.ycombinator.com/item?id=10947192
16:03:59gokrI totally missed that.
16:04:44*coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
16:06:43*derka joined #nim
16:07:59*pwernersbach joined #nim
16:10:33*coffeepot joined #nim
16:12:19*Jesin joined #nim
16:13:59*derka quit (Ping timeout: 264 seconds)
16:15:56Araq_gokr: only good comments, I hope ;-)
16:18:04gokrI skimmed it through and made some clarifications on HN, pcwalton of course had to pour his views but I think it ended up balanced anyway.
16:21:00*derka joined #nim
16:25:52*vendethiel joined #nim
16:29:26*junw quit (Quit: Leaving)
16:34:34coffeepot"Does Nim now deep copy all messages between threads and start every thread with a fresh environment?" That is currently true, isn't it?
16:34:48coffeepotunless of course you send a pointer through a channel
16:36:40*junw joined #nim
16:49:17*vendethiel quit (Ping timeout: 276 seconds)
16:51:15dom96oh, I didn't see those new messages made by pcwalton et al
16:52:10*sjums joined #nim
16:53:06*RG92 quit (Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030])
16:54:15*Salewski joined #nim
16:55:10SalewskiCan not find odd and even proc for int type. Missing?
16:57:34*derka quit (Quit: derka)
16:58:49dom96Salewski: x mod 2 == 0?
16:59:20*derka joined #nim
16:59:54*derka quit (Client Quit)
17:00:48SalewskiThanks, but I really expected odd and even to exists.
17:02:32ArrrrrThat's odd
17:03:10ArrrrrBut a good suggestion to add to math.
17:04:11*coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
17:05:36SalewskiWe may argue that simple procs like odd, even, sign, copy_sign are not really necessary. True, but people expect them to exist, the search about then, which cost some time. And copy_sign -- I would really like that, not fully trivial.
17:06:17dom96Personally I wouldn't expect those to exist.
17:07:19SalewskiOdd, even is there in Modula, Oberon, Ruby. In Ruby with a terminating ?
17:07:51ArrrrrI won't expect them, but i agree they are a good adition
17:08:37SalewskiAnd copy_sign and sign can be really usefull, I thin C or C++ has it, and copy_sign is not easy to made at home...
17:11:47SalewskiVery good solution is not that simple, see http://stackoverflow.com/questions/1903954/is-there-a-standard-sign-function-signum-sgn-in-c-c
17:11:54SalewskiBye
17:11:58*Salewski quit ()
17:24:54*derka joined #nim
17:30:15*zaquest quit (Ping timeout: 260 seconds)
17:30:16*EastByte quit (Ping timeout: 260 seconds)
17:30:16*r-ku quit (Ping timeout: 260 seconds)
17:30:50*rinukkusu quit (Ping timeout: 260 seconds)
17:34:41*rinukkusu joined #nim
17:34:50*r-ku joined #nim
17:36:10*EastByte joined #nim
17:36:38*zaquest joined #nim
17:40:30Araq_salewski: PRs are always welcome
17:40:51Araq_it for some things it takes as much time as discussing it
17:56:19*derka quit (Quit: derka)
17:58:21*derka joined #nim
18:02:26*derka quit (Ping timeout: 240 seconds)
18:04:20*vendethiel joined #nim
18:25:40*yglukhov quit (Ping timeout: 260 seconds)
18:35:41*dextorious joined #nim
18:40:53*Matthias247 joined #nim
18:52:32*BitPuffin quit (Ping timeout: 256 seconds)
18:53:38*xificurC joined #nim
19:00:47*junw_ joined #nim
19:03:15*junw quit (Ping timeout: 240 seconds)
19:05:06*Arrrrr quit (Ping timeout: 240 seconds)
19:06:45*yglukhov joined #nim
19:09:07wuehlmausi play around with pegs instead of using nre. what is the equivalent off \d{3,5} with pegs? sorry about the a bit offtopic question.
19:11:36*yglukhov quit (Ping timeout: 272 seconds)
19:15:42pwernersbachI have a structure like this: Future -> tuple -> Future
19:15:44pwernersbachIs there a guide on how to break a cycle with a tuple?
19:16:44pwernersbachWhere the futures are the same. So there's a cycle that I need to break. I figure I can break the cycle safely since the tuple's only reference is the Future, but I can't find a guide on how to do it.
19:59:47*Nikopol_ joined #nim
20:00:00*Nikopol_ left #nim (#nim)
20:08:49*zaquest quit (Quit: Leaving)
20:15:20pwernersbachHmm, acyclic doesn't seem to work
20:17:12ephjaeither get rid of the recursion or turn the recursive tail into a pointer type
20:27:33pwernersbachephja: Thanks, that worked
20:27:49Araq_pwernersbach: is that yet another workaround for the debug GC's recursion limit?
20:28:04pwernersbachAraq_: Yes sir
20:28:27Araq_can't you patch the GC instead?
20:28:45Araq_{.push stackTrace:off.} ... {.pop.}
20:29:14pwernersbachAraq_: This whole thing is a workaround for the recursion limit. If there wasn't the recursion limit, I wouldn't have to have a manually memory managed linked list, etc. etc.
20:29:30Araq_the problem should be gone with gc:v2
20:29:44pwernersbachIf I compile with gc:v2 it will work you say?
20:29:44Araq_which is not ready but I can raise its priority
20:29:48pwernersbachIn v0.13.0?
20:29:58*yglukhov joined #nim
20:29:59pwernersbachOh okay
20:30:20Araq_let me push a workaround now
20:31:50Araq_sux that I didn't attack this for v0.13, maybe I need a nanny
20:32:21pwernersbachIt's okay, you work for free
20:32:41pwernersbachI'm trying to get my company to allocate funds to donate to you guys, but rome wasn't built in a day
20:32:57ephjaoh
20:34:32*filwit joined #nim
20:35:58*dthrvr quit (Ping timeout: 250 seconds)
20:36:34filwithey folks, what's the best way to manually set the optimization GCC (or other CC) flag for release builds?
20:37:08pwernersbachfilwit: I use passC to set mine to O4
20:37:13pwernersbach--opt:speed will do O3
20:37:33filwiteg, I want to use -Ofast instead of -O3, but passing --passC:-Ofast sets both and -O3 takes over
20:38:08filwitpwernerbach: hmm... when you do passC:O4 you don't see -O3 in the GCC output when you use --listCmd?
20:38:44filwitcause when i use --passC:Ofast I still get -O3 in the gcc commands..
20:40:21pwernersbachI still see O3, but I just assumed O4 stuck
20:40:36pwernersbachI pass flto as well anyways, so its a moot point for me
20:41:55pwernersbachfilwit: try --opt:none, it gets rid of "-O3 -ffast-math" here and leaves my passC
20:42:02filwitpwernerbach: well I was manually compiling the other day (copied the listCmd output into my own make file to build with different settings) and if I compiled with -O3 -Ofast then the performance was the same as just -O3, but if I just had -Ofast it respected that and produced faster bins
20:42:27filwitpwernerbach: ahh.. good idea
20:43:10filwitpwernerbach: though I'm guessing there's some `gcc.opt = ...` setting I can put in the nim.cfg file is why I'm asking here
20:44:20pwernersbachYou can put both --opt:speed and --passC:none in your nim.cfg file, that's what I do
20:44:38pwernersbachI don't know of a gcc specific setting though
20:46:51filwitalso, I was a bit disappointed to learn that using `const` (with objects) is slower than using `templates`, due to the` memset(0)` C command that always gets placed at the callsite of where the const object is used.
20:48:44pwernersbachargh, stupid reference counting gc, after the async changes it's leaking memory, even with manually breaking the cycle. I instrumented my manually allocated linked list with an allocation counter, and my allocation counters are always zero after the code gets done, but its using infinitely increasing amounts of memory
20:48:51pwernersbachgoing afk
20:48:54filwitI'm sure this is considered an acceptable performance/safety trade for general purpose code, but I can't get rid of the zeroMem operation with some {.noinit.} pragma like I can with vars, and using templates isn't always as nice (to some very minor degree) as using const for an API
20:49:50*dthrvr joined #nim
20:51:06filwitshould I report this issue as a feature request for a const {.noinit.} pragma? I tried searching for an already open request but didn't find anything. Anyone know anything more on weather this has been discussed already?
20:52:32*enquora joined #nim
20:55:48*pwernersbach quit (Ping timeout: 252 seconds)
20:57:19Araq_filwit: .noinit for const? hum?
21:00:09filwitAraq_: to avoid the the zeroMem operation at callsite for const vars which are objects.. it was slowing down my ECS benchmark compared to C until I switched some const to templates.. due to the way Nim zeros the memory of const vars
21:00:51Araq_what are const vars?
21:01:14filwitconst gravity: Vector = (0.0, -0.98, 0.0)
21:01:19filwitetc..
21:01:42filwitvs: template gravity: Vector = (...)
21:01:54filwitusing the template version is faster
21:02:05Araq_why would it?
21:02:46filwitbecause the way Nim outputs a memSet(.., 0) operation for const variables every time they're used
21:03:14filwitthis is a minor performance concern, and it's got an easy work-around
21:03:26Araq_you mean for var v = gravity ?
21:03:41Araq_because I'm pretty sure the codegen doesn't emit memset for consts
21:04:37*Jesin quit (Quit: Leaving)
21:04:41filwitAraq_: I was just doing tests the other day... but I'll revisit them and make a issue about it.
21:06:25filwitAraq_: I was just wondering if this had already been discussed is all.. OR perhaps this has been fixed in version 0.13 (I was testing with devel, but prior to the 0.13 release)
21:07:06Araq_.noinit for consts makes no sense there is some other problem here
21:07:20Araq_which I'm trying to figure out
21:08:05filwitwell it would make sense if I'm correct and Nim does indeed output a memset(0) at the callsite of each const use (in which case {.noinit.} could be used as a way to avoid that)
21:08:31filwitbut let me revisit my benchmark and look at the C output again to verify this
21:15:41filwitAraq_: okay, so yes I just checked and Nim does indeed output a `memset(..., 0, ...)` for every place I use a const which is and `object`
21:17:04filwitAraq_: eg, if I have the code `const gravity = Vector(y: -0.98)` and then I use `gravity` in some equation, the resulting C code will memset the var, then set the `y` component (for obvious safety reasons).
21:18:36filwitcompared to `template gravity: Vector = newVector(0, -0.98, 0)` which does not zero the memory (due to `newVector` having a {.noinit.})... but even if I use `const gravity = newVector(...)` the gravity var will be memset(0) at callsite
21:22:02filwitAraq_: Like I said, very minor performance concern.. I'm iterating over ~1-2 Gbs of vector data mostly to test cache efficiency and this using templates the bench completes in ~1.7s vs ~2.1s with const
21:22:32ldleworkAraq_: mmm http://neogfx.org/
21:22:57filwitAraq_: I just noticed it the other day, and thought I'd ask about it is all.. this issue is not why I'm here right now.
21:23:00Araq_filwit: just fix the codegen rather than hacking more .noinit into your code
21:24:38filwitAraq_: okay.. like I said I wasn't aware of weather or not this issue had already been discussed (until just now). But make note and look into it later.
21:24:56filwitI'll** make note...
21:40:56*jakesyl joined #nim
21:46:20*dextorious quit (Quit: Page closed)
21:50:28*jakesyl quit (Ping timeout: 256 seconds)
21:54:28*bozaloshtsh joined #nim
21:59:35*def- quit (Ping timeout: 240 seconds)
22:01:28*def- joined #nim
22:10:30*pwernersbach joined #nim
22:13:54*xificurC quit (Quit: WeeChat 1.3)
22:14:37*darkf quit (Quit: Leaving)
22:16:38pwernersbachAraq_ or Araq: How can I figure out what the reference counting GC is failing to collect?
22:38:16*lawnchair_ joined #nim
22:40:05*Jesin joined #nim
22:40:46Araq_pwernersbach: there is no easy way unless you touch the GC
22:41:31Araq_or play around with your program
22:41:43pwernersbachAraq_: Well I'm going to have to do it then, I have absolutely no idea what's leaking
22:41:51pwernersbachWhere do I start?
22:42:18Araq_see if --gc:markAndSweep works for you
22:42:57pwernersbachyes sir
22:43:05Araq_I made the GC non-recursive but now tests are failing, this algorithm is just so wrong on so many levels
22:44:26Araq_and it was actually "proved" correct in the literature btw. Not my fault the proof is completely wrong.
22:46:58filwitI'm trying to do `macro foo(name:static[string]) = let s = bindSym(name)` but keep getting "can't evaluate 'name' at compile-time"... is this a bug and/or is there a workaround?
22:47:22pwernersbachAraq_: error with --gc:markAndSweep
22:47:22pwernersbachError: internal error: genTraverseProc()
22:48:33filwiti got it working by making `foo` take a `name:typed{nkStrLit}` and outputing another macro with that sym injected directly into the 'bindSym' command, then calling the injected macro... but that seems hacky and requires me to export stuff from macros to get it to work
22:49:37Araq_filwit: bindSym only works with string literals and that's no bug. internally the VM is not allowed to access the symbol table as that would allow for yet more fragile macros
22:49:57Araq_pwernersbach: outch.
22:55:35filwitAraq_: okay, i see... so there's really no convenient way (besides the method I just mentioned above) to build a macro which gets all the overloads of a specific symbol from some other module? Just trying to pick your brain on this a little since you know the macros abilities back-to-front.
22:55:56*junw_ quit (Ping timeout: 250 seconds)
22:56:01pwernersbachAraq_: Here's the error: https://gist.github.com/philip-wernersbach/0c34a34d641544d30bb0
22:56:05pwernersbachCode error or compiler bug?
22:57:17filwitAraq_: it's not really a problem for me, I can go about this in a different way. Just wondering if I'm missing something about how to use bindSym.. it seems odd that it can only work with string lits, thereby limiting it to only getting overloads of symbols within the module the macro is defined in.
23:02:01*yglukhov_ joined #nim
23:02:01*yglukhov quit (Read error: Connection reset by peer)
23:04:20*yglukhov_ quit (Read error: Connection reset by peer)
23:04:43*yglukhov joined #nim
23:06:50*yglukhov quit (Read error: Connection reset by peer)
23:07:09*yglukhov joined #nim
23:08:51dom96Good news guys! I can finally reveal my secret project. Nim in Action, and it just launched on Manning's Early Access Program https://www.manning.com/books/nim-in-action
23:09:05*aziz quit (Remote host closed the connection)
23:12:11*yglukhov quit (Read error: Connection reset by peer)
23:16:52filwithey dom96: very cool! congrats. Will look into getting it sometime soon :)
23:17:13*yglukhov joined #nim
23:18:03filwitdom96: also, great cover pic, haha. Is that a picture of Nimrod?
23:19:39dom96filwit: Thanks! :)
23:19:45dom96filwit: I don't think that's a picture of Nimrod, no hehe
23:20:33Araq_dom96: awesome work, but not surprising for me :P
23:21:07dom96Araq_: hehe indeed
23:40:00pwernersbachGood job dom96! It'll be awesome to have a Nim book
23:51:41*Matthias247 quit (Read error: Connection reset by peer)
23:53:58Araq_pwernersbach: your types look a bit fishy
23:55:34dom96pwernersbach: Thank you! I completely agree, cannot wait to finish the book and get my hands on a printed version :)