<< 08-04-2019 >>
00:05:39*rnrwashere quit ()
00:15:46ryukoposting(warning: anime ahead) I'm not the only one that sees this, right https://lewd.pics/p/tdOz.jpg
00:27:22*Snircle joined #nim
00:36:19FromDiscord<demotomohiro> @Zevv
00:36:19FromDiscord<demotomohiro> quote from 2.1 Execution Model in OpenGL 4.6 API Specification (February 2, 2019):
00:36:20FromDiscord<demotomohiro>
00:36:20FromDiscord<demotomohiro> > Data binding occurs on call. This means that data passed to a GL command
00:36:20FromDiscord<demotomohiro> > are interpreted when that command is received. Even if the command requires a
00:36:22FromDiscord<demotomohiro> > pointer to data, those data are interpreted when the call is made, and any subsequent
00:36:25FromDiscord<demotomohiro> > changes to the data have no effect on the GL (unless the same pointer is used in a
00:36:26FromDiscord<demotomohiro> > subsequent command).
00:36:27FromDiscord<demotomohiro>
00:36:30FromDiscord<demotomohiro> That means when you write buffer object with ``glBufferData`` or ``glBufferSubData``, memory area given to them doesn't need to be valid after they return.
00:36:31FromDiscord<demotomohiro>
00:36:33FromDiscord<demotomohiro> @liquid600pgm
00:36:35FromDiscord<demotomohiro> If you are using OpenGL core profile, you have to bind vertex array object before calling glDrawElements.
00:36:37FromDiscord<demotomohiro> Debug Output might also help.
00:36:39FromDiscord<demotomohiro> https://www.khronos.org/opengl/wiki/Debug_Output
00:42:21*rnrwashere joined #nim
00:43:16*noeontheend quit (Ping timeout: 264 seconds)
00:43:33FromDiscord<exelotl> ryukoposting: lmao
00:44:24FromDiscord<exelotl> my friend says the only language megumin knows is explosion
00:47:09ryukopostinglmao
00:47:39ryukopostingdoes anyone know where I can find the type definition for addTimer, or just a code snippet showing how it's used? I'm so confused
00:48:31ryukopostingnot type definiton for addTimer, type definition for Callback, sorry
00:48:44ryukopostingtrying to figure out how to use addTimer, or really just get a timed callback honestly
00:49:49disruptekyou mean async futures?
01:06:50*dddddd quit (Ping timeout: 250 seconds)
01:17:03*rnrwashere quit (Remote host closed the connection)
01:21:03*neceve quit (Remote host closed the connection)
01:51:10*dddddd joined #nim
02:06:56*banc quit (Quit: Bye)
02:10:37*arecacea1 quit (Remote host closed the connection)
02:10:55*arecacea1 joined #nim
02:12:24*rnrwashere joined #nim
02:28:19*banc joined #nim
02:30:50*I_Right_I quit (Remote host closed the connection)
02:35:13*drewr joined #nim
02:42:54*Jesin quit (Quit: Leaving)
02:45:06*Jesin joined #nim
02:51:34*noeontheend joined #nim
03:15:18*rnrwashe_ joined #nim
03:17:45*rnrwashere quit (Ping timeout: 250 seconds)
03:20:55*chimez joined #nim
03:21:03*chimez quit (Client Quit)
03:22:58*rnrwashe_ quit ()
03:23:54*rnrwashere joined #nim
03:23:54*rnrwashere quit (Client Quit)
03:38:56*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:42:48*dddddd quit (Remote host closed the connection)
04:01:53ryukopostingdisruptek yuh
04:02:48ryukopostingI've used the the async stuff before, but I can't find a type definition for Callback anywhere in the docs, even though https://nim-lang.org/docs/asyncdispatch.html#addTimer%2Cint%2Cbool%2CCallback uses it
04:06:10FromGitter<Varriount> ryukoposting: Oh good, your around
04:06:25*arecacea1 quit (Remote host closed the connection)
04:06:45*arecacea1 joined #nim
04:12:41ryukopostingyuh
04:14:39FromGitter<Varriount> ryukoposting: You're at the point where you need to sign AWS requests?
04:15:06ryukopostingyeah, we've got the v4 signing code almost finished or finished, v2 I believe is either starting or in progress
04:15:38ryukopostingbut the guy working on it is super busy rn
04:17:18FromGitter<Varriount> Uh, you know I have working v4 signing code, right?
04:17:42ryukopostingthe code you sent wouldn't compile
04:24:05FromGitter<Varriount> ryukoposting: Even the newer revisions? https://gist.github.com/Varriount/076f406c475b5369301a2fcd7b4527af
04:24:46ryukopostingyeach chief, what's utils
04:25:51FromGitter<Varriount> Utility functions required by aws.nim?
04:26:02FromGitter<Varriount> The gist has multiple files.
04:26:15ryukopostingaaaaaaaaah there it is
04:26:51ryukopostingalright I'm just dumb, I'll give it another shot then
04:27:09ryukopostingI also have actual code to test it out with now lol
04:28:22ryukopostingis nimcrypto actively maintained?
04:28:32FromGitter<Varriount> Last I checked, it was.
04:28:36ryukopostingnice
04:28:49FromGitter<Varriount> It was the only crypto implementation that allowed streaming data to be used.
04:29:28ryukopostingok and calculate_signature is sample code
04:29:33FromGitter<Varriount> Yes.
04:29:38ryukopostingneat
04:29:46FromGitter<Varriount> I was using that code to test against the AWS signature v4 test suite
04:30:33*rnrwashere joined #nim
04:30:51*rnrwashere quit (Remote host closed the connection)
04:30:57FromGitter<Varriount> ryukoposting: There's probably still some "bugs" in the implementation. The V4 signature specification is a bit ambiguous about certain cases.
04:31:56ryukoposting(as a side node, whoever published a nimble package called "utils" should be skinned alive)
04:32:31ryukopostingthat's what I've heard Varriount
04:32:50*nsf joined #nim
04:32:56FromGitter<Varriount> ryukoposting: Oh! So that's why it wouldn't compile originally?
04:33:18ryukopostingno, that's not it
04:33:31ryukopostingI just have a room temperature IQ and didn't realize the gist had more than 1 file
04:38:43FromDiscord<demotomohiro> ``Callback`` type is used for parameter type but it is not exported.
04:38:43FromDiscord<demotomohiro> It is defined here:
04:38:43FromDiscord<demotomohiro> https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L248
04:38:44FromDiscord<demotomohiro> https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L1073
04:39:24ryukopostingwhy is it an argument for exported procs if it isn't even exported?
04:40:25ryukopostingit's the second argument to a bunch of procs, it isn't even something that could be called on the member of another object
04:40:32ryukopostingat least not without weird cruft
04:40:40FromGitter<Varriount> ryukoposting: Perhaps it's used by the async macro?
04:41:10ryukopostingthat makes sense
04:41:22ryukopostingstill kind of weird
04:48:24FromGitter<Varriount> ryukoposting: Feel free to ask me questions. I should be up for a couple more hours
04:50:26FromGitter<Varriount> the calculate_signature program was written with the AWS V4 signature test suite in mind
04:55:59*narimiran joined #nim
05:14:08Zevv@demotomohior: you're absolutely right; my case was about glVertexData (which he was not using)
05:34:59*rnrwashere joined #nim
05:35:18*noeontheend quit (Ping timeout: 264 seconds)
05:36:35*solitudesf joined #nim
05:48:55Zevvhehe, "room temperature IQ", is that celcius or fahrenheit?
05:51:18*solitudesf quit (Ping timeout: 245 seconds)
05:54:08*rnrwashere quit (Remote host closed the connection)
05:55:43*rnrwashere joined #nim
05:57:46Araqthe new for loop unpacking syntax is so intuitive that I used it without realizing...
05:57:51Araq:-)
06:07:06*rnrwashere quit (Remote host closed the connection)
06:10:41*rnrwashere joined #nim
06:11:55*krux02 joined #nim
06:13:41*rnrwashere quit (Remote host closed the connection)
06:14:47*rnrwashere joined #nim
06:16:30*PMunch joined #nim
06:19:32FromGitter<Varriount> Araq: New syntax?
06:25:13*arecacea1 quit (Remote host closed the connection)
06:25:31*arecacea1 joined #nim
06:28:04FromGitter<kayabaNerve> Are there any actual differences between ord and int?
06:33:29FromGitter<Varriount> @kayabaNerve `int` is a type, not a procedure? So if you do `int(value)`, value must be convertible to an integer
06:33:49FromGitter<Varriount> Whereas `ord` can be overridden (I think) for a specific type.
06:34:04FromGitter<kayabaNerve> Thanks
06:34:08leorizealso you can't pass `int()` into `map` :P
06:35:42leorizeVarriount: I believe Araq was talking about this: https://github.com/nim-lang/Nim/commit/001835bdecfb64974b52e91e1167301f66e4c72d
06:36:11FromGitter<Varriount> leorize: You mean, Nim hasn't had that since forever?
06:37:17leorizeyea? there was a huge post in the forum requesting that syntax iirc
06:52:10*Arlenx joined #nim
06:52:22*rnrwashere quit (Remote host closed the connection)
06:52:46*rnrwashere joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:49*gmpreussner joined #nim
07:10:56*rnrwashere quit (Remote host closed the connection)
07:18:42*dddddd joined #nim
07:27:47*Vladar joined #nim
07:46:11FromGitter<mratsim> oh?
07:46:35FromGitter<mratsim> the syntax without parenthesis worked when iterators returned a tuple
08:06:23*absolutejam joined #nim
08:07:15*Arlenx quit (Quit: Leaving)
08:10:40*gangstacat quit (Remote host closed the connection)
08:17:19*fanta7531 joined #nim
08:33:51*stefanos82 joined #nim
08:48:22*gangstacat joined #nim
09:05:55*floppydh joined #nim
09:06:18Araqhttp://gliese1337.blogspot.com/2012/04/schrodingers-equation-of-software.html
10:07:35FromGitter<kayabaNerve> I think I may have found a bug, but I'm honestly not sure
10:08:25FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cab1d983ebbdc55b37fdb93]
10:08:37FromGitter<kayabaNerve> This is perfectly valid code, without the `| int`.
10:09:17FromGitter<kayabaNerve> Even with the nesting. When you add the second `| int`, it's a compile time error of `Error: undeclared identifier: '|'`
10:09:39FromGitter<mratsim> what happens with "or" instead?
10:10:08FromGitter<kayabaNerve> Works fine
10:10:16FromGitter<kayabaNerve> Thanks for the workaround. I kinda needed this.
10:10:37FromGitter<kayabaNerve> So should I file a bug for the `|` part, noting the workaround of `or`?
10:11:37FromGitter<kayabaNerve> I forget how I found out Nim supports this feature. I can't find it in the manual. I'm guessing it's working off the concepts system but... I also don't have experience there.
10:16:52FromGitter<mratsim> I think it's in the typeclass section of the manual
10:17:05FromGitter<mratsim> it predates concepts
10:17:36FromGitter<mratsim> concepts are only about 2.5 years old iirc
10:21:41FromGitter<kayabaNerve> I've only been using Nim on a heavy basis for an year now.
10:23:09FromGitter<liquid600pgm> what proc do I use to convert a `ptr char` and length to a `string`?
10:28:34*lritter joined #nim
10:29:09AraqnewString + copyMem
10:29:19FromGitter<liquid600pgm> thanks!
10:32:27FromGitter<liquid600pgm> something like ⏎ ⏎ ```var msg = newString(length) ⏎ copyMem(msg.unsafeAddr, msgPtr, length)``` [https://gitter.im/nim-lang/Nim?at=5cab233b1f6e900d5efa779f]
10:32:45Araqyes
10:33:02FromGitter<liquid600pgm> hmm, I get a segmentation fault for some reason
10:34:23AraqunsafeAddr(msg[0])
10:34:25Araqobviously
10:34:33Araqdon't copy into the string's header
10:34:38FromGitter<liquid600pgm> aah, forgot the `[0]`
10:34:42FromGitter<liquid600pgm> of course
10:42:03FromGitter<kayabaNerve> Araq: Have a second?
10:45:17Araqhardly but shoot
10:48:44FromGitter<kayabaNerve> I had my issue on block hints closed because `used` exists and you could push all hints off.
10:49:11FromGitter<kayabaNerve> When I just found an error with Type Classes, and tested on devel, I saw that was already fixed. I also saw you could no longer push all hints off.
10:49:25*NimBot joined #nim
10:49:40FromGitter<kayabaNerve> I was curious if you'd accept a PR to re-enable that (after I reopen the issue, explain the update...).
10:51:21Araq"could no longer push" ... what are you talking about, nothing was changed
10:51:58FromGitter<kayabaNerve> From stable to devel.
10:52:18FromGitter<kayabaNerve> On stable, 0.19.4, you can push all hints off, and pop it back later.
10:52:23FromGitter<kayabaNerve> On devel, just compiled, that does nothing.
10:53:47*Araq shrugs
10:53:54Araqgive us some snippet to reproduce
10:53:57FromGitter<kayabaNerve> https://imgur.com/a/I9S2rqF
10:54:27Araqno, write a real bug report
10:54:36FromGitter<kayabaNerve> That test can be... 'fixed' via the `used` pragma, I know.
10:54:53FromGitter<kayabaNerve> I was trying to send that before I got your message :P
10:55:12FromGitter<kayabaNerve> I'll add a snippet to the existing issue or a new one, your choice.
10:59:11*neceve joined #nim
11:04:08FromGitter<kayabaNerve> I was writing the MWE, and it turns out that pushing/popping `hints: off` works, it's just that no longer affects generated procs `XDeclaredButNotUsed`. Using both workarounds (`used` and `push hints:off`) in tandem solves any issue.
11:04:23FromGitter<kayabaNerve> So never mind, I guess? Sorry for bringing you into this.
11:06:13FromGitter<liquid600pgm> oh gosh, I just noticed the issue
11:06:43FromGitter<liquid600pgm> (https://files.gitter.im/nim-lang/Nim/Duf7/image.png)
11:07:03FromGitter<liquid600pgm> it's all \`=destroy\`'s fault
11:07:41FromGitter<liquid600pgm> basically, it destroyed the window too early, right when a glDrawElements was about to happen
11:07:58FromGitter<liquid600pgm> and destroying a window invalidates its GL context
11:08:02*fredrik92 is now known as couven92
11:09:24Araqliquid600pgm: if you have =destroy you also better have = and =sink
11:09:35Araqwill probably enforce it soon
11:09:35FromGitter<liquid600pgm> what are those for?
11:09:57FromGitter<liquid600pgm> I know =, but what's =sink
11:09:59FromGitter<liquid600pgm> ?
11:10:29Araqthe move operator
11:10:38FromGitter<liquid600pgm> ahh, right
11:11:21FromGitter<liquid600pgm> I thought =destroy was basically a finalizer for objects that are about to get garbage collected
11:11:35*Vladar quit (Remote host closed the connection)
11:11:55*Vladar joined #nim
11:12:01Araqno.
11:12:30FromGitter<liquid600pgm> right, so how do I create a finalizer then?
11:12:48Araqnew(result, finalizerHere)
11:13:20FromGitter<liquid600pgm> that's what I thought I should do, but then saw `=destroy` as a "cleaner solution" and switched to it
11:13:29*clyybber joined #nim
11:13:31FromGitter<liquid600pgm> perhaps the docs should be more clear on what it does
11:17:19FromGitter<liquid600pgm> so I deleted =destroy for my window, but the error still persists for no apparent reason
11:17:53FromGitter<liquid600pgm> I have absolutely no idea what the driver is doing, but it seems as if it executes `glVertexAttribPointer` later than it should
11:41:58krux02liquid600pgm: it is not all the drivers fault.
11:42:24FromGitter<liquid600pgm> it's strange then that the window is closed *right before* my call to `glDrawElements`
11:44:44krux02I recommend you to use the functions from GL_ARB_direct_state_access everywhere, it prevents bugs.
11:46:13krux02what function closes the window?
11:46:58FromGitter<liquid600pgm> glXDestroyWindow, right after that glXDestroyContext
11:47:16krux02and what function call glXDestroyWindow?
11:49:04krux02this doesn't seems to be a driver bug
11:49:27krux02it seems to be related to using nim correctly.
11:51:44FromGitter<liquid600pgm> how do I find out?
11:52:25FromGitter<liquid600pgm> qapitrace only shows me the function that was called and its params, not the call stack
11:52:53ZevvwriteStackTrace()?
11:53:07Zevvor a breakpoint in Your Favorite Debugger
11:54:16krux02Zevv, we don't really support any other debugger other than gdb
11:54:30ZevvI know :)
11:54:39*fanta7531 quit (Quit: fanta7531)
11:54:44krux02at least we have gdb now
11:54:46FromGitter<liquid600pgm> problem is, the call is done somewhere in (I think) GLFW and I don't use my own generated GLX wrapper
11:55:07Zevvyou shoul still be able to get a full traceback - the close must be coming somewhere through your code
11:55:51krux02or you can show me your code and I might be able to tell you
11:56:21FromGitter<liquid600pgm> it's not, I only have an `updateEbo` call, which doesn't close the window, and then there's a `glDrawElements` call which does cause the window to get closed
11:56:41krux02do you have the code online?
11:56:55FromGitter<liquid600pgm> wait, let me push a commit to my repo
11:58:14FromGitter<liquid600pgm> here: https://github.com/liquid600pgm/rapid/blob/master/src/gfx/gfx.nim#L201
11:58:28FromGitter<liquid600pgm> this is *precisely* where I draw glDrawElements
12:01:00krux02yay yet another game engine :P
12:01:39Zevvwe can't all use Pygame
12:01:42FromGitter<liquid600pgm> what's wrong with making my own?
12:02:02FromGitter<liquid600pgm> I have my own requirements which this engine aims to satisfy
12:02:03Zevvnothing at all!
12:02:19FromGitter<mratsim> I still think push XDeclaredButNotUsed should be enabled for blocks @Araq @kayabaNerve (https://github.com/nim-lang/Nim/issues/10973).
12:02:30FromGitter<mratsim> probably other pragmas have this push/pop issue
12:03:23FromGitter<liquid600pgm> I don't intend to make this engine super wide-spread, I'm just going to use it in my games and that's it
12:03:27FromGitter<mratsim> it can be low prio though (unless another pragmas without any workaround pops out
12:04:41krux02well I can't build it at all
12:05:17krux02I just tried to build it
12:05:57Zevvsame here, don't seem to have vulkan headers in my glfw
12:06:10krux02can't find glfw/src/x11_monitor.c
12:08:09krux02liquid600pgm: did you try to set a breakpoint in gdb via ``break glXDestroyWindow``?
12:08:51FromGitter<liquid600pgm> I'm not really that experienced with gdb so I didn't know I could just break into a function like that
12:08:59krux02yes you can
12:09:06FromGitter<liquid600pgm> thanks for the tip
12:09:09FromGitter<kayabaNerve> @mratsim I'm copying the function in a macro, and I don't want any hints to appear from the copy, whether caused by macro or present in the original one. `push hints: off` disables everything on stable. On devel, you need to use that and `used` in the ProcDef to mute everything. `push hints: off` still handles other hints.
12:09:16krux02you need to build with "--debugger:native" though
12:09:23FromGitter<liquid600pgm> yeah, I know
12:09:25dom96Araq/krux02/narimiran: any thoughts about this? https://github.com/nim-lang/Nim/pull/10932
12:09:51narimirandom96: my thought: "You can't just break this module like that." ;)
12:10:00FromGitter<mratsim> @kayabaNerve you can also push: used
12:10:41dom96narimiran: Agreed.
12:10:47FromGitter<mratsim> but I'm also using workarounds because for testing I want some proc to be "used" but not for normal code
12:11:27krux02liquid600pgm: it might be though that glXDestroyWindow isn't actually called glXDestroyWindow in the binary. So you might also try ``rbreak glXDestroyWindow``.
12:13:28FromGitter<mratsim> @dom96, ini comments are supposed to be #, not & or did I miss the memo
12:13:31FromGitter<liquid600pgm> both don't break, it just continues until the segfault
12:13:43dom96mratsim: ini isn't standardised
12:14:37FromGitter<mratsim> then we can add a "comment" char option.
12:46:04*Snircle joined #nim
13:02:16FromGitter<liquid600pgm> krux02: rbreak also doesn't break
13:11:38krux02well I guess the debugger doesn't see the symbol then
13:13:19shashlickDid devel get fixed? Nightlies failed
13:13:41narimiranshashlick: yes, devel is now green
13:13:52shashlickCool
13:20:37FromGitter<liquid600pgm> seems I can't use gdb, I can't even set a simple breakpoint lol
13:21:16FromGitter<liquid600pgm> I tried setting a breakpoint at glDrawElements and it doesn't work too
13:21:39narimiranhttps://www.youtube.com/watch?v=DmYOPkI_LzU this video helped me use gdb with nim for the first time
13:23:02krux02I just tried it as well the gl functions are "special"
13:23:38krux02they are function pointers not not normal functions
13:23:50FromGitter<liquid600pgm> yeah, that's probably why it doesn't work
13:23:56krux02liquid600pgm what opengl wrapper are you using
13:24:15FromGitter<liquid600pgm> glad
13:24:22krux02yea, me too
13:24:30FromGitter<liquid600pgm> for OpenGL 3.3 core profile
13:24:56krux02you can see if you can configure glad in a way that you will see function names
13:25:19FromGitter<liquid600pgm> I just found this https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown#backtrace-capturing
13:25:24FromGitter<liquid600pgm> how could I miss this
13:28:26*kapil____ joined #nim
13:29:20FromGitter<liquid600pgm> yeah now qapitrace doesn't show any calls, how nice
13:29:55Zevvwhy weren't you able to get a backtrace on the segfault in gdb?
13:30:25krux02https://github.com/Dav1dde/glad#cc-debug
13:30:35krux02Zevv, segfault was too late
13:31:14FromGitter<liquid600pgm> that segfault occurs somewhere in the nvidia driver, that's all I know
13:31:38FromGitter<liquid600pgm> and I know that it occurs because the GL context is destroyed right before my glDrawElements call
13:32:05FromGitter<liquid600pgm> KHR_debug doesn't really help because no error message is generated before the segfault
13:32:05Zevvvalgrind?
13:32:36FromGitter<liquid600pgm> that won't tell me anything new (I tried when this error first occured)
13:33:15FromGitter<liquid600pgm> I need the backtrace from *right before* the segfault occurs
13:33:28krux02that link I sent you for glad debug, that is what you need for nim as well
13:33:40krux02the functions are all function pointers
13:33:47krux02the symbols are known in gdb
13:34:14krux02print (long*)glDrawBuffer_jkzdyP5IArhk9cqJik5N15g
13:34:20krux02that one for example works
13:34:29krux02the problem is, it is not a breakable symbol
13:34:58krux02at program start it's value is also 0
13:36:10Zevvits cb(fd: AsyncFD): bool
13:36:18Zevvoops
13:37:03*MasterdonY quit (Quit: ZNC - http://znc.in)
13:37:41*masterdonx joined #nim
13:38:42FromGitter<liquid600pgm> all right, I had enough
13:38:48FromGitter<liquid600pgm> I'm going to start from the beginning
13:39:49FromGitter<mratsim> People said that and spent their life implementing a CSV parser ;)
13:40:19FromGitter<liquid600pgm> I mean, I have no idea what could be wrong
13:40:20Zevvwell, that's not trivial, is it
13:40:38Zevvliquid600pgm: what would I need to do to get your code running?
13:40:39FromGitter<liquid600pgm> I just prefer to do a solid re-write than spend 3 more days debugging this code
13:40:47FromGitter<liquid600pgm> Zevv: what OS?
13:40:59Zevvdebian unstable or ubuntu 16.04
13:44:49FromGitter<liquid600pgm> all you'll need is GLFW's dependencies (https://www.glfw.org/docs/latest/compile.html#compile_deps), everything else is pure Nim
13:45:00*nsf quit (Quit: WeeChat 2.4)
13:45:25Zevvis everything added to your repo? I don't have glfw/src/posix_tls.c for example
13:46:29Zevvok, built
13:46:38ZevvI added upstream glfw to rapid/src
13:47:52Zevvnimble test opens a blue window, how do I reproduce your crash?
13:49:10FromGitter<liquid600pgm> that's strange, is there a white triangle in the window?
13:50:00Zevvnope
13:50:21FromGitter<liquid600pgm> that's completely different from what I get, what about console output?
13:50:27Zevvdebug: GL | kind 33360, severity 37191: Scanning index buffer to compute index buffer bounds. Use glDrawRangeElements() to avoid this.
13:50:30Zevva thousand times
13:50:37Zevvhint :)
13:51:06FromGitter<liquid600pgm> that's *very* different from what I get, what drivers are you on?
13:51:35ZevvOpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
13:52:20FromGitter<liquid600pgm> so now for sure that crash is caused by the nvidia driver
13:52:26Zevvyou could maybe try to force linking to mesa or swiftshader instead of nvidia to force software rendering?
14:01:09*PMunch quit (Remote host closed the connection)
14:18:23*solitudesf joined #nim
14:32:41dom96wow, 3D development sounds fun when you get different behaviour for each graphics driver
14:34:55FromGitter<liquid600pgm> yeah, for example, there's an nvidia specific thing where it tells you that a buffer object has just been created *every single time you do so*
14:35:23FromGitter<liquid600pgm> yet it doesn't give you **any** optimization hints, like Mesa does
14:35:33*Trustable joined #nim
14:44:01*fanta7531 joined #nim
14:44:35*noeontheend joined #nim
14:46:57*abm joined #nim
14:47:51*ng0 joined #nim
14:54:39clyybberdom96 That's why vulkan is a good thing
14:54:55FromGitter<mratsim> But Apple went solo ...
14:54:59*clyybber is happy to not deal with buggy openGL drivers
14:55:14*Xe quit (Quit: WeeChat 1.9.1)
14:56:16clyybbermratsim: I honestly don't care about apple. If they *want* to fuck their customers they can. But I won't support them by adding support for their proprietary crap,
14:57:41clyybbersadly/luckily theres vulkan->metal
14:57:49dom96How does Vulkan solve this? Isn't it possible to get poorly implemented Vulkan drivers?
14:58:56clyybberdom96 yeah, but generally it's harder for the manufacturers to fuck up the vulkan implementation
14:59:12clyybbersince vulkan does not do so much by itself.
15:00:03*couven92 quit (Quit: Client disconnecting)
15:00:43clyybberAs in, the API user has to do more of the things the opengl driver implementation did for you.
15:01:28clyybberit's just much more verbose.
15:01:40FromGitter<mratsim> DX12 on Vulkan works great in Linux btw
15:01:55clyybberyeah, wine has done a really great job at that
15:02:16clyybberits amazing, a year ago DX12 support was nothing.
15:02:25*Xe joined #nim
15:05:59*fanta7531 quit (Quit: fanta7531)
15:12:22*noeontheend quit (Remote host closed the connection)
15:25:35FromGitter<liquid600pgm> I just rewrote the whole thing, making it much more bare-bones yet it *still* crashes for the same reason
15:26:19FromGitter<liquid600pgm> I bind the vertex array, the window gets closed for no reason, and the call to glDrawArrays occurs
15:26:35FromGitter<liquid600pgm> vertex buffer* that is
15:27:19FromGitter<liquid600pgm> it all worked until I put my seq of vertex data into an object
15:31:26shashlickWhat os @liquid600pgm
15:31:38FromGitter<liquid600pgm> fedora 29
15:45:37*rnrwashere joined #nim
15:50:27*noonien joined #nim
15:52:09*MightyJoe joined #nim
15:55:04*cyraxjoe quit (Ping timeout: 268 seconds)
15:57:22*kapil____ quit (Quit: Connection closed for inactivity)
16:05:36*rnrwashe_ joined #nim
16:07:25WilhelmVonWeinerif calling a function in the form obj.f(), should I keep or leave parens?
16:08:09dom96keep
16:08:47*rnrwashere quit (Ping timeout: 240 seconds)
16:11:40WilhelmVonWeinerwhy?
16:13:20Araqleave them out
16:13:46narimiranand to have a third opinion: it depends :D
16:14:20WilhelmVonWeinersorry dom96 but Araq has tied my hands
16:15:00dom96It does depend indeed
16:15:16dom96leaving them out is ambiguous ;)
16:15:27WilhelmVonWeineris it?
16:15:34Araqno it is ambiguous when the compiler tells you it is.
16:16:10Araqand leaving out the () is much of the point of having a syntax
16:16:59*fanta7531 joined #nim
16:18:02clyybberAraq: Can I use the header pragma for a c macro?
16:20:19Araqsure
16:22:13*noeontheend joined #nim
16:25:46clyybbernice.
16:26:00clyybberwrapping alsa sure is a feat
16:40:49*rnrwashe_ quit ()
16:41:55*kapil____ joined #nim
16:43:55*noeontheend quit (Remote host closed the connection)
16:44:02*clyybber is not so sure it's a good idea wrapping alsa
16:44:08Zevvhaha
16:44:16Zevvalsa is hell
16:45:47Zevvbut cant you get away with a small subset?
16:46:21clyybberyeah, but wrapping that subset is the problem
16:46:39clyybberI actually wanted to only wrap alsa's seq API
16:48:29clyybberbut those headers require things out of the other headers and all that jazz
16:49:39Zevvcan't you get there without the headers?
16:50:20clyybberZevv Hmm, you mean just wrapping whatever I need with importc and header
16:50:47leorizeyou don't even need header
16:50:52Zevvshould be doable if the structs aren't not too complicated
16:50:59leorizejust importc the procs you need
16:51:07Zevvyou can just define Nim objects which are binary compatible with the alsa data structures
16:51:12Zevvdefine some enums, and procs, and you're good to go
16:51:23clyybberleorize I need to have #include <alsa/asoundlib.h> generated in the source code though
16:51:44clyybberZevv: Yeah, that's essentially what I'm doing.
16:51:54clyybberwith the help of c2nim
16:52:00clyybberbut there are so many
16:52:49clyybberand for some reason alsa has to fuck my head with 2 type aliases per struct...
16:53:12Zevvlet me see, did you give nimterop a try yet?
16:53:16clyybberone with the _t suffix, and one with an underscore prefix, which in turn fucks c2nim
16:53:25Zevv./toast -rnp /usr/include/alsa/seq.h
16:53:47clyybberZevv: Nah, I want to keep it as "simple" as possible
16:53:51Zevvhttp://paste.debian.net/plain/1076680
16:53:53Zevvthis is what you get
16:54:32Zevvyou don't need nimterop in your project, you can use it like c2nim; sometimes c2nim gives better results, sometimes nimterop does
16:54:49clyybberoh, alright. thanks
16:55:02clyybberbut c2nim actually works with some postprocessing bash
16:55:18Zevvask the nimterop people how to get the best results
16:55:20clyybberand the problem is seq.h doesn't suffice
16:55:26*I_Right_I joined #nim
16:55:29clyybberZevv: aka shashlick?
16:55:30Zevvno, but nimterop can recurse and find whatever is needed
16:55:38Zevvthere problem is that sometimes it pulls in half the world, though
16:55:43clyybberlol
16:55:48clyybberbut thats a nice feature
16:56:05*_Raid_ joined #nim
16:56:55clyybberand then alsa can't have a fucking normal header to just include, no. They have a makefile which builds the header, depending on build variables
16:57:53*_Raid_ quit (Client Quit)
16:58:18FromGitter<liquid600pgm> I found my problem! apparently you need to bind your VBO before you declare your vertex attributes, and I didn't think of that.
16:58:32clyybber\o/
16:58:46*_Raid_ joined #nim
16:58:58Zevvhaha
16:59:15Zevvopengl is always a PITA. *everything* needs to be in place, or you get either a black screen or a black screen
16:59:19Zevvor a segfault :)
16:59:30Zevvcongrats
16:59:42clyybbervulkan is a bit nicer in that regard
16:59:42*I_Right_I quit (Ping timeout: 255 seconds)
16:59:54clyybberwith validation layers at least
17:00:00clyybberwithout them... not so much
17:00:20Zevvcrayons is even more fool proof
17:01:53clyybber* is wondering if its a better idea to build a pure C midi library and then wrap that with nim
17:05:39*rnrwashere joined #nim
17:05:55Araqno
17:06:09Araqbuild a --newruntime midi library
17:07:48*noeontheend joined #nim
17:07:52FromGitter<liquid600pgm> why create a pure C MIDI lib and wrap that if you can just write a Nim library for that?
17:08:46clyybberyeah, because creating a wrapper around alsa is tricky
17:09:03FromGitter<liquid600pgm> MIDI is standardized, for device communication all you'll need is some way of sending and receiving serial data from USB
17:09:21clyybberI want to support the alsa_seq api
17:09:24clyybberthough
17:09:41Zevvhow do you plan to integrate with the rest of your app; main loop, timing, etc?
17:09:42clyybberand possibly the jack api too (although jack implements the alsa_seq api too)
17:12:41clyybberZevv: WDYM?
17:13:22clyybberfor now I just want to make a midi sequencer library for nim
17:18:06*clyybber wonders why sed exists, when there is perl
17:19:18ZevvI just learned sed is as old as I am. amazing
17:31:17*druonysus quit (Ping timeout: 245 seconds)
17:34:27clyybberAraq: Will do. Though I doubt --newruntime will affect much.
17:34:45clyybberOr do you mean I should use refs instead of pointers
17:34:51clyybberand owned refs
17:36:07*noeontheend quit (Ping timeout: 268 seconds)
17:37:41shashlickLet me know how nimterop does with alsa
17:37:44shashlickHappy to help
17:38:31shashlickIf nothing else use -p to process the preprocessor stuff out
17:38:47shashlickThen use nimterop or c2nim
17:38:48Zevvhi shashlick; I forgot, toast was able to dynlib instead of header importc's, right?
17:38:51FromGitter<samdmarshall> @Araq hey, I'm not sure I am understanding your suggestion here: https://github.com/nim-lang/nimble/issues/625#issuecomment-480772731 I seem to keep running into errors with module-names or import/include behavior as the properties in the .nimble file don't have a var/let/const attached. I have constructed a macro to intake and process the data at compile-time but seems like an ugly solution to this
17:39:12clyybbershashlick Does -p use gcc as its preprocessor?
17:39:24shashlickZevv: I don't think so yet but minor fix for that
17:39:39Zevvah ok, would be cool
17:39:50Araqsandmarshall: well yeah, it requires something like 'var version: string'
17:40:15shashlickYes it is gcc right now but works with clang too
17:40:30shashlickCan always be expanded
17:40:39_Raid_Hey,in nim whats the most efficient way to convert an array of chars to a string?
17:43:38FromGitter<samdmarshall> @Araq that seems to break the parsing of the nimble file. I had a thought about if I could get the chunk of text that gets returned from the `include` statement, then a very small macro should be able to nicely wrap that into a `const` def block but i'm not that clever with macros to figure out the first part of that :\
17:43:45clyybbershashlick Can nimterop handle macros with concatenation ## ?
17:51:23*floppydh quit (Quit: WeeChat 2.4)
17:52:05*fanta7531 quit (Quit: fanta7531)
17:52:24livcdHow should I do the error checking for a winapi when a winapi function returns something when it succeeds and it returns nil when it does not ?
17:55:24clyybberAraq: How do multiple arguments for c2nim's --assumedef option look?
17:56:06clyybberI'm trying --assumedef:SOMETHING,OTHERTHING but it doesn't work
18:00:20*rnrwashe_ joined #nim
18:01:32*noeontheend joined #nim
18:04:15*rnrwashere quit (Ping timeout: 264 seconds)
18:09:17FromDiscord<demotomohiro> @livcd I think you need to call GetLastError function. https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx
18:11:38_Raid_so I am guessing this is the fastest way to copy an array of chars to a string ----> https://pastebin.com/JPLhvM6Q
18:14:13_Raid_but if there is a better method than copyMem() plz let me know
18:16:59Araqclyybber: --assumedef:a --assumedef:b
18:20:00*zielmicha__ quit (Read error: Connection reset by peer)
18:20:15*msmorgan quit (Ping timeout: 252 seconds)
18:20:15*nimblepoultry quit (Ping timeout: 252 seconds)
18:20:38*zielmicha__ joined #nim
18:20:43*nimblepoultry joined #nim
18:21:34*msmorgan joined #nim
18:21:41*JStoker quit (Ping timeout: 250 seconds)
18:23:02*JStoker joined #nim
18:26:26*theelous3__ joined #nim
18:26:40FromGitter<samdmarshall> @Araq is there a way I can dump or otherwise iterate/access what is defined during compile time. I know there are ways to check for specific things but I haven't seen anything with regards to seeing what exists
18:26:53*noeontheend quit (Ping timeout: 250 seconds)
18:44:36*uvegbot quit (Ping timeout: 250 seconds)
18:46:10*nsf joined #nim
18:54:36*noeontheend joined #nim
19:19:25*clyybber quit (Quit: WeeChat 2.4)
19:22:48*noeontheend quit (Ping timeout: 255 seconds)
19:29:31ZevvAraq: I was looking to improve the performance of bit sets. bitsets.nim mentions in comments that U8 is used to "avoid issues with cross-compiling", can you recall what issues you expect here?
19:32:42livcdwhat would be the equivalent of this in nim ? lpservice = new ENUM_SERVICE_STATUS [dwBytes];
19:33:59*Trustable quit (Remote host closed the connection)
19:36:02FromGitter<arnetheduck> Zevv, if you want to take it over, https://github.com/nim-lang/Nim/pull/9029 has some improvements, specially in removing the ugly -d option to select sane or insane behavior..
19:37:22*kapil____ quit (Quit: Connection closed for inactivity)
19:37:46shashlick@Clyybber can give me an example? Right now only numeric defines are translated
19:38:46FromGitter<arnetheduck> at status we've already forked it though, except for the builtins (maybe), the rest could live in a separate library easily.. specially that new macro stuff is.. different from our needs
19:38:49shashlickI'm more wondering why you'd need this in Nim
19:40:31Araqarnetheduck: any opinion on my 'owned ref' RFC?
19:41:33FromGitter<arnetheduck> Araq, tbh, I haven't had time to give it the time and focus it deserves
19:42:02FromGitter<arnetheduck> intuitively, I like it conceptually, but the devil is in the details
19:42:30Araqsure, fair enough.
19:44:48*rnrwashe_ quit (Remote host closed the connection)
19:44:54_Raid_how's the newruntime coming alone?
19:45:05_Raid_along*
19:45:50Araq_Raid_: strutils' tests are beginning to work, next is koch.nim then we will get serious and port an async program
19:46:41Araqin the worst case we'll have a *much* better --gc:none alternative
19:47:08FromGitter<arnetheduck> > btw, Araq, the new owner thing, would it cover the following scenario: ⏎ > * I have some `state` which is a ref object ⏎ > * I compute a cache over that `state` ⏎ > * I want to make sure that the `state` does not change while the cache "exists" (by scoping cache object) ⏎ > something like: ... [https://gitter.im/nim-lang/Nim?at=5caba53cc55bd14d35af9fac]
19:48:22Araqunclear, are you asking about immutability?
19:49:06FromGitter<arnetheduck> no, just that as long as cache exists and holds a (non-owning) ref to `state`, I can't create another owning ref
19:49:41Araqwell but who owns the cache entry? the cache?
19:50:04FromGitter<arnetheduck> yeah, just some local with a scoped duration
19:50:17FromGitter<arnetheduck> so I compute a cache over state, then use it
19:50:40FromGitter<arnetheduck> I want to ensure that `state` doesn't change while `cache` is around
19:51:14Araqbut your local doesn't own the cache entry so it cannot outlive the cache
19:51:44Araq(checked at runtime, I know, I know, give me a break. We can add more borrow checks later.)
19:52:15FromGitter<arnetheduck> so `cache` is the cache entry here, if I understand your question right
19:52:31FromGitter<arnetheduck> ie I compute it from `state` - say that it's an index into a vector
19:53:41Araqok, well if 'someFunc' doesn't play nice and invalidates the cached result you'll get a runtime error
19:54:01FromGitter<arnetheduck> and what exactly causes that runtime error?
19:54:26Araqcache means the object's refcount is > 0
19:55:12FromGitter<arnetheduck> so basically, when I take a non-owning ref, refcount goes up.. then if I try to mutate through owning ref and refcount > 0, runtime error
19:55:55Araqno, mutations are fine but if you lose the owned pointer and it gets free()d then it asserts the RC == 0
19:56:17livcdhow i can get this in Nim ? https://glot.io/snippets/fb43trn74x oO
19:56:43Araqthink about it this way: Instead of detecting dangling pointer *reads*, it detects dangling pointers and assumes they might be used later on for a read
19:57:12Araqso instead of a read barrier we can use reference counts to detect the bugs
19:58:25FromGitter<arnetheduck> ok, I need to make a more detailed pass over the proposal then - in particular, it sounds like it won't be enough on its own to provide a safe way to pass stuff between threads
19:59:25*nsf quit (Quit: WeeChat 2.4)
19:59:55Araqit's enough if you enforce RC == 0 when passing the owned ref to a different thread
20:00:21FromGitter<arnetheduck> yeah, but is there a language construct for that?
20:00:31Araqbut for thread interop you might be better off with the classic uniquePtr.
20:01:16AraqPlease notice that with the destructors we can replicate C++'s unique and shared pointers. However, it was unclear what to do with the builtin 'ref' that is everywhere
20:01:45Araqand the proposal claims these are exactly the semantics that fit the stdlib's needs best.
20:01:51FromGitter<arnetheduck> what happens in (modern) c++ is that you generally start off with uniqueptr, then you promote them to shared when needed (by moving the unique ptr into the shared one)
20:02:24FromGitter<arnetheduck> but like I said, it's been a busy few weeks.. need to read up on the details
20:03:14_Raid_Araq: Sorry AFK, That's really cool! When I have the time I can't wait to try it out!
20:03:39Araq_Raid_: I'll announce it on the forum when I think you can give it a try
20:04:20FromGitter<arnetheduck> the second (general) question I would have for ref is that memory is just one kind of resource - what about files, handles etc?
20:04:40FromGitter<arnetheduck> it seems that owned + destructors should take care of that too, but..
20:05:11Araqthat is indeed the case. you define =destroy for a file and it's called when the owned ref disappears
20:06:47*narimiran quit (Ping timeout: 240 seconds)
20:08:07*c3V0aXZ joined #nim
20:13:21*avanderneut quit (Remote host closed the connection)
20:22:49*rnrwashere joined #nim
20:25:05FromGitter<arnetheduck> different topic: there's a `quoteShell`, but is there a `parseShell` too?
20:27:01*rnrwashere quit (Ping timeout: 246 seconds)
20:30:06livcdoh noes no one replied to me :-(
20:32:25*rnrwashere joined #nim
20:36:24Araqarnetheduck: there is os.parseCmdLine
20:36:34Araqlivcd: please repeat
20:39:08FromGitter<arnetheduck> perfect.
20:41:07*noeontheend joined #nim
20:44:24*rnrwashere quit (Remote host closed the connection)
20:46:24shashlickparseCmdLine is awesome
20:46:55*theelous3__ quit (Ping timeout: 258 seconds)
20:50:27*solitudesf quit (Ping timeout: 268 seconds)
20:52:58*c3V0aXZ quit (Quit: Leaving)
20:53:27FromDiscord<exelotl> if I'm currently dependent on gc:none (as in, it's literally the only option that works for my platform), will I be able to switch to newruntime without any additional memory usage?
20:55:28*c3v0axz joined #nim
20:56:16Araqexelotl: it's very likely, the new runtime doesn't produce RTTI anymore either
21:00:47*ng0 quit (Quit: Alexa, when is the end of world?)
21:03:34*Vladar quit (Remote host closed the connection)
21:19:15*rnrwashere joined #nim
21:23:28federico3I feel the need for a more expressive parseopt
21:23:35*rnrwashere quit (Ping timeout: 246 seconds)
21:39:28FromDiscord<exelotl> Araq: oh that's good to hear :D
22:01:36FromGitter<mratsim> @federico3 agree, maybe RFC? cligen works quite well
22:11:17*stefanos82 quit (Remote host closed the connection)
22:12:28*rnrwashere joined #nim
22:13:06*rnrwashere quit (Remote host closed the connection)
22:13:12*rnrwashere joined #nim
22:14:15_Raid_I wanted to double check, are strings passed by reference?
22:16:33*noeontheend quit (Ping timeout: 250 seconds)
22:21:36*abm quit (Quit: Leaving)
22:25:19Araqsure they are
22:26:56_Raid_but int is passed by value?
22:27:10*rnrwashere quit (Remote host closed the connection)
22:28:08*rnrwashere joined #nim
22:29:53*seni joined #nim
22:30:03_Raid_I asked because I read a post that said all nim basic types where passed by value and I just assumed they where including strings
22:32:03*noeontheend joined #nim
22:32:29FromGitter<mratsim> Nim default types have value semantics
22:33:28FromGitter<mratsim> but at a low-level they are passed by reference if they are bigger than the size of 3 pointers. It's only a Nim<->C optimization though you don't need to care about that.
22:38:04_Raid_Yeah, I don't know why I even needed to double check that. I see that nim is pretty fast. But I didn't trust you to handle strings efficiently.
22:40:03*rnrwashere quit (Remote host closed the connection)
22:40:49*rnrwashere joined #nim
22:41:28*_Raid_ is now known as i_Right_i
22:43:32FromGitter<mratsim> Since strings are mutable and you can also preallocate a string buffer you're free to do the fastest string implementation of algorithm you need without any low-level restriction
22:44:15FromGitter<mratsim> The main issue is temporaries when using API with return values (like in strutils).
22:49:28FromGitter<Varriount> *Raid*: For efficient string handling, avoid creating slices and temporaries, like this code does: https://gist.github.com/Varriount/076f406c475b5369301a2fcd7b4527af
22:56:55i_Right_iso when a proc returns a string that is local to its scope, is the return a full copy?
22:57:10i_Right_ior deep copy
22:58:21*noeontheend quit (Remote host closed the connection)
23:01:34*lritter quit (Ping timeout: 250 seconds)
23:02:45FromGitter<mratsim> if you use result = you will get return value optimisation and directly build the string efficiently
23:03:07FromGitter<mratsim> otherwise it's a copy.
23:14:37*krux02_ joined #nim
23:17:07*krux02 quit (Ping timeout: 240 seconds)
23:31:18copygirlI'm a copy!
23:31:46FromGitter<mratsim> :D
23:39:20*krux02_ quit (Remote host closed the connection)
23:40:28i_Right_imratsim: thanks again!
23:41:10*rnrwashere quit (Remote host closed the connection)
23:52:57*rnrwashere joined #nim
23:53:41*rnrwashere quit (Remote host closed the connection)
23:53:47*rnrwashere joined #nim