Camelia, the Perl 6 bug

IRC log for #parrot, 2012-03-13

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 kid51 joined #parrot
00:09 trey joined #parrot
00:33 pjcj joined #parrot
01:20 dngor joined #parrot
02:30 bacek_at_work ~~
03:29 dalek parrot: 9317840 | luben++ | src/pmc/hashiterator.pmc:
03:29 dalek parrot: add shift_integer() VTABLE to HashIterator PMC in order to
03:29 dalek parrot: make possible iterating over Hash PMCs with int keys
03:29 dalek parrot: review: https://github.com/parrot/parrot/commit/9317840523
03:29 dalek Heuristic branch merge: pushed 150 commits to parrot/opsc_llvm by luben
03:54 travis-ci joined #parrot
03:54 travis-ci [travis-ci] parrot/parrot#151 (master - 9317840 : luben): The build was fixed.
03:54 travis-ci [travis-ci] Change view : https://github.com/parrot/par​rot/compare/59b35dc...9317840
03:54 travis-ci [travis-ci] Build details : http://travis-ci.org/parrot/parrot/builds/851927
03:54 travis-ci left #parrot
03:57 preflex joined #parrot
04:20 preflex_ joined #parrot
04:26 japhb joined #parrot
04:57 dngor joined #parrot
05:05 nnunley joined #parrot
05:09 losinggeneration joined #parrot
05:20 losinggeneration joined #parrot
05:35 nnunley joined #parrot
05:50 dngor joined #parrot
07:57 dngor joined #parrot
08:12 alin joined #parrot
08:32 mj41 joined #parrot
08:39 lucian joined #parrot
09:23 lucian joined #parrot
09:36 alin joined #parrot
09:44 moritz oh hai
09:44 moritz I'm looking for a fast and compact way to turn a memory location into a string
09:45 moritz it doesn't really matter how the result looks like, just that it's unambiguous
10:18 fperrad joined #parrot
10:24 arnsholt moritz: sprintf("%p", ptr) might be more or less what you want
10:25 moritz arnsholt: is that fast?
10:25 moritz I mean, in parrot, at the PIR level?
10:26 arnsholt Oh, I was assuming C, sorry
10:26 moritz my question wasn't very clear either, sorry :-)
10:26 arnsholt printf should be reasonably quick, so if you can get the pointer from PIR and send it to printf that should work
10:27 arnsholt If you get the memory location as just an int, I guess sprintf("%x") would be much the same
10:28 moritz though that's not quite as compact as I hoped for
10:28 arnsholt Or sprintf("%08x") if you want fixed width
11:19 marcel_r joined #parrot
11:38 benabik joined #parrot
11:38 benabik G'morning, #parrot!
11:48 particle joined #parrot
12:04 mtk joined #parrot
12:26 PacoAir joined #parrot
12:44 dalek nqp/b64-lookup-table: 1859ad1 | moritz++ | src/6model/base64.c:
12:44 dalek nqp/b64-lookup-table: base64 decoding now uses a lookup table, not repeated branching
12:44 dalek nqp/b64-lookup-table: review: https://github.com/perl6/nqp/commit/1859ad17ef
12:51 preflex joined #parrot
13:07 dngor joined #parrot
13:40 dngor joined #parrot
13:50 dngor_ joined #parrot
14:29 dngor joined #parrot
15:00 dngor joined #parrot
15:03 wagle joined #parrot
15:12 JimmyZ joined #parrot
15:16 davidfetter joined #parrot
15:22 mj41 joined #parrot
15:46 lateau joined #parrot
15:47 dalek rakudo/nom: fee8919 | moritz++ | src/core/Exception.pm:
15:47 dalek rakudo/nom: awesomize error message for numeric parameters
15:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/fee8919e67
15:52 johbar_work joined #parrot
15:56 bluescreen joined #parrot
15:59 dngor joined #parrot
16:01 Psyche^ joined #parrot
16:18 contingencyplan joined #parrot
16:40 Psyche^ joined #parrot
16:46 lateau Can I include other files in parrot-nqp? I tried -I/path/to/file and 'use' but they didn't work.
16:48 fperrad_ joined #parrot
16:48 lateau I want to run test file named 'grammar.t' and grammar.t needed to knows about Test::Grammar class in grammar.pm.
17:24 dukeleto ~~
17:55 mj41 joined #parrot
18:02 japhb What is the current state of thread and AIO support in Parrot?
18:07 dukeleto japhb: nine is working hard on the "threads" branch
18:07 dukeleto japhb: which builds on green_threads
18:08 japhb Will 'threads' be a more advanced green_threads or native threads or a multiplexing thread scheduler?
18:08 japhb And what about AIO and/or event loop support?
18:10 dukeleto japhb: http://niner.name/Hybrid_Th​reads_for_the_Parrot_VM.pdf
18:10 dukeleto japhb: ask nine++
18:10 dukeleto japhb: also, welcome back :)
18:11 japhb :-)
18:12 japhb I forget, is there a message-bot in here?
18:12 dmalcolm joined #parrot
18:12 benabik msg japhb Yes.
18:12 aloha OK. I'll deliver the message.
18:12 nine Good evening #parrot
18:12 japhb Ah, hello nine!
18:13 japhb nine, I'm going to go look at your hybrid threads PDF, but in the mean time, are you also the one to answer my questions about AIO and event loop support?
18:13 nine japhb: no, concentrating on threading for now.
18:14 japhb OK, fair enough, thanks.
18:20 nine japhb: if you have any questions on threading or suggestions after reading, just shoot
18:21 japhb nine, thank you, will do!
18:36 japhb nine, is my PDF viewer failing, or are some sections of the paper intentionally empty (such as 2.3 Erlang)?
18:38 nine japhb: it's just not yet finished
18:38 japhb nine, OK, gotcha.
19:14 japhb nine, on page 14, you say "In other words all data is owned by the thread creating it and only the owner may write to it.  Other threads have only read access."  Do you mean 'interpreter' there rather than 'thread'?  (That's what I'm gathering from the next paragraph, I just want to make sure I'm not missing something important.)
19:17 nine japhb: I use 'interpreter' and 'thread' interchangibly since there's a 1:1 relationship between them. But I'm quite unsure when to use which and there are probably lots of places where readability could be improved
19:21 japhb nine, OK, so you're following the convention 'task' = virtual thread, 'interpreter' 1:1 'thread' = OS thread
19:21 nine japhb: yep
19:25 nine I added a note with regard to that
19:28 japhb Good idea.
19:34 cotto #ps time
19:34 autark joined #parrot
19:35 benabik cotto: Thanks for the reminder.  :-D
19:37 johbar_work joined #parrot
19:47 awwaiid joined #parrot
20:17 nine Why is pmc_constants in CallContext a PMC ** and not a PMC *?
20:17 benabik someone was being clever?
20:18 benabik It's a pointer to an array?
20:18 benabik Oh!
20:18 fperrad joined #parrot
20:18 benabik It's probably an array of pointers to PMCs.
20:18 nine (gdb) p *((Parrot_CallContext_attributes*)​call_object->data)->pmc_constants
20:18 nine $22 = PMC<FixedIntegerArray> = {[size] = 0, [int_array] = 0x0}
20:25 benabik Yeah, That's probably printing the first element in the array.
20:25 benabik In the array of constants.
20:26 nine ah of course
20:26 benabik It's actually `PMC *pmc_constants[]`.  Not sure if there's a portability reason it's a ** instead
20:26 nine got confused by the first element being an array
20:26 benabik They're equivelant to C.
20:26 benabik I think FIAs are used for type information on calls...
20:27 benabik So the first constant will probably often be a FIA
20:27 nine FIA?
20:27 nine Ah FixedIntegerArray
20:27 benabik FixedIntegerArray
20:27 benabik :-D
20:28 nine where do they come from?
20:30 benabik The PCC ops like get_params and set_returns use an integer array for the type (INSP, slurpy, named, etc) information
20:30 benabik The FIAs generally get built by IMCC
20:30 benabik And stored in the packfile.
20:32 nine So probably the reason why these pmc_constancs leak from the main thread to the sub threads is that I access the packfile unproxied (since they are read only anyway)
20:39 benabik Seems likely.
20:39 * benabik has a meeting, bb in :30 - 1:00
20:41 nine That's a tough one. Since packfiles are no PMCs, I cannot just put a Proxy in front of them
20:47 mj41 joined #parrot
20:53 cotto nine: there are PMCs that wrap packfiles
20:55 nine cotto: but I'd have to change Sub so sub->seg would be this wrapper instead of a PackFile_ByteCode*. Sounds scary.
21:01 nine Can these constants be accessed by the user? E.g. can they be put into a register?
21:06 * benabik is back
21:08 benabik nine: I don't _think_ you can with IMCC, but I don't think there's anything else limiting it.
21:08 benabik Actually, you probably can with the Sub consts at least.
21:09 nine Well that would rule out just using them as is and letting the GC ignore them
21:11 benabik nine: You can get the Sub constants and the result of :immediate subs back out into registers.
21:12 benabik .const 'Sub' $P0 = 'main'
21:13 benabik huh.  I sent IMCC into a loop or somethin.g
21:13 nine Ok, so definitely no go on using them as is. I fear my only choice will be to clone the packfiles into the new threads.
21:13 benabik :-/
21:16 bluescreen_ joined #parrot
21:18 benabik So I managed to throw IMCC for a loop with the following line: .const 'FixedIntegerArray' $P0 = 'test'
21:19 benabik test is the name of an :immediate sub, which I thought I was invoking.
21:19 benabik But instead it's trying to build a FIA from the string "test", I think.
21:22 benabik "Doctor, doctor it hurts when I declare an invalid FixedIntegerArray"
21:23 benabik Neat.  IMCC has a custom hand-rolled parser for FixedIntegerArrays.
21:25 nine sounds....nice ;)
21:26 benabik I'm just confused why it keeps trying to reparse it when it fails.
21:28 dngor joined #parrot
21:35 benabik Hm.
21:38 PacoAir joined #parrot
21:42 * benabik wonders if anyone uses this "build an FIA in IMCC" bit.
21:49 donaldh joined #parrot
21:52 benabik Innnnnteresting.
21:57 nine msg whiteknight pmc_constants still leak from the main thread to the sub threads because I access the packfile unproxied (as they are no PMCs). Since the constants may be used quite anywhere, I cannot just ignore them in the GC. The only solution I can see is to deep clone packfiles into the sub threads on thread creation. Any better ideas?
21:57 aloha OK. I'll deliver the message.
21:57 benabik nine: You should only need to clone the pmc_constants.
21:58 benabik I don't see a reason to clone the strings, bytecode, etc.
22:01 nine benabik: yes, but the pointer to the PackFile_ConstTable is in the PackFile_ByteCode struct. So I need to clone the PackFile_ByteCode to be able to change the pointer. Either I do a really deep clone of this struct or I fix GC to only touch some parts if running on a sub thread
22:08 Timbus joined #parrot
22:09 nine Well, I'll have a closer look tomorrow. Good night, #parrot
22:12 japhb o/
22:44 tadzik \o
22:45 brambles_ joined #parrot
22:48 jsut_ joined #parrot
22:48 brambles joined #parrot
22:50 dngor joined #parrot
23:07 dngor joined #parrot
23:20 bacek_at_work ~~
23:20 tadzik ~~
23:20 bacek_at_work nine, I think "constants" should be marked only in main interp. Child interps can use shallow copies.
23:30 benabik joined #parrot
23:32 dngor joined #parrot
23:35 whiteknight joined #parrot
23:57 whiteknight good evening, #parrot
23:58 whiteknight msg nine Can we set a flag on the PMC header for "only GC mark on the main thread"? Then we can mark PMCs which might leak but are managed only by the main thread
23:58 aloha OK. I'll deliver the message.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced