| 00:03:53 | * | gsingh93_ quit (Ping timeout: 265 seconds) |
| 00:04:12 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:05:51 | * | gsingh93 quit () |
| 00:11:25 | * | gsingh93- is now known as gsingh93 |
| 00:14:23 | * | gsingh93_ joined #nimrod |
| 00:38:13 | Skrylar | EXetoC: is the opengl module you were working on usable? |
| 00:42:57 | Jehan_ | Eep. |
| 00:43:15 | Jehan_ | The number of workers useable by spawn is hardcoded as 4? |
| 00:43:34 | Varriount | Jehan_: spawn is still in the alpha stage at the moment. |
| 00:44:00 | Jehan_ | Yeah, I was wondering why the hell I was capped at 400% CPU usage on a 64-core machine. :) |
| 00:44:10 | Jehan_ | Okay, createThread() it is. :) |
| 00:44:13 | Varriount | You have a 64 core machine? |
| 00:44:38 | Varriount | I take it you're not using the average home desktop then? |
| 00:45:14 | EXetoC | Skrylar: yes. it triggered an ICE for Demos though |
| 00:45:48 | Varriount | Whatever OpenGl wrapper I used for the OpenGl tutorials I followed works. |
| 00:46:01 | * | DAddYE_ quit (Remote host closed the connection) |
| 00:46:42 | EXetoC | well I rewrote it 2-3 weeks ago |
| 00:47:04 | Varriount | Why? |
| 00:48:08 | Jehan_ | Technically, I could use a Cray XE, but someone would be very unhappy if I spent research money there for experimenting with Nimrod. |
| 00:48:26 | Varriount | Jehan_: Yeah, but what are you currently using? |
| 00:48:30 | Jehan_ | And the reason is that I have access it for work. |
| 00:48:44 | Jehan_ | At home, an iMac or Macbook Pro. |
| 00:49:09 | Jehan_ | The 64 core machines are just standard AMD Opteron machines. |
| 00:50:02 | Skrylar | oh joy. i get to fiddle with more stuff: http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf |
| 00:50:05 | EXetoC | Varriount: I replaced the old one that is, which wasn't implemented by me. I added some missing symbols and optionally automatic error handling |
| 00:55:21 | Skrylar | apparently valve made up some weird thing where you blur a font texture and it makes it so you can scale it up/down... Qt uses it in one place |
| 00:55:53 | Varriount | Skrylar: I skimmed through that paper. Looks really neat. |
| 01:00:18 | * | njoejoe quit (Ping timeout: 240 seconds) |
| 01:03:25 | Skrylar | Varriount: yeah, i might have to rethink some of my text rendering code |
| 01:03:50 | Skrylar | apparently QML uses that technique so they don't have to make a glyph cache for every font size, you just made a single one and zoom |
| 01:04:25 | * | njoejoe joined #nimrod |
| 01:04:38 | * | gsingh93_ quit (Ping timeout: 255 seconds) |
| 01:05:44 | * | Jesin joined #nimrod |
| 01:05:51 | Varriount | I don't suppose any of you guys has used ReadDirectoryChanges in combination with IO completion ports before? |
| 01:16:59 | njoejoe | Varriount: I haven't. not sure these are the magical search keys, but sometimes i search github for key functions to get started: https://github.com/search?q=CreateIoCompletionPort+ReadDirectoryChanges&ref=searchresults&type=Code |
| 01:19:26 | Varriount | njoejoe: Thanks for the tip about github. |
| 01:21:24 | * | gsingh93_ joined #nimrod |
| 01:21:28 | * | gsingh93_ quit (Client Quit) |
| 01:31:23 | Jehan_ | If anyone wants to look at a parallel version of the codegolf example: |
| 01:31:26 | Jehan_ | https://gist.github.com/rbehrends/cf84a2cd8b407f4fc612 |
| 01:32:06 | Jehan_ | I still have to find an eight core machine to compare it to the C++ version, but I expect it should compare reasonably well. |
| 01:32:14 | Jehan_ | Despite not pulling any dirty tricks. |
| 01:32:35 | Jehan_ | Anybody who needs context: http://codegolf.stackexchange.com/questions/26371/how-slow-is-python-really-part-ii |
| 01:32:48 | Demos | a day well spent :D |
| 01:33:12 | Jehan_ | Not really a day, more like a couple of hours total. :) |
| 01:33:52 | njoejoe | need a version of nimrod > 0.9.4? (12, 18) Error: undeclared identifier: 'TThread' |
| 01:34:28 | Varriount | njoejoe: Import threading. |
| 01:34:32 | Jehan_ | need to compile with --threads:on |
| 01:34:50 | Varriount | Nimrod needs a joke module, like python and braces. |
| 01:34:59 | Jehan_ | nimrod cc --threads:on -d:release --passc:-flto |
| 01:35:16 | njoejoe | worked. and FAST! |
| 01:35:17 | Jehan_ | --passc:-flto only for clang. |
| 01:35:43 | Varriount | I dunno if flto will work for me, being on windows and such. |
| 01:35:53 | Jehan_ | Yeah. The credit largely goes to clang (Nimrod insofar as it produces C code that the C compiler can optimize well). |
| 01:36:07 | Jehan_ | Just skip -flto, that's just another 10% or so. |
| 01:36:25 | Jehan_ | It's mostly so that the RNG call can be inlined. |
| 01:36:47 | Jehan_ | What is interesting is that tail recursion leads to faster code here than using a loop with break. |
| 01:36:49 | Demos | you can use /LTGC on windows I think |
| 01:37:00 | Demos | also -flto works with gcc |
| 01:37:17 | Demos | in fact I thought the "proper" way to do it with clang was to use some kind of "emit llvm" command |
| 01:37:35 | Varriount | Demos: Yeah, I know. However I've heard that -flto on gcc is unstable. |
| 01:37:57 | Jehan_ | But really, the interesting part is that this is a fairly faithful implementation without speed hacks and is still competitive. |
| 01:38:25 | njoejoe | 0.2 seconds on my machine vs 70 seconds for pypy |
| 01:39:10 | Jehan_ | How many cores/hyperthreading? |
| 01:39:40 | Jehan_ | On my fairly old quadcore it's about 0.34 seconds vs 89 for PyPy. |
| 01:40:13 | Jehan_ | On 64 cores with as many threads about 0.07 seconds, a good part of which is startup time. :) |
| 01:40:18 | njoejoe | Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (4 cores) |
| 01:41:14 | Jehan_ | I'll probably give it a review tomorrow (to make sure I don't have any inadvertent bugs) and post it then. |
| 01:42:20 | * | gsingh93_ joined #nimrod |
| 01:43:42 | njoejoe | just think how fast it could be with hardware RNG! http://wiki.openssl.org/index.php/Random_Numbers#Hardware :-) |
| 01:44:43 | Varriount | Oh wonderful. Even without -flto, the codegolf thing doesn't work for me. It just crashes. |
| 01:45:05 | Varriount | T_T |
| 01:45:33 | Jehan_ | Bug in the code or in the compiler? |
| 01:46:11 | Varriount | It compiles correctly, but when I run the resulting binary, I get a straight crash. Even without -d:release, there's no stack trace. |
| 01:46:36 | Varriount | Observing the process with Process Monitor doesn't reveal anything. |
| 01:47:27 | Jehan_ | Sounds like something goes wrong in one of the threads. |
| 01:48:09 | Varriount | Demos: Have been able to compile it with VCC? If so, what command did you use? |
| 01:48:35 | Demos | the codegolf thing? |
| 01:48:40 | Varriount | Yeah. |
| 01:49:07 | * | DAddYE joined #nimrod |
| 01:52:37 | Demos | yeah it segfaults |
| 01:52:42 | Demos | locks.nim line 137 |
| 01:53:06 | Varriount | You got stack trace information? |
| 01:53:41 | * | DAddYE quit (Ping timeout: 255 seconds) |
| 01:54:36 | Demos | working on it |
| 01:56:28 | Jehan_ | Ugh, lock may need to be initialized. |
| 01:57:20 | Jehan_ | Yeah, that'd be it. |
| 01:58:56 | Jehan_ | Okay, updated it, and got a bit more speed out of it, too. |
| 02:00:41 | Varriount | Um. It finished instantly. |
| 02:00:43 | Jehan_ | This is where the lack of constructors really bites you. |
| 02:00:44 | njoejoe | 0.185s for me |
| 02:01:04 | Varriount | (Now how do I get timing information) |
| 02:01:11 | Jehan_ | Heh. |
| 02:01:27 | Jehan_ | A really good stopwatch and fast reactions? :) |
| 02:01:47 | Jehan_ | On Unixes, it's just the time command. |
| 02:01:53 | Demos | I got 344 ticks |
| 02:02:02 | Demos | Measure-Command |
| 02:02:08 | njoejoe | very impressive. i notice no use of "spawn". is spawn not the way to use multicore with nimrod? |
| 02:02:09 | Demos | so from a visual studio command prompt you type: |
| 02:02:23 | Jehan_ | Spawn is currently capped at four worker threads. |
| 02:02:23 | Demos | @powershell Measure-Command {./golf.exe} |
| 02:02:33 | Varriount | njoejoe: Spawn is still in the very early stages of development. |
| 02:02:36 | Jehan_ | I used spawn initially, but then was told it was alpha still. |
| 02:02:53 | njoejoe | gotcha |
| 02:03:40 | Demos | 3.56 million clock ticks |
| 02:03:41 | renesac | how much smaller would the code be using spawn? |
| 02:03:50 | Jehan_ | Not much. |
| 02:04:01 | Jehan_ | The createThread() calls would be replaced by spawns. |
| 02:04:12 | Jehan_ | And the joinThread() loop by a single sync(). |
| 02:04:15 | renesac | the performance should be the same, right? |
| 02:04:38 | Jehan_ | Pretty much, except that right now you can spawn at most four threads at once. |
| 02:04:47 | renesac | yeah, I know |
| 02:05:09 | Jehan_ | As a matter of fact, performance is roughly the same for me with spawn on a quadcore machine. |
| 02:05:28 | renesac | using more threads than cores helps? |
| 02:05:28 | Varriount | Jehan_: Are you going to submit that to the codegolf page? |
| 02:05:35 | renesac | or hurts? |
| 02:05:41 | Jehan_ | Yeah, tomorrow, after I've had time to sleep on it. |
| 02:06:19 | Jehan_ | Depends on what you're doing. |
| 02:06:26 | renesac | in this benchmark |
| 02:06:36 | Jehan_ | In this benchmark, it shouldn't matter much. |
| 02:06:43 | Jehan_ | Except if you've got hyperthreading. |
| 02:07:42 | Jehan_ | The effect of hyperthreading is a bit unpredictable. Should help, but doesn't always. |
| 02:08:29 | Varriount | I noticed noone used PHP on that codegolf page. :3 |
| 02:08:44 | Jehan_ | Wonder why. :) |
| 02:09:26 | Varriount | It would be interesting to see what a Forth implementation would look like. |
| 02:09:30 | renesac | we need a nimrod->brainfuck compiler |
| 02:09:48 | Jehan_ | Speak for yourself. :) |
| 02:09:53 | Demos | ah randomly flipping signs in my shaders fixed my problem |
| 02:10:13 | Varriount | Demos: The programmer equivalent of mashing buttons to get things working. |
| 02:11:39 | Demos | all too common with graphics code |
| 02:11:56 | Demos | I bet we could automate this a bit |
| 02:11:59 | * | superfunc joined #nimrod |
| 02:14:37 | Varriount | Hi superfunc |
| 02:14:51 | superfunc | wassup |
| 02:18:21 | Demos | got it to 309s with LTCG |
| 02:19:11 | Varriount | Wait, so it's actually /slower/? |
| 02:19:18 | * | superfunc quit (Ping timeout: 240 seconds) |
| 02:19:20 | Demos | sorry 309ms |
| 02:19:26 | Demos | it was 344 before |
| 02:20:22 | Varriount | Demos: Is there a way to tell the measure command to choose the best time out of a predetermined count? |
| 02:20:44 | Demos | I dun know |
| 02:25:26 | Varriount | Hm. Enabling flto with gcc doesn't really lower the min speed I get (300ms) |
| 02:27:26 | Jehan_ | Yup, I was using -flto with clang, where it did help. |
| 02:27:39 | Jehan_ | Code optimization is a black art, anyway. |
| 02:28:18 | Jehan_ | As I said, it surprised me that tail recursion was actually faster than using break. |
| 02:28:30 | Varriount | Oddly enough, with -flto enabled the timings are more erratic/varied. |
| 02:28:56 | Jehan_ | There is some unavoidable randomness either way. |
| 02:29:20 | * | Jesin quit (Ping timeout: 246 seconds) |
| 02:31:47 | Jehan_ | Anyhow, time to get some sleep, even though it's a holiday tomorrow (today?). Night! |
| 02:32:09 | Varriount | Goodnight! |
| 02:32:22 | * | Jehan_ quit (Quit: Leaving) |
| 02:33:09 | Varriount | Demos: When I compile with vcc, I get timings in the 470ms range. |
| 02:33:49 | * | DAddYE joined #nimrod |
| 02:35:39 | Demos | well PGO did nothing, which is not suprising for such a small app |
| 02:37:23 | Varriount | Goodnight Demos, et al |
| 02:37:57 | njoejoe | gnite Varriount |
| 02:40:12 | * | gsingh93_ quit () |
| 02:40:44 | * | Jesin joined #nimrod |
| 03:06:51 | * | superfunc joined #nimrod |
| 03:07:15 | superfunc | Varriount: my bad, forgot I had to go talk with a teacher |
| 03:19:29 | * | superfunc quit (Quit: Page closed) |
| 04:01:01 | * | xenagi quit (Quit: Leaving) |
| 04:42:14 | * | bjz joined #nimrod |
| 04:51:06 | * | menscrem joined #nimrod |
| 05:28:48 | * | [1]Endy joined #nimrod |
| 05:33:06 | * | darithorn quit (Ping timeout: 240 seconds) |
| 05:36:09 | * | DAddYE quit (Remote host closed the connection) |
| 05:36:35 | * | DAddYE joined #nimrod |
| 05:40:47 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 05:52:38 | * | DAddYE joined #nimrod |
| 06:05:47 | * | superfunc joined #nimrod |
| 06:07:25 | * | nande quit (Read error: Connection reset by peer) |
| 06:09:48 | * | superfunc quit (Ping timeout: 240 seconds) |
| 06:42:48 | * | menscrem quit (Ping timeout: 240 seconds) |
| 07:18:35 | * | Demos quit (Read error: Connection reset by peer) |
| 07:22:02 | * | olahol quit (Quit: Lost terminal) |
| 07:49:42 | * | skyfex joined #nimrod |
| 07:54:26 | * | DAddYE quit (Remote host closed the connection) |
| 07:55:00 | * | DAddYE joined #nimrod |
| 08:00:11 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 08:13:30 | * | springbok quit (Ping timeout: 240 seconds) |
| 08:32:57 | * | Matthias247 joined #nimrod |
| 08:56:58 | Araq | hi skyfex wb |
| 09:03:41 | Skrylar | wow libjpeg's headers are old |
| 09:03:51 | Skrylar | does nimrod even have a 'far pointer'? |
| 09:06:10 | skyfex | Araq: hi, been a while :) |
| 09:08:00 | skyfex | fyi, I have a little program that's used every day at work now |
| 09:08:07 | skyfex | written in Nimrod |
| 09:08:29 | skyfex | Gonna upload the code to github soon.. but it's hideous at the moment though |
| 09:11:53 | * | io2 joined #nimrod |
| 09:16:07 | * | io2 quit (Client Quit) |
| 09:23:12 | * | menscrem joined #nimrod |
| 09:23:45 | menscrem | hi all |
| 09:24:41 | * | io2 joined #nimrod |
| 09:26:27 | * | [2]Endy joined #nimrod |
| 09:27:53 | Skrylar | hi menscrem |
| 09:30:21 | * | [1]Endy quit (Ping timeout: 265 seconds) |
| 09:31:02 | Skrylar | Araq: well i found a new way to stress test c2nim |
| 09:31:10 | Skrylar | throw an archaic libjpeg header at it |
| 09:31:21 | Skrylar | they're full of absolutely horrible things like #defines for constants in the MIDDLE of a structure |
| 09:32:17 | * | io2 quit (Remote host closed the connection) |
| 09:32:19 | * | [1]Endy joined #nimrod |
| 09:32:59 | * | io2 joined #nimrod |
| 09:33:19 | * | io2 quit (Remote host closed the connection) |
| 09:33:25 | skyfex | There, it's up on Github: https://github.com/skyfex/kiosk |
| 09:35:39 | * | io2 joined #nimrod |
| 09:36:23 | * | [2]Endy quit (Ping timeout: 276 seconds) |
| 09:38:17 | Skrylar | skyfex: your screenshots contain errors, so says firefox :( |
| 09:42:35 | skyfex | Skrylar: Works for me :P |
| 09:42:55 | skyfex | even in FF |
| 09:43:02 | skyfex | but it's old though |
| 09:44:04 | Araq | cool |
| 09:44:05 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 09:44:14 | Araq | the screenshots work for me |
| 09:44:55 | * | io2 joined #nimrod |
| 09:45:31 | Skrylar | i'll try on a different computer |
| 09:48:33 | Skrylar | works over there |
| 09:48:37 | Skrylar | i wonder whats wrong with my ff |
| 09:49:45 | * | io2 quit (Client Quit) |
| 09:51:01 | * | io2 joined #nimrod |
| 09:53:45 | * | io2 quit (Client Quit) |
| 09:55:36 | * | io2 joined #nimrod |
| 09:55:57 | * | io2 quit (Remote host closed the connection) |
| 10:02:11 | * | uvelichitel joined #nimrod |
| 10:15:20 | Skrylar | huh. |
| 10:15:40 | Skrylar | i went and checked how godot does fonts.. it also does fixed-size premade bitmaps and has hell with asian fonts |
| 10:16:21 | Skrylar | i think the auto-packing font thing i had planned for nimrod coupled with the distance field technique for scalable fonts might actually be state of the art xD |
| 10:17:50 | * | njoejoe quit (Quit: Page closed) |
| 10:18:20 | * | njoejoe joined #nimrod |
| 10:19:59 | * | [2]Endy joined #nimrod |
| 10:23:33 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 10:31:24 | * | [1]Endy joined #nimrod |
| 10:34:05 | * | [2]Endy quit (Ping timeout: 246 seconds) |
| 10:37:02 | dom96 | skyfex: Awesome, you should make a video showing it in action :D |
| 10:41:19 | Araq | we got our first spam bot |
| 10:41:35 | Araq | that means we need a new captcha |
| 10:42:21 | Araq | the idea behind the current one was that nobody would bother to solve it since it's not used anywhere else |
| 10:44:50 | dom96 | aww, did you remove it already? |
| 10:44:52 | dom96 | What did it say? |
| 10:49:39 | dom96 | and how do you know it was a spam bot? |
| 10:49:55 | Skrylar | the account was named spammusbutt333 |
| 10:50:08 | Araq | it was about losing weight made easy |
| 10:50:19 | dom96 | So? Maybe a human solved the captcha. |
| 10:51:01 | * | [2]Endy joined #nimrod |
| 10:52:01 | Araq | true |
| 10:55:02 | * | [1]Endy quit (Ping timeout: 276 seconds) |
| 11:25:13 | * | springbok joined #nimrod |
| 11:25:47 | * | springbok quit (Changing host) |
| 11:25:47 | * | springbok joined #nimrod |
| 11:38:59 | skyfex | dom96: I will, but right now it's text based.. I want a flash graphical UI first :P |
| 11:40:54 | EXetoC | oh no |
| 11:45:53 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 11:46:24 | * | BitPuffin joined #nimrod |
| 12:35:20 | * | wan joined #nimrod |
| 12:41:23 | wan | Araq: I've converted a nicer-looking captcha (still using cairo) if you want: https://gist.github.com/idlewan/d1e8d0af59e93a78274d |
| 12:45:11 | * | uvelichitel quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 13:02:50 | Araq | wan: a screenshot would be nice ... ;-) |
| 13:04:46 | dom96 | Araq: look at the comment in the gist |
| 13:08:40 | Araq | ok. That's pretty hard to read for a human being though. |
| 13:10:57 | wan | Yes, well, it's a captcha |
| 13:11:30 | wan | It wouldn't be one if it was easy to read for a human (thus for a machine as well) |
| 13:12:27 | wan | but it's possible to tune the opacity of the circles |
| 13:12:36 | Araq | well the point of the current captcha is that it is simple to read and yet requires math :P |
| 13:13:03 | Araq | so that you have to adapt the captcha solver |
| 13:13:16 | Araq | and since that's work people wouldn't do it |
| 13:19:10 | wan | You can still display "3+999" as text, but have it more readable by changing the 0.4 opacity in the set_source_rgba to something less opaque |
| 13:19:26 | * | darkf quit (Quit: Leaving) |
| 13:25:10 | wan | by the way, in the current nimforum code, are captcha files ever deleted? Or does someone purges the folder manually? |
| 13:27:13 | Araq | iirc they are re-used |
| 13:30:10 | * | Jehan_ joined #nimrod |
| 13:31:46 | wan | ah, mod 10000 on the id, missed that |
| 13:41:14 | * | uvelichitel joined #nimrod |
| 13:42:53 | * | lesshaste joined #nimrod |
| 13:42:56 | lesshaste | hi |
| 13:43:06 | lesshaste | is there a nimrod compiler for ubuntu? |
| 13:44:49 | uvelichitel | Hi. Can I somehow express proc(arg: doable): in meaning my proc would be happy with arg of any type if it has method arg.dosomething implemented? |
| 13:45:04 | * | wan quit (Quit: leaving) |
| 13:52:12 | Jehan_ | uvelichitel: I think what you're looking for is parametric polymorphism (a.k.a. generic types). |
| 13:55:19 | Jehan_ | proc f[T](arg: T) = |
| 13:55:19 | Jehan_ | mixin dosomething |
| 13:55:19 | Jehan_ | dosomething(arg) |
| 13:55:19 | Jehan_ | proc dosomething(x: int) = |
| 13:55:19 | Jehan_ | echo x |
| 13:55:19 | Jehan_ | f(99) |
| 13:56:09 | uvelichitel | Jehan_: I see. Thanks |
| 13:56:14 | Jehan_ | Templates (i.e., macros) can also accomplish the same thing. |
| 13:57:20 | Jehan_ | template g(arg: expr): stmt = |
| 13:57:20 | Jehan_ | dosomething(arg) |
| 13:57:20 | Jehan_ | g(100) |
| 13:57:29 | Jehan_ | But be careful with those. |
| 14:00:14 | Jehan_ | User-defined type classes allow you to specify more specific constraints than "mixin" does, but I believe they're still somewhat beta-ish. |
| 14:03:34 | * | lesshaste quit (Quit: Leaving) |
| 14:19:29 | Araq | yeah they are beta-ish and what's worse they don't yet affect symbol binding rules, so 'mixin' is still necessary. sometimes. |
| 14:20:03 | OrionPK | lesshaste nimrod should work on ubuntu just fine |
| 14:20:34 | Araq | symbol binding rules are the hardest part in nimrod's design, I wonder if we'll ever get them "right" |
| 14:21:13 | Jehan_ | Binding in conjunction with metaprogramming is always hard. I'm not sure it's even possible to properly define "right". :) |
| 14:22:19 | Jehan_ | Incidentally, I got some more performance out of the codegolf example and posted it: http://codegolf.stackexchange.com/questions/26371/how-slow-is-python-really-part-ii/26479#26479 |
| 14:23:56 | dom96 | Argh, I can't upvote it. |
| 14:24:33 | Jehan_ | You probably don't have enough rep. In any event, I'm just as happy with people not stuffing the ballot box. :) |
| 14:25:01 | dom96 | Yeah, I need 15. In any case, great job! |
| 14:25:42 | Jehan_ | The really interesting part is how pointless some of the micro optimizations you can try are. |
| 14:25:53 | Jehan_ | Some of the stuff I experimented with made things even worse. |
| 14:26:01 | Jehan_ | Even though it was impossible to tell why. |
| 14:26:30 | Jehan_ | Even when they didn't obviously did to pipeline stalls, branch mispredictions, or confused the optimizer. |
| 14:26:50 | Jehan_ | s/did to/lead to/ |
| 14:27:54 | Araq | yeah. modern cpus are just too strange |
| 14:28:06 | Araq | I recently timed: |
| 14:28:17 | Araq | for i in 0..10_000: inc globalVar |
| 14:28:19 | Araq | vs. |
| 14:28:28 | Araq | for i in 0..10_000: inc localVar |
| 14:28:34 | Jehan_ | I also note that since Nimrod compiles to C, you can obviously get the exact same performance in C/C++. :) |
| 14:28:49 | Araq | atomicInc(globalVar, localVar) |
| 14:29:06 | Jehan_ | Oh! Do you know that nimrod cpp --threads:on doesn't seem to work? |
| 14:29:06 | Araq | and got no difference beyond the measurement noise |
| 14:29:38 | Araq | was multi-threaded ofc, so the accesses to the shared global should kill it |
| 14:29:46 | Araq | but didn't |
| 14:29:51 | Jehan_ | Hmm, what exactly did you compare? the increment of the global and local variables or vs. atomic increments? |
| 14:30:25 | Araq | well the benchmark was more complex |
| 14:30:43 | Araq | but this was one difference that I tried |
| 14:31:10 | Jehan_ | There's generally no way around atomic operations being expensive. |
| 14:31:32 | Araq | well it was done in a branch |
| 14:31:33 | Jehan_ | But local vs. global -- wouldn't be surprised there. |
| 14:31:45 | Araq | maybe I got the basic frequencies wrong |
| 14:31:55 | Araq | and so what's in the branch didn't matter |
| 14:32:24 | Jehan_ | The thing about atomic operations is that they essentially ignore caches and write/read directly to/from main memory. |
| 14:32:42 | Jehan_ | To put it somewhat simplistically, it's actually a bit more complicated on modern processors. |
| 14:33:21 | Jehan_ | So, there's an unavoidable 50 clock cycle lag, give or take, for any code that depends on an atomic instruction. |
| 14:34:01 | Jehan_ | Of course, for code that doesn't depend on it, and if it happens infrequently, it might not be that bad. |
| 14:34:17 | dom96 | Araq: Is the profiler still broken? |
| 14:34:34 | Araq | dom96: I didn't fix it |
| 14:34:35 | Jehan_ | On the other hand, it was much worse on older CPUs (where atomic instructions essentially locked down the memory bus entirely). |
| 14:34:38 | OrionPK | Jehan_ whats the speed diff? |
| 14:34:50 | Jehan_ | OrionPK: Between what and what? |
| 14:35:17 | OrionPK | every other post has a 50x speedup" |
| 14:35:18 | OrionPK | " |
| 14:35:29 | OrionPK | except yours |
| 14:35:59 | Jehan_ | No, the C++ implementation has a 500+ speedup or so on eight cores. |
| 14:36:34 | Jehan_ | On my quadcore machine, I go from 89 seconds to .15 seconds (gcc-4.9, -flto). |
| 14:36:41 | Jehan_ | Which is also a little over x500. |
| 14:37:06 | OrionPK | comparing apples and oranges? |
| 14:37:13 | OrionPK | different algorithms to produce the same result? |
| 14:37:34 | Jehan_ | No, my algorithm is actually pretty faithful to the original. |
| 14:37:42 | OrionPK | oh ok |
| 14:37:47 | OrionPK | nice |
| 14:38:20 | dom96 | Jehan_: Maybe you should include the '500x' beside "Nimrod" (in the title) |
| 14:38:49 | Jehan_ | dom96: I could, but I'm not big on advocacy. :) |
| 14:39:12 | * | Jesin quit (Quit: Leaving) |
| 14:39:22 | * | darithorn joined #nimrod |
| 14:39:26 | Jehan_ | It's down in the text for anybody who really cares, with proper context of how the speedup is measured. |
| 14:39:46 | OrionPK | I'm big on consistency :P |
| 14:39:51 | OrionPK | ur post is not consistent w/ the other posts |
| 14:40:02 | Jehan_ | In what way? |
| 14:44:15 | OrionPK | in not having a speed difference from the op |
| 14:45:10 | Jehan_ | The OP is in Python, there should be a difference? |
| 14:46:24 | dom96 | The only inconsistency as far as I can see is that the "500x" is not in the title. |
| 14:46:31 | dom96 | It is mentioned in the text. |
| 14:46:57 | Araq | Jehan_: I read http://www.1024cores.net/home/scalable-architecture/parallel-disk-io/the-solution and I think our thead pool should get some magic to activate as many threads as is reasonable and adapt the number to the workload |
| 14:46:57 | Jehan_ | Yup. And it's speedup on an architecture that's different from what the other people (or the OP) use. |
| 14:48:27 | Jehan_ | I'm not sure I understand what you mean by that? |
| 14:48:53 | Araq | well I only have some vague ideas |
| 14:49:25 | Jehan_ | Do you mean not starting more threads than is necessary initially and create new workers on demand? |
| 14:49:35 | Araq | but --threads:on could profile IO operations and try to see if it's IO bound or CPU bound at runtime |
| 14:50:29 | Araq | Jehan_: yes, creating new workers on demand, or perhaps start with a high number but disable most of these initially |
| 14:50:44 | Jehan_ | Probably don't want to start a high number. |
| 14:51:07 | Jehan_ | Threads require resources (such as stack memory). |
| 14:51:37 | Araq | yeah but fixed size arrays are nice :P |
| 14:51:39 | Jehan_ | Also, some architectures may have only a limited number of threads available to support. |
| 14:51:54 | Jehan_ | Yeah, but no need to prepopulate them. :) |
| 14:51:58 | Araq | well "many" is still <= 256 here |
| 14:52:11 | Araq | but anyway, that's just a detail |
| 14:52:15 | Jehan_ | I'm thinking of having hundreds of processes with hundreds of threads each. :) |
| 14:55:34 | Jehan_ | And interesting, I didn't know that rawProc and rawEnv existed. |
| 14:56:37 | Jehan_ | I have to say, much as the rough corners of Nimrod frustrate me at times, the sheer amount of work that has gone into it is pretty darn impressive. |
| 14:57:31 | Jehan_ | Eh, s/corners/edges/ |
| 14:57:57 | renesac | Jehan_, you can use the new syntax for array declaration |
| 14:58:01 | renesac | just the lenght |
| 14:58:05 | renesac | not a range |
| 14:58:06 | Araq | thanks |
| 14:58:13 | Araq | I need to go, bbl |
| 14:58:20 | Jehan_ | Yes, I know. That's not even that new. |
| 14:58:29 | Jehan_ | I prefer to be explicit about ranges, though. |
| 14:59:23 | renesac | and have you tried {.inline.} and {.noinit.} as micro-optimizations? |
| 14:59:52 | Jehan_ | -O3 -flto already does inlining automatically. |
| 15:00:08 | Jehan_ | {.inline.}, as I recall, just puts an inline on the corresponding C function. |
| 15:00:26 | renesac | an additional hint to the compiler |
| 15:00:40 | Jehan_ | Yeah, and the compiler usually knows better what it does. |
| 15:00:43 | renesac | but probably don't changes |
| 15:01:12 | Jehan_ | From my brief glimpse at the disassembly, pretty much all of it ends up in one big assembly routine either way. |
| 15:01:17 | renesac | last I heard, gcc decided to inline or not based on line count |
| 15:01:24 | renesac | right |
| 15:01:45 | Jehan_ | And {.noinit.} is not useful anywhere, even if I wanted to use it. |
| 15:01:53 | renesac | and how about {.noinit} for the vectors? |
| 15:01:54 | Jehan_ | It's actually not based on line count, but IR size. |
| 15:02:58 | Jehan_ | That would avoid only a couple of initializations once per thread. |
| 15:03:04 | OrionPK | you mean noinit is not useful in your code? |
| 15:03:19 | OrionPK | I've had big performance improvements from using noinit |
| 15:03:25 | Jehan_ | OrionPK: exactly. |
| 15:04:12 | renesac | oh, you re-use the same vector many times |
| 15:04:22 | Jehan_ | The only place where I could avoid the initialization is mainThread(). |
| 15:04:37 | Jehan_ | Which does not even amount to a rounding error. |
| 15:04:53 | renesac | yeah, I didn't saw that you reuse the same vectors |
| 15:05:20 | renesac | and have you tried a xorshift PRNG? |
| 15:05:40 | Jehan_ | The big advantage over C is: I can turn on bound checks, suffer virtually no performance loss, and get automatic memory safety. |
| 15:05:48 | Jehan_ | The code uses the xorshift RNG now. |
| 15:05:52 | OrionPK | how often do you call random |
| 15:05:54 | renesac | oh, now I see that you replaced for your own |
| 15:05:56 | OrionPK | you could do noinit on that |
| 15:06:09 | Jehan_ | Partly because the Mersenne generator in the lib has some inefficiencies. |
| 15:06:23 | Jehan_ | There's no use for noinit in random(). |
| 15:06:49 | Jehan_ | The only local variable in random has to be initialized and is (from the RNG state). |
| 15:07:09 | OrionPK | the result variable is initialized |
| 15:07:17 | OrionPK | and then overwritten |
| 15:07:23 | Jehan_ | Yes, and the compiler optimizes that away. |
| 15:07:27 | OrionPK | does it? |
| 15:07:29 | OrionPK | it didnt used to |
| 15:07:36 | renesac | OrionPK, : only once per thread, right? |
| 15:07:42 | Jehan_ | Using {.noinit.} on ints is a waste of time. :) |
| 15:07:51 | OrionPK | true renesac |
| 15:07:53 | renesac | ^ |
| 15:08:07 | Jehan_ | And introduces potential bugs. |
| 15:08:08 | renesac | {.noinit.} is for vectors and other objects |
| 15:08:19 | Jehan_ | If I wanted to risk that, I'd write C in the first place. |
| 15:08:27 | renesac | ints the compiler really optimizes the initialization away |
| 15:08:34 | Jehan_ | {.noinit.} is to be used only after careful consideration on performance-critical code. |
| 15:09:31 | renesac | and you really should put the speedup on the title, like everybody else |
| 15:09:42 | Jehan_ | Not without context. :) |
| 15:09:48 | renesac | people won't care to look at a text wall for a speed up of 5 |
| 15:10:02 | Jehan_ | I'm an academic, posting under my real name. |
| 15:10:11 | Jehan_ | If it works, the OP will put it in the main post. |
| 15:10:36 | renesac | context like the number of cores? |
| 15:10:46 | renesac | or the full context of every optimization you tried and failed? |
| 15:10:48 | renesac | :P |
| 15:10:51 | Jehan_ | Architecture, number of cores, yeah. |
| 15:10:58 | renesac | C++: x200 (4-core i7, should scale to x400 on 8-core) |
| 15:11:03 | renesac | <-- like that guy? |
| 15:11:14 | renesac | it is not difficult |
| 15:11:34 | Jehan_ | Like that, but I'd also like someone else to review it first. |
| 15:11:51 | Jehan_ | As I said, advocacy is not my thing. I leave that to dom96. :) |
| 15:12:03 | renesac | it is like any claim in a title, if you are catch by it, you will read the rest of the article to see exactly how they got it |
| 15:12:37 | Jehan_ | Incidentally, the C++ header may overstate its claim. |
| 15:12:47 | Jehan_ | You do not necessarily see a linear speedup. |
| 15:13:09 | Jehan_ | I peaked out at a 35ish speedup or so on a 64-core machine, and only after increasing iters. |
| 15:13:31 | Jehan_ | Even going from 4 to 8 threads didn't quite double the speed. |
| 15:13:48 | renesac | right |
| 15:13:59 | Jehan_ | Performance numbers just don't make good soundbites. |
| 15:17:57 | renesac | and the ubuntu user asking for nimrod for it's os probably didn't find it with apt-get |
| 15:18:11 | Jehan_ | The Ubuntu user is the OP, alas. :) |
| 15:18:53 | Jehan_ | For what it's worth, I tried and installed it on a RedHat system the other day from Git, just following the instructions there, so it shouldn't be too hard. |
| 15:19:07 | renesac | did we ever had an debian/ubuntu package? |
| 15:19:17 | Jehan_ | No idea. |
| 15:19:19 | renesac | yeah, but apt-get is easier |
| 15:19:39 | Jehan_ | Oh, I agree. Push-button solutions are always easier. Problem is, someone has to prepare them. :) |
| 15:19:59 | renesac | only heard of arch-linux having a nimrod package |
| 15:20:08 | Jehan_ | I should probably look into submitting a PR for Homebrew. |
| 15:20:15 | renesac | yeah, nothing in computers is easy until someone makes it so... |
| 15:20:18 | * | wan joined #nimrod |
| 15:20:19 | Jehan_ | Which is still on 0.9.2 |
| 15:22:03 | dom96 | niminst can generated deb packages |
| 15:22:31 | dom96 | if someone wants to create a 0.9.4 .deb I can include it on the download page |
| 15:22:32 | Jehan_ | I think the work is more navigating the Debian bureaucracy. |
| 15:22:41 | Jehan_ | To have it included there. |
| 15:22:58 | dom96 | oh yeah, including it in the debian repos is a lot more work. |
| 15:25:01 | wan | Round 9 results of the web framework benchmarks: https://news.ycombinator.com/item?id=7680261 |
| 15:25:33 | wan | Nimrod is not bad on the updates test: http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=update |
| 15:25:56 | dom96 | it's been a while since round 8 |
| 15:26:08 | dom96 | glad they are still doing them |
| 15:26:15 | dom96 | New async should be ready for round 10! |
| 15:26:47 | Jehan_ | Hmm, under what name is Nimrod participating there? |
| 15:26:47 | wan | And there is room to grow for nawak (augment workers from 42 to 256 will surely get more for 'updates' test) |
| 15:26:49 | renesac | have you done any optimization between rounds 8 and 9? |
| 15:26:54 | renesac | Jehan_, jester |
| 15:26:55 | wan | Nawak |
| 15:27:02 | wan | and jester too for json test |
| 15:27:11 | renesac | ops |
| 15:27:13 | renesac | yea |
| 15:27:14 | renesac | h |
| 15:27:20 | Jehan_ | Ah, I didn't see Jester, which is why I asked. |
| 15:27:52 | dom96 | I wonder why nawak is missing from EC2 on the data updates test |
| 15:27:55 | renesac | jester is in another tab |
| 15:28:08 | wan | It's missing too from peak |
| 15:28:16 | dom96 | yeah |
| 15:29:07 | renesac | lua is on top of the single query benchmark |
| 15:29:15 | Jehan_ | While I hate optimizing code for benchmarks, JSON is useful enough in general that performance may be worth looking at for other use cases, too. |
| 15:29:17 | dom96 | interesting that nawak performs worse than jester on the json test |
| 15:30:21 | wan | I don't know why nawak isn't on ec2 and peak. Maybe they had trouble installing Mongrel2 or something, but they did it manually on i7. |
| 15:30:48 | dom96 | jester isn't on ec2 either |
| 15:32:59 | dom96 | maybe they didn't want to spend any more money on ec2 |
| 15:33:48 | wan | nawak in its current form has probably a lot of overhead (Mongrel2 handling http, passing on through zeromq to nawak) and it will never take the lead for the not-so-important brute tests (json, plaintext). However it is trivial to add workers, and this fact only boosts the concurrency level when slow operations (db) is involved. |
| 15:34:03 | wan | Fortunes test is winnable (http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=fortune) |
| 15:34:33 | dom96 | wan: indeed. Good job :) |
| 15:34:51 | dom96 | Hopefully new async will also help nawak. |
| 15:35:24 | wan | We'll have to update nimrod's version too, I pinned to an end-of-december commit previously. |
| 15:35:42 | dom96 | indeed |
| 15:35:57 | wan | I'm realy |
| 15:36:06 | wan | *really interested in new async |
| 15:36:20 | wan | however we have to make db wrappers async too |
| 15:36:21 | Jehan_ | Random aside: One of the killer features of Nimrod for me is that I can package the compiler with any software I'm writing. |
| 15:36:33 | Jehan_ | In source form, no less. |
| 15:36:54 | Jehan_ | That isn't really practical with, say, Mono. |
| 15:36:59 | dom96 | wan: That's good to hear, may still take some time before new async is fully functional and well tested though. |
| 15:40:44 | wan | With new async, jester should be able to surpass Mongrel2+nawak on everything, if it works correctly and you use a db connection pool |
| 15:41:12 | * | bjz quit (Ping timeout: 245 seconds) |
| 15:46:26 | dom96 | wan: heh, looks like we both commented about Nimrod at the same time |
| 15:46:55 | dom96 | I'll delete my comment and reply to yours |
| 15:49:05 | wan | kay thanks |
| 15:49:28 | dom96 | there |
| 15:50:17 | dom96 | oh dear, looks like someone beat you to it: https://news.ycombinator.com/item?id=7680242 |
| 15:51:03 | dom96 | your link isn't even on the front page anymore :( |
| 15:51:15 | dom96 | wan: can you make the some comment in that thread? |
| 15:51:32 | Jehan_ | HN is a bit like roulette in that way. :) |
| 15:51:38 | wan | yes, I think it got removed from the standard listing |
| 15:51:49 | wan | dom96: I'll do that |
| 15:51:53 | EXetoC | still not number one :/ good job still! |
| 15:53:11 | dom96 | EXetoC: we'll get there |
| 15:53:21 | wan | Yes but room to grow! I purposefully only used ~40 workers instead of 256 to keep hopes up for further rounds |
| 15:53:50 | Jehan_ | Just remember that people still use Rails and Django, despite their performance. :0 |
| 15:53:56 | renesac | Jehan_, here I get a 432x speedup with 3 threads |
| 15:54:06 | Jehan_ | Language ecosystem matters a LOT. |
| 15:54:40 | dom96 | Jehan_: True. But currently we have neither best speed nor best ecosystem. |
| 15:54:42 | Jehan_ | renesac: Nice, I'm just curious why you picked 3? :) |
| 15:54:59 | EXetoC | dom96: rly, ok :> |
| 15:55:00 | renesac | runing on a VM with 3 visible cores |
| 15:55:01 | wan | Jehan_: Yes, that's why micro-frameworks that are sinatra-like and still very fast will be quite attractive |
| 15:55:07 | Jehan_ | Gotcha. |
| 15:56:06 | wan | cpoll_cppsp implementations for example are really fast but horrible to look at |
| 15:56:10 | Jehan_ | In all fairness, most of the credit for Nimrod's performance should go to the authors of the C optimizer. :) |
| 15:56:37 | Jehan_ | Though it helps a lot that Nimrod generates pretty idiomatic C (not a trivial task, either). |
| 15:57:04 | renesac | hey, we get credit too, for allowing you to use those nice optimizers |
| 15:57:09 | renesac | also that |
| 15:57:33 | Jehan_ | But really, languages like Nimrod outshine C for larger programs. |
| 15:57:42 | Jehan_ | Where it's really hard to make C code both fast and safe. |
| 15:57:49 | dom96 | Perhaps most of the credit should go to the CPU engineers? :P |
| 15:58:21 | dom96 | wan: let me know when you comment |
| 15:59:13 | wan | already did, I just copied over my comment |
| 15:59:36 | Jehan_ | It got autokilled. |
| 15:59:40 | Jehan_ | Because it's a duplicate. |
| 15:59:57 | Jehan_ | Shows up as [dead] for me. |
| 16:00:16 | dom96 | ahh, explains why I can't see it. |
| 16:00:22 | * | untitaker quit (Ping timeout: 245 seconds) |
| 16:00:31 | dom96 | HN has so many invisible rules |
| 16:01:00 | Jehan_ | Well, they're designed to maximize the signal/noise ratio, not make it easy to advertise your stuff. :) |
| 16:01:29 | dom96 | hehe true |
| 16:02:27 | wan | I changed it a little. Can you see it, or should I repost? |
| 16:02:37 | dom96 | I think you need to repost |
| 16:02:56 | Jehan_ | Still dead. I don't think you can edit it once dead. |
| 16:03:29 | Jehan_ | I'd recommend just letting it sit until you have a context to post it in, though. |
| 16:03:51 | Jehan_ | Right now it looks too much like an ad and may get hit by a downvote storm anyway. |
| 16:05:18 | Jehan_ | I'd add something like: "Disclaimer: I'm the author of Nawak, so I'm pretty excited about this." |
| 16:05:30 | wan | Good point |
| 16:05:33 | Jehan_ | Assuming you are the author of Nawak (guessing here). |
| 16:05:45 | wan | yep |
| 16:06:14 | * | untitaker joined #nimrod |
| 16:08:59 | Jehan_ | But in general, hackers being happy about their work doing well in a contest get a much different reception on HN than fanboys appearing to hawk something. |
| 16:09:55 | wan | Alright, I've tried again. Let me know if it gets invisible |
| 16:10:42 | Jehan_ | Can see it, yeah. |
| 16:12:15 | wan | Jehan_: (I used your introduction sentence, it was so clear that I didn't change it. Thanks!) |
| 16:14:50 | * | Johz joined #nimrod |
| 16:15:52 | Johz | Hello, is there an obvious way of making sublists that I'm missing? |
| 16:16:17 | * | superfunc joined #nimrod |
| 16:16:23 | Johz | I'm trying to iterate over the arguments list, having already dealt with the first argument. |
| 16:17:11 | dom96 | hi Johz. list[0..3] should work. Is that what you mean? |
| 16:17:37 | Johz | Yep, that's exactly it. Knew I was missing something! :P |
| 16:21:00 | * | easygreasy joined #nimrod |
| 16:25:01 | EXetoC | that's a copy operation btw |
| 16:26:19 | Varriount | Hi easygreasy |
| 16:27:07 | easygreasy | Varriount: hi there |
| 16:27:48 | * | superfunc quit (Ping timeout: 240 seconds) |
| 16:29:27 | easygreasy | so, a new version of Nimrod (9.4)popped up on the Arch repos which reminded me that I wanted to try it out, I remember skimming through the tutorials many moons ago, but I find I learn/grok best by looking at actual project code, anyone with some suggestions? |
| 16:31:02 | EXetoC | the compiler? :) |
| 16:31:20 | Jehan_ | Wouldn't recommend the compiler. That might be a bit daunting as a first look. |
| 16:31:41 | easygreasy | EXetoC: heh |
| 16:31:42 | Jehan_ | Just consider the size, 40k lines of not exactly trivial code. |
| 16:32:00 | dom96 | Here is a good list https://github.com/trending?l=nimrod :) |
| 16:32:01 | Jehan_ | Someone should probably do http://www.ic.unicamp.br/~meidanis/courses/mc336/2009s2/prolog/problemas/ for Nimrod. :) |
| 16:33:23 | easygreasy | btw are there bindings for opengl, glfw, perhaps sdl2 ? |
| 16:33:59 | EXetoC | all of those |
| 16:34:04 | dom96 | ^ |
| 16:34:21 | easygreasy | EXetoC: sweet :) |
| 16:35:05 | easygreasy | anyone been experimenting with some 'higher-level' game 2d frameworks in nimrod? |
| 16:36:31 | * | Demos joined #nimrod |
| 16:37:32 | EXetoC | there's a graphics module and then plenty of wrappers, but not that much high level stuff |
| 16:37:54 | EXetoC | there are at least 1-2 engines in the works that haven't been released yet |
| 16:38:18 | easygreasy | EXetoC: ok, just figured I'd ask as it's something I'd probably like to try as a nimrod project (simple 2d game engine) |
| 16:38:19 | dom96 | there is nimgame |
| 16:39:30 | easygreasy | dom96: sounds interesting, is it an actual game or a framework? |
| 16:39:40 | dom96 | a framework |
| 16:39:53 | EXetoC | I wonder if it compile |
| 16:39:56 | dom96 | https://github.com/Vladar4/nimgame |
| 16:40:06 | dom96 | Yeah, it's a bit old now |
| 16:40:09 | Demos | easygreasy: cairo! |
| 16:40:13 | Demos | cairo is pretty good |
| 16:40:32 | EXetoC | cairo seems like a great lib indeed |
| 16:41:35 | easygreasy | cairo as in the vector gfx library? |
| 16:41:52 | Demos | yeah |
| 16:42:19 | easygreasy | haven't considered that for 2dgame development |
| 16:42:21 | EXetoC | but I can't remember if hardware acceleration worked well on windows |
| 16:42:37 | easygreasy | but I may have missed something |
| 16:42:58 | Demos | it will be slower than custom GL calls, but likely not slower than something like love or pygame |
| 16:43:03 | Demos | or god forbid game maker |
| 16:43:27 | Demos | you can load up bitmaps and use them as a source I think |
| 16:43:35 | EXetoC | shouldn't matter much, depending on how well it batches things |
| 16:44:27 | easygreasy | ok, looking through the babel package manager source code right now, looks very neat and concise, which reflects well on the nimrod language I suppose |
| 16:45:40 | easygreasy | the T for type and P for pointer (?) prefix is that a hardline convention amongst nimrod developers, can't say I personally find it pleasing but I guess it's more a 'get used to' deal |
| 16:45:46 | Demos | easygreasy: well it was written by one person :D but yeah the package manager is nice |
| 16:45:56 | Demos | easygreasy: some people do not do it |
| 16:46:05 | Jehan_ | easygreasy: I ignore Hungarian notation myself. |
| 16:46:10 | Demos | personally I use T but not P (I just use ref TFoo and whatnot) |
| 16:46:32 | Demos | Jehan_: it is not really Hungarian notation though since these are type names and not variable names |
| 16:46:42 | Jehan_ | I use FooRef and FooObj in the rare cases where I need to distinguish between objects and references to them. |
| 16:48:33 | easygreasy | Jehan_ lol, yes now that was a horrid time in my development life, WINAPI... |
| 16:49:40 | Jehan_ | Luckily, type inference allows you to ignore the type names 99% of the time. |
| 16:52:24 | * | DAddYE joined #nimrod |
| 16:54:16 | easygreasy | Jehan_: ok, good, so I won't be crucified if I write code which doesn't use the T/P convention |
| 16:54:49 | * | gsingh93 quit (Quit: ZNC - http://znc.in) |
| 16:55:05 | Jehan_ | I think you'll find that Nimrod as a language isn't very opinionated. |
| 16:55:21 | Jehan_ | It even allows for OOP, even though the primary author isn't a fan of it. |
| 16:56:00 | Jehan_ | Another example: it's specifically case-insensitive (even underscores are optional) so that people aren't forced to use the conventions of third-party libraries. |
| 16:56:39 | Demos | funny, I found nimrod to be quite opinionated, just not on stupid things :D |
| 16:56:40 | Jehan_ | There's still a style guide for the core, but the general attitude seems to be more "live and let live". |
| 16:57:15 | Jehan_ | Demos: Then you haven't written code in Ada or Eiffel or Haskell or … :) |
| 16:57:35 | easygreasy | isn't that T/P prefixa Delphi thing btw? I seem to recall that but my memory is what it is... |
| 16:57:39 | Jehan_ | Yup. |
| 16:57:53 | Jehan_ | Nimrod has its roots in the Pascal family of languages. |
| 16:58:16 | easygreasy | oh, case-insensitive, that's an interesting choice |
| 16:58:20 | Jehan_ | Even the syntax in general is Pascal-likes (except Pythonesque white space blocks instead of begin end). |
| 16:58:30 | Jehan_ | Pascal-like* |
| 16:59:14 | * | gsingh93 joined #nimrod |
| 16:59:17 | Jehan_ | I have always preferred Pascal's syntax over C's, so that's actually a selling point for me. |
| 16:59:39 | Jehan_ | But it's interesting to see how many people have never encountered a Pascal-like language in their life. |
| 16:59:42 | EXetoC | "syntax doesn't matter too much" is a lie :p |
| 16:59:55 | Jehan_ | "Type names AFTER variables? How odd." |
| 17:00:14 | Varriount | Back. (I was commuting to class) |
| 17:00:23 | Jehan_ | EXetoC: Google "Sapir-Whorf hypothesis". |
| 17:00:28 | Demos | Jehan_: I have written a tad bit of haskell (not enough to really internalize all the crazy shit those people do) but nirmod came across as being opinionated in terms of having "flat" code and good code-locality |
| 17:00:52 | Varriount | easygreasy: If you want a look at conventional nimrod code, look at the standard library, or dom96's Jester framework. |
| 17:01:07 | Jehan_ | Code locality, yet it has include? |
| 17:01:11 | easygreasy | I do like that it compiles to c which allows you to make use of the excellent optimizating compilers with years of effort put into generating efficient code, it's a big selling point for me, that and the python style indentation |
| 17:01:22 | easygreasy | Varriount: thanks, will do |
| 17:01:38 | Varriount | Though, for the sake of sanity, do not try to understand the compiler unless you have several bottles worth of aspirin. |
| 17:01:59 | Varriount | (Not that the compiler code is badly written, it's just very complex) |
| 17:02:18 | Jehan_ | Compiling to C is a bit of a double-edged sword. |
| 17:02:21 | Demos | and somewhat crufty, it was apperently translated from Pascal |
| 17:02:44 | Jehan_ | I think it's overall a benefit, but it also makes a few things hard. |
| 17:03:05 | Jehan_ | Like anything that involves inspecting stack frames. |
| 17:03:17 | EXetoC | that's just one of the outputs |
| 17:03:45 | easygreasy | Varriount: heh, no I don't have any such aspirations, I own two books on compiler development, they are still in pristine mint condition after all these years, hohum... |
| 17:03:46 | Jehan_ | I still think it's the best choice for the primary backend of a new compiler. |
| 17:05:35 | EXetoC | inspecting stack frames? you normally just need to view the nimrod stack, and that works as expected |
| 17:05:51 | Varriount | Jehan_: For what it's worth, I don't think the include directive is used anywhere in the *pure* standard library. |
| 17:05:54 | Jehan_ | EXetoC: Try to implement a precise garbage collector. |
| 17:06:17 | Jehan_ | The standard library uses include internally quite a bit? Or what do you mean? |
| 17:06:42 | Varriount | The modules in the pure directory? |
| 17:06:43 | Jehan_ | I don't have a problem with include, actually. I think it's a good thing that it exists. |
| 17:08:16 | menscrem | Prompt, why does not work?: a = 10'u - 2'u |
| 17:08:21 | Jehan_ | They do have a fair amount of includes, yeah? |
| 17:08:29 | Varriount | Ok, I was wrong, the modules in the pure directory do use include, but only for the runtime library |
| 17:09:00 | Jehan_ | menscrem: import unsigned |
| 17:09:44 | EXetoC | Varriount: runtime library, in pure? |
| 17:10:04 | Jehan_ | Varriount: Realistically, it's often helpful to break down a large module into smaller ones without needing implementation hiding between the smaller modules. |
| 17:10:38 | menscrem | Jehan_: oh, exactly, thanks |
| 17:10:54 | * | q66 joined #nimrod |
| 17:10:55 | * | q66 quit (Changing host) |
| 17:10:55 | * | q66 joined #nimrod |
| 17:11:10 | Demos | actually yeah, why are libs in pure importing symbols from dlls? |
| 17:11:23 | fowl | Demos, which |
| 17:11:30 | Jehan_ | Araq considers unsigned arithmethic dangerous by default, because it can wrap around, so you need to enable it. |
| 17:11:31 | Demos | well os does |
| 17:11:55 | Demos | people love to use unsigned numbers for no good reason, so we make it harder for them to do that |
| 17:12:05 | Jehan_ | E.g.: for i in 0..x-1 breaks if x == 0 and x is unsigned. |
| 17:12:18 | fowl | os is a special case, its also full of when defined(platform) stuff that implies non-pure-nimrod code |
| 17:13:00 | Demos | yeah |
| 17:13:19 | renesac | Jehan_, it also currently breaks if x == x.high |
| 17:13:20 | renesac | :P |
| 17:13:35 | Jehan_ | renesac: Yeah, but that's a far less likely situation. |
| 17:14:15 | renesac | I'm not sure... |
| 17:14:49 | renesac | as those 'x-1' are usually used to iterate in vectors and things like that |
| 17:14:54 | Jehan_ | If you work with numbers that can be that large, then both int and uint are generally the wrong choice. |
| 17:15:33 | renesac | where in nimrod you can just 'for i in vec' |
| 17:15:49 | renesac | 128 or 256 aren't that big |
| 17:15:50 | renesac | :P |
| 17:16:15 | renesac | and I first encountered this problem making a unittest with uint32 |
| 17:16:29 | Jehan_ | Oh, I'm not saying that it can't happen. |
| 17:16:32 | renesac | and yes, uint32 is the right choice |
| 17:16:42 | renesac | for that thing |
| 17:17:00 | * | q66 quit (Quit: Leaving) |
| 17:17:54 | renesac | well, in the things I program, I aways end up using uints and their wrap around semantics... |
| 17:18:20 | renesac | I really hope someday they can be a 1st class citizen in nimrod... |
| 17:18:32 | Jehan_ | Yeah, I often use that, too, but for those situations, "import unsigned" isn't a big burden. |
| 17:18:56 | renesac | well, my problem isn't just that |
| 17:19:06 | fowl | my parser combinator builds trees now: {"left": {"I": "1"}, "op": "+", "right": {"left": {"I": "3"}, "op": "-", "right": {"I": "2"}}} |
| 17:19:06 | Jehan_ | My personal problem is more that mod is broken for signed ints. |
| 17:19:11 | fowl | :>~ |
| 17:19:18 | renesac | Jehan_, it is not broken |
| 17:19:31 | Jehan_ | From a mathematician's perspective, it is. |
| 17:19:48 | Jehan_ | That's not Nimrod's fault, though, that's the fault of CPU designers primarily. |
| 17:20:00 | renesac | Jehan_, see this table: |
| 17:20:00 | renesac | http://en.wikipedia.org/wiki/Modulo_operation |
| 17:20:23 | renesac | there is no standard... |
| 17:20:53 | renesac | but yeah... what nimrod calls 'mod' is usually called 'rem' in languages that use letters for those operators |
| 17:22:13 | Jehan_ | Yup. And in mathematics, x mod n \in {0,…,n-1} pretty much always. |
| 17:23:09 | Jehan_ | mod creates equivalence classes (congruence modulo n), and it makes no sense to have two representations for the same equivalence class. |
| 17:23:46 | renesac | things that are annoying with uints: in c: "if(x)", in nimrod: "if (x == 0'u32)" |
| 17:24:28 | renesac | and having to convert to int for array indexing, etc |
| 17:24:47 | renesac | those are open bugs... |
| 17:25:41 | Jehan_ | Array indexing I buy. |
| 17:25:45 | Jehan_ | The "if" not. |
| 17:26:22 | renesac | buy? |
| 17:26:48 | Jehan_ | I mean, I agree that this is a misfeature. |
| 17:26:50 | EXetoC | renesac: x == 0 is enough in this case |
| 17:26:53 | EXetoC | it's really minor |
| 17:27:00 | renesac | EXetoC, no, it is not |
| 17:27:07 | renesac | that is a open bug |
| 17:27:24 | renesac | and yeah, nimrod don't need the parenthesis |
| 17:27:27 | renesac | that is a plus |
| 17:27:52 | * | q66 joined #nimrod |
| 17:27:52 | * | q66 quit (Changing host) |
| 17:27:53 | * | q66 joined #nimrod |
| 17:27:58 | EXetoC | well ok I only care about intended behavior |
| 17:28:42 | renesac | I care for what I'm forced to use |
| 17:28:43 | renesac | ^" |
| 17:28:52 | Jehan_ | import unsigned |
| 17:28:52 | Jehan_ | var x: uint32 = 0 |
| 17:28:52 | Jehan_ | if x == 0: echo "0" |
| 17:28:55 | Jehan_ | That works for me? |
| 17:30:27 | renesac | var u:uint32 = 2147483648'u32 # Error: type mismatch: got (int64) but expected 'uint32' |
| 17:30:27 | renesac | assert u > 0 # Error: type mismatch: got (int literal(0), uint32) |
| 17:30:54 | renesac | https://github.com/Araq/Nimrod/issues/936 |
| 17:31:16 | renesac | oh, the first line I pasted is already corrected with the 'u32 |
| 17:31:33 | Varriount | Part of the problem is that the compiler doesn't have an int128 type to work with, to deal with unsigned types range. |
| 17:32:02 | renesac | that is only a problem for 'uint' and 'uint64' I think |
| 17:32:14 | renesac | not for ordinals |
| 17:32:35 | Varriount | But uint's aren't ordinals (in nimrod) |
| 17:32:57 | renesac | uint8, uint16, etc are ordinals |
| 17:33:08 | Jehan_ | I note that comparing ints and uints for things other than equality is dangerous. |
| 17:33:28 | Jehan_ | There are a ton of problems in C because that's allowed there. |
| 17:33:43 | renesac | I want to compare a literal, that should be converted to uint |
| 17:33:54 | renesac | *against a literal |
| 17:34:10 | EXetoC | yeah that's different. it's just a shortcut evaluated at compile-time |
| 17:34:11 | Jehan_ | I grant you that literals should ideally be special-cased if they're in the intersection of int and uint. |
| 17:34:12 | renesac | I appreciate that nimrod is more strict, but those things listed are just bugs |
| 17:35:17 | renesac | the manual says that widening type conversions are aways allowed |
| 17:35:20 | renesac | implicitly |
| 17:35:39 | renesac | bbl |
| 17:35:51 | Jehan_ | Yup. Small integer literals should ideally be in a special subtype of int and uint. |
| 17:35:57 | Araq | fyi renesac is correct |
| 17:37:54 | * | brson joined #nimrod |
| 17:37:54 | * | springbok quit (Ping timeout: 240 seconds) |
| 17:39:15 | EXetoC | that these are bugs? |
| 17:42:48 | Araq | yes |
| 17:43:10 | Araq | they are not even hard to fix ... |
| 17:43:17 | Araq | I should tell renesac how to do it |
| 17:43:30 | Jehan_ | Heh. :) |
| 17:46:13 | Araq | for the 'if x' one can define a converter to get that feature |
| 17:46:29 | Araq | but I don't like it. it's sloppy thinking |
| 17:47:09 | Jehan_ | If it's all the same to you, I'd rather not have non-boolean types implicitly treated as booleans. |
| 17:47:23 | Jehan_ | Except where that's part of their feature set. |
| 17:49:10 | reactormonk | Jehan_, converters are kinda explicit |
| 17:49:35 | Demos | that road leads to C insanity, lets not do it |
| 17:49:35 | Jehan_ | That's not what I mean. |
| 17:49:48 | Jehan_ | If there were an int -> bool converter in system, for example. |
| 17:49:57 | EXetoC | declaring one is explicit, while using one is not |
| 17:50:16 | EXetoC | well, optionally it is |
| 17:50:17 | Demos | heck I think if (x==0) is more explicit than if(x), esp since they do different things |
| 17:50:37 | Demos | rather I think it is more clean |
| 17:50:39 | Demos | *clear |
| 17:50:41 | Demos | argh |
| 17:52:01 | Jehan_ | It's also that it can lead to bugs. One reason for having a type system is to avoid clerical errors. |
| 17:57:34 | fowl | dom96, did you try to use `=>` with map()? |
| 17:57:44 | dom96 | fowl: yes, why? |
| 17:58:03 | fowl | cant do it without the type |
| 17:58:20 | EXetoC | that's known |
| 17:58:25 | fowl | map(s, (it: int) => $it) |
| 17:58:37 | fowl | oh :( |
| 17:58:44 | dom96 | the compiler still needs help sometimes. |
| 18:03:40 | dom96 | Is there anything in the stdlib for indenting a string? |
| 18:06:26 | Araq | there is strutils.wordWrap iirc |
| 18:07:00 | dom96 | huh? Why would that indent? |
| 18:07:52 | Araq | you can pass newLine= "\n " to it |
| 18:09:13 | Araq | but yes. it does more than that |
| 18:09:19 | dom96 | wouldn't that only add indentation where it word wraps? |
| 18:09:45 | Araq | true |
| 18:10:51 | renesac | I've already tried a converter actually |
| 18:11:11 | renesac | but nimrod has a single "and" operator, instead of a separate one for bitwise and logical |
| 18:11:34 | renesac | and the last time I tried to fix those implicit conversion bugs, I got overload resolution errors |
| 18:12:33 | Araq | the quick way out is to patch sigmatch.complexDisambiguation() then |
| 18:12:37 | renesac | there were procs for 'int64' and 'uint64', and 'uint8' was unsure of which to pick |
| 18:15:14 | fowl | dom96, im pretty sure theres an indentation function in the json module |
| 18:15:58 | dom96 | fowl: if there is it doesn't seem to be publi |
| 18:16:00 | dom96 | *public |
| 18:16:05 | fowl | yea |
| 18:16:56 | dom96 | 'cannot evaluate at compile time: stdout' |
| 18:17:02 | Demos | why would complex disambiguation help here? It looks to me like it just does ordering for like Foo[Bar[T]] vs Foo[T] vs T |
| 18:17:16 | dom96 | stdout.write should work at compile-time shouldn't it? |
| 18:17:35 | Araq | dom96: not anymore, no |
| 18:17:52 | Araq | the compile-time FFI was removed |
| 18:17:53 | dom96 | why? |
| 18:18:24 | fowl | dom96, because the api changed and nobody wants to update it |
| 18:18:34 | dom96 | echo works, stdout should too |
| 18:19:01 | Araq | no, "echo" is special |
| 18:19:01 | dom96 | hrm, I guess I see the problem. |
| 18:19:03 | dom96 | oh well. |
| 18:20:07 | Araq | Demos: indeed that's what it currently does. but one could make it perform "prefer int over uint8 if both match" |
| 18:20:38 | Araq | that it ultimately needs to be rewritten still stands |
| 18:22:17 | Demos | yeah, again I am up for that but it is jumping into the deep end. Now I can not figure out how "prefer int over uint8" would fix our literal problems |
| 18:25:29 | Demos | oh for the widening conversions |
| 18:25:30 | fowl | how to fix the literal problems: when someone mentions a problem with literals we just insist that there is literally no problem |
| 18:26:30 | Demos | I care more about the literal problems, although they are way more annoying in a stuff like var s: seq[uint32] = @[1,2,3,4,5] |
| 18:26:33 | Demos | which does not work |
| 18:26:55 | fowl | 1u32, 2,3,4,.. |
| 18:27:11 | Demos | OoOooOOOOoo really! |
| 18:27:28 | Demos | sweet |
| 18:27:46 | fowl | Demos, [] is a literal array here and @ is a prefix op, all members of array are the same type, so you can just do the first one |
| 18:28:01 | renesac | this should be on tutorial |
| 18:28:08 | Demos | yeah, makes sense now, but I did not realize it before |
| 18:28:35 | renesac | but yeah, ideally you should't need this |
| 18:28:55 | renesac | because you are declaring the type on the same line |
| 18:28:57 | Demos | yeah, but fixing it may be too complex for little benifit |
| 18:29:05 | EXetoC | indeed |
| 18:29:20 | renesac | yeah, not the highest priority |
| 18:29:20 | Demos | would perhaps need something like c++'s initalizer lists, which add complexity to type deduction rules |
| 18:30:39 | renesac | Araq, what do you think about the idea I and filwitt were discussing about deprecating the 'u32', 'f64', etc literal suffixes |
| 18:30:53 | renesac | and add '.u32', '.f64' instead? |
| 18:31:13 | renesac | so everything is more consistent, and less special cases? |
| 18:31:39 | Demos | that is not more consistent unless we allow stuff like var x: u32 = 4 |
| 18:31:40 | renesac | 'u would turn into '.uint' of course, same for 'f |
| 18:31:49 | dom96 | IIRC there were times where I had to explicitly use the suffixes for each literal in an array constructor |
| 18:32:03 | fowl | Demos, c++s requirements are getting astounding |
| 18:32:12 | dom96 | I'd say it's not for 'little benefit' |
| 18:32:21 | renesac | Demos, true... |
| 18:32:30 | EXetoC | dom96: isn't it a bug? |
| 18:32:39 | Demos | fowl: c++ is not actually all that complex, it is just that it has some features that interact badly |
| 18:33:08 | fowl | Demos, "const" alone requires code analysis |
| 18:33:14 | Demos | and from a programmer's perspective it is verbose and doing some simple things requires a lot of insane work |
| 18:33:35 | fowl | Demos, more than what nimrod does, given its weirdness with things like vector<const T> |
| 18:33:35 | dom96 | https://github.com/Araq/Nimrod/blob/devel/lib/windows/winlean.nim#L692 |
| 18:34:15 | Araq | dom96: that's caused by the ambiguous hex literals |
| 18:34:19 | Demos | const is just a regular old type qualifier, I do not think the analysis required for it is that big |
| 18:34:43 | Demos | const may be a bad idea, but still |
| 18:34:45 | Araq | hi Johz welcome |
| 18:35:01 | dom96 | Araq: i'm not sure why they are ambiguous |
| 18:35:04 | renesac | dom96, fill a bug |
| 18:35:19 | renesac | yeah, it is an array, it should not be ambiguous |
| 18:35:27 | Araq | dom96: 0xFF is 255, does that look like an int8 to you? |
| 18:35:44 | Araq | that's the problem here |
| 18:35:50 | renesac | -127? |
| 18:36:04 | renesac | *-128 |
| 18:36:20 | dom96 | *shrug* that's what it's defined as, the compiler shouldn't get in my way |
| 18:36:30 | Araq | well TGUID's definition is old, it should use unsigned instead |
| 18:36:54 | dom96 | unless allowing such code is dangerous, perhaps it is. |
| 18:37:10 | renesac | I don't think so |
| 18:37:35 | renesac | 0xFF is a valid int8 value |
| 18:37:55 | fowl | i say we include rope and directions for tying good knots with the compiler |
| 18:38:21 | fowl | or if we can find them cheap enough, a pistol and a bullet |
| 18:38:59 | renesac | I agree that usually uint8 is better in those cases (and probably the protocol is defined using them) |
| 18:39:12 | renesac | but that should work |
| 18:39:12 | EXetoC | but 255 isn't valid int8, so why should 0xff be? |
| 18:39:19 | Araq | renesac: I don't care about 'u8 vs .u8 but this "omg this is inconsistent" is getting tiresome very fast |
| 18:39:46 | renesac | I know |
| 18:40:51 | renesac | still, that might simplify the language and mean less typing (well, a '.' if you use the suffixes w/o the ') |
| 18:41:05 | renesac | but yeah, not sure if it is worth now |
| 18:43:23 | Araq | filwit is a smart guy but he never answered the question: "if your coworker can't remember .u8 vs 'u8 would you really want to work with him?" in a satisfying manner |
| 18:43:33 | EXetoC | less typing? you mean either exactly as many characters or one more? |
| 18:43:59 | renesac | when you don't have a literal, you need 'uint8' |
| 18:44:15 | Demos | the bigger problem is that even if we allow .u8 it is not more consistent, since we normally only allow .type and u8 is not a type |
| 18:44:50 | renesac | and if demos crictic would be solved, we would have 'array[u8]' |
| 18:45:20 | renesac | it would become the type |
| 18:45:34 | Demos | which is not a great idea |
| 18:45:39 | fowl | renesac, what stops you from defining those types? |
| 18:46:06 | EXetoC | so are strings for byte buffers a good idea? in the socket interface for example |
| 18:46:08 | renesac | fowl, I would have to create a babel package and import them everywhere? |
| 18:46:13 | EXetoC | I suppose more types could be supported |
| 18:46:30 | fowl | renesac, when you compile you can do --import:module , or add that to your nimrod.cfgs |
| 18:46:45 | renesac | not great for sharing code |
| 18:47:00 | fowl | renesac, neither is not declaring your dependencies |
| 18:47:11 | renesac | ? |
| 18:47:20 | renesac | the alternative is not defining those types |
| 18:47:21 | fowl | i'd rather see import librenesac |
| 18:47:37 | EXetoC | it should indeed be used sparingly, and I've only ever implicitly imported a single 'common' module |
| 18:47:38 | renesac | and not have to import anything more |
| 18:48:03 | Demos | is foo(4) supposed to match proc foo(a: openarray[int])? |
| 18:48:16 | renesac | I need to touch up my bithacks module |
| 18:48:17 | Araq | Demos: no, but varargs[int] |
| 18:48:19 | fowl | renesac, your real complaint then, not the lack of types called i* and u*, its that they arent in system, ready for you to use without importing anything |
| 18:48:34 | Demos | it does not, but the comment on baseTypeMatch in sigmatch seems to suggest it might |
| 18:48:46 | renesac | fowl, that was an improvement suggestion for nimrod |
| 18:49:08 | renesac | also, people making syntax highlighting could ignore the ' case |
| 18:49:15 | renesac | in the future |
| 18:49:37 | Araq | there is also the improvement request of making every type Uppercase |
| 18:49:49 | Araq | and then we end up with I32 which is hard to read ... |
| 18:50:03 | renesac | and harder to type |
| 18:50:04 | renesac | :P |
| 18:50:26 | fowl | renesac, filwit has all these suggestions for truly minor syntax changes, why does he not just fork the syntax file and make the changes he wants? |
| 18:50:29 | EXetoC | everyone knows that these are types |
| 18:51:05 | dom96 | and that is why 'i32 should stay |
| 18:51:19 | Araq | also the semantics are slightly different |
| 18:51:22 | dom96 | it's a type suffix not a type and can therefore stay as it is case-wise |
| 18:51:49 | Araq | it's not a type *conversion* it's part of the literal |
| 18:52:06 | Araq | 0xfff'f64 is valid too |
| 18:52:19 | Araq | floating point hexadecimal literal |
| 18:52:36 | Araq | 0xffff.float64 does something entirely different |
| 18:53:12 | Araq | so yes. it's "inconsistent" if you don't understand it. :P |
| 18:53:43 | renesac | Araq, it does something different because it transforms 0xffff to int before, right? |
| 18:54:18 | Araq | right |
| 18:54:28 | EXetoC | then there's constant folding, but maybe you shouldn't rely on it |
| 18:54:37 | fowl | does anybody have a pun on "parser/parsing" i can use |
| 18:54:55 | Demos | fowl: you writing a parsec clone? |
| 18:55:59 | fowl | Demos, parsec looks a lot more advanced. this is just a combinator |
| 18:57:09 | renesac | well, it is a typecast then |
| 18:58:11 | EXetoC | conversion you mean? |
| 18:58:12 | Johz | <Araq> hi Johz welcome <-- Hi, sorry! |
| 18:58:23 | EXetoC | cast is unchecked |
| 18:58:28 | renesac | EXetoC, 0xfff'f64 |
| 18:58:57 | renesac | ok, 1'f64 is a conversion |
| 18:59:04 | renesac | yeah, different semantics |
| 18:59:54 | EXetoC | maybe construction is the right term here, but anyway |
| 19:00:12 | renesac | was that 5000'u for echo bug fixed? |
| 19:00:31 | renesac | it was discussed some days ago |
| 19:00:56 | renesac | 5000'u8 |
| 19:01:16 | renesac | the compiler should probably give an error in this case |
| 19:01:34 | Johz | Is there a way of getting a line from a file without stripping the line ending? |
| 19:01:41 | EXetoC | I haven't seen such a commit. I tried to fix it, but gave up because I wasn't able to step through the compiler |
| 19:03:01 | renesac | ok, so it was you |
| 19:04:23 | * | brson quit (Ping timeout: 246 seconds) |
| 19:05:01 | EXetoC | I thought maybe I could've fixed some of the bugs in a reasonable time frame anyway had I had another monitor :-) |
| 19:05:34 | renesac | yeah, a second monitor is really handy for coding and writing |
| 19:05:55 | renesac | and many other things |
| 19:06:06 | Varriount | Johz: No. If you want, add an option to the current procedures that read lines from files to prevent stripping the lines. |
| 19:06:51 | Demos | Araq: why is the printing of errors from typeclass matching disabled? |
| 19:06:58 | Demos | I just turned it on and it seemed to work |
| 19:07:02 | * | brson joined #nimrod |
| 19:07:38 | EXetoC | and maybe visual bookmark management in vim |
| 19:09:57 | EXetoC | it probably exists. I need to look for that |
| 19:11:30 | fowl | easygreasy, can you put together a list of components you would like for a 2d game engine |
| 19:20:09 | Araq | Johz: what do you need it for? |
| 19:20:40 | Araq | Demos: "seemed to work" well ... :P |
| 19:20:59 | Demos | OK fine I will actually run the tests :D |
| 19:21:04 | Demos | gawd |
| 19:21:04 | Araq | but I didn't write it, maybe indeed it's not necessary anymore |
| 19:21:07 | Johz | Essentially so that I can tell if there's a newline at the end of the file or not. |
| 19:22:26 | Araq | lol why would you care about that |
| 19:22:28 | EXetoC | what follows is essentially an empty line then |
| 19:22:43 | EXetoC | but it might or might not be included |
| 19:23:19 | easygreasy | fowl: sorry was afk, some component/entity based framework with support for collisions (circle,rect), sprite/animation functionality, probably some tile display/collision functionality |
| 19:26:21 | Demos | https://github.com/barcharcraz/Systemic/tree/master/ecs <-- that is my component framework core. A little messy ATM |
| 19:26:30 | Johz | <Araq> lol why would you care about that <-- Because I *want* to! :P |
| 19:26:34 | fowl | easygreasy, check this out, it has all that except for tiles https://github.com/fowlmouth/roids |
| 19:27:25 | Johz | It's not so much an issue, as more that I'm used to having to deal with line endings, and apparently making my life easier for me is just too confusing to cope with... :P |
| 19:27:53 | easygreasy | fowl: I will, thanks! |
| 19:28:22 | EXetoC | Johz: well, have you checked if the last line is an empty line in that case? |
| 19:29:42 | EXetoC | "" |
| 19:30:30 | Johz | That's what I probably will do. Or just force newlines all over the place. I mean, no-one's ever complained about an excess of newlines, have they? |
| 19:31:32 | EXetoC | it's the most logical thing to do imo, but like I said, it depends on whether or not said proc includes that, which I consider to be the correct behavior |
| 19:31:35 | Araq | what I will complain about though is petty tools which tell me my files don't end in a newline |
| 19:33:38 | Varriount | The 'and' keyword does bitwise AND'ing on ints, correct? |
| 19:33:47 | EXetoC | yes |
| 19:34:01 | fowl | Johz, you can always rewind and check the byte of the file if you want |
| 19:38:46 | Varriount | Araq: Did you read Gradha's post on the forum about 'emit'? |
| 19:38:47 | * | renesac quit (Ping timeout: 240 seconds) |
| 19:39:22 | EXetoC | Araq: what's the deal with newlines and C? the problem is that some old compilers suck in this regard |
| 19:40:19 | Araq | Varriount: no. link? |
| 19:40:44 | Araq | EXetoC: visual C++ only eat windows' newlines, maybe newer versions are better |
| 19:40:52 | Varriount | Araq: http://forum.nimrod-lang.org/t/429#2327 |
| 19:41:20 | EXetoC | I forgot to end with ", I guess" |
| 19:41:25 | EXetoC | ok |
| 19:42:18 | * | menscrem quit (Ping timeout: 240 seconds) |
| 19:42:34 | easygreasy | fowl: looking a bit at the source/hierarchy, I'm a bit confused about the 'room' part, is that an abstraction like a 'scene' type solution seen in other frameworks or is it game specific as an actual 'room' ? |
| 19:43:03 | Araq | Varriount: well he is obviously kidding |
| 19:43:18 | fowl | easygreasy, no, it just holds a collection of entities |
| 19:44:09 | fowl | easygreasy, i didnt spend a lot of a time thinking about the best topology, entities are also stored in a spatial tree for rendering |
| 19:44:17 | easygreasy | fowl: oh, so it's like a 'group' functionality? like 'aliens' or 'bullets' ? |
| 19:44:41 | easygreasy | fowl: so you can omit unecessary collisions et al ? |
| 19:44:44 | fowl | easygreasy, no, more like a world or space |
| 19:44:55 | fowl | there is also a physics system attached to it |
| 19:45:23 | Varriount | Gah. I can *open* a directory handle fine, but as soon as I call ReadDirectoryInfo on it, I get a permission denied error. |
| 19:45:24 | easygreasy | fowl: ok, so likely more like a 'scene' abstraction that I've seen in some frameworks |
| 19:46:20 | * | xtagon joined #nimrod |
| 19:46:52 | fowl | easygreasy, yes |
| 19:47:40 | EXetoC | scene is pretty much the universal term for that |
| 19:50:22 | EXetoC | hm, doomsys |
| 19:51:35 | * | renesac joined #nimrod |
| 19:51:46 | easygreasy | fowl: ok, I gotta hit the sack, bookmarked your project and will study it, thanks for the link! |
| 19:52:32 | * | easygreasy quit (Quit: ChatZilla 0.9.90.1 [Firefox 29.0/20140430131441]) |
| 19:52:41 | Jehan_ | Johz: Does https://gist.github.com/rbehrends/c7fbe8aa8660e3d4379a what you need? |
| 19:55:26 | Demos | Araq: allright, looks like turning on typeclass errors did not cause any mass breakage |
| 19:55:59 | Jehan_ | And here I was wondering why it suddenly started to rain fire outside ... |
| 19:56:36 | Demos | Also are you sure you want to allow multiple hops through converters? It is not currently allowed? |
| 19:57:29 | fowl | Jehan_, it should be an iterator |
| 19:57:29 | Araq | I'm sure I don't want it, Demos |
| 19:58:19 | EXetoC | 'lines' already includes an empty line if \n is the last char |
| 19:58:32 | Jehan_ | fowl: Yes, feel free to adapt it. :) |
| 20:00:29 | Varriount | How do I ensure that an array is alligned to a 32 bit integer (dword) boundary? |
| 20:00:36 | Varriount | *aligned |
| 20:00:59 | EXetoC | by wrapping it I assume |
| 20:01:06 | fowl | sizeof(t) mod 4 == 0 ? |
| 20:01:20 | Jehan_ | How do you allocate that array? |
| 20:01:40 | Varriount | var buffer: array[100, int32] |
| 20:02:14 | fowl | put a char after it any - the addresses? |
| 20:02:25 | Varriount | What? |
| 20:03:01 | fowl | chr.addr.int - buffer.addr.int = size of buffer |
| 20:04:51 | Jehan_ | Normally, the C compiler should automatically align it properly for performance. Is there some other crucial reason why you absolutely have to assure it's on a boundary? E.g. using assembly instructions that require it? |
| 20:05:38 | Jehan_ | Doing it portably is generally tricky because the C standard does not constrain memory alignment all that much. |
| 20:05:43 | Varriount | Jehan_: The api that uses the buffer wants it "Aligned on a DWORD boundary" |
| 20:05:55 | EXetoC | I don't know if there's such a requirement. anyway, since the size of an array is static, just enforce this with a template |
| 20:05:58 | Varriount | http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx |
| 20:06:09 | EXetoC | *guarantee |
| 20:06:18 | Jehan_ | Ah, that's what I wanted to know. |
| 20:06:35 | Araq | just use: tuple [alignIt: int32, buffer: array [X, byte]], Varriount |
| 20:06:53 | Araq | and pass addr buffer to it |
| 20:07:03 | Varriount | Jehan_: I'm trying to get the call to ReadDirectoryChanges to work, however I end up with a 'Permission Denied' error. |
| 20:07:04 | Jehan_ | If it's platform-specific, you can … yeah, pretty much that, except use a double instead of int32. |
| 20:07:27 | EXetoC | int64? |
| 20:10:05 | EXetoC | as always, don't pay attention to what I'm saying |
| 20:10:22 | Varriount | And.. I still get an Access Denied error. Oh well. |
| 20:11:41 | fowl | c needs int4 and int6 |
| 20:12:51 | Varriount | Well, I have to go. |
| 20:13:04 | Varriount | If anone wants to try getting this working - https://gist.github.com/Varriount/941fcda927679af9ae89 |
| 20:13:38 | EXetoC | bye |
| 20:14:01 | EXetoC | are you sure you have enough fun things to do? |
| 20:14:22 | Jehan_ | Sorry, Varriount, not a Windows person. |
| 20:15:11 | Jehan_ | EXetoC: I don't think int64s necessarily have to be aligned that way, especially when it's x86 code. |
| 20:17:24 | * | Jesin joined #nimrod |
| 20:18:01 | * | Johz quit (Ping timeout: 265 seconds) |
| 20:18:55 | Jehan_ | Varriount: If you want to do it absolutely portably, use a slightly longer buffer, then find the lowest address within it that is aligned, then use copyMem() afterwards to extract the data. |
| 20:19:28 | Araq | float64 IS aligned on a 8 byte boundary though |
| 20:19:46 | Jehan_ | Yeah, but in theory, the C compiler could decide to leave a gap. |
| 20:19:50 | EXetoC | I don't why, but wait, why are discussing 8 byte types? |
| 20:20:04 | EXetoC | +we |
| 20:20:21 | Jehan_ | I had a discussion with a professor once who knew a guy who actually did that to facilitate some optimizations. |
| 20:20:34 | Araq | Jehan_: no C compiler does that |
| 20:20:35 | Jehan_ | Where he could prove that the struct wasn't used elsewhere. |
| 20:20:48 | Jehan_ | No existing C compiler that I know of, yes. |
| 20:21:13 | Jehan_ | But you never know what things will be like in a few years. |
| 20:21:42 | Jehan_ | Just recently, a lot of compiler writers have started taking the "undefined" parts of the C standard pretty literally to facilitate more optimizations. |
| 20:24:27 | Araq | alignment changes for *bytes* after 8 byte that have to be aligned |
| 20:24:37 | Araq | are really unlikely |
| 20:24:44 | Araq | even in 10 years from now |
| 20:24:50 | EXetoC | will things like sizeof or len ever return Natural? |
| 20:25:39 | Araq | and the C standard is a living document with a few contradictions |
| 20:25:59 | Araq | EXetoC: unlikely. |
| 20:26:22 | Araq | var L = len(x); while L > 0: dec L # argh, don't make L a natural |
| 20:26:43 | Araq | *while L >= 0 |
| 20:30:10 | EXetoC | you're right it's silly. everyone knows that a natural number will be returned anyway, and it's unlikely that <0 will be returned because of some bug |
| 20:31:08 | Jehan_ | Araq: I've had my share of issues getting stuff to work on the Cray CC so I tend to be careful about assuming that compiler always writers think the same way I do. :) |
| 20:34:44 | * | faassen left #nimrod (#nimrod) |
| 21:00:29 | * | brson quit (Quit: leaving) |
| 21:00:43 | * | brson joined #nimrod |
| 21:27:59 | njoejoe | trying to get memchr() working with nimrod: https://gist.github.com/jots/11461543 the file "split.txt" in the middle there explains what i'm trying to do. |
| 21:33:17 | Jehan_ | You're calling memchr() incorrectly. |
| 21:33:50 | Jehan_ | The last argument is the size of the buffer you're searching, the first the start of the buffer. |
| 21:36:29 | dom96 | Wasn't there a VM bug which caused code to be evaluated incorrectly when comments were present or something like that? |
| 21:36:41 | dom96 | I think I may be hitting the same bug |
| 21:37:40 | dom96 | nope, i'm wrong |
| 21:42:13 | njoejoe | Jehan_: I see. so I need something like p = c_memchr(addr(s), 10, (addr(s) + p) - p) ? but it says s has no address |
| 21:42:34 | EXetoC | make it a var if it isn't |
| 21:42:38 | Jehan_ | Honestly, I don't think you even need memchr(). |
| 21:42:56 | Jehan_ | I just threw together a quick implementation in pure nimrod that actually seems to be faster than the C one. |
| 21:43:14 | Jehan_ | Mostly because of using fread() vs. read() underneath, I suspect, but still. |
| 21:43:52 | njoejoe | wow. if you gist it, i'll test it :-) |
| 21:45:02 | Jehan_ | https://gist.github.com/rbehrends/738010461a04b44cd2a5 |
| 21:45:18 | Jehan_ | No guarantees, but it produces the same numbers as lc2.c for me. |
| 21:46:56 | njoejoe | it produces same number as lc.c for me. 3 seconds. i'm after that 1 second white whale... |
| 21:48:02 | Jehan_ | Hmm. I suspect that has less to do with the code and more with using read() vs. fread(). |
| 21:48:06 | njoejoe | btw, i found the memchr() trick looking at gnu's wc.c |
| 21:48:27 | Jehan_ | What OS are you running on? |
| 21:48:35 | njoejoe | linux |
| 21:48:42 | Jehan_ | Yeah, I was testing it on OS X. |
| 21:49:02 | Jehan_ | So it's probably different system calls, especially for something that should be I/O bound. |
| 21:49:22 | Jehan_ | Yeah. lc.c uses fread(), lc2.c read(). |
| 21:49:39 | Jehan_ | readBuffer() in nimrod calls fread() also. |
| 21:49:47 | Jehan_ | That's probably where the difference comes from. |
| 21:50:38 | Jehan_ | Yeah, lc.c is also faster for me than lc2.c. |
| 21:51:11 | njoejoe | lc2 did fread as well with same result. for some reason on linux, memchr faster than buf[i] == '\L |
| 21:52:10 | njoejoe | i just have to figure out how to call it in nimrod |
| 21:52:50 | Jehan_ | That's straightforward. |
| 21:53:16 | Jehan_ | address of byte in buffer as first argument, '\L' as second argument, remaining bytes as third. |
| 21:53:27 | Jehan_ | The trick is converting the result to an offset. |
| 21:54:23 | * | silven quit (Ping timeout: 250 seconds) |
| 21:56:47 | Jehan_ | Also, you can use isNil to check if a C pointer is null. |
| 22:00:16 | njoejoe | isNil. much nicer. thanks. |
| 22:03:54 | * | brson quit (Ping timeout: 240 seconds) |
| 22:03:56 | Araq | njoejoe: system.lines uses a bigger buffer on devel so it might be useful again to you |
| 22:04:07 | * | [2]Endy quit (Ping timeout: 245 seconds) |
| 22:11:34 | dom96 | I just implemented the jist of downforeveryoneorjustme.com in 24 lines: https://gist.github.com/dom96/49427cd0a9c8da47fff3 |
| 22:11:38 | dom96 | :D |
| 22:12:09 | dom96 | Less than that even |
| 22:12:22 | dom96 | if you remove the empty lines and echo |
| 22:12:25 | Varriount | dom96: Implement async file reading/writing for asyncstuff |
| 22:12:37 | dom96 | Varriount: I have bigger fish to fry |
| 22:12:44 | dom96 | Varriount: How's fsmonitor going? |
| 22:12:55 | njoejoe | thanks Araq. I'm wondering about use of fgetc and ungetc in sysio.nim:readline because on linux (at least my machine) they don't perform so well. (i *think*). so i'm trying see if a better way for readLine() |
| 22:13:17 | Varriount | njoejoe: Assembly. >:D |
| 22:13:18 | Araq | oh yeah, good idea! |
| 22:13:42 | Araq | forgot about this crappy implementation |
| 22:14:54 | Jehan_ | njoejoe: Have a look at this: https://gist.github.com/rbehrends/c63debe2ee689ccd5ff3 |
| 22:15:13 | Jehan_ | It uses memchr(). I have serious doubts that memchr() is the bottleneck, though. |
| 22:16:01 | Jehan_ | It frankly shouldn't be on something that by rights should be I/O bound. |
| 22:17:23 | Jehan_ | Btw, Araq: Is it intended that "using" does not work with fields, only procs? |
| 22:17:59 | Varriount | Last I heard, It's still debatable whether 'using' will stay in the language. |
| 22:18:07 | Jehan_ | Heh. |
| 22:18:12 | Jehan_ | Yeah, I can see why. |
| 22:18:48 | Araq | I think it pushes the language beyond its breaking point |
| 22:18:51 | Jehan_ | It's just that I remembered it the other day and tried to give it a whirl to save some typing on an RNG implementation and found that it didn't do anything for that. |
| 22:19:18 | * | Demos quit (Read error: Connection reset by peer) |
| 22:19:19 | Jehan_ | I can see it introducing unwanted ambiguities, too. |
| 22:19:19 | * | Jesin quit (Remote host closed the connection) |
| 22:19:47 | njoejoe | Jehan_: you are a genius! it worked! I will have to read it and understand it now :-) |
| 22:19:52 | EXetoC | "template x: stmt = fooBarBazOhaicjriweocr" |
| 22:20:19 | njoejoe | Jehan_: it got down to 1 second. same as lc2.c |
| 22:20:43 | Jehan_ | njoejoe: Huh. Now I _am_ surprised. |
| 22:21:04 | Jehan_ | But I'm no genius, it's just all about making Nimrod pretend to do pointer arithmetic. |
| 22:21:58 | Jehan_ | I take it you're doing -d:release? |
| 22:22:05 | njoejoe | yes |
| 22:22:35 | Jehan_ | Also, how long is your file? Must be over a GB. |
| 22:22:36 | njoejoe | so nimrod version just as fast as highly optimized gnu wc.c |
| 22:22:47 | njoejoe | 2.9GB |
| 22:23:24 | Jehan_ | I can see it giving an improvement with very long lines. Still, a 3x speedup is odd. |
| 22:24:55 | njoejoe | 100mm lines, so 29 bytes per line. |
| 22:25:34 | Jehan_ | Hmm. That is strange. |
| 22:25:36 | NimBot | Araq/Nimrod devel 6c4870d Dominik Picheta [+0 ±3 -0]: Get rid unsafe pointer type in GetQueuedCompletionStatus. |
| 22:25:36 | NimBot | Araq/Nimrod devel 543687f Dominik Picheta [+0 ±1 -0]: Fixes buffered recv in asyncnet. |
| 22:25:36 | NimBot | Araq/Nimrod devel a21289f Dominik Picheta [+0 ±1 -0]: Await is now supported in try statements. |
| 22:25:51 | Jehan_ | Oh well, I need my beauty sleep. |
| 22:25:53 | Jehan_ | Good night. |
| 22:26:11 | EXetoC | Jehan_: pretend, how? the most basic way to do pointer arithmetic is this: "cast[ptr array[nElems, T]](yourPointer)" |
| 22:26:29 | njoejoe | goodnight Jehan_ and thanks! |
| 22:26:43 | Jehan_ | Yeah, that's what I mean: Use casts, since it can't do it natively. |
| 22:26:45 | EXetoC | dunno if that's relevant, but it's good to know that |
| 22:26:46 | Jehan_ | Anyhow, take care. |
| 22:27:16 | * | Jehan_ quit (Quit: Leaving) |
| 22:28:38 | EXetoC | that's natively, in a way |
| 22:33:51 | * | uvelichitel quit (Quit: Textual IRC Client: www.textualapp.com) |
| 22:36:46 | * | xenagi joined #nimrod |
| 22:42:36 | Varriount | dom96: I'm stuck at the moment figuring out why ReadDirectoryChanges complains about me giving it an invalid handle. |
| 22:43:17 | dom96 | Varriount: Can I see your code? |
| 22:43:59 | Varriount | dom96: If you insist.. but it's hackish, and requires marking some field in asyncdispatch structures as public. |
| 22:44:55 | Varriount | dom96: https://gist.github.com/Varriount/cece02012ff743e39c3e |
| 22:47:24 | dom96 | You shouldn't be allocating PCustomOverlapped anymore |
| 22:47:39 | dom96 | It's a ref now |
| 22:47:43 | Varriount | dom96: I said it was hackish. |
| 22:48:25 | Varriount | dom96: Also, I haven't had a chance to update the code from your commit 15 minutes ago. I'm still in class. |
| 22:48:56 | dom96 | My code shouldn't make much of a difference |
| 22:49:07 | dom96 | If you've got Araq's fixes then you can't allocate |
| 22:49:16 | dom96 | you should alloc the buffer though I think |
| 22:49:27 | fowl | dom96, you could probably still allocate and cast it |
| 22:49:51 | dom96 | fowl: To a ref? Doesn't sound like a good idea. |
| 22:50:11 | Varriount | dom96: It should be an array of the structure that windows fills the array with. I'll fix it when I get home. |
| 22:50:30 | fowl | dom96, not a good idea, but it may not crash initially |
| 22:51:12 | dom96 | Varriount: well perhaps that will work if it's captured by the callback |
| 22:51:35 | Varriount | dom96: It hasn't even gotton to the wait for iocp stuff stage. |
| 22:51:42 | Varriount | So stop berating me about things. |
| 22:52:11 | Varriount | Also, just updated gist. |
| 22:52:19 | dom96 | I'm not, i'm trying to help you. |
| 23:04:11 | EXetoC | I wonder if int32 matched float better than cint at some point |
| 23:09:08 | EXetoC | no I don't think so. MongoDB does have an int32 type, but it gets coerced into a float or something when sent to the server |
| 23:30:10 | Skrylar | i have developed a newfound hatred for the jpeg format |
| 23:30:40 | Skrylar | the amount of Irrelevant Crap exposed in the header is amazing |
| 23:32:13 | EXetoC | metadata? |
| 23:32:36 | Skrylar | EXetoC: you could call it that |
| 23:32:45 | Skrylar | why would i need to have access to the huffman tables? |
| 23:32:59 | Skrylar | all i want is to 1) encode an image, and 2) decode an image and 3) maybe get exif data |
| 23:33:15 | Skrylar | that should be maybe 6-9 functions and a tuning parameter struct |
| 23:41:08 | Varriount | How do I define a structure whose array is of variable size? I'm importing something from Windows.h |
| 23:42:35 | * | darkf joined #nimrod |
| 23:43:23 | EXetoC | Varriount: I was able to select the size at runtime, but was told that it was a bug |
| 23:43:55 | Varriount | I guess a pointer will do then. |
| 23:44:57 | EXetoC | but if it is to be allowed then it must be the last field, at which point sizeof won't be evaluated at compile time |
| 23:49:13 | EXetoC | but then you have an additional field all of a sudden, so yeah probably not a good idea |
| 23:52:48 | Varriount | dom96: Won't the GC dislike passing a ref of the custom overlapped structure to an outside procedure? I distinctly remember Araq mentioning that passing ref's to outside sources did something... |
| 23:53:53 | dom96 | You need to GC_ref it |
| 23:55:11 | Varriount | Also, I thought we were abondoning the pascal prefixes? |
| 23:55:28 | dom96 | not yet |