| 00:00:03 | fowl | its just slightly more verbose than c |
| 00:00:42 | runvnc | You don't normally need to cast things anyway |
| 00:00:44 | runvnc | at least I dont |
| 00:01:00 | runvnc | and that syntax is easier to understand than traditional cast syntax I think |
| 00:01:13 | Mat3 | yes I know. My point is that type systems are generally unreasonable because there tag variable data, not there storage location |
| 00:02:44 | Mat3 | so most of the time types only complicate programming without solving the storage problematic |
| 00:04:28 | runvnc | well, I think that is true to some degree |
| 00:04:29 | fowl | storage..? |
| 00:04:41 | runvnc | I have been avoiding types by using coffeescript/typescript which are variants of javascript |
| 00:04:50 | * | io2 quit () |
| 00:05:07 | runvnc | one thing I have found though is that a lot of my simple errors are caught by the compiler now while before I didnt catch them until testing |
| 00:05:44 | runvnc | I would prefer if nimrod or whatever language could infer/read my mind/whatever about all of the types and I could leave them out wherever they were obvious from the names |
| 00:05:58 | runvnc | but I think nimrod does a great job of compromising |
| 00:07:53 | Mat3 | fowl: A type do not tag the location (address) of its content, it is only a formal identification of the data format |
| 00:07:53 | * | DAddYE quit (Read error: Connection reset by peer) |
| 00:08:16 | * | DAddYE joined #nimrod |
| 00:09:45 | Mat3 | get some sleep,. ciao |
| 00:09:58 | * | Mat3 quit (Quit: Verlassend) |
| 00:10:19 | * | q66 quit (Quit: Leaving) |
| 00:11:13 | EXetoC | I don't get it |
| 00:12:01 | * | Demos_ joined #nimrod |
| 00:12:11 | EXetoC | you want an address, you use addr. is there much else to it? |
| 00:16:46 | fowl | i dont get it either |
| 00:18:58 | EXetoC | he might think that getting the actual integer value is overly complex, but it's not a common operation |
| 00:52:05 | * | psquid joined #nimrod |
| 00:52:52 | * | Zuu joined #nimrod |
| 00:53:26 | * | Zuu left #nimrod (#nimrod) |
| 00:55:06 | * | Demos_ quit (Ping timeout: 268 seconds) |
| 01:07:42 | * | boydgreenfield joined #nimrod |
| 01:10:04 | * | Demos_ joined #nimrod |
| 01:10:50 | Demos_ | I like to think about types in terms of the size of things. You need them unless you force everything to be the same size |
| 01:12:53 | * | cark quit (*.net *.split) |
| 01:12:55 | * | DAddYE quit (*.net *.split) |
| 01:12:55 | * | darkf quit (*.net *.split) |
| 01:12:56 | * | Demos quit (*.net *.split) |
| 01:12:56 | * | nande quit (*.net *.split) |
| 01:12:58 | * | runvnc quit (*.net *.split) |
| 01:25:07 | * | brson quit (Ping timeout: 264 seconds) |
| 01:26:07 | * | brson joined #nimrod |
| 01:49:22 | * | DAddYE joined #nimrod |
| 01:49:22 | * | runvnc joined #nimrod |
| 01:49:22 | * | darkf joined #nimrod |
| 01:49:22 | * | Demos joined #nimrod |
| 01:49:22 | * | nande joined #nimrod |
| 01:57:10 | * | DAddYE quit (Remote host closed the connection) |
| 01:57:27 | * | DAddYE joined #nimrod |
| 01:59:21 | * | Demos_ quit (Ping timeout: 245 seconds) |
| 02:09:04 | * | Demos quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 02:09:19 | * | Demos joined #nimrod |
| 02:19:35 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 02:33:32 | Demos | project idea: Pure software implementation of openGL written in nimrod, maybe lacking the ability to actually draw stuff. |
| 02:33:58 | runvnc | demos: would that actually talk to the hardware |
| 02:34:04 | Demos | no |
| 02:34:06 | runvnc | or is it using some driver library |
| 02:34:15 | runvnc | what layer does opengl use below it |
| 02:34:15 | Demos | it is not even a driver at all |
| 02:34:27 | Demos | like it jut provides the relevant functions |
| 02:34:39 | runvnc | ok now I get it, doesnt use the hardware |
| 02:34:41 | Demos | so you could do stuff like shader introspection at compile time |
| 02:35:04 | runvnc | well just wondering, do you have any idea where to get programming manuals for programming nvidia or ati gpus directly |
| 02:35:08 | Demos | it you include rendering and debug info it becomes like Microsoft's Direct3D reference device |
| 02:35:23 | Demos | erm you don't program them directly |
| 02:35:48 | runvnc | I know |
| 02:35:51 | Demos | I am not sure if detailed specs are availbe to the average joe |
| 02:36:03 | runvnc | but in order to build a driver you need that programming manual |
| 02:36:07 | runvnc | so thouse manuals must exist somewhere |
| 02:36:12 | runvnc | otherwise we wouldnt have drivers |
| 02:36:29 | runvnc | I dont like opengl as an abstraction |
| 02:36:34 | runvnc | or direct3d that much |
| 02:36:43 | runvnc | I just want to be able to send shader code to the gpu directly |
| 02:36:58 | runvnc | anyway the reference renderer thing is an interesting idea |
| 02:37:24 | Demos | you are kinda SOL I think then |
| 02:37:31 | runvnc | or reference device that doesnt render |
| 02:37:45 | Demos | I mean you can use mantle, but afaik that is also not avalible to the average joe |
| 02:38:31 | Demos | d3d also has something called WARP which is a fast software rasterizer that can be nice |
| 02:38:48 | runvnc | d3d has a lot of things that are nice |
| 02:38:52 | runvnc | but its ms |
| 02:38:58 | runvnc | I disagree with fascism |
| 02:39:12 | Demos | I actually have a nimrod wrapper that I started working on for D3D, but wrapping that is a shit-ton of work |
| 02:39:41 | * | boydgreenfield joined #nimrod |
| 02:39:53 | runvnc | I would like to ok.. this is just a fantasy but I would like to build a new operating system that is sort of based on an exokernel type thing but at a higher level, with incremental compiliation and completely open source evertyhing, and |
| 02:39:58 | runvnc | it needs to talk to hardware directly |
| 02:40:23 | Demos | incremental compilation of what? |
| 02:40:30 | runvnc | everything |
| 02:40:37 | runvnc | the entire system is statically compiled |
| 02:40:54 | Demos | I mean so are all operateing systems |
| 02:40:57 | Demos | you have to be |
| 02:41:08 | runvnc | sort of with an abstraction that is like an exokernel, but a fast implementation generated like a monolithic kernel |
| 02:41:41 | runvnc | not just the operating system is statically compiled, everything is compiled together into a monolithic kernel-like thing for performance |
| 02:41:53 | Demos | oh I think I see |
| 02:41:58 | runvnc | but the abstraction is vey high level, like description logics |
| 02:42:14 | Demos | the abstraction of what? the things you are running? |
| 02:42:15 | runvnc | however allowing for low-level abstractions or interfaces with hardware when necessary |
| 02:42:58 | runvnc | everything on the computer, from files, file implementation, file systems, gpus, graphics libraries, user applications |
| 02:43:05 | runvnc | nevermind |
| 02:43:14 | runvnc | I need to just do some work instead of rambling |
| 02:43:16 | runvnc | heh |
| 02:49:37 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 03:26:23 | * | DAddYE quit (Remote host closed the connection) |
| 03:32:22 | * | ruzu joined #nimrod |
| 03:32:26 | * | ruzu quit (Read error: Connection reset by peer) |
| 03:32:42 | * | ruzu joined #nimrod |
| 03:33:13 | * | ruzu quit (Changing host) |
| 03:33:13 | * | ruzu joined #nimrod |
| 03:49:05 | Demos | oh my god whoever decided to make this online homework tool use exact floating point comparisions needs to be shot |
| 03:56:31 | * | boydgreenfield joined #nimrod |
| 03:58:15 | reactormonk | Demos, send a mail somewhere ;-) |
| 03:58:25 | Demos | hehe |
| 03:58:50 | Demos | like I am off from the right answer by 2E-14 and it is marking me wrong :D |
| 03:59:30 | Demos | heh I got a 90% on the assignment so fuckit |
| 04:01:27 | * | DAddYE joined #nimrod |
| 04:01:55 | Demos | actually you can enter equations in as input and it will evaluate them, so I may just be able to just inject some code in there next time |
| 04:13:35 | Demos | it would be need to have some kind of shallow slice |
| 04:13:57 | Demos | so I could say like sort(arr[3..10]) and just have a portion of my array sorted |
| 04:17:31 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 04:25:49 | fowl | how often do you want to sort a portion of a list |
| 04:27:42 | * | boydgreenfield joined #nimrod |
| 04:29:39 | Demos | not that often, but it is useful in other contexts |
| 04:29:56 | Demos | I wanted to do a linear searh on a porition of a list earlier today |
| 04:38:08 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 04:49:54 | * | brson quit (Ping timeout: 252 seconds) |
| 04:51:38 | * | Demos_ joined #nimrod |
| 05:17:03 | * | Demos_ quit (Ping timeout: 265 seconds) |
| 05:44:10 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 05:44:18 | * | Demos quit (Remote host closed the connection) |
| 06:10:33 | runvnc | hello |
| 06:10:44 | runvnc | so some exception can return a string with additional information |
| 06:10:51 | runvnc | besides just the name of the exception |
| 06:10:53 | runvnc | is that correct |
| 06:11:02 | runvnc | how can I access that information in the except: block |
| 06:11:07 | runvnc | to echo it |
| 06:11:37 | fowl | getcurrentexceptionmsg() |
| 06:13:01 | runvnc | thanks fowl you are a big help :) |
| 07:18:40 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 07:27:33 | * | Ransel joined #nimrod |
| 07:44:03 | * | DAddYE quit (Remote host closed the connection) |
| 07:55:35 | * | zahary quit (Quit: Leaving.) |
| 08:03:53 | * | gXen joined #nimrod |
| 08:15:05 | * | DAddYE joined #nimrod |
| 08:16:51 | * | DAddYE_ joined #nimrod |
| 08:19:39 | Araq | hi gXen welcome |
| 08:19:45 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 08:20:35 | gXen | Hi Araq |
| 08:21:25 | EXetoC | runvnc: the name would be the actual exception class, along with its msg field. you can look through system.nim too see how it works |
| 08:21:41 | * | DAddYE_ quit (Ping timeout: 265 seconds) |
| 08:24:36 | * | cark joined #nimrod |
| 08:53:50 | * | BitPuffin joined #nimrod |
| 08:57:57 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 08:59:06 | * | nande quit (Read error: Connection reset by peer) |
| 09:17:43 | * | DAddYE joined #nimrod |
| 09:22:35 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 10:18:28 | * | DAddYE joined #nimrod |
| 10:21:19 | * | faassen joined #nimrod |
| 10:23:01 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 10:36:19 | * | BitPuffin joined #nimrod |
| 10:44:34 | BitPuffin | o/ |
| 10:44:37 | * | XAMPP joined #nimrod |
| 10:44:41 | * | XAMPP quit (Changing host) |
| 10:44:41 | * | XAMPP joined #nimrod |
| 10:46:34 | * | Mat3 joined #nimrod |
| 10:46:37 | Mat3 | hello |
| 11:12:07 | Mat3 | after reading the logs, useful documentation for GPU programming is summarized here: http://renderingpipeline.com/graphics-literature/low-level-gpu-documentation/ |
| 11:19:04 | * | DAddYE joined #nimrod |
| 11:23:20 | * | psquid quit (Ping timeout: 252 seconds) |
| 11:23:39 | * | psquid joined #nimrod |
| 11:23:55 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 11:50:47 | * | easy_muffin joined #nimrod |
| 11:51:11 | Skrylar | oh. that's why workbench was blue and orange. it showed up on crappy televisions |
| 11:51:57 | * | psquid quit (Ping timeout: 240 seconds) |
| 11:55:57 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 11:59:20 | * | psquid joined #nimrod |
| 12:17:43 | * | io2 joined #nimrod |
| 12:19:39 | * | lanior joined #nimrod |
| 12:19:54 | * | DAddYE joined #nimrod |
| 12:24:12 | * | DAddYE quit (Ping timeout: 255 seconds) |
| 12:27:26 | * | lanior quit (Quit: Page closed) |
| 12:39:01 | * | vendethiel joined #nimrod |
| 13:20:44 | * | DAddYE joined #nimrod |
| 13:23:16 | * | [1]Endy joined #nimrod |
| 13:24:57 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 13:39:28 | * | easy_muffin quit () |
| 13:56:40 | * | Mat3 quit (Quit: Verlassend) |
| 14:01:17 | * | darkf quit (Quit: Leaving) |
| 14:10:52 | Araq | zahary_: I think we should deprecate anything random related in math.nim |
| 14:11:07 | Araq | these things should be in separate modules |
| 14:11:59 | * | nande joined #nimrod |
| 14:15:25 | EXetoC | who put it in math? that seems a little random |
| 14:21:22 | * | DAddYE joined #nimrod |
| 14:26:08 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 14:28:33 | Skrylar | EXetoC: isn't that where rand() is in C? |
| 14:30:58 | * | Guest73710 joined #nimrod |
| 14:33:37 | * | psquid quit (Ping timeout: 252 seconds) |
| 14:40:29 | renesac | I agree we should have a dedicated random module |
| 14:41:04 | renesac | because there are many more things one could have related to it, let alone many different type of generators |
| 14:42:28 | renesac | for example: http://docs.python.org/2/library/random.html |
| 14:53:43 | * | nolan_d left #nimrod (#nimrod) |
| 14:57:00 | * | easy_muffin joined #nimrod |
| 14:57:54 | Skrylar | i thought about porting mersenne twister over |
| 15:05:04 | Araq | Skrylar: I think that already exists on babel |
| 15:05:21 | Araq | (yeah it's in math.nim because of C's math.h) |
| 15:07:42 | zahary_ | Araq, sure, maybe, dunno, I was mostly acting as a discussion moderator :) random almost sounds like a system.nim material to me |
| 15:08:05 | renesac | there is rand() on system.nim |
| 15:08:11 | renesac | :P |
| 15:08:28 | zahary_ | ah, is randomize affecting it? |
| 15:08:36 | renesac | I don't know |
| 15:09:21 | renesac | proc rand*(max: int): int {.magic: "Rand", sideEffect.} |
| 15:09:21 | renesac | ## compile-time `random` function. Useful for debugging. |
| 15:10:01 | renesac | it looks like a bit out of place to be honest... |
| 15:10:24 | zahary_ | compile-time rand() :P; lisp, take that! |
| 15:10:57 | zahary_ | http://xkcd.com/221/ |
| 15:11:01 | * | Skrylar glares at cast[]. |
| 15:11:16 | Skrylar | Manual says bit pattern. Actual compiler says "i don't feel like casting that" :| |
| 15:17:07 | * | nolan_d joined #nimrod |
| 15:22:22 | * | DAddYE joined #nimrod |
| 15:27:02 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 15:34:51 | Skrylar | Araq: so i found out that apparently the Amiga originally used an interesting GUI model where the actual controls were kept separate from the rest of the program |
| 15:35:03 | Skrylar | interesting to know that this has actually been used in the past |
| 15:40:37 | * | [2]Endy joined #nimrod |
| 15:43:43 | * | [1]Endy quit (Ping timeout: 264 seconds) |
| 15:56:30 | * | Ransel quit (Quit: Connection closed for inactivity) |
| 16:08:33 | * | easy_muffin quit () |
| 16:11:08 | * | easy_muffin joined #nimrod |
| 16:12:42 | * | DAddYE joined #nimrod |
| 16:15:07 | * | easy_muffin quit (Client Quit) |
| 16:17:10 | * | gXen quit () |
| 16:18:17 | * | DAddYE quit (Ping timeout: 255 seconds) |
| 16:33:07 | * | noam quit (Ping timeout: 252 seconds) |
| 16:36:06 | BitPuffin | EXetoC: so punny |
| 16:50:29 | fowl | does using apply to proc definitions |
| 16:50:57 | fowl | probably not |
| 16:55:22 | Skrylar | ugh.. this guy talking about doing smartphone apps and being surprised at how rare it is when CPU/RAM optimization is "necessary"... |
| 16:55:32 | Skrylar | I bet he's one of those people who writes simple smartphone apps that drain your battery : |
| 16:56:19 | Trixar_za | ala whatsapp |
| 16:57:12 | * | DAddYE joined #nimrod |
| 16:59:16 | Skrylar | its just me but i really cringe when i see people throw inefficiency to the wind and i wonder what exactly an A500 does differently than a smartphone that excuses a 30sec-2min startup time |
| 17:01:35 | fowl | my phone takes like 4 minutes to boot up |
| 17:02:49 | Skrylar | last time i touched a physical A500, it took 20-40 seconds to boot because it had to load from a really slow floppy |
| 17:03:33 | Skrylar | i put an SSD in a computer, and windows still takes around 20-40 seconds to boot. What exactly is a modern computer doing that makes the boot time the same speed as a 1990's box? |
| 17:05:02 | Skrylar | i'm not a super optimizer, but something feels *very* wrong |
| 17:06:48 | Skrylar | i like that a simple nimrod program is still very small in binary, which is refreshing from all the new langs that bolt on mandatory megabyte runtimes :| |
| 17:07:37 | fowl | nimrod was made for floppy-disk distribution |
| 17:09:02 | Skrylar | so what you're saying is we should port nimrod to AROS xD |
| 17:09:52 | fowl | yea |
| 17:09:54 | fowl | that sounds fun |
| 17:10:37 | Skrylar | buying the rights to amos is on my pipedream list |
| 17:10:55 | Skrylar | they had to split the OS because there's a patent troll just camping on the amiga rights, so nobody can really do much |
| 17:11:40 | Skrylar | It's really eye opening when you're used to people finding excuses for slow-loading programs, and then you see that someone fit a modern operating system in 20mb of kernel memory |
| 17:16:12 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 17:16:27 | Varriount | Meep |
| 17:28:50 | * | Guest73710 quit (Ping timeout: 265 seconds) |
| 17:33:31 | * | tumak quit (Ping timeout: 245 seconds) |
| 17:37:47 | * | easy_muffin joined #nimrod |
| 17:37:48 | * | easy_muffin quit (Client Quit) |
| 17:37:49 | * | tumak_ joined #nimrod |
| 17:37:51 | * | Guest73710 joined #nimrod |
| 17:43:48 | * | easy_muffin joined #nimrod |
| 17:54:06 | * | q66 joined #nimrod |
| 18:02:15 | * | easy_muffin quit () |
| 18:17:40 | * | noam joined #nimrod |
| 18:21:59 | * | Demos joined #nimrod |
| 18:34:01 | Demos | Skrylar: the stopwatch app I downloaded on my smartphone reduced battery life from 12h to 1.5h and increased the temprature of the phone by like 20C |
| 18:37:44 | EXetoC | :E |
| 18:40:28 | Skrylar | Demos: yep, i bet the developer was one of those "see it works that means its good" |
| 18:40:41 | Demos | hehe |
| 18:40:44 | Skrylar | i know a guy who was like that when he was in comp-sci and it was really aggravating to talk to him |
| 18:40:50 | EXetoC | the battery life is already short as it is |
| 18:41:10 | Skrylar | "no, you need to do it like this because then the type system will prevent screwups" and he decided to use void* because casting was faster |
| 18:41:13 | Skrylar | than learning actual C++ |
| 18:41:35 | * | q66 quit (Ping timeout: 252 seconds) |
| 18:42:59 | Skrylar | admittedly i have some of that in this event code :( to my credit, its handled through a generic so the typecasting is hidden behind an assert to ensure the data fits and comes back out via macro that verifies the types are correct |
| 18:43:36 | * | q66 joined #nimrod |
| 18:43:36 | * | q66 quit (Changing host) |
| 18:43:36 | * | q66 joined #nimrod |
| 18:43:47 | * | brson joined #nimrod |
| 18:44:10 | Demos | honestly sometimes the unsafe solution is actually OK. But dear god use static and dynamic analysis tools |
| 18:45:11 | Skrylar | i still feel ick about the typecast and macro |
| 18:45:38 | Skrylar | its a sensible way of doing it; there's a buffer object of ints and it basically acts as though the input belongs to a union |
| 18:46:15 | Demos | yeah void*s are for when you want to implement type erasure yourself, you need to keep track of the types seperately someplace else |
| 18:46:28 | Skrylar | in this case, there's a UID |
| 18:47:04 | Skrylar | the actual generated code is "if E.uid == 3: let data = <converts from the data>; <do user code here>" where a separate macro has issued 3 to an event type |
| 18:47:20 | Skrylar | Interestingly it also means that event data types are completely unrelated via heirarchy o.O |
| 18:48:25 | Skrylar | i've been wondering about how to expose it to C |
| 18:48:27 | EXetoC | variants \o/ |
| 18:49:16 | Skrylar | I think I can just use exportc to make the queue code available to C/C++, then just call it like it was a C method |
| 18:51:40 | EXetoC | what requires exporting? |
| 18:53:02 | Skrylar | a method to put events in a queue |
| 18:53:16 | Skrylar | in case one was hypothetically using a FLTK frontend to a nimrod program and wanted to shove button notifications over |
| 18:54:16 | * | gXen joined #nimrod |
| 18:54:42 | gXen | syntax highligting for nimrod in sublime text? |
| 18:55:23 | Skrylar | i'm pretty sure theres a plugin entitled "nimlime" that provides that |
| 18:55:55 | gXen | yes. didnt work at first install, but now works |
| 18:56:28 | Demos | gXen: yeah https://github.com/Varriount/NimLime |
| 18:56:42 | Demos | there is an old plugin in package control but it is old |
| 18:57:03 | gXen | yeah, didnt work at first install, came here, reinstalled, now works |
| 18:57:04 | gXen | thx |
| 18:57:05 | Demos | and welcome to nimrod! |
| 18:57:23 | gXen | ty |
| 18:57:41 | Varriount | Unfortunately our plugin is probably going to have to be moved again, into the nimrod-code user's repos, so that I can submit it to package control |
| 18:58:03 | fowl | EXetoC, is opengl #2 good to go |
| 18:58:07 | fowl | looks good |
| 18:58:37 | Varriount | See: https://github.com/wbond/package_control_channel/pull/2884 |
| 18:59:55 | Demos | hey Varriount: I added an example to my lower bound PR |
| 19:00:32 | EXetoC | fowl: I think so |
| 19:01:26 | Varriount | Demos: Hm. Has Araq voiced any other suggestions for your PR on irc? |
| 19:04:38 | fowl | wrapping physfs, because i read something about it and it sounded useful |
| 19:05:11 | * | Demos_ joined #nimrod |
| 19:05:24 | Varriount | Demos: Hm. Has Araq voiced any other suggestions for your PR on irc? |
| 19:05:37 | * | Demos quit (Ping timeout: 240 seconds) |
| 19:05:59 | * | Varriount has his hand hovering on the "Merge PR" button |
| 19:06:34 | Demos_ | well I asked if the function was already in the stdlib and he said no and that I should write it and submit a pr. The function is pretty much a clone of std::lower_bound |
| 19:08:20 | dom96 | Demos_: You should put any inline code in `` `` |
| 19:08:21 | NimBot | Araq/Nimrod devel 0eb2b93 Charlie Barto [+0 ±2 -0]: added lowerBound function to algorithm library |
| 19:08:21 | NimBot | Araq/Nimrod devel 3384537 Charlie Barto [+0 ±1 -0]: made the default comparator for lowerBound unqualified, so the user can customize via two phase lookup |
| 19:08:21 | NimBot | Araq/Nimrod devel 7166683 Charlie Barto [+0 ±1 -0]: added usage example for lower bound |
| 19:08:21 | NimBot | Araq/Nimrod devel 1983904 Varriount [+0 ±2 -0]: Merge pull request #1032 from barcharcraz/lowerBound... 2 more lines |
| 19:08:29 | dom96 | .. |
| 19:08:35 | Demos_ | a little too late :D |
| 19:08:51 | dom96 | ...and the standalone code in a ```nimrod ``` |
| 19:08:56 | Demos_ | is ``` for multi-line inline code, or do I still use ``? |
| 19:09:03 | dom96 | or better lookup the rst way |
| 19:09:11 | dom96 | which is like .. code-block::nimrod or something like that. |
| 19:09:16 | Varriount | Demos_: Submit another PR! Quick! Before the higher powers notice. |
| 19:09:25 | Demos_ | I am in class! |
| 19:09:36 | Demos_ | time to ninja edit |
| 19:09:52 | Varriount | You can use the github webediteor |
| 19:10:16 | Varriount | Although, I don't think you can create a new branch online.. |
| 19:11:09 | Demos_ | yeah I am |
| 19:13:42 | Demos_ | OK I think I fixed it |
| 19:13:57 | renesac | an alternative name for "lowerBond" could be "insertPosition" |
| 19:14:28 | * | xtagon joined #nimrod |
| 19:15:02 | renesac | is there a upperBound equivalent? |
| 19:15:39 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 19:16:11 | Demos_ | no. although mucking about with the comparator could work. C++ has upper_bound but I have never used it. |
| 19:23:48 | Demos_ | sorry about that. Still getting used to rst I guess |
| 19:27:55 | gXen | is runtime for Case linear with amount of case statements, or constant? |
| 19:33:46 | reactormonk | gXen, depends on your expressions and if the compiler can convert it to a lookup table. |
| 19:34:06 | reactormonk | gXen, most likely O(n) in the javascript. |
| 19:34:28 | gXen | reactormonk: you mean if the values are hashable? |
| 19:34:50 | reactormonk | gXen, nah, the C compiler. Not sure if nimrod does optimizations there |
| 19:35:05 | gXen | reactormonk, ok |
| 19:35:38 | reactormonk | gXen, it's going to be the fastest way, unless you go crazy and have 100 case statements |
| 19:36:55 | gXen | reactormonk: just wondering if nested if else statements work faster |
| 19:37:15 | reactormonk | gXen, if they are, that's a bug imo. |
| 19:40:25 | * | Varriount wonders what makes programmers using statically compiled languages prone to pre-optimization |
| 19:46:10 | NimBot | nimrod-code/packages master 518f738 Billingsly Wetherfordshire [+0 ±1 -0]: added physfs |
| 19:46:39 | renesac | gXen, reactormonk : if else statments can be faster if the CPU branch predictor works right |
| 19:47:58 | renesac | if you have a performance critical branch, you should bench it |
| 19:48:02 | renesac | if not, use what fells right |
| 19:48:52 | Demos_ | also, if you have a critical path use VTune or perf or whatever to get real data from the hardware on this stuff |
| 19:49:13 | Varriount | renesac: I always use what looks pretty. |
| 19:49:26 | * | Varriount goes and powders his code |
| 19:49:52 | renesac | Varriount, heh, nothing wrong with that |
| 19:49:55 | Araq | string cases are optimized into a hash table |
| 19:50:14 | Araq | doesn't get much faster than that |
| 19:50:20 | gXen | Araq: what types are ahshable? |
| 19:50:43 | Araq | gXen: 'case' only supports ordinals and strings and perhaps floats |
| 19:50:55 | reactormonk | Araq, doesn't use `hash`? |
| 19:50:58 | * | Araq wonders if he ever implemented 'case' for float |
| 19:51:15 | Araq | reactormonk: nope it uses its own super optimized hash |
| 19:51:26 | gXen | Araq: so if case is applicable, case is always faster |
| 19:51:26 | renesac | you need some kind of rounded comparison in case of float... |
| 19:51:44 | reactormonk | you don't want == for floats anyway |
| 19:51:44 | Araq | renesac: no it is translated into a bunch of == and <= |
| 19:51:50 | * | Mat3 joined #nimrod |
| 19:51:58 | Araq | often you do want == for floats |
| 19:52:03 | Mat3 | good afternoon |
| 19:52:07 | reactormonk | how come? |
| 19:52:17 | Araq | when you know you're performing integer ops with floats |
| 19:52:22 | EXetoC | renesac: what about the claim that "branching is really slow"? does that apply mostly to mispredictions? |
| 19:52:30 | EXetoC | not that I think it's that simple |
| 19:52:31 | renesac | right |
| 19:52:37 | renesac | unpredictable branches are slow |
| 19:52:56 | Araq | gXen: no, 'case' is O(1), but not always faster |
| 19:53:00 | Demos_ | don't worry about branches until you have actual misperdiction data |
| 19:53:14 | renesac | http://igoro.com/archive/fast-and-slow-if-statements-branch-prediction-in-modern-processors/ |
| 19:53:36 | Araq | gXen: you can infuence code generation with .computedGoto and .linearScanEnd pragmas |
| 19:53:44 | gXen | Araq: if you use super optimized hash function, may I assume its not advised to use for large sets due to hash collisions? (I guess <=32bit hash values) |
| 19:54:11 | Demos_ | at that point you may as well just asm the whole thing :D |
| 19:54:28 | Araq | gXen: large sets don't make sense to embed into a case statement anyway |
| 19:54:31 | Mat3 | EXetoC: False predicted branches cost many clock cycles on out-or-order CPU's with large pipelines |
| 19:55:07 | EXetoC | right |
| 19:55:28 | Mat3 | However, common used predictive algorithms are efficient except indirect branches which are poorly predicted (if at all) |
| 19:55:32 | gXen | case of <1mil of >1mil,<5mil of >5mil? sensible? |
| 19:55:42 | Mat3 | ^except for |
| 19:55:47 | EXetoC | I wonder if the mill architecture will ever catch on |
| 19:55:51 | * | Varriount remembers that GameMaker scripting can only use floats. |
| 19:56:29 | Varriount | Which makes it very easy to use CheatEngine on GameMaker games. You only have to search for floats and doubles :3 |
| 19:56:33 | Mat3 | EXetoC: hmm, it's mainly a proof of concept |
| 19:58:52 | EXetoC | I didn't know that. Maybe some refined alternative then |
| 19:59:36 | Varriount | I read a bit on the Mills architecture. It's quite interesting. |
| 19:59:57 | fowl | Varriount, gamemaker is disgusting, discussion of it should be bannable |
| 20:00:05 | Araq | Varriount: yeah watched the latest talk about it |
| 20:00:22 | Araq | the Mill rules but doesn't exist yet :-) |
| 20:00:41 | Varriount | fowl: I know. I haven't touched the actual program myself in /years/, and have never used the script. |
| 20:01:05 | Araq | fowl: bug #1022 (push pragma) is a feature, not a bug |
| 20:01:21 | Varriount | I just.. hear things. Horrible, dreadful things that no sentient being should ever have to hear. |
| 20:01:25 | Araq | because 'push' is so ambiguous the compiler tells you when it can't apply it |
| 20:01:34 | renesac | Araq, I'm not finding it now, but there was some bugreport about telling what 'if' branch was the most likely for the compiler |
| 20:01:46 | Araq | we really need pushProc, pushProcType etc. |
| 20:01:49 | renesac | and the response was that it was already a function, not a pragma |
| 20:01:57 | Araq | yes |
| 20:02:04 | fowl | Araq, you said it was a bug |
| 20:02:04 | renesac | why a function not a pragma? |
| 20:02:31 | Araq | fowl: checked the compiler's source and thus the spec in my head |
| 20:03:14 | Araq | Mat3: branch misprediction seems to be much less severe than a cache miss |
| 20:03:19 | * | Demos_ quit (Ping timeout: 268 seconds) |
| 20:03:52 | Araq | Varriount: I like renesac's name susggestion. "insertPosition" is MUCH better than lowerBound, IMO |
| 20:04:04 | fowl | Araq, well at least importc should not apply to f |
| 20:04:44 | Araq | fowl: it applies to f's pragma |
| 20:04:59 | Araq | I can special case this but I don't know whether it's a good idea |
| 20:05:37 | Araq | (rule of thumb: don't use any name from C++'s STL...) |
| 20:05:37 | renesac | Araq, the question would be what higherBound should be named, if ever added |
| 20:05:40 | EXetoC | insertPositionOf? |
| 20:05:57 | Varriount | Araq: Well, that'll teach me to accept PR's without your explicit presence. :/ |
| 20:06:14 | Araq | no worries |
| 20:06:42 | Varriount | whatWouldSortedPositionBe() |
| 20:06:48 | Araq | renesac: why would it? you can simply flip the comparator, right? |
| 20:07:19 | Araq | hmm 'sorted' should be in its name |
| 20:07:23 | renesac | sortedPosition() |
| 20:07:24 | renesac | ? |
| 20:08:52 | * | Araq wonders what he had in mind when he added system.rand |
| 20:09:08 | Araq | how does a compile time rand help with debugging? |
| 20:09:43 | * | Araq opens a bottle of beer and tries to remember |
| 20:09:45 | renesac | fixed seed for all runs... but there are other ways to do that |
| 20:10:09 | renesac | I can't use the normal random() at compile time? |
| 20:10:35 | renesac | to pre-generate arrays, that sort of thing? |
| 20:10:40 | gXen | I am sure he opened a Maibock |
| 20:10:51 | Varriount | renesac: Try compiling your nimrod compile with -useCffi |
| 20:11:15 | Varriount | Otherwise the VM can only access a limited number of foreign functions at runtime. |
| 20:11:18 | renesac | so, was rand() before that -useCffi got implemented? |
| 20:11:19 | Mat3 | Araq: that depends. For interpreters reducing them is more important for the runtime performance than the general dispatch overhead |
| 20:12:45 | renesac | anyway, it is an obvious candidate to be taken of system.nim, to make it more lean... |
| 20:13:09 | renesac | and in the process rename it to static_rand() or something like that |
| 20:13:44 | Araq | gXen: Tannen-Zäpfle, in fact |
| 20:13:58 | Varriount | Maibock? |
| 20:14:25 | Varriount | Oh, beer. |
| 20:14:51 | Araq | renesac: I'm pretty use rand predates useFFI |
| 20:14:57 | Varriount | Have I mentioned that, to me, anything with alchohol in it tastes of denatured rubbing alchohol? |
| 20:15:06 | Araq | (which is currently broken btw and should stay that way) |
| 20:16:28 | fowl | Varriount, that sucks |
| 20:16:58 | Araq | Varriount: so drink cocktails, most of those are sweet and don't taste like alcohol |
| 20:16:58 | OrionPK | cmp(TTime, TTime) seems to be not working |
| 20:17:11 | Mat3 | Varriount: Just do not consume alcohol |
| 20:17:21 | OrionPK | well i guess it's just generic |
| 20:17:27 | OrionPK | proc cmp*[T](x, y: T): int for TTime |
| 20:17:44 | Araq | TTime doesn't have == and <= ? |
| 20:18:57 | Araq | dom96: now where is that test with gensym and iterators? |
| 20:19:05 | * | gXen left #nimrod (#nimrod) |
| 20:19:16 | Mat3 | hmm, why the heck are comments intentation sensitive ? |
| 20:19:41 | Varriount | Mat3: They are part of the AST |
| 20:19:43 | Araq | Mat3: looked like a good idea back in the days |
| 20:19:55 | Araq | you can do |
| 20:20:07 | Araq | foo #\ |
| 20:20:13 | Araq | # real comment here |
| 20:20:51 | Varriount | Araq: How are doc-comments for type fields supposed to be formatted? I can only seem to place them on the same line as the actual field, which is a bit.. ugly for long doc-comments. |
| 20:21:08 | Araq | read what I just wrote |
| 20:21:12 | Varriount | Oh. |
| 20:21:24 | Varriount | That's still ugly, just less-so |
| 20:21:52 | Araq | changing the comment is handling is planned but more work than it looks like |
| 20:22:03 | Araq | *comment handling |
| 20:22:13 | dom96 | Araq: In my local git repo. |
| 20:22:21 | Varriount | Gotta go, Calculus class calls. |
| 20:22:22 | dom96 | i.e. not online yet |
| 20:22:38 | Mat3 | ciao |
| 20:22:40 | Araq | well you made me work on less important bugs |
| 20:22:47 | Mat3 | Varriount |
| 20:23:35 | * | Demos joined #nimrod |
| 20:23:56 | Araq | sortedPosition is good I think, renesac |
| 20:25:09 | NimBot | Araq/Nimrod devel b41c7f1 Araq [+1 ±2 -0]: fixes #1009 |
| 20:25:09 | NimBot | Araq/Nimrod devel ec57a66 Araq [+0 ±3 -1]: made some tests green |
| 20:25:09 | NimBot | Araq/Nimrod devel 5f6aa76 Araq [+0 ±1 -0]: ENDB: got rid of deprecated 'nil' stmt |
| 20:25:09 | NimBot | Araq/Nimrod devel 62d1e58 Araq [+0 ±2 -0]: fixes a typo |
| 20:25:09 | NimBot | 1 more commits. |
| 20:25:54 | Demos | is lowerBound really that bad? |
| 20:26:58 | Araq | I think it's confusing |
| 20:27:02 | renesac | the name isn't intuitive |
| 20:27:18 | renesac | at least for the proposed use |
| 20:28:15 | Demos | sortedPosition has problems if there are a bunch of elements that compre equal |
| 20:28:59 | Araq | no. why? it's not called stableSortedPosition |
| 20:32:12 | Demos | because it could be the upper end of the range of equal elements, I dont really care that much about the name though |
| 20:33:44 | Araq | you can easily make it stable |
| 20:35:11 | renesac | lowerSortedPosition, if we can't emulate the upperSortedPosition using a different cmp() |
| 20:35:51 | renesac | otherwise, just document that by default it returns the lowest possible insertion position... |
| 20:37:42 | * | Matthias247 joined #nimrod |
| 20:39:51 | Varriount | Mat3: Yes? |
| 20:41:55 | Mat3 | sorry, thought you got to an caculus class |
| 20:42:05 | Mat3 | ^calculus |
| 20:42:14 | Mat3 | (whatever this means) |
| 20:42:54 | * | Mat3 probably have an english misinterpretating day |
| 20:47:38 | Varriount | Mat3: I am. However at the moment, I'm blocking out my teacher, who is currently going over the test we just took. |
| 20:48:48 | * | Varriount doesn't want to know how badly he did on the test. |
| 20:50:11 | Araq | dom96: well please upload the test. It's hard to fix the bug otherwise and I don't feel like debugging your GC corruption |
| 20:52:57 | * | Demos quit (Ping timeout: 240 seconds) |
| 20:53:23 | Mat3 | lunch time, ciao |
| 20:53:28 | * | Mat3 quit (Quit: Verlassend) |
| 21:11:02 | * | DAddYE joined #nimrod |
| 21:15:12 | * | [2]Endy quit (Ping timeout: 255 seconds) |
| 21:22:20 | * | xtagon quit (Quit: Leaving) |
| 21:23:56 | fowl | am i winning the number of babel packages |
| 21:24:01 | fowl | its a contest right? |
| 21:24:31 | dom96 | Hell yeah. |
| 21:24:52 | dom96 | Araq: alright |
| 21:24:59 | fowl | i have two more that just dont work for some reason :/ |
| 21:25:03 | fowl | libjit and mruby |
| 21:25:06 | Araq | dialogs.nim depends on gtk2 so it makes no sense to have it in the stdlib |
| 21:25:25 | Araq | fowl: you know we now have .union, right? |
| 21:25:37 | Araq | somehow I missed your love letter |
| 21:25:44 | fowl | yes |
| 21:25:48 | fowl | ? |
| 21:26:15 | Araq | "omg I love nimrod, it supports unions now" |
| 21:26:50 | fowl | oh |
| 21:27:01 | fowl | well i could always emit a union then importc it :p |
| 21:27:22 | Araq | hmm true |
| 21:27:38 | Araq | .emit is evil though :P |
| 21:33:23 | EXetoC | no, use it everywhere |
| 21:51:11 | NimBot | Araq/Nimrod devel 2d37030 Dominik Picheta [+1 ±0 -0]: Added test for issue #911. |
| 21:51:23 | dom96 | Araq: there you go |
| 21:51:28 | Araq | yay |
| 21:53:22 | fowl | adding seq initialization is hard |
| 21:54:32 | fowl | can i just make the functions private and wrap them in nimrod checks |
| 21:55:35 | * | BitPuffin joined #nimrod |
| 21:56:55 | BitPuffin | oi dom96 you are now officially famous |
| 21:57:17 | dom96 | BitPuffin: Give me the time :P |
| 21:57:23 | BitPuffin | dom96: http://youtu.be/ecJhHqWcZw0 and Araq I suppose, this episode is funner |
| 21:57:41 | dom96 | I don't want to watch it all because I don't want spoilers. |
| 21:58:29 | Araq | dom96: a wise decision |
| 21:59:00 | Araq | BitPuffin: no mods? lol |
| 21:59:08 | BitPuffin | 4:49 is pretty funsies |
| 21:59:11 | fowl | BitPuffin, wheres your avatar from |
| 21:59:17 | BitPuffin | fowl: I made it |
| 21:59:21 | * | faassen quit (Remote host closed the connection) |
| 21:59:21 | fowl | oh |
| 21:59:22 | BitPuffin | it's a puffin |
| 21:59:24 | fowl | programmer art :> |
| 21:59:24 | dom96 | BitPuffin: At what time do I message you? |
| 21:59:25 | BitPuffin | made of bits |
| 21:59:38 | BitPuffin | fowl: well I could only use black or white because it's bits |
| 21:59:39 | EXetoC | it's kinda pixelated |
| 21:59:44 | BitPuffin | either on or off |
| 21:59:47 | BitPuffin | EXetoC: on purpose yeah |
| 21:59:49 | fowl | BitPuffin, btw i took care of al_main, but could you see if we need to do any of the thread stuff that the d wrapper does |
| 22:00:09 | BitPuffin | fowl: I will but not now :( |
| 22:00:15 | fowl | sure |
| 22:00:20 | BitPuffin | great though |
| 22:00:24 | BitPuffin | fucken sweet :D |
| 22:00:27 | EXetoC | and a binary color space |
| 22:00:29 | BitPuffin | is everything wrapped? |
| 22:00:46 | fowl | everything except threads and memfiles |
| 22:00:51 | BitPuffin | dom96: there is magic monkeys in the game *spoiler alert* |
| 22:01:06 | BitPuffin | fowl: ah, well those shouldn't be too much work to bind |
| 22:01:15 | fowl | yea |
| 22:01:28 | fowl | they are low priority honestly |
| 22:01:29 | Araq | BitPuffin: how do you run the game? some emulator? wine? |
| 22:01:35 | EXetoC | windows? |
| 22:01:37 | BitPuffin | Araq: Windows |
| 22:01:54 | Araq | you need to attach it to a single cpu core |
| 22:01:55 | BitPuffin | fun fact though, the Mac version just runs it in wine |
| 22:02:00 | BitPuffin | why? |
| 22:02:05 | Araq | otherwise it's buggy like hell |
| 22:02:18 | Araq | they got the threading all wrong, I think |
| 22:02:24 | EXetoC | :o |
| 22:02:34 | BitPuffin | Araq: interesting, well I haven't noticed any big bugs |
| 22:02:41 | BitPuffin | except for a disappearing monkey |
| 22:02:47 | fowl | how old is this game/ |
| 22:02:59 | BitPuffin | pretty old |
| 22:03:08 | dom96 | why would it use other cores? |
| 22:03:08 | BitPuffin | late 90s maybe? early 2000s? |
| 22:03:19 | dom96 | in those days all CPUs were single core, no? |
| 22:03:38 | Araq | dom96: yeah but threads existed before |
| 22:03:49 | BitPuffin | dom96: 14:30 is where you message me |
| 22:03:50 | Araq | and can be convenient for programming |
| 22:04:01 | BitPuffin | you sabotaging cunt :P |
| 22:04:07 | dom96 | :D |
| 22:04:09 | Araq | especially if you don't know about their dangers ;-) |
| 22:05:01 | dom96 | LOL |
| 22:05:19 | BitPuffin | disappearing monkey at15:50 |
| 22:05:24 | EXetoC | yeah slightly more convenient than manual interleaving :> |
| 22:05:31 | dom96 | "Yes Dom, you're fucking famous" |
| 22:05:45 | BitPuffin | dom96: you should at least like the video you bitch :( |
| 22:06:02 | dom96 | I'll do more. I'll put it in my favourites! |
| 22:06:12 | BitPuffin | waoaoaoa |
| 22:06:14 | BitPuffin | thank yaaa |
| 22:06:17 | BitPuffin | and sub? lol |
| 22:06:19 | BitPuffin | ;D;D;D; |
| 22:06:23 | * | BitPuffin is a whore |
| 22:06:29 | dom96 | Hell yeah, why not. |
| 22:07:01 | BitPuffin | because all you want to do is to destroy xD |
| 22:07:17 | BitPuffin | Araq: them monkeys though |
| 22:07:21 | BitPuffin | somewhat hilarious |
| 22:07:45 | EXetoC | Why aren't you begging for likes and subscribes? You don't know how to youtube |
| 22:08:01 | fowl | this game looks creepy |
| 22:08:27 | BitPuffin | EXetoC: I don't like to do it |
| 22:08:36 | BitPuffin | because I think it's annoying when people do it |
| 22:09:01 | dom96 | You should put some subliminal messages into your videos. Like a single frame with a big "SUBSCRIBE NOWWWWW" every 5 minutes :P |
| 22:09:03 | BitPuffin | I guess I'm fine with more like like if you liked and subscribe if you wont more if not then that's aight |
| 22:09:09 | BitPuffin | haha |
| 22:09:13 | BitPuffin | like subtle whispers |
| 22:09:24 | BitPuffin | *subscribe, ibe, ibe, ibe* |
| 22:09:29 | fowl | ill subscribe just for your avatar |
| 22:09:37 | BitPuffin | "like, ike, ike" |
| 22:09:41 | BitPuffin | fowl: you like it? |
| 22:09:55 | BitPuffin | It's based off my old one |
| 22:10:01 | BitPuffin | which was just a photo from google |
| 22:10:13 | BitPuffin | now I made it more matching to the name with bits, and also it's my creation |
| 22:11:07 | fowl | what license is it |
| 22:11:15 | BitPuffin | my avatar? |
| 22:11:18 | fowl | yea |
| 22:11:25 | * | DAddYE_ joined #nimrod |
| 22:11:37 | BitPuffin | copyright? lol |
| 22:11:41 | Araq | dude, press U to hear the audio log immediately |
| 22:11:51 | BitPuffin | Araq: jeez, thanks |
| 22:11:55 | BitPuffin | seriously thanks XD |
| 22:12:10 | BitPuffin | I didn't look for it in the menu, but I thought there gotta be one |
| 22:12:57 | Araq | you can jump and smash the camera |
| 22:13:17 | Araq | or use the gun |
| 22:13:35 | * | DAddYE quit (Read error: Connection reset by peer) |
| 22:14:55 | fowl | gah these controls are crazy |
| 22:15:07 | fowl | qwes for movement and a/d for leaning? |
| 22:15:38 | BitPuffin | Araq: yeah but it doesn't always die in one hit does it? |
| 22:15:42 | Araq | you can modify every key binding, fowl |
| 22:15:43 | BitPuffin | and the gun is good to save |
| 22:15:46 | BitPuffin | for the shotgun guys |
| 22:15:51 | BitPuffin | fowl: yeah I modified that |
| 22:16:34 | EXetoC | BitPuffin: even when headshotting? |
| 22:16:43 | EXetoC | that should be a one-shot kill always |
| 22:16:51 | * | DAddYE joined #nimrod |
| 22:16:52 | BitPuffin | EXetoC: it's an RPG |
| 22:16:59 | BitPuffin | but yeah it might do more dmg |
| 22:17:08 | BitPuffin | plus, we are not facing like regular humans |
| 22:17:17 | BitPuffin | these are aliens taking over humans |
| 22:17:20 | EXetoC | still |
| 22:17:24 | BitPuffin | it's a nice detail that they still are somewhat human |
| 22:17:28 | BitPuffin | they say kill me and stuff |
| 22:17:32 | BitPuffin | and run |
| 22:17:41 | * | Demos joined #nimrod |
| 22:18:38 | * | DAddYE_ quit (Ping timeout: 240 seconds) |
| 22:20:13 | * | DAddYE_ joined #nimrod |
| 22:22:14 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 22:22:20 | * | Demos quit (Ping timeout: 255 seconds) |
| 22:22:57 | * | Skrylar quit (Ping timeout: 240 seconds) |
| 22:25:30 | EXetoC | Turning OpenGL constants into enumerators is fun, isn't it? it's like a puzzle when you have about 40 of them that need to be ordered |
| 22:26:26 | BitPuffin | XD |
| 22:26:33 | BitPuffin | then why do it |
| 22:26:35 | BitPuffin | there is no gain |
| 22:27:32 | fowl | BitPuffin, which branch is the most awesome |
| 22:27:51 | fowl | EXetoC, thats probably why they were constants |
| 22:28:31 | BitPuffin | fowl: depends on what project |
| 22:32:46 | fowl | BitPuffin, system shock 2, idk what u mean project |
| 22:33:02 | fowl | ill just go navy, they are one of the intelligent branches |
| 22:35:32 | EXetoC | fowl: that's just the way it's officially structured, and I guess not many people bother to do that manually |
| 22:35:37 | EXetoC | and this just adds to the pain |
| 22:36:25 | BitPuffin | fowl: that's the one I wanted to pick |
| 22:36:29 | BitPuffin | but I accidentally picked marine lol |
| 22:36:48 | EXetoC | BitPuffin: there might be if enough people use it |
| 22:36:59 | EXetoC | A small gain, but a gain nevertheless :> |
| 22:51:16 | * | Demos joined #nimrod |
| 22:54:00 | EXetoC | BitPuffin: Have a taste of the awesomeness "proc setTexParamSwizzleRGBA*(target: TTexParamTarget, param: var array[4, TSwizzleColor])" |
| 22:55:42 | BitPuffin | EXetoC: regarding what? |
| 22:55:47 | BitPuffin | oh right |
| 22:55:50 | BitPuffin | the enums |
| 22:56:06 | EXetoC | hm, but does that apply to every TTexParamTarget enumerator? that is the question :-) |
| 23:07:18 | Araq | good night |
| 23:08:15 | Demos | is there a way to export a whole module, or should I use the include statement |
| 23:09:32 | fowl | export modulename |
| 23:10:07 | Demos | oh, if I import folder/modulename I have to export just modulename |
| 23:10:08 | Demos | k |
| 23:10:46 | fowl | yea beacuse the module's name is modulename |
| 23:11:18 | * | Matthias247 quit (Quit: Matthias247) |
| 23:11:42 | EXetoC | is that the same thing? I did try that, but ended up exporting symbols explicitly |
| 23:11:51 | EXetoC | so it must've not worked somehow |
| 23:20:42 | EXetoC | Demos: it works for you? |
| 23:20:48 | Demos | kyeah |
| 23:24:19 | EXetoC | I think it was that I wanted "export opengl except TRect" |
| 23:25:25 | EXetoC | apparently there's some windows type in there called TRect, and you currently can't selectively exclude when exporting |
| 23:25:31 | EXetoC | cya |
| 23:25:32 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 23:27:38 | BitPuffin | Demos: I was gonna point something out about eigen earlier but now I forgot because you weren't here |
| 23:39:01 | * | darkf joined #nimrod |
| 23:53:33 | * | flyx quit (Ping timeout: 252 seconds) |
| 23:54:42 | * | flyx joined #nimrod |
| 23:58:24 | * | reloc0 quit (Ping timeout: 252 seconds) |
| 23:58:41 | * | reloc0 joined #nimrod |