www.parrotcode.org/ | Last release: 0.7.1 "Manu Aloha"
Set by moderator on 17 September 2008.
00:09 AndyA joined
Whiteknight what file contains the NCI function prototype definitions? 00:20
00:22 TonyC joined 00:32 gmansi joined
chromatic config/gen/call_list/*.in 00:40
00:54 Theory joined 01:16 tetragon joined 01:23 TonyC joined 01:33 tetragon joined 01:39 dmknopp left 02:09 tetragon joined
dalek r32040 | chromatic++ | trunk: 03:08
: [src] Replaced all return CONST_STRING(...) instances with return
: string_from_literal(...) instances, as the latter allows safe caller
: modification of the returned string, and the former does not.
diff: www.parrotvm.org/svn/parrot/revision?rev=32040
03:10 bacek_ joined
bacek_ 10058 root 25 0 930m 823m 3576 R 100 41.0 2:57.78 check_state.pl 03:10
1 gig of memory for check_state...
EWRONGWINDOW
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
dalek r32041 | chromatic++ | trunk: 03:19
: [t] Removed non-functional trailing spaces from test files.
diff: www.parrotvm.org/svn/parrot/revision?rev=32041
Tene purl: Georgia? 03:21
purl Georgia is in the south. next to south carolina. dummies!
dalek r32042 | chromatic++ | trunk: 03:38
: [IMCC] Added a mutex to static global used in IMCC to make unique identifiers
: for EVAL_nn labels. See RT #40010, filed by Matt Diephouse.
diff: www.parrotvm.org/svn/parrot/revision?rev=32042
r32043 | chromatic++ | trunk: 03:59
: [ops] Restored debug_print op to the land of the living, or at least
: non-disabled, non-crashy ops. Also fixed a segfault. This closes RT #42379,
: though I don't guarantee it's *useful* for the debugger yet.
diff: www.parrotvm.org/svn/parrot/revision?rev=32043
chromatic 43 new + 617 open = 660 tickets. 04:02
dalek r32044 | chromatic++ | trunk: 04:11
: [ops] Removed a comment referring to RT #42371; it doesn't make sense to check
: that an invocant can do the method passed to callmethodcc invocant, method, as
: the method gets invoked anyway.
diff: www.parrotvm.org/svn/parrot/revision?rev=32044
04:48 mj41_ joined
dalek r32045 | chromatic++ | trunk: 04:58
: [distro] Added some deprecated functions to DEPRECATED.pod.
diff: www.parrotvm.org/svn/parrot/revision?rev=32045
r32046 | chromatic++ | trunk: 05:01
: [src] Replaced all uses of readable_name() with VTABLE_get_repr(), which now
: works on String and Key PMCs. This helps to unify all uses of readable_name(),
chromatic 43 + 614 = 657, and there I stop for the night.
dalek : get_repr(), and key_set_to_string(), as RT #45967 requests. readable_name()
: will persist through one deprecation cycle, vanishing in a few days after the
: Parrot 0.8.0 release. 05:02
: Please note that someone smarter or more diligent to me could improve the test
: coverage for the error message produced in t/oo/new.t. Object instantiation
: from arrays in particular needs testing.
diff: www.parrotvm.org/svn/parrot/revision?rev=32046
05:27 Bzek joined 05:39 MariachiElf joined
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:40
moritz depends 05:41
chromatic How big is the change? 05:42
cotto in #59940, changing some tests to check exception types rather than messages 05:43
although a general rule of thumb would be nice too
chromatic I usually make coding standards or typo fixes as I apply. 05:44
If it's anything more that a non-committer should reasonably be able to do, feel free to ask for changes.
cotto works for me 05:45
moritz that's how I do it as well, except that I was too lazy/sleepy to write it like that ;-) 05:46
chromatic++
05:51 TiMBuS joined
chromatic rt.perl.org/rt3/NoAuth/parrot/ParrotTODO.html 05:55
Very useful.
cotto very long 05:58
06:25 uniejo joined 07:28 Zaba_ joined 07:34 apeiron joined, uniejo joined 07:37 cosimo joined 08:00 iblechbot joined 08:39 Ontolog joined 08:51 viklund joined 09:04 tomyan joined 09:06 tomyan joined 09:38 apeiron joined 09:44 kj joined 10:07 xiaoyafeng joined 10:57 rdice joined 10:59 gaz joined 12:08 DietCoke joined
moderator parrot.org/ - clean up those smolders for the release! 12:09
dalek r32047 | coke++ | trunk: 12:11
: [docs] point to new website
diff: www.parrotvm.org/svn/parrot/revision?rev=32047
DietCoke tcl still doesn't work with tge latest; /me wonders how code has to change in tcl. 12:12
12:29 iblechbot joined 12:53 grim_fandango joined 13:10 Lorn joined 13:13 gryphon joined 13:27 allison joined 13:34 AndyA joined 13:40 Theory joined 13:43 PacoLinux joined 14:17 Andy joined
Infinoid chromatic's r32041 broke a couple of t/examples/ tests for me. 14:28
particle Infinoid: please post to parrotbug@ 14:30
Infinoid I was just going to revert the bits that fail 14:31
particle ok 14:32
Infinoid I was actually hoping someone knew what his "non-functional" rationale was
...wondering if maybe I need to upgrade something in Test:: or somesuch. 14:33
particle some tests, like those testing readline, require trailing spaces
they're expected in the i/o 14:34
Infinoid the failing tests are ones whose corresponding examples emit trailing spaces.
particle that makes those "functional"
Infinoid right.
particle i haven't run the tests today. i'm recompiling after a change to include [] after empty .namespace 14:35
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...
Infinoid I get breakage in t/examples/pir.t and t/examples/tutorial.t 14:38
particle hanoi and substr
(in pir.t) 14:39
Infinoid yep, and 21_string_ops_repeat.pir
particle i'm almost there
Infinoid fix checked in. 14:41
driving to work, back later &
particle ~~
dalek r32048 | infinoid++ | trunk:
: [t] Revert a couple of functional trailing whitespace breakages from r32041.
diff: www.parrotvm.org/svn/parrot/revision?rev=32048
Zaba_ does rakudo implement macros?
that lisp-like cutiness!
moritz Zaba_: no 14:42
particle no
Zaba_ :/
particle that's really hard
last on the roadmap
14:42 AndyA joined
Zaba_ what if it requires major changes to the internals.. and it's the last on the roadmap.. 14:42
particle it has yet unimplemented dependencies 14:43
read the roadmap file in languages/perl6
Zaba_ I see.
moritz Zaba_: it requires a much more flexible parser than we have right now. Running STD.pm is a big step towards that...
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
DietCoke gets one test file or so to pass. 14:56
14:57 jhorwitz joined
Infinoid so... that just leaves the failure in t/native_pbc/header.t for me. when's the release? 14:58
DietCoke Anyone have hints on converting an existing language to use the new TGE? 15:00
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 www.nationaldayofslayer.org/ and community.livejournal.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
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
Infinoid does parrot build (or will it ever build) on a platform whose words are 2 bytes long? 15:01
particle may need config changes and bugfixes, but it should be possible 15:02
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:03
DietCoke particle: As you requested, I added a few tickets to the meta ticket. 15:04
particle thanks, skinny
dalek r32049 | infinoid++ | trunk: 15:08
: [t] Fix a failure in t/native_pbc/header.t for 64-bit platforms.
: This fixes RT #59876. (wordsize == 8 is not a bug.)
diff: www.parrotvm.org/svn/parrot/revision?rev=32049
15:11 masak joined
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:21
particle is close to committing a likely unrelated tge change 15:24
Infinoid All tests successful on debian/x86_64 15:29
segfault in t/op/bitwise_27.pir on gentoo/x86_64 15:31
(otherwise all tests successful)
allison Infinoid: what's the segfault? 15:35
purl well don't DO that, then.
Infinoid allison: rt.perl.org/rt3/Ticket/Display.html?id=59880 15:36
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
Infinoid nopaste.snit.ch/14293 was the result of chromatic's guidance 15:40
(note the final value is not even dword-aligned) 15:41
All tests successful on gentoo/x86_32 15:45
15:47 AndyA joined 15:53 hercynium joined
DietCoke tene: here's my test: "cd pheme && make test". =-) 15:56
part of my problem is that I can't write a new test without already knowing how to fix partcl. 15:58
(or, presumably, pheme)
(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:00
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.
Infinoid and I also have a couple of pcre failures on that box. probably something to do with library versions 16:02
dalek r32050 | fperrad++ | trunk: 16:08
: [Lua]
: - remove PCT 'push_new' (deprecated)
diff: www.parrotvm.org/svn/parrot/revision?rev=32050
16:16 particle1 joined 16:20 apeiron joined 16:25 apeiron joined 16:26 xiaoyafeng_ joined
Infinoid anyone else seeing failures in t/library/pcre.t or t/examples/library.t ? 16:46
dalek r32051 | particle++ | trunk: 16:48
: [perl #48549] add empty brackets to .namespace declarations
diff: www.parrotvm.org/svn/parrot/revision?rev=32051
17:17 chromatic joined
Infinoid moritz: ping 17:25
17:41 jsut|work joined
DietCoke 17:52
chromatic Existential, man. 17:53
DietCoke times out trying to load rt.perl.org 17:59
chromatic Yeah, I have trouble decoding packets by hand that fast too. 18:03
DietCoke 646 new/open remaining 18:15
chromatic An improvement of 39 tickets since Wednesday. 18:17
DietCoke Think we can get another 46 closed by release?
(not with rt.perl.org going so fast.)
DietCoke gives up on peeking at this during his break. 18:18
chromatic 10 or 15 is possible. 18:20
18:34 johbar joined 18:35 krunen joined
pmichaud anyone have any thoughts about removing the codingstd tests from 'make test'? 18:44
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, ruoso joined
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
purl Message for tene stored.
johbar hi 18:47
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.
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:54
for releases or casual 18:55
>>
allison and the answer is, we won't include them in make test when we get closer to the production release
DietCoke users, it doesn't make sense. only for core developers, and we can be taught to run something else.
allison for now, they're useful
DietCoke respectfully disagree.
but I was overruled last time, and fully expect to be so again. =-)
allison when we take them out of 'make test' then they'll become a required step for the release manager before a release 18:56
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
pmichaud: that's up to you, but I do understand why you turned them on after being caught by coding standards failures several times
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'
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
pmichaud anyway, rakudo will continue to follow Parrot's lead here.
chromatic Q: How many non-codingstd tests do we have where the presence of an unnecessary trailing space indicates a legitimate failure?
Q: How many non-codingstd tests do we have where the absence of SVN metadata indicates a legitimate failure?
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
purl 1
chromatic Q: How many checkins over the past year have gone toward satisfying my previous two questions?
Seems like someone could set up a cron job to run those tests and report any findings.
pmichaud there's already a weekly Parrotbug report. 19:01
maybe it could be similar.
allison chromatic: A: coding standards tests don't identify legitimate failures, they only help prevent code drift
call it the anti-dandruff shampoo of code
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.
pmichaud chromatic: (RT #59788 -- newclass exception handler) -- I have a short PIR file that demonstrates the problem. submitting now.
allison also line length
i get caught by line length all the time in branches 19:03
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
Perhaps 'make devtest'
chromatic I'm all for coding standards, and automated testing makes sense there.
I'm just asking if our slowest tests tell us anything of value. 19:05
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.
allison Yup, even those have value. 19:07
But, again probably not in 'make test'.
chromatic What value do they have? Which actual behavioral failures do they prevent?
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?
allison Andy's "Technical Debt"
Andy what?
huh?
Oh, I have opininos on this one. :-) 19:09
allison Trailing spaces are always accidental garbage in the code.
NotFound svn metadata helps to avoid having a mix of LF and CRLF test files.
s/test/text
chromatic For which files is that actually a problem? Has anyone measured that lately? (I have.)
allison NotFound: Yes, and we have had real functional bugs caused by the line endings.
(line endings in test files)
19:10 grim_fandango_ joined
chromatic In *three* test files, the last time I measured it. 19:10
I'll be generous and triple that.
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.
allison chromatic: Because that doesn't sound like you.
chromatic I'm saying "Get rid of slow, useless tests."
Andy allison: That was what I was thinking, too.
chromatic We have 3700+ files in MANIFEST where line endings do not matter.
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.
Andy analagous to lint
allison chromatic: Sure, but these aren't useless tests.
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?
allison chromatic: Yes, it's worth checking them before a release, at least.
Andy I see the stuff Allison is talking about as cage cleaner stuff.
chromatic Why? If their SVN properties are wrong, we'll get legitimate failures.
19:13 hercynium joined
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.
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.
chromatic Heaven help the person who tries to use anything other than SVN to work with our code.
Andy I think the problem is that those SVN tests are EXPENSIVE. 19:14
chromatic That's exactly the problem.
allison chromatic: We skip the tests on non-SVN checkouts.
sure, so run them once a month
Andy But for those of us who do have svn, then it takes a LONG TIME
Right
chromatic SVK takes longer.
Andy so we make cagetests
chromatic And don't forget people who make non-SVN checkins.
Andy not even cagetests, cagework
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.
It's basically laziness. 19:15
NotFound And fixing
Andy because you could have svn properties, and line endings, and incorrect brace style
chromatic Like "make fulltest", you mean?
allison chromatic: yup, we could add it to 'fulltest'
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"
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.
Andy and then not even call 'em tests
allison: I agree with you in principle, BUT
in practice they are DOG slow.
allison If they're only in fulltest, then the release manager will have to spend an hour before the release fixing coding standards test
Andy I'd rather have people run the tests AT ALL.
allison which is annoying
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.
Andy They should be unrelated.
pmichaud (er, I meant 59778 earlier, not 59788.)
allison but, if the release managers are okay with that, then remove them from 'make test'
or, if we can get a cage process in place, so the release managers aren't the only ones
pmichaud "make codetest" already runs just the coding standards tests 19:18
a wise release manager would ask people to run "make codetest" a day or two before the release.
allison ok, but who actually runs 'make codetest'?
chromatic ... but doesn't "make codetest" runs some codingstd tests that don't all pass?
pmichaud no.
Andy Do we agree that failed coding standards are not enough to hold up a release? 19:19
or more importantly, an install?
allison pmichaud: yes, we can add a note about asking others to run 'make codetest' to the release manager's guide
chromatic or more importantly, a Smolder run?
pmichaud that's "make codingstd_tests" that runs all of the tests (including the non-passing ones)
chromatic Okay, good.
Andy To me, "tests" = pass/fail.
dalek r32052 | julianalbo++ | trunk:
: fix a C++ build problem
diff: www.parrotvm.org/svn/parrot/revision?rev=32052
Andy The cage/coding/etc stuff will NOT be pass/fail
pmichaud basically, "make codingstd_tests" runs all of the tests in t/codingstd, "make codetest" runs all of the ones expected to pass
Andy for a long long time.
chromatic The macro tests will never pass, as written. 19:20
pmichaud okay, from what I'm reading now, Rakudo will go ahead and remove the codingstd tests from its "make test" target. 19:23
Parrot can go to monthly or less-frequent checks as it desires.
chromatic time make codetest 19:24
pmichaud thanks, thread's resolved for me :-)
chromatic real 4m51.173s
user 3m35.125s
sys 0m10.953s
allison ticket submitted 19:26
pmichaud: yes, Rakudo can remove the coding standards tests
RT #60020 19:27
chromatic time make coretest
real 2m37.291s
user 1m25.381s
sys 0m22.337s
dalek r32053 | julianalbo++ | trunk: 19:29
: fix a C++ build problem part II, generated imclexer.c
diff: www.parrotvm.org/svn/parrot/revision?rev=32053
chromatic time prove t/codingstd/perlcritic.t t/distro/file_metadata.t 19:32
real 3m13.200s
user 3m3.247s
sys 0m7.928s
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
At least to run them by default from the command line.
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
chromatic Failing tests should indicate necessary changes and provide useful information. 19:41
NotFound Yes, and if people can see that information, they can avoid writing and comiting more substandard code. 19:44
chromatic We could add that to the patch submitter's guide. 19:46
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:50
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.
chromatic I have the impression, but no stats yet, that most codingstd test failures are trailing spaces and missing metadata.
By far.
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
DietCoke Even if they were still insanely fast, I'd rather not have them run by default. 19:53
but that's a separate argument. 19:54
19:54 bacek joined 20:11 kj joined
moritz Infinoid: pong 20:13
kj anyone on windows who cares to confirm rt#39760? 20:18
particle i'm failing a bunch of tests on windows and need to figure out why 20:21
so i can't confirm or deny any bugs yet
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
Infinoid I've got a crash before "ok 5", and am not sure whether it's the same issue.
moritz Infinoid: checking...
Infinoid thanks
NotFound Infinoid: I have a fail on that test right now
moritz Infinoid: yes, just like you described 20:23
Infinoid so, we're all failing before "ok 5" now?
moritz before ok 3 20:24
NotFound # got: 'asdf =~ /as/
# '
# expected: 'asdf =~ /as/
# 1 match(es):
# as
# '
Infinoid that looks more like t/examples/library.t
NotFound Ups, not the same test
Infinoid I have that error too :)
... one one box out of 5 20:25
those 2 tests pass everywhere else for me.
NotFound Is intermitent for me, sometimes passes, sometimes fails.
Infinoid both failures are consistent here.
NotFound pcre.t modifies interp[.IGLOBALS_LIB_PATHS] Is that usage supposed to be supported? 20:28
dalek r32054 | julianalbo++ | trunk: 20:33
: 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
diff: www.parrotvm.org/svn/parrot/revision?rev=32054
r32055 | kjs++ | trunk: 20:54
: [docs] update pdd19 w.r.t. RT#58236 (.arg->.set_arg, etc.)
: + update examples
diff: www.parrotvm.org/svn/parrot/revision?rev=32055
chromatic NotFound, I expect so. 20:55
21:03 rajit joined
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:04
21:43 Lorn joined 22:02 bacek_ joined
Tene Do we know anyone near Atlanta, GA? 22:11
jhorwitz chromatic: ping
chromatic pong 22:14
RT #60030?
I'll take a look in a little bit. 22:15
jhorwitz awesome
chromatic Do you want it for the release?
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.
jhorwitz: did you see that I have some module stuff in cardinal? I think you said you wanted it for mod-parrot support? 22:17
jhorwitz yep, i saw some commits. :) 22:18
been stuck in segfault hell for a couple weeks.
particle ah, it's one of chromatic's patches causing me ill
jhorwitz afk & 22:19
22:20 GeJ joined
dalek r32056 | particle++ | trunk: 22:21
: [t] fix windows failures due to pathname backslashes, and remove 'end' ops from pir while at it
diff: www.parrotvm.org/svn/parrot/revision?rev=32056
22:40 TiMBuS joined 22:42 ruoso joined 22:49 Whiteknight joined
dalek r32057 | Whiteknight++ | trunk: 23:13
: [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.
diff: www.parrotvm.org/svn/parrot/revision?rev=32057
23:14 tetragon joined
particle ok, only 5 failures with msvc now 23:17
all due to invalid linking in t/src/compiler.t
23:17 pantherse joined
dalek r32058 | particle++ | trunk: 23:18
: [t] create utility module for parrot tests
: ~ add function for createing cross-platform tempfiles
: ~ convert tests to use it
diff: www.parrotvm.org/svn/parrot/revision?rev=32058
particle oops, spelling error :(
Whiteknight We're going to hit 600 tickets by the release if I have to work my fingers to the bone
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?
hello? 23:22
purl Raise purl's hand in the back if you can't hear me.
23:22 chromatic joined
pantherse where can I get help with the tutorial for compiler writer? 23:23
particle pantherse: we've been called 'helpful' before...
pantherse ok, I tried to follow the tutorial from this site: www.parrotblog.org/2008/03/targetin...ot-vm.html but when I run make test, I get the following error 23:24
perl t/harness 23:25
t/00-sanity....error:imcc:syntax error, unexpected PREG, expecting '(' ('$P12')
in file 'EVAL_1' line 11
error:imcc:syntax error, unexpected ')' (')')
in file 'EVAL_1' line 12
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/HLLCompiler.pir:498)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1138 (src/PCT/HLLCompiler.pir:627)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1317 (src/PCT/HLLCompiler.pir:716)
called from Sub 'parrot;Aescla;Compiler;main' pc 58 (aescla.pir:49)
t/00-sanity....dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 3
Failed 1/3 tests, 66.67% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/00-sanity.t 1 256 3 2 66.67% 3
Failed 1/1 test scripts, 0.00% okay. 1/3 subtests failed, 66.67% okay.
BEGIN failed--compilation aborted at t/harness line 12.
make: *** [test] Error 1
whoops, was hoping that wouldn't trigger a flood
let me try again 23:26
perl t/harness
t/00-sanity....error:imcc:syntax error, unexpected PREG, expecting '(' ('$P12')
in file 'EVAL_1' line 11
error:imcc:syntax error, unexpected ')' (')')
in file 'EVAL_1' line 12
Could not find non-existent sub n_add
current instr.: '_block11' pc 45 (EVAL_1:11)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/HLLCompiler.pir:498) 23:27
particle pantherse: learn about nopaste
nopaste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl nopaste is probably at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/
23:27 chromatic joined
particle have a little patience, TonyC 23:27
dalek r32059 | Whiteknight++ | trunk: 23:28
: [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.
diff: www.parrotvm.org/svn/parrot/revision?rev=32059
23:29 pantherse joined
nopaste "pantherse" at 69.233.246.105 pasted "Error message from make test of Episode 1 of parrot compiler tutorial" (21 lines) at nopaste.snit.ch/14340 23:29
pantherse there, hopefull that's better 23:30
particle much better thanks
are you using parrot from svn, or a release? 23:31
pantherse svn. I tried the suggestions in the comments and still no joy
particle ok, what did you run to create the language? 23:32
pantherse Followed the steps to do perl tools/dev/mk_language_shell.pl Aescla language/aescla (I know I changed the name) 23:34
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
so I did what the commenter on Sept 28 said to do hoping the error would be fixed; but no go
particle yes, you don't need to specify the location, it will be in languages by default
pantherse I just now did a make and got no error
particle that said, i just got the same error in make test
pantherse then when I went into languages/aescla directory and ran ../../parrot aescla.pbc it ran no problem 23:36
make test on the parrot root directory seems to go just fine.
particle sure, we just deprecated some ops 23:37
pantherse BTW, I'm running this on a mac osx
particle it's possible the new language generator uses the old ops
fixing... 23:38
purl i heard fixing was good, definitely.
pantherse ok, tnx
particle svn up, and regen 23:40
thanks for the report! pantherse++
dalek r32060 | particle++ | trunk: 23:41
: [tools] removed deprecated n_ ops from language shell generator, pantherse++ for the bug report
diff: www.parrotvm.org/svn/parrot/revision?rev=32060
pantherse tnx particle, I'll give it a try right now 23:43
trying fix right now 23:45
dalek r32061 | particle++ | trunk: 23:51
: [lib] add documentation to create_tempfile function, coke++
diff: www.parrotvm.org/svn/parrot/revision?rev=32061
particle rebuilds parrot, with only five expected failing tests remaining, in t/src/compiler.t 23:52
Whiteknight 13 more tickets
particle #48549 shouldn't be hard 23:53
also #58974. tedious, but not difficult. 23:54
particle heads out to do errands & 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!