00:00:16 | * | couven92 joined #nim |
00:07:43 | * | libman joined #nim |
00:17:39 | * | arnetheduck quit (Ping timeout: 248 seconds) |
00:19:46 | * | def-pri-pub joined #nim |
00:19:46 | * | def-pri-pub quit (Changing host) |
00:19:46 | * | def-pri-pub joined #nim |
00:21:02 | FromGitter | <timeyyy> I got mixed up with ada an apl but I will post this anyway |
00:22:00 | FromGitter | <timeyyy> https://youtu.be/a9xAKttWgP4 |
00:27:32 | PMunch | Hmm, something is wrong with my macro but I'm not quite sure what.. |
00:27:34 | PMunch | http://ix.io/1RxP |
00:27:41 | PMunch | wxuimacro.nim(15, 13) Error: attempting to call undeclared routine: 'widget=' |
00:28:00 | * | Kingsquee joined #nim |
00:28:16 | PMunch | It seems to think that result.widget = <object creation call> is a routine call.. |
00:29:25 | zachcarter | okay so I hardcoded an identity matrix in my shader and I see my image, which means my uniform isn’t being passed correctly to my shader, grrr |
00:29:28 | zachcarter | glm is failing me hard |
01:31:42 | * | libman quit (Ping timeout: 240 seconds) |
01:34:16 | * | libman joined #nim |
01:46:44 | PMunch | Hmm, I want to create a macro that can basically turn the comment in this code into the code |
01:46:45 | PMunch | http://ix.io/1Rya |
01:47:14 | PMunch | Not quite sure about the let statements, they would probably be better off as table assignments or something. |
01:47:30 | PMunch | But I'm having a hard time with macros.. |
01:47:48 | * | gokr quit (Quit: Leaving.) |
01:48:33 | PMunch | But I can't help of thinking this should be simple |
01:50:34 | PMunch | Basically all objects have their parameters in parenthesis (apart from id which defaults to wxID_ANY). A single string parameter is treated as a label argument. And if you are the direct descendent of a sizer then you can specify arguments to the add function with square brackets. |
01:53:37 | * | Snircle_ joined #nim |
01:54:03 | * | Snircle quit (Ping timeout: 255 seconds) |
02:04:35 | * | chemist69 quit (Ping timeout: 264 seconds) |
02:18:15 | * | chemist69 joined #nim |
02:21:05 | * | jinshil joined #nim |
02:25:59 | * | devted quit (Quit: Sleeping.) |
02:29:18 | * | PMunch quit (Quit: leaving) |
02:49:51 | * | yglukhov joined #nim |
02:53:23 | * | libman quit (Ping timeout: 248 seconds) |
02:54:06 | * | yglukhov quit (Ping timeout: 240 seconds) |
02:58:26 | * | libman joined #nim |
03:00:32 | * | couven92 quit (Read error: Connection reset by peer) |
03:01:09 | * | brson quit (Quit: leaving) |
03:02:18 | FromGitter | <martinium> is there a way to restart a program after it finishes with async? |
03:02:27 | * | chemist69 quit (Ping timeout: 255 seconds) |
03:03:00 | FromGitter | <martinium> runForever() is keeping the program open but not starting it over |
03:16:57 | * | chemist69 joined #nim |
03:33:47 | demi- | hmmm, so I have a nim package i am working on that has multiple files in it to break up the code in a more organized manner. when i run "nimble build" I get an error that says that nimble found a source file that is named "afoo.nim" instead of "foo.nim" -- I do have a "foo.nim" in the source directory i specified in the .nimble file. what is the strategy for having multiple nim sources in a single package? |
03:39:39 | def-pri-pub | For the JS target, are there any nice cookie setting libraries out there? |
04:05:17 | * | libman2 joined #nim |
04:07:41 | * | libman quit (Ping timeout: 240 seconds) |
05:19:19 | * | huonw joined #nim |
05:21:02 | * | pregressive quit (Remote host closed the connection) |
05:21:36 | * | pregressive joined #nim |
05:25:41 | * | pregressive quit (Ping timeout: 240 seconds) |
05:31:51 | * | libman2 quit (Ping timeout: 255 seconds) |
05:39:03 | * | def-pri-pub quit (Quit: Lost terminal) |
05:55:33 | * | chemist69 quit (Ping timeout: 276 seconds) |
05:57:37 | * | chemist69 joined #nim |
06:25:50 | * | bjz joined #nim |
06:35:18 | * | nsf joined #nim |
06:36:41 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
06:51:56 | * | rokups joined #nim |
07:18:31 | * | vendethiel quit (Quit: q+) |
07:18:57 | * | Guest89004 joined #nim |
07:23:37 | * | ftsf_ quit (Quit: :q!) |
07:52:02 | * | Vladar joined #nim |
08:16:43 | * | yglukhov joined #nim |
08:20:43 | * | Arrrr joined #nim |
08:20:43 | * | Arrrr quit (Changing host) |
08:20:43 | * | Arrrr joined #nim |
08:20:57 | * | yglukhov quit (Ping timeout: 252 seconds) |
08:26:01 | * | yglukhov joined #nim |
08:37:29 | * | gokr joined #nim |
08:38:46 | * | yglukhov quit (Remote host closed the connection) |
08:52:14 | * | arnetheduck joined #nim |
08:57:57 | * | yglukhov joined #nim |
09:00:58 | * | yglukhov quit (Remote host closed the connection) |
09:01:13 | * | yglukhov joined #nim |
09:11:11 | euantor | demi-: It's explained here: https://github.com/nim-lang/nimble#libraries |
09:11:15 | euantor | See the fourth paragraph |
09:12:07 | euantor | Basically, a structure like this (assuming the package is called `foo`): https://www.irccloud.com/pastebin/xaIaBH2Q/ |
09:13:22 | * | jinshil quit (Quit: Good-bye!) |
09:18:14 | euantor | Though for binary packages, the folder should be named `foopkg` or something as otherwise you can have a binary and a folder called `foo` (in theory, but the OS wouldn't let you as `foo` would already exist) |
09:19:29 | Arrrr | Did you actually mean "you can't" ? |
09:26:36 | * | yglukhov quit (Remote host closed the connection) |
09:29:03 | * | yglukhov joined #nim |
09:30:23 | euantor | yeah, doh! |
09:33:59 | chemist69 | After latest pull, my Nim fails to build koch (`bin/nim c koch`)! |
09:34:32 | chemist69 | undefined reference to `dlclose', etc... |
09:34:41 | * | gokr quit (Ping timeout: 240 seconds) |
09:34:50 | chemist69 | on Ubuntu 16.04 |
09:34:51 | * | yglukhov quit (Read error: Connection reset by peer) |
09:35:00 | chemist69 | *16.10 |
09:35:05 | * | yglukhov joined #nim |
09:35:19 | * | BluntObject quit (Quit: Lost terminal) |
09:36:18 | Arrrr | 32 or 64 bits |
09:36:40 | Arrrr | Why can't you have a foo.exe and a foo.nim ? |
09:38:39 | * | couven92 joined #nim |
09:41:12 | * | Andris_zbx joined #nim |
09:46:11 | chemist69 | fails even after rebuilding from csources... |
09:49:05 | FromGitter | <andreaferretti> @chemist69 the same is happening to me when doing`koch tools` (nimsuggest is ok but it breaks building nimgrep) |
09:49:36 | Araq | chemist69: due to my changed config? |
09:49:42 | * | yglukhov quit (Read error: Connection reset by peer) |
09:49:58 | Araq | I changed config/nim.cfg |
09:50:14 | Araq | please revert it and see if it makes a difference |
09:50:14 | * | yglukhov joined #nim |
09:53:54 | * | gokr joined #nim |
09:53:58 | * | yglukhov quit (Remote host closed the connection) |
09:54:33 | * | yglukhov joined #nim |
09:57:29 | * | yglukhov quit (Remote host closed the connection) |
09:57:46 | * | yglukhov joined #nim |
09:58:39 | euantor | Arrrr: You can have `foo.exe` and `foo.nim` |
09:58:49 | euantor | What you can't have is a `foo` directory and a `foo` binary |
09:59:07 | euantor | As binaries on unix don't have an extension |
10:05:43 | chemist69 | Araq: sorry, it took me a while. I don't do these things too often with git. |
10:06:13 | chemist69 | But yes, after reverting config/nim.cfg koch builds again on Ubuntu 16.10 64bit. |
10:06:31 | Araq | can you create a PR please for this? I'm busy |
10:06:55 | * | yeeve quit (Remote host closed the connection) |
10:07:44 | * | filcuc joined #nim |
10:11:58 | * | yeeve joined #nim |
10:12:29 | chemist69 | done. |
10:13:07 | * | yglukhov quit (Remote host closed the connection) |
10:13:41 | Araq | thanks, would be interesting to know how -m32/64 broke anything though |
10:15:02 | chemist69 | that you definitely have to ask someone else.. :P |
10:17:00 | chemist69 | "I'm sorry. My responses are limited. You must ask the right questions." |
10:17:24 | chemist69 | great film |
10:24:43 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
10:33:02 | * | yglukhov joined #nim |
10:46:28 | * | bjz joined #nim |
10:48:08 | * | gokr quit (Ping timeout: 256 seconds) |
10:52:19 | * | gokr joined #nim |
10:59:42 | * | peted joined #nim |
11:03:47 | * | PMunch joined #nim |
11:08:26 | * | yglukhov quit (Remote host closed the connection) |
11:10:51 | * | yglukhov joined #nim |
11:13:05 | federico3 | relevant for Nim? https://shuttleworthfoundation.org/apply/ |
11:22:57 | Araq | maybe |
11:50:58 | * | bjz_ joined #nim |
11:51:32 | * | bjz quit (Ping timeout: 245 seconds) |
11:55:40 | * | vlad1777d joined #nim |
12:04:20 | * | yglukhov quit (Remote host closed the connection) |
12:05:20 | * | yglukhov joined #nim |
12:15:41 | * | Snircle_ quit (Quit: Textual IRC Client: www.textualapp.com) |
12:16:11 | * | Snircle joined #nim |
12:39:11 | * | bjz joined #nim |
12:39:20 | * | bjz_ quit (Ping timeout: 255 seconds) |
12:40:40 | * | yglukhov quit (Remote host closed the connection) |
12:47:42 | * | ofelas quit (Ping timeout: 252 seconds) |
12:53:04 | * | zachcarter quit (Quit: zachcarter) |
13:02:13 | * | yglukhov joined #nim |
13:18:10 | ftsf | where are the options for --os: defined? |
13:18:25 | demi- | euantor: ah, thanks for the explanation! |
13:18:40 | ftsf | is that a nim thing? or is it passed to the compiler directly? |
13:18:47 | ftsf | (c compiler i mean) |
13:19:46 | flyx | ftsf: https://nim-lang.org/docs/nimc.html#cross-compilation |
13:19:59 | flyx | it's a Nim thing |
13:21:51 | ftsf | mmm, is there a way to specify "no os" ? wanting to try building for something that's going to run on arm bare metal |
13:23:05 | flyx | ftsf: what are you expecting to happen by specifying „no os“? |
13:23:39 | ftsf | flyx, well i know it doesn't work, but i'm curious what i should specify, and what that option is used for? |
13:24:36 | ftsf | i'm using arm-none-eabi-gcc as the c compiler |
13:25:01 | flyx | I believe it defines compile-time variables used like `when defined(posix)` and so on |
13:25:36 | flyx | there are quite some in the stdlib, so basically it means that you will not be able to use anything in the stdlib which has these sections |
13:25:50 | ftsf | I see, so if I disable stdlib it might work |
13:26:00 | flyx | you would still need a libc |
13:28:24 | * | rupil joined #nim |
13:30:50 | ftsf | using os:linux has some progress but fails on sys/mman.h guess it's missing memory mapped files support |
13:32:42 | ftsf | wondering if there's more lightweight os options |
13:33:21 | ftsf | ahh standalone |
13:42:35 | * | yglukhov quit (Remote host closed the connection) |
13:45:39 | * | Arrrr quit (Ping timeout: 248 seconds) |
13:46:25 | * | zachcarter joined #nim |
13:47:20 | * | bungoman_ joined #nim |
13:49:59 | * | bungoman quit (Ping timeout: 255 seconds) |
13:50:02 | ftsf | progress... maybe |
13:50:22 | ftsf | lib/system.nim(2539, 16) Error: undeclared identifier: 'rawoutput' |
13:55:07 | * | yglukhov joined #nim |
13:55:49 | Araq | ftsf: you need a override |
13:56:15 | ftsf | the panicoverride? i'm trying to make that at the moment |
13:56:22 | Araq | look at tests/manyloc/standalone |
13:56:39 | Araq | you can pretty much copy it from there I think |
13:57:34 | ftsf | closer! lib/system/alloc.nim(327, 13) Error: undeclared identifier: 'stdout' |
13:58:50 | Araq | ah, disable writeFreeList() |
13:59:04 | Araq | it's only used for debugging |
13:59:21 | Araq | or use --deadCodeElim:on |
14:00:08 | Araq | that is what the standalone test case uses too. maybe you should read it |
14:00:33 | ftsf | using deadCodeElim already, will have a look at the tests |
14:00:49 | ftsf | thanks |
14:01:39 | * | nsf quit (Quit: WeeChat 1.7) |
14:02:26 | * | Arrrr joined #nim |
14:02:26 | * | Arrrr quit (Changing host) |
14:02:26 | * | Arrrr joined #nim |
14:09:16 | FromGitter | <Varriount> Araq: Would it be possible for os:standalone to throw a more informative error message when panic override is missing |
14:09:27 | FromGitter | <Varriount> ? |
14:11:36 | Araq | sure but it's for power users. |
14:12:07 | Araq | sometimes we excpect power users to read the documentation :P |
14:12:50 | Araq | or to be able to use 'nimgrep rawoutput --recursive --ext:nim . |
14:14:14 | * | Arrrr quit (Read error: Connection reset by peer) |
14:15:27 | ftsf | got panicoverride compiled \o/ but now it's trying to link with nonexistent -ldl |
14:15:38 | ftsf | can i tell nim to not bother with -ldl? |
14:15:48 | Araq | yes. fix the config |
14:17:26 | * | yglukhov quit (Remote host closed the connection) |
14:18:30 | ftsf | more useful info? tried setting passL to " " but it still appends -ldl and nothing else in my config is adding -ldl |
14:19:48 | Araq | @if unix: |
14:19:50 | Araq | @if not bsd or haiku: |
14:19:51 | Araq | # -fopenmp |
14:19:53 | Araq | gcc.options.linker = "-ldl" |
14:19:54 | Araq | gcc.cpp.options.linker = "-ldl" |
14:19:56 | Araq | clang.options.linker = "-ldl" |
14:19:57 | Araq | clang.cpp.options.linker = "-ldl" |
14:19:59 | Araq | tcc.options.linker = "-ldl" |
14:20:00 | Araq | @end |
14:20:02 | Araq | is part of my config/nim.cfg |
14:20:05 | Araq | maybe it's also part of yours? |
14:20:27 | * | leru joined #nim |
14:20:34 | Araq | also wow, we really have haiku specific stuff in there |
14:20:51 | ftsf | ahh, i didn't realise there was a default nim.cfg that my own config only modified, thanks. |
14:24:15 | leru | hi, i have a fresh nim install which doesn't work. error message: http://pastebin.com/0aqY0rnu |
14:25:18 | Araq | error: size of array 'Nim_and_C_compiler_disagree_on_target_architecture' is negative |
14:25:38 | Araq | what do you think this means? |
14:27:05 | leru | i understand what it means, but i have no idea, how to fix it. |
14:27:14 | FromGitter | <Varriount> leru: As the error says, your Nim compiler is targeting one architecture, while the backend C compiler is targeting another. Which MinGW did you download, and what Nim did you download (x64 or x86/32)? |
14:28:08 | * | xet7 joined #nim |
14:29:05 | FromGitter | <Varriount> If you downloaded a 64-bit Nim compiler, the MinGW compiler should be of a variant that outputs 64-bit binaries by default. Same for 32 bit. |
14:30:41 | FromGitter | <Varriount> Araq: How hard would it be for the Nim compiler to detect the output architecture? I'm assuming it would be fairly easy to implement, and would just involve running some stock commands for each type of compiler to retrieve the default target. |
14:31:33 | Araq | varriount, it's an ongoing pita, check tools/finish.nim if you don't believe me |
14:31:37 | leru | Alright, I thought there was a secret config or something |
14:32:44 | FromGitter | <Varriount> leru: Well, if you have a x64 Nim compiler, I believe you can set the configuration for the Nim compiler to target x86, but that won't work the other way around. |
14:33:31 | FromGitter | <Varriount> In other news, lets see what the first hacker news comments is on a nice article on C's setenv. |
14:33:34 | FromGitter | <Varriount> https://news.ycombinator.com/item?id=13528407 |
14:34:50 | FromGitter | <Varriount> Really. Even if I didn't harbor some animosity towards Rust, the high occurrence of comments its community injects into C and C++ submissions is annoying. |
14:35:41 | FromGitter | <Varriount> leru: See the "target" command line switch: https://nim-lang.org/docs/nimc.html#compiler-usage-command-line-switches |
14:45:00 | * | vlad1777d quit (Remote host closed the connection) |
14:48:47 | * | yglukhov joined #nim |
14:49:33 | * | daekano quit (Ping timeout: 256 seconds) |
14:52:22 | * | couven92 quit (Quit: Client disconnecting) |
14:52:32 | * | daekano joined #nim |
14:57:39 | * | hendi_ joined #nim |
15:01:54 | ftsf | hmm system module needs 'nimLoadLibrary' |
15:06:15 | * | chemist69 quit (Ping timeout: 258 seconds) |
15:08:41 | FromGitter | <Varriount> ftsf: is that a problem ? |
15:08:58 | * | chemist69 joined #nim |
15:09:04 | ftsf | sorry, it's prefixed with Error: ;) |
15:09:32 | ftsf | I assume that means nimLoadLibrary is not available |
15:09:46 | FromGitter | <Varriount> What's throwing that error? `nimble build`? |
15:10:16 | ftsf | nim c building my app using --os:standalone . |
15:10:40 | Araq | ftsf: does the test work for you? |
15:11:53 | ftsf | it does |
15:15:39 | * | Guest89004 quit (Ping timeout: 252 seconds) |
15:15:43 | ftsf | ahh, I think I know why my app is raising that error, since i'm importing sdl2, which I should no longer be using. |
15:16:46 | Araq | sdl2 is so awesome it doesn't require an OS to run :P |
15:18:57 | ftsf | =) |
15:19:55 | * | devted joined #nim |
15:20:52 | ftsf | thanks for the help, bedtime! |
15:30:13 | * | yglukhov quit (Remote host closed the connection) |
15:31:19 | * | ofelas joined #nim |
15:31:49 | * | yglukhov joined #nim |
15:35:59 | * | PMunch quit (Quit: leaving) |
15:36:16 | * | PMunch joined #nim |
15:38:15 | * | nsf joined #nim |
15:39:11 | * | yglukhov quit (Remote host closed the connection) |
15:42:41 | FromGitter | <zetashift> good night? |
15:42:46 | FromGitter | <zetashift> itś 16:42 here |
15:44:39 | * | yglukhov joined #nim |
15:49:12 | * | yglukhov quit (Ping timeout: 252 seconds) |
15:53:30 | * | pregressive joined #nim |
15:59:02 | rokups | if i use "--cpu:i386 --passC:-m32 --passL:-m32 -d:release" flags it builds 32 bit executable with gcc. however if i add --cc:gcc it throws Nim_and_C_compiler_disagree_on_target_architecture error. any ideas why that would be happening? |
16:08:17 | * | gokr left #nim (#nim) |
16:08:40 | FromGitter | <barcharcraz> Can you check the commands being passed (genscript) |
16:18:38 | * | vlad1777d joined #nim |
16:33:45 | * | vlad1777d quit (Remote host closed the connection) |
16:36:46 | * | Andris_zbx quit (Remote host closed the connection) |
16:36:50 | * | arnetheduck quit (Ping timeout: 248 seconds) |
16:39:32 | rokups | barcharcraz with --genScript and without --cc i get "execution of an external compiler program 'gcc ...' failed" |
16:40:14 | * | vlad1777d joined #nim |
16:40:17 | rokups | complains about missing c file which is in nimcache |
16:40:31 | FromGitter | <barcharcraz> Perhaps you don't have the right GCC cross compiler installed? |
16:40:33 | rokups | though its in lib/pure/nimcache, for some reason deep |
16:41:03 | rokups | idk what is right and what is wrong, but i can build 32 bit binaries.. just not in all cases |
16:41:29 | rokups | obviously i do have gcc installed as well. im not drunk to not notice :p |
16:43:40 | * | vlad1777d quit (Remote host closed the connection) |
16:45:27 | Araq | rokups: don't add --cc:gcc, prepend it |
16:45:51 | Araq | https://github.com/nim-lang/Nim/issues/5307 |
16:54:53 | * | Trustable joined #nim |
17:01:54 | rokups | thanks Araq, works ;) i had hit a brickwall with gcc/32bit in release builds but figured out workaround. so now coroutines work on all combinations of clang/gcc/debug/release/i386/amd64 (linux) and vcc/debug/release/i386/amd64 (windows). now testing it with optimizations, some of combos still crash. but its getting better. |
17:07:45 | rokups | is there any define i could check for optimization level? |
17:08:07 | * | filcuc quit (Ping timeout: 240 seconds) |
17:12:17 | * | hendi_ quit (Quit: hendi_) |
17:12:51 | * | chemist69 quit (Ping timeout: 276 seconds) |
17:15:11 | Araq | rokups: you can only check for 'defined(release)' |
17:16:07 | rokups | hmm yeah.. im adding my own for testing. turns out gcc does not support asmNoStackFrame and it is so complicating everything.. |
17:16:52 | * | chemist69 joined #nim |
17:19:52 | * | Parashurama joined #nim |
17:20:07 | Parashurama | hey! |
17:20:53 | Araq | hi |
17:20:55 | * | yglukhov joined #nim |
17:20:55 | Parashurama | Araq: following github issue. what did I misunderstood? |
17:22:36 | Araq | well the default config is C compiler specific, like gcc.options.always = "foo bar" so CC=vcc doesn't break anything |
17:23:39 | Parashurama | Okay, and since project/nim.cfg is user responsability, we could do what I suggested. |
17:23:50 | * | yglukhov quit (Remote host closed the connection) |
17:24:09 | Araq | in Nim code {.passC: "".} is processed after we know the CC so that can in general be protected by a 'when defined(gcc)' (and is) |
17:24:32 | Parashurama | for all other people we are talking about: https://github.com/nim-lang/Nim/issues/5307 |
17:24:35 | Araq | so --passC is dangerous in a config file and kind of broken on the command line :-) |
17:24:49 | Araq | I don't know what follows from all of this. |
17:25:22 | Araq | on the other hand, say we have --passC in a config file and no CC |
17:25:41 | Araq | we set CC on the command line, then CC resets the passC stuff, exactly what we need |
17:26:01 | Araq | so that works too, but it's a bit subtle |
17:26:02 | Parashurama | we could maybe deprecate passC/passL on cmdline |
17:26:25 | Parashurama | add prefer setting in nim.cfg |
17:26:32 | Araq | well we could do your initial proposal so more cases do work. |
17:26:37 | Parashurama | or even nim_file.cfg |
17:26:51 | Araq | the problem with that is that I cannot see what else might require the same mechanism. |
17:27:16 | Araq | what if I set the CPU? doesn't affect passC, i guess |
17:27:55 | FromGitter | <andreaferretti> (passC on the command line is also useful for nimble tasks - ideally I would like a single nimble file instead of that + .cfg) |
17:28:27 | Parashurama | Yeah not so simple after all! |
17:29:14 | Parashurama | andreaferretti: I don't get what you are saying. |
17:29:39 | Parashurama | You mean using nimble for everything, even small scripts? |
17:30:52 | Parashurama | In theory, my proposal should work (see github issue above), but I might be missing something. |
17:31:03 | Araq | isn't this just switch("passC", "value") in NimScript? |
17:31:32 | Araq | https://nim-lang.org/docs/nims.html |
17:31:43 | Araq | "NimScript as a configuration file" |
17:31:58 | Araq | if not, this should be reported as a bug. |
17:32:09 | * | brson joined #nim |
17:33:51 | Parashurama | I haven't actually used Nimscript before, but it seems interesting. |
17:35:37 | Parashurama | If I understand this. in a .nims file I use switch("passc", " -g ") then in the same file: exec "nim c -r test_file" and the option is passed along? |
17:36:09 | * | nsf quit (Quit: WeeChat 1.7) |
17:36:21 | Araq | lol no. |
17:36:39 | Araq | I mean yes, that can work |
17:36:57 | Araq | but it doesn't work by passing the config to the subprocess "nim c" |
17:37:11 | Araq | instead the subprocess reads the config.nims again ;-) |
17:37:47 | Parashurama | Okay. it is a bit convoluted, but it means I can replace my Makefiles with this. |
17:38:05 | Araq | yay :-) that was its goal. |
17:39:14 | Araq | btw "-g" is "--debugger:native" |
17:39:21 | FromGitter | <andreaferretti> My point was that if one removes the possibility to `passC:` on the command line |
17:39:45 | FromGitter | <andreaferretti> I would like for that to keep working in nimble |
17:40:19 | FromGitter | <andreaferretti> I am not sure if nimble tasks actually shell out a command on the command line |
17:40:33 | Parashurama | I think I would like to read the code for nimscript? Where is it hosted? |
17:41:12 | FromGitter | <andreaferretti> https://github.com/unicredit/linear-algebra/blob/master/linalg.nimble#L46 |
17:42:20 | Parashurama | Well that's much nicer than cmake/makefile syntax :) |
17:43:21 | Parashurama | I think I will go play with it. |
17:43:50 | FromGitter | <andreaferretti> bye, I got to go |
17:44:10 | Araq | hosted? it's part of Nim. |
17:44:27 | Araq | Parashurama: I think your proposed fix the best solution for now. |
17:44:45 | Araq | errors like "use --passC after --cc" are puzzling for users. |
17:45:00 | Araq | "why not understand what I mean instead?" |
17:45:16 | * | PMunch quit (Quit: leaving) |
17:45:47 | Parashurama | so are we disabling passC on the cmdline? or my first proposal with separate option list? |
17:46:50 | Parashurama | Araq: I will make a tentative PR proposal and see how that works. |
17:47:27 | Araq | internal separate option list |
17:47:35 | * | yglukhov joined #nim |
17:47:59 | Araq | don't disable passC on the cmdline, that's too radical. |
17:49:11 | * | couven92 joined #nim |
17:57:33 | * | vlad1777d joined #nim |
18:04:11 | Parashurama | Araq: sorry for the delay. I was called. |
18:04:18 | * | leru quit (Quit: Leaving) |
18:04:33 | Parashurama | I will start making that PR now. |
18:06:04 | rokups | Araq: is there a proc in compiler to find a file in PATH? |
18:07:47 | rokups | oh its findExe! |
18:27:40 | * | couven92 quit (Quit: Client disconnecting) |
18:29:25 | * | smt quit (Read error: Connection reset by peer) |
18:29:59 | * | cheatfate joined #nim |
18:44:14 | FromGitter | <Varriount> rokups: findExe should be renamed findInPath :p |
18:47:04 | * | yglukhov quit (Remote host closed the connection) |
18:48:17 | rokups | truly ;) |
18:53:39 | rokups | looks like x64 mingw will be the last broken thing i wont do today. everything else seems to work though ^_^ |
18:54:20 | FromGitter | <Varriount> Hm. Or if you want to be really precise, searchForPathInPathEnvironmentVariable |
18:54:42 | FromGitter | <Varriount> @Araq ^ :D |
18:58:19 | * | hendi_ joined #nim |
18:59:03 | Araq | Varriount: I prefer findExe |
18:59:22 | Araq | at one point we'll have a sane OS without environment variables |
18:59:38 | Araq | and then findExe() continues to make sense and findInPath doesn't :P |
19:04:23 | dom96 | That won't happen any time soon. |
19:04:31 | * | synshroud quit (Quit: ZNC 1.6.4 - http://znc.in) |
19:04:43 | dom96 | if it does then we'll have a findInDatastore proc |
19:07:26 | * | synshroud joined #nim |
19:09:40 | * | krux02 joined #nim |
19:11:44 | dom96 | Interesting https://news.ycombinator.com/item?id=13533701 |
19:16:03 | FromGitter | <Varriount> @dom96 https://news.ycombinator.com/item?id=13530485 |
19:17:59 | FromGitter | <Varriount> Perhaps someone could add that rust isn't the only language that has safe features? |
19:19:30 | FromGitter | <Varriount> I've already made a comment there but forgot to mention Nim |
19:22:42 | * | hendi_ quit (Quit: hendi_) |
19:28:49 | dom96 | Mentioning Nim under a comment that complains about Rust being mentioned doesn't seem like the best idea |
19:30:12 | Araq | yup :-) |
19:30:16 | * | Arrrr joined #nim |
19:30:16 | * | Arrrr quit (Changing host) |
19:30:16 | * | Arrrr joined #nim |
19:31:27 | FromGitter | <Varriount> I guess. |
19:32:12 | FromGitter | <Varriount> It's unfair though,l. |
19:35:24 | * | yglukhov joined #nim |
19:37:45 | * | Matthias247 joined #nim |
19:38:35 | * | kulelu88 joined #nim |
19:40:13 | demi- | that website is so bad |
19:40:38 | * | yglukhov quit (Remote host closed the connection) |
19:40:45 | cheatfate | demi-, nim website? |
19:40:54 | demi- | no, HN |
19:43:07 | Araq | any book recommendations? |
19:43:28 | Araq | hmm #nim-offtopic |
19:44:51 | * | nsf joined #nim |
19:48:05 | * | yglukhov joined #nim |
19:50:40 | * | vlad1777d quit (Remote host closed the connection) |
19:56:16 | Araq | so ... we now have .appveyor support again |
19:59:03 | Araq | how do I get a "build failing" button for this thing? |
19:59:35 | Araq | and also email notifications? hello? anybody? |
20:00:53 | demi- | hm? |
20:04:27 | Araq | never mind, I think I got it |
20:09:14 | * | unlaudable joined #nim |
20:12:18 | subsetpark | Any idea why this is "illegal capture 'jobs'"? |
20:12:33 | subsetpark | https://www.irccloud.com/pastebin/oznidqQG/ |
20:13:12 | Araq | subsetpark: the macro expands to a closure and closures cannot capture "openArray" |
20:13:20 | Araq | make it a 'seq' and it works |
20:13:20 | subsetpark | i see! |
20:13:45 | subsetpark | thanks Araq |
20:13:47 | Araq | maybe the macro can be rewritten to not use closures though, seems slow |
20:19:35 | * | unlaudable quit (Ping timeout: 264 seconds) |
20:30:59 | Arrrr | Araq, last summer you said you thought about dropping GC support for v2.0. Do you think the same nowdays? |
20:31:18 | Araq | hmm? |
20:33:28 | Araq | I have some concrete plans now for that |
20:33:51 | Araq | but it will still be "automatic" memory management |
20:34:10 | Araq | and it's too early to talk about it. |
20:35:25 | demi- | would it be an ARC-like system where the compiler inserts the correct retain/release calls at compile time? |
20:38:02 | Araq | no, it is better than that. (I hope.) |
20:38:21 | Araq | but I don't wanna talk about it. |
20:39:59 | demi- | sounds neat |
20:40:18 | * | Arrrr quit (Quit: Leaving.) |
20:44:38 | Parashurama | Araq: PR for passC/passL issue is pushed. |
20:47:30 | subsetpark | Is it possible to have a seq of types, which are then instantiated at runtime? |
20:48:27 | * | unlaudable joined #nim |
20:48:52 | Parashurama | If you mean types which inherit a common parent type, then yes. |
20:49:34 | subsetpark | yeah, they do... so is the type of that seq, `seq[typedesc]`? |
20:49:42 | Parashurama | otherwise it's a bit more complicated. you can use interface macros and stuff like that. |
20:49:58 | * | Parashurama left #nim (#nim) |
20:50:07 | * | Parashurama joined #nim |
20:50:33 | Araq | subsetpark: don't use seq[typedesc] |
20:50:41 | Araq | use seq[RootRef] instead |
20:50:49 | Araq | or whatever your base class is |
20:50:54 | Parashurama | say you have type Parent = ref object of RootObj |
20:51:12 | Parashurama | type Child0 = ref object of Parent |
20:51:18 | Parashurama | type Child1 = ref object of Parent |
20:51:18 | * | yglukhov quit (Remote host closed the connection) |
20:51:30 | Parashurama | and seq type is seq[Parent] |
20:51:59 | subsetpark | it's not a seq of values, though. It's more like this: |
20:52:10 | subsetpark | type Base = ref object of RootObj |
20:52:41 | subsetpark | let myChildren = seq[???] |
20:53:12 | subsetpark | for childType in myChildren: let value = childType(...); doSomething(value) |
20:53:49 | Araq | you can use RTTI for that I guess |
20:54:09 | Parashurama | You mean literally a seq of typedesc. As far I know that's not possible in nim, at least outside macros. This is not python :) |
20:54:21 | demi- | can you also use HashSets for this? |
20:55:35 | Parashurama | Can you use a PNimType to instanciate a new object ? |
20:56:08 | Araq | you can use RTTI which wraps the PNimType stuff somewhat nicely |
20:56:29 | Araq | but don't do it. |
20:56:56 | Araq | your problem seems backwards. you don't start with a "list of unknown" types |
20:57:05 | Araq | that you then need to treat as values, somehow |
20:57:17 | subsetpark | Translating from Python, they are a list of subclasses that are parameterized at runtime |
20:57:40 | Araq | sounds like you want a macro that takes a varargs |
20:58:21 | subsetpark | It might be overkill - the arguments will always be the same, just different values |
20:58:50 | subsetpark | They're structured that way for performance reasons, to be able to create classes on the fly rather than store instance variables many times over |
20:59:01 | subsetpark | But I suppose maybe they just would all be instance attributes here? |
20:59:41 | Araq | no idea. dynamic class creation is usually not done for "performance" |
21:00:06 | * | zachcarter quit (Ping timeout: 240 seconds) |
21:02:13 | subsetpark | Well - basically I have a 'worker' object, which has a bunch of instance attributes that change over time; i want to create several kinds of workers. The instances will all have their own copies of the instance attributes. There are also a bunch of attributes (always the same attributes) whose values vary per "kind", but not per instance |
21:02:17 | subsetpark | How would you structure that? |
21:03:07 | * | unlaudable quit (Ping timeout: 240 seconds) |
21:03:17 | * | filcuc joined #nim |
21:03:40 | filcuc | how do i change the compiler used from nim from the command line? |
21:03:41 | Araq | have a Worker object that contains a RootRef that contains the instance specific data |
21:04:05 | Araq | or have all the fields in the worker anyway |
21:04:15 | filcuc | second question: can i specify the compiler full path without changing the nim.cfg? |
21:04:41 | Araq | --gcc.path="c:\..." might work on the command line |
21:05:01 | Araq | subsetpark: or have a 'case kind' in your object |
21:05:14 | filcuc | Araq: for the first question? |
21:05:26 | Araq | --cc:gcc |
21:05:28 | subsetpark | Araq: but "case kind" can't be determined at runtime, right? |
21:05:29 | filcuc | Araq: basically i'm integrating the nim compiler in QtCreator toolchains |
21:05:53 | filcuc | and already submitted some patches upstream |
21:06:11 | Araq | subsetpark: if you don't know your "types" at compiletime, you are not working with "types" at all. |
21:06:25 | filcuc | so right now i've to add some option for selecting the compiler that nim should use |
21:06:42 | subsetpark | well, that's a matter of debate :) |
21:06:43 | filcuc | or at least extract the compiler used by nim and get its abi |
21:06:44 | Araq | you then have some fuzzy stuff that might as well be Json |
21:07:00 | Araq | filcuc: why? |
21:07:11 | * | gokr joined #nim |
21:07:28 | filcuc | Araq: not strictly related to nim, but basically QtCreator kits make some checks for ABI between various tools |
21:07:49 | filcuc | like between the selected debugger and compiler |
21:08:04 | filcuc | they're just some validation checks |
21:08:29 | filcuc | but in order to integrate correcly i've to "understand" or "specify" the compiler that nim should use |
21:09:19 | filcuc | but it's working more or less, i've also already integrated error messages to QtCreator output messages |
21:11:59 | Araq | I am not sure QtCreator knows better than me which compiler to use :-) |
21:12:06 | * | rokups quit (Quit: Connection closed for inactivity) |
21:12:17 | filcuc | ah..btw if any of you have time or will you can test the plugin already since a couple or releases inside QtCreator |
21:12:43 | filcuc | Araq: infact it's my job to teach him :) |
21:13:26 | Araq | well I dunno. if QtCreator invokes Nim I guess --cc:gcc and --gcc.path are fine |
21:13:36 | filcuc | hope to finish this for 4.3 |
21:13:53 | filcuc | Araq: that's all i needed to know |
21:13:58 | filcuc | (thanks) |
21:14:11 | filcuc | does it work with a possible cross compiler? |
21:14:40 | Araq | yeah, e.g. --os:linux --cpu:x86 |
21:14:49 | filcuc | suppose i add a compiler in QtCreator...with a name "arm-linux-gnueabi-gcc" |
21:15:01 | Parashurama | Araq: hey I trying to fix: https://github.com/nim-lang/Nim/issues/5042 |
21:15:02 | filcuc | i mean the cfg for gcc matches also for this compiler? |
21:15:32 | Parashurama | Where do you think I should start, with type inferance |
21:15:38 | filcuc | o have i to add some lines inside the cfg for supporting this compiler? |
21:15:57 | Araq | Parashurama: just let it be. |
21:16:10 | Araq | spent weeks on these things. |
21:16:31 | filcuc | in other words: can i specify with "--cc:some_compiler" any arbitrary compiler executable (also not specified inside nim.cfg)? |
21:16:38 | cheatfate | unsigned integers in Nim is main flaw :) like unsafe pointers in C |
21:17:09 | Araq | filcuc: no, Nim needs to understand the backend compiler |
21:17:27 | Araq | besides, there are only a handful of C++ compilers left. |
21:17:37 | Parashurama | Oh. it's all linked to an unsigned int problem. |
21:17:54 | Araq | your "arm-linux-gnueabi-gcc" would be --cc:gcc too |
21:18:07 | Parashurama | well, onto the next issue i can try to solve. only 881 left :) |
21:18:32 | Araq | Parashurama: most "bugs" are minor annoyances and feature requests |
21:18:56 | Araq | people got the idea they can request features here ... tz tz tz |
21:19:31 | Parashurama | I suppose, but shoudn't they be closed then. |
21:19:59 | Araq | how about you fix this: https://github.com/nim-lang/Nim/issues/5308 |
21:20:13 | Araq | should be easy. and add a test case for --gc:stack please |
21:21:25 | Araq | or this here: https://github.com/nim-lang/Nim/issues/5264 |
21:21:49 | Parashurama | I will certainly try. I haven't yet explored gc:stack. |
21:21:53 | * | yglukhov joined #nim |
21:24:42 | Araq | use the issue tagging please. |
21:24:58 | Araq | https://github.com/nim-lang/Nim/labels/High%20Priority |
21:25:30 | Parashurama | Okay, I am on the GC stack problem. |
21:26:02 | * | Vladar quit (Quit: Leaving) |
21:26:05 | Araq | ok, next one is this: https://github.com/nim-lang/Nim/issues/4636 |
21:26:58 | * | yglukhov quit (Ping timeout: 249 seconds) |
21:27:00 | FromGitter | <barcharcraz> hey filcuc: Thanks for dotherside and nimqml |
21:27:39 | * | Trustable quit (Remote host closed the connection) |
21:31:18 | dom96 | ooh, new github feature |
21:31:28 | dom96 | "topics" |
21:33:36 | * | filcuc quit (Ping timeout: 240 seconds) |
21:38:01 | krux02 | Araq: regarding issue #881 |
21:38:30 | krux02 | The issue that was fixed was the reverse |
21:39:23 | krux02 | it was when I reference an ast from a quote, and then change it, but in issue #881 I insert a node with backticks |
21:40:11 | * | filcuc joined #nim |
21:40:19 | krux02 | I am not sure if an insertion with backticks is inteded to copy the tree or not, I think no matter what it does, there could be reasons for it, but currently it copies the node |
21:40:20 | filcuc | FromGitter: np ;) |
21:40:21 | FromGitter | filcuc, I'm a bot, *bleep, bloop*. I relay messages between here and https://gitter.im/nim-lang/Nim |
21:41:09 | Araq | krux02: hmm I don't know. would by ref be sound? |
21:41:31 | Araq | we don't want to be able to modify the ASTs through 'quote do' |
21:43:18 | krux02 | It is useful to use quote do, to reference into the AST though |
21:43:42 | krux02 | but on the other end, in most cases the quote do can also just be placed behind all modifications |
21:49:49 | Araq | hmm I think I finally understand your problem |
21:49:54 | Araq | how come it copies? |
21:50:14 | Araq | shouldn't the nodes internally have the nfIsRef flag set already? |
21:51:23 | * | chemist69 quit (Ping timeout: 264 seconds) |
21:52:09 | * | zachcarter joined #nim |
21:54:51 | Parashurama | Araq: btw the gc_stack is really a non-issue. you are not supposed to import system/gc_stack into your module, everything is already available from system.nim (included via system/mmdisp.nim) |
21:55:18 | Araq | so write that and close the bug |
21:55:33 | Araq | or let me close the bug now |
21:55:47 | Araq | you need to fix more to get write access to the repo :P |
21:56:31 | Parashurama | I will add a comment on this issue and go to the next one in the list. |
21:58:18 | Parashurama | You can now close issue: https://github.com/nim-lang/Nim/issues/5308 |
22:03:19 | * | rupil quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
22:04:50 | Araq | too late, was already closed |
22:05:40 | Parashurama | Now onto https://github.com/nim-lang/Nim/issues/4636 |
22:06:06 | * | PMunch joined #nim |
22:10:53 | * | dddddd joined #nim |
22:17:37 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
22:18:04 | * | chemist69 joined #nim |
22:35:57 | * | bjz joined #nim |
22:45:48 | PMunch | Hmm, sometimes Nim reports an error on the wrong line |
22:46:37 | Parashurama | That a pretty old error. mostly around template defined in sytem.nim |
22:46:41 | cheatfate | PMunch, only seen this with templates which using templates |
22:46:51 | Parashurama | in iterator for seq/array etc... |
22:47:00 | PMunch | http://ix.io/1RD0 |
22:47:08 | PMunch | That's the code I currently have |
22:47:16 | PMunch | And it reports an error on line 88 |
22:47:28 | PMunch | But the error doesn't actually occur until line 101/102 |
22:47:44 | Parashurama | Let's try to make a smaller test case. :) |
22:48:03 | PMunch | Yeah, sorry about that :P |
22:48:04 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
22:48:20 | PMunch | Hmm, commenting out the dumptree statements makes the error appear at line 102 |
22:48:42 | PMunch | With just the top one it occurs on line 72 |
22:48:56 | PMunch | So it always seem to occur on the last line of the previous dumptree.. |
22:49:01 | * | FromGitter quit (Remote host closed the connection) |
22:49:01 | * | BlaXpirit quit (Quit: Bye) |
22:49:18 | * | FromGitter joined #nim |
22:49:25 | * | BlaXpirit joined #nim |
22:50:45 | PMunch | http://ix.io/1RD1 |
22:50:47 | PMunch | There |
22:50:51 | PMunch | A more minimal example |
22:50:57 | * | filcuc quit (Quit: Konversation terminated!) |
22:51:14 | PMunch | First a dumptree, then a macro definition which creates some bad AST, then the call |
22:51:48 | PMunch | Defining the macro before the dumptree makes no difference |
22:52:46 | * | pregressive quit (Remote host closed the connection) |
22:52:55 | Parashurama | just tried it with your reduced testfile. can reproduce. |
22:56:50 | Parashurama | interesting bug. this seems related to dumptree, since I couldn't reproduce the bug with another macro invocation in its place |
22:57:15 | PMunch | Yes it seems like it |
22:57:29 | PMunch | Not quite sure what causes it though.. |
22:57:44 | Araq | vm.nim c.comesFromHeuristic ;-) |
22:59:30 | Parashurama | PMunch: you probably should write a new issue. |
22:59:53 | Parashurama | Araq: that sounds like good start. |
23:00:04 | Araq | meh don't report it please |
23:00:11 | Araq | pushing a fix alredy |
23:00:14 | Araq | *already |
23:00:20 | PMunch | Oh nice :) |
23:00:26 | Parashurama | damn you are fast. |
23:00:48 | Parashurama | but you probably know the compiler like the back of your hand |
23:01:08 | * | couven92 joined #nim |
23:01:28 | Araq | no, it's just that I recently looked at a similar problem and remembered "that is weird" :P |
23:02:02 | Araq | but yeah, I know most parts of the compiler very well |
23:02:41 | * | Jesin quit (Quit: Leaving) |
23:03:09 | Parashurama | I'm wrapping the string slice issue before going to sleep (writing test-cases is boring) |
23:03:17 | Parashurama | *wrapping-up |
23:04:00 | Araq | wrapping up? |
23:04:13 | Araq | does that mean you fixed it? |
23:04:35 | Araq | https://github.com/nim-lang/Nim/issues/4992 |
23:04:44 | Araq | is a nice exercise in compiler development |
23:04:59 | Araq | any takers? |
23:05:04 | Parashurama | yeah, the code suggested in the issue was already mostly working. I'm just writing a test file. |
23:05:42 | Parashurama | maybe tomorrow. it already past midnight where I live. |
23:07:18 | Araq | same timezone as me then |
23:07:35 | Parashurama | I live in France at the moment. It's pretty nice. |
23:13:18 | Parashurama | Araq: okay good night. |
23:13:31 | Parashurama | night |
23:13:45 | * | Parashurama left #nim (#nim) |
23:13:52 | PMunch | I should probably go to bed as well |
23:13:59 | PMunch | Same timezone as you guys |
23:14:19 | couven92 | PMunch, we got to write on our paper tomorrow |
23:14:27 | couven92 | :P |
23:14:54 | PMunch | Yup |
23:18:36 | * | PMunch quit (Quit: leaving) |
23:23:16 | * | nsf quit (Quit: WeeChat 1.7) |
23:24:42 | * | devted quit (Quit: Sleeping.) |
23:24:45 | * | yglukhov joined #nim |
23:28:41 | zachcarter | is there a way to get an array from a sequence? |
23:29:05 | * | xet7 quit (Quit: Leaving) |
23:29:11 | * | yglukhov quit (Ping timeout: 240 seconds) |
23:31:06 | Araq | no. |
23:31:25 | zachcarter | alright thank you |
23:35:22 | * | dddddd quit (Quit: Hasta otra..) |
23:38:23 | dyce[m] | when declaring variables before the routes in jester, nim says that its not gcsafe, does that mean if you reassign the variable to a new object, the unreferences objects wont get deleted? |
23:39:13 | dyce[m] | unreferenced* |
23:39:16 | * | xet7 joined #nim |
23:40:11 | Araq | no. |
23:41:43 | * | Jesin joined #nim |
23:45:45 | dyce[m] | what do those warnings signal and is there some other way to have global variables (without using a db) and avoid the warnings? |
23:46:22 | * | xet7 quit (Quit: Leaving) |
23:48:25 | dyce[m] | i mean what are examples of problems caused by the warning |
23:49:52 | * | gokr quit (Quit: Leaving.) |
23:50:04 | * | smt joined #nim |
23:52:05 | Araq | make the vars .threadvar |
23:53:09 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:56:09 | * | chemist69 quit (Ping timeout: 240 seconds) |
23:58:44 | * | chemist69 joined #nim |