Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-24

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 ilia joined #parrot
00:01 Whiteknight hey, take your time
00:02 Whiteknight I probably won't do any looking tonight, my wife is being all like "you need to pay attention to me eventually" and shit
00:02 Whiteknight :)
00:02 Infinoid if I could find a place to steal more time in the day, I would :)
00:02 Whiteknight tell me about it
00:02 purl it is in the universe repo which is not enabled by default
00:02 Infinoid forget it
00:02 purl Infinoid: I forgot it
00:02 Whiteknight I tried to do hacking at night instead of sleeping, but that ended badly
00:03 Infinoid I hack best in the early morning
00:03 japhb Whiteknight: I feel your pain
00:03 Infinoid 06:00-09:00
00:03 Infinoid those are my best hours
00:03 Infinoid after that I start getting distracted by shiny things
00:04 Whiteknight i'm probably about the same
00:08 japhb Server problem found and fixed.  udev for the lose.
00:08 Infinoid I has a nachos!
00:08 Infinoid time for debugging.
00:08 Infinoid Whiteknight: pay my respects to Mrs. Whitworth :)
00:09 Whiteknight thanks!
00:11 ilia_ joined #parrot
00:15 japhb Austin_Hastings: OK, bak.  Let me know if you need any info from me.
00:26 Austin_Hastings japhb: Tene put his "new API" in a nopaste, which has since expired. I'll dig it out of the Rakudo source.
00:27 eternaleye joined #parrot
00:28 japhb Austin_Hastings: Also see runtime/parrot/languages/parrot/parrot.pir
00:29 Austin Save some inches...
00:31 Austin That's more like it. Thanks again, japhb
00:32 japhb OK, afk for dinner.  bbl.
00:37 eternaleye joined #parrot
00:54 Sark joined #parrot
01:03 kurahaupo joined #parrot
01:13 amuck joined #parrot
01:16 Coke purl, \msg is also "msg <user> <msg>"
01:16 purl okay, Coke.
01:16 Coke msg?
01:16 purl i guess msg is Monosodium Glutamate, accelerates cooking of chinese food or a flavor enhancer, to make shitty stuff taste better, increase thirst, and desire to eat more.  the perfect food additive :> or Madison Square Garden or in *everything* or "msg <user> <msg>"
01:19 Coke msg NotFound (tt #785) - my failure is on feather. You can probably duplicate it there.
01:19 purl Message for notfound stored.
01:31 Austin left #parrot
01:35 cotto joined #parrot
01:40 dalek tracwiki: v21 | cotto++ | ParrotQuotes
01:40 dalek tracwiki: particle's a luminary
01:40 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=21&amp;action=diff
02:06 tetragon joined #parrot
02:07 Theory joined #parrot
02:32 Austin joined #parrot
02:33 Austin wikiwikiwiki
02:44 dalek tracwiki: v22 | Austin_Hastings++ | ParrotQuotes
02:44 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=22&amp;action=diff
02:48 chromatic joined #parrot
02:48 dalek tracwiki: v12 | Austin_Hastings++ | Parrot%20Virtual%20Machine%20Workshop%202009
02:48 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Parrot%20Virtual%20Machine%20Worksho​p%202009?version=12&amp;action=diff
03:00 cotto joined #parrot
03:01 Austin howdy cotto
03:01 skids .oO(Either Austin purposefully chose the shot where his face is blocked, or photographer too fascinated by camera)
03:01 Austin I think that was the photog saying "this (cotto's) camera is portrait, not landscape - everyone scrunch in"
03:02 cotto Hi Austin.
03:02 Austin Or maybe I have that backwards. I know there were two cameras involved...
03:02 cotto Yup.  The picture from pmichaud's camera should be better.
03:03 Austin (Or maybe I'm like the neighbor on Home Improvement, and no-one will ever see my face on camera...)
03:03 Austin Wilson?
03:03 purl Wilson is 2
03:03 cotto Austin; ?
03:03 Austin ... ?
03:03 purl Yada yada yada hasn't been implemented yet! (unless you run bleadperl)
03:03 skids I forget his name, but do remember the character.
03:04 Austin So what's new at yapc?
03:04 cotto we had the dinner tonight at the Steelers' stadium and got a nice tour
03:05 Austin Wow. That is nice.
03:05 Austin Get any cheerleaders?
03:05 cotto chromatic's talk on Modern Perl was very well attended
03:05 cotto nope
03:05 cotto I'm sure you'll be glad not to have missed that.
03:05 Austin Should have let RBlackwe organize it.
03:05 Austin He would have got you cheerleaders, I'm sure.
03:06 cotto I think he did
03:07 Austin Get 'em doing the CMU cheer: "e to the x, dy/dx, e to the y, dy! Secant, tangent, cosine, sine, 3.14159..."
03:08 Austin Changing the subject slightly, what's the worst possible thing that could happen (in code) to parrot?
03:09 Austin Specifically, describe the severity of the worst possible bug
03:10 skids runtime, or design-wise?
03:10 japhb IO opens root instead of desired file?
03:10 japhb socket sends naked pics from office party instead of apology to spouse?
03:11 japhb I tease, but your question was extremely open ended.  :-)
03:11 skids Arbitrary bytecode can be loaded from a malformed packet on a network socket?
03:11 Austin Background: If you go to https://trac.parrot.org/parrot/wiki/Yapc10Bof and look at the "How Can We Do Better" section, one of the action items is to define/specify what the severity levels are.
03:12 Austin cotto++ for getting those snapshots uploaded like 5 minutes after the meeting
03:12 skids Oh, then I have plenty.
03:12 skids 1) multiple developers take design in circles, subsystems never converge to satisfy all needs
03:13 Austin I'm thinking that the worst possible thing is "right now, in production, on multiple or all core languages, nobody can work."
03:13 Austin That would be something like a y2k problem or a virus vulnerability or some such.
03:14 japhb bigger even than that would be active data corruption, I would think.
03:14 chromatic That's the big one.
03:14 japhb though perhaps just make both of those max
03:15 Austin Hmm. I was considering "corrupts data" => "noone can work", but okay.
03:15 Austin And there's a bunch of those, and they all are essentially "Galactic Ultimate"
03:16 Austin So how far do we back down that chain for "worst" (or "highest") severity? What's the cut-off?
03:16 japhb Austin -- Linux filesystem history shows many cases of people thinking they could work while silently corrupting their data
03:16 Austin japhb Sure, but they weren't reporting the bug. I bet when they realized what was going on, they stopped working :)
03:16 japhb heh
03:17 skids One cut off point is "you can't just revert svn to fix it"
03:18 skids Another is "you have to revert a whole lot of svn to fix it and reapply is going to frustrate everyone"
03:18 Austin Okay. Persistent data is corrupted.
03:18 skids Or, as you were saying, it's a bug that's been there all along but the right external factors were not there to provoke it.
03:19 japhb unicode, anyone?
03:19 Austin chromatic: I transcribed cotto's pics of the BOF results, and then injected a bunch of "here's what *I* thought was going on" on the wiki (https://trac.parrot.org/parrot/wiki/Yapc10Bof). Please invite someone with more clues than me to check that, and maybe tell the true story.
03:19 Austin japhb: Everyone wants it.
03:19 skids Massive popular standard emerges that absolutely must be supported, and is completely antithetical to bas architecture.
03:20 Austin lol
03:20 Austin That's just a major rev...
03:20 Austin SMOP
03:20 Austin :)
03:22 Austin So what's a short word for "this problem goes outside parrot to affect a bunch of business-critical data or systems"?
03:22 jdv79 there was a BOF?
03:22 chromatic critical?
03:22 purl somebody said critical was good, over picky isnt... this should be a 'qcuik read up' for beginners.. i'll link to real tutorials, perldoc, etc later
03:23 Austin I think that might be too short a word, or the wrong one.
03:23 chromatic Hm, I didn't think the RCA was incomplete, even if I was hungry.
03:23 Austin Here's me not knowing Trac well enough, but can we get on-screen help to explain what the "rules" are?
03:24 skids You mean other than "something like the weak Debian SSH keys"?
03:25 Austin chromatic: I kind of had the impression that some of the other high-vote issues didn't get explored - that we focused the why/how to fix session on the "missed ... milestones" issue.
03:25 chromatic I had in mind a normal retrospective.  We pick the highest priority issue, perform RCA on that, come up with some experiments to try to improve it, and call that good.
03:26 chromatic I'm not sure we can keep enough other experiments going to fix other problems.
03:26 chromatic I also think that fixing this problem will improve many of the others.
03:26 Austin Okay. That's just my expectations being different, then.
03:27 Austin I agree that the fix list will address a lot of the issues, and I know that Patrick deliberately addressed a bunch of the others, too.
03:27 chromatic You've never seen me wear my "THIS IS PROJECT MANAGEMENT I KNOW THIS" hat before.
03:28 chromatic Then again, no one here's seen my "I CAN HAZ SHIRT WITH BUTTONZ" before.
03:28 * skids thinks greatest longterm design threat is continued procrastination on concurrency and realtime issues.
03:29 skids Not that there aren't blockers to getting very far on that.
03:29 Austin laugh
03:30 Austin Why is concurrency a threat, skids?
03:30 dalek tracwiki: v6 | Austin_Hastings++ | Yapc10Bof
03:30 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Yapc10Bof?version=6&amp;action=diff
03:30 Austin chromatic: reworded
03:30 skids Because nobody codes with it in mind.
03:30 s1n_yapc joined #parrot
03:30 skids It may become an insurmountable task.  Should be worked on before the codebase gets huge.
03:31 japhb "before"?
03:31 Austin :->
03:31 japhb I think it's already pretty damn large
03:31 japhb Hell, the *docs* are a maze of twisty passages, all different.
03:32 japhb The fact that it is taking months to refactor calling conventions makes me quite worried about doing anything even deeper than that.
03:33 skids Despite my worries over L1, I was hoping maybe it could be a starting point for that -- give each op a contract for interruptibility and at least realtime hints, if not constraints.
03:34 Andy joined #parrot
03:34 Austin skids: How hard are you hoping this will get?
03:34 Austin (realtime, I mean)
03:34 skids Latency 2-3 orders of magnitude worse than machine IRQ.
03:35 skids (not timetick, IRQ)
03:35 Austin Yikes
03:35 japhb Way back in the dark ages, there was a design intent that ops be simple and fast, and that a lot of the per-op guaranteed overhead from the P5VM become, at worst, additional ops -- except that we could schedule them when we wanted, rather than doing them every op whether needed or not.  Did that go the way of the dodo?
03:35 cotto Austin, the only way they'd get uploaded was if I did it right away.
03:35 Austin cotto :)
03:35 Austin you still rock
03:36 Austin japhb: I confess to knowing nothing of p5 internals
03:36 Austin Can you elaborate a little?
03:36 japhb Austin: the simplest way to put it is "P5 ops are heavy"
03:37 skids Though I guess machine IRQs are probably an order of magnitude faster than last I checked :-)  So let's say, green threads schedule at least a few times per slice.
03:37 japhb They're interpreter ops, with a lot of internal "brains" ... not bytecode ops in the traditional sense that do very little, and can be compiled to a handful of machine instructions by a JIT.
03:37 skids (assuming a modern HZ, not like 100 of days past)
03:37 japhb 'add' in the P5 VM is pages of code.
03:39 japhb Years ago, part of the argument for Parrot having a bazillion ops is that they were all *tiny*.
03:39 Austin So a parrot op is generally much lighter than a p5 op already, with some suspicious exceptions like maybe mmd?
03:39 japhb Austin: yes ... but my understanding is that the intent was them to be even lighter than they are right now.
03:40 japhb (And, BTW, I mean "semantically lighter" -- I'm not talking about actual current implementation efficiency, because P5 is the winner there.)
03:40 japhb afk for a bit
03:41 Austin skids: In my head I'm thinking IRQ = about 1000 ops, which would make your "2 or 3 OOM worse" be O(1_000_000) machine ops, right?
03:41 skids Ops could be lighter if they were coroutineish -- either they get called multiple times until they say "enough I'm done" or they can pass state to the next op, e.g. so a setup op is followed by interchangeble middle section followed by a cleanup.
03:42 Austin Aside from interruptability, what benefit does that offer?
03:42 skids Let's put it this way: fast enough you could run a TCP stack on it without relying on the OS, and get decent throughput.
03:43 skids It makes the contract with the VM include things like register utilization, so JIT knows when it has what available.
03:45 Austin Is the JIT even profitable?
03:46 skids Well, I have my doubts, personally, but it's one of Whitenights reasons for wanting L1, and he certainly knows more of JIT tham me.
03:47 Austin As far as I can see, most of the pir I've seen is relatively light on I & N registers, and heavy on P & S registers. How much profit will the JIT give us when such a huge proportion of the ops are going to have to do "call function pointer indirect" immediately?
03:48 skids Good question.
03:48 purl Yeah, it is. I'm stumped.
03:50 skids But then most of the call overhead is in rearranging parms, I am to understand.
03:50 Austin Well, Java would be worse, and they get something out of JIT. So it must work.
03:50 * skids wonders how much of a lexpad 16 SSE4 registers would fit.
03:51 skids I'm sure it works, the question is, does it rob more speed in unnecessary copies and such due to the abstractions it imposes.
03:51 Austin Well, at the C level if you're calling, you're saving and restoring CPU registers.
03:52 Austin Which is why I wonder what JIT does...
03:52 japhb skids: That depends on whether it's a traditional JIT or tracing JIT, I believe.
03:52 Austin Maybe they put all the common ops into a big switch stmt.
03:52 cotto L1 has all kinds of benefits beside jit.  Even if we assume the worst about jitting and only ever generate C from L1, it's still a significant win.
03:52 japhb Parrot had a traditional JIT design, before tracing became in vogue
03:52 japhb sigh, afk again
03:53 Austin japhb: You're not here for the hunting, are you?
03:53 cotto but perhaps I was reading too much "L1" into "jit"
03:53 jdv79 there's a switch runcore iirc
03:53 cotto jdv79, yes
03:54 Austin cotto: What other benefits do you see from L1?
03:55 cotto there won't be a border between C and PIR that we'll get a speed penalty from crossing
03:55 cotto we can do better analysis and optimization of L1
03:55 Austin I keep hearing that, and I keep not understanding what it means. What is this C/PIR boundary everyone is on about? PIR is written in C, how can there be a boundary?
03:56 skids I'm really up past bedtime.  Parting thought Re: "How can we do better?"  Leadership is showing people where to go.  Generally that involves giving them a map.  Ergo documentation is an intrinsic of leadership.
03:56 cotto There's no penalty when calling a simple function, but there's a big one when switching between PIR calling conventions and C calling conventions
03:56 jdv79 Austin: its beer time
03:56 Austin jdv79: For you, maybe. Are you at YAPC?
03:56 skids (For one, I'd really like to understand lexpads/stack more, but the code doesn't congeal for me.)
03:56 cotto since C and PIR do argument passing completely differently
03:56 jdv79 i am justin - the one that sat to your right at hofbrau
03:57 jdv79 so, yes, i am probably mostly here
03:57 Austin jdv79: Aha! A clue! You realize I won't remember your name for more than 30 seconds. (I remember you as being very helpful, though, in that regard.)
03:58 skids Austin: BTW, yours was the best whack at S17 I read, despite it being years old.
03:58 jdv79 i try - I am off to find beer:)  later.
03:58 Austin skids: thanks. I think that's the first actual response I've ever gotten
03:58 Austin jdv79: Good hunting.
03:58 skids Like I said, a topic everyone likes to avoid.
03:59 skids Anyway, sleep time.
03:59 Austin niterz
03:59 Austin cotto: What are we doing on the other side of C?
03:59 cotto converting to varargs, iirc
04:00 Austin I mean, given the multiplicity of opcodes (set_int_register_from_unicode_string_on​_odd_tuesday_in_non_leapyear_parity_8n1)
04:00 cotto care to elaborate?
04:01 Austin I can't. I don't know why we cross the C/PIR boundary.
04:01 Austin You're not talking about just going inside an opcode or vtable function, right?
04:01 cotto We have some functions in C that need to deal with PIR calling conventions.  That's expensive.
04:02 s1n_yapc joined #parrot
04:02 cotto I don't know about VTABLE functions.  My intuition says they shouldn't be expensive, but istr reading something that contradicts that.
04:02 Austin Can you name one? I'll got read the code and stop pestering you about it :)
04:02 Austin s/got read/go read/
04:02 cotto Sure.  Any METHOD in a PMC counts.
04:03 cotto also note what pmc2c does to those functions (and MULTIs)
04:04 Austin So filehandle::open would be a valid example?
04:05 cotto yes, and that's why whiteknight doesn't like doing IO through methods (afaiui)
04:06 magnachef joined #parrot
04:06 Austin Okay, is the problem inside or outside the function?
04:06 cotto outside; it's in all the stuff that pmc2c has to add
04:07 Austin Back up.
04:08 Austin Should I be looking in the "Parrot_FileHandle_nci_open()" function defined in filehandle.c, or should I be looking at whatever calls that function?
04:09 cotto Austin, Parrot_FileHandle_nci_open, especially compared to what's in the METHOD in the .pmc file
04:09 Austin Okay. Looking now.
04:11 cotto brace yourself
04:11 tetragon joined #parrot
04:12 brbrooks joined #parrot
04:14 cotto btw, chromatic++ for leading that meeting.  He did a good job of drawing out what needs to happen.
04:29 dalek tracwiki: v23 | Util++ | ParrotQuotes
04:29 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=23&amp;action=diff
04:31 cotto Util++ #I was just going to do that.
04:32 Austin Why does the method have to create a return continuation pmc?
04:32 Austin Shouldn't that be passed in from the interp?
04:33 Util :)
04:33 cotto If I could answer that, I'd probably be fixing pcc_rewiring.
04:35 Austin :)
04:35 cotto Hmmm. Whiteknight hasn't put up his writeup from the L1 discussion today.
04:37 Austin Okay, the PARMS SCOPE section looks fine - do some pointer-foo to get the params in local vars.
04:37 cotto I hate "50% faster".  What's so hard about saying something like "twice as fast" or "a 50% decrease in running time"?
04:37 magnachef joined #parrot
04:39 Austin There's some function calls that I don't grok, and it seems like things are inside out. And there's a bunch of stuff that seems like it should be static, instead of created with each call. (Maybe not a problem for FileHandle::open, but probably a win for add-two-integers, etc.)
04:41 Austin What's the L1 proposal for this?
04:43 Austin 50% faster means 1.5x speed, not 2x speed. And so would mean 33% decrease in run time.
04:44 cotto Austin, you're right.  That's why I hate that phrasing.
04:44 Austin :)
04:45 Austin Do you know what L1 proposes to do about the calling thing? I see some inefficiency, but it looks like the run-loop and pmc2c should be able to fix it.
04:55 cotto First, calling conventions will be massively simplified once pcc_rewiring gets merged (or something equivalent).
04:56 cotto Second, afaiui the calling conventions will be implemented in L1, meaning that you can use L1 to call C functions directly.
04:57 cotto My understanding starts to fade at this point.
04:57 Austin laugh
04:57 cotto s/once/after/
04:58 Austin Changing the subject completely: If you get a chance, take a look at the wiki page with the photos (if you haven't already) because I took your name in vain at least once. Make sure I'm honest, please.
05:02 cotto Austin++ for writing up your comments.
05:03 Austin <bow>
05:04 cotto I don't think your name should be on them (since it could discourage others from editing and adding), but that's an excellent start.
05:04 cotto karma austin_hastings
05:04 purl austin_hastings has karma of 11
05:04 cotto karma austin
05:04 purl austin has karma of 4
05:06 Austin I put my name on it to separate "Austin's editorial comments" from "stuff we actually agree about". I'm hoping someone(s) will take some of the action items onto separate pages or tickets or something, and then they (or I, if they don't want to) can delete my comments.
05:06 Austin But maybe I should just make them tickets...
05:08 cotto We didn't set up a process to make sure that the meeting items got followed up on, so it could easily not happen if none of us do it spontaneously.
05:08 cotto iirc
05:08 Austin combust!
05:08 purl combust is the web framework / content management system for geeks that we use at perl.org. See http://combust.develooper.com
05:08 Austin Maybe I'll pick that up tomorrow, then. I think I'm going to go to bed.
05:09 cotto It's very close to that time for me too.
05:09 Austin Good night, then.
05:09 cotto I just want to scribble down the major points from the L1 discussion, then I'm down too.
05:09 cotto night, Austin.
05:09 Austin left #parrot
06:09 uniejo joined #parrot
06:23 uniejo joined #parrot
06:23 Theory joined #parrot
06:37 iblechbot joined #parrot
07:07 japhb msg Austin "here for the hunting"?  If you're asking if I'm at YAPC, then no, sorry.  :-/
07:07 purl Message for austin stored.
07:19 whoppix joined #parrot
07:21 viklund joined #parrot
07:47 st joined #parrot
07:48 barney joined #parrot
07:56 eternaleye joined #parrot
08:17 ArjenL joined #parrot
09:15 JC1 left #parrot
09:25 patspam joined #parrot
09:28 donaldh joined #parrot
09:32 bacek joined #parrot
09:38 bacek o hai
09:54 Infinoid :)
10:11 guru joined #parrot
10:11 Infinoid msg Whiteknight Parrot_io_write_buffer is completely broken.  The crash in t/pmc/io_18.pasm is caused by it overrunning the buffer.  (at src/io/buffer.c:650, buffer_size is 8192, but buffer_next-buffer_start is 21054)
10:11 purl Message for whiteknight stored.
10:12 Infinoid msg Whiteknight For what it's worth, the line-buffering patch I tried yesterday was affected by the same brokenness.  I'll see if I can fix it
10:12 purl Message for whiteknight stored.
10:17 iblechbot joined #parrot
10:24 bacek *incoming*
10:26 dalek parrot: r39751 | bacek++ | branches/tt761_keys_revamp/src/pmc (2 files):
10:27 dalek parrot: [pmc] Hash.get_string_keyed* migrated to new style
10:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39751/
10:27 dalek parrot: r39752 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
10:27 dalek parrot: [pmc] Small fixes in Hash - don't blindly cast value to PMC*
10:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39752/
10:27 dalek parrot: r39753 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
10:27 dalek parrot: [pmc] Reshuffle Hash code to keep related things close.
10:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39753/
10:27 dalek parrot: r39754 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
10:27 dalek parrot: [pmc] Reshuffle Hash code more. No functional changes.
10:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39754/
10:27 dalek parrot: r39755 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
10:27 dalek parrot: [pmc] Hash.get_pmc_keyed* migrated to MULTIs.
10:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39755/
10:27 dalek parrot: r39756 | bacek++ | branches/tt761_keys_revamp/li​b/Parrot/Pmc2c/PMCEmitter.pm:
10:27 dalek parrot: [pmc2c] Provide PMC* return value in generated switch-optimised VTABLE for MULTIs instead of relying on arguments.
10:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39756/
10:27 dalek parrot: r39757 | bacek++ | branches/tt761_keys_revamp/src/pmc/namespace.pmc:
10:27 dalek parrot: [pmc] Sigh. Replace SUPER() with hand-crafted call to INTERP->vtables[...] again.
10:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39757/
10:29 * bacek crawl out under the table
10:32 Infinoid wow!
10:32 Infinoid (gdb) print buffer_size
10:32 Infinoid $6 = 8192
10:32 Infinoid (gdb) print avail
10:32 Infinoid $7 = 18446744073709538754
10:32 Infinoid small error there...
10:33 bacek welcome to 21st century! There is a LOT of space available!
10:36 Infinoid I don't think we support lazy buffer allocation yet :)
10:38 bacek :)
10:39 * bacek hit another roadblock on Hash refactoring...
10:39 bacek I can't declare "MULTI FLOATVAL foo()"... JIT doesn't support it.
10:53 Infinoid msg whiteknight t/pmc/io.t failures fixed in r39758.
10:53 purl Message for whiteknight stored.
10:54 dalek parrot: r39758 | Infinoid++ | branches/io_cleanups/src/io/buffer.c:
10:54 dalek parrot: [io] When done flushing the buffer, mark it as empty.  (I think this was a typo.)
10:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39758/
11:03 Infinoid I/O buffering is very poorly tested at the moment, there are other bugs lurking in this code
11:05 bacek s{I/O buffering}{Parrot}
11:05 Infinoid I think Parrot overall is fairly well tested... more so than most projects
11:06 bacek yeah. But it still can be better.
11:06 Infinoid That's always true, of every project, no matter how good they get :)
11:07 bacek "GNU Hello World" is perfect example :) They have version 2.68 or something already
11:08 Infinoid GNU Hello is also an example of how the GNU way is not always the best way :)
11:08 purl okay, Infinoid.
11:09 Infinoid time to get ready for the day, seeya!
11:21 donaldh joined #parrot
11:35 guru left #parrot
11:39 whoppix joined #parrot
11:42 st joined #parrot
11:43 burmas joined #parrot
11:44 mtk joined #parrot
11:46 mtk left #parrot
12:07 cotto joined #parrot
12:09 chromatic joined #parrot
12:09 chromatic 1610–20; < L pellūcidus, var. of perlūcidus. See per-, lucid
12:21 Whiteknight joined #parrot
12:21 Whiteknight hello friends
12:30 pmichaud hello
12:30 Patterner joined #parrot
12:34 masak joined #parrot
12:39 kid51 joined #parrot
12:43 skids joined #parrot
12:47 * Whiteknight has a lot of blogging and summarizing to do today
12:47 Whiteknight YAPC was quite the fun experience!
12:48 pmichaud Yes, I suspect I'll be catching up on yapc-related todo lists for weeks.  :-(
12:52 kid51 joined #parrot
12:57 iblechbot joined #parrot
13:05 gryphon joined #parrot
13:08 cosimo joined #parrot
13:10 s1n_yapc joined #parrot
14:13 magnachef joined #parrot
14:16 particle1 joined #parrot
14:23 Theory joined #parrot
14:24 s1n_yapc joined #parrot
14:25 dalek tracwiki: v72 | whiteknight++ | WikiStart
14:25 dalek tracwiki: create a page to hold info about L1 as discussed at YAPC
14:25 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=72&amp;action=diff
14:28 dalek tracwiki: v1 | whiteknight++ | L1Recap
14:28 dalek tracwiki: create page about L1 with info originally drafted on my blog
14:29 dalek tracwiki: https://trac.parrot.org/parrot/wiki​/L1Recap?version=1&amp;action=diff
14:32 dalek tracwiki: v2 | whiteknight++ | L1Recap
14:32 dalek tracwiki: removing stuff that was intended only for the blog post
14:32 dalek tracwiki: https://trac.parrot.org/parrot/wiki​/L1Recap?version=2&amp;action=diff
14:34 AndyA joined #parrot
14:45 chromatic joined #parrot
14:46 * Coke needs something help enforce coding standards for cold fusion.
14:48 cotto Whiteknight++ for the L1 recap
14:50 uniejo joined #parrot
14:51 chromatic Coke, a priest?
14:53 pmichaud I was thinking "baseball bat"
14:56 Whiteknight ColdFusion coding standard #1: you should actually be using PHP instead
14:56 kid51 joined #parrot
14:56 cotto Whiteknight, does atomicity apply to L1 opcodes?
14:56 Whiteknight :)
14:56 Whiteknight cotto: I believe so
14:57 chromatic Atomicity at the processor level?
14:57 cotto If they're made up of more than one machine instruction (which I assume in the common case), it's perfectly possible that an L1 instruction could be interrupted.
14:57 cotto chromatic, that's what I was thinking.
14:58 chromatic Depends on the processor.
14:59 chromatic I don't think we can guarantee automicity of every L1 op right now.
14:59 Whiteknight an L1 instruction could be interrupted by a C-level callback. But the C-level callback will register a PIR-level callback in the scheduler, which treats L1 ops as atomic
14:59 Whiteknight so from the high-level view, L1 appears atomic for all components in Parrot
14:59 chromatic The kernel could interrupt an L1 op though.
15:00 Coke Whiteknight: coldfusion > php, IME.
15:00 Whiteknight Coke: that's fine too
15:01 Whiteknight chromatic: yes, that's true, but another L1 stream will not interrupt an L1 op
15:01 Coke chromatic: I see talk about L1 bytecode. Are we going to have LBC and PBC ??
15:01 Coke (seems like we should not be multiplying bytecode types.)
15:02 Whiteknight Coke: yes and no. PBC can be thought of as a macro layer around LBC for compactness
15:05 NotFound Coke: I just read your message. How can I access feather?
15:05 Coke ask juerd.
15:05 Coke juerd?
15:05 purl hmmm... juerd is root or at http://juerd.nl/ or mailto:juerd@juerd.nl
15:06 Coke NotFound: I am running against my own copy of an installed parrot, and there's a installed version in the common area that I'm not using.
15:06 Coke I suspect if you're not duplicating the error, the other-installed copy might be the problem
15:07 NotFound I installed in a non privileged directory, without any other installation.
15:07 Whiteknight which test target do we use to test file-level and funciton-level documentation?
15:07 Whiteknight is that codetests?
15:07 Coke NotFound: so it's probably the other-installed version conflicting.
15:07 Coke (at a guess)
15:08 NotFound I'll check that locally in one of my machines first, then.
15:09 dalek tracwiki: v3 | cotto++ | L1Recap
15:09 dalek tracwiki: basic copyediting and clarity changes
15:09 dalek tracwiki: https://trac.parrot.org/parrot/wiki​/L1Recap?version=3&amp;action=diff
15:10 Whiteknight copyediting++
15:10 jdv79 isn't the stack getting a bit large?  from HLL to the hw i mean.  it seems as if optimzations may get more difficult the deeper the stack gets, no?
15:11 Whiteknight jdv79: it's counterintuitive. The more layers of abstraction we have, the more opportunities we have for major algorithmic optimizations in each
15:11 chromatic Easier actually.  The better the abstractions, the easier to optimize them.
15:12 moritz but we should not forget that we also have to actually *do* them :-)
15:12 moritz having possibilities for optimization isn't enough in itself
15:13 Whiteknight True. Very true
15:13 Whiteknight but we don't even have the potential right now
15:13 moritz right
15:13 chromatic STOP SAYING WHAT I'M THINKING... oh well, go ahead
15:13 cotto Simply going through a single layer instead of a PIR/C mutt is an optimization itself.
15:13 * Whiteknight is tuned in to chromatic's wavelength
15:14 chromatic Tell me then, what flavor pie?
15:14 cotto btw chromatic, I've got a map I'd like you to draw me a picture of.
15:14 chromatic It looks like Florida.  Creepy.
15:15 cotto particle1, where are you?
15:15 ilia joined #parrot
15:16 * cotto goes off to search
15:18 pmichaud anyone seen particle?
15:18 ilia joined #parrot
15:19 pmichaud nm, found him.
15:19 chromatic How fast is he going?
15:20 pmichaud I have no idea.
15:20 Coke wave to him for me.
15:20 chromatic That's him then.
15:20 donaldh joined #parrot
15:23 eternaleye joined #parrot
15:23 Tene tene?
15:23 purl you are, like, Stephen Weeks or a madman
15:23 Tene purl: tene is also http://blogs.gurulabs.com/stephen/
15:23 purl okay, Tene.
15:25 ilia_ joined #parrot
15:30 cotto seen darbelo
15:30 purl darbelo was last seen on purl 17 hours, 41 minutes and 43 seconds ago, saying: <private message>
15:31 cotto apparently he's right here and he's sitting still.  I'm going to write a paper about it.
15:31 cotto (particle)
15:32 pmichaud barbie's talk is running longer than listed, so I'll be a bit longer than originally expected
15:34 Whiteknight chromatic: blackberry pie
15:36 Coke I would have picked Shephard's. ah well.
15:37 dalek TT #786 created by jkeenan++: io_cleanups branch:  config step auto::gettext throws warnings on ...
15:38 Whiteknight kid51++
15:38 Whiteknight karma kid51
15:38 purl kid51 has karma of 77
15:39 Whiteknight well that's bullshit, he has like several thousand commits
15:39 Whiteknight karma jkeenan
15:39 purl jkeenan has karma of 2229
15:39 Whiteknight that's better
15:39 Whiteknight jkeenan++
15:40 chromatic joined #parrot
15:45 japhb Tene: obNVidiaPing
15:57 fish joined #parrot
15:57 fish hi :)
15:58 fish moritz told me, here is someone who is attending the fusion festival. i'm attending too. so if anyone like to meet, i'm there ;)
15:58 dalek TT #787 created by japhb++: add vtables for: get_pmc_keyed{_int,_str,}_lvalue ; and similarly for ...
16:22 Themeruta joined #parrot
16:24 ascent joined #parrot
16:27 NotFound joined #parrot
16:32 kid51 joined #parrot
16:35 cotto joined #parrot
16:47 Psyche^ joined #parrot
16:54 cognominal joined #parrot
16:57 chromatic joined #parrot
17:01 Whiteknight allison: ping
17:01 dalek TT #788 created by jkeenan++: Audit PDD30 compliance
17:02 magnachef joined #parrot
17:15 chongax joined #parrot
17:26 jhorwitz joined #parrot
17:51 jjore joined #parrot
17:59 bacek joined #parrot
18:07 allison Whiteknight: pong
18:07 Whiteknight hey allison, how are you doing?
18:08 Whiteknight did you see that email I sent to the list about the io_cleanups branch? I would really like to get a thumbs up/down from you about my approach there to see if I should waste any more time on it
18:10 allison Whiteknight: didn't see the message yet, will take a look now
18:10 bobke joined #parrot
18:10 bobke joined #parrot
18:10 skids .oO(Renaming Hash to AssociativePMCArray?  Why not AssocativePMC array, then they can both be misspelled
18:17 soxet joined #parrot
18:17 Coke Whiteknight: my concern is why did you make Handle a PMC?
18:18 Coke if it's abstract, and no one inherits from it...
18:18 Whiteknight Coke: Because all ATTRs of FileHandle need to be P/I/S/N in order for FileHandle to be inheritable
18:18 Coke seems like it's better modeled as a library, or as private-to-parrot c methods.
18:18 Whiteknight and it's persistent information that we want to keep for each instance of FileHandle
18:18 Coke but if Handle only being used a collection of methods, why does it need to be an attribute?
18:19 Coke so a Handle is not just a collection of method?
18:19 Coke "s"
18:19 Whiteknight it isn't a collection of methods, it's a collection of data
18:19 Coke ok.
18:19 Whiteknight it actually has no methods and only a small handful of vtables (although I want to add a few vtables for ease)
18:21 Whiteknight by separating it out this way, we can finally subclass FileHandle properly from PIR
18:21 Whiteknight or, we're much closer to that goal
18:23 darbelo joined #parrot
18:23 Coke Is there a ticket open for not being able to sublass something witha a non-register attribut?
18:23 Coke "e"
18:24 Whiteknight Coke: a handful of tickets reported have that as a root cause, yes
18:24 Whiteknight but no one ticket for this root issue
18:26 JC1 joined #parrot
18:29 japhb joined #parrot
18:31 allison Coke: well, that was by design
18:32 allison Coke: on the theory that C attributes aren't particularly useful from PIR (where everything is a register)
18:34 allison Coke: it would be possible to inherit C structs etc, using a various proxy PMCs (like UnmanagedStruct, etc)
18:35 allison Coke: not entirely sure it's a good idea...
18:36 cghene joined #parrot
18:36 Whiteknight allison: the implementation in the branch is obviously very messy right now, should I spend the time to clean it up or not?
18:37 cghene joined #parrot
18:38 reezer bacek: are you there?
18:38 purl yes!
18:39 allison Whiteknight: how's the speed?
18:39 allison Whiteknight: we made the move to make FileHandle *not* subclassable, because making it subclassable made it really slow
18:40 Whiteknight as the implementation stands a little slower then trunk, but I'm not currently caching the Handle PMC between accesses.
18:40 allison ouch
18:40 allison (because trunk is already too slow)
18:40 Whiteknight Once I finish cleaning, I don' think there will be any performance penalty though
18:41 allison it needs to be faster, not equal
18:41 allison Whiteknight: do you have a specific range of revisions you want me to review, or all revisions since the branch started?
18:42 Whiteknight the basics got put in place in just one revision, let me get it
18:42 allison 39741?
18:43 Whiteknight yep, that's the one
18:43 Whiteknight pretty big though, sorry about that. it was proof-of-concept
18:45 Whiteknight I think I can make it faster then trunk. Won't be dramatic but I think I can make it better
18:46 Whiteknight (I don't want to sell you more then I can deliver)
18:46 bacek reezer: no actually
18:47 * bacek trying to understand why he woke up at 5AM...
18:47 Coke allison: i would say that having un-subclassable PMCs is bad.
18:47 allison Whiteknight: side comment, don't check TODO into source code, that was an old bad habit we're still cleaning out of old code
18:48 Coke allison: I think that's fine in a branch.
18:48 Whiteknight allison: noted. Those notes are for the branch and will be definitely gone before it merges
18:48 Whiteknight I should probably use a wiki checklist instead though
18:49 Coke (non-subclassable) especially given all the places where subclassing fails already accidentally. (adding more on purpose)--
18:49 allison Coke: mmm... the theory was that we'd be moving everything over to use register types (that everything should be using register types), but in actual fact the main point of the C PMCs is to act as an interface to low-level C systems
18:49 pmichaud moving to register types seems.... unlikely.
18:49 allison Coke: so, I can consider that a theory proven unworkable
18:49 Coke allison: if we're going to have PMCs we can't subclass on purpose, i think we're going to have to introduce 'final', ala java.
18:50 Coke (using register types instead of PMC types for, say, HLL vars?)
18:50 allison Coke: it's not that they're unsubclassable, it's just that they're not subclassable from PIR
18:50 Whiteknight I agree with that, I've had a few instances of PMCs I wanted to be able to mark "not subclassable"
18:50 allison it's perfectly fine to subclass them from C
18:50 Coke ew.
18:51 allison well, it's the basic nature of our C/HLL divide
18:51 allison C is primitive, but we're using it to bootstrap a HLL virtual machine
18:51 allison this is why chromatic wants to eliminate C PMCs entirely
18:51 allison and write them all in some higher-level language
18:52 allison but, that solution also has problems, since there are times when it's really valuable (read fast and clean) to write PMCs in C
18:53 allison the PMC can encapsulate some low-level detail of the VM (like the interpreter, or an I/O handle) and hide the C details from the PIR user
18:55 allison I'm not really sure what the ultimate solution will be.
18:56 allison so far, it seems to be heading in the direction of making C PMCs act more like PIR PMCs
18:56 allison (that is, more toward chromatic's idea)
18:56 reezer bacek: am I allowed to query you? I would like to make a suggestion related to bug #758. You can read it later
18:56 moritz reezer: I'm sure he won't kill you for it, so go ahead ;-)
18:56 bacek reezer: of cause
18:57 bacek moritz: Austria and Australia are different countries! He is just too far away to kill him (at least in person :)
18:58 moritz ;-)
18:59 Whiteknight allison: So what's your initial verdict on io_cleanups, reasonable idea or not?
18:59 Whiteknight (assuming I can make it faster)
19:00 bacek doughera?
19:10 bacek .oO( Modulus of negative numbers is counter-intuitive)
19:12 bacek Small quiz:
19:12 bacek result of "-5 mod 3" will be:
19:12 bacek a) -2
19:12 bacek b) -1
19:12 bacek c) 1
19:13 moritz -2 in C, 1 in Perl
19:13 bacek d) This poll suck, no one should mod negative numbers
19:13 Coke 1 in tcl also.
19:14 bacek Why it's "1"?
19:14 moritz bacek: because $n mod $m is usally a function mapping to the range 0..($m-1)
19:15 moritz bacek: it's "wheen you add or substract $m sufficiently many times, what's the number you get in that range"
19:15 Coke modulous != remainder.
19:15 bacek moritz: what about "5 mod -3"?
19:15 Coke modulus.
19:15 purl Math is HARD!
19:16 bacek and "-5 mod -3"...
19:16 moritz bacek: that doesn't make sense to me.
19:16 bacek moritz: indeed...
19:16 purl indubitably
19:17 moritz well, you could interpret it as a mapping into the range -3..0
19:17 bacek but parrot's test suite expect "-1" and "-2"...
19:19 bacek moritz: looks like your assumptions are correct
19:19 allison Whiteknight: still reading through the diff
19:19 allison Whiteknight: (with some interruptions)
19:20 donaldh joined #parrot
19:24 moritz Infinoid: iirc you're the one to talk to about dalek... could please bring the commit mesages from http://github.com/hinrik/grok/ to #perl6?
19:24 cotto grok?
19:24 purl grok is an anagram of okrg, not okra
19:25 moritz cotto: documentation tool for Perl 6
19:25 cotto good naming
19:27 Coke grok is also a documentation tool for Perl 6
19:27 purl okay, Coke.
19:27 cotto how does it relate to u4x
19:27 cotto ?
19:28 moritz masak started the u4x project, and literal decided to call the command line tool "grok", or so
19:28 cotto ok.  so it's a component
19:29 moritz afaict, yes
19:29 masak it's the tool that delivers the docs on the CLI.
19:29 allison Whiteknight: I understand the reasoning behind the change, you're looking at handles from the OS perspective (particularly the linux perspective) where they're all integer descriptors
19:29 masak there might be other views as well, HTML/Web, Padre, etc.
19:29 allison Whiteknight: but this particular code rearrangement isn't buying us anything
19:30 allison Whiteknight: and it's costing us an extra PMC for every filehandle, expensive
19:30 allison Whiteknight: tweak your thinking around a bit, and you're nearly there
19:31 allison Whiteknight: FileHandle, Socket, and Pipe *are* the low-level PMCs, doing what your Handle PMC is doing
19:31 allison Whiteknight: and the way to subclass them from PIR is by delegation
19:34 Whiteknight allison: so subclassing these from PIR is a different process from subclassing any other PMC from PIR?
19:35 Whiteknight I don't think it's good to relegate certain PMC types to second-class status in terms of subclassability, especially when there is no check anywhere that using the subclass op on these types will fail in strange ways
19:36 allison you just did with Handle
19:36 allison it's okay to have some core types who's entire purpose is to act as an interface with low-level systems
19:36 Whiteknight But I specifically made it impossible to directly instantiate a Handle from PIR
19:36 Whiteknight you can't do that with FileHandle
19:37 allison by doing that, you made it impossible for anyone to subclass FileHandle from PIR
19:37 Whiteknight how's that?
19:37 allison since they couldn't directly instantiate the core delegate type from PIR
19:37 Whiteknight the system will allocate the Handle internally, and do it lazily
19:38 allison a subclass has to be able to override all behavior of the parent
19:38 Whiteknight (doesn't do that yet, that's one of the "cleanups" I mentioned)
19:38 allison if the subclass can't create the delegate Handle, it's no better off then not being able to create the low-level os_handle
19:39 Whiteknight that's a bit of an exaggeration, it is a little better off
19:39 Whiteknight certainly better then the behavior now with regards to subclasses of FileHandle
19:41 Whiteknight Okay, as an alternate idea, what if instead of delegating to a Handle type, we store the file descriptors in a table internal to the IO system, and store an INTVAL index into that table instead?
19:42 Whiteknight provides the kind of complete subclassability that I think we both want
19:43 Coke yay, global variables!
19:43 Coke ;=)
19:43 Whiteknight Coke: would be a pointer on the interpreter, so thread-local
19:45 Whiteknight we already have an IO-specific structure in there anyway, it would be trivial to add in a table of OS descriptors
19:46 Coke Whiteknight: I can live with interpreter-level, sure.
19:47 cotto does the idea of multiple threads per interpreter make sense?
19:48 cotto (sanity check, not suggestion)
19:48 Whiteknight cotto: no, each thread is it's own interpreter
19:49 cotto k
19:53 Whiteknight allison: The current semantics of FileHandle are bad (subclassing is allowed, but then subclassed objects can't do any file operations). I want to fix that.
19:53 Whiteknight I don't think disallowing subclassing on FileHandle is the right way forward, but I could be wrong about that
19:54 allison Whiteknight: the way to fix that is to fix PMC subclassing
19:55 Whiteknight okay, good. I would rather fix the root problem in one shot. How do we go about doing that?
19:56 Whiteknight (I ask with the full knowledge that there may not be a satisfactory solution anywhere)
19:56 allison Whiteknight: give PIR Classes the ability to create a delegate or proxy structure for ATTRs that aren't register types
19:57 Whiteknight like a delegate PMC type? or something lower then that?
19:57 allison though, it's messier than that, since the GET_ATTR/SET_ATTR macros also need to know how to interact with the unusual types
19:57 Whiteknight that shouldn't be so hard if the delegate type has a sane interface
19:57 allison the basic problem is, attributes in PIR Classes are stored in an array
19:58 allison That array can only have PMC elements
19:58 allison so, it knows how to box and unbox the basic register types
19:58 Whiteknight so do something like box C types into ManagedStruct or something similar?
19:58 allison it doesn't know how to box and unbox other arbitrary types
19:58 allison C struct types can be boxed as ManagedStruct, yes
19:59 Whiteknight we can teach anything how to handle anything, we just need to know the way to do the teaching.
19:59 allison yes
19:59 allison the magic is all in the GET_ATTR/SET_ATTR macros
19:59 Whiteknight I'm not daunted by the challenge, so long as there is a solid goal in mind
20:00 allison the best place to start is probably with a list of C types in the current C PMCs, and how they can be represented as a PMC
20:00 allison mostly it's structs (which we already have a correspondence for)
20:01 allison some are stranger
20:01 Whiteknight anything that's stranger we could easily (though naively) put into a struct and handle that way
20:01 Whiteknight so that's not a problem
20:02 allison Whiteknight: we don't want to create another C struct for every C PMC
20:02 Whiteknight I said it was naive
20:02 allison they already have a C struct, which we're translating to an array
20:03 allison dropping them into a one-element ManagedStruct is a possibility
20:04 Whiteknight or another Managed* PMC type to handle scalar values
20:04 allison something more like a CPointer may be preferable
20:05 allison A generic PMC, designed to hold a pointer to any arbitrary C type
20:05 Whiteknight okay, I'll put this on my queue for now. I'll back out the Handle stuff from io_cleanups and continue working around that for now, and we can plan this idea out on the wiki. Good?
20:05 allison (with appropriate behavior for boxing and unboxing that value, depending on its type)
20:05 allison sounds good
20:05 Whiteknight Thanks. allison++
20:06 allison The Handle stuff was on the right track, BTW, in the sense of abstracting a C type into a PMC.
20:07 Whiteknight yeah, I figured it couldn't be entirely wrong
20:07 Whiteknight :)
20:07 cotto allison, have you looked at L1Recap on the wiki?
20:12 * Whiteknight is heading home now. Goodbye
20:12 allison cotto: not yet
20:23 gryphon joined #parrot
20:29 chromatic joined #parrot
20:43 cotto joined #parrot
20:56 amuck_ joined #parrot
20:57 whoppix joined #parrot
21:13 Tene allison: available to chat about pynie?
21:14 HG` joined #parrot
21:14 allison Tene: sure
21:15 Tene allison: I've been wanting to work on getting clases functional in Pynie.  Any guidance you want to offer, or can I just do whatever I want and ask forgiveness?
21:16 allison Tene: are there any particular obstacles to getting classes to work?
21:16 Tene Right now, the class bodies aren't even making it into the AST.  I have an implementation of that working pretty well, and I made it use P6object... I figure that will be subclassed.
21:17 Tene The major obstacle is class instantiation.  To do it the right way, I'd need to be able to set :vtable('invoke') on a method
21:17 allison Tene: it seems to me that getting them to even partially work is better than what it has now, and we can always refine later
21:17 Tene but that's broken at least until after PCT refactors.
21:17 allison Tene: oooh, I see, yes that's the one thing that could be problematic
21:17 Tene I got it working when I faked it.
21:17 allison (using anything from Perl 6)
21:18 Tene P6object isn't Perl 6.
21:18 allison P6object seems like overkill for Pynie's needs
21:18 Tene eh, could be.  I'm not so sure.
21:18 allison Tene: yes, and I've talked to patrick about changing the name
21:18 allison Tene: but using anything with P6 in the name is problematic
21:18 Tene Will it still be problematic if I subclass it first to give a different name?
21:19 allison a more likely solution, is a trimmed-down version of it for Python
21:19 allison strip out all the extra Perl6-ish stuff
21:19 Tene Sure, okay.
21:20 Tene I'll investigate that.
21:20 allison basically, a PyObject
21:20 cotto Just rename it to PythonObjectThatHasNothingToDoWithPerl6
21:20 allison in fact, you could likely do fine just emulating PyObject
21:20 cotto with a boolean attribute called "comes_from_perl6" that's always false
21:20 Tene eh?  explain "emulating PyObject"
21:21 allison on the whole, the data types for Parrot implementations of existing languages should mirror the types of the existing languages as much as possible
21:21 allison PyObject is C Python
21:21 Tene Ah.
21:21 allison http://docs.python.org/c-api/structures.html
21:22 Tene (see... I don't know python very much. :)
21:22 allison that's okay, deep knowledge of Python isn't needed, just treat it like a spec
21:22 cotto pmichaud, ping
21:25 Tene allison: but it's definitely not okay for me to commit anything referring to P6object.
21:26 Whiteknight joined #parrot
21:26 allison hmmmm... I guess it depends on if it's a "temporary, will remove in a month" solution or a "permanent" solution
21:27 allison Tene: but it's at least not worth pouring a pile of work into a P6object based solution
21:27 Tene Okay, I understand.
21:27 allison Tene: if you have one already implemented, it would seem like a waste to throw it away
21:28 Tene Speaking of :vtable('invoke'), I hear that's blocking on pcc refactors... What's the story on that branch?
21:28 allison held until after 1.4
21:28 allison too risky for a "supported" release
21:28 allison it's mainly in the phase of "fix build and test failures"
21:29 Tene last I checked, trunk wouldn't merge cleanly into the branch.
21:29 allison no, it shouldn't
21:30 Tene Shouldn't?
21:30 allison (I hope no one tried to commit a merge)
21:30 allison no, I'll extract a diff and apply it to a clean branch
21:30 Tene Nobody tried to commit a merge.
21:30 Tene TWhile I've been watching, at least.
21:31 allison patrick's branching strategy is cleanest here
21:31 moritz with git-svn you can experiment with branches without ever pushing anything to the server
21:31 allison moritz: you can with svn too, just don't commit it
21:33 Whiteknight irclogs?
21:33 purl irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
21:38 japhb allison: (local svn branch == don't commit)  That's ... suboptimal.
21:39 Tene We're not on a sub.
21:40 allison japhb: actually, I prefer it. Untangling the "locally committed" from "locally not committed" from "remotely committed" is an absolute nightmare in git
21:40 allison japhb: in svn it's dead easy to revert, or throw away a branch
21:41 japhb allison: I'm not sure I follow -- In git, you can branch freely, commit to whichever, and deleting branches is trivial.  If that's not enough, you can make multiple local clones, and branch each of them trivially.
21:41 allison japhb: but then, that's one of those open source holy wars, so best to call it a personal preference
21:41 * japhb shrugs.
21:42 Tene allison++
21:42 japhb It's not the SVN v. Git thing that I was commenting about, it's the not ever committing a branch, just to keep it away from remote repo.
21:42 ilia joined #parrot
21:43 allison japhb: oh, agreed, long-lived changes should be committed somewhere
21:43 dalek TT #789 created by whiteknight++: Make All PMCs Subclassable
21:43 allison japhb: but moritz was talking about experimenting with merges, so a shortlived change
21:43 Tene I have trouble keeping track of which of my strong opinions are appriopriate to share, so I just try to keep all of them to myself.
21:43 japhb ah, I get it.
21:44 japhb Tene: How about having a strong opinion about OpenGL?  ;-)
21:44 * japhb pushing while he still can spare tuits ....
21:44 Tene japhb: oh, sure.
21:44 Tene lemme go back to nvidia proprietary...
21:45 Tene and then you want me to rebuild Parrot?
21:45 japhb And don't forget to add those two extra packages ... the -libs and -devel packages for the nvidia proprietary drivers.
21:45 Tene Yes, installed.
21:45 purl installed is, like, easy as well
21:45 japhb Ah, great,
21:45 japhb yes, so after the switchback, do a realclean/configure/make
21:54 Tene japhb: rebuilding
21:57 Tene japhb: exactly the same failure as before
21:58 * japhb goes mentally Turrett's for a minute
21:58 japhb Dang it, I thought that was the key
21:59 japhb ... I wonder if those libs aren't being picked up properly.  (linked in wrong order, or something)
21:59 Tene I can give you ssh on my box if you like
22:00 moritz opengl over ssh? teh horror :)
22:01 japhb moritz: It can be done!
22:01 Tene I was more thinking just to check out linking order... ;)
22:02 japhb (I have, actually ... because the machine I was sitting on didn't have the app, but it *did* have a much faster video card than the machine running the app, and I was on a fast network.  It was a win over just sitting at the slower machine, believe it or not!)
22:02 japhb Tene: I knew what you meant.
22:02 Whiteknight Yay! Whiteknight: 1, Warnock: 0
22:02 japhb And yes, sounds good.
22:05 japhb Tene, are you accepting PM's?
22:05 Tene I am.
22:07 davidfetter joined #parrot
22:20 gryphon joined #parrot
22:23 chromatic joined #parrot
22:31 viklund joined #parrot
22:32 contingencyplan joined #parrot
22:34 rg1 joined #parrot
22:38 Infinoid moritz: Will do, sometime tonight
22:46 Whiteknight Infinoid: I'm backing out those changes to Handle I committed the other day
22:48 Whiteknight Allison helped me realize that it's not really the right solution, instead I opened TT #789
22:48 * Infinoid reads #789
22:49 Infinoid Ok.  I think the buffer fix is valid either way (and I also have some other things to fix there)
22:49 Infinoid ... why can't I get to trac
22:54 bacek joined #parrot
22:54 Infinoid there we go.  I love how running my server out of disk results in DNS timeouts
22:58 Whiteknight I'll check out the buffer fix then and reapply if necessary
23:01 Whiteknight I had a fix in there too with Socket PMC, so I need to reapply that
23:02 Infinoid oh, did the branch go poof?
23:02 Whiteknight no, not the whole branch, just the one commit
23:03 tetragon joined #parrot
23:07 japhb How do you determine the full pathname of a library loaded via 'library = loadlib "libfoo"'
23:07 japhb ?
23:20 donaldh joined #parrot
23:21 skids joined #parrot
23:25 patspam joined #parrot
23:33 cotto joined #parrot
23:34 bacek good morning
23:34 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
23:43 bacek msg mj41 Can you setup "make cover" on TapTinder? Not for every commit though.
23:43 purl Message for mj41 stored.
23:48 mikehh joined #parrot
23:48 cotto Whiteknight, ping
23:49 kid51 joined #parrot
23:58 Limbic_Region joined #parrot

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

Parrot | source cross referenced