| 00:00:07 | Araq | just edit vmdeps.nim |
| 00:00:09 | Jehan_ | I can easily add a "\n" after each line, but that would work differently from one-liners for now. |
| 00:00:38 | Jehan_ | Oh, hmm, I was looking at evalStaticExec. |
| 00:00:55 | Araq | just add \n after each line but don't for the last line |
| 00:01:32 | Jehan_ | Do I also have to do the same in evals.nim for evalStaticExec? |
| 00:01:45 | Araq | evals.nim is a dead module |
| 00:02:25 | Jehan_ | I see. |
| 00:04:20 | * | brson quit (Quit: leaving) |
| 00:04:49 | superfunc | Hmm, does a for loop through a sequence copy the elements by default? |
| 00:04:52 | * | brson joined #nimrod |
| 00:09:00 | * | superfunc quit (Quit: leaving) |
| 00:09:15 | * | superfunc joined #nimrod |
| 00:09:21 | superfunc | sorry, connection is awful in this place. |
| 00:09:41 | Araq | superfunc: yes, use mitems if you don't want that |
| 00:09:57 | Araq | if mitems has made it into system yet |
| 00:11:05 | Jehan_ | Araq: PR submitted. |
| 00:11:17 | Araq | thanks |
| 00:12:22 | Araq | er |
| 00:12:33 | Araq | does this work when the program produces no output at all? |
| 00:13:01 | Araq | not sure if output.readLine then blocks forever |
| 00:13:30 | Jehan_ | Oops. |
| 00:13:35 | Jehan_ | My bad. |
| 00:13:37 | * | askatasuna quit (Ping timeout: 244 seconds) |
| 00:13:39 | Jehan_ | Will fix and resubmit. |
| 00:13:39 | superfunc | If the object is 'var', should the for syntax go to mitems by default? |
| 00:13:46 | Jehan_ | That's the one case I didn't test. |
| 00:14:04 | superfunc | I mean in the case of an object with holds a sequence as a member |
| 00:14:22 | Araq | I'd simply use result.setLen(result.len - "\n".len) to stip the final \n |
| 00:14:51 | Araq | superfunc: no, we all like the default 'items' |
| 00:15:13 | Araq | if you need something else, write it explicitly |
| 00:15:29 | Jehan_ | Araq: That'll also break with an empty output? |
| 00:15:54 | Araq | I think setLen can deal with negative numbers just fine |
| 00:16:16 | * | shodan45 quit (Quit: Konversation terminated!) |
| 00:18:06 | Araq | negative numbers are a great achievement of civilization and "unsigned" is from hell :-) |
| 00:18:17 | Jehan_ | Araq: Umm, not sure I want to rely on that. |
| 00:18:52 | superfunc | Fair enough, its probably a bad precedent to set. |
| 00:21:41 | * | OrionPK quit (Remote host closed the connection) |
| 00:24:50 | * | OrionPK joined #nimrod |
| 00:24:53 | Jehan_ | Araq: updated accordingly. I decided, what the heck, if setLen does get changed at some point, there's probably a lot more that's going to break. :) |
| 00:25:49 | NimBot | Araq/Nimrod devel 672e724 Reimer Behrends [+0 ±1 -0]: Fixed gorge/staticExec to not strip newlines. |
| 00:25:49 | NimBot | Araq/Nimrod devel 989bf5f Andreas Rumpf [+0 ±1 -0]: Merge pull request #1295 from rbehrends/fix-staticexec... 2 more lines |
| 00:26:57 | superfunc | I don't have much knowledge on it, Araq, could you brielf explain your disdain for unsigned? |
| 00:27:26 | Araq | superfunc: argh not again |
| 00:27:46 | superfunc | lol |
| 00:27:47 | Araq | in a nutshell: it breaks the precious minus operator |
| 00:29:19 | goobles | i love unsigned |
| 00:29:25 | goobles | ALWAYS |
| 00:29:33 | superfunc | bye goobles, we'll miss you |
| 00:29:39 | goobles | :( |
| 00:29:40 | Jehan_ | superfunc: This is one of the things that Araq and Bjarne Stroustrup agree on. :) |
| 00:30:02 | superfunc | jk, tell your friends of the gospel of nimrod |
| 00:30:21 | goobles | i love my extra bit of positiveness |
| 00:30:26 | Araq | goobles: for (int i = 0; i < str.size() - 3; ++i) // oops |
| 00:30:26 | Jehan_ | Quote: "Using an unsigned instead of an int to gain one more bit to represent positive integers is almost never a good idea." |
| 00:30:31 | superfunc | I've been talking it up to a bunch of PhDs who will only write in Haskell and Coq |
| 00:30:43 | superfunc | and maybe Agda |
| 00:30:57 | goobles | for (int i = 0; i < str.size() - 3; ++i) // <-- raw loops ewww |
| 00:31:07 | Jehan_ | superfunc: I'm not sure Nimrod is a competitor for fans of Haskell and Coq. |
| 00:31:16 | superfunc | Jehan_: Hence the trolling |
| 00:32:12 | Jehan_ | That said, I work with mathematicians, and Haskell isn't exactly popular with them, either. |
| 00:32:19 | Jehan_ | Coq's a different story. |
| 00:33:04 | Jehan_ | But many of them find Haskell's model too constraining for practical programming and the type system too limited for stuff that they like Coq for. |
| 00:33:07 | superfunc | Coq is interesting, one of the people I met is using it to verify Rust's type system |
| 00:33:28 | flaviu | I find it hard to say Coq seriously |
| 00:33:59 | superfunc | flaviu: I've heard Coq at least 500 times this week, so I'm used to it, but yeah, I almost lost it at first |
| 00:34:00 | Jehan_ | flaviu: That's because you're not French. |
| 00:34:31 | Jehan_ | I'm pretty sure that a lot of English speakers mispronounce "koch", too. |
| 00:35:10 | goobles | Araq: msvc response to your code |
| 00:35:11 | goobles | error C2220: warning treated as error - no 'object' file generated warning C4018: '<' : signed/unsigned mismatch |
| 00:35:18 | goobles | no compiles;0 |
| 00:35:32 | Araq | goobles: and yet it should compile |
| 00:35:36 | flaviu | Looks like "Koch", but I think wikipedia's fancy symbols say its pronounced "coke"? |
| 00:35:47 | goobles | not if you set warning level to level 4/warnings as errors |
| 00:35:58 | Araq | making size() return 'unsigned' is just braindead |
| 00:36:23 | Araq | it should compile and loop the right number of iterations, goobles |
| 00:36:38 | Jehan_ | goobles: Just make i unsigned. |
| 00:36:54 | Jehan_ | Then it should compile. |
| 00:37:15 | goobles | well then u clearly wanted to loop for a really long time |
| 00:37:19 | goobles | so its all good |
| 00:37:38 | flaviu | goobles: I think it was `--passc:\w` |
| 00:37:44 | Jehan_ | The problem is that underflow can occur pretty easily by accident. |
| 00:37:49 | superfunc | I gotta get back to the uni where they dont believe in proper wifi. Later everyone |
| 00:38:13 | Jehan_ | A similar example is to test whether a divides b. |
| 00:38:34 | Jehan_ | Sorry, if a is congruent to b modulo m. |
| 00:38:49 | Jehan_ | if ( (a - b) % m == 0) ... |
| 00:39:03 | Jehan_ | blows up for unsigned integers, unless m is a power of 2. |
| 00:39:50 | * | superfunc quit (Quit: leaving) |
| 00:40:01 | goobles | if blows up if you underflow? |
| 00:40:46 | Araq | goobles: the C guys confused 'unsigned' with 'natural' and it stuck |
| 00:41:31 | Jehan_ | goobles: There is no such thing as underflow for unsigned ints in C, they wrap around. |
| 00:41:51 | goobles | i know they wrap, didn't know it wasn't called underflow |
| 00:42:28 | Jehan_ | Terminology question, but basically, yes. |
| 00:42:53 | Jehan_ | Because you're doing arithmetic in Z_{2^k}. |
| 00:49:48 | * | Jehan_ quit (Quit: Leaving) |
| 00:58:34 | * | goobles quit (Ping timeout: 246 seconds) |
| 00:59:04 | * | goobles joined #nimrod |
| 00:59:43 | goobles | chrome crashed guess they used unsigned HU |
| 01:48:31 | * | brihat joined #nimrod |
| 02:02:05 | * | gsingh93_ joined #nimrod |
| 02:24:17 | * | q66 quit (Quit: Leaving) |
| 02:48:20 | * | brson quit (Quit: leaving) |
| 03:04:28 | * | joelmo quit (Quit: Connection closed for inactivity) |
| 03:23:14 | * | BitPuffin quit (Ping timeout: 244 seconds) |
| 03:32:47 | * | hoverbear joined #nimrod |
| 04:04:05 | flaviu | I think everyone is asleep, but if someone isn't, I'd like to know how I can copy a value into a pointer |
| 04:04:06 | flaviu | I've tried memcpy, but I think that also brings along some bookkeeping fields somehow |
| 04:08:48 | flaviu | nm, my fault. I was taking a pointer of a pointer |
| 04:13:02 | * | flaviu quit (Ping timeout: 240 seconds) |
| 04:33:41 | * | Jesin quit (Excess Flood) |
| 04:34:12 | * | Jesin joined #nimrod |
| 06:10:26 | * | Varriount|Deskto joined #nimrod |
| 06:12:03 | * | Raynes quit (Ping timeout: 240 seconds) |
| 06:12:03 | * | Skrylar quit (Ping timeout: 240 seconds) |
| 06:12:31 | * | Raynes joined #nimrod |
| 06:13:33 | * | Varriount quit (Ping timeout: 240 seconds) |
| 06:29:06 | * | hoverbear quit () |
| 08:02:03 | * | joelmo joined #nimrod |
| 08:26:09 | * | Varriount|Deskto is now known as Varriount |
| 08:37:40 | * | kemet joined #nimrod |
| 08:51:40 | * | BitPuffin joined #nimrod |
| 09:21:41 | * | kemet quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) |
| 09:39:29 | * | gsingh93_ quit (Quit: Connection closed for inactivity) |
| 10:49:15 | flyx | what's happening when I get "lib/pure/collections/sets.nim(1, 1) Error: redefinition of 'sets'"? |
| 10:49:35 | flyx | I don't see any definition of "sets" in my code |
| 10:50:11 | flyx | this shouldn't happen just because I imports "sets" in multiple files, should it? |
| 10:55:29 | dom96 | did you name one of your modules 'sets'? |
| 10:58:43 | * | Trustable joined #nimrod |
| 11:08:25 | flyx | dom96: no. I got it, I included one of my files twice |
| 11:09:30 | flyx | I have a curious problem that I get a SIGSEGV when trying to add stuff to a string |
| 11:09:54 | flyx | the string seems fine, I get execute len() on it, but I cannot add anything |
| 11:09:56 | flyx | *can |
| 11:10:19 | dom96 | Did you initialise it? |
| 11:10:25 | flyx | yes. |
| 11:10:41 | dom96 | then maybe what you are trying to add is nil |
| 11:11:33 | flyx | when I change add to myString = myString & val, it works |
| 11:11:39 | flyx | instead of myString.add(val) |
| 11:12:07 | Araq | let me guess |
| 11:12:14 | Araq | you're doing it all at compile-time |
| 11:12:25 | flyx | jup |
| 11:12:30 | Araq | bug report please |
| 11:12:38 | flyx | on it |
| 11:13:29 | Araq | I wonder if I'll get this VM stable ... |
| 11:13:55 | Araq | or if somebody else will ever be able to fix bugs in it |
| 11:15:16 | * | goobles quit (Ping timeout: 246 seconds) |
| 11:20:21 | * | q66 joined #nimrod |
| 11:21:35 | flyx | done. https://github.com/Araq/Nimrod/issues/1297 |
| 11:22:41 | Araq | ah nice |
| 11:22:52 | Araq | you reduced it to a simple test case |
| 11:23:25 | flyx | well I'm trying my best to help fixing it ;) |
| 11:29:05 | Varriount | <3 Standalone test cases. |
| 11:31:29 | Araq | dom96: btw your "fix" for 'high' for the JS backend is wrong |
| 11:31:35 | Araq | see gradha's bug report |
| 11:36:16 | dom96 | I never "fixed" 'high' |
| 11:36:20 | dom96 | only setLen IIRC |
| 11:37:16 | Araq | hmm I thought you did |
| 12:00:00 | * | XAMPP-8 joined #nimrod |
| 12:00:13 | * | XAMPP-8 quit (Read error: Connection reset by peer) |
| 12:21:36 | * | untitaker quit (Ping timeout: 244 seconds) |
| 12:26:45 | * | untitaker joined #nimrod |
| 12:31:25 | * | shevy quit (Ping timeout: 244 seconds) |
| 12:35:46 | * | shevy joined #nimrod |
| 12:44:35 | * | darkf quit (Quit: Leaving) |
| 12:47:29 | * | shevy quit (Ping timeout: 272 seconds) |
| 12:47:46 | * | shevy joined #nimrod |
| 12:56:02 | * | shevy quit (Ping timeout: 245 seconds) |
| 12:56:27 | * | noam quit (Ping timeout: 245 seconds) |
| 12:56:59 | * | kunev joined #nimrod |
| 13:01:31 | * | shevy joined #nimrod |
| 13:11:43 | * | flaviu joined #nimrod |
| 13:13:24 | BitPuffin | maybe whoever made that command line parsing lib should look at Core.Command for inspiration on how to make it more complete |
| 13:14:39 | flaviu | I can't take the address of something allocated on the stack, I assume thats a missing feature? |
| 13:15:11 | BitPuffin | maybe it's intentional |
| 13:15:14 | BitPuffin | why do you wanna do it? |
| 13:16:07 | flaviu | BitPuffin: https://gist.github.com/9af6abe9010ea10ff961 |
| 13:17:25 | BitPuffin | new(result) |
| 13:17:33 | BitPuffin | you are calling new on something that isn't a ref? |
| 13:17:42 | flaviu | No, result is a ref T |
| 13:17:49 | BitPuffin | oh, right |
| 13:17:51 | BitPuffin | lol |
| 13:18:53 | BitPuffin | well still, why do you want to do this? |
| 13:19:23 | BitPuffin | for gits and shiggles? |
| 13:19:47 | flaviu | So I can get rid of the emit on line 8 |
| 13:20:00 | BitPuffin | so this is your workaround? |
| 13:20:41 | flaviu | Yep, my workaround is to write it in C |
| 13:21:26 | BitPuffin | good times |
| 13:23:48 | flaviu | Also, if I rename it to `new`, the semantic checking recurses infinitely, although it does make sense why it'd do that] |
| 13:24:09 | BitPuffin | hm |
| 13:24:14 | BitPuffin | create an issue? |
| 13:24:49 | dom96 | I don't get why you need to emit that |
| 13:25:07 | BitPuffin | because it doesn't work if he writes it in nimrod dom96 |
| 13:25:56 | dom96 | ahh, you probably can't take the address of a param |
| 13:26:08 | dom96 | I'm quite certain that is intentional. |
| 13:26:39 | dom96 | Just write: var dummy = obj |
| 13:26:43 | dom96 | and then take the address of dummy |
| 13:27:18 | BitPuffin | either that or take a var parameter right? |
| 13:27:41 | flaviu | dom96: Nope |
| 13:27:44 | dom96 | yeah, but he can't take a var param |
| 13:27:53 | flaviu | BitPuffin: I don't want to take a var param |
| 13:27:57 | BitPuffin | dom96: neither can your mom |
| 13:27:57 | dom96 | flaviu: why? |
| 13:28:17 | BitPuffin | flaviu: var god gör det ändå |
| 13:28:18 | flaviu | That means the user has to do `var myvalue: T; new myvalue` |
| 13:28:26 | flaviu | and we're back where we've started |
| 13:28:38 | BitPuffin | no |
| 13:28:50 | dom96 | what BitPuffin said |
| 13:28:53 | flaviu | dom96: Oh, I have to make it var |
| 13:28:57 | BitPuffin | dom96: no? lol |
| 13:29:07 | BitPuffin | or what did I say |
| 13:29:12 | dom96 | yes |
| 13:29:35 | BitPuffin | so instead of typing "no" you saved time by saying "what bitpuffin said" xD |
| 13:29:48 | BitPuffin | little shit |
| 13:29:50 | dom96 | :P |
| 13:29:53 | BitPuffin | lying, even, some would say |
| 13:30:00 | dom96 | It wasn't meant to save time. |
| 13:30:19 | BitPuffin | no it was meant to be a bro I gotcha son |
| 13:30:30 | dom96 | yea |
| 13:37:07 | flaviu | I doubt anything will be as clear as C, I'll just keep that |
| 13:40:28 | dom96 | This is much clearer IMO: https://gist.github.com/dom96/51dfb4cfd341958985c8 |
| 13:40:59 | flaviu | I'm really really not a fan of [] for derefrencing |
| 13:41:20 | dom96 | Still better than emitting C. |
| 13:42:00 | dom96 | You could also probably use this: http://build.nimrod-lang.org/docs/typeinfo.html |
| 13:42:13 | flaviu | IMO the emitted C is clearer |
| 13:42:22 | flaviu | Why would I want to use typeinfo? |
| 13:42:32 | BitPuffin | yeah dom96's version is much better |
| 13:42:54 | flaviu | I don't really care about types, all I care about is that bytes move from obj to result |
| 13:43:02 | dom96 | You could loop through each field of the object and set it in your new ref object. |
| 13:43:11 | dom96 | But meh. |
| 13:43:23 | BitPuffin | dom96's version has better guarantees with GC |
| 13:43:45 | flaviu | I don't think the performance of that is going to be very good, thanks for the suggestion though I guess |
| 13:44:48 | BitPuffin | why are you even doing this |
| 13:45:46 | flaviu | dom96's version does a fieldwise copy of obj |
| 13:46:06 | BitPuffin | well I mean why do you want this function |
| 13:46:45 | flaviu | BitPuffin: Because I think that having to do `type PMyThing = ref TMyThing; PMyThing(a: 1, b:"23")` is ridiculous |
| 13:47:39 | BitPuffin | well that's a pretty common nimrod idiom |
| 13:47:48 | dom96 | type PMyThing = ref object ... ? |
| 13:47:49 | BitPuffin | don't be such a rebel |
| 13:48:07 | BitPuffin | yeah |
| 13:48:09 | dom96 | You can do that you know. |
| 13:48:11 | BitPuffin | you don't have to have a stack version |
| 13:48:26 | BitPuffin | although if you can use something on the stack you should |
| 13:48:26 | flaviu | BitPuffin: Its a common idiom that many don't really like |
| 13:48:37 | BitPuffin | so? |
| 13:48:37 | flaviu | dom96: I know, but I want both stack and heap allocation |
| 13:49:34 | BitPuffin | it's how it's meant to be used |
| 13:49:57 | dom96 | if he wants to do it let him do it |
| 13:50:00 | BitPuffin | sure |
| 13:50:04 | BitPuffin | I'm not forcing him not to |
| 13:50:13 | BitPuffin | I'm just saying there is value in following convention |
| 13:50:33 | flaviu | There is also value in _changing_ convention |
| 13:52:41 | BitPuffin | yeah, it's called making your own language :P |
| 13:52:49 | BitPuffin | otherwise you will have a split community |
| 13:54:35 | flaviu | Do people actually like the P and T prefixes? |
| 13:55:05 | BitPuffin | yeah |
| 13:55:30 | BitPuffin | they tell you if a type is on the stack or on the heap without having to look at the definition |
| 13:55:37 | BitPuffin | I think that's valuable |
| 13:55:59 | flaviu | `ref MyType` gives you the same information |
| 13:56:36 | BitPuffin | sure |
| 13:56:51 | BitPuffin | but it's 2 words or something I dunno |
| 13:56:54 | BitPuffin | I don't mind eihter |
| 13:57:14 | BitPuffin | I probably prefer ref Type |
| 13:57:21 | BitPuffin | but PType is nimrod convention so hey |
| 13:57:34 | BitPuffin | to quote NA "shut up slave!" |
| 14:02:58 | flaviu | Since nimrod convention is being changed to get rid of P and T, then why not change it a bit more to use my awesome new statement? |
| 14:03:55 | dom96 | Araq will allow (ref T)(a: blah) in the future |
| 14:04:38 | flaviu | I think my method looks much better: new T(a : blah) |
| 14:05:24 | BitPuffin | dom96: that looks like C typecast lol |
| 14:06:34 | dom96 | flaviu: Yeah. Suggest it to Araq. |
| 14:07:24 | dom96 | flaviu: But that kind of makes things confusing. What would 'new PType()' do? |
| 14:08:11 | dom96 | Not having the 'new' would suggest stack allocation when in fact it could be allocated on the heap if the type used is a 'ref' |
| 14:09:32 | BitPuffin | dom96: compile time error |
| 14:09:43 | BitPuffin | we can't have ref ref's can we? |
| 14:10:11 | flaviu | dom96: Easy. It would allocate a pointer on the heap |
| 14:10:38 | BitPuffin | flaviu: also you could probably get even better performance by making it a macro instead of a function |
| 14:10:41 | dom96 | flaviu: So a ptr ref T? |
| 14:10:48 | BitPuffin | constructing it on the stack to copy over to the heap is wasteful |
| 14:10:51 | flaviu | dom96: No, a ref ref T |
| 14:10:53 | BitPuffin | make it go directly to heap son |
| 14:10:57 | flaviu | Everything is traced |
| 14:11:01 | flaviu | BitPuffin: I know |
| 14:11:11 | BitPuffin | is ref ref allowed? |
| 14:11:13 | BitPuffin | wtf |
| 14:11:25 | dom96 | I don't think so. |
| 14:11:38 | flaviu | Yes, it is |
| 14:12:08 | dom96 | Anyway, the bigger problem is the assumption that people will definitely learn that the lack 'new' means the object is allocated on the stack. |
| 14:12:33 | flaviu | dom96: Get rid of `ref object` |
| 14:12:51 | dom96 | flaviu: lol. Good luck convincing Araq to do that. |
| 14:13:28 | BitPuffin | yeah |
| 14:13:35 | BitPuffin | you just want to watch the world burn |
| 14:13:58 | dom96 | Letting the user decide whether to allocate on the stack or the heap will cause a lot of breakage in the stdlib I think. |
| 14:14:00 | BitPuffin | Araq is pretty unwilling to break backwards compatibility, even with small things that are ugly |
| 14:14:10 | BitPuffin | imagine breaking every nimrod codebase on the planet |
| 14:14:19 | dom96 | ... yeah lol |
| 14:14:48 | BitPuffin | breaking backwards compatibility is good |
| 14:14:52 | BitPuffin | don't know why people are so scared |
| 14:14:59 | BitPuffin | as long as you provide a tool to help cope |
| 14:15:04 | BitPuffin | doesn't Go do that? |
| 14:15:30 | dom96 | Yeah, because we're just sitting bored. Looking for stuff to do! |
| 14:17:11 | dom96 | Araq has a good reason for not breaking backwards compatibility. |
| 14:17:15 | flaviu | dom96: Ok, so don't give the user the option to decide whether to use the stack or not. Give him a constructor, and get the constructor to take care of it |
| 14:18:55 | BitPuffin | dom96: no he doesn't |
| 14:19:25 | dom96 | BitPuffin: He does. If he breaks backwards compatibility he will have to deal with breaking code in the compiler. |
| 14:19:28 | dom96 | Which takes time to correct. |
| 14:19:40 | BitPuffin | dom96: just tell people what changed and if they have iq > 10 they can fix it with sed |
| 14:19:52 | BitPuffin | dom96: tough shit |
| 14:19:56 | BitPuffin | not a good reason |
| 14:20:23 | flaviu | BitPuffin: Not in this case. You need to have an AST to fix this breaking change |
| 14:21:06 | BitPuffin | flaviu: well the point is, you can fix it pretty quickly even without an ast |
| 14:21:18 | flaviu | But I guess you're somewhat right, specific cases can be fixed with find replace since there aren't many types |
| 14:21:35 | BitPuffin | you can check each replace before doing it for example |
| 14:24:04 | BitPuffin | dom96: plus, most of the time he's refusing to change things in the stdlib as well |
| 14:24:33 | dom96 | The compiler uses the stdlib :P |
| 14:24:48 | BitPuffin | not hard to correct though |
| 14:26:32 | flaviu | If it gets changed, I'd be willing to do the grunt work of updating everything. That's just a crap argument against changing things. |
| 14:28:16 | * | noam joined #nimrod |
| 14:28:45 | BitPuffin | I agree |
| 14:28:51 | BitPuffin | especially when you are not even 1.0 yet |
| 14:28:56 | BitPuffin | but even then it's a bad argument |
| 14:29:20 | BitPuffin | it's like great, you started off with ugliness |
| 14:39:58 | dom96 | Perhaps. Araq probably has better arguments than me. |
| 14:41:49 | BitPuffin | meh |
| 14:44:39 | * | Jehan_ joined #nimrod |
| 14:49:26 | Jehan_ | I guess it's better when your computer breaks three weeks before the warranty ends rather than three weeks after. :) |
| 14:55:41 | * | kunev quit (Quit: leaving) |
| 15:08:00 | dom96 | Jehan_: oh dear, how did it break? |
| 15:08:20 | Jehan_ | One of the graphic cards is on the fritz, apparently. |
| 15:08:50 | dom96 | that sucks |
| 15:08:53 | Jehan_ | It's still working if I don't use that, but if I don't have it repaired, it'll eventually affect the logic board, too. |
| 15:09:02 | Jehan_ | Eh, there are bigger problems in life. :) |
| 15:09:23 | Jehan_ | Luckily, I have Applecare until middle of next month. |
| 15:10:30 | Jehan_ | That laptop was oddly cursed, anyway. First, the trackpad stopped functioning, then the battery turned out to be defective, and now this. |
| 15:11:18 | Jehan_ | I suspect that it may have been part of a bad batch. |
| 15:14:30 | * | hoverbear joined #nimrod |
| 15:22:18 | * | exirctest joined #nimrod |
| 15:25:49 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 15:27:10 | * | kunev joined #nimrod |
| 15:34:17 | * | io2 joined #nimrod |
| 15:42:34 | * | hoverbear quit () |
| 15:43:20 | OrionPK | mornin |
| 15:45:47 | dom96 | afternoon |
| 15:49:04 | flaviu | python doesn't really have any functional methods |
| 15:49:35 | flaviu | I want to do select, but nope |
| 15:51:10 | Trixar_za | Don't even get me started on Python 3 |
| 15:51:24 | flaviu | lol ok |
| 15:51:46 | Trixar_za | Yes, adding less abstraction is good for programmers, but it needlessly complicates it for newbies |
| 15:52:23 | Trixar_za | Transform b'' to proper strings without me having to decode it :| |
| 15:58:20 | Trixar_za | But yeah, some parts I like, most parts I hate |
| 15:58:42 | Trixar_za | Getting into using str format for example |
| 16:05:33 | shevy | if you hate python 3 then you hate the future man |
| 16:06:11 | BitPuffin | Python 2 fappers are pathetic |
| 16:06:13 | * | BitPuffin runs |
| 16:07:01 | * | OrionPK quit (Remote host closed the connection) |
| 16:09:11 | * | OrionPK joined #nimrod |
| 16:10:48 | * | KevinKelley joined #nimrod |
| 16:11:29 | KevinKelley | So I'm needing some tricks for debugging dynlib loading. |
| 16:12:07 | KevinKelley | I'm wrapping the bgfx library, which is mostly C++ but has a C99 api exported. |
| 16:12:17 | * | flaviu quit (Ping timeout: 245 seconds) |
| 16:12:40 | KevinKelley | All I get is, "could not load: libbgfx.so" |
| 16:13:05 | KevinKelley | no explanation of why. No idea where the error occurred. |
| 16:14:52 | Jehan_ | Dynamic libraries are loaded using dlopen(). |
| 16:16:56 | Jehan_ | I'd suspect that dlopen() couldn't find the library. |
| 16:17:31 | KevinKelley | How does that tie in with the '{.importc: "bgfx_init", dynlib: "libbgfx.so".} syntax? I can't tell where the errors are... why it isn't working. |
| 16:17:38 | Jehan_ | Depending on your system, it may be in a directory that the dynamic loader consults, in LD_LIBRARY_PATH, etc. |
| 16:19:04 | KevinKelley | Does the dlopen work with libs in arbitray locations, or does it have to be in system dirs (on the LD_LIB_PATH)? |
| 16:19:50 | Jehan_ | Depends on the system. I'm honestly a bit fuzzy at the moment where Linux looks, for example. |
| 16:19:59 | Jehan_ | rpath may also play a role. |
| 16:21:06 | Jehan_ | If you don't need portability across multiple architectures, you can also use {.passL:"-lname".} |
| 16:21:09 | * | Jesin quit (Quit: Leaving) |
| 16:21:21 | Jehan_ | To load a library, that is. |
| 16:21:40 | KevinKelley | I'll try that |
| 16:22:08 | Jehan_ | Not sure if it can be part of an importc pragma or has to be done at the module level. |
| 16:22:36 | Jehan_ | I recommend making a custom pragma for the importc stuff so that you don't have to retype everything all the time, anyway. |
| 16:24:27 | Jehan_ | You can also try and see if --dynlibOverride:bgfx --passL:-lbgfx works better. |
| 16:24:37 | * | Jesin joined #nimrod |
| 16:24:45 | Jehan_ | That you should be able to do without rewriting any code. |
| 16:25:01 | KevinKelley | okay will try |
| 16:25:20 | Jehan_ | May also give you a better error message if you can't find it. |
| 16:25:36 | * | Jehan_ honestly isn't a big fan of using dlopen() to access dynamic libraries. |
| 16:26:34 | Jehan_ | And the problems with figuring out what went wrong is exactly why. |
| 16:27:15 | Jehan_ | Unix systems have tools to debug the regular dynamic library loading process, but those are of no or only limited use for dlopen(). |
| 16:29:21 | KevinKelley | Okay that might have helped, using the passL to static link. |
| 16:29:54 | Jehan_ | --passL:-lwhatever will link dynamically or statically depending on what's available. |
| 16:30:00 | KevinKelley | Thanks Jehan_, think you fixed me |
| 16:33:43 | * | hoverbear joined #nimrod |
| 16:54:36 | * | io2 quit (Ping timeout: 260 seconds) |
| 17:36:03 | * | Matthias247 joined #nimrod |
| 17:37:42 | KevinKelley | anybody got a gallon of gasoline? I want to burn C++ with fire. |
| 17:45:55 | Jehan_ | KevinKelley: Heh. :) |
| 17:47:17 | Jehan_ | I sympathize, but, alas, C++ is sort of the COBOL of system programming. |
| 17:48:40 | Jehan_ | We can't get rid of it without destroying too many of the foundations we stand on. |
| 17:49:16 | Jehan_ | And, honestly, many of the problems with C++ are with how it's being used and what it's used for, not with the language design itself. |
| 17:51:25 | Jehan_ | Not to mention that until a few years ago, there weren't a great many realistic alternatives for many application domains. |
| 17:57:07 | * | goobles joined #nimrod |
| 18:05:31 | KevinKelley | @Jehan_, yeah, it's a tool that gives you all the control you might want, but it always cuts your hand. |
| 18:08:03 | KevinKelley | The ABI is a problem -- in that there isn't one. Or, that there's one for every different version of every compiler that's out there. |
| 18:20:44 | goobles | how come this doesn't compile;0 |
| 18:20:45 | goobles | proc '?'(x, y): auto = return y + x |
| 18:20:59 | goobles | indentifier expect but found '?' |
| 18:21:34 | exirctest | it's `, not ' |
| 18:21:52 | exirctest | '?' would be a char literal |
| 18:22:33 | goobles | oh ic, backticks like lisp |
| 18:31:15 | * | io2 joined #nimrod |
| 18:43:57 | Araq | so ... what's in the history ... ah yeah |
| 18:44:12 | Araq | people not understanding nimrod's memory model and complaining about it |
| 18:44:20 | Araq | and it's all my fault |
| 18:44:36 | Araq | because I don't like to "break backwards compatibility" |
| 18:44:55 | Araq | who cares if it fucks up memory safety in major ways |
| 18:45:20 | goobles | what what |
| 18:45:57 | * | superfunc joined #nimrod |
| 18:47:49 | * | vendethiel joined #nimrod |
| 18:48:53 | Araq | ah and ofc 'new T(a: 1)' is much better than 'T(a: 1)' ... |
| 18:57:37 | superfunc | loving the new anon. proc syntax, really cleans up some code for me |
| 18:59:55 | goobles | what does it look like |
| 18:59:57 | dom96 | superfunc: I'm glad somebody is using it :) |
| 19:00:18 | superfunc | from my code: |
| 19:00:50 | superfunc | w.debris = map( w.debris, ((p:Point2D) => (p.x, p.y - PROJ_RATE_Y))) |
| 19:01:07 | superfunc | which basically filters out all projectiles that have left the map in one clean statement |
| 19:01:29 | superfunc | Actually, I have a filter after that, that removes them |
| 19:01:36 | superfunc | The map is what updates their position |
| 19:02:11 | superfunc | w.debris = filter( w.debris, ((p: Point2D) => (p.y > 0))) |
| 19:02:34 | def- | superfunc: i think you don't need "w.debris = " |
| 19:02:48 | superfunc | I thought it returned a new sequence |
| 19:02:55 | Araq | yes, nice clean. Also iterates twice where one iteration would suffice ... but hey, who cares about that |
| 19:03:03 | def- | there is also a version of map that modifies the data directly |
| 19:03:19 | * | Araq is tired of functional map+filter. |
| 19:04:25 | * | superfunc am ashamed for my algorithmic misgivings |
| 19:04:35 | Trixar_za | If it's reasonable to break backward compatibility, then break backward compatibility |
| 19:04:51 | Araq | Trixar_za: that's what we do |
| 19:04:54 | superfunc | def-: Thanks, I had not seen that one |
| 19:05:03 | Araq | but the raised issues have *nothing* to do with that |
| 19:13:28 | dom96 | json.`{}` should return nil when its first param is nil right? |
| 19:14:08 | Araq | I guess |
| 19:14:16 | Araq | "Google initiated a $50 million coding project on Thursday to increase girls interest in computer science. " omg |
| 19:14:27 | Araq | they could have funded Nimrod with this money instead ... |
| 19:15:49 | Araq | "This comes after the technology giant revealed one-sided diversity statistics that showed a global workforce comprised just 30% women. The Mountain View, California.-based company blamed education for the uneven diversity figures, and vowed to invest in computer science education for minorities and women." |
| 19:16:59 | Araq | 30% women is actually quite a lot, isn't it? |
| 19:17:00 | Jehan_ | Good intentions, but as they say, at least Sisyphus had a boulder that could be moved. :) |
| 19:17:39 | Araq | I don't even see how these are "good intentions" ... |
| 19:17:55 | Araq | is working in front of a computer all that desirable? |
| 19:17:56 | Jehan_ | Araq: Not really. And that's not even considering how many of them are probably in secretarial jobs. |
| 19:19:00 | Jehan_ | Araq: You mean secretaries still use typewriters? |
| 19:20:00 | superfunc | No, but the money to do so is |
| 19:20:32 | dom96 | Araq: Also, isn't allowing varargs for {} but not [] inconsistent? |
| 19:20:44 | superfunc | Most students I meet, especially where I am(San Jose), go into CS for the paycheck |
| 19:20:58 | Araq | dom96: I don't care, fix it |
| 19:21:20 | Araq | superfunc: ah so girls don't know about the paychecks |
| 19:21:31 | Araq | and we need 50 Million to tell them |
| 19:21:52 | superfunc | Araq: lol |
| 19:22:37 | superfunc | def-: I see map() in system, but I don't see a version of filter there |
| 19:23:00 | Matthias247 | those wo do id for the paycheck ususally don't pass the exams |
| 19:23:23 | superfunc | If they do, I end up fixing their code. |
| 19:23:23 | Matthias247 | and ... it's not worth for the paycheck |
| 19:23:39 | Matthias247 | better go for medicine, law or banking |
| 19:23:58 | Araq | spending 50 million for girls under the assumption they are too stupid to do CS otherwise is misogynic |
| 19:24:02 | def- | superfunc: i guess it makes less (no) sense to make filter work on the data structure directly |
| 19:24:15 | def- | modifying it directly* |
| 19:25:07 | superfunc | def-: I suppose, though I've seen it handled both ways |
| 19:25:38 | superfunc | def-: STL basically moves all "filtered things" to the end then chops it off |
| 19:26:11 | def- | superfunc: ah, true, you could do that |
| 19:26:17 | Araq | Matthias247: I agree |
| 19:26:22 | NimBot | Araq/Nimrod devel 38cdd75 Dominik Picheta [+0 ±1 -0]: Remove varargs from json.`{}` |
| 19:26:22 | NimBot | Araq/Nimrod devel 0449791 Dominik Picheta [+0 ±1 -0]: Merge branch 'devel' of github.com:Araq/Nimrod into devel |
| 19:26:35 | exirctest | and if they were indeed too stupid, then maybe they should do something else instead. tell em :p |
| 19:26:46 | Araq | dom96: argh. |
| 19:26:49 | superfunc | Matthias247: Most end up there. I think my CS department had a retention rate of like 35% lol |
| 19:26:55 | Araq | I liked the varargs |
| 19:27:02 | dom96 | Araq: ... |
| 19:27:06 | Araq | the compiler doesn't really like them, but will soon |
| 19:27:15 | dom96 | Araq: You just said you didn't care. |
| 19:27:27 | Araq | I trusted you to do the right thing :P |
| 19:28:20 | exirctest | lol |
| 19:31:28 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 19:31:30 | * | vendethiel- joined #nimrod |
| 19:31:38 | * | vendethiel- is now known as vendethiel |
| 19:32:17 | superfunc | Araq: Does the compiler elide copies? |
| 19:32:26 | Matthias247 | superfunc: was the same at my unverisity. Most then switched to some media stuff |
| 19:32:38 | Matthias247 | which is finished by 99% of all people |
| 19:33:38 | Araq | superfunc: sometimes |
| 19:33:52 | superfunc | Araq: Neat, thanks |
| 19:39:14 | superfunc | Matthias247: What country did you go to school in? |
| 19:43:47 | goobles | 'MERICA |
| 19:44:19 | superfunc | lol |
| 19:45:10 | Matthias247 | superfunc: germany |
| 19:46:46 | goobles | i bet german CS is fun |
| 19:48:09 | goobles | is nimrod hot in germany |
| 19:49:28 | superfunc | nimrod is hot worldwide |
| 19:50:01 | Araq | that's news to me |
| 19:51:47 | dom96 | Nimrod is hot on Venus. |
| 19:52:09 | * | steeb joined #nimrod |
| 19:53:22 | goobles | nimrod is safe cause you don't use unsigned |
| 19:53:33 | goobles | and also nimrod has memory safety |
| 19:54:14 | goobles | D is dumb cause it is boring and has a GC which takes forever to GC |
| 19:54:30 | * | steeb left #nimrod (#nimrod) |
| 19:54:47 | superfunc | I wouldn't call D dumb, just not for me. |
| 19:55:18 | Jehan_ | I wouldn't even go that far. |
| 19:55:45 | superfunc | It just didn't excite me enough to bother using it over C++11(14) |
| 19:56:01 | goobles | ya its boring like i said;0 |
| 19:56:09 | Jehan_ | It did clear that bar for me (admittedly, not a very high one). |
| 19:57:07 | Jehan_ | I had honestly hoped for some feature deprecation and streamlining in C++11. |
| 19:57:21 | goobles | what you want deprecated? |
| 19:57:34 | goobles | unsigned? |
| 19:57:45 | Jehan_ | Why would I want to get rid of unsigned integers? |
| 19:57:49 | superfunc | Jehan_: It would be nice, I just didn't expect it. |
| 19:57:55 | goobles | idk cause you hates them? |
| 19:58:05 | goobles | Araq hates them |
| 19:58:06 | Jehan_ | Then you got the wrong message last night. |
| 19:58:32 | Jehan_ | I don't hate unsigned integers. But when you're doing arithmetic, signed integers are the safer default. |
| 19:58:43 | goobles | yessir |
| 19:59:03 | Jehan_ | Conversely, unsigned integers tend to be superior when you're dealing with bitpatterns. |
| 19:59:03 | goobles | i want header files deprecated |
| 19:59:19 | goobles | i fucking hate header files |
| 19:59:51 | goobles | i don't understand how C++ is stull using this header file crap after 30 years:( |
| 20:00:00 | Jehan_ | Inertia. |
| 20:00:11 | Jehan_ | They may be on their way out come C++14, though. |
| 20:00:19 | goobles | it better |
| 20:00:32 | Jehan_ | But yeah, probably the biggest problem that C++ is facing in practice. |
| 20:00:42 | Jehan_ | Because of what they do to compile times. |
| 20:01:01 | Jehan_ | Not to mention writing tons of stuff twice is tedious beyond belief. |
| 20:01:26 | goobles | ya thankfully my IDE does most of that |
| 20:01:49 | Jehan_ | Which one are you using? |
| 20:01:56 | goobles | visual studio 2013 |
| 20:02:02 | goobles | with visual assist pluggin |
| 20:02:09 | Jehan_ | Ah, not an option for me, alas. :) |
| 20:02:24 | Araq | this is exactly what people mean when they say "IDEs patch over language warts" |
| 20:02:40 | Jehan_ | Araq: Yeah, I know. |
| 20:03:03 | Araq | a sensible IDE feature would be "extract this header-file-like view for me" |
| 20:03:38 | Araq | but an IDE *writing code for you* is just madness |
| 20:03:40 | Jehan_ | Heh. I remember when that was an actually novel feature (short/flat for Eiffel). |
| 20:03:45 | goobles | my process is to write the header, then tell it to generate the .cpp contents from the header;0 |
| 20:03:51 | goobles | still hate the stupid headers |
| 20:04:12 | Jehan_ | goobles: I use a script that generates the header from the (annotated) source. |
| 20:04:52 | goobles | hum how does that work, you classes have to be visible in header..? |
| 20:04:56 | Jehan_ | Unfortunately, it's somewhat fragile if I use too many exciting C++ syntax features. |
| 20:06:00 | Jehan_ | I write a class definition with all methods inline, basically. The ones that I don't want to actually be part of the header get a body that begins with {{ and ends with }}. |
| 20:06:22 | Jehan_ | The script removes those bodies from the header and puts them (along with a proper method header) in the source. |
| 20:06:41 | Jehan_ | Same goes for functions not associated with a class. |
| 20:06:48 | goobles | oh so you are basically writing the header first? |
| 20:06:59 | Jehan_ | It's more that I'm writing the header only. :) |
| 20:07:09 | goobles | yes i can do the same thing in VS |
| 20:07:13 | Jehan_ | Or rather, a combined header/source thing. |
| 20:07:15 | goobles | i just tell it to move the function |
| 20:07:26 | Jehan_ | From which I then generated header and source. |
| 20:07:35 | superfunc | Jehan_: I thought Modules weren't making it into 14 |
| 20:07:39 | Jehan_ | Yeah. The thing is that I can use that as part of the build process. |
| 20:07:50 | Jehan_ | superfunc: I said I'm hoping for it, not that it's a rational hope. :) |
| 20:07:54 | goobles | oh that is kinda useful |
| 20:08:45 | goobles | but what about all the extra headers, like the ones only used by your {{}} functions, do you include those in both?.. C++ basically requires you to manage the build yourself to avoid horrible compile times |
| 20:09:04 | goobles | i think modules is definitely not making c++14 |
| 20:09:07 | Jehan_ | Yeah. The downside is that the script isn't really a C++ parser, so I have to be somewhat careful with how I write code so that it can be processed. |
| 20:09:27 | Jehan_ | I have an implementation part to denote code that only goes in the source, not the header. |
| 20:09:51 | Jehan_ | #implementation, everything after that is non-header stuff. |
| 20:10:09 | goobles | ah ok |
| 20:10:20 | goobles | my guess is modules no sooner than C++17 |
| 20:10:38 | goobles | they are slow and don't seem to care enough about modules |
| 20:10:46 | goobles | more interested in transactional memory etc |
| 20:10:47 | Jehan_ | In my ideal world, I won't need to use C++ anymore by then. :) |
| 20:11:39 | Jehan_ | One or more of the alternatives will have matured enough so that people transition to them for new projects and may think about rewriting some of the older ones. |
| 20:11:50 | Jehan_ | Not stuff like KDE, though. :) |
| 20:13:01 | BitPuffin | Araq: didn't say that there was anything wrong with the memory model because you don't want to break backwards compatibility. I was saying that you don't want to break backwards compatibility even when something is bad. In general. If you read you'd see that I don't really care which one is the convention :P |
| 20:13:14 | superfunc | Its not really an issue of being slow, per say. Getting things into that standard are very hard. You have to be able to guarantee backwards compatibility and offer a seemingly optimal implementation. |
| 20:13:33 | Jehan_ | superfunc: Yup. They have good reason. |
| 20:14:00 | Jehan_ | Source: A former officemate of mine is on the C++ standards committee. |
| 20:14:05 | goobles | nimrooooooooooood to the rescue! |
| 20:14:15 | Araq | BitPuffin: "when something is bad" -- well ... |
| 20:15:06 | BitPuffin | Araq: yeah, like stuff in the stdlib etc |
| 20:15:11 | BitPuffin | I've seen it multiple times |
| 20:15:29 | Araq | usually the stuff that "is bad" works |
| 20:15:31 | BitPuffin | you worrying, "would fixing this break people's code dom? omg dom will it break? TELL ME DOM" |
| 20:15:39 | BitPuffin | who cares if it works |
| 20:15:41 | BitPuffin | C++ works |
| 20:15:56 | BitPuffin | why make something better if it works |
| 20:16:02 | BitPuffin | great logic |
| 20:16:07 | Jehan_ | Well … I point you to the widespread adoption of Python 3. |
| 20:16:22 | BitPuffin | like I said earlier Python 2 fappers are pathetic |
| 20:16:49 | Araq | BitPuffin: I'm sure people enjoy a non-compiling compiler with a stdlib that is "better" |
| 20:17:02 | goobles | lua breaks backward compatibility when they update it |
| 20:17:12 | BitPuffin | if you don't like python 3 then you should find another ship, not sink with the one you are currently on |
| 20:17:18 | BitPuffin | Araq: boohoo, fucking fix it then |
| 20:17:26 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 20:17:44 | BitPuffin | to quote yourself "activate brain" |
| 20:18:51 | Araq | I'll keep in mind the next time you complain about your code not compiling |
| 20:19:06 | BitPuffin | how does that make any sense? |
| 20:19:08 | * | Raynes quit (Remote host closed the connection) |
| 20:19:30 | BitPuffin | I complain when your code in the compiler has bugs that make my code not compile |
| 20:19:37 | BitPuffin | not when the stdlib changes and I can fix it :P |
| 20:20:09 | Araq | and yet both take up my time |
| 20:20:11 | BitPuffin | the point is, I don't bitch if there is changes in libraries I use that I have to update in MY codebase, but you bitch if you have to update your codebase :P |
| 20:20:22 | Jehan_ | Are there any important backward-compatibility breaking features that people think Nimrod should have? |
| 20:20:36 | Jehan_ | Other than the great T/P prefix exodus ... |
| 20:20:46 | Araq | 'defined' would be high on my list |
| 20:20:57 | Jehan_ | Araq: What about defined? |
| 20:21:04 | Jehan_ | Make it a keyword, remove it, rename it? |
| 20:21:12 | Araq | it conflates 2 different things |
| 20:21:20 | Jehan_ | Gotcha. |
| 20:21:21 | Araq | the --define:foo stuff |
| 20:22:04 | Araq | and the defined(strutils.toUpper) usage |
| 20:23:31 | * | kunev quit (Quit: leaving) |
| 20:24:12 | Araq | also I plan to get rid of 'static[T]' |
| 20:24:25 | BitPuffin | woopwoop |
| 20:24:28 | Araq | not sure how to do it, but it needs either to be fixed |
| 20:24:33 | BitPuffin | it barely got a chance lol |
| 20:24:37 | Araq | or replaced by something better |
| 20:24:48 | BitPuffin | it's zahary's code isn't it? |
| 20:25:00 | Araq | of course :P |
| 20:25:03 | BitPuffin | yeah |
| 20:25:04 | Jehan_ | Don't you like the concept or the syntax? Or do you mean how it's being used for type parameters? |
| 20:25:06 | Araq | I don't make any mistakes |
| 20:25:08 | BitPuffin | hard to fix then |
| 20:25:12 | BitPuffin | Araq: lol |
| 20:25:14 | BitPuffin | sure :P |
| 20:25:44 | Araq | Jehan_: the concept of this *type* is flawed |
| 20:25:57 | Araq | it shouldn't be a type, it should be a constraint |
| 20:26:14 | Jehan_ | Yeah, I'd agree with that. |
| 20:26:30 | Araq | also it doesn't really work with the language, is 3 of type static[int] ? |
| 20:26:37 | Araq | no it's not |
| 20:26:47 | Araq | var foo: type(3) |
| 20:26:52 | Araq | should be |
| 20:26:54 | Araq | var foo: int |
| 20:27:22 | Araq | it's like C++'s const |
| 20:27:26 | BitPuffin | the name is also pretty bad |
| 20:27:30 | BitPuffin | static[T] |
| 20:27:38 | BitPuffin | doesn't say much about what it is |
| 20:27:42 | Araq | well it used to be expr[T] |
| 20:27:51 | Araq | so .. the name already improved :P |
| 20:28:26 | Jehan_ | x: immediate T :) |
| 20:29:09 | Jehan_ | Sigh, it's depressing how slow a 6-year old laptop with 2GB RAM feels. |
| 20:29:19 | Araq | also first class types give me the creeps |
| 20:29:31 | Araq | var foo = int # yeah, it's an = here |
| 20:29:47 | Araq | very newbie unfriendly |
| 20:29:54 | Araq | who often confuse = with : |
| 20:30:05 | Araq | and then they get nice errors or even compiler crashes |
| 20:30:18 | Araq | can only guess how many users this "feature" did cost us |
| 20:30:38 | def- | Araq: yeah, those error messages had me confused a few times |
| 20:32:30 | superfunc | Jehan_: Try a chromebook: you may enjoy it |
| 20:32:58 | Jehan_ | superfunc: Not for this kind of stuff, thank you. |
| 20:33:27 | Jehan_ | Chromebooks have their use, being a primary software development machine isn't one of them. |
| 20:33:39 | NimBot | nimrod-code/babel master 05d9956 Dominik Picheta [+0 ±3 -0]: Implements babel uninstall. |
| 20:33:39 | NimBot | nimrod-code/babel master 45f0a20 Dominik Picheta [+0 ±1 -0]: Added uninstall test. |
| 20:33:39 | NimBot | nimrod-code/babel master dd1cc21 Dominik Picheta [+0 ±1 -0]: Fixes crash when installing using git URL. |
| 20:33:39 | NimBot | nimrod-code/babel master 014b897 Dominik Picheta [+0 ±2 -0]: Packages with URL dependencies are now removed properly. |
| 20:33:39 | NimBot | 2 more commits. |
| 20:34:10 | goobles | so can you do like constraints in nimrod(c++ enable_if) |
| 20:34:11 | Araq | dom96: how do you remove dependencies? |
| 20:34:15 | dom96 | Test if you can please^ |
| 20:34:42 | dom96 | Araq: babel uninstall/remove/delete? |
| 20:34:47 | dom96 | Araq: or what do you mean? |
| 20:34:50 | Araq | dom96: yes |
| 20:35:15 | Araq | (also add 'del' and 'rm' to this list please ;-) ) |
| 20:35:43 | dom96 | those are already on that list |
| 20:35:48 | dom96 | I just didn't feel like listing them here |
| 20:36:02 | Araq | ok well |
| 20:36:09 | Araq | I have package A and B and B depends on A |
| 20:36:12 | superfunc | Jehan_: idk, I threw ubuntu on one and found it sufficient, but I was hardly leaving vim |
| 20:36:16 | Araq | but is useful on its own |
| 20:36:31 | Araq | when I remove B and Babel also removes A that's annoying |
| 20:36:44 | Araq | but it's also annoying if it doesn't remove deps |
| 20:36:53 | Araq | so how do you deal with this problem? |
| 20:37:57 | Jehan_ | superfunc: I need to compile C++ programs with a few hundred KLOC and the build process shouldn't take forever. |
| 20:38:56 | superfunc | Jehan_: Oh wow, haha. Mine was like 20k max I think |
| 20:39:10 | dom96 | Araq: Babel doesn't remove dependencies. |
| 20:39:17 | superfunc | Jehan_: and Qbs helped mitigate it some |
| 20:39:19 | dom96 | Araq: it only removes what you ask it to |
| 20:39:19 | Jehan_ | MInd you, it's not code that I've written, I'm just stuck with it. |
| 20:39:36 | dom96 | Now you'll tell me that that is annoying :P |
| 20:39:52 | BitPuffin | Araq: thought you hated aliases :P |
| 20:40:04 | dom96 | Maybe i'll add a flag which removes a package's dependencies too |
| 20:40:12 | dom96 | in fact, that's pretty simple to do I think |
| 20:40:23 | dom96 | but by default it only removes the packages you ask it to remove. |
| 20:40:26 | def- | superfunc: after writing an inline filter (it's much faster) i guess i know why it's not in sequtils by default: Ambiguous call when using filter, because arguments have same type |
| 20:41:32 | * | OrionPK quit (Remote host closed the connection) |
| 20:41:42 | superfunc | def-: That makes sense. We could have one and call it inPlaceFilter or something to be clear |
| 20:41:45 | * | OrionPK joined #nimrod |
| 20:41:54 | * | Raynes joined #nimrod |
| 20:42:03 | OrionPK | dom96 about? |
| 20:42:04 | * | Raynes quit (Changing host) |
| 20:42:04 | * | Raynes joined #nimrod |
| 20:42:18 | def- | superfunc: yeah, but i'm not sure which name would be best, filterDirectly, keepIf or something entirely different? |
| 20:42:29 | dom96 | OrionPK: what? |
| 20:42:54 | OrionPK | im having an issue w/ nginx chunked and scgi on jester, wonder if you had any ideas |
| 20:42:57 | BitPuffin | dom96: you should also have a command that lists orphans |
| 20:43:08 | OrionPK | like when my response gets too big, it seems like it just gets cut off |
| 20:43:14 | OrionPK | it gets to like 64kb |
| 20:43:25 | dom96 | OrionPK: oh. Yes, I am about. |
| 20:43:42 | Araq | dom96: ok that's a good solution |
| 20:43:52 | dom96 | BitPuffin: sure |
| 20:44:23 | dom96 | OrionPK: Yeah. I think that's a known bug. |
| 20:44:52 | OrionPK | oh really... |
| 20:45:06 | dom96 | OrionPK: I believe I ran into that. |
| 20:45:09 | OrionPK | well i guess glad it's not just me |
| 20:45:17 | Araq | dom96: how can you still like socket handling? |
| 20:45:18 | OrionPK | it's happening in ircfamiliar |
| 20:45:40 | dom96 | OrionPK: IIRC the problem is that jester does not do async properly yet |
| 20:46:02 | dom96 | OrionPK: so if you're sending a lot of data, the socket gets filled up and the rest gets dropped because it cannot send anymore. |
| 20:46:39 | OrionPK | okay |
| 20:46:47 | dom96 | Araq: Did I ever say I liked it? |
| 20:46:47 | OrionPK | so you think your current work might resolve that? |
| 20:46:52 | dom96 | OrionPK: yeah. |
| 20:47:08 | OrionPK | dom96 alrighty cool. I'll set ircfamiliar to preserve less irc log for now |
| 20:47:11 | dom96 | OrionPK: Just have to wait for Araq to finish his fixes. |
| 20:47:29 | dom96 | OrionPK: I already rewrote Jester to use the new async stuff |
| 20:47:35 | OrionPK | sweet dude |
| 20:47:48 | dom96 | OrionPK: https://github.com/dom96/jester/tree/new-async in case you wanna take a look |
| 20:47:52 | Araq | I really think with these fixes we should release 0.9.6 |
| 20:48:03 | Araq | or perhaps 0.9.4.2 |
| 20:48:05 | exirctest | so, are we fixing those typedesc related issues then? we've often discussed how to make the language more popular after all |
| 20:48:11 | dom96 | OrionPK: still untested because I need nested closures and so I need to wait for Araq to implement them |
| 20:48:21 | OrionPK | dom96 okay |
| 20:49:29 | exirctest | I might've missed something. My own client has one foreground and one background, which makes reading walls of text difficult. will switch to weechat again |
| 20:49:41 | * | exirctest quit (Remote host closed the connection) |
| 20:50:06 | * | EXetoC joined #nimrod |
| 20:50:28 | goobles | how do you have "few hundred KLOC" omg |
| 20:50:32 | dom96 | But anyway. Please test babel's new uninstall feature guys! |
| 20:50:40 | Jehan_ | goobles: It's an old project. |
| 20:50:50 | Jehan_ | I've seen bigger ones, too. |
| 20:50:54 | dom96 | I may release a new version of it soon. |
| 20:51:02 | goobles | in 1 file? |
| 20:51:08 | EXetoC | dom96: ok. let's see if "babel install babel" breaks the installation now :> |
| 20:51:09 | Jehan_ | goobles: God, no. |
| 20:51:12 | goobles | oh ok;0 |
| 20:51:19 | goobles | i thought u meant u had a giant ass file of doom |
| 20:51:22 | Araq | can somebody please run this: |
| 20:51:37 | Araq | nimrod c tests/closure/tinvalidclosure2.nim |
| 20:52:00 | dom96 | tinvalidclosure2.nim(10, 17) Error: illegal capture 'A' |
| 20:52:04 | Jehan_ | tests/closure/tinvalidclosure2.nim(10, 17) Error: illegal capture 'A' |
| 20:52:08 | Araq | fuck |
| 20:52:13 | Araq | but thanks |
| 20:52:21 | Jehan_ | Do we need to pull a more recent version? |
| 20:52:27 | OrionPK | brb |
| 20:52:28 | * | OrionPK quit (Remote host closed the connection) |
| 20:52:35 | Araq | well it compiles with my version |
| 20:52:38 | dom96 | EXetoC: lol |
| 20:52:40 | Araq | so I broke it |
| 20:52:44 | EXetoC | dom96: tried to uninstall termbox, but it segfaulted after "Checking reverse dependencies..." |
| 20:52:57 | superfunc | def-: Not sure either. We could have something called remove_if() |
| 20:53:04 | * | OrionPK joined #nimrod |
| 20:53:11 | dom96 | EXetoC: hm |
| 20:53:28 | EXetoC | I will build a debug version |
| 20:53:40 | dom96 | EXetoC: works for me |
| 20:53:42 | superfunc | def-: Maybe have a sig of proc remove_if[T](s: seq[T], proc(t: T): bool) ... |
| 20:53:56 | def- | superfunc: but then it's the other way around than filter, hm |
| 20:54:27 | goobles | does it work like C++ remove_if that doesn't remove anything;0 |
| 20:54:27 | superfunc | def-: Well, remove_if is essentially an in place filter, no? |
| 20:54:28 | EXetoC | dom96: ok I might have to pull in the latest json changes |
| 20:54:37 | BitPuffin | Araq: alias bblrm="babel remove" |
| 20:54:37 | dom96 | EXetoC: ahh yes. |
| 20:54:44 | dom96 | EXetoC: Should have mentioned that lol |
| 20:55:12 | EXetoC | sorry for taking ages on that dependency fix. I also need to fix the babel-git package. I'm as motivated as always |
| 20:55:38 | def- | superfunc: except remove_if takes true to remove and filter false to remove |
| 20:55:53 | dom96 | EXetoC: it's ok. |
| 20:56:03 | * | dom96 really likes that Windows 8 has an Alarms app |
| 20:57:03 | superfunc | def-: Oh, I see what you mean |
| 20:57:06 | superfunc | my bad |
| 20:57:23 | OrionPK | cant build babel |
| 20:58:00 | dom96 | OrionPK: what's the error? |
| 20:58:11 | OrionPK | babel.nim(280, 14) Error: type mismatch: got (TSet[string], TSet[string]) |
| 20:58:26 | OrionPK | i havent used my desktop much though, maybe nimrod's out of date |
| 20:59:04 | dom96 | possibly |
| 20:59:41 | * | Raynes quit (Quit: ZNC - http://znc.sourceforge.net) |
| 21:01:45 | superfunc | def-: remove_if would still give us the functionality we want though. So long as we don't call it filter, it could be useful |
| 21:06:09 | OrionPK | dom96 yeah updating fixed it |
| 21:07:19 | dom96 | good |
| 21:07:20 | def- | superfunc: yeah, i guess it's a matter of taste. According to wikipedia most programming languages do it the filter way instead of the remove_if way |
| 21:08:00 | superfunc | def-: true, I come from mostly a C++ perspective, which is probably why I skew that way |
| 21:28:02 | * | hoverbear quit (Read error: Connection reset by peer) |
| 21:28:33 | * | hoverbear joined #nimrod |
| 21:28:54 | * | hoverbear quit (Max SendQ exceeded) |
| 21:32:11 | * | hoverbear joined #nimrod |
| 21:36:50 | * | shodan45 joined #nimrod |
| 21:40:26 | dom96 | So, who's watching US vs. Portugal? |
| 21:40:54 | * | Raynes joined #nimrod |
| 21:42:17 | * | dioq joined #nimrod |
| 21:42:46 | * | f0wl quit (Changing host) |
| 21:42:46 | * | f0wl joined #nimrod |
| 21:48:34 | superfunc | dom96: I would be, if the internet here could handle it lul |
| 21:50:58 | dioq | Hi, does anyone know how to create an uint8 literal in a macro? I've tried newNimNode(nnkUInt8Lit), but it doesn't have a setter (nnkInt8Lit has intVal), am I missing something? |
| 21:55:36 | dom96 | dioq: I think it also uses intVal |
| 21:57:16 | * | brson joined #nimrod |
| 21:57:39 | f0wl | dioq, intval seems to be missing from uint*lit |
| 21:57:51 | OrionPK | USA! USA! |
| 21:58:27 | f0wl | dioq, you can get around it in the meantime by using parseexpr("4'u8") |
| 21:59:38 | dom96 | OrionPK: I'm rooting for USA too! |
| 22:00:03 | OrionPK | :D |
| 22:00:18 | OrionPK | cant help but root for the underdogs;) |
| 22:00:26 | dom96 | lol |
| 22:00:32 | OrionPK | i even had a friend from PT wish the USA luck :p |
| 22:01:24 | BitPuffin | I'm hoping they all die |
| 22:02:27 | OrionPK | you suck |
| 22:02:37 | OrionPK | just cuz sweden didnt make it to the world cup finals |
| 22:02:38 | OrionPK | ? |
| 22:02:44 | dioq | f0wl, this works, thanks |
| 22:03:16 | OrionPK | just noticed that nimrod's bindings for sfml are up on sfml's page |
| 22:03:16 | OrionPK | http://www.sfml-dev.org/download/bindings.php |
| 22:03:31 | BitPuffin | didn't even knowo that so no |
| 22:03:34 | BitPuffin | because it's boring |
| 22:04:10 | BitPuffin | If we are gonna bitch that google isn't giving money to nimrod imagine all the money that nimrod could get if we didn't finance any football/soccer ever :P |
| 22:04:18 | goobles | ugh usa don't loose ;0 |
| 22:04:54 | BitPuffin | lose* |
| 22:05:19 | dom96 | OrionPK: Awesome |
| 22:05:29 | dom96 | also their new site looks nice |
| 22:05:32 | OrionPK | fuck |
| 22:05:34 | OrionPK | me |
| 22:05:43 | OrionPK | its gonna be a long game |
| 22:05:46 | dom96 | damn it |
| 22:05:49 | dom96 | they scored |
| 22:06:21 | goobles | well this is going to be ugly |
| 22:10:16 | f0wl | OrionPK, i emailed sdl2 and allegro people but i couldnt get ahold of anyone |
| 22:10:34 | OrionPK | whats the status of the sfml plugin |
| 22:10:55 | f0wl | 0 issues reported |
| 22:10:58 | BitPuffin | f0wl: why not bitch in the irc? |
| 22:11:00 | OrionPK | ;) |
| 22:12:36 | BitPuffin | they usually respond there |
| 22:13:48 | f0wl | they said to send emails |
| 22:14:22 | * | musicalchair quit (Ping timeout: 245 seconds) |
| 22:14:28 | BitPuffin | send emails they said |
| 22:14:32 | BitPuffin | it will be fun they said |
| 22:14:41 | BitPuffin | we will do it they said |
| 22:17:18 | OrionPK | f0wl no issues, but how much of the api do you have covered |
| 22:21:00 | * | Trustable quit (Quit: Leaving) |
| 22:22:37 | EXetoC | BitPuffin: football monies -> nimrod? great idea |
| 22:24:27 | f0wl | OrionPK, of csfml? all of it i think |
| 22:25:51 | BitPuffin | EXetoC: exactly |
| 22:26:13 | BitPuffin | so all of you watching football right now are stealing money from nimrod |
| 22:26:14 | BitPuffin | you bastards |
| 22:26:18 | BitPuffin | you should be ashamed |
| 22:26:38 | BitPuffin | dom96: I think the new nimrod mascot should be a little shit |
| 22:27:04 | BitPuffin | with a surf shirt |
| 22:27:18 | dom96 | BitPuffin: only if it's a lying little shit |
| 22:27:32 | BitPuffin | yes |
| 22:27:37 | BitPuffin | it should have a speech bubble |
| 22:27:44 | BitPuffin | saying something like "Go is the future" |
| 22:28:10 | dom96 | perfect |
| 22:28:28 | dom96 | better yet, let's have the honey badger taking a crap |
| 22:28:33 | dom96 | and that crap is the lying little shit |
| 22:28:43 | dom96 | with the speech bubble |
| 22:28:59 | BitPuffin | don't forget the surf shirt |
| 22:29:11 | dom96 | Yes, it will be a piece of art. |
| 22:29:13 | EXetoC | BitPuffin: you think Araq could work fulltime on nimrod then? |
| 22:29:17 | EXetoC | yeah I think so |
| 22:29:25 | EXetoC | lots of money in it innit |
| 22:29:28 | BitPuffin | with all the football moneys in the world? |
| 22:29:42 | BitPuffin | I think araq would never stop demanding more money for working full time :P |
| 22:31:12 | * | musicalchair joined #nimrod |
| 22:32:51 | Araq | Is a man not entitled to the sweat of his brow? |
| 22:39:51 | OrionPK | wow |
| 22:39:52 | OrionPK | water break |
| 22:39:55 | OrionPK | never seen that in world cup ;) |
| 22:40:18 | dom96 | lol |
| 22:41:31 | OrionPK | "the sweat is dripping off everbody - including your commentators" |
| 22:45:45 | Araq | damn you guys |
| 22:45:52 | Araq | do I need to watch this match? |
| 22:46:48 | EXetoC | nah |
| 22:47:09 | BitPuffin | Araq: if you want to steal funds from nimrod yes |
| 22:52:43 | superfunc | dom96: has the json module been updated recently? |
| 22:52:55 | dom96 | superfunc: yes |
| 22:53:15 | superfunc | ok, the example wasn't compiling, this makes more sense |
| 22:53:38 | * | io2 quit () |
| 22:55:28 | dom96 | superfunc: which example? |
| 22:56:21 | superfunc | from the generated documentation on module json |
| 23:01:22 | * | superfunc quit (Quit: leaving) |
| 23:01:24 | dom96 | The one at the top of the page? |
| 23:01:28 | dom96 | argh |
| 23:01:41 | * | superfunc joined #nimrod |
| 23:01:57 | dom96 | EXetoC: So does Babel work for you? |
| 23:10:52 | * | superfunc quit (Quit: leaving) |
| 23:11:43 | * | dioq quit (Quit: Page closed) |
| 23:13:16 | * | darkf joined #nimrod |
| 23:22:13 | dom96 | Yes! USA! |
| 23:22:55 | goobles | woooooot |
| 23:23:13 | * | superfunc joined #nimrod |
| 23:23:21 | superfunc | dom96: New version seems to have fixed it |
| 23:23:40 | EXetoC | dom96: yes |
| 23:23:49 | Araq | hmm there is a youtube video with the title "Infinity is bigger than you think" |
| 23:24:02 | dom96 | EXetoC: good |
| 23:24:24 | OrionPK | WOOOOOO! |
| 23:24:26 | OrionPK | YEAH! |
| 23:24:27 | OrionPK | USA! |
| 23:24:29 | OrionPK | omg |
| 23:24:36 | OrionPK | I stepepd out of the room for 30 seconds to pee |
| 23:24:38 | OrionPK | and missed the goal |
| 23:24:44 | BitPuffin | lol |
| 23:24:47 | BitPuffin | nubs |
| 23:24:59 | dom96 | wow, Portugal seems much more aggressive now |
| 23:25:56 | superfunc | dom96: thanks for this module, made a part of my game much simpler |
| 23:26:07 | dom96 | BitPuffin: There is a guy playing who reminds me of you, he has dreadlocks :P |
| 23:26:11 | superfunc | using it to define enemy patterns |
| 23:26:25 | goobles | portugal has to win or they dead |
| 23:26:34 | dom96 | superfunc: heh, sure. It wasn't all me though. Araq wrote the parser, I wrote most of the high-level interface. |
| 23:27:22 | superfunc | Araq: Thanks too |
| 23:28:34 | OrionPK | yeah pt is peesed |
| 23:28:55 | dom96 | is US still in if they lose? |
| 23:28:56 | BitPuffin | dom96: that probably means we are the same him and I |
| 23:30:13 | dom96 | BitPuffin: of course |
| 23:39:53 | dom96 | ANOTHER ONE! |
| 23:39:54 | dom96 | USA! |
| 23:40:21 | goobles | YAAAA |
| 23:40:41 | OrionPK | WOOOO |
| 23:40:46 | OrionPK | USA!!! |
| 23:40:51 | OrionPK | go dempsey! |
| 23:40:58 | OrionPK | broken nose? no problem :D |
| 23:42:16 | BitPuffin | nurds |
| 23:43:33 | superfunc | eat it portugal |
| 23:44:36 | * | Jehan_ quit (Quit: Leaving) |
| 23:48:52 | * | superfunc quit (Quit: leaving) |
| 23:49:04 | * | superfunc joined #nimrod |
| 23:53:40 | dom96 | fuck |
| 23:55:14 | Varriount | ? |
| 23:57:04 | superfunc | Varriount: US got scored on |
| 23:57:07 | BitPuffin | dom96 is just stating his desires |
| 23:57:23 | * | Varriount doesn't watch sports, and thus could care less. |
| 23:57:34 | dom96 | Varriount: *couldn't |
| 23:57:45 | Varriount | ^ |
| 23:58:19 | BitPuffin | ^ |
| 23:58:25 | BitPuffin | stupid muricans |
| 23:58:49 | BitPuffin | could care less has actually been defined to mean couldn't care less |
| 23:58:50 | BitPuffin | it's retarded |
| 23:59:22 | Varriount | BitPuffin: That's the way of language. It's like when people as the question "Do you mind" |