<< 20-12-2018 >>
00:30:13*fthe quit (Ping timeout: 250 seconds)
00:44:42*zachk quit (Quit: Leaving)
00:54:52*kapil____ joined #nim
00:58:47FromDiscord_<exelotl> Hey I have a question
00:59:35FromDiscord_<exelotl> if you are writing nim for a platform with limited resources, with the garbage collector turned off
01:00:16FromDiscord_<exelotl> and you import some modules like JSON, maybe something heavy like an image processing module
01:01:20FromDiscord_<exelotl> but you only use those modules at compile-time, to generate data arrays for your main program to use
01:02:15FromDiscord_<exelotl> will those modules find their way into the compiled executeable?
01:22:15*krux02 quit (Remote host closed the connection)
01:36:29FromDiscord_<exelotl> Basically I want to use the full power of Nim for code that should execute at compile time, but only a limited subset of Nim for code that should execute at runtime.
01:38:13FromGitter<zacharycarter> I think as long as you don't refer to anything that relies on the GC at runtime
01:38:27FromGitter<zacharycarter> so no seqs, no strings, no refs and no std stuff that relies on the GC
01:38:32FromGitter<zacharycarter> you should be okay
01:38:38FromGitter<zacharycarter> but don't take my word on it - I've never tried to do ^
01:39:00FromGitter<zacharycarter> maybe try a small test?
01:39:10FromGitter<zacharycarter> using the json example you described
01:39:38FromDiscord_<exelotl> yeah I'll have to test for sure. What you descibed is what I'm hoping for x)
01:40:01FromDiscord_<exelotl> but now now, it's 2:40 am and I need to slep
01:40:31FromGitter<zacharycarter> :) have a good night!
01:40:53FromDiscord_<exelotl> lmao did I just write now now
01:40:59FromDiscord_<exelotl> I meant to write 'for now'
01:41:07FromGitter<zacharycarter> I think you need sleep :P
01:41:19FromDiscord_<exelotl> yes xD
02:01:52*rockcavera joined #nim
02:28:01FromGitter<gogolxdong> How to check an object is no nil?
02:39:30FromGitter<gogolxdong> `stdlib_nativesockets.c:(.text+0xe58): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking`
03:08:51*banc quit (Quit: Bye)
03:17:05*rockcavera quit (Remote host closed the connection)
03:19:12*Tyresc quit (Quit: WeeChat 2.3-dev)
03:22:39*rockcavera joined #nim
03:23:51FromGitter<gogolxdong> How do I specify nim building with static library?
03:24:34*banc joined #nim
03:44:04leorizepass `-Bstatic` to the link flags
04:09:31*endragor joined #nim
04:12:07FromGitter<gogolxdong> cool
04:12:11FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c1b169b416379024158cc62]
04:12:58FromGitter<gogolxdong> `var host: ptr ptr libssh2_knownhost` as the comparable C **libssh2_knownhost
04:14:44FromGitter<gogolxdong> nim c -r -d:release --hints:off -Bstatic scp.nim
04:14:48FromGitter<gogolxdong> like this
04:14:56FromGitter<gogolxdong> ?
04:22:56FromGitter<gogolxdong> nim c -r -d:release --hints:off --passC:-Bstatic scp.nim ?
04:24:12FromGitter<gogolxdong> ```code paste, see link```
04:34:17FromGitter<gogolxdong> I think nim build it in static by default according to the error msg ` -lm -lrt -lssh2 -lgcrypt -lgpg-error -static -ldl`
04:34:40*lritter joined #nim
04:40:15*lritter quit (Ping timeout: 250 seconds)
04:41:07*lritter joined #nim
05:00:20leorizegogolxdong: use --passL:'-Bstatic'
05:00:55*nsf joined #nim
05:10:44FromGitter<AchalaSB> What is message represent? ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ It is showing me operation success but it is not displying my output [https://gitter.im/nim-lang/Nim?at=5c1b2453dab2222ab3c106eb]
05:12:58*kapil____ quit (Quit: Connection closed for inactivity)
05:13:41FromGitter<AchalaSB> here's my simple code
05:15:44FromGitter<AchalaSB> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c1b258041637902415923ef]
05:20:57*dddddd quit (Remote host closed the connection)
05:22:51FromGitter<gogolxdong> @leorize what's the difference between -static and -Bstatic `-lm -lrt -lssh2 -lgcrypt -lgpg-error -static -Bstatic -ldl`
05:24:32leorizeit depends
05:24:47leorizemost gcc will map it directly to -Bstatic, but they might choose not to
05:25:02leorizewhile -Bstatic will almost always be passed to the linker
05:29:58FromDiscord_<JGiraffe> I think I understand that any language can be used in DOP because it's about the efficiency of the processes and their associated hardware. Is that right?
05:30:35FromDiscord_<JGiraffe> I want to make my game using DOP if possible
05:31:01FromDiscord_<JGiraffe> Also Nim
05:44:24*d10n-work quit (Quit: Connection closed for inactivity)
05:53:02*lritter quit (Ping timeout: 268 seconds)
05:55:07*narimiran joined #nim
06:07:05leorize@AchalaSB: because your sample code isn't called anywhere?
06:10:53*m712 quit (Ping timeout: 245 seconds)
06:15:51*m712 joined #nim
06:25:22*plushie quit (Quit: plushie)
07:13:10*kapil____ joined #nim
07:25:53*crem quit (Ping timeout: 245 seconds)
07:32:30*nif joined #nim
07:33:24*crem joined #nim
07:44:56AraqZevv, just report it
08:07:28*crem quit (Read error: Connection reset by peer)
08:07:48*crem joined #nim
08:08:02*crem quit (Read error: Connection reset by peer)
08:08:25*crem joined #nim
08:36:10*narimiran quit (Remote host closed the connection)
08:38:06FromGitter<mratsim> When passing C++ to c2nim, std::string becomes string, on the C++ target Nim string are using C++ std::string?
08:43:10*narimiran joined #nim
08:49:58leorizeI don't think so?
08:56:33FromGitter<mratsim> ah I know, when c2nim sees foo::something, it automatically strips foo
08:56:43FromGitter<mratsim> this is a coincidence
08:59:15*krux02 joined #nim
09:03:38*narimiran quit (Remote host closed the connection)
09:05:00*narimiran joined #nim
09:06:24Araqexactly
09:06:29*floppydh joined #nim
09:12:21FromGitter<alehander42> @AchalaSB are you sure you want to echo what you GET from a png? what do you want to actually test
09:12:44FromGitter<alehander42> otherwise yeah, make sure you call those
09:34:44*regtools left #nim (#nim)
09:34:59*regtools joined #nim
09:47:05*stefanos82 joined #nim
09:49:09*whaletechho quit (Quit: ha det bra)
10:25:25*theelous3 joined #nim
10:27:02*ftsf joined #nim
10:42:08*kaliy quit (Ping timeout: 245 seconds)
10:42:44*kaliy joined #nim
11:04:27*theelous3 quit (Ping timeout: 268 seconds)
11:07:30ftsfhttps://github.com/nim-lang/Nim/blob/master/lib/pure/collections/heapqueue.nim this claims to be a priority queue, but how would you change the priority for an element?
11:09:13*theelous3 joined #nim
11:14:51dom96I think you can implement a priority queue on top of it, see here: https://docs.python.org/2/library/heapq.html#priority-queue-implementation-notes
11:15:39ftsfahh, thanks dom96 !
11:18:01*Cthalupa quit (Ping timeout: 268 seconds)
11:19:56*Cthalupa joined #nim
11:34:47*theelous3 quit (Ping timeout: 240 seconds)
11:43:59*PMunch joined #nim
11:44:13ftsfhmm, I guess I need a way to tell it how to compare elements as well
11:58:36*theelous3 joined #nim
11:59:15ftsfcool, just defined `<` for my element type, easy =)
12:17:41*Vladar joined #nim
12:49:43*Vladar quit (Remote host closed the connection)
13:10:32*fthe joined #nim
13:29:52*fthe quit (Ping timeout: 246 seconds)
13:38:10*Snircle joined #nim
13:41:44PrimHelioswhat's the purpose of enclosing proc names in backticks, does that just specify an infix?
13:42:01narimiranyes
13:42:32PrimHelioscool, thanks :)
13:44:18*Vladar joined #nim
13:44:50*dddddd joined #nim
13:46:37*kungtotte quit (Remote host closed the connection)
13:47:19*whaletechho joined #nim
13:48:59FromGitter<alehander42> sometimes they do, sometimes they specify that it is a reserved name
13:49:34FromGitter<alehander42> e.g. you can have a `ref`
13:49:35FromGitter<alehander42> proc
13:50:03FromGitter<alehander42> it's similar with variables : you can use e.g. keywords as variable names if you have ` `
13:50:08FromGitter<alehander42> "`"
13:50:50narimiranoh, i didn't think of that, and the other day i needed to have `addr`, which i disguised as `adrr`
13:51:35FromGitter<alehander42> no problem, I use them from time to time, but I feel they might be not very good style, not sure
13:52:14PrimHeliosthat's interesting, thanks guys
13:56:51*endragor quit (Remote host closed the connection)
13:57:19*endragor joined #nim
13:57:30*Cthalupa quit (Ping timeout: 244 seconds)
13:58:10*Cthalupa joined #nim
13:59:10FromGitter<arnetheduck> Araq, if you're working on the `AST`, it would also be nice to clean up the remaining stmt/expression overlap.. for example, there's `ifexpr` and `ifstmt` but only `casestmt` and `trystmt` even though both of those can be expressions.. also, I've noticed that some transformations and macros don't set the `typ` on `casestmt` and `trystmt`- would be nice if one could depend on nodes in an expression context always
13:59:10FromGitter... having a type - basically that would mean that some part sem should reject macros that generate invalid ast's like that
14:01:34*endragor_ joined #nim
14:02:03*endragor quit (Ping timeout: 268 seconds)
14:05:46*endragor_ quit (Ping timeout: 244 seconds)
14:39:37*ftsf quit (Remote host closed the connection)
14:40:01*ftsf joined #nim
14:41:55*d10n-work joined #nim
14:43:43*theelous3 quit (Ping timeout: 246 seconds)
15:32:12*PMunch quit (Remote host closed the connection)
15:41:56*xet7 quit (Remote host closed the connection)
15:52:55*nsf quit (Quit: WeeChat 2.3)
15:56:19Araqarnetheduck: macros in general don't set n.typ at all
15:56:47Araqsem'check is responsible for this and every AST coming from a macro is sem'checked
15:57:42Araqmaybe there are issues here indeed but the macro system has no concept of n.typ, but there is getType() for type inspection, not for setting of a type
16:00:37Araqunification of nkIfExpr and nkIfStmt is problematic for karax but I'll think about it further
16:00:40FromGitter<arnetheduck> ok, because I get lots of those trystmts and casestmts without it, arriving to `nlvm` which is structured a little different than the cgen (it uses the typ more heavily to make type decisions.. might be only transformations then, there's a lot going on in those cases and I haven't been able to pin it down exactly - I suspect `defer` as one, and possibly some templates or maybe some specific macros, but is guesswork
16:02:17Araqcompile with --define:useNodeIds and echo n.id and then use the ID in ast.nim
16:02:35Araqconst nodeIdToDebug
16:02:43Araqthen it prints where the nodes comes from
16:03:05Araqno guesswork, Nim has a poor man's "go back in time" debugger
16:03:15Araqwith its ID mechanism
16:03:30Araq(Just saying this in case you didn't know already)
16:04:14*Vladar quit (Remote host closed the connection)
16:04:16FromGitter<arnetheduck> I didn't - I try to stay out of the non-backend parts, confused enough as-is :)
16:06:29*Tyresc joined #nim
16:06:49FromGitter<arnetheduck> another case I suspect is when the last statement is something like `quit` that doesn't return.. for example `try: if xxx: a else: quit`
16:07:25FromGitter<arnetheduck> stuff like that messes with the assumption that the last node in the list is the one that gives the typ
16:08:06Araqwell the typing rules for these are underspecified, but the implementation is quite stable. And the type is always in n.typ
16:08:23FromGitter<arnetheduck> in the cgen, it's kind of handled because you pass in the target tloc and hope it'll be set correctly.. nlvm tries to follow the ast more closesly
16:09:11FromGitter<arnetheduck> well, that's good news at least - that basically means you'd consider any such try node without typ a bug?
16:10:00FromGitter<arnetheduck> in the cgen btw, that might cause issues as well, I think it tries to use the typ for data flow analysis and simply ignores that part if typ is not set..
16:12:15Araqa try node with n.typ == nil is the same as the tyVoid type, it doesn't produce a value
16:12:29Araqif this rule is violated, it's a bug.
16:13:24FromGitter<arnetheduck> generally speaking, it would actually be nice if n.typ was always set to tyVoid if it doesn't produce a value - just to avoid the nil check ;)
16:13:33Araqyup
16:13:39Araqtotally agree
16:14:01Araqwhile we're at it ... what's the point of the renamefest again?
16:14:13Araqwhy does 'genIf' bite with anything?
16:16:41FromGitter<xmonader> guys, what is good/idiomatic approach to achieve pluggable applications in nim? something like go plugin
16:17:26FromGitter<arnetheduck> the point is to have a unique prefix for anything that handles ast nodes, so as to differentiate it from helpers/utilities/common code/rtti stuff etc.. simply because a lot of these names are taken for random purposes, so it's nice and easy to have a "rule" to quickly look up direct ast handlers as a "category" of code, and ast handlers only (same for magics).. if ever you want to turn it into a macro, it'll be the
16:17:26FromGitter... same thing
16:20:31Araqxmonader: there are few ways of killing your productivity in programming. A plugin system is one of them.
16:21:04FromGitter<arnetheduck> basically, it consistently saves jumping around when looking up the code, and narrows down the search results to something manageable.. I know it's not perfect for some names, but it's a small cost compared to the convenience gained from the regular naming / categorization
16:21:18AraqAPI design is hard, plugin design is harder and in the end you give your users a shitty microcosmos of half-baked features
16:22:03Araqnow that I warned you, there are 3 different ways:
16:22:06Araq- DLLs
16:22:10Araq- execProcess
16:22:12FromGitter<arnetheduck> the `vscode` devs would disagree with that :)
16:22:13Araq- NimScript
16:22:50Araqarnetheduck: most projects die before they become the next vscode
16:22:58ZevvAraq: its not that I don't agree, but what is the source of your plugin aversion?
16:23:07*OrganicAnywhere joined #nim
16:23:19FromGitter<xmonader> @Araq can you elaborate?
16:23:28FromGitter<arnetheduck> @Araq, not necessarily because they introduce a plugin system
16:24:08FromGitter<xmonader> in go they create .so and load that in runtime, not sure if that's the best with the expressivity and all magic nim has .. but that doable
16:24:20*OrganicAnywhere left #nim (#nim)
16:24:33Araqwell people claim DLLs are broken but I got nothing to reproduce the problem
16:24:45Araqthe tests cover them, including the GC aspect
16:25:05FromGitter<xmonader> for instance i'm trying to develop something like ansible but in nim where users can write their own modules and autoload it in the controller
16:25:17*Trustable joined #nim
16:25:18FromGitter<xmonader> maybe there's a better approach, but not sure
16:25:28FromGitter<arnetheduck> dll's are easy to break on your own and then blame the language or environment.. lots of hard constraints on resources and memory usage, as well as platform differences
16:25:41Araqgive them a Nim library and a Nim program.
16:26:00Araqhint: giving them a library is already the "API design" problem
16:26:30FromGitter<xmonader> yeah, but how then i make the app aware of there plugins?
16:26:51*OrganicAnywhere joined #nim
16:26:55*OrganicAnywhere left #nim (#nim)
16:27:00Araqyou ship Nim with it and recompile :-)
16:27:34AraqI dunno, depends on your use case. Usually it's better to get the basics right, good defaults etc and skip this whole "it must extensible" madness
16:27:53Araqand that's coming from me, somebody who loves macros. :P
16:28:01FromGitter<xmonader> that's not ideal, and for users who will be using it they would care only about having the plugins and the app not recompiling the whole thing
16:28:21FromGitter<xmonader> Hahahahaha yeah I couldn't believe you're the one saying so :P
16:28:32Araqif your users notice the recompile step maybe you need to hide it better
16:28:34Zevvxmonader: I needed something similar and ended up with fork/exec and RPC. Crude but works for me
16:28:57*OrganicAnywhere joined #nim
16:29:17Araqfwiw I need to restart vscode occasionally and wouldn't mind to have to do that for plugin installations
16:29:29FromGitter<xmonader> @Araq I see, maybe i'm just too used to the Go way that I don't think out of the box
16:29:32AraqI rarely install plugins anyway, would be a tiny inconvenience
16:29:32FromGitter<arnetheduck> @Araq - while on the subject of AST, another difficulty I've encountered is inconsistent n.typ across related nodes (assignments, or parent/son relations), specially for integers - this works for the cgen because it liberally sprinkles `NI` and other casts everywhere, but it would be nice if these were limited to the nodes that "should" take care of such stuff (nkCast, nkHiddenConv or whatever they're called)
16:29:46FromGitter<xmonader> @Zevv How did you manage the service discovery ?
16:29:53Zevvreaddir :)
16:30:12Zevvplugin discovery, if that is waht you mean
16:30:25FromGitter<xmonader> ah sorry yes
16:30:57Zevvbasically, I made a small lib that manages RPC on the plugin side, which all plugins import
16:31:14Araqarnetheduck: but genIfStmt and genAddI can't conflict, the AST has Stmt/Section suffixes, the magics don't
16:31:18FromGitter<xmonader> @Zevv can you share the link? if it's opensource
16:31:55Zevvits corporate stuff for now, but I can see if I can take some of it out
16:32:18FromGitter<xmonader> thank you I'll tinker a bit in the meanwhile :)
16:32:40FromGitter<xmonader> @Araq also while I'm on a vacation what compilers book do you recommend? mainly for the code generation and backend phase?
16:33:13Zevvit is pretty trivial. the RPC uses msgpack4nim for serialization, and both sides export RPC methods for the other to call
16:33:38Araq"Modern compiler construction in ML/C/Java" is good, the book about LCC is good
16:33:56AraqWirth's books are good if you know what to ignore
16:34:22Araqthe dragon book --- sorry, skip that one.
16:34:46FromGitter<xmonader> @Zevv thanks a lot :) I'll give it a shot to see how it fits together
16:35:00FromGitter<xmonader> @Araq Ah i'm pretty familiar with ML i'll give that one a shot thank you
16:35:12ZevvAraq: what would you recoomend concerning the multimethod/generic issue I ran into. Just drop using methods altoghether?
16:35:14FromGitter<xmonader> Maybe you give us AMA on reddit I sure have loads of questions :D
16:35:38Zevvor is there some robust way to work around the issue
16:35:42Araqmost books don't cover code generation well
16:35:57AraqLCC does though, ymmv, it's a bit dated
16:36:33Araqand source-to-source compilers are not handled anywhere really.
16:36:41FromGitter<xmonader> it'd be hella interesting if you write us a modern one with the state of the art on the subject
16:36:50Zevvyou should write a book about it :)
16:36:57Zevvhehe
16:37:19FromGitter<xmonader> Listen to the People @Araq and do it :D
16:37:33FromDiscord_<hotdog> Has anyone got an example of the `.()` operator in use?
16:37:36Araqit's not the first time I hear this, thank you
16:37:53Araqwill do it after v1 is out.
16:38:25Araq(yeah, yeah, I know, I know)
16:42:44FromGitter<arnetheduck> they can't, true, but they're different concepts with different behavior.. the present real conflicts are mainly with "other random stuff", not between ast and magic.. the important part though is that this is about ergonomics and about dividing the code up into conceptual pieces that follow the concepts you have in the language - it's a help when navigating the code because you can look at the ast and immediately
16:42:44FromGitter... find the corresponding section of code in the cgen, sem or whatever.. for you, it's less of any issue having written the code, but for outsiders that want to understand it, this kind of categorization helps limit the surface area of stuff you have to look at to meaningfully progress.. ie if I'm learning about magic ... [https://gitter.im/nim-lang/Nim?at=5c1bc6842a66862cc95cfb52]
16:44:22FromDiscord_<hotdog> `.()` is ungoogleable
16:45:04Araqarnetheduck: I don't mind changing it for you and others but I think
16:45:33AraqgenXStmt vs genMagic vs generateStuff will work out nicely
16:46:04Araqgen$Stmt vs gen$Magic vs generate$Stuff will work out nicely (introduced $ in the hope it makes the patterns clearer)
16:46:26Araqso I'd rather rename expr() to generateExpr()
16:46:32Araqif that's what it is about
16:47:13FromGitter<arnetheduck> ok, what's the handler for `nkBracket` and `nkBracketExpr` going to be called? `genBracketStmt` and `genBracketExprStmt`?
16:47:53AraqgenBracket and genBracketExpr
16:48:12Araqah and then you cannot tell there is no mBracket magic?
16:48:19Araqis that what you're after?
16:48:38FromGitter<arnetheduck> yeah
16:48:43*OrganicAnywhere left #nim ("Opi out.")
16:48:55FromGitter<arnetheduck> and there's also no `tyBracket`
16:49:20Araqhmm but for me that's an unfortunate implementation detail, ideally I would prefer nkAddI over mAddI but it is what it is
16:50:49FromGitter<arnetheduck> well, they're a little bit different though, magics and ast nodes.. the magics being the implementation while the nodes talk more about structure, even if the border is a bit floating
16:51:37Araqmaybe 'gen$Node' vs 'gem$Magic' ?
16:51:50AraqRuby has gems too and everybody loves it :P
16:52:22FromGitter<arnetheduck> so fyi, the way I have it set up is: `genNode` is your `expr` basically - then `genNodeX` is what `genNode` calls.. likewise, there's `genMagic` and `genMagicX`
16:52:44AraqZevv, you can wait for a bugfix but these bugs are like whack-a-mole and want me to throw methods away
16:53:06FromGitter<arnetheduck> `gen$Node` and `gen$Magic` works for sure
16:53:35AraqZevv, originally methods + generics were not supported and the language was better this way.
16:53:36*Jesin quit (Quit: Leaving)
16:54:07FromGitter<arnetheduck> the alternative I see actually is to join ccgexprs and ccgstmts, then move magics into ccgmagics.. that would maybe make more sense, but it's much more invasive as well
16:54:12Araqthey don't mix well, so they were not supported. And then the Araq fool listened to his users and tried to make it work. Story of my life.
16:55:32Zevvok, for now I'll play safe and just avoid methods, as I have no clue at all what you are talking about regarding ccgexprs and ccgstmts.
16:55:45Araqno, my point is
16:55:57Araqgenerics are fine, methods are fine, but don't have generic methods.
16:56:13Zevvthat's what I ment as well, sorry
16:56:16Araqok
16:57:14Araqarnetheduck: the file setup doesn't concern me much, ccgmagics is ok
16:57:48FromGitter<arnetheduck> it's not the kind of change that sits well with other pr authors :)
16:58:04AraqI don't like long-winded *Node* and *Magic* in the names though, hence my suggestion to use 'gen' vs 'gem'
17:01:10FromGitter<arnetheduck> well, that works as well, as long as the other `gen`'s are renamed to something else (`genTypeDesc` etc) and friends
17:02:06Araqor how about this:
17:02:33Araqnode$NodeKind vs magic$Magic and skip the gen(erate) verb
17:02:45FromGitter<arnetheduck> works
17:02:45Araqit's a codegen, what else would it do
17:03:09Araqusually throwing away the verb is bad style but I think in this case it's good enough
17:03:51FromGitter<arnetheduck> I also thought about `on` and `magic`: `onBracket` and `magicAddI`
17:05:11AraqI only use 'on' for callbacks / events
17:07:12FromGitter<arnetheduck> or.. dunno if it works, but I can easily produce such a branch and we can try it on :)
17:17:07*banc quit (Ping timeout: 240 seconds)
17:17:14*Jesin joined #nim
17:17:39Araqyeah ok, will try to do it tonight
17:20:29*banc joined #nim
17:20:33bozaloshtshit doesn't make sense to use not nil as a type in a generic parameter right?
17:20:54bozaloshtshso not nil can't really be thought of as a type constructor in the same way generics can be
17:30:00*nsf joined #nim
17:57:56*narimiran quit (Ping timeout: 272 seconds)
17:59:20*plushie joined #nim
18:14:00*kinkinkijkin quit (Quit: Leaving)
18:15:23*Subspice joined #nim
18:21:40*Subspice left #nim ("Opi out.")
18:22:18*OrganicAnywhere joined #nim
18:31:46FromGitter<alehander42> Araq, what is the best place to invoke genTypeInfo for all enum types in cgen ?
18:31:56FromGitter<alehander42> (in debug mode)
18:34:48*Pisuke quit (Ping timeout: 250 seconds)
18:37:00*Pisuke joined #nim
18:38:00*OrganicAnywhere quit (Ping timeout: 252 seconds)
18:40:19AraqI dunno, do you use the .ndi files
18:49:25*floppydh quit (Quit: WeeChat 2.3)
18:54:44*Trustable quit (Remote host closed the connection)
19:01:46*theelous3__ joined #nim
19:02:23*kinkinkijkin joined #nim
19:02:24*natrys joined #nim
19:07:57*kinkinkijkin quit (Quit: Leaving)
19:11:46*kinkinkijkin joined #nim
19:14:09*kinkinkijkin quit (Remote host closed the connection)
19:18:26*kinkinkijkin joined #nim
19:23:44*McSoFake joined #nim
19:36:25*nsf quit (Quit: WeeChat 2.3)
19:38:58*kinkinkijkin quit (Quit: Leaving)
19:54:06*kinkinkijkin joined #nim
20:09:35*kinkinkijkin quit (Quit: Leaving)
20:14:33*PMunch joined #nim
20:16:04*kinkinkijkin joined #nim
20:22:19*kinkinkijkin quit (Quit: Leaving)
20:26:59*Sembei joined #nim
20:27:31*Pisuke quit (Ping timeout: 250 seconds)
20:40:07FromGitter<timotheecour> hi @araq https://github.com/nim-lang/Nim/pull/9766 is finally green
20:48:42*natrys quit (Quit: natrys)
20:49:13*vegax87 quit (Changing host)
20:49:13*vegax87 joined #nim
20:49:13*vegax87 quit (Changing host)
20:49:13*vegax87 joined #nim
20:55:43*kungtotte joined #nim
20:56:05*kungtotte quit (Client Quit)
21:22:04*deech joined #nim
21:22:31deech Araq: Any feedback on https://github.com/nim-lang/Nim/pull/10001 and https://github.com/nim-lang/Nim/pull/9934?
21:24:34*deech left #nim (#nim)
21:24:46*deech joined #nim
21:43:47*ftsf quit (Ping timeout: 240 seconds)
22:05:38*kinkinkijkin joined #nim
22:22:04*kapil____ quit (Quit: Connection closed for inactivity)
22:25:00*stefanos82 quit (Remote host closed the connection)
22:53:42XeSo I have a question for you guys: how can we use kafka the most effectively from our applications? Is there
22:53:44Xeno
22:53:46Xewhat would you all suggest for doing recursive descent parsing in nim?
22:54:58*mr_yogurt joined #nim
22:56:04*PMunch quit (Remote host closed the connection)
22:56:13FromGitter<zacharycarter> Xe: I replied to you in nim-offtopic
22:56:17FromGitter<zacharycarter> re: recursive descent parsing
22:56:28FromGitter<zacharycarter> I'm not sure if there are Nim bindings to apache kafka
22:56:48FromGitter<zacharycarter> if there are - I don't think there'd be any special way of using it in Nim vs using it in any other language
22:56:49Xeyeah the former was a kill buffer misfire
22:56:51FromGitter<zacharycarter> minus the bindings
22:56:53Xeignore it please
22:57:00FromGitter<zacharycarter> :) np
22:59:06*kinkinkijkin quit (Read error: Connection reset by peer)
22:59:11Araqtimotheecour, yay, more compiler flags
22:59:31Araqwhat about --excessiveStackTraces:on|off? that thing already exists
23:03:00*kinkinkijkin joined #nim
23:14:15*Tyresc quit (Quit: WeeChat 2.3-dev)
23:14:37*Tyresc joined #nim
23:15:44*xet7 joined #nim
23:17:27*zachk joined #nim
23:18:23*zachk quit (Read error: Connection reset by peer)
23:18:49*zachk joined #nim
23:19:34*zachk quit (Max SendQ exceeded)
23:20:09*zachk joined #nim
23:31:26*Sentreen quit (Quit: WeeChat 1.6)
23:33:22*xet7 quit (Quit: Leaving)
23:33:57*zachk quit (Changing host)
23:33:57*zachk joined #nim
23:49:16FromGitter<timotheecour> happy to reusing existing ones and extending their meaning if u prefer
23:49:28Araqalways.
23:49:44Araqthink about it this way: Why would bugfixes require new compiler switches?