| 00:04:16 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 00:05:45 | * | Trixar_za is now known as Trix[a]r_za |
| 00:30:29 | SirSkidmore | dom96: yeah |
| 00:37:35 | * | q66 quit (Quit: Leaving) |
| 01:32:04 | * | mario-go` joined #nimrod |
| 01:38:51 | * | Reisen quit (*.net *.split) |
| 01:38:51 | * | mario-goulart quit (*.net *.split) |
| 01:38:51 | * | Boscop quit (*.net *.split) |
| 01:48:57 | * | Amrykid_ joined #nimrod |
| 01:49:19 | * | Amrykid quit (Ping timeout: 264 seconds) |
| 01:54:24 | * | Associat0r joined #nimrod |
| 01:59:25 | * | mario-go` is now known as matio-goulart |
| 02:05:29 | * | JStoker quit (*.net *.split) |
| 02:05:29 | * | Araq quit (*.net *.split) |
| 02:17:45 | * | Amrykid_ is now known as Amrykid |
| 02:23:50 | * | OrionPKM joined #nimrod |
| 02:28:39 | * | ChanServ joined #nimrod |
| 02:28:39 | * | Reisen joined #nimrod |
| 02:29:32 | * | Onion_PK joined #nimrod |
| 02:31:12 | * | OrionPKM quit (Remote host closed the connection) |
| 02:31:29 | * | JStoker joined #nimrod |
| 02:31:29 | * | Araq joined #nimrod |
| 02:31:48 | * | OnionPK quit (Ping timeout: 245 seconds) |
| 02:45:14 | * | Reisen quit (*.net *.split) |
| 02:45:14 | * | ChanServ quit (*.net *.split) |
| 03:49:46 | * | ChanServ joined #nimrod |
| 03:49:46 | * | Reisen joined #nimrod |
| 04:00:30 | * | Reisen quit (*.net *.split) |
| 04:00:30 | * | ChanServ quit (*.net *.split) |
| 04:21:57 | * | Onion_PK quit (Quit: Leaving) |
| 04:22:43 | * | ChanServ joined #nimrod |
| 04:22:43 | * | Reisen joined #nimrod |
| 04:25:07 | * | ChanServ left #nimrod (#nimrod) |
| 04:32:32 | * | Boscop joined #nimrod |
| 04:53:09 | * | Endy joined #nimrod |
| 05:17:39 | * | Boscop quit (Disconnected by services) |
| 05:17:42 | * | Boscop joined #nimrod |
| 05:26:30 | * | Boscop quit (Ping timeout: 264 seconds) |
| 05:32:53 | * | Boscop joined #nimrod |
| 06:48:55 | NimBot | Araq/Nimrod master 07849a9 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Silences debug echo. |
| 06:48:55 | NimBot | Araq/Nimrod master 80f4a3f Araq [+0 ±1 -0]: Merge pull request #508 from gradha/patch-1... 2 more lines |
| 06:51:26 | NimBot | Araq/Nimrod master a308501 Erik Johansson Andersson [+0 ±1 -0]: Modify babelpath... 2 more lines |
| 06:51:26 | NimBot | Araq/Nimrod master 44f230c Araq [+0 ±1 -0]: Merge pull request #509 from EXetoC/patch-1... 2 more lines |
| 06:54:23 | * | Endy quit (Ping timeout: 240 seconds) |
| 07:29:15 | * | Endy joined #nimrod |
| 08:35:41 | * | EXetoC joined #nimrod |
| 10:09:06 | * | q66 joined #nimrod |
| 10:12:09 | * | Endy quit (Ping timeout: 264 seconds) |
| 10:37:36 | * | Endy joined #nimrod |
| 10:42:36 | * | matio-goulart is now known as mario-goulart |
| 11:42:10 | * | Reisen quit (*.net *.split) |
| 12:24:24 | * | gradha joined #nimrod |
| 12:30:35 | * | SirSkidmore left #nimrod ("WeeChat 0.4.0") |
| 12:31:10 | * | [1]Endy joined #nimrod |
| 12:34:21 | * | Endy quit (Ping timeout: 264 seconds) |
| 12:34:22 | * | [1]Endy is now known as Endy |
| 12:46:20 | * | comex quit (*.net *.split) |
| 12:46:21 | * | reactormonk quit (*.net *.split) |
| 12:53:09 | * | XAMPP quit (*.net *.split) |
| 12:53:11 | * | tumak quit (*.net *.split) |
| 12:53:12 | * | fowl quit (*.net *.split) |
| 12:53:14 | * | Trix[a]r_za quit (*.net *.split) |
| 12:53:34 | * | gradha quit (*.net *.split) |
| 12:53:35 | * | Boscop quit (*.net *.split) |
| 13:12:19 | * | JStoker quit (*.net *.split) |
| 13:12:19 | * | Araq quit (*.net *.split) |
| 13:12:22 | * | mal`` quit (*.net *.split) |
| 13:12:23 | * | apotheon quit (*.net *.split) |
| 13:12:27 | * | Amrykid quit (*.net *.split) |
| 13:12:28 | * | Roin quit (*.net *.split) |
| 13:12:30 | * | Zor quit (*.net *.split) |
| 13:12:35 | * | Associat0r quit (*.net *.split) |
| 13:12:35 | * | silven quit (*.net *.split) |
| 13:12:45 | * | Endy quit (*.net *.split) |
| 13:12:46 | * | q66 quit (*.net *.split) |
| 13:12:53 | * | nihathrael quit (*.net *.split) |
| 13:12:53 | * | dom96 quit (*.net *.split) |
| 13:12:57 | * | EXetoC quit (*.net *.split) |
| 13:14:10 | * | mario-goulart quit (*.net *.split) |
| 13:20:16 | * | Reisen joined #nimrod |
| 13:27:09 | * | apotheon joined #nimrod |
| 13:27:09 | * | mal`` joined #nimrod |
| 13:27:09 | * | Zor joined #nimrod |
| 13:27:09 | * | Roin joined #nimrod |
| 13:27:09 | * | Amrykid joined #nimrod |
| 13:27:09 | * | q66 joined #nimrod |
| 13:27:09 | * | mario-goulart joined #nimrod |
| 13:27:09 | * | Araq joined #nimrod |
| 13:27:09 | * | JStoker joined #nimrod |
| 13:27:09 | * | silven joined #nimrod |
| 13:27:09 | * | dom96 joined #nimrod |
| 13:27:09 | * | nihathrael joined #nimrod |
| 13:27:09 | * | Endy joined #nimrod |
| 13:27:09 | * | Boscop joined #nimrod |
| 13:27:09 | * | gradha joined #nimrod |
| 13:27:09 | * | reactormonk joined #nimrod |
| 13:27:09 | * | comex joined #nimrod |
| 13:27:09 | * | Trix[a]r_za joined #nimrod |
| 13:27:09 | * | fowl joined #nimrod |
| 13:27:09 | * | tumak joined #nimrod |
| 13:27:34 | * | Reisen quit (Changing host) |
| 13:27:35 | * | Reisen joined #nimrod |
| 13:39:53 | * | EXetoC joined #nimrod |
| 13:48:11 | * | XAMPP joined #nimrod |
| 13:48:11 | * | XAMPP quit (Changing host) |
| 13:48:11 | * | XAMPP joined #nimrod |
| 14:52:38 | * | OrionPK joined #nimrod |
| 15:00:51 | * | BitPuffin_ joined #nimrod |
| 15:57:53 | * | [1]Endy joined #nimrod |
| 16:01:57 | * | Endy quit (Ping timeout: 268 seconds) |
| 16:01:57 | * | [1]Endy is now known as Endy |
| 16:08:57 | * | BitPuffin_ quit (Read error: Connection reset by peer) |
| 16:55:56 | * | DAddYE joined #nimrod |
| 17:02:50 | OrionPK | hoy fowl, you about? |
| 17:10:07 | * | Associat0r joined #nimrod |
| 17:10:07 | * | Associat0r quit (Changing host) |
| 17:10:07 | * | Associat0r joined #nimrod |
| 17:58:44 | dom96 | hi |
| 18:19:37 | * | Sergio965 joined #nimrod |
| 18:31:58 | * | Endy quit (Ping timeout: 276 seconds) |
| 19:04:18 | * | Endy joined #nimrod |
| 19:27:31 | * | Associat0r quit (Quit: Associat0r) |
| 19:35:47 | Araq | hi dom96 |
| 19:58:23 | fowl | OrionPK, hi |
| 19:58:26 | fowl | OrionPK, whats up |
| 19:58:57 | OrionPK | yo.. i got your sdl_skeleton working in os x without much modification |
| 19:58:59 | dom96 | hey Araq |
| 19:59:41 | OrionPK | the other one, sdl_gui? wont compile. it's getting unexpected identifiers for the colors (white, yellow etc) |
| 20:00:08 | OrionPK | on windows, I couldn't get SDL to statically link |
| 20:00:23 | OrionPK | because SDL makes a macro out of main |
| 20:00:31 | fowl | OrionPK, not a big deal, i was thinking about taking the static linking stuff out anyways |
| 20:00:39 | fowl | if just dynamic works on windows thats fine |
| 20:00:42 | Araq | --nomain |
| 20:00:43 | OrionPK | might be for the best |
| 20:01:39 | fowl | irt sdl_gui, i started doing an sdl2 colors module but i think i ended up just making a toSDLcolor() like the stdlib graphics module has so you could just use the stdlib colors module |
| 20:01:40 | OrionPK | araq I still need a main somewhere, right? SDL will make one and then try to call whatever entry point I specify |
| 20:02:20 | OrionPK | gotcha fowl |
| 20:02:57 | fowl | then of course sdl2 is still weird like using the int-packed color in some places and using the struct in others |
| 20:03:02 | OrionPK | I dont have pkg_config set up on my mac, so I excluded that line, and thats all I did to get sdl_skeleton working |
| 20:03:02 | fowl | notably sdl_gui |
| 20:03:53 | Araq | OrionPK: --nomain + .emit ftw |
| 20:04:31 | OrionPK | I'll give that a try next time I get a chance araq, thanks |
| 20:04:49 | OrionPK | seems hacky though :P |
| 20:05:19 | OrionPK | SDL just seems to expect a specific format for the main function, and the main function nimrod emits by default doesnt fit it I guess |
| 20:05:55 | OrionPK | (only for windows, iphone and android) |
| 20:06:30 | Araq | nimrod emits an ANSI C main |
| 20:06:47 | Araq | perhaps that's not good enough for SDL but frankly |
| 20:07:11 | Araq | if they fucked up even basic main, I don't care about sdl 2 |
| 20:07:17 | OrionPK | *shrug* I don't have an opinion either way, but SDL expects this: |
| 20:07:18 | OrionPK | int main(int argc, char *argv[]) |
| 20:07:57 | Araq | allegro used to do the same for main and it was a PITA |
| 20:08:24 | Araq | and I'm tired of people who program libraries in C for best interoperability and yet know nothing about interop |
| 20:08:35 | OrionPK | would be better if they just said "hey, make sure to call these initialization functions before you do anything else" |
| 20:08:37 | EXetoC | >.< |
| 20:08:39 | OrionPK | rather than hijack your entry point |
| 20:08:44 | Araq | try to influence the 'main' that Freepascal generates for instance |
| 20:09:14 | Araq | it's a bloody stupid idea |
| 20:09:25 | EXetoC | OrionPK: seems like the same thing, only more confusing |
| 20:09:28 | EXetoC | oh well |
| 20:10:08 | gradha | it's hard to provide forward source compatibility from DOS based code on a platform which requires a WinMain entry point, that was all the reason for the macro tricks |
| 20:10:23 | gradha | but yeah, the Allegro guys learned the lesson, I'm surprised the sdl guys didn't |
| 20:10:32 | fowl | OrionPK, what does sdl_main do anyways |
| 20:10:39 | fowl | it just called sdl_init() right |
| 20:10:56 | OrionPK | not sure |
| 20:10:57 | fowl | i wonder why its needed for static linking and not dynamic |
| 20:11:01 | OrionPK | i'm only looking at the header |
| 20:11:09 | fowl | yea me too |
| 20:11:23 | fowl | though i have the source right here, im trying to do like 5 other things atm :/ |
| 20:25:07 | gradha | it's troublesome that JoinPath uses AltSep, but on unix this is defined as "/" |
| 20:25:50 | Araq | why, gradha? |
| 20:25:50 | gradha | dos/windows paths are not handled correctly then when used as input |
| 20:26:44 | Araq | ah you mean it should pick the char that makes the path consistent? |
| 20:27:05 | Araq | btw, gradha xmltree exports a 'kind' proc and TXmlNodeKind |
| 20:27:12 | gradha | I can imagine a situation where a dos/windows configuration file with relative paths ends up on unix and breaks |
| 20:27:47 | Araq | but therefore we have UnixToNativePath, gradha |
| 20:28:09 | Araq | the paths in the config file should use / |
| 20:28:20 | Araq | and then translated to the native path |
| 20:29:49 | gradha | that's confusing, what's the reason for wrapping the field k with a kind proc? is the field expected to change? |
| 20:30:14 | Araq | I think it's a misguided attempt to provide information hiding |
| 20:30:32 | Araq | many old modules do stuff like that |
| 20:31:33 | * | Endy quit (Ping timeout: 248 seconds) |
| 20:36:21 | * | Endy joined #nimrod |
| 20:40:21 | EXetoC | is there a generic way of getting a set of all the members for some enum? |
| 20:40:46 | Araq | for x in myenum ? |
| 20:40:59 | Araq | {low(myenum)..high(myenum)} ? |
| 20:41:35 | gradha | does the second one work for sparse enums? |
| 20:42:01 | Araq | I don't know |
| 20:42:33 | Araq | it might, the range '..' doesn't check for holes I think |
| 20:42:46 | gradha | I guess it depends on how/what EXetoC is going to use the resulting set |
| 20:42:49 | EXetoC | yeah, will try the former as well |
| 20:44:17 | EXetoC | ok 'for' iterates over holes as well |
| 20:46:29 | Araq | that's a feature, right? :P |
| 20:46:55 | Araq | enums with holes are second class citizens anyway; they only exists for C interop |
| 20:48:30 | gradha | we should mark what parts of the language are second class so people can laugh/point at them |
| 20:49:02 | gradha | this could spawn into a "first class Nimrod" subset of the language |
| 20:53:15 | EXetoC | Araq: that's what I'm dealing with. I just want to check if the value returned by a C function is present in some enumerator set |
| 20:55:38 | Araq | you also should ensure the C function always checks malloc's return value, EXetoC |
| 20:55:39 | EXetoC | by the way, the order requirement might be a problem in this case, because I don't think that OpenGL for example guarantees that some symbolic error code must be bigger or smaller than another |
| 20:56:21 | Araq | extra points if it also checks whether there is stack space left to call another function |
| 20:57:03 | Araq | what do you mean, "nobody does that and the C standard doesn't offer a way to do that" |
| 20:57:04 | EXetoC | Araq: I'm not in control of the actual function bodies in this case, but yeah sure |
| 20:57:27 | EXetoC | wut |
| 20:57:35 | * | Araq laughs at C code that pretends to care about correctness |
| 20:58:07 | gradha | Araq: you should start the asm.c effort, which would be an improved subset of C for people caring to implement languages on top of it |
| 20:58:32 | Araq | gradha: C-- already exists |
| 20:58:45 | * | Endy quit (Ping timeout: 248 seconds) |
| 20:58:47 | OrionPK | question; how come I cant do import math; math.pow(x, y) (I get "undeclared identifier 'math'") |
| 20:58:59 | Araq | it's been replaced by LLVM |
| 20:59:14 | gradha | can you check the stack there before calling a function? |
| 20:59:45 | Araq | gradha: I could register a signal handler for that ... |
| 21:00:16 | Araq | OrionPK: no idea |
| 21:00:24 | gradha | so when you are out of stack and your signal gets called... can it do anything at all without stack? |
| 21:00:40 | Araq | signal handlers have their own stack iirc |
| 21:01:18 | gradha | the point would be to do something in the stack that is about to overflow, isn't it? otherwise it's just a custom abort() |
| 21:01:33 | Araq | yep. custom abort |
| 21:01:40 | OrionPK | araq bug? |
| 21:03:34 | Araq | OrionPK: obviously 'import math; math.pow' works for me, you need to give more context |
| 21:04:00 | OrionPK | I'll boil it down into an example, give me a few.. |
| 21:05:58 | gradha | the C-- mailing list is cool, people are integrating it with algol 68 |
| 21:06:50 | OrionPK | araq works on os X, but not windows |
| 21:07:52 | OrionPK | https://gist.github.com/onionhammer/5937254 |
| 21:09:11 | Araq | OrionPK: what is the exact error message? |
| 21:09:25 | OrionPK | Error: undeclared identifier: 'math' |
| 21:09:46 | Araq | looks like your windows nimrod is broken then |
| 21:10:20 | OrionPK | im up to date with head |
| 21:11:24 | Araq | could be duplicate/variant of bug #497 |
| 21:13:05 | gradha | meh, the c-- guys have given up hope and consider llvm the portable asm they were aiming for |
| 21:15:34 | gradha | the nimrod forum registers more activity than the c-- mailing list |
| 21:15:55 | gradha | OTOH it's great to read a few dozen posts and realize you have covered four years of their timeline |
| 21:17:03 | Araq | c-- is an academic project afaik; so people are more interested in writing papers about it than creating working software |
| 21:24:59 | gradha | time for cake |
| 21:25:09 | EXetoC | endsWith($enumerator, "(invalid data!)") :> |
| 21:26:42 | EXetoC | gradha: ok, but it better not contain any sugar. that shit is bad for ya! |
| 21:26:51 | Araq | EXetoC: do you know about: type TMyEnum = distinct cint; const ba = TMyEnum(20) |
| 21:27:14 | EXetoC | hm, might as well just eat proper food then |
| 21:28:07 | gradha | EXetoC: just ate all the proper food I had |
| 21:28:27 | Araq | same here, but I still have beer :P |
| 21:38:29 | EXetoC | Araq: yeah, but I want to group the symbolic constants together |
| 21:38:48 | EXetoC | I'm not going to expose untyped C stuff to the users, that's madness! |
| 21:39:25 | EXetoC | actually, that's slightly more typed, but it's not good enough :> |
| 21:39:45 | EXetoC | what you suggested that is |
| 21:40:28 | Araq | *shrug* it's still grouped due to the distinct type that is not used for anything else |
| 21:41:03 | Araq | and syntactically it can be grouped in a single 'const' but I know what you mean |
| 21:41:36 | EXetoC | yeah but I'm pedantic, and it's not like I have a deadline or anything, so I don't have to care about diminishing returns :p |
| 21:43:24 | Araq | these days programmers mostly turn off their brains and are overly concerned about aesthetics instead |
| 21:44:40 | EXetoC | it's a good quality to have when writing libs |
| 21:44:54 | EXetoC | I bet I would be really good at writing software for the nuclear industry! |
| 21:45:07 | Araq | I bet you wouldn't |
| 21:45:53 | EXetoC | so negative :> |
| 21:46:02 | Araq | you still like dynamic binding :P |
| 21:46:31 | Araq | but there ain't no such thing in Ada Spark |
| 21:47:29 | Araq | there is no heap either, say hello to good old global arrays |
| 21:49:11 | Araq | oh btw try to make your data structures immutable in such a setting; I'll have a good laugh in the meantime |
| 21:56:53 | EXetoC | I don't think I said that |
| 21:58:03 | Araq | EXetoC: sorry, I'm not really talking about you; I'm having fun about the redditors who think they know software "best practices" |
| 22:04:00 | EXetoC | oh. well we talked about that before |
| 22:04:48 | EXetoC | most people use bad languages after all |
| 22:05:31 | Araq | it's not about bad vs good languages |
| 22:06:33 | Araq | it's about that people know nothing about semantics and mistakenly like dynamic binding and despise global variables |
| 22:13:50 | EXetoC | sure, but it's easy to just settle with whatever 'class' provides |
| 22:20:36 | nihathrael | Hi everyone, is there an example available of using startProcess and streams to communicate with a process? |
| 22:21:24 | Araq | nihathrael: that's incredibly deadlock prone due to unix's fixed sized IO buffers, better avoid it if you can |
| 22:21:50 | nihathrael | so for CAAS I should rather use the tcp version? |
| 22:22:36 | Araq | for CAAS it might work good enough I don't know; gradha ? |
| 22:23:27 | dom96 | I would use sockets. |
| 22:23:47 | Araq | dom96: ok thanks |
| 22:27:13 | gradha | nihathrael: I implemented idetools caas mode using stdout |
| 22:28:06 | gradha | in https://github.com/gradha/the_hyperlink_vs_nimrod I start the caas server then feed it commands |
| 22:28:56 | gradha | of course you can also look at nimrod's tests/caasdriver.nim, which tests idetools |
| 22:29:47 | gradha | it's smaller and with less hacks |
| 22:34:54 | nihathrael | thanks! I'll take a look at that. |
| 22:36:25 | OrionPK | syntax highlighter having issues https://github.com/gradha/the_hyperlink_vs_nimrod/blob/master/the_hyperlink_vs_nimrod.nim#L157 |
| 22:37:44 | Araq | OrionPK: blame dom96 for that ;-) |
| 22:38:16 | dom96 | yeah, blame me. Without me there would be no syntax highlighting at all. |
| 22:38:19 | OrionPK | tut tut |
| 22:38:48 | gradha | without dom96 nimrod might still be implemented in C for all we know |
| 22:39:34 | * | alexandrus joined #nimrod |
| 22:39:34 | EXetoC | you're implemented in C! |
| 22:40:16 | Araq | hi alexandrus, welcome |
| 22:40:22 | alexandrus | hi |
| 22:40:37 | EXetoC | you could be. how do I know you're not a bot? |
| 22:40:47 | EXetoC | but you're doing useful stuff, so maybe it doesn't matter |
| 22:41:21 | alexandrus | yeah, i am the monkey coder of the year...you know xD |
| 22:42:09 | Araq | I think EXetoC meant gradha, alexandrus |
| 22:42:21 | alexandrus | oh:-) |
| 22:42:35 | gradha | C processes like to listen to kpop while crunching on cake |
| 22:44:18 | EXetoC | c(:)-< |
| 23:13:29 | * | alexandrus quit () |
| 23:14:03 | EXetoC | he'll be back! |
| 23:14:15 | Araq | yeah I know |
| 23:14:21 | gradha | who? |
| 23:14:34 | Araq | alexandrus |
| 23:15:45 | gradha | at least he lasted some time |
| 23:18:57 | Araq | he had to go to sleep ;-) |
| 23:20:41 | EXetoC | probably |
| 23:21:05 | Araq | well he told me that personally |
| 23:21:40 | nihathrael | when using suggest in caas, sometimes I get lines like this: "sugskVartextRender/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../lib/crt1.o: In function `_start':", why is it mixing output like that? |
| 23:22:38 | gradha | weird, looks like stdout and stderr are getting mixed somehow |
| 23:23:12 | gradha | does it happen also for other idetools commands or only suggest? |
| 23:23:32 | dom96 | there is a flag which mixes them |
| 23:24:17 | nihathrael | "serve", "--server.type:stdin", "--verbosity:0", "--hints:off" is what i'm using as args |
| 23:25:14 | gradha | look at the startProcess call, by default options is set to poStdErrToStdOut, try passing an empty set there |
| 23:25:15 | dom96 | it's a default param for startProcess |
| 23:27:41 | * | Sergio965 quit (Ping timeout: 256 seconds) |
| 23:27:56 | nihathrael | great, that fixed that |
| 23:30:54 | nihathrael | behaving a little weird, going totally nuts with multiple thousand results on the first suggest call, and followup calls don't return anything |
| 23:31:58 | gradha | idetools is still being worked on, if you find weird behaviours it would be good if you could reproduce a small test case and add it to the caas suite |
| 23:32:47 | nihathrael | not sure it's a problem with idetools, might be me doing studip stuff as well :) |
| 23:33:16 | gradha | or maybe you are hitting a buffer limit, try repeating the query and see if you still get the same amount of output |
| 23:35:12 | gradha | queries you make are usually small and fit in a buffer, so the output shouldn't be a problem as long as you consume it all until an empty line |
| 23:35:52 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 23:35:55 | nihathrael | it's quite weird. it will return tons of output on the first try and on the second query there will be no output at all |
| 23:36:20 | nihathrael | https://github.com/nihathrael/Aporia/commit/df678985404ec33b7f6693ad8756bd150af903e7 |
| 23:36:48 | nihathrael | this is my first rough implementation, maybe I screwed up somewhere with the streams |
| 23:38:31 | gradha | if you don't get blocked it means suggest is failing |
| 23:41:44 | gradha | just tried duplicating the query/expected result of tests/caas/suggest-compile.txt and caas mode still works ok, but of course you could have hit a new problem |
| 23:43:22 | nihathrael | you can see my entire log here: http://up.unknown-horizons.org/f/?a=v&id=506&n=log.txt (4MB) |
| 23:43:29 | nihathrael | I execute the same query 2 times |
| 23:43:41 | nihathrael | first try gives me around 40k lines of output |
| 23:43:49 | nihathrael | second time 0 |
| 23:44:32 | nihathrael | download link: http://up.unknown-horizons.org/f/?a=d&id=506&n=log.txt (most browsers won't show everything) |
| 23:46:26 | gradha | hmm... are the Saving/Copying lines generated by Aporia? |
| 23:46:35 | nihathrael | yea |
| 23:47:09 | nihathrael | it's basically copying the project to make sure currently edited (potentially unsaved) files are not saved over the real files |
| 23:47:24 | gradha | it's clearly not the problem here, but in the future the caas server might check timestamps to know if it has to "recompile" internally the file |
| 23:48:20 | gradha | try to replicate tests/caas/suggest-compile.txt inside Aporia |
| 23:49:17 | gradha | for simplicity you could simply open tests/caas/main_dirty.nim and perform the suggest query there |
| 23:49:55 | gradha | if that fails to repeat the information there's something wrong, at least repetition works on that small case for me |
| 23:50:08 | nihathrael | yea saem problem |
| 23:51:04 | nihathrael | http://pastebin.com/SGhfkbtQ |
| 23:51:47 | gradha | then it's time to debug the communication, currently the vim plugin does something weird like that too for me: it answers the first time, then remains silent |
| 23:56:13 | nihathrael | Ok, I'll see if I can find some time tomorrow to look into it. Time for bed now. Thanks for your help, very appreciated! |
| 23:56:31 | gradha | no worries, btw I replicated your problem here from the commandline |
| 23:56:51 | gradha | may look into it tomorrow, good night |
| 23:58:56 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |