| 00:00:03 | Demos | YAY! |
| 00:00:05 | Demos | it wooooorks |
| 00:00:25 | * | Demos starts writing a better linear algebra library |
| 00:01:49 | zahary | Demos, I planning only once small fix for matrix libraries - for generic types defined like this Matrix[N, M: range; T], the rules that apply to the built-in array type will apply as well |
| 00:01:53 | * | Matthias247 quit (Quit: Matthias247) |
| 00:02:21 | zahary | so, you'll be able to say Matrix[4, 4, float] just like with static ints. |
| 00:02:42 | zahary | the very small benefit is that you can use the range types in the cell accessor procs |
| 00:03:10 | Demos | my matrix is going to be defined as type Matrix[T; N,M: static[int]] = array[0..N*M-1, T] |
| 00:03:15 | zahary | proc `[]` (x: Matrix, a: Matrix.N, b: Matrix.M) |
| 00:03:35 | zahary | make that at least distinct |
| 00:03:40 | Demos | yeah ofc |
| 00:04:00 | Demos | actually right now it is an object with an array member |
| 00:04:45 | Demos | actually I have an options param as well, but it is just so I can overload on stuff like storage order |
| 00:05:22 | zahary | default parameters should be supported as well |
| 00:05:45 | Demos | wonderful! |
| 00:06:28 | Demos | btw the implicit generic style is really, really nice for this sort of stuff |
| 00:07:57 | zahary | yeah, I don't know another language that is so slick when it comes to generics |
| 00:09:09 | Demos | my favorite c++ linear algebra library returns something derived from the following for its operations: |
| 00:09:11 | Demos | typedef Matrix<typename internal::traits<Derived>::Scalar, internal::traits<Derived>::RowsAtCompileTime, internal::traits<Derived>::ColsAtCompileTime, AutoAlign | (internal::traits<Derived>::Flags&RowMajorBit ? RowMajor : ColMajor), internal::traits<Derived>::MaxRowsAtCompileTime, internal::traits<Derived>::MaxColsAtCompileTime > PlainObject |
| 00:09:12 | EXetoC | yeah, good stuff |
| 00:11:01 | EXetoC | Demos: holy shit |
| 00:11:39 | Demos | it is using something called expression templates to do lazy evaluation of the ops, so that infix operations and operations that return new matrices can be done quickly |
| 00:12:09 | zahary | I know the drill - is it euler? |
| 00:12:15 | Demos | Eigen |
| 00:12:21 | zahary | ah, yeah :) |
| 00:13:34 | Demos | it is awesome, and actually does not hurt compile time much. |
| 00:15:35 | * | DAddYE quit (Remote host closed the connection) |
| 00:16:01 | * | DAddYE joined #nimrod |
| 00:17:43 | zahary | well, go after it - it's still not clear whether we'll be able to improve on the expression template techniques with the term rewriting macros - they can apply similar elimination of temporaries by collecting long expressions such m1 * m2 + m3 to be processed in a single macro |
| 00:20:42 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 00:42:21 | Skrylar | meep |
| 00:42:55 | * | darkf joined #nimrod |
| 00:44:45 | EXetoC | meep |
| 00:44:54 | EXetoC | Varriount: meep? |
| 00:50:05 | Demos | oh EXetoC I was having problems with your GLFW wrapper |
| 00:50:21 | Demos | in particular glfw is glfw3.dll on my system |
| 00:50:25 | * | Varriount quit (Ping timeout: 240 seconds) |
| 00:50:39 | Demos | this may only be the devel versions built from master though |
| 00:57:56 | EXetoC | Demos: no the same goes for the binaries apparently. will fix |
| 00:58:06 | Demos | sweet, thanks |
| 00:59:41 | Skrylar | well thats unawesome |
| 00:59:43 | EXetoC | there |
| 00:59:50 | Skrylar | I updated to the latest devel and compile speed dropped 3fold |
| 01:00:22 | EXetoC | that's not good |
| 01:00:40 | Demos | Skrylar, did you forget -d:release |
| 01:00:56 | Skrylar | i rolled it with koch but i can go fiddle with it again |
| 01:01:51 | Skrylar | I'm not satisfied that using 'unittest' requires so many dependencies i will admit |
| 01:01:58 | Skrylar | using asserts -> 8000 lines |
| 01:02:02 | Skrylar | using unittest -> 30,000 lines |
| 01:03:06 | Skrylar | alright, re-rebootstrapped now its good |
| 01:03:07 | Demos | looks like it only imports macros and os |
| 01:03:44 | Skrylar | i import unittest and unsigned, the compiler logs macros, stdutils, parseutils, winlean, terminal and windows |
| 01:03:47 | EXetoC | it's a fine module |
| 01:04:08 | Demos | OK a lot of that is windows headers |
| 01:16:34 | * | DAddYE joined #nimrod |
| 01:17:45 | EXetoC | did I break Varriount's internet? |
| 01:18:18 | EXetoC | Demos: is it working now? |
| 01:21:07 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 01:21:35 | * | mangat quit (Remote host closed the connection) |
| 01:21:35 | * | pelevina quit (Remote host closed the connection) |
| 01:25:10 | * | askatasuna joined #nimrod |
| 01:30:54 | * | Demos_ joined #nimrod |
| 01:33:22 | * | zielmicha quit (Quit: Connection closed for inactivity) |
| 01:38:18 | * | askatasuna quit (Ping timeout: 240 seconds) |
| 01:59:22 | * | brson quit (Quit: leaving) |
| 01:59:39 | * | brson joined #nimrod |
| 02:08:59 | * | Demos_ quit (Ping timeout: 240 seconds) |
| 02:09:40 | * | Varriount joined #nimrod |
| 02:17:13 | * | olegbel joined #nimrod |
| 02:28:58 | Skrylar | wb Varriount |
| 02:29:32 | Varriount | My internet connection to irc has been weird ever since that big netsplit. |
| 02:33:31 | * | q66 quit (Quit: Leaving) |
| 02:34:36 | * | xenagi joined #nimrod |
| 02:34:49 | Demos | ah let me check EXetoC |
| 02:36:07 | Skrylar | I'm getting sorta sick of arranging people from different parts of the globe and timezones yet they all at the same time decide to just stop showing up at the same time :\ |
| 02:36:10 | Skrylar | meh |
| 02:37:43 | Demos | seems to work EXetoC |
| 02:37:51 | Varriount | Something wrong? |
| 02:39:49 | Skrylar | Nah I'm just an asshole since I don't know any better, so people off IRC walk off and leave when they can. A fun deathspiral of leaving someone to write code and rot which doesn't make them nicer people, but hey we have better hashing code now |
| 02:39:54 | Skrylar | tonight its a hashtable |
| 03:00:34 | Skrylar | I don't suppose procedures can be used as generic parameters |
| 03:02:22 | Varriount | Skrylar: What do you mean? |
| 03:11:24 | Skrylar | Varriount something like X = Thistable[string, sometype, thisismyhashfunction] |
| 03:12:21 | Varriount | Skrylar: X = Thistable[string, sometype, type(thisismyhashfunction)] |
| 03:13:35 | Demos | try it! |
| 03:14:17 | Demos | you should somehow be able to encode the hash function in the type, like c++ odes |
| 03:14:28 | Demos | except we have less insane first class functions |
| 03:17:18 | Varriount | Demos, Skrylar : https://gist.github.com/Varriount/9458869 |
| 03:17:37 | Varriount | Of course that's with a seq, but you get the idea. |
| 03:18:10 | Skrylar | i'm not really encoding the hash function to the type; i wanted the hash alg to be adjustable |
| 03:18:25 | Demos | one thing is that you don't really want to store the function pointer in the hash table anywhere |
| 03:18:31 | Demos | you want it to be a phantom type |
| 03:18:45 | Skrylar | thats why i was asking about it being part of the generic |
| 03:18:48 | Skrylar | so it just gets compiled in |
| 03:19:12 | * | flaviu quit (Remote host closed the connection) |
| 03:19:39 | Skrylar | I sorta don't like when there is just a "hash" function like C#/Java does it |
| 03:19:56 | Skrylar | xblah.hash() # what does that mean? FNV? siphash? Is it secure? is it fast? |
| 03:20:06 | Varriount | Skrylar: One where you have to pass the kind of hash as a string/enum? |
| 03:24:05 | Demos | welp I tried to make a test case and segfaulted the compiler |
| 03:24:23 | Varriount | Demos: Can I see? |
| 03:24:52 | Demos | https://gist.github.com/barcharcraz/6154649dab9033a776db |
| 03:25:55 | Varriount | Demos, 'T' is type - you can't perform a runtime proc on it :p |
| 03:29:29 | Demos | https://gist.github.com/barcharcraz/87799af057a39a934528 |
| 03:29:37 | Demos | I heard that int.foo was short for foo[int]() |
| 03:29:52 | Demos | but currently it seems to go to foo(typedesc[int]) |
| 03:29:57 | Demos | anyway that second gist works |
| 03:31:11 | Varriount | You know what would be an awesome project - Easy nimrod running and deployment on android. |
| 03:32:58 | Demos | we need easy nimrod deployment in general, that means getting some kind of system for buildiing things that depend on the outside world |
| 03:33:11 | Demos | anyway that codee may have been wrong but the segfault is still a bug |
| 03:33:13 | Varriount | Well, there's nake |
| 03:33:35 | Demos | I am talking like CMake implemented in nimrd, heck we may even be able to use cmake |
| 03:34:17 | Demos | we probably would not need the makefile generation stuff, but we would set the correct linker flags, find libraries, maybe even download, build, and install libs at compile time |
| 03:34:26 | Demos | that would be sweet |
| 03:34:30 | Varriount | Isn't the whole point of nimrod's compile-time stage to mitigate the need for such measures? |
| 03:36:27 | Demos | yes, but it would be a nimrod lib not external program |
| 03:36:45 | Demos | so more sane |
| 03:36:58 | Demos | we need to be able to deal with using external libs and assets |
| 03:37:04 | Demos | anyway ima go play ArmA |
| 03:43:13 | * | psquid_ quit (Ping timeout: 265 seconds) |
| 03:44:35 | * | psquid_ joined #nimrod |
| 04:01:54 | * | DAddYE joined #nimrod |
| 04:05:07 | * | DAddYE quit (Client Quit) |
| 04:07:16 | Skrylar | meh, arma. |
| 04:07:32 | Skrylar | i'm thinking about removing skype/teamspeak from my PC |
| 04:09:24 | Demos | heh whatever, arma requires a good few hours to really have fun in but it is /really/ fun |
| 04:09:29 | * | xenagi quit (Quit: Leaving) |
| 04:09:49 | Demos | like if you die the teamspeak addon will make it so you are talking only to the other dead people |
| 04:10:01 | Demos | and everyone is watching the game as spectators |
| 04:11:23 | Skrylar | i'm aware of how acre works |
| 04:11:40 | Skrylar | people regularly plug how awesome arma is at me even after i told them i don't enjoy games with 6 hour respawn times |
| 04:14:32 | Demos | yeah, it is not for a quick drop in game |
| 04:14:55 | Demos | I like CoD and friends as well |
| 04:16:00 | runvnc_ | hello |
| 04:16:06 | runvnc_ | is there a bcrypt library in babel or something |
| 04:16:34 | runvnc_ | well not in babel |
| 04:20:43 | Skrylar | i guess i could add bcrypt to my list of things to port |
| 04:21:38 | runvnc_ | does it need to be ported or could it be like a wrapper for this http://bcrypt.sourceforge.net/ |
| 04:23:41 | runvnc_ | the wrappers all use dynamic libs or something? so can't be entirely static |
| 04:23:59 | Skrylar | wrappers can be static if you make them that way |
| 04:24:23 | Demos | usually the wrappers use dynamic libs by default |
| 04:25:42 | Demos | the libraries are loaded with dlopen during program initialization, if you want the libraries to be loaded the "normal" way you use --dynlibOverride:libname if you want static linking you also use --dynlibOverride:libname. In both cases you may have to pass extra linker flags with --passl |
| 04:26:43 | Demos | it looks like bcrypt is an algorithm |
| 04:26:56 | Demos | I would say we should wrap a C implementation of that algorithm |
| 04:28:18 | Skrylar | Demos: the problem is (@the fps' earlier) i'm not a super-competitive-korean-y player at heart; i spent a lot of time the past two days thinking about it, and it really only takes a single "competitive" player to completely ruin any multiplayer experience for everyone else. there are more than a few articles that extend that even to casual social games, about how it only takes one min-maxer |
| 04:28:18 | Skrylar | who's memorized half the sourcebooks to completely relegate the rest of a 6-man party completely unnecessary and out of having fun. So its a matter of one jackass shows up and makes a game 'competitive', and now everyone else has to sit and do four hours of accuracy training a day or memorize sourcebooks to prevent that guy ruining everything. And in effect, he's ruined the casual nature by |
| 04:28:18 | Skrylar | virtue of making people *have* to do that in the first place. Which is why I've been somewhat disenfranchised with multiplayer-anything as of late |
| 04:30:46 | Demos | in my experience with arma people are totally fine as long as you are not derping around (like singing on the mic, melting faces with backblast, randomly stealing tanks and so on) |
| 04:31:05 | Demos | you have to put some time in to learn how the teams work though |
| 04:31:39 | Skrylar | i've been around a few; it doesn't solve the 'accuracy problem' though |
| 04:31:52 | Skrylar | not everyone enjoys "well your DPS is bad, so 'teamwork' for you means you get to hide in the truck" |
| 04:33:57 | Skrylar | I have a lot of interest in how AI coding works to make better single/co-op experiences, because people can just have fun with those without one guy dragging everyone in to needing to do training missions |
| 04:35:26 | Skrylar | It bothers me somewhat that the point of RPGs is to be immersed in a story as somebody/something else, but in reality they just allow calculus experts to engage in powerfantasies while relegating everyone else to the noob pile |
| 04:35:29 | * | Skrylar shrugs |
| 04:36:17 | Demos | I agree about RPG min-maxing but I enjoy the serious teamwork of ArmA, with a focus on fun ofc |
| 04:36:54 | Demos | I do /not/ like hypercompetitive dota clones |
| 04:37:22 | Demos | starcraft is kinda fun but extremely stressful. I play games to relax and have fun. Starcraft is not that fun when you loose |
| 04:37:27 | Demos | I need to go to sleep now |
| 04:37:30 | * | Demos quit (Quit: Leaving) |
| 04:37:34 | Skrylar | lol. g'night |
| 04:38:10 | Skrylar | runvnc_: no i don't think we have a pre-existing bcrypt lib |
| 04:38:20 | runvnc_ | k |
| 04:39:15 | runvnc_ | I'm looking at some code like https://github.com/ncb000gt/node.bcrypt.js/blob/master/src/bcrypt_node.cc or http://stuff.mit.edu/afs/sipb/project/freebsd/head/secure/lib/libcrypt/blowfish.c to see if its feasible for me to try to do it |
| 04:39:22 | runvnc_ | to wrap it |
| 04:39:39 | runvnc_ | the freebsd one seems to be missing the part where you actually compare to check if a password is right |
| 04:41:23 | runvnc_ | although maybe thats pretty simple |
| 04:56:35 | Varriount | Hm. I wonder how hard it would be to wrap Android's NDK with C2Nim |
| 04:56:44 | runvnc_ | well yeah comparing strings is simple and this node one has a compare strings that uses a set length which makes it harder to hack |
| 05:08:59 | renesac | Skrylar, one would pass the hash function to the hash table at creation time, and then the hash table uses that hash function internally for the input? |
| 05:12:35 | renesac | an now you can use static[T] to implement different types of siphash |
| 05:26:01 | * | brson quit (Ping timeout: 240 seconds) |
| 05:27:19 | * | brson joined #nimrod |
| 05:35:34 | * | brson quit (Ping timeout: 264 seconds) |
| 05:36:18 | * | brson joined #nimrod |
| 05:36:19 | * | brson quit (Client Quit) |
| 05:39:29 | * | Demos joined #nimrod |
| 05:43:37 | * | Demos quit (Client Quit) |
| 06:06:11 | Skrylar | Varriount: probably not very, though you would need to augment the compile chain so it used the ARM-based gcc instead of the x86 |
| 06:08:28 | * | respire quit (Ping timeout: 244 seconds) |
| 06:15:46 | runvnc_ | well I have a test bcrypt c program that works on my computer now :) |
| 06:24:41 | * | nande quit (Remote host closed the connection) |
| 06:27:05 | Skrylar | runvnc_: success |
| 06:35:47 | * | skyfex joined #nimrod |
| 07:04:14 | * | kserov quit (Remote host closed the connection) |
| 07:04:15 | * | olegbel quit (Remote host closed the connection) |
| 07:11:07 | * | Endy joined #nimrod |
| 07:17:04 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 07:19:58 | * | ninjin quit (Ping timeout: 264 seconds) |
| 07:20:11 | * | ninjin joined #nimrod |
| 07:25:37 | * | r0b1 quit (Ping timeout: 240 seconds) |
| 07:45:53 | * | Kelet quit (Read error: Connection reset by peer) |
| 07:51:29 | * | Kelet joined #nimrod |
| 08:14:10 | * | Kelet quit (Remote host closed the connection) |
| 08:39:10 | * | ninjin quit (Ping timeout: 264 seconds) |
| 08:39:50 | * | ninjin joined #nimrod |
| 09:03:38 | * | [1]Endy joined #nimrod |
| 09:06:46 | * | Endy quit (Ping timeout: 264 seconds) |
| 09:06:46 | * | [1]Endy is now known as Endy |
| 09:28:15 | * | BitPuffin joined #nimrod |
| 09:33:38 | * | zahary1 joined #nimrod |
| 09:35:15 | * | CarpNet joined #nimrod |
| 09:39:40 | * | zahary1 quit (Quit: Leaving.) |
| 09:45:10 | * | ninjin quit (Ping timeout: 264 seconds) |
| 09:45:24 | * | ninjin joined #nimrod |
| 10:01:22 | * | Endy quit (Ping timeout: 264 seconds) |
| 10:25:30 | BitPuffin | Araq: okay today I don't think I'll be tired as fuck so possibly I could try and do the thing you said and debug it :) |
| 10:25:57 | BitPuffin | at least that part because I also wanna play okami :P |
| 10:26:06 | Araq | BitPuffin: yay |
| 10:26:18 | Araq | okami only runs on macosx? |
| 10:26:58 | BitPuffin | Araq: lol no :P |
| 10:27:08 | BitPuffin | Araq: it runs on ps2, ps3 and Wii :P |
| 10:27:22 | BitPuffin | and it's amazing |
| 10:27:58 | Araq | looks like an LSD trip |
| 10:28:00 | BitPuffin | however probably not your style of game I'd imagine, but what do I know about your taste really |
| 10:28:03 | BitPuffin | hahaha |
| 10:28:06 | BitPuffin | no u |
| 10:28:08 | BitPuffin | kidding |
| 10:28:17 | BitPuffin | I like the art direction very much |
| 10:30:48 | BitPuffin | Araq: you seem to know a lot about LSD trips |
| 10:32:35 | BitPuffin | Araq: does include pose any requirements on the file extension of a file? |
| 10:32:44 | BitPuffin | by the looks of it it doesn't |
| 10:33:00 | Araq | dunno but .tmpl gets special treatment |
| 10:33:05 | BitPuffin | ah |
| 10:33:38 | BitPuffin | anyways I thought I'd put some cruft that people shouldn't include in a file like private.cruft |
| 10:33:49 | BitPuffin | which just contains nimrod, that is included by the binding |
| 10:34:53 | * | awestroke joined #nimrod |
| 10:41:39 | BitPuffin | Araq: hmm, seems like it would be really useful if there was a flag to c2nim to add importc to each function |
| 10:42:31 | Araq | #header ? |
| 10:42:36 | Araq | #dynlib ? |
| 10:42:43 | Araq | read the docs? |
| 10:42:47 | BitPuffin | Araq: ? |
| 10:44:16 | EXetoC | also, there's pragma push/pop |
| 10:44:29 | BitPuffin | EXetoC: which doesn't help |
| 10:44:46 | BitPuffin | Araq: well why is header discouraged? |
| 10:45:11 | BitPuffin | I always skipped looking at it because I was like, oh, discouraged, guess I don't care about what it does then |
| 10:46:17 | BitPuffin | damn it, this header uses the #if defined style instead of #ifdef |
| 10:47:13 | Araq | ask Discolod1 to improve c2nim then |
| 10:47:28 | * | Boscop_ joined #nimrod |
| 10:47:37 | EXetoC | BitPuffin: doesn't it, if you keep the original names? |
| 10:47:54 | * | zahary__ joined #nimrod |
| 10:48:00 | EXetoC | which some people think is a good idea for the actual 1:1 binding, but not everybody does it |
| 10:49:05 | BitPuffin | Araq: well I was just wondering why it's discouraged |
| 10:49:18 | BitPuffin | EXetoC: yeah but I don't keep the original names |
| 10:49:26 | BitPuffin | EXetoC: "some people" aka fowl |
| 10:50:04 | Araq | BitPuffin: I don't like to have the headers and import libraries around |
| 10:50:29 | Araq | the DLL should suffice and has not as many PATH related problems |
| 10:50:34 | * | zahary_ quit (Ping timeout: 264 seconds) |
| 10:50:34 | * | Boscop quit (Ping timeout: 264 seconds) |
| 10:51:43 | EXetoC | BitPuffin: ok what about #mangle? |
| 10:51:50 | BitPuffin | Araq: ah I see. So what you really think c2nim should be used for is actually compiling .c no .nim files and not .h at all? |
| 10:53:15 | Araq | er ... what? |
| 10:53:38 | BitPuffin | Araq: yeah like you want us to translate entire libraries to nimrod instead of headers? |
| 10:53:50 | Araq | it's about translating .h files into nimrod modules that bind to the C via dynlib |
| 10:53:58 | BitPuffin | oh yeah |
| 10:54:18 | BitPuffin | well I guess translating to nimrod to then be translated to c would be a bit off |
| 10:54:36 | Araq | a bit off perhaps, but very cool |
| 10:54:40 | BitPuffin | true |
| 10:54:56 | Araq | you get a type checker that's not stuck in the 70ies as a reward |
| 10:55:13 | BitPuffin | EXetoC: don't know shit about PEG stuff but it looks like learning it would save me a lot of time |
| 10:55:14 | BitPuffin | hrm |
| 10:55:21 | EXetoC | macros containing ## are not supported. you think it'll be easy to support? |
| 10:55:32 | BitPuffin | Araq: well I just meant that the .c files will become .c files anyway |
| 10:55:40 | BitPuffin | so why not just include them in the project somehow |
| 10:55:44 | * | aftershave quit (Ping timeout: 244 seconds) |
| 10:55:48 | EXetoC | gonna report that, and yeah that nimgrep issue too :p |
| 10:55:50 | BitPuffin | plus you aren't really supposed to touch libraries |
| 10:56:23 | BitPuffin | I'm still confused and curious as to what the actual fuck Demos was talking about |
| 10:56:39 | Araq | EXetoC: ## seems easy, true |
| 10:56:41 | BitPuffin | I guess I'll notice over the coming days |
| 11:00:49 | BitPuffin | linagl probably has aquired new errors with possible regressions in the compiler etc |
| 11:02:57 | EXetoC | that's likely. meanwhile, Demos seems to be doing well with his matrix interface using bleeding-edge features |
| 11:04:07 | BitPuffin | what kind of bleeding edge features? |
| 11:04:31 | * | awestroke quit (Remote host closed the connection) |
| 11:04:44 | BitPuffin | EXetoC: where is his matrix library thing? |
| 11:06:03 | BitPuffin | or what's his github account :P |
| 11:06:57 | NimBot | Araq/Nimrod devel 5d33bda Zahary Karadjov [+0 ±2 -0]: fix #988... 2 more lines |
| 11:08:10 | * | askatasuna joined #nimrod |
| 11:08:49 | EXetoC | or maybe I'm wrong |
| 11:09:44 | EXetoC | BitPuffin: maybe just static[T] at the time being http://build.nimrod-lang.org/docs/manual.html#static-t |
| 11:09:51 | EXetoC | but I don't remember him sharing anything yet |
| 11:10:20 | BitPuffin | ah right |
| 11:10:32 | BitPuffin | didn't he say he was gonna do a PR that uses it? |
| 11:10:37 | BitPuffin | I'll probably add it myself tbh |
| 11:11:35 | BitPuffin | maybe even today |
| 11:11:40 | BitPuffin | or like now |
| 11:11:46 | EXetoC | are you going to switch to devel then? |
| 11:12:41 | BitPuffin | oh this is on devel? |
| 11:14:01 | EXetoC | I'm pretty sure. Master was last updated a month ago |
| 11:14:33 | BitPuffin | once again git being a fucking retard |
| 11:14:41 | BitPuffin | anyway |
| 11:14:46 | BitPuffin | okay |
| 11:15:02 | BitPuffin | but hasn't static been around longer than a month |
| 11:15:42 | BitPuffin | looks like devel built this time yay |
| 11:16:06 | * | Endy joined #nimrod |
| 11:17:31 | EXetoC | I think it was broken/buggy before |
| 11:17:40 | BitPuffin | is zahary zahary__ here? |
| 11:18:04 | BitPuffin | I guess the protocol i ping but whatever |
| 11:18:29 | BitPuffin | we need to have a zahary pinger bot, since there is usually so many zaharies |
| 11:18:38 | * | zahary__ is now known as zahary_office |
| 11:18:48 | zahary_office | I'm here |
| 11:18:50 | BitPuffin | a sign of life! |
| 11:19:06 | BitPuffin | zahary_office: hey I was just wondering if generics can take other parameters than types and ranges yet |
| 11:19:30 | zahary_office | the latest in the devel branch have some pretty rough test cases for them |
| 11:19:46 | BitPuffin | that pass? |
| 11:19:50 | zahary_office | yep |
| 11:19:59 | BitPuffin | good incentive enough to try it out I suppose |
| 11:20:03 | BitPuffin | I'll report back in a sec |
| 11:24:14 | BitPuffin | hmm |
| 11:24:45 | BitPuffin | So putting static in a type signature doesn't let me not specify the value in a proc parameter? |
| 11:25:06 | zahary_office | what do you mean? |
| 11:25:08 | BitPuffin | ie with TVector*[T; D: static[int]] = array[0..D-1, T] |
| 11:25:31 | BitPuffin | I can't do proc `*.`*[T, I](a, b: TVector[T, I]): T {.noSideEffect.} = |
| 11:25:32 | BitPuffin | ? |
| 11:25:34 | BitPuffin | or oh |
| 11:25:44 | BitPuffin | I have to say static there too don't I? |
| 11:26:09 | zahary_office | I guess, I'll try to improve it - go for implicit generics for now |
| 11:27:24 | * | aftershave joined #nimrod |
| 11:27:34 | BitPuffin | got: (typedesc[T], static[typedesc[I]]) |
| 11:27:36 | BitPuffin | but expected: (T, D) |
| 11:27:38 | BitPuffin | that was the error btw |
| 11:27:42 | BitPuffin | proably relevant |
| 11:28:20 | BitPuffin | zahary_office: well I can't do proc `*.`*(a, b): a.type.T yet |
| 11:28:45 | BitPuffin | and (a, b: TVector): TVector.T doesn't work either |
| 11:30:24 | BitPuffin | lolwut |
| 11:30:39 | EXetoC | the first one is a shortcut, while the second one refers to a generic type that hasn't been instantiated, right? |
| 11:30:50 | BitPuffin | with: got: (typedesc[T], static[typedesc[I]]) |
| 11:30:52 | BitPuffin | but expected: (T, D) |
| 11:30:54 | BitPuffin | oops |
| 11:31:09 | BitPuffin | okay so that's what I get for: proc `*.`*[T, D: static[int]](a, b: TVector[T, D]): T {.noSideEffect.} = |
| 11:31:28 | zahary_office | here is what works for me: |
| 11:31:29 | zahary_office | https://gist.github.com/zah/9463398 |
| 11:31:30 | EXetoC | what about a.type.T or something? |
| 11:31:31 | BitPuffin | EXetoC: yeah, I assumed the second one wouldn't work either, anyways |
| 11:31:45 | EXetoC | hm |
| 11:31:58 | BitPuffin | 12:28:19 BitPuffin | zahary_office: well I can't do proc `*.`*(a, b): a.type.T yet |
| 11:32:00 | BitPuffin | EXetoC: ^ |
| 11:33:06 | EXetoC | It does seem a little magic, so I didn't expect it to work |
| 11:33:53 | BitPuffin | oh it worked |
| 11:33:58 | BitPuffin | just that I got the same error on another line |
| 11:34:00 | BitPuffin | doh |
| 11:36:05 | BitPuffin | zahary_office: hmm but now I am getting vector.nim(147, 15) Error: cannot evaluate at compile time: a |
| 11:36:27 | BitPuffin | for this proc: https://gist.github.com/BitPuffin/1bc3cb5f97c5372c551c |
| 11:36:32 | EXetoC | either (x, y: V): V.T == (x: V, y: V): V.T or the latter is now ambiguous, which is fine I guess but I think I prefer the 'type' approach |
| 11:37:03 | BitPuffin | EXetoC: none of them are ambiguous |
| 11:37:17 | BitPuffin | because TVector can only mean one thing in that context |
| 11:37:17 | EXetoC | does that assertion hold true then? |
| 11:37:21 | BitPuffin | yes |
| 11:37:23 | EXetoC | ok |
| 11:37:34 | EXetoC | fair enough |
| 11:37:42 | BitPuffin | ah I thought you said that one of them where ambigous, need to learn english |
| 11:38:58 | BitPuffin | EXetoC: anyways as far as I can understand it, when instantiating the proc, the TVector can only mean one thing at that time, so if you have type D[T] and have (x, y: D) you can't pass x[int] and y[float] |
| 11:39:05 | BitPuffin | their T need to match |
| 11:39:09 | BitPuffin | otherwise they aren't the same D |
| 11:39:14 | BitPuffin | so they get the D in the ass |
| 11:40:22 | BitPuffin | zahary_office: oh I see why it fails, not sure why it didn't fail before though, it can't know that $ is defined for all the T's for TVector |
| 11:40:31 | BitPuffin | however how the fuck do I assert that even |
| 11:41:14 | EXetoC | user-defined type classes :> |
| 11:41:49 | * | zahary_office left #nimrod (#nimrod) |
| 11:41:54 | BitPuffin | seems kinda overkill |
| 11:43:02 | BitPuffin | just for having a $ operator for a generic type |
| 11:43:38 | BitPuffin | also now I suddenly got the urge to create a currency converter library where if you use $ on a TCurrency you get the dollar value back JUST to fuck with nimrod convention |
| 11:44:27 | EXetoC | is T restricted? though I don't know if the compiler is smart enough to infer something based on that |
| 11:44:33 | BitPuffin | actually it would be a pretty sweet library. You would do c.€= 38 and then do $c and get the dollar val |
| 11:44:37 | EXetoC | to integral types that is |
| 11:45:13 | BitPuffin | EXetoC: well isn't it supposed to not compile only when $ isn't defined |
| 11:45:24 | BitPuffin | and I'm not using any time where $ isn't defined |
| 11:45:35 | BitPuffin | in fact it doesn't fail just by looking at the proc |
| 11:45:46 | BitPuffin | when evaluating the proc it's like aight fine, looks good |
| 11:45:58 | BitPuffin | but when I use it with a TVector[int, 3] it fucks out |
| 11:46:27 | BitPuffin | god I love being able to use TVector[int, 3] instead of TVector[int, range[0..2]] |
| 11:47:34 | BitPuffin | oh wow this error started happening everywhere |
| 11:47:38 | BitPuffin | well I guess that's a given |
| 11:47:39 | BitPuffin | hrm |
| 11:48:40 | * | zahary_office joined #nimrod |
| 11:48:49 | zahary_office | BitPuffin, https://gist.github.com/BitPuffin/1bc3cb5f97c5372c551c |
| 11:49:57 | * | psquid joined #nimrod |
| 11:50:14 | BitPuffin | zahary_office: well weird |
| 11:50:22 | BitPuffin | because non of my stuff seems to work |
| 11:50:30 | * | psquid_ quit (Ping timeout: 244 seconds) |
| 11:50:31 | BitPuffin | not $, or == |
| 11:50:39 | BitPuffin | I may aswell paste the whole file lol |
| 11:50:40 | zahary_office | where do you try to evaluate it at compile time |
| 11:51:00 | zahary_office | are you sure you are not trying to do it with a run-time variable? |
| 11:51:11 | BitPuffin | https://gist.github.com/BitPuffin/9463633 |
| 11:51:13 | BitPuffin | zahary_office: I am |
| 11:51:26 | BitPuffin | or what do you mean |
| 11:51:37 | BitPuffin | It's not a static[TVector] anywhere |
| 11:52:14 | BitPuffin | or is it going GPL on my ass saying that just because the generic parameter is static making the whole type having to be static? |
| 11:55:23 | zahary_office | no, I can't make sense of the error either |
| 11:55:51 | BitPuffin | so far 162, 163, 167, 168, 169, 173, 174 fails |
| 11:56:04 | BitPuffin | well, 174 fails because 173 fails |
| 11:56:09 | BitPuffin | so I can't test it properly |
| 11:56:25 | BitPuffin | zahary_office: it works for you? |
| 11:57:34 | zahary_office | nope |
| 11:57:46 | BitPuffin | ah |
| 11:57:52 | BitPuffin | well that's good-ish news at least |
| 11:59:33 | BitPuffin | removing the D-1 didn't do any good either |
| 11:59:42 | BitPuffin | so I can't see how it is any different from your code |
| 11:59:55 | BitPuffin | other than you naming it $$ |
| 12:00:12 | BitPuffin | which shouldn't be relevant at all |
| 12:00:52 | BitPuffin | well and you running the echo on compile time |
| 12:01:19 | BitPuffin | zahary_office: with the code that worked for you, does it still work if you don't do static: echo($$xx) and just do echo x instead |
| 12:02:24 | * | zahary_office left #nimrod (#nimrod) |
| 12:02:43 | * | zahary_office joined #nimrod |
| 12:03:35 | zahary_office | I think I figured it out, I'll fix it tonight |
| 12:03:50 | BitPuffin | zahary_office: what seems to be the problem? |
| 12:03:54 | zahary_office | watch out when I commit a fix for tsemistatic, it's related |
| 12:04:16 | BitPuffin | okay! |
| 12:04:18 | BitPuffin | sweet |
| 12:04:35 | BitPuffin | I'll refactor matrix.nim to be more up to date in the mean time |
| 12:04:43 | BitPuffin | will just hold off the commit until it actually compiles :P |
| 12:06:02 | BitPuffin | not having to use range[0..1] really shines through with TMatrix, wow, such nice |
| 12:22:04 | * | io2 joined #nimrod |
| 12:38:14 | BitPuffin | proc identity[T; D: static[int]](): TMatrix[T, D, D] {.noSideEffect.} = |
| 12:38:24 | BitPuffin | matrix.nim(22, 47) Error: internal error: cannot generate code for: D |
| 12:38:30 | BitPuffin | zahary_office: ^ :s |
| 12:39:09 | BitPuffin | guess static might not be available in generic params? |
| 12:39:31 | BitPuffin | for procs |
| 12:44:22 | BitPuffin | the docs don't mention that it works in generics for procs but they really should |
| 12:52:30 | * | Endy quit (Ping timeout: 244 seconds) |
| 13:03:06 | zahary_office | BitPuffin, static[int] as a regular param will work |
| 13:04:03 | zahary_office | but I would make the identity proc parametrized on the type |
| 13:04:03 | zahary_office | proc identity(T: type Matrix): Matrix = for i in 0 .. Matrix.N: result[i, i] = 1 |
| 13:04:29 | zahary_office | then, it can be used like this: Matrix4.identity |
| 13:09:13 | Araq | if type(Matrix) is the same as typedesc[Matrix] this needs to be documented |
| 13:24:18 | BitPuffin | zahary_office: problem is that if static[whatever] doesn't work as a generic parameter for a proc it is still gonna cause issues in many other places other than this |
| 13:24:35 | BitPuffin | and yes that's something I've considered too |
| 13:24:42 | BitPuffin | and might just do that |
| 13:24:47 | BitPuffin | but that's beside the point |
| 13:24:49 | zahary_office | proc foo(x: static[int]) # I meant that this should work |
| 13:25:07 | BitPuffin | right |
| 13:25:10 | zahary_office | I agree that proc foo[T, I] is broken, when I is static |
| 13:25:12 | BitPuffin | it only works as a parameter |
| 13:25:18 | zahary_office | I'll look into this tonight |
| 13:25:24 | BitPuffin | cool |
| 13:25:33 | * | awestroke joined #nimrod |
| 13:27:18 | BitPuffin | it breaks ~= as well: proc `~=`*[T, R, C](a, b: TMatrix[T, R, C], tolerance: float = 1.0e-5): bool {.noSideEffect.} = |
| 13:27:31 | BitPuffin | got: (typedesc[T], static[typedesc[R]], typedesc[C]) |
| 13:27:33 | BitPuffin | but expected: (T, R, C) |
| 13:27:58 | BitPuffin | Araq: they don't seem the same, it seems like one is a typedesc and one is a type |
| 13:28:06 | BitPuffin | makes me wonder why we should even have typedesc |
| 13:28:26 | BitPuffin | if type is a new thing that is the actual type maybe typedesc should be deprecated |
| 13:38:29 | * | askatasuna quit (Ping timeout: 252 seconds) |
| 13:41:49 | zahary_office | type Matrix is the same as typedesc[Matrix] indeed. I adopted this style, because people complain about the verbosity of typedesc |
| 13:41:49 | zahary_office | actually, maybe even this would work: proc foo(x: type, y: ...) |
| 13:53:50 | Trixar_za | We have an off topic channel now? |
| 13:54:51 | EXetoC | yes |
| 13:59:44 | * | darkf quit (Quit: Leaving) |
| 14:06:50 | BitPuffin | zahary_office: so why not deprecate typedesc then? |
| 14:07:24 | BitPuffin | if someone with an existing codebase whines about it it is their fault for using a non-stable language anyways |
| 14:07:32 | BitPuffin | such changes should be taken for granted |
| 14:07:35 | BitPuffin | I like my attitude |
| 14:07:37 | BitPuffin | brb lunch |
| 14:10:41 | EXetoC | not that many people will complain if there's a long deprecation period |
| 14:12:07 | EXetoC | after all, deprecated != removed |
| 14:12:31 | * | Endy joined #nimrod |
| 14:14:26 | * | zielmicha joined #nimrod |
| 14:35:43 | * | OrionPK quit (Ping timeout: 252 seconds) |
| 14:46:19 | Araq | Varriount: since you asked for work, add a special test that check nimrod still bootstraps with visual c++ |
| 14:48:56 | * | io2_ joined #nimrod |
| 14:49:35 | * | silven quit (Read error: Connection reset by peer) |
| 14:49:35 | * | io2 quit (Remote host closed the connection) |
| 14:51:34 | * | silven_ joined #nimrod |
| 14:57:24 | * | psquid quit (Quit: Math is hard, let's go shopping!) |
| 14:58:27 | * | awestroke quit (Quit: No Ping reply in 180 seconds.) |
| 15:02:19 | BitPuffin | EXetoC: exactly |
| 15:02:27 | BitPuffin | EXetoC: just a compiler warning that nags you until you get to it |
| 15:18:19 | * | askatasuna joined #nimrod |
| 15:19:50 | * | io2_ quit () |
| 15:43:18 | * | silven_ is now known as silven |
| 16:04:52 | * | nequitans joined #nimrod |
| 16:11:22 | nequitans | Hi all! Is there a way to convert a user-defined type to an openarray (e.g via a converter?) |
| 16:13:38 | nequitans | (e.g. i'd like to be able to use the 'sort' function in algorithms on my own type) |
| 16:13:49 | * | Demos joined #nimrod |
| 16:14:16 | NimBot | Araq/Nimrod devel 5fdbb4d Zahary Karadjov [+0 ±1 -0]: fix #971 |
| 16:18:29 | BitPuffin | nequitans: how do you mean convert to an openarray? |
| 16:18:46 | BitPuffin | nequitans: openarrays are only used for taking variable amount of args afaik |
| 16:18:53 | BitPuffin | you can't use them regularly in code |
| 16:18:58 | dom96 | hello |
| 16:19:07 | BitPuffin | if you want to store something in a variably sized array use a sequence |
| 16:19:08 | nequitans | BitPuffin, so I have my own version of a sequence object, but i'd like to use the standard sort function |
| 16:19:27 | BitPuffin | nequitans: so you it is a distinct sequence? |
| 16:19:35 | BitPuffin | s/you // |
| 16:19:50 | BitPuffin | heyo domboi |
| 16:19:52 | dom96 | nequitans: You may need to overload the sort function for your type then |
| 16:20:02 | nequitans | it's actually it's own type |
| 16:20:03 | dom96 | nequitans: btw, what ever happened to you making those corrections on your blog post? |
| 16:20:13 | BitPuffin | dom96: isn't it enough if he implements the comparisation procs? |
| 16:20:22 | BitPuffin | kind of like when you implement == you get != for free? |
| 16:20:23 | nequitans | dom96, yea, i'll get to that today, i had family in town all weekend :) |
| 16:21:02 | dom96 | BitPuffin: There should really be a type class called List or something. |
| 16:21:11 | BitPuffin | you like echo can take any object that implements $ |
| 16:21:14 | dom96 | The current sort implementation is not generic like that I don't think. |
| 16:21:35 | BitPuffin | why do I say you without any reason |
| 16:21:37 | dom96 | Only way you can convert to openarray is to convert to seq I guess |
| 16:21:43 | BitPuffin | It's like I'm on drugs |
| 16:21:45 | BitPuffin | you |
| 16:21:57 | dom96 | BitPuffin: Too much dota. |
| 16:22:02 | BitPuffin | hahaha |
| 16:22:11 | BitPuffin | actually it's been mostly CS:GO lately |
| 16:22:26 | BitPuffin | but I gues 262 hours of dota is a wee bit too much |
| 16:22:29 | dom96 | BitPuffin: I wanna play that with you! |
| 16:22:37 | dom96 | BitPuffin: Let me know when there is a CS: GO sale |
| 16:22:39 | BitPuffin | dom96: you wanna play with me? |
| 16:22:47 | dom96 | BitPuffin: Sure, why not. |
| 16:22:50 | BitPuffin | hot |
| 16:22:51 | BitPuffin | kidding |
| 16:22:56 | BitPuffin | no but why not just buy it as it is |
| 16:23:00 | BitPuffin | I was gonna wait for a sale too |
| 16:23:04 | BitPuffin | but it wasn't really that expensive |
| 16:23:08 | dom96 | Because i'm cheap |
| 16:23:14 | BitPuffin | probably because of it's F2P natures sometimes |
| 16:23:14 | dom96 | And I don't have time to play it NOW anyway |
| 16:23:25 | BitPuffin | well me neither because I'm not home yet |
| 16:23:42 | BitPuffin | but you should buy it within days |
| 16:23:56 | BitPuffin | 14 euros is not that much |
| 16:24:03 | BitPuffin | what's the price in the uck? |
| 16:24:05 | dom96 | It is to me. |
| 16:24:15 | dom96 | BitPuffin: If it's not that much then buy it for me :P |
| 16:24:25 | BitPuffin | I could |
| 16:24:47 | BitPuffin | but it's wasteful enough if I buy anything so probably not |
| 16:25:05 | BitPuffin | but I would if I wasn't doing terrbly but still my best to save up for moving |
| 16:27:44 | dom96 | well I will (hopefully) be starting uni soon. |
| 16:27:55 | dom96 | I can't just throw money around |
| 16:28:08 | dom96 | A new computer is looong overdue for me. |
| 16:28:48 | BitPuffin | dom96: yeah same here |
| 16:28:53 | BitPuffin | well not the uni part |
| 16:28:55 | BitPuffin | fuck that |
| 16:28:57 | BitPuffin | :P |
| 16:29:07 | * | aftersha_ joined #nimrod |
| 16:31:00 | Demos | can someone try and compile https://gist.github.com/barcharcraz/8bb9f8dd63230288d6b4? I want to make sure that it is actually a bug and my compiler is not just stale or something |
| 16:31:38 | BitPuffin | o/ Demos |
| 16:31:48 | Demos | hey |
| 16:31:51 | dom96 | nequitans: Let me know when you do it, reddit needs to experience your brilliant article :) |
| 16:32:04 | nequitans | kk -- i updated the blog post with some of the suggestions that i remembered |
| 16:32:14 | nequitans | any other things you guys can rememmber? additional helpful examples? |
| 16:32:37 | BitPuffin | Demos: locally linagl has been updated because I can finally enable the var bla: TMatrik[int, 3, 3] thing instead of ranges, and it uses static[T], just waiting for a bug or two to be fixed before I commit |
| 16:32:45 | nequitans | oh, let me get rid of the *s |
| 16:33:06 | Demos | yeah BitPuffin! I have been fooling with those as well, still have some real problems, like that gist I posted |
| 16:33:41 | BitPuffin | Demos: yeah there is issues with using them in generic parameters for procs |
| 16:34:39 | BitPuffin | like in your gist |
| 16:34:55 | dom96 | nequitans: http://build.nimrod-lang.org/irclogs/06-03-2014.html 19:12 |
| 16:35:06 | BitPuffin | brb go home |
| 16:35:21 | BitPuffin | Demos: zahary said he'd look at it tonight though |
| 16:35:24 | Demos | so I can define the `[]` proc but not `[]=` since var auto does not work, maybe I could say result = cast[var self.T](addr bla) |
| 16:36:39 | BitPuffin | I'm supposed to watch for semistatic commits, if you see one shout at me if I don't react |
| 16:36:42 | BitPuffin | brb |
| 16:36:43 | nequitans | dom96, thanks -- yea, i've been using that as a ref. I think I got everything except the logo change |
| 16:37:18 | dom96 | nequitans: Alright. Let's ask Araq when he gets here one last time before we reddit it |
| 16:37:19 | nequitans | filwit mentioned that he could provide a higher-res version that has the original dark background |
| 16:37:30 | nequitans | i was also thinking of adding a small paragraph |
| 16:37:37 | * | DAddYE joined #nimrod |
| 16:37:51 | nequitans | regarding memory allocation |
| 16:38:20 | dom96 | sure |
| 16:39:06 | dom96 | nequitans: perhaps you could use this: http://nimrod-lang.org/icons/logo.svg |
| 16:41:24 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 16:43:06 | * | icebattle quit (Quit: leaving) |
| 16:45:00 | * | icebattle joined #nimrod |
| 16:45:08 | nequitans | kk |
| 16:45:11 | nequitans | logo changed |
| 16:45:18 | nequitans | small para on memory added |
| 16:46:59 | nequitans | brb -- lunch |
| 16:47:05 | dom96 | awesome :) |
| 16:54:27 | * | Demos quit (Ping timeout: 265 seconds) |
| 17:03:26 | * | aftersha_ quit (Quit: Textual IRC Client: www.textualapp.com) |
| 17:04:39 | * | brson joined #nimrod |
| 17:05:49 | * | aftershave quit (Quit: Textual IRC Client: www.textualapp.com) |
| 17:06:08 | * | aftershave joined #nimrod |
| 17:34:32 | * | psquid joined #nimrod |
| 17:36:40 | EXetoC | dom96: *user-defined* type class, right? :p |
| 17:37:05 | EXetoC | a container interface is indeed an obvious candidate for this new feature |
| 17:37:50 | * | carum joined #nimrod |
| 17:49:08 | * | flaviu joined #nimrod |
| 17:49:10 | * | flaviu quit (Read error: Connection reset by peer) |
| 17:49:21 | * | carum quit (Remote host closed the connection) |
| 17:49:28 | * | flaviu joined #nimrod |
| 17:53:34 | shodan45 | I wonder if I could make a PHP "DSL" in nimrod |
| 17:53:45 | * | flaviu quit (Read error: Connection reset by peer) |
| 17:56:31 | shodan45 | and, if I did, how much sanity would I have afterward? |
| 17:57:06 | dom96 | EXetoC: What's the difference between writing "user-defined type class" and "type class"? |
| 17:57:34 | dom96 | Oh, I guess 'proc' is a type class. |
| 17:57:39 | dom96 | and it's not user-defined |
| 17:57:49 | dom96 | oh well. You know what I mean anyway. |
| 18:05:58 | * | XAMPP quit (Ping timeout: 240 seconds) |
| 18:08:24 | EXetoC | shodan45: if you must :p |
| 18:10:39 | * | io2 joined #nimrod |
| 18:38:40 | * | q66 joined #nimrod |
| 18:40:09 | Varriount | nequitans: Use a converter? |
| 18:40:21 | Varriount | Oh sory, was reading old logs. |
| 18:40:25 | Varriount | *sorry |
| 18:40:52 | nequitans | Varriout, np: yea was interested if I could easily adapt a user-defined type to an openarray since it is a special type |
| 18:48:46 | * | Matthias247 joined #nimrod |
| 18:49:03 | * | Matthias247 quit (Client Quit) |
| 18:50:18 | * | Matthias247 joined #nimrod |
| 18:53:43 | EXetoC | dom96: yeah sure |
| 18:54:17 | EXetoC | but someone suggested the name traits, which is short, common and not ambiguous |
| 18:55:31 | * | xtagon joined #nimrod |
| 18:55:32 | * | carum joined #nimrod |
| 18:56:34 | * | brson quit (Ping timeout: 264 seconds) |
| 19:03:06 | dom96 | EXetoC: the what? |
| 19:03:22 | * | brson joined #nimrod |
| 19:06:08 | Varriount | Araq: Nimrod fails to bootstrap with vcc - some bug in it's macro pre-processor causes a divide-by-zero error. |
| 19:09:00 | * | Varriount|Mobile joined #nimrod |
| 19:09:34 | * | flaviu joined #nimrod |
| 19:09:41 | * | flaviu quit (Client Quit) |
| 19:09:53 | Araq | nequitans: your can cast the underlying array to openArray, I think |
| 19:09:58 | * | flaviu joined #nimrod |
| 19:10:24 | * | flaviu quit (Client Quit) |
| 19:10:32 | nequitans | Araq, thanks -- i'll try that |
| 19:10:42 | dom96 | Araq: Can we reddit nequitans' article now? |
| 19:10:54 | Araq | I have to read it again |
| 19:10:57 | Araq | link? |
| 19:11:16 | Varriount|Mobile | Araq: What is 'koch temp' supposed to do when given options/arguments after the 'temp' command? |
| 19:11:29 | dom96 | Araq: http://geetduggal.wordpress.com/2014/03/03/consider-nimrod/ |
| 19:11:36 | Araq | Varriount|Mobile: pass them to nimrod, of course |
| 19:11:42 | dom96 | whoa, did Google just fail at its stylesheet or did the results page style change? |
| 19:12:55 | Varriount|Mobile | Araq: Do you mean, pass them as an argument to the nimrod executable compiling the temp compiler, or pass them to the built temp compiler? |
| 19:14:50 | Araq | pass them to built temp compiler |
| 19:15:26 | Araq | koch temp c temp.nim # compile temp.nim with nimrod_temp to see if the bug disappeared |
| 19:15:50 | Varriount|Mobile | So how would I influence the building of the temporary compiler itself? |
| 19:16:24 | EXetoC | dom96: UDTC -> traits |
| 19:16:47 | EXetoC | and "seq[int] is Container" is true, so time for some experimentation |
| 19:16:55 | * | Demos joined #nimrod |
| 19:18:34 | Araq | Varriount|Mobile: you can't with "koch temp" |
| 19:18:53 | Araq | you need to type in the particular instructions on your own |
| 19:21:18 | Araq | nequitans: "Nimrod also supports multiple dispatch which allows dynamic binding to variables." <-- no, it allows dynamic binding of methods |
| 19:22:52 | Araq | "Nimrod’s type system and compile-time checks may be all the ‘traits’ I really need" -- maybe but nimrod's effect system puts it ahead of Scala's type safety anyway. Afaik Scala is about to get an effect system though. |
| 19:24:16 | Araq | reactormonk: please correct me if you know more |
| 19:24:37 | nequitans | Araq, thanks -- will make those mods as soon as i have a chance |
| 19:24:57 | nequitans | scala also supports type classes, although it seems it implements them via traits |
| 19:25:55 | Araq | the difference afaict is in the defaults |
| 19:26:16 | Araq | can you invoke '+' on a generic unconstrained 'T'? |
| 19:26:23 | Araq | yes for nimrod, no for scala |
| 19:26:54 | nequitans | ic |
| 19:27:30 | Demos | who the hell thought it was a good idea to munge linker options as much as GCC does? |
| 19:27:32 | Demos | I mean honestly |
| 19:29:11 | Araq | nequitans: nimrod allows you do specify the T needs a '+', but is happy without these details, Scala requires it. |
| 19:30:57 | Demos | by default nimrod is "any type where all versions of the template compile" right? |
| 19:31:24 | Araq | not sure what you mean, but no |
| 19:31:37 | * | OrionPK joined #nimrod |
| 19:31:52 | Araq | by default nimrod is "who cares, I'll tell you at instantation time when it makes no sense" |
| 19:32:15 | Araq | "no need to write down twice that every field of obj requires a $ operator" |
| 19:32:17 | nequitans | Araq, interesting how do you specify that type T requires a '+'? (looking around in docs ...) |
| 19:32:53 | Demos | I posted an example where if you have two generics with the same name and you try and instantiate them with a type where one can compile and one can not you get an error |
| 19:33:22 | Araq | Demos: last time I looked at it, that was a bug |
| 19:34:03 | Demos | Oh, I was told that was just the way it worked. I thought the bug was that it still failed if you used typeclasses to constrain the types to only those that compile |
| 19:34:32 | Araq | zahary and me disagree on this :P |
| 19:36:24 | Demos | fwiw c++ agrees with you... |
| 19:37:09 | EXetoC | ok that's an insta-win |
| 19:37:50 | Araq | nequitans: http://build.nimrod-lang.org/docs/manual.html#user-defined-type-classes |
| 19:38:06 | Araq | and yes we know a release with these great features is overdue |
| 19:40:08 | * | BitPuffin joined #nimrod |
| 19:40:46 | Araq | Demos: what's the issue number for this? |
| 19:41:09 | Demos | #976 |
| 19:41:12 | nequitans | Araq, very interesting...thx |
| 19:41:21 | nequitans | brb |
| 19:41:50 | Demos | you can remove the typeclass constraints and it still fails |
| 19:42:48 | * | Puff joined #nimrod |
| 19:42:56 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 19:45:23 | Araq | so 'trait' instead of "user defined type classes" hmm? ping zahary, zahary_office |
| 19:46:59 | Demos | things called traits usually involve dynamic dispatch though right? |
| 19:47:23 | Araq | right |
| 19:47:44 | zahary | I think trait should be reserved for the meaning of "component" in component-entity systems - that's a nicer match for the term |
| 19:48:13 | zahary | metatype, protocol, interface, contract - these work as a synonims for the type classes |
| 19:48:20 | Araq | ok but since even I can't remember the names, they need to change :P |
| 19:48:30 | OrionPK | i like the word contract ;) |
| 19:48:44 | Araq | is it "type classes" vs "user defined type classes" currently? |
| 19:49:15 | zahary | the whole family of generic types is called "type classes" |
| 19:49:17 | EXetoC | zahary: ok well there's an issue for it |
| 19:49:26 | Demos | erm... dare I suggest "concept" |
| 19:49:41 | zahary | ah, yeah, concept as well |
| 19:49:48 | OrionPK | contract encapsulates the idea best imo |
| 19:50:07 | EXetoC | Demos: both static or dynamic in Rust, and static in C++ I think. maybe that's unusual |
| 19:50:16 | Demos | as far as I can tell our typeclasses are almost the same as concepts in c++ |
| 19:50:21 | * | carum quit (Remote host closed the connection) |
| 19:50:22 | EXetoC | and yes I know it's not a distinct feature in C++ |
| 19:50:27 | Araq | "generic" reads better than "contract" though, IMHO |
| 19:50:28 | zahary | I have some other planned features that will also make the user defined type classes a viable replacement for existential types (a.k.a. haskell-style type classes( |
| 19:50:32 | Demos | and c++ does not have anything called a trait, there are type traits but those are more compiler magic |
| 19:50:35 | zahary | so that's why I prefer to keep the name |
| 19:51:43 | dom96 | How about we call "user defined type classes" "type classes", and "type classes" "built in type classes"? |
| 19:52:07 | zahary | to explain the plans, you should remember that I've talked about a type class like "ConvertibleToString" as an alternative to the local conversion that we currently support |
| 19:52:08 | EXetoC | dom96: T|U|V |
| 19:52:16 | EXetoC | that's not really built in |
| 19:52:19 | EXetoC | type variants? |
| 19:52:41 | zahary | you say that "ConvertableToString" requires an $ operator and then you automatically invoke it everywhere where the type class is used as param |
| 19:52:45 | EXetoC | that feature is much older though |
| 19:52:58 | Demos | well T|U|V could be type Foo = generic x \n (x is T) or (x is U) or (x is V) |
| 19:52:59 | EXetoC | Convertible</pedantic> |
| 19:53:15 | zahary | I'm just explaining myself - that's not the real name |
| 19:53:40 | OrionPK | should there be a prefix for user defined type classes, for convention? |
| 19:53:46 | zahary | … now, the same logic can be applied to a type class called "MatchesDynamicInterface" that is automatically converted to a fat pointer carrying a Vtable |
| 19:53:55 | Demos | I like how typeclasses are implicit, I dont want to have to write like Enumerable, Frobable, Runnable, and so on everywhere |
| 19:53:57 | Araq | OrionPK: no we getting rid of prefixes. |
| 19:54:03 | OrionPK | I know that araq |
| 19:54:10 | zahary | and viola, you get existential types and dynamic binding without vtables stuck in the objects |
| 19:54:15 | OrionPK | but it makes sense for this case imo |
| 19:54:18 | EXetoC | Demos: they are often not aliased though (proc foo[T:x|y|z]) |
| 19:54:38 | OrionPK | the IPrefix of C# interfaces, helps keep things sane |
| 19:55:12 | Araq | OrionPK: it's better to look cute than to help the programmer |
| 19:55:20 | Demos | OrionPK: well I dont like haveing to list out all the interfaces I want to support, hurts interop as well |
| 19:55:22 | OrionPK | lol |
| 19:55:32 | EXetoC | and that's very common, so it would increase verbosity considerably |
| 19:56:01 | OrionPK | araq I dont think anyone would bitch at you for having a style guide that includes prefix for user defined type classes |
| 19:56:21 | OrionPK | but I guess there's always someone to bitch about everything |
| 19:56:24 | EXetoC | people always will |
| 19:56:42 | EXetoC | yeah you gotta measure the frequency :> |
| 19:58:13 | Araq | OrionPK: the type classes will all end in 'able' or similar, ToStringAble, Comparable, etc. |
| 19:58:28 | fowl | stringifyable |
| 19:58:44 | OrionPK | araq that seems like it would make things difficult to name |
| 19:59:03 | OrionPK | we'll see though |
| 20:00:58 | Demos | but then you have stuff like Container and SquareMatrix and whatnot |
| 20:01:11 | Demos | they define properties of the type, not really what you can do with it |
| 20:01:16 | Araq | zahary your plans align well with mine which are to ultimately get rid of 'method' |
| 20:01:49 | zahary | well, that's still single-dispatch mechanism |
| 20:02:24 | Demos | I have been finding that it is actually easy to just use function pointers (closures whatever) when I really need dynamic dispatch. I am sure methods are great for some things though |
| 20:02:52 | zahary | but the double dispatch is surely generetable in user space too |
| 20:03:01 | Araq | Demos: yeah and they play somewhat nicer with the effect system |
| 20:03:26 | reactormonk | Araq, monads are kinda effects |
| 20:03:45 | EXetoC | Demos: I don't know if it's that important to differentiate between that and normal types. So perhaps you can just use your judgement and append "Trait" when necessary |
| 20:03:46 | * | Demos remembers writing a visitor, never again |
| 20:04:18 | Demos | I dont think it is important either, I like the way typeclasses are currently implicit |
| 20:04:31 | EXetoC | Comparable is alright, but ToStringAble is kinda ugly imo |
| 20:04:51 | Demos | could be something like Convertable[string] |
| 20:05:23 | fowl | EXetoC, stringifyable |
| 20:05:51 | Araq | yeah stringifyable is better |
| 20:06:08 | reactormonk | there's string as in serialize and there's string as in display |
| 20:06:18 | reactormonk | so I'm for serializable and displayable |
| 20:06:38 | Demos | I think I will probably end up writing most of my generic code without typeclass constraints and add them as needed to improve the interface and errors |
| 20:06:48 | fowl | string isnt the right structure to use for serializing |
| 20:06:52 | fowl | \0 allowed and all |
| 20:06:55 | reactormonk | Araq, according to the scala channel, there are none planned |
| 20:07:05 | fowl | seq[byte] works better |
| 20:07:22 | reactormonk | fowl, so any `$` operator is inheritly non-parseable? |
| 20:07:39 | Demos | again, we should make sure to keep the typeclass system from getting verbose and explicit |
| 20:07:52 | dom96 | What does Haskell call its Stringifyable type class? |
| 20:07:56 | dom96 | display or something? |
| 20:08:08 | fowl | reactormonk, nobody uses $ for serializing |
| 20:08:08 | * | dom96 doesn't like Stringifyable |
| 20:08:19 | EXetoC | fowl, Araq: ok that's fine I guess |
| 20:08:21 | reactormonk | fowl, good. |
| 20:08:43 | reactormonk | fowl, imho it should generate nimrod code though |
| 20:08:45 | Demos | dom96: show I think |
| 20:09:01 | fowl | reactormonk, wat |
| 20:09:35 | dom96 | Perhaps it would make sense to call our type classes something like "Show" without the 'able' suffix? |
| 20:09:38 | Araq | zahary yeah I now want the classic dispatchTable[a.id * 10 + b.id](a, b) but generated via macros |
| 20:09:53 | reactormonk | fowl, `$` of an object should give you the nimrod literal corresponding to that object |
| 20:10:16 | fowl | reactormonk, then $ on a string "foo" gives you "\"foo\"" ? |
| 20:10:17 | Demos | reactormonk: we are not homoiconic so storing stuff as nimrod code is kinda pointless |
| 20:10:58 | Demos | reactormonk: I do not agree, I think $ is allowed to destroy information |
| 20:11:25 | reactormonk | Demos, example? |
| 20:11:27 | reactormonk | fowl, yup |
| 20:12:04 | zahary | Araq, yes, that's how it's going to work - you use a macro in the type section - it generates the "fat pointer" abstract value type, generates proc working on that type that use the dispatch table and finally, it generates a user defined type class that populates the table |
| 20:12:54 | zahary | in the second sentence, procs should be plural |
| 20:13:05 | * | skyfex joined #nimrod |
| 20:13:06 | EXetoC | reactormonk: countless types, including things like euclidean vectors |
| 20:13:10 | Demos | like if I print a color I may output rgb values "0"-"255" but the color may not be RGB |
| 20:13:24 | EXetoC | "allowed" or not, that's the way it has been used in general |
| 20:13:26 | zahary | I'll have to add support for nkStmtListTy or something |
| 20:13:32 | Demos | or it may not be 8_8_8 RGB |
| 20:13:39 | dom96 | Also, wouldn't it be more clear to just use $ on a generic instead of creating some "Stringifyable" (oh god this is too hard to type, please don't choose this name) type class? |
| 20:13:50 | Araq | zahary that already exists |
| 20:13:58 | reactormonk | Demos, the idea is to get a literal that produces the same object, however it may be |
| 20:14:06 | zahary | ah, will check it out then when I get to there |
| 20:14:13 | Demos | and `$` should not do that |
| 20:14:20 | dom96 | reactormonk: if anything repr should do that. |
| 20:14:23 | reactormonk | dom96, let's just go for haskell and call it `show` |
| 20:14:25 | * | Puff quit (Read error: Operation timed out) |
| 20:14:27 | EXetoC | dom96: Conv[string]? |
| 20:14:30 | reactormonk | dom96, ok. |
| 20:14:40 | Demos | if I serialize a int16 as "4" how am I supposed to know it is an int16? |
| 20:14:45 | Araq | nkStmtListType, # a statement list ending in a type; for macros |
| 20:14:45 | reactormonk | conv[string] is good too imho |
| 20:14:56 | reactormonk | Demos, ok, I see your point. |
| 20:15:04 | dom96 | Personally I don't think this needs a type class. |
| 20:15:08 | Araq | exists since forever, but I don't think it has been tested :P |
| 20:15:09 | Demos | also produceing a real "object" at runtime is probably possible, but extremely hard. |
| 20:15:42 | dom96 | EXetoC: ConvertsTo[string] ? |
| 20:16:06 | Demos | and produceing a real object at runtime would make it hard to do dead code elim |
| 20:16:38 | Demos | so you do not even want like "pickle" style serialization |
| 20:16:43 | fowl | CONFLICT (content): Merge conflict in compiler/ropes.nim |
| 20:16:55 | fowl | guess i gotta delete nimrod and check it out again |
| 20:16:56 | fowl | thanks, git |
| 20:17:08 | dom96 | How would that work with other types? There is no way to check if a proc exists with a signature such as: proc (x: MyType): int which would be required for ConvertsTo[int]. |
| 20:17:17 | dom96 | Unless you just check if MyType.int compiles. |
| 20:17:23 | EXetoC | dom96: wasn't easy-to-type part of the argument? :p |
| 20:17:53 | dom96 | EXetoC: ConvertsTo is easy to type. It's a bit long but it's still easier to type than Stringifyable |
| 20:17:57 | fowl | dom96, var x: T; x = value |
| 20:18:03 | * | flaviu joined #nimrod |
| 20:18:28 | reactormonk | zahary, cool bugsquash spree |
| 20:18:51 | dom96 | fowl: git reset --hard origin/devel |
| 20:19:31 | dom96 | fowl: But don't do it if you have made changes. |
| 20:19:39 | dom96 | fowl: Unless you don't care about keeping them. |
| 20:19:44 | fowl | ty |
| 20:20:27 | flaviu | You'll still have them if you've sent a pull request though |
| 20:20:49 | * | fowl sends all his PRs through the web interface |
| 20:21:10 | dom96 | or if you pushed your changes, but you wouldn't have if you have conflicts :P |
| 20:23:02 | EXetoC | fowl: You don't want to? I found this https://github.com/stephencelis/ghi |
| 20:23:53 | Araq | zahary what about bug #976 ? looks like a simple 'is' bug to me |
| 20:24:24 | Araq | proc take[T: int2g](vale: int2) = |
| 20:24:25 | Araq | when T is int1: # how can that ever be true? |
| 20:24:27 | Araq | static: error("killed in take(int2)") |
| 20:25:49 | zahary | T here is not the input type, but something that he passed as a parameter |
| 20:26:16 | Araq | argh |
| 20:26:30 | Araq | I missed that |
| 20:26:35 | zahary | it should return false indeed, because the type class is unbounded (it includes other types besides int) |
| 20:26:54 | * | samaryan quit (Remote host closed the connection) |
| 20:26:59 | zahary | but there are at least 3 other things that are not supported here :) |
| 20:27:34 | Araq | you need a blog and write about type classes |
| 20:28:10 | zahary | I'll write an articles about the generics system after I add the mimic types - I'll attack the C++ community with it |
| 20:29:29 | Araq | I don't think that's a wise idea ;-) mimic types are inherently unsound |
| 20:29:37 | * | Endy quit (Ping timeout: 240 seconds) |
| 20:30:28 | Demos | mimic types also mean that you need full source for all libraries, which honestly is usually true in any case but still |
| 20:30:38 | zahary | I think the idea that "every function is generic" will resonate well with some people |
| 20:30:58 | Demos | mimic types are more than that though |
| 20:31:04 | Demos | right? |
| 20:31:19 | flaviu | Google turns up nothing on mimic types, is there another query I should try? |
| 20:31:30 | Araq | and everything that is unsound is BAD for marketing |
| 20:31:34 | zahary | they are just a means to achieve this goal |
| 20:31:35 | Demos | since you can relax the generic type constraints from anywhere |
| 20:31:58 | Demos | flaviu: I think they allow you to make a proc generic at the callsite |
| 20:32:25 | Demos | so if you have proc(x: float): int you could call it with an int and it would be as if the proc was generic |
| 20:32:44 | zahary | that's not a particularly good example |
| 20:32:55 | flaviu | That sounds neat, sort of like structural typing? |
| 20:33:00 | zahary | if you have a proc like boyerMooreSearch(x: string, y: string) |
| 20:33:32 | zahary | you can call it with boyerMooreSearch(MyCopyOnWriteString) |
| 20:34:19 | Araq | zahary we can implement them and mark them experimental and be defensive as in "we know they have inherent problems but they solve an important real world problem" |
| 20:34:44 | Araq | but I don't think we can market them as a killer feature this day and age |
| 20:35:03 | Araq | in 10 years perhaps when people realized "correctness" is not a boolean property |
| 20:35:12 | * | BitPuffin joined #nimrod |
| 20:35:38 | zahary | I don't see them as particularly unsound - you can shoot yourself in the foot, but there is plenty of code written against the stable interfaces of types you can imitate easily |
| 20:36:40 | zahary | but, they surely belong in the "and finally, if that's not enough…" section |
| 20:38:46 | zahary | your thinking about tyProxy got you to imagine how if we follow the code all-the-way down, we get to ugly implementation details |
| 20:38:49 | * | Demos quit (Ping timeout: 252 seconds) |
| 20:39:18 | flaviu | Wouldn't it be better to have the programmer specify what functions he wants that feature on? |
| 20:39:26 | zahary | but mimic types don't do that - after you instantiate the generic, it will get back to your code as soon as there is a call to proc that you are implementing yourself |
| 20:39:33 | Araq | flaviu: that defeats the purpose |
| 20:40:06 | Araq | zahary I see |
| 20:40:28 | Araq | it's still very fragile, or perhaps not |
| 20:40:57 | zahary | as I said, it's pretty safe with code that is already using the public interface of something |
| 20:41:16 | Araq | if boyerMoore makes usage of a new helper proc, the instantation process will look into that as well and it will continue to work ... hmm |
| 20:42:39 | Araq | flaviu: the default needs to be "open for mimic types", we could introduce a "closed for mimic types" pragma but for now I can't see the value in that |
| 20:42:55 | Araq | conservative people will start to use it everywhere and moan about the verbosity |
| 20:42:55 | flaviu | `proc `*`(a,b) = if(b==0): 0 else: a*(b-1)` as the decleration |
| 20:42:55 | flaviu | Then the programmer can pass in anything for a that supports multiplication with a b, and anything for b that supports substraction |
| 20:43:31 | Araq | flaviu: that works already with exactly this syntax |
| 20:43:32 | flaviu | "a a", not "a b" |
| 20:43:54 | Araq | well you forgot the 'auto' return type |
| 20:44:17 | flaviu | oh, I didn't think of checking the irc logs |
| 20:44:37 | nequitans | I modded the blog post to incorporate Araq's most recent suggestions |
| 20:45:12 | dom96 | What would the syntax be for these mimic types? Surely there would be an operator which would tell the compiler "I want a mimic type here" right? |
| 20:45:39 | zahary | you postulate that your types mimics another type |
| 20:45:49 | zahary | the first version will be ugly on purpose and it will use a pragma |
| 20:45:59 | zahary | {.mimic: my_string is string.} |
| 20:47:15 | zahary | generic types are also allowed here. you can say |
| 20:47:15 | zahary | {.mimic: bitset is seq[bool].} |
| 20:47:22 | zahary | or myarray is seq |
| 20:49:56 | * | Demos joined #nimrod |
| 20:49:56 | * | Demos quit (Client Quit) |
| 20:50:41 | * | carum joined #nimrod |
| 20:51:02 | * | Tuned joined #nimrod |
| 20:51:31 | * | Demos joined #nimrod |
| 20:51:37 | Tuned | Is multiple inheritance planned for Nimrod in the future? |
| 20:54:56 | Demos | Probably not Tuned. MI is not a very good idea |
| 20:55:06 | flaviu | Tuned: I think you're looking for type classes: http://build.nimrod-lang.org/docs/manual.html#user-defined-type-classes |
| 20:55:22 | Demos | there is a lot of stuff that c++ does behind the scenes to make MI and esp virtual inheratance work |
| 20:56:18 | Araq | Tuned: I'm not opposed to MI but it's lots of work and we have much more important things to do |
| 20:56:52 | Araq | MI won't come before 1.0 is out |
| 20:57:14 | Demos | how would MI work with miltimethods? |
| 20:57:29 | Demos | actually hold that I gotta go |
| 20:58:40 | Araq | MI with multi-methods is a solved problem |
| 20:58:52 | Tuned | Would it be too hard if it was just implemented for the C++ compiling and not C? |
| 20:59:37 | Araq | Tuned: the C++ target doesn't help much, the type checker needs to be taught that an object can have multiple direct parents |
| 21:01:07 | Araq | nequitans: 'zeros' is not necessary, alloc uses newSeq which initializes to 0 for you |
| 21:01:56 | * | Demos quit (Ping timeout: 265 seconds) |
| 21:02:40 | Araq | "also In addition, Nimrod also supports an effects system which allows for additional compile-time safety checks." |
| 21:02:56 | Araq | <-- "addition" used twice |
| 21:04:22 | * | BitPuffin quit (Ping timeout: 244 seconds) |
| 21:06:22 | nequitans | Araq, post updated |
| 21:07:42 | Araq | nequitans: I still think you should use (a: Matrix) instead of [T](a: Matrix[T]) |
| 21:07:43 | nequitans | i am *this* close to doing static blog post generation |
| 21:07:56 | nequitans | kk |
| 21:08:05 | Araq | use ipsum genera, it's written in nimrod |
| 21:08:20 | Araq | then you can say even this blog post has been created with nimrod |
| 21:09:23 | nequitans | lol, noted. I'm changing a buch of " to actual quotes now -- it's 2014, and this is happening :) |
| 21:09:37 | zahary | nequitans: where is your blog, btw? |
| 21:09:58 | nequitans | it's hosted by wordpress.com |
| 21:10:00 | flaviu | zah: http://geetduggal.wordpress.com/author/nequitans/ |
| 21:12:25 | Tuned | is := part of syntax in Nimrod? I was thinking for var a = 10, a := 10 could be a simpler way to do the same. |
| 21:12:42 | flaviu | Tuned: Make a template for it |
| 21:13:02 | nequitans | Araq, for proc `[]`[T](A: Matrix[T], r,c: int): T, is there away to avoid using the T, or are you suggesting it just for the overall matrix type |
| 21:14:36 | flaviu | Tuned: template `:=`(name:expr, value: expr): stmt = var name = value |
| 21:14:46 | flaviu | nimrod now had syntax that does exactly that |
| 21:15:27 | zahary | nequitans: that would be proc `[]`(A: Matrix; r,c: int): Matrix.T |
| 21:15:50 | Araq | flaviu: you need to make that template 'dirty' |
| 21:16:09 | nequitans | zahary, thx |
| 21:16:22 | Araq | and 'immediate' |
| 21:17:01 | nequitans | so everytime i want to refer to the matrix's type, I just say Matrix.T |
| 21:17:52 | Araq | yeah |
| 21:18:52 | Araq | nequitans: instead of for i in 0 .. A.nrows-1 |
| 21:19:08 | Araq | for i in 0 .. <A.nrows is more idiomatic |
| 21:19:13 | dom96 | nequitans: Would you be able to make the nimrod logo a hyperlink to the nimrod site? |
| 21:19:52 | EXetoC | linalg for all |
| 21:22:20 | nequitans | dom96, sure |
| 21:23:18 | * | Demos joined #nimrod |
| 21:23:54 | NimBot | Araq/Nimrod devel a3ca0d2 Araq [+0 ±1 -0]: minor additions to the manual |
| 21:23:54 | NimBot | Araq/Nimrod devel 54881b0 Araq [+1 ±2 -0]: osproc compiles again for haiku |
| 21:23:54 | NimBot | Araq/Nimrod devel 3a60d33 Araq [+5 ±29 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 21:24:00 | nequitans | Araq, noted. zahary, i'm getting some compile time errors when changing the code to: proc `[]`(A: Matrix; r,c: int): Matrix.T like this uniformly everywhere |
| 21:24:34 | Araq | nequitans: do you use the devel version of the compiler? |
| 21:24:52 | nequitans | ah, yea, i just switched machines that has a non-devel |
| 21:25:18 | Araq | great that you check the code compiles |
| 21:25:25 | Araq | wanted to tell you that :P |
| 21:25:46 | Araq | you should also submit your code to tests/showoff so that it keeps working |
| 21:26:21 | Araq | we're plagued by regressions unfortunately |
| 21:26:54 | nequitans | kk |
| 21:28:53 | * | filwit joined #nimrod |
| 21:35:45 | nequitans | I noticed the user defined classes are in the build.nimrod-lang.org -- should I avoid mentioning this in the post (was thinking about it)? |
| 21:38:26 | Tuned | iff should be if, small typo "A type a is implicitly convertible to type b iff the following algorithm returns true:" http://build.nimrod-lang.org/docs/manual.html |
| 21:38:58 | Tuned | biff sounds a bit aggressive. |
| 21:39:17 | dom96 | No, that's not a typo. |
| 21:39:50 | EXetoC | Tuned: iff means "if and only if" |
| 21:48:58 | fowl | how big of a job is fixing all the case sensitive stuff |
| 21:51:41 | fowl | compiler/vm.nim(718, 44) Error: type mismatch: got (PNode, PType, seq[TFullReg], range 1..256(int), range -1..254(int), TLineInfo) |
| 21:54:08 | Araq | fowl: nimrod pretty does it |
| 21:54:49 | * | Discolod1 left #nimrod (#nimrod) |
| 21:59:46 | Varriount|Mobile | nequitans: Or add a link to the build docs |
| 22:00:23 | nequitans | Varriount|Mobile, the version up right now does exactly that |
| 22:01:43 | fowl | Araq, i get that error on devel |
| 22:05:13 | * | filwit quit (Quit: Leaving) |
| 22:06:07 | Araq | fowl: nimbuild disagrees with you |
| 22:06:20 | Araq | and ofc it compiles on my machine too |
| 22:07:55 | * | filwit joined #nimrod |
| 22:12:50 | * | BitPuffin joined #nimrod |
| 22:13:00 | BitPuffin | oi |
| 22:13:17 | BitPuffin | Araq: got stuck doing some data recovery stuff which just ate up way too much time so I'm gonna have to postpone :( |
| 22:13:35 | * | filwit quit (Quit: Leaving) |
| 22:15:19 | * | filwit joined #nimrod |
| 22:16:09 | * | Tuned quit (Remote host closed the connection) |
| 22:17:57 | * | carum quit (Remote host closed the connection) |
| 22:21:24 | nequitans | the compile times in nimrod are wicked fast |
| 22:22:58 | * | Demos quit (Ping timeout: 264 seconds) |
| 22:25:17 | Varriount | nequitans: And don't require autotools! |
| 22:25:53 | nequitans | When I first started playing w/ Nimrod, I was also impressed at how fast the lang compiled. Nobloat. |
| 22:35:18 | dom96 | Are we redditing then!? |
| 22:37:54 | fowl | ok |
| 22:38:02 | fowl | it must be broken then |
| 22:38:06 | * | carum joined #nimrod |
| 22:38:36 | * | DAddYE quit (Remote host closed the connection) |
| 22:40:19 | * | DAddYE joined #nimrod |
| 22:47:41 | nequitans | dom96, i'm cool w/ it if others are :) |
| 22:49:51 | dom96 | Araq: well? |
| 22:59:48 | NimBot | Araq/Nimrod devel 9879ecb Zahary Karadjov [+0 ±4 -0]: fix tsemistatic |
| 22:59:48 | NimBot | Araq/Nimrod devel a262a92 Zahary Karadjov [+1 ±3 -0]: Merge branch 'devel' of github.com:Araq/Nimrod into devel |
| 22:59:56 | flaviu | nequitans: Line 5 under *Quick start with Nimrod* has a minor bug, the error code can be anything but 0, not just 1 |
| 23:00:18 | nequitans | flwit, thanks |
| 23:01:01 | nequitans | i'm headed out, but will be online l8r |
| 23:02:11 | Araq | nequitans: it's good |
| 23:02:26 | * | io2 quit () |
| 23:08:17 | * | darkf joined #nimrod |
| 23:12:28 | fowl | Araq, i get the same error on a fresh repo |
| 23:15:35 | Araq | fowl: my vm.nim:718 contains if newValue.kind != nkEmpty: |
| 23:15:48 | Araq | ah, do you compile with -d:useFFI ? |
| 23:15:58 | Araq | that might indeed be broken right now |
| 23:16:42 | fowl | yea |
| 23:17:00 | fowl | thx |
| 23:29:04 | * | nande joined #nimrod |
| 23:45:21 | * | carum quit () |
| 23:48:06 | dom96 | well i'm away to sleep. |
| 23:48:35 | dom96 | nequitans: You can reddit it if you want, but maybe it would be better to wait until tomorrow. |
| 23:48:40 | dom96 | 'night |
