Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
00:00 dmalcolm left 00:02 gbacon joined
dukeleto soh_cah_toa: i see what you've done :) 00:03
soh_cah_toa: git remote rename origin upstream; git remote rename github origin <-- this renames your fork as "origin" and then the canonical parrot repo as "upstream" 00:04
soh_cah_toa: with that setup, by default, all the git commands will be working on your fork, which will probably be a lot more intuitive for you 00:05
soh_cah_toa: "git push" will push to your fork, for example
soh_cah_toa dukeleto: ok, i think you're right
dukeleto: while we're on the subject...is there any way to rename a branch? 00:07
dukeleto soh_cah_toa: git branch -m old new
soh_cah_toa: git help branch is your friend :)
soh_cah_toa dukeleto: yeah, git man pages are pretty well written 00:08
cotto dukeleto, M0 should be safe for you to hack on this evening. I'll either do other things or sync with you first.
dukeleto soh_cah_toa: go read the section called "Maintain a Fork" here github.com/parrot/parrot/blob/mast...rkflow.pod
cotto: status => acceptable :)
soh_cah_toa dukeleto: ok
dukeleto soh_cah_toa: they are extensive. Some are less approachable than others :) 00:09
soh_cah_toa dukeleto: ok, so i've made my changes on the master branch and commit but i don't know what to push to 00:16
cotto soh_cah_toa, did you make the changes to a clone of parrot/parrot.git or your clone? 00:20
soh_cah_toa cotto: i'm not really sure 00:22
dukeleto soh_cah_toa: you ran commit locally, right ? 00:23
dalek rrot: 2b2dc13 | dukeleto++ | / (2 files):
[doc] Improve our Git workflow
dukeleto soh_cah_toa: try doing a "git push" 00:24
soh_cah_toa: what happens?
soh_cah_toa: just type: git push<ENTER>
soh_cah_toa i did but it seems like it's using upstream instead of origin. git push says "You can't push to git://github.com/parrot/parrot.git" 00:25
i think it's b/c i branched soh-cah-toa/hbdb from parrot/parrot but i've been pushing to soh-cah-toa/parrot (my github fork) 00:27
dalek rrot: 14a6c68 | Whiteknight++ | src/dynpmc/os.pmc:
Add an .exists() method to OS. Returns 1 if the specified file exists.
 00:30
dukeleto soh_cah_toa: i see. your branch is tracking the read-only URL still 00:36
soh_cah_toa: try "git push origin" 00:37
soh_cah_toa dukeleto: it says everything's up to date 00:38
great, now i can't even switch back to soh-cah-toa/hbdb because upstream/master is ahead by 1 commit and for some reason my gsoc code from soh-cah-toa/hbdb is in master 00:42
00:44 kid51 joined
soh_cah_toa i must have some magnetic attraction to brick walls because i've been doing nothing but running into them lately :\\ 00:44
00:49 gbacon left
dalek sella: c8999dc | Whiteknight++ | t/query/ (2 files):
Add tests for sort so we don't regress on it
 00:49
sella: 872003c | Whiteknight++ | s (2 files):
Fix File so it builds and runs a short example again
sella: a3c9e13 | Whiteknight++ | s (2 files):
update setup.winxed to build include files with libraries. Factor out the STAT constants into a separate file, since they are inexplicably different from the constants in the stat.pasm file in the parrot repo
sella: a1df406 | Whiteknight++ | src/unstable/file/File.winxed:
Add exists method to File, mirroring the new method added to OS. Add a copy method to File
sella: eff1963 | Whiteknight++ | s (4 files):
Refactor is_file and is_directory logic out into separate functions. Flesh out details of various Directory methods
nopaste "soh_cah_toa" at 192.168.1.3 pasted "More Errors...Yippee" (12 lines) at nopaste.snit.ch/47551
whiteknight soh_cah_toa: that's what happens when you use software that other people aren't using often
delete that main.c folder, or rename it to something 00:51
soh_cah_toa whiteknight: will that effect the soh-cah-toa/hbdb branch though? b/c that file shouldn't even be in the master branch to begin w/ 00:52
cotto soh_cah_toa, do you have any unpushed changes? If not, it's safe to nuke the file.
whiteknight it may just be a leftover. Rename it to something else, then pull
soh_cah_toa alright, looks like deleting it was fine 00:54
cotto: what subdirectory of t/ do you think my test file should go in? 00:56
cotto soh_cah_toa, are you planning on having only one test file? 00:57
soh_cah_toa cotto: no, i meant tests. typo 00:58
cotto soh_cah_toa, in that case they should go under t/hbdb
soh_cah_toa cotto: alright
01:04 theory left
cotto soh_cah_toa, are you doing ok getting git untangled? 01:11
soh_cah_toa cotto: i think it's ok for now. i would like to fix things in the future like actually branching from soh-cah-toa/parrot and not parrot/parrot but that can wait. right now i'm working on my tests 01:13
cotto excellent
Tests are great. Passing tests are even better. 01:14
soh_cah_toa some breakpoints would be even better but i wanna test what i've got so far before moving on 01:15
01:16 davidfetter left
cotto soh_cah_toa, you can always write tests before you implement the relevant feature. 01:17
soh_cah_toa cotto: i know but i'm still unsure about the stuff from last night 01:18
cotto soh_cah_toa, you mean how you're going to implement breakpoints? 01:19
soh_cah_toa cotto: yeah, since i'm not going to use the opcode method anymore
01:20 silug left
cotto soh_cah_toa, that shouldn't matter for tests. 01:20
soh_cah_toa cotto: well, for this part at least, i'd like to do them afterwards b/c this is really bothering me 01:21
cotto your call 01:22
soh_cah_toa well, once i get these few tests written i wanna brainstorm w/ you about it 01:24
cotto soh_cah_toa, when were you thinking? 01:30
soh_cah_toa cotto: a half hour maybe
cotto k
whiteknight where is rand now? 01:39
cotto dynop iirc
dukeleto soh_cah_toa: does hbdb stand for something? 01:53
soh_cah_toa dukeleto: hbdb = honey bee debugger. it's a nickname i gave to one my cats, sophie 01:54
01:54 whiteknight left
dukeleto soh_cah_toa: i like it. as long as I can pronounce it "heebee deebee" too ;) 01:59
sorear apparently github emails me whenever people comment on nqp commits 02:00
soh_cah_toa dukeleto: lol everyone pronounces it funny. cotto calls it hubdub
sorear maybe I should disable my email address on github? *glances at dukeleto* 02:01
02:02 gbacon joined
dukeleto sorear: go to your notification center, in your github user admin 02:02
sorear: turn everything off. that might help :)
sorear: you get an email because you are listed as an admin for the org 02:03
sorear I think 'cappy' is short for 'capture', btw 02:04
dukeleto sorear: ah. that makes more sense. Makes them seem almost jovial 02:05
cotto very small edit distance from another word though 02:06
bubaflub evening dukeleto 02:09
02:09 kid51 left 02:21 arnsholt left, arnsholt joined 02:23 benabik left 02:24 benabik joined 02:25 woosley joined 02:27 bluescreen joined 02:31 bluescreen left 02:40 contingencyplan left
soh_cah_toa cotto: i'd like to show you an error i'm getting in one of my tests but for some reason i can't push now. git says that everything's up to date 02:42
02:43 contingencyplan joined
bubaflub soh_cah_toa: are you pushing to github? what branch are you on? 02:47
soh_cah_toa i'm on branch soh-cah-toa/hbdb and i'm trying to push to origin (git@github.com:soh-cah-toa/parrot.git)
atrodo what branch do you have checked out? 02:49
soh_cah_toa soh-cah-toa/hbdb
atrodo try git push origin soh-cah-toa/hbdb 02:50
soh_cah_toa there we go. i think it was b/c github wasn't tracking soh-cah-toa/hbdb because i renamed it from soh-cah-toa/pdb 02:51
atrodo that'd be why
cotto soh_cah_toa, hmm 02:53
soh_cah_toa in my github fork, is everything reflected from parrot/parrot? i mean, if someone pushes to the parrot/parrot repo, does my soh-cah-toa/parrot repo get the changes?
cotto soh_cah_toa, no. If you want some changes from parrot.git, you'll need to resync 02:54
soh_cah_toa ok
cotto: now that that's solved, take a look at t/hbdb/main.t. how am i able to test argv? i want to test that Parrot_api_string_import_ascii() succeeds but i use argv[1] as one of its arguments 02:56
cotto looking
soh_cah_toa cotto: the other thing is that i can't find the point of failure in test 2 02:57
cotto soh_cah_toa, why are you testing C at all? Covering normal usage of hbdb should cover all the relevant C code. 02:58
soh_cah_toa cotto: you don't think it's worth testing? 03:00
cotto: hmm...i do see you're point 03:01
*your
cotto testing a debugger requires more thought since the debugger is designed to run interactively, but you're in a good place to think about how to do it 03:02
dukeleto, does the current debugger have some tests? istr you doing some work in that area. 03:03
soh_cah_toa cotto: yeah, i suppose once i actually have a working program those tests would be redundant. very redundant 03:04
03:04 gbacon left
cotto soh_cah_toa, and you'd have to update them if you wanted to mess with hbdb's internal 03:05
*internals
soh_cah_toa cotto: oh yeah, that makes it even worse
cotto aloha, coverage?
aloha cotto: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
soh_cah_toa cotto: there are some old tests for the current debugger. dukeleto sent them to be but i bookmarked them in my other os so i can't get the link now 03:07
cotto The current debugger seems to be not entirely untested.
soh_cah_toa, do you remember where they were, i.e. which branch?
and file 03:08
soh_cah_toa i didn't notice
cotto I don't see any likely branches in parrot/parrot or any files in master
soh_cah_toa well, i can take a look at them when i reboot later. what i'm really concerned w/ is breakpoints 03:10
i suppose the runcore needs to be able to read bytecode annotations 03:11
cotto soh_cah_toa, an important thing to steal is a viable strategy for making hbdb amenable to testing. If it's too hard to write tests or if they're too noisy, it'll discourage you from writing them.
eventually, yes
think about how to make testing features easy 03:12
soh_cah_toa i'm thinking looping until the line annotation == what user entered and then break
03:15 JimmyZ joined
soh_cah_toa i guess what's stumping me is how to alter the runcore's behavior 03:15
cotto the runcore executes one op at a time. Between ops you can do whatever you feel like. 03:16
soh_cah_toa right, but i mean...what functions do i even look at? how do i execute one op? 03:17
cotto DO_OP(pc, interp); 03:18
03:19 theory joined
sorear soh_cah_toa: why are you writing a runcore? 03:22
dalek rrot/leto/embed_grant: b16e00d | dukeleto++ | t/src/extend_vtable.t:
[t] Remove a suboptimal getprop test and regain Parrot_PMC_destroy coverage
 03:23
soh_cah_toa sorear: i don't even know, man. i'm so stumped 03:25
cotto sorear, my thinking is that it's simpler to put the debugger behavior in a runloop than to modify ops. 03:27
sorear cotto: what's so hard about modifying ops? 03:30
dalek rrot/leto/embed_grant: da488e4 | dukeleto++ | t/src/extend_vtable.t:
[t] Destroy most of the PMC's we use at the end of each test. Attempting to destroy the ResizablePMCArray's causes a double free
 03:31
cotto sorear, Parrot's ops are messy. At times they can be variadic. 03:32
a custom runcore means fewer special cases 03:33
dalek rrot/leto/embed_grant: d41d1c9 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_get_pointer_keyed
 03:39
sorear cotto: the length of the op doesn't matter, only the first word needs to be modified 03:40
x86 ops are very messy too
cotto this is true
quite a bit more than Parrot's
dalek rrot/leto/embed_grant: a7ed854 | dukeleto++ | t/src/extend_vtable.t:
Destroy our Namespace PMC at the end of testing
 03:41
04:01 JimmyZ left 04:08 wagle_ joined
dalek rrot/leto/embed_grant: 021999b | dukeleto++ | t/src/extend_vtable.t:
Add a commented-out test for Parrot_PMC_get_pointer_keyed_int. Need to create an Object PMC
 04:09
rrot/leto/embed_grant: 74019f3 | dukeleto++ | t/src/extend_vtable.t:
[t] Gain some test coverage of Parrot_PMC_newclass
04:09 ingy left 04:10 allison left, wagle left
dalek rrot/leto/embed_grant: 56fa3c4 | dukeleto++ | t/src/extend_vtable.t:
Destroy our Class and Object PMCs after testing
 04:11
cotto dukeleto, is it safe to assume that you're not going to be touching M0 tonight?
dalek rrot: b16e00d | dukeleto++ | t/src/extend_vtable.t:
[t] Remove a suboptimal getprop test and regain Parrot_PMC_destroy coverage
 04:12
rrot: da488e4 | dukeleto++ | t/src/extend_vtable.t:
[t] Destroy most of the PMC's we use at the end of each test. Attempting to destroy the ResizablePMCArray's causes a double free
rrot: d41d1c9 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_get_pointer_keyed
rrot: a7ed854 | dukeleto++ | t/src/extend_vtable.t:
Destroy our Namespace PMC at the end of testing
rrot: 021999b | dukeleto++ | t/src/extend_vtable.t:
Add a commented-out test for Parrot_PMC_get_pointer_keyed_int. Need to create an Object PMC
rrot: 74019f3 | dukeleto++ | t/src/extend_vtable.t:
[t] Gain some test coverage of Parrot_PMC_newclass
rrot: 56fa3c4 | dukeleto++ | t/src/extend_vtable.t:
Destroy our Class and Object PMCs after testing
rrot: c0d0b11 | dukeleto++ | t/src/extend_vtable.t:
Merge branch 'leto/embed_grant'
04:14 allison joined 04:26 ingy joined 04:32 soh_cah_toa left
cotto hello.m0b has the right number of bytes 04:46
violently fails some tests though 04:47
clearly we need fewer tests 04:48
04:50 davidfetter joined 04:52 birdwindupbird joined
dalek rrot/m0-prototype: f7fb144 | cotto++ | src/m0/m0_assembler.pl:
fix bytecode segment length calculation
 05:12
rrot/m0-prototype: 1d9e2ee | cotto++ | src/m0/m0_assembler.pl:
tighten chunk parsing regex a bit, remove todone todos
rrot/m0-prototype: b80daa1 | cotto++ | src/m0/m0_ (2 files):
fix bytecode op count calculation
rrot/m0-prototype: 8a03024 | cotto++ | src/m0/m0_interp.pl:
undo accidental commit
 05:13
05:17 davidfetter left
cotto dukeleto, !!! 05:26
nopaste "cotto" at 192.168.1.3 pasted "M0 lives!!!!" (20 lines) at nopaste.snit.ch/47612 05:29
dalek rrot/m0-prototype: 1c1a7e4 | cotto++ | t/m0/hello_canon.m0b:
fix minor goof in hello_canon.m0b

was using 11 (0x0B) for I0 instead of 12 (0x0C) in the last two ops
rrot/m0-prototype: 15be142 | cotto++ | src/m0/m0_assembler.pl:
fix thinkos, generate runnable hello.m0b!
cotto dukeleto, there's some difference between hello.m0b and hello_canon.m0b, but both run 05:30
05:32 bubaflub left
dukeleto cotto: whoa! 05:35
05:35 mtk left
dukeleto cotto: nicely done 05:36
05:36 fperrad joined
cotto dukeleto, I'm excited. 05:37
dukeleto, if you're bored, most of the m0 assembler tests fail 05:39
cotto sleeps
05:42 mtk joined 06:08 theory left 07:38 mj41 joined 07:57 mj41 left 08:08 ShaneC joined 09:10 jsut_ joined 09:15 jsut left 09:59 woosley left 10:01 cosimo_ left 10:07 cosimo joined 10:37 lucian joined 10:43 lucian_ joined 10:47 lucian left 11:03 Psyche^ joined 11:08 Patterner left, Psyche^ is now known as Patterner 11:13 birdwindupbird left 11:16 birdwindupbird joined 11:21 contingencyplan left 12:06 whiteknight joined 12:10 lucian_ left
whiteknight scifac.ru.ac.za/compilers/conts.htm 12:10
good morning, #parrot 12:15
benabik Morning, #parrot! Morning, whiteknight! 12:16
whiteknight hello benabik
xenoterracide particle: any chance you're about?
atrodo =~ 12:17
whiteknight particle is on the west coast USA. I'm sure he's still asleep 12:19
or, recently just awake
xenoterracide whiteknight: well I've been trying to ping him for like 2 weeks... 12:20
whiteknight xenoterracide: I do know he's pretty busy lately 12:21
I haven't seen him in a few weeks either
xenoterracide whiteknight: right. worth knowing. trying to get a hold of him to see if he'll let me take over maintenance of Test::Version for p5 on CPAN
whiteknight xenoterracide: you might want to try emailing him. Otherwise, I suggest you fork it on gitpan and just start hacking. Eventually he'll come back and see a huge pile of pull requests 12:22
:)
xenoterracide whiteknight: I've done a rewrite, but some people talked me into trying to get the namespace... do you have an email for him that works? only one I found was particle@cpan .. tried that 3 weeks ago 12:24
whiteknight xenoterracide: privmsg 12:25
Coke_ particle? 12:29
aloha, particle?
aloha Coke_: particle are any of these students spanish speakers.
Coke_ no, particle is Jerry Gay
aloha, particle?
aloha Coke_: particle is Jerry Gay
12:31 bubaflub joined
whiteknight seen particle? 12:41
aloha particle was last seen in #parrot 1 days 5 hours ago joining the channel. 12:42
Coke_ Haven't heard from Jerry in ages. 12:43
nearly since last yapc.
13:08 jsut joined 13:13 jsut_ left, ambs joined 13:42 bluescreen joined
benabik On a PIR sub, what do the arguments to :multi mean? 14:32
14:33 hercynium joined
benabik I think the first argument is the return type, based on what I'm seeing in PAST::Compiler. But that's a guess. 14:35
whiteknight I think it's just arguments, not returns 14:36
The dispatcher wouldn't know what the return type is
and there could be no returns at all, or multiple returns 14:37
benabik .sub 'as_post' :method :multi(_, Integer) \\n .param pmc node \\n .param pmc options :slurpy :named
whiteknight the first item might be the invocant
benabik Ah!
whiteknight I don't use multis often, because winxed doesn't currently support them 14:38
benabik That makes sense. (And is completely undocumented...)
whiteknight benabik: feel free to write down some documentation for it, if you want
help save the next coder so much trouble
benabik I'm going to open a ticket and assign it to me... I'd write a patch now but I'm not sure we're right. (And I personally find no doc preferable to wrong doc.) 14:45
tcurtis benabik: whiteknight is right, iirc. 14:46
The first argument is the invocant.
benabik Hm. Another vote in that favor. I guess I'll make the patch after all. 14:47
Although how is the invocant going to have a type other than the class being written?
IOW, why would a method in PAST::Compiler have an invocant that wasn't a PAST::Compiler object? 14:48
tcurtis benabik: why not? It's perfectly possible to call a PAST::Compiler method on any random object. 14:52
Not to say that it's a good idea.
benabik tcurtis: How?
And it seems like a very poor idea. 14:53
tcurtis benabik: find_method, then invoke it, I think.
whiteknight benabik: It's not a matter of the invocant changing type, unless you subclass. It's a matter of the invocant being just another argument as far as MMD is concerned 14:54
it's just another arg on the front of the list
tcurtis benabik: again, not a good idea, but it's an option with normal methods, so it makes sense for it to be possible to leave it as an option for multimethods. 14:55
14:57 theory joined 15:07 baest_ joined
cotto ~~ 15:07
15:09 baest_ left
whiteknight gist.github.com/993341 15:13
those are the kinds of results I was hoping for
benabik ~15% improvement for 10000 entries? Nice. 15:14
whiteknight 22% decrease, isn't it 15:15
Coke_ Hopefully we can pull those changes into core so I don't have to do extra work to go faster?
whiteknight Coke_: That's the plan. But since it's PIR and not a built-in method, there will be a little extra work to import it 15:16
Coke_ to write PMC methods in PIR now is evil and even slower.
benabik Ah, yes. sorry, I was comparing 0.85 to 1.0, not 1.1
Coke_ hurm. vtable overrides in PIR are even slower. methods themselves may not be. 15:17
whiteknight it's the nested runloops that are really slow
Coke_ Happy to wait until lorito hits, then.
whiteknight PIR->PIR method calls are pretty quick
Coke_ wonders whose idea it was to EVER write pmcs in c.
benabik Coke_: It seemed like a good idea at the time, I'd guess. 15:18
Coke_ ah well. onward and upward.
benabik: Hai.
whiteknight yeah, in hindsight writing those types in C has been a big problem
Coke_ supposes he should test partcl on the latest release to make sure it still works. 15:19
whiteknight The funny thing is that if we don't use the compare function, and instead let the sort method use it's default (written in C) comparisons, it speeds up by 80% 15:22
so the lions share of the cost is in the comparison routine, and calling the nested runloop specifically
The pure PIR version saves on runloop creation costs, but is still 400% slower than an all-C version 15:23
benabik Is a nested runloop essentially creating a new interpreter?
whiteknight no, same interpreter
benabik Then why is it so slow?
whiteknight but it recurses down into a new runloop function call
Do yourself a favor. One day when you have a few free moments, trace the execution flow from Parrot_pcc_invoke_sub_from_c_args all the way down to runops_int 15:24
dalek p: c46d7b0 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to 3.4.0. The old PARROT_REVISION (3.3.0) was

slower than it was in January 2011. Moving to Parrot 3.4.0 uses the GMS gc, which gives a huge overall performance speedup and an even bigger speedup for regexes and parsing.
whiteknight or, better yet, from Parrot_ext_call (which Parrot_util_quicksort uses) down to runops_in
runops_int
dalek TT #2122 created by benabik++: :method and :multi
TT #2122: trac.parrot.org/parrot/ticket/2122
cotto_work ~~ 15:34
15:37 theory left
dalek sella: 4d61ab2 | Whiteknight++ | src/query/Provider.winxed:
Fix selection of pivot so that a sorted array doesn't exhibit pathological performance
 15:39
sella: ac0ff60 | Whiteknight++ | s (2 files):
Inline the swap calls, and use var instead of int for types so we aren't unboxing/reboxing.
sella: 1fc8cc3 | Whiteknight++ | src/query/Provider.winxed:
inline the partition routine into the sort routine. No appreciable speedup in my benchmarks
15:39 xenoterracide left 15:46 dod left 16:13 AzureStone left 16:18 AzureStone joined 16:22 theory joined
cotto_work dukeleto: ping 16:29
16:31 dalek left, mj41 joined 16:32 lucian joined 16:35 TimToady left, sorear left 16:36 p6eval left
dukeleto cotto_work: pong 16:37
cotto_work dukeleto: can you take a look at line 326 of the m0 assembler and tell me the right way to do that?
16:37 dalek joined
cotto_work $op_count++ for ($bc_seg =~ /^\\s*\\w+/mg); 16:38
dukeleto cotto_work: only after I have made coffee :)
cotto_work dukeleto: that's an important dependency
16:39 p6eval joined
cotto_work ohai p6eval 16:39
dukeleto cotto_work: so you wanter to keep an op counter. Why not just count lines? Because you added labels? 16:40
16:40 TimToady joined
dukeleto s/wanter/want/ 16:40
TimToady: welcome back to the party
cotto_work dukeleto: I want to count non-empty lines
16:40 sorear joined
dukeleto cotto_work: what about label lines? 16:41
cotto_work dukeleto: do you think we should have those? I was thinking that labels would have to be on the same line as an op.
16:44 birdwindupbird left
cotto_work dukeleto: my assumption was that any line with 16:44
\\w would have an op
NotFound Allowing both kinds of labels can be easier code generators. 16:46
for
cotto_work NotFound: ok. That's an important data point. 16:47
NotFound Not very importante, but convenient. 16:48
16:49 mj41 left
benabik Does NQP have a something like `use 'PCT/HLLCompiler.pbc'` or do I just have to use `INIT { pir::load_bytecode('PCT/HLLCompiler.pbc'); }`? 16:50
whiteknight benabik: you have to do it with INIT
benabik The INIT block seems to work but is also not really easy to read.
pmichaud "nqp-rx" 16:51
whiteknight yes, that's for nqp-rx
benabik Yes. Sorry, when I speak of NQP I mean parrot-nqp. :-/
pmichaud "nqp" has an improved use statement. 16:52
cotto_work delightful
dukeleto cotto_work: coffee is still percolating to my brain. I will take a look at the m0 tests in a few 16:53
pmichaud aloha msg bacek did you mean "gc_tuning" branch instead of "gc_tuneup" branch? I can't find the latter. 16:54
aloha pmichaud: OK. I'll deliver the message.
benabik imcc-- # line numbers shouldn't be hard! 16:56
dukeleto benabik: patches/blowtorches welcome 17:00
benabik I'm really really hoping I can get inline nodes running via PIRATE by the end of summer. It would really pave the way for never having to touch IMCC. 17:01
It looks like IMCC is skipping some type of line, since the line number is always too low and it seems the farther in the file, the more its off. 17:02
whiteknight line number handling is screwed up by heredocs, at least 17:06
I don't know what else would do it
many a brave soul has fought that battle and lost 17:10
TimToady well, there's a right way and a wrong(ish) way to do line numbers
the wrong(ish) way is to do linenum++
whiteknight there's a right way, a wrong(ish) way, and the Parrot way
TimToady the right way is just to remember a file position and then map that back to line numbers at need 17:11
whiteknight or, more specifically, the IMCC way
TimToady s/file/string/
doing it the wrong(ish) way means you cannot reliably delegate line counting to any new sublanguage that might traverse line endings, such as a heredoc parser 17:13
and any sublanguage that gets the line count off affects everything after it 17:14
(and yes, we did it wrong in Perl 5 :)
pmichaud
.oO( "The Voice Of Experience!" )
 17:15
benabik My hope is that PCT will propagate line and file information from match objects into the packfile.
Although that doesn't help IMCC any
pmichaud PCT already does this. :) 17:16
although you mean "directly into the packfile", without going through PIR, I guess?
benabik pmichaud: Yes.
whiteknight Unfortunately, getting IMCC to be smarter about line numbers is going to require some real technical skill, in addition to a flashlight, a shovel, and a rosary
cotto_work I wonder how hard it'd be to fix imcc and if the pain of doing so would outweigh the pain of continuing to use broken line numbers.
whiteknight ...I'll bring the shovel
benabik pmichaud: And somebody appears to be ignoring .file and .line annotations. My backtraces have PIR line numbers. 17:17
pmichaud cotto_work: my impression has been that every attempt to fix imcc line numbers has just caused them to be broken in a different way.
whiteknight we're at the point now where the breakage is not absurd
pmichaud benabik: we definitely use .file/.line annotations in Rakudo. Parrot tends to ignore them.
cotto_work pmichaud: mine too, though sometimes it's decreased the drasticness of how broken they are.
benabik whiteknight: It's at least 500 lines off in the backtrace I'm working on. 17:18
cotto_work TimToady: do you know of a compiler that does line numbers the right way?
pmichaud Rakudo? PCT? ;-)
whiteknight benabik: Prior to the current round of fixing, linenumbers were up around INT_MAX
benabik whiteknight: Oh. That's... I don't even know. 17:19
pmichaud last time I complained about line numbers, they were consistently reporting "1"
cotto_work pmichaud: great.
whiteknight oh yes, being told that every error is happening on line 1 brings it's own brand of hilarity
benabik Okay, apparently I should stop complaining... Other than the fact that the line number as is means I have _no idea_ what's broken.
cotto_work whiteknight: but that means everything is a one line fix 17:20
pmichaud cotto_work: alas, if that were only the case.
whiteknight benabik: take solace. PIRATE won't have as many of these problems and your job is to get PIRATE working more better 17:21
gooder and more better
pmichaud afk, walk 17:23
benabik whiteknight: Yes. Hopefully IMCC will be an optional part of compiling by the end of summer. Not quite sure I'll get everything needed for that, but I'm trying.
whiteknight benabik: I'm squarely in your corner. I *really* want this project to succeed 17:24
I don't think we would be able to get rid of IMCC completely for performance reasons, but I would love to see it minimized 17:25
NotFound benabik: Do you indent your generated code?
whiteknight ah yes, indentations have an effect on line numbering, for some reason
NotFound ... for some lack of reason.
cotto_work NotFound++ 17:26
benabik NotFound: Uhm, it is intended inside the Q:PIR blocks. Should I stop that?
whiteknight I think it needs to be indented
everything needs to be
benabik is currently just wrapping existing NQP method definitions around great big Q:PIR blocks.
whiteknight I don't know how PCT is going to handle that 17:27
benabik Handle what now? 17:29
whiteknight those Q:PIR blocks
I don't know what effect that has
pmichaud my intent is that Q:PIR should go away
benabik Q:PIR is really really handy when converting existing PIR.
pmichaud or be used extremely rarely, if at all. they got over-used in rakudo.
benabik But should probably be really really avoided otherwise. :-D
whiteknight: IIRC, Q:PIR gets turned into PAST inline nodes. I intend to hand those blocks off to PIRATE, tweaking PIRATE if it can't quite handle the lack of context. 17:31
cotto_work I'd love to be able to avoid it almost completely.
whiteknight avoid what, Q:PIR?
cotto_work yes
whiteknight PIR is something everybody should try to avoid, in the future
pmichaud I only introduced Q:PIR because I thought there would be a few cases where a programmer might want to drop down to PIR directly. Also, Q:PIR predates the (far superior) pir:: notation.
whiteknight we shouldn't be writing any of it by hand, or vanishingly little of it 17:32
cotto_work It usually feels like workaround for a missing feature in nqp-rx.
NotFound Maybe now you see why I refuse to add too much inlining pir features to winxed ;)
whiteknight winxed doesn't even offer block PIR literals, and I very rarely miss it
benabik cotto_work: It really does. I'd like something other than pir::defined to handle optional parameters, for example.
whiteknight Typically when I need any PIR ops at all, I can use the few I am missing directly instead of needing a whole block for it 17:33
pmichaud oh, I've been planning to add the 'defined' operator to NQP
whiteknight +1
pmichaud just never got around to it
NotFound I added it to winxed for that same reason.
pmichaud afk, walk for real this time 17:34
NotFound And exists
benabik `$var = Undef if !$has_var; if( defined $var ) ...` seems a little roundabout to me. I keep wanting a way to just get to the :opt_flag. 17:38
Although I'd probably not care if I wasn't converting straight from PIR. 17:39
17:40 mj41 joined
NotFound Pir optionals aren't undefined when not provided, they are null 17:44
benabik NotFound: NQP replaces it with an Undef. 17:45
whiteknight There are probably about 10-20 PIR ops I use in Rosella pretty regularly that I don't think winxed provides a direct analog for 17:46
4-argument getattr and setattr are indispensible for now
can and isa are important
dalek rrot: 4046b69 | cotto++ | lib/Parrot/Test.pm:
various English fixes in inline POD, patch courtesy of soh_cah_toa++
 17:47
NotFound whiteknight: You have instanceof
whiteknight oh right, that's isa
wait, I had a problem with instanceof. I don't think it works with a class object, only a class name 17:48
NotFound whiteknight: please open an issue with an use case.
whiteknight I'll have to put together a test case, if I can even remember it clearly 17:49
benabik So since this line number is useless, does anyone have any idea how to figure out where in the code it's dying?
whiteknight winxed has defined()? 17:50
I must have missed that
dukeleto benabik: use bisection
dalek TT #2121 closed by cotto++: Mistakes in lib/Parrot/Test.pm Perldoc
TT #2121: trac.parrot.org/parrot/ticket/2121
dukeleto benabik: with a die or something like that. Not pretty, but it works.
benabik dukeleto: What's the easy way to have PIR do say or die? Is it as simple as `die "testing"`? 17:51
cotto_work benabik: yes
benabik woo
NotFound Oh, wait, I fooled myself, it has only exists. 17:52
whiteknight okay, that's what I thought
Okay, the list of PIR ops I need in Winxed is actually pretty large 17:53
benabik Ah! using .param inside Q:PIR isn't a good idea. 17:55
17:56 tcurtis_ joined, tcurtis left
whiteknight that's...weird 17:56
and that causes the linenumber failures?
17:56 KaeseEs left, KaeseEs joined
benabik whiteknight: No, but it causes the failure I couldn't find due to the linenumber issues. 17:56
whiteknight ah, okay 17:57
yes, the parsing of .param is extremely inflexible
no small part of the reason why I want to redo parameter parsing entirely
benabik whiteknight: It was dying at runtime saying something like "vtable 'get_integer' not found on type Capture" 17:58
whiteknight oh, fun
those are the great kinds of errors
dukeleto cotto_work: i am going to merge master into m0-spec so we don't see IPv6 test failures in jitterbug (which were fixed in master before m0-spec branched) 18:00
cotto_work: s/before m0-spec branched/after m0-spec branched/
cotto_work dukeleto: go for it
dukeleto cotto_work: actually, it is m0-prototype 18:01
cotto_work: but it shouldn't matter much to us
cotto_work dukeleto: nope
should be a really easy merge too 18:02
dalek rrot/m0-prototype: 4046b69 | cotto++ | lib/Parrot/Test.pm:
various English fixes in inline POD, patch courtesy of soh_cah_toa++
rrot/m0-prototype: 63d93f0 | dukeleto++ | / (252 files):
Merge branch 'master' into m0-prototype

Conflicts:
  \t.gitignore
dukeleto almost at 80% test coverage for tapir2.ro.vutbr.cz/cover/latest-c_c...ble-c.html ... 18:07
benabik Wow. I'm getting the wrong _file_ on my backtrace now. How'd I manage that one? 18:08
dukeleto Writing those tests sure is a good way to understand how our vtables work.
benabik: special surprise! IMCC must like you.
benabik dukeleto: Feeling not mutual.
18:08 gbacon joined
whiteknight getting the wrong file? 18:13
benabik whiteknight: current instr.: 'parrot;PAST;Compiler;node_as_post' pc 8228 (compilers/pct/src/PAST/Stmts.pir:1259)
whiteknight okay, so is the error actually in your code, or in PCT?
benabik whiteknight: Stmts.pir is only 67 lines, BTW. 18:14
whiteknight ...lolfail
benabik whiteknight: I'm currently hacking PAST::Compiler, so it's both in my code and in PCT. :-D
dukeleto Only 41 more functions to test in extend_vtable ... 18:15
whiteknight better yet, 41 VTABLEs for us to deprecate and remove! 18:16
you can't say I'm not an optimist
dukeleto whiteknight: i won't argue. But I prefer to have things tested before we replace/remove them :) 18:18
whiteknight: i have questions for you 18:20
18:20 dmalcolm joined
whiteknight good questions or bad questions? 18:20
dukeleto whiteknight: i am working on a TPF grant now, and part of it is writing tests for src/embed.c
whiteknight: but i would rather write tests for the new embed API
whiteknight okay 18:21
I was just looking at src/embed.c. There are more than a few things in that file which are deprecated and slated for removal
next time I think about it, I need to suggest we make the new API non-experimental, and then proceed with the deprecation on the older stuff 18:22
dukeleto whiteknight: sure, I am on board that train
whiteknight yay! passengers!
dukeleto whiteknight: so I would like your blessing to modify news.perlfoundation.org/2010/08/201...posal.html 18:23
whiteknight: what do you think would be reasonable?
whiteknight what do you mean? You don't need my blessing for that
what are you thinking about changing? 18:24
dukeleto whiteknight: the part about raising test coverage of src/embed.c and src/extend.c
whiteknight: i think we both agree, that it would be better to spend time+energy adding test coverage to the new embed API you wrote 18:25
whiteknight right
dukeleto whiteknight: i don't need your blessing, but I am asking for your opinion on what would be a reasonable change to my grant
whiteknight ah, okay
let me look at it 18:26
the files in src/embed/*.c actually have decent coverage right now, thanks to GCI
Some of the tests are pretty large, so we cover multiple routines in a single test
but we're at 72%, 74%, and 86% for those files 18:27
oh, and 96%
dukeleto whiteknight: should I attempt to to raise src/embed/api.c to 95% instead ? 18:28
whiteknight that would probably be the best use of time, Yes
dukeleto whiteknight: i feel like raising all src/embed/*.c to 95% may be more work than the original grant, since the new embed API is more code than the old
whiteknight yes
dukeleto whiteknight: just to clarify, both src/extend.c and src/embed.c are deprecated and planned to be removed, right? 18:29
whiteknight I don't know about extend.c (did I typo that earlier?) embed.c definitely is
dukeleto whiteknight: ok. I will send an email to parrot-dev letting people know of my proposed change to my grant and wait for some approval 18:30
whiteknight: i just don't want people to perceive that I am changing my grant for my own personal reasons/etc. I think this change benefits everybody. 18:31
whiteknight I strongly agree
dukeleto whiteknight: awesome. I appreciate it.
whiteknight: also, i think I found a double-free in extend_vtable
whiteknight: i haven't had the time to look into it.
whiteknight oh fun
benabik Does .return inside Q:PIR not work?
dukeleto benabik: i think you should assign to %r for that 18:32
whiteknight benabik: probably not
dukeleto whiteknight: github.com/parrot/parrot/commit/da...c0027ee0bd
benabik dukeleto: Right, although it also involve some changes in control flow since .return leaves the sub and assigning to %r doesn't.
dukeleto benabik: yeah, I don't pretend to understand all the implications. But that is the idiom that I often see 18:33
whiteknight: also, what is the deal with Parrot_PMC_destroy not understanding that it shouldn't attempt to destroy NULL PMC's ?
whiteknight: is that considered a feature?
whiteknight: because checking if a pmc is null before destroying just seems dumb to me
benabik .tailcall seems to work. 18:34
whiteknight there is a PObj_something_something_destroy flag on the PMC header
the GC only calls destroy when that flag is set
PerlJam benabik: you can return from NQP and break up the Q:PIR as needed.
dukeleto whiteknight: so why can't I just call Parrot_PMC_destroy(interp, pmc) and not care if pmc == PMCNULL ?
benabik PerlJam: I was hoping for minimal changes to the PIR. Some of it is very complex. I'll figure it out. 18:35
whiteknight I suspect you should be able to. default.destroy() is an empty function
dukeleto, what problem are you having with it?
dukeleto whiteknight: Null PMC access in destroy()
whiteknight: if you comment out the checks for NOT_NULL in extend_vtable.c, you will see tests fail because of that exception 18:36
whiteknight: can we make destroy smarter?
whiteknight: the alternative is every call to _destroy that exists has to check for null-ness, which seems like a big annoying waste
whiteknight Ah, Null.destroy is being automatically generated by Pmc2c 18:37
and that exception is being thrown in the auto-generated function for it
PerlJam benabik: from my copy of rakudo's src/gen/core.pm ... gist.github.com/993743
whiteknight If you don't think that's a good idea, remove that
benabik PerlJam: Oh. Hm. Then it's something else. Drat. 18:38
whiteknight But, I'm not sure that we don't want that check in there. Null is currently a singleton and shouldn't be getting destroyed
dukeleto whiteknight: sure. but the common case of some function returning PMCNULL into a PMC variable, and then destroying the PMC causes this annoyance to pop up 18:39
whiteknight: i understand that we are being very strict and telling the user "hey, you are trying to destroy PMCNULL which maybe you didn't want to"
whiteknight dukeleto: I wouldn't call that a common case. The destroy vtable is only called from GC, and GC contains checks to avoid dealing with null 18:40
plus, Null doesn't have the flag set to cause it to be destroyed
so, I suspect your test is wrong
18:40 ShaneC left
dukeleto whiteknight: interesting. What about Parrot_PMC_destroy ? That should only be called from the GC? 18:40
whiteknight That should never be called, and shouldn't exist
dukeleto whiteknight: because we are exposing end-users to that function, and I am trying to test it, is all
whiteknight: lulz. Well then. 18:41
whiteknight kill it. It's a land-mine
or, add in a check for that PObj flag
dukeleto whiteknight: interesting
whiteknight actually, just kill it 18:42
I can't think of a reason why an extender would need to manually destroy a PMC, unless it can guarantee that no references to it exist in the whole rest of the system
or that doing it out of sequence will not cause problems for an arbitrary, pluggable, hasn't-been-developed-yet GC core
in our current GC core, for instance, calling VTABLE_destroy on the PMC won't add it to the free list, and might cause it to be leaked 18:44
benabik Guh. Found the error. Q:PIR is converting %r and %t inside string literals into new register allocations.
whiteknight benabik: :)
benabik whiteknight: No. sadface. Very sadface.
whiteknight benabik: tell it to cut that the hell out
benabik whiteknight: The funny thing is that it's breaking the function designed to do that replacement. 18:45
whiteknight :)
now that's just funny
benabik Sorry, I meant "funny"
whiteknight I guess that's going to have to be the first function you rewrite into pure NQP
benabik Or at least that part. 18:46
whiteknight once you get started, I'm sure the conversion for the whole thing will go quick
benabik In order to do the %r/%t replacements properly, I think I'll have to teach PIRATE to do them instead of trying to do it in PAST::Compiler. 18:47
whiteknight benabik: that doesn't sound right. Other languages will use PAST::Compiler besides just PIRATe 18:48
and all of them are going to need that functionality
benabik whiteknight: ... I'll have to ponder that eventually. I was going to pass inline nodes off to PIRATE to get parsed so that nothing was using IMCC. OTOH, I don't want to kill PIR generation completely so that replacement will have to be done a little higher I guess. :-/ 18:51
For now: Convert what it's doing and add a comment saying it's not enough.
whiteknight unrelated, but interesting link: article.gmane.org/gmane.comp.lang.l...eral/75426 18:52
pmichaud aloha msg bacek results of gc_tuning branch versus master and 3.4.0: gist.github.com/993771 18:53
aloha pmichaud: OK. I'll deliver the message.
whiteknight pmichaud: those numbers are cautiously good
at least a step in the right direction
benabik: if it's PIRATE, you have PIRATE as the PIR parser. PIRATE can recurse into the inline blocks 18:54
just pass the inline block along, and PIRATE will deal with it
and by "PIRATE will deal with it", I mean you will do the hard work to make PIRATE deal with it
benabik whiteknight: I'll look into the details a bit down the line. I want to use PIRATE to do the heavy lifting for inline PIR, but don't want to break PIR output as is. 18:57
whiteknight hmmm... it looks like src/embed.c didn't make it into api.yaml 19:06
I'll have to add that eventually
dalek website: lucian++ | Starting, sort of 19:13
website: www.parrot.org/content/starting-sort
19:16 ShaneC joined
benabik How do I print out the class of a PMC? `say(pir::class_PP($node));` is what I came up with, but doesn't seem to work. 19:28
whiteknight pir::say(pir::typeof__SP($node)) 19:29
obviously
:)
you need two underscores
benabik That was a typo in IRC, not in code.
whiteknight okay, i figurecf
figured
typeof gets the class of the object. class__pp looks up the class using the value as a key 19:30
benabik The multitude of class opcodes is a little confusing. 19:31
whiteknight needlessly so
and for all that complexity, we still look up classes by string keys
fixing that infelicity would cause massive breakage in HLL compilers, I think, so we aren't rushing to do it 19:32
benabik ... Is there a version of say that outputs to STDERR? 19:33
whiteknight no, I don't think there is a two-argument version of say
say is just a convenience method for stdout
there is a two-argument form of print that takes a filehandle
and there's a method on interp to get stderr handle 19:34
benabik Okay, that's too much work for a simple debug. I'll find the file it's outputting to.
whiteknight I think it's something like $P0 = getinterp \\n $P1 = $P0.stderr_handle() \\n print $P1, "whatever"
19:36 contingencyplan joined 19:43 Kulag left 19:44 Kulag joined 19:49 davidfetter joined
benabik Coke is currently winning at Parrot: github-high-scores.heroku.com/parro...gh_scores/ 19:50
19:52 hercynium left
whiteknight what is that thing? 19:54
benabik High scores for github. I think score = # commits * 100
whiteknight awesome 19:55
atrodo i keep getting a 404 on that
whiteknight I got a 404 the first time 19:56
pmichaud is winning at Rakudo 19:57
Coke_ it's "high_scores/" not "high_scores/15:52", which is what I got when I clicked on it in irssi. 20:01
must only be showing github users. 20:02
(no leo or dan) (makes sense)
20:16 Coke left, Coke joined
Tene I'm wedged between simoncozens and chip 20:16
PerlJam Tene: that's some sandwich! 20:18
benabik Well, my NQP wrapped PAST::Compiler now builds everything in parrot, but I'm getting test failures. Now to see if they're broken in master.
cotto_work benabik: nice
Tene I miss working on parrot. :( 20:20
cotto_work Parrot misses you working on Parrot.
whiteknight it's not like there is any less code to be written 20:25
or, better yet, any less code to ruthlessly delete
benabik cd dev/parrot; rm -rf *; git add -u; git commit -m "Fixed everything!"; git push 20:26
whiteknight that's one way to get rid of all the bugs and cruft 20:27
20:29 whiteknight left 20:32 ShaneC left, mj41 left
cotto_work office move time 20:32
20:32 cotto_work left
benabik Good(?) news! My nqp_pct branch only fails tests that are broken for me in master too. 20:37
tadzik good news 20:39
benabik I added the question mark because I dislike that master is failing tests. :-)
bubaflub benabik: which tests are failing? 20:52
benabik bubaflub: One checkdepend, four extend_vtable.
(IIRC)
dukeleto benabik: crikey 20:53
benabik: master shouldn't ever fail tests, but sometimes it does. Like, when I break it on accident :) 20:54
benabik: can you gist the output of the failing extend_vtable tests?
benabik dukeleto: Will do. Just have to re-run them. 20:55
dukeleto benabik: the checkdepend failure is not mine, but there are some TT's out for checkdepend failing when some libs are not available
benabik: prove -v t/src/extend_vtable.t
benabik: i don't need the whole test output
benabik dukeleto: Well, more like `git stash; git checkout master; make; prove` 20:56
dukeleto benabik: what OS/compiler are you using? 20:57
benabik OS X/gcc 20:58
gist.github.com/9b70421714f540c813c9
dukeleto: ^^ OS X 10.6.7 and gcc
Coke_ benabik: what's the checkdepend failure? 20:59
benabik Coke_: not ok 96 - src/platform.c (no rule found for this file).
21:01 mtk left
benabik Does NQP have a way to iterate over the keys of a hash? 21:10
21:10 mtk joined
benabik Nevermind, my tests were building the hash wrong. 21:12
21:14 bluescreen left 21:15 darbelo joined
dukeleto benabik: gcc version? 21:20
benabik dukeleto: gcc version 4.2.1 (Apple Inc. build 5664)
dukeleto the dreaded Null PMC access in destroy() 21:21
dukeleto shakes his fist
21:22 lucian_ joined 21:23 lucian_ left
dukeleto benabik: can you create a TT for that? 21:23
benabik: i will unbreak master 21:24
21:25 bluescreen joined
benabik dukeleto: TT #2123, all yours. 21:28
21:28 cotto_work joined
dalek rrot: 6f2f834 | dukeleto++ | t/src/extend_vtable.t:
Unbreak master by avoiding the unpleasant Parrot_PMC_destroy function
 21:28
dukeleto benabik: danke! I think?
benabik: please test master again, should be goodly, let me know if it isn't
dalek TT #2123 created by benabik++: t/src/extend_vtable.t: Null PMC access in destroy 21:29
TT #2123: trac.parrot.org/parrot/ticket/2123
21:29 ambs left
cotto_work ohai 21:30
21:30 mj41 joined 21:34 bluescreen left
dukeleto cotto_work: hola 21:34
cotto_work: should PMC_IS_NULL be exported to embed/extend users, or does it only live in parrot-internals land?
benabik dukeleto++ # fixing what he broke
dukeleto cotto_work: i ask because currently the PMC_IS_NULL macro does not work from the extend interface 21:35
benabik dukeleto: Now I just have that checkdepend failure
21:35 gbacon left
dukeleto benabik: make sure you are doing a "make realclean" 21:37
benabik: and configuring again. it might be cruft from switching branches
benabik: make reconfig 21:38
cotto_work dukeleto: there's a function for that iirc
dukeleto cotto_work: it isn't exported
cotto_work: the macro calls the function
cotto_work orly?
benabik dukeleto: Does make reconfig work across make realclean? 21:39
cotto_work what's the use case for exporting it?
dukeleto # t/src/extend_vtable.t:146: error: ‘Parrot_pmc_is_null’ was not declared in this scope
that is what I get when I try to use PMC_IS_NULL macro from the extend interface 21:40
cotto_work: well, for me, I am trying to add test coverage/tests for Parrot_PMC_destroy
cotto_work I mean is it something generally useful to embedders?
dukeleto cotto_work: and if you give that function a NULL or PMCNULL, it throws an exception
cotto_work: perhaps I just need to use an exception handler to catch it 21:41
cotto_work: well, it is function/macro that let's one know if something is either NULL or PMCNULL, which seems useful
cotto_work: i can imagine using it in PL/Parrot
cotto_work: i think PL/Parrot leaks lots of memory now, because I don't destroy anything
cotto_work: whiteknight says Parrot_PMC_destroy is broken by design, and should only be called by the GC 21:42
cotto_work: but PMC_IS_NULL would be a useful macro for extend/embed people to have, in my opinion
cotto_work: do we want to give extenders the false promise that they can destroy stuff? 21:43
cotto_work: because Parrot_PMC_destroy doesn't do anything intuitive
cotto_work: you have to call multiple methods and do other work to make sure to destroy a PMC totally. It seems like an internal implementation detail that leaked out. 21:44
21:45 Psyche^ joined
dukeleto cotto_work: this all suggest that we think hard about what vtable methods should not be made part of the public API and deprecated before our next stable release 21:46
bubaflub dukeleto: that latest commit fixed things for me. now i only have one unrelated failure. 21:47
benabik dukeleto: Indeed, a total cleanup (git clean -xdf) fixed checkdepend.
cotto_work dukeleto: that's worth thinking about. as for pmc null testing, I'm +1 to whatever whiteknight says. 21:50
21:50 Patterner left, Psyche^ is now known as Patterner
dukeleto benabik: yes, git clean -fdx is your friend :) 21:51
bubaflub: what unrelated failure?
pmichaud if PMC_IS_NULL isn't available to others... what should we be using instead?
(I ask because Rakudo uses it *a lot*) 21:52
pmichaud@kiwi:~/rakudo$ ack PMC_IS_NULL src | wc -l
85
dukeleto pmichaud: perhaps I am not including the correct headers to make it defined correctly 21:55
pmichaud: most of those hits from ack are in Parrot internals 21:56
pmichaud false
there are no Parrot internals in rakudo's src/ directory
and I did a "make clean" before the ack
gist.github.com/994179 21:57
dukeleto pmichaud: indeed. My repo is old and I hadn't done a clean
pmichaud: it looks like PMC_IS_NULL is defined when you define a custom PMC 21:58
pmichaud: but I am using the extension interface, which is different
pmichaud we use it in our custom ops, too.
and in our custom binder
bubaflub dukeleto: when i run make test i see t/dynoplibs/debug.t test #5; when i try to run it with prove or perl all the tests fail
dukeleto bubaflub: interesting 21:59
bubaflub dukeleto: (they all fail with "dyld: Library not loaded: /usr/local/lib/libparrot.dylib ... Reason: image not found")
dukeleto: i don't have an installed parrot
pmichaud nqp (the new version) has 182 instances of PMC_IS_NULL
bubaflub dukeleto: and this was from a make realclean
pmichaud oh, some of those are generated 22:00
dukeleto pmichaud: what headers does nqp/rakudo include to get the PMC_IS_NULL definition?
pmichaud dukeleto: I don't know.
I would've expected parrot/parrot.h
dukeleto pmichaud: that is an internal header file
pmichaud it looks like PMC_IS_NULL is defined in interpreter.h 22:01
which is included from embed.h and extend.h
and maybe other places too
tcurtis_ ~~
22:01 dmalcolm left
dukeleto pmichaud: i don't think rakudo should be including parrot/parrot.h 22:02
pmichaud: from the top of the file: Only parrot core files should include this file.
pmichaud dukeleto: if Parrot doesn't expose the interfaces we need, we'll go into the guts. Sorry, that's just the way it is (that's what we're forced to do to make things work).
If Parrot changes the guts... it's on us and we know it.
dukeleto pmichaud: sure, I understand. I am trying to make parrot work correctly so Rakudo is not forced to do that :) 22:03
pmichaud so, remove parrot/parrot.h from rakudo's headers (there aren't many) and see what breaks :)
dukeleto pmichaud: it could be you are including parrot/parrot.h solely for PMC_IS_NULL 22:04
NotFound PMC_IS_NULL is supposed to expand different for internals and for extenders.
dukeleto NotFound: what about HLLs?
NotFound If you use inappropiate headers, too bad for that assumption.
dukeleto NotFound: where are they supposed to get it? Because Rakudo gets it from parrot/parrot.h, which we don't want.
NotFound dukeleto: HLLs aren't internals, AFAIK.
pmichaud dukeleto: I didn't say that's where we definitively got it. 22:05
dukeleto NotFound: yes, I understand. But they are the important part of the question.
pmichaud I just suspected that. If parrot.h is a strictly internal file... I'm not sure where the internal/external distinctions are documented.
NotFound The important part is that our header are a bit convoluted %-)
pmichaud removing parrot/parrot.h from perl6.ops doesn't seem to have broken anything
removing parrot/parrot.h from bind.c breaks a ton of stuff (and not PMC_IS_NULL) 22:06
dukeleto pmichaud: would you be OK if I created a rakudobug about using parrot/parrot.h and that Parrot will work with Rakudo to provide it what it needs without including that header?
pmichaud we get erros from including extend.h if we don't include parrot/parrot.h first 22:07
*errors
dukeleto pmichaud: i understand that was the only way to get at stuff. But we want to fix that.
pmichaud dukeleto: are the "external headers" documented anywhere?
i.e., if I'm a HLL developer, where do I go to see which headers I'm allowed to use and which ones I shouldn't?
More directly... if I'm writing a custom PMC, what parrot header do I include? 22:08
Currently all of Rakudo's PMCs include parrot/parrot.h, which you're claiming is wrong :) 22:09
dukeleto pmichaud: well, if you read the comment at the top of parrot/parrot.h, it describes itself as internals-only
pmichaud: i agree, we need more docs about this
NotFound It should be wrong, but probably is not at this point.
dukeleto pmichaud: i understand Rakudo was forced to include it, to get what it needed 22:10
pmichaud: i ran into similar issues with PL/Parrot, which is what got me into this rabbit hole of fixing our extend/embed interface
pmichaud dukeleto: I understand that you understand. I'm trying to help you identify what Parrot needs to provide.
I'm not complaining.
NotFound extend.h by itself should not give errors. What error do you get? 22:11
dukeleto pmichaud: ok, just wanted to clarify
pmichaud: your help identifying it is greatly appreciated
NotFound BTW the easier way to avoid problems with PMC_IS_NULL is to not use it. 22:12
pmichaud ...and use what instead (which was my original question)?
dukeleto NotFound: yes, what instead? 22:13
NotFound Parrot_pmc_is_null(interp, pmc)
dukeleto NotFound: that is not exported to our extend interface
NotFound dukeleto: hurrah
dukeleto NotFound: but Rakudo currently has access to it, because they include parrot/parrot.h
NotFound: so we need HLL's to be able to get at that function as well 22:14
pmichaud looks like we get it even without including parrot/parrot.h
so something else is giving us access
as I said, both embed.h and extend.h include interpreter.h which defines PMC_IS_NULL
NotFound: gist.github.com/994223 # results of including extend.h without first including parrot.h 22:15
NotFound pmichaud: yes, but the "wrong" definition is inside #ifdef PARROT_IN_CORE 22:16
dukeleto pmichaud: that is interesting, because when I try to use PMC_IS_NULL from the tests in t/src/extend_vtable.t, they say that Parrot_PMC_is_null isn't exported correctly
pmichaud NotFound: fare enough.
*fair
it's possible we define PARROT_IN_CORE somewhere.
no, looks like we don't.
NotFound pmichaud: some other header must define it.
pmichaud (the gist shows only the first couple of screenfuls of errors from extend.h)
dukeleto pmichaud: i am creating a TT for that now 22:17
pmichaud we do define PARROT_IN_EXTENSION in that file, which might be an issue.
gist.github.com/994230 # first lines of bind.c
NotFound I see... the problem is that the tests in extend.t include embed.h, so the errors for using extend.h alone never get diagnosed. 22:18
22:19 fperrad left
dukeleto NotFound: t/src/extend_vtable.t includes all three (extend, embed and extend_vtable) 22:19
NotFound dukeleto: yes, and if we always include embed.h first...
pmichaud afk, fetching dinner 22:20
dukeleto NotFound: I hear ya. We need tests which use all combinations of those headers. Oy.
NotFound Probably some declaration or macro should be moved to core_types.h, I'll look at it.
dukeleto NotFound: do you agree that we don't want Rakudo using parrot/parrot.h ?
NotFound dukeleto: the intention for some time has been that nothing outside core should use that file, but looks like we haven't advanced much in that goal. 22:21
I agree to keep walking on that direction, yes. 22:22
22:22 bubaflub left
NotFound Talking about that things, should we expose Parrot_pmc_destroy? 22:26
dukeleto NotFound: you mean Parrot_PMC_destroy, the extend_vtable function ? 22:28
NotFound: I don't think so
NotFound dukeleto: probably
dukeleto NotFound: it is very misleading, and you have to read the source code of parrot internals to know how to use it correctly 22:29
NotFound Destruction should be a private GC business.
dukeleto NotFound: it isn't documented and it doesn't do what you think it might
NotFound: asking for destruction should be a public thing, but actual destruction should be internal, I agree
NotFound Whatever it do, is probably wrong.
22:30 mj41 left
NotFound Asking for destruction is done in a easy way: nulling any pointer that points to the pmc. 22:30
dalek TT #2124 created by dukeleto++: Including extend.h without first including parrot.h blows up in Rakudo 22:32
TT #2124: trac.parrot.org/parrot/ticket/2124
NotFound Shit, extend.h has an #if defined(PARROT_IN_CORE) 22:35
22:36 Coke left
lucian i think i asked this before. PAST doesn't have a textual representation, does it? 22:37
benabik lucian: It's possible to output PAST, but there's nothing that reads it. 22:38
NotFound lucian: I think that --target PAST gives you one.
lucian NotFound: ah, but my frontend is in python3
NotFound But you can't get back a PAST from it.
lucian benabik: i see
that might be an interesting project, s-expressions for PAST
so i guess i'll be generating PIR
benabik lucian: You could generate PIR that make a PAST tree... But I think that's the best we've got right now. 22:39
S-Expressions aren't quite right. I think it would be more adept to something like YAML
NotFound I have deja-vu feelings with that conversations.
lucian benabik: perhaps, i'm not familiar with PAST
benabik: i was thinking of s-exps for ease of parsing. technically they can express any AST 22:41
but there are enough yaml libs out there, yeah
sorear -1 to any solution which involves parsing yaml
lucian sorear: is that so hard with parrot as it is now? 22:42
benabik lucian: PCT uses trees with nodes that have key->value data. SExps don't quite feel natural for that to me. 22:43
NotFound I'm under the impression that our yaml and json parsers are too slow.
lucian benabik: *shrug* doesn't seem like a big deal
NotFound: which ones?
sorear lucian: you need to parse yaml with the same lib that generated it. Which I guess we can do
NotFound lucian: all
tcurtis_ Do we have a YAML parser? 22:44
lucian NotFound: you sure? and what does slow mean?
NotFound runtime/parrot/library/YAML
lucian sorear: always?
benabik sorear: There is, in theory, a specification for YAML that all parsers should try to follow.
dukeleto benabik: take a look at cdent.org/examples/hello-world/
yes, parrot has a yaml parser
YAML::Tiny it is called
sorear lucian: only if you want it to work in 100% of cases 22:45
lucian sorear: hmm, that might be an issue, i guess
NotFound lucian: slow means causing annoying delays in almost any usage.
sorear YAML is designed to be efficiently human-scannable and human-editable 22:46
lucian NotFound: i've not experienced such annoying delays. and what's faster?
sorear it has a lot of complexities which make it very easy to have a subtly wrong parser or emitter
lucian sorear: you might have a point, writing ASTs by hand shouldn't be optimised for
sorear not helping matters is that the specification does not come with tests 22:47
lucian i mean you definitely do have a point
NotFound lucian: don't know much about yaml, but I probably can write a json faster with both hands down.
lucian NotFound: just make sure it's correct, json is deceptively simple :)
NotFound lucian: yes, and is kept simple with the intention of being parseable very fast. 22:48
So doing it slowly is not good.
lucian NotFound: could you give me an example of a slow parser? i've yet to have an issue with slow parsing
NotFound lucian: just try to load in memory the metadata of all plumage packages, for example. 22:49
sorear it's easy to write a slow JSON parser, if you do it using a sufficient amount of overkill tools
eg. NQP grammars
pmichaud (includes) also, if parrot.h is really intended only for parrot core files, perhaps it should be named something *other* than parrot.h. Either "internals.h" or "private.h" would be much more obvious than a couple of lines at the top of the file (that people aren't likely to see anyway). 22:50
NotFound sorear: even better, don't generate data but code that genrates the data. 22:52
sorear Unable to interpret sentence 22:53
tcurtis_ ls
tcurtis_ mistakenly typed in the wrong window.
NotFound sorear: the json parser generates code, and executing that code you get the data contained in the json.
lucian NotFound: what code?
NotFound: and i don't see the advantage 22:54
sorear NotFound: ...ick.
22:54 bubaflub joined
NotFound lucian: the advantage is... you learn to be patient. 22:54
benabik NotFound: But then you have compile the code... It's useful if you have to read the data far more than you write it.
sorear lucian: probably someone thought "JSON is a language, I'll just use new_language"
lucian: and then they were stuck with a *compiler* 22:55
Tene I expect it was wanting to support something like: eval($data, :lang<json>);
lucian shrugs
i've only had experience with it in js, java and python 22:56
22:56 whiteknight joined
lucian neither of those tried to be anything other than a mapping to data structures 22:56
NotFound benabik: I think we have enough code generation tools to be able to generate such code when we need it, without being forced to doit when we don't.
won't
Anyway, I'm not sure if that has some serious impact on the speed, ot the parsing dominates. 22:57
pmichaud added TT #2125 for parrot.h -> private.h 22:58
NotFound I'll write a simple parser and check its speed.
benabik NotFound: I'd expect that the fact that our code gen requires going to text and back would slow that significantly. 23:00
whiteknight parrot.h has always been required with extend.h. extend.h isn't really intended to be used by itself 23:02
sorear also, our code gen makes massive use of multiple dispatch in the PAST::Compiler and POST::Compiler stages
whiteknight api.h is used stand-alone for embedders
sorear which can't help
NotFound I'll bet that compiling a json as winxed code is faster. 23:03
dalek TT #2125 created by pmichaud++: rename parrot.h to internals.h or private.h or equivalent
TT #2125: trac.parrot.org/parrot/ticket/2125
23:03 lucian left
whiteknight dukeleto: ping 23:08
dukeleto whiteknight: pong 23:09
whiteknight dukeleto: I want to nuke Parrot_PMC_destroy. Is that going to upset your work?
dukeleto whiteknight: nope. Makes less work for me.
whiteknight I'm going to remove it from your .t file. Will that cause you merge difficulties?
t/src/extend_vtable.t
dukeleto whiteknight: one less function to add coverage :)
whiteknight: go ahead and nuke it
whiteknight: i will deal with the merge. there are already going to be conflicts 23:10
whiteknight okay. Testing now. I'll push in a few minutes
dukeleto whiteknight: you are doing this in master? 23:11
whiteknight: or my branch?
whiteknight master
dukeleto whiteknight: cool.
whiteknight unless you want me to fiddle with your branch?
dukeleto whiteknight: nope. i will merge master in again
whiteknight oaky
dukeleto whiteknight: do what ye will
whiteknight this also explains those double-frees you were seeing 23:12
that whole function is basically a weapon. It's like an oddly-named hcf
dukeleto whiteknight: indeed. that TT can be closed if Parrot_PMC_destroy doesn't exist any more
whiteknight: lulz
whiteknight: this will make great material for my next grant update blog post
NotFound About #2125: that file, or its replacement, should have not comments about how to things unrelated, like "Programs embedding parrot should include..." 23:13
dukeleto NotFound: sometimes a SEE ALSO can be helpful
just sayin'
NotFound This only adds one more place of misleading outdated information.
dukeleto: yes, SEE ALSO is good, DO THIS is bad.
But note that we probably also have a lot of wrong SEE ALSO. 23:15
dalek rrot: cbfc76e | Whiteknight++ | / (3 files):
Nuke Parrot_PMC_destroy. It's an extremely dangerous function that should *ABSOLUTELY NEVER BE CALLED BY ANYBODY EVER*. Seriously. Re-read that.
dukeleto laughs a good laugh
tcurtis_ whiteknight: does that not need a deprecation cycle? 23:16
whiteknight tcurtis: no
tcurtis_: ever using that function would cause your program to crash. We don't support crashes
if people want their program to crash, I can suggest ways that do it more quickly 23:17
NotFound We can even resurrect the hcf opcode.
23:18 lucian joined
cotto_work whiteknight++ for bringing me joy with your commit messages 23:19
whiteknight :) 23:20
tcurtis_ whiteknight: In that case, it should probably be noted somewhere other than the commit log for the sake of anyone who might have had code that could call that function but never actually does at runtime?
dalek rrot/leto/embed_grant: c0d0b11 | dukeleto++ | t/src/extend_vtable.t:
Merge branch 'leto/embed_grant'
rrot/leto/embed_grant: 4046b69 | cotto++ | lib/Parrot/Test.pm:
various English fixes in inline POD, patch courtesy of soh_cah_toa++
rrot/leto/embed_grant: 6f2f834 | dukeleto++ | t/src/extend_vtable.t:
Unbreak master by avoiding the unpleasant Parrot_PMC_destroy function
rrot/leto/embed_grant: cbfc76e | Whiteknight++ | / (3 files):
Nuke Parrot_PMC_destroy. It's an extremely dangerous function that should *ABSOLUTELY NEVER BE CALLED BY ANYBODY EVER*. Seriously. Re-read that.
rrot/leto/embed_grant: 67b4080 | dukeleto++ | / (45 files):
Merge remote branch 'origin/master' into leto/embed_grant
dukeleto blarg
i am good at confusing dalek 23:21
tcurtis_ whiteknight: also, I like your commit message. 23:22
dukeleto whiteknight: perhaps we should add something to api.yaml, like "this used to exist and if you ever tried to use it, you probably noticed badness, so we deleted it"
whiteknight: it would be nice for there to be a record of it, but I want it to stay deleted
I checked and Rakudo doesn't use Parrot_PMC_destroy. But perhaps some unlucky HLL is attempting to use it 23:24
lucian dukeleto: i though everything but rakudo, winxed and nqp were rotting
NotFound Lua?
lucian is it working? nice 23:25
NotFound I think pmichaud take care of it.
lucian hmm, i'm trying to decide whether parrot on arm is slow 23:26
whiteknight brb
23:26 whiteknight left
lucian this machine is pretty slow itself (800mhz), so it's hard to judge 23:26
NotFound lucian: In one machine of the gcc farm, building it is sloooooooow.
lucian well, building parrot is slow anywhere. i blame all the bla->c compilers 23:27
NotFound And make test is also slow, so I bet it is.
dukeleto lucian: Lua and Cardinal are both in good health
lucian dukeleto: nice
NotFound: hmm. i should probably profile it on arm and compare with x86 23:28
NotFound lucian: as slow as orders of magnitude worse than in my Asus EEE first generation. 23:29
23:29 whiteknight joined
NotFound But maybe the gcc farm machine had competing processes. 23:30
dalek rrot: 16871ba | dukeleto++ | NEWS:
Add a note to NEWS about Parrot_PMC_destroy

This information should go somewhere, probably in api.yaml as well. If you remove this info from NEWS, please make sure it is recorded somewhere else.
23:30 whiteknight left
23:30 whiteknight joined
dalek TT #2123 closed by whiteknight++: t/src/extend_vtable.t: Null PMC access in destroy 23:34
TT #2123: trac.parrot.org/parrot/ticket/2123
lucian NotFound: boostrapping winxed is very slow here. maybe i'm swapping 23:37
yeah, that's the problem. i have 400mb ram and parrot wants more 23:39
sorear I think it would be more useful to describe memory usages in Mwords 23:41
23:52 lucian left 23:53 lucian joined
whiteknight I would like to start a cull of our array types 23:54
I would like to deprecate and remove all our Fixed*Array types
The Resizable*Array variants all inherit from the fixed-size ones, so there really isn't a complexity or performance savings 23:55
lucian whiteknight: want to only have growables?
whiteknight you can presize the resizable arrays
lucian i'm not arguing against it, just wondering if there's a use-case for fixed ones
whiteknight ResizablePMCArray isa FixedPMCArray. When you grow it, it grows the underlying FixedPMCArray
lucian most likely not
whiteknight the only difference is that Fixed*Array throws an exception if you try to grow it implicitly, but does nothing if you try to grow it explicitly 23:56
lucian btw, bootsrapping winxed on 400mb ram is impossible
sorear 96 mword?
lucian ah. then it makes perfect sense
whiteknight I would like to see the winxed source broken up into a series of smaller files like what Rosella does 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!