Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply merge
Set by moderator on 23 October 2009.
dalek rrot-linear-algebra: fd89940 | darbelo++ | (2 files):
Add first example of custom @symbol@ creation for the Makefile template.

Incidentally, fix the build on OpenBSD.		 00:06
rrot-linear-algebra: 90d7929 | darbelo++ | :
Merge branch 'master' of github.com:Whiteknight/parrot-linear-algebra
rrot-linear-algebra: 632761f | Whiteknight++ | src/pmc/nummatrix2d.pmc:
Add a few new accessors to NumMatrix2D. This includes STRING and PMC accessors, and linear '_keyed_int' accessors for people who want that too
rrot-linear-algebra: 8d158d8 | Whiteknight++ | :
Merge branch 'master' of git@github.com:Whiteknight/parrot-linear-algebra
darbelo Whiteknight: ping 00:09
Whiteknight darbelo: pong
purl msg darbelo pong
darbelo Can you test my last push, see if it unbroke the build after a reconfigure. 00:10
dalek rrot-linear-algebra: 8cbe0d7 | darbelo++ | Configure.nqp:
Oops. Unbreak other platforms after the last Configure change.
 00:11
Whiteknight darbelo: make and test works for me 00:12
darbelo did you run Configure.nqp?
Also, is there a -lblas in your makefile? 00:13
Whiteknight I did run Configure.nqp 00:14
no, it doesn't look like there's -lblas in my makefile
but it did link. So no idea what that's about 00:15
darbelo You probably don't need -lblas for it to link. 00:16
Whiteknight ok
darbelo But that means my changes didn't work like I expected.
Whiteknight ok
Coke who has the most recent version of gcc? 00:17
(I have 4.3.4)
darbelo Agh, another stupid typo. Nevermind.
Whiteknight what's the most recent?
I have 4.4.1
darbelo has 3.3.5 00:18
Whiteknight darbelo has been banned from the internet
Coke Whiteknight: can you try rt.perl.org/rt3/Ticket/Display.html?id=50908 00:19
00:19 payload joined
Coke (there's a .c file at the end there; try the lat compilation line with -Werror=... 00:19
dalek rrot-linear-algebra: 373fd82 | darbelo++ | Configure.nqp:
Agh. Another typo in Configure.
 00:23
Whiteknight Coke: works for me 00:26
warns when -W, errors when -Werror=
close that sucker 00:27
Coke ok, I believe you. =-)
bacek_at_work Coke, trust no one! 00:28
Coke Whiteknight++ 00:31
00:31 payload joined
cotto_work I'd like to see einstein rewrite his proposal. I'm sure part of the reason for the partial warnocking is that it's not especially well written or formatted. 00:34
dalek rrot: r42147 | whiteknight++ | branches/tt_1020:
Creating a new branch to test some stuff for TT #1020
 00:35
Whiteknight cotto_work: agreed. It's very interesting, but I completely misunderstood it today 00:36
00:38 mokurai joined
cotto_work also I don't see how it could possibly be faster than what we have now. iiuc he wants make every PMC act like a pir-level PMC and go through Object. 00:42
Whiteknight that's sort of what I thought too, but I think that's not it
jonathan got a link handy?
Whiteknight TT #1020
cotto_work trac.parrot.org/parrot/attachment/...0/plan.txt
jonathan glances over it 00:43
cotto_work just ignore the struct stuff. 00:44
the first batch, at least
jonathan oh, it's another attempt on making subclassing PMCs cleaner. 00:45
Ah, and perhaps storage efficiency, and opening the door to non-PMC attributes. 00:47
Whiteknight it has some interesting ideas, but it's a huge change 00:48
cotto_work jonathan, you mean non-INSP attribute? 00:49
s/te/tes/
jonathan cotto_work: today, an Object PMC can only have PMC attributes.
That is, you gotta box everything.
cotto_work ok
jonathan Some unification between PMCs and Objects would be perhaps interesting.
Doing it well may mean runtime generation of stuff doing struct-like things though. 00:50
dalek TT #1151 created by coke++: Exception thrown from constructor leads to oddness
jonathan Whiteknight: Yes, it's a huge change. 00:51
Whiteknight it may also mean some nice performance wins
jonathan Whiteknight: And, I hate to say this, but...I've got code that actually depends on us having the proxy objects. ;-) 00:52
I'd be willing to change though.
Whiteknight I cna't imagine. I still have no idea what purpose those damn proxies serve
jonathan Oh, I know that part.
The idea was like this: 00:53
You could have multiple types of classes (e.g. PMCs were one type, a Parrot Class was another, a HLL's custom class would be another).
And they could have their own objects which had their own internal layout. 00:54
If you inherited from something that was a different type of object, e.g. that had a different internal layout, then you would just have a proxy object there for the prupose of the storage, and iteract with it fully through the vtable methods.
If it was your own, known, type of class, you could of course cheat lots and not have the proxies. 00:55
That meant that we could have different underlying object representations.
At the time we had 2 - PMCs and high level Objects. 00:56
But I could see more coming.
Whiteknight I can't imagine that anybody ever saw that as a good idea
jonathan Heh. It was mine, and I don't think it was a bad one.
cotto_work Whiteknight, where could the performance wins come from in TT #1020?
Whiteknight I mean, the performance loss of switching representations is lousy. Much better to shoehorn everyting into the same system
cotto_work: not having to box Object attributes for one
jonathan Yes, if you really seriously thing you're going to create one amazing representation that is so awesome it will work for every language that could want to use Parrot. 00:57
Whiteknight storing Object attributes in a C array, instead of a Hash for another
jonathan *think
Whiteknight: Object attributes are stored in a RPA, not a Hash.
Whiteknight jonathan: doesn't have to be seriously awesome. Needs to be very low level and stay out of the way
Anyway, I've got to get to bed. Goodnight all 00:58
jonathan o/
cotto_work but it seems like for the common case of using simple PMCs, adding another level will cause a big slowdown without performance win
night
jonathan cotto_work: Right.
cotto_work I can see how this could be more valiable with Lorito though. 00:59
jonathan cotto_work: Thus why it made some sense that things that could represent themselves in a smarter way than a hash table (e.g. being based on a C struct and written in C, like PMCs are) could do that.
The fact that Parrot since I put this model in has half-heartedly soft-of abandoned it but not quite means we're now stuff with the worst of both worlds in some senses, as einstein points out. 01:00
It also hurts in that Rakudo now has lost Parrot providing support for the Perl 6 idea of multiple representations. 01:01
Meaning we'll quite possibly end up moving away from Parrot's Class and Object PMCs at some point in the future.
01:03 tetragon joined
plobsing I don't see why we don't do something equivalent now. If we restrict sizes we can fit INTVALS and FLOATVALS into the R(not really P)A. 01:03
implement the appropriate get/set attribute ops and we're there. 01:04
plobsing is obviously overlooking something
dalek rrot: r42148 | coke++ | trunk (2 files):
Add a test for TT #1151
cotto_work coke++ for adding a file called new-old.t
cotto_work hopes his reply sounds more like constructive criticism than a flame 01:10
summon purl 01:11
purl--
we'll find out soon enough 01:12
dalek TT #1152 created by coke++: :named should default to the name of the parameter 01:13
01:13 purl joined
cotto_work wb purl-- 01:13
plobsing karma purl 01:14
purl purl has karma of 8754
cotto_work the selective hearing helps
purl--
purl cotto_work: what?
cotto_work karma purl
purl purl has karma of 8754
cotto_work afk 01:15
afw too
jonathan -> sleep
plobsing purl?
purl yes, plobsing?
dalek rrot: r42149 | coke++ | trunk/t/compilers/imcc/syn/pcc.t:
add a test for TT #1152
 01:20
Coke cotto_work: I thought it was awesome, myself. =-) 01:25
dalek rrot-plumage: 8e29a0e | japhb++ | :
[META] Lots of TODO updates
rrot: r42150 | coke++ | trunk/docs/running.pod:
Remove hopeful but incorrect docs.
 01:27
01:39 payload joined 01:40 dduncan joined 01:41 dduncan left 01:42 kid51 joined
dalek TT #1153 created by coke++: 'parrot -O2 oofib.pir' errors out, when -O1 succeeds 01:42
01:45 jhelwig joined
dalek rrot: r42151 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
[pct/past]: Add 'contextual' scope to PAST::Var.
 02:17
02:17 confound joined
dalek p-rx: f645528 | pmichaud++ | (4 files):
[nqp]: Add contextual vars, tests for optional args.
 02:17
02:28 hercynium joined
dalek rrot: r42152 | coke++ | trunk/src/pmc/default.pmc:
Remove old "what-if" comment.
 02:33
Coke lua? 02:37
purl it has been said that lua is at www.lua.org/
bacek_at_work purl: lua is also github.com/fperrad/lua 02:38
purl okay, bacek_at_work.
02:40 mokurai joined 02:47 Austin joined
bacek_at_work msg chromatic I don't think that trac.parrot.org/parrot/changeset/42135 is correct. We just need more tests... 02:48
purl Message for chromatic stored.
Coke pmichaud_: ping 03:01
dalek TT #1154 created by chromatic++: Handle Pending Events More Frequently 03:12
TT #1155 created by rurban++: dynext - dll versioning 03:15
Coke I am kind of wierded out that I can create tickets as if I were someone else. =-) 03:16
msg chromatic assigned you RT#57236 because you're the pbc2exe guy. 03:17
purl Message for chromatic stored.
03:20 abqar joined
Austin Remember, Coke: with great power comes great responsibility. 03:26
dalek rrot: r42153 | coke++ | trunk/t/pmc/resizablepmcarray.t:
Avoid regressions for #56448
 03:38
03:41 janus joined 03:46 eternaleye joined
Coke msg pmichaud can you please double check if #47970 is still an issue? 04:07
purl Message for pmichaud stored.
Coke gets TT down to 156.
er, RT
dalek p-rx: ed8726a | pmichaud++ | (4 files):
[nqp] Add named argument handling.
 04:08
p-rx: 742167e | pmichaud++ | (3 files):
[nqp]: Add modules, package-based names.
Austin Coke++ 04:16
04:20 theory joined 04:29 mikehh joined
Austin The worthless word for today is "stupex". An obsolescent, jocular term for "a fool". 04:30
dalek p-rx: e1d65a0 | pmichaud++ | (3 files):
[nqp]: Add class declarations and method calls.
 04:51
p-rx: 8199cf6 | pmichaud++ | (4 files):
[nqp]: Add 'self', methodop tests.
 04:57
p-rx: 9bfe3c4 | pmichaud++ | t/nqp/28-subclass.t:
[nqp]: Add tests for subclassing.
cotto "stupex"? That's an awesome word! 05:13
pmichaud_, how close to "ready" is nqp-rx? 05:15
05:18 kyle_l5l joined 05:20 mberends joined
dalek p-rx: dd2ec36 | pmichaud++ | (3 files):
[nqp]: Add statement_prefix:sym<make>, $/ $_ $! variables.
 05:26
p-rx: 1316068 | pmichaud++ | src/NQP/ (2 files):
[nqp]: Add $<foo> and $[0] variables.
pmichaud_ cotto: very close to "ready" 05:34
cotto: I'm already passing all of the old nqp test suite except for pod comments.
and @(...)
jdv79 i look forward to the new nqp
pmichaud_ (the later is trivial to implement.)
I do too.
cotto With your velocity, I'm not surprised.
pmichaud_ I need to write up the list of features that are already in the new nqp 05:35
here's a short list:
infix:<//>
contextual vars
$foo.method: $args (alternative to $foo.method($args) )
:xyz<something> (alternative to :xyz('something') ) 05:36
:xyz (alternative to :xyz(1) )
:!xyz (alternative to :xyz(0) )
<abc def ghi> (alternative to ('abc', 'def', 'ghi') ) 05:37
Tene pmichaud_: does rakudo trunk build against parrot after the pcc merge yet?
pmichaud_ Tene: I think jnthn merged the branch earlier today
Tene Great.
pmichaud_ (so I think "yes")
I haven't independently verified it yet.
Tene I'm feeling like starting on some IO work for Parrot, probably starting with a 'select' PMC 05:38
I want to get back to working on my POE clone. 05:39
cotto it looks like yes, as rakudo master pulls a post-merge revision with gen-parrot
Tene Thanks, cotto.
05:41 eternaleye joined
cotto night, owls 05:41
jdv79 POE is entirely too inefficient 05:42
dngor Tene: If I had Moose when I was starting POE it might look like Reflex
jdv79 p6 events were supposed to be better
treed Power over Ethernet?
pmichaud_ at the moment I'm seeing if the new NQP can compile its own Actions.pm 05:43
jdv79 POE is perl's answer to python's Twisted.
just an event framework
treed Ah.
jdv79 Perl Object Environment i think...
lame name
treed has only limited experience with Perl. 05:44
Starting to get better, though.
I was reading up today on use threads.
Need to parallelize a script at work.
jdv79 has almost no ruby experience except that rake thing for cardinal
treed heh.
I would love to use ruby at work. 05:45
But no one else would love me for it.
jdv79 do not use p5 threads.
treed Engineering uses Python, Ops uses Perl5.
No love for Ruby. :-(
Why not?
jdv79 :(
cause they are implemented horribly
each thread is a new interp
just fork 05:46
treed Sure, but I intended to do the worker model.
Like 5 threads.
Farm out work and collect the results. 05:47
jdv79 *nix?
treed Yeah.
jdv79 fork! 05:48
:)
treed Isn't that the same thing?
jdv79 no. cow.
treed But with threads, the coding is a little cleaner.
jdv79 good luck with that:)
jdv79 passes out. 05:49
Tene 'night
treed Seems like this would be a prime candidate for P6 junctions+autothreading. 05:54
The stuff that takes forever is just a foreach.
Tene If I could get Parrot threading to not crash, it would be a step towards autothreading in Rakudo. 05:58
tt757, iirc 05:59
kyle_l5l I think I'm getting close. 06:00
(to get parrot threading to not crash, and threads to work in rakudo)
Tene :D 06:02
I'm so glad to hear that.
kyle_l5l I only need 10GB of memory at the moment to make one rakudo thread!
Tene o.O what? 06:03
purl o.O is what happens when one of my bra straps is broken
kyle_l5l hah. Somewhere in the jungle that is parrot_freeze and parrot_thaw, something is getting out of hand.
06:09 JimmyZ joined 06:15 preflex joined
pmichaud_ nopaste.snit.ch/18488 # accessing PIR opcodes directly from NQP 06:17
dalek p-rx: 463e6af | pmichaud++ | src/NQP/ (2 files):
[nqp]: Allow subroutine and method names of form "category:sym<...>".
 06:19
p-rx: 2a89139 | pmichaud++ | (3 files):
[nqp]: Add ability to access PIR opcodes directly via PIR:: pseudonamespace.
pmichaud_ time for sleep -- more tomorrow.
JimmyZ pmichaud_: good ninght. 06:21
06:26 japhb joined
Tene okay, I got a basic pipe example working in C... I think I'd be willing to tackle the Pipe PMC. 06:31
... I don't see one. 06:32
06:33 chromatic joined
Tene ah, it's just part of filehandle.pmc 06:40
okay, got the IO tasklist open, I'll start evaluating it during work tomorrow. 06:44
whiteknight++ for detailed iotasklist wiki page
dalek rrot: r42154 | mikehh++ | trunk/compilers/pct/src/PAST/Compiler.pir:
fix codetest failure - trailing spaces
 06:58
07:12 uniejo joined
mikehh All tests PASS (pre/post-config, smoke (#29455), fulltest) at r42154 - Ubuntu 9.10 RC amd64 07:13
07:16 iblechbot joined 07:22 uniejo joined 07:31 fperrad joined 07:40 fperrad joined 07:48 mokurai joined 08:20 fperrad joined 08:23 payload joined
dalek p-rx: 819be4d | pmichaud++ | t/nqp/30-pirop.t:
[nqp]: Failure to plan(3); is like planning to fail.
 08:27
p-rx: b1c6254 | pmichaud++ | src/ (4 files):
[nqp]: Add regex_declarator.
p-rx: c571f83 | pmichaud++ | (3 files):
[nqp]: Add grammars, tokens, regexes, rules, and protoregexes.
p-rx: eb5ffe7 | pmichaud++ | t/nqp/32-protoregex.t:
[nqp]: Add some simple protoregex tests.
08:45 fperrad joined 08:57 gaz joined
Austin Is it me, or are there absolutely no tests for the 'slice' opcode? 09:09
moritz I have an old version of parrot lying here, and it really doesn't have any tests for it 09:11
Austin 7 ack -a slice $_PARROT/t only has an opcode parse test with a hit - 01-parse_ops, or some such.
moritz same here 09:12
moderator Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply merge | write tests for slice opcode 09:12
Austin I can't find any design docs for it - FPA references pdd17 - basic types, but there's nothing there. 09:13
The intent seems to have been to turn a key into an iterator.
Which suggests that they intended to overload the key with both starting and ending data: $P0 = slice array [ 0; 10 ] 09:14
moritz I'm sure chromatic or bacek_at_work know what to make of it
Austin Which strikes me as idiotic, since keys support multiple dimensions. So that must be wrong.
Slice pmcs were removed in 1.1.0 09:16
(NEWS)
Slice syntax was gone in 0.9.0
So the opcode should probably get deprecated. 09:17
moritz rakudo doesn't seem to use it
moderator Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply merge | find out what's up with the slice opcode 09:17
Austin I think their slices are probably way too mixed up with the language. 09:18
Anyway, all this is unfortunate, because I need a slice of an array. :(
Hello, "for(...)"
dalek rrot: r42155 | kjs++ | trunk/compilers/pirc/src/pircompunit.c:
[pirc] TT#1152; set default value of :named flag if not specified
 09:28
09:33 Ron joined 09:34 xenoterracide joined 09:37 xenoterracide joined 09:42 xenoterracide joined, bacek joined 09:46 xenoterracide joined
moritz purl: patches welcome? 09:57
purl well, patches welcome is ponies welcome or Set Objectives, Achieve Results! or swahili for "Put up or shut up."
10:27 mokurai left 10:46 iblechbot joined 10:53 kid51 joined 10:56 payload joined
kid51 nods at #mongers and gives him a small kipper 10:59
11:01 kj joined 11:02 kid51 joined
kid51 Good morning #parrot 11:02
kid51 is testing gabor's new Padre IRC client
... which can be found at padre.perlide.org/irc.html 11:03
It's basically a wrapper around mibbit (for the time being)
szbalint which is mibbit in disguise 11:04
:)
heh, latency--
11:06 jimk joined
kid51 What this means, of course, is that if I use my regular IRC client, I'll get logged in with my alternate nick ... 11:07
jimk ... and then the two sides of my personality can publicly argue with each other :-)
kid51 The Mibbit interface serves up ads. Am seeing, "Train Your African Grey: Earn Your Parrot's Love in Minutes. You'll Never be Bitten Again!" 11:09
11:09 einstein joined 11:25 xenoterracide joined 11:29 xenoterracide joined 11:32 fperrad joined 11:34 masak joined 11:43 uniejo joined 12:11 JimmyZ joined 12:18 whiteknight joined
whiteknight good morning #parrot 12:24
12:28 fperrad joined
moritz does 'make install' now also imply 'make install-dev'? 12:32
12:36 tetragon joined
moritz I'm getting an error trying to build rakudo on parrot trunk 12:39
/scratch/mlenz/rakudo/parrot_install/bin/parrot: symbol lookup error: /scratch/mlenz/rakudo/parrot/runtime/parrot/dynext/math_ops.so: undefined symbol: Parrot_pcc_get_context_struct
that's during the step that compiles the setting to PIR
has anything been changed regarding installation of math dynops?
(on amd64 linux btw) 12:40
jonathan moritz: Yes, make install is make install-dev now - they're aliases. 12:52
moritz jonathan: so we can remove that part of rakudo's README - great
jonathan nod
dalek kudo: 3ec4d40 | moritz++ | src/setting/Operators.pm:
implement Bool eqv Bool, be more verbose in error message in cases where eqv is not yet implemented
 13:01
kudo: c0ba847 | moritz++ | README:
[README] "make install" in parrot is now sufficient
TT #1156 created by whiteknight++: add_sub should append to a MultSub 13:03
whiteknight moritz: make install is what make install-dev used to be
13:10 particle joined
dalek TT #1157 created by whiteknight++: Whitespace before/after the dot in a methodcall is disallowed 13:16
whiteknight Down to 145 RT tickets now 13:32
I'll make another pass through the unowned tickets later to pick more low-hanging fruit 13:37
Coke iotasklist. (being able to gets on a socket would be nice.) 13:39
whiteknight: thanks. 13:40
13:40 fperrad joined
Coke whiteknight++ 13:40
whiteknight: have you been cc'ing the list when closing tickets?
whiteknight ...I don't think so 13:41
doesn't it do that automatically?
(or is that Trac?)
Coke whiteknight: that's trac.
(this is why I mentioned explicitly in my email about RT)
whiteknight ah damnit. Then no, I haven't cc'd the list
next time :) 13:42
Coke OK. especially if you closed tickets without opening them in RT, and you weren't the OP, it would be nice to have those cc'd to the list.
s/in RT/in TT/
whiteknight I did open trac tickets for the ones that weren't obviously, or weren't completely resolved 13:43
Coke did you take ownership of the ones you closed? 13:46
(just wondering if we can get at a list of those tickets via the GUI)
(of course, rt is HTTP 500 now.)
dalek rrot: r42156 | jonathan++ | trunk/compilers/pct/src (3 files):
[pct] Add initial bits of support to PAST and POST for handling :call_sig parameters.
 13:49
13:49 nopaste joined
Coke ah, there's a lastupdatedby 13:49
got 'em 13:50
I'll just cc the list with your last commetn. 13:51
jonathan whiteknight: ping 13:52
13:54 payload joined
Coke whiteknight: done. 13:54
13:56 payload joined
whiteknight jonathan: pong 13:56
jonathan whiteknight: oh hai 13:57
whiteknight hello
purl hey, whiteknight.
jonathan whiteknight: First, good news: I've got sub calls with :call_sig working awesome in Rakudo so far, it appears. :-)
whiteknight w00t 13:58
jonathan whiteknight: Bad news: :call_sig + :method is epic fial
whiteknight really? that bad huh?
jonathan We fail in IMCC when compiling.
With:
:call_sig must be the first and only parameter
pmichaud_ good morning, #parrot
whiteknight ah yes, I knew that stupid code would cause problems
jonathan pmichaud_: oh hai I patched PCT ;-)
pmichaud_ to add :call_sig ?
whiteknight jonathan: I needed to fix that anyway
jonathan pmichaud_: Indeedy.
pmichaud_ I'll take a look. 13:59
jonathan whiteknight: OK. I have tuits to do it.
whiteknight: And am quite happy to. I was looking more some kinda direction on it.
whiteknight jonathan: those semantic checks in IMCC need to disappear and get moved into src/call/args.c:fill_params instead
jonathan I'm guessing that we want to not bother with 'self' being extracted if we have :call_sig?
Or do we want to extract self anyway? 14:00
whiteknight I think what we need to do is add :call_sig as just another option in the parameter list and not limit to just one param
Coke (if you're talking about :method and :call_sig, don't forget about :vtable. =-)
whiteknight so we will extract self and anything else
Coke wouldn't extracting self conflict with letting call_sig manage it?
<- guessing 14:01
jonathan Coke: It may not be so bad.
whiteknight: I need to nom lunch now, I'll have a go at patching this up. 14:02
Coke question about all the "please test" tickets on RT; I wonder if those aren't better handled via a trac wiki page.
jonathan (e.g. after lunch)
whiteknight jonathan: okay, awesome. Let me know if you need any info
jonathan whiteknight: Thanks. 14:03
And whiteknight++ for doing the bits that are done so far :-)
14:03 gravity joined
whiteknight Coke++ 14:09
14:12 whiteknight joined
whiteknight something is up with the slice opcode? 14:13
moritz whiteknight: it's not tested anywhere 14:14
whiteknight oh, okay
moritz and concerns where raised if it still makes sense (see backlog :) 14:15
whiteknight I don't see a slice opcode 14:18
moritz it's mentioned in t/op/01-parse_ops.t for example 14:19
maybe that's a fossile?
if so, why doesn't taht test fail?
whiteknight maybe I'm just not seeing it 14:24
Austin Whiteknight: It's not there. But the vtable functions for it are still laying about. 14:27
And it still shows up in the docs for e.g., FPA
whiteknight gotcha 14:31
Coke ISTR slices being removed. 14:34
Coke hurls trac.parrot.org/parrot/ticket/372 14:35
but that was removing a PMC, not an op.
dalek kudo: f8fb41b | (Kyle Hasselbacher)++ | Test.pm:
[Test.pm] Teach is_deeply how to compare Bool
 14:36
pmichaud_ istr slices being removed also 14:38
at least that was the general sense of where we're headed
dalek p-rx: ff564c6 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION.
 14:44
14:44 raaggh joined
raaggh hi, 14:44
dalek a: dec6dce | fperrad++ | (3 files):
add pasttype : callmethod
 14:45
whiteknight hello raaggh
raaggh I'm looking for javascript ecma VM 14:47
Coke checkes the wiki... 14:49
moritz doesn't remember any recent activity around a js compiler for parrot 14:50
raaggh I think I need "grammar" file ? no ?
Coke code.google.com/p/parrotjs/ 14:51
particle raaggh: are you looking to create one, or use an existing one?
Coke but that's old.
raaggh @particle : use an existing one... i'm not very skilled 14:52
14:53 bluescreen joined
Coke pmichaud_: I left you a message (for pmichaud) 14:53
particle raaggh: there has been some preliminary work done on javascript for parrot, but nothing production-ready
raaggh @particle : I can help... 14:54
particle ok, then coke's link is a good start 14:55
moritz this is IRC, not twitter - no need to prepend nicknames with an @
Coke but it's not a problem. =-) 14:56
particle raaggh: however, it seems the parrotjs project has been untouched for more than a year. i suggest you contact the author for a commit bit, if you're interested in making it work with current parrot
we can help you
raaggh particle :thanks 14:57
dalek TT #1158 created by particle++: t/op/01-parse_ops.t: figure out how to test parsing of pmc constant ...
whiteknight how do I make a branch on github?
Coke wow, particle, thanks for migrating that ticket!
particle um, dalek?
purl dalek is #parrot's spammy little rss bot or (see: dalek plugins)
Coke =-)
Austin You the owner?
whiteknight Austin: yes
I want to make a branch for Matrixy 14:58
Austin Push it.
purl Oh!
Coke do you want a branch, or do you want to fork?
particle coke: did you migrate that?
Coke particle: yes.
moritz git push origin $yourbranch
whiteknight Coke: not sure I know the difference
Coke fork is "my copy of your project". branch is in your own project.
fork is another downstream copy, basically.
whiteknight then branch
14:59 eternaleye joined
whiteknight moritz: do I need to do anything special on github before I push? 14:59
Austin Like "I think parrot should just go ahead and switch to C++. Then we could get refcounted pointers!" would be a fork.
moritz whiteknight: no 15:00
Coke RT : a gross of tickets.
(btw, tickets with only the single original post are really easy to transfer over. =-)
raaggh byebye... 15:02
nopaste "Austin" at 98.235.55.43 pasted "Here's some bash goodness to make 'less' a little better - parses filename:line# into less +line# filename" (22 lines) at nopaste.snit.ch/18492
15:03 fperrad_ joined 15:09 bluescreen joined 15:10 Psyche^ joined 15:16 fperrad_ joined
whiteknight moritz: git push origin <branchname> didn't work 15:21
error: src refspec newbranch does not match any.
error failed to push some refs to ...
moritz whiteknight: seems like you didn't create the newbranch branch locally 15:22
whiteknight okay, so how do I do that?
moritz so try git checkout -b newbranch first
whiteknight ah, okay. That did it 15:23
thanks
moritz (but don't name it newbranch, of course :-)
whiteknight of course
moritz++
dalek p-rx: 9f4cd36 | pmichaud++ | build/Makefile.in:
Add 'nqp-self' target, to test-build a self-hosted copy of NQP.
 15:25
p-rx: 42e99a3 | pmichaud++ | src/NQP/ (2 files):
[nqp]: Don't rely on module BEGIN semantics anymore.
p-rx: 42ff618 | pmichaud++ | src/NQP/Actions.pm:
[nqp]: Bootstrap intermediate step

new version of nqp, move the private subs to the top so they work in both old and new versions of nqp. nqp-self target passes all nqp tests.
p-rx: 72b2520 | pmichaud++ | build/Makefile.in:
[nqp]: Self-generate actions for nqp-self target.
whiteknight okay, now how do I delete a branch? 15:27
Coke oooh, I know.
github.com/guides/remove-a-remote-branch
pmichaud_: should nqp-rx be telling us how to checkout the perl6 tests? 15:29
dalek rrot: r42157 | jonathan++ | trunk/compilers/imcc/pcc.c:
Make IMCC think it's OK to have a :call_sig in a method.
 15:33
pmichaud_ Coke: probably not. 15:41
pmichaud_ fixes. 15:42
jonathan whiteknight: oooh, I might just have made it work \\o/ 15:47
jonathan even wrote tests :-) 15:48
dalek p-rx: d9b4687 | pmichaud++ | Configure.pl:
Remove bogus note about Perl 6 spectests (Coke++).
whiteknight jonathan++ 15:49
15:50 fperrad joined
jonathan whiteknight: committed, feel free to improve, there are tests to help make sure it stays working. :-) 15:51
And hopefully this unblocks me moving Rakudo over to this.
whiteknight awesome
dalek rrot: r42158 | jonathan++ | trunk (2 files):
[core] First cut at making :call_sig work with methods. The comment about the overall call_sig implementation being experimental very much stands for this too - I suspect we could do it better - but it works and, importantly, passes all of the new tests for it.
 15:52
Coke pmichaud_: I am eager to attempt to switch tcl over.
jonathan: if the whole thing is experimental, perhaps a notice in DEP*.pod 15:53
?
jonathan Coke: No, the syntax is not experimental.
purl okay, jonathan.
jonathan Coke: Just the current implementation in args.c. 15:54
Coke k.
jonathan Coke: That is, I expect it'll end up being handled a little differently in args.c
Coke that's fine, yah, i was worried about user-facing.
jonathan But I think there's pretty wide consensus that :call_sig - the PIR-facing bit - is here to stay.
whiteknight yes, here to stay
jonathan Coke: Sure - I wasn't clear.
whiteknight ! [rejected] master -> master (non-fast forward) 15:55
what does that mean?
purl You're a nut! You're crazy in the coconut!
whiteknight and how do I make that message go away? 15:56
jonathan whiteknight: Were you doing a "git push origin master"?
whiteknight just a git push on my new branch
jonathan whiteknight: Are you in another branch?
e.g. not master?
If so, you want
git push origin branchname
whiteknight I am in a branch locally, and am pushing to a branch on github 15:57
jonathan Yes, then I think you want origin branchname, not origin master.
whiteknight so I just did "git push", and it pushed all my changes successfully, but then it spit out that error too
jonathan Oh, oddness.
whiteknight great
my first command on my first git branch and it's oddness
jonathan whiteknight: Yeah, "great" is how git makes me feel too a bunch of the time. :-( 15:58
whiteknight all I need to do is learn the incantations. My big problem is a huge dirth of helpful documentation
jonathan Doing "git push origin branchname" spits out that error?
whiteknight i don't know. I have no more commits to push right now
jonathan omfg. 15:59
PerlJam whiteknight: the remote master has changes that need to be merged with your local master, ergo the push to the master branch was rejected
jonathan My very first patch to switch Rakudo over to using call_sig not only now compiles, but passes all sanity tests!
whiteknight PerlJam: and what do all those words mean that you just said?
jonathan++
dalek p-rx: 36a6064 | pmichaud++ | (5 files):
[bootstrap]: Add stage0 versions of HLLCompiler, NQP.
PerlJam whiteknight: do a "git pull" on the master branch before you push 16:00
whiteknight for instance, I don't know what a "remote master" or a "local master" are, or why I would be pushing to one of them
I thought I was on a branch
jonathan whiteknight: The benchmarks for call-heavy stuff also show that we've gained back some from this too :-)
Austin whiteknight: You're on a branch called "master" by default.
Tene jonathan: but does it pass them faster?
PerlJam whiteknight: you're always on a branch, just that sometimes the branch is called master
whiteknight okay, I did a "git checkout -b" and now it says I am on a different branch 16:01
jonathan Tene: make test did pass a bit faster, yes.
whiteknight so I'm not on master
moritz PerlJam: not quite true :-)
Austin okay.
PerlJam moritz: don't confuse him with facts :)
moritz PerlJam: in general after a git checkout $sha you're not on a branch
particle whiteknight: git branch -l # shows you your branches, including current branch 16:02
16:02 theory joined
whiteknight particle: okay. That's very helpful. I am on a branch, not master 16:02
16:04 fperrad joined
Austin whiteknight: now, make a change and commit it. 16:04
Add a space or something.
whiteknight okay. made a commit
now push? 16:05
Austin push it, real good!
whiteknight what, exactly, do I type?
Austin git push?
purl git push is much faster than svn ci or svk push
Tene git thrust
whiteknight ! [rejected] master -> master (non-fast forward)
but the commit shows up on github anyway 16:06
Austin You've got a master/master conflict. But this is a branch.
whiteknight okay. More important question: how the hell do I make that go away?
Tene whiteknight: 'git push' is trying to push commits from all branches.
PerlJam whiteknight: git checkout master; git pull; git push # Whatever changes you've made to master are now pushed
Tene whiteknight: git checkout master; git pull; what perljam said; 16:07
Austin Resolve the conflict. ^^ What PJ said, except there will probably be a merge.
whiteknight "Everything up-to-date"
PerlJam pull == fetch + merge
PerlJam assumes Austin meant conflict
whiteknight no conflict, no merge 16:08
Austin nods.
So, push it back.
cotto_work someone should add all the fetch variants to ops.num
mikehh All tests PASS (pre/post-config, smoke (#29470), fulltest) at r42157 - Ubuntu 9.10 RC amd64
16:09 davidfetter joined
Austin Whiteknight, where's the remote repo? 16:11
16:17 fperrad joined
cotto_work whiteknight++ for a great blog post and a not-so-sneaky recruiting tool for Parrot 16:24
bold test 16:25
Austin It worked.
purl Of course it worked
moritz waits for the blinking colors
cotto_work ENOHTML
16:25 Andy_ joined
Austin reversed? 16:25
Nope.
cotto_work looks like inversed colors to me 16:26
‏backwards testfds
moritz reversed, yes
Austin Hmm. Still black on white here, but you guys see it? That's weird. 16:27
whiteknight see what?
moritz it's black on white here, but the usual text is white on black :-) 16:28
Austin Moritz, what's your client?
moritz Austin: irssi
Austin k 16:29
moritz (irssi in screen over ssh on xterm :-)
whiteknight ETOOCOMPLICATED
jonathan Heh. It wasn't until moritz wrote that, that I realized I'm doing irssi in screen over ssh on windows. :-) 16:31
cotto_work jonathan, throw in a couple of nested VMs and you're golden
moritz whiteknight: most of the time everything just works[tm], so it's not too complicated 16:32
whiteknight any time your application contains that many acronyms, it's too complicated 16:33
I'm using Chatzilla, in chatzilla over internet on Windows 16:34
jonathan moritz: It is amazing that despite sounding so convoluted, it's actually quite convenient! 16:35
einstein I just added some extra documentation to ticket #1020 16:41
whiteknight awesome 16:42
cotto_work einstein, great. Thanks. 16:43
einstein I hope it makes things a little bit more clear
I think I also will make wiki page for it some where next week 16:45
dalek a: 82795f3 | fperrad++ | src/lib/luaaux.pir:
fix lua_findtable when modname contains dot
 16:48
cotto_work einstein, I was about to copy/paste your attachment into a wiki page. 16:49
einstein ok if you can do that then it would be fine :) 16:50
cotto_work What'd be a good page name?
MakeEveryPMCAnObject ? 16:51
einstein yes
that is what is ment to do :) + it makes the isa and typeof op work better/finer 16:53
whiteknight unifying underlying representations is probably a very good idea 16:54
einstein :) 16:55
whiteknight I'm not endorsing any particular strategy, but I think the goal is good
I need to read all your new docs, einstein
cotto_work done, though it's mostly a direct copy/paste
jonathan Apart from making Parrot a more difficult target for languages that are explicitly spec'd as supporting multiple representations.
*cough*Perl 6*cough*
einstein whiteknight: yes I know :) 16:56
i have to eat
afk
dalek tracwiki: v1 | cotto++ | MakeEveryPMCAnObject
tracwiki: initial version, probably needs lots for formatting fixes
tracwiki: trac.parrot.org/parrot/wiki/MakeEv...ction=diff
whiteknight jonathan: I'm talking about Parrot native. If Parrot had one representation that was low-level and flexible, other languages would be able to build their own stuff on top 16:57
jonathan whiteknight: My point is more representations that would come from outside of Parrot.
whiteknight yes 16:58
jonathan That is, what if you wanted to have, say, a GObject and just wrap it up in a PMC?
whiteknight I don't know really, I haven't put a lot of thought into this area
jonathan You'd not want other types of object thinking they knew about its internal layout.
Right, I kinda had, but apparently the result was something that you couldn't imagine anyone thinking was a good idea. :-) 16:59
Right now we didn't embrace either way, so ended up with something less clean.
I'd really rather we thought about how to do interaction of different object layouts though. 17:00
Even if we do unify PMCs and Parrot objects.
I'm not saying that latter part is a bad idea. The two aren't mutually exclusive.
17:00 bluescreen joined
jonathan So in that sense, I'm not opposed to einstein++'s thoughts on that, I'm just trying to keep us from missing a slightly bigger picture. 17:02
17:02 kurahaupo joined
whiteknight okay, that's more what I'm talking about. Making Object more like normal built-in PMC types is a good thing I think for a variety of reasons 17:02
but I don't necessarily think that we only need one representation 17:03
jonathan Right, but the proxy infrastructure we have in place now is there because PMCs and Objects have a differnet underlying representation.
whiteknight I'm hard pressed to think of a reason for another, but I won't rule it out
dalek p-rx: dc737ba | pmichaud++ | (3 files):
[nqp]: Per suggestion from TimToady++, switch PIR::pirop to pir::pirop .
 17:04
cotto_work that'll help save my shift key from wearing out 17:07
whiteknight einstein's proposal actually looks like it might provide a performance win in some cases 17:10
although I'm having some trouble seeing why certain things are the way they are
I think it would also change some semantics in a non-trivial way 17:11
17:27 payload joined
mikehh All tests PASS (pre/post-config, smoke (#29471), fulltest) at r42158 - Ubuntu 9.10 RC amd64 17:35
dalek tracwiki: v18 | kurahaupo++ | ArrayTasklist 17:42
tracwiki: questions about "Array" PMC; added RT links
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
Tene whiteknight: I was reading through some of the IO stuff again last night. Looks like I'm starting to get interested in it again. 17:43
I'll probably be trying to work on a Select and Pipe PMC this week.
whiteknight Tene: that would be awesome 17:44
Coke cotto_work: (all fetch variants) not for experimental ops. 17:45
cotto_work ok
Tene whiteknight: I remember you saying you planned to be very busy... think you'll be able to watch out for my commits and repair or revert anything too brain-damaged? 17:50
Coke botsnack? 17:51
purl :)
jonathan Tene++ # yay, those would be great to have :-) 17:52
whiteknight Tene: of course!
I'll help too when I'm able
Austin woo-hoo! The check is in the mail. 17:54
Tene Okay, depending on what the gfs have planned for me tonight, I might be able to get started today.
Coke ^_O 17:59
whiteknight "gfs" more then one?
Tene yeah. 18:01
whiteknight has a million follow up questions, but thinks better about it 18:02
dalek p-rx: 92cc0bf | pmichaud++ | src/ (4 files):
[nqp]: Unify <noun> with <term>, per latest STD.pm changes. TimToady++
Tene whiteknight: I'd be glad to answer any questions in /msg 18:04
whiteknight ok
18:05 joeri joined
dalek tracwiki: v2 | jessevdam++ | MakeEveryPMCAnObject 18:12
tracwiki: make up
tracwiki: trac.parrot.org/parrot/wiki/MakeEv...ction=diff
einstein I just have added some make up to the wiki page, does any body have questions? 18:14
cotto_work einstein, some headings would be good too
einstein ok yes i will add them
dalek kudo: 6a43a35 | jonathan++ | (9 files):
Switch to using :call_sig for argument handling. Wins back a little performance and gets us positioned almost ready to implement nested sigs. whiteknight++ for :call_sig Parrot work. Please note: PARROT_REVISION bumped.
 18:16
cotto_work Mmmm. External dependence on experimental features.
(though jonathan already knows that)
whiteknight the feature isn't experimental, it's the lousy implementation that is
jonathan cotto_work: What whiteknight said. That feature is not going away. :-) 18:17
whiteknight: I'm not in a hurry for it, but caller side :call_sig would also be sweet. ;-) 18:18
whiteknight jonathan: I tried adding that and ran into huge problems and segfaults and stuff 18:19
jonathan whiteknight: oh gee
They sound un-fun.
whiteknight well, I was being ambitious and trying to allow any arbitrary type to be used
if only CallSignatures and polymorphs of it are used, that should be fine 18:20
jonathan whiteknight: Ah.
whiteknight a "does callsignature" role might be handy in weeding out bozo types
jonathan As far as I can see it, the "trouble" is that there's lots of interface-breaking stuff in the binder.
(e.g. in args.c)
Taht's fine - it wins speed for the common case. 18:21
But it does mean that we essentially need to work out some way for non-CallSignature thingies to operate.
Again, this isn't a huge problem.
whiteknight for instance, an RPA would be great to pass if you were only using positional parameters and no returns
or a hash for only named parameters and no returns
we need to refactor return handling before we can talk about using other types for returns as well 18:22
jonathan whiteknight: Well, perhaps...I'm quite happy that we have to support a slightly "fatter" interface though.
Than just an RPA or Hash gives.
That doesn't seem unreasonable. 18:23
It'd just be nice to know exactly what the interface is.
whiteknight I like thinking about opportunities for optimizing
jonathan At the moment though I mostly only want it because I am getting a CallSigature in, want to delegate with the exact same args, and can't just pass the same thing along but have to pick it apart instead.
cotto_work might that not be premature?
jonathan I don't actually have any need of a custom CallSignature right now. 18:24
So an initial impl that restricted to just passing on a CallSignature is enough for me.
whiteknight is P6 going to write it's own subclass?
or can it use CallSignature directly?
einstein I have to go, bye 18:25
cotto_work bye einstein
dalek tracwiki: v3 | jessevdam++ | MakeEveryPMCAnObject
tracwiki: add headings
tracwiki: trac.parrot.org/parrot/wiki/MakeEv...ction=diff
jonathan whiteknight: There's only one bit of the spec that might make me need to subclass CallSignature. 18:26
whiteknight: However I'm hoping that bit of the spec dies in a fire. :-)
whiteknight all it takes is one bit...
jonathan Yeah. But I actually think that one bit is a bad idea. 18:27
Something that was a bad idea for similar reasons actually got tossed a week or two ago.
So I'm kinda hoping this bit will go the same way. Not least because it carries extra problems...
whiteknight what's the spec? 18:28
purl rumour has it the spec is clear
jonathan whiteknight: There's a bit in S06 about dealing with multiple named parameters of the same name. 18:29
And how it means different things depending on what you bind to.
whiteknight urg
jonathan Meaning that we would have to preserve all of the name-value pairs.
whiteknight I would disallow that in a heartbeat
jonathan Yes, I'm not fond of it for many reasons.
Also it interacts weirdly with type checking, depending on how you do it. 18:30
cotto_work That's really odd.
jonathan :-) 18:32
jonathan -> shop, bbiab 18:35
18:35 mokurai joined 18:38 chromatic joined
japhb nothingmuch blogged about having his perl5 site_lib under git control: blog.woobling.org/2009/10/versioned-sitelib.html ... I've been thinking of something similar for Plumage as an option for doing the grunt work of uninstalls (after dependency changes had been dealt with). Any thoughts on the sanity (or lack thereof) of such an option? 18:48
Tene japhb: adds a dep on git. 18:49
japhb Tene, sure, but not a required dep.
Tene Well... 18:50
japhb I'm not sure there's a "correct" way to do uninstall without either depending on some external tool, or recreating one. I don't want to do the latter, and I don't want to force a dep, so I'm thinking uninstall is something a plugin provides ....
Tene Plumage needs to have enough information to do uninstalls anyway. It should know every file that it installs.
japhb Tene, how?
Sure, for manifest-based installs, yes. 18:51
But what about when it's just calling 'make install'?
Tene install to a prefix
japhb Tene, that doesn't fix the problem unless you do prefix-per-project ...
in which case library searching gets "interesting" 18:52
PerlJam japhb: +1 for optional git tracking of files.
18:52 fperrad joined
Tene Yes, exactly. You mkdir a new dir, install to it, and then move the files from there. 18:52
"Make a reasonable directory structure in the prefix I'm assigning you, and then I'll put it in the right place."
moritz that doesn't work with parrot, for example 18:53
japhb Tene, I'm not sure that works with the "installable" thing for PBC/fakecutable
moritz because it hardcodes paths to its files
18:53 bacek joined
japhb what moritz said 18:53
(Or I would have done that. :-)
If I had an API to swizzle those hardcoded paths, maybe.
treed With Debian stuff, you ./configure -prefix=/usr 18:54
japhb I don't want to go hex editing manually.
treed but then make install DEST_ROOT=foo
Tene That's... unfortunate.
treed I mean, when packaging.
japhb treed, right, but when you build debian packages, you're often doing so in a chroot.
treed So that hardcoded paths DRTR, but you can still pack the installed files into an appropriate tree.
I don't.
Really?
That's debuild. 18:55
Not everyone uses that.
japhb true
treed I just run dpkg-buildpackage
or fakeroot debian/rules binary if I'm feeling lazy
Really, you just need the Makefile to have an optional prepending path. 18:56
and then copy the files to $(DEST_ROOT)$(PREFIX)
so you end up with foo/usr/bin/bar in the case above
japhb The other problem there is that it assumes a proper debian/rules ... which in parrot parlance would mean Plumage would have to patch all the modules that don't natively support prefix != DEST_ROOT
treed Seems a little naive to assume that you can permit any given package to just install via make install without any interference whatsoever on Plumage's part. 18:57
And have it not cause issues, I mean. 18:58
japhb Well ... most of the parrot-specific modules are pulling the proper PREFIX from parrot_config, so PREFIX is well-supported right now. DEST_ROOT, not.
I mean, we can certainly make this change to parrot ... and distro packagers might like that ... but it's not what we have *now*. 18:59
treed Well, the other option is to have no idea what was installed by the package?
Tene japhb: there's also an argument for "That's wrong, we won't support that, you need to make it work better"
japhb treed, ... or to capture it from noting the changes to the FS, as by git, for instance.
Tene Decide what we need now, before we're stuck supporting something Less Than Awesome.
treed You want to scan the entire FS everytime you do a package operation? 19:00
Tene japhb: assuming 'make install' only installs to the PREFIX
japhb Tene, no argument there. I am just playing devil's advocate.
treed, just parrot's PREFIX.
treed Still a lot of files.
japhb yes, could be.
treed And what if something else changed aside from what you were doing?
japhb That's why I brought this up ... I wanted more angles than I was currently seeing.
treed Some other process changes a file, and Plumage assumes that it was part of the package install. 19:01
Could be messy.
japhb treed ... you check before and after the install. If someone changes a file *during* the install, you're right, you're screwed.
treed I think the best solution overall is to make whatever adjustments you need to know definitively what files a package installed. 19:02
japhb OK, so from this angle, it certainly sounds like making parrot be DEST_ROOT friendly would be very useful.
Tene japhb: we really need a way to say "put your files in this directory here."
yes
treed Also, has the possibility that two or more plumage packages (feathers, are they?) wants to use the same filename?
want
Having actual manifests could help a lot with figuring out that situation.
19:02 bluescreen joined
japhb treed, I haven't even started on that problem. 19:02
Tene afk 19:03
japhb Because we've got the whole Perl 6 versioning and authorities issue to deal with
The whole way that libraries are loading in Parrot is going to have to change. At the very least, the directory searching has to be pluggable by the HLL. 19:04
19:08 Andy joined
japhb Who understands the hardcoding in installed parrot libs/bins? 19:11
Don't all raise your hand at once ... 19:18
Ooh, I can just tell I'm in for some "real fun" on this one. :-) 19:22
19:22 whiteknight joined
whiteknight hello again 19:23
japhb o/
19:29 desertm4x joined 19:30 cognominal joined 19:32 darbelo joined
darbelo purl: msg japhb decnum-dynpmcs provides a make uninstall target, how would plumage handle that. 19:37
purl Message for japhb stored.
japhb darbelo, originally that's what I thought plumage would depend on. Then I realized that a module may not have the information to do a proper uninstall of itself without breaking other things. Plus, if someone clears out their plumage cache (the repo checkouts, tarballs, etc.) how do I find the correct version of the uninstall? I could just save off the Makefile for later ... but what if the project uses recursive make? 19:41
Uninstall is just a world of hurt, and I don't have a good answer for it yet. 19:42
But I'm open to all suggestions and arguments ....
Also, perfect is the enemy of good, but people get really annoyed about uninstall not being perfect. Which in itself is a bit of pressure, shall we say. 19:43
darbelo japhb: Have 'manifest installs' and a manifest-builder 19:44
plumage only does manifest install. Everything else passes through the "manifest-builder" and gives us a nice manifest we can uninstall from. 19:45
japhb darbelo, how does the manifest builder work ...? Treed and tene seem to support the idea of using DEST_ROOT to do a two-pass install -- let the project do its own normal install to DEST_ROOT (which is a temporary directory), and then plumage does a second pass to build a manifest and do the "real" install 19:46
Are you agreeing with Tene and treed's idea?
(Just to make sure there isn't a detail I'm missing)
darbelo japhb: Close to that. We install to a fake dir, and generate a Manifest. One time operation. We keep the manifest arround and use *that* to install. 19:47
If our manifest builder turns out to be too dumb for a particular project, fine, the can provide a correct manifest for us. 19:48
japhb OK. I think we're all in agreement. 19:49
Tene, treed, anything to add?
Tene japhb: yes.
japhb shoot
Tene japhb: I have a pumpkin on my living room floor.
That's all.
japhb LOL
nice
Are you planning to eviscerate it with extreme prejudice? 19:50
Tene relevant to plumage? 'sec...
darbelo Tene: That mean you do all the patching, right?
Tene something like "i'll be rather upset if we can't build RPMS etc. from plumage modules"
japhb (Treehouse of Horror)++ for having The Grand Pumpkin go on a killing spree when it sees what we've been doing to all the other pumpkins .... 19:51
Tene, No worries. I think we may end up doing half the work for the packagers, just because we have to.
treed Similarly for debs here. 19:52
japhb But I will do my best to make it so we don't do things in a way that is incompatible for the packagers.
darbelo "plumage rmp rakudo"?
s/rmp/rpm/
Tene and, um, whatever the package format is for windows.
japhb darbelo, eventually I'd expect yes, since that suggestion keeps coming up. :-)
Tene, MSI?
Tene isn't it, like, MSI or something?
I'm making shit up. I don't really know anything about windows. 19:53
treed A deb, BTW, is basically an ar file containing a tarball of that DEST_ROOT installation, and another with control files and installation scripts
So automated debs from something like that should be pretty simple.
There are .msi files.
Which are kinda like packages.
But I'm not sure they handle dependencies.
japhb IIRC, MSI was Microsoft going "Oh dear god people, we thought we could leave install packaging to people who were supposed "experts" at installation programs. But it turns out you all suck, so now we have to do your work for you. SIGH."
treed I believe they released some Shared Source tools to produce .msi files. 19:54
Tene afk teaching
Tene passes the pumpkin to treed.
treed places it on his head like a hat.
japhb While I've got people around ... 19:55
darbelo runs away
japhb I've got two ideas in extending the "nouns" that plumage can handle.
First, instead of just a project name, you can specify a path to a metadata file, and plumage will skip the lookup and directly use that. 19:56
I think that's just pure win, no real downside.
darbelo +1
purl 1
NotFound japhb: great 19:57
Tene +1
purl 1
japhb Second, I was thinking of a magic noun saying "I'm sitting in the project repo, just install the thing I'm sitting in." This would be for the active developers of the project, like pmichaud_ working on rakudo or whiteknight working on matrixy
whiteknight +1 19:58
purl 1
whiteknight 1+1
purl 2
NotFound japhb: I was about to suggest the same
whiteknight (4 +4)/(4+4)
purl 1
darbelo Inf/NaN
whiteknight (4/4) + (4/4)
purl 2
japhb Good, sounds like agreement there.
treed +1
purl 1
dalek a: e0819c5 | fperrad++ | src/lib/luapackage.pir:
fix _PACKAGE
 19:59
a: 8e0fa68 | fperrad++ | (2 files):
fix function require
japhb Any suggestions for the name of the magic "install this" noun? So far my ideas are: '.' and 'this'.
NotFound installme
TimToady phone 20:00
whiteknight instalme
Tene 'pumpkin'
darbelo plumage install this
whiteknight I don;t like "phone", doesn't make sense
NotFound whiteknight: then send a cablegram
bacek Good morning 20:01
treed i like "this"
Assuming no-one ever wants to be able to install a package called "this".
cotto_work good morning bacek
clock?
purl cotto_work: LAX: Wed 1:01pm PDT / CHI: Wed 3:01pm CDT / NYC: Wed 4:01pm EDT / LON: Wed 8:01pm GMT / BER: Wed 9:01pm CET / IND: Thu 1:31am IST / TOK: Thu 5:01am JST / SYD: Thu 7:01am EST /
bacek g'day cotto 20:02
japhb OK, thanks everyone 20:03
japhb wanders off to make lunch 20:04
20:06 whiteknight joined 20:12 mikehh joined 20:17 bluescreen joined
japhb pmichaud_, am I reading the #perl6 backlog correctly that you essentially just have 'has $!foo' and 'make install' left to do on nqp-rx before you're ready for all of us to go crazy with it? 20:38
20:38 ash_ joined
japhb has some heavy refactoring of Plumage to do that would be a bunch nicer if I could refactor directly into OO 20:38
20:49 joeri left 20:51 usaki joined 20:58 bluescreen joined, kurahaupo joined 21:04 usaki left
japhb For pulling "official" metadata, manually-created manifests, and so on out of a project's working dir, I'd like to specify a standard top-level subdirectory in which to find all of this (similar to a debian/ directory). I've got two suggestions so far: metadata/ (which seems accurate but overly generic), and plumage/ , which Close seems to have picked. I think plumage/ works fine, but anyone have any objections? 21:12
Tene none
darbelo plumage/++ 21:22
japhb: Do you have any particular manifest format in mind? I can whip one up for decnum-dynpmcs in no time. 21:23
21:23 Whiteknight joined 21:25 rdice joined
japhb darbelo, nope, not there yet 21:32
As a matter of fact, I'm just planning right now, because I've got in-laws in town, so don't have concentrated hack cycles at the moment. 21:33
For manually-created manifests, there's the problem that the install directory layout will change depending on parrot version, so can't just use a raw list of paths relative to DEST_ROOT. 21:34
Perhaps have a set of well known replacements, like @bin_dir@ and @lib_dir@, or what have you. 21:35
darbelo japhb: I would go for that, but maybe with another syntax. 21:36
darbelo doesn't like @names@
But I have grown used to makfile-y $SHOUTING_NAMES 21:37
dalek p-rx: d8b7aae | pmichaud++ | (5 files):
Refactor stage0 build.
 21:38
p-rx: e226b2b | pmichaud++ | src/Regex/Cursor-builtins.pir:
Update FAILGOAL to display line number of source if available.
p-rx: 5ccfc54 | pmichaud++ | src/ (2 files):
Some whitespace tweaks in prefix and postcircumfix rules.
p-rx: 8060ccf | pmichaud++ | src/NQP/Grammar.pm:
[nqp]: Prevent blockoids from eating trailing whitespace.
p-rx: 775500b | pmichaud++ | build/Makefile.in:
Fix nqp-test target.
p-rx: 6f44564 | pmichaud++ | src/Regex/P6Regex (2 files):
[p6regex]: Handle @MODIFIER initialization.
p-rx: a785048 | pmichaud++ | src/HLL/Actions.pm:
[HLLGrammar]: Move lexical subs to top for now.
p-rx: 5c96a9f | pmichaud++ | (8 files):
Complete bootstrapping of nqp-rx. It now builds itself entirely

the Parrot repository. It also passes all of the tests
  (except for pod comments) from Parrot's nqp test suite.
darbelo Hmm, we don't have a nqp-rx metadata file. 21:40
I'll get that going. 21:41
21:41 Whiteknight joined
japhb darbelo, call it metadata.json 21:42
Otherwise we have a chicken and egg problem trying to find it.
so plumage/metadata.json
darbelo, I'm not wedded to any @particular@ $SYNTAX for interpolation, btw. 21:43
darbelo japhb: I don't have a nqp-rx commit bit, I was going to stick it into plumage's metadata/
pmichaud_ japhb: you're correct, I'm pretty much down to the stage of needing 'make install' 21:44
japhb darbelo, oh, well, no problem then, nqp-rx.json is fine. ;-)
pmichaud_, EXCELLENT. 21:45
pmichaud_ I don't have 'has $!foo' yet, but it shouldn't be difficult and I know how to do it
japhb great.
do you have closures?
pmichaud_ I don't know, actually. :-)
japhb (Would make the syntax for try() way less horrid, for one thing) 21:46
pmichaud_ I could use a test for closures.
japhb But closures would be Dang Useful in a number of places.
pmichaud_ tests would make closures happen faster.
japhb heh
pmichaud_ did you see the pir::op syntax?
japhb Not the most recent changes.
pmichaud_ basically, one can get directly at a pir opcode
without having to use Q:PIR or fetch lexicals 21:47
thus:
my $char = 'h'; my $ord := pir::ord__Is($char);
Whiteknight how do I pull down a branch of my repo from github?
pmichaud_ the "__Is" tells what arguments to expect
for opcodes that PAST already knows about, that part is optional
(and we can add opcodes to PAST) 21:48
japhb Any doc on the mapping for the __Is part?
pmichaud_ in PAST::Compiler, yes
japhb OK
pmichaud_ basically it's a signature, I == int register, N == num register, S == string register, P == pmc register 21:49
i == any integer register or constant, n == any num register or constant, s == any string register or constant
so "ord__Is" says the opcode returns an int register and expects a string register or string constant argument
japhb "Takes any string register or constant, returns int register"
jinx 21:50
pmichaud_ exactly.
v == void
so, pir::ord__Is($char) replaces
dalek trixy: d907536 | Whiteknight++ | Configure.nqp:
Comment out the stuff that checks for parrot-linear-algebra. Not ready for that yet
trixy: ef19323 | Whiteknight++ | :
Merge branch 'master' of git@github.com:Whiteknight/matrixy
pmichaud_ Q:PIR { $P0 = find_lex '$char'; $S0 = $P0; $I0 = ord $S0; %r = box $I0 } 21:51
(where those all had to be on separate lines, of course)
japhb nodnod
very nice indeed. 21:52
pmichaud_ things I'll probably add soon
japhb Q:PIR{} still works though, yes?
pmichaud_ yes, Q:PIR{} is still available.
japhb excellent
pmichaud_ I'll probably add sub MAIN(@args) { ... } to tag a sub as :main
japhb w00t 21:53
pmichaud_ and I suspect I'll add INIT { ... } to cause statements to be run at :load/:init
japhb Going to make an attempt at CATCH {} ? 21:54
pmichaud_ thinking about it, yes.
I'd like there to be a try/catch
japhb dances a little jig
moritz CATCH is a sack full of rats
japhb Any try/catch syntax would be nice. Keeping with the "proper subset" is just frosting for me. :-)
darbelo catches a rat that scaped from moritz's sack. 21:55
Whiteknight how do I undo a commit in git? 21:57
treed How far back is it?
pmichaud_ git revert <commit-id>
to rever the last commit, git revert HEAD^
bacek_at_work Whiteknight, if it's not pushed - git rebase -i HEAD~10, delete line with commit. 21:58
21:58 Patterner joined
Whiteknight apparently a branch merged and I didn't tell it to do that 21:58
I'm becoming very frustrated by branching in git, which I was lead to believe would not be the case 21:59
pmichaud_ Whiteknight: it's frustrating until you grok it, at which point it's like "oh, that's so easy"
japhb Whiteknight, ... oh, what pmichaud_ said. 22:00
Whiteknight that may be, but groking it is turning out to take a long damn time
darbelo Whiteknight: You are not loving the DAG, you need to love th DAG.
Whiteknight all the while I am unable to do even the simplest operations
japhb With the extra bit that not only does it suddenly become easy, but you realize why the merging sucks less.
moritz Whiteknight: a branch merge is no big thing in git, it might just mean that you and somebody else made a commit between the last pull
treed progit.org/book/ch3-0.html 22:01
Whiteknight I have a branch on github that I created from a different computer. How do I get that branch here on this computer? 22:02
my last attempt apparently caused that branch to merge
or, merge to master
dalek trixy: cb2d7eb | Whiteknight++ | Configure.nqp:
Revert "Comment out the stuff that checks for parrot-linear-algebra. Not ready for that yet"
japhb git checkout -b foo remotename foo
bacek_at_work Whiteknight, git checkout --track -b branchname origin/branchname
Whiteknight what are foo and remotename? 22:03
treed foo is the branch name
remotename is probably origin
japhb Whiteknight, bacek_at_work remembered the / that I forgot
(one thing that bugs me about git. I know there is a reason for some things to have a / and some not, but it still annoys me)
Whiteknight I'm not sure how anybody is supposed to learn this stuff from the documentation 22:04
treed What documentation is this?
Whiteknight any. the git man pages, the help docs on github, anything I can manage to find on google
darbelo Whiteknight: There's documentation?
treed progit.org 22:05
purl progit.org is really good
treed Indeed, purl.
purl indubitably
Whiteknight I've been reading a lot of stuff, and still can't manage to figure some simple things out
ash_ for git, i like: www.gitready.com/ and cheat git 22:06
cheat.errtheblog.com/s/git is the cheat reference
Tene Whiteknight: I learned it by reading the man pages and a few pieces of www.kernel.org/pub/software/scm/git...anual.html
ash_ between those two I have figured out most of the things i have problems with, with git
treed progit.org/book/ch3-5.html 22:07
the section "Tracking Branches" specifically addresses your earlier question
Tene I've had it easy, though. It always just seems to match my default inclinations, which seems to not be the case for everyone.
treed Indeed. I doubt if I match your default inclinations. 22:08
Since you seem to be into chicks and all.
Whiteknight I find a lot of the vocabulary to be very confusing, and a lot of the command-line incantations to be complete jibberish
I can understand the operations, it's finding a way to tell the computer to do them that's frustrating me 22:09
darbelo I came at git from the other end. I attended a talk about it's implementation before ever using it. Seen that way, most of the gibberish^Wincantations make sense. 22:10
22:11 payload joined
darbelo Which probably says bad things of the ui's design. 22:12
dalek p-rx: fcb7998 | moritz++ | build/gen_parrot.pl:
[build] enable parallel parrot build per environment variable
 22:13
22:21 kid51 joined
dalek rrot-linear-algebra: 16517bf | Whiteknight++ | src/pmc/nummatrix2d.pmc:
Add a fill() method to nummatrix2d
 22:46
rrot-linear-algebra: a764c8b | Whiteknight++ | :
Merge branch 'master' of git@github.com:Whiteknight/parrot-linear-algebra
22:58 tetragon joined 23:08 plobsing joined
plobsing hello 23:09
dalek rrot: r42159 | jkeenan++ | trunk/config/auto/arch.pm:
Applying auto::arch part of patch submitted by Andy Dougherty in TT #423 to refine config step on Solaris.
 23:10
kudo: fcdf3e8 | moritz++ | src/setting/Complex.pm:
whitespace fixes in Complex.pm
 23:16
kudo: 8cf27e5 | moritz++ | src/ (3 files):
move sign() to setting, also implement the method form
Whiteknight hello plobsing 23:28
git-people: how do I see how many commits I have on my machine that have not been pushed
?
or, the raw commit difference between myself and the master on github (because it may have commits I don't have) 23:29
treed you just want a diff?
or a list of commits?
moritz git log HEAD..origin 23:30
add a -p option to also see the diff
bacek_at_work moritz, origin..HEAD :) 23:31
moritz erm, whatever ;-) 23:32
23:47 patspam joined 23:56 ash_ 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!