Parrot 2.11.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Keep up with GCI
Set by moderator on 5 January 2011.
cotto_work Kapace: what's md5sum_c.pir? 00:00
Kapace cotto_work: thats the md5sum example using the class interface
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/
ok, git has rename/move tool? 00:02
cotto_work git rename
er, git mv
Kapace yeah, ok
cotto_work: should I put the sha256 stuff in the same pull, or different? 00:03
cotto_work Kapace: whatever's easier
I haven't merged yet
Coke . 00:04
Kapace ok
cotto_work do you want a gci task for sha256?
Kapace yes please :) 00:06
Got to make sure I stay in the top 10, don't want anything crazy to happen in the last few days
whiteknight really loves the github postmortem reports 00:08
Most online services don't really offer that kind of introspective analysis. It's fascinating 00:09
cotto_work Kapace: need to update the test plan 00:10
everything else looks good
new task created
Kapace ok thanks
cotto_work: alright fixed the plan. 1 Hour for SHA task :| 00:14
(even worse "1 Hours")
melange--
cotto_work marked complete, time fixed 00:17
melange-- 00:19
Kapace: don't forget to run the codingstds tests 00:21
Kapace ok, Ill try to remember. (I should setup an alias for git commit to automatically ask if I ran it) 00:23
00:23 plobsing joined
Kapace dpaste.com/295061/ 00:41
00:43 gbacon left
dalek p-rx/smoke: 1ec882f | dukeleto++ | build/Makefile.in:
Getting closer to smoking nqp-rx
 00:51
p-rx/smoke: 27f1ff4 | dukeleto++ | build/Makefile.in:
Looks like we need a harness
00:53 Yuki`N joined
cotto_work Kapace: can you fix it? 00:59
00:59 dmalcolm left
cotto_work and add a test 00:59
kapace_ I doubt I can fix it, don't know enough about encryption :|
cotto_work I'm sure the algorithm is well-documented 01:00
kapace_ I can open a ticket :P
cotto_work that's purely optional though
ok
kapace_: it'd be helpful to write a couple test cases with externally-verified sha256 sums 01:06
dalek p-rx/smoke: 3fc8dc8 | dukeleto++ | / (3 files):
We can now make Smolder shoot 500-smoke
kapace_ cotto_work, what counts as externally verifiable? a link to a online hash calculator? a file and my sha256sum output? 01:07
dalek rrot/kill_packfile_new_dummy: 5a85e76 | Whiteknight++ | src/ (2 files):
remove PackFile_new_dummy. A few test failures pop up
 01:09
cotto_work any of those 01:11
Kapace ok cool 01:12
cotto_work also, "verified" (i.e. you didn't use the pir code to verify itself) not "verifiable"
msg dukeleto your thoughts are welcome on trac.parrot.org/parrot/wiki/AutomatedHLLTesting 01:25
aloha OK. I'll deliver the message.
01:30 Kristaba left
dalek tracwiki: v1 | cotto++ | AutomatedHLLTesting 01:36
tracwiki: initial free-form braindump
tracwiki: trac.parrot.org/parrot/wiki/Automat...ction=diff
TT #1936 created by DavidCzech++: SHA256 sums don't seem to match with external tools.
TT #1936: trac.parrot.org/parrot/ticket/1936
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
cotto_work whiteknight: that's a special test case you added. 01:59
It's not often I want to clean up testing code to make it easier to understand.
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
time to decommute
rfw argh goddammit 02:11
is it okay if i use some double pointer naughtiness 02:12
reduced fill_params by 117 lines 02:30
yay
www.google-melange.com/gci/task/sho...9413127098 02:36
made fulltest, unrelated things failed
one test in class.t relating to inspect, no tests executed in packfileopmap.t
whiteknight: are you there? 02:37
whiteknight sorta 02:38
rfw does sorta mean yes you can review? :(
whiteknight sorta 02:39
link?
rfw www.google-melange.com/gci/task/sho...9413127098
whiteknight rfw: it builds and passes all tests? 02:42
rfw whiteknight: it fails unrelated tests
whiteknight does master fail tests too?
rfw yes
whiteknight oh, okay then
cotto ~~
dalek rrot/gci_fill_params_reduce: 18d905a | rfw++ | src/call/args.c:
Moved some parameter assignment routines into their own functions.
 02:43
cotto we need to make sure and do some benchmarking on that too
I'm pretty sure any competent compiler will inline static functions, but better safe than sorry
whiteknight it's pulled into a branch
so we can test it there
we may want to mark them all PARROT_HOT too 02:44
make Andy happy
rfw: pulled, approved the task
rfw thanks
whiteknight I don't have time for any more review though, time for bed 02:45
goodnight
rfw night whiteknight
02:45 whiteknight left 02:54 NotFound left 02:55 NotFound joined, PacoLinux left 02:56 PacoLinux joined 03:00 kid51 joined 03:10 gbacon joined
kid51 Yuki`N: ping 03:17
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.
Yuki`N kid pong 03:22
kid51, 03:23
03:24 Yuki`N left
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 trac.parrot.org/parrot/ticket/1199) 03:24
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 trac.parrot.org/parrot/ticket/1199) 03:25
aloha OK. I'll deliver the message.
04:10 kid51 left 04:17 contingencyplan left 04:32 gbacon left
dalek m-eta-wink-kzd: 08af6a3 | plobsing++ | README.pod:
add README
 04:40
05:35 particle left
Kapace cotto: looks like I'm going to have to add a new file for sha testing, i think... 05:41
gedit--
05:43 rurban_ joined
cotto Kapace, yup 05:44
Kapace cotto: is there docs for that, or can you guide me through the process? 05:45
05:46 rurban left, rurban_ is now known as rurban
Kapace this is what my test file is looking like: dpaste.com/295109/ 05:47
is there an easier way to make those is() calls into todo()s?
cotto Kapace, you mean other than s/is/todo/ ? 05:48
no. That's a weakness of PIR-based tests currently.
Kapace don't i need to make a comparision first?
oh ok.. well it will just have to be done once the bug is fixed 05:49
(which I'll like to investigate some more, probably after GCI) 05:50
bacek_at_work cotto, idea for GCI? Implement something like C<is(foo, bar, "Description", :todo("NYI"))> in parrot's Test::More 05:51
cotto bacek_at_work, that's not a bad idea 05:52
bacek_at_work "medium" size project
cotto sounds about right 05:53
bacek_at_work got for it :)
Kapace so, how do I add my new test to the makefiles etc? 05:56
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.
Kapace awesome, then add to MANIFEST and commit? er make codetest :) 06:00
cotto and distrotest 06:01
you can just run perl tools/dev/mk_manifest_and_skip.pl
we're lazy like that
Kapace cool
make distrotest -> no rule to make target 'distrotest' ? 06:03
cotto distro_tests 06:05
If you're on Ubuntu (and possibly others), you can use tab completion for makefile targets. 06:06
Kapace oh, cool
dalek m-eta-wink-kzd: 7ea81e1 | plobsing++ | / (35 files):
move /src to /bootstrap
 06:11
m-eta-wink-kzd: 02b43c3 | plobsing++ | / (2 files):
add toplevel makefile for end user use (hide uglyness in bootstrap makefile)
m-eta-wink-kzd: 7345ecc | plobsing++ | src/ometa-winxed (2 files):
add bootstrap files
m-eta-wink-kzd: c892f81 | plobsing++ | Makefile:
add rules to actually build default targets
cotto bacek_at_work, are you sure that'd be a medium task? There's a lot of code that'll need changing. 06:15
bacek_at_work cotto, I don't think so. You can confirm with chromatic about complexity. 06:17
cotto bacek_at_work, how does socghop.appspot.com/gci/task/show/g...9438019014 look? 06:18
bacek_at_work cotto, remove "todo" from list of functions to change :) 06:19
cotto I thought I caught that one
bacek_at_work hese functions are ok, nok, is, is_deeply, like, isa_ok, isnt, todo,
cotto fix't 06:20
06:21 aantn joined
bacek_at_work I would add "Add tests for new behaviour" explicitly into task 06:21
cotto also a good idea 06:22
dukeleto ~~ 06:25
cotto hio dukeleto
dalek rrot: add4e13 | bacek++ | t/pmc/packfileopmap.t:
Don't test loading od dynops after coretest
 06:27
dukeleto cotto: i just read your hll testing wiki page 06:28
cotto thoughts?
flames?
pasta?
dukeleto cotto: it is good. is that list in order of importance, or random order ? 06:30
cotto dukeleto, random
bacek_at_work, doesn't that test need some jumping around to make sure the same number of tests are run in both cases?
dalek m-eta-wink-kzd: 5f40c83 | plobsing++ | README.pod:
license formatting
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
Rakudo is important, but that can be the second hll
dukeleto cotto: yep, rakudo is second in line. nqp-rx is the canary in the coal mine 06:32
cotto: plumage is probably next, or possibly second, since that allows testing many HLLs 06:33
cotto also a good idea
dukeleto cotto: can you add some info about which Configure.pl flags you would like to see tested on the wiki page? 06:40
cotto: and perhaps something about how plumage can be used? 06:41
cotto sure 06:42
06:43 aantn left 06:45 aantn joined 06:50 particle joined
dalek tracwiki: v2 | dukeleto++ | AutomatedHLLTesting 06:51
tracwiki: trac.parrot.org/parrot/wiki/Automat...ction=diff
tracwiki: v3 | cotto++ | AutomatedHLLTesting
tracwiki: trac.parrot.org/parrot/wiki/Automat...ction=diff
cotto upgrade time 06:57
06:57 cotto left 07:04 cotto joined
Kapace what did you upgrade? 07:07
cotto ubuntu to 10.01 07:08
er 10.10
now to copy everything to an ssd 07:09
07:11 fbrito joined, cotto left 07:16 aantn left 07:23 aantn joined 07:32 chromatic left 07:43 fperrad joined
rfw Kapace: are you there 08:06
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
fbrito me too, ehhe 08:18
rfw fbrito: you wouldn't happen to know how to fuzz test ffmpeg would you :x
fbrito rfw: coincidently I have my last uni tests on 10th (gci deadline) 08:19
rfw oh
good luck!
alsoi accidentally read that as "last unit tests"
fbrito ahhaha
rfw: on my English class book we had "unit tests" and even a "mock tests" :D 08:21
rfw lol 08:22
08:28 rurban left
dalek umage: 887882c | fperrad++ | plumage/metadata/nqp-rx.json:
[NQP-rx] add target clean & realclean
 08:46
fbrito I have just started working on this task: www.google-melange.com/gci/task/sho...9438019014 09:03
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
moritz it might be 'todo'=>'reason' 09:05
the :todo(...) thing works in Perl 6 09:06
fbrito moritz: yeah, I have just found this syntax on the PIR book
thank you :) 09:07
moritz accepts claim 09:11
09:13 aantn left, aantn joined
aantn how can I get a class's type number in PIR? 09:18
I'm trying to test PMCProxy
09:36 ppant joined
fbrito aantn: class type number? can you show me some piece of code? 09:51
aantn aloha: coverage 09:52
oops 09:53
fbrito: look at init_pmc in tapir2.ro.vutbr.cz/cover/cover-resu...y-pmc.html
frodwith: class type numbers are used internally to look up classes
fbrito: I think they map up to the PMC's location in an array of types 09:54
fbrito: which allows for quick lookup and instantation
fbrito hm, interesting 09:55
sorry, but I am also a GCI student... can't help much :( 09:57
I am going to bed. good night 09:58
10:00 cotto joined 10:01 rfw left 10:06 fbrito left
cotto just realized that he typed 10:13
"man watch" into a terminal
tadzik like a Night Watch 10:20
11:29 mj41 left 11:40 redicaps joined 11:47 contingencyplan joined 11:56 nwellnhof joined, ppant left 11:57 nwellnhof left 12:00 mj41 joined 12:13 GodFather joined
Coke We tried very hard a while back to remove all non-C references to the type number. 12:35
12:37 fperrad left 12:42 bluescreen joined
jnthn Heh, I tried to kill the type number altogether way back... :) 12:57
moritz and a few days ago you tried to write a cache based on them :-) 12:58
... which didn't work with parametric types, it seems
jnthn moritz: Aye 12:59
moritz: Well, was an interesting experiment none the less.
Too bad it didn't work out.
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
jnthn In fact, that was what inspired me to try it. 13:00
Oh, I know why parametric types maybe broke... 13:01
cotto jnthn, ping (since I'm up anyway) 13:03
13:06 mikehh joined
jnthn o/ cotto 13:06
Just got back from Christmas/New Year's break today :)
13:06 rurban joined
cotto wb 13:06
jnthn thx :)
cotto jnthn, how prototypey is nom? The code is unusual.
jnthn Varies :) 13:07
"unusual"? :)
cotto either that or I haven't looked at much object metamodel code
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:08
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:09
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
I look forward to seeing what you have in store.
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?
The best person to write docs is someone who doen't know what's going on, so I'm highly qualified.
jnthn The S-Table and REPR data structures are, the KnowHOW bootstrap probably mostly is too.
P6opaque REPR - feel free to document but it needs to become more complicated soonish. 13:12
cotto hints?
jnthn At the moment it's missing the ability to handle native type (or native struct) attributes. 13:13
It also does a memory allocation too many.
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
(e.g. a doc on why everything is designed the way it is)
moritz that is the most useful piece of documentation that is missing most often
cotto sorry. Are your upcoming changes related to hints? I noticed that all the hint-related code was stubbed out.
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)
cotto Yes. I really miss the inline POD.
jnthn cotto: Yes, more bits on hints will be coming at some point.
Though it's not top of the hit list.
But it'll happen, for sure. 13:17
cotto What are they?
jnthn For attributes, a way to do the lookup just as an index rather than a name lookup.
For methods, similar, but the lookup is into a v-table
cotto ok. that's pretty simple.
jnthn Thing is that for it to work, one needs to have the meta-objects at compile time. 13:18
So you can ask it what index things will be at and compile that into the code.
That's where things get a bit trickier. :)
cotto Is it fine if I start documenting with inline POD or do you prefer a different format? 13:21
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?
jnthn Well, I don't really have a problem with a C-style comment before the function explaining what it does. ;-) 13:23
But I'm not sure if that counts as a documentation format. ;)
cotto good enough 13:24
jnthn Well, it's mostly if you want to extract the stuff. I figure that's what POD offers.
There's already plenty of readers and tools for munging it.
cotto that's the advantage I see in POD
but I don't care that much
jnthn Anyway, I don't feel too strongly on the issue.
cotto ok 13:26
jnthn (That is, if POD gets used, I certainly won't complain.)
cotto tries attempt #3 to get to sleep 13:28
pmichaud good morning, #parrot 13:35
moritz good morning pmichaud 13:36
jnthn pmichaud! :) 13:38
13:44 rurban_ joined 13:47 rurban left, rurban_ is now known as rurban
dalek nxed: r729 | NotFound++ | trunk/winxedst1.winxed:
compile time evaluation of substr with constant arguments
 13:47
13:51 GodFather left 13:58 whiteknight joined 14:09 plobsing left
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
seems to happen on amd64 as well, but will test there later
I think it might be due to ASSERT not happening with optimized builds. 14:11
whiteknight okay, so either we have a faulty assert that is too restrictive, or we have really terrible input conditioning 14:19
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
t/src/embed.t - TODO passed: 3
whiteknight: src/thread.c:1397: failed assertion '!interpreter_array' with no --optimize 14:47
14:47 aantn left
mikehh whiteknight: which it won't fail with an optimized build 14:47
whiteknight stupid interpreter_array 14:50
that variable is the primary reason why I wanted to rip threads out
aloha coverage? 14:51
aloha whiteknight: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
nopaste "mikehh" at 192.168.1.3 pasted "t/src/embed.t - TODO passed: 3 with optimized build" (26 lines) at nopaste.snit.ch/27580 14:53
14:54 plobsing joined
mikehh maybe I should open a ticket on that 14:56
whiteknight yes, please
15:03 JimmyZ joined 15:06 Patterner left 15:07 Psyche^ joined, Psyche^ is now known as Patterner, particle1 joined 15:11 particle left
dalek TT #1937 created by mikehh++: t/src/embed.t - TODO passed: 3 in optimized builds 15:21
TT #1937: trac.parrot.org/parrot/ticket/1937
15:21 particle1 is now known as particle 15:26 plobsing left 15:35 fperrad joined 15:42 Andy joined
dalek nxed: r730 | NotFound++ | trunk/winxedst1.winxed:
compile time evaluation of indexof with constant arguments
 15:48
15:55 fbrito joined, plobsing joined
dalek umage: e2f0543 | fperrad++ | plumage/metadata/rakudo.json:
[rakudo] add target: clean & realclean
 15:59
16:01 JimmyZ left
dalek rrot: 2025a9f | Whiteknight++ | docs/embed.pod:
restore the old embed.pod, which contains details from dukeleto and will be necessary in the transition.
 16:07
rrot: 8bffd5b | Whiteknight++ | docs/embed_new.pod:
add in a new version of the embed docs, for the new API that doesn't conflict with dukeleto's changes
rrot: fa9eece | Whiteknight++ | docs/embed.pod:
add a note to the old documentation about the phase-out and a link to the new docs
pmichaud is plumage intended to be an "end-user" tool, or one just for developers?
whiteknight pmichaud: an end-user tool
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?
isn't that like someone saying that Parrot end-users should download and install Parrot HEAD?
whiteknight pmichaud: It has a file of metadata that tells it what to install. The metadata for Rakudo may need to be updated/improved
pmichaud yes, I was reading the metadata when I noticed that it installed Rakudo HEAD
that seems wrong. 16:09
whiteknight I don't know if plumage supports tags. It should if it doesn't
pmichaud also, even the Rakudo team doesn't recommend downloading tags from Rakudo github
we recommend downloading rakudo star tarballs
whiteknight okay
if plumage doesn't yet support that, it should
I still consider plumage to be immature and in development
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
whiteknight I think dukeleto's plan for continuous integration involves plumage as a key component
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
pmichaud: yes. For the common case of parrot devs, not using plumage is probably better
but for the automated case, we want a tool there to manage metadata and test against many projects
pmichaud fair enough 16:12
the automated case probably needs to be testing multiple versions
whiteknight is it worthwhile to include nqp tests in parrot's ext/ too, so we can include those in the test harness automatically?
pmichaud for example, it probably makes sense to test Parrot against the latest rakudo release as well as rakudo head
whiteknight or is the snapshot sufficiently different from nqp-rx HEAD?
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
pmichaud for one, hll devs really want parrot devs to test against the language build process
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?"
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
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
whiteknight okay 16:15
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
my thinking is that the more we can automate, the more likely people are to actually run the tests
but maybe we need something larger than just a transparent change to the test harness for that
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.
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
pmichaud as long as releases are coming from the integration branch, sure.
whiteknight the integration branch will be used for releases, and must always be tested to the nth degree before merging into it
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
well, it could be
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
whiteknight right. I see that being the purview of the release manager, and maybe a few other individuals
pmichaud but more generally, let's suppose a committer named "jpatch" creates a development branch, does a lot of work, and merges to master
when and who do those changes make it to integration? 16:21
does jpatch do the merge to integration?
whiteknight no
pmichaud okay, that's good 16:22
does the release manager do it?
whiteknight I mean, maybe. We would want somebody that we trust not to be hasty to do it
I think the release manager is a good candidate, since his name is on the release
pmichaud how long before the release does the manager do it?
I mean, obviously waiting until the day-of-release isn't going to work out.
whiteknight good question. There are obviously lots of ideas to work out before we try to move to a system like this 16:23
if we decide to move to it
pmichaud right
I could very easily see it being staged at two levels (more)
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
plobsing I'd propose that the release manager creates the branch immediately before the call for extensive testing goes out.
whiteknight if people branch from broken commits, they are going to have broken branches, etc
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.
whiteknight wash, rinse, repeat
pmichaud plobsing: it seems to put the onus on non-parrot folks to test parrot
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
that is a request targetted at parrot devs
pmichaud but based on what whiteknight said earlier, an integration branch would be made *after* testing 16:26
16:18 <whiteknight> the integration branch will be used for releases, and must always be tested to the nth degree before merging into it
whiteknight no, I think the integration branch would be continuous. It would exist side-by-side with master for all time
pmichaud so the integration branch comes *after* testing, not before.
whiteknight changes from master would be tested and then merged into integration
by a responsible person
pmichaud right. and a "call for extensive testing" somewhat goes against that premise. 16:27
unless the call for extensive testing is testing against master
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:28
pmichaud plobsing: I care that parrot releases don't break my hlls in ways they aren't supposed to. 16:29
16:29 allison joined 16:31 particle left
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:31
16:32 particle joined
whiteknight right. that's sort of backwards 16:32
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
pmichaud viewed in light of what I just wrote, I think I tend to agree. 16:33
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
but we want to make sure the common cases are all well covered before we put something "live"
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.
whiteknight right
pmichaud saying "we can't test all permutations, so let's test none of them" is completely wrong IMO
plobsing off-topic: is there a library function for mkstemp() within parrot?
pmichaud saying "one of the permutations takes forever, so let's test none of them" is also completely wrong IMO
whiteknight right, no. Nobody is saying that
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
whiteknight pmichaud: well, whoever says that is wrong
pmichaud (comprehensive testing) I'll be glad for that, but let's not make the perfect the enemy of the good (more) 16:37
I'd like to see *some* regular testing taking place without it having to be comprehensive yet
let's focus on getting *some* regular testing going first, and *then* work on comprehensive testing 16:38
a simple cron job that tests parrot master against nqp-rx master will catch 95% of the issues, I suspect
a cron job that tests parrot master against rakudo master will get another 3%
(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:39
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?
whiteknight possibly 16:42
pmichaud that's one of the main reasons that feather exists
whiteknight I would hate to see a huge Rakudo build for instance be creating problems for other things that run there
pmichaud we do rakudo builds on feather all the time w/o any problems
that's where the evalbot runs
whiteknight oh, I wasn't aware
I'm not really sure how beefy a box feather is
pmichaud it's beefy enough to do repeated rakudo builds :-) 16:43
like, every 30 minutes or so
whiteknight what's the story with those builds? Can we hijack existing builds to do smoke testing against parrot HEAD?
pmichaud no, because those builds are explicitly against PARROT_REVISION
whiteknight okay. 16:44
pmichaud those builds are primarily for testing rakudo changes, not parrot ones.
whiteknight how often does PARROT_REVISION bump
?
pmichaud 1. right after a parrot release
2. whenever rakudo needs a new Parrot feature "immediately" 16:45
3. whenever someone tests rakudo against Parrot head and decides to bump
(end)
particle beefy doesn't matter. everything on feather is niced.
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.
pmichaud feather also has the advantage of having multiple admins available to help
particle name your favorite distro and i'll create a vm and give you admin rights to set up what you want
pmichaud (and is frequently watched by many parrot/perl6 folks)
particle feather is a great place for this. 16:47
but if you also want another platform for testing, let me know and i'll help.
pmichaud in an ideal world, PARROT_REVISION would bump only on parrot releases
particle i have about 6GB ram (of 20) free at any given time, and 8 cores 16:48
so i have plenty to spare.
whiteknight particle: We may just take you up on that offer
particle does PARROT_REVISION work with git tags?
pmichaud particle: yes.
(it has to)
particle great. 16:49
pmichaud pmichaud@orange:~/rakudo$ cat build/PARROT_REVISION
RELEASE_2_11_0-478-gd69dbbc
particle well, it could work with only commit hashes, but i can't see it being hard to support any refspec
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
avoiding PARROT_REVISION altogether. PARROT_REVISION only comes into play when using --gen-parrot
16:56 redicaps left, chromatic joined 17:04 hercynium joined, cotto left 17:06 theory joined 17:21 JimmyZ joined
cotto_work ~~ 17:21
whiteknight good morning, cotto_work 17:23
17:24 JimmyZ left
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
looks like good things will come of it, if not the good things originally intended
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.
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:41
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:43
dukeleto ~~ 17:44
particle: howdy 17:45
particle heya duke
17:45 plobsing left
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
17:48 darbelo joined
particle let me know if you need access to any resources i can provide 17:51
dukeleto particle: ok, will do. 17:52
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
(by me, at least)
fbrito: any new code added should be covered. How much longer do you think it'll take than you initially thought? 18:05
dalek TT #1038 closed by cotto++: Convert Digest::MD5 to object-based implementation 18:06
TT #1038: trac.parrot.org/parrot/ticket/1038
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
that's good to hear
I don't want any other students getting harder tasks than expected. 18:08
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:09
moritz is there already a parrot ticket for the newest rakudo spectest failures 18:12
?
if not, I could open one
cotto_work fbrito: foo(1 :named('x'), 2 :named('y')) also works
moritz: sure.
fbrito hm, interesting
dukeleto fbrito++ # doing hard stuff 18:14
cotto_work I was thinking of nqp-rx in what I mentioned in gci task
dukeleto: do you think that should be a difficult task? 18:15
dukeleto cotto_work: huh? 18:16
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"?
cotto_work is it rightly marked "medium"?
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?
moritz pmichaud: failures in t/spec/S14-roles/crony.t, t/spec/S14-roles/mixin.rakudo and t/spec/integration/advent2009-day18.rakudo
dalek rrot: f4d04a8 | cotto++ | / (5 files):
Merge branch 'kapace/objectify_md5' of github.com/kapace/parrot into kapace-kapace/objectify_md5
rrot: 70238f6 | cotto++ | / (7 files):
Merge branch 'kapace-kapace/objectify_md5'
dukeleto cotto_work: i haven't seen the task you are talking about
dukeleto just woke up
cotto_work dukeleto: ok
jnthn moritz: Is day18 role-y too?
moritz jnthn: yep 18:19
jnthn Darn.
pmichaud what does todo() do in PIR's Test::More now?
moritz jnthn: it segfaults.
jnthn moritz: :(
pmichaud moritz: have you been able to bisect it yet? 18:20
jnthn moritz: Got a st?
moritz pmichaud: not a chance. It appeared immediately after the :main thing
pmichaud oh, so we haven't had a fully-functioning spectest since after :main?
moritz not afaict
pmichaud :( 18:21
nopaste "moritz" at 192.168.1.3 pasted "day18 bt" (23 lines) at nopaste.snit.ch/27581
jnthn If it's roles, it's at least in an area I can try and hung down.
wtf. :|
That's...REALLY not a good place to explode. 18:22
moritz wonders where nopaste has its fantasy IPs from
cotto_work pmichaud: the gci task is to make ok(1, "msg here", "todo" => "broken") work.
moritz it's not even my IP in this local subnet
jnthn moritz: huh? I can connect to 192.168.1.3 just fine
oh, wait...
;)
fbrito :P
jnthn moritz: That st is...less helpful than hoped. :( 18:23
pmichaud cotto_work: ah.
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
it's a pain to maintain
cotto_work pmichaud: the idea is that it's less annoying than using todo()
pmichaud instead, we have a todo(number, reason) call that marks the next <number> tests as todo, supplying <reason>
I think that Test::PIR has a todo(test, reason), which is really annoyintg. 18:24
*annoying.
looks like Test::PIR currently has todo(test, test description, reason). Yes, that's annoying. 18:25
but we found that the :test adverb was also annoying
especially when needing to skip a large number of tests
s/skip/todo/
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
(or at least Rakudo's approach)
jnthn On that stack trace, there seems to have been commits to Parrot recently related to init handling. 18:28
:init that is
fbrito so... is my task still valid? :D
pmichaud there have
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
jnthn ah
cotto_work fbrito: yes
18:29 allison left
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
fbrito: but if you do what the task says, your task will be approved
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 :-)
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 :-)
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
pmichaud in the past when I've done parrot bisecting I've done it from the parrot repo and using git-bisect 18:32
that might be more robust in this case, then.
moritz with this script you run 'git bisect' from parrot-as-subdir-of-rakudo
pmichaud so, 'git bisect tools/parrot-bisect.pl testscript' ? 18:33
er 18:34
moritz git bisect perl ../tools/parrot-bisect.pl testscript
pmichaud 'git bitsect start <bad> <good>' followed by 'git bisect run perl..... ' right 18:35
moritz right
18:35 nwellnhof joined
moritz note that currently it configures parrot with ccache 18:35
pmichaud that's good -- I typically use ccache
looks like run 'git bisect' from rakudo root, though. 18:36
otherwise it can't find ./perl6
moritz there's a chdir() or two involved 18:37
pmichaud ah, I see.
$rakudo_dir gets set 18:38
okay
dalek TT #1938 created by moritz++: rakudo on parrot RELEASE_2_11_0-777-gef82f5c segfaults on role related ... 18:39
TT #1938: trac.parrot.org/parrot/ticket/1938
pmichaud I don't get a segfault on day18 -- I get "too many arguments" 18:40
18:40 plobsing joined
pmichaud er, "too many named arguments" 18:40
that sounds like a parameter checking error 18:41
iwbni bisect-parrot.pl could check the results of 'make localtest', so that multiple tests could be tested. 18:42
whiteknight moritz: is it possible to get a dump of the PIR generated by those failing Rakudo tests? 18:44
pmichaud pmichaud@orange:~/rakudo$ ./perl6 t/spec/S14-roles/crony.t 18:45
1..4
too many named arguments: 1 passed, 0 used in <anon> at line 1 in main program body at line 1
pmichaud@orange:~/rakudo$
I fear we have the case again where two rakudo breakages in master conflict with each other 18:46
i.e.: 18:47
merge implicit :main (breaks rakudo)
merge sub argument checking (breaks rakudo)
fix implicit :main (fixes rakudo partially)
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
pmichaud yes, I know argument checking was being enabled somewhere (more)
whiteknight if I can see the PIR from that test, I can probably pinpoint it quickly
pmichaud uploading now
whiteknight awesome
plobsing is it possible to augment git bisect to programatically cherry-pick out branch merges? 18:49
pmichaud gist.github.com/769909
dukeleto plobsing: what do you mean? 18:50
nwellnhof when was the sub argument checking change merged? is it this ticket trac.parrot.org/parrot/ticket/1103?
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
branch merges being good candidates
whiteknight according to the network view, that branch wasn't merged 18:52
unless those changes were wrongfully included in a different branch which was merged 18:53
pmichaud lunchtime here -- bbl
dukeleto plobsing: you could "git revert" merges, is that what you mean? 18:59
whiteknight moritz: would it be possible for you to get a GDB stack trace with a debug Parrot? 19:00
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 19:01 shortcircuit joined
whiteknight (I know that's a bit of a pain in the ass) 19:01
plobsing dukeleto: yes, the algorithm can be driven manually. I'm wondering if can be automated. 19:02
cotto_work whiteknight: I can repro here 19:05
where do you want the stack trace from?
probably Parrot_ex_throw_from_c_args 19:06
nopaste "cotto_work" at 192.168.1.3 pasted "backtrace from rakudo failure in crony.t" (16 lines) at nopaste.snit.ch/27582 19:07
moritz whiteknight: how do I build a parrot with debug symbols? 19:09
cotto_work moritz: should be there by default
plobsing might not be there if you --optimize
moritz can I both --optimize and have debug symbols? 19:10
for gcc those are not mutually exclusive
plobsing --ccflags="-g" or --ccflags="-ggdb" 19:11
those make sure to include the debug symbols
moritz tries
whiteknight Isn't error checking on the number of parameters turned off by default? 19:15
github.com/parrot/parrot/commit/a3...b43d5c5851 19:20
I knew that backtrace looked familiar 19:21
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:22
jnthn Also, an error that talks about number of named arguments is awful from a user perspective. 19:24
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
the first case silently passed, the second case threw an exception
We need to make that consistent
moritz why not just list all named arguments that weren't expected?
whiteknight moritz: that doesn't change the fact that any exception thrown here will break your test
so that raises the question: Do we want an exception where named parameters are passed but not used? I suspect not 19:26
moritz in a low level language like PIR I expect it to be an error 19:27
in a higher level language you can always install a slurpy named hash if you want to surpress it
it's harder the other way round
whiteknight moritz: ok, so then the parrot behavior stays as-is, and Rakudo needs to fix it's test 19:28
which is not a result I'm inclined to support
moritz whiteknight: which test is that, btw? 19:29
jnthn I'm confused. Rakudo uses its own binder...
So would never be in that code, unless it's happening somewhere in the guts.
whiteknight crony.t
that's the backtrace cotto gave me from crony.t
jnthn I suspect that somewhere in the PIR implementing roles, something triggers this check/error. 19:30
We could do with a PIR-level backtrace to tell us where.
moritz jnthn: I was just about to say, could be a PIR routine
jnthn But I guess it segfaults before producing one somehow?
whiteknight I don't know what's the deal with the segfaulting test. That is a different problem 19:31
I don't have a backtrace suitable to debug that one yet
moritz recompiles rakudo without custom bactrace printer
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
I don't think this detail is important enough either way
error checking is off by default, which means that behavior is rarely used anyway 19:35
19:40 whiteknight left
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:40
19:41 whiteknight joined, Yuki`N joined
cotto_work plobsing: that's handy 19:41
whiteknight cotto_work: what's your opinion on "number of named arguments" errors? 19:43
I'll be happy to keep or ditch them at this point. I could care less
cotto_work I thought we didn't care about extra named arguments. 19:45
whiteknight i certainly don't care about them
cotto_work checks the pdds
whiteknight ok
I don't think we have any tests for it either way 19:46
cotto_work If it's a choice, ignoring them makes more sense to me. 19:47
particle do any languages care
whiteknight it's breaking rakudo right now 19:49
cotto_work I don't see anything in pdd03 that specifies either way
whiteknight but it seems like a relatively small breakage
moritz it might be easy to fix on the rakudo side
even easier if the line numbers in the backtrace weren't so far off
whiteknight moritz: What does Rakudo want here? Our docs don't specify either way
cotto_work It's important to ask why it's breaking now, especially if that test was passing at some point.
whiteknight cotto_work: we used to have a special case in the code marked as a "hack"
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
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
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
if error checking is not enabled, it doesn't matter (which is default)
particle it matters if assumptions are broken when checking is enabled 19:52
do most dynamic languages care about the number of named params?
do any that you know of care?
cotto_work can you disable named arg mismatch in a branch so we can see how other hlls do?
particle i think the answer is 'no', but i'm not sure
whiteknight again, any HLL can remove checking by turning off error checking there 19:53
particle sure, but only at parrot compile time, correct?
whiteknight so when error checking is explicitly turned on, do we count named arguments and throw exception if we pass too many?
particle: no, it's a runtime flag
particle ah, excellent.
plobsing whiteknight: does that mean toggling a flag at every function call?
particle then my vote is to disable it
whiteknight this is an extremely esoteric thing, which is why I have no real opinion on it
plobsing: I think the flag gets set once, but is checked on every function call 19:54
it's set on the interpreter, I think. Or maybe on the context and inherited by child contexts
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?
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:56
that seems annoying to say the least 19:57
cotto_work whiteknight: where's the flag checked? 19:59
20:00 [hercynium] joined
cotto_work whiteknight: found it 20:01
20:01 allison joined
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 :)
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
cotto_work fbrito: nice! Send a pull request. 20:05
Kapace morning..
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!"
maybe it was never completed?
cotto_work Kapace: that explains it
20:05 bluescreen joined 20:06 hercynium left, [hercynium] is now known as hercynium
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
fbrito++
nwellnhof which OSes use parrot's portable IO code? 20:08
whiteknight probably none
20:08 [hercynium] joined
whiteknight but nobody has the guts to pull it out 20:09
plobsing nwellnhof: break it and see who screams >;)
nwellnhof it's broken right now, but i wouldn't puul it out.
fbrito cotto_work: hm... failing tests :/. wait a moment
cotto_work fbrito: take your time
Kapace fbrito: thats going to help a lot with the SHA tests :) 20:10
cotto_work pmichaud: based on your experience, what'd be the least annoying way to do todo in PIR Test::More? 20:11
20:13 hercynium left, [hercynium] is now known as hercynium 20:17 rfw joined 20:20 bluescreen left
darbelo nwellnhof: If it's portable you can probably make your system use it. Just disable the 'non-portable' implementation. 20:21
dalek rrot: 7cb039f | Whiteknight++ | src/call/args.c:
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
nwellnhof darbelo: yes, i did that 20:23
whiteknight nwellnhof: rip it out
you have my blessing, for whatever that's worth
moritz if a call to routine failed, does the name of the routine appear in the stack trace? 20:24
I get 20:25
too many named arguments: 1 passed, 0 used
current instr.: 'perl6;RoleHOW;attributes' pc 6491 (src/builtins/Mu.pir:97)
but the method attributes doesn't call any other methods
whiteknight moritz: I think it should
attributes is the place where it failed
so it's probably failing in the .param declararts of attributes 20:26
can you nopaste the PIR of it?
moritz how can a declaration fail?
.sub 'attributes' :method .param pmc role $P0 = getattribute self, '$!attributes' .return ($P0)
.end 20:27
dalek rrot/gci_todotest: f4a5cf4 | fbrito++ | / (2 files):
[t] Add 'todo' param to 'ok' and 'nok'
rrot/gci_todotest: d4a226e | fbrito++ | / (2 files):
[t] Add 'todo' param to 'is'
rrot/gci_todotest: 4507477 | fbrito++ | runtime/parrot/library/Test/More.pir:
[t] Add 'todo' param to 'isnt'
rrot/gci_todotest: 1794a96 | fbrito++ | runtime/parrot/library/Test/More.pir:
[t] Add 'todo' param to 'is_deeply, like, isa_ok, lives_ok'
rrot/gci_todotest: 26cee27 | fbrito++ | runtime/parrot/library/Test/More.pir:
[t] Add 'todo' param to 'dies_ok, throws_like'
rrot/gci_todotest: 3e0f7fe | fbrito++ | t/library/test_more.t:
[t] Add more tests to new 'todo' param
cotto_work fbrito: reviewing now
rrot/gci_todotest: 49afc0b | fbrito++ | t/library/test_more.t:
[t] Add even more tests to new 'todo' param
rrot/gci_todotest: f327a22 | fbrito++ | runtime/parrot/library/Test/More.pir:
[t] Fix 'todo' param in throws_like
rrot/gci_todotest: a4f1685 | fbrito++ | t/library/test_more.t:
[t] Add tests to 'todo' param on isa_ok and throws_like
whiteknight moritz: add a slurpy hash PMC .param to that function
rrot/gci_todotest: 55ac514 | fbrito++ | runtime/parrot/library/Test/More.pir:
[t] Fix 'todo' param in dies_ok and lives_ok
rrot/gci_todotest: c011221 | fbrito++ | t/library/test_more.t:
[t] Add tests to 'todo' param on dies_ok and lives_ok
rrot/gci_todotest: 3a47d19 | cotto++ | / (2 files):
Merge branch 'gci_todotest' of github.com/fernandobrito/parrot into fernandobrito-gci_todotest
whiteknight moritz: and your problem should go away 20:28
whiteknight DAMNIT FBRITO!
TOO MANY COMMITS!
:)
too many commits is a good problem to have :) 20:29
cotto_work especially for the sucker reviewing
whiteknight well said, sucker
:)
fbrito whiteknight: wait a second. I think make test is failing :P
whiteknight so, same as usual then 20:30
fbrito it says that t/pmc/context.t planned 19 tests but ran 20. funny
Kapace lol
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?
fbrito no way... now it is working 20:32
rfw karma fbrito
aloha fbrito has karma of 103.
moritz karma rfw
aloha rfw has karma of 44.
fbrito I haven't change anything and now it works. -.- I hate when this happens
rfw i should've made more spurious commits
cotto_work fbrito: I see the test passing what looks like an extra todo 20:33
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)
cotto_work It'll be hilarious when it dies in a fire. I'll bring marshmallows. 20:35
whiteknight Coke: why so funny? 20:36
moritz be careful, its smokes might be poisonous
Coke because we went through a lot of work to /integrate/ it. it was someone's standalone project that parrot ate.
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
Unfortunately, the needs of the younger Parrot project were far different from the needs of Parrot c. 2011
at the time, I'm sure IMCC was a godsend 20:39
chromatic At the time, the original author said "Wait, this was a proof of concept!" 20:40
cotto_work chromatic: who was that?
Coke Melvin 20:41
IIRC. (he might still have his name in copyright entries in the imcc)
cotto_work his name is in several places 20:42
dukeleto what is the deal with that. I always wondered.
Coke He wrote it and parrot ate it. 20:43
he didn't write it to be included in parrot.
whiteknight that explains why it frequently doesn't place nicely with Parrot
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
cotto_work fbrito: do tell 20:45
darbelo Gremlins!
fbrito cotto_work: line 125 of context.t was: ok($P0, 'FOO', 'Got CallContext.current_hll')
cotto_work That looked suspicious
Why does it get weird with your code though? 20:46
fbrito it looks that this line was never called before my code :o 20:47
cotto_work you're right 20:48
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
but why it was not called before my code?
dalek rrot: a480a06 | nwellnhof++ | / (5 files):
[io] Make portable IO code almost compile again

ops2c hangs during build with the portable IO code, might be related to mmap.		 20:50
cotto_work that's surprising. I wouldn't expect an unnamed argument to get stuffed into a named slow
*slot
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"
(forget about that, haha) 20:53
(every test does that) 20:54
I have just pushed a fix to it (last commit on github.com/parrot/parrot/pull/102) 20:55
dalek rrot/gci_todotest: 98b5638 | fbrito++ | t/pmc/context.t:
[t] Fix test in context.t
 20:57
rrot/gci_todotest: 5e04e7f | cotto++ | t/pmc/context.t:
Merge branch 'gci_todotest' of github.com/fernandobrito/parrot into gci_todotest
rrot: 5e04e7f | cotto++ | t/pmc/context.t:
Merge branch 'gci_todotest' of github.com/fernandobrito/parrot into gci_todotest
rrot: 0771755 | cotto++ | / (3 files):
Merge branch 'gci_todotest'
 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
cotto_work fbrito: I like them. Review is easier.
it would have been a little better to put the tests and feature additions together, but that's not a big deal 21:00
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
whiteknight getting bored is the only reason I do anything 21:03
fbrito cotto_work: done :)
cotto_work done
fbrito: I can't imagine those tests getting boring. I only fell asleep twice while reviewing them. 21:04
21:06 perlite left, perlite_ is now known as perlite
cotto_work msg kristaba Is your gci code all ready to be reviewed? 21:06
aloha OK. I'll deliver the message.
fbrito nice... now I am 7 points from getting away of the top 10 :P 21:08
ok, time to fix that sha256 bug 21:11
21:23 kid51 joined
nopaste "kid51" at 192.168.1.3 pasted "t/library/test_more.t: new, extensive failures" (36 lines) at nopaste.snit.ch/27583 21:25
21:26 whiteknight left
dalek rrot: b5922fd | mikehh++ | MANIFEST:
re-generate MANIFEST
 21:27
21:33 hercynium left
cotto_work kid51: did you re-rerun make? 21:34
kid51: nm
fbrito: BigNum wasn't the best choice for those tests 21:36
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)?
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
dalek rrot: 4523ae7 | nwellnhof++ | t/tools/pbc_disassemble.t:
[t] Make t/tools/pbc_disassemble.t pass on Windows
 21:39
rrot: 748958d | nwellnhof++ | src/io/buffer.c:
[io] Cleanup Parrot_io_read_buffer
rrot: f867e30 | nwellnhof++ | / (7 files):
[io] Change PIO_READ arguments to raw buffer

This avoids creation of a string header in Parrot_io_read_buffer and simplifies the code.
rrot: a92e441 | nwellnhof++ | / (3 files):
[io] Change Parrot_io_read_buffer arguments to raw buffer
rrot: 9269865 | nwellnhof++ | / (2 files):
[io] Add FileHandle.read_bytes method returning a ByteBuffer
rrot: d02241d | nwellnhof++ | / (5 files):
[io] Don't use STRING ** output arguments
fbrito cotto_work: wait a second... I will change it to something else 21:42
cotto_work k
dalek rrot: da5c3e6 | mikehh++ | src/io/portable.c:
correct wrong ASSERT_ARGS
rrot: e7fd781 | mikehh++ | src/io/portable.c:
update copyright
21:44 rurban_ joined 21:46 kid51 left 21:47 rurban left, rurban_ is now known as rurban
fbrito cotto_work: sorry for the delay... had to go out for a while. What do you suggest using in place of BigNum? 21:54
cotto_work any of the core PMCs are fine 21:56
Integer, Float, F*A, R*A, etc 21:57
21:57 darbelo left 21:59 allison left
cotto_work kid51++ for reporting that 22:08
dalek rrot: de482bf | nwellnhof++ | config/gen/makefiles/root.in:
Fix dependencies of PBC_TEST_FILES

This makes 'make -j2 test' work from clean build dir and makes sure that the test files are regenerated after a new build.		 22:10
22:10 gbacon joined
fbrito wow, the universe seems to conspire against me 22:11
cotto_work: finally: github.com/fernandobrito/parrot/co...i_todotest
dalek rrot: 1c472f8 | mikehh++ | src/io/buffer.c:
fix to make g++ build, change buf to unsigned char, add cast
 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
dalek rrot: 06b014f | cotto++ | t/library/test_more.t:
Merge branch 'gci_todotest' of github.com/fernandobrito/parrot into fbrito-todo-test-fix
 22:17
rrot: 214f47f | cotto++ | / (15 files):
Merge branch 'master' of github.com:parrot/parrot
nwellnhof plobsing: that's on my TODO list 22:19
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.
plobsing Don't we already have one of those? 22:21
what is wrong with Parrot_str_new_init ? 22:22
nwellnhof we need zero-terminated strings
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.
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.
plobsing true, but then we already *have* a string with an attached encoding. we don't need to create a string then.
nwellnhof #1898 seems to be related to something different, maybe command line handling. 22:25
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
(1) pass them throuhg with no processing or sanity checking (2) assume they are the "default" encoding (which is almost always ASCII)
nwellnhof #1898 fails somewhere in IMCC
plobsing it isn't just IMCC 22:27
nwellnhof plosing: yes, parrot is completely broken in that regard.
plobsing create a fakecutable. change the name to something unicode. run the fakecutable. BOOM. not in IMCC this time.
nwellnhof IMCC is especially bad because it uses C strings in many places. 22:30
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
IMCC mostly treats its C strings this way
the problems occur when you try to make parrot strings out of them 22:32
nwellnhof but IMCC also uses fopen.
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.
you have to use CreateFileW on windows and pass it a UTF-176 string.
*UTF-16 22:34
plobsing supporting wchar stuff on windows will take more than that
nwellnhof forget wchar on windows.
plobsing I thought wchar was how windows handled unicode
nwellnhof i mean libc wchar stuff. 22:35
it's best to call the windows API directly.
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
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
unicode filenames, unicode environment variables, etc
it has little to do with IMCC specifically
22:39 gcamblin joined
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.
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 rrot: 779719a | bacek++ | src/call/args.c:
Fix arg guard. named_used_list can be NULL
plobsing switch over all places that convert OS-originating strings to use this encoding 22:42
nwellnhof what is there besides filename, command line arguments and environment variables? 22:43
plobsing I don't know. user names, etc? 22:44
22:45 Coke left
bacek aloha, humans 22:45
cotto_work aloha, other human 22:47
Kapace fbrito: hows the sha thing going? 22:49
22:51 Coke joined
dalek r: 4cc7018 | bacek++ | src/PIR/Compiler.pm:
Add *%adverbs
 22:53
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:54
Tene I thought I saw a ticket filed asking for a pull from githob for a patch that touched that code 22:55
"rofflwaffls wants someone to pull from rofflwaffls:call_args_refactor:"
did that get pulled?
rfw yes
cotto_work bacek: that happened earlier today 22:58
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:05
bacek cotto_work, whiteknight's commit? 23:06
23:06 lucian left
fbrito kapace: I gave up for a moment 23:07
23:07 Matt221 joined
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:10
dalek r: aaab154 | bacek++ | t/pbc/keys.txt:
Fix Keys test. Auto-vivification of nested aggregates was removed.
 23:15
cotto_work bacek: yes 23:17
bacek cotto_work, it's kind of... weird. And bad. We probably broke all of our HLLs.
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
cotto_work I thought he was going to put it in a branch.
bacek What is current replacement for "fixed_8" encoding?
plobsing "binary"? 23:20
bacek plobsing, hm. Is it default encoding in IMCC? 23:22
plobsing pretty sure IMCC uses whatever the interp says is the "default" encoding 23:23
it can be set by the user
Matt221 cotto_work: Thanks, wasn't sure what you mean by checking for performance issues. 23:26
Making a call to a C function shouldn't be expensive
*meant 23:27
bacek plobsing, "invalid encoding 'default'". Looks like it's not available from PIR. 23:28
cotto_work Matt221: no, but that code is called very frequently and has potential to slow down parrot meaningfully. 23:29
dalek r: 7efeeef | bacek++ | src/PIR/Actions.pm:
Use "binary" instead of "fixed_8" encoding as default. plobsing++
r: 2376574 | bacek++ | t/post/ (7 files):
Fix test to use binary encoding
 23:36
bacek cotto_work, PIRATE now again in pretty good shape. Feel free to finish it :)
cotto_work bacek: that sounds like a fun thing to do this weekend. What needs doing? 23:38
plobsing bacek: to get the default encoding by name, you need to pass STRINGNULL 23:39
see src/string/encoding.c:Parrot_find_encoding_by_string 23:40
bacek plobsing, thanks, I'll try it (later) 23:41
cotto_work, no idea. I almost forgot about todo list for pirate... 23:42
May be on RTM there is something
cotto_work, "Implement ".const 'Sub'" handling. Looks like it's last one before self-hosting stage." 23:43
Implement handling of additional CLI params. E.g. "--debug" 23:44
this two
cotto_work what would --debug do?
can you update the PirateTodo page?
nm. that's my page 23:45
I'll update it
bacek: what about using PIRATE
s POST in nqp-rx? 23:46
bacek cotto_work, "$P0 = compreg 'PIRATE'", etc.
ah... this one will require more effort.
cotto_work yeah
bacek 1. update parrot's POST to PIRATE's version.
2. Change nqp-rx to use PIRATE. 23:47
3. Bring tree-optimizations into parrot.
cotto_work Why is that third?
bacek because we do need it for PIRATE.
Check src/PIR/Compiler swap_gtge 23:48
# Swapping "gt" and "ge" with "lt" and "le"
# There is no gt_i_i_ic, so we have to swap it with lt
etc, etc, etc
dalek m-eta-wink-kzd: fc8ca8c | plobsing++ | / (4 files):
combine Parser library into OMeta base library
 23:49
m-eta-wink-kzd: b1bd60e | plobsing++ | src/ometa-winxed.pir:
rebootstrap
m-eta-wink-kzd: 3bbd5dd | plobsing++ | / (5 files):
move libraries to more Winxed-friendly filenames
m-eta-wink-kzd: 23d8ea2 | plobsing++ | src/ometac.winxed:
add compiler program
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:50
bacek cotto_work, I don't remember either... 23:51
I think we can just put it into ext/
Preferably overtaking github's repo from tcurtis to parrot 23:52
dalek tracwiki: v4 | cotto++ | PirateTodo
tracwiki: trac.parrot.org/parrot/wiki/PirateT...ction=diff
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.
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:54
23:55 kid51 joined
bacek And tree-optimizations is much more powerful to be used with PIRATE only :) 23:55
cotto_work of course
23:56 fperrad left
bacek anyway, time for some shopping 23:57
c u

Powered by Cro and the Raku® Programming Language.

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

Thank you!