| 00:02:45 | * | BitPuffin joined #nimrod |
| 00:02:53 | * | Varriount-Mobile quit (Read error: No route to host) |
| 00:20:58 | * | ehaliewicz quit (Remote host closed the connection) |
| 00:24:31 | * | Sht0 quit (Ping timeout: 272 seconds) |
| 00:38:25 | * | q66 quit (Quit: Leaving) |
| 00:48:49 | * | dapz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:53:40 | Onionhammer | dom96 no my blog |
| 00:56:28 | * | fowl joined #nimrod |
| 01:01:11 | * | fowl quit (Ping timeout: 272 seconds) |
| 01:14:58 | * | bjz quit (Ping timeout: 258 seconds) |
| 01:20:30 | * | dapz joined #nimrod |
| 01:29:05 | * | cone is now known as clone1018 |
| 01:51:14 | NimBot | Varriount/NimLime master cc0318e AllNamedRTaken [+0 ±3 -0]: NimLime didnt work on Win 8.1 machines... 2 more lines |
| 01:51:14 | NimBot | Varriount/NimLime master a54685f onionhammer [+0 ±3 -0]: Merge pull request #9 from AllNamesRTaken/master... 2 more lines |
| 01:52:10 | * | boydgreenfield joined #nimrod |
| 01:59:43 | Triplefox | jonathan blow gonna talk about language design http://www.twitch.tv/naysayer88 |
| 02:00:20 | Triplefox | i'm probably gonna disagree with everything |
| 02:27:16 | * | adrusi quit (Quit: adrusi) |
| 02:30:11 | * | adrusi joined #nimrod |
| 02:39:37 | * | dapz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 02:52:57 | * | adrusi quit (Quit: adrusi) |
| 02:53:23 | * | kshlm joined #nimrod |
| 02:53:34 | * | wkbrg joined #nimrod |
| 02:56:27 | * | wkoch quit (Ping timeout: 272 seconds) |
| 02:57:09 | * | adrusi joined #nimrod |
| 03:05:11 | * | flaviu1 joined #nimrod |
| 03:14:56 | * | wkochbrg joined #nimrod |
| 03:18:09 | * | wkbrg quit (Ping timeout: 246 seconds) |
| 03:18:19 | * | wkbrg joined #nimrod |
| 03:22:17 | * | wkochbrg quit (Ping timeout: 260 seconds) |
| 03:34:54 | * | brson quit (Quit: leaving) |
| 03:52:47 | * | wkochbrg joined #nimrod |
| 03:55:12 | * | wkbrg quit (Ping timeout: 258 seconds) |
| 03:56:49 | * | flaviu1 quit (Ping timeout: 260 seconds) |
| 04:09:43 | * | fowl joined #nimrod |
| 04:25:55 | * | NimBot joined #nimrod |
| 04:26:22 | * | wkochbrg quit (Ping timeout: 240 seconds) |
| 04:31:16 | * | fowlmouth joined #nimrod |
| 04:31:52 | * | fowl quit (Ping timeout: 245 seconds) |
| 04:34:52 | * | kshlm quit (Ping timeout: 245 seconds) |
| 04:53:51 | * | fowlmouth quit (Ping timeout: 272 seconds) |
| 04:59:53 | * | dapz joined #nimrod |
| 05:02:06 | * | kokozedman joined #nimrod |
| 05:04:00 | kokozedman | hi, wondering, is there an event loop already established in Nimrod that uses poll(3) on Linux? |
| 05:09:56 | * | kshlm joined #nimrod |
| 05:16:37 | * | wkochbrg joined #nimrod |
| 05:18:32 | * | wkbrg quit (Ping timeout: 245 seconds) |
| 06:03:49 | * | Ven joined #nimrod |
| 06:08:16 | * | BlaXpirit joined #nimrod |
| 06:16:00 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 06:16:19 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 06:38:56 | Araq | kokozedman: our async stuff uses epoll already |
| 06:42:03 | kokozedman | Araq: thanks for the info... does that mean, there is no poll(3) but directly to epoll? I mean, epoll is a bit overkill for my usecase, I'm just handling about 10 connections |
| 06:43:52 | kokozedman | are you talking about the asyncio? or the asyncdispatch? |
| 06:48:39 | Araq | the async* modules all work together, but there are also legacy modules |
| 06:49:10 | kokozedman | legacy modules, which ones? |
| 06:50:30 | Araq | or maybe deprecated apis in these modules ... dom96 knows these things much better than I do |
| 06:50:53 | Araq | however asynchttpserver seems to be what you want? |
| 06:51:22 | Araq | it's not a problem if that's much more efficient than you need it to be, right? :-) |
| 06:51:39 | kokozedman | I'm a bit unsure of thestate "still largely experimental" of these libraries |
| 06:53:10 | Araq | well 0.9.6 is around the corner and the api is stable now |
| 06:53:18 | kokozedman | asyncio module is indeed still using select() right? (according to the doc that is) |
| 06:53:51 | kokozedman | oh, that's nice to hear :D ... devel branch is close to that 0.9.6? |
| 06:54:27 | kokozedman | is there a targeted release date for 0.9.6? |
| 06:54:36 | Araq | end of this month |
| 06:55:07 | Araq | devel branch is close, but "bigbreak" is much closer |
| 06:55:35 | kokozedman | alright :) ... I think i'm really interested to check that |
| 07:01:39 | Araq | looking at it, I think asnycio should be deprecated |
| 07:01:45 | Araq | *asyncio |
| 07:01:58 | Araq | asynchttpserver doesn't use it |
| 07:03:01 | kokozedman | is there a kind of "cook book" or wiki that contains common ways to interact directly to C world? I mean, apart from digging a lot of the standard library? |
| 07:03:33 | kokozedman | there are lots of jargons and keywords that newcomers like me find really difficult to grasp in the standard lib |
| 07:05:06 | kokozedman | I really like Nimrod with the speed of dev that it provides, it would be a tremendous boost to that same productivity to have that kind of wiki cookbook in most of Nimrod, in this case, C interoperability |
| 07:05:58 | * | Trustable joined #nimrod |
| 07:13:18 | Araq | kokozedman: "learn nimrod by example"? |
| 07:13:43 | Araq | http://nimrod-by-example.github.io/ |
| 07:13:49 | kokozedman | hmm... that would be a tutorial, but I'm talking about corner cases |
| 07:14:07 | kokozedman | oh, I didn't know about that... thanks for showing to me |
| 07:14:27 | * | Sht0 joined #nimrod |
| 07:16:28 | Araq | but yeah, this doesn't cover the FFI |
| 07:17:23 | kokozedman | yes, FFI really is what I want to learn at this persent time |
| 07:17:55 | kokozedman | there is this project that I have been working on, and it's in C ... I don't want to convert it to Nimrod but I want to just use it straight away |
| 07:18:45 | kokozedman | it's very confusing for the beginners to see how to work this out, especially that the stdlib is filled with advanced keywords that I constantly say, man, what does this mean now? |
| 07:19:41 | kokozedman | you know this feeling that you're completely unsure of what the right way to do that one thing, which keyword, is the context right for the keyword, etc... |
| 07:21:22 | Araq | maybe c2nim's docs can help you? |
| 07:21:34 | Araq | there are essentially 2 ways to do FFI |
| 07:21:49 | Araq | plus you can combine them however you please |
| 07:22:06 | Araq | which might be the source of your confusion |
| 07:22:50 | Araq | but go ahead, just ask here please |
| 07:24:10 | kokozedman | I guess that is one... but in the context of .importc. that is also introduces something unclear to me as to how variables are behaving in terms of GC for example |
| 07:24:20 | kokozedman | same goes for dynlib |
| 07:30:54 | Araq | importc essentially disables name mangling |
| 07:31:10 | Araq | then you can either use .header or .dynlib with it |
| 07:31:30 | Araq | .header causes more problems IMO |
| 07:32:14 | kokozedman | hmm... this is the first time I see .header |
| 07:33:15 | Araq | there is also .nodecl for when you know it's in some #include file that really is already in the scope in the generated C code |
| 07:33:49 | Araq | but that's mostly a legacy |
| 07:34:29 | kokozedman | and there is a dynlib module, and there is a .dynlib. keyword... and the correct uses of all these keywords are really confusing to me 'cause I never get confident which to use in which kind of context |
| 07:40:32 | Araq | kokozedman: you usually don't need the dynlib module at all |
| 07:41:06 | Araq | and it's quite obvious that .dnylib is for interfacing DLL / Lib*.so, right? |
| 07:41:46 | Araq | if you build your C code as a DLL, you interface with it via .dynlib |
| 07:41:51 | kokozedman | yes, so what's the corner usecase for the dynlib module? |
| 07:41:55 | * | io2 joined #nimrod |
| 07:42:10 | Araq | else via .header and then you link your .o files to your Nim code |
| 07:43:02 | kokozedman | Araq: like I said before, this is the first time I have heard of the .header, the manual doesn't contain that... so, where can I find more info about it? |
| 07:43:16 | kokozedman | because I think my existing app is in .o file |
| 07:43:57 | Araq | kokozedman: Python requires DLL lookup of *variables*, which .dynlib didn't support so the dynlib module was created |
| 07:44:56 | kokozedman | so, you're saying, that is no longer the case today? and the dynlib module is kind of deprecated? |
| 07:48:55 | Araq | when you truely want dynamic loading, the dynlib module is still useful |
| 07:49:15 | Araq | dynamic as in "load the DLL only when this proc is called" |
| 07:50:23 | kokozedman | ok, I see... can you point me to the .header documentation? or docs that explains more about it and other related? |
| 07:51:08 | Araq | http://nimrod-lang.org/nimrodc.html#header-pragma |
| 07:51:21 | kokozedman | thanks |
| 07:58:46 | Araq | I gotta go, see you later |
| 07:58:56 | kokozedman | thanks Araq |
| 08:07:47 | * | wkbrg joined #nimrod |
| 08:08:19 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 08:09:12 | * | wkochbrg quit (Ping timeout: 260 seconds) |
| 08:18:37 | * | Skrylar quit (Ping timeout: 245 seconds) |
| 08:38:02 | * | bjz joined #nimrod |
| 08:44:47 | * | Trustable quit (Ping timeout: 272 seconds) |
| 08:45:23 | * | Trustable joined #nimrod |
| 09:01:32 | * | wkochbrg joined #nimrod |
| 09:05:06 | * | wkoch joined #nimrod |
| 09:05:17 | * | wkbrg quit (Ping timeout: 260 seconds) |
| 09:05:17 | * | edayo joined #nimrod |
| 09:07:32 | * | wkochbrg quit (Ping timeout: 260 seconds) |
| 09:16:04 | * | dapz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:34:16 | * | wkbrg joined #nimrod |
| 09:37:52 | * | wkoch quit (Ping timeout: 260 seconds) |
| 09:41:30 | dom96 | kokozedman: Araq: Yes, asyncio is deprecated. Asyncnet should be used for async sockets together with the asyncdispatch module which contains the event loop. |
| 09:46:44 | * | Jesin quit (Ping timeout: 260 seconds) |
| 10:05:49 | * | wkochbrg joined #nimrod |
| 10:09:53 | * | wkbrg quit (Ping timeout: 272 seconds) |
| 10:10:11 | * | wkbrg joined #nimrod |
| 10:14:19 | * | wkochbrg quit (Ping timeout: 272 seconds) |
| 10:49:10 | * | wkochbrg joined #nimrod |
| 10:51:41 | * | wkbrg quit (Ping timeout: 260 seconds) |
| 11:04:10 | * | wkbrg joined #nimrod |
| 11:06:39 | * | wkochbrg quit (Ping timeout: 272 seconds) |
| 11:08:12 | * | kuzy000 joined #nimrod |
| 11:08:42 | * | tdc joined #nimrod |
| 11:15:29 | * | tdc quit (Quit: Leaving) |
| 11:25:43 | * | edayo quit (Read error: Connection reset by peer) |
| 11:26:12 | * | edayo joined #nimrod |
| 11:28:21 | * | tdc joined #nimrod |
| 11:29:55 | * | BlaXpirit joined #nimrod |
| 11:31:17 | * | BlaXpirit quit (Client Quit) |
| 11:32:33 | * | BlaXpirit joined #nimrod |
| 11:34:21 | * | wkochbrg joined #nimrod |
| 11:37:29 | * | wkbrg quit (Ping timeout: 255 seconds) |
| 11:51:42 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 11:52:03 | * | wkbrg joined #nimrod |
| 11:55:39 | * | wkochbrg quit (Ping timeout: 272 seconds) |
| 11:57:19 | * | bjz quit (Ping timeout: 272 seconds) |
| 12:13:28 | * | BitPuffin joined #nimrod |
| 12:17:46 | * | wkochbrg joined #nimrod |
| 12:21:28 | * | wkbrg quit (Ping timeout: 272 seconds) |
| 12:34:29 | * | bjz joined #nimrod |
| 12:42:45 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 12:45:37 | * | wkochbrg quit (Quit: Saindo) |
| 12:55:35 | * | untitaker quit (Ping timeout: 272 seconds) |
| 13:00:56 | kokozedman | dom96: thanks for your confirmation; could there be a some docs on an example on this? |
| 13:01:11 | kokozedman | I mean, the asyncdispatch, not the asyncnet |
| 13:01:44 | kokozedman | I'm currently trying to create a Raw socket: newAsyncRawSocket(AF_PACKET, SOCK_RAW, htons(cast[int16](ETH_P_ALL))) .. failing miserably |
| 13:01:54 | * | untitaker joined #nimrod |
| 13:02:20 | * | francisl quit (Quit: francisl) |
| 13:05:32 | * | edayo quit (Ping timeout: 260 seconds) |
| 13:06:13 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 13:06:52 | * | francisl joined #nimrod |
| 13:07:52 | * | BlaXpirit joined #nimrod |
| 13:09:30 | * | edayo joined #nimrod |
| 13:11:40 | * | AMorpork joined #nimrod |
| 13:16:39 | * | kshlm quit (Ping timeout: 246 seconds) |
| 13:35:06 | * | BitPuffin joined #nimrod |
| 13:40:27 | * | bjz quit (Ping timeout: 246 seconds) |
| 13:42:15 | * | Ven joined #nimrod |
| 13:43:12 | * | bjz joined #nimrod |
| 13:44:27 | * | Ven quit (Client Quit) |
| 13:45:16 | kokozedman | hmm... I'm getting a crash on the compiler, probably something wrong with what I'm doing, but can anyone help point what's wrong? http://pastebin.com/RKKDjyj7 |
| 13:45:18 | * | Ven joined #nimrod |
| 13:46:53 | kokozedman | the error is: Error: internal error: GetUniqueType |
| 13:48:24 | * | vendethiel joined #nimrod |
| 13:49:33 | dom96 | kokozedman: You need to pass a var to cast() not a type |
| 13:49:55 | dom96 | var x: ETH_P_ALL |
| 13:50:01 | dom96 | cast[int16](x) |
| 13:50:16 | kokozedman | oh, I see, thanks |
| 13:50:27 | dom96 | or alternatively: cast[int16](ETH_P_ALL(123)) |
| 13:50:40 | dom96 | but that's a bit pointless anyway :P |
| 13:51:31 | kokozedman | yeah, the ETH_P_ALL is a value from the C header file... how can I have it imported as value? |
| 13:51:33 | demilichsd | Are the C sources generated by the Nimrod compiler portable to Linux-based libcs besides glibc? Such as musl, uClibc and dietlibc. |
| 13:52:09 | kokozedman | demilichsd: I'm targetting OpenWrt which uses uClibc ... so yes |
| 13:52:57 | dom96 | kokozedman: Declare it as a variable |
| 13:53:01 | demilichsd | That's good to know. I would assume the sources generated do not assume any particular semantics, but wanted to make sure. |
| 13:53:06 | dom96 | or better yet a 'let' |
| 13:53:32 | dom96 | const may also work |
| 13:53:41 | dom96 | and if so then use it |
| 13:54:03 | kokozedman | demilichsd: you need to add your toolchain (GCC compiler matching your libc) to the nimrod.cfg |
| 13:54:17 | demilichsd | that would be obvious, yes |
| 13:54:48 | kokozedman | so far, everything I did worked, so no particularities |
| 13:54:59 | kokozedman | (I guess) |
| 13:56:48 | * | darkf quit (Quit: Leaving) |
| 13:57:56 | kokozedman | dom96: so there is no way to get a "value" that is imported from C header files? |
| 13:58:08 | kokozedman | you have to always get it manually? |
| 13:58:36 | dom96 | it should work I think |
| 13:58:49 | * | bjz quit (Read error: Connection reset by peer) |
| 13:58:51 | dom96 | if the header file specifies it |
| 13:59:07 | * | bjz joined #nimrod |
| 13:59:11 | kokozedman | yes, the header does speicify it |
| 13:59:23 | kokozedman | but then how do I get that into Nim? |
| 13:59:57 | * | francisl quit (Quit: francisl) |
| 14:00:10 | kokozedman | as an example, I have this in the header: #define ETH_P_ALL0x0003 |
| 14:00:19 | kokozedman | as an example, I have this in the header: #define ETH_P_ALL 0x0003 |
| 14:01:36 | * | rg4 joined #nimrod |
| 14:03:20 | * | AMorpork quit (Quit: WeeChat 1.0) |
| 14:03:32 | * | AMorpork joined #nimrod |
| 14:04:19 | * | AMorpork quit (Client Quit) |
| 14:09:25 | kokozedman | :) got it |
| 14:24:07 | * | edayo quit (Quit: Leaving) |
| 14:25:53 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 14:37:53 | * | Ven joined #nimrod |
| 14:42:44 | * | kshlm joined #nimrod |
| 14:57:44 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:09:52 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 15:11:24 | * | BlaXpirit joined #nimrod |
| 15:12:56 | * | adrusi quit (Quit: adrusi) |
| 15:22:07 | * | francisl joined #nimrod |
| 15:24:52 | demilichsd | Does Nimrod provide an interface to the syscall(2) function, like Ruby does? |
| 15:25:05 | demilichsd | Or, should I write plain C in such cases? |
| 15:30:24 | BitPuffin | demilichsd: even if it doesn't you wouldn't have to write plain C. You can just call the C function |
| 15:31:23 | demilichsd | ah, BitPuffin |
| 15:31:42 | demilichsd | using a generic pragma to point to the C header effectively creates a wrapper? |
| 15:31:53 | dom96 | yeah, just wrap it. proc syscall(...) {.importc, header: "<sys/syscall.h>".} |
| 15:32:07 | demilichsd | thanks, this will be very useful |
| 15:33:44 | kokozedman | I'm trying to use async with a raw socket that's not defined in the rawsocket/sockets (AF_PACKET for capturing traffic). I managed to get a TSocketHandle from posix.socket(), but then how do I work with the async modules? |
| 15:35:55 | dom96 | kokozedman: I would suggest adding AF_PACKET to rawsockets and then using the asyncnet module. |
| 15:36:36 | dom96 | But perhaps it's a posix-only thing? |
| 15:36:58 | dom96 | Ahh, but that shouldn't be a problem. |
| 15:37:03 | dom96 | I can add it for you if you want. |
| 15:37:28 | kokozedman | dom96: I already thought of that, but I thought, that's not a very clean way to do things. Yes, it's posix only. No alternative that's cleaner? |
| 15:38:13 | dom96 | Why do you consider this unclean? Is it because you have to edit the stdlib modules? |
| 15:38:20 | kokozedman | yes |
| 15:39:12 | * | vegai left #nimrod (#nimrod) |
| 15:39:58 | dom96 | The other way isn't ideal. |
| 15:40:23 | dom96 | It's a lot more work. The fact that rawsockets doesn't specify this constant is a bug. |
| 15:42:24 | dom96 | kokozedman: Can you tell me the value of AF_PACKET? |
| 15:43:47 | * | adrusi joined #nimrod |
| 15:44:06 | kokozedman | dom96: it resolves to 17 after resolving from PF_PACKET |
| 15:44:35 | kokozedman | and I also use the ETH_P_ALL == 0x0003 for the protocol |
| 15:45:49 | * | Demos joined #nimrod |
| 15:47:42 | kokozedman | dom96: something intriges me, what happens for different identifiers with the same value? for example there is ETH_P_ALL == 0x0002 and there is also IPPROTO_IGMP == 2 ... all these values are all ultimately == 2, yet, they are all protocols; in the C context, it is just converted to a short int, but what about Nimrod context? since these values are all protocol, how to you cram them all in and not create a |
| 15:47:44 | kokozedman | value conflict? |
| 15:48:25 | dom96 | hrm |
| 15:48:43 | dom96 | Perhaps it would make sense to allow arbitrary ints to be passed in. |
| 15:49:19 | kokozedman | and there are a whole bunch of other defines in netinet/in.h header + linux/if_ether.h |
| 15:50:07 | kokozedman | indeed, that's what I thought too... because I found out the hard way that Nim types are hard to substitutes to other types |
| 15:52:33 | kokozedman | and who's making the decision for this kind of change? I'm just curious; i'm guessing if it is changed, hell will break lose |
| 15:53:09 | dom96 | I can simply introduce an overload and that we get the best of both worlds :) |
| 15:53:14 | dom96 | *that way |
| 15:54:22 | kokozedman | hmm... can't wait to see your changes about that, 'cause I'm curious how can I solve this problem right now... can't seem to be able to advance anywhere around this problem |
| 16:00:25 | dom96 | kokozedman: are you on the bigbreak branch? if not then you will need to switch to it. |
| 16:01:11 | * | dapz joined #nimrod |
| 16:01:41 | kokozedman | dom96: on devel... doesn't have it? |
| 16:02:13 | dom96 | there is a lot of async improvements in the bigbreak branch |
| 16:02:31 | kokozedman | cool... switching |
| 16:03:01 | * | Jehan_ joined #nimrod |
| 16:03:28 | NimBot | Araq/Nimrod bigbreak 867dfbf Dominik Picheta [+0 ±4 -0]: Adds socket creation for arbitrary domain, type and protocol. |
| 16:03:31 | dom96 | There you go. |
| 16:03:53 | dom96 | Haven't tested it but it should work heh |
| 16:04:54 | * | brson joined #nimrod |
| 16:05:21 | Jehan_ | Very reassuring. :) |
| 16:09:10 | kokozedman | dom96: no need to recompile my whole Nim right? |
| 16:09:27 | dom96 | kokozedman: there is |
| 16:09:34 | dom96 | likely need to grab c sources again |
| 16:10:24 | kokozedman | ohhh... for c sources, there is no need of branch thingy right? |
| 16:10:34 | kokozedman | just pull |
| 16:10:35 | Jehan_ | If you want to use the bigbreak branch, here's how it goes: https://gist.github.com/rbehrends/0e3f58a229ba31396253 |
| 16:10:50 | * | Ven joined #nimrod |
| 16:10:54 | Jehan_ | Basically, you need the matching branch in csources. |
| 16:11:10 | kokozedman | ok, I see, thanks |
| 16:12:13 | Jehan_ | Okay, so the Boehm GC bug I ran into last night has disappeared and I don't know why ... |
| 16:13:44 | Jehan_ | Ah, nevermind, needed --threads:on |
| 16:25:20 | * | Jesin joined #nimrod |
| 16:36:42 | * | francisl quit (Quit: francisl) |
| 16:48:01 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 16:48:27 | * | adrusi quit (Ping timeout: 255 seconds) |
| 16:49:22 | * | askatasuna joined #nimrod |
| 16:49:40 | kokozedman | dom96: running the asyncnet example, I get: lib/pure/asyncdispatch.nim(1067, 7) Error: 'cb' is not GC-safe |
| 16:49:53 | * | francisl joined #nimrod |
| 16:49:55 | kokozedman | example at http://nimrod-lang.org/asyncnet.html |
| 16:51:37 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:53:41 | * | Ven joined #nimrod |
| 16:53:55 | * | adrusi joined #nimrod |
| 16:59:59 | * | dapz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 17:04:16 | NimBot | Araq/Nimrod bigbreak 83e26cc Dominik Picheta [+0 ±1 -0]: Fixes asyncnet example. |
| 17:04:49 | dom96 | kokozedman: This should work: https://gist.github.com/dom96/8b82fca017092b89c1ce |
| 17:09:55 | kokozedman | thanks... that worked; now, there seems to be some changes that I'm not aware of, so where do we get the documentation for the next up-coming 0.9.6? for example, I don't seem to know about asyncCheck |
| 17:12:00 | dom96 | unfortunately doc gen is broken for bigbreak currently. But you should be able to generate docs yourself by executing nim doc2 lib/pure/asyncdispatch.nim |
| 17:12:24 | * | q66 joined #nimrod |
| 17:13:18 | NimBot | Araq/Nimrod devel 67525d7 PavelVozenilek [+0 ±1 -0]: more precise word |
| 17:13:18 | NimBot | Araq/Nimrod devel a179dde Dominik Picheta [+0 ±1 -0]: Merge pull request #1532 from PavelVozenilek/devel... 2 more lines |
| 17:20:15 | * | dapz joined #nimrod |
| 17:23:22 | * | betawaffle quit (Ping timeout: 240 seconds) |
| 17:33:55 | * | Matthias247 joined #nimrod |
| 17:38:23 | * | adrusi quit (Quit: adrusi) |
| 17:40:08 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:42:59 | * | BitPuffin joined #nimrod |
| 17:47:51 | * | Ven joined #nimrod |
| 18:17:04 | Onionhammer | dom96 doh on the epoll thing ;) |
| 18:17:12 | Onionhammer | dom96 i never actually got it to compile because of that error yesterday |
| 18:21:53 | * | shodan45 quit (Quit: Konversation terminated!) |
| 18:25:40 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 18:27:19 | * | BlaXpirit joined #nimrod |
| 18:32:32 | * | JasonJAyalaP joined #nimrod |
| 18:33:53 | JasonJAyalaP | I've written the (most) of the (first) rough draft for a learnxinyminutes.com nimrod tutorial. I uploaded it as a gist so that I can get some initial impressions. I'll have it in a repo soon. |
| 18:33:55 | JasonJAyalaP | https://gist.github.com/JasonJAyalaP/62597df6dd1fde37d7fb |
| 18:34:28 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:34:33 | JasonJAyalaP | Note: Since they say that learnxiny is aim at experienced programmers, I went the stereotypical "variables -> types -> data structures -> functions" route |
| 18:41:08 | * | dapz joined #nimrod |
| 18:41:21 | Araq | JasonJAyalaP: 'const' explanation could be better |
| 18:41:42 | Araq | s/bound/computed/ |
| 18:42:11 | Araq | also the language is renamed to Nim |
| 18:42:27 | Araq | the TPrefixes are deprecated for types |
| 18:43:33 | Araq | the indentation for the 'case' - while valid - doesn't make much sense IMHO |
| 18:44:05 | Araq | reason: 'elif' is not indented either |
| 18:49:02 | JasonJAyalaP | ah. I indented `case` in two different ways. `of` should be same column? |
| 18:49:26 | Araq | yeah but I guess it's better to show both ways are allowed |
| 18:49:43 | Araq | on the same column is the preferred style though |
| 18:49:57 | * | tdc quit (Ping timeout: 255 seconds) |
| 18:51:32 | JasonJAyalaP | I'll fix it. It's usually better to show "most common, memorize this way" for a quick tutorial. Later on they can run into all the variations and edge cases :) |
| 18:51:32 | dom96 | JasonJAyalaP: Remove the spaces before the : in var declarations |
| 18:51:57 | Araq | oh yeah I hate these with a passion :P |
| 18:52:19 | JasonJAyalaP | We need a nimfmt then! |
| 18:52:34 | Araq | the colon is not important enough to emphasize it with hard to maintain alignments |
| 18:52:38 | JasonJAyalaP | Or at least a regex i can put into a vim %s to fix that... |
| 18:53:02 | JasonJAyalaP | Araq: You say that now, but wait until your 60 |
| 18:53:30 | JasonJAyalaP | fixing the TTypes now.. |
| 18:53:45 | Araq | JasonJAyalaP: with some luck I'll never become that old :-) |
| 18:54:37 | JasonJAyalaP | Araq: technological singularity, or ascension into heaven? |
| 18:56:03 | Araq | I don't really care as long as the pain of using computers ends |
| 18:56:22 | * | demilichsd quit (Ping timeout: 240 seconds) |
| 18:56:28 | JasonJAyalaP | Araq: type name = string creates conflict with var name ? Compiler tells me redefinition |
| 18:56:49 | JasonJAyalaP | Araq: Get thee to a monastary! |
| 18:57:03 | Araq | JasonJAyalaP: use Name for the type and --cs:partial |
| 18:57:03 | JasonJAyalaP | *type Name I should say |
| 18:58:13 | JasonJAyalaP | Will built-in types be renamed with Capitals? |
| 18:58:48 | Araq | no |
| 18:59:04 | Araq | some are renamed, int etc. will stay lowercase |
| 18:59:11 | Araq | it's too annoying to be consistent |
| 19:02:15 | JasonJAyalaP | Araq: What about `const` would you clarify? |
| 19:02:41 | Araq | at the very least replace "bound" with "computed" |
| 19:02:47 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:02:49 | JasonJAyalaP | Fixed |
| 19:03:16 | JasonJAyalaP | I updated the gist. Fixed those problems you mentioned (except the : ... still working on the regex) |
| 19:05:38 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:09:04 | * | tdc joined #nimrod |
| 19:09:12 | Araq | dom96: ugh should we even bother to update all this SDL stuff? |
| 19:09:26 | Araq | everybody wants to use SDL 2.0 now, right? |
| 19:10:22 | * | tdc quit (Max SendQ exceeded) |
| 19:11:00 | * | tdc joined #nimrod |
| 19:11:23 | * | demilichsd joined #nimrod |
| 19:12:16 | Araq | oh well, nimfix already did most of the work for me |
| 19:12:28 | Araq | I might as well finish it |
| 19:12:34 | * | Joe_knock joined #nimrod |
| 19:12:50 | * | tdc_ joined #nimrod |
| 19:13:04 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:13:37 | * | Joe_knock joined #nimrod |
| 19:14:38 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:15:10 | * | Joe_knock joined #nimrod |
| 19:15:17 | * | Joe_knock quit (Changing host) |
| 19:15:18 | * | Joe_knock joined #nimrod |
| 19:15:48 | * | Jesin quit (Quit: Leaving) |
| 19:15:58 | * | tdc quit (Ping timeout: 244 seconds) |
| 19:16:09 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:16:42 | * | Joe_knock joined #nimrod |
| 19:17:37 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:18:10 | * | Joe_knock joined #nimrod |
| 19:18:12 | * | Ven joined #nimrod |
| 19:18:21 | JasonJAyalaP | Ahh, there we go: %s/\s\+:/:/ |
| 19:19:03 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:19:05 | Jehan_ | JasonJAyalaP: Immutable variables are not just a functional programming thing. |
| 19:19:33 | JasonJAyalaP | Jehan_: Immutable variables are for all to enjoy! |
| 19:19:36 | * | Joe_knock joined #nimrod |
| 19:19:51 | Jehan_ | I'd try not to make an argument, but simply explain that let creates immutable name assignments. |
| 19:19:57 | Jehan_ | It's a bit of a tricky concept. |
| 19:20:27 | * | Jesin joined #nimrod |
| 19:20:29 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:20:31 | Jehan_ | You can have both of a let and a var name referencing the same object and can still modify the referenced object through the var version. |
| 19:21:01 | * | Joe_knock joined #nimrod |
| 19:21:05 | Araq | Jehan_: actually I wouldn't count on this feature to stay in the language |
| 19:21:14 | Araq | Joe_knock: please fix your connection |
| 19:21:29 | Joe_knock | Araq: In progress. |
| 19:21:33 | Jehan_ | But it's helpful in that you know that (1) using a let reference will not be involved in any mutation and (2) you can make the object immutable by not having aliasing. |
| 19:21:39 | Jehan_ | Araq: Oh, interesting? |
| 19:21:58 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:22:15 | Jehan_ | Are you planning on performing a copy when you use let with a var alias? |
| 19:22:54 | JasonJAyalaP | Link updated with fixed formatting: https://gist.github.com/JasonJAyalaP/62597df6dd1fde37d7fb |
| 19:23:09 | JasonJAyalaP | Any major complaints about the structure or proposed TODOs ? |
| 19:23:33 | Jehan_ | consts aren't just about performance; most importantly, they can be involved in compile time expressions. |
| 19:23:50 | Jehan_ | For example, you can use a const for the size of an array, but not a let variable. |
| 19:24:07 | Jehan_ | JasonJAyalaP: Just reading over it, giving you feedback as I go. :) |
| 19:24:30 | dom96 | Araq: We're moving it to babel anyway. |
| 19:24:53 | Araq | dom96: yeah but I'm fixing it anyway |
| 19:25:02 | Araq | it needs fixing for Babel too |
| 19:25:31 | Jehan_ | I think using discard for multi-line comments needs some more explanation. |
| 19:25:34 | JasonJAyalaP | Jehan_: Np |
| 19:25:40 | Araq | Jehan_: no additional copy, but some best effort to forbid aliasing to 'let' variables |
| 19:25:42 | Jehan_ | It's really a way to comment out code that isn't working. |
| 19:26:05 | Jehan_ | If you want a normal comment that runs over multiple lines, better to use a column of #'s. |
| 19:26:34 | Jehan_ | discard """…""" tends to signal code that does not work or is only used for debugging or some such thing. |
| 19:27:12 | Araq | not really |
| 19:27:17 | Araq | we have 'when false' for that |
| 19:27:32 | Araq | I use discard """ """ for multi line comments, sometimes |
| 19:27:43 | Jehan_ | Araq: Hmm, that's pretty ugly, I have to say. |
| 19:28:08 | Jehan_ | But "when false" is probably a good thing to use for the examples of erroneous code. |
| 19:28:08 | Triplefox | Triple quoted comments were okay in python |
| 19:28:28 | JasonJAyalaP | It will look bad to have to go into details about indenting, compile time issues, etc while still on the "Here's a comment" section |
| 19:28:41 | Triplefox | They just seem out of place with the additional rule |
| 19:28:48 | Jehan_ | JasonJAyalaP: I know. |
| 19:28:52 | dom96 | We really need a better multi-line comment syntax IMO |
| 19:28:57 | JasonJAyalaP | discard """ brings up the compiler, unfortunately, but i dunno |
| 19:28:58 | Jehan_ | Plus, you'd also have to explain discard. |
| 19:29:15 | Jehan_ | I'd suggest moving discard """….""" towards the end. |
| 19:29:23 | Jehan_ | As an advanced feature. |
| 19:29:25 | dom96 | Many people will simply stop reading when they see such an ugly multi-line comment syntax. |
| 19:29:27 | Araq | why? it's perfectly clean. It was code you used but now you don't anymore. hence the 'when false', Jehan_ |
| 19:29:46 | Jehan_ | Araq: No, the when false is fine, I meant using discard ""…"" for multiline comments. |
| 19:30:01 | JasonJAyalaP | discard """ looks nice to comment out the code that won't compile... But I can simply replace all discard """ with a bunch of #s |
| 19:30:21 | Jehan_ | JasonJAyalaP: You can use "when false" for code that won't compile. |
| 19:30:22 | Araq | JasonJAyalaP: but you should use 'when false' :P |
| 19:30:25 | Jehan_ | Unless it won't even parse. |
| 19:30:34 | Araq | yeah |
| 19:30:38 | Jehan_ | In which case, discard """…""" is still useful. |
| 19:30:52 | Jehan_ | But as I said, that's an advanced feature that should come at the end. |
| 19:31:01 | Araq | yeah I agree |
| 19:31:25 | dom96 | Since this is 'bigbreak' why don't we finally introduce a new multi-line comment syntax? |
| 19:31:29 | Araq | it's not even a feature. it's an interaction of language features that was discovered |
| 19:31:46 | Jehan_ | dom96: Is there a need for multi-line comments? |
| 19:32:04 | dom96 | Jehan_: Yes there is: for doc comments. |
| 19:32:06 | JasonJAyalaP | I only use discard """ to comment out errors (I think). I could just replace them with #s |
| 19:32:10 | Jehan_ | I mean, even in C, multi-line comments usually get a column of asterisks in front. |
| 19:32:29 | Jehan_ | dom96: Yeah, but why not just prefix multiple lines with #? |
| 19:32:47 | dom96 | Jehan_: Too much hassle. |
| 19:33:05 | Jehan_ | JasonJAyalaP: In the example, you can use "when false:" instead to comment out errors. |
| 19:33:26 | Jehan_ | This will also keep syntax highlighting for the erroneous code intact. |
| 19:33:36 | Triplefox | The biggest use cases i see for multiline are the intro and then api docs |
| 19:33:47 | Araq | dom96: and update all the syntax highlighters out there? |
| 19:33:49 | JasonJAyalaP | Jehan_: But then I have to explain `when` as a compile time `if`, and `when false` as a sort of trick for bad code... |
| 19:33:59 | * | dapz joined #nimrod |
| 19:34:05 | dom96 | Araq: That's really a non-issue. |
| 19:34:16 | Araq | how can you say that? |
| 19:34:17 | dom96 | Pygments is already full of bugs. |
| 19:34:20 | dom96 | And needs an update. |
| 19:34:26 | Araq | it took *years* to get it into github |
| 19:34:33 | dom96 | It really didn't. |
| 19:34:41 | Jehan_ | JasonJAyalaP: I think when as Nim's way of doing #if should be straightforward and the #if 0 <-> when false equivalence also. |
| 19:34:47 | * | Joe_knock joined #nimrod |
| 19:34:56 | JasonJAyalaP | While we're here, I'll just add that a Literate Nimrod would be great! ...I'll get my coat. |
| 19:35:24 | * | Demos_ joined #nimrod |
| 19:35:26 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:35:42 | dom96 | JasonJAyalaP: We have filters for that: http://build.nimrod-lang.org/docs/filters.html |
| 19:35:45 | Araq | really? I consider Literale programming quite absurd... |
| 19:35:53 | dom96 | JasonJAyalaP: (I think, I never used any literate * stuff) |
| 19:35:57 | Araq | *Literate |
| 19:36:23 | Triplefox | I tried it once, it's okay |
| 19:36:28 | JasonJAyalaP | dom96: Oh. neat. |
| 19:36:39 | Triplefox | But not a natural way to write new code |
| 19:36:46 | dom96 | The syntax in filters can use a lot of improvements too IMO. |
| 19:37:15 | * | Joe_knock joined #nimrod |
| 19:37:18 | dom96 | But it supports custom prefixes, they were broken last time I used them but that's a whole different issue. |
| 19:37:24 | Jehan_ | addSugar doesn't really need a void result type. |
| 19:37:47 | dom96 | Araq: It's really not the end of the world if the multi-line comment syntax will be broken for a while on github. |
| 19:37:48 | * | Joe_knock quit (Max SendQ exceeded) |
| 19:37:51 | * | flaviu1 joined #nimrod |
| 19:37:54 | Araq | dom96: did you report that? |
| 19:37:58 | Jehan_ | What's missing is an explanation of the implicit "result" variable. |
| 19:38:06 | Araq | flaviu1: your nim by example needs an FFI section |
| 19:38:06 | dom96 | Araq: Can't remember, it was a really long time ago. |
| 19:38:28 | JasonJAyalaP | is lowerCamelCase the best way to name variables and procs? |
| 19:38:30 | Araq | I plan to use the new VM for crazier source code filters ... |
| 19:38:31 | JasonJAyalaP | Jehan_: Agreed |
| 19:38:35 | * | Demos quit (Ping timeout: 258 seconds) |
| 19:38:54 | Araq | JasonJAyalaP: it is the standard according to our precious guidelines |
| 19:39:13 | Jehan_ | The loop/continue example seems a bit complicated. |
| 19:39:26 | dom96 | 80 users. New record! |
| 19:40:07 | dom96 | Araq: Please please please, can we have a new multi-line comment syntax? |
| 19:40:20 | Jehan_ | dom96: What kind of syntax would you want? |
| 19:40:59 | dom96 | I don't mind, as long as it's shorter than discard """ ... """ |
| 19:41:27 | Jehan_ | Here's the thing, look at the introductory multi-line comments in: https://github.com/apache/httpd/blob/trunk/server/config.c |
| 19:41:31 | Jehan_ | Just as an example. |
| 19:41:39 | flaviu1 | Araq: Ok, I'll work on that soon |
| 19:41:48 | Jehan_ | They may be multi-line, but every single line is still prefixed with a '*' |
| 19:41:54 | Araq | flaviu1: yay. thanks! |
| 19:42:13 | Araq | Jehan_: yeah and I consider it barbaric |
| 19:42:22 | Araq | it's like ASCII art |
| 19:42:22 | Jehan_ | Araq: That's my point. |
| 19:42:50 | dom96 | I wouldn't do that though. |
| 19:42:52 | Araq | Hu? |
| 19:42:55 | Jehan_ | If you do this, there's no difference to just using a single line comment style for each line. |
| 19:43:23 | Araq | Jehan_: yeah but other people use multi line comments for having multi line comments :-) |
| 19:43:33 | Jehan_ | dom96: Generally, you should be able to see if a line is a comment without syntax highlighting. |
| 19:43:46 | Araq | nah |
| 19:43:51 | Jehan_ | Araq: Like =begin/=end in Ruby that nobody uses? :) |
| 19:44:10 | Araq | if you don't have syntax highlighting, you shouldn't even look at the code |
| 19:44:22 | JasonJAyalaP | btw, are they called "Type Alias" or "Type Synonym"? |
| 19:44:41 | Jehan_ | Sometimes not an option if you're ssh-ing into a server and view code with "less". |
| 19:44:50 | Araq | pffff |
| 19:45:12 | Araq | welcome in the current century |
| 19:45:33 | JasonJAyalaP | And that plan9 editor which uses 3 mouse buttons is very anti-highlighting |
| 19:46:10 | Araq | JasonJAyalaP: "type alias" |
| 19:46:55 | Jehan_ | Araq: Well, the current century is awash in cloud services. |
| 19:47:50 | dom96 | Araq: I know that you like to avoid it but the current century still enjoys ssh from time to time :P |
| 19:50:05 | * | Sht0 quit (Ping timeout: 258 seconds) |
| 19:50:28 | * | Sht0 joined #nimrod |
| 19:50:35 | dom96 | That said, even ssh supports syntax highlighting. |
| 19:50:53 | Araq | well I don't mind multi line comments too much |
| 19:51:05 | Araq | but I also do not see a real value |
| 19:51:39 | Araq | dom96: if you want them, open some forum thread so people can discuss minor syntactic details endlessly |
| 19:52:55 | * | Joe_knock joined #nimrod |
| 19:53:43 | dom96 | Araq: That's not productive. |
| 19:54:26 | Araq | dom96: people appreciate to have some mild form of democracy though |
| 19:54:33 | dom96 | You simply have to agree with me :P |
| 19:56:31 | dom96 | As far as I can see the only problem that an introduction of a new syntax will bring will be that we break syntax highlighters. |
| 19:57:08 | dom96 | But imagine the horror people feel when they see that they must write 'discard """' for multi line comments. |
| 19:58:12 | dom96 | The fact that """ is highlighted as a string doesn't help. |
| 19:58:35 | Joe_knock | Araq: it was a "who" issue. |
| 19:59:39 | dom96 | Joe_knock: interesting. Your client was sending that command too much? |
| 20:01:25 | flaviu1 | how about |
| 20:01:25 | flaviu1 | multiline-comment := '{' inner-multiline-comment '}' |
| 20:01:25 | flaviu1 | inner-multiline-comment := '#' text* '#' |
| 20:01:34 | Joe_knock | dom96: auto-joining 11 channels and so I think it was sending it to like every user in every channel |
| 20:02:01 | flaviu1 | Since I love to bikeshed so much |
| 20:02:14 | Araq | flaviu1: is that what Haskell uses? |
| 20:02:27 | flaviu1 | I just made it up right now, no idea |
| 20:02:40 | * | JasonJAyalaP quit (Ping timeout: 246 seconds) |
| 20:02:59 | Jehan_ | dom96: Whatever syntax you choose will probably break somebody using it for an operator. :) |
| 20:03:05 | * | Varriount|Mobile joined #nimrod |
| 20:03:08 | Araq | flaviu1: if it's not copied from Haskell, it cannot be correct |
| 20:03:52 | Jehan_ | My suggestion would be simply to have a "comment procedure" that does nothing (i.e., the same thing that discard does). |
| 20:04:01 | Jehan_ | This way you can write: comment """ …. """ |
| 20:04:39 | Araq | that's not shorter |
| 20:04:51 | Jehan_ | No, but it doesn't confuse people about its meaning. |
| 20:05:13 | Jehan_ | Which I think is what the issue with discard was. |
| 20:05:33 | dom96 | Jehan_: not necessarily. |
| 20:05:59 | dom96 | No, the primary issue is the length. |
| 20:06:14 | dom96 | Araq: Haskell uses {- -} IIRC |
| 20:06:25 | Araq | Jehan_: we can use #[] and break very little code and in particular no operators |
| 20:06:26 | dom96 | We could use ### ... ### |
| 20:06:48 | Jehan_ | Both could break existing comments. |
| 20:06:56 | Araq | dom96: that would be very consistent but is that a doc comment or not? |
| 20:07:22 | dom96 | Araq: We could use #### for doc comments. |
| 20:07:36 | Araq | dom96: ugh |
| 20:07:56 | Jehan_ | For inspiration: http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)#Comment_comparison |
| 20:08:01 | Araq | btw doc comments are part of the grammar, but ordinary comments are not anymore |
| 20:08:42 | dom96 | Not as nice a comparison but more languages here: http://rosettacode.org/wiki/Comments |
| 20:08:57 | Jehan_ | An alternative would also be to simply allow """…""" without discard. |
| 20:09:25 | Araq | Jehan_: I don't think this works well with the expr/stmt unification |
| 20:09:39 | dom96 | Yeah. That wouldn't be a good idea. |
| 20:09:49 | Jehan_ | Oh, right, I forgot that. I was thinking primarily about doc comments. |
| 20:10:14 | Araq | #[] and ##[] is pretty clear |
| 20:10:22 | Araq | clearer than ### vs #### |
| 20:11:06 | Araq | and now I remember why I'm against them. it's just a tad too complex |
| 20:11:27 | Araq | and then you have to answer if #[] can be nested |
| 20:11:40 | Jehan_ | #[]/##[] have problems when there are brackets in the comment, though. |
| 20:12:05 | Jehan_ | End of comment can't really be a normal token. |
| 20:12:33 | Araq | #[ and ]# then. *shrug* |
| 20:13:12 | Jehan_ | Sure, just wanted to mention it. :) |
| 20:13:52 | Jehan_ | Anyhow, I've got stuff to do still. See you around. :) |
| 20:13:53 | * | Jehan_ quit (Quit: Leaving) |
| 20:14:33 | dom96 | sure |
| 20:14:42 | dom96 | It's not super sexy |
| 20:14:47 | dom96 | but it's better than what we have now... |
| 20:19:20 | NimBot | Araq/Nimrod devel b114935 Reimer Behrends [+0 ±1 -0]: Various fixes to how the Boehm GC's interface.... 5 more lines |
| 20:19:20 | NimBot | Araq/Nimrod devel 2fde559 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1533 from rbehrends/fix-boehmgc-interface... 2 more lines |
| 20:23:26 | * | endou____ quit (Ping timeout: 258 seconds) |
| 20:25:23 | * | endou_____ joined #nimrod |
| 20:29:07 | * | brson quit (Quit: Lost terminal) |
| 20:29:16 | * | brson joined #nimrod |
| 20:29:49 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:30:27 | * | vendethiel quit (Quit: q+) |
| 20:45:57 | * | tdc_ is now known as tdc |
| 20:54:52 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 20:58:19 | * | Mat3 joined #nimrod |
| 20:58:23 | Mat3 | hello |
| 20:59:04 | Araq | servus |
| 20:59:09 | Araq | fyi my connection is very bad |
| 20:59:19 | Araq | Mat3: what's the status of your C compiler? |
| 21:00:00 | Discoloda | a new c compiler? |
| 21:00:37 | Araq | Discoloda: we try to embed that into Nim :-) |
| 21:00:57 | Araq | advantage: even .emit works for compile time evaluation |
| 21:01:06 | Araq | well we'll see |
| 21:01:24 | * | Jesin quit (Quit: Leaving) |
| 21:01:46 | Mat3 | Araq: start porting the sources to Nim(rod) |
| 21:01:48 | Discoloda | ah, i see |
| 21:02:08 | * | adrusi joined #nimrod |
| 21:02:08 | Discoloda | you have a tinyc directory, whats that for |
| 21:02:23 | Araq | tinyC used to work with the compiler |
| 21:02:46 | Araq | but since it's not maintained anymore we don't support it anymore |
| 21:03:18 | Discoloda | might as well delete it, it is in git history |
| 21:03:44 | dom96 | Mat3: on github yet? |
| 21:04:38 | Araq | Discoloda: yes for this case. but in general pretending people should constantly look into git history to see failed attempts is misguided |
| 21:04:58 | Mat3 | may I remark that TinyC is a compiler with a really long history ? |
| 21:05:16 | Araq | Mat3: I know about its history |
| 21:05:57 | Mat3 | dom96: nope, I'm currently create a new Github repro for it |
| 21:08:32 | * | kuzy000 quit (Ping timeout: 260 seconds) |
| 21:11:27 | Mat3 | dom96: ok, I try to upload my sources |
| 21:11:35 | Discoloda | i guess it depends on whats more important, presenting what is used and maintained or showing failed attempts |
| 21:14:19 | Mat3 | if I remember correcly I need a new SSH hash for the new created repro ? |
| 21:14:36 | * | mko joined #nimrod |
| 21:14:48 | * | tdc quit (Ping timeout: 244 seconds) |
| 21:15:04 | dom96 | Mat3: Just for your github account. |
| 21:17:43 | Mat3 | thanks |
| 21:17:59 | dom96 | thanks for putting it on github :) |
| 21:18:39 | wan | You could delete tinyC from the git history right after tagging the last time it is present. So it would be reachable, and cleaned up. |
| 21:23:52 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 21:24:02 | Araq | wan: sounds to me like it's not for me |
| 21:24:33 | dom96 | it's not that big is it? |
| 21:24:38 | dom96 | We should simply remove it in a commit. |
| 21:25:14 | * | Mat3 wonders about git |
| 21:27:16 | kokozedman | in the last few days, I have been using 0.9.4 for my OpenWrtproject ... today I switched to bigbreak, and sure enough... it is no longer working; there is a dependency to several header files that are non-existant in uClibc/OpenWrt world, such as aio.h, fenv.h and probably others. Could there be some ways to disable dependencies to those? are they critically important? |
| 21:27:37 | * | nande joined #nimrod |
| 21:28:13 | * | Roin quit (Ping timeout: 245 seconds) |
| 21:28:36 | Araq | kokozedman: try to compile with --deadCodeElim:on please |
| 21:29:24 | * | Roin joined #nimrod |
| 21:29:35 | kokozedman | Araq: I've already tried that, no luck |
| 21:30:33 | dom96 | It seems that osproc changes introduced aio.h |
| 21:30:59 | dom96 | There is a hasAioH const in posix.nim |
| 21:31:19 | dom96 | which is set to 'defined(linux)' |
| 21:31:38 | dom96 | Is there a way to detect the libc? |
| 21:31:58 | kokozedman | dom96: I've already tried to disable that, and there are more headers being requested and do not exist: fmtmsg.h (not sure which part requires it, but I stopped checking because it seems that I'm really fighting against it |
| 21:33:37 | dom96 | Unfortunately I think it's a case of fixing it one by one. |
| 21:34:27 | Araq | it's also a case of accepting the fact that the people who come here and pretend to know better than we do really don't |
| 21:36:11 | kokozedman | fair enough, I'm a noob in terms of Nim mastery... but improvements over libraries and languages are always intriguing |
| 21:36:15 | dom96 | I think it's a good idea not to make our contributors feel bad. |
| 21:36:42 | Araq | kokozedman: oh no, I'm not talking about you |
| 21:36:57 | Araq | I'm talking about our general happiness to apply PRs |
| 21:37:16 | kokozedman | Araq: I really thought you did |
| 21:37:20 | EXetoC | a new C compiler? interesting |
| 21:39:05 | EXetoC | Mat3: what's your motivation? |
| 21:39:12 | Mat3 | I'm start switching (and porting over my sources) only if the new version seem to be stable |
| 21:39:18 | dom96 | The problem is that sometimes we have to trust others. |
| 21:39:20 | kokozedman | dom96: I'm really not sure how much changes will be required to make it work on OpenWrt again... I'll try for a while and I'll see where it leads |
| 21:39:28 | dom96 | We are not experts on everything. |
| 21:39:38 | dom96 | But this also highlights our need for a better testing infrastructure. |
| 21:40:10 | Araq | not really. OpenWrt is not officially supported, heck I don't even know what that is |
| 21:40:22 | Mat3 | EXetoC: Integrate my vm environment with Nim(rod) |
| 21:40:24 | kokozedman | yeah, I agree on the testing |
| 21:40:38 | dom96 | True. We don't officially support other libc's. |
| 21:41:05 | Araq | no, we need people like kokozedman that tell us that's *used* |
| 21:41:21 | Araq | otherwise it's simply some target that the builder tells us now fails |
| 21:41:31 | Araq | and nobody can be bothered to fix it for months |
| 21:41:37 | dom96 | Yes. And he told us :) |
| 21:41:40 | dom96 | Anyway. |
| 21:42:04 | dom96 | Is there a way to check whether something is defined in a .h file? |
| 21:42:09 | Mat3 | It would be nice to see some kind of documentation which summarizes the changes to the current stable version |
| 21:42:11 | Araq | yeah and we're willing to support it now :-) |
| 21:42:31 | * | adrusi quit (Quit: adrusi) |
| 21:42:50 | Araq | Mat3: we're working on it, but it's really |
| 21:42:55 | Araq | a) the name changed to Nim |
| 21:42:59 | dom96 | Because then we can add a const usesGLibC = defined(__GLIBC__). 'Defined' won't work here though. |
| 21:43:02 | Araq | b) --cs:partial is now the default |
| 21:43:42 | dom96 | or better yet figure out a way to detect the libc kokozedman is using |
| 21:43:50 | dom96 | I guess it defines some symbol too. |
| 21:44:37 | Araq | dom96: you have to use staticExec for some tiny generated C program to test for this |
| 21:44:44 | dom96 | This is a good start but we need to add to it: https://github.com/Araq/Nimrod/blob/bigbreak/web/news.txt#L9 |
| 21:44:59 | dom96 | Araq: bah really? |
| 21:45:04 | kokozedman | Araq: I understand. I'll tinker around and see what can be done. But still, I believe it's a really good thing if Nim could rise-up to be everyone's favorite language for developing OpenWrt apps. At this point, either you have to code in Lua (darn slow in such a slow CPU environment), or you have to use C/C++ (both of these I'd like to be away from if I can). So far, Nim has proven to be amazingly productive |
| 21:45:05 | kokozedman | and the performance is also great |
| 21:45:14 | dom96 | Araq: What about emitting some C code to do it? |
| 21:45:49 | Araq | dom96: you can't .emit at compile time |
| 21:45:49 | * | Sht0 quit () |
| 21:46:29 | dom96 | ok, this is something we should add then. |
| 21:46:34 | * | Sht0 joined #nimrod |
| 21:46:50 | Araq | kokozedman: we'll do anything to make it work again |
| 21:46:51 | dom96 | But perhaps it's not so easy. |
| 21:47:00 | Mat3 | Araq: because I'm currently compiling with --cs:partial this would mean that my sources compile without changes ? |
| 21:47:22 | Araq | Mat3: yes |
| 21:47:26 | Mat3 | nice :) |
| 21:47:48 | Araq | plus we also have a 'nimfix' tool that is almost there |
| 21:47:50 | * | will joined #nimrod |
| 21:48:24 | Araq | that ports code from Nimrod to Nim automatically |
| 21:49:15 | kokozedman | Araq: it's really nice to hear that. Thank you guys |
| 21:50:21 | dom96 | Something like this but if Nim actually put the echo inside the ifdef https://gist.github.com/dom96/b8e310791b05c053a096 |
| 21:50:26 | Araq | Mat3: the async libs also have been overdone completely, but I think you don't use them :-) |
| 21:50:45 | dom96 | Mat3: Some wrappers and modules have also been moved to babel. |
| 21:50:57 | dom96 | Some wrappers still need to be moved. |
| 21:51:03 | Araq | dom96, kokozedman I think the non-hacky solution is to introduce linux_embedded as a new OS |
| 21:51:19 | Araq | maybe under a better name |
| 21:52:05 | dom96 | Araq: Maybe. But generalising this may be a bad idea. |
| 21:52:44 | Araq | dom96: tried your gist? |
| 21:52:52 | dom96 | Araq: yes |
| 21:53:06 | Araq | it should work when in a proc |
| 21:53:06 | will | couldnt you have something similar to ./configure step that detects c library? |
| 21:53:25 | * | Matthias247_ joined #nimrod |
| 21:53:54 | dom96 | Araq: ahh, just a case of making it work for proc/type defs :P |
| 21:54:25 | Araq | will: we have that too, but it's posix shell based and only works with the OS/CPU target system |
| 21:54:36 | kokozedman | Araq: I agree, but linux_embedded sounds like something a bit different... anyway, it's more about OpenWrt (open source router platforms based on linux & uClibc in general) |
| 21:54:56 | * | JasonJAyalaP joined #nimrod |
| 21:55:01 | dom96 | Perhaps a better temporary solution would be to introduce a new constant called libcName into system.nim |
| 21:55:23 | Araq | sounds to me like --os:OpenWrt |
| 21:55:28 | JasonJAyalaP | blarg. Internet went down. You'd think overpriced 1Mbit down DSL would be more stable |
| 21:55:40 | JasonJAyalaP | Araq: Did you get my "when false: do" message? |
| 21:55:56 | dom96 | Araq: Operating systems can use different libc's |
| 21:56:12 | * | Matthias247 quit (Ping timeout: 258 seconds) |
| 21:56:12 | Araq | JasonJAyalaP: nope |
| 21:56:14 | dom96 | I mean: the same OS can use different ones. |
| 21:56:26 | JasonJAyalaP | Uhm. I think this is wrong... `when false: blahblahblah` works but `when false: blahblahblah do` fails to compile. The "do" is getting parsed. |
| 21:57:25 | dom96 | 'do' is a keyword |
| 21:57:26 | dom96 | http://build.nimrod-lang.org/docs/manual.html#do-notation |
| 21:57:49 | dom96 | (Which i'm not the biggest fan of) |
| 21:58:12 | Araq | dom96: yeah but than we have OS+Libc+CPU+CC combinations |
| 21:59:33 | dom96 | Yes, but that does sound right. |
| 22:00:21 | JasonJAyalaP | dom96: So then "when false" isn't good for broken code... |
| 22:00:22 | Mat3 | well, that's common for C based, embedded development |
| 22:00:40 | Araq | ok fine |
| 22:00:51 | Araq | what's the name of the constant? system.libc? |
| 22:01:22 | dom96 | sure |
| 22:01:39 | kokozedman | what about a more flexible approach? --libc:uClibc or --libc:eglibc or --libc:musl ... OpenWrt is really linux, so I think that doesn't change. One thing is for sure, there is a default OpenWrt configuration that's very very common in most routers: uClibc is always the default libc. If it's different, that's been compiled to be a custom system, and that means the user knows what he's doing. |
| 22:02:30 | Araq | kokozedman: that doesn't gain you much over -d:uClibc |
| 22:02:42 | dom96 | JasonJAyalaP: Yep. That's why you should vote yes for new multi-line comment syntax :) |
| 22:02:43 | Araq | and then 'when defined(uClibc)' |
| 22:02:43 | JasonJAyalaP | dom96: If you use `when false:` you can have meaningless symbols (when false: blarg my blarg := 1000) but you keywords better be properly indented! |
| 22:03:05 | Araq | JasonJAyalaP: commented out *code* is still *code* |
| 22:03:12 | Araq | otherwise use a comment |
| 22:04:17 | kokozedman | Araq: -d:uClibc is fine by me |
| 22:05:03 | Araq | very well then, that doesn't require yet another magic builtin |
| 22:06:33 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 22:07:44 | kokozedman | I'm trying to do: when not defined(uClibc) or not defined(haiku) and not defined(OpenBSD) |
| 22:07:52 | kokozedman | code is still evaluated, what's wrong? |
| 22:12:34 | Mat3 | ciao |
| 22:12:52 | * | Mat3 quit (Quit: Verlassend) |
| 22:13:31 | * | Trustable quit (Remote host closed the connection) |
| 22:13:46 | Araq | kokozedman: 'and' instead of 'or' |
| 22:15:38 | kokozedman | oh sorry about that |
| 22:15:52 | * | wkoch joined #nimrod |
| 22:16:04 | kokozedman | my head ain't right no more, it's really late here... anyway |
| 22:16:09 | kokozedman | there's this: Tfenv* {.importc: "fenv_t", header: "<fenv.h>", final, pure.} |
| 22:16:20 | kokozedman | I don't seem to be able to get around that |
| 22:16:55 | kokozedman | (around line #105) seems to be hard-coded required |
| 22:17:03 | dom96 | can't you put it inside a when not defined(uClibc)? |
| 22:17:41 | Araq | he needs to break up the 'type' sections for that to work |
| 22:17:49 | kokozedman | heheh... let's try that, let's hope it will not break major stuffs |
| 22:24:27 | * | wkoch quit (Quit: Saindo) |
| 22:24:47 | dom96 | Let's implement this for Nim: http://talks.golang.org/2014/playground.slide |
| 22:26:07 | * | askatasuna quit (Ping timeout: 245 seconds) |
| 22:26:33 | kokozedman | ah, finally got it to compile... obviously, asynchronous sockets doesn't work; traditional socket ops works |
| 22:28:51 | dom96 | why not? |
| 22:32:54 | * | lewislevinmbr joined #nimrod |
| 22:34:43 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:34:57 | kokozedman | dom96: correction: IT WORKS, async works on uClibc/OpenWrt... I accidentally disabled the echo that tells me it does... ffphheww |
| 22:35:35 | Araq | hi lewislevinmbr welcome |
| 22:36:01 | lewislevinmbr | is this the primary channel for nim (formerly known as nimrod) |
| 22:36:13 | Araq | yes |
| 22:36:33 | kokozedman | welcome lewislevinmbr |
| 22:36:36 | lewislevinmbr | what’s the best url for scanning through old transcripts |
| 22:36:55 | * | dapz joined #nimrod |
| 22:38:22 | lewislevinmbr | just getting started. finding all the sources. |
| 22:38:35 | lewislevinmbr | anyone interested in a nim wrapper to eigen? |
| 22:38:48 | dom96 | kokozedman: hehe awesome |
| 22:38:58 | Araq | not sure what you mean "scanning through old transcripts" |
| 22:39:17 | dom96 | lewislevinmbr: You mean IRC logs? http://build.nimrod-lang.org/irclogs/ |
| 22:39:31 | Araq | lewislevinmbr: sure thing, eigen is sweet |
| 22:39:32 | lewislevinmbr | araq: seems not everything interesting is in the forum posts. never mind, dom96 answered |
| 22:41:17 | lewislevinmbr | araq: probably beyond my ability but eigen seems like one of the 2 best linear algebra libraries. with a decent nim api to it we’d have much of, not all of, what numpy provides |
| 22:41:32 | kokozedman | is it possible to have a buffer reuse like in the regular recv(..., pointer, ...) in the asyncdispatch? |
| 22:43:08 | lewislevinmbr | off for now. i’ll see what I can learn about eigen and how it could be wrapped to be called from nim code. |
| 22:43:20 | Araq | lewislevinmbr: feel free |
| 22:43:25 | Araq | to post your questions here |
| 22:43:31 | lewislevinmbr | also, I’m glad about the name change |
| 22:43:46 | Araq | 75% support the name change :-) |
| 22:43:47 | kokozedman | I can see a readInto() in asyncnet, but it is not exported |
| 22:44:06 | * | lewislevinmbr left #nimrod (#nimrod) |
| 22:44:06 | kokozedman | Araq: +1 for name change |
| 22:47:15 | * | adrusi joined #nimrod |
| 22:48:25 | kokozedman | Araq: dom96: is it possible to have a buffer reuse like in the regular recv(..., pointer, ...) in the asyncdispatch? |
| 22:49:32 | dom96 | kokozedman: No. |
| 22:49:54 | Araq | dom96: but perhaps it should be? |
| 22:50:06 | kokozedman | it really should |
| 22:51:27 | dom96 | It would be a bit strange. |
| 22:51:49 | kokozedman | why? |
| 22:52:04 | dom96 | Because the future wouldn't hold the value. |
| 22:53:14 | dom96 | You can easily implement it yourself on Linux though. |
| 22:53:54 | kokozedman | I'm not claiming to know how things work, but as a vague idea, user should be able to give a pointer+size to the function that returns the future... and all the user do when the future returns is simply check for error and read his buffer |
| 22:54:18 | * | francisl quit (Ping timeout: 255 seconds) |
| 22:54:43 | kokozedman | can you give me some pointers for me to get started? |
| 22:55:41 | dom96 | Sure, just take a look at the current recv implementation: https://github.com/Araq/Nimrod/blob/bigbreak/lib/pure/asyncdispatch.nim#L948 |
| 22:56:27 | dom96 | addRead adds a callback to the dispatcher which will be called when the fd is ready to be read. |
| 22:57:10 | dom96 | all you need to do is replace readBuffer with your pointer |
| 22:57:22 | dom96 | and return a Future[void] |
| 23:00:37 | Araq | kokozedman: how does that help though? you need to allocate a buffer for every Future that can be pending |
| 23:00:38 | Araq | you'd need to alloc/dealloc these |
| 23:00:56 | Araq | and at this point you can just as well use what async already provides |
| 23:01:20 | Araq | you cannot reuse the buffer easily when your asyncronous |
| 23:01:40 | dom96 | he might be able to in an async proc |
| 23:01:44 | dom96 | no? |
| 23:01:57 | kokozedman | Araq: I'm not using the async's buffer because I can't wait for the buffer to be filled before doing anything; it's a raw socket, message based |
| 23:02:09 | kokozedman | I need the message to be processed as soon as it is received |
| 23:02:17 | Araq | dom96: dunno, it's too late, ask me again tomorrow |
| 23:03:37 | dom96 | kokozedman: recv will give you data as soon as it's received |
| 23:03:47 | dom96 | it will not wait until it gets all the data you requested |
| 23:04:11 | kokozedman | and it's very easy to have like thousdans of messages in 1 sec, having to alloc/dealloc at that rate is going to be slow as hell |
| 23:04:27 | kokozedman | dom96: well, not according to what I have experienced |
| 23:04:46 | kokozedman | I set the read size to 4096, I don't get anything until 4096 is full |
| 23:07:20 | dom96 | kokozedman: Posix recv is doing that then. |
| 23:08:11 | kokozedman | yes, that's right... the async one waits |
| 23:09:28 | Araq | kokozedman: the compiler allocates ~6 million objects in 2 seconds, but ok, this is on decent hardware. and you're right it can be a bottleneck for async code |
| 23:11:08 | kokozedman | Araq: especially in such a tiny device, it is a major bottleneck... 60% CPU usage for just around 10 mbps speed... looking at around 80 mbps tops |
| 23:12:39 | kokozedman | it's really late here, I think I'm also going to have to do. see you guys tomorrow, and thanks for the insights |
| 23:12:49 | * | kokozedman left #nimrod ("WeeChat 0.3.7") |
| 23:13:59 | JasonJAyalaP | Ok. I forked, pulled, branched, initially committed, and pushed.... https://github.com/JasonJAyalaP/learnxinyminutes-docs/blob/nim/nim.html.markdown |
| 23:14:38 | JasonJAyalaP | I'm in need of some small examples of common operations on the data structures, as well as for/iteration |
| 23:14:49 | JasonJAyalaP | (look for TODO) |
| 23:15:47 | JasonJAyalaP | If you just have comments, or want me to copy/paste examples (to save you time), open an issue |
| 23:15:54 | Araq | JasonJAyalaP: steal the examples from somewhere? ;-) |
| 23:16:07 | Araq | rosetta code, tutorials etc. |
| 23:18:15 | JasonJAyalaP | Araq: I tried. nimrod-by-example doesn't have (m)any (!) and the standard library documentation isn't full of them either. I started to flip through source code of 3rd party libs. I'll keep looking. |
| 23:18:55 | JasonJAyalaP | Araq: Ah. I'll look at rosetta |
| 23:19:54 | Araq | well Table, CountTable, seq are common |
| 23:20:11 | Araq | array, set, string |
| 23:20:28 | Araq | that's about it really, I think |
| 23:20:42 | Araq | we have crit bit trees, lists etc etc |
| 23:21:00 | Araq | but there is usually not much love for them |
| 23:21:36 | JasonJAyalaP | Araq: Any reason why table isn't in the core/system/whatever? |
| 23:22:10 | JasonJAyalaP | Araq: Yeah i noticed queues and other abstract data types. It will be fun playing with them. |
| 23:22:18 | Araq | it requires == and 'hash' to work |
| 23:22:45 | Araq | a builtin Table makes no sense for Nim |
| 23:23:21 | Araq | unless you mean we should simply put it into system.nim |
| 23:23:32 | * | darkf joined #nimrod |
| 23:23:36 | Araq | but system.nim is already bloated |
| 23:23:54 | Araq | you can do include prelude to get the standard stuff |
| 23:24:12 | Araq | but that's a well kept secret |
| 23:24:19 | * | Matthias247_ quit (Read error: Connection reset by peer) |
| 23:24:20 | Araq | I wonder if anybody uses it |
| 23:24:21 | dom96 | JasonJAyalaP: You should add an async await example :D |
| 23:24:38 | JasonJAyalaP | Araq: I see. Having to import it makes it look like it's a second class citizen. But I guess that's naive.. Oh. I didn't even know there was a prelude |
| 23:25:08 | JasonJAyalaP | dom96: I was thinking of adding some FFI since that's one of the selling points of nim (at least for me) |
| 23:25:17 | dom96 | sure |
| 23:26:37 | Araq | dom96: where is there both BIO_write and bioWrite? |
| 23:27:13 | dom96 | openssl wrapper? |
| 23:27:19 | Araq | yes |
| 23:30:50 | Araq | meh never mind |
| 23:32:57 | Varriount | JasonJAyalaP: ping |
| 23:33:43 | dom96 | Araq: What's the problem? |
| 23:34:07 | Araq | dom96: that breaks nimfix, but I added a when not defined(nimfix) |
| 23:34:57 | Varriount | Araq: How would one go about creating a tool to auto-format nimrod code, keeping comments? |
| 23:35:32 | JasonJAyalaP | Varriount: pong |
| 23:35:58 | Varriount | JasonJAyalaP: https://github.com/Araq/Nimrod/wiki/NEP-1-:-Style-Guide-for-Nimrod-Code |
| 23:36:42 | Araq | Varriount: you have 2 options: do it like nimfix which is full semcheck->AST ->LineInfo -> go back to file buffer and fix it |
| 23:36:58 | Araq | or you base it on the lexer only |
| 23:37:05 | JasonJAyalaP | Varriount: neat. thanks. |
| 23:37:10 | Araq | with perhaps some heuristics |
| 23:39:38 | JasonJAyalaP | Araq: Varriount: Should enum values have a prefix? |
| 23:40:10 | Araq | or maybe take the parser, give it some heuristical symbol table and use that |
| 23:40:11 | Varriount | JasonJAyalaP: Yes. |
| 23:40:43 | Araq | JasonJAyalaP: you can also use a .pure enum. that requires full qualification |
| 23:40:56 | Araq | these should not have prefixes then |
| 23:45:28 | JasonJAyalaP | do tupples have "fields", "labels" or "members"? |
| 23:45:31 | JasonJAyalaP | tuples |
| 23:46:19 | Araq | "fields" |
| 23:47:25 | * | Joe_knock quit (Quit: Leaving) |
| 23:48:06 | Araq | Varriount: can you please run nimfix over various babel packages? |
| 23:52:19 | dom96 | he must finish kickstart! |
| 23:55:24 | NimBot | Araq/Nimrod bigbreak 45accd6 Araq [+0 ±1 -0]: 'nim i' should work again |
| 23:55:24 | NimBot | Araq/Nimrod bigbreak 03744be Araq [+0 ±2 -0]: updated xml modules |
| 23:55:24 | NimBot | Araq/Nimrod bigbreak e7140f2 Araq [+0 ±8 -0]: updated SDL wrapper |
| 23:55:24 | NimBot | Araq/Nimrod bigbreak 4367fb2 Araq [+0 ±2 -0]: updated graphics.nim |
| 23:55:24 | NimBot | 7 more commits. |
| 23:57:37 | * | Fran__ joined #nimrod |
| 23:57:45 | * | flaviu1 quit (Ping timeout: 255 seconds) |