Parrot 0.9.0 | parrot.org/ | 500 unresolved RTs left.
Set by moderator on 7 February 2009.
Whiteknight allison++ is kicking ass tonight 00:02
00:09 AndyA joined 00:30 kid51 joined 00:36 Tene joined
mikehh created ticket TT#293 - t/native_pbc/integer.t still fails for me at r36481 00:58
Whiteknight did you realclean and reconfigure? 01:03
mikehh nake realclean, perl Configure.pl --optimize --test, make world 01:05
sorry make 01:06
it worked at r36416 01:07
chromatic Do you know at which point in between it failed?
mikehh no I have been trying to track it down
it worked 15:34 [UTC] Feb 7 but failed at 23:20[UTC] Feb 8 01:10
dalek rrot: r36482 | whiteknight++ | trunk/docs/book:
[Book] Add more information about namespaces, and an example about using coroutines
chromatic r36468? 01:14
dalek rrot: r36483 | whiteknight++ | trunk/docs/book/ch04_pir_subroutines.pod:
[Book] Add another example about coroutines and how they handle parameters
 01:16
mikehh thats the one that seems most likely 01:20
01:25 gravity joined
mikehh there was a change to the test between r36416 and 36444 01:26
01:31 allison joined 01:33 Fayland joined
dalek rrot: r36484 | whiteknight++ | trunk/docs/book/ch04_pir_subroutines.pod:
[Book] more info about multis. I'm sure I have some details wrong, a lot of this is coming out of my memory
 01:41
mikehh change in r36419 but that was documentation
purl mikehh: that doesn't look right
mikehh what doesn't look right? 01:42
Whiteknight don't listen to purl, he's retarded 01:43
plus, he's a bot 01:44
or she, or whatever gender a bot has
mikehh ok
what does the message - Unknown PMC type to thaw 0 - mean 01:52
chromatic Parrot tried to thaw a PMC from bytecode, but the identifier for the PMC's type is invalid. 01:53
Perhaps someone removed a PMC so the numbers shifted down, or the PBC is invalid so it's misinterpreting some instructions. 01:56
mikehh I tried ./pbc_dump -h t/native_pbc/integer_1.pbc (and 2 and 3) and got that message 01:58
chromatic How about ./parrot !$
mikehh same message 02:00
purl same message is, like, being reinjected by prserv.net into pobox MXes
chromatic Okay, good to know. 02:01
mikehh The test generates a message - May need to regenerate t/native_pbc/integer_1.pbc; read test file and for 2 and 3 02:07
ok I followed the instructions in the test file to regenerate the first test and that now works 02:24
where are these files supposed to be generated 02:25
chromatic Manually, generally at release time or whenever someone changes the PBC format. 02:27
02:28 tetragon joined 02:35 mikehh joined
mikehh I got disconnected 02:35
anyway i manually regenerated the integer_1.pbc and 2 and 3 and the test now passes 02:36
chromatic Hard to say if they'd pass for anyone else though. 02:38
mikehh for sure - I fail to see haow to resolve the ticket or why thee files did not regenerate for me - moritz says they passed for him 02:40
chromatic They test that PBC is portable across platforms. 02:42
mikehh so the pbc files sgould be the same on all playforms? 02:43
chromatic yes 02:47
mikehh ok - let me add the info I have to the ticket - I don't know where to go from there 02:54
dalek tracwiki: v48 | particle++ | WikiStart 03:08
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...version=48
chromatic rurban or Infinoid might know better 03:11
dalek tracwiki: v1 | particle++ | ParrotVirtualAppliance 03:15
tracwiki: trac.parrot.org/parrot/wiki/Parrot...?version=1
shorten dalek's url is at xrl.us/befjg6
dalek tracwiki: v49 | particle++ | WikiStart 03:16
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...version=49
tracwiki: v2 | particle++ | ParrotVirtualAppliance
tracwiki: trac.parrot.org/parrot/wiki/Parrot...?version=2
shorten dalek's url is at xrl.us/befjhe
dalek tracwiki: v3 | particle++ | ParrotVirtualAppliance 03:17
tracwiki: trac.parrot.org/parrot/wiki/Parrot...?version=3
shorten dalek's url is at xrl.us/befjhg
dalek tracwiki: v4 | particle++ | ParrotVirtualAppliance 03:20
tracwiki: trac.parrot.org/parrot/wiki/Parrot...?version=4
shorten dalek's url is at xrl.us/befjhp
03:42 janus joined
mikehh The latest smolder test smolder.plusthree.com/app/public_pr...ails/17867 also failed these tests (not mine) 03:42
shorten mikehh's url is at xrl.us/befjjc
03:59 eternaleye joined 04:31 Andy joined
dalek rrot: r36486 | petdance++ | trunk/src/sub.c:
fixed formatting
 04:56
05:11 masak joined 05:23 mib_mhq8fu joined
mib_mhq8fu Does PMCs mean PolyMorphic Containers? 05:27
chromatic Yes.
mib_mhq8fu I saw that /docs/book does, but /docs doesn't. 05:28
chromatic Not universally updated. 05:33
mib_mhq8fu Ok, thanks :)
masak rakudo: test 06:00
polyglotbot OUTPUT[Could not find non-existent sub testā¤current instr.: '_block14' pc 53 (EVAL_16:38)ā¤called from Sub '!UNIT_START' pc 18229 (src/builtins/guts.pir:321)ā¤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527)ā¤called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1275
..(src/PCT/HLLCompiler.pir:688)ā¤called from Sub 'p...
masak rakudo: $*OUT := (class {}).new; say "OH HAI"
polyglotbot OUTPUT[OH HAIā¤]
06:09 allison joined
dalek rrot: r36487 | allison++ | trunk/docs:
[doc] More conversions for PMC backronym.
 06:09
06:22 tewk joined 06:28 HG` joined 06:38 Theory joined 06:44 rurban__ joined
dalek rrot: r36488 | pmichaud++ | trunk:
[tools]: Refactor pbc_to_exe to execute 90% faster.

when creating the .c fakecutable. This results in a 90.5% speedup for building the Rakudo fakecutable from the .pbc (improved from 174.9 seconds to 16.5 seconds on my system). Also eliminate the pbc_to_exe_gen.pl step; pbc_to_exe.pir is now static w.r.t. parrot configuration, so we no longer need to be using a Perl 5 script to create it.		 06:58
chromatic Very nice.
pmichaud I also think Parrot's buffered I/O is broken. 07:00
But I'll have to write that up tomorrow after I get some sleep.
chromatic I thought GCC time was the bottleneck in pbc_to_exe. 07:01
pmichaud no.
(as can be seen above)
I didn't change what pbc_to_exe outputs to gcc -- I only changed how it did it.
put another way -- I changed the time needed to generate perl6.c from 162 seconds to 4 07:02
(gcc takes about 12 seconds)
masak pmichaud++
pmichaud I'll nopaste my "buffering is maybe broken" test -- just a sec
07:02 jan joined
szbalint pmichaud++ # This is what I like to call "optimization" ;) 07:03
nopaste "pmichaud" at 72.181.176.220 pasted "buffered I/O might be broken -- pir test program" (26 lines) at nopaste.snit.ch/15547 07:04
"pmichaud" at 72.181.176.220 pasted "buffered I/O might be broken -- perl 5 version for comparison" (23 lines) at nopaste.snit.ch/15548
pmichaud Parrot is 15x - 20x slower at file output than Perl 5. 07:05
chromatic Sure spins the CPU when Parrot runs that one. 07:07
pmichaud I did query the FileHandle to see if it was buffered; it reported 'full_buffering'
masak the difference isn't as large over here (19s v. 4s) 07:08
pmichaud so I'm presuming it's mis-reporting or there's something else wrong there.
chromatic Oh. Parrot_io_putps calls PCCINVOKE.
Explains it for me. 07:09
pmichaud similar issues with 1-char-at-a-time reads 07:10
very very slow
masak is PCCINVOKE that slow?
chromatic Yes.
pmichaud anyway, I'll write it up in a message to parrot-dev tomorrow morning.
sleep time for me -- bbt 07:11
chromatic It costs 30,625,800 PMCs to run that benchmark. 07:12
masak that's... insane.
pmichaud that is truly horrible.
Especially since I'm only explicitly creating one PMC.
chromatic PCC is slow.
pmichaud and the rest is in registers.
chromatic Converting between C calling conventions and Parrot calling conventions is expensive.
The less code we have in C, the better. 07:15
lu_zero chromatic there isn't a way to make it cost less? 07:19
(beside having gcc output something different) 07:20
07:28 TiMBuS joined
chromatic We can reduce the cost, but the problem is converting to and from PCC. 07:34
We lose so much information we cross the barrier, we can't optimize across it.
It also kills any possibility of JIT speedups. 07:39
08:20 szabgab joined 08:25 alvar joined 08:32 iblechbot joined 09:38 Gerd joined 09:39 gaz joined 09:45 Tene_ joined 09:59 tomyan joined
lu_zero I see 10:05
11:36 Gerd joined
Gerd Is it know that current Parrot revision can be not compiled 12:00
By me is stops with - gmake[1]: *** [PGE.pbc] Segmentation fault
masak Gerd: I don't have that issue here. what OS are you on? 12:08
moritz Gerd: is that a 64bit system?
Gerd my OS is Fedora 7 on a 32-bit system the revision is 36488 12:16
moritz Gerd: I'll try that revision now 12:18
masak Gerd: did you do a 'make realclean' before? or is this your first build?
Gerd It is a new checkout 12:19
masak that's not good, then. :/ 12:20
moritz works here, with Debian i386 on 32 bit
so it's really a platform specific problem 12:21
Gerd: care to open a ticket?
masak parrotbug?
purl parrotbug is mailto:parrotbug@parrotcode.org or svn.perl.org/parrot/trunk/docs/submissions.pod or see also "rakudobug" or needs to be converted to trac
moritz newticket?
ticket?
purl ticket is easier to keep track of
moritz purl: tell me something usefull
purl moritz: huh?
masak purl-- 12:22
purl masak: i'm not following you...
moritz purl: newticket is trac.parrot.org/parrot/newticket
purl OK, moritz.
moritz purl: ticket is <reply> trac.parrot.org/parrot/newticket
purl ...but ticket is easier to keep track of...
moritz purl: no, ticket is <reply> trac.parrot.org/parrot/newticket
purl okay, moritz.
Gerd okay I open a ticket
12:25 alvar joined 12:27 kj joined 12:31 elmex joined 13:06 alinbsp joined
kj Create a language compiler for .NET: msdn.microsoft.com/en-us/magazine/cc136756.aspx 13:08
in all the videos/blogs/tutorials on DLR/.NET targeting, Parrot is never mentioned; seems it's being ignored. 13:09
szbalint first they ignore you, then they laugh at you, then they fight you, then you win. 13:10
kj ha ha ha
It'd be nice to see Perl 6 for DLR :-)
Coke-really-afk (pge segfault) there's an rt ticket AND a trac ticket for that. 13:12
lu_zero hmm 13:24
13:25 gryphon joined 13:27 tomyan joined
Coke wants (for purely technical reasons) to get trac wiki updates via email. 13:31
Coke settles for mailing the interesting ones by hand. 13:32
szbalint set a rss watching spamming bot on the trac feed? :) 13:43
Coke yah, I considered that; but since I'm only going to want to keep some of them anyway, I'll just do the thinking on my reader and email the ones I care about. 13:46
(Then I can tag them in gmail, and use that to drive the summary)
14:02 riffraff joined 14:09 jan joined 14:13 rg joined 14:22 Whiteknight joined 14:27 PacoLinux joined
pmichaud should we eliminate the parrotbug@parrotcode.org address from the factoid? 14:29
rg i believe once email2trac is working properly, that address will be pointed there and be correct again. 14:30
pmichaud well, even then it should probably be parrotbug@parrot.org
or perhaps parrotbug@trac.parrot.org
i.e., we might want a new canonical addr 14:31
Infinoid you could point parrotbug@parrotcode.org to tickets@parrot.org right now, and it'll work. Creating new tickets works, its just replying that doesn't.
pmichaud oh, is tickets@parrot.org the "correct" address now?
Infinoid I have no idea. It's just the address where email2trac is currently set up
rg i guess we can tell that to the infobot then 14:32
Coke can't email new tickets to the tickets@parrot.org address yet. 14:33
Infinoid oh? it worked last week 14:34
Coke er, updates?
part of it was broken, no?
Infinoid yeah, posting comments/followups didn't work yet
Coke my bad. 14:35
the old address should eventually just be an alias for the new address, IMO.
pmichaud I agree. I'm asking whether we should continue to advertise the old address.
Infinoid sounds like a policy decision, but if I get a vote, the new one looks cleaner 14:38
does parrot-porters still exist? or is that parrot-dev now? 14:41
pmichaud it's parrot-dev
iiuc
Infinoid 'ack parrot-porters' reports 22 hits 14:42
Infinoid cleans that up.
Coke pmichaud: until the new address is sorted out, no point in updating the docs. 14:43
the old one works. putting in docs to say "we have two" is more confusing, IMO.
pmichaud I wasn't going to advertise two addresses, I was only going to advertise the correct one. 14:44
14:44 rurban__ joined
Coke the new one isn't correct yet. 14:46
once email2trac works for everything, then it will be fine.
pmichaud Okay, excellent. Thanks.
Coke (reducing confusion)++ 14:47
hurm. that's silly.
confusion--
Coke wonders why it initially feels more proper to karma up negative things.
pmichaud Because some negatives are actually positives. 14:48
see, for example, 'electron'. :-) 14:49
szbalint I think I need to extend the integer set of karma to complex, I want imaginary karma ;)
Infinoid are we still using Perl CLAs, or do we have Parrot CLAs yet? because submissions.pod only mentions the perl one. 14:50
Infinoid is fixing up all the old perl6-internals and parrot-porters references
pmichaud we now have Parrot CLAs
Whiteknight do we need to fill out Parrot CLAs if we've already filled out a Perl CLA? 14:51
pmichaud www.parrot.org/files/parrot_cla.pdf
Whiteknight: I don't know.
Infinoid submissions.pod also mentions obtaining a perl.org account (what's that for, RT?) 14:52
I don't feel qualified to fix up this part of submissions.pod, but I'll trigger some interrupts
Coke I think that is pretty much up to allison to rule on; she's the only one who seems abreast of all the legalities.
Coke supposes he should fill out a CLA. :|
Infinoid heh. 14:53
particle yes, the perl.org account is for rt, committers will need a parrot.org account for trac now 14:55
there's no legalities involved
Coke particle: we're talking about CLAs, not commit bits. 14:58
Infinoid well, the paragraphs are right next to eachother in submissions.pod and I think they will both need fixing up 15:00
oh my, lots of codingstd failures. did my s/// patch cause those? 15:01
(nope, already there.) 15:03
dalek rrot: r36489 | Infinoid++ | trunk:
[docs] Fix up old references to submitting/subscribing/archives for the old

the hostname varied (parrot.org or lists.parrot.org), fix those to be consistent with the official address.		 15:05
PerlJam good morning #parrot people 15:06
Infinoid hai PerlJam
dalek rrot: r36490 | Infinoid++ | trunk/src:
[cage] Fix some codingstd failures. (This fixes everything but the PDD format failures for me.)
 15:12
Coke rant: we shouldn't have "if 0" code checked in, should we? 15:14
dalek rrot: r36491 | fperrad++ | trunk/t/codingstd/perlcritic.t:
[codingstd] use the same interface than over tests
 15:15
rrot: r36492 | fperrad++ | trunk/languages/lua/config/makefiles/root.in:
[Lua] more codetest (especially PerlCritic)
 15:16
15:16 Andy joined
15:17 Tene joined
Coke gets a segfault on pgegrep. 15:24
Coke updates and realcleans to double check.
PerlJam is the parrot dead? 15:27
masak groans
Infinoid parrot_config.c:129: error: expected expression at end of input 15:28
parrot_config.c:129: error: too few arguments to function 'PackFile_unpack'
nice.
PerlJam I haven't really tried building much since the repository moves, but a fresh checkout dies ... with what Infinoid said
Infinoid it built fine yesterday
Coke wonders how big this bt is. 15:30
Infinoid driving in snow, back in 30m & 15:32
PerlJam wait a second. "make realclean; perl Configure.pl && make" dies differently 15:33
parrot_config.c:129: error: ā€˜PackFile_unpaā€™ undeclared (first use in this function)
oh. parrot_config.c was incompletely built. 15:34
Coke ... this bt is too large to attach to trac. 15:35
(partial bt. gzip -9'd)
dalek rrot: r36493 | fperrad++ | trunk/t/codingstd/pdd_format.t:
[codingstd] update test with new requirement of POD documentation
 15:39
15:40 galf joined
Infinoid ok, back 15:59
PerlJam: yeah, for me parrot_config.c is cut off directly after "if (!PackFile_unpack("
pmichaud considers re-installing 64-bit kubuntu. 16:00
Infinoid actually, the point where it gets cut off varies. This time I got "if (!PackFile_unpack(i" 16:03
is pbc_to_exe not flushing a buffer before closing the file? 16:04
kj Infinoid: doesn't closing a file imply to flush first?
Infinoid I would have thought so 16:05
kj I'm pretty sure it does, but I could be mistaken of course
Infinoid oh, I'm sure it does... you can generate a whole file without ever explicitly calling flush
it just seems like this is somehow buffer-related 16:06
the fact that parrot_config.c is exactly 8192 bytes long seems to add weight to that hunch
welp... when in doubt, bisect. 16:07
rg sounds to me more like it crashed
while writing the file
which seems kind of unlikely for a perl program :/ 16:08
Coke i would assume that pmichaud's recent big update to pbc2exe is to blame. =-)
Infinoid the 90% faster thing?
well, that's easy to test, one moment
Coke I am no longer able to use string_str_index in tcl; but it's defined in src/string.c ; suggestions? 16:10
pmichaud I doubt it's pbc_to_exe that's causing the issue.
but it's entirely possible.
Infinoid pbc_to_exe is generating this .c file (well, generating most of it)
ok, locally reverting r36488 resulted in a successful build here 16:12
nopaste "pmichaud" at 72.181.176.220 pasted "excerpt of pbc_to_exe that generates .c output" (40 lines) at nopaste.snit.ch/15549
pmichaud it's hard for me to see how it could be failing to flush a buffer.
note that the statement immediately following the print to the file is 'close'
particle linking fails for me when creating perl6.exe 16:13
moritz that's not perl 5, right?
pmichaud it's PIR
so if the file is being cut off with "if (!PackFile_unpack(" then it's likely a Parrot bug. 16:14
Infinoid the exact point of cutoff varies, I think because some of the preceding array data varies in ascii length 16:15
the file is cut off at 8192, exactly 2 vm/io pages
pmichaud Infinoid: I believe you. I just don't see how pbc_to_exe can be the cause.
Infinoid I'll debug further, thanks for pointing out the code in question 16:16
Coke pmichaud: we're not saying it's a bug in your new code there, but exposed by the switch to PIR. no?
pmichaud Coke: it was PIR before.
Coke hurm.
pmichaud it was different PIR, but it was PIR.
Infinoid I really want that 90% speed improvement, I just need the whole .c file too :)
pmichaud I presume all concerned have done a 'make realclean' and rebuilt the Makefile? That changed also.
Coke Infinoid: put in an explicit flush to see if that helps. :|
Infinoid several times, yes. 16:17
particle i'd rather have a 90% speed improvement in running perl6, rather than in generating it 16:19
but i'll take what i can get :) 16:20
Coke Infinoid: I'm not seeing the problem on darwin/x86 16:22
jonathan hi all 16:23
Infinoid ok, something specific to me then
moritz hi jonathan
rg no, i can reproduce the error on freebsd/amd64
Infinoid PerlJam: are you on x86-64?
PerlJam Infinoid: no, something specific to us. Which last time was 64 bit CPU
:-)
yes
Infinoid here too. that's probably the cutoff
nopaste "Infinoid" at 96.238.213.50 pasted "The Evidence (from strace)" (10 lines) at nopaste.snit.ch/15550 16:28
Infinoid I'm not going to be able to fix this without learning parrot's I/O first. Which won't happen in the next few hours. 16:29
jonathan pmichaud: ping 16:32
pmichaud jonathan: pong
jonathan pmichaud: Hi! :-) 16:34
I plan to have a Rakudo day or two this week, in which I'll focus on the RT queue, if that sounds good to you.
pmichaud that's fine with me. 16:35
jonathan Any days that you expect to be around/not around etc?
pmichaud I want to do the same -- RT queue is getting a bit full.
I expect to be around most every day this week.
jonathan Great! :-)
I've been at a conference and had guests, but from tomorrow I'm back to normal, undisrupted work time.
pmichaud excellent.
jonathan How was the hackathon? 16:36
pmichaud *lots* of enthusiasm for Rakudo at Frozen Perl.
hackathon was very good. I wish our build system had been a bit farther along.
moritz I merged a rakudo patch from chris dolan
pmichaud moritz: yes -- chris misunderstood which patch I was referring to when I said I had approved it... but it's okay. :-) 16:37
jonathan Great.
I saw a comment in the sldies as to wanting to get Rakudo released in 2009.
pmichaud jonathan: you might review chrisdolan's patch for sanity.
Andy thinks that needs to happen, yes.
jonathan What kinda release was he meaning?
It wasn't entirely clear to m.
*me
pmichaud I'm not sure it was entirely clear from the talk, either. 16:38
jonathan OK.
pmichaud But he was talking about something more substantial than just the compiler.
I don't disagree with what he said, but I'm not going to lose sleep if we don't make it in 2009 proper.
If we don't have a good release by early 2010, though, I'm going to cast about for a successor. :-)
of course, we will be having releases starting in February. 16:39
jonathan I agree we should have some some kinda alpha/beta release in 2009.
But I think production release in 2009 is epicly unrealistic.
moritz aye
particle $$$
pmichaud well, it depends on the meaning of "production".
I definitely wouldlike to see "useful" releases in 2009.
jonathan Aye. 16:40
particle: It's not just about money, though it helps. :-)
PerlJam Are you saying it's not useful now? ;)
pmichaud anyway, I've neither endorsed nor repudiated Andy's suggestion. :-)
Infinoid PerlJam, rg, pmichaud: I've made TT #296 to track the pbc_to_exe I/O issue
pmichaud Infinoid++ 16:41
I'll see if I can install 64-bit kubuntu on my shiny new laptop and reproduce and trace a bit.
I'm thinking that we'll need to rely on fakecutable perl6 for a while.
Infinoid ok. I'll bang on it after work if I have time 16:42
particle can we use parrot's exec runcore?
Infinoid work &
Andy I really wish I coulda been there for the hackathon.
16:43 NotFound joined
NotFound hi 16:43
pmichaud particle: I don't understand "parrot's exec runcore"
Andy My real point was that we had to get Rakudo out
particle it generates a native executable
Andy it was more about "we're nearing the end" than "here's the date" 16:44
Consider it a mini mug-throwing.
pmichaud Andy: I thought of you during the hackathon (more)
Andy: Guess what the most common variable name was in the pbc_to_exe program I worked on...? ;-)
jonathan pmichaud: Got an RT# handy for Chris's patch you want me to sanity check?
particle anyway, it's more of a musing, i'll need to look into whether the exec runcore is even functional at this point
Andy hahahaha
purl LOLCON 4 reached.
dalek rrot: r36494 | NotFound++ | trunk/tools/util/pgegrep:
[tools] fix an exception handler in pgegrep, TT #295
Andy pmichaud: I made my first branch last night
pmichaud jonathan: yes -- just a sec.
Andy how do we merge back?
How do you get notified
jonathan particle: exec runcore would be ideal...if it works. :-|
pmichaud Andy: we can still do "submit patches to rakudobug@perl.org"
Andy Well, I've got a git branch
pmichaud I still don't know/understand the whole git branch model yet. 16:46
I'm sure I'll get there. :-)
Andy ok
pmichaud if someone wanted to draft a "git committers guide" that'd be very helpful. :-)
particle andy: there's a bunch of guides on github.com
Andy on launchpad, you "propose a merge"
hey, particle, you were in my slides, too
pmichaud (a "git committers guide for rakudo", I mean) 16:47
particle i'm imfamous!
Infinoid I'm guessing "propose a merge" means "tell pmichaud to git pull blah"?
particle andy: where are your slides?
pmichaud well, it could be any rakudo committer, I suppose.
Andy slideshare
purl slideshare is in need of being called slideshr or www.slideshare.net
pmichaud but yes, we'd like patches/pulls to be reviewed.
Andy added to xoa.petdance.com/What_we_need_on_ra...al_rollout
shorten Andy's url is at xrl.us/befk2q
particle got em 16:48
Andy I'm working on brinigng over the perlcritic stuff from Parrot
also, random consting 'cause, you know, that's how I rolls.
particle i see you got my good side 16:49
jonathan pmichaud: Configure.pl now fails for me on Windows. :-( 16:52
(Rakudo's one.)
nopaste "jonathan" at 85.216.157.73 pasted "failure" (6 lines) at nopaste.snit.ch/15553 16:53
jonathan pmichaud: It strikes me that if I uncommented this block:
if (!$options{'parrot-config'} && -e "../../tools/dev/reconfigure.pl") { 16:54
Then it'd work...but I suspectthat's not the real issue...
Andy hey, pmichaud My parrot seemed to build just find.
fine
jonathan ah, it's hardcoded forward slashes.
Infinoid does Andy D have a commit bit? 16:55
pmichaud I thought I got rid of the reconfigure.pl line. 16:56
Yes, I did. 16:57
jonathan It's just commented out.
pmichaud right.
I no longer want to be using Parrot's reconfigure.pl .
jonathan OK
pmichaud (if we have to, we can put it back in, but it's introducing other issues.) 16:58
jonathan So I need to make parrot_config.exe when I build Parrot?
particle Infinoid: andyd has frequently refused commit bits
pmichaud I thought that was built by default.
It's built by default on my system.
particle he doesn't have direct network access, he needs to ftp to his devel environment
so he has no great way to do commits, and prefers submitting high quality patches forever
Infinoid fair enough. Smart guy. Seems like half the time I've tracked down a weird internals issue, I then come across a patch from him he posted months ago 16:59
particle he gets honorary commit bit in my book. apply every patch he submits, and we'll be better off.
Infinoid starts with TT #294
nopaste "NotFound" at 213.96.228.50 pasted "Access PMC attributes from derived pir classes - with ExceptionHandler fixes that uses it" (154 lines) at nopaste.snit.ch/15555 17:00
17:00 rhr joined
NotFound This patch can solve several inheritance problems, but I'm not sure that this is the way to go 17:01
dalek rrot: r36495 | Infinoid++ | trunk/config/auto/format.pm:
Apply patch from doughera++ in TT #294.

always correct.		 17:05
jonathan pmichaud: Gotta go now - there's some issues with the "open" thingy I think. But not sure what yet. Will work on it. Agree we don't want to get back the reconfigure.pl dep. Back later... 17:07
pmichaud jonathan: okay. I think I need to set up a Win devel environment at some point. 17:08
Infinoid does pbc_to_exe work with msvc, generally? (I'm asking in the context of TT #282, not regarding the recent I/O bug.) 17:12
pmichaud I don't know.
I wasn't aware of #282 when I did my pbc_to_exe work.
17:13 hercynium joined
Infinoid #282 just switches it to use Config[link] (whatever that is) instead of being specific to ld. I think. I'm trying to understand the patch, and what it fixes 17:13
particle yes, i developed pbc_to_exe with chromatic, it should work on win32 and linux 17:17
i'm currently getting a link failure, but i think that's due to rurban's changes and not pmichaud's
pmichaud yes, I don't think I changed anything in the link phase. 17:18
I only changed the way the .c file was being generated.
particle ok, that's what i thought i saw
Infinoid Sorry if I wasn't clear - this has nothing to do with pmichaud's changes, I was just looking at applying another patch from TT and wondering exactly what it did
particle msvc needs an absolute filename for libparrot.lib 17:19
17:19 tomyan joined
Infinoid the patch looks like it fixes a hardcoded "ld" which I figured probably wouldn't work on msvc, and if it actually fixed something, I wanted to mention that in the commit message 17:19
that's all. 17:20
particle ah, gotcha
17:21 tomyan joined 17:28 mikehh joined
nopaste "NotFound" at 213.96.228.50 pasted "Don't hide close errors" (99 lines) at nopaste.snit.ch/15557 17:36
NotFound Please take a look at this patch, and somenoe try it on win32 17:37
17:42 Theory joined
rurban particle: for win32 there's still a hints patch pending. 17:46
I also tried to fix bigint.pmc 17:47
kj Coke++ # TWIP
Whiteknight TWIP? 17:48
kj see parrot.org
dalek rrot: r36496 | Infinoid++ | trunk/tools/dev/pbc_to_exe.pir:
Apply patch from doughera++ in TT #282:

for details.)
kj (I knew that should trigger *someone* to be curious ;-)
particle TWIP is "this week in parrot"
purl, TWIP is "this week in parrot"
purl i already had it that way, particle.
particle purl, TWOP is "that was obnoxious, purl" 17:50
purl OK, particle.
dalek rtcl: r326 | wcoleda++ | trunk/src/binary.c:
Modify/trunk/src/pmc/tclfloat.pmc

   Modify/trunk/src/pmc/tcllist.pmc
   Modify/trunk/src/pmc/tclstring.pmc
   Track rename of string_length
rurban BTW: we still miss linkflags (TT #282), my patch was reverted, so linkflags is ignored.
Infinoid hrm.
particle kicks dalek
Infinoid another day, another rss parser to fix
at least by the end of this, we'll have high quality parsers for trac, googlecode and github (they're all different) 17:52
moritz or just amke dalek ignore lines that only contain whitespaces
PerlJam Infinoid: parsers written in perl 6? :)
particle god no! we want this to be stable, and fast!
sigh. 17:53
Infinoid for googlecode, the list of changed files appears at the top of the rss item description. dalek tries to parse those out to get the greatest-common-prefix for the first line, but it failed horribly
moritz ah, that's the "high quality" part of it ;-) *me ducks*
Whiteknight purl no, TWOP is <reply>*purl hits himself in the head*
purl okay, Whiteknight.
Whiteknight TWOP?
purl *purl hits himself in the head*
Infinoid TWOP!
aaw. 17:54
Whiteknight TWOP
moritz Whiteknight++
TWOP?
purl *purl hits himself in the head*
Infinoid purl: TWOP
purl *purl hits himself in the head*
kj particle: I hope everybody notices the self-deprecation, otherwise it may show up on reddit in another parrot-bashing topic ;-)
Infinoid fun.
PerlJam kj: There have been mischievous lurkers who wouldn't care about the context. 17:55
kj PerlJam: exactly.. 17:56
ah well. some attention is better than no attention
17:56 geof joined
dalek rrot: r36497 | particle++ | trunk/lib/Parrot/Test.pm:
[lib] fix some indentation-challenged logic, and correct a broken case for ccache with msvc
 17:56
kj particle: where did you get ccache for msvc? 17:57
I've tried to find it; but failed
particle google
Infinoid ccache-win32 is for mingw, I think 17:58
particle artax.karlin.mff.cuni.cz/~kendy/ccache/
Infinoid purl, ccache-msvc is artax.karlin.mff.cuni.cz/~kendy/ccache/
purl OK, Infinoid.
nopaste "rurban" at 212.183.63.40 pasted "my needed mingw fixes: no static lib, no blib_dir" (93 lines) at nopaste.snit.ch/15558 18:02
"rurban" at 212.183.63.40 pasted "my bigint.pmc work from today" (351 lines) at nopaste.snit.ch/15559 18:03
rurban bignum, sorry
there are several totally unneeded bignum methods, probably copy & paste from bigint, like shl, shr, mod, fdiv 18:04
I tried to accept bigint PMC's for bignum methods, but doesn't look easy. 18:05
particle rebuilds with rurban's patch 18:06
...mingw patch...
rurban my problem was that dynpmc picked up the static lib. a mix of static and dynamic caused the ptr failures in encoding and PMCNULL 18:07
since nobody needs the static lib on win32 because then dynpmc's willnot work, I disabled it 18:08
target: LIBPARROT_STATIC: dummy.static in the Makefile
pbc_to_exe works fine with msvc, mingw, cygwin 18:09
dalek rrot: r36498 | particle++ | trunk/t/codingstd/copyright.t:
[t] modify coding standard test to look for 'Parrot Foundation' in copyright
 18:10
18:11 jsut|work joined
mikehh I think r36495 causes t/steps/auto_format-01.t to fail 18:11
kj particle: should copyright notices be changed to grant to parrot foundation? 18:12
mikehh t/steps/auto_format-01 (Wstat: 256 Tests: 16 Failed: 1) 18:13
rurban Oh, and I fixed the native_pbc tests, tools, and docs. Added to TT#293 and RT#47940
The lurking 64bit align packfile bug not yet. 18:14
mikehh # at t/steps/auto_format-01.t line 102.
dalek rrot: r36499 | particle++ | trunk/README:
update copyright in README (the most important copyright notice)
particle kj: yes, all files except LICENSE, which is properly TPF
mikehh # got: '%.15Lg'
kj oki. Can that be changed using a script? 18:15
or manually?
mikehh # expected: '%Lf'
particle perl -i should do it
i just changed the test and most important file, to get the ball rolling
Infinoid urk 18:16
mikehh: thanks, I'm thinking maybe the test should be changed 18:18
18:18 chromatic joined
Infinoid chromatic: Any chance you know what TT #296 might be caused by, off the top of your head? 18:21
chromatic Off the top of my head, no. 18:22
mikehh yes - it does cause perl Configure.pl --optimize --test to fail before configure
chromatic As a guess, probably an assumption about sizes that's not true.
Infinoid Ok. I'll dig into I/O tonight and hopefully figure it out, thanks. 18:23
mikehh although perl Configure.pl --optimize does complete
Infinoid mikehh: Yeah. r36495 changed the hardcoded format string but not the hardcoded test 18:24
rakudo: say "Infinoid-- # committing patches without fully testing them" 18:25
polyglotbot OUTPUT[Infinoid-- # committing patches without fully testing themā¤]
Whiteknight Infinoid++ # admitting your mistakes 18:26
dalek rrot: r36500 | fperrad++ | trunk/languages/lua/src/pmc/luathread.pmc:
[Lua] refactor LuaThread PMC with ATTR
 18:30
rrot: r36501 | fperrad++ | trunk/languages/lua/doc:
[Lua] Abandoning daft Perl 5-style documentation headings.
 18:33
rrot: r36502 | Infinoid++ | trunk/t/steps/auto_format-01.t:
[t] Fix some test fallout from r36495.
 18:34
NotFound Infinoid: you can try #297, maybe it can help to diagnose #296 18:35
rurban The #297 patch is the same as nopaste 15557? I'm trying that right now 18:36
NotFound rurban: yes, same patch
rurban sounds good so far. 18:37
NotFound Nobody answered here, so I create tickets to not forget the issues ;)
rurban I could reproduce in the morning with t/src/extend.t test 17 failing on mingw and cygwin 18:40
NotFound rurban: I think that test uses global symbols, so is exposed to the same problems with global charsets and encodings 18:44
rurban I think I have a minor issue with make reconfig when no Configure.pl args was given. Will check later 18:48
NotFound I can't find that, maybe that part was already discarded. 18:49
particle what is a "DIR *" in parrot? 18:52
i can't find a tag for it
pmichaud I think that might actually come from c library.
like FILE *
particle or is that an os thing.
chromatic Probably an OS thing.
particle ok, that needs to be abstracted away
chromatic Hm, no comments on my "Here's why writing methods in C is bad." message yet.
pmichaud particle: www.gnu.org/software/libtool/manual...ctory.html 18:53
shorten pmichaud's url is at xrl.us/befmio
particle git clones perl5
kj chromatic: 1,454 PMCs for "hello world"??!! That seems like a bit of overkill :-P 18:54
chromatic It takes that many PMCs to start Parrot. 18:55
kj yeah. so much for 'lean and mean'. 18:57
chromatic: so basically PIR methods are faster than C methods?
chromatic Very much so.
particle parrot++ # faster than c :) 18:58
kj it's slightly non-intuitive. "C" often implies high speed
NotFound What is slow are call chains: bytecode -> C -> bytecode -> C -> bytecode ...
kj but I understood why...
chromatic There are only three advantages for C code in Parrot.
1) Direct access to memory
2) Direct calls to other C code which uses C calling conventions 18:59
3) Algorithms which do not call PCC and need tremendous speed
#3 is rare.
kj chromatic: GC?
purl GC is probably the boehm conservative garbage collector at reality.sgi.com/boehm/cg.html or a really really bad perl "programmer" or GrandCentral.com or branches/gsoc_pdd09 or a travesty against god
chromatic We could work around #1.
pmichaud some algorithms are easier to write in C than PIR, also.
chromatic kj, GC doesn't even have to be written in C.
#2 is really the only sticking point. 19:00
kj chromatic: no, but surely it must be faster than PIR
chromatic Not necessarily.
NotFound We can write the GC in brainfuck
kj heh
chromatic You mean we didn't?
kj :-)
NotFound Maybe the semantic, but the syntax looks like C 19:01
chromatic "easier to write than in PIR" is sort of a half point.
PerlJam or you could write a language that expresses things in terms of common/useful GC operations and write the GC in that language. :-)
Infinoid who GC's the GC?
chromatic I did write a self-hosting GC once. 19:02
PerlJam Infinoid: it's still tutles all the way down.
er, turtles even
kj ISTR that Dan wrote in one of his "WIWHDD" posts that he should have created a higher level language to implement parts of parrot
Infinoid as long as they keep getting bigger, I'm ok with that
chromatic PMCs and ops especially. 19:03
Anytime any C function calls back into the Parrot runloop, we lose.
We lose big.
NotFound BTW, you can take a look at TT #299 to help solve one obstacle against writing things in pir
chromatic The worst part is that the puts() method on FileHandle doesn't have to be 2500 times slower. 19:05
19:05 Theory joined
chromatic If it were written in PIR it wouldn't be. 19:05
rurban chromatic: can you take a look at my patches in TT#293 and RT#47940 (native_pbc docs)
chromatic Well, 2500 times more expensive in terms of garbage anyway.
Will do in a bit.
The main points are that crossing the C/PCC barrier is hugely expensive, and it ruins our chances to JIT things to make them faster. 19:07
rurban So the op preprocessor has to be rewritten to emit pir and not C? 19:09
Because I thought the ops are already pir 19:10
NotFound The ops are ops.
pmichaud chromatic: how do you measure the number of PMCs created? 19:11
i.e., what option is it?
NotFound Writing a Parrot VM interpreter in a language hosted in Parrot will be a nice excersise. 19:12
pmichaud: the info command of parrot_debugger can be helpful 19:13
Coke pmichaud: interpinfo .INTERPINFO_TOTAL_PMCS ? 19:17
(from code.google.com/p/partcl/source/bro...s.pir#113) 19:18
shorten Coke's url is at xrl.us/befmnu
Coke (implemeting a HLL sooner rather than later) yes, I agree, that would have been very helpful. 19:19
we could theoretically use NQP for that, esp. if we had cross-platform PBC and could ship with a precompiled version of the compiler. 19:20
but if we had, say, a small scheme in place in year 1, I think parrot would look very different today. 19:23
pmichaud .INTERPINFO_TOTAL_PMCS seems to always report back the same number for me. 19:24
Infinoid NotFound: Thanks for mentioning #297, but I've verified with strace that the close() syscall is being called and returns 0
pmichaud (even as I change the code to produce more/less PMCs)
the strace shows pretty clearly that Parrot isn't calling write sufficient numbers of times or with the correct value. 19:27
Whiteknight pmichaud: that .INTERPINF_TOTAL_PMCs number may not be updated in the GC reliably for the current collector
pmichaud Whiteknight: that's fine -- thus my original question: how to obtain it?
NotFound pmichaud: yes, I'm testing with ecamscript under parrot_debugger and the number of Total PMC does not vary
pmichaud i.e., I'm wondering how chromatic gets his numbers (so I can do similar benchmarking here) 19:28
install 64-bit kubuntu on new laptop: FAIL
oh well, back to comfy 32-bit 19:29
Infinoid aaw. 19:30
pmichaud install worked fine, but applying updates caused the network card to stop working.
Infinoid e1000 network card chipset? 19:31
pmichaud can't find the card type 19:33
Infinoid mine looks like 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03) 19:35
(in the output of "lspci")
pmichaud Intel Corporation 82567LM Gigabit Network Connection (rev 03) 19:36
Infinoid yep, same driver (e1000)
pmichaud weird that the kubuntu updates cause it to fail. 19:37
Infinoid ubuntu kernels have had some problems with that driver in the past
pmichaud oh, I often had trouble with suse + e1000 as well.
Infinoid I always compile my own kernels (old habits die hard), but it's always worked pretty well for me 19:38
chromatic pmichaud, I used callgrind and looked at the number of calls to pmc_new in kcachegrind.
Infinoid pmichaud: bugs.launchpad.net/ubuntu/+source/...bug/263555 (I'm not sure what "Fix Released" means in this case) 19:50
dalek rrot: r36503 | fperrad++ | trunk/languages/lua/src/pmc/luathread.pmc:
[Lua] fix line length
 20:10
rrot: r36504 | NotFound++ | trunk:
[debugger] some fixes and add an option to pirric for interaction with the debugger
 20:13
20:34 chip joined
chip regreets 20:34
chromatic Sick of Perl 5's guts yet, chip? 20:35
Coke hey, chip. 20:36
tewk posits, as a VM matures the amount of the vm implementation written in C should drastically shrink. 20:39
Whiteknight adds "tewk's rule" to Wikipedia
tewk C is a bootstrapping crutch, albeit a difficult crutch to give up. 20:40
chromatic posits that, as it's no longer the '70s, the amount of code written in C should drastically shrink.
Infinoid is quite comfortable with his OS kernel having been written in C 20:41
tewk PCCINVOKE was always meant to be a enabling but *temporary* crutch.
Whiteknight See, there are some things for which C is still well-suited. Kernels are one of them
tewk the conjecture was qualified for language vms :) 20:42
20:42 jonathan joined
chromatic I stand by my statement. 20:42
Whiteknight I gave up serious C coding years ago. Which is a funny statement considering how old I am and how few years I've been programming 20:46
It used to be when I needed to write something, I used C. Now it's all perl. 20:47
tewk I've had to write some python lately, I'm sick of explicit self and $self, save me perl6 20:48
dalek rrot: r36505 | rurban++ | trunk/Configure.pl:
RT#58034: make reconfig, fix a cornercase when no args are given
 20:50
Whiteknight considering my degree and intended career path, I'm probably going to spend most of the rest of my life writing C code 20:51
embedded systems don't take kindly to managed interpreted code 20:52
Infinoid I've spent a lot of years commercially writing C code, and I'll probably spend a lot more. And I spend all my spare time tossing things together with perl
Whiteknight: funny you should mention that, as I'm an embedded systems engineer :) 20:53
Whiteknight I'm actually at a job right now that doesn't use any C code, so I have to get it out of my system with Parrot
Infinoid lucky parrot
Whiteknight Infinoid: Whereabouts do you work?
Infinoid I work for a wireless networking hardware startup that isn't doing too well at the moment... 20:56
Whiteknight well, I'm sorry to hear that. Speaking of wireless networking, I'm about 30 seconds away from breaking my goddamned router into a billion pieces 20:57
Infinoid chances are, it isn't running my code then :) 20:58
Whiteknight no, it's some piece of shit netgear router. worst. router. ever. 21:00
rurban who in the world buys this crap 21:01
Infinoid Whiteknight, apparently
mikehh chromatic: where do you think we should be going in moving away from C code?
Infinoid XS!
Whiteknight BLASPHEMY! 21:02
Infinoid like it nor not, at least I'd be able to hide the ASSERT_ARGS() nonsense
mikehh most definately!!!
dalek rrot: r36506 | fperrad++ | trunk/languages/lua/src/pmc:
[Lua] refactor metatable access, and s/find_meth/_LuaAny_find_meth/
 21:03
Whiteknight if we switch to XS, I'm out of here. I'll go hack on Mono, or some other sane virtual machine :)
rurban with a proper preprocessor macro language you could do that automatically 21:04
chromatic mikehh, I'd like to see (eventually) a slim set of base opcodes on which we can build other ops and PMCs.
mikehh sort of riscify?
chromatic That's a good way to think about it. 21:05
Whiteknight okay, I'm heading home now. chromatic: I'll create a branch tonight to work on that METHOD nonsense, so if you have any particular suggestions email them to me or something
later
chromatic ta
mikehh, Smalltalk does (or did, at least -- I haven't looked at a modern Smalltalk) something similar.
If we had a handful of ops which handle memory allocation and direct memory access and calling C functions, we could build everything else on top of that. 21:06
Infinoid a reduced instruction set would probably make JIT *much* simpler
chromatic Almost all of the code could stay in the same runloop.
rurban like in lisp
chromatic We wouldn't have the PMCProxy mess, or inheriting from C-based PMCs, or....
We wouldn't have to use C calling conventions except for calling C code (which NEVER calls back into Parrot code). 21:07
mikehh just returns a value 21:08
21:08 alvar joined
mikehh how minimalist could you go? 21:12
chromatic 64 core ops could do it.
In theory, you could go down to the level of the SK calculus or a UTM emulator, but that's a little bit nuts. 21:13
I think you could almost guarantee that you'll never have null pointer dereferences too. The only modern language I know capable of making that guarantee is Eiffel, and that's a really recent version. 21:14
Infinoid I love the contract model in Eiffel 21:15
moritz too
just the syntax is too verbose, a little bit javaish :(
chromatic Hm, you could almost trivially put contracts into Parrot that way too. 21:16
*Optional* contracts.
Infinoid without another ASSERT_ARGS() type mess? :) 21:17
chromatic Right.
Infinoid WANT
chromatic You'd have to write contract information in the language which defines the ops and PMC methods and such, but it's doable. 21:18
Infinoid Let's make PCC faster first, and then make ops slower. Deal?
chromatic How would that make ops slower? 21:19
Infinoid I'd assume doing the check would be slower than not doing the check (which is how we live today).
chromatic Oh, right.
But it could be optional.
Also with JIT much more trivial, I suspect things could go faster. 21:20
Infinoid ./configure --bat-outta-hell
mikehh I think a sort of Huffman type selection of essential ops would make it much faster as the most used ops would be very fast 21:21
chromatic The selection criterion isn't really "Which ops need to be fast?" but "Which ops do we need to build every other op?" 21:22
rurban hot_ops
chromatic more like base_ops 21:23
particle bootstrap_ops
rurban c_ops 21:24
chromatic Right, something along those lines.
mikehh Yes but you also need to optimize for speed
chromatic That's what started this whole mess! 21:25
Infinoid Fewer ops means more attention to optimizing those ops.
chromatic The idea that you have to write slow bits in C sounds good, but in practice it's wrong.
rurban jit
chromatic A method call to a method written in C has at least one barrier the JIT cannot cross. 21:26
A method call to a method written in PIR is fully JITtable. 21:27
It's probably even inlinable.
*inlinable
If it's in a loop, even the method lookup is cacheable.
mikehh I like it
chromatic *and* the check for the loop invariant "Oh, we can't use the cached form!" is effectively free, thanks to processor prediction.
If you write your JIT such that the common case through the JITted basic block is straight-line code, you do the check but the processor has already executed the next several operations and keeps them, instead of throwing them away, so you avoid even a pipeline stall. 21:29
If the check fails, you do a side exit to the normal, non-JITted code. It's a little bit more expensive than the non-JITted code because you've taken a side exit, but if you're doing this JIT strategy on hotspots, the wins way amortize.
GeJ Good morning everyone 21:30
rurban eek, icc and llcm-gcc stopped working..
llvm-gcc
21:32 barney joined
chromatic Now that's all a lot of work, and a big conversion, and a maintenance risk in developing a language in which to write all of this code... but I do think it's our best hope of reclaiming all of the speed we hope to gain. 21:32
Infinoid If there's a way to break that into stages, I'd have lots of enthusiastic tuits to pour onto it.
21:33 Theory joined
chromatic I've been toying with a proof of concept VM, as that seems like the best approach to demonstrate this bootstrappy. 21:33
If we can show that we can implement at least *some* ops and one or two PMCs with that scheme, it's worthwhile to pursue more. 21:34
Infinoid Having an easily extensible system for optimization would be crucial, I think. Not for proof of concept, but eventually there's going to be a *ton* of logic on that side of things. 21:36
chromatic I dunno. Run any non-trivial Parrot program through callgrind and kcachegrind and look at how many cycles we waste crossing calling convention boundaries. 21:38
rurban nci would be faster? 21:40
I doubt: just write less C and more pir 21:41
chromatic That's hard to say.
rurban eg the String class?
all those methods 21:42
Coke staying on one side or the other of the barrier will help, but it seems we also have to make crossing the barrier less expensive.
chromatic For now we do.
Only because our architecture demands that there's a barrier.
There doesn't have to be a barrier.
Coke ORLY? 21:43
purl YA RLY.
chromatic Really.
Coke nifty.
chromatic That's my point.
We need to stop thinking that writing things in C makes them fast. It doesn't. It makes them *slower*.
particle sure, if we store our args in registers and call them by name
Coke chromatic: well, to be fair, only if we have to call them from not C. neh? 21:44
particle let's make a new set of regs, A0-A99
for *arguments* :)
rurban maybe a c-callstack and c-return stack as parrot pseudo registers 21:45
chromatic Coke, I think we should keep that idea as a core goal, if we still intend to build a VM and compiler tools for people to write languages which are not C.
Coke chromatic: I'd be interested to see a writeup of your ideas somewhere.
chromatic Will do. 21:46
Coke even if there's no way to do this for 1.0, (there's not), it would be nice to see how much effort it would be to generate a POC, and then to see how much effort it would take to actuallyd o. (could we get it for 1.5, or more likely, 2.0?)
chromatic 1.5 is a stretch. 2.0 is a possibility.
particle 3.0 is more likely. 21:47
chromatic The best we can do for 1.0 is mitigate the damage so the system is partially usable.
rurban are there numbers for the "damage" 21:48
chromatic Sure, see pm's benchmark on the list.
Or the examples/benchmarks/primes2.pir code.
21:50 Tene_ joined
Coke (partially usuable) that would be nice. 21:53
chromatic Every time I try to optimize things, I keep running into that barrier. 21:54
21:59 Whiteknight joined
Coke Every time I try to optimize things, I realize I didn't know what was slow. :| 22:07
I've given up on that, at least from tcl's standpoint.
irclogs? 22:08
purl well, irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
22:17 alvar joined
dalek rrot: r36507 | NotFound++ | trunk/examples:
[examples] Mysql and pirric fixes
 22:18
mikehh on another topic: I seem to be picking up a lot of tmp files - Makefile_n.out.tmp which don't seem to go away 22:28
chromatic Some configuration test is probably not using File::Temp and has hardcoded '$$' somewhere. 22:30
mikehh all length 50 containing the line 22:33
# Test reporting sourcefile line numbers. TT #279
chromatic lib/Parrot/Configure/Compiler.pm line 347 22:37
tewk chromatic: is there a quick way to export all subs in perl5 or export all subs minus some exceptions? 22:38
chromatic Use tags in EXPORT_OK 22:39
perldoc Exporter
Perl6::Export (or whatever the name is) might work too. 22:40
dalek rrot: r36508 | allison++ | branches/kill_pccinvoke:
Creating branch for refactoring calling conventions, removing the old PCCINVOKE and streamlining the rest.
rrot: r36509 | chromatic++ | trunk/t/steps/gen_makefiles-01.t:
[t] Ensured the removal of a temporary file generated by

Tidied code.		 22:43
22:45 rurban__ joined
szabgab chromatic, did you have a chance to look at the Parrot::Embed stuff ? 22:49
chromatic I haven't, I'm sorry.
What's your top priority?
szabgab remove SKIP from t/languages.t 22:51
chromatic Will work on that. 22:53
szabgab thanks, once that works I'll try to write and send other tests 22:54
23:02 allison joined
NotFound allison: can you take a look at TT #299 ? 23:05
allison NotFound: sure 23:11
NotFound: well, the problem isn't really that children can't access the attributes of the parents... they access a high-level alternate for the parent that's stored as an ordinary high-level attribute 23:13
NotFound: That's what GET_ATTR is for, to access the high-level attribute from a high-level object 23:14
(but still access the low-level attribute from a low-level object
NotFound allison: yes, if the children redefines it.
allison NotFound: the problem is we're not automatically adding the high-level attributes when a child subclasses from a low-level PMC 23:15
NotFound allison: I thinked about that way, but I don't see where to get the ATTR list from. 23:16
allison NotFound: now, that's something PMCProxy could do 23:17
NotFound: yes, the ATTR list needs to be serialized into the low-level PMC definition
Whiteknight allison: you beat me to it: I was going to create a new calling conventions branch tonight
allison NotFound: it could be simply captured raw, so PMCProxy can parse it, or provided as a C function with a constant struct 23:18
mikehh r36401 - t/steps/gen_makefiles-01.t chromatic: commented on it 23:19
Whiteknight Here's a question: does pmc->vtable->pmc_class always point to the Class PMC for that type?
because i'm seeing an instance where it appears to be pointing to a String PMC instead 23:21
allison Whiteknight: no, because not all PMCs have a Class PMC
Whiteknight: if you're getting a String PMC, is it the name of the class?
Whiteknight I don't know yet, I'm just looking at a backtrace right now 23:22
I'm trying to change VTABLE_morph to take a class PMC instead of a type id, and I'm running into problems with that 23:23
NotFound I'd like better to kill VTABLE_morph
Whiteknight NotFound: that's an interesting alternative. 23:24
for what it's worth, I'm not against it, since morph usually involves creating a new PMC and initializing it with data from SELF
dalek rrot: r36510 | allison++ | branches/kill_pccinvoke/src/call:
[pcc] Moving the core files for C and Parrot calling conventions for
 23:26
rrot: r36511 | allison++ | branches/kill_pccinvoke/include/parrot/call.h:
[pcc] Renaming files for C and Parrot calling conventions for greater
 23:34
Whiteknight sanity++ 23:36
mikehh t/steps/gen_makefiles-01.t generates a tmp file that is not removed
prove t/steps/gen_makefiles-01.t 23:37
-rw-r--r-- 1 mhk mhk 50 2009-02-09 23:32 Makefile_21487.out.tmp
23:38 Tene joined
particle mikehh: trac.parrot.org/parrot/changeset/36509/ 23:38
mikehh particle: ok I am r36504 - let me svn up etc 23:40
23:44 Theory joined
mikehh The problem with chromatic++ is that he has fixed the thing before I have even tracked it down 23:46
Whiteknight yeah, it's definitely a problem 23:47
eventually I'm going to write up a shell alias for "maek" 23:51
because when I type "maek test", it should DWIM
allison: let me know when you're done with infrastructure changes on that branch, I want to get in there and help out 23:52
motivational speaker chromatic has me fired up about it
allison Whiteknight: I expect I'll be ready for collaborative work on that branch by tomorrow 23:53
chromatic If only I could likewise motivate the Macarthur foundation to give me a grant to work onit.
Whiteknight Macarthur foundation? stupid biased genius tests 23:55
particle i'll work on a shell alias for maek without a macarthur grant. 23:56
i'm not proud.
chromatic Scab. You're pushing wages down.
23:59 cognominal joined
dalek parrot: r36512 | allison++ | branches/kill_pccinvoke: 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!