| 00:02:06 | boydgreenfield | Can anyone point me to an example using the || operator? (and relevant necessary compile flags/options) |
| 00:02:16 | boydgreenfield | Documentation on it is a bit sparse |
| 00:03:45 | fowl | boydgreenfield, ive never seen it used but if you find/write one please add it to the docs |
| 00:05:23 | EXetoC | Demos_: yes, because opengl errors don't only cover programming mistakes. see enableAutoGlErrorCheck(yes: bool). it can be disabled at compile-time by defining NoAutoGlErrorCheck |
| 00:06:49 | flaviu1 | Any thoughts on prototype-based ASTs? Purely prototypical would be inefficient, and non-immutable prototypes would be weird, but it would allow for fairly concise code. |
| 00:06:53 | Demos_ | OK great, they DO const in perf, and I used glDebugMessageCallbackARB (the wrapper needs updateing to gl 4.4 btw, which includes a core glDebugMessageCallback) and I check that way |
| 00:06:59 | EXetoC | this is documented, but it ends up right next to about 5000 symbols. I need to fix that |
| 00:07:38 | Demos_ | wait where are those symbols coming from? |
| 00:07:47 | EXetoC | opengl |
| 00:08:21 | fowl | flaviu1, ast has to have structure to have any meaning |
| 00:08:57 | boydgreenfield | fowl: Was trying to get this example to work (https://github.com/logicchains/Levgen-Parallel-Benchmarks/blob/master/PN.nim) (http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/) but can only seem to get it running on one thread. |
| 00:10:02 | EXetoC | I could disable those when generating the documentation, or I could mention them in a doc comment for the module, but I don't know if I can link to them |
| 00:10:11 | boydgreenfield | fowl: What’s the current best practice / pattern re: parallelization? |
| 00:10:41 | fowl | boydgreenfield, i dunno :/ i dont think about parallelization much |
| 00:11:02 | boydgreenfield | fowl: Fair enough. If anybody else has an example, pls let me know! (And thx!) |
| 00:13:47 | EXetoC | Demos_: there's TGLDebugProc and then 3 others |
| 00:13:56 | flaviu1 | fowl: There would be structure, things essential to each node would be concrete, and each concrete node would be a non-strict superset of it's prototype |
| 00:14:27 | Demos_ | EXetoC: yeah I am using that, but the functions related to it are NOT core in the version of the gl that the wrapper supports |
| 00:16:20 | EXetoC | Demos_: glDebugMessageCallback isn't? |
| 00:16:26 | EXetoC | I targeted opengl 4.4 |
| 00:17:33 | Demos_ | oh. look at that |
| 00:17:34 | Demos_ | :D |
| 00:18:31 | Demos_ | does anyone ever actually use GL remotely? |
| 00:20:43 | * | Kazimuth quit (Ping timeout: 240 seconds) |
| 00:22:10 | boydgreenfield | Separate but related question – so I have gotten it to work w/ -fopenmp, but the —passC:-fopenmp option only seems to pass the flag to the `gcc -c` calls and not the final `gcc -o` call. Does anyone know how to pass a variable to this? Currently the compilation fails with the following message, but works file if done manually w/ the -fopenmp flag too: gcc -o /vagrant/pn /vagrant/nimcache/stdlib_unsigned.o |
| 00:22:11 | boydgreenfield | /vagrant/nimcache/stdlib_posix.o /vagrant/nimcache/stdlib_times.o /vagrant/nimcache/stdlib_parseutils.o /vagrant/nimcache/stdlib_strutils.o /vagrant/nimcache/stdlib_os.o /vagrant/nimcache/stdlib_system.o /vagrant/nimcache/bfield_pn.o -ldl -pthread |
| 00:22:38 | fowl | boydgreenfield, you likely want -passl |
| 00:23:04 | fowl | boydgreenfield, that passes to the linker, also you can do it the module with {.passl: ...} |
| 00:23:06 | boydgreenfield | fowl: That does indeed work. |
| 00:23:15 | boydgreenfield | fowl: Thx. |
| 00:23:44 | * | Kazimuth joined #nimrod |
| 00:34:42 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 00:38:42 | * | q66 quit (Quit: Leaving) |
| 00:52:12 | * | hoverbear joined #nimrod |
| 00:56:24 | * | boydgreenfield joined #nimrod |
| 01:00:25 | fowl | type TDict[K,V] = openarray[tuple[key: K, val: V]] |
| 01:00:40 | fowl | causes cgen error :( |
| 01:04:14 | Demos_ | hm so I have a situation where I want something like a dirty flag, but I was thinking that it may be better to just have a counter I increment every time I modify the thing, that way I need not deal with reseting the flag, and I can have multiple place where I watch to see if the thing is dirty, is there a reason why people use dirty flags instead? |
| 01:04:51 | * | hoverbear quit () |
| 01:09:13 | * | hoverbear joined #nimrod |
| 01:09:15 | * | hoverbear quit (Max SendQ exceeded) |
| 01:09:53 | * | hoverbear joined #nimrod |
| 01:19:16 | * | hoverbear quit () |
| 01:24:27 | * | hoverbear joined #nimrod |
| 01:33:40 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 01:35:23 | * | Kazimuth quit (Remote host closed the connection) |
| 01:45:46 | * | askatasuna quit (Quit: WeeChat 0.4.3) |
| 01:54:35 | flaviu1 | How do I check pointer equality? Apparently 'expression has no address' for `addr(a.str)` |
| 01:59:03 | * | xenagi joined #nimrod |
| 02:00:22 | * | hoverbear quit () |
| 02:01:11 | EXetoC | flaviu1: is 'a' a var? and you might want str[0].addr if it's a nimrod string |
| 02:01:30 | fowl | flaviu1, i just tried == for pointer and ptr T |
| 02:02:00 | fowl | for ptr T you can write one that does a[] == b[] to invoke nimrods == for object types |
| 02:03:26 | flaviu1 | My bad, I thought that strings were something like `ptr char` |
| 02:12:44 | EXetoC | there are 2 preceding fields I think |
| 02:14:03 | fowl | flaviu1, string explicit and implicit converts to cstring |
| 02:14:11 | fowl | somestring.cstring |
| 02:18:34 | flaviu1 | All these primitive data types are too complicated for me :/. All I want is a pointer to a length of memory, I guess I'll just do that directly. |
| 02:26:27 | fowl | i dont understand |
| 02:27:17 | fowl | EXetoC, i see what the problem is, its the proc fields in struct mrb_state getting declared as types |
| 02:51:09 | * | gsingh93_ joined #nimrod |
| 02:53:29 | * | hoverbear joined #nimrod |
| 03:02:56 | flaviu1 | I have no idea why openarray == openarray doesn't work, but its time for bed |
| 03:03:42 | * | flaviu1 quit (Quit: Leaving.) |
| 03:05:09 | * | hoverbear quit () |
| 03:11:22 | * | hoverbear joined #nimrod |
| 03:33:34 | * | hoverbear quit () |
| 03:34:12 | * | boydgreenfield joined #nimrod |
| 03:47:43 | * | hoverbear joined #nimrod |
| 03:50:22 | * | boboman13 joined #nimrod |
| 03:50:43 | boboman13 | hi guys |
| 03:50:52 | boboman13 | has there been any previous talk of redesigning the documentation? |
| 03:57:04 | Demos_ | yes, and some work has been done |
| 03:57:26 | Demos_ | not sure when it will be deployed, I think filwit is doing it |
| 03:57:48 | * | xenagi quit (Quit: Leaving) |
| 04:27:45 | boboman13 | okay, so nobody is looking for a new person to redesign it? |
| 04:55:18 | * | havenwood joined #nimrod |
| 04:59:22 | * | gsingh93_ quit (Quit: Connection closed for inactivity) |
| 05:02:03 | * | isenmann joined #nimrod |
| 05:04:16 | * | Varriount|Mobile joined #nimrod |
| 05:08:20 | * | Demos_ quit (Ping timeout: 255 seconds) |
| 05:16:19 | * | Varriount|Mobile quit (Ping timeout: 252 seconds) |
| 05:37:30 | * | xtagon quit (Quit: Leaving) |
| 05:38:30 | * | boboman13 quit (Quit: Page closed) |
| 06:03:44 | * | DAddYE joined #nimrod |
| 06:06:11 | * | hoverbear quit () |
| 06:23:20 | * | chh quit (Quit: Leaving) |
| 07:01:39 | * | DAddYE quit (Remote host closed the connection) |
| 07:02:06 | * | DAddYE joined #nimrod |
| 07:06:32 | * | DAddYE quit (Ping timeout: 258 seconds) |
| 07:06:42 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 07:09:37 | * | skroll quit (Ping timeout: 252 seconds) |
| 07:15:13 | * | skroll joined #nimrod |
| 07:39:30 | * | skroll quit (Ping timeout: 258 seconds) |
| 07:46:19 | * | skroll joined #nimrod |
| 08:21:55 | * | BitPuffi1 quit (Ping timeout: 265 seconds) |
| 08:54:35 | * | io2 joined #nimrod |
| 08:56:04 | * | john3213 joined #nimrod |
| 09:01:07 | * | john3213 left #nimrod (#nimrod) |
| 09:10:30 | * | Mat3 joined #nimrod |
| 09:10:40 | Mat3 | Good Day |
| 09:21:25 | Araq | hi Mat3 |
| 09:24:37 | * | BitPuffi1 joined #nimrod |
| 09:25:11 | * | BitPuffi1 is now known as BitPuffin |
| 09:26:29 | * | lyro joined #nimrod |
| 09:36:32 | Mat3 | hi Araq |
| 09:57:30 | fowl | is there a str[0..-1] that doesnt allow negative slices |
| 09:58:17 | * | lyro quit (Ping timeout: 252 seconds) |
| 09:59:34 | Araq | fowl: substr doesn't iirc |
| 10:00:31 | fowl | o cool |
| 10:00:50 | fowl | ty |
| 10:18:25 | * | Varriount|Mobile joined #nimrod |
| 10:18:39 | Varriount|Mobile | Meep |
| 10:25:37 | Mat3 | hello Varriount |
| 10:26:44 | Varriount|Mobile | Hello Mat3, anything interesting going on? |
| 10:34:27 | Mat3 | not much, machine code programming at moment |
| 10:37:29 | * | lyro joined #nimrod |
| 10:50:44 | Varriount | dom96: Please, please optimize/fix the substring find procedure when you have the chance. We have yet another post on the forum complaining about its performance. |
| 10:54:46 | Araq | lol |
| 10:54:58 | Araq | yeah we might want to fix that |
| 10:55:48 | Varriount | Or wait, was it the find procedure, or the split procedure? |
| 11:04:41 | Mat3 | I bet the find procedure |
| 11:11:37 | Varriount | http://forum.nimrod-lang.org/t/447/1#2411 |
| 11:15:45 | Varriount | The irritating thing is that the poster didn't give any of the other implementations, nor a sample log file, that would allow us to test and optimize |
| 11:23:58 | Mat3 | as the poster had written, his example program was compiled with '-d:release' flag and invoke 'strutils.find' |
| 11:26:18 | Mat3 | because I see no compared timings to justify his conclusion, it can result from a workload artefact |
| 11:27:27 | Mat3 | ... or something other which does not relate to the algorithm |
| 11:33:57 | Araq | I think it's simply the lines iterator which doesn't use decent buffering in master |
| 11:34:04 | Araq | but should in devel |
| 11:34:29 | Araq | find itself is not quick due to the used algorithm too |
| 11:34:50 | Araq | a decent implementation should use SSE, I guess |
| 11:36:54 | Mat3 | hmm, questionable because SSE flag handling is rudimentary at best which complicate comparisons |
| 11:39:25 | Araq | Mat3: ok, lets just say "compare 4/8/16 characters at once" :-) |
| 11:40:32 | Mat3 | *g* |
| 11:43:20 | * | kunev joined #nimrod |
| 12:11:40 | * | untitaker quit (Ping timeout: 258 seconds) |
| 12:18:00 | * | untitaker joined #nimrod |
| 12:29:27 | * | mal`` quit (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 12:33:44 | * | mal`` joined #nimrod |
| 13:11:14 | * | Mat3 quit (Quit: Verlassend) |
| 13:25:50 | * | havenwood left #nimrod (#nimrod) |
| 13:26:12 | EXetoC | fowl: what are you up to? did you want any more help with that wrapper? |
| 13:41:40 | * | darkf quit (Quit: Leaving) |
| 14:09:27 | * | lyro quit (Ping timeout: 252 seconds) |
| 14:16:58 | * | kunev quit (Remote host closed the connection) |
| 14:17:14 | * | kunev joined #nimrod |
| 14:34:19 | * | Hat_and_Cloak joined #nimrod |
| 14:52:52 | * | Hat_and_Cloak left #nimrod ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is") |
| 15:01:58 | * | nande_ joined #nimrod |
| 15:10:20 | * | bjz_ quit (Ping timeout: 265 seconds) |
| 15:12:40 | * | lyro joined #nimrod |
| 15:14:56 | * | kunev quit (Quit: leaving) |
| 15:28:01 | * | njoejoe joined #nimrod |
| 15:50:38 | * | lyro quit (Ping timeout: 240 seconds) |
| 16:06:15 | * | Varriount-Mobile joined #nimrod |
| 16:09:43 | * | Varriount|Mobile quit (Ping timeout: 252 seconds) |
| 16:21:19 | * | q66 joined #nimrod |
| 16:21:19 | * | q66 quit (Changing host) |
| 16:21:19 | * | q66 joined #nimrod |
| 16:22:14 | * | hoverbear joined #nimrod |
| 16:31:11 | * | BitPuffin quit (Ping timeout: 258 seconds) |
| 16:53:52 | * | Varriount-Mobile quit (Ping timeout: 240 seconds) |
| 16:58:32 | * | bjz joined #nimrod |
| 17:03:26 | * | bjz quit (Ping timeout: 265 seconds) |
| 17:10:00 | * | Amrykid quit (Changing host) |
| 17:10:00 | * | Amrykid joined #nimrod |
| 17:10:05 | * | BitPuffin joined #nimrod |
| 17:28:46 | * | nande_ quit (Read error: Connection reset by peer) |
| 17:34:29 | * | Demos_ joined #nimrod |
| 17:37:06 | * | Varriount-Mobile joined #nimrod |
| 17:41:28 | * | Varriount-Mobile quit (Ping timeout: 240 seconds) |
| 17:42:00 | * | Matthias247 joined #nimrod |
| 17:47:41 | * | wan joined #nimrod |
| 17:56:28 | * | zezba9000 joined #nimrod |
| 18:00:12 | * | Varriount-Mobile joined #nimrod |
| 18:06:02 | zezba9000 | Does nimrod require SH version 4.0 or higher to build? |
| 18:06:46 | zezba9000 | I was doing an experiment yesterday on my G5, but it only has SH 3.1.x and would not build because of what looked like an sh error |
| 18:08:42 | * | brson joined #nimrod |
| 18:12:03 | Demos_ | are you talking about sh as in the shell> |
| 18:14:00 | Demos_ | is it bad that I am thinking of using the C preprocessor on a nimrod file... |
| 18:15:40 | EXetoC | templates? |
| 18:15:50 | fowl | EXetoC, well now that you mention it |
| 18:16:57 | Demos_ | EXetoC: I dont think I can, I want to end up with source files that are all expanded, and I do not /really/ want to rely on C's memory layout and generic types |
| 18:16:57 | fowl | EXetoC, i am having trouble cramming everything in one module, theres a lot of interdependence and ifdef nesting >:/ |
| 18:17:49 | Demos_ | if class B is a child of A than B's vtbl contains A's vtbl except that the "This" pointers are of type ptr B, not ptr A |
| 18:18:32 | * | Varriount-Mobile quit (Ping timeout: 255 seconds) |
| 18:18:44 | Demos_ | now I could just stick A's vtbl as the first member of B's vtbl and have the vtbls be generic on the type of This, but then you call a method of a base type you would be like C->vtbl->base_vtbl->base_vtbl->method |
| 18:26:13 | EXetoC | fowl: you can't just include all the headers? |
| 18:27:25 | zezba9000 | Demos_: Yes i'm talking about shell on OSX 10.5 |
| 18:27:53 | zezba9000 | Which only comes with version 3.1... not sure if I can upgrate to 4+ |
| 18:29:02 | zezba9000 | I'm testing out nimrods portability as it builds to C... and I would like to benchmark it on G5 processors. |
| 18:29:28 | * | brson quit (Quit: leaving) |
| 18:29:32 | zezba9000 | does nimrod use C11 btw? |
| 18:29:35 | * | brson joined #nimrod |
| 18:30:05 | zezba9000 | or can it build with older compilers? Like gcc 4.0 |
| 18:43:06 | zezba9000 | sry gcc question is supid as thats listed on github |
| 18:43:54 | zezba9000 | but it would be nice to support older versions of shell |
| 18:46:12 | * | Johz joined #nimrod |
| 18:46:23 | zezba9000 | I might look into it... but dam that shell script is big. |
| 18:46:48 | * | Jehan_ joined #nimrod |
| 18:47:02 | Demos_ | we support old compilers |
| 18:47:07 | Demos_ | like down to gcc 4.4 I think |
| 18:47:14 | EXetoC | big indeed. holy moly |
| 18:47:27 | zezba9000 | Demos_: The site says gcc 3.x |
| 18:47:33 | zezba9000 | err github does |
| 18:47:36 | Demos_ | we also support MSVC and I can confirm that it works on MSVC 18 |
| 18:47:39 | Demos_ | oh |
| 18:47:43 | Demos_ | well than maybe that |
| 18:47:44 | EXetoC | but lots of repetition |
| 18:47:50 | Demos_ | afaik we generate more or less C89 |
| 18:48:35 | zezba9000 | Demos_: I may ask you how to compile it with MSVC later as I wanted to see what it might take to make it run on WinRT/Metro |
| 18:49:02 | Demos_ | I am working on getting microsoft libraries wrapped up |
| 18:49:12 | Araq | we generate C89 + various GCC and VCC extensions |
| 18:49:15 | zezba9000 | Demos_: Win32 or WinRT? |
| 18:49:27 | Demos_ | thinking I will try and coax the MIDL compiler into emitting mroe or less standard C and then try and get c2nim to work on it |
| 18:49:35 | Demos_ | I think both |
| 18:49:38 | Demos_ | not sure though |
| 18:50:01 | zezba9000 | Demos_: Well the file API in WinRT is totally different |
| 18:50:10 | Demos_ | winRT is sometimes the new libs for win8 and sometimes c++ + those libs + /CX |
| 18:50:26 | Araq | zezba9000: tell your brother to join us, please |
| 18:50:30 | zezba9000 | Any file synchronous API in Nimrod with not work on WinRT. |
| 18:50:31 | Demos_ | I dont think it is though, I thought it was only different if you use /CX and you could access it like regular COM |
| 18:50:50 | zezba9000 | Araq: He is sick, but I will pass on the message |
| 18:51:02 | Demos_ | anyway I g2g for a bit |
| 18:51:11 | Araq | oh, tell him to get well soon then please |
| 18:51:17 | zezba9000 | Demos_: No you can't |
| 18:51:21 | zezba9000 | That will not work on ARM |
| 18:51:40 | zezba9000 | It might on x86 but it will never pass WACK when trying to put something on the store |
| 18:52:19 | EXetoC | Araq: what do these extensions do? various low-level stuff I suppose |
| 18:52:23 | zezba9000 | Metro apps can access Win32 APIs but can never be distributed... so its pointless. |
| 18:53:38 | BitPuffin | Araq: what do you think about ada 2012 |
| 18:53:50 | Araq | EXetoC: ranges for 'switch', computed goto, __assume(false) |
| 18:54:42 | Araq | BitPuffin: looks nice, but doesn't deal with Ada's real problems |
| 18:55:00 | BitPuffin | Araq: which is? |
| 18:55:41 | Araq | which is that it really is not well suited for anything that is not critical and doesn't require strict memory bounds |
| 18:56:07 | Araq | in other words strings still suck and the lack of GC sucks |
| 18:57:24 | BitPuffin | I wonder how they deal with memory safety without having a GC |
| 18:57:39 | BitPuffin | maybe they take a similar approach to what rust does |
| 18:58:19 | Araq | no not at all |
| 18:58:38 | Araq | they deal with it by declaring "dealloc" unsafe ... ;-) |
| 18:58:47 | BitPuffin | rust or ada? |
| 18:59:11 | Araq | ada. also the spec is agnostic to GC which is nice but since no real implemenation provides a GC |
| 18:59:20 | Araq | rather pointless |
| 18:59:23 | BitPuffin | hmm |
| 18:59:39 | BitPuffin | so you can't dealloc? xD |
| 18:59:50 | Araq | oh you can, but it's unsafe |
| 18:59:54 | BitPuffin | ah |
| 18:59:56 | BitPuffin | lol |
| 19:00:13 | Araq | well |
| 19:00:31 | Araq | if you care about provably *bounded* memory usage |
| 19:00:39 | Araq | you don't use the heap anyway |
| 19:00:54 | BitPuffin | true |
| 19:01:04 | Araq | globally allocated fixed size arrays ftw |
| 19:01:31 | Araq | so here you go. that's how it is memory safe |
| 19:01:47 | BitPuffin | kinda funky |
| 19:02:01 | Araq | you allocate everything statically |
| 19:02:08 | BitPuffin | well |
| 19:02:13 | BitPuffin | static allocation is good to prefer |
| 19:03:10 | BitPuffin | I remember reading about a story where a programmer just started working for a game company and was surprised that when he tried to use the heap the program wouldn't compile |
| 19:03:18 | BitPuffin | they had simply disallowed using it lol |
| 19:03:53 | Araq | also the syntax is brutal. They confused verbosity with readability, it's even worse than Pascal |
| 19:04:35 | BitPuffin | the naming conventions make it quite a bit worse though |
| 19:05:03 | Araq | The_Uppercase_With_Underscores style is also a pita, yeah |
| 19:05:24 | BitPuffin | yeah and it looks like poop |
| 19:05:29 | EXetoC | it's also a bitch to type |
| 19:06:30 | zezba9000 | Araq: How do you manage your build server? Like do you own all the computers it builds with at home via this: http://build.nimrod-lang.org/ |
| 19:06:36 | zezba9000 | Or are you cross compiling? |
| 19:06:42 | zezba9000 | with a single computer? |
| 19:06:52 | Araq | we "own" all the computers |
| 19:07:18 | zezba9000 | For ARMv6 what do you build it with? The Pi? |
| 19:07:43 | zezba9000 | or do you cross compile for ARM, just wondering |
| 19:08:00 | BitPuffin | well it does run the tests as well doesn't it? |
| 19:08:07 | BitPuffin | so cross compiling isn't sufficient if that's the case |
| 19:08:39 | Araq | BitPuffin: yeah it also runs all the tests |
| 19:08:59 | Araq | zezba9000: perhaps, I don't know, you have to ask dom96 |
| 19:10:39 | fowl | EXetoC, meh, trying to fix things that c2nim missed |
| 19:10:48 | Matthias247 | BitPuffin: you could still use qemu for that |
| 19:12:00 | BitPuffin | Matthias247: sure |
| 19:12:12 | BitPuffin | did I say anything to indicate something else? |
| 19:12:47 | zezba9000 | Araq: k, the reason I was asking was because I would be happy to set up my RaspberryPi as a real-world test build device. As well as the G5 if I can get it to build on there as I would find nimrod useful on those CPUs and OSX versions. Does Dom handle all things related to the build server devices it gets pushed to? |
| 19:14:02 | zezba9000 | dom96: Hey dom wondering how you handle the build server for ARM? Do you cross compile or build on a ARM device? |
| 19:14:27 | Araq | oh we don't cross compile |
| 19:14:42 | Araq | it builds on the device |
| 19:14:43 | zezba9000 | What device do you compile with then? |
| 19:15:06 | Araq | well dom96 owns a RaspberryPI |
| 19:15:20 | Araq | but I am not sure that's what's listed on nimbuild |
| 19:15:47 | Araq | so yes, it builds on a RaspberryPI |
| 19:16:53 | zezba9000 | Well I would be happy to set up some of my computers as test devices if you want. I'm all about portability so would be happy to help there if I can. |
| 19:18:02 | dom96 | Yeah, the ARM builds were done on my RPI. |
| 19:18:07 | zezba9000 | It would be cool to be able to set up the build server to test on Android/iOS/BB10/ect devices... not sure the best way about doing that though |
| 19:18:18 | dom96 | It's insanely slow though and I don't run the builder there anymore. |
| 19:18:59 | zezba9000 | dom96: If I can get nimrod to build on my G4 & G5 would you like to add those to the build server tests? |
| 19:19:20 | dom96 | zezba9000: What we currently need is a Mac machine, so if you have that it would be great if you let us use it. |
| 19:19:36 | zezba9000 | I have G4 G5 & Intel |
| 19:20:32 | dom96 | zezba9000: Which version of Mac OS is your G5 running? |
| 19:20:43 | zezba9000 | OSX 10.5.8 |
| 19:21:02 | zezba9000 | I run the newest OS on everything |
| 19:21:13 | zezba9000 | G4 is 10.4.11 |
| 19:21:21 | zezba9000 | Intel is 10.9.2 |
| 19:22:09 | dom96 | I think the newest one would be best. |
| 19:22:31 | dom96 | If you have a machine with 10.9.2 then it would be best. |
| 19:23:07 | zezba9000 | Well just build nimrod on 10.9 yesterday.. that works fine... and would be happy to have it do builds |
| 19:23:15 | BitPuffin | if only we knew someone who had a macbook with 10.9.3 |
| 19:23:43 | * | filwit joined #nimrod |
| 19:23:49 | dom96 | BitPuffin: oh yeah, you have a mac book don't you? :P |
| 19:24:01 | BitPuffin | just so happens to be that I do |
| 19:24:18 | filwit | hey Araq, andrew said you wanted to talk to me? |
| 19:24:33 | BitPuffin | who is Andrew |
| 19:24:34 | dom96 | BitPuffin: And do you want to run a builder? |
| 19:24:42 | filwit | andrew == zezba |
| 19:24:47 | BitPuffin | dom96: well it's not always on so it's probably not the best idea |
| 19:24:54 | BitPuffin | for example, when I travel to/from work |
| 19:25:00 | zezba9000 | dom96: But its those special cases I would find interesting to get working as well, like the G4/G5 |
| 19:25:03 | dom96 | BitPuffin: Yeah... |
| 19:26:23 | dom96 | zezba9000: Sure. That would be awesome. But can you wait a couple of weeks, I'm in the middle of exams so I don't really have much time to help with the set up. |
| 19:26:25 | Araq | hi filwit wb |
| 19:26:42 | BitPuffin | dom96: other than that it is usually always on |
| 19:26:44 | dom96 | Also I would like to fix some things in nimbuild before introducing any new builders. |
| 19:26:49 | filwit | hi Araq |
| 19:26:51 | BitPuffin | as I use it for alarm clock and so on |
| 19:26:58 | zezba9000 | dom96: Ya I have work to do too, so I can wait |
| 19:27:05 | dom96 | zezba9000: great |
| 19:27:15 | dom96 | BitPuffin: Macbook as an alarm clock? lol |
| 19:27:30 | dom96 | I would even feel weird using my iPad mini as an alarm clock |
| 19:27:37 | BitPuffin | dom96: yeah well I just open a website etc |
| 19:27:43 | BitPuffin | and put the speakers way up |
| 19:27:51 | BitPuffin | and turn off all the brightness etc |
| 19:27:53 | BitPuffin | it works |
| 19:28:04 | dom96 | BitPuffin: why not just use your phone? |
| 19:28:10 | zezba9000 | I use the Metro app on Win8.1 as an alarm clock |
| 19:28:14 | BitPuffin | because to turn it off I have to fn+f2 and stuff |
| 19:28:20 | BitPuffin | dom96: I do but it's not loud enough |
| 19:28:35 | dom96 | BitPuffin: Connect some speakers to it :P |
| 19:28:58 | BitPuffin | lol |
| 19:29:01 | BitPuffin | :P |
| 19:29:50 | * | brson quit (Ping timeout: 255 seconds) |
| 19:30:00 | zezba9000 | dom96: Also I know Araq told me this before, but nimrod doesn't work on NaCl right now because of some API that doesn't exist. I would like to get it working on there as well. |
| 19:30:46 | zezba9000 | If its just a missing API or method, i'm sure re-implementing it for NaCl should be easy (I hope) |
| 19:31:08 | dom96 | Sure go ahead. |
| 19:31:13 | * | dom96 should get back to studying |
| 19:31:19 | dom96 | bye |
| 19:31:47 | zezba9000 | Also if I ever can get my hands on a "gcw zero" could test with MIPS cpus. |
| 19:31:55 | zezba9000 | bye |
| 19:35:46 | * | Mat3 joined #nimrod |
| 19:35:48 | Mat3 | hello |
| 19:36:28 | Araq | zezba9000: indeed it is rather easy to provide mmap via malloc for NaCl |
| 19:37:41 | BitPuffin | Araq: apparently normal objects are deallocated when they exit scope |
| 19:37:46 | BitPuffin | so that's something at least lol |
| 19:38:43 | * | dymk quit (Ping timeout: 240 seconds) |
| 19:39:32 | zezba9000 | Araq: Are you sure its "mmap" thats missing? |
| 19:39:46 | zezba9000 | Looks like people are talking about how they use it in Nacl |
| 19:40:24 | zezba9000 | https://code.google.com/p/nativeclient/issues/detail?id=1848 |
| 19:42:32 | Mat3 | that link makes me angry |
| 19:43:44 | Mat3 | "If a thread is writing to an address that is remapped, there is a small window during which the address is unwritable" |
| 19:45:55 | Araq | zezba9000: no, I'm not. at one point in time it was missing, I'm pretty sure |
| 19:46:37 | zezba9000 | Araq: Before 2011 i'm guessing? |
| 19:46:53 | zezba9000 | Well if I have time maybe I can try |
| 19:47:17 | Araq | please try it and ask for help when you get stuck |
| 19:47:31 | Araq | it surprises me many people don't do that |
| 19:48:02 | Araq | it still much faster than waiting for me do it ... |
| 19:52:33 | zezba9000 | Araq: Well if I do get some of these builds working I will be documenting it and making sure it can be reproduced with an updated build script or something... so the build server can use it |
| 19:53:22 | * | flaviu1 joined #nimrod |
| 19:53:57 | * | jez0990 quit (Quit: No Ping reply in 180 seconds.) |
| 19:54:05 | * | jez0990 joined #nimrod |
| 19:54:30 | * | snearch joined #nimrod |
| 19:55:50 | * | snearch quit (Max SendQ exceeded) |
| 19:56:04 | zezba9000 | I think it makes sense to have the build server build with lots of different GCC versions, as the more devices you test with the more bugs you find and the more portable a code base becomes... this is very true with GLSL shader code :) |
| 19:56:15 | filwit | Araq: btw, you said you weren't sure the 'using' statement was going to stay or not.. it currently has bugs with my macros, but I like the general idea of it. Is there something specific where it causes problems (just interested) |
| 19:56:49 | * | brihat joined #nimrod |
| 19:57:36 | Araq | zezba9000: that is true but also not really relevant when you still have way too few manpower |
| 19:57:54 | Araq | "oh look it crashes with GCC 3.3 on CentOS" |
| 19:58:15 | Araq | "now who cares enough to spend his afternoons on that?" |
| 19:58:36 | Mat3 | in this context: Testing for clang, icc and tcc would alos help in my opinion |
| 19:59:20 | zezba9000 | Araq: Well i'm not going that far... more like G5 CPUS which are used on Nintendo Wii, NaCl which is used today... I don't think any platform is still using GCC 3 |
| 20:00:00 | zezba9000 | And if I can get help compiling for those platforms, I will be happy to run tests on them. |
| 20:00:00 | * | Mat3 thinks Haiku is still using gcc 2 |
| 20:00:06 | BitPuffin | Mat3: no |
| 20:00:08 | BitPuffin | it uses both |
| 20:00:10 | BitPuffin | :P |
| 20:00:16 | BitPuffin | you can switch between gcc version |
| 20:00:26 | BitPuffin | gcc 2 is for backwards compatability with beos 5 |
| 20:00:33 | Mat3 | that make programming live easier |
| 20:00:55 | Mat3 | ^life |
| 20:01:04 | filwit | is Haiku actually used for anything? |
| 20:01:29 | Mat3 | I do not think so |
| 20:05:06 | Demos_ | well I preprocessed dxgi.h, but I have a feeling c2nim will reject the 300,000 line output |
| 20:06:07 | Araq | filwit: I have no concrete examples what 'using' breaks |
| 20:07:03 | filwit | Araq: okay, just wondering if there was a known flaw with symbol resolution using it |
| 20:09:22 | Araq | well we know it's buggy |
| 20:09:35 | Araq | I only skimmed the implemenation tbh |
| 20:10:16 | filwit | yeah np, i'll fixed it eventually |
| 20:10:28 | filwit | just wondering why you said that before is all |
| 20:20:27 | * | Jehan_ quit (Read error: Connection timed out) |
| 20:25:01 | * | krusipo quit (Ping timeout: 276 seconds) |
| 20:26:21 | * | krusipo joined #nimrod |
| 20:30:31 | * | Jehan_ joined #nimrod |
| 20:35:28 | * | krusipo quit (Ping timeout: 240 seconds) |
| 20:38:05 | Araq | elif (let size = computeSize(argType); size < 0 or size > 16): |
| 20:38:22 | Araq | I love 'let' inside an expression |
| 20:38:48 | Araq | whoever came up with it is a genius |
| 20:38:58 | Araq | oh wait ... it was me :P |
| 20:40:05 | flaviu1 | Araq: couldn't you do Java's try with resources with that? |
| 20:40:44 | flaviu1 | modified somewhat |
| 20:40:50 | Araq | not sure what you mean but 'try' can also be used as an expression: f(try: parseInt("abc") except: 0) |
| 20:41:46 | flaviu1 | Araq: try(let file = file("./a", fRead)):gfjhasgkj finally: close file |
| 20:43:03 | * | krusipo joined #nimrod |
| 20:43:35 | Araq | flaviu1: you can do that with a template |
| 20:46:47 | * | brson joined #nimrod |
| 20:54:57 | * | jbe joined #nimrod |
| 20:56:23 | jbe | hello fellow nimheads |
| 20:56:33 | Araq | hi |
| 20:57:00 | Demos_ | how does one deal with extern variables in nimrod? |
| 20:57:38 | Araq | var foo {.importc, header: "arg.h".}: T |
| 20:58:13 | Demos_ | I can omit importc if I want right? |
| 20:58:19 | Demos_ | or rather omit header |
| 20:58:32 | Araq | I dunno |
| 20:59:00 | Araq | header should imply importc |
| 20:59:18 | jbe | is there something in stdlib that will tell me how much heap i've allocated/deallocated using alloc or allocShared etc? |
| 20:59:55 | Araq | jbe: getOccupiedMem et al |
| 21:00:12 | Araq | only exist for the thread local heaps though |
| 21:01:08 | jbe | Araq: so i would basically have to implement something of my own if i want to track shared memory use? |
| 21:01:48 | Araq | jbe: you only have to expose what's already there |
| 21:01:54 | Araq | and make a PR |
| 21:02:08 | flaviu1 | Araq: Since you know the most about the compiler, are there any challenges in parsing concurrently? |
| 21:02:32 | Araq | flaviu1: it's pretty much impossible |
| 21:03:18 | Araq | the actual parsing is really too cheap to bother and semantic checking is full of dependencies |
| 21:04:47 | Araq | code generation ... might work in parallel some day |
| 21:05:35 | flaviu1 | What about generating AST stubs (just method headers and such) for each module? That would allow mostly anything to run in paralell |
| 21:05:50 | Araq | better make the incremental parsing mode we got stable instead |
| 21:06:11 | Araq | (--symbolFiles:on) |
| 21:07:06 | fowl | EXetoC, https://github.com/fowlmouth/mruby.nim |
| 21:09:21 | * | brson quit (Quit: Lost terminal) |
| 21:09:33 | * | brson joined #nimrod |
| 21:10:37 | * | brson quit (Client Quit) |
| 21:10:56 | Araq | flaviu1: that only works when the whole compiler has been written with this particular way of parallel parsing in mind |
| 21:11:15 | * | brson joined #nimrod |
| 21:11:53 | Araq | I'm not aware of any compiler that does that except perhaps Roslyn |
| 21:13:57 | * | vendethiel quit (Read error: Connection reset by peer) |
| 21:14:29 | jbe | Araq: do you prefer getTotalShared or getTotalSharedMem? |
| 21:14:38 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 21:15:31 | flaviu1 | When I do type |
| 21:15:48 | flaviu1 | foo = object; a: ref openarray[char] |
| 21:15:49 | Araq | jbe: getTotalSharedMem |
| 21:16:09 | flaviu1 | , it looks like the parser just gives up |
| 21:17:34 | flaviu1 | It says that the following procs are 'invalid types'. It looks like a bug, or am I misunderstanding the syntax? |
| 21:17:50 | Araq | ref openarray[char] is not a valid type |
| 21:19:46 | flaviu1 | oh, they can only be used as parameters. But it looks like an unchecked array is what I'm looking for |
| 21:20:15 | Araq | yeah |
| 21:21:53 | * | BitPuffin quit (Quit: WeeChat 0.4.3) |
| 21:22:22 | * | BitPuffin joined #nimrod |
| 21:22:42 | * | askatasuna joined #nimrod |
| 21:23:49 | * | brson quit (Quit: Lost terminal) |
| 21:24:39 | * | vendethiel joined #nimrod |
| 21:31:25 | flaviu1 | It says that the GC can't collect unchecked arrays, but doesn't malloc include a header with the size of the allocation? |
| 21:32:41 | jbe | Araq: should getFreeSharedMem etc still be be available, but return 0 when not hasThreadSupport? |
| 21:34:15 | * | brson joined #nimrod |
| 21:39:27 | * | Mat3 quit (Quit: Verlassend) |
| 21:42:16 | jbe | zero sounds like a better inconsistency than returning the size of the thread local heap to me - so that shared + local give a sane total when added up |
| 21:42:25 | jbe | never mind |
| 21:50:07 | BitPuffin | wow modula 3's syntax is very similar to nimrod |
| 21:50:11 | BitPuffin | except with a lot more caps |
| 21:55:50 | * | OrionPK quit (Remote host closed the connection) |
| 22:00:58 | * | BitPuffi1 joined #nimrod |
| 22:01:29 | * | askatasuna quit (Quit: WeeChat 0.4.3) |
| 22:02:19 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 22:05:00 | * | BitPuffi1 quit (Client Quit) |
| 22:05:18 | * | BitPuffin joined #nimrod |
| 22:06:44 | Araq | flaviu1: well the manual says support for unchecked arrays can be improved |
| 22:07:39 | Araq | jbe: these should not be available when threads are turned off |
| 22:07:46 | Araq | imo |
| 22:17:26 | Demos_ | how can I forward declare types? |
| 22:18:40 | * | filwit quit (Ping timeout: 240 seconds) |
| 22:20:54 | Araq | you don't |
| 22:21:08 | Araq | you put them all in the same type section and hope for the best |
| 22:21:27 | Demos_ | ugh, I need to move around this whole damn file then |
| 22:28:46 | * | xenagi joined #nimrod |
| 22:29:10 | * | Jehan_ quit (Ping timeout: 276 seconds) |
| 22:29:42 | * | Jehan_ joined #nimrod |
| 22:30:02 | Demos_ | w00t my dxgi wrapper compiles |
| 22:30:07 | Jehan_ | You can also abuse generics to some extent. |
| 22:30:27 | Demos_ | I am just abusing vim and regex |
| 22:30:37 | Jehan_ | For forward type declarations, I mean. :) |
| 22:31:21 | Demos_ | right, I would like to keep things as close to the MS headers as I can |
| 22:33:20 | * | flaviu1 quit (Remote host closed the connection) |
| 22:34:29 | * | Johz quit (Ping timeout: 264 seconds) |
| 22:42:44 | * | jbe quit (Quit: Leaving) |
| 22:56:32 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:00:08 | * | brson quit (Ping timeout: 265 seconds) |
| 23:06:13 | * | OrionPK joined #nimrod |
| 23:09:24 | * | brihat left #nimrod (#nimrod) |
| 23:13:00 | * | xenagi|2 joined #nimrod |
| 23:15:44 | * | xenagi quit (Ping timeout: 255 seconds) |
| 23:16:36 | * | flaviu1 joined #nimrod |
| 23:41:11 | Demos_ | awww c2nim can not do Anonymous Unions |
| 23:48:38 | fowl | nope:< |
| 23:52:37 | * | Jehan_ quit (Quit: Leaving) |
| 23:54:01 | * | filwit joined #nimrod |
| 23:56:43 | Demos_ | this is going way better than I thought it would |
| 23:57:16 | filwit | taking a look at Dash https://github.com/Circular-Studios/Dash |
| 23:57:34 | filwit | i've forgotten how ugly C-ish code looks :~ |
| 23:58:14 | * | xenagi joined #nimrod |
| 23:58:32 | filwit | at least used the way they're doing it.. but i remember doing the same things in D with all those `mixin( property!("foo", int) )` stuff |
| 23:58:45 | * | brson joined #nimrod |
| 23:58:56 | * | brson quit (Client Quit) |
| 23:59:04 | * | brson joined #nimrod |