| 00:00:08 | dom96 | Varriount: I'll give you an account on the VPS anyway though. Send me the username and pass you want for it through PM. |
| 00:01:10 | * | superfunc quit (Ping timeout: 250 seconds) |
| 00:01:25 | Varriount | dom96: Yeah, but the credit isn't indefinate |
| 00:05:11 | dom96_ | it'll last for long though |
| 00:14:21 | dom96 | Varriount: ok, can you PM me this info please? |
| 00:15:10 | Varriount | dom96: 100$ credit will last for a little less than 2 years. |
| 00:15:43 | Varriount | Also, I'd rather not have something tied directly to my github account - what if I get run over by a bus? |
| 00:15:43 | dom96 | ok, can you send that info? |
| 00:15:55 | Varriount | dom96: What info? |
| 00:16:07 | dom96 | <dom96> Varriount: I'll give you an account on the VPS anyway though. Send me the username and pass you want for it through PM. |
| 00:16:07 | * | Trustable quit (Quit: Leaving) |
| 00:19:54 | Varriount | dom96: What is the server hosted on? |
| 00:20:01 | Varriount | Erm, the website, I mean. |
| 00:20:40 | flaviu | Varriount: Digital Ocean |
| 00:21:16 | NimBot | Araq/Nimrod devel ee9c70e Araq [+0 ±2 -0]: user defined pragmas work for generics instantiated in different modules |
| 00:21:47 | Varriount | flaviu: Then does the website have ipv6 support? |
| 00:23:02 | flaviu | Ask dom96, I only pretend to know everything :P |
| 00:23:20 | Araq | I'm renaming the git repo to Nim now |
| 00:23:23 | Araq | any objections? |
| 00:24:18 | dom96 | why now? |
| 00:24:26 | dom96 | 0.10.0 hasn't been released yet |
| 00:26:19 | Araq | yes, but we can't do the release all at once anyway |
| 00:26:36 | Araq | I'd like to encourage people to already update their Nimble packages |
| 00:26:57 | Araq | now that bigbreak is devel the exe is already named "nim" |
| 00:28:22 | * | Fran__ joined #nimrod |
| 00:29:02 | Araq | well? |
| 00:29:03 | Joe_knock | is 0.10.0 being released soon? |
| 00:29:05 | * | Jehan_ joined #nimrod |
| 00:29:31 | Joe_knock | Wait, I don't make much contribs, so my voice doesn't matter :P |
| 00:29:48 | Araq | true but raise your voice anyway |
| 00:30:26 | * | Francisco quit (Ping timeout: 256 seconds) |
| 00:31:12 | Joe_knock | dom96: makes a valid point. Changing the name to nim should be "step before final release" commit. |
| 00:31:43 | Joe_knock | But its just a name. Doesn't matter too much. |
| 00:33:51 | Varriount | Araq: Will changing the repo name change the git url? |
| 00:33:59 | Araq | yes |
| 00:34:33 | Varriount | Then it might be better to do this on friday, when most of us will have time to spend picking up stuff. |
| 00:34:45 | Araq | ok |
| 00:34:56 | Araq | I want to release this weekend anyway |
| 00:35:24 | Varriount | Araq: Everything that uses the old git url will need to be changed. koch, website, instructions, etc. |
| 00:36:00 | flaviu | Varriount: Github redirects automaticlly it iirc |
| 00:36:35 | Jehan_ | I have to say that C keeps surprising me. |
| 00:37:06 | Varriount | Jehan_: Howso? |
| 00:37:06 | Jehan_ | If you have a call to a non-existent function in a static inline function, the program will still compile cleanly. |
| 00:37:31 | Varriount | Eh... what happens if you run the program? |
| 00:37:36 | Jehan_ | It'll just run. |
| 00:37:59 | Jehan_ | I stumbled over it when trying to compile with nim cpp --threads:on |
| 00:38:11 | Jehan_ | There's a reference to pthread_mutex_timedlock() |
| 00:38:17 | Jehan_ | Which does not exist on some platforms. |
| 00:38:33 | Jehan_ | But because it's hidden away in a static inline function and never used, it compiles on C. |
| 00:38:46 | Jehan_ | Whereas on C++, you'll get a compilation error. |
| 00:39:02 | Varriount | Jehan_: Is this ensured under the C standard? |
| 00:39:08 | Jehan_ | Varriount: I have no idea. |
| 00:39:37 | Jehan_ | But both gcc and clang allow it. |
| 00:39:49 | Jehan_ | clang will generate a warning for the missing prototype by default, but that's all. |
| 00:44:55 | Jehan_ | Araq: It looks like you've renamed branches, PRs w.r.t devel again? |
| 00:45:09 | Araq | yes |
| 00:45:28 | Araq | argh |
| 00:45:35 | Araq | I hunted a phantom again |
| 00:45:52 | Araq | mexport2b.nim vs mexportb.nim |
| 00:46:23 | Araq | seriously, these multi module tests are annoying |
| 00:49:39 | Joe_knock | Wait, wouldn't renaming the git repo break older versions of nimrod? |
| 00:49:54 | Joe_knock | or rather, installing older versions |
| 00:50:01 | Varriount | Joe_knock: Howso? |
| 00:50:20 | Araq | not really, but we have official releases for a reason |
| 00:50:24 | Jehan_ | Varriount: I think he refers to scripts that rely on the existing URL. |
| 00:50:40 | Varriount | Which is why such scripts should be changed. |
| 00:50:55 | Araq | and nimrod-lang.org will be kept for some time |
| 00:51:00 | flaviu | Github redirects old repo names |
| 00:51:19 | Araq | Github is really a nice piece of software |
| 00:51:25 | flaviu | https://github.com/blog/1508-repository-redirects-are-here |
| 00:51:29 | Araq | there. I did it. |
| 00:51:49 | Araq | for the first time in history I praised some software. |
| 00:54:29 | NimBot | Araq/Nimrod devel 9500dfc Araq [+0 ±4 -0]: fixes #1612 |
| 00:56:00 | * | darkf joined #nimrod |
| 00:56:44 | Jehan_ | Interesting, the compiler can't compile itself with --threads:on, but … because of some really obscure error. |
| 00:57:06 | Varriount | Araq: Oh my goodness. Are you feeling alright? You don't have a fever? |
| 00:58:40 | Varriount | Jehan_: But the compiler can compile itself in C++ mode. |
| 00:58:50 | Jehan_ | Varriount: That's a different issue now. |
| 00:59:06 | Jehan_ | For some reason, --threads:on messes up type inference. |
| 00:59:12 | Jehan_ | And I have no clue (yet) why. |
| 00:59:47 | Araq | Jehan_: error in rstgen.nim? |
| 00:59:54 | Jehan_ | Basically, there's a call to sort in rstgen that uses system.cmp |
| 00:59:55 | Jehan_ | Yeah. |
| 01:00:04 | Jehan_ | If you change it to system.cmp[string], everything works. |
| 01:00:36 | Araq | that seems like yet another symbol table bug |
| 01:00:58 | Araq | --threads:on changes hash insertion order pseudo-randomly |
| 01:01:13 | Araq | and the compiler picks a different 'cmp' as default |
| 01:01:16 | Jehan_ | Hmm. |
| 01:01:19 | Araq | a serious bug |
| 01:01:22 | Varriount | Gah. I just had a horrid idea: A multi-threaded compiler. |
| 01:01:28 | Araq | but not really thread related |
| 01:01:41 | Jehan_ | Araq: Yeah, I mostly found it fascinating. |
| 01:01:46 | Araq | well that's what I think happens |
| 01:02:39 | Jehan_ | Varriount: Not all that bad if you do it right. |
| 01:02:50 | Jehan_ | After all, that's pretty much what make -j N does. |
| 01:03:11 | Varriount | Jehan_: Doesn't that spawn multiple processes though? |
| 01:03:21 | Jehan_ | Varriount: Correct. So? |
| 01:03:33 | Araq | Varriount: visual studio's C# compiler is multi-threaded I think |
| 01:04:03 | Jehan_ | Nothing says that a parallel program needs to have massive amounts of global shared state. |
| 01:04:25 | Jehan_ | That's mostly because of the atrociously poor support for thread-local data, historically. |
| 01:04:50 | Araq | I disagree slightly |
| 01:05:01 | * | q66 quit (Quit: Leaving) |
| 01:05:14 | Jehan_ | Araq: Well, there's more to it. But I think it's a big contributor. |
| 01:05:17 | Araq | thead-local vs global data is a minor issue. the heap itself is shared and continues to be. |
| 01:05:35 | Araq | for C, C++, C#, D etc. |
| 01:05:48 | Jehan_ | Araq: Controlling access to a shared heap (other than for a global GC) isn't hard. |
| 01:06:18 | Jehan_ | Liskov and Meyer did it in the 1980s. |
| 01:06:29 | Araq | not sure what you mean |
| 01:06:34 | Jehan_ | We've continued to ignore their lessons for three decades straight. |
| 01:06:45 | Jehan_ | Argus (concurrent CLU derivative), SCOOP for Eiffel. |
| 01:07:06 | Jehan_ | They had pretty much sorted out how to do the shared heap thing in a safe fashion. |
| 01:09:59 | * | boydgreenfield joined #nimrod |
| 01:11:40 | * | bjz_ quit (Ping timeout: 255 seconds) |
| 01:13:16 | Araq | I'm not sure I agree, but you know much more about these things |
| 01:14:40 | Jehan_ | I'm not saying that their solutions were optimal, but there were workable. |
| 01:14:46 | Jehan_ | they* |
| 01:15:18 | Araq | just one remark: when you say that OO lead to a natural solution (the monitor) for controlling concurrency |
| 01:15:55 | Araq | then I disagree. it wasn't OO, it was the abstract data type. |
| 01:17:34 | Jehan_ | Araq: Didn't say that. |
| 01:17:52 | Araq | well that's what I got from some of your forum posts |
| 01:18:19 | Jehan_ | OO has various aspects that often get mashed together. |
| 01:18:55 | Jehan_ | I believe I was very specifically referring to object-based programming (i.e. disregarding inheritance) rather than object-oriented programming for this particular case. |
| 01:20:11 | Jehan_ | Inheritance does not have much of an effect with respect to concurrency (well, not this aspect of it). |
| 01:20:20 | Araq | ah ok |
| 01:22:04 | * | ehaliewicz joined #nimrod |
| 01:26:05 | Araq | good night |
| 01:27:56 | * | ehaliewicz quit (Ping timeout: 255 seconds) |
| 02:00:47 | * | Joe_knock left #nimrod ("Leaving") |
| 02:10:03 | * | xenagi joined #nimrod |
| 02:11:29 | * | mko quit (Ping timeout: 258 seconds) |
| 02:39:58 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 02:41:48 | * | Jesin quit (Quit: Leaving) |
| 02:46:53 | * | Jesin joined #nimrod |
| 02:54:56 | * | brson quit (Quit: leaving) |
| 03:07:15 | * | Jehan_ quit (Quit: Leaving) |
| 03:12:08 | * | AMorpork is now known as AFKMorpork |
| 03:30:54 | * | flaviu quit (Ping timeout: 244 seconds) |
| 03:45:22 | * | Hakaslak quit (Ping timeout: 256 seconds) |
| 03:47:01 | * | kemet joined #nimrod |
| 03:47:53 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 03:54:11 | * | kemet quit (Remote host closed the connection) |
| 04:01:05 | * | Boscop quit (Ping timeout: 264 seconds) |
| 04:28:21 | * | dsallbee joined #nimrod |
| 04:28:39 | * | dsallbee is now known as dallbee |
| 04:31:35 | * | dallbee left #nimrod (#nimrod) |
| 04:33:17 | * | mko joined #nimrod |
| 04:34:25 | * | ehaliewicz joined #nimrod |
| 05:43:40 | * | pscha joined #nimrod |
| 05:46:10 | * | pscha quit (Remote host closed the connection) |
| 06:02:43 | * | darkf_ joined #nimrod |
| 06:04:52 | * | xenagi quit (Quit: Leaving) |
| 06:05:10 | * | darkf quit (Ping timeout: 265 seconds) |
| 06:05:56 | * | darkf_ is now known as darkf |
| 06:08:12 | * | BlaXpirit joined #nimrod |
| 06:08:22 | * | boydgreenfield joined #nimrod |
| 06:10:00 | * | kemet joined #nimrod |
| 06:30:46 | * | darkf_ joined #nimrod |
| 06:32:43 | * | darkf quit (Ping timeout: 272 seconds) |
| 06:33:41 | * | darkf_ is now known as darkf |
| 06:40:54 | * | bjz joined #nimrod |
| 07:13:19 | * | kemet quit (Ping timeout: 265 seconds) |
| 07:27:04 | * | skroll1 quit (Ping timeout: 250 seconds) |
| 07:30:28 | * | Trustable joined #nimrod |
| 07:34:41 | * | gokr_ joined #nimrod |
| 07:42:41 | * | skroll1 joined #nimrod |
| 07:46:54 | * | mko quit (Quit: Bye.) |
| 08:04:36 | * | ehaliewicz quit (Read error: Connection reset by peer) |
| 08:08:31 | gokr | Varriount: There? |
| 08:18:42 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 08:26:06 | * | lyro joined #nimrod |
| 08:46:40 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 09:01:39 | * | nande quit (Read error: Connection reset by peer) |
| 10:48:34 | * | EXetoC quit (Read error: Connection reset by peer) |
| 10:52:34 | * | AFKMorpork is now known as AMorpork |
| 11:00:23 | * | rpag quit (Ping timeout: 240 seconds) |
| 11:25:29 | * | BitPuffin joined #nimrod |
| 11:30:56 | * | BlaXpirit joined #nimrod |
| 12:11:42 | * | rpag joined #nimrod |
| 12:19:10 | * | kemet joined #nimrod |
| 12:31:14 | * | BitPuffin quit (Ping timeout: 256 seconds) |
| 12:36:30 | * | Jehan_ joined #nimrod |
| 12:52:54 | woodgiraffe | I'm trying to index a seq via an uint8 and it fails, AFAIS the manual mentions all ordinal types to be legit indexes, uint8 is said to be an ordinal type. - e.g. http://ix.io/f4u - Any pointers on what I'm doing wrong? |
| 13:11:40 | Jehan_ | seqs are indexed with ints, you can index an array[uint8, T] with a uint8, though. |
| 13:12:40 | Jehan_ | Oh, wait, that's probably actually an unsigned <-> int issue. |
| 13:12:55 | Jehan_ | small ints are automatically converted to ints, unsigned ints not. |
| 13:13:22 | woodgiraffe | Shall I bug-report? |
| 13:13:46 | Jehan_ | I don't think it's a bug. |
| 13:13:59 | * | kemet quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) |
| 13:14:01 | Jehan_ | unsigneds and ints don't autoconvert to each other for a reason. |
| 13:15:27 | woodgiraffe | Well, then the manual errs |
| 13:15:41 | woodgiraffe | On array and seqs: "They can be indexed by any ordinal type." |
| 13:16:40 | Jehan_ | Hmm. |
| 13:16:59 | Jehan_ | No, it only says that for arrays. |
| 13:17:15 | woodgiraffe | Notice in my example I'm using an array |
| 13:17:42 | woodgiraffe | Doesn't seem to make a difference. |
| 13:17:44 | Jehan_ | It works with array[uint8, T] |
| 13:18:43 | Jehan_ | Index type has to be declared, otherwise it's a subrange of int. |
| 13:19:30 | Jehan_ | Can't index an array[0..9,string] with an enum, either, or an array[SomeEnumType, T] with an int. |
| 13:19:49 | woodgiraffe | I see |
| 14:01:15 | * | gokr quit (Ping timeout: 265 seconds) |
| 14:27:21 | * | gokr joined #nimrod |
| 14:33:20 | * | Jehan_ quit (Quit: Leaving) |
| 14:45:53 | * | dom96_ quit (Ping timeout: 240 seconds) |
| 14:47:38 | * | darkf quit (Quit: Leaving) |
| 14:53:14 | * | kemet joined #nimrod |
| 14:56:52 | * | gokr_ quit (Ping timeout: 256 seconds) |
| 15:03:03 | * | gokr quit (Ping timeout: 265 seconds) |
| 15:18:30 | * | BitPuffin joined #nimrod |
| 15:19:58 | * | BitPuffin quit (Remote host closed the connection) |
| 15:31:03 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 15:33:12 | * | vendethiel joined #nimrod |
| 15:34:33 | * | Jehan_ joined #nimrod |
| 15:38:15 | * | BitPuffin joined #nimrod |
| 15:50:04 | * | Jehan_ quit (Quit: Leaving) |
| 15:55:07 | * | Sembei quit (Ping timeout: 272 seconds) |
| 15:55:23 | * | Jehan_ joined #nimrod |
| 15:59:52 | * | Jehan_ quit (Ping timeout: 245 seconds) |
| 16:00:14 | * | untitaker quit (Ping timeout: 245 seconds) |
| 16:06:02 | * | untitaker joined #nimrod |
| 16:13:55 | * | EastByte joined #nimrod |
| 16:13:55 | * | EastByte____ quit (Read error: Connection reset by peer) |
| 16:23:13 | * | boydgreenfield joined #nimrod |
| 16:35:35 | NimBot | nimrod-code/nimforum new_async dd61f5b Dominik Picheta [+0 ±3 -0]: Implemented side bar. |
| 16:58:52 | * | TylerE joined #nimrod |
| 17:08:39 | * | Matthias247 joined #nimrod |
| 17:14:31 | * | johnsoft quit (Ping timeout: 265 seconds) |
| 17:14:56 | * | johnsoft joined #nimrod |
| 17:16:46 | * | Jehan_ joined #nimrod |
| 17:18:47 | * | dom96_ joined #nimrod |
| 17:22:18 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 17:24:41 | onionhammer | dom96 around? |
| 17:24:50 | onionhammer | dom96_ |
| 17:25:58 | onionhammer | dom96 i want to use the new async stuff for httpclient, but it looks like you neglected to include any way to add headers (extraHeaders) on the procs which return Futures |
| 17:29:58 | * | kemet quit (Ping timeout: 255 seconds) |
| 17:35:21 | * | gokr joined #nimrod |
| 17:38:13 | dom96_ | yeah, newAsyncHttpClient should have that param. |
| 17:41:41 | * | q66 joined #nimrod |
| 17:42:49 | * | irrequietus joined #nimrod |
| 17:43:41 | onionhammer | dom96_ i think it has 'headers' but its private |
| 17:43:53 | dom96_ | yeah, there should be a setter & getter for that I think |
| 17:43:55 | dom96_ | make a PR |
| 17:56:16 | dom96_ | oh no, headers is used for response headers I think |
| 17:56:25 | dom96_ | add an reqHeaders field |
| 17:56:59 | * | Sembei joined #nimrod |
| 17:58:32 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 17:58:47 | onionhammer | I think it'd probably make sense to not just use strings |
| 17:59:07 | onionhammer | the user shouldnt have to know anything about needing an empty line between headers and content etc |
| 18:01:04 | onionhammer | bigbreak was merged into devel? |
| 18:01:06 | onionhammer | ? |
| 18:14:20 | * | boydgreenfield joined #nimrod |
| 18:14:40 | onionhammer | I think all that needs to be done is marking PAsyncHttpClient.headers as public.. |
| 18:15:35 | onionhammer | or else you have to add [] and []= for them |
| 18:28:59 | * | rpag quit (Ping timeout: 245 seconds) |
| 18:30:30 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 18:31:12 | * | johnsoft joined #nimrod |
| 18:32:54 | * | tillzy joined #nimrod |
| 18:34:35 | * | Joe_knock joined #nimrod |
| 18:46:27 | * | boydgreenfield quit (Ping timeout: 250 seconds) |
| 18:46:56 | * | gokr quit (Ping timeout: 256 seconds) |
| 18:52:58 | Araq | onionhammer: yup. there is no bigbreak anymore |
| 19:15:56 | Joe_knock | How did that happen? Did you abandon it? |
| 19:16:31 | Araq | it got merged into devel |
| 19:16:43 | Araq | and to avoid confusion I removed bigbreak afterwards |
| 19:17:07 | Joe_knock | oh, but it still is a bigbreak in terms of breaking the current packages? |
| 19:17:15 | Araq | yes |
| 19:35:11 | * | brson joined #nimrod |
| 19:35:14 | * | gokr_ joined #nimrod |
| 19:36:09 | * | enurlyx joined #nimrod |
| 19:37:15 | gokr_ | How can i do -p:../foo in a cfg file? |
| 19:37:34 | Araq | --path: "../foo" |
| 19:37:51 | Araq | you should be able to use -p, but single character commands are bad style |
| 19:37:52 | gokr_ | oh, quotes, cool |
| 19:38:17 | Araq | ping Jehan_ |
| 19:45:02 | * | tillzy quit (Quit: tillzy) |
| 19:48:51 | * | brson quit (Ping timeout: 250 seconds) |
| 19:58:25 | * | xtagon joined #nimrod |
| 19:59:56 | * | Jehan_ quit (Quit: Leaving) |
| 20:01:20 | enurlyx | gokr_: Thank you for the nice articles. I like to read them :) Also I think it is good for nim |
| 20:01:57 | ldlework | Did anyone post my article to the reddit? |
| 20:02:04 | ldlework | npe. |
| 20:17:06 | gokr_ | thanks :) |
| 20:21:13 | * | nullmove joined #nimrod |
| 20:24:53 | nullmove | Does threadpool have any doc page? |
| 20:25:12 | * | Jehan_ joined #nimrod |
| 20:25:51 | * | BitPuffin joined #nimrod |
| 20:28:25 | * | bjz quit (Ping timeout: 260 seconds) |
| 20:29:45 | Araq | nullmove: nah, I forgot to add it to the docgen process ... |
| 20:30:21 | Araq | ping Jehan_ |
| 20:30:36 | Jehan_ | Araq: pong? |
| 20:31:08 | Araq | here's the problem: in threadpool.nim:156 |
| 20:31:54 | Araq | the thread may need to wait until the thread that owns the ToFreeQueue clears the queue |
| 20:32:15 | Araq | this is done in proc slave via cleanFlowVars |
| 20:32:50 | Araq | however, it's possible that 'slave' sleeps in line 265 |
| 20:33:07 | Araq | and then boom, deadlock. |
| 20:33:28 | Araq | however, only the owning thread is allowd to do cleanFlowVars |
| 20:33:31 | Jehan_ | Umm, why release before wait in that function? |
| 20:34:03 | Araq | because it's the proper way to do it? |
| 20:34:36 | Jehan_ | No, pthread_cond_wait() must happen inside pthread_mutex_lock() … phtread_mutex_unlock(). |
| 20:35:30 | Jehan_ | "The pthread_cond_wait() and pthread_cond_timedwait() functions are used to block on a condition variable. They are called with mutex locked by the calling thread or undefined behaviour will result." |
| 20:35:59 | * | bjz joined #nimrod |
| 20:36:21 | Jehan_ | Also, whatever you're waiting on, pthread_cond_wait() may get spurious signals. |
| 20:36:56 | Jehan_ | Should always be in a loop: while not condition_represented_by_condvar: wait(condvar, mutex) |
| 20:39:15 | Araq | hrm yes, that should indeed by 'await' |
| 20:39:42 | Araq | but the other issue remains |
| 20:39:51 | Araq | *indeed be |
| 20:40:19 | Jehan_ | acquire(q.lock) |
| 20:40:19 | Jehan_ | while not (q.len < q.data.len): |
| 20:40:19 | Jehan_ | wait(q.empty, q.lock) |
| 20:40:19 | Jehan_ | waited = true |
| 20:40:19 | Jehan_ | q.data[q.len] = fv.data |
| 20:40:20 | Jehan_ | inc q.len |
| 20:40:20 | Jehan_ | release(q.lock) |
| 20:40:35 | Jehan_ | Araq: Okay, now on to the other problem. |
| 20:43:58 | * | gokr joined #nimrod |
| 20:48:46 | Jehan_ | My gut feeling would be to put the ToFreeQueue in a shared heap so that it can be resized when needed. |
| 20:50:23 | * | bjz quit (Ping timeout: 250 seconds) |
| 20:50:30 | Araq | that dosn't solve anything |
| 20:50:38 | Araq | the GC_unref is the important operation |
| 20:50:51 | Araq | and that needs to be done by the thread who owns the 'ref' |
| 20:51:00 | * | bjz joined #nimrod |
| 20:51:22 | Araq | but hrm |
| 20:51:32 | Jehan_ | Yup. But this way, you don't have to wait for there to be enough space in the queue. |
| 20:52:03 | Jehan_ | The alternative is to keep all flow vars in a linked list of ptrs. |
| 20:52:14 | Jehan_ | With a lock for each thread to access the list. |
| 20:52:50 | Jehan_ | When you want to put a flowvar in the thread's to free queue, you acquire the lock, update the ptr, then release the lock. |
| 20:53:40 | Jehan_ | This actually seems to be the (relatively) simplest solution overall. |
| 20:55:39 | * | bjz quit (Ping timeout: 245 seconds) |
| 20:55:48 | onionhammer | is there a functiokn for parsing a URL or detecting if a string is a url built in somewhere? |
| 20:56:58 | Araq | onionhammer: parseUrl, parseUri, use the index please |
| 20:58:56 | onionhammer | i did use the index |
| 20:59:04 | onionhammer | there wre some 300 matches for "url" |
| 20:59:09 | onionhammer | and most of them had to do with curl |
| 20:59:14 | Araq | this is not a simple solution either, Jehan_ |
| 20:59:15 | onionhammer | we need a better index |
| 20:59:24 | Jehan_ | Araq: Why not? |
| 20:59:31 | Araq | we need a trimmed down index, I agree, onionhammer |
| 20:59:47 | Araq | Jehan_: because the flowVar is a 'ref' |
| 21:00:03 | Jehan_ | Araq: Correct. Which is why you make it a linked list of ptrs. |
| 21:00:37 | Araq | hrm I think I don't get your idea |
| 21:03:36 | Trustable | @Araq: Is csources default branch now compatible with Nim bigbreak? |
| 21:04:06 | Araq | Trustable: csources branches reflect nim branches |
| 21:04:21 | Trustable | good, I will test now |
| 21:04:26 | Araq | so csources has a devel that can build the devel branch |
| 21:04:43 | Araq | note that master is still at 0.9.x |
| 21:04:50 | Jehan_ | Araq: Give me an hour or so, I can write up the code. |
| 21:05:11 | Jehan_ | Probably less, but having occasional RL interrupts. |
| 21:05:11 | Araq | ok |
| 21:09:53 | Trustable | bootstrap works, good job :) |
| 21:12:24 | nullmove | Hi Araq , could you explain the disjoin check inside the parallel statement in a somewhat simpler terms? |
| 21:13:23 | Araq | nullmove: er ... that's highly experimental stuff which uses a home grown proof engine |
| 21:14:07 | nullmove | I mean what is the general idea? |
| 21:14:23 | Araq | that you want to split your data into disjoint parts |
| 21:14:31 | * | brson joined #nimrod |
| 21:14:44 | Araq | and every part is passed over to a worker thread |
| 21:15:58 | * | brson_ joined #nimrod |
| 21:18:41 | Araq | the idea is that the compiler cannot do the partitioning for you because that depends on a non-existant cost model |
| 21:19:06 | Araq | but it can at least check the partitioning you chose is logical |
| 21:19:23 | nullmove | ah ok |
| 21:20:07 | * | brson quit (Ping timeout: 265 seconds) |
| 21:20:43 | * | irrequietus quit () |
| 21:24:16 | * | brson_ quit (Quit: leaving) |
| 21:24:32 | * | brson joined #nimrod |
| 21:27:30 | onionhammer | yay https://github.com/onionhammer/onion-nimrod/blob/master/pushbullet/pushbullet.nim |
| 21:29:49 | * | nullmove quit (Ping timeout: 246 seconds) |
| 21:35:10 | Jehan_ | Araq: Okay, I have an implementation, but the problem seems to be actually that the GC_unref() occurs at all. |
| 21:35:41 | Araq | Jehan_: that's another issue. I fixed that, but didn't push yet |
| 21:35:53 | Araq | unless you mean something else |
| 21:35:59 | Jehan_ | Ah, alright. |
| 21:36:17 | Jehan_ | Let me clean it up and put it where you can see it. |
| 21:39:00 | * | nande joined #nimrod |
| 21:39:11 | Varriount | Meeeep |
| 21:39:32 | Varriount | gokr: I'm here now. |
| 21:39:41 | gokr | Hehe |
| 21:40:10 | gokr | So yeah, you are working on getting buildbot up? |
| 21:40:52 | * | delian66 quit (Ping timeout: 240 seconds) |
| 21:40:58 | gokr | I think I am going to do the same for our internal use - I started with Jenkins but... well. |
| 21:41:16 | Varriount | gokr: Yeah. I was planning on working on the main configuration script. |
| 21:41:45 | Jehan_ | Araq: https://github.com/rbehrends/nimrod/tree/flowvar-queue |
| 21:42:04 | Varriount | gokr: There's still a lot of work that needs to be done - I haven't started on the build configurations for manual builds, such as csource and installer generation. |
| 21:42:15 | * | delian66 joined #nimrod |
| 21:42:21 | Jehan_ | First commit in that branch contains all the changes. |
| 21:43:21 | gokr | Varriount: I will fire up our box anyway, and perhaps install buildbot on it for our use. Whenever you reach the spot where I can configure it to do some slave work - let me know. |
| 21:43:27 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 21:43:47 | gokr | Where is your box btw? Europe? |
| 21:44:06 | Varriount | gokr: At the moment, I'm using my laptop, which is located in the US |
| 21:44:29 | gokr | Doesn't matter of course, just curious. |
| 21:44:33 | Varriount | Eventually, the plan is to use the vps hosting the (current, old) build bot. |
| 21:44:45 | gokr | We have most of our infrastructure at cloudsigma, Las Vegas. |
| 21:45:26 | Jehan_ | Araq: What I'm wondering, though, is whether the main thread ever calls cleanFlowVars. |
| 21:45:36 | Jehan_ | As far as I can tell, the only call occurs in the worker loop. |
| 21:45:52 | Varriount | gokr: I'm going to make a repository on github that contains the master and slave configuration files for the builders. |
| 21:46:01 | gokr | oki |
| 21:46:02 | Joe_knock | Varriount: Digital Ocean? |
| 21:47:02 | Varriount | Joe_knock: Yes. |
| 21:47:14 | Varriount | Unless someone has a better idea. |
| 21:47:19 | Joe_knock | There are cheaper options |
| 21:48:09 | * | BitPuffin joined #nimrod |
| 21:48:53 | Varriount | Joe_knock: List them then. Again, if there are better options, I'll happily take them. |
| 21:49:20 | Joe_knock | https://vultr.com (Should I be giving referral links?) |
| 21:49:40 | Joe_knock | Vultr is basically cheaper, with the same quality. |
| 21:50:45 | Araq | Jehan_: no, but the main thread never returns a flow var either |
| 21:50:53 | Araq | it's never a worker thread |
| 21:51:03 | Araq | also your patch can't work |
| 21:51:09 | Jehan_ | Araq: Oh? |
| 21:51:21 | Jehan_ | For what it's worth, I did test it ... |
| 21:51:47 | * | Mat3 joined #nimrod |
| 21:51:49 | Araq | the flow var is a 'ref' belonging the thread that spawned |
| 21:51:51 | Mat3 | hi all |
| 21:51:59 | Araq | it can be collected any time |
| 21:52:08 | Araq | and then the list is corrupted |
| 21:52:17 | Jehan_ | Gotcha. |
| 21:52:30 | Jehan_ | So, need a separate list for that, no big deal. |
| 21:53:34 | Araq | well but it is, kind of |
| 21:53:49 | Araq | you gonna need allocShared for that |
| 21:53:53 | Jehan_ | Right. |
| 21:54:24 | Jehan_ | And obviously, right now, allocShared() is a bit of a bottle neck because of the global lock. |
| 21:55:03 | Jehan_ | No, actually, there is another solution. |
| 21:55:19 | Varriount | Joe_knock: Right now I'm trying to write an application for https://crissic.net/open-source_free-hosting |
| 21:55:21 | Jehan_ | When we allocated the flowvar, we allocate another space for the queue. |
| 21:55:55 | Jehan_ | Which gets freed along with the flowvar. |
| 21:56:16 | Jehan_ | Eh, nevermind. That's again in the wrong thread. |
| 21:57:13 | Araq | he he he, it is suprisingly tricky to get right |
| 21:57:30 | Joe_knock | wow, they're as cheap as the other options. Underlying hardware could be ... |
| 21:57:45 | Jehan_ | I just want to point out that I've been arguing for multiple shared heaps since forever. :) |
| 21:57:53 | Araq | the flowvar is from the spawn'ed thread, but the data it keeps alive comes from the worker thread |
| 21:58:00 | Joe_knock | What OSS project are you working on? Varriount |
| 21:58:11 | Jehan_ | Because they trivialize this kind of problem. |
| 21:58:27 | Araq | yeah but on the other hand we only need to solve it once |
| 21:58:38 | Araq | plus the issue is rather academic |
| 21:58:42 | Jehan_ | Well, it's a more general problem. |
| 21:59:07 | Araq | we can make the array big enough and simply quit when it overflows |
| 21:59:25 | Jehan_ | Sharing data between threads is a pretty common desire in multi-threaded applications. |
| 21:59:59 | Araq | or try to save the current solution |
| 22:00:27 | Araq | the current solution is cool and can be made to work |
| 22:00:40 | Jehan_ | The simplest solution is to have a queue that lives on the shared heap and simply allocates only infrequently. |
| 22:00:50 | Jehan_ | So it doesn't become a bottleneck. |
| 22:01:11 | Jehan_ | Basically, where each node can hold a few hundred fv references. |
| 22:01:57 | * | flaviu joined #nimrod |
| 22:02:02 | Araq | with some timed await in the slave we can make it free the queue periodically |
| 22:02:14 | Araq | and that solves the problem too |
| 22:02:46 | Jehan_ | Timed waiting is always a portability problem, though. |
| 22:02:55 | Jehan_ | It's a solvable portability problem, but one all the same. |
| 22:03:06 | flaviu | Joe_knock: The Nim buildbot |
| 22:03:24 | Araq | well the thing is, I can only produce the problem with ridiculously small queue sizes |
| 22:03:46 | Jehan_ | Also has the bad habit of keeping applications on laptops and mobile alive when they don't need to be, thus draining battery life. |
| 22:04:06 | Araq | i can't imagine it can happen when the queue size is 512 |
| 22:04:37 | Araq | that means you have that many pending flowvars and at the same time will never again wake up the thread to do some work |
| 22:04:39 | Jehan_ | Araq: I think you'd have to write code to trigger it, but I think it could be done. |
| 22:05:05 | Araq | thinking about it ... |
| 22:05:20 | Araq | it should simply wake up the owning thread ... |
| 22:05:29 | * | Araq feels stupid |
| 22:05:33 | Jehan_ | Heh. |
| 22:05:50 | Jehan_ | Yeah, that should solve it. |
| 22:06:10 | Jehan_ | You'll just have to distinguish between what it's being woken up. Or have a no-op task for this purpose. |
| 22:06:18 | Araq | yeah |
| 22:06:19 | Jehan_ | * up for |
| 22:07:19 | Varriount | Joe_knock: Uh, this one? |
| 22:08:06 | Araq | I have to say this thing is remarkably deterministic (on windows at least) |
| 22:08:26 | Araq | quite a joy to debug |
| 22:11:53 | onionhammer | www.eoleary.me/Blog/Pushbullet |
| 22:14:26 | flaviu | onionhammer: Looks interesting, but 10 seconds isn't long at all. Perhaps 10m would bet better? :P |
| 22:22:10 | onionhammer | lol. it was an example |
| 22:27:23 | Araq | hrm I wonder if we need q.empty at all then |
| 22:27:42 | Araq | if finished simply wakes up the thread anyway |
| 22:27:55 | Araq | and pretends to hand a task over to it |
| 22:27:59 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:29:07 | Araq | ah but then there is no "task finished" event |
| 22:29:33 | Araq | so that would be the 'empty' event |
| 22:34:11 | * | mko joined #nimrod |
| 22:35:34 | * | Mat3 quit (Quit: Verlassend) |
| 22:36:03 | Varriount | Araq: What would you say were major influences for the design of Nim? |
| 22:36:24 | Araq | the FAQ answers that |
| 22:36:50 | Joe_knock | Python |
| 22:36:55 | Joe_knock | Pascal |
| 22:36:59 | Joe_knock | Turbo Pascal |
| 22:37:16 | Joe_knock | PHP |
| 22:37:19 | Joe_knock | Perl |
| 22:37:26 | Araq | "The language borrows heavily from (in order of impact): Modula 3, Delphi, Ada, C++, Python, Lisp, Oberon." |
| 22:39:30 | Araq | though now I would argue the Delphi influence is stronger than the Modula 3 influence |
| 22:40:40 | Araq | Joe_knock: PHP and Perl are not in the list |
| 22:40:52 | Joe_knock | I kid I kid. |
| 22:48:08 | ldlework | :) |
| 22:48:11 | * | mko quit (Remote host closed the connection) |
| 22:55:41 | * | Fran__ quit (Ping timeout: 264 seconds) |
| 22:57:05 | * | Fran__ joined #nimrod |
| 22:57:19 | * | mko joined #nimrod |
| 23:00:06 | * | enurlyx quit (Quit: Leaving.) |
| 23:00:43 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 23:01:20 | * | BitPuffin joined #nimrod |
| 23:07:50 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 23:08:06 | * | johnsoft joined #nimrod |
| 23:09:21 | * | AMorpork is now known as AFKMorpork |
| 23:20:55 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:22:00 | Araq | well this "wakeup" thing produces deterministic crashes |
| 23:22:07 | Araq | and I have no idea why |
| 23:22:38 | dom96_ | onionhammer: No. Did you not read what I said? the headers field is used for response headers. |
| 23:23:54 | Jehan_ | Araq: What did you change? |
| 23:24:14 | Jehan_ | I.e. is there a diff somewhere that I could look at? |
| 23:24:24 | Araq | let me push it |
| 23:24:57 | dom96_ | <Varriount> Eventually, the plan is to use the vps hosting the (current, old) build bot. |
| 23:25:06 | dom96_ | No, the plan is to use our new Digital Ocean VPS. |
| 23:27:50 | NimBot | Araq/Nimrod devel b558626 Araq [+1 ±1 -0]: broken attempt to fix queue exhaustion |
| 23:28:08 | Araq | I use the tconvexhull test case |
| 23:37:21 | * | AFKMorpork is now known as AMorpork |
| 23:41:33 | Joe_knock | What does the build bot do? dom96 |
| 23:41:40 | Joe_knock | dom96_: ^^ |
| 23:41:50 | flaviu | Joe_knock: It runs the tests on each commit |
| 23:42:06 | Joe_knock | flaviu: Unit tests, etc. ? |
| 23:42:12 | flaviu | Yes, the unit tests |
| 23:42:37 | dom96_ | Joe_knock: it bootstraps the compiler and runs the test suite (koch tests) |
| 23:42:48 | flaviu | And tests for the general operation of the compiler |
| 23:43:15 | flaviu | Joe_knock: Just an example: http://build.nimrod-lang.org/commits/linux-x86/634852e23df4/testresults.html |
| 23:43:31 | Joe_knock | So the build bot will pull the commit onto the server, run the tests and send out "a log to say what tests passed/failed" ? |
| 23:47:58 | Araq | Joe_knock: yes and just to prevent rumors. we have such a thing for years now. |
| 23:48:49 | Araq | it's called "nimbuild". however dom96 has not the time to maintain it anymore and so Varriount is trying some alternative software |
| 23:51:03 | Joe_knock | Is this type of tool used for purposes of language/compiler assurance? |
| 23:52:34 | Jehan_ | Araq: Hmm, the acquire statement in cleanFlowVars seems to hang. |
| 23:53:03 | Araq | Jehan_: the thing is: it doesn't hang for me. it crashes. |
| 23:53:13 | Jehan_ | I think that's because the sending thread reacquires the lock before the receiving thread gets the message. |
| 23:53:29 | Jehan_ | Ah, I may have a different test case then. What are you using to test it? |
| 23:54:14 | Araq | nim c -r --threads:on tests/parallel/tconvexhull |
| 23:54:55 | Jehan_ | Okay, let me look at that. |
| 23:55:42 | Jehan_ | Hmm, crashes in GC_unref for me. |
| 23:56:17 | Araq | well I fixed that in that commit |
| 23:56:48 | * | Trustable quit (Quit: Leaving) |
| 23:56:53 | Araq | but you're right |
| 23:56:58 | Araq | if I disable that it works |
| 23:57:29 | Jehan_ | refcount seems to be zero if I print it. |
| 23:58:17 | Araq | oh yeah |
| 23:58:22 | Araq | my fix is totally wrong |
| 23:58:33 | Araq | it must not be a RootRef |
| 23:58:41 | Araq | cause that's then followed by the wrong GC |
| 23:58:52 | Araq | it needs to stay pointer |
| 23:59:12 | Araq | and we must make the codegen insert a GC_ref |