| 00:04:25 | * | seubert joined #nimrod |
| 00:18:29 | * | lanior joined #nimrod |
| 00:23:23 | BitPuffin | Demos_: why column major? |
| 00:23:30 | BitPuffin | doesn't make any difference what so ever |
| 00:23:44 | BitPuffin | other than forcing you to write all the equations backwards |
| 00:24:10 | Demos_ | I know. But that is how have been keeping everything. And no, if I write ABx I expect A(Bx) not (AB)x |
| 00:24:13 | BitPuffin | but yeah there is no extra data stored in any thing |
| 00:24:28 | * | skyfex quit (Ping timeout: 246 seconds) |
| 00:24:35 | BitPuffin | Demos_: well row major is more intuitive |
| 00:24:35 | Demos_ | col major has nothing to do with multiplication order |
| 00:24:50 | Demos_ | not for me. |
| 00:24:53 | BitPuffin | but yeeah I have considered adding so that majorness is a parameter |
| 00:25:03 | BitPuffin | well for you it's not about intuition |
| 00:25:06 | BitPuffin | it's about habit |
| 00:25:09 | Demos_ | I mean not a big deal, you can transpose when you send it to the GPU |
| 00:25:19 | BitPuffin | wat |
| 00:25:19 | Demos_ | true |
| 00:25:24 | BitPuffin | you don't need to transpose shit |
| 00:25:43 | Demos_ | yeah you do, unless you tell your GPU that the stuff coming in is row major |
| 00:25:55 | BitPuffin | well, unless you write your operations backwards in the shaders |
| 00:25:57 | BitPuffin | then yeah |
| 00:26:00 | BitPuffin | you need to transpose |
| 00:26:15 | BitPuffin | well you need to tell the GPU how they are coming in anyway |
| 00:26:19 | Demos_ | if you write A * B * x where A,B are mats and x is a vec what do you expect |
| 00:26:21 | BitPuffin | otherwise it won't know how to store them |
| 00:26:44 | BitPuffin | well the point is, if you write x * A * B in your shader and on the client you don't need to transpose |
| 00:26:51 | BitPuffin | the GPU will still need to know how to store them though |
| 00:26:53 | * | skyfex joined #nimrod |
| 00:26:57 | BitPuffin | because each GPU stores them different |
| 00:27:10 | BitPuffin | got nothing to do with GL being col major or anything, that's bullshit legacy talk |
| 00:27:13 | Demos_ | both opengl and direct3d will assume colmajor storage unless you prod them |
| 00:27:28 | BitPuffin | pretty sure d3d assume row major |
| 00:27:32 | Demos_ | nope |
| 00:27:37 | BitPuffin | although I haven't used it but so I hear |
| 00:27:55 | BitPuffin | either way, some GPUs store row major and some store col major |
| 00:27:56 | Demos_ | d3d9 does, I think 10 (or maybe 11) is colmajor with a pragma like thing if you want row majorness |
| 00:28:10 | BitPuffin | there is no advantage in terms of performance to picking one |
| 00:28:20 | BitPuffin | because the GPU will transpose to its internal storage anyway |
| 00:28:37 | BitPuffin | and unless you know what hardware you are working with exactly on all deices it's gonna run on there is no win in col major |
| 00:28:38 | Demos_ | well for me it is just that I want everything following one convention |
| 00:28:43 | BitPuffin | only harder to write literals |
| 00:29:05 | BitPuffin | well what's stopping you if you use row major in shaders and in client code |
| 00:29:06 | BitPuffin | ? |
| 00:29:11 | BitPuffin | then it is the same convention |
| 00:30:49 | BitPuffin | look if you check the PAST of linagl you'll see that it used to be col major |
| 00:30:57 | Demos_ | nothing I guess, just habit. I was rewriteing some c++ code that used eigen with colmajor storage, and I did not want to change anything to reduce bugs. Besides linagl failed to compile so I had to write my own anyways |
| 00:31:06 | xenagi | BitPuffin, what's Nimrod's GPU support (OpenCL, CUDA, etc..) |
| 00:31:07 | BitPuffin | because I had gotten the wrong idea that it was better |
| 00:31:12 | xenagi | :P |
| 00:31:36 | BitPuffin | but then I realized that the only thing that changes in reality is the code order |
| 00:31:43 | BitPuffin | and it reads more like the rest of the code with the row major way |
| 00:31:56 | BitPuffin | and I can write vectors in code more easily |
| 00:32:12 | Demos_ | Eigen uses some horrable operator,() overloading to make initialization look good... |
| 00:32:48 | BitPuffin | Demos_: I mean when you write a vector literal then it's basically a row vector, so why wouldn't you wanna have it like that, makes it more readable, instead of writing it as a row in code, since nothing else is possible without enormous pain and then pretending it is a column |
| 00:32:55 | BitPuffin | xenagi: we have opengl |
| 00:33:00 | xenagi | :O |
| 00:33:06 | BitPuffin | xenagi: don't think there is CL or CUDA, but if you wanna bind it that would be sweet |
| 00:33:12 | * | xenagi is googling |
| 00:33:32 | BitPuffin | Demos_: yeah again, linagl is just a few bugs away from its next release |
| 00:33:33 | xenagi | BitPuffin, I am very interested in porting CUDA to Nimrod, but I'm lightyears from that :P |
| 00:33:36 | BitPuffin | which makes it a lot nicer to use |
| 00:33:40 | xenagi | binding* |
| 00:33:42 | xenagi | not porting lol |
| 00:33:48 | BitPuffin | xenagi: haha was just about to correct you :P |
| 00:33:57 | BitPuffin | it's not that difficult |
| 00:33:57 | Demos_ | it /is/ convention, and I choose colmajor. I guess changeing it all would be less pain that sorting out all my hadedness issues was |
| 00:34:11 | BitPuffin | Demos_: it's not convention |
| 00:34:12 | Demos_ | BitPuffin: compiler bugs? |
| 00:34:29 | BitPuffin | some graphics books use col major, some use row |
| 00:34:37 | Demos_ | but /that/ is convention |
| 00:34:50 | BitPuffin | I get used for both for literature and then use what looks best in code, ie row |
| 00:34:52 | Demos_ | storage order is not quite the same as the representation when you print the vector |
| 00:35:04 | BitPuffin | Demos_: well there is no storage convention either |
| 00:35:07 | BitPuffin | that's just a lie |
| 00:35:21 | Demos_ | if I have a vec3 I really prefer to see a column "printed" even though the storage is the same no matter what |
| 00:35:33 | BitPuffin | you might say "well legacy GL stored it col major" and then yeah maybe it told you it did but internally it might have been row major |
| 00:35:54 | Demos_ | I dont really give a shit about legacy openGL |
| 00:35:55 | BitPuffin | well it's really when you do matrices it starts to differ |
| 00:35:59 | BitPuffin | me neither |
| 00:36:00 | Demos_ | yeah |
| 00:36:04 | BitPuffin | so why are you saying it's convention |
| 00:36:13 | BitPuffin | only legacy GL brainwashed people think that |
| 00:36:17 | BitPuffin | and they are wrong even then :P |
| 00:36:24 | BitPuffin | but if it makes you happy |
| 00:36:41 | BitPuffin | when you multiply a vector like m*v, v is interpreted as a col |
| 00:36:45 | BitPuffin | just like glsl |
| 00:37:05 | BitPuffin | just that the projection matrices etc currently generates with row major convention |
| 00:37:25 | Demos_ | I care much more about the way matrix multiplcation works than I do about actual storage order |
| 00:37:35 | BitPuffin | so all you really need to do in order to be stuck in your old grumy ways is to use those matrices transposed, with the vector multiplying into the ass instead |
| 00:38:02 | BitPuffin | so if that's the case |
| 00:38:06 | Demos_ | now that I can not deal with. graphics books may use row major but it is much more rare in math |
| 00:38:16 | Demos_ | I mean I can transpose em |
| 00:38:24 | BitPuffin | then I think ABv is vBA in linagl |
| 00:38:34 | Demos_ | yeah... no |
| 00:38:38 | BitPuffin | if AB is transposed |
| 00:38:44 | BitPuffin | which they are if you do so from the start |
| 00:38:54 | BitPuffin | ie when you get the projection blabla and the translate blabla |
| 00:39:10 | BitPuffin | if you just transpose them first and then use them regularly it should probably be the same |
| 00:39:21 | BitPuffin | I can't see why it wouldn't hold up |
| 00:39:26 | Demos_ | I think this conversation has shown why I just picked set of conventions and made sure everything was in those |
| 00:39:33 | BitPuffin | although it's pretty late so my mind might be playing tricks |
| 00:39:42 | fowl | matrixes are confusing |
| 00:39:49 | Demos_ | it sucks when you use the wrong convention twice and things /almost/ work |
| 00:39:51 | BitPuffin | Demos_: I don't see how but okay |
| 00:40:02 | BitPuffin | the wrong convention? lol |
| 00:40:12 | BitPuffin | it's like you didn't even listen :( typing wasted |
| 00:40:16 | Demos_ | one different from your mental convention |
| 00:40:37 | Demos_ | or different from the convention of the rest of your app |
| 00:40:44 | BitPuffin | well eitherway |
| 00:40:53 | BitPuffin | like I said you should be able to use it as if it was col major |
| 00:41:06 | BitPuffin | if you transpose the base matrices it provides |
| 00:41:09 | BitPuffin | ie translate etc |
| 00:41:29 | Demos_ | it should be an option |
| 00:41:42 | BitPuffin | yeah I've considered making it such and it's not off the list |
| 00:41:45 | BitPuffin | just not high priority |
| 00:41:47 | Demos_ | also storage order and the way multiplication works should be seperate options |
| 00:42:03 | BitPuffin | what do you meant the way multiplication works |
| 00:42:30 | Demos_ | like ABv vs vBA |
| 00:42:31 | BitPuffin | matrix * matrix multiplicaion is not defined separately for different conventions you goof :P |
| 00:42:35 | BitPuffin | well no |
| 00:42:43 | BitPuffin | because it's already doing exactly what glsl does |
| 00:42:59 | BitPuffin | vA doesn't work if v is a col vector |
| 00:43:10 | BitPuffin | and Av doesn't work if v is a row vector |
| 00:43:16 | Demos_ | but BA and AB do |
| 00:43:23 | Demos_ | so if they are square... |
| 00:44:10 | BitPuffin | yeah I know, then if you'd be using the column major version you would do BA |
| 00:44:12 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:44:12 | BitPuffin | instead of AB |
| 00:44:21 | BitPuffin | and do BAv |
| 00:44:34 | BitPuffin | point is, you don't need to add anything extra to the multiplication parts |
| 00:44:52 | BitPuffin | it comes down to the "primitive" matrices |
| 00:45:03 | BitPuffin | like for transformation and stuff |
| 00:45:06 | Demos_ | no but then BAv is the same as vBA for row major right? |
| 00:45:42 | BitPuffin | if you use col major for BAv primitive matrices and use row major primitives for vAB it's the same yes |
| 00:46:10 | Demos_ | I guess I care about using col major primitives then |
| 00:46:17 | BitPuffin | exactly |
| 00:46:22 | BitPuffin | which is what I've been saying |
| 00:46:24 | BitPuffin | for like years |
| 00:46:28 | BitPuffin | decades even |
| 00:46:47 | BitPuffin | no but yeah, the way you can do that now is to just transpose the primitives |
| 00:47:07 | Demos_ | which is fine... I guess |
| 00:47:10 | BitPuffin | but eventually I'd want them separate types so that they are not mixed by mistake |
| 00:47:21 | * | DAddYE quit (Remote host closed the connection) |
| 00:47:23 | Demos_ | yeah, that would be good |
| 00:47:37 | BitPuffin | simple enough to add |
| 00:47:52 | BitPuffin | does generic parameters take default values? |
| 00:47:56 | * | DAddYE joined #nimrod |
| 00:47:59 | BitPuffin | if not I probably wanna wait for that |
| 00:48:21 | Demos_ | not sure, but you can just define all the TVecXT stuff to use the default |
| 00:48:26 | EXetoC | BitPuffin: yes. possibly without the ability to constrain |
| 00:48:35 | fowl | hm |
| 00:48:48 | Demos_ | could do it with a static[int] bitflag |
| 00:48:50 | BitPuffin | EXetoC: referring to? |
| 00:49:06 | BitPuffin | Demos_: yeah but I want a default value for it |
| 00:49:30 | fowl | did you try it BitPuffin |
| 00:49:44 | BitPuffin | so type TMatrix[T; R, C: static[int], rowmajor: = true] |
| 00:49:46 | BitPuffin | fowl: no not now |
| 00:49:47 | EXetoC | I don't know if you can for actual values. I wouldn't be surprised if it didn't work yet |
| 00:49:49 | BitPuffin | gonna sleep soon |
| 00:49:55 | Demos_ | dun know. I gotta go, but I think we have established that being explicit about both storage order and actuall primitive convention is important |
| 00:50:43 | Demos_ | *actual |
| 00:50:47 | BitPuffin | Demos_: well I had made up my mind about that a long while back, but yes it's good that it is clear to everyone, unfortunately the only way you can do col major style now is "unsafe" because you might mix by mistake, but if you are using a convention already I find that highly unlikely |
| 00:51:31 | Demos_ | it makes the library much eaiser to use, and means you can sorta "set and forget" |
| 00:51:58 | BitPuffin | Demos_: exactly |
| 00:52:01 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 00:52:19 | Demos_ | I have spent way too much time tracking down bugs that were because of two conventions like this that almost canceled each other out but not quite |
| 00:52:39 | BitPuffin | Demos_: It is pretty stinking rocking already, I believe some of the stuff I had to compile out with when false will work with some of the recent bug fixes |
| 00:52:51 | BitPuffin | ie N-dimensional operations that I think are not even found in most libs |
| 00:53:08 | BitPuffin | like determinant etc |
| 00:53:38 | BitPuffin | if you look at D's library, gl3n, it does have generic types just like linagl, but determinant is hardcoded |
| 00:53:47 | BitPuffin | so it only supports certain sizes |
| 00:53:52 | BitPuffin | don't know about eigen though |
| 00:53:57 | BitPuffin | pretty sure glm doesn't have it |
| 00:54:12 | Varriount | Man, the nimrod forum thread discussing a switch to using google groups is very... heated. |
| 00:54:15 | BitPuffin | mabye some obscure scientific python lib too, but not something meant for opengl :P |
| 00:54:24 | dom96 | xenagi: Araq wrapped OpenCL recently |
| 00:54:35 | xenagi | orly? o.0 |
| 00:54:46 | dom96 | nimrod-code/opencl |
| 00:54:50 | xenagi | :D |
| 00:54:52 | xenagi | nice |
| 00:56:06 | BitPuffin | Demos_: soon I'll also add geometric primitives :D |
| 00:56:11 | BitPuffin | like rays, spheres etc |
| 00:56:13 | dom96 | good night |
| 00:56:58 | BitPuffin | AABB |
| 00:57:07 | BitPuffin | you name it yo |
| 00:57:07 | * | Demos_ quit (Ping timeout: 264 seconds) |
| 00:57:54 | OrionPK | then opencl wrapper need some more examples |
| 00:59:27 | BitPuffin | xenagi: get on it |
| 00:59:44 | xenagi | lol |
| 01:05:17 | Varriount | What practical things do people use opencl for? |
| 01:05:45 | BitPuffin | Varriount: computing things |
| 01:06:13 | BitPuffin | such as gaussian blur |
| 01:06:56 | BitPuffin | believe it's fairly used in image processing at least |
| 01:09:21 | BitPuffin | Varriount: maybe in some non-realtime rendering too probably |
| 01:10:42 | Demos | Eigen kinda has the works |
| 01:10:44 | BitPuffin | http://www.luxrender.net/wiki/index.php?title=Luxrender_and_OpenCL |
| 01:11:04 | BitPuffin | the works? |
| 01:11:10 | Demos | all the things |
| 01:11:39 | Demos | decompositions, determinants, block operations, various solvers |
| 01:12:18 | BitPuffin | for any size? |
| 01:13:43 | BitPuffin | lol |
| 01:13:51 | BitPuffin | Linagl - size doesn't matter |
| 01:14:20 | Demos | probably, with specializations for special optimized algorithms when approperate |
| 01:14:45 | BitPuffin | Demos: yeah will probably keep hard coded versions for the usual sizes |
| 01:15:00 | Demos | like eigen you can say matrix.row<2>() and it will give you the 2nd row, and it manages NOT TO COPY it |
| 01:15:34 | Demos | Eigen is awesome |
| 01:16:05 | EXetoC | no copy? sounds innovative |
| 01:16:49 | BitPuffin | doesn't sound safe |
| 01:18:36 | BitPuffin | what about the kids |
| 01:19:10 | Demos | they are good at safety |
| 01:19:28 | Demos | almost every error is compile time, others are runtime with a good assert message |
| 01:20:39 | fowl | what about the kids?! |
| 01:58:59 | * | DAddYE joined #nimrod |
| 02:12:49 | * | yzzyx joined #nimrod |
| 02:14:11 | * | yzzyx left #nimrod ("ERC Version 5.3 (IRC client for Emacs)") |
| 02:14:51 | * | q66 quit (Quit: Leaving) |
| 02:19:13 | * | DAddYE quit () |
| 02:37:08 | * | brson quit (Ping timeout: 246 seconds) |
| 03:15:21 | fowl | i killed the convo. sry. |
| 03:41:25 | xenagi | ... |
| 03:41:38 | xenagi | it's just two awkward now |
| 04:00:21 | Demos | I really like Eigen. It showcases how c++'s template system may be ad-hoc and strange and syntax heavy but at the end of the day it can get the job done really well |
| 04:09:57 | * | xenagi quit (Quit: Leaving) |
| 04:13:33 | * | Demos quit (Read error: Connection reset by peer) |
| 04:30:24 | Skrylar | welp. gimp.org seems to be down |
| 04:46:08 | * | renesac quit (Ping timeout: 265 seconds) |
| 05:00:06 | * | renesac joined #nimrod |
| 05:09:43 | renesac | BitPuffin, numpy stores data in row major order, so in this case it is a plus for interoperability w/o transposing back and forth. |
| 05:11:13 | * | superfunc joined #nimrod |
| 05:12:32 | renesac | oh, it also supports column major (or 'asfortranarray' as they say) |
| 05:13:11 | renesac | but by default it is row-major |
| 05:13:56 | renesac | http://stackoverflow.com/questions/17954990/performance-of-row-vs-column-operations-in-numpy |
| 05:20:42 | * | zielmicha joined #nimrod |
| 05:28:43 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 05:29:06 | Skrylar | i should learn matrix math :\ |
| 05:33:28 | fowl | "neo, multiply these matrix for me" |
| 05:36:28 | * | superfunc quit (Ping timeout: 245 seconds) |
| 06:04:27 | * | bearg joined #nimrod |
| 06:20:14 | Skrylar | fowl: you think those are opcodes you're beathing? |
| 06:52:53 | * | skyfex_ joined #nimrod |
| 06:52:54 | * | skyfex quit (Read error: Connection reset by peer) |
| 07:18:45 | * | skyfex_ quit (Quit: Computer has gone to sleep.) |
| 07:19:22 | * | skyfex_ joined #nimrod |
| 08:09:44 | * | Matthias247 joined #nimrod |
| 08:10:54 | * | Matthias247 quit (Client Quit) |
| 08:56:09 | * | silven joined #nimrod |
| 09:27:03 | * | Ransel joined #nimrod |
| 09:29:28 | * | BitPuffin joined #nimrod |
| 10:13:38 | * | jbe_ joined #nimrod |
| 10:36:03 | * | Ransel quit (Ping timeout: 245 seconds) |
| 10:50:39 | BitPuffin | renesac: well ha! :D |
| 10:50:45 | BitPuffin | good decision on their end |
| 10:54:11 | BitPuffin | renesac: I'm not really sure their row vs col major thing is fair though, since numpy probably introduces extra overhead when converting to col major |
| 10:54:20 | BitPuffin | although I might be wrong |
| 10:54:32 | BitPuffin | anyway it really just depends on what the hardware likes I guess |
| 10:54:52 | Araq | hi bearg welcome |
| 10:55:25 | Araq | BitPuffin: hw likes whatever you access in a cache-friendly manner |
| 10:55:32 | BitPuffin | yep |
| 10:56:39 | BitPuffin | I dunno I guess adding a matrix where rows > cols is faster with row major and adding matrices where cols > rows is faster with col major |
| 10:56:55 | BitPuffin | or hrm |
| 10:56:58 | BitPuffin | yeah |
| 10:57:03 | BitPuffin | at least if you traverse them correctly |
| 10:57:17 | BitPuffin | not sure |
| 10:57:23 | BitPuffin | guess I'd have to bench to know for sure |
| 11:00:27 | BitPuffin | hmm Araq, if I were to optimize some of the procs in nimrod with inline assembly, how would I deal with stuff like some CPUs supporting SIMD and some not? |
| 11:01:41 | Araq | optimizing with TR macros is likely to give more bang for the bucks |
| 11:02:12 | Araq | the trivial for loops are SIMD'ed by the C compiler already, check the assembler output |
| 11:02:13 | BitPuffin | true |
| 11:02:42 | Araq | or rather add __atttribute__((vector)) or whatever |
| 11:02:51 | Araq | it is called |
| 11:03:36 | Araq | the .codegenDecl pragma perhaps works for that |
| 11:03:43 | Araq | if not, file a feature request |
| 11:09:14 | BitPuffin | well hopefully it does |
| 11:09:23 | BitPuffin | I guess I'll investigate if linagl performs poorly |
| 11:09:27 | BitPuffin | I doubt it will |
| 11:11:27 | BitPuffin | btw have you seen this? http://demo.yasp.me/ |
| 11:14:57 | Araq | no |
| 11:15:14 | Araq | btw have you seen my jump optimizer in my vm? |
| 11:18:35 | * | easy_muffin joined #nimrod |
| 11:19:19 | Araq | hi easy_muffin are you BitPuffin ? |
| 11:19:28 | * | Araq has asked this before ... |
| 11:19:29 | easy_muffin | Nope |
| 11:19:44 | Araq | prove it! |
| 11:19:51 | easy_muffin | how? |
| 11:20:28 | BitPuffin | yeah how? |
| 11:20:41 | BitPuffin | Araq: no I haven't, is it sweet? |
| 11:20:54 | easy_muffin | Hey BitPuffin are you easy_muffin? |
| 11:21:05 | Araq | hmm, say something BitPuffin never would say |
| 11:21:22 | easy_muffin | I am easy_muffin |
| 11:22:06 | BitPuffin | easy_muffin: I am bitpuffin, but I heard easy_muffin is BitPuffin |
| 11:22:13 | Araq | hmm alright |
| 11:22:24 | * | Araq believes easy_muffin |
| 11:22:27 | BitPuffin | Araq: something BitPuffin would never say, you are a funny guy |
| 11:23:10 | Araq | I also have the "Dr Hippert" syndrome |
| 11:24:23 | Araq | BitPuffin: it's delicious |
| 11:24:57 | Araq | it also mutates state (evil! evil!) |
| 11:26:40 | BitPuffin | :O! |
| 11:26:42 | BitPuffin | HOW DARE YU |
| 11:30:41 | EXetoC | no u |
| 11:30:45 | BitPuffin | yu! |
| 11:38:20 | EXetoC | did I just perform a module/enumerator comparison in python? interesting |
| 11:55:08 | * | Ransel joined #nimrod |
| 12:01:28 | * | Ransel quit (Ping timeout: 245 seconds) |
| 12:07:40 | * | phI||Ip quit (Read error: Operation timed out) |
| 12:08:58 | * | silven_ joined #nimrod |
| 12:09:14 | * | silven quit (Ping timeout: 252 seconds) |
| 12:09:31 | * | psquid quit (Ping timeout: 264 seconds) |
| 12:11:34 | * | phI||Ip joined #nimrod |
| 12:13:40 | BitPuffin | does digitalocean.com work for you guys? |
| 12:15:56 | Araq | no |
| 12:16:41 | BitPuffin | weird |
| 12:16:52 | BitPuffin | downforeveryoneorjustme says it's up lol |
| 12:17:22 | Araq | downforeveryoneorjustme is lying |
| 12:19:04 | BitPuffin | good |
| 12:20:09 | rixx | digitalocean.com works over here |
| 12:20:21 | BitPuffin | where you at? |
| 12:20:26 | rixx | Germany |
| 12:20:31 | BitPuffin | but so is Araq lol |
| 12:20:40 | BitPuffin | oh |
| 12:20:44 | BitPuffin | it's only because now it is up |
| 12:20:46 | BitPuffin | :P |
| 12:21:22 | EXetoC | different tubes |
| 12:21:25 | EXetoC | probably |
| 12:21:57 | EXetoC | it connects with mine |
| 12:22:03 | * | psquid joined #nimrod |
| 12:22:30 | BitPuffin | it's a series of toobs |
| 12:54:17 | * | BitPuffin quit (Quit: WeeChat 0.4.3) |
| 12:55:44 | * | BitPuffin joined #nimrod |
| 12:57:05 | BitPuffin | lol |
| 12:57:12 | BitPuffin | I just set the mac display to it's real resolution |
| 12:57:20 | BitPuffin | which without third party tools apple doesn't let you do |
| 12:57:22 | BitPuffin | holy shit |
| 12:57:24 | BitPuffin | so much space |
| 12:57:26 | BitPuffin | love this |
| 13:20:25 | * | Ransel joined #nimrod |
| 13:28:39 | * | zahary quit (Read error: Operation timed out) |
| 13:39:17 | EXetoC | BitPuffin: how stupid. especially if it can't even detect the max res |
| 13:42:35 | * | darkf quit (Quit: Leaving) |
| 13:48:01 | * | easy_muffin quit (Ping timeout: 240 seconds) |
| 14:17:44 | BitPuffin | EXetoC: yeah I know, but now that I have full res it's awesome |
| 14:22:18 | * | lanior quit (Ping timeout: 245 seconds) |
| 14:29:53 | * | clovis joined #nimrod |
| 14:38:33 | * | easy_muffin joined #nimrod |
| 14:38:39 | * | easy_muffin quit (Remote host closed the connection) |
| 14:41:37 | * | awestroke joined #nimrod |
| 14:59:46 | * | bearg quit (Quit: Leaving.) |
| 15:08:44 | * | Endy joined #nimrod |
| 15:09:22 | BitPuffin | is convention for constructors still initFoo and newFoo for stack and heap types respectively? |
| 15:17:29 | * | [1]Endy joined #nimrod |
| 15:20:49 | * | Endy quit (Ping timeout: 240 seconds) |
| 15:20:49 | * | [1]Endy is now known as Endy |
| 15:34:47 | BitPuffin | Araq: is there a way to partially define parts of a type in one place and keep on going later on? The reason I'm asking is because I want to define my public fields of an object once, but the private fields may vary depending on what platform it is running, so I want to add those separately for each target |
| 15:42:30 | * | Demos joined #nimrod |
| 15:53:18 | * | bearg joined #nimrod |
| 16:06:46 | * | dffd joined #nimrod |
| 16:07:04 | * | dffd quit (Client Quit) |
| 16:12:01 | * | Demos quit (Ping timeout: 240 seconds) |
| 16:18:03 | * | Varriount|Mobile joined #nimrod |
| 16:18:20 | * | DAddYE joined #nimrod |
| 16:18:52 | Varriount|Mobile | Anyone here know a good way for me to write the equivalent of a blog post, without actually setting up a blog? |
| 16:19:14 | * | clovis quit (Ping timeout: 245 seconds) |
| 16:19:28 | Varriount|Mobile | I'm interested in writing up a blog post on using opengl in nimrod |
| 16:21:18 | Varriount|Mobile | (Feel free to respond even if my mobile connection disconnects, Ill read the logs on my desktop connection) |
| 16:26:21 | OrionPK | Varriount|Mobile forum post? |
| 16:26:47 | OrionPK | or a self post here: http://www.reddit.com/r/nimrod |
| 16:27:33 | * | Demos joined #nimrod |
| 16:31:35 | Varriount|Mobile | Hi Demos. |
| 16:31:53 | Demos | can not talk, have a day of exams and work |
| 16:32:09 | Varriount|Mobile | :( |
| 16:33:35 | * | zahary joined #nimrod |
| 16:38:58 | BitPuffin | Varriount|Mobile: use dom96's thing? |
| 16:40:07 | * | Demos quit (Ping timeout: 264 seconds) |
| 16:40:19 | Varriount|Mobile | BitPuffin: Thing? |
| 16:40:20 | * | brson joined #nimrod |
| 16:41:14 | * | Demos joined #nimrod |
| 16:41:26 | BitPuffin | blog gen |
| 16:42:05 | dom96 | Varriount|Mobile: You could also use gist. |
| 16:43:56 | BitPuffin | Varriount|Mobile: you could also borrow dom96's blog |
| 16:44:53 | dom96 | BitPuffin: Use a 'when'? |
| 16:45:29 | dom96 | BitPuffin: And what do you mean by 'borrow'? |
| 16:46:15 | EXetoC | Is a type in each block no good? |
| 16:47:20 | BitPuffin | dom96: a when? |
| 16:47:21 | EXetoC | it shouldn't be necessary of course, and it might be error-prone for complex types |
| 16:47:42 | EXetoC | BitPuffin: when-statement |
| 16:47:48 | BitPuffin | I know |
| 16:48:07 | BitPuffin | that's not even related |
| 16:48:46 | EXetoC | not related to your question about fields? |
| 16:49:07 | * | Demos quit (Ping timeout: 264 seconds) |
| 16:50:48 | BitPuffin | exactly |
| 16:50:58 | BitPuffin | when would be part of the solution regardless about the portability part |
| 16:51:07 | BitPuffin | but it's got nothing to do with what I asked how to do |
| 16:51:27 | BitPuffin | I already know that I can conditionally compile stuff with when and I am already doing that |
| 16:51:55 | BitPuffin | just that I think it's kind of odd to maintain N versions of the same object when they might only differ with like one variable |
| 16:52:33 | EXetoC | I said it shouldn't be necessary, but I think it currently is |
| 16:52:43 | BitPuffin | unfortunately yeah |
| 16:52:55 | BitPuffin | and inheritance etc with like a "base" object feels unnecessary too |
| 16:53:05 | BitPuffin | in this particular case |
| 16:53:15 | BitPuffin | because I want them to be one type |
| 16:53:34 | BitPuffin | or hmm |
| 16:53:41 | BitPuffin | maybe that would simplify things |
| 16:53:44 | BitPuffin | or complicate |
| 16:53:45 | BitPuffin | hm |
| 16:53:47 | BitPuffin | :P |
| 16:58:42 | dom96 | type |
| 16:58:45 | dom96 | Foo = object |
| 16:58:49 | dom96 | when defined(windows): |
| 16:58:54 | dom96 | field: string |
| 16:58:57 | dom96 | else: |
| 16:59:06 | dom96 | fuuu: int |
| 16:59:19 | dom96 | Is that what you already know? |
| 16:59:26 | EXetoC | I guess not |
| 17:00:04 | dom96 | Actually, i'm not sure if that will work :P |
| 17:00:17 | BitPuffin | I don't think it will |
| 17:00:37 | dom96 | actually no, it does. |
| 17:00:38 | dom96 | I use it |
| 17:00:51 | EXetoC | I did the mistake of trying that in the actual type block. that doesn't work which is inconsistent |
| 17:01:08 | EXetoC | wee trial and error |
| 17:04:29 | BitPuffin | oh I thought when wasn't allowed inside type stuff like that |
| 17:04:36 | BitPuffin | guess that works |
| 17:04:37 | BitPuffin | then |
| 17:04:59 | BitPuffin | still though, I'd still like to be able to extend a type's definition further down the file |
| 17:05:08 | * | Varriount|Mobile quit (Ping timeout: 246 seconds) |
| 17:05:27 | EXetoC | I doubt it's necessary, and it does seem like a confusing thing to do |
| 17:05:36 | BitPuffin | no |
| 17:05:53 | BitPuffin | because instead of doing when defined(windows) a million times in a bunch of different small places |
| 17:06:05 | BitPuffin | it can be nice to group the platform specific stuff in to one big when |
| 17:06:15 | BitPuffin | if you know what I'm sayin |
| 17:08:04 | BitPuffin | EXetoC: do you hang with? |
| 17:09:27 | dom96 | BitPuffin: WHAT DID YOU MEAN BY BORROW?! |
| 17:09:42 | BitPuffin | dom96: mr period has come to town? |
| 17:09:45 | BitPuffin | dom96: guest post |
| 17:09:47 | BitPuffin | einstein |
| 17:10:01 | dom96 | wut? |
| 17:10:33 | BitPuffin | dom96: yes, let Varriount post his article as a guest post on your blog |
| 17:10:52 | dom96 | No, I was wut-ing at the other two lines. |
| 17:11:15 | BitPuffin | well I mean you are yelling as if you were on your period |
| 17:11:23 | dom96 | Borrow could have had 2 perfectly reasonable meanings. |
| 17:11:23 | * | io2 joined #nimrod |
| 17:11:48 | BitPuffin | and you are einstein for not figuring out that borrowing your blog to write a post on it means that he posts his article on your blog |
| 17:11:49 | dom96 | So don't be condenscending, bitch. |
| 17:11:55 | BitPuffin | dom96: come at me bro |
| 17:12:05 | dom96 | YOU WANNA GO!? |
| 17:12:10 | BitPuffin | hell ye |
| 17:12:13 | * | dom96 polishes the ban hammer |
| 17:12:19 | BitPuffin | I'm not afraid of no hammah |
| 17:12:25 | dom96 | YOU SURE ABOUT THAT?! |
| 17:12:42 | BitPuffin | I know that you value our friendship too much to do such a thing |
| 17:12:52 | dom96 | Awww |
| 17:12:53 | BitPuffin | But if that turns out to be false |
| 17:12:57 | BitPuffin | there is something you need to know |
| 17:12:59 | BitPuffin | I.... |
| 17:13:00 | dom96 | Well I can't ban you now. |
| 17:13:01 | BitPuffin | Am your father |
| 17:13:12 | * | dom96 jumps off bridge |
| 17:13:22 | * | dom96 dies |
| 17:13:24 | BitPuffin | And son, I'm disappoint, where's the dreads |
| 17:14:45 | dom96 | Perhaps when I get to uni. |
| 17:15:38 | dom96 | anyway bbl |
| 17:27:11 | * | wolfspaw joined #nimrod |
| 17:38:10 | * | wolfspaw left #nimrod (#nimrod) |
| 17:39:47 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 17:40:38 | * | brson quit (Ping timeout: 255 seconds) |
| 17:41:39 | * | Demos joined #nimrod |
| 17:44:46 | * | brson joined #nimrod |
| 17:50:14 | * | bearg quit (Ping timeout: 252 seconds) |
| 17:52:15 | * | Demos quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 17:52:24 | * | Demos joined #nimrod |
| 17:58:21 | * | q66 joined #nimrod |
| 18:04:32 | * | Demos quit (Ping timeout: 252 seconds) |
| 18:22:37 | Araq | when bitpuffing comes around, tell him he can do what he wants with a macro |
| 18:27:24 | EXetoC | I don't think that whatever he's proposing will reduce typing at all |
| 18:28:13 | EXetoC | well maybe ~10 characters per line or something like that, so it barely matters |
| 18:28:58 | Araq | it's not about typing |
| 18:29:17 | Araq | it's about splitting stuff in a modularity-breaking way |
| 18:31:00 | Araq | like C#'s partial classes |
| 18:32:54 | fowl | sounds to me like he wants an interface |
| 18:33:41 | EXetoC | he's not being very clear then |
| 18:33:59 | fowl | type platforminterface = generic x x.does(this) .... ; when defined(linux): import private/platform/linux ; assert platformimpl is platforminterface |
| 18:38:13 | EXetoC | sure, if he does indeed want shared fields |
| 18:48:45 | Araq | dom96: may I merge Varriount's nimbuild patch? |
| 18:55:54 | dom96 | Araq: What's the point if I can't deploy it anyway? |
| 18:56:24 | Araq | why can't you deploy it? o.O |
| 18:56:34 | dom96 | Because I'm busy |
| 18:58:25 | Araq | but it is deploy day! |
| 18:59:35 | skyfex_ | Araq: What's does ropecg do vs. ropef? |
| 19:01:49 | Araq | ropecg supports #magiccall(foo) |
| 19:04:36 | reactormonk | Araq, partial classes? |
| 19:05:20 | reactormonk | ah, found it. |
| 19:05:31 | reactormonk | Araq, how is that modularity-breaking? |
| 19:14:50 | * | Demos joined #nimrod |
| 19:16:09 | Araq | reactormonk: var foo: partialFoo # when does the compiler know foo's size? at link-time, aka modularity breaking |
| 19:16:15 | flyx | how does one sleep a thread in nimrod? |
| 19:16:22 | * | flyx has his gtk2 patch almost ready |
| 19:16:25 | reactormonk | Araq, aww fuck, size. |
| 19:16:29 | Araq | os.sleep() ? |
| 19:16:52 | flyx | sounds like it, thanks |
| 19:16:59 | * | flyx didn't have a look at the stdlib yet |
| 19:17:05 | Araq | reactormonk: afaict "modularity" is not well defined though |
| 19:17:28 | fowl | flyx, this is the link you need http://build.nimrod-lang.org/docs/theindex.html |
| 19:17:42 | reactormonk | Araq, do you want binary modularity or source modularity? |
| 19:18:18 | Araq | reactormonk: did you make these terms up? |
| 19:18:51 | reactormonk | Araq, yup. binary modularity cares about size, where as source doesn't because you can change the size of an object on compile-time |
| 19:35:01 | flyx | can I define a symbol in my code, so that a defined(symbol) call in an imported lib evaluates to true? |
| 19:37:19 | EXetoC | const? |
| 19:38:31 | * | Demos quit (Ping timeout: 264 seconds) |
| 19:38:39 | flyx | I tried, but that doesn't work - probably because it's not in scope of the imported lib |
| 19:40:35 | EXetoC | you mean module? shouldn't that module import a module that defines the const then? also, make sure that it's being exported (*) |
| 19:41:37 | Araq | don't use when defined(myconst), use when myconst instead |
| 19:42:06 | Araq | "defined" is fragile, typos are not caught |
| 19:42:31 | flyx | does it also work with a -d parameter without defined()? |
| 19:43:15 | Araq | no for -d you need 'defined' |
| 19:44:24 | flyx | okay, then I have to stick with that. I just wondered whether I can add a define in the code using the library |
| 19:44:37 | EXetoC | otherwise it might be evaluated to "when defined(true)" for example |
| 19:44:57 | Varriount | Araq: Before I go to my next class, is there anything that needs to be done regarding the nimbuild "announce still failing tests" PR? |
| 19:50:24 | Araq | Varriount: I don't think so, thank you |
| 19:51:22 | Varriount | Araq: No problem. Thank you for not getting angry at my week-long break. |
| 19:51:56 | * | foodoo joined #nimrod |
| 19:52:01 | Araq | er ... wow |
| 19:52:36 | Araq | now I look like a jerk ... |
| 19:53:27 | Araq | why would I be angry? I'm angry about software, not people |
| 19:56:43 | Varriount | Araq: I never meant to imply that you were a jerk. Unfortunately, I've known people who are not.. nice to work with. I'm glad to say, you aren't one of them. |
| 19:58:40 | dom96 | flyx: Can you compile Aporia on Mac OS X? |
| 19:59:12 | flyx | dom96: I'm just about to test it |
| 19:59:20 | dom96 | flyx: Great, thanks. |
| 20:02:19 | Araq | ping zahary: please fix the command syntax usages that keep the compiler from bootstrapping |
| 20:03:07 | dom96 | flyx: Did you want to define gtk_quartz in gtkmacintegration.nim? |
| 20:03:37 | Varriount | Are file handles automatically closed when collected by the GC? |
| 20:04:11 | skyfex_ | Ugh, git can be confusing sometimes |
| 20:04:15 | flyx | dom96: no, in the example |
| 20:04:15 | Araq | Varriount: no |
| 20:04:50 | dom96 | flyx: I see. I think your comment is good enough. |
| 20:07:33 | Varriount | In the parameter declaration section of a procedure definition/declaration, is there a way to declare a parameter as either taking a 'var' type *or* a ref type? |
| 20:08:19 | zahary | Araq: why don't we push new sources instead? |
| 20:08:47 | zahary | I don't think I'm using the command syntax - istead, it's the inline stmtListExpr (isn't this ancient by now?) |
| 20:09:06 | zahary | else: (internalAssert typ.kind == tyCompositeTypeClass; typ.sons[1]) |
| 20:10:59 | renesac | zahary, can 'openarray' be expressed via typeclasses now? Or it still needs magic? |
| 20:11:22 | zahary | not yet |
| 20:11:51 | renesac | that yet leaves me hopeful :) |
| 20:11:51 | zahary | at least not in the current form that uses a single implementation |
| 20:12:38 | fowl | zahary, adding parens around the param to internalassert fixes it |
| 20:12:44 | fowl | its the command syntax |
| 20:13:21 | zahary | erm, ok - I'll include it in the next commit |
| 20:13:38 | renesac | humhum |
| 20:13:40 | renesac | *hum |
| 20:19:58 | EXetoC | Varriount: you don't want to dereference? |
| 20:22:58 | EXetoC | Varriount: http://build.nimrod-lang.org/docs/manual.html#type-classes |
| 20:23:23 | EXetoC | this seems to imply that it's possible, right? |
| 20:24:29 | flyx | dom96: Aporia does build, but I cannot start it. it doesn't find libiconv.dylib, which is in /usr/lib |
| 20:24:56 | flyx | do I need to tell nimrod where to look for dynamic libraries? |
| 20:25:33 | dom96 | good to hear that it builds |
| 20:26:43 | flyx | ah, never mind, fixed it |
| 20:26:48 | flyx | seems like it runs |
| 20:32:53 | * | awestroke quit (Read error: Connection reset by peer) |
| 20:33:03 | nequitans | zahary, i'm assuming you wrote the Atom plugin for nimrod. Thanks! |
| 20:33:17 | Araq | zahary: meh, so push new C sources instead, I don't mind either way |
| 20:35:11 | nequitans | (and for the vim ones) |
| 20:35:52 | * | webclienttest joined #nimrod |
| 20:36:10 | Araq | hi webclienttest welcome |
| 20:36:34 | * | webclienttest left #nimrod ("Leaving") |
| 20:36:38 | zielmicha | sorry webclienttest is not real, it's just my bot |
| 20:36:58 | zielmicha | I connected from wrong server. |
| 20:36:58 | Araq | that's what I thought |
| 20:37:21 | Araq | but I also greet bots |
| 20:45:07 | * | Demos joined #nimrod |
| 20:45:47 | * | zielmicha_beta joined #nimrod |
| 20:46:07 | zielmicha_beta | better name than webclienttest :) |
| 20:47:53 | * | BitPuffin joined #nimrod |
| 20:51:31 | * | BitPuffin quit (Client Quit) |
| 20:51:46 | * | BitPuffin joined #nimrod |
| 20:55:02 | * | foodoo quit (Remote host closed the connection) |
| 20:56:23 | * | clovis joined #nimrod |
| 20:58:20 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 20:58:45 | * | vendethiel joined #nimrod |
| 21:04:10 | NimBot | nimrod-code/nimbuild master c6f1c37 Clay Sweetser [+0 ±1 -0]: Added "still failing tests" feature.... 2 more lines |
| 21:04:10 | NimBot | nimrod-code/nimbuild master 1592b6c Clay Sweetser [+0 ±1 -0]: Removed IRC reporting of "still failing" tests |
| 21:04:10 | NimBot | nimrod-code/nimbuild master 7e7fe50 Andreas Rumpf [+0 ±1 -0]: Merge pull request #14 from Varriount/website/report-still-failing... 2 more lines |
| 21:05:05 | * | vendethiel quit (Read error: Connection reset by peer) |
| 21:06:20 | skyfex_ | Araq: Is it currently possible to construct a type that can be assigned 0, 1, 'Z' or 'X' ? |
| 21:06:52 | Araq | with a converter it should be possible |
| 21:07:51 | * | vendethiel joined #nimrod |
| 21:11:16 | skyfex_ | hmm.. i could define it as range[0..3] and then have 'Z' and 'X' convert to 2/3.. but then I can't block someone from assigning 2/3 |
| 21:13:42 | skyfex_ | It's not important right now though.. just preparing a small presentation of Nimrod to some fellow hardware engineers |
| 21:14:10 | skyfex_ | Trying to get a feel for which parts of HDLs like Verilog/VHDL could be implemented in Nimrod |
| 21:15:00 | Araq | mymacro: |
| 21:15:06 | Araq | foo = Z |
| 21:15:17 | * | vendethiel quit (Remote host closed the connection) |
| 21:15:36 | Araq | --> you can have more flexibity within a macro invocation |
| 21:17:11 | * | DAddYE quit (Remote host closed the connection) |
| 21:18:07 | * | DAddYE joined #nimrod |
| 21:18:20 | Araq | skyfex_: you should have an enum instead of range[0..3] |
| 21:18:42 | * | Matthias247 joined #nimrod |
| 21:18:49 | Araq | and then a type converter from 0,1, 'Z', 'X' to convert to the enum |
| 21:19:18 | Araq | you can restrict the type converter via AST based overloading |
| 21:22:21 | * | vendethiel joined #nimrod |
| 21:24:02 | * | jbe_ quit (Quit: Leaving) |
| 21:25:36 | skyfex_ | why does converter toWire(a: range[0..1]): Wire = ... not match on 0 and 1 (unless toWire is explicitly called)? |
| 21:27:52 | Araq | dunno, looks like a bug. converters are rarely used ... |
| 21:36:53 | * | Endy quit (Ping timeout: 255 seconds) |
| 21:41:56 | Araq | skyfex_: my bet it's because 1 matches range[0..1] via a subtype relation and 'converter' is strict in its matching |
| 21:42:44 | * | io2 quit () |
| 21:45:00 | * | renesac quit (Ping timeout: 255 seconds) |
| 21:45:56 | * | flaviu joined #nimrod |
| 21:48:09 | zahary | nequitans: I'm still using mostly vim - the atom plugin is rather primitive |
| 21:49:33 | * | BitPuffin quit (Quit: WeeChat 0.4.3) |
| 21:49:55 | * | BitPuffin joined #nimrod |
| 21:50:09 | nequitans | zahary, i just started playing around with Atom the other day and it was nice to see that something existed. I do like how the Vim one alerts me to potential compiler errors |
| 21:50:32 | * | BitPuffin quit (Client Quit) |
| 21:50:48 | * | BitPuffin joined #nimrod |
| 21:51:31 | * | Demos quit (Ping timeout: 264 seconds) |
| 21:55:39 | nequitans | not sure how long this foray into atom will last |
| 22:00:23 | * | jbe joined #nimrod |
| 22:01:15 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:28:16 | * | clovis quit (Quit: clovis) |
| 22:59:13 | fowl | is {.union.} necessary |
| 23:02:30 | * | jbe quit (Quit: Leaving) |
| 23:28:58 | * | flaviu quit (Remote host closed the connection) |
| 23:33:54 | * | darkf joined #nimrod |
| 23:46:23 | * | lanior joined #nimrod |
| 23:50:05 | * | lanior quit (Client Quit) |