| 00:02:30 | OrionPK | thanks fowl |
| 00:03:44 | Varriount | BitPuffin, trying to compile nimrod on Dragonfly? |
| 00:04:35 | BitPuffin | Varriount: no, on plain freebsd |
| 00:06:58 | OrionPK | would be nice if I could call call().toSeq() instead of having to call .toSeq(call()) |
| 00:08:29 | BitPuffin | OrionPK: why wouldn't that work? |
| 00:08:36 | OrionPK | dunno, doesnt compile though |
| 00:08:59 | * | ltbarcly joined #nimrod |
| 00:09:01 | BitPuffin | Araq: attempted a workaround where I use the 0.9.2 release to compile koch and then bootstrap but that didn't work either |
| 00:10:01 | BitPuffin | Araq: the funny thing is that the files it says do not exist exist |
| 00:11:33 | fowl | OrionPK, not sure why you cant |
| 00:13:16 | OrionPK | I get Error: type mismatch: got (TFile) |
| 00:13:29 | OrionPK | using the "lines" iterator in system module |
| 00:13:32 | Varriount | BitPuffin, make sure to explicitly add them to the linker |
| 00:13:47 | OrionPK | input is TFile, lines(input).toSeq() gives that compile time error |
| 00:14:08 | Varriount | for windows, I have to add "-Isrc" etc whenever I'm building nimrod. |
| 00:15:21 | BitPuffin | hrm |
| 00:15:25 | fowl | OrionPK, i get errors doing it too |
| 00:15:30 | BitPuffin | Varriount: did you build on dragonfly? |
| 00:15:52 | Varriount | I just said, "for windows" |
| 00:16:11 | Varriount | No, I did not |
| 00:16:43 | Varriount | I mentioned it, because I read in the logs today that someone mentioned dragonfly |
| 00:16:45 | OrionPK | fowl issue with expr templates maybe? |
| 00:18:27 | fowl | template foo(x:expr):expr = x |
| 00:18:31 | fowl | 42.foo works fine |
| 00:19:18 | BitPuffin | Varriount: well I was thinking maybe you did both |
| 00:19:39 | Varriount | I am a programmer, not a miracle worker. |
| 00:20:30 | Varriount | Though I've used linux in the past, and I know how to get around in it, most of my knowledge about it is theoretical |
| 00:22:43 | Varriount | BitPuffin, I commend you for your bravery, delving into the battlefield of an OS constructed by programmers. |
| 00:23:10 | Varriount | Such constructs don't generally take into account user friendliness |
| 00:24:05 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 00:25:09 | * | ltbarcly joined #nimrod |
| 00:26:32 | * | ltbarcly quit (Client Quit) |
| 00:27:26 | BitPuffin | Varriount: pretty sure all OSs are constructed by programmers :P |
| 00:28:05 | fowl | i heard windows was spawned from random masturbation |
| 00:28:54 | Varriount | fowl, you're talking about Mac OSX |
| 00:29:07 | Varriount | Windows is the one created by binge drinking. |
| 00:29:11 | BitPuffin | I think you are talking about both |
| 00:31:19 | BitPuffin | I cannot fathom |
| 00:31:21 | BitPuffin | WHY |
| 00:31:24 | BitPuffin | does it create a usr directory |
| 00:31:27 | BitPuffin | it makes no sense |
| 00:31:48 | fowl | yes it does |
| 00:32:11 | fowl | it is the missing first / |
| 00:38:47 | OrionPK | https://github.com/Araq/Nimrod/issues/619 |
| 00:50:10 | Varriount | OrionPK, try surounding the something() with parens |
| 00:51:09 | OrionPK | name |
| 00:51:12 | OrionPK | nah* |
| 00:51:13 | OrionPK | doesnt work |
| 00:51:19 | OrionPK | type mismatch: got () |
| 00:51:22 | OrionPK | var info = (something()).toSeq() |
| 00:51:36 | BitPuffin | fowl: but why |
| 00:52:06 | fowl | idk? freebsd is weird |
| 00:52:12 | BitPuffin | not really |
| 00:54:59 | Varriount | OrionPK, the price of somewhat ambiguous grammer |
| 00:55:23 | OrionPK | Hmm? |
| 00:59:05 | fowl | OrionPK, you should note that happens with sequtils.toseq too |
| 00:59:32 | OrionPK | right, but I think it's a compiler issue that if solved would fix toSeq |
| 00:59:40 | OrionPK | add a comment :P |
| 01:00:39 | fowl | k |
| 01:03:07 | fowl | nimrod syntax is on github |
| 01:03:09 | fowl | btw |
| 01:03:12 | fowl | use ```nimrod |
| 01:03:16 | OrionPK | yeah, i know |
| 01:03:25 | OrionPK | I just dont know the markdown syntax :P |
| 01:03:41 | fowl | i just told you |
| 01:03:44 | fowl | open with that instead of ``` |
| 01:03:50 | OrionPK | lol |
| 01:03:56 | OrionPK | I know *now*, thanks |
| 01:04:11 | fowl | yep |
| 01:04:16 | OrionPK | better? |
| 01:04:42 | OrionPK | i wonder if your example is optimized away or something |
| 01:09:33 | fowl | works if i do something with it |
| 01:09:36 | fowl | var y = x + 1 |
| 01:09:36 | fowl | y |
| 01:09:40 | OrionPK | mmk |
| 01:09:47 | OrionPK | just a thing w/ iterator i guess then |
| 01:15:34 | * | cablehea_ quit (Remote host closed the connection) |
| 01:16:02 | * | cablehead joined #nimrod |
| 01:18:50 | Varriount | Waaaiiitttiiinnggg for test to run |
| 01:19:26 | Varriount | Then I can finally hunt down bugs. |
| 01:20:52 | * | cablehead quit (Ping timeout: 265 seconds) |
| 01:28:13 | * | DAddYE quit (Remote host closed the connection) |
| 01:47:58 | * | cablehead joined #nimrod |
| 02:02:06 | Varriount | cablehead, what king of isp do you have? |
| 02:02:23 | OrionPK | potato |
| 02:05:01 | fowl | lol |
| 02:05:05 | fowl | potato with some wires in it |
| 02:09:28 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 02:09:51 | Varriount | Seriously, why all the ping timeouts? |
| 02:10:29 | OrionPK | not just him tho |
| 02:11:08 | * | Varriount never times out... |
| 02:14:04 | * | cablehead quit (Remote host closed the connection) |
| 02:14:33 | * | cablehead joined #nimrod |
| 02:14:56 | EXetoC | I guess your internets are pretty good then |
| 02:16:25 | * | cablehead quit (Read error: Connection reset by peer) |
| 02:16:43 | * | cablehead joined #nimrod |
| 02:16:56 | * | Varriount goes to wavecable.com |
| 02:17:48 | Varriount | Oh. My. God. |
| 02:18:04 | Varriount | My Eyes! -> http://www.wavebroadband.com/ |
| 02:19:56 | EXetoC | looks like shit |
| 02:20:02 | EXetoC | it's also broken. in firefox anyway |
| 02:20:12 | fowl | lol |
| 02:20:25 | EXetoC | overlaps etc |
| 02:29:24 | * | DAddYE joined #nimrod |
| 02:30:20 | * | gdos quit (Quit: *GONE*) |
| 02:36:11 | * | cablehead quit (Remote host closed the connection) |
| 02:36:15 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 02:36:37 | * | cablehead joined #nimrod |
| 02:38:30 | * | ltbarcly joined #nimrod |
| 02:41:12 | * | cablehead quit (Ping timeout: 252 seconds) |
| 02:44:16 | * | fowl quit (*.net *.split) |
| 02:44:33 | * | fowl joined #nimrod |
| 02:44:44 | * | fowl quit (Changing host) |
| 02:44:44 | * | fowl joined #nimrod |
| 03:17:52 | * | fowl quit (Quit: Leaving) |
| 03:24:52 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 03:32:09 | * | DAddYE joined #nimrod |
| 03:34:23 | * | OrionPK quit (*.net *.split) |
| 03:34:23 | * | Varriount quit (*.net *.split) |
| 03:34:49 | * | Varriount joined #nimrod |
| 03:34:49 | * | OrionPK joined #nimrod |
| 03:35:45 | * | wlhlm joined #nimrod |
| 03:35:58 | Varriount | Yay! You guys are back! |
| 03:36:03 | * | Varriount hugs OrionPK |
| 03:36:45 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 03:41:14 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 03:44:51 | OrionPK | yay |
| 03:45:32 | Varriount | OrionPK, are you using Linux as your OS? |
| 03:50:28 | OrionPK | osx and windows primarily |
| 03:52:42 | Varriount | I don't suppose you host the OSX Build bot, do you? |
| 03:52:59 | Varriount | OrionPK ^ |
| 03:56:56 | OrionPK | nope, not I |
| 03:57:07 | OrionPK | couldnt say who does |
| 03:57:18 | Varriount | OrionPK, then could you do me a favor? |
| 03:57:24 | OrionPK | mm maybe |
| 03:57:33 | OrionPK | im knackered right now, though, so it'll have to wait |
| 03:59:48 | OrionPK | going to bed, night |
| 03:59:54 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:03:30 | * | gdos joined #nimrod |
| 04:04:41 | Varriount | Hello gdos |
| 04:05:09 | gdos | hi guys. |
| 04:05:47 | Varriount | What OS are you using at the moment? |
| 04:06:01 | Varriount | And do you have a recent build of nimrod? |
| 04:10:04 | * | brson quit (Ping timeout: 264 seconds) |
| 04:12:15 | * | brson joined #nimrod |
| 04:32:57 | * | DAddYE joined #nimrod |
| 04:33:40 | * | ltbarcly joined #nimrod |
| 04:39:15 | * | wlhlm quit (Ping timeout: 260 seconds) |
| 04:39:21 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 04:44:11 | * | brson quit (Ping timeout: 248 seconds) |
| 04:48:56 | * | Demos joined #nimrod |
| 04:52:30 | Demos | how would I go about calling nimrod from c#? just dump out a C library and link to it? |
| 05:10:28 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 05:17:18 | * | ltbarcly joined #nimrod |
| 05:35:40 | * | DAddYE joined #nimrod |
| 05:40:11 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 06:21:09 | * | q66 joined #nimrod |
| 06:36:10 | * | DAddYE joined #nimrod |
| 06:36:55 | Demos | well if anyone cares you copy the data structures into C# and export procs with {.cdecl,exportc,dynlib.} then you P/Invoke them from C# |
| 06:37:05 | Demos | I just love glue! |
| 06:43:04 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 06:46:49 | * | Demos quit (Read error: Connection reset by peer) |
| 06:58:23 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 07:39:11 | * | DAddYE joined #nimrod |
| 07:43:31 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 08:00:18 | * | Araq_ joined #nimrod |
| 08:39:45 | * | DAddYE joined #nimrod |
| 08:46:26 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 08:53:53 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]) |
| 09:42:42 | * | DAddYE joined #nimrod |
| 09:47:21 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 10:34:03 | * | BitPuffin joined #nimrod |
| 10:43:11 | * | DAddYE joined #nimrod |
| 10:43:23 | * | Araq_ joined #nimrod |
| 10:49:41 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 11:38:36 | BitPuffin | dom96: are you here? :) |
| 11:39:25 | BitPuffin | dom96: I need a little help, I put some js files in public/js/ in my app but referring to them either with or without makeUri gives me a 404 in the server |
| 11:46:12 | * | DAddYE joined #nimrod |
| 11:53:23 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 12:19:52 | * | EXetoC joined #nimrod |
| 12:48:25 | dom96 | hello |
| 12:49:13 | * | DAddYE joined #nimrod |
| 12:50:31 | dom96 | BitPuffin: Keep in mind that 'public' is not part of the url |
| 12:55:33 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 12:59:41 | BitPuffin | dom96: oooh |
| 12:59:46 | BitPuffin | dom96: that might be it then :P |
| 13:02:31 | * | Ricky_Ricardo joined #nimrod |
| 13:27:08 | * | Endy joined #nimrod |
| 13:33:50 | * | ltbarcly joined #nimrod |
| 13:33:55 | * | ltbarcly quit (Client Quit) |
| 13:50:55 | * | Endy quit (Ping timeout: 272 seconds) |
| 13:52:11 | * | DAddYE joined #nimrod |
| 13:58:04 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 13:58:20 | BitPuffin | dom96: how do I destroy a cookie? |
| 13:58:39 | EXetoC | any hard object will do |
| 13:58:53 | dom96 | flamethrower |
| 13:59:22 | BitPuffin | oh come on guys :P |
| 13:59:28 | BitPuffin | water is obviously super effective |
| 14:00:00 | dom96 | true. Just throw some water on top of that PC of yours. |
| 14:01:26 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]) |
| 14:01:33 | BitPuffin | dom96: but seriously, in jester |
| 14:01:37 | BitPuffin | there is only setCookie |
| 14:01:42 | BitPuffin | no dieCookieDie |
| 14:01:59 | dom96 | I quite honestly can't remember how to remove cookies |
| 14:03:27 | BitPuffin | dom96: There doesn't seem to be anything, I guess one could perhaps setCookie("value", "", daysForward(0)= ? |
| 14:03:53 | dom96 | look up how to do it using HTTP |
| 14:04:53 | Ricky_Ricardo | I believe there is a header that will set expiration. Don't know about revoking (if that's what you're trying to do) |
| 14:17:58 | EXetoC | big, static web elements that are unaffected by scrolling sure are annoying |
| 14:18:08 | EXetoC | fortunately it's relatively rare |
| 14:19:26 | * | shevy quit (Ping timeout: 240 seconds) |
| 14:20:35 | EXetoC | my tab bar is 6 rows tall though so that doesn't exactly help. http://wrongsideofmemphis.com/2013/03/25/80-chars-per-line-is-great/ |
| 14:25:27 | * | Ricky_Ricardo quit (Quit: Ricky_Ricardo) |
| 14:33:08 | * | shevy joined #nimrod |
| 14:38:06 | * | wlhlm joined #nimrod |
| 14:38:31 | * | gdos quit (Ping timeout: 245 seconds) |
| 14:41:18 | BitPuffin | Araq: minix not supported by nimrod? :P |
| 14:54:11 | * | DAddYE joined #nimrod |
| 14:57:19 | * | profmakx quit (Ping timeout: 246 seconds) |
| 14:58:15 | * | profmakx joined #nimrod |
| 14:58:38 | * | profmakx is now known as Guest38413 |
| 15:00:52 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 15:06:40 | * | Guest38413 quit (Changing host) |
| 15:06:40 | * | Guest38413 joined #nimrod |
| 15:06:47 | * | Guest38413 is now known as profmakx |
| 15:23:39 | * | Endy joined #nimrod |
| 15:24:51 | * | zanoni quit (Remote host closed the connection) |
| 15:25:13 | * | zanoni joined #nimrod |
| 15:28:54 | BitPuffin | oh wait |
| 15:29:00 | BitPuffin | guess watch isn't being called |
| 15:29:35 | BitPuffin | or wait |
| 15:29:37 | BitPuffin | it is |
| 15:29:39 | BitPuffin | hrm |
| 15:30:30 | BitPuffin | sorry |
| 15:30:34 | BitPuffin | WRONG CHANNEL GUIZE |
| 15:45:32 | * | zanoni quit (Remote host closed the connection) |
| 15:45:46 | * | ltbarcly joined #nimrod |
| 15:45:47 | * | ltbarcly quit (Client Quit) |
| 15:55:28 | * | dyu joined #nimrod |
| 15:56:11 | shevy | hehe |
| 16:03:08 | * | fowl joined #nimrod |
| 16:06:48 | * | gdos joined #nimrod |
| 16:19:31 | * | gdos quit (Remote host closed the connection) |
| 16:20:41 | * | [1]Endy joined #nimrod |
| 16:21:29 | * | io2 joined #nimrod |
| 16:22:41 | * | shodan45 joined #nimrod |
| 16:24:27 | * | Endy quit (Ping timeout: 272 seconds) |
| 16:24:29 | * | [1]Endy is now known as Endy |
| 16:30:03 | * | EXetoC quit (Read error: Connection reset by peer) |
| 16:31:27 | * | EXetoC joined #nimrod |
| 16:39:15 | * | dyu quit (Quit: Leaving) |
| 16:44:08 | * | io2 quit (Ping timeout: 240 seconds) |
| 16:44:11 | * | io2_ joined #nimrod |
| 17:00:47 | * | io2_ quit () |
| 17:04:56 | * | brson joined #nimrod |
| 17:09:11 | * | Associat0r joined #nimrod |
| 17:09:12 | * | Associat0r quit (Changing host) |
| 17:09:12 | * | Associat0r joined #nimrod |
| 17:10:50 | * | DAddYE joined #nimrod |
| 17:17:02 | * | ltbarcly joined #nimrod |
| 17:18:04 | Varriount | dom96, you there? |
| 17:18:08 | dom96 | Varriount: yes |
| 17:19:00 | Varriount | When was the linux builder compiled? |
| 17:19:13 | dom96 | Varriount: Your builder is currently spamming #nimbuild with disconnects btw |
| 17:19:17 | Varriount | As in, what code base is it using? |
| 17:19:27 | Varriount | dom96, Sorry, I took care of it. |
| 17:24:20 | dom96 | Varriount: Last compiled in July. |
| 17:25:50 | Varriount | dom96, I think there's a big regression in ftpclient.nim, and the only reason your builder's aren't affected is because they were built with an older code base. |
| 17:26:11 | dom96 | why ftpclient in particular? |
| 17:26:26 | Varriount | Because ftpclient is what errors when I run the builder |
| 17:26:33 | dom96 | what's the error? |
| 17:27:21 | Varriount | Specifically, it's trying to use sockets.send on a nonblocking socket |
| 17:27:23 | Varriount | Error: unhandled exception: This function cannot be used on non-blocking sockets. [EInvalidValue] |
| 17:27:43 | dom96 | Do you have a traceback? |
| 17:28:06 | Varriount | Traceback (most recent call last) |
| 17:28:06 | Varriount | ftpclient.nim(610) ftpclient |
| 17:28:06 | Varriount | ftpclient.nim(257) connect |
| 17:28:06 | Varriount | ftpclient.nim(132) send |
| 17:28:06 | Varriount | sockets.nim(1515) send |
| 17:28:06 | Varriount | Error: unhandled exception: This function cannot be used on non-blocking sockets. [EInvalidValue] |
| 17:29:23 | Varriount | Actually, the line numbers might be different for you. I wrapped a couple of blocks of code in the blockingOperation template, which stopped it from erroring there |
| 17:29:44 | Araq | I'm here |
| 17:29:51 | Araq | anything important? |
| 17:29:59 | Araq | cause I will leave in 2 minutes |
| 17:30:11 | Varriount | I'm either seeing a major flaw in ftpclient, or going insane. |
| 17:30:14 | dom96 | Araq: When will you be back? |
| 17:30:52 | Araq | dunno. 2-3 hours |
| 17:32:29 | dom96 | interesting. It does look like a bug. |
| 17:33:27 | Varriount | dom96, what happens if you run ftpclient.nim as an executable (compiled) |
| 17:34:52 | dom96 | I think I added that error to send recently |
| 17:34:59 | dom96 | And indeed ftpclient is incorrect. |
| 17:35:38 | * | OrionPK joined #nimrod |
| 17:35:54 | Varriount | Yay! I'm not insane! |
| 17:37:01 | Araq | time is up. bye |
| 17:37:11 | Varriount | Bye Araq |
| 17:41:23 | dom96 | But yeah, just add blockingOperation above line 132 |
| 17:51:40 | Varriount | It's working! |
| 17:52:26 | dom96 | :D |
| 18:01:47 | dom96 | In that case I will make the change and commit the code. |
| 18:02:48 | Varriount | dom96, Doesn't that make the AsyncFTPClient... Not Asyncronous? |
| 18:03:37 | dom96 | kinda, it's asynchronous only for file transfers |
| 18:07:56 | Varriount | :D -> http://build.nimrod-code.org/ |
| 18:12:14 | * | cablehead joined #nimrod |
| 18:12:32 | EXetoC | I installed the recommended vim plugins for nimrod.nim, and now I'm presented with diagnostics and everything |
| 18:12:41 | EXetoC | this shit is the future |
| 18:13:08 | Varriount | Hm, maybe I should try vim again. I'm currently using sublime text for most things. |
| 18:13:20 | Varriount | EXetoC, screenshot? |
| 18:18:25 | EXetoC | no time, shop closes soon :> it just adds a bar that displays stuff when on a line with ">>" on the left side |
| 18:19:12 | * | XAMPP quit (Read error: Connection reset by peer) |
| 18:20:04 | NimBot | Araq/Nimrod master 173ca8d Dominik Picheta [+0 ±1 -0]: Fixed async send in ftpclient module. |
| 18:22:48 | * | Endy quit (Ping timeout: 240 seconds) |
| 18:40:51 | dom96 | Varriount: Why did your builder disconnect? |
| 18:46:27 | Varriount | dom96, "builder.exe stopped working" - windows error message |
| 18:46:38 | dom96 | D: |
| 18:46:39 | Varriount | In other words, it segfaulted |
| 18:46:46 | Varriount | Oh wait, not builder.exe |
| 18:46:54 | Varriount | client.exe, I think |
| 18:47:07 | dom96 | huh |
| 18:47:19 | Varriount | Lemme see if I can find the event log |
| 18:47:47 | dom96 | If builder segfaulted then it must be the same problem that happens on linux. i.e. the corruption |
| 18:47:53 | Varriount | I've gotta go in 3 minutes |
| 18:48:20 | dom96 | no worries |
| 18:51:13 | BitPuffin | Frictional games new sci fi horror game revealed! http://youtu.be/TWHVkMIP1b8 |
| 18:51:19 | BitPuffin | dom96: :) |
| 18:51:37 | dom96 | :O |
| 18:52:35 | Varriount | dom96, Error log here -> http://pastebin.com/GWq6hrQg |
| 18:52:42 | * | zanoni joined #nimrod |
| 18:52:47 | Varriount | Gotta go for now, bye |
| 18:52:52 | * | Varriount is now known as Varaway |
| 18:55:50 | dom96 | BitPuffin: Now THAT is looking awesome. |
| 18:56:04 | dom96 | 2015 COME ONN |
| 18:56:55 | OrionPK | game not written in nimrod? |
| 18:56:56 | BitPuffin | dom96: yeah I know! That was definitely the scariest part of the trailer lol |
| 18:57:16 | BitPuffin | OrionPK: if it was it would have been out already :P |
| 18:57:22 | OrionPK | lol |
| 18:57:46 | OrionPK | cant wait to watch people play this game on youtube |
| 18:58:00 | dom96 | lol. |
| 18:58:19 | dom96 | Have you guys played the new Amnesia yet? |
| 18:58:32 | OrionPK | fuck no, i've watched it played a few times on youtube though :P |
| 18:58:58 | OrionPK | i cant handle scary video games |
| 18:59:06 | OrionPK | i love horrorr movies, but horror games are too much |
| 18:59:21 | dom96 | I played both Penumbra and the first Amnesia. |
| 18:59:37 | dom96 | I haven't completed either. |
| 19:00:45 | OrionPK | :D |
| 19:01:38 | OrionPK | we need a concerted effort to build a game in nimrod I think |
| 19:01:52 | OrionPK | not an overly ambitious one either, just a fun simple one |
| 19:02:15 | dom96 | I agree. |
| 19:05:42 | dom96 | Games are difficult though, mainly because art is required and few people can do art. |
| 19:05:53 | EXetoC | tic-tac-toe or something? |
| 19:05:55 | OrionPK | depends |
| 19:06:09 | OrionPK | for story driven games, most definitely |
| 19:06:24 | OrionPK | for simple, non-AAA games, you dont need a lot of art chops |
| 19:06:29 | fowl | dead space 2 creeped me the f out |
| 19:06:44 | OrionPK | also you can do a lot w/ procedural graphics |
| 19:06:50 | OrionPK | without being a great artist |
| 19:08:03 | fowl | just a mathematician |
| 19:08:31 | OrionPK | :D |
| 19:09:01 | OrionPK | i made a pretty cool looking 3d space environment w/ procedurally generated nebulae several years back |
| 19:09:07 | EXetoC | I've been thinking of making something like dwarf fortress, except with *slightly* less crap graphics |
| 19:09:38 | EXetoC | shouldn't be too hard to make if it's tile-based and all |
| 19:09:53 | fowl | i had something close to treasure arena a while back |
| 19:10:06 | fowl | more rpg like |
| 19:14:45 | BitPuffin | oops |
| 19:14:50 | BitPuffin | and I am building a big game in nimro |
| 19:15:11 | BitPuffin | d |
| 19:15:18 | BitPuffin | you know like, 3d and shit |
| 19:15:24 | EXetoC | it seems a little simplistic, but some RPG elements could add some depth to it |
| 19:15:24 | fowl | cool |
| 19:15:34 | BitPuffin | anyways |
| 19:15:35 | dom96 | let just create a minecraft clone |
| 19:15:38 | BitPuffin | time to bike the dawg |
| 19:15:44 | fowl | clonecraft |
| 19:15:52 | dom96 | nimcraft |
| 19:16:09 | fowl | block: block: block: |
| 19:16:33 | EXetoC | lol |
| 19:16:44 | EXetoC | that's an awesome idea fowl |
| 19:16:46 | dom96 | break; break; break :D |
| 19:17:13 | EXetoC | brilliant |
| 19:17:44 | EXetoC | obfuscated macro awesomeness |
| 19:18:47 | OrionPK | heh |
| 19:21:55 | OrionPK | how about an r-type clone |
| 19:26:55 | dom96 | I don't think i've ever played it, but I am familiar with the genre. |
| 19:27:12 | fowl | will return to being productive after i see the last two episodes of breaking bad |
| 19:32:23 | EXetoC | over a thousand people must watch that show. I keep hearing about it |
| 19:34:04 | * | Varaway is now known as Varriount |
| 19:34:09 | * | Varriount is back |
| 19:34:12 | fowl | way > 1000 |
| 19:35:27 | Varriount | Anyone know if using a try..except statement gives any penalty? |
| 19:35:43 | Varriount | *penalty, performance/memory wise? |
| 19:36:43 | dom96 | I bet it does, but how significant I do not know. |
| 19:36:44 | OrionPK | probably |
| 19:36:46 | OrionPK | do a benchmark |
| 19:38:00 | Varriount | I'm just wondering If I can get away with doing a full context manager template, to emulate python's 'with' statement. |
| 19:46:52 | EXetoC | I'm sure you can |
| 19:48:23 | * | Endy joined #nimrod |
| 19:49:27 | EXetoC | the overhead is quite small judging from what I've read |
| 19:49:54 | * | Associat0r quit (Quit: Associat0r) |
| 19:50:23 | * | Associat0r joined #nimrod |
| 19:50:30 | EXetoC | it doesn't add any noticeable overhead compared to C style return value checking, right? |
| 19:51:12 | dom96 | I'm not sure about the details but I have a hunch that it does. |
| 19:51:54 | OrionPK | check what it generates when it compiles to C |
| 19:53:02 | * | Endy quit (Ping timeout: 264 seconds) |
| 19:55:06 | dom96 | Cumberbatch AMA :O |
| 19:55:17 | OrionPK | link/ |
| 19:55:55 | dom96 | http://www.reddit.com/r/IAmA/comments/1o8l5f/i_am_benedict_cumberbatch_ama/ |
| 19:59:16 | * | dom96 should stop procrastinating |
| 20:01:02 | Varriount | Hm. Looking through winlean.nim.. I se a few uses of int.. |
| 20:01:09 | * | Varriount wonders... |
| 20:04:10 | Varriount | dom96, Do you know who wrote the winlean.nim code? |
| 20:04:39 | dom96 | https://github.com/Araq/Nimrod/commits/master/lib/windows/winlean.nim |
| 20:05:55 | fowl | Varriount, most ints in wrappers should be cint |
| 20:06:09 | Varriount | Yeah, but some aren't |
| 20:06:30 | Varriount | I found one in TerminateProcess that is a plain int |
| 20:07:27 | EXetoC | dom96: you might be right. the overhead should be fairly insignificant on x64 though, which is nice |
| 20:12:23 | Varriount | How would one get the actual code of a statement in a template? Like, a string form of the statement passed? |
| 20:13:49 | * | wlhlm quit (Ping timeout: 265 seconds) |
| 20:14:41 | * | fowl quit (Read error: Operation timed out) |
| 20:18:14 | dom96 | Varriount: astToStr |
| 20:20:10 | EXetoC | is anyone using that function for anything practical? |
| 20:20:15 | Varriount | I am |
| 20:20:22 | dom96 | EXetoC: It's used in assert. |
| 20:20:37 | Varriount | I'm making a print template that prints that name and the value of the variable is is given. |
| 20:22:04 | EXetoC | oh yeah, that's what I used it for :> |
| 20:24:31 | Varriount | EXetoC, care to share? |
| 20:27:23 | shevy | huh |
| 20:27:28 | shevy | I can not build nimrod from another directory? |
| 20:27:31 | shevy | sh ../build.sh |
| 20:27:39 | shevy | gcc: error: build/2_1/nimrod.c: No such file or directory |
| 20:28:26 | Varriount | shevy, I believe the build script uses relative paths. |
| 20:28:26 | EXetoC | maybe just ./build.sh? after changing dir |
| 20:28:44 | shevy | EXetoC yes that works but I tried to build inside a build directory |
| 20:30:38 | Araq | Varriount: 'try' is expensive for the C backend, close to 0 cost for the c++ backend |
| 20:31:07 | Varriount | Araq, you're back! |
| 20:31:09 | OrionPK | whats the advantage to the C backend over the C++ backend |
| 20:31:23 | OrionPK | other than just being more stable |
| 20:31:41 | * | io2 joined #nimrod |
| 20:31:52 | * | fowl joined #nimrod |
| 20:33:06 | Araq | OrionPK: can't think of any advantage except faster compile times |
| 20:33:28 | OrionPK | hm |
| 20:34:25 | Araq | though it's very hard to generate correct C++ |
| 20:34:30 | Araq | thanks to "const" |
| 20:34:34 | Varriount | Araq, is there a list of all the basic data types available (without importing any modules besides the implicit system) available in nimrod |
| 20:34:57 | Araq | well system.nim has generated docs |
| 20:35:05 | EXetoC | Varriount: will share it soon |
| 20:35:07 | OrionPK | was that the reason why you chose to go with C back end |
| 20:35:58 | Araq | I dunno, I think it's because my mindstorm supported C but not C++ :P |
| 20:36:06 | Varriount | OrionPK, C is to C++ what a toaster is to a rocket. |
| 20:36:19 | Varriount | At least, in terms of convolution |
| 20:36:23 | OrionPK | lol |
| 20:36:43 | OrionPK | Varriount, you can write very C-like C++ and compile it with a C++ compiler, and then obtain some benefits of C++ |
| 20:36:48 | Araq | plus as I said C's type system is much more forgiving when it comes to 'const' |
| 20:36:49 | OrionPK | like try..catch performance boost |
| 20:37:02 | OrionPK | or even having try..catch at all built into the language) |
| 20:37:51 | Araq | yeah you also have a chance of handling stuff properly that doesn't map to a flat array of bytes |
| 20:37:52 | OrionPK | obviously wouldnt be pretty idiomatic C++ you generate |
| 20:37:52 | OrionPK | but |
| 20:37:54 | OrionPK | who cares |
| 20:37:58 | OrionPK | the nimrod is what matters |
| 20:38:24 | Araq | actually producing idiomatic code is important for performance |
| 20:38:48 | Araq | compilers tend to optimize idiomatic code pretty well |
| 20:38:56 | Araq | and everything else ... not so much |
| 20:38:57 | OrionPK | wouldnt idiomatic C code perform fairly well with a C++ compiler, generally speaking? |
| 20:39:00 | EXetoC | when will symbols be bound by default? some time before next release? |
| 20:39:16 | Araq | EXetoC: it's in a branch, I only need to merge it |
| 20:39:24 | EXetoC | ok |
| 20:40:08 | Varriount | Symbols? |
| 20:40:52 | Araq | OrionPK: surely C++ compilers handle the C subset well |
| 20:41:30 | EXetoC | Varriount: see 'bind' in the manual |
| 20:42:27 | EXetoC | it avoids having to export certain symbols that are used in templates |
| 20:42:33 | OrionPK | Araq, thats what I said right? :P the C subset that is actually compileable anyway |
| 20:42:52 | EXetoC | if used in another module for example. you'll get the idea soon. uploading my code now |
| 20:44:05 | EXetoC | Varriount: https://gist.github.com/EXetoC/6941738 |
| 20:44:12 | OrionPK | if there are advantages to be gained for runtime performance at the cost of compile time performance.. that seems worth it to me |
| 20:44:14 | EXetoC | is that what you mean? it's pretty simple |
| 20:44:45 | OrionPK | even to switch nimrod to a C++ backend as the default |
| 20:45:08 | EXetoC | I think fast compilations are important, but usually you'll only need maximum performance when shipping anyway |
| 20:45:42 | EXetoC | which is rare in comparison, but it might be worth a mention |
| 20:46:01 | OrionPK | what, shipping nimrod code? :P |
| 20:46:12 | OrionPK | or rather shipping nimrod bits |
| 20:47:12 | EXetoC | yeah shipping/releasing |
| 20:48:36 | OrionPK | I imagine it's easier to implement a lot of high level concepts that nimrod utilizes in the C++ backend |
| 20:48:39 | EXetoC | Varriount: just pass it an expression. it should compile still |
| 20:48:43 | OrionPK | high level things like "try..catch" xD |
| 20:48:53 | EXetoC | right |
| 20:49:21 | OrionPK | and I dont think you would really lose any platform support, would you? |
| 20:50:59 | Araq | OrionPK: except 'try' there is nothing C++ adds which is useful for the backend |
| 20:51:27 | Araq | except perhaps the C++11 styled atomic stuff |
| 20:52:30 | OrionPK | yeah, atomics, maybe in the future the await stuff might be interesting to add language support for |
| 20:52:41 | EXetoC | maybe that low level guy wants to have a go at an efficient C backend impl |
| 20:53:39 | Araq | EXetoC: what do you mean? |
| 20:55:55 | EXetoC | Araq: A C impl that is just as fast. that would require some platform-specific code though |
| 20:56:10 | EXetoC | but he's working on a low level backend, isn't he? |
| 20:56:39 | OrionPK | is it even possible to do efficient try/catch with C even with platform specific code? |
| 20:56:42 | Araq | afaik he finished x86 32/64 code generation and is working on the embedded targets |
| 20:57:46 | Araq | OrionPK: it's not possible; you need to generate some kind of stack maps |
| 20:58:06 | OrionPK | right, so the limitation is C |
| 20:58:10 | Araq | it's a pervasive thing not something you can "fix" with some inline assembler |
| 20:58:12 | OrionPK | not the C generator |
| 20:59:27 | Araq | yes; C is only a "portable assembler" if you have no idea about what an assembler can do |
| 20:59:29 | OrionPK | araq have you given any thought to await type functionality? |
| 20:59:47 | EXetoC | I wonder how optimized his targets are. I'm sure that's a priority nevertheless |
| 20:59:53 | Araq | we're working on it, the implementation is C#-like, OrionPK |
| 21:00:03 | OrionPK | excellent :D |
| 21:00:33 | OrionPK | would something like that not be easier to implement with a C++11 backend than C backend? |
| 21:00:47 | EXetoC | dom96: will that too be ready by christmas? |
| 21:01:06 | Varriount | Araq, you have a minute? I would like you to look at these data type lengths, and tell me if there are any parts of nimrod that need to be changed because of them. |
| 21:01:10 | EXetoC | let's make this the best christmas ever |
| 21:01:10 | Varriount | https://gist.github.com/Varriount/6941963 |
| 21:01:20 | EXetoC | I need to implement something awesome quick |
| 21:01:27 | dom96 | maybe :P |
| 21:01:32 | Varriount | Make an ascii table generator |
| 21:01:46 | Varriount | I just spend 25 minutes on a ascii table by hand. |
| 21:01:50 | Varriount | *spent |
| 21:03:38 | Araq | Varriount: I fixed sizeof(culong): 8 but didn't commit |
| 21:03:53 | EXetoC | that should be simple enough for a nub like me |
| 21:04:11 | Araq | the rest is correct |
| 21:04:23 | Varriount | Araq, Ah, ok. I'm still trying to track down the mysterious socket problem for win64 |
| 21:05:09 | Varriount | Araq, I saw that there were some types in winlean that used plain ints, and wondered if they were supposed to be that way. |
| 21:05:36 | Araq | in general I put some thought into the winlean types |
| 21:05:48 | Araq | can't say the same for windows.nim because it has been translated |
| 21:06:40 | OrionPK | by C# like, something like this? https://gist.github.com/onionhammer/724e32faa960de4600c5 |
| 21:07:12 | Araq | quite, yes |
| 21:07:23 | Araq | syntax is slightly different |
| 21:07:40 | OrionPK | let me guess, more {..}'s ? :P |
| 21:07:57 | Araq | proc foo {.async.} = |
| 21:08:04 | OrionPK | ahhhh I was right |
| 21:08:06 | Araq | let x = await(gah(bah)) |
| 21:08:18 | OrionPK | but await gah(blah) would also work, wouldnt it? |
| 21:08:42 | Araq | we'll see |
| 21:08:46 | OrionPK | you can call procs without () around them |
| 21:08:48 | OrionPK | cant u? |
| 21:08:52 | Araq | it requires grammar changes |
| 21:09:08 | Araq | currently you can only omit the () if it's a statement |
| 21:09:16 | OrionPK | ah |
| 21:09:58 | OrionPK | imo async procedures warrant their own keyword or w/e |
| 21:10:02 | OrionPK | instead of just 'proc' |
| 21:10:57 | Araq | yeah yeah yeah |
| 21:11:03 | Araq | and so do "threads" |
| 21:11:43 | OrionPK | well, I think typing {.thread.} is tedious, but.. |
| 21:11:59 | OrionPK | i hadnt thought of making it "thread" instead of "proc" |
| 21:11:59 | EXetoC | could the brackets and/or dots be removed from the pragma syntax? would that cause problems? |
| 21:12:31 | Araq | EXetoC: only in edge cases, so yeah we can do that |
| 21:12:33 | EXetoC | I hate modifier keys, but again I'm happy with the syntax overall :> |
| 21:13:03 | Araq | however we could also make use of «» for instance |
| 21:13:07 | Araq | unicode ftw |
| 21:13:09 | Varriount | OrionPK, That's what IDE Utilities are for |
| 21:13:17 | OrionPK | Aporia? |
| 21:13:34 | Varriount | I haven't used it, I can't get GTK to compile. |
| 21:13:48 | OrionPK | just download the binaries |
| 21:14:01 | EXetoC | ©n®þ←↓→đð®€ł®€łœ©®€ßđð©ŋđðŋđð”ħđœ®€ł€łœ®þ®←þđðß®€ł©®ł»”↓®€ł I suck at generating unicode chars |
| 21:14:08 | Varriount | Where? |
| 21:14:24 | OrionPK | what platform? |
| 21:14:33 | OrionPK | http://www.gtk.org/download/win32.php |
| 21:14:40 | EXetoC | þ←↓đðß©ħđnðµł@€ł→œ↓þ®←þþœ→↓¨æøĸħłŋðħªðßðħðŋª»ħ«””µ I found both! |
| 21:14:42 | Araq | EXetoC: well you'll learn «» I'm sure and if not you can use {. .} |
| 21:14:44 | OrionPK | http://www.gtk.org/download/index.php |
| 21:14:58 | * | io2 quit () |
| 21:14:59 | Araq | no, download my stuff instead |
| 21:15:02 | Varriount | OrionPK, The 64 bit binary is out of date. |
| 21:15:11 | OrionPK | why not just { } instead of {. .} |
| 21:15:17 | EXetoC | «»«»«»«»«»«»«»«»«»«» |
| 21:15:19 | dom96 | Varriount: http://forum.nimrod-code.org/t/131/2#642 |
| 21:15:27 | EXetoC | people will be hatin' though |
| 21:15:43 | OrionPK | my IRC client does not support this unicode business :p |
| 21:15:47 | Araq | OrionPK: ok that can be made to work too :P |
| 21:16:01 | EXetoC | it's altgr-z/x for me. much better |
| 21:16:37 | Varriount | Personally, I like the {. .} - It makes the pragmas stand out. |
| 21:16:49 | OrionPK | it's nice for them to stand out, but it's also annoying to have to type them |
| 21:17:00 | EXetoC | yep |
| 21:17:08 | Varriount | OrionPK, autocomplete. |
| 21:17:08 | OrionPK | just awkward on the keyboard |
| 21:17:22 | OrionPK | at least with a traditional qwerty keyboard, Im sure all you hackers are on dvorak |
| 21:17:36 | Araq | Varriount: yeah but when I designed the language I didn't imagine they would be everywhere and excessively used |
| 21:17:47 | EXetoC | I suppose I could make a snippet for that |
| 21:17:51 | Araq | so ... it makes sense to beautify them |
| 21:18:08 | Varriount | *shrug* Ok. I'm all for beautification |
| 21:18:16 | OrionPK | woo! go beautify! |
| 21:18:23 | dom96 | I like that they stand out too, they're also easy to highlight this way. |
| 21:18:24 | OrionPK | i'm all on board with making pragmas prettier |
| 21:18:42 | OrionPK | syntax highlighting could make them stand out more dom96 |
| 21:18:48 | Araq | dom96: oh that's a good point |
| 21:18:51 | OrionPK | instead of making the syntax itself ugly |
| 21:19:01 | EXetoC | and that's something you could toggle anyway |
| 21:19:03 | Araq | they are easy for regex based parsers |
| 21:19:12 | Araq | hmm |
| 21:19:15 | OrionPK | yeah but thats not something you should worry about imo |
| 21:19:25 | OrionPK | how syntax highlighter writers are going to be taxed :P |
| 21:20:01 | EXetoC | as long as we don't enter C++ territory :> |
| 21:20:06 | OrionPK | could just add loads of other keywords in like C++... |
| 21:20:07 | OrionPK | :P |
| 21:20:26 | OrionPK | proc await const myProcName() = :P |
| 21:20:47 | OrionPK | proc await template thread myProcName() |
| 21:21:12 | Varriount | God no. |
| 21:21:22 | dom96 | /kick OrionPK |
| 21:21:23 | Araq | btw template vs macro is a design flaw in the language but it's too late to change that imo |
| 21:21:24 | OrionPK | :D |
| 21:21:27 | dom96 | :P |
| 21:21:42 | Araq | whether it's a macro or a template is only an implementation detail |
| 21:21:52 | Varriount | Araq, don't be afraid to depracate. |
| 21:21:52 | Araq | so the language should only expose "macro" |
| 21:22:05 | Varriount | Otherwise nimrod could end up like C++ |
| 21:22:18 | OrionPK | yeah, deprecating things now is better than after 1.0 |
| 21:22:23 | EXetoC | sounds like a search/replace will almost do |
| 21:22:34 | Araq | Varriount: ok but perfect is the enemy of good |
| 21:23:02 | Araq | and the successful languages all stopped at one point to improve and went for stability instead |
| 21:23:17 | Varriount | C++ : 50 million features, all trying to fix each other. |
| 21:23:21 | OrionPK | what if pragmas went on the next line |
| 21:23:28 | Varriount | Or returns |
| 21:23:34 | OrionPK | under the proc declaration |
| 21:23:40 | Araq | well we can fix this template vs macro issue after 1.0 too |
| 21:23:53 | Araq | when we know how it should work |
| 21:23:54 | profmakx | and then there was python! |
| 21:24:03 | Araq | because now I only know it's wrong :P |
| 21:24:08 | Varriount | I've always wondered why languages don't do something like: |
| 21:24:13 | Araq | not how to make it better ;-) |
| 21:24:22 | Varriount | def foo(x:int, y:string): |
| 21:24:27 | Varriount | returns int |
| 21:24:48 | Varriount | (body) |
| 21:24:55 | Varriount | return 5 |
| 21:25:02 | Varriount | ^ return 5 |
| 21:25:03 | Araq | Varriount: that's kind of what Ada does |
| 21:25:07 | OrionPK | how about ! for pragmas, that stands out |
| 21:25:09 | Araq | and it's verbose and sucks |
| 21:25:14 | OrionPK | \proc someProc(a: int) !async! |
| 21:25:30 | EXetoC | def\nfoo\n(\nint x\nint y\n)\n |
| 21:25:39 | Araq | OrionPK: most of these things vanish as soon as you realize that nimrod supports user defined operators |
| 21:26:04 | Araq | leaving you with nicely few alternatives how the syntax should look like :P |
| 21:26:06 | OrionPK | Araq yeah but you'd process away the pragmas before getting to the user defined stuff, right? |
| 21:26:15 | Araq | wrong |
| 21:26:17 | OrionPK | :S |
| 21:26:41 | OrionPK | are you saying you could write code like that now with user defined operators? |
| 21:26:46 | OrionPK | proc someProc(a: int) !async! |
| 21:26:46 | EXetoC | d\nfoo\nint x\nint y#pragmas\nrettype\nbody that's a little more compact character-wise |
| 21:26:49 | dom96 | proc someProc(a: int) ~ async = |
| 21:26:55 | OrionPK | ooh I like that dom |
| 21:27:04 | OrionPK | like the proc jizzed out some pragmas |
| 21:27:08 | dom96 | lol |
| 21:27:13 | Araq | OrionPK: not quite but proc someProc(a: int): !gah works |
| 21:28:08 | OrionPK | well, { } would still be an improvement upon {. .}, can we agree on that? |
| 21:28:20 | OrionPK | dunno if it makes it harder to parse.. |
| 21:28:24 | Araq | actually we can't as {. } already works |
| 21:28:31 | Araq | and keeps it easy to syntax highlight |
| 21:28:57 | EXetoC | p foo#a, b: int#pragmas#rettype\n body |
| 21:28:59 | EXetoC | nailed it |
| 21:29:00 | Varriount | Besides pragmas, is there anywhere else nimrod uses {}? |
| 21:29:08 | EXetoC | no wait, # is for comments |
| 21:29:11 | EXetoC | Varriount: sets |
| 21:29:20 | Araq | Varriount: yes, set and table constructors |
| 21:29:25 | EXetoC | iz awesome |
| 21:29:36 | OrionPK | how about // |
| 21:29:37 | OrionPK | :P |
| 21:29:44 | OrionPK | we'll be the opposite of C |
| 21:29:51 | OrionPK | / for pragmas and # for comments |
| 21:29:57 | OrionPK | //* |
| 21:30:10 | Varriount | What about ` |
| 21:30:41 | Araq | Varriount: already used to turn operators into ordinary identifiers |
| 21:30:46 | OrionPK | /pragma/ |
| 21:30:50 | Araq | `+`(a, b) |
| 21:30:57 | Varriount | ~? |
| 21:30:57 | OrionPK | separate with / |
| 21:31:03 | OrionPK | that would look pretty, right? |
| 21:31:10 | * | Associat0r quit (Quit: Associat0r) |
| 21:31:27 | OrionPK | proc someProc(..) /async/thread/ = ... |
| 21:31:53 | OrionPK | or async,thread |
| 21:32:07 | OrionPK | since you wouldnt want to make it seem thread belonged to async (in this isntance) |
| 21:34:15 | fowl | hi alternate syntax easy to add, so do it if the syntax bothers you so much |
| 21:36:00 | EXetoC | lemme just submit a poll first :> |
| 21:36:15 | OrionPK | obviously i like nimrod's syntax by-and-large |
| 21:36:17 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 21:36:28 | OrionPK | and I like to bend other people to my will |
| 21:36:29 | OrionPK | so |
| 21:36:36 | fowl | of course, its just the small things that bother you, right |
| 21:37:04 | EXetoC | yep! |
| 21:40:40 | EXetoC | not really, but they started it |
| 21:40:46 | EXetoC | or was it me? |
| 21:41:36 | * | gurug33k joined #nimrod |
| 21:42:11 | Varriount | My only irritation with nimrod is that the syntax for return types is a bit funky (but it does make sense), and that the syntax can seem a bit ambiguous/context sensitive at times. |
| 21:42:43 | Varriount | But those are minor annoyances, I have those with every language. |
| 21:43:00 | fowl | syntax for return types? |
| 21:43:22 | OrionPK | you mean : type? |
| 21:43:31 | Varriount | proc name(params): type = |
| 21:43:46 | OrionPK | i mean, it's the same as parameter types |
| 21:43:49 | OrionPK | it's consistent |
| 21:43:50 | Varriount | It's the ': type =' equals |
| 21:43:52 | EXetoC | that I consider minor, and it's not hard to type, but to each his own |
| 21:44:20 | Araq | I picked : type = over -> type: because it made more sense to me |
| 21:44:41 | Araq | but it's a close call and we had to re-introduce -> for the 'do' notation |
| 21:44:52 | fowl | support both |
| 21:44:53 | fowl | seriously |
| 21:45:05 | fowl | i can probably do that |
| 21:45:10 | Araq | we do support -> and : for procs too iirc |
| 21:45:13 | Varriount | No, please don't |
| 21:45:30 | fowl | nope |
| 21:45:57 | Varriount | I would like my fingers to stay in their normal shape, thankyouverymuch |
| 21:46:20 | Araq | Varriount: supporting "both" means you don't have to adapt |
| 21:46:37 | fowl | Araq, i think i can make that change |
| 21:46:37 | EXetoC | well, he said both, but that seems unnecessary unless the purpose is migration |
| 21:47:11 | Araq | *shrug* oh well, just leave it as it is |
| 21:47:25 | Araq | the people who care already don't like it |
| 21:47:30 | fowl | itd just be nice that it can be consistent with do()->: |
| 21:47:36 | Araq | and there is no chance to get them back |
| 21:47:52 | Araq | because it's not python-like enough anyway |
| 21:48:05 | dom96 | personally I would like: (int, int) -> string for proc types instead of having to write: proc (a: int, b: int): string. |
| 21:48:15 | fowl | ^ |
| 21:48:17 | * | ltbarcly joined #nimrod |
| 21:49:25 | fowl | i'd also say that ^ should mean pointer, [4] ^ int should be an array of four pointer to int |
| 21:49:27 | fowl | but thats just me |
| 21:52:56 | EXetoC | dom96: that's a shortcut though so it serves a purpose, but you lose some self-documentation in that case |
| 21:59:50 | dom96 | yeah, so you will be able to choose between the shortcut and the full syntax. |
| 22:01:30 | EXetoC | is it often obvious for you what the args are for? |
| 22:01:48 | BitPuffin | Araq: I managed to compile nimrod on netbsd |
| 22:02:08 | BitPuffin | Araq: But when compiling babel it looks for lib in the babel directory instead of the nimrod directory |
| 22:02:38 | EXetoC | BitPuffin: you are on fire. might I suggest templeos next? |
| 22:02:44 | Araq | BitPuffin: interesting how did you fix the /usr vs usr issue? |
| 22:02:53 | dom96 | EXetoC: yes |
| 22:03:01 | fowl | EXetoC, haha |
| 22:03:16 | fowl | EXetoC, i tried that before it was all biblified |
| 22:03:23 | fowl | so many blinking things |
| 22:03:54 | EXetoC | :> |
| 22:03:59 | dom96 | Actually, in regards to templeos wouldn't the guy that made it find Nimrod in line with his beliefs because of his obsession with the bible and the fact that Nimrod is a name from the bible? |
| 22:04:38 | EXetoC | dom96: no wait, when is the actual name omitted in a declaration? |
| 22:04:51 | EXetoC | good point |
| 22:05:00 | * | ltbarcly quit (Quit: Computer has gone to sleep.) |
| 22:05:12 | EXetoC | did you just omit that part? |
| 22:05:13 | fowl | EXetoC, it can be omitted in C |
| 22:08:53 | EXetoC | nothing comes to mind, but ok I believe you |
| 22:10:04 | * | ltbarcly joined #nimrod |
| 22:10:19 | fowl | try it typedef (*foo)(int,char*); |
| 22:10:24 | * | ltbarcly quit (Client Quit) |
| 22:10:38 | fowl | er |
| 22:10:39 | fowl | u know |
| 22:10:40 | dom96 | If you ever used Haskell all you would see is: Type -> Int -> String -> (Type2 -> Int) |
| 22:11:42 | dom96 | The type for map for example is: (a -> b) -> [a] -> [b] |
| 22:12:00 | fowl | int foo(int) {} should be valid c |
| 22:12:12 | BitPuffin | Araq: I didn't |
| 22:12:19 | BitPuffin | Araq: it worked on netbsd but not freebsd |
| 22:12:37 | BitPuffin | Araq: still didn't show the / though :s |
| 22:13:00 | EXetoC | fowl: oh. I meant the actual name of the function, which would be foo in this case |
| 22:13:07 | EXetoC | anyway, nevermind |
| 22:14:22 | BitPuffin | EXetoC: hahaha wasn't that the christian psycho os? |
| 22:15:06 | EXetoC | BitPuffin: he's not that crazy, really. check out his tunes on youtube |
| 22:15:56 | BitPuffin | EXetoC: lol: :) some other time |
| 22:18:15 | BitPuffin | Araq: Where do you think I should look for the error? |
| 22:19:13 | EXetoC | http://www.youtube.com/watch?v=u3DcbkR1Ugc hm, weren't some of these tunes slightly more rubbish? |
| 22:21:19 | EXetoC | ok I need to shut up and maybe do something of value |
| 22:22:44 | BitPuffin | Araq: It is when running babel install that it fails btw, not when compiling babel |
| 22:22:47 | fowl | songs by god and me |
| 22:22:54 | fowl | god and i* |
| 22:23:17 | BitPuffin | Araq: So the error must be something that it checks the process path or something to find the lib directory, but since we are invoking babel and not nimrod the executable is in the wrong place |
| 22:23:21 | BitPuffin | Araq: that's my guess at least |
| 22:23:21 | Araq | BitPuffin: I don't know and please stop bothering me for now |
| 22:23:36 | Araq | there are much more important things to do than bsd support |
| 22:25:08 | BitPuffin | maybe the issue is with babel actually |
| 22:25:24 | BitPuffin | since it is when running babel install it fails |
| 22:25:47 | BitPuffin | Araq: funny that you support Mac OSX then :p |
| 22:29:15 | BitPuffin | anyways dom96 I am having a look at babel |
| 22:29:27 | EXetoC | but isn't the market share several times higher? |
| 22:29:33 | EXetoC | or are they fairly compatible still? |
| 22:33:19 | BitPuffin | What's the procedure for getting the path of the current process? |
| 22:33:53 | EXetoC | didn't you answer that question for me though? :p |
| 22:34:40 | BitPuffin | EXetoC: I dunno xD |
| 22:34:55 | gurug33k | for desktop I doubt anyone uses netbsd |
| 22:35:21 | gurug33k | but for servers may be more ppl use *BSD than OS X I guess |
| 22:35:37 | BitPuffin | yeah most definitely |
| 22:35:41 | BitPuffin | especially freebsd |
| 22:36:32 | gurug33k | althou I have some mac mini servers and they do work very well |
| 22:36:46 | gurug33k | in general there is more support for OSX stuff as many developers use OS X I think |
| 22:36:52 | BitPuffin | yeah, but most system admins don't use OSX for servers |
| 22:36:55 | gurug33k | just like since ppl use it they want to work on it |
| 22:36:57 | BitPuffin | most use Linux :P |
| 22:37:06 | BitPuffin | and I think osx is probably somewhere in the bottom |
| 22:37:11 | gurug33k | yes of course linux #1 |
| 22:38:00 | gurug33k | but many web programmers use OS X lot of ruby ppl this is why they made the brew to install some stuff that didn't usually install that easily on OSX |
| 22:38:35 | EXetoC | "be careful when using boiling water" thank you internet |
| 22:39:48 | BitPuffin | gurug33k: sure they might be using osx for coding, but usually not for deployment |
| 22:40:02 | gurug33k | yes right |
| 22:40:54 | BitPuffin | Araq: And I am not currently asking YOU to fix it, I am just wondering what modules might be relevant to look at. Since you have the entire project structure in the head |
| 22:53:25 | * | brson quit (Quit: leaving) |
| 22:53:43 | * | brson joined #nimrod |
| 23:03:01 | BitPuffin | Araq: Anyways, don't complain that people don't want to help you fix bugs if you don't even take the time pointing them in the right direction. Just saying, finding your way around a compiler is a daunting task if you didn't write it yourself. |
| 23:14:27 | dom96 | Araq already spends a lot of his time helping people, you can't expect him to spend his whole time answering your questions. |
| 23:17:22 | BitPuffin | I'm not expecting that |
| 23:18:43 | BitPuffin | I'm just saying if he expects people to help him fix stuff, he needs to help them help him |
| 23:23:20 | fowl | im writing game state stuff... again |
| 23:23:35 | fowl | this time i should save the code so i dont have to do it.. again |
| 23:24:05 | EXetoC | that's not a bad idea |
| 23:28:05 | BitPuffin | fowl: maybe turn it in to a lib? |
| 23:28:46 | fowl | now im realizing that it needs to be more specialized |
| 23:29:07 | fowl | so taking half of the code from fowltek/sdl2/engine and merging it into the game state manager |
| 23:48:04 | OrionPK | writing your own engine? |
| 23:49:00 | fowl | just a basic one |