Parrot 1.8.0 Zygodactyly released | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang
Set by moderator on 2 December 2009.
tewk It has been a long time but, why does a sub have a ctx pointer? 00:03
dalek p-rx: 2f65563 | pmichaud++ | (3 files):
Initial version of smartmatch operator.
 00:06
cotto_work That'll be shiny
japhb oooh 00:07
cotto_work The longer I put off using nqp-rx, the better it gets.
00:07 tetragon joined
chromatic I put off using it until it has documentation, in hopes that the documentation will get much better. 00:07
cotto_work and ideally, faster
chromatic I have THAT hat downstairs. Everyone voted. 00:08
cotto_work if either happens, I'll be happy. 00:11
chromatic Yesterday should have helped. 00:12
pmichaud sub has a ctx pointer so that "capture_lex" can grab the correct context from an outer sub
chromatic I'm still not sure why that doesn't harm recursion. 00:13
pmichaud it's only used at initialization -- once a closure has been created it already knows its outer context
i.e., we don't use the ->ctx pointer to look up the outer stack -- that chain is already in the context once it's initialized 00:14
chromatic Do we even need to store it in the sub itself?
tewk ctx is runtime state though right, I think of the sub as compile time info,
pmichaud it's possible we don't, but when we call "capture_lex" on an inner sub it needs to be able to find the context of its outer sub 00:15
dalek tracwiki: v5 | cotto++ | WhyDoesNQPGenerateInefficientCode
tracwiki: trac.parrot.org/parrot/wiki/WhyDoe...ction=diff
pmichaud the "current context" of its outer sub, that is.
chromatic My naive assumption is that that's its calling context.
pmichaud not always.
tewk pmichaud, agreed but it seems that it should do that through the continuation chain.
pmichaud tewk: if you mean "caller chain", that doesn't work in some situations. See the long discussion between myself and Bob Rogers from Summer 2008 about why. 00:16
chromatic I'd like to find some mechanism that doesn't store call information in the Sub PMC itself. 00:17
tewk but by placing ctx in sub you can't use the sub in two simluteous threads of execution.
pmichaud keep in mind that the existing code is adaptation of previous code that was very broken 00:18
I felt a bit limited in terms of the number of core changes I could make to get *something* that worked.
tewk I understand I'm just trying to understand how we can improve it.
pmichaud it may be easier now that our contexts are PMCs
chromatic Sure, no one thinks that the current situation is ideal.
Merely that it passes its tests, which is a fine enough thing.
pmichaud the tricky part is when we call an inner-sub when its outer sub hasn't been invoked yet. 00:19
in Perl, the situation is one of { my $x; our sub xyz() { say $a; } }
er 00:20
{ my $x; our sub xyz() { say $x; } }; xyz();
er
(argggh)
xyz(); { my $x; our sub xyz() { say $x; } };
in this case, the caller is not the outer sub. 00:21
chromatic There's a static, compile-time lex pad there then.
pmichaud except that Parrot doesn't support compile-time lexpads
so we have to create one on the fly... and then we have to have something to attach that lexpad to. The only thing available (afaik) is the sub itself. 00:22
chromatic Attaching a compile time lexpad to the sub seems fine in this case.
pmichaud that's what ->ctx is for, then.
but if we do 00:23
xyz(); { my $x; our sub xyz() { say $x; } }; xyz();
the $x we see in the second xyz() isn't the same as the one from the first xyz()
in both calls to xyz(), though, the caller is not the outer context.
chromatic change that declaration to 'my $x = 77' and what do you expect it to print? 00:24
purl chromatic: that doesn't look right
pmichaud I expect the first one to be printing undef, the second prints 77 00:25
chromatic Me too. 00:26
pmichaud ...and that's what the current code. Invoking the block causes its ->ctx to point to the new context of the invocation
it also does a "capture_lex" on the lexically nested xyz sub so that it now points to the new context 00:27
chromatic Is part of the problem that we have to create an anonymous sub to represent the external context?
pmichaud anonymous context, yes.
oh, wait
(misread your question) 00:28
that might be part of the problem, yes. We do have to have something to represent the outer scope, though, yes.
chromatic I should have written "outer context".
pmichaud so far lexical scopes in Parrot are intimately tied to Parrot subs
but I can certainly change the code to 00:29
chromatic If we had a way to create a compile-time lexical scope without forcing the use of an anonymous sub, would that help?
pmichaud xyz(); our sub abc() { my $x; our sub xyz() { say $x; } }; xyz();
...and then we still need the Parrot Sub.
I have a feeling that being able to create a copmile-time lexical scope might not completely be the answer here, no. 00:30
I'd need to think about it a bit.
chromatic That case is a little more complicated. 00:31
pmichaud It's possible that we could use the ->ctx pointer to _only_ refer to compile-time lexical scopes though
chromatic It depends on how often xyz binds.
pmichaud that would help a lot.
chromatic That's what I'm getting at.
pmichaud I'd need to think about it just a bit more.
What is really nasty-ish is that a "capture_lex" operation needs to be done on all inner scopes as soon as an outer scope is entered 00:32
but there's not an easy way to query a sub for all of its inner scopes
chromatic Right. That makes me think the design could use some improvements.
pmichaud Oh, likely so. Jonathan and I briefly explored ways for a sub to be able to find all of its inner subs, but we decided that was particularly messy. 00:33
that said, we might not need to do that now.
(more)
since PCT is generating explicit capture_lex operations, and those operations always take place from the outer scope, it's possible that we could tie those to the current caller instead of the sub's ->ctx pointer
leaving the ->ctx pointer to be used only when an inner sub hasn't been capture_lex'd yet. 00:34
chromatic Right.
pmichaud however, that implies a tighter coupling between Parrot and PCT's code generation than currently exists
the current code works even when someone fails to do a capture_lex operation. 00:35
in short, we'd need a deprecation cycle for it (or an explicit decision to ignore deprecation in this case)
(and keeping the ability to have current code working w/o explicit capture_lex is partially what led to the current use of ->ctx in the first place, iirc) 00:36
tewk but subs are really reified bytecode, they should be read-only
chromatic I'm willing to categorize code that works without capture_lex as fortunate and buggy.
or buggy but fortunate 00:37
pmichaud tewk: they almost *cannot* be completely read-only
chromatic where numification reduces that string to merely buggy.
pmichaud tewk: at runtime we have to be able to dynamically modify sub's outer contexts.
*subs'
chromatic: I'm willing to categorize it that way also.... but there could easily be a fair bit of existing code out there that relies on the buggy behavior. (This is more than a darkpan argument... I'm the author of some such code.) 00:38
chromatic The current deprecation and support policy and timeline tend to preclude the existence of unknowable darkpir. 00:39
pmichaud I don't quite follow that statement.
chromatic I don't think any darkpir exists.
I'm not sure how it could. 00:40
pmichaud okay.
tewk I'm thinking about it from a parallelism point of view, you want to share as much readonly data as you can and seperate mutable data into separate structures.
pmichaud I know there is pir that will break if we were to enforce the capture_lex requirement. It might not be completely dark.
I don't know how much pir would break. I know it's greater than zero but it may be ultimately very small. 00:41
one could find it fairly quickly by searching for :outer in the PIR sources, though (and it's okay to skip code generated from PCT, as that's known to be either correct or easily fixed)
chromatic I don't want to get in the habit of delaying obvious and mostly obvious bug fixes because they may break code which accidentally worked... 00:42
pmichaud tewk: I agree, the current situation is LTA from a parallelism point of view. My point is that with Parrot's current design, "outer scope" isn't static.
chromatic ... especially if we can find and fix that code with reasonable ease.
pmichaud I'll be happy to create a branch that uses ->ctx only for compile-time lexpads. 00:43
and then we can see what breaks.
that part shouldn't be a difficult change. 00:44
chromatic I'd like to see what happens there, if you think it's valuable in the near future.
pmichaud well, it could significantly improve gc
chromatic I'm not certain it's hurting, but if it's a short experiment to find out, I'm happy to know for sure.
pmichaud because right now we keep around contexts long after they've existed, including all of their callers and outers, and including all of the PMCs referenced by their callers and outers (and all of the PMCs referenced by those PMCs...) 00:45
s/existed/exited/
have to go to a concert -- bbl
00:58 tetragon joined, lucian joined 00:59 abqar joined
bacek_at_work chromatic, ping 01:04
chromatic pong
bacek_at_work do you spare couple of hours to fix last bug in cs_csr_merge branch?
do you have
chromatic Not tonight, but perhaps tomorrow. 01:05
bacek_at_work ok, I'll try to fix tonight
01:17 brrant joined 01:33 nopaste joined 01:42 JimmyZ joined
JimmyZ hello chromatic. 01:54
chromatic Hello.
01:54 lucian joined
JimmyZ nopaste? 01:54
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
nopaste "JimmyZ" at 61.144.177.28 pasted "Using GET_ATTR syntax for chromatic" (498 lines) at nopaste.snit.ch/18937 01:55
01:55 japhb joined
JimmyZ Is it the correct way? 01:57
chromatic Yes. Be careful that you undid a change to Hash's init() there though. 01:58
01:59 TonyC joined
JimmyZ where? 02:00
Hash *registry ?
chromatic init().
The first hunk of the patch.
JimmyZ yes, I could find where it is used. 02:02
s/could/could not
chromatic - SELF.set_pointer(registry); 02:03
I'd rather see code removal in a separate patch, so we can verify it.
JimmyZ yep, so I will separate it. 02:04
chromatic Thanks!
JimmyZ svn doesn't has a good way to separate though. 02:05
02:07 bacek joined 02:13 Coke_ joined, Coke left
dalek rrot: r42867 | pmichaud++ | branches/dectx:
Create a new branch to experiment with sub->ctx pointer a bit.
 02:28
02:33 mikehh_ joined, theory joined 02:43 plobsing joined
pmichaud purl message chromatic There appears to be a big stumbling block to eliminating sub->ctx . Without it, I don't see a way to implement a lexically scoped eval() given Parrot's other compilation/:outer constraints. 02:46
purl Message for chromatic stored.
Coke NYS-- 03:01
pmichaud purl message chromatic on second thought... we _might_ be able to do it, but it involves either adding an extra method to sub (to set its outer_ctx), updating capture_lex (to follow the caller chain looking for an outer sub), or updating Sub.invoke to follow the caller chain. 03:04
purl Message for chromatic stored.
dalek kudo: 7914ca3 | (Solomon Foster)++ | src/setting/Rat.pm:
Use Rat::gcd to make infix:<+>(Rat, Rat) and infix:<->(Rat, Rat) yield Rats in more cases.
 03:06
03:35 bacek joined 03:43 nopaste joined 03:46 mikehh__ joined
Coke pmichaud: message sent. 03:46
purl Message for sent stored.
03:46 TonyC joined
sent messages? 03:46
purl To access purl's messages, msg me with the word "messages".
Coke finds a gramatical error 2s after hitting send. *sigh* 03:47
03:58 nopaste joined 03:59 xenoterracide joined
dalek tracwiki: v6 | coke++ | TracSpammers 04:06
tracwiki: trac.parrot.org/parrot/wiki/TracSp...ction=diff
tracwiki: v7 | coke++ | TracSpammers 04:09
tracwiki: trac.parrot.org/parrot/wiki/TracSp...ction=diff
Coke removes trac spam. bozos. 04:14
dalek rtcl-nqp: 1b98037 | (Will Coleda)++ | TODO:
add a note on the t/cmd_for.t failure...
 04:21
04:25 mikehh joined 04:28 TonyC joined 04:33 TonyC joined 04:34 bacek joined 04:38 nopaste joined
dukeleto 'ello 04:39
cotto h' 04:50
It's not really pronounceable, but it cancels out nicely. 04:53
Coke++ for the spam deletion. I don't think there are too many brides around surfing the tt queue. 04:54
05:05 hercynium joined
cotto Coke, can you bulk delete comments? 05:14
JimmyZ hello, cotto. Could help me for some questions? 05:29
It's about pmc class. 05:30
dalek TT #1344 created by kurahaupo++: documentation spell-checking 05:34
cotto I can try. 05:35
JimmyZ cotto: I saw some PMCs(such as bignum.pmc) must be used PMC_data(self) = mem_allocate_zeroed_typed(Parrot_BigNum_attributes); for init. othwise, the test failed. 05:38
why?
cotto: bigint.pmc doesn't need. 05:39
s/othwise/otherwise/ 05:40
cotto afaict, it's cheating. Since it only needs space for a pointer, it just uses PMC_data(SELF) directly.
nm. I think I misunderstood. 05:42
JimmyZ cotto: we're using GET_ATTR syntax.
cotto PMCs that don't declare auto_attrs need to manually allocate their ATTRs.
JimmyZ so we don't need PMC_data
cotto: bigint doesn't declare auto_attrs 05:43
cotto right, so it does the allocation manually
JimmyZ cotto: I couldn't find where it does. 05:44
cotto the GET_ATTR doesn't care if the ATTR struct is allocated manually or not, as long as it hangs off PMC_data()
plobsing JimmyZ: doesn't it do it in bigint_init()?
cotto bigint_init
JimmyZ oh, should we re-add auto_attrs for them? 05:46
cotto I don't think it'd hurt.
It's not necessary though. 05:47
JimmyZ since we're going to use GET_ATTR syntax and avoid PMC_data syntax.
oh ,should say PARROT_$pmcname syntax. 05:48
cotto That'd be a good idea. 05:49
dalek TT #1345 created by plobsing++: [PATCH] eliminate {push,shift}_opcode_pmc from pmc_freeze 05:50
cotto There needs to be a "mark user as spammer and delete all comments by user" button. 05:51
JimmyZ cotto: but MakeEveryPMCAnObject suggest removing the auto_attr syntax, such as context.pmc
oh 05:52
Did I misunderstand?
cotto That's a proposal that needs further discussion, not an agreed-upon implementation goal. 05:53
JimmyZ cotto: thanks 05:55
cotto Wiki organization is not our strong point right now.
JimmyZ I see. 05:56
cotto plobsing, I like where your patches are going. 05:57
15-20 more of those and freeze/thaw won't be entirely insane. ;)
plobsing I see a problem in how freeze/thaw relates to subs that appears non-trivial. I would appreciate advice. 05:58
cotto I suspect that it'll go over my head real fast. 05:59
plus I need to do some late-night shopping 06:00
plobsing who should I direct my questions towards?
cotto chromatic would be good 06:02
possibly bacek
JimmyZ and thanks to plobsing
plobsing cotto: thanks, I'll bug them when I see them 06:03
dalek TT #1346 created by jimmy++: [patch]Removed unused macro in pobj.h, reordered codes in args.c 06:30
06:31 nopaste joined, hachi joined
cotto plobsing, pmichaud might know something too 06:39
allison definitely would, but she's not here as often
dalek rrot: r42868 | cotto++ | trunk (2 files):
[freeze] when pushing/shifting to/from an IMAGE_IO, don't dress up an INTVAL as a PMC*
TT #1345 closed by cotto++: [PATCH] eliminate {push,shift}_opcode_pmc from pmc_freeze 06:40
cotto time for sleeeeeeeeep 06:48
JimmyZ good night, cotto.
dalek TT #1347 created by jimmy++: [patch]removed unused codes in addrregistry.pmc 06:50
TT #1348 created by jimmy++: [patch]changed addrregistry.pmc to use GET_ATTR syntax
TT #1349 created by jimmy++: [patch]changed arrayiterator.pmc to use GET_ATTR syntax 06:56
07:03 uniejo joined
dalek TT #1350 created by jimmy++: [patch]changed bigint.pmc to use GET_ATTR syntax 07:03
Coke I would appreciate it if I had a way to report trac spammers with gmail addresses to google. 07:05
cotto: can't bulk delete, but can individually delete. I see there are more that I missed before or that didn't come through until later. Will clean them all up tomorrow. 07:06
07:10 theory joined
dalek TT #1351 created by jimmy++: [patch]changed bignum.pmc to use GET_ATTR syntax 07:20
07:27 brrant joined 07:51 bacek joined 07:53 mikehh joined 08:19 iblechbot joined
dukeleto plobsing: i am very close to fixing coretest 08:23
dalek TT #1352 created by dukeleto++: [RFC]: Realtime garbage collector for RTEMS
dukeleto plobsing: i was actually 1 test away from being done at the coffee shop and I let a cute girl borrow my power supply, so I had to shut down. decisions, decisions. 08:24
plobsing: anyway, it should be fixed shortly
mikehh dukeleto: what tests are failing? and where? 08:34
davidfetter dukeleto, did you get the digits? 08:37
dukeleto hola 08:40
davidfetter: i gave her my alphanumerics
davidfetter: it was actually a cute girl that i knew in college on the east coast, and we end up bumping into each other and living 5 blocks or so from each other on the west coast. crazy. 08:41
davidfetter heh 08:42
dukeleto mikehh: "make corevm; make coretest" fails due to tests in t/dynpmc/* using test_more.pir functions that need PGE
is t/dynpmc/*.t generated or something?
i modified a bunch of tests in t/dynpmc/*.t and they do not show up in "svn diff". what gives? 08:44
mikehh All tests PASS (pre/post-config, smoke (#30503), fulltest) at r42868 - Ubuntu 9.10 amd64 (g++ with --optimize) 08:45
dukeleto Properties on 't/dynpmc': svn:ignore 08:46
mikehh got to take my grandsons to school (only 5 min away) - bbiab
dukeleto Why does t/dynpmc have a svn:ignore property?
mikehh++ 08:47
whoa, lots of directoris in t/ have svn:ignore, what the junk is going on? 08:48
dalek TT #1353 created by dukeleto++: svn:ignore-ing too many things in t/ 08:53
08:56 bacek joined 09:17 TonyC joined 09:20 abqar joined 09:27 bacek joined 09:29 integral joined 09:32 chromatic joined
JimmyZ good morning, chromatic 09:36
chromatic: I had created some ticket :) 09:40
dukeleto chromatic: hola 09:42
dalek rrot: r42869 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] update dependencies doc
chromatic Very nice. 09:46
JimmyZ chromatic: If they're correct, I will do the next. 09:47
chromatic I'll review them in the morning. 09:48
JimmyZ thanks 09:49
10:01 fperrad joined 10:15 JimmyZ_ joined
dalek TT #1354 created by jimmy++: [patch]removed unused codes from Vtable.pm 10:19
10:22 mikehh joined
dukeleto does anybody know why various directories in t/ are svn:ignored? 10:34
10:36 bacek joined 11:08 fperrad joined 11:09 fperrad_ joined
bacek dukeleto, ping 11:30
11:31 gaz joined
dalek rrot: r42870 | bacek++ | branches/cs_csr_merge/src/pmc/callsignature.pmc:
Initialize new fields in CallSignature
 11:33
moderator Parrot 1.8.0 Zygodactyly released | cs_csr_merge branch need testing! | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang 11:37
dalek rrot: r42871 | bacek++ | failed to fetch changeset:
Fix merging CallSignature for tailcall
 11:37
rrot: r42872 | bacek++ | branches/cs_csr_merge/t/native_pbc (2 files):
Partially rebuild native PBCs
bacek trac is almost dead...
dalek TT #1355 created by bacek++: tools/dev/mk_native_pbc is broken 11:44
dukeleto bacek: yo 11:49
bacek dukeleto, care to test cs_csr_merge? 11:50
dukeleto bacek: checking out the branch now 11:51
bacek: do you know why various directories in t/ are svn:ignored?
bacek dukeleto, no idea. I don't understand why anyone uses svn. 11:52
dukeleto bacek: good answer
purl i guess good answer is "yes, but i guess crysflame is mistaken."
dukeleto purl, forget good answer 11:53
purl dukeleto: I forgot good answer
dukeleto purl, good answer is "up your nose, with a rubber hose!"
purl OK, dukeleto.
11:53 payload joined
dukeleto trac is so f'ing slow 11:54
bacek dukeleto, (packfile tests will fail in branch. 'cause of TT#1355)
dukeleto and so is this svn checkout
bacek svn is always slow
11:56 payload joined 12:06 ruoso joined
dalek TT #1355 closed by bacek++: tools/dev/mk_native_pbc is broken 12:08
rrot: r42873 | bacek++ | trunk (3 files):
Made mk_native_pbc self-contained.
 12:09
12:10 cghene joined
dukeleto bacek: compiling and testing cs_csr_merge now 12:10
moritz dukeleto: could you please also check if rakudo compiles with it? 12:11
pmichaud good morning, #parrot 12:13
dalek rrot: r42874 | bacek++ | failed to fetch changeset:
Bring branch up-to-date with trunk.
rrot: r42875 | bacek++ | branches/cs_csr_merge/MANIFEST:
Update MANIFEST...
dukeleto moritz: i will try that now 12:16
dalek rrot: r42876 | bacek++ | branches/cs_csr_merge/src/call/args.c:
Use ASSERT_ARGS in new functions.
 12:17
dukeleto moritz: compiling on the cs_merge branch now
bacek: everything passes other than packfile tests 12:18
bacek: on darwin/x86
bacek dukeleto, your branch is outdated :)
dukeleto, try r42878
dukeleto bacek: smolder.plusthree.com/app/public_pr...ails/30515
bacek dukeleto, make test passed on my box 12:19
dukeleto bacek: i am going to try rakudo on r42872 first
bacek dukeleto, ok
dukeleto moritz: i see some warnings from "perl6.ops" but "make test" passes on rakudo with r42872 12:20
moritz ok, great
dalek rrot: r42877 | bacek++ | branches/cs_csr_merge/src/call/args.c:
Fix some ARGIN guards to allow NULLs
 12:21
rrot: r42878 | bacek++ | branches/cs_csr_merge/t/native_pbc (2 files):
Rebuild native PBCs.
dukeleto moritz: i am running spectest now
moritz: that will be a while :)
bacek dukeleto, it will take about half an hour.
12:21 payload joined
dukeleto bacek: tell me when you are done committing and i will test more :) 12:21
bacek dukeleto, I'm done. Running fulltest now 12:22
dukeleto bacek, moritz: ok, killing my spec test, updating to latest on cs_csr_merge and then testing both parrot and rakudo on that 12:23
bacek dukeleto, ok.
dukeleto bacek: lots of warnings in ./src/pmc/callsignature.pmc: In function ‘Parrot_CallSignature_set_integer_keyed’: 12:24
bacek: that is no good
bacek dukeleto, nopaste?
dukeleto bacek: gist.github.com/248115 12:25
bacek dukeleto, interesting... I didn't touch this code. 12:26
dukeleto bacek: i have actually been getting some of those warnings before. not the clone warning though 12:27
bacek: i think they multiplied, tho
bacek: it is not a blocker, just something to note
bacek dukeleto, "clone_cell" was introduced by YOU! :) 12:28
dukeleto bacek: the file "t/pmc/callsignaturereturns.t" is empty ?
bacek dukeleto, no. It should be removed 12:29
dukeleto bacek: i applied a patch, i guess
bacek dukeleto, indeed :) 12:30
I added "default:".
To pacify compiler about switch.
dukeleto bacek: thanks
moritz: "make test" is ok with rakudo on latest cs_csr_merge, running spectest now 12:31
pmichaud ugh, trac.parrot.org slooooooow
dukeleto pmichaud: yes. please kick it.
moritz: t/spec/S02-lexical-conventions/unicode.rakudo .................. Dubious, test returned 1 (wstat 256, 0x100) 12:32
moritz: Failed 5/31 subtests
12:33 hercynium joined
moritz dukeleto: that's unrelated 12:33
dukeleto moritz: good to know 12:34
mikehh I am also getting really slow responses from svn.parrot.org and trac.parrot.org 12:38
purl okay, mikehh.
moritz purl: I?
purl you are Moritz Lenz, mailto:moritz@faui2k3.org or very boring or very exciting
dukeleto moritz: t/spec/S12-class/basic.rakudo .................................. Failed 1/33 subtests 12:40
purl: I?
purl i heard dukeleto was still employeed. i "made the cut" in our CEO's words or pretty close to going to sleep or unaccountably violent.
moritz purl: mikehh? 12:41
purl mikehh is not sure if we just need to consider i386 vs amd64 vs ppc or we need to consider Darwin vs Linux (various flavors), OpenBSD, Windows etc or getting assert args failures with: or getting really slow responses from svn.parrot.org and trac.parrot.org
dukeleto moritz: t/spec/S06-other/main-eval.t ................................... Failed 2/3 subtests
moritz that one is also expected
not sure about S12-class/basic
mikehh where on earth did purl get that? 12:43
moritz mikehh: it records that whenever you say "I am ..."
dalek rrot: r42879 | bacek++ | branches/cs_csr_merge/src (2 files):
Pacify codingstd tests about linelength.
dukeleto moritz: it just "parrots" what people say in the channel
moritz: gist.github.com/248129 12:44
moritz dukeleto: I'm recompiling master now to test it, but it could very well be unrelated too 12:45
12:55 whiteknight joined, payload joined 12:58 payload1 joined
Coke rakudo: say 'what' ? 13:02
(do we still have our compiler bot?)
moritz Coke: on #perl6, yes. If it's of help I can also bring it here 13:03
Coke moritz: we used to have one here that did everything in languages/
... back when we had one of those.
moritz Coke: ah yes, polyglotbot. That suffered from not being taken care of 13:04
Coke wow, trac is pretty much dead, huh? 13:25
Coke pings OSUOSL 13:26
whiteknight we got hit pretty good by a weird spambot this morning 13:27
Util trac is dead from here
Coke whiteknight: yes, I already killed his account. 13:30
some email hadn't made it through, so there are still some comments to delete.
13:45 bacek joined
bacek ~ 13:46
our GC suck big times...
cs_csr_merge is only ~5% faster than trunk
(on magical fib.nqp) 13:47
purl: (31593623631-29891188893)/29891188893*100 13:48
purl 5.69544003115474
whiteknight 5% is still good
bacek yeah...
anyway, branch is ready to merge back into trunk 13:49
I'm falling asleep. I'll try to merge is tomor^W today.
Or anyone else can merge it back
It should be pretty easy
whiteknight that's good. Easy is good 13:51
bacek it's up-to-date with trunk. git didn't report any conflicts during merge. I just don't want to dcommit it without more testing. 13:53
Anyway, bedtime.
See you!
Coke asks if anyone wants to write some NQP! =-) 14:02
whiteknight what NQP needs writing? 14:03
Coke tcl builtins in partcl-nqp.
whiteknight partcl has it's own NQP flavor?
Coke github.com/partcl/partcl-nqp
(a rewrite in nqp-rx)
whiteknight oh, okay 14:04
Coke github.com/partcl/partcl-nqp/blob/m.../string.pm is in some particular need of love, and 1) it has tests, and 2) it has a PIR version that can be used for inspiration.
Util Parrot's Trac and SVN are up again, from here. 14:06
14:07 ruoso joined
Util No, back down again 14:07
14:08 JimmyZ joined, payload joined
Coke talking to admins on freenode, they're on it. 14:10
seems better now. 14:14
huh. I think someone else went on spam deletion duty. 14:16
14:25 dalek joined 14:26 d4l3k_ joined, dalek joined, d4l3k_ joined 14:28 dalek joined
Infinoid Sorry about the dalek spam, guys. I fiddled with the daemontools script and hadn't tested it sufficiently 14:29
Coke 09:25 -!- mode/#parrot [+v dalek] by slavorg 14:33
?
that's very light on the channel spam. =-) 14:34
szbalint you probably have join/part hidden
but still it wasn't exactly noticeable
dalek rrot: r42880 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add a step 'patch'
szbalint I think the ensuing discussion generate[sd] more noise than the even itself :)
Infinoid ah. 8-10 copies of the bot were spawned, but only 2 at a time ended up in here 14:37
szbalint probably due to the ircd connection limits for feather 14:39
14:48 bluescreen joined 14:52 bluescreen joined 15:04 shockwave joined
shockwave Is there support in any form for class/object destructors? Perhaps some form of finalize method. 15:05
BTW, I'm refering to PIR. 15:08
Coke you can override the destroy VTABLE. 15:11
something like ".sub destroy :vtable"
s/can/should be able to/ =-)
(see docs/pdds/*17* for a list of the various vtables available. 15:12
shockwave Thanks, @Coke 15:20
dalek rrot-linear-algebra: 7c6b8f1 | Whiteknight++ | PLATFORMS:
update PLATFORMS with the compiler version
 15:30
rrot-linear-algebra: bc3e0d2 | Whiteknight++ | t/00-sanity.t:
add a check to our sanity test to verify that we have the linalg_group library available to test with
15:32 cghene joined, patspam joined 15:36 payload joined
Coke thedailywtf.com/Articles/Bad-Code-O...pdate.aspx -- there is a 500 $ grant up for grabs. "Tell us how your free and open source project prevents bad code from being created and show us how $500 would make a real difference in your project" 15:38
particle cotto: any news on my msdn subscription yet? sadly, november came and went.... 15:46
15:57 Psyche^ joined
cotto_work Coke, how much do you think we could do with $500? 15:58
Coke focus a core developer on performance for a few days? 15:59
(grant hourly rate typically being cheaper than $real rate.) 16:00
cotto_work True. That'd give us a meaningful improvement.
If we got people to look at the right code, we might be able to convince people that we prevent bad code. 16:03
If nothing else, we certainly refactor a lot of it.
t/pmc/threads.t test 9 fails in cs_csr_merge 16:16
(ubuntu x64 9.04) 16:17
16:30 shockwave left
dalek rrot: r42881 | jkeenan++ | trunk (6 files):
Applying patch submitted by kurahaupo++ in trac.parrot.org/parrot/ticket/1344: typographic corrections.
 16:34
whiteknight we help prevent bad code by enabling language interoperation, which allows progammers to solve problems using the right tools 16:46
16:47 cotto_w0rk joined 16:48 theory joined 16:54 ruoso joined 16:55 dalek joined 17:10 payload joined 17:14 dalek joined 17:24 darbelo joined 17:27 dalek joined
darbelo Oh, I see someone recently put some sanity into pmc_freeze.c recently. (Whoever did that)++ 17:29
cotto_work plobsing 17:30
purl somebody said plobsing was trying to create a set of classes which have attributes with a 'label' attribute which can be mapped to and from the attribute name
cotto_work no, plobsing is part of our sanity injection framework
purl okay, cotto_work.
darbelo plobsing++ 17:32
We need to get him a bit. Cut out the middlemen in the sanity injection framework. 17:33
moritz what is it blocking on? 17:34
darbelo I think he doesn't have a CLA. But might be mistaken. 17:35
cotto_work It looks like nobody's proposed that he be given a bit. 17:37
moritz then somebody should it on next #ps
cotto_work I'm sure somebody will. ;)
dalek TT #1356 created by fperrad++: [TODO] add method FixedStringArray.sort() 17:57
18:01 cognominal joined
pmichaud trac.parrot.org down again :( 18:03
cotto_work That's no good. Has it been down much recently? 18:04
Coke they're on it.
previous downtime was due to a robots.txt issue so we got hammered by <search engine>+ 18:05
cotto_work It's kinda back. 18:06
or all the way back
japhb pmichaud, ping
pmichaud japhb: pong 18:08
japhb pmichaud, a couple of days ago a couple of us were discussing making Plumage itself installable. For most of the generated files, no problem, but 18:09
Glue.pir and Util.nqp are of more general usage, and don't really belong within the Plumage/ namespace used for the other libs. Someone suggested
Coke back now. 18:10
japhb NQP/Glue and NQP/Util, because they are in fact generic libraries for people who write in raw NQP-rx. But I wanted to make sure
that you were OK with putting them in "your" namespace
pmichaud I'm fine with use creating standard libraries that can be distributed with NQP, yes.
(and can appear in the NQP namespace)
s/use/us/
japhb OK, cool
pmichaud in some ways they probably belong in the nqp-rx repo, then. 18:11
(I'm fine with that also)
japhb pmichaud, I'm fine with that as well. Take your pick.
pmichaud how about I take a look at Glue,pir and Util.nqp and cherry pick what I think belongs into NQP?
japhb It's all going to get distributed with Parrot eventually, it's just a matter of which git repo gets used
pmichaud, sounds great. 18:12
pmichaud what's the plumage repo, again?
plumage?
purl plumage is, like, the future Parrot module ecosystem. It will include tools to search metadata, handle dependencies, install modules, and so forth. The repository is at gitorious.org/parrot-plumage/parrot-plumage and the design docs are at trac.parrot.org/parrot/wiki/ModuleEcosystem
Coke I am told that the robots.txt is fixed again, and that there is a new caching mechanism in place that should also help.
japhb yay
pmichaud instead of Util and Glue, should we instead break those up into smaller modules? 18:17
japhb pmichaud, no problem, ... (more)
18:17 joeri joined
japhb They were only single files for hysterical raisins. Well, two files: one for PIR code and one for NQP code. But like I said, I have no problems breaking them into pieces. 18:18
pmichaud okay
wfm
dalek rkdown: 1bf1ac4 | fperrad++ | setup.pir:
add flag verbose
japhb Hmmm, probably want a single convenience file that just load_bytecodes all the pieces, for when you don't need/want to be so selective. 18:19
dalek lscript: 647fbcd | fperrad++ | setup.pir:
add flag verbose
 18:20
japhb Or I suppose we could do it at make time ... merging the PIR (hand-coded and NQP-generated) into one PBC
pmichaud nah, just have a .pbc that loads the others
that way we don't have to worry about duplicate loads
japhb Good point
pmichaud I'll set up the initial structure later today, then people can start populating it as commits 18:21
also, I plan to do nearly all of it in NQP, avoiding the PIR parts
dalek nxed: r237 | julian.notfound++ | trunk/winxedst1.winxed:
operator ! in stage 1
japhb Speaking of which, when you load_bytecode something that's already been loaded, what if anything happens? Does it trigger :load or :init again?
pmichaud if the filename is the same, it doesn't load it a second time 18:22
if the filename is different, it does the load and re-triggers any :load subs
so
load_bytecode 'xyz.pbc'
load_bytecode 'xyz.pbc' # doesn't re-load the pbc
load_bytecode '/full/path/to/xyz.pbc' # does re-load the pbc
japhb "avoiding the PIR parts" Do you mean, just not including Glue.pir? Or do you mean applying your NQP fu to the problem of translating Glue.pir to NQP?
pmichaud applying nqp-fu to the pir parts, and/or using inline PIR 18:23
afk for a bit
japhb OK, fair enough. Once upon a time, some of Glue.pir *had* to be done in PIR, because NQP didn't support the right calling semantics. I think most of those reasons are gone now. The only thing I'm missing is support for root_new []. Or did you make that work? 18:24
dalek a: bc50bfb | fperrad++ | setup.pir:
add flag verbose
 18:29
rrot: r42882 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add option verbose to setenv
 18:30
Coke Infinoid++ 18:38
integral indow 45
pmichaud I don't have a good mechanism for root_new, no (other than Q:PIR or pir::root_new) 18:39
Coke pir::root_new is better than .pir 18:42
pmichaud yup.
japhb pmichaud, IIRC at least at one time pir::root_new could not work because it wants a key, not normal arguments. Is that restriction gone now? 18:47
pmichaud root_new will accept a variety of things
it can take a class object, or an array, or a namespace, or a constant key 18:48
so pir::root_new(['parrot';'OS']) ought to work
er
so pir::root_new(['parrot','OS']) ought to work
(it's not the most efficient, but it should work)
japhb Oooh! OK, I had forgotten that.
Ah, probably because of the efficiency thing. I bet I mentally blocked it on account of slow. 18:49
pmichaud also, looking through Util.pir, I wouldn't use root_new at all
I'd create a single $*OS object upon load, and re-use it in the individual functions.
instead of creating a new object in each function
japhb Any task using parrot;OS is going to be dominated performance-wise by the actual task, so that's not an issue
pmichaud and root_new ['parrot';'ResizablePMCArray'] is now just [] :-) 18:50
japhb pmichaud, yes, and I was thinking of doing that ... right about the time that the discussion of moving Glue and Util came up yesterday. ;-)
pmichaud well, a nice aspect of having $*OS is that people can get to it directly instead of only through the functions 18:51
japhb pmichaud, yes, agreed.
Still going to want the wrappers in a couple places, because there's annoying boilerplate like for is_dir(), but that can easily be in NQP 18:52
(now that try/CATCH work, yay Tene!)
pmichaud there's also a question about whether it's better as is_dir() or $*OS.is_dir()
Infinoid Coke++ # Randomly giving me karma, huh? Have a taste of your own medicine!
pmichaud in some ways I prefer the latter
japhb pmichaud, that's fine by me ... just use 'module OS { ... }' trick? 18:53
pmichaud sure.
japhb sounds good 18:54
pmichaud helps to not pollute the global namespace :)
japhb agreed. That's why I've over the last couple months removed a number of subs from Glue.pir and replaced them with methods elsewhere (some but not all went into Util) 18:55
:-)
18:56 mikehh joined
japhb pmichaud, so, let me know what parts you plan to do, and I'll start preparing different stuff on my end. 18:57
pmichaud japhb: I'll just get things started on this end in the nqp directory (and parrot build), then let you exercise your commit bit for the rest :-) 18:58
japhb heh
fair enough 18:59
pmichaud, what's :load :init in NQP? INIT { } ?
pmichaud yes 19:00
that may change to BEGIN or CHECK or something like that, but for now it's INIT { ... }
19:01 mikehh joined
japhb OK, cool 19:01
19:06 schnee joined
schnee Hi folks. I'm just trying to build parrot (as part of rakudo) on windows/cygwin, and although it apparently compiles just fine, I'm running into crashes there. I was wondering if anyone could help me with that? 19:10
dalek rrot: r42883 | mikehh++ | trunk/MANIFEST:
regenerate manifest
japhb schnee, I believe fperrad is our resident Parrot-on-cygwin expert, if he is around 19:11
schnee Ah, great!
japhb fperrad, feel highlighted. :-) 19:12
19:12 mikehh joined, chromatic joined
PerlJam schnee: If you just want to play with parrot/rakudo, I believe that there are cygwin packages for both. 19:12
(I could be wrong though)
japhb schnee, if fperrad is not around right now, you can also try the packages PerlJam mentioned (which IIRC fperrad made :-), or the parrot-users mailing list. 19:13
schnee There are, but they're horribly out of date.
japhb parrot-users?
purl i think parrot-users is lists.parrot.org/mailman/listinfo/parrot-users
schnee Thanks for the pointer, I may try that, too. :) 19:14
dalek rrot: r42884 | mikehh++ | trunk/t/native_pbc/testdata (2 files):
set svn properties
 19:17
rrot-linear-algebra: 3659aaf | Whiteknight++ | t/00-sanity.t:
fix the sanity test
 19:21
rrot-linear-algebra: 4dc502c | Whiteknight++ | src/pmc/charmatrix2d.pmc:
fix charmatrix so that we initialize all it's storage on resize, since we use that storage directly to build strings
cotto_work bacek_at_work, t/pmc/threads.t test 9 fails in cs_csr_merge on ubuntu 9.04 x64, non-optimized 19:35
19:36 schnee left, bacek joined
dalek rrot: r42885 | mikehh++ | trunk/t/native_pbc/testdata (2 files):
add copyright, Id and coda
 19:37
19:43 lucian_ joined
dalek trixy: dcf5c2a | Whiteknight++ | README.NCI.pod:
remove the NCI readme file, unused now. Parrot-Linear-Algebra handles all these details
 19:43
trixy: 8783099 | Whiteknight++ | README.pod:
updates to README.pod to make it clean and current
trixy: 3f29530 | Whiteknight++ | t/parrot/parrot_pir.t:
add tests for the pir() function, since apparently CharMatrix2D didn't work with it until recently
trixy: d4c9a30 | Whiteknight++ | t (2 files):
add an ismatrix() function with tests
trixy: b5847f9 | Whiteknight++ | src/builtins/pir.pir:
fix pir() to take PMC arguments
trixy: 2ab528a | Whiteknight++ | t (2 files):
add iscell() function and tests
trixy: 9799159 | Whiteknight++ | t (2 files):
add ischar() function and tests
trixy: c6ae1d2 | Whiteknight++ | t (2 files):
add iscomplex() and tests
trixy: 6f7b40e | Whiteknight++ | t/functions/ (2 files):
Merge branch 'master' of github.com:Whiteknight/matrixy
trixy: bdbf114 | Whiteknight++ | t/functions/transpose.t:
remove the ctranspose tests from transpose.t
 19:49
rrot: r42886 | jkeenan++ | trunk (6 files):
Revert 5 files patched in r42881 to their pre-existing status (cf. TT #1344).
 19:50
19:57 iblechbot joined 20:00 davidfetter joined 20:05 brrant joined
tewk Whats the current best practice module for writing simple to moderate XS code? 20:06
dukeleto 'ello 20:07
tewk: are you trolling or do you want a real answer? ;)
Coke do mean the equivalent in parrot? 20:08
*do you
tewk perl5 XS I just wanted a recommendation of a CPAN module to use or something like that. 20:11
dukeleto tewk: what do you want to do? 20:12
whiteknight I tought current best practices involved not writing XS in the first place? 20:13
japhb tewk, it has been a while for me, but last I recall it really depends on your task -- if you want to wrap a largish but relatively simple API, there are tools for that. But if you need to deal with a complex API that doesn't quite match Perl 5's model for things, you end up with a lot of hand-written XS. OpenGL has this issue, for instance.
dukeleto ba dump ching!
tewk dukeleto, wrap simple c library calls
dukeleto tewk: take a look at how Math:GSL wraps the GSL library with SWIG 20:14
japhb tewk, Inline::, SWIG, and h2xs can all do the simple stuff.
afk, lunch
dukeleto tewk: how "simple" is your library? how many functions? what is the most complicated function signature? callbacks make things interesting
tewk dukeleto, its very very simple, sounds like I should just use raw XP or inline, SWIG is way to complicated for this problem. 20:22
raw XS I mean
dukeleto tewk: SWIG adds complications to the build process, but actually makes you write a lot less code 20:23
tewk: GSL has thousands of functions, so SWIG was the only choice
tewk: how many functions do you need to wrap?
tewk: also, you can just use the XS code that SWIG generates as a starting place, to see how it is done. The generated code is not pretty, tho 20:24
tewk: if you want to write raw XS, i don't understand your question about a best practice module. you just need to read perlxs, perlguts and perlapi and then it is just a SMOP 20:25
mikehh All tests PASS (pre/post-config, smoke (#30543), fulltest) at r42885 - Ubuntu 9.10 amd64 (gcc with --optimize)
dukeleto mikehh++ 20:28
whiteknight how do I resolve a merge conflict in git? 20:30
tewk fix it then git add
whiteknight I have done both of those things, but still get an error message
dukeleto whiteknight: nopaste 20:31
whiteknight "fatal: you have not concluded your merge. (MERGE_HEAD exists)"
dukeleto: what to nopaste?
dukeleto whiteknight: entire error output
whiteknight: did you do git rebase --continue ?
tewk whiteknight, are you rebasing?
dukeleto whiteknight: were you in a rebase?
whiteknight tewk: I don't know what rebasing is, I never do it
dukeleto: that is the entire error output
dukeleto whiteknight: please nopaste all the commands that you are typing 20:32
whiteknight: as well as git status -a
whiteknight $> git pull 20:33
fatal: You have not concluded your merge. (MERGE_HEAD exists)
particle git mergetool
whiteknight urg. "no known merge resolution tool available"
dukeleto whiteknight: git status -a, please
purl git status -a is my friend, as well as a healthy .gitignore
dukeleto purl++ 20:34
nopaste "Whiteknight" at 173.12.37.77 pasted "git status -a for dukeleto++" (32 lines) at nopaste.snit.ch/18952
whiteknight doesn't show anything as conflicted 20:35
dukeleto whiteknight: you haven't commited!
whiteknight so it's not just fix the conflict and add, like I had been lead to believe?
particle git mergetool --tool=<tool>. Valid merge tools are: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, diffuse, tortoisemerge, opendiff, p4merge and araxis.
dukeleto whiteknight: it is : fix the conflict, git add foo, then commit 20:36
particle git mergetool walks you through the process
dukeleto if you don't commit, all your stuff is just sitting in your working copy, not committed to your index
particle s/index/staging area/
dukeleto whiteknight: which means you can't pull
particle that's the new term iirc
dukeleto whiteknight: you can do: git stash && git pull && git stash pop 20:37
particle: both are used interchangeably
whiteknight: that will get around your "can't pull before I push" issue
whiteknight ok 20:38
dukeleto whiteknight: i have that aliased to "git up"
whiteknight: github.com/leto/Util/blob/master/co....gitconfig 20:39
fperrad japhb, a new one trac.parrot.org/languages/browser/e...cript.json
Infinoid dukeleto: Do you actually use "praise"? If so, you're the first person I've ever met who does. :) 20:40
japhb fperrad, OK, will do
dalek trixy: 7bba118 | Whiteknight++ | (17 files):
merge that sucker
 20:41
japhb fperrad, did schnee manage to get in touch with you?
dukeleto Infinoid: yes, when i am in a good mood
whiteknight dukeleto: by the way, I have some ideas for improvements to nqpTAP. I'll try to monkey around with it later if I can find the tuits
dukeleto whiteknight: you mean Tapir? 20:42
tapir? 20:43
purl somebody said tapir was being written to be testable from the ground up, unlike nqpTAP or github.com/leto/tapir
japhb dukeleto, is Tapir a complete replacement for nqpTAP?
dukeleto japhb: Tapir already does 10x more than nqpTAP ever did. And it has tests to boot.
whiteknight Tapi?
Tapir?
purl Tapir is being written to be testable from the ground up, unlike nqpTAP or github.com/leto/tapir
fperrad japhb, in fact I don't work with cygwin
whiteknight dukeleto: I have never heard of Tapir. I'll have to check that out later 20:44
anyway, I have to disappear now. talk to you gentlemen later
japhb fperrad, I thought you did, hmmm. Sorry about that.
dukeleto whiteknight: you have a commit bit now :)
whiteknight w00t
dukeleto++
dukeleto whiteknight: i just wrote tapir in the last 5 days
japhb fperrad++ # Lots of new projects brought into the Plumage fold
dukeleto whiteknight: it is MUCH faster than Test::Harness 3.x
anybody else want a bit for tapir? 20:45
particle does 20:46
dalek rrot-linear-algebra: c2564ba | Whiteknight++ | PLATFORMS:
add entry about performance on Ubuntu 9.10 with the newer GCC
dukeleto particle: done
japhb dukeleto, please. # I won't have time to use it for a bit, but will probably eventually
dukeleto japhb: you already have one :)
japhb oh
well 20:47
then.
*cough*
dukeleto i have japhb, tene, chromatic, bubaflub, whiteknight, particle, ewilhelm and brianwisti with a commit bit to tapir
if anybody else wants one, let me know
the TODO file is extensive, please look for something to work on in there 20:48
dalek rrot-plumage: 3c8da7d | japhb++ | :
[METADATA] ecmascript, courtesy fperrad++
 20:49
fperrad dukeleto, my requirement for Tapir :
- a single pbc
- a installable executable
- available in Parrot tree (like nqp-rx)
- equivalent of Perl5 prove
- with option --exec 20:50
- with option --archive
- with option --env (see rt.cpan.org/Public/Bug/Display.html?id=50215)
japhb fperrad, I sense that getting Tapir into the Parrot tree will not be terribly hard, since it is excellent dog food, and would kill the last vestiges of perl5 dependency for a bunch of projects.
If necessary, it will come in under the auspices of Plumage. 20:51
darbelo dukeleto: sign me up!
fperrad japhb, yes, the goal is kill dependencies, perl5 and others 20:52
dukeleto darbelo: done!
fperrad: you have a bit too
darbelo likes killing dependencies.
japhb fperrad, also, it sounds like pmichaud and I have agreement on general course of action to make Plumage installable (which involves moving some code out of Plumage and into NQP-rx)
dukeleto fperrad: tapir has --exec already
fperrad: a single .pbc and installable needs to be written, but it not very hard 20:53
japhb pmichaud++ is preparing things on the NQP-rx side.
dukeleto fperrad: the idea is that tapir will go in ext/ like nqp-rx
fperrad: re-implementing *every* prove feature is non-trivial 20:54
fperrad: --archive is planned. this basically means writing TAP::Harness::Archive in PIR
fperrad: can you add these items to the TODO?
fperrad: i want more details on "equivalent to prove" 20:55
fperrad: you want exactly the same output format?
japhb: yes, it is planned that Plumage will be the first guinea pig for Tapir, when it is ready 20:56
japhb dukeleto, excellent.
dukeleto japhb: since Plumage does not need --archive, yet.
japhb I would have if you hadn't. ;-)
dukeleto fperrad: --env seems like a neat feature 20:57
fperrad dukeleto, all features of prove are not mandatory, we need only feature that we currently use
dukeleto fperrad: yes, like --merge 20:58
fperrad: tapir's TAP parser is very close to being done, then the aggregator needs improvement and then extra features (like --env) need to be added 20:59
japhb What is --env? It's not documented in my local 'man prove' 21:00
dukeleto japhb: new feature
purl new feature is, like, X =~ s/A/B/ or www.cs.cmu.edu/~infobot/infobot_guide.html
fperrad dukeleto, a single pbc is easy, just write an PIR file that includes all other
dukeleto japhb: rt.cpan.org/Public/Bug/Display.html?id=50215
fperrad: yes, i just need to fiddle with the build stage
so Tapir will be invoked like: parrot t/harness.pbc t/*.t 21:01
japhb Ah, interesting
dukeleto currently it is parrot t/harness.pir t/*.t
japhb fperrad, I'm about to do a Plumage feature sprint. Anything on the top of your requests? (installability is WIP, blocked on pmichaud). 21:03
I was thinking new/improved stages, so if you've got suggestions there let me know now.
darbelo japhb: How about an interactive mode? Activated via a switch on the command line. 21:05
fperrad japhb, always a stage 'update'
darbelo japhb: The "Oops. The project you are trying to install burst into flame while testing. Do you want me to keep going anyway?" mode. 21:07
japhb darbelo, added to TODO. Different user interfaces have long been planned, blocked on getting refactors far enough that all model and controller bits were moved off to libraries. I'm 80% there on those.
darbelo japhb: is the remaining 20% listed in TODO? 21:08
japhb darbelo, (re: keep going after testing fail) Already exists. See option --ignore-fail in usage
darbelo japhb: I meant that as an example of the 'interactive' mode. 21:09
japhb darbelo, no, mostly because I haven't found all the places that need to be refactored away. I'm judging 20% mostly as a matter of line count in the relevant areas.
darbelo, ah, I see 21:10
fperrad, right, I remember now. You wanted an 'update' stage that falls back to 'fetch', right? And there was another one, too, do you remember?
Coke (praise) kid51 also does. 21:11
darbelo japhb: 'patch'? 21:12
japhb I'm planning to add a reread_metadata_from key for all stages ... it specifies a file in the build tree to reread the metadata from before going to the next step. (Or in the case of the install step, before placing in the "final metadata" archive, which feature is also WIP ATM.)
darbelo, yes, sure. I would swear there was another one, but I'm forgetting it now.
clean! 21:13
that's the one
and someone had wanted a "show me the README" as well 21:14
darbelo That's... lazy. 21:15
plumage readthedocsforme
japhb darbelo, not run by default. Just reachable.
fperrad japhb, we've spoken about : 21:16
- a stage 'clean'
- a command purge/remove project
japhb I'm almost thinking a "jump to build dir" is more generally useful
DAMN UNIX PROCESS MODEL. 21:17
I can either exec a shell there or display the directory. Hmmm, latter is probably easier. Because then people can say 'cd `plumage project-dir foo`' or 'PROJECT_DIR=$(plumage project-dir foo)' or whatever 21:18
fperrad japhb, before writing metadata requirements, have you study the spec file of RPM package ? 21:21
because now with distutils, I can produce source distribution (ie tarball), so the next step is binary distribution : RPM package, Debian package
japhb I have experience with both RPM and DEB, but no, I have not studied them in depth yet (more's the shame). Mostly I'm just trying to keep their general requirements in mind while I work, as well as those of various HLL native installers, like CPAN for Perl 5. 21:23
darbelo plumage generate-deb projectname would be veeeeery cool to have.
japhb Any places I have painted myself into a corner I would REALLY like to know about.
fperrad darbelo, with distutils : $ parrot setup.pir bdist 21:28
or $ parrot setup.pir bdist_deb
japhb, another stage for Plumage is 'smoke' 21:31
currently, distutils know Smolder (see Lua for working example), but not TapTinder
japhb fperrad, great, thank you 21:33
darbelo fperrad: Sold. I'm migrating decnum-dynpmcs to distutils.
Are there any docs? Or do I just RTFS? 21:34
dukeleto darbelo: basically just copy over setup.pir and a few other files and you are done 21:35
fperrad darbelo, see runtime/parrot/library/distutils.pir, some doc, and many examples (links) 21:36
darbelo fperrad: excelent.
dalek pir: 6836fad | fperrad++ | TODO:
add my wishlist
 21:51
cotto_work looks like the manifest needs to be regenerated in cs_csr_merge 21:53
(minor nit, but it causes a fulltest failure)
fperrad darbelo, currently distutils handles pmc files, but need some hacks for external C files. 21:59
I'll work on it, tomorrow
darbelo fperrad: Ah, ok. I was looking into that just now. I have to build a lib and link it to the pmc's .so 22:01
22:02 davidfetter joined
pmichaud it's interesting that we're moving to something distutils-like, as many of the python folks I talk to continually complain about the problems with distutils in python :) 22:15
darbelo pmichaud: We're doing it better ;)
pmichaud wfm :) 22:20
davidfetter darbelo, how is this distutils different from all other distutils? 22:30
22:31 payload joined
darbelo fperrad wrote this one, but not all others? ;) 22:32
davidfetter that'd be an important difference
is there some kind of spec for it?
lucian_ pmichaud: the concept of distutils isn't bad, that particular implementations is less than perfect
22:34 brrant joined
darbelo davidfetter: AFAIK, there's no spec, and we aren't aiming at 100% compatibility. It's a matter of leveraging parrot's platform knowledge to build stuff that runs on it. 22:35
From what I've seen so far it's a pretty sane interface. load_bytecode distutils, put your data in a Hash PMC and let it worry about platform differences for you. 22:36
davidfetter :) 22:37
dukeleto distutils.pir is pretty cool 22:38
japhb Now if we had hash literals in NQP ... *cough* ;-) 22:42
pmichaud "patches welcome!" *cough* 22:43
particle cough syrup welcome, too!
Tene "I finished being sick two weeks ago, why am I still coughing?" *cough*
PerlJam japhb: What do you need hash literals for exactly?
pmichaud although it did occur to me that a hash() function might make building hashes a bit easier 22:44
i.e., one could do
Tene PerlJam: initializing hashes, of course.
pmichaud my %h = hash( :key(value), :key(value), :key( hash( :key(value), :key(value) ) ), :key(value) );
not quite as nice as the '{' syntax, but certainly a lot easier to implement 22:45
sub hash(*%h) { %h }
particle wouldn't that produce a Bag? 22:47
japhb bak
pmichaud in NQP? no.
japhb PerlJam, I do a lot of data-driven programming. Right now I'm hacking it via JSON. Which sucks.
particle ah, right, nqp. that oughtta work.
Tene sucks bad. 22:48
japhb PerlJam, and because distutils wants to be fed nested hashes. :-)
Tene but clever.
japhb OK, I guess that goes in Util, then
chromatic I don't like the hash marking algorithm. 22:50
pmichaud fwiw, I don't like Hash.clone much, either. :-| 22:51
chromatic Seems like it should be able to walk the bucket store, rather than following bucket->next.
dalek rrot-plumage: 1afb1f4 | japhb++ | :
[DOCS] Add new docs/ tree, and first doc: adding a new command
 23:01
rrot-plumage: ea2c0b7 | japhb++ | :
[META] TODO updates
23:05 Whiteknight joined 23:08 Coke joined
Coke has his second power outage in a week or so. 23:08
dalek rrot-plumage: d768b2d | japhb++ | :
[LIB] Plumage::Project: Add accessor methods
 23:12
rrot-plumage: 5ef5de2 | japhb++ | :
[LIB] Add project-dir command
japhb documenting++ # Forcing junk to be cleaned up rather than having to admit it in the document 23:32
23:42 kid51 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!