<< 26-11-2019 >>
00:02:01*abm joined #nim
00:04:59*ng0 quit (Quit: Alexa, when is the end of world?)
00:41:42*theelous3 quit (Read error: Connection reset by peer)
01:02:18*shodan45 quit (Quit: No Ping reply in 180 seconds.)
01:06:41*shodan45 joined #nim
01:16:03*Hideki_ joined #nim
01:31:22*Hideki_ quit (Remote host closed the connection)
01:32:25*Hideki_ joined #nim
01:36:16*uu91 quit (Read error: Connection reset by peer)
01:36:31*uu91 joined #nim
01:36:37*Hideki_ quit (Ping timeout: 240 seconds)
01:37:03*uu91 quit (Read error: Connection reset by peer)
01:37:16*uu91 joined #nim
01:41:55*uu91 quit (Read error: Connection reset by peer)
01:42:16*uu91 joined #nim
01:53:41*Hideki_ joined #nim
01:59:44*kevin5 joined #nim
02:07:00*Hideki_ quit (Remote host closed the connection)
02:10:33*Hideki_ joined #nim
02:15:18*Hideki_ quit (Ping timeout: 268 seconds)
02:17:31*Hideki_ joined #nim
02:18:46*Hideki_ quit (Remote host closed the connection)
02:19:53*Hideki_ joined #nim
02:24:33*Hideki_ quit (Ping timeout: 268 seconds)
02:26:56*kevin5 quit (Quit: ERC (IRC client for Emacs 26.3))
02:27:50*kevinchau joined #nim
02:40:21*endragor joined #nim
02:57:06*Hideki_ joined #nim
03:16:01*Hideki_ quit (Ping timeout: 265 seconds)
03:59:21*uu91 quit (Read error: Connection reset by peer)
03:59:25*rockcavera quit (Remote host closed the connection)
03:59:34*uu91 joined #nim
04:04:50*kevinchau quit (Ping timeout: 265 seconds)
04:06:43*nsf joined #nim
04:16:45*chemist69 quit (Ping timeout: 250 seconds)
04:18:43*chemist69 joined #nim
04:37:41disruptekdisbot now falls back to non-nim searches when it fails to find !repo(s) or !search(es) results.
04:37:41disboton it. 👍
04:37:52disruptekyou a badass, alright.
05:06:30*ltriant quit (Quit: leaving)
05:12:42*Hideki_ joined #nim
05:14:10FromDiscord_<Kaynato> If I have set in nim.cfg `cc:"gcc"` and `gcc.cpp.exe:"nvcc"`, etc. when I run `nim cpp --verbosity=3 test`, if it shows `g++.exe -c` .... have I misconfigured?
05:17:38*Hideki_ quit (Ping timeout: 276 seconds)
05:25:36FromDiscord_<demotomohiro> Try `--listcmd` option instead of --verbosity might show nvcc command.
05:25:51*njoseph quit (Ping timeout: 246 seconds)
05:26:18FromDiscord_<Kaynato> Hmm, still g++.exe ... (etc)
05:26:27FromDiscord_<Kaynato> I think it is not picking up the config correctly
05:28:20FromDiscord_<Kaynato> The nim.cfg is definitely being read because it behaves differently than otherwise. That means the flag is going through and it it setting the parameters, but somehow I must be doing that incorrectly
05:28:31*dddddd quit (Remote host closed the connection)
05:33:05FromDiscord_<Kaynato> Ok, this is really weird. I can manually specify the switches, but the switches as defined in the config don't do anything at all
05:33:07FromDiscord_<Kaynato> Ok, this is really weird. I can manually specify the switches, but the switches as defined in the config don't do anything at all for that
05:38:44FromDiscord_<Kaynato> `nvcc.exe -c -w -mno-ms-bitfields -arch=sm_61 --x cu -Xcompiler -fpermissive -DWIN32_LEAN_AND_MEAN -IE:\PROGRA~2\nim-1.0.2\lib -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\include" -IE:\Cloud\Sync\Sync\Dev\_Project\nim\aura\src -o C:\Users\main\nimcache\array_d\stdlib_sequtils.nim.cpp.o C:\Users\main\nimcache\array_d\stdlib_sequtils.nim.cpp` need to figure out how to not pass nvcc bad switches in meanwhile. think i'm gettin
05:39:48FromDiscord_<Kaynato> I am using `nim cpp --cincludes:"$CUDA_PATH/include" --cc:gcc --gcc.exe:nvcc.exe --gcc.linkerexe:nvcc --gcc.cpp.exe:nvcc --gcc.cpp.linkerexe:nvcc.exe --gcc.options.always:"-arch=sm_61 --x cu" --gcc.cpp.options.always:"-arch=sm_61 --x cu -Xcompiler -fpermissive" --listcmd array`
05:40:06FromDiscord_<Kaynato> not sure where I've gone wrong with the nim.cfg
05:40:12FromDiscord_<Kaynato> not sure where I've gone wrong with the nim.cfg that it won't pick those up
05:40:15FromDiscord_<Kaynato> not sure where I've gone wrong with the nim.cfg that it won't pick those up there
05:41:30FromDiscord_<demotomohiro> if you set cpu or os option, `gcc.cpp.exe` would be ignored. In that case, you have to set `cpu.os.gcc.cpp.exe`.
05:42:10FromDiscord_<Kaynato> How can I check if I've set cpu or os option?
05:45:35FromDiscord_<demotomohiro> If you have a line like `os="..."` or `cpu="..."` in cfg file, it is set
05:46:00FromDiscord_<Kaynato> Ah, there is none
05:46:39madpropshow can i divide a BiggestInt?
05:46:46madpropslet kb = info.size / 1024
05:46:50FromDiscord_<demotomohiro> When you run nim, it prints path to cfg file nim reads
05:47:55FromDiscord_<Kaynato> Ah. It apparently is only reading the default cfg, not the cfg for the package that has flags which should be activating
05:48:02FromDiscord_<Kaynato> wait
05:48:23FromDiscord_<Kaynato> Yes, that's right
05:51:39FromDiscord_<Kaynato> Ok. So, the behavior of flags, i.e. `-d:someflag` for some package can be defined in its package.nimble? Or am I completely wrong here
05:52:22FromDiscord_<Kaynato> via `template someflagSwitches(switches: var string)`
05:52:25FromDiscord_<Kaynato> via `template someflagSwitches(switches: var string)`?
05:52:57madpropsthere is no way to divide BiggestInt? / seems to require int
05:54:13FromDiscord_<Kaynato> div?
05:54:17FromDiscord_<Kaynato> re: biggestint, div?
05:55:38*sagax joined #nim
05:58:14FromDiscord_<Kaynato> wrt. the config file issue, I can put that aside for now, but I want to ask if there's a way to overwrite a switch or otherwise omit an option, specifically `-mno-ms-bitfields`
06:01:28*njoseph joined #nim
06:08:39FromDiscord_<Kaynato> no way to overwrite `gcc.cpp.options.always`?
06:10:05*narimiran joined #nim
06:12:14Zevvsealmove: isn't TRegister just the range of a register value?
06:13:30FromDiscord_<demotomohiro> `gcc.cpp.options.always = "..."` in cfg does'nt work?
06:13:46FromDiscord_<Kaynato> It keeps the old config, which includes `-mno-ms-bitfields`
06:14:00FromDiscord_<Kaynato> The new assignment only appends to the preexisting value
06:15:21sealmoveZevv: I see `if c.maxSlots+n >= high(TRegister): globalError(cc.config, cc.bestEffort, "VM problem: too many registers required")`
06:16:16sealmoveIt's the register index, not the value
06:16:37Zevvah ok. Well, if that solves your problem, great!
06:17:11sealmovejust increasing the number doesn't solve the problem
06:17:31sealmovethe algorithm assumes a small number, so VM freezes if you tweak it
06:19:41*njoseph quit (Ping timeout: 265 seconds)
06:21:24FromDiscord_<Kaynato> @demotomohiro Does doing that in cfg work for you (overwrites existing string)
06:31:04FromDiscord_<demotomohiro> I wrote `gcc.options.always = "-DAAA"` in nim.cfg in the same directory of test.nim.
06:31:04FromDiscord_<demotomohiro> Then `-w -mno-ms-bitfields` was replace with `-DAAA`
06:31:30sealmoveevery proc can use up to 256 registers
06:32:10sealmovethe error I get is:
06:32:20sealmovenpeg-0.21.1/npeg/codegen.nim(133, 15) Error: VM problem: too many registers required
06:33:16sealmoveSo there might be some issue with this code:
06:33:18sealmove let match = proc(ms: var MatchState, s: Subject, userDataId: var userDataType): MatchResult =
06:33:20sealmove # Create local instances of performance-critical MatchState vars, this saves a
06:33:22sealmove # dereference on each access
06:33:24sealmove var
06:33:26sealmove ip {.inject.}: range[0..count] = ms.ip
06:33:28sealmove si {.inject.} = ms.si
06:33:30sealmove simax {.inject.} = ms.simax
06:33:32sealmove # Debug trace. Slow and expensive
06:34:10FromDiscord_<Kaynato> in nim.cfg: `gcc.options.always = " -DAAA"`
06:34:29FromDiscord_<Kaynato> through --listcmd: `nvcc.exe -c -w -mno-ms-bitfields -DAAA `
06:35:51FromDiscord_<Kaynato> I wonder why it's appending. If I have another assignment in the same cfg it does override. But the default nim.cfg cannot be overridden.
06:48:30Zevvsealmove: so,does increasing that value fix your issue? I guess we need to increase regA size as well then to make that fit
06:48:41Zevvand probably b and c as well
06:49:06sealmovealready tried it :(
06:49:55Zevvah :)
06:50:04FromDiscord_<demotomohiro> `gcc.options.always = "-DAAA"` override option when I do `nim c test.nim`, but it was append when I do `nim cpp test.nim`.
06:51:27FromDiscord_<Kaynato> Interesting. I'm guessing it's not supposed to do that
06:51:52FromDiscord_<demotomohiro> Setting both `gcc.options.always = "-DAAA"` and `gcc.cpp.options.always = "-DAAA"` in nim.cfg override `-w -mno-ms-bitfields`.
06:51:53FromDiscord_<demotomohiro> But Nim hangs.
06:52:33FromDiscord_<Kaynato> Hanging not due to the invalid flag? Is it possible there is a resolution issue?
06:52:57FromDiscord_<demotomohiro> It seems in `cpp` command, `gcc.options.always` and `gcc.cpp.options.always` are merged.
06:54:45*endragor quit (Ping timeout: 246 seconds)
06:55:43FromDiscord_<demotomohiro> I think it hangs because g++ output large message.
06:55:44FromDiscord_<demotomohiro> https://github.com/nim-lang/Nim/issues/8648
06:55:46disbot➥ Nim compiler hangs for certain C/C++ compiler errors; snippet at 12https://play.nim-lang.org/#ix=22SM 😏
06:55:51FromDiscord_<Kaynato> I've got to go to bed now, it is quite late (almost 2 AM) but thank you for the help. Trying to manually compile the files has actually thrown its own share of errors (only on some of the nim stdlib, frustratingly enough), because nvcc and cl don't like `N_LIB_PRIVATE N_NOINLINE(void, raiseEIO__ZYk14k3sVNZUIjJjtqzFZQ)(NimStringDesc* msg) __attribute__((noreturn));`
06:56:17FromDiscord_<Kaynato> Oh wait. Is that what I think it is
06:57:29FromDiscord_<Kaynato> ...apparently not
06:58:19FromDiscord_<Kaynato> Yep, the output large message hang is forever a bane to speedy diagnosis here 😔
07:00:20FromDiscord_<demotomohiro> I can see outputs from g++ when I terminate cc1plus.exe
07:00:56FromDiscord_<Kaynato> Thank you tremendously for the help, hopefully tomorrow (today) I'll be able to make more progress on this
07:01:36FromDiscord_<demotomohiro> It seems when I override default gcc.options.always, g++ output large amount of warnings but there is no errors.
07:01:36FromDiscord_<Kaynato> if you get a chance, I'm trying to compile https://forum.nim-lang.org/t/3171#20029 on windows
07:01:43FromDiscord_<Kaynato> oh, that would be `-w`
07:01:50FromDiscord_<Kaynato> oh, that would be `-w` for `no warnings`
07:04:14*uu91 quit (Ping timeout: 276 seconds)
07:04:33*Jjp137 quit (Read error: Connection reset by peer)
07:04:35*uu91 joined #nim
07:09:31*Jjp137 joined #nim
07:17:32*endragor joined #nim
07:20:28*solitudesf joined #nim
07:22:45*njoseph joined #nim
07:26:19*PMunch joined #nim
07:27:02*LargeEpsilon joined #nim
07:30:08*JustASlacker joined #nim
07:39:03*JustASlacker quit (Ping timeout: 245 seconds)
07:48:02*ftsf joined #nim
07:53:18*ftsf quit (Quit: Leaving)
08:00:00*gmpreussner quit (Quit: kthxbye)
08:04:50*gmpreussner joined #nim
08:06:32*solitudesf- joined #nim
08:09:16*solitudesf quit (Ping timeout: 268 seconds)
08:11:28*NimBot joined #nim
08:21:17PMunchHmm, I consider pitching a talk on running Nim everywhere
08:21:42PMunchLike how it's possible to run it on everything from microcontrollers, as a DLL, or even as JavaScript on a web-site
08:26:39Zevvand where will you be holding this talk? At fosdem, for which the talk registration just closed yesterday? :)
08:27:15Zevvhow is nim treating you on the atmel? Have things improved enough to make this usable?
08:28:35narimirani've never seen a conference which doesn't introduce new deadline after the original one passed. (at least in academia)
08:29:06narimirani'd say that 90% of people are counting on that second deadline
08:30:10ZevvI never learned to do talks properly. Sometimes feel sorry about that, but not too much.
08:39:50*floppydh joined #nim
08:43:32PMunchZevv, deadline for our room is today :)
08:43:53Zevvoh right :)
08:44:30PMunchAnd I've just been running it on the Arduboy emulator, the Arduboy is essentially just an Arduino Leonardo with a screen and some buttons
08:44:33PMunchAnd battery and such
08:45:05PMunchIt works pretty well as far as I can tell, but I'm porting a larger example now to see if everything is working as it should :)
08:46:23Zevvwas the constants-copy-to-C-varaibale already solved?
08:50:52Zevvusing --gc:arc?
08:51:01narimiranZevv: what to do with https://github.com/nim-lang/Nim/pull/12712 ? it breaks npeg
08:51:02disbot➥ introduce capture macro; snippet at 12https://play.nim-lang.org/#ix=22Eq 😏
08:51:27Zevvnarimiran: so sweet if you to complain about Nim PRs when they break NPeg :)
08:52:16ZevvI do like `capture` over `closureScope` tho
08:53:28ZevvI would even like more to Nim always capture everything implicitly, but I expect there are Reasons No To Do that
09:00:55narimiranZevv: can you tell why npeg is failing? can/would you modify it?
09:03:14*JustASlacker joined #nim
09:10:15*Hideki_ joined #nim
09:11:19*lritter joined #nim
09:12:51Zevvi dont know and didn't try yet
09:14:17*Hideki_ quit (Ping timeout: 240 seconds)
09:33:13*clyybber joined #nim
09:39:03Zevvlets see then, yet another remote in my nim repo would not hurt I guess
09:42:13Zevvhm you got a sec narimiran?
09:43:47ZevvI have a macro that converts `$1` to `capture[1].s` - this fails because the `capture` referenced is not my capture but the new introduced macro. However, if I type `capture[1].s` directly instead of `$1`, it works fine.
09:43:53ZevvSo it binds to the wrong thing
09:44:33narimiranyeah, i have more than a sec, but i might not be the right man for those kinds of questions....
09:45:21Zevvwho should I ping for this kind of things?
09:46:04*JustASlacker quit (Ping timeout: 265 seconds)
09:46:07clyybberuse bindSym?
09:46:59narimiranZevv: maybe krux02 when he comes online
09:47:48Zevvclybber: it's this thingy: https://github.com/zevv/npeg/blob/master/src/npeg/codegen.nim#L45
09:49:44Zevvthe problem is probably that it now binds early because it can now find a symbol with that name
09:50:39clyybberah yeah
09:51:05clyybbermaybe that could work: https://nim-lang.github.io/Nim/macros.html#BindSymRule
09:51:51clyybbersetting it to forceOpen?
09:52:22Zevvhm I have no clue how to use that, I'll dig for some examples
09:52:30clyybberZevv: Wait
09:52:42clyybberThe issue is just due to the quote do
09:52:44clyybberright?
09:53:48ZevvWell, not "just". The issue is that the macro transforms the `code` NimNode, but seems to be tirgger happy to bind. So when this `code` is later used in the `quote do` it assumes its already bound to the wrong thing.
09:53:58Zevvbut it's not caused by the quote-do per se
09:54:23Zevvthe `capture` it should use does not exist at the time of rewriting the dollar-expression
09:54:35Zevvthat only lives in the quote do scope
09:55:20clyybberand instead it uses this one: https://github.com/zevv/npeg/blob/master/src/npeg/codegen.nim#L5 ?
09:55:46Zevvright. So it's not a problem of that commit, it's a problem of NPeg with the way it uses this rewriting. Anything else in scope with the same name will break as sweet.
09:56:30ZevvSo I guess I need to tell this rewriter somehow not to resolve the symbol at that time
09:57:32ZevvIt feels like "A symbol can be forced to be open by a mixin declaration"
09:57:39Zevvbut "mixin statements only make sense in templates and generics"
10:01:37*abm quit (Ping timeout: 240 seconds)
10:01:42*a_b_m joined #nim
10:02:06*a_b_m quit (Client Quit)
10:07:40*letto quit (Quit: Konversation terminated!)
10:09:11*letto joined #nim
10:09:55*sentreen_ quit (Ping timeout: 250 seconds)
10:10:26*letto quit (Client Quit)
10:11:09*sentreen_ joined #nim
10:11:51*letto joined #nim
10:14:19clyybberAraq: paramTypesMatch/paramTypesMatchAux isn't supposed to mutate its parameters right?
10:14:29clyybberBecause it does. In a very bad way.
10:14:54clyybbercausing #12713
10:14:55disbothttps://github.com/nim-lang/Nim/issues/12713 -- 3A few bugs related to static parameters; snippet at 12https://play.nim-lang.org/#ix=22E4 😏
10:15:06*clyybber pats disbot
10:15:28Araqclyybber, yeah well
10:15:43Araqnothing surprising here, I know the bug
10:15:49Araqtried to fix it but it's hard
10:16:12clyybberIn your static fixes branch?
10:16:40Araqwhat branch? dunno
10:16:59clyybberThis commit: https://github.com/nim-lang/Nim/commit/0922f4a512035c3f6b9eb298d05ab9bd6c84d505#diff-cb1ae2f19ab4f17b110ff3805148bb5bL1238
10:17:04clyybberremoves the offending else branch
10:21:51Araqyeah well, that's 4 years old
10:22:37*tklohna joined #nim
10:23:01clyybberwouldn't it be enough to simply deepcopy paramTypesMatch's args?
10:23:12clyybberAraq: Regardless of efficiency, would it solve the issue?
10:23:21Araqno.
10:23:34clyybberSo they are supposed to mutate their params?
10:23:36Araqother parts now rely on the mutation
10:23:40clyybberAh
10:23:59Araqin particular, we resolve tyTyped/tyUntyped in this way
10:24:28Araqthe good news is that nothing of this would pass today's review or development process
10:24:40clyybber:)
10:25:13clyybberAraq: I may try doing your static fix from 5 years back again. WDYT?
10:25:29Araqgive it a try but don't get depressed
10:25:44Araqso ... I wrote a cycle collector based on Lins's work from 2008
10:27:24clyybberAraq: And? How does it fare?
10:27:44FromDiscord_<demotomohiro> @Araq How did you find out this mistake (len(s) in comment was changed to s.len) from this large PR?
10:27:44FromDiscord_<demotomohiro> https://github.com/nim-lang/Nim/pull/12718
10:27:46disbot➥ Cosmetic compiler cleanup
10:30:03*solitudesf- quit (Ping timeout: 265 seconds)
10:32:23*JustASlacker joined #nim
10:34:45FromDiscord_<demotomohiro> Just reading all diff of this PR to find mistake would take very long time.
10:36:42FromDiscord_<Rika> maybe grep?
10:37:24FromGitter<gogolxdong> How to instantiate `proc newAEAD*[T](HashType: typedesc, connectionId: string, pers: int = PerspectiveClient, myhp: var string): AeadAESGCM[T] =` ⏎ with T could be aes256, typedesc could be sha256?
10:37:28FromGitter<alehander92> i guess he might have guessed it can happen in comments
10:37:39AraqI simply read the diff
10:37:43stefantalpalaruWhy is "csize" (size_t) defined as an "int" here: https://github.com/nim-lang/Nim/blob/97e0ce3c75c9348226ea1fcdfc601c6fbe5c0e75/lib/system.nim#L2255
10:38:01Araqstefantalpalaru, legacy, fixed on devel
10:38:16stefantalpalaruOK
10:38:29*Vladar joined #nim
10:42:46ZevvAraq: can I bother you a sec? I have a proc for rewriting NimNodes that rewrites to an identifier that does not yet exist at that point - works ok. Now due to circumstances the differnt symbol with the same name is defined before that proc, which seems to cause an early bind to the wrong thing.
10:43:10ZevvSo how can I avoid that proc to be bound/resolved too early? Does that question make sense?
10:43:42*ng0 joined #nim
10:50:17FromDiscord_<demotomohiro> @Araq I thought you used some tools. That sound like you have a great skill to read large diff.
10:51:01AraqZevv, can't you ensure a unique name instead?
10:51:54*Hideki_ joined #nim
10:53:07ZevvWell, something else anywhere can come up with the same name - which is what now happened
10:53:37ZevvWhat I basically want is where the rewritten NimNode is *used*, normal scoping rules apply and the innermost thing with that name is used
10:55:25*clyybber quit (Read error: Connection reset by peer)
10:55:31*clyybber1 joined #nim
11:02:18*clyybber1 is now known as clyybber
11:04:21Araqare you looking for gensym?
11:05:18Zevvmaybe, let me check
11:06:11*Hideki_ quit (Remote host closed the connection)
11:07:02Zevvnah, also not. More details: In my code block I can use `capture[1].s`, which works ok even if there is another `capture` defined somewhere else. I provide this simple rewrite so the user can write `$1` instead. The proc rewirtes `$1` to `capture[1].s`, so it generates the exact same AST according to repr - but the one works and the other doesn't
11:07:28ZevvI can not generate a random unique id since `capture[]` should still be avaiable as well
11:08:19AraqI think it's fine to not do anything about it
11:08:42Araqnpeg users know about 'capture' in the scope and must not use the name themselves
11:11:30Araqclyybber, too early for performance measurements
11:13:06ZevvAraq: right, but the name is now introduced by a Nim PR: https://github.com/nim-lang/Nim/pull/12712
11:13:08disbot➥ introduce capture macro; snippet at 12https://play.nim-lang.org/#ix=22Eq 😏
11:13:10Zevvand npeg goes *boom*
11:13:26Araqouch
11:15:50*solitudesf joined #nim
11:16:07*LargeEpsilon quit (Ping timeout: 268 seconds)
11:18:33*LargeEpsilon joined #nim
11:27:46Zevvso, any ideas more then welcome :)
11:31:46*krux02 joined #nim
11:33:14*rockcavera joined #nim
11:36:50*letto quit (Quit: Konversation terminated!)
11:38:16*Hideki_ joined #nim
11:38:21*letto joined #nim
11:38:57*sagax quit (Ping timeout: 240 seconds)
11:40:17*Jjp137 quit (Ping timeout: 240 seconds)
11:41:56Zevvhm ok, solved. `quote do` did nog generate the AST I expected, it had an unintend nnkOpenSymChoice() in there
11:42:44*Jjp137 joined #nim
11:52:32clyybberAraq: Since procvar is on by default now, should I remove occurences of it in the compiler code?
11:54:15Araqdunno, it might still be useful for preventing map(x, system.`+`)
11:54:46Zevvnarimiran: fixed in NPeg
11:54:49Zevvfwiw
11:55:28clyybberAraq: Ah, I meant literal `{.procvar.}` pragmas on the procs used in the compiler
11:55:46clyybberFor the cleanup PR
11:56:31*Hideki_ quit (Ping timeout: 250 seconds)
12:01:01Araqok
12:02:29clyybberZevv: So it *was* the quoted do, huh?
12:04:21Zevvyeah, sorry for not listening to you
12:04:34ZevvI looked at 'repr' but that hid the nitty gritty details what astGenRepr showed
12:05:33clyybberhehe
12:07:32*endragor quit (Remote host closed the connection)
12:35:45*nif quit (Quit: ...)
12:35:55*nif joined #nim
12:40:12PMunchHmm, what is the proper way to call NimMain when --noMain is defined?
12:40:50PMunchCurrently I just have "proc NimMain() {.importc.}" at the top of my file and then call it when my code is first run, but is there a better way of doing this?
12:45:21*sagax joined #nim
12:48:56*leorize quit (Ping timeout: 260 seconds)
12:51:04*leorize joined #nim
13:01:11*Hideki_ joined #nim
13:13:21FromDiscord_<Delta231> is nim forum made with nim?
13:13:40FromGitter<alehander92> yes
13:13:56FromDiscord_<Delta231> how much time did it take to make it
13:18:54AraqI think a month
13:21:09*Hideki_ quit (Ping timeout: 265 seconds)
13:24:10*nif quit (Quit: ...)
13:24:50*nif joined #nim
13:44:36rockcaveraI have code that compiled with "nim c -d:danger -d:release umain2" takes 13s to execute, but memory usage reaches 246MB. Compiling with "nim c -d:danger -d:release --gc:boehm umain2" the memory usage is no more than 2.2MB, but it takes 109s to execute. I tested with the boehm GC because I suspected that Nim's GC was leaking memory. I am using devel version 2019-11-25.
13:45:28dom96Araq Delta231: the new redesigned forum took almost exactly 2 weeks.
13:45:32rockcaveraI believe the memory leak is in the recursion association with seqs.
13:47:03*lbartoletti joined #nim
13:47:18clyybberrockcavera: Maybe its just the CG being lazy?
13:47:53*lbart quit (Ping timeout: 276 seconds)
13:48:04rockcaveracan be, clyybber
13:49:12*Hideki_ joined #nim
13:59:25rockcaveraclyybber That's right, because using GC_fullCollect() there's no memory lift
14:09:43*krux02_ joined #nim
14:11:43*krux02 quit (Ping timeout: 250 seconds)
14:14:03*nif quit (Quit: ...)
14:14:13*nif joined #nim
14:19:27dom96Anyone else want to submit a Nim-related talk for our co-opted FOSDEM devroom? Deadline is today https://forum.nim-lang.org/t/5577
14:19:44dom96@mratsim: can you ping the other Status people about this? ^
14:19:56PMunch:D
14:20:36dom96(talks on other emerging languages are fine too)
14:20:40PMunchHmm, I have a weird thing happening when compiling for this arduino based board. When I enable -d:release the binary becomes almost twice the size
14:21:03dom96btw perfect length for these talks is 15 minutes (+5 for questions)
14:21:40FromDiscord_<treeform> How many talks do we have?
14:22:27PMunch6 submitted Nim talks so far. But 3 are by dom and 2 are by mratsim I think, so I think they would prefer to not hold all the talks :P
14:23:19zedeusisn't it only one per person? seemed that way from the forum posts
14:24:49Zevvone is by dom, one is by dom with a fake moustache. one is by dome with a green wig. one by mratsim and one by mratsim with doms fake moustache
14:24:59zedeuslol
14:25:14zedeuswouldn't mind that, all the talks sound interesting
14:26:11PMunchHaha, now I just imagine someone walking off the podium, the room organiser coming on and presenting the next talker, and the same guy coming up with a huge fake mustache :P
14:26:56dom96now, that is an idea :D
14:29:32PMunchNice, threw on some of the flags that the Arduino compiler users and my Nim-reimplementation is now 48K vs the 42K of the normal version
14:31:16FromGitter<Willyboar> @alehander92 How are you?
14:32:58floppydhanyone got nim7z running? - seems they changed how nimble works and now it does pretty much nothing on install :(
14:33:48dom96regression in Nimble?
14:33:59dom96please report it if you haven't already
14:34:36floppydhsure thing
14:34:48floppydhto be fair the lib hasn't been updated in a year
14:39:01*njoseph quit (Ping timeout: 250 seconds)
14:43:11floppydhI'll report it right away, but in short: there's some logic in the nimble 'setup'-task that checks out the 7z repo I think and then uses 'c2nim' to generate wrapper-code, which all seems to work fine if on 'nimble install nim7z'
14:43:51floppydhbut then if I check the ~/.nimble/pkgs/nim7z... directory the directory in which the wrapper and 7z c code should be checked out is empty
14:44:41*endragor joined #nim
14:45:59FromGitter<Willyboar> @disruptek a nice feature will be disbot to post every time an issue or PR opened, closed, merged etc. I don't know if it is supported from github API but I have seen it in some gitter channels in the activity section.
14:46:26*njoseph joined #nim
14:48:50*endragor quit (Remote host closed the connection)
14:50:35*endragor joined #nim
14:51:37rockcaveraI solved my problem without having to manually work with the GC. I began to set the initial size of the seqs to 0. There was no loss of speed and no more absurd memory allocations occurred.
14:51:40rockcaveraxD
14:53:54*ng0_ joined #nim
14:54:54floppydhdom96: https://github.com/genotrance/nim7z/issues/1
14:56:20*ng0 quit (Ping timeout: 260 seconds)
14:56:55*Hideki_ quit (Remote host closed the connection)
14:57:05*ng0_ is now known as ng0
14:57:41*Hideki_ joined #nim
14:59:57PMunchHmm, when I strip this binary it just randomly freezes on me..
15:02:42disruptekWillyboar: yeah, we talked about doing that in a #nim-news channel.
15:04:54Araqrockcavera, sounds weird
15:05:21FromGitter<Willyboar> Great
15:07:08*PMunch quit (Quit: Leaving)
15:08:55clyybberAraq: For the future, do we want implicit statics or static evaluation on demand?
15:09:42*endragor quit (Remote host closed the connection)
15:10:17*fox_0x00 joined #nim
15:13:28*kcvinu joined #nim
15:13:41kcvinuHi
15:14:11kcvinuDoes "Times.fractional" deprecated ?
15:17:29clyybberseems like it
15:17:31*dddddd joined #nim
15:17:44kcvinuThen whats the alternatives ?
15:19:42rockcaveraAraq, What sounds weird?
15:20:15clyybberIs there a callgraph visualizer for nim?
15:26:21*seni joined #nim
15:29:48*JustASlacker quit (Remote host closed the connection)
15:30:40*Hideki_ quit (Remote host closed the connection)
15:31:39*Hideki_ joined #nim
15:36:05*Hideki_ quit (Ping timeout: 252 seconds)
15:36:19*kcvinu quit (Ping timeout: 260 seconds)
15:36:57*tklohna quit (Ping timeout: 246 seconds)
15:37:36sealmoveAraq: new problem with the VM, now it complains about using too many registers :D should I give up and stop stressing it too much? or this trivial to solve?
15:41:34*norm joined #nim
15:41:45Zevvsealmove: I'll take a look after diner if it is related to the VM stuff we've been doing at all
15:41:57*norm is now known as Guest46073
15:42:41sealmoveThanks (of course it's related)
15:43:33*Vladar quit (Quit: Leaving)
15:45:09Araqclyybber, the spec says that f(a, b) is evaluated iff 'f' is noSideEffect and 'a' and 'b' are known
15:45:13Araqand it's a good rule
15:45:27Araqother evaluations must be triggered by a 'static' block
15:45:37Araqbut then this cannot be used in overload resolution
15:45:48AraqI mean
15:45:56Araqyou can disambiguate in OR
15:46:08Araqbut you cannot trigger static evaluating during OR
15:46:43Araqseems like a good set of rules avoiding the current set of problems (but maybe it has different problems)
15:46:55Araqsealmove, are you on Nim devel?
15:47:05sealmoveAraq: sure
15:52:06Araqok cause on devel the VM generator actually reuses registers :P
15:58:40sealmove if c.maxSlots >= high(TRegister):
15:58:41sealmove for i in start .. c.maxSlots-1:
15:58:43sealmove if not c.slots[i].inUse:
15:58:45sealmove c.slots[i] = (inUse: true, kind: k)
15:58:47sealmove return TRegister(i)
16:00:15sealmoveseems all slots are inUse :S
16:01:44shashlickfloppydh: ya you will need to run nimble setup before running nimble install
16:01:58shashlickElse nimble doesn't install the generated files
16:02:30floppydhshashlick: that is not the issue tho
16:02:41floppydhmethinks
16:02:50floppydhoh
16:03:11shashlickhttps://github.com/nim-lang/nimble/issues/549
16:03:50shashlickNimble creates the list of files to install before running the before install hook
16:04:09floppydhyeah
16:04:10shashlickSo the generated files never get copied over
16:04:12floppydhexactly
16:04:20floppydhthe setup task is executed, as I can see that in the output
16:04:25floppydhit seems it's just not taken along with the rest
16:04:54floppydhthis is not the only repository
16:04:56floppydhwhere this is an issue
16:05:39floppydhcan't remember the other one, have to look it up once I'm home
16:05:47floppydhoh right
16:05:57shashlickYes almost all nimgen projects are broken because of this
16:06:24floppydhthis also didn't work through nimble, but unsure if this due to `.gitmodules` https://github.com/OpenSystemsLab/xxhash.nim
16:06:50floppydhunsure if nimble cares for git submodules
16:07:06floppydhshashlick:what's the fix for the not-copying-over thing?
16:07:14floppydhoh I see it's open
16:07:19floppydhstill, the issue
16:07:23shashlickThere's no fix yet
16:07:50floppydhthere's apparently simple workarounds in the commentsß
16:07:52floppydh?
16:08:21floppydhoh wait
16:09:26shashlickI've tried all sorts of tricks, most don't work
16:09:40floppydhoh
16:09:50floppydhyou can just not use `nimble install X`
16:09:59floppydhand install in the cloned dir via `nimble install -y`
16:10:13floppydhguess I'll go with that
16:11:26*Hideki_ joined #nim
16:11:32shashlickCool
16:13:49*kcvinu joined #nim
16:14:29kcvinuWhats the alternative for fractional ?
16:14:36disruptektotal.
16:15:07kcvinui mean times.fractional
16:17:35Zevvsealmove: can you get me a simple reproducable thing for the registers?
16:21:26*floppydh quit (Quit: WeeChat 2.6)
16:24:59*Guest46073 quit (Quit: Leaving)
16:25:11*LargeEpsilon quit (Ping timeout: 276 seconds)
16:32:26*kcvinu quit (Remote host closed the connection)
16:34:00*Hideki_ quit (Ping timeout: 265 seconds)
16:39:57*njoseph quit (Ping timeout: 240 seconds)
16:46:03sealmoveZevv: I'll try later
16:52:57*LargeEpsilon joined #nim
17:12:27*njoseph joined #nim
17:15:44clyybberAraq: Sigmatch really deserves a refactoring :D
17:21:09clyybberOr maybe I'm just too dumb to grok it
17:21:55*nif quit (Quit: ...)
17:22:06*nif joined #nim
17:34:11sealmoveZevv I think the problem is injecting too many variables, trying to reproduce now
17:34:22ZevvI just created a macro that creates a 1000 ints without problems
17:34:44Zevv10_000 even
17:35:07Zevvso first we should try to understand how register allocation even works
17:35:17*sagax quit (Ping timeout: 240 seconds)
17:37:19*njoseph quit (Ping timeout: 265 seconds)
17:42:53Zevvah got it
17:42:56Zevvneed to put it in a proc
17:43:32Zevv-> http://ix.io/22Vg
17:44:41Zevvwell, that works
17:44:58rockcaveraWhen I pass --cc:clang to the nim compiler, can I know from my code which cc is being used?
17:47:25sealmoveyup
17:48:00Zevvsealmove: I think I got it fixed.
17:48:03sealmoveso is it possible to tweak npeg (the match proc) so that it doesn't inject more than 255 symbols?
17:48:05Zevvchange regA B and 16 to 16 bits
17:48:12Zevvand TRegister* = range[0..regAMask]
17:48:40Zevvfixed at the Nim VM
17:48:51Zevvit just fits in where we updated stuff yesterday
17:49:02rockcaveraow, I found it already
17:49:03Zevvnow there are 65536 regisrers
17:49:05FromGitter<alehander92> @Willyboar
17:49:08FromGitter<alehander92> good
17:49:13FromGitter<alehander92> thank you how are you
17:50:22*LargeEpsilon quit (Ping timeout: 265 seconds)
17:50:49clyybberZevv, sealmove: Did this register issue only pop up because of the 64bit rework or because the 64bit rework allows so large procs that its reached?
17:51:05Zevvsecond
17:51:14clyybbernice
17:51:21sealmoveI think it was a problem before the rework
17:51:21ZevvAraq recently added some stuff to reuse registers, then we hit the relative max jump distance
17:51:24*fox_0x00 quit (Quit: leaving)
17:51:33Zevvwith that fixed we now hit register usage again
17:51:47ZevvBut all I had to do is increased regA,B,C to 16 bits and it Just Works
17:52:11clyybberNICE
17:52:16Zevvrunning vm/ tests now
17:52:16sealmovethis is like karate-kid pressure for the VM lol
17:52:53Zevvits a bit of a waterbed when things are limited. You push here and it pops up there
17:53:02Zevv"65536 registers should be enough for everyone"
17:53:21Zevvvm tests passed, will check it in on the same branch
17:53:53ZevvSo, all we now need to do is adding 3142 casts/conversions to make sure it works out on 32bits
17:54:06sealmovedoes TDest need to change too?
17:54:36ZevvNo clue, what is it?
17:54:54sealmoveseems to be used alongside TRegister
17:55:42Zevvhmm will update that as well
17:55:50Zevvjust give it a spin if you have time for it
17:55:55sealmovenot sure why it's a seperate type
17:56:03clyybberZevv: what?
17:56:05sealmoveyes I am running stuff
17:56:07FromGitter<Willyboar> Nice @alehander92 spending time with the kids, read about nim and search about frameworks
17:56:13clyybberwhy 3142 conversions?
17:56:22Zevvoh maybe 1692 or only 321
17:56:27clyybberwhy?
17:56:42ZevvI started adding in a few and then I went down the rabbit hole of things not compiling
17:56:49Zevvso I stopped it because I got bored
17:57:06clyybberbut why do you need conversions at all?
17:57:31Zevvstuff boils down to `int` by default, but the VM TInstr type is now bigger
17:57:37Zevvso lots of stuff does not compute on 32 bits
17:57:45Zevvunless things are made explicitly int64
17:58:01clyybberbut why does that leak out of the VM?
17:58:26Zevvit doesn't really, but yesterday I did a quick try to fix this, and then I had to change more and more and more
17:58:37Zevvit doesn't leak out the VM, true
17:58:37clyybberin which files?
17:58:40Zevvvm*
17:58:49Zevvnot even. mostly vmdefs
17:58:58Zevvvmdef
18:01:36*leorize quit (Ping timeout: 260 seconds)
18:02:11FromGitter<alehander92> @Willyboar love it
18:02:15FromGitter<alehander92> take care
18:02:21FromGitter<alehander92> which frameworks did you read for
18:04:09*leorize joined #nim
18:05:27FromGitter<Willyboar> i think all of them
18:06:05FromGitter<Willyboar> i think the only one is close to let's say is close to rails/django/phoenix is xander
18:12:33*mike32 joined #nim
18:12:47*rockcavera quit (Remote host closed the connection)
18:19:36*lbartoletti is now known as lbart
18:24:08*mike32 quit (Remote host closed the connection)
18:30:16FromGitter<alehander92> yeah it looks nice
18:30:52sealmoveZevv did you do any tests? The compiler hangs when I change TRegister. Sorry for not being useful, no time today for investigation.
18:33:14FromGitter<Willyboar> I think he abandoned it
18:34:00*rockcavera joined #nim
18:35:47Zevvsealmove: Works For Me
18:42:37lqdev[m]is it possible to pass -O0 to cc from Nim?
18:56:11sealmoveZevv: I get: npeg-0.21.1/npeg/codegen.nim(141, 28) Error: interpretation requires too many iterations;
18:56:19sealmovevm must get stuck somewhere
18:57:14sealmoveline is: `simax {.inject.} = ms.simax`
18:57:20sealmoveso something to do with the injection
19:04:45*uu91 quit (Read error: Connection reset by peer)
19:05:02*uu91 joined #nim
19:05:05*uu91 quit (Read error: Connection reset by peer)
19:05:49*uu91 joined #nim
19:15:29*njoseph joined #nim
19:17:32ehmrymy nim doc/nimble doc is producing empty HTML files, has anyone else seen this?
19:18:06Araqno
19:18:43ehmryits caused by using a wrapper script, which is entirely my fault
19:37:51*NimBot joined #nim
19:46:50clyybberAraq: Those rules sound good. We should add that all literals are static T, not sure how its done rn..
19:48:06*ncharlie joined #nim
19:48:37ncharliehey folks -- I'm trying to set up idetools with vim, but for some reason the latest build of nim doesn't seem to have the idetools subcommand anymore
19:48:48ncharliedid that get moved out into the standalone nimsuggest tool?
19:49:56ncharlie(I ask because there's still a docpage on idetools, which confused me)
19:56:58Araqclyybber, they should *match* a static T but not be a static T
19:57:18Araqbecause 'static T' is actually really only a parameter mode like 'sink' is
19:57:40clyybberhmm
19:57:46Araqwell currently it's allowed elsewhere but think about it, what does 'myObjectField: static string' mean anyway...
20:00:36*nsf quit (Quit: WeeChat 2.6)
20:03:59Zevvsealmove: send me your parser then
20:04:29clyybberAraq: I guess its like a generic param of the type
20:19:15clyybberzah: WDYT about the rules Araq proposed here: https://irclogs.nim-lang.org/26-11-2019.html#15:45:09
20:24:51FromDiscord_<sealmove> Zevv it's in sealmove/nimitai/nimitai/private/ksypeg.nim
20:24:54*Ven`` joined #nim
20:26:13FromDiscord_<sealmove> I've made some change locally, and not home atm to push them, but maybe this older version behaves the same.
20:30:23*ncharlie quit (Quit: leaving)
20:31:02*Hideki_ joined #nim
20:32:31*MnlPhlp joined #nim
20:35:39*Hideki_ quit (Ping timeout: 250 seconds)
20:46:25*LargeEpsilon joined #nim
20:50:50*LargeEpsilon quit (Ping timeout: 250 seconds)
20:51:11*NimBot joined #nim
20:59:19sealmoveZevv: ok I pushed changes, this is the parser: https://github.com/sealmove/nimitai/blob/master/nimitai/private/ksypeg.nim
21:01:25Zevvok I pulled, how do I reproduce?
21:01:33Zevv nim c ksypeg.nim
21:01:34Zevv?
21:08:29*narimiran quit (Quit: leaving)
21:11:06FromDiscord_<Kaynato> Is the equivalent call of c++ std::vector<SomeClass> someVector (someDynamicSize) roughly going to be a custom seq with an UncheckedArray backing the data if the data is passed around often in the c++?
21:11:26*uu91 quit (Ping timeout: 265 seconds)
21:11:46*uu91 joined #nim
21:11:52FromDiscord_<Kaynato> I am getting "invalid type: UncheckedArray[SomeObject]' in this context: 'someVector' for var"
21:19:09*rockcavera quit (Remote host closed the connection)
21:19:26FromDiscord_<Kaynato> Nevermind, that's been solved
21:24:37*lritter quit (Ping timeout: 240 seconds)
21:26:56*MnlPhlp left #nim ("WeeChat 2.6")
21:28:12*nif quit (Quit: ...)
21:28:21*nif joined #nim
21:33:08*nif quit (Client Quit)
21:33:18*nif joined #nim
21:36:33*nif quit (Client Quit)
21:36:43*nif joined #nim
21:50:47FromDiscord_<sealmove> Zevv, import nimitai and call generateParser(), then nim c -r
21:54:37FromDiscord_<sealmove> I dont know if simply compiling ksypeg.nim triggers it
21:56:09*NimBot joined #nim
22:11:05Zevvdo you have something I can parse?
22:14:00ZevvOk, I found an example. This works, don't get VM outages anymore
22:14:05*norm joined #nim
22:14:05Zevvback to the 'too many iterations'
22:14:28*norm is now known as Guest26634
22:16:36Zevvset iterations to 100M, but this is unbearibly slow
22:17:04*Guest26634 quit (Client Quit)
22:17:12ZevvI guess your parser is not ok
22:18:27Zevvit stops consuming input after the first newline
22:19:23Zevvbut I think that's a grammar issue
22:19:33Zevvthe VM now runs fine, but bails out because the program takes too long
22:27:17*Jesin quit (Quit: Leaving)
23:07:55FromDiscord_<Generic> is it a known issue that if you iterate over a large array (about 1/4mb) it gets copied completely onto the stack which ends up crashing the whole application?
23:08:09FromDiscord_<Kaynato> If it's ok, I'd like to ask for a sanity check... for some x: seq[SomeObjType], is x[0].addr equivalent to data() from std::vector ? I haven't used either c++ before, and I am also new to nim. Sorry if this is a simplistic question.
23:08:16FromDiscord_<Generic> yes
23:08:20FromDiscord_<Kaynato> thanks!
23:08:57FromDiscord_<Generic> if you're very very sure the data won't be modified there's unsafeAddr
23:09:21FromDiscord_<Generic> it even works with non mutable objects
23:09:24FromDiscord_<Generic> like parameters
23:09:34FromDiscord_<Generic> or let variables
23:09:39FromDiscord_<Kaynato> Ah, I have to pass the address in because it's a c++ function that presumably modifies the memory at that location
23:10:13FromDiscord_<Kaynato> Not sure if it's the binding library's issue for being structured like that, or if it's an unavoidable consequence of interfacing with that sort of c++
23:10:27FromDiscord_<Kaynato> so I should use unsafeAddr for all of those scenarios?
23:10:27FromDiscord_<Generic> then using addr is correct
23:10:41FromDiscord_<Generic> unsafeAddr is useful when making C/C++ interfaces
23:10:59FromDiscord_<Generic> and you are sure the library won't modify the data
23:11:55FromDiscord_<Kaynato> Ah, ok. And for a function that returns an arbitrary unknown function, in the case where I need to be sure it will return a function of a specific type, I should use cast[desiredProcType](procReturningProc(...)), right?
23:11:59FromDiscord_<Generic> otherwise you would have to create a new mutable object and copy all the there data
23:12:42FromDiscord_<Generic> an arbitrary unknown function?
23:12:48FromDiscord_<Generic> yes, I think so
23:12:56FromDiscord_<Generic> though you're responsible here
23:13:48FromDiscord_<Generic> if you mess up the function's probably going to be called anyway with nonsense parameters
23:14:03FromDiscord_<Generic> but you probably know that yourself
23:14:06FromDiscord_<Kaynato> Right, yep
23:15:10FromDiscord_<Kaynato> This is for porting a small vulkan compute example into nim, since I've completely given up on CUDA + nim in windows. Hopefully it goes well, thank you for your help
23:34:56clyybberKaynato: Which vulkan wrapper are you using?
23:38:23FromDiscord_<Clyybber> @Kaynato Because in my wrapper (https://github.com/Clyybber/vulkanim) I have a macro called vk that will load vulkan functions
23:39:38disruptekit's been 4 months since i spoke to a horse.
23:39:46disruptekoops; wrong window.
23:40:20clyybberwhich end of the horse?
23:40:46disruptekwell, i've spoken to numerous horse's asses during the last few months.
23:42:37clyybberass or horse?
23:43:40disruptekass to mouth.
23:43:51clyybberman of culture
23:44:25*abm joined #nim
23:48:29*solitudesf quit (Ping timeout: 276 seconds)
23:50:27*Jesin joined #nim