00:09:35 | * | io2 quit () |
00:41:12 | * | xenagi joined #nimrod |
00:44:28 | * | Skrylar joined #nimrod |
00:56:36 | * | tumak_ quit (Ping timeout: 255 seconds) |
00:59:22 | * | tumak joined #nimrod |
01:03:20 | * | tumak quit (Remote host closed the connection) |
01:03:37 | * | tumak joined #nimrod |
01:05:41 | * | Demos quit (Ping timeout: 255 seconds) |
01:14:15 | * | DAddYE_ quit (Remote host closed the connection) |
01:32:24 | * | OrionPK quit (Remote host closed the connection) |
01:33:49 | * | OrionPK joined #nimrod |
01:41:32 | * | q66 quit (Quit: Leaving) |
02:12:26 | * | Demos joined #nimrod |
02:14:58 | * | DAddYE joined #nimrod |
02:18:41 | * | Demos_ joined #nimrod |
02:19:20 | * | Demos quit (Ping timeout: 265 seconds) |
02:19:33 | * | DAddYE quit (Ping timeout: 265 seconds) |
02:23:09 | * | nolan_d left #nimrod (#nimrod) |
02:53:03 | * | nolan_d joined #nimrod |
03:15:55 | * | DAddYE joined #nimrod |
03:20:27 | * | DAddYE quit (Ping timeout: 265 seconds) |
03:49:30 | * | xenagi quit (Read error: Connection reset by peer) |
04:11:05 | * | Demos_ quit (Ping timeout: 255 seconds) |
04:15:17 | * | brson quit (Ping timeout: 240 seconds) |
04:21:09 | NimBot | Varriount/NimLime master 12035b2 Varriount [+0 ±1 -0]: Fixed thread error caused by compiler path settings. |
04:54:02 | * | Demos joined #nimrod |
04:55:01 | * | Demos quit (Client Quit) |
04:55:10 | * | Demos joined #nimrod |
05:25:09 | * | Demos quit (Ping timeout: 265 seconds) |
05:27:54 | * | Skrylar quit (Ping timeout: 252 seconds) |
05:43:44 | * | nande quit (Read error: Connection reset by peer) |
05:45:44 | * | BitPuffin quit (Ping timeout: 265 seconds) |
06:23:39 | * | Guest73710 quit (Quit: WeeChat 0.4.3) |
06:37:59 | * | psquid joined #nimrod |
06:37:59 | * | psquid quit (Changing host) |
06:37:59 | * | psquid joined #nimrod |
07:15:27 | * | DAddYE joined #nimrod |
07:23:10 | * | DAddYE quit (Remote host closed the connection) |
07:23:36 | * | DAddYE joined #nimrod |
07:28:25 | * | DAddYE quit (Ping timeout: 265 seconds) |
08:02:31 | Araq | hi ruzu welcome |
08:24:12 | * | DAddYE joined #nimrod |
08:28:40 | * | DAddYE quit (Ping timeout: 252 seconds) |
08:34:15 | * | DAddYE joined #nimrod |
08:38:59 | * | DAddYE quit (Ping timeout: 265 seconds) |
08:56:46 | reactormonk | Araq, o/ |
08:56:59 | * | EXetoC joined #nimrod |
08:57:00 | reactormonk | sometimes I ask myself why I'm coding in scala :-( |
08:57:35 | reactormonk | their file reading lib is dead slow. slow as in reading char by char at some level. |
08:58:15 | reactormonk | I think getting the idetools to work would make me use nimrod a bit more :-) |
09:27:14 | Araq | reactormonk: so please do it |
11:29:41 | * | Skrylar joined #nimrod |
12:06:34 | * | easy_muffin joined #nimrod |
12:14:48 | Skrylar | meep. |
12:19:47 | * | oxful quit (Ping timeout: 252 seconds) |
12:20:28 | * | oxful joined #nimrod |
12:43:08 | * | [1]Endy joined #nimrod |
12:58:38 | * | nande joined #nimrod |
13:07:18 | * | easy_muffin quit () |
13:16:27 | * | BitPuffin joined #nimrod |
13:39:42 | * | psquid quit (Quit: out) |
13:50:46 | * | zahary_ quit (Ping timeout: 268 seconds) |
13:58:21 | BitPuffin | Araq: is there a way to take a ref, ptr, (or var I guess) in a proc and say I promise not to modify it? |
13:59:02 | BitPuffin | you know, const lol* foo in C |
14:04:01 | Skrylar | i don't think there is a 'const' modifier |
14:04:33 | BitPuffin | I feel like that's a useful thing to have |
14:06:03 | Skrylar | I ran in to an annoyance with that; I couldn't do a reinterpret_cast without upgrading a parameter to a var |
14:06:59 | * | Demos joined #nimrod |
14:07:30 | Skrylar | Demos: do you know of a pressing use-case for dynamic event binding? i know we were talking about it the other day, i just wanted to make sure i had the bases covered before committing to an implementation |
14:08:50 | Demos | I mean I can see most use cases bing fine with static binding, but at the same time I see little disadvantage to allowing dynamic binding (and I mean like dynamicly adding events, not some kind of janky dispatch scheme) |
14:09:22 | Demos | also wrt your question about taking stuff by "const var" the compiler will just do that for you as an optimization if you take by "value" |
14:09:38 | Skrylar | i think the problem is that you can't addr() a non-pointer value |
14:09:45 | Demos | true |
14:09:46 | Skrylar | which means you can't memcpy data out of it |
14:09:51 | Araq | BitPuffin: we will get write tracking instead |
14:10:15 | Araq | which is none of C++'s or D's const problems, in theory |
14:10:17 | Araq | *has |
14:10:43 | Demos | right now you can shadow the var or just deal with it and take by var |
14:10:47 | BitPuffin | Araq: hmm, well how would I say with the write tracking that variable a won't be modified but variable b will be |
14:11:09 | Araq | writes: b |
14:11:20 | Skrylar | Demos: mostly that handling becomes O(n) instead of O(1) |
14:11:21 | Araq | # a not mentioned, must not write a |
14:11:26 | BitPuffin | in a pragma? |
14:11:35 | Araq | yes |
14:11:36 | BitPuffin | oh so you have to be explicit to write? |
14:11:38 | Demos | Skrylar: you mean O(2n) instead of O(n) |
14:11:54 | Demos | Araq: what about doing it implicitly? bad idea? |
14:11:57 | Skrylar | sure, it has to go through a linear search instead of cases |
14:11:59 | Araq | BitPuffin: IF you have an explicit 'writes' annotation |
14:12:07 | Araq | otherwise it's computed for you |
14:12:12 | * | [2]Endy joined #nimrod |
14:12:12 | BitPuffin | Araq: hmm, I see |
14:12:17 | BitPuffin | I guess that's ok |
14:12:28 | Skrylar | Demos: one of the models i considered was to jump through a callback to an object's handler function, which then consulted the event map macro so it really was O(1) |
14:12:32 | Araq | Demos: it is done implicitly unless you annotate it yourself |
14:13:13 | Demos | Skrylar: talking about big-o complexity on event maps/handlers is really not a great plan |
14:13:14 | BitPuffin | Araq: also, if you don't take ref, var or ptr. And you only read from a variable, will it be passed by reference as an optimization? |
14:13:25 | Demos | we are talking about dozens to hundreds of events |
14:13:33 | Skrylar | I have a vague appreciation for doing a queue instead for one reason: you can defer deletion of scene graph items to a separate step, and make sure no deletions occur until *after* all pending events are handled |
14:13:35 | Skrylar | which is safer |
14:14:26 | Demos | BitPuffin: I would think if you take "by value" the compiler will not let you write at all |
14:14:30 | BitPuffin | Araq: I don't think as a systems language too much of that stuff should happen automatically. Because on some systems it will be faster to copy it to the cache etc |
14:14:43 | BitPuffin | Demos: not what I asked |
14:14:51 | BitPuffin | Demos: it would let me write to my local copy |
14:15:01 | Demos | what local copy |
14:15:05 | BitPuffin | but I was asking, if I don't write, does it skip the copy |
14:15:08 | Araq | BitPuffin: so you know better than the compiler when the tuple should be passed by copy on the stack? |
14:15:26 | Araq | because it is system dependent you know better? |
14:15:27 | BitPuffin | Araq: I don't, but some people do :P |
14:15:31 | Araq | makes no sense |
14:15:31 | * | [1]Endy quit (Ping timeout: 264 seconds) |
14:15:39 | Demos | nimrod's default argument passing convention is to just be immutable on an abstract sense and let the compiler deal with it |
14:15:41 | BitPuffin | Demos: hmm, actually yeah |
14:15:44 | Demos | because it really is a simple rule |
14:15:46 | BitPuffin | maybe we don't get a local copy |
14:15:52 | BitPuffin | that makes it ez then |
14:15:59 | BitPuffin | we have to make the copy ourselves |
14:16:03 | Demos | like if sizeof(T) > register_size then by ref else by val |
14:16:39 | Demos | I think you can say var parm = parm to shadow |
14:16:40 | Araq | BitPuffin: there is a .bycopy pragma to override it if you know better |
14:16:57 | Araq | Demos: that is even an *idiom* |
14:17:00 | BitPuffin | Araq: the compiler won't always know the best, since it's not the one profiling and benchmarking etc |
14:17:15 | Araq | BitPuffin: and yet you trust it to get register allocation right |
14:17:21 | * | [2]Endy quit (Ping timeout: 252 seconds) |
14:17:36 | BitPuffin | Araq: I didn't say it never gets it right |
14:17:38 | Demos | BitPuffin: it is the one optimizeing, and the way nimrod deals with args makes that eaiser |
14:17:41 | Demos | I think |
14:17:46 | BitPuffin | Demos: yep |
14:17:58 | BitPuffin | Demos: I forgot that we don't get a copy when we pass a variable |
14:18:20 | BitPuffin | Araq: I guess you do {.bycopy: a, b, d.} or something then? |
14:18:37 | Araq | no, you annotate the *type* instead |
14:18:48 | BitPuffin | oh |
14:19:02 | Demos | if you want to get a copy in a proc use the var p = p thing |
14:19:16 | BitPuffin | Araq: but what if you only want it to happen on one proc? Guess just create a local variable then |
14:19:40 | * | [1]Endy joined #nimrod |
14:20:03 | Araq | BitPuffin: "but what if" questions are relevant when they turn into "but in this case that actually happened" |
14:20:22 | BitPuffin | well |
14:20:25 | BitPuffin | not sure I agree |
14:20:29 | BitPuffin | it's good to be aware of stuff |
14:20:33 | BitPuffin | even if you won't have to use it :P |
14:21:17 | Demos | BitPuffin: I agree. And you should be aware that the way nimrod passes arguments makes functions decls shorter and makes it harder to fuck up your performence by taking that huge sequence by value |
14:21:28 | BitPuffin | I have a feeling a compiler would want to optimize away a let foo = a though |
14:21:48 | BitPuffin | Demos: yep :) I know, it's awesome |
14:21:58 | BitPuffin | a very sane default |
14:22:40 | BitPuffin | I'm pretty sure most languages don't do that. D passes by value by default iirc |
14:22:45 | Demos | I am actually not sure how I feel about var return types though |
14:22:47 | BitPuffin | just because it wants to be C |
14:23:02 | BitPuffin | var return types? |
14:23:09 | Araq | "but what if a progammer comes along and nests his if statements 40 levels deep? omg we need to ensure in the language spec this is not possible" |
14:23:17 | BitPuffin | proc foo*(in: foo, out: var bar) ? |
14:23:33 | Demos | like proc foo*(in: foo): var TBar |
14:23:42 | BitPuffin | Demos: hm |
14:23:46 | BitPuffin | the fuck does that even do |
14:24:03 | Demos | like a c++ function returning a reference |
14:24:10 | BitPuffin | Araq: lol, much relevant |
14:24:13 | * | easy_muffin joined #nimrod |
14:24:33 | BitPuffin | Demos: but then you'd have to have a variable laying around somewhere right? |
14:24:51 | Demos | does more lifetime analysis than returning a ptr I guess. You can say like foo(glarg) = abar |
14:24:52 | BitPuffin | or will it keep on living if you declare it in the proc? |
14:25:13 | BitPuffin | oh |
14:25:20 | Demos | yeah the compiler will not let you return a local |
14:25:23 | BitPuffin | that's funky |
14:25:34 | BitPuffin | grooveh |
14:25:39 | Araq | Demos: the 'var T' as a return type breaks memory safety. This is a well known issue with at least 2 solutions. |
14:25:58 | Araq | the compiler prevents trivial mistakes for now, but the more complex examples escape it |
14:26:00 | BitPuffin | I can see it being somewhat cool though |
14:26:17 | Demos | it also means you have to write two functions in some cases, when you want mutable access |
14:26:17 | BitPuffin | for maybe interacting with a database |
14:26:44 | * | darkf quit (Quit: Leaving) |
14:27:03 | Demos | and in general I dont really like that we have three pointer types, even if they do mix pretty well |
14:27:05 | BitPuffin | so you could do some kind of query thing, and it would return an array or something, and you'd override the = for that array type and it would set all the returned stuff to the value |
14:27:49 | Demos | I dont really like that use of `=` overloading, but OK |
14:28:04 | BitPuffin | Demos: it was just a shitty example |
14:28:07 | Araq | Demos: ptr/ref are essential. I couldn't eliminate 'var' from the language after trying hard. |
14:28:08 | BitPuffin | DEAL WIZ IT |
14:28:27 | Araq | if you have a solution, let us know |
14:28:47 | BitPuffin | var is pretty much like doing void foo(int &lol) in C righ? |
14:28:57 | Araq | in C++, yes |
14:29:11 | BitPuffin | oh |
14:29:14 | BitPuffin | so that's not in C? |
14:29:16 | BitPuffin | didn't know |
14:29:35 | BitPuffin | rarely use it |
14:29:53 | BitPuffin | but yeah it can be pretty useful in nimrod |
14:29:55 | Araq | & is c++ only |
14:30:04 | BitPuffin | since it's esseintal to defining += |
14:30:09 | BitPuffin | or maybe not actually |
14:30:13 | BitPuffin | if you do it as a template |
14:30:29 | Araq | still '=' conceptually takes a 'var' |
14:30:39 | BitPuffin | yeah |
14:30:40 | BitPuffin | true |
14:31:07 | Demos | why should I return a var over a ptr (once we get implicit deref)? |
14:32:08 | BitPuffin | Demos: you mean over a ref? |
14:32:17 | Demos | no. over a ref |
14:32:26 | BitPuffin | you mean ptr? |
14:32:36 | Demos | oh yeah I mean ptr |
14:32:37 | Demos | christ |
14:32:41 | BitPuffin | HEHE |
14:32:50 | * | BitPuffin is trolling a little |
14:32:57 | Demos | I am not transfering ownership at all |
14:33:13 | BitPuffin | Demos: well var is not supposed to break memory safety probably |
14:33:19 | BitPuffin | ptr is not memory safe at all |
14:33:23 | BitPuffin | so why compare them |
14:34:42 | Demos | because one nimrod lets you return the var memory safety is the same |
14:34:59 | Demos | if you want to hold onto a var you need to take its address anyways |
14:35:16 | Araq | well BitPuffin is right 'ptr' is not safe at all, 'var' tries to be (but currently fails) |
14:35:41 | Varriount | How does var currently fail? |
14:36:13 | BitPuffin | Varriount: if you return var |
14:36:49 | BitPuffin | then Araq will spank you |
14:37:09 | Araq | proc foo(x: var int): var int =x; proc unsafe(): var int = foo(result) |
14:37:47 | Varriount | Huh. I didn't know you could *return* a var type |
14:38:06 | BitPuffin | Varriount: me neither, or I think I knew but I had completely forgotten |
14:38:42 | BitPuffin | Araq: forbidding returning var seems reasonable |
14:38:51 | BitPuffin | and then to enable it you could mark a proc as unsafe or something |
14:39:21 | Demos | Yeah esp since we hav the `..=` thing |
14:39:39 | Varriount | We have a ..= thing? |
14:39:50 | BitPuffin | think by .. he means +, * or whatever |
14:40:21 | * | BitPuffin the communication guru |
14:40:37 | BitPuffin | I should get that domain |
14:40:40 | BitPuffin | communication.guru |
14:40:43 | * | Varriount bows to BitPuffin's communicative prowess |
14:40:55 | Varriount | .guru exists? |
14:40:59 | BitPuffin | yeah |
14:41:00 | BitPuffin | it's new |
14:41:13 | BitPuffin | there is also .sexy -_- |
14:41:24 | BitPuffin | https://rms.sexy/ |
14:41:31 | Varriount | Is that sfw? |
14:42:04 | BitPuffin | that's where freetards go to fap |
14:42:06 | Araq | BitPuffin: 'var T' as return type is *essential* for containers |
14:42:10 | BitPuffin | Varriount: Yeah it is |
14:42:16 | Araq | that's why I added it |
14:42:24 | EXetoC | I heard he likes computers |
14:42:29 | BitPuffin | Araq: how so= |
14:42:37 | Araq | see tables.mget |
14:42:56 | Demos | mget could return a pointer though... right? |
14:42:57 | Araq | (which should become '[]' one day but that's a different topic) |
14:43:20 | Araq | Demos: right but then that is not consistent with how built-ins like arrays work |
14:43:43 | Demos | right, and we would need implicit dereferenceing for it to work |
14:43:48 | Araq | proc foo(x: var T); foo(a[i]) # [] for arrays returns a 'var T' conceptually |
14:44:09 | * | isenmann quit (Quit: Leaving.) |
14:45:00 | BitPuffin | zahary would freak out for me asking this, and Araq will surely to. But is or will procs be valid generic parameters one day? |
14:45:02 | * | BitPuffin hides |
14:45:19 | EXetoC | does seq as a magic type provide any benefits compared to a pure library implementation? |
14:45:38 | BitPuffin | will surely TOO* |
14:46:13 | Araq | EXetoC: for now yes. in the longer run, no. |
14:46:48 | EXetoC | ok |
14:46:56 | BitPuffin | Varriount: what did you think? |
14:47:03 | Demos | I assumed seq as magic was some GC related thing that I did not understand |
14:48:12 | Araq | Demos: yes, indeed |
14:48:17 | Demos | BitPuffin: you can emulate a proc as a generic param with a "functor" I think, but it is a bit unclean |
14:49:09 | BitPuffin | where the fuck is tables.nim anyway, github can't find it |
14:49:21 | BitPuffin | Demos: functor? |
14:49:26 | BitPuffin | Well I mean proc types |
14:49:27 | Demos | the c++ kind |
14:52:35 | EXetoC | BitPuffin: yo, search the lib dir |
14:52:48 | EXetoC | or check the manual. it's in pure/collections |
14:53:13 | BitPuffin | github search is useless yo |
14:53:39 | EXetoC | it shows up there |
14:53:53 | EXetoC | going to the actual repository first might help |
14:58:03 | BitPuffin | EXetoC: http://youtu.be/R0nbhh-GWpw |
14:58:10 | BitPuffin | I was in the repo |
14:59:28 | EXetoC | so was I |
15:00:14 | Demos | gotta go to class, see yall in 4 hours |
15:01:52 | BitPuffin | Demos: sounds like a fun class if it's 4 hours lol |
15:04:38 | * | Demos quit (Ping timeout: 240 seconds) |
15:19:03 | * | Matthias247 joined #nimrod |
15:38:42 | * | Matthias247 quit (Read error: Connection reset by peer) |
15:45:39 | dom96 | BitPuffin: Here is a useful tip for you: go to the repo you want to search and press 't' |
15:45:46 | dom96 | Type in the filename |
15:45:55 | dom96 | and you will get a list of files in that repo |
15:46:07 | BitPuffin | neato |
15:46:13 | BitPuffin | you wanna vnug? |
15:46:35 | dom96 | hell yes. Let's do it baby |
15:46:42 | dom96 | let me just put something to eat in the oven |
15:46:52 | Raynes | o_o |
15:47:45 | Skrylar | o_o |
15:47:49 | BitPuffin | 0_0 |
15:48:08 | EXetoC | d-(O_o)-p |
15:48:10 | Skrylar | ಠ_ಠ |
15:48:34 | EXetoC | «_«þ®€þœ©→þ€®œþ©®ł€ĸœµ€@ł |
15:49:38 | BitPuffin | O(log n * n^n^n^n^n) |
15:49:47 | Skrylar | O(kirby) |
15:49:56 | BitPuffin | O(u) |
15:49:58 | dom96 | 0_o |
15:50:05 | Skrylar | this has been a very productive hour in nimrod history |
15:50:12 | BitPuffin | dom96: done putting your penis in the oven? |
15:50:57 | dom96 | BitPuffin: Stop spying on me! |
15:52:31 | BitPuffin | we all know you like it hot dom96, no need to spy |
15:53:07 | Raynes | NOT APPROPRIATE FOR HQ |
15:53:34 | EXetoC | you know what this salad needs? |
15:54:03 | BitPuffin | EXetoC: semen? |
15:54:17 | EXetoC | cowbell |
15:54:32 | * | Skrylar checks EXetoC for a fever |
15:56:41 | BitPuffin | EXetoC: you are drunk |
15:57:24 | NimBot | Varriount/NimLime master cab8e7a onionhammer [+0 ±1 -0]: Differentiate i from tmpl operator |
15:58:06 | BitPuffin | dom96: meet |
15:59:04 | NimBot | Varriount/NimLime master 070c9fa onionhammer [+0 ±1 -0]: Differentiate i from tmpl operator |
16:36:11 | BitPuffin | dom96: staahp |
16:50:33 | * | DAddYE joined #nimrod |
16:56:58 | * | DAddYE quit (Read error: Connection timed out) |
16:57:33 | * | DAddYE joined #nimrod |
17:02:34 | Araq | so I made the "feature matrix" people nag me about |
17:02:48 | OrionPK | link? |
17:02:58 | Araq | but I'm tired of ascii-arting tables |
17:03:14 | Araq | how do I make a html table with a dead simple syntax? |
17:03:31 | OrionPK | <table><tr><td>? :P |
17:03:40 | Araq | OrionPK: btw I can't reproduce the memory leak with windows' task manager |
17:03:48 | Araq | it doesn't leak at all for me |
17:03:52 | OrionPK | good |
17:04:00 | OrionPK | I guess ;P |
17:04:57 | OrionPK | Araq use emmet to generate html |
17:05:42 | OrionPK | table>tr*2>td*4 + {tab} = 2x4 table |
17:08:13 | * | nande quit (Remote host closed the connection) |
17:11:12 | dom96 | Araq: Write a Nimrod DSL to generate HTML easily :P |
17:11:28 | Araq | dom96: thars what i am doing |
17:13:14 | dom96 | Also, yeah. Link? plz? |
17:16:57 | NimBot | Araq/Nimrod devel 08a19bf Araq [+0 ±3 -0]: fixes #911 |
17:16:57 | NimBot | Araq/Nimrod devel 083b946 Araq [+0 ±2 -0]: tester outputs full test path |
17:44:00 | * | shodan45 joined #nimrod |
17:44:14 | Araq | hi shodan45 wb |
17:44:21 | shodan45 | Araq: hello |
17:45:20 | shodan45 | I've been on an anti-IRC diet lately.... needed to get stuff done :/ |
17:45:52 | Araq | dom96: release date: 2014-03-30 |
17:46:26 | dom96 | Araq: async isn't ready |
17:46:34 | Araq | it is |
17:46:49 | dom96 | can you fix the corruption? |
17:46:55 | Araq | working on it |
17:47:04 | Araq | it's the last thing on my todo ... |
17:47:18 | BitPuffin | dom96, Araq: yeah we should really update htmlgen |
17:47:19 | Araq | then 0.9.4 is as stable as it will get |
17:47:22 | BitPuffin | need to make it more complete |
17:47:25 | BitPuffin | in terms of html5 |
17:47:30 | Araq | no |
17:47:36 | Araq | deprecated htmlgen |
17:47:43 | Araq | rewrite it |
17:47:55 | Araq | the immediate 1 char macros are evil |
17:48:08 | BitPuffin | lal |
17:48:12 | BitPuffin | what are you calling the new one |
17:48:19 | BitPuffin | htmlsparkle? |
17:48:43 | Araq | system.universe.html.generator ofc |
17:49:15 | BitPuffin | speedo.sphincter.html.penetrator* |
17:49:43 | Araq | BitPuffin.told.us.it.is.a.good.idea.html.generator |
17:50:02 | BitPuffin | seems like a reasonable name |
17:50:36 | Araq | web.scale.html.generator |
17:50:41 | Araq | now that's it |
17:51:01 | BitPuffin | haha |
17:51:07 | BitPuffin | almost there |
17:51:21 | BitPuffin | web.scale.html.big.data |
17:51:40 | BitPuffin | cloud |
17:52:00 | BitPuffin | web.scale.nosql.cloud.big.data.html |
17:52:06 | BitPuffin | done |
17:53:20 | BitPuffin | dom96: sandwitch, then CS, done with this iOS shit |
17:53:36 | BitPuffin | whoever made it is a foken tätt |
17:54:33 | * | easy_muffin quit () |
17:55:22 | BitPuffin | dom96: right forgot you were fapping |
18:02:05 | * | psquid joined #nimrod |
18:04:46 | dom96 | BitPuffin: back |
18:05:46 | BitPuffin | dom96: I hear ya |
18:06:03 | BitPuffin | yes |
18:06:10 | * | Matthias247 joined #nimrod |
18:06:12 | BitPuffin | sandwich |
18:12:34 | * | q66 joined #nimrod |
18:13:03 | * | vendethiel quit (Ping timeout: 255 seconds) |
18:16:17 | dom96 | Araq: I would like to add async support to all the other modules too if possible. |
18:16:22 | dom96 | before release. |
18:16:29 | * | vendethiel joined #nimrod |
18:16:42 | dom96 | but oh well. I guess it's ok. |
18:16:59 | dom96 | We should add the closure macro though |
18:18:03 | * | vendethiel quit (Read error: Connection reset by peer) |
18:18:52 | * | vendethiel joined #nimrod |
18:18:56 | * | q66 quit (Ping timeout: 252 seconds) |
18:20:21 | BitPuffin | dom96: almost done |
18:21:09 | * | q66 joined #nimrod |
18:25:54 | * | CarpNet quit (Quit: Leaving) |
18:32:17 | Araq | dom96: the closure macro will only be buggy as hell when people pass 3x nested templates to it or something |
18:32:31 | dom96 | oh well. |
18:32:34 | Araq | we need to mark that as experimental too |
18:32:58 | dom96 | hrm, I guess. |
18:33:12 | dom96 | But shouldn't people assume most things are experimental anyway? |
18:36:55 | Araq | hmm I dunno |
18:37:32 | Araq | I guess |
18:41:09 | * | brson joined #nimrod |
18:41:19 | * | brson quit (Client Quit) |
18:41:26 | * | brson joined #nimrod |
18:41:48 | shodan45 | experimental just means that it's more fun |
18:42:53 | Varriount | Warning: Unless otherwise stated, everything anywhere is experimental. We are not responsible for any lost pets, reality distortions, or insurence premium changes. |
18:43:24 | * | [1]Endy quit (Ping timeout: 265 seconds) |
18:45:05 | Araq | it's not "experimental" at all. more like "it works unless you fuck the compiler" |
18:46:12 | runvnc | The features that I use work |
18:46:33 | runvnc | Normal templates and well, all the features I tried |
18:46:45 | Varriount | Araq: It works unless you try to be a smarty-pants with the compiler. |
18:46:47 | runvnc | I haven't really comprehended or exercised a lot of the metaprogramming though |
18:47:56 | runvnc | I think there are some things that are like getting clever with expanding/changing the language that are experimental |
18:48:06 | runvnc | these are just my rough impressions, take them with a grain of salt |
18:50:52 | * | DAddYE_ joined #nimrod |
18:53:05 | * | DAddYE quit (Read error: Operation timed out) |
18:54:56 | * | DAddYE_ quit (Ping timeout: 240 seconds) |
19:11:26 | * | askatasuna joined #nimrod |
19:31:07 | * | Demos joined #nimrod |
19:33:31 | * | eximiuswastaken joined #nimrod |
19:33:41 | eximiuswastaken | quick question: how do I cast an int to some enumerated ordinal type? ie, 3->Three |
19:34:50 | EXetoC | if 3.T doesn't work, then I think you have to do cast[T](val) |
19:34:56 | fowl | type conversion should work |
19:35:00 | dom96 | 3.TEnumType should work. |
19:35:00 | fowl | T(3) or 3.T |
19:35:11 | eximiuswastaken | lets find out... |
19:36:32 | dom96 | eximiuswastaken: Welcome to #nimrod btw :) |
19:36:41 | * | easy_muffin joined #nimrod |
19:37:08 | eximiuswastaken | dom96: thank you! :) I've been here before... for some reason I got kicked. maybe idle for too long? idk. |
19:37:12 | eximiuswastaken | anyway, that worked! |
19:37:16 | eximiuswastaken | Followup! |
19:37:26 | eximiuswastaken | Why does system.rand give me the same value each time? lol |
19:37:31 | eximiuswastaken | do I have to seed it? |
19:37:44 | dom96 | did you call randomize() ? |
19:37:45 | fowl | eximiuswastaken, that one is a random number at compiletime |
19:37:54 | fowl | you want randomize/random from the math module |
19:38:09 | dom96 | oh yeah, nvm what I said. |
19:38:29 | eximiuswastaken | I'm calling it in a loop 10 times for testing. So, it gets assigned the same value 10 times, but different values across compilation? |
19:38:33 | eximiuswastaken | how bizarre. |
19:38:56 | fowl | random number at compiletime |
19:40:33 | eximiuswastaken | got it. it works now. |
19:40:58 | eximiuswastaken | it's just a stupidly simply deck of cards thing. very easy to see with the enumerations being the index of the array and all. |
19:41:12 | EXetoC | sometimes it's useful to do certain things at compile-time, but it's a source of confusion in this case |
19:41:40 | EXetoC | if you for whatever don't read the documentation, but still |
19:41:55 | Demos | random() is probably a bad name for that funciton |
19:41:59 | Demos | I got bit a while ago as well |
19:42:09 | fowl | rand predates static: |
19:44:03 | Araq | rand was also added when I was much smarter than I am today |
19:44:24 | fowl | lol why do you say that |
19:45:30 | eximiuswastaken | Yea... lol if anything, it should at least be renamed or contain a reference to math.random in the documentation for system.rand so that people know that it's not what they're looking for. |
19:45:40 | Araq | because I don't get why I added it. how can a compiletime rand be used for testing or debugging? |
19:45:54 | eximiuswastaken | Araq: I was actually just thinking that. I have no idea. |
19:46:01 | Demos | Araq: making nimrod really fast on benchmarks? |
19:46:04 | eximiuswastaken | lol |
19:46:16 | EXetoC | how is the connectivity for wireless keyboards that aren't dirt cheap? having to move it around is a pain in the ass |
19:46:41 | Demos | I would not go there. If you do get a RF one, bluetooth is the devil's tool |
19:47:18 | fowl | Araq, if i wanted a compile-time random number how else could i get it? something like let x = static: random() isnt working |
19:48:45 | EXetoC | Demos: RF? |
19:48:51 | EXetoC | it's USB |
19:48:57 | Demos | Radio Frequency |
19:49:00 | Araq | fowl: yeah I know. But still |
19:49:10 | Demos | so like not bluetooth |
19:49:53 | Demos | wow apperently concepts GCC was like 5x slower than regular GCC, christ |
19:51:05 | dom96 | Araq: You added it about 2 years ago: https://github.com/Araq/Nimrod/commit/3f03d9da39391c7bdeb5ee2f18de6ef999c56813 |
19:51:32 | EXetoC | Demos: I'm confused. you're saying bluetooth is alright? anyway, I'll replace it with a wired keyboard |
19:51:47 | Demos | no, you want RF. Bluetooth is hard to deal with |
19:52:08 | fowl | bluetooth is annoying and possibly more power hungry than bluetooth, on the other hand RF will likely take up a USB port |
19:52:18 | fowl | more power hungry than RF* |
19:53:07 | * | awestroke joined #nimrod |
19:57:31 | EXetoC | ok. you've never had a wireless device that you've had to re-position? it's only a meter a way in my case, with not that much in the way |
19:59:44 | BitPuffin | dom96: doooooOOOOoooom |
20:00:06 | fowl | Araq, there should be a way to do that right? |
20:00:46 | fowl | oh cannot importc a variable at compiletime :/ |
20:02:33 | BitPuffin | Araq: join us |
20:02:36 | BitPuffin | Araq: in CS:GO |
20:03:32 | * | easy_muffin quit () |
20:03:38 | * | gXen joined #nimrod |
20:08:36 | OrionPK | bluetooth is RF |
20:10:49 | Matthias247 | details ;) |
20:15:25 | Matthias247 | one major difference is also that the proprietary RF stuff (e.g. from logitech) works also in the Bios or anywhere else without a driver |
20:15:37 | Demos | OrionPK: whatever, you want something that comes with a dongle (hehe) that had its own drivers. Bluetooth is a PITA to set up |
20:17:35 | * | io2 joined #nimrod |
20:19:08 | Matthias247 | as fowl said: BT makes sense when you are restricted on USB ports and don't want to carry a receiver around. E.g. on a laptop |
20:22:08 | fowl | bt also might be a security risk, i've met people in mcdonalds (self-professed hackers) who were like dude just turn on ur bluetooth i'll show you i can hack your computer |
20:22:30 | fowl | of course that merrits the response: using a program you find online makes you a script kiddy, not a hacker |
20:22:51 | fowl | "tell me something about the bluetooth stack" "..what?" |
20:23:14 | EXetoC | hacker or cracker? :p |
20:23:29 | fowl | im a hacker, i know how to google |
20:37:38 | BitPuffin | Demos: did you join and leave the VNUG? |
20:37:42 | EXetoC | gotta have more cowbell man |
20:37:56 | Demos | yeah, I decided to finish my assignment first |
20:38:25 | BitPuffin | aight |
20:43:06 | runvnc | well I have a wireless usb keyboard and mouse on my linut mint, hope no one is hacking me. sure is nice to not have wires though |
20:45:16 | EXetoC | runvnc: you never lose the connection? |
20:45:55 | runvnc | no. but my keyboad is only like a meter away max |
20:45:59 | runvnc | keyboard |
20:46:25 | EXetoC | mine too. I gotta figure out what the hell is going on |
20:47:30 | * | nande joined #nimrod |
20:47:50 | runvnc | you havent had it for a long time have you? most obvious thing is battery getting low |
20:48:25 | EXetoC | it's always bad |
20:49:57 | runvnc | you have logitech? |
20:50:18 | runvnc | I googled logitech wireless it says "unifying" tiny wireless receiver 2.4 ghz |
20:50:27 | runvnc | then I googled 2.4ghz interference |
20:51:09 | runvnc | hm uses of 2.4 ghz band: phone, bluetooth, car alarm, microwave, wi-fi, eirp |
20:55:18 | runvnc | here you go, you can just paint your entire room with this YSHIELD EMF Shielding Paint http://www.amazon.com/YSHIELD-Shielding-Paint-HSF74-Liter/dp/B007AT1PVW/ref=sr_1_2?s=hi&ie=UTF8&qid=1396040064&sr=1-2&keywords=emf+shielding lol |
20:55:51 | EXetoC | alright thanks |
20:55:57 | runvnc | heh |
21:00:14 | fowl | lol |
21:05:15 | EXetoC | dom96: wanna try that macro? :p |
21:09:44 | * | [1]Endy joined #nimrod |
21:12:54 | * | rixx quit (Quit: WeeChat 0.4.3) |
21:13:44 | * | rixx joined #nimrod |
21:20:25 | EXetoC | so what should the html templates be replaced with? good old procs should do |
21:21:49 | EXetoC | we're just emulating kwargs now aren't we? is that possible using a less hacky approach? |
21:26:21 | * | rixx quit (Quit: WeeChat 0.4.3) |
21:26:37 | * | rixx joined #nimrod |
21:38:12 | Araq | EXetoC: what do you mean? our approach has 0 overhead and is idiomatic |
21:40:18 | EXetoC | Araq: yeah but you said it was badly implemented |
21:41:31 | * | [1]Endy quit (Ping timeout: 265 seconds) |
21:43:53 | EXetoC | didn't you want it to be rewritten? |
21:44:05 | Araq | htmlgen? yes |
21:44:17 | Araq | but the kwargs are cool |
21:46:26 | EXetoC | yeah and the current approach is used for that reason, right? |
21:47:04 | Araq | htmlgen is archaic |
21:47:36 | Araq | but to get rid of the immediate we need an additional rule for 'any' in the overloading resolution or something |
21:47:48 | Araq | that's what you mean, I think |
21:49:38 | EXetoC | I don't know the details |
22:04:36 | io2 | This should be a nimrod project eventually: https://github.com/gogits/gogs |
22:04:59 | io2 | nimrod could fare better design - wise, I believe |
22:07:56 | * | reloc0 quit (Ping timeout: 255 seconds) |
22:12:52 | * | reloc0 joined #nimrod |
22:13:44 | NimBot | Araq/Nimrod devel 1384660 Charlie Barto [+0 ±1 -0]: fixed doc comment |
22:13:44 | NimBot | Araq/Nimrod devel 9570c4f Andreas Rumpf [+0 ±1 -0]: Merge pull request #1045 from barcharcraz/lowerBound... 2 more lines |
22:23:23 | * | Matthias247 quit (Read error: Connection reset by peer) |
22:34:04 | * | reloc0 quit (Quit: WeeChat 0.3.8) |
22:34:13 | * | armin1 joined #nimrod |
22:34:29 | * | armin1 is now known as reloc0 |
22:38:48 | Araq | OrionPK, dom96, Varriount, EXetoC, BitPuffin https://github.com/Araq/Nimrod/wiki/Feature-Matrix |
22:48:28 | * | xenagi joined #nimrod |
22:55:19 | * | gXen quit () |
23:03:32 | Demos | hmm facebook wrote a c preprocessor |
23:07:37 | Demos | well helped walter bright write one I guess |
23:11:15 | * | nande quit (Read error: Connection reset by peer) |
23:11:38 | * | nande joined #nimrod |
23:31:13 | * | nolan_d quit (Remote host closed the connection) |
23:36:57 | * | darkf joined #nimrod |
23:45:28 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
23:45:46 | Araq | oh dom96, btw I found an easy way to do iterator validation for seqs if assertions are turned on |
23:48:42 | dom96 | cool |