Camelia, the Perl 6 bug

IRC log for #parrot, 2011-05-26

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 dmalcolm left #parrot
00:02 gbacon joined #parrot
00:03 dukeleto soh_cah_toa: i see what you've done :)
00:04 dukeleto 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:05 dukeleto 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 dukeleto soh_cah_toa: "git push" will push to your fork, for example
00:05 soh_cah_toa dukeleto: ok, i think you're right
00:07 soh_cah_toa 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
00:07 dukeleto soh_cah_toa: git help branch is your friend :)
00:08 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.
00:08 dukeleto soh_cah_toa: go read the section called "Maintain a Fork" here https://github.com/parrot/parrot/blob​/master/docs/project/git_workflow.pod
00:08 dukeleto cotto: status => acceptable :)
00:08 soh_cah_toa dukeleto: ok
00:09 dukeleto soh_cah_toa: they are extensive. Some are less approachable than others :)
00:16 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:20 cotto soh_cah_toa, did you make the changes to a clone of parrot/parrot.git or your clone?
00:22 soh_cah_toa cotto: i'm not really sure
00:23 dukeleto soh_cah_toa: you ran commit locally, right ?
00:23 dalek parrot: 2b2dc13 | dukeleto++ | / (2 files):
00:23 dalek parrot: [doc] Improve our Git workflow
00:23 dalek parrot: review: https://github.com/parrot/parrot/commit/2b2dc1323a
00:24 dukeleto soh_cah_toa: try doing a "git push"
00:24 dukeleto soh_cah_toa: what happens?
00:24 dukeleto soh_cah_toa: just type: git push<ENTER>
00:25 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:27 soh_cah_toa 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:30 dalek parrot: 14a6c68 | Whiteknight++ | src/dynpmc/os.pmc:
00:30 dalek parrot: Add an .exists() method to OS. Returns 1 if the specified file exists.
00:30 dalek parrot: review: https://github.com/parrot/parrot/commit/14a6c68dae
00:36 dukeleto soh_cah_toa: i see. your branch is tracking the read-only URL still
00:37 dukeleto soh_cah_toa: try "git push origin"
00:38 soh_cah_toa dukeleto: it says everything's up to date
00:42 soh_cah_toa 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:44 kid51 joined #parrot
00:44 soh_cah_toa i must have some magnetic attraction to brick walls because i've been doing nothing but running into them lately :\
00:49 gbacon left #parrot
00:49 dalek Rosella: c8999dc | Whiteknight++ | t/query/ (2 files):
00:49 dalek Rosella: Add tests for sort so we don't regress on it
00:49 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/c8999dc9fb
00:49 dalek Rosella: 872003c | Whiteknight++ | s (2 files):
00:49 dalek Rosella: Fix File so it builds and runs a short example again
00:49 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/872003c4ac
00:49 dalek Rosella: a3c9e13 | Whiteknight++ | s (2 files):
00:49 dalek Rosella: 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
00:50 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/a3c9e13eb5
00:50 dalek Rosella: a1df406 | Whiteknight++ | src/unstable/file/File.winxed:
00:50 dalek Rosella: Add exists method to File, mirroring the new method added to OS. Add a copy method to File
00:50 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/a1df40621c
00:50 dalek Rosella: eff1963 | Whiteknight++ | s (4 files):
00:50 dalek Rosella: Refactor is_file and is_directory logic out into separate functions.  Flesh out details of various Directory methods
00:50 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/eff19638fe
00:50 nopaste "soh_cah_toa" at 192.168.1.3 pasted "More Errors...Yippee" (12 lines) at http://nopaste.snit.ch/47551
00:50 whiteknight soh_cah_toa: that's what happens when you use software that other people aren't using often
00:51 whiteknight delete that main.c folder, or rename it to something
00:52 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.
00:52 whiteknight it may just be a leftover. Rename it to something else, then pull
00:54 soh_cah_toa alright, looks like deleting it was fine
00:56 soh_cah_toa cotto: what subdirectory of t/ do you think my test file should go in?
00:57 cotto soh_cah_toa, are you planning on having only one test file?
00:58 soh_cah_toa cotto: no, i meant tests. typo
00:58 cotto soh_cah_toa, in that case they should go under t/hbdb
00:58 soh_cah_toa cotto: alright
01:04 theory left #parrot
01:11 cotto soh_cah_toa, are you doing ok getting git untangled?
01:13 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
01:14 cotto Tests are great.  Passing tests are even better.
01:15 soh_cah_toa some breakpoints would be even better but i wanna test what i've got so far before moving on
01:16 davidfetter left #parrot
01:17 cotto soh_cah_toa, you can always write tests before you implement the relevant feature.
01:18 soh_cah_toa cotto: i know but i'm still unsure about the stuff from last night
01:19 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 #parrot
01:20 cotto soh_cah_toa, that shouldn't matter for tests.
01:21 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:22 cotto your call
01:24 soh_cah_toa well, once i get these few tests written i wanna brainstorm w/ you about it
01:30 cotto soh_cah_toa, when were you thinking?
01:30 soh_cah_toa cotto: a half hour maybe
01:30 cotto k
01:39 whiteknight where is rand now?
01:39 cotto dynop iirc
01:53 dukeleto soh_cah_toa: does hbdb stand for something?
01:54 soh_cah_toa dukeleto: hbdb = honey bee debugger. it's a nickname i gave to one my cats, sophie
01:54 whiteknight left #parrot
01:59 dukeleto soh_cah_toa: i like it. as long as I can pronounce it "heebee deebee" too ;)
02:00 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
02:01 sorear maybe I should disable my email address on github? *glances at dukeleto*
02:02 gbacon joined #parrot
02:02 dukeleto sorear: go to your notification center, in your github user admin
02:02 dukeleto sorear: turn everything off. that might help :)
02:03 dukeleto sorear: you get an email because you are listed as an admin for the org
02:04 sorear I think 'cappy' is short for 'capture', btw
02:05 dukeleto sorear: ah. that makes more sense. Makes them seem almost jovial
02:06 cotto very small edit distance from another word though
02:09 bubaflub evening dukeleto
02:09 kid51 left #parrot
02:21 arnsholt left #parrot
02:21 arnsholt joined #parrot
02:23 benabik left #parrot
02:24 benabik joined #parrot
02:25 woosley joined #parrot
02:27 bluescreen joined #parrot
02:31 bluescreen left #parrot
02:40 contingencyplan left #parrot
02:42 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:43 contingencyplan joined #parrot
02:47 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)
02:49 atrodo what branch do you have checked out?
02:49 soh_cah_toa soh-cah-toa/hbdb
02:50 atrodo try git push origin soh-cah-toa/hbdb
02:51 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
02:53 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?
02:54 cotto soh_cah_toa, no.  If you want some changes from parrot.git, you'll need to resync
02:54 soh_cah_toa ok
02:56 soh_cah_toa 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
02:57 soh_cah_toa cotto: the other thing is that i can't find the point of failure in test 2
02:58 cotto soh_cah_toa, why are you testing C at all?  Covering normal usage of hbdb should cover all the relevant C code.
03:00 soh_cah_toa cotto: you don't think it's worth testing?
03:01 soh_cah_toa cotto: hmm...i do see you're point
03:01 soh_cah_toa *your
03:02 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:03 cotto dukeleto, does the current debugger have some tests?  istr you doing some work in that area.
03:04 soh_cah_toa cotto: yeah, i suppose once i actually have a working program those tests would be redundant. very redundant
03:04 gbacon left #parrot
03:05 cotto soh_cah_toa, and you'd have to update them if you wanted to mess with hbdb's internal
03:05 cotto *internals
03:05 soh_cah_toa cotto: oh yeah, that makes it even worse
03:05 cotto aloha, coverage?
03:05 aloha cotto: coverage is http://cv.perl6.cz or http://tapir2.ro.vutbr.cz/cover/cover-results/
03:07 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.
03:07 cotto soh_cah_toa, do you remember where they were, i.e. which branch?
03:08 cotto and file
03:08 soh_cah_toa i didn't notice
03:08 cotto I don't see any likely branches in parrot/parrot or any files in master
03:10 soh_cah_toa well, i can take a look at them when i reboot later. what i'm really concerned w/ is breakpoints
03:11 soh_cah_toa 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.
03:11 cotto eventually, yes
03:12 cotto 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 #parrot
03:15 soh_cah_toa i guess what's stumping me is how to alter the runcore's behavior
03:16 cotto the runcore executes one op at a time.  Between ops you can do whatever you feel like.
03:17 soh_cah_toa right, but i mean...what functions do i even look at? how do i execute one op?
03:18 cotto DO_OP(pc, interp);
03:19 theory joined #parrot
03:22 sorear soh_cah_toa: why are you writing a runcore?
03:23 dalek parrot/leto/embed_grant: b16e00d | dukeleto++ | t/src/extend_vtable.t:
03:23 dalek parrot/leto/embed_grant: [t] Remove a suboptimal getprop test and regain Parrot_PMC_destroy coverage
03:23 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/b16e00d64a
03:25 soh_cah_toa sorear: i don't even know, man. i'm so stumped
03:27 cotto sorear, my thinking is that it's simpler to put the debugger behavior in a runloop than to modify ops.
03:30 sorear cotto: what's so hard about modifying ops?
03:31 dalek parrot/leto/embed_grant: da488e4 | dukeleto++ | t/src/extend_vtable.t:
03:31 dalek parrot/leto/embed_grant: [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 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/da488e4057
03:32 cotto sorear, Parrot's ops are messy.  At times they can be variadic.
03:33 cotto a custom runcore means fewer special cases
03:39 dalek parrot/leto/embed_grant: d41d1c9 | dukeleto++ | t/src/extend_vtable.t:
03:39 dalek parrot/leto/embed_grant: [t] Parrot_PMC_get_pointer_keyed
03:39 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/d41d1c9262
03:40 sorear cotto: the length of the op doesn't matter, only the first word needs to be modified
03:40 sorear x86 ops are very messy too
03:40 cotto this is true
03:40 cotto quite a bit more than Parrot's
03:41 dalek parrot/leto/embed_grant: a7ed854 | dukeleto++ | t/src/extend_vtable.t:
03:41 dalek parrot/leto/embed_grant: Destroy our Namespace PMC at the end of testing
03:41 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/a7ed854a82
04:01 JimmyZ left #parrot
04:08 wagle_ joined #parrot
04:09 dalek parrot/leto/embed_grant: 021999b | dukeleto++ | t/src/extend_vtable.t:
04:09 dalek parrot/leto/embed_grant: Add a commented-out test for Parrot_PMC_get_pointer_keyed_int. Need to create an Object PMC
04:09 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/021999be76
04:09 dalek parrot/leto/embed_grant: 74019f3 | dukeleto++ | t/src/extend_vtable.t:
04:09 dalek parrot/leto/embed_grant: [t] Gain some test coverage of Parrot_PMC_newclass
04:09 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/74019f369e
04:09 ingy left #parrot
04:10 allison left #parrot
04:10 wagle left #parrot
04:11 dalek parrot/leto/embed_grant: 56fa3c4 | dukeleto++ | t/src/extend_vtable.t:
04:11 dalek parrot/leto/embed_grant: Destroy our Class and Object PMCs after testing
04:11 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/56fa3c4ebc
04:11 cotto dukeleto, is it safe to assume that you're not going to be touching M0 tonight?
04:12 dalek parrot: b16e00d | dukeleto++ | t/src/extend_vtable.t:
04:12 dalek parrot: [t] Remove a suboptimal getprop test and regain Parrot_PMC_destroy coverage
04:12 dalek parrot: review: https://github.com/parrot/parrot/commit/b16e00d64a
04:12 dalek parrot: da488e4 | dukeleto++ | t/src/extend_vtable.t:
04:12 dalek parrot: [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
04:12 dalek parrot: review: https://github.com/parrot/parrot/commit/da488e4057
04:12 dalek parrot: d41d1c9 | dukeleto++ | t/src/extend_vtable.t:
04:12 dalek parrot: [t] Parrot_PMC_get_pointer_keyed
04:12 dalek parrot: review: https://github.com/parrot/parrot/commit/d41d1c9262
04:12 dalek parrot: a7ed854 | dukeleto++ | t/src/extend_vtable.t:
04:12 dalek parrot: Destroy our Namespace PMC at the end of testing
04:12 dalek parrot: review: https://github.com/parrot/parrot/commit/a7ed854a82
04:12 dalek parrot: 021999b | dukeleto++ | t/src/extend_vtable.t:
04:12 dalek parrot: Add a commented-out test for Parrot_PMC_get_pointer_keyed_int. Need to create an Object PMC
04:12 dalek parrot: review: https://github.com/parrot/parrot/commit/021999be76
04:12 dalek parrot: 74019f3 | dukeleto++ | t/src/extend_vtable.t:
04:12 dalek parrot: [t] Gain some test coverage of Parrot_PMC_newclass
04:12 dalek parrot: review: https://github.com/parrot/parrot/commit/74019f369e
04:12 dalek parrot: 56fa3c4 | dukeleto++ | t/src/extend_vtable.t:
04:12 dalek parrot: Destroy our Class and Object PMCs after testing
04:12 dalek parrot: review: https://github.com/parrot/parrot/commit/56fa3c4ebc
04:12 dalek parrot: c0d0b11 | dukeleto++ | t/src/extend_vtable.t:
04:13 dalek parrot: Merge branch 'leto/embed_grant'
04:13 dalek parrot: review: https://github.com/parrot/parrot/commit/c0d0b11c38
04:14 allison joined #parrot
04:26 ingy joined #parrot
04:32 soh_cah_toa left #parrot
04:46 cotto hello.m0b has the right number of bytes
04:47 cotto violently fails some tests though
04:48 cotto clearly we need fewer tests
04:50 davidfetter joined #parrot
04:52 birdwindupbird joined #parrot
05:12 dalek parrot/m0-prototype: f7fb144 | cotto++ | src/m0/m0_assembler.pl:
05:12 dalek parrot/m0-prototype: fix bytecode segment length calculation
05:12 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/f7fb144b7e
05:12 dalek parrot/m0-prototype: 1d9e2ee | cotto++ | src/m0/m0_assembler.pl:
05:12 dalek parrot/m0-prototype: tighten chunk parsing regex a bit, remove todone todos
05:12 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/1d9e2ee233
05:12 dalek parrot/m0-prototype: b80daa1 | cotto++ | src/m0/m0_ (2 files):
05:12 dalek parrot/m0-prototype: fix bytecode op count calculation
05:12 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/b80daa18e7
05:13 dalek parrot/m0-prototype: 8a03024 | cotto++ | src/m0/m0_interp.pl:
05:13 dalek parrot/m0-prototype: undo accidental commit
05:13 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/8a0302475b
05:17 davidfetter left #parrot
05:26 cotto dukeleto, !!!
05:29 nopaste "cotto" at 192.168.1.3 pasted "M0 lives!!!!" (20 lines) at http://nopaste.snit.ch/47612
05:29 dalek parrot/m0-prototype: 1c1a7e4 | cotto++ | t/m0/hello_canon.m0b:
05:29 dalek parrot/m0-prototype: fix minor goof in hello_canon.m0b
05:29 dalek parrot/m0-prototype:
05:29 dalek parrot/m0-prototype: was using 11 (0x0B) for I0 instead of 12 (0x0C) in the last two ops
05:29 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/1c1a7e468d
05:29 dalek parrot/m0-prototype: 15be142 | cotto++ | src/m0/m0_assembler.pl:
05:29 dalek parrot/m0-prototype: fix thinkos, generate runnable hello.m0b!
05:29 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/15be14284f
05:30 cotto dukeleto, there's some difference between hello.m0b and hello_canon.m0b, but both run
05:32 bubaflub left #parrot
05:35 dukeleto cotto: whoa!
05:35 mtk left #parrot
05:36 dukeleto cotto: nicely done
05:36 fperrad joined #parrot
05:37 cotto dukeleto, I'm excited.
05:39 cotto dukeleto, if you're bored, most of the m0 assembler tests fail
05:39 * cotto sleeps
05:42 mtk joined #parrot
06:08 theory left #parrot
07:38 mj41 joined #parrot
07:57 mj41 left #parrot
08:08 ShaneC joined #parrot
09:10 jsut_ joined #parrot
09:15 jsut left #parrot
09:59 woosley left #parrot
10:01 cosimo_ left #parrot
10:07 cosimo joined #parrot
10:37 lucian joined #parrot
10:43 lucian_ joined #parrot
10:47 lucian left #parrot
11:03 Psyche^ joined #parrot
11:08 Patterner left #parrot
11:08 Psyche^ is now known as Patterner
11:13 birdwindupbird left #parrot
11:16 birdwindupbird joined #parrot
11:21 contingencyplan left #parrot
12:06 whiteknight joined #parrot
12:10 lucian_ left #parrot
12:10 whiteknight http://scifac.ru.ac.za/compilers/conts.htm
12:15 whiteknight good morning, #parrot
12:16 benabik Morning, #parrot!  Morning, whiteknight!
12:16 whiteknight hello benabik
12:16 xenoterracide particle: any chance you're about?
12:17 atrodo =~
12:19 whiteknight particle is on the west coast USA. I'm sure he's still asleep
12:19 whiteknight or, recently just awake
12:20 xenoterracide whiteknight: well I've been trying to ping him for like 2 weeks...
12:21 whiteknight xenoterracide: I do know he's pretty busy lately
12:21 whiteknight I haven't seen him in a few weeks either
12:21 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
12:22 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 whiteknight :)
12:24 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:25 whiteknight xenoterracide: privmsg
12:29 Coke_ particle?
12:29 Coke_ aloha, particle?
12:29 aloha Coke_: particle are any of these students spanish speakers.
12:29 Coke_ no, particle is Jerry Gay
12:29 Coke_ aloha, particle?
12:29 aloha Coke_: particle is Jerry Gay
12:31 bubaflub joined #parrot
12:41 whiteknight seen particle?
12:42 aloha particle was last seen in #parrot 1 days 5 hours ago joining the channel.
12:43 Coke_ Haven't heard from Jerry in ages.
12:43 Coke_ nearly since last yapc.
13:08 jsut joined #parrot
13:13 jsut_ left #parrot
13:13 ambs joined #parrot
13:42 bluescreen joined #parrot
14:32 benabik On a PIR sub, what do the arguments to :multi mean?
14:33 hercynium joined #parrot
14:35 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:36 whiteknight I think it's just arguments, not returns
14:36 whiteknight The dispatcher wouldn't know what the return type is
14:37 whiteknight 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
14:37 whiteknight the first item might be the invocant
14:37 benabik Ah!
14:38 whiteknight I don't use multis often, because winxed doesn't currently support them
14:38 benabik That makes sense.  (And is completely undocumented...)
14:38 whiteknight benabik: feel free to write down some documentation for it, if you want
14:38 whiteknight help save the next coder so much trouble
14:45 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:46 tcurtis benabik: whiteknight is right, iirc.
14:46 tcurtis The first argument is the invocant.
14:47 benabik Hm.  Another vote in that favor.  I guess I'll make the patch after all.
14:47 benabik Although how is the invocant going to have a type other than the class being written?
14:48 benabik IOW, why would a method in PAST::Compiler have an invocant that wasn't a PAST::Compiler object?
14:52 tcurtis benabik: why not? It's perfectly possible to call a PAST::Compiler method on any random object.
14:52 tcurtis Not to say that it's a good idea.
14:52 benabik tcurtis: How?
14:53 benabik And it seems like a very poor idea.
14:53 tcurtis benabik: find_method, then invoke it, I think.
14:54 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 whiteknight it's just another arg on the front of the list
14:55 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:57 theory joined #parrot
15:07 baest_ joined #parrot
15:07 cotto ~~
15:09 baest_ left #parrot
15:13 whiteknight https://gist.github.com/993341
15:13 whiteknight those are the kinds of results I was hoping for
15:14 benabik ~15% improvement for 10000 entries?  Nice.
15:15 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?
15:16 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.
15:16 benabik Ah, yes.  sorry, I was comparing 0.85 to 1.0, not 1.1
15:17 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
15:17 Coke_ Happy to wait until lorito hits, then.
15:17 whiteknight PIR->PIR method calls are pretty quick
15:17 * Coke_ wonders whose idea it was to EVER write pmcs in c.
15:18 benabik Coke_: It seemed like a good idea at the time, I'd guess.
15:18 Coke_ ah well. onward and upward.
15:18 Coke_ benabik: Hai.
15:18 whiteknight yeah, in hindsight writing those types in C has been a big problem
15:19 * Coke_ supposes he should test partcl on the latest release to make sure it still works.
15:22 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 whiteknight so the lions share of the cost is in the comparison routine, and calling the nested runloop specifically
15:23 whiteknight 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?
15:23 whiteknight no, same interpreter
15:23 benabik Then why is it so slow?
15:23 whiteknight but it recurses down into a new runloop function call
15:24 whiteknight 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 nqp: c46d7b0 | pmichaud++ | build/PARROT_REVISION:
15:24 dalek nqp: Bump PARROT_REVISION to 3.4.0.  The old PARROT_REVISION (3.3.0) was
15:24 dalek nqp: defaulting to --gc=ms2, which since February 2011 has been about 60%
15:24 dalek nqp: slower than it was in January 2011.  Moving to Parrot 3.4.0 uses the
15:24 dalek nqp: GMS gc, which gives a huge overall performance speedup and an even
15:24 dalek nqp: bigger speedup for regexes and parsing.
15:24 dalek nqp: review: https://github.com/perl6/nqp/commit/c46d7b096b
15:24 whiteknight or, better yet, from Parrot_ext_call (which Parrot_util_quicksort uses) down to runops_in
15:24 whiteknight runops_int
15:24 dalek TT #2122 created by benabik++: :method and :multi
15:24 dalek TT #2122: http://trac.parrot.org/parrot/ticket/2122
15:34 cotto_work ~~
15:37 theory left #parrot
15:39 dalek Rosella: 4d61ab2 | Whiteknight++ | src/query/Provider.winxed:
15:39 dalek Rosella: Fix selection of pivot so that a sorted array doesn't exhibit pathological performance
15:39 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/4d61ab262e
15:39 dalek Rosella: ac0ff60 | Whiteknight++ | s (2 files):
15:39 dalek Rosella: Inline the swap calls, and use var instead of int for types so we aren't unboxing/reboxing.
15:39 dalek Rosella: This cuts >%10 off runtime for my tests.
15:39 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/ac0ff60a26
15:39 dalek Rosella: 1fc8cc3 | Whiteknight++ | src/query/Provider.winxed:
15:39 dalek Rosella: inline the partition routine into the sort routine. No appreciable speedup in my benchmarks
15:39 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/1fc8cc321b
15:39 xenoterracide left #parrot
15:46 dod left #parrot
16:13 AzureStone left #parrot
16:18 AzureStone joined #parrot
16:22 theory joined #parrot
16:29 cotto_work dukeleto: ping
16:31 dalek left #parrot
16:31 mj41 joined #parrot
16:32 lucian joined #parrot
16:35 TimToady left #parrot
16:35 sorear left #parrot
16:36 p6eval left #parrot
16:37 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 #parrot
16:38 cotto_work $op_count++ for ($bc_seg =~ /^\s*\w+/mg);
16:38 dukeleto cotto_work: only after I have made coffee :)
16:38 cotto_work dukeleto: that's an important dependency
16:39 p6eval joined #parrot
16:39 cotto_work ohai p6eval
16:40 dukeleto cotto_work: so you wanter to keep an op counter. Why not just count lines? Because you added labels?
16:40 TimToady joined #parrot
16:40 dukeleto s/wanter/want/
16:40 dukeleto TimToady: welcome back to the party
16:40 cotto_work dukeleto: I want to count non-empty lines
16:40 sorear joined #parrot
16:41 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 #parrot
16:44 cotto_work dukeleto: my assumption was that any line with
16:44 cotto_work \w would have an op
16:46 NotFound Allowing both kinds of labels can be easier code generators.
16:46 NotFound for
16:47 cotto_work NotFound: ok.  That's an important data point.
16:48 NotFound Not very importante, but convenient.
16:49 mj41 left #parrot
16:50 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
16:50 benabik The INIT block seems to work but is also not really easy to read.
16:51 pmichaud "nqp-rx"
16:51 whiteknight yes, that's for nqp-rx
16:51 benabik Yes.  Sorry, when I speak of NQP I mean parrot-nqp.  :-/
16:52 pmichaud "nqp" has an improved use statement.
16:52 cotto_work delightful
16:53 dukeleto cotto_work: coffee is still percolating to my brain. I will take a look at the m0 tests in a few
16:54 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.
16:56 benabik imcc-- # line numbers shouldn't be hard!
17:00 dukeleto benabik: patches/blowtorches welcome
17:01 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:02 benabik 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:06 whiteknight line number handling is screwed up by heredocs, at least
17:06 whiteknight I don't know what else would do it
17:10 whiteknight 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
17:10 TimToady the wrong(ish) way is to do linenum++
17:10 whiteknight there's a right way, a wrong(ish) way, and the Parrot way
17:11 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
17:11 TimToady s/file/string/
17:13 TimToady 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:14 TimToady and any sublanguage that gets the line count off affects everything after it
17:14 TimToady (and yes, we did it wrong in Perl 5 :)
17:15 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.
17:15 benabik Although that doesn't help IMCC any
17:16 pmichaud PCT already does this.  :)
17:16 pmichaud although you mean "directly into the packfile", without going through PIR, I guess?
17:16 benabik pmichaud: Yes.
17:16 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
17:16 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.
17:16 whiteknight ...I'll bring the shovel
17:17 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.
17:17 whiteknight we're at the point now where the breakage is not absurd
17:17 pmichaud benabik: we definitely use .file/.line annotations in Rakudo.  Parrot tends to ignore them.
17:17 cotto_work pmichaud: mine too, though sometimes it's decreased the drasticness of how broken they are.
17:18 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?
17:18 pmichaud Rakudo?  PCT?  ;-)
17:18 whiteknight benabik: Prior to the current round of fixing, linenumbers were up around INT_MAX
17:19 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"
17:19 cotto_work pmichaud: great.
17:19 whiteknight oh yes, being told that every error is happening on line 1 brings it's own brand of hilarity
17:19 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.
17:20 cotto_work whiteknight: but that means everything is a one line fix
17:20 pmichaud cotto_work: alas, if that were only the case.
17:21 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 whiteknight gooder and more better
17:23 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.
17:24 whiteknight benabik: I'm squarely in your corner. I *really* want this project to succeed
17:25 whiteknight 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?
17:25 whiteknight ah yes, indentations have an effect on line numbering, for some reason
17:25 NotFound ... for some lack of reason.
17:26 cotto_work NotFound++
17:26 benabik NotFound: Uhm, it is intended inside the Q:PIR blocks.  Should I stop that?
17:26 whiteknight I think it needs to be indented
17:26 whiteknight everything needs to be
17:26 * benabik is currently just wrapping existing NQP method definitions around great big Q:PIR blocks.
17:27 whiteknight I don't know how PCT is going to handle that
17:29 benabik Handle what now?
17:29 whiteknight those Q:PIR blocks
17:29 whiteknight I don't know what effect that has
17:29 pmichaud my intent is that Q:PIR should go away
17:29 benabik Q:PIR is really really handy when converting existing PIR.
17:29 pmichaud or be used extremely rarely, if at all.  they got over-used in rakudo.
17:29 benabik But should probably be really really avoided otherwise.  :-D
17:31 benabik 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.
17:31 whiteknight avoid what, Q:PIR?
17:31 cotto_work yes
17:31 whiteknight PIR is something everybody should try to avoid, in the future
17:31 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.
17:32 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.
17:32 NotFound Maybe now you see why I refuse to add too much inlining pir features to winxed ;)
17:32 whiteknight winxed doesn't even offer block PIR literals, and I very rarely miss it
17:32 benabik cotto_work: It really does.  I'd like something other than pir::defined to handle optional parameters, for example.
17:33 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
17:33 whiteknight +1
17:33 pmichaud just never got around to it
17:33 NotFound I added it to winxed for that same reason.
17:34 pmichaud afk, walk for real this time
17:34 NotFound And exists
17:38 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:39 benabik Although I'd probably not care if I wasn't converting straight from PIR.
17:40 mj41 joined #parrot
17:44 NotFound Pir optionals aren't undefined when not provided, they are null
17:45 benabik NotFound: NQP replaces it with an Undef.
17:46 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 whiteknight 4-argument getattr and setattr are indispensible for now
17:46 whiteknight can and isa are important
17:47 dalek parrot: 4046b69 | cotto++ | lib/Parrot/Test.pm:
17:47 dalek parrot: various English fixes in inline POD, patch courtesy of soh_cah_toa++
17:47 dalek parrot: review: https://github.com/parrot/parrot/commit/4046b69b3f
17:47 NotFound whiteknight: You have instanceof
17:47 whiteknight oh right, that's isa
17:48 whiteknight 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.
17:49 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?
17:50 whiteknight winxed has defined()?
17:50 whiteknight I must have missed that
17:50 dukeleto benabik: use bisection
17:50 dalek TT #2121 closed by cotto++: Mistakes in lib/Parrot/Test.pm Perldoc
17:50 dalek TT #2121: http://trac.parrot.org/parrot/ticket/2121
17:50 dukeleto benabik: with a die or something like that. Not pretty, but it works.
17:51 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
17:51 benabik woo
17:52 NotFound Oh, wait, I fooled myself, it has only exists.
17:52 whiteknight okay, that's what I thought
17:53 whiteknight Okay, the list of PIR ops I need in Winxed is actually pretty large
17:55 benabik Ah!  using .param inside Q:PIR isn't a good idea.
17:56 tcurtis_ joined #parrot
17:56 tcurtis left #parrot
17:56 whiteknight that's...weird
17:56 whiteknight and that causes the linenumber failures?
17:56 KaeseEs left #parrot
17:56 KaeseEs joined #parrot
17:56 benabik whiteknight: No, but it causes the failure I couldn't find due to the linenumber issues.
17:57 whiteknight ah, okay
17:57 whiteknight yes, the parsing of .param is extremely inflexible
17:57 whiteknight no small part of the reason why I want to redo parameter parsing entirely
17:58 benabik whiteknight: It was dying at runtime saying something like "vtable 'get_integer' not found on type Capture"
17:58 whiteknight oh, fun
17:58 whiteknight those are the great kinds of errors
18:00 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 dukeleto cotto_work: s/before m0-spec branched/after m0-spec branched/
18:00 cotto_work dukeleto: go for it
18:01 dukeleto cotto_work: actually, it is m0-prototype
18:01 dukeleto cotto_work: but it shouldn't matter much to us
18:01 cotto_work dukeleto: nope
18:02 cotto_work should be a really easy merge too
18:02 dalek parrot/m0-prototype: 4046b69 | cotto++ | lib/Parrot/Test.pm:
18:02 dalek parrot/m0-prototype: various English fixes in inline POD, patch courtesy of soh_cah_toa++
18:02 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/4046b69b3f
18:02 dalek parrot/m0-prototype: 63d93f0 | dukeleto++ | / (252 files):
18:02 dalek parrot/m0-prototype: Merge branch 'master' into m0-prototype
18:02 dalek parrot/m0-prototype:
18:02 dalek parrot/m0-prototype: Conflicts:
18:02 dalek parrot/m0-prototype: .gitignore
18:02 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/63d93f04cb
18:07 dukeleto almost at 80% test coverage for http://tapir2.ro.vutbr.cz/cover/late​st-c_cover/src-extend_vtable-c.html ...
18:08 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.
18:08 dukeleto benabik: special surprise! IMCC must like you.
18:08 benabik dukeleto: Feeling not mutual.
18:08 gbacon joined #parrot
18:13 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)
18:13 whiteknight okay, so is the error actually in your code, or in PCT?
18:14 benabik whiteknight: Stmts.pir is only 67 lines, BTW.
18:14 whiteknight ...lolfail
18:14 benabik whiteknight: I'm currently hacking PAST::Compiler, so it's both in my code and in PCT.  :-D
18:15 dukeleto Only 41 more functions to test in extend_vtable ...
18:16 whiteknight better yet, 41 VTABLEs for us to deprecate and remove!
18:16 whiteknight you can't say I'm not an optimist
18:18 dukeleto whiteknight: i won't argue. But I prefer to have things tested before we replace/remove them :)
18:20 dukeleto whiteknight: i have questions for you
18:20 dmalcolm joined #parrot
18:20 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
18:20 dukeleto whiteknight: but i would rather write tests for the new embed API
18:21 whiteknight okay
18:21 whiteknight 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
18:22 whiteknight 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
18:22 whiteknight yay! passengers!
18:23 dukeleto whiteknight: so I would like your blessing to modify http://news.perlfoundation.org/20​10/08/2010q3-grant-proposal.html
18:23 dukeleto whiteknight: what do you think would be reasonable?
18:23 whiteknight what do you mean? You don't need my blessing for that
18:24 whiteknight what are you thinking about changing?
18:24 dukeleto whiteknight: the part about raising test coverage of src/embed.c and src/extend.c
18:25 dukeleto 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
18:25 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
18:25 whiteknight ah, okay
18:26 whiteknight let me look at it
18:26 whiteknight the files in src/embed/*.c actually have decent coverage right now, thanks to GCI
18:26 whiteknight Some of the tests are pretty large, so we cover multiple routines in a single test
18:27 whiteknight but we're at 72%, 74%, and 86% for those files
18:27 whiteknight oh, and 96%
18:28 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
18:28 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
18:28 whiteknight yes
18:29 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
18:30 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:31 dukeleto 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
18:31 dukeleto whiteknight: awesome. I appreciate it.
18:31 dukeleto whiteknight: also, i think I found a double-free in extend_vtable
18:31 dukeleto whiteknight: i haven't had the time to look into it.
18:31 whiteknight oh fun
18:31 benabik Does .return inside Q:PIR not work?
18:32 dukeleto benabik: i think you should assign to %r for that
18:32 whiteknight benabik: probably not
18:32 dukeleto whiteknight: https://github.com/parrot/parrot/commit/​da488e40574e3bbcc2bb4639366247c0027ee0bd
18:32 benabik dukeleto: Right, although it also involve some changes in control flow since .return leaves the sub and assigning to %r doesn't.
18:33 dukeleto benabik: yeah, I don't pretend to understand all the implications. But that is the idiom that I often see
18:33 dukeleto whiteknight: also, what is the deal with Parrot_PMC_destroy not understanding that it shouldn't attempt to destroy NULL PMC's ?
18:33 dukeleto whiteknight: is that considered a feature?
18:33 dukeleto whiteknight: because checking if a pmc is null before destroying just seems dumb to me
18:34 benabik .tailcall seems to work.
18:34 whiteknight there is a PObj_something_something_destroy flag on the PMC header
18:34 whiteknight the GC only calls destroy when that flag is set
18:34 PerlJam benabik: you can return from NQP and break up the Q:PIR as needed.
18:34 dukeleto whiteknight: so why can't I just call Parrot_PMC_destroy(interp, pmc) and not care if pmc == PMCNULL ?
18:35 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
18:35 whiteknight dukeleto, what problem are you having with it?
18:35 dukeleto whiteknight: Null PMC access in destroy()
18:36 dukeleto 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 dukeleto whiteknight: can we make destroy smarter?
18:36 dukeleto whiteknight: the alternative is every call to _destroy that exists has to check for null-ness, which seems like a big annoying waste
18:37 whiteknight Ah, Null.destroy is being automatically generated by Pmc2c
18:37 whiteknight and that exception is being thrown in the auto-generated function for it
18:37 PerlJam benabik: from my copy of rakudo's  src/gen/core.pm ... https://gist.github.com/993743
18:37 whiteknight If you don't think that's a good idea, remove that
18:38 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
18:39 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 dukeleto 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"
18:40 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 whiteknight plus, Null doesn't have the flag set to cause it to be destroyed
18:40 whiteknight so, I suspect your test is wrong
18:40 ShaneC left #parrot
18:40 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
18:40 dukeleto whiteknight: because we are exposing end-users to that function, and I am trying to test it, is all
18:41 dukeleto whiteknight: lulz. Well then.
18:41 whiteknight kill it. It's a land-mine
18:41 whiteknight or, add in a check for that PObj flag
18:41 dukeleto whiteknight: interesting
18:42 whiteknight actually, just kill it
18:42 whiteknight 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
18:42 whiteknight or that doing it out of sequence will not cause problems for an arbitrary, pluggable, hasn't-been-developed-yet GC core
18:44 whiteknight 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.
18:44 whiteknight benabik: :)
18:44 benabik whiteknight: No.  sadface.  Very sadface.
18:44 whiteknight benabik: tell it to cut that the hell out
18:45 benabik whiteknight: The funny thing is that it's breaking the function designed to do that replacement.
18:45 whiteknight :)
18:45 whiteknight now that's just funny
18:45 benabik Sorry, I meant "funny"
18:45 whiteknight I guess that's going to have to be the first function you rewrite into pure NQP
18:46 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
18:47 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:48 whiteknight benabik: that doesn't sound right. Other languages will use PAST::Compiler besides just PIRATe
18:48 whiteknight and all of them are going to need that functionality
18:51 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 benabik For now:  Convert what it's doing and add a comment saying it's not enough.
18:52 whiteknight unrelated, but interesting link: http://article.gmane.org/gman​e.comp.lang.lua.general/75426
18:53 pmichaud aloha msg bacek  results of gc_tuning branch versus master and 3.4.0:  http://gist.github.com/993771
18:53 aloha pmichaud: OK. I'll deliver the message.
18:53 whiteknight pmichaud: those numbers are cautiously good
18:53 whiteknight at least a step in the right direction
18:54 whiteknight benabik: if it's PIRATE, you have PIRATE as the PIR parser. PIRATE can recurse into the inline blocks
18:54 whiteknight just pass the inline block along, and PIRATE will deal with it
18:54 whiteknight and by "PIRATE will deal with it", I mean you will do the hard work to make PIRATE deal with it
18:57 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.
19:06 whiteknight hmmm... it looks like src/embed.c didn't make it into api.yaml
19:06 whiteknight I'll have to add that eventually
19:13 dalek website: lucian++ | Starting, sort of
19:13 dalek website: http://www.parrot.org/content/starting-sort
19:16 ShaneC joined #parrot
19:28 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:29 whiteknight pir::say(pir::typeof__SP($node))
19:29 whiteknight obviously
19:29 whiteknight :)
19:29 whiteknight you need two underscores
19:29 benabik That was a typo in IRC, not in code.
19:29 whiteknight okay, i figurecf
19:29 whiteknight figured
19:30 whiteknight typeof gets the class of the object. class__pp looks up the class using the value as a key
19:31 benabik The multitude of class opcodes is a little confusing.
19:31 whiteknight needlessly so
19:31 whiteknight and for all that complexity, we still look up classes by string keys
19:32 whiteknight fixing that infelicity would cause massive breakage in HLL compilers, I think, so we aren't rushing to do it
19:33 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
19:33 whiteknight say is just a convenience method for stdout
19:33 whiteknight there is a two-argument form of print that takes a filehandle
19:34 whiteknight 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.
19:34 whiteknight I think it's something like $P0 = getinterp \n $P1 = $P0.stderr_handle() \n print $P1, "whatever"
19:36 contingencyplan joined #parrot
19:43 Kulag left #parrot
19:44 Kulag joined #parrot
19:49 davidfetter joined #parrot
19:50 benabik Coke is currently winning at Parrot: http://github-high-scores.heroku​.com/parrot/parrot/high_scores/
19:52 hercynium left #parrot
19:54 whiteknight what is that thing?
19:54 benabik High scores for github.  I think score = # commits * 100
19:55 whiteknight awesome
19:55 atrodo i keep getting a 404 on that
19:56 whiteknight I got a 404 the first time
19:57 whiteknight pmichaud is winning at Rakudo
20:01 Coke_ it's "high_scores/" not "high_scores/15:52", which is what I got when I clicked on it in irssi.
20:02 Coke_ must only be showing github users.
20:02 Coke_ (no leo or dan) (makes sense)
20:16 Coke left #parrot
20:16 Coke joined #parrot
20:16 Tene I'm wedged between simoncozens and chip
20:18 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.
20:18 cotto_work benabik: nice
20:20 Tene I miss working on parrot. :(
20:20 cotto_work Parrot misses you working on Parrot.
20:25 whiteknight it's not like there is any less code to be written
20:25 whiteknight or, better yet, any less code to ruthlessly delete
20:26 benabik cd dev/parrot; rm -rf *; git add -u; git commit -m "Fixed everything!"; git push
20:27 whiteknight that's one way to get rid of all the bugs and cruft
20:29 whiteknight left #parrot
20:32 ShaneC left #parrot
20:32 mj41 left #parrot
20:32 cotto_work office move time
20:32 cotto_work left #parrot
20:37 benabik Good(?) news!  My nqp_pct branch only fails tests that are broken for me in master too.
20:39 tadzik good news
20:39 benabik I added the question mark because I dislike that master is failing tests.  :-)
20:52 bubaflub benabik: which tests are failing?
20:52 benabik bubaflub: One checkdepend, four extend_vtable.
20:52 benabik (IIRC)
20:53 dukeleto benabik: crikey
20:54 dukeleto benabik: master shouldn't ever fail tests, but sometimes it does. Like, when I break it on accident :)
20:54 dukeleto benabik: can you gist the output of the failing extend_vtable tests?
20:55 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
20:55 dukeleto benabik: prove -v t/src/extend_vtable.t
20:55 dukeleto benabik: i don't need the whole test output
20:56 benabik dukeleto: Well, more like `git stash; git checkout master; make; prove`
20:57 dukeleto benabik: what OS/compiler are you using?
20:58 benabik OS X/gcc
20:58 benabik https://gist.github.com/9b70421714f540c813c9
20:58 benabik dukeleto: ^^  OS X 10.6.7 and gcc
20:59 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 #parrot
21:10 benabik Does NQP have a way to iterate over the keys of a hash?
21:10 mtk joined #parrot
21:12 benabik Nevermind, my tests were building the hash wrong.
21:14 bluescreen left #parrot
21:15 darbelo joined #parrot
21:20 dukeleto benabik: gcc version?
21:20 benabik dukeleto: gcc version 4.2.1 (Apple Inc. build 5664)
21:21 dukeleto the dreaded Null PMC access in destroy()
21:21 * dukeleto shakes his fist
21:22 lucian_ joined #parrot
21:23 lucian_ left #parrot
21:23 dukeleto benabik: can you create a TT for that?
21:24 dukeleto benabik: i will unbreak master
21:25 bluescreen joined #parrot
21:28 benabik dukeleto: TT #2123, all yours.
21:28 cotto_work joined #parrot
21:28 dalek parrot: 6f2f834 | dukeleto++ | t/src/extend_vtable.t:
21:28 dalek parrot: Unbreak master by avoiding the unpleasant Parrot_PMC_destroy function
21:28 dalek parrot: review: https://github.com/parrot/parrot/commit/6f2f834664
21:28 dukeleto benabik: danke! I think?
21:28 dukeleto benabik: please test master again, should be goodly, let me know if it isn't
21:29 dalek TT #2123 created by benabik++: t/src/extend_vtable.t: Null PMC access in destroy
21:29 dalek TT #2123: http://trac.parrot.org/parrot/ticket/2123
21:29 ambs left #parrot
21:30 cotto_work ohai
21:30 mj41 joined #parrot
21:34 bluescreen left #parrot
21:34 dukeleto cotto_work: hola
21:34 dukeleto cotto_work: should PMC_IS_NULL be exported to embed/extend users, or does it only live in parrot-internals land?
21:34 benabik dukeleto++ # fixing what he broke
21:35 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 #parrot
21:37 dukeleto benabik: make sure you are doing a "make realclean"
21:37 dukeleto benabik: and configuring again. it might be cruft from switching branches
21:38 dukeleto benabik: make reconfig
21:38 cotto_work dukeleto: there's a function for that iirc
21:38 dukeleto cotto_work: it isn't exported
21:38 dukeleto cotto_work: the macro calls the function
21:38 cotto_work orly?
21:39 benabik dukeleto: Does make reconfig work across make realclean?
21:39 cotto_work what's the use case for exporting it?
21:39 dukeleto # t/src/extend_vtable.t:146: error: ‘Parrot_pmc_is_null’ was not declared in this scope
21:40 dukeleto that is what I get when I try to use PMC_IS_NULL macro from the extend interface
21:40 dukeleto cotto_work: well, for me, I am trying to add test coverage/tests for Parrot_PMC_destroy
21:40 cotto_work I mean is it something generally useful to embedders?
21:40 dukeleto cotto_work: and if you give that function a NULL or PMCNULL, it throws an exception
21:41 dukeleto cotto_work: perhaps I just need to use an exception handler to catch it
21:41 dukeleto cotto_work: well, it is function/macro that let's one know if something is either NULL or PMCNULL, which seems useful
21:41 dukeleto cotto_work: i can imagine using it in PL/Parrot
21:41 dukeleto cotto_work: i think PL/Parrot leaks lots of memory now, because I don't destroy anything
21:42 dukeleto cotto_work: whiteknight says Parrot_PMC_destroy is broken by design, and should only be called by the GC
21:42 dukeleto cotto_work: but PMC_IS_NULL would be a useful macro for extend/embed people to have, in my opinion
21:43 dukeleto cotto_work: do we want to give extenders the false promise that they can destroy stuff?
21:43 dukeleto cotto_work: because Parrot_PMC_destroy doesn't do anything intuitive
21:44 dukeleto 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:45 Psyche^ joined #parrot
21:46 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:47 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.
21:50 cotto_work dukeleto: that's worth thinking about.  as for pmc null testing, I'm +1 to whatever whiteknight says.
21:50 Patterner left #parrot
21:50 Psyche^ is now known as Patterner
21:51 dukeleto benabik: yes, git clean -fdx is your friend :)
21:51 dukeleto bubaflub: what unrelated failure?
21:51 pmichaud if PMC_IS_NULL isn't available to others... what should we be using instead?
21:52 pmichaud (I ask because Rakudo uses it *a lot*)
21:52 pmichaud pmichaud@kiwi:~/rakudo$ ack PMC_IS_NULL src | wc -l
21:52 pmichaud 85
21:55 dukeleto pmichaud: perhaps I am not including the correct headers to make it defined correctly
21:56 dukeleto pmichaud: most of those hits from ack are in Parrot internals
21:56 pmichaud false
21:56 pmichaud there are no Parrot internals in rakudo's src/ directory
21:56 pmichaud and I did a "make clean" before the ack
21:57 pmichaud http://gist.github.com/994179
21:57 dukeleto pmichaud: indeed. My repo is old and I hadn't done a clean
21:58 dukeleto pmichaud: it looks like PMC_IS_NULL is defined when you define a custom PMC
21:58 dukeleto pmichaud: but I am using the extension interface, which is different
21:58 pmichaud we use it in our custom ops, too.
21:58 pmichaud and in our custom binder
21:58 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
21:59 dukeleto bubaflub: interesting
21:59 bubaflub dukeleto: (they all fail with "dyld: Library not loaded: /usr/local/lib/libparrot.dylib ... Reason: image not found")
21:59 bubaflub dukeleto: i don't have an installed parrot
21:59 pmichaud nqp (the new version) has 182 instances of PMC_IS_NULL
21:59 bubaflub dukeleto: and this was from a make realclean
22:00 pmichaud oh, some of those are generated
22:00 dukeleto pmichaud: what headers does nqp/rakudo include to get the PMC_IS_NULL definition?
22:00 pmichaud dukeleto: I don't know.
22:00 pmichaud I would've expected parrot/parrot.h
22:00 dukeleto pmichaud: that is an internal header file
22:01 pmichaud it looks like PMC_IS_NULL is defined in interpreter.h
22:01 pmichaud which is included from embed.h and extend.h
22:01 pmichaud and maybe other places too
22:01 tcurtis_ ~~
22:01 dmalcolm left #parrot
22:02 dukeleto pmichaud: i don't think rakudo should be including parrot/parrot.h
22:02 dukeleto pmichaud: from the top of the file: Only parrot core files should include this file.
22:02 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).
22:02 pmichaud If Parrot changes the guts... it's on us and we know it.
22:03 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 :)
22:04 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.
22:04 dukeleto NotFound: what about HLLs?
22:04 NotFound If you use inappropiate headers, too bad for that assumption.
22:04 dukeleto NotFound: where are they supposed to get it? Because Rakudo gets it from parrot/parrot.h, which we don't want.
22:04 NotFound dukeleto: HLLs aren't internals, AFAIK.
22:05 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.
22:05 pmichaud I just suspected that.  If parrot.h is a strictly internal file... I'm not sure where the internal/external distinctions are documented.
22:05 NotFound The important part is that our header are a bit convoluted %-)
22:05 pmichaud removing parrot/parrot.h from perl6.ops doesn't seem to have broken anything
22:06 pmichaud 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?
22:07 pmichaud we get erros from including extend.h if we don't include parrot/parrot.h first
22:07 pmichaud *errors
22:07 dukeleto pmichaud: i understand that was the only way to get at stuff. But we want to fix that.
22:07 pmichaud dukeleto: are the "external headers" documented anywhere?
22:07 pmichaud 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?
22:08 pmichaud More directly... if I'm writing a custom PMC, what parrot header do I include?
22:09 pmichaud 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
22:09 dukeleto pmichaud: i agree, we need more docs about this
22:09 NotFound It should be wrong, but probably is not at this point.
22:10 dukeleto pmichaud: i understand Rakudo was forced to include it, to get what it needed
22:10 dukeleto pmichaud: i ran into similar issues with PL/Parrot, which is what got me into this rabbit hole of fixing our extend/embed interface
22:10 pmichaud dukeleto: I understand that you understand.  I'm trying to help you identify what Parrot needs to provide.
22:10 pmichaud I'm not complaining.
22:11 NotFound extend.h by itself should not give errors. What error do you get?
22:11 dukeleto pmichaud: ok, just wanted to clarify
22:11 dukeleto pmichaud: your help identifying it is greatly appreciated
22:12 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)?
22:13 dukeleto NotFound: yes, what instead?
22:13 NotFound Parrot_pmc_is_null(interp, pmc)
22:13 dukeleto NotFound: that is not exported to our extend interface
22:13 NotFound dukeleto: hurrah
22:13 dukeleto NotFound: but Rakudo currently has access to it, because they include parrot/parrot.h
22:14 dukeleto 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
22:14 pmichaud so something else is giving us access
22:14 pmichaud as I said, both embed.h and extend.h include interpreter.h which defines PMC_IS_NULL
22:15 pmichaud NotFound: http://gist.github.com/994223   # results of including extend.h without first including parrot.h
22:16 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
22:16 pmichaud NotFound: fare enough.
22:16 pmichaud *fair
22:16 pmichaud it's possible we define PARROT_IN_CORE somewhere.
22:16 pmichaud no, looks like we don't.
22:16 NotFound pmichaud: some other header must define it.
22:16 pmichaud (the gist shows only the first couple of screenfuls of errors from extend.h)
22:17 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.
22:17 pmichaud http://gist.github.com/994230  # first lines of bind.c
22:18 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:19 fperrad left #parrot
22:19 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...
22:20 pmichaud afk, fetching dinner
22:20 dukeleto NotFound: I hear ya. We need tests which use all combinations of those headers. Oy.
22:20 NotFound Probably some declaration or macro should be moved to core_types.h, I'll look at it.
22:20 dukeleto NotFound: do you agree that we don't want Rakudo using parrot/parrot.h ?
22:21 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:22 NotFound I agree to keep walking on that direction, yes.
22:22 bubaflub left #parrot
22:26 NotFound Talking about that things, should we expose Parrot_pmc_destroy?
22:28 dukeleto NotFound: you mean Parrot_PMC_destroy, the extend_vtable function ?
22:28 dukeleto NotFound: I don't think so
22:28 NotFound dukeleto: probably
22:29 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.
22:29 dukeleto NotFound: it isn't documented and it doesn't do what you think it might
22:29 dukeleto NotFound: asking for destruction should be a public thing, but actual destruction should be internal, I agree
22:29 NotFound Whatever it do, is probably wrong.
22:30 mj41 left #parrot
22:30 NotFound Asking for destruction is done in a easy way: nulling any pointer that points to the pmc.
22:32 dalek TT #2124 created by dukeleto++: Including extend.h without first including parrot.h blows up in Rakudo
22:32 dalek TT #2124: http://trac.parrot.org/parrot/ticket/2124
22:35 NotFound Shit, extend.h has an #if defined(PARROT_IN_CORE)
22:36 Coke left #parrot
22:37 lucian i think i asked this before. PAST doesn't have a textual representation, does it?
22:38 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.
22:38 lucian NotFound: ah, but my frontend is in python3
22:38 NotFound But you can't get back a PAST from it.
22:38 lucian benabik: i see
22:38 lucian that might be an interesting project, s-expressions for PAST
22:38 lucian so i guess i'll be generating PIR
22:39 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 benabik S-Expressions aren't quite right.  I think it would be more adept to something like YAML
22:39 NotFound I have deja-vu feelings with that conversations.
22:39 lucian benabik: perhaps, i'm not familiar with PAST
22:41 lucian benabik: i was thinking of s-exps for ease of parsing. technically they can express any AST
22:41 lucian but there are enough yaml libs out there, yeah
22:41 sorear -1 to any solution which involves parsing yaml
22:42 lucian sorear: is that so hard with parrot as it is now?
22:43 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.
22:43 lucian benabik: *shrug* doesn't seem like a big deal
22:43 lucian NotFound: which ones?
22:43 sorear lucian: you need to parse yaml with the same lib that generated it.  Which I guess we can do
22:43 NotFound lucian: all
22:44 tcurtis_ Do we have a YAML parser?
22:44 lucian NotFound: you sure? and what does slow mean?
22:44 NotFound runtime/parrot/library/YAML
22:44 lucian sorear: always?
22:44 benabik sorear: There is, in theory, a specification for YAML that all parsers should try to follow.
22:44 dukeleto benabik: take a look at http://cdent.org/examples/hello-world/
22:44 dukeleto yes, parrot has a yaml parser
22:44 dukeleto YAML::Tiny it is called
22:45 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
22:45 NotFound lucian: slow means causing annoying delays in almost any usage.
22:46 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?
22:46 sorear it has a lot of complexities which make it very easy to have a subtly wrong parser or emitter
22:46 lucian sorear: you might have a point, writing ASTs by hand shouldn't be optimised for
22:47 sorear not helping matters is that the specification does not come with tests
22:47 lucian i mean you definitely do have a point
22:47 NotFound lucian: don't know much about yaml, but I probably can write a json faster with both hands down.
22:47 lucian NotFound: just make sure it's correct, json is deceptively simple :)
22:48 NotFound lucian: yes, and is kept simple with the intention of being parseable very fast.
22:48 NotFound So doing it slowly is not good.
22:48 lucian NotFound: could you give me an example of a slow parser? i've yet to have an issue with slow parsing
22:49 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
22:49 sorear eg. NQP grammars
22:50 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:52 NotFound sorear: even better, don't generate data but code that genrates the data.
22:53 sorear Unable to interpret sentence
22:53 tcurtis_ ls
22:53 * tcurtis_ mistakenly typed in the wrong window.
22:53 NotFound sorear: the json parser generates code, and executing that code you get the data contained in the json.
22:53 lucian NotFound: what code?
22:54 lucian NotFound: and i don't see the advantage
22:54 sorear NotFound: ...ick.
22:54 bubaflub joined #parrot
22:54 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.
22:54 sorear lucian: probably someone thought "JSON is a language, I'll just use new_language"
22:55 sorear 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>);
22:55 * lucian shrugs
22:56 lucian i've only had experience with it in js, java and python
22:56 whiteknight joined #parrot
22:56 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.
22:56 NotFound won't
22:57 NotFound Anyway, I'm not sure if that has some serious impact on the speed, ot the parsing dominates.
22:58 pmichaud added TT #2125  for parrot.h -> private.h
22:58 NotFound I'll write a simple parser and check its speed.
23:00 benabik NotFound: I'd expect that the fact that our code gen requires going to text and back would slow that significantly.
23:02 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
23:02 whiteknight api.h is used stand-alone for embedders
23:02 sorear which can't help
23:03 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
23:03 dalek TT #2125: http://trac.parrot.org/parrot/ticket/2125
23:03 lucian left #parrot
23:08 whiteknight dukeleto: ping
23:09 dukeleto whiteknight: pong
23:09 whiteknight dukeleto: I want to nuke Parrot_PMC_destroy. Is that going to upset your work?
23:09 dukeleto whiteknight: nope. Makes less work for me.
23:09 whiteknight I'm going to remove it from your .t file. Will that cause you merge difficulties?
23:09 whiteknight t/src/extend_vtable.t
23:09 dukeleto whiteknight: one less function to add coverage :)
23:09 dukeleto whiteknight: go ahead and nuke it
23:10 dukeleto 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
23:11 dukeleto whiteknight: you are doing this in master?
23:11 dukeleto whiteknight: or my branch?
23:11 whiteknight master
23:11 dukeleto whiteknight: cool.
23:11 whiteknight unless you want me to fiddle with your branch?
23:11 dukeleto whiteknight: nope. i will merge master in again
23:11 whiteknight oaky
23:11 dukeleto whiteknight: do what ye will
23:12 whiteknight this also explains those double-frees you were seeing
23:12 whiteknight that whole function is basically a weapon. It's like an oddly-named hcf
23:12 dukeleto whiteknight: indeed. that TT can be closed if Parrot_PMC_destroy doesn't exist any more
23:12 dukeleto whiteknight: lulz
23:12 dukeleto whiteknight: this will make great material for my next grant update blog post
23:13 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
23:13 dukeleto just sayin'
23:13 NotFound This only adds one more place of misleading outdated information.
23:13 NotFound dukeleto: yes, SEE ALSO is good, DO THIS is bad.
23:15 NotFound But note that we probably also have a lot of wrong SEE ALSO.
23:15 dalek parrot: cbfc76e | Whiteknight++ | / (3 files):
23:15 dalek parrot: Nuke Parrot_PMC_destroy. It's an extremely dangerous function that should *ABSOLUTELY NEVER BE CALLED BY ANYBODY EVER*. Seriously. Re-read that.
23:15 dalek parrot: review: https://github.com/parrot/parrot/commit/cbfc76e64a
23:15 * dukeleto laughs a good laugh
23:16 tcurtis_ whiteknight: does that not need a deprecation cycle?
23:16 whiteknight tcurtis: no
23:16 whiteknight tcurtis_: ever using that function would cause your program to crash. We don't support crashes
23:17 whiteknight 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 #parrot
23:19 cotto_work whiteknight++ for bringing me joy with your commit messages
23:20 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?
23:20 dalek parrot/leto/embed_grant: c0d0b11 | dukeleto++ | t/src/extend_vtable.t:
23:20 dalek parrot/leto/embed_grant: Merge branch 'leto/embed_grant'
23:20 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/c0d0b11c38
23:20 dalek parrot/leto/embed_grant: 4046b69 | cotto++ | lib/Parrot/Test.pm:
23:20 dalek parrot/leto/embed_grant: various English fixes in inline POD, patch courtesy of soh_cah_toa++
23:20 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/4046b69b3f
23:20 dalek parrot/leto/embed_grant: 6f2f834 | dukeleto++ | t/src/extend_vtable.t:
23:20 dalek parrot/leto/embed_grant: Unbreak master by avoiding the unpleasant Parrot_PMC_destroy function
23:20 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/6f2f834664
23:20 dalek parrot/leto/embed_grant: cbfc76e | Whiteknight++ | / (3 files):
23:20 dalek parrot/leto/embed_grant: Nuke Parrot_PMC_destroy. It's an extremely dangerous function that should *ABSOLUTELY NEVER BE CALLED BY ANYBODY EVER*. Seriously. Re-read that.
23:20 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/cbfc76e64a
23:20 dalek parrot/leto/embed_grant: 67b4080 | dukeleto++ | / (45 files):
23:20 dalek parrot/leto/embed_grant: Merge remote branch 'origin/master' into leto/embed_grant
23:20 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/67b40809b9
23:20 dukeleto blarg
23:21 dukeleto i am good at confusing dalek
23:22 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"
23:22 dukeleto whiteknight: it would be nice for there to be a record of it, but I want it to stay deleted
23:24 dukeleto 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
23:24 NotFound Lua?
23:25 lucian is it working? nice
23:25 NotFound I think pmichaud take care of it.
23:26 lucian hmm, i'm trying to decide whether parrot on arm is slow
23:26 whiteknight brb
23:26 whiteknight left #parrot
23:26 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.
23:27 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.
23:27 dukeleto lucian: Lua and Cardinal are both in good health
23:27 lucian dukeleto: nice
23:28 lucian NotFound: hmm. i should probably profile it on arm and compare with x86
23:29 NotFound lucian: as slow as orders of magnitude worse than in my Asus EEE first generation.
23:29 whiteknight joined #parrot
23:30 NotFound But maybe the gcc farm machine had competing processes.
23:30 dalek parrot: 16871ba | dukeleto++ | NEWS:
23:30 whiteknight left #parrot
23:30 dalek parrot: Add a note to NEWS about Parrot_PMC_destroy
23:30 dalek parrot:
23:30 dalek parrot: This information should go somewhere, probably in api.yaml as well. If
23:30 dalek parrot: you remove this info from NEWS, please make sure it is recorded
23:30 dalek parrot: somewhere else.
23:30 dalek parrot: review: https://github.com/parrot/parrot/commit/16871baafe
23:30 whiteknight joined #parrot
23:34 dalek TT #2123 closed by whiteknight++: t/src/extend_vtable.t: Null PMC access in destroy
23:34 dalek TT #2123: http://trac.parrot.org/parrot/ticket/2123
23:37 lucian NotFound: boostrapping winxed is very slow here. maybe i'm swapping
23:39 lucian yeah, that's the problem. i have 400mb ram and parrot wants more
23:41 sorear I think it would be more useful to describe memory usages in Mwords
23:52 lucian left #parrot
23:53 lucian joined #parrot
23:54 whiteknight I would like to start a cull of our array types
23:54 whiteknight I would like to deprecate and remove all our Fixed*Array types
23:55 whiteknight 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?
23:55 whiteknight you can presize the resizable arrays
23:55 lucian i'm not arguing against it, just wondering if there's a use-case for fixed ones
23:55 whiteknight ResizablePMCArray isa FixedPMCArray. When you grow it, it grows the underlying FixedPMCArray
23:55 lucian most likely not
23:56 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
23:56 sorear 96 mword?
23:56 lucian ah. then it makes perfect sense
23:59 whiteknight I would like to see the winxed source broken up into a series of smaller files like what Rosella does

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

Parrot | source cross referenced