| 00:05:13 | * | bjz quit (Read error: Connection reset by peer) |
| 00:06:11 | * | bjz joined #nimrod |
| 00:09:37 | fowl | Araq, ty |
| 00:10:18 | fowl | dom96, i'll go through the wrappers on nimrod-code and add deadcodeelim to them |
| 00:13:35 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 00:16:44 | reactormonk | fowl, wondering if it would be possible to have a repl in a website |
| 00:16:51 | reactormonk | like haskell does |
| 00:17:10 | flaviu | reactormonk: Yes, give me a few seconds to search my history |
| 00:19:33 | flaviu | reactormonk: Not quite a repl, but its a sandbox: https://github.com/thestinger/playpen |
| 00:19:58 | flaviu | Its a full sandbox, so you can use the less buggy C backend |
| 00:20:24 | reactormonk | not too shabby |
| 01:02:47 | * | brson quit (Quit: leaving) |
| 01:04:33 | * | q66 quit (Quit: Leaving) |
| 01:34:01 | * | bjz quit (Read error: Connection reset by peer) |
| 01:34:26 | * | bjz joined #nimrod |
| 01:38:19 | * | bjz quit (Read error: Connection reset by peer) |
| 01:38:51 | * | bjz joined #nimrod |
| 01:50:44 | * | milosn quit (Ping timeout: 260 seconds) |
| 02:10:12 | * | bjz quit (Ping timeout: 245 seconds) |
| 02:11:53 | * | bjz joined #nimrod |
| 02:16:33 | * | kemet joined #nimrod |
| 02:17:50 | * | lorxu joined #nimrod |
| 02:29:59 | * | milosn joined #nimrod |
| 02:31:15 | * | kemet quit (Ping timeout: 240 seconds) |
| 02:37:07 | flaviu | {:} is valid syntax, right? |
| 02:38:07 | flaviu | Seems to be, yes |
| 02:40:53 | flaviu | I wish there was a way to make an array without caring about its size |
| 02:41:38 | flaviu | Like java arrays |
| 02:42:59 | fowl | you mean a seq? |
| 02:45:10 | def- | sometimes i would also like something between an array and a seq |
| 02:45:32 | flaviu | Yes, but with just a length field, no capacity (essentially [len: int, data: ptr]). Also integration with syntactic sugar, so `let a: Array[tuple[key, val: String]] = {:}` |
| 02:56:24 | fowl | gross |
| 02:58:13 | fowl | you want the array to be reallocated every time you change its size? |
| 03:04:04 | flaviu | fowl: Yes, but I can be as clever as I want about it. The idea is that its a lower level primitive than a seq. |
| 03:06:16 | flaviu | Or even better, I'd like to be able to specify the length of an unchecked array. That's an even better primitive because it allows a maximum of flexibility |
| 03:13:11 | Demos | flaviu, what are you actually trying to do |
| 03:13:28 | Demos | you can use alloc and do a C style array if you want |
| 03:13:58 | flaviu | I know, I've implemented my own array in the style that I like them. The issue is that GC will not work with it |
| 03:15:20 | flaviu | It doesn't know where the array ends so it can't collect anything. And in this specific usecase, I'm looking for pretty syntax, not anything else. I'm not going to get nice syntax without a language builtin, but hmm... |
| 03:15:34 | Demos | well then use a seq |
| 03:15:40 | flaviu | Maybe something could be hacked together with converters |
| 03:15:44 | Demos | that is literally the point of a seq |
| 03:16:10 | flaviu | Demos: {:} returns a Array[I, tuple[key: T1, value: T2]] |
| 03:16:47 | Demos | does @{:} work? |
| 03:17:42 | flaviu | I |
| 03:17:59 | flaviu | 'm still pretty meh on requiring a @ in this case, but it works, thanks |
| 03:18:15 | Demos | :D no problem, I have been there as well |
| 03:21:45 | * | milosn quit (Ping timeout: 240 seconds) |
| 03:22:01 | * | milosn joined #nimrod |
| 03:27:59 | flaviu | Demos: Actually, I even managed to get rid of that little blemish in some cases :D |
| 03:28:44 | fowl | i cannot fathom why someone would want an array of the type you describe |
| 03:29:07 | flaviu | https://gist.github.com/flaviut/f4570de4cd9e97f564ec |
| 03:29:08 | fowl | if you add 100 items to it, it has to do 100 reallocs |
| 03:29:27 | flaviu | The thing is, I'm not going to add 100 items to it. |
| 03:29:37 | flaviu | It isn't a vector, its an array |
| 03:30:16 | fowl | then array[idx,t] should work just fine |
| 03:30:22 | flaviu | How is a seq implemented? What if I have n values, but n is not known at compiletime? |
| 03:30:48 | flaviu | What if I don't want to specialize my function on a thousand different values of n? |
| 03:31:12 | fowl | openarray |
| 03:31:14 | fowl | next q |
| 03:31:58 | flaviu | Openarray is exactly what I'm looking for, but not just in parameter lists |
| 03:32:30 | fowl | yeah ok |
| 03:33:07 | flaviu | Also, my idea for the array would not include an append method. It doesn't make sense, an array is just a bunch of indexed values. |
| 03:43:50 | flaviu | Here is my expertly drawn explanation: http://i.imgur.com/obLSZpe.png?1 |
| 04:15:39 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 04:30:01 | * | bjz joined #nimrod |
| 04:58:25 | * | Demos quit (Read error: Connection reset by peer) |
| 05:18:20 | * | nande quit (Read error: Connection reset by peer) |
| 05:26:22 | * | kshlm joined #nimrod |
| 06:07:00 | * | kunev joined #nimrod |
| 06:13:11 | * | flaviu quit (Ping timeout: 264 seconds) |
| 06:18:54 | * | flaviu joined #nimrod |
| 06:19:01 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 06:27:08 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 07:05:16 | * | kunev quit (Ping timeout: 240 seconds) |
| 07:19:56 | * | noam quit (Ping timeout: 240 seconds) |
| 07:40:04 | * | kunev joined #nimrod |
| 07:40:22 | * | BitPuffin joined #nimrod |
| 08:11:05 | * | Trustable joined #nimrod |
| 08:28:19 | * | mko joined #nimrod |
| 08:28:33 | * | mko quit (Quit: Bye.) |
| 08:30:27 | * | mko joined #nimrod |
| 08:57:18 | * | q66 joined #nimrod |
| 09:05:56 | * | btiffin quit (Ping timeout: 240 seconds) |
| 09:15:58 | * | flaviu quit (Ping timeout: 240 seconds) |
| 09:25:01 | * | btiffin joined #nimrod |
| 09:33:18 | * | io2 joined #nimrod |
| 09:48:32 | * | EXetoC joined #nimrod |
| 10:04:31 | * | Boscop quit (Read error: Connection reset by peer) |
| 10:04:44 | * | Boscop joined #nimrod |
| 10:04:47 | * | Boscop quit (Changing host) |
| 10:04:47 | * | Boscop joined #nimrod |
| 10:11:08 | * | flyx quit (Ping timeout: 252 seconds) |
| 10:13:01 | * | flyx joined #nimrod |
| 10:17:21 | * | utkan joined #nimrod |
| 10:27:37 | * | utkan quit (Read error: Connection reset by peer) |
| 11:41:56 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 11:45:01 | * | EXetoC joined #nimrod |
| 12:21:03 | * | kshlm quit (Ping timeout: 240 seconds) |
| 12:24:02 | * | BlameStross quit (Quit: BlameStross) |
| 12:28:23 | * | untitaker quit (Ping timeout: 256 seconds) |
| 12:35:06 | * | untitaker joined #nimrod |
| 13:03:03 | * | lorxu quit (Ping timeout: 240 seconds) |
| 13:14:45 | * | kshlm joined #nimrod |
| 13:14:45 | * | kshlm quit (Changing host) |
| 13:14:46 | * | kshlm joined #nimrod |
| 13:23:29 | * | darkf quit (Quit: Leaving) |
| 14:21:53 | * | Demos joined #nimrod |
| 14:43:52 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 15:04:47 | * | bjz joined #nimrod |
| 15:13:09 | * | flaviu joined #nimrod |
| 15:18:35 | * | kshlm quit (Ping timeout: 252 seconds) |
| 15:47:39 | * | kshlm joined #nimrod |
| 15:54:50 | def- | Is it safe to cast a tuple just to change parameter names? Or is there a better way to make zip and toTable work together? |
| 16:21:28 | * | bjz quit (Read error: Connection reset by peer) |
| 16:21:49 | * | bjz joined #nimrod |
| 16:23:34 | BitPuffin | def-: sounds safe |
| 16:25:49 | BitPuffin | flaviu: use a pointer lol |
| 16:26:53 | flaviu | BitPuffin: Does a pointer interact with the GC in the expected way? Unfortunately, it doesn't, so a pointer wouldn't help me |
| 16:27:39 | BitPuffin | GC doesn't know about pointers |
| 16:28:12 | flaviu | But I do need it to know about pointers, which is where my issue is |
| 16:28:21 | BitPuffin | yeah I know |
| 16:28:23 | BitPuffin | it's stupid |
| 16:29:00 | BitPuffin | that said I don't think there is really any overhead with using seq as long as you don't resize it |
| 16:29:23 | BitPuffin | in fact you could probably even make your own distinct generic seq that doesn't have resize |
| 16:29:26 | BitPuffin | if you want to enforce it |
| 16:32:49 | flaviu | My beef with the Seq is that it isn't the simplest possible data-type. Its a [Header|len|cap|data...], but I just want [Header|data...] |
| 16:35:16 | * | kunev quit (Quit: leaving) |
| 16:36:39 | BitPuffin | ah |
| 16:36:41 | BitPuffin | that's awful |
| 16:36:44 | BitPuffin | g2g will be back later |
| 16:36:49 | BitPuffin | could go for some vnug maybe |
| 16:41:37 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 16:53:45 | * | Matthias247 joined #nimrod |
| 16:57:30 | * | dLog_ is now known as dLog |
| 17:00:39 | dom96 | hello |
| 17:01:29 | dom96 | flaviu: Why are you after the simplest possible type? |
| 17:09:53 | * | Varriount quit (Read error: Connection reset by peer) |
| 17:10:52 | * | Varriount joined #nimrod |
| 17:17:58 | * | superfunc joined #nimrod |
| 17:39:43 | * | kshlm quit (Quit: Konversation terminated!) |
| 17:43:42 | Demos | holy crap I think that whole service provider GUID mess was literally all in the managed package framework, way to wrap a C++/COM library with c# and make it 300% more complex |
| 17:43:53 | Demos | and this is COM we are talking about, more complex than that is /hard/ |
| 17:52:55 | * | boydgreenfield joined #nimrod |
| 17:53:46 | * | io2_ joined #nimrod |
| 17:54:11 | * | io2_ quit (Client Quit) |
| 17:54:15 | boydgreenfield | Are there any important gotcha with iterators that I should be aware of? I just replaced some inline file parsing in a loop with an iterator version and saw a 5X+ slowdown |
| 17:54:16 | boydgreenfield | https://gist.github.com/boydgreenfield/16a496a705311b49d437 |
| 17:54:41 | * | io2_ joined #nimrod |
| 17:54:46 | * | io2_ quit (Changing host) |
| 17:54:46 | * | io2_ joined #nimrod |
| 17:54:52 | * | io2 quit (Ping timeout: 260 seconds) |
| 17:55:27 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 17:55:30 | Araq | boydgreenfield: lines is slow to begin with |
| 17:55:54 | Araq | maybe my buffer size changes on devel already helped with that |
| 17:56:35 | Araq | using 2 yields with an inline iterator is very bad for code size, i think the compiler should warn about this |
| 17:56:47 | * | io2_ quit (Client Quit) |
| 17:57:00 | Araq | and in general your string handling sucks |
| 17:57:09 | * | io2 joined #nimrod |
| 17:57:21 | Araq | so yes, 5x slowdown. why not. |
| 18:02:24 | boydgreenfield | Araq: Ok, that’s all fair. Could you point me to an example re: string handling improvements? I’m surprised because the exact same thing in a loop is 5x faster (same string handling, same lines, etc.) |
| 18:03:55 | Araq | well I guess the compiler still misses some important copy elision for your iterator, so ultimately it'll produce the same code. perhaps. |
| 18:04:23 | boydgreenfield | (Specifically, I call an expensive function f(sequence) and doing that in the loop vs. doing `for header, sequence in file.fasta_pairs(): f(sequences)`) |
| 18:04:31 | Araq | for now, don't do: sequence = "" |
| 18:04:46 | Araq | sequence.setLen(0) in the loop re-uses the buffer |
| 18:05:07 | def- | Araq: doesn't make a difference at all in this case |
| 18:07:13 | def- | boydgreenfield: can you show your old loop version? when I make it a loop it has the same speed |
| 18:07:22 | boydgreenfield | def-: Will do. Gimme 2 minutes. |
| 18:07:41 | Araq | very well. listen to def- |
| 18:07:46 | Araq | I need to go anyway, bbl |
| 18:08:31 | * | kunev joined #nimrod |
| 18:08:45 | boydgreenfield | Araq: Thx. |
| 18:13:09 | Araq | def-: btw the tuple issue will be solved at the language level. it's not hard to change the spec/implementation. |
| 18:13:18 | Araq | bye |
| 18:13:24 | def- | alright, bye |
| 18:23:50 | boydgreenfield | def-: Ok well this is frustrating… having some reproducibility issues when I take out a bunch of the processing functions (e.g., a discard loop is the same speed) |
| 18:24:04 | boydgreenfield | def-: That said, would still love pointers on optimizing string handling |
| 18:24:48 | * | zahary joined #nimrod |
| 18:24:51 | def- | boydgreenfield: alright, I'll try what i can |
| 18:25:30 | boydgreenfield | (def-: I really just mean any general good examples — happy to look through some fast string handling code if you have a good example) |
| 18:26:08 | def- | boydgreenfield: i think i made it twice as fast already |
| 18:26:13 | * | BlameStross joined #nimrod |
| 18:26:22 | boydgreenfield | def-: Ouch / thanks! |
| 18:26:41 | boydgreenfield | def-: Clearly I need some best practices examples to imitate. |
| 18:26:53 | def- | just trying a few other things to see what is worth something |
| 18:27:08 | def- | I don't have any good examples I think, hmm |
| 18:29:45 | * | brson joined #nimrod |
| 18:30:28 | def- | boydgreenfield: https://gist.github.com/def-/c6f3ae893b935464dab0 |
| 18:30:47 | def- | I used another line reader, which is much faster |
| 18:32:42 | def- | makes me go from 0.35 to 0.19. knowing the approximate sequence size ahead goes down to 0.14 |
| 18:32:49 | def- | (seconds) |
| 18:32:55 | def- | for a 15 MB file |
| 18:35:07 | boydgreenfield | def-: That’s very helpful, thanks. |
| 18:35:59 | boydgreenfield | def-: Well and I found my iterator bug — I wasn’t clearing something in my extra code. Oops. |
| 18:38:03 | boydgreenfield | def-: As to general string processing, I have a lot of code that’s iterating through strings and getting fixed length substrings, e.g., `for i in 0.. <(sequence.len - k): process(sequence[i..(i+k-1)])` |
| 18:38:15 | boydgreenfield | Is that going to be creating all sorts of extraneous copies I should be avoiding? |
| 18:38:28 | boydgreenfield | I’m quite new to Nimrod’s string handling |
| 18:39:25 | def- | boydgreenfield: i guess that will create copies, yes |
| 18:39:37 | def- | but maybe I'm wrong, I'll try to check |
| 18:40:21 | boydgreenfield | def-: As context, I’m doing a lot of bioinformatics string handling, and this notion of using “k-mer” or enumerating all k-length substrings is very prevalent |
| 18:40:47 | * | Jesin quit (Ping timeout: 240 seconds) |
| 18:41:29 | flaviu | boydgreenfield: You could define your own substring, so that it does whatever is most performant for your application |
| 18:42:00 | def- | you could benchmark if it's better to pass the entire string and the start and end index |
| 18:43:22 | def- | strings in nimrod have a 0 at the end, so making a substring needs to create a copy I guess |
| 18:48:06 | boydgreenfield | flaviu: You mean overriding the `[]` operator on some custom string type? And practically speaking, could one create the fixed k-length string with the 0 terminator, and then shallow-copy into it? |
| 18:48:15 | boydgreenfield | (At some point, this seems harder than just using cstrings, however) |
| 18:51:45 | * | zahary quit (Ping timeout: 255 seconds) |
| 18:52:51 | * | gsingh93_ joined #nimrod |
| 18:58:11 | flaviu | You wouldn't have the 0 terminator, I don't know if that's needed |
| 19:00:31 | Demos | woohoo VS can compile and launch nimrod executables! |
| 19:02:58 | dom96 | Demos: Awesome. |
| 19:03:21 | Demos | breakpoints seem to work |
| 19:04:05 | flaviu | Demos: How do local variables do? |
| 19:04:44 | flaviu | GDB renders them as LOC123 |
| 19:05:56 | Demos | well it renders whatever is in the pdb file. Nimrod apperently tries to keep locals names reasonable, but I see a few LOCXXX here |
| 19:06:29 | flaviu | Hmm, I wonder if I can get the compiler to use real symbol names |
| 19:06:42 | Demos | it does when it can |
| 19:07:30 | Demos | better would be a way to ask what the actual locals are (there is a locals() proc, but it is not /really/ a proc afaik |
| 19:08:52 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 19:10:19 | * | Jesin joined #nimrod |
| 19:20:52 | * | mwbrown joined #nimrod |
| 19:23:50 | dom96 | hi mwbrown |
| 19:36:02 | * | BitPuffin joined #nimrod |
| 19:37:58 | * | io2_ joined #nimrod |
| 19:38:33 | * | io2 quit (Ping timeout: 255 seconds) |
| 19:51:23 | * | zahary joined #nimrod |
| 19:56:34 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:14:29 | * | kunev quit (Ping timeout: 252 seconds) |
| 20:16:26 | mwbrown | dom96: Have you ever seen an issue in c2nim where converting a macro changes minuses to plus? |
| 20:16:52 | mwbrown | I just started learning Nimrod a few weeks ago and noticed when I ran a header through c2nim it messed up the math on macros with a - in it |
| 20:22:15 | mwbrown | here's a good example of what I'm talking about |
| 20:22:16 | mwbrown | http://pastebin.com/Bjxf0yD1 |
| 20:24:17 | flaviu | mwbrown: Its a copypaste bug, https://github.com/Araq/Nimrod/blob/devel/compiler/c2nim/cparse.nim#L1532-L1539 |
| 20:27:08 | mwbrown | that's not terribly surprising |
| 20:27:11 | mwbrown | at least it's an easy fix |
| 20:31:07 | * | ics joined #nimrod |
| 20:37:17 | Araq | flaviu: c2nim got its own repo |
| 20:37:25 | Araq | please fix it there |
| 20:37:33 | Araq | I removed c2nim from the compiler already |
| 20:37:45 | Araq | but ofc it's in some unmerged branch ... |
| 20:38:41 | flaviu | I didn't realize, thanks for pointing that out |
| 20:39:54 | * | boydgreenfield joined #nimrod |
| 20:40:42 | Araq | hmm why I am subscribed to the bitc mailing list ... all they do is talking about how to improve Java's interfaces |
| 20:41:09 | Araq | how will this ever result in a systems programming language? |
| 20:41:15 | Araq | who knows ... |
| 20:41:58 | * | bjz quit (Read error: Connection reset by peer) |
| 20:43:16 | * | bjz joined #nimrod |
| 20:43:44 | BitPuffin | Araq: bitcoin? |
| 20:43:46 | EXetoC | java interface? fair enough! |
| 20:44:05 | def- | BitPuffin: i guess this: http://www.bitc-lang.org/ |
| 20:45:15 | BitPuffin | ah interesting |
| 20:45:33 | BitPuffin | Araq: well just because you can talk to java doesn't make you any less of a systems language :P |
| 20:45:52 | BitPuffin | that's like saying ermagerd nimrod can compile to javascript how can it ever be a systems language |
| 20:52:01 | flaviu | There isn't any way to say 'n to m of E' in pegs, right? |
| 20:52:37 | flaviu | Like the regex `E{n,m}` |
| 20:53:54 | Araq | dunno, can't remember |
| 20:54:21 | Araq | pegs suck |
| 20:54:25 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:55:18 | dom96 | Would be nice to have a native regex engine in Nimrod. |
| 20:56:10 | flaviu | Especially a compile-time one, like D |
| 20:57:34 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 20:58:01 | dom96 | indeed |
| 20:58:08 | flaviu | Araq: Mind doing some finger exercises? I'd like a parser generator and regex engine. :P |
| 20:58:57 | Araq | I've written a lexer generator, well the start of one |
| 20:59:10 | Araq | but the code is years old |
| 21:00:44 | BitPuffin | yeah we should all switch to D |
| 21:00:44 | flaviu | The lexer generator is the easy part |
| 21:00:53 | flaviu | BitPuffin: How about a D backend? |
| 21:01:10 | BitPuffin | that would be stupid |
| 21:01:13 | BitPuffin | but I think you are referencing |
| 21:01:15 | BitPuffin | a certain thread |
| 21:01:20 | dom96 | How about an asm backend? |
| 21:01:35 | Araq | flaviu: no it's not |
| 21:01:39 | BitPuffin | yeah like I said to you like yesterday dom96 |
| 21:01:54 | dom96 | How about a web service which translates nim code into js? |
| 21:02:02 | flaviu | Araq: Huh? Take a bunch of regexes, apply them, and see what fits |
| 21:02:08 | dom96 | WHERE ARE ALL THESE COOL THINGS?! |
| 21:02:09 | BitPuffin | that doesn't make much sense dom96 |
| 21:02:26 | BitPuffin | since most of the nimrod code people write is dependent on OS things |
| 21:02:29 | flaviu | dom96: https://github.com/thestinger/playpen |
| 21:02:36 | BitPuffin | it's not like anyone is writing code that is only using the dom api |
| 21:02:44 | dom96 | BitPuffin: I am? |
| 21:02:52 | BitPuffin | no you fucking aren't :P |
| 21:03:04 | BitPuffin | yeah, your async module is written with the dom module |
| 21:03:22 | BitPuffin | and what's there to gain anyway? |
| 21:03:22 | dom96 | flaviu: There you go. You already know how to get it done. |
| 21:03:24 | Araq | flaviu: you describe a poor man's lexer generator |
| 21:03:31 | dom96 | flaviu: Get on with it. |
| 21:03:32 | BitPuffin | instead of running the code you copy and paste it into a web form? |
| 21:03:39 | BitPuffin | s/code/compiler |
| 21:03:44 | flaviu | dom96: I'm working on a url library that is awesome |
| 21:03:55 | * | ics joined #nimrod |
| 21:03:58 | BitPuffin | dom96: someone should however write a js2nim thing |
| 21:04:01 | BitPuffin | that would be useful |
| 21:04:07 | BitPuffin | however |
| 21:04:11 | BitPuffin | not really possible probably |
| 21:04:23 | BitPuffin | you probably have to do like typescript and write shit manually |
| 21:04:29 | dom96 | flaviu: I wish you would just add to parseurl/url modules. |
| 21:04:38 | flaviu | I think that ironing out all the bugs in c2nim should have greater priority than some js2nim thing of minimal usefulness |
| 21:04:59 | Demos | I have found c2nim fairly bug free |
| 21:05:14 | Demos | it should not be expected that it can translate C code with no modification |
| 21:05:14 | * | Trustable quit (Quit: Leaving) |
| 21:05:17 | dom96 | c2nim is stable IMO |
| 21:05:31 | Araq | "ironing out all the bugs" means rewriting it into clang2nim |
| 21:05:37 | BitPuffin | Demos: but then wtf is the point |
| 21:05:49 | Demos | It makes it a heck of a lot eaiser to translate stuff |
| 21:05:53 | flaviu | dom96: parseurl? |
| 21:05:56 | dom96 | A good ecosystem of tools and packages is more important now. |
| 21:05:58 | BitPuffin | good luck finding useful C libraries that are written in ansi c |
| 21:06:03 | Araq | DaddYE is working on that, but I don't know the status and he hasn't been here since quite some time |
| 21:06:18 | Demos | you sit your ass down with c2nim, vim, regex, and gcc -E and you fix the headers till it works |
| 21:06:19 | dom96 | flaviu: https://github.com/Araq/Nimrod/blob/devel/lib/pure/parseurl.nim |
| 21:06:39 | BitPuffin | Demos: that's not good enough, and that's not selling at all |
| 21:06:56 | BitPuffin | if we could say we can generate perfect C bindings automatically like magic |
| 21:07:00 | BitPuffin | that's when it's impressive |
| 21:07:08 | dom96 | BitPuffin: Can other languages do that? |
| 21:07:10 | BitPuffin | btw we kind of oversell c2nim right now anyway |
| 21:07:21 | Demos | there is NO language that supports automaticly translateing any C code, closest is C++ (well maybe objc) and they are (near) supersets of C |
| 21:07:21 | BitPuffin | dom96: no and that's why it would be a selling argument |
| 21:07:27 | Araq | flaviu: did you run the c2nim test suite btw? |
| 21:07:30 | BitPuffin | dom96: also I guess swig is probably pretty good at it |
| 21:07:38 | dom96 | BitPuffin: Yeah, maybe because it's hard to do. |
| 21:07:43 | dom96 | BitPuffin: Perhaps even impossible. |
| 21:07:52 | Demos | I kinda suspect that it is indeed impossible |
| 21:07:54 | flaviu | dom96: Besides that that code isn't pretty, you don't deal with ipv6 or ipv_future |
| 21:07:54 | dom96 | To do 100% accurately. |
| 21:08:00 | BitPuffin | dom96: it's not impossible, and most cool things are hard to do, that's not a convincing argument at all |
| 21:08:07 | flaviu | Araq: Nope, I've just heard of people having trouble. |
| 21:08:13 | Demos | unless Araq has a strong AI sitting around that we do not know about |
| 21:08:37 | dom96 | flaviu: Make it pretty then and extend it. |
| 21:08:38 | flaviu | Demos: How about llvm ir? |
| 21:08:46 | dom96 | flaviu: Requiring pcre for URL parsing would annoy me. |
| 21:09:09 | Demos | flaviu, huh. I dont think you can translate llvm IR back into useful C |
| 21:09:47 | flaviu | Demos: You used to be able to a couple years ago |
| 21:10:05 | flaviu | LLVM supported it, but no one maintained it so it fell apart |
| 21:10:16 | Demos | flaviu, maybe it is possible then. And we should indeed keep improving c2nim |
| 21:10:49 | flaviu | dom96: I'm using PEGs, but I'm not really happy with how its turning out: `( ( h16 ":" )? ( h16 ":" )? ( h16 ":" )? ( h16 ":" )? ( h16 ":" )? ( h16 ":" )? h16 )? "::"` |
| 21:11:00 | dom96 | What happened to that PR that merged the url (or is uri?) modules with parseurl? |
| 21:11:04 | Demos | the fact is though that there is no way to know which C macros should be turned into nimrod constructs and which ones should be evaluated by the c preprocessor before translation to c |
| 21:11:09 | Demos | *to nimrod |
| 21:11:16 | dom96 | flaviu: You should do it how I'm doing it. |
| 21:11:22 | dom96 | flaviu: While loop + case stmt |
| 21:11:35 | flaviu | Yeah, but thats ugly |
| 21:11:39 | dom96 | flaviu: FYI that is my first stdlib contribution IIRC |
| 21:11:47 | dom96 | so the code isn't ideal |
| 21:11:53 | flaviu | http://tools.ietf.org/html/rfc3986#appendix-A |
| 21:12:15 | flaviu | That isn't practical for anything but the most basic grammers |
| 21:13:08 | Araq | flaviu: but it is. |
| 21:13:21 | Araq | on the contrary regexes and pegs do not scale for complex grammars |
| 21:13:45 | flaviu | Why not? |
| 21:14:34 | Araq | because you always end up with a *list* of patterns |
| 21:14:49 | Araq | and this matched sequentially |
| 21:15:01 | Araq | and the interactions kill you |
| 21:15:09 | Araq | they kill you very quickly |
| 21:15:14 | Araq | been there, done that |
| 21:15:17 | BitPuffin | Demos: there is no reason you couldn't do it, it's just that you have to build a c pre processor :P |
| 21:15:38 | BitPuffin | or use a C compiler's |
| 21:15:40 | Demos | BitPuffin, but how do you know what needs to be kept and what should be preprocessed and expanded |
| 21:15:44 | Demos | that is what I do |
| 21:16:06 | Demos | but for example you can not know if a #define should be made into a const or expanded |
| 21:16:32 | BitPuffin | it's pretty easy to see if it's a value or a macro |
| 21:16:35 | Araq | actually you can quite easily |
| 21:16:51 | Araq | but I never implemented the heuristic |
| 21:17:16 | Demos | Araq, well I guess I am wrong then |
| 21:17:21 | BitPuffin | yes |
| 21:17:32 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:18:10 | Araq | the heuristic I have in mind simply counts the occurances of the #define |
| 21:18:27 | Araq | if the number is > 2 then it's a #def, otherwise it's a #define |
| 21:18:54 | Demos | what if there is a constant that you use a whole lot? |
| 21:19:13 | Araq | that doesn't happen in header files |
| 21:19:21 | dom96 | flaviu: it would be nice to have something which is compatible with parseurl because I use it in many places |
| 21:19:31 | Demos | Araq, true |
| 21:19:46 | dom96 | flaviu: Also, we really don't need to support the full RFC from the start. |
| 21:20:12 | dom96 | ipv6 is still rare |
| 21:20:22 | flaviu | So? |
| 21:20:37 | Araq | is the RFC even a spec? |
| 21:20:47 | Araq | or is it a "living" document like the HTML spec? |
| 21:20:55 | * | xenagi joined #nimrod |
| 21:21:28 | Araq | (cause if it's a living document I don't really give a fuck) |
| 21:22:31 | flaviu | Araq: Its a real standard |
| 21:22:52 | Araq | impressive |
| 21:23:09 | dom96 | I seriously doubt that every implementation implements it fully 100% correctly. |
| 21:23:48 | flaviu | dom96: Do we really want to be php, where everything is implmented half-assedly? |
| 21:25:04 | Araq | no, we want to be Java where everything is correct and unusable and slow :P |
| 21:25:15 | dom96 | flaviu: Look at it this way: 99% of users only require 60% of the spec to be implemented. |
| 21:25:24 | dom96 | You spend all your time implementing 100% of the spec. |
| 21:25:59 | dom96 | A user comes along and tries to use Nimrod but can't because some other library is missing. |
| 21:26:07 | Araq | and when you're done with a bit of luck the spec changed. and maybe it even adapted to all the other broken implementations out there... |
| 21:26:14 | dom96 | Which you could have implemented in the time you saved by only implementing 60% of the spec :P |
| 21:26:52 | dom96 | I think the law of diminishing returns applies here very well. |
| 21:27:26 | Raynes | dom96: You. Hi. |
| 21:27:35 | dom96 | Raynes: Hi. Sup. |
| 21:27:49 | Raynes | dom96: So when are you gonna come visit us in LA? |
| 21:28:11 | dom96 | Raynes: Right after I visit Araq in Germany :P |
| 21:28:40 | Raynes | Oh, I see how it is. |
| 21:28:44 | Raynes | I' |
| 21:29:06 | Raynes | I'll fight Araq for coolness factor any day of the week and twice on Thursday. |
| 21:29:15 | * | seubert is now known as suckit |
| 21:29:38 | dom96 | I think the bigger problem is that curtis would murder me since he's now living with you too from what I saw. |
| 21:29:58 | Raynes | He isn't living with us. |
| 21:30:00 | Raynes | He left today. |
| 21:30:02 | Raynes | He was here for a week. |
| 21:30:15 | * | suckit is now known as seubert |
| 21:31:11 | dom96 | Raynes: I see. Hrmmm. Tickets to the US cost way too much though and i'm starting Uni soon. |
| 21:31:22 | Raynes | Erik and Daniel currently live with me. Daniel works full time at Scopely now and thus is with me for the indefinite future. Erik goes back to school in August. |
| 21:31:45 | Raynes | dom96: Heh, I know. We'll get you out here one day. |
| 21:32:10 | Raynes | We want to get everyone out to visit us over time, but the people like you and Liam make it difficult. |
| 21:32:30 | Raynes | Overseas travel is just impossible, even with our combined income :P |
| 21:32:47 | dom96 | Raynes: I'm surprised you want me. I left your "crew" a loooong time ago. |
| 21:33:00 | * | lorxu joined #nimrod |
| 21:33:05 | BitPuffin | I'm surprised you want him period |
| 21:33:17 | Raynes | lol |
| 21:33:23 | BitPuffin | just kidding dom96, hugs :) |
| 21:33:30 | Raynes | dom96: We never stopped being friends. |
| 21:33:34 | Raynes | I still love you. |
| 21:33:47 | dom96 | Raynes: <3 |
| 21:33:49 | dom96 | BitPuffin: <3 |
| 21:34:05 | * | dom96 needs to share his love nowadays |
| 21:34:49 | dom96 | Raynes: We should probably stop derailing this channel into offtopic land. PM. |
| 21:35:54 | * | boydgreenfield joined #nimrod |
| 21:36:56 | BitPuffin | was Raynes the guy who wanted everything to be FP evar? |
| 21:37:38 | Raynes | I'm sure I bitched about shortcomings at some point. |
| 21:37:59 | BitPuffin | of what? |
| 21:41:24 | dom96 | BitPuffin: You still moving to London? |
| 21:41:33 | BitPuffin | dom96: yaman |
| 21:41:38 | BitPuffin | I'll be there on the 26th yo |
| 21:41:41 | BitPuffin | get your ass over there |
| 21:41:46 | BitPuffin | and we'll penis-boop |
| 21:42:01 | dom96 | BitPuffin: ewwww. I mean hell yes. |
| 21:42:20 | BitPuffin | OMFGYESIHAVEBEENWAITINGSOLO... err I mean eeeeewww |
| 21:42:24 | dom96 | London is certainly closer. |
| 21:42:29 | BitPuffin | it is |
| 21:42:30 | dom96 | I could probably get a cheap ticket someday |
| 21:42:34 | BitPuffin | for sure |
| 21:42:45 | dom96 | we'll see how it goes :P |
| 21:42:51 | BitPuffin | :D |
| 21:42:55 | Araq | don't we have an offtopic channel? |
| 21:42:58 | BitPuffin | no |
| 21:43:07 | dom96 | if you ever wanna see where GoT is produced you can come to northern ireland :P |
| 21:43:25 | BitPuffin | hey man, what if more peolpe in the UK see it and want to arrange a meetup Araq, it's not necessarily offtopic |
| 21:43:42 | dom96 | Araq: People aren't really talking anyway. |
| 21:43:43 | BitPuffin | dom96: :P so that's why you watch it, you nazi |
| 21:44:00 | Araq | I am |
| 21:44:02 | dom96 | BitPuffin: I walk past Titanic Studios on my way to work every day :D |
| 21:44:13 | dom96 | BitPuffin: Still haven't seen Tyrion :( |
| 21:44:22 | dom96 | BitPuffin: Or anyone for that matter D: |
| 21:44:23 | BitPuffin | dom96: do you get in there and fap them off? |
| 21:44:34 | BitPuffin | Araq: you were silent for like 20 minutes |
| 21:44:40 | dom96 | BitPuffin: I wish *cough* |
| 21:44:48 | BitPuffin | dom96: peeeeeeteeeeer diii-iii-iiiiinklaaageee |
| 21:44:59 | Araq | there is a reason we have an offtopic channel and I'm not in there |
| 21:45:00 | dom96 | http://www.danbarham.com/dinklage/ |
| 21:45:22 | dom96 | ok ok |
| 21:45:26 | dom96 | BitPuffin: Let's take it to offtopic |
| 21:45:30 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:45:47 | BitPuffin | Araq: rot here all alone then. |
| 21:51:19 | dom96 | Araq: Seems I just created a simple example of an async segfault which can be reproduced every time. Want it? |
| 21:51:35 | dom96 | Araq: My small changes to the stdlib stuff may affect it i'm not sure. |
| 21:52:19 | dom96 | Araq: https://gist.github.com/dom96/4ee7a2f7b05d2da1a46b |
| 21:52:28 | dom96 | Segfaults on linux |
| 21:58:08 | Araq | does it segfault on windows too? ;-) |
| 21:59:01 | * | BitPuffin wonders if you are trying to convey some kind of windows propaganda |
| 21:59:19 | dom96 | Araq: Try it and see |
| 22:00:33 | * | mwbrown quit (Ping timeout: 240 seconds) |
| 22:01:06 | Raynes | BitPuffin: It depends on what you mean by 'everything'. |
| 22:01:16 | Raynes | I complained about some random Nimrod stuff at some point. |
| 22:01:34 | Raynes | I can't remember what it was that I did the complaining about. |
| 22:01:54 | * | Matthias247 joined #nimrod |
| 22:02:37 | BitPuffin | well dom96 knew some guy who said that even kernels should be written in like haskell or something |
| 22:02:45 | Raynes | That's not gonna be me. |
| 22:02:52 | Raynes | Sounds more like another guy I know. |
| 22:02:54 | BitPuffin | that said I love FP thingies |
| 22:02:58 | Raynes | Who would say that. |
| 22:03:24 | dom96 | I can't even remember saying that. |
| 22:03:32 | BitPuffin | dom96: you weren't the one saying it |
| 22:03:41 | BitPuffin | it was one of your friends who came in here that mentioned it |
| 22:03:45 | BitPuffin | it could have even been Raynes |
| 22:03:50 | BitPuffin | but the FP friend wasn't in here |
| 22:04:20 | Raynes | I think kernels should be written in whatever you want to write kernels in,. |
| 22:04:22 | BitPuffin | however there is a kernel written in haskell actually believe it or not |
| 22:04:27 | Raynes | That's my opinion about a lot of things. |
| 22:04:33 | BitPuffin | sure |
| 22:04:36 | Demos | I doubt we will ever see a new mature kernel |
| 22:04:44 | BitPuffin | Demos: pff |
| 22:04:49 | BitPuffin | Demos: maybe not in our lifetime |
| 22:04:51 | BitPuffin | well actually |
| 22:04:54 | BitPuffin | probably in our lifetime |
| 22:05:09 | BitPuffin | but I think you are thinking on a micro level compared to the big picture |
| 22:05:44 | BitPuffin | fast forward many years and people will think C is like COBOL and linux is like punchcards |
| 22:06:01 | superfunc | I gave up on telling people what languages to use lol |
| 22:06:02 | Demos | honestly, I could see NT, BSD, and Linux being the only kernels around for a really long time, like as long as we are using CPUs with something resembleing a von neumann architecture |
| 22:06:08 | BitPuffin | and mac os x will prevail |
| 22:06:10 | BitPuffin | just kidding |
| 22:06:15 | superfunc | working at a java shop breaks you down |
| 22:06:55 | BitPuffin | superfunc: well our backend uses node.js and mongodb so working with java would be a fucking wet dream compared to going through that backend |
| 22:07:00 | BitPuffin | luckily I don't have to touch it |
| 22:07:27 | Matthias247 | superfunc: but even the jvm guys have now lots of options with scala, groovy, kotlin, ceylon, ... |
| 22:07:55 | superfunc | I heard this today, almost made me fall out of my chair: "I don't like passing functions to functions, it makes me uncomfortable, I feel like it shouldn't work like that" |
| 22:08:24 | Matthias247 | yeah, passing interfaces to functions is much more natural :) |
| 22:08:38 | superfunc | Matthias247, totally, I wanna check out clojure |
| 22:08:45 | Demos | superfunc, someone needs to teach them how interfaes work |
| 22:09:12 | Matthias247 | superfunc: looks least appealing to me: I can't stand the brackets :) |
| 22:09:49 | Demos | if I am going to program in lisp I want the option of annotateing my code and getting good assembly generation |
| 22:10:02 | superfunc | I was talking about C++ at the time, to be fair. Some exam ? had asked to give an example of first class functions in Java. I decided to go rogue and do it in C++ since java wasn't a pre req |
| 22:10:25 | BitPuffin | Demos: which you have |
| 22:10:40 | superfunc | and since using std::function<T> would actually fit in the answer box |
| 22:10:55 | BitPuffin | Demos: you can get static types etc and very good binary output from for example common lisp |
| 22:11:01 | Demos | yeah, I know |
| 22:11:05 | Demos | but I like nimrod better |
| 22:11:07 | Matthias247 | they both feel super-cluncy versus jusing C# |
| 22:11:10 | BitPuffin | you could probably even get pretty good speeds with something like chicken scheme, that compiles to C |
| 22:11:13 | BitPuffin | I like lisp syntax |
| 22:11:15 | Demos | does clisp have the stuff people like about clojure? |
| 22:11:21 | BitPuffin | however I'm not going for that |
| 22:11:31 | BitPuffin | Demos: what does people like about clojure? |
| 22:11:35 | Demos | dun know |
| 22:11:36 | BitPuffin | the java api? no |
| 22:11:42 | Demos | it has some neat mutability thingies |
| 22:11:42 | superfunc | I got hip on scheme last year, which is why I wanted to try it. |
| 22:12:01 | BitPuffin | I really like how extremely minimal the syntax is |
| 22:12:04 | BitPuffin | it's quite amazing |
| 22:12:25 | Demos | since I come from c++ pretty much any syntax is really minimal |
| 22:12:38 | Demos | although I find that nimrod's syntax is pretty great tbh |
| 22:12:46 | BitPuffin | that said I'm not sure it's the most practical language for everything. That said if you would only get one language for everything it would probably be the best syntax |
| 22:12:48 | superfunc | Demos: yep |
| 22:13:22 | BitPuffin | Demos: lol, yeah |
| 22:13:42 | superfunc | Coming to nimrod, I was like, what else do I type, this can't be enough |
| 22:13:45 | BitPuffin | When I saw D it was like, wow it's so liberating like C++ was but much more minimal |
| 22:13:47 | BitPuffin | which is true |
| 22:13:54 | BitPuffin | but feeling that the language is minimal is hilarious |
| 22:14:12 | BitPuffin | superfunc: and it ain't |
| 22:14:12 | Demos | I have looked at some fancy D libraries that use templates and mixins and I did not like the way they looked |
| 22:14:14 | * | BitPuffin runs |
| 22:14:34 | * | nande joined #nimrod |
| 22:14:57 | BitPuffin | Demos: D is not horrible, it's pretty good actually. Just that it's trying to be C++ too much. |
| 22:15:01 | BitPuffin | and like araq once said |
| 22:15:10 | BitPuffin | they don't really think about the cost of parameterization |
| 22:15:20 | BitPuffin | oddly enough it still compiles very very fast |
| 22:15:27 | BitPuffin | I wonder if that scales though |
| 22:15:35 | Demos | pretty sure the cost of parameterization is not in compile times |
| 22:15:40 | BitPuffin | oh it is |
| 22:16:01 | BitPuffin | as well as executable size |
| 22:16:20 | Demos | honestly once you have a real module system you can do all kinds of crazy stuff and not really feel it |
| 22:16:44 | Demos | but parameterization is the right way to do a whole lot of things |
| 22:17:01 | BitPuffin | the point is that you are duplicating code for a whole bunch of different types that are used in many places and it just kind of grows exponentially |
| 22:17:18 | Demos | it grows lineraly for the number of instances.... |
| 22:17:20 | BitPuffin | Demos: polymorphism is often a much better thing |
| 22:17:32 | BitPuffin | Demos: yes :P |
| 22:17:32 | Demos | but you need heap allocation to use polymorphism |
| 22:17:56 | Demos | I agree that it is situational |
| 22:17:56 | BitPuffin | Demos: however we don't really have a real module system |
| 22:18:03 | Demos | BitPuffin, we don't? |
| 22:18:18 | BitPuffin | Demos: the best think is probably a nice middleground between the two |
| 22:18:24 | Demos | well seperate compilation does not work, but for a given compile each module only needs to be parsed once |
| 22:18:45 | BitPuffin | Demos: ah, I thought you meant that you could do cool things with the modules themselves |
| 22:18:57 | Demos | BitPuffin, I would not know what that middle ground is, and if it is "the compiler decideing for you" (does rust do this?) then I would be concerned about the loss of control |
| 22:19:16 | Demos | BitPuffin, Like what ML has? |
| 22:19:34 | Demos | I dont know anything about ML's modules, but I know they are supposed to be "pretty nifty" |
| 22:19:53 | * | boydgreenfield joined #nimrod |
| 22:20:12 | Demos | also VNUG |
| 22:20:40 | Matthias247 | Demos: you can also use polymorphism on the stack? |
| 22:20:40 | def- | boydgreenfield: i worked some more on the fasta thing to see how i could make it faster: https://gist.github.com/def-/c6f3ae893b935464dab0 |
| 22:21:07 | Demos | Matthias247, true, but you need the pointer |
| 22:21:20 | Demos | and usually if the thing is on the stack you want parameterization anyways for speed reasons |
| 22:21:26 | BitPuffin | Demos: they are first class, it's fucking awesome |
| 22:21:32 | BitPuffin | :D |
| 22:22:14 | flaviu | BitPuffin: So you can pass a module around like an object? |
| 22:22:18 | BitPuffin | flaviu: yeah |
| 22:22:31 | Demos | I really just do not understand them. I guess it is like dependency injection baked into the language |
| 22:22:32 | BitPuffin | maybe http://www.ats-lang.org/ is a good middleground between templates and polymorphism |
| 22:22:34 | BitPuffin | haven't looked at it |
| 22:22:53 | Demos | is ats actually useful? |
| 22:23:11 | BitPuffin | I don't know |
| 22:23:13 | BitPuffin | it might be |
| 22:23:32 | flaviu | Ah, so they're like type classes |
| 22:23:35 | BitPuffin | by it's description it sounds like it |
| 22:23:44 | BitPuffin | flaviu: ish |
| 22:24:09 | BitPuffin | probably more close to rust's traits |
| 22:24:20 | BitPuffin | that are basically type classes |
| 22:24:23 | BitPuffin | but more objecty |
| 22:24:37 | Demos | oh, nimrod can totally do that |
| 22:25:03 | flaviu | Demos: Sure, if you want to use a function tuple |
| 22:25:03 | BitPuffin | Demos: I believe ATS has dependent types which is awesome |
| 22:25:07 | Demos | make an object with some function pointers and then make a converter from a typeclass to the object |
| 22:25:14 | Matthias247 | rusts traits can act as type classes as well as interfaces. But they don't work good as interfaces (trait objects) at the moment |
| 22:25:14 | BitPuffin | Demos, flaviu: no, because then you don't get polymorphism |
| 22:25:30 | Demos | BitPuffin, you totally do though |
| 22:25:40 | BitPuffin | with first class modules that are polymorphic you can take a module that has at least two functions |
| 22:25:47 | Demos | you can stick these objects into a collection and call the functions as you like |
| 22:25:48 | BitPuffin | but you can also send one with 382 |
| 22:26:05 | flaviu | structural subtyping? |
| 22:26:13 | Demos | oh, I meant like traits, not ML modules |
| 22:26:21 | BitPuffin | ah |
| 22:26:25 | BitPuffin | yeah it can do like traits |
| 22:26:29 | BitPuffin | but not ml modules |
| 22:26:33 | BitPuffin | because ml modules are the shit |
| 22:26:33 | Demos | but how is it useful to take those modules, you need to know that you can call functions on them |
| 22:27:24 | BitPuffin | well you do know that |
| 22:27:38 | BitPuffin | you need to know that a certain collection of functions exist |
| 22:28:02 | BitPuffin | but you don't need to know all of the possible ones |
| 22:28:18 | BitPuffin | if the module that is passed in does not have the function you want it is a static error |
| 22:29:19 | Demos | a object of function pointers would do the same, the converter would not match in overload resolution if you did not have the approperate functions avalible |
| 22:30:10 | BitPuffin | btw I'll get in the vnug soonish |
| 22:30:51 | BitPuffin | the difference is though that you need an object hiearchy |
| 22:30:59 | BitPuffin | so you say I take an object of this type |
| 22:31:11 | BitPuffin | and all the passed in objects need to be that type or inherit from it |
| 22:31:30 | BitPuffin | whereas in ML any module that matches that signarue works with no extra hassle |
| 22:31:34 | BitPuffin | they are more loose |
| 22:32:39 | Demos | no I say you take on object of a type, and that there is a converter that converts from object (with associated "methods") to the object of function pointers |
| 22:32:56 | * | flyx quit (*.net *.split) |
| 22:32:56 | * | q66 quit (*.net *.split) |
| 22:32:57 | * | fowl quit (*.net *.split) |
| 22:32:57 | * | clone1018 quit (*.net *.split) |
| 22:32:58 | * | Zuchto quit (*.net *.split) |
| 22:32:58 | * | Roin quit (*.net *.split) |
| 22:32:59 | * | X-Scale quit (*.net *.split) |
| 22:32:59 | * | Skrylar quit (*.net *.split) |
| 22:32:59 | * | Amrykid quit (*.net *.split) |
| 22:32:59 | * | Araq quit (*.net *.split) |
| 22:33:00 | * | darkfusi1n quit (*.net *.split) |
| 22:33:01 | * | TylerE quit (*.net *.split) |
| 22:33:01 | * | mal`` quit (*.net *.split) |
| 22:33:02 | * | btiffin quit (*.net *.split) |
| 22:33:02 | * | mko quit (*.net *.split) |
| 22:33:02 | * | bjz quit (*.net *.split) |
| 22:33:02 | * | zahary quit (*.net *.split) |
| 22:33:03 | * | BlameStross quit (*.net *.split) |
| 22:33:03 | * | untitaker quit (*.net *.split) |
| 22:33:04 | * | Matthias247 quit (*.net *.split) |
| 22:33:04 | * | xenagi quit (*.net *.split) |
| 22:33:05 | * | betawaffle quit (*.net *.split) |
| 22:33:06 | * | Varriount quit (*.net *.split) |
| 22:33:06 | * | flaviu quit (*.net *.split) |
| 22:33:06 | * | Fr4n quit (*.net *.split) |
| 22:33:06 | * | phI||Ip quit (*.net *.split) |
| 22:33:06 | * | mmatalka quit (*.net *.split) |
| 22:33:06 | * | reloc0 quit (*.net *.split) |
| 22:33:07 | * | comex quit (*.net *.split) |
| 22:33:07 | * | jez0990_ quit (*.net *.split) |
| 22:33:07 | * | oddmunds quit (*.net *.split) |
| 22:33:08 | * | bstrie quit (*.net *.split) |
| 22:33:08 | * | def- quit (*.net *.split) |
| 22:33:08 | * | nande quit (*.net *.split) |
| 22:33:08 | * | brson quit (*.net *.split) |
| 22:33:09 | * | io2_ quit (*.net *.split) |
| 22:33:10 | * | tumak quit (*.net *.split) |
| 22:33:10 | * | reactormonk quit (*.net *.split) |
| 22:33:10 | * | dLog quit (*.net *.split) |
| 22:33:11 | * | boydgreenfield quit (*.net *.split) |
| 22:33:12 | * | lorxu quit (*.net *.split) |
| 22:33:12 | * | Demos quit (*.net *.split) |
| 22:33:12 | * | EXetoC quit (*.net *.split) |
| 22:33:12 | * | Boscop quit (*.net *.split) |
| 22:33:12 | * | milosn quit (*.net *.split) |
| 22:33:12 | * | eigenlicht_ quit (*.net *.split) |
| 22:33:14 | * | BitPuffin quit (*.net *.split) |
| 22:33:14 | * | gsingh93_ quit (*.net *.split) |
| 22:33:15 | * | dom96 quit (*.net *.split) |
| 22:33:15 | * | vendethiel quit (*.net *.split) |
| 22:33:15 | * | rixx quit (*.net *.split) |
| 22:33:15 | * | Raynes quit (*.net *.split) |
| 22:33:16 | * | silven quit (*.net *.split) |
| 22:33:16 | * | Jesin quit (*.net *.split) |
| 22:33:17 | * | nequitans quit (*.net *.split) |
| 22:33:18 | * | superfunc quit (*.net *.split) |
| 22:33:19 | * | OrionPK quit (*.net *.split) |
| 22:33:20 | * | bastian__ quit (*.net *.split) |
| 22:33:21 | * | CARAM_ quit (*.net *.split) |
| 22:33:21 | * | skroll quit (*.net *.split) |
| 22:36:41 | * | JStoker quit (Max SendQ exceeded) |
| 22:36:46 | * | fowl joined #nimrod |
| 22:36:46 | * | Zuchto joined #nimrod |
| 22:36:46 | * | nande joined #nimrod |
| 22:36:46 | * | Matthias247 joined #nimrod |
| 22:36:46 | * | lorxu joined #nimrod |
| 22:36:46 | * | xenagi joined #nimrod |
| 22:36:46 | * | bjz joined #nimrod |
| 22:36:46 | * | zahary joined #nimrod |
| 22:36:46 | * | io2_ joined #nimrod |
| 22:36:46 | * | BitPuffin joined #nimrod |
| 22:36:46 | * | Jesin joined #nimrod |
| 22:36:46 | * | gsingh93_ joined #nimrod |
| 22:36:46 | * | brson joined #nimrod |
| 22:36:46 | * | BlameStross joined #nimrod |
| 22:36:46 | * | superfunc joined #nimrod |
| 22:36:46 | * | Varriount joined #nimrod |
| 22:36:46 | * | flaviu joined #nimrod |
| 22:36:46 | * | Demos joined #nimrod |
| 22:36:46 | * | untitaker joined #nimrod |
| 22:36:46 | * | EXetoC joined #nimrod |
| 22:36:46 | * | Boscop joined #nimrod |
| 22:36:46 | * | btiffin joined #nimrod |
| 22:36:46 | * | mko joined #nimrod |
| 22:36:46 | * | milosn joined #nimrod |
| 22:36:46 | * | Fr4n joined #nimrod |
| 22:36:46 | * | phI||Ip joined #nimrod |
| 22:36:46 | * | tumak joined #nimrod |
| 22:36:46 | * | mmatalka joined #nimrod |
| 22:36:46 | * | reactormonk joined #nimrod |
| 22:36:46 | * | reloc0 joined #nimrod |
| 22:36:46 | * | betawaffle joined #nimrod |
| 22:36:46 | * | eigenlicht_ joined #nimrod |
| 22:36:46 | * | nequitans joined #nimrod |
| 22:36:46 | * | dLog joined #nimrod |
| 22:36:46 | * | dom96 joined #nimrod |
| 22:36:46 | * | vendethiel joined #nimrod |
| 22:36:46 | * | OrionPK joined #nimrod |
| 22:36:46 | * | bstrie joined #nimrod |
| 22:36:46 | * | rixx joined #nimrod |
| 22:36:46 | * | bastian__ joined #nimrod |
| 22:36:46 | * | def- joined #nimrod |
| 22:36:46 | * | oddmunds joined #nimrod |
| 22:36:46 | * | jez0990_ joined #nimrod |
| 22:36:46 | * | comex joined #nimrod |
| 22:36:46 | * | Raynes joined #nimrod |
| 22:36:46 | * | silven joined #nimrod |
| 22:36:46 | * | CARAM_ joined #nimrod |
| 22:36:46 | * | skroll joined #nimrod |
| 22:36:47 | * | Roin joined #nimrod |
| 22:36:47 | * | X-Scale joined #nimrod |
| 22:36:47 | * | Skrylar joined #nimrod |
| 22:36:47 | * | Amrykid joined #nimrod |
| 22:36:47 | * | Araq joined #nimrod |
| 22:36:47 | * | darkfusi1n joined #nimrod |
| 22:36:47 | * | TylerE joined #nimrod |
| 22:36:47 | * | mal`` joined #nimrod |
| 22:36:50 | * | mko quit (Ping timeout: 240 seconds) |
| 22:36:50 | * | X-Scale quit (Ping timeout: 240 seconds) |
| 22:36:51 | * | JStoker joined #nimrod |
| 22:39:54 | * | clone1018 joined #nimrod |
| 22:41:09 | dom96 | 'night |
| 22:42:29 | * | X-Scale joined #nimrod |
| 22:42:48 | bjz | Demos: rust's traits can be used for both static and dynamic dispatch |
| 22:44:10 | bjz | Demos: if you have a value that implements a certain trait, you can box it then cast it to a 'trait object' |
| 22:44:57 | bjz | Demos: this gives you a fat pointer with a reference to the value and a reference to the vtable (I think) |
| 22:45:49 | bjz | http://doc.rust-lang.org/master/tutorial.html#trait-objects-and-dynamic-method-dispatch |
| 22:46:25 | Demos | ah, OK you can do the same in nimrod with typeclasses like I described, good to know you have control over it |
| 22:46:34 | BitPuffin | Demos: and what type does the converter take? |
| 22:46:36 | flaviu | Varriount: Thanks for the sublime text plugin! |
| 22:46:44 | Demos | a typeclass |
| 22:46:46 | BitPuffin | do you have to write a converter for every object type? |
| 22:46:47 | flaviu | Its awesome, and the highlighting actually works well! |
| 22:46:51 | BitPuffin | ah |
| 22:46:52 | bjz | Demos: neat |
| 22:47:01 | BitPuffin | Demos: well the problem is that it's too inflexible |
| 22:47:20 | Demos | not really, with some macros to generate stuff you could be off |
| 22:47:30 | Demos | just as flexible as rust I think |
| 22:47:32 | BitPuffin | I might define in a library a typeclass that is used it many places to create the modules |
| 22:47:36 | BitPuffin | I'm not talking about rust |
| 22:47:40 | * | io2_ quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 22:47:46 | bjz | Demos: there are some interesting papers on unifying type classes with ML-style module systems btw |
| 22:48:08 | Demos | well I would have to learn ML first |
| 22:48:10 | BitPuffin | However if your code takes modules of those typeclasses and only uses a subset of its functions |
| 22:48:36 | BitPuffin | then when you are porting to a foreign platform and want to implement only the methods you use you'd have to write dummy procedures of those typeclasses |
| 22:48:39 | BitPuffin | and that makes me cry |
| 22:49:04 | BitPuffin | either that or modify the typeclass signature |
| 22:49:10 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:49:12 | BitPuffin | for that platform |
| 22:49:14 | BitPuffin | and that is bullshit |
| 22:49:27 | bjz | Demos: http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf |
| 22:49:47 | bjz | Demos: http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf |
| 22:50:36 | bjz | Demos: I'm not sure it has actually been realized in a language yet though |
| 22:51:09 | BitPuffin | bjz: I'll do it |
| 22:51:15 | BitPuffin | you mean what's being said in those papers? |
| 22:51:19 | * | q66 joined #nimrod |
| 22:51:23 | bjz | Demos: I am interested to see what elm does: http://elm-lang.org/blog/announce/0.7.elm#notes-on-expressiveness |
| 22:51:50 | bjz | BitPuffin: yeah, unifying modules and typeclasses into a single language construct |
| 22:52:44 | bjz | BitPuffin: unfortunately Rust went conservative - ie. with the haskell model (albeit using static dispatch as default and allowing you to opt-in to a vtable) |
| 22:53:21 | BitPuffin | bjz: yeah, my current decision is just first class modules but I would be interested in unifying them if it gives me what I need |
| 22:53:54 | bjz | BitPuffin: but I guess there was too much on their plate with all the other interesting things like linear types and regions |
| 22:54:07 | BitPuffin | yeah |
| 22:54:12 | BitPuffin | I'm undecided on linear types |
| 22:54:17 | BitPuffin | I think maybe it should be explicit |
| 22:54:26 | bjz | <3 linear types :) |
| 22:54:30 | BitPuffin | yeah? |
| 22:54:41 | BitPuffin | how so |
| 22:54:47 | bjz | explicit in what way? |
| 22:55:17 | bjz | explicit freeing? That is what ATS does. |
| 22:55:29 | BitPuffin | bjz: no, I mean explicit linearness to variables |
| 22:55:30 | bjz | (in Rust it is implicit) |
| 22:55:42 | BitPuffin | let linear v = ... |
| 22:55:51 | BitPuffin | or let lin |
| 22:55:53 | BitPuffin | would probably be better |
| 22:56:02 | superfunc | Does a linear type just guarantee one referrer at any given time? |
| 22:56:07 | BitPuffin | superfunc: yes |
| 22:56:15 | BitPuffin | superfunc: ones you have used a variable it can't be used anymore |
| 22:56:21 | bjz | lis that not what `let x = box 2;` do? |
| 22:56:40 | BitPuffin | or actually that's how linear types work, in rust they are a little bit more relaxed |
| 22:56:51 | BitPuffin | bjz: no, box something; puts it on the heap |
| 22:56:57 | BitPuffin | which you don't want |
| 22:57:02 | BitPuffin | if you can avoid it |
| 22:57:05 | bjz | ohh wait - yeah |
| 22:57:13 | superfunc | BitPuffin: Is there no way to explicitly move ownership of a linear type? |
| 22:57:19 | BitPuffin | I think you are thinking of taking references |
| 22:57:26 | BitPuffin | superfunc: they are always moved |
| 22:57:31 | bjz | you can have a linear type on the heap - it is linear if it has a destrutor |
| 22:57:38 | bjz | *stack I mean |
| 22:57:47 | BitPuffin | let somevar = 2; somefunc somevar; somevar # error |
| 22:57:53 | bjz | in rust's case that is |
| 22:58:07 | BitPuffin | somevar can not be used after being sent to somefunc |
| 22:58:19 | superfunc | Ok, the way you phrased it before it seemed like the value was inaccessible after the original owner uses it |
| 22:58:43 | BitPuffin | bjz: well does integers have destructors? Because they have the same move semantics |
| 22:59:05 | bjz | BitPuffin: they do have the same move semantics, but they also implicitly copy |
| 22:59:49 | superfunc | Would std::unique_ptr qualify as a linear type then? |
| 22:59:55 | BitPuffin | superfunc: take a look at LinearML |
| 23:00:08 | bjz | superfunc: yes, approximately |
| 23:00:21 | BitPuffin | bjz: yeah, which is kinda strange although it makes sense I guess |
| 23:00:24 | bjz | superfunc: it's just not very well enforced |
| 23:00:25 | BitPuffin | yeah it does |
| 23:00:29 | * | boydgreenfield joined #nimrod |
| 23:00:35 | BitPuffin | nvm :P |
| 23:01:41 | BitPuffin | bjz: move semantics must be a pretty big pain in the bum though when modules are first class values |
| 23:01:58 | bjz | superfunc: the interesting insight when it comes to Rust is that you can combine linear types with regions to get memory safety without GC. it is a combination of ideas from the research world with the things that the C++ folks stumbled on |
| 23:02:24 | bjz | BitPuffin: yeah? |
| 23:03:03 | BitPuffin | bjz: yeah, I mean you can basically only send the module one place and it's gone |
| 23:03:06 | BitPuffin | unless you clone it I guess |
| 23:03:29 | flaviu | Isn't the module immutable? |
| 23:03:39 | flaviu | just pass it by value |
| 23:03:47 | * | bjz does not actually have enough practical experience with first class modules to make much of a comment |
| 23:04:03 | bjz | flaviu: you mean by reference - if it is immutable? |
| 23:05:25 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 23:05:48 | flaviu | Well you could pass it by value, just a tuple of function pointers. However, after thinking a bit more, I think that statically allocating it is best. A module can't change after being compiled. |
| 23:05:59 | bjz | flaviu: sorry, I am embedded in Rust land, where by-val means a linear move, and immutable stuff can be referenced multiple times |
| 23:06:34 | BitPuffin | flaviu: well the whole deal with linear types is that once they are used once they can't be used again |
| 23:06:52 | flaviu | Why should a module be a linear type? |
| 23:06:52 | BitPuffin | that is they sort of flow through the program in a linear fashion |
| 23:06:56 | BitPuffin | not used all over the place |
| 23:07:01 | BitPuffin | flaviu: because it is first class |
| 23:07:04 | BitPuffin | just like an integer |
| 23:07:07 | BitPuffin | or string |
| 23:07:09 | BitPuffin | whatever |
| 23:07:11 | bjz | BitPuffin: if you combine them with regions it would be fine though? |
| 23:07:11 | BitPuffin | :P |
| 23:07:29 | bjz | BitPuffin: as I say - via a reference |
| 23:07:35 | flaviu | BitPuffin: But aren't string literals staticly allocated in some place in memory? |
| 23:07:38 | BitPuffin | bjz: sure |
| 23:07:50 | bjz | flaviu: yep |
| 23:07:51 | BitPuffin | bjz: but then you are sending a pointer essentially aren't you? |
| 23:08:08 | bjz | BitPuffin: to the module, yes |
| 23:08:28 | flaviu | Can you change first class modules at runtime or something? I'm not sure what you'd get out of making them linear |
| 23:08:31 | BitPuffin | bjz: yeah, so you need to dereference twice instead of once |
| 23:08:33 | bjz | BitPuffin: so I guess you get some cost of indirection |
| 23:08:35 | bjz | yep |
| 23:08:41 | BitPuffin | once to the mohdule and one more for the function |
| 23:08:44 | bjz | :( |
| 23:08:59 | bjz | but wouldn't that happen in GC land anyway? |
| 23:09:12 | bjz | also, I wonder if that could be statically optimized away? |
| 23:09:12 | * | darkf joined #nimrod |
| 23:09:39 | bjz | hmm, perhaps not... |
| 23:10:45 | BitPuffin | bjz: my language doesn't have a gc, and neither does rust :P |
| 23:11:01 | bjz | nope |
| 23:11:15 | superfunc | BitPuffin: I'll add it the laughably insurmountable reading stack |
| 23:11:27 | bjz | but yeah - I am talking about for example SML modules |
| 23:11:34 | BitPuffin | bjz: me too |
| 23:11:38 | bjz | wouldn't they also have a double indirection? |
| 23:11:46 | BitPuffin | not necessarily |
| 23:11:56 | BitPuffin | if the pointers in the module are passed by value |
| 23:12:02 | BitPuffin | then you just dereference the address |
| 23:12:46 | BitPuffin | that said I want to have zero indirection |
| 23:12:46 | flaviu | The module will already be in cache in all the cases where it'd make a big difference, I think you should benchmark first and worry later |
| 23:13:05 | BitPuffin | not sure how that would work |
| 23:13:07 | superfunc | bjz: I like the phrase "stumbled upon", its nicer than how most put it |
| 23:13:15 | BitPuffin | flaviu: true |
| 23:13:24 | bjz | superfunc: how do most people put it? |
| 23:14:44 | superfunc | something along the lines of, "...forced into an already bloated language" |
| 23:15:10 | superfunc | not that I agree with it, most of those opinions don't take into account what the committee has to consider |
| 23:15:11 | bjz | eh, I don't care for that slander |
| 23:15:16 | bjz | yeah |
| 23:16:29 | superfunc | Like, "Make it better, but make it work with all the old stuff, and it better be fast as hell" |
| 23:16:59 | bjz | C++ has definitely made a huge contribution to figuring out how to build abstractions in a systems programming context. that said I still thing the writing is on the wall for it, and has been for far too long now |
| 23:17:12 | bjz | yeah, crazy constraints to work under |
| 23:17:23 | bjz | amazing that they can get anything done |
| 23:17:27 | superfunc | I agree. |
| 23:17:38 | * | bjz is not surprised bjarne's hair is falling out |
| 23:18:39 | superfunc | I commend them for making it better, because it will live on for 20 years in terms of people maintaining legacy systems. But I am glad the new group of sys. languages are giving a transition path away from it |
| 23:20:26 | * | bjz is excited about the next generation beyond this current new group |
| 23:20:46 | bjz | so much awesomeness still to come |
| 23:20:46 | BitPuffin | superfunc: well I'll never take the approach of "but make it work with all the old stuff". It is fundamentally wrong |
| 23:22:45 | bjz | BitPuffin: A language is built on a community and an ecosystem. People expect stuff to keep working. If you break stuff too much in the quest for perfection your language will forever be relegated to the sidelines. |
| 23:23:12 | flaviu | bjz: If the language has powerful AST transformation tools, no, not really. |
| 23:23:24 | bjz | flaviu: that is one solution |
| 23:23:28 | superfunc | bjz: Me too |
| 23:23:50 | bjz | flaviu: Go has done a good job in that regard |
| 23:24:51 | BitPuffin | bjz: well I'm not looking to build a community at all |
| 23:25:01 | bjz | BitPuffin: then thats fine |
| 23:25:10 | BitPuffin | bjz: also if I ever did I would probably work hard on having a tool that helps migrating |
| 23:25:26 | bjz | BitPuffin: it depends on your priorities - and one size doesn't fit all |
| 23:25:45 | BitPuffin | bjz: but yeah I'm basically trying to make "perfect for me" |
| 23:25:51 | superfunc | At least I won't seem as young with these new languages. At C++ meetups, I'm always 20 years below everyone |
| 23:26:42 | BitPuffin | lol |
| 23:27:02 | BitPuffin | you'll feel old instead |
| 23:28:29 | superfunc | Finally |
| 23:31:19 | NimBot | Araq/Nimrod devel 82fc908 def [+0 ±1 -0]: Export FileInfo object |
| 23:31:19 | NimBot | Araq/Nimrod devel 09d67d9 Varriount [+0 ±1 -0]: Merge pull request #1347 from def-/export-fileinfo... 2 more lines |
| 23:31:31 | Demos | I feel like I know far too much about c++. There is a lot of overhead in c++ to avoid all the design traps it sets for you |
| 23:31:40 | Demos | I kinda like C better in a lot of ways |
| 23:32:23 | BitPuffin | Demos: agreed |
| 23:32:25 | BitPuffin | that said |
| 23:32:29 | BitPuffin | the best thing you can do is write C in C++ |
| 23:32:38 | BitPuffin | so that you at least can do some things easier |
| 23:33:02 | Demos | but at the same time it is nice writing C that will be portable to anything |
| 23:33:12 | Demos | it is between ANSI C and C in C++ |
| 23:33:25 | superfunc | I disagree with that, mostly. I think C++ offers too many valuable abstractions for me to pass up. |
| 23:33:28 | Demos | honestly C with modules may have prevented me from coming to nimrod |
| 23:33:40 | EXetoC | :E |
| 23:34:09 | Demos | superfunc, right, but there is no easy way to go from not using the abstractions to using them, you have to just write the abstraction from the get go, which is really hard |
| 23:34:30 | superfunc | That's fair |
| 23:34:32 | flaviu | Demos: Its pretty easy if you don't care about readability |
| 23:34:48 | BitPuffin | Demos: C with modules is not ansi C though |
| 23:34:48 | superfunc | Much of it is more readable now |
| 23:34:54 | BitPuffin | and ansi C is pretty annoying |
| 23:35:06 | flaviu | Demos: NM, I read it backwards |
| 23:35:07 | Demos | I mean tbh, I don't like member functions, C++ fucks up the template syntax pretty bad, I dont like classes, I dont like IO streams, I dont like boost, I dont like iterators all that much. |
| 23:35:07 | BitPuffin | like you can't even put variable declarations between statements XD |
| 23:35:21 | Demos | so I pretty much end up avoiding most of C++ |
| 23:35:35 | BitPuffin | Demos: yeah I pretty much use C++ as "C with templates" |
| 23:35:51 | BitPuffin | so that I can write like some funky data structure that can be re-used |
| 23:35:52 | Demos | Templates are easy to get wrong as well |
| 23:36:00 | BitPuffin | that is correct |
| 23:36:00 | Demos | esp if you want the member functions syntax with them |
| 23:36:07 | BitPuffin | but it's harder to go wrong that doing it with macros :P |
| 23:36:10 | Demos | but for containers, ofc templates are great |
| 23:36:24 | Demos | well nimrod's generics are eaiser |
| 23:36:37 | superfunc | Yes ^ |
| 23:36:55 | BitPuffin | not really |
| 23:36:56 | Demos | the trouble with c++ templates is that in a lot of cases you have to use inheratance to reuse code in partial specializations |
| 23:36:58 | BitPuffin | it's basically the same |
| 23:36:58 | Demos | and it is annoying |
| 23:37:05 | Demos | well one of the troubles |
| 23:37:12 | BitPuffin | except right now you can do more in C++ |
| 23:37:30 | Demos | yeah statics need to be fixed |
| 23:37:44 | Demos | well I could not do my entity system macros in c++ |
| 23:37:44 | BitPuffin | or replaced |
| 23:37:54 | Demos | or maybe I could but they would be C macros |
| 23:38:01 | BitPuffin | well really fuck generics and all that shit, dependent types is where it is at |
| 23:38:03 | Demos | replaced with what? |
| 23:38:13 | BitPuffin | Demos: dependent types |
| 23:38:23 | BitPuffin | it's basically the perfect thing for linear algebra libs |
| 23:38:25 | Demos | I was under the impression that dependent types were far too hard to get working in a useful language |
| 23:38:33 | superfunc | BitPuffin: lol |
| 23:38:48 | BitPuffin | Demos: pff |
| 23:38:58 | BitPuffin | Demos: http://www.idris-lang.org/ |
| 23:39:46 | superfunc | I met the creator of agda a few weeks back, they are def. possible |
| 23:40:14 | Demos | the bigger issue is that I dont really understand how dependent types work all that well. This is likely a problem on my end. Still static[T] is a really simple concept |
| 23:41:13 | def- | What's the easiest way to create a cstring of some size? |
| 23:41:24 | BitPuffin | Demos: well I'm reading up on it, because when I saw them I was like holy tits this is exactly what I've been searching for |
| 23:41:27 | flaviu | newString(n).cstring |
| 23:41:33 | def- | thanks flaviu |
| 23:42:35 | Demos | I guess the other problem is that I am not used to the haskell style syntax everyone uses |
| 23:42:41 | Demos | also a stupid problem |
| 23:43:10 | BitPuffin | Demos: you get used to it |
| 23:43:23 | Demos | but I don't understand how dependent types can always work at compile time |
| 23:44:07 | BitPuffin | that's the part I want and need to know |
| 23:44:16 | BitPuffin | I see immediately and understand how to use them |
| 23:44:28 | BitPuffin | but I wonder what the fuck kind of black magic is needed to do that |
| 23:44:38 | flaviu | Lots and lots of assertions? |
| 23:45:11 | * | lorxu quit (Remote host closed the connection) |
| 23:45:24 | BitPuffin | I guess it's the type erasure part that confuses me |
| 23:45:42 | flaviu | Wasn't Araq working on a limited version of dependent types? |
| 23:47:12 | BitPuffin | dunno |
| 23:47:23 | BitPuffin | Demos: I'll be on in approx 10 min |
| 23:47:32 | BitPuffin | well maybe |
| 23:47:35 | * | mko joined #nimrod |
| 23:57:51 | superfunc | I gotta take off. Later guys |
| 23:58:16 | bjz | Demos: Haskell syntax is just so nice - would recommend learning it |
| 23:58:46 | * | superfunc quit (Quit: leaving) |
| 23:59:01 | bjz | Demos: I don't really use haskell all that much, but it's so much easier to throw stuff up on a whiteboard in the haskell notation |
| 23:59:35 | Demos | yeah, I learned haskell for a bit, was kinda fun but doing utilities with lots of IO and internets stuff was a pain |
| 23:59:59 | BitPuffin | Demos: yau'd probably enjoy ocaml then |
