| 00:00:33 | Discoloda | why, is it using immediate primitives? |
| 00:00:59 | filwit | don't use glVertexf() stuff (aka, GL 1.1) |
| 00:01:13 | filwit | use indexed vertex array objects |
| 00:01:18 | * | Matthias247 quit (Quit: Matthias247) |
| 00:01:25 | Demos | no, I am recompileing/relinking shaders, and allocateing VBOs each frame |
| 00:01:33 | filwit | and then learn one of the three main ways to do instancing |
| 00:01:39 | Discoloda | filwit: thats immediate primitives |
| 00:02:04 | Demos | I am using indexed VBOs, but I am allocateing a new set each frame |
| 00:02:20 | Demos | and I am making a new VAO each frame but I dont think that matters so much |
| 00:02:26 | filwit | Discolada: pretty sure that's a broader term than what i said |
| 00:02:42 | filwit | Discolada: but not positive either |
| 00:02:58 | filwit | Demos: how can you even do that? |
| 00:03:15 | Demos | erm with glGenBuffers? |
| 00:03:40 | Demos | I was like "I could deal with state management, or I could get something rendering asap" |
| 00:03:41 | filwit | Demos: when you make a vertex array object, you have to bind it to an GLHandle (int) and then enable it through that handle.. |
| 00:03:54 | Demos | right |
| 00:03:57 | filwit | Demos: just generate it once, and continue to use the handle afterwards |
| 00:04:02 | EXetoC | yeah it's a simple solution when you're starting out |
| 00:04:39 | * | skyfex joined #nimrod |
| 00:04:39 | EXetoC | Rasmus Lerdorf would approve |
| 00:04:42 | filwit | Demos: if you want to quickly render things, use glBegin/end and glVertexf |
| 00:05:37 | Demos | but I know how to use VBOs and such, I have no idea how to use glBegin/glEnd, eaiser. And this way I have code that I can refactor later to not be so slow |
| 00:06:44 | filwit | Demos: i don't understand how your concerns with the state machine effect this though. You still have to glBindBuffer(myVAOhandle), just glBindBuffer(0) aftewards.. |
| 00:07:36 | Demos | I need to associate the gl buffer handles with meshes and I dont feel like doing that right now |
| 00:07:47 | Demos | I will later, but first I want something working |
| 00:08:09 | filwit | you're going to eat through all your VRam and cause a crash |
| 00:08:26 | Demos | I am not just leaking memory |
| 00:08:34 | Demos | geez |
| 00:08:59 | * | skyfex quit (Ping timeout: 240 seconds) |
| 00:09:27 | filwit | lol, so you're also going through deallocation each frame? i can't possibly see why you're doing that. It's basically the same steps to just retain the handle and use them as to create/delete the buffer to begin with. |
| 00:10:45 | filwit | Demos: let me make you a gist really quick to illustrate. |
| 00:13:30 | Skrylar | no, do not use glBeginEnd |
| 00:13:43 | Skrylar | Those are deprecated (and removed in 3.x Core) |
| 00:14:26 | EXetoC | for testing purposed obviously |
| 00:14:33 | EXetoC | but you can just emulate that eventually if you want |
| 00:14:36 | Skrylar | Demos: why are you creating a new VBO/VAO every frame? Is there something wrong with using the 'streaming mode' which tells GL to expect those to be *modified* each frame? |
| 00:14:44 | Skrylar | EXetoC: I know, there's a C++ library which does just that |
| 00:14:45 | filwit | Demos: https://gist.github.com/PhilipWitte/9402516 |
| 00:15:28 | filwit | Demos: whoops, updated it. |
| 00:15:52 | Demos | ugh I am lazy. Geez. |
| 00:16:11 | Demos | I am going to fix this once everything works |
| 00:16:32 | filwit | Demos: you use glBindVertexArray() for both creating the buffer, and for rendering an existing one. You're just telling the GL driver to lock to that handle. |
| 00:16:40 | Skrylar | thats why i was considering doing the cairo backend for a GUI before the GL one :( |
| 00:16:56 | Skrylar | the correct way to use GL3 feels like trying to build a ship in a bottle with a toothpick |
| 00:18:11 | filwit | idk, maybe it's always seemed rather straight forward to me. The problem is when you get into vertex layouts |
| 00:18:11 | EXetoC | it seems pretty similar to not using immediate mode in 2.1 |
| 00:18:18 | EXetoC | the basics anyway |
| 00:18:33 | filwit | but the basic concept is staright forward: bind to handle, do something, unbind |
| 00:19:03 | Skrylar | well the toothpicks part i mean is exactly that |
| 00:19:27 | Skrylar | in a normal compositor/painter lib you just say "put a line from here to there, fill that area, put this line here and there" |
| 00:19:43 | Skrylar | some really advanced functions involve making a vertex buffer and asking it to draw that |
| 00:19:46 | filwit | yeah, DirectX is a bit more sane here, but then it never seemed that hard to track unwind things |
| 00:20:01 | Skrylar | nah its more just a matter of them being different worlds IMO |
| 00:20:06 | Skrylar | you can't really "draw a line" on a GPU |
| 00:20:16 | Skrylar | you "render geometry with line drawing mode" |
| 00:20:24 | filwit | actually, DirectX works pretty similar to what you're saying |
| 00:20:34 | Skrylar | didn't they remove immediate mode in DX :P |
| 00:20:39 | filwit | but at the expensive of performance in some cases |
| 00:21:01 | filwit | when you say "bind this VA" it checks for already bound things and auto-unbinds them |
| 00:21:11 | filwit | (at least, that's what i think is going on) |
| 00:21:13 | Skrylar | yeah, these are different conversations going past each other |
| 00:21:46 | filwit | in truth, it's a bit more complex for sure, as really these draw calls are just queuing up draw calls on a separate GL/DX thread |
| 00:22:10 | filwit | Skrylar: DX never had immediate mode |
| 00:22:57 | filwit | and immediate mode is not recommended in GL anymore either |
| 00:23:03 | Skrylar | immediate mode is removed in GL |
| 00:23:16 | Skrylar | and I'm pretty sure DX7 had an immediate mode, because I remember reading about it getting removed |
| 00:23:19 | filwit | i think even the Intel Mesa drivers where talking about removing GL 1.1 features entirely, but not sure if that panned out |
| 00:23:47 | filwit | Skrylar: you could be right, but DX works differently and features are actually depreciated from one version to the next |
| 00:24:04 | filwit | DX 8+ does not have immediate mode |
| 00:24:08 | Skrylar | they were deprecated and removed from GL too |
| 00:24:16 | filwit | yet they still work.. |
| 00:24:25 | Skrylar | that's because you have a 2.x context |
| 00:24:26 | EXetoC | Skrylar: right, a lib possibly sitting on top of OpenGL, so I don't think it's a valid complaint |
| 00:24:41 | Skrylar | EXetoC: SDL used to be software based and worked the same way :P |
| 00:24:48 | filwit | Skrylar: to even get a GL 2+ context, you have to first create a GL 1.1 context |
| 00:25:02 | Skrylar | but yes, you can emulate that specific example with a lib; and its a great way to ignore what i was trying to say |
| 00:25:03 | filwit | Skrylar: though I think that's changing with EGL |
| 00:25:30 | Skrylar | Modern OSX versions force the core profile which means you can't use old shaders / anything fixed function |
| 00:25:37 | Discoloda | opengl drivers (at least for nvidia) tend to give you access to everything, even with 4.x mode. i guess its slower for them to check what mode your in to see if it can be used. |
| 00:25:51 | Skrylar | you can initialize a 3.X Core or a 4+ profile on other OS which does the same |
| 00:26:00 | filwit | Skrylar: i don't see how "emulating with a lib" applies here since the code that runs this is all CPU bound anyways. It's the same as it's always been AFAIK |
| 00:26:40 | Skrylar | filwit: because my example of how GL exposes the concept of "draw this icon on the screen" was meant to demonstrate how it requires extra understanding, something that is not necessarily easy to grasp unless you sit and make an effort to understand how the GPU works |
| 00:26:57 | filwit | Skrylar: Apple writes there own OpenGL drivers i think, or at least, enforces some different standards. I'm not the most familiar with OSX stuff. |
| 00:27:05 | Skrylar | in every 2d software blit lib, you do it by saying drawsurface(x, y, 0, 0) or blit(x, y, 0, 0) and in GL you have these extra steps people need to learn |
| 00:27:08 | filwit | driver frontend** |
| 00:28:10 | filwit | Skrylar: i see, i thought you where talking about the removal of glBegin/End/Vertexf stuff |
| 00:28:39 | Skrylar | yeah; immediate mode is basically the analogue of that because people could understand it more easily |
| 00:28:59 | Skrylar | but its been removed, anyone supporting it is doing so because they're not complying with the core profile or the app didn't ask for one http://www.opengl.org/wiki/Legacy_OpenGL |
| 00:29:26 | Skrylar | And yes, EGL is basically the core profile |
| 00:29:30 | Skrylar | So it doesn't have those |
| 00:30:10 | filwit | yeah, plus they don't exist in GLES 2 IIRC |
| 00:30:36 | Skrylar | yep, because gles is the core profile with some parts removed for mobiles :) |
| 00:30:42 | filwit | but i might be wrong about that.. it's been a little while since i've looked at the specifics |
| 00:30:43 | EXetoC | if only they hadn't advertised it as a high level interface :p |
| 00:31:03 | filwit | EXetoC, exactly, lol |
| 00:31:12 | Skrylar | i'll have to comb over all of that again when i get to dealing with GL again |
| 00:31:14 | Skrylar | that won't be a fun time |
| 00:31:30 | filwit | the DX camp is always like "DX is soo much better" and i'm like "bad comparison" |
| 00:31:41 | Skrylar | GL has to support code for so long, lol |
| 00:31:49 | Skrylar | anyway i'm getting made to go to a social outing, be back later |
| 00:32:15 | filwit | have fun |
| 00:32:19 | filwit | brb |
| 00:36:13 | Demos | what is with stuff like cGL_CULL_FACE in opengl.nim? |
| 00:36:36 | Demos | oh I see |
| 00:36:38 | filwit | to avoid name conflicts due to case-insensitivity |
| 00:36:39 | filwit | yeah |
| 00:36:43 | Demos | not CS and glCullFace is a function |
| 00:36:45 | Demos | sweet |
| 00:38:26 | * | q66 quit (Ping timeout: 252 seconds) |
| 00:41:00 | Demos | also why does glGetShaderiv take an int as the first param |
| 00:41:11 | Demos | or rather a GLHandle (typedef'd to an int) |
| 00:41:26 | Demos | the docs say it takes a GLuint, which makes sense |
| 00:44:33 | filwit | what do you mean? |
| 00:45:04 | filwit | you mean Nimrod's OpenGL.glGetShaderIV takes an Int? |
| 00:45:56 | Demos | opengl.nim has proc glGetShaderiv(shaderObj: GLHandle, pname: GLenum, params, PGLInt) where the khronos docs have void glGetShaderiv(GLuint shader, GLenum pname, GLint* params) |
| 00:46:28 | filwit | GLHandle is just a GLuint i think |
| 00:46:46 | filwit | but should probably match the khronos def for sure |
| 00:47:08 | Demos | nope, it is totally a GLint in my version |
| 00:47:16 | filwit | same thing |
| 00:47:49 | filwit | accept that i believe -1 means an error or something |
| 00:47:54 | filwit | not sure |
| 00:48:11 | Demos | well the opengl spec says it is a gluint |
| 00:48:30 | filwit | yeah it should be changed to match the spec |
| 00:50:18 | Demos | I am almost tempted to just generate a new wrapper, but I will hold off and do that only if the current wrapper is more awkward in the function loading department |
| 00:51:42 | * | q66 joined #nimrod |
| 00:55:03 | Demos | ugh and glGetShaderInfoLog takes a var GLint instead of a ptr GLint |
| 00:57:09 | * | carum quit (Remote host closed the connection) |
| 00:59:21 | EXetoC | Demos: you just create your window and then call opengl.loadExtensions if necessary |
| 00:59:43 | Demos | yeah that is what I figured, but I think Varriount said it did not work |
| 00:59:45 | Demos | so we will see |
| 01:01:47 | * | carum joined #nimrod |
| 01:01:57 | * | darkf joined #nimrod |
| 01:02:19 | Demos | having to write cast[var GLint](nil) to call some of these funcitons is pretty scary |
| 01:03:51 | filwit | GL needs to be wrapped anyways, so what's the point of making a "more convenient" wrapper for and API which will almost always be wrapped again? Especially if it means changing things from the GL spec |
| 01:04:20 | filwit | just make your own Canvas/Mesh/Shader/etc constructs which use GL behind the scenes |
| 01:05:35 | filwit | either way, you're going to have to put cast[var GLint](nil) somewhere probably, you're just making more work for yourself by trying to make OpenGL more Nimrod-friendly probably |
| 01:06:12 | filwit | then again, there are a lot of people who are going to want to use OpenGL directly, so you may have a point |
| 01:06:28 | Demos | well it is NOT the same as the GL spec |
| 01:06:36 | Demos | the gl spec says GLint* |
| 01:06:45 | filwit | that's probably a bug |
| 01:06:49 | Demos | which should be ptr GLint |
| 01:06:51 | filwit | error* |
| 01:06:58 | EXetoC | it's binary compatible isn't it? |
| 01:07:02 | Demos | yes |
| 01:07:10 | Demos | but terrifying |
| 01:07:26 | Demos | var Ts should not be allowed to be null |
| 01:08:40 | EXetoC | it's fine as long as you don't need to specify nil I think. I guess I managed to avoid it |
| 01:09:15 | * | carum quit (Remote host closed the connection) |
| 01:09:36 | EXetoC | or not need to, to clear |
| 01:09:40 | EXetoC | *be clear |
| 01:16:38 | * | zielmicha quit (Quit: Connection closed for inactivity) |
| 01:19:23 | * | r0b4 quit (Ping timeout: 264 seconds) |
| 01:20:42 | Demos | the issue is that I want the wrapper to be as close to the XML spec as possible |
| 01:22:52 | * | zezba9000 joined #nimrod |
| 01:30:41 | Varriount | Demos: loadExtensions works |
| 01:30:51 | Varriount | It was just a bug with my setup, I think. |
| 01:33:14 | Varriount | Demos: Gah I hate having to mess around with cstringarrays |
| 01:34:34 | * | EXetoC quit (Read error: Operation timed out) |
| 01:34:44 | Demos | I just used cast[cstringArray](addr cstringvar) |
| 01:35:27 | Varriount | Demos: Are you following a tutorial? |
| 01:37:00 | Demos | nope |
| 01:37:08 | Demos | porting some code I had written in c++ |
| 01:40:36 | fowl | Araq, pong |
| 01:40:58 | * | brson quit (Ping timeout: 240 seconds) |
| 01:41:34 | fowl | Demos, you need to get cmd line args? |
| 01:42:08 | Demos | no, why? |
| 01:42:30 | fowl | jw |
| 01:42:48 | filwit | Okay folks, time for some opinions on Syntax again. This time, with screenshots: http://reign-studios.net/philipwitte/nimrod/UniformSyntaxComparison.png |
| 01:43:48 | * | q66 quit (Quit: Leaving) |
| 01:43:51 | Varriount | filwit: Show me how winlean.nim would look. |
| 01:43:54 | filwit | Both syntax models Left/Right are fully consistent by have slight difference in implications. Mostly, on the right (the one with '='), to be fully consistent macro consume bodies after the '=' mark |
| 01:44:06 | fowl | lol varria |
| 01:44:24 | filwit | this means that '=' cannot appear directly inside the param body, and would need to be encapsulated, eg.. |
| 01:44:28 | filwit | var a, b: int |
| 01:44:35 | fowl | filwit, you know {} can be postfix like x{y,z} righ |
| 01:44:39 | filwit | myMacro (a = b) = ... |
| 01:44:47 | Varriount | I'm not kidding. I'd truly like to see how this proposed syntax would look for code that I have to refer to and add to. |
| 01:45:02 | filwit | fowl: this is a new parser where that would not be possible |
| 01:45:16 | filwit | fowl: {} would no longer represent a set |
| 01:45:27 | fowl | i like postfix {} |
| 01:45:39 | filwit | cool, i don't, and i'm writing this |
| 01:45:40 | fowl | i havent found a use for it yet but i enjoy the concept of it |
| 01:45:43 | fowl | like `()` |
| 01:45:51 | Demos | I am happy with whatever. Literally anything is better than c++ syntax |
| 01:46:29 | filwit | that's a very poor argument when you can't even find a use case for it then, fowl, and especially when {} would attract a lot of people from the curly-brackets camp |
| 01:46:55 | fowl | filwit, if we are attracting people based off syntax that scares me |
| 01:46:59 | Varriount | filwit: You ask for consistancy, yet you want to allow both indentation and curly bracket syntax? |
| 01:47:00 | filwit | fowl, sorry, didn't mean to come off as rude. I appreciate the input. |
| 01:47:17 | fowl | tell them to go use coffeescript or typescript if it matters that much |
| 01:47:53 | filwit | Varriount: i have no problem with options. but optional stuff doesn't mean inconsistency just like the case-sensitivity stuff really. It just makes more people happy |
| 01:48:02 | filwit | Varrount: plus it works just fine in C |
| 01:48:06 | filwit | if () { .. } |
| 01:48:09 | filwit | if () ..; |
| 01:48:41 | fowl | this.(x,y,z) + v.(x,y,z) |
| 01:49:03 | Varriount | filwit: That's not a very good logical argument. That's like me saying that strict OO heirarchies work fine for java. |
| 01:49:12 | filwit | fowl: it's not entirely about syntax of course. No one is going to pick a language JUST because of syntax. Nimrod has the best GC and codegen around, and it would be nice if _the most_ people felt very comfortable using it. Including me. |
| 01:49:43 | Varriount | filwit: What concerns me is the definition of 'noise' you seem to define in your post. |
| 01:50:08 | filwit | Varriount: i only meant that it's nothing people bat an eye-lash at. Sometimes you want short-hand code, so optional stuff at some level is good. It's a slippery slope, but there's a balance. |
| 01:50:25 | fowl | ^ how can you complain of noise when you want your api to use typedesc[T] as the first param, so it feels more like C# |
| 01:50:52 | Varriount | fowl: Where did I say that? |
| 01:51:02 | fowl | Varriount, i meant filwit |
| 01:51:04 | filwit | Varriount: about the 'noise' to me, personally, the left code looks better cause there's less "noisy" symbols. |
| 01:51:53 | filwit | fowl: i never wanted to actually use typedesc[T] as the first argument. that's what the OOP macros are for |
| 01:52:21 | filwit | fowl: and i like OOP, unlike some here. But i also thing functional is good as well. There are balances to all these things. |
| 01:52:35 | Varriount | From what I learned in my communication class last semester, 'noise' is an outside force which interferes with communication. Colons seperating types is not noise, especially when a 'type' may consists of multiple identifiers. |
| 01:53:19 | Varriount | filwit: And no, I'm not going to stop fussing about the removal of my precious colons. |
| 01:54:36 | filwit | Varriount, well i will concede that 'noise' might not be the _perfect_ terminology, but i think my point is clear |
| 01:54:41 | Varriount | I also notice your example lacks type definitions with multiple members of different types. |
| 01:54:59 | fowl | filwit, i dont think you'll have many fans of changing 'var x: ref int' to 'ref x int' |
| 01:55:00 | filwit | Varriount: also, so looking at the two side-by-side, you prefer the right due to the : use ? |
| 01:55:33 | filwit | fowl: i have other arguments for that one actually, but know that "var x: ref int" would be optional |
| 01:55:36 | Varriount | filwit: Pretty much. |
| 01:55:41 | fowl | "ref a int: b" == "var a: ref int = b" wat |
| 01:55:51 | filwit | Varriount: okay, thanks for your vote! :) |
| 01:56:03 | fowl | filwit, you're doing what C does, mangling the type with the name of the var |
| 01:56:06 | Varriount | Although I don't see how the right is different from normal nimrod syntax. |
| 01:56:28 | filwit | Varriount: also, the lack of certain idioms is only due to me trying to present a simplified example (that fits in one image) |
| 01:56:29 | Varriount | Except for pragmas |
| 01:56:42 | fowl | instead of c saying foo : *int it is int (*foo) |
| 01:57:13 | filwit | crap.. just realized there's a flaw with the syntax on the right... |
| 01:57:17 | Varriount | filwit: How is the right side syntax different from normal nimrod syntax? |
| 01:57:38 | filwit | in the macro, the : should come after the 'Immediate' |
| 01:57:54 | fowl | better example int (*foo)[] vs foo: *[]int |
| 01:58:25 | filwit | Varriount: it's almost the same, true. and I don't like it because it's inconsistent with builtins like for/if/etc (again, i prefer the left) |
| 01:58:57 | filwit | fowl: i don't see exactly what you're saying |
| 01:59:14 | filwit | fowl: if you're talking about the 'ref as keyword' thing, it's only sugar |
| 01:59:46 | filwit | fowl: but i have additional arguments for distinguishing ref/var like that which i don't want to get into ATM |
| 01:59:50 | fowl | how do you define a ref ptr int |
| 02:00:01 | filwit | var x ref ptr int |
| 02:00:12 | filwit | ref x ptr int |
| 02:00:24 | fowl | meh |
| 02:00:25 | fowl | no thanks |
| 02:00:34 | fowl | take me off your mailing list plz |
| 02:00:39 | filwit | lol |
| 02:00:59 | filwit | noted, but if you had to choose. left of right? |
| 02:01:04 | Varriount | fowl: So you don't want me sending you "Spam Monthly" anymore? |
| 02:01:06 | filwit | or* |
| 02:02:19 | fowl | filwit, right, the colons separating the name from the type soothes my savage soul |
| 02:02:28 | filwit | also note, the var/ref on the left could use '=' instead of ':' for assignment |
| 02:02:36 | filwit | i'm not apposed to that inconsistency |
| 02:02:38 | fowl | also: actionscript does this and people seem to love actionscript |
| 02:02:43 | filwit | since it's the only odd-man-out |
| 02:03:13 | filwit | fowl, okay, thanks for the vote |
| 02:03:39 | * | icebattle quit (Ping timeout: 240 seconds) |
| 02:03:40 | filwit | (some) people also really love the Go syntax. these things are opinions |
| 02:03:47 | Demos | Varriount: did you have problems with "undefined reference to nimLoadProcs0"? |
| 02:04:01 | filwit | i'm interested in arguments which appeal to the _most_ people in general |
| 02:04:12 | Varriount | Demos: At first, but it seemed to go away. I don't know why. |
| 02:04:18 | Demos | oh great |
| 02:04:20 | fowl | Demos, you comment out opengl.loadExtensions until you use an extension |
| 02:04:37 | * | DAddYE quit (Remote host closed the connection) |
| 02:04:41 | fowl | Demos, (hint, when you use an extension you'll get a different crash, thats when its time to uncomment it) |
| 02:04:52 | Demos | that is insane, but OK |
| 02:04:57 | fowl | also loadextensions has to be right after the gl context is created |
| 02:05:16 | Varriount | When you use an extension, you'll get a nil value error. |
| 02:05:31 | Varriount | (if you don't loadExtensions) |
| 02:05:32 | * | icebattle joined #nimrod |
| 02:05:36 | * | skyfex joined #nimrod |
| 02:06:48 | * | Zuchto quit (Ping timeout: 240 seconds) |
| 02:06:50 | * | phI||Ip quit (Ping timeout: 240 seconds) |
| 02:06:50 | * | comex quit (Ping timeout: 240 seconds) |
| 02:07:17 | * | phI||Ip joined #nimrod |
| 02:07:20 | Varriount | Hi skyfex, icebattle |
| 02:07:27 | * | Zuchto joined #nimrod |
| 02:10:29 | * | skyfex quit (Ping timeout: 269 seconds) |
| 02:10:52 | * | nequitans quit (Ping timeout: 240 seconds) |
| 02:10:52 | * | eigenlicht quit (Ping timeout: 240 seconds) |
| 02:10:57 | * | nequitans_ joined #nimrod |
| 02:12:04 | Varriount | I'm a little confused about the "cstringArray" type - is each variable of cstringArray type actually allocated the amount specified in it's length? |
| 02:12:04 | Varriount | http://nimrod-lang.org/system.html#435 |
| 02:13:14 | * | Raynes quit (Ping timeout: 240 seconds) |
| 02:13:20 | * | eigenlicht joined #nimrod |
| 02:14:04 | fowl | Varriount, no |
| 02:15:03 | * | brson joined #nimrod |
| 02:15:33 | fowl | Varriount, its used for interfacing with c, cstringarray would be argv ( char *argv[] ) |
| 02:16:00 | Varriount | fowl: Yes, I know that it is used for that, but then why does it not actually allocate all the memory? Is it a special compiler rule? |
| 02:16:21 | * | Raynes joined #nimrod |
| 02:16:30 | fowl | Varriount, no, because its ptr array |
| 02:16:50 | * | brson quit (Client Quit) |
| 02:17:04 | fowl | var x: ptr array[9001, int] initialized to 0 (nil) not an array of 9001 ints |
| 02:18:56 | Varriount | Oh I see. I missed the 'ptr' |
| 02:19:18 | fowl | "The array's high value is large enough to disable bounds checking in practice" -- it might as well be int.high |
| 02:20:18 | Varriount | fowl: Though we did just get the 'unchecked' pragma |
| 02:21:38 | * | Discolod1 joined #nimrod |
| 02:22:25 | fowl | o rly |
| 02:24:48 | Varriount | fowl: Ys, o rly. lk at yr eml |
| 02:25:04 | * | nequitans_ quit (Ping timeout: 265 seconds) |
| 02:25:04 | * | Discoloda quit (Ping timeout: 265 seconds) |
| 02:28:26 | * | BitPuffi1 joined #nimrod |
| 02:28:41 | * | nande_ joined #nimrod |
| 02:35:23 | * | xenagi quit (*.net *.split) |
| 02:35:24 | * | BitPuffin quit (*.net *.split) |
| 02:35:24 | * | nande quit (*.net *.split) |
| 02:35:25 | * | cark quit (*.net *.split) |
| 02:35:28 | * | Discolod1 quit (*.net *.split) |
| 02:35:30 | * | zezba9000 quit (*.net *.split) |
| 02:35:30 | * | Demos quit (*.net *.split) |
| 02:35:31 | * | XAMPP quit (*.net *.split) |
| 02:35:32 | * | Varriount quit (*.net *.split) |
| 02:35:34 | * | aftershave_ quit (*.net *.split) |
| 02:35:37 | * | fowl quit (*.net *.split) |
| 02:35:50 | * | filwit quit (Quit: Leaving) |
| 02:42:29 | * | xenagi joined #nimrod |
| 02:47:14 | Kelet | So have any open source games been made with Nimrod? If so, I'd love to see a repository or something :) |
| 03:04:38 | * | carum joined #nimrod |
| 03:06:11 | * | noam quit (Ping timeout: 244 seconds) |
| 03:06:13 | * | Skrylar quit (Ping timeout: 244 seconds) |
| 03:06:15 | * | Raynes quit (Ping timeout: 244 seconds) |
| 03:06:15 | * | rixx quit (Ping timeout: 244 seconds) |
| 03:06:17 | * | betawaffle quit (Ping timeout: 244 seconds) |
| 03:06:23 | * | rixx_weechat joined #nimrod |
| 03:07:43 | * | Raynes joined #nimrod |
| 03:18:33 | * | carum quit (Read error: Connection reset by peer) |
| 03:24:20 | * | flaviu quit (Remote host closed the connection) |
| 03:24:40 | * | romnatol quit (*.net *.split) |
| 03:24:42 | * | eigenlicht quit (*.net *.split) |
| 03:24:42 | * | Zuchto quit (*.net *.split) |
| 03:24:43 | * | icebattle quit (*.net *.split) |
| 03:24:43 | * | darkf quit (*.net *.split) |
| 03:24:44 | * | shodan45 quit (*.net *.split) |
| 03:26:44 | * | icebattle joined #nimrod |
| 03:29:55 | * | darkf joined #nimrod |
| 03:38:23 | * | DAddYE joined #nimrod |
| 03:48:56 | * | fowl joined #nimrod |
| 04:04:23 | * | fowl quit (Ping timeout: 264 seconds) |
| 04:05:18 | * | comex joined #nimrod |
| 04:18:21 | * | nande_ quit (Remote host closed the connection) |
| 04:23:58 | * | xenagi quit (Quit: Leaving) |
| 04:29:08 | * | XAMPP joined #nimrod |
| 04:32:05 | * | rixx_weechat is now known as rixx |
| 04:41:24 | * | DAddYE quit (Remote host closed the connection) |
| 04:50:31 | * | meguli quit (Quit: Page closed) |
| 05:12:39 | * | Demos joined #nimrod |
| 05:13:03 | Demos | and back |
| 05:13:32 | Demos | oh crap I think the netsplit is still going on |
| 05:14:25 | * | Demos quit (Client Quit) |
| 05:19:08 | * | Demos joined #nimrod |
| 05:47:38 | * | BitPuffi1 quit (Ping timeout: 252 seconds) |
| 06:07:15 | * | skyfex joined #nimrod |
| 06:11:18 | * | skyfex quit (Ping timeout: 240 seconds) |
| 06:12:20 | * | Trixar_za quit (Ping timeout: 245 seconds) |
| 06:13:14 | * | Trixar_za joined #nimrod |
| 06:28:12 | Demos | WOOOOOOOWWWWW |
| 06:32:53 | * | carum joined #nimrod |
| 06:38:39 | * | carum quit (Remote host closed the connection) |
| 06:47:16 | * | brson joined #nimrod |
| 06:50:46 | * | skyfex joined #nimrod |
| 07:00:14 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 07:40:38 | * | Demos quit (Ping timeout: 240 seconds) |
| 07:52:43 | * | DAddYE joined #nimrod |
| 07:52:43 | * | carum joined #nimrod |
| 07:52:43 | * | eigenlicht joined #nimrod |
| 07:52:43 | * | fowl joined #nimrod |
| 07:52:43 | * | Zuchto joined #nimrod |
| 07:52:43 | * | aftershave_ joined #nimrod |
| 07:52:43 | * | Varriount joined #nimrod |
| 07:52:43 | * | Discolod1 joined #nimrod |
| 07:52:43 | * | betawaffle joined #nimrod |
| 07:52:43 | * | noam joined #nimrod |
| 07:52:43 | * | Skrylar joined #nimrod |
| 07:52:43 | * | cark joined #nimrod |
| 08:09:15 | Skrylar | i see the realities have reconverged |
| 08:15:10 | Skrylar | reactormonk: so i ported the shiphash over and then realized nimrod doesn't have pointer arithmetic |
| 08:18:40 | * | carum quit (Remote host closed the connection) |
| 08:25:56 | fowl | Skrylar, fowltek/pointer_arithm |
| 08:27:22 | Skrylar | fowl: i did look at that |
| 08:28:46 | Skrylar | huh, why are the bitops complaining about uints |
| 08:35:14 | * | Matthias247 joined #nimrod |
| 08:43:41 | * | DAddYE quit (Remote host closed the connection) |
| 08:44:08 | * | DAddYE joined #nimrod |
| 08:46:24 | Araq | fowl: I can't reproduce your problems with importc/exportc: "$1_foo" |
| 08:49:01 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 08:57:22 | * | XAMPP quit (Read error: Connection reset by peer) |
| 09:01:20 | * | skyfex joined #nimrod |
| 09:05:18 | * | skyfex quit (Ping timeout: 240 seconds) |
| 09:06:41 | * | brson quit (Quit: leaving) |
| 09:07:03 | fowl | Araq, i cant either >_> |
| 09:20:46 | fowl | gn |
| 09:21:11 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 09:21:16 | fowl | Araq, roids compiles on devel branch, im happy :) |
| 09:35:28 | * | zahary_ joined #nimrod |
| 09:39:33 | Skrylar | i probably ought to sync my compiler install |
| 09:39:41 | Skrylar | i haven't updated in a week |
| 09:40:59 | * | krusipo quit (Ping timeout: 264 seconds) |
| 09:44:46 | Skrylar | Araq, reactormonk: siphash routine is ported over; going to port the tests and make it prettier in a bit |
| 09:45:09 | * | ddl_smurf joined #nimrod |
| 09:48:32 | * | noam_ joined #nimrod |
| 09:50:24 | * | noam quit (Ping timeout: 265 seconds) |
| 10:06:06 | * | EXetoC joined #nimrod |
| 10:13:08 | * | io2 joined #nimrod |
| 10:47:46 | * | studentm joined #nimrod |
| 10:58:10 | * | r0b4 joined #nimrod |
| 10:58:37 | * | krusipo joined #nimrod |
| 11:02:08 | * | skyfex joined #nimrod |
| 11:02:18 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 11:05:49 | * | r0b4 quit (Quit: WeeChat 0.4.2) |
| 11:06:07 | * | r0b1 joined #nimrod |
| 11:06:47 | * | skyfex quit (Ping timeout: 264 seconds) |
| 11:57:09 | Araq | Skrylar: excellent. your unicode stuff should move into the stdlib |
| 12:22:47 | * | Matthias247 joined #nimrod |
| 12:22:55 | * | isenmann quit (Quit: Leaving.) |
| 12:37:13 | Skrylar | Araq: did you peek through the github for it? |
| 12:37:46 | Skrylar | also, balls. the siphash test vectors aren't matching up, i'll have to comb over it tomorrow to see which part didn't port right |
| 12:49:15 | * | Skrylar quit (Ping timeout: 265 seconds) |
| 12:56:32 | * | Skrylar joined #nimrod |
| 12:56:45 | Skrylar | Araq: disconnect troubles aside, i fixed it. woot. |
| 13:03:02 | * | skyfex joined #nimrod |
| 13:07:18 | * | skyfex quit (Ping timeout: 240 seconds) |
| 13:14:35 | * | carum joined #nimrod |
| 13:29:37 | * | carum quit (Remote host closed the connection) |
| 13:29:54 | * | carum joined #nimrod |
| 13:53:31 | * | EXetoC joined #nimrod |
| 14:21:56 | * | studentm quit (Remote host closed the connection) |
| 14:23:25 | * | darkf quit (Quit: Leaving) |
| 14:23:58 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 14:52:49 | * | brihat left #nimrod (#nimrod) |
| 14:59:20 | Varriount | Yay! People are here again! |
| 15:00:58 | Varriount | OrionPK: Ping |
| 15:01:04 | OrionPK | yo |
| 15:01:58 | Varriount | OrionPK: How should we respond to this: https://github.com/wbond/package_control_channel/pull/2884 |
| 15:02:22 | OrionPK | hmm |
| 15:02:27 | OrionPK | he does accept PR's |
| 15:02:35 | OrionPK | because i've submitted them to him before |
| 15:02:49 | OrionPK | I think it'd be better to ask him to pull his and add him as a contributor to ours though :p |
| 15:03:51 | * | skyfex joined #nimrod |
| 15:03:51 | Varriount | My main reason is that we are actually on IRC and following things, and he isn't. |
| 15:04:11 | OrionPK | then tell joneshf that.. this is the nimrod community's plugin |
| 15:04:31 | Varriount | OrionPK: Then maybe it should be added to nimrod-code |
| 15:04:36 | OrionPK | perhaps |
| 15:04:59 | OrionPK | talk to dom |
| 15:08:35 | * | skyfex quit (Ping timeout: 264 seconds) |
| 15:19:38 | * | meguli joined #nimrod |
| 15:22:28 | * | BitPuffi1 joined #nimrod |
| 15:41:34 | * | carum quit (Remote host closed the connection) |
| 15:44:16 | * | carum joined #nimrod |
| 15:55:40 | * | pillot joined #nimrod |
| 16:00:33 | * | brihat joined #nimrod |
| 16:00:46 | * | brihat quit (Client Quit) |
| 16:02:41 | * | brihat joined #nimrod |
| 16:07:39 | Varriount | Ok.. so my vertex shader code compile, but not my fragment shader. Wonderful. |
| 16:10:05 | * | psquid quit (Quit: work) |
| 16:12:55 | * | ermachenko quit (Remote host closed the connection) |
| 16:14:04 | * | pillot quit (Remote host closed the connection) |
| 16:33:44 | * | brihat quit (Quit: Leaving.) |
| 16:34:08 | * | XAMPP joined #nimrod |
| 16:36:17 | * | flyx joined #nimrod |
| 16:39:11 | flyx | hi folks! I was aware of this new language for some time, but didn't really see a reason to switch. I decided to have a closer look now |
| 16:54:12 | OrionPK | welcome flyx! |
| 17:02:03 | * | noam__ joined #nimrod |
| 17:02:24 | reloc0 | j/buffer 4 |
| 17:02:32 | reloc0 | sorry |
| 17:04:47 | * | skyfex joined #nimrod |
| 17:05:19 | * | noam_ quit (Ping timeout: 244 seconds) |
| 17:06:17 | * | Endy joined #nimrod |
| 17:08:50 | * | skyfex_ joined #nimrod |
| 17:08:58 | * | skyfex quit (Ping timeout: 240 seconds) |
| 17:20:17 | * | [1]Endy joined #nimrod |
| 17:20:23 | * | nande joined #nimrod |
| 17:23:13 | * | Endy quit (Ping timeout: 240 seconds) |
| 17:23:13 | * | [1]Endy is now known as Endy |
| 17:31:54 | * | DAddYE joined #nimrod |
| 17:38:44 | * | shodan45 joined #nimrod |
| 17:44:25 | * | brson joined #nimrod |
| 17:44:53 | dom96 | https://news.ycombinator.com/item?id=7361593 |
| 17:51:58 | * | renesac quit (Ping timeout: 240 seconds) |
| 17:59:24 | OrionPK | dom96 how about it? nimlime in nimrod-code |
| 18:07:56 | * | zielmicha joined #nimrod |
| 18:09:57 | dom96 | OrionPK: Ehh. I don't mind. |
| 18:12:03 | * | brihat joined #nimrod |
| 18:18:42 | Araq | dom96: can you move babel to $nimrod/tools this weekend? |
| 18:19:16 | dom96 | No. And this shouldn't be done. |
| 18:19:53 | Araq | gah |
| 18:20:05 | Araq | why not? |
| 18:20:22 | dom96 | Because the Nimrod repo is bloated as it is. |
| 18:20:43 | Araq | we will trim it soon |
| 18:22:37 | dom96 | Another reason is that babel is a babel package. |
| 18:22:41 | dom96 | So it needs its own repo. |
| 18:23:03 | dom96 | Everything in tools/ should be in a separate repo |
| 18:23:12 | Araq | babel is the tool to install further stuff |
| 18:23:23 | Araq | it makes perfect sense to include it with the compiler |
| 18:23:42 | Araq | other tools can indeed be moved to their own repo |
| 18:23:55 | dom96 | I also prefer to have a separate issue tracker |
| 18:24:34 | Araq | ok |
| 18:24:57 | Araq | I should bundle babel's C sources then to the compiler's C sources |
| 18:25:14 | Araq | and ofc have a babel.exe for the windows install |
| 18:25:43 | dom96 | That's fine. |
| 18:25:59 | dom96 | And zielmicha's nimrod-env is nice |
| 18:26:13 | dom96 | We shouldn't include more stuff in the repo, we should make it easier to install the stuff |
| 18:32:55 | * | ddl_smurf_ joined #nimrod |
| 18:33:18 | * | ddl_smurf quit (Ping timeout: 240 seconds) |
| 18:33:18 | * | ddl_smurf_ is now known as ddl_smurf |
| 18:35:50 | * | ddl_smurf quit (Client Quit) |
| 18:41:01 | * | CarpNet quit (Quit: Leaving) |
| 18:41:28 | Araq | bbl |
| 18:45:54 | * | q66 joined #nimrod |
| 18:53:29 | * | carum quit (Remote host closed the connection) |
| 19:29:25 | Varriount | dom96: How do you feel about nimrod-code hosting the sublime-plugin |
| 19:29:42 | dom96 | Varriount: I don't mind. |
| 19:31:30 | Varriount | Hm. Anyone know good OpenGl tutorials on 2d graphics, preferably using v3.0+? |
| 19:36:43 | * | Demos joined #nimrod |
| 19:43:09 | * | nande quit (Remote host closed the connection) |
| 19:48:28 | Varriount | Hi Demos |
| 19:48:34 | Demos | hi |
| 19:48:43 | Araq | hi Varriount |
| 19:48:57 | OrionPK | Varriount wasnt there an awesome gl tutorials website out there |
| 19:49:23 | Varriount | OrionPK: I've found many tutorials on 3d graphics, but none for specifically 2d graphics. |
| 19:49:54 | Demos | for 2D you usually render a quad faceing the camera |
| 19:49:57 | OrionPK | yeah |
| 19:50:13 | OrionPK | then you can render whatever you want onto the texture of the quad |
| 19:50:16 | Demos | so you can use an ortho projection or just have the quad fill clip space |
| 19:50:44 | Demos | or you could just use Cairo |
| 19:50:57 | Demos | (or direct2D if that is your thing) |
| 19:50:59 | OrionPK | http://www.opengl-tutorial.org/beginners-tutorials/tutorial-2-the-first-triangle/ |
| 19:51:08 | OrionPK | thats not the site im thinking of though :\ |
| 19:51:30 | OrionPK | http://open.gl/ |
| 19:51:32 | OrionPK | there it is |
| 19:51:33 | Varriount | Demos: I've not heard good things about direct2d |
| 19:51:45 | OrionPK | direct2d is deprecated, isnt it? |
| 19:53:07 | Demos | no directdraw is depricated |
| 19:53:14 | Demos | d2d is actually pretty neat |
| 19:53:19 | OrionPK | ah, true.. |
| 19:53:25 | OrionPK | I was thinking of direct draw |
| 19:53:33 | OrionPK | they're constantly deprecating parts of directx |
| 19:53:47 | Demos | directx is pretty much just D3D and D2D now |
| 19:53:56 | OrionPK | yeah |
| 19:54:03 | Demos | oh, and directwrite |
| 19:54:29 | OrionPK | DirectCompute? never heard of that |
| 19:54:41 | Demos | DirectCompute is not really a seperate API |
| 19:55:42 | Demos | it is more like ARB_compute_shader than openCL |
| 19:55:48 | OrionPK | i havent done 3d / DX stuff since 07 |
| 19:55:51 | OrionPK | :( |
| 20:01:18 | * | Endy quit (Ping timeout: 240 seconds) |
| 20:01:44 | Demos | I want PiX for OpenGL |
| 20:04:53 | Demos | the only decent opengl debuggers seem to be CodeXL, intel GPA, and NSignt. I dont have an nvidia GPU, GPA is not avalible on arch, and CodeXL segfaults on kernels above 3.8... |
| 20:34:23 | * | meguli quit (Ping timeout: 245 seconds) |
| 20:37:04 | Araq | vmgen.nim(33, 18) Error: number of spaces around '..' not consistent |
| 20:38:11 | * | Araq implemented strong spaces |
| 20:38:13 | * | Matthias247 joined #nimrod |
| 20:38:25 | Araq | gah this eror message is nasty |
| 20:50:02 | * | Endy joined #nimrod |
| 20:50:07 | Demos | hey neat! intel's GLSL IR is a lisp |
| 21:03:18 | OrionPK | Demos how is your nimrod -> GLSL compiler coming? :P |
| 21:05:14 | Demos | not well, I want to get just regular openGL calls working first, and so I have been playing find the triangle for the past few hours. That was a pretty high in the sky goal anyway. Honestly I really want macros.quote to work before I even try and get a nimord->glsl compiler working |
| 21:07:54 | Araq | just use parseExpr instead of macros.quote |
| 21:08:56 | Demos | yeah, I guess. |
| 21:08:57 | * | meguli joined #nimrod |
| 21:09:40 | Demos | when are {.global.} vars in a proc initialized? |
| 21:10:19 | Araq | before the proc is called |
| 21:10:41 | * | carum joined #nimrod |
| 21:12:28 | Demos | ergh, that is annoying |
| 21:15:19 | OrionPK | Demos macros.quote? |
| 21:16:28 | OrionPK | whats the diff between that and parseexpr? |
| 21:16:30 | Demos | Araq: that is really subtly different from how static variables work in C |
| 21:17:02 | Araq | Demos: guess what. we didn't copy C here. |
| 21:17:12 | Demos | k, I am fine with that. |
| 21:17:20 | Araq | it's also called "global" and not "static" |
| 21:17:44 | Araq | and the way it works has been designed for meta programming |
| 21:18:01 | * | Endy quit (Ping timeout: 240 seconds) |
| 21:20:59 | * | flaviu joined #nimrod |
| 21:21:06 | * | Demos quit (Remote host closed the connection) |
| 21:30:15 | Varriount | Araq: What command causes the tester to produce a diff between two test runs? |
| 21:30:32 | Araq | tester html |
| 21:30:37 | Araq | also produces the json |
| 21:33:48 | * | meguli quit (Quit: Page closed) |
| 21:34:32 | Varriount | And you the tester to add the results of all the previous tests to the json as well? |
| 21:35:43 | Varriount | Do you mean, the number of failed/succeeded tests, or the actual tests names, results, etc? |
| 21:35:46 | NimBot | Araq/Nimrod devel 3ff9869 Araq [+0 ±8 -0]: implements strongSpaces parsing mode |
| 21:35:46 | NimBot | Araq/Nimrod devel dcdaf49 Araq [+2 ±31 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 21:36:16 | Araq | the latter |
| 21:36:58 | Varriount | Any particular structure you have in mind for the result data? |
| 21:38:31 | Araq | ask dom96 |
| 21:39:31 | Varriount | dom96: Ping |
| 21:39:51 | * | BitPuffi1 quit (Read error: Operation timed out) |
| 21:41:20 | dom96 | Varriount: Add a field called "results" to the current json |
| 21:41:26 | * | BitPuffi1 joined #nimrod |
| 21:41:33 | dom96 | Make it a JObject |
| 21:41:45 | dom96 | or rather an array |
| 21:42:13 | dom96 | with objects |
| 21:42:20 | * | svprts joined #nimrod |
| 21:42:21 | dom96 | which correspond to a single test result. |
| 21:42:34 | Araq | hi svprts welcome |
| 21:43:24 | dom96 | {"name": "ttest.nim", "expected": "foo", "result": "bar", "success": true/false} |
| 21:43:43 | dom96 | Oh wait, there can also be ignored tests. |
| 21:44:18 | dom96 | "status": "success/failure/ignored" |
| 21:44:20 | dom96 | or something like that |
| 21:44:21 | Araq | just copy the sql model |
| 21:44:30 | Varriount | Remind me why this is needed when we have the sqlite database? |
| 21:45:06 | dom96 | NimBuild will assimilate the sqlite db. |
| 21:45:47 | Varriount | Ok.. so what does the tester need the json for? |
| 21:47:49 | * | carum quit (Remote host closed the connection) |
| 21:48:28 | dom96 | So that NimBuild can parse the test results easily. |
| 21:48:50 | Varriount | But nimbuild can already read from an sqlite database - why not use that? |
| 21:49:04 | dom96 | It can't. |
| 21:49:11 | Varriount | Why not? |
| 21:49:50 | * | svprts quit (Remote host closed the connection) |
| 21:49:51 | dom96 | Because that's not implemented? |
| 21:49:59 | Araq | Varriount: the database is not shared between the different testing machines |
| 21:50:07 | dom96 | That too. |
| 21:50:12 | Araq | nimbuild is supposed to deal with that |
| 21:50:53 | Varriount | How is nimbuild supposed to "assimilate" the sqlite db? |
| 21:51:41 | dom96 | What I meant was that NimBuild will keep a central sqlite db with the test results which it will populate on its own |
| 21:51:55 | Varriount | dom96: You mean the hub? |
| 21:52:01 | dom96 | Yes |
| 21:52:30 | * | carum joined #nimrod |
| 21:52:58 | Varriount | So why can't each individual tester use it's own sqlite database? The functionality is not that hard to implement, and more efficient than having the tester essentially dump the entire database into json. |
| 21:53:45 | dom96 | Because you can't easily compare the data as it's not centralised. |
| 21:53:58 | dom96 | The db functionality will be removed from the tester at some point |
| 21:54:53 | Varriount | And how would storing the data in JSON allow it to be centralized? |
| 21:55:18 | Araq | Varriount: the JSON is the *message* format, it will be put into the sqlite database by nimbuild |
| 21:55:42 | Araq | also it doesn't dump the entire database at all, but the rests belonging to the current commit |
| 21:55:42 | dom96 | The builder will read the JSON file, send the data to the hub, the hub will then save the data to the sqlite database. |
| 21:55:48 | Araq | *results |
| 21:56:11 | * | carum_ joined #nimrod |
| 21:57:22 | * | carum quit (Ping timeout: 265 seconds) |
| 21:57:23 | Varriount | Oh, I must have misunderstood what was meant by "all tests" - I had thought it entailed the dumping of all test runs performed by the tester. |
| 22:01:54 | * | Demos joined #nimrod |
| 22:14:10 | dom96 | Araq: babel install aporia#head |
| 22:14:25 | dom96 | Save as bug should be fixed. |
| 22:27:06 | Araq | dom96: I know but it's not annoying enough to make me update aporia |
| 22:27:07 | Varriount | dom96: You want only the categories you listed above, correct? |
| 22:27:34 | Araq | Varriount: you need to join machine, commit, testresults and provide that information |
| 22:27:52 | dom96 | commit and machine info is not necessary |
| 22:28:17 | Araq | yes it is |
| 22:28:25 | dom96 | Why? |
| 22:28:43 | Araq | I don't trust git enough, so commit is useful redundant information |
| 22:28:53 | Araq | same for machine |
| 22:29:04 | dom96 | huh |
| 22:29:14 | dom96 | How does the tester get this info if not from git? |
| 22:29:30 | * | renesac joined #nimrod |
| 22:29:58 | dom96 | There is no point in putting this info in the json since the builder knows it already. |
| 22:30:34 | Araq | how can the builder know about the commit on the test machine? |
| 22:31:49 | dom96 | The hub tells it. |
| 22:32:19 | Araq | so the test client checks out the commit the hub told it to? |
| 22:32:37 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:32:38 | dom96 | "test client"? |
| 22:32:43 | dom96 | The builder does. |
| 22:32:45 | Araq | test machine |
| 22:39:33 | Varriount | To be fair, the builder doesn't really have the commit, just a series of relative versions. |
| 22:40:25 | dom96 | I'm not sure what you mean by that. |
| 22:40:49 | dom96 | When I say "commit" I really mean "commit hash" btw. |
| 22:41:00 | dom96 | And the builder does have that info. |
| 22:44:09 | Varriount | dom96: https://gist.github.com/Varriount/9421729 |
| 22:44:22 | Varriount | Is that what you want? |
| 22:45:27 | dom96 | yes, perfect. |
| 22:45:55 | Varriount | It was surprisingly easy. |
| 22:46:13 | Varriount | (I haven't had much experience with SQL) |
| 22:46:50 | Demos | YAYAYAYAYAY I fixed the error |
| 22:47:27 | Demos | turns out that I was using an array of uints for indices and telling OGL they were of type GL_UNSIGNED_INT, which is a 32bit uint, nimrod's default uint is 64 bit |
| 22:49:43 | Varriount | *gasp* Demos mentioned one of the u-words! |
| 22:50:06 | Demos | it is actually worth using the unsigned ints in this case I think |
| 22:50:17 | Demos | I mean it is an index buffer |
| 22:50:46 | Demos | still that took a good 6h of solid debugging |
| 22:50:50 | Demos | grr |
| 22:50:54 | * | yawnt joined #nimrod |
| 22:51:03 | Araq | hi yawnt welcome |
| 22:51:56 | yawnt | long time no see Araq |
| 22:52:08 | Araq | indeed, I thought you were new :P |
| 22:52:26 | yawnt | we talked a bit a while ago in another chan, ##luna-lang |
| 22:52:49 | Varriount | dom96: Pull request sent. |
| 22:53:03 | dom96 | Araq: ^ |
| 22:53:09 | yawnt | i guess nimrod kinda got stuck in my mind ;P |
| 22:53:32 | Varriount | yawnt: It has a habit of doing that. Probably because its awesome :3 |
| 22:53:54 | Araq | Varriount: add the commit at least |
| 22:54:18 | dom96 | Araq: Why?! |
| 22:54:18 | Varriount | Araq: The commit is just a number. |
| 22:54:25 | Araq | since I still don't trust nimbuild, adding redundancy can't hurt |
| 22:54:40 | Araq | Varriount: I know it's just a number |
| 22:54:45 | dom96 | Araq: What redundancy?! The builder checks out the commit! |
| 22:54:58 | dom96 | It will end up being *exactly* the same. |
| 22:54:58 | yawnt | Varriount: tbh i'm just here because i like compilers |
| 22:55:44 | Varriount | Araq: How is the number '1' going to add redundancy? |
| 22:57:15 | dom96 | oh, so it's not the commit hash? |
| 22:57:51 | dom96 | It's just a count of the commits in the db? |
| 22:58:00 | Varriount | dom96: The testresults table has a commit column, but it just contains the relative new-ness of the test run (1 being the latest test run) |
| 22:58:19 | Varriount | There's another table called commit, but at least on my machine, it contains nothing |
| 22:58:22 | dom96 | So it'll always be '1'? |
| 22:58:29 | Varriount | Unless my db viewer is broken. |
| 22:58:33 | dom96 | (in the JSON) |
| 22:58:41 | Araq | argh, no |
| 22:58:50 | Varriount | dom96: Yes, if the builder sends only the results from the latest commit. |
| 22:58:54 | Araq | you have to join with the commit table to get the hash |
| 22:59:08 | Araq | and the commit table shouldn't be empty |
| 22:59:21 | dom96 | Ahh, so you do want the hash. |
| 22:59:26 | dom96 | Then I go back to what I said previously. |
| 23:00:06 | Varriount | dom96: If Araq wants that piece of extra data, let him have it. It's not like it will make a huge difference. |
| 23:00:27 | Varriount | cd koch |
| 23:00:28 | dom96 | Sure, but the builders will completely ignore it. |
| 23:00:35 | Varriount | Erms, wrong text box |
| 23:01:28 | Araq | dom96: no, you shoul check the commits are the same |
| 23:01:55 | dom96 | ALrght. |
| 23:01:59 | dom96 | *alright |
| 23:04:21 | Varriount | Yeah, nothing in the commits table is being generated, I've checked both the db for nimbuild (after running koch tests manually) and the db in my personal build. |
| 23:04:29 | * | brson quit (Ping timeout: 269 seconds) |
| 23:05:55 | Varriount | dom96: Can you check your testers? Maybe it's a Windows issue. |
| 23:06:58 | dom96 | Is there a CLI sqlite db viewer I can use quickly to do it? |
| 23:07:36 | Demos | I think sqlite comes with one |
| 23:08:59 | dom96 | What is it called and how do I use it? I don't have much experience with SQL. |
| 23:09:05 | Araq | Varriount: I'm on windows and my commit table is filled |
| 23:09:29 | Araq | dom96: you can use the SQLite Manager Firefox plugin |
| 23:09:40 | dom96 | Araq: That's not CLI. |
| 23:09:52 | Araq | good point lol |
| 23:11:07 | flaviu | dom96: No idea, but try `sqlite3 places.sqlite .dump` |
| 23:11:15 | flaviu | from serverfault |
| 23:12:22 | dom96 | "Unable to open database "testament.db": file is encrypted or is not a database" |
| 23:12:41 | dom96 | flaviu: Thanks though. |
| 23:17:01 | Skrylar | dom96: I'm not sure if introducing a language by mentioning "there is a lot of work that needs done on it" is the best advertisement. lol |
| 23:17:47 | dom96 | Skrylar: Where did I say that? |
| 23:18:06 | Skrylar | https://news.ycombinator.com/item?id=7361593 "There is plenty to do, the most important of which is fixing compiler bugs but I'm certain that most people would not like to start with that." |
| 23:18:37 | dom96 | "there is a lot of work that needs done on it" != "there is plenty to do" :P |
| 23:19:07 | Skrylar | it might as well read the same :( |
| 23:19:11 | dom96 | But yeah. I could've worded it better. |
| 23:19:20 | Skrylar | anyhow, the CLI program is just called "sqlite3" and it comes from the sqlite3 page |
| 23:19:24 | dom96 | Oh well, it's at the bottom of the thread anyway |
| 23:19:29 | Varriount | "Compiler Bugs" does not instill confidence |
| 23:19:34 | Skrylar | ^ |
| 23:20:06 | Skrylar | I hate when it turns out i abandoned an almost full can of soda on my desk. |
| 23:20:12 | Demos | we are at version 0.9.2/3 what do people expect |
| 23:20:12 | Skrylar | a sad waste :( |
| 23:20:21 | dom96 | So it's better to lie? |
| 23:20:30 | Varriount | Demos: People always expect more than they should. |
| 23:20:49 | Skrylar | Usually when advertising you go on about how it has all these awesome things that make you envious to use it |
| 23:20:56 | Varriount | ^ |
| 23:20:59 | dom96 | "The compiler is extremely stable, so er... well... I guess you can write software with it." |
| 23:21:06 | Skrylar | no, you just don't mention it |
| 23:21:21 | dom96 | Well, I wrote it quickly. |
| 23:21:29 | Skrylar | "This is our new systems language C++0x, it has a compile time of ass and its designed by a massive ocean barge, use it today!" |
| 23:21:30 | Skrylar | :D |
| 23:21:31 | Varriount | The compiler has backends for C, C++, Objective C, and Javascript. |
| 23:22:21 | Varriount | The language is flexible, allowing for multiple programmatic approaches to problems in a non-restrictive methodology. |
| 23:24:21 | dom96 | In any case I don't see you guys writing *anything* |
| 23:24:43 | Varriount | I'm fixing commit stuff on my system. Plus, you didn't ask me to write anything. |
| 23:24:44 | Araq | I upvoted you ... |
| 23:24:47 | Skrylar | aside from unicode grapheme support and better hashtables :\ |
| 23:25:17 | Araq | Skrylar: dom96 meant reddit/hn spamming |
| 23:25:35 | dom96 | Araq: I don't think upvoting works for you on HN still... :\ |
| 23:25:45 | Araq | -.- |
| 23:26:16 | dom96 | I don't get it. |
| 23:27:11 | Varriount | I think I figured out why the commit stuff wasn't working. |
| 23:27:39 | Araq | Varriount: interesting. what's the cause? |
| 23:27:57 | Varriount | http://stackoverflow.com/questions/7949956/why-does-git-diff-on-windows-warn-that-the-terminal-is-not-fully-functional |
| 23:29:46 | Varriount | Also, for some reason all the .git directories are missing from the nimbuild's internal nimrod repo. |
| 23:30:05 | Varriount | Owait, they're hidden. |
| 23:30:23 | Araq | good night |
| 23:30:37 | Varriount | "fatal: ref HEAD is not a symbolic ref"? |
| 23:31:51 | dom96 | Achievement unlocked: got git to fail with a fatal error. |
| 23:36:23 | flaviu | Is there any documentaion on type classes or example code? |
| 23:37:06 | dom96 | http://build.nimrod-lang.org/docs/manual.html#type-classes |
| 23:37:49 | flaviu | Thanks, I had no idea there were newer docs |
| 23:39:08 | NimBot | nimrod-code/nimbuild master c6e4afc Dominik Picheta [+0 ±1 -0]: Updated structure doc. |
| 23:39:39 | * | psquid joined #nimrod |
| 23:47:52 | Varriount | dom96: We really need to make certain resources more available :/ |
| 23:48:40 | Varriount | Like the fact that dev builds are available, that there's up-to-date documentation, etc |
| 23:49:20 | dom96 | yes |
| 23:52:00 | flaviu | Especially since much of the official release docs are _totally_ empty of any explaination |
| 23:56:32 | Varriount | flaviu: Are the dev docs that much better? |
