Parrot 1.3.0 "Andean Swift" released | parrot.org
Set by moderator on 23 June 2009.
00:00 ilia joined
Whiteknight hey, take your time 00:01
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
:)
Infinoid if I could find a place to steal more time in the day, I would :)
Whiteknight tell me about it
purl it is in the universe repo which is not enabled by default
Infinoid forget it
purl Infinoid: I forgot it
Whiteknight I tried to do hacking at night instead of sleeping, but that ended badly
Infinoid I hack best in the early morning 00:03
japhb Whiteknight: I feel your pain
Infinoid 06:00-09:00
those are my best hours
after that I start getting distracted by shiny things
Whiteknight i'm probably about the same 00:04
japhb Server problem found and fixed. udev for the lose. 00:08
Infinoid I has a nachos!
time for debugging.
Whiteknight: pay my respects to Mrs. Whitworth :)
Whiteknight thanks! 00:09
00:11 ilia_ joined
japhb Austin_Hastings: OK, bak. Let me know if you need any info from me. 00:15
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:26
00:27 eternaleye joined
japhb Austin_Hastings: Also see runtime/parrot/languages/parrot/parrot.pir 00:28
Austin Save some inches... 00:29
That's more like it. Thanks again, japhb 00:31
japhb OK, afk for dinner. bbl. 00:32
00:37 eternaleye joined 00:54 Sark joined 01:03 kurahaupo joined 01:13 amuck joined
Coke purl, \\msg is also "msg <user> <msg>" 01:16
purl okay, Coke.
Coke msg?
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>"
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 01:35 cotto joined
dalek tracwiki: v21 | cotto++ | ParrotQuotes 01:40
tracwiki: particle's a luminary
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
02:06 tetragon joined 02:07 Theory joined 02:32 Austin joined
Austin wikiwikiwiki 02:33
dalek tracwiki: v22 | Austin_Hastings++ | ParrotQuotes 02:44
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
02:48 chromatic joined
dalek tracwiki: v12 | Austin_Hastings++ | Parrot%20Virtual%20Machine%20Workshop%202009 02:48
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
03:00 cotto joined
Austin howdy cotto 03:01
skids
.oO(Either Austin purposefully chose the shot where his face is blocked, or photographer too fascinated by camera)
Austin I think that was the photog saying "this (cotto's) camera is portrait, not landscape - everyone scrunch in"
cotto Hi Austin. 03:02
Austin Or maybe I have that backwards. I know there were two cameras involved...
cotto Yup. The picture from pmichaud's camera should be better.
Austin (Or maybe I'm like the neighbor on Home Improvement, and no-one will ever see my face on camera...) 03:03
Wilson?
purl Wilson is 2
cotto Austin; ?
Austin ... ?
purl Yada yada yada hasn't been implemented yet! (unless you run bleadperl)
skids I forget his name, but do remember the character.
Austin So what's new at yapc? 03:04
cotto we had the dinner tonight at the Steelers' stadium and got a nice tour
Austin Wow. That is nice. 03:05
Get any cheerleaders?
cotto chromatic's talk on Modern Perl was very well attended
nope
I'm sure you'll be glad not to have missed that.
Austin Should have let RBlackwe organize it.
He would have got you cheerleaders, I'm sure.
cotto I think he did 03:06
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:07
Changing the subject slightly, what's the worst possible thing that could happen (in code) to parrot? 03:08
Specifically, describe the severity of the worst possible bug 03:09
skids runtime, or design-wise? 03:10
japhb IO opens root instead of desired file?
socket sends naked pics from office party instead of apology to spouse?
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?
Austin Background: If you go to 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.
cotto++ for getting those snapshots uploaded like 5 minutes after the meeting 03:12
skids Oh, then I have plenty.
1) multiple developers take design in circles, subsystems never converge to satisfy all needs
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
That would be something like a y2k problem or a virus vulnerability or some such.
japhb bigger even than that would be active data corruption, I would think. 03:14
chromatic That's the big one.
japhb though perhaps just make both of those max
Austin Hmm. I was considering "corrupts data" => "noone can work", but okay. 03:15
And there's a bunch of those, and they all are essentially "Galactic Ultimate"
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
Austin japhb Sure, but they weren't reporting the bug. I bet when they realized what was going on, they stopped working :)
japhb heh
skids One cut off point is "you can't just revert svn to fix it" 03:17
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.
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.
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 (trac.parrot.org/parrot/wiki/Yapc10Bof). Please invite someone with more clues than me to check that, and maybe tell the true story.
japhb: Everyone wants it.
skids Massive popular standard emerges that absolutely must be supported, and is completely antithetical to bas architecture.
Austin lol 03:20
That's just a major rev...
SMOP
:)
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?
chromatic critical?
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
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.
Austin Here's me not knowing Trac well enough, but can we get on-screen help to explain what the "rules" are?
skids You mean other than "something like the weak Debian SSH keys"? 03:24
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.
I'm not sure we can keep enough other experiments going to fix other problems. 03:26
I also think that fixing this problem will improve many of the others.
Austin Okay. That's just my expectations being different, then.
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.
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.
Not that there aren't blockers to getting very far on that. 03:29
Austin laugh
Why is concurrency a threat, skids? 03:30
dalek tracwiki: v6 | Austin_Hastings++ | Yapc10Bof
tracwiki: trac.parrot.org/parrot/wiki/Yapc10...ction=diff
Austin chromatic: reworded
skids Because nobody codes with it in mind.
03:30 s1n_yapc joined
skids It may become an insurmountable task. Should be worked on before the codebase gets huge. 03:30
japhb "before"? 03:31
Austin :->
japhb I think it's already pretty damn large
Hell, the *docs* are a maze of twisty passages, all different.
The fact that it is taking months to refactor calling conventions makes me quite worried about doing anything even deeper than that. 03:32
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:33
03:34 Andy joined
Austin skids: How hard are you hoping this will get? 03:34
(realtime, I mean)
skids Latency 2-3 orders of magnitude worse than machine IRQ.
(not timetick, IRQ) 03:35
Austin Yikes
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?
cotto Austin, the only way they'd get uploaded was if I did it right away.
Austin cotto :)
you still rock
japhb: I confess to knowing nothing of p5 internals 03:36
Can you elaborate a little?
japhb Austin: the simplest way to put it is "P5 ops are heavy"
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.
skids (assuming a modern HZ, not like 100 of days past)
japhb 'add' in the P5 VM is pages of code.
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?
japhb Austin: yes ... but my understanding is that the intent was them to be even lighter than they are right now.
(And, BTW, I mean "semantically lighter" -- I'm not talking about actual current implementation efficiency, because P5 is the winner there.) 03:40
afk for a bit
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.
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.
It makes the contract with the VM include things like register utilization, so JIT knows when it has what available. 03:43
Austin Is the JIT even profitable? 03:45
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:46
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:47
skids Good question. 03:48
purl Yeah, it is. I'm stumped.
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.
skids wonders how much of a lexpad 16 SSE4 registers would fit.
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.
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.
Austin Maybe they put all the common ops into a big switch stmt.
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.
japhb Parrot had a traditional JIT design, before tracing became in vogue
sigh, afk again
Austin japhb: You're not here for the hunting, are you? 03:53
cotto but perhaps I was reading too much "L1" into "jit"
jdv79 there's a switch runcore iirc
cotto jdv79, yes
Austin cotto: What other benefits do you see from L1? 03:54
cotto there won't be a border between C and PIR that we'll get a speed penalty from crossing 03:55
we can do better analysis and optimization of L1
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?
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
jdv79 Austin: its beer time
Austin jdv79: For you, maybe. Are you at YAPC?
skids (For one, I'd really like to understand lexpads/stack more, but the code doesn't congeal for me.)
cotto since C and PIR do argument passing completely differently
jdv79 i am justin - the one that sat to your right at hofbrau
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.)
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.
Austin skids: thanks. I think that's the first actual response I've ever gotten
jdv79: Good hunting.
skids Like I said, a topic everyone likes to avoid.
Anyway, sleep time. 03:59
Austin niterz
cotto: What are we doing on the other side of C?
cotto converting to varargs, iirc
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?
Austin I can't. I don't know why we cross the C/PIR boundary. 04:01
You're not talking about just going inside an opcode or vtable function, right?
cotto We have some functions in C that need to deal with PIR calling conventions. That's expensive.
04:02 s1n_yapc joined
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 :)
s/got read/go read/
cotto Sure. Any METHOD in a PMC counts.
also note what pmc2c does to those functions (and MULTIs) 04:03
Austin So filehandle::open would be a valid example? 04:04
cotto yes, and that's why whiteknight doesn't like doing IO through methods (afaiui) 04:05
04:06 magnachef joined
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
Austin Back up. 04:07
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:08
cotto Austin, Parrot_FileHandle_nci_open, especially compared to what's in the METHOD in the .pmc file 04:09
Austin Okay. Looking now.
cotto brace yourself 04:11
04:11 tetragon joined 04:12 brbrooks joined
cotto btw, chromatic++ for leading that meeting. He did a good job of drawing out what needs to happen. 04:14
dalek tracwiki: v23 | Util++ | ParrotQuotes 04:29
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
cotto Util++ #I was just going to do that. 04:31
Austin Why does the method have to create a return continuation pmc? 04:32
Shouldn't that be passed in from the interp?
Util :) 04:33
cotto If I could answer that, I'd probably be fixing pcc_rewiring.
Austin :) 04:35
cotto Hmmm. Whiteknight hasn't put up his writeup from the L1 discussion today.
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
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:39
What's the L1 proposal for this? 04:41
50% faster means 1.5x speed, not 2x speed. And so would mean 33% decrease in run time. 04:43
cotto Austin, you're right. That's why I hate that phrasing. 04:44
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:45
cotto First, calling conventions will be massively simplified once pcc_rewiring gets merged (or something equivalent). 04:55
Second, afaiui the calling conventions will be implemented in L1, meaning that you can use L1 to call C functions directly. 04:56
My understanding starts to fade at this point. 04:57
Austin laugh
cotto s/once/after/
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. 04:58
cotto Austin++ for writing up your comments. 05:02
Austin <bow> 05:03
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
karma austin_hastings
purl austin_hastings has karma of 11
cotto karma austin
purl austin has karma of 4
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
But maybe I should just make them tickets...
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
iirc
Austin combust!
purl combust is the web framework / content management system for geeks that we use at perl.org. See combust.develooper.com
Austin Maybe I'll pick that up tomorrow, then. I think I'm going to go to bed.
cotto It's very close to that time for me too. 05:09
Austin Good night, then.
cotto I just want to scribble down the major points from the L1 discussion, then I'm down too.
night, Austin.
05:09 Austin left 06:09 uniejo joined 06:23 uniejo joined, Theory joined 06:37 iblechbot joined
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 07:21 viklund joined 07:47 st joined 07:48 barney joined 07:56 eternaleye joined 08:17 ArjenL joined 09:15 JC1 left 09:25 patspam joined 09:28 donaldh joined 09:32 bacek joined
bacek o hai 09:38
Infinoid :) 09:54
10:11 guru joined
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.
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
bacek *incoming* 10:24
dalek rrot: r39751 | bacek++ | branches/tt761_keys_revamp/src/pmc (2 files):
[pmc] Hash.get_string_keyed* migrated to new style
 10:26
rrot: r39752 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Small fixes in Hash - don't blindly cast value to PMC*
rrot: r39753 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Reshuffle Hash code to keep related things close.
rrot: r39754 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Reshuffle Hash code more. No functional changes.
rrot: r39755 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Hash.get_pmc_keyed* migrated to MULTIs.
rrot: r39756 | bacek++ | branches/tt761_keys_revamp/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] Provide PMC* return value in generated switch-optimised VTABLE for MULTIs instead of relying on arguments.
rrot: r39757 | bacek++ | branches/tt761_keys_revamp/src/pmc/namespace.pmc:
[pmc] Sigh. Replace SUPER() with hand-crafted call to INTERP->vtables[...] again.
bacek crawl out under the table 10:29
Infinoid wow! 10:32
(gdb) print buffer_size
$6 = 8192
(gdb) print avail
$7 = 18446744073709538754
small error there...
bacek welcome to 21st century! There is a LOT of space available! 10:33
Infinoid I don't think we support lazy buffer allocation yet :) 10:36
bacek :) 10:38
bacek hit another roadblock on Hash refactoring... 10:39
I can't declare "MULTI FLOATVAL foo()"... JIT doesn't support it.
Infinoid msg whiteknight t/pmc/io.t failures fixed in r39758. 10:53
purl Message for whiteknight stored.
dalek rrot: r39758 | Infinoid++ | branches/io_cleanups/src/io/buffer.c:
[io] When done flushing the buffer, mark it as empty. (I think this was a typo.)
 10:54
Infinoid I/O buffering is very poorly tested at the moment, there are other bugs lurking in this code 11:03
bacek s{I/O buffering}{Parrot} 11:05
Infinoid I think Parrot overall is fairly well tested... more so than most projects
bacek yeah. But it still can be better. 11:06
Infinoid That's always true, of every project, no matter how good they get :)
bacek "GNU Hello World" is perfect example :) They have version 2.68 or something already 11:07
Infinoid GNU Hello is also an example of how the GNU way is not always the best way :) 11:08
purl okay, Infinoid.
Infinoid time to get ready for the day, seeya! 11:09
11:21 donaldh joined 11:35 guru left 11:39 whoppix joined 11:42 st joined 11:43 burmas joined 11:44 mtk joined 11:46 mtk left 12:07 cotto joined 12:09 chromatic joined
chromatic 1610–20; < L pellūcidus, var. of perlūcidus. See per-, lucid 12:09
12:21 Whiteknight joined
Whiteknight hello friends 12:21
pmichaud hello 12:30
12:30 Patterner joined 12:34 masak joined 12:39 kid51 joined 12:43 skids joined
Whiteknight has a lot of blogging and summarizing to do today 12:47
YAPC was quite the fun experience!
pmichaud Yes, I suspect I'll be catching up on yapc-related todo lists for weeks. :-( 12:48
12:52 kid51 joined 12:57 iblechbot joined 13:05 gryphon joined 13:08 cosimo joined 13:10 s1n_yapc joined 14:13 magnachef joined 14:16 particle1 joined 14:23 Theory joined 14:24 s1n_yapc joined
dalek tracwiki: v72 | whiteknight++ | WikiStart 14:25
tracwiki: create a page to hold info about L1 as discussed at YAPC
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
tracwiki: v1 | whiteknight++ | L1Recap 14:28
tracwiki: create page about L1 with info originally drafted on my blog
tracwiki: trac.parrot.org/parrot/wiki/L1Reca...ction=diff 14:29
tracwiki: v2 | whiteknight++ | L1Recap 14:32
tracwiki: removing stuff that was intended only for the blog post
tracwiki: trac.parrot.org/parrot/wiki/L1Reca...ction=diff
14:34 AndyA joined 14:45 chromatic joined
Coke needs something help enforce coding standards for cold fusion. 14:46
cotto Whiteknight++ for the L1 recap 14:48
14:50 uniejo joined
chromatic Coke, a priest? 14:51
pmichaud I was thinking "baseball bat" 14:53
Whiteknight ColdFusion coding standard #1: you should actually be using PHP instead 14:56
14:56 kid51 joined
cotto Whiteknight, does atomicity apply to L1 opcodes? 14:56
Whiteknight :)
cotto: I believe so
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.
chromatic, that's what I was thinking.
chromatic Depends on the processor. 14:58
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
so from the high-level view, L1 appears atomic for all components in Parrot
chromatic The kernel could interrupt an L1 op though.
Coke Whiteknight: coldfusion > php, IME. 15:00
Whiteknight Coke: that's fine too
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 ??
(seems like we should not be multiplying bytecode types.)
Whiteknight Coke: yes and no. PBC can be thought of as a macro layer around LBC for compactness 15:02
NotFound Coke: I just read your message. How can I access feather? 15:05
Coke ask juerd.
juerd?
purl hmmm... juerd is root or at juerd.nl/ or mailto:juerd@juerd.nl
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
I suspect if you're not duplicating the error, the other-installed copy might be the problem
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?
is that codetests?
Coke NotFound: so it's probably the other-installed version conflicting.
(at a guess)
NotFound I'll check that locally in one of my machines first, then. 15:08
dalek tracwiki: v3 | cotto++ | L1Recap 15:09
tracwiki: basic copyediting and clarity changes
tracwiki: trac.parrot.org/parrot/wiki/L1Reca...ction=diff
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?
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.
moritz but we should not forget that we also have to actually *do* them :-) 15:12
having possibilities for optimization isn't enough in itself
Whiteknight True. Very true 15:13
but we don't even have the potential right now
moritz right
chromatic STOP SAYING WHAT I'M THINKING... oh well, go ahead
cotto Simply going through a single layer instead of a PIR/C mutt is an optimization itself.
Whiteknight is tuned in to chromatic's wavelength
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.
chromatic It looks like Florida. Creepy.
cotto particle1, where are you? 15:15
15:15 ilia joined
cotto goes off to search 15:16
pmichaud anyone seen particle? 15:18
15:18 ilia joined
pmichaud nm, found him. 15:19
chromatic How fast is he going?
pmichaud I have no idea. 15:20
Coke wave to him for me.
chromatic That's him then.
15:20 donaldh joined 15:23 eternaleye joined
Tene tene? 15:23
purl you are, like, Stephen Weeks or a madman
Tene purl: tene is also blogs.gurulabs.com/stephen/
purl okay, Tene.
15:25 ilia_ joined
cotto seen darbelo 15:30
purl darbelo was last seen on purl 17 hours, 41 minutes and 43 seconds ago, saying: <private message>
cotto apparently he's right here and he's sitting still. I'm going to write a paper about it. 15:31
(particle)
pmichaud barbie's talk is running longer than listed, so I'll be a bit longer than originally expected 15:32
Whiteknight chromatic: blackberry pie 15:34
Coke I would have picked Shephard's. ah well. 15:36
dalek TT #786 created by jkeenan++: io_cleanups branch: config step auto::gettext throws warnings on ... 15:37
Whiteknight kid51++ 15:38
karma kid51
purl kid51 has karma of 77
Whiteknight well that's bullshit, he has like several thousand commits 15:39
karma jkeenan
purl jkeenan has karma of 2229
Whiteknight that's better
jkeenan++
15:40 chromatic joined
japhb Tene: obNVidiaPing 15:45
15:57 fish joined
fish hi :) 15:57
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 16:24 ascent joined 16:27 NotFound joined 16:32 kid51 joined 16:35 cotto joined 16:47 Psyche^ joined 16:54 cognominal joined 16:57 chromatic joined
Whiteknight allison: ping 17:01
dalek TT #788 created by jkeenan++: Audit PDD30 compliance
17:02 magnachef joined 17:15 chongax joined 17:26 jhorwitz joined 17:51 jjore joined 17:59 bacek joined
allison Whiteknight: pong 18:07
Whiteknight hey allison, how are you doing?
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:08
allison Whiteknight: didn't see the message yet, will take a look now 18:10
18:10 bobke joined
skids
.oO(Renaming Hash to AssociativePMCArray? Why not AssocativePMC array, then they can both be misspelled
 18:10
18:17 soxet joined
Coke Whiteknight: my concern is why did you make Handle a PMC? 18:17
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
Coke seems like it's better modeled as a library, or as private-to-parrot c methods.
Whiteknight and it's persistent information that we want to keep for each instance of FileHandle
Coke but if Handle only being used a collection of methods, why does it need to be an attribute?
so a Handle is not just a collection of method? 18:19
"s"
Whiteknight it isn't a collection of methods, it's a collection of data
Coke ok.
Whiteknight it actually has no methods and only a small handful of vtables (although I want to add a few vtables for ease)
by separating it out this way, we can finally subclass FileHandle properly from PIR 18:21
or, we're much closer to that goal
18:23 darbelo joined
Coke Is there a ticket open for not being able to sublass something witha a non-register attribut? 18:23
"e"
Whiteknight Coke: a handful of tickets reported have that as a root cause, yes 18:24
but no one ticket for this root issue
18:26 JC1 joined 18:29 japhb joined
allison Coke: well, that was by design 18:31
Coke: on the theory that C attributes aren't particularly useful from PIR (where everything is a register) 18:32
Coke: it would be possible to inherit C structs etc, using a various proxy PMCs (like UnmanagedStruct, etc) 18:34
Coke: not entirely sure it's a good idea... 18:35
18:36 cghene joined
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:36
18:37 cghene joined
reezer bacek: are you there? 18:38
purl yes!
allison Whiteknight: how's the speed? 18:39
Whiteknight: we made the move to make FileHandle *not* subclassable, because making it subclassable made it really slow
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
(because trunk is already too slow)
Whiteknight Once I finish cleaning, I don' think there will be any performance penalty though
allison it needs to be faster, not equal 18:41
Whiteknight: do you have a specific range of revisions you want me to review, or all revisions since the branch started?
Whiteknight the basics got put in place in just one revision, let me get it 18:42
allison 39741?
Whiteknight yep, that's the one 18:43
pretty big though, sorry about that. it was proof-of-concept
I think I can make it faster then trunk. Won't be dramatic but I think I can make it better 18:45
(I don't want to sell you more then I can deliver) 18:46
bacek reezer: no actually
bacek trying to understand why he woke up at 5AM... 18:47
Coke allison: i would say that having un-subclassable PMCs is bad.
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
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
I should probably use a wiki checklist instead though
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
pmichaud moving to register types seems.... unlikely.
allison Coke: so, I can consider that a theory proven unworkable
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.
(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
Whiteknight I agree with that, I've had a few instances of PMCs I wanted to be able to mark "not subclassable"
allison it's perfectly fine to subclass them from C
Coke ew.
allison well, it's the basic nature of our C/HLL divide 18:51
C is primitive, but we're using it to bootstrap a HLL virtual machine
this is why chromatic wants to eliminate C PMCs entirely
and write them all in some higher-level language
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:52
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:53
I'm not really sure what the ultimate solution will be. 18:55
so far, it seems to be heading in the direction of making C PMCs act more like PIR PMCs 18:56
(that is, more toward chromatic's idea)
reezer bacek: am I allowed to query you? I would like to make a suggestion related to bug #758. You can read it later
moritz reezer: I'm sure he won't kill you for it, so go ahead ;-)
bacek reezer: of cause
moritz: Austria and Australia are different countries! He is just too far away to kill him (at least in person :) 18:57
moritz ;-) 18:58
Whiteknight allison: So what's your initial verdict on io_cleanups, reasonable idea or not? 18:59
(assuming I can make it faster)
bacek doughera? 19:00
.oO( Modulus of negative numbers is counter-intuitive)
 19:10
Small quiz: 19:12
result of "-5 mod 3" will be:
a) -2
b) -1
c) 1
moritz -2 in C, 1 in Perl 19:13
bacek d) This poll suck, no one should mod negative numbers
Coke 1 in tcl also.
bacek Why it's "1"? 19:14
moritz bacek: because $n mod $m is usally a function mapping to the range 0..($m-1)
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.
bacek moritz: what about "5 mod -3"?
Coke modulus.
purl Math is HARD!
bacek and "-5 mod -3"... 19:16
moritz bacek: that doesn't make sense to me.
bacek moritz: indeed...
purl indubitably
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"...
moritz: looks like your assumptions are correct 19:19
allison Whiteknight: still reading through the diff
Whiteknight: (with some interruptions)
19:20 donaldh joined
moritz Infinoid: iirc you're the one to talk to about dalek... could please bring the commit mesages from github.com/hinrik/grok/ to #perl6? 19:24
cotto grok?
purl grok is an anagram of okrg, not okra
moritz cotto: documentation tool for Perl 6 19:25
cotto good naming
Coke grok is also a documentation tool for Perl 6 19:27
purl okay, Coke.
cotto how does it relate to u4x
?
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
moritz afaict, yes 19:29
masak it's the tool that delivers the docs on the CLI.
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
masak there might be other views as well, HTML/Web, Padre, etc.
allison Whiteknight: but this particular code rearrangement isn't buying us anything
Whiteknight: and it's costing us an extra PMC for every filehandle, expensive 19:30
Whiteknight: tweak your thinking around a bit, and you're nearly there
Whiteknight: FileHandle, Socket, and Pipe *are* the low-level PMCs, doing what your Handle PMC is doing 19:31
Whiteknight: and the way to subclass them from PIR is by delegation
Whiteknight allison: so subclassing these from PIR is a different process from subclassing any other PMC from PIR? 19:34
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:35
allison you just did with Handle 19:36
it's okay to have some core types who's entire purpose is to act as an interface with low-level systems
Whiteknight But I specifically made it impossible to directly instantiate a Handle from PIR
you can't do that with FileHandle
allison by doing that, you made it impossible for anyone to subclass FileHandle from PIR 19:37
Whiteknight how's that?
allison since they couldn't directly instantiate the core delegate type from PIR
Whiteknight the system will allocate the Handle internally, and do it lazily
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)
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
Whiteknight that's a bit of an exaggeration, it is a little better off 19:39
certainly better then the behavior now with regards to subclasses of FileHandle
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:41
provides the kind of complete subclassability that I think we both want 19:42
Coke yay, global variables! 19:43
;=)
Whiteknight Coke: would be a pointer on the interpreter, so thread-local
we already have an IO-specific structure in there anyway, it would be trivial to add in a table of OS descriptors 19:45
Coke Whiteknight: I can live with interpreter-level, sure. 19:46
cotto does the idea of multiple threads per interpreter make sense? 19:47
(sanity check, not suggestion) 19:48
Whiteknight cotto: no, each thread is it's own interpreter
cotto k 19:49
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
I don't think disallowing subclassing on FileHandle is the right way forward, but I could be wrong about that
allison Whiteknight: the way to fix that is to fix PMC subclassing 19:54
Whiteknight okay, good. I would rather fix the root problem in one shot. How do we go about doing that? 19:55
(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
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
Whiteknight that shouldn't be so hard if the delegate type has a sane interface
allison the basic problem is, attributes in PIR Classes are stored in an array
That array can only have PMC elements 19:58
so, it knows how to box and unbox the basic register types
Whiteknight so do something like box C types into ManagedStruct or something similar?
allison it doesn't know how to box and unbox other arbitrary types
C struct types can be boxed as ManagedStruct, yes
Whiteknight we can teach anything how to handle anything, we just need to know the way to do the teaching. 19:59
allison yes
the magic is all in the GET_ATTR/SET_ATTR macros
Whiteknight I'm not daunted by the challenge, so long as there is a solid goal in mind
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
mostly it's structs (which we already have a correspondence for)
some are stranger 20:01
Whiteknight anything that's stranger we could easily (though naively) put into a struct and handle that way
so that's not a problem
allison Whiteknight: we don't want to create another C struct for every C PMC 20:02
Whiteknight I said it was naive
allison they already have a C struct, which we're translating to an array
dropping them into a one-element ManagedStruct is a possibility 20:03
Whiteknight or another Managed* PMC type to handle scalar values 20:04
allison something more like a CPointer may be preferable
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?
allison (with appropriate behavior for boxing and unboxing that value, depending on its type)
sounds good
Whiteknight Thanks. allison++
allison The Handle stuff was on the right track, BTW, in the sense of abstracting a C type into a PMC. 20:06
Whiteknight yeah, I figured it couldn't be entirely wrong 20:07
:)
cotto allison, have you looked at L1Recap on the wiki?
Whiteknight is heading home now. Goodbye 20:12
allison cotto: not yet
20:23 gryphon joined 20:29 chromatic joined 20:43 cotto joined 20:56 amuck_ joined 20:57 whoppix joined
Tene allison: available to chat about pynie? 21:13
21:14 HG` joined
allison Tene: sure 21:14
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:15
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.
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
Tene but that's broken at least until after PCT refactors.
allison Tene: oooh, I see, yes that's the one thing that could be problematic
Tene I got it working when I faked it.
allison (using anything from Perl 6)
Tene P6object isn't Perl 6. 21:18
allison P6object seems like overkill for Pynie's needs
Tene eh, could be. I'm not so sure.
allison Tene: yes, and I've talked to patrick about changing the name
Tene: but using anything with P6 in the name is problematic
Tene Will it still be problematic if I subclass it first to give a different name?
allison a more likely solution, is a trimmed-down version of it for Python 21:19
strip out all the extra Perl6-ish stuff
Tene Sure, okay.
I'll investigate that. 21:20
allison basically, a PyObject
cotto Just rename it to PythonObjectThatHasNothingToDoWithPerl6
allison in fact, you could likely do fine just emulating PyObject
cotto with a boolean attribute called "comes_from_perl6" that's always false
Tene eh? explain "emulating PyObject"
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
PyObject is C Python
Tene Ah.
allison docs.python.org/c-api/structures.html
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
cotto pmichaud, ping
Tene allison: but it's definitely not okay for me to commit anything referring to P6object. 21:25
21:26 Whiteknight joined
allison hmmmm... I guess it depends on if it's a "temporary, will remove in a month" solution or a "permanent" solution 21:26
Tene: but it's at least not worth pouring a pile of work into a P6object based solution 21:27
Tene Okay, I understand.
allison Tene: if you have one already implemented, it would seem like a waste to throw it away
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
too risky for a "supported" release
it's mainly in the phase of "fix build and test failures"
Tene last I checked, trunk wouldn't merge cleanly into the branch. 21:29
allison no, it shouldn't
Tene Shouldn't? 21:30
allison (I hope no one tried to commit a merge)
no, I'll extract a diff and apply it to a clean branch
Tene Nobody tried to commit a merge.
TWhile I've been watching, at least.
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
allison moritz: you can with svn too, just don't commit it
Whiteknight irclogs? 21:33
purl irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
japhb allison: (local svn branch == don't commit) That's ... suboptimal. 21:38
Tene We're not on a sub. 21:39
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
japhb: in svn it's dead easy to revert, or throw away a branch
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
japhb shrugs.
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
allison japhb: oh, agreed, long-lived changes should be committed somewhere 21:43
dalek TT #789 created by whiteknight++: Make All PMCs Subclassable
allison japhb: but moritz was talking about experimenting with merges, so a shortlived change
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.
japhb ah, I get it.
Tene: How about having a strong opinion about OpenGL? ;-) 21:44
japhb pushing while he still can spare tuits ....
Tene japhb: oh, sure.
lemme go back to nvidia proprietary...
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.
Tene Yes, installed.
purl installed is, like, easy as well
japhb Ah, great,
yes, so after the switchback, do a realclean/configure/make
Tene japhb: rebuilding 21:54
japhb: exactly the same failure as before 21:57
japhb goes mentally Turrett's for a minute 21:58
Dang it, I thought that was the key
... 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
moritz opengl over ssh? teh horror :) 22:00
japhb moritz: It can be done! 22:01
Tene I was more thinking just to check out linking order... ;)
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
Tene: I knew what you meant.
Whiteknight Yay! Whiteknight: 1, Warnock: 0
japhb And yes, sounds good.
Tene, are you accepting PM's? 22:05
Tene I am.
22:07 davidfetter joined 22:20 gryphon joined 22:23 chromatic joined 22:31 viklund joined 22:32 contingencyplan joined 22:34 rg1 joined
Infinoid moritz: Will do, sometime tonight 22:38
Whiteknight Infinoid: I'm backing out those changes to Handle I committed the other day 22:46
Allison helped me realize that it's not really the right solution, instead I opened TT #789 22:48
Infinoid reads #789
Ok. I think the buffer fix is valid either way (and I also have some other things to fix there) 22:49
... why can't I get to trac
22:54 bacek joined
Infinoid there we go. I love how running my server out of disk results in DNS timeouts 22:54
Whiteknight I'll check out the buffer fix then and reapply if necessary 22:58
I had a fix in there too with Socket PMC, so I need to reapply that 23:01
Infinoid oh, did the branch go poof? 23:02
Whiteknight no, not the whole branch, just the one commit
23:03 tetragon joined
japhb How do you determine the full pathname of a library loaded via 'library = loadlib "libfoo"' 23:07
?
23:20 donaldh joined 23:21 skids joined 23:25 patspam joined 23:33 cotto joined
bacek good morning 23:34
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
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
cotto Whiteknight, ping 23:48
23:49 kid51 joined 23:58 Limbic_Region joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!