| 00:00:17 | boydgreenfield | Jehan_: Does indeed. Quite a bit removed from my area of expertise unfortunately. Odd that the behavior changed so suddenly. I’ll do a bit more Docker + DNS + git googling... |
| 00:15:58 | BitPuffin | Jehan_: oh it doesn't say anything? |
| 00:15:59 | BitPuffin | but I mean |
| 00:16:12 | BitPuffin | short, int and long are keywords in C89 |
| 00:16:26 | Jehan_ | Yes? |
| 00:16:26 | BitPuffin | but I guess they don't necessarily mean anything in terms of bit count |
| 00:16:39 | Jehan_ | Exactly. |
| 00:16:44 | BitPuffin | hrm |
| 00:16:58 | BitPuffin | but you can't use stdint.h in C89 and expect full portability right |
| 00:17:10 | BitPuffin | and I don't think long long is allowed |
| 00:17:21 | Jehan_ | No, long long isn't in C89. |
| 00:17:51 | BitPuffin | so how would you get a 64 bit number :P |
| 00:18:09 | Jehan_ | The reality is that most compilers either support C99 or a sufficiently powerful subset. |
| 00:18:36 | Jehan_ | The latter being Microsoft's compiler, more or less. |
| 00:18:46 | BitPuffin | hm |
| 00:18:46 | BitPuffin | yeah |
| 00:18:48 | BitPuffin | CL sucks :P |
| 00:19:24 | Jehan_ | So, you make an #ifdef _WIN32 or something like that, hardcode int sizes for that, and use stdint.h for other platforms. |
| 00:19:38 | BitPuffin | oh windows doesn't have stdint.h? |
| 00:20:33 | Jehan_ | Not last time I checked. |
| 00:20:44 | Jehan_ | Well, Microsoft C doesn't have it. |
| 00:20:56 | BitPuffin | yeah it's in the C++ thingy |
| 00:21:00 | BitPuffin | but that's not C |
| 00:21:01 | BitPuffin | :P |
| 00:21:23 | Jehan_ | But other compilers have to stick to the same ABI, so you can just handle all Windows compilers as one single case here. |
| 00:21:39 | BitPuffin | the annoying thing is that gcc does not whine about using stdint.h even when you have -std=c89 and all the pedantic stuff |
| 00:22:33 | BitPuffin | at least not with mingw |
| 00:22:35 | Jehan_ | Because the standard doesn't say say anything about being limited to only a certain set of include files. |
| 00:22:52 | Jehan_ | Any platform can provide whatever other include files they want. |
| 00:23:06 | Jehan_ | As long as they provide the minimum listed in the standard. |
| 00:23:30 | BitPuffin | yeah I know |
| 00:23:43 | BitPuffin | but doesn't the header files usually have an ifdef hell of version stuff? |
| 00:23:54 | Jehan_ | Yes. |
| 00:24:23 | BitPuffin | so I guess it's mingw's fault for not having it in this particular header |
| 00:25:32 | Jehan_ | Hmm? |
| 00:25:43 | Jehan_ | There's nothing wrong with having stdint.h in c89. |
| 00:25:57 | Jehan_ | No reason they have to disallow it. |
| 00:27:10 | BitPuffin | well I mean |
| 00:27:19 | BitPuffin | then you could also use say threads.h |
| 00:27:30 | BitPuffin | so what's the point of doing -std=c89 then :P |
| 00:28:12 | BitPuffin | well |
| 00:28:17 | BitPuffin | actually doing all of this |
| 00:28:20 | BitPuffin | -Werror -Wall -Wextra -std=c89 -pedantic-errors -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition |
| 00:29:22 | * | brson quit (Quit: leaving) |
| 00:29:39 | BitPuffin | maybe I also need -Wpedantic |
| 00:30:27 | Jehan_ | It means that everything in the standard is there, at a minimum. |
| 00:30:37 | * | superfunc_ joined #nimrod |
| 00:30:46 | Jehan_ | Anyhow, good night. :) |
| 00:30:48 | * | Jehan_ quit (Quit: Leaving) |
| 00:38:26 | * | superfunc_ quit (Quit: Page closed) |
| 00:43:12 | * | BitPuffin quit (Remote host closed the connection) |
| 00:44:26 | * | BitPuffin joined #nimrod |
| 01:10:06 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 01:21:23 | * | mko quit (Quit: Bye.) |
| 01:27:15 | * | will quit (Read error: Connection reset by peer) |
| 01:36:34 | * | darkf joined #nimrod |
| 01:47:07 | * | dom96_ joined #nimrod |
| 01:57:24 | * | Fran__ joined #nimrod |
| 01:57:24 | * | Fran__ is now known as Fr4n |
| 02:00:26 | * | Francisco quit (Ping timeout: 258 seconds) |
| 02:18:37 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 02:20:11 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 02:28:19 | * | dapz joined #nimrod |
| 02:33:26 | * | dapz quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:52:59 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 02:53:17 | * | johnsoft joined #nimrod |
| 03:00:18 | * | xenagi quit (Quit: Leaving) |
| 03:12:43 | * | flaviu quit (Ping timeout: 255 seconds) |
| 03:19:18 | * | kemet joined #nimrod |
| 03:40:22 | * | ditzex is now known as comex |
| 04:02:34 | * | superfunc joined #nimrod |
| 04:07:56 | Varriount | Araq, dom96: Regarding --parallelBuild and mixed up output, has any thought been put into gathering the called processes output into individual buffers, and reading out the buffers, in order, when the processes have completed? |
| 04:30:16 | * | boydgreenfield joined #nimrod |
| 04:50:57 | * | ARCADIVS joined #nimrod |
| 05:13:46 | * | superfunc quit (Ping timeout: 246 seconds) |
| 05:20:05 | * | kshlm joined #nimrod |
| 05:20:55 | * | kshlm left #nimrod (#nimrod) |
| 05:27:01 | * | nande quit (Remote host closed the connection) |
| 05:40:28 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 05:48:33 | * | boydgreenfield joined #nimrod |
| 05:55:59 | * | khmm joined #nimrod |
| 05:56:32 | * | khmm_ joined #nimrod |
| 05:57:00 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 06:30:40 | * | gokr joined #nimrod |
| 06:32:57 | * | kemet quit (Ping timeout: 260 seconds) |
| 06:46:23 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 06:53:45 | * | superfunc joined #nimrod |
| 06:55:05 | superfunc | does anyone have experience getting pandoc to highlight nim properly? |
| 07:54:57 | * | superfunc quit (Quit: Page closed) |
| 08:03:40 | gokr1 | Morning! |
| 09:19:37 | * | Matthias247 joined #nimrod |
| 09:33:04 | * | khmm__ joined #nimrod |
| 09:38:51 | * | kuzy000 joined #nimrod |
| 09:40:41 | * | kuzy000 quit (Remote host closed the connection) |
| 09:47:35 | * | khmm__ quit (Remote host closed the connection) |
| 09:47:36 | * | khmm_ quit (Read error: Connection reset by peer) |
| 09:48:23 | * | kemet joined #nimrod |
| 10:02:03 | * | kemet quit (Remote host closed the connection) |
| 11:21:16 | * | johnsoft joined #nimrod |
| 11:22:35 | * | Matthias247 quit (Quit: Matthias247) |
| 11:27:39 | * | Matthias247 joined #nimrod |
| 11:32:27 | * | Trustable joined #nimrod |
| 11:37:05 | * | tdc joined #nimrod |
| 11:39:40 | * | johnsoft quit (Read error: Connection reset by peer) |
| 11:40:24 | * | johnsoft joined #nimrod |
| 11:42:10 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 11:56:40 | * | kemet joined #nimrod |
| 12:02:02 | * | untitaker quit (Ping timeout: 265 seconds) |
| 12:06:49 | * | untitaker joined #nimrod |
| 12:34:40 | * | kemet quit (Ping timeout: 272 seconds) |
| 12:55:01 | * | darkf quit (Quit: Leaving) |
| 12:59:49 | * | Trustable quit (Quit: Leaving) |
| 13:04:01 | * | bjz joined #nimrod |
| 13:12:42 | * | BitPuffin joined #nimrod |
| 13:19:52 | * | kemet joined #nimrod |
| 13:25:14 | * | superfunc joined #nimrod |
| 13:26:00 | * | BitPuffin quit (Remote host closed the connection) |
| 13:37:03 | * | BitPuffin joined #nimrod |
| 14:06:15 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 14:09:11 | * | Trustable joined #nimrod |
| 14:10:16 | * | BitPuffin quit (Remote host closed the connection) |
| 14:10:45 | * | BitPuffin joined #nimrod |
| 14:19:52 | * | irrequietus joined #nimrod |
| 14:28:54 | gokr1 | Posted a long article on Nim and OO: http://goran.krampe.se/category/nim/ |
| 14:46:09 | gokr1 | Its not one of my more structured articles - but perhaps its interesting. |
| 14:46:41 | * | BlaXpirit joined #nimrod |
| 15:14:06 | Trustable | gokr1: thanks for you article! :) |
| 15:15:44 | gokr1 | What did you think of it? |
| 15:15:54 | gokr1 | It turned very long - and probably quite confusing |
| 15:18:43 | Trustable | gork1: You write "Procs bind statically and calling a super proc is easy using type conversion." |
| 15:19:14 | Trustable | That's true, but normally you use methods, and for methods calling "super" is not possible. |
| 15:20:52 | Trustable | We really need this feature in my opinion. |
| 15:30:07 | * | nullmove joined #nimrod |
| 15:30:10 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 15:39:22 | * | untitaker quit (Quit: ZNC - http://znc.in) |
| 15:44:53 | * | untitaker joined #nimrod |
| 15:53:44 | * | johnsoft quit (Ping timeout: 255 seconds) |
| 15:54:20 | * | johnsoft joined #nimrod |
| 15:57:10 | * | brson joined #nimrod |
| 15:57:11 | gokr1 | Trustable: Read it all :) |
| 15:58:41 | gokr1 | Its "easy" calling super - but its also dangerous. Because if the base "proc" calls "self procs" then... it will fail. Since it now has lost type info. |
| 15:59:36 | gokr1 | But I agree - we need the super call. As Jehan said, in Dylan and CLOS etc they have some kind of "call-the-next" method. Not sure if there is a smoother solution. |
| 16:04:40 | * | superfunc joined #nimrod |
| 16:11:36 | * | kemet quit (Ping timeout: 264 seconds) |
| 16:14:32 | superfunc | Araq, dom96_ : just wanted to say how much I enjoy the (T -> T) syntax for procs, really has cleaned some things up for me |
| 16:35:35 | gokr | hmmm, the lambda syntax? |
| 16:36:35 | * | AMorpork is now known as AFKMorpork |
| 16:36:45 | * | nande joined #nimrod |
| 16:38:05 | * | CARAM_ quit (Ping timeout: 265 seconds) |
| 16:38:28 | superfunc | I can write proc map[T,V](s: SomeFunctor[T], f: (T -> V)) : SomeFunctor[V] |
| 16:38:41 | superfunc | where f is a function going from type T to V |
| 16:38:59 | * | endou_____ quit (Ping timeout: 265 seconds) |
| 16:39:44 | superfunc | just a little easier then writing f: proc(x: T) : V, for me |
| 16:40:52 | gokr | oh, didnt know that syntax |
| 16:41:37 | superfunc | its from the future module |
| 16:41:46 | * | irrequietus quit () |
| 16:50:53 | * | MyMind quit (Ping timeout: 255 seconds) |
| 16:54:33 | * | mko joined #nimrod |
| 16:55:00 | * | irrequietus joined #nimrod |
| 17:01:14 | * | MyMind joined #nimrod |
| 17:02:20 | * | mko quit (Ping timeout: 256 seconds) |
| 17:07:47 | * | MyMind quit (Ping timeout: 258 seconds) |
| 17:11:11 | * | MyMind joined #nimrod |
| 17:12:20 | superfunc | gokr: What did you use for syntax highlighting in your blog? |
| 17:12:57 | * | kemet joined #nimrod |
| 17:16:23 | * | Jesin quit (Quit: Leaving) |
| 17:18:15 | * | Jesin joined #nimrod |
| 17:18:41 | gokr | its pygments i think |
| 17:18:49 | gokr | octopress |
| 17:19:17 | gokr | it supports nimrod |
| 17:32:21 | * | mko joined #nimrod |
| 17:36:50 | superfunc | gokr: thanks |
| 17:37:02 | superfunc | I'm gonna try to hack some support together for pandoc tonight |
| 17:38:16 | * | endou_____ joined #nimrod |
| 17:43:00 | * | BitPuffin quit (Remote host closed the connection) |
| 17:47:43 | * | BitPuffin joined #nimrod |
| 17:50:55 | * | CARAM_ joined #nimrod |
| 17:52:53 | Varriount | Meep |
| 17:54:21 | * | kemet quit (Ping timeout: 244 seconds) |
| 17:55:19 | Varriount | Araq: How does Mixed mode work? |
| 17:58:12 | * | irrequietus quit () |
| 17:59:35 | * | bjz quit (Read error: Connection reset by peer) |
| 17:59:56 | * | bjz joined #nimrod |
| 18:04:51 | * | Demos joined #nimrod |
| 18:08:14 | Varriount | Demos: Ping |
| 18:08:20 | * | Matthias247 joined #nimrod |
| 18:10:17 | * | khmm quit (Ping timeout: 245 seconds) |
| 18:10:39 | * | superfunc quit (Quit: Page closed) |
| 18:10:45 | Demos | Varriount, pong |
| 18:11:19 | Varriount | Demos: Are there any special flags the Nim compiler needs to use to compile C++ on VCC? |
| 18:11:45 | Demos | well look in extccomp.nim for the ones we currently use |
| 18:12:01 | Demos | I think we change the stack size and maybe turn off SEH or something |
| 18:13:38 | Demos | we also pass /arch:sse2 which prompts some output on newer compilers but it is required as older compilers do not do that by default |
| 18:14:31 | Varriount | Hm. |
| 18:15:38 | Demos | you having some kind of problem? |
| 18:15:56 | Varriount | I'm adjusting configuration reading for when the compiler is in C++ mode. |
| 18:16:08 | * | nande quit (Remote host closed the connection) |
| 18:16:11 | Varriount | I'm just undecided if the way I'm doing it is correct. |
| 18:17:07 | Varriount | The current way I have it done is that, when the compiler is in C++ mode, it reads options loaded from the config file using a 'cpp' prefix. |
| 18:17:53 | Varriount | Eg, 'gcc.options.linker' is used in C mode, and 'gcc.cpp.options.linker' in C++ mode. |
| 18:18:56 | Demos | that sounds OK, as long as you are comfortable duplicating options... |
| 18:19:18 | Varriount | Well, what alternative is there? |
| 18:20:05 | Demos | having the c++ ones be based on the C ones, I dont really like that idea though, sounds complicated |
| 18:30:12 | * | vsajip joined #nimrod |
| 18:30:25 | * | mko quit (Quit: Bye.) |
| 18:37:51 | vsajip | Just installed Nimrod 0.9.6 on Windows 7 64-bit, hit a couple of problems. I selected the mingw option during installation, but when I tried compiling a "Hello, world!" program, I got "Error: unhandled exception: The system cannot find the file specified." Not too helpful, but I assumed this might be referring to gcc. The installer adds c:\Nimrod\dist\mingw to the PATH, but the compiler is... |
| 18:37:52 | vsajip | ...in c:\Nimrod\dist\mingw\bin. I updated the path, and now I get a different slew of errors, starting with: |
| 18:37:54 | vsajip | In file included from c:\users\vinay\projects\scratch\nimcache\hello.c:8:0: |
| 18:37:55 | vsajip | c:\Nimrod\lib/nimbase.h:383:13: error: size of array 'assert_numbits' is negative |
| 18:37:57 | vsajip | typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof(NI)*8 ? 1 : -1]; |
| 18:37:59 | vsajip | Anything obvious I'm doing wrong? hello.nim is just echo("Hello, world!") - I assume this could be to do with include files, but I'm not sure where to look. |
| 18:39:52 | * | mko joined #nimrod |
| 18:40:12 | Demos | that error says that your compiler and nim disagree on the size of a pointer |
| 18:40:15 | * | noam joined #nimrod |
| 18:40:38 | Demos | as far as I know mingw is a 32-bit compiler, so try running nimrod with --cpu:i386 |
| 18:41:07 | Demos | this should indeed be the default but we moved to a new installation scheme with this release so things are a little rough around the edges |
| 18:41:15 | Araq | vsajip: you're too late. both issues have already been fixed in the latest installer. please re-download. |
| 18:42:19 | Araq | sorry for the inconvenience, but hey, we migrated from Inno Setup to NSIS |
| 18:44:28 | Araq | Varriount: mixed mode detects "importcpp" and sets some module-wide flag that then checked for in the codegen |
| 18:44:39 | vsajip | No worries, retrying ... |
| 18:44:54 | * | noam quit (Ping timeout: 256 seconds) |
| 18:50:33 | vsajip | Araq: Latest installer does fix the problem, thanks. |
| 18:51:25 | Araq | please note that our mingw is incredibly small in comparison to the official mingw release |
| 18:54:11 | Varriount | :D |
| 18:54:39 | Varriount | vsajip: It takes about 2 hours to programmatically trim down a mingw installation. |
| 18:56:46 | vsajip | Varriount: Oof! What's left out? On Windows, is mingw preferred over the Microsoft compilers? |
| 18:57:19 | Demos | I dont think anything is preferred, but the MS compilers are harder to install than the included mingw |
| 18:58:10 | Demos | if you want to use stuff like gtk+ you probably want to use mingw, whereas if you want to use something like Direct3D you should probably stick to the microsoft compiler |
| 18:58:40 | Demos | although mingw may be able to compile code using d3d, I don't really know |
| 18:59:09 | vsajip | Demos: Makes sense, thanks. Even the Visual C/C++ Express installers don't get the installation right (64-bit and cross-compiler environment vars aren't properly set). |
| 18:59:55 | Varriount | vsajip: GDB, Ada, Python & Perl, among other things |
| 19:00:37 | Varriount | Araq: Does mixed mode cause the CPP compiler to be called? |
| 19:02:10 | Varriount | vsajip: Oh, and a number of binutils are left out as well. |
| 19:02:49 | vsajip | Varriount: Good to know, thanks. |
| 19:02:54 | Varriount | Essentially, anything that, if deleted, doesn't alter/prevent koch and the Nimrod compiler from compiling. |
| 19:03:39 | Varriount | vsajip: If you need to switch to a full mingw installation, you can write over the bundled one - just make sure it's the same bitness |
| 19:04:15 | Demos | vsajip, hm, they should be. You need to use the bash script in like Common7/Tools/Shortcuts or something to get the x64 compiler or the cross compilers |
| 19:04:29 | Varriount | As to why we use mingw over vcc, vcc is now bundled with visual studio (no seperate download), which is a 3GB release. |
| 19:04:30 | Demos | I don't use the express versions so I may be wrong |
| 19:04:36 | vsajip | Varriount: Noted. |
| 19:04:46 | Demos | Varriount, it is in the WDK as well I think |
| 19:04:49 | Demos | not 100% sure though |
| 19:05:31 | Varriount | Demos: http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx |
| 19:05:49 | Varriount | "The Windows SDK no longer ships with a complete command-line build environment. You must install a compiler and build environment separately." |
| 19:07:18 | vsajip | Demos: The vcvarsall.bat files aren't properly setup in some Visual C Express versions. For example, on 2008, vcvarsall.bat looks for amd64\vcvarsamd64.bat, but there's no such file, it's in vcvars64.bat which is moreover not in the amd64 directory. Fun and games :-) |
| 19:07:34 | Varriount | Which is quite a daft move - I don't need to download Visual Studio on, say, a remote builder. |
| 19:08:18 | Demos | ugh... what a pain |
| 19:08:39 | Varriount | T_T |
| 19:08:43 | Araq | Varriount: the c++ compiler is called for these modules that need it |
| 19:09:03 | Varriount | Araq: Hm.. I wonder how that will work with my configuration changes... |
| 19:09:13 | Araq | Varriount: it might in fact work |
| 19:09:34 | Araq | will review your patch later, I'm busy |
| 19:09:35 | * | irrequietus joined #nimrod |
| 19:12:04 | Varriount | Hello irrequietus |
| 19:12:42 | irrequietus | 'lo |
| 19:25:08 | wan | Is there a way to do a static error? I'd like compilation to fail with a nice error when neither -d:postgres nor -d:redis is passed to the compiler for a program that has to make use of either one or the other... |
| 19:26:00 | wan | Something like when not defined(...) and not defined(...): staticError("please pass either -d:postgres or -d:redis") |
| 19:29:58 | wan | Alright, found it. Static statement/expression on the tutorial page. |
| 19:30:36 | * | superfunc joined #nimrod |
| 19:33:47 | Demos | wan, also the {.fatal.} pragma |
| 19:33:54 | Demos | or the {.error.} pragma |
| 19:35:35 | wan | Oh, much better than static:, thanks! |
| 19:35:40 | Demos | fatal will crash the rpel as well as stop a compile, error does not stop the rpel, you probably want error |
| 19:39:06 | * | nullmove quit (Quit: Leaving) |
| 19:40:04 | Demos | In case anyone cares useFFI is broken on bigbreak, I still like it but I understand that is it not supported |
| 19:40:16 | * | Demos quit (Read error: Connection reset by peer) |
| 19:40:38 | Araq | well yes. it's not supported anymore. |
| 19:40:47 | Araq | but thanks, will update koch.nim |
| 19:40:49 | wan | I've noticed that the export statement behaves differently also |
| 19:40:58 | Araq | yeah, will fix it |
| 19:41:08 | Araq | it's actually a bugfix |
| 19:41:09 | wan | I had to do 'export bla.stuff, bla.stuff2' instead of 'export bla' |
| 19:41:22 | * | Jehan_ joined #nimrod |
| 19:41:32 | Araq | well, I don't think 'export bla' was documented? |
| 19:41:41 | Araq | where 'bla' is a complete module |
| 19:41:52 | * | edayo joined #nimrod |
| 19:41:58 | Araq | hi edayo welcome |
| 19:42:18 | wan | Probably not documented. I just tried it at some point :) |
| 19:42:34 | Araq | other people even use it instead of the export marker |
| 19:42:38 | Araq | aka * |
| 19:42:51 | Araq | which never was documented either |
| 19:43:15 | Araq | but I don't mind supporting it officially, many dislike the * export marker |
| 19:44:57 | * | Demos joined #nimrod |
| 19:46:12 | wan | I quite like * as an export marker, but 'export mymodule' has its uses. Like for example forwarding exports so that the user of a lib only has to import one file |
| 19:46:45 | wan | but the lib would be separated in several files |
| 19:47:35 | wan | achievable by 'export mylibfile1.stuff, mylibfile2.stuff2', but cleaner with 'export mylibfile, mylibfile2' |
| 19:50:38 | Jehan_ | The only problem with export instead of '*' is that export can't come before the declaration of the symbol. So you have to look at the end to see what's visible. |
| 19:50:50 | * | Hakaslak joined #nimrod |
| 19:53:40 | * | superfunc quit (Ping timeout: 246 seconds) |
| 19:54:57 | wan | I find * more usable for everyday exports because it's right next to the definition of the proc. It's not in a special place somewhere in the file, or in a .h file |
| 20:01:11 | Araq | well yes, 'export' was designed for forwarding |
| 20:01:28 | Araq | * is more convenient to use and read |
| 20:01:44 | Araq | thinking about it |
| 20:01:53 | Araq | export instead of * likely breaks the docgen |
| 20:01:59 | Araq | hi Hakaslak welcome |
| 20:03:45 | Hakaslak | oh hi Araq |
| 20:03:48 | Hakaslak | someone said hi to me! |
| 20:04:00 | Araq | I'm not "someone" :P |
| 20:04:05 | Hakaslak | I have no idea what Nimrod is, I just read about you guys on HN |
| 20:04:30 | * | MightyJoe quit (Ping timeout: 258 seconds) |
| 20:04:35 | Hakaslak | Per brihat 270 days ago... "Nimrod's gang (including Araq) are very friendly and welcoming." Source: https://news.ycombinator.com/item?id=7161236 |
| 20:04:36 | * | cyraxjoe joined #nimrod |
| 20:04:52 | Araq | hi cyraxjoe welcome |
| 20:05:09 | Araq | what's up tonight? are we on reddit or something? |
| 20:05:26 | Hakaslak | are you having an influx of new people? |
| 20:05:36 | Araq | kind of, yeah |
| 20:05:52 | cyraxjoe | Araq: hi! |
| 20:05:56 | Hakaslak | I got here by Googling for "best javascript irc channels" and clicking the first link, and adding all the channels people said were good. |
| 20:06:20 | Araq | er ... ok? well we have a JS backend |
| 20:07:09 | wan | What google finds links to an HN "Best IRC channels?" page, no mention of js on that |
| 20:10:57 | * | Hakaslak quit (Quit: TODO: Generate 'Part & Quit Message') |
| 20:11:41 | * | Hakaslak joined #nimrod |
| 20:12:46 | * | Hakaslak quit (Max SendQ exceeded) |
| 20:12:49 | * | vsajip left #nimrod (#nimrod) |
| 20:13:25 | * | Hakaslak joined #nimrod |
| 20:16:29 | Araq | flaviu? can I summon you this way? |
| 20:19:50 | Jehan_ | Nah, /cast[summon](flaviu) would be the correct syntax. :) |
| 20:20:17 | Jehan_ | He's not on the channel at the moment, though. |
| 20:20:52 | * | nande joined #nimrod |
| 20:22:17 | Araq | yeah but he has the habit of showing up when appropriate |
| 20:23:41 | * | Hakaslak quit (Quit: TODO: Generate 'Part & Quit Message') |
| 20:24:16 | * | Hakaslak joined #nimrod |
| 20:25:21 | * | Hakaslak quit (Max SendQ exceeded) |
| 20:25:57 | * | Hakaslak joined #nimrod |
| 20:33:18 | * | flaviu joined #nimrod |
| 20:35:57 | flaviu | Hey Araq |
| 20:36:11 | flaviu | sorry, I was 10 minutes late :P |
| 20:37:12 | * | superfunc joined #nimrod |
| 20:41:06 | * | tillzy joined #nimrod |
| 20:41:49 | tillzy | :D |
| 20:42:17 | superfunc | hi tillzy |
| 20:42:27 | tillzy | Hi! |
| 20:42:56 | superfunc | welcome to nim-irc |
| 20:43:17 | tillzy | thanks! i think there is something wrong with my irc client tho :S |
| 20:43:42 | superfunc | why? |
| 20:45:10 | tillzy | not sure, the latest i can see from this chat is and the other i am in is "oh dear tillzy" and "yep, something wrong with tillzy" :p |
| 20:45:34 | tillzy | channel* |
| 20:46:44 | flaviu | tillzy: Have you tried turning it off and on again? ;) |
| 20:47:11 | tillzy | lol, i just turned it on right now, the logs are form october 18th, not sure what happened back then |
| 20:47:24 | tillzy | maby my kid got hold of the computer |
| 20:51:47 | tillzy | Onionhammer: do you by anny chanse remember what happened? you wrote "dear lordy lord tillzy" =/ |
| 20:52:33 | tillzy | looks like i been banned from that other channel, must have been quite bad |
| 20:54:13 | * | tillzy quit (Quit: tillzy) |
| 20:54:35 | flaviu | tillzy: http://build.nimrod-lang.org/irclogs/17-10-2014.html |
| 20:55:44 | flaviu | ahaha araq discovered the arch installer :D |
| 21:06:20 | * | nande quit (Ping timeout: 250 seconds) |
| 21:09:24 | Varriount | flaviu: >:D |
| 21:10:13 | Varriount | flaviu: Araq, dom96, and I have decided to replace nimbuild with buildbot for the time being. |
| 21:10:32 | flaviu | ok, sounds good |
| 21:13:14 | Araq | flaviu: your PR cannot be applied |
| 21:13:21 | Araq | and I'm not sure it's against bigbreak |
| 21:13:46 | flaviu | ok. I'll see if I can sort it out |
| 21:14:28 | * | Trustable1 joined #nimrod |
| 21:14:28 | * | Trustable1 quit (Client Quit) |
| 21:16:50 | * | dom96_ quit (Ping timeout: 255 seconds) |
| 21:17:23 | * | superfunc quit (Quit: Page closed) |
| 21:23:21 | * | edayo quit (Ping timeout: 260 seconds) |
| 21:23:48 | fowl | arch is nice |
| 21:24:13 | fowl | customized a livecd to include beta nvidia drivers, it was super easy |
| 21:24:15 | * | dom96_ joined #nimrod |
| 21:55:28 | Varriount | Araq: Regarding the recent PR, it messes up a test case, or it requires a test case? |
| 21:56:04 | flaviu | Araq: Ok, I think it'll work now |
| 21:59:40 | * | irrequietus quit () |
| 22:00:23 | Araq | Varriount: it requires a test case |
| 22:00:43 | flaviu | Araq: I've opened another PR https://github.com/Araq/Nimrod/pull/1605 |
| 22:00:48 | flaviu | this should be much easier now |
| 22:01:40 | Araq | fowl: does that mean opencl works for you out of the box? |
| 22:04:31 | * | Mat3 joined #nimrod |
| 22:04:34 | Mat3 | hello |
| 22:07:34 | Trustable | I want to try out bigbreak and get this error: lib/system.nim(2388, 67) Error: invalid pragma: locks: 0 |
| 22:08:21 | Varriount | Araq: What folder would this test go under? lookups? |
| 22:08:35 | Araq | modules |
| 22:08:41 | Varriount | Trustable: What OS, and did you boot from csources? |
| 22:09:18 | Trustable | Linux Mint, yes, boot from csources |
| 22:09:29 | Trustable | both branch bigbreak |
| 22:09:39 | gokr1 | Hey guys |
| 22:09:50 | Trustable | Hi gokr1 |
| 22:10:38 | gokr1 | Trustable: IIRC that issue is because the Nim compiler now uses a new "locks" pragma, so ... you need newer csources. Just cloned or? |
| 22:11:04 | Trustable | yes, cloned and checkout bigbreak |
| 22:11:54 | gokr1 | Btw, wrote an extremely detailed article on the bootstrap process just like a week ago: http://goran.krampe.se/2014/10/15/bootstrapping-nim/ |
| 22:12:11 | gokr1 | I can try again on my box. |
| 22:12:20 | NimBot | nimrod-code/nimforum new_async 4de7e58 Dominik Picheta [+14 ±4 -1]: First steps towards new forum design. |
| 22:14:18 | gokr1 | Trustable: Was the error when you did... the last step? koch boot? |
| 22:14:49 | flaviu | Varriount: I have a shitty ARM box you can use for the builder if you'd like. Of course, 64MB/s ram isn't too exciting :P |
| 22:14:49 | Trustable | The error occurs, when I try to compile a Hello World |
| 22:14:50 | * | tdc_ joined #nimrod |
| 22:15:46 | gokr1 | oh, and you use "nim"? |
| 22:15:54 | gokr1 | Not "nimrod"? |
| 22:16:09 | gokr1 | In bin you will have both an older "nimrod" (from csources) and the new "nim". |
| 22:16:18 | Varriount | gokr: Yes, because the name change is instituted after 1.0 |
| 22:16:20 | gokr1 | The real bigbreak compiler is "nim" |
| 22:16:27 | gokr1 | Varriount: I know. |
| 22:16:39 | gokr1 | But I am guessing Trustable uses the old one. |
| 22:17:12 | gokr1 | Works for me: ../bin/nim c hallo.nim |
| 22:17:38 | gokr1 | And yes, indeed, using "nimrod" fails. |
| 22:18:04 | gokr1 | The "nimrod" compiler left there is... just AFAIK an artefact from the boot procedure. You can nuke it :) |
| 22:18:11 | gokr1 | Trustable: Works? |
| 22:18:14 | Trustable | Solved my using "nim" instead of "nimrod". thanks. |
| 22:18:18 | gokr1 | great |
| 22:18:25 | * | tdc quit (Ping timeout: 260 seconds) |
| 22:19:23 | gokr1 | And best way now is to NOT install - just softlink that nim binary somewhere in your path :) |
| 22:19:59 | Varriount | I wonder if we can/should fix that - perhaps the standard library and compiler code should have a version number matching the nimrod compiler, and the compiler should warn if the number doesn't match? |
| 22:20:40 | Mat3 | I agree, this would be nice |
| 22:21:52 | Varriount | Hm.. what would be the warning... |
| 22:22:39 | Varriount | "Warning: Version mismatch between compiler and standard library - errors may occur"? |
| 22:23:00 | * | tdc_ quit (Quit: Leaving) |
| 22:23:07 | Mat3 | something like that |
| 22:25:52 | Araq | Varriount: good idea. and not hard to do. |
| 22:26:18 | Varriount | Araq: How would you prefer it to be done? |
| 22:26:32 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 22:26:42 | * | johnsoft joined #nimrod |
| 22:27:00 | Varriount | My first impulse would be to make some sort of marker file in the standard library. |
| 22:28:30 | flaviu | Varriount: Too unixy :P |
| 22:30:34 | * | Fr4n quit (Ping timeout: 255 seconds) |
| 22:31:07 | * | Fr4n joined #nimrod |
| 22:31:08 | Araq | Varriount: simple, fill in the real version for NimVersion and then use magicsys to read this value and compare it to nversion |
| 22:36:18 | Varriount | Hm, another question is, should we force the user to specify a command line param to ignore the warning? |
| 22:36:45 | Varriount | Since it would be displayed near the beginning of compiler invocation, and not the end, it's less likely that it will be seen. |
| 22:37:14 | Araq | you can even make it an error unless 'booting' is defined |
| 22:38:52 | flaviu | meh, I'm sure there's at least one obscure usecase where it's intentional |
| 22:39:31 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 22:39:46 | Araq | flaviu: ah, you're learning ;-) |
| 22:40:10 | Varriount | How about an overrideable error when using a library whose version is greater than the compiler, and just a warning when it's less? |
| 22:40:35 | Trustable | Is there already a changelog for bigbreak? |
| 22:40:37 | flaviu | The impression I get from error is "this is non-optional" |
| 22:40:54 | Trustable | Why was it necessary to have the first letter case sensitive? |
| 22:41:00 | Varriount | flaviu: Unless the error message specifies that it can be overridden. |
| 22:41:17 | Varriount | Trustable: So that people can do 'socket = Socket()' |
| 22:41:31 | Trustable | ok |
| 22:41:31 | Varriount | and not have the compiler throw up on them. |
| 22:42:30 | flaviu | Varriount: sorry, but that doesn't make sense to me. Only warnings should be disablable. Errors are for things that cannot be recovered from. |
| 22:43:08 | Varriount | flaviu: Then what do you call a warning that stops the program unless overriden via a command line parameter? |
| 22:43:29 | flaviu | Implement werror? |
| 22:44:03 | Mat3 | Varriount: I'm not sure if it would be better to handle these situation as error if not otherwise (explicitly) specified |
| 22:44:20 | Araq | Varriount: flaviu is right. there are no "optional" errors. (*cough* don't look at --theadAnalysis) |
| 22:45:14 | flaviu | isn't threadAnalysis just a way of specifying you're opting into some possibly buggy analyses? |
| 22:46:27 | Varriount | Araq: Well, it's your call. I've stated what I want done. |
| 22:47:10 | Araq | flaviu: no, it's sound these days. but to be able to compile non-complying code, you can disable it |
| 22:47:51 | gokr1 | Someone commented on my slightly confusing OO article about UI bindings. And we only have gtk right? hmm. |
| 22:48:16 | Araq | we also have IUP and claro bindings |
| 22:48:41 | gokr1 | Ah, right. |
| 22:48:41 | Araq | and I once played a bit with the Tcl binding |
| 22:49:20 | Varriount | IUP? |
| 22:49:21 | Araq | also we have a couple of SDL/opengl based widgets |
| 22:49:24 | gokr1 | Wonder how hard it would be to take that c-thingy that Haskell did for wx - you looked at it, right? |
| 22:49:44 | Araq | and we have some terminal based UI |
| 22:49:59 | Araq | quite a lot of code, I fixed 2 compiler bugs to make it run |
| 22:50:14 | Araq | the developer didn't show up in quite some time though. |
| 22:50:14 | Varriount | Araq: That was whitestag, right? |
| 22:50:21 | Araq | aye |
| 22:50:25 | Araq | that was its name |
| 22:50:28 | Varriount | :< |
| 22:51:16 | Araq | Varriount: well I can't do more than fixing critical bugs |
| 22:51:30 | Araq | if that takes too long for some people, so be it |
| 22:51:43 | Varriount | Araq: My frowny face wasn't at you, it was at him/her not showing up. |
| 22:53:14 | Araq | gokr1: wxWidgets is not that hard to wrap but tedious |
| 22:53:44 | gokr1 | It seems wxRust first does what c2nim does - then they have a Python prog that generates the "high level" layer. |
| 22:53:45 | Mat3 | probably FLTK is a good target too |
| 22:53:52 | Araq | the time is better invested in wrapping Qt afaict |
| 22:54:03 | gokr1 | vs wx? |
| 22:54:08 | Araq | yes |
| 22:54:34 | gokr1 | But those are the top 2 choices I would say. |
| 22:55:01 | flaviu | whitestag? |
| 22:55:24 | Varriount | https://github.com/bbodi/WhiteStag |
| 22:56:35 | Araq | gokr1: no, wx, qt and lazarus are the top 3 choices ;-) |
| 22:56:53 | gokr1 | Mmm, for an IDE you mean? |
| 22:57:08 | Araq | for developing UIs |
| 22:57:16 | Araq | well |
| 22:57:21 | gokr1 | But... for picking the "best" UI toolkit - wouldn't Qt basically trump all? |
| 22:57:32 | gokr1 | I mean, it supports all the mobile platforms too, right? |
| 22:57:33 | Mat3 | no |
| 22:57:45 | Araq | from the list of UI libraries that we have no wrappers for |
| 22:57:47 | flaviu | qt still has a reputation for being heavy |
| 22:57:52 | Mat3 | it is |
| 22:58:14 | Varriount | Araq: Revised the PR for issue 1561 |
| 22:58:34 | Araq | gokr1: dunno about mobile, but lazarus comes with an UI builder and produces *native* widgets for mac, linux, win |
| 22:58:45 | Mat3 | (just one example: Qt features is own preprocessor (!) as I know) |
| 22:58:55 | Araq | for linux both qt and gtk are supported |
| 22:59:02 | Araq | so it has actually 4 backends |
| 22:59:23 | Varriount | Araq: Yeah, but isn't pascal a bit more... object oriented than Nimrod? |
| 22:59:36 | Araq | Varriount: as opposed to Qt? |
| 22:59:47 | Araq | or wxWidgets? (both in c++) |
| 22:59:52 | Varriount | ... point taken. |
| 23:00:14 | gokr1 | I need to read more about Lazarus - I had never heard of it until a few days back,. |
| 23:00:23 | gokr1 | So you mean it fits Nimrod well or? |
| 23:00:30 | gokr1 | Nim, sorry! Nim, Nim... |
| 23:00:32 | Varriount | gokr: Well, it's in pascal. |
| 23:01:08 | Trustable | I'm fixing currently the case-related errors in the gtk2 wrapper |
| 23:01:17 | Araq | gokr1: I mean it's an impressive piece of technology. but it's hard to wrap for Nim. |
| 23:01:28 | flaviu | pas2nim? |
| 23:01:29 | Araq | harder than Qt or wx |
| 23:01:42 | Araq | pas2nim is not nearly up to the task |
| 23:01:51 | gokr1 | And if one would build a Qt app - then you would use the Nim cpp backend, right? |
| 23:02:12 | Araq | gokr1: that's the plan, yes |
| 23:02:12 | gokr1 | Unless it was C-wrapped first I guess. |
| 23:02:27 | gokr1 | But that's ... a biggie I guess. |
| 23:02:34 | Varriount | I'm not sure that it would be easy to use either - using lazarus as a gui would mean having a nimrod layer using a pascal layer using a native/qt/gtk layer. |
| 23:02:46 | Araq | we'll improve the C++ support so that no C wrapper is necessary |
| 23:03:03 | Trustable | oh, I just have to update |
| 23:03:34 | Varriount | Araq: Right now I'm working on getting up the BuildBot. It's going to take a bit of work. |
| 23:03:38 | Araq | Varriount: what works well is to build the UI with lazarus and program the backend in Nim. calling Nim code from Lazarus works nicely. |
| 23:03:53 | Varriount | Araq: Have you tried this? |
| 23:04:01 | Araq | we even have an example for that in the distribution |
| 23:04:35 | Varriount | Araq: Wouldn't it require compiling Qt/GTK, Lazarus, and the Nimrod wrapper on top of everything else? |
| 23:04:41 | Mat3 | Araq: even then, wrapping Qt is a difficult effort |
| 23:05:50 | Araq | Varriount: well usually you install lazarus, no need to compile it |
| 23:06:11 | Araq | and then you compile the project with the ide and link .o files produces from Nim to it |
| 23:06:32 | Araq | *produced |
| 23:07:00 | Varriount | Hm.. I still wish we had a library of our own - something native to Nimrod. |
| 23:07:19 | Araq | sure thing |
| 23:09:00 | Araq | I wanted to slowly port claro to Nim |
| 23:09:14 | Araq | but I won't have the time |
| 23:09:16 | Varriount | Doesn't Claro only work on Windows? |
| 23:10:10 | * | Varriount_ joined #nimrod |
| 23:10:16 | * | superfunc joined #nimrod |
| 23:10:26 | Araq | native widgets for windows, linux (gtk) and macosx (cocoa) |
| 23:10:34 | Araq | but it't not maintained anymore |
| 23:10:42 | Araq | and the code kind of sux |
| 23:11:05 | Araq | the instance the text widget uses a fixed size 1MB buffer |
| 23:11:31 | Araq | because memory management is too painful in c |
| 23:11:42 | flaviu | It should have been a fixed 4GB buffer |
| 23:11:47 | * | Varriount__ joined #nimrod |
| 23:11:52 | flaviu | Then it's the OS's problem :P |
| 23:12:00 | * | bjz quit (Ping timeout: 265 seconds) |
| 23:12:18 | Varriount__ | Designing a gui framework for Nim would require a bit of planning |
| 23:12:37 | * | Varriount quit (Disconnected by services) |
| 23:12:52 | * | Fr4n quit (Ping timeout: 255 seconds) |
| 23:13:02 | * | Varriount__ is now known as Varriount |
| 23:13:27 | Varriount | What would a proper GUI framework for Nimrod even look like, api wise? |
| 23:13:44 | Araq | Varriount: well you can always ask fowl |
| 23:13:56 | Araq | he did one |
| 23:14:31 | * | Fr4n joined #nimrod |
| 23:15:19 | * | Varriount_ quit (Ping timeout: 265 seconds) |
| 23:15:23 | Trustable | I also think of creating a GUI library: WinAPI on Windows, Gtk on Linux |
| 23:18:42 | reactormonk | Trustable, I kinda liked TK, but that's also the only one I've ever worked with |
| 23:19:15 | Varriount | Be back, restarting computer. |
| 23:19:21 | * | Varriount quit (Read error: Connection reset by peer) |
| 23:19:50 | * | Mat3 quit (Quit: Verlassend) |
| 23:20:28 | Trustable | I only know WinAPI and Gtk so far |
| 23:23:05 | gokr1 | Trustable: Google for wxRust, do something similar - in other words, take the C wrap of wx from wxHaskell, then read my article on c2nim - then generate a low level Nim binding. |
| 23:23:26 | gokr1 | When that is done, you can whip up a hello world. |
| 23:23:50 | gokr1 | And then start thinking of the "pure" layer, to make it Nimmish. |
| 23:24:13 | gokr1 | But I think the first start - is a good start. And it might be fairly quickly done, if you are lucky. |
| 23:24:46 | Trustable | gokr1: I will take a look. |
| 23:28:35 | * | Varriount joined #nimrod |
| 23:33:58 | Varriount | I noticed that araq pulled in a PR to nimble packages which includes a GMP wrapper. Anyone played with it yet? |
| 23:35:02 | * | Varriount_ joined #nimrod |
| 23:37:50 | gokr1 | Btw, if anyone feels like reading a... long article on OO in Nim - my confused n00b ramblings on the subject with lots of code: http://goran.krampe.se/2014/10/29/nim-and-oo/ |
| 23:38:03 | gokr1 | And I am all ears fixing things that are wrong in it. |
| 23:38:44 | Varriount_ | Eh.. flaviu, is it me, or did the arch installer disappear from arch? |
| 23:38:47 | * | Varriount quit (Ping timeout: 258 seconds) |
| 23:39:09 | flaviu | Varriount_: Arch doesn't have an installer. I hear it had one a time ago |
| 23:39:16 | flaviu | Before my time with it |
| 23:39:32 | Trustable | gokr1: wxWidgets is way too heavy in my opinion |
| 23:39:42 | * | BitPuffin quit (Remote host closed the connection) |
| 23:39:45 | superfunc | gokr1: I'll give it a look later this evening |
| 23:39:52 | gokr1 | superfunc: cool |
| 23:40:09 | gokr1 | Trustable: Perhaps, but it sure does seem to work. |
| 23:40:23 | * | BitPuffin joined #nimrod |
| 23:53:14 | * | boydgreenfield joined #nimrod |
| 23:54:53 | * | Fr4n quit (Ping timeout: 240 seconds) |
| 23:59:04 | * | Fr4n joined #nimrod |
| 23:59:05 | Varriount_ | flaviu: *cough* https://github.com/helmuthdu/aui *cough* |
| 23:59:27 | * | Varriount_ is now known as Varriount |
| 23:59:31 | flaviu | Varriount_: Just learn to love the command line |