Camelia, the Perl 6 bug

IRC log for #parrot, 2008-10-20

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:09 AndyA joined #parrot
00:20 Whiteknight what file contains the NCI function prototype definitions?
00:22 TonyC joined #parrot
00:32 gmansi joined #parrot
00:40 chromatic config/gen/call_list/*.in
00:54 Theory joined #parrot
01:16 tetragon joined #parrot
01:23 TonyC joined #parrot
01:33 tetragon joined #parrot
01:39 dmknopp left #parrot
02:09 tetragon joined #parrot
03:08 dalek r32040 | chromatic++ | trunk:
03:08 dalek : [src] Replaced all return CONST_STRING(...) instances with return
03:08 dalek : string_from_literal(...) instances, as the latter allows safe caller
03:08 dalek : modification of the returned string, and the former does not.
03:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32040
03:10 bacek_ joined #parrot
03:10 bacek_ 10058 root      25   0  930m 823m 3576 R  100 41.0   2:57.78 check_state.pl
03:10 bacek_ 1 gig of memory for check_state...
03:10 bacek_ EWRONGWINDOW
03:18 cotto Ohio?
03:18 purl hmmm... Ohio is just stupid and inbred. or the cesspool state or the state whose roads go ga-bump ga-bump ga-bump ga-bump or FOUR DEAD or tin soldiers and Nixon's coming, we're finally on our own
03:19 dalek r32041 | chromatic++ | trunk:
03:19 dalek : [t] Removed non-functional trailing spaces from test files.
03:19 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32041
03:21 Tene purl: Georgia?
03:21 purl Georgia is in the south. next to south carolina. dummies!
03:38 dalek r32042 | chromatic++ | trunk:
03:38 dalek : [IMCC] Added a mutex to static global used in IMCC to make unique identifiers
03:38 dalek : for EVAL_nn labels.  See RT #40010, filed by Matt Diephouse.
03:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32042
03:59 dalek r32043 | chromatic++ | trunk:
03:59 dalek : [ops] Restored debug_print op to the land of the living, or at least
03:59 dalek : non-disabled, non-crashy ops.  Also fixed a segfault.  This closes RT #42379,
03:59 dalek : though I don't guarantee it's *useful* for the debugger yet.
03:59 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32043
04:02 chromatic 43 new + 617 open = 660 tickets.
04:11 dalek r32044 | chromatic++ | trunk:
04:11 dalek : [ops] Removed a comment referring to RT #42371; it doesn't make sense to check
04:11 dalek : that an invocant can do the method passed to callmethodcc invocant, method, as
04:11 dalek : the method gets invoked anyway.
04:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32044
04:48 mj41_ joined #parrot
04:58 dalek r32045 | chromatic++ | trunk:
04:58 dalek : [distro] Added some deprecated functions to DEPRECATED.pod.
04:58 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32045
05:01 dalek r32046 | chromatic++ | trunk:
05:01 dalek : [src] Replaced all uses of readable_name() with VTABLE_get_repr(), which now
05:01 dalek : works on String and Key PMCs.  This helps to unify all uses of readable_name(),
05:01 chromatic 43 + 614 = 657, and there I stop for the night.
05:01 dalek : get_repr(), and key_set_to_string(), as RT #45967 requests.  readable_name()
05:01 dalek : will persist through one deprecation cycle, vanishing in a few days after the
05:02 dalek : Parrot 0.8.0 release.
05:02 dalek : Please note that someone smarter or more diligent to me could improve the test
05:02 dalek : coverage for the error message produced in t/oo/new.t.  Object instantiation
05:02 dalek : from arrays in particular needs testing.
05:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32046
05:27 Bzek joined #parrot
05:39 MariachiElf joined #parrot
05:40 cotto If a patch submitted by someone without a commit bit needs a change, is it better to make that change and commit it or to ask the submitter to make the change?
05:41 moritz depends
05:42 chromatic How big is the change?
05:43 cotto in #59940, changing some tests to check exception types rather than messages
05:43 cotto although a general rule of thumb would be nice too
05:44 chromatic I usually make coding standards or typo fixes as I apply.
05:44 chromatic If it's anything more that a non-committer should reasonably be able to do, feel free to ask for changes.
05:45 cotto works for me
05:46 moritz that's how I do it as well, except that I was too lazy/sleepy to write it like that ;-)
05:46 moritz chromatic++
05:51 TiMBuS joined #parrot
05:55 chromatic http://rt.perl.org/rt3/NoA​uth/parrot/ParrotTODO.html
05:55 chromatic Very useful.
05:58 cotto very long
06:25 uniejo joined #parrot
07:28 Zaba_ joined #parrot
07:34 apeiron joined #parrot
07:34 uniejo joined #parrot
07:37 cosimo joined #parrot
08:00 iblechbot joined #parrot
08:39 Ontolog joined #parrot
08:51 viklund joined #parrot
09:04 tomyan joined #parrot
09:06 tomyan joined #parrot
09:38 apeiron joined #parrot
09:44 kj joined #parrot
10:07 xiaoyafeng joined #parrot
10:57 rdice joined #parrot
10:59 gaz joined #parrot
12:08 DietCoke joined #parrot
12:09 Topic for #parrotis now http://parrot.org/ - clean up those smolders for the release!
12:11 dalek r32047 | coke++ | trunk:
12:11 dalek : [docs] point to new website
12:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32047
12:12 DietCoke tcl still doesn't work with tge latest; /me wonders how code has to change in tcl.
12:29 iblechbot joined #parrot
12:53 grim_fandango joined #parrot
13:10 Lorn joined #parrot
13:13 gryphon joined #parrot
13:27 allison joined #parrot
13:34 AndyA joined #parrot
13:40 Theory joined #parrot
13:43 PacoLinux joined #parrot
14:17 Andy joined #parrot
14:28 Infinoid chromatic's r32041 broke a couple of t/examples/ tests for me.
14:30 particle Infinoid: please post to parrotbug@
14:31 Infinoid I was just going to revert the bits that fail
14:32 particle ok
14:32 Infinoid I was actually hoping someone knew what his "non-functional" rationale was
14:33 Infinoid ...wondering if maybe I need to upgrade something in Test:: or somesuch.
14:33 particle some tests, like those testing readline, require trailing spaces
14:34 particle they're expected in the i/o
14:34 Infinoid the failing tests are ones whose corresponding examples emit trailing spaces.
14:34 particle that makes those "functional"
14:34 Infinoid right.
14:35 particle i haven't run the tests today. i'm recompiling after a change to include [] after empty .namespace
14:37 Infinoid I'll revert the failing tests in a few.  there's a bunch more valid stuff in c's patch that I won't touch
14:37 particle running prove t/examples now...
14:38 Infinoid I get breakage in t/examples/pir.t and t/examples/tutorial.t
14:38 particle hanoi and substr
14:39 particle (in pir.t)
14:39 Infinoid yep, and 21_string_ops_repeat.pir
14:39 particle i'm almost there
14:41 Infinoid fix checked in.
14:41 Infinoid driving to work, back later &
14:41 particle ~~
14:41 dalek r32048 | infinoid++ | trunk:
14:41 dalek : [t] Revert a couple of functional trailing whitespace breakages from r32041.
14:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32048
14:41 Zaba_ does rakudo implement macros?
14:41 Zaba_ that lisp-like cutiness!
14:42 moritz Zaba_: no
14:42 particle no
14:42 Zaba_ :/
14:42 particle that's really hard
14:42 particle last on the roadmap
14:42 AndyA joined #parrot
14:42 Zaba_ what if it requires major changes to the internals.. and it's the last on the roadmap..
14:43 particle it has yet unimplemented dependencies
14:43 particle read the roadmap file in languages/perl6
14:43 Zaba_ I see.
14:43 moritz Zaba_: it requires a much more flexible parser than we have right now. Running STD.pm is a big step towards that...
14:44 moritz Zaba_: STD.pm implements adding operators, that's like "baby macros", so we have a proof-of-concept already.
14:44 Zaba_ aha.
14:54 sjansen joined #parrot
14:56 * DietCoke gets one test file or so to pass.
14:57 jhorwitz joined #parrot
14:58 Infinoid so... that just leaves the failure in t/native_pbc/header.t for me.  when's the release?
15:00 DietCoke Anyone have hints on converting an existing language to use the new TGE?
15:01 particle tomorrow
15:01 purl o/~ the sun will come out.. tomorrow.. o/~ or the National Day of Slayer, and the National Emo Kid Beatdown day, by http://www.nationaldayofslayer.org/ and http://community.livejourna​l.com/wtf_inc/2805832.html or tomorrow and tomorrow and tomorrow creeps in this petty pace or mañana or free for all or another day
15:01 ruoso joined #parrot
15:01 particle and i have a bunch of failures that are annoying me
15:01 DietCoke (I see pheme is still failing)
15:01 sjansen joined #parrot
15:01 Infinoid does parrot build (or will it ever build) on a platform whose words are 2 bytes long?
15:02 particle may need config changes and bugfixes, but it should be possible
15:03 Infinoid in that case, I won't break t/native_pbc/header.t for those platforms, I'll just fix it for 64 bit platforms, thanks.
15:04 DietCoke particle: As you requested, I added a few tickets to the meta ticket.
15:04 particle thanks, skinny
15:08 dalek r32049 | infinoid++ | trunk:
15:08 dalek : [t] Fix a failure in t/native_pbc/header.t for 64-bit platforms.
15:08 dalek : This fixes RT #59876.  (wordsize == 8 is not a bug.)
15:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32049
15:11 masak joined #parrot
15:21 Tene DietCoke: please check your example on that ticket against new TGE, and post if that's how it should be, and if so, please make a new example that shows behavior that breaks?
15:24 * particle is close to committing a likely unrelated tge change
15:29 Infinoid All tests successful on debian/x86_64
15:31 Infinoid segfault in t/op/bitwise_27.pir on gentoo/x86_64
15:31 Infinoid (otherwise all tests successful)
15:35 allison Infinoid: what's the segfault?
15:35 purl well don't DO that, then.
15:36 Infinoid allison: http://rt.perl.org/rt3/Tic​ket/Display.html?id=59880
15:38 Infinoid chromatic helped me with some debugging last week, but we didn't get to a resolution.  something about a CPointer PMC pointing to bad data.  it's really hard to trace through the MMD stuff with gdb, I'm not familiar with that code at all.
15:38 allison aye, I've seen the ticket. there are a couple of different segfaults on that test from different platforms. just wondering which this was, or if it was a new one
15:40 Infinoid http://nopaste.snit.ch/14293 was the result of chromatic's guidance
15:41 Infinoid (note the final value is not even dword-aligned)
15:45 Infinoid All tests successful on gentoo/x86_32
15:47 AndyA joined #parrot
15:53 hercynium joined #parrot
15:56 DietCoke tene: here's my test: "cd pheme && make test". =-)
15:58 DietCoke part of my problem is that I can't write a new test without already knowing how to fix partcl.
15:58 DietCoke (or, presumably, pheme)
16:00 DietCoke (I can certainly get farther by updating certain bits from "a::b" to "a"; "b", but at some point there are no obvious conversions left to make, and partcl still fails. Is this a problem with TGE or partcl? I have no clue.
16:01 Infinoid ooh, I've reproduced the t/op/bitwise_27.pir segfault on x86_32
16:01 DietCoke Not a huge deal for tcl before the release. I don't have to target a release version, I can just update LANGUAGES.STATUS; I'm more worried about the other languages that are still in core.
16:02 Infinoid and I also have a couple of pcre failures on that box.  probably something to do with library versions
16:08 dalek r32050 | fperrad++ | trunk:
16:08 dalek : [Lua]
16:08 dalek : - remove PCT 'push_new' (deprecated)
16:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32050
16:16 particle1 joined #parrot
16:16 was kicked by particle1: particle
16:20 apeiron joined #parrot
16:25 apeiron joined #parrot
16:26 xiaoyafeng_ joined #parrot
16:46 Infinoid anyone else seeing failures in t/library/pcre.t or t/examples/library.t ?
16:48 dalek r32051 | particle++ | trunk:
16:48 dalek : [perl #48549] add empty brackets to .namespace declarations
16:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32051
17:17 chromatic joined #parrot
17:25 Infinoid moritz: ping
17:41 jsut|work joined #parrot
17:52 * DietCoke
17:53 chromatic Existential, man.
17:59 * DietCoke times out trying to load rt.perl.org
18:03 chromatic Yeah, I have trouble decoding packets by hand that fast too.
18:15 DietCoke 646 new/open remaining
18:17 chromatic An improvement of 39 tickets since Wednesday.
18:17 DietCoke Think we can get another 46 closed by release?
18:17 DietCoke (not with rt.perl.org going so fast.)
18:18 * DietCoke gives up on peeking at this during his break.
18:20 chromatic 10 or 15 is possible.
18:34 johbar joined #parrot
18:35 krunen joined #parrot
18:44 pmichaud anyone have any thoughts about removing the codingstd tests from 'make test'?
18:45 pmichaud purl msg tene   NQP should not get a .HLL, it's intended to work in the parrot namespace
18:45 purl Message for tene stored.
18:45 rajit joined #parrot
18:45 ruoso joined #parrot
18:46 chromatic pmichaud, +1
18:46 pmichaud purl msg tene   $parseactions and $parsegrammar should be allowed to be (1) a protoobject or (2) a string specifying the name of a protoobject
18:46 purl Message for tene stored.
18:47 johbar hi
18:48 pmichaud purl msg tene  we can't always use a protoobject because sometimes the protoobject doesn't exist at the time the hllcompiler instance is being created
18:48 purl Message for tene stored.
18:54 DietCoke pmichaud: we drag this topic up every six months or so. I don't see the utility of including codingstd tests in make test at all. There's a very small class of people running make test for whom that makes sense as a default.
18:55 DietCoke for releases or casual
18:55 DietCoke >>
18:55 allison and the answer is, we won't include them in make test when we get closer to the production release
18:55 DietCoke users, it doesn't make sense. only for core developers, and we can be taught to run something else.
18:55 allison for now, they're useful
18:55 DietCoke respectfully disagree.
18:55 DietCoke but I was overruled last time, and fully expect to be so again. =-)
18:56 allison when we take them out of 'make test' then they'll become a required step for the release manager before a release
18:57 pmichaud allison:  so, should rakudo's 'make test' also be running the codingstd tests as well, then?
18:57 allison with the rapid code changes at the moment, it's nice to have them constantly checked
18:57 allison pmichaud: that's up to you, but I do understand why you turned them on after being caught by coding standards failures several times
18:58 pmichaud I'm just trying to resolve a thread.  :-)
18:58 allison maybe the answer is to set up a regular cage-cleaner task of running 'make standardstests'
18:59 pmichaud I think that as long as they're run monthly before release, we're probably okay.
18:59 allison but, I know *I* tend to rely heavily on 'make test' (in core or languages) as the stamp of approval
18:59 pmichaud anyway, rakudo will continue to follow Parrot's lead here.
18:59 chromatic Q: How many non-codingstd tests do we have where the presence of an unnecessary trailing space indicates a legitimate failure?
18:59 chromatic Q: How many non-codingstd tests do we have where the absence of SVN metadata indicates a legitimate failure?
19:00 allison well, heck, let's be agile about it: turn off the coding standards tests from 'make test' for a month or two and see if it adds substantial annoyance for the release manager
19:00 pmichaud +1
19:00 purl 1
19:00 chromatic Q: How many checkins over the past year have gone toward satisfying my previous two questions?
19:00 chromatic Seems like someone could set up a cron job to run those tests and report any findings.
19:01 pmichaud there's already a weekly Parrotbug report.
19:01 pmichaud maybe it could be similar.
19:01 allison chromatic: A: coding standards tests don't identify legitimate failures, they only help prevent code drift
19:01 allison call it the anti-dandruff shampoo of code
19:02 allison and, yes, a smoulder-like report would work
19:02 chromatic Just about the only codingstd tests that fail check for no trailing spaces and SVN metadata.
19:02 pmichaud chromatic: (RT #59788 -- newclass exception handler)  -- I have a short PIR file that demonstrates the problem.  submitting now.
19:02 allison also line length
19:03 allison i get caught by line length all the time in branches
19:04 pmichaud we should still have a make target that tests functionality + coding standards -- I'm just not sure that 'make test' is it.
19:04 pmichaud Perhaps 'make devtest'
19:04 chromatic I'm all for coding standards, and automated testing makes sense there.
19:05 chromatic I'm just asking if our slowest tests tell us anything of value.
19:06 allison Well, I remember the old days, where simple debugging operations pretty much always turned into code tidying sessions.
19:06 chromatic Again, I'm only talking about the trailing spaces and SVN metadata tests.
19:07 allison Yup, even those have value.
19:07 allison But, again probably not in 'make test'.
19:07 chromatic What value do they have?  Which actual behavioral failures do they prevent?
19:08 allison We're not talking about functional failures, we're talking about helping to keep the codebase clean and maintainable.
19:08 chromatic How do the SVN metadata tests do that?  How do the trailing spaces tests do that?
19:08 allison Andy's "Technical Debt"
19:08 Andy what?
19:08 Andy huh?
19:09 Andy Oh, I have opininos on this one. :-)
19:09 allison Trailing spaces are always accidental garbage in the code.
19:09 NotFound svn metadata helps to avoid having a mix of LF and CRLF test files.
19:09 NotFound s/test/text
19:09 chromatic For which files is that actually a problem?  Has anyone measured that lately?  (I have.)
19:09 allison NotFound: Yes, and we have had real functional bugs caused by the line endings.
19:09 allison (line endings in test files)
19:10 grim_fandango_ joined #parrot
19:10 chromatic In *three* test files, the last time I measured it.
19:10 chromatic I'll be generous and triple that.
19:11 allison chromatic: Just to be clear: are you arguing that we should yield to messy code if it doesn't (currently) cause functional test failures?
19:11 chromatic By no means.
19:11 allison chromatic: Because that doesn't sound like you.
19:11 chromatic I'm saying "Get rid of slow, useless tests."
19:11 Andy allison: That was what I was thinking, too.
19:11 chromatic We have 3700+ files in MANIFEST where line endings do not matter.
19:12 Andy What I have is a make target called "fluff"
19:12 NotFound chromatic: we don't know how many problems we can have, because we are avoiding having them.
19:12 Andy analagous to lint
19:12 allison chromatic: Sure, but these aren't useless tests.
19:12 chromatic Is it worth checking all of them just to make sure the dozen or so files where it does matter have their SVN properties set?
19:12 allison chromatic: Yes, it's worth checking them before a release, at least.
19:12 Andy I see the stuff Allison is talking about as cage cleaner stuff.
19:12 chromatic Why?  If their SVN properties are wrong, we'll get legitimate failures.
19:13 hercynium joined #parrot
19:13 chromatic Compare that to our approach now, where every time someone wants to add (or move? I don't know for sure) a file, he has to update the SVN properties manually as well.
19:13 pmichaud perhaps a "make cagetests"?  Turn up the warnings and fluff and let the cleaners have at it.
19:13 allison chromatic: But we'll have to spend the time figuring out what caused the failures. While the SVN prop check will tell us right away what's wrong.
19:13 chromatic Heaven help the person who tries to use anything other than SVN to work with our code.
19:14 Andy I think the problem is that those SVN tests are EXPENSIVE.
19:14 chromatic That's exactly the problem.
19:14 allison chromatic: We skip the tests on non-SVN checkouts.
19:14 allison sure, so run them once a month
19:14 Andy But for those of us who do have svn, then it takes a LONG TIME
19:14 Andy Right
19:14 chromatic SVK takes longer.
19:14 Andy so we make cagetests
19:14 chromatic And don't forget people who make non-SVN checkins.
19:14 Andy not even cagetests, cagework
19:14 allison The only reason they're in 'make test' is because we don't have any process for running them as part of the release.
19:15 allison It's basically laziness.
19:15 NotFound And fixing
19:15 Andy because you could have svn properties, and line endings, and incorrect brace style
19:15 chromatic Like "make fulltest", you mean?
19:15 allison chromatic: yup, we could add it to 'fulltest'
19:15 Andy I do like the idea of splitting out into "tests that mean the software doesn't work" and "tests that aren't really tests but are verifying the infrastructure is correct"
19:16 chromatic I don't want drive-by potential committers to get tests that aren't really tests failures and think "These jokers can't write software."
19:16 allison I've argued for keeping them in 'make test' because it means everyone chips in to fix coding standards.
19:16 Andy and then not even call 'em tests
19:16 Andy allison: I agree with you in principle, BUT
19:16 Andy in practice they are DOG slow.
19:16 allison If they're only in fulltest, then the release manager will have to spend an hour before the release fixing coding standards test
19:16 Andy I'd rather have people run the tests AT ALL.
19:16 allison which is annoying
19:17 Andy that's why it shouldn't be "fulltest"
19:17 chromatic If only there were a way to set SVN properties on all new files automatically.
19:17 Andy They should be unrelated.
19:17 pmichaud (er, I meant 59778 earlier, not 59788.)
19:17 allison but, if the release managers are okay with that, then remove them from 'make test'
19:17 allison or, if we can get a cage process in place, so the release managers aren't the only ones
19:18 pmichaud "make codetest" already runs just the coding standards tests
19:18 pmichaud a wise release manager would ask people to run "make codetest" a day or two before the release.
19:18 allison ok, but who actually runs 'make codetest'?
19:18 chromatic ... but doesn't "make codetest" runs some codingstd tests that don't all pass?
19:18 pmichaud no.
19:19 Andy Do we agree that failed coding standards are not enough to hold up a release?
19:19 Andy or more importantly, an install?
19:19 allison pmichaud: yes, we can add a note about asking others to run 'make codetest' to the release manager's guide
19:19 chromatic or more importantly, a Smolder run?
19:19 pmichaud that's "make codingstd_tests" that runs all of the tests (including the non-passing ones)
19:19 chromatic Okay, good.
19:19 Andy To me, "tests" = pass/fail.
19:19 dalek r32052 | julianalbo++ | trunk:
19:19 dalek : fix a C++ build problem
19:19 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32052
19:19 Andy The cage/coding/etc stuff will NOT be pass/fail
19:19 pmichaud basically, "make codingstd_tests" runs all of the tests in t/codingstd,  "make codetest" runs all of the ones expected to pass
19:19 Andy for a long long time.
19:20 chromatic The macro tests will never pass, as written.
19:23 pmichaud okay, from what I'm reading now, Rakudo will go ahead and remove the codingstd tests from its "make test" target.
19:23 pmichaud Parrot can go to monthly or less-frequent checks as it desires.
19:24 chromatic time make codetest
19:24 pmichaud thanks, thread's resolved for me :-)
19:24 chromatic real    4m51.173s
19:24 chromatic user    3m35.125s
19:24 chromatic sys     0m10.953s
19:26 allison ticket submitted
19:26 allison pmichaud: yes, Rakudo can remove the coding standards tests
19:27 allison RT #60020
19:27 chromatic time make coretest
19:27 chromatic real    2m37.291s
19:27 chromatic user    1m25.381s
19:27 chromatic sys     0m22.337s
19:29 dalek r32053 | julianalbo++ | trunk:
19:29 dalek : fix a C++ build problem part II, generated imclexer.c
19:29 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32053
19:32 chromatic time prove t/codingstd/perlcritic.t t/distro/file_metadata.t
19:32 chromatic real    3m13.200s
19:32 chromatic user    3m3.247s
19:32 chromatic sys     0m7.928s
19:36 chromatic Now we *could* have someone set up a dedicated 'make codetest' Smolder box, which would seem to satisfy everyone's concerns, but you're going to have to argue very well to convince me that even those two codingstd tests are so important that they're worth spending 130% of the time we spend on coretests.
19:36 chromatic At least to run them by default from the command line.
19:40 particle1 as long as this doesn't impact my release tomorrow negatively, do what you will
19:40 NotFound I'm not concerned about passing the tests, but about fixing the code
19:41 chromatic Failing tests should indicate necessary changes and provide useful information.
19:44 NotFound Yes, and if people can see that information, they can avoid writing and comiting more substandard code.
19:46 chromatic We could add that to the patch submitter's guide.
19:50 jsut|work it looks to me like you all agree that they are too slow to be run every time you run make test, the only concern is that they DO get run before people commit (or at least regularly), but i've only spent a couple of hours in this channel, so take that with a grain of salt
19:51 NotFound I'm not make a statistic, but my subjective impression is that the number of rakudo commits with failing codingstd drastically decresed since the inclusion of codingstd in his tests.
19:51 DietCoke If we're talking about removing things from make test, t/configure/ should also go on the discussion list.
19:51 chromatic I have the impression, but no stats yet, that most codingstd test failures are trailing spaces and missing metadata.
19:51 chromatic By far.
19:52 NotFound Well, another thing that maybe can be done is to improve the speed of those tests.
19:52 particle the speed can be improved if the files are opened less frequently
19:53 DietCoke Even if they were still insanely fast, I'd rather not have them run by default.
19:54 DietCoke but that's a separate argument.
19:54 bacek joined #parrot
20:11 kj joined #parrot
20:13 moritz Infinoid: pong
20:18 kj anyone on windows who cares to confirm rt#39760?
20:21 particle i'm failing a bunch of tests on windows and need to figure out why
20:21 particle so i can't confirm or deny any bugs yet
20:22 Infinoid moritz: (re #59886) just want to verify: your t/library/pcre.t still fails before it hits "ok 3", right?
20:22 particle i think it's all unicode-related
20:22 Infinoid I've got a crash before "ok 5", and am not sure whether it's the same issue.
20:22 moritz Infinoid: checking...
20:22 Infinoid thanks
20:22 NotFound Infinoid: I have a fail on that test right now
20:23 moritz Infinoid: yes, just like you described
20:23 Infinoid so, we're all failing before "ok 5" now?
20:24 moritz before ok 3
20:24 NotFound #          got: 'asdf =~ /as/
20:24 NotFound # '
20:24 NotFound #     expected: 'asdf =~ /as/
20:24 NotFound # 1 match(es):
20:24 NotFound # as
20:24 NotFound # '
20:24 Infinoid that looks more like t/examples/library.t
20:24 NotFound Ups, not the same test
20:24 Infinoid I have that error too :)
20:25 Infinoid ... one one box out of 5
20:25 Infinoid those 2 tests pass everywhere else for me.
20:25 NotFound Is intermitent for me, sometimes passes, sometimes fails.
20:25 Infinoid both failures are consistent here.
20:28 NotFound pcre.t modifies interp[.IGLOBALS_LIB_PATHS] Is that usage supposed to be supported?
20:33 dalek r32054 | julianalbo++ | trunk:
20:33 dalek : replace remaining usage of Parrot_get_runtime_prefix with Parrot_get_runtime_path and add a note about deprecation of the former in his POD item
20:33 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32054
20:54 dalek r32055 | kjs++ | trunk:
20:54 dalek : [docs] update pdd19 w.r.t. RT#58236 (.arg->.set_arg, etc.)
20:54 dalek : + update examples
20:54 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32055
20:55 chromatic NotFound, I expect so.
21:03 rajit joined #parrot
21:04 Tene pmichaud: at the time we're creating new parsegrammar and parseaction objects, where do we get the hll namespace from if pa or pg is a string? Do we go digging around in the call stack the? earlier and store it, or get it explicitly and store it?
21:43 Lorn joined #parrot
22:02 bacek_ joined #parrot
22:11 Tene Do we know anyone near Atlanta, GA?
22:11 jhorwitz chromatic: ping
22:14 chromatic pong
22:14 chromatic RT #60030?
22:15 chromatic I'll take a look in a little bit.
22:15 jhorwitz awesome
22:15 chromatic Do you want it for the release?
22:16 jhorwitz not necessary, but it would be a bonus.  :)
22:16 Tene I'm going to take another swing at the TGE issues as soon as I get to my hotel.  The traaffic here in Atlanta is horrible.
22:17 Tene jhorwitz: did you see that I have some module stuff in cardinal?  I think you said you wanted it for mod-parrot support?
22:18 jhorwitz yep, i saw some commits.  :)
22:18 jhorwitz been stuck in segfault hell for a couple weeks.
22:18 particle ah, it's one of chromatic's patches causing me ill
22:19 jhorwitz afk &
22:20 GeJ joined #parrot
22:21 dalek r32056 | particle++ | trunk:
22:21 dalek : [t] fix windows failures due to pathname backslashes, and remove 'end' ops from pir while at it
22:21 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32056
22:40 TiMBuS joined #parrot
22:42 ruoso joined #parrot
22:49 Whiteknight joined #parrot
23:13 dalek r32057 | Whiteknight++ | trunk:
23:13 dalek : [GC] Investigating RT#46187. There was a lone "TODO" comment with no explanation. I've determined that there's nothing of interest to be done here, so I'm removing the offending comment and closing the ticket.
23:13 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32057
23:14 tetragon joined #parrot
23:17 particle ok, only 5 failures with msvc now
23:17 particle all due to invalid linking in t/src/compiler.t
23:17 pantherse joined #parrot
23:18 dalek r32058 | particle++ | trunk:
23:18 dalek : [t] create utility module for parrot tests
23:18 dalek : ~ add function for createing cross-platform tempfiles
23:18 dalek : ~ convert tests to use it
23:18 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32058
23:18 particle oops, spelling error :(
23:18 Whiteknight We're going to hit 600 tickets by the release if I have to work my fingers to the bone
23:19 particle i'd better get started on NEWS tonight!
23:19 pantherse hey, I just downloaded parrot from SVN and I tried to follow the episode 1 on the compiler FAQ. Does anyone know of any issues with running parrot on mac osx?
23:22 pantherse hello?
23:22 purl Raise purl's hand in the back if you can't hear me.
23:22 chromatic joined #parrot
23:23 pantherse where can I get help with the tutorial for compiler writer?
23:23 particle pantherse: we've been called 'helpful' before...
23:24 pantherse ok, I tried to follow the tutorial from this site: http://www.parrotblog.org/200​8/03/targeting-parrot-vm.html but when I run make test, I get the following error
23:25 pantherse perl t/harness
23:25 pantherse t/00-sanity....error:imcc:syntax error, unexpected PREG, expecting '(' ('$P12')
23:25 pantherse in file 'EVAL_1' line 11
23:25 pantherse error:imcc:syntax error, unexpected ')' (')')
23:25 pantherse in file 'EVAL_1' line 12
23:25 pantherse called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/HLLCompiler.pir:498)
23:25 pantherse called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1138 (src/PCT/HLLCompiler.pir:627)
23:25 pantherse called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1317 (src/PCT/HLLCompiler.pir:716)
23:25 pantherse called from Sub 'parrot;Aescla;Compiler;main' pc 58 (aescla.pir:49)
23:25 pantherse t/00-sanity....dubious
23:25 pantherse Test returned status 1 (wstat 256, 0x100)
23:25 pantherse DIED. FAILED test 3
23:25 pantherse Failed 1/3 tests, 66.67% okay
23:25 pantherse Failed Test   Stat Wstat Total Fail  Failed  List of Failed
23:25 pantherse ----------------------------------------​---------------------------------------
23:25 pantherse t/00-sanity.t    1   256     3    2  66.67%  3
23:25 pantherse Failed 1/1 test scripts, 0.00% okay. 1/3 subtests failed, 66.67% okay.
23:25 pantherse BEGIN failed--compilation aborted at t/harness line 12.
23:25 pantherse make: *** [test] Error 1
23:25 pantherse whoops, was hoping that wouldn't trigger a flood
23:26 pantherse let me try again
23:26 pantherse perl t/harness
23:26 pantherse t/00-sanity....error:imcc:syntax error, unexpected PREG, expecting '(' ('$P12')
23:26 pantherse in file 'EVAL_1' line 11
23:26 pantherse error:imcc:syntax error, unexpected ')' (')')
23:26 pantherse in file 'EVAL_1' line 12
23:26 pantherse Could not find non-existent sub n_add
23:26 pantherse current instr.: '_block11' pc 45 (EVAL_1:11)
23:27 pantherse called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/HLLCompiler.pir:498)
23:27 particle pantherse: learn about nopaste
23:27 particle nopaste?
23:27 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
23:27 purl nopaste is probably at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/
23:27 chromatic joined #parrot
23:27 was kicked by TonyC: nopaste
23:27 particle have a little patience, TonyC
23:28 dalek r32059 | Whiteknight++ | trunk:
23:28 dalek : [PMC] RT#46663 pointed to a comment with a question asking whether a particular sequence would cause problems with --gc-debug. The ticket is over 1 year old with no problems exposed by this sequence, and I don't see any way this could cause a problem as-is. Removing the offending comment.
23:28 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32059
23:29 pantherse joined #parrot
23:29 nopaste "pantherse" at 69.233.246.105 pasted "Error message from make test of Episode 1 of parrot compiler tutorial" (21 lines) at http://nopaste.snit.ch/14340
23:30 pantherse there, hopefull that's better
23:30 particle much better thanks
23:31 particle are you using parrot from svn, or a release?
23:31 pantherse svn. I tried the suggestions in the comments and still no joy
23:32 particle ok, what did you run to create the language?
23:34 pantherse Followed the steps to do perl tools/dev/mk_language_shell.pl Aescla language/aescla (I know I changed the name)
23:35 pantherse that didn't generate the Makefile, so I did what one of the comment posters did: perl tools/dev/mk_language_shell.pl Aescla; that generated the Makefile but I got the error on make test
23:35 pantherse so I did what the commenter on Sept 28 said to do hoping the error would be fixed; but no go
23:35 particle yes, you don't need to specify the location, it will be in languages by default
23:35 pantherse I just now did a make and got no error
23:35 particle that said, i just got the same error in make test
23:36 pantherse then when I went into languages/aescla directory and ran ../../parrot aescla.pbc it ran no problem
23:36 pantherse make test on the parrot root directory seems to go just fine.
23:37 particle sure, we just deprecated some ops
23:37 pantherse BTW, I'm running this on a mac osx
23:37 particle it's possible the new language generator uses the old ops
23:38 particle fixing...
23:38 purl i heard fixing was good, definitely.
23:38 pantherse ok, tnx
23:40 particle svn up, and regen
23:40 particle thanks for the report! pantherse++
23:41 dalek r32060 | particle++ | trunk:
23:41 dalek : [tools] removed deprecated n_ ops from language shell generator, pantherse++ for the bug report
23:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32060
23:43 pantherse tnx particle, I'll give it a try right now
23:45 pantherse trying fix right now
23:51 dalek r32061 | particle++ | trunk:
23:51 dalek : [lib] add documentation to create_tempfile function, coke++
23:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32061
23:52 * particle rebuilds parrot, with only five expected failing tests remaining, in t/src/compiler.t
23:52 Whiteknight 13 more tickets
23:53 particle #48549 shouldn't be hard
23:54 particle also #58974. tedious, but not difficult.
23:55 * particle heads out to do errands &

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

Parrot | source cross referenced