| 00:15:01 | * | q66 quit (Remote host closed the connection) |
| 00:52:42 | NimBot | Araq/Nimrod cf47ff4 Araq [+0 ±12 -0]: first steps to implement object construction expressions |
| 06:31:49 | Zor | Araq: poke |
| 07:10:12 | Zor | Araq: a couple of things: |
| 07:10:24 | Zor | 1) how do you identify non-nimrod stack frames (if at all)? |
| 07:10:34 | Zor | 2) can your shadow stack somehow let the debugger mutate locals? |
| 07:11:10 | * | Trix[a]r_za quit (Ping timeout: 260 seconds) |
| 07:14:03 | * | Trix[a]r_za joined #nimrod |
| 08:12:44 | * | gour joined #nimrod |
| 09:44:00 | * | xcombelle joined #nimrod |
| 09:53:12 | * | Araq_ joined #nimrod |
| 10:05:40 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]) |
| 13:17:25 | * | q66 joined #nimrod |
| 14:56:58 | * | Trix[a]r_za is now known as Trixar_za |
| 14:58:47 | * | gour quit (Disconnected by services) |
| 14:58:47 | * | gour_ joined #nimrod |
| 15:08:22 | * | gour_ is now known as gour |
| 15:26:19 | * | XAMPP quit (Read error: Connection reset by peer) |
| 16:11:32 | * | Trixar_za quit (Quit: ZNC - http://znc.in) |
| 16:12:32 | * | Trixar_za joined #nimrod |
| 16:31:11 | * | Trixar_za is now known as Trix[a]r_za |
| 18:19:55 | NimBot | Araq/Nimrod 2c1cc72 Araq [+0 ±3 -0]: next steps for object construction expressions |
| 18:19:55 | NimBot | Araq/Nimrod 0833974 Araq [+0 ±2 -0]: next steps for object construction expressions |
| 19:38:20 | Araq | Zor: 1) there is no need for that; non-nimrod stack frames are ignored implicitly by the shadow stack linked list structure |
| 19:38:52 | Araq | 2) it would be quite easy to implement, yes; but the debugger doesn't have such a feature for now |
| 19:39:55 | Zor | reason for (1) is that the C functions won't show up in stack traces |
| 19:42:05 | * | xcombelle quit (Read error: Connection reset by peer) |
| 19:46:46 | Araq | true but you can't do much about it |
| 19:47:17 | Araq | there is also code for generating a stack trace using Linux specifics |
| 19:47:35 | Araq | but it's fragile |
| 19:47:51 | Araq | and I haven't tested it for years |
| 19:48:49 | Zor | one thing you could do for C functions is, whenever a non-nimrod function is called, insert a dummy "Nimrod -> External" stack frame, and then an "External -> Nimrod" stack frame when it returns |
| 19:49:01 | Zor | (dummy as in no locals and so on) |
| 19:51:02 | Araq | good idea but the stack traces are already fine the way they are |
| 19:51:38 | Araq | more important would be to introduce dummy stack frames for instantiated macros |
| 19:53:53 | Araq | also note that the stack trace contains line information |
| 19:54:20 | Araq | so it points to a line that contains a call to some external C code |
| 20:01:30 | * | ccssnet quit (Quit: http://atccss.net) |
| 20:04:36 | * | ccssnet joined #nimrod |
| 20:42:47 | Zor | how do you get line information in there? update the shadow stack as you go? (within the same function) |
| 20:56:03 | Araq | exactly |
| 20:57:30 | Araq | "before every instruction" injections are necessary for breakpoint support anyway |
| 21:04:11 | * | filwit joined #nimrod |
| 21:04:19 | filwit | hi folks |
| 21:10:41 | Araq | hey filwit |
| 21:12:34 | Araq | fyi constructors are almost finished |
| 21:12:51 | Araq | the syntax is TObject(x: 1, y: 2) |
| 21:12:58 | filwit | interesting. |
| 21:13:22 | filwit | so: var x = TFile("...") ? |
| 21:13:36 | filwit | type of thing? |
| 21:13:40 | filwit | is possible? |
| 21:13:54 | Araq | not really for TFile as it's opaque |
| 21:14:07 | filwit | well, i just used that as an example |
| 21:14:10 | Araq | and it's the opposite of what you desire |
| 21:14:37 | Araq | as it's for internal usage only, you should export a constructor proc |
| 21:14:58 | filwit | how do you define a constructor? |
| 21:15:26 | Araq | like before: proc initT(x, y: int): T = T(x: x, y: y) |
| 21:16:02 | filwit | ahhh... so a constructors params are just a init-list? |
| 21:16:18 | Araq | yeah |
| 21:16:21 | * | gradha joined #nimrod |
| 21:16:23 | filwit | i see |
| 21:16:26 | Araq | it's really like tuple construction |
| 21:16:36 | filwit | makes sense. |
| 21:16:44 | Araq | so no changes to the stdlib, factories continue to work |
| 21:17:00 | filwit | yes |
| 21:17:03 | Araq | but we gain non-nilable types as a side effect |
| 21:17:24 | Araq | and it fixes a loophole in the language wrt case objects |
| 21:17:53 | filwit | wrt? |
| 21:18:13 | filwit | also, nimrod now supports non-nilable types? |
| 21:18:34 | gradha | wrt == with regards to |
| 21:18:43 | filwit | gradha: thanks |
| 21:18:45 | Araq | the syntax is there and the compiler catches trivial mistakes already |
| 21:18:45 | gradha | case objects == object variants (aka kind field) |
| 21:18:50 | Araq | wrt == with respect to |
| 21:19:09 | gradha | true, I lost respect a long time ago |
| 21:19:34 | filwit | you lost respect for case-objects? |
| 21:19:47 | filwit | i always thought there where kinda a neat little Nimrod feature |
| 21:19:48 | gradha | I just generally lost respect |
| 21:20:01 | filwit | (though i with there where simple Unions) |
| 21:20:11 | gradha | variants are fun, ever thought of nested variants? |
| 21:20:28 | filwit | i see, so you are now not a respectable person. |
| 21:20:58 | filwit | variants = dynamic type vars? |
| 21:21:09 | gradha | err.. sorry, object variants |
| 21:21:09 | filwit | in that case, variants aren't fun |
| 21:21:17 | gradha | one case object which contains sub-case objects |
| 21:21:32 | filwit | isn't that basically what case-objects are? |
| 21:21:32 | Araq | gradha: I think the grammar disallows that |
| 21:21:56 | Araq | but you can work around with an explicit type defintion |
| 21:22:27 | filwit | i had a good idea once for a built-in state machine object structure |
| 21:22:41 | filwit | but it had a lot to with with time-transitions |
| 21:22:57 | filwit | so ultimately i think it would be best to do it in a library |
| 21:23:10 | filwit | but that's neither here nor there |
| 21:23:49 | filwit | anyone else pissed about "Mir"? |
| 21:23:57 | gradha | maybe you could make ragel output nimrod |
| 21:24:02 | gradha | what's "Mir"? |
| 21:24:21 | filwit | Ubuntu's new Display Server |
| 21:24:25 | filwit | nevermind |
| 21:24:36 | filwit | just save yourself a headache and don't look it up |
| 21:24:40 | gradha | isn't that like progress? |
| 21:24:49 | filwit | not when there's Wayland |
| 21:25:20 | filwit | and Mir is far behind... and not compatible.. and started secretly 9 months ago.. without attempt to communicate with Wayland devs |
| 21:25:49 | Araq | filwit: what do you suggest for reading about graphics algorithms? |
| 21:26:03 | filwit | and all future Ubuntu core apps with be Mir based... which means they wont run on Wayland unless there's a xmir (like xwayland), etc |
| 21:26:18 | filwit | it basically divides the whole Linux ecosystem unless one dies off |
| 21:26:31 | gradha | so, like every time people want to do something |
| 21:26:35 | filwit | Araq: hmmm... one sec |
| 21:26:38 | Araq | ubuntu is dying afaict |
| 21:26:52 | filwit | Araq: well first, what do you want to know about in terms of "graphics"? |
| 21:27:11 | Araq | hmm I dunno :-) |
| 21:28:07 | gradha | Araq: learn about photon mapping, write a photon mapping renderer software in nimrod, make it work on a toaster |
| 21:28:12 | filwit | yes, now every future Linux application will probably need to support both Mir and Wayland... cause neither is probably going away, even if Nvidia/AMD back only one (which is likely) |
| 21:28:41 | Araq | for instance, why did ecstatica manage to produce ellipsoids and Doom 3 did not? |
| 21:29:03 | filwit | ellipsoids where built into the OpenGL/DX pipeline a long time ago |
| 21:29:10 | filwit | but no one used them in reality |
| 21:29:17 | filwit | and you can recreate them in shaders |
| 21:29:48 | filwit | the graphics pipeline has become much more programmable in the last few years |
| 21:30:08 | Araq | interesting and yet I still see polygons |
| 21:30:23 | filwit | well, that has to do with the hardware |
| 21:30:30 | Araq | for things that should be *round* ;-) |
| 21:30:44 | filwit | you've heard of DirectX 11 tessellation? |
| 21:30:47 | gradha | trouble is rarely anything is round |
| 21:30:51 | filwit | (same tech is in OpenGL) |
| 21:31:12 | filwit | the reason you see polygons still is a memory issue mostlys |
| 21:31:24 | Araq | gradha: nor is it angular |
| 21:31:27 | filwit | and the fact that hardware tessellation isn't fast enough (yet) |
| 21:31:34 | filwit | there's a cut-off |
| 21:31:43 | filwit | but things are changing on the memory front |
| 21:31:53 | filwit | for instance, PS4 has 8Gb shared memory |
| 21:32:07 | filwit | which means you could literally have almost all of that for Textures |
| 21:32:21 | filwit | that's 4x more than todays best cards |
| 21:32:26 | Araq | I don't get it really; of course if you approximate round things with polygons that takes lots of them and so memory is an issue |
| 21:32:39 | filwit | yes |
| 21:32:51 | filwit | but remember about LOD |
| 21:33:04 | filwit | in the background, you don't want to render a million poly model just for a few pixels |
| 21:33:18 | filwit | so you have multiple versions of the model in ram |
| 21:33:20 | filwit | and choose the version |
| 21:33:34 | filwit | Hardware tessellation improves that |
| 21:33:42 | Araq | but my point is: why approximate everything with polygons in the first place? |
| 21:33:52 | filwit | you can dynamically add polygons (no ram needed) and offset them to be more round |
| 21:34:04 | gradha | maybe polygons are simpler to draw/handle than ellipsoids? |
| 21:34:07 | Araq | ecstatica didn't use polygons |
| 21:34:15 | Araq | and it's from 1994 |
| 21:34:23 | gradha | it's software too |
| 21:34:27 | gradha | you had voxels in software |
| 21:34:30 | filwit | Araq: because for the level of detail our cards can handle today, it's the most efficient technique |
| 21:34:48 | filwit | Araq: games from '94 rendered on the CPU |
| 21:34:58 | Zor | Araq: how do you do breakpoints, btw? atomic boolean flag + a lock or something like that? |
| 21:35:28 | Araq | why not have voxels, ellipsoids and polygons in the same engine? |
| 21:35:35 | filwit | Voxels uses a ray-tracing algorithms |
| 21:35:52 | filwit | that's best done on a scalar CPU, not a vector GPU |
| 21:36:16 | filwit | polygons are rasterized (they all render into a buffer) |
| 21:36:33 | filwit | voxels, each pixel is traced through a voxel grid |
| 21:36:54 | filwit | and there's a lot of "if voxel, continue or stop" situations |
| 21:37:13 | filwit | where as polygons is like "giant list of polys; render them all as fast as possible" |
| 21:37:31 | Araq | Zor: before every instruction something like 'debug(currentPosition);' is executed and in 'debug' it's checked whether the current position has been marked as a break point; no threading is involved |
| 21:37:49 | filwit | the thing is there's a cut-off with detail vs speed |
| 21:38:03 | filwit | polygons can be textured and made to "fake" high detail |
| 21:38:10 | Zor | Araq: so how do you actually pause execution if the current position is a breakpoint? |
| 21:38:10 | filwit | with a low amount of polygons |
| 21:38:11 | Araq | I understand that |
| 21:38:18 | filwit | where is Voxels can't really do that |
| 21:38:36 | filwit | so in order to get good texture detail in Voxels, you need really fast CPUs |
| 21:38:42 | Araq | Zor: it's suprisingly easy when you think about it ;-) |
| 21:38:47 | filwit | and we just haven't reached that point yet |
| 21:38:53 | filwit | but we're almost there |
| 21:39:05 | filwit | in fact, Voxel rendering is a part of all new game-engines |
| 21:39:10 | filwit | just not in the way you might think |
| 21:39:27 | filwit | they use it for real-time global illumination (light bouncing) |
| 21:39:39 | Araq | Zor: the debugger may end up calling the console's readline in the 'debug' function |
| 21:39:55 | Zor | I see |
| 21:40:04 | filwit | and they render a really low-res voxel image of the scene, so the shaders can pick up colors from walls witch indirect illumination, etc |
| 21:40:04 | Zor | you'd need more complex machinery for a remote debugger api though |
| 21:41:54 | Araq | Zor: actually all that's necessary is to provide a better system.dbgLineHook() (http://nimrod-code.org/system.html#539) |
| 21:42:12 | Araq | and then let people can write their own debuggers |
| 21:42:41 | Araq | it's much easier to do this in "user space" when you can in fact use the stdlib for sockets etc. |
| 21:43:49 | Araq | the Nimrod profiler uses this approach |
| 21:44:22 | Araq | it works quite nicely though the timings are always off |
| 21:45:28 | Araq | filwit: but an engine could easily send the polygons to the GPU and the voxels and ellipsoids to the CPU to process |
| 21:45:57 | Araq | that's just some low level optimization stuff |
| 21:46:12 | filwit | Araq: no, you have a big limit with the bus-line to/from GPU-CPU |
| 21:46:15 | gradha | good luck merging the results, like figuring depth for voxels mixed with polygons |
| 21:46:48 | filwit | Araq: the GPU has it's own memory, where all the graphics are (ideally) stored, and that's how you get good performance |
| 21:47:01 | Araq | voxels + polygons have been tried in "Outcast" and it worked, gradha |
| 21:47:16 | filwit | Araq: on a system like Xbox 360 (and PS4) you have a Shared Memory system, so Voxels becomes a little more realistic |
| 21:47:28 | Araq | filwit: I know but performance is not my point |
| 21:47:49 | Araq | but I guess your point is that performance disallows such a "mixed mode" I envision? |
| 21:47:49 | filwit | gradha: actually, getting things like depth, etc from the voxels isn't a challenge at all |
| 21:48:09 | filwit | Araq: have you seen the Atomatage engine? |
| 21:48:18 | Araq | nope |
| 21:48:19 | filwit | http://www.atomontage.com/ |
| 21:48:27 | filwit | he rendering the Voxels on the CPU |
| 21:48:33 | filwit | then overlays polygons on the GPU |
| 21:48:40 | gradha | filwit: try that with translucency |
| 21:49:03 | filwit | gradha: translucency is a problem even for modern polygons engines |
| 21:49:27 | filwit | gradha: Deferred Rendering can't really handle translucency (all modern engines use it) |
| 21:50:01 | filwit | so you render all your regular (opaque) stuff deferred, and all translucent stuff afterwards |
| 21:50:36 | gradha | and trying to merge translucent voxels with translucen polygons is going to be just fun |
| 21:50:49 | gradha | of course you can restrict one to be solid |
| 21:51:32 | filwit | gradha: yes, there's a challenge with translucency these days, with whatever technique |
| 21:51:32 | Araq | filwit: I remember that site ;-) so ... when will they add ellipsoids? |
| 21:51:47 | filwit | gradha: that's why a pure, traced, voxel system would be best |
| 21:52:07 | filwit | gradha: you could do true refraction and things that way. |
| 21:52:21 | filwit | gradha: the problem with that is animation... voxels don't animate so well |
| 21:52:47 | filwit | Araq: ellipsoids are possible through shaders |
| 21:53:05 | filwit | Araq: they never really went away, just no one uses them |
| 21:53:05 | Araq | and yet I've never seen one :P |
| 21:53:15 | Araq | yeah but why? |
| 21:53:30 | filwit | because defining complex shapes is difficult with them |
| 21:53:43 | filwit | the best you can get is circles and spheres |
| 21:54:00 | filwit | and usually you're breaking the ZBuffer pipline |
| 21:54:03 | filwit | which is slow |
| 21:54:24 | filwit | you have to perform your own depth-tests in the shader |
| 21:54:46 | filwit | and there's a lot of hardware optimization on polygon depth-testing |
| 21:55:22 | filwit | besides... why do you even want ellipsoides? |
| 21:55:30 | filwit | what are you trying to achieve? |
| 21:55:39 | gradha | tits |
| 21:55:44 | filwit | ^ LOL |
| 21:56:39 | filwit | i see the appeal then... who wants to render a jagged set of tits. |
| 21:57:21 | gradha | DOA Volleyball 3000, more curves than you can imagine |
| 21:57:50 | filwit | god, that "game" |
| 21:58:02 | filwit | was so retarded... but i bet it made so much money |
| 21:58:42 | Araq | filwit: nothing concrete really, but it's 2013 and I'm tired of angular objects which are round in the real world |
| 21:59:39 | gradha | Araq: maybe you lack a decent card/machine? the videos or rendered action I see nowadays are worse because of mpeg arctifacts than visible polygons |
| 21:59:50 | filwit | Araq: it's mostly about the hardware at this point. we've hit a ceiling in all hardware |
| 21:59:57 | gradha | filwit: talking about money, more than 1M$ in less than 5h http://www.kickstarter.com/projects/inxile/torment-tides-of-numenera |
| 22:00:22 | filwit | Araq: the only way forward is to do what Parrallella is doing (many core CPUs) and then use them for Voxel Raytracing |
| 22:02:14 | gradha | oh man, that's funny, they are exploring parallella support for python |
| 22:03:45 | filwit | what a waist... Python wont do the chip justice |
| 22:03:51 | gradha | well, indeed that will be challenging, I can understand that from the POV of enterntainment |
| 22:03:51 | filwit | (watching video |
| 22:04:15 | filwit | what will be challenging? |
| 22:04:37 | gradha | the global interpreter lock |
| 22:05:11 | * | filwit is unaware of Phython specifics |
| 22:05:37 | gradha | the interpreter uses a global lock which prevents two python instructions from running at the same time (in general terms) |
| 22:05:49 | gradha | so most of python parallelization comes from running separate processes or calling C |
| 22:06:19 | gradha | at some point during 2.x development they tried to remove the GIL and found that the GILless version ran slower, and didn't scale as well as thought |
| 22:06:37 | filwit | i see |
| 22:06:49 | filwit | so it's about the worst language to try and port o Parrallella? |
| 22:07:00 | Araq | quite |
| 22:07:03 | gradha | yep |
| 22:07:08 | filwit | perfect |
| 22:07:16 | Araq | Ruby does the same and it's interpreter was AST based |
| 22:07:31 | Araq | so Ruby 1.8.7 would be even better for that |
| 22:07:34 | filwit | Python is not AST based!? |
| 22:07:40 | Araq | no |
| 22:07:42 | filwit | wut |
| 22:07:44 | filwit | how? |
| 22:07:53 | Araq | it compiles to its own shitty bytecode |
| 22:08:04 | filwit | ah, i see |
| 22:08:10 | Araq | there is an AST involved during compilation of course |
| 22:08:25 | Araq | well not "of course", actually it's quite easy to do without |
| 22:08:33 | Araq | like Lua does |
| 22:08:49 | filwit | Lua doesnt use an AST for compiling... |
| 22:09:00 | filwit | it has to use something |
| 22:09:38 | filwit | even spaghetti code functions need some form of data structures to pass around |
| 22:09:45 | Araq | it uses a symbol table and some temporary data structures for codegen |
| 22:10:39 | Araq | just like the early Pascal and C compilers did |
| 22:10:49 | Araq | a real *one* pass compiler ;-) |
| 22:10:59 | filwit | i see |
| 22:11:17 | filwit | my compiler is written in Brainfuck |
| 22:11:20 | filwit | just so you know |
| 22:11:29 | Araq | good choice |
| 22:11:30 | filwit | cause i'm l33t and hardcore |
| 22:11:33 | filwit | lol |
| 22:11:47 | filwit | (it's really written in C++) |
| 22:12:13 | Araq | visitor pattern? |
| 22:12:25 | filwit | what? |
| 22:12:46 | Araq | do you use the visitor pattern in your compiler? |
| 22:12:59 | filwit | i don't know what that is... |
| 22:13:04 | filwit | one sec |
| 22:13:05 | Araq | good |
| 22:13:09 | Araq | no |
| 22:13:13 | Araq | don't read what it is |
| 22:13:17 | filwit | lol |
| 22:13:20 | Araq | it's crap |
| 22:13:21 | filwit | reading now |
| 22:13:34 | Araq | it's the worst way to design a compiler |
| 22:13:42 | filwit | idk, this is the first time I've tried to write a compiler |
| 22:13:57 | filwit | and it's kinda structure like a 3D modeling program (which i've written in the past) |
| 22:14:10 | Araq | lol |
| 22:14:26 | filwit | basically, every type/function/var etc maintains dynamic lists to declarations and stuff |
| 22:14:39 | gradha | you can argue with Araq then if instructions by your compiler are rendered as polygons, voxels or ellipses |
| 22:14:52 | filwit | so if you change something, the structure can instantly react to the changes (designed for IDE tooling support) |
| 22:15:27 | filwit | gradha: lol.. they're voxels, obviously |
| 22:15:58 | Araq | filwit: you really shouldn't write that in C++ |
| 22:16:12 | Araq | but then you want an LLVM backend ... hm |
| 22:16:57 | filwit | Araq: i was thinking about writting it in D or Nimrod, but I want to support JIT compilation (as well as interpreted and native), and (for some reason) i don't want the runtime component to rely on a GC (especially not D's GC) |
| 22:17:06 | filwit | and yes, LLVM is an issue |
| 22:17:19 | filwit | LLVM has C bindings, but the C++ ones are much better |
| 22:17:38 | filwit | plus, i use a lot of C++11 features |
| 22:17:44 | filwit | so it's not all that bad |
| 22:17:54 | filwit | foreach loops and stuff make the code much more readable |
| 22:18:04 | filwit | and the 'auto' keyword... |
| 22:18:18 | Araq | C++11 still lacks pattern matching though |
| 22:18:25 | filwit | i use STL containers not Boost though... |
| 22:18:30 | filwit | dont' know if that was a good choice |
| 22:19:04 | Araq | and a GC is really NICE for writing a compiler |
| 22:19:15 | gour | Araq: what about pattern matching in nimrod? |
| 22:19:17 | filwit | yeah, if I could, i would use something else, but practically speaking, C++ is the best option... until Reign (my language codename) is bootstrappable |
| 22:20:01 | Araq | the GCC people patched their compiler with an home-brew GC |
| 22:20:27 | Araq | because maintainance was a nightmare otherwise |
| 22:20:34 | filwit | yes, but again, JIT compiling distribution is my concern there... |
| 22:20:43 | filwit | now that i think about it |
| 22:20:47 | filwit | that's not much of a concern |
| 22:20:54 | filwit | but still, there's also LLVM |
| 22:20:59 | filwit | which is designed for C++ |
| 22:21:10 | Araq | true |
| 22:21:11 | filwit | so i don't have to wrap that into Nimrod/D |
| 22:21:26 | Araq | we have an LLVM wrapper |
| 22:21:30 | filwit | and then i'd have to use LLVM's C bindings, etc |
| 22:21:35 | filwit | really? |
| 22:21:40 | filwit | i thought you hated LLVM |
| 22:21:40 | Araq | but it's a wrapper around the C bindings |
| 22:21:49 | filwit | oh... i see |
| 22:21:52 | filwit | i didn't know that |
| 22:21:53 | Araq | I don't hate it at all |
| 22:22:04 | Araq | it's just more work than emitting C |
| 22:22:11 | filwit | i see |
| 22:22:20 | Araq | and their type API was crap |
| 22:22:30 | filwit | but ultimately, it (in my opinion) is very important for popularity |
| 22:22:41 | filwit | one thing i think Nimrod should do |
| 22:22:43 | Araq | so crappy that it's easier to produce their textual representation |
| 22:23:08 | filwit | to help it gain popularity, is remove forward-declaration and use LLVM or GCC directly |
| 22:23:21 | gradha | filwit: why is JIT a concern for you? |
| 22:23:25 | Araq | gour: we already have exhaustiveness checking in case statements and proper pattern matching can easily be implemented via a macro |
| 22:23:37 | filwit | gradha: JIT IMO, is the most logical compilation model |
| 22:24:10 | filwit | gradha: if all programs where JIT, then you could have the benefits of a Gentoo based distro, without all the slow compilation times |
| 22:24:14 | Araq | filwit: porting it to either LLVM or GCC takes a year |
| 22:24:27 | Araq | and it's a bad decision |
| 22:24:36 | filwit | gradha: i dont' like VMs, but I like JIT |
| 22:24:48 | Araq | because people like to use Visual C++ with it or Intel's compiler |
| 22:25:01 | gradha | filwit: I like forward declarations |
| 22:25:10 | filwit | Araq: well that's a choice you can make, but I think you scare a lot of potential users away from the langauge with "Compiled to C" |
| 22:25:37 | filwit | Araq: of course, this is marketing tactics, not technical aspects |
| 22:25:44 | Araq | filwit: they are scared by everything else too anyway |
| 22:25:50 | dom96 | I know a lot of people for whom "Compiled to C" is a very big feature. |
| 22:25:51 | gradha | which reminds me latest LLVM removed requirement of objc forward declaration inside compilation unit |
| 22:25:54 | filwit | Araq: so if there are more pressing concerns, then you have to account for those variables |
| 22:26:25 | gradha | filwit: compiled to c made me go with nimrod |
| 22:26:26 | filwit | gradha: you may like forward-declaration, but statistically speaking, i doubt the majority of coders do |
| 22:26:40 | gradha | well, statistically speaking, nimrod is not going anywhere |
| 22:26:54 | filwit | that's a horrible outlook |
| 22:27:01 | filwit | and is depressing |
| 22:27:10 | Araq | D has no forward declarations; it has lots of related bugs instead |
| 22:27:16 | gradha | that's why we don't do things statistically |
| 22:27:23 | filwit | Araq: C# does not |
| 22:27:36 | Araq | filwit: C# has no meta programming to speak of |
| 22:27:40 | Araq | big difference. |
| 22:27:48 | filwit | Araq: true, but I have solutions to those things |
| 22:27:53 | dom96 | C# also has a big company behind it. |
| 22:28:03 | gradha | and Miguel |
| 22:28:10 | Araq | filwit: so do I |
| 22:28:11 | gradha | that's like a company and a hippy |
| 22:28:18 | filwit | dom96: that matters of course, but look what Araq (one guy) has achieved in a 7 years |
| 22:28:24 | Araq | but as I said, zahary will remove them |
| 22:29:01 | Araq | I fear their removal tbh |
| 22:29:05 | dom96 | filwit: Yes, think about what he could accomplish with proper funding. |
| 22:29:23 | gradha | casino! black jack! |
| 22:29:43 | filwit | dom96: unfortunately, and i say this with the best of intentions, he will never get funding if popularity is not a concern |
| 22:29:58 | dom96 | filwit: I agree. |
| 22:30:00 | Araq | omg ... here we go again ... |
| 22:30:20 | filwit | Araq: i will refrain from arguing this point, for the sake of your sanity |
| 22:30:21 | filwit | :P |
| 22:30:32 | filwit | i didn't come on here to debate this, again, anyways |
| 22:30:59 | gradha | maybe we should ask the guys who funded a succesfull kickstarter game to use nimrod to develop it? |
| 22:31:19 | filwit | wont work |
| 22:31:22 | gradha | they were crazy enough to use kickstarter, they could try nimrod too! |
| 22:31:50 | gradha | Araq: how many patents you have on nimrod? |
| 22:31:53 | dom96 | maybe we should start a kickstarter for nimrod?! |
| 22:32:25 | filwit | it wont works guys |
| 22:32:33 | filwit | sorry, that's just my opinion of course |
| 22:32:36 | gradha | dom96: the trailer could be a real time capture of the irc channel |
| 22:32:43 | filwit | but what do i know |
| 22:32:45 | dom96 | gradha: with inception music |
| 22:32:50 | filwit | you should try it and see if it works |
| 22:32:51 | gradha | and voxels |
| 22:32:57 | gradha | aalib voxels |
| 22:32:57 | dom96 | and boobies |
| 22:33:07 | filwit | if anything else, it will help you understand public opinion of Nimrod's design |
| 22:33:35 | gradha | I think the public opinion of Nimrod is "what? whitespace for identation? sux!" |
| 22:33:57 | filwit | gradha: LOL at the trailer being a caption of the IRC... perfect way to get funding |
| 22:34:17 | filwit | gradha: backed by the Inception soundtrack |
| 22:35:00 | filwit | gradha: i almost didn't try Nimrod because of Python-style indentation, but it had other attractive features |
| 22:35:09 | dom96 | Nah, it wouldn't work. We would get sued by Hans Zimmer or whoever composed the Inception OST. |
| 22:35:09 | filwit | gradha: that's really not it's problem, IMO |
| 22:35:28 | filwit | Python style is much better than Lisp or Haskell, or VB |
| 22:35:49 | dom96 | filwit: I tried Nimrod because of the Python-style indentation. |
| 22:35:58 | filwit | dom96: the lawsuit would be great for publicity |
| 22:36:00 | filwit | :P |
| 22:36:04 | Araq | funny most people complain it's not enough like Haskell ... |
| 22:36:28 | Araq | which I don't really get tbh |
| 22:36:41 | Araq | if I want Haskell, I know where to find it |
| 22:36:46 | filwit | Araq: that's cause the only people you talk to have made it through the existing documentation |
| 22:36:56 | filwit | that's nothing against the documentation |
| 22:37:15 | filwit | is just means that you're weeding out people who just turn away for whatever reason |
| 22:38:40 | gradha | so it's a problem with the documentation or with the language? |
| 22:38:50 | filwit | with the language |
| 22:39:16 | gradha | you just haven't seen the documentation I'll write, with unicorns and stuff |
| 22:39:21 | filwit | but good marketing is like the force... it works on the week minded |
| 22:39:22 | gradha | people will forget about the language |
| 22:39:32 | filwit | lol |
| 22:39:36 | gradha | they will buy the documentation, it will come in novels |
| 22:39:43 | filwit | you and Dom share common interests |
| 22:39:57 | dom96 | hah, unicorns ftw. |
| 22:40:06 | filwit | :} |
| 22:40:12 | gradha | I've been thinking about a little boy with glasses, learning magic on a flying pink unicorn |
| 22:40:21 | dom96 | filwit: btw, any new ideas for an Aporia icon? |
| 22:40:31 | filwit | good storry, add vampires and it will be a best-seller |
| 22:40:52 | filwit | dom96: i haven't really given it much thought |
| 22:40:54 | gradha | oh, right, vampires, the kind which sparkles in the light, we will get the first language with female coders |
| 22:41:03 | dom96 | don't forget the werewolves and shapeshifters. |
| 22:41:06 | filwit | i'm kinda in a pressing situation for work (dead-line wise) |
| 22:41:18 | dom96 | filwit: no worries. |
| 22:41:28 | filwit | but don't worry, i will design it |
| 22:41:59 | filwit | gradha: LOL, sudden influx of girl-coders due to awesome documentation novels |
| 22:42:08 | dom96 | holy shit, AoE2 HD: http://www.youtube.com/watch?v=q_MEFt7KrxQ |
| 22:42:14 | Araq | filwit: if you could vote for a single new feature/ change in the language, what would be it? |
| 22:42:21 | filwit | gradha: then the boys will follow, out of lust, and we'll create a social sub-culture |
| 22:42:27 | dom96 | I'm not even sorry about this being off-topic. |
| 22:42:59 | filwit | Araq: i want it to be known that you are starting this |
| 22:43:12 | filwit | Araq: strict encapsulation |
| 22:43:44 | filwit | Araq: which isn't really a "new feature", it's more of a core change |
| 22:44:26 | filwit | Araq: but honestly man, let's not get off on that now |
| 22:44:29 | gradha | dom96: wait a sec, the graphics in the video are the remastered ones? |
| 22:44:39 | filwit | Araq: just skpe with me sometime so we can talk about things |
| 22:45:22 | filwit | dom96: have you seen the PS4 trailers? |
| 22:45:43 | Araq | filwit: yeah next week, I'm pretty busy the next days |
| 22:46:06 | dom96 | gradha: I think the HD basically means "We now support 1920x1080". |
| 22:46:28 | filwit | Araq: sounds good, whenever you want to. |
| 22:46:36 | dom96 | gradha: which IMO is good because the game is still awesome, it's just a pain to play on modern operating systems. |
| 22:46:47 | Araq | filwit: however, Nimrod has encapsulation, just not in the way you think it needs to be done |
| 22:46:54 | filwit | dom96: you ever get Steam running again? |
| 22:46:58 | gradha | dom96: certainly HD version sounds much better than "we recompiled it" |
| 22:47:10 | filwit | Araq: thus the 'strict' part |
| 22:47:37 | dom96 | gradha: indeed. |
| 22:47:47 | filwit | Araq: the problem is floating functions, which are compounded by Nimrods ability to define symbol functions |
| 22:48:17 | Araq | filwit: do you know what "private" in C# actually means btw? |
| 22:48:21 | dom96 | filwit: Yeah, I can always start steam. The UI is a messed up though. |
| 22:48:34 | dom96 | filwit: As for the PS4 trailer, no I have not seen it? |
| 22:48:38 | filwit | dom96: get it from the official repos already! |
| 22:48:45 | dom96 | filwit: I did! |
| 22:48:52 | filwit | dom96: oh |
| 22:48:55 | filwit | :) |
| 22:48:55 | dom96 | filwit: That's not the issue. |
| 22:49:02 | Araq | class A { private int x; public void(A other) { other.x = 4; } } |
| 22:49:27 | filwit | PS4 trailer of Killzone: http://www.youtube.com/watch?v=8ptA6fCNPeg |
| 22:49:28 | Araq | oops ... it changes the 'other' object and not the this object ... |
| 22:49:30 | filwit | apparently that's realtime |
| 22:49:47 | filwit | Araq: what does private in C# mean? |
| 22:50:10 | Araq | "private" is no strict encapsulation either |
| 22:50:11 | filwit | Araq: ps. in my langauge, things are 'readonly' (not C#'s readonly) by default, not private or public |
| 22:50:30 | Araq | filwit: see my example code |
| 22:50:58 | filwit | Araq: i don't get it.... |
| 22:51:10 | filwit | Araq: i don't see anything out of the ordinary |
| 22:51:17 | Araq | it's some visibility thing that doesn't really capture what people have in mind when they say "encapsulation" |
| 22:51:20 | dom96 | filwit: Ahh, I saw some of that. I watched the PS4 announcement ;) |
| 22:51:41 | Araq | filwit: it accesses 'other.x' even though it's private |
| 22:51:57 | filwit | Araq: of course... even C++ does that by default |
| 22:52:03 | Araq | because privateness is bound to the class |
| 22:52:11 | Araq | but that's not what is desired |
| 22:52:20 | Araq | you want to bind it to an *instance* |
| 22:52:28 | filwit | Araq: i don't think so |
| 22:52:36 | filwit | cause all the code is part of the defining object |
| 22:52:45 | Araq | because you're *used* to the status quo! |
| 22:52:56 | filwit | no because it's logical |
| 22:53:00 | Araq | it IS confusing for newbies |
| 22:53:06 | Araq | it's not logical |
| 22:53:11 | filwit | okay, so there could be two level of private |
| 22:53:14 | Araq | it's some weird implementation issue |
| 22:53:14 | filwit | that's fine with me |
| 22:53:22 | filwit | but it is useful for some things |
| 22:53:39 | filwit | honestly i like the way C++ does it |
| 22:53:42 | Araq | because binding the concept to an instance is undecidable |
| 22:53:49 | filwit | with friend classes, even if the syntax is dumb |
| 22:53:52 | filwit | it works out well |
| 22:54:54 | Araq | so go back 30 years in time and tell Stroustrup C++ lacks encapsulation |
| 22:55:07 | Araq | because "private" doesn't cut it |
| 22:55:15 | * | gour quit (Quit: WeeChat 0.4.0) |
| 22:55:15 | filwit | Araq: it's useful to be able to work with other instance's private variables at times though... but only because they type of object is the same |
| 22:55:38 | filwit | the classic example is linked lists |
| 22:55:40 | Araq | it's also useful to just get shit done |
| 22:56:02 | filwit | what? how is that applicable to the topic? |
| 22:56:25 | Araq | instead of the endless intellectual masturbation if it should be private, public or protected |
| 22:56:32 | Araq | sorry... |
| 22:57:10 | Araq | I have yet to encounter a single bug that was actually prevented by the OO way of modelling |
| 22:57:13 | filwit | you brought it up... |
| 22:57:42 | filwit | Araq: there are ways of "doing things" in either model |
| 22:57:50 | filwit | it's about what is easier to learn, and read |
| 22:58:21 | filwit | OOP, IMO (and i think if you took a "raise of hands") is easier to conceptualize for most tasks |
| 22:58:40 | filwit | because in real-life we think in terms of objects |
| 22:58:46 | Araq | omg |
| 22:58:59 | Araq | please don't give me this bullshit |
| 22:59:07 | filwit | the person has a name, and he can do something |
| 22:59:20 | filwit | not the person has a name, and do something with him |
| 22:59:33 | filwit | whatever man, you brought it up |
| 22:59:35 | Araq | yeah and when a child grows up you have to change the instance's *class* |
| 22:59:39 | Araq | oh wait |
| 22:59:45 | Araq | OO doesn't support that |
| 22:59:57 | filwit | no.... |
| 23:00:11 | filwit | if the person CAN grow up, it's a part of the person's structure |
| 23:00:15 | filwit | Person.age |
| 23:00:23 | filwit | it's becomes dynamic |
| 23:00:33 | filwit | and you have to account for that in some way |
| 23:00:43 | filwit | i don't see how programming outside of OOP helps solve that |
| 23:01:19 | filwit | plus, i never said OOP couldn't be improved upon |
| 23:01:25 | filwit | i really like Nimrod case-objects |
| 23:01:28 | Araq | oh but it does, because you don't begin to introduce child <: person, adult <: person |
| 23:01:46 | filwit | you never would |
| 23:01:52 | filwit | introduce those two types |
| 23:01:55 | Araq | lol |
| 23:02:04 | Araq | of course you would |
| 23:02:11 | Araq | that's the point of OO :P |
| 23:02:35 | filwit | no, the point of OOP is to encapsulate functionality along with the type |
| 23:02:42 | filwit | if the type is dynamic |
| 23:02:50 | filwit | you account for that in the base type |
| 23:03:08 | filwit | if ti's not dynamic (and truely a different type), then you make a new type... |
| 23:03:11 | filwit | that's the way it works... |
| 23:03:28 | filwit | again, if there was some extension to that model, i would be all for it |
| 23:03:49 | filwit | but floating functions is confusing, and forces you to stutter the type pointlessly |
| 23:04:00 | filwit | (i dont' care that they're defined outside the type body) |
| 23:04:06 | Araq | http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf |
| 23:04:13 | filwit | i care that they're not "associated" with the type |
| 23:04:20 | Araq | I'm sure you're aware of that link |
| 23:04:33 | filwit | i'm not actually |
| 23:05:23 | filwit | again though, i'm not against extending the current OOP paradigm |
| 23:05:40 | filwit | only that I think it makes more conceptual sense in the broad sense |
| 23:06:12 | filwit | even if there are corner cases, the benefit of learn-ability in the common case easily pays for them |
| 23:06:24 | gradha | filwit: I remember more situations in life where I thought "shit, this would be better if it was NOT an object" than "shit, this would be better as an object". IMO OOP puts a constraint you hardly later remove |
| 23:07:08 | gradha | in fact, the first time I saw python I though "sweet! the methods are just functions nested with the first param as the object!", but later realized you can't use them "without" the object |
| 23:07:11 | filwit | gradha: you must not have been using an Langauge with extension functiosn like C# |
| 23:07:22 | Araq | ML, Ocaml, Haskell, F#, Go, Rust, Lisp ... |
| 23:07:30 | gradha | let me look that extension function |
| 23:07:39 | Araq | they all prefer free functions |
| 23:07:45 | filwit | so? |
| 23:07:58 | filwit | i would argue the same thing to their creators |
| 23:08:16 | Araq | Ada, C, ... |
| 23:08:27 | gradha | filwit: oh, just like objc categories, sure, use them every day, precisely because OOP sucks |
| 23:08:29 | filwit | you want a list of objects-oriented languages? maybe we can compare which ones are most popular for application code... |
| 23:08:50 | Araq | Erlang ... |
| 23:09:06 | gradha | filwit: but aren't extension functions a point against OOP rather than in favor of? |
| 23:09:15 | Araq | gradha: exactly |
| 23:09:47 | filwit | gradha: because, in my design, they cannot be global |
| 23:10:16 | filwit | meaning, you cannot extend the functionality of an object, beyond what you need to do for local things |
| 23:10:16 | gradha | so you can add to your object in a lib and people using your lib can't reuse them/access them? |
| 23:10:54 | filwit | well, you have to understand that in my design, a "Type" is the top-level object (still not 100% on that) |
| 23:11:03 | filwit | there is not modules |
| 23:11:03 | gradha | hm... so you can access only private variables, not external ones? |
| 23:11:08 | filwit | no |
| 23:11:17 | filwit | things are still private/public/readonly/etc |
| 23:11:26 | filwit | and you can have free-functions |
| 23:11:35 | filwit | but those free-functions are file-specific |
| 23:11:46 | Araq | Lua, JavaScript, ... all these horrible marketing failures ... |
| 23:11:51 | filwit | they CANNOT (unless export C) be seen outside the file |
| 23:12:22 | filwit | Araq: all of those language have more situations than OOP alone |
| 23:12:26 | Araq | filwit: Java in fact does almost enforce the style you desire |
| 23:12:42 | Araq | and yet everybody hates it nowadays |
| 23:12:48 | gradha | filwit: people in global languages achieve that with mangling, everything is global but methods for a class are "mangled" in a deterministic way so as to discourage external people form using them |
| 23:13:14 | filwit | Araq: more importantly, you're using an "argument from authority" and "argument from popularity" arguments... which i dont' find convincing |
| 23:13:42 | Araq | you argue with "argument from popularity" |
| 23:13:56 | filwit | gradha: yes i know, and in properly written C code is easy to follow |
| 23:14:09 | filwit | gradha: the problem is, it's very easy to write bad C code |
| 23:14:22 | Araq | it's far easier to write bad C++ code tbh |
| 23:14:35 | Araq | I still like C++ better though |
| 23:14:35 | filwit | Araq: my OOP design is not C++ |
| 23:14:59 | gradha | filwit: it seems that people wishing to extend the functionality of an object only for local needs could just inherit the method, so maybe you foresee the need to extend classes you can't inherhit? |
| 23:15:06 | filwit | though it does have multiple inheritance (i think) and doesn't have interfaces like D/C# |
| 23:15:30 | Araq | that's good, I prefer MI too |
| 23:16:11 | Araq | (except that I rarely even use SI) |
| 23:16:14 | filwit | Araq: yes, and interfaces are dumb... just use abstract classes (type Foo : proto)... one simple design which is more powerful |
| 23:16:58 | Araq | filwit: that's highly controversial, most people find interfaces much cleaner |
| 23:17:11 | filwit | gradha: have you ever worked with OOP? just wondering... |
| 23:17:28 | filwit | gradha: because private vars can't be set in extended types |
| 23:17:37 | filwit | gradha: so i'm not sure what you're getting at |
| 23:17:44 | Araq | no, he hide under a rock for the last 20 years |
| 23:17:57 | Araq | seriously ... I appreciate your work and feedback |
| 23:18:01 | gradha | but if they are private, how do you know they exist if you have no source? |
| 23:18:10 | Araq | but this whole "you just don't get OO" is offensive |
| 23:18:15 | gradha | I mean, there's a contradiction there, it's either private, or it's public |
| 23:18:19 | filwit | Araq: a proto type can just be an interface... if all the functions are marked as proto and dont have bodies |
| 23:18:48 | filwit | Araq: but there are many times you want base functionality in an "interface" type (something that can't be instantiated) |
| 23:19:31 | Araq | filwit: please read this if you haven't already: http://www.geocities.com/tablizer/oopbad.htm |
| 23:19:49 | filwit | Araq: also i am: a) not saying "you just don't get OOP", and b) how is that any more offensive than "you just don't understand non-OOP" which you are saying to me? |
| 23:20:12 | Araq | I don't agree with everything tablizer says |
| 23:20:29 | filwit | gradha: you have source |
| 23:20:36 | filwit | gradha: you have IDE tools |
| 23:20:38 | Araq | but seriously his arguments are better than anything I've ever heard from the OO crowd |
| 23:20:53 | filwit | gradha: you have header files for when you don't have source (and for linking), etc |
| 23:21:13 | gradha | sure, but header files don't include implementation details, or do they? |
| 23:21:28 | filwit | Araq: i will read it in a minute |
| 23:21:29 | gradha | privates are implementation details, at least in objc you don't "see" them |
| 23:21:35 | gradha | though you can "feel" them through pointer access |
| 23:21:59 | filwit | gradha: no, header files don't include implementation details |
| 23:22:22 | gradha | in that case, how could you extend a class to modify a private variable you don't "know" exists? |
| 23:22:25 | filwit | gradha: but privates are needed in header files so the compiler know the size of the type |
| 23:22:37 | gradha | well, maybe in your language |
| 23:22:38 | filwit | gradha: for linking among other thigns |
| 23:22:48 | filwit | no... that's C++ |
| 23:22:58 | gradha | yes, I don't use C++ |
| 23:23:01 | filwit | and D |
| 23:23:14 | gradha | at least we've reached the conclusion your concept of private is public as the light of day |
| 23:23:22 | gradha | that private doesn't float my boat |
| 23:23:28 | filwit | and you can never modify a private variable outside of the class definition |
| 23:23:38 | gradha | ha |
| 23:23:47 | filwit | it's part of the benefit of encapsulation (but Nimrod has it too) |
| 23:23:47 | gradha | C++ doesn't have pointers? |
| 23:24:02 | filwit | yes, you can hack set privates |
| 23:24:11 | filwit | that is a security detail |
| 23:24:18 | gradha | you can also take a header file, change all privates to public and use the compiler without problems |
| 23:24:32 | filwit | yes.. and get linking errors and stuff |
| 23:24:47 | gradha | oh, they broke that trick? |
| 23:25:02 | filwit | no it's still possible to do that, depending on the compiler |
| 23:25:14 | filwit | that has nothing to do with the design |
| 23:25:20 | filwit | and the same thing exist in Nimrod |
| 23:25:33 | filwit | I don't see your argument against OOP in these questions though |
| 23:26:00 | filwit | modern OOP langauges like D & C# define a "safe code" |
| 23:26:07 | gradha | I wasn't arguing against OOP, just trying to understand your concept of private |
| 23:26:13 | filwit | which can't use Pointers and require bounds-checking |
| 23:26:22 | gradha | I got confused with the jumps to C# mentions |
| 23:26:23 | filwit | so it's much harder to hack that way |
| 23:26:37 | filwit | oh, okay i see |
| 23:28:16 | filwit | damn, we always talk about this when i come on here |
| 23:28:20 | filwit | always |
| 23:28:43 | gradha | don't worry, Araq is surely watching the ellipsoids from the Killzone video |
| 23:28:47 | filwit | my presence details us into language philosophy |
| 23:29:13 | filwit | the Killzone video has ellipsoids!? |
| 23:29:27 | filwit | (jk, i know you where joking) |
| 23:29:48 | filwit | Araq: do you like this kind of music: http://www.youtube.com/watch?v=hCpmzP2UHjs |
| 23:29:49 | filwit | ? |
| 23:30:09 | filwit | oh wait, nevermind i think you where here when i posted that before |
| 23:31:26 | Araq | filwit: I like this kind of music: http://www.youtube.com/watch?v=ji9prBdXV_0 |
| 23:32:07 | filwit | yeah that's good |
| 23:32:08 | gradha | sounds like rammstein |
| 23:32:10 | filwit | can't understand it |
| 23:32:15 | filwit | but sounds cool |
| 23:32:52 | filwit | in HS, this kind of music was my favorite: http://www.youtube.com/watch?v=0o9u2W_iGNY |
| 23:33:19 | filwit | my brother was always the Electronic fan, an i used to think it was dumb and that no one would like it |
| 23:33:28 | filwit | but look at it now... lol was i wrong |
| 23:33:34 | filwit | plus, it's grown on me |
| 23:34:05 | gradha | people use to say the same about classical music, it's just a fad |
| 23:34:24 | filwit | i also used to really like this emo shit: http://www.youtube.com/watch?v=QTOKnYNI3tU |
| 23:34:35 | filwit | it's actually not that bad still |
| 23:34:48 | filwit | but i got sick of how depressing all of it is |
| 23:35:09 | gradha | ow, that video is blocked in my country |
| 23:35:15 | Araq | lol same here |
| 23:35:18 | gradha | is it against spanish people? |
| 23:35:24 | filwit | lol, odd... |
| 23:35:27 | Araq | but then everything is blocked here anyway due to GEMA |
| 23:35:44 | filwit | yeah, i've only had a few things blocked and way pissed |
| 23:36:09 | filwit | http://vimeo.com/39945252 |
| 23:36:10 | gradha | nowadays I rarely hear to music if it doesn't come with FullHD and sexy ladies |
| 23:36:11 | filwit | work? |
| 23:36:24 | gradha | vimeo works |
| 23:36:30 | filwit | yeah, but that's cause it's party music |
| 23:36:47 | filwit | you dont' want to listen to depressing music when you're drinking with friends |
| 23:37:28 | filwit | i think that's why kids like electronic music these days |
| 23:37:41 | filwit | it's not all "bitches and hoes", but is still uplifting (some of it) |
| 23:37:51 | gradha | I like hearing music with lyrics I don't understand (different language), so I give it the meaning I prefer however I feel |
| 23:38:21 | filwit | are you from spain or mexico/south-america? |
| 23:38:24 | gradha | in fact, I remember a song I used to think it was really sad and emo |
| 23:38:41 | gradha | then I realized I had misunderstood a part of lyrics and it was engouraging |
| 23:38:52 | gradha | I'm in spain |
| 23:39:16 | gradha | we speak mexican here, mexicans speak in spanish instead (or so the saying goes in the USA) |
| 23:39:16 | filwit | yeah, i don't really mind the downer music |
| 23:39:30 | filwit | but just like anything, too much is a bad thing |
| 23:39:45 | filwit | lol wut? |
| 23:39:49 | filwit | you speak mexican? |
| 23:39:59 | filwit | what does that mean? (joke?) |
| 23:40:24 | filwit | you mean cause 'Mexicans' speak 'Spanish'? |
| 23:40:43 | gradha | well, if you are from spain and go to the USA, nobody says you speak spanish |
| 23:40:54 | gradha | they say mexican people speak spanish, you speak... weird |
| 23:40:59 | filwit | yes, i met a spanish exchange student awhile ago |
| 23:41:11 | gradha | so the conclusion is spanish people must be speaking mexican |
| 23:41:16 | filwit | and he liked to listen to Shakira (which was on the radio a lot at the time) |
| 23:41:24 | filwit | and try and understand what she was saying |
| 23:41:35 | filwit | also, i get the joke :) |
| 23:41:38 | gradha | lol, nobody understands that squirrel |
| 23:41:41 | filwit | i've just never heard it before |
| 23:42:42 | filwit | yeah Shekira is like Justin Beihber to me... i just don't care either way |
| 23:43:04 | filwit | i never really got all the JB hate thing, cause i don't really listen to the radio maybe |
| 23:43:17 | filwit | i just never really cared either way |
| 23:43:20 | gradha | here the joke seems to be that people will understand her lyrics whenever wikileaks releases them, maybe because of poor diction (actually haven't heard hear) |
| 23:43:33 | Araq | comparing Shakira to JB is blasphemy |
| 23:43:33 | filwit | lol |
| 23:43:45 | filwit | uh oh |
| 23:43:46 | gradha | yeah, shakira is hotter |
| 23:44:02 | filwit | ^ good point |
| 23:44:58 | Araq | filwit: it's fine, I don't care about her music either ;-)9 |
| 23:46:48 | filwit | don't germans use grammar like this: "the man walks to the store and talks to the cashier, quickly, softly" |
| 23:46:49 | filwit | ? |
| 23:47:08 | filwit | instead of "the man quickly walks to the store and softly talks to the cashier" |
| 23:47:09 | gradha | also "what are you wearing tonight?" ?? |
| 23:47:14 | filwit | LOL |
| 23:48:11 | filwit | and by "germans use" i mean "in German (language)" |
| 23:48:22 | Araq | dunno |
| 23:48:31 | Araq | it's hard to tell right now |
| 23:48:33 | filwit | what do you mean you don't know |
| 23:48:34 | filwit | lol |
| 23:48:40 | filwit | are you high? |
| 23:48:56 | Araq | I'd have to translate word by word and see if it works that way in german |
| 23:49:22 | filwit | isn't German your first language? |
| 23:49:30 | Araq | it is, but I'm debugging things |
| 23:49:36 | filwit | okay, i see |
| 23:50:12 | gradha | filwit: fwiw you can use both constructions in spanish |
| 23:50:23 | filwit | you can sorta in english |
| 23:50:31 | Araq | "der mann schnell läuft ..." nope |
| 23:50:36 | Araq | doesn't work that way |
| 23:50:36 | filwit | you can say "the man walks to the store, quickly" |
| 23:50:46 | filwit | but you can't chain both adjectives to the end |
| 23:51:13 | NimBot | nimrod-code/Aporia c3a0344 Dominik Picheta [+0 ±1 -0]: Small todo changes. |
| 23:51:19 | filwit | lauft means "quickly"? |
| 23:51:31 | Araq | no it means "walks" |
| 23:51:46 | filwit | schnell means quickly? |
| 23:51:52 | Araq | yes |
| 23:51:53 | filwit | and that's proper? |
| 23:52:05 | Araq | der Mann läuft schnell ... # proper |
| 23:52:27 | filwit | and the second part? |
| 23:52:32 | Araq | but german is very flexible when it comes to word order |
| 23:52:48 | Araq | "Schnell läuft der Mann" # also possible, albeit uncommon |
| 23:53:06 | filwit | well that's also valid in english |
| 23:53:11 | filwit | "quickly the man walks" |
| 23:53:31 | filwit | but i meant the chaining of two things: "the man walks, and talks to the clerk" |
| 23:53:37 | Araq | "quickly walks the man"? :P |
| 23:53:50 | filwit | but then, in German (so i hear), you can add both adjective to the end and it's valid |
| 23:54:04 | filwit | oh no, you're right |
| 23:54:08 | filwit | that's not valid in english |
| 23:54:28 | filwit | actually... i've heard people say things like that before and get away with it |
| 23:54:37 | filwit | aka: Yoda |
| 23:54:43 | filwit | :P |
| 23:54:52 | Araq | english speaking people often complain the verb comes so late in german sentences |
| 23:55:05 | Araq | but then that's not quite true |
| 23:55:15 | Araq | often it moves to the front ;-) |
| 23:55:37 | Araq | and much more often it's split up |
| 23:55:43 | Araq | into 2 parts |
| 23:56:09 | gradha | hrm... given filwit gaming background I expect him to understand pretty well the pdf Araq posted earlier, it's all about how encapsulation fucks up cache hits and game developers resort to taking obejcts apart for performance |
| 23:56:31 | gradha | it's just like denormalization of tables in SQL for performance |
| 23:56:42 | filwit | gradha: encapsulation is still used a ton in Game Engines |
| 23:56:50 | filwit | i also didn't download that PDF |
| 23:57:00 | Araq | you should read it |
| 23:57:08 | filwit | i doubt it will be convincing |
| 23:57:18 | Araq | but it is |
| 23:57:20 | gradha | I don't need that pdf, I can tell you I've seen it with my own eyes |
| 23:57:24 | filwit | besides, the point gradha is making is an error |
| 23:57:35 | gradha | when I worked with console guys we had this array/linked list of objects |
| 23:57:46 | gradha | and you had a logic loop going through all of them checking stuff |
| 23:57:50 | gradha | it was really slow |
| 23:58:09 | gradha | so we "cached" the checks into an array, which fit into the cache of the console, and voila, much faster |
| 23:58:18 | filwit | the situation is literally the same, weather OOP is in the picture or not |
| 23:58:24 | gradha | but that leaves part of your object in a separate array for performance |
| 23:58:52 | filwit | game objects are much different |
| 23:59:11 | filwit | you don't think of a "Character" as a full game object usually |
| 23:59:22 | filwit | you think of the "Mesh" as a game object component |
| 23:59:34 | filwit | but that has nothing to do with functions being tied to what objects |
| 23:59:40 | gradha | can't tell you really what game objects are, during a year we redesigned the hierarchy three times IIRC |
| 23:59:46 | filwit | even in Nimrod, the situation would be tackled the same way |