Camelia, the Perl 6 bug

IRC log for #parrot, 2009-02-09

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 Whiteknight allison++ is kicking ass tonight
00:09 AndyA joined #parrot
00:30 kid51 joined #parrot
00:36 Tene joined #parrot
00:58 mikehh created ticket TT#293 - t/native_pbc/integer.t still fails for me at r36481
01:03 Whiteknight did you realclean and reconfigure?
01:05 mikehh nake realclean, perl Configure.pl --optimize --test, make world
01:06 mikehh sorry make
01:07 mikehh it worked at r36416
01:07 chromatic Do you know at which point in between it failed?
01:07 mikehh no I have been trying to track it down
01:10 mikehh it worked 15:34 [UTC] Feb 7 but failed at 23:20[UTC] Feb 8
01:10 dalek parrot: r36482 | whiteknight++ | trunk/docs/book:
01:11 dalek parrot: [Book] Add more information about namespaces, and an example about using coroutines
01:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36482/
01:14 chromatic r36468?
01:16 dalek parrot: r36483 | whiteknight++ | trunk/docs/book/ch04_pir_subroutines.pod:
01:16 dalek parrot: [Book] Add another example about coroutines and how they handle parameters
01:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36483/
01:20 mikehh thats the one that seems most likely
01:25 gravity joined #parrot
01:26 mikehh there was a change to the test between r36416 and 36444
01:31 allison joined #parrot
01:33 Fayland joined #parrot
01:41 dalek parrot: r36484 | whiteknight++ | trunk/docs/book/ch04_pir_subroutines.pod:
01:41 dalek parrot: [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 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36484/
01:41 mikehh change in r36419 but that was documentation
01:41 purl mikehh: that doesn't look right
01:42 mikehh what doesn't look right?
01:43 Whiteknight don't listen to purl, he's retarded
01:44 Whiteknight plus, he's a bot
01:44 Whiteknight or she, or whatever gender a bot has
01:44 mikehh ok
01:52 mikehh what does the message - Unknown PMC type to thaw 0 - mean
01:53 chromatic Parrot tried to thaw a PMC from bytecode, but the identifier for the PMC's type is invalid.
01:56 chromatic Perhaps someone removed a PMC so the numbers shifted down, or the PBC is invalid so it's misinterpreting some instructions.
01:58 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 !$
02:00 mikehh same message
02:00 purl same message is, like, being reinjected by prserv.net into pobox MXes
02:01 chromatic Okay, good to know.
02:07 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:24 mikehh ok I followed the instructions in the test file to regenerate the first test and that now works
02:25 mikehh where are these files supposed to be generated
02:27 chromatic Manually, generally at release time or whenever someone changes the PBC format.
02:28 tetragon joined #parrot
02:35 mikehh joined #parrot
02:35 mikehh I got disconnected
02:36 mikehh anyway i manually regenerated the integer_1.pbc and 2 and 3 and the test now passes
02:38 chromatic Hard to say if they'd pass for anyone else though.
02:40 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:42 chromatic They test that PBC is portable across platforms.
02:43 mikehh so the pbc files sgould be the same on all playforms?
02:47 chromatic yes
02:54 mikehh ok - let me add the info I have to the ticket - I don't know where to go from there
03:08 dalek tracwiki: v48 | particle++ | WikiStart
03:08 dalek tracwiki: https://trac.parrot.org/parr​ot/wiki/WikiStart?version=48
03:11 chromatic rurban or Infinoid might know better
03:15 dalek tracwiki: v1 | particle++ | ParrotVirtualAppliance
03:15 dalek tracwiki: https://trac.parrot.org/parrot/wik​i/ParrotVirtualAppliance?version=1
03:15 shorten dalek's url is at http://xrl.us/befjg6
03:16 dalek tracwiki: v49 | particle++ | WikiStart
03:16 dalek tracwiki: https://trac.parrot.org/parr​ot/wiki/WikiStart?version=49
03:16 dalek tracwiki: v2 | particle++ | ParrotVirtualAppliance
03:16 dalek tracwiki: https://trac.parrot.org/parrot/wik​i/ParrotVirtualAppliance?version=2
03:16 shorten dalek's url is at http://xrl.us/befjhe
03:17 dalek tracwiki: v3 | particle++ | ParrotVirtualAppliance
03:17 dalek tracwiki: https://trac.parrot.org/parrot/wik​i/ParrotVirtualAppliance?version=3
03:17 shorten dalek's url is at http://xrl.us/befjhg
03:20 dalek tracwiki: v4 | particle++ | ParrotVirtualAppliance
03:20 dalek tracwiki: https://trac.parrot.org/parrot/wik​i/ParrotVirtualAppliance?version=4
03:20 shorten dalek's url is at http://xrl.us/befjhp
03:42 janus joined #parrot
03:42 mikehh The latest smolder test http://smolder.plusthree.com/app/pu​blic_projects/report_details/17867 also failed these tests (not mine)
03:42 shorten mikehh's url is at http://xrl.us/befjjc
03:59 eternaleye joined #parrot
04:31 Andy joined #parrot
04:56 dalek parrot: r36486 | petdance++ | trunk/src/sub.c:
04:56 dalek parrot: fixed formatting
04:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36486/
05:11 masak joined #parrot
05:23 mib_mhq8fu joined #parrot
05:27 mib_mhq8fu Does PMCs mean PolyMorphic Containers?
05:27 chromatic Yes.
05:28 mib_mhq8fu I saw that /docs/book does, but /docs doesn't.
05:33 chromatic Not universally updated.
05:33 mib_mhq8fu Ok, thanks :)
06:00 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
06:00 polyglotbot ..(src/PCT/HLLCompiler.pir:688)␤called from Sub 'p...
06:00 masak rakudo: $*OUT := (class {}).new; say "OH HAI"
06:00 polyglotbot OUTPUT[OH HAI␤]
06:09 allison joined #parrot
06:09 dalek parrot: r36487 | allison++ | trunk/docs:
06:09 dalek parrot: [doc] More conversions for PMC backronym.
06:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36487/
06:22 tewk joined #parrot
06:28 HG` joined #parrot
06:38 Theory joined #parrot
06:44 rurban__ joined #parrot
06:58 dalek parrot: r36488 | pmichaud++ | trunk:
06:58 dalek parrot: [tools]:  Refactor pbc_to_exe to execute 90% faster.
06:58 dalek parrot: Rewrite pbc_to_exe so that it's a lot smarter about buffering and I/O
06:59 dalek parrot: when creating the .c fakecutable.  This results in a 90.5% speedup
06:59 dalek parrot: for building the Rakudo fakecutable from the .pbc (improved
06:59 dalek parrot: from 174.9 seconds to 16.5 seconds on my system).
06:59 dalek parrot: Also eliminate the pbc_to_exe_gen.pl step; pbc_to_exe.pir
06:59 dalek parrot: is now static w.r.t. parrot configuration, so we no longer
06:59 dalek parrot: need to be using a Perl 5 script to create it.
06:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36488/
06:59 chromatic Very nice.
07:00 pmichaud I also think Parrot's buffered I/O is broken.
07:00 pmichaud But I'll have to write that up tomorrow after I get some sleep.
07:01 chromatic I thought GCC time was the bottleneck in pbc_to_exe.
07:01 pmichaud no.
07:01 pmichaud (as can be seen above)
07:01 pmichaud I didn't change what pbc_to_exe outputs to gcc -- I only changed how it did it.
07:02 pmichaud put another way -- I changed the time needed to generate perl6.c from 162 seconds to 4
07:02 pmichaud (gcc takes about 12 seconds)
07:02 masak pmichaud++
07:02 pmichaud I'll nopaste my "buffering is maybe broken" test -- just a sec
07:02 jan joined #parrot
07:03 szbalint pmichaud++ # This is what I like to call "optimization" ;)
07:04 nopaste "pmichaud" at 72.181.176.220 pasted "buffered I/O might be broken -- pir test program" (26 lines) at http://nopaste.snit.ch/15547
07:04 nopaste "pmichaud" at 72.181.176.220 pasted "buffered I/O might be broken -- perl 5 version for comparison" (23 lines) at http://nopaste.snit.ch/15548
07:05 pmichaud Parrot is 15x - 20x slower at file output than Perl 5.
07:07 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'
07:08 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.
07:08 chromatic Oh.  Parrot_io_putps calls PCCINVOKE.
07:09 chromatic Explains it for me.
07:10 pmichaud similar issues with 1-char-at-a-time reads
07:10 pmichaud very very slow
07:10 masak is PCCINVOKE that slow?
07:10 chromatic Yes.
07:10 pmichaud anyway, I'll write it up in a message to parrot-dev tomorrow morning.
07:11 pmichaud sleep time for me -- bbt
07:12 chromatic It costs 30,625,800 PMCs to run that benchmark.
07:12 masak that's... insane.
07:12 pmichaud that is truly horrible.
07:12 pmichaud Especially since I'm only explicitly creating one PMC.
07:12 chromatic PCC is slow.
07:12 pmichaud and the rest is in registers.
07:12 chromatic Converting between C calling conventions and Parrot calling conventions is expensive.
07:15 chromatic The less code we have in C, the better.
07:19 lu_zero chromatic there isn't a way to make it cost less?
07:20 lu_zero (beside having gcc output something different)
07:28 TiMBuS joined #parrot
07:34 chromatic We can reduce the cost, but the problem is converting to and from PCC.
07:34 chromatic We lose so much information we cross the barrier, we can't optimize across it.
07:39 chromatic It also kills any possibility of JIT speedups.
08:20 szabgab joined #parrot
08:25 alvar joined #parrot
08:32 iblechbot joined #parrot
09:38 Gerd joined #parrot
09:39 gaz joined #parrot
09:45 Tene_ joined #parrot
09:59 tomyan joined #parrot
10:05 lu_zero I see
11:36 Gerd joined #parrot
12:00 Gerd Is it know that current Parrot revision can be not compiled
12:00 Gerd By me is stops with - gmake[1]: *** [PGE.pbc] Segmentation fault
12:08 masak Gerd: I don't have that issue here. what OS are you on?
12:08 moritz Gerd: is that a 64bit system?
12:16 Gerd my OS is Fedora 7 on a 32-bit system the revision is 36488
12:18 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?
12:19 Gerd It is a new checkout
12:20 masak that's not good, then. :/
12:20 moritz works here, with Debian i386 on 32 bit
12:21 moritz so it's really a platform specific problem
12:21 moritz Gerd: care to open a ticket?
12:21 masak parrotbug?
12:21 purl parrotbug is mailto:parrotbug@parrotcode.org or http://svn.perl.org/parrot/​trunk/docs/submissions.pod or see also "rakudobug" or needs to be converted to trac
12:21 moritz newticket?
12:21 moritz ticket?
12:21 purl ticket is easier to keep track of
12:21 moritz purl: tell me something usefull
12:21 purl moritz: huh?
12:22 masak purl--
12:22 purl masak: i'm not following you...
12:22 moritz purl: newticket is https://trac.parrot.org/parrot/newticket
12:22 purl OK, moritz.
12:22 moritz purl: ticket is <reply> https://trac.parrot.org/parrot/newticket
12:22 purl ...but ticket is easier to keep track of...
12:22 moritz purl: no, ticket is <reply> https://trac.parrot.org/parrot/newticket
12:22 purl okay, moritz.
12:22 Gerd okay I open a ticket
12:25 alvar joined #parrot
12:27 kj joined #parrot
12:31 elmex joined #parrot
13:06 alinbsp joined #parrot
13:08 kj Create a language compiler for .NET: http://msdn.microsoft.com/e​n-us/magazine/cc136756.aspx
13:09 kj in all the videos/blogs/tutorials on DLR/.NET targeting, Parrot is never mentioned; seems it's being ignored.
13:10 szbalint first they ignore you, then they laugh at you, then they fight you, then you win.
13:10 kj ha ha ha
13:10 kj It'd be nice to see Perl 6 for DLR :-)
13:12 Coke-really-afk (pge segfault) there's an rt ticket AND a trac ticket for that.
13:24 lu_zero hmm
13:25 gryphon joined #parrot
13:27 tomyan joined #parrot
13:31 * Coke wants (for purely technical reasons) to get trac wiki updates via email.
13:32 * Coke settles for mailing the interesting ones by hand.
13:43 szbalint set a rss watching spamming bot on the trac feed? :)
13:46 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 Coke (Then I can tag them in gmail, and use that to drive the summary)
14:02 riffraff joined #parrot
14:09 jan joined #parrot
14:13 rg joined #parrot
14:22 Whiteknight joined #parrot
14:27 PacoLinux joined #parrot
14:29 pmichaud should we eliminate the parrotbug@parrotcode.org address from the factoid?
14:30 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
14:30 pmichaud or perhaps  parrotbug@trac.parrot.org
14:31 pmichaud 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.
14:31 pmichaud oh, is tickets@parrot.org the "correct" address now?
14:31 Infinoid I have no idea.  It's just the address where email2trac is currently set up
14:32 rg i guess we can tell that to the infobot then
14:33 Coke can't email new tickets to the tickets@parrot.org address yet.
14:34 Infinoid oh?  it worked last week
14:34 Coke er, updates?
14:34 Coke part of it was broken, no?
14:34 Infinoid yeah, posting comments/followups didn't work yet
14:35 Coke my bad.
14:35 Coke the old address should eventually just be an alias for the new address, IMO.
14:35 pmichaud I agree.  I'm asking whether we should continue to advertise the old address.
14:38 Infinoid sounds like a policy decision, but if I get a vote, the new one looks cleaner
14:41 Infinoid does parrot-porters still exist?  or is that parrot-dev now?
14:41 pmichaud it's parrot-dev
14:41 pmichaud iiuc
14:42 Infinoid 'ack parrot-porters' reports 22 hits
14:42 * Infinoid cleans that up.
14:43 Coke pmichaud: until the new address is sorted out, no point in updating the docs.
14:43 Coke the old one works. putting in docs to say "we have two" is more confusing, IMO.
14:44 pmichaud I wasn't going to advertise two addresses, I was only going to advertise the correct one.
14:44 rurban__ joined #parrot
14:46 Coke the new one isn't correct yet.
14:46 Coke once email2trac works for everything, then it will be fine.
14:46 pmichaud Okay, excellent.  Thanks.
14:47 Coke (reducing confusion)++
14:47 Coke hurm. that's silly.
14:47 Coke confusion--
14:47 * Coke wonders why it initially feels more proper to karma up negative things.
14:48 pmichaud Because some negatives are actually positives.
14:49 pmichaud see, for example, 'electron'.  :-)
14:49 szbalint I think I need to extend the integer set of karma to complex, I want imaginary karma ;)
14:50 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
14:50 pmichaud we now have Parrot CLAs
14:51 Whiteknight do we need to fill out Parrot CLAs if we've already filled out a Perl CLA?
14:51 pmichaud http://www.parrot.org/files/parrot_cla.pdf
14:51 pmichaud Whiteknight: I don't know.
14:52 Infinoid submissions.pod also mentions obtaining a perl.org account (what's that for, RT?)
14:52 Infinoid I don't feel qualified to fix up this part of submissions.pod, but I'll trigger some interrupts
14:52 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.
14:52 * Coke supposes he should fill out a CLA. :|
14:53 Infinoid heh.
14:55 particle yes, the perl.org account is for rt, committers will need a parrot.org account for trac now
14:55 particle there's no legalities involved
14:58 Coke particle: we're talking about CLAs, not commit bits.
15:00 Infinoid well, the paragraphs are right next to eachother in submissions.pod and I think they will both need fixing up
15:01 Infinoid oh my, lots of codingstd failures.  did my s/// patch cause those?
15:03 Infinoid (nope, already there.)
15:05 dalek parrot: r36489 | Infinoid++ | trunk:
15:05 dalek parrot: [docs] Fix up old references to submitting/subscribing/archives for the old
15:05 dalek parrot: parrot-porters and perl6-internals lists.  There were a couple places where
15:05 dalek parrot: the hostname varied (parrot.org or lists.parrot.org), fix those to be
15:05 dalek parrot: consistent with the official address.
15:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36489/
15:06 PerlJam good morning #parrot people
15:06 Infinoid hai PerlJam
15:12 dalek parrot: r36490 | Infinoid++ | trunk/src:
15:12 dalek parrot: [cage] Fix some codingstd failures.  (This fixes everything but the PDD format failures for me.)
15:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36490/
15:14 Coke rant: we shouldn't have "if 0" code checked in, should we?
15:15 dalek parrot: r36491 | fperrad++ | trunk/t/codingstd/perlcritic.t:
15:15 dalek parrot: [codingstd] use the same interface than over tests
15:15 dalek parrot: needed by tests in languages
15:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36491/
15:16 dalek parrot: r36492 | fperrad++ | trunk/languages/lua/config/makefiles/root.in:
15:16 Andy joined #parrot
15:16 dalek parrot: [Lua] more codetest (especially PerlCritic)
15:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36492/
15:17 Tene joined #parrot
15:24 * Coke gets a segfault on pgegrep.
15:24 * Coke updates and realcleans to double check.
15:27 PerlJam is the parrot dead?
15:27 * masak groans
15:28 Infinoid parrot_config.c:129: error: expected expression at end of input
15:28 Infinoid parrot_config.c:129: error: too few arguments to function 'PackFile_unpack'
15:28 Infinoid nice.
15:28 PerlJam I haven't really tried building much since the repository moves, but a fresh checkout dies ... with what Infinoid said
15:28 Infinoid it built fine yesterday
15:30 * Coke wonders how big this bt is.
15:32 Infinoid driving in snow, back in 30m &
15:33 PerlJam wait a second.  "make realclean; perl Configure.pl && make" dies differently
15:33 PerlJam parrot_config.c:129: error: ‘PackFile_unpa’ undeclared (first use in this function)
15:34 PerlJam oh.  parrot_config.c was incompletely built.
15:35 Coke ... this bt is too large to attach to trac.
15:35 Coke (partial bt. gzip -9'd)
15:39 dalek parrot: r36493 | fperrad++ | trunk/t/codingstd/pdd_format.t:
15:39 dalek parrot: [codingstd] update test with new requirement of POD documentation
15:39 dalek parrot: see TT #292
15:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36493/
15:40 galf joined #parrot
15:59 Infinoid ok, back
15:59 Infinoid PerlJam: yeah, for me parrot_config.c is cut off directly after "if (!PackFile_unpack("
16:00 * pmichaud considers re-installing 64-bit kubuntu.
16:03 Infinoid actually, the point where it gets cut off varies.  This time I got "if (!PackFile_unpack(i"
16:04 Infinoid 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?
16:05 Infinoid I would have thought so
16:05 kj I'm pretty sure it does, but I could be mistaken of course
16:05 Infinoid oh, I'm sure it does... you can generate a whole file without ever explicitly calling flush
16:06 Infinoid it just seems like this is somehow buffer-related
16:06 Infinoid the fact that parrot_config.c is exactly 8192 bytes long seems to add weight to that hunch
16:07 Infinoid welp... when in doubt, bisect.
16:07 rg sounds to me more like it crashed
16:07 rg while writing the file
16:08 rg 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. =-)
16:08 Infinoid the 90% faster thing?
16:08 Infinoid well, that's easy to test, one moment
16:10 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.
16:10 pmichaud but it's entirely possible.
16:10 Infinoid pbc_to_exe is generating this .c file (well, generating most of it)
16:12 Infinoid 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 http://nopaste.snit.ch/15549
16:12 pmichaud it's hard for me to see how it could be failing to flush a buffer.
16:12 pmichaud note that the statement immediately following the print to the file is 'close'
16:13 particle linking fails for me when creating perl6.exe
16:13 moritz that's not perl 5, right?
16:13 pmichaud it's PIR
16:14 pmichaud so if the file is being cut off with "if (!PackFile_unpack(" then it's likely a Parrot bug.
16:15 Infinoid the exact point of cutoff varies, I think because some of the preceding array data varies in ascii length
16:15 Infinoid the file is cut off at 8192, exactly 2 vm/io pages
16:15 pmichaud Infinoid: I believe you.  I just don't see how pbc_to_exe can be the cause.
16:16 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?
16:16 pmichaud Coke:  it was PIR before.
16:16 Coke hurm.
16:16 pmichaud it was different PIR, but it was PIR.
16:16 Infinoid I really want that 90% speed improvement, I just need the whole .c file too :)
16:16 pmichaud I presume all concerned have done a 'make realclean' and rebuilt the Makefile?  That changed also.
16:16 Coke Infinoid: put in an explicit flush to see if that helps. :|
16:17 Infinoid several times, yes.
16:19 particle i'd rather have a 90% speed improvement in running perl6, rather than in generating it
16:20 particle but i'll take what i can get :)
16:22 Coke Infinoid: I'm not seeing the problem on darwin/x86
16:23 jonathan hi all
16:23 Infinoid ok, something specific to me then
16:23 moritz hi jonathan
16:23 rg no, i can reproduce the error on freebsd/amd64
16:23 Infinoid PerlJam: are you on x86-64?
16:23 PerlJam Infinoid: no, something specific to us.  Which last time was 64 bit CPU
16:23 PerlJam :-)
16:23 PerlJam yes
16:23 Infinoid here too.  that's probably the cutoff
16:28 nopaste "Infinoid" at 96.238.213.50 pasted "The Evidence (from strace)" (10 lines) at http://nopaste.snit.ch/15550
16:29 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:32 jonathan pmichaud: ping
16:32 pmichaud jonathan: pong
16:34 jonathan pmichaud: Hi! :-)
16:34 jonathan 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.
16:35 pmichaud that's fine with me.
16:35 jonathan Any days that you expect to be around/not around etc?
16:35 pmichaud I want to do the same -- RT queue is getting a bit full.
16:35 pmichaud I expect to be around most every day this week.
16:35 jonathan Great! :-)
16:35 jonathan I've been at a conference and had guests, but from tomorrow I'm back to normal, undisrupted work time.
16:35 pmichaud excellent.
16:36 jonathan How was the hackathon?
16:36 pmichaud *lots* of enthusiasm for Rakudo at Frozen Perl.
16:36 pmichaud hackathon was very good.  I wish our build system had been a bit farther along.
16:36 moritz I merged a rakudo patch from chris dolan
16:37 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.
16:37 jonathan I saw a comment in the sldies as to wanting to get Rakudo released in 2009.
16:37 pmichaud jonathan: you might review chrisdolan's patch for sanity.
16:37 pmichaud Andy thinks that needs to happen, yes.
16:37 jonathan What kinda release was he meaning?
16:37 jonathan It wasn't entirely clear to m.
16:37 jonathan *me
16:38 pmichaud I'm not sure it was entirely clear from the talk, either.
16:38 jonathan OK.
16:38 pmichaud But he was talking about something more substantial than just the compiler.
16:38 pmichaud 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.
16:38 pmichaud If we don't have a good release by early 2010, though, I'm going to cast about for a successor.  :-)
16:39 pmichaud 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.
16:39 jonathan But I think production release in 2009 is epicly unrealistic.
16:39 moritz aye
16:39 particle $$$
16:39 pmichaud well, it depends on the meaning of "production".
16:39 pmichaud I definitely wouldlike to see "useful" releases in 2009.
16:40 jonathan Aye.
16:40 jonathan particle: It's not just about money, though it helps. :-)
16:40 PerlJam Are you saying it's not useful now?  ;)
16:40 pmichaud anyway, I've neither endorsed nor repudiated Andy's suggestion.  :-)
16:40 Infinoid PerlJam, rg, pmichaud: I've made TT #296 to track the pbc_to_exe I/O issue
16:41 pmichaud Infinoid++
16:41 pmichaud I'll see if I can install 64-bit kubuntu on my shiny new laptop and reproduce and trace a bit.
16:41 pmichaud I'm thinking that we'll need to rely on fakecutable perl6 for a while.
16:42 Infinoid ok.  I'll bang on it after work if I have time
16:42 particle can we use parrot's exec runcore?
16:42 Infinoid work &
16:42 Andy I really wish I coulda been there for the hackathon.
16:43 NotFound joined #parrot
16:43 NotFound hi
16:43 pmichaud particle: I don't understand "parrot's exec runcore"
16:43 Andy My real point was that we had to get Rakudo out
16:43 particle it generates a native executable
16:44 Andy it was more about "we're nearing the end" than "here's the date"
16:44 Andy Consider it a mini mug-throwing.
16:44 pmichaud Andy: I thought of you during the hackathon  (more)
16:44 pmichaud Andy: Guess what the most common variable name was in the pbc_to_exe program I worked on...?  ;-)
16:44 jonathan pmichaud: Got an RT# handy for Chris's patch you want me to sanity check?
16:44 particle anyway, it's more of a musing, i'll need to look into whether the exec runcore is even functional at this point
16:44 Andy hahahaha
16:44 purl LOLCON 4 reached.
16:44 dalek parrot: r36494 | NotFound++ | trunk/tools/util/pgegrep:
16:45 dalek parrot: [tools] fix an exception handler in pgegrep, TT #295
16:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36494/
16:45 Andy pmichaud: I made my first branch last night
16:45 pmichaud jonathan: yes -- just a sec.
16:45 Andy how do we merge back?
16:45 Andy How do you get notified
16:45 jonathan particle: exec runcore would be ideal...if it works. :-|
16:45 pmichaud Andy: we can still do "submit patches to rakudobug@perl.org"
16:45 Andy Well, I've got a git branch
16:46 pmichaud I still don't know/understand the whole git branch model yet.
16:46 pmichaud I'm sure I'll get there.  :-)
16:46 Andy ok
16:46 pmichaud if someone wanted to draft a "git committers guide" that'd be very helpful.  :-)
16:46 particle andy: there's a bunch of guides on github.com
16:46 Andy on launchpad, you "propose a merge"
16:46 Andy hey, particle, you were in my slides, too
16:47 pmichaud (a "git committers guide for rakudo", I mean)
16:47 particle i'm imfamous!
16:47 Infinoid I'm guessing "propose a merge" means "tell pmichaud to git pull blah"?
16:47 particle andy: where are your slides?
16:47 pmichaud well, it could be any rakudo committer, I suppose.
16:47 Andy slideshare
16:47 purl slideshare is in need of being called slideshr or http://www.slideshare.net
16:47 pmichaud but yes, we'd like patches/pulls to be reviewed.
16:47 Andy added to http://xoa.petdance.com/What_we_need_on_​rakudo.org#After_the_new_Drupal_rollout
16:47 shorten Andy's url is at http://xrl.us/befk2q
16:48 particle got em
16:48 Andy I'm working on brinigng over the perlcritic stuff from Parrot
16:48 Andy also, random consting 'cause, you know, that's how I rolls.
16:49 particle i see you got my good side
16:52 jonathan pmichaud: Configure.pl now fails for me on Windows. :-(
16:52 jonathan (Rakudo's one.)
16:53 nopaste "jonathan" at 85.216.157.73 pasted "failure" (6 lines) at http://nopaste.snit.ch/15553
16:53 jonathan pmichaud: It strikes me that if I uncommented this block:
16:54 jonathan if (!$options{'parrot-config'} && -e "../../tools/dev/reconfigure.pl") {
16:54 jonathan Then it'd work...but I suspectthat's not the real issue...
16:54 Andy hey, pmichaud My parrot seemed to build just find.
16:54 Andy fine
16:54 jonathan ah, it's hardcoded forward slashes.
16:55 Infinoid does Andy D have a commit bit?
16:56 pmichaud I thought I got rid of the reconfigure.pl line.
16:57 pmichaud Yes, I did.
16:57 jonathan It's just commented out.
16:57 pmichaud right.
16:57 pmichaud I no longer want to be using Parrot's reconfigure.pl .
16:57 jonathan OK
16:58 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?
16:58 particle Infinoid: andyd has frequently refused commit bits
16:58 pmichaud I thought that was built by default.
16:58 pmichaud It's built by default on my system.
16:58 particle he doesn't have direct network access, he needs to ftp to his devel environment
16:58 particle so he has no great way to do commits, and prefers submitting high quality patches forever
16:59 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.
16:59 * Infinoid starts with TT #294
17:00 nopaste "NotFound" at 213.96.228.50 pasted "Access PMC attributes from derived pir classes - with ExceptionHandler fixes that uses it" (154 lines) at http://nopaste.snit.ch/15555
17:00 rhr joined #parrot
17:01 NotFound This patch can solve several inheritance problems, but I'm not sure that this is the way to go
17:05 dalek parrot: r36495 | Infinoid++ | trunk/config/auto/format.pm:
17:05 dalek parrot: Apply patch from doughera++ in TT #294.
17:05 dalek parrot: [config] Use "long double" printf format from perl5 config; "%.15Lg" isn't
17:05 dalek parrot: always correct.
17:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36495/
17:07 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:08 pmichaud jonathan: okay.  I think I need to set up a Win devel environment at some point.
17:12 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.
17:12 pmichaud I wasn't aware of #282 when I did my pbc_to_exe work.
17:13 hercynium joined #parrot
17:13 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:17 particle yes, i developed pbc_to_exe with chromatic, it should work on win32 and linux
17:17 particle i'm currently getting a link failure, but i think that's due to rurban's changes and not pmichaud's
17:18 pmichaud yes, I don't think I changed anything in the link phase.
17:18 pmichaud I only changed the way the .c file was being generated.
17:18 particle ok, that's what i thought i saw
17:18 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
17:19 particle msvc needs an absolute filename for libparrot.lib
17:19 tomyan joined #parrot
17:19 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:20 Infinoid that's all.
17:20 particle ah, gotcha
17:21 tomyan joined #parrot
17:28 mikehh joined #parrot
17:36 nopaste "NotFound" at 213.96.228.50 pasted "Don't hide close errors" (99 lines) at http://nopaste.snit.ch/15557
17:37 NotFound Please take a look at this patch, and somenoe try it on win32
17:42 Theory joined #parrot
17:46 rurban particle: for win32 there's still a hints patch pending.
17:47 rurban I also tried to fix bigint.pmc
17:47 kj Coke++ # TWIP
17:48 Whiteknight TWIP?
17:48 kj see parrot.org
17:48 dalek parrot: r36496 | Infinoid++ | trunk/tools/dev/pbc_to_exe.pir:
17:49 dalek parrot: Apply patch from doughera++ in TT #282:
17:49 dalek parrot: pbc_to_exe should use 'link' to link.  (See config/init/defaults.pm
17:49 dalek parrot: for details.)
17:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36496/
17:49 kj (I knew that should trigger *someone* to be curious ;-)
17:49 particle TWIP is "this week in parrot"
17:49 particle purl, TWIP is "this week in parrot"
17:49 purl i already had it that way, particle.
17:50 particle purl, TWOP is "that was obnoxious, purl"
17:50 purl OK, particle.
17:50 dalek partcl: r326 | wcoleda++ | trunk/src/binary.c:
17:50 rurban BTW: we still miss linkflags (TT #282), my patch was reverted, so linkflags is ignored.
17:51 dalek partcl: Modify/trunk/src/pmc/tclfloat.pmc
17:51 dalek partcl:
17:51 dalek partcl:
17:51 dalek partcl:  Modify/trunk/src/pmc/tcllist.pmc
17:51 dalek partcl:
17:51 dalek partcl:
17:51 dalek partcl:  Modify/trunk/src/pmc/tclstring.pmc
17:51 dalek partcl:
17:51 dalek partcl:
17:51 dalek partcl:  Track rename of string_length
17:51 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=326
17:51 Infinoid hrm.
17:51 * particle kicks dalek
17:51 Infinoid another day, another rss parser to fix
17:52 Infinoid 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
17:52 PerlJam Infinoid: parsers written in perl 6?  :)
17:52 particle god no! we want this to be stable, and fast!
17:53 particle 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
17:53 moritz ah, that's the "high quality" part of it ;-) *me ducks*
17:53 Whiteknight purl no, TWOP is <reply>*purl hits himself in the head*
17:53 purl okay, Whiteknight.
17:53 Whiteknight TWOP?
17:53 purl *purl hits himself in the head*
17:53 Infinoid TWOP!
17:54 Infinoid aaw.
17:54 Whiteknight TWOP
17:54 moritz Whiteknight++
17:54 moritz TWOP?
17:54 purl *purl hits himself in the head*
17:54 Infinoid purl: TWOP
17:54 purl *purl hits himself in the head*
17:54 kj particle: I hope everybody notices the self-deprecation, otherwise it may show up on reddit in another parrot-bashing topic ;-)
17:54 Infinoid fun.
17:55 PerlJam kj: There have been mischievous lurkers who wouldn't care about the context.
17:56 kj PerlJam: exactly..
17:56 kj ah well. some attention is better than no attention
17:56 geof joined #parrot
17:56 dalek parrot: r36497 | particle++ | trunk/lib/Parrot/Test.pm:
17:56 dalek parrot: [lib] fix some indentation-challenged logic, and correct a broken case for ccache with msvc
17:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36497/
17:57 kj particle: where did you get ccache for msvc?
17:57 kj I've tried to find it; but failed
17:57 particle google
17:58 Infinoid ccache-win32 is for mingw, I think
17:58 particle http://artax.karlin.mff.cuni.cz/~kendy/ccache/
17:58 Infinoid purl, ccache-msvc is http://artax.karlin.mff.cuni.cz/~kendy/ccache/
17:58 purl OK, Infinoid.
18:02 nopaste "rurban" at 212.183.63.40 pasted "my needed mingw fixes: no static lib, no blib_dir" (93 lines) at http://nopaste.snit.ch/15558
18:03 nopaste "rurban" at 212.183.63.40 pasted "my bigint.pmc work from today" (351 lines) at http://nopaste.snit.ch/15559
18:03 rurban bignum, sorry
18:04 rurban there are several totally unneeded bignum methods, probably copy & paste from bigint, like shl, shr, mod, fdiv
18:05 rurban I tried to accept bigint PMC's for bignum methods, but doesn't look easy.
18:06 * particle rebuilds with rurban's patch
18:06 particle ...mingw patch...
18:07 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:08 rurban since nobody needs the static lib on win32 because then dynpmc's willnot work, I disabled it
18:08 rurban target: LIBPARROT_STATIC: dummy.static in the Makefile
18:09 rurban pbc_to_exe works fine with msvc, mingw, cygwin
18:10 dalek parrot: r36498 | particle++ | trunk/t/codingstd/copyright.t:
18:10 dalek parrot: [t] modify coding standard test to look for 'Parrot Foundation' in copyright
18:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36498/
18:11 jsut|work joined #parrot
18:11 mikehh I think r36495 causes t/steps/auto_format-01.t to fail
18:12 kj particle: should copyright notices be changed to grant to parrot foundation?
18:13 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
18:14 rurban The lurking 64bit align packfile bug not yet.
18:14 mikehh #   at t/steps/auto_format-01.t line 102.
18:14 dalek parrot: r36499 | particle++ | trunk/README:
18:14 dalek parrot: update copyright in README (the most important copyright notice)
18:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36499/
18:14 particle kj: yes, all files except LICENSE, which is properly TPF
18:14 mikehh #          got: '%.15Lg'
18:15 kj oki. Can that be changed using a script?
18:15 kj or manually?
18:15 mikehh #     expected: '%Lf'
18:15 particle perl -i should do it
18:15 particle i just changed the test and most important file, to get the ball rolling
18:16 Infinoid urk
18:18 Infinoid mikehh: thanks, I'm thinking maybe the test should be changed
18:18 chromatic joined #parrot
18:21 Infinoid chromatic: Any chance you know what TT #296 might be caused by, off the top of your head?
18:22 chromatic Off the top of my head, no.
18:22 mikehh yes - it does cause perl Configure.pl --optimize --test to fail before configure
18:22 chromatic As a guess, probably an assumption about sizes that's not true.
18:23 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
18:24 Infinoid mikehh: Yeah.  r36495 changed the hardcoded format string but not the hardcoded test
18:25 Infinoid rakudo: say "Infinoid-- # committing patches without fully testing them"
18:25 polyglotbot OUTPUT[Infinoid-- # committing patches without fully testing them␤]
18:26 Whiteknight Infinoid++ # admitting your mistakes
18:30 dalek parrot: r36500 | fperrad++ | trunk/languages/lua/src/pmc/luathread.pmc:
18:30 dalek parrot: [Lua] refactor LuaThread PMC with ATTR
18:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36500/
18:33 dalek parrot: r36501 | fperrad++ | trunk/languages/lua/doc:
18:33 dalek parrot: [Lua] Abandoning daft Perl 5-style documentation headings.
18:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36501/
18:34 dalek parrot: r36502 | Infinoid++ | trunk/t/steps/auto_format-01.t:
18:34 dalek parrot: [t] Fix some test fallout from r36495.
18:34 dalek parrot: r36495 patched the hardcoded format string but not the hardcoded test.
18:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36502/
18:35 NotFound Infinoid: you can try #297, maybe it can help to diagnose #296
18:36 rurban The #297 patch is the same as nopaste 15557? I'm trying that right now
18:36 NotFound rurban: yes, same patch
18:37 rurban sounds good so far.
18:37 NotFound Nobody answered here, so I create tickets to not forget the issues ;)
18:40 rurban I could reproduce in the morning with t/src/extend.t test 17 failing on mingw and cygwin
18:44 NotFound rurban: I think that test uses global symbols, so is exposed to the same problems with global charsets and encodings
18:48 rurban I think I have a minor issue with make reconfig when no Configure.pl args was given. Will check later
18:49 NotFound I can't find that, maybe that part was already discarded.
18:52 particle what is a "DIR *" in parrot?
18:52 particle i can't find a tag for it
18:52 pmichaud I think that might actually come from c library.
18:52 pmichaud like FILE *
18:52 particle or is that an os thing.
18:52 chromatic Probably an OS thing.
18:52 particle ok, that needs to be abstracted away
18:52 chromatic Hm, no comments on my "Here's why writing methods in C is bad." message yet.
18:53 pmichaud particle:  http://www.gnu.org/software/libtool/​manual/libc/Opening-a-Directory.html
18:53 shorten pmichaud's url is at http://xrl.us/befmio
18:53 * particle git clones perl5
18:54 kj chromatic: 1,454 PMCs for "hello world"??!! That seems like a bit of overkill :-P
18:55 chromatic It takes that many PMCs to start Parrot.
18:57 kj yeah. so much for 'lean and mean'.
18:57 kj chromatic: so basically PIR methods are faster than C methods?
18:57 chromatic Very much so.
18:58 particle parrot++ # faster than c :)
18:58 kj it's slightly non-intuitive. "C" often implies high speed
18:58 NotFound What is slow are call chains: bytecode -> C -> bytecode -> C -> bytecode ...
18:58 kj but I understood why...
18:58 chromatic There are only three advantages for C code in Parrot.
18:58 chromatic 1) Direct access to memory
18:59 chromatic 2) Direct calls to other C code which uses C calling conventions
18:59 chromatic 3) Algorithms which do not call PCC and need tremendous speed
18:59 chromatic #3 is rare.
18:59 kj chromatic: GC?
18:59 purl GC is probably the boehm conservative garbage collector at http://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
18:59 chromatic We could work around #1.
18:59 pmichaud some algorithms are easier to write in C than PIR, also.
18:59 chromatic kj, GC doesn't even have to be written in C.
19:00 chromatic #2 is really the only sticking point.
19:00 kj chromatic: no, but surely it must be faster than PIR
19:00 chromatic Not necessarily.
19:00 NotFound We can write the GC in brainfuck
19:00 kj heh
19:00 chromatic You mean we didn't?
19:00 kj :-)
19:01 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.
19:01 PerlJam or you could write a language that expresses things in terms of common/useful GC operations and write  the GC in that language.  :-)
19:01 Infinoid who GC's the GC?
19:02 chromatic I did write a self-hosting GC once.
19:02 PerlJam Infinoid: it's still tutles all the way down.
19:02 PerlJam er, turtles even
19:02 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
19:02 Infinoid as long as they keep getting bigger, I'm ok with that
19:03 chromatic PMCs and ops especially.
19:03 chromatic Anytime any C function calls back into the Parrot runloop, we lose.
19:03 chromatic We lose big.
19:03 NotFound BTW, you can take a look at TT #299 to help solve one obstacle against writing things in pir
19:05 chromatic The worst part is that the puts() method on FileHandle doesn't have to be 2500 times slower.
19:05 Theory joined #parrot
19:05 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)
19:05 chromatic Well, 2500 times more expensive in terms of garbage anyway.
19:05 chromatic Will do in a bit.
19:07 chromatic 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:09 rurban So the op preprocessor has to be rewritten to emit pir and not C?
19:10 rurban Because I thought the ops are already pir
19:10 NotFound The ops are ops.
19:11 pmichaud chromatic: how do you measure the number of PMCs created?
19:11 pmichaud i.e., what option is it?
19:12 NotFound Writing a Parrot VM interpreter in a language hosted in Parrot will be a nice excersise.
19:13 NotFound pmichaud: the info command of parrot_debugger can be helpful
19:17 Coke pmichaud: interpinfo .INTERPINFO_TOTAL_PMCS ?
19:18 Coke (from http://code.google.com/p/partcl/sou​rce/browse/trunk/src/macros.pir#113)
19:18 shorten Coke's url is at http://xrl.us/befmnu
19:19 Coke (implemeting a HLL sooner rather than later) yes, I agree, that would have been very helpful.
19:20 Coke 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:23 Coke but if we had, say, a small scheme in place in year 1, I think parrot would look very different today.
19:24 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
19:24 pmichaud (even as I change the code to produce more/less PMCs)
19:27 pmichaud 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
19:27 pmichaud Whiteknight: that's fine -- thus my original question:  how to obtain it?
19:27 NotFound pmichaud: yes, I'm testing with ecamscript under parrot_debugger and the number of Total PMC does not vary
19:28 pmichaud i.e., I'm wondering how chromatic gets his numbers (so I can do similar benchmarking here)
19:28 pmichaud install 64-bit kubuntu on new laptop:  FAIL
19:29 pmichaud oh well, back to comfy 32-bit
19:30 Infinoid aaw.
19:30 pmichaud install worked fine, but applying updates caused the network card to stop working.
19:31 Infinoid e1000 network card chipset?
19:33 pmichaud can't find the card type
19:35 Infinoid mine looks like 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
19:35 Infinoid (in the output of "lspci")
19:36 pmichaud Intel Corporation 82567LM Gigabit Network Connection (rev 03)
19:36 Infinoid yep, same driver (e1000)
19:37 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
19:37 pmichaud oh, I often had trouble with suse + e1000 as well.
19:38 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.
19:50 Infinoid pmichaud: https://bugs.launchpad.net/ubu​ntu/+source/linux/+bug/263555  (I'm not sure what "Fix Released" means in this case)
20:10 dalek parrot: r36503 | fperrad++ | trunk/languages/lua/src/pmc/luathread.pmc:
20:10 dalek parrot: [Lua] fix line length
20:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36503/
20:13 dalek parrot: r36504 | NotFound++ | trunk:
20:13 dalek parrot: [debugger] some fixes and add an option to pirric for interaction with the debugger
20:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36504/
20:34 chip joined #parrot
20:34 chip regreets
20:35 chromatic Sick of Perl 5's guts yet, chip?
20:36 Coke hey, chip.
20:39 * 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
20:40 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.
20:41 * 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.
20:41 Whiteknight See, there are some things for which C is still well-suited. Kernels are one of them
20:42 tewk the conjecture was qualified for language vms :)
20:42 jonathan joined #parrot
20:42 chromatic I stand by my statement.
20:46 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:47 Whiteknight It used to be when I needed to write something, I used C. Now it's all perl.
20:48 tewk I've had to write some python lately, I'm sick of explicit self and $self, save me perl6
20:50 dalek parrot: r36505 | rurban++ | trunk/Configure.pl:
20:50 dalek parrot: RT#58034: make reconfig, fix a cornercase when no args are given
20:50 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36505/
20:51 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:52 Whiteknight 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
20:53 Infinoid 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
20:53 Infinoid lucky parrot
20:53 Whiteknight Infinoid: Whereabouts do you work?
20:56 Infinoid I work for a wireless networking hardware startup that isn't doing too well at the moment...
20:57 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:58 Infinoid chances are, it isn't running my code then :)
21:00 Whiteknight no, it's some piece of shit netgear router. worst. router. ever.
21:01 rurban who in the world buys this crap
21:01 Infinoid Whiteknight, apparently
21:01 mikehh chromatic: where do you think we should be going in moving away from C code?
21:01 Infinoid XS!
21:02 Whiteknight BLASPHEMY!
21:02 Infinoid like it nor not, at least I'd be able to hide the ASSERT_ARGS() nonsense
21:02 mikehh most definately!!!
21:03 dalek parrot: r36506 | fperrad++ | trunk/languages/lua/src/pmc:
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 :)
21:03 dalek parrot: [Lua] refactor metatable access, and s/find_meth/_LuaAny_find_meth/
21:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36506/
21:04 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.
21:04 mikehh sort of riscify?
21:05 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
21:05 Whiteknight later
21:05 chromatic ta
21:05 chromatic mikehh, Smalltalk does (or did, at least -- I haven't looked at a modern Smalltalk) something similar.
21:06 chromatic 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
21:06 chromatic Almost all of the code could stay in the same runloop.
21:06 rurban like in lisp
21:06 chromatic We wouldn't have the PMCProxy mess, or inheriting from C-based PMCs, or....
21:07 chromatic We wouldn't have to use C calling conventions except for calling C code (which NEVER calls back into Parrot code).
21:08 mikehh just returns a value
21:08 alvar joined #parrot
21:12 mikehh how minimalist could you go?
21:12 chromatic 64 core ops could do it.
21:13 chromatic 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:14 chromatic 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:15 Infinoid I love the contract model in Eiffel
21:15 * moritz too
21:15 moritz just the syntax is too verbose, a little bit javaish :(
21:16 chromatic Hm, you could almost trivially put contracts into Parrot that way too.
21:16 chromatic *Optional* contracts.
21:17 Infinoid without another ASSERT_ARGS() type mess? :)
21:17 chromatic Right.
21:17 Infinoid WANT
21:18 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?
21:19 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).
21:19 chromatic Oh, right.
21:19 chromatic But it could be optional.
21:20 chromatic Also with JIT much more trivial, I suspect things could go faster.
21:20 Infinoid ./configure --bat-outta-hell
21:21 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:22 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
21:23 chromatic more like base_ops
21:23 particle bootstrap_ops
21:24 rurban c_ops
21:24 chromatic Right, something along those lines.
21:24 mikehh Yes but you also need to optimize for speed
21:25 chromatic That's what started this whole mess!
21:25 Infinoid Fewer ops means more attention to optimizing those ops.
21:25 chromatic The idea that you have to write slow bits in C sounds good, but in practice it's wrong.
21:25 rurban jit
21:26 chromatic A method call to a method written in C has at least one barrier the JIT cannot cross.
21:27 chromatic A method call to a method written in PIR is fully JITtable.
21:27 chromatic It's probably even inlinable.
21:27 chromatic *inlinable
21:27 chromatic If it's in a loop, even the method lookup is cacheable.
21:27 mikehh I like it
21:27 chromatic *and* the check for the loop invariant "Oh, we can't use the cached form!" is effectively free, thanks to processor prediction.
21:29 chromatic 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 chromatic 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.
21:30 GeJ Good morning everyone
21:30 rurban eek, icc and llcm-gcc stopped working..
21:30 rurban llvm-gcc
21:32 barney joined #parrot
21:32 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 #parrot
21:33 chromatic I've been toying with a proof of concept VM, as that seems like the best approach to demonstrate this bootstrappy.
21:34 chromatic 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:36 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:38 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:40 rurban nci would be faster?
21:41 rurban I doubt: just write less C and more pir
21:41 chromatic That's hard to say.
21:41 rurban eg the String class?
21:42 rurban 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.
21:42 chromatic For now we do.
21:42 chromatic Only because our architecture demands that there's a barrier.
21:42 chromatic There doesn't have to be a barrier.
21:43 Coke ORLY?
21:43 purl YA RLY.
21:43 chromatic Really.
21:43 Coke nifty.
21:43 chromatic That's my point.
21:43 chromatic We need to stop thinking that writing things in C makes them fast.  It doesn't.  It makes them *slower*.
21:43 particle sure, if we store our args in registers and call them by name
21:44 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
21:44 particle for *arguments* :)
21:45 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.
21:45 Coke chromatic: I'd be interested to see a writeup of your ideas somewhere.
21:46 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?)
21:46 chromatic 1.5 is a stretch.  2.0 is a possibility.
21:47 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.
21:48 rurban are there numbers for the "damage"
21:48 chromatic Sure, see pm's benchmark on the list.
21:48 chromatic Or the examples/benchmarks/primes2.pir code.
21:50 Tene_ joined #parrot
21:53 Coke (partially usuable) that would be nice.
21:54 chromatic Every time I try to optimize things, I keep running into that barrier.
21:59 Whiteknight joined #parrot
22:07 Coke Every time I try to optimize things, I realize I didn't know what was slow. :|
22:07 Coke I've given up on that, at least from tcl's standpoint.
22:08 Coke irclogs?
22:08 purl well, irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
22:17 alvar joined #parrot
22:18 dalek parrot: r36507 | NotFound++ | trunk/examples:
22:18 dalek parrot: [examples] Mysql and pirric fixes
22:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36507/
22:28 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:30 chromatic Some configuration test is probably not using File::Temp and has hardcoded '$$' somewhere.
22:33 mikehh all length 50 containing the line
22:33 mikehh # Test reporting sourcefile line numbers. TT #279
22:37 chromatic lib/Parrot/Configure/Compiler.pm line 347
22:38 tewk chromatic: is there a quick way to export all subs in perl5 or export all subs minus some exceptions?
22:39 chromatic Use tags in EXPORT_OK
22:39 chromatic perldoc Exporter
22:40 chromatic Perl6::Export (or whatever the name is) might work too.
22:40 dalek parrot: r36508 | allison++ | branches/kill_pccinvoke:
22:40 dalek parrot: Creating branch for refactoring calling conventions, removing the old PCCINVOKE and streamlining the rest.
22:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36508/
22:43 dalek parrot: r36509 | chromatic++ | trunk/t/steps/gen_makefiles-01.t:
22:43 dalek parrot: [t] Ensured the removal of a temporary file generated by
22:43 dalek parrot: Parrot::Configure::Compiler.
22:43 dalek parrot: Tidied code.
22:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36509/
22:45 rurban__ joined #parrot
22:49 szabgab chromatic, did you have a chance to look at the Parrot::Embed stuff ?
22:49 chromatic I haven't, I'm sorry.
22:49 chromatic What's your top priority?
22:51 szabgab remove SKIP from t/languages.t
22:53 chromatic Will work on that.
22:54 szabgab thanks, once that works I'll try to write and send other tests
23:02 allison joined #parrot
23:05 NotFound allison: can you take a look at TT #299 ?
23:11 allison NotFound: sure
23:13 allison 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:14 allison NotFound: That's what GET_ATTR is for, to access the high-level attribute from a high-level object
23:14 allison (but still access the low-level attribute from a low-level object
23:14 NotFound allison: yes, if the children redefines it.
23:15 allison NotFound: the problem is we're not automatically adding the high-level attributes when a child subclasses from a low-level PMC
23:16 NotFound allison: I thinked about that way, but I don't see where to get the ATTR list from.
23:17 allison NotFound: now, that's something PMCProxy could do
23:17 allison NotFound: yes, the ATTR list needs to be serialized into the low-level PMC definition
23:17 Whiteknight allison: you beat me to it: I was going to create a new calling conventions branch tonight
23:18 allison NotFound: it could be simply captured raw, so PMCProxy can parse it, or provided as a C function with a constant struct
23:19 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?
23:21 Whiteknight 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
23:21 allison Whiteknight: if you're getting a String PMC, is it the name of the class?
23:22 Whiteknight I don't know yet, I'm just looking at a backtrace right now
23:23 Whiteknight 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
23:24 Whiteknight NotFound: that's an interesting alternative.
23:24 Whiteknight 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
23:26 dalek parrot: r36510 | allison++ | branches/kill_pccinvoke/src/call:
23:26 dalek parrot: [pcc] Moving the core files for C and Parrot calling conventions for
23:26 dalek parrot: maintenance sanity.
23:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36510/
23:34 dalek parrot: r36511 | allison++ | branches/kill_pccinvoke/include/parrot/call.h:
23:34 dalek parrot: [pcc] Renaming files for C and Parrot calling conventions for greater
23:34 dalek parrot: maintenance sanity.
23:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36511/
23:36 Whiteknight sanity++
23:36 mikehh t/steps/gen_makefiles-01.t generates a tmp file that is not removed
23:37 mikehh prove t/steps/gen_makefiles-01.t
23:37 mikehh -rw-r--r-- 1 mhk mhk     50 2009-02-09 23:32 Makefile_21487.out.tmp
23:38 Tene joined #parrot
23:38 particle mikehh: https://trac.parrot.org/parrot/changeset/36509/
23:40 mikehh particle: ok I am r36504 - let me svn up etc
23:44 Theory joined #parrot
23:46 mikehh The problem with chromatic++ is that he has fixed the thing before I have even tracked it down
23:47 Whiteknight yeah, it's definitely a problem
23:51 Whiteknight eventually I'm going to write up a shell alias for "maek"
23:51 Whiteknight because when I type "maek test", it should DWIM
23:52 Whiteknight 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 Whiteknight motivational speaker chromatic has me fired up about it
23:53 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.
23:55 Whiteknight Macarthur foundation? stupid biased genius tests
23:56 particle i'll work on a shell alias for maek without a macarthur grant.
23:56 particle i'm not proud.
23:56 chromatic Scab.  You're pushing wages down.
23:59 cognominal joined #parrot
23:59 dalek parrot: r36512 | allison++ | branches/kill_pccinvoke:

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced