Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 25 August 2011.
benabik o/ 00:08
davidfetter \\<>/ 00:16
00:37 AzureStone joined 00:46 kid51 joined
kid51 ~~ 00:54
cotto: ping
cotto_work kid51: ping 01:01
er, pong
02:01 woosley joined
cotto_work allison: ping 02:08
allison: unping 02:20
02:23 jkitazawa joined 02:42 nbrown joined 02:43 dngor joined 03:03 rfw joined
dukeleto ~~ 04:39
cotto ~~ 04:50
dukeleto cotto: i am working on merging the m0 pull request that we got from nbrown++. Any objections? 04:51
cotto dukeleto, I haven't reviewed it yet. 04:56
so technically, I don't object
I'll look at it in a couple minutes. 04:57
looking now 05:01
dukeleto cotto: i found some small issues, which I already have fixed 05:04
cotto dukeleto, the C code is fine but I don't like the test duplication. I intended that there only be one M0 test suite and that it be used for all implementations.
dukeleto cotto: yes, i thought the same. Should I get rid of the test duplication, and just make the current tests run against both implementations?
cotto dukeleto, if you have the tuits, please do. 05:05
dukeleto cotto: i don't like the duplication either, but it makes it easy to run tests against on implementation or the other
cotto we can do that with makefile targets
make c_m0_tests
something like that
dukeleto cotto: yeah, that patch adds something like that, but also has test duplication 05:06
cotto: should me make the tests take an argument of which implementation binary to test against?
s/me/we/
cotto dukeleto, +1 as long as the argument isn't assumed to be a binary. (e.g. perl src/m0/perl5/m0_assembler.pl) 05:07
dukeleto cotto: passing arguments to tests doesn't interact well with running multiple tests via a harness 05:09
cotto: how do you feel about an env var? 05:10
cotto dukeleto, good point 05:11
I guess that's workable.
just don't tell greenpeace 05:12
dukeleto cotto: another issue: t/m0/integration.t runs every all the tests, but t/m0_c/integration.t only runs the test that the c implementation groks 05:13
cotto dukeleto, we either say that some failures are expected or take a page from the Perl 6 spec test and fudge tests. 05:15
or another option, if you have one
dukeleto cotto: i am fine with expected failures, so we can get this pull request merged, and then we can either make the tests pass or figure out a fudge framework 05:16
did I just say fudge framework?
cotto dukeleto, I'm afraid so. 05:17
sounds delicious, though not very healthy
dukeleto cotto: looks like we are passing 30/60 files with our M0 c implementation. Not bad. 05:24
cotto: those are 30/60 of the integration tests 05:26
cotto dukeleto, indeed
dalek Heuristic branch merge: pushed 22 commits to parrot/m0-prototype by leto 05:35
dukeleto nbrown++ # keep the m0 pull requests coming 05:36
cotto nbrown++ 05:38
06:40 wayland76 joined 07:25 mj41 joined 07:58 lucian joined 08:01 p6eval joined 08:17 jsut_ joined 08:22 jsut__ joined 08:35 Kovensky joined 09:07 janus joined 10:59 lateau joined 11:07 ambs joined
mls afternoon, parrot! 11:13
does pbc_merge really strip the annotations?
11:17 woosley joined 11:21 jsut joined 11:53 JimmyZ joined
dalek nxed: b84ddb5 | NotFound++ | t/advanced/02varcast.t:
test for cast to var builtin
 11:58
12:10 mtk joined 12:29 ambs_ joined 12:35 whiteknight joined
whiteknight good morning, #parrot 12:36
tadzik good morning whiteknight 12:41
whiteknight hello tadzik 12:45
mls morning whiteknight!
I noticed that pbc_merge does not merge annotations. Is that a known defect? 12:46
whiteknight mls: yes. I was working on it at one point, but I didn't finish 12:57
12:57 bluescreen joined
JimmyZ \\o 12:59
13:06 mtk joined 13:09 lucian joined
atrodo =~ 13:15
mls whiteknight: ok, thanks! 13:21
plobsing mls: pbc_merge merges at too deep a level. it is likely one of the things that'll get changed when we rethink PBC (which has been a long time coming) 13:36
mls good to known, thanks 13:45
dukeleto ~~ 13:47
dalek nxed: 5d85a13 | NotFound++ | winxedst1.winxed:
fixes for HLL modifier:

  - use new or root_new depending on HLLs of instantiated class and
   instantiation point in dotted new		 13:52
14:35 redicaps joined 14:59 nbrown joined 15:11 RobertLJ joined 15:17 redicaps left 15:22 dmalcolm joined 15:24 RobertLJ1 joined
dalek rrot: 5f1cec8 | plobsing++ | src/debug.c:
refactor common call preamble into sub
 15:50
rrot: d52dba8 | plobsing++ | / (2 files):
don't assume interp->code still points to the top frame of a backtrace

fixes TT #2188
rrot: bab687c | plobsing++ | src/debug.c:
rewrite backtrace iteration to eliminate special-case for top stack element

this eliminates essentially duplicate code
rrot: fad065b | plobsing++ | / (5 files):
don't use interp to guess where the top of a backtrace is, use an explicit parameter
rrot: 4d99ed7 | plobsing++ | MANIFEST:
mk_manifest_and_skip
mls pbc_dump doesn't correctly dump annotations. Here's a patch: gist.github.com/1188987 15:53
whiteknight what does that patch do?
mls: open a pull request? 15:56
plobsing mls: good catch. +1 to merge 15:58
whiteknight: can it be merge-o'clock for parrot2 yet? 15:59
whiteknight yeah, go for it 16:00
or I can do it 16:01
if you have time now, go for it
plobsing I will do it after I close-out TT #2188 (still needs a test to prevent regression)
whiteknight ok
plobsing++ on those last few commits, by the way
anything we can do to fix up that ratty old code is a big benefit
mls must I really do a pull request for one-liner changes? 16:03
JimmyZ mls: nope
mls speaking of annotations, how do I put an annotation on the start of a sub?
plobsing oooh, tricky question 16:04
the answer is "you don't". at least not with IMCC
mls .annotate seems to need to come after the .param lines, but that makes the annotation stick to the op after the get_params
Ah, ok ;)
plobsing mls: you could try an .annotate at the end of the previous sub, but that is beyond "ugly hack" 16:05
mls Yes, that solution also crossed my mind ;)
plobsing mls: why do you want an annotation before the get_params? 16:07
mls I've written a little op tracer, and I want to print some location information next to each sub name 16:08
Currently, I use PackFile_Annotations_lookup(interp, sp->sub->seg->annotations, sp->sub->start_offs + 1, NULL), but that picks the wrong annotation 16:09
plobsing at does?
s/at/it/
mls So I'll change the code to look for the first annotation in the [start_offs, end_offs[ range 16:10
whiteknight .params and get_params are evil and need to die
I'm thinking a wooden spike, covered in garlic oil
mls Yes, cause the annotation of the sub starts at the op after the get_params
plobsing mls: I would suggest you put null file and line annotations at the end of your subs and then check for that in your tracer (and file it under "sub preamble")
I wouldn't count null annotations (as opposed to the next sub's annotations) as hack-ish 16:11
mls ok, back to hacking. Thanks guys! 16:12
plobsing whiteknight: .param is the syntactic abstraction that let us change PCC in the past and is what will let us change PCC in the future. I'm not sure getting rid of it is altogether a good idea 16:13
get_params on the other hand...
mls (Btw, how about an "auto-annotate" option for imcc that makes it automatically but an annotation on each sub?)
s/but/put
plobsing mls: what would the annotation contain? 16:14
mls the pir filename and the line number
plobsing mls: we already have an op to (filename, lineno) lookup mechanism for PIR - the debug segment 16:15
annotations are only for HLL info
mls ah, ok. so I should also look into the debug segment. good to know.
dalek rrot: 4d4be12 | jimmy++ | src/packfile/segments.c:
pbc_dump should dump annotation correctly, patch courtesy of mls++
plobsing and IMCC is happily agnostic about annotations, simply passing them on into PBC
dukeleto mls: nice to see your awesome patches lately. Keep it up :) 16:16
mls Thanks!
whiteknight plobsing: well, .param is a hassle because of the strict way it's parsed. get_params is the real evil 16:20
plobsing: there was a time not too long ago when you couldn't even have comments between .param statements, or between the .sub line and the subsequent .param line
imagine a world where it's impossible to comment your parameters 16:21
so, we've come a long way since then
plobsing let's not mistake a poor implementation for a poor concept 16:22
whiteknight let's not mistake the vision for the future for the current reality either 16:24
the .param abstraction concept isn't bad. .param as we currently have it sort of is
plobsing granted. I just get worried when you grab the chainsaw with that crazed look you get sometimes. 16:26
atrodo I don't. I like to encourage that look
plobsing fixing all bad code in parrot by chainsaw would leave a very empty repo 16:27
whiteknight it's only a bad thing if we rip out the bad crap and don't replace it with shiney new crap 16:34
plobsing like the jit? 16:35
or threads?
whiteknight the JIT replacement is happening, in a roundabout way
and threads aren't even out the door yet
plobsing I'm just pointing out a pattern
whiteknight okay, okay. it's a lousy pattern. We should take the chainsaw to it too 16:36
maybe I'm not understanding the problem :) 16:37
I had ideas for a replacement for threading, and you poo-pooed them 16:38
in your standard unassailably rational way 16:39
if you would just let me make all the same old mistakes in new and labor-intensive ways, we wouldn't be having this conversation. 16:40
dukeleto is parrot-dev stuck again? 16:41
plobsing my concern is that we rip out threads and then it festers like the jit problem
if we get a new implementation in a couple months, that's great
whiteknight of threads? 16:42
dukeleto can't we say "we don't support this implementation of this subsystem anymore", work on the replacement, and delete the old one when we have a viable replacement?
whiteknight dukeleto: because there are many open tickets and broken pieces now because of threading, in unrelated areas
plobsing dukeleto: I do agree that we need to rip out threads before providing a new implementation. It ties into core-parrot too much to have a side-by-side. 16:43
16:44 davidfetter joined
mls (btw, pdd03_calling_conventions.pod says that one must call get_results before calling the sub. That's not correct anymore, right?) 16:44
plobsing now whether we merge the ripped-out-threads into master before the new implementation rolls around is debatable
mls: nope
(as in it is false)
mls subs.pod also has it wrong 16:45
plobsing mls: although why you would be calling get_results directly (as opposed to using the PIR calling syntax sugar) is beyond me 16:46
mls Heh. I don't want to do that. I just stumbled over that while reading the docs and was a bit confused
plobsing it is inaccurate, but its accuracy is immaterial. opcodes for making calls are abstracted because we reserve the right to change the calling convention. 16:48
cotto_work ~~
whiteknight we reserve the right to change them, and we have particularly vicious plans to do just that
at least, I have plans 16:49
evil, evil plans
plobsing so acting on that information (accurate or not) is a bad idea
17:26 mj41 joined
dalek rrot: 5b76269 | plobsing++ | t/op/exceptions.t:
test that there are no unexpected differences between user-generated backtraces and automatic ones

this test was massaged from the code in TT #8122		 17:31
TT #2188 closed by plobsing++: Missing path in exception stack trace 17:34
TT #2188: trac.parrot.org/parrot/ticket/2188
whiteknight nice test 17:58
18:01 contingencyplan joined 18:19 plobsing_ joined
dalek rrot: 6fdc50a | pmichaud++ | compilers/pct/src/PCT/HLLCompiler.pir:
[pct]: Switch HLLCompiler's .lineof to a binary search instead of linear.

Recent profiling from mls++ on Rakudo's setting compilation seems to indicate that lineof does a lot of work. This patch switches the linear search to a binary search, making an O(n**2) process into an O(n*log(n)) one. However, this doesn't seem to translate into any sort of significant speed improvement in setting compilation, which makes me think the profiling itself is off. Still, it's an easy optimization for now so I'm going ahead and committing it.		 18:27
rrot: cf02146 | plobsing++ | compilers/pct/src/PCT/HLLCompiler.pir:
Merge branch 'master' of github.com:parrot/parrot
 18:33
rrot/mls/sub-profiler: 254c000 | cotto++ | / (3 files):
initial patch from mls++ to add a sub-level profiling runcore

The patch will need some re-working, but it seems to be much faster than the default profiling runcore and makes pmichaud very happy, so we'll see what we can do.		 18:37
whiteknight okay, methinks we need to throw a commit bit at mls so he stops bothering us with all his awesome patches! 18:38
cotto_work the branch needs love.
whiteknight which branch?
cotto_work it builds though
that one I just pushed
whiteknight oh, okay
cotto_work I'll probably poke at it this evening if I can manage not to do so earlier. ;) 18:39
mls parrot/mls/sub-profiler: it generates profile data that can be read with kcachegrind 18:44
It's a bit different than parrot's current profiling: It doesn't write a line for every op or context change, but counts in memory
the idea is the same, though. (Actually I borrowed a lot of code/ideas from it) 18:45
18:46 davidfetter joined
mls (apologies for the coding style and the hardware dependency, it was just a quick hack) 18:46
plobsing_ rdtsc probably needs to go somewhere arch-specific
mls yeah. it's just a workaround because I thought Parrot_hires_get_time() for every op might be too expensive. I've not tested it, though 18:49
(the code also leaks quite a bit of memory)
plobsing_ O(const) or O(n) or worse? 18:50
mls O(number of subs in the code) 18:51
i.e. pretty const
nothing to worry about ;)
cotto_work mls: I'd like to see the magic numbers commented better. 18:59
mls you mean the "16"? 19:00
cotto_work mls: I also am planning on stealing the relevant bits and possibly making that the default behavior for the current profiling runcore, if you don't mind.
mls: 32767
mls ah yes, that's a second magic number ;)
whiteknight is this version of a profiler less bad than the version we have? 19:01
or, more good?
mls I wrote it to profile the rakudo setting compilation.
whiteknight Is it more accurate than what we previously had? 19:02
mls That was not possible with the current profiler, which wrote a line for every op/context switch
otherwise it's not that different
whiteknight ok
tadzik hmm, wasn't someone doing green threads last gsoc?
whiteknight if it's better for Rakudo, and it doesn't break things in other ways, we probably want it
tadzik sorry for the sudden new topic
whiteknight tadzik: yes, but wasn't completed
tadzik oh, ok
cotto_work It's been my plan to eventually do more stuff in-memory in the current profiler. This may provide an excellent excuse. 19:03
time for noms
whiteknight we still have that branch around. I was planning to cannibalize it if I got the go-ahead to implement my rheading proposal
mls it also handles callcontext changes a bit different, it should work with exceptions/continuations 19:04
whiteknight oh, that is nice
plobsing_ mls: I just ran a simple test (running parrot using the --trace core), and get_params appears to get annotated just fine 19:37
are you running an old parrot perhaps?
(I was toying around with inserting a nop to annotate before get_params) 19:38
19:39 RobertLJ joined 19:42 wayland76 joined 19:48 preflex joined 19:54 pmichaud_ joined
pmichaud_ cotto_work: ping 19:54
cotto_work: unping (heading to lunch here) 19:56
right now the mls/sub-profiler branch is behind master by about 58 commits (including the binary search commit I just pushed an hour ago) -- could someone see about sync'ing the two? kthx 19:57
whiteknight pmichaud_: yeah, we'll definitely take care of it 20:03
20:03 jsut_ joined
plobsing_ argh! every time I go to act on a deprecation, it turns out the notice wasn't ported from DEPRECATED.pod to api.yaml. 20:27
dalek tracwiki: v1 | plobsing++ | ParrotDeprecationsFor4.0
tracwiki: document FPA.set_pmc deprecation
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v33 | plobsing++ | ParrotDeprecations
tracwiki: note FPA.set_pmc deprecation
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
plobsing_ what to do? 20:28
20:28 RobertLJ1 joined
plobsing_ tadzik-- # lost data 20:28
20:29 bluescreen joined
dalek rrot: bdfe6ab | plobsing++ | src/pmc/continuation.pmc:
specify that we are talking about the return continuation

TT #1926 points out that 'the continuation of a continuation' is pretty meaningless		 20:34
rrot: eb78e6c | plobsing++ | compilers/pct/src/PCT/HLLCompiler.pir:
[codingstd] trailing space
cotto_work plobsing_: do it anyway? What's the impact on HLLs? 20:36
benabik o/
plobsing_ cotto_work: rakudo still passes spec 20:37
so I'm figuring it probably won't cause too much harm
tadzik plobsing_: please define "every time" 20:38
plobsing_ tadzik: the last two times
and I have tried to act on a deprecation twice since api.yaml went into effect
so 100% of the times I have tried
plobsing_ is going to try to determine which active deprecations are missing from api.yaml 20:39
so this doesn't happen again
dalek rrot: 2011cf3 | plobsing++ | src/pmc/ (2 files):
per deprecation TT #1904, FixedPMCArray should not support any resizing operations (including set_pmc)

however, code reasonably expects RPA to support this opperation, so move the supporting code there		 20:40
rrot: 34e414d | plobsing++ | t/pmc/ (2 files):
move set_pmc tests from FPA to RPA, same as functionality move
plobsing_ can someone independantly confirm that bdfe6ab reasonably satisfies TT #1926? 20:42
tadzik plobsing_: I remember checking that api.yaml held the same number of deprecations as DEPRECATED.pod did, which suprises me. Sorry for the loss, that or any way 20:45
dalek rrot: 2efcf43 | plobsing++ | api.yaml:
add TT #1904 deprecation to api.yaml (was missed in import)
 20:48
20:49 PacoLinux_ joined
dalek rrot/mls/sub-profiler: cf02146 | plobsing++ | compilers/pct/src/PCT/HLLCompiler.pir:
Merge branch 'master' of github.com:parrot/parrot
 20:53
rrot/mls/sub-profiler: 81ae7de | cotto++ | / (28 files):
Merge branch 'master' into mls/sub-profiler
rrot/mls/sub-profiler: d37407c | cotto++ | / (5 files):
break sub profiling code into its own files
plobsing_ tadzik: I count 10 TTs in the nuked DEPRECATED.pod not present in api.yaml 20:54
tadzik huh, now I feel stupid 20:55
plobsing_ git show 95d715cfeb256214c30575f613a792298c8d25e0 | grep 'ticket/' | pnle '/(\\d+)/; say $1' | sort -u > DEPRECATED.pod.tickets
likewise for api.yaml
then view the diff
alias pnle = 'perl -nlE' 20:56
tadzik okay, my fault. Sorry for that 20:57
plobsing_ no problem now. it was quite infuriating at the moment of discovery. 20:59
there are sins a computer can commit worse than the loss of user data
s/are/are few/
tadzik: what do you recommend for a deprecation with multiple associated tickets? 21:04
tadzik it seems like there were 57 entries in the DEPRECATED.yaml those days, and 64 in DEPRECATED.pod
plobsing_ TT #1033 and TT #1704 aren't in api.yaml but are assicated with the deprecation in TT #1705 21:05
tadzik plobsing_: I suppose merging the tickets is not an option? No answer straight in my head, I must say
maybe ticket: should be an array, if there's a need for that. Otherwise, we can have a place like "see also"
plobsing_ I'm creating a 'tickets' entry as an array 21:06
tadzik I'm going through the first version of DEPRECATED.yaml manually to see what's missing 21:09
plobsing_ I've got about half manually imported 21:15
tadzik not pushed? 21:17
I've already added like 3
cotto_work mls: are you on parrot-dev? 21:18
plobsing_ tadzik: not yet
I will now
tadzik okay
oh, I now see what you meant about multiple tickets 21:19
dalek rrot: d74dbbe | plobsing++ | api.yaml:
manually import into api.yaml several previously missed deprecations
 21:21
tadzik I'll go through the rest of them 21:23
dalek rrot: 4092f78 | plobsing++ | api.yaml:
manually import more deprecations into api.yaml. hopefully thats the last of them
 21:26
plobsing_ tadzik: I think I got 'em all, but it would be great if you could double check
tadzik plobsing_: what does grep -c 'name:' give you now? 21:27
plobsing_ 63 21:28
grep -c 'name\\s*:' api.yaml => 78
tadzik okay 21:29
I'll go to the end of the old DEPRECATED.pod and see if I'll get the same number
plobsing_ there have been deprecations added since DEPRECATED.pod was nuked, so your number should be slightly lower
tadzik I know, I'm editing the new api.yaml 21:30
damn, I counted 77 21:31
plobsing++ # fixing what I screwed up 21:34
everything seems fine now 21:36
plobsing_ going through those tickets, they were all eligible in 3.1. perhaps there was a race condition on your branch merge. 21:37
or something similar
21:46 RobertLJ1 left
dalek TT #1904 closed by plobsing++: [DEPRECATED] assign on FPA 21:46
TT #1904: trac.parrot.org/parrot/ticket/1904
pmichaud_ hmmm.... the mls/sub-profiler branch no longer profiles, it seems :( 21:56
unless I missed something
cotto_work looking into it 22:00
22:11 Limbic_Region joined
pmichaud_ is it still "-R slow" to get the profiling output in the sub-profiler branch? 22:18
cotto_work pmichaud_: looks like we're using the parrot2 frontend now 22:20
I'll have a fix in a sec
pmichaud_ cotto_work: okay, thanks.
dalek rrot/mls/sub-profiler: 2d18c6d | cotto++ | / (2 files):
nuke leftover pod, enable sub profiler in parrot2 frontend
 22:22
cotto_work pmichaud_: there you go
pmichaud_ cotto_work: testing 22:23
cotto_work It'd have helped if I'd actually looked at gdb's output and realized that it was breaking on parrot2's main
I got it to spit out some kind of profile.
with -Rslow
pmichaud_ building now 22:25
cotto_work should be sunshine and rainbows 22:26
22:36 rfw joined
pmichaud_ sunshine and rainbows it is. cotto_work++ 22:50
cotto_work just don't look at the code. ;) 22:52
23:00 nbrown joined 23:04 whiteknight joined
cotto_work hio whiteknight 23:05
whiteknight helloio, cotto_work
plobsing++ on the whiteknight/frontend_parrot2 merge 23:07
I'm going to update the mls/sub-profiler branch to master now 23:24
23:25 Coke joined
whiteknight mls: ping 23:26
cotto_work whiteknight: please do 23:33
what's your plan?
whiteknight I can't build that branch. missing reference to rdtsc
should I just push anyway? 23:34
what plan, for what?
sorear whiteknight: what kind of computer do you have? 23:35
whiteknight sorear: a normal one?
cotto_work sorear: that should be a thing on x86 and x86_64
whiteknight: I can test. Push away.
dalek rrot/mls/sub-profiler: 8f1d154 | Whiteknight++ | / (7 files):
Merge branch 'master' into mls/sub-profiler
 23:36
sorear whiteknight: there are no "normal" computers yet.
whiteknight: rdtsc exists at all only on PC clones and Intel Macs 23:37
whiteknight then, I must have an abnormal one
benabik rdtsc?
404 Manpage not found
cotto_work en.wikipedia.org/wiki/Time_Stamp_Counter
I'm not a fan of how that's done. It's on my list to replace that with the Parrot hires timing thingy 23:38
benabik We have a hires timing thingy?
cotto_work Parrot_hires_get_time
plobsing_ whiteknight, cotto_work: can you confirm that TT #1926 is closeable after bdfe6ab? I need an outside opinion saying "yes, I understand that now"
cotto_work plobsing_: much better. 23:39
plobsing++
sorear cotto_work: read mls' mail carefully. Doing that would defeat the entire point
plobsing_ good enough for me. closing ticket.
sorear cotto_work: Parrot_hires_get_time is too slow for use in the mls profiling runcore
plobsing_ sorear: mls has admitted he used that based on intuition and never actually tested 23:40
premature optimization
cotto_work sorear: I'll buy that when I see a profile that confirms it.
though I'll profile if when I switch and see what the impact is. 23:41
sorear don't profile, measure.
cotto_work ?
benabik Isn't profiling measuring?
cotto_work actually, I can do that now 23:42
I see a significant increase. 23:45
sorear: looks like you're correct.
17s with the hires thingy vs 6.3s with rdtsc 23:46
running ./parrot -Rslow examples/benchmarks/oofib.pir 28 2>/dev/null 23:47
though kcachegrind says it shouldn't be doing that 23:49
benabik ?
cotto_work kcachegrind says that Parrot_hires_get_time is at about 5% 23:50
benabik but it takes 100% longer? poor
cotto_work I'm probably messing something up 23:51
sorear benabik: this is what I mean when I say profiling isn't a substitute for measuring 23:52
benabik sorear: Fair enough. 23:53
Is rdtsc in a function? We'll need to figure out some way to figure out the cross-platform aspects of this.
plobsing_ benabik: rdtsc is a machine instruction 23:54
benabik plobsing_: Yes, I'm aware. But are we just peppering asm through the slow runcore or is it nicely isolated in a function? 23:55
dalek TT #1926 closed by plobsing++: continuation method of Continuation PMC
TT #1926: trac.parrot.org/parrot/ticket/1926
plobsing_ benabik: it is isolated in a function, which we can select an appropriate implementaton of at configure-time.
benabik plobsing_: Excellente.
cotto_work benabik: yes 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!