|
Parrot 4.7.0 "Hispaniolan" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 4 September 2012. |
|||
| dalek | rrot/rurban/threads_array_heap: 240885e | rurban++ | / (7 files): Dynamic threads_array in the heap, i.e. massive parallel multi-threading For what it's worth, this branch implements up to 16.000 threads (just an arbitrary limit) by allocating threads_array on the heap. I do not want to realloc this array on demand when a new task is created, I rather want it to be at the same location. What I'm not sure is if the tasks and threads need to be killed at interp teardown at all, or just be freed. Cancelling or terminating a thread is not really friendly. The current code passes all tests. |
00:34 | |
| rurban | Still Changelog entries needed? | 00:37 | |
| dalek | rrot: ad9a8e3 | rurban++ | ChangeLog: ChangeLog: note improved VALGRIND env |
00:43 | |
| rurban | I think that's it for the release. good luck | 00:51 | |
|
00:51
travis-ci joined
|
|||
| travis-ci | [travis-ci] parrot/parrot#563 (master - ad9a8e3 : Reini Urban): The build was fixed. | 00:51 | |
| [travis-ci] Change view : github.com/parrot/parrot/compare/3...9a8e33c7e6 | |||
| [travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2486813 | |||
|
00:51
travis-ci left
|
|||
| rurban | Coke: travis did not like my branch setup. How can we make it test threads and smoke-me branches? | 00:55 | |
|
01:08
elmex_ joined
|
|||
| dalek | rrot/rurban/preload-config-steps-gh833: e685dd0 | rurban++ | Configure.pl: preload only when debugging perl via -d As per jkeenans comment github.com/parrot/parrot/issues/83...nt-8634064 |
01:16 | |
| rrot/rurban/preload-config-steps-gh833: c4de4b4 | rurban++ | Configure.pl: [GH #833] preload only when debugging perl via -d As per jkeenans comment github.com/parrot/parrot/issues/83...nt-8634064 |
01:17 | ||
|
01:29
l3l1p joined
02:30
l3l1p joined
04:12
l3l1p joined
05:13
mdupont joined
06:00
awwaiid joined
06:21
rurban_mobile joined
|
|||
| nine | msg rurban Parrot_thread_destroy looks like a nice and tidy idea, but in its current form, I'm not sure it's actually helpful. You kill all foreign tasks but do not wait for them to actually exit. A currently running task would still run till the end of its timeslice. But you immediately go on to cancel all worker threads. Then you free the threads_array but not the thread's interpreters. Also the name Parrot_thread_destroy sounds to me like it would destroy one | 06:29 | |
| aloha | OK. I'll deliver the message. | ||
|
06:37
fperrad joined
|
|||
| nine | tadzik: would be interesting what ctx=0x88ed58 exactly is. Could it be a Proxy? Then the direct access is bound to fail. When that happens, it seems like a second distinct problem appears when trying to create the exception. Since I don't know anything about HLL stuff in Parrot, it can very well be that I overlooked something. | 06:40 | |
| tadzik | nine: I've no idea what that is | 07:03 | |
|
07:12
brrt joined
08:09
lucian joined
08:20
Psyche^ joined
11:23
JimmyZ joined
|
|||
| Coke | rurban: I have nothing to do with travis. talk to dukeleto | 12:44 | |
| My experience with travis is that it generates channel chatter when builds time out, and not much else. | 12:45 | ||
|
12:49
PacoAir joined
13:04
bluescreen joined
|
|||
| dalek | kudo/nom: 0973612 | moritz++ | src/core/Grammar.pm: Default to Mu for action methods that way fewer method names are prone to name conflicts, because Mu simply does not have as many methods as Any. But it is not a real fix |
13:27 | |
|
13:28
whiteknight joined
|
|||
| brrt | hi #parrot | 13:44 | |
| whiteknight | hello brrt | 13:58 | |
| good morning, #parrot | 13:59 | ||
| brrt | hello whiteknight | ||
|
14:05
benabik joined
14:29
l3l1p joined
|
|||
| brrt | wtf stupid linux-standard-base | 14:39 | |
|
14:55
fperrad joined
|
|||
| dalek | p: 4b84f41 | jonathan++ | docs/QASTMAP: Delete QAST migration roadmap. |
15:08 | |
|
15:43
dmalcolm joined
|
|||
| rurban | Coke: Sorry, mixed you up. Always do. | 15:52 | |
| nine: but how do we kill our threads now? Does the gc wait and kill them? I saw nothing. | 15:54 | ||
|
15:55
benabik joined
|
|||
| Coke | rurban: no worries. | 15:56 | |
| dalek | p: bba277c | jonathan++ | docs/qast.markdown: Start documenting the QAST nodes. |
16:03 | |
| rurban | whiteknight: Already done with the release? I wanted to add one more line to ChangeLog: + platforms - Fixed Solaris with gcc | 16:06 | |
| Better line: "+ Fixed broken int3 trap on Solaris with gcc." | 16:09 | ||
| whiteknight | rurban: I haven't seen the release go by yet. Alvis is doing it | ||
| alvis | rurban: Go ahead. I'm just now getting to the release. I have to first update the 4.6.0 docs. | 16:12 | |
| Coke | whiteknight: What's currently on your parrot plate? | 16:16 | |
| dalek | rrot: b6cf2d1 | rurban++ | ChangeLog: ChangeLog: Add int3 trap fix on Solaris with gcc [GH #583] |
16:19 | |
| rurban | Ah Alvis. I thought it was you. For Alvis it's 11:20am | 16:20 | |
| whiteknight | Coke: threads, but I can take more. What do you need? | 16:23 | |
|
16:28
benabik_ joined
|
|||
| Coke | Just asking. | 16:30 | |
| dalek | p: c0bb465 | jonathan++ | docs/qast.markdown: Document some more node types. |
16:31 | |
| rurban | whiteknight: you can look at readline on windows which returns now with added "\\r\\n" but should only add "\\n" | 16:35 | |
| commit f77643e9c9165dde47318717011983f5348413be | 16:36 | ||
|
16:36
benabik_ joined
|
|||
| rurban | I found it in t/src/threads_io.t | 16:36 | |
| whiteknight | rurban: Make a ticket? | ||
| rurban | I'm not sure what the proper behavior should be. This failing test is new. | 16:37 | |
| It came with threads. But I guess it was io_cleanupo1 which changed the behaviour. | 16:38 | ||
| github.com/parrot/parrot/issues/834 | |||
| Oh, a good one: github.com/parrot/parrot/issues/835 | 16:45 | ||
| I'll add it to t/pmc/bytebuffer.t | 16:47 | ||
| Coke | parrot has a several nqp-rx tickets that can probably be closed with a pointer to the nqp-rx repository, and a note that we're either removing it or upgrading to nqp. | 16:50 | |
|
16:50
davidfetter joined
|
|||
| rurban | hmm, I'm totally baffled. the #835 test fails if called as main, but works if called as function inside t/pmc/bytebuffer.t | 16:53 | |
| Maybe the buffers are reused and already big enough from the previous tests... | 16:54 | ||
| dalek | rrot/rurban/bytebuffer-resize-gh835: cd367ec | rurban++ | t/pmc/bytebuffer (2 files): Add bytebuffer resize tests for [GH #835] As it turns out adding the failing test to t/pmc/bytebuffer.t does not reveil any problem, but if called seperately as main it does. |
17:01 | |
| rurban | alvis: working on the release? | 17:02 | |
| Yesterday night I also improved pmc2c a lot by checking all the UNUSED macros and changing them to SHIM the pmc args. | 17:06 | ||
| It went from hundreds to zero warnings from clang. | 17:07 | ||
| I also added clang support to warnings. clang detects more than gcc | 17:08 | ||
|
17:12
rurban_mobile joined
17:16
tuxit joined
17:28
mdupont joined
|
|||
| dalek | rrot/rurban/pmc2c-unused-gh836: 60cfaca | rurban++ | lib/Parrot/Pmc2c/Method.pm: [GH #836] Improve parsing pmc2c UNUSED arguments UNUSED(arg) amcros are now detected in pmc bodies and change the argument declaration to SHIM(). Empty bodies with return 1; are now detected and the two args are SHIMed. UNUSED(interp) cause a new warning to be replaced by UNUSED(INTERP). |
17:30 | |
| rrot/rurban/pmc2c-unused-gh836: 6afb068 | rurban++ | config/auto/warnings.pm: warnings: Improve clang support clang requires warnings overrides for -Wno-parentheses-equality and adds -Wno-unused-result to src/ops/core_ops.c. (used in 29582199aef9ea9462 [GH #828] Optimize print_n/i and say_n/i) |
|||
| rrot/rurban/pmc2c-unused-gh836: a95f757 | rurban++ | config/gen/makefiles/root.in: Add ccwarn::src/ops/core_ops.c SUFFIX OVERRIDE for using (void)Parrot_io_write_b Added with 29582199aef9ea94622b4202aee129521bc |
|||
| rrot/rurban/pmc2c-unused-gh836: ef4b571 | rurban++ | src/ (3 files): Add more UNUSED() declarations to key.pmc and core.ops |
|||
| rurban | There's still a problem with pmc2c-unused-gh836 in null.pmc for derived methods | 17:31 | |
|
17:40
contingencyplan joined
18:09
benabik joined
|
|||
| nine | rurban: threads get killed on program exit. Your Parrot_thread_destroy is the first attempt to do real cleanup which might be nice in an embedding situation | 19:07 | |
| rurban | So the OS loader terminates the threads? I rewrote it slightly and seperated kill tasks from a later destroy interp's, terminate threads and free the array. | 19:09 | |
|
19:09
lucian joined
|
|||
| nine | Yes. Sounds like nice improvement. | 19:09 | |
| rurban | Please feel free to fix my naive implementation. | 19:15 | |
| dalek | rrot/rurban/threads_array_heap: 2bae6d7 | rurban++ | / (3 files): Seperate thread_kill from thread_destroy Rename Parrot_thread_destroy to Parrot_thread_destroy_all Add an earlier Parrot_thread_kill_all step, which kills the foreign tasks, and use the later Parrot_thread_destroy_all to cancel the threads, kill its interpreters and free the threads_array. I'm not sure if the scenario is sound and right but the tests pass. |
19:16 | |
|
19:22
benabik joined
|
|||
| dalek | rrot/rurban/threads_array_heap: 42bb405 | rurban++ | / (3 files): Do Parrot_thread_kill_all before Parrot_runcore_destroy Change Parrot_thread_destroy_all(interp) to Parrot_thread_destroy_all(NULL) No interp needed for the interp's in the global threads_array. |
19:34 | |
| rurban | I think killing those threads and destroying the interp's is a can of worms. Can there be be recursion? Which interp? But it needs to be done. Even without the heap change. | 19:42 | |
| nine | Shutting down an interp looks like scary business to me even without threading :) | 20:28 | |
| dalek | rrot: 7847e55 | alvis++ | / (12 files): The 4.8.0 Release |
21:21 | |
|
22:03
Khisanth joined
22:31
whiteknight joined
|
|||
| whiteknight | ayardly++ | 22:46 | |
|
23:00
lucian joined
23:18
alvis_ joined
23:33
lucian joined
|
|||