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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!