Camelia, the Perl 6 bug

IRC log for #parrot, 2011-01-07

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 cotto_work Kapace: what's md5sum_c.pir?
00:00 Kapace cotto_work: thats the md5sum example using the class interface
00:01 cotto_work I'd rename to md5sum_oo.pir .  c seems to indicate that it has something to do with C.
00:01 Kapace s/class/object/
00:02 Kapace ok, git has rename/move tool?
00:02 cotto_work git rename
00:02 cotto_work er, git mv
00:02 Kapace yeah, ok
00:03 Kapace cotto_work: should I put the sha256 stuff in the same pull, or different?
00:03 cotto_work Kapace: whatever's easier
00:03 cotto_work I haven't merged yet
00:04 Coke .
00:04 Kapace ok
00:04 cotto_work do you want a gci task for sha256?
00:06 Kapace yes please :)
00:06 Kapace Got to make sure I stay in the top 10, don't want anything crazy to happen in the last few days
00:08 * whiteknight really loves the github postmortem reports
00:09 whiteknight Most online services don't really offer that kind of introspective analysis. It's fascinating
00:10 cotto_work Kapace: need to update the test plan
00:10 cotto_work everything else looks good
00:10 cotto_work new task created
00:10 Kapace ok thanks
00:14 Kapace cotto_work: alright fixed the plan. 1 Hour for SHA task :|
00:14 Kapace (even worse "1 Hours")
00:14 Kapace melange--
00:17 cotto_work marked complete, time fixed
00:19 cotto_work melange--
00:21 cotto_work Kapace: don't forget to run the codingstds tests
00:23 Kapace ok, Ill try to remember. (I should setup an alias for git commit to automatically ask if I ran it)
00:23 plobsing joined #parrot
00:41 Kapace http://dpaste.com/295061/
00:43 gbacon left #parrot
00:51 dalek nqp-rx/smoke: 1ec882f | dukeleto++ | build/Makefile.in:
00:51 dalek nqp-rx/smoke: Getting closer to smoking nqp-rx
00:51 dalek nqp-rx/smoke: review: https://github.com/perl6/nqp-rx/commit/1ec882f32c
00:51 dalek nqp-rx/smoke: 27f1ff4 | dukeleto++ | build/Makefile.in:
00:51 dalek nqp-rx/smoke: Looks like we need a harness
00:51 dalek nqp-rx/smoke: review: https://github.com/perl6/nqp-rx/commit/27f1ff4425
00:53 Yuki`N joined #parrot
00:59 cotto_work Kapace: can you fix it?
00:59 dmalcolm left #parrot
00:59 cotto_work and add a test
00:59 kapace_ I doubt I can fix it, don't know enough about encryption :|
01:00 cotto_work I'm sure the algorithm is well-documented
01:00 kapace_ I can open a ticket :P
01:00 cotto_work that's purely optional though
01:00 cotto_work ok
01:06 cotto_work kapace_: it'd be helpful to write a couple test cases with externally-verified sha256 sums
01:06 dalek nqp-rx/smoke: 3fc8dc8 | dukeleto++ | / (3 files):
01:06 dalek nqp-rx/smoke: We can now make Smolder shoot 500-smoke
01:06 dalek nqp-rx/smoke: review: https://github.com/perl6/nqp-rx/commit/3fc8dc82dc
01:07 kapace_ cotto_work, what counts as externally verifiable? a link to a online hash calculator? a file and my sha256sum output?
01:09 dalek parrot/kill_packfile_new_dummy: 5a85e76 | Whiteknight++ | src/ (2 files):
01:09 dalek parrot/kill_packfile_new_dummy: remove PackFile_new_dummy. A few test failures pop up
01:09 dalek parrot/kill_packfile_new_dummy: review: https://github.com/parrot/parrot/commit/5a85e76fa2
01:11 cotto_work any of those
01:12 Kapace ok cool
01:12 cotto_work also, "verified" (i.e. you didn't use the pir code to verify itself) not "verifiable"
01:25 cotto_work msg dukeleto your thoughts are welcome on http://trac.parrot.org/parr​ot/wiki/AutomatedHLLTesting
01:25 aloha OK. I'll deliver the message.
01:30 Kristaba left #parrot
01:36 dalek tracwiki: v1 | cotto++ | AutomatedHLLTesting
01:36 dalek tracwiki: initial free-form braindump
01:36 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Autom​atedHLLTesting?version=1&action=diff
01:36 dalek TT #1936 created by DavidCzech++: SHA256 sums don't seem to match with external tools.
01:36 dalek TT #1936: http://trac.parrot.org/parrot/ticket/1936
01:40 whiteknight msg plobsing I created a kill_packfile_new_dummy branch to try and rip out PackFile_new_dummy. This is the first step in not treating the initial packfile specially. Parrot compiles and runs without it just fine, but a handful of tests fail. I need to review them all to see how serious they are
01:40 aloha OK. I'll deliver the message.
01:52 davidfetter left #parrot
01:59 cotto_work whiteknight: that's a special test case you added.
01:59 cotto_work It's not often I want to clean up testing code to make it easier to understand.
02:00 whiteknight cotto_work: the purpose there is just to tailcall as much as possible, including a tailcall into the PIR compiler
02:00 cotto_work not quite minimal, but it works
02:00 cotto_work time to decommute
02:11 rfw argh goddammit
02:12 rfw is it okay if i use some double pointer naughtiness
02:30 rfw reduced fill_params by 117 lines
02:30 rfw yay
02:36 rfw http://www.google-melange.com/gci/task/show/goog​le/gci2010/parrot_perl_foundations/t129413127098
02:36 rfw made fulltest, unrelated things failed
02:36 rfw one test in class.t relating to inspect, no tests executed in packfileopmap.t
02:37 rfw whiteknight: are you there?
02:38 whiteknight sorta
02:38 rfw does sorta mean yes you can review? :(
02:39 whiteknight sorta
02:39 whiteknight link?
02:39 rfw http://www.google-melange.com/gci/task/show/goog​le/gci2010/parrot_perl_foundations/t129413127098
02:42 whiteknight rfw: it builds and passes all tests?
02:42 rfw whiteknight: it fails unrelated tests
02:42 whiteknight does master fail tests too?
02:42 rfw yes
02:42 whiteknight oh, okay then
02:42 cotto ~~
02:43 dalek parrot/gci_fill_params_reduce: 18d905a | rfw++ | src/call/args.c:
02:43 dalek parrot/gci_fill_params_reduce: Moved some parameter assignment routines into their own functions.
02:43 dalek parrot/gci_fill_params_reduce: review: https://github.com/parrot/parrot/commit/18d905aec2
02:43 cotto we need to make sure and do some benchmarking on that too
02:43 cotto I'm pretty sure any competent compiler will inline static functions, but better safe than sorry
02:43 whiteknight it's pulled into a branch
02:43 whiteknight so we can test it there
02:44 whiteknight we may want to mark them all PARROT_HOT too
02:44 whiteknight make Andy happy
02:44 whiteknight rfw: pulled, approved the task
02:44 rfw thanks
02:45 whiteknight I don't have time for any more review though, time for bed
02:45 whiteknight goodnight
02:45 rfw night whiteknight
02:45 whiteknight left #parrot
02:54 NotFound left #parrot
02:55 NotFound joined #parrot
02:55 PacoLinux left #parrot
02:56 PacoLinux joined #parrot
03:00 kid51 joined #parrot
03:10 gbacon joined #parrot
03:17 kid51 Yuki`N: ping
03:19 kid51 msg whiteknight: I will look at TT #196 -- but can you add your recent experiences in that environment to that ticket?  Thanks.
03:19 aloha OK. I'll deliver the message.
03:22 Yuki`N kid pong
03:23 Yuki`N kid51,
03:24 Yuki`N left #parrot
03:24 kid51 Yuki`N: For the purpose of GCI, you can complete your work on that configure.log and get credit -- but we should not merge it into master without further discussion (see http://trac.parrot.org/parrot/ticket/1199)
03:25 kid51 msg Yuki`N For the purpose of GCI, you can complete your work on that configure.log and get credit -- but we should not merge it into master without further discussion (see http://trac.parrot.org/parrot/ticket/1199)
03:25 aloha OK. I'll deliver the message.
04:10 kid51 left #parrot
04:17 contingencyplan left #parrot
04:32 gbacon left #parrot
04:40 dalek ohm-eta-wink-kzd: 08af6a3 | plobsing++ | README.pod:
04:40 dalek ohm-eta-wink-kzd: add README
04:40 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/08af6a3c9a
05:35 particle left #parrot
05:41 Kapace cotto: looks like I'm going to have to add a new file for sha testing, i think...
05:41 Kapace gedit--
05:43 rurban_ joined #parrot
05:44 cotto Kapace, yup
05:45 Kapace cotto: is there docs for that, or can you guide me through the process?
05:46 rurban left #parrot
05:46 rurban_ is now known as rurban
05:47 Kapace this is what my test file is looking like: http://dpaste.com/295109/
05:47 Kapace is there an easier way to make those is() calls into todo()s?
05:48 cotto Kapace, you mean other than s/is/todo/ ?
05:48 cotto no.  That's a weakness of PIR-based tests currently.
05:48 Kapace don't i need to make a comparision first?
05:49 Kapace oh ok.. well it will just have to be done once the bug is fixed
05:50 Kapace (which I'll like to investigate some more, probably after GCI)
05:51 bacek_at_work cotto, idea for GCI? Implement something like C<is(foo, bar, "Description", :todo("NYI"))> in parrot's Test::More
05:52 cotto bacek_at_work, that's not a bad idea
05:52 bacek_at_work "medium" size project
05:53 cotto sounds about right
05:53 bacek_at_work got for it :)
05:56 Kapace so, how do I add my new test to the makefiles etc?
05:57 Kapace or do they just test all files *.t?
05:57 cotto Kapace, I think you just drop it in the right dir and it'll get run.
06:00 Kapace awesome, then add to MANIFEST and commit? er make codetest :)
06:01 cotto and distrotest
06:01 cotto you can just run perl tools/dev/mk_manifest_and_skip.pl
06:01 cotto we're lazy like that
06:01 Kapace cool
06:03 Kapace make distrotest -> no rule to make target 'distrotest' ?
06:05 cotto distro_tests
06:06 cotto If you're on Ubuntu (and possibly others), you can use tab completion for makefile targets.
06:06 Kapace oh, cool
06:11 dalek ohm-eta-wink-kzd: 7ea81e1 | plobsing++ | / (35 files):
06:11 dalek ohm-eta-wink-kzd: move /src to /bootstrap
06:11 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/7ea81e119b
06:11 dalek ohm-eta-wink-kzd: 02b43c3 | plobsing++ | / (2 files):
06:11 dalek ohm-eta-wink-kzd: add toplevel makefile for end user use (hide uglyness in bootstrap makefile)
06:11 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/02b43c3dec
06:11 dalek ohm-eta-wink-kzd: 7345ecc | plobsing++ | src/ometa-winxed (2 files):
06:11 dalek ohm-eta-wink-kzd: add bootstrap files
06:11 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/7345ecc874
06:11 dalek ohm-eta-wink-kzd: c892f81 | plobsing++ | Makefile:
06:11 dalek ohm-eta-wink-kzd: add rules to actually build default targets
06:11 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/c892f818c4
06:15 cotto bacek_at_work, are you sure that'd be a medium task?  There's a lot of code that'll need changing.
06:17 bacek_at_work cotto, I don't think so. You can confirm with chromatic about complexity.
06:18 cotto bacek_at_work, how does http://socghop.appspot.com/gci/task/show/google​/gci2010/parrot_perl_foundations/t129438019014 look?
06:19 bacek_at_work cotto, remove "todo" from list of functions to change :)
06:19 cotto I thought I caught that one
06:19 bacek_at_work hese functions are ok, nok, is, is_deeply, like, isa_ok, isnt, todo,
06:20 cotto fix't
06:21 aantn joined #parrot
06:21 bacek_at_work I would add "Add tests for new behaviour" explicitly into task
06:22 cotto also a good idea
06:25 dukeleto ~~
06:25 cotto hio dukeleto
06:27 dalek parrot: add4e13 | bacek++ | t/pmc/packfileopmap.t:
06:27 dalek parrot: Don't test loading od dynops after coretest
06:27 dalek parrot: review: https://github.com/parrot/parrot/commit/add4e13a53
06:28 dukeleto cotto: i just read your hll testing wiki page
06:28 cotto thoughts?
06:28 cotto flames?
06:28 cotto pasta?
06:30 dukeleto cotto: it is good. is that list in order of importance, or random order ?
06:30 cotto dukeleto, random
06:30 cotto bacek_at_work, doesn't that test need some jumping around to make sure the same number of tests are run in both cases?
06:30 dalek ohm-eta-wink-kzd: 5f40c83 | plobsing++ | README.pod:
06:30 dalek ohm-eta-wink-kzd: license formatting
06:30 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/5f40c83533
06:31 dukeleto cotto: ok. also, for me right now, i am going to test nqp-rx master on parrot master and then iterate from there. I see that being the first useful feature that we need
06:31 cotto dukeleto, I agree
06:31 cotto Rakudo is important, but that can be the second hll
06:32 dukeleto cotto: yep, rakudo is second in line. nqp-rx is the canary in the coal mine
06:33 dukeleto cotto: plumage is probably next, or possibly second, since that allows testing many HLLs
06:33 cotto also a good idea
06:40 dukeleto cotto: can you add some info about which Configure.pl flags you would like to see tested on the wiki page?
06:41 dukeleto cotto: and perhaps something about how plumage can be used?
06:42 cotto sure
06:43 aantn left #parrot
06:45 aantn joined #parrot
06:50 particle joined #parrot
06:51 dalek tracwiki: v2 | dukeleto++ | AutomatedHLLTesting
06:51 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Autom​atedHLLTesting?version=2&amp;action=diff
06:51 dalek tracwiki: v3 | cotto++ | AutomatedHLLTesting
06:51 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Autom​atedHLLTesting?version=3&amp;action=diff
06:57 cotto upgrade time
06:57 cotto left #parrot
07:04 cotto joined #parrot
07:07 Kapace what did you upgrade?
07:08 cotto ubuntu to 10.01
07:08 cotto er 10.10
07:09 cotto now to copy everything to an ssd
07:11 fbrito joined #parrot
07:11 cotto left #parrot
07:16 aantn left #parrot
07:23 aantn joined #parrot
07:32 chromatic left #parrot
07:43 fperrad joined #parrot
08:06 rfw Kapace: are you there
08:10 fbrito rfw: I am just 7 points from getting out of the top 10, ahahha. starting to get really worried.
08:10 rfw fbrito: i hope you make it
08:18 fbrito me too, ehhe
08:18 rfw fbrito: you wouldn't happen to know how to fuzz test ffmpeg would you :x
08:19 fbrito rfw: coincidently I have my last uni tests on 10th (gci deadline)
08:19 rfw oh
08:19 rfw good luck!
08:19 rfw alsoi accidentally read that as "last unit tests"
08:19 fbrito ahhaha
08:21 fbrito rfw: on my English class book we had "unit tests" and even a "mock tests" :D
08:22 rfw lol
08:28 rurban left #parrot
08:46 dalek plumage: 887882c | fperrad++ | plumage/metadata/nqp-rx.json:
08:46 dalek plumage: [NQP-rx] add target clean & realclean
08:46 dalek plumage: review: https://github.com/parrot/​plumage/commit/887882c523
09:03 fbrito I have just started working on this task: http://www.google-melange.com/gci/task/show/goog​le/gci2010/parrot_perl_foundations/t129438019014
09:03 fbrito is "ok(foo, "foo works", :todo("doesn't work yet"))" syntax correct? I am getting "error:imcc:syntax error, unexpected $undefined (':')" error
09:04 theory left #parrot
09:05 moritz it might be 'todo'=>'reason'
09:06 moritz the :todo(...) thing works in Perl 6
09:06 fbrito moritz: yeah, I have just found this syntax on the PIR book
09:07 fbrito thank you :)
09:11 * moritz accepts claim
09:13 aantn left #parrot
09:13 aantn joined #parrot
09:18 aantn how can I get a class's type number in PIR?
09:18 aantn I'm trying to test PMCProxy
09:36 ppant joined #parrot
09:51 fbrito aantn: class type number? can you show me some piece of code?
09:52 aantn aloha: coverage
09:53 aantn oops
09:53 aantn fbrito: look at init_pmc in http://tapir2.ro.vutbr.cz/cover/cove​r-results/2011-01/2011-01-06-ef82f5c​/c_cover/src-pmc-pmcproxy-pmc.html
09:53 aantn frodwith: class type numbers are used internally to look up classes
09:54 aantn fbrito: I think they map up to the PMC's location in an array of types
09:54 aantn fbrito: which allows for quick lookup and instantation
09:55 fbrito hm, interesting
09:57 fbrito sorry, but I am also a GCI student... can't help much :(
09:58 fbrito I am going to bed. good night
10:00 cotto joined #parrot
10:01 rfw left #parrot
10:06 fbrito left #parrot
10:13 * cotto just realized that he typed
10:13 cotto "man watch" into a terminal
10:20 tadzik like a Night Watch
11:29 mj41 left #parrot
11:40 redicaps joined #parrot
11:47 contingencyplan joined #parrot
11:56 nwellnhof joined #parrot
11:56 ppant left #parrot
11:57 nwellnhof left #parrot
12:00 mj41 joined #parrot
12:13 GodFather joined #parrot
12:35 Coke We tried very hard a while back to remove all non-C references to the type number.
12:37 fperrad left #parrot
12:42 bluescreen joined #parrot
12:57 jnthn Heh, I tried to kill the type number altogether way back... :)
12:58 moritz and a few days ago you tried to write a cache based on them :-)
12:58 moritz ... which didn't work with parametric types, it seems
12:59 jnthn moritz: Aye
12:59 jnthn moritz: Well, was an interesting experiment none the less.
12:59 jnthn Too bad it didn't work out.
13:00 moritz /o\
13:00 jnthn We'll get that win - but better and more globally - out of the new meta-model (though it's not a cache as such - or not like that anyway...)
13:00 mikehh left #parrot
13:00 jnthn In fact, that was what inspired me to try it.
13:01 jnthn Oh, I know why parametric types maybe broke...
13:03 cotto jnthn, ping (since I'm up anyway)
13:06 mikehh joined #parrot
13:06 jnthn o/ cotto
13:06 jnthn Just got back from Christmas/New Year's break today :)
13:06 rurban joined #parrot
13:06 cotto wb
13:06 jnthn thx :)
13:06 cotto jnthn, how prototypey is nom?  The code is unusual.
13:07 jnthn Varies :)
13:07 jnthn "unusual"? :)
13:07 cotto either that or I haven't looked at much object metamodel code
13:08 cotto how much do you think the implementation will change between now and when it's called "ready"?  Documenting it would be a good way for me to learn it, but I don't want to spend too much time on something temporary.
13:09 jnthn There's a lot missing compared to what's in the 6model repo (I plan to change that over the next week or so, though, and get things muchly caught up).
13:10 jnthn There's also places where I did stuff a certain way to make my life easier, but that's not structural, more just "could be more optimal but I wanted it to work first"
13:10 cotto that makes sense
13:10 cotto I look forward to seeing what you have in store.
13:11 jnthn OK. I know it's badly documented too. That's also very high on my hit list.
13:11 cotto what's stable enough to start documenting?
13:11 cotto The best person to write docs is someone who doen't know what's going on, so I'm highly qualified.
13:11 jnthn The S-Table and REPR data structures are, the KnowHOW bootstrap probably mostly is too.
13:12 jnthn P6opaque REPR - feel free to document but it needs to become more complicated soonish.
13:12 cotto hints?
13:13 jnthn At the moment it's missing the ability to handle native type (or native struct) attributes.
13:13 jnthn It also does a memory allocation too many.
13:15 jnthn If you wish to document pieces of it, that's fine. I think maybe most useful for me to do, is write an overview of what the pieces actually do to make up a useful whole.
13:15 jnthn (e.g. a doc on why everything is designed the way it is)
13:15 moritz that is the most useful piece of documentation that is missing most often
13:15 cotto sorry.  Are your upcoming changes related to hints?  I noticed that all the hint-related code was stubbed out.
13:16 jnthn Oh, I thought that was meta... :)
13:16 moritz (and that's the reason why Perl modules usually have a SYNOPSIS section -- it gives an overview of how to use the different parts)
13:16 cotto Yes.  I really miss the inline POD.
13:16 jnthn cotto: Yes, more bits on hints will be coming at some point.
13:16 jnthn Though it's not top of the hit list.
13:17 jnthn But it'll happen, for sure.
13:17 cotto What are they?
13:17 jnthn For attributes, a way to do the lookup just as an index rather than a name lookup.
13:17 jnthn For methods, similar, but the lookup is into a v-table
13:17 cotto ok.  that's pretty simple.
13:18 jnthn Thing is that for it to work, one needs to have the meta-objects at compile time.
13:18 jnthn So you can ask it what index things will be at and compile that into the code.
13:18 jnthn That's where things get a bit trickier. :)
13:21 cotto Is it fine if I start documenting with inline POD or do you prefer a different format?
13:22 jnthn Ideally, I'd prefer a format that doesn't mean the function name and signature have to be repeated in the docs as well as the code.
13:22 cotto What's your preference?
13:23 jnthn Well, I don't really have a problem with a C-style comment before the function explaining what it does. ;-)
13:23 jnthn But I'm not sure if that counts as a documentation format. ;)
13:24 cotto good enough
13:24 jnthn Well, it's mostly if you want to extract the stuff. I figure that's what POD offers.
13:24 jnthn There's already plenty of readers and tools for munging it.
13:24 cotto that's the advantage I see in POD
13:24 cotto but I don't care that much
13:24 jnthn Anyway, I don't feel too strongly on the issue.
13:26 cotto ok
13:26 jnthn (That is, if POD gets used, I certainly won't complain.)
13:28 * cotto tries attempt #3 to get to sleep
13:35 pmichaud good morning, #parrot
13:36 moritz good morning pmichaud
13:38 jnthn pmichaud! :)
13:44 rurban_ joined #parrot
13:47 rurban left #parrot
13:47 rurban_ is now known as rurban
13:47 dalek winxed: r729 | NotFound++ | trunk/winxedst1.winxed:
13:47 dalek winxed: compile time evaluation of substr with constant arguments
13:47 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=729
13:51 GodFather left #parrot
13:58 whiteknight joined #parrot
14:09 plobsing left #parrot
14:10 mikehh t/src/embed.t - TODO passed:   3 in optimized builds, but not without --optimize (both gcc and g++ - Ubuntu 10.10 i386 4.5 version of compiler)
14:10 mikehh seems to happen on amd64 as well, but will test there later
14:11 mikehh I think it might be due to ASSERT not happening with optimized builds.
14:19 whiteknight okay, so either we have a faulty assert that is too restrictive, or we have really terrible input conditioning
14:38 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#2121) fulltest) at 2_11_0-778-gadd4e13 - Ubuntu 10.10  i386 (gcc-4.5 with --optimize)
14:38 mikehh t/src/embed.t - TODO passed:   3
14:47 mikehh whiteknight: src/thread.c:1397: failed assertion '!interpreter_array' with no --optimize
14:47 aantn left #parrot
14:47 mikehh whiteknight: which it won't fail with an optimized build
14:50 whiteknight stupid interpreter_array
14:50 whiteknight that variable is the primary reason why I wanted to rip threads out
14:51 whiteknight aloha coverage?
14:51 aloha whiteknight: coverage is http://cv.perl6.cz or http://tapir2.ro.vutbr.cz/cover/cover-results/
14:53 nopaste "mikehh" at 192.168.1.3 pasted "t/src/embed.t - TODO passed: 3 with optimized build" (26 lines) at http://nopaste.snit.ch/27580
14:54 plobsing joined #parrot
14:56 mikehh maybe I should open a ticket on that
14:56 whiteknight yes, please
15:03 JimmyZ joined #parrot
15:06 Patterner left #parrot
15:07 Psyche^ joined #parrot
15:07 Psyche^ is now known as Patterner
15:07 particle1 joined #parrot
15:11 particle left #parrot
15:21 dalek TT #1937 created by mikehh++: t/src/embed.t - TODO passed:   3 in optimized builds
15:21 dalek TT #1937: http://trac.parrot.org/parrot/ticket/1937
15:21 particle1 is now known as particle
15:26 plobsing left #parrot
15:35 fperrad joined #parrot
15:42 Andy joined #parrot
15:48 dalek winxed: r730 | NotFound++ | trunk/winxedst1.winxed:
15:48 dalek winxed: compile time evaluation of indexof with constant arguments
15:48 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=730
15:55 fbrito joined #parrot
15:55 plobsing joined #parrot
15:59 dalek plumage: e2f0543 | fperrad++ | plumage/metadata/rakudo.json:
15:59 dalek plumage: [rakudo] add target: clean & realclean
15:59 dalek plumage: review: https://github.com/parrot/​plumage/commit/e2f0543d24
16:01 JimmyZ left #parrot
16:07 dalek parrot: 2025a9f | Whiteknight++ | docs/embed.pod:
16:07 dalek parrot: restore the old embed.pod, which contains details from dukeleto and will be necessary in the transition.
16:07 dalek parrot: review: https://github.com/parrot/parrot/commit/2025a9fac5
16:07 dalek parrot: 8bffd5b | Whiteknight++ | docs/embed_new.pod:
16:07 dalek parrot: add in a new version of the embed docs, for the new API that doesn't conflict with dukeleto's changes
16:07 dalek parrot: review: https://github.com/parrot/parrot/commit/8bffd5b339
16:07 dalek parrot: fa9eece | Whiteknight++ | docs/embed.pod:
16:07 dalek parrot: add a note to the old documentation about the phase-out and a link to the new docs
16:07 dalek parrot: review: https://github.com/parrot/parrot/commit/fa9eecec7f
16:07 pmichaud is plumage intended to be an "end-user" tool, or one just for developers?
16:07 whiteknight pmichaud: an end-user tool
16:08 whiteknight I see it as being similar in purpose and use to the cpan client for perl5
16:08 pmichaud ...then why does it install Rakudo HEAD?
16:08 pmichaud isn't that like someone saying that Parrot end-users should download and install Parrot HEAD?
16:08 whiteknight pmichaud: It has a file of metadata that tells it what to install. The metadata for Rakudo may need to be updated/improved
16:08 pmichaud yes, I was reading the metadata when I noticed that it installed Rakudo HEAD
16:09 pmichaud that seems wrong.
16:09 whiteknight I don't know if plumage supports tags. It should if it doesn't
16:09 pmichaud also, even the Rakudo team doesn't recommend downloading tags from Rakudo github
16:09 pmichaud we recommend downloading rakudo star tarballs
16:09 whiteknight okay
16:09 whiteknight if plumage doesn't yet support that, it should
16:09 whiteknight I still consider plumage to be immature and in development
16:10 whiteknight so don't be discouraged if it isn't perfect right now
16:10 pmichaud I'm somewhat reacting to fperrad's comment on parrot-dev that says to use plumage for nqp-rx/rakudo testing
16:10 whiteknight I think dukeleto's plan for continuous integration involves plumage as a key component
16:11 pmichaud which seems to completely circumvent the point I'm trying to get to (which is one of having parrot devs do regular rakudo and nqp-rx testing)
16:11 whiteknight he's looking for automated ways to fetch, build, and test many HLLs and external projects
16:11 whiteknight pmichaud: yes. For the common case of parrot devs, not using plumage is probably better
16:11 whiteknight but for the automated case, we want a tool there to manage metadata and test against many projects
16:12 pmichaud fair enough
16:12 pmichaud the automated case probably needs to be testing multiple versions
16:12 whiteknight is it worthwhile to include nqp tests in parrot's ext/ too, so we can include those in the test harness automatically?
16:12 pmichaud for example, it probably makes sense to test Parrot against the latest rakudo release as well as rakudo head
16:12 whiteknight or is the snapshot sufficiently different from nqp-rx HEAD?
16:13 pmichaud I thought about that a fair bit yesterday and decided against it (more)
16:13 whiteknight yes: testing against multiple versions does make sense
16:13 pmichaud for one, hll devs really want parrot devs to test against the language build process
16:13 pmichaud i.e., testing nqp-rx does more than simply ask "does nqp-rx pass its test" but also "can we still build and run an hll?"
16:14 pmichaud I'm afraid many devs would say "oh, the nqp-rx tests ran in the parrot repo, so nqp is good"  when that might not be the case
16:14 pmichaud because the steps that parrot uses to build its copy of nqp is not at all what nqp-rx (or rakudo) do to build themselves
16:15 dmalcolm joined #parrot
16:15 whiteknight okay
16:16 pmichaud add to that the small hassle of keeping nqp-rx tests in sync, and I think it's just easier to say "treat nqp-rx like an external hll for testing"
16:16 whiteknight okay. That works fine for me
16:16 whiteknight my thinking is that the more we can automate, the more likely people are to actually run the tests
16:16 whiteknight but maybe we need something larger than just a transparent change to the test harness for that
16:16 pmichaud that said, I won't object to having a copy of nqp-rx's tests in ext/ if others think that's a useful addition.  I'd hate to see it become "use the internal tests and skip nqp-rx build testing" though.
16:18 pmichaud iirc, we have had at least one instance where nqp-rx in the parrot repo would've passed its tests but nqp-rx as a separate hll would've been unable to build.  This is especially true when dealing with deprecations.
16:18 whiteknight What I'm thinking in the long term is that maybe we need a separate integration branch from our current master
16:18 pmichaud as long as releases are coming from the integration branch, sure.
16:18 whiteknight the integration branch will be used for releases, and must always be tested to the nth degree before merging into it
16:19 whiteknight right. That way we can avoid little hiccups as master changes, and provide a more tested and more stable branch for HLLs to build from
16:19 pmichaud I'm not sure I see that as being any different from what we have now, though
16:19 pmichaud well, it could be
16:20 whiteknight the more tests we want to run, the harder it becomes to make changes to master
16:20 pmichaud I guess if there's someone dedicated to merging master to integration it could work out okay
16:20 whiteknight right. I see that being the purview of the release manager, and maybe a few other individuals
16:20 pmichaud but more generally, let's suppose a committer named "jpatch"  creates a development branch, does a lot of work, and merges to master
16:21 pmichaud when and who do those changes make it to integration?
16:21 pmichaud does jpatch do the merge to integration?
16:21 whiteknight no
16:22 pmichaud okay, that's good
16:22 pmichaud does the release manager do it?
16:22 whiteknight I mean, maybe. We would want somebody that we trust not to be hasty to do it
16:22 whiteknight I think the release manager is a good candidate, since his name is on the release
16:22 pmichaud how long before the release does the manager do it?
16:22 pmichaud I mean, obviously waiting until the day-of-release isn't going to work out.
16:23 whiteknight good question. There are obviously lots of ideas to work out before we try to move to a system like this
16:23 whiteknight if we decide to move to it
16:23 pmichaud right
16:23 pmichaud I could very easily see it being staged at two levels (more)
16:23 whiteknight it does seem very similar to things I've seen Linus say about Linux development. That people should be making branches only from known-stable branch points
16:23 plobsing I'd propose that the release manager creates the branch immediately before the call for extensive testing goes out.
16:23 whiteknight if people branch from broken commits, they are going to have broken branches, etc
16:24 whiteknight an integration branch that is always tested and stable gives us an automatic way to do this: branch from integration, merge into master
16:24 pmichaud plobsing: "call for extensive testing" is part of the problem, I think.
16:24 whiteknight wash, rinse, repeat
16:24 pmichaud plobsing: it seems to put the onus on non-parrot folks to test parrot
16:25 pmichaud it's a way for the parrot devs to say "we can't be bothered to make sure we didn't break anything outside of the deprecation policy"
16:25 plobsing before most releases the release manager sends a message out to parrot-dev requesting testing
16:25 plobsing that is a request targetted at parrot devs
16:26 pmichaud but based on what whiteknight said earlier, an integration branch would be made *after* testing
16:26 pmichaud 16:18 <whiteknight> the integration branch will be used for releases, and must always be tested to the nth degree before merging into it
16:26 whiteknight no, I think the integration branch would be continuous. It would exist side-by-side with master for all time
16:26 pmichaud so the integration branch comes *after* testing, not before.
16:26 whiteknight changes from master would be tested and then merged into integration
16:26 whiteknight by a responsible person
16:27 pmichaud right.  and a "call for extensive testing" somewhat goes against that premise.
16:27 pmichaud unless the call for extensive testing is testing against master
16:28 plobsing pmichaud: so would you rather parrot not be extensively tested? or limit the number of people capable of integration merges to those with access to all platforms about which parrot cares?
16:29 pmichaud plobsing: I care that parrot releases don't break my hlls in ways they aren't supposed to.
16:29 allison joined #parrot
16:31 particle left #parrot
16:31 pmichaud I don't like that the current process seems to rely on hll devs doing frequent testing of master to make sure that parrot releases don't break the hll.
16:32 particle joined #parrot
16:32 whiteknight right. that's sort of backwards
16:32 whiteknight If dukeleto can put together a great continuous-integration system on the GCC compile farm, I think we go a long way towards everybody's needs
16:33 pmichaud viewed in light of what I just wrote, I think I tend to agree.
16:34 pmichaud but I'm also mindful of how long we've talked about having such a system with no real progress (yes, I know there's renewed emphasis now, for which I'm happy, but nothing says 'progress' like working code)
16:34 whiteknight we don't necessarily want to rely on just parrot devs though. there's no way any parrot dev or even all parrot devs can test all permutations of parrot versions, HLL versions, and platforms
16:34 whiteknight but we want to make sure the common cases are all well covered before we put something "live"
16:35 whiteknight pmichaud: We're very acutely aware that Parrot has a reputation problem we need to overcome
16:35 pmichaud I don't mind if a few permutations slip through the cracks.  What bugs me is when there are issues where *none* of the permutations are tested.
16:35 whiteknight right
16:35 pmichaud saying "we can't test all permutations, so let's test none of them" is completely wrong IMO
16:35 plobsing off-topic: is there a library function for mkstemp() within parrot?
16:35 pmichaud saying "one of the permutations takes forever, so let's test none of them" is also completely wrong IMO
16:35 whiteknight right, no. Nobody is saying that
16:36 whiteknight I just want to make clear: parrot devs are going to do a hell of a lot of testing, but we're going to need wider support to make sure the testing is truely comprehensive
16:36 pmichaud whiteknight: actually, people *have* been saying that whenever we ask why HLLs aren't being tested
16:36 whiteknight pmichaud: well, whoever says that is wrong
16:37 pmichaud (comprehensive testing)  I'll be glad for that, but let's not make the perfect the enemy of the good (more)
16:37 pmichaud I'd like to see *some* regular testing taking place without it having to be comprehensive yet
16:38 pmichaud let's focus on getting *some* regular testing going first, and *then* work on comprehensive testing
16:38 pmichaud a simple cron job that tests parrot master against nqp-rx master will catch 95% of the issues, I suspect
16:38 pmichaud a cron job that tests parrot master against rakudo master will get another 3%
16:39 pmichaud (my numbers might be a bit exaggerated on the split between nqp-rx and rakudo, but I suspect simply testing those two platforms would reveal 95%+ of breakages)
16:41 whiteknight right. It's a matter of finding a place to run that cron job that's a bit of a killer right now
16:41 pmichaud feather can't do it?
16:42 whiteknight possibly
16:42 pmichaud that's one of the main reasons that feather exists
16:42 whiteknight I would hate to see a huge Rakudo build for instance be creating problems for other things that run there
16:42 pmichaud we do rakudo builds on feather all the time w/o any problems
16:42 pmichaud that's where the evalbot runs
16:42 whiteknight oh, I wasn't aware
16:42 whiteknight I'm not really sure how beefy a box feather is
16:43 pmichaud it's beefy enough to do repeated rakudo builds :-)
16:43 pmichaud like, every 30 minutes or so
16:43 whiteknight what's the story with those builds? Can we hijack existing builds to do smoke testing against parrot HEAD?
16:43 pmichaud no, because those builds are explicitly against PARROT_REVISION
16:44 whiteknight okay.
16:44 pmichaud those builds are primarily for testing rakudo changes, not parrot ones.
16:44 whiteknight how often does PARROT_REVISION bump
16:44 whiteknight ?
16:44 pmichaud 1.  right after a parrot release
16:45 pmichaud 2.  whenever rakudo needs a new Parrot feature "immediately"
16:45 pmichaud 3.  whenever someone tests rakudo against Parrot head and decides to bump
16:45 pmichaud (end)
16:45 particle beefy doesn't matter.  everything on feather is niced.
16:46 pmichaud also, feather is no longer running svn services, so its got a bit more spare capacity I suspect.
16:46 particle i can devote cycles and ram to a parrot/rakudo testing effort.
16:46 pmichaud feather also has the advantage of having multiple admins available to help
16:46 particle name your favorite distro and i'll create a vm and give you admin rights to set up what you want
16:46 pmichaud (and is frequently watched by many parrot/perl6 folks)
16:47 particle feather is a great place for this.
16:47 particle but if you also want another platform for testing, let me know and i'll help.
16:47 pmichaud in an ideal world, PARROT_REVISION would bump only on parrot releases
16:48 particle i have about 6GB ram (of 20) free at any given time, and 8 cores
16:48 particle so i have plenty to spare.
16:48 whiteknight particle: We may just take you up on that offer
16:48 particle does PARROT_REVISION work with git tags?
16:48 pmichaud particle: yes.
16:48 pmichaud (it has to)
16:49 particle great.
16:49 pmichaud pmichaud@orange:~/rakudo$ cat build/PARROT_REVISION
16:49 pmichaud RELEASE_2_11_0-478-gd69dbbc
16:49 particle well, it could work with only commit hashes, but i can't see it being hard to support any refspec
16:50 pmichaud but normally the way one would test rakudo against a given parrot (e.g., head)   is by using --parrot-config=$PARROT_INSTALL/bin/parrot_config
16:50 pmichaud avoiding PARROT_REVISION altogether.  PARROT_REVISION only comes into play when using --gen-parrot
16:56 redicaps left #parrot
16:56 chromatic joined #parrot
17:04 hercynium joined #parrot
17:04 cotto left #parrot
17:06 theory joined #parrot
17:21 JimmyZ joined #parrot
17:21 cotto_work ~~
17:23 whiteknight good morning, cotto_work
17:24 JimmyZ left #parrot
17:25 cotto_work I was going to reply to the fill_params thread when I saw that it had grown a bit during the night.
17:25 cotto_work looks like good things will come of it, if not the good things originally intended
17:39 fbrito cotto_work: hi :D. I have started working on the PIR todo param GCI task
17:39 cotto_work fbrito, great.  That'll be useful.
17:41 fbrito cotto_work: I am afraid I am going to take a bit longer than what I thought because there are a lot of tests to write
17:43 fbrito like is(). it has is(PMC, Int), is(PMC, String), is(PMC, Number) and is(PMC, PMC). I should write tests with the new todo param to each one of these, with a fail and a success case, right?
17:44 dukeleto ~~
17:45 dukeleto particle: howdy
17:45 particle heya duke
17:45 plobsing left #parrot
17:48 dukeleto particle: i am working on adding "make smoke" to nqp-rx and testing nqp-rx master on parrot master on the GCC compile farm
17:48 darbelo joined #parrot
17:51 particle let me know if you need access to any resources i can provide
17:52 dukeleto particle: ok, will do.
18:04 cotto_work I've added a gci task to fix sha256.pir.  Unless someone's excited about another project, there probably won't be any more tasks created.
18:04 cotto_work (by me, at least)
18:05 cotto_work fbrito: any new code added should be covered.  How much longer do you think it'll take than you initially thought?
18:06 dalek TT #1038 closed by cotto++: Convert Digest::MD5 to object-based implementation
18:06 dalek TT #1038: http://trac.parrot.org/parrot/ticket/1038
18:07 fbrito cotto_work: I have added the todo param to all the functions mentioned on the task. So far I have only written tests to "ok, nok and is", but now I see that it won't take that long to write tests to the other functions
18:07 cotto_work ok
18:07 cotto_work that's good to hear
18:08 cotto_work I don't want any other students getting harder tasks than expected.
18:09 fbrito cotto_work: ah, the the task mentioned the following syntax "ok(foo, "foo works", :todo("doesn't work yet"))", but thats perl 6 syntax. in PIR we have to use the "todo" => "doesn't work yet"
18:12 moritz is there already a parrot ticket for the newest rakudo spectest failures
18:12 moritz ?
18:12 moritz if not, I could open one
18:12 cotto_work fbrito: foo(1 :named('x'), 2 :named('y')) also works
18:12 cotto_work moritz: sure.
18:12 fbrito hm, interesting
18:14 dukeleto fbrito++ # doing hard stuff
18:14 cotto_work I was thinking of nqp-rx in what I mentioned in gci task
18:15 cotto_work dukeleto: do you think that should be a difficult task?
18:16 dukeleto cotto_work: huh?
18:17 cotto_work the gci task to add todo to PIR Test::More
18:17 pmichaud moritz: I'd guess file a ticket.  Is Rakudo not working "again"?
18:17 cotto_work is it rightly marked "medium"?
18:18 * pmichaud rebuilds parrot and tries rakudo
18:18 dukeleto cotto_work: we have a todo() it just sucks. Are you talking about implementing the feature where test functions look for a TODO lexical variable?
18:18 moritz pmichaud: failures in t/spec/S14-roles/crony.t, t/spec/S14-roles/mixin.rakudo and t/spec/integration/advent2009-day18.rakudo
18:18 dalek parrot: f4d04a8 | cotto++ | / (5 files):
18:18 dalek parrot: Merge branch 'kapace/objectify_md5' of https://github.com/kapace/parrot into kapace-kapace/objectify_md5
18:18 dalek parrot: review: https://github.com/parrot/parrot/commit/f4d04a81b4
18:18 dalek parrot: 70238f6 | cotto++ | / (7 files):
18:18 dalek parrot: Merge branch 'kapace-kapace/objectify_md5'
18:18 dalek parrot: review: https://github.com/parrot/parrot/commit/70238f6cce
18:18 dukeleto cotto_work: i haven't seen the task you are talking about
18:18 * dukeleto just woke up
18:18 cotto_work dukeleto: ok
18:18 jnthn moritz: Is day18 role-y too?
18:19 moritz jnthn: yep
18:19 jnthn Darn.
18:19 pmichaud what does todo() do in PIR's Test::More now?
18:19 moritz jnthn: it segfaults.
18:19 jnthn moritz: :(
18:20 pmichaud moritz: have you been able to bisect it yet?
18:20 jnthn moritz: Got a st?
18:20 moritz pmichaud: not a chance. It appeared immediately after the :main thing
18:20 pmichaud oh, so we haven't had a fully-functioning spectest since after :main?
18:20 moritz not afaict
18:21 pmichaud :(
18:21 nopaste "moritz" at 192.168.1.3 pasted "day18 bt" (23 lines) at http://nopaste.snit.ch/27581
18:21 jnthn If it's roles, it's at least in an area I can try and hung down.
18:21 jnthn wtf. :|
18:22 jnthn That's...REALLY not a good place to explode.
18:22 * moritz wonders where nopaste has its fantasy IPs from
18:22 cotto_work pmichaud: the gci task is to make ok(1, "msg here", "todo" => "broken") work.
18:22 moritz it's not even my IP in this local subnet
18:22 jnthn moritz: huh? I can connect to 192.168.1.3 just fine
18:22 jnthn oh, wait...
18:22 jnthn ;)
18:22 fbrito :P
18:23 jnthn moritz: That st is...less helpful than hoped. :(
18:23 pmichaud cotto_work: ah.
18:23 pmichaud cotto_work: in Perl 6 (and I think in P5 also) we've tried to get away from using the todo named argument for todo marking
18:23 pmichaud it's a pain to maintain
18:23 cotto_work pmichaud: the idea is that it's less annoying than using todo()
18:23 pmichaud instead, we have a    todo(number, reason)     call that marks the next <number> tests as todo, supplying <reason>
18:24 pmichaud I think that Test::PIR  has a    todo(test, reason), which is really annoyintg.
18:24 pmichaud *annoying.
18:25 pmichaud looks like Test::PIR currently has  todo(test, test description, reason).  Yes, that's annoying.
18:25 pmichaud but we found that the :test adverb was also annoying
18:25 pmichaud especially when needing to skip a large number of tests
18:25 pmichaud s/skip/todo/
18:27 pmichaud anyway, it's just a thought that if we're fixing Test::More todo() processing, it might be nice to make it closer to Perl 6's approach
18:27 pmichaud (or at least Rakudo's approach)
18:28 jnthn On that stack trace, there seems to have been commits to Parrot recently related to init handling.
18:28 jnthn :init that is
18:28 fbrito so... is my task still valid? :D
18:28 pmichaud there have
18:29 jnthn Then they are probably, given the stack trace, a likely cause of the issue.
18:29 pmichaud jnthn: there's been a bunch of :load / :main / :init related commits this week, iiuc
18:29 jnthn ah
18:29 cotto_work fbrito: yes
18:29 allison left #parrot
18:29 jnthn pmichaud: Probably one of them is to blame for the regression then.
18:29 moritz fbrito: I certainly hope so. If the parrot devs decide that they don't want the result of your work, then it's their decision not to merge
18:29 moritz fbrito: but if you do what the task says, your task will be approved
18:30 cotto_work fbrito: we wouldn't give you a gci task and then say "jk lol"
18:30 pmichaud moritz: I think I'll try a bisect using the neat new parrot-bisect script :-)
18:31 pmichaud might take a while :)
18:31 moritz pmichaud: have fun... I would be surprised if it sophistaced enough, but I would be delighted if it worked :-)
18:31 whiteknight :init, :load, and :main flags do need a major rework and redesign. Hard part is changing them in the way that they need to change without completely breaking things
18:32 pmichaud in the past when I've done parrot bisecting I've done it from the parrot repo and using git-bisect
18:32 pmichaud that might be more robust in this case, then.
18:32 moritz with this script you run 'git bisect' from parrot-as-subdir-of-rakudo
18:33 pmichaud so, 'git bisect tools/parrot-bisect.pl testscript'  ?
18:34 pmichaud er
18:34 moritz git bisect perl ../tools/parrot-bisect.pl testscript
18:35 pmichaud 'git bitsect start <bad> <good>'  followed by 'git bisect run perl..... '   right
18:35 moritz right
18:35 nwellnhof joined #parrot
18:35 moritz note that currently it configures parrot with ccache
18:35 pmichaud that's good -- I typically use ccache
18:36 pmichaud looks like run 'git bisect' from rakudo root, though.
18:36 pmichaud otherwise it can't find ./perl6
18:37 moritz there's a chdir() or two involved
18:37 pmichaud ah, I see.
18:38 pmichaud $rakudo_dir gets set
18:38 pmichaud okay
18:39 dalek TT #1938 created by moritz++: rakudo on parrot RELEASE_2_11_0-777-gef82f5c segfaults on role related ...
18:39 dalek TT #1938: http://trac.parrot.org/parrot/ticket/1938
18:40 pmichaud I don't get a segfault on day18 -- I get "too many arguments"
18:40 plobsing joined #parrot
18:40 pmichaud er, "too many named arguments"
18:41 pmichaud that sounds like a parameter checking error
18:42 pmichaud iwbni bisect-parrot.pl could check the results of 'make localtest', so that multiple tests could be tested.
18:44 whiteknight moritz: is it possible to get a dump of the PIR generated by those failing Rakudo tests?
18:45 pmichaud pmichaud@orange:~/rakudo$ ./perl6 t/spec/S14-roles/crony.t
18:45 pmichaud 1..4
18:45 pmichaud too many named arguments: 1 passed, 0 used in <anon> at line 1 in main program body at line 1
18:45 pmichaud pmichaud@orange:~/rakudo$
18:46 pmichaud I fear we have the case again where two rakudo breakages in master conflict with each other
18:47 pmichaud i.e.:
18:47 pmichaud merge implicit :main  (breaks rakudo)
18:47 pmichaud merge sub argument checking (breaks rakudo)
18:47 pmichaud fix implicit :main  (fixes rakudo partially)
18:48 pmichaud so that it's not possible to use bisect to find the other breakage
18:48 whiteknight pmichaud: I have a good idea where that second breakage is happening at
18:48 pmichaud yes, I know argument checking was being enabled somewhere (more)
18:48 whiteknight if I can see the PIR from that test, I can probably pinpoint it quickly
18:48 pmichaud uploading now
18:48 whiteknight awesome
18:49 plobsing is it possible to augment git bisect to programatically cherry-pick out branch merges?
18:49 pmichaud http://gist.github.com/769909
18:50 dukeleto plobsing: what do you mean?
18:50 nwellnhof when was the sub argument checking change merged? is it this ticket http://trac.parrot.org/parrot/ticket/1103?
18:51 plobsing dukeleto: given situations similar to what pmichaud described, a way to identify all changes causing breakage would be to cherry-pick out certain ones and see if it is still broken in the same way.
18:51 plobsing branch merges being good candidates
18:52 whiteknight according to the network view, that branch wasn't merged
18:53 whiteknight unless those changes were wrongfully included in a different branch which was merged
18:53 pmichaud lunchtime here -- bbl
18:59 dukeleto plobsing: you could "git revert" merges, is that what you mean?
19:00 whiteknight moritz: would it be possible for you to get a GDB stack trace with a debug Parrot?
19:00 whiteknight I have an idea what the problem might be, but without line numbers and parameter values in that stack trace, it's hard for me to really tell
19:00 shortcircuit left #parrot
19:01 shortcircuit joined #parrot
19:01 whiteknight (I know that's a bit of a pain in the ass)
19:02 plobsing dukeleto: yes, the algorithm can be driven manually. I'm wondering if can be automated.
19:05 cotto_work whiteknight: I can repro here
19:05 cotto_work where do you want the stack trace from?
19:06 cotto_work probably Parrot_ex_throw_from_c_args
19:07 nopaste "cotto_work" at 192.168.1.3 pasted "backtrace from rakudo failure in crony.t" (16 lines) at http://nopaste.snit.ch/27582
19:09 moritz whiteknight: how do I build a parrot with debug symbols?
19:09 cotto_work moritz: should be there by default
19:09 plobsing might not be there if you --optimize
19:10 moritz can I both --optimize and have debug symbols?
19:10 moritz for gcc those are not mutually exclusive
19:11 plobsing --ccflags="-g" or --ccflags="-ggdb"
19:11 plobsing those make sure to include the debug symbols
19:11 * moritz tries
19:15 whiteknight Isn't error checking on the number of parameters turned off by default?
19:20 whiteknight https://github.com/parrot/parrot/commit/​a3a8335d226869a76571f7a9bbbeadb43d5c5851
19:21 whiteknight I knew that backtrace looked familiar
19:22 whiteknight so I'm thinking that we should never check the number of named parameters. We revert it to the old behavior and remove the note about it being a hack
19:24 jnthn Also, an error that talks about number of named arguments is awful from a user perspective.
19:25 whiteknight what's funny there is that we have two cases: When X are passed but zero are expected, and when X are passed and Y>0 are expected
19:25 whiteknight the first case silently passed, the second case threw an exception
19:25 whiteknight We need to make that consistent
19:25 moritz why not just list all named arguments that weren't expected?
19:25 whiteknight moritz: that doesn't change the fact that any exception thrown here will break your test
19:26 whiteknight so that raises the question: Do we want an exception where named parameters are passed but not used? I suspect not
19:27 moritz in a low level language like PIR I expect it to be an error
19:27 moritz in a higher level language you can always install a slurpy named hash if you want to surpress it
19:27 moritz it's harder the other way round
19:28 whiteknight moritz: ok, so then the parrot behavior stays as-is, and Rakudo needs to fix it's test
19:28 whiteknight which is not a result I'm inclined to support
19:29 moritz whiteknight: which test is that, btw?
19:29 jnthn I'm confused. Rakudo uses its own binder...
19:29 jnthn So would never be in that code, unless it's happening somewhere in the guts.
19:29 whiteknight crony.t
19:29 whiteknight that's the backtrace cotto gave me from crony.t
19:30 jnthn I suspect that somewhere in the PIR implementing roles, something triggers this check/error.
19:30 jnthn We could do with a PIR-level backtrace to tell us where.
19:30 moritz jnthn: I was just about to say, could be a PIR routine
19:30 jnthn But I guess it segfaults before producing one somehow?
19:31 whiteknight I don't know what's the deal with the segfaulting test. That is a different problem
19:31 whiteknight I don't have a backtrace suitable to debug that one yet
19:31 * moritz recompiles rakudo without custom bactrace printer
19:32 whiteknight so I'm in this code right now. I can go either way. Do I leave count-checking on named parameters in place (then it's your job to debug rakudo) or do I try to take it out?
19:32 whiteknight I don't think this detail is important enough either way
19:35 whiteknight error checking is off by default, which means that behavior is rarely used anyway
19:40 whiteknight left #parrot
19:40 plobsing If you want a PIR-backtrace from gdb, run 'p PDB_backtrace(interp)'. however, after a segfault in pcc, that may not be worth anything.
19:41 whiteknight joined #parrot
19:41 Yuki`N joined #parrot
19:41 cotto_work plobsing: that's handy
19:43 whiteknight cotto_work: what's your opinion on "number of named arguments" errors?
19:43 whiteknight I'll be happy to keep or ditch them at this point. I could care less
19:45 cotto_work I thought we didn't care about extra named arguments.
19:45 whiteknight i certainly don't care about them
19:45 * cotto_work checks the pdds
19:45 whiteknight ok
19:46 whiteknight I don't think we have any tests for it either way
19:47 cotto_work If it's a choice, ignoring them makes more sense to me.
19:47 particle do any languages care
19:49 whiteknight it's breaking rakudo right now
19:49 cotto_work I don't see anything in pdd03 that specifies either way
19:49 whiteknight but it seems like a relatively small breakage
19:49 moritz it might be easy to fix on the rakudo side
19:49 moritz even easier if the line numbers in the backtrace weren't so far off
19:49 whiteknight moritz: What does Rakudo want here? Our docs don't specify either way
19:49 cotto_work It's important to ask why it's breaking now, especially if that test was passing at some point.
19:49 whiteknight cotto_work: we used to have a special case in the code marked as a "hack"
19:50 whiteknight if 0 named params are expected, arg checking was always off. If >0 were expected, we checked
19:50 moritz whiteknight: I'm not sure if it wants anything, or if it's an accidnetal feature usage
19:50 bluescreen left #parrot
19:50 whiteknight I removed the hack, so the behavior is consistent. Rakudo was relying on the special case
19:50 moritz for Perl 6 subroutines, rakudo uses its own binder, so it only matters for internal code
19:51 whiteknight so I would prefer this be consistent one way or the other. Either we throw an exception on named arg count mismatch when error checking is enabled, or we don't
19:51 whiteknight if error checking is not enabled, it doesn't matter (which is default)
19:52 particle it matters if assumptions are broken when checking is enabled
19:52 particle do most dynamic languages care about the number of named params?
19:52 particle do any that you know of care?
19:52 cotto_work can you disable named arg mismatch in a branch so we can see how other hlls do?
19:52 particle i think the answer is 'no', but i'm not sure
19:53 whiteknight again, any HLL can remove checking by turning off error checking there
19:53 particle sure, but only at parrot compile time, correct?
19:53 whiteknight so when error checking is explicitly turned on, do we count named arguments and throw exception if we pass too many?
19:53 whiteknight particle: no, it's a runtime flag
19:53 particle ah, excellent.
19:53 plobsing whiteknight: does that mean toggling a flag at every function call?
19:53 particle then my vote is to disable it
19:53 whiteknight this is an extremely esoteric thing, which is why I have no real opinion on it
19:54 whiteknight plobsing: I think the flag gets set once, but is checked on every function call
19:54 whiteknight it's set on the interpreter, I think. Or maybe on the context and inherited by child contexts
19:55 plobsing so if you have 2 HLLs with different settings for this flag, call-ins to each other, they need to set this flag at every call-in point
19:55 whiteknight ...yes?
19:56 plobsing in the general case, the language compilers do not know where these call ins are. so, upon sub entry and after every sub call, you need to reset the flag (because it may have been set to the wrong thing)
19:57 plobsing that seems annoying to say the least
19:59 cotto_work whiteknight: where's the flag checked?
20:00 [hercynium] joined #parrot
20:01 cotto_work whiteknight: found it
20:01 allison joined #parrot
20:04 whiteknight I plobsing: I wasn't intending to get into a bigger description about the way Parrot handles error-checking in HLLs, but you do raise a good point about it being...annoying
20:04 fbrito cotto_work: 430 lines later, I think I am done with the 'todo' param task :)
20:04 whiteknight plobsing: I think the real solution here is for HLLs to provide their own subclasses of CallContext, so those flags exist on the context and are created automatically when we jump back and forth
20:05 cotto_work fbrito: nice!  Send a pull request.
20:05 Kapace morning..
20:05 Kapace cotto_work: btw, look at sha256.pir, theres a comment that says "# This is the start of the implemation and sha224 is not done yet!"
20:05 Kapace maybe it was never completed?
20:05 cotto_work Kapace: that explains it
20:05 bluescreen joined #parrot
20:06 hercynium left #parrot
20:06 [hercynium] is now known as hercynium
20:06 fbrito cotto_work: ok, just a moment. make test still running
20:06 cotto_work though that's the only place in the file where "224" is mentioned
20:06 cotto_work fbrito++
20:08 nwellnhof which OSes use parrot's portable IO code?
20:08 whiteknight probably none
20:08 [hercynium] joined #parrot
20:09 whiteknight but nobody has the guts to pull it out
20:09 plobsing nwellnhof: break it and see who screams >;)
20:09 nwellnhof it's broken right now, but i wouldn't puul it out.
20:09 fbrito cotto_work: hm... failing tests :/. wait a moment
20:09 cotto_work fbrito: take your time
20:10 Kapace fbrito: thats going to help a lot with the SHA tests :)
20:11 cotto_work pmichaud: based on your experience, what'd be the least annoying way to do todo in PIR Test::More?
20:13 hercynium left #parrot
20:13 [hercynium] is now known as hercynium
20:17 rfw joined #parrot
20:20 bluescreen left #parrot
20:21 darbelo nwellnhof: If it's portable you can probably make your system use it. Just disable the 'non-portable' implementation.
20:22 dalek parrot: 7cb039f | Whiteknight++ | src/call/args.c:
20:22 dalek parrot: move all named parameter count-checking error code into a separate function. We don't special case functions with 0 named paramters any more.
20:22 dalek parrot: review: https://github.com/parrot/parrot/commit/7cb039f81d
20:23 nwellnhof darbelo: yes, i did that
20:23 whiteknight nwellnhof: rip it out
20:23 whiteknight you have my blessing, for whatever that's worth
20:24 moritz if a call to routine failed, does the name of the routine appear in the stack trace?
20:25 moritz I get
20:25 moritz too many named arguments: 1 passed, 0 used
20:25 moritz current instr.: 'perl6;RoleHOW;attributes' pc 6491 (src/builtins/Mu.pir:97)
20:25 moritz but the method attributes doesn't call any other methods
20:25 whiteknight moritz: I think it should
20:25 whiteknight attributes is the place where it failed
20:26 whiteknight so it's probably failing in the .param declararts of attributes
20:26 whiteknight can you nopaste the PIR of it?
20:26 moritz how can a declaration fail?
20:26 moritz .sub 'attributes' :method .param pmc role $P0 = getattribute self, '$!attributes' .return ($P0)
20:27 moritz .end
20:27 dalek parrot/gci_todotest: f4a5cf4 | fbrito++ | / (2 files):
20:27 dalek parrot/gci_todotest: [t] Add 'todo' param to 'ok' and 'nok'
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/f4a5cf47d6
20:27 dalek parrot/gci_todotest: d4a226e | fbrito++ | / (2 files):
20:27 dalek parrot/gci_todotest: [t] Add 'todo' param to 'is'
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/d4a226e2c6
20:27 dalek parrot/gci_todotest: 4507477 | fbrito++ | runtime/parrot/library/Test/More.pir:
20:27 dalek parrot/gci_todotest: [t] Add 'todo' param to 'isnt'
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/4507477c22
20:27 dalek parrot/gci_todotest: 1794a96 | fbrito++ | runtime/parrot/library/Test/More.pir:
20:27 dalek parrot/gci_todotest: [t] Add 'todo' param to 'is_deeply, like, isa_ok, lives_ok'
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/1794a962a1
20:27 dalek parrot/gci_todotest: 26cee27 | fbrito++ | runtime/parrot/library/Test/More.pir:
20:27 dalek parrot/gci_todotest: [t] Add 'todo' param to 'dies_ok, throws_like'
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/26cee27ef3
20:27 dalek parrot/gci_todotest: 3e0f7fe | fbrito++ | t/library/test_more.t:
20:27 cotto_work fbrito: reviewing now
20:27 dalek parrot/gci_todotest: [t] Add more tests to new 'todo' param
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/3e0f7fedf6
20:27 dalek parrot/gci_todotest: 49afc0b | fbrito++ | t/library/test_more.t:
20:27 dalek parrot/gci_todotest: [t] Add even more tests to new 'todo' param
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/49afc0b30e
20:27 dalek parrot/gci_todotest: f327a22 | fbrito++ | runtime/parrot/library/Test/More.pir:
20:27 dalek parrot/gci_todotest: [t] Fix 'todo' param in throws_like
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/f327a22108
20:27 dalek parrot/gci_todotest: a4f1685 | fbrito++ | t/library/test_more.t:
20:27 whiteknight moritz: add a slurpy hash PMC .param to that function
20:27 dalek parrot/gci_todotest: [t] Add tests to 'todo' param on isa_ok and throws_like
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/a4f1685456
20:27 dalek parrot/gci_todotest: 55ac514 | fbrito++ | runtime/parrot/library/Test/More.pir:
20:27 dalek parrot/gci_todotest: [t] Fix 'todo' param in dies_ok and lives_ok
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/55ac514d6f
20:27 dalek parrot/gci_todotest: c011221 | fbrito++ | t/library/test_more.t:
20:27 dalek parrot/gci_todotest: [t] Add tests to 'todo' param on dies_ok and lives_ok
20:27 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/c011221be5
20:27 dalek parrot/gci_todotest: 3a47d19 | cotto++ | / (2 files):
20:28 whiteknight moritz: and your problem should go away
20:28 dalek parrot/gci_todotest: Merge branch 'gci_todotest' of https://github.com/fernandobrito/parrot into fernandobrito-gci_todotest
20:28 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/3a47d1987c
20:28 whiteknight DAMNIT FBRITO!
20:28 whiteknight TOO MANY COMMITS!
20:28 whiteknight :)
20:29 whiteknight too many commits is a good problem to have :)
20:29 cotto_work especially for the sucker reviewing
20:29 whiteknight well said, sucker
20:29 whiteknight :)
20:29 fbrito whiteknight: wait a second. I think make test is failing :P
20:30 whiteknight so, same as usual then
20:30 fbrito it says that t/pmc/context.t planned 19 tests but ran 20. funny
20:30 Kapace lol
20:31 fbrito I am waiting make test results on master
20:31 Kapace fbrito: sounds like a test is being todo'd and ok'd, maybe?
20:32 fbrito no way... now it is working
20:32 rfw karma fbrito
20:32 aloha fbrito has karma of 103.
20:32 moritz karma rfw
20:32 aloha rfw has karma of 44.
20:32 fbrito I haven't change anything and now it works. -.- I hate when this happens
20:32 rfw i should've made more spurious commits
20:33 cotto_work fbrito: I see the test passing what looks like an extra todo
20:34 cotto_work that's quite strange.  There's no todo in the test
20:34 Coke I chuckle every time I see the discussion about /removing/ IMCC. (yes, I think it's a good idea. It's still hilarious and tragic)
20:35 cotto_work It'll be hilarious when it dies in a fire.  I'll bring marshmallows.
20:36 whiteknight Coke: why so funny?
20:36 moritz be careful, its smokes might be poisonous
20:36 Coke because we went through a lot of work to /integrate/ it. it was someone's standalone project that parrot ate.
20:38 cotto_work I'm glad you've been around long enough to appreciate the irony.  I didn't know that.
20:38 whiteknight Coke: yeah, that is kind of funny and tragic
20:38 whiteknight Unfortunately, the needs of the younger Parrot project were far different from the needs of Parrot c. 2011
20:39 whiteknight at the time, I'm sure IMCC was a godsend
20:40 chromatic At the time, the original author said "Wait, this was a proof of concept!"
20:40 cotto_work chromatic: who was that?
20:41 Coke Melvin
20:41 Coke IIRC. (he might still have his name in copyright entries in the imcc)
20:42 cotto_work his name is in several places
20:42 dukeleto what is the deal with that. I always wondered.
20:43 Coke He wrote it and parrot ate it.
20:43 Coke he didn't write it to be included in parrot.
20:43 whiteknight that explains why it frequently doesn't place nicely with Parrot
20:44 whiteknight it's not a bad system, all thigns considered. It's far different now from what it was
20:44 fbrito cotto_work: I found what was the failing test problem
20:45 cotto_work fbrito: do tell
20:45 darbelo Gremlins!
20:45 fbrito cotto_work: line 125 of context.t was: ok($P0, 'FOO', 'Got CallContext.current_hll')
20:45 cotto_work That looked suspicious
20:46 cotto_work Why does it get weird with your code though?
20:47 fbrito it looks that this line was never called before my code :o
20:48 cotto_work you're right
20:49 cotto_work the plot thickens
20:49 fbrito adding a new optional parameter to ok() made this line be called as a TODO, and that's why it was complaining about the plan
20:49 fbrito but why it was not called before my code?
20:50 dalek parrot: a480a06 | nwellnhof++ | / (5 files):
20:50 dalek parrot: [io] Make portable IO code almost compile again
20:50 dalek parrot:
20:50 dalek parrot: ops2c hangs during build with the portable IO code, might be related
20:50 dalek parrot: to mmap.
20:50 dalek parrot: review: https://github.com/parrot/parrot/commit/a480a0690f
20:50 cotto_work that's surprising.  I wouldn't expect an unnamed argument to get stuffed into a named slow
20:50 cotto_work *slot
20:51 Coke (doesn't play nicely) - it's older than most of the rest of parrot at this point. ;)
20:51 fbrito and, and it was called, but the plan didn't notice it. running prove on that file (on master) will show a "ok" after "ok 19"
20:53 fbrito (forget about that, haha)
20:54 fbrito (every test does that)
20:55 fbrito I have just pushed a fix to it (last commit on https://github.com/parrot/parrot/pull/102)
20:57 dalek parrot/gci_todotest: 98b5638 | fbrito++ | t/pmc/context.t:
20:57 dalek parrot/gci_todotest: [t] Fix test in context.t
20:57 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/98b563830b
20:57 dalek parrot/gci_todotest: 5e04e7f | cotto++ | t/pmc/context.t:
20:57 dalek parrot/gci_todotest: Merge branch 'gci_todotest' of https://github.com/fernandobrito/parrot into gci_todotest
20:57 dalek parrot/gci_todotest: review: https://github.com/parrot/parrot/commit/5e04e7f7d0
20:57 dalek parrot: 5e04e7f | cotto++ | t/pmc/context.t:
20:57 dalek parrot: Merge branch 'gci_todotest' of https://github.com/fernandobrito/parrot into gci_todotest
20:57 dalek parrot: review: https://github.com/parrot/parrot/commit/5e04e7f7d0
20:58 dalek parrot: 0771755 | cotto++ | / (3 files):
20:58 dalek parrot: Merge branch 'gci_todotest'
20:58 dalek parrot: review: https://github.com/parrot/parrot/commit/0771755417
20:58 fbrito I wonder how useful my atomic commits on test files are. picking one of them and leaving the others away will break the plan very badly
20:58 cotto_work fbrito: I like them.  Review is easier.
21:00 cotto_work it would have been a little better to put the tests and feature additions together, but that's not a big deal
21:01 cotto_work don't forget to mark your task
21:01 fbrito I did that on the first 2 or 3 commits, but than I got really bored and started to do all the features first and write all the tests later, hahaha. sorry for that
21:02 perlite_ joined #parrot
21:03 whiteknight getting bored is the only reason I do anything
21:03 fbrito cotto_work: done :)
21:03 cotto_work done
21:04 cotto_work fbrito: I can't imagine those tests getting boring.  I only fell asleep twice while reviewing them.
21:06 perlite left #parrot
21:06 perlite_ is now known as perlite
21:06 cotto_work msg kristaba Is your gci code all ready to be reviewed?
21:06 aloha OK. I'll deliver the message.
21:08 fbrito nice... now I am 7 points from getting away of the top 10 :P
21:11 fbrito ok, time to fix that sha256 bug
21:23 kid51 joined #parrot
21:25 nopaste "kid51" at 192.168.1.3 pasted "t/library/test_more.t: new, extensive failures" (36 lines) at http://nopaste.snit.ch/27583
21:26 whiteknight left #parrot
21:27 dalek parrot: b5922fd | mikehh++ | MANIFEST:
21:27 dalek parrot: re-generate MANIFEST
21:27 dalek parrot: review: https://github.com/parrot/parrot/commit/b5922fd71b
21:33 hercynium left #parrot
21:34 cotto_work kid51: did you re-rerun make?
21:34 cotto_work kid51: nm
21:36 cotto_work fbrito: BigNum wasn't the best choice for those tests
21:37 fbrito cotto_work: what should I use? Sorry, but I ran out of creativity :P
21:37 plobsing is it reasonable to assume that, for any given operating system, the assumed encoding is consistent among all OS functionality (command line args, path names, environment variables, etc)?
21:38 cotto_work Something that works on all systems.  Big* depends on an externally library that's not guaranteed to be installed
21:38 fbrito Ah, I see
21:39 dalek parrot: 4523ae7 | nwellnhof++ | t/tools/pbc_disassemble.t:
21:39 dalek parrot: [t] Make t/tools/pbc_disassemble.t pass on Windows
21:39 dalek parrot: review: https://github.com/parrot/parrot/commit/4523ae7ff4
21:39 dalek parrot: 748958d | nwellnhof++ | src/io/buffer.c:
21:39 dalek parrot: [io] Cleanup Parrot_io_read_buffer
21:39 dalek parrot: review: https://github.com/parrot/parrot/commit/748958d5c2
21:39 dalek parrot: f867e30 | nwellnhof++ | / (7 files):
21:39 dalek parrot: [io] Change PIO_READ arguments to raw buffer
21:39 dalek parrot:
21:39 dalek parrot: This avoids creation of a string header in Parrot_io_read_buffer
21:39 dalek parrot: and simplifies the code.
21:39 dalek parrot: review: https://github.com/parrot/parrot/commit/f867e30781
21:39 dalek parrot: a92e441 | nwellnhof++ | / (3 files):
21:39 dalek parrot: [io] Change Parrot_io_read_buffer arguments to raw buffer
21:40 dalek parrot: review: https://github.com/parrot/parrot/commit/a92e441c56
21:40 dalek parrot: 9269865 | nwellnhof++ | / (2 files):
21:40 dalek parrot: [io] Add FileHandle.read_bytes method returning a ByteBuffer
21:40 dalek parrot: review: https://github.com/parrot/parrot/commit/9269865b81
21:40 dalek parrot: d02241d | nwellnhof++ | / (5 files):
21:40 dalek parrot: [io] Don't use STRING ** output arguments
21:40 dalek parrot: review: https://github.com/parrot/parrot/commit/d02241d983
21:42 fbrito cotto_work: wait a second... I will change it to something else
21:42 cotto_work k
21:42 dalek parrot: da5c3e6 | mikehh++ | src/io/portable.c:
21:42 dalek parrot: correct wrong ASSERT_ARGS
21:42 dalek parrot: review: https://github.com/parrot/parrot/commit/da5c3e6e24
21:42 dalek parrot: e7fd781 | mikehh++ | src/io/portable.c:
21:42 dalek parrot: update copyright
21:42 dalek parrot: review: https://github.com/parrot/parrot/commit/e7fd781d89
21:44 rurban_ joined #parrot
21:46 kid51 left #parrot
21:47 rurban left #parrot
21:47 rurban_ is now known as rurban
21:54 fbrito cotto_work: sorry for the delay... had to go out for a while. What do you suggest using in place of BigNum?
21:56 cotto_work any of the core PMCs are fine
21:57 cotto_work Integer, Float, F*A, R*A, etc
21:57 darbelo left #parrot
21:59 allison left #parrot
22:08 cotto_work kid51++ for reporting that
22:10 dalek parrot: de482bf | nwellnhof++ | config/gen/makefiles/root.in:
22:10 dalek parrot: Fix dependencies of PBC_TEST_FILES
22:10 dalek parrot:
22:10 dalek parrot: This makes 'make -j2 test' work from clean build dir and makes sure that
22:10 dalek parrot: the test files are regenerated after a new build.
22:10 dalek parrot: review: https://github.com/parrot/parrot/commit/de482bf797
22:10 gbacon joined #parrot
22:11 fbrito wow, the universe seems to conspire against me
22:11 fbrito cotto_work: finally: https://github.com/fernandobri​to/parrot/commits/gci_todotest
22:14 dalek parrot: 1c472f8 | mikehh++ | src/io/buffer.c:
22:14 dalek parrot: fix to make g++ build, change buf to unsigned char, add cast
22:14 dalek parrot: review: https://github.com/parrot/parrot/commit/1c472f8f93
22:14 plobsing is there a person with the master plan for the strings subsystem? who do I get to sanity-check my ideas for fixing TT #1836 and TT #1898 before implementing?
22:16 lucian joined #parrot
22:17 dalek parrot: 06b014f | cotto++ | t/library/test_more.t:
22:17 dalek parrot: Merge branch 'gci_todotest' of https://github.com/fernandobrito/parrot into fbrito-todo-test-fix
22:17 dalek parrot: review: https://github.com/parrot/parrot/commit/06b014f1db
22:17 dalek parrot: 214f47f | cotto++ | / (15 files):
22:17 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
22:18 dalek parrot: review: https://github.com/parrot/parrot/commit/214f47f5e9
22:19 nwellnhof plobsing: that's on my TODO list
22:20 plobsing nwellnhof: how do you intend to solve it?
22:20 nwellnhof what we need is a function like Parrot_str_to_cstring that accepts an encoding parameter. Then we can create UTF-8 filenames for Linux, UTF-16 for Windows etc.
22:21 plobsing Don't we already have one of those?
22:22 plobsing what is wrong with Parrot_str_new_init ?
22:22 nwellnhof we need zero-terminated strings
22:23 nwellnhof Parrot_str_new_init doesn't convert encodings.
22:23 plobsing but we don't need to convert encodings. we just need to attach the right ones.
22:24 plobsing at least thats the case for TT #1898, where we erroneously attempt to encode as ASCII
22:24 nwellnhof for FileHandle.open we have to convert encodings.
22:24 plobsing true, but then we already *have* a string with an attached encoding. we don't need to create a string then.
22:25 nwellnhof #1898 seems to be related to something different, maybe command line handling.
22:26 plobsing #1898 and #1836 are related in that they represent the 2 approaches (both wrong) that parrot takes to dealing with "operating system encoding" strings
22:26 plobsing (1) pass them throuhg with no processing or sanity checking (2) assume they are the "default" encoding (which is almost always ASCII)
22:26 nwellnhof #1898 fails somewhere in IMCC
22:27 plobsing it isn't just IMCC
22:27 nwellnhof plosing: yes, parrot is completely broken in that regard.
22:27 plobsing create a fakecutable. change the name to something unicode. run the fakecutable. BOOM. not in IMCC this time.
22:30 nwellnhof IMCC is especially bad because it uses C strings in many places.
22:31 plobsing C strings aren't really that much of an issue if you just pass them around and don't make too many assumptions about whats in them.
22:31 plobsing IMCC mostly treats its C strings this way
22:32 plobsing the problems occur when you try to make parrot strings out of them
22:32 nwellnhof but IMCC also uses fopen.
22:33 plobsing not an issue. it gets those names for argv. so long as the OS is self-consistent WRT encodings, everything should be fine.
22:33 nwellnhof this will never work on windows.
22:33 nwellnhof you have to use CreateFileW on windows and pass it a UTF-176 string.
22:34 nwellnhof *UTF-16
22:34 plobsing supporting wchar stuff on windows will take more than that
22:34 nwellnhof forget wchar on windows.
22:34 plobsing I thought wchar was how windows handled unicode
22:35 nwellnhof i mean libc wchar stuff.
22:35 nwellnhof it's best to call the windows API directly.
22:36 nwellnhof the windows c library is only a wrapper around the windows API and is horribly broken in many regards.
22:36 plobsing it matches the rest of the platform well in that regard
22:39 plobsing OK, I'm not terribly interested in what OS-specific APIs need calling. My specific concern is that we treat OS-originating strings as ASCII. That shows up in many places.
22:39 plobsing unicode filenames, unicode environment variables, etc
22:39 plobsing it has little to do with IMCC specifically
22:39 gcamblin joined #parrot
22:40 nwellnhof all the places that use STRINGs should be easy to fix
22:40 plobsing but they aren't yet. and it sucks. really really bad.
22:41 plobsing so what I am proposing is this: create a new encoding alias (similar to "default") called "platform" which is defined to be "whatever your OS encodes things in"
22:41 dalek parrot: 779719a | bacek++ | src/call/args.c:
22:41 dalek parrot: Fix arg guard. named_used_list can be NULL
22:41 dalek parrot: review: https://github.com/parrot/parrot/commit/779719a008
22:42 plobsing switch over all places that convert OS-originating strings to use this encoding
22:43 nwellnhof what is there besides filename, command line arguments and environment variables?
22:44 plobsing I don't know. user names, etc?
22:45 Coke left #parrot
22:45 bacek aloha, humans
22:47 cotto_work aloha, other human
22:49 Kapace fbrito: hows the sha thing going?
22:51 Coke joined #parrot
22:53 dalek pir: 4cc7018 | bacek++ | src/PIR/Compiler.pm:
22:53 dalek pir: Add *%adverbs
22:53 dalek pir: review: https://github.com/parrot/pir/commit/4cc70189b8
22:54 bacek When and who changed handling of named args in parrot??? Previously we allow "named args without named param". Now it's throwing exception
22:55 Tene I thought I saw a ticket filed asking for a pull from githob for a patch that touched that code
22:55 Tene "rofflwaffls wants someone to pull from rofflwaffls:call_args_refactor:"
22:55 Tene did that get pulled?
22:55 rfw yes
22:58 cotto_work bacek: that happened earlier today
23:05 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#2126) fulltest) at 2_11_0-820-g214f47f - Ubuntu 10.10 i386 (g++-4.5)
23:06 bacek cotto_work, whiteknight's commit?
23:06 lucian left #parrot
23:07 fbrito kapace: I gave up for a moment
23:07 Matt221 joined #parrot
23:10 Matt221 For the task regarding refactoring fill_params, are multiple smaller static functions accepted (since performance is key)? Refactoring a larger chunk will result in many arguments being passed to the function since everything is so tightly coupled.
23:15 dalek pir: aaab154 | bacek++ | t/pbc/keys.txt:
23:15 dalek pir: Fix Keys test. Auto-vivification of nested aggregates was removed.
23:15 dalek pir: review: https://github.com/parrot/pir/commit/aaab154b78
23:17 cotto_work bacek: yes
23:17 bacek cotto_work, it's kind of... weird. And bad. We probably broke all of our HLLs.
23:18 cotto_work Matt221: smaller functions are nice if possible.  The whole refactoring of fill_params is pretty experimental.
23:18 bacek At least PIRATE was broken
23:18 cotto_work I thought he was going to put it in a branch.
23:18 bacek What is current replacement for "fixed_8" encoding?
23:20 plobsing "binary"?
23:22 bacek plobsing, hm. Is it default encoding in IMCC?
23:23 plobsing pretty sure IMCC uses whatever the interp says is the "default" encoding
23:23 plobsing it can be set by the user
23:26 Matt221 cotto_work: Thanks, wasn't sure what you mean by checking for performance issues.
23:26 Matt221 Making a call to a C function shouldn't be expensive
23:27 Matt221 *meant
23:28 bacek plobsing, "invalid encoding 'default'". Looks like it's not available from PIR.
23:29 cotto_work Matt221: no, but that code is called very frequently and has potential to slow down parrot meaningfully.
23:29 dalek pir: 7efeeef | bacek++ | src/PIR/Actions.pm:
23:29 dalek pir: Use "binary" instead of "fixed_8" encoding as default. plobsing++
23:29 dalek pir: review: https://github.com/parrot/pir/commit/7efeeeffe1
23:36 dalek pir: 2376574 | bacek++ | t/post/ (7 files):
23:36 dalek pir: Fix test to use binary encoding
23:36 dalek pir: review: https://github.com/parrot/pir/commit/23765740dc
23:36 bacek cotto_work, PIRATE now again in pretty good shape. Feel free to finish it :)
23:38 cotto_work bacek: that sounds like a fun thing to do this weekend.  What needs doing?
23:39 plobsing bacek: to get the default encoding by name, you need to pass STRINGNULL
23:40 plobsing see src/string/encoding.c:Parr​ot_find_encoding_by_string
23:41 bacek plobsing, thanks, I'll try it (later)
23:42 bacek cotto_work, no idea. I almost forgot about todo list for pirate...
23:42 bacek May be on RTM there is something
23:43 bacek cotto_work, "Implement ".const 'Sub'" handling. Looks like it's last one before self-hosting stage."
23:44 bacek Implement handling of additional CLI params. E.g. "--debug"
23:44 bacek this two
23:44 cotto_work what would --debug do?
23:44 cotto_work can you update the PirateTodo page?
23:45 cotto_work nm.  that's my page
23:45 cotto_work I'll update it
23:45 cotto_work bacek: what about using PIRATE
23:46 cotto_work s POST in nqp-rx?
23:46 bacek cotto_work, "$P0 = compreg 'PIRATE'", etc.
23:46 bacek ah... this one will require more effort.
23:46 cotto_work yeah
23:46 bacek 1. update parrot's POST to PIRATE's version.
23:47 bacek 2. Change nqp-rx to use PIRATE.
23:47 bacek 3. Bring tree-optimizations into parrot.
23:47 cotto_work Why is that third?
23:47 bacek because we do need it for PIRATE.
23:48 bacek Check src/PIR/Compiler swap_gtge
23:48 bacek # Swapping "gt" and "ge" with "lt" and "le"
23:48 bacek # There is no gt_i_i_ic, so we have to swap it with lt
23:48 bacek etc, etc, etc
23:49 dalek ohm-eta-wink-kzd: fc8ca8c | plobsing++ | / (4 files):
23:49 dalek ohm-eta-wink-kzd: combine Parser library into OMeta base library
23:49 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/fc8ca8c7f4
23:49 dalek ohm-eta-wink-kzd: b1bd60e | plobsing++ | src/ometa-winxed.pir:
23:49 dalek ohm-eta-wink-kzd: rebootstrap
23:49 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/b1bd60e516
23:49 dalek ohm-eta-wink-kzd: 3bbd5dd | plobsing++ | / (5 files):
23:49 dalek ohm-eta-wink-kzd: move libraries to more Winxed-friendly filenames
23:49 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/3bbd5ddd7f
23:49 dalek ohm-eta-wink-kzd: 23d8ea2 | plobsing++ | src/ometac.winxed:
23:49 dalek ohm-eta-wink-kzd: add compiler program
23:49 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/23d8ea297c
23:50 cotto_work bacek: what needs fixing in tree-optimizations?  I recall that there was something blocking it from being merged, but I don't recall what.
23:51 bacek cotto_work, I don't remember either...
23:51 bacek I think we can just put it into ext/
23:52 bacek Preferably overtaking github's repo from tcurtis to parrot
23:52 dalek tracwiki: v4 | cotto++ | PirateTodo
23:52 dalek tracwiki: http://trac.parrot.org/parrot/wiki/P​irateTodo?version=4&amp;action=diff
23:52 cotto_work I thought the plan was to make it an internal component.  It'll need to be if we distribute PIRATE as part of Parrot.
23:54 bacek cotto_work, hm. It can be bundled with parrot. In same terms as nqp-rx. We just need some working snapshot of tree-optimizations. Development can be independent.
23:55 kid51 joined #parrot
23:55 bacek And tree-optimizations is much more powerful to be used with PIRATE only :)
23:55 cotto_work of course
23:56 fperrad left #parrot
23:57 bacek anyway, time for some shopping
23:57 bacek c u

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

Parrot | source cross referenced