parrot.org/ - clean up those smolders for the release!
Set by moderator on 20 October 2008.
00:09 AndyA joined
pantherse particle, looks like mk_language_shell.sh produces code that doesn't error out on make test anymore. However, it appears that make test on parrot root now spits out an error 00:12
00:13 dmknopp joined
nopaste "pantherse" at 69.233.246.105 pasted "make test on parrot root dir output" (561 lines) at nopaste.snit.ch/14341 00:13
pantherse before the 32061 revision I didn't get an actual error code from gmake, thought I'd let you know 00:14
chromatic pantherse, those are non-functional tests that we're not going to run by default any more. 00:17
Don't worry about them; all of the functional tests of things that matter passed. 00:18
pantherse ok, just making sure. I figured it's okay per the last few messages.
chromatic We had a long discussion about this earlier today, actually. 00:19
I've corrected the appropriate files and am re-running the test before I commit a fix. 00:20
00:25 grim_fandango__ joined
dalek r32062 | chromatic++ | trunk: 00:26
: [lib] Fixed SVN properties on new file Parrot::Test::Util.
diff: www.parrotvm.org/svn/parrot/revision?rev=32062
chromatic make testj works on x86-32/Linux 00:35
make testC has some segfaults. 00:39
The testC problems look like the same weird context problems we have with Parrot -> NCI -> Parrot control flow in the slow core. 00:44
make testf works on x86-32/Linux 00:47
make testg works on x86-32/Linux
make testj works on x86-32/Linux 00:48
make testr has the same failure as last month on x86-32/Linux 00:50
make testS has plenty of problems 00:51
It looks like testC and testS have the same types of problems. 00:52
Whiteknight I didn't even know we had all those make targets! 00:53
00:54 rdice joined
chromatic They run through make fulltest. 00:55
examples/benchmarks/overload.pir has deprecated add_multi syntax. 01:04
Whiteknight don't open a ticket, we're so close to 600!
chromatic I'll just fix it in place. 01:07
dalek r32063 | chromatic++ | trunk: 01:08
: [examples] Replaced deprecated add_multi op with :multi declaration on multisub.
diff: www.parrotvm.org/svn/parrot/revision?rev=32063
particle thanks for cleaning up my commit detritus, chromatic 01:09
chromatic You'd do the same for me.
particle and i have. :)
particle looks at svn log for the past month
just under 1k revs 01:10
ok, <900 01:11
i've got to get these five tests passing
and i'd love to apply some patches from p6c
e.g. the doc patch from ovid 01:12
# compiler_6.obj : error LNK2001: unresolved external symbol _PMCNULL
chromatic Whiteknight, there's a segfault in examples/benchmarks/oofib.pir. Want to stab it?
Whiteknight can't tonight, but if it's still here tomorrow I can 01:15
oh shoot, I need to update NEWS with some of the stuff I've been doing 01:16
Whiteknight goes to look at the SVN logs now
particle svn log -r 31199:HEAD | gvim -
Whiteknight svn log -r 31199:HEAD | medit - 01:17
I never got into the swing of vim or it's kin
particle i never got away from it
Whiteknight back when I was first learning it, I left my computer on for 4 days because I couldn't figure out how to exit it 01:18
particle it's an editor with line noise commands... perfect for this perl programmer.
chromatic src/multidispatch.c is broken with regard to CPointer 02:33
It's setting CPointer to stack locations, which isn't going to work. 02:34
Infinoid is that related to the issues I'm seeing?
chromatic Looks like it. 02:35
Add this at line 170 in src/pmc/cpointer.pmc
fprintf( stderr, "Set %p pointer to %p\\n", pmc, value );
then ./parrot examples/benchmarks/oofib.pir
Set 0x80db55c pointer to 0xbfc3cec0 02:36
Set 0x80db2bc pointer to 0xbfc3cec0
Set 0x80db0a8 pointer to 0xbfc3cec0
Set 0x80dae5c pointer to 0xbfc3cec0
0xbfc3cec0 is way outside of any PMC pool... and it looks like stack storage, though I haven't checked the process map to be absolutely sure. 02:38
Infinoid it sure does
Infinoid updates to r32063
chromatic I'm not sure the varargs unpacking code is correct in Parrot_mmd_add_function, even.
But that's a matter of taking one * off of STRING ** and PMC **. 02:39
02:41 ab5tract joined
chromatic That means CPointer's set_pointer has to dereference value pointers and merely copy pointers. 02:42
Infinoid ah. now that ccache isn't trying to go over an nfsmount over a slow VPN, things are actually building at a reasonable pace. (oops) 02:44
chromatic No reason we couldn't combine all of those operations in to set_FOO_keyed_str, where the key is the STRING type. 02:48
Infinoid infinoid@chirp parrot-trunk % ./parrot examples/benchmarks/oofib.pir
Set 0x994150 pointer to 0x7fff4ec3a5b8
Set 0x993d60 pointer to 0x7fff4ec3a5b8
[snip a bunch of pages]
Set 0xa1c190 pointer to 0x7fff4ec3a5b8 02:49
Set 0xa1be10 pointer to 0x7fff4ec3a5c8
zsh: segmentation fault ./parrot examples/benchmarks/oofib.pir
chromatic 0x7fff... definitely looks like stack space.
Infinoid yep, confirmed by /proc/[pid]/maps 02:50
I'm seriously considering turning off this stack randomization stuff gentoo does. The numbers aren't consistent between runs, which make this kind of thing harder.
03:24 apeiron joined 03:31 Zaba joined 03:38 apeiron joined 03:40 allison joined 03:42 apeiron joined
chromatic Infinoid, look at Parrot_mmd_multi_dispatch_from_c_args though. 03:43
With a signature like PP->I, the INTVAL is a pointer to an INTVAL.
See cmp in src/pmc/default.pmc for example. 03:44
In that case, the pointer *can* be to a stack location, because it's to a prior call. 03:47
Infinoid hmm 03:48
that sounds dangerous
chromatic Parrot_mmd_multi_dispatch_from_c_args(interp,
"cmp", "PP->I", SELF, value, &retval);
It's an out parameter.
Infinoid so what's to stop that spot on the stack from being overwritten? 03:50
shouldn't it be copied to some more stable location when wrapping a PMC around it? 03:51
chromatic In theory, the PMC shouldn't outlast that call frame. 03:52
Infinoid an "out parameter" is a return value, right?
chromatic yes.
Because the MMD function doesn't know the arity of the function being called, you pass in pointers to locations where it will store the return values. 03:53
Infinoid so you allocate something on the stack and return it, thereby "freeing" your section of the stack... then the caller goes and calls something else that uses a lot of stack... crunch?
chromatic INTVAL retval;
/* Don't multidispatch if you've got two pointers to the same PMC. They
* are equal. */
if (SELF == value)
return 0;
Parrot_mmd_multi_dispatch_from_c_args(interp,
"cmp", "PP->I", SELF, value, &retval);
return retval;
retval's a stack variable, so &retval is a pointer to a stack location, but return retval is fine because it returns a value, not a pointer. 03:54
Infinoid ok, that makes sense. sorry, I thought we were talking about pointers to pointers
chromatic Me too, but we're not here. 03:55
03:57 Ademan joined
Infinoid what's a "PPP->P" signature? I'm not sure how to read that. 04:02
takes 3 PMC arguments, returns 1 PMC?
chromatic Yes. 04:03
Infinoid cool.
chromatic allison, how does a CallSignature set return values through a CPointer PMC? 04:05
Anyway Infinoid, that's why our backtraces were showing that BigInt and FixedIntegerArray and such were changing the value of the pointed-to value. 04:10
Infinoid ok, that makes sense 04:14
unfortunately, I think the memory containing this pointer got freed somewhere.
chromatic We probably need to invalidate the CPointer PMC after we've finished manipulating its results. 04:17
04:27 tetragon joined
nopaste "chromatic" at 69.64.234.10 pasted "Invalid CPointer After Setting Its Return Values" (49 lines) at nopaste.snit.ch/14342 04:28
chromatic Infinoid, try that. It fixes things for me.
dalek r32064 | chromatic++ | trunk: 04:31
: [t] Fixed benchmark output results from floating point precision patch.
diff: www.parrotvm.org/svn/parrot/revision?rev=32064
Infinoid t/op/bitwise....ok
examples/benchmarks/oofib.pir runs to completion, too 04:32
chromatic That's definitely an improvement.
Infinoid absolutely. going through a "make test" now 04:33
ab5tract is making smoke 04:37
Infinoid All tests successful. 04:39
chromatic++
04:40 donaldh joined
chromatic Committing now. 04:40
Infinoid out of curiosity, what's the s/results/returns/ part about?
chromatic See set_attr_str in the CallSignature PMC. 04:42
Future-proofing.
dalek r32065 | chromatic++ | trunk: 04:46
: [src] Made return-to-C parameter handling invalidate any CPointer PMC used to
: store out parameter pointers. Without this, any GC which somehow marks a used
: CPointer PMC may attempt to mark a location on the C stack as if it were a
: pointer. That should frighten you. See RT #59880 for an example of the
: consequences.
: If CPointer PMCs get re-used, this may be a problem, but if you re-use a
: CPointer PMC, you're probably going to abuse your C stack in a very bad way
: anyway, and I may not help you, so don't do that.
diff: www.parrotvm.org/svn/parrot/revision?rev=32065
chromatic Hm, perhaps I should eat. 04:47
Infinoid oh hey, good idea. 04:48
ab5tract is making smoke again 05:08
good shit yall ;)
dalek r32066 | moritz++ | trunk: 05:32
: [rakudo] Update README with instructions on how to run individual tests.
: Patch courtesy by Ovid++. Closes [perl #60016].
diff: www.parrotvm.org/svn/parrot/revision?rev=32066
05:39 TimToady joined 05:40 diakopter joined
Infinoid chromatic: I've closed #59880, thanks again. 05:59
z &
06:05 rajit joined 06:10 uniejo joined
allison chromatic: still around? 06:26
chromatic: ah, looks like you've got it sorted, and no longer need the answer to the earlier question 06:38
chromatic: giving the CPointer an empty signature, clever 06:40
06:43 Patterner joined
chromatic It might not even be worth marking anything in CPointer. 06:56
allison chromatic:possibly not, though if GC did run in the middle of a call, then it's useful to know that a string or PMC return value isn't going to be collected before the call completes 07:07
07:08 spinclad joined
allison (in theory, it will be marked by the calling context, but can't necessarily guarantee that) 07:08
allison sleeps, early to airport tomorrow 07:09
07:16 bacek joined 07:30 cosimo joined 07:34 tetragon joined 07:56 iblechbot joined
bacek evening 08:16
moritz: around? 08:17
msg moritz There is 'sprintf' and 'chomp' is Str.pir in "todo" section. Looks like they already implemented 08:19
purl Message for moritz stored.
08:29 tomyan joined 08:49 TiMBuS joined
dalek r32067 | fperrad++ | trunk: 09:02
: [install]
: - remove Perl modules dependencies
: - this script must be shipped (see RT #58852)
diff: www.parrotvm.org/svn/parrot/revision?rev=32067
09:04 Zaba joined 09:12 Debolaz joined 09:49 kj joined 11:06 Bzek joined 11:18 Bzek joined 11:22 gaz joined 11:28 ruoso joined 11:33 masak joined 11:42 nopaste joined 12:00 TonyC joined 12:03 Lorn joined
moritz I won't be there for #ps today, but I have nothing interesting to report anyway 12:29
12:44 davidfetter joined
ruoso wonders if anyone is aware of www.perlfoundation.org/perl6/index....tionformat 12:59
masak is it release day today? 13:00
13:03 gryphon joined
Infinoid I think so, yes 13:04
13:09 donaldh joined 13:15 xiaoyafeng joined
Infinoid infinoid@tweet ~/parrot $ ./parrot examples/library/pcre.pir asdf as 13:16
asdf =~ /as/
1 match(es):
Segmentation fault
purl (Core dumped)
13:16 jhorwitz joined
nopaste "Infinoid" at 75.28.74.251 pasted "backtrace (bufstart pointer is null)" (34 lines) at nopaste.snit.ch/14346 13:17
Infinoid NotFound: I think that's the same error you were seeing. 13:18
./parrot -G runs fine, of course. 13:20
13:25 Wknight8111 joined
particle masak: yes, i release today 13:34
Wknight8111 particle++ 13:36
particle moritz++ for applying ovid's patch before me 13:37
Wknight8111 the karma fairy sprinkles liberally!
particle :)
i *really* hate releasing parrot with known segfaults
Wknight8111 There are known segfaults? Which ones? 13:41
and have you started the release process yet? Is it too late to update NEWS and stuff? 13:42
jhorwitz Wknight8111: i submitted #60030 last night. chromatic and i worked on it before, but i was able to get a nice test case this time.
you're local, so if you fix, you could collect your beer in person. ;-) 13:44
PerlJam particle: just remember that perl 5 AFAIK can still be made to segfault.
Wknight8111 great, now I have to take a look at it
PerlJam (I haven't played with 5.10 much, so they may have fixed most of the segfaults)
particle Wknight8111: please update news, i haven't started the release yet
will probably be a few hours, as i'm getting paid for work atm :) 13:45
Wknight8111 yeah, me too :)
jhorwitz has a sudden guilt trip and gets to work...
dalek r32068 | Whiteknight++ | trunk: 13:46
: [NEWS] Update NEWS with an IMCC change I made this week.
diff: www.parrotvm.org/svn/parrot/revision?rev=32068
14:02 barney joined
pmichaud particle: what's the release eta? 14:09
Wknight8111 he said it's going to be a few hours 14:11
I'm more interested in what the release version and release name is going to be!
and I really should be taking good notes if I'm going to have to do this in december 14:12
DietCoke Wknight8111: the notes are already taken. docs/project/rel*
feel free to do a dry run to practice. =-)
Wknight8111 trust me, I've already done one or two on my machine 14:13
I thought about scheduling the day off work too, but I don't have any vacation time left and I need the money too bad
DietCoke money++ 14:15
pmichaud I'm not in favor of a release that regresses, though.
DietCoke which regressions are you referring to? 14:18
pmichaud the inplace math ops
DietCoke I didn't realize we had any failing tests on that.
(I've pretty much given up on this release for tcl, though, so haven't been following much else.)
pmichaud #59788, but apparently there are more.
particle pmichaud: yeah, i want that fixed 14:20
i may hold over until tomorrow for it, if we see a solution in sight 14:21
DietCoke I added it as a dep on the release ticket.
particle Wknight8111: the release number is 0.8.0
i haven't even put two minutes thought into a name
DietCoke I didn't realize it was a showstopper.
pmichaud inplace might not be a showstopper, but we keep finding more fundamental failures in Parrot so I'm curious how many more are left. 14:22
DietCoke are we adding failing tests for these failures? 14:23
(not that we'd have noticed them given that smolder's been dying for about a week) 14:24
pmichaud yes. #59788 has tests.
#59630, too.
14:25 grim_fandango joined
Wknight8111 8.0? nice! 14:29
or, 0.8.0
DietCoke 0.8.0 14:45
note that 0.9 is NOT the last point release, a source of much confusion.
PerlJam People won't be confused any more when 0.10.0 comes out :)
DietCoke perhaps we should just jump to that. =-) 14:46
14:50 silug joined
dalek r32069 | pmichaud++ | trunk: 15:16
: [rakudo]: per #parrot, remove 'codetest' from 'make test' target
diff: www.parrotvm.org/svn/parrot/revision?rev=32069
Wknight8111 What's the criteria to updating to 0.x.0 or 0.x.y? How do we decide whether it's a major or minor point release? 15:18
pmichaud addition of a major milestone feature causes a major point release 15:19
Infinoid isn't it a milestone thing?
pmichaud in this case, mmd
Infinoid cool.
particle Wknight8111: www.perlfoundation.org/parrot/index...e_planning
things are a little out of order there, but we keep adjusting
pmichaud: are you ready to call ast 'complete'? can't remember if that milestone has been paid 15:20
actually, are compiler tools complete, too?
pmichaud milestone for ast implementation is paid 15:21
particle where complete is >>80%
pmichaud but not for ast documentation (still needs to be done)
oh, maybe I have that backwards
I think we've already done ast impl and doc, but only compiler tools impl
particle that sounds right to me 15:22
pmichaud (i.e., we're still missing compiler tools doc)
adding that to my hiveminder list....
particle unless you count kj++'s tutorial
Wknight8111 hiveminder! I started using hiveminder about a week ago, and I love it! 15:24
it's turning my entire life around
Infinoid wow. with a glowing review like that, how can I not check it out
pmichaud what's really nice is being able to manipulate my hiveminder lists from irssi :-)
Wknight8111 I haven't watched more then 15 minutes of TV since I got organized with hiveminder. Having a todo list right there in my face is amazingly motivating 15:25
pmichaud since I already have irssi open anyway, it's nice to just be able to type "/todo add compiler tools documentation [perl]" and have it go onto my list.
particle hiveminder++
wish it would work on my phone, att--
so, should i pop the release number to 0.9.0 based on ast completion? 15:26
pmichaud no
i'd still only go to 0.8, even if there are multiple milestones achieved. 15:27
Wknight8111 What all milestones have been acheived this month?
I know we did the MMD stuff, what else? 15:28
particle ok, i'm renumbering the release plan now
dalek jerry.gay+openid@gmail.com | Release Planning:
link: www.perlfoundation.org/parrot/index...e_planning
particle mmd/concurrency
Wknight8111 I can't wait till we can finally get that GC milestone tackled! 15:29
until that problem gets resolved, my sanity is going to be tenuous at best
especially with daily hiveminder emails about it in my inbox! 15:30
particle currently, gc is scheduled for release 0.13 :)
Wknight8111: take a week off the reminder emails for your sanity 15:31
just postpone it, you're not going to work on it anyway
Wknight8111 ...that sounds like a challenge!
DietCoke particle: works fine on my at&t phone. =-)
dalek r32070 | pmichaud++ | trunk:
: [rakudo]: Fix test output in 06-op-inplace.t (RT #60016)
: * Patch courtesy Ovid++ (publiustemp-perl6internals2@yahoo.com)
Wknight8111 but no, you're probably right. I won't have time to work on it for a while
dalek : * Now correctly reports failures as failures instead of misnumbered tests
: * Still some failing tests due to inplace errors (RT #59788 ?)
diff: www.parrotvm.org/svn/parrot/revision?rev=32070
r32071 | pmichaud++ | trunk:
: [rakudo]: Correct infix:<**=> operation for new 'pow' opcode (RT #60016)
diff: www.parrotvm.org/svn/parrot/revision?rev=32071
particle pmichaud: r32071 is purely a workaround, correct? 15:33
15:34 jan joined
dalek jerry.gay+openid@gmail.com | Release Planning: 15:36
link: www.perlfoundation.org/parrot/index...e_planning
pmichaud no. 15:38
it's not a workaround.
particle so, do the rest of the inplace ops need to change? 15:42
pmichaud I don't know yet
the difference for **= is that parrot doesn't have an inplace pow opcode
thus the code was doing pow a, a, b
which used to compute a**b and then store the result back in a 15:43
but now the pow opcode code something different
namely, it computes a**b in a new PMC and then sets the a register to point to the new PMC, leaving the original PMC untouched (i.e., it now acts like n_pow)
particle ah 15:47
dalek r32072 | pmichaud++ | trunk:
: [rakudo]: Fix some tests in 06-op-inplace.t .
diff: www.parrotvm.org/svn/parrot/revision?rev=32072
particle that seems wrong on the parrot side 15:48
seems to me there should be inplace pow
pmichaud eh, it's not likely going to matter anyway, at least for Rakudo. 15:49
I suspect most or all of the inplace operations are going to end up not using the inplace opcodes anyway
unless we really think we get a significant optimization from it.
in Rakudo, a op= b is likely to be implemented as a meta operator, directly becoming a = a op b 15:50
at least for most values of "op"
we're agreed that t/02-test-pm/ should disappear, yes? 15:54
particle sure, rip it out
15:54 Theory joined
pmichaud done in r32073. 15:55
dalek r32073 | pmichaud++ | trunk: 15:56
: [rakudo]: Remove obsolete t/02-test-pm/ .
diff: www.parrotvm.org/svn/parrot/revision?rev=32073
DietCoke particle: is "cd languages/pheme && make test" a showstopper for you to release?
particle what's pheme?!?! ;)
the failures are the same in pheme as for tcl, right? 15:57
pmichaud: you need to delete the testtest target in perl6 makefile
DietCoke particle: they're related. I can't say more than that with certainty 15:58
pmichaud particle: I thought I already did that. 16:00
(r32069) 16:01
particle ah, sorry i missed that one
ok, i have <30m to write an important work document, so i'm going incognito
i'll read scrollback
pmichaud np -- I have errands to run, then I need to head back to the hospital 16:05
I _may_ miss #ps today
if so, I'll post-contribute my report
(oh, for those who are wondering -- paula's having minor surgery today so I'm shuttling her to/from the hospital) 16:06
nopaste "barney" at 84.154.51.71 pasted "Has IMCC been changed WRT macros?" (36 lines) at nopaste.snit.ch/14347 16:07
16:28 sjansen joined
DietCoke barney: odd. (I'd update the label and locals to use the macro versions of same, but even with that, I can't get that last line to compile 16:34
16:49 NotFound joined
NotFound Hi 16:49
DietCoke NotFound: ho
barney Coke: I think it's the macro constants .STAT_xxxx The order of evaluation might have changed
NotFound Let's go 16:50
DietCoke is found by his high school reunion committee.
DietCoke hopes his easy-to-remember email address helped.
dalek r32074 | bernhard++ | trunk: 17:00
: [Pipp] workaround for funny macro expansion weirdness
diff: www.parrotvm.org/svn/parrot/revision?rev=32074
Infinoid All tests successful on 4 out of 5 of my linux boxes... that's a lot better than last week 17:06
particle pmichaud: let me know if you want to get spectest_regression.csv updates in before release
Infinoid my only remaining failure is the pcre test in t/examples/library.t, and I'm not sure what's different about that box. 17:07
17:17 Theory joined
DietCoke pcre version? 17:19
17:21 tewk joined
Infinoid 7.7 17:22
17:22 chromatic joined
Infinoid hmm. the GC is barfing because we're allocating a buffer with a null pointer, and then trying to dereference it later during a compact_pool run 17:22
#2 0xb7b57e46 in string_make_direct (interp=0x8050040, buffer=0x0, len=500, encoding=0x8070d88, charset=0x8072328, flags=0) at src/string.c:725 17:23
buffer=0 is wrong, right?
oh, nevermind. the pointer is set and then nulled later by libpcre, that was nice of them. 17:24
Old value = (void *) 0xb72a5904
New value = (void *) 0x0 17:25
0xb78db59e in pcre_compile2 () from /usr/lib/libpcre.so.0
NotFound NULL buffer and non zero length? 17:26
Infinoid yep 17:27
pointer=0 length=0x500
Wknight8111 urg 17:28
NotFound Smells bad to me, even if valid.
Infinoid I really doubt it's valid.
Wknight8111 tell libpcre that I hate it
Infinoid even if it didn't crash, it would leak memory
NotFound Infinoid: if (buffer) { ... } else {s->strlen = s->bufused = 0;}
Is ignored. 17:29
DietCoke smolder.plusthree.com/app/public_pr...st_failure ... that's looking pretty tragic for a near-release check. 17:30
DietCoke fires up a run on his OS X box.
Infinoid parrot's testsuite passes fine for me on 4 out of 5 boxes 17:31
this crash is the only thing preventing the 5th from passing
particle dietcoke: looks like it's a link problem, which is what's causing 5 test failures for me with t/src/ with msvc
NotFound Infinoid: from where is that call to string_make_direct? 17:32
chromatic It'd be nice to bisect that link problem down to one specific patch. 17:34
particle yes, it would.
Tene I don't have net access here, so no #ps for me. 17:36
particle checks out r31199 as a starting point
Infinoid NotFound: one moment, nopasting
barney LDTA 2009 in York, ldta.info/, might be an interesting conference
particle tene: any time to update pynie/cardinal news before release?
nopaste "Infinoid" at 96.238.213.50 pasted "gdb log" (98 lines) at nopaste.snit.ch/14348 17:37
Infinoid NotFound: see the first and second backtraces. but I don't think that's the problem... it seems to have been allocated correctly
the issue is, the pointer was unset later
particle Infinoid: when you say testsuite, do you mean fulltest or test? 17:38
Tene particle: I'll be back online around 5:00 EST.
particle tene: you may make the cut, then. thanks
Infinoid I just mean test
once that passes, I can fulltest too :)
Tene I'm on my phone right now. I don't think there are any svn clients for PalmOS. :)
(I certainly hope not!) 17:39
particle i don't need a proper patch, bullet points will do
17:39 allison joined
particle however, you may need svn log to jog your memory, i know 17:39
hey allison, travelling today?
allison yup, flying to sfo 17:40
Tene Oh, sure. I'll /query
particle from?
allison portland
purl portland is at www.perl.org/oscon/2003/portland/altis.html or (: oscon, pdx people)
particle an, no worries
Infinoid NotFound: I created #60042 so I won't forget about the issue. 17:41
particle allison: anything special i should worry about wrt release? 17:43
pmichaud particle: yes, I'd like to get spectest_regression.csv updates in today, but it may be 3-4 hours before I can do that 17:44
NotFound Infinoid: looks like the buffer is allocated, but length and bufused are set to zero.
pmichaud it's not worth holding the release for, if that's the only thing holding the release
allison particle: looks like we've had a fantastic effort at cleaning up smolder failures
particle pmichaud: i *must* be *done* with release by 5p seattle time
pmichaud that's 7p CDT -- hrm 17:45
Infinoid NotFound: yes, the values are set correctly later on in Parrot_allocate_string()
particle pmichaud: your changes can go in last, since they're not code
allison: yes, and hopefully squashing a few more before release
pmichaud particle: if I don't have it done by 3:30p PDT, it's not likely to happen.
Infinoid wonder if there's a way of telling libpcre to not null our pointer. or maybe we can just give it a bounce pointer and fixup the case afterwards
NotFound Infinoid: the setting to zero happens *after* calling Parrot_allocate_string
Infinoid NotFound: ... by libpcre
dalek r32075 | particle++ | trunk: 17:47
: [RELEASE] updates for Cardinal and numbered release as 0.8.0
diff: www.parrotvm.org/svn/parrot/revision?rev=32075
NotFound Infinoid: if libpcre manipulate string internal details, is not strange that if fails in bizarre ways.
DietCoke particle: smolder.plusthree.com/app/public_pr...tails/6473 looks good, anyway. 17:48
Infinoid it is unsetting our pointer, it must think its a string literal or something (otherwise memory will leak)
DietCoke (osx intel)
particle boy, i wish those urls were friendlier
DietCoke shorten that 17:49
purl That URL is at xrl.us/oumq7 [smolder.plusthree.com]
Infinoid nice.
NotFound: we've made an NCI call out to a library that unset the pointer we gave it, which screwed up our internals. sounds like something NCI should handle 17:50
DietCoke <B extjs.
particle friendly as in, parrot/darwin-gcc-x86_64/ or whatever
DietCoke particle: there's a tag could, I think.
particle and i'd love the test summary info at the top 17:51
DietCoke smolder?
purl smolder is sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8
NotFound Infinoid: you must not treat a buffer under control of the string subsystem as an arbitrary pointer.
DietCoke the smolder guy (mike?) has been very responsive when we ask for features. 17:52
Infinoid agreed. I think maybe we should create a bounce pointer and then give *that* to libpcre
DietCoke bounce pointer?
Infinoid we're giving it a pointer to a pointer, but that value is important to use for GC reasons 17:53
tewk Infinoid: you can tell NCI to transform a STRING to a char*, i think a 't' in the signature doesn that.
Infinoid so I want to copy it and then give libpcre the copy
so it can unset it without breaking us
s/use/us/
tewk s/doesn/does
jhorwitz finds string GC maddening 17:54
Infinoid finds NCI confusing
its being called by pcf_p_tiB3P(), if that tells you anything about the signature it's using. 17:55
tewk the B in the signature may not be right, it may need to be a t, file:line? 17:57
Infinoid typedef void * (*func_t)(char *, int, void **, int *, PMC *); 17:58
DietCoke better you get confused now than someone else at 1.0. or something.
Infinoid yeah, I don't think the char* is the problem, I think its the void**
that's pcre_compile's char**errptr argument
tewk: nopaste.snit.ch/14348 17:59
second backtrace.
tewk Infinoid: where is the pir its trying to execute? 18:00
Infinoid oh. its something called from examples/library/pcre.pir, one moment
runtime/parrot/library/pcre.pir:89 18:01
that NCI function is called by examples/library/pcre.pir line 56. 18:02
jhorwitz that doesn't look right for the signature 18:04
Infinoid its a pointer to a char* which libpcre uses to give you an error string if something breaks 18:05
but instead, we're passing a pointer to a string as an input, and libpcre is mangling it and breaking GC.
18:06 particle joined
Infinoid it is odd that this only breaks on one machine and not others 18:07
allison Infinoid: mmm, yeah, passing a pointer to a STRING in place of a pointer to a char * will certainly break things
tewk Yeah its a char* OUT type variable, I'm trying to see how to handle that. B used to be the way to do that but I don't know now.
jhorwitz i *never* got B to work 18:08
tewk B reached into the guts of buffers.
jhorwitz tried to use it in mod_parrot years ago and i gave up
tewk I think it worked before calling conventions got redone.
allison we haven't changed the NCI calling conventions 18:09
Infinoid allison: well, we're giving it a pointer to the char* pointed to by the STRING... but its an output, not an input
when libpcre sets it to NULL, its really setting the STRING's pointer to NULL, which breaks gc later on.
(I think.) 18:10
allison yeah, that's giving a little too much access to STRING internals
tewk looking at tools/build/nativecall.pl:97
Zaba what does parrot use pcre for? 18:11
tewk 16172 paultcochrane # b => "Buffer *final_destination =
Infinoid well, the NCI example, for starters
jhorwitz fails at "Failed to load libpcre" even with libpcre installed. hrm.
particle pcre is optional
used as an example of linking an external library to parrot
NotFound The library linking is another issue that needs some discussion.
particle yes, i'm trying to find where it bork 18:12
tewk svn blame 16172 paultcochrane
I'm guessing it hasn't worked since pre 16172
Infinoid have we just gotten lucky and libpcre didn't try to overwrite the error pointer in most cases? 18:13
chromatic That sounds likely.
Infinoid lucky me
tewk Infinoid: It shouldn't be to hard to fix. 18:14
NotFound With code like that, minimal changes in garbage collection can break.
Infinoid tewk: great, I'm pretty clueless but I'm open to suggestion 18:15
tewk give me a minute
particle r31199 failed (t/src linking), trying r30000
NotFound "if compilation of a pattern fails, pcre_compile() returns NULL, and sets the variable pointed to by errptr to point to a textual error message. This is a static string that is part of the library. You must not try to free it." 18:18
chromatic We need to set the external flag on the STRING then somehow.
Infinoid in my case, it's just trying to write NULL to errptr, which has disasterous consequences
jhorwitz couldn't you pin it beforehand? 18:19
tewk "B" is the right answer, B is just broken. 18:21
jhorwitz touches nose
Infinoid tewk: ok. I posted that nopaste as RT #60042, but it's pretty terse, I can add your analysis to it 18:22
tewk I'm working on fixing it right now, assign #60042 to me 18:23
Infinoid great, thanks
chromatic #ps in 7 18:24
allison my flight leaves 20 minutes after #ps starts, so I'll miss question time. does anyone have any questions for me? 18:26
chromatic Why is there air? 18:27
allison So you can speak.
18:28 Ivatar joined
particle allison: if you have any suggestions for a release name, let me know 18:29
chromatic "A Golden Field of Radioactive Parrots"
kj currently it seems 'broken wings' would do, but that's kindof bad for publicity :-P
allison particle: There's the ever useful "Index of Parrot Species" www.avianweb.com/parrotspecies.htm 18:30
NotFound kj: 'Broken arrow' can be even worse X-)
allison have we used "Antipodes Island" yet? :)
NotFound Anti-pod? 18:31
chromatic #ps time
Infinoid NotFound: its just like pod, but it contains disinformation
NotFound Infinoid: I think we have several of that kind 18:32
chromatic allison, any ideas on how to unbreak Pheme? 18:33
allison chromatic: I suspect the problem is that PGE's output tree changed 18:34
chromatic: I know the problem is that Pheme's TGE rules are returning null nodes, which shouldn't happen 18:35
18:35 johbar joined
chromatic Cannot find the attribute 'application' (PAST;Op) that you asked for. 18:36
allison chromatic: okay, so PAST attributes have changed
chromatic: are you using PCT PAST or custom PAST? 18:37
chromatic PCT PAST.
transform application (PAST::Op) :language('PIR') { ... }
allison chromatic: so it's very possible that it changed out from under you
chromatic lib/ASTGrammar.pir:157:.sub '_PAST::Op_application' :method 18:38
I don't know how TGE creates the subs for the attribute grammars. 18:39
DietCoke drinks a coffee.
I think that's an OK sub name; just need to key off the types properly in the dispatch() calls. 18:40
-think-. (never did get tcl working) 18:41
Tene: allison will not be here for questions, so ask over here now.
allison chromatic: okay, I'll take a look on the plane 18:42
DietCoke de plane?
allison en plane 18:43
chromatic en passant
DietCoke check.
Tene parrot;Foo;Bar and perl6;Foo;Bar are both created as class Foo;Bar. There's an RT ticket somewhere. 18:45
I'll make mail later.
18:46 masak joined
Wknight8111 $real_job can be such a bother sometimes, like when it distracts me from #ps! 18:47
jhorwitz $real_job--
particle yeah. $real_job--. who's hiring?
Tene Or takes me to Georgia, with no wifi. 18:48
jhorwitz oh the horror!
Wknight8111 particle, I could probably get you a job here as a low-level hardware assembly guy
...not that you would want that
jhorwitz yes particle, get back over here.
particle i haven't used a soldering gun in a few months...
Wknight8111 good, we don't even have guns here, just shitty radioshack irons 18:49
particle i *didn't* get a job in pittsburgh today
jhorwitz Wknight8111: you and i require a beer one happy hour in the near future.
particle ...better than a one beer happy hour...
jhorwitz well, it all starts with one.... 18:50
Wknight8111 why, did I do something good? 18:51
jhorwitz i didn't say i was buying... ;-)
Wknight8111 haha! nice
I'm around in November if you want to get together and drink and hack 18:52
jhorwitz we're 15 minutes away. the rules state that beer must be had.
Wknight8111 Agreed 18:53
jhorwitz november it is then
masak I have a question about point 1 of bacek's comment in rt.perl.org/rt3/Ticket/Display.html?id=57652 -- what does it mean, more exactly?
because I think I can do points 2 and 3 quite easily, so I'm wondering if point 1 is easy too. 18:54
jsut|work there are 2 companies i know of looking hard for perl people in toronto.
particle jsut|work: feel free to send me the details, i'll see if they're open to part-time telecommuters 18:55
particle? 18:56
purl The most abundant particle in the universe is the moron. or spin 1/2, charge 2/3 or jerry gay or a boson. or a bozon. or a bogon or one bad mobo. or full of lies
particle particle is also mailto:jerry.gay@gmail.com
purl okay, particle.
pmichaud masak: bacek's patch is modifying PCT to allow a 'control' attribute 18:57
masak oh! didn't see the attached patch till now 18:58
masak investigates
Infinoid chromatic: you're welcome. 19:00
particle has the 'loop' refactor been done yet?
chromatic welcome? 19:02
purl Heh, not likely around here you won't be.
particle carrie fisher was born today in 1956
chromatic mmm cinnamon rolls 19:05
jhorwitz LOL
19:06 cotto joined
DietCoke I'm only using TGE because PCT can't do everything I need. I think. 19:06
Tene particle: no
DietCoke I wouldn't complain if someone ported parrot away from TGE if the plan is to ditch TGE.
particle the plan is not to ditch tge
DietCoke s/ported parrot/ported partcl/
pmichaud DietCoke: even if PCT doesn't do what you need it to, NQP might. 19:07
the "replacement" for TGE is really NQP, not PCT
particle except see my "really ugly" comment about tree walking with nqp
pmichaud I saw the comment but didn't understand 19:08
particle see the patch i emailed you
Wknight8111 purl, the plan?
purl well, the plan is to get you onto something, aevil.
DietCoke basically, I don't have a preference, is what I'm saying.
particle for $?BLOCK[0][1] { ...
pmichaud oops, I have to run now 19:09
time to head home again :-)
particle ~~
chromatic That man seems born to run.
DietCoke baby? 19:10
purl Baby me and you'll be peeing through a catheter!
masak purl, you're obscene, grotesque and obnoxious.
purl masak: sorry...
jhorwitz purl requires an anger management module 19:11
purl jhorwitz: excuse me?
cotto Great Tit would be a good release name (en.wikipedia.org/wiki/Great_Tit) 19:12
chromatic That *is* a nice name for 8
cotto although not technically a parrot
Wknight8111 and not technically unobscene 19:13
masak does it have to be?
cotto there are some nice Tits on that page
jhorwitz covers purl's ears
Wknight8111 no, we can be as obscene as we want. Everybody knows there are no women on the internet :)
cotto masak, I don't think "reverse sublimation" is a parrot either.
masak jhorwitz: way, way too late
jhorwitz :) 19:14
masak cotto: did I say it was? :)
chromatic It might be nice to pick something that's not even tangentially sexist though.
masak yes.
masak is slowly coming around to 'Octarine'
chromatic Though I do admit "Caulked Snack" was Cockney slang.
masak octarine's a nice color 19:15
Wknight8111 okay, I have to split. I have another meeting today on another IRC server. 19:17
later
19:17 Wknight8111 left
masak has there already been a Parrot release named 'Cockatoo'? 19:18
cotto hmmm. it seems like Parrot's Wikipedia page should have a list of previous releases. 19:20
masak I know some page on the web does 19:21
cotto www.parrotcode.org/docs/parrothist.html 19:22
masak hm, says here #57332 depends on merging of the pdd25cx branch. that branch is merged now. maybe something I could look into? 19:23
NotFound Some objection to "typedef struct Parrot_Context Parrot_Contex;" and get rid of parrot_context_t ? 19:27
(The lack of t in the second is a typo) 19:28
chromatic Don't care either way.
NotFound This will solve the current headerizer breakage and help prevent others. 19:29
particle if it breaks my release, i will break you. :)
chromatic Solving the headerizer breakage gets +1
particle indeed
Infinoid thought there already was a Parrot_Context typedef
NotFound particle: you must found me ;) 19:30
Infinoid: easily solvable
Infinoid oh, I see
consolidation++
chromatic jhorwitz, your string segfault example in RT #60030 doesn't segfault for me. 19:31
particle even with --gc-debug?
jhorwitz i had the same issue on 64-bit 19:32
however, the "say" after the collect would print nothing or garbage
chromatic With --gc-debug, the last say prints nothing.
jhorwitz which is obviously not the right thing to print 19:33
chromatic True.
particle infinoid: can you check svn log -r 20750
t/src/compiler.t fails to link for me, with missing exported symbol PMCNULL 19:34
NotFound chromatic: same results for me
particle in 20750, you reverted my changes since thy broke darwin
but i'm not sure there's a fix for msvc again later
NotFound Why PMCNULL must be exported?
chromatic 'Foo::Bar' is a constant string though, stored in the bytecode. 19:35
particle NotFound: actually, i think linking needs to be fixed, not pmcnull exported
NotFound From the outside, there is a function to be used to check pmc nullness instead of the macro. 19:36
particle PMC_is_null is tha function
jhorwitz chromatic: i believe the string becomes "unconstanted" after substr cuz of COW.
in the parlance of our times
particle ok, i'm hungry. sorry for the misdirection.
uncontantinople 19:37
chromatic I have an idea then.
particle unconstantinople
where are all these darned bugs coming from!?! we need less code.
jhorwitz NotFound: the embed/extend API needs PMCNULL 19:38
chromatic From New Bugsterdam.
NotFound jhorwitz: why? 19:39
jhorwitz so i can assign a NULL PMC to things
example...
from mod_parrot: Parrot_PMC_set_pmc_intkey(interp, handler, 0, PMCNULL);
sets foo[0] to an null PMC.
NotFound jhorwitz: we can solve that with a function that returns a null pmc.
jhorwitz that would work too 19:40
particle NotFound: please update NEWS with any pirric &| examples info you want added
nopaste "chromatic" at 69.64.234.10 pasted "jhorwitz: Fix for in place substr with constant source string segfault" (14 lines) at nopaste.snit.ch/14349
jhorwitz oooooh, tasty tasty patch
NotFound particle: sorry, I completely forgot it. 19:41
particle np, you have time
chromatic Add another doit('Foo::Bar') call after the first, and you see that the source string isn't modified.
jhorwitz tries it on his 2 platforms....
Infinoid particle: can do 19:43
jhorwitz needs to svn up... 19:45
Infinoid particle: I take it r20767 didn't help? 19:47
jhorwitz chromatic: can you explain why that works in 50 words or less? 19:48
particle parrot had a cow, man. 19:49
jhorwitz rolls eyes
purl You rolled a 11, jhorwitz
chromatic A string is a container. 19:50
Infinoid regarding r20750, declaring a local (uninitialized) PMCNULL variable may hide linker problems, but I'd prefer to actually solve them
chromatic When you free a string, you free its contents.
A constant string is a constant container.
Passing a constant string and modifying it in place reuses the container. 19:51
particle Infinoid: yes, you're correct with that approach
chromatic Making the string COW reuses the contents until they change, and modifies the container.
Freeing the modified string during GC frees only any copied contents.
Looks like ~60 words. Sorry. 19:52
jhorwitz segfaults
purl No whammies!
19:52 peepsalot joined
jhorwitz ah, looks like it works! chromatic++ 19:53
DietCoke segfaults works?
Infinoid the 50 word buffer overflowed
jhorwitz indeed 19:54
DietCoke ah.
jhorwitz subtle
chromatic This is probably a pattern we need to repeat in our code -- either always COW when we modify constants in place in ops, or COW constant strings passed as function arguments. 19:55
The latter seems like a more complete change.
... but this one fixes a release semi-blocker, so commit it goes.
jhorwitz ...and there was much rejoicing.
chromatic Nice test case too. 19:58
jhorwitz 3 weeks in the making. ;-) 19:59
chromatic Two line patch.
How nicely things work with simple PIR test cases! 20:00
dalek r32076 | chromatic++ | trunk:
: [ops] Added a COW when attempting to modify a constant string with inplace
: substr when passed as a parameter to a function. This avoids strange GC
: segfaults. See RT #60030, reported by Jeff Horwitz.
diff: www.parrotvm.org/svn/parrot/revision?rev=32076
chromatic Three more tickets to go until we hit 650. 20:01
DietCoke 60020 should be pretty easy. 20:03
(also, there are about 5 tickets relating to Storable version.) 20:08
chromatic Like r32069?
Or was that just the Parrot side?
Just the Rakudo side. 20:09
DietCoke his was just rakudo 20:10
chromatic Testing my patch now. 20:11
20:14 Zaba_ joined
dalek r32077 | chromatic++ | trunk: 20:16
: [lib] Removed coding standards tests from default test target (RT #60020).
diff: www.parrotvm.org/svn/parrot/revision?rev=32077
r32078 | julianalbo++ | trunk: 20:18
: put pirric in NEWS
diff: www.parrotvm.org/svn/parrot/revision?rev=32078
NotFound If we want to upset a lot of people, we can call this release: 'GOTO parrot' X-) 20:25
cotto I'm sure pirric will upset enough people as-is. 20:26
particle i just might have to call the release "Macaw-Palin" 20:30
NotFound What about 'Crisis? What Crisis?' 20:31
cotto "Parrot for President" 20:32
chromatic What should say_p output when given PMCNULL?
Stringy Undef? 20:33
DietCoke BOOM?
purl i think BOOM is the battery exploding.
Infinoid perl6 say(undef) prints "\\n" I think
NotFound Warning! Big commit! 20:34
Infinoid Danger Will Robinson
purl use POE! ohh... DANGER!
dalek r32079 | julianalbo++ | trunk: 20:36
: typedef struct Parrot_Context Parrot_Context, replace parrot_context_t usages with Parrot_Context and update headerizing
diff: www.parrotvm.org/svn/parrot/revision?rev=32079
pmichaud (say_p null) seems like it ought to throw the same exception that most other opcodes give when doing something with a null PMC 20:37
chromatic I'm thinking the fix in typeof is more useful. 20:38
20:38 allison joined
particle how was the flight, alison? 20:38
allison, even
dalek r32080 | particle++ | trunk:
: [RELEASE] NEWS updates
diff: www.parrotvm.org/svn/parrot/revision?rev=32080
allison particle: mercifully brief 20:39
particle ok, i have zero tuits to fix that link problem, so i'm skipping those tests
allison I fixed the pheme problem too
it was a separator problem
PAST nodes now report their type as "PAST;Op" instead of "PAST::Op" 20:40
chromatic The Great Divorce
purl it has been said that the great divorce is good too :) CS Lewis is wonderful
pmichaud that's just what typeof_s_p returns :-)
nopaste "chromatic" at 69.64.234.10 pasted "Make typeof_p_p return Undef instead of PMCNULL (RT #59532)" (16 lines) at nopaste.snit.ch/14351 20:42
pmichaud chromatic: is that because typeof_p_p returns PMCNULL if run on a PMCNULL argument? 20:43
dalek r32081 | allison++ | trunk:
: [CAGE] TGE now accepts classname strings that use either ';' or '::' as the separator.
diff: www.parrotvm.org/svn/parrot/revision?rev=32081
pmichaud or is there some argument to typeof that is returning PMCNULL as its class? 20:44
chromatic typeof_p_p returns PMCNULL when run on a namespace with no associated class.
pmichaud ....shouldn't it be returning NameSpace ?
allison typeof just calls VTABLE_name
dalek r32082 | allison++ | trunk:
: [CAGE] Update Pheme to use ';' separators for PAST node names (since that's
: what the PAST classes use).
diff: www.parrotvm.org/svn/parrot/revision?rev=32082
chromatic typeof_p_p just calls VTABLE_get_class 20:45
allison so, every PMC gets to decide how it'll report its string name
pmichaud $P0 = get_namespace ['Foo']; $P1 = typeof $P0; # I expect to get the NameSpace PMCProxy
allison: we're talking about typeof_p_p, not typeof_s_p
allison I should say typeof_s_p
yes
chromatic $P0 = get_namespace
$P1 = typeof $P0
say $P1
*crash*
pmichaud I think that $P1 should end up being the NameSpace PMCProxy in that case 20:46
having it return Undef is ... wrong.
allison is this an unrelated conversation I wandered into, or is it related to the Pheme problem?
pmichaud allison: unrelated to pheme 20:47
allison ok
dalek r32083 | particle++ | trunk:
: [t] skip tests which fail to link with msvc -- fix these after release!
diff: www.parrotvm.org/svn/parrot/revision?rev=32083
chromatic RT #59532
pmichaud I'm referring to chromatic's nopaste
it's causing typeof_p_p to return Undef instead of PMCNULL
I see two issues there.
First, say_p on PMCNULL shouldn't cause "boom" -- it should throw a "Null PMC exception" like most other operations 20:48
chromatic I'm comfortable with that.
allison oh, yeah, we've been changing all those Undef returns to PMCNULL wherever possible
pmichaud secondly, typeof $P0 should always return something that is class-like.
(unless overridden, of course.)
allison pmichaud: yes, Null PMC exception is right
particle i hate fulltest 20:49
20:49 Theory joined
NotFound A guideline on some doc about returning PMCNULL, NULL, or Undef will be helpful. 20:49
chromatic I'll put the Null PMC exception in place there and close the segfault ticket.
20:50 zostay joined
DietCoke I don't think anything "user facing" in parrot should be returning NULL. 20:50
pmichaud NotFound: the basic guideline I use is: PMCNULL == "doesn't exist", Undef == "exists but isn't defined"
DietCoke: hash['no_such'key'] returns PMCNULL
DietCoke PMCNULL != NULL 20:51
pmichaud I agree there, then.
sorry, I misread.
DietCoke I don't think anything "user facing" in parrot should be returning C's NULL.
pmichaud I agree.
NotFound DietCoke: mainly, no function whose result is assigned to register must never return NULL.
allison no, Undef is Perl 6
purl okay, allison.
allison PMCNULL is Parrot 20:52
pmichaud Perl 6 has no Undef
allison returning Undef as an 'error' value is Perl 6 semantics
DietCoke should we at some point commit a run of 'make headerizer' ?
allison Parrot has an Undef, but it's only provided as a utility to various HLLs
pmichaud Perl 6 returns Failure as an error
Perl 6 doesn't have an C<Undef> class. 20:53
NotFound DietCoke: I've done it right now
allison ah, so now we have legacy useless code
pmichaud oh, it gets used
DietCoke ah, so you have.
pmichaud PCT makes use of Parrot's Undef type because it can't rely on having a Perl 6 runtime.
allison okay, in the old days, Parrot returned Undef because Perl 6 wanted it
pmichaud So yes, Undef then becomes perl-like semantics
NotFound So we must deprecate the Undef pmc? 20:54
allison fair enough
NotFound: no
pmichaud PCT and PGE depend on Undef
I just want to be clear (because it's a common point of confusion) that Perl 6 itself doesn't have a "Undef" type
allison NotFound: we're just changing core types like Array and Hash to return PMCNULL instead of Undef
(have changed many)
pmichaud We still need some sort of PMC in Parrot to represent undefined values 20:55
allison but, Undef is provided for HLLs
and for tools
though, if Perl 6 has abandoned the name "Undef", maybe we should use a more generic name for the Parrot type
because that name came straight from the old Perl 6 specs
TimToady the most generic undefined type in Perl 6 is "Object"
pmichaud "Undef" works well for me in Parrot 20:56
allison well, the relevant type here would be "Failure"
but, we don't really want that
chromatic "Teenager"
Full of potential, but practically useless.
allison pmichaud: It likely wouldn't make much difference to you if it was called "Undefined" instead, though 20:57
pmichaud allison: correct, other than it's yet-another-name to have to remember.
allison pmichaud: or "Empty", or whatever
pmichaud at least "Undef" roughly correspond's to Perl 5's "undef" 20:58
chromatic "CPD"?
DietCoke allison: is that PAST::Op -> Past;Op change only if you're using some default PAST object?
allison pmichaud: yeah, but we're supporting legacy specs that never saw the light of day, seems like a silly burden to put on future language implementors
NotFound Maybe we can just use the Default pmc.
pmichaud but you're right, it doesn't make much difference to me
DietCoke: when ['PAST::Op'] changed to ['PAST';'Op'], the way that Parrot reports the typename for PAST::Op objects changed from "PAST::Op" to "PAST;Op" 20:59
allison DietCoke: it's basically whatever the output of 'typeof' is on the node you're transforming
DietCoke: so you can quickly check if you need to use "PAST;Op" or "PAST::Op"
NotFound: Default might work, though currently it's "abstract" never instantiated 21:00
dalek r32084 | chromatic++ | trunk: 21:01
: [ops] Added PMCNULL exception to say_p op to avoid segfaults when trying to
: stringify PMCNULL (RT #59532, reported by I Sop).
diff: www.parrotvm.org/svn/parrot/revision?rev=32084
allison NotFound: the scalar PMC might also work
21:01 particle1 joined
allison NotFound: but "Undefined" is more immediately obvious than "Scalar" 21:02
DietCoke rants about "Null pmc access in invoke()" with lack of stacktrace.
chromatic Pheme confirmed to work as of r32084.
NotFound Yes, for code and error messages a descriptive name is better.
allison NotFound: Also possible is creating an "Error" type, which could also contain an error message (explaining the reason for the Null return value), and allowing easy promotion to an actual exception in certain contexts or pragmas 21:03
NotFound DietCoke: if you want a stack trace, add an exception handler with hcf inside.
DietCoke a -parrot- stack trace. 21:04
allison uncaught fatal exceptions should spit out a stack trace
NotFound We have an opcode for that, if I remember well.
DietCoke unfortunately, this is a rethrow'n one.
(If it's where I think it is. which of course, i don't know at the moment.) 21:05
pmichaud chromatic: did you happen to catch my addition to RT #59778? I'm thinking that ticket should move to the parrot queue because it's not really a rakudo issue. 21:06
chromatic pmichaud, I saw that. You may be right. It could be that longjmp confuses gdb terribly. 21:07
pmichaud okay, just wanted to make sure you saw it. No rush for a fix from here. :-)
chromatic It might also be the resumable exception problem as well. 21:08
42 new + 609 open = 651
pmichaud yes, I know moving it to the queue would work in the wrong direction. Maybe I need to close a parrot ticket before I move it :-P
NotFound allison: sounds good, like Undef except that throws an exception with a descriptive message instead of "Null pmc access" in any usage other than check for defined
nopaste "Coke" at 72.228.52.192 pasted "shouldn't rethrow show the full stacktrace here?" (18 lines) at nopaste.snit.ch/14352
particle1 allison: tene's question from earlier was about class registration 21:09
particle perl6;Foo;Bar and python;Foo;Bar both register as Foo;Bar
DietCoke that is showing that the error occurred at the rethrow, making that just a throw.
allison yes, that is a bug in the current registry code
pmichaud tene's question is essentially RT #43419.
allison it's one of the reasons we started ripping out the current registry 21:10
ah, yeah, I looked at that ticket before, should have left a note
pmichaud it's also a big reason why Rakudo does things like "Perl6Object", "Perl6Array", "Perl6Scalar", etc. -- because the non-Perl6 names are already taken by the class registry for 'parrot'. 21:11
allison which is silly, since that's the whole reason for having HLL namespaces
pmichaud correct. it's also one of the reasons why I hadn't been pushing hard to get .HLL to work in Rakudo
(we now have lots of languages using PCT, though, and so we need .HLL to work so we can avoid global symbol name conflicts for things like "infix:+" 21:12
particle yep
Infinoid does another run of make tests 21:13
NotFound There is a note in oo.c:fail_if_type_exists that says: "The global type registry will go away eventually"
allison yes, that's the intention 21:14
but, it's longer away than expected
pmichaud (I don't know, I expect it to be a very long ways away. You're saying it's longer than that? ;-)
allison the quick fix (and probably also the right fix as long as we have the type registry), is to prefix all registered types with their HLL namespace
NotFound Many, many moons ;)
pmichaud OOC, would the quick fix also end up affecting typeof_s_p ? 21:15
allison well, the plan was to rip it out in the OO branch
pmichaud: no, the type registry is all through a separate interface
would have no effect on what's reported by typeof
pmichaud allison: okay, I'm a bit confused there, but no problem. Would $P0 = get_class "Integer" then need to become $P0 = get_class "parrot;Integer" ? 21:16
allison no
the registry is a hash internal to Parrot
it only keeps an association of class name to type id
get_class searches the namespace, not the registry 21:17
pmichaud ...it does?
allison yup
pmichaud hrm.
allison so maybe there's another problem here, and that is code that's searching from the HLL root namespace, instead of the true root namespace? 21:18
or vice versa
nopaste "pmichaud" at 76.183.97.54 pasted "get_class searches wrong namespace?" (10 lines) at nopaste.snit.ch/14353
allison but, for the "already registered" problem, it's just the registry
pmichaud: you would expect that to say "Perl6Integer" instead? 21:19
pmichaud I would expect it to say "class Integer not found" or return PMCNULL 21:20
allison why?
pmichaud because there is no "Integer" class defined in the perl6 HLL namespace
i.e., there's no "Integer" namespace in the perl6 HLL
allison okay, so you want no access to core parrot types when operating within an HLL 21:21
that does make sense
pmichaud no, I'm simply questioning whether get_class actually searches namespaces
allison though it's likely to seriously disrupt some code
pmichaud I think it currently looks things up in the registery
I'm not advocating for or against a position yet -- simply seeking to understand what is currently implemented
nopaste "pmichaud" at 76.183.97.54 pasted "get_class searches registry? -- another example" (23 lines) at nopaste.snit.ch/14354 21:22
allison the get_class opcode calls 'Parrot_oo_get_class_str', which searches the namespace 21:23
pmichaud I don't quite understand why get_class 'Integer' works then.
DietCoke perhaps it's a fallback? 21:24
(the result of a...)
21:24 TiMBuS joined
allison It has a default fall-back to create a PMCProxy by type number, if nothing is found in the namespace 21:24
that does use the registry
pmichaud okay, that explains it then.
I knew the registry had to be in use *somewhere*
DietCoke throws his rethrow question to the list. 21:25
Hopefully I'll be able to get tcl working with the tge updates post release. There's no status information about partcl in the repo anymore, so nothing to update pre-release.
pmichaud again, I'm not advocating for a particular design -- I'll just be curious to know what the final answer will be. (I suspect the answer belongs in RT #43419.) 21:26
also, I think it's more than just "create a PMCProxy by type number", because it works even for non-PMCProxy things 21:27
(nopaste coming up)
nopaste "pmichaud" at 76.183.97.54 pasted "get_class searches registry -- example #3 for non-PMCProxy" (23 lines) at nopaste.snit.ch/14355 21:28
pmichaud or it's creating a PMCProxy for the non-PMC type 21:29
allison that's just searching the namespace 21:30
you mean 'MyFoo'?
pmichaud yes
in example #3 it's searching the wrong namespace, then.
because the get_class is being run from the 'parrot' namespace, while 'MyFoo' is in the 'perl6' namespace.
what's really happening is that it's not finding ['parrot';'MyFoo'], so it's falling back to the type registry. 21:31
allison would have to look at 'Parrot_get_namespace_keyed_str' to see if it's falling back
but, if it is falling back to the registry there, it's a bug
pmichaud I'm reasonably sertain that ['parrot';'MyFoo'] doesn't exist. 21:32
*certain
allison a big bug, but easy to fix
I suspect it's a bug that a lot of code is relying on too
pmichaud probably not so much
there hasn't been a lot of HLL usage yet, for precisely this reason.
afaik only Tcl is making heavy use of .HLL as yet
allison yeah, it is fundamentally broken 21:33
pmichaud and as I said, I've been holding off on using .HLL in hopes that this would somehow get fixed
allison well, the registry naming is easy to fix
pmichaud (because I didn't want to be introducing a lot of broken code.)
(or, a lot of code that would break when we tried to fix it.)
fortunately most tools making use of P6object won't be affected, because they use protoobjects for their class manipulations and not stringified names. 21:34
allison (the latter is likely, unfortunately)
pmichaud we pretty much avoid making use of class string names in PCT
allison using class objects is always preferred to using string names or type numbers
pmichaud time for dinner here -- bbiah
particle time for make fulltest 21:35
21:35 mberends joined
particle ...which has failures... 21:35
21:36 Whiteknight joined
particle Whiteknight: update news with any you might have, especially regarding the book/docs 21:36
allison could we smolder 'make fulltest' too? 21:38
particle i don't know... it's multiple harnesses
Whiteknight Okay, let me look at it now 21:40
Infinoid make testC fails a bunch of stuff for me
on both 32-bit and 64-bit linux 21:41
Whiteknight done 21:44
allison off to pick up rental car 21:46
dalek r32085 | Whiteknight++ | trunk: 21:49
: [NEWS] Update NEWS with some information about what's changed in /docs/books
diff: www.parrotvm.org/svn/parrot/revision?rev=32085
GeJ q 22:00
my mistake 22:01
Good morning all.
Infinoid hi GeJ
GeJ Anyone familiar with stam_start, stm_wait and friends?
Heya Infinoid 22:04
purl Infinoid is Mark Glines <mailto:mark@glines.org>
GeJ thanks hun'
Infinoid I'm not familar with them, sorry 22:06
particle PLATFORMS updates anybody? 22:12
GeJ could it be possible to SKIP t/stm/basic_mt_4.pir? 22:16
22:17 cognominal joined
dalek r32086 | pmichaud++ | trunk: 22:17
: [rakudo]: spectest-progress.csv update: 204 files, 4407 passing, 13 failing
diff: www.parrotvm.org/svn/parrot/revision?rev=32086
r32087 | pmichaud++ | trunk:
: [NEWS]: rakudo, pct, pge updates
particle yes, but it would be best if it could be narrowed down to platform/arch
dalek diff: www.parrotvm.org/svn/parrot/revision?rev=32087
GeJ it's already skipped on darwin, and it is know to hang on cygwin (#59790), freebsd (self) and --I suspect-- randomly on linux as well ( buildbot.eigenstate.net:8040/fc6-x8...-shell_3/0 )
pmichaud particle: I think I'm done with my NEWS and spectest-progress.csv updates. 22:20
particle thanks
pmichaud I'm a little concerned about the 13 failing spectests in rakudo, though -- looking to see if those were just a timing issue or if they're still present. 22:21
particle pmichaud: i haven't done any language testing yet
pmichaud (timing issue == failing at 00:00 CDT but fixed shortly thereafter)
particle i wonder if #59788 can be fixed quickly, like **=
pmichaud that's a parrot bug 22:22
particle ah :(
pmichaud it has to do with the mmd merge, I think.
particle yep
22:22 Limbic_Region joined
Infinoid GeJ: heh, hung here on linux on the second try. 22:23
GeJ Infinoid: It hangs on my freebsd box every time. 22:25
I tried to look at it, but
1) my C-fu is close to nil
2) I got lost trying to understand the code
3) When I wanted to come here for tuits, people were already busy with some bugfixing, so I hesitated to interupt. 22:26
Infinoid its a thread race
GeJ I believe so.
Infinoid is there a ticket open for it? if not, opening one would be a good idea 22:27
in the meantime, skipping the test seems appropriate to me
GeJ there is one for cygwin
#59790
I think it appeared with mmd merge.
particle Infinoid: can you mark it skipped? 22:28
Infinoid will do
GeJ: thanks. can you can add a followup to that with your own test results?
and I'll add a note about the skip, and gdb output 22:29
GeJ Infinoid: sure, will do.
Infinoid heh, we aren't testing threads much. 22:31
after my change:
1..4
ok 1 - wait (simple)
ok 2 # skip Intermittent failures on all platforms
ok 3 # skip Intermittent failures on all platforms
ok 4 # skip Intermittent failures on several platforms
GeJ yup 22:34
Infinoid particle: done, r32088
dalek r32088 | infinoid++ | trunk:
: [t] Skip t/stm/basic_mt.t test #4 for now;
: it hangs on several platforms (cygwin, darwin, freebsd, and linux).
: This issue is tracked as RT #59790.
diff: www.parrotvm.org/svn/parrot/revision?rev=32088
particle thanks. unfortunately, this release is going out very dirty. 22:36
i can't stop smokers from reporting failures, there's just too many
pmichaud I think I found the 13 failing tests -- they may be due to a misconfig on my machine.
I'm regenerating spectest-progress.csv (at least the latest entry) now 22:37
Infinoid its ok, X.Y.0 releases have never been known for their stability :)
dalek Krishna Sethuraman | Parrot Development on Windows: 22:38
link: www.perlfoundation.org/parrot/index...on_windows
22:38 allison joined
particle oh, gimme a break! t/pharness/01-default_tests.t fails due to removing codetest 22:41
Infinoid I've taken ownership of #59790 for now. compared to the memory management nightmares I've been flailing helplessly against for the last week, a thread race seems pretty trivial 22:42
22:43 bacek_ joined
Infinoid (famous last words, probably.) 22:44
GeJ :-D 22:47
I'll be available for any patch-testing if required
now, if I could only find my bitcard credentials...
Infinoid so many sites, so little time 22:48
chromatic wishes the repository browser actually worked 22:49
GeJ svn-sync every 2 hours and feeds a local trac setup. 22:50
DietCoke (smolder multiple harness) just smolder each one with a different tag.
dalek r32089 | particle++ | trunk: 22:51
: [t] skip config tests i don't have time to understand how to modify properly before release of 0.8.0
diff: www.parrotvm.org/svn/parrot/revision?rev=32089
GeJ works fine, except when commits use the #\\d+ notation that trac interprets as local tickets.
Infinoid like my last one did? 22:53
pmichaud gotta run -- bbl
dalek r32090 | pmichaud++ | trunk:
: [rakudo]: spectest-progress.csv correction: 204 files, 4413 passing, 0 failing
diff: www.parrotvm.org/svn/parrot/revision?rev=32090
DietCoke seen kid51? 22:54
purl kid51 was last seen on #parrot 3 days, 5 hours, 46 minutes and 48 seconds ago, saying: The smolder report at r31992 was from me, and I know that I did not have Perl 6 build at the time that smolder report was run ('cause kid51 doesn't work like that!) [Oct 18 17:07:37 2008]
dalek r32091 | particle++ | trunk: 23:10
: [RELEASE] updated release info
diff: www.parrotvm.org/svn/parrot/revision?rev=32091
r32092 | particle++ | RELEASE_0_8_0: 23:11
: tagged release 0.8.0
diff: www.parrotvm.org/svn/parrot/revision?rev=32092
23:13 chromatic joined
particle ok, it's on cpan. now i need a name.... 23:15
Infinoid Smoking Crater 23:16
23:17 daxelrod joined
chromatic Sheesh, I just fixed the make testC failures. 23:18
Or at least worked around them.
Infinoid actually, Octarine sounded pretty good
particle i found a name 23:19
Whiteknight ??? 23:20
chromatic Did you already upload it? 23:21
particle yes, i did
i need to be done soon, seattle.pm beckons 23:22
chromatic Let's hope no one wants to play with CGP then with the release version!
particle i'll buy you a hot beverage if we get any unsolicited error reports for CGP this month
chromatic Seems a safe bet. 23:24
I'm not sure we can fix the code without the calling conventions branch merging anyway.
DietCoke how can you upload a version before deciding on the name? 23:26
dalek r32093 | particle++ | trunk:
: [RELEASE] are we there yet? almost.
diff: www.parrotvm.org/svn/parrot/revision?rev=32093
particle i run into this every time... how do i fix perms on Parrot::Test::C99AST? 23:37
pause perms 23:38
GeJ All tests successful, 15 tests and 610 subtests skipped.
Thanks everyone. 23:39
chromatic Is it an unauthorized release?
Generally the previous uploader has to disclaim ownership of all of those first-come/first-served modules.
dalek r32094 | chromatic++ | trunk:
: [src] Temporarily disabled CGP when re-entering runops due to MMD calls. See
: RT #60048.
diff: www.parrotvm.org/svn/parrot/revision?rev=32094
particle ok, that's pmic 23:40
pmichaud: Parrot::Test::C99AST needs pause fixing
then i can request reindex

Powered by Cro and the Raku® Programming Language.

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

Thank you!