Camelia, the Perl 6 bug

IRC log for #parrot, 2011-09-02

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:08 benabik o/
00:16 davidfetter \<>/
00:37 AzureStone joined #parrot
00:46 kid51 joined #parrot
00:54 kid51 ~~
00:54 kid51 cotto: ping
01:01 cotto_work kid51: ping
01:01 cotto_work er, pong
02:01 woosley joined #parrot
02:08 cotto_work allison: ping
02:20 cotto_work allison: unping
02:23 jkitazawa joined #parrot
02:42 nbrown joined #parrot
02:43 dngor joined #parrot
03:03 rfw joined #parrot
04:39 dukeleto ~~
04:50 cotto ~~
04:51 dukeleto cotto: i am working on merging the m0 pull request that we got from nbrown++. Any objections?
04:56 cotto dukeleto, I haven't reviewed it yet.
04:56 cotto so technically, I don't object
04:57 cotto I'll look at it in a couple minutes.
05:01 cotto looking now
05:04 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.
05:04 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?
05:05 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
05:05 cotto we can do that with makefile targets
05:05 cotto make c_m0_tests
05:05 cotto something like that
05:06 dukeleto cotto: yeah, that patch adds something like that, but also has test duplication
05:06 dukeleto cotto: should me make the tests take an argument of which implementation binary to test against?
05:06 dukeleto s/me/we/
05:07 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:09 dukeleto cotto: passing arguments to tests doesn't interact well with running multiple tests via a harness
05:10 dukeleto cotto: how do you feel about an env var?
05:11 cotto dukeleto, good point
05:11 cotto I guess that's workable.
05:12 cotto just don't tell greenpeace
05:13 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:15 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 cotto or another option, if you have one
05:16 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 dukeleto did I just say fudge framework?
05:17 cotto dukeleto, I'm afraid so.
05:17 cotto sounds delicious, though not very healthy
05:24 dukeleto cotto: looks like we are passing 30/60 files with our M0 c implementation. Not bad.
05:26 dukeleto cotto: those are 30/60 of the integration tests
05:26 cotto dukeleto, indeed
05:35 dalek Heuristic branch merge: pushed 22 commits to parrot/m0-prototype by leto
05:36 dukeleto nbrown++ # keep the m0 pull requests coming
05:38 cotto nbrown++
06:40 wayland76 joined #parrot
07:25 mj41 joined #parrot
07:58 lucian joined #parrot
08:01 p6eval joined #parrot
08:17 jsut_ joined #parrot
08:22 jsut__ joined #parrot
08:35 Kovensky joined #parrot
09:07 janus joined #parrot
10:59 lateau joined #parrot
11:07 ambs joined #parrot
11:13 mls afternoon, parrot!
11:13 mls does pbc_merge really strip the annotations?
11:17 woosley joined #parrot
11:21 jsut joined #parrot
11:53 JimmyZ joined #parrot
11:58 dalek winxed: b84ddb5 | NotFound++ | t/advanced/02varcast.t:
11:58 dalek winxed: test for cast to var builtin
11:59 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/b84ddb51bc
12:10 mtk joined #parrot
12:29 ambs_ joined #parrot
12:35 whiteknight joined #parrot
12:36 whiteknight good morning, #parrot
12:41 tadzik good morning whiteknight
12:45 whiteknight hello tadzik
12:45 mls morning whiteknight!
12:46 mls I noticed that pbc_merge does not merge annotations. Is that a known defect?
12:57 whiteknight mls: yes. I was working on it at one point, but I didn't finish
12:57 bluescreen joined #parrot
12:59 JimmyZ \o
13:06 mtk joined #parrot
13:09 lucian joined #parrot
13:15 atrodo =~
13:21 mls whiteknight: ok, thanks!
13:36 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:45 mls good to known, thanks
13:47 dukeleto ~~
13:52 dalek winxed: 5d85a13 | NotFound++ | winxedst1.winxed:
13:52 dalek winxed: fixes for HLL modifier:
13:52 dalek winxed: - emit correct .namespace directives in nested namespaces.
13:52 dalek winxed: - use new or root_new depending on HLLs of instantiated class and
13:52 dalek winxed:   instantiation point in dotted new
13:52 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/5d85a13ad3
14:35 redicaps joined #parrot
14:59 nbrown joined #parrot
15:11 RobertLJ joined #parrot
15:17 redicaps left #parrot
15:22 dmalcolm joined #parrot
15:24 RobertLJ1 joined #parrot
15:50 dalek parrot: 5f1cec8 | plobsing++ | src/debug.c:
15:50 dalek parrot: refactor common call preamble into sub
15:50 dalek parrot: review: https://github.com/parrot/parrot/commit/5f1cec8333
15:50 dalek parrot: d52dba8 | plobsing++ | / (2 files):
15:50 dalek parrot: don't assume interp->code still points to the top frame of a backtrace
15:50 dalek parrot:
15:50 dalek parrot: fixes TT #2188
15:50 dalek parrot: review: https://github.com/parrot/parrot/commit/d52dba8f5d
15:50 dalek parrot: bab687c | plobsing++ | src/debug.c:
15:50 dalek parrot: rewrite backtrace iteration to eliminate special-case for top stack element
15:50 dalek parrot:
15:50 dalek parrot: this eliminates essentially duplicate code
15:50 dalek parrot: review: https://github.com/parrot/parrot/commit/bab687ca8d
15:50 dalek parrot: fad065b | plobsing++ | / (5 files):
15:50 dalek parrot: don't use interp to guess where the top of a backtrace is, use an explicit parameter
15:50 dalek parrot: review: https://github.com/parrot/parrot/commit/fad065bd43
15:50 dalek parrot: 4d99ed7 | plobsing++ | MANIFEST:
15:50 dalek parrot: mk_manifest_and_skip
15:50 dalek parrot: review: https://github.com/parrot/parrot/commit/4d99ed7438
15:53 mls pbc_dump doesn't correctly dump annotations. Here's a patch: https://gist.github.com/1188987
15:53 whiteknight what does that patch do?
15:56 whiteknight mls: open a pull request?
15:58 plobsing mls: good catch. +1 to merge
15:59 plobsing whiteknight: can it be merge-o'clock for parrot2 yet?
16:00 whiteknight yeah, go for it
16:01 whiteknight or I can do it
16:01 whiteknight if you have time now, go for it
16:01 plobsing I will do it after I close-out TT #2188 (still needs a test to prevent regression)
16:01 whiteknight ok
16:01 whiteknight plobsing++ on those last few commits, by the way
16:01 whiteknight anything we can do to fix up that ratty old code is a big benefit
16:03 mls must I really do a pull request for one-liner changes?
16:03 JimmyZ mls: nope
16:03 mls speaking of annotations, how do I put an annotation on the start of a sub?
16:04 plobsing oooh, tricky question
16:04 plobsing the answer is "you don't". at least not with IMCC
16:04 mls .annotate seems to need to come after the .param lines, but that makes the annotation stick to the op after the get_params
16:04 mls Ah, ok ;)
16:05 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 ;)
16:07 plobsing mls: why do you want an annotation before the get_params?
16:08 mls I've written a little op tracer, and I want to print some location information next to each sub name
16:09 mls 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?
16:09 plobsing s/at/it/
16:10 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
16:10 whiteknight I'm thinking a wooden spike, covered in garlic oil
16:10 mls Yes, cause the annotation of the sub starts at the op after the get_params
16:10 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")
16:11 plobsing I wouldn't count null annotations (as opposed to the next sub's annotations) as hack-ish
16:12 mls ok, back to hacking. Thanks guys!
16:13 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 plobsing get_params on the other hand...
16:13 mls (Btw, how about an "auto-annotate" option for imcc that makes it automatically but an annotation on each sub?)
16:13 mls s/but/put
16:14 plobsing mls: what would the annotation contain?
16:14 mls the pir filename and the line number
16:15 plobsing mls: we already have an op to (filename, lineno) lookup mechanism for PIR - the debug segment
16:15 plobsing annotations are only for HLL info
16:15 mls ah, ok. so I should also look into the debug segment. good to know.
16:15 dalek parrot: 4d4be12 | jimmy++ | src/packfile/segments.c:
16:15 dalek parrot: pbc_dump should dump annotation correctly, patch courtesy of mls++
16:15 dalek parrot: review: https://github.com/parrot/parrot/commit/4d4be123f6
16:15 plobsing and IMCC is happily agnostic about annotations, simply passing them on into PBC
16:16 dukeleto mls: nice to see your awesome patches lately. Keep it up :)
16:16 mls Thanks!
16:20 whiteknight plobsing: well, .param is a hassle because of the strict way it's parsed. get_params is the real evil
16:20 whiteknight 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
16:21 whiteknight imagine a world where it's impossible to comment your parameters
16:21 whiteknight so, we've come a long way since then
16:22 plobsing let's not mistake a poor implementation for a poor concept
16:24 whiteknight let's not mistake the vision for the future for the current reality either
16:24 whiteknight the .param abstraction concept isn't bad. .param as we currently have it sort of is
16:26 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
16:27 plobsing fixing all bad code in parrot by chainsaw would leave a very empty repo
16:34 whiteknight it's only a bad thing if we rip out the bad crap and don't replace it with shiney new crap
16:35 plobsing like the jit?
16:35 plobsing or threads?
16:35 whiteknight the JIT replacement is happening, in a roundabout way
16:35 whiteknight and threads aren't even out the door yet
16:35 plobsing I'm just pointing out a pattern
16:36 whiteknight okay, okay. it's a lousy pattern. We should take the chainsaw to it too
16:37 whiteknight maybe I'm not understanding the problem :)
16:38 whiteknight I had ideas for a replacement for threading, and you poo-pooed them
16:39 whiteknight in your standard unassailably rational way
16:40 whiteknight 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:41 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
16:41 plobsing if we get a new implementation in a couple months, that's great
16:42 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?
16:42 whiteknight dukeleto: because there are many open tickets and broken pieces now because of threading, in unrelated areas
16:43 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:44 davidfetter joined #parrot
16:44 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
16:44 plobsing mls: nope
16:44 plobsing (as in it is false)
16:45 mls subs.pod also has it wrong
16:46 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
16:48 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 ~~
16:48 whiteknight we reserve the right to change them, and we have particularly vicious plans to do just that
16:49 whiteknight at least, I have plans
16:49 whiteknight evil, evil plans
16:49 plobsing so acting on that information (accurate or not) is a bad idea
17:26 mj41 joined #parrot
17:31 dalek parrot: 5b76269 | plobsing++ | t/op/exceptions.t:
17:31 dalek parrot: test that there are no unexpected differences between user-generated backtraces and automatic ones
17:31 dalek parrot:
17:31 dalek parrot: this test was massaged from the code in TT #8122
17:31 dalek parrot: review: https://github.com/parrot/parrot/commit/5b76269167
17:34 dalek TT #2188 closed by plobsing++: Missing path in exception stack trace
17:34 dalek TT #2188: http://trac.parrot.org/parrot/ticket/2188
17:58 whiteknight nice test
18:01 contingencyplan joined #parrot
18:19 plobsing_ joined #parrot
18:27 dalek parrot: 6fdc50a | pmichaud++ | compilers/pct/src/PCT/HLLCompiler.pir:
18:27 dalek parrot: [pct]:  Switch HLLCompiler's .lineof to a binary search instead of linear.
18:27 dalek parrot:
18:27 dalek parrot: Recent profiling from mls++ on Rakudo's setting compilation seems to
18:27 dalek parrot: indicate that lineof does a lot of work.  This patch switches the
18:27 dalek parrot: linear search to a binary search, making an O(n**2) process into
18:27 dalek parrot: an O(n*log(n)) one.  However, this doesn't seem to translate into
18:27 dalek parrot: any sort of significant speed improvement in setting compilation,
18:27 dalek parrot: which makes me think the profiling itself is off.   Still, it's an
18:27 dalek parrot: easy optimization for now so I'm going ahead and committing it.
18:27 dalek parrot: review: https://github.com/parrot/parrot/commit/6fdc50ae98
18:33 dalek parrot: cf02146 | plobsing++ | compilers/pct/src/PCT/HLLCompiler.pir:
18:33 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
18:33 dalek parrot: review: https://github.com/parrot/parrot/commit/cf02146c32
18:37 dalek parrot/mls/sub-profiler: 254c000 | cotto++ | / (3 files):
18:37 dalek parrot/mls/sub-profiler: initial patch from mls++ to add a sub-level profiling runcore
18:37 dalek parrot/mls/sub-profiler:
18:37 dalek parrot/mls/sub-profiler: The patch will need some re-working, but it seems to be much faster than
18:37 dalek parrot/mls/sub-profiler: the default profiling runcore and makes pmichaud very happy, so we'll
18:37 dalek parrot/mls/sub-profiler: see what we can do.
18:37 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/254c0002a2
18:38 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.
18:38 whiteknight which branch?
18:38 cotto_work it builds though
18:38 cotto_work that one I just pushed
18:38 whiteknight oh, okay
18:39 cotto_work I'll probably poke at it this evening if I can manage not to do so earlier. ;)
18:44 mls parrot/mls/sub-profiler: it generates profile data that can be read with kcachegrind
18:44 mls 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
18:45 mls the idea is the same, though. (Actually I borrowed a lot of code/ideas from it)
18:46 davidfetter joined #parrot
18:46 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
18:49 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 mls (the code also leaks quite a bit of memory)
18:50 plobsing_ O(const) or O(n) or worse?
18:51 mls O(number of subs in the code)
18:51 mls i.e. pretty const
18:51 mls nothing to worry about ;)
18:59 cotto_work mls: I'd like to see the magic numbers commented better.
19:00 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.
19:00 cotto_work mls: 32767
19:00 mls ah yes, that's a second magic number ;)
19:01 whiteknight is this version of a profiler less bad than the version we have?
19:01 whiteknight or, more good?
19:01 mls I wrote it to profile the rakudo setting compilation.
19:02 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
19:02 mls otherwise it's not that different
19:02 whiteknight ok
19:02 tadzik hmm, wasn't someone doing green threads last gsoc?
19:02 whiteknight if it's better for Rakudo, and it doesn't break things in other ways, we probably want it
19:02 tadzik sorry for the sudden new topic
19:02 whiteknight tadzik: yes, but wasn't completed
19:02 tadzik oh, ok
19:03 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 cotto_work time for noms
19:03 whiteknight we still have that branch around. I was planning to cannibalize it if I got the go-ahead to implement my rheading proposal
19:04 mls it also handles callcontext changes a bit different, it should work with exceptions/continuations
19:04 whiteknight oh, that is nice
19:37 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 plobsing_ are you running an old parrot perhaps?
19:38 plobsing_ (I was toying around with inserting a nop to annotate before get_params)
19:39 RobertLJ joined #parrot
19:42 wayland76 joined #parrot
19:48 preflex joined #parrot
19:54 pmichaud_ joined #parrot
19:54 pmichaud_ cotto_work: ping
19:56 pmichaud_ cotto_work: unping (heading to lunch here)
19:57 pmichaud_ 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
20:03 whiteknight pmichaud_: yeah, we'll definitely take care of it
20:03 jsut_ joined #parrot
20:27 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
20:27 dalek tracwiki: document FPA.set_pmc deprecation
20:27 dalek tracwiki: http://trac.parrot.org/parrot/wiki/ParrotDe​precationsFor4.0?version=1&amp;action=diff
20:27 dalek tracwiki: v33 | plobsing++ | ParrotDeprecations
20:27 dalek tracwiki: note FPA.set_pmc deprecation
20:27 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Parro​tDeprecations?version=33&amp;action=diff
20:28 plobsing_ what to do?
20:28 RobertLJ1 joined #parrot
20:28 plobsing_ tadzik-- # lost data
20:29 bluescreen joined #parrot
20:34 dalek parrot: bdfe6ab | plobsing++ | src/pmc/continuation.pmc:
20:34 dalek parrot: specify that we are talking about the return continuation
20:34 dalek parrot:
20:34 dalek parrot: TT #1926 points out that 'the continuation of a continuation' is pretty meaningless
20:34 dalek parrot: review: https://github.com/parrot/parrot/commit/bdfe6ab655
20:34 dalek parrot: eb78e6c | plobsing++ | compilers/pct/src/PCT/HLLCompiler.pir:
20:34 dalek parrot: [codingstd] trailing space
20:34 dalek parrot: review: https://github.com/parrot/parrot/commit/eb78e6c538
20:36 cotto_work plobsing_: do it anyway?  What's the impact on HLLs?
20:36 benabik o/
20:37 plobsing_ cotto_work: rakudo still passes spec
20:37 plobsing_ so I'm figuring it probably won't cause too much harm
20:38 tadzik plobsing_: please define "every time"
20:38 plobsing_ tadzik: the last two times
20:38 plobsing_ and I have tried to act on a deprecation twice since api.yaml went into effect
20:38 plobsing_ so 100% of the times I have tried
20:39 * plobsing_ is going to try to determine which active deprecations are missing from api.yaml
20:39 plobsing_ so this doesn't happen again
20:40 dalek parrot: 2011cf3 | plobsing++ | src/pmc/ (2 files):
20:40 dalek parrot: per deprecation TT #1904, FixedPMCArray should not support any resizing operations (including set_pmc)
20:40 dalek parrot:
20:40 dalek parrot: however, code reasonably expects RPA to support this opperation, so move the supporting code there
20:40 dalek parrot: review: https://github.com/parrot/parrot/commit/2011cf343e
20:40 dalek parrot: 34e414d | plobsing++ | t/pmc/ (2 files):
20:40 dalek parrot: move set_pmc tests from FPA to RPA, same as functionality move
20:40 dalek parrot: review: https://github.com/parrot/parrot/commit/34e414d601
20:42 plobsing_ can someone independantly confirm that bdfe6ab reasonably satisfies TT #1926?
20:45 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:48 dalek parrot: 2efcf43 | plobsing++ | api.yaml:
20:48 dalek parrot: add TT #1904 deprecation to api.yaml (was missed in import)
20:48 dalek parrot: review: https://github.com/parrot/parrot/commit/2efcf4306e
20:49 PacoLinux_ joined #parrot
20:53 dalek parrot/mls/sub-profiler: cf02146 | plobsing++ | compilers/pct/src/PCT/HLLCompiler.pir:
20:53 dalek parrot/mls/sub-profiler: Merge branch 'master' of github.com:parrot/parrot
20:53 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/cf02146c32
20:53 dalek parrot/mls/sub-profiler: 81ae7de | cotto++ | / (28 files):
20:53 dalek parrot/mls/sub-profiler: Merge branch 'master' into mls/sub-profiler
20:53 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/81ae7dea32
20:53 dalek parrot/mls/sub-profiler: d37407c | cotto++ | / (5 files):
20:53 dalek parrot/mls/sub-profiler: break sub profiling code into its own files
20:53 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/d37407c7a0
20:54 plobsing_ tadzik: I count 10 TTs in the nuked DEPRECATED.pod not present in api.yaml
20:55 tadzik huh, now I feel stupid
20:55 plobsing_ git show 95d715cfeb256214c30575f613a792298c8d25e0 | grep 'ticket/' | pnle '/(\d+)/; say $1' | sort -u > DEPRECATED.pod.tickets
20:55 plobsing_ likewise for api.yaml
20:55 plobsing_ then view the diff
20:56 plobsing_ alias pnle = 'perl -nlE'
20:57 tadzik okay, my fault. Sorry for that
20:59 plobsing_ no problem now. it was quite infuriating at the moment of discovery.
20:59 plobsing_ there are sins a computer can commit worse than the loss of user data
20:59 plobsing_ s/are/are few/
21:04 plobsing_ 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
21:05 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
21:05 tadzik maybe ticket: should be an array, if there's a need for that. Otherwise, we can have a place like "see also"
21:06 plobsing_ I'm creating a 'tickets' entry as an array
21:09 tadzik I'm going through the first version of DEPRECATED.yaml manually to see what's missing
21:15 plobsing_ I've got about half manually imported
21:17 tadzik not pushed?
21:17 tadzik I've already added like 3
21:18 cotto_work mls: are you on parrot-dev?
21:18 plobsing_ tadzik: not yet
21:18 plobsing_ I will now
21:18 tadzik okay
21:19 tadzik oh, I now see what you meant about multiple tickets
21:21 dalek parrot: d74dbbe | plobsing++ | api.yaml:
21:21 dalek parrot: manually import into api.yaml several previously missed deprecations
21:21 dalek parrot: review: https://github.com/parrot/parrot/commit/d74dbbe0c7
21:23 tadzik I'll go through the rest of them
21:26 dalek parrot: 4092f78 | plobsing++ | api.yaml:
21:26 dalek parrot: manually import more deprecations into api.yaml. hopefully thats the last of them
21:26 dalek parrot: review: https://github.com/parrot/parrot/commit/4092f7829d
21:26 plobsing_ tadzik: I think I got 'em all, but it would be great if you could double check
21:27 tadzik plobsing_: what does grep -c 'name:' give you now?
21:28 plobsing_ 63
21:28 plobsing_ grep -c 'name\s*:' api.yaml => 78
21:29 tadzik okay
21:29 tadzik I'll go to the end of the old DEPRECATED.pod and see if I'll get the same number
21:29 plobsing_ there have been deprecations added since DEPRECATED.pod was nuked, so your number should be slightly lower
21:30 tadzik I know, I'm editing the new api.yaml
21:31 tadzik damn, I counted 77
21:34 tadzik plobsing++ # fixing what I screwed up
21:36 tadzik everything seems fine now
21:37 plobsing_ going through those tickets, they were all eligible in 3.1. perhaps there was a race condition on your branch merge.
21:37 plobsing_ or something similar
21:46 RobertLJ1 left #parrot
21:46 dalek TT #1904 closed by plobsing++: [DEPRECATED] assign on FPA
21:46 dalek TT #1904: http://trac.parrot.org/parrot/ticket/1904
21:56 pmichaud_ hmmm.... the mls/sub-profiler branch no longer profiles, it seems :(
21:56 pmichaud_ unless I missed something
22:00 cotto_work looking into it
22:11 Limbic_Region joined #parrot
22:18 pmichaud_ is it still "-R slow" to get the profiling output in the sub-profiler branch?
22:20 cotto_work pmichaud_: looks like we're using the parrot2 frontend now
22:20 cotto_work I'll have a fix in a sec
22:20 pmichaud_ cotto_work: okay, thanks.
22:22 dalek parrot/mls/sub-profiler: 2d18c6d | cotto++ | / (2 files):
22:22 dalek parrot/mls/sub-profiler: nuke leftover pod, enable sub profiler in parrot2 frontend
22:22 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/2d18c6d7a2
22:22 cotto_work pmichaud_: there you go
22:23 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
22:23 cotto_work I got it to spit out some kind of profile.
22:23 cotto_work with -Rslow
22:25 pmichaud_ building now
22:26 cotto_work should be sunshine and rainbows
22:36 rfw joined #parrot
22:50 pmichaud_ sunshine and rainbows it is.  cotto_work++
22:52 cotto_work just don't look at the code. ;)
23:00 nbrown joined #parrot
23:04 whiteknight joined #parrot
23:05 cotto_work hio whiteknight
23:05 whiteknight helloio, cotto_work
23:07 whiteknight plobsing++ on the whiteknight/frontend_parrot2 merge
23:24 whiteknight I'm going to update the mls/sub-profiler branch to master now
23:25 Coke joined #parrot
23:26 whiteknight mls: ping
23:33 cotto_work whiteknight: please do
23:33 cotto_work what's your plan?
23:33 whiteknight I can't build that branch. missing reference to rdtsc
23:34 whiteknight should I just push anyway?
23:34 whiteknight what plan, for what?
23:35 sorear whiteknight: what kind of computer do you have?
23:35 whiteknight sorear: a normal one?
23:35 cotto_work sorear: that should be a thing on x86 and x86_64
23:35 cotto_work whiteknight: I can test.  Push away.
23:36 dalek parrot/mls/sub-profiler: 8f1d154 | Whiteknight++ | / (7 files):
23:36 dalek parrot/mls/sub-profiler: Merge branch 'master' into mls/sub-profiler
23:36 dalek parrot/mls/sub-profiler: review: https://github.com/parrot/parrot/commit/8f1d154f32
23:36 sorear whiteknight: there are no "normal" computers yet.
23:37 sorear whiteknight: rdtsc exists at all only on PC clones and Intel Macs
23:37 whiteknight then, I must have an abnormal one
23:37 benabik rdtsc?
23:37 benabik 404 Manpage not found
23:37 cotto_work http://en.wikipedia.org/wiki/Time_Stamp_Counter
23:38 cotto_work 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?
23:38 cotto_work Parrot_hires_get_time
23:38 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"
23:39 cotto_work plobsing_: much better.
23:39 cotto_work plobsing++
23:39 sorear cotto_work: read mls' mail carefully.  Doing that would defeat the entire point
23:39 plobsing_ good enough for me. closing ticket.
23:39 sorear cotto_work: Parrot_hires_get_time is too slow for use in the mls profiling runcore
23:40 plobsing_ sorear: mls has admitted he used that based on intuition and never actually tested
23:40 plobsing_ premature optimization
23:40 cotto_work sorear: I'll buy that when I see a profile that confirms it.
23:41 cotto_work though I'll profile if when I switch and see what the impact is.
23:41 sorear don't profile, measure.
23:41 cotto_work ?
23:41 benabik Isn't profiling measuring?
23:42 cotto_work actually, I can do that now
23:45 cotto_work I see a significant increase.
23:45 cotto_work sorear: looks like you're correct.
23:46 cotto_work 17s with the hires thingy vs 6.3s with rdtsc
23:47 cotto_work running ./parrot -Rslow examples/benchmarks/oofib.pir 28 2>/dev/null
23:49 cotto_work though kcachegrind says it shouldn't be doing that
23:49 benabik ?
23:50 cotto_work kcachegrind says that Parrot_hires_get_time is at about 5%
23:50 benabik but it takes 100% longer? poor
23:51 cotto_work I'm probably messing something up
23:52 sorear benabik: this is what I mean when I say profiling isn't a substitute for measuring
23:53 benabik sorear: Fair enough.
23:53 benabik Is rdtsc in a function?  We'll need to figure out some way to figure out the cross-platform aspects of this.
23:54 plobsing_ benabik: rdtsc is a machine instruction
23:55 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
23:55 dalek TT #1926: http://trac.parrot.org/parrot/ticket/1926
23:55 plobsing_ benabik: it is isolated in a function, which we can select an appropriate implementaton of at configure-time.
23:55 benabik plobsing_: Excellente.
23:57 cotto_work benabik: yes

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

Parrot | source cross referenced