00:00:05*lf-araujo_ joined #nim
00:01:32*lf-araujo quit (Ping timeout: 272 seconds)
00:01:33*lf-araujo_ is now known as lf-araujo
00:05:30*krux02_ quit (Remote host closed the connection)
00:23:28*dddddd quit (Ping timeout: 268 seconds)
00:27:28*kuon quit (Remote host closed the connection)
00:27:51*kuon joined #nim
00:32:13*stefanos82 quit (Quit: Quitting for now...)
00:36:52*dddddd joined #nim
00:42:44*kuon__ joined #nim
00:43:47*kuon quit (Ping timeout: 245 seconds)
00:49:15*theelous3 quit (Ping timeout: 244 seconds)
00:57:38*lf-araujo quit (Quit: lf-araujo)
00:57:46*lf-araujo joined #nim
01:05:12*squattingmonk joined #nim
01:17:11squattingmonkHowdy, all. Is there a simple way to get the differences between two Times in seconds?
01:43:37*lf-araujo quit (Ping timeout: 250 seconds)
02:00:37*theelous3 joined #nim
02:04:23FromGitter<zetashift> subtract using https://nim-lang.org/docs/times.html#-%2CTime%2CDuration and then pass the resulting Duration to `inSeconds` https://nim-lang.org/docs/times.html#inSeconds%2CDuration ?
02:05:28*theelous3 quit (Ping timeout: 245 seconds)
02:14:12*dwdv quit (Ping timeout: 245 seconds)
02:15:01*vlad1777d quit (Ping timeout: 244 seconds)
02:18:25*jest joined #nim
02:35:07*actuallybatman joined #nim
02:37:44*actuallybatman is now known as MikeSS
02:38:50*MikeSS is now known as actuallybatman
02:46:04*laaron- joined #nim
02:47:03*laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
02:50:42squattingmonkI wanted to do comething like that, but you can't use - with two Times, only a Time and a Duration.
02:50:42*chun joined #nim
02:50:57squattingmonkI unded up sing toUnix() on both, then subtracting.
02:51:02*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
02:51:07squattingmonk*ended up using
02:53:32squattingmonkWait, yes you can.
02:56:47FromGitter<ratiotile> c2nim currently translates `const` to `var`. Would it be better to make it `let`?
02:58:21squattingmonkThanks, zeta. I missed that.
03:05:25*chun_ joined #nim
03:06:31*chun__ joined #nim
03:06:45*chun__ quit (Client Quit)
03:09:15*chun quit (Remote host closed the connection)
03:10:28*chun_ quit (Ping timeout: 245 seconds)
03:24:01*lritter quit (Ping timeout: 246 seconds)
03:25:03*lritter joined #nim
03:44:17*fjellfras joined #nim
03:45:38*lritter quit (Ping timeout: 258 seconds)
03:50:55*nimNoob joined #nim
04:14:05FromGitter<zacharycarter> all of a sudden, on 0.2.0, I'm getting this error every time I start up my application- ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d26b78d0c8c4114d90c0657]
04:14:08FromGitter<zacharycarter> and I have no idea why
04:17:42FromGitter<zacharycarter> debugging provides me with nothing - because the program crashes before the entry point is reached
04:18:52nimNoobhola is there a channel specifically for beginners?
04:19:54FromGitter<zacharycarter> this one :)
04:19:57FromGitter<zacharycarter> fire away
04:21:47nimNoob I am new to programming and I bought Nim in Action. In " Chapter 7. Building a Twitter clone" nimble asks me what package type I should choose. Should I choose bin ? would it break if I chose anything else ?
04:22:45FromGitter<zacharycarter> bin = binary, like creating an executable that you can run, so like on windows - app.exe or on linux macos an (well they don't have extensions for apps do they?)
04:23:10FromGitter<zacharycarter> lib = a Nim library that you can then use in other Nim projects, or potentially a static / dynamically linked library if you want to go down that route
04:23:43FromGitter<zacharycarter> let me take a look at the twitter clone code and I can let you know what you should pick - I'm not sure how it's supposed to be built
04:24:37FromGitter<zacharycarter> you want to choose bin
04:24:43nimNoobah ty
04:24:46FromGitter<zacharycarter> no problem
04:24:58*nimNoob quit (Remote host closed the connection)
04:25:14*fjellfras quit (Remote host closed the connection)
04:25:34*fjellfras joined #nim
04:29:37*squattingmonk quit (Quit: WeeChat 2.5)
04:30:52*nimNoob joined #nim
04:35:37*nimNoob quit (Remote host closed the connection)
04:37:03*nsf joined #nim
04:37:19FromGitter<zacharycarter> I was being stupid and closing a stream
04:42:29FromGitter<zacharycarter> okay - I seem to get that error when I read from the stream, assign a value to a sequence that is read from the stream, close the stream, and try to echo the sequence
04:42:33FromGitter<zacharycarter> why though...
04:45:10*nimNoob joined #nim
04:45:40nimNoobty dom I got the answer from chat. your book is amazing!
05:04:47FromGitter<zacharycarter> Well the stream seems like a red herring. I have absolutely no idea what is causing this error. I'm starting to lean towards thinking it has something to do with my usage of options...
05:07:34*dddddd quit (Remote host closed the connection)
05:09:51*laaron- quit (Remote host closed the connection)
05:10:16*laaron joined #nim
05:15:58*narimiran joined #nim
05:24:17ZevvAraq: got some context about that npeg thing??
05:26:20*nimNoob quit (Remote host closed the connection)
05:31:25*jest quit (Ping timeout: 246 seconds)
05:39:37*lf-araujo joined #nim
05:43:38*lf-araujo quit (Remote host closed the connection)
05:51:20*absolutejam joined #nim
06:15:53*solitudesf joined #nim
06:27:12*PMunch joined #nim
06:39:33*absolutejam quit (Ping timeout: 244 seconds)
06:47:07*eterps joined #nim
06:53:30*Vladar joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:01:04*krux02 joined #nim
07:04:32*gmpreussner joined #nim
07:33:12PMunchHmm, trying to run parseSql on compile-time yields an intVal is not accessible error
07:33:27PMunchOr more specifically http://ix.io/1N8C
07:35:10*absolutejam joined #nim
07:38:04PMunchTried with 0.19.6, which gave me a different error: ../../home/peter/.choosenim/toolchains/nim-0.19.6/lib/pure/lexbase.nim(156, 13) Error: VM is only allowed to 'cast' between integers of same size
07:38:10*stefanos82 joined #nim
07:39:38PMunchHmm, is there a way to check if you are in the VM?
07:45:11*krux02 quit (Remote host closed the connection)
07:45:23*krux02 joined #nim
07:47:08PMunchOkay, I found `nimvm`
07:47:15PMunchBut it's the most finnicky thing I've seen
07:56:17PMunchEnded up doing this just to be able to use it: http://ix.io/1N8H/nim
08:00:27PMunchUhm, this assertion fails http://ix.io/1N8J/nim
08:01:27PMunchTrying to modify lexbase to also run on compile-time
08:03:49Araqhuh, it was patched to work at compile-time, krux02 ?
08:04:19PMunchHmm, then it might be something else that trips up
08:04:37PMunchI went back to 0.19.6 since I got the intVal is not accesible error
08:05:05PMunchYeah, I can see that lexbase in 0.20.0 is patched
08:05:24*solitudesf quit (Ping timeout: 272 seconds)
08:07:05krux02PMunch: I don't understand the problem
08:07:15krux02what do you try to do with `nimvm`?
08:07:49krux02nimvm is a Schrödinger's constant that is both true and false at the same time.
08:08:15PMunchI was just trying to patch lexbase
08:08:20PMunchBut I see that is already done
08:08:28PMunchThat is my actual issue
08:08:45PMunchWhen I try to compile it I get the error: http://ix.io/1N8C
08:09:46krux02interesting: http://ix.io/1N8M
08:10:19krux02Araq: I have a path from your computer in there on my computer ^
08:10:43Araqyou should be thankful for that
08:10:46PMunchYeah, I think that's a known issue that has been fixed in devel already
08:10:53Araq^ yup
08:11:53PMunchFull error with a debug compiler
08:13:58*arecaceae quit (Remote host closed the connection)
08:14:17*arecaceae joined #nim
08:20:11krux02I can reproduce the problem now
08:20:25krux02I went in it with a debugger, but I don't understand it
08:20:46krux02The important part of the stacktrace is missing/incorrect
08:22:35ZevvAraq: can you elaborate on your npeg const problem? I'd like to fix but I don't know what your problem is
08:24:25PMunchYeah the line numbers in that stack trace doesn't make much sense..
08:25:40*actuallybatman quit (Ping timeout: 272 seconds)
08:26:31FromGitter<zacharycarter> how can I trouble shoot an issue that happens before any of my code executes? This error seems to be thrown as soon as my executable starts - ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d26f2b7f867ec1687eaee93]
08:33:26PMunchHmm, on devel I get another error krux02
08:33:36PMunchError: index 140609990366264 not in 0 .. 8191
08:33:58krux02I could reproduce that problem as well
08:34:09PMunchThat seems related to the strange L.bufLen = bufLen; assert(L.bufLen == bufLen) error
08:34:16PMunchThat assert fails..
08:35:04*floppydh joined #nim
08:35:24PMunchAh wait, but that isn't there in the refactor
08:36:20PMunchBut L.bufpos = 0; assert(L.bufpos == 0) now fails..
08:36:51PMunchIf you insert the assert at line 139 of lexbase
08:52:16*eterps quit (Ping timeout: 252 seconds)
08:54:03FromGitter<kayabaNerve> Anyone here have a bit to help me debug a mystery?
08:55:55Zevvjust ask
08:56:36FromGitter<kayabaNerve> Alrighty then
08:57:19FromGitter<kayabaNerve> I have two macros in place here. One is a custom case statement macro to handle sub-types and one is one for the errors systems.
08:58:43FromGitter<kayabaNerve> The error system macro (well, effect system, but that's not directly accessible...) creates a copy of the function, embeds it, and guarantees the function only raises what it explicitly raises.
08:59:29FromGitter<kayabaNerve> The case statement works with my object hierarchy which goes A -> B -> SB, yet A also goes to C which goes to CB, and so on.
08:59:59FromGitter<kayabaNerve> ```case a: ⏎ of B as b: ⏎ #B is usable.``` [https://gitter.im/nim-lang/Nim?at=5d26fa8f270d2b1bfa789405]
09:01:05FromGitter<kayabaNerve> The following function compiles with both macros.
09:01:08FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d26fad472d4092b1ac21702]
09:01:44FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d26faf70c8daa1686c46894]
09:01:59FromGitter<kayabaNerve> That second function, from the same file which has had pieces cut out for consistency, doesn't work.
09:02:55FromGitter<kayabaNerve> *SB, not CB
09:03:07FromGitter<kayabaNerve> My theory was because the case statement macro takes A, like the first function, yet the second function takes a typeclass of SA, SB, SC, SD... it failed.
09:03:35FromGitter<kayabaNerve> However editing the case statement macro to take a type class of Element or SignedElement, or casting the SignedElement to an Element, does not fix this code.
09:03:52FromGitter<kayabaNerve> The code does however compile with the discard statement I left in when I submitted this.
09:04:32FromGitter<kayabaNerve> ... yet the case statement above the discard was testing code which also doesn't work. Direct copy of the code from function 1. Ignore that please.
09:05:04FromGitter<kayabaNerve> So I believe it's a bug with Nim, but I don't know how to wrap it up, and more urgently, find a workaround.
09:05:18FromGitter<kayabaNerve> Zevv: I feel like this should've been done in PM :P
09:05:40Zevvwell, usually just asking stuff gets people to respond, but in your case it might be a bit overwhelming
09:06:07ZevvThe usual answer in this case would be: "can you isolate to a minimal example so I can reproduce"
09:06:14Zevvbut I guess that's not trivial here?
09:06:59FromGitter<kayabaNerve> Thankfully, the workaround is easy. Just manually expand to if element of Verification: var verif: Verification = castVerification (element); ...`
09:07:16FromGitter<kayabaNerve> Let me say If I can isolate it to just the typedefs/macros/and macro uses
09:07:19FromGitter<kayabaNerve> 'just'
09:16:39*ng0 joined #nim
09:25:50FromGitter<kayabaNerve> Zevv: I think I did it
09:25:53FromGitter<kayabaNerve> Have a minute?
09:30:09*lf-araujo joined #nim
09:30:38*actuallybatman joined #nim
09:31:43FromGitter<kayabaNerve> The following was compiled on the latest devel with `im c --experimental:caseStmtMacros -r file.nim`: https://gist.github.com/kayabaNerve/169d7d5d5fa3f9d745f31632b0b68946. The first case compiles, yet the second does not. If you edit the match macro to use a typeclass of `A or S`, even though S should match for A, it still doesn't work. If you explicitly cast `s` to `A`, it still doesn't work.
09:32:09FromGitter<kayabaNerve> This looks to be a Nim bug where the only workaround is manual expansion of the macro :thinking: I'd like to know if I'm wrong though before I make an issue :P
09:32:45*fjellfras quit (Quit: Leaving)
09:33:48Zevvdoes the macro expand to what you think it does?
09:37:01Zevvyour snippet does not compile for me: /tmp/t.nim(68, 10) Error: selector must be of an ordinal type, float or string
09:37:24Zevvnim 0.20.99, just pulled
09:37:46FromGitter<kayabaNerve> It's only run once.
09:37:52FromGitter<kayabaNerve> `-experimental:caseStmtMacros`
09:37:57FromGitter<kayabaNerve> *double dash
09:38:50Zevvah right
09:38:52FromGitter<kayabaNerve> So it does expand properly the one time it's run. With a type class, or with the cast, or even with both, it's still only run once.
09:40:51FromGitter<kayabaNerve> It looks like B and SB work fine. Match just can't handle typeclasses.
09:41:13FromGitter<kayabaNerve> Even when there's a type class accepting that type class or the type class is casted to the baser type.
09:41:27FromGitter<kayabaNerve> I'll create the issue...
09:42:40Zevvyeah, it's kind of over my head I must admit
09:42:47Zevvand no one else stepped in here :)
09:43:16AraqI skimmed it, but I don't understand it
09:43:23FromGitter<kayabaNerve> Mr. "just ask" :P
09:43:53Zevvwell, I ment 'just ask, an someone might respond' :)
09:43:59FromGitter<kayabaNerve> If you have a type class of inherited objects, a case statement macro for the parent object fails.
09:44:04FromGitter<kayabaNerve> *fails to match
09:44:34FromGitter<kayabaNerve> Changing the macro's arguments to `Parent or Type class` (type class of a type class) also fails.
09:44:45FromGitter<kayabaNerve> Casting from the type class to the parent type also fails.
09:51:16FromGitter<kayabaNerve> Issue created.
09:52:07*shomodj joined #nim
09:56:13*eterps joined #nim
09:59:36PMunchHmm, there is something seriously wrong with the VM I think.. echo L.bufpos; L.bufpos = 0; echo L.bufpos
09:59:43PMunchThey both echo the same thing..
10:02:51PMunchvar p: SqlParser; echo p.bufpos
10:02:54PMunchThat doesn't echo 0..
10:04:18Zevv!eval import parsesql; var p: SqlParser; echo p.bufpos
10:05:14PMunch!eval import parsesql; static(var p: SqlParser; echo p.bufpos)
10:05:16NimBotCompile failed: /usercode/in.nim(1, 25) Error: expected: ':', but got: '('
10:05:55ZevvI don't know how to do a static in a one liner
10:06:00narimiran!eval import parsesql; static: (var p: SqlParser; echo p.bufpos)
10:06:02NimBotCompile failed: Error: unhandled exception: intVal is not accessible [FieldError]
10:06:21PMunchYeah, there is another weird bug in 0.20.0
10:06:27PMunchBut that's apparently fixed in devel
10:07:22Zevvrunning devel, same error
10:08:00PMunchHmm, maybe it was just my specific version of devel
10:08:03*dwdv joined #nim
10:08:05PMunchWhich probably is a bit dated
10:09:57PMunchYeah, updated my devel version and now I get the intVal error as well
10:10:32PMunchBut the stack trace is just completely bonkers (from the devel compiler without -d:release)
10:11:07ZevvThe IntVal is cuased because the src.knd == rkNode, not rkInt
10:12:16Zevvwhich part is bonkers? It makes sense here?
10:13:31PMunchHmm, what code were you using?
10:13:43Zevvnim devel of just now
10:13:56Zevvand http://paste.ubuntu.com/p/pGWdYxnXn8/
10:14:14PMunchThis is what I'm doing
10:15:15Zevvcompletely bonkers!
10:15:16PMunchAh, you were doing the field test
10:15:50PMunchI mean the line numbers don't match up..
10:16:59Zevvehm, I don't follow - it matches up fine here
10:17:32PMunchvm.nim:219 is the "case x.kind" statement in writeField
10:17:59PMunchBut the error seems to occur on line 221 which is "of rxInt: n.intVal = x.intVal"
10:18:02Zevvah you'd expect it to say line 221 where it actaully access the intVal
10:19:04*miona joined #nim
10:19:35Zevvright, I didn't even notice - I guess it kind of makes sense to point there as the various 'of' branches simply do not exist for the wrong kind
10:19:57PMunchEh, I guess it might..
10:21:07PMunchNo idea what the actual cause of the bug is though..
10:21:37PMunchSomehow it tries to get an int field for something that doesn't have an int field..
10:22:10PMunchBut it's weird that it only happens here
10:25:32Zevvis an object variand and the kind is wrong
10:26:16PMunchYeah I know what fails, but not why
10:27:01*clyybber joined #nim
10:30:45*absolutejam1 joined #nim
10:32:41Araqthe bugs is in 0.19 too, but 0.20 changed the rules for -d:release
10:32:52Araqso more bugs are detected
10:34:04Zevv ah right
10:34:26FromGitter<arnetheduck> yay for behavior-changing compiler flags, software is not complicated enough without them :)
10:35:12*Kaivo quit (Ping timeout: 268 seconds)
10:36:14Araqhuh? -d:release now does *not* change behavior anymore
10:37:18*Kaivo joined #nim
10:38:06*vlad1777d joined #nim
10:40:48PMunchAha, turning on -d:danger for the compiler indeed gives the same behaviour where the number simply isn't set
10:45:13*miona left #nim (#nim)
10:49:44FromGitter<arnetheduck> oh, I think it's excellent that it was changed :) could simplify things further and remove -d:danger too..
10:50:16PMunchWell it's nice to have the option to turn it on
10:50:21FromGitter<arnetheduck> I'm curious though, it looks like the overflow checks are part in std lib code and part in compiler, as if they'd been implemented in either place at some point in time.. any preference?
10:50:32PMunchIf you really need to squeeze performance, or want to fit things on a microcontroller
10:52:30*eterps quit (Ping timeout: 252 seconds)
10:53:59PMunchHmm, and I who thought I would just throw together a small little ORM for fun..
10:54:13PMunchNow I've spent all day looking at strange VM bugs..
10:54:21FromGitter<arnetheduck> well, they significantly alter the control flow of your application.. `catch` takes on a completely different meaning, so you need to do more than just flip a switch - your code-base must be prepared for the change.. meaning that most libraries are off limits because they're not prepped for it etc etc
10:54:53PMunchTrue, which is why it's good that -d:release was split
10:55:10PMunchBut -d:danger is still nice to have if you need it for something
10:59:46FromGitter<alehander42> PMunch where is this orm
11:00:02FromGitter<alehander42> i am making a small web framework these days
11:00:16FromGitter<alehander42> and i wondered what should my default orm: for now i use norm
11:00:59*actuallybatman quit (Ping timeout: 244 seconds)
11:02:03PMunchalehander42, I haven't gotten around to creating my ORM since parsesql doesn't run on compile-time..
11:02:19FromGitter<alehander42> i even managed to make scaffolding => different model files work, but not sure this makes sense with most nim orm-s as often they need a central schema
11:02:40FromGitter<alehander42> hmm i like that norm is the opposite: based on types/pragmas
11:02:50FromGitter<alehander42> i prefer using that as a single source of truth
11:02:55FromGitter<alehander42> have you looked at ormin btw
11:03:45PMunchYes I was looking at ormin
11:03:59PMunchI like it
11:14:02PMunchBut it doesn't have a MySQL backend yet..
11:14:24PMunchI think that should be an easy fix though
11:16:49FromGitter<alehander42> does parsesql fail because of streams
11:17:45FromGitter<alehander42> ok Araq, actually a better argument for the python imports people: right now it might be easy for me to find out with goto def what is defined where
11:18:11FromGitter<alehander42> but how can i see quickly how many things in e.g. "lexbase" come from "streams."
11:18:31PMunchalehander42, parsesql fails because of some VM bug I think
11:18:34FromGitter<alehander42> i guess one can say that this still doesnt help with >1 level of dependencies
11:19:27Araqalehander42: remove the 'import streams' from lexbase and run 'nim check'
11:19:30FromGitter<alehander42> hm its interesting that lexbase. actually is used a lot in parsesql
11:19:46PMunchAs you can see it tries to access a field that doesn't exist..
11:20:11Araqand while that might not be ideal it's still so much better than having to do the same in Python. Ridiculous.
11:21:09Araqagain, if you want to make this argument, argue in #python that module level def is to be preferred over def in classes.
11:21:43Araq"Python without OO is more maintainable", go ahead and make that claim.
11:22:09Araqdon't waffle around it, say it.
11:22:41FromGitter<alehander42> Araq: i am just noticing a possible tradeoff
11:22:48FromGitter<alehander42> otherwise dont care a lot
11:23:14FromGitter<alehander42> i dont like(understand) oop too much anyway, so i wont involve myself in that :D
11:23:47FromGitter<alehander42> btw PMunch what is the blocker
11:23:55FromGitter<alehander42> for directly hotcodereloading your web app
11:24:05FromGitter<alehander42> is it nimrtl support for the async stdlib modules
11:24:16FromGitter<alehander42> or for something else in jester
11:25:43PMunchI dunno, I tried to turn it on, and jester started complaining
11:26:01PMunchLike the most trivial jester example fails if you turn it on
11:27:05*eterps joined #nim
11:27:18FromGitter<alehander42> woah hm it actually compiled to C
11:27:37PMunchYeah, on devel
11:27:49FromGitter<alehander42> but had a c codegen bug in asyncdispatch
11:27:58Araqwe fixed nimrtl bugs fwiw
11:28:26FromGitter<alehander42> my error is /dev/shm/codetracer/stdlib_asyncdispatch.nim.c:739:88: error: conflicting types for ‘getGlobalDispatcher_Qj2WZ6U46mm9bNMz9b8QTS9cA_actual’
11:29:00FromGitter<alehander42> yeah the same
11:29:45PMunchThis happens a lot when you enable HCR/nimrtl /home/peter/.choosenim/toolchains/nim-0.20.0/lib/pure/htmlgen.nim(72, 28) Error: VM not allowed to do FFI, see `compiletimeFFI`
11:30:11*lf-araujo quit (Quit: lf-araujo)
11:30:26*lf-araujo joined #nim
11:33:02FromGitter<alehander42> its interesting that clang fails with different conflicting case
11:33:16FromGitter<alehander42> but probably a different order of analyzing them
11:33:23clyybberAraq: I think we need to introduce temporarys when an nkObjDown/nkObjUpConv is passed to a sink param
11:34:54Araqthat would be wrong
11:35:12Araqwhen you moved a subtype/supertype the underlying object must be nil'ed out
11:35:28clyybberAh, right.
11:35:46clyybberBut how to do it then?
11:36:17*vlad1777d quit (Ping timeout: 245 seconds)
11:36:51*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:37:13*Snircle joined #nim
11:37:14clyybberI think one solution would be to generate more eqmoves, so that every subtype is covered by one.
11:38:32clyybberSo that when we have `type Root = ref object of RootObj` `type Sub1 = ref object of Root` `type Sub2 = ref object of Root`
11:39:14clyybberinstead of generating eqmove(Root, Root); eqmove(Sub1, Sub1); eqmove(Sub2, Sub2)
11:39:44clyybberwe additionally generate eqmove(Root, Sub1); eqmove(Root, Sub2)
11:48:33FromGitter<zacharycarter> krux02: do you think you could merge - https://github.com/nim-lang/sdl2/pull/117 ?
11:49:05FromGitter<zacharycarter> just so it doesn't hang around forever
11:59:02*dddddd joined #nim
12:04:33krux02zacharycarter: just merged it
12:05:45FromGitter<zacharycarter> thanks!
12:07:06clyybberAraq: WDYT about the above approach?
12:12:37Araqclyybber, what's the problem?
12:13:46Araqthe problem appears to be: nkAddr(nkConv(x)) must be turned into nkConv(nkAddr(x))
12:19:10*eterps quit (Read error: Connection reset by peer)
12:28:44PMunchHmm, Araq is there a good reason why ormin doesn't name it's tuple values?
12:29:17*krux02 quit (Remote host closed the connection)
12:30:12*lf-araujo quit (Quit: lf-araujo)
12:30:32*lf-araujo joined #nim
12:35:35clyybberAraq: Ah, yeah that should work
12:50:04*miona joined #nim
12:53:51clyybberAraq: As a side effect, the Cgen will then also be able to compile stuff like this: 'proc t(v: var RootObject) = ... ; var a = ObjectThatInheritsFromRootObj(); t(a)'
12:55:47clyybberor to make it even through to the backend: 't(RootObject(a))'
12:55:56clyybberwhich would currently generate invalid code
12:56:03*shomodj joined #nim
12:57:19*nsf quit (Quit: WeeChat 2.4)
13:08:09AraqPMunch, because Ormin also supports real object types
13:15:53PMunchWait, it does?
13:23:09*theelous3 joined #nim
13:25:22*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:26:57Araqcheck the examples, I forgot
13:30:17*lf-araujo quit (Quit: lf-araujo)
13:34:21Araq"And don’t forget the fact, that UNIX system failed to keep T-Rex into park. It was even on TV, I think it was a documentary, but go look it up yourself."
13:34:55*krux02 joined #nim
13:35:08*krux02 quit (Read error: Connection reset by peer)
13:35:19*krux02 joined #nim
13:35:43*shomodj joined #nim
13:36:10PMunchHmm, I can't really see either of the examples using anything but tuples..
13:39:14*synshroud quit (Quit: ZNC 1.7.4 - https://znc.in)
13:40:00*clyybber quit (Quit: WeeChat 2.5)
13:40:07*miona quit (Remote host closed the connection)
13:44:32FromGitter<mratsim> Thoughts on deprecating `[]` as a deref operator and replacing it by `deref` function? https://github.com/nim-lang/Nim/issues/11705
13:48:20FromGitter<alehander42> there is a problem with lineinfo for functions
13:48:25FromGitter<alehander42> linedir *
13:49:11PMunchmratsim, I'm all for it
13:49:28PMunchI haven't had any issues with `[]`, but it's a bit strange and cryptic
13:49:31FromGitter<alehander42> i tried to add genLineDir(p, prc.ast)
13:49:38FromGitter<alehander42> in the beginning of genProcAux
13:49:41PMunchNim is already verbose about .addr, so why not .deref
13:50:06FromGitter<alehander42> to make line directives appear again for N_LIB_PRIVATE N_NIMCALL(.. etc lines
13:50:36FromGitter<alehander42> but its producing it in the body
13:50:38PMunchHmm, Araq the Ormin chat example gives me an error when I try to go to localhost:8080 "WebSocket negotiation failed: the only supported sec-websocket-version is 13"
13:51:18PMunchBut I might not have built it correctly
13:51:26PMunchBut that is hard since it doesn't have any documentation..
13:51:41Araqit's been a long time since I got ws to work with it
13:51:57PMunchI did "nim c server" and "nim js frontend"
13:52:03PMunchIs there anything else I need to do?
13:52:03AraqIME sockets/websockets don't work.
13:52:16Araquse a more recent ws implementation
13:53:01PMunchI just want to run the Ormin examples, do they rely on websockets?
13:53:35PMunchRather I'd want to run some tests, to see if my implementation of named tuples work
13:53:44PMunchBut Ormin doesn't have any tests..
13:54:13Araqthe examples are the tests
13:54:27PMunchBut how do I run them?
13:55:34Araqyour commands seem correct
13:55:37*lf-araujo joined #nim
13:55:44PMunchAnd to launch the test?
13:55:49PMunchErr, example
13:55:57Araqread the .travis.yml file please
13:58:14PMunchThat only builds it..
13:58:24PMunchIt doesn't actually run it, which is what I have issues with
13:58:35PMunchIt doesn't even build the front-end as far as I can tell..
14:00:17PMunchOh well, I have to go now..
14:00:22*PMunch quit (Remote host closed the connection)
14:07:42*floppydh quit (Quit: WeeChat 2.5)
14:10:50*natrys joined #nim
14:11:21*jmiven quit (Quit: reboot)
14:12:07*jmiven joined #nim
14:13:25*fredrik92 joined #nim
14:13:54*fredrik92 quit (Client Quit)
14:15:33*Senketsu quit (Quit: WeeChat 2.5)
14:15:47FromGitter<alehander42> it would be nice to get ormin in shape
14:16:00FromGitter<alehander42> i wonder whats the best way to make migrations
14:16:43FromGitter<alehander42> i have a lib where one defines them declaratively with some nim calls
14:17:30FromGitter<alehander42> but i dont like that : i think often one should be able to automate it, change your schema/models, change your init code and make the tool generate the migration
14:20:06*jest joined #nim
14:23:13*jest quit (Remote host closed the connection)
14:24:12*abm joined #nim
14:32:15*solitudesf joined #nim
14:54:22*solitudesf quit (Remote host closed the connection)
14:54:49*solitudesf joined #nim
14:58:46*lf-araujo quit (Ping timeout: 246 seconds)
15:03:49*lritter joined #nim
15:18:41Araqalehander42: agreed
15:21:12*synshroud joined #nim
15:23:11shashlickjoinThread() is hanging on linux, but works fine on Windows - what's the deal?
15:33:25FromGitter<mratsim> @Araq, is it feasible to get minimal stacktraces in release mode when we have a SIGSEGV?
15:35:21FromGitter<arnetheduck> it's feasible to get full stacktraces by compiling with --debuginfo and running through gdb :)
15:35:57FromGitter<mratsim> Sounds like a chore :P
15:36:28FromGitter<mratsim> and I think it's --debugger:native
15:36:45FromGitter<arnetheduck> this will always be "lighter" than whatever nim can achieve due to how it's table-driven with dwarf debug info.. `nlvm` can get it for free too but from `c` it's trickier to gen the right tables
15:36:47FromGitter<mratsim> you even get the function input values
15:37:16FromGitter<mratsim> So can nlvm compile nimbus?
15:37:34FromGitter<mratsim> ah there is secp256k1 dependency
15:37:35FromGitter<arnetheduck> no, nlvm is 0.20 which is broken
15:37:47FromGitter<arnetheduck> secp is fine, nlvm can use c libraries
15:38:05FromGitter<arnetheduck> (how would it link to glibc otherwise?)
15:39:05*couven92 quit (Read error: Connection reset by peer)
15:39:06FromGitter<mratsim> Ithought it still had importc issues
15:39:25FromGitter<arnetheduck> `--debuginfo` works for me.. everything is nicer with it enabled, I kind of wonder why it's not the default actually
15:39:55FromGitter<arnetheduck> ie call stacks, parameters etc etc.. profiling with `perf` - all the c tooling that exists already
15:40:02*rockcavera quit (Remote host closed the connection)
15:41:14FromGitter<arnetheduck> nlvm has never had importc issues. it has issues when in nim the ABI is not matched (ie if you specify a struct/object with the fields in different order) because nim-c will use the c header file order and nlvm will use the nim order..
15:41:18*absolutejam quit (Ping timeout: 245 seconds)
15:42:34FromGitter<arnetheduck> ah there's one more importc issue: when nim imports a macro/constant as a var - arguably this is dubious in nim because a const shouldn't be a var.
15:48:48*federico3 quit (Ping timeout: 245 seconds)
15:49:00*federico3 joined #nim
15:54:21Araqwell yes, you're both right
15:55:03Araqthe default stack traces are nicer to read but their overhead is big and I don't like to spend more effort on a "minimal" version for the release mode
15:55:34Araqfor the release mode we have --debuginfo. there is also "nativeStackTraces"
15:58:54*vlad1777d joined #nim
16:09:49*shomodj quit (Quit: Textual IRC Client: www.textualapp.com)
16:10:02*shomodj joined #nim
16:29:38*nsf joined #nim
16:52:29FromDiscord_<Skaruts> hey guy, is there a way to ask the compiler to tell me where a function call came from?
16:53:33FromDiscord_<Skaruts> cos I have a mysterious call, if I comment out the function there's no errors, if I don't, it gets called somehow (I have an `echo` in it getting printed out)
16:57:16lqdev[m]add that to the problematic function
16:58:05FromDiscord_<Skaruts> I just noticed its from a `case of`
16:58:43FromDiscord_<Skaruts> but I don't think I'm using the branch that calls the function though...
17:00:01FromDiscord_<Skaruts> well I probably forgot something somewhere...
17:01:49*rockcavera joined #nim
17:03:18lqdev[m]perhaps some stack trace related call gets optimized away
17:03:30lqdev[m]gdb may help you in that scenario
17:03:46lqdev[m]or, echo the value that you pass to the case of
17:03:56FromDiscord_<Skaruts> nevermind I'm just burned out and not thinking straight
17:04:17lqdev[m]I feel you
17:04:26FromDiscord_<Skaruts> I was commenting out the case of branch, so of course there's no errors when I comment out the function
17:04:30FromDiscord_<Skaruts> lol
17:05:32lqdev[m]dumb errors happen to us all the time, don't worry :)
17:05:39FromDiscord_<Skaruts> thanks for that tip though
17:07:46*Jesin quit (Quit: Leaving)
17:10:55*Jesin joined #nim
17:13:39*krux02 quit (Remote host closed the connection)
17:22:22FromGitter<zacharycarter> question - if I'm using HCR - can I use streams in the code that isn't hot reloaded?
17:23:56*xet7 quit (Quit: Leaving)
17:25:09FromGitter<zacharycarter> I guess not :/ because when I try to with `--hotCodeReloading:on` I get the error: `Error: unhandled exception: key not found: failedAssertImpl_W9cjVocn1tjhW7p7xohJj6A [KeyError]`
17:25:22FromGitter<zacharycarter> that's disappointing - I guess I won't be using HCR :/
17:25:55FromGitter<zacharycarter> I guess it's still not very useful
17:26:29*Senketsu joined #nim
17:27:22*actuallybatman joined #nim
17:30:42FromGitter<zacharycarter> and that I guess means coming up with scripting system becomes a pointless endeavor as well
17:31:18shashlick@zacharycarter - i know i already mentioned it but check out feud's plugin system
17:31:33FromGitter<zacharycarter> I took a look - but you're using boehm correct?
17:31:38shashlicki haven't used hcr but it works just fine
17:31:56FromGitter<zacharycarter> I'm using Nim's default GC
17:31:57shashlickyes, but i'm working on https://github.com/genotrance/shared which will remove dependency on boehm, at least for me
17:32:19shashlickreally makes no diff which GC, between default and boehm for most projects
17:32:31shashlickalthough boehm is more unstable on devel/0.20.0
17:32:40shashlickwhich pushed me to making shared again
17:33:48FromGitter<zacharycarter> from my understanding, with shared libraries and nim's default GC, there will be multiple instances of the GC that are not aware of one another
17:34:13FromGitter<zacharycarter> so you could potentially have one GC collect memory another is still referencing
17:36:32shashlickdo you have multiple threads loading the same dll?
17:38:01FromGitter<zacharycarter> well ideally no - but I think in every plugin system I've looked at with Nim there is another thread responsible for watching changes to files and loading / unloading the dll
17:38:01*xet7 joined #nim
17:43:01shashlickthat's what i do too
17:43:40FromGitter<zacharycarter> yeah - so my main thread would potentially grab references to memory from the thread that loads the shared lib
17:43:46FromGitter<zacharycarter> and both threads would have independent GCs
17:44:20FromGitter<zacharycarter> maybe I'll just use luajit or something
17:45:16FromGitter<zacharycarter> although I'm not sure that would just automatically guarantee any type of hot swapping either
17:45:48Araqif you tell me that you don't need freaking async I can give you threads and channels for --newruntime
17:46:15FromGitter<zacharycarter> I don't need async. Yet... haha
17:48:53FromGitter<zacharycarter> hot loading would drastically speed up iteration time though - if I can figure out some way of achieving it and still use the default gc
17:50:12*leorize quit (Ping timeout: 260 seconds)
17:53:09shashlickthat's exactly why i built the plugin system first, since i didn't want to build everything into one binary - would make dev slow
17:54:08FromGitter<zacharycarter> yeah - I've been down that road before though and it's a lot of work for unreliable results (if you're not able to use boehm or another GC)
17:54:26Araqwell HCR worked for me with the default GC
17:54:26*leorize joined #nim
17:54:39FromGitter<zacharycarter> it works for me - but not if I use streams in my main program
17:54:49FromGitter<zacharycarter> that results in an instant crash
17:55:00FromGitter<zacharycarter> FileStream
17:57:03FromGitter<zacharycarter> I'll post a gist
17:57:38FromGitter<zacharycarter> maybe I'm doing something else wrong and blaming it on HCR
17:59:38FromGitter<zacharycarter> https://gist.github.com/zacharycarter/2555ccf9e7afcb6f5a27cd0934942f38
18:00:13FromGitter<zacharycarter> first file is the file I'm parsing - second file is the Nim source
18:01:11*absolutejam joined #nim
18:02:10*Trustable joined #nim
18:07:03shashlickwhat's the crash output
18:07:14FromGitter<zacharycarter> it's at the top of the second file in the gist
18:07:38FromGitter<zacharycarter> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5d277aea4d750532412aa43f]
18:08:01shashlickno stack trace?
18:08:06FromGitter<zacharycarter> nope
18:08:42*leorize_ joined #nim
18:09:19shashlickok, going back to the previous topic, I load the dlls in my main thread and call procs in the same thread, so everything is in one GC
18:10:02shashlickif you want every thread to do that, perhaps each thread loads its own copy of the dll? Araq might know better
18:10:16*leorize quit (Ping timeout: 260 seconds)
18:10:28shashlickas for sharing memory, you can only share what's allocShared()
18:10:50shashlickso i don't understand why loading dlls is being mixed with threads
18:12:16FromGitter<zacharycarter> hmm - I might have to give it a try then if you're only loading and calling procs from one thread - that might work
18:12:21FromGitter<zacharycarter> are you using channels or something to achieve that?
18:12:28shashlickwhat do you want to do across threads?
18:12:33FromGitter<zacharycarter> nothing
18:12:34shashlicki'm loading and calling in the same thread
18:12:46FromGitter<zacharycarter> oh okay
18:12:52FromGitter<zacharycarter> but not in the main thread
18:12:54shashlickmy monitor is a separate thread but it tells my main thread when something has changed
18:12:58FromGitter<zacharycarter> ah okay
18:13:08FromGitter<zacharycarter> I see - I'll give it a looksee and maybe I can get it to work
18:13:34shashlicki am using boehm cause i was sharing between monitor thread and main thread
18:14:02shashlickbut that is a mess, Araq saw the bug in 2 minutes when i was crashing nonstop with the default GC
18:14:18shashlickso boehm helped with 0.19.x but 0.20.0 even that is crashing
18:14:27shashlickso in order for me to update, i have to share with allocShared
18:14:33*nsf quit (Quit: WeeChat 2.4)
18:14:36shashlickhence the shared module i'm working on
18:15:03FromGitter<zacharycarter> gotcha
18:15:18shashlickdoes anyone know if you can check if you already have a lock?
18:15:35shashlickusing withLock() recursively works fine on windows, but pthreads gets pissed off
18:17:34FromGitter<zacharycarter> maybe something is up other than using HCR with streams - because I can put together a four line example that works fine
18:17:50FromGitter<zacharycarter> this error is just not very easy to debug because I don't get any stack trace...
18:24:17*leorize_ is now known as leorize
18:27:05FromGitter<zacharycarter> Araq: should I file an issue for this?
18:30:20*leorize quit (Ping timeout: 260 seconds)
18:37:43*leorize joined #nim
18:38:20*Trustable quit (Remote host closed the connection)
18:40:23*kuon__ quit (Remote host closed the connection)
18:40:50*kuon__ joined #nim
18:44:27FromGitter<zacharycarter> well - it works with sdl rwops so I think I can get by with that
18:57:45FromGitter<zacharycarter> I don't think this has to do with streams after all - I think it's because I'm echoing something that isn't echoable with useNimRtl
18:58:21FromGitter<zacharycarter> or something along those lines
19:03:25rayman22201trippy that there is no stack trace
19:03:35rayman22201are you using devel or 0.20?
19:05:18FromGitter<zacharycarter> 1) 20
19:05:49FromGitter<zacharycarter> it seems to happen as soon as the executable is launched - if I compile with debug symbols and run it through gdb my entrypoint doesn't even get hit
19:06:57rayman22201try devel?
19:09:08rayman22201also, where do you end up when you run it inside gdb? just curious
19:09:09*lmariscal quit (Quit: I'm out!)
19:09:40*lmariscal joined #nim
19:09:55*lmariscal quit (Client Quit)
19:10:12*lmariscal joined #nim
19:20:01FromGitter<Obround> Is there some way you can override built-ins in nim?
19:23:48FromGitter<zacharycarter> I basically see the same output in gdb
19:24:12FromGitter<zacharycarter> I can try devel - but I have managed to get around the error by just not echoing the sequence I had created
19:24:58rayman22201@Obround, what are you trying to override exactly?
19:24:59rayman22201@zacharycarter, you end up inside Tables.nim line 263? Does gdb show the stack trace of how it got there?
19:25:09FromGitter<zacharycarter> nope
19:25:49FromGitter<zacharycarter> let me double check but I'm pretty sure it doe snot
19:25:50rayman22201hrmmm. When gdb can't show the stack trace it usually means a memory corruption... weird...
19:27:22FromGitter<zacharycarter> well - I can't get gdb to stop anywhere
19:27:29FromGitter<zacharycarter> I even am running it with flags to stop on exceptions
19:27:31FromGitter<zacharycarter> and it's not stopping
19:28:03FromGitter<zacharycarter> as long as I don't echo this seq though - everything seems fine - and I was only doing that for debugging purposes
19:28:25FromGitter<zacharycarter> I can still echo the strings it contains
19:30:23rayman22201well, when it crashes, gdb should stop
19:30:43rayman22201then you can do "bt" to get the stack trace from that point
19:30:50FromGitter<zacharycarter> yeah - but that doesn't happen at all
19:30:59FromGitter<zacharycarter> at least I don't think it does
19:35:27FromGitter<zacharycarter> gdb just exits
19:35:46rayman22201yeah, Nim catches the exception and "gracefully exits"
19:36:32FromGitter<zacharycarter> :)
19:37:07Araqto prevent that from happening
19:37:30rayman22201I was going to tell him to try and put a breakpoint in the signal handler, but that works too
19:38:41Zevvzacharycarter: you are still hunting the crash from your gist snippet?
19:38:56rayman22201I'm pushing him to look deeper into it :-P
19:38:58FromGitter<zacharycarter> nah - I'm just not doing what I think was causing the crash anymore
19:39:40rayman22201because I have a hunch there is something interesting going on here
19:40:05FromGitter<zacharycarter> even `-d:noSignalHandler` produces the same reuslt
19:40:50Zevvvalgrind knows what is happening
19:40:55FromGitter<zacharycarter> I'd blame all the bindings and shared libs I'm loading and chalk it up to memory corruption - but given that the gist which isn't using anything but the Nim stdlib crashes too
19:41:06FromGitter<zacharycarter> no valgrind for me :( on windows
19:41:47FromGitter<zacharycarter> nice!
19:41:51FromGitter<zacharycarter> I wonder why that's happening
19:42:13FromGitter<zacharycarter> and also why I get that funky ass error
19:42:39rayman22201Valgrind is cool... I always forget lol
19:43:56FromGitter<zacharycarter> also - why does removing the echo from the program fix it?
19:44:35rayman22201I'm guessing the invalid read brought some garbage into memory, that the echo is later trying to read. If you don't echo, it doesn't read the bad memory.
19:45:23FromGitter<zacharycarter> makes sense - so basically I have a time bomb in my app atm
19:45:37rayman22201I have a feeling the bad memory is still there though, waiting to cause havoc for you later. yup... a memory land mine :-P
19:45:47ZevvI'm digging, looks like readDataImpl is messed up
19:47:30FromGitter<zacharycarter> I feel like I'm war torn Bosnia
19:48:05ZevvnewFileStream is borked
19:48:30Zevvif you call it with file name it creates a proper file stream if the file can be opened
19:48:44Zevvif not, it silently returns and the stream has uninitialized function pointers
19:49:13FromGitter<zacharycarter> yeah - I think I switched to using openFileStream
19:49:49rayman22201ohhh, nice find
19:50:11FromGitter<zacharycarter> but the whole invalid read size is still a mystery
19:50:19Zevvso, what should it do if open fails?
19:50:40FromGitter<zacharycarter> supposedly
19:50:43FromGitter<zacharycarter> according to the docs
19:51:23Zevv"This function returns nil in case of failure"
19:51:24rayman22201nope: "This function returns nil in case of failure"
19:51:33rayman22201I'm too slow lol
19:52:45rayman22201I'm guessing two implementations b/c some people don't want exceptions?
19:53:09Zevvwell there you have it. The thing is friggin nil
19:53:16Zevvthis is why I left Lua
19:53:24FromGitter<zacharycarter> oh sorry - when you said `open` I thought you meant - `openFileStream`
19:53:31FromGitter<zacharycarter> `newFileStream` will return nil
19:53:38FromGitter<zacharycarter> `openFileStream` with raise an exception
19:53:53Zevvyeah. It's try-ed in your code, but not checked for nilism
19:54:49FromGitter<zacharycarter> well - in my actual program I'm using `openFileStream` now and it's still crashing
19:55:05Zevvgist it
19:55:15FromGitter<zacharycarter> let me modify the example - it's a lot of code
19:56:57FromGitter<zacharycarter> if you just change line 130 from `stream = newFileStream(basePath)` to `stream = openFileStream(basePath)` - that's what I just did and it still crashes
19:57:16FromGitter<zacharycarter> also - the file exists so it's not because of that I don't think
19:57:39rayman22201it exists, but does your program have the right permissions to read it?
19:58:09rayman22201I know you are windows, but that kind of thing can still happen
19:58:12Zevvit works just fine
19:58:25Zevvas long as the zmap is in the proper subdir
19:58:38ZevvI had to make assets/maps and move it in there
19:59:21Zevv@["grass.png", "cliffs.png", "cobblestone.jpg", "grass2.jpg", "dirty_grass.jpg", "cracked_dirt.jpg", "dirt_road.jpg", "metal_platform.jpg", "snowy_grass.jpg", "lava_ground.jpg", "sand.jpg"]
20:00:11FromGitter<zacharycarter> okay let me try putting it in the same directory and modifying the code slightly
20:00:40FromGitter<zacharycarter> I still get that error - let me check file permissions
20:00:54Zevvoooooh, wait. you're not on linux :)
20:01:17FromGitter<zacharycarter> nope - windows :)
20:01:30Zevvglad I can be of help. I tried to help some other guy this morning, but I was completely flabbergasted
20:01:39ZevvNever heard of that stuff
20:01:44rayman22201there is a reason it's experimental lol
20:02:12FromGitter<zacharycarter> permissions seem fine
20:02:13Zevvyeah, why is it not in the experimental manual?
20:02:22rayman22201I thought it was?
20:02:37Zevvit's in the devel manual, but not in the experimental manual
20:03:36rayman22201hrmmmm.... maybe an oversight? or maybe the core team thinks it won't be experimental by the next release? lol
20:03:37FromGitter<zacharycarter> here's what Dr. Memory spits out - https://gist.github.com/zacharycarter/85b15100361498a54077edd45f4a15b2
20:04:55FromGitter<zacharycarter> definitely looks to me like it has something to do with hcr / nimRtl
20:05:16ZevvJust sent a PR to move it to experimental manual
20:05:56Zevvthat's a pretty useless dump of numbers if you ask me
20:06:38Zevvso you are doing more then just the snippet I assume
20:06:49FromGitter<zacharycarter> no - that's from compiling and running the snippet
20:07:01FromGitter<zacharycarter> `nim c -r --hotCodeReloading:on -d:useNimRtl -d:noSignalHandler .\foo.nim`
20:10:29Zevvoh need to bake some libnimhcr stuff ifrst
20:11:10FromGitter<zacharycarter> it's probably reproducable with just -d:useNimRtl
20:11:25FromGitter<zacharycarter> nevermind
20:13:53*narimiran quit (Ping timeout: 258 seconds)
20:14:29ZevvI have hcr issues.
20:14:42Zevv"key not found: failedAssertImpl_W9cjVocn1tjhW7p7xohJj6A" at compile time
20:14:50FromGitter<zacharycarter> yarrr
20:14:53FromGitter<zacharycarter> that's the error I get!
20:15:05Zevvoh raight :)
20:16:39*jjido joined #nim
20:17:04FromGitter<zacharycarter> I guess it might be time to checkout shashlick's plugin system :P
20:17:17FromGitter<zacharycarter> because I have no idea how to figure this one out
20:17:19ZevvI have no clue about the hcr status
20:17:34ZevvI got it to run once, but I feel there is some tricky stuff involved there and a very small user base to find bugs
20:18:35rayman22201apparently pei386_runtime_relocator is a mingw thing that runs on dll startup. Maybe a mingw bug? https://mingw.fedoraproject.narkive.com/lxzD0FxL/pei386-runtime-relocator
20:19:06FromGitter<zacharycarter> well if Zevv is getting it on linux too
20:19:34rayman22201hrmmm, true
20:21:11ZevvfailedAssertImpl_W9cjVocn1tjhW7p7xohJj6A gets declared static in the C code
20:21:23ZevvI know nil about codegen
20:23:23FromGitter<zacharycarter> I don't even know where nimcache resides anymore lol
20:23:32FromGitter<zacharycarter> oh found it
20:24:07rayman22201what happens if you add `--passC: --enable-runtime-pseudo-reloc-v1` ?
20:24:54FromGitter<zacharycarter> not sure what the equivalent of that is for `cc`
20:25:13FromGitter<zacharycarter> okay well `failedAssertImpl_W9cjVocn1tjhW7p7xohJj6A` must come from the asserts next to the readlines
20:25:19FromGitter<zacharycarter> so let me get rid of those
20:25:51rayman22201are you not using mingw on windows?
20:25:57rayman22201what are you using?
20:27:51FromGitter<zacharycarter> yeah I think I am - but that flag did not work for me
20:28:02rayman22201actually it's `PassL` sorry. It's a linker flag
20:28:06FromGitter<zacharycarter> ah np
20:28:19FromGitter<zacharycarter> same error :/
20:28:32rayman22201well damn. It was worth a shot
20:29:10*Vladar quit (Read error: Connection reset by peer)
20:29:26*Trustable joined #nim
20:31:20FromGitter<zacharycarter> I agree - I should probably go to sleep because I don't think this one is going to get solved any time soon
20:31:48Zevvlikely an HCR issue
20:32:08FromGitter<zacharycarter> I agree - and I don't know if anyone is working on HCR
20:32:41rayman22201I agree. It
20:32:46rayman22201it's an hcr issue
20:32:58rayman22201would be nice to get a bug report, but oh well
20:33:22FromGitter<zacharycarter> I can file one - but I'm not sure if my example is minimal enough
20:33:30ZevvI'm diging through the C gen code to see where this static is coming from
20:33:33FromGitter<zacharycarter> I tried coming up with smaller ones but to no avail
20:33:35rayman22201That's what I mean. a minimal repro
20:33:39FromGitter<zacharycarter> yeah
20:33:39Zevvand everywhere I go I see `if hcrOn:`
20:36:54Zevvwell, you could file an issue with your gist, it's small enough to reproduce
20:36:56rayman22201@zacharycarter, are you using mingw 64bit or 32bit?
20:37:05ZevvI guess in the hands of someone who knows whats going on it should be clear
20:37:22rayman22201based on the Dr. Memory thingy you sent, this is the function that is exploding: https://github.com/Alexpux/mingw-w64/blob/d0d7f784833bbb0b2d279310ddc6afb52fe47a46/mingw-w64-crt/crt/pseudo-reloc.c#L464
20:37:43rayman22201And that has some ifdef stuff for 64bit, so I wonder if that is related
20:38:20rayman22201maybe some similar issue with linux gcc and 64bit shared libs?
20:39:13rayman22201@Zevv, good poitn
20:39:15FromGitter<Obround> @FromIRC -- I am trying to override something like the out keyword
20:39:34Zevvnah, it's not even getting to the shared lib parts. It's the Nim compiler itself not finding a symbol somewhere
20:39:38ZevvThere is nothing getting linked yet
20:39:40FromGitter<Obround> Oh
20:41:28rayman22201lol. @Obround. IRC is bridged, that's not my username. You cannot override reserved words.
20:42:23FromGitter<zacharycarter> 64 bit mingw
20:42:39rayman22201I wonder if using 32bit will make a difference
20:44:03FromGitter<zacharycarter> if I turn up the verbosity to 3 on the nim compile command I get some more output
20:44:05rayman22201@Obround, you can do this: http://ix.io/1ObS/nim
20:44:34FromGitter<zacharycarter> but that seems like it's because the compilation is failing
20:44:47Zevvalso wrong with 32 bit
20:44:58Zevvand I was wrong, it *is* a runtime error, not nim compile time
20:45:03rayman22201what does verbosity 3 show?
20:45:28Zevvnim and c compilation are just fine, linking as well
20:45:35Zevvrun time problem with symbol resolving.
20:46:19Zevvand now: nightynight
20:46:30rayman22201ah, so that _pei386_runtime_relocator function failing makes more sense
20:48:03FromGitter<zacharycarter> night! thanks for helping look into it Zevv!
20:48:10FromGitter<zacharycarter> and you too rayman :)
20:48:23rayman22201np. sorry we couldn't help more
20:48:48Zevvits worth an issue I guess
20:51:25FromGitter<zacharycarter> no worries - I'll file an issue tomorrow and give shashlick's plugin system a go
20:59:46shashlick@zacharycarter - i'm still fighting with 0.20.0 so will recommend sticking with 0.19.6 for now
20:59:58shashlickclose to finishing shared - just ran into =destroy issue
21:00:18shashlick`Error: type bound operation `=destroy` can be defined only in the same module with its type (SharedSeq)`
21:06:40leorize[m]due to complications in letting them to be defined in other modules
21:08:12leorize[m]causing those to be bound too late
21:08:23shashlickit worked in 0.19.6 😞
21:08:51*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:09:33leorize[m]and there were bugs related to it
21:09:52leorize[m]iirc one of the reason for this change was that if you define a type like this:
21:10:01leorize[m]A: object
21:10:20leorize[m]B = object
21:10:23leorize[m]a: A
21:10:40leorize[m]and you define destructors for A afterwards
21:11:00leorize[m]that destructor won't be bound to B
21:16:45*stefanos82 quit (Quit: Quitting for now...)
21:17:59*shomodj_ joined #nim
21:18:20*__Myst__ quit (Ping timeout: 272 seconds)
21:21:05*shomodj quit (Ping timeout: 248 seconds)
21:22:42shashlickhow do you do parent/child classes such that if i pass a child obj to a proc with parent param, it will work
21:26:27rayman22201you can make a `FlowVar[string]` but you can't make a `FlowVar[tuple[a: string]]` ???
21:27:13*jjido joined #nim
21:27:45leorize[m]shashlick: what do you mean?
21:28:29*seni joined #nim
21:28:30leorize[m]a child type can always be converted to the parent type
21:31:16shashlickgeneric methods are deprecated?
21:31:52*jjido quit (Client Quit)
21:32:00FromGitter<alehander42> i think this is old
21:32:19FromGitter<alehander42> a long time ago it was talked that generics + methods have problems
21:37:02shashlickgosh i'm totally stuck
21:38:09*absolutejam quit (Ping timeout: 248 seconds)
21:39:56rayman22201I would expect this to work: http://ix.io/1Oc9
21:40:01rayman22201but I get `/home/ray/test.nim(6, 15) Error: cannot create a flowVar of type: tuple[a: string]`
21:40:26rayman22201any thoughts?
21:41:22rayman22201latest devel btw
21:42:59dom96shashlick, https://github.com/dom96/choosenim/issues/124
21:43:15dom96Can't remember if you changed this or not
21:43:30dom96I guess so since we built from tar.gz's on windows before :/
21:45:00shashlickyep, it's that damn powershell 2.0
21:45:35dom96if unzipping isn't reliable on Windows we should revert back to what we had
21:45:41dom96at least it was reliable AFAIK
21:46:10*jjido joined #nim
21:46:24shashlickwe should fallback to legacy if powershell is old
21:46:37shashlicki am close to getting nimarchive working, then we can just extract ourselves
21:47:22*a_b_m joined #nim
21:47:55shashlickI'm getting unresolved generic parameter here - https://github.com/genotrance/shared/blob/master/shared/seq.nim#L131 - worked on 0.19.6 - any suggestions?
21:48:09FromGitter<alehander42> dom96 please look or merge that category pr for nimforum
21:48:23FromGitter<alehander42> active contributors should remain motivated :(
21:48:34FromGitter<alehander42> and it seems this one waited so much
21:49:21dom96Please help with reviews like this
21:49:35dom96I am only one person, I cannot be the sole reviewer for so many things
21:49:54dom96I know you don't have as much knowledge about this, but at least you can pick out the low hanging things that obviously need fixing
21:50:25*abm quit (Ping timeout: 248 seconds)
21:50:29dom96also, with this one this is more about testing rather than reviewing tbh
21:51:00FromGitter<alehander42> yeah this one just looked like a bigger change which probably requires some kind of decision by the software creator
21:51:06FromGitter<alehander42> as its a big new feature
21:51:12*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:51:15FromGitter<alehander42> otherwise you're right
21:51:54dom96A decision of whether this should be implemented is already: yes. In fact, I asked for this to be implemented IIRC
21:52:23*absolutejam joined #nim
21:55:59FromGitter<alehander42> ahh
21:56:00*solitudesf quit (Ping timeout: 268 seconds)
22:00:03dom96So many changes, yeah, I can't review this tonight
22:00:55FromGitter<alehander42> yeah, i feel you
22:02:54FromGitter<Kvothe87> hello all
22:03:18FromGitter<Kvothe87> any experience with nigui?
22:04:01*absolutejam1 quit (Ping timeout: 246 seconds)
22:04:24FromGitter<Kvothe87> i just took one of the examples and tried to compile and get the following error "Error: 2147483648 can't be converted to int"
22:05:53FromGitter<Kvothe87> i don't have any int so i guess is something in the library
22:06:11FromGitter<Kvothe87> was there any change in 0.20 that may have an effect?
22:07:34rayman22201lots of changes in 0.20, hard to tell. I don't have experience with nigui. You might be better off posting on the forum along with which specific example is failing.
22:08:22FromGitter<Kvothe87> thanks
22:08:55FromGitter<ratiotile> @Kvothe87 I ran into a similar problem before and the solution was to use a static int for generics
22:09:37FromGitter<ratiotile> but that's something in the library itself that needs to change
22:09:48rayman22201iirc the NiGui guy is on the forum more than he is on irc.
22:15:41*__Myst__ joined #nim
22:16:40*absolutejam1 joined #nim
22:20:46*a_b_m quit (Ping timeout: 258 seconds)
22:23:50*absolutejam quit (Ping timeout: 258 seconds)
22:34:42shashlick@Araq - any chance you are around?
22:35:56*Trustable quit (Remote host closed the connection)
22:40:50*shomodj_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:44:10*vlad1777d quit (Ping timeout: 244 seconds)
22:55:18shashlickif I make a generic object but don't use T, Nim complains "unresolved generic parameter". this doesn't happen with 0.19.6. my workaround - https://github.com/genotrance/shared/blob/master/shared/seq.nim#L9
22:56:21*disruptek quit (Read error: Connection reset by peer)
22:57:32*disruptek joined #nim
23:00:08*dwdv quit (Ping timeout: 268 seconds)
23:02:38lmariscalshashlick but why do you need the generic type?
23:03:23lmariscalsince you are not using it in the SharedObj
23:07:21shashlickI am using it
23:07:29shashlickit is a shared seq
23:07:33shashlickso has to be generic
23:07:44shashlicki'm just not using the info in the object but within SharedObj
23:13:36*disruptek quit (Ping timeout: 272 seconds)
23:16:30*disruptek joined #nim
23:24:12*traviss joined #nim
23:24:26*traviss quit (Client Quit)
23:26:59FromDiscord_<Travis> araq: what is the `gg` file search tool you use on stream? I want to try it out.
23:27:23*natrys quit (Quit: natrys)
23:27:29*ng0 quit (Quit: Alexa, when is the end of world?)
23:29:21FromGitter<Obround> Is there a way you can disable a proc (for example `echo`)
23:30:24FromGitter<ratiotile> you can use a template that checks cond and then calls echo
23:31:19FromGitter<Obround> could you give an example(i'm noob at nim)
23:32:24FromGitter<Obround> @ratiotile -- Could you give an example(I'm noob at Nim)
23:32:40FromDiscord_<Travis> does this throw an error for you?
23:32:40FromDiscord_<Travis> ```nim
23:32:40FromDiscord_<Travis> template echo(ss: varargs[string]) = discard
23:32:40FromDiscord_<Travis> ```
23:32:55shashlickjust don't import it
23:33:41FromGitter<Obround> <Travis> What do you mean by don;t import it?
23:34:05FromGitter<ratiotile> @Obround try starting with a proc and turn it into a template once you get it
23:34:16FromGitter<Obround> Ok.
23:36:36rayman22201@Obround, `import system except echo`
23:36:43rayman22201that is @shashlicks solution
23:37:25rayman22201That will just skip the echo function from being imported into your program
23:38:37rayman22201If you wanted something *fancier*, you could do:
23:38:38rayman22201`template echo(args: untyped) = raise newException(AssertionError, "sorry echo not allowed")`
23:39:27rayman22201the import except way is better though imo
23:41:46FromDiscord_<Travis> and if you want to ignore echo:
23:41:46FromGitter<ratiotile> huh, I assumed he wanted a way to globally turn off all echos in the code. Is Obround making some sort of sandbox?
23:41:46FromDiscord_<Travis> ```nim
23:41:46FromDiscord_<Travis> import system except echo
23:41:46FromDiscord_<Travis> template echo(args: untyped) = discard
23:41:46FromDiscord_<Travis> ```
23:43:39rayman22201lol. Yes, that will turn `echo` into a noop.
23:48:32rayman22201@ratiotile, good question. There is no way to disable a proc "globally". If a library that you import calls `echo` there isn't anything you can do about it.
23:49:23FromDiscord_<Travis> haha, i think that would be a pretty big security problem
23:52:31*dddddd quit (Ping timeout: 246 seconds)
23:57:27rayman22201what are you actually trying to do @Obround?