| 00:00:08 | BlaXpirit | that may be something different then? |
| 00:00:32 | def- | random.nim(141, 9) Error: internal error: expr: var not init mtRandomBytes_138513 |
| 00:02:13 | Araq | that is a regression, right? |
| 00:02:23 | def- | definitely, the library used to work |
| 00:02:27 | Araq | def-: can you attach that to the current bug report please? |
| 00:02:34 | def- | sure |
| 00:02:51 | Araq | ty |
| 00:02:55 | * | brson quit (Quit: leaving) |
| 00:04:25 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0.1/20150122214805]) |
| 00:06:45 | Araq | hrm for me bug #2023 doesn't require deadcodeElim:on at all |
| 00:06:57 | Araq | it simply always crashes with the same error message |
| 00:07:03 | def- | yeah, same here |
| 00:08:05 | BlaXpirit | Araq, maybe the regression got worse recently? |
| 00:08:20 | BlaXpirit | that code works for me |
| 00:08:35 | Araq | what version are you using? |
| 00:08:36 | BlaXpirit | on commit 995510664e543ff74a10750e804767443429d5f8 |
| 00:08:55 | BlaXpirit | that's quite an old devel Sat Jan 24 |
| 00:09:20 | BlaXpirit | well not really old now that i think about it |
| 00:09:36 | BlaXpirit | and d:release breaks it |
| 00:09:59 | * | onionhammer joined #nim |
| 00:10:00 | BlaXpirit | maybe try d:debug or something |
| 00:10:01 | reactormonk | Araq, what happened to https://github.com/Araq/Nim/pull/1644 ? |
| 00:11:40 | BlaXpirit | and i currently can't build nim... long story |
| 00:14:00 | Araq | reactormonk: I should close that I guess |
| 00:14:51 | reactormonk | Araq, how do you personally test for regressions? A bunch of the tests fail and I never know which ones fail because of tests and which ones failed beforehand |
| 00:15:54 | * | noahmorrison joined #nim |
| 00:16:18 | onionhammer | araq stdin vs sockets aside |
| 00:17:06 | onionhammer | whats your recommendation for a scenario like im describing, with multiple modules. Take fowls nimlibs for example |
| 00:17:25 | onionhammer | you clone that folder, open it up in your editor, some might reference each other, but most are independent |
| 00:18:18 | Araq | onionhammer: the editor can generate a project file that imports all these |
| 00:18:26 | Araq | well |
| 00:18:36 | Araq | nimsuggest could do that too of course |
| 00:18:46 | reactormonk | onionhammer, I'd be fine with file sockets too |
| 00:20:09 | onionhammer | araq the ST plugin has the capability of setting a project file associate w/ a sublime project, but thats only if the user actually creates a sublime project. the nature of nim (to me) seems a lot more transient than something like C#/visual studio |
| 00:20:11 | Araq | reactormonk: usually I simply fix the bug and don't look at what commit may have broken it |
| 00:20:33 | onionhammer | in C# you're basically forced to create a big old project, and then a solution, with an entry point etc |
| 00:20:47 | noahmorrison | I can't cross compile a Hello World program to windows. `nim --os:windows --parallelBuild:1 c hw.nim` says that there is no such file or directory io.h |
| 00:20:48 | onionhammer | in nim you can just basically "run" any module independently |
| 00:20:55 | dom96 | ldlework: Was hoping that maybe you could help with our GSoC application. |
| 00:21:00 | onionhammer | it might not build if it's meant to be an include but whatever |
| 00:22:13 | Araq | onionhammer: in Aporia there is "run this file" and "run the project" and aporia knows the project because that's the one marked with a .nim.cfg file |
| 00:22:53 | reactormonk | noahmorrison, https://stackoverflow.com/questions/2211030/failing-to-compile-a-project-missing-io-h-file - seems to be a problem where there's no POSIX stuff missing |
| 00:25:07 | Araq | onionhammer: well the first problem is: how does the editor know if the file belongs to the project or not? nimsuggest knows all the files so the editor should ask nimsuggest |
| 00:26:27 | Araq | well ok, I guess you don't have to do that, you can leave that to nimsuggest to figure out |
| 00:26:58 | Araq | so you simply pass: sug "new file" line col and it does the right thing |
| 00:32:27 | Araq | onionhammer: ok, so nimsuggest should simply load previously unknown files? |
| 00:32:38 | Araq | no protocol changes necessary? |
| 00:33:26 | Araq | and thinking about it, this should simply work with how we process the module graph anyway. |
| 00:36:59 | Araq | noahmorrison: or use Wine. This way you can also debug problems your Windows users might report. ;-) |
| 00:43:15 | * | FusionGaming joined #nim |
| 00:45:06 | onionhammer | Araq i like this train of thought |
| 00:45:50 | onionhammer | let it work like a graph, so to speak |
| 00:47:59 | Araq | onionhammer: ok, seems like some trivial addition. consider it done |
| 00:48:26 | Araq | but please test it with projects already |
| 00:48:50 | onionhammer | yep, thats next on my list. |
| 00:48:52 | onionhammer | thanks |
| 00:48:55 | onionhammer | afk a while |
| 00:50:56 | * | bmaxa quit (Quit: Leaving) |
| 00:57:15 | * | reem quit (Remote host closed the connection) |
| 01:00:00 | * | AtomicBool joined #nim |
| 01:00:46 | AtomicBool | .eval echo(&5) |
| 01:00:49 | Mimbus | AtomicBool: eval.nim(3, 5) Error: type mismatch: got (int literal(5)) |
| 01:03:16 | * | reem joined #nim |
| 01:05:56 | * | reem quit (Remote host closed the connection) |
| 01:06:06 | * | kniteli quit (Ping timeout: 276 seconds) |
| 01:07:05 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 01:10:10 | vendethiel- | uh, with `proc retLit(): ref Literal = new(result); result.x = 5` <- what happens here? |
| 01:10:41 | vendethiel- | (it's a code example from the manual) there's no "var result" anywhere to be new()ed, and I don't see a result to a ptr |
| 01:11:13 | EXetoC | no, but result is the return value |
| 01:11:34 | vendethiel- | EXetoC: is there an implicit "var result : PROC_RET_TYPE"? |
| 01:11:43 | vendethiel- | (that is, at the beginning of every function) |
| 01:11:52 | EXetoC | basically |
| 01:12:02 | vendethiel- | (like being able to declare named return variables, go does that iirc) |
| 01:12:21 | EXetoC | and no return statement here so it's going to be returned implicity at the end |
| 01:12:44 | vendethiel- | EXetoC: is it statically checking that "result" was mentioned in the body? |
| 01:12:50 | vendethiel- | to decide that it needs to return it implicitly |
| 01:13:04 | * | brson joined #nim |
| 01:13:50 | vendethiel- | EXetoC: ? also, can there be an explicit return at the same time -- say, inside an if? |
| 01:13:54 | EXetoC | no, it will be returned anyway |
| 01:13:57 | EXetoC | yes |
| 01:14:49 | vendethiel- | EXetoC: okay, so, for a proc with void as the return type, a simple "return" will get inserted at the end? |
| 01:15:14 | vendethiel- | but does that mean that, with a simple `proc testret(): int = echo "hey"`, I'll get 0 (default int) returned? |
| 01:15:59 | EXetoC | both assumptions are correct |
| 01:16:14 | vendethiel- | alright, thank you |
| 01:18:36 | * | noahmorrison quit (Quit: WeeChat 1.1-dev) |
| 01:19:14 | * | kniteli joined #nim |
| 01:19:45 | vendethiel- | the manual doesn't seem to mention it, so: what's the scoping rules for converters? They won't get exported unless I put the asterisk there, right? |
| 01:19:59 | vendethiel- | are multiple passes of convert possible? |
| 01:20:09 | vendethiel- | or maybe, a language-built convert into a user-defined one? |
| 01:20:26 | * | reem joined #nim |
| 01:20:41 | vendethiel- | (by "language-built" I mean from int64 to int, for example) |
| 01:22:25 | EXetoC | yes same scoping rules as for most things |
| 01:23:16 | EXetoC | it seems to be one conversion only |
| 01:23:17 | vendethiel- | lexical scoping, then. If I import one inside a block:, I won't get it outside of it |
| 01:23:30 | vendethiel- | alright, one conversion, even for the built-in ones :-). Thank you!! |
| 01:24:01 | EXetoC | imports are only allowed at the top level |
| 01:24:07 | vendethiel- | oh, that also makes sense |
| 01:24:20 | vendethiel- | it was usings that were allowed inside blocks, then |
| 01:25:04 | vendethiel- | EXetoC: sorry, I'm sleep-reading the manual, it's making sense but you've helped me clarify the less clear parts |
| 01:26:51 | EXetoC | I don't know if it's mentioned there |
| 01:28:16 | vendethiel- | the "is operator" section doesn't describe the behavior wrt subtyping, etc. is it strict type matching? what happens with generics? I guess they're not reifed, but the "is" is apparently done at compile-time, so would that work? |
| 01:29:48 | vendethiel- | same for generic constraints (`proc test[T: int]()`, or `int|string` -- what happens with subtyping?) |
| 01:30:15 | AtomicBool | helllllooooooooo |
| 01:30:22 | vendethiel- | hi |
| 01:32:03 | * | mytrile quit (Read error: Connection reset by peer) |
| 01:38:16 | * | adam- joined #nim |
| 01:39:03 | * | dv-_ joined #nim |
| 01:39:52 | * | adam- is now known as adam12_ |
| 01:41:58 | * | Rush__ joined #nim |
| 01:43:08 | * | Grauwolf joined #nim |
| 01:43:12 | * | hguux_ quit (Ping timeout: 256 seconds) |
| 01:43:12 | * | adam12 quit (Ping timeout: 256 seconds) |
| 01:43:12 | * | VinceAddons quit (Ping timeout: 256 seconds) |
| 01:43:14 | * | Demon_Fox quit (Ping timeout: 256 seconds) |
| 01:43:14 | * | Gonzih quit (Ping timeout: 256 seconds) |
| 01:43:14 | * | visi0n quit (Ping timeout: 256 seconds) |
| 01:43:14 | * | jokra quit (Ping timeout: 256 seconds) |
| 01:43:14 | * | xAndy quit (Ping timeout: 256 seconds) |
| 01:43:14 | * | ekarlso quit (Ping timeout: 256 seconds) |
| 01:43:14 | * | dv- quit (Remote host closed the connection) |
| 01:43:15 | * | RushPL quit (Ping timeout: 256 seconds) |
| 01:43:15 | * | Mimbus quit (Ping timeout: 256 seconds) |
| 01:43:15 | * | kashyap___ quit (*.net *.split) |
| 01:43:15 | * | kashyap_ quit (*.net *.split) |
| 01:43:15 | * | wtw quit (*.net *.split) |
| 01:43:16 | * | beatmox quit (*.net *.split) |
| 01:43:16 | * | flyx quit (*.net *.split) |
| 01:43:21 | * | adam12_ is now known as adam |
| 01:43:25 | * | hguux__ joined #nim |
| 01:43:26 | * | hguux__ quit (Changing host) |
| 01:43:26 | * | hguux__ joined #nim |
| 01:43:30 | * | xAndy| joined #nim |
| 01:43:35 | vendethiel- | with a user-defined type class, can I do stuff like `generic t count(Vector[t]) is int` (asserting a function kind, using the type as a type param, and asserting return type as well) |
| 01:43:35 | vendethiel- | "Future versions of Nim may also support overloading based on the return type of the overloads" erm, how can you have both multiple dispatch and return type overloading? |
| 01:43:35 | * | vendethiel- notices he's very spammy and goes back to the manual |
| 01:43:58 | * | adam is now known as Guest24051 |
| 01:44:28 | * | Gonzih joined #nim |
| 01:44:52 | * | trevorriles joined #nim |
| 01:45:00 | * | Mimbus joined #nim |
| 01:45:26 | * | jokra joined #nim |
| 01:46:50 | * | kashyap___ joined #nim |
| 01:46:50 | * | kashyap_ joined #nim |
| 01:46:56 | * | reem quit (Remote host closed the connection) |
| 01:48:12 | * | beatmox joined #nim |
| 01:48:12 | * | wtw joined #nim |
| 01:48:12 | * | flyx joined #nim |
| 01:49:38 | EXetoC | vendethiel-: I assume that check should work, but some things are still broken |
| 01:51:12 | * | brson quit (Quit: leaving) |
| 01:56:28 | def- | how do you print the resulting code of a macro/template call again? |
| 01:57:25 | EXetoC | repr? |
| 01:57:53 | EXetoC | yep |
| 01:57:56 | def- | thanks |
| 01:58:45 | def- | and is there any way to expand all macros and templates and print the resulting code then? |
| 02:06:50 | * | ekarlso joined #nim |
| 02:08:46 | * | gunn joined #nim |
| 02:09:05 | * | Mimbus quit (Read error: Connection reset by peer) |
| 02:09:05 | * | flaviu quit (Read error: Connection reset by peer) |
| 02:10:15 | * | Mimbus joined #nim |
| 02:10:53 | * | bjz quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:11:31 | * | flaviu joined #nim |
| 02:12:01 | AtomicBool | Challenge! |
| 02:12:21 | AtomicBool | create Nim code to solve this problem! |
| 02:12:23 | AtomicBool | https://projecteuler.net/problem=5 |
| 02:14:42 | EXetoC | it can only be done with php |
| 02:15:16 | AtomicBool | wat |
| 02:15:23 | AtomicBool | im srs |
| 02:16:09 | AtomicBool | oh, if ur logged in, theres an input box |
| 02:16:13 | AtomicBool | but thats not the point |
| 02:16:29 | flaviu | AtomicBool: 232792560 |
| 02:16:44 | flaviu | https://gist.github.com/4070661f1fb09541e7f5 |
| 02:16:50 | AtomicBool | thanks |
| 02:16:56 | flaviu | it' |
| 02:16:57 | def- | flaviu: it should be nimcode, so "echo 232792560" |
| 02:17:04 | flaviu | s straightforward though |
| 02:17:30 | AtomicBool | flaviu can u time test that? |
| 02:18:06 | flaviu | 10.12s, I'm sure I could optimize it though. |
| 02:18:20 | AtomicBool | try optimizing it pls :) |
| 02:18:44 | AtomicBool | I'm trying to bench |
| 02:19:33 | * | zahary quit (Ping timeout: 276 seconds) |
| 02:20:47 | * | bjz joined #nim |
| 02:20:49 | * | MattAitchison joined #nim |
| 02:21:20 | flaviu | https://gist.github.com/b591fb9dbf2a67fc8ac5 3.5s |
| 02:23:57 | AtomicBool | flaviu, could it be optimized more? |
| 02:24:22 | def- | AtomicBool: you can google for more advanced mathematical solutions and implement them in nim for more speed |
| 02:25:24 | AtomicBool | in this case, in this bench, I didnt use a methmatical algor |
| 02:25:26 | AtomicBool | math* |
| 02:25:30 | AtomicBool | that was not intentional |
| 02:27:18 | Varriount__ | Woo! Maths! |
| 02:27:23 | * | Varriount__ is now known as Varriount |
| 02:27:41 | * | sillesta joined #nim |
| 02:27:46 | Varriount | Hello sillesta |
| 02:27:53 | sillesta | hey |
| 02:28:11 | AtomicBool | Just try, at your best without using google, to try to optimize it as BEST as u can |
| 02:29:23 | * | reem joined #nim |
| 02:30:26 | flaviu | AtomicBool: 0 seconds is almost possible. |
| 02:31:07 | AtomicBool | flaviu, naive, but 0 seconds, maybe u can do the same? https://gist.github.com/Ap0ph1s/8ae6029e4312d3d71554 |
| 02:31:26 | * | darkf joined #nim |
| 02:31:46 | * | reem quit (Remote host closed the connection) |
| 02:32:23 | * | reem joined #nim |
| 02:32:45 | * | reem quit (Remote host closed the connection) |
| 02:33:19 | * | reem joined #nim |
| 02:33:36 | * | reem quit (Remote host closed the connection) |
| 02:48:24 | def- | AtomicBool: sure: https://gist.github.com/def-/c1e93006eb853a35dcd7 |
| 02:48:47 | def- | with nim -d:release pj5 it runs in 40 ms for me |
| 02:50:16 | AtomicBool | thats 0.04 secs right? |
| 02:50:20 | dtscode | can someone tell me why this isnt printing anything? https://bitbucket.org/dtscode/billspc/src |
| 02:50:20 | def- | yes |
| 02:50:42 | AtomicBool | lemme test my rust version again, havent in weeks |
| 02:50:44 | flaviu | I don't really like that. |
| 02:50:45 | def- | dtscode: asking me for a login |
| 02:50:57 | flaviu | Best for everything to use the same code |
| 02:50:58 | dtscode | oshit. forgot i set it to private. give me a sec |
| 02:51:36 | dtscode | ok it should be fine now |
| 02:52:34 | def- | It's funny that for Nim code clang is twice as fast as gcc here, while for C code it's the opposite: https://github.com/nsf/pnoise |
| 02:52:59 | AtomicBool | actaully im doing this wrong |
| 02:53:12 | * | sillesta quit (Ping timeout: 246 seconds) |
| 02:54:32 | Varriount | def-: Makes me wonder if someone should come up with a 'metacompiler' that compiles versions of a C/C++ program, and picks the fastest one. |
| 02:56:35 | def- | Varriount: probably better to do pgo |
| 02:56:51 | flaviu | PGO won't do much here. |
| 02:57:12 | AtomicBool | def- how fast is ur pc? |
| 02:57:19 | AtomicBool | as in specs* |
| 02:57:39 | def- | AtomicBool: ehm, core2quad q9300 |
| 02:57:43 | def- | so nothing that modern |
| 02:57:57 | AtomicBool | idk if that helps me |
| 02:58:21 | def- | what about compiling the rust and nim code on your computer and comparing? |
| 02:58:35 | AtomicBool | im downloafing nim atm |
| 02:59:17 | flaviu | The disassembly for my code: http://i.imgur.com/OyMJ7jc.png |
| 03:00:05 | * | skyfex____ quit (Quit: (null)) |
| 03:00:18 | AtomicBool | I think im gonna create a blog for comparing both Rust and Nim in some PE problems |
| 03:00:27 | def- | AtomicBool: compiling with "rustc -O main.rs"? |
| 03:00:44 | AtomicBool | No, just regular rustc main.rs |
| 03:00:59 | def- | isn't that unoptimized? |
| 03:01:25 | AtomicBool | I never tried with -O |
| 03:01:29 | def- | for nim you also have to compile with "nim -d:release c main.nim" for good speed |
| 03:02:12 | AtomicBool | okay done downloading |
| 03:02:34 | dtscode | dom96, you should take a look dom96 |
| 03:02:45 | dtscode | wtf did it say dom96 twice? |
| 03:03:37 | def- | AtomicBool: for me: rust: 0.249s, nim: 0.038s |
| 03:04:11 | flaviu | It's best to use exactly the same code. That way you benchmark the language, not implementation. |
| 03:04:12 | AtomicBool | what extention is the nim binary? |
| 03:04:20 | AtomicBool | we are falviu |
| 03:04:24 | AtomicBool | flaviu |
| 03:05:00 | def- | AtomicBool: on windows .exe, otherwise none |
| 03:06:22 | flaviu | You can also get a tiny speed boost if you use uint32s. |
| 03:09:16 | * | skyfex joined #nim |
| 03:10:24 | AtomicBool | rust vs nim without compiler args, rust performas faster |
| 03:10:43 | AtomicBool | but with args, nim passes rust by a bit |
| 03:10:53 | AtomicBool | I gtg now, ill look into this tomorrow |
| 03:11:13 | def- | good luck, looking forward to the benchmarks, AtomicBool |
| 03:13:28 | bjz | what is the nim code? |
| 03:13:37 | def- | bjz: https://gist.github.com/def-/c1e93006eb853a35dcd7 |
| 03:13:46 | def- | just a literal translation of the rust one |
| 03:13:53 | * | ARCADIVS joined #nim |
| 03:15:32 | AtomicBool | In these benchmarks, does it have to be exact code translations? |
| 03:15:41 | bjz | interesting. wonder if its a gcc/llvm issue. or if its still our (rust) IR output that could be improved. Seems like a simple program that should be pretty much the same performance wise |
| 03:16:12 | bjz | what numeric type does nim default to? |
| 03:16:44 | bjz | (by gcc/llvm I mean, gcc vs llvm) |
| 03:16:45 | def- | bjz: int64 on 64bit, int32 on 32bit |
| 03:16:51 | AtomicBool | Its rustc, the IR it outputs is not as fast as it should be at ALL |
| 03:17:20 | def- | bjz: oh, you're right, it's a gcc vs llvm issue |
| 03:17:26 | bjz | AtomicBool: yeah - it's definitely something that could be improved |
| 03:18:06 | def- | "nim -d:release --cc:clang c pj5" and the nim solution is much slower, 0.169s instead of 0.038s with gcc for me |
| 03:18:46 | bjz | AtomicBool: if the llvm IR was better, you'd hope that it could generate better asm, but I've heard that gcc has always had a bit of an edge over llvm in terms of release builds |
| 03:19:24 | def- | bjz: actually with Nim I often see clang being faster as a backend than gcc |
| 03:20:02 | bjz | really? |
| 03:20:05 | bjz | interesting |
| 03:20:09 | def- | yes, for example here: https://github.com/nsf/pnoise |
| 03:22:00 | bjz | you might get more insight on rust internals - I'm not super knowledgable at the compiler backend stuff |
| 03:22:20 | AtomicBool | I'm starting to see an immaturity pattern here |
| 03:23:08 | * | bjz thinks things like this could be of mutual interest |
| 03:23:38 | AtomicBool | Rust performance isn't ready and not what it is supposed to be right now, with IR improvennts and llvm not optimizing it like it should be |
| 03:24:14 | AtomicBool | While nim, compiling to c, has advantages of c optimized compilers |
| 03:24:40 | bjz | I'm not too concerned. it's something that can be improved over time. C was pretty bad at the beginning |
| 03:24:47 | flaviu | AtomicBool: IME Nim gets the best performance with clang too... |
| 03:25:02 | def- | flaviu: except for this small benchmark |
| 03:25:56 | bjz | AtomicBool: I would be wary about relying on that argument |
| 03:25:58 | AtomicBool | I'm not concerned either, performance to this extent isn't their priority rn |
| 03:26:24 | AtomicBool | Its essentially C vs Rust |
| 03:26:31 | bjz | yeah |
| 03:26:49 | bjz | Nim has the advantage of leaning on C |
| 03:27:23 | AtomicBool | However, rust isnt fully optimized as a whole |
| 03:27:33 | AtomicBool | We shall see as the time goes on |
| 03:32:22 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 03:32:29 | * | vendethiel- quit (Ping timeout: 264 seconds) |
| 03:34:07 | * | reem joined #nim |
| 03:38:41 | * | reem quit (Ping timeout: 246 seconds) |
| 03:55:22 | * | EXetoC quit (Ping timeout: 240 seconds) |
| 04:12:10 | AtomicBool | Should I include compiler flags or nah? |
| 04:12:42 | AtomicBool | Since rustc and nim do different things when optimizing |
| 04:18:20 | flaviu | not really. Nim turns off bound and overflow checks, and turns off stack traces. But CC does most the hard work. |
| 04:24:04 | * | Demon_Fox joined #nim |
| 04:26:48 | AtomicBool | The flags is more of a llvm vs GCC thing |
| 04:26:51 | AtomicBool | Right? |
| 04:29:40 | AtomicBool | As in compiler backend features |
| 04:30:37 | flaviu | yes, but I think nim just passes O3. |
| 04:31:03 | flaviu | And clang emulates all the GCC options that do useful stuff anyway. |
| 04:31:10 | flaviu | night. |
| 04:34:48 | AtomicBool | I'll see, and night |
| 05:02:37 | * | brson joined #nim |
| 05:05:38 | * | brson quit (Client Quit) |
| 05:05:53 | * | brson joined #nim |
| 05:06:16 | * | dv-_ is now known as dv- |
| 05:24:48 | * | kniteli quit (Ping timeout: 276 seconds) |
| 05:55:03 | * | johnsoft quit (Ping timeout: 244 seconds) |
| 06:04:08 | * | brson quit (Quit: leaving) |
| 06:14:34 | * | BlueJello joined #nim |
| 06:32:10 | * | BlueJello left #nim ("Textual IRC Client: www.textualapp.com") |
| 07:00:05 | * | NimBot joined #nim |
| 07:21:25 | * | reem joined #nim |
| 07:25:23 | * | Demon_Fox quit (Quit: Leaving) |
| 07:26:31 | * | NimBot joined #nim |
| 07:29:57 | * | reem quit (Remote host closed the connection) |
| 07:33:58 | * | reem joined #nim |
| 07:51:23 | * | SplinterOfChaos quit (Ping timeout: 246 seconds) |
| 08:11:59 | * | brson joined #nim |
| 08:21:58 | * | brson quit (Quit: leaving) |
| 08:28:30 | * | BitPuffin joined #nim |
| 08:29:28 | * | reem quit (Remote host closed the connection) |
| 08:32:21 | * | reem joined #nim |
| 08:33:04 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 08:39:00 | * | xeizlif_ joined #nim |
| 08:40:00 | * | Grauwolf_ joined #nim |
| 08:40:05 | * | milosn_ joined #nim |
| 08:40:29 | * | gokr joined #nim |
| 08:45:05 | * | adam- joined #nim |
| 08:45:21 | * | Grauwolf quit (*.net *.split) |
| 08:45:21 | * | Guest24051 quit (*.net *.split) |
| 08:45:21 | * | milosn quit (*.net *.split) |
| 08:45:21 | * | eigenlicht quit (*.net *.split) |
| 08:45:21 | * | Roin quit (*.net *.split) |
| 08:45:22 | * | gokr1 quit (*.net *.split) |
| 08:45:22 | * | xeizlif quit (*.net *.split) |
| 08:45:54 | * | adam- is now known as adam |
| 08:46:00 | * | adam is now known as Guest51733 |
| 08:49:15 | * | milosn_ is now known as milosn |
| 08:51:09 | * | Roin joined #nim |
| 08:51:34 | * | eigenlicht joined #nim |
| 08:57:28 | * | reem quit (Remote host closed the connection) |
| 08:58:08 | * | reem joined #nim |
| 08:58:52 | * | Boscop_ joined #nim |
| 09:02:20 | * | phira quit (Max SendQ exceeded) |
| 09:02:36 | * | Boscop__ quit (Ping timeout: 277 seconds) |
| 09:02:49 | * | phira joined #nim |
| 09:03:43 | * | Grauwolf_ quit (Quit: Bye!) |
| 09:04:09 | * | Grauwolf joined #nim |
| 09:07:54 | * | reem quit (Remote host closed the connection) |
| 09:08:53 | * | BitPuffin joined #nim |
| 09:19:08 | * | xeizlif_ is now known as xeizlif |
| 09:28:57 | * | alexruf joined #nim |
| 09:30:38 | * | reem joined #nim |
| 09:58:31 | * | Matthias247 joined #nim |
| 09:59:09 | * | mytrile joined #nim |
| 10:04:21 | * | reem quit (Remote host closed the connection) |
| 10:05:02 | * | akiradeveloper joined #nim |
| 10:07:34 | reactormonk | Araq, how do I test for vmgen.nim? |
| 10:09:53 | Araq | reactormonk: the vm stores cstring as string |
| 10:10:21 | Araq | so the check == tyString becomes in {tyString, tyCstring} |
| 10:10:34 | Araq | hardest part is to come up with a test for that :P |
| 10:10:34 | reactormonk | oh, I modified it into a case statement |
| 10:10:42 | reactormonk | yeah, exactly. |
| 10:11:15 | Araq | btw, keep up the good work! |
| 10:11:30 | reactormonk | Might drop again as soon as I get a job |
| 10:11:59 | * | VinceAddons joined #nim |
| 10:12:33 | reactormonk | origin [email protected]:Araq/Nim.git (fetch) |
| 10:12:35 | reactormonk | origin [email protected]:reactormonk/Nim.git (push) |
| 10:12:38 | reactormonk | ^ very useful setup |
| 10:12:59 | reactormonk | Araq, I have no idea how to test that stuff btw |
| 10:13:35 | Araq | reactormonk: add an 'echo "came here"' into the compiler and put stuff in a static block |
| 10:14:04 | reactormonk | Araq, can I test that? |
| 10:15:15 | Araq | the "came here"? nah, that's just for development |
| 10:15:38 | Araq | but just do something like: |
| 10:15:41 | Araq | static: |
| 10:16:02 | Araq | let x = cstring("foobar") |
| 10:16:15 | Araq | echo high(x) |
| 10:16:24 | Araq | that triggers the vmgen |
| 10:16:57 | Araq | this will later cause endless amounts of pain when the HLO arrives |
| 10:17:09 | * | reem joined #nim |
| 10:17:16 | reactormonk | HLO? |
| 10:17:27 | reactormonk | btw, declare https://github.com/Araq/Nim/issues/460 as wontfix? |
| 10:17:39 | Araq | "high level optimizer" |
| 10:17:40 | * | kuzy000_ joined #nim |
| 10:18:11 | * | alexruf quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 10:18:17 | reactormonk | I don't have any concept associated with that name |
| 10:18:34 | Araq | well I invented that name |
| 10:19:04 | Araq | it does all the trivial optimizations that a C backend easily misses or isn't allowed to do |
| 10:19:17 | Araq | it's on the roadmap |
| 10:20:40 | reactormonk | such as? |
| 10:21:37 | Araq | GCSE |
| 10:21:39 | Araq | loop invariant hoisting |
| 10:21:40 | Araq | escape analysis for string/seq |
| 10:21:42 | Araq | inlining of small lambdas |
| 10:23:46 | reactormonk | Hm. I'd have to spend an hour to understand them and their significance |
| 10:24:16 | reactormonk | Araq, where do I put tests which test if a file compiles |
| 10:24:37 | Araq | these are simply tests without a discard section |
| 10:24:50 | Araq | put it under the appropriate category |
| 10:25:15 | Araq | and document the tester better please |
| 10:26:08 | reactormonk | If I'd know how it would work... |
| 10:26:24 | reactormonk | I'm currently using ./koch tests c <directory name> |
| 10:28:21 | Araq | that's fine |
| 10:28:42 | Araq | I use |
| 10:28:54 | Araq | tests/testament/tester cat <category> |
| 10:30:03 | reactormonk | Where would you put the code at https://github.com/Araq/Nim/issues/496 ? |
| 10:30:42 | Araq | tests/method ? |
| 10:30:42 | * | reem quit (Remote host closed the connection) |
| 10:31:03 | reactormonk | thanks |
| 10:32:04 | reactormonk | ah, there's already a test for this |
| 10:33:11 | * | reem joined #nim |
| 10:34:01 | Araq | when I don't add a test case that's usually not because I'm lazy |
| 10:34:16 | Araq | but because I expect the bug to never happen again |
| 10:36:00 | Araq | hrm the max iteration count in the vm is set to half a million |
| 10:36:31 | Araq | and people managed to break that limit |
| 10:36:36 | Araq | https://github.com/Araq/Nim/issues/1989 |
| 10:38:27 | * | gokr quit (Ping timeout: 264 seconds) |
| 10:43:26 | reactormonk | don't wanna compute stuff in the vm? ^^ |
| 10:43:35 | * | alexruf joined #nim |
| 10:44:25 | reactormonk | Araq, where is stuff like let/var in the compiler? |
| 10:44:57 | Araq | in the parser, semantic checker and the codegens |
| 10:45:12 | Araq | ie. your question makes little sense ;-) |
| 10:45:28 | reactormonk | https://github.com/Araq/Nim/issues/868 |
| 10:45:47 | * | reem quit (Remote host closed the connection) |
| 10:47:07 | reactormonk | Araq, I have found nkAsgn... |
| 10:47:29 | Araq | there is some shadow checking already done |
| 10:47:41 | Araq | in the right spot |
| 10:48:37 | Araq | semstmts.nim:411 |
| 10:48:53 | Araq | check if it conflicts with skResult and produce a warning |
| 10:56:11 | reactormonk | Araq, what's that shadow checking? |
| 10:56:26 | reactormonk | oKeepVariableNames <- ? |
| 10:56:32 | Araq | yup |
| 10:58:55 | * | reem joined #nim |
| 11:00:54 | reactormonk | Araq, how do I check for said conflict? I'd go "if sons[0].ident == "result"" |
| 11:00:59 | * | dumdum joined #nim |
| 11:01:37 | * | mytrile quit (Read error: Connection reset by peer) |
| 11:02:53 | Araq | if shadowed.kind == skResult |
| 11:03:13 | reactormonk | ahhh |
| 11:03:36 | reactormonk | I should get some fucking sleep |
| 11:03:51 | Araq | it's noon |
| 11:04:15 | * | alexruf quit (Quit: Textual IRC Client: www.textualapp.com) |
| 11:04:24 | reactormonk | Araq, Austin TX, here. |
| 11:04:44 | reactormonk | Araq, anyway, result isn't found by findShadowedVar |
| 11:05:50 | Araq | but it should |
| 11:07:01 | reactormonk | let shadowed = findShadowedVar(c, v) |
| 11:07:02 | reactormonk | debug(n) |
| 11:07:04 | reactormonk | debug(shadowed) |
| 11:07:11 | reactormonk | gives me null on my test |
| 11:07:30 | reactormonk | http://sprunge.us/BIDM |
| 11:07:32 | * | gokr joined #nim |
| 11:07:43 | Araq | well that's good |
| 11:07:50 | Araq | because your test has no 'result' |
| 11:07:59 | Araq | it doesn't have a return type |
| 11:08:20 | reactormonk | kk |
| 11:08:24 | * | Boscop__ joined #nim |
| 11:08:28 | reactormonk | yup, finds it when I add a result type |
| 11:11:03 | Araq | yeah it does |
| 11:11:08 | reactormonk | Araq, btw, it doesn't seem to have the sfShadowed flag, only sfUsed |
| 11:11:09 | reactormonk | result_89005: ["sfUsed"], [], ["test.nim", 1, 0], skResult |
| 11:11:30 | * | phira quit (Read error: Connection reset by peer) |
| 11:11:32 | * | Boscop_ quit (Ping timeout: 245 seconds) |
| 11:11:45 | Araq | why would it? |
| 11:11:51 | * | phira joined #nim |
| 11:12:26 | reactormonk | well, that's the shadowed result |
| 11:12:58 | * | gokr quit (Remote host closed the connection) |
| 11:13:10 | * | sillesta joined #nim |
| 11:13:57 | * | gokr joined #nim |
| 11:18:01 | * | vendethiel joined #nim |
| 11:18:46 | reactormonk | oh wait. |
| 11:21:36 | reactormonk | Araq, should I add a condition to warnShadowIdent or always warn? |
| 11:21:48 | Araq | always warn |
| 11:23:22 | reactormonk | warning only, no error, correct? |
| 11:25:53 | Araq | warning only |
| 11:26:04 | Araq | perhaps later an error |
| 11:26:12 | Araq | but we don't want to needlessly break code |
| 11:26:17 | Araq | bbl |
| 11:28:12 | reactormonk | how do I test for warnings? |
| 11:43:18 | * | Jesin quit (Ping timeout: 264 seconds) |
| 11:44:13 | * | Jesin joined #nim |
| 11:49:43 | * | gokr quit (Quit: Leaving.) |
| 12:06:53 | * | akiradeveloper quit () |
| 12:13:52 | vendethiel | on the topic of last night's questions: "mixin" is interesting, but how does it know the signature? It's basically delayed until the template is invoked? |
| 12:19:10 | * | darkf_ joined #nim |
| 12:23:14 | * | darkf quit (Ping timeout: 272 seconds) |
| 12:24:10 | * | darkf_ is now known as darkf |
| 12:40:21 | * | Mimbus quit (Read error: No route to host) |
| 12:41:13 | * | flaviu quit (Read error: Connection reset by peer) |
| 12:41:18 | * | flaviu_ joined #nim |
| 12:44:26 | * | johnsoft joined #nim |
| 12:49:11 | * | flaviu_ is now known as flaviu |
| 13:00:43 | * | gokr joined #nim |
| 13:40:09 | * | EXetoC joined #nim |
| 14:02:14 | ekarlso | .eval @[1,2] & &[3,4] |
| 14:04:13 | * | dumdum quit (Ping timeout: 256 seconds) |
| 14:14:40 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 14:19:21 | * | Mimbus joined #nim |
| 14:19:23 | flaviu | ekarlso: ^ |
| 14:20:00 | ekarlso | flaviu: ...... |
| 14:20:02 | ekarlso | it's always dead :P |
| 14:20:26 | ekarlso | flaviu: when you think we gonna use packages ? :D |
| 14:21:58 | flaviu | It's not up to me, have a chat with Araq |
| 14:22:08 | ekarlso | :p |
| 14:33:05 | * | dumdum joined #nim |
| 14:45:05 | * | 5EXAAD13L joined #nim |
| 14:52:46 | * | 5EXAAD13L quit (Quit: Verlassend) |
| 14:53:12 | * | 5EXAAD15X joined #nim |
| 14:56:29 | * | 5EXAAD15X is now known as pafmaf |
| 14:57:12 | * | Trustable joined #nim |
| 14:59:32 | * | kashyap___ quit (Quit: Page closed) |
| 15:00:19 | * | dumdum quit (Ping timeout: 256 seconds) |
| 15:00:39 | * | pafmaf quit (Quit: Verlassend) |
| 15:00:45 | * | pafmaf joined #nim |
| 15:01:26 | * | darkf quit (Quit: Leaving) |
| 15:26:12 | * | BlaXpirit joined #nim |
| 15:40:59 | AtomicBool | will nim ever have a vm of its own, without compilation to C? |
| 15:48:32 | AtomicBool | Ok, anyone online so we can get started on this article? |
| 15:48:44 | AtomicBool | I hope this to be the LAST article of nim vs rust |
| 15:50:18 | flaviu | AtomicBool: Nim already has an internal VM. |
| 15:50:53 | AtomicBool | As in, When will nim run without compilation to C? |
| 15:51:59 | sillesta | does it need to? |
| 15:53:22 | flaviu | AtomicBool: It's already possible. $ nim i |
| 15:53:40 | AtomicBool | oh |
| 15:55:39 | AtomicBool | I get errors when compiling with I instead of C |
| 15:55:47 | AtomicBool | "too many iterations" |
| 15:55:50 | AtomicBool | any help? |
| 15:56:06 | dtscode | i is interactive mode |
| 15:56:25 | dtscode | its still experimental iirc |
| 15:56:32 | dtscode | http://forum.nim-lang.org/t/817 |
| 15:57:04 | flaviu | AtomicBool: It's trying to protect you from yourself by not allowing long loops. |
| 15:57:28 | AtomicBool | I want it to allow long loops :( |
| 15:58:12 | flaviu | patch compiler/vmdef.nim:19 |
| 15:59:00 | AtomicBool | wut |
| 16:00:17 | Araq | AtomicBool: will Rust ever compile via its own backend, not via LLVM? |
| 16:00:27 | Araq | why is that important? |
| 16:01:00 | AtomicBool | Mainly because If use C, its C vs Rust |
| 16:01:08 | dtscode | no its not |
| 16:01:11 | AtomicBool | use the c way of compiling |
| 16:01:15 | AtomicBool | yes it is? |
| 16:01:19 | dtscode | no its not |
| 16:01:24 | AtomicBool | How so? |
| 16:01:33 | Araq | does C have exceptions or a GC? |
| 16:01:40 | dtscode | because it just happens to compile to c |
| 16:01:48 | Araq | proper closures? generics? |
| 16:01:55 | dtscode | thats like saying its not really c++ code, its just ELFs |
| 16:01:57 | Araq | coroutines? |
| 16:02:01 | AtomicBool | That doesnt make sense, Nim compiles to C correct? |
| 16:02:15 | Araq | yes, but it *compiles* |
| 16:02:18 | dtscode | yes. and c++ compiles to ELF format binaries |
| 16:02:29 | AtomicBool | Im benchmarking here |
| 16:02:33 | AtomicBool | not comparing features |
| 16:02:43 | dtscode | its still nim vs rust |
| 16:02:45 | flaviu | AtomicBool: Nim isn't like coffeescript, where it's a mostly 1:1 mapping. |
| 16:03:34 | dtscode | while im waiting for someone to answer my async question i think i might write a brainfuck interpreter |
| 16:04:06 | def- | dtscode: that's really fun in nim: https://github.com/def-/nim-unsorted/blob/master/brainfuck.nim |
| 16:04:20 | AtomicBool | I fail to see how its still nim vs rust, when nim->C-> |
| 16:04:49 | dtscode | why not just say its AT&T ASM vs Rust? since c compiles to that |
| 16:05:10 | AtomicBool | Im talking about the same level of compilation |
| 16:05:22 | dtscode | why does that matter? |
| 16:05:25 | AtomicBool | Nim has one more compilation than Rust does |
| 16:05:30 | dtscode | no it doesnt |
| 16:05:35 | dtscode | not if rust uses llvm |
| 16:06:19 | AtomicBool | whats the main source of Nim's speed? |
| 16:06:41 | Araq | maybe our good backend that produces good C code? |
| 16:06:46 | dtscode | and anyways, even if it did, so what? if you take the Nims compiler IR then you have to use Rust's IR |
| 16:06:52 | Araq | and our not too shitty GC? |
| 16:07:00 | AtomicBool | it was an experiment anyway, if it was too difficult, I would just use nim c |
| 16:07:14 | AtomicBool | Exactly |
| 16:07:30 | Araq | AtomicBool: you have no idea of how much effort was put into producing efficient C code |
| 16:07:42 | Araq | it could easily generate crappy C code instead |
| 16:07:45 | AtomicBool | I am not bashing anything? |
| 16:07:52 | sillesta | Araq: unrelated: what makes nim's GC different from say Java's, and why doesn't java use one similar to nim? |
| 16:08:19 | Araq | AtomicBool: you pretend that compiling to C is like some cheap hack but it's not. |
| 16:08:28 | dtscode | Araq, no you misunderstand |
| 16:08:29 | Araq | it's hard. |
| 16:08:30 | AtomicBool | I am not... |
| 16:08:53 | dtscode | hes saying that since nim compiles to c then you are really comparing the speed of c and rust |
| 16:09:06 | AtomicBool | the speed of good C code in this case |
| 16:09:33 | Araq | well so what? do you even know how C-like LLVM's IR is? |
| 16:09:38 | dtscode | and im arguing that if you say that, you cant stop there. you would have to go to Rust compiler IR |
| 16:10:43 | Araq | Rust seems to produce some suboptimal LLVM code, currently. in principle the languages are on par, efficiency wise |
| 16:11:14 | Araq | Rust has some advantage not requiring a GC, but then Nim's thread local heap is a much better default than Rust's |
| 16:11:50 | flaviu | sillesta: Thread-local heaps helps avoid lots of complexity. |
| 16:12:03 | Araq | if you buy the "Nim needs a GC to work" argument, that is. |
| 16:12:36 | AtomicBool | Rust's LLVM IR is no where its supposed to be rn |
| 16:14:03 | flaviu | AtomicBool: Does https://gist.github.com/dbc263cbc8b0ff52821f look like anything but "portable assembler"? |
| 16:14:32 | dtscode | holy shit def thats a lot of nim |
| 16:14:49 | AtomicBool | its not on our priority list, with all these stabliazations |
| 16:14:54 | def- | dtscode: was fun to write and learned the language |
| 16:15:05 | dtscode | def-, i meant the repo itself |
| 16:15:12 | def- | i know |
| 16:15:23 | dtscode | oh |
| 16:16:08 | AtomicBool | does nim use gcc? |
| 16:16:26 | def- | AtomicBool: you can use many c compilers, like gcc, clang, icc, tinycc |
| 16:16:35 | def- | but default is gcc |
| 16:16:40 | AtomicBool | by default, which? |
| 16:17:03 | dtscode | pcc works too :D |
| 16:17:43 | Araq | AtomicBool: btw dom96 is working on a native codegen for fun (!) and he recently told me "you know what? generating asm is easier than generating C" |
| 16:18:24 | Araq | and I can only agree |
| 16:18:49 | dtscode | so we are getting closer to being our own standalone tool? |
| 16:18:57 | flaviu | Araq: What about register allocation? |
| 16:19:03 | AtomicBool | ude, I have no fucking idea how hard it is to do what you do |
| 16:19:21 | Araq | flaviu: you don't have to do that at all really. |
| 16:19:45 | Araq | generating *fast* asm surely is harder than generating C, don't get me wrong here |
| 16:20:15 | AtomicBool | Im only 16, I'm trying to learn, not bash other languages |
| 16:20:17 | Araq | but generating asm is pretty simple |
| 16:20:27 | Araq | when you are not after speed |
| 16:20:48 | AtomicBool | so literally correct me if Im wrong, This is all the learn after all |
| 16:20:51 | * | reem quit (Remote host closed the connection) |
| 16:21:39 | reloc0 | Araq: but even when you just create any asm, you still have those nasty platform issues so much more then when using c as an intermediate language . thus i always thought that it was a very wise decission for nim to use c and reuse everything the c compiler can do. |
| 16:21:47 | flaviu | Araq: Where do you store locals though? |
| 16:21:51 | def- | AtomicBool: you can consider it an implementation detail how the nim/rust code get compiled into a binary. i don't think that's relevant for benchmarking the languages |
| 16:22:00 | Araq | flaviu: on the stack |
| 16:23:06 | flaviu | var i = 0; var j = 0; inc i. What happens there? |
| 16:24:12 | Araq | you output some load; inc; store triple |
| 16:24:57 | AtomicBool | so does nim use gcc be deafult? |
| 16:25:00 | AtomicBool | default? |
| 16:25:08 | dtscode | if it can, yes |
| 16:25:14 | flaviu | AtomicBool: https://github.com/Araq/Nim/blob/devel/config/nim.cfg#L10 |
| 16:25:58 | AtomicBool | ok den |
| 16:26:01 | Araq | reloc0: the nasty platform issues are worse with C than with asm. asm is mostly well defined, in C every basic operation is pretty much full of UB |
| 16:26:36 | Araq | we generate C because it's universally available with good optimizers everywhere |
| 16:26:45 | reloc0 | Araq: ah interesting. |
| 16:27:06 | AtomicBool | I dont think im going to include compiler flags, since thats an LLVM vs gcc thing |
| 16:27:09 | reloc0 | but i thought that it was probably to reuse the optimizers that the c-compilers have |
| 16:27:26 | AtomicBool | so both w/out compiler flags |
| 16:27:36 | def- | AtomicBool: you should do release/optimized builds, otherwise it's useless |
| 16:27:46 | AtomicBool | whats useless? |
| 16:28:01 | flaviu | reloc0: It's impossible to reuse code from GCC, it's GPL. It's possible to use code from Clang, but that's just called emiting LLVM IR. |
| 16:28:06 | def- | AtomicBool: to compare the performance of debug builds |
| 16:29:10 | Araq | reloc0: and don't let me get started about what you can express in asm that you can't in C ;-) |
| 16:29:11 | AtomicBool | def-, the flags used in rustc vs nim d:release so different things since they are both different compiler backends |
| 16:30:05 | AtomicBool | its a factor of the compiler backends witht he flags, not the language implmentation itself imo |
| 16:30:15 | reloc0 | Araq: i know that from my work with microcontrollers :) on those things c is close to the hardware but still a fat abstraction layer. |
| 16:31:47 | dtscode | how do i read just one char from input? |
| 16:33:49 | AtomicBool | Okay.... |
| 16:34:07 | AtomicBool | So does anyone have time to translate a few lines of code with me? |
| 16:34:15 | AtomicBool | Araq? :) |
| 16:34:51 | Araq | I don't really have time to be in #nim |
| 16:35:57 | def- | AtomicBool: try it yourself? best way to learn about a language |
| 16:37:22 | AtomicBool | I was thinking if one nimcoder did the nim, and one Rust coder did the Rust, and we came to some sort of agreement of how this is set up, the benchmarks would be unbiased |
| 16:37:46 | AtomicBool | I dont want to create a biased article towards Rust |
| 16:37:47 | EXetoC | Araq: leave, or rename to Araq_ and ignore messages :p |
| 16:38:10 | * | NimBot joined #nim |
| 16:38:15 | AtomicBool | there lil PE code snippets |
| 16:38:17 | def- | i can probably translate a few pieces of code, but no guarantees |
| 16:39:09 | AtomicBool | Im sure u can, max lines of code there was i think was like 30, but i might not do those |
| 16:39:28 | AtomicBool | Okay last night, we did a one benchmark |
| 16:39:53 | AtomicBool | def-, I hope you understood my reason for excluding compiler flags for both langs right? |
| 16:40:19 | def- | AtomicBool: oh, you want to run "nim c file" without -d:release? |
| 16:40:35 | def- | that's totally useless, spits out unoptimized code full of debugging stuff |
| 16:40:38 | def- | will always be slow |
| 16:40:41 | AtomicBool | Yes, same with Rust, no rustc -O rust.rs |
| 16:40:54 | def- | so you're just comparing which language has more debugging stuff in by default? |
| 16:41:04 | AtomicBool | Essentially |
| 16:41:10 | def- | why is that relevant? |
| 16:41:14 | EXetoC | dtscode: from stdin? possibly with the readline wrapper |
| 16:41:17 | AtomicBool | for the reasons I said above |
| 16:41:33 | def- | No one will run performance dependent code without -d:release |
| 16:41:36 | AtomicBool | and rustc's IR isnt optimized using -O |
| 16:42:04 | Araq | is --stackTrace:off allowed then? |
| 16:42:29 | EXetoC | dtscode: or something like termbox (nimble package) |
| 16:42:33 | Araq | or how are you gonna compare the quality of stack traces |
| 16:42:49 | def- | If you make a speed comparison, you make sure each participant can get as fast as possible, not as slow as possible |
| 16:42:52 | AtomicBool | wait why do we need stack traces? |
| 16:43:19 | Araq | for debugging convenience? |
| 16:43:37 | AtomicBool | def-, but -O doesnt optimize rustc's IR for the reason that rustc at the moment doesnt spit out good IR, for the priorites that the Rust dev team has rn |
| 16:43:55 | AtomicBool | Sure, we can add --stackTrace:off |
| 16:44:06 | Araq | if you compare debug compile modes, maybe you should start comparing debug experiences? |
| 16:44:34 | def- | AtomicBool: so because rust doesn't optimize well, nim shouldn't be allowed to optimize well either? What? |
| 16:45:01 | AtomicBool | the Original IR isnt ready |
| 16:45:26 | AtomicBool | However, I think now we should include both |
| 16:45:44 | Araq | AtomicBool: I'm not even sure Rust produces poor IR. do you use the most recent version of it? |
| 16:46:12 | def- | yeah, in most benchmarks Rust does quite well |
| 16:46:15 | AtomicBool | Araq, the Ir spit out by rustc is not what its supposed to be |
| 16:46:23 | Araq | according to whom? |
| 16:46:41 | AtomicBool | According to everyone in Rust |
| 16:46:51 | * | EXetoC quit (Quit: WeeChat 1.1.1) |
| 16:47:04 | Araq | I surely hope this has been confirmed by a coredev |
| 16:47:21 | AtomicBool | I can go double check? |
| 16:47:29 | Araq | cause to me that's a statement that would be true 2 years ago |
| 16:47:40 | Araq | *was true |
| 16:48:20 | dtscode | is everything in a seq already initialized to nil? |
| 16:48:28 | Araq | dtscode: yes |
| 16:49:00 | dtscode | Mimbus: let foo = newSeq[char];echo(foo[3]) |
| 16:49:12 | dtscode | .exec let foo = newSeq[char];echo(foo[3]) |
| 16:49:20 | dtscode | Mimbus, let foo = newSeq[char];echo(foo[3]) |
| 16:49:23 | dtscode | grr |
| 16:49:32 | dtscode | mimbus, let foo = newSeq[char];echo(foo[3]) |
| 16:49:42 | Araq | 1. it's newSeq[char]() |
| 16:49:50 | Araq | 2. you will get an out of bounds error |
| 16:49:55 | dtscode | sorry, meant that. and damn |
| 16:49:56 | AtomicBool | Araq, Rust sint as fast as it should be right |
| 16:49:57 | Araq | 3. do that in #nim-offtopic |
| 16:50:03 | dtscode | alright |
| 16:50:11 | AtomicBool | They arent doing anything about rn because of the stabilization of the language |
| 16:50:17 | AtomicBool | since 1.0.0 alpha |
| 16:51:15 | def- | AtomicBool: then wait until rust is fast enough for you and do the comparison with full optimizations then? |
| 16:51:36 | AtomicBool | Thats weeks from now |
| 16:51:51 | BlaXpirit | sigh |
| 16:51:57 | AtomicBool | but I guess its fair :/ |
| 16:52:03 | BlaXpirit | who the hell cares |
| 16:53:34 | Araq | AtomicBool: IMHO you should at *least* use -d:release and -O for the comparison |
| 16:53:56 | Araq | and then you should check what C compiler works best with the C code that Nim produces. |
| 16:54:11 | AtomicBool | Thats nice |
| 16:54:22 | Araq | and that's fair because Nim offers this flexibility |
| 16:54:39 | Araq | so it's unfair to pretend it doesn't exist |
| 16:54:47 | flaviu | .eval echo ".exec doesn't do anything" |
| 16:54:52 | Mimbus | flaviu: .exec doesn't do anything |
| 16:54:55 | AtomicBool | Well I decided that I will, once coreteam focus on rustc's IR |
| 16:56:06 | Araq | in fact, it's easier to test different C compilers with Nim code than with hand written C code |
| 16:56:19 | AtomicBool | Actually im curious |
| 16:56:29 | flaviu | AtomicBool: Microbenchmarks are pointless anyway. Nim and Rust have roughly the same performance. |
| 16:56:35 | AtomicBool | Whats the nim equivalent to this? https://github.com/Ap0ph1s/ProjectEuler/blob/master/src/Problem24.rs |
| 16:58:31 | def- | don't think there's a permutation proc in the stdlib |
| 17:01:53 | BlaXpirit | anyone remade python itertools? |
| 17:02:14 | BlaXpirit | (need to think how much itertools would even make sense in nim) |
| 17:02:28 | * | threewood joined #nim |
| 17:02:31 | def- | BlaXpirit: i only remade sequtils to iterutils: https://github.com/def-/nim-iterutils |
| 17:02:55 | BlaXpirit | "what sequtils should've been" |
| 17:03:13 | BlaXpirit | it is very concerning that we need 2 versions of each function: iterator vs seq |
| 17:03:45 | def- | yes, should be improved |
| 17:03:50 | BlaXpirit | it is also concerning that we need 2 versions of each function: ones that take a proc and ones that are templates on `it` |
| 17:08:50 | def- | BlaXpirit: agreed |
| 17:10:13 | BlaXpirit | in a language like python iterators have a huge overhead, and yet many functions return only iterators |
| 17:11:09 | BlaXpirit | here it is not that big of a deal, and it sure would be awesome to have optimizations that make functions that return iterators have 0 overhead when converted to seq |
| 17:11:44 | BlaXpirit | in fact, it might already as optimal as possible for non-closure iterators |
| 17:11:49 | def- | AtomicBool: apart from implementing nextPermutation it's easy: https://gist.github.com/def-/28574c7d9703eab87ec5 |
| 17:13:12 | def- | Should we put nextPermutation and prevPermutation into algorithm? |
| 17:13:34 | BlaXpirit | looks like a good place |
| 17:13:35 | BlaXpirit | BUT |
| 17:13:44 | BlaXpirit | making "nextPermutation" is suboptimal |
| 17:13:52 | BlaXpirit | iterator is much more efficient |
| 17:14:00 | BlaXpirit | (well, why not both) |
| 17:14:05 | AtomicBool | glad to have inspired |
| 17:14:25 | BlaXpirit | wait, it is not "much" more efficient, if at all :| |
| 17:14:40 | def- | BlaXpirit: well, i have a few implementations of permutations iterators |
| 17:14:42 | AtomicBool | it shorter |
| 17:22:36 | * | mapdog joined #nim |
| 17:23:28 | BlaXpirit | because of abundance of such things, I really fear 1.0 |
| 17:24:08 | BlaXpirit | things like mentioned 20 minutes ago |
| 17:24:34 | def- | BlaXpirit: find ways to fix them and work on it? |
| 17:25:17 | BlaXpirit | it's everywhere in stdlib... |
| 17:25:25 | BlaXpirit | goes down to ideology |
| 17:34:04 | * | mapdog quit (Quit: Page closed) |
| 18:08:43 | * | silven quit (Ping timeout: 245 seconds) |
| 18:10:23 | * | silven joined #nim |
| 18:10:56 | AtomicBool | https://i.imgur.com/ASiD3tH.png |
| 18:11:30 | AtomicBool | thats mem::swap |
| 18:11:53 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 18:13:19 | ekarlso | Araq: how do you think of something like a pkg registry ? |
| 18:24:31 | flaviu | AtomicBool: So what? It looks scary, but it's not nearly as bad as it looks. |
| 18:25:17 | AtomicBool | It's what I mean by how we still need to improve |
| 18:27:54 | * | EXetoC joined #nim |
| 18:28:30 | flaviu | AtomicBool: If you look carefully, you'd see that it does only what is necessary. It doesn't do any extra work. |
| 18:28:32 | * | jsudlow quit (Remote host closed the connection) |
| 18:29:05 | AtomicBool | It's still atrocious |
| 18:29:14 | AtomicBool | And that's only men::swap |
| 18:29:21 | AtomicBool | Mem |
| 18:31:44 | flaviu | It isn't "just" mem::swap. It's mem::swap<Option<Result<(), Box<Any + Send>>> |
| 18:32:26 | ekarlso | rust in here now ? :p |
| 18:34:23 | flaviu | Nah, just trying to show him that "It looks complicated" != "It is complicated" |
| 18:34:51 | ekarlso | ah |
| 18:36:46 | * | jasondotstar quit (Read error: Connection reset by peer) |
| 18:37:07 | * | d3m1gd joined #nim |
| 18:37:19 | * | jasondotstar joined #nim |
| 18:38:39 | d3m1gd | anyone experimented with real life compilation to js? how do one access window.* and document.* if those are seen by compiler as undefined? |
| 18:38:39 | * | flaviu quit (Read error: Connection reset by peer) |
| 18:38:39 | * | Mimbus quit (Read error: Connection reset by peer) |
| 18:39:51 | * | flaviu joined #nim |
| 18:41:50 | * | BlaXpirit quit (Remote host closed the connection) |
| 18:43:06 | vendethiel | I'm not completly finished reading the manual, but I don't think I've seen it, so I'll ask: is there a way to turn an operator into a (possibly curried) function? |
| 18:43:21 | vendethiel | like (+) to get a arity=2 function (that adds both arguments) |
| 18:43:32 | flaviu | `+` |
| 18:43:51 | * | Mimbus joined #nim |
| 18:44:21 | vendethiel | flaviu: ooh, thanks! |
| 18:44:34 | * | Mimbus quit (Excess Flood) |
| 18:44:41 | * | Mimbus joined #nim |
| 18:47:37 | vendethiel | are "destroy", "deepCopy", etc, procs always exported? |
| 18:47:43 | def- | d3m1gd: Didn't experiment much: http://hookrace.net/blog/what-is-special-about-nim/#compile-to-javascript |
| 18:48:04 | vendethiel | i.e. if I export a type but not the "destroy", what happens? |
| 18:51:40 | d3m1gd | def-: import dom, that's it. Sorry for being so blind, it is mentioned in the docs |
| 18:55:05 | * | BlaXpirit joined #nim |
| 19:01:17 | * | jsudlow joined #nim |
| 19:03:18 | * | mapdog joined #nim |
| 19:06:38 | AtomicBool | Not that's its complicated,it's not optimizrd |
| 19:09:58 | dom96 | AtomicBool: You should really listen to what people are telling you here. You said yourself that you are 16 and you are not yet experienced. |
| 19:13:11 | * | alexruf joined #nim |
| 19:15:12 | Araq | vendethiel: they are bound to the *type*, that doesn't mean they are visible |
| 19:15:41 | Araq | but there is no way to get around them, the compiler knows about them and ensures they end up being called |
| 19:17:02 | Araq | ekarlso: I have no opinion on a package registry. dom96 is the guy to ask. |
| 19:18:55 | vendethiel | Araq: that makes sense, thanks |
| 19:19:34 | ekarlso | dom96: should search support both tags || name at once ? |
| 19:20:41 | * | kuzy000_ quit (Ping timeout: 250 seconds) |
| 19:21:10 | * | kuzy000 joined #nim |
| 19:24:01 | Araq | ekarlso: yes, search usually should be smart |
| 19:24:27 | Araq | nobody wants to stop and think "err, am I searching names or tags or ...?" |
| 19:24:47 | flaviu | ekarlso: See how stackoverflow does tag search. |
| 19:25:01 | Araq | please think about the users who also have real work to do ;-) |
| 19:27:12 | AtomicBool | Idk what I'm saying wrong |
| 19:27:58 | * | VinceAddons quit (Quit: Leaving) |
| 19:29:27 | flaviu | AtomicBool: I've blocked out all the noops: http://i.imgur.com/ADO1xnd.png |
| 19:34:19 | * | dumdum joined #nim |
| 19:36:32 | AtomicBool | flaviu: I'm saying its not optimized, nothing more |
| 19:38:18 | Araq | BlaXpirit: I don't see the problem. this is just "the perfect is the enemy of the good" idea at work |
| 19:39:23 | Araq | the alternative would be to have no useful stdlib at all until everything that the language offers is perfect |
| 19:39:55 | Araq | that doesn't even work for when you have as much resources as Microsoft |
| 19:40:18 | * | Jesin quit (Quit: Leaving) |
| 19:44:45 | Araq | also note that the "everything has to be lazy" idea can also be implemented via "use 'seq' freely and implement a deforastation pass in the compiler instead" |
| 19:46:00 | flaviu | Araq: But that doesn't work if I use my own sequence type. |
| 19:49:31 | Araq | that's a fair point, but then you end up designing the whole language and stdlib for the rare edge cases |
| 19:50:12 | * | d3m1gd quit (Ping timeout: 252 seconds) |
| 19:50:41 | Araq | and at the end you still get incompatibilities in the form of std::vector vs wxWidgets::vector. hurray. |
| 19:51:30 | flaviu | which is what typeclasses are for! |
| 19:52:16 | Araq | yes. so every single proc ends up being generic. that's what Clay did. |
| 19:53:57 | flaviu | Clay is actually quite nice. |
| 19:57:35 | Araq | yeah but it's not yet clear to me that the excessive generics everywhere are actually better than what you get with Luajit |
| 19:57:50 | * | alexruf quit (Quit: Textual IRC Client: www.textualapp.com) |
| 19:59:54 | flaviu | I'm not sure what luajit has to do with anything. |
| 20:00:54 | Araq | clay's problem was excessive binary sizes |
| 20:01:16 | ldlework | I'm surprised that binary size is even a consideration these days |
| 20:01:20 | * | jsudlow quit (Quit: Leaving) |
| 20:02:16 | ldlework | Seeing as how there is a significant movement to ship all software with an accompanying environment (Docker, et al) |
| 20:03:11 | Araq | when I spoke with Clay's lead developer he told me to not repeat Clay's mistake, but hey, what do I know. |
| 20:04:29 | flaviu | In some cases, Java-style generics are desirable, and in others C++-style generics are desirable. |
| 20:05:24 | Araq | no, Luajit's technology to deal with this mess is desirable ;-) |
| 20:06:48 | Araq | but Mike Pall is not in IRC, so I can't convince him to join Nim dev and so we're stuck with generating C |
| 20:07:37 | flaviu | I don't understand what you're saying about luajit. Do you have a link or something I can google? |
| 20:09:44 | Araq | no, but I mean that it does specialization at runtime when it's necessary and that seems to me the best thing. as then you have no inherent compile-time specialization vs code size tradeoff to make |
| 20:10:31 | Araq | well the tradeoff is still there at runtime |
| 20:10:44 | Araq | but library development is so much easier as a result |
| 20:12:19 | Araq | There is an inherent Stream vs generic iterator/type classes/whatever design tradeoff. |
| 20:12:40 | ekarlso | dom96: any clue on why I get illegal storage access when doing some query parameters ? |
| 20:12:55 | flaviu | ekarlso: Because you have something nil. |
| 20:13:20 | Araq | this tradeoff exists in C++, D, Nim and afaict in Rust too. |
| 20:14:00 | Araq | but I think you can get rid of it with JIT technology. |
| 20:14:35 | flaviu | But JIT really makes native interop and cross-platformness more difficult. |
| 20:15:25 | ekarlso | flaviu: nah, because jester logs doesn't even log the GET |
| 20:15:27 | ekarlso | http --verify no "https://nim-pkg.svcs.io/packages?name=nre&name=asdadasd" |
| 20:15:53 | ekarlso | http --verify no "https://nim-pkg.svcs.io/packages?name=nre&tag=asdadasd" as well |
| 20:15:58 | ekarlso | makes it go boom |
| 20:16:03 | flaviu | ekarlso: gdb! |
| 20:16:16 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:16:16 | flaviu | --linedir:on --debuginfo and then open it up in gdb |
| 20:16:42 | ekarlso | person that makes me a better way of writing queries |
| 20:16:45 | ekarlso | will get a beer :| |
| 20:17:45 | flaviu | https://www.sqlite.org/docs.html |
| 20:18:02 | ekarlso | flaviu: yeah, but mapping query strings to stuff atm is meh |
| 20:18:15 | flaviu | http://sqlitestudio.pl/ is also incredibly useful. |
| 20:18:39 | ekarlso | flaviu: I meant mapping nim code to sql :p |
| 20:18:46 | ekarlso | a'la sqlalchemy core in python |
| 20:18:54 | * | dc0d joined #nim |
| 20:19:37 | * | jsudlow joined #nim |
| 20:19:43 | * | jsudlow__ joined #nim |
| 20:19:52 | * | jsudlow__ quit (Remote host closed the connection) |
| 20:20:16 | def- | Araq: can't convice Mike Pall by mail? |
| 20:21:29 | ekarlso | flaviu: how do you run gdb then and pass args to the program ? |
| 20:22:11 | flaviu | gdb myprogram, and when you're in the shell, `run --ihave=many --opts` |
| 20:22:39 | * | Demon_Fox joined #nim |
| 20:23:01 | * | dc0d quit (Ping timeout: 246 seconds) |
| 20:26:34 | ekarlso | flaviu: what to look for when it borks? |
| 20:26:38 | ekarlso | or do |
| 20:27:21 | flaviu | print stuff |
| 20:27:21 | flaviu | https://gist.github.com/flaviut/487be89b8abfae2612e8 |
| 20:28:12 | ekarlso | gawd |
| 20:28:15 | ekarlso | too man variables there |
| 20:28:52 | * | davidhq joined #nim |
| 20:29:29 | ekarlso | meh, flaviu any ideas ? :p |
| 20:29:44 | flaviu | i lo |
| 20:29:57 | Araq | def-: maybe I should try. |
| 20:30:30 | ekarlso | flaviu: sorry ? |
| 20:30:42 | flaviu | type `i lo` |
| 20:31:15 | ekarlso | https://bpaste.net/show/b1066c6ff416 |
| 20:32:22 | reactormonk | Araq, how do I test warnings with the tester? |
| 20:32:43 | flaviu | ekarlso: The line that gdb stopped on probably can give you clues about which variables you care about. `print *foo` will derefrence foo and print it. |
| 20:33:52 | Araq | ekarlso: your 'result' var is borked |
| 20:34:09 | * | bjz joined #nim |
| 20:34:47 | * | mapdog quit (Quit: Page closed) |
| 20:35:36 | Araq | reactormonk: msg: "compiler message" |
| 20:35:41 | Araq | line: 24 |
| 20:35:43 | reactormonk | ok |
| 20:35:44 | Araq | iirc |
| 20:36:56 | * | Sornaensis quit (Excess Flood) |
| 20:37:41 | * | Sornaensis joined #nim |
| 20:39:38 | AtomicBool | Whats a trade-off in Rust? |
| 20:40:49 | * | jsudlow quit (Quit: Leaving) |
| 20:42:15 | ekarlso | Araq ... but which one |
| 20:42:37 | Araq | bt gives you a stack trace |
| 20:43:49 | flaviu | ekarlso: print out http://www.cs.berkeley.edu/~mavam/teaching/cs161-sp11/gdb-refcard.pdf and keep it next to your computer. |
| 20:43:52 | ekarlso | hmmms |
| 20:44:04 | ekarlso | seems like a jester bug |
| 20:44:07 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:44:51 | ekarlso | https://bpaste.net/show/dcdbf12f0084 |
| 20:52:54 | * | bjz joined #nim |
| 20:52:56 | Araq | ekarlso: there is still a codegen bug that is affecting jester and this surely looks familiar. sorry. |
| 20:53:07 | Araq | let me fix it asap |
| 20:54:50 | * | bjz quit (Client Quit) |
| 20:57:24 | dumdum | this: http://pastebin.com/ZM5w3EHG causes compiler check to never end though it reports 'Error: recursive dependency: 'items' |
| 20:59:02 | * | Jesin joined #nim |
| 21:02:06 | Araq | dumdum: what about a real bug report? |
| 21:07:10 | * | dc0d joined #nim |
| 21:07:31 | dumdum | ook |
| 21:07:39 | dumdum | #2051 |
| 21:08:32 | * | dc0d quit (Client Quit) |
| 21:08:39 | * | BitPuffin joined #nim |
| 21:09:25 | * | jsudlow joined #nim |
| 21:10:41 | * | bjz joined #nim |
| 21:12:31 | * | gokr_ joined #nim |
| 21:14:45 | * | superfunc[mobile joined #nim |
| 21:17:40 | superfunc[mobile | Not sure if anyone has experience with bsd here, but I'm having trouble building Nim on it. Seems to be from a use of u_int32_t in the system header netinet/in.h |
| 21:17:50 | def- | superfunc[mobile: freebsd? |
| 21:18:01 | superfunc[mobile | Yeah |
| 21:18:02 | def- | we recently had a fix for freebsd building |
| 21:18:07 | def- | wtw should now |
| 21:18:36 | def- | https://github.com/Araq/Nim/pull/2010 |
| 21:18:49 | * | d3m1gd joined #nim |
| 21:20:39 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:20:59 | * | bjz joined #nim |
| 21:22:07 | def- | superfunc[mobile: but apart from that it built |
| 21:24:58 | * | gokr_ quit (Ping timeout: 245 seconds) |
| 21:25:37 | * | bjz quit (Ping timeout: 264 seconds) |
| 21:26:41 | * | gokr_ joined #nim |
| 21:31:19 | * | dumdum quit (Ping timeout: 256 seconds) |
| 21:34:49 | wtw | superfunc[mobile: what problem did you have exactly? |
| 21:40:53 | * | kuzy000 quit (Ping timeout: 240 seconds) |
| 21:42:30 | superfunc[mobile | http://imgur.com/Glaj6FC |
| 21:42:42 | def- | superfunc[mobile: not loading |
| 21:42:48 | superfunc[mobile | Err, one src |
| 21:43:11 | superfunc[mobile | http://m.imgur.com/GIaj6FC |
| 21:43:23 | superfunc[mobile | The I looked like an L to me |
| 21:43:43 | def- | good that the nim compiler warns about using a lowercase l |
| 21:43:53 | superfunc[mobile | Hell yea |
| 21:45:20 | def- | u_int32_t is bsd specific, shouldn't it be uint32_t? |
| 21:45:53 | EXetoC | I think so |
| 21:46:24 | wtw | this stuff is usually defined in /usr/include/sys/types.h |
| 21:46:51 | wtw | as a workaround something like #define uint32_t u_int32_t would do |
| 21:47:39 | flaviu | superfunc[mobile: http://i.imgur.com/XBFaSfN.png?1 |
| 21:48:07 | flaviu | DejaVu Sans Mono |
| 21:48:57 | EXetoC | wtw: stdint.h? |
| 21:50:23 | wtw | my stdint.h includes <sys/_types.h> which contains __uint32_t but not u_int32_t |
| 21:51:14 | wtw | afaik this u_int_bla things are also deprecated |
| 21:51:17 | d3m1gd | i want to use console.log on js target, so i put this in my dom.nim: log*: proc (item: ref RootObj) {.nimcall, varargs.} |
| 21:51:27 | d3m1gd | it works for ref TNode for example |
| 21:51:37 | wtw | ah yes: typedef __uint8_t u_int8_t; /* unsigned integrals (deprecated) */ |
| 21:51:48 | d3m1gd | but not for strings. how to make it work for any object? |
| 21:53:19 | wtw | bbl |
| 21:53:27 | EXetoC | does the dom stuff even work? |
| 21:54:34 | EXetoC | there was something that I just couldn't figure out, and then I was told that it was unfinished, though that was a couple of months ago |
| 21:55:10 | d3m1gd | it works, but not unfinished, yes. Trivial to extend though |
| 21:55:18 | d3m1gd | but unfinished* |
| 21:56:19 | d3m1gd | apart from the stuff that some functions can take any javascript object, so need some way to express it in nim |
| 21:56:42 | * | kniteli joined #nim |
| 21:57:28 | superfunc[mobile | That fixed it, thanks everyone |
| 21:57:32 | superfunc[mobile | Though, we may want to make note of a fix on the nim end, rather than the bsd end |
| 21:58:32 | Varriount | Meep |
| 21:58:38 | dom96 | hello |
| 21:58:47 | EXetoC | d3m1gd: what works? I can't even use the global vars |
| 21:59:09 | EXetoC | to set the background color for example |
| 21:59:29 | superfunc[mobile | Sup Dom |
| 22:00:05 | dom96 | New term of uni starting soon, apart from that not much. What's up with you? |
| 22:00:06 | d3m1gd | EXetoC: document.getElements* works with 'document' being global. |
| 22:00:21 | d3m1gd | EXetoC: what exactly you want to set color of? |
| 22:01:00 | EXetoC | d3m1gd: document.bgColor = ... just as a test |
| 22:01:38 | EXetoC | I'll mess around with those functions |
| 22:01:44 | d3m1gd | EXetoC: ok, will make some tests |
| 22:03:50 | EXetoC | d3m1gd: oops, I did "nim js -r ..." |
| 22:04:04 | d3m1gd | EXetoC: yup, works. Can set attributes. bgColor has put bgcolor on body for me |
| 22:04:51 | EXetoC | so the actual problem before was the fact that everything would blow up as soon as an exception was raised |
| 22:05:08 | * | Demos joined #nim |
| 22:05:12 | d3m1gd | oh, didnt cross that yet |
| 22:05:27 | EXetoC | d3m1gd: yes, it was "-r" that caused the problem. gotta have access to the dom, of course |
| 22:07:00 | d3m1gd | EXetoC: what does -r do exactly? it is not on help page of compiler |
| 22:07:42 | EXetoC | d3m1gd: it runs the program after compiling |
| 22:08:17 | d3m1gd | and i still have no idea how to tell proc to take anything as an argument for console.log |
| 22:08:26 | d3m1gd | EXetoC: oooh, yup =) |
| 22:09:40 | EXetoC | d3m1gd: echo? |
| 22:10:17 | EXetoC | yes |
| 22:10:32 | d3m1gd | EXetoC: well, echo append elements to body, and i think in string form, which is not satisfactory |
| 22:11:28 | d3m1gd | EXetoC: with proper conrole.log you can debug node elements and all kind of stuff only with log, as is does not make everything to string, but keeps objects as objects |
| 22:11:32 | EXetoC | but the generated source just invokes console.log |
| 22:12:03 | d3m1gd | but it does not compile with console.log("hello"), as "hello" is a string |
| 22:12:35 | d3m1gd | log*: proc (item: string) would fix it, but want the refs too. |
| 22:12:50 | EXetoC | what do you mean? rawEcho(cstrToNimstr("test")); |
| 22:13:02 | d3m1gd | actually want compiler to forget about types at all for this exact proc |
| 22:13:09 | EXetoC | ok |
| 22:13:35 | EXetoC | var buf = ""; yeah that's not very useful |
| 22:22:52 | d3m1gd | it turns out i overlooked jssys.nim in system, which deals with console.log. Included it and get a compilation error: lib/nim/system/jssys.nim(102, 3) Error: undeclared identifier: 'name=' |
| 22:29:01 | d3m1gd | ok, it is way easier than i expected. Wrap calls to console.log in asm""" """ and it is all good! thats why reading sources is good ^__^ |
| 22:30:33 | superfunc[mobile | dom96: mostly research stuff keeping me busy |
| 22:35:02 | * | milosn quit (Ping timeout: 272 seconds) |
| 22:35:57 | * | milosn joined #nim |
| 22:39:30 | wtw | superfunc[mobile: what did you do in the end? |
| 22:40:23 | superfunc[mobile | Added the define to the file |
| 22:40:40 | wtw | ok |
| 22:41:01 | * | milosn quit (Ping timeout: 256 seconds) |
| 22:41:14 | wtw | as this is deprecated I'm not sure if we should bother changing something in nim |
| 22:41:36 | wtw | ok, although deprecated it's used within some bsd headers... |
| 22:42:07 | superfunc[mobile | Yeah it's in the most recent rc |
| 22:42:59 | wtw | I'm still not very familiar how things are done in nim, afaik there is a linux-specific file, perhaps a bsd-specific one could contain fixups of this kind |
| 22:43:50 | * | AtomicBool left #nim (#nim) |
| 22:44:06 | wtw | or it could be done only for the bsd port, keeping the platform-specific things at a minimum |
| 22:44:59 | wtw | well, we'll find a way ;) |
| 22:46:55 | * | DemonOne joined #nim |
| 22:48:04 | * | milosn joined #nim |
| 22:55:40 | * | ehaliewicz joined #nim |
| 23:14:54 | reactormonk | Araq, nope, "msg" isn't checked |
| 23:26:49 | * | sillesta quit (Ping timeout: 264 seconds) |
| 23:28:19 | superfunc[mobile | wtw: we could possibly have build sh fix it in csources? |
| 23:29:26 | * | gokr quit (Quit: Leaving.) |
| 23:37:54 | * | pafmaf quit (Quit: Verlassend) |
| 23:46:25 | gmpreussner|work | dom96: what's the preferred versioning scheme for nimble packages that contain bindings to third party libs? should we use our own versioning, or should we match the version of the libs? |
| 23:47:09 | dom96 | gmpreussner|work: That's up to you to decide. |
| 23:47:13 | BlaXpirit | gmpreussner|work, i'd say this is not specific to nim :| |
| 23:47:18 | dom96 | We don't really have a preference |
| 23:47:38 | gmpreussner|work | ok |
| 23:53:14 | reactormonk | dom96, how about two version numbers? ^^ |
