| 00:01:04 | EXetoC | I'm referring to when you responded to my PR saying that I should instead create a package for mongo and then follow up with a PR that removes it from the stdlib |
| 00:03:22 | fowl | EXetoC, ill make the repos for you |
| 00:03:28 | fowl | whats your github name |
| 00:03:44 | EXetoC | EXetoC |
| 00:03:54 | Araq | Araq |
| 00:05:49 | fowl | EXetoC, https://github.com/nimrod-code/mongo |
| 00:06:47 | EXetoC | thanks |
| 00:08:00 | Varriount | Araq: should I use UPX on the binaries being placed in the installer? |
| 00:08:30 | Varriount | I'd only do it for 32 bit, because UPX support for 64 bit is experimental. |
| 00:08:35 | Araq | no, you should never use upx |
| 00:09:05 | Varriount | Araq: Ok. Any particular reason why I should never use it? |
| 00:11:26 | Araq | Varriount: http://wiki.freepascal.org/Size_Matters#UPX |
| 00:11:27 | EXetoC | done. I haven't added much, but I should release early so that people can tell me if it sucks |
| 00:15:40 | Varriount | Araq: Huh, interesting. |
| 00:16:27 | Varriount | At least for me, the only strong point in that argument is the whole memory-mapping drawback, but that's good enough for me. |
| 00:17:19 | Demos | imo binary sizes are not much of a problem unless they get into the 100M+ range.... or if you have link time problems |
| 00:17:44 | Varriount | Demos: *cough*visual studio 5 gb*cough* |
| 00:18:07 | Demos | that is the total size of the product, there is more than just the binary. But yes that is large |
| 00:18:16 | Demos | or RAGE which clocks in at 30GB for everything |
| 00:18:22 | Varriount | RAGE? |
| 00:18:25 | Demos | a game |
| 00:18:38 | Varriount | Ph, well, a game I can understand. |
| 00:18:45 | Demos | a very good one if you get the chance, it does some nifty stuff |
| 00:19:03 | Varriount | Though, 30 gb seems a bit excessive, unless some very fancy graphic techniques are being used. |
| 00:20:29 | Varriount | Araq: How soon does the installer need to be completed? As soon as possible? |
| 00:21:17 | Demos | it does virtual texturing, so there is essentially one "motherfucking huge" compressed texture that can be progressively decompressed as the data gets to the GPU, at least this is how I understand it. This means that they do not need to tile their landscape textures and they can have the game run at 60fps on anything. |
| 00:22:40 | * | BitPuffin joined #nimrod |
| 00:23:27 | Varriount | Anyone here have a blank 64 bit windows vm free? |
| 00:23:45 | Varriount | The 64 bit nimrod installer needs testing |
| 00:27:39 | OrionPK | you might be able to get one from Microsoft |
| 00:27:48 | Varriount | Oh? |
| 00:28:01 | OrionPK | they have images for testing IE |
| 00:28:24 | dom96 | https://github.com/Araq/Nimrod/wiki/GSoC-2014-Ideas |
| 00:28:31 | dom96 | Thoughts? |
| 00:28:59 | Araq | Varriount: as soon as possible is good enough |
| 00:29:22 | Araq | will be at least 1 week until we're ready for a release |
| 00:29:33 | Varriount | Araq: Well, the 64 and 32 bit installers are currently being generated, however they need testing. |
| 00:30:05 | Araq | I can test the 32 bit build on my XP VM |
| 00:30:30 | Varriount | On a side note, I was wondering if using nimrod executables in place of the build shell scripts would be a good idea. |
| 00:31:28 | Araq | nah, .bat files are cool |
| 00:31:44 | Araq | don't change what works |
| 00:32:18 | Varriount | Araq: Adding mingw and msys is going to increase the size quite a bit, and I don't know what's safe to remove. |
| 00:32:34 | Araq | msys is not necessary |
| 00:33:00 | Araq | also we have the Gamera edition with a minimal GCC package |
| 00:33:48 | * | carum joined #nimrod |
| 00:33:58 | Araq | tools\trimcc.nim is a program that trims the GCC installation to a bare minimum |
| 00:34:06 | Araq | I used that to build Gamera |
| 00:34:14 | Varriount | Gamera? |
| 00:35:42 | Araq | Varriount: we got the name from http://www.youtube.com/watch?v=Gqejmh-nJFo |
| 00:35:45 | vbtt | dom96, Araq: knowledge of C could be added to the desirable skills under coroutines. |
| 00:36:05 | dom96 | hrm, and asm too I guess |
| 00:36:15 | Araq | vbtt: meh, I prefer knowledge of assembler |
| 00:36:29 | dom96 | I added both. |
| 00:36:35 | Araq | k |
| 00:36:37 | vbtt | either is fine i guess - just knowledge of machine architecture is what i'm getting at. |
| 00:36:51 | dom96 | Knowledge of C is true for many things since Nimrod compiles to C anyway. |
| 00:37:56 | vbtt | probably rephrase 'assembler' to 'assembly language' |
| 00:37:57 | OrionPK | http://www.modern.ie/en-us/virtualization-tools |
| 00:39:07 | vbtt | not sure why Lua is highlighted. I can think of Lua, Erlang, Python (using greenlets), Go |
| 00:39:49 | Araq | Go has no coroutines |
| 00:39:56 | Araq | neither does Erlang |
| 00:39:59 | Araq | neither does Python |
| 00:40:27 | vbtt | what are goroutines then? or erlang processes? |
| 00:40:38 | Araq | not in the "collaborative" multi tasking sense |
| 00:41:05 | Araq | goroutines are light-weight processes |
| 00:42:01 | vbtt | do you mean the difference is preemptive vs cooperative scheduling? |
| 00:43:45 | Araq | yes |
| 00:43:49 | vbtt | what else will you use erlang processes or goroutines for, if not collaborative multi tasking? |
| 00:44:02 | vbtt | go is not preemptive, btw. erlang is. python greenlets are not preemptive either. |
| 00:44:42 | vbtt | it's just that they are also well integrated with the io operations (i.e. io ops automatically do async system calls and automatically call 'yield') |
| 00:45:12 | Araq | go is preemptive, otherwise it couldn't run on multiple cores |
| 00:45:55 | Discoloda | fun fact, Wings3D (easy to use 3d modeler written in Erlang) doesnt use processes (or it didnt years ago) |
| 00:46:45 | vbtt | by preemptive i mean, go runtime will not suspend any running go routine doing pure cpu work. |
| 00:46:53 | vbtt | it only suspends them when they do io. |
| 00:47:00 | * | noam_ is now known as noam |
| 00:47:08 | Araq | I know but that's not enough to prevent races |
| 00:47:10 | dom96 | gah, the competition is tough. |
| 00:47:10 | * | xenagi joined #nimrod |
| 00:47:16 | vbtt | right, fair point. |
| 00:47:22 | dom96 | Other idea pages are much more thorough than ours :\ |
| 00:48:03 | vbtt | ok, so perhaps mentioning go and erlang is not a good idea. |
| 00:49:06 | Araq | dom96: I really need to sleep now, others need to expand this stuff |
| 00:49:07 | vbtt | i see what you're saying. perhaps mentioning that the coroutines we want are bound to a single threaded, non moving (not best choice of words) |
| 00:49:30 | vbtt | good night Araq. I'll try to come up with some expansions you can review tomorrow. |
| 00:49:42 | dom96 | vbtt: Thanks :) |
| 00:49:55 | dom96 | zahary_: Varriount: Could you guys try to help out too if at all possible? |
| 00:50:31 | dom96 | I need to sleep now too. |
| 00:53:05 | vbtt | dom96:good night. |
| 00:55:11 | * | Icefoz_ quit (Ping timeout: 245 seconds) |
| 00:56:20 | Varriount | dom96: Help out how? |
| 00:58:03 | Demos | I added some stuff to the CAAS section. Do we want to mention adding some kind of debugging support or is that not really part of CAAS? |
| 01:01:07 | dom96 | Varriount: Expand the descriptions. Add more detail. Provide links to helpful sites. |
| 01:01:30 | dom96 | I asked for a review in #gsoc and the guy said we need to be more thorough. |
| 01:01:50 | Varriount | Eeep |
| 01:02:03 | dom96 | and that we need to write what the intended outcome is. |
| 01:02:29 | dom96 | Last year 42% of the orgs got accepted. |
| 01:02:38 | dom96 | But I will not give up now :P |
| 01:02:54 | dom96 | oh, and write a paragraph about what Nimrod is if you can please. |
| 01:03:13 | dom96 | Good night. |
| 01:03:21 | Varriount | dom96: What, the information on the website isn't enough? Goodnight |
| 01:03:37 | dom96 | "<carols> dom96: you'll probably also want some info on your org itself on that page since that may be the first thing students see about you before anything else" |
| 01:05:50 | Varriount | Araq: ping |
| 01:17:23 | * | Demos quit (Quit: Textual IRC Client: www.textualapp.com) |
| 01:21:10 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 01:31:54 | * | Icefoz joined #nimrod |
| 01:38:07 | * | Demos joined #nimrod |
| 01:43:40 | Varriount | Hi icefoz |
| 01:54:01 | * | carum quit (Remote host closed the connection) |
| 02:08:19 | * | DAddYE_ joined #nimrod |
| 02:13:50 | * | evil_CarpNet joined #nimrod |
| 02:14:30 | * | brson quit (Quit: leaving) |
| 02:15:21 | * | athaudia1 joined #nimrod |
| 02:15:28 | * | DAddYE quit (Read error: Connection reset by peer) |
| 02:15:37 | * | XAMPP_ quit (Ping timeout: 260 seconds) |
| 02:15:37 | * | CarpNet quit (Ping timeout: 260 seconds) |
| 02:15:38 | * | JStoker quit (Ping timeout: 260 seconds) |
| 02:15:49 | * | zahary___ joined #nimrod |
| 02:15:54 | * | xtagon_ joined #nimrod |
| 02:16:10 | * | JStoker joined #nimrod |
| 02:16:25 | * | BitPuffi1 joined #nimrod |
| 02:18:28 | * | icebattl1 joined #nimrod |
| 02:18:31 | * | epsylon joined #nimrod |
| 02:18:40 | * | DAddYE joined #nimrod |
| 02:18:47 | * | epsylon` quit (Ping timeout: 260 seconds) |
| 02:18:52 | * | xtagon quit (*.net *.split) |
| 02:18:53 | * | icebattle quit (*.net *.split) |
| 02:18:53 | * | ics quit (*.net *.split) |
| 02:18:54 | * | Zuchto quit (*.net *.split) |
| 02:18:55 | * | athaudia quit (*.net *.split) |
| 02:18:56 | * | mietek quit (*.net *.split) |
| 02:19:10 | * | DAddYE quit (Remote host closed the connection) |
| 02:19:32 | * | [Pete_27] quit (Ping timeout: 260 seconds) |
| 02:20:05 | * | ics joined #nimrod |
| 02:20:07 | * | [Pete_27] joined #nimrod |
| 02:20:17 | * | Zuchto_ joined #nimrod |
| 02:22:29 | * | DAddYE_ quit (*.net *.split) |
| 02:22:30 | * | Demos quit (*.net *.split) |
| 02:22:30 | * | BitPuffin quit (*.net *.split) |
| 02:22:31 | * | renesac quit (*.net *.split) |
| 02:22:32 | * | zahary_ quit (*.net *.split) |
| 02:22:32 | * | EXetoC quit (*.net *.split) |
| 02:22:32 | * | OrionPK quit (*.net *.split) |
| 02:30:34 | * | icebattle joined #nimrod |
| 02:31:24 | * | Varriount quit (Ping timeout: 265 seconds) |
| 02:33:36 | * | [Pete_27] quit (*.net *.split) |
| 02:33:36 | * | icebattl1 quit (*.net *.split) |
| 02:33:37 | * | zahary___ quit (*.net *.split) |
| 02:36:03 | * | ttt joined #nimrod |
| 02:36:07 | * | Varriount joined #nimrod |
| 02:37:34 | * | zahary___ joined #nimrod |
| 02:38:50 | * | [Pete_27] joined #nimrod |
| 02:38:58 | * | EXetoC joined #nimrod |
| 02:39:01 | * | wa_ joined #nimrod |
| 02:41:14 | * | mietek joined #nimrod |
| 02:43:15 | * | fowl quit (Ping timeout: 260 seconds) |
| 02:43:35 | * | fowl joined #nimrod |
| 02:44:30 | ttt | does the current compiler support nested types such as TTable[foo[T], TQueue[foo[T]]]. If so, I may just be having trouble inserting into the table |
| 02:46:26 | * | xenagi quit (Ping timeout: 260 seconds) |
| 02:46:39 | * | xtagon joined #nimrod |
| 02:47:55 | * | xenagi joined #nimrod |
| 02:48:24 | * | carum joined #nimrod |
| 02:48:48 | * | carum quit (Remote host closed the connection) |
| 02:50:00 | * | xtagon_ quit (*.net *.split) |
| 02:50:00 | * | athaudia1 quit (*.net *.split) |
| 02:50:03 | * | brihat quit (*.net *.split) |
| 02:50:03 | * | skrylar_ quit (*.net *.split) |
| 02:50:03 | * | askatasuna quit (*.net *.split) |
| 02:50:05 | * | musicalchair quit (*.net *.split) |
| 02:50:05 | * | krusipo quit (*.net *.split) |
| 02:50:16 | EXetoC | ttt: yes it does |
| 02:50:24 | EXetoC | either there's a type mismatch, or the table is constant |
| 02:51:03 | ttt | if a function is creating and returning the table, the new(result) section will create a non-const table? |
| 02:51:04 | * | krusipo joined #nimrod |
| 02:51:41 | * | musicalchair joined #nimrod |
| 02:52:02 | * | skrylar joined #nimrod |
| 02:53:55 | EXetoC | ttt: it should depend on whether or not the caller uses 'let' or 'var' |
| 02:55:37 | EXetoC | but you cannot pass result to a 'var' argument, so you might need a temporary in that case |
| 02:56:47 | EXetoC | nevermind that last statement |
| 02:57:08 | EXetoC | I think I was thinking of closures |
| 02:58:09 | * | ddl_smurf_ joined #nimrod |
| 02:58:21 | * | Zuchto joined #nimrod |
| 03:01:02 | * | carum joined #nimrod |
| 03:04:06 | * | ddl_smurf quit (Read error: Connection reset by peer) |
| 03:04:06 | * | ddl_smurf_ is now known as ddl_smurf |
| 03:04:08 | * | Zuchto_ quit (Ping timeout: 260 seconds) |
| 03:04:14 | * | musicalchair quit (Ping timeout: 260 seconds) |
| 03:04:15 | * | athaudia1 joined #nimrod |
| 03:05:16 | * | musicalchair joined #nimrod |
| 03:07:09 | * | renesac joined #nimrod |
| 03:08:59 | * | brihat joined #nimrod |
| 03:14:23 | * | ttt quit (Ping timeout: 245 seconds) |
| 03:30:10 | * | wa_ quit (Changing host) |
| 03:30:10 | * | wa_ joined #nimrod |
| 03:34:29 | * | xtagon quit (Ping timeout: 248 seconds) |
| 03:35:18 | * | xtagon joined #nimrod |
| 03:37:17 | * | DAddYE joined #nimrod |
| 03:46:45 | * | DAddYE quit (Remote host closed the connection) |
| 03:47:12 | * | DAddYE joined #nimrod |
| 03:47:32 | * | carum quit (Remote host closed the connection) |
| 03:47:52 | * | carum joined #nimrod |
| 03:51:24 | * | carum quit (Remote host closed the connection) |
| 03:51:26 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 03:52:16 | * | carum joined #nimrod |
| 03:56:43 | * | carum quit (Ping timeout: 260 seconds) |
| 04:13:19 | renesac | nimrod has map() but not reduce()? |
| 04:13:49 | * | reactormonk joined #nimrod |
| 04:36:44 | * | Icefoz quit (Ping timeout: 245 seconds) |
| 04:37:18 | * | Icefoz joined #nimrod |
| 04:38:09 | Varriount | renesac: foldl and foldr |
| 04:40:07 | renesac | oh, in sequtils |
| 04:40:19 | renesac | and I was used to "reduce" as the name |
| 04:40:20 | renesac | thanks |
| 04:42:04 | reactormonk | I think we need search aliases ^^ |
| 04:43:05 | * | carum joined #nimrod |
| 04:54:56 | * | askatasuna joined #nimrod |
| 05:00:35 | * | reactormonk quit (Quit: WeeChat 0.4.1) |
| 05:05:54 | * | askatasuna quit (Ping timeout: 245 seconds) |
| 05:09:43 | * | brihat quit (Ping timeout: 272 seconds) |
| 05:15:45 | renesac | https://gist.github.com/ReneSac/56fa1fa99d1551d3ca96 <-- converters are supposed to fail that way? |
| 05:23:30 | * | dmac joined #nimrod |
| 05:30:10 | renesac | well, I submitted a issue |
| 05:41:05 | * | xenagi quit (Quit: Leaving) |
| 05:48:30 | * | xtagon quit (Quit: Leaving) |
| 05:55:30 | * | carum quit (Remote host closed the connection) |
| 05:56:05 | * | carum joined #nimrod |
| 06:00:29 | * | carum quit (Ping timeout: 245 seconds) |
| 06:37:43 | * | vbtt joined #nimrod |
| 06:39:45 | vbtt | hello |
| 06:40:14 | vbtt | dom96, Araq: I've expanded the gsoc coroutine idea |
| 06:42:22 | vbtt | btw, anyone know what code generates the website from the txt files? |
| 06:43:54 | vbtt | nm, found nimweb |
| 06:53:25 | * | skyfex joined #nimrod |
| 07:05:02 | * | reactormonk joined #nimrod |
| 07:12:12 | * | DAddYE joined #nimrod |
| 07:20:01 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 07:29:18 | * | aftersha_ joined #nimrod |
| 07:30:01 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 07:39:16 | * | BitPuffi1 quit (Ping timeout: 265 seconds) |
| 07:43:21 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 07:44:19 | * | vbtt joined #nimrod |
| 07:53:26 | * | wa_ quit (Quit: Page closed) |
| 08:12:41 | * | rndbit quit (Ping timeout: 245 seconds) |
| 08:13:06 | * | Trixar_za quit (Ping timeout: 245 seconds) |
| 08:13:29 | * | Trixar_za joined #nimrod |
| 08:14:21 | * | musicalchair quit (Ping timeout: 245 seconds) |
| 08:14:38 | * | musicalchair joined #nimrod |
| 08:15:11 | * | fowl quit (Ping timeout: 245 seconds) |
| 08:15:38 | * | fowl joined #nimrod |
| 08:17:01 | * | rndbit joined #nimrod |
| 08:49:03 | * | _davidk_ joined #nimrod |
| 09:14:06 | * | surma joined #nimrod |
| 09:16:25 | * | DAddYE quit (Remote host closed the connection) |
| 09:34:27 | * | _davidk_ quit (Ping timeout: 272 seconds) |
| 09:34:37 | * | _davidk_ joined #nimrod |
| 10:13:58 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 10:17:31 | * | DAddYE joined #nimrod |
| 10:21:44 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 10:33:20 | * | zahary joined #nimrod |
| 10:36:27 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:44:13 | * | zahary quit (Quit: Leaving.) |
| 10:51:58 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 10:56:07 | * | BitPuffi1 joined #nimrod |
| 11:24:39 | * | _davidk_ quit (Ping timeout: 245 seconds) |
| 11:25:14 | * | _davidk_ joined #nimrod |
| 11:31:06 | * | _davidk_ quit (Ping timeout: 245 seconds) |
| 11:59:21 | * | BitPuffi1 is now known as BitPuffin |
| 12:01:20 | dom96 | hrmpf |
| 12:01:21 | dom96 | -MemoServ- Bitpuffin has read your memo, which was sent at Jan 26 17:59:31 2014 |
| 12:01:27 | dom96 | Took you long enough :P |
| 12:01:28 | BitPuffin | dom96: :P |
| 12:02:00 | dom96 | lies |
| 12:07:53 | BitPuffin | dom96: :D |
| 12:18:08 | * | ddl_smurf joined #nimrod |
| 12:36:27 | dom96 | BitPuffin: sup? |
| 12:36:42 | BitPuffin | o |
| 12:36:46 | BitPuffin | just coding |
| 12:36:48 | BitPuffin | and you? |
| 12:38:21 | dom96 | working on GSoC ideas |
| 12:42:47 | BitPuffin | dom96: what's the ideas? |
| 12:42:58 | dom96 | https://github.com/Araq/Nimrod/wiki/GSoC-2014-Ideas |
| 12:43:05 | BitPuffin | I know |
| 12:43:07 | BitPuffin | lol |
| 12:43:59 | BitPuffin | dom96: we should play dota ability draft |
| 12:44:01 | BitPuffin | it's hilarious |
| 12:44:12 | BitPuffin | you get a random hero and then you pick skills from a bunch of different heroes |
| 12:44:25 | dom96 | ooh, that sounds cool |
| 12:44:49 | BitPuffin | so you can for example be tidehunter with juggernaut ulti |
| 12:45:12 | BitPuffin | and venomancer plague wards |
| 12:45:16 | BitPuffin | or whatever |
| 12:45:18 | BitPuffin | you get the drift :P |
| 12:45:32 | BitPuffin | or a riki with pudge hook lol |
| 12:46:40 | dom96 | Problem is I won't know what to pick lol |
| 12:46:49 | dom96 | I'll end up picking some silly abilities. |
| 12:48:06 | BitPuffin | that's fine |
| 12:48:13 | BitPuffin | it's a for shits and giggles thing anyway |
| 12:49:24 | * | Ycros quit (Quit: No Ping reply in 180 seconds.) |
| 12:49:51 | * | Ycros joined #nimrod |
| 12:56:24 | * | askatasuna joined #nimrod |
| 12:56:41 | BitPuffin | dom96: lol: https://www.youtube.com/watch?feature=player_embedded&v=LLOlGkipXyU |
| 13:12:25 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 13:12:31 | dom96 | BitPuffin: wtf is this I don't even |
| 13:16:27 | renesac | BitPuffin: wow, a new addittion to my fukkireta collection |
| 13:18:10 | surma | Am i doing this wrong? I want to pass a TChannel as a parameter to a thread proc. Since it needs to be variable (and the thread parameter is not), I defined a reference type for TChannel. But how do I actually make it reference a TChannel? |
| 13:19:12 | dom96 | surma: You should make the TChannel a global var |
| 13:20:07 | surma | really? That is so not compatible with my Go mindset ^^ |
| 13:20:17 | BitPuffin | dom96: too much fun watching over edited dota 2 videos :( |
| 13:21:13 | dom96 | surma: Yeah. I can imagine. Out of curiosity, what made you leave Go? |
| 13:27:18 | fowl | where is nimgrep?? |
| 13:27:25 | BitPuffin | dom96: like this one https://www.youtube.com/watch?feature=player_embedded&v=qcw10LhMTuk |
| 13:27:29 | renesac | is there a technical reason that requires TChannel to be global? |
| 13:29:02 | dom96 | Well, the TChannel has to be kept alive. Best way to do that is to put it in the global namespace I guess. |
| 13:29:22 | EXetoC | fowl: in the tools dir |
| 13:29:49 | dom96 | I dunno. Maybe it is possible to pass a ref TChannel to a thread. |
| 13:29:58 | fowl | EXetoC, ty |
| 13:30:32 | dom96 | BitPuffin: 420noscopeswardingbrrrawwww |
| 13:33:30 | * | surma_ joined #nimrod |
| 13:35:42 | BitPuffin | dom96: hellyeee |
| 13:36:37 | * | surma quit (Ping timeout: 248 seconds) |
| 13:40:26 | fowl | waft |
| 13:46:11 | * | bbodi joined #nimrod |
| 13:46:41 | bbodi | hi all! How can I copy a string in memory? |
| 13:47:08 | bbodi | Do I have to copy it byte by byte, or is there a simpler way? |
| 13:47:18 | fowl | string2 = string21 |
| 13:47:23 | fowl | string2 = string1 * |
| 13:47:51 | fowl | there's copyMem() |
| 13:48:37 | bbodi | string2 = string1 just creates an other references to string1, but I want to create two copies of the string in different locations in memory |
| 13:49:05 | fowl | bbodi, no, string2 would be a copy of string1 |
| 13:49:26 | bbodi | fowl: I try it, thanks a lot! |
| 13:55:00 | bbodi | fowl: I try it, thanks a lot! |
| 14:03:15 | * | darkf quit (Quit: Leaving) |
| 14:07:00 | * | OrionPK joined #nimrod |
| 14:08:03 | * | dmac quit (Ping timeout: 272 seconds) |
| 14:17:26 | surma_ | dom96: Who said I left Go ;) I still love Go, I'm actually the organizer of Berlin's Go User Group. But for certain things I want to have more control (and freedom). And nimrod actually seems to satisfy all my needs while still being compiled, statically typed, cross platform and not stupid. |
| 14:17:36 | * | surma_ is now known as surma |
| 14:17:47 | EXetoC | \o/ |
| 14:17:48 | * | surma quit (Changing host) |
| 14:17:48 | * | surma joined #nimrod |
| 14:18:04 | dom96 | heh, I shouldn't have assumed you left it. |
| 14:18:22 | surma | I actually expect quite a lot of syerngy |
| 14:18:25 | surma | synergy* |
| 14:18:50 | dom96 | You should spread the news of Nimrod in your user group :) |
| 14:19:01 | skrylar | I remember using Go... I thought it was adorable. lol :) |
| 14:19:06 | surma | That is actually the plan, once I actually got up to speed |
| 14:19:15 | surma | We did Rust vs Go a while back |
| 14:19:25 | skrylar | admittedly at the time they hadn't solved the dynamic linking problem, exceptions or Windows support, so it wasn't useful to me :( |
| 14:19:32 | surma | And I assume some people really crave generics (although I'm here for the meta) |
| 14:19:58 | dom96 | surma: oh, I would be interested in such a comparison. Too bad I don't live in Berlin D: |
| 14:20:25 | surma | Well, Windows is done, exceptions are called `panics` (have always been there) and are discouraged to be used for flow control and dynamic linking only at compile time |
| 14:20:58 | skrylar | by panics you mean the 'stop the world abort()' calls that self respecting library designers will never use? :P |
| 14:21:00 | surma | dom96: Let me see if I can find the slides. But the main result was, that Go and Rust are actually not really the big rivals HN & others want them to be |
| 14:21:18 | surma | skrylar: Exactly. They should never be used by a library. |
| 14:21:21 | dom96 | I don't understand how people can live with Go's exception situation. |
| 14:21:42 | fowl | go has exceptions now? |
| 14:21:45 | skrylar | surma: abort() should never be used, at all |
| 14:22:23 | dom96 | fowl: I bet they realised that they are really useful in some scenarios so decided to implement them. But still discourage their use for some silly reason. |
| 14:22:34 | skrylar | dom96: no, 'panic' is abort() |
| 14:22:46 | skrylar | its the equivalent of doing a println() and segfault |
| 14:22:48 | fowl | i dislike the error-check api |
| 14:23:04 | dom96 | skrylar: So it's basically quit() in Nimrod? |
| 14:23:05 | fowl | err, foo := something(); if err: die() |
| 14:23:23 | skrylar | dom96: worse, because abort() tends to lead an OS to throw up crash warnings |
| 14:23:24 | surma | skrylar: No. They are recoverable |
| 14:23:33 | skrylar | they weren't when i used it :P |
| 14:23:40 | surma | panic() always had recover() |
| 14:23:47 | surma | since the very first release afair |
| 14:23:54 | skrylar | I used it before 1.0 |
| 14:24:06 | dom96 | surma: Would love to see the slides if you can find them. |
| 14:24:07 | surma | me too ;) That's why I said release, not stable |
| 14:24:08 | skrylar | i don't remember them having a recover, but *shrugs* |
| 14:24:40 | skrylar | i don't see why libraries shouldn't use exceptions, they're useful things that serve a use; there's even some microcontroller code that uses the setjmp varient of them |
| 14:24:58 | skrylar | they did this analysis and found it was way more efficient than branching after *every* procedure call to check for an error |
| 14:25:00 | surma | skrylar: Its used - for example - to sandbox the goroutines for each incoming http connections. If one of them panics (may that be a custom panic or a runtime panic like Index OOB), it doesn't affect anythng else and produces a 500 response |
| 14:25:29 | skrylar | (source: http://www.on-time.com/ddj0011.htm ) |
| 14:25:37 | surma | skrylar: You can, you might. But you should really think about if it's the right way to do that. There are perfectly valid usecases for panics in libraries. |
| 14:26:23 | * | rixx joined #nimrod |
| 14:26:29 | dom96 | hello rixx |
| 14:27:00 | rixx | hi :) |
| 14:27:09 | dom96 | welcome to #nimrod :) |
| 14:27:17 | rixx | thanks |
| 14:27:47 | skrylar | surma: i just went and looked up 'recover'... it looks like its the equivalent of rust fail! |
| 14:30:12 | EXetoC | makes sense |
| 14:30:20 | EXetoC | no, wait.. |
| 14:30:47 | skrylar | IMO i tend to prefer a first class try/catch system, since when they are used properly they are very nice ways of dealing with problems |
| 14:31:38 | skrylar | though i think they suffer from C++ being most people's implementation of it, which is a horrible system (as is a lot of C++) |
| 14:32:12 | surma | skrylar: I'm always afraid it will turn code into try/catch-hell like I have gotten to know from Java. In my experience, the amount of function-call-and-error-handling-code goes down a lot. It isn't really as annoying as it first seems. |
| 14:32:44 | surma | skrylar: Also, in that way, Go really is forcing you into a lot of things. But they bring their benefits esp. at large scale projects |
| 14:33:03 | surma | Code is very explicit and maintainable without being noisy. |
| 14:33:20 | skrylar | I prefer when compilers obey instead of dictate |
| 14:33:36 | surma | Yeah, than Go is not for you ;) |
| 14:33:45 | skrylar | And i hate having to "if (x != 0) { welp(); }" |
| 14:34:50 | skrylar | I left Rust because there were bugs and incompletions in the workaround for getting a display-tree GUI working |
| 14:36:34 | skrylar | admittedly i could replace the parent pointers with lookup handles but that would add in an unpleasant degree of bookkeeping |
| 14:37:07 | surma | Funnily enough, I never touched (native) GUI programming ever since I started with Go |
| 14:37:34 | surma | And I don't plan to change that in the futuer with any language I look at |
| 14:38:03 | skrylar | heh |
| 14:38:07 | skrylar | I still prefer my non-cloud :) |
| 14:40:36 | skrylar | I kinda miss the days when Applescript was taken seriously and you could tie two GUI apps together, and when this whole concept of applications being cross compatible was an idea people sometimes used |
| 14:41:06 | surma | I'm not saying I dont like using GUIs. I just find them incredible boring to write. |
| 14:41:30 | surma | So I usually just write a web api and use the humongous eco system of libraries for web dev to write a GUI there (even for local applications) |
| 14:41:33 | surma | yeah, AppleScript was fun |
| 14:41:39 | surma | Even if a little weird to write |
| 14:42:25 | skrylar | yay hypertalk \o/ the system they killed because it was too successful at what it did |
| 14:42:51 | skrylar | Kinda sets a bad precedent when technologies die because they were good at something o_o |
| 14:44:39 | surma | Just wait for Skynet.... |
| 14:44:46 | surma | (written in Go(tm) btw ^^) |
| 14:44:58 | fowl | brought to you by google |
| 14:45:14 | fowl | they're working on robots and self-driving cars.. spooky |
| 14:45:17 | dom96 | They have bought Boston Robotics recently... |
| 14:46:53 | skrylar | I'm not worried about a Skynet from Google |
| 14:47:00 | skrylar | they can't tell their ass from a hole in the ground most of the time |
| 14:48:16 | skrylar | I've spoken to more than a few people who has client contracts with Google and they're completely unhelpful, for instance |
| 14:49:03 | skrylar | I've also seen a lot of stupidity like when they banned the guy who made Choice of Games from adsense, and they wouldn't bother to highlight what section he actually supposedly violated |
| 14:51:39 | OrionPK | skynet written in Go would be pretty slow wouldnt it? :P |
| 14:51:55 | surma | Oh the flame bait ^^ |
| 14:51:57 | OrionPK | i imagine it'd have to rewrite itself in binary |
| 14:52:28 | skrylar | I was going to say something about "Go isn't *that* slow" but then I remembered seeing the benches ._. |
| 14:52:37 | OrionPK | lol |
| 14:52:42 | skrylar | its actually not bad compared to a lot of languages |
| 14:52:43 | surma | Skynet is actually a project by one of the more known Go users https://github.com/skynetservices/skynet |
| 14:53:21 | surma | It's a reputation that just stuck with people from the early days, where performance was alright but not good. A lot has changed tho |
| 14:53:42 | OrionPK | i converted a benchmark from go go nimrod not that long ago |
| 14:53:49 | OrionPK | https://github.com/kidoman/rays |
| 14:53:51 | skrylar | Hmm no, I recall seeing some more modern benches where Rust was outperforming Go |
| 14:54:19 | skrylar | http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/ |
| 14:54:34 | OrionPK | that benchmark was actually written to demonstrate how fast Go is iirc |
| 14:54:44 | bstrie | skrylar: https://github.com/nsf/pnoise |
| 14:54:53 | skrylar | Nimrod has the lowest SLOC but that could just be the removal of closing braces |
| 14:55:07 | surma | I dont really like the SLOC metric |
| 14:55:33 | skrylar | i don't care about the sloc on that chart, mostly found it interesting that LDC was outdoing C++ o_o |
| 14:55:39 | surma | and also: I find it interesting how people focus so hard on miniscule performance difference. 99% of people don't have issues which have to be solve by performance of the language itself |
| 14:55:57 | OrionPK | well.. it's not miniscule when it's 50% difference |
| 14:56:31 | OrionPK | but benchmarks are pretty artificial usually |
| 14:56:40 | skrylar | I usually look at the 'miniscule' difference as an example of toolchain bloat |
| 14:56:48 | skrylar | but i tend not to use the same benchmarks |
| 14:57:11 | skrylar | by toolchain bloat i mean "if i write 'a=b+c' how many clocks is it before i get an answer?" |
| 14:57:25 | skrylar | In something like python you take a 50% or more hit just because |
| 14:57:41 | OrionPK | i would say... how many clocks before it even gets to the question |
| 14:57:44 | OrionPK | not the answer |
| 14:58:23 | surma | I'd rather see development benchmarks. "How long does compiling take?" "How easily is debugging set up?" "How navigatable is the documentation". |
| 14:58:26 | surma | lol |
| 14:58:35 | OrionPK | ;) |
| 14:58:52 | OrionPK | that's all a bit subjective, unfortunately |
| 14:59:00 | skrylar | compiling, eh |
| 14:59:11 | skrylar | i'm happy with FPC's compile times |
| 14:59:14 | OrionPK | well, compile time isnt subjective |
| 14:59:24 | skrylar | its probably a lot slower than Go, but its significantly faster than most |
| 15:00:02 | surma | FPC? |
| 15:00:06 | skrylar | Freepascal |
| 15:00:28 | skrylar | OrionPK: the total time is objective, but if that time is a problem isn't |
| 15:00:47 | skrylar | for instance i doubt people care much about build times for a final dev release, which you rarely make |
| 15:00:58 | surma | I have to say, Go spoiled me the most when it comes to documentation and tooling. |
| 15:01:02 | skrylar | at that point you just want the program fast and all the instrumentation is removed |
| 15:01:20 | surma | skrylar: Probably true. But when I think back at my C/C++ times - I couldn't stand that anymore |
| 15:01:49 | skrylar | surma: yeah but those problems have solutions :( |
| 15:01:55 | skrylar | the C derps just aren't interested |
| 15:03:17 | skrylar | there's a handfull of things like storing symbol caches to mitigate the 60mb worth of header and template hell, and the compiler as a service so it doesn't have to reindex the cache every single file |
| 15:03:23 | skrylar | GCC doesn't want any of that |
| 15:03:44 | skrylar | and sadly, the majority of C++ compile time *is* spent in the parser |
| 15:04:59 | skrylar | i think it comes down to a culture of this http://xkcd.com/303/ lol |
| 15:05:03 | surma | Well, with that kind of syntax, what do you expect ;) |
| 15:06:03 | skrylar | surma: Wirth suggested as much :P but nobody listens to him |
| 15:06:34 | skrylar | Some of the weirdisms in Pascal actually had/have everything to do with being able to build a humongous code base from zero in a minute |
| 15:08:07 | skrylar | But C++ devs usually live in cognitive dissonance land where they don't want to understand that they live in infinite complexity, because they will tell you all these things about how "those languages aren't optimized so of course they are faster" and completely breeze over any instrumentation that shows the optimizer isn't the problem lol |
| 15:08:18 | skrylar | so nothing gets fixed :/ |
| 15:13:18 | OrionPK | C can compile pretty quick ;) |
| 15:13:57 | skrylar | it can, yeah |
| 15:14:07 | skrylar | don't ask it to parse 60mb of sadness :) |
| 15:14:36 | surma | a_lot_of_sadness.c |
| 15:14:47 | surma | #include <insanity.h> |
| 15:15:16 | skrylar | maybe its unfair to compare things with C because C does have to basically include megabytes of overhead for each file, whereas almost literally everything which is not C has done it symbolically |
| 15:15:40 | skrylar | either through symbol tables or the Lisp/Forth/Smalltalk system of images |
| 15:17:21 | skrylar | or they did at the time; i think ruby still parses files every time it goes to read them, though python does have .pyc's |
| 15:19:15 | * | surma left #nimrod (#nimrod) |
| 15:24:08 | skrylar | anyhow, back to line wrapping hell for me \o/ |
| 15:35:14 | dom96 | You guys think this is thorough enough? https://github.com/Araq/Nimrod/wiki/GSoC-2014-Ideas |
| 15:37:35 | skrylar | Light Table you say |
| 15:37:41 | * | skrylar peers at this website with curiosit |
| 15:42:03 | skrylar | oh. its primarily a clojure thing |
| 15:51:46 | Araq | hi rixx welcome |
| 15:52:07 | rixx | hi :) |
| 15:52:19 | rixx | thanks ^^ |
| 15:58:11 | * | [1]Endy joined #nimrod |
| 16:05:44 | * | brihat joined #nimrod |
| 16:10:19 | Araq | skrylar: from my limited experience FPC compiles much faster than Go ... |
| 16:12:01 | * | [2]Endy joined #nimrod |
| 16:15:38 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 16:43:53 | reactormonk | are seqs on the stack or heap? |
| 16:44:32 | Araq | heap |
| 16:50:23 | * | vbtt joined #nimrod |
| 16:57:10 | skrylar | Araq: I would be really surprised if it did |
| 16:58:32 | OrionPK | woow |
| 16:58:49 | OrionPK | adding noinit to some procs in this benchmark improved the time by like 50% |
| 16:59:15 | OrionPK | would be nice if the compiler somehow didnt generate a result variable if it's not used |
| 16:59:40 | skrylar | how would that work? :) |
| 16:59:55 | Araq | OrionPK: planned optimization |
| 17:00:04 | OrionPK | thought so :) |
| 17:00:25 | skrylar | well, if it could prove there was no exit branch that didn't end in 'return' |
| 17:00:53 | OrionPK | right |
| 17:01:20 | skrylar | not surprised removing initializers speeds code up though |
| 17:01:31 | skrylar | thats a series of probably unoptimized mov's |
| 17:02:02 | renesac | OrionPK, what benchmark? |
| 17:02:15 | OrionPK | https://github.com/nsf/pnoise |
| 17:02:18 | OrionPK | converted that to nimrod |
| 17:03:00 | OrionPK | C runs ~ 0.290s, nimrod is ~ 0.337s on my machine |
| 17:03:02 | * | skrylar feels stupid commenting on compiler optimizations while spending 3 days to fail a line wrapping alg |
| 17:03:38 | fowl | OrionPK, now beat rust |
| 17:03:54 | OrionPK | fowl i dont have rust compiler on my machine, so i have no idea what it's at |
| 17:04:07 | skrylar | eh, throw it through clang |
| 17:04:27 | skrylar | Rust mostly works through making LLVM IR and then asking LLVM to run its built-in passes over it |
| 17:04:37 | OrionPK | nimrod was 0.730s before the noinit's |
| 17:05:26 | renesac | hum, maybe something similar is killing D speed |
| 17:05:50 | skrylar | renesac: D automatically initializes |
| 17:06:04 | skrylar | its non-optional at least in D1 IIRC |
| 17:06:18 | OrionPK | if anyone wants to compare rust, the nimrod version is here: https://gist.github.com/onionhammer/8979260 |
| 17:06:36 | skrylar | i have a rust compiler still if everyone's just curious |
| 17:06:37 | renesac | IIRC there were ways to get unitilialized memory in D2 |
| 17:07:01 | Araq | Foo foo = void; |
| 17:07:32 | fowl | OrionPK, lerp and smooth should be inline |
| 17:07:56 | OrionPK | fowl they were actually |
| 17:08:12 | OrionPK | saw no difference in performance |
| 17:08:24 | Araq | OrionPK: just compare the assembler that C produces with the assembler that nimrod's C output produces for fuck's sake |
| 17:08:41 | OrionPK | :P |
| 17:08:47 | OrionPK | why would I do that |
| 17:09:17 | OrionPK | im not asking any questions, this is purely informational |
| 17:09:26 | fowl | OrionPK, why not pass around var tnoise2dcontext instead of ptr |
| 17:09:33 | Araq | oh well, I will do it one day |
| 17:09:40 | skrylar | rust 0.10-pre; build time 5s, run time 0.420s |
| 17:09:49 | skrylar | --opt-level=3 |
| 17:09:55 | OrionPK | fowl no idea |
| 17:10:20 | * | ics joined #nimrod |
| 17:11:51 | OrionPK | skrylar what about nimrod |
| 17:12:08 | skrylar | nimrod: compile 2.19s, --opt:speed -x:off |
| 17:12:16 | skrylar | runtime: 0.355s |
| 17:12:43 | fowl | what -x:off do |
| 17:12:49 | skrylar | all runtime checks off |
| 17:12:55 | fowl | oh |
| 17:12:56 | skrylar | e.g. don't bounds check array access |
| 17:13:02 | OrionPK | so it beats rust :P |
| 17:13:20 | skrylar | they both might have run faster if i wasn't running them in an SSH shell lol |
| 17:13:30 | OrionPK | i dont think that would matter.. |
| 17:13:36 | skrylar | nimrod to dev null: 0.278 |
| 17:13:48 | skrylar | rust to dev null: 0.363 |
| 17:14:03 | bstrie | skrylar: yeah I was poking at the rust version this morning, I have no idea how nsf got his numbers. we must have regressed since his measurements |
| 17:14:04 | OrionPK | oh you were just outputting to stdout? |
| 17:14:16 | skrylar | yeah |
| 17:14:27 | skrylar | stdout via tmux via ssh |
| 17:14:38 | OrionPK | so there u go fowl |
| 17:14:42 | OrionPK | it beats rust |
| 17:14:58 | skrylar | its possible i didn't set rust to fast mode correctly |
| 17:15:14 | bstrie | skrylar: no, even on my current test machine rust is twice as slow as C |
| 17:15:24 | bstrie | skrylar: I'm trying to figure out where the rust is going wrong |
| 17:15:28 | OrionPK | there's always more flags to pass in skrylar |
| 17:15:34 | skrylar | i could have sworn LLVM made better code than GCC |
| 17:15:42 | bstrie | skrylar: not usually, no :P |
| 17:15:46 | OrionPK | skrylar this is how I was compiling nimrod c -d:release --passC:-std=c99 --passC:-Ofast --passC:-march=native --passC:-msse3 --passC:-mfpmath=sse -o:bin_test_nim test.nim |
| 17:15:48 | OrionPK | :P |
| 17:16:03 | OrionPK | I also had a test.nimrod.cfg with even more flags |
| 17:16:08 | Araq | sometimes LLVM is faster, sometimes GCC is |
| 17:16:13 | fowl | OrionPK, surely you could do --passC:"opt1 op2 op3" |
| 17:16:22 | skrylar | I know I prefer using LLVM/Clang |
| 17:16:32 | skrylar | partly because the error messages are useful and the architecture is nicer |
| 17:16:36 | * | ddl_smurf joined #nimrod |
| 17:17:16 | skrylar | my guess is that llvm probably beats gcc in extreme microoptimizations, if nothing else because you *can* go and tell it to run different opts on different obj files |
| 17:17:29 | skrylar | if you knew what each llvm pass did and felt like minmaxing them |
| 17:17:33 | zahary___ | Rust have decided to ditch segmented stack, but have they done this already? |
| 17:17:54 | bstrie | zahary___: I'll check |
| 17:18:10 | skrylar | e.g. if you want you can have tail call recursion in C through llvm :o |
| 17:18:39 | zahary___ | gcc is doing it too - we actually had a GC related problem due to tail recursion once |
| 17:19:12 | bstrie | zahary___: totally gone, yeah |
| 17:19:37 | BitPuffin | So hey guys how do you like this bug I'm working with |
| 17:19:44 | BitPuffin | When I have this line in the code: |
| 17:19:45 | BitPuffin | NSLog(@"Adding file with id %@", identifier); |
| 17:19:49 | BitPuffin | it doesn't crash |
| 17:19:55 | BitPuffin | but if I comment it out it does |
| 17:21:20 | BitPuffin | :'D |
| 17:23:47 | Araq | BitPuffin: -d:useGcAssert -d:useSysAssert |
| 17:24:26 | BitPuffin | Araq: it's an objective-c thing |
| 17:25:19 | * | Mat3 joined #nimrod |
| 17:25:24 | Mat3 | hi all |
| 17:26:44 | * | Demos joined #nimrod |
| 17:31:27 | fowl | OrionPK, i get 3.5s for ur thing |
| 17:33:12 | fowl | nvm, 0.494s |
| 17:39:07 | * | DAddYE joined #nimrod |
| 17:41:50 | Mat3 | hi DAddYE |
| 17:42:16 | dom96 | reactormonk: BitPuffin: EXetoC: fowl: and anyone else: would you guys mind being "backup" mentors for GSoC? |
| 17:42:53 | * | vbtt quit (Ping timeout: 260 seconds) |
| 17:43:57 | dom96 | I'm assuming you will help GSoC students in here anyway. But just in case one of the "primary" mentors disappears, which is unlikely to happen, it would be cool if you guys could help out more. |
| 17:48:36 | Mat3 | for my Nimrod subset I plan to abstract memory access though type objects which collect memory references and ensure valid access instead of the type casting mechanism. What are your opinions about this idea ? |
| 17:49:11 | renesac | pypy got funding through some european financing program... did someone here tried something similar for nimrod? |
| 17:51:26 | BitPuffin | dom96: sure |
| 17:51:33 | dom96 | BitPuffin: Great :D |
| 17:51:43 | Mat3 | dom96: I think only of help for machine-level programming stuff, sorry |
| 17:53:27 | dom96 | Mat3: Why? |
| 17:53:29 | Demos | Mat3, sounds like a java-style garbage collector |
| 17:53:40 | renesac | OrionPK, that pnoise benchmark don't specifies the random number generator... it could be a big reason for some of the speed differences |
| 17:54:20 | Mat3 | Demos: Jes, i is an similar idea (the Java solution however is .. ehm, academic) |
| 17:54:24 | Mat3 | ^Yes |
| 17:54:59 | Demos | I like the idea of being able to set up my memory in such a way as to be able to defragment it |
| 17:55:03 | Demos | but it sounds really hard |
| 17:55:43 | Mat3 | dom96: I have to less experience with the Nimrod compiler - probably I can help out implementimng coroutines at demand though |
| 17:56:01 | dom96 | Mat3: That would already be a big help. |
| 17:57:51 | Demos | well lets see if nimrod even gets accepted first |
| 17:58:22 | Mat3 | Demos: That's an side-effect of this approach. Much more important is memory tagging for dynamic error detection (illegal accesses, wrong storage type, buffer overflows etc.) |
| 18:00:31 | Demos | right, but I think the compaction and defrag is more important. you can use bonds checking to get rid of some illegal accesses and you can allocate memory in such a way that segfaults happen more often for some others. Not ideal but still. |
| 18:00:36 | dom96 | Demos: There is some tough competition like for example: ReactOS. |
| 18:01:00 | Mat3 | it also a valid replacement for complex, static type systems... (which have some impact on the code-size, specially for implementations on say micor-controllers) |
| 18:01:01 | Demos | nimrod is more useful than react though :D |
| 18:01:37 | Mat3 | ^micro-controllers |
| 18:01:48 | Demos | well static type systems have no runtime binary size impact, beyound like generic generation and such |
| 18:01:57 | Demos | and doing the static type system means you either need to explicitly managed sizes or have everything on the heap |
| 18:01:57 | dom96 | Demos: :) |
| 18:02:19 | dom96 | Demos: What do you think of our ideas page? https://github.com/Araq/Nimrod/wiki/GSoC-2014-Ideas |
| 18:02:30 | Mat3 | Demos: I plan an interpretative environment - not much related to the Nimrod compiler |
| 18:03:07 | Demos | why is the "times" module improvements marked easy? |
| 18:03:33 | Demos | also I see react has a little FAQ for like "what happens for diappearing mentors" and the like |
| 18:03:46 | Demos | also, I need to go to a chemestry lecture in -3 mins |
| 18:03:51 | dom96 | I'd say it's easy compared to the other tasks. |
| 18:04:00 | * | brson joined #nimrod |
| 18:04:52 | * | Mat3 the Nimrod compiler really do not fit in 16 kByte ;) |
| 18:04:56 | Demos | right, like it needs little compiler knowlege, but it is /times/ |
| 18:05:15 | * | brson quit (Client Quit) |
| 18:05:24 | Demos | Mat3, sure, but the generated executables can fit |
| 18:05:44 | * | brson joined #nimrod |
| 18:05:55 | Demos | anyway I gotta go |
| 18:06:01 | * | Demos quit (Read error: Connection reset by peer) |
| 18:06:13 | EXetoC | is the C++ backend unused? |
| 18:06:58 | Mat3 | Demos: Yes of course, but this approach do not allow rapid prototype development on the target (which is the *top* thema nowadays, see eLua for example) |
| 18:07:38 | bstrie | skrylar OrionPK: got nsf to update his perlin noise benchmark repo with your nimrod program: https://github.com/nsf/pnoise |
| 18:07:42 | Mat3 | or ML on Bare-Metal, or the reactivation of various Basic dialects etc... |
| 18:08:50 | EXetoC | I'd like to compare the overhead of the exception mechanism |
| 18:08:55 | * | DAddYE quit () |
| 18:09:01 | Mat3 | (I hope he read this later on the log) |
| 18:09:25 | EXetoC | Mat3: speaking of which, how far have you gotten? because the asm backend should be similar in that regard |
| 18:15:03 | * | DAddYE joined #nimrod |
| 18:15:40 | Mat3 | EXetoC: The VM is finished and also the AOT compiler. I'm currently work on the documentation of these stuff (as requested from Araq) and start the environment implementation |
| 18:16:06 | * | DAddYE quit (Client Quit) |
| 18:16:13 | EXetoC | ok |
| 18:17:08 | * | DAddYE joined #nimrod |
| 18:17:20 | EXetoC | how can I ensure that something with a reference count of 0 is collected? |
| 18:18:02 | dom96 | Mat3: Is the source available anywhere? |
| 18:18:35 | Mat3 | I am preparing a web site (shoud be finished next week) |
| 18:19:01 | EXetoC | or rather, that the finalizer gets called. I know that finalizers are preferred over destructors for now, but I haven't heard anything about any issues |
| 18:19:08 | * | skyfex joined #nimrod |
| 18:19:10 | dom96 | Mat3: great |
| 18:20:34 | EXetoC | ok, GC_fullCollect. 'quit' mentions GC_collect but it's not exported |
| 18:25:03 | EXetoC | actually it doesn't exist |
| 18:33:42 | reactormonk | dom96, uhm, yup, but I don't have too much clue about the compiler |
| 18:34:34 | dom96 | reactormonk: Hopefully every student won't be doing compiler work but also stdlib stuff. |
| 18:35:41 | skrylar | I'm not a student so I guess I can't do doc writing :P |
| 18:36:28 | reactormonk | skrylar, you can still do it, but we can't pay you for it |
| 18:37:05 | skrylar | i have actually yet to see 'nimrod doc x.nim' produce more than an empty html file |
| 18:37:16 | EXetoC | doc2? |
| 18:37:47 | skrylar | lib/terminal.nim(329, 21) Error: internal error: not used |
| 18:38:45 | skrylar | i actually had an idea for a doc tool but i never got around to writing it; basically using a special tag and vim markers so you could assign a keyword to arbitrary text, then it would checksum that text and store it in an index |
| 18:39:17 | Araq | nimrod doc lib\pure\terminal.nim works for me ... |
| 18:39:29 | skrylar | the reason for that is you could then take the keyword and index, go to your other docs and put in the ":foobar:30823084:" in a comment, and then your external docs could be auto-checked for calling changed methods |
| 18:39:50 | skrylar | which would be useful because docs you placed in wiki text for instance would get auto-flagged |
| 18:40:59 | Mat3 | ciao |
| 18:41:06 | Araq | Mat3: bye |
| 18:41:09 | * | Mat3 quit () |
| 18:41:57 | reactormonk | skrylar, first we fix bugs, then we add features ;-) |
| 18:42:19 | skrylar | reactormonk: that was a standalone tool ;p |
| 18:42:46 | reactormonk | Araq, https://github.com/Araq/Nimrod/pull/910#issuecomment-34998628 <- that's gonna be interesting. |
| 18:44:37 | OrionPK | bstrie ah thanks |
| 18:47:06 | OrionPK | bstrie get him to add test.nimrod.cfg as well ;) |
| 18:47:07 | OrionPK | https://gist.github.com/onionhammer/8979260 |
| 18:53:45 | EXetoC | Araq: are there any plans to allow user-defined constructors to be allocation-agnostic (heap, GC heap, stack)? the proposed 'func' pragma comes to mind |
| 18:59:04 | EXetoC | I suppose 'var' parameters allows for that if you're willing to perform casts |
| 19:04:49 | * | micklat joined #nimrod |
| 19:05:27 | * | carum joined #nimrod |
| 19:05:40 | Araq | EXetoC: I have no plans for that before 1.0 is out |
| 19:13:52 | * | vbtt joined #nimrod |
| 19:18:22 | * | carum quit (Read error: Connection reset by peer) |
| 19:18:43 | * | carum joined #nimrod |
| 19:28:18 | reactormonk | micklat, works as intended. |
| 19:28:38 | micklat | sorry, what? |
| 19:28:46 | micklat | you mean it compiles on your machine? |
| 19:30:32 | reactormonk | micklat, nope, the error works as intended. you can't mix containers and values with varargs |
| 19:30:47 | micklat | why? |
| 19:31:00 | reactormonk | hm.... because you can't in ruby? :-) |
| 19:31:21 | reactormonk | but as soon as you have varags[seq[T]] stuff gets hairy |
| 19:31:40 | micklat | honestly, what's the problem? |
| 19:33:09 | skrylar | I would guess the way you transferred the sequence in |
| 19:33:58 | micklat | skrylar: I don't follow |
| 19:34:43 | skrylar | micklat: i don't see why its not technically possible either, though usually when i say things like that someone comes in with this weird obscure explanation about the compiler doesn't allow you to do that on tuesdays |
| 19:37:55 | micklat | ruby isn't even statically typed |
| 19:38:37 | reactormonk | micklat, yeah, that's why you can't do it there |
| 19:38:58 | micklat | but you can do it in python |
| 19:39:09 | reactormonk | how does it decide what's what? |
| 19:39:22 | micklat | How does what decide what's what? |
| 19:39:36 | reactormonk | well, you have to treat containers different from values |
| 19:39:52 | micklat | is it because of the value semantics? |
| 19:40:19 | micklat | do you copy the whole array to stack, and having array arguments complicates your life? |
| 19:40:36 | reactormonk | no idea |
| 19:40:58 | micklat | so I don't understand your question then |
| 19:42:25 | Araq | micklat: what does thirteen("a", 1, 2) produce? |
| 19:42:31 | micklat | 13 |
| 19:42:42 | micklat | or, at least it should |
| 19:42:49 | Araq | lol |
| 19:42:57 | Araq | well what does the compiler say? |
| 19:43:13 | Araq | in any case, it's a bug |
| 19:43:42 | micklat | the compiler compiles it correctly |
| 19:44:01 | Araq | so it's confused by the [] |
| 19:46:10 | micklat | echo thirteen({1}, 2) works too |
| 19:47:13 | Araq | yeah well [] with varargs is special, because you can write [1,2] instead of 1,2 for varargs[int] |
| 19:47:29 | * | xtagon joined #nimrod |
| 19:47:39 | Araq | ... except when it's varargs[expr] |
| 19:47:52 | * | bbodi2 joined #nimrod |
| 19:48:26 | micklat | you mean that thirteen([1,2]) is a call with 2 rather than 1 argument? |
| 19:48:32 | micklat | how inconsistent |
| 19:49:10 | bbodi2 | Hi all! I have a question: How can I get a data structure's memory as a byte array? |
| 19:49:48 | fowl | bbodi, cast[ptr array[sizeof(x), byte]](obj.addr) |
| 19:50:07 | bbodi2 | fowl: thanks a lot |
| 19:50:49 | bbodi2 | fowl: are there any difference between a byte array and a string? ( I ask it because with string I can use Streams ) |
| 19:52:38 | fowl | strings end with '\0', have a length, are garbage-collected |
| 19:53:09 | fowl | what are you trying to do |
| 19:53:11 | * | eager-beaver joined #nimrod |
| 19:53:18 | Araq | hi eager-beaver welcome |
| 19:53:59 | micklat | is there any hope of trying to convince anyone that arrays should not be a special case in varargs? |
| 19:54:22 | Araq | micklat: you convinced me already |
| 19:54:23 | bbodi2 | I convert any data structure to a byte array, then modify the byte array so that the data structure's field will be modified as well. |
| 19:54:28 | micklat | yay! |
| 19:54:45 | * | brson quit (Ping timeout: 248 seconds) |
| 19:54:57 | * | shodan45 joined #nimrod |
| 19:55:14 | dom96 | Whoa. Look at that user count. |
| 19:55:27 | dom96 | welcome eager-beaver |
| 19:55:42 | * | brson joined #nimrod |
| 19:56:02 | fowl | bbodi, if you're reading/writing data id recommend using streams |
| 19:56:09 | eager-beaver | thank you all for the welcome |
| 19:56:36 | bbodi2 | I would like to use it too. But if I know it well, there aren't Stream for byte arrays |
| 19:57:38 | bbodi2 | hi eager-beaver! |
| 19:57:39 | * | skrylar sighs of relief as this wordwrap code finally greens all the tests |
| 19:57:46 | fowl | bbodi2, see my example https://github.com/Araq/Nimrod/issues/907 |
| 19:58:35 | fowl | bbodi, then to unserialize your obj type you would define proc `>>` (left:PStream; right:var MyObj) = left >> right.field1 >> right.field2 |
| 19:58:40 | * | tdc joined #nimrod |
| 19:59:00 | * | eager-beaver is now known as bezeredi |
| 19:59:46 | bbodi2 | fowl: thanks a lot! |
| 20:00:15 | fowl | bbodi2, also take a look at streams.nim, it wont be hard to implement a stream for a byte array if you want to |
| 20:01:53 | dom96 | oh cool. When I google "nimrod programming" I get a picture of Araq now. |
| 20:03:06 | * | nande joined #nimrod |
| 20:03:12 | fowl | bbodi2, now that im looking at streams.nim i would probably just steal the private read[T] function from it, no need for these overloads |
| 20:03:48 | Araq | hi nande welcome |
| 20:05:46 | nande | hi Araq :) thanks |
| 20:05:58 | nande | ive seen Nimrod a lot of time before and i love it :) |
| 20:06:04 | Araq | :O |
| 20:06:25 | nande | too bad the zip linked on the web doesnt compile maybo you should update it. |
| 20:06:39 | nande | now im trying to build from git but takes a lot to dowload |
| 20:09:45 | Araq | git clone --depth 1 iirc |
| 20:09:53 | Araq | the wiki tells you |
| 20:10:04 | micklat | BTW, is anyone taking "nimrod i" seriously? |
| 20:10:36 | micklat | I mean, should I bother with bug reports about it? |
| 20:10:53 | Araq | no |
| 20:11:04 | micklat | ok |
| 20:11:34 | nande | i did exactly as the wiki said. took more than 10 mins |
| 20:11:54 | nande | http://screencloud.net/v/CzIJ |
| 20:12:16 | nande | itll be nice to have updated info on the front page. might scare newcommers |
| 20:12:55 | * | carum quit (Remote host closed the connection) |
| 20:13:22 | Araq | nande: afaict you didn't do exactly as the wiki said |
| 20:14:16 | dom96 | nande: You didn't clone with the '--depth 1' switch. |
| 20:14:17 | fowl | Araq, it says use --depth 1 on csources but not nimrod for some reason |
| 20:14:37 | Araq | and yes we know the website is outdated, happens when a release is overdue but nobody fixes showstopper bugs |
| 20:14:52 | Araq | fowl: oh |
| 20:15:05 | fowl | btw i recently found out that --depth 1 checks out only the master branch, i had to jump through some hoops to get the other branches |
| 20:15:09 | nande | the wiki didnt said -1 except on the second clone |
| 20:15:24 | * | zahary joined #nimrod |
| 20:16:01 | reactormonk | Araq, showstoppers == https://github.com/Araq/Nimrod/issues?labels=major&page=1&state=open ? |
| 20:17:10 | Araq | reactormonk: almost, bug #124 is no show stopper |
| 20:17:45 | reactormonk | Araq, I'll retag it as minor |
| 20:18:05 | Araq | no, we need a new category for that |
| 20:18:39 | reactormonk | Araq, showstopper? |
| 20:18:54 | Araq | ok |
| 20:19:46 | Araq | though it makes no sense to have showstopper bugs when I plan to go with a "release by date" model |
| 20:20:17 | reactormonk | Araq, just make a release once every showstopper is killed |
| 20:20:29 | reactormonk | and at least each month |
| 20:21:00 | reactormonk | Araq, done. Feel free to uncheck a few boxes. |
| 20:23:06 | skrylar | er, i disagree |
| 20:23:20 | skrylar | you don't want to do the Rust thing and have a release where code segfaults out of the bod |
| 20:23:23 | skrylar | *box |
| 20:23:33 | bbodi2 | I have a data field like that: data*: array[int, byte] and a line of code: result.data = cast[array[sizeof(T), byte]](addr data) |
| 20:23:35 | nande | also http://screencloud.net/v/99Dy theres a permission error on the wiki |
| 20:23:46 | bbodi2 | But i get compiler error: Error: type mismatch: got (array[int, Byte]) but expected 'array[int, Byte]' |
| 20:24:26 | Araq | bbodi2: not sure but data*: array[int, byte] is wrong |
| 20:24:49 | fowl | bbodi2, are you working on the streams thing? |
| 20:24:53 | bbodi2 | yes |
| 20:25:07 | bbodi2 | But now, I just want to convert a custom data type to a bunch of bytes |
| 20:25:33 | fowl | bbodi2, you'll want to store it as ptr array[int.high, byte] since array cannot be dynamic sized |
| 20:25:40 | reactormonk | nande, yeah, someone messed up the generation script |
| 20:25:55 | reactormonk | nande, take it as a slight entrance check >;) |
| 20:26:06 | nande | is just a detail just saying |
| 20:26:10 | nande | entrance check? |
| 20:26:18 | reactormonk | nande, you know, like the bouncer in a club |
| 20:26:29 | Araq | bbodi2: use 'cstring' instead of 'array ...' |
| 20:26:40 | fowl | yea do that ^ |
| 20:26:50 | bbodi2 | what is the different? |
| 20:27:07 | Araq | compiler is more forgiving when it comes to 'cstring' |
| 20:27:16 | reactormonk | nande, https://github.com/nimrod-code/csources <- wrap up a PR here |
| 20:28:19 | nande | oh thanks reactormonk. english is not my native language. |
| 20:28:23 | bbodi2 | fowl, Araq: thanks guys, you are awesome |
| 20:30:20 | nande | also im trying to build aporia but it complains of a missing library which i seem to have installed. am i missing something? http://screencloud.net/v/wYGy |
| 20:31:23 | reactormonk | nande, you got libglib2.0-dev ? |
| 20:31:30 | fowl | nande, its missing a (nimrod) module, not a library |
| 20:31:47 | fowl | you need the gtk package from babel |
| 20:33:20 | nande | reactormonk: yes i have that installed |
| 20:33:26 | nande | i have no idea whats babel. |
| 20:33:43 | reactormonk | nande, the nimrod lib package management |
| 20:34:07 | reactormonk | git clone https://github.com/nimrod-code/babel.git |
| 20:34:09 | reactormonk | nimrod c -r src/babel install |
| 20:34:10 | nande | cool . i've run koch boot, do i have it now? |
| 20:34:22 | nande | oh, you answered me . thanks |
| 20:36:00 | bbodi2 | good night guys |
| 20:36:04 | * | bbodi2 quit (Quit: Leaving) |
| 20:37:16 | Araq | skrylar: there is a difference between "built automatically and crashes" and "built automatically after tests passed" |
| 20:37:41 | NimBot | Araq/Nimrod devel 8029a5d Araq [+0 ±3 -0]: more things case consistent |
| 20:37:41 | NimBot | Araq/Nimrod devel 02662f5 Araq [+0 ±1 -0]: fixes #612 |
| 20:37:41 | NimBot | Araq/Nimrod devel 729d61a Araq [+0 ±1 -0]: edited compiler's config |
| 20:37:41 | NimBot | Araq/Nimrod devel 6d294ae Araq [+0 ±1 -0]: the tester now produces a diff in the JSON |
| 20:37:41 | NimBot | 1 more commits. |
| 20:38:11 | Araq | dom96: please add this "diff" output to nimbuild |
| 20:39:55 | nande | http://screencloud.net/v/cdRA i cant install nimrod... says it cant find it.. |
| 20:41:08 | nande | http://screencloud.net/v/yzKB and if i want to run pour command reactormonk it says it cant find nimrod too |
| 20:42:25 | Araq | nande: if nimrod is not in your path, how did you manage to compile "koch"? |
| 20:43:06 | nande | ./bin/nimrod c kach |
| 20:43:14 | nande | i hate to touch the path |
| 20:43:32 | Araq | *shrug* I hate Unix |
| 20:43:41 | nande | i like it :) |
| 20:43:47 | BitPuffin | Araq: what about windows? |
| 20:44:07 | nande | also it what it says on the wiki http://screencloud.net/v/mopU |
| 20:44:09 | fowl | nande, the easiest way to install it is symlink the nimrod binary into your PATH |
| 20:44:37 | fowl | into ~/bin or ~/local/bin |
| 20:44:49 | reactormonk | nande, just symlink it in there |
| 20:44:52 | nande | thanks fowl i also hate to install devel stuff on my machine. i tend to forget what ive installed |
| 20:45:11 | reactormonk | nande, then make a package out of it |
| 20:45:23 | nande | mm good but i dont know how |
| 20:45:27 | skrylar | nande: I have a /home/name/Local folder i put all of that in |
| 20:45:28 | reactormonk | nande, which system? |
| 20:45:35 | nande | ubuntu |
| 20:45:44 | skrylar | you can have a login shell put that in your path, install your dev ware to ~/local |
| 20:45:48 | skrylar | and use git to package manage it |
| 20:45:58 | skrylar | e.g. git add . && git commit -a -m "nimrod 0.9-blah" |
| 20:45:59 | BitPuffin | so dom96, will the API of asyncio module change or just the implementation? |
| 20:46:17 | skrylar | if you want to chuck dev-ware, you can use git-rebase to delete the commit |
| 20:46:18 | reactormonk | nande, http://packaging.ubuntu.com/html/ |
| 20:46:19 | skrylar | 'tis handy |
| 20:47:17 | nande | i know im earning some boots at my head but i dont really have that much time to package stuff. thanks for the link though |
| 20:48:29 | reactormonk | nande, just symlink to ~/bin |
| 20:48:35 | nande | im on that :) |
| 20:51:30 | nande | once i made the symlink i've no need to run "koch install" right? |
| 20:52:12 | Araq | right "koch install" is an abomination anyway |
| 20:52:24 | Araq | (any installation on unix is) |
| 20:54:20 | skrylar | lol |
| 20:54:22 | vbtt | Araq:why is installing in unix worse than, say, win or mac? |
| 20:54:40 | skrylar | vbtt: probably because the canonical way to install on unix is to shove things in a giant unmanageable folder |
| 20:55:14 | vbtt | rather.. one of many possible such folders. is that what you are referring to, Araq? |
| 20:55:21 | Araq | yup |
| 20:55:35 | Araq | also it requires root rights |
| 20:55:42 | skrylar | nix is okay with you using other folders, however GNU is stupid about it |
| 20:55:46 | Araq | it's just a bizzare clusterfuck |
| 20:55:51 | * | tdc quit (Quit: Leaving) |
| 20:56:00 | skrylar | for instance autotools are retarded about picking up libs in ~/local even with PATH and LIBRARY_PATH set |
| 20:56:47 | vbtt | the need for autotools demonstrates another failure of unix. |
| 20:57:11 | skrylar | eh? autotools served a purpose once |
| 20:57:48 | Araq | I still think this nails it: http://xkcd.com/1200/ |
| 20:57:49 | skrylar | its good at checking the size of int, if libs are installed, etc, all though the way its implemented is dumb |
| 20:58:04 | Araq | nothing makes any sense in unix land ... |
| 20:58:30 | nande | ok so much for my free time. must go back to work |
| 20:58:40 | Varriount | Hi guys |
| 20:58:42 | nande | thanks for the assistance and the hard work. |
| 20:58:53 | nande | if i can ill send a couple af btcs :) |
| 20:59:07 | skrylar | Araq: eh, that chart is funny but misses the point |
| 20:59:18 | nande | btw itll be awesome to have nimrod on the repository i could convince my friends to try it out |
| 20:59:29 | skrylar | it makes sense when you figure it was a mainframe OS; you didn't want someone else installing things on the mainframe |
| 20:59:55 | skrylar | you also don't want the mysql account getting compromised and deciding to replace bash for instance |
| 21:00:38 | vbtt | yeah the unix permission system is quite lacking for desktop use. but somewhat adequate for server use. |
| 21:00:49 | skrylar | it was never really meant for end users |
| 21:00:58 | skrylar | apple did a pretty decent job covering up the unix parts |
| 21:01:36 | vbtt | not really - underneath it's still one key to the kingdom. e.g. if a process can run as me it can access all my files and the entire internet at the same time. |
| 21:01:42 | nande | http://screencloud.net/v/tm9D btw i get this "could not load: libgtksourceview-2.0.so(|.0)" ? |
| 21:01:45 | vbtt | that's the flaw. |
| 21:02:21 | skrylar | vbtt: the 'average user' is somewhat of an idiot; they would be more confused by sandboxing files than helped by it |
| 21:02:58 | vbtt | skrylar:sandboxing is a hacky workaround for a broken system underneath anyway. of course it'll be confusing. |
| 21:03:05 | fowl | nande, thats a missing library |
| 21:03:17 | fowl | nande, gtksourceview |
| 21:03:19 | nande | yeah but which and how should i install it |
| 21:03:23 | nande | with babel? |
| 21:03:28 | skrylar | vbtt: by sandboxing i meant you *can* have multiple keys for your files, as far as a password for one folder or another |
| 21:03:35 | skrylar | it's just most people don't really seem to want it |
| 21:03:37 | fowl | nande, no, through your system package manager |
| 21:03:42 | Varriount | It's a pity that GoboLinux is dormant :/ |
| 21:03:44 | skrylar | i mean loads of people still use one password for those different cloud sites |
| 21:03:53 | fowl | Varriount, lucas is working on 015 |
| 21:03:55 | vbtt | skrylar:consider this - the syscalls are list-directory and open-file - which means by design the process should have permission to do both in order to do anything useful. it's designed for batch usage. |
| 21:04:12 | Varriount | fowl: 015? |
| 21:04:17 | nande | fowl: http://screencloud.net/v/hLaf one of those right? |
| 21:04:28 | fowl | Varriount, the gobolinux version that comes after 014 |
| 21:04:34 | nande | though they depend on mono. i sensed that was wrong |
| 21:04:53 | fowl | nande, yea |
| 21:04:55 | vbtt | skrylar:rather the syscall could be 'find-file' which makes the os display the file selector to the user and gives access to the just that file. |
| 21:04:56 | nande | no sorry those where the -cil |
| 21:04:58 | fowl | nande, the -dev one probably |
| 21:05:12 | nande | the -dev too? thanks |
| 21:05:28 | nande | nopes the -dev wasnt needed :) |
| 21:05:36 | vbtt | anyway dont want to create too much off topic noise.. |
| 21:05:36 | nande | main screen turn on. ship it |
| 21:05:55 | vbtt | Araq:where is the website hosted and who runs nimweb on a regular basis? |
| 21:05:59 | skrylar | vbtt: i'm not saying anything about someone couldn't redesign it, i'm just saying it doesn't seem like there is a combination of people wanting it hard enough + someone with a design better enough to be worth gutting the relevant code |
| 21:06:05 | BitPuffin | hmm |
| 21:06:10 | BitPuffin | what was it we had again |
| 21:06:12 | BitPuffin | assert and like |
| 21:06:15 | BitPuffin | was it doAssert? |
| 21:06:19 | fowl | yea |
| 21:06:19 | skrylar | desktop and server permissions are very different for instance, since most desktop users don't want to be asked for passwords to do anything |
| 21:06:26 | nande | that was some trip. c ya ppl |
| 21:06:29 | * | bezeredi quit (Quit: Konversation terminated!) |
| 21:06:51 | BitPuffin | coolio |
| 21:13:21 | * | Demos joined #nimrod |
| 21:13:21 | * | [2]Endy quit (Ping timeout: 260 seconds) |
| 21:13:26 | * | bbodi quit (Ping timeout: 264 seconds) |
| 21:16:33 | skrylar | vbtt: sorry, didn't mean to sound combative |
| 21:18:02 | dom96 | BitPuffin: It will change. |
| 21:18:09 | BitPuffin | dom96: daw |
| 21:18:11 | BitPuffin | oh well |
| 21:18:15 | BitPuffin | I guess I will have to adapt |
| 21:18:51 | vbtt | skrylar: didn't sound that way. |
| 21:19:20 | BitPuffin | dom96: what's the difference between connect and bindaddr? |
| 21:19:27 | vbtt | i just decided to do other stuff atm and vent when i have more free time. |
| 21:19:37 | dom96 | BitPuffin: Connect is for clients, bindaddr is for servers |
| 21:19:53 | BitPuffin | dom96: gotcha |
| 21:19:54 | dom96 | Araq: Tomorrow. |
| 21:20:07 | BitPuffin | dom96: what do I put as address? |
| 21:20:09 | Varriount | dom96: A better term would probably be "listen" |
| 21:20:21 | skrylar | isn't it called 'listen' by berkeley sockets |
| 21:20:31 | skrylar | wait |
| 21:20:34 | skrylar | i think listen is used for something else |
| 21:20:40 | BitPuffin | listen is another proc I think |
| 21:20:43 | fowl | listen for tcp |
| 21:20:51 | skrylar | i think was confusing listen and accept for a second |
| 21:21:02 | dom96 | You need to call both bindAddr and listen. |
| 21:21:12 | BitPuffin | Marks socket as accepting connections. Backlog specifies the maximum length of the queue of pending connections. |
| 21:21:14 | fowl | sockets are a PITA |
| 21:21:20 | dom96 | BitPuffin: There is a default value, just use that. |
| 21:21:31 | dom96 | BitPuffin: Unless you don't want to allow remote access. |
| 21:21:32 | BitPuffin | dom96: do NOT TELL ME WHAT TO DO |
| 21:21:33 | bstrie | OrionPK: I don't even know what a nimrod.cfg is, just make a pull request to the repo :P |
| 21:23:16 | OrionPK | bstrie its in the gist |
| 21:23:17 | OrionPK | and nah |
| 21:23:40 | Araq | dom96: please do it now |
| 21:24:00 | BitPuffin | dom96: hmm, how do I try several ports |
| 21:24:06 | BitPuffin | I'm thinking looping through a range |
| 21:24:10 | BitPuffin | just in case one is already taken |
| 21:24:27 | dom96 | BitPuffin: Use a try catch I guess. |
| 21:24:30 | BitPuffin | but how do I determine that it was successful |
| 21:24:32 | BitPuffin | yeah I know |
| 21:24:35 | fowl | BitPuffin, use enet, be happier |
| 21:24:52 | BitPuffin | that's what I was thinking |
| 21:25:17 | BitPuffin | but then how do I stop the loop if it was successful, and how do I make sure that the exception stays when it reaches the end of the loop |
| 21:25:21 | BitPuffin | if all of them are taken |
| 21:25:29 | BitPuffin | fowl: this is for a multiplayer game |
| 21:25:42 | skrylar | there is an easier way, BitPuffin |
| 21:25:45 | skrylar | is this for network handles? |
| 21:25:47 | fowl | BitPuffin, that you're writing? |
| 21:25:48 | BitPuffin | zmq? |
| 21:25:52 | BitPuffin | fowl: yes |
| 21:25:56 | fowl | BitPuffin, use enet |
| 21:25:57 | BitPuffin | fowl: no that YOU are writing |
| 21:26:20 | dom96 | Maybe there is a way to query is a port is taken. |
| 21:26:30 | * | zahary quit (Quit: Leaving.) |
| 21:26:32 | skrylar | IIRC you just bind it |
| 21:26:34 | dom96 | *if |
| 21:26:35 | skrylar | it will fail if its not available |
| 21:26:40 | fowl | BitPuffin, ..opposed to say, you connecting to a server or something |
| 21:28:29 | BitPuffin | skrylar: yeah it raises an exception, but that makes it difficult to keep the exception at the end of the loop |
| 21:28:31 | BitPuffin | or actually not |
| 21:28:41 | BitPuffin | I guess I can just check if port is the highest port and re-raise |
| 21:28:46 | BitPuffin | fowl: what's enet |
| 21:28:49 | BitPuffin | and why would I use it |
| 21:29:22 | * | micklat quit (Remote host closed the connection) |
| 21:29:23 | BitPuffin | I am not even sure that this game is possible on the network so I am not sure that using abstractions is a smart thing |
| 21:29:40 | BitPuffin | considering I am writing a physics engine for it even because there is no existing one that provide me what I need |
| 21:30:03 | fowl | its what you use when you get to the point of needing things like reliable and unreliable packets, and you dont feel like writing all that because its already written |
| 21:30:08 | skrylar | BitPuffin: what is it you need? |
| 21:30:20 | fowl | BitPuffin, http://enet.bespin.org/ |
| 21:30:48 | skrylar | enet is a socket lib for games; it gives you message-based TCP over UDP |
| 21:30:48 | BitPuffin | skrylar: dynamic fracture and deformation etc |
| 21:31:25 | fowl | BitPuffin, id love to see your work btw (: |
| 21:31:57 | EXetoC | can't fit the tubes? |
| 21:32:03 | Trixar_za | I've heard of enet before, but not sure where... |
| 21:32:17 | BitPuffin | fowl: well which people do you think I will probably recruit for super pre-notevenalpha testing? :P |
| 21:32:43 | BitPuffin | patience biatch |
| 21:32:47 | fowl | lol |
| 21:32:48 | BitPuffin | your day will come |
| 21:33:12 | BitPuffin | not so sure about this enet thing |
| 21:33:14 | BitPuffin | sounds great |
| 21:33:17 | BitPuffin | but maybe not for this |
| 21:33:18 | fowl | Trixar_za, its used in some really popular engine -- cube maybe? |
| 21:33:43 | Trixar_za | Could be. I remember it being used for an MMO I played or something |
| 21:33:50 | BitPuffin | I can imagine being able to shave off a few nanoseconds could be valuable for this game |
| 21:34:05 | Trixar_za | It was one of the depedencies of the client |
| 21:34:35 | skrylar | fowl: it was written specifically for Cube |
| 21:34:56 | skrylar | BitPuffin: i donno, are you doing something novel with the networking? |
| 21:35:14 | fowl | ah tahts right |
| 21:35:26 | skrylar | i get if you just want to learn sockets, all though enet does a decent number of things for you (e.g. multiple channels, which can be set to ignore previous messages if a newer one beat it to the client) |
| 21:35:58 | skrylar | if you use a zero-copy deserializer, the overhead is negligible |
| 21:36:00 | vbtt | is enet popular or just used by one game? |
| 21:36:09 | BitPuffin | skrylar: physics |
| 21:36:09 | skrylar | well its used by cube and sauerbraten at least |
| 21:36:17 | Demos | cube has pretty badass network code, pretty light on server-side verification though |
| 21:36:18 | skrylar | BitPuffin: physics is not novel networking |
| 21:36:27 | BitPuffin | skrylar: what do you mean with novel |
| 21:36:29 | Demos | but it works on a satelite connection |
| 21:36:30 | BitPuffin | I'm not writing a novel |
| 21:36:34 | skrylar | novel = new |
| 21:36:41 | fowl | i used enet in keineschweine |
| 21:36:42 | skrylar | most people *don't* do a full sync of physics |
| 21:36:53 | BitPuffin | skrylar: this kind of physics in a multiplayer environment is surely something new |
| 21:36:55 | skrylar | they simply transmit the scene graph's movements, and let the physics engines run on the client |
| 21:36:57 | fowl | thought thats not really a good demonstration of it, i didnt finish it |
| 21:37:02 | fowl | you can log in and download files though :p |
| 21:37:08 | vbtt | is enet not suitable for reliable messaging? |
| 21:37:20 | skrylar | vbtt: *shrug* |
| 21:37:24 | skrylar | it provides it, if you ask |
| 21:37:49 | skrylar | I'm guessing BitPuffin is paranoid of enet's overhead for packing messages |
| 21:38:05 | fowl | there doesnt have to be overhead |
| 21:38:16 | skrylar | all though, as mentioned, the usual response to physics is to have it simulated deterministically by each client (or nondeterministic, unless its important) |
| 21:38:30 | skrylar | for instance Clockwork Empires only transmits actions, the engine is fully deterministic |
| 21:38:59 | BitPuffin | skrylar: yeah it will most likely be a hybrit |
| 21:39:02 | BitPuffin | hybrid |
| 21:39:11 | BitPuffin | some things running on clients and some on the server |
| 21:39:23 | skrylar | but anyway; if you want to rewrite whats been done you're welcome to :) |
| 21:39:28 | BitPuffin | :P |
| 21:39:38 | BitPuffin | good for learning too |
| 21:41:59 | BitPuffin | I am guessing it will be interpolation of what the client thinks it will be and what the server says it is with timestep or something |
| 21:42:02 | BitPuffin | we'll see |
| 21:43:49 | BitPuffin | err, what's the prettiest way to re-raise? |
| 21:44:09 | EXetoC | 'raise'? |
| 21:44:29 | BitPuffin | EXetoC: yeah but like with the same info or something |
| 21:44:30 | EXetoC | I don't know if that's pretty, but it's short |
| 21:44:38 | * | tinAndi joined #nimrod |
| 21:44:46 | fowl | getcurrentexceptionmsg |
| 21:44:48 | fowl | () |
| 21:45:02 | Araq | hi tinAndi welcome |
| 21:45:06 | BitPuffin | so in the case of sockets |
| 21:45:10 | tinAndi | hi |
| 21:45:16 | BitPuffin | raise newEOS(getCurrentExceptionMsg())? |
| 21:45:37 | fowl | did you forget how to raise |
| 21:45:41 | fowl | raise newexception(t, msg) |
| 21:45:51 | BitPuffin | well the manual said that |
| 21:45:52 | fowl | er..i think thats it |
| 21:45:59 | fowl | ok i'll be honest i forgot how to raise |
| 21:46:02 | BitPuffin | http://build.nimrod-lang.org/docs/manual.html#raise-statement_toc |
| 21:46:11 | BitPuffin | however I usually do it the way you said too |
| 21:46:14 | BitPuffin | so I'm confused |
| 21:46:15 | EXetoC | why doesn't the proc also raise? I suppose it doesn't hurt to make it stand out |
| 21:46:18 | * | BitPuffin looks at araq |
| 21:46:57 | EXetoC | that's just a proc. it's outdated I guess |
| 21:46:58 | fowl | BitPuffin, neweos() is just a shortcut for newexception(E_OS, msg) |
| 21:47:04 | EXetoC | both are |
| 21:47:29 | EXetoC | nvm |
| 21:47:47 | BitPuffin | fowl: I see |
| 21:47:55 | BitPuffin | because let's introduce inconsistency |
| 21:48:04 | BitPuffin | either way, does this seem reasonable? https://gist.github.com/BitPuffin/8984557 |
| 21:48:14 | EXetoC | there's an unexported newEOS in streams |
| 21:48:30 | BitPuffin | without the raise |
| 21:48:35 | BitPuffin | like, only newEOS |
| 21:48:41 | BitPuffin | or not |
| 21:48:43 | BitPuffin | wtf |
| 21:48:47 | EXetoC | is that different from raise without an arg? |
| 21:49:22 | BitPuffin | doesn't even exist anymore |
| 21:49:28 | BitPuffin | so I guess manual needs to be updated |
| 21:50:59 | BitPuffin | hmm well it seems like it works when it fails |
| 21:51:04 | BitPuffin | not sure why I can't bind the port |
| 21:51:30 | EXetoC | could you before? have you enabled re-use? |
| 21:52:15 | BitPuffin | maybe I am missing a step |
| 21:52:20 | BitPuffin | EXetoC: no I'm just writing this |
| 21:52:22 | BitPuffin | https://gist.github.com/BitPuffin/8984557 |
| 21:52:28 | BitPuffin | that includes the full setup |
| 21:53:30 | fowl | BitPuffin, it looks alright except after bindaddr() you should break or return so it doesnt keep trying ports |
| 21:54:06 | BitPuffin | good idea lol |
| 21:54:11 | BitPuffin | that's why it wasn't working :P |
| 21:54:19 | BitPuffin | I wasn't sure how to check if it was successfully bound |
| 21:54:21 | BitPuffin | hrm |
| 21:54:34 | Varriount | Hm. How do I generate the nimrod documentation, including the PDF form? |
| 21:54:46 | fowl | well leave it running and try to use the same port twice to make sure EOS gets thrown on the second one |
| 21:55:26 | BitPuffin | fowl: yeah but like how do I check that the exception wasn't thrown without catching it |
| 21:55:28 | BitPuffin | guess it doesn't matter |
| 21:55:30 | BitPuffin | since it will say |
| 21:55:37 | BitPuffin | and crash |
| 21:55:40 | BitPuffin | which is what I want |
| 21:55:57 | fowl | the exception wasnt thrown if you get past bindAddr |
| 21:56:05 | BitPuffin | exactly |
| 21:56:09 | BitPuffin | and if it isn't caught |
| 21:56:11 | BitPuffin | boom |
| 21:56:20 | BitPuffin | although doesn't execution continue as far as possible? |
| 21:56:26 | fowl | thats why im saying test it |
| 21:56:36 | * | surma joined #nimrod |
| 21:56:44 | * | surma quit (Changing host) |
| 21:56:44 | * | surma joined #nimrod |
| 21:56:46 | fowl | or look at the source of sockets to make sure that is the behavior, because the documentation isnt clear |
| 21:57:35 | surma | Could someone take a look at these 12 lines and tell me why I get a SIGSEGV? https://gist.github.com/surma/8984641 |
| 21:58:39 | fowl | surma, you dont use channels properly |
| 21:59:27 | surma | figured as much as I never got them to work |
| 21:59:58 | fowl | surma, you have to call open() to initialize it http://build.nimrod-lang.org/docs/channels.html |
| 22:00:06 | BitPuffin | seems right |
| 22:00:17 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 22:01:08 | surma | *sigh*... I have had this page open all along but that function somehow slipped through |
| 22:01:09 | surma | of well, thanks |
| 22:01:46 | fowl | the doc could use a good example to display |
| 22:02:14 | surma | fowl: It's still failing tho |
| 22:03:12 | Varriount | surma: Try creating an explicit main() procedures |
| 22:03:42 | Varriount | For some reason, certain procedures (like newWideCString) don't like being called at the top level |
| 22:04:01 | BitPuffin | was there a way to refer to the parent scope variable of the same name? |
| 22:04:13 | BitPuffin | For example if I have a port variable next to the socket variable |
| 22:04:19 | BitPuffin | and then also call the loop variable port |
| 22:04:35 | BitPuffin | how would I assign the loop variable to the regular variable without changing name |
| 22:04:42 | fowl | surma, see |
| 22:04:48 | fowl | surma, tests/threads/threadex.nim |
| 22:04:50 | Varriount | BitPuffin: Can I see the code? |
| 22:05:24 | BitPuffin | https://gist.github.com/BitPuffin/8984557 |
| 22:06:19 | fowl | BitPuffin, unshadowing? the only answer is to not shadow |
| 22:06:24 | BitPuffin | oh |
| 22:06:26 | BitPuffin | so there is no way |
| 22:06:28 | BitPuffin | okay |
| 22:06:28 | Varriount | BitPuffin: Afaik, no, there's no way to access a shadowed variable |
| 22:06:33 | fowl | BitPuffin, well no |
| 22:06:43 | fowl | BitPuffin, if its top-level you could refer it it as mymodule.port |
| 22:07:24 | Varriount | Quite frankly, if you're shadowing variables, and need access to the shadowed values, your should just rename things. |
| 22:07:39 | BitPuffin | even if it is in the same module? |
| 22:08:12 | Varriount | Yes. |
| 22:08:33 | Varriount | Oh, for what fowl said, yes too |
| 22:09:03 | BitPuffin | lol :) |
| 22:09:23 | BitPuffin | must have confused it with some other language |
| 22:09:35 | BitPuffin | was it in D that you could do .variable = variable ? |
| 22:09:38 | Varriount | Python |
| 22:09:40 | BitPuffin | for top level stuff |
| 22:09:41 | * | awestroke joined #nimrod |
| 22:11:06 | Varriount | BitPuffin: In python you have the 'global' and 'nonlocal' keywords |
| 22:14:27 | BitPuffin | that's funky, there is PDispatcher that is equal to TDispatcher but I can't find any definition of it even in the index |
| 22:14:45 | vbtt | global and nonlocal just disable shadowing |
| 22:15:01 | vbtt | there is still no clean way to access shadowed variables in python. |
| 22:15:08 | * | zahary___ is now known as zahary_ |
| 22:15:34 | vbtt | not sure why that's useful anyway |
| 22:18:47 | Araq | Varriount: newWideCString really shouldn't fail in a top level statement ... |
| 22:19:09 | Araq | can you reproduce this with a simple test program? |
| 22:19:17 | Varriount | Yep. |
| 22:19:27 | * | askatasuna quit (Ping timeout: 260 seconds) |
| 22:20:20 | BitPuffin | dom96: what's the intended way to use delegates and all the stuff |
| 22:20:37 | BitPuffin | delegate and dispatcher |
| 22:20:44 | BitPuffin | and it doesn't even tell me what dispatcher is |
| 22:21:28 | Araq | strange. I remember asyncio having extensive docs |
| 22:21:50 | BitPuffin | Araq: if there even is a definition of TDispatcher it is not caught by the docgen |
| 22:22:35 | Araq | yeah. Perhaps it's an opaque object? nah, that's crazy talk |
| 22:22:49 | fowl | BitPuffin, here you go, example async server/client https://gist.github.com/fowlmouth/753ce0b4adbd9accff57 |
| 22:23:02 | BitPuffin | nope |
| 22:23:08 | BitPuffin | it's in the source file |
| 22:23:11 | BitPuffin | but not caught by the doc |
| 22:23:19 | BitPuffin | not sure what you mean by opaque object |
| 22:23:34 | BitPuffin | fowl: ty :D |
| 22:23:54 | fowl | BitPuffin, thats a 2 year old gist, so yeah |
| 22:23:57 | Araq | PDispatcher* = ref TDispatcher |
| 22:23:59 | Araq | TDispatcher = object |
| 22:24:06 | Araq | noticed something? |
| 22:24:14 | Araq | yeah TDispatcher is not exported |
| 22:24:20 | Araq | what does this mean? |
| 22:24:27 | BitPuffin | Araq: yeah I did notice that mr smartypants |
| 22:24:28 | Araq | perhaps that it's not your business? |
| 22:24:36 | surma | May I request another look? The channel now opens, but peek() returns -1 (i.e. allegedly closed) https://gist.github.com/surma/8984641 |
| 22:24:40 | BitPuffin | then why the fuck is PDispatcher exported |
| 22:25:12 | Araq | BitPuffin: I'll answer further question after you turned on your brain |
| 22:26:15 | BitPuffin | Araq: it is quite late |
| 22:26:26 | BitPuffin | at least for not even having left the office yet lol |
| 22:26:54 | Araq | surma: logger runs before you sent the message |
| 22:26:57 | BitPuffin | but yeah it just seemed like if I can call newDelegate() I should be able to use it for something |
| 22:27:47 | surma | Araq: Yeah, but I open the channel before. So peek should not return -1, right? |
| 22:28:04 | surma | "Returns -1 if the channel has been closed." |
| 22:28:17 | surma | That seemed liek the only way to check if a channel is open |
| 22:28:18 | Varriount | Araq: Posted the issue |
| 22:28:26 | BitPuffin | I am a bit dehydrated actually |
| 22:28:30 | BitPuffin | gonna grab some water |
| 22:28:35 | BitPuffin | maybe I will become more intelligent |
| 22:29:31 | EXetoC | BitPuffin: because that's not part of the interface |
| 22:30:00 | Araq | surma: ah my bad |
| 22:30:03 | BitPuffin | EXetoC: newDelegator is though |
| 22:30:18 | BitPuffin | but maybe you are only supposed to pass it around or something |
| 22:30:21 | Araq | so thread A closes the channel before 'logger' got a chance to run |
| 22:30:25 | EXetoC | yes, but you do have a set of procs that operate on said object |
| 22:30:26 | BitPuffin | either way, have no idea what it is for |
| 22:30:51 | surma | Araq: Oh.. I actually expected send() to block until someone recv() the msg. But now I see that's not actually in the documentation |
| 22:30:58 | * | cark joined #nimrod |
| 22:30:59 | surma | Again. Go making me make assumptoins |
| 22:31:01 | Araq | surma: 'close' gets rid of anything that's in the channel |
| 22:31:26 | fowl | BitPuffin, delegates? just ignore them.. |
| 22:31:38 | BitPuffin | fowl: what about dispatchers? |
| 22:31:50 | Araq | you generally don't close channels |
| 22:32:04 | Araq | instead you send a "stop" message to the thread to tell it to stop |
| 22:32:07 | fowl | BitPuffin, I quoth the docs for asyncio: "For most purposes you do not need to worry about the TDelegate type. The PAsyncSocket is what you are after. It's a reference to the TAsyncSocket object. This object defines events which you should overwrite by your own procedures." |
| 22:32:25 | Araq | and then you joinThread() it |
| 22:32:29 | BitPuffin | ah |
| 22:32:30 | surma | Araq: ah, just wanted to ask what the common idiom is. Thank you :) |
| 22:33:14 | fowl | BitPuffin, as for dispatchers, there are only like 2 functions that have anything to do with them |
| 22:33:40 | BitPuffin | handle read and write? |
| 22:34:02 | BitPuffin | by the way Araq if you are gonna be so snarky about things not being exported, why is fields for objects that aren't exported shown, eh? |
| 22:35:30 | EXetoC | shown where? |
| 22:35:33 | Araq | BitPuffin: it's because I release useful software before it is "perfect" |
| 22:35:38 | fowl | BitPuffin, you can see in my example all the dispatcher is used for is register() and poll() |
| 22:36:09 | BitPuffin | fowl: currently reading it |
| 22:36:31 | reactormonk | Araq, How to deal with data types that are value-typed but use heap-based datastructures internally like tset? |
| 22:36:53 | EXetoC | BitPuffin: you're not referring to TDispatcher right? |
| 22:37:14 | Araq | reactormonk: haven't made up my mind yet |
| 22:37:21 | BitPuffin | EXetoC: no |
| 22:37:31 | BitPuffin | EXetoC: the fields of TDelegate and TAsyncSocket |
| 22:37:32 | fowl | EXetoC, he means the fields on TAsyncSocket that arent exported |
| 22:37:45 | reactormonk | Araq, ok. |
| 22:38:05 | EXetoC | not quite what he said, but ok |
| 22:38:08 | fowl | BitPuffin, tdelegate is exported, the * isnt shown |
| 22:38:40 | BitPuffin | fowl: I know |
| 22:38:45 | BitPuffin | fowl: I said fields |
| 22:39:13 | fowl | BitPuffin, all the fields of tdelegate are exported though |
| 22:39:49 | fowl | so.. what u talking about |
| 22:39:53 | BitPuffin | fowl: exactly that |
| 22:39:59 | BitPuffin | fowl: why doesn't it omit the non-exported ones |
| 22:40:07 | surma | I MADE THREADS WORK! Wow... can't believe it feels just as good even tho it is this primitive |
| 22:40:10 | EXetoC | I think Araq told you |
| 22:40:11 | BitPuffin | but Araq already said why |
| 22:40:16 | BitPuffin | yeah I know |
| 22:40:27 | BitPuffin | but fowl kept explaining it or what he thought I was asking |
| 22:40:35 | fowl | ok |
| 22:40:40 | fowl | what a boring convo |
| 22:41:09 | BitPuffin | lol yeah |
| 22:41:09 | fowl | :p |
| 22:41:15 | BitPuffin | went on much longer than needed :P |
| 22:41:17 | fowl | just use enet dude, its a lot easier |
| 22:41:40 | fowl | the same client/server example in enet https://github.com/fowlmouth/nimrod-enet/tree/master/examples |
| 22:43:22 | BitPuffin | I don't want abstraction for this |
| 22:43:34 | BitPuffin | It might be useful in the future though for some other project |
| 22:44:25 | vbtt | BitPuffin: are you using tcp? |
| 22:44:39 | vbtt | enet is udp based |
| 22:45:56 | vbtt | designed for lower latency (tcp has more 'handshake' and stream protocol so latency will be an issue) |
| 22:46:41 | Araq | if starcraft 2 runs over TCP, your stuff should be fine too |
| 22:46:57 | Araq | and iirc it does use TCP |
| 22:46:59 | BitPuffin | vbtt: no I'm not using tcp |
| 22:47:01 | BitPuffin | that would not be smart |
| 22:47:04 | vbtt | ok |
| 22:47:13 | vbtt | so what are you using? |
| 22:47:16 | BitPuffin | Araq: this is not an RTS game |
| 22:47:18 | BitPuffin | vbtt: UDP |
| 22:47:37 | BitPuffin | Araq: starcraft doesn't do networked physics with realtime deformation and fracture |
| 22:48:00 | Varriount | O_o |
| 22:48:01 | surma | Can the nimrod compiler link statically? |
| 22:48:09 | Araq | fair enough, BitPuffin |
| 22:48:18 | vbtt | BitPuffin: i guess it's ok then, as long as you're ok with the non-reliability |
| 22:48:19 | Varriount | surma: iirc, It links statically by default |
| 22:48:24 | Araq | surma: it does link statically |
| 22:48:32 | BitPuffin | vbtt: I am quite ok with it |
| 22:48:32 | Demos | surma, sure. Pure nimrod libs should be linked "staticly" by default, you can use --overrideDynlib to link with C libraries |
| 22:48:39 | surma | but not with threads, right? |
| 22:48:45 | Discoloda | BitPuffin: im curious, what can deform and fracture? |
| 22:48:46 | BitPuffin | and if it becomes a problem I'll deal with it |
| 22:48:55 | BitPuffin | Discoloda: meshes and terrain? |
| 22:48:59 | Varriount | surma: What do you mean, not with threads? |
| 22:49:09 | Demos | surma, it will likely be somewhat hard to get gcc to link pthreads and glibc staticly, you can try --passl:-static |
| 22:49:16 | fowl | BitPuffin, too many dimensions lol |
| 22:49:17 | Discoloda | so, like buildings or even down to things as small as a pole |
| 22:49:40 | BitPuffin | Discoloda: both |
| 22:49:45 | Araq | surma: threads don't change anything. Yes we kick Go's ass when it comes to .exe size. :P |
| 22:49:51 | BitPuffin | no pre-made destruction meshes like in battleshit :P |
| 22:49:58 | Discoloda | cool |
| 22:50:22 | BitPuffin | Discoloda: so it is used as a tactical element of gameplay basically |
| 22:50:27 | Varriount | Araq: Nimrod does many things better than Go |
| 22:50:33 | fowl | BitPuffin, this is an FPS? |
| 22:50:37 | BitPuffin | fowl: yes |
| 22:50:51 | Varriount | I think the only big thing Go has on Nimrod is Goroutines |
| 22:50:56 | fowl | BitPuffin, i always wanted an FPS version of yoshi's island |
| 22:51:00 | surma | Demos: That worked, thanks |
| 22:51:06 | BitPuffin | fowl: this will not be it |
| 22:51:11 | fowl | BitPuffin, throwing eggs at shyguys in first person perspective |
| 22:51:22 | surma | Araq: Actually, when I link statically it's basically the same size |
| 22:51:27 | Varriount | Araq: Is the nimrod compiler able to calculate the stack size of a particular procedure? |
| 22:51:31 | surma | But yeah, Go has gotten a lot bigger |
| 22:51:32 | BitPuffin | fowl: so do you have to use a dispatcher for handling reading and writing? |
| 22:51:33 | fowl | BitPuffin, yea yea just make it very data-driven and it may become first-person-yoshi :p |
| 22:51:36 | BitPuffin | or is that just one way |
| 22:51:38 | Discoloda | i just want what Dust514 was promised to be on the PC (PS3 is slow these days) |
| 22:51:43 | surma | It's one of the goals for Go 1.3 to reduce size again |
| 22:51:49 | Araq | surma: I think you're doing it wrong |
| 22:51:50 | Varriount | 'again' |
| 22:51:55 | BitPuffin | fowl: I plan to ship it with level editor etc so that modding community can go nutz |
| 22:52:01 | Araq | and Go doesn't link statically to *libc* either |
| 22:52:20 | Araq | so you compare "fully static" vs "somewhat static" |
| 22:52:42 | surma | wait, what are you talking about? I wasnt trying to offend anyone ^^ |
| 22:52:54 | BitPuffin | araq is always offended, didn't you know :P |
| 22:53:03 | Varriount | ^ Tis true |
| 22:53:04 | surma | Nah, I'm kinda new ;) |
| 22:53:36 | skrylar | Araq is always offended and Skrylar always hates things |
| 22:53:38 | skrylar | lol |
| 22:53:38 | fowl | BitPuffin, the pasyncsocket object has a bunch of callbacks, i only use handleRead or handleConnect |
| 22:54:06 | fowl | BitPuffin, sending data is easy, asyncsocket.send("bond\0\0\7") |
| 22:54:09 | Discoloda | BitPuffin: for the game im working on, im trying to get it to have a world up to 8388608 meters on each side. |
| 22:54:27 | * | awestroke quit (Remote host closed the connection) |
| 22:54:34 | BitPuffin | fowl: yeah that's what I thought |
| 22:55:02 | BitPuffin | fowl: so handleConnect is when a new client connects?, And handleRead is when one of the clients send data to you |
| 22:55:04 | BitPuffin | ? |
| 22:56:20 | fowl | yea |
| 22:56:34 | fowl | i think |
| 22:56:47 | fowl | there's another example in tests/run/tasyncudp |
| 22:57:32 | Araq | surma: afaict you need "go build -ldflags "-linkmode external -extldflags -static" " to link statically |
| 22:57:56 | * | io2 joined #nimrod |
| 22:59:50 | surma | Araq: Nah, just CGO_ENABLED=0 |
| 23:00:35 | Araq | but *shrug* who links statically against libc anyway. makes no sense |
| 23:00:47 | Demos | Araq, does on windows |
| 23:01:17 | Araq | Demos: ok but then you don't link statically against kernel32.dll |
| 23:01:18 | * | DAddYE_ joined #nimrod |
| 23:01:40 | Araq | that's not even possible, is it? |
| 23:02:29 | Demos | yeah, don't think it is |
| 23:02:40 | surma | Araq: Most of the time, go is not linking against anything, everything is in the core lib. OS X is one of the exceptions because external libraries are needed to access the systems TLS certificates for example |
| 23:02:49 | Demos | are POSIX and linux syscalls in a shared lib on nix? |
| 23:03:09 | surma | Under linux it is now linking against libc for faster DNS lookup. But if you set CGO_ENABLED=0, it doesnt link against anything external |
| 23:03:52 | Varriount | dom96: The GSoC page looks pretty |
| 23:04:26 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 23:05:39 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 23:08:02 | vbtt | can someone update the website news before submitting gsoc? |
| 23:08:23 | vbtt | you can post the strangeloop video and dr dobbs article |
| 23:08:41 | Varriount | vbtt: I think dom96 and Araq are the only ones who can modify the website |
| 23:08:58 | Varriount | filwit and zahary might be able to as well. |
| 23:10:33 | reactormonk | Varriount, just post it to news.txt |
| 23:10:58 | Varriount | Oh. That simple? |
| 23:11:23 | vbtt | web/news.txt - i looked at it but found a new news item not on the website, about releasing 0.9.4 |
| 23:11:24 | Araq | surma: your comparsion is still unfair, nimrod links its own stdlib statically, golang does the same. You then make nimrod link statically against something out of our control and end up with comparable sizes. They are not. |
| 23:11:30 | vbtt | perhaps i looked at the devel branch. |
| 23:12:11 | * | surma quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 23:12:13 | reactormonk | vbtt, hm |
| 23:12:49 | vbtt | so i dont know which branch of the website to edit .. |
| 23:13:16 | Varriount | Probably master |
| 23:13:22 | Araq | no, devel |
| 23:13:27 | vbtt | but then how do the new changes make it to devel? |
| 23:13:59 | vbtt | yeah the devel already has a news item about 9.4: https://github.com/Araq/Nimrod/blob/devel/web/news.txt |
| 23:14:33 | Araq | vbtt: make a PR with the news.txt and I can upload it |
| 23:14:34 | Varriount | vbtt: Don't forget that the ticker.txt contains the sidebar news |
| 23:15:03 | vbtt | Araq: but what do I do with the future news item? delete it? |
| 23:15:12 | Araq | comment it out |
| 23:15:15 | Araq | with |
| 23:15:17 | Araq | .. |
| 23:15:22 | Araq | comment |
| 23:15:31 | vbtt | oh we have comments.. ok. |
| 23:15:36 | Araq | RST surely is strange sometimes |
| 23:16:05 | vbtt | yeah RST is weird |
| 23:16:15 | Discoloda | ping |
| 23:16:19 | vbtt | asciidoc is better |
| 23:17:03 | NimBot | Araq/Nimrod devel 3a8f782 Araq [+0 ±1 -0]: koch install should work now as documented |
| 23:17:04 | vbtt | btw i wasn't able to run nimweb either, so i can't verify my change |
| 23:17:26 | Araq | why not? |
| 23:19:26 | vbtt | can't remember and dont have access - something about an expected file missing. i just ran it on the cloned web directory and it didn't work. |
| 23:20:07 | Araq | well I have the same problem, I think |
| 23:20:26 | * | xenagi joined #nimrod |
| 23:21:14 | vbtt | good! |
| 23:21:25 | * | skrylar still hugs nanoc as a site generator *nods* |
| 23:22:06 | vbtt | btw, was nimweb really necessary? off the shelf solutions didn't work? |
| 23:23:28 | Araq | how could they? do they support highlighting for nimrod source code? |
| 23:23:58 | skrylar | Araq: plug in a highlighter to coderays/pygments? |
| 23:24:04 | vbtt | of course, pygments does |
| 23:24:21 | Araq | pygments didn't have a nimrod highlighter back then |
| 23:25:02 | skrylar | I know you can have asciidoctor (ruby version) call out to a number of highlighters (highlightjs, coderay, pygmentize at least), then have nanoc process docs with asciidoctor (which has close-to-reST syntax as it is) |
| 23:25:16 | skrylar | thats what i use when markdown isn't good enough |
| 23:25:24 | Araq | *shrug* I know my solution works much better anyway |
| 23:26:12 | Araq | my RST parser works better than docutils's too |
| 23:26:33 | skrylar | i think i've only used rest once |
| 23:26:49 | vbtt | that's nice, but nimweb doesn't work atm |
| 23:28:46 | Araq | that's because other people constantly add features |
| 23:29:00 | Araq | and then complain version 0.9.4 is not out already |
| 23:29:06 | Araq | and call me names |
| 23:30:52 | vbtt | while it's nice to eventually have nimweb working, right now i see it just sidetracking you (and me) |
| 23:32:08 | * | DAddYE_ quit (Remote host closed the connection) |
| 23:32:24 | vbtt | you can say no to any features |
| 23:32:40 | * | DAddYE joined #nimrod |
| 23:33:25 | vbtt | new features are fun and stabilizing is boring but is nimrod going to be a purely research/fun platform? |
| 23:34:24 | skrylar | how many more features are needed that macros can't do? |
| 23:35:13 | vbtt | needed or wanted? everybody wants something that doesn't exist yet. |
| 23:36:42 | vbtt | go released 1.0 with a non-generational GC, python 1.0 didn't even have classes afaik (other useful features came in > 2.3) |
| 23:37:09 | vbtt | but it appears that nimrod is going to leapfrog all versions and the first release will be v 5.0 |
| 23:37:54 | Araq | so what do you suggest? |
| 23:38:10 | * | darkf joined #nimrod |
| 23:38:12 | Araq | remove what's broken to get a stable 1.0 ? |
| 23:38:34 | Araq | should I go through the list of what is currently broken then? |
| 23:38:45 | vbtt | sure, that's fine too. i'd say pick a date - anything not even started by that date is out - anything broken is dealt with on a case-by-case and anything stable is in. |
| 23:39:22 | vbtt | the date is for feature freeze. |
| 23:40:03 | vbtt | you could have 1.0 in 6 months or less i think. |
| 23:40:24 | Araq | closures, iterators, generics, macros, exceptions |
| 23:40:28 | Araq | all broken |
| 23:40:40 | Araq | should we remove them then? |
| 23:41:03 | Araq | I'm in feature freeze mode since months already |
| 23:41:38 | vbtt | oh? i didn't realize. |
| 23:41:53 | vbtt | i still see talk of new features going into 1.0 |
| 23:42:18 | Araq | it's 0.9.4 vs 1.0 |
| 23:42:28 | Araq | 0.9.4 is in feature freeze, 1.0 is not |
| 23:43:23 | Araq | and of course things don't work that way. for instance dom96 can't fix most critical bugs, but he surely can work on asyncio in the meantime |
| 23:43:50 | Araq | having him do nothing instead doesn't help |
| 23:44:46 | vbtt | i understand everyone is a volunteer. |
| 23:45:43 | vbtt | but you control the branches - just fork 0.9.4 and only allow stabilization changes in it. then new features will not break 0.9.4 |
| 23:45:50 | vbtt | (0.9.4 should just be 1.0 anyway) |
| 23:47:00 | * | tinAndi quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 23:47:24 | Araq | that's what we're doing, except branches don't work well when you touched almost every single line of code |
| 23:47:44 | Araq | so 'devel' is the new 'stable', sort of |
| 23:49:46 | vbtt | but new features for 1.0 and fixes for 0.9.4 are going in the same branch at the same time - am I wrong? |
| 23:52:16 | vbtt | also the person writing the new feature should be responsible for merging it later. |
| 23:52:55 | vbtt | so you're focused on one thing only - 0.9.4 |
| 23:54:42 | vbtt | people want a stable platform to build on - and it seems even some core features (you listed above) are not stable yet. |
| 23:55:28 | vbtt | you were talking about the pointer tagging stuff - is that even in 0.9.4? |
| 23:55:37 | EXetoC | Araq: will explicitly doing a full GC collection remain necessary in order to guarantee that all unreferenced objects are finalized? |
| 23:56:21 | vbtt | can it not be added later? in 1.2 perhaps? |
| 23:56:40 | Araq | vbtt: pointer taggin is not implemented |
| 23:56:55 | Araq | not in a devel2 branch |
| 23:57:08 | Araq | planning goes ahead of implementation |
| 23:59:54 | skrylar | i kinda wish GTK+ was better at being portable |