Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 20 tickets (0 to go), merge outstanding branches
Set by moderator on 27 August 2010.
kid51 cotto: Suggestion: place it in t/tools/ 00:00
It will fall into @library_tests which "are run unless --runcore-tests or --core-tests is present." 00:01
cotto Paul_the_Greek, go for it. I'm wondering how negative we can get the counter.
00:02 Psyche^ joined 00:07 Patterner left, Psyche^ is now known as Patterner 00:11 hercynium left
Paul_the_Greek cotto: Do you know if PMC attribute blocks are ever shared by multiple PMC headers? 00:11
00:14 hercynium joined
dalek rrot: r48698 | jkeenan++ | trunk (1 files):
Per discussion on list (also see TT #677), move pgegrep to examples/tools/ and move related test to t/examples/tools/.
 00:19
cotto Paul_the_Greek, I wouldn't think so but there might be a weird case. 00:20
Paul_the_Greek If not, we could allocate the PMC header and attribute block together.
We'd have to know the the attribute block wouldn't be replaced. 00:21
plobsing Paul_the_Greek: what about morph? 00:26
Paul_the_Greek Does it change one PMC into another type?
plobsing exactly
00:27 kid51 is now known as kid51_at_dinner
Paul_the_Greek So we add a promise_not_to_morph flag. When set, allocate header and attributes together. 00:27
It would be in the vtable.
plobsing you could allocate the header and attributes together initially and keep the data pointer
Paul_the_Greek I presume most languages don't use morph.
plobsing it would still have good cache locality most of the time 00:28
Paul_the_Greek Right.
And cut the number of allocations+frees in half.
plobsing most PMCs don't morph, but CallContext does. generally only deep magic has to do such things. 00:32
dalek rrot: r48699 | jkeenan++ | branches/tt677_toolsdirs (1 files):
As in trunk, move pgegrep to examples/tools/ and move associated test file to t/examples/tools/.
 00:35
Paul_the_Greek Perl allows it with rebless, right?
plobsing maybe. you'd have to check with jnthn or pmichaud on how Rakudo intends to implement that sort of thing. 00:37
Paul_the_Greek What's the right venue for discussing this sort of thing? Tuesday #ps meeting or here? 00:39
plobsing Not sure. I'd go with here. But probably you can make what you want to do work in the presence of morph, now that you know about it. 00:43
Paul_the_Greek The trick is to coordinate this with gc massacre. No point in woking on gc_ms when it will be replaced by gc_ms2. 00:45
I should talk to chromatic.
plobsing If you can't I'd try to get ahold of architect-y people to see if morph can be deprecated.
Paul_the_Greek I'm fairly sure from a conversation earlier today that Rakudo replaces PMC attribute blocks. 00:46
We might want a global flag that says "promise not to replace PMC attributes."
plobsing why are you trying to reduce the gcables load? I thought the biggest problem with gc was that it was stack-blowingly recursive. 00:47
Paul_the_Greek I'm thinking about allocation/free time, not GC time. 00:48
I suspect chromatic has reduced the stack requirements, but I'm not sure.
plobsing does it really cost that much to allocate? I thought it was just return and increment a pointer 00:49
Paul_the_Greek I'm more familiar with gc_ms, but it's pretty expensive to allocate a PMC.
At least with my old-timer mindset. 00:50
plobsing benchmark plz
Paul_the_Greek Indeed, some benchmarking would be the first task. It might reveal that I'm worried about nothing. 00:51
Someone suggested that a variant of one of the prime number benchmarks might be good. 00:52
plobsing if I'm not mistaken, pcc involves a lot of allocating. so anything with just a lot of recursion and simple integer math should have a lot (relatively) of gc over-head 00:53
Paul_the_Greek pcc? 00:54
purl Welcome to Perl Community College, where we, for free, and at your convenience, teach you all of an intro-CS curriculum, such as you should have learned in college or by simply reading on your own. Please also visit the Perl Crisis Clinic, where we do all your job for you. or Parrot Calling Convention or Proof Carrying Code or en.wikipedia.org/wiki/Portable_C_Compiler
Paul_the_Greek Yes, that's the sort of benchmark. What is pcc? 00:55
plobsing parrot calling conventions 00:58
purl parrot calling conventions is probably my best bet. But I don't know if anyone's done tests yet.
Paul_the_Greek Hey, sometimes Purl is clever. 00:59
On another subject: would it be helpful if I deal with some of the IMCC deprecations and bugs? 01:00
01:01 Administrator_ joined, Paul_the_Greek left
Administrator_ purl,messages 01:02
plobsing: Sorry, got disconnected.
plobsing imcc destroyed another perfectly good developer :(
01:02 Administrator_ left, Administrator_ joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48699 - Ubuntu 10.04 amd64 (g++ with --optimize) 01:02
Administrator_ plobsing: Sorry, I got disconnected. 01:03
01:03 Administrator_ left
plobsing heh. sure, have at those deprecations, Paul_the_Administrator. 01:03
01:03 Paul_the_Greek joined
plobsing sure, have at those deprecations, Paul_the_Administrator. or just poke me about them. I seem to be one of the only people working on IMCC these days. 01:04
(it's not that bad, I swear!)
mikehh plobsing: just don't walk in front of any busses 01:05
Paul_the_Greek I'd be happy to work on IMCC. I have a special place in my heart for assemblers.
What's the story with PIRC? 01:06
01:06 jsut_ left
plobsing if and when anyone cares enough about getting a saner variant of imcc, we intend to switch it in 01:06
Paul_the_Greek Has it been dropped in favor of Pirate? 01:07
plobsing or wait until pirate is fast and somehow magically solves bootstrapping accross pbc deprecations
mikehh Paul_the_Greek: PIRC was started and seemed to be progressing well. but the main dev (kj/kjs) ran out of availability
Paul_the_Greek Are they all source compatible? 01:08
mikehh it seems we have too much of parrot with low bus numbers
Paul_the_Greek Parsing "low bus numbers" ... nope. What it means? 01:09
mikehh what happens when developers get taken out by a bus
plobsing SIGBUS! 01:10
mikehh low bus number, not enough depth
Paul_the_Greek Ah, high bus danger.
Got it.
So if a guy wanted to work on "the assembler," where would he put his energy? 01:11
mikehh PIRC was to be a replacement of IMCC, pir/PIRATE is another option, but slow at the moment 01:12
plobsing Paul_the_Greek: if you have plenty of tuits, I'd work on swapping in pirc
you'd get plenty of kudos
if you want to work on the optimizer, I have been toying with the idea of post-processing PBC files to null-out dead registers as a stand in for a decent register allocator. 01:14
Paul_the_Greek After I work on a few more tickets and familiarize myself with the system, I'll think about looking at PIRC.
The IMCC optimizer? 01:15
mikehh tcurtis's GSOC project was an optimizer, it looks quite good, not sure what is happening with it
plobsing imcc doesn't really have an optimizer anymore. people kept blaming it for things (some of which it actually did)
tcurtis's optimizer is at a PCT level. PCT is great and all, but shouldn't be the only way of running things on parrot. 01:16
Paul_the_Greek It almost sounds as if there is room for a fresh assembler project here. 01:17
Then again, I suppose we might just end up with another unfinished one.
mikehh I think there are a lot of devs waiting to see what happens with Lorito 01:19
It would be nice to see PIRC completed 01:20
plobsing I'm not a big fan of parrot.exe containing a blessed assembler at all. But it seems most people are more comfortable with parrot.exe being able to run text files. 01:21
sorear let's add a text format which maps 1:1 to bytecode?
plobsing sorear: great idea. what happens when the internals of parrot change (eg: PBC_COMPAT bump) 01:22
?
Paul_the_Greek Do all HLL compilers generate pir source that is then compiled by IMCC? 01:23
sorear atm yes 01:24
whiteknight eventually they should all generate PBC directly 01:25
sorear plobsing: that won't be an issue as long as we still have a PIR processor written in C somewhere 01:26
I think PIRATE has a hacked version of PCT which generates PBC
Paul_the_Greek whiteknight: Using some library of functions that Parrot provides? Not with their own code generators.
whiteknight Paul_the_Greek: using a library, yes. We've made some progress in that direction in recent months, but we still don't have a comprehensive solution 01:27
sorear parrot already provides such a library. sort of.
plobsing sorear: that's not really what I'm getting at. If I'm not mistaken, at one point PIR mapped pretty well to parrot. Then things changed underneath and PIR became a kludge layer.
whiteknight is is possible to manually generate PBC from PIR code, bacek has a few examples of manually producing and executing bytecode
plobsing if a language maps 1:1 with PBC, it will change as PBC changes
whiteknight what we really need is a library with a nice API that does the dirty work internally
Paul_the_Greek Why not simply organize PIRC so that the HLL compiler can give it PAST directly? Then all the back-end good stuff works just fine. 01:28
plobsing PIRC is in C (not the most convenient language for manipulating trees of PMCs). 01:29
Paul_the_Greek A mere matter of a good library, no? 01:30
plobsing maybe when we get lorito, we can manipulate such trees in core parrot using a better HLL
Paul_the_Greek: if you write it, I'm sure they'll come. 01:31
Paul_the_Greek Writing the assembler in something that has to be assembled produces bootstrapping issues.
cotto I'm hoping that moving Parrot to git helps lower the barrier to working on highly experimental stuff like Lorito so more people feel like they can play along. 01:32
Paul_the_Greek There is much to ponder.
I'm not sure how much it will help. 01:33
sorear Paul_the_Greek: PAST is a third-party thing; for political reasons we can't make it the official way to interact with Parrot
compilers/ is our contrib/ 01:34
Paul_the_Greek The problem is knowing where to spend energy. For example, I spent maybe 8 hours studying gc_ms. But then I discovered gs_ms2.
sorear (also, I think you mean POST)
Paul_the_Greek The HLL compiler front end wants to give PIRC an abstract syntax tree, no?
There's poliics involved? 01:35
01:36 dngor_ joined 01:39 dngor left
Paul_the_Greek Looking for description of POST ... 01:39
plobsing Paul_the_Greek: PAST and POST serve more or less at the pleasure of pmichaud and the rakudo team. They aren't owned by parrot and could be changed at any time (although likely not). 01:40
Paul_the_Greek Oh. Does IMCC or PIRC parse into PAST/POST or something else? 01:41
plobsing neither use PCT (of which PAST and POST are part). they parse internally and either emit PBC, or generate packfiles (in-memory PBC representation) 01:42
01:42 bluescreen joined
Paul_the_Greek If I build an HLL that uses PCT, does my compiler ultimately emit PIR, which then gets compiled by IMCC? 01:44
Or does PCT have its own final code generator?
plobsing for the moment, yes. there are plans afoot to make PCT generate PBC directly. 01:45
making use of the Packfile* PMCs
Paul_the_Greek Duplicating all the optimization phases?
plobsing what optimization phases?
Paul_the_Greek The ones that IMCC/PIRC currently do or eventually will do. 01:46
plobsing currently IMCC's optimizer is disused. PIRC apparently has some whizbang optimizations, but is itself disused.
01:46 theory left
Paul_the_Greek In other words: Everything after the parser+intermediate code should only ever be written once. 01:46
plobsing ultimately, any optimization that PIRC or IMCC can do should be able to be done to a finished PBC. 01:47
01:47 theory joined
Paul_the_Greek But all possible optimizations involve phases in between parsing and code generation. No reason to duplicate those optimizations. 01:48
plobsing but PIR code maps pretty close to PBC. there should be no information lost when compiling from PIR to PBC. 01:49
whiteknight PAST/POST live in the Parrot repo. They aren't developed externally
plobsing Oh? I thought they were part of rakudo's nqp bootstrap. 01:50
Paul_the_Greek I'm thinking of optimizations between parsing and PIR generation. Does each HLL compiler worry about those? 01:51
01:51 jsut joined
plobsing Paul_the_Greek: some optimizations are allowed or dissallowed explicitly by the language spec. Backtraces conflict with TCO for example. 01:52
so they already have to worry about that. 01:53
Paul_the_Greek I would think there are a host of pre-PIR-generation optimizations that could be provided by a common compiler middle. 01:54
Is there objection to generating a source IR like PIR? Do people want a binary IR?
plobsing that's what PCT and tcurtis's gsoc provide
Paul_the_Greek Ah, got it. 01:55
plobsing requiring HLLs to compile down to PIR makes piecewise compilation more difficult (if not impossible). Whole-file compilation can get unacceptably expensive on bigger files. 01:57
Paul_the_Greek So the idea is that optimizations after PIR generation should be done by the PIR assembler.
plobsing: Why is that? A typical compiler generates a tuple IR that has a bunch of optimizations applied to it. 01:59
plobsing a tuple IR?
Paul_the_Greek A linear sequence of 3- or 4-tuples representing the program. 02:00
Pretty much what PIR is.
Some compilers never even bother with a tree. 02:01
plobsing the way we've done things so far, the pir compiler has done the optimization. I'm not sure it has to be (or should be) that way.
Paul_the_Greek Not all the optimizations, but I would think doing the final set of optimizations makes sense, so as not to duplicate them in every compiler. 02:02
Plus you guys are the experts in the interpreter, which is the ultimate target.
Perhaps it's difficult to break out a final set of optimizations from the rest of the optimizations. 02:03
plobsing I think some PBC-level universall-ish optimizations would be great if applicable after the PIR compiler (hotspot-like optimizing runtimes become possible)
Paul_the_Greek For example, register allocation. It's usually done pretty much at the end. Why not do it in the PIR assembler? 02:04
plobsing why not do it after the PIR assembler?
Paul_the_Greek Peephole optimizations.
plobsing maybe only on subs where it actually matters
Paul_the_Greek Why make the distinction "after the assembler"?
plobsing do one thing well
Paul_the_Greek Not sure I follow. Does someone want to generate PBC without going through the assembler? 02:05
sorear whiteknight: That's going to change soon, IIUC
whiteknight sorear: what do you mean? 02:06
sorear pmichaud wants to pull most of PCT out into the nqp-rx repository
and rewrite it in not-pir
cotto is afk 02:07
plobsing Paul_the_Greek: part of what people dislike about IMCC is that it is tightly coupled in odd ways. It uses the same datastructures to represent the parse as it does in optimization passes. As it turns out, this isn't such a great idea.
Paul_the_Greek Yes, most compilers have a sequence of IRs through their phases. But everything is still part of the compiler. 02:09
sorear IMCC also has more than a little tight coupling to other parts of parrot
plobsing worse, parts of parrot have tight coupling to IMCC
Paul_the_Greek The only reason I can think of to pull out the optimizations is because people want to use them a la carte.
sorear last time someone tried to fix the garbage collector, IMCC started randomly crashing
Paul_the_Greek Oops.
Well, I'm exhausted from a day of sititng on the beach. Back home tomorrow. Take care, everyone. 02:13
02:13 Paul_the_Greek left
dalek rrot: r48700 | chromatic++ | trunk/src/packfile.c:
[PBC] Fixed a memory leak in PackFile op mapping.
 02:15
rrot: r48701 | chromatic++ | trunk/src/pmc/class.pmc:
[PMC] Set destroy flag to plug Class memory leak.
rrot: r48702 | chromatic++ | trunk/src/packfile.c:
[PBC] Plugged Annotations memory leak.
rrot: r48703 | chromatic++ | trunk/src/runcore/main.c:
[runcore] Plugged op_libs memory leak.
rrot: r48704 | chromatic++ | trunk/src/pmc/parrotlibrary.pmc:
[PMC] Cleaned up ParrotLibrary destroy().
rrot: r48705 | chromatic++ | trunk/src/dynext.c:
[dynext] Tidied code; no functional changes.
plobsing msg chromatic: I don't think the memory leak addressed in r48700 should be leaking in the first place. That memory should be static, one-per-oplib; not one-per-packfile. 02:22
purl Message for chromatic stored.
02:35 janus left 02:48 kid51_at_dinner is now known as kid51
dalek rrot: r48706 | jkeenan++ | failed to fetch changeset:
Merge tt677_toolsdirs branch into trunk. Restrict tools/build/ to programs called by 'make all'. Eliminate tools/util/. Create tools/release/. Move other programs to tools/dev/. See: �trac.parrot.org/parrot/ticket/677.
 02:50
rrot: r48707 | jkeenan++ | branches/tt677_toolsdirs:
Branch has been merged into trunk and is no longer needed at HEAD.
purl i already had it that way, dalek.
rrot: r48708 | jkeenan++ | trunk/tools/util:
tools/util/ is now empty; delete from repository.
02:56 theory left 03:05 kid51 left 03:06 whiteknight left 03:13 janus joined
plobsing msg chromatic nevermind, I was making the same mistake I made when I wrote that code 03:19
purl Message for chromatic stored.
03:32 tcurtis joined 04:18 jsut_ joined 04:19 hercynium left 04:23 jsut left 04:33 preflex left 04:37 plobsing left 04:38 preflex joined 05:00 patspam left 05:03 bluescreen left 05:18 cognominal left, plobsing joined 05:29 cognominal joined, dngor_ is now known as dngor 05:30 plobsing left, plobsing joined 05:52 plobsing left 06:33 dalek left 06:34 dalek joined 06:48 fperrad joined
cotto 206*43 07:16
purl 8858
cotto 206*43/60
purl 147.633333333333
cotto 206*43/(60*24)
purl 6.15138888888889
cotto msg bacek Make sure aloha can do math. 07:21
purl Message for bacek stored.
moritz aloha: 35*2 07:22
purl 70
cotto purl_ignore_this_it_isnt_for_you: 2+3 07:23
purl 5
moritz Infinoid: dalek currently takes the 'login' field from the github API. However that's empty if the email address doesn't match the one that's registered with github... could you make it fall back to the name field in this case? 07:59
08:19 tcurtis left 08:34 jsut joined 08:39 jsut_ left 09:00 aloha left, aloha joined
bacek aloha: 35*2 09:02
purl 70
aloha bacek: 70
09:11 robin-gvx joined 09:34 lucian joined
bacek aloha, +1 09:40
09:40 bacek left, bacek joined
aloha bacek: Coke asked me to tell you that aloha only tells on join, not on "I said something." 09:40
bacek: Coke asked me to tell you to allow a trailing ? on karma requests.
dalek rrot: r48709 | mikehh++ | trunk/src/packfile.c:
add cast to get g++ to build
 09:41
09:44 fperrad_ joined 09:46 dalek left, dalek joined
Infinoid moritz: try that 09:46
moritz Infinoid: will do, as soon as I have a good testcase :-)
09:47 fperrad left, fperrad_ is now known as fperrad
Infinoid moritz: my test case: change your email in your .gitconfig to something else, then commit a whitespace change 09:48
moritz Infinoid: done 09:54
dalek kudo: a3d4be0 | moritz++ | src/core/Range.pm:
delete trailing blanks in Range.pm
 09:57
moritz Infinoid: seems to have worked 09:58
Infinoid cool. other symptom is that for that commit link, the author's name field isn't a link to your account 09:59
that means it didn't map it back 10:00
moritz Infinoid++
Infinoid and it was able to change "Moritz Lenz" to "moritz" because of your A: entry in parrot's CREDITS file 10:03
moritz right
dalek TT #1758 created by nwellnhof++: Segfault caused by new dynop mapping code 10:16
TT #1758: trac.parrot.org/parrot/ticket/1758
10:24 lucian left
dalek kudo: a821f58 | moritz++ | src/Perl6/Actions.pm:
change FORBID_PIR from contextual to global; this makes it persist through multiple REPL lines
 10:27
purl dalek: that doesn't look right
10:47 janus left 11:00 whiteknight joined
dalek TT #1537 closed by bacek++: Continuations fail to revert all registers to the correct state 11:07
TT #1537: trac.parrot.org/parrot/ticket/1537
11:24 janus joined 11:45 kid51 joined
dalek rrot: r48710 | bacek++ | trunk/src/pmc/filehandle.pmc:
Try to read whole file in FileHandle.readall. Closes #1749
 11:53
11:55 aloha left, aloha joined
dalek TT #1749 closed by bacek++: readall method on open FileHandle is inefficient 11:57
TT #1749: trac.parrot.org/parrot/ticket/1749
12:01 aloha left, aloha joined
bacek ~~ 12:02
aloha bacek asked me to tell you blah
bacek msg bacek looks like it works 12:03
purl Message for bacek stored.
aloha OK. I'll deliver the message.
bacek ~~
aloha bacek asked me to tell you looks like it works
bacek msg Coke aloha now delivers messages on any event. 12:04
purl Message for coke stored.
aloha OK. I'll deliver the message.
bacek msg cotto ask aloha about 2*26 for answer
purl Message for cotto stored.
aloha OK. I'll deliver the message.
kid51 aloha 2*26? 12:05
aloha kid51: 52
kid51 aloha 2**26?
aloha kid51: 67108864
bacek meh...
dalek kudo: 4ca5220 | moritz++ | src/Perl6/Grammar.pm:
forbid my $1
 12:32
12:42 kid51 left 12:46 NotFound left 12:58 NotFound joined 13:07 nwellnhof joined
nwellnhof Hey, more than 20 tickets closed 13:09
13:15 Coke left
dalek rrot: r48711 | nwellnhof++ | trunk (7 files):
Hash cleanup

  - Make get_*_pmc static
  - Cleanup and fix [gs]et_*_keyed functions in Hash PMC
  - Fix other bugs in Hash PMC		 13:18
13:50 lucian joined 14:19 ruoso joined 14:30 plobsing joined
dalek rrot: r48712 | nwellnhof++ | trunk/src (2 files):
codetest fixes
 14:42
15:03 Coke joined 15:04 theory joined 15:05 lucian left 16:04 patspam joined 16:17 theory left 16:22 robin-gvx left 16:26 robin-gvx joined 16:37 tcurtis joined 16:46 lucian joined, lucian left 17:19 nwellnhof left
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 20 tickets (-2 to go), merge outstanding branches 17:33
17:39 plobsing left 17:59 theory joined 18:01 theory left 18:23 Coke left
moritz on r48709, rakudo works fine 18:27
on r48712, 'use Test;' segfaults
(amd64 linux) 18:30
18:38 autark joined
moritz also broken on r48711 18:47
seems like r48710 is to blame 19:07
19:10 Coke joined
moritz indeed it is 19:14
moritz opens track ticket with severity 'fatal' 19:16
dalek TT #1759 created by moritz++: r48710 makesmodule loading in Rakudo segfault 19:17
TT #1759: trac.parrot.org/parrot/ticket/1759
19:26 kurahaupo joined 19:34 valya joined 19:37 kurahaupo left 19:39 valya left 19:40 robin-gvx left
dalek kudo: d9aa575 | moritz++ | src/Perl6/Grammar.pm:
reset $*IN_DECL for regex bodies
 20:01
20:11 kurahaupo joined 20:25 kurahaupo left 20:33 Paul_the_Greek joined
Paul_the_Greek Greetings, folks. Back home from the beach. I could have used another week. 20:33
20:41 fperrad_ joined 20:44 fperrad left, fperrad_ is now known as fperrad 20:54 ruoso left
Paul_the_Greek ping cotto 20:57
cotto pong 20:58
aloha bacek asked me to tell you ask aloha about 2*26 for answer
moritz aloha++ 20:59
aloha moritz: Thanks!
moritz bacek++
aloha-- # being spammy like purl 21:00
aloha moritz: Pbbbbtt!
cotto prefers privmsg messages
moritz aloha: karma bacek
purl bacek has karma of 3227
aloha moritz: bacek has karma of 7.
cotto Paul_the_Greek, pong
21:00 fperrad left
Paul_the_Greek cotto: Howdy. I'm back home and ready to commit the find_lex removal after fixing the broken tests. Can I review committing with you? 21:00
cotto I'd be glad to help. 21:01
Paul_the_Greek So I have five files with changes for this patch. I presume I need to commit them all with one commit so the changeset makes sense? 21:02
cotto It's a good idea to keep commits as atomic as possible. 21:03
Paul_the_Greek Not sure what you mean. One commit for each file?
cotto If you introduce a bug, it'll make bisecting easier.
one self-contained feature per patch, as much as possible
Paul_the_Greek So the files are: DEP.pod, var.ops (the change), and 3 test files. That would be "one feature," I think. 21:04
cotto Yes.
Paul_the_Greek If I commit all 5 files with one commit, does the changeset come out the way we want it? 21:05
cotto are you just updating the documentation or actually changing an op?
yes
Paul_the_Greek This is the change to find_lex so it doesn't throw an exception. You found two tests that failed, which I missed and have now fixed.
So it's a change to the op. 21:06
Ticket: trac.parrot.org/parrot/ticket/1207
cotto ok. You'll also need to run bootstrap-ops to update the generated ops files.
(It's easy to forget)
21:07 ruoso joined
Paul_the_Greek Yes, I did that. Then I did make test. That repeated the two test failures you found. I fixed them. Now make test is good. 21:07
cotto ok
Paul_the_Greek But the new ops files aren't part of the changes, right? 21:08
21:08 AzureStone left
cotto new ops files? 21:08
21:08 AzureStone joined
Paul_the_Greek The files generated by make bootstrap-ops. Those aren't part of the source, so not part of the commit. 21:08
cotto They are part of the checked-in code. 21:09
Paul_the_Greek Oh. You mean I have to commit core_ops.c, too? 21:10
cotto It will be committed automatically when you run svn commit
Paul_the_Greek How does it know to do that?
Oh wait ... 21:11
purl i guess wait ... is that one of his other silly conventions? placing a 'G' in front of any account that he thinks is global?
cotto can you nopaste the output from svn diff?
21:11 tcurtis left
Paul_the_Greek I don't want to commit everything I have here. I just want to commit the files for this one change. 21:11
cotto something like svn diff>var_ops.patch && perl tools/dev/nopaste.pl -t "var diff" var_ops.patch
Ah. Then you'll need to list the files explicitly, and src/ops/core_ops.c should be in that list 21:12
Paul_the_Greek You'll see all sorts of diffs that have nothing to do with this patch.
Right, that was my plan.
Why is core_ops.c part of the source? Why not just assume it's built when the system is built?
Oh ...
Because bootstrap_ops is not part of the basic build. 21:13
cotto exactly
You need parrot to build core_ops.c, but you need core_ops.c to build parrot
Paul_the_Greek Now will people be screwed up by the fact that these files have CR/LF line endings? 21:14
cotto something has to be checked in to allow bootstrapping
svn may be smart enough to take care of that. 21:15
Paul_the_Greek When I svn diff core_ops.c I get "svn: Inconsistent line ending style"
cotto give it a shot and we'll fix anything that needs to be fixed
Paul_the_Greek Okay. Now a stupid question about svn.
cotto go for it
Paul_the_Greek Hang on ...
cotto hangs on
Paul_the_Greek I want to put the six file specs in a file and then append that file to the svn commit command line. 21:16
How would you do that in a Unix shell?
My lack of shell knowledge is showing here. 21:17
cotto specs?
purl Specs in stone break no bones, but touch them and I will hurt you.
cotto forget specs
purl cotto: I forgot specs
Paul_the_Greek Forget that question. All set with that. 21:19
purl Paul_the_Greek, I didn't have anything matching that question. all set with that
cotto wfm
Paul_the_Greek All right, I'm going to try this. This is like trying sky diving for the first time. 21:20
cotto You're almost certain not to be killed. 21:21
just like skydiving
Paul_the_Greek Well, it worked for scuba diving in shark-infested waters, so here goes ...
cotto I'd love to do that sometime. 21:22
depending on the shark
Paul_the_Greek Down in the Bahamas they bring a frozen blob of fish and suspend it in the water. Go sharkies!
Okay, no editor defined. Let me fix that.
It wants a password for 'Administrator'. I'm guessing it doesn't know who I am. 21:25
cotto You need to use the same u/p as your trac account 21:26
Paul_the_Greek Is there an svn command for setting those, or do I edit a file?
I see no svn config or svn set. 21:27
cotto pass --username=your_name to svn when using svn commit
Paul_the_Greek svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request 21:30
I'm guessing I don't have commit privilege.
cotto I thought you did. 21:31
Paul_the_Greek It was to be given to three of us after the Tuesday meeting a few weeks ago. 21:32
cotto That's what I thought too.
Coke, ping
Paul_the_Greek Shall I msg him? 21:34
cotto if he doesn't answer soon, sure 21:35
did you put your usename in quotes? The spaces might be throwing something off. 21:39
Paul_the_Greek Yes, I did. 21:46
I'll msg Coke and ask for privs. 21:47
msg Coke I tried to commit something today, but it appears I haven't been given commit privilege. Could you set that up? 21:48
purl Message for coke stored.
aloha OK. I'll deliver the message.
Paul_the_Greek I'll wait to hear from him. Thanks for all your help, cotto.
cotto sure 21:50
22:07 dngor left 22:16 Paul_the_Greek left 22:24 theory joined 22:43 davidfetter joined 22:44 davidfetter left 22:49 dngor joined 23:06 kid51 joined 23:15 darbelo joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!