| 00:00:45 | * | fredmorcos quit (Quit: Leaving) |
| 00:16:17 | * | freezerburnv joined #nimrod |
| 00:16:54 | * | freezerburnv quit (Client Quit) |
| 00:29:00 | * | MFlamer quit (Ping timeout: 268 seconds) |
| 00:45:48 | Varriount | Anyone know what system.safeAdd is meant for? |
| 00:46:19 | * | vidot_j joined #nimrod |
| 00:46:26 | vidot_j | hi all |
| 00:46:29 | Varriount | Hello vidot_j |
| 00:47:40 | vidot_j | Can you tell me how I can get the arguments passed with "nimrod compile --run file.nim arg1 arg2" into my code ? |
| 00:47:59 | fowl | vidot_j, paramStr() and paramCount() |
| 00:48:10 | fowl | or use optparse module |
| 00:48:10 | vidot_j | thanks fowl ^^ |
| 00:49:29 | EXetoC | Varriount: if you check the definition you'll see that it prevents a crash in case of a nil input |
| 00:49:41 | EXetoC | and the plans are to make that the default IIRC |
| 00:50:17 | vidot_j | yes i read the doc ^^ |
| 00:50:32 | Varriount | EXetoC, crash as in, complete program crash, or crash as in, an error is thrown? |
| 00:52:04 | EXetoC | segfault basically, since it's a null dereference, except you get a nice custom error message |
| 00:52:11 | EXetoC | I wonder if it appears in release mode as well |
| 00:52:35 | Varriount | Meh, I rarely use release mode. |
| 00:52:44 | Varriount | It's for... releases |
| 00:53:15 | * | webskipper quit (Ping timeout: 272 seconds) |
| 00:53:23 | EXetoC | yup, what it says on the tin basically :p |
| 00:54:10 | EXetoC | the plan is also for strings and sequences to default to "" and @[] respectively |
| 00:54:16 | OrionPK | *sigh* why are the slutty ones always christian |
| 00:54:35 | Varriount | Thing is, I rarely ever need the speed, but I often need the error information. |
| 00:54:42 | Varriount | OrionPK, hard night? |
| 00:55:00 | OrionPK | nah |
| 00:55:10 | Varriount | EXetoC, I even have the compiler compiled in debug mode. |
| 01:24:06 | * | freezerburnv joined #nimrod |
| 01:25:58 | EXetoC | Varriount: yeah might as well do if speed isn't a concern, which it generally isn't so that's nice |
| 01:29:32 | * | Ricky_Ricardo joined #nimrod |
| 01:36:13 | * | brson quit (Ping timeout: 272 seconds) |
| 01:37:52 | * | brson joined #nimrod |
| 01:43:06 | * | DAddYE quit (Remote host closed the connection) |
| 01:43:42 | * | DAddYE joined #nimrod |
| 01:45:01 | * | DAddYE_ joined #nimrod |
| 01:48:15 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 01:49:02 | * | DAddYE_ quit (Ping timeout: 240 seconds) |
| 02:20:17 | * | freezerburnv quit (Quit: freezerburnv) |
| 02:40:28 | * | Ricky_Ricardo quit (Quit: Ricky_Ricardo) |
| 02:41:53 | shevy | hmm |
| 02:42:01 | shevy | are there speed comparisons with nimrod? as in how it compares to other languages? |
| 02:42:27 | xenagi | shevy, yea |
| 02:42:29 | xenagi | nimrod is fast |
| 02:42:32 | xenagi | ^ |
| 02:43:29 | shevy | ok |
| 02:43:32 | shevy | nimrod is slow |
| 02:43:40 | shevy | but now we need some way to verify those two statements |
| 02:43:41 | shevy | :( |
| 02:45:37 | xenagi | someone wrote a blog with a benchmark |
| 02:45:41 | * | DAddYE joined #nimrod |
| 02:45:57 | xenagi | i cba to find it again tho |
| 02:46:03 | xenagi | i'm sure if you google it, it'll turn up |
| 02:46:36 | shevy | hmm one seems to be at http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/ |
| 02:50:01 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 03:12:25 | Varriount | Meep |
| 03:12:45 | * | Varriount has about 1/2 of the python itertools module translated to nimrod |
| 03:13:48 | xenagi | oh nice |
| 03:15:01 | * | fowl quit (Ping timeout: 272 seconds) |
| 03:27:03 | * | fowl joined #nimrod |
| 03:31:50 | * | brson quit (Ping timeout: 240 seconds) |
| 03:46:29 | * | DAddYE joined #nimrod |
| 03:49:29 | Varriount | Araq, dom96, under what circumstances does an iterator maintain its state? As in, how would I, say, pass around a variable with a countUp iterator that has been initialized with the arguments 1, 20? |
| 03:50:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 03:51:35 | fowl | Varriount, when its a closure |
| 03:51:49 | fowl | countup is inline iterator |
| 03:52:01 | Varriount | -_- |
| 03:52:33 | * | Varriount feels silly |
| 03:56:10 | * | mflamer joined #nimrod |
| 03:58:38 | Varriount | fowl, so, now I'm confused. Why does this output 1, and then 2? -> https://gist.github.com/Varriount/7348747 |
| 03:59:44 | fowl | thats what you want |
| 04:00:17 | Varriount | fowl, sorry, look at the gist again, I mis-pasted |
| 04:02:08 | fowl | i dunno how it works |
| 04:02:38 | fowl | you should be able to call x() after the first call with args |
| 04:03:26 | Varriount | I guess I'm just unused to nimrod iterators. In python-land, an iterator is a function-like *object*. Nimrod seems to think of an iterator as something more like an inside-out function |
| 04:03:57 | Varriount | Although... |
| 04:07:47 | * | vidot_j quit (Remote host closed the connection) |
| 04:09:44 | Varriount | fowl, here's something wierd -> https://gist.github.com/Varriount/7348835 |
| 04:10:04 | Varriount | A sliding average, of sorts. |
| 04:12:06 | fowl | tbh ive only messed with closure iters with no params so i dont know whats going on |
| 04:13:45 | Varriount | Well, I think what's happening is that when the iterator is being advanced, it's references to the parameters its passed are always being updated. |
| 04:14:15 | Varriount | It's interesting behavior, akin to python iterator's send() method. |
| 04:16:52 | fowl | yea |
| 04:18:28 | Varriount | Well, goodnight |
| 04:19:13 | fowl | good night |
| 04:33:42 | * | jdp_ is now known as jdp |
| 04:47:25 | * | DAddYE joined #nimrod |
| 04:51:43 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:51:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 04:56:29 | * | fowl quit (Quit: Leaving) |
| 05:15:22 | * | xenagi quit (Quit: Leaving) |
| 05:18:47 | * | Demos joined #nimrod |
| 05:22:49 | Demos | anyone have a little circle between working on c++ projects and nimrod projects. It is like "c++ has these nice libraries but is painful ima go work on nimrod tools <-> nimrod has all these nice features but no tools ima go work on c++ |
| 05:48:11 | * | DAddYE joined #nimrod |
| 05:51:58 | * | ponce is now known as Guest33859 |
| 05:51:58 | * | Guest33859 quit (Killed (moorcock.freenode.net (Nickname regained by services))) |
| 05:52:21 | * | p0nce joined #nimrod |
| 05:52:37 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 06:28:17 | * | Demos quit (Read error: Connection reset by peer) |
| 06:49:00 | * | DAddYE joined #nimrod |
| 06:50:19 | * | shevy quit (Ping timeout: 260 seconds) |
| 06:50:38 | * | mflamer quit (Ping timeout: 240 seconds) |
| 06:53:02 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 06:54:22 | * | mflamer joined #nimrod |
| 07:02:42 | * | shevy joined #nimrod |
| 07:04:28 | * | mflamer quit (Ping timeout: 244 seconds) |
| 07:39:36 | * | DAddYE joined #nimrod |
| 08:43:02 | * | dyu joined #nimrod |
| 09:18:25 | * | Araq_ joined #nimrod |
| 09:31:01 | * | CarpNet joined #nimrod |
| 09:33:27 | * | DAddYE quit (Remote host closed the connection) |
| 09:39:24 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]) |
| 10:06:14 | * | mkb quit (Ping timeout: 240 seconds) |
| 10:21:11 | * | mkb joined #nimrod |
| 10:34:36 | * | DAddYE joined #nimrod |
| 10:38:46 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 11:13:32 | * | freezerburnv joined #nimrod |
| 11:17:02 | * | Araq_ joined #nimrod |
| 11:17:48 | * | Araq_ quit (Client Quit) |
| 11:31:22 | * | faassen joined #nimrod |
| 11:32:04 | * | dyu quit (Disconnected by services) |
| 11:32:38 | * | dyu_ joined #nimrod |
| 11:35:25 | * | DAddYE joined #nimrod |
| 11:39:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 11:39:45 | * | freezerburnv quit (Quit: freezerburnv) |
| 11:54:16 | * | BitPuffin joined #nimrod |
| 11:54:54 | BitPuffin | yoho yoho! |
| 12:01:07 | EXetoC | hi |
| 12:14:36 | * | q66_ joined #nimrod |
| 12:16:55 | * | Zor_ joined #nimrod |
| 12:20:43 | * | Raynes_ joined #nimrod |
| 12:21:44 | * | faassen quit (*.net *.split) |
| 12:21:46 | * | q66 quit (*.net *.split) |
| 12:21:46 | * | Zor quit (*.net *.split) |
| 12:21:47 | * | Raynes quit (*.net *.split) |
| 12:21:48 | * | rndbit quit (*.net *.split) |
| 12:22:14 | * | rndbit joined #nimrod |
| 12:22:17 | * | Raynes_ is now known as Raynes |
| 12:22:26 | * | Raynes quit (Changing host) |
| 12:22:26 | * | Raynes joined #nimrod |
| 12:22:30 | * | q66_ is now known as q66 |
| 12:27:44 | * | faassen joined #nimrod |
| 12:36:11 | * | DAddYE joined #nimrod |
| 12:39:08 | * | freezerburnv joined #nimrod |
| 12:40:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 12:42:27 | BitPuffin | hey EXetoC what's up? |
| 12:43:31 | * | Varriount_ joined #nimrod |
| 12:43:31 | EXetoC | BitPuffin: writing a parser |
| 12:43:41 | freezerburnv | Mornin all |
| 12:47:00 | * | Varriount quit (Ping timeout: 265 seconds) |
| 12:47:19 | * | Jackneill joined #nimrod |
| 12:49:39 | BitPuffin | EXetoC for your language? |
| 12:49:47 | BitPuffin | morning freezerburnv |
| 12:49:49 | EXetoC | yes |
| 12:56:13 | * | Ricky_Ricardo joined #nimrod |
| 13:04:32 | BitPuffin | dom96: why is varchar used for post content instead of text in nimforum? |
| 13:32:30 | * | Jackneill quit (Ping timeout: 244 seconds) |
| 13:32:53 | * | Jackneill joined #nimrod |
| 13:37:14 | * | DAddYE joined #nimrod |
| 13:41:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 13:44:28 | * | webskipper joined #nimrod |
| 13:51:59 | webskipper | does support nimrod real threads ? |
| 13:52:13 | webskipper | distributed on multi cores ? |
| 14:02:33 | profmakx | why shouldn't it? |
| 14:12:00 | EXetoC | there's no reason it shouldn't, but what exactly do you mean? you could just use posix threads if you really wanted to |
| 14:12:33 | EXetoC | if for some reason more high level constructs weren't available. I don't know the details, but I think a couple of libs in the standard lib might be of relevance |
| 14:12:51 | BitPuffin | pretty sure the threading in nimrod uses real cores |
| 14:13:00 | EXetoC | they are working on improving it though |
| 14:13:12 | * | OrionPK joined #nimrod |
| 14:19:04 | EXetoC | webskipper: see the core section in the library documentation. about three modules seem relevant |
| 14:19:20 | EXetoC | and the asyncio branch is also of relevance, right? |
| 14:23:49 | EXetoC | do all the major platforms allow threads to be spread out evenly? because of load-balancing and so on |
| 14:24:47 | Varriount_ | webskipper, nimrod != python |
| 14:24:53 | * | Varriount_ is now known as Varriount |
| 14:26:08 | webskipper | system module doc is too big, really |
| 14:26:15 | webskipper | one page... |
| 14:26:30 | Varriount | *shrug* it's autogenerated |
| 14:26:34 | webskipper | and module threads we should not use.... |
| 14:27:04 | Varriount | webskipper, you can use threads |
| 14:27:10 | Varriount | Er, the threads module |
| 14:27:12 | webskipper | Varriount: sure but thats not the point |
| 14:27:22 | Varriount | You just can't import it *explicitly* |
| 14:27:26 | webskipper | No I am not allowed ^^ |
| 14:27:40 | webskipper | "Do not import it explicitly." |
| 14:27:56 | webskipper | "Do not import it directly. " |
| 14:28:24 | Varriount | webskipper, it's imported the same way the system module is imported. |
| 14:28:34 | Varriount | automatically. |
| 14:28:42 | webskipper | ok |
| 14:30:15 | EXetoC | yes, says it here http://nimrod-code.org/threads.html |
| 14:30:44 | Varriount | Araq, dom96, have you considered having someone clean up the tickets a bit? I've noticed that at least 3 tickets for the same bug (lack of implicitly generic lambdas) |
| 14:36:16 | EXetoC | you can cross-reference issues if you want |
| 14:36:57 | Varriount | EXetoC, they're all reports for the *same* issue |
| 14:37:56 | EXetoC | yes but I don't know if they are aware of that |
| 14:38:27 | * | DAddYE joined #nimrod |
| 14:39:03 | Varriount | Well, some of the issues are 3+ months old |
| 14:42:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 14:57:58 | webskipper | hmm, aporia: could not load: libglib-2.0-0.dll |
| 15:01:07 | webskipper | ok, had to restart the shell |
| 15:04:13 | webskipper | hmm, does not work really. no fullcreen and i cant edit the code :/ |
| 15:07:41 | EXetoC | any terminal output? |
| 15:13:04 | CarpNet | i think i'm hitting a bug in the compiler when compiling this (narrowed it down) https://gist.github.com/acolley/7356220 |
| 15:13:23 | CarpNet | i get a "SIGSEGV: Illegal storage access. (Attempt to read from nil?)" |
| 15:13:53 | CarpNet | in the case of a proc though it correctly catches the bug (the : at the end of the declaration instead of an = for the method/proc body) |
| 15:16:16 | CarpNet | i'll open an issue about it if it's not already been seen before |
| 15:17:39 | EXetoC | http://www.kotaku.com.au/2012/05/epics-tim-sweeney-next-gen-needs-more-power-and-more-open-platforms/ isn't that Tim Sweeney the DJ? |
| 15:17:48 | EXetoC | Apparently he's also the founder of Epic. amazing |
| 15:17:57 | EXetoC | that's some bad journalism right there |
| 15:32:35 | * | p0nce is now known as ponce |
| 15:39:03 | * | DAddYE joined #nimrod |
| 15:41:20 | * | dymk quit (Ping timeout: 260 seconds) |
| 15:43:43 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 15:59:12 | * | dymk joined #nimrod |
| 16:03:58 | BitPuffin | OrionPK: any chance you'll refactor out your sha1 implementation into a separate lib than websockets? |
| 16:04:15 | BitPuffin | so that we can do babel install sha1 |
| 16:04:43 | OrionPK | Bitpuffin yeah, when I submit them to babel they will be separate |
| 16:05:00 | BitPuffin | OrionPK: cool! |
| 16:05:06 | BitPuffin | can we really trust sha1 though? |
| 16:05:11 | BitPuffin | It was designed by the NSA :P |
| 16:05:31 | OrionPK | for websockets it's not used for security purposes |
| 16:08:26 | BitPuffin | OrionPK: by the way if it already works why not submit it immediately to babel? |
| 16:08:31 | BitPuffin | the sha1 I mean |
| 16:10:39 | OrionPK | patience :P |
| 16:10:58 | BitPuffin | :'( |
| 16:13:54 | BitPuffin | OrionPK: do you also plan to implement other sha algos? |
| 16:15:03 | OrionPK | no |
| 16:15:52 | Varriount | Araq, ping |
| 16:17:22 | BitPuffin | aw :( |
| 16:18:38 | Varriount | BitPuffin, fowl and I found something interesting with iterators last night. |
| 16:21:34 | EXetoC | fowl and you, or Bitpuffin and fowl and you? |
| 16:21:39 | EXetoC | ambiguous comma :p |
| 16:24:46 | Varriount | fowl and I. |
| 16:24:56 | Varriount | EXetoC, BitPuffin, https://gist.github.com/Varriount/7348835 |
| 16:25:04 | * | MFlamer joined #nimrod |
| 16:27:06 | dom96 | hi guys |
| 16:27:10 | dom96 | what's up? |
| 16:27:14 | BitPuffin | hey dom96! |
| 16:27:25 | Varriount | dom96, tickets need managing. |
| 16:27:28 | BitPuffin | Varriount: what's the output? and does that have to do with me >.< |
| 16:27:56 | dom96 | Varriount: Manage them then |
| 16:28:25 | Varriount | dom96, I don't have the right privledges. |
| 16:29:05 | dom96 | Varriount: What sort of managing do they need? |
| 16:29:36 | EXetoC | s/: int/: string |
| 16:30:14 | Varriount | dom96, some are duplicates, some are questions that have been answered, etc |
| 16:30:15 | EXetoC | I was that yesterday, but this example is a little clearer |
| 16:30:41 | dom96 | Varriount: You can certainly write a comment saying "This is a duplicate of #bug" |
| 16:31:12 | Varriount | dom96, and for the answered questions? |
| 16:31:34 | dom96 | Varriount: Give a link to where it has been answered. |
| 16:32:51 | EXetoC | how does the loop prevent a crash? |
| 16:33:43 | Varriount | No, I mean, there are tickets, that are questions, that have comments, that answer the questions. |
| 16:34:29 | * | OrionPK quit (Ping timeout: 250 seconds) |
| 16:35:11 | Varriount | dom96, I'd just like to lower the number of open tickets a bit - not only because it kinda reflects badly on nimrod, but also because it makes it harder for those who want to find tickets that they can fix |
| 16:35:36 | dom96 | 161 tickets is hardly a lot |
| 16:37:00 | Varriount | But it's still enough to make it something of a challenge to sift through |
| 16:37:22 | dom96 | Well what do you want me to do? You can ask Araq to give you access to the repo if you want. |
| 16:40:05 | * | DAddYE joined #nimrod |
| 16:40:28 | EXetoC | example? trying to find an issue now where the answer implies that it should be closed |
| 16:40:51 | EXetoC | any relatively new ones? |
| 16:41:48 | EXetoC | dom96: what're you working on these days? |
| 16:42:17 | dom96 | nothing sadly |
| 16:42:48 | EXetoC | ok |
| 16:43:08 | dom96 | Busy with school stuff |
| 16:44:01 | EXetoC | fun |
| 16:44:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 16:46:38 | * | enurlyx joined #nimrod |
| 16:48:47 | EXetoC | Varriount: *highlight* |
| 16:49:43 | * | OrionPK joined #nimrod |
| 16:49:55 | Varriount | ? |
| 16:52:41 | EXetoC | Varriount: highlight as in being notified when your nick is typed. the above was directed towards you in case it was unclear |
| 16:53:32 | Varriount | One moment |
| 16:55:33 | Varriount | EXetoC, -> https://github.com/Araq/Nimrod/issues/658 |
| 16:55:42 | Varriount | :3 |
| 16:58:24 | EXetoC | Varriount: what about it? I thought it'd be a useful shortcut |
| 16:58:52 | EXetoC | and it has been closed so it's not related to what you said before |
| 16:59:08 | Varriount | EXetoC, then why is it still in the open category? |
| 16:59:59 | Varriount | Another example -> https://github.com/Araq/Nimrod/issues/644 |
| 17:00:04 | EXetoC | I don't see it |
| 17:00:17 | freezerburnv | Is there anything in Nimrod similar to Python's "with open(...) as someFile: ..." syntax? |
| 17:00:36 | Varriount | freezerburnv, I think there's a block template.. |
| 17:00:39 | EXetoC | is this when searching for it? if so, then be sure to click on "Open" |
| 17:01:36 | Varriount | EXetoC, Oh, it apears that I needed to refresh my page for your issue to appear in the closed category. |
| 17:01:48 | EXetoC | ok |
| 17:01:57 | Varriount | H/e, that other link *is* in the open cateory. |
| 17:02:01 | Varriount | *category. |
| 17:02:49 | freezerburnv | Varriount: Looking at block in the manual, it looks like the same kind of thing as "{ declare some vars } vars no longer bound" in C/C++. But optionally you can give the block a name and break out of that specific block by name. Rather than in Python where you can do some special things via the __enter__ and __exit__ magic methods in python (or whatever they're called) |
| 17:02:49 | freezerburnv | Varriount: Unless I'm missing something |
| 17:03:00 | EXetoC | yes, but doesn't Araq's comment imply that it might be fixed by a commit later? |
| 17:03:39 | EXetoC | freezerburnv: python does a little more than that though |
| 17:03:39 | Varriount | freezerburnv, I didn't mean the block staement. Look at the section on macros and templates |
| 17:04:09 | Varriount | There's a kind of template (or possible a macro) that allows you to write it as a block |
| 17:04:25 | EXetoC | namely the ability to intercept exceptions, which I think is useful |
| 17:05:06 | webskipper | don't try to use cython + mingw - buggy shit |
| 17:05:29 | Varriount | freezerburnv, see http://nimrod-code.org/manual.html#passing-a-code-block-to-a-template |
| 17:05:32 | freezerburnv | EXetoC: I know :) Just looking for a way to do something simple |
| 17:06:11 | freezerburnv | Varriount: Awesome, thanks! |
| 17:07:27 | Varriount | Actually, if you come up with a with..Open template/macro for nimrod, I wonder if Araq would be willing to add it. |
| 17:08:18 | BitPuffin | dom96: did you see my question about varchar in nimforum? |
| 17:08:36 | EXetoC | Varriount: "You make lots of good points. :-) I will take some deeper look later." so yes, that implies potential future commits |
| 17:09:11 | dom96 | BitPuffin: Yes, can you give me a link to the code you're talking about? |
| 17:09:18 | Varriount | Fine, you win... *goes back into his hole* |
| 17:10:52 | * | gradha joined #nimrod |
| 17:13:02 | EXetoC | more labeling might help, and closing reduces noise slightly, but then you need to be able to find it later somehow |
| 17:18:23 | * | Ricky_Ricardo_ joined #nimrod |
| 17:20:19 | * | Ricky_Ricardo quit (Ping timeout: 260 seconds) |
| 17:20:20 | * | Ricky_Ricardo_ is now known as Ricky_Ricardo |
| 17:25:44 | * | MFlamer quit (Remote host closed the connection) |
| 17:29:42 | gradha | dom96: babel installs packages with version numbers, but is there any mechanism for the local copy to "learn" about new versions? Even babel update won't know, this info is not in the json |
| 17:31:20 | gradha | maybe the packages.json could grow a version number, and after "babel update" it could spit out what installed modules can be updated |
| 17:37:01 | * | enurlyx quit (Ping timeout: 246 seconds) |
| 17:37:33 | BitPuffin | dom96: https://github.com/nimrod-code/nimforum/blob/master/createdb.nim#L58 |
| 17:38:42 | gradha | BitPuffin: a limit sort of prevents spam? |
| 17:40:53 | * | enurlyx joined #nimrod |
| 17:49:30 | * | DAddYE joined #nimrod |
| 18:04:41 | * | brson joined #nimrod |
| 18:07:49 | * | Endy joined #nimrod |
| 18:12:09 | * | ponce is now known as Guest18822 |
| 18:12:10 | * | Guest18822 quit (Killed (cameron.freenode.net (Nickname regained by services))) |
| 18:12:29 | * | p0nce joined #nimrod |
| 18:15:58 | * | [1]Endy joined #nimrod |
| 18:16:18 | Varriount | Araq, in the compiler directory, what do types.skipTypes and types.skipGeneric do, and what are they used for exactly? |
| 18:19:32 | * | Endy quit (Ping timeout: 265 seconds) |
| 18:19:32 | * | [1]Endy is now known as Endy |
| 18:19:58 | webskipper | Have I to give a type in "var q = initQueue(4)" , for example "initQueue[int](4)" ? |
| 18:20:04 | BitPuffin | gradha: but 1000 is kind of short |
| 18:20:08 | webskipper | doc says [T] |
| 18:20:44 | Varriount | Webskipper, try it. |
| 18:22:16 | webskipper | Varriount: it seems so. But on other side add(q, 100) instead of add[int](q, 100) is allowed .... |
| 18:23:37 | Varriount | webskipper, I think it might be because you're giving a literal int. |
| 18:26:02 | webskipper | Varriount: Ok. I guess I have to use add[MyType] than if its not a literal. |
| 18:26:37 | Varriount | Wait, what? |
| 18:27:03 | webskipper | add[MyType](q, varofMyType) ? |
| 18:29:02 | Varriount | Sorry, I think we have a misunderstanding. You have to explicitly say initQueue[int](4), because, in that context, there's no way to infer what data type the initQueue holds |
| 18:29:47 | Varriount | However, once you use the add procedure, the type should be inferred from the kind of queue you are using. |
| 18:30:38 | gradha | BitPuffin: it has served well so far |
| 18:30:39 | EXetoC | BitPuffin: yes. we don't have return type inference a la Rust AFAIK |
| 18:31:30 | webskipper | Varriount: ok, but why is it in doc written as proc add[T] ? |
| 18:31:32 | EXetoC | I think there are future plans regarding overloading of return types, but I wonder what that implies |
| 18:32:01 | Varriount | webskipper, because you can also call add that way - add is a generic procedure |
| 18:32:37 | Varriount | webskipper, in your case, the [T] doesn't need to be added, because it can be inferred. |
| 18:32:49 | EXetoC | the return type can be selected using a generic type, so I really don't know what purpose that would serve |
| 18:32:50 | webskipper | Varriount: is it faster if I give the tyoe ? |
| 18:32:59 | Varriount | webskipper, no |
| 18:33:17 | webskipper | Varriount: than its useless ? Give me an example please :D |
| 18:33:37 | * | CarpNet quit (Quit: Leaving) |
| 18:33:38 | EXetoC | unless for some reason T: int|char is considered worse </speculation> |
| 18:34:29 | EXetoC | BitPuffin: ok wait a minute |
| 18:34:57 | webskipper | var mydirection : TDirection = north |
| 18:34:57 | webskipper | add(q, mydirection) , works ! |
| 18:34:58 | EXetoC | don't you simply mean this: proc f[T](x: T)? :p |
| 18:35:15 | EXetoC | or proc f[T](x: T): T or something like that |
| 18:35:44 | EXetoC | BitPuffin: of course I'm replying to you even though it was webskipper who asked |
| 18:35:45 | webskipper | y |
| 18:36:45 | EXetoC | -.- |
| 18:37:26 | Varriount | webskipper, -> https://gist.github.com/Varriount/7359636 |
| 18:37:53 | * | [1]Endy joined #nimrod |
| 18:38:16 | Varriount | Although, why nimrod can infer types when given t.proc(a) , and not proc(t, a), I don't know. |
| 18:38:28 | * | exhu joined #nimrod |
| 18:38:48 | EXetoC | it can't? hm. will you have to try it |
| 18:39:25 | * | Dispatch joined #nimrod |
| 18:39:57 | webskipper | Varriount: ty |
| 18:40:46 | EXetoC | Varriount: when can't it? add[float](x, 20); add(x, 20); x.add(20); compiles |
| 18:40:48 | exhu | i have so much hobbies and almost no free time to progress in each of them :( want to play guitar, draw, photography and write gui lib for nimrod, but have only time for one of them :( |
| 18:41:15 | gradha | exhu: clearly you are here to learn guitar playing |
| 18:41:37 | * | Endy quit (Read error: Operation timed out) |
| 18:41:38 | * | [1]Endy is now known as Endy |
| 18:41:51 | exhu | gradha, exactly :) |
| 18:42:32 | webskipper | And initQueue needs the T Type because it has to reserve memory with size of T I guess ? |
| 18:42:44 | EXetoC | a high level gui lib? we do have gui libs, but mostly in the form of 1:1 ports |
| 18:42:58 | exhu | gradha, had some progress with gui -- have a top x11 window and a post-thread-message implemented in nimrod |
| 18:43:21 | shevy | bindings for gtk, but also for qt? |
| 18:43:24 | EXetoC | IUP seems like an interesting gui lib, and maybe it wouldn't be too hard to wrap it. I think it also has OpenGL widgets |
| 18:43:45 | shevy | exhu yeah, lack of time is killing me too :( |
| 18:43:56 | exhu | i'm writing a pure cross-platf nimrod lib (using x11 and win32 api) |
| 18:44:06 | dom96 | gradha: Yes, this is currently missing. Updating this information in packages.json would be annoying though. |
| 18:45:08 | EXetoC | EXetoC: does mac OS use X11? |
| 18:45:11 | gradha | dom96: by the time it gets annoying you will write a jester web app for people to submit/update/manage the info |
| 18:45:12 | EXetoC | *exhu |
| 18:45:32 | exhu | EXetoC, you can run x11 apps using XQuartz |
| 18:45:34 | dom96 | gradha: Hopefully :P |
| 18:45:40 | EXetoC | ok |
| 18:46:51 | exhu | EXetoC, it's a so-so solution, but better than nothing. I've not implemented win32 part yet, and will not have time to support three platforms. |
| 18:47:58 | EXetoC | it's obviously less painful to wrap GTK for instance, but whatever floats your boat :-) |
| 18:48:30 | exhu | EXetoC, GTK is a huge and buggy platform both under windows and mac |
| 18:48:51 | exhu | EXetoC, i would say it's linux-only |
| 18:49:03 | EXetoC | :E |
| 18:49:29 | webskipper | use HTML + JS, HAHA :D |
| 18:50:51 | EXetoC | exhu: how is it buggy? I think pidgin is the only GTK app I've run on windows, and I can't recall having any issues with it 6-7 years ago |
| 18:51:30 | EXetoC | just saying. that's obviously not an extensive "test" |
| 18:51:39 | exhu | EXetoC, it's buggy under mac -- both x11 and cocoa versions i tried. Under windows it's just bloated. |
| 18:52:00 | gradha | exhu: please release your incomplete GUI for others to contribute the missing ports you won't have time to implement |
| 18:54:03 | exhu | gradha, my work is already open, i've posted the url on the forum, https://bitbucket.org/exhu/paulina |
| 18:55:53 | * | ics quit (Ping timeout: 272 seconds) |
| 18:58:03 | webskipper | have to ask: why is "proc add[T](q: var TQueue[T]; item: T)" not written as "add[T](q: TQueue[T], item : T) ? Why is var statement used ? Thanks. |
| 18:59:04 | exhu | webskipper, probably the proc modifies the queue |
| 18:59:15 | gradha | exhu: I don't see your design working on macosx, unless you duplicate the menu bar inside the apps window |
| 18:59:49 | exhu | gradha, yes it has to be duplicated. global mac menubar sucks |
| 19:01:24 | exhu | gradha, i've been working on mac for 5 yrs now and i still cannot get used to the top menu bar. |
| 19:01:48 | * | fowl joined #nimrod |
| 19:02:04 | gradha | I don't use any menu bar, could do without them |
| 19:02:11 | dom96 | BitPuffin: Yeah, I think gradha is right. |
| 19:02:16 | dom96 | BitPuffin: (About the varchar) |
| 19:03:49 | gradha | exhu: what's preventing you from implementing this over SDL and have that portable? is that much difference in performance with regards to using raw win32? |
| 19:04:29 | exhu | gradha, well mainly my gui design is like a web app in the browser :) |
| 19:04:37 | exhu | gradha, SDL uses busy waiting. |
| 19:04:57 | EXetoC | webskipper: consider the difference between these: "proc f(x: int) = x = 1", and "proc f(x: var int) = x = 1". x can only be modified in the latter |
| 19:05:18 | exhu | gradha, allegro is too big to write bindings for, i don't feel like doing that. |
| 19:05:18 | gradha | fair enough, busy waiting is so DOS anyway |
| 19:05:24 | dom96 | exhu: How much of Paulina is done? |
| 19:05:38 | exhu | dom96, main loop =) |
| 19:05:48 | gradha | exhu: if you get over the macros you could use c2nim |
| 19:06:29 | EXetoC | not specifying 'var' in a parameter is very similar to declaring a variable with 'let', where "let x = 1; x = 2" won't work, but where "var x = 1; x = 2" will |
| 19:07:41 | * | dyu_ quit (Quit: Leaving) |
| 19:08:02 | gradha | exhu: did you look at a5? presumably it's modular now |
| 19:08:24 | exhu | gradha, i have written bindings for fontconfig which is one header file and it took a lot of hours to make it correct although I used c2nim |
| 19:08:42 | EXetoC | exhu: I guess it's only the rest that remains then :p |
| 19:08:59 | EXetoC | that's always something |
| 19:10:24 | exhu | dom96, the problem with paulina is that each time i begin working on it, i reread the sources and notes and think over what have to be done next and then i have to leave for a sleep or the job. |
| 19:13:25 | exhu | i also don't like the idea to adapt the C libraries to nimrod coding style etc, i.e. cairo bindings are heavily translated so that it makes hard to quickly find the appropriate info the C API reference. |
| 19:14:48 | exhu | Look at the hello world: https://bitbucket.org/exhu/paulina/src/a574f4884f7b4c1330345ad205ce72eb5a87416f/src/tests/test1.nim?at=default |
| 19:14:51 | Varriount | exhu, I agree. It's better to create as direct a wrapper as possible. Then, if need be, create a separate library/framework |
| 19:17:18 | * | enurlyx quit (Ping timeout: 252 seconds) |
| 19:19:58 | dom96 | exhu: Yeah, I know what you mean. It's hard to work on things when you've only got a couple of hours per day to do it in. Most of the work I do happens when I have a couple of days of freedom which is starting to happen less and less. |
| 19:21:57 | * | q66_ joined #nimrod |
| 19:22:21 | * | q66 quit (Disconnected by services) |
| 19:22:23 | * | q66_ is now known as q66 |
| 19:24:14 | * | ics joined #nimrod |
| 19:24:30 | exhu | dom96, it was easier to me during university days (18-22) to sleep 2-3 hours a day, have lectures and practice done from 8 to 17, then homework to prepare for practice and then half night to program as a hobby -) |
| 19:25:01 | reactormonk | exhu, I need 9h otherwise I'm sleepy all day :-/ |
| 19:25:08 | EXetoC | exhu: it'd be more of a wrapper then, but it looks to me like it is a direct binding |
| 19:25:26 | EXetoC | apart from the omission of the "cario_"-prefix, which is redundant |
| 19:26:06 | EXetoC | or is that the actual problem? |
| 19:27:20 | exhu | EXetoC, i don't remember which library functions i could not find in the api docs, but i found them to be named in a non-c way, like without underline chars etc |
| 19:27:36 | * | faassen quit (Quit: Leaving.) |
| 19:28:47 | exhu | EXetoC, aha PSurface in cairo bindings, it would be better to keep it *cairo_surface* |
| 19:30:00 | exhu | EXetoC, or even cairo_surface_t |
| 19:30:13 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 19:32:48 | exhu | Guys, should the gui lib have it's own 2D graphics functions or cairo is ok? |
| 19:32:54 | exhu | *its |
| 19:32:59 | * | MFlamer joined #nimrod |
| 19:33:35 | exhu | i mean an abstract 2d graphics api which maps to cairo or anything else underneath? |
| 19:35:39 | * | ics joined #nimrod |
| 19:36:56 | EXetoC | I think it's fine as long as the interface is binary equivalent. Too bad we can't start polls on the forum |
| 19:37:08 | reactormonk | exhu, for starters, just go for plain cairo. If you want any fancy wrappers, make them optional. |
| 19:37:15 | reactormonk | EXetoC, write some \o/ |
| 19:38:46 | gradha | the other day I overheard how dom96 was willing to accept pull requests for nimforum polls, just nobody was willing to implement them |
| 19:39:16 | dom96 | Where did you overhear that? |
| 19:39:18 | dom96 | :P |
| 19:39:23 | exhu | reactormonk, i mean introduce abstracted api for 2d graphics which is implemented using cairo on linux and directgraphics on windows etc. |
| 19:39:40 | reactormonk | exhu, uh-oh. |
| 19:40:04 | EXetoC | same deal with cairo eh? good on linux, not-so-good on windows? |
| 19:41:08 | EXetoC | I know that there are hardware-accelerated backends, but maybe that's only for linux |
| 19:41:19 | reactormonk | exhu, actually, I would advise against that, as such an abstraction tends to break at some time :-( |
| 19:41:22 | exhu | cairo is just another extra dll to provide with an app -) using native apis on mac/win can reduce dependencies. Anyway i don't feel like writing optimized platform-specific stuff in the nearest future but intent to use cairo everywhere. |
| 19:41:24 | fowl | gradha, go ahead and merge your other PR on nake |
| 19:42:46 | gradha | fowl: have you had time to review them? |
| 19:42:48 | exhu | i just don't want to go the GTK way with dozens of DLLs to distribute with a hello-world app -) |
| 19:43:03 | Varriount | This is probably a stupid question, but in what case would you use *methods* as opposed to *procedures*? |
| 19:43:25 | exhu | Varriount, methods are for dynamic binding |
| 19:43:26 | fowl | gradha, yea, looks good |
| 19:43:35 | fowl | gradha, thanks |
| 19:48:12 | Varriount | exhu, yeah, but what circumstances? Can you give me an example situation? |
| 19:48:52 | exhu | Varriount, OOP: inheritance and polymorphism |
| 19:48:56 | EXetoC | Varriount: think Virtual member functions in C++ |
| 19:49:18 | EXetoC | is the OOP section of the tutorial unclear? |
| 19:49:22 | Varriount | Ah, so when you want to override an already existing procedure, for example? |
| 19:49:50 | Varriount | EXetoC, the tutorial is 4 years old, and though clear, demonstrates only a small part of nimrod. |
| 19:49:53 | fowl | Varriount, http://build.nimrod-code.org/docs/manual.html#multi-methods |
| 19:50:03 | EXetoC | yes |
| 19:51:05 | EXetoC | the static type might be T, but obj.method() might invoke method(U) rather than method(T) if such a method exists |
| 19:52:58 | * | [1]Endy joined #nimrod |
| 19:54:20 | EXetoC | I think that's what you meant |
| 19:55:29 | fowl | that section of the manual should explain everything |
| 19:56:11 | * | Endy quit (Ping timeout: 260 seconds) |
| 19:56:12 | * | [1]Endy is now known as Endy |
| 20:00:57 | * | CarpNet joined #nimrod |
| 20:06:24 | * | freezerburnv quit (Quit: freezerburnv) |
| 20:12:38 | * | Endy quit (Ping timeout: 265 seconds) |
| 20:13:08 | * | MFlamer quit (Remote host closed the connection) |
| 20:19:01 | * | exhu quit (Quit: Ex-Chat) |
| 20:19:57 | * | fredmorcos joined #nimrod |
| 20:24:14 | EXetoC | reactormonk: I might. looking at the code now |
| 20:24:59 | EXetoC | the inject pragma is used a couple of times. that can't be good for readability |
| 20:25:16 | gradha | BitPuffin: can't begin to think when https://github.com/nimrod-code/babel/issues/10 is useful |
| 20:25:39 | gradha | isn't that too jester-server specific? |
| 20:26:02 | Varriount | Ok, I'm trying to solve a recently reported bug, concerning the compiler crashing when ":" is used instead of "=" in a *method* |
| 20:26:39 | EXetoC | dom96: ^ |
| 20:26:40 | Varriount | Does anyone have any pointers? I suspect that it is a problem with the parser, since the same error does not occur with procedures |
| 20:27:09 | EXetoC | what do you think? I only use such templates when I need to invoke it lots of time |
| 20:27:09 | gradha | IIRC that bug is older than me, other than that, no idea |
| 20:27:51 | dom96 | EXetoC: Are you asking me what I think? |
| 20:28:23 | Varriount | Gah, aren't there ny bugs that are A: Within my ability, and B: Within my time, to fix? |
| 20:28:29 | Varriount | *any |
| 20:28:44 | dom96 | Varriount: That does seem like a fairly simple bug to fix. Look at the stack trace. |
| 20:29:12 | Varriount | Dom, the stack trace is an out of bounds error, because the ast is malformed |
| 20:29:49 | Varriount | The compiler *should* be reporting that "method foo(x: int): int :" has invalid syntax |
| 20:29:59 | Varriount | Or has invalid indentation. |
| 20:30:18 | dom96 | But instead it probably generates an incorrect AST |
| 20:31:05 | dom96 | gradha: Perhaps it would be useful for other applications, but it will be a while before I implement that. |
| 20:31:06 | * | Jackneill quit (Remote host closed the connection) |
| 20:32:31 | EXetoC | dom96: yes. I don't know who wrote what pieces though |
| 20:33:05 | dom96 | EXetoC: Are you referring to the same thing gradha is referring to? if not then please elaborate. |
| 20:35:45 | EXetoC | dom96: That was very vague indeed. I'll get back on that a little later |
| 20:41:39 | * | freezerburnv joined #nimrod |
| 20:42:19 | * | filwit joined #nimrod |
| 20:43:49 | * | webskipper quit (Ping timeout: 248 seconds) |
| 20:46:46 | Araq | Varriount: pong |
| 20:50:04 | BitPuffin | gradha: um no it isn't just for server |
| 20:50:13 | BitPuffin | gradha: the server there was just an example |
| 20:51:22 | BitPuffin | gradha: it is useful for when using babel as a build system (and yes nimrod is also its own build system, and babel does and should continue to leverage that) |
| 20:53:44 | * | fredmorcos quit (Quit: Leaving) |
| 20:54:47 | BitPuffin | gradha: but basically it would mean that you wouldn't have to do nimrod c -r -d:release --oneParameter --anotherParameter:3 --passL:"-lfarts" ./path/to/just/one/of/my/executables/in/this/projects/that/I/want/to/have/specific/options/for |
| 20:54:56 | BitPuffin | gradha: so instead you could have a preset |
| 20:55:17 | BitPuffin | babel run thatoneExeWithItsIndividualOptions |
| 20:55:27 | Araq | BitPuffin: you know about project.nimrod.cfg, right? |
| 20:56:03 | BitPuffin | Araq: I know about nimrod.cfg, but I don't know about a way to have multiple options for different targets etc :o |
| 20:56:14 | Araq | @if ? |
| 20:56:24 | BitPuffin | o.O |
| 20:57:50 | * | olahol quit (Ping timeout: 264 seconds) |
| 20:58:05 | * | olahol joined #nimrod |
| 20:58:26 | * | musicalchair quit (Ping timeout: 264 seconds) |
| 20:59:51 | Araq | brb |
| 21:02:49 | gradha | BitPuffin: you should use nake for that, then "nake run" |
| 21:03:19 | BitPuffin | Araq: something that I have noticed when writing code that creates operators is that you often want that operator to work with reversed order of the parameters, for example in the case of scalar*vector you also want vector*scalar, wouldn't it be nice to have a pragma that provides a template that takes the reverse order and rewrites it to the normal way (like I do manually with templates in linagl). Because |
| 21:03:21 | BitPuffin | surely this isn't something that just shows up when making 3d math operators |
| 21:03:35 | BitPuffin | that defines operators* |
| 21:04:13 | BitPuffin | I know I can just use a macro as a pragma for that but it seems like it is something that would be common enough to be good for not just me |
| 21:04:27 | Varriount | BitPuffin, suggest it for the stdlib |
| 21:04:54 | BitPuffin | gradha: hmm, yeah I guess :P |
| 21:05:21 | Araq | BitPuffin: that's just some stdlib macro. we need to find a module name for those perhaps |
| 21:05:45 | BitPuffin | Araq: so it already exists |
| 21:05:46 | BitPuffin | ? |
| 21:05:50 | Araq | I suggest nimrod.fu.std.templategen.macros |
| 21:06:15 | Araq | any other name would not be enterprisey |
| 21:06:23 | BitPuffin | very subtle "fuck you" to the programmer in there :P |
| 21:06:48 | filwit | Araq: you forgot the system. at the beginning |
| 21:07:03 | filwit | BitPuffin: use a template as a macro? |
| 21:07:10 | filwit | BitPuffin: sorry |
| 21:07:17 | gradha | a library path is not enterprisey enough if it doesn't contain oracle in it |
| 21:07:17 | filwit | BitPuffing use a template as a pragma? |
| 21:07:52 | Varriount | How about.. metatools? |
| 21:07:53 | BitPuffin | filwit: http://nimrod-code.org/manual.html#macros-as-pragmas |
| 21:08:37 | BitPuffin | by the way we NEEED an irc bot where we can just go !manual macros as pragmas |
| 21:09:01 | gradha | dom96! manual macros as pragmas |
| 21:09:07 | * | gradha thinks that wasn't hard |
| 21:09:13 | filwit | BitPuffin: ... did not know Nimrod had that ability.. that.. kinda fixes something i was thinking about recently. Awesome, thanks |
| 21:09:36 | * | gradha wonders if the bot learned to high five |
| 21:09:44 | gradha | NimBot: high five! |
| 21:10:02 | filwit | NimBot: kirby rape! |
| 21:10:07 | filwit | damn.. |
| 21:10:15 | dom96 | !kirbyrape |
| 21:10:15 | NimBot | (>^(>O_O)> |
| 21:10:24 | filwit | there it is |
| 21:10:26 | filwit | :) |
| 21:10:35 | Araq | !ping |
| 21:10:35 | NimBot | pong |
| 21:10:36 | BitPuffin | system.enterprise.business.synergy.scrum.macros.bean |
| 21:10:44 | filwit | lol, Araq, nice |
| 21:10:47 | * | Araq only knows "ping |
| 21:11:01 | * | fredmorcos joined #nimrod |
| 21:11:03 | * | Araq !ping |
| 21:11:13 | BitPuffin | !pong |
| 21:11:15 | BitPuffin | :P |
| 21:12:20 | * | fowl quit (Read error: Connection reset by peer) |
| 21:12:26 | * | fowl_ joined #nimrod |
| 21:12:47 | filwit | fowl_: btw, the OpenGL module works fine |
| 21:12:56 | fowl_ | sure why wouldnt it |
| 21:13:03 | Varriount | BitPuffin, I do think metatools would be a good name for a module covering misc. templates and macros |
| 21:13:05 | * | fowl_ is now known as fowl |
| 21:13:08 | * | fowl quit (Changing host) |
| 21:13:08 | * | fowl joined #nimrod |
| 21:13:11 | filwit | fowl_: i just wasn't calling loadExtentions() earlier, so it wasn't linking i think |
| 21:13:22 | BitPuffin | Varriount: tell that to Araq then :D |
| 21:13:41 | Araq | the docs clearly mention it. and yet NOBODY calls loadExtensions |
| 21:13:51 | fowl | filwit, ^ |
| 21:13:59 | gradha | amazing, there's rule34 on kirby |
| 21:14:02 | Araq | but clearly we need MORE documentation that people can ignore |
| 21:14:08 | filwit | Araq: no one reads docs... |
| 21:14:15 | filwit | :P |
| 21:14:19 | Araq | I know |
| 21:14:24 | BitPuffin | filwit: skimming the fm at least once helps with knowing what features nimrod has |
| 21:14:40 | filwit | BitPuffin: fm? |
| 21:14:52 | BitPuffin | filwit: the manual |
| 21:14:56 | filwit | k |
| 21:15:06 | filwit | i've read through the manual a ton |
| 21:15:16 | BitPuffin | oh? |
| 21:15:19 | filwit | but when you're writing code, sometimes you're not in "reading" mode |
| 21:15:22 | BitPuffin | │22:09:08 filwit | BitPuffin: ... did not know Nimrod had that │ |
| 21:15:23 | BitPuffin | │22:09:08 filwit | BitPuffin: ... did not know Nimrod had that │ |
| 21:15:26 | BitPuffin | woa |
| 21:15:30 | BitPuffin | damn that keeps happening |
| 21:15:38 | Varriount | Araq, what are the plans on implicit generic parameters? |
| 21:15:47 | filwit | BitPuffin: what's your point? |
| 21:15:47 | BitPuffin | filwit: no that's true |
| 21:15:52 | Araq | what about them, Varriount ? |
| 21:16:14 | BitPuffin | filwit: Well I thought you didn't know because you hadn't gotten the full overview of what features are available |
| 21:16:48 | Varriount | Araq, well, to be blunt, they're kinda half-baked at the moment, and the only time I see them is when people accidentally use them and trigger errors |
| 21:17:01 | filwit | BitPuffin: well i didn't know about that feature, but to be fair there's a lot involved with Nimrod's macro/templates |
| 21:17:18 | filwit | BitPuffin: and that is only a very small chunk of the docs that talk about it :) |
| 21:17:25 | BitPuffin | filwit: yeah that's very true |
| 21:17:30 | Araq | Varriount: tell that zahary ;-) |
| 21:18:03 | Araq | I'd prefer empty [] for implicit generics and better type inference for proc (a, b) |
| 21:18:08 | BitPuffin | Varriount: I think implicit generics are pretty cool |
| 21:18:18 | Araq | so: |
| 21:18:18 | BitPuffin | just that they are a bit buggy atm |
| 21:18:23 | dom96 | gradha: of course, that is the very definition of rule 34 :P |
| 21:18:26 | Araq | proc (a, b) # type inference |
| 21:18:34 | Araq | proc [](a, b) # generic |
| 21:18:43 | Varriount | BitPuffin, I just wish I knew how to actually fix their bugs |
| 21:18:56 | BitPuffin | Varriount: Well I've been wrestling with one |
| 21:19:00 | BitPuffin | it's kinda hard :( |
| 21:20:21 | dom96 | BitPuffin: The one I reported |
| 21:20:21 | dom96 | ? |
| 21:20:32 | BitPuffin | dom96: which one? |
| 21:21:27 | BitPuffin | dom96: I've been working on fixing this one https://github.com/Araq/Nimrod/issues/618 |
| 21:21:36 | BitPuffin | I'm not far away really but I'm kind of stuck |
| 21:21:46 | dom96 | I see. |
| 21:22:09 | dom96 | I'm talking about: https://github.com/Araq/Nimrod/issues/641 |
| 21:22:30 | Varriount | dom96, also https://github.com/Araq/Nimrod/issues/643 |
| 21:22:54 | dom96 | Varriount: Yeah, nice coincidence that you just referenced my issue from a different issue heh. |
| 21:22:58 | Varriount | 618, 641, and 643 are all related to implicit generics |
| 21:24:21 | Varriount | Oh, and also 599 |
| 21:24:26 | BitPuffin | Varriount: that's a chilly bug you've got there har har har |
| 21:25:16 | BitPuffin | you know |
| 21:25:19 | BitPuffin | because of the ICE |
| 21:25:27 | BitPuffin | murrhurrdurrhurr |
| 21:26:37 | BitPuffin | dom96: we still haven't decided on a project |
| 21:26:46 | BitPuffin | ping EXetoC |
| 21:27:17 | Varriount | BitPuffin, my project is fixing bugs. |
| 21:27:41 | Varriount | Or at least, helping fix them. -_- |
| 21:28:00 | BitPuffin | Varriount: my project is getting helped by Araq to fix the bugs :P |
| 21:30:23 | fowl | implicit generic procs shouldnt be necessary once user defined type classes exist |
| 21:30:41 | BitPuffin | fowl: now why is that |
| 21:30:41 | Varriount | fowl, I thought they already did? |
| 21:30:50 | Araq | fowl: why? please elaborate |
| 21:31:00 | BitPuffin | doesn't make any sense fowl |
| 21:31:09 | fowl | enough with the pings jeez |
| 21:31:26 | BitPuffin | ping fowl |
| 21:31:34 | BitPuffin | sorry :P |
| 21:31:37 | dom96 | BitPuffin: Will we ever agree on anything though, it seems like everyone wants something different. |
| 21:31:49 | fowl | your proc is going to call something like len(arg) or something thats covered by comparable[t] |
| 21:31:57 | BitPuffin | dom96: well maybe |
| 21:32:51 | fowl | how you use the arg is going to (or should be) covered by a typeclass |
| 21:32:51 | BitPuffin | dom96: Well my suggestion is some kind of multiplayer coop survival shooter game thingy |
| 21:33:08 | fowl | BitPuffin, postal 2 with pee only |
| 21:33:10 | fowl | plz |
| 21:33:23 | BitPuffin | fowl: games are bad they make you bad |
| 21:33:26 | fowl | female characters allowed but completely ineffective |
| 21:34:06 | dom96 | Let's just make a sex simulator. |
| 21:34:22 | dom96 | Should become popular :P |
| 21:34:32 | Varriount | Ahem, I thought that user defined type classes already existed? |
| 21:34:36 | BitPuffin | probably not with the right audience though lol |
| 21:35:09 | BitPuffin | dom96: we could have driving in the survival game, didn't you say driving games were cool xD |
| 21:36:39 | fowl | Varriount, guess they do |
| 21:37:11 | dom96 | BitPuffin: Yes! Driving! |
| 21:37:18 | dom96 | With realistic car damage! |
| 21:37:36 | filwit | so much work... |
| 21:37:44 | OrionPK | you guys are insane |
| 21:37:52 | BitPuffin | dom96: driving is possible, realistic car damage not so much :P |
| 21:38:21 | fowl | https://gist.github.com/fowlmouth/62b8fc4ddacad52bf95d |
| 21:38:22 | dom96 | BitPuffin: ok, simple car damage like in GTA Vice City then :P |
| 21:38:31 | OrionPK | you guys shouldn't try to do a story driven game, story = art = artists |
| 21:38:31 | fowl | how you use the generic arg should be covered by a type class ^^ |
| 21:38:38 | BitPuffin | dom96: well there should at least be car damage :P |
| 21:38:41 | filwit | because you guys can't make up your mind on what game to make.. just make them all in one! |
| 21:38:49 | Varriount | Araq, is having to call closure iterators with the same types of arguments they were instanciated with an intended feature? See this -> https://gist.github.com/Varriount/7348835 |
| 21:38:52 | BitPuffin | dom96: so that your car can crash and die, and you get eaten by zambees |
| 21:39:24 | filwit | play space invaders on the window of your car as you race through zombies around tight corners in a tactical COD-style shoot/racer |
| 21:40:00 | dom96 | BitPuffin: hrm, sure. |
| 21:40:13 | dom96 | BitPuffin: But zombies are boring. |
| 21:40:19 | dom96 | We need something more modern. |
| 21:40:37 | dom96 | Alien invasion! |
| 21:40:45 | filwit | from the sea! |
| 21:41:29 | fowl | how about an anti illuminati game |
| 21:41:30 | filwit | Octopoctolypse |
| 21:41:30 | fowl | js |
| 21:41:33 | Araq | Varriount: what does it output? |
| 21:41:44 | BitPuffin | dom96: how about redneck invasion? |
| 21:42:00 | Varriount | "Hello" then "Hello World" then "Hello World!" |
| 21:42:04 | Varriount | Araq, ^ |
| 21:42:05 | * | io2 joined #nimrod |
| 21:42:07 | dom96 | BitPuffin: mehhhh |
| 21:42:12 | fowl | game based on NWA's classic track "fight the power" |
| 21:42:14 | BitPuffin | dom96: what about middleground between zambees and aliens |
| 21:42:36 | BitPuffin | dom96: aliens that take control over humans |
| 21:42:52 | * | freezerburnv quit (Quit: freezerburnv) |
| 21:42:53 | dom96 | Sure, why not. |
| 21:42:54 | fowl | remake of lion king for SNES |
| 21:43:18 | fowl | dom96, lets just finish your gb emulator |
| 21:43:19 | fowl | :p |
| 21:43:28 | BitPuffin | dom96: then we could have both aleans and some kind of infected human who will eventually become alien but is struggling against the control of their body |
| 21:43:31 | BitPuffin | dom96: ala ss2 |
| 21:43:38 | filwit | honestly.. y'all want to make a game to get Nimrod noticed? Make first-person scare game and put it on the Oculus Rift.. then submit it to PudyPie and all other youtube oculus reviewers |
| 21:43:41 | dom96 | fowl: Actually.... good point. |
| 21:43:43 | dom96 | I need to finish that. |
| 21:43:49 | filwit | scare games are easy to make |
| 21:43:58 | dom96 | True. A scare game would be cool. |
| 21:44:01 | filwit | and oculus has a Linus SDK |
| 21:44:01 | dom96 | Something like SCP. |
| 21:44:04 | filwit | linux* |
| 21:44:16 | BitPuffin | meh I will release scare games |
| 21:44:18 | fowl | BitPuffin, you should wrap xscreensaver |
| 21:44:20 | BitPuffin | patience gayz |
| 21:44:22 | Araq | Varriount: yeah that's how it's supposed to work |
| 21:44:30 | BitPuffin | fowl: why? |
| 21:44:38 | fowl | BitPuffin, because screensavers in nimrod |
| 21:44:44 | BitPuffin | fowl: why? |
| 21:44:44 | fowl | neat right |
| 21:44:50 | fowl | because |
| 21:45:04 | BitPuffin | I think an open source game project is more fun if it is a multiplayer game |
| 21:45:11 | BitPuffin | because we can enjoy it together as we're making it |
| 21:45:13 | Varriount | Araq, it just makes things... a bit odd if you're trying to pass iterators around. |
| 21:45:17 | BitPuffin | and it sticks |
| 21:45:38 | BitPuffin | and filwit, pudypaj also makes vids where he plays multiplayer games :P |
| 21:45:44 | Varriount | And can also be quite unexpected. |
| 21:46:33 | EXetoC | BitPuffin: bong |
| 21:46:42 | dom96 | BitPuffin: Co-op horror game? There are not many of those. |
| 21:46:48 | dom96 | Maybe we should do that? |
| 21:46:50 | filwit | BitPuffin: just saying, everyone likes watching people get scared.. so they're really popular right now, and Oculus Rift could be a great movement to ride the coat-tails of (in terms of public awareness) |
| 21:47:32 | filwit | BitPuffin: every time i youtube "oculus rift" it's normally the scare games that people are reviewing |
| 21:47:34 | BitPuffin | dom96: well isn't that kind of the suggestion already with the zambee aleans and the stuff |
| 21:48:00 | OrionPK | who are you going to get to do your meshes/textures/creature design/level editing? |
| 21:48:01 | OrionPK | :P |
| 21:48:07 | BitPuffin | filwit: sure but those videos are for people looking for a quick laugh, not something that they will play and play |
| 21:48:18 | dom96 | BitPuffin: hrm, true. |
| 21:49:07 | filwit | BitPuffin: yes, but if millions of people have seen the game because review X played it.. then you can go on tech forums and be like "yeah.. that was written in Nimrod" |
| 21:49:17 | BitPuffin | multiplayer would also be a nice distribution of skills, dom96 is good at network programming etc, I am a graphics programmer by self education and a 3d artist by education and EXetoC must be good at something :P |
| 21:49:33 | filwit | BitPuffin: and you get more WOW factor because lots of people know the game from the reviews |
| 21:49:48 | OrionPK | bitpuffin set your sights too high, and you're doomed to fail. Make something simple and stylistic (like cell shading) and you wont have to worry about artwork as much |
| 21:50:10 | filwit | BitPuffin: realistically, games are a lot of work.. so your original visions probably wont match the actual product |
| 21:50:30 | filwit | BitPuffin: but scare games can be crappy and still get noticed cause the Oculus Rift is blowing up |
| 21:50:30 | OrionPK | games are a LOT of work, and you need more than just programmers to make a AAA game |
| 21:50:43 | filwit | ^ |
| 21:50:52 | BitPuffin | OrionPK: that's more or less what I had in mind anyway |
| 21:50:55 | gradha | settle for a Z game |
| 21:51:13 | EXetoC | dom96: I was referring to the templates in forum.nim for example that inject symbols, which I think should be restricted to situations where it needs to be repeated at least 10 times or something like that |
| 21:51:20 | filwit | one of the biggest problems with games is they require a TON of artwork.. |
| 21:51:35 | OrionPK | yes, unless they rely on procedural art |
| 21:51:39 | filwit | anyone here (besides me) know how to model, texture, and animate 3D artwork? |
| 21:51:41 | BitPuffin | filwit: well I've already got nimrod horror games in my personal cooker so it's fine |
| 21:51:55 | BitPuffin | OrionPK: well you may have noticed that I said that I am also a 3d artist by education |
| 21:52:02 | BitPuffin | OrionPK: so I'm not just a programmer :P |
| 21:52:05 | filwit | BitPuffin: Awesome! :) |
| 21:52:08 | BitPuffin | plus I'm also interested in the sound stuff |
| 21:52:11 | OrionPK | bitpuffin cool, I didn't know that |
| 21:52:20 | OrionPK | bitpuffin got a link to your work? |
| 21:52:22 | filwit | BitPuffin: you're a 3D artist? that's cool |
| 21:52:43 | filwit | BitPuffin: me too (not by education though) :) |
| 21:52:49 | fowl | BitPuffin, ping |
| 21:52:53 | fowl | BitPuffin, how do you like it |
| 21:52:59 | fowl | BitPuffin, gettin blown up |
| 21:53:14 | BitPuffin | them pingz |
| 21:53:16 | fowl | got notifications? jerk |
| 21:53:22 | EXetoC | lol |
| 21:53:30 | BitPuffin | fowl: nope, no notifications :P |
| 21:53:31 | EXetoC | BitPuffin: nope, not really good at anything |
| 21:53:55 | BitPuffin | OrionPK: sure, I don't have much online but I do have a quick concept up I did a while back for a monster for one of my games |
| 21:54:08 | BitPuffin | EXetoC: yeah you are :D |
| 21:54:10 | OrionPK | cool |
| 21:54:12 | * | Dispatch quit (Quit: Page closed) |
| 21:54:25 | BitPuffin | OrionPK: http://img830.imageshack.us/img830/6575/deserter23romp.jpg |
| 21:54:46 | filwit | BitPuffin: Sculptris, cool :) |
| 21:54:51 | OrionPK | thats fucked up |
| 21:55:07 | EXetoC | da fuk |
| 21:55:14 | filwit | BitPuffin: though Blender's a better Sculpting app these days for dynamic-topology |
| 21:56:24 | OrionPK | bitpuffin how about skeletal animations? |
| 21:56:29 | EXetoC | BitPuffin: no :p |
| 21:56:29 | filwit | BitPuffin: learning curve is much higher, but it has a ton of things that Sculptris doesn't (toggle asym sculpting, boolean ops, zsphere-type base mesh creation, etc..) |
| 21:57:40 | gradha | there you go https://code.google.com/p/graphicsdemoskeleton/ for your game |
| 21:58:11 | BitPuffin | filwit: yep I replaced sculptris with blender as soon as the feature was added |
| 21:58:48 | BitPuffin | OrionPK: what about skeletal animations? |
| 21:59:09 | filwit | gradha: looks like a D3D code-base.. meaning all Matrix/Quaternion math will be row-major and will need converting to OpenGL col-major probably |
| 21:59:10 | OrionPK | have you done them? |
| 21:59:46 | BitPuffin | OrionPK: actually I did test animate that model really quickly but I didn't do it with a clean retopologized mesh (because I didn't know better then) so it turned out to be shit |
| 21:59:56 | BitPuffin | OrionPK: but the result is on the toob |
| 22:01:10 | filwit | Animation is a huge world.. you can just do forward kinematics, to do any walk-cycles or anything you need to know how to create proper IK rigs, etc |
| 22:01:32 | filwit | this is why video games cost millions of dollars today |
| 22:02:07 | filwit | you have a army of artist/coders working on specific things... one guy does texturing, one guy does rigging.. no way to build a decent game without knowledge on all those fronts |
| 22:02:21 | filwit | that's why i said Scare game.. |
| 22:02:42 | filwit | easy cause there doesn't even need to be animations (just look at the Slendy games.. he just glides along) |
| 22:03:00 | gradha | or model kirby |
| 22:03:02 | filwit | so it's just ray-intersection with the world and rendering polygons and you're done |
| 22:03:40 | OrionPK | filwit a lot of work has to go into the ambiance though |
| 22:03:44 | OrionPK | for a horror game |
| 22:03:46 | gradha | it could be a game where the only model is a kirby model |
| 22:03:54 | OrionPK | you need music, good lighting, etc |
| 22:04:04 | gradha | so to differentiate things, you use different kirby colors |
| 22:04:24 | gradha | and if you put three or more kirbies of the same color, they disappear and you score some points |
| 22:04:25 | filwit | true, but that's much easier to do and it's all just creative sound/artwork at that point.. no "we can't do this cause no one knows how to properly UV unwrap models fast enough" |
| 22:04:36 | gradha | you could name it… kirbtris, or kirby crush |
| 22:04:54 | filwit | or.. make a game like a puzzle or tetris game |
| 22:05:01 | filwit | something along those lines |
| 22:05:03 | OrionPK | something arcady would be a lot easier |
| 22:05:23 | OrionPK | and be a good first go on making a game in nimrod |
| 22:05:31 | BitPuffin | anyways I think we could remedy the problem of this kind of project being huge by making it pseudo procedural |
| 22:05:33 | OrionPK | something fun that you can just pick up and play with no story |
| 22:05:43 | BitPuffin | so that assets are already created etc |
| 22:05:56 | BitPuffin | but the world is layed out in a unique way each time |
| 22:06:06 | gradha | I reckon you can create shapes of anything with small enough kirbies, like pixel size small |
| 22:06:15 | filwit | BitPuffin: perfect! just make a Minecraft clone! |
| 22:06:21 | filwit | (jk.. don't actually do that) |
| 22:06:25 | BitPuffin | filwit: no >.< |
| 22:06:31 | filwit | lol |
| 22:06:31 | gradha | kirbycraft |
| 22:06:36 | filwit | ^ lol |
| 22:06:46 | filwit | kirbyrapecraft |
| 22:06:48 | filwit | fixed |
| 22:06:59 | fowl | this convo should go in another room |
| 22:07:06 | fowl | #nimrod-community or something |
| 22:07:45 | filwit | sure fowl. though it's not like there's a ton of people asking Nimrod-related questions atm |
| 22:09:26 | BitPuffin | fowl: exactly, you can just zap to another channel :P |
| 22:09:32 | BitPuffin | no but I dunno |
| 22:09:39 | BitPuffin | maybe #nimrod-game or something |
| 22:09:40 | fowl | if there was it would be washed out |
| 22:11:42 | OrionPK | fowl welcome to IRC |
| 22:12:12 | fowl | thanks, ive been here since i was 11 |
| 22:14:26 | * | filwit discovered IRC only a couple years back |
| 22:14:55 | BitPuffin | dom96: okay so how does this sound: each session starts with the actual invasion + outbreak thing where the players start with nothing to defend themselves with. So you have an intense start each game when you go hunting for weapons, and then from there it's about survival or maybe even defeating the invasion? with random worlds each time? |
| 22:15:10 | BitPuffin | poop and stuff? |
| 22:15:39 | OrionPK | basically killing floor |
| 22:16:04 | filwit | OrionPK, it's all been done before.. the point is to do it with Nimrod i think |
| 22:16:12 | Araq | Varriount: that they keep state is essential for async stuff |
| 22:16:28 | BitPuffin | OrionPK: killing floor isn't random and open |
| 22:16:38 | BitPuffin | OrionPK: it's with pre-built maps and more closed |
| 22:16:59 | EXetoC | should only take a month or two |
| 22:17:01 | EXetoC | cake |
| 22:17:03 | BitPuffin | EXetoC: :P |
| 22:17:10 | BitPuffin | EXetoC: don't you mean a weekend? |
| 22:18:04 | BitPuffin | no but if you keep things simple from there (simple art style etc) it isn't a huge mega project |
| 22:19:16 | * | musicalchair joined #nimrod |
| 22:19:24 | BitPuffin | hello musicalchair |
| 22:19:43 | musicalchair | hello BitPuffin! |
| 22:20:07 | BitPuffin | musicalchair: are you new? |
| 22:21:37 | musicalchair | BitPuffin: I've been hanging out in this channel here and there. I've *barely* played around with nimrod. I recently picked up D and have been doing my best to focus on that for at least a month =P |
| 22:22:14 | dom96 | BitPuffin: to be honest I doubt I will have enough time to work on it :( |
| 22:22:39 | BitPuffin | musicalchair: ah okay! Yeah I've been a D user too. Let us know if you need any help if you decide to stick with nimrod for a while! |
| 22:23:30 | BitPuffin | dom96: perhaps :/ |
| 22:24:43 | musicalchair | BitPuffin: after using D for a little, the effects system nimrod has seems pretty nice. What's your biggest nimrod > D feature? |
| 22:24:45 | * | fredmorcos quit (Quit: Leaving) |
| 22:25:11 | BitPuffin | musicalchair: well one thing about D that breaks the deal a bit is the stop the world GC |
| 22:25:56 | BitPuffin | musicalchair: nimrod also has much nicer metaprogramming abilities (macros etc) and a pretty syntax |
| 22:26:36 | musicalchair | BitPuffin: yes, I'm eager to play around with nimrod's metaprogramming (and hopefully not fall down a rabbit hole) |
| 22:27:43 | BitPuffin | dom96: well at least it's what i could come up with that was 3d and multiplayer that wasn't yet another warsow/xonotic |
| 22:28:38 | filwit | musicalChair: I think the "biggest" Nimrod > D feature is specific to your goals. I came from D as well, and for me it's the GC and performance of Nimrod over D (and that it compile to C, which is nice for ARM, etc, which D doesn't support well) |
| 22:29:31 | BitPuffin | yeah compile to C definitely brings it to all possible kinds of platforms |
| 22:29:34 | musicalchair | BitPuffin: I'm no GC expert. From http://nimrod-code.org/gc.html I gather that the nimrod GC only runs on memory alloc. At which point a partial GC can occur, stopping the world (for that thread). I guess, from my uninformed perspective, it seems like nimrod also stops the world, but more deterministically |
| 22:29:38 | BitPuffin | like you could run nimrod on a console for example |
| 22:29:47 | musicalchair | filwit: portability is definitely on my mind =) |
| 22:30:02 | BitPuffin | game console that is |
| 22:30:35 | musicalchair | I also want to learn about compilers so it seems like a young language like nimrod might have more opportunities for me to learn |
| 22:30:43 | Araq | musicalchair: since it's thread local it doesn't stop "the world" (which would be "stop every thread") |
| 22:30:51 | BitPuffin | musicalchair: well yeah the GC doesn't stop the entire program and it dosn't stop for a noticable time |
| 22:31:11 | musicalchair | ok, makes sense |
| 22:31:21 | Araq | also it doesn't "stop" it takes up the time slice you give to it |
| 22:31:45 | Araq | and is able to collect a little, in other words does useful work and returns |
| 22:31:54 | filwit | musicalchair: all GC's technically "stop the world" (i think), some just don't need to collect everything all at once (like Nimrod's GC) |
| 22:32:09 | Araq | as opposed to merely doing nothing useful for the time you give to it |
| 22:32:42 | BitPuffin | yeah that's a much better explanation |
| 22:32:55 | BitPuffin | Araq is really the guy to talk to about this |
| 22:33:09 | filwit | musicalchair: that's what an "incremental" GC is. In my experience, Nimrod's GC is simply the best around (in terms of performance, control, and multi-threading). |
| 22:33:38 | filwit | filwit: granted, i've never tested Java's GC much, and I'd imagine it'd give Nimrod's a run for it's money |
| 22:34:40 | Araq | the GC's throughput is not nearly as good, but we'll get there |
| 22:34:40 | BitPuffin | filwit: I'm not sure it would be all that much better |
| 22:34:55 | BitPuffin | maybe better but not run for its money better |
| 22:35:29 | * | MFlamer joined #nimrod |
| 22:35:32 | Araq | also one more thing: a good GC is barely an implementation detail |
| 22:35:37 | filwit | well i've just heard that Java's GC is "the best", but don't actually have (much of) any experience with it |
| 22:36:25 | BitPuffin | well java also loses some performance because its not native cewd |
| 22:36:28 | Araq | the language semantics need to be adapted for efficient GCs |
| 22:37:03 | Araq | and both D and Golang get that horribly wrong :P |
| 22:38:20 | BitPuffin | Araq: nimrod got it right. It's got the acyclic pragma |
| 22:39:25 | filwit | musicalchair: on top of what Araq just said, Nimrod also has a ton of control of it's GC, and (if memory serves), it's standard lib works well without the GC, so turning it off in areas is actually doable (compared to D) |
| 22:39:36 | filwit | (Araq: correct me if i'm wrong on that) |
| 22:40:53 | Araq | actually since the GC works rather well the stdlib does allocate without caring too much |
| 22:41:13 | Araq | allocations are only avoided for performance reasons but it does allocate |
| 22:41:29 | Araq | D's stdlib is getting crazy about avoiding GC |
| 22:41:42 | Araq | since they can't make the GC fast :P |
| 22:41:46 | filwit | i see, okay well nevermind then |
| 22:42:26 | filwit | I think some big AAA game company just revealed they're using some C++ GC on all their code anyways.. |
| 22:42:28 | musicalchair | interesting points! Being able to control the GC time slices seems awesome |
| 22:43:02 | musicalchair | Araq: I'd be interested in hearing about your thoughts on coupling language semantics to the GC sometime |
| 22:43:31 | Araq | sure it would make a great blog post I guess |
| 22:43:58 | Araq | but then it took years of pain to gain all that knowledge, so I'd rather write a book about it :P |
| 22:44:00 | BitPuffin | for sure |
| 22:44:16 | musicalchair | I think so =) |
| 22:44:40 | MFlamer | BitPuffin: how did that bug fix turn out? |
| 22:45:01 | filwit | Araq: that's not a bad idea actually. You could sell it.. i found D randomly, but I learned it by buying Andreas "The D Programming Language" book |
| 22:45:24 | Araq | his name is alexandrescu |
| 22:45:47 | filwit | yeah |
| 22:45:53 | Araq | *Andrei |
| 22:46:06 | filwit | i always for his name cause i'm American |
| 22:46:16 | filwit | and i use that as an excuse not to remember things like that |
| 22:46:34 | BitPuffin | Araq: wait your name is not Andrei Alexandrescu? |
| 22:46:36 | BitPuffin | :P |
| 22:46:37 | filwit | forget** |
| 22:46:48 | Araq | BitPuffin: no, I'm not famous |
| 22:46:56 | filwit | not yet |
| 22:47:12 | filwit | goal is to put Araq's picture on all the code blogs |
| 22:47:15 | BitPuffin | MFlamer: didn't work on it today, got stuck yesterday, but it's near completion I think :P |
| 22:47:23 | BitPuffin | Araq: it was a joke |
| 22:47:29 | BitPuffin | actually I also own that book |
| 22:47:39 | filwit | Araq, i'm going to make one of those "Hope" obama images with your face on it |
| 22:47:47 | filwit | Araq: hahaha |
| 22:47:53 | Araq | filwit: gah |
| 22:48:01 | * | OrionPK quit (Ping timeout: 250 seconds) |
| 22:49:22 | filwit | Araq: a bit more serious though, any word on your talk yet? |
| 22:50:04 | filwit | Araq: i forget when dom96 said that would be available. was it Nov, Dec, or Jan ? |
| 22:50:27 | Araq | no idea, nobody asked for my permission and I'm too busy to ask them |
| 22:50:44 | BitPuffin | Araq: what are your thoughts on Andrei? |
| 22:51:14 | Araq | he's brilliant but underestimates the cost of parametrization |
| 22:51:17 | filwit | Araq: also, what's your thoughts on the Pope, Ghandi, and Princess Diana? |
| 22:51:33 | Araq | the new Pope is creepy |
| 22:51:44 | BitPuffin | he does look like a sith lord |
| 22:51:57 | EXetoC | " |
| 22:52:43 | filwit | idk, i haven't really been keeping up with the Catholics. The old guy looked creepy, so if the new guys looks worse... |
| 22:53:06 | fowl | the last one looked liek palpatine |
| 22:53:19 | EXetoC | in the meantime, check out other presentations, such as "Taking PHP Seriously" for example |
| 22:54:45 | BitPuffin | Araq: doesn't nimrod also have a lot of parameterization? or are you referring to D's stdlib? |
| 22:55:02 | BitPuffin | Araq: also isn't walter kind of an optimization guy who should raise a red flag if it costs too much :P |
| 22:56:50 | Araq | BitPuffin: well tbh in the long run I expect somebody figures nimrod can easily do D-styled ranges and uses them everywhere |
| 22:57:14 | BitPuffin | Araq: how can one do that btw? |
| 22:58:39 | filwit | BitPuffin: to long to explain in IRC |
| 22:58:42 | Araq | hu? how is that in any way hard to do? |
| 22:59:28 | BitPuffin | Araq: well not sure, I didn't really ever use them |
| 22:59:49 | filwit | BitPuffin: a "range" in D is just a generic pointer + length type (used in all their stdlibs instead of iterators) |
| 23:00:25 | * | Amrykid quit (Excess Flood) |
| 23:00:40 | EXetoC | it can be anything that implements its interface |
| 23:00:49 | * | Amrykid joined #nimrod |
| 23:01:12 | EXetoC | popFront and all that |
| 23:01:14 | filwit | BitPuffin: yeah, what EXetoC said.. it's just an duck-typed interface |
| 23:02:23 | * | Amrykid quit (Changing host) |
| 23:02:23 | * | Amrykid joined #nimrod |
| 23:02:59 | BitPuffin | sounds goofy |
| 23:03:27 | EXetoC | I shouldn't say interface though |
| 23:03:54 | filwit | "prototype" ? |
| 23:04:24 | Araq | afaict D makes the mistake to use ranges for everything including streams |
| 23:04:25 | filwit | btw, Araq: does Nimrod have any {.noInstanceOfThisType.} pragma? |
| 23:04:45 | Araq | but for streams you should use dynamic binding to avoid code bloat |
| 23:05:11 | musicalchair | BitPuffin: I seem to remember you wanted to write a wayland shell in nimrod. How's that going? Do you have any goals? I'm toying with the idea of a WM that reveals communication links between processes and allows manipulating, inspecting them |
| 23:05:35 | filwit | musicalchair: just port Weston to Nimrod :D |
| 23:05:47 | Araq | so ... the design doesn't really work, though maybe they have workarounds in place for that |
| 23:06:12 | musicalchair | filwit: that could be a nice exercise. hmm |
| 23:06:42 | Araq | filwit: no but you might be able to fake it with a TR macro |
| 23:06:45 | filwit | Araq: to be fair, ranges work quite well for some things.. and the Steams example is more like a bad use of ranges rather than ranges themselves being "bad" |
| 23:07:01 | filwit | Araq: okay, just wanted to know. |
| 23:07:12 | Araq | ranges are hard to write, nimrod's iterators are much easier to write |
| 23:07:25 | Araq | range work well when you use them though |
| 23:08:01 | Araq | but then C#'s IEnumerable is comparable and C# has yield ... |
| 23:08:18 | filwit | not inlineable though! |
| 23:08:22 | filwit | (i think?) |
| 23:08:24 | EXetoC | except when you're trying to be const-correct |
| 23:09:17 | Araq | filwit: I think it's inlinable with a bit of effort |
| 23:09:30 | BitPuffin | musicalchair: well it's on ice until an issue with the wlglamor driver is fixed |
| 23:09:50 | filwit | Araq: C#'s? Even if it is, i highly doubt they do it. |
| 23:10:20 | * | CarpNet quit (Quit: Leaving) |
| 23:10:39 | Araq | filwit: I guess they don't but you'd be surprised what a typical JIT for JS does with these things |
| 23:12:06 | musicalchair | BitPuffin: I see |
| 23:12:16 | filwit | Araq: I've looked at V8 a bit, i understand a JIT can do a lot of fancy things. |
| 23:14:54 | * | fredmorcos joined #nimrod |
| 23:15:15 | * | vidot_j joined #nimrod |
| 23:22:17 | * | OrionPK joined #nimrod |
| 23:24:00 | * | io2 quit () |
| 23:29:46 | * | MFlamer quit (Ping timeout: 244 seconds) |
| 23:29:57 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:30:18 | * | ics joined #nimrod |
| 23:35:36 | EXetoC | ª |
| 23:36:15 | BitPuffin | dom96: non mod prop hunt? :P |
| 23:37:21 | * | fredmorcos quit (Quit: Leaving) |
| 23:44:45 | gradha | good night |
| 23:44:55 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=n7pXRdkdJxI again) |
| 23:45:04 | dom96 | BitPuffin: huh? |
| 23:46:40 | BitPuffin | dom96: game |
| 23:47:03 | dom96 | I know, but I'm not sure what you mean by what you said. |
| 23:47:49 | BitPuffin | dom96: well standalone open source version of prop hunt |
| 23:48:00 | dom96 | no idea what prop hunt is :P |
| 23:48:09 | fowl | like duck hunt |
| 23:48:12 | fowl | cept you hunt props |
| 23:50:27 | BitPuffin | dom96: https://www.youtube.com/results?search_query=prop+hunt |
| 23:52:13 | dom96 | hah, that's brilliant. |
| 23:52:20 | dom96 | Never heard of this. |
| 23:52:30 | BitPuffin | it's hilarious |
| 23:52:32 | dom96 | Looks like I need to spend more time on youtube |
| 23:52:52 | fowl | first time i've heard someone say that ^ |
| 23:53:13 | BitPuffin | lol! |
| 23:53:25 | dom96 | :P |
| 23:54:13 | BitPuffin | dom96: would be cool to have that except with random placement of props, because after a while you learn how a level should look and it becomes obvious what's the props |
| 23:54:46 | * | MFlamer joined #nimrod |
| 23:57:42 | dom96 | Going to need lots of models for props though I think |
| 23:59:15 | dom96 | BitPuffin: EXetoC: We should play some gmod :P |
| 23:59:36 | BitPuffin | dom96: props are easy |
