00:02:02 | Araq | flaviu: import foo.* is not homoiconic without yet another special case in the grammar :P |
00:02:46 | Araq | myimport foo.* # breaks the parser unless we introduce postfix operators |
00:02:58 | flaviu | Araq: I was mostly playing devil's advocate |
00:03:17 | flaviu | Current syntax is a bit odd, but its fine with me |
00:04:09 | Araq | yeah well I'm only saying this because it's something we keep forgetting about |
00:04:47 | * | askatasuna quit (Quit: WeeChat 0.4.3) |
00:04:48 | Araq | and if anything the syntax needs to become more homoiconic, not less |
00:05:46 | * | BlameStross left #nimrod (#nimrod) |
00:06:30 | bogen | Araq: I submitted a fix for #1451 |
00:07:03 | * | johnsoft quit (Quit: Leaving) |
00:07:41 | Araq | bogen: is it urgent? |
00:08:02 | bogen | no, I can use my own builds for now |
00:08:32 | bogen | I can wait for the next production release |
00:09:42 | Araq | btw you can use c[i] in {' ', '\t', '\L', '\c'} |
00:09:58 | NimBot | Araq/Nimrod devel 530d210 Dwight Schauer [+0 ±1 -0]: Added carriage return and linefeed check to os::parseCmdLine ti delimiting whitespace eating. |
00:09:58 | NimBot | Araq/Nimrod devel cc230fc Andreas Rumpf [+0 ±1 -0]: Merge pull request #1453 from dschauer/devel... 2 more lines |
00:10:41 | Araq | def-: ugh, I really don't want "-lm" for posix? is that really necessary? |
00:12:43 | def- | Araq: doesn't compile if you want to use these functions |
00:12:50 | def- | they could also be moved to another module i guess |
00:12:54 | def- | math or a new one? |
00:13:09 | Araq | what are these functions? |
00:14:07 | def- | set and get how floating point numbers are rounded |
00:15:03 | def- | They are standardized in C99 too |
00:15:04 | Araq | is that Posix 99 that nobody implements? |
00:15:49 | Araq | does macosx have these? BSD? Solaris? Irix? |
00:16:00 | def- | C99 and POSIX.1-2001 apparently |
00:16:42 | Araq | meh, put them in math.nim |
00:16:42 | bogen | ok, thanks... I was just following the example of the code that was there...". c [i] in {...} is cleaner... |
00:17:04 | Araq | bogen: yeah I know, but I thought maybe you don't know already |
00:17:16 | def- | Araq: hm, they don't seem to work everywhere. "Microsoft has _controlfp(). Some Unix clones, like OpenBSD, have fpsetround()" |
00:17:39 | Araq | def-: yup |
00:18:05 | bogen | Araq: you are correct, I did not know it, I meant, thanks for the suggestion :) |
00:26:44 | def- | Araq: is there a way to have the volatile pragma for parameters? |
00:29:01 | Araq | no, I can add it, but why do you need it? |
00:29:28 | Araq | who needs volatile anyway, its semantics are unclear |
00:29:43 | def- | exactly for this float rounding stuff |
00:30:18 | def- | if i don't set the parameters to volatile gcc optimizes away the second calculation and i get the wrong result: |
00:30:27 | def- | https://github.com/def-/nimrod-unsorted/blob/master/safeadd.nim |
00:31:29 | Araq | what? |
00:31:41 | Araq | are you sure that's the problem? |
00:31:57 | Araq | are the volatile lets not good enough? |
00:32:01 | def- | They are good enough |
00:32:06 | def- | I just wanted it without them |
00:32:12 | Araq | ah ok |
00:33:42 | Araq | what happens when fesetround produces a memory barrier? |
00:33:49 | Araq | does GCC still optimize it then? |
00:34:53 | def- | i don't know. how would i test that? |
00:37:46 | Araq | wrap it in some proc that also does {.emit: """asm volatile("pause" ::: "memory");""".} |
00:38:05 | Araq | but I guess it does |
00:38:26 | Araq | it's crazy to treat non volatile locals as "memory" |
00:39:35 | def- | Araq: still optimized away |
00:43:44 | * | saml_ joined #nimrod |
00:47:01 | Varriount | Hi saml |
00:47:22 | saml_ | hi Varriount |
00:47:36 | saml_ | i've been waiting for you |
00:47:39 | saml_ | welcome to the channel |
00:47:42 | Varriount | Uh oh... |
00:48:17 | saml_ | lol |
00:48:19 | Varriount | Araq: http://forum.nimrod-lang.org/t/514 |
00:48:28 | * | Joe_knock joined #nimrod |
00:48:44 | * | Varriount waves at Joe_knock |
00:49:02 | Joe_knock | Hello Varriount :) |
00:49:04 | Araq | Varriount: yes, I read it |
00:49:58 | Araq | FileInfo should expose whether it's a hidden dir/file |
00:52:12 | Joe_knock | Is there a way to execute the executable in linux? I don't see the command and hitting "right-click, execute" doesn't work. |
00:53:37 | Varriount | Araq: At that point, you get into what exactly constitutes a 'hidden' file, and whether there are any other important file attributes that need to be exposed. |
00:54:47 | flaviu | Araq: What happened to sleeping? |
00:55:00 | Araq | flaviu: it's overrated |
00:55:26 | def- | Joe_knock: what executable? |
00:55:30 | flaviu | lol |
00:56:27 | Joe_knock | def- the one that is created when I compile a .nim file. |
00:57:25 | def- | Joe_knock: I can just execute them. You can run them from a terminal? |
00:57:55 | Joe_knock | def-: That is what I am trying to find out. What command do I use with the executable? |
00:58:16 | def- | when you're in the same directory of the file ./filename |
00:58:17 | saml_ | ./asdf |
00:58:30 | saml_ | nimrod c --run asdf.nim |
00:58:44 | def- | -r also works! |
01:00:06 | Joe_knock | Wait a second, this feels very much like running a normal linux executable :-/ I think I've been spending too much time on the dynamic side of coding :'D |
01:00:16 | def- | Sure, it's a normal executable |
01:00:46 | Araq | good night |
01:00:46 | Araq | this time for real |
01:01:48 | Joe_knock | def-, flaviu: I think our combined timezones stretch across the world |
01:06:28 | Joe_knock | What is the most up to date Nimrod code highlighter in ST2? |
01:07:23 | def- | I guess this one: https://github.com/Varriount/NimLime |
01:08:54 | * | johnsoft joined #nimrod |
01:12:56 | Joe_knock | def- That looks like the most advanced one. |
01:21:21 | * | brson quit (Quit: leaving) |
01:31:18 | * | q66 quit (Quit: Leaving) |
01:39:58 | * | saml_ quit (Remote host closed the connection) |
01:47:23 | * | willwillson quit (Ping timeout: 240 seconds) |
01:57:20 | Joe_knock | Is anyone still here? |
01:58:50 | Skrylar | nope, we were all abducted :( |
02:00:14 | def- | I'm going to sleep, bye |
02:00:19 | Joe_knock | Skrylar: If you are able to assist, I keep getting this error: Error: type mismatch: got (TaintedString) but expected 'float' |
02:00:36 | Joe_knock | I am trying to get number input from the user using readLine(stdin) |
02:00:43 | def- | Joe_knock: import strutils |
02:00:50 | def- | and then parseFloat(readLine(stdin)) |
02:05:42 | * | saml_ joined #nimrod |
02:05:46 | Joe_knock | Would this be considered incorrect: var numero: float = parseFloat(readLine(stdin)) ? |
02:07:02 | Skrylar | oh. you have the tainted string stuff turned on |
02:07:58 | Skrylar | you're supposed to make sure there's nothing bad in the string before using .string to cast it from taintedstring to string IIRC |
02:08:11 | Joe_knock | Can you only feed input that are strings? |
02:08:31 | Skrylar | taintedstring is considered distinct to stop someone from wildly taking input from unsafe sources and tossing it at code that should be receiving safe input |
02:10:08 | Joe_knock | Skrylar: So when I say that the only valid input is strings, is this correct? |
02:15:06 | Skrylar | as far as i am aware yes |
02:15:33 | Skrylar | parseFloat(readLine(stdin).string) ought to work |
02:15:46 | Skrylar | IIRC |
02:16:26 | Joe_knock | interesting. Is it possible that parseFloat may require 2 variables in the function? I seem to have gotten an error that indicates such. |
02:17:31 | Skrylar | i haven't particularly used parseFlot or done a lot of IO work |
02:17:35 | Skrylar | unfortunately |
02:44:38 | * | Joe_knock quit (Quit: Leaving) |
02:57:23 | bogen | flyx: are you around? |
03:11:03 | * | xenagi quit (Quit: Leaving) |
03:25:24 | * | Jesin quit (Quit: Leaving) |
03:28:28 | * | adoniscik quit (Ping timeout: 255 seconds) |
03:36:35 | * | kshlm joined #nimrod |
03:46:30 | * | Hat_and_Cloak joined #nimrod |
03:51:20 | * | Hat_and_Cloak quit (Quit: Leaving) |
04:01:06 | * | JStoker quit (Ping timeout: 244 seconds) |
04:03:03 | * | Zuchto quit (Ping timeout: 255 seconds) |
04:04:20 | * | Zuchto joined #nimrod |
04:04:36 | * | JStoker joined #nimrod |
04:45:32 | * | ARCADIVS joined #nimrod |
04:49:31 | * | JStoker quit (Ping timeout: 256 seconds) |
04:53:05 | * | JStoker joined #nimrod |
04:53:18 | * | Zuchto quit (Ping timeout: 260 seconds) |
04:54:55 | * | Zuchto joined #nimrod |
05:12:25 | * | saml_ quit (Quit: Leaving) |
05:17:07 | * | shodan45 quit (Quit: Konversation terminated!) |
05:22:02 | * | Demos_ quit (Read error: Connection reset by peer) |
05:25:39 | * | methlabs joined #nimrod |
05:25:51 | * | methlabs left #nimrod (#nimrod) |
06:05:09 | * | nande quit (Read error: Connection reset by peer) |
06:16:42 | * | kaushal_ joined #nimrod |
06:17:20 | * | kshlm quit (Read error: Connection reset by peer) |
06:19:40 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
06:21:14 | * | kaushal_ quit (Ping timeout: 250 seconds) |
06:45:06 | * | kshlm joined #nimrod |
06:55:46 | * | kunev joined #nimrod |
07:07:10 | * | silven quit (Ping timeout: 250 seconds) |
07:27:12 | * | adoniscik joined #nimrod |
07:30:54 | * | darkfusion quit (Ping timeout: 250 seconds) |
07:31:03 | * | Zuchto quit (Ping timeout: 260 seconds) |
07:35:38 | * | Zuchto joined #nimrod |
07:39:11 | flyx | bogen: I am now. |
07:46:21 | flyx | bogen: I'll be afk for another hour or so, but I'll read the backlog when I come back. |
07:55:06 | NimBot | Araq/Nimrod devel a64d733 Araq [+0 ±2 -0]: some bugfixes for 'deepCopy' |
07:55:06 | NimBot | Araq/Nimrod devel 404ada2 Araq [+0 ±1 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
07:57:20 | * | BlameStross1 joined #nimrod |
08:19:11 | * | darkfusion joined #nimrod |
08:20:56 | * | EXetoC joined #nimrod |
08:53:32 | * | rektide quit (Ping timeout: 266 seconds) |
08:53:32 | * | skroll quit (Ping timeout: 266 seconds) |
08:53:47 | * | skroll joined #nimrod |
08:53:51 | * | rektide_ joined #nimrod |
09:40:56 | * | adoniscik quit (Ping timeout: 255 seconds) |
09:49:57 | * | willwillson joined #nimrod |
09:54:48 | * | zahary joined #nimrod |
10:04:25 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
10:46:04 | * | flaviu quit (Ping timeout: 240 seconds) |
11:24:05 | bogen | flyx: on the echo problem the issue is in compiler/ccgexprs.nim in genEcho (as far as I can tell). Once I wrap my head around linefmt I can correct the issue |
11:33:57 | bogen | rather than >>> printf("%s\012", (X)->data); <<< the compiler needs to generate something like >>> frwite((X)->data, (X)->Sup.len, 1, stdout); putchar ('\n'); << |
11:38:04 | bogen | s/frwite/fwrite/ |
11:38:36 | bogen | flyx: I'm referring to https://github.com/Araq/Nimrod/issues/1137 |
11:53:41 | * | darkf quit (Quit: Leaving) |
12:02:51 | bogen | well, I need to wrap my head around appf and app as well. I need to take off for a while, I'll check the channel logs when I get back |
12:03:02 | * | bogen left #nimrod (#nimrod) |
12:29:33 | flyx | bogen: shouldn't it rather be >>> fwrite((X)->data, sizeof(char), (X)->Sup.len, stdout); <<< |
12:35:04 | * | untitaker quit (Ping timeout: 240 seconds) |
12:42:07 | * | untitaker joined #nimrod |
13:06:03 | * | kshlm quit (Quit: Konversation terminated!) |
13:15:26 | * | Araq_ joined #nimrod |
13:16:27 | Araq_ | bogen: keep in mind that the spec says 'echo' is thread safe and so you either need to generate 1 printf call or use an explicit lock around mutliple puts calls |
13:17:20 | Araq_ | this file lock is likely not in Ansi C leading to further complications |
13:39:31 | * | bjz joined #nimrod |
13:59:13 | flyx | afaik, ANSI C doesn't even specify that printf is thread-safe |
13:59:30 | flyx | POSIX does |
14:06:00 | flyx | however, it shouldn't be a problem to fill one char[] with all the output and then fwrite() it. |
14:06:55 | Araq_ | but it is, you don't want to allocate and a fixed size buffer is not enough |
14:07:20 | flyx | hm. wouldn't printf allocate internally anyway? |
14:08:37 | flyx | ah, probably not, it directly stuffs it into the output stream |
14:10:32 | flyx | but ISO C99 allows char[] with a length that isn't a constant expression |
14:12:56 | flyx | not an option if the output should be ANSI C, of course |
14:17:12 | Araq_ | that only transforms it into a potential stack overflow |
14:17:30 | Araq_ | generting a single printf call is the way to go here |
14:25:17 | * | bogen joined #nimrod |
14:27:29 | bogen | printf will always stop on \0. locks would be expensive. It would be cheaper to do a copy/append and fwrite the result |
14:27:43 | bogen | the issue is not multiple c calls or buffer |
14:27:49 | bogen | buffering... |
14:27:59 | bogen | those can be preemempted |
14:28:19 | bogen | (as far as being thread safe) |
14:28:26 | Araq_ | you can tell printf to use a passed length for the passed cstring |
14:28:35 | Araq_ | forgot the %syntax for that though |
14:28:48 | bogen | ok, and it will skip the nul? |
14:28:57 | bogen | let me try that with regular c |
14:29:03 | bogen | that would fix the problem |
14:29:08 | Araq_ | yes |
14:29:17 | EXetoC | are you the one who responded to that issue on github? I posted a solution there |
14:29:35 | EXetoC | which is exactly that |
14:29:41 | bogen | yeah, I understand that now |
14:29:59 | EXetoC | but that was a couple of months ago |
14:30:19 | bogen | that is a better way to fix it. I saw your solution, and I did find the place to fix it |
14:30:33 | EXetoC | ok |
14:31:06 | bogen | I just did not connect your solution as being the fix until you clued me into here :) |
14:31:25 | EXetoC | right |
14:32:40 | bogen | what I was getting at earlier is that it is not the multiple c calls or the buffering, it is just that the final result of printf gets handed off to the kernel in a single call |
14:33:10 | bogen | which won't be preempted causing overlapping text output |
14:34:00 | Araq_ | so how does printf manage its buffer? |
14:35:07 | bogen | I would need to look into that. In order to be thread safe though it has to only make one kernel call (due to the forced flush from the final newline char) |
14:36:13 | Araq_ | well we can always have our own lock for stdout |
14:36:40 | Araq_ | 'echo' doesn't support anything other than stdout and the other IO procs are not guaranteed to be thread safe |
14:39:31 | bogen | printf("%.*s\n", 7, "dog\0cat"); // that still gets clipped at dog |
14:39:48 | bogen | why a lock? why not a copy/append? |
14:40:20 | bogen | (a copy and append the newline, the fwrite the result?) |
14:40:27 | bogen | then... |
14:41:16 | Araq_ | a lock is likely cheaper for long output |
14:42:22 | bogen | yeah, that would need to be profiled |
14:42:46 | Araq_ | well a lock is cheap when there is not much contention |
14:43:06 | Araq_ | copy is always O(n), even if there is no contention |
14:43:07 | bogen | I'm not disagreeing, but I think it would need to be many lines of output for a lock to be cheaper |
14:43:31 | bogen | yeah, I'm not familiar with the locking you would be using |
14:43:54 | EXetoC | of course my example sucks |
14:44:06 | bogen | or that you would want to be used in this case |
14:47:07 | Araq_ | stack overflow agrees: |
14:47:13 | Araq_ | printf("%.*s", length, string) will NOT work. |
14:47:15 | Araq_ | This means to print UP TO length bytes OR a null byte, whichever comes first |
14:47:26 | Araq_ | damn, this sucks |
14:54:37 | Araq_ | oh well, I might as well change the spec then, I see no reason to guarantee that |
14:54:48 | Araq_ | echo "foo", "bar" |
14:54:52 | Araq_ | behaves like |
14:55:02 | Araq_ | echo "foo" & "bar" |
14:56:20 | Araq_ | when the implementation has to do exactly that and can't do it more efficiently |
14:57:51 | Araq_ | I mean writing & is easy enough if I need the guarantee |
15:06:25 | bogen | yeah |
15:09:01 | bogen | so either per the the spec echo is thread safe (and harder to implement) or echo is not compliant with all unicode encodings |
15:12:42 | Araq_ | what has unicode to do with it? |
15:16:15 | * | [CBR]Unspoken2 joined #nimrod |
15:22:54 | bogen | unicode 16 can't be used with printf |
15:23:41 | bogen | which is why windows has wspintf and wprintf |
15:24:22 | bogen | http://stackoverflow.com/questions/6907297/can-utf-8-contain-zero-byte |
15:24:49 | bogen | utf-8 also has nuls it seems |
15:24:57 | Araq_ | so? echo outputs utf-8 / byte strings |
15:25:28 | Araq_ | utf-16 needs to die |
15:25:54 | bogen | echo with "nimrod i" works find with nuls |
15:26:52 | bogen | can echo print utf-8 byte strings that use code point 0? |
15:28:10 | Araq_ | well it should be able to do that, hence the bug report |
15:28:22 | Araq_ | I don't understand your question |
15:29:47 | bogen | http://en.wikipedia.org/wiki/UTF-8#Codepage_layout see row C_, columns _2 through _4 |
15:30:24 | bogen | there are others as well that have 00 bytes |
15:32:54 | bogen | oh, the encoding likely does not end up with nuls, as I can do an echo "Ā" |
15:33:08 | bogen | http://en.wikipedia.org/wiki/Latin_Extended-A |
15:33:25 | bogen | so, if all of UTF-8 can be printed, this issue can be closed |
15:34:34 | bogen | #1137 can closed I think if it is determined that all of UTF-8 is supported and that it does not need to support UTF-16 |
15:35:33 | bogen | which is what flyx said in #1137: Impact: May lead to unexpected or missing (debug) output, especially when working with stuff like UTF-16. |
15:41:31 | bogen | https://www.google.com/search?q=can+UTF-8+strings+have+nuls others seem to say no, I've not seen a definitive source on that (other than what libgit2 and rust people have discussed) |
15:42:24 | def- | bogen: https://en.wikipedia.org/wiki/UTF-8#Description |
15:42:47 | def- | bogen: there is always a leading 1 bit in each byte, so no byte can be nul |
15:42:48 | bogen | yes, but where does it say there will not be nuls |
15:44:01 | bogen | byte 1 if only 7 bit ascii, can have a nul |
15:44:31 | def- | yes, but that's the nul characte, which you want to have |
15:44:37 | bogen | multibyte encodings don't have nul |
15:46:08 | bogen | so the spec for echo could be, works with UTF-8, does not work with UTF-16, does not work with embedded nuls (which are not needed for the extended character sets) |
15:50:39 | Araq_ | I don't understand this, depending on which type you use for utf-16, it doesn't compile or it uses $ to transform it into utf-8 |
15:51:07 | Araq_ | and it should work with embedded nuls, hence the bug report |
15:54:00 | Araq_ | why does utf-16 need to be mentioned? why not utf-32? |
15:56:19 | bogen | https://github.com/Araq/Nimrod/issues/1137 "Impact: May lead to unexpected or missing (debug) output, especially when working with stuff like UTF-16.". flyx mentioned it initially, not me, but as you said, utf-16 is transformed to utf-8 |
15:58:16 | * | kunev quit (Quit: leaving) |
15:58:29 | flyx | it was just an example. |
16:04:00 | Araq_ | ok ok |
16:09:46 | bogen | well, I need to leave, I'll check the logs when I come back |
16:09:56 | Araq_ | ok, bye |
16:10:04 | bogen | bye |
16:10:08 | * | bogen quit (Quit: Leaving.) |
16:11:55 | def- | Is there a way to execute some memory as if it were a function (without emitting C code): https://github.com/def-/nimrod-unsorted/blob/master/machinecode.nim#L24 |
16:19:24 | Araq_ | no, but I dreamed of a proc allocExecutableMem() |
16:19:53 | Araq_ | then you can cast this pointer to some proc type and invoke it |
16:21:28 | Araq_ | I'm pretty sure Mat3 has code for that somewhere, but he'll be back in a month |
16:21:53 | * | zahary1 joined #nimrod |
16:22:20 | Araq_ | allocExecutableMem is not allowed on iOS iirc |
16:26:04 | * | zahary quit (Ping timeout: 260 seconds) |
16:27:53 | * | zahary joined #nimrod |
16:28:24 | * | zahary1 quit (Ping timeout: 260 seconds) |
16:37:06 | * | Matthias247 joined #nimrod |
16:38:47 | * | govg joined #nimrod |
16:38:54 | * | Jesin joined #nimrod |
16:46:07 | * | silven joined #nimrod |
16:49:34 | * | Jesin quit (Quit: Leaving) |
16:51:06 | * | Jesin joined #nimrod |
16:51:33 | Araq_ | screw this, PROT_EXEC is supported on iOS |
16:55:03 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 29.0/20140421221237]) |
16:56:10 | * | Matthias247 quit (Read error: Connection reset by peer) |
17:05:14 | * | q66 joined #nimrod |
17:11:47 | * | Jesin quit (Quit: Leaving) |
17:19:15 | * | brson joined #nimrod |
17:23:09 | * | zahary quit (Quit: Leaving.) |
17:29:42 | * | Demos joined #nimrod |
17:37:06 | * | Jesin joined #nimrod |
17:44:14 | * | willwillson quit (Ping timeout: 255 seconds) |
17:46:05 | * | kunev joined #nimrod |
17:48:33 | * | pown joined #nimrod |
17:55:34 | * | pown quit (Read error: Connection reset by peer) |
17:56:13 | * | pown_ joined #nimrod |
17:58:21 | pown_ | Hi, anoyone here working on c2nim? |
17:59:01 | * | nande joined #nimrod |
18:08:25 | * | Fr4n quit (Ping timeout: 244 seconds) |
18:12:22 | Araq | hi pown_ |
18:12:23 | Araq | rarely. |
18:19:31 | * | adoniscik joined #nimrod |
18:23:20 | pown_ | Hi! OK, any suggestions on approach for wrapping fftw3? |
18:23:33 | pown_ | Do you usually just do it 100% manual when c2nim breaks? |
18:24:10 | Demos | I usually fix the C source file |
18:24:22 | EXetoC | I can't remember which fft lib I tried to wrap |
18:24:58 | Demos | often the problems are with macros, you may have to manually convert them but for everything else you can run the c preprocessor to just eliminate macros and then add them back into the nimrod file |
18:25:03 | Araq | lol, 100% manual when c2nim breaks. no way. |
18:25:10 | EXetoC | well it worked, but I could never figure out why the nimrod code would behave differently |
18:25:37 | Araq | I cleanup the C header until c2nim likes it |
18:26:28 | pown_ | I see. THanks! |
18:26:53 | EXetoC | you basically have to, and it's often worth it |
18:27:59 | EXetoC | it's just difficult to learn how to fix things in batches, cus C is C |
18:29:00 | pown_ | Mm! |
18:30:15 | pown_ | Tricky to guess what to do to make c2nim like it though |
18:30:26 | EXetoC | let's replace C with something from this century that actually makes wrapper generation relatively simple |
18:30:54 | * | johnsoft quit (Read error: Connection reset by peer) |
18:31:08 | dom96 | hello |
18:31:33 | EXetoC | in many cases it's dll macros, which you can just define to nothing, the c2nim way (the manual explains that part) |
18:32:07 | EXetoC | and then there are some problems with multiline macros and anonymous types and such |
18:32:11 | Araq | pown_: just ask and gist some examples |
18:32:23 | Araq | EXetoC: anon types now work afaict :P |
18:32:44 | EXetoC | great. I recall that being worked on |
18:34:06 | Araq | hi dom96 |
18:34:12 | dom96 | hi Araq |
18:34:53 | pown_ | Araq, thanks! So here is one which I am not sure how to fix: https://gist.github.com/anonymous/85214cbf6bc6f98a48c1 |
18:35:28 | pown_ | (that is a smaller one, obviously - there are many defines in FFTW_DEFINE_API) |
18:35:32 | Araq | replace #define by #def |
18:45:58 | pown_ | Araq - you mean to put FFTW_DEFINE_COMPLEX as def? https://gist.github.com/anonymous/85214cbf6bc6f98a48c1 |
18:46:53 | Araq | well yes but ensure c2nim doesn't see the #define |
18:47:44 | pown_ | Hah! Operation successful - thanks! |
18:49:01 | * | johnsoft joined #nimrod |
18:52:41 | Araq | btw isn't this the very first thing that c2nim's docs now teach you? |
18:59:19 | pown_ | I think so. I just was not able to "get it", I'm afraid |
19:00:03 | Araq | no problem, but if you know how to improve the docs, I'm all ears |
19:00:24 | Araq | maybe add your gist as an example |
19:03:25 | pown_ | OK perhaps suggestions for the docs: it is more general than just "function prototype". And with yes, perhaps one more example. Btw, curious, how come c2nim does not attempt to just "search replace" the macros? (why the need to make #def?) |
19:04:30 | pown_ | oh and I deleted the gist, but I added it on the issues on c2nim |
19:04:52 | Araq | can you make a PR please to improve the docs? |
19:05:03 | pown_ | I can try :) |
19:05:54 | Araq | it doesn't attempt to just "search replace" because I came up with a useful heuristic later and now I've lots of more important things to do |
19:06:33 | pown_ | Ah I see. Thx! |
19:07:53 | pown_ | If you have a quick answer: does c2nim always fail to expand macros? |
19:08:02 | pown_ | macros/defines |
19:09:34 | Araq | the documentation explains this |
19:12:41 | Araq | pown_: #define FOO 8989 |
19:12:50 | Araq | is most common and c2nim handles that correctly |
19:13:06 | pown_ | OK Let me reread the docs properly |
19:35:10 | pown_ | Seems nimrod doc c2nim.txt fails on master branch |
19:36:13 | Araq | nimrod rst2html c2nim.txt |
19:36:25 | Araq | doc is for nimrod source code |
19:37:47 | pown_ | :] |
19:38:00 | * | wan joined #nimrod |
19:38:28 | * | willwillson joined #nimrod |
19:40:01 | * | brihat joined #nimrod |
19:43:25 | Araq | hi willwillson welcome |
19:47:35 | pown_ | Araq: https://github.com/nimrod-code/c2nim/pull/9 |
19:49:59 | Araq | pown_: thanks. applied |
19:52:21 | * | brihat left #nimrod (#nimrod) |
20:03:58 | * | io2 joined #nimrod |
20:09:56 | * | flaviu joined #nimrod |
20:14:52 | * | flaviu quit (Remote host closed the connection) |
20:21:23 | * | BlameStross1 quit (Ping timeout: 240 seconds) |
20:38:17 | * | pown_ quit (Remote host closed the connection) |
20:41:25 | * | Matthias247 joined #nimrod |
20:49:39 | * | pown joined #nimrod |
20:51:22 | * | pown quit (Client Quit) |
20:54:49 | * | wan quit (Quit: WeeChat 0.4.3) |
20:55:14 | * | Fr4n joined #nimrod |
21:03:19 | Araq | ping Varriount |
21:12:45 | * | CARAM_ is now known as CARAM |
21:13:49 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
21:20:52 | * | flaviu joined #nimrod |
21:27:45 | Araq | ping flaviu |
21:28:48 | Matthias247 | pong ;) |
21:30:05 | flaviu | Araq: Hey |
21:40:25 | * | nande quit (Read error: Connection reset by peer) |
21:49:02 | * | Fr4n quit (Ping timeout: 244 seconds) |
21:49:06 | * | kunev quit (Quit: Lost terminal) |
21:57:31 | Varriount | Araq: Pong |
21:57:52 | Araq | Varriount: I'm waiting for your PRs |
21:58:05 | Varriount | For..? |
21:58:11 | Varriount | Which ones? |
22:03:23 | Varriount | Araq: Which PR's do you want? |
22:04:28 | Araq | Varriount: well I don't really know. hiddenFile attribute for FileInfo? |
22:05:16 | Varriount | That can be done. Do you want a new walkDirRec as well? |
22:07:46 | * | bogen joined #nimrod |
22:09:14 | Araq | yeah |
22:09:25 | Araq | perhaps walkFileInfos ? |
22:09:25 | bogen | Hi Araq |
22:09:32 | Araq | wb bogen |
22:10:02 | bogen | http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/stdio-common/vfprintf.c#L221 a printf is more expensive than a copy/append/fwrite |
22:10:22 | bogen | printf has to build another string from based on the template |
22:12:21 | * | Jehan_ joined #nimrod |
22:12:22 | bogen | so for nimrod's echo it sees the %s, copies the string, and appends new line |
22:13:22 | Araq | bogen: without some micro benchmark this doesn't mean anything |
22:13:52 | bogen | yeah, I will do some benchmarking in large loops |
22:14:38 | bogen | but skipping the I/O I guess, as that would be the slowest part |
22:14:46 | bogen | so just an sprintf |
22:14:52 | Varriount | Araq: Oo, nice name |
22:14:54 | Araq | hmm ok |
22:15:08 | * | Varriount stabs launchpad |
22:15:19 | Araq | Varriount: really? glad you like it then, was a first shot |
22:17:56 | Varriount | Araq: Any other file attributes I should look into including? |
22:18:35 | Araq | well you already have soft links etc. right? |
22:19:11 | Varriount | Yeah, but only because pcLinkTo* is part of the PathComponent enum. *grumble grumble* |
22:20:19 | Araq | why the gumble? |
22:22:10 | Varriount | I keep thinking that it might have been better to replace TPathComponent with some sort of TFileDetails set, which contains various file aspects: "isFile", "isHidden", etc. |
22:28:01 | flaviu | Araq: You pinged me a while back? |
22:28:28 | Araq | flaviu: yeah for the same reason. get your ass up and fix some bugs or do some other nimrod related work. |
22:33:55 | * | Skrylar wrote a msgpack serializer FWIW |
22:34:14 | Varriount | flaviu: Apparently we're lazy lunks |
22:34:39 | flaviu | lol |
22:36:48 | flaviu | Sorry though, I've started trying to come up with my own language. Of course like most things I start, it'll take a (long | never) time to actually do anything lol |
22:37:19 | Varriount | Araq: I'm assuming that you would like wether a file is hidden or not to be expressed through a boolean isHidden attribute? |
22:39:25 | Araq | Skrylar: it is on babel? if not, it doesn't exist |
22:42:03 | Araq | Varriount: sure, unless you already have some 'flags' attribute in FileInfo |
22:43:05 | Varriount | Araq: Are the any explanations for https://github.com/Araq/Nimrod/issues/1445 ? That's an interesting issue. |
22:43:49 | Araq | I thought it was related to PR #1400 but according to def- that doesn't change anything |
22:44:13 | Araq | need to look at it, or even better implement some memory visualizer |
22:44:15 | Varriount | Unless PR #1400 doesn't work... |
22:44:39 | Jehan_ | It's something different, as far as I can tell. |
22:45:17 | Araq | well I didn't really look at it |
22:45:31 | Jehan_ | Currently looking at it. |
22:50:27 | Jehan_ | Interestingly, it manifests regardless of the GC type. |
22:51:05 | Jehan_ | I mean, the memory leak exists for the reference counting collector, the mark and sweep collector, and the Boehm GC. |
22:51:27 | Jehan_ | I had been wondering if maybe it was an issue with refcounts being off, but apparently not. |
22:52:19 | Araq | that's interesting indeed |
22:55:19 | Jehan_ | if I insert the "if i mod 1_000_000 == 0:" version, it goes away for all but the Boehm version. |
22:58:42 | * | Fr4n joined #nimrod |
22:59:50 | Araq | well gc:markAndSweep transforms leaks into crashes, usually |
23:00:16 | Araq | if the refcounting is wrong, it produces leaks |
23:00:32 | Araq | markAndSweep instead frees things prematurely |
23:00:35 | def- | I just started reporting where cpp doesn't compile but this might end up with too many issues |
23:00:48 | Araq | def-: don't report it, fix it |
23:02:16 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:02:19 | Varriount | Araq: Could it be that the programs are allocating memory faster than the Garbage collectors can deallocate it? |
23:02:53 | Araq | that can only happen for the realtime gc |
23:04:31 | Varriount | Araq: Should I also follow this rule? http://en.wikipedia.org/wiki/Hidden_file_and_hidden_directory#GNOME |
23:05:24 | Araq | Varriount: yes, on unix. |
23:05:38 | Varriount | No, I mean, the gnome convention |
23:06:08 | Varriount | "In the GNOME desktop environment (as well as all programs written using GLib[7]), filenames listed in a file named .hidden in each directory are also excluded from display" |
23:07:22 | Varriount | Oh crud. This is.. interesting. |
23:08:27 | Varriount | Since getFileInfo works with file handles (behind the scenes), I can't actually get the file name of the target. |
23:09:28 | Varriount | Which means I can't determine whether a file is hidden on Unix-like systems. |
23:10:00 | bogen | Araq: https://gist.github.com/dschauer/8804f820a6664671f9ce the copy/append is about 3 times faster than sprintf on my system |
23:10:50 | bogen | with the malloc/free overhead it would likely be even faster, I will test it with the malloc/free outside |
23:11:29 | * | darkf joined #nimrod |
23:12:20 | Jehan_ | Araq: I think I know why the bug happens. |
23:12:54 | Jehan_ | generic assignments are bracketed with GC_disable() and GC_enable() |
23:13:18 | Varriount | O_o |
23:13:33 | Jehan_ | Because no allocation happens outside that, collection is never triggered. |
23:14:09 | Araq | huh, interesting |
23:14:16 | Araq | and easy to fix :-) |
23:14:47 | Araq | I disabled these for .. erm ... reasons |
23:14:47 | * | bjz quit (Ping timeout: 245 seconds) |
23:15:54 | Araq | Varriount: ok, well can't you check for filename[0] == '.' in the construction of FileInfo |
23:15:58 | Araq | or however you do it |
23:16:23 | Varriount | Not if the procedure is called with a file handle |
23:16:44 | bogen | about 9 times faster without the malloc/free overhead https://gist.github.com/dschauer/1715b86f8a6f3269ff22 |
23:16:52 | Varriount | Ironically enough, getting a file name from a file handle is easy on Windows, but difficult with Unix systems. |
23:17:05 | Varriount | http://stackoverflow.com/questions/1188757/getting-filename-from-file-descriptor-in-c |
23:17:53 | * | brson quit (Quit: leaving) |
23:17:59 | Varriount | bogen: Is this code/technique meant to replace anything in particular? |
23:19:35 | flaviu | Varriount: Ignore the gnome thing |
23:19:47 | flaviu | if ls doesn't use it, you shouldn't either |
23:20:28 | Araq | Varriount: there is no irony here. unix breaks as soon as you take a close look at it |
23:20:45 | * | willwillson quit (Ping timeout: 256 seconds) |
23:21:41 | Araq | Varriount: I suppose this means my isHidden(filename: string): bool idea has even more merit? |
23:22:06 | Varriount | Araq: Yes... but it would only work for path names, not strings. |
23:22:11 | Varriount | *not handles |
23:23:22 | * | Fr4n quit (Ping timeout: 250 seconds) |
23:23:48 | Araq | ppfff hidden files are not special in any meaningful way anyway. why are they even a deal? |
23:24:09 | flaviu | Because I don't want my ~ clogged up with dot files? |
23:24:24 | Araq | lol |
23:24:33 | Araq | as if you can avoid it |
23:24:57 | Araq | I have ~/projects and this is my "real" home dir for exactly this reason |
23:24:58 | Varriount | flaviu: Then go petition Unix systems to develop a proper configuration store. |
23:25:26 | flaviu | Varriount: They have one: .config, and /etc/ |
23:25:39 | Araq | .bashrc is not in .config |
23:25:40 | flaviu | Please don't try to get the windows registry into unix |
23:26:21 | flaviu | Varriount: Windows has the same problem too, although a more manageable |
23:26:24 | Araq | the registry sucks but gnome and KDE copied it |
23:26:30 | flaviu | It has AppData |
23:26:33 | Varriount | :3 |
23:27:01 | flaviu | Araq: Gnome discontinued that |
23:27:42 | Araq | hu? why? what do they use instead? |
23:27:46 | flaviu | and from how much KDE configuration I've done, I'd say that KDE has done so too |
23:28:21 | flaviu | flat files, unix-style |
23:29:19 | flaviu | .kde4/share/config looks like |
23:29:28 | flaviu | Just a bunch of files, one per program or so |
23:30:17 | flaviu | kde looks like its never had a registry |
23:30:42 | flaviu | It's done some fancy caching with different file formats, but no more |
23:35:01 | Varriount | I wonder why, with the philosophy of "do one thing and do it well", linux never had a program to read/write configuration values to a file. |
23:35:28 | bogen | Varriount: it is meant to fix echo from stopping at nul bytes. (it could also possibly speed up echo, but that is not the intent, it is just that it would undesirable to slow down echo with the fix). https://github.com/Araq/Nimrod/issues/1137 |
23:35:47 | Varriount | bogen: Yay! |
23:36:53 | Varriount | Araq: Should the isHidden proc error if the file doesn't exist, even on Unix-like systems? |
23:39:07 | Araq | meh I dunno. I would make it return false on error |
23:39:21 | * | Fr4n joined #nimrod |
23:41:13 | flaviu | Varriount: What is the point of having a program to do that? |
23:41:40 | Jehan_ | Varriount: It's `vi ~/.profile` :) |
23:41:41 | flaviu | You just have to parse it yourself anyway, might as well cut out the middle man |
23:41:55 | Varriount | flaviu: Making sure configuration formats are similar. |
23:42:11 | Jehan_ | More generally, it doesn't make much sense with the combinator-style shell programming UNIX uses. |
23:42:13 | flaviu | minor problem, I haven't had much issue |
23:42:25 | flaviu | its mostly ini-style |
23:42:36 | Jehan_ | For all other use cases, you want a library, not a program. |
23:44:42 | * | Fr4n quit (Ping timeout: 250 seconds) |
23:44:47 | bogen | Araq: since copy/append is 3-9 times faster than sprintf, I plan to move ahead with implementing a fix for 1137, unless you still have some concerns. I need to know how you would want the allocation for the copy to be handled if I proceed. |
23:49:59 | Varriount | bogen: I wonder if there are other uses of printf family procedures that could be replaced with your code. |
23:57:38 | * | Fr4n joined #nimrod |