Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2008-12-23

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

All times shown according to UTC.

Time Nick Message
01:14 particle1 joined #parrotsketch
01:14 particle1 left #parrotsketch
10:12 particle joined #parrotsketch
14:01 particle1 joined #parrotsketch
14:25 Wknight8111 joined #parrotsketch
14:51 contingencyplan joined #parrotsketch
15:34 contingencyplan joined #parrotsketch
16:20 contingencyplan_ joined #parrotsketch
16:24 contingencyplan_ joined #parrotsketch
16:30 contingencyplan__ joined #parrotsketch
16:32 contingencyplan_ joined #parrotsketch
16:35 contingencyplan joined #parrotsketch
16:51 contingencyplan_ joined #parrotsketch
16:56 davidfetter joined #parrotsketch
17:24 particle joined #parrotsketch
18:03 Whiteknight joined #parrotsketch
18:06 rurban joined #parrotsketch
18:19 pmichaud joined #parrotsketch
18:23 mberends joined #parrotsketch
18:26 jhorwitz joined #parrotsketch
18:29 barney joined #parrotsketch
18:30 cotto joined #parrotsketch
18:32 allison joined #parrotsketch
18:34 Whiteknight hello
18:34 cotto hi
18:34 allison hi
18:35 pmichaud hello
18:35 jhorwitz hello
18:35 rurban hi
18:35 Whiteknight who's driving this train?
18:35 Coke joined #parrotsketch
18:36 pmichaud I blame Coke.
18:36 * allison nominates Coke for today's MC
18:36 rurban let's wait for chromatic?
18:36 Coke Coke, as you recall, said there was no meeting today, but if you wanted to have one, that was fine with him. =-)
18:36 PacoLinux joined #parrotsketch
18:36 allison rurban: I believe chromatic is in family Christmas stuff
18:36 allison Coke: ok
18:37 Coke I'm at verk, but have half a brain cell to devote.
18:37 Coke allison?
18:37 particle hi-o
18:37 allison - Mainly worked on integrating other's branches this week.
18:37 barney servis
18:37 chromatic joined #parrotsketch
18:37 Coke allison: hokay.
18:37 allison - Started the branch for the GC refactor, and spent some time planning it with chromatic and Whiteknight.
18:38 allison - Also traveling with family stuff.
18:38 allison EOR
18:38 Coke k. Barney?
18:38 barney Pipp:
18:38 barney Remove the alternative frontends from Pipp.
18:38 barney Applied patches from Daniel Keane: 'elsif' and 'do-while'
18:38 barney Add implementation of 'eval'.
18:38 barney Put PHP functions into hll root namespace 'pipp'.
18:38 barney Put internal functions into hll root namespace '_pipp'.
18:38 barney Parrot:
18:38 barney Update function doc for Parrot_register_HLL().
18:38 barney Requested documentation of the default hll root namespace.
18:38 barney Nudge pmichaud++ into implementing .hll() on PAST::Block.
18:38 barney reserve 1 q
18:38 barney .eor
18:38 Coke k. chromatic?
18:38 chromatic Profiled op-level MMD, found three places to optimize.
18:39 chromatic Waiting for GC branch tasklets.
18:39 chromatic Will look at Gabor's Parrot::Embed questions; hope to improve things for Padre.
18:39 chromatic Will review lathos's NCI generator update, but it looks good now.
18:39 chromatic Happy to look at any segfaults reproducable from PIR.
18:39 chromatic END
18:39 Tene Oh, there's a meeting here.  I forgot again.
18:39 Tene Hi.
18:40 Coke see http://partcl.blogspot.com/
18:40 Coke now running 5 more spec tests (regressed on one.) Thanks to some folks on #tcl
18:40 Coke have a lead on a fix for a dozen more that I hope to complete this week.
18:40 Coke (involves getting a barely functional [trace] working.)
18:40 Coke exit;
18:40 Coke cotto?
18:40 cotto * randomized the per-interp hash seed (child interps inherit the seed from their parent so I don't have to mark anything shared)
18:40 cotto * knocked off a bunch of Coverity defects
18:40 cotto eof
18:40 cotto q1q
18:40 Coke jhorwitz: ?
18:40 jhorwitz mod_parrot is still blocked due to the IO merge.  waiting on either a subclassable FileHandle PMC or a string IO version of FileHandle, which i discussed with allison.  since all 0.5 milestones are completed, i may branch so i can keep working.
18:40 jhorwitz q1q
18:41 jhorwitz EOR
18:41 Tene Did we meeting last week?
18:41 Coke tene, why don't you report now.
18:41 Coke and yes.
18:41 Tene Looks like a lot of exceptions work.
18:41 Tene CATCH and CONTROL in rakudo
18:41 Tene continue/break in given/when
18:42 Tene resumable exceptions in rakudo
18:42 Tene started on loops refactor with pmichaud++
18:42 Tene still a few issues to work out with that
18:42 Tene KTHXBAI
18:42 Coke k. rurban?
18:42 rurban * started working on the cygwin release and install patches again. 51 .rej files todo. allison already applied some minor stuff, but there's still a lot missing. eor
18:42 Coke k. Whiteknight ?
18:43 Whiteknight =Misc
18:43 Whiteknight - released 0.8.2
18:43 Whiteknight - removed compilers/bcg/*
18:43 Whiteknight - refactored Integer.pmc to use VTABLEs instead of direct MMD calls
18:43 Whiteknight - closed a few RT tickets that I've been sitting on
18:43 Whiteknight - a few updates to old files in docs/
18:43 Whiteknight =branches/pdd09gc_part1
18:43 Whiteknight - updated gsoc_pdd09 branch to get a clear diff of changes
18:43 Whiteknight - created src/gc/marksweep.c to hold the old MS collector. Would like to merge this change to trunk soonish
18:43 Whiteknight - tried to slim down the IT collector from branches/gsoc_pdd09 for use in the new branch
18:43 Whiteknight =JIT
18:43 Whiteknight - Worked on removing exec code from .h files in src/jit/
18:43 Whiteknight - Able to update src/jit/amd64/*
18:43 Whiteknight - created the branches/jit_h_files/ to work on src/jit/ia32/*.  More convoluted then I expected, so going is slow.
18:43 Whiteknight - I don't have access to other platforms for testing
18:43 Whiteknight - Looking to improve JIT coverage on amd64, idly poking and prodding at this
18:43 Whiteknight EOR
18:44 Coke any other committers that want to report?
18:44 * pmichaud raises hand.
18:44 Coke whoops.
18:44 Coke Ok, i suppose you can go. =-)
18:44 particle !
18:44 pmichaud I didn't accomplish much this week.  Only:
18:44 pmichaud ** Rakudo spectests (r34267): 264 files, 5833 passing, 0 failing
18:44 pmichaud +694 passing tests since last #ps.
18:44 pmichaud == Parrot stuff
18:44 pmichaud : updated non-ICU unicode strings to recognize more ALPHABETIC and WORD types
18:44 pmichaud : corrected .arity method on Sub PMCs
18:44 pmichaud == PGE stuff
18:44 pmichaud == PCT stuff
18:44 pmichaud : added "hll" attribute to PAST::Block nodes, based on barney++ nudge
18:44 pmichaud : working on loop refactor, should finish shortly (< 2 hrs)
18:44 pmichaud == Rakudo stuff
18:45 pmichaud : resolved lots of RT tickets
18:45 pmichaud : updated 'sort' to be a stable sort
18:45 pmichaud : fixed infix:<cmp> and other Pair methods and functions
18:45 pmichaud : refactored Mapping methods
18:45 pmichaud : refactored initialization, use, and MAIN handling
18:45 pmichaud : converted \d[...] to \c[...]
18:45 pmichaud : fixed unicode hyperops »+«
18:45 pmichaud : cleaned up IO.readline and prefix:<=>
18:45 pmichaud : added radix support to string-to-number conversion
18:45 pmichaud : applied patches from cspencer++, bacek++, and others
18:45 pmichaud : added +/- Inf, NaN support
18:45 pmichaud : added whatever * to array slices
18:45 pmichaud EOR
18:45 Coke woof.
18:45 Coke particle?
18:46 particle ~ mainly infrastructure and accounting items this week
18:46 particle ~ some discussions with designers/developers on various parrot/pct/rakudo topics
18:46 particle ~ missing io sockets implementation has broken some examples (e.g. http.pir) and blocks progress on an http server written in perl 6 (willing contributers available)
18:46 particle ~ i'd like to remove all unused or unfrequently used code from parrot, including stm, certain runcores, and certain garbage collectors
18:46 particle .end
18:47 Coke I will interject a question: there's a TT about the old streams.pir library that's now borked, in re: your sockets note.
18:47 Coke ok. barney, you had a question?
18:48 allison particle: +1 on removals
18:48 barney Anything speaking against https://trac.parrot.org/parrot/ticket/85
18:49 Coke barney: +0
18:49 barney Being able to set the hll root from embedders
18:49 Whiteknight +1 from me
18:49 allison Coke: your reservations?
18:49 chromatic +0.1
18:50 Coke allison: more of a no opinion.
18:50 Coke as opposed to a -1
18:50 particle abs(-1)
18:50 Coke barney: looks like no one's objecting...
18:50 chromatic We need a way to access namespaced symbols, but I'm not sure adding a stateful API call is the right approach.
18:50 allison barney: it looks like a workable solution for now, no caps in function names, though so "Parrot_set_hll"
18:50 rurban You must set the HLL to find a symbol in other namespaces?
18:50 allison or "Parrot_hll_select"
18:51 chromatic If we do this, we'll also need a way to access symbols in other HLLs and namespaces.
18:51 Coke rurban: no. you can do get_root_global ['hll'], 'foo'
18:51 allison (following the convention that the first word should indicate the subsystem)
18:51 chromatic Coke, you can't do that from Parrot::Embed.
18:51 chromatic It's not easy to do that from C either.
18:51 Coke hokay.
18:52 jhorwitz if we have that, we will also need a Parrot_get_hll...
18:53 allison jhorwitz: that's a good idea anyway
18:53 barney There is an exported  Parrot_get_HLL_id
18:53 allison barney: which is a terrible name
18:53 * jhorwitz concurs
18:53 chromatic What we currently export shouldn't imply any design rationale.
18:54 allison but, can be simply renamed instead of reinvented
18:54 chromatic That is, there's no coherent rationale behind our list of exported symbols.
18:54 allison chromatic: true, but we should clean up as we go along
18:54 chromatic I want to change my vote then.  -1
18:55 allison chromatic: reasoning?
18:55 chromatic The request is to access symbols in a given namespace.
18:56 allison i.e. the solution isn't a direct response to the stated problem?
18:56 chromatic Suppose you want to access symbols from multiple HLLs.
18:56 chromatic Exactly.
18:56 barney szabgab wants that for calling PHP function from Padre
18:56 chromatic You write: Parrot_hll_set( 'Foo' ); Parrot_get_global( 'bar' ); Parrot_hll_set( 'Baz' ); Parrot_hll_get( 'other_bar' );
18:57 chromatic ... and then you shake your fist at the sky and say:
18:57 allison yes, we should probably have a way of calling a function from a particular HLL without actually setting the current HLL
18:57 jhorwitz you can do that now
18:57 chromatic "Why didn't you give me Parrot_get_global_from_hll( 'Foo', 'bar' )?"
18:57 jhorwitz but it involves knowing the namespace
18:57 pmichaud Parrot_get_hll_global (to match the opcode, perhaps)?
18:57 chromatic Sure, that's a better name.
18:58 jhorwitz i like that, but then you also need Parrot_set_hll
18:58 allison ok, so that's the direct response to the stated problem
18:58 chromatic Why do you need Parrot_set_hll?
18:58 barney When calling a function in a HLL, the current_HLL might be expected
18:58 jhorwitz i guess you don't if you include the HLL in Parrot_get_hll_global
18:58 jhorwitz (the opcode doesn't)
18:58 allison but, yes, in general most things we can do from PIR, we should also be able to do from C
18:59 pmichaud oh, sorry.  Parrot_get_root_global( 'Foo', 'bar' )
18:59 pmichaud (to match the opcode)
18:59 pmichaud jhorwitz is correct that get_hll_global finds a symbol in the current hll
19:00 chromatic I disagree about the necessity to have C and PIR isomorphic through the embedding interface.
19:00 chromatic Any non-trivial C program which uses the external interface will end up looking a lot like inlined opcode bodies.
19:00 jhorwitz i agree w/ chromatic here.  we have Parrot_find_global_*
19:01 barney Parrot_find_global_*  is really   Parrot_find_hll_global_*    with the HLL 'parrot'
19:01 chromatic Besides, mostly I (or someone else suitably crazy) can address Gabor's needs within the XS of Parrot::Embed anyway.
19:01 chromatic I think.
19:02 allison the find* alternates were all deprecated years ago
19:03 particle where is namespaces pdd on the roadmap? this seems directly related.
19:04 pmichaud (point of clarification:  the find*global alternates are deprecated.  Other find* ops still exist.)
19:05 allison pmichaud: yes, good clarification for the record
19:05 Coke so, barney, is your question answered? =-)
19:05 allison particle: 1.1, April release
19:05 barney A problem is that most HLLs don't use the scheme layed out in PDD21, with hll root namespace 'lang' and  '_lang'
19:05 Coke barney: tcl does, fwiw.
19:06 particle it might be that tcl is the shining example here
19:06 barney Pipp is following that lead
19:06 allison barney: would shifting the languages over to using that scheme for private language namespaces resolve part of the problem?
19:07 barney No, shifting over to that scheme caused the problem.
19:07 Coke tcl was never embedded, and so never noticed. =-)
19:08 allison barney: ah, which raises a question of whether it's a good scheme
19:08 barney find_global() in Parrot::Embed can find symbols below 'parrot', but not below 'pipp'
19:09 chromatic Parrot::Embed needs fixing.  I haven't done anything until now because no one needed it until now.
19:09 allison this sounds like a bigger problem than just adding 'set_hll'
19:09 jhorwitz barney: you can do what you need using the existing embedding interface -- mod_parrot does it.
19:09 particle sounds like we need find_root_global that searches from the root, and don't need set_hll at all
19:10 barney Another issue is that whoever uses the op get_hll_global  depends on the value of current_HLL in the interpreter
19:11 allison barney: where does that cause conflicts?
19:12 allison should 'get_hll_global' search both 'lang' and '_lang'? (first one and then the other)
19:12 barney If you have one interpreter calling subs from different HLLs
19:12 barney when subs in the HLL use get_hll_global
19:12 Coke allison: no.
19:12 allison ok, yes *that*'s a huge problem
19:12 Coke (search both)
19:13 Coke tcl is using _tcl to hide subs from the user at runtime. I don't want them exposed.
19:13 allison should the HLL be set in the context instead of the interpreter
19:13 chromatic Again, anyone who's calling ops directly from C has already done something crazy.  We shouldn't make it easier for them.
19:13 allison Coke: fair enough, and on the whole would prefer to keep them cleanly separated
19:13 barney sorry. I think it is set in the context
19:14 pmichaud right now, get_hll_global is in the hll of the sub
19:14 allison chromatic: but this isn't just about calling ops from C, the current HLL is also used for selecting HLL-mapped types in C
19:14 pmichaud at least from PIR.
19:14 allison chromatic: and there are plenty of C functions that are used to support the PIR ops that need access to current HLL information
19:15 chromatic The Parrot_sub struct stores an HLL_id.
19:15 barney Coke: It's not about calling ops directly, but calling userspace HLL functions, that execute some bytecode
19:15 pmichaud when invoking a sub, the interpreter switches to the HLL of the sub.
19:15 allison barney: being set in the context should be safe, it'll only affect the particular execution chain
19:15 chromatic If subs don't know their HLLs, we have interesting problems when we export subs.
19:16 Coke barney: did you mean chromatic ?
19:16 barney yes
19:16 chromatic barney, how are they calling userspace HLL functions that *don't* have an HLL set?
19:16 jhorwitz subs may know their HLL, but you have to know how to find the sub in the first place (using either namespace or HLL)
19:17 barney jhorwitz++
19:18 allison jhorwitz: yes
19:18 chromatic Sure, but we're already talking about Parrot_find_root_global() or whatever it's called.
19:19 chromatic Everyone seems to agree that we need that and should use that.
19:19 barney extending Parrot::Embed::find_global() with a HLL probably a better solution
19:19 chromatic Exactly.
19:19 allison barney: that sounds good
19:19 * jhorwitz agrees
19:19 rurban much better than set_global
19:19 barney Maybe disallow hll names starting with an '_'
19:20 chromatic I don't see the point of that.
19:20 chromatic If you're controlling Parrot from C, you have access to its pasty white underbelly already.
19:21 chromatic Document what's available and public, and then laugh long and loud at people who rely on undocumented internals when you break them and they get to keep the pieces.
19:23 allison barney: we need some convention to give languages a private namespace. It doesn't matter what that convention is. '_' works for now, until we come up with something better
19:23 jhorwitz fyi, the *official* API definition isn't due til 1.3 (6/2009)
19:23 allison jhorwitz: yes
19:24 barney Yes. User defined functions and builtins in 'pipp', internals in '_pipp'
19:26 allison barney: ah, I see, you're saying we should formalize '_' for private language namespaces, so we never get '_foo' as public and '__foo' as private. That seems reasonable.
19:27 barney That's how I understood PDD 21
19:28 allison barney: yes, I took it as so much of a given that at first I thought you were proposing entirely doing away with '_foo' as a *private* namespace
19:29 chromatic Shall we move on to the next questions?
19:29 barney Not at all. I started using '_pipp' today.
19:30 * jhorwitz had a question when this one is settled
19:30 Coke we've got the queue. =-)
19:30 jhorwitz yay
19:30 jhorwitz right, i'm behind cotto.  :)
19:31 Coke chromatic: lets.
19:33 chromatic cotto?
19:33 cotto Can we do one of the following:
19:33 cotto - Add a PARROT_EXPORT function to get entropy from the underlying system (and a way to access that function from PIR)
19:33 cotto - Use entropy from the system to seed the prng
19:33 chromatic Why do we need to export it?
19:33 cotto so PIR code that needs randomness can get it
19:34 cotto (either option is fine afaict)
19:34 chromatic PARROT_EXPORT has nothing to do with PIR code; it's about whether the symbol is visible from outside libparrot at the dlfunc() level.
19:35 allison cotto: sounds like a good addition. go ahead and make it PARROT_EXPORT, we'll decide later if it's also part of the API
19:35 cotto The only issue for me is making it cross-platform.
19:35 pmichaud PIR code that needs randomness uses the Random PMC, yes?
19:35 allison chromatic: at the moment PARROT_EXPORT is necessary on windows for just about anything that isn't 'static'
19:36 chromatic I don't believe that.
19:36 allison chromatic: that's why we changed the name, so people don't think it defines what is and isn't part of the API
19:37 chromatic I recall that we changed the name because we're going to cut down on what we export and make part of the API.
19:37 allison chromatic: I'm not sure I do either, but it needs more extensive testing by windows developers, and isn't a priority until 1.3
19:37 cotto I'll write a patch for as much as I can figure out and make a TT out of it.
19:37 chromatic The reason I added GCC visibility hiding to our default GCC 4.x behavior is to get the same symbol visibility on Windows and non-Windows platforms.
19:38 allison chromatic: yes, definite progress. they're not identical, but closer. will still need some more work when we get to that roadmap task
19:38 cotto eoq
19:40 Whiteknight cotto: sounds to me like you could add a seed function to the files in config/gen/platforms/*
19:41 cotto Whiteknight, sounds good
19:41 allison looks like we lost chromatic in a network dropoff, are there any other questions?
19:42 Coke jhorwitz had one.
19:42 jhorwitz yes...
19:43 jhorwitz allison: mod_parrot is blocked due to the IO merge.  you and i discussed a branch to start picking at the low level IO functions so we could eventually subclass FileHandle.  any progress?
19:43 allison jhorwitz: I'll do that today
19:43 Whiteknight need any help with that?
19:43 allison it's not a long task
19:43 allison Whiteknight: I want you working on the GC branch
19:44 jhorwitz the branch isn't, but the working bits won't take long?
19:44 Whiteknight okay, I'll focus on that tonight then
19:44 allison jhorwitz: it's mainly just that I've been traveling non-stop since we talked about it
19:44 jhorwitz understood.  :)
19:45 allison jhorwitz: neither is long, the code is already mostly done, just not checked in anywhere
19:45 jhorwitz ok, so the goal for this branch is to be able to properly subclass FileHandle?
19:45 jhorwitz or is this the string IO bit?
19:45 allison jhorwitz: which is a higher priority? creating a StringHandle to substitute for FileHandle is fastest
19:46 jhorwitz StringHandle is not optimal, but unblocks mod_parrot
19:46 allison jhorwitz: the general ability to polymorphically substitute any PMC with the right interface for FileHandle is the ultimate goal, and will only take a little longer
19:47 allison (and if that's what you really need, I'll just scrap StringHandle and do that instead)
19:47 jhorwitz if by a little longer you mean on the order of a few days, i can wait for the real deal.  :)
19:47 allison yes, it's on the order of a few days
19:48 jhorwitz then +1 for working on the subclassable FileHandle
19:48 allison I'll be back home and settled tomorrow, and will have the rest of this week to finish that off, so should have it for you before next #parrotsketch
19:48 rurban_ joined #parrotsketch
19:48 jhorwitz works for me.
19:49 Coke Oh, I have a semi-announcement.
19:49 Coke jhorwitz: you all set?
19:49 * jhorwitz yields the floor
19:49 Coke floor.resume()
19:49 Coke .join()?
19:49 * jhorwitz regrets his choice of terminology
19:49 Coke I have some volunteers for releases; we have january allocated.
19:50 Whiteknight ...and march!
19:50 Coke (that's chromatic). I'll make sure we have february locked in before the january release.
19:50 Coke thanks to all who volunteered.
19:50 Coke that's it for me; anyone else?
19:50 particle weekly reminder: https://trac.parrot.org/parrot/wiki/ParrotRoadmap
19:50 particle *lots* of tasks this month
19:51 Coke particle: any leftover tasks from 0.8.2 that didn't make it in, push them down to 0.9.0 as a higher priority?
19:51 particle already done.
19:51 pmichaud I should have pct_loop done today.
19:51 pmichaud and I think we're in very good shape on PCT honors hll
19:51 Coke particle++ # coke sees his name on something. whee.
19:52 Coke particle: "ticket sprint" doesn't mean anything to me.
19:52 allison Coke: a run of closing tickets
19:52 particle aka "bug day"
19:52 particle we've been making steady progress there, i think
19:53 particle do we need to deprecate the runcores/gc/stm?
19:53 particle i think not. others?
19:54 * Coke adds https://trac.parrot.org/parrot/wiki/TicketSprint
19:55 Coke allison: ping.
19:55 allison particle: I'd say it's worth deprecating them. it's only a one month cycle
19:55 particle ok, then, i'll updated DEPRECATED.pod and create tickets
19:55 Coke eliminating assignment syntax for some opcodes is hard.
19:56 Coke Just want to verify that we desire spending the energy (if not now, eventually.)
19:56 particle yeah, that's better left to replacing imcc with pirc
19:56 allison Coke: yeah, not an urgent priority
19:56 particle let's leave DEPRECATED.pod review for another time, this meeting's gone on long enough.
19:56 Coke adios.
19:57 allison ok, thanks all!
19:57 rurban left #parrotsketch
19:58 Coke left #parrotsketch
20:00 jhorwitz left #parrotsketch
20:12 PacoLinux left #parrotsketch
22:02 Whiteknight joined #parrotsketch
22:24 mberends left #parrotsketch
22:37 particle ENOTWEETY
23:02 Whiteknight urg, the meeting today didn't get logged?
23:05 Tene I logged it!
23:12 pmichaud Whiteknight: http://irclog.perlgeek.de/parrotsketch/today
23:17 pmichaud left #parrotsketch
23:43 particle left #parrotsketch

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