| 00:01:57 | vbtt | ok. I dont think I get how the hash table example "encourages freedom of both deadlocks and data races" |
| 00:03:11 | vbtt | A C program doing the same thing would look structurally similar and not have deadlocks or races either. Maybe i'll read it again. |
| 00:03:35 | Araq | yes, of course |
| 00:04:34 | Araq | but does the C compiler check you got it right? no it doesnt |
| 00:05:49 | vbtt | well, what if I lock the wrong lock in the array? does nimrod know that bucket[x] maps to locks[y] ? |
| 00:06:06 | Araq | no :P |
| 00:06:42 | vbtt | so it just check that *something* got locked in the related locks? |
| 00:06:48 | gradha | good night, honey badgers |
| 00:06:59 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 00:07:01 | Araq | yeah |
| 00:08:07 | vbtt | A cleaner solution might be to declare it as Array(100) of (Array(10) of bucket, Lock) pairs. |
| 00:08:34 | Araq | that requires 2 index operations though |
| 00:08:44 | vbtt | ..and then somehow optimize that out :) |
| 00:09:30 | vbtt | But from a high level, it makes sense to me. |
| 00:10:31 | vbtt | i.e. my solution makes more sense to me and seems safer from programmer error. |
| 00:10:51 | vbtt | the proposed solution removes some but not all concerns of using locks. |
| 00:11:11 | Araq | no it's not safer, you only need to ensure you can only reach 1 lock (easily) to have the same guarantee |
| 00:11:38 | filwit | bbl |
| 00:12:27 | vbtt | It's safer because I can't lock array[0].lock and then update array[1].data[2]. |
| 00:13:36 | Araq | as if I don't know ... |
| 00:14:54 | Araq | it's very easy to design the data structure as you suggested and get the same safety, but I prefer the greater expressivity |
| 00:16:36 | vbtt | ok |
| 00:24:10 | vbtt | btw, re the forum suggestion of read/write locks, I think they dont belong in the language at the level proposed. |
| 00:25:07 | Araq | yeah but Jehan thinks otherwise and he's a concurrency expert |
| 00:26:06 | Araq | argument by authority sucks though |
| 00:26:06 | vbtt | r/w locks can be implemented using the proposed semantics and specific to each data structure (e.g. copy-on-write) |
| 00:26:41 | vbtt | anyway, if a simple implementation is guaranteed correct (i.e. no dirty reads, even for nested objects) then it may be ok. |
| 00:28:51 | * | gcr joined #nimrod |
| 00:29:56 | Araq | vbtt: I still don't get how r/w locks work on the assembler level |
| 00:31:01 | Araq | you need to "lock" to read and to write anyway, so I don't see where the gain can come from |
| 00:31:16 | vbtt | multiple readers can concurrently read. |
| 00:31:33 | Araq | yeah but there could be a write |
| 00:31:55 | vbtt | write is exclusive and locks out all other reads/writes. |
| 00:32:05 | Araq | and so you need memory barriers anyway |
| 00:32:07 | vbtt | so write has to wait for read locks to release. |
| 00:32:09 | vbtt | yes. |
| 00:32:35 | vbtt | that is why I think r/w locks don't belong in the proposal and must be at a higher level. |
| 00:32:56 | vbtt | e.g. using copy-on-write you can have writes that dont block reads at all. |
| 00:33:21 | vbtt | there are many choices when implementing read/write concurrency. |
| 00:33:42 | Araq | well then answer on the forum |
| 00:33:54 | vbtt | heh ok. |
| 00:45:28 | Araq | hi gcr welcome |
| 00:45:36 | gcr | hey there! |
| 00:48:53 | * | icebattle quit (Quit: Leaving) |
| 00:50:34 | filwit | Araq, is the code for the website online anywhere? |
| 00:50:46 | filwit | koch.nim? |
| 00:51:08 | Araq | web/ and doc/ are on github |
| 00:51:21 | filwit | thanks |
| 00:53:27 | filwit | well crap.. so where's the HTML being added? |
| 00:53:49 | filwit | i would assume it's from some template |
| 00:54:15 | Araq | tools/website.tmpl |
| 00:54:25 | filwit | ah, thanks again |
| 00:54:40 | Araq | tools/nimweb.nim |
| 00:54:46 | filwit | btw, you see the new github analytics? |
| 00:54:53 | filwit | pretty cool as well |
| 00:55:47 | Araq | well it's your html, so yeah :-) |
| 00:55:54 | filwit | how to build the website with koch? $ koch web ? |
| 00:55:58 | filwit | and where's the output? |
| 00:56:29 | Araq | somewhere in web/ |
| 00:56:36 | filwit | k |
| 00:57:08 | filwit | do you have a gmail account? |
| 00:57:30 | Araq | yeah but i lost the pw |
| 00:57:45 | * | Araq keeps losing his passwords |
| 00:58:01 | filwit | would you mind making a new one (for nimrod) so I could setup google analytics on the site? |
| 00:58:23 | filwit | (is that okay with you?) |
| 00:58:45 | Araq | tbh I prefer it when dom96 does these things |
| 00:58:57 | Araq | so use dom96's gmail account :P |
| 00:59:05 | filwit | okay that's fine |
| 00:59:20 | filwit | i was going to need his help anyways with getting the changes pushed to the server |
| 00:59:36 | filwit | i would just like to get it setup, it really is useful information |
| 00:59:57 | filwit | (even if i wont be able to see it, :)) |
| 01:01:55 | dom96 | Sure, i'll do it. |
| 01:02:02 | filwit | great! |
| 01:02:05 | dom96 | Also need to add the twitter account to the website. |
| 01:02:28 | filwit | good idea |
| 01:03:02 | Araq | vbtt: in the forum thread I describe 1 possible solution to share GC'ed heaps, there is at least a 2nd one: for fork&join you can pass the parent's allocator to the workers and then the workers can allocate. the parent has to stop during this time as it generally accesses its heap without any lock. |
| 01:03:50 | Araq | after the "join" the parent thread has control over its heap again and nobody else has access |
| 01:04:43 | zezba9000 | http://www.google.com/analytics/ |
| 01:04:45 | vbtt | Araq: yeah |
| 01:04:57 | Araq | this is quite easy to implement but I'm not sure about the resulting type system |
| 01:05:27 | Araq | basically "ref" turns into "foreign ref" when the ref is passed to the child |
| 01:06:30 | Araq | but this doesn't suffice, actually you need ref parametrization by some region label |
| 01:07:07 | * | io2 quit (Ping timeout: 260 seconds) |
| 01:07:11 | vbtt | Araq:without good use cases, I'm not convinced the complexity is worth it. |
| 01:07:33 | Araq | yeah, exactly my problem |
| 01:07:50 | vbtt | Araq: also multiple threads mucking about in the same heap will cause contention reducing the scaling factor anyway |
| 01:08:12 | vbtt | in other words, what's the use of running multiple threads on multiple cpus if they're contending on the allocator lock? |
| 01:08:34 | Araq | well it's not said they really do contend |
| 01:08:52 | Araq | also you can mitigate the issue, not every allocator needs a single global lock |
| 01:09:07 | vbtt | right, but they might. |
| 01:10:03 | Araq | there are lockfree allocators or you can use some lock stripes |
| 01:11:57 | filwit | dom96: to sign up, just go to that link zezba posted and click the "Access ..." button. You can register a URL, it's all pretty straight forward. Once you do that, you'll need to copy a JS snippet into the Nimrod/tools/website.tmpl (just put it at the end of the <body>). Then it's setup and you can even track in real-time (to the second). |
| 01:12:48 | dom96 | Don't worry, I know how to do it. Like I said I set it up for my blog. |
| 01:13:02 | filwit | oh, right right, i forgot about that. |
| 01:14:15 | vbtt | all i'm saying is, implementing less at this point might be better. |
| 01:14:45 | Araq | and yet you complain about my 80/20 solution :P |
| 01:15:20 | Araq | which aims to get rid of 80% of all concurrency related problems with 20% of implementation effort |
| 01:15:57 | vbtt | heh, except I dont think you're getting rid of the iproblems. |
| 01:16:05 | filwit | why write software if there aren't others around to complain about it? |
| 01:17:36 | Araq | vbtt: yeah you might be right but we'll see |
| 01:17:43 | Araq | I need to sleep now, good night guys |
| 01:17:46 | vbtt | e.g. you need partial order for locks, not total order. |
| 01:17:49 | vbtt | ok, ttyl. |
| 01:18:02 | Araq | wait what |
| 01:18:24 | Araq | total order based on integers is definitely good enough for version 1 |
| 01:21:04 | vbtt | ok i'll think about it. |
| 01:21:51 | Araq | ok, bye |
| 01:29:43 | gcr | goodnight! |
| 01:29:52 | gcr | Hm, what's the purpose of lines 1212-1217 of https://github.com/Araq/Nimrod/blob/838c35ef7a4d9250fd6b0931dc2391b768f580bd/compiler/semstmts.nim#L1212-L1217 ? |
| 01:30:26 | gcr | from what i can tell, that replaces the syntax node with an outer and an inner, but it causes strange destructor behavior when a section of code has multiple 'var' statements |
| 01:30:29 | gcr | consider a failing test case, https://gist.github.com/gcr/8365804 |
| 01:30:43 | gcr | "main_broken()" is split into two 'var' blocks, but only y's destructor is called |
| 01:30:55 | gcr | where main_works() has one var block and the destructor for both variables is called |
| 01:31:39 | gcr | i'm not sure but i wonder if maybe the lines i highlighted are causing the rest of the variable blocks to be ignored by that pass? |
| 01:35:02 | * | DAddYE quit () |
| 01:35:11 | hitesh | any mysql users out there? |
| 01:38:19 | filwit | i know Araq uses MySQL, but he's not here right now |
| 01:39:58 | hitesh | I thought language authors never sleep. :p |
| 02:01:43 | * | gcr quit (Ping timeout: 260 seconds) |
| 02:18:23 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 02:34:24 | * | dmac quit (Quit: Leaving.) |
| 03:20:27 | * | BitPuffin joined #nimrod |
| 03:21:30 | * | BitPuffin quit (Client Quit) |
| 03:42:49 | * | dmac joined #nimrod |
| 03:43:40 | * | cwds420 joined #nimrod |
| 03:44:09 | * | cwds420 quit (Client Quit) |
| 03:49:42 | * | dmac quit (Ping timeout: 265 seconds) |
| 04:22:49 | * | ddl_smurf joined #nimrod |
| 04:47:13 | * | dmac joined #nimrod |
| 04:47:55 | * | vbtt_ joined #nimrod |
| 04:51:49 | * | dmac quit (Ping timeout: 248 seconds) |
| 04:52:30 | * | vbtt_ quit (Client Quit) |
| 05:47:32 | * | dmac joined #nimrod |
| 05:51:56 | * | dmac quit (Ping timeout: 246 seconds) |
| 06:39:27 | * | ehaliewicz joined #nimrod |
| 06:47:52 | * | dmac joined #nimrod |
| 06:52:12 | * | dmac quit (Ping timeout: 245 seconds) |
| 06:57:15 | * | ehaliewicz quit (Remote host closed the connection) |
| 07:24:20 | * | filwit quit (Quit: Leaving) |
| 07:46:51 | * | achim joined #nimrod |
| 07:48:11 | * | dmac joined #nimrod |
| 07:52:37 | * | dmac quit (Ping timeout: 248 seconds) |
| 08:18:19 | * | dmac joined #nimrod |
| 08:18:33 | * | brson quit (Quit: leaving) |
| 08:22:53 | * | dmac quit (Ping timeout: 272 seconds) |
| 08:38:41 | * | zezba9000 left #nimrod (#nimrod) |
| 08:58:47 | * | dmac joined #nimrod |
| 09:02:06 | Araq | hitesh: I've used the mysql wrapper once ... what's the problem? |
| 09:40:29 | * | Boscop joined #nimrod |
| 10:31:27 | * | pe7ed27 joined #nimrod |
| 10:31:36 | Araq | hi pe7ed27 welcome |
| 10:32:59 | * | [Pete_27] quit (Ping timeout: 252 seconds) |
| 10:55:56 | * | io2 joined #nimrod |
| 11:44:40 | * | dmac quit (Quit: Leaving.) |
| 11:47:39 | * | radsoc joined #nimrod |
| 12:16:07 | * | girvo joined #nimrod |
| 12:16:43 | girvo | hey, just to let you know (as I had troubles with it months ago), installing Aporia through babel worked perfectly on Linux Mint 16 |
| 12:23:53 | girvo | quick q: whats the current state of idetools |
| 12:30:37 | Araq | girvo: afaik idetools work quite well if you don't run the compiler in server mode |
| 12:32:35 | girvo | Araq: alright easy. I'm currently trying to write a plugin for Textadept that will take advantage of it, so wanted to check if there were any gotchas |
| 12:33:45 | * | pafmaf quit (Remote host closed the connection) |
| 12:34:23 | * | pafmaf joined #nimrod |
| 12:43:06 | * | girvo quit (Quit: Leaving) |
| 12:43:23 | * | girvo joined #nimrod |
| 12:44:56 | * | girvo quit (Client Quit) |
| 12:45:08 | * | girvo joined #nimrod |
| 12:45:12 | * | dmac joined #nimrod |
| 12:48:05 | girvo | anyone i should add to my rss feed to keep up with nimrod's latest stuff? |
| 12:49:47 | * | dmac quit (Ping timeout: 272 seconds) |
| 12:50:24 | Araq | the forum supports rss |
| 12:50:39 | dom96 | I have a blog at picheta.me, probably won't post very often though. Gradha has a blog at gradha.github.io (IIRC) |
| 12:51:02 | girvo | I was looking for yours dom96 -- i couldn't remember. and cheers Araq I'll link the forum in as well :) |
| 12:51:10 | Araq | I have a blog but it's secret and I have no rss :P |
| 12:52:00 | dom96 | But yeah forum is probably the main thing since we'll be announcing our blog posts there anyway. |
| 12:54:02 | girvo | haha Araq :) okay, ez pz dom96 I'll chuck that in, how busy is it? I might mark it as "noise" so it doesn't fill up so much (puts it in a seperate category in selfoss) if its *very* busy, but if its not too bad I wont bother |
| 12:54:39 | Araq | nothing is *very* busy here for better or worse |
| 12:54:51 | dom96 | Yes, but that will hopefully change. |
| 12:55:05 | girvo | fingers crossed :) |
| 12:55:29 | girvo | i mean, i'm new, and from my vantage point more people are becoming interested (myself included for the past few months) |
| 12:56:33 | girvo | HN is starting to pay attention at least, heh |
| 13:02:50 | Araq | we don't need more attention on HN or reddit really, it's easy to get that, we need money ;-) |
| 13:05:23 | wan | You probably can't get both at the same time. Attention first, money eventually/hopefully follows? |
| 13:21:05 | radsoc | Hi Araq, I have yet another question for you, related to shared hash tables. |
| 13:21:38 | radsoc | I'm still playing with threads and global tables and I get weird results (in my view). I have one big file with 1B key/value pairs: 1M distinct keys and the value is always 1. And I want to aggregate all the values for each key. So, as a result, I should get 1,000 for each of the 1M keys. If I use one thread in my test, that's what I get. But if I use, say, 8 threads, I only get 1,000 for about 55,000 keys, between 984 and 999 (mostly 998) for the other |
| 13:21:38 | radsoc | keys, and I even get about 25,000 duplicates (with values between 1 and 7). In this test, I only implemented one shared countTable, filled by each thread. Do you think this performance is related to lock (but I thought allocShared was using a single global lock)? or (cpu-)cache? or something else? |
| 13:24:54 | * | darkf quit (Quit: Leaving) |
| 13:32:57 | Araq | I am having weird results too here, I need to fire up linux + cachegrind to learn more :-) |
| 13:33:21 | Araq | so sorry, I'm afraid I can't help you |
| 13:33:44 | Araq | perhaps try it with 0mq and multi *processing* |
| 13:38:10 | Araq | er. .. do you mean you get weird performance or do you get wrong results? |
| 13:40:42 | radsoc | wrong results! |
| 13:41:32 | radsoc | even duplicates! |
| 13:41:42 | Araq | well your shared count table is wrong then |
| 13:41:57 | Araq | how did you implement it? |
| 13:42:09 | radsoc | wrong? |
| 13:42:40 | Araq | uh oh |
| 13:42:55 | Araq | you didn't use TCountTable as a global variable, did you? |
| 13:43:41 | radsoc | yes |
| 13:44:01 | radsoc | I used TCountTable as a global variable |
| 13:44:20 | Araq | the compiler should have warned you ... |
| 13:45:41 | * | dmac joined #nimrod |
| 13:46:23 | * | [1]Endy joined #nimrod |
| 13:46:25 | Araq | radsoc: allocShared is safe but TcountTable itself doesn't use allocShared so you can't use it in the way you do |
| 13:50:07 | * | dmac quit (Ping timeout: 245 seconds) |
| 13:51:09 | Araq | you need to use MFLamer's lock free hash table if that works at all now |
| 13:51:31 | Araq | or you can use --gc:boehm |
| 13:51:48 | Araq | or play some games with GC_disable() in every thread |
| 13:52:03 | radsoc | araq: sorry, I forgot to mention I use a slighty different version of table.nim. |
| 13:52:22 | Araq | ah ok |
| 13:53:03 | Araq | well the global heap lock doesn't suffice as a syncronization operation for your count table if that's what you meant |
| 13:53:45 | radsoc | https://gist.github.com/radsoc/d23211d9087ee0c291ec (quick and dirty...) |
| 13:58:14 | Varriount | Anyone know how common 128-bit integers data types are, as far as various OS api's go? |
| 13:59:00 | Araq | Varriount: very uncommon afaict |
| 13:59:53 | Varriount | Mkay. I was wondering if I should reserve space in the type FileInfo type for 128 bit values (eg, for times or size) |
| 14:02:00 | Araq | radsoc: ah I see. well your solution is sweet but you need to protect the whole table with a lock if you don't already |
| 14:03:20 | Araq | you can however do a bit better by not locking the rawget called from "inc" |
| 14:03:58 | Araq | and use atomicInc in line 94 |
| 14:04:26 | * | achim quit (Quit: Computer has gone to sleep.) |
| 14:04:33 | Araq | the copymem in lines 93 and 95 seem unnecessary and wrong for this solution to work |
| 14:04:58 | Araq | I can see why they are useful when you mmap() the input file though |
| 14:05:52 | radsoc | exactly |
| 14:06:18 | radsoc | thanks for the code review! |
| 14:06:42 | Araq | well did I help you? |
| 14:06:52 | * | psquid quit (Quit: work) |
| 14:08:08 | * | achim joined #nimrod |
| 14:08:38 | radsoc | yes |
| 14:11:44 | radsoc | I'll try to use this locks module |
| 14:11:57 | Varriount | Araq: Is it possible to open a handle to a directory using nimrod's system module? |
| 14:12:50 | Araq | Varriount: I don't think so but you can call fileHandle on a TFile iirc |
| 14:17:37 | Araq | damn going through a list of 500 tests to categorize them is more work than I expected |
| 14:18:59 | Varriount | Nimrod has that many tests? |
| 14:21:08 | Araq | nimrod has over 600 tests |
| 14:21:30 | Varriount | Woah :O |
| 14:21:39 | Araq | but projects of this size require 5000 at least |
| 14:21:58 | Varriount | Not counting the built-in module tests (that aren't run by the tester, cough cough) |
| 14:22:07 | Araq | true |
| 14:22:19 | dom96 | Not all of them can be ran though |
| 14:22:23 | Araq | btw this is about to change too |
| 14:22:31 | Varriount | How? |
| 14:22:32 | Araq | with my "testament" tool |
| 14:22:35 | dom96 | especially the network stuff |
| 14:22:39 | Varriount | *gasp* |
| 14:23:29 | Araq | categorizing should help with speed of development, I hope |
| 14:23:45 | Araq | so I can fix a closure bug and only run the closure related tests |
| 14:24:01 | Araq | quicker turnaround is always a win |
| 14:25:36 | dom96 | and then your fix breaks some unrelated test and you never realise :P |
| 14:25:49 | Araq | no, we have nimbuild for that |
| 14:25:53 | dom96 | ahh yes. |
| 14:26:27 | Araq | btw I though the nimbuild crash comes from a bug in the channels implementation |
| 14:27:19 | Araq | but I looked at that again and can't see it |
| 14:28:48 | Araq | the channels are also faster than I thought or maybe this i7 doesn't mind my RTTI stuff anymore |
| 14:30:25 | Araq | modern cpus are strange beasts ... |
| 14:31:32 | girvo | That they are Araq :/ |
| 14:34:36 | Varriount | Do all doslike filesystems/OS's use the concept of 'drives'? |
| 14:35:05 | Araq | Varriount: that's my definition of "dos-like" |
| 14:37:02 | girvo | dos-like, as in CPM-inspired? |
| 14:38:53 | Varriount | And are the default arguments to top level functions akin to globals, in that, if they are modified, they aren't reset every procedure call? (If I add something to a argument with a default string value, will the value be reset by the next call?) |
| 14:39:00 | Araq | girvo: exactly |
| 14:40:00 | Araq | Varriount: default arguments work as they should work, we don't copy python's design mistakes |
| 14:40:11 | Varriount | Ah, good. |
| 14:40:37 | Varriount | That's always been an.. irritation concerning python. |
| 14:42:39 | girvo | python frustrates me. its a really nice language... with these tiny little rough edges that have never been fixed, which annoy me even more than if it had *major* issues. my brain is weird |
| 14:42:57 | EXetoC | I've never even read anywhere that they're like globals |
| 14:43:45 | EXetoC | what a bad feature |
| 14:44:40 | Araq | Varriount: I think it's a bug in the implementation that they documented |
| 14:45:29 | Varriount | Araq: More like a quirk in the implemention, since there's no intention to fix it. |
| 14:45:50 | Araq | well now it's part of python's spec of course |
| 14:45:56 | * | dmac joined #nimrod |
| 14:46:06 | Araq | but I bet it started as a bug |
| 14:46:32 | Varriount | It has to do with the fact that the values for default functions in python are stored in the function object somewhere, and aren't copied. |
| 14:47:45 | Varriount | Wooh, 21 pull requests! |
| 14:50:10 | Araq | girvo: I don't get why they didn't change the default args issue in python 3 |
| 14:50:38 | girvo | Araq: I truly don't get why they didn't fix a *lot* of things in python 3, considering they broke backwards compat. sigh |
| 14:51:00 | girvo | Araq: IIRC, there was talk on the ML of fixing default args, but it never went through :/ |
| 14:51:07 | * | dmac quit (Ping timeout: 272 seconds) |
| 14:51:16 | Araq | I ported koch.py from python 2 to 3 |
| 14:51:29 | Araq | didn't work, so I rewrote it in nimrod |
| 14:51:42 | Varriount | girvo: Have you seen python-ideas mailing list? Trying to actually *change* anything is nearly impossible, which is both good and bad. |
| 14:52:17 | girvo | Varriount: Yep. It's about as painful as php's core ML, which i particpate on... or used to, anyway, until it drove me up the wall one too many times |
| 14:52:58 | Varriount | Which is funny when you get these really long discussions about a possible new feature that, in the end, amounts to "we won't do anything about this" |
| 14:53:14 | Araq | hey I plan to have these too :P |
| 14:53:37 | Araq | keeps people busy and results in no work for me :P |
| 14:53:39 | Varriount | Araq: Well duh, they are a defining characteristic of a successful language. |
| 14:53:50 | Araq | yep |
| 14:54:07 | Varriount | Or rather, a large, successful language (currently nimrod is a small successful language) |
| 14:56:12 | girvo | quick q: is nake used much? I'm a fan of task-systems in the host language |
| 14:56:33 | girvo | but then, nimrod's compiler flags are already awesome, so it seems somewhat.. unneeded? |
| 14:58:46 | girvo | oh, and *really* dumb question because it's 1am here, my brain has shut down: are compiled binaries statically linked? just curious about the best way of deploying a nimrod app |
| 14:59:08 | Araq | yes, you can also link against nimrtl.dll though |
| 14:59:27 | Araq | but I don't think anybody does that for production |
| 14:59:35 | EXetoC | I don't know how versatile the config system is, and the help output doesn't say anything about selecting a config |
| 15:00:00 | Araq | EXetoC: the config system is quite well documented in nimrodc.html |
| 15:00:08 | Varriount | Araq: Isn't nimrtl.dll linking broken, iirc? |
| 15:00:10 | girvo | Araq: sweet, cheers |
| 15:00:12 | dom96 | girvo: I use nake for my little nimkernel |
| 15:00:21 | girvo | dom96: thats where I came across it :) |
| 15:00:25 | Araq | and imo nake is only necessary for cross language projects |
| 15:00:49 | Varriount | A large part of nimrod's metaprogramming mechanisms negate the need for build systems |
| 15:00:57 | Araq | Varriount: I think it still works for -d:release |
| 15:02:12 | Varriount | girvo: This is the part where you are suppose to shout "Hurrah, the beast that is autoconf need not be used!" |
| 15:03:35 | girvo | Varriount: autoconf... *throws salt over shoulder* *knocks on wood* |
| 15:03:48 | girvo | Varriount: don't mention that word around me :| *shudder |
| 15:07:21 | EXetoC | I don't see a way to override the project config for example, but conditionals are indeed supported, and incremental compilation is built in so writing helper scripts should be trivial |
| 15:10:20 | * | eigenlicht quit (Ping timeout: 260 seconds) |
| 15:11:59 | Varriount | Araq: Just submitted a pull request for the devel branch |
| 15:12:11 | Araq | what is it about? |
| 15:15:16 | Varriount | Araq: Adding symlink procedures to os.nim, and fixing unixToNativePath in regards to default drives for absolute path conversions. |
| 15:16:28 | EXetoC | The only tricky part was putting all the test executables in a single dir, because of how the compiler deals with paths |
| 15:16:50 | EXetoC | but weren't some path changes/extensions pushed not long ago? I can't remember the exact details, so I don't know if it's of any relevance |
| 15:16:56 | Araq | bbl |
| 15:17:20 | Varriount | EXetoC: Nope |
| 15:18:12 | EXetoC | either way, a set of re-usable functions should make this trivial |
| 15:18:18 | EXetoC | ok |
| 15:23:38 | EXetoC | dom96: Have you gotten any file descriptor error outputs with Jester? specifically when polling continually, rather than calling the blocking 'run' function |
| 15:24:12 | dom96 | Possibly. What kind of errors? |
| 15:24:32 | EXetoC | I can give you the exact message the next time it happens. Maybe it's specific to asyncio or something. Nothing major though, as it's just a matter of reloading the page |
| 15:25:04 | EXetoC | something about a non-existent file descriptor I think. I'll see if I can trigger it |
| 15:25:44 | dom96 | If you reload the page really quickly then the fd will be closed, maybe that's why? |
| 15:27:12 | OrionPK | are we getting rid of the P/T prefixes on types? |
| 15:27:24 | OrionPK | cant remember what the consensus was on that.. |
| 15:27:33 | EXetoC | OrionPK: yeah pretty sure :/ |
| 15:27:46 | dom96 | IIRC just the T prefixes for now |
| 15:27:54 | OrionPK | mmk |
| 15:29:58 | Araq | no both T/P will go |
| 15:30:28 | Araq | also I plan to turn EIO into IoError and get rid of the F for effects |
| 15:35:10 | girvo | Oh cool, I'm a fan of that change |
| 15:35:15 | OrionPK | why is initTable new newTable |
| 15:35:22 | OrionPK | not* |
| 15:35:24 | * | [2]Endy joined #nimrod |
| 15:35:38 | Araq | init -> value type, new -> ref type |
| 15:35:50 | Araq | and yes, I know we have newSeq and newString |
| 15:36:00 | Araq | these predate the convention |
| 15:36:11 | OrionPK | ahh |
| 15:39:18 | * | [1]Endy quit (Ping timeout: 276 seconds) |
| 15:40:25 | dom96 | Araq: Really? I prefer the version with the prefix. |
| 15:42:17 | EXetoC | yeah but he has said before that many people are against that convention |
| 15:43:28 | dom96 | True. I've gotten used to it heh |
| 15:43:29 | EXetoC | and it's going to be confusing to have "Foo" be the name of the "primary" type (value, ref, ptr) |
| 15:43:51 | EXetoC | or maybe I've misunderstood that part. anyway, it's not the end of the world |
| 15:44:00 | Araq | EXetoC: depends on the type though, TSocket already is a 'ref' |
| 15:44:15 | Araq | because it changed from object to ref object and we didn't want to break code |
| 15:44:42 | Araq | also |
| 15:44:52 | Araq | people don't adhere to the convention at all afaict |
| 15:45:07 | dom96 | I suppose not being able to tell (by the name) whether a type is a ref/ptr/value isn't the end of the world. |
| 15:45:53 | Araq | I plan to support (ref Foo)(a: 2, b: 3) for better support of writing "ref Type" everywhere |
| 15:46:06 | Araq | though I personally won't use it |
| 15:46:18 | * | dmac joined #nimrod |
| 15:51:00 | * | dmac quit (Ping timeout: 260 seconds) |
| 15:53:46 | Varriount | Sometimes I think "Nimrod's standard library should have some coding conventions" |
| 15:54:04 | Varriount | And then I remember that all of us are too stubborn to stick to a convention |
| 15:54:13 | Araq | er what? |
| 15:54:27 | Varriount | Or maybe I'm just too detail oriented. |
| 15:54:29 | EXetoC | Araq: you'd use FooRef? |
| 15:54:32 | Araq | we have lots of conventions |
| 15:55:06 | Araq | Varriount: http://nimrod-lang.org/apis.html |
| 15:55:17 | Varriount | Araq: That's naming conventions |
| 15:55:31 | Varriount | Araq: What about conventions for usage of references? |
| 15:55:42 | * | Varriount points to asycio.nim |
| 15:55:59 | Araq | ha alright |
| 15:56:21 | Araq | well actually we prefer objects over 'ref' unless it becomes too painful |
| 15:56:33 | Araq | or 'ref' really is necessary like for PRope |
| 15:56:50 | Varriount | When *is* ref necessary? |
| 15:57:27 | EXetoC | when copying doesn't makes sense or should be done sparingly? |
| 15:58:31 | Varriount | But doesn't the compiler figure that out? |
| 15:59:36 | EXetoC | are you thinking of parameters that might or might not be passed by value when 'var' isn't present? |
| 15:59:49 | EXetoC | which is not the same thing, but that's all I could think of |
| 16:00:17 | EXetoC | well, it is related to the performance aspects of copying |
| 16:02:48 | * | dom96 recalls Araq telling him to just use ref everywhere :P |
| 16:02:49 | girvo | Oh crap. I just found the lua package in the nimrod-code github. That makes life a lot easier, interesting. |
| 16:02:56 | EXetoC | 'ref' means reference to a garbage-collected object in case you forgot |
| 16:03:42 | Varriount | EXetoC: Yes, I know that. |
| 16:03:47 | EXetoC | ok |
| 16:04:35 | Araq | dom96: that's because you create disgusting stuff with inheritance |
| 16:04:48 | EXetoC | :p |
| 16:04:53 | Araq | though admittedly we didn't even have closures when you started :P |
| 16:05:01 | girvo | lol |
| 16:05:38 | * | Varriount wishes for inner-generic closures |
| 16:05:54 | Varriount | Unles that got fixed in devel :/ |
| 16:07:09 | Varriount | *inner-generic iterators |
| 16:08:04 | dom96 | Araq: I'm not the only one. |
| 16:08:45 | * | dom96 points at streams |
| 16:11:32 | girvo | :O and there's an SDL2 wrapper? Man I'm glad I decided to look at the packages.json, heh |
| 16:11:51 | Araq | girvo: we have wrappers for everything I think |
| 16:12:00 | girvo | Araq: It certainly seems like it! |
| 16:12:10 | girvo | Araq: I suppose thats the benefit of compile-to-C :) |
| 16:12:23 | girvo | Araq: and having a language that doesn't hide from it |
| 16:12:30 | Varriount | girvo: We also have a binding generator, which helps |
| 16:12:34 | girvo | I'm looking at you, Vala :| |
| 16:12:40 | Araq | actually it has little to do with it |
| 16:12:48 | Araq | it has more to do with pas2nim and c2nim |
| 16:12:53 | girvo | Araq: neat |
| 16:13:34 | Varriount | c2nim is probably part of the reason why the person that introduced windows.nim and winlean.nim didn't go mad. |
| 16:13:38 | girvo | Vala's "generator" needs hand-holding, and things to be written for it to work. It frustrates, as I really like the language, but got fed up with a lack of libs and no time to port everything myself |
| 16:14:09 | Araq | girvo: discoloda ported quake 2 with c2nim |
| 16:14:45 | Araq | pretty cool, huh? but I don't think it's finished yet |
| 16:15:00 | girvo | Araq: Christ. Well, that settles it, I'm definitely going to move my current game project to Nimrod instead of C++ |
| 16:15:17 | girvo | Well.. it was more C, with basic C++ classes. Heh |
| 16:15:28 | EXetoC | I realized that c2nim could deal with quite a few expressions as well. pretty neat |
| 16:16:28 | girvo | I know gtk2 works quite well so far, gtk3 i'm guessing is a bit harder to port? |
| 16:16:50 | Araq | there is a fluent transition from gtk2 to gtk3, I think? |
| 16:16:52 | EXetoC | or maybe even most expressions. I couldn't say for certain, because freetype is riddled with macros |
| 16:17:10 | Araq | EXetoC: pretty much *all* expressions and statments |
| 16:17:30 | dom96 | gtk3 is not /that/ different from gtk2 |
| 16:17:33 | dom96 | AFAIK |
| 16:18:03 | girvo | dom96: yeah, its not that different from an API standpoint, (at least as a consumer of said API) |
| 16:18:05 | dom96 | No one yet bothered to create a wrapper though. And I don't see the point since i'm not the biggest fan of gtk3 |
| 16:18:09 | girvo | dom96: I'm unsure about the internals |
| 16:20:32 | girvo | dom96: I don't mind it myself, performance is quite good IMO, and I prefer some of the API, but yeah its not so different. I only ask because of elementary-os -- they use a neat fork, but its implemented in vala so i dont know how id go interfacing with it |
| 16:20:35 | EXetoC | Araq: woohoo |
| 16:22:02 | Araq | EXetoC: I keep telling you guys c2nim is vastly underrated :P |
| 16:23:01 | girvo | haha |
| 16:23:08 | EXetoC | :/ |
| 16:23:53 | dom96 | Araq: It would be cool if you could expose c2nim's C parser as a babel package. |
| 16:25:53 | Varriount | This is interesting - the Windows api CreateFile procedure allows the use of a template file when a new file must be created. |
| 16:26:32 | Araq | dom96: hmm, it depends on the compiler though |
| 16:26:41 | Araq | however we can split the compiler into parts |
| 16:26:52 | Araq | only few things are necessary for c2nim |
| 16:27:05 | Araq | the ast and the renderer basically |
| 16:27:09 | dom96 | Exposing the Nimrod parser would be nice too. |
| 16:27:28 | EXetoC | I'd write about it, but I have to focus on this website for now, and hopefully get some monies in the process. It's so boring, apart from using Nimrod to assemble everything |
| 16:30:19 | Araq | most interesting is actually that c++ is not significantly harder to parse than C |
| 16:30:54 | Araq | at least when you take the "heuristics everywhere" route that c2nim needs to take |
| 16:36:31 | Varriount | Is there any way to do an infix 'or' operation? (Like +=, -=, etc) |
| 16:38:40 | * | [2]Endy quit (Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet) |
| 16:41:06 | EXetoC | "proc `or`*(x, y: bool): bool {.magic: "Or", noSideEffect.}" my guess would be no because of the magic. how about a converter? |
| 16:41:32 | Varriount | Eh, not important enough for a converter |
| 16:41:33 | EXetoC | if it's not too confusing |
| 16:42:00 | dom96 | A converter? Isn't this a job for a template? |
| 16:42:44 | dom96 | or even an inline proc |
| 16:43:16 | EXetoC | why? I suppose you could support only `or`, and not the other operators, but why? |
| 16:44:02 | dom96 | what other operators? +=, -= already exists. |
| 16:44:20 | Araq | just overload `or` |
| 16:46:29 | * | dmac joined #nimrod |
| 16:46:37 | EXetoC | ok so it works |
| 16:46:51 | Varriount | Again, if it isn't built in, my use case is not important enough to implement it. |
| 16:47:13 | Varriount | It's just OR'ing two flags together for an os api call |
| 16:48:28 | EXetoC | built in how? does it matter? |
| 16:48:56 | * | BitPuffin joined #nimrod |
| 16:49:05 | Varriount | EXetoC: In the procedure I'm writing, there's an argument which specifies whether to follow symlinks or not. |
| 16:49:31 | Varriount | var flags = NORMAL_FILE |
| 16:49:38 | Varriount | if followSymlinks: |
| 16:49:49 | dom96 | Varriount: Do you want a ``|=`` operator? |
| 16:49:54 | Varriount | flags = flags OR FILE_FLAG_OPEN_REPARSE_POINT |
| 16:50:11 | Varriount | dom96: Want, yes. Need, no. |
| 16:50:20 | Varriount | It's only two lines. |
| 16:50:37 | dom96 | Yeah, so I understood you correctly. Still don't understand how a converter helps though. |
| 16:51:27 | * | dmac quit (Ping timeout: 276 seconds) |
| 16:51:49 | Araq | bbl |
| 16:52:38 | girvo | i'm gonna go to sleep, its 3am here lol |
| 16:52:46 | dom96 | girvo: good night! |
| 16:52:51 | Araq | good night |
| 16:52:54 | EXetoC | yes but I don't know what you mean by built in. there's the "Or" magic, but that's just an implementation detail |
| 16:53:20 | Varriount | By built in, I mean, available in the standard library |
| 16:53:20 | dom96 | He means it's not in system.nim |
| 16:53:27 | girvo | catch ya tomorrow, i'm going to go play in nimrods internals tomorrow i think |
| 16:53:29 | girvo | <3 |
| 16:53:42 | * | girvo quit (Quit: Leaving) |
| 16:54:05 | EXetoC | well if you want to overload it yourself |
| 16:54:50 | EXetoC | hm |
| 16:55:02 | dom96 | An `or` for ints already exists. |
| 16:55:07 | EXetoC | "proc `or` *(x, y: int): int {.magic: "BitorI", noSideEffect.}" |
| 16:55:22 | dom96 | So what's all this talk about overloading for? |
| 16:55:22 | EXetoC | yeah, I thought he was referring to user-defined objects |
| 16:55:36 | EXetoC | I don't know. I didn't have all the details |
| 16:56:12 | Varriount | EXetoC, dom96: https://gist.github.com/Varriount/8373418 |
| 16:56:24 | Varriount | Lines 5, 6, and 7 |
| 16:57:25 | dom96 | var openFlags = FILE_ATTRIBUTE_NORMAL or (if followSymlinks: FILE_FLAG_OPEN_REPARSE_POINT else: 0) ? |
| 16:57:47 | dom96 | is that what you want? |
| 16:57:58 | Varriount | essentially |
| 16:58:16 | Varriount | But I prefer readability. |
| 16:58:30 | dom96 | then keep it as it is. |
| 16:58:48 | EXetoC | what are they? enumerators? constants? |
| 16:58:53 | Varriount | EXetoC: Flags |
| 16:59:32 | EXetoC | plain integers? |
| 17:00:00 | dom96 | or add: proc `|=`*[T](x: var T, y: T) {.inline, nosideeffects.} = x = x or y |
| 17:00:02 | dom96 | to the stdlib |
| 17:00:29 | EXetoC | it should work then. if they're enumerators, then just stick ".int" onto the end whenever the integral value is needed. |
| 17:01:17 | dom96 | Wait, it doesn't work? |
| 17:01:32 | EXetoC | so `or` and `|=`? I don't know about that |
| 17:02:28 | dom96 | I can understand that writing openFlags = openFlags or BlahBlah can get annoying if you've gotta write 5 lines like that. |
| 17:02:34 | dom96 | But otherwise there is nothing to complain about. |
| 17:04:22 | Varriount | dom96: You on the VNUG? |
| 17:04:27 | EXetoC | 5 lines? sounds like a pain in the butt :p |
| 17:04:28 | dom96 | no |
| 17:04:50 | Varriount | EXetoC: os.nim isn't the place to add such operators. |
| 17:05:25 | Varriount | And, as I said, since I'm only writing that line once, I don't need to add the operator in the first place. |
| 17:09:39 | EXetoC | right |
| 17:11:25 | EXetoC | I was a little confused by your used of the term infix, but then again you mentioned += in the same sentence :p |
| 17:12:29 | * | eigenlicht joined #nimrod |
| 17:12:56 | dom96 | argh, why does Windows have to make everything complicated. Epoll is so much simpler. |
| 17:13:16 | Varriount | dom96: Working on iocp implementation for selectors? |
| 17:13:20 | dom96 | yes |
| 17:13:32 | dom96 | It won't be in selectors it'll be in a separate module |
| 17:13:42 | dom96 | iocp is different enough to warrant that |
| 17:13:44 | Varriount | dom96: Lemme give you a link to a blog post of iocp |
| 17:13:52 | dom96 | I'm still thinking about it though. |
| 17:14:03 | OrionPK | is there going to be an abstracted 'best choice' "selector" |
| 17:14:13 | dom96 | However Python does it this way too. |
| 17:14:38 | dom96 | They have selectors and a 'proactor' module. Then the proactor wraps epoll/select/poll too. |
| 17:14:53 | dom96 | And you get to choose between two different event loops |
| 17:15:13 | dom96 | OrionPK: Hopefully yes. |
| 17:15:58 | OrionPK | we need a nimrod solution to the C10K problem |
| 17:16:02 | Varriount | dom96: Here's one - http://tinyclouds.org/iocp-links.html |
| 17:16:22 | Varriount | I have another that's more helpful, It's buried in my history somewhere |
| 17:16:27 | dom96 | Varriount: thanks |
| 17:17:11 | Varriount | dom96: I did some research on iocp, when/if I get around to writing a windows implementation for fsmonitor |
| 17:17:51 | dom96 | It seems that with iocp I will need to implement all functions which support it explicitly. |
| 17:18:00 | dom96 | in the module which implements iocp |
| 17:18:05 | Varriount | dom96: Howso? |
| 17:18:19 | dom96 | I like epoll's abstraction with read/write events. |
| 17:18:52 | dom96 | Because with iocp you request something (recv/readfile) and get a completion callback when it finishes. |
| 17:20:42 | dom96 | on the other hand, epoll will tell you when you can read or write from an fd and then you know that you can perform some operation on that fd. |
| 17:20:55 | dom96 | It's more generic that way. |
| 17:21:00 | Varriount | dom96: Here. I know that the post is focused on file montitoring, but it might give you some help |
| 17:21:01 | Varriount | http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html |
| 17:21:59 | dom96 | Although the current async sockets work on callbacks anyway, so perhaps I will just keep it that way |
| 17:22:05 | dom96 | then build futures on top |
| 17:22:22 | Varriount | dom96: Just so you know, at any time, a thread may have only one io completion port at a time |
| 17:22:38 | Varriount | however that completion port may have multiple handles associated with it. |
| 17:22:56 | Varriount | And multiple threads may share a single completion port (i think) |
| 17:23:06 | dom96 | oh yeah, threading is another thing ... |
| 17:23:13 | dom96 | Too many variables to consider. |
| 17:23:18 | Varriount | Wait a sec |
| 17:23:47 | Varriount | What python's twisted library does is simply create one completion port, and associate multiple ports/handles with it. |
| 17:23:49 | dom96 | I may just think about threading after the first implementation is done though |
| 17:23:54 | dom96 | I want to get a feel for this. |
| 17:24:22 | Varriount | dom96: All I ask is that you be careful with the api design, and allow for expansion and changes |
| 17:25:07 | dom96 | It's very unlikely that this will be perfect. |
| 17:25:41 | Varriount | Nothing ever is. But you should always consider the fact that such things will not be perfect, and allow room for improvement. |
| 17:25:53 | dom96 | Of course. |
| 17:26:20 | Varriount | (Which, on an unrelated topic, is why I hate the 'final' keyword in java) |
| 17:27:27 | dom96 | oh and someone with bsd or a mac needs to write a kqueue implementation ;) |
| 17:27:42 | dom96 | but there is plenty of time for that |
| 17:27:48 | Varriount | On the subject of iocp, the goal that they are meant to solve is polling for reads/writes from multiple threads. |
| 17:28:39 | Varriount | Since the OS manages when the threads run, you don't get the huge context switching fight over data input. |
| 17:32:40 | dom96 | I think I have a basic idea of how it works now. |
| 17:33:08 | dom96 | You perform some action, ask for a function to be called when that action completes and that's it. |
| 17:33:19 | dom96 | Seems pretty easy actually. |
| 17:34:12 | dom96 | I don't think there is much point in making it extensible since the number of possible actions is rather small |
| 17:36:39 | Varriount | dom96: You do know that nearly anything handle-like in windows can be used with iocp, right? |
| 17:38:05 | dom96 | Varriount: So is the list of functions on http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%29.aspx not compehensive? |
| 17:38:26 | dom96 | *comprehensive |
| 17:39:39 | dom96 | The first comment on that page sounds like a load of fun... |
| 17:40:05 | dom96 | Don't tell me I will have to synchronize everything myself. |
| 17:40:18 | Varriount | It is comprehensive, to the best of my knowledge, it's just that there are many combinations of parameters and procedures that can be used to with iocp |
| 17:40:26 | Varriount | bbl, have to shower and eat |
| 17:41:31 | dom96 | I think exposing the iocp object will be enough to support any low level operations that you would need to make. |
| 17:46:52 | * | dmac joined #nimrod |
| 17:47:06 | OrionPK | we need a nimrod solution to the C10K problem |
| 17:47:08 | OrionPK | oops |
| 17:47:11 | OrionPK | wrong window |
| 17:50:57 | * | gradha joined #nimrod |
| 17:51:20 | * | dmac quit (Ping timeout: 252 seconds) |
| 17:59:34 | dom96 | bbl |
| 18:12:45 | * | ddl_smurf quit (Read error: Connection reset by peer) |
| 18:13:21 | Varriount | OrionPK: Your mispost actually brings up a point that my mind has been lurking on |
| 18:13:49 | gradha | world domination? |
| 18:13:49 | OrionPK | i said it earlier here, but the 2nd time I said it was an accident ;p |
| 18:14:00 | Varriount | I know of at least one filesystem which uses 128 bit data types for file metadata |
| 18:14:04 | OrionPK | I alt+tabbed to familiar instead of my console and hit up-arrow + enter |
| 18:14:32 | * | ddl_smurf joined #nimrod |
| 18:15:00 | Varriount | I hope that nimrod's standard library is sufficiently future proof |
| 18:19:57 | Araq | Varriount: of course it is. OSes stopped evolving a long time ago. now everybody loves unix and can't imagine something better |
| 18:20:43 | Varriount | Araq: XD |
| 18:22:35 | Varriount | Araq: I've been meaning to ask, how has the threading stuff been going? |
| 18:25:30 | Araq | I have a cool prototype for "spawn". that's it. |
| 18:31:50 | discoloda | does Nimrod use os threads or does it use it's own thread/coroutine |
| 18:32:12 | Varriount | discoloda: For now, os threads. |
| 18:32:22 | Varriount | Though I think Araq has.. *plans* |
| 18:32:45 | discoloda | heh |
| 18:35:34 | discoloda | i think await would be awesome to have. http://channel9.msdn.com/Events/GoingNative/2013/Bringing-await-to-Cpp |
| 18:35:50 | gradha | discoloda: I think dom96 was working on that |
| 18:36:44 | * | dmac joined #nimrod |
| 18:48:21 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 18:49:33 | OrionPK | it wasn't dom, it was someone else iirc |
| 18:49:52 | OrionPK | zahary maybe |
| 18:50:16 | gradha | in any case, it doesn't exist yet |
| 18:53:50 | dom96 | it was me |
| 19:02:03 | OrionPK | oh ok, sorry |
| 19:08:31 | * | Demos joined #nimrod |
| 19:15:44 | Varriount | Anyone know if there's a way to run 'nimrod check' using standard input as the input file, instead of a system file? |
| 19:16:48 | gradha | sounds unlikely, how would you deal with include and path related stuff? |
| 19:17:01 | Araq | I don't think so use a temporary file instead |
| 19:23:38 | Varriount | Araq: but a temp file will break any non-standard library imports |
| 19:25:49 | Araq | as opposed to stdin which does not even have a path? |
| 19:25:56 | gradha | maybe you can -path:dir_where_file_was_meant_to_be? or create the temp file in the same dir, like check_foo.nim |
| 19:27:41 | Varriount | Araq: Well, I was hoping that maybe I could something like "nimrod check --input=stdin <file>" |
| 19:28:19 | Varriount | I'm trying to write a nimrod code-checking plugin |
| 19:28:36 | Araq | I know |
| 19:31:58 | Varriount | What's the oppisite of --excludePath? |
| 19:32:02 | Varriount | *opposite |
| 19:32:16 | gradha | just path? |
| 19:32:38 | gradha | -p, --path:PATH add path to search paths |
| 19:33:28 | Varriount | Ah, thanks. I didn't see it because I was inputting --advanced. |
| 19:41:58 | * | shodan45 joined #nimrod |
| 19:48:05 | fowl | waft Error: internal error: getTypeDescAux(tyEmpty) |
| 19:48:33 | Araq | you used "void" incorrectly, perhaps |
| 20:18:35 | * | faassen left #nimrod (#nimrod) |
| 20:44:08 | Varriount | OrionPK: ping |
| 20:44:40 | OrionPK | what's up |
| 20:45:13 | Varriount | I'm about halfway done with 'nimrod check' integration with sublime text |
| 20:45:43 | OrionPK | sweet |
| 20:48:54 | * | tdc joined #nimrod |
| 20:49:16 | OrionPK | hows it work then? you going to map it to hotkeys? |
| 20:49:27 | Varriount | Yes. |
| 20:49:56 | Varriount | Saves the file, runs 'nimrod check' as a subprocess, parses the output, and displays it to the user. |
| 20:52:36 | OrionPK | pretty quick? |
| 20:53:05 | gradha | Araq: you can get your paper now from http://gradha.github.io/articles/2014/01/small-big-mistakes.html, still hot from the oven |
| 20:53:48 | Varriount | OrionPK: Pretty quick as in execution time, or time to code? |
| 20:54:29 | OrionPK | execution |
| 20:54:39 | Varriount | OrionPK: It should be. |
| 20:55:05 | Varriount | OrionPK: It shouldn't block, in any case - I have a looping callback set mechanism |
| 20:57:07 | OrionPK | cool |
| 21:00:03 | Araq | gradha: wtf man |
| 21:00:04 | * | tdc quit (Quit: Leaving) |
| 21:00:26 | Araq | I take it under "constructive criticism" but seriously |
| 21:03:42 | gradha | hopefully it is constructive, there are holes in the way the nimrod project operates, and I suggest a possible solution |
| 21:03:59 | gradha | but stuff like this is too complicate to write on irc |
| 21:06:32 | dom96 | gradha: I like the PDF, very professional. |
| 21:07:00 | Varriount | What pdf? |
| 21:07:07 | gradha | dom96: thanks, it's a pain to do though, crappy python software and all |
| 21:08:26 | gradha | Varriount: the one from http://gradha.github.io/articles/2014/01/small-big-mistakes.html |
| 21:10:03 | dom96 | gradha: Not too fond of the blog post though. |
| 21:10:38 | dom96 | I feel bad for Araq's sake, since you mention him by name and only him. |
| 21:11:12 | dom96 | There is no need for that when criticising constructively. |
| 21:12:04 | Varriount | gradha: Very well written, very constructive. I like it. |
| 21:12:14 | gradha | I can change it if you find anything wrong, maybe it's you dom96 who uploads the web? |
| 21:13:03 | gradha | Varriount: hah, maybe that's because you haven't read the references yet |
| 21:13:41 | Varriount | gradha: While that may be true, the writing in and of itself is well-formed. |
| 21:15:20 | Varriount | Who *does* have control of the website? It would be a trivial task to add the master branch github link to the downloads page (as well as the most recent build from the builders) |
| 21:15:42 | Araq | I have control and so does dom96 |
| 21:21:42 | gradha | ok, I'll remove Araq's reference then and put something like "manual care is needed" |
| 21:27:05 | Araq | gradha: alright so here is the thing: I have a "devel" branch I'm working on, but it's not up to date |
| 21:27:19 | Araq | well I can pull and merge, no problem |
| 21:27:58 | Araq | but I also have a new shiney tester and even better all the tests are now in proper categories which should help testing a lot |
| 21:28:30 | Araq | is that a new branch according to the methology you suggest? |
| 21:28:44 | dom96 | gradha: I like the rant about babel, but why didn't you just fix that issue before I released 0.2? |
| 21:28:57 | dom96 | or tell me just how much you dislike that behaviour? |
| 21:30:59 | gradha | Araq: I like the one branch per feature convention, but that doesn't mean its right |
| 21:31:25 | gradha | Araq: I would have the testers in a separate branch and work on that, the other stuff in other branches as well |
| 21:31:40 | gradha | Araq: if those branches are interdependent, you can merge between them, as you are likely doing now |
| 21:32:10 | gradha | Araq: but it sounds they are separate, so if you have them in the same branch, both are kind of holding themselves hostages |
| 21:32:29 | gradha | dom96: you mean the #head thingy? |
| 21:33:09 | Araq | gradha: we have 21 pull requests all against master ... not "devel" |
| 21:33:32 | gradha | Araq: precisely because there is nowhere written what against new features should be worked on, there is no convention |
| 21:34:17 | gradha | Araq: I did ask you if the branch "devel" was started from git-flow and you said no, so I presumed you just happened to use that name |
| 21:34:43 | Araq | yes indeed |
| 21:34:57 | gradha | Araq: more than asking about devel, is master stable? is master ready for a release? If not, devel and master are just "feature" branches in my view |
| 21:35:41 | Araq | nothing is ready I'm overwhelmed with work in case you didn't notice |
| 21:36:04 | gradha | Araq: I know |
| 21:36:18 | gradha | Araq: if stuff is not ready by monday hordes of people will chant "Araq is a liar" |
| 21:37:03 | gradha | Araq: this has happened to me many times at work, direction tells to put more and more features, then release day is near and there is no stable stuff, because features kept being aded |
| 21:38:12 | gradha | and from there comes the "I won't sleep until the software is released", heard circa one month ago. You are keeping your sanity pretty well without that much sleep. |
| 21:39:52 | gradha | I don't mind if you keep doing things this way, I'm fine knowing about which git commit/branch works for me |
| 21:40:32 | gradha | but I keep reading about "wow, such a great language, never read about it", and I wonder about the reasons for that |
| 21:40:42 | Araq | I'm fine giving you access to upload stuff on the website |
| 21:41:18 | gradha | well, that's progress, you can care less about the bureaucracy and let your minioins fix some stuff |
| 21:41:46 | Araq | "care less" hardly fits |
| 21:44:33 | Araq | but yeah, that's progress |
| 21:44:42 | dom96 | gradha: yes |
| 21:44:50 | Araq | btw does "koch web" work again? |
| 21:45:07 | gradha | seems to work for me, didn't it before? |
| 21:45:36 | Araq | yes |
| 21:46:01 | gradha | will update and check again then |
| 21:46:35 | Araq | does "koch web" use your new hyperlinking stuff? |
| 21:46:49 | Araq | is that stable? :P |
| 21:47:09 | gradha | it's waiting code review, seems stable for me |
| 21:48:13 | Araq | btw we had a release process. a stable release every 6 months, master is development version, we have stable releases |
| 21:48:49 | Araq | works when you find the time to release every 6 months and don't get children in the meantime |
| 21:49:14 | gradha | that, or you cut features if you want to stick to periodic releases |
| 21:50:12 | Araq | I spend usually a whole weekend ensuring the binaries work and the produced source code installs |
| 21:51:24 | gradha | if making a release is that painful, then you don't make releases |
| 21:51:56 | Araq | it is all automated |
| 21:52:26 | Araq | but no no no, things have to change, build instructions need to change |
| 21:52:41 | Araq | somebody dislikes something I can't even remember |
| 21:52:55 | Araq | and you change niminst |
| 21:53:00 | Araq | and you need to test again |
| 21:55:09 | Araq | or ubuntu decides lrintf which is part of ansi C is not important |
| 21:56:08 | gradha | these situations you mention are dealt perfectly fine with git-flow creating a hotfix, but you can't with your current release process because master is already "tainted" by new development code |
| 21:57:40 | gradha | it's against intuition that a bureaucratic process speeds up such mini-releases, but it does, I've been enjoying it precisely because you can address all the people who think they know how to do your job better |
| 21:58:35 | gradha | dom96: I couldn't tell you before or my awesome blog post would be ruined! |
| 21:59:05 | gradha | just updated the blog post to remove all personal attacks |
| 21:59:19 | gradha | now it is all clearly neutral and feminist safe |
| 21:59:28 | * | gradha *dongle* |
| 21:59:30 | Araq | damn I liked the personal attacks |
| 21:59:49 | Araq | they were against me though, so now I'm pissed |
| 21:59:55 | gradha | master builds compiler and docs fine right now |
| 22:00:14 | gradha | but you know, macs are toys, you might want to test on a real OS |
| 22:00:20 | Araq | lol |
| 22:03:14 | gradha | good night, honey badgers |
| 22:03:20 | Araq | hey |
| 22:03:30 | Araq | you can't leave just now |
| 22:03:45 | gradha | ok |
| 22:03:48 | gradha | why? |
| 22:04:18 | Araq | because I still don't understand our new way of software development |
| 22:05:02 | gradha | well, you shouldn't accept just what any random guy tells you |
| 22:05:27 | gradha | you can think over it once you've dealt with your fires |
| 22:05:58 | Araq | well since "master" is stable, I can simply work on that |
| 22:06:18 | Araq | and not do the risky merge until long after monday |
| 22:07:22 | gradha | our definitions of stable are different |
| 22:07:49 | gradha | for me stable is the current software being downloaded as a zip from the website |
| 22:08:38 | gradha | changes on master are replicated immediately to the website, with automation |
| 22:09:14 | gradha | so if Ubuntu decides to change another API, you can hotfix master and release |
| 22:09:36 | gradha | meanwhile, you work on develop, or whatever you want to call it, and all PR are made against that, not against master |
| 22:10:07 | Araq | ok but this is what the rust guys did I think |
| 22:10:10 | gradha | essentially, you just keep a branch which is the front-facing release to the world, it doesn't have to be master |
| 22:10:36 | Araq | but everybody made PR against 'master' anyway |
| 22:10:49 | gradha | maybe their documentation sucks |
| 22:11:00 | gradha | or they are unable to ask contributors to rebase against develop |
| 22:11:09 | gradha | NSA gag orders and such |
| 22:11:11 | fowl | plz to accept #801 |
| 22:11:18 | fowl | improvements for c2nim |
| 22:11:47 | Araq | fowl: I talked with discoloda about it, he said he would make a new PR since his changes broke stuff |
| 22:12:02 | fowl | oh |
| 22:12:21 | Araq | you're free to merge it already though if you need it right now |
| 22:12:39 | Araq | I mean merge it to your local repo |
| 22:12:59 | gradha | Araq: using git-flow completely breaks the current organization convention, you don't want to adopt it before the next public release |
| 22:13:23 | Araq | gradha: I'm still torn what "master" should be |
| 22:13:57 | gradha | Araq: sure, that's why I wrote that "paper", so you can think over it carefully all the time you want |
| 22:14:26 | gradha | Araq: I've also used this strategy in most of my nimrod repos, you can take a look at them or ask me questions on how I deal with stuff |
| 22:14:56 | gradha | one of the advantages of master being the front-facing software is that you don't need a website with downloads, github already provides that |
| 22:15:17 | gradha | of course nimrod needs more than github offers, or maybe not, if their releases thingy is used to attach binaries to tags |
| 22:15:39 | Araq | does "git-flow" work on windows or is it a bunch of perl scripts? |
| 22:15:53 | gradha | Araq: I'm positive it only works on macosx |
| 22:16:54 | gradha | well, since windows is superior people make binary installers https://xinyustudio.wordpress.com/2012/03/26/installing-git-flow-in-windows/ |
| 22:17:31 | gradha | Araq: but you don't need to use git-flow at all, the problem is defining what goes into each branch, and how you want to handle that |
| 22:18:26 | bstrie | Araq: nimrod actually has a stable release, so I don't think that looking at what rust does is going to help you at all :P |
| 22:19:04 | bstrie | rust is just "shove everything into master, and once every three months take the current git hash and call it 0.x+1" |
| 22:19:52 | bstrie | 0.9's been out for two days and I've already told three people that it's too old and that they should be using master... |
| 22:20:13 | Araq | well it's clear we need "stable" and "devel" but it's not clear what "master" should be to me |
| 22:20:16 | Araq | however |
| 22:20:50 | Araq | I think I prefer to use what most other github repos use |
| 22:20:56 | bstrie | I think a lot of big projects have the urge to migrate away from having a branch named "master" |
| 22:21:09 | bstrie | this is why github lets you change the "default" branch for your repo |
| 22:21:57 | bstrie | so I'd recommend changing your default branch to "devel", because then whenever anybody makes a PR it automatically gets chosen as the branch to merge into |
| 22:22:05 | bstrie | and just ditching master entirely |
| 22:22:32 | Araq | now that's a good idea |
| 22:22:44 | Araq | since "master" has no meaning, get rid of it |
| 22:23:02 | gradha | or rename it to "stable" |
| 22:23:06 | Varriount | I like the idea of having a "release" branch that only gets bugfixes/hotfixes |
| 22:23:47 | Varriount | Araq: Just be careful with the remote branches, since there are currently at least 20 active pull requests waiting |
| 22:26:21 | Araq | Varriount: first the fix gets into branch, it's tested and then merged into "stable" |
| 22:26:34 | Araq | I don't think a "release" branch is necessary |
| 22:27:36 | Araq | and it should be named after the bug number |
| 22:28:55 | * | dmac quit (Quit: Leaving.) |
| 22:33:54 | Araq | gradha: alright we'll rename "master" to "stable" though that still doesn't mean 0.9.2 + bugfixes |
| 22:34:33 | gradha | Araq: you know you can travel in time for that? |
| 22:35:05 | gradha | Araq: search for the commit in master which was 0.9.2, then create from it the stable branch. |
| 22:35:22 | gradha | Araq: then you can use it to apply only bugfixes, and merge those back into master, develop, whatever |
| 22:36:20 | Araq | hmm |
| 22:36:34 | gradha | using that convention, if tomorrow Ubuntu fucks up, you add a hotfix to stable, then merge into master+devel+everything else |
| 22:36:44 | gradha | then release from stable to the website |
| 22:37:00 | gradha | it's the same as git-flow, but with the names changed, big deal |
| 22:38:21 | gradha | I can write tomorrow a formal proposal of how that would work in the wiki, then we can discuss it further |
| 22:39:33 | Araq | sure but I don't think anybody is interested in 0.9.2 + bugfixes, 0.9.2 is old |
| 22:39:59 | gradha | also, it wasn't possible, because now it's painful to extract from devel the actual bugfixes |
| 22:40:43 | Araq | not really "devel" doesn't have bugfixes, but I guess you mean "master" |
| 22:41:00 | gradha | yes, still thinking the wrong way |
| 22:42:51 | Araq | gah |
| 22:42:58 | Araq | let's continue tomorrow |
| 22:43:05 | gradha | good night |
| 22:43:07 | Araq | bye |
| 22:43:11 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 22:54:28 | * | dmac joined #nimrod |
| 23:12:51 | * | brson joined #nimrod |
| 23:13:29 | * | darkf joined #nimrod |
| 23:21:51 | * | brson quit (Ping timeout: 272 seconds) |
| 23:26:45 | * | dmac quit (Quit: Leaving.) |
| 23:27:29 | radsoc | Araq: I ended up using an array of shared allocCountTables (one per thread) and aggregating them after the joinThreads (I think I'm lock-averse). But actually I wanted to add something about memfiles. I added two small procs to my memfiles.nim in order to deal with huge files (bigger than available ram): mapView and unmapView ( https://gist.github.com/radsoc/8e6d22a36e432940422a ). Using memfiles.close and memfiles.open each time you want to change |
| 23:27:29 | radsoc | mappedSize or offset really slows things down. My procs only work on windows so you should consider them as feature requests not pull requests... |
| 23:27:38 | * | dmac joined #nimrod |
| 23:33:45 | * | brson joined #nimrod |
| 23:33:50 | Araq | radsoc: not sure what to do with these |
| 23:34:04 | Varriount | radsoc: How do you have memory maps larger than available ram? swap to disk? |
| 23:36:17 | radsoc | Varriount: my files are larger than available ram and I have to map only parts (views) of them |
| 23:37:11 | Varriount | Ah |
| 23:39:49 | radsoc | Araq: in case you have some time to kill... |
| 23:41:57 | * | psquid joined #nimrod |
| 23:42:07 | * | psquid quit (Changing host) |
| 23:42:07 | * | psquid joined #nimrod |
| 23:42:53 | Araq | radsoc: make it {.error.} for the other OSes please and then it's fine |
| 23:43:33 | Araq | {.error: "Not ported to your OS".} |
| 23:43:47 | Araq | oh wait lol |
| 23:43:51 | Araq | that doesn't work |
| 23:43:59 | Araq | what does work though is this: |
| 23:44:08 | Araq | when defined(windows): ... :P |
| 23:47:08 | radsoc | sorry? |
| 23:47:40 | Araq | the dummy empty implementation doesn't create a compile-time error |
| 23:47:48 | Araq | this is bad |
| 23:48:13 | Araq | so wrap these routines in a toplevel "when defined(windows)" instead |
| 23:48:34 | Araq | --> are not available for other OSes, users get nice compiler errors |
| 23:50:58 | radsoc | ok, but I guess you're going to ask me a PR... |
| 23:51:25 | Araq | no I assumed you already made one :-) |
| 23:53:56 | radsoc | of course not (I'm too lazy for that...) |
| 23:54:46 | Araq | well I think your memfiles + counttable are a good addition to babel, but you're lazy |
| 23:55:02 | radsoc | and in 'devel' or 'master' or ? |
| 23:55:16 | Araq | all PR against "devel" please |
| 23:55:41 | radsoc | I'm lazy and I've never done that... |
| 23:57:28 | radsoc | but I know I have to contribute to Nimrod somehow |
| 23:57:53 | radsoc | I really really like Nimrod, but you know that |
| 23:58:53 | Araq | yeah but thanks |
| 23:59:25 | Araq | oh btw do you see a linear speedup with the number of cores? |
| 23:59:38 | Araq | i.e. 4 times faster on 4 cores? |