Parrot 1.9.0 released | parrot.org/
Set by moderator on 15 December 2009.
dalek TT #1371 created by carlin++: failed assertion 'PObj_is_PMC_TEST(obj)' doing IO from Rakudo 00:00
Tene anyone available for some git questions? 00:01
00:01 tetragon joined
japhb Tene, what's the question? 00:02
Tene japhb: possible to store acls in git?
japhb You mean, ACLs for the files? 00:03
Tene yes
setfacl/getfacl
My google-fu is failing me here. 00:04
japhb I don't know offhand, but there are a couple projects that have to do something similar, because they version secured trees.
Give me a sec, lemme find some
Tene, try taking a look at etckeeper 00:07
00:07 Zak joined
japhb kitenet.net/~joey/code/etckeeper/ 00:07
Tene japhb: thanks
japhb That may also be a decent jump-off point for googling
00:18 lucian joined 00:24 eiro_ left
dukeleto Tene: did I here git question? 00:27
Tene dukeleto: the answer seems to be "git doesn't do that"
storing file or directory acls
dukeleto Tene: aren't those OS-specific? 00:28
Tene kinda depends on how you look at it.
00:35 plobsing_ joined
dukeleto Tene: what depends? for example, do Linux ACLs work on freebsd? 00:39
Tene: where are ACLs stored? in the filesystem?
Tene: if the data is not in the file, it is not really git's problem
Tene acls are stored in extended attributes.
dukeleto Tene: it is a similar situation with svn:properties. they are outside the data of the file, so git-svn can allow you to read them, but there is no way to write to them from git
Tene So, same place as the permissions and ownership, approximately. 00:40
dukeleto Tene: where are extended attributes stored?
Tene: i see, well them maybe git can get access to them
Tene Huh. I thought that git didn't track ownership of files.
dukeleto Tene: if you ask the git mailing list about it, they might just actually implement it. 00:41
Tene: git tracks the permissions. what do you mean about ownership? the user/group of a file? I don't think it stores that. maybe I am wrong
purl but it feels so right
dukeleto purl++
Tene Yes, user/group.
darbelo purl msg plobsing I think I found the root cause of your failure after I removed the packfile. Passing a NULL assumes that the data is in platform-native format. If you pass it a packfile it inspects the header to determine the actual format. 00:48
purl Message for plobsing stored.
darbelo purl msg plobsing We should probably revert it, as I can't think of a clean way to work around it. 00:50
purl Message for plobsing stored.
00:56 abqar joined
diakopter what's a dynamic pmc? 01:18
cotto_work diakopter, it's a PMC that's compiled into a shared library and loaded at runtime 01:19
there are some in src/dynpmc
diakopter ok
must it be written to disk before it's loaded? 01:20
er
cotto_work I suppose it could be compiled into Parrot, which istr was the plan with the RTEMS port.
dalek tracwiki: v9 | cotto++ | CottoTasklist
tracwiki: trac.parrot.org/parrot/wiki/CottoTa...ction=diff
tracwiki: v1 | cotto++ | TestingProfiling
tracwiki: create a page to document the difficulties in testing the profiling runcore
tracwiki: trac.parrot.org/parrot/wiki/Testing...ction=diff
diakopter is it compiled to C and then sent through gcc? or to machine code? 01:22
(or pasm?)
cotto_work machine code
purl machine code is, like, a script for the CPU to follow
cotto_work the eventual plan is to have all PMCs and ops be written in Lorito, but that's a ways off.
diakopter what's Lorito? another assembly language? 01:23
cotto_work Lorito?
purl i think Lorito is "little parrot" in spanish or examples/embed/lorito.c
cotto_work L1?
purl well, L1 is a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982 or magical unicorns and flying puppies.
cotto_work that one
purl hmmm... that one is fairly new 01:24
cotto_work (L1 is the old name)
Coke pbc?
purl well, pbc is an acronym for the parrot bytecode format
Coke pbc is also Pay By Computer
purl okay, Coke.
diakopter purl, purl is dead. 01:25
purl ...but purl is <reply> ā™¬ beat on the bot // beat on the bot // beat on the bot with a baseball bat// oh yeah ā™¬ or pretty stupid, aren't you or an annoying girl or a non-intuitive answering machine or just the most convenient random number generator or a maroon or triddle's favorite information slut...
diakopter no, purl is dead.
purl, no, purl is dead
purl okay, diakopter.
cotto_work purl, purl?
purl hmmm... i am dead
01:25 cbarrett joined
diakopter is someone working on a spec for L1/Lorito? 01:26
cotto_work diakopter, nope. atm we're focusing on solidifying the foundation for Rakudo *, but I think it'll become a higher priority shortly after that. 01:27
diakopter or is it TAWP SCEEKRIT still. oh.
cotto_work chromatic said that it'd be at a similar level to libjit
diakopter hm 01:28
01:28 Zak joined
plobsing_ likes that idea... about as far as I can throw it 01:28
diakopter it must be a heavy idea..
plobsing_ nope, I'm just really bad at sports 01:29
cotto_work The idea is that once we can compile HLL code down to Lorito, we can write parts of Parrot in any HLL that compiles to Lorito.
(well, one idea among several)
diakopter oh 01:30
Lorito would be the MSIL equivalent then, I guess
cotto_work That sounds about right. 01:31
It'd be painful to write, but the majority of Lorito code would be generated anyway.
(Lorito would sit below PIR, so existing PIR could would continue to run, oblivious to lower-level changes.) 01:32
cbarrett Why have two levels of abstraction? PIR and then another intermediate representation. Seems duplicative. 01:36
(Not being aggressive, just curious)
bacek_at_work cbarrett, PIR is kinda macro assembler. A lot of syntax sugar, etc 01:38
cotto_work cbarrett, Lorito would be in there so we can avoid the expensive boundary between Parrot (PIR) and C calling conventions.
bacek_at_work Lorito is low-level ops. Think "RISC"
cotto_work hi bacek_at_work
bacek_at_work hi cotto_work :)
cbarrett So the idea is that you port Lorito to architeture X and then everything else rests on top of that 01:39
which means Lorito will look pretty different from PIR
(If so, that makes sense)
cotto_work cbarrett, kinda. The idea is to make it easy to have multiple backends for Lorito (e.g. libjit, LLVM, straight C, a runloop, etc) 01:40
diakopter 3-operand?
cbarrett Right. Perhaps architecture was the wrong word. 01:41
We're on the same page, I think.
cotto_work I think so.
Hopefully it's the right one.
diakopter, I suspect that's how it'll end up.
cbarrett cotto_work: If you think of Parrot as a PIR compiler, it makes (more) sense that Parrot would have an IR internally. 01:43
01:43 JimmyZ joined
diakopter my [limited] understanding of LLVM is that it's particularly good at optimizing HLL concepts/structures, like contexts, recursions, and closures... 01:43
cotto_work My understanding of LLVM is ļæ½. 01:45
diakopter so, I don't know how much gain could be had from emitting LLIR that was already essentially single-assignment
cbarrett diakopter: LLVM makes it easy to express those optimizations, I think. Particular the tools it gives you for building stuff in SSA form are neat. 01:46
s/I think/as I understand it/ 01:47
diakopter right, but if the Lorito language can't express those notions, they'll be compiled away already by the time it gets to LLVM..
will pointer arithmetic and jump to address by value be expressible in Lorito? 01:48
cbarrett diakopter: Yes, that's correct. 01:49
Coke japhb: you've been picked up. 01:52
cbarrett diakopter: Although it occurs to me that SSA form is not really an optimization, it's just a form that is easy to optimize.
So emitting SSA'd code would simply allow LLVM's optimizer to do all the hard work. 01:53
I don't really know how tightly coupled to LLVM you guys want to be.
cotto_work cbarrett, not very. We don't want to be limited to the platforms supported by LLVM. 01:55
cbarrett Fair. 01:56
japhb Coke, excellent, thank you! 02:12
Coke japhb++ # np. 02:13
Coke sighs. 02:32
02:33 kid51 joined
Tene Coke: looking at control shit now 02:33
where are my headphones...
02:37 darbelo joined
Tene Coke: I can't reproduce it in nqp... 02:45
nopaste "tene" at 24.10.252.130 pasted "This outputs 42, as it should, Coke. Can you confirm?" (8 lines) at nopaste.snit.ch/19100
Tene now, rakudo does fail on it... 02:46
Coke parrot-nqp or parrot_nqp?
Tene ./nqp in the nqp-rx repo
do you want me to check with one of those? 02:47
dukeleto 'ello
Coke ; I'm not using that. I'm using parrot. =-)
I'll check in nqp-rx. moment.
Tene isn't that the nqp that parrot ships with these days?
parrot-nqp gives the same result
I don't have a parrot_nqp
Coke hurm. 02:48
failed for me when I sent you the email. checking my example...
Tene Coke: that fails with *rakudo* thought
though
Coke I originally had the problem in nqp, though. 02:49
yah, I cannot duplicate it in nqp. 02:50
darbelo plobsing_: ping 02:53
Tene I feel weird patching rakudo master. >.>
although it looks like ng gets it wrong too? huh?
plobsing_ darbelo: pong 02:54
cotto Rakudo has bugs. Ask masak. 02:55
darbelo I sent purl-msgs to your un-underscored alter ego. Did you see those?
plobsing_ some.
I am currently testing a revert of 43056,43057 02:56
Coke Tene: sorry about the confusion on my bug report.
Tene Coke: that's fine. No problem. Do you want rakudo fixed in master, or is just ng okay for you? 02:57
darbelo plobsing_: Cool. I'm on amd64 now, so I was about to try to reproduce the failures. 02:58
plobsing_ darbelo: However, I don't think this is a x-platform issue. When it has the pf, it reads as LE 8 (native)
I think the problem is in being lazy in the reading.
without the pf
darbelo It could be that too. I only looked inside PF_fetch_number() 02:59
plobsing_ In the grand scheme though, thaw should really take a PF as an argument to be able to thaw PMCs in non-native-encoded PBCs
Coke Tene: just ng is fine.
plobsing_ darbelo: IIRC, thats the only one that doesn't cause an error when passed null 03:00
darbelo chuckles.
Figures.
I'm actually wondering if we should move to a Packfile PMC instead of a PackFile struct. There'll be a performace hit, since we'll be hoping the PIR/C barrier often, but it would give increased PIR-level functionality. 03:03
plobsing_ I breifly looked at that. I didn't see how to do low-level IO through the PMC version. 03:05
darbelo I think we could manage a RawPackfileSegment in the same way we now manage the buffer. 03:06
Tene purl: msg pmichaud should PAST::Op(:pasttype('try')) maybe have named arguments for exception types to handle? or do we just say "use .handlers() for that"?
purl Message for pmichaud stored.
Tene Coke: committed. now looking at loops. 03:07
darbelo Granted, that's two extra GC-ables per frozen PMC, but I don't think it's a frequent enough operation to be worth worying about. 03:08
plobsing_ darbelo: if this code becomes useful, we might use it for other object graph traversals. that might increase the frequency 03:09
kid51 I will soon be applying this patch from JimmyZ: trac.parrot.org/parrot/attachment/t..._886.patch 03:12
Any objections?
Coke I'd like one of the C developers to +1 that. 03:13
+0 from me. =-)
cotto give me a few minutes
JimmyZ couldn't find a scanner here. :) 03:14
kid51 There is also an associated patch in that ticket for Win32: trac.parrot.org/parrot/attachment/t..._win.patch
cotto kid51, does it cause any new warnings or test failures, and what did you test it on?
kid51 I am currently running 'make test' on Linux/i386. Results in a few.
darbelo kid51: The consting looks good, but I would use mem_allocate_n_typed.
Tene Coke: you'll like this... s/last/zomglol/ in your loop 03:15
since you don't have ()s after it, it's not trying to *call* it, it's just doing a "get_hll_global" and then doing nothing with it.
Coke should you need ()'s for last? 03:16
Tene I don't know...
dalek rrot: r43079 | plobsing++ | branches/pmc_freeze_cleanup (2 files):
Revert of r43056 and r43057. Apparently the Packfile is used for something after all.
kid51 'make': No difference in output with tt_886.patch applied on top of r43078 from 'make' output at r43056. 03:17
'make test': PASS: smolder.plusthree.com/app/public_pr...ails/30946 03:18
cotto I'd second darbelo's recommendation. Other than that, +1 from me.
kid51 darbelo: If you want to work on it, please discuss with Jimmy and post to ticket. I'll hold off applying until this is resolved. 03:19
nopaste "tene" at 24.10.252.130 pasted "This works, fwiw" (16 lines) at nopaste.snit.ch/19101
kid51 cotto: ditto, please post in TT. thanks.
Tene Coke: check the paste for something that works.
cotto It's a pretty trivial change. I can adjust and apply. 03:20
darbelo kid51: It's a cosmetic issue, it ends up #defined to what he wrote anyways. I give it +1. 03:21
Coke Tene: ok. I can construct something like that that fails, since that's pretty much what "break" is, and break doesn't work. 03:24
Tene purl: msg pmichaud Coke is wondering about next/last/redo in NQP... should nqp recognize those names in its grammar and generate PIR to build and throw the exceptions, or do we leave it up to nqp users to write their own last() functions, like nopaste.snit.ch/19101 (note: this requires you to call last(); instead of just last;)
purl Message for pmichaud stored.
Coke if you grab the latest partcl and try:
Tene building... 03:25
Coke partcl-nqp, that is;
Tene yes
Coke ./partcl t/cmd_break.t - you can see the mis.
*miss
Tene do you have some kind of global error handler in compiled code? you're calling back into the compiler here... 03:29
looks like no 03:30
darbelo sees INTVAL last_type 03:32
Do we really have to care if the previous PMC was of the same type here?
plobsing_ darbelo: its compression. not sure if it is good or not.
dalek TT #1367 closed by jkeenan++: [patch]changed codestring.pmc to use GET_ATTR syntax and consting 03:33
kid51 must sleep
purl $kid51->sleep(8 * 3600);
darbelo plobsing_: Exactly. All of this code is full of small optimizations that I'm not sure are really still valid. 03:34
plobsing_ darbelo: if you have an array of the same type, you'd save N-1 INTVALs in the PBC
probably also true of hashes 03:35
with elements of only one type
darbelo I don't see too many of those around here. 03:36
plobsing_ Yeah, seems uncommon. I would remove, but it would change PBC 03:37
is changine PBC backwards incompatible change?
Tene Coke: adding a CONTROL block to your for builtin shows that the exception isn't making it through your eval stuff.
nopaste "tene" at 24.10.252.130 pasted "CONTROL for log patch for Coke++" (13 lines) at nopaste.snit.ch/19102
darbelo plobsing_: Not really. We just bump PBC_COMPAT and move on. 03:38
Coke Tene: odd; eval() doesn't have a try {}. 03:40
03:40 cbarrett joined
Coke looks like it ends with &sub(), which should throw the exception, yes? 03:41
s/throw/pass through/
Tene yes
Coke wier.d 03:42
nopaste "tene" at 24.10.252.130 pasted "as it does here" (19 lines) at nopaste.snit.ch/19103
plobsing_ darbelo: wait, hold on a second. its type in the PMC type sense. In that sense all Objects are of the same type. 03:43
so an array of Object PMCs gets more efficient. that seems like it might come up quite a bit.
darbelo I thought it was getting set to vtable->base_type; 03:47
That's different for every PMC. 03:48
dalek rrot: r43080 | cotto++ | trunk (7 files):
[misc] consting and various cleanups as part of TT #886, courtesy of JimmyZ++
 03:49
rrot: r43081 | plobsing++ | branches/pmc_freeze_cleanup (3 files):
Add {push,shift}_pmc ops to visit_info.

src/hash.c is an example use of this.
plobsing_ darbelo: in general yes, but if the pmc passes PObj_is_object_TEST(), it gets set to enum_class_Object 03:50
so all objects are considered to be of the same type 03:51
darbelo That would be PMCs defined in PIR IIRC. 03:52
plobsing_ anyways, there's only one way to know for sure... rip it out and compare before and after. 03:53
darbelo That could have an impact in big arrays.
Yah, I'm looking for an example that execises this so I can callgrind it. 03:54
But this isn't heavily exercised code AFAICT. 03:55
03:56 patspam joined 03:58 theory joined 04:04 cbarrett left
Tene any other parrot or rakudo requests before I sign off for the night? 04:13
darbelo Ohh, config_lib.pasm looks like a very good test case for this. 04:14
A short run, and all it does is place a bunch of strings in a hash which is the frozen. 04:16
plobsing_ Strings or string PMCs?
japhb Tene, still here? 04:17
JimmyZ Tene:怀rakudo: my ($a, $b) = $b, $a doesn't work in ng.
darbelo It's all string literals in the source. I don't know if the Hash PMC autoboxes.
japhb Tene, if you're also doing NQP-rx, fat arrow => at least for function arguments would be nice. ;-) 04:18
plobsing_ I think by default a hash's contents are assumed to be PMC
you have to ask for different behaviour
Tene yes. working on Getopt::Obj now.
JimmyZ Tene: ($a, $b) = ($b, $a) if ($b > $a); 04:19
Tene oh right, forgot about that, japhb.
japhb np! 04:21
darbelo "By default Hash uses string keys and PMC values."
dalek rrot: r43082 | japhb++ | trunk/compilers/data_json (2 files):
[data_json] Working but possibly suboptimal fix for TT #1326
TT #1326 closed by japhb++: crow.pir is broken 04:22
plobsing_ side note, config_lib.pasm is a good place to use a Hash[String=>String]. Would probably save space, and definitely save gcables. 04:23
Tene okay, we just had a release, so I'm just going to commit this Getopt::Obj change, and everything in the parrot repo that's using it. c thinks it counts as a bugfix, so no deprecation notice required.
darbelo Tene++ 04:27
plobsing_: Well, on tha particular run callgrind's instruction coun reports a difference of 0.48% 04:30
plobsing_ darbelo: I don't think that's the metric that matters. What's the difference in sizes of fpmc produced? Thats what's being optimized for. 04:32
Tene japhb: gimme a quick test for fatarrow. 04:34
darbelo plobsing_: True, but I wanted to see if the performace changed at all. I'm measuring space next. 04:35
Tene japhb: my tests seem to work... I'll commit it if you add a test for it to the nqp-rx repo 04:36
japhb: committed.
dalek p-rx: 7c9ba0a | tene++ | src/NQP/ (2 files):
"Fat Arrow" named parameter passing syntax for japhb++
japhb
.oO( Don't know if I even have an nqp-rx commitbit )
 04:37
diakopter japhb: any of several folks can add you through the ircbot ui 04:38
dalek rrot: r43083 | tene++ | trunk (11 files):
Fix Getopt::Obj to use a keyed namespace
darbelo 32432 - 30160
purl 2272
darbelo as measured by "du -b"
diakopter not Tene though :)
darbelo I'm not sure I care for that space saving, really. 04:40
plobsing_ If it matters that much, it can always be redone 04:42
JimmyZ otto: ping 04:43
cotto: ping
cotto JimmyZ, pong 04:45
JimmyZ Could anyone tell me where is the function defined? trac.parrot.org/parrot/browser/trun....pmc#L1773
cotto Without looking, I'd guess that it's invalid code that gets silently dropped on the floor by pmc2c. 04:46
I'll check.
JimmyZ cotto: Does it call STATICSELF.remove_method ?
cotto JimmyZ, yes. I was wrong in my guess. 04:47
I'd never seen that VTABLE function before.
It's the same as any other VTABLE function call. 04:48
JimmyZ cotto: I am trying to change them to use static function instead of pmc->vtable->foo().
cotto That will work within a single file but I intentionally removed that functionality a while ago to reduce the number of symbols that libparrot needed to expose. 04:50
(at chromatic++'s recommendation)
JimmyZ cotto: STATICSELF.remove_method is works well in pmc now.
cotto: s/is// 04:51
cotto: Does it not recommend?
cotto I don't know either way/ 04:52
s?/??
I'd submit a tt about it. 04:53
JimmyZ cotto: I think use static function within a single file always be recommendatory
cotto My only concern would be subclasses of Class, but I don't know if that would make sense.
dalek rrot: r43084 | plobsing++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
headerizer + codingstd updates
 04:54
JimmyZ cotto: yep
cotto It's nice to see our sanity injection framework (a.k.a. plobsing) at work. 04:55
plobsing++
Tene any other requests before I'm done for the night?
cotto make Parrot faster than the jvm 04:56
darbelo Yeah, now I can look at this file without my eyes bleeding. plobsing++ indeed.
JimmyZ cotto: My only concen would be reducing the useful codes from parrot and unifying the codes.
cotto: ;)
cotto: s/useful/unuseful/ :)
cotto ok. Dead code elimination is a good goal. 04:57
It's nice not to have to take a little extra time to figure out that a bit of code is useless.
JimmyZ cotto: i.e. when it can use STATICSELF.foo(), I shouldn't let it use SELF.foo() or VTABLE_foo(). 04:58
cotto: that is abount unifying.
cotto Sure. That'll save us some pointer dereferences.
JimmyZ cotto: 'there is more than one way to do it' is perl's cultural. I don't think parrot has the same. haha 05:00
cotto Parrot doesn't need that. That's an HLL philosophy. 05:01
(which Perl 6 takes to dazzling and terrifying new heights, btw)
JimmyZ cotto: yep, so I'm reducing it in parrot. 05:02
Tene Okay, goodnight all.
cotto night Tene
JimmyZ Tene: good night.
cotto don't let the Parrot bugs bite
maybe when you wake up there will be fewer of them 05:04
or more
JimmyZ Is there a way to catch them? 05:06
dukeleto japhb++ # fixing crow.pir 05:07
japhb dukeleto, and now I already have my TT fix for the week. ;-)
JimmyZ cotto: If I'm wrong, please warn me. thanks. 05:12
cotto pbc_dump makes me happy 05:19
darbelo cotto: How so? 05:21
cotto It makes it easier to figure out the packfile format
darbelo Wish I had known that two days ago. 05:22
cotto there's also pbc_disassemble
darbelo, now you know 05:23
dalek rrot: r43085 | darbelo++ | branches/pmc_freeze_cleanup (2 files):
Remove the last_type member from the visit_info structure.
 05:26
JimmyZ hmm. SELF.foo() and STATICSELF.foo() is different, changing them maybe make test failed. 05:28
cotto yup 05:29
JimmyZ when it's only within METHOD and using PIR args flags(i.e. :optional), it's defferent. 05:31
Is it right? 05:32
pmichaud ...I'm a little surprised that r43083 (changing the Getopt namespace) doesn't require a deprecation notice. 05:33
JimmyZ any other difference?
Coke pmichaud: ... it should. 05:40
if it's a change and not an addition, that's going to break anyone using it.
darbelo pmichaud, Coke: irclog.perlgeek.de/parrot/2009-12-15#i_1841499
pmichaud yes, I read the backlog. I'm still surprised. 05:41
Coke opening a itcket.
darbelo Oh, ok. FWIW we can still go with NotFound's idea of having duplicates. 05:42
dalek rrot: r43086 | darbelo++ | branches/pmc_freeze_cleanup/src/pmc_freeze.c:
Add _NULLOK() to an ARGIN macro and add a cast to pacify the compiler.
 05:43
pmichaud well, I expect nqp-rx and HLL::Compiler to totally not use Getopt::Obj anyway, so it's not a big deal to me. I'm just surprised by it.
afk # sleep time 05:45
Coke tt#1372 05:46
05:47 abqar joined
dalek TT #1372 created by coke++: r43083 breaks support 06:00
Tene pmichaud: according to chromatic it doesn't count because it's a bug. 06:18
oh, yes, you read the backlog.
pmichaud: PCT::HLLCompiler used it, fwiw 06:19
06:32 chromatic joined 06:55 particle1 left 07:08 bacek joined
dukeleto time to hack on tapir 07:10
is trac.parrot.org/parrot/ticket/1372 about JSON vs data_json ? the TT is ambiguous 07:14
cotto clock? 07:15
purl cotto: LAX: Tue 11:15pm PST / CHI: Wed 1:15am CST / NYC: Wed 2:15am EST / LON: Wed 7:15am GMT / BER: Wed 8:15am CET / IND: Wed 12:45pm IST / TOK: Wed 4:15pm JST / SYD: Wed 6:15pm EST /
cotto are we there yet? 07:26
purl almost, it's just around the corner
cotto which corner?
purl which corner is that?
dukeleto who's on first?
purl okay, dukeleto.
JimmyZ where is purl? 07:29
purl i am probably dead
JimmyZ purl, are you dead?
purl jimmyz: i haven't a clue
JimmyZ purl? 07:30
purl yes, JimmyZ?
cotto purl, are you dead? is <reply>braaaaaiiiiiiinnnnnssssss 07:32
purl OK, cotto.
cotto are you dead?
purl braaaaaiiiiiiinnnnnssssss
dukeleto purl, what do you want for dinner? 07:34
purl dukeleto: bugger all, i dunno
dukeleto purl, you want brains for dinner
purl dukeleto: excuse me?
dukeleto purl, what is for dinner? is <reply>BRAAAAAAIIIIIIIIINNNNNNSSSS with a side of fava beans and a nice chianti 07:35
purl i don't know, dukeleto
dukeleto purl: i hate you 07:36
purl dukeleto: sorry...
cotto kicks purl with an old botsnack
night, bot abusers ;) 07:37
dukeleto botsmack 07:39
purl shoots up... ahhh
dukeleto maybe this should be our new logo: www.bordom.net/view/30684/Honey_did...ce=twitter 07:41
japhb: is there something in plumage that can tell me if a binary exists in the current PATH? i remember something like that 07:51
08:02 bacek joined
bacek o hai 08:02
dukeleto bacek: howdy
bacek aloha dukeleto
dukeleto is hacking on using distutils.pbc in Tapir 08:03
08:06 JimmyZ joined
dalek rrot: r43087 | bacek++ | branches/context_unify3/src (2 files):
Remove setting of caller_ctx from Sub.invoke and op get_params.
 08:10
dukeleto hmmmmm, looks like distutils does not have a "pbc_merge" step 08:17
msg fperrad does distutils have a pbc_merge step? should it? or should i define custom distutils step? 08:18
purl Message for fperrad stored.
08:25 iblechbot joined
chromatic always likes seeing bacek delete code. 08:33
bacek chromatic, I hate code. Best program consists of zero lines of code and DTRT.
dukeleto bacek++
bacek btw, I just fixed "no such attribute" problem 08:34
chromatic That should reclaim a lot of tests. 08:35
bacek r43089
Indeed.
chromatic r43088 looks a lot like something I mentioned....
I *think* there are a couple of places where we can't tell the difference between "I have a context" and "I have a call sig" where we used to be able to do so. 08:36
bacek chromatic, I suspect problem is in pushing initial context. But I didn't investigate it
chromatic That could very well be. 08:37
08:37 mikehh joined
bacek sigh... exceptions are badly broken... 08:37
dalek pir: de92d4e | dukeleto++ | setup.pir:
Start porting Tapir to use distutils instead of a Makefile
08:37 fperrad joined
dukeleto fperrad: hola! 08:37
fperrad: i think i need a pbc_merge step in distutils 08:38
fperrad: i have added a basic setup.pir to Tapir, but I need to merge some PBC's
bacek chromatic, hmm... "no such attribute" replaced with "Null PMC access in get_pmc()"... 08:40
fperrad dukeleto, I'll do it 08:41
chromatic I saw that in a few places, especially PGE. 08:42
dukeleto fperrad++ # you rock
dalek rrot: r43088 | bacek++ | branches/context_unify3/src/pmc/continuation.pmc:
Band-aid wrongly created Continuation.
rrot: r43089 | bacek++ | branches/context_unify3/src/ops/object.ops:
Merge CallSignature for tailcallmethod(cc).
pir: 0ada11d | dukeleto++ | TODO:
Update TODO
 08:43
bacek chromatic, real problem is in lexicals. 08:52
chromatic How so?
bacek chromatic, I was wrong, sorry
Parrot_mmd_sort_manhattan_by_sig_pmc
Yay! Even easier.
MustiSub wasn't updated
chromatic Excellent.
That'll reclaim a lot of PIR-only tests.
bacek dcommiting now 08:53
done 08:54
Time for exceptions. 08:55
chromatic You're a madman. 08:56
dalek rrot: r43090 | bacek++ | branches/context_unify3/src/pmc/multisub.pmc:
Update MultiSub.invoke.
 08:59
rrot: r43091 | bacek++ | branches/context_unify3/t/pmc/callcontext.t:
Update CallContext test to use CallContext, not CallSignature
moritz 'make coretest' seems to hang in context_unify3 somewhere 09:04
chromatic I saw that.
moritz but parallel testing is very ill suited for finding out which test hangs :/ 09:05
chromatic We should review all uses of ->current_sig.
Let it go for about a minute (parallel tests take ~28 seconds for me), then killall parrot and see what prints.
It looked like t/op/calling.t or something for me.
JimmyZ chromatic: how to change trac.parrot.org/parrot/browser/trun....pmc#L1209 to use SET_ATTR syntax? it blocked me. 09:06
moritz t/op/exceptions_23.pir
htop++
chromatic Looking now, JimmyZ.
JimmyZ chromatic: Thanks. 09:07
moritz the old-23 too 09:08
chromatic SETATTR_Object__class(interp, object, SELF);
You need 'include "pmc/pmc_object.h";' as well.
You can find the attribute macros in that file: include/pmc/pmc_object.h.
JimmyZ chromatic: src\\oo.c:498: failed assertion 'classobj' 09:09
chromatic: it does like PObj_is_object_TEST(pmc) in SETATTR_Object_attr marco. 09:10
chromatic: s/does/doesn't/
chromatic That part should be fine, but it's probably the VTABLE_set_attr_str() part that hurts.
If that's the case, we can't do it many other ways... or any. 09:12
JimmyZ chromatic: How can I fix it? 09:13
chromatic You'll have to leave it for now. 09:14
It's not ideal.
JimmyZ chromatic: ok, thanks.
chromatic One option is to change Object.init_pmc() to take the class instantiating it. 09:16
That'd be cleaner, but I'd like to ask allison for her thoughts about such a change.
bacek moritz, I'm working on exceptions atm. 09:17
Will fix soon (I hope) 09:18
moritz bacek: I'm not meaning to press you on, just wanted to tell about my experience 09:20
bacek moritz, no worries. 09:21
JimmyZ chromatic: actully, I always plan a better way than GET_ATTR syntax. 09:22
bacek chromatic, "BIG DEAL" - lexicals are bloody broken. Because we are not creating new CallContext in tailcalls anymore 09:27
and Sub/LexPad/CallContext mixture doesn't work anymore 09:28
fperrad with Parrot-1.9.0 & mingw, cannot build Rakudo (master) 09:43
perl6_ops.o:perl6_ops.c:(.text+0x5d2d): undefined reference to `GETATTR_CallSignature_results' 09:44
10:40 payload joined 10:42 lucian joined 11:05 mikehh joined
dalek rrot: r43092 | fperrad++ | trunk/tools/util/pgegrep:
Fix Getopt::Obj to use a keyed namespace
 11:09
mikehh cotto: I am getting a g++ build error related to r43080 as follows: 11:35
config/gen/platform/generic/exec.c: In function ā€˜INTVAL Parrot_Run_OS_Command_Argv(parrot_interp_t*, PMC*)ā€™: 11:36
config/gen/platform/generic/exec.c:109: error: cannot convert ā€˜char***ā€™ to ā€˜char**ā€™ in initialization
I also get the following in the gcc build: 11:37
src/ops/core_ops_switch.c: In function ā€˜Parrot_DynOp_core_switch_1_9_0ā€™:
src/ops/core_ops_switch.c:14014: warning: dereferencing type-punned pointer will break strict-aliasing rules
sorry wrong paste 11:38
config/gen/platform/generic/exec.c: In function ā€˜Parrot_Run_OS_Command_Argvā€™:
config/gen/platform/generic/exec.c:109: warning: initialization from incompatible pointer type
11:41 bacek joined
mikehh pre/post-config, smoke (#30954) PASS - fulltest FAIL at at r43092 - Ubuntu 9.10 i386 (gcc with --optimize) 11:53
t/examples/pir.t - Failed test: 2 in examples_tests
I think this is relatedf to the problem I outlined above - why it won't build with g++ 11:58
got to go out for a bit - bbl
dalek rrot: r43093 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add the key 'pbc_pbc' in order to support pbc_merge
 12:05
pir: e345edf | fperrad++ | t/harness.pir:
Fix Getopt::Obj to use a keyed namespace
 12:09
pir: c7b4f83 | fperrad++ | setup.pir:
now distutils support pbc_merge
12:22 ruoso joined
nopaste "bacek" at 122.110.90.61 pasted "make coretest status on context_unify3 branch" (50 lines) at nopaste.snit.ch/19105 12:34
bacek At least it doesn't hang anymore 12:36
dalek rrot: r43094 | bacek++ | branches/context_unify3 (5 files):
Made tailcall to push new CallContext instead of reusing old one. Apparently we need new CallContext to store LexPad information and other bits
 12:38
rrot: r43095 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] escape JSON strings
12:39 whiteknight joined
moritz do we know how good the parrot GC is? does it miss objects sometimes? 12:51
whiteknight it's possible that it's missing something if somebody has made major PMC changes recently
why do you ask?
moritz just idle curiosity
with the background of where to look if rakudo increases in memory 12:52
whiteknight Parrot's GC is generally very conservative. It has more false positives than false negatives 12:53
12:54 payload joined
nopaste "bacek" at 122.110.90.61 pasted "And more updates on context_unify3 branch coretest" (26 lines) at nopaste.snit.ch/19106 13:06
13:06 payload joined
bacek ok, I'm done for today... 13:06
or even yesterday.
dalek rrot: r43096 | bacek++ | branches/context_unify3/src/ops/core.ops:
Create CallObject for tailcall if it wasn't created early.
 13:11
rrot: r43097 | bacek++ | branches/context_unify3/src/pmc/sub.pmc:
Resurrect old core to setting caller_ctx in Sub.invoke.
rrot: r43098 | bacek++ | branches/context_unify3/tools/dev/mk_native_pbc:
mk_native_pbc actually depends on make "corevm" target, not "all"
rrot: r43099 | bacek++ | branches/context_unify3/t/native_pbc (4 files):
Rebuild native PBC.
13:16 patspam joined 13:19 JimmyZ joined
bacek msg chromatic smolder.plusthree.com/app/public_pr...ails/30968 - corotines are broken. 13:20
purl Message for chromatic stored.
bacek msg chromatic but it looks much better now. 13:21
purl Message for chromatic stored.
whiteknight bacek++
bacek whiteknight, not yet... make all still failing
whiteknight whatever, progress is progress
bacek anyway, $bedtime 13:25
Good night, everybody
13:37 JimmyZ_ joined
fperrad whiteknight, I've seen a setup.pir in PLA, but not in matrixy 13:45
whiteknight fperrad: I may not have pushed it. I've been playing with it locally
fperrad does it work as expected ? 13:47
whiteknight yes. I have some local tweaks to make, but otherwise it's very good
13:49 plobsing1 joined
Coke dalek? 14:12
purl i guess dalek is #parrot's spammy little rss bot or (see: dalek plugins)
14:16 patspam joined, mikehh joined
dalek rrot: r43100 | coke++ | trunk/docs/project (2 files):
Reflect community decision regarding 3-month supported cycle.
 14:16
rrot: r43101 | coke++ | trunk/docs/project/support_policy.pod:
One more historical note to avoid confusion.
rrot: r43102 | whiteknight++ | branches/context_unify3 (3 files):
remove t/pmc/context.t. We no longer have a Context PMC so tests for creatingo one are bad. Fold tests into t/pmc/callcontext.t, though some are commented out for now
rrot: r43103 | whiteknight++ | branches/context_unify3/t/pmc/callcontext.t:
uncomment the inspect tests. These should work in CallContext just like they did in Context (or functionality should exist in some way).
14:24 payload joined
dalek rrot: r43104 | whiteknight++ | branches/context_unify3/t/pmc/callcontext.t:
fix t/pmc/callcontext.t Context attributes are accessed by the getattribute opcode now, not named hash lookup. Hash lookup is for named arguments.
 14:34
rrot: r43105 | fperrad++ | trunk (7 files):
[befunge] update infrastructure with setup.pir (distutils)
14:34 JimmyZ joined
dalek rrot: r43106 | whiteknight++ | branches/context_unify3/t/pmc/parrotinterpreter.t:
ParrotInterpreter[context] returns an object of type CallContext
 14:34
rrot: r43107 | fperrad++ | trunk (8 files):
[abc] update infrastructure with setup.pir (distutils)
 15:22
15:29 jsut_ joined 15:36 bluescreen joined 15:37 Psyche^ joined
dalek rrot: r43108 | fperrad++ | trunk (8 files):
[squaak] update infrastructure with setup.pir (distutils)
 15:38
16:06 bluescreen joined 16:13 payload joined
whiteknight purl msg bacek context_unify3: several files fail (debuginfo.t, file.t) because PDB_backtrace isn't printing out the "current instr.:" line, expected by pir_error_output_like. This fails because ctx->current_sub is Null there for some reason. 16:16
purl Message for bacek stored.
16:16 ruoso joined
Coke whines. 16:21
msg dukeleto does tapir support --exec ? 16:23
purl Message for dukeleto stored.
whiteknight Coke: I believe it does 16:24
never tried it, but I saw it in the source code
moritz without it tapir would be pretty useless for HLL testing 16:26
Coke msg dukeleto nevermind, it does; looks like we could use tapir to test partcl then, if it were installable. 16:27
purl Message for dukeleto stored.
moritz pmichaud: is there a good reason why building nqp-rx in parrot depends on PGE?
Coke (works now if I copy in all the tapir bits into the partcl-nqp build dir)
16:27 darbelo joined
Coke moritz: I would not trust the makefile dependencies further than I could throw them. =-) 16:27
moritz that's why I'm asking 16:28
Coke ponders working on his makefile sanity project.
moritz sanity++ 16:33
dalek rtcl-nqp: 3d9f9ff | coke++ | src/Partcl/commands/main.pm:
make p6.vim happier
 16:35
Coke moritz++ # making irc logs searchable. 16:36
japhb dukeleto, (from last night): You need find_program() in src/lib/Util.nqp 16:37
pmichaud moritz: just forgot to remove that dependency 16:39
darbelo mikehh: ping 16:40
dalek rrot: r43109 | whiteknight++ | branches/context_unify3 (3 files):
t/op/cc_params.t was looking for CallSignature, which doesn't exit. Replace references with CallContext and things work normally
 16:42
dukeleto japhb: thanks! japhb++ 16:44
Coke: yes, Tapir suppports --exec, right now 16:45
Coke: Tapir is now semi-installable. a fakecutable can be generated 16:46
darbelo purl: msg mikehh Does r43110 fix the c++ issues tou were seeing?
purl Message for mikehh stored.
cotto mikehh, is your build still broken? I tried realclean and the build was still ok.
darbelo cotto: I think he's building with g++, that means a mis-cast breaks the build. 16:47
we had one '*' too many in a mem_allocate_n_typed() call. 16:48
cotto ok. I see how that happened.
darbelo I *think* it's fixed by r43110, nut my g++ is too ancient to build parrot. 16:49
nopaste "coke" at 65.91.151.194 pasted "pmichaud - stupid question time" (28 lines) at nopaste.snit.ch/19107 16:50
Coke dukeleto: the fakeceutable is not standalone.
dukeleto Coke: tapir currently uses a Makefile, but as soon as fperrad has pbc_merge support in setup.pir, it will switch over to that 16:51
Coke (it requires the lib dir.)
I have no problem with requiring make. =-)
dukeleto Coke: i think i forgot to make the PBC's installable
Coke: if you don't care about 3 files, just copying t/harness.pir and lib/Tapir/*.pir into your project should work
Coke: and then invoke it as parrot t/harness.pir t/*.t 16:52
darbelo dukeleto: Have you considered getting Tapir imported into parrot?
whiteknight in general, I think it's better to keep it external 16:53
dukeleto darbelo: yes. it will probably happen this month. it will be an external like nqp-rx and live in ext/
darbelo dukeleto++ # Exactly what I had in mind.
dukeleto darbelo: it needs a few more rough edges polished, but is very close
nopaste "coke" at 65.91.151.194 pasted "pmichaud - two more examples" (8 lines) at nopaste.snit.ch/19108
cotto what are the g++ flags for Configure.pl? 16:54
dukeleto Tapir will also be installable via plumage soon, as well
whiteknight --cc="g++" --c++="g++" --link="g++" --ld="g++"
At least, I think that will work
fperrad dukeleto, the support of pbc_merge is already committed in parrot & tapir 16:55
whiteknight --cxx="g++"
Coke tene; oh. 16:56
Tene: I'm using CONTROL_ERROR; I probably expect that to be NOT a control-style, at least from NQP's standpoint. 16:57
fperrad japhb, Plumage is broken with the HEAD of parrot, see r43083 for fix example 16:58
japhb fperrad, I'm a little groggy
what's going on now?
dalek rrot: r43110 | darbelo++ | trunk/config/gen/platform/generic/exec.c:
Correct the allocation size an type for **argv.

This should fix the c++ build as well.		 16:59
cotto darbelo, thanks
dukeleto fperrad: wow!
japhb Sheesh, almost 30 revs since I went to bed? Yikes 17:00
dukeleto fperrad++ # pbc_merge in distutils and Tapir. you rock! 17:01
fperrad japhb, see TT #1372
17:01 nopaste joined
whiteknight fperrad does rock 17:01
japhb definitely 17:02
OK, read ticket.
Now ... has a decision been made? Are we rolling back 43083 or not? 17:03
pmichaud ...who gets to make that call? 17:04
japhb I have no idea. We need some sort of ruling on whether Getopt::Obj was under protection 17:05
pmichaud I'm sure it technically was. Any application or language that uses Getopt::Obj (and there are several) would be relying on its 1.4 behavior.
17:05 theory joined
pmichaud clearly it's one of the parrot libraries. 17:06
japhb Personally, I don't care, I just want to get back to working, so I need to know if I need to change my code or not. ;-)
It would be somewhat annoying that Plumage would cease to work with 1.9 so soon after release, but ... :-/ 17:07
pmichaud japhb: that's normal.
japhb: it's common for changes to occur shortly after release
japhb Yeah, I'm beginning to feel your pain, rather than just empathize with it 17:08
pmichaud or, put another way, what is in parrot HEAD is no longer 1.9
1.9 is what was released
so, if you're asking if plumage works with 1.9, the answer is "yes"
Coke anything in library/ is covered, yes. 17:09
japhb pmichaud, no, I meant, "if we don't roll back, then Plumage will change to support HEAD, and thus plumage HEAD will not work with 1.9 anymore, only parrot HEAD"
Coke japhb: welcome to the club! =)
pmichaud oh, yeah. Rakudo has exactly this problem, which is why we have PARROT_REVISION
japhb Coke, yup
pmichaud because it's never sufficient for us to say "1.9 or later"
japhb nodnod
speaking of which ... 17:10
purl i think speaking of which ... is anyone working on dbdi?
japhb purl, forget speaking of which ...
purl japhb, I didn't have anything matching speaking of which
japhb purl, forget (speaking of which ...)
purl japhb, I didn't have anything matching (speaking of which ...)
japhb sigh
Anyway,
Coke no, speaking of which ... is <reply>
purl okay, Coke.
particle i forgot to mention over the weekend or during parrotsketch... we might try to be coverity-defect-free by 2.0. is it worth the effort?
Coke particle: I don't think so, no. 17:11
that falls under "nice to have" for me.
pmichaud particle: if it didn't steal away from other tasks, perhaps
PerlJam particle: isn't that a transient thing anyway?
japhb At some point the HLLs will need to do something to make sure they all support the same parrot at the same time, like support revision ranges or something. Because otherwise when Plumage tries to depsolve between all the HLLs to find a safe Parrot revision, it's going to come up with nada. 17:12
particle PerlJam: no, there are levels of coverity analysis, if we go defect-free, we advance to the next level of scan
PerlJam Or do you mean, be defect free for the release?
pmichaud in the realm of "parrot runs faster" versus "coverity-defect-free", it's no contest.
particle defect-free for the 2.0 release
dalek rtcl-nqp: 4c8feef | coke++ | src/Partcl/commands/main.pm:
Don't use a CONTROL type for [error]
particle pmichaud: correctness before speed
rtcl-nqp: 6f81dc9 | coke++ | (5 files):
Allow expr's == to fallback to string comparision.
Coke japhb: ha. good luck. =-)
tewk_ particle, who is the coverity admin, can I get an id and passwd.
particle tewk_: i wish i knew, i've tried several times to get id/passwd, and just ended up borrowing whiteknight 17:13
Coke particle: if the HLLs are not triggering the code that coverity is testing, you're right, it's no contest.
pmichaud particle: that's a slightly different form of "correctness". Or, put another way, glacial slowness is a form of bug.
tewk_ particle, I used to have one in the svn.perl.org days but I don't know what it was.
particle what the heck is wrong with static analysis?
anyway, there are only a few defects 17:14
i think we can achieve the next level, which would put us on par with perl and ruby
pmichaud japhb: (HLLs will have to support the same Parrot at the same time) I think you're putting the responsibility in the wrong place.
japhb Coke: well, here's some ideas: 1. supported revision ranges, 2. tag or branch the HLL revision in a computer-identifiable way that works with a given Parrot release (so that Parrot releases can be safe sync points)
particle it says something good about the stability of the vm to achieve defect-free coverity scans
pmichaud particle: to me (as HLL developer), it means that we're targeting the wrong form of stability. 17:15
particle you'd rather be fast and have segfaults?
japhb (By 2., I mean "have the tag or branch name follow a pattern or formula that I can program into Plumage")
PerlJam japhb: and have that introspectable via parrot_config (if it's not already) 17:16
pmichaud particle: most of the effort that has gone into parrot over the past six months has been refactoring existing code to make it more stable. meanwhile, little has been done to improve live for hll developers. to me, that's the wrong priority at this time.
particle i remember when i replaced my 386/33 with a 486/66 how excited i was that i could crash windows 4x faster
pmichaud *life
I'm not saying that segfaults are desirable, but at the same time, other critical parrot needs are going unaddressed.
Coke particle: we already have segfaults. being coverity clean in the past hasn't helped here.
particle pmichaud: i agree, but i don't think it's much effort to go defect-free, and it's a marketing win
Coke particle: then have fun. =-) 17:17
particle coke: we've never been coverity-clean
Coke ok. "addressing coverity in the past hasn't helped."
pmichaud particle: as I said, "if it doesn't steal away from other tasks, perhaps"
particle pmichaud: yes, i'm suggesting that might be the case.
pmichaud I'm not saying don't do it, I'm saying don't do it if it causes our ROADMAP items to suffer.
I'm saying it's not at all a priority for Rakudo*, also.
particle otherwise, i agree, life for hll devs takes precedence
tewk_ fixing/reading coverity reports makes people better C / vm hackers. 17:18
pmichaud it's also been my strong experience that people going in and cleaning up parrot code have also made it slower, as well as broken our deprecation policy. All of that makes things harder for hll devs too.
Coke points to: trac.parrot.org/parrot/report/16
fperrad pmichaud, with Parrot-1.9.0, cannot build Rakudo (master)
perl6_ops.o:perl6_ops.c:(.text+0x5d2d): undefined reference to `GETATTR_CallSignature_results'
pmichaud fperrad: you probably need to do some realcleans somewhere 17:19
fperrad: I tested it just a couple of hours ago and it worked for me
japhb Before these get lost: 17:20
fperrad pmichaud, I use fresh checkout when I work with a released Parrot
pmichaud ...fresh checkout of.... ?
japhb 1. It sounds like the Getopt::Obj change needs to be rolled back. Can someone raise their hand to do that? 17:21
fperrad pmichaud, I want said checkout in new empty directory (not an update)
japhb 2. HLL developers: Would you be averse to tagging or branching a known good rev of *your* repository each month that works with the latest Parrot release? (Kindof reversing the PARROT_REVISION semantics.) 17:22
pmichaud japhb: Yes.
japhb pmichaud, better suggestions then?
pmichaud japhb: I am adamantly opposed to limiting my development to the latest Parrot release.
japhb pmichaud, no, no, just giving some way for Plumage to find *a* rev (other than HEAD) that works with the latest parrot rev. 17:23
pmichaud japhb: I'll put it another way. Given that new changes land shortly after a parrot release, I'm opposed to waiting four weeks to even begin to think about making use of those changes.
17:23 payload joined
pmichaud japhb: oh. we already do this in Rakudo. 17:23
each release is tagged
japhb Otherwise I have no way to say "User just upgraded to 1.9, now I have to update all the HLLs and modules. But which revs do I use?"
pmichaud, and your release is known to work with the latest monthly from Parrot, right. 17:24
pmichaud at any rate, parrot's general philosophy is not to impose too many requirements on hll devs
I'm not sure I want to be maintaining a map of "Parrot revision x.y.z corresponds to tag a-b-c" in my repo, though. 17:25
japhb As long as your tag is obvious, plumage can just compute it, no map. "WORKS_WITH_PARROT_1_9_0" 17:26
pmichaud I don't want to be responding to bug reports from someone who just downloaded Parrot 1.5.0, got the corresponding version of Rakudo, and finds bugs.
japhb OK, that's a fair point. 17:27
japhb is looking for better ideas ... because the problem is a real one, and there needs to be *some* sort of solution
pmichaud the solution is likely for Parrot to actually stabilize for HLL devs.
but I don't know that this will happen anytime soon.
japhb If we want Parrot to move along a little faster, I can't imagine Parrot getting stable in the way you're wanting for a year or two 17:28
whiteknight pmichaud: users reporting bugs against unsupported platforms or against old releases is a fact of the universe
plumage or any other kind of package management solution isn't going to prevent that
pmichaud whiteknight: yes, but the approach that japhb is describing gets the streams backwards (more) 17:29
it would be like the linux kernel trying to keep track of all of the libraries, modules, and applications built on top of it 17:30
japhb ???
That analogy doesn't make sense.
I'm not asking Parrot to do anything
moritz it's more like apt/dpkg, which only intalls linux, libc and user level apps if the version numbers are compatible 17:31
japhb I'm just asking for some way to not hose the user when they change Parrot version
moritz, right
whiteknight Parrot is the base. We have parrot, then we search for a suitable Rakudo version from that
pmichaud who is the "we" doing the searching?
japhb In the apt case, there are several thousand DDs whose job is to figure out which revs match up. We don't have that kind of scale 17:32
whiteknight we the users
pmichaud that's a non-answer
what do you mean by "users" here?
whiteknight end-users
pmichaud you want the end-users to be installing parrot and figuring out which version of each hll to install?
whiteknight I have a linux kernel on my machine, and my packager finds packages that work with it
pmichaud okay, so it's not "end user" then, it's "packager" that is doing the searching 17:33
whiteknight i don't download libc and then try to find a compatible kernel
pmichaud the end user doesn't search
the end user asks the packager to do the search
japhb OK, pmichaud, let's turn it around. User has Parrot 1.8 and a bunch of modules and HLLs installed. They upgrade to Parrot 1.9. What revisions of each module and HLL should Plumage upgrade to? How does Plumage figure that out?
(I can figure out the algorithm for the depsolving. It's getting the data to *feed* the depsolver that I don't have.) 17:34
pmichaud why would someone upgrade to 1.9? that seems backwards to me.
japhb From 1.8?
OK, 2.0 to 2.1
purl 41
pmichaud no, you're missing my point.
Coke pmichaud: let's say they upgrade tcl, which requires a new parrot, which then impacts everything else.
japhb seriously, purl, that's what you're bringing to the table?
What coke said 17:35
pmichaud Coke: yes, your scenario makes much more sense to me.
japhb Now that we have the story, how can we get to a solution?
moritz in Debian, Rakudo would depend on an exact parrot version 17:36
pmichaud seems to me that plumage has to have a map for "parrot-revision-to-hll"
moritz no wait
pmichaud er, parrot-revision-to-hll-version
moritz rakudo would be a virtual package
and rakudo-2009-10, rakudo-2009-11 etc provide 'rakudo'
adn each of those depends on a particular version of parrot 17:37
japhb moritz, it can't be an exact revision unless all the HLLs and modules can *agree* on one. In Debian, usually rakudo would depend on a >= rev or a rev range
Coke japhb: and you are not going to get that with parrot as it exists today.
japhb or that, I suppose, though I haven't seen that very often
pmichaud japhb: which gets back to my point that parrot isn't stable enough for rakudo to depend on a >= rev
Coke the best you can get today is a one-one.
er, 1:1
moritz japhb: rakudo depends on exactly one parrot version
japhb is having a bad morning
pmichaud japhb: it just doesn't happen. It doesn't even happen for a range of more than one parrot. 17:38
Coke japhb: it'll get better by about 3.6 =-)
moritz japhb: likewise firefox usually depends on an exact version of xulrunner
PerlJam Coke++ I was just about to type something like that
moritz s/firefox/iceweasel/
Coke you may find the answer to the question is "if you upgrade tcl, you will break rakudo; sorry."
moritz so when xulrunner gets a security update, iceweasel gets an update too, just to keep compatibility
japhb OK listen, this is why I started the entire discussion by saying "I need to be able to figure out sync revisions of parrot, one revision that all of the HLLs and modules have at least one *findable* revision matching that sync revision of parrot"
Coke japhb: that's not a guarantee, either. 17:39
PerlJam Coke: hopefully though, the answer is "you get two versions of parrot so that both rakudo and tcl continue to run"
Coke I may not have a release that matches 2.0
s/I/partcl/
japhb nod
pmichaud there's nothing that says that hll developers have to follow parrot's release cycle
Coke I mean, sure, we can give you the mappings that exist, but it's is at best going to be 1:1
pmichaud: I think for the purposes of 'finding a version to work with for plumage', we can assume that. 17:40
I don't think plumage wants to be involved with individual svn revisions.
pmichaud Coke: fair enough. I have no idea what the situation is for, say, pynie though.
moritz I don't even know if pynie has releases
pmichaud Coke: I'm saying that some hlls might not have monthly releases
Coke I would say if you can't pin to a release, plumage doesn't figure this out for you.
pmichaud: sure, partcl doesn't.
(I might bother if there was an easy way for people to install them via plumage, though._) 17:41
japhb pmichaud, they don't have to have a release. They just have to tag a rev in their repository to mark it safe.
pmichaud japhb: let's consider APL, then
what release of Parrot is known to work with APL?
japhb blinks
pmichaud what tags would you expect to see in the APL repo?
Coke pmichaud: I don't think it's fair to make him ask the first question. you or I would have to answer that. =-) 17:42
pmichaud Coke: can you answer it?
(I can't)
Coke not without researching.
pmichaud right.
Coke it /is/ answerable, though.
japhb Again, it's not "what release of Parrot works with APL" it's "What release of APL works with a given Parrot release"?
pmichaud japhb: that's my point
japhb And the APL developers have to know that
pmichaud japhb: and I'm saying that we don't. :) 17:43
japhb Ah-ha!
PerlJam sounds insane.
pmichaud so, Parrot 1.9.0 just came out
you're wanting us to somehow know that APL works with 1.9.0
but at the moment we don't really care if APL works with 1.9.0 -- suppose we're targeting 1.4.0 -- the last supported release 17:44
japhb I think I see where this is going
pmichaud we can't tell you "xyz version of APL works with 1.9.0", because there may not be such a beast
PerlJam pmichaud: so the answer to japhb's question is "none"
Coke pmichaud: so presumably if we had any data we'd have rHEAD(APL) works on 1.4.0(parrot)
and that's it. and that's fine.
japhb 'BBQ I hate the deprecation system having gone in so early
Coke we don't have to answer the question for every single version of parrot (though someone could.) 17:45
pmichaud Coke: right. But japhb seems to be wanting us to have tags in the apl repo that do answer that for every version of parrot
japhb Coke, exactly
Coke pmichaud: no, I think you're over-reading.
pmichaud fair enough
Coke japhb: ?
japhb pmichaud, no, I'm wanting "any the HLL knows", so we can feed the depsolver with some info. Right now, it has *none*. 17:46
pmichaud japhb: then why does this information need to live in the hll repos?
japhb I'd be fine with saying "You can only install a new partcl if you uninstall APL or accept that it is likely broken"
pmichaud japhb: look, I'm open to maintaining such a mapping for rakudo -- just let me know what you want it to look like. I'd prefer it *not* to be tags in my repo, though. 17:47
japhb pmichaud, That was my initial *idea* of how to store that information. I was asking for better ideas. :0-(
er
:-)
pmichaud I don't want parrot dictating how my repo needs to be structured.
(or plumage)
japhb It really was just an idea.
Sometimes I think we get too hung up on the problems with a particular suggestion, rather than searching for other bits of the solution space. 17:48
17:48 davidfetter joined
diakopter pmichaud: whatever package manager someone uses (themselves or some software) will need to know (through reading it on a rakudo download webpage, or programmatically in some dependencies manifest) which max backend version will work with that release 17:48
(I'm not being pedantic; just stating the obvious) 17:49
pmichaud diakopter: I don't disagree with any of what you just wrote.
NotFound Did we have a deprecation policy? Then why someone has broke Getopt without a notice?
Coke NotFound: because chromatic said it was ok.
<shrug> was a mistake, it's getting fixed.
pmichaud actually, chromatic said it was okay for SDL
17:49 Andy joined
NotFound Given that SDL doesn't work, no surprise. 17:50
Coke pmichaud: I read it as asking about getopt in the scroll. I could have misread. Anyway, it's a mistake and someone will fix it. =-)
darbelo japhb: Wait, you intend plumage to be able to update parrot?
pmichaud I read chromatic's response as being about the ::'s in SDL libraries. I can also see how it could be read to apply to Getopt as well.
japhb darbelo, yes. It will have to be able to, for the reason that Coke pointed out:
If the user wants to upgrade partcl, that rev of partcl may need a new parrot. 17:51
NotFound I'm fine with the change and can fix Winxed in a moment, but I excpect some sort of formal announcement before doing that.
Coke don't fix it, it needs to be rolled back. =-) 17:52
darbelo You mean my ports tree can upgrade my base system when I tell it to update firefox? Scary.
Coke NotFound: yes. it was a mistake.
japhb You know, the unspoken "other possibility" is for parrot to support being installed a bunch of times on the same system, with different revisions, without stomping on each other.
whiteknight but if you want to interoperate with plumage or any other project, you need to agree on an interface
Coke japhb: that should absolutely be a possibility.
otherwise the answer will often be {NULL SET}
pmichaud in Rakudo's case, it may end up being a necessity, even just for Perl 6. 17:53
japhb Coke, yeah, I was hoping to avoid having {NULL SET} be *always* the answer.
:-(
Coke well then, make sure we can have N different versions installed. =-)
japhb Yeah, I'll get right on that.
What's the emoticon for rolling eyes?
Coke then plumage can say after a year, "hey, you're not using 1.0. Want me to remove it to free up some space?"
mikehh pre/post-config, make corevm/makecoretest, smoke (#30972) PASS - fulltest FAIL at at r43110 - Ubuntu 9.10 i386 (g++ with --optimize) 17:54
t/examples/pir.t - Failed test: 2 in examples_tests
all other test5s PASS
darbelo japhb: If we bundle plumage into parrot, people install parrot X.X (which includes plumage Y.Y) and that plumage only install stuff that works on parrot X.X
NotFound No one wants to free up space these days, on the contrary, people like excuses to but bigger disks systems X-)
Coke darbelo: ... ok, if you install plumage, how does that work?
NotFound s/but/buy 17:55
pmichaud afk, lunch
mikehh darbello: yes to the build - I am not sure if it effects the failing test
japhb darbelo, And here comes the rub: When someone says "plumage upgrade partcl" ... what happens? Does it install a new parrot, and then exec the plumage owned by that parrot?
darbelo japhb: It looks in it's (posibly remote) metadata store for a partcl that can work with that parrot. 17:57
japhb darbelo, right ... and how did we get that compatibility information into the metadata store in the first place?
darbelo Each plumage release can have a different metadata store, I can have six parrots installed inparallel, each with it's own lumage, each with it's own metadata store, each with the lates partcl known to work for that parrot rev installed. 17:58
pmichaud bah
the metadata store can be somewhere that plumage knows where to look 17:59
(and that single metadata store have sufficient information for all versions of plumage)
japhb darbelo, right, fine, the question is: where does that metadata COME FROM? Where does the information about compatibility come from? CAN THAT BE AUTOMATED IN ANY WAY? IF so, how?
Sorry for shouting. I'm just getting frustrated. 18:00
Coke the metadata has to be vetted by a human at this point.
japhb Coke, right, I agree. Who.
darbelo japhb: I don't think you can automate it. You can recruit volunteers to keep it up-to date. 18:01
Coke "someone who cares"
japhb Chicken and egg.
purl So the chicken's looking really pissy, and the egg's sitting up in bed next to her smoking a cigarette. The chicken snarls, "Well, I guess that solves THAT question."
darbelo That's how all package managers work nowadays.
Coke nice, purl.
purl I'm smooth like that
Coke nice, purl.
purl I'm smooth like that
Coke japhb: do you want a sign up sheet? =-) 18:02
I mean, I'll probably be the one to update the information for partcl.
japhb darbelo, we're trying to essentially bootstrap a new package manager into this space. But no one will use it if its unreliable, but it will be unreliable if the HLLs and module authors don't do the vetting (at least at first), and they won't go through the effort if no one is using it.
darbelo japhb: If the very HLL author can't tell what parrot releases he supports, how could plumage even guess at that? 18:03
Coke darbelo: you're agreeing with him. =-)
PerlJam darbelo: I think you can automate it with some sort of smoker-server geared towards collecting the appropriate meta-data. The trick is just getting everyone to register with the smoke-server and having some convention for them to follow and ... etc. :)
japhb Coke, thank you. :-)
darbelo Coke: Sorta, he thinks he can solve it. 18:04
;)
pmichaud darbelo: as an HLL author, I can very quickly say what parrot releases I do support. I can't say anything about parrot releases that may have occurred that I don't support.
Coke pmichaud: that's all we need.
japhb pmichaud, I'll take what I can get, and I mean that quite seriously.
pmichaud or, put another way, I can say which parrot releases I support. I cannot say anything about parrot releases I don't support.
Coke pmichaud: no one expects you to.
japhb Fair enough
NotFound I suppose the HLL author can check that his HLL work witth the parrot version he uses X-)
japhb NotFound, true! 18:05
pmichaud japhb: right, I'm not arguing that point at the moment
japhb: all I need is an idea of what information you need, and where you want it to be located
tagging in the repo doesn't work for me
(unless you can somehow use the tags I already have) 18:06
we already put parrot revision information in our repo, in the build/PARROT_REVISION file
released versions of Rakudo contain the corresponding release number of Parrot in that file
(note "release number" not "revision number")
Coke so someone could backfill a bit of information there. 18:07
darbelo pmichaud: could you possibly extend that file to be a *list* of acceptable revs/releases?
pmichaud darbelo: no. There's not a list.
18:07 Zak joined
japhb darbelo, probably not. Because only one release is ever a match at a time. 18:07
pmichaud darbelo: at any given point in time, I can only guarantee a single revision of parrot.
darbelo pmichaud: A one element list is perfectly acceptable ;)
japhb "at most one", I guess 18:08
pmichaud (note "revision" not "release")
PerlJam pmichaud: released versions of rakudo should contain *both* the release number and the revision number
(in build/PARROT_REVISION)
japhb OK, so: pmichaud, it sounds like if I want that information, your suggestion is to skim the history of the PARROT_REVISION file, look for all the points at which it changes, and import that information into the Plumage metadata to get my map 18:09
darbelo PerlJam: A parrot release might not map to a particular trunk rev.
japhb (I'm not saying that's good or bad, I'm trying to paraphrase)
pmichaud PerlJam: they do contain that information, yes.
Coke japhb: I would instead grab the info from his releases. 18:10
japhb Coke, how do I determine what a release is?
PerlJam japhb: there's a tarball for each one :)
japhb (programmatically)
pmichaud japhb: that's going to be hll-specific, yes?
the mechanism one hll uses for a release may be very different from the one that other hlls use 18:11
same for modules
Coke japhb: his github repo has tags, I assume most of those are from a release.
(I'd grab all the ones #'d 200X-XX)
japhb pmichaud, yes, I was pointing out to Coke that I had no idea how to do some common rule for "this is a release" across all HLLs.
Coke japhb: you can't.
pmichaud japhb: you can't.
japhb I know.
Coke since this is a one time grab, I wouldn't worry about it.
pmichaud japhb: you can propose a protocol by which hlls can make it easier for this information to be made available to plumage 18:12
Coke github.com/rakudo/rakudo/blob/2009-...T_REVISION gets you the last one.
japhb I did propose such a protocol. You said no. So I'm asking for better ideas.
Coke (then you can keep bumping back the date.)
PerlJam maybe a small tool that updates build/PARROT_REVISION and the plumage metadata store.
Coke japhb: it's a one off.
japhb Coke, it's not. It has to happen all through the future. 18:13
pmichaud japhb: I can't really offer better ideas because I don't know plumage's other constraints
PerlJam (build/PARROT_REVISION seems like a good (enough) convention to me)
Coke japhb: the HLL dev is going to have to vet this answer.
18:13 jan joined
Coke so pulling it magically across 100 different projects when they're all going to do it differently anyway is not, IMO worth the time. 18:13
japhb Could all of you agree to use something like build/PARROT_REVISION?
pmichaud but also, keep in mind that this is one of those areas where plumage's goals diverge slightly from hll's goals (more)
japhb Then I can just look at that.
Coke I wouldn't rely on that. 18:14
pmichaud plumage's goal at the moment seems to be to make it easy to install languages and modules *for Parrot*
Coke posit:
I declare that my january release works with 2.0
PerlJam or even "If you include a file called PARROT_REVISION *somewhere* (not necessarily build), your project can be installable/etc with plumage"
Coke 2.3 comes out. it /happens/ to work with my release from january.
pmichaud but the bulk of my users aren't at all interested in Parrot or its requirements. They just want to run Perl 6.
Coke I'm not going to re-release my january release to declare support for parrot 2.3
pmichaud ideally, they want to download rakudo, run some build commands, and start writing Perl 6 code
NotFound Or using 18:15
japhb Coke, that's a completely valid point.
pmichaud (that's the point I was making earlier about APL, fwiw) 18:16
Coke so you /could/ use it for an initial cut, but I don't think it's worth writing the code to do that, when someone is going to have to bless it anyway.
japhb pmichaud, my apologies for not understanding that earlier
Coke (even if that someone is a buildfarm.)
japhb Coke: does that leave us with the idea of some monster smoke test matrix, and look for the local minima? 'Cause that sounds painful. 18:17
nopaste "coke" at 193.200.132.135 pasted "pmichaud: any idea why this causes t/cmd_incr.t and time.t to fail? (or have better suggestions on cleaning up the impl?" (41 lines) at nopaste.snit.ch/19110 18:18
Coke japhb: it is painful. which is why I suggest not bothering trying to automate this.
pmichaud I think the overall point I'm trying to make is that Parrot has not yet reached a level of stability whereby .... what Coke said.
Coke let the HLL do the first approximation, and users can say "hey, this works with <later version>, btw." 18:19
pmichaud it's going to require people who care to manually keep things up to date
make it easy for them to do so
japhb I guess I'm stuck with a problem: The HLLs, if pmichaud is any indication, really don't care to make this easy for Plumage. Which means it will be hard (in the sense of either a LOT of code, or humans (me) doing it by hand). That's ... somewhat suboptimal for me.
PerlJam Coke, pmichaud: or he could establish a convention and encourage people to use it *now* so that the meta-info is easier to gather later :)
pmichaud I care to make it easy for Plumage, if doing so doesn't make it hard on me
Coke japhb: you can automate the data collection, just not the data /vetting/
so give the HLLs a way to submit data to you.
NotFound We can increase our stability level just by not deprecating things before providing working alternatives. 18:20
pmichaud I don't want to offload Plumage's difficulties onto myself :)
Coke s/HLLs/interested parties/
pmichaud NotFound: No, because working alternatives still requires updating the hlls and libraries.
and those may happen on a different time scale
PerlJam Coke: that's why I mentioned a small tool to update build/PARROT_REVISION *and the plumage metadata store* earlier :) 18:21
NotFound pmichaud: yes, but providing it allows an interval of compatibility.
japhb pmichaud, I'm not trying to offload stuff that is "hard" for Plumage. I'm trying to offload stuff that is impossible for Plumage to do without me becoming essentially a metadata manager for the rest of my days.
NotFound Is better than having an empty interval.
PerlJam japhb: not for the rest of your days .... just until you can find some chump^Wvolunteer to take over for you :)
Coke japhb: this metadata needs to live in plumage, somewhere.
pmichaud NotFound: agreed fully.
Coke alongside the metadata you already keep. 18:22
just like, e.g. the macport information about parrot lives in the macport repo, not parrot.
(yes, I know we have a copy, but it's just a copy, and only for our convenience.)
pmichaud japhb: my comment was not intended to say that plumage is trying to push its problems into the hll devs laps 18:23
Coke so, here's a thought: create a new repo that just tracks the metadata.
pmichaud (new repo) that's what I also was implying earlier
Coke then you don't have to update it, but the repo can be the clearinghouse.
PerlJam Coke++ pmichaud++ excellent idea.
Coke you can even git out commit bits to hll authors. 18:24
*give
pmichaud 17:59 <pmichaud> the metadata store can be somewhere that plumage knows where to look
NotFound Coke: macport repo? Not in the Apple store? ;)
Coke cries because he's gong to have to go to the apple store to resurrect 3 dead macs. :|
PerlJam Maybe proto should do the same (that might make it easier for proto to be replaced with something better too)
pmichaud proto already does the same -- it just uses its own repo as the metadata store
(but commits are freely given)
japhb Wait ... so y'all would update your project's Plumage metadata if it just was in a separate repo?
PerlJam pmichaud: right, I'm saying divorce the two 18:25
japhb Or you're expecting the community would?
pmichaud japhb: I'm saying I'll update my projects Plumage metadata if it's not a significant cost to do so.
and if I don't do it, someone else likely will.
Coke yah.
18:25 payload joined
pmichaud there are a few places I don't want the metadata to live (new tags in my repo) 18:25
beyond that, if it's easy for me to keep the metadata up-to-date somehow, then I'll do it 18:26
Coke pmichaud: I snuck in a nopaste to you, btw.
japhb OK, wow. If I'd known that was the blocker, I would have made the "metadata out of plumage repo" a high priority task rather than a low-priority one, a long time ago.
pmichaud if it's hard for me to keep metadata up to date, I won't do it (standard open source applies here)
18:26 bubaflub joined
pmichaud i.e., the value derived from keeping the metadata up to date has to be greater than the cost of doing so 18:27
Coke: I saw the nopaste... I don't have a quick answer
NotFound We can create a 'Best metadata of the year' contest X-)
Coke it's just a slightly expanded version of yours.
pmichaud Coke: I'm thinking that perhaps we should not inline this just yet. 18:28
it's.... messy.
so perhaps take the speed hit for now of a separate dispatch function until we get a few more things worked out.
Coke pmichaud: fair enough. 18:29
japhb pmichaud, what could Plumage do for you that would make it a net win to help plumage?
pmichaud japhb: I need to know what metadata to provide. I need to know where to provide it. 18:30
moritz if plumage brings rakudo users, it's a net win :-)
japhb moritz, :-)
pmichaud At the moment it's easiest if that metadata can live somewhere that Rakudo release managers can easily update it.
japhb pmichaud, OK, fair enough.
pmichaud this probably means it would be nice if it could live somewhere in the rakudo repo 18:31
I don't have a problem with that, depending on where that "somewhere" ends up being
18:31 Zak joined
pmichaud (in the rakudo repo being nice because then the release managers don't have to get separate commits to plumage's metadata repository) 18:31
japhb pmichaud, the convention other projects have used is in plumage/metadata.json or plumage/projectname.json in their repo
pmichaud hmmm, I'm not so sure I like that name, though. 18:32
I need to provide a lot of metadata for projects other than plumage as well, can't we have a standard for that?
similar to parrot's ports/ directory, iirc?
i.e., I don't know that I want a plumage/ debian/ ubuntu/ redhat/ etc. in my top-level repo dir 18:33
Coke: need me to write up a version of the dispatch function to start with? 18:34
(It'll have to be after lunch, though)
japhb pmichaud, it was intended to match 'debian/control' and similar 18:36
pmichaud right... I'm just not a fan of having my root repo cluttered with directories that are really in support of other projects 18:37
s/root repo/repo root dir/
i.e., the directories that are important to me are "build/", "src/", and "docs/"
Coke pmichaud: that would be spiffy. 18:40
pmichaud japhb: I'd also be okay with rakudo having a separate repo just to maintain metadata for plumage and other projects :)
Coke (dir) build/ seems vaguely abusable for this. 18:41
(for plumage in specific)
pmichaud build/ is what Rakudo uses now -- see build/rakudo.spec in the rakudo repo (for building RPMs)
I'm fine with build/plumage.json or build/plumage/...
even better, the create_language.pl tool could automatically populate a plumage metadata file :) 18:42
(and provide the make targets for performing releases and keep that file up-to-date)
anyway, lunchtime here -- bbl 18:44
dukeleto 'ello 18:46
dukeleto is amazed at how the Parrot Roadmap google doc has exponentially grown since I last looked
Coke Parrot Roadmap? 18:47
18:47 japhb joined, Tene_ joined, dngor_ joined, leto_ joined, athomaso1 joined, bubaflub joined, theory joined, darbelo joined, bluescreen joined, jsut_ joined, rhr joined, diakopter joined, cotto_work joined, PacoLinux joined, wayland__ joined, silug joined, tewk_ joined, bacek_at_work joined, dcolish joined, ingy joined, zostay joined, purl joined, spinclad joined, szabgab joined, particle joined, TimToady joined, workbench joined, Ryan52 joined, jjore joined, cxreg joined, estrabd_ joined, frodwith_ joined, treed joined, sjn joined, Maddingue joined, baest joined
darbelo Netsplit-- 18:48
18:48 s1n joined, jhelwig joined
japhb Well, I couldn't respond to pmichaud earlier, but: 18:49
darbelo Ok, we're back on the irclog. 18:50
japhb Plumage doesn't care where you keep the metadata in your repo. It needs to be told *once* where that file will be, and then from then on when you fetch/update it will reload the metadata from the fetched copy.
dukeleto roadmap?
purl somebody said roadmap was trac.parrot.org/parrot/wiki/ParrotRoadmap
japhb (Or rather, that's the behavior it will have later this week or so -- it was always the plan, just needed to be done after the refactors) 18:51
Coke roadmap google doc is spreadsheets.google.com/a/coleda.c...&hl=en
dukeleto purl, roadmap is also spreadsheets.google.com/ccc?key=0Ah...&hl=en
purl okay, dukeleto.
Coke forget roadmap google doc
purl Coke: I forgot roadmap google doc
dukeleto purl, forget roadmap 18:52
purl dukeleto: I forgot roadmap
dukeleto purl, roadmap is icanhaz.com/parrotroadmap or trac.parrot.org/parrot/wiki/ParrotRoadmap
purl OK, dukeleto.
moderator Parrot 1.9.0 "Blue-fronted Amazon" released! | parrot.org | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs 18:53
19:01 confound joined 19:03 payload joined
dalek 9plus: 5407b5e | bernhard++ | .gitignore:
Makefile is no longer generated.
 19:08
rrot: r43111 | tene++ | trunk/compilers/pct/src/PAST/Compiler.pir:
Small fix to remove CONTROL_ERROR from the CONTROL handled types. This API needs more-significant work, but this is enough for now.
 19:09
19:22 chromatic joined, Andy joined, davidfetter joined, patspam joined, cotto joined, KatrinaTheLamia joined, Khisanth joined, Infinoid joined, DrForr_ joined
dukeleto yay for netsplits! 19:26
Coke pmichaud: I just avoided a pain point of mine by elminating the gen/ directory for partcl-nqp; hopefully this won't introduce pain for you.
dukeleto Coke: is that like reverse code acupuncture? 19:27
dalek rtcl-nqp: 3286c67 | coke++ | build/Makefile.in:
strip out unused items.
 19:28
rtcl-nqp: 3a031e8 | coke++ | (4 files):
switch from putting generated PIR in gen/ to using a SUFFIX rule.

  * the .pir files aren't being installed, they're being .included
  * puts generated PIR near the NQP that generated it. (con for some)
19:30 Khisanth joined, davidfetter joined, chromatic joined, cotto joined, patspam joined, KatrinaTheLamia joined 19:31 payload joined
Coke ponders what <nibbler> and <termish> are for in partcl-nqp's ARE grammar. 19:31
19:32 Zak joined
dalek rrot-plumage: b68c463 | darbelo++ | src/plumage.nqp:
Change the dprecated ['parrot';'Getopt::Obj'] to ['parrot';'Getopt';'Obj'] notation for Getopt.
 19:37
purl dalek: that doesn't look right
PerlJam Coke: How would you write it without them? :)
japhb darbelo, I thought we agreed earlier that the Getopt::Obj change was going to rolled back? 19:40
Or was that reversed again during one of the netsplits?
darbelo japhb: really? I missed that. 19:41
japhb Lots of people complained.
I'm guessing no one actually did the rollback yet, though
dalek rrot: r43112 | fperrad++ | trunk (4 files):
[distutils] now, works in a build tree
 19:42
darbelo I think I saw something about keeping both names and depreacting the old one yesterday when it was first brought up.
dalek rrot-plumage: 60794cc | darbelo++ | metadata/hq9plus.json:
Add metadata file for hq9plus.
japhb Oy, Vey. 19:43
darbelo Which is the sane startegy if you ask me. You anounce that 'X' won't be available tomorrow, and provide the alternative today.
japhb Well, if you've got Plumage working again, great. We can always fix plumage again if the rollback happens
darbelo, the problem was that it wasn't "both" now, it was just changed. 19:44
19:45 Infinoid joined, japhb left, japhb joined
Coke PerlJam: I can't write it /with/ them, so it's not entirely a fair question. =-) 19:45
yes. that change must be rolled back. 19:46
adding a copy that's the new would be very nice.
19:50 zak_ joined
pmichaud returns 19:54
19:59 lucian joined, iblechbot joined 20:01 ruoso joined 20:07 payload joined
pmichaud phone 20:07
20:09 patspam1 joined, bacek joined
Coke pmichaud: ENOPHONE today. 20:17
(for me. will catch you next week.)
20:32 whiteknight joined
bacek Good morning 20:47
whiteknight++ # fixing context_unify3
dukeleto bacek: good moroning 20:48
bacek wonder when purl changed name to dukeleto 20:49
Tene_ I'll go roll back the getopt change and put in a non-breaking version... someday. 20:51
dukeleto bacek: purl wishes she could be as cool as me 20:52
darbelo Tene_: Can't we just put a copy of the old file under a different name and .inlude it from the new one? 20:53
whiteknight bacek: I needed to do more, but I had a few spare moments
bacek whiteknight, your comment about interp->sub was very helpful. Now I know where to look. 20:54
Tene_ darbelo: dunno. I feel kind of stupid having two copies in the repo. The fix I'd like to see is copying the two namespaces into their old names and the old classes being made from the :load sub, I guess. 20:56
dalek kudo/master: 98b3f18 | chromatic++ | build/PARROT_REVISION:
Updated PARROT_REVISION for Parrot release 1.9.0.
 20:57
Tene_ I guess that would work, though.
Coke doesn't have to be high tech. just needs to last through the 2.0 release.
(after which it can be immediately ripped out. 20:58
dalek rrot-plumage: e516d05 | japhb++ | metadata/xml.json:
[METADATA] Update xml.json; fperrad++
 20:59
rrot-plumage: 01f22a5 | japhb++ | README:
[META] Bring OVERVIEW section in README more in line with current status of Plumage
rrot: r43113 | tene++ | trunk (11 files):
Revert "Fix Getopt::Obj to use a keyed namespace"
 21:03
Coke tene++ 21:05
chromatic I thought commit numbers always started with r!
Tene_ ack, I forgot to remove the "this reverts commit ..." line. 21:06
moritz that has is a bit useless when there's no canonical git repo
Tene_ sorry.
moritz s/has/hash/
chromatic Just teasing. 21:07
japhb darbelo, care to do the honors to Plumage again? :-) 21:09
Coke pmichaud: chaud++ 21:10
er...
pmichaud++
darbelo japhb: Ok, I'm on it... 21:14
japhb darbelo, thanks! 21:15
21:22 joeri joined
bacek yay! 21:26
darbelo bacek++
bacek "make all" works on branch
chromatic PGE builds?
darbelo dammit I forgot to push to Gitorious. 21:27
bacek chromatic, yes
darbelo japhb: Ok. pushed.
chromatic Now comes the fun part.
bacek chromatic, running test now
japhb darbelo, thank you, rebuilding world
bacek ho-ho-ho 21:29
nopaste "bacek" at 122.110.75.223 pasted "test summary on context_ubify3 branch" (16 lines) at nopaste.snit.ch/19115
dalek nxed: r268 | julian.notfound++ | trunk/winxedst0.cpp:
quick fix for non-pmc attributes
 21:30
21:30 patspam joined
bacek smolder.plusthree.com/app/public_pr...ails/30976 same on smolder 21:31
dalek rrot-plumage: e4cae47 | darbelo++ | src/plumage.nqp:
Change ['parrot';'Getopt';'Obj'] back to ['parrot';'Getopt::Obj'] notation for Getopt.
purl dalek: that doesn't look right
bacek 12,109 ok, 6 failed, 274 todo, 622 skipped and 0 unexpectedly succeeded 21:32
On this positive note I'm departing to $dayjob
chromatic Only six failures. That's very reasonable.
21:35 bacek joined 21:36 mikehh joined
dalek rrot: r43114 | bacek++ | branches/context_unify3/src/call/context.c:
Put workaround into init_context to avoid reinitilising Coro context.
 21:36
rrot: r43115 | bacek++ | branches/context_unify3/src/pmc/coroutine.pmc:
Fix Coro invoke to pop freshly pushed Context
kudo/master: 26251f5 | chromatic++ | docs/announce/2009-12:
Added initial release announcement, with obvious places for additions.
 21:37
kudo/master: 34895f9 | moritz++ | docs/announce/2009-12:
[docs] deprecation notcies for release: Object -> Mu, undef is gone
 21:49
rrot-plumage: 424be23 | darbelo++ | src/Makefile.in:
[MAKEFILE] Make 'test' dpepend on 'all' so make doesn't start testing before everything gets built.
 22:15
japhb *chuckle* 22:17
Things you don't notice if you don't parallel make.
dukeleto japhb: :) 22:18
japhb suddenly remembers ... now that Tene has implemented =>, we can do setup.nqp! 22:19
Tene_ Yes! The one patch i wrote last night that didn't break anything!
darbelo japhb: I wasn't doing a parallel make, it's a "Thing you don't notice if you don't use GNU make." ;) 22:20
japhb Tene, sorry I haven't gotten tests in for you. I've been swamped.
Tene japhb: don't worry about it.
dalek nxed: r269 | julian.notfound++ | trunk/winxedst1.winxed:
operator '.' for method calls and related fixes in stage 1
 22:22
nxed: r270 | julian.notfound++ | trunk/Makefile:
more passing tests in stage 1
kudo/master: 036536a | jnthn++ | src/ops/perl6.ops:
Chase a Parrot change that broke our junction auto-threading code.
 22:34
kudo/master: c4b4110 | chromatic++ | t/spectest.data:
Skipped a few tests which don't pass with Parrot 1.9.0; will revert after the
purl NO! it will ESCAPE and leave behind a bloddy trail of QA
kudo/master: 73c4a80 | chromatic++ | docs/announce/2009-12:
Merge branch 'master' of git@github.com:rakudo/rakudo
22:36 nopaste joined 22:50 joeri left 22:51 nopaste joined
dalek nxed: r271 | julian.notfound++ | trunk/ (2 files):
member var creation and some related fixes in stage 1
 22:56
dukeleto i would greatly appreciate feedback on this blog post that I co-wrote with Brian Wisti: coolnamehere.com/geekery/parrot/lea...-more.html 22:59
it is a Test::More tutorial for Parrot
chromatic reads fine to me, dukeleto 23:01
japhb darbelo, plumage seems back to life, thank you 23:04
dukeleto chromatic: awesome
NotFound dukeleto++ 23:05
dalek kudo/master: 1d44f48 | chromatic++ | src/ops/perl6.ops:
[ops] Fixed a C++ compilation warning with an appropriate typedef.
 23:08
23:10 TonyC joined 23:12 cotto_work joined 23:13 payload joined 23:27 diakopter left 23:28 kid51 joined 23:36 hercynium 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!