| 00:01:18 | reactormonk | def-, I don't know |
| 00:12:22 | * | Sphax_ quit (Quit: CYA!!) |
| 00:12:33 | reactormonk | Araq, I currently have the problem that I don't really know how to test the split so I can assure it still works the same afterwards. Is it enough to test the docstring stuff? Or can I ask the tester to give me a diff. |
| 00:17:12 | * | Demon_Fox joined #nim |
| 00:20:22 | * | Trustable quit (Quit: Leaving) |
| 00:20:56 | Araq | there are tests in strutils itself and perhaps some in tests/stdlib |
| 00:21:23 | Araq | but the docstring should be its spec |
| 00:35:13 | * | Matthias247 joined #nim |
| 00:35:35 | * | Ionian_ joined #nim |
| 00:35:49 | Ionian_ | Hello! |
| 00:39:06 | Ionian_ | anyone on? |
| 00:42:09 | Ionian_ | NimBot |
| 00:45:11 | * | ctran quit (Quit: ctran) |
| 00:46:06 | * | FusionGaming quit (Read error: Connection reset by peer) |
| 00:46:32 | * | FusionGaming joined #nim |
| 00:48:47 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:50:18 | * | Mat4 left #nim (#nim) |
| 01:03:22 | * | keyle joined #nim |
| 01:04:13 | keyle | morning |
| 01:09:59 | * | davidhq joined #nim |
| 01:16:26 | * | JinShil joined #nim |
| 01:20:18 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 01:32:31 | ekarlso | is there a way I can expand somehting to a varargs or so ? |
| 01:32:45 | ekarlso | like in python u do myFucc(*lst ) |
| 01:32:53 | ekarlso | similar in nim ? |
| 01:35:02 | ekarlso | similar in nim ? |
| 01:35:07 | ekarlso | meh, wrong arrow up |
| 01:35:16 | daniel_cp | ekariso: http://nim-lang.org/tut1.html#varargs |
| 01:36:13 | daniel_cp | err *ekarlso ^ |
| 01:38:49 | Ionian_ | Im choosing between Rust vs Nim |
| 01:38:53 | Ionian_ | to learn |
| 01:38:55 | Ionian_ | any help? |
| 01:45:50 | reactormonk | Ionian_, welcome to IRC, you haven't asked your question yet. |
| 01:46:13 | reactormonk | Ionian_, and naturally, you should choose nim. |
| 01:46:32 | Ionian_ | I knew you were gonna say that |
| 01:46:40 | Ionian_ | but after i come back, ill explain |
| 01:48:23 | reactormonk | Araq, none in strutils itself. Will add the doc examples. One split example in tstrutils. |
| 01:50:09 | Ionian_ | Ok, Why Nim? |
| 01:50:33 | Ionian_ | Rust post 1.0 will have Compile time Execution |
| 01:50:47 | bjz | Ionian_: yeah |
| 01:51:04 | Ionian_ | Rust post 1.0 will also have improved LLVM Ir format and optimizations |
| 01:51:07 | reactormonk | Ionian_, nim has that for a few years. |
| 01:51:14 | Ionian_ | Yes I know |
| 01:51:16 | reactormonk | Ionian_, nim runs on the metal with C. |
| 01:51:30 | bjz | Ionian_: nim is better at compile time metaprogramming |
| 01:51:40 | Ionian_ | As of now yes |
| 01:51:48 | bjz | Ionian_: it just depends on what you value most |
| 01:52:28 | Ionian_ | the improved LLVM IR output of Rust will result in speed as fast as idiomatic C code, and even faster than C with some other compiler tweaks |
| 01:52:29 | bjz | Ionian_: yes, but as a heavy Rust user, I think nim's ergonomics for metaprogramming will always be nicer |
| 01:52:35 | keyle | I read samples of code in Rust, and in Nim. From there on, the choice was damn easy. |
| 01:52:48 | bjz | Ionian_: better IR will mean faster build times |
| 01:53:04 | Ionian_ | Can also result in faster programs in the end |
| 01:53:10 | Ionian_ | not just from the IR |
| 01:53:36 | bjz | Ionian_: agreed - we can output better invariants than C can, because we know more about the semantics of the program |
| 01:53:37 | * | reem quit (Remote host closed the connection) |
| 01:53:47 | bjz | Ionian_: which give llvm more room to move |
| 01:54:08 | bjz | *gives |
| 01:54:41 | reactormonk | Ionian_, not sure about rust, but you can actually do sampling with valgrind and linux perf on nim code |
| 01:55:11 | reactormonk | it won't give you the source code, but you can go by the function names farely relyably |
| 01:56:26 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 01:56:34 | bjz | reactormonk: you are outputting good debug symbols |
| 01:56:34 | bjz | ? |
| 01:57:04 | reactormonk | bjz, yup |
| 01:57:13 | bjz | yeah, that is good |
| 01:57:15 | reactormonk | well, kinda |
| 01:57:16 | reactormonk | nim -d:release --passC:-pg --passL:-pg c strutilstest.nim |
| 01:57:29 | bjz | same with Rust - makes debuggin much nicer |
| 01:57:46 | reactormonk | Ionian_, if you want speed, -d:release - gives 5x-10x speed boost but no more stack traces. |
| 01:57:52 | bjz | shame all the tools are built with C or C++ in mind |
| 01:58:50 | Ionian_ | reactormonk: On the valgrind and linux perf, Rust cam |
| 01:58:52 | * | davidhq joined #nim |
| 01:58:52 | Ionian_ | can* |
| 01:58:53 | reactormonk | you could {.push extern.} if you really want to (IIRC that's the syntax) |
| 01:59:05 | reactormonk | so all the function names in that file don't get mangled |
| 01:59:20 | reactormonk | naturally, if you have any collissions, you're screwed |
| 01:59:27 | reactormonk | Ionian_, ok |
| 01:59:42 | bjz | reactormonk: collisions? |
| 01:59:57 | reactormonk | bjz, yup |
| 02:00:02 | * | keyle gets the measuring tape and unzip compiler pants |
| 02:00:12 | reactormonk | as in your function names are called something that's already used |
| 02:00:12 | keyle | this is non sense |
| 02:00:20 | Ionian_ | reactormonk: Also I know Nim is fast, given C is its target, but rust gives you all of that and _performance_ |
| 02:00:43 | Ionian_ | disclaimer, I may seem biased, as I enter the Rust IRC first |
| 02:00:47 | Ionian_ | Im trying to compare |
| 02:01:05 | keyle | expressiveness and developer productivity beats the few milliseconds you're trying to shave 15 folds. |
| 02:01:31 | reactormonk | Ionian_, performance? https://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html#execution-time-comparison |
| 02:01:45 | keyle | if not, write the speed critical stuff in C, and the domain logic in python or groovy or whateverelse. |
| 02:01:47 | Ionian_ | I brought that up as well over there |
| 02:01:59 | Ionian_ | Check the updates |
| 02:02:07 | reactormonk | ah right, stringops. |
| 02:02:39 | Ionian_ | plus Rust was also running with bound checks, while Nim was running with release mode |
| 02:02:47 | Ionian_ | It is however self-evident |
| 02:02:55 | Ionian_ | Nim is much prettier then Rust |
| 02:03:44 | reactormonk | that's your choice. But I stay far away from any language that uses ; |
| 02:05:35 | Ionian_ | I dont really mind it |
| 02:05:44 | Ionian_ | its become a habit from the firs tlanguage I was taught |
| 02:05:47 | Ionian_ | JavaScript |
| 02:06:10 | EXetoC | keyle: I'll happily write high level code in nim ;) |
| 02:06:30 | * | Boscop_ joined #nim |
| 02:06:38 | keyle | choosing nim for the lack of ; is comical |
| 02:06:41 | Ionian_ | Nim's syntax reminds me of Ruby |
| 02:07:27 | EXetoC | keyle: it's silly. I don't exactly agree with "syntax matters not" though |
| 02:08:09 | keyle | at the end of the day, it's also a personal choice |
| 02:08:18 | keyle | write a medium size program in both languages, rust and nim |
| 02:08:23 | keyle | then you will know what you want to use |
| 02:08:27 | * | Threewood3W joined #nim |
| 02:08:48 | keyle | agressively picking on compiler details in the language's irc channel achieves very little to your personal choice |
| 02:09:04 | keyle | "I chose to write my programs in XYZ because the irc channel convinced me" |
| 02:09:29 | bjz | keyle: +1 |
| 02:09:33 | * | def-- joined #nim |
| 02:09:47 | keyle | but one thing to consider is that Rust has Mozilla. |
| 02:09:54 | keyle | Go has Google |
| 02:10:06 | keyle | Julia has a large science community |
| 02:10:12 | * | no_name_ joined #nim |
| 02:10:22 | * | buMPnet_ joined #nim |
| 02:10:36 | bjz | Nim has a super committed fellow behind it! |
| 02:10:41 | keyle | Nim feels like that little rebel language, but at the same time, has no agenda beyond itself |
| 02:10:54 | keyle | (which is good) |
| 02:11:09 | Ionian_ | Im asking people form each side of this question |
| 02:11:12 | Ionian_ | from* |
| 02:11:13 | * | onionhammer1 joined #nim |
| 02:11:17 | * | Araq_ joined #nim |
| 02:11:30 | Ionian_ | Then, gathering it up to acheive my personal choice |
| 02:11:49 | Ionian_ | Im not letting a minor ';' choose between 2 languages |
| 02:12:09 | Ionian_ | before Rust vs Nim, I was either choosing D, Go, Rust, or Nim |
| 02:12:28 | keyle | what made you drop Go ? |
| 02:12:50 | * | darkf joined #nim |
| 02:12:55 | Ionian_ | Just didnt like it personally |
| 02:13:53 | Ionian_ | I like Rust's syntax personally |
| 02:14:12 | Ionian_ | except the word 'Let' |
| 02:14:19 | bjz | Ionian_: have you encounters the pyramids of doom? |
| 02:14:36 | Ionian_ | Dunno whta that is |
| 02:14:43 | keyle | Ionian_, can you overwrite rust to have your own keyword instead of Let ;> |
| 02:15:06 | bjz | Ionian_: the crazy nesting of match expressions :) |
| 02:15:15 | Ionian_ | keyle, explain? |
| 02:15:44 | Ionian_ | bjz, I encountered that the first time I tried rust, seemed prety straight forwad to me :S |
| 02:15:47 | bjz | Ionian_: just saying - Rust's syntax is not the nicest always. |
| 02:15:59 | Ionian_ | Im sure thats true |
| 02:16:01 | keyle | well in nim you can easily overwrite the keywords |
| 02:16:12 | Ionian_ | hmm |
| 02:16:19 | * | onionhammer quit (*.net *.split) |
| 02:16:19 | * | Araq quit (*.net *.split) |
| 02:16:20 | * | threewood quit (*.net *.split) |
| 02:16:20 | * | ARCADIVS quit (*.net *.split) |
| 02:16:20 | * | sillesta quit (*.net *.split) |
| 02:16:20 | * | Boscop__ quit (*.net *.split) |
| 02:16:20 | * | VinceAddons quit (*.net *.split) |
| 02:16:20 | * | buMPnet quit (*.net *.split) |
| 02:16:20 | * | def- quit (*.net *.split) |
| 02:16:20 | * | betawaffle quit (*.net *.split) |
| 02:16:21 | * | eigenlicht quit (*.net *.split) |
| 02:16:21 | * | no_name quit (*.net *.split) |
| 02:16:21 | * | def-- is now known as def- |
| 02:16:24 | keyle | so if you didn't like `type` you could use another word |
| 02:16:25 | bjz | Ionian_: each match expression gives two levels of indentation - that's 8 spaces |
| 02:16:33 | Ionian_ | Ima have to ask Rusteceans, however Im sure U cant, but idk, worth a shot |
| 02:16:45 | * | VinceAddons joined #nim |
| 02:16:46 | bjz | Ionian_: you can't in Rust |
| 02:16:58 | reactormonk | keyle, you'd rather not. |
| 02:16:59 | bjz | Ionian_: for better or for worse |
| 02:17:00 | * | no_name_ is now known as no_name |
| 02:17:03 | * | Ionian_ left #nim (#nim) |
| 02:17:09 | keyle | but Ionian_ don't let the word let put you off a complete language |
| 02:17:20 | * | betawaffle joined #nim |
| 02:17:24 | keyle | it's also about the standard lib, the wrappers, the community |
| 02:17:39 | keyle | ok he's gone |
| 02:18:18 | * | Ionian_ joined #nim |
| 02:18:27 | Ionian_ | bjz, I dont exactly mind it |
| 02:18:52 | * | eigenlicht joined #nim |
| 02:18:54 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 02:19:23 | * | fowlmouth joined #nim |
| 02:25:40 | * | davidhq joined #nim |
| 02:27:36 | * | ARCADIVS joined #nim |
| 02:27:46 | * | ARCADIVS quit (Max SendQ exceeded) |
| 02:28:35 | * | visi0n joined #nim |
| 02:28:38 | * | gmpreussner__ quit (Ping timeout: 244 seconds) |
| 02:29:01 | * | ARCADIVS joined #nim |
| 02:29:37 | * | Demon_Fox quit (Quit: Leaving) |
| 02:35:10 | * | fowl quit (Ping timeout: 244 seconds) |
| 02:35:12 | * | VinceAddons quit (*.net *.split) |
| 02:35:12 | * | JinShil quit (*.net *.split) |
| 02:35:12 | * | trevorriles quit (*.net *.split) |
| 02:37:55 | * | atticusalien joined #nim |
| 02:38:55 | * | JinShil joined #nim |
| 02:40:47 | * | valberg_ joined #nim |
| 02:41:04 | * | skyfex_ joined #nim |
| 02:41:34 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 02:42:21 | * | VinceAddons joined #nim |
| 02:42:24 | * | Ionian__ joined #nim |
| 02:42:32 | * | gmpreussner__ joined #nim |
| 02:42:43 | * | jez0990_ joined #nim |
| 02:44:54 | * | dv-_ joined #nim |
| 02:45:15 | * | vegai_ joined #nim |
| 02:45:49 | * | gunn_ joined #nim |
| 02:45:57 | * | Triplefox_ joined #nim |
| 02:46:37 | Ionian__ | is there inline asm in nim? |
| 02:46:44 | EXetoC | yes |
| 02:49:27 | * | Ionian_ quit (*.net *.split) |
| 02:49:27 | * | gunn quit (*.net *.split) |
| 02:49:28 | * | gokr quit (*.net *.split) |
| 02:49:28 | * | lyro quit (*.net *.split) |
| 02:49:28 | * | TylerE quit (*.net *.split) |
| 02:49:28 | * | skyfex quit (*.net *.split) |
| 02:49:29 | * | reactormonk quit (*.net *.split) |
| 02:49:29 | * | Triplefox quit (*.net *.split) |
| 02:49:30 | * | valberg quit (*.net *.split) |
| 02:49:30 | * | vegai quit (*.net *.split) |
| 02:49:30 | * | jez0990 quit (*.net *.split) |
| 02:49:31 | * | dv- quit (*.net *.split) |
| 02:49:43 | * | Ionian__ is now known as Ionian_ |
| 02:51:33 | * | atticusalien left #nim (#nim) |
| 02:52:15 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 02:55:48 | * | TylerE joined #nim |
| 02:56:06 | * | reactormonk joined #nim |
| 02:57:50 | * | lyro joined #nim |
| 03:09:15 | Ionian_ | Does nim have bounded polymorphism |
| 03:10:23 | * | CARAM__ quit (Ping timeout: 245 seconds) |
| 03:11:22 | * | endou______ quit (Read error: Connection reset by peer) |
| 03:11:38 | * | keyle quit (Quit: <Morbo> Chitchat achieved!) |
| 03:12:19 | * | VinceAddons quit (Read error: Connection reset by peer) |
| 03:15:12 | * | CARAM__ joined #nim |
| 03:16:21 | * | endou______ joined #nim |
| 03:20:55 | * | gmpreussner__ quit (Ping timeout: 244 seconds) |
| 03:21:07 | * | gmpreussner__ joined #nim |
| 03:23:31 | * | davidhq joined #nim |
| 03:26:22 | * | davidhq quit (Client Quit) |
| 03:34:54 | * | johnsoft quit (Ping timeout: 272 seconds) |
| 03:36:33 | * | Boscop__ joined #nim |
| 03:40:25 | * | nande_ joined #nim |
| 03:41:39 | reactormonk | Ionian_, example |
| 03:47:07 | * | dtscoder joined #nim |
| 03:52:04 | * | Boscop_ quit (Ping timeout: 628 seconds) |
| 03:52:04 | * | Jesin quit (Ping timeout: 628 seconds) |
| 03:52:04 | * | nande quit (Ping timeout: 628 seconds) |
| 03:52:05 | * | dtscode quit (Read error: Connection reset by peer) |
| 03:52:05 | * | Jessin joined #nim |
| 04:01:46 | * | gunn joined #nim |
| 04:01:53 | * | gunn quit (Max SendQ exceeded) |
| 04:02:30 | * | gunn joined #nim |
| 04:02:46 | * | gunn_ quit (Ping timeout: 244 seconds) |
| 04:05:19 | * | Triplefox_ is now known as Triplefox |
| 04:09:08 | * | dtscoder is now known as dtscode |
| 04:14:17 | * | EXetoC quit (Ping timeout: 252 seconds) |
| 04:16:29 | * | dtscode is now known as notdts |
| 04:18:06 | * | notdts is now known as dtscode |
| 04:20:39 | * | chroem joined #nim |
| 04:21:35 | chroem | How would one go about serving HTTPS content in Nim? |
| 04:30:05 | dtscode | can someone eli5 how to use the pegs module to find each occurance of a word in a string and replace it with another word? |
| 04:43:30 | onionhammer1 | chroem look at jester https://github.com/dom96/jester/ |
| 05:11:31 | gmpreussner__ | i've been using nim for a while now, and i'm starting to think that 2 spaces for indentation is not enough. 4 spaces is much easier to read |
| 05:11:54 | gmpreussner__ | with 2 spaces, everything kinda melts together. of course, it is less wasteful, too |
| 05:12:34 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 05:13:02 | gmpreussner__ | oh well, maybe my eyes are just tired :) |
| 05:18:03 | gmpreussner__ | yeah, two spaces is not so bad. nevermind |
| 05:20:59 | Ionian_ | reactormonk: T: Trait |
| 05:21:40 | Triplefox | I tested four spaces on some code I had...didn't really change it for me |
| 05:22:22 | Triplefox | with four i tend to get irritated at how code gets cramped when using an 80-col limit |
| 05:23:31 | Triplefox | (I write wide code when I'm allowed to) |
| 05:32:00 | chroem | onionhammer1: From what I can tell, Jester doesn't seem to support it yet. |
| 05:39:35 | * | gunn quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 05:40:23 | gmpreussner__ | Triplefox: yeah, i agree. it eats up too much space. 2 is fine. i'm just tired :) |
| 05:41:21 | * | gmpreussner__ is now known as gmpreussner |
| 05:49:19 | * | dv-_ is now known as dv- |
| 06:07:55 | * | johnsoft joined #nim |
| 06:18:33 | dtscode | is httpclient async? |
| 06:19:01 | dtscode | oh never mind |
| 06:22:55 | * | rkj-b joined #nim |
| 06:28:46 | dtscode | Araq_, just an fyi, http://nim-lang.org/system.html#declared the example uses defined instead of declared |
| 06:52:59 | * | brson joined #nim |
| 06:53:57 | gmpreussner | can someone tell me whether this is supposed to work? https://gist.github.com/gmpreussner/34b6bf829f8a2e46b2bb |
| 06:54:19 | * | brson quit (Client Quit) |
| 06:54:33 | * | brson joined #nim |
| 07:02:46 | dtscode | is check like assert? |
| 07:03:24 | dtscode | i dont think that should compile, since the tuples type would have to be known at compile time |
| 07:05:17 | * | cb_ joined #nim |
| 07:07:03 | * | chroem quit (Quit: Page closed) |
| 07:07:27 | gmpreussner | dtscode: yeah, check is in unittest |
| 07:07:33 | gmpreussner | similar to assert() |
| 07:07:46 | dtscode | figured. was too lazy to look it up |
| 07:08:08 | gmpreussner | dtscode: so the error is legit? |
| 07:08:21 | dtscode | yeah. do you write c++ code? |
| 07:08:22 | gmpreussner | i expected T to be known at compile time |
| 07:08:36 | dtscode | its not guaranteed to be known though |
| 07:09:11 | gmpreussner | i see... maybe i don't fully understand tuples then |
| 07:09:32 | gmpreussner | under what circumstances would T not be known? |
| 07:10:02 | dtscode | creating a variable at runtime |
| 07:10:14 | dtscode | of course, im just guessing here. im by no means a nim expert |
| 07:11:10 | gmpreussner | dtscode: i don't see how that would be any different for the first version then |
| 07:11:22 | gmpreussner | if the type wasn't known, then that shouldn't compile either, should it? |
| 07:12:08 | dtscode | arent tuples created at run time though? |
| 07:12:33 | gmpreussner | dtscode: i don't think i know what you mean by that :) |
| 07:13:16 | dtscode | sorry :/ too tired to explain |
| 07:13:41 | gmpreussner | hehe... yeah, and i'm probably too tired to comprehend it anyway |
| 07:13:44 | gmpreussner | 2 a.m. here |
| 07:15:08 | dtscode | 11, but im very behind on my sleep :D. it might also be worth while to post on the forums or to create an issue, because the compiler developers will be able to give you a much better answer than my shitty response |
| 07:15:10 | dtscode | s |
| 07:15:59 | gmpreussner | yeah |
| 07:16:24 | gmpreussner | i'll keep the gist for now. let's see what Araq says tomorrow. if it's a bug, i'll file an issue. |
| 07:17:12 | dtscode | it could very well be a bug, but my c++ roots are screaming no duck typing |
| 07:17:19 | * | JinShil quit (Quit: Konversation terminated!) |
| 07:27:20 | gmpreussner | dtscode: well, it's not really duck typing. variable b is clearly of type 'tuple(float, float)', so it should match Bar[float]. it may be that Foo is simply an alias for 'tuple(float, float)', which is why it works. and there may not be any code trying to resolve Bar[T] from 'tuple[T, T]'. this may be a bug or feature; i don't know. we'll let the compiler gods decide. |
| 07:29:51 | dtscode | saying something is clearly of type foo without actually specifiying its foo is exactly what duck typing is |
| 07:31:55 | gmpreussner | you mean Bar... yes, maybe |
| 07:32:10 | gmpreussner | i gotta go to sleep now. have a good night :) |
| 07:32:25 | * | cb_ quit (Quit: Page closed) |
| 07:32:34 | * | gmpreussner is now known as gmpreussner|zzZz |
| 07:33:02 | dtscode | night |
| 08:02:03 | * | barosl quit (Ping timeout: 245 seconds) |
| 08:06:28 | * | Outlander joined #nim |
| 08:09:13 | * | d3m1gd joined #nim |
| 08:25:49 | * | vegai_ is now known as vegai |
| 08:26:05 | * | barosl joined #nim |
| 08:27:22 | * | Outlander quit (Ping timeout: 245 seconds) |
| 08:27:23 | * | nande_ quit (Read error: Connection reset by peer) |
| 08:45:35 | * | rkj-b quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) |
| 08:45:54 | * | gmpreussner|zzZz quit (Ping timeout: 244 seconds) |
| 08:48:08 | * | VinceAddons joined #nim |
| 08:51:46 | * | Ionian_ quit (Quit: Connection closed for inactivity) |
| 08:54:07 | * | gmpreussner|zzZz joined #nim |
| 09:04:02 | * | reem joined #nim |
| 09:06:59 | * | reem quit (Remote host closed the connection) |
| 09:07:40 | * | reem joined #nim |
| 09:09:42 | * | reem quit (Remote host closed the connection) |
| 09:10:10 | * | reem joined #nim |
| 09:15:55 | * | reem quit (Ping timeout: 256 seconds) |
| 09:21:33 | * | gmpreussner|zzZz quit (Ping timeout: 244 seconds) |
| 09:21:34 | * | gmpreussner joined #nim |
| 09:23:26 | * | vendethiel quit (Ping timeout: 246 seconds) |
| 09:23:38 | * | xeizlif joined #nim |
| 09:24:52 | * | vendethiel joined #nim |
| 09:26:35 | xeizlif | Hey folks. I'm trying to use nim-sdl2's RendererPtr's copy method, but it takes two [ptr Rect] but I can't seem to get a pointer out. |
| 09:26:38 | xeizlif | Using renderer.copy(bg_texture, ptr Rect, ptr Rect) |
| 09:26:50 | xeizlif | gives error| type mismatch: got (RendererPtr, TexturePtr, typedesc[ptr Rect], typedesc[ptr Rect]) |
| 09:27:37 | xeizlif | I'm... not really sure what the compiler's trying to tell me. |
| 09:27:43 | xeizlif | Library's funciton signature is: proc copy*(renderer: RendererPtr; texture: TexturePtr; srcrect, dstrect: ptr Rect): SDL_Return |
| 09:29:54 | xeizlif | ...nevermind. |
| 09:30:28 | xeizlif | changed it to srcrect and dstrect instead of "ptr Rect" twice ;) |
| 09:31:25 | xeizlif | But now I get "error| type mismatch: got (RendererPtr, TexturePtr, typedesc[ptr Error Type], typedesc[ptr Error Type])", and two "error| type expected" ... how can I supply more type information? |
| 09:36:40 | xeizlif | The keyword I'm supposed to be using is "addr". Fixed. |
| 09:37:35 | * | Matthias247 joined #nim |
| 09:46:15 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 09:50:55 | * | gokr joined #nim |
| 09:51:24 | * | JinShil joined #nim |
| 09:55:25 | * | BlaXpirit joined #nim |
| 10:03:24 | * | barosl quit (Ping timeout: 244 seconds) |
| 10:03:45 | * | barosl joined #nim |
| 10:09:04 | * | vendethiel joined #nim |
| 10:11:09 | * | bjz_ joined #nim |
| 10:11:28 | * | bjz quit (Read error: Connection reset by peer) |
| 10:12:53 | * | SplinterOfChaos quit (Ping timeout: 252 seconds) |
| 10:20:59 | * | EXetoC joined #nim |
| 10:23:09 | * | barosl_ joined #nim |
| 10:23:21 | * | barosl quit (Ping timeout: 256 seconds) |
| 10:26:35 | * | valberg_ is now known as valberg |
| 10:26:39 | * | valberg quit (Changing host) |
| 10:26:39 | * | valberg joined #nim |
| 10:59:53 | ekarlso | how can you do something like optional args in nim ? |
| 11:02:42 | xeizlif | proc test(x: int = 4) = ... |
| 11:03:09 | xeizlif | basically you just assign to the argument as if it were a local variable, and if you don't specify it then it gets filled in |
| 11:03:16 | Triplefox | .eval proc fn(a, b=2)=return a+b; echo(fn(1)) |
| 11:03:41 | xeizlif | Also works without specifying the type, as Triplefox demonstrated |
| 11:03:54 | Triplefox | well i expect the bot to be there .-. |
| 11:14:26 | ekarlso | ah, so you need to specify a default -,,- |
| 11:15:37 | xeizlif | Well, otherwise you'd have an undefined variable and I'm not sure how you'd handle that otherwise... |
| 11:15:45 | EXetoC | overloading? |
| 11:17:10 | * | keyle joined #nim |
| 11:17:11 | Triplefox | overloading can usually do what you want to do with an optional arg |
| 11:17:30 | Triplefox | although i'm still getting used to the idea of having 10 implementations of "copy" |
| 11:18:17 | EXetoC | I've tried to rely on only a single proc that is generic, but it's a little ugly atm |
| 11:22:11 | ekarlso | https://bpaste.net/show/b44194c06a57 < better way to write that ? :p |
| 11:25:42 | Triplefox | it seems like that would make an inefficient query that searches for -1 a lot |
| 11:26:07 | ekarlso | Triplefox: just unsure of how to make a "query" constructor else in nim :& |
| 11:27:09 | wtw | is there a reason I cannot 'echo' an int and a string like "echo $int & "string" "? |
| 11:27:21 | wtw | it works when doing "echo "" &int & "string" " |
| 11:27:28 | wtw | arg |
| 11:27:38 | Triplefox | you could define each argument as an object i guess, if you need a generic query constructor |
| 11:27:38 | wtw | "echo "" &$int & "string" " |
| 11:27:54 | EXetoC | might be a case of operator precedence. try adding parentheses |
| 11:28:51 | EXetoC | it will change at some point I think. it's a common mistake |
| 11:29:15 | wtw | ok |
| 11:29:33 | EXetoC | ekarlso: what packages will have an id of -1? |
| 11:29:48 | wtw | it's somewhat counter-intuitive if something works in the middle of an expression but not in the beginning |
| 11:29:52 | ekarlso | EXetoC: it was more like add a if pkgId != -1 then filter on id |
| 11:30:07 | ekarlso | but tbh I think i'll make a small "Filter" object and use that instead |
| 11:32:46 | EXetoC | consider overloading too (procs with the same name but different parameters) |
| 11:34:44 | EXetoC | so as to minimize redundancy |
| 11:37:27 | EXetoC | it's just a suggestion. it might make more sense to introduce some type |
| 11:48:03 | EXetoC | wtw: that statement is too general, but in this case it is. it's the equivalent of this: "echo($, 1)". the same principle applies for "x + y * z" which is the same as "x + (y * z)" |
| 11:50:40 | wtw | ah, unified calling syntax goes wrong here without parentheses? |
| 11:51:06 | * | Trustable joined #nim |
| 11:52:24 | BlaXpirit | no, no, EXetoC |
| 11:52:34 | BlaXpirit | echo $ 1 |
| 11:53:11 | BlaXpirit | wtw, it's sees that as a binary operator |
| 11:53:58 | EXetoC | that's true |
| 11:54:23 | EXetoC | wtw: yes, this alternative call syntax is the culprit |
| 11:55:04 | EXetoC | gotta use dumpTree more often |
| 12:14:24 | * | heinrich5991 joined #nim |
| 12:31:25 | * | darkf_ joined #nim |
| 12:33:12 | * | gunn joined #nim |
| 12:33:43 | * | darkf quit (Ping timeout: 245 seconds) |
| 12:37:17 | * | sillesta joined #nim |
| 12:49:53 | gokr | hey |
| 12:51:20 | sillesta | hi |
| 12:52:16 | * | BlaXpirit quit (Read error: Connection reset by peer) |
| 13:25:12 | keyle | hi |
| 13:25:54 | * | Outlander joined #nim |
| 13:27:49 | * | BitPuffin joined #nim |
| 13:29:52 | * | Boscop__ quit (Ping timeout: 240 seconds) |
| 13:35:23 | EXetoC | wtw: there's no need for either $ or & when using echo though |
| 13:35:40 | EXetoC | because of the proc signature |
| 13:36:52 | xeizlif | What the. Apparently consts will adapt their type to their usage, not their assignment |
| 13:37:13 | xeizlif | i.e.: |
| 13:37:37 | xeizlif | const x = 32; var y = 1.0'f32 + x |
| 13:37:46 | xeizlif | x is now a float32 |
| 13:38:13 | xeizlif | this is strange considering that the string literal "32" used in place of x will not do that |
| 13:38:24 | def- | xeizlif: yes, 32 will do that too |
| 13:38:36 | def- | xeizlif: but with let instead of const it's an int |
| 13:39:34 | xeizlif | hmmm, odd, before when I had literal ints mixed with floats the compiler complained about expecting a float but getting an int ... perhaps there was a difference I overlooked |
| 13:39:52 | xeizlif | Thanks for telling me that, const's behaviour makes more sense now |
| 13:40:07 | xeizlif | I decided to give my consts types from now on |
| 13:40:50 | EXetoC | huh |
| 13:41:46 | def- | Interesting, consts are just symbols bound to a value. So a const number can be used as int and float at the same time |
| 13:43:17 | xeizlif | The problem I was having is that my presumably integer consts were causing for-loop ranges to be promoted to floats... |
| 13:43:19 | EXetoC | it's a case of implicit conversion |
| 13:43:59 | xeizlif | which was driving me crazy because I couldn't work out why that was happening. Turned out I'd used the const elsewhere in the function as a float and so it treated it like a float throughout the whole function |
| 13:44:31 | xeizlif | wrapping everything in my const block in int() fixed that. I probably should use :int syntax tho |
| 13:44:39 | EXetoC | 'x' will remain an int of value 2 no matter what |
| 13:45:21 | EXetoC | you could, but it's obvious what the type is in the case of the constant at least |
| 13:45:49 | xeizlif | unfortunately if I do not do this, I have to explicitly cast to int everywhere I want it to be an int. |
| 13:46:06 | EXetoC | you can type 'x.type' and look at the error message to see what the type is |
| 13:46:30 | xeizlif | I fixed the code and so for me it's no longer a problem but I can try to show you what I mean if you'd like |
| 13:46:57 | def- | EXetoC: import typetraits; echo x.type.name |
| 13:47:38 | EXetoC | def-: I know but I can't be bothered for simple cases |
| 13:49:19 | EXetoC | and it is convenient for plugins that show the error message after a save |
| 13:51:01 | EXetoC | xeizlif: I'm just saying that you're wrong about the semantics of constants |
| 13:51:28 | * | Boscop joined #nim |
| 13:51:28 | * | Boscop quit (Changing host) |
| 13:51:28 | * | Boscop joined #nim |
| 13:51:39 | EXetoC | you mean when doing float + int? then yes. floatVar.int works too, but you can decide what looks best |
| 13:54:09 | EXetoC | x.int being syntactic sugar for int(x). "var y = 1.0'f32 + x" expands to this: "var y = 1.0'f32 + x.float32" |
| 13:58:06 | * | keyle quit (Quit: <Morbo> Chitchat achieved!) |
| 13:58:24 | EXetoC | someone made a complaint about this implicit behavior on the forum recently. I disagree though. first of all, you can do "x: int" if needed; and second, it's only applied iff it's certain that no bits will be lost (such as when doing "int16(int32var)") |
| 14:00:33 | * | Outlander quit (Ping timeout: 244 seconds) |
| 14:05:51 | xeizlif | ...my actual problem was `/` having a float result. Big mistake. |
| 14:06:34 | xeizlif | I'm very glad that people definitely know the language in this channel or I'd have caused a lot of trouble :S |
| 14:06:56 | xeizlif | from now on if I notice something weird I'll write an extremely constrained test for it. |
| 14:07:10 | EXetoC | ok. do you know about `div`? |
| 14:08:32 | xeizlif | I do now. It's an integer typed division |
| 14:11:05 | xeizlif | I should change my floating-point `mod`s to `fmod`, even though `mod` has a valid floating point overload |
| 14:11:22 | * | rational joined #nim |
| 14:12:05 | xeizlif | Although fmod is implemented differently to mod(float, float) |
| 14:31:51 | ekarlso | is there any sql compiler in nim ? |
| 14:32:50 | * | brson quit (Quit: leaving) |
| 14:37:33 | xeizlif | http://nim-lang.org/parsesql.html there's a parser |
| 14:38:06 | xeizlif | http://nim-lang.org/lib.html is a good list to check if you haven't seen it already |
| 14:40:17 | xeizlif | https://cdn.mediacru.sh/X/XsuIgXk1NQiI.png :D. My crappy platformer's map drawing code partially works. (I generated a random mapfile, this is intended behaviour) |
| 14:49:12 | * | JinShil quit (Quit: Konversation terminated!) |
| 14:55:58 | def- | xeizlif: nice |
| 14:56:47 | xeizlif | ty ^_^ |
| 14:59:17 | def- | xeizlif: sdl2 instead of csfml? |
| 15:00:33 | xeizlif | Yeah. I've got a fondness for sdl (sdl2 > sdl, but I've used sdl a lot in the past), and I'm basically writing this game because I was bored. |
| 15:06:00 | def- | what's your opinion on sfml? |
| 15:07:39 | xeizlif | I don't have a lot of experience with it, but using it with C++ was nicer and of course faster than SDL1's archaic API and software blitting on X11 |
| 15:08:09 | def- | there's a really nice binding for nim for it, by blaxpirit |
| 15:08:13 | xeizlif | It's a nice library, but if I'm just going to hack something up, sdl2 will do just fine |
| 15:08:21 | xeizlif | oh, I'll check that out |
| 15:08:47 | xeizlif | To be quite honest, as soon as I saw nim-sdl2 I just started using it. The only other graphics binding I knew existed was nim-opengl |
| 15:08:48 | def- | with example games and everything: https://github.com/blaxpirit/nim-csfml |
| 15:11:11 | xeizlif | Excellent. I'll definitely consider that in future. That's very nice. |
| 15:11:43 | xeizlif | Thanks very much for your help, everyone, it's 2AM so I better get to bed. |
| 15:12:32 | def- | good night |
| 15:15:26 | * | UberLambda joined #nim |
| 15:21:42 | * | Sphax joined #nim |
| 15:35:13 | * | Sphax quit (Quit: CYA!!) |
| 15:38:18 | * | darkf_ quit (Ping timeout: 245 seconds) |
| 15:54:38 | * | TylerE quit (Ping timeout: 272 seconds) |
| 15:59:25 | * | TylerE joined #nim |
| 16:27:55 | * | UberLambda quit (Quit: Leaving the Matrix) |
| 16:29:01 | * | Ionian_ joined #nim |
| 16:29:28 | Ionian_ | reactormonk: |
| 16:44:37 | * | sdw joined #nim |
| 16:53:13 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 16:53:31 | * | johnsoft joined #nim |
| 17:05:59 | * | sdw_ joined #nim |
| 17:06:41 | * | sdw quit (Disconnected by services) |
| 17:06:45 | * | sdw_ is now known as sdw |
| 17:06:46 | * | sdw quit (Changing host) |
| 17:06:46 | * | sdw joined #nim |
| 17:09:14 | * | Trustable1 joined #nim |
| 17:11:15 | * | matkuki joined #nim |
| 17:15:09 | * | EXetoC1 joined #nim |
| 17:15:21 | wtw | can the importc pragma also import c macros? the manual only states "proc or variable from C" |
| 17:15:25 | * | matkuki is now known as 7F1ACIFBX |
| 17:15:25 | * | Trustable quit (Ping timeout: 240 seconds) |
| 17:15:25 | * | EXetoC quit (Ping timeout: 240 seconds) |
| 17:15:46 | ekarlso | is there "some" for rust ? |
| 17:15:49 | ekarlso | ehm, nim -,,- |
| 17:16:08 | wtw | you mean a Maybe monad? |
| 17:16:42 | ekarlso | not sure what it's called elsewhere ;) |
| 17:16:53 | * | 7F1ACIFBX quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) |
| 17:17:48 | wtw | so something like "Just a | Nothing" (in Haskell), i.e. the return value thing? |
| 17:17:48 | * | matkuki joined #nim |
| 17:18:23 | ekarlso | i dont know haskell either.. |
| 17:19:30 | * | endou______ quit (Ping timeout: 272 seconds) |
| 17:19:34 | wtw | if you're referring to this https://en.wikipedia.org/wiki/Option_type, then afaik not yet, but it could be easily implemented |
| 17:20:54 | * | CARAM__ quit (Ping timeout: 276 seconds) |
| 17:23:06 | * | matkuki quit (Ping timeout: 240 seconds) |
| 17:25:54 | * | endou______ joined #nim |
| 17:26:00 | * | UberLambda joined #nim |
| 17:28:55 | EXetoC1 | ekarlso: https://github.com/fowlmouth/nimlibs/blob/master/fowltek/maybe_t.nim ? |
| 17:29:15 | * | EXetoC1 is now known as EXetoC |
| 17:30:45 | * | CARAM__ joined #nim |
| 17:46:56 | * | SplinterOfChaos joined #nim |
| 17:54:21 | * | Jessin quit (Quit: Leaving) |
| 17:54:35 | ekarlso | EXetoC: a |
| 17:54:37 | ekarlso | ah |
| 18:14:47 | wtw | Araq_: I identified the FreeBSD parallel bug, quite silly... the fix is probably three lines or so, I'll create a PR tomorrow |
| 18:19:10 | * | Jesin joined #nim |
| 18:23:59 | def- | wtw: nice |
| 18:24:08 | * | matkuki joined #nim |
| 18:37:34 | titaniumone^ | how do you use importc to import a variable from a header, instead of a function? |
| 18:37:50 | matkuki | When using the "fields" iterator, is there a way to make the loop variable readonly? Example: for field in MyTuple.fields():; field = 12 #error, cannot assign! |
| 18:41:24 | def- | titaniumone^: var foo {.importc: "foobar" .}: cint |
| 18:42:16 | gmpreussner | can the assignment operator be overloaded yet? |
| 18:42:22 | def- | gmpreussner: nope |
| 18:42:57 | titaniumone^ | def- oh that's easy. thanks |
| 18:42:57 | gmpreussner | def-: hmmk... so we're still stuck with constructor procs (newXYZ) and converters then? |
| 18:44:10 | def- | thnk so |
| 18:44:12 | def- | think* |
| 18:44:25 | gmpreussner | i have a generic proc that uses expressions of the form 0.T, 1.T etc. how would I add support for these in types that do are not compatible with ordinals and reals? |
| 18:44:40 | gmpreussner | -do |
| 18:45:19 | def- | gmpreussner: don't think i understand |
| 18:46:22 | def- | matkuki: you could implement your own immutable replacement iterator |
| 18:46:25 | gmpreussner | T is a generic parameter for the type. the proc works on T. for example, within the proc i want to initialize local vars to a zero value, i.e. "let a = 0.T", where 0.T is the zero value for type T. |
| 18:46:34 | EXetoC | foo.bar is bar(foo) |
| 18:47:03 | matkuki | def-: Will try it, thanks. |
| 18:47:34 | gmpreussner | so i need something like "proc newFoo(x: SomeOrdinal)" then? |
| 18:47:39 | EXetoC | gmpreussner: it doesn't work? objects are implicitly zero'ed though |
| 18:47:52 | gmpreussner | well, i have values other than zero as well |
| 18:48:05 | gmpreussner | unit values are common, i.e. 1.T |
| 18:48:53 | EXetoC | gmpreussner: so it doesn't work? |
| 18:49:14 | gmpreussner | i haven't tried it yet. newFoo() is what i need in this case, yes? |
| 18:49:21 | EXetoC | I can't remember if appropriate constraining helped in this regard (T:SomeInteger for example) |
| 18:50:16 | gmpreussner | i guess my question is: which proc performs the conversion for 1.T where T is Foo |
| 18:50:30 | gmpreussner | i.e. what if |
| 18:50:37 | gmpreussner | type Foo = string |
| 18:51:14 | gmpreussner | or: type Foo = object ... |
| 18:52:55 | * | UberLambda quit (Quit: Leaving the Matrix) |
| 18:53:22 | gmpreussner | i'm not making any sense, am i? let me see... |
| 18:53:54 | Ionian_ | Hi |
| 18:53:58 | EXetoC | gmpreussner: it's not a proc actually, but int(x) is very similar to "proc int(x: T): int". what is T anyway? |
| 18:53:59 | Ionian_ | Does Nim have bounded polymorphism? |
| 18:55:04 | gmpreussner | for example: "var c = 1.T". i want this to work for all numeric types. let's say T is Complex, then 1.T should be converted to a tuple "(1.0, 0.0)" |
| 18:55:51 | EXetoC | initFoo(x: SomeInteger)? |
| 18:56:19 | gmpreussner | EXetoC: ah ok, so "initXYZ" is the proc that the compiler is looking for then? |
| 18:56:37 | Ionian_ | :( |
| 18:57:26 | EXetoC | gmpreussner: no it doesn't. x.int does involve some magic |
| 18:57:42 | gmpreussner | aha |
| 18:57:57 | gmpreussner | so i need to add equivalent magic to my own types then |
| 18:58:16 | gmpreussner | is that possible, and if yes, how? |
| 18:58:26 | EXetoC | gmpreussner: you can do "proc T..." |
| 18:58:42 | EXetoC | but user-defined constructors are named initFoo/newFoo by convention |
| 18:59:18 | EXetoC | T(U) is supported for distinct types though |
| 18:59:58 | EXetoC | Ionian_: not in the form of interface constraints, but it might be possible to enforce that in the body. I'll look into it |
| 19:00:07 | gmpreussner | that would include built-in numeric types, i suppose. so i could write T(1) instead of 1.T |
| 19:00:45 | gmpreussner | i guess ultimately i'm really looking for an assignment operator :/ |
| 19:01:26 | EXetoC | but "proc Foo" might be appropriate. conventions can be deviated from |
| 19:01:49 | * | UberLambda joined #nim |
| 19:03:44 | EXetoC | Ionian_: "U is T". "when U is T: ..." for example |
| 19:06:41 | Ionian_ | EXetoC: Like T: Trait |
| 19:07:56 | * | bpr joined #nim |
| 19:08:01 | EXetoC | Ionian_: I was trying with a typeclass, and that didn't work. "traits" have been broken for some time. the author has been busy with other things for quite some time |
| 19:08:45 | Ionian_ | I see |
| 19:08:49 | EXetoC | Ionian_: http://nim-lang.org/manual.html#user-defined-type-classes |
| 19:09:05 | EXetoC | it seems like we will get that some time after 1.0 |
| 19:09:15 | Ionian_ | Again, just tryna compare |
| 19:09:25 | sdw | is there any work done in nim on modeling ranges from D? |
| 19:10:10 | EXetoC | sdw: I've been wanting to experiment with that, but I haven't bothered to try it without traits |
| 19:10:54 | Ionian_ | been doing some trivial programs in Nim and Rust |
| 19:12:02 | EXetoC | sdw: and D-like arbitrary constraints cannot be applied to an actual interface, so that incurs some limitations |
| 19:12:20 | EXetoC | Ionian_: great |
| 19:14:55 | Ionian_ | as im going, the only thing I see Nim having over Rust is is syntax |
| 19:15:08 | EXetoC | I disagree |
| 19:15:12 | Ionian_ | anyone want to shed light on some other features Nim has that Rust doesnt? |
| 19:16:07 | sdw | It's strange the perspective that people have. I usually think "What is so great about Rust that I should invest the time?" |
| 19:16:43 | Ionian_ | Whats bad about Rust? |
| 19:17:03 | bpr | Ionian_: Nim has overloading, Rust doesn't. |
| 19:17:19 | Ionian_ | you mean function overloading? |
| 19:17:27 | bpr | Yes. |
| 19:17:39 | Ionian_ | I find that confusing to be honest :S |
| 19:17:45 | Ionian_ | coming from java |
| 19:17:46 | sdw | How can Rust not have overloading? |
| 19:18:29 | bpr | I like overloading. My biggest problem with OCaml was the lack of overloading. |
| 19:18:41 | sdw | That seems synonymous with "Cannot do generic programming" |
| 19:19:14 | EXetoC | but then again I haven't used Rust in a long time, but this was my transition: D -> Rust -> Nim, after discovering each language in that order |
| 19:19:22 | EXetoC | sdw: kind of, with traits |
| 19:19:25 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 19:19:25 | Ionian_ | Rust has generics |
| 19:19:57 | Ionian_ | EXetoC, when was the last time you touched Rust? |
| 19:20:22 | sdw | Ionian_: nevermind me, I don't actually know Rust. It may well be that they prefer another solution to similar problems |
| 19:20:24 | * | Jervac joined #nim |
| 19:20:47 | * | johnsoft joined #nim |
| 19:20:52 | Ionian_ | Rust's Type system is pretty cool if u ask me |
| 19:21:04 | Ionian_ | Then again im a noob deciding between Nim and Rust |
| 19:21:21 | bpr | Rust has generics, and when Nim finally has user defined type classes working properly, it will (I think) have bounded genericity. |
| 19:21:23 | * | cjbest joined #nim |
| 19:21:25 | Ionian_ | thats why I only see Nim's pretty syntax as a big win |
| 19:21:38 | Ionian_ | bpr, bounded polymorphism? |
| 19:21:59 | Ionian_ | Rust is also implementing Compile-Time execution |
| 19:22:03 | sdw | http://nim-lang.org/manual.html#user-defined-type-classes |
| 19:22:53 | Ionian_ | i c |
| 19:23:02 | Ionian_ | so wut else does nim have |
| 19:23:12 | bpr | You'll be able to constrain the types of your generics. Terminology is confusing here because the two languages are using using different terminology. Score one against overloading ;-) |
| 19:23:38 | Ionian_ | overloading I see is about personal preference |
| 19:24:05 | bpr | Nim has a GC, so the massive PITA of satisfying the borrow checker is not an issue. |
| 19:24:05 | Ionian_ | maybe not, but im personally against overloading of functions |
| 19:24:13 | Ionian_ | PITA? |
| 19:24:23 | bpr | Pain In The Ass |
| 19:24:23 | sdw | urbandictionary that one :P |
| 19:24:30 | Jervac | I have a fix to the nim sdl2 library. How do I show nim-lang my fix? |
| 19:24:30 | dom96 | Ionian_: Does Rust have coroutines? |
| 19:24:35 | EXetoC | the metaprogramming capabilities of Nim is a big plus for me. it's a huge part of the language |
| 19:24:43 | dom96 | Jervac: create a pull request |
| 19:24:54 | Ionian_ | dom96: Idk,lemme ask |
| 19:25:01 | bpr | Because Nim has a GC, it can have full closures too, not just the downward funeral variety. |
| 19:25:15 | dom96 | Ionian_: Does Rust have async await? |
| 19:25:17 | bpr | funarg not funeral. FU spell checker! |
| 19:25:46 | Ionian_ | dom96: do you mean coroutines like goroutines? |
| 19:26:26 | dom96 | Ionian_: no |
| 19:26:40 | Ionian_ | explain a bit more then please |
| 19:27:00 | dom96 | http://nim-lang.org/manual.html#first-class-iterators |
| 19:27:46 | EXetoC | dom96: I still would like to try my hands at an iterator interface implemented in userland. macros yay |
| 19:28:38 | Jervac | dom96: thanks, I think i did it correctly |
| 19:29:39 | dom96 | Jervac: I don't think that will compile |
| 19:30:03 | dom96 | Ionian_: Does Rust have exceptions? |
| 19:30:06 | Jervac | it tells me there's an invalid indentation too |
| 19:30:13 | Jervac | line 1381 |
| 19:30:14 | dom96 | Ionian_: Does Rust have an effect system? |
| 19:30:21 | Ionian_ | dom |
| 19:30:23 | Ionian_ | calm down |
| 19:30:27 | Ionian_ | ur not letting me answer |
| 19:30:33 | dom96 | Ionian_: I can go on and on :P |
| 19:30:40 | dom96 | My point is: it's not just prettier syntax. |
| 19:30:51 | Ionian_ | Ima answer your question |
| 19:31:00 | Ionian_ | Rust does have iterators |
| 19:31:12 | Ionian_ | by execptions, you mean error handling? |
| 19:31:22 | dom96 | By exceptions I mean exceptions. |
| 19:31:31 | dom96 | Error handling can be implemented in different ways. |
| 19:31:44 | dom96 | Iterators or first-class iterators? |
| 19:31:45 | Ionian_ | If Not found => thorw exeception error? |
| 19:31:47 | dom96 | There is a different. |
| 19:32:01 | dom96 | try: foobar() except: echo("Something bad happened") |
| 19:32:25 | dom96 | *difference |
| 19:32:48 | Ionian_ | Yes |
| 19:32:51 | Ionian_ | Rust has that |
| 19:33:03 | Ionian_ | With options |
| 19:33:20 | Ionian_ | .unwrap().expect("Something bad happened"); |
| 19:33:27 | EXetoC | dom96: not a good example is it? since nothing specific is caught |
| 19:33:48 | sdw | Rust probably has a nicer error handling mechanism than nim atm |
| 19:34:04 | dom96 | Ionian_: Will Rust give me a nice stack trace if I don't catch that? |
| 19:34:11 | dom96 | sdw: That's debatable. |
| 19:36:23 | Ionian_ | dom96: Rust has async |
| 19:37:15 | dom96 | Does it have async *await*? |
| 19:37:26 | Ionian_ | btw |
| 19:37:36 | Ionian_ | whats the difference between first class iterators |
| 19:37:39 | Ionian_ | and iterators |
| 19:37:51 | Ionian_ | Oh and yeah, take a look at mio |
| 19:38:46 | sdw | dom96: yes, Rust claims to have nearly all of those |
| 19:38:55 | sdw | I'm unsure about the effect system part |
| 19:39:46 | sdw | does nim use the effect system for anything besides checked exceptions? |
| 19:40:14 | Ionian_ | Yeah |
| 19:40:15 | def- | Ionian_: inline iterators get translated to loops: http://nim-lang.org/manual.html#iterators-and-the-for-statement |
| 19:40:32 | Ionian_ | Im talking about first class |
| 19:40:35 | Ionian_ | whats the sifference |
| 19:40:39 | Ionian_ | I dont see any |
| 19:40:44 | def- | first class iterators are not inline iterators |
| 19:41:07 | def- | you can use them more flexibly |
| 19:41:39 | dom96 | Ionian_: Perhaps you should try out both languages. That should give you a good idea of the different features each supports. |
| 19:42:00 | Ionian_ | That would be diving straight into the very core of the languages |
| 19:42:25 | dom96 | See? Rust doesn't have coroutines :P |
| 19:42:36 | Ionian_ | Im talking about first class iterators and normal Rust iterators |
| 19:42:45 | Ionian_ | which they call kickass iterators |
| 19:43:22 | dom96 | Ionian_: It seems to me that you are already sold on Rust. |
| 19:43:41 | Ionian_ | No actaully I just entered their IRC first |
| 19:43:51 | Ionian_ | with no knowledge |
| 19:44:02 | Ionian_ | then cam to Nim, hoping for some light |
| 19:44:10 | * | BlaXpirit joined #nim |
| 19:44:25 | dom96 | Ionian_: A user in #rust admitted that mio is "very low-level" |
| 19:44:50 | dom96 | So it doesn't sound like it's ready for action yet. |
| 19:44:56 | Ionian_ | dom96, have you seen its repo on github? |
| 19:44:57 | dom96 | Async await is pretty good for beginners. |
| 19:44:58 | sdw | Ionian_: expect this no matter where you go. If I go to Rust and ask "Why is Rust better than nim" I'm likely to just get a different incoherent list of features :P |
| 19:45:16 | EXetoC | sdw: even in #java :-p |
| 19:45:25 | Ionian_ | I basically sked |
| 19:45:29 | Ionian_ | what does x have over y |
| 19:45:42 | Ionian_ | and being on the irc chat on the same time |
| 19:45:47 | Ionian_ | can make them more honest |
| 19:46:13 | * | gmpreussner_ joined #nim |
| 19:46:15 | sdw | Ionian_: that's not a simple answer |
| 19:46:32 | Ionian_ | Im surely not expecting one answer right away |
| 19:46:43 | * | gmpreussner quit (Ping timeout: 244 seconds) |
| 19:46:52 | dom96 | see you later |
| 19:47:16 | sdw | Go through the language docs for each one and you'll get a good feel for the differences |
| 19:47:30 | Ionian_ | differences in syntax |
| 19:47:56 | sdw | sure, certainly there's a large difference in syntax |
| 19:48:41 | Ionian_ | Of course |
| 19:48:56 | Ionian_ | Thats why I said Nim's syntax is a win for nim |
| 19:49:06 | Ionian_ | in most aspects |
| 19:49:43 | Ionian_ | Last night, I looked at what Rust has and will have |
| 19:49:48 | Ionian_ | and what Nim has and will have |
| 19:49:58 | Ionian_ | both looking quite the same |
| 19:50:08 | Ionian_ | then I looked into speed |
| 19:50:14 | Ionian_ | performance* |
| 19:50:15 | * | Demon_Fox joined #nim |
| 19:53:13 | EXetoC | https://github.com/Araq/Nim/wiki/Roadmap |
| 19:53:26 | cjbest | what's the state of the union with nimble: is it a going concern? do people feel it's a critical piece of the ecosystem? |
| 19:54:14 | cjbest | / package management in general |
| 19:54:17 | EXetoC | cjbest: it's usable and it's being improved upon slowly but surely |
| 19:56:09 | cjbest | EXetoC: that's good to hear. |
| 19:57:28 | * | BitPuffin quit (Quit: See you on the dark side of the moon!) |
| 19:57:49 | cjbest | I recently stumbled on nim and am blown away by the language in general, but it feels like a great package manager/ecosystem is one of those practical things that makes things go |
| 19:58:57 | bpr | Ionian_: I like Rust quite a bit, and I'd be happy to use it if I were writing high performance servers. Lately my work is more oriented to data munging and analysis, and Nim is far (FAR) more pleasant to use for that task. |
| 19:59:09 | * | BitPuffin joined #nim |
| 20:00:01 | bpr | Pick the language for the set of tasks you'll likely be doing. |
| 20:00:43 | EXetoC | easy exploratory programming is a great thing, and I haven't needed to care about strict memory safety yet. I welcome improvements that aren't too intrusive though |
| 20:01:00 | EXetoC | 'lent' pointers qualify I think, but I'm not sure yet what that will imply |
| 20:01:28 | EXetoC | but now I'm speculating and there's only so much you can convey here, so I'm done. happy coding |
| 20:02:04 | Ionian_ | data munging? |
| 20:02:40 | * | TheJacob joined #nim |
| 20:02:41 | * | TheJacob left #nim (#nim) |
| 20:02:44 | * | TheJacob joined #nim |
| 20:03:11 | TheJacob | Is there anything I can say to convince a friend that despite having a gc nim is still as fast (or faster) than rust? |
| 20:03:36 | vegai | is that even true? |
| 20:03:45 | vegai | I mean... the "faster" bit |
| 20:03:50 | TheJacob | I don't know |
| 20:04:05 | EXetoC | TheJacob: tell him that languages like java are far from bleeding-edge |
| 20:04:12 | vegai | about as fast for most things, certainly |
| 20:04:26 | TheJacob | my friend is convinced that when it comes down to performance sensitive applications rust will beat nim handily |
| 20:04:44 | TheJacob | EXetoC: how did java come in to this? |
| 20:04:48 | EXetoC | and that research has improved the situation greatly for modern languages |
| 20:05:19 | * | fizzbooze joined #nim |
| 20:05:25 | EXetoC | TheJacob: many people believe that every GC is roughly as bad as the one for java |
| 20:05:29 | sdw | TheJacob: what application? |
| 20:05:31 | TheJacob | EXetoC: any links or article, or things to look up? |
| 20:05:38 | * | Varriount|Mobile joined #nim |
| 20:05:49 | TheJacob | sdw: he's saying anythign that is memory sensitive |
| 20:05:52 | TheJacob | *anything |
| 20:05:55 | fizzbooze | what's the overhead of calling a C++ function from ffi? |
| 20:05:56 | TheJacob | *its |
| 20:06:05 | sdw | consider that in nim you can just use maloc, right? |
| 20:06:42 | TheJacob | sdw: true, but that kinda defeats the point to a large extent, doesn't it? |
| 20:06:44 | EXetoC | TheJacob: unfortunately not. I'm sure Araq has some. ask in the forum if you want |
| 20:06:50 | sdw | TheJacob: it does not |
| 20:06:53 | TheJacob | EXetoC: okay, thanks |
| 20:07:04 | TheJacob | sdw: can you use both malloc and leave little things to gc? |
| 20:07:44 | sdw | sure, why not? |
| 20:07:53 | TheJacob | sdw: okay, cool, thanks! |
| 20:07:56 | sdw | isn't Rust garbage collected? |
| 20:08:13 | TheJacob | sdw: they have some weird ownership system, I don't really understand it honestly |
| 20:08:28 | sdw | make sure you compare apples to apples |
| 20:08:35 | fizzbooze | sdw: rust has no GC |
| 20:09:10 | TheJacob | sdw: we are comparing lack of gc to gc |
| 20:09:12 | EXetoC | a clever programmer oce told me that it's very difficult to manage memory as efficiently as a performant GC in certain situations </anecdotal evidence> |
| 20:09:12 | fizzbooze | what's the overhead of calling a C++ function from ffi? |
| 20:09:26 | bpr | Data munging is just transforming data from one form to another. Cleaning, translating, etc. Sorry if I was unclear, I don't often know the terminology others use. |
| 20:09:40 | EXetoC | that shouldn't be surprising to anyone |
| 20:11:05 | * | TheJacob left #nim (#nim) |
| 20:11:35 | bpr | <TheJacob>: Is the Rust compiler a performance sensitive application? |
| 20:11:44 | EXetoC | TheJacob: the GC can also be disabled, and there's a real-time GC (the documentation claims that the granularity is about 1ms, which is often too high, but the real number is lower than that apparently) |
| 20:11:48 | sdw | too slow :P |
| 20:12:27 | EXetoC | we'll have to wait for relevant benchmarks |
| 20:14:41 | EXetoC | dom96, Araq_: do any of the benchmarks that we're doing well in stress the GC? |
| 20:15:38 | * | Mat4 joined #nim |
| 20:15:44 | Mat4 | hello |
| 20:15:59 | sdw | Hi Mat4 |
| 20:16:09 | Mat4 | hi sdw |
| 20:20:12 | fizzbooze | can anyone answer my question regarding ffi overhead? |
| 20:21:20 | * | gmpreussner_ quit (Ping timeout: 244 seconds) |
| 20:21:22 | cjbest | is the argument against having a GC "in some rare cases it causes unacceptable performance" or "its better never to have it"? If the former, it feels like being able to write code quickly and naturally without burning cycles worrying about memory management minutiae, and being able to hand optimizing where it really matters is the best of all worlds |
| 20:21:39 | * | Threewood3W quit (Ping timeout: 264 seconds) |
| 20:21:40 | * | gmpreussner_ joined #nim |
| 20:22:25 | EXetoC | fizzbooze: there should be no additional overhead |
| 20:23:22 | EXetoC | and we do have a C++ generator (C being the default) |
| 20:23:42 | * | UberLambda quit (Quit: Leaving the Matrix) |
| 20:24:14 | * | Jervac quit (Quit: Page closed) |
| 20:25:30 | fizzbooze | EXetoC: thanks |
| 20:25:33 | * | dumdum joined #nim |
| 20:26:19 | dumdum | Hello, does anyone know how autocomplete is supposed to work in Aporia ide? |
| 20:27:01 | dumdum | For me it triggers on '.' but always comes up with: "No items found for suggest" |
| 20:27:44 | EXetoC | it might not work at all still |
| 20:27:46 | sdw | cjbest: my take is that it's a fear of performance loss. The person who asked was inquiring about performance |
| 20:28:33 | EXetoC | dumdum: it did break at some point, and context sensitivity seems limited atm |
| 20:29:14 | dumdum | :( ok, is there any other editor with proper autocomplete? |
| 20:29:38 | sdw | NimSlime for sublime? |
| 20:30:00 | EXetoC | the problem has been idetools, which I'd imagine is used by most editors with autocomplete support |
| 20:30:54 | dumdum | sdw: Nimlime only gives already parsed strings from the file.. |
| 20:31:11 | dumdum | or i havent configured it properly maybe |
| 20:31:13 | cjbest | sdw: but how often is there meaningful performance loss? Feels like most stuff you want to do, the GC is just not a performance problem |
| 20:31:46 | EXetoC | cjbest: and far from everyone needs uncompromised speed anyway |
| 20:32:35 | sdw | cjbest: it depends on the application |
| 20:32:44 | cjbest | i've had that pain in Java, where it mostly sucks because a) you can't *avoid* using the GC, so in cases where you're actually throwing a lot at it you have to do hacky things to avoid allocation, and b) it stops things for so freaking long (this is the cause of like 95% of shitty UI stutter on android) |
| 20:33:35 | * | UberLambda joined #nim |
| 20:34:19 | Mat4 | at least on Android the situation is getting slightly better because of the new runtime |
| 20:34:55 | sdw | Are there nim projects that run on android? |
| 20:35:25 | cjbest | sdw: I dunno, certainly sounds like a fun idea. The ndk works (but is a pain) |
| 20:36:21 | Mat4 | sdw: No I'm aware of |
| 20:36:22 | cjbest | imagine a world where I can write my core libraries in nim and target android+ios, and then just write the last mile of graphical sugar in the standard languages |
| 20:37:05 | * | UberLambda quit (Client Quit) |
| 20:37:15 | Mat4 | do you have something like Net in mind ? |
| 20:37:19 | EXetoC | you just need a C++ compiler, right? so I'd assume that it'll work. one might have to wrap something though |
| 20:38:18 | cjbest | now I kinda want to try this |
| 20:38:36 | sdw | dumdum: https://github.com/Varriount/NimLime <- it advertises autocomplete, but I think I agree with you that I've never seen it work |
| 20:38:44 | EXetoC | http://forum.nim-lang.org/t/640#3464 |
| 20:39:28 | * | bpr quit (Ping timeout: 246 seconds) |
| 20:40:34 | dumdum | sdw: lots of code in: https://github.com/Varriount/NimLime/blob/master/AutoComplete.py but does not work for me :( |
| 20:41:38 | dumdum | i dont know much about ide tools or nim , just a beginner |
| 20:42:06 | * | Var|Mobile joined #nim |
| 20:42:30 | * | TylerE quit (Ping timeout: 265 seconds) |
| 20:43:51 | dumdum | I think i have been dumbed down by Java too much and eclipse like IDEs |
| 20:44:18 | cjbest | having a great IDE doesn't dumb you down IMO, it lets you focus on the things that matter |
| 20:44:45 | cjbest | say what you will about Java, using IntelliJ is a pleasure |
| 20:44:52 | cjbest | even pycharm kindof rocks for python |
| 20:44:58 | cjbest | should make nimcharm :) |
| 20:45:04 | dumdum | liclipse :) |
| 20:45:25 | cjbest | i hate eclipse with a firey passion |
| 20:46:10 | * | Varriount|Mobile quit (Ping timeout: 264 seconds) |
| 20:46:17 | reactormonk | cjbest, nim-mode for emacs is meh. I should take another look at it. |
| 20:47:08 | dumdum | about dumbing down: I really think I should have spent this time teaching myself nim, but instead have spent last two hours searching for a 'proper' ide |
| 20:48:39 | Mat4 | you can try working with a simple text editor and use a shell for compilation (for Unixoid operating systems 'screen' offers easy handling of virtual consoles) |
| 20:48:49 | reactormonk | dumdum, apora is all you will get |
| 20:49:01 | reactormonk | *aporia |
| 20:49:06 | Mat4 | or try aporia |
| 20:49:17 | sdw | NimLime kinda works |
| 20:49:28 | dumdum | yep, aporia and sublime text (nimlime) it is for now |
| 20:50:24 | Mat4 | there exist also a syntax highlighting file for gedit (or other gtkview based editors) |
| 20:51:00 | * | cjbest quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 20:51:02 | Mat4 | not to forget, you can use Vim or Emacs |
| 20:51:42 | sdw | That's so sad :P |
| 20:52:10 | reactormonk | sdw, no corporate money behind nim :-/ |
| 20:53:08 | sdw | dumdum: when you try out esoteric languages, you often have to accept that the tooling won't be great |
| 20:53:12 | dumdum | Emacs is great I think but I dont like emacs :) |
| 20:56:02 | * | d3m1gd quit (Ping timeout: 276 seconds) |
| 20:56:29 | dumdum | sdw: agreed, I am not dumb enough to leave nim for an ide lang |
| 20:57:10 | dumdum | I spent last week on exploring Rust. .had not heard of Nim before it |
| 20:57:40 | sdw | The big 3 C++ replacements seem like D, Rust, and Nim |
| 21:00:23 | dumdum | I was super excited about Rust, u know its seduced me , its branding (mozilla, logo, website etc) , its complexity (made me feel great to try understand it) |
| 21:00:43 | dumdum | but in the end when i was writing it, my code looked massively ugly |
| 21:01:45 | dumdum | so if in the end i will only use it if: i dont want GC at any cost |
| 21:01:48 | sdw | I think it would be difficult to beat nim's syntax |
| 21:02:37 | dumdum | its the best infix notation i have even seen, it seems to be well thought out |
| 21:02:52 | sdw | it'll be the thing that bites it in the ass, though |
| 21:03:13 | dumdum | why? too much syntax? |
| 21:03:16 | EXetoC | can't compromise too much |
| 21:03:51 | sdw | When large programs grow, all that sugar makes it difficult to reason about what it's going to do |
| 21:05:52 | EXetoC | possibly, if you go nuts with the syntax |
| 21:06:02 | EXetoC | what about the compiler source? |
| 21:06:14 | sdw | Trying to bring that up right now, in fact :) |
| 21:06:58 | dumdum | but does not the sugar reduce the number of symbols needed for expressing |
| 21:07:12 | EXetoC | sdw: a lot of the code was ported though |
| 21:07:13 | dumdum | so otherwise, you will be using more words.. |
| 21:07:17 | sdw | sure, it's a trade-off |
| 21:07:42 | sdw | but understand that it's a cognitive load for the reader |
| 21:07:57 | dumdum | as I saw in nim docs somewhere: complexitiy is constand in the problem at hand |
| 21:08:06 | dumdum | constant* |
| 21:08:16 | EXetoC | sdw: are you making any assumptions about the reader's skills? |
| 21:08:24 | sdw | EXetoC: yes |
| 21:08:55 | dumdum | agreed, that is why java got so popular, it basically took away all freedom and many people seem to like it that way |
| 21:09:32 | dumdum | for large programs, multi people programs, I still java is great choice if it fits |
| 21:09:41 | sdw | it's something that coding standards can enforce anyways. don't like operator overloading? fine, don't use it |
| 21:09:42 | * | cjbest joined #nim |
| 21:11:01 | EXetoC | dumdum: The "objects everywhere" sales pitch wasn't a big factor? |
| 21:11:35 | ekarlso | https://github.com/deuterium-orm/deuterium-orm < wondering how hard that would be in nim |
| 21:13:53 | dumdum | ok yes :) but the relatively simple language was one too |
| 21:13:54 | EXetoC | ekarlso: we do have type introspection. see the typeinfo module, and marshal for typeinfo in action |
| 21:17:30 | sdw | is that a work in progress? I wouldn't expect to see any SQL in an ORM system |
| 21:17:57 | ekarlso | sdw: ? |
| 21:18:34 | sdw | in your link they set up the tables using sql |
| 21:22:50 | ekarlso | https://github.com/deuterium-orm/deuterium/ < guess that's the most important bit |
| 21:23:11 | * | threewood joined #nim |
| 21:26:32 | * | Var|Mobile quit (Remote host closed the connection) |
| 21:28:53 | * | hasenj joined #nim |
| 21:29:05 | hasenj | noob question |
| 21:29:17 | hasenj | does the noSideEffect pragma still work or has it been deprecated? |
| 21:29:30 | hasenj | I put it on a function with an echo statement and the compiler didn't complain |
| 21:30:24 | Ionian_ | Nim isnt faster than Rust |
| 21:34:39 | EXetoC | never? |
| 21:34:49 | * | MightyJoe is now known as cyraxjoe |
| 21:35:09 | * | cyraxjoe is now known as MightyOP |
| 21:35:11 | Ionian_ | wut |
| 21:35:34 | * | MightyOP is now known as cyraxjoe |
| 21:35:46 | EXetoC | it never is? that seems unlikely |
| 21:36:03 | dumdum | hasnj: it allows echo, but does not for example changing a variables value |
| 21:36:40 | dumdum | probably nim does not know the nature of echo |
| 21:36:49 | EXetoC | or maybe it isn't in this point in time, but it's a vague claim |
| 21:37:23 | Ionian_ | as of now, even when Rust isnt as fast as its suppoed to be, Rust is faster than nim in most cases |
| 21:37:33 | Ionian_ | however there is room for improvemnt on both sides |
| 21:37:41 | hasenj | dumdum: got it, thanks |
| 21:37:47 | EXetoC | definitely |
| 21:37:48 | hasenj | The tutorial needs updating then :) |
| 21:38:03 | hasenj | http://nim-by-example.github.io/procs/ |
| 21:38:35 | Ionian_ | but really |
| 21:38:42 | Ionian_ | the Comparison is more like Rust vs C |
| 21:38:58 | EXetoC | llvm vs C? |
| 21:39:24 | Ionian_ | well llvm is like gcc |
| 21:39:26 | dumdum | hansnj: tutorial appears correct to me |
| 21:39:33 | EXetoC | but it's not idiomatic C, so that might be overly simplistic |
| 21:39:44 | dumdum | it has additional expr: x - y |
| 21:39:46 | dumdum | not just echo |
| 21:40:09 | threewood | Are pragmas part of the type system? |
| 21:40:31 | threewood | Or done through meta-programming? |
| 21:41:43 | threewood | Can I have a side-effecting function that returns a noSideEffect function? |
| 21:41:55 | EXetoC | metaprogramming yes. how does it work with the alternative? |
| 21:42:18 | threewood | Well, is the {. noSideEffect .} part of a function type? |
| 21:42:45 | threewood | Is it possible to declare a parameter that is a noSideEffect function? |
| 21:43:42 | threewood | I'm thinking no and that it's only meta-programming |
| 21:44:07 | threewood | So the requirement that the function be noSideEffect is implicitly required when the function is used in a noSideEffect context |
| 21:44:21 | threewood | but I'm not sure |
| 21:45:08 | dumdum | hansenj: sorry, you are right, there are no sideffects |
| 21:48:17 | EXetoC | threewood: is it not part of the type system then? |
| 21:48:37 | threewood | I don't think so... still reading through the docs |
| 21:49:22 | threewood | I think pragmas are annotations of symbols and don't affect types |
| 21:49:39 | threewood | anyone know? |
| 21:50:39 | threewood | Or maybe they annotate expressions actually |
| 21:51:14 | * | Var|Mobile joined #nim |
| 21:51:24 | EXetoC | what if you try to pass a closure to a non-closure proc? (closure being defined by including the closure pragma) |
| 21:52:36 | threewood | I think pragmas are generally AST annotations, but maybe Araq can answer when he returns |
| 21:53:06 | EXetoC | I don't know what it is then if not a type error |
| 21:53:24 | threewood | EXetoC, would that be a problem? |
| 21:53:58 | * | milosn quit (Ping timeout: 264 seconds) |
| 21:54:22 | EXetoC | it would apply only to certain compiler-defined pragmas then I imagine |
| 21:54:48 | threewood | I mean your question about closures being passed to non-closure procs... that seems like it should just work fine |
| 21:55:14 | EXetoC | threewood: the other way around then |
| 21:56:03 | * | dumdum quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 21:57:15 | threewood | I don't think either way should be a problem. The ones that are closures have access to their environment. If you have a closure function defined in a non-closure function, I would expect the environment it has access to would only be the local environment of the non-closure function. |
| 21:57:26 | EXetoC | a type error is generated, right? because the compiler sees the pragma and acts accordingly |
| 21:59:12 | EXetoC | well it fails in some way, because of a mismatch, caused by the application of the closure pragma. I'm referring to your type system claim |
| 22:00:02 | threewood | Oh ok. I think what it's going to do is fail when you pass it in. |
| 22:00:34 | * | milosn joined #nim |
| 22:01:07 | threewood | Wait, are you talking about whether closure is a pragma or part of the type? |
| 22:01:18 | EXetoC | so, the closure pragma is then part of the type system? the compiler needs to take the pragma into account when doing signature matching |
| 22:01:20 | threewood | I would think calling convention would need to be part of the type |
| 22:01:26 | threewood | Yeah, I agree |
| 22:01:26 | * | davidhq joined #nim |
| 22:01:43 | EXetoC | so the answer would be, "it depends" |
| 22:02:45 | * | brson joined #nim |
| 22:03:28 | threewood | Yeah, I'm not sure. Maybe it is part of the type. That, or the 'proc' meta-function interprets the annotations passed to it and attaches the calling convention to the procedure type, at which point it's in the type and not just an annotation anymore. |
| 22:03:49 | threewood | I kind of think it's the latter, but again, not sure. |
| 22:03:56 | gokr | Ionian_: As some random input on the "Rust vs Nim" choice: Nim has a nice and neat Exception mode, error handling in Rust seems very primitive IMHO. Nim has very good C/C++ interop, I suspect much better than Rust. On performance, Nim and Rust are probably quite equal. On platform support, I suspect Nim wins given "C runs everywhere". |
| 22:04:07 | EXetoC | down with Rust! |
| 22:04:15 | EXetoC | brson: joking of course. sup |
| 22:04:22 | gokr | s/mode/model |
| 22:04:58 | Ionian_ | gokr, have you tried Rust and C/C++ interop? |
| 22:05:34 | Ionian_ | "Run everywhere" |
| 22:06:02 | gokr | Ionian_: And IMHO... no GC? Ok, of course you *may* be doing stuff where you don't want GC, but ... I suspect the vast majority of software works perfectly fine with a good GC and that is a big difference in effort. |
| 22:06:21 | Ionian_ | GC is irrevelant right now |
| 22:06:26 | Ionian_ | Im asking you a question |
| 22:07:11 | gokr | Ionian_: No, I have not tried Rust (take it easy man, I am trying to answer) but since Nim compiles via C/C++ a fair guess is that Nim will interoperate better. |
| 22:07:56 | EXetoC | wasn't there a nim vs rust article? did you read it? |
| 22:08:24 | bjz_ | http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html |
| 22:08:40 | gokr | Ionian_: And... GC irrelevant? Its a HUGE difference between the languages. |
| 22:09:01 | Ionian_ | Yeah |
| 22:09:07 | Ionian_ | I read that to see performance |
| 22:09:15 | Ionian_ | and after he updated the whole thing |
| 22:09:18 | gokr | Ionian_: Also, try to check how Rust does error handling. |
| 22:09:25 | Ionian_ | .expect() |
| 22:09:31 | gokr | Ionian_: I tried to even find info on it - and failed quite badly. |
| 22:10:01 | Ionian_ | gokr, did you try asking the IRC themselves? |
| 22:10:16 | gokr | They may have changed the manual, but a hint: Don't search for "Error handling", look under "Result". |
| 22:11:00 | gokr | No, I have never had enough interest in Rust to go chatting. |
| 22:11:14 | Triplefox | i idle in the IRC. it is always busy, although it seems like most people's questions involve complex situations involving borrowing...which I find a little unnerving |
| 22:11:18 | Ionian_ | If you have questions in Rust, by all means go ask them! |
| 22:11:23 | gokr | I keep track of it in the corner of my eye, but for my use cases Rust is not it. |
| 22:11:41 | gokr | Ionian_: Why should I? I don't even use Rust. |
| 22:11:50 | gokr | I am just trying to give you some input on differences. |
| 22:12:01 | Ionian_ | gokr, you are making assumptions of your 0 experience with rust -.- |
| 22:12:31 | gokr | Ionian_: Reality check - you are here asking for differences. I try to help you. |
| 22:13:13 | * | flaviu joined #nim |
| 22:13:16 | Ionian_ | differences based on actual experience |
| 22:13:45 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:14:06 | gokr | Oh, why didn't you say so - then I don't have to waste time trying to help you. |
| 22:14:15 | Triplefox | i did write a little bit of rust code myself but it put me off, i got into a situation where i did have to rely on IRC for help |
| 22:14:29 | Ionian_ | I understand you are trying to help, thanks for that, but I cant be misled based on assumptions like that |
| 22:14:59 | bjz_ | Ionian_: there is only so much you can learn on IRC |
| 22:15:20 | Ionian_ | TripleFox, is common, stabilizing the language involves talking to the people that work on the language itself |
| 22:15:24 | gokr | Ionian_: I am giving you hints on what the major differences are. I don't think I have said anything that isn't fairly well known. |
| 22:17:06 | fizzbooze | gokr: you shouldn't be judging Rust when you said yourself that you have 0 experience it in |
| 22:17:13 | Ionian_ | ^ |
| 22:17:31 | gokr | Regarding C++ interop (which is something very different from C) I do have a small bird in my ear telling me that Nim very shortly will show excellent results there. |
| 22:17:57 | * | Triplefox reviews what he had encountered...right, it was that he didn't know that "iter_mut" existed and he needed it to mutate things within an iteration |
| 22:18:01 | gokr | fizzbooze: I am not judging Rust - in fact - I love the fact that Rust (and other languages) are beating the path forward. |
| 22:18:39 | Ionian_ | Rust and C/C++ interop is thematic, so there wont be such a big difference between the 2 |
| 22:18:41 | Ionian_ | since they are similar |
| 22:19:14 | * | sampwing joined #nim |
| 22:19:40 | Ionian_ | I rely and go to their IRC alot because of the amount of poeple willing to help, and the sort of straight talk to the devs |
| 22:19:49 | gokr | Mmmm, my bird says different. What about C++ templates for example? |
| 22:19:54 | fizzbooze | subl |
| 22:20:02 | fizzbooze | ^ oops , ignore plz |
| 22:20:10 | sdw | Ionian_: where are your benchmarks/code? I'd be interested in seeing them |
| 22:20:12 | gokr | Is there any big C++ library wrapped for Rust? (honest question here) |
| 22:20:20 | EXetoC | fizzbooze: your nickserv password? ;) |
| 22:20:47 | bjz_ | gokr: if it doesn't have a C wrapper, then no |
| 22:20:58 | bjz_ | gokr: spidermonkey and such I think |
| 22:21:00 | fizzbooze | EXetoC: subl from the terminal brings up the sublime editor |
| 22:21:13 | gokr | fizzbooze: Do point out where I "judged" Rust also. I tried to be fair. |
| 22:21:26 | bjz_ | gokr: but the mismatch in semantics is challenging |
| 22:21:52 | gokr | I know, but check back here in a week or so - and I suspect you will be amazed by what Nim can do with C++. |
| 22:21:58 | fizzbooze | gokr: you mentioned that you've never tried rust, but at the same time you said its error handling is primitive |
| 22:22:13 | fizzbooze | gokr: i find rust's error handling to be the most advanced shit i've ever seen imho |
| 22:22:39 | Triplefox | from what i recall rust's _runtime_ error model is pretty simplistic |
| 22:22:50 | Triplefox | the compiler does do an impressive job though |
| 22:22:51 | gokr | fizzbooze: I wrote "error handling in Rust seems very primitive IMHO.". I didn't say *is*. Its my perception from what I have read. |
| 22:23:35 | fizzbooze | rust doesn't have a c++ ffi tho, that's something nim excels that. rust can only ffi C code |
| 22:24:04 | gokr | fizzbooze: This may be interesting to read: http://lucumr.pocoo.org/2014/10/16/on-error-handling/ |
| 22:24:16 | Ionian_ | Also, Rust, even though its not as fast as its supposed to be right now, is faster than Nim |
| 22:24:27 | sdw | Ionian_: show |
| 22:24:32 | fizzbooze | : i've read that. have you read the updated article? |
| 22:24:33 | gokr | Ionian_: Ok, yeah, show. |
| 22:24:56 | fizzbooze | http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html |
| 22:25:00 | Ionian_ | ^ |
| 22:25:05 | Ionian_ | beat me to it |
| 22:25:14 | Ionian_ | reddi thread, created yesterday |
| 22:25:14 | gokr | fizzbooze: Ah, no I haven't read the updated article on errors. I will. |
| 22:25:15 | Ionian_ | http://www.reddit.com/r/rust/comments/2tksc2/updatedread_updates_quick_comparison_between_nim/ |
| 22:26:20 | Triplefox | i don't think there's anything that stops each from being at parity when hand-optimized sufficiently, however i would offer that there would be differences in idiomatic code |
| 22:26:34 | * | hasenj quit (Quit: hasenj) |
| 22:26:52 | Ionian_ | Atm, Rust isnt as fast is it _should_ be |
| 22:27:24 | gokr | You can always find benchmarks saying this or that, here is one where Nim beats Rust: https://github.com/logicchains/LPATHBench/blob/master/writeup.md |
| 22:27:29 | gokr | (search for "756" on that page) |
| 22:27:41 | gokr | Which is why I wrote - that performance probably is fairly equal. |
| 22:28:03 | * | sampwing quit (Ping timeout: 252 seconds) |
| 22:28:58 | Triplefox | if the performance is dependent on hand-tuned allocation then rust would be more likely to come out ahead, just because it's built around doing exactly that |
| 22:29:03 | fizzbooze | are there plans to add nim to the language benchmark game? |
| 22:29:44 | Ionian_ | think there is |
| 22:29:48 | fizzbooze | i hope nim and rust will complete replace golang. i've been severely disappointed with go lately |
| 22:29:50 | Ionian_ | but gokr: http://prntscr.com/5x2cxl |
| 22:30:23 | gokr | Ionian_: Sorry? |
| 22:30:27 | bjz_ | fizzbooze: would be nice to see nim taking a chunk out of go |
| 22:30:29 | Ionian_ | especially since that Code he is using can be optimized |
| 22:30:58 | Ionian_ | Rust 1.0 would chnage its LLVM IR output to be similar to clang's |
| 22:31:01 | bjz_ | fizzbooze: and Rust out of C++ |
| 22:31:15 | Ionian_ | so that Rust would be literally as fast or faster than idomatic C code |
| 22:31:21 | Ionian_ | post 1.0 |
| 22:31:21 | bjz_ | fizzbooze: and abit of overlap |
| 22:31:32 | Ionian_ | gokr, he said himself the Rust section is outdated |
| 22:32:28 | * | meanfish joined #nim |
| 22:32:35 | gokr | Ok, fine. My point is, I suspect you can find small benchmarks where either come out on top - since they are fairly close to each other on performance. |
| 22:33:09 | bjz_ | Ionian_: I think this is an unproductive line of questions - #nim has no idea about Rust's code gen, and arguing over numbers over IRC is a black hole of wasted energy |
| 22:33:16 | EXetoC | Ionian_: got specific applications in mind? |
| 22:33:24 | fizzbooze | bjz_: agreed |
| 22:33:41 | fizzbooze | it'll be more fruitful to compare perf when both are 1.0 |
| 22:34:10 | Ionian_ | maybe even more post 1.0 |
| 22:34:13 | Ionian_ | but who knows |
| 22:34:20 | Ionian_ | lots of room ahead for both langs |
| 22:34:23 | sdw | I don't see on the page. What backend is it using for nim? |
| 22:35:30 | * | asdfghjkl joined #nim |
| 22:35:32 | bjz_ | Ionian_: yes, so could you stop harassing them? they are reasonable questions, but the format is not conducive to a good quality debate |
| 22:36:14 | bjz_ | (format == IRC) |
| 22:36:31 | * | Ionian_ left #nim (#nim) |
| 22:36:45 | flaviu | gokr: There is a C backend for LLVM being made. |
| 22:38:18 | * | cjbest quit (Quit: Textual IRC Client: www.textualapp.com) |
| 22:38:27 | asdfghjkl | Does anyone know of any official or unoffcial packages that would let me do cryptographic signing and verification? |
| 22:38:28 | wtw | is there a preferred way to convert/import c macros to nim? can c2nim do it? |
| 22:39:17 | EXetoC | wtw: yes, they are turned into templates |
| 22:39:21 | def- | asdfghjkl: openssl? |
| 22:39:36 | EXetoC | c2nim does have problems with ## and multiline macros atm |
| 22:39:43 | gokr | fizzbooze: Skimmed that error article for Rust... and I am sorry, but a) it doesn't look that simple and b) does this mean that every piece of code calling some code that may raise errors need to use this macro etc? Call me daft, perhaps I just don't get it. |
| 22:40:00 | wtw | the macro I need to use is very simple |
| 22:40:01 | asdfghjkl | def-: The wrapper doesn't have rsautl |
| 22:40:11 | wtw | #define WIFEXITED(x) (_WSTATUS(x) == 0) |
| 22:40:19 | wtw | so just a check for 0 |
| 22:40:32 | gokr | fizzbooze: To me it seems that this Result thingy will totally invade every code path. Or? |
| 22:40:33 | EXetoC | wtw: just make it a proc if you want to wrap it manually |
| 22:40:56 | EXetoC | or not if you can't be bothered to look up the types in question |
| 22:41:00 | wtw | my problem is, a thing with this name is already present in lib/posix/posix.nim |
| 22:41:11 | wtw | WIFEXITED* {.importc, header: "<sys/wait.h>".}: cint |
| 22:41:23 | wtw | but I feel it doesn't work ;) |
| 22:41:50 | wtw | expression 'WIFEXITED(status)' cannot be called |
| 22:41:55 | wtw | is the error |
| 22:42:32 | wtw | therefore my feeling is the import doesn't handle macros? is this correct? |
| 22:42:38 | EXetoC | wtw: I assume it's a variable, in which case you can't call it |
| 22:42:50 | EXetoC | I wonder if that works |
| 22:43:21 | wtw | well, it shouldn't be a variable :/ ok |
| 22:43:40 | sdw | gokr: I think that's the point |
| 22:45:04 | EXetoC | wtw: nah, shouldn't work. report it if you want, and create your own wrapper in the meantime |
| 22:45:07 | asdfghjkl | Whelp, I guess I'll try my hand at making an NaCl wrapper. |
| 22:45:18 | asdfghjkl | Nim really needs some better crypto suport. |
| 22:45:29 | EXetoC | it needs plenty of things |
| 22:46:34 | EXetoC | asdfghjkl: there are 4 libs with the crypto tag |
| 22:46:53 | asdfghjkl | But they all only do hashes |
| 22:47:03 | EXetoC | ok |
| 22:47:49 | fizzbooze | gokr: it forces to to check whether the result of your function is a valid value or an error. it may seem complicated but it's actually really simple. perhaps it may help you understand it if you write a few programs in it |
| 22:48:03 | EXetoC | flaviu: any plans to add more crypto stuff? |
| 22:48:14 | EXetoC | other than hashing |
| 22:48:50 | flaviu | EXetoC: I'm not sure what you're referencing. |
| 22:49:07 | flaviu | easy-bcrypt won't be getting any more features, it's complete. |
| 22:49:11 | EXetoC | asdfghjkl: anything specific? |
| 22:49:16 | gokr | fizzbooze: But does that mean that every call "level" needs to check? Here is someone that seems to think this is not Heaven at least: http://discuss.rust-lang.org/t/crazy-exception-like-constructs-for-result/587 |
| 22:49:31 | def- | asdfghjkl: I'm interested in signify myself, don't think it's there for non-OpenBSD platforms yet: http://www.tedunangst.com/flak/post/signify |
| 22:49:44 | asdfghjkl | ExetoC: I just want to be able sign and verify data. |
| 22:49:57 | asdfghjkl | General public key crypto would be a plus. |
| 22:50:28 | fizzbooze | gokr: that's because they added the FromError trait to simplify things |
| 22:50:41 | * | bpr joined #nim |
| 22:50:42 | fizzbooze | before* they added |
| 22:51:03 | gokr | fizzbooze: But perhaps you have worked with it? How does it work then in practice? Let's say a function can raise several different errors? Or... what if I have 3 levels of callers - and realize I want to be able to raise something "down there". Do I then need to rewrite every call to use try and handle Result etc? |
| 22:51:16 | * | TylerE joined #nim |
| 22:51:26 | asdfghjkl | NaCl is supposed to be pretty compact. |
| 22:51:40 | asdfghjkl | I'll look into writing a wrapper module for it, I guess. |
| 22:52:19 | def- | asdfghjkl: if the header is clean, it's mostly automatic |
| 22:52:29 | def- | (at least a low level wrapper) |
| 22:52:39 | asdfghjkl | Oh, that's cool. |
| 22:52:52 | asdfghjkl | I haven't made any yet, so I wouldn't know. |
| 22:53:22 | gokr | fizzbooze: I am just saying, perhaps its "all just great", but its not clear to me at least. ;) |
| 22:53:26 | fizzbooze | gokr: i have worked with it, yes. a function that may return several differnent error types is common. you would wrap the error types in an enum, which is a algrebraic type |
| 22:53:42 | EXetoC | http://goran.krampe.se/2014/10/16/nim-wrapping-c/ |
| 22:53:44 | def- | asdfghjkl: here's how i did it: http://hookrace.net/blog/what-makes-nim-practical/#wrapping-libraries-with-c2nim |
| 22:54:05 | fizzbooze | gokr: it's fine. i don't think it's appropriate to pollute #nim with rust tutorials. you'll find much more help in the rust irc :) |
| 22:54:09 | gokr | asdfghjkl: Yeah, both those articles explain quite a lot. |
| 22:54:55 | gokr | fizzbooze: Sure, I am just slightly amazed that people seem to think its "just fine" - but I don't get it. ;) |
| 22:55:08 | asdfghjkl | Alright, I'll see if I can do this. |
| 22:55:26 | sdw | gokr: Do you agree that exceptions are not very useful? |
| 22:55:34 | asdfghjkl | Do I just come back here to get it on the unofficial package list? |
| 22:55:47 | gokr | sdw: No, I find them quite useful. |
| 22:55:53 | def- | asdfghjkl: make a PR on https://github.com/nim-lang/packages |
| 22:56:11 | asdfghjkl | Alright, great. |
| 22:56:49 | sdw | gokr: That's fine. Consider that for example google's C++ coding standards forbids them. |
| 22:57:45 | EXetoC | isn't there something wrong with C++'s exceptions? |
| 22:58:02 | sdw | Yeah. They're exceptions |
| 22:58:02 | def- | asdfghjkl: it's probably even easier now with a foo.c2nim file, but i haven't looked into it |
| 22:58:03 | gokr | Well, C++ in my book is not a very interesting area of comparison. :) |
| 22:58:22 | gmpreussner_ | i think C++ exception always incur a cost even when they're not used. that's why many vendors disable them altogether. |
| 22:58:28 | EXetoC | either way, it's very convenient to just fail hard if necessary without having to do much at all |
| 22:58:31 | asdfghjkl | def-: What do you mean? |
| 22:58:51 | def- | asdfghjkl: for c2nim you don't need to edit the header file directly anymore, you can make a .c2nim file |
| 22:59:36 | EXetoC | gmpreussner_: yes, but how much slower compared to good old return code checking? |
| 23:00:08 | EXetoC | not much I'd think, at least on x64 |
| 23:00:37 | gmpreussner_ | i think the impact used to be significant, although modern compilers have gotten much better at it |
| 23:00:58 | gmpreussner_ | i remember reading an extensive article on this topic a year or two ago, but i don't have the link handy |
| 23:01:10 | gokr | sdw: I just read Google's reasoning - and it was not just "they suck". It was more complicated than that. |
| 23:01:35 | * | barosl__ joined #nim |
| 23:01:42 | sdw | Bottom line: they suck :P |
| 23:02:23 | * | wan quit (Quit: WeeChat 1.1) |
| 23:02:49 | gmpreussner_ | sdw: well, i wouldn't generalize like that. they're used with great success in Java in C# for example |
| 23:03:38 | gmpreussner_ | the problem there is that they are often used for things other than exceptional states |
| 23:03:42 | Triplefox | hmm, writing this bmp header seems ugly |
| 23:03:46 | Triplefox | var bytes : seq[char] = @[chr(0x42),chr(0x9A)] # BM |
| 23:03:51 | Triplefox | discard outf.writeChars(bytes, 0, bytes.len) |
| 23:04:49 | * | barosl_ quit (Ping timeout: 245 seconds) |
| 23:05:30 | EXetoC | Triplefox: is outf.write(bytes) wrong? |
| 23:05:36 | sdw | gmpreussner_: And that's the tricky part, right? |
| 23:05:51 | Triplefox | that implementation doesn't exist |
| 23:05:56 | Triplefox | but it's not my worry |
| 23:06:04 | Triplefox | chr() for every hex value is |
| 23:06:05 | sdw | gmpreussner_: out of memory is exceptional, and likely all I'll do is log it and terminate the program. |
| 23:06:18 | EXetoC | Triplefox: why not int8? |
| 23:06:28 | EXetoC | or uint8 |
| 23:06:44 | Triplefox | .eval var a = int8(0x42) |
| 23:07:07 | * | cjbest joined #nim |
| 23:07:24 | Triplefox | hmm |
| 23:07:25 | EXetoC | var bytes = [0x48i8, 0x9a]? |
| 23:07:42 | EXetoC | the first literal dictates the element type |
| 23:07:57 | Triplefox | it doesn't work in the seq when i try it, unlike every other sequence type |
| 23:08:09 | Triplefox | conversion from int literal to int8 is invalid |
| 23:08:33 | EXetoC | uint8? |
| 23:08:44 | EXetoC | because its outside the range |
| 23:09:18 | Triplefox | type mismatch on the writeBytes |
| 23:09:29 | Triplefox | got seq[uint8] expected openarray[int8] |
| 23:11:07 | sdw | gokr: What's the situation like in nim in light of restarts? |
| 23:11:10 | Triplefox | there's probably something that needs sorting out in system about this...char works except that i have to use chr() |
| 23:11:19 | EXetoC | Triplefox: it works with write, if it's a seq |
| 23:11:25 | EXetoC | still can't stringify arrays.. |
| 23:12:27 | Triplefox | please, show me the working code |
| 23:12:44 | Triplefox | (not meant maliciously, i'm just not sure which way is up at this point) |
| 23:12:57 | def- | the standard library just doesn't like unsigneds i guess |
| 23:12:59 | EXetoC | right, it includes @[]. you can use writeBytes and cast |
| 23:13:36 | * | barosl_ joined #nim |
| 23:14:14 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) |
| 23:14:22 | Triplefox | cast which |
| 23:14:54 | EXetoC | Triplefox: fout.writeBytes(cast[seq[int8]](myseq), 0, myseq.len) |
| 23:15:17 | Triplefox | okay, yeah, it works |
| 23:15:40 | Triplefox | (writeBytes should have a uint8 version :< ) |
| 23:15:45 | EXetoC | I hope I'm not causing too much confusion again |
| 23:16:17 | Triplefox | for posterity, the final code |
| 23:16:18 | def- | Triplefox: i agree |
| 23:16:19 | Triplefox | var bytes : seq[uint8] = @[uint8(0x42),0x9A] |
| 23:16:19 | Triplefox | discard outf.writeBytes(cast[seq[int8]](bytes), 0, bytes.len) |
| 23:16:39 | def- | var bytes = @[0x42'u8, 0x9a] |
| 23:16:54 | * | barosl__ quit (Ping timeout: 245 seconds) |
| 23:17:01 | Triplefox | ah that's new to me |
| 23:17:40 | def- | actually "const bytes = ..." |
| 23:17:54 | def- | if that's all you need |
| 23:18:16 | fizzbooze | how do i get the underlying bytes of a string? |
| 23:18:32 | Triplefox | i can inline it in fact and just do a one-liner |
| 23:18:59 | EXetoC | fizzbooze: str[i].int8 |
| 23:19:17 | fizzbooze | EXetoC: i mean get the byte array :) |
| 23:19:31 | fizzbooze | like [byte] from string |
| 23:19:42 | def- | addr str[0] |
| 23:19:51 | fizzbooze | thankx |
| 23:19:52 | def- | that's a pointer to the array |
| 23:22:43 | wtw | freebsd parallel build PR is up..., hope this brakes nothing ;) |
| 23:23:33 | * | flaviu quit (Read error: Connection reset by peer) |
| 23:24:39 | * | sillesta quit (Ping timeout: 264 seconds) |
| 23:27:13 | * | flaviu joined #nim |
| 23:31:28 | * | tttt joined #nim |
| 23:32:04 | * | Outlander joined #nim |
| 23:35:33 | gokr | sdw: Granted, I have not yet used the Exceptions much in Nim (but I use them extensively in Smalltalk), but it looks to me that Nim today has no concept of resumable Exceptions. If that was indeed what you wondered? Smalltalk has them, and its pretty slick stuff, but I doubt Nim doesn't unwind when looking for handlers. |
| 23:37:17 | sdw | gokr: that's the main problem with exceptions. All the context is lost at the catch handler. C++ does not have resumable exceptions |
| 23:38:07 | sdw | gokr: This is the problem I suspect Rust is trying to solve. You can't leave where the problem occurred or it becomes more difficult to respond |
| 23:38:46 | gokr | To me it looks like "error codes" dressed up to satisfy the type system. But I may be wrong. |
| 23:38:53 | sdw | No, you' |
| 23:38:53 | bjz_ | yeah, Rust doesn't have exceptions for safety reasons. |
| 23:38:56 | sdw | re right |
| 23:39:24 | bjz_ | It is basically returning error codes, but you have to handle them |
| 23:39:34 | sdw | Yeah, which is pretty slick imo |
| 23:39:38 | dom96 | In Nim exceptions are tracked and you also have to handle them. |
| 23:39:44 | gokr | Further, an Exception is a ref object , you can stuff stuff in them to make sure the handler has the context you wish it to have. |
| 23:40:10 | bjz_ | also you can chain them together. There is some cool stuff that looks like it'll be in post 1.0 to make the ergonomics nicer |
| 23:40:27 | dom96 | If you mark that your procedure with {.raises: [].} |
| 23:40:35 | dom96 | *mark your |
| 23:40:45 | sdw | meh, I would need some examples that make good use of restarts. I know that exceptions do a bad job of replacing errors codes without resumability |
| 23:40:50 | bjz_ | yeah, not saying one is better than the other, just informing |
| 23:40:56 | * | lws joined #nim |
| 23:40:56 | * | lws quit (Changing host) |
| 23:40:56 | * | lws joined #nim |
| 23:42:21 | dom96 | IMHO that gives you the best of both worlds. |
| 23:42:33 | sdw | restarts? |
| 23:42:34 | gokr | sdw: I don't follow. Are you saying Rust error handling supports "restarts"? In what way do you mean? |
| 23:42:44 | dom96 | What are "restarts"? |
| 23:42:53 | * | lws__ quit (Ping timeout: 245 seconds) |
| 23:43:11 | gokr | I guess resumable Exceptions. Not that common, but Smalltalk, Lisp and Dylan has such things. |
| 23:43:16 | bjz_ | "I would need some examples that make good use of restarts" |
| 23:43:17 | bjz_ | ? |
| 23:43:54 | gokr | In Smalltalk you can have a handler x levels up that simply tells the Exception to resume, and it will keep on running. Because Smalltalk doesn't unwind the stack when looking for handlers. |
| 23:43:57 | bjz_ | Rust used to have conditions, but they were removed - if that is what you were referring to |
| 23:44:41 | gokr | I presume Nim unwinds, at least the manual has no mentions of being able to resume. |
| 23:45:31 | gokr | Right, is it Lisp that calls such "resumable Exceptions" conditions? |
| 23:46:54 | gokr | sdw: I just wonder how a regular error code can be considered to "support restarts"? |
| 23:47:54 | sdw | Where is the nim docs on restarts? Did those get removed from the langauge? |
| 23:48:23 | EXetoC | gokr: it reduces repetition? |
| 23:48:46 | gokr | dom96: Yeah, from the looks of it I think the Exception model in Nim is quite nice (with the tracking etc). Sure, not resumable, but that's actually not even used much in Smalltalk either. |
| 23:49:16 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:49:17 | gokr | EXetoC: You mean... resumable Exceptions? |
| 23:57:33 | * | renesac joined #nim |
| 23:57:43 | sdw | http://web.mit.edu/nimrod-lang/arch/i386_linux26/doc/manual.html#onraise-builtin |
| 23:59:53 | * | threewood quit (Ping timeout: 244 seconds) |
