Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2008-10-28

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

All times shown according to UTC.

Time Nick Message
05:49 TimToady joined #parrotsketch
10:58 tewk_ joined #parrotsketch
13:14 particle joined #parrotsketch
15:48 davidfetter joined #parrotsketch
17:31 allison joined #parrotsketch
17:39 pmichaud joined #parrotsketch
17:48 rdice joined #parrotsketch
18:14 cotto joined #parrotsketch
18:16 cjfields joined #parrotsketch
18:21 masak joined #parrotsketch
18:23 NotFound joined #parrotsketch
18:23 jhorwitz joined #parrotsketch
18:24 moritz joined #parrotsketch
18:26 kj joined #parrotsketch
18:27 Croke joined #parrotsketch
18:28 chromatic joined #parrotsketch
18:30 pmichaud hello.
18:30 NotFound H
18:30 kj hiya
18:30 moritz hi
18:30 jhorwitz yo
18:30 chromatic greetz
18:30 Tene OHAI
18:30 cotto ohio
18:30 masak salut
18:31 spinclad .oO( ho from peanut gallery )
18:31 chromatic Let's go in order.
18:31 chromatic Though I see no allison.
18:31 chromatic I... fixed some bugs.
18:31 chromatic I'm working on some segfaults, and hope to clear those up in the next day.
18:31 allison hi
18:32 particle hi-o
18:32 davidfetter hai
18:32 chromatic I have a patch against Test::More that's almost finished.  It may require some changes in other PIR tests, because it's more accurate now.
18:32 chromatic That's it.
18:32 chromatic allison?
18:32 allison - Started the I/O branch.
18:32 allison - Did a code review of the I/O subsystem and expanded the I/O milestone tasklist with more details. (http://www.parrot.org/wiki/io-tasklist)
18:32 allison - Finished an initial draft of the FileHandle PMC, and some of the core C files for the subsystem.
18:32 allison - Worked on closing more MMD tickets.
18:32 allison EOR
18:33 chromatic Croke?
18:33 Croke started to work on partcl, sidetracked by a GC bug:
18:33 Croke and then 2 more. opened tickets for all three. no actual progress, however.
18:33 Croke EOR
18:34 chromatic davidfetter?
18:34 davidfetter still too lazy
18:34 davidfetter EOR :(
18:35 chromatic japhb?
18:35 japhb chromatic: nr
18:35 tewk_ vi
18:36 PacoLinux joined #parrotsketch
18:36 chromatic jhorwitz?
18:36 japhb (catching me actually at my desk in this time period is a fluke, by the way -- I'm only around for logs and questions)
18:36 jhorwitz helped chromatic++ debug segfault with "use Foo::Bar", which unblocked mod_perl6.
18:36 jhorwitz partial implementation of mod_perl6 method handlers, but blocking because i can't pass flattened args to a sub in rakudo yet.
18:36 jhorwitz writing pure-perl6 versions of Apache::Const, Apache::RequestRec, etc.
18:36 jhorwitz brainstorming for a tutorial on writing an HLL layer for mod_parrot
18:36 jhorwitz EOR
18:37 chromatic kj?
18:37 kj == work on PIRC
18:37 kj * integrated the macro processor into pirc lexer (no separate specification)
18:37 kj * integrated the heredoc preprocessor into pirc executable (still separate specification)
18:37 kj * works very nicely
18:37 kj == other
18:37 kj <<EOF>>
18:38 chromatic masak?
18:38 masak - haven't done anything to decrease ticket count during the past week
18:38 masak - increased it a bit, though
18:38 masak - went into a Rakudo bug hunt/reporting spree during weekend
18:38 masak - also failed to build Parrot and reported that, #60178
18:38 masak - so far fails only on my machine, so I will investigate further
18:38 masak EOR
18:39 chromatic moritz?
18:39 moritz fighting troubles with the server on which the #perl6 evalbot runs on, no time for much more.
18:39 moritz EOR.
18:39 chromatic NotFound?
18:39 NotFound - Some fixing and cleaning
18:39 NotFound - Working in some EH problems
18:39 NotFound - A question about that
18:40 NotFound EOR
18:40 chromatic particle?
18:40 particle ~ attended gsoc mentor summit. it was of great benefit. i'll write up a use.perl post about it when time permits.
18:40 particle ~ all my tuits since the release are now devoted to the parrot developer summit
18:40 particle ~ looking forward to it, an to someday getting back to hacking
18:40 particle .end
18:41 chromatic pmichaud?
18:41 pmichaud ** Rakudo spectest_regression: 206 files, 4433 passing, 2 failing
18:41 pmichaud == Parrot stuff
18:41 pmichaud : started new 'lex' branch to work on new lexicals implementation
18:41 pmichaud : eliminated the Closure PMC -- all Subs can have outers
18:41 pmichaud : implemented capture_lex opcode, updated newclosure opcode
18:41 pmichaud : currently 16 failing core tests, most due to needing "autoclose" semantics
18:41 pmichaud : two options:
18:41 pmichaud --> 1. eliminate autoclose from Parrot entirely (and tests)
18:41 pmichaud --> 2. design sane autoclose semantics
18:41 pmichaud : I'm currently working on #2 in the branch
18:41 pmichaud : Found/fixed a number of issues with adding/removing opcodes
18:41 pmichaud : Added various comments to tickets and discussions
18:41 pmichaud == Rakudo stuff
18:41 pmichaud : Commented and provided notes on lots of tickets and patches
18:41 pmichaud EOR
18:42 chromatic Tene?
18:42 Tene I have negligible memory of the past week.  I don't see any commits in the repo from me, so I don't think I did anything.
18:42 Tene EOR, I guess
18:42 chromatic tewk_?
18:42 tewk_ * Fixed consting of strings in the nci_info struct.
18:42 tewk_ * The only jitted NCI failures left involve t/pmc/threads.t
18:42 tewk_ * Going to try to ncigen parrot headers, haven't done that yet.
18:42 tewk_ * Going to look at the IO branch, I like doing IO work, I don't know why.
18:42 tewk_ EOR
18:42 chromatic Did I miss anyone (besides cotto, who had no report)?
18:43 chromatic Question time.
18:43 chromatic NotFound, go ahead.
18:43 NotFound RT#60166
18:44 NotFound Some opcodes use throw_from_c_args, for convenience of the _args part.
18:44 NotFound Is cretaing the function Parrot_ex_throw_from_op_args a correct solution?
18:45 NotFound creating
18:45 chromatic Seems sane to me.
18:45 Tene I endorse it.
18:46 allison well, that's for creating an exception from C arguments
18:47 chromatic It seems like there are two behaviors.
18:47 allison (going back and reading the ticket)
18:47 NotFound allison: yes, that is the problem. When used from an opcode, it enters a new runloop for no benefit.
18:47 chromatic One is which runloop to use to dispatch the exception and the other is how you pass arguments to it.
18:47 allison on the exact subject of the ticket, exception handling isn't supposed to unwind the stack
18:48 pmichaud the notion of "unwind stack" bothers me.
18:48 pmichaud what allison just said.
18:48 pmichaud there's an assumption that activating an exception handler should remove it from the list of handlers, and that's not true
18:49 pmichaud i.e., I'd claim that the code in the original is wrong.
18:49 NotFound The problem in that case is that it enters a new runloop from C, growing the C stack.
18:49 pmichaud (it's current practice, but not current design)
18:49 allison NotFound: yes, that's expected
18:49 NotFound allison: but no need to do that from an opcode.
18:49 pmichaud as far as entering a new runloop from C, that sounds more like a different ticket.
18:50 pmichaud (looking up that different ticket now)
18:50 allison (pulling up the code for find_method)
18:51 NotFound find_method is just an example, a lot of opcodes does the same
18:51 particle pmichaud: the 'inferior runloop' ticket?
18:52 pmichaud particle -- the one I posted an update to last week.
18:52 pmichaud (rt is very slow today)
18:53 NotFound allison: here are yesterday's tests: http://nopaste.snit.ch/14406
18:54 pmichaud RT #59778
18:54 allison NotFound: okay, I see where you're going now (after poking through the code)
18:56 Croke (inferior runloop) another IR ticket at #57088, though it's a different symptom.
18:56 allison NotFound: okay, let's add 'Parrot_ex_throw_from_op_args'
18:57 NotFound This is not a general solution for inner runloops problems, is for some particular cases.
18:57 allison NotFound: abstract the exception building code from 'Parrot_ex_throw_from_c_args' into a separate function
18:57 allison yes, this isn't about runloop problems
18:57 allison it's just a matter of using the appropriate function in the appropriate place
18:58 allison the 'throw_from_op' variants return an opcode_t
18:58 allison allowing for clean continuation of the runloop
18:58 NotFound allison: ok, i have it almost ready and applied to the majority of opcodes, will finish and commit it today.
18:59 NotFound EOQ
18:59 pmichaud my guess is that Parrot_ex_throw_from_op_args doesn't completely resolve the stated problem in RT#60166, though.
19:00 pmichaud each iteration of the loop is adding another exception handler that is never reclaimed.
19:00 pmichaud (i.e., memory leak)
19:00 allison pmichaud: yes, that is a problem in the code example
19:00 NotFound pmichaud: this is an ortogonal problem IMO
19:01 pmichaud NotFound: I agree it's orthogonal, but it's also the one stated in the ticket title.
19:01 allison and, it's not a problem of the same size as it used to be
19:01 allison since exception handlers are now local, they will all be cleaned up on scope exit
19:01 pmichaud fair enough.  I just think we need a note somewhere that says "this is not the way to do this."
19:01 NotFound pmichaud: yes, but I think it will be easier to analyse after the change.
19:01 allison (so, we've at least contained the damage of poor coding practices)
19:02 allison yes, agreed, that should go in a tutorial
19:03 particle it should go in the PDD
19:03 particle *AND* a tutorial
19:04 allison well, there are contexts where you *want* to create a new exception handler on every iteration through the loop
19:04 allison this is more about usage
19:04 allison and understanding the consequences of using particular features
19:05 pmichaud imo, it's that most of us have assumed that invoking an exception handler causes it to be removed from the list of handlers, which is not the case.
19:05 allison pmichaud: it used to be the case
19:05 pmichaud correct.
19:06 pmichaud we need to update the docs to indicate the correct usage, and provide some examples, and convert existing code to the correct usage
19:06 pmichaud right now I'm not entirely certain what the correct PIR would be for creating an exception handler on every iteration through a loop
19:06 allison it was still the case when the exceptions branch was merged in, I'd have to look at the code to see what it's doing now
19:07 NotFound What I do in pirric runloop is creating the EH one time, and creating again when handling a control flow exception. I'm not sure is a correct way.
19:08 pmichaud that creates a new handler on each exception, as opposed to each iteration.
19:08 Tene allison: it's still behaving the same unless a type or severity filter is set.
19:08 pmichaud (in current implementation)
19:09 allison Tene: we should probably be consistent and either always remove it or never remove it
19:09 Tene I haven't removed the "only invoke once" code yet because I haven't felt up to tryint o track down everything that can currently break.
19:09 allison Tene: we're working towards the "never remove" direction, but that will involve more code changes
19:10 Tene I left it at "only invoke once" for the case where no filters are set to avoid breaking old code.
19:10 pmichaud I'm in favor of never remove
19:10 pmichaud at least, never remove automatically
19:10 pmichaud that *is* in fact what is happening now.  :-)
19:10 allison pmichaud: yes, that's what's currently spec'd, but not what's currently implemented (last I checked)
19:10 Tene I can nopaste the relevant patch for you if someone wants to work on it.
19:10 pmichaud what's currently implemented is that the handler is disabled (but not removed)
19:10 allison Tene: make it an RT ticket
19:10 pmichaud (if I read the code correctly.)
19:11 allison pmichaud: yes, that's accurate
19:11 allison pmichaud: it was a cheap way of mimicing the old behavior
19:11 pmichaud so really what we're talking about is turning off "auto-disable"
19:11 allison pmichaud: yes, the auto-disable feature was only put in place to support legacy exception code
19:12 pmichaud allison: correct.  So, we ought to be able to go ahead and move existing code to the "assume the handler is already there" without any code changes
19:12 pmichaud sorry, that was unclear
19:12 pmichaud we should be able to migrate legacy PIR code to work assuming the handler remains present without having to change the underlying exception system
19:12 allison pmichaud: yeah, should be possible
19:12 NotFound A .get_results variant that removes the handler can be useful.
19:13 allison pmicaud: the main thing it involves is having exception handlers check to see if the exception they're getting is one they can handle, and rethrowing if they can't
19:13 pmichaud I don't think we have any legacy code that depends on this
19:13 allison it's basically a mini preamble to every handler
19:14 Tene adding a type or severity filter should be more appropriate than rethrowing.
19:14 Tene That's what the 'can_handle' check is for.
19:14 pmichaud what we're really looking at is any exception handling code that assumes the handler is automatically pop_eh'd should explicitly do a pop_eh.
19:14 allison pmichaud: the problems I was getting before I added auto-disable were segfaults from exception handlers that were trying to handle exceptions they didn't know what to do with
19:14 Croke can we define our own exception types at runtime, or declare that we handle only a specific exception class?
19:15 NotFound But in label handler there is no way to add a can_handle
19:15 Tene the other problem is if code in an EH throws an exception.
19:15 allison pmichaud: that is, the first handler wouldn't be removed, and another exception would be thrown and passed to the first handler again
19:15 Croke (if not, then we're still going to need to catch and rethrow)
19:15 pmichaud allison:  correct -- however, we can change the legacy code so that the first handler is removed (explicitly, not automatically)
19:16 allison pmichaud: yes, that's true, the handler could do 'pop_eh' as a quick fix
19:16 pmichaud to date there's been no official word that this is in fact what handlers are supposed to do.
19:16 allison pmichaud: In general, handlers shouldn't do 'pop_eh'
19:16 allison handlers should just handle the exception
19:16 chromatic How would a handler know which EH is on top of the stack?
19:16 Tene exactly
19:16 allison the calling code is what decides the scope of the handler
19:17 NotFound Croke: you can inherit from ExceptionHandler and add a can_handle method
19:17 allison think of it like a 'try' block
19:17 pmichaud ....then how should handlers get removed (in the case of creating a handler for each iteration, for example)
19:17 allison push_eh is the start of the 'try' block, and 'pop_eh' is the end of the block
19:17 Tene Croke: propose an API for setting class-based filters and I'll implement it.
19:18 Tene Croke: if you can provide some example PIR, even better.
19:18 Tene I've heard several times that we want to support that as well.
19:18 Croke Tene: very low on my list of priorities.
19:19 Tene Croke: would .handle_classes work for you?
19:19 allison pmichaud: I suppose what we're really missing is scopes smaller than a subroutine
19:19 pmichaud I understand that push_eh is conceptually the start of a 'try' block, and pop_eh is the end of the block.  But when/where should pop_eh be done if a handler block is invoked?
19:19 allison pmichaud: in a real 'try' block, the handler would be cleared at the close of the block scope
19:19 allison (because handlers are always stored in a scope)
19:20 allison pmichaud: but here, they won't be cleared until the close of the subroutine scope
19:20 pmichaud so, if we're looping over a try statement, we'd end up clearing all of the handlers when the outer loop exits?
19:20 allison pmichaud: I mean, ideally, the 'pop_eh' opcode goes away, and handlers are just cleared on scope exit
19:21 allison pmichaud: but that does mean refining our implementation of scope
19:21 allison pmichaud: (which we probably need to do anyway, but perhaps not before 1.0)
19:22 pmichaud okay.  I'll leave it here, with a request that we see the "best practice" for creating handlers within a loop.
19:22 pmichaud s/see/publish/
19:22 NotFound So a way to avoid this problems in pir is to enclose the conceptual try/catch block in an inner sub?
19:22 allison pmichaud: looping over a try block would (ideally) clear the handler each time through the loop, since 'try' is its own scope
19:22 pmichaud I have my own thought on this at the moment, which I can publish to the list.
19:22 spinclad (next iteration, EH becomes inaccessible when new EH bound to its name: collect it then?)
19:22 pmichaud allison: would 'try' have to be its own scope in every language?
19:23 pmichaud allison: (yes, it's that way in Perl 6, but I can imagine languages where 'try' doesn't modify scope.)
19:23 allison pmichaud: not necessarily, ('try' its own scope) Parrot would just provide EH features and scope features. Different HLLs can combine them any way they want.
19:24 allison that is, if you want try to be scoped to the whole subroutine, just don't wrap it in a smaller scope
19:24 pmichaud I'm simply talking about the case where try doesn't introduce a scope that the handler is attached to (and would be cleared from).
19:25 allison spinclad: actually, it becomes inaccessible at the end of scope, so GC'd at the next sweep
19:25 allison NotFound: yes, enclosing a try/catch block in a sub would work for now, but a bit expensive for long-term
19:25 spinclad (good)
19:26 allison pmichaud: the two are orthogonal features
19:26 pmichaud spinclad: notice that it's inaccessible at end of sub scope, though, not when the new EH is created
19:26 allison pmichaud: push_eh (or whatever), simply adds an exception handler to the current scope, whatever that scope is
19:26 spinclad (end of scope: end of sub, then, not end of try or loop scope)
19:27 pmichaud allison: and if try is being iterated 1e6 times within the current scope, we end up with 1e6 handlers?
19:27 allison pmichaud: languages that want a specific scope for 'try' emit the code for marking off a scope (which is completely hypothetical)
19:28 allison pmichaud: yes, because you could be creating a completely different handler each time, based on code within the loop
19:28 NotFound A quick test with RT#60166 example shows that with a pop_eh it does not leak (or at least, it leaks a lot less)
19:28 allison pmicaud: that is, the handler could be eval'd code
19:28 allison but, you can always put the 'try' block outside the loop
19:28 pmichaud allison: that would be different semantics, however.
19:29 allison pmichaud: yes, it would resume after the loop
19:29 particle at this point, is seems more appropriate for the mailing list.
19:29 particle unless there are no other questions
19:30 pmichaud NotFound: that's what I expected, and what I'm likely to write to the list (i.e., always do a pop_eh for every push_eh)
19:30 allison yes, mailing list it is
19:30 allison (this is largely hypothetical futures we're talking at this point)
19:30 pmichaud (except that it occurs in reality in #60166.)
19:30 NotFound However, with a .get_results added it leaks a lot.
19:31 allison pmichaud: yes, the immediate answer is "don't do that", but there are definitely some more refined tools we could give HLL developers in the future
19:32 pmichaud allison:  I'm simply saying that the immediate answer ought to be "don't do it that way, do it this other way instead"
19:32 pmichaud where "this other way" isn't well defined yet.
19:32 pmichaud or "this other way" could be "...and Parrot doesn't support that yet."
19:33 pmichaud iterating over exception handlers is very common and very important at the moment:  next, last, redo
19:33 pmichaud so it's not even completely hypothetical.
19:34 pmichaud in fact, I'll say it's not hypothetical at all.
19:34 allison pmichaud: in theory, what should happen now is that the successfully handled exception should resume, and go on to the 'pop_eh', which is the next instruction after the one that threw the exception
19:34 pmichaud "and go on to the pop_eh" is effectively the same as saying that the handler resumes at the pop_eh, yes?
19:35 pmichaud i.e., within a Parrot sub, the handler could fall-through to the pop_eh?
19:35 chromatic I'm not sure that can work for control flow exceptions.
19:35 allison pmichaud: effectively, but if there was another statement between the one that threw an exception handler and the 'pop_eh' it would resume at that one
19:36 allison pmichaud: if the handler *doesn't* resume, or continues at some other location, they, yes, it should take responsibility for the 'pop_eh' it skipped
19:36 allison s/they/then/
19:36 pmichaud I guess what I'm saying is that handlers should not assume that they are automatically removed from the list.  Whatever creates the handler should also make sure the handler is removed (if not being automaticallyremoved by scope exit)
19:36 pmichaud rephrasing
19:36 pmichaud scopes that create handlers should not assume that the handler is automatically removed when it is invoked.
19:36 allison pmichaud: yes, entirely agreed
19:37 pmichaud the scope that creates the handler should make sure that the handler is effectively removed, e.g. in an iteration
19:37 pmichaud if that's the case, then I can write an example for that and we can publish it.
19:37 allison wonderful, thanks!
19:37 pmichaud and we can start moving existing code to follow that guideline
19:38 allison we may have to do it in a short-lived branch
19:38 allison that is, the current 'auto-disable' feature may interfere with the implementation of how it should work
19:39 pmichaud I don't think it will.
19:39 pmichaud auto-disable is simply making it "appear" that the handler has been removed -- in reality it's still there.  Explicitly removing it won't change that.
19:39 allison I'm thinking that pop_eh currently skips disabled handlers
19:39 pmichaud it does not.
19:39 allison ok, good
19:39 pmichaud I was very surprised to see that.
19:39 allison then no problems
19:39 allison (it probably should have)
19:40 pmichaud yes, but that's also why I know that we have a leak.  :-)
19:40 allison (but, it's convenient that it didn't)
19:40 pmichaud (within a loop)
19:40 Tene allison: if it skipped disabled handlers, then pop_eh would behave differently based on whether there was an exception or not.
19:40 Tene push_eh;...maybe_throw_exception;...pop_eh;
19:41 allison given that the auto-disable feature was put in place to support legacy code, I'm surprised that popping a disabled handler didn't break legacy code (since they would have expected it to be completely removed already)
19:41 Tene Hm.
19:41 pmichaud as I said, I don't think there are many places that make use of pop_eh in that way.
19:41 allison but then, our use of exceptions wasn't all that extensive before, since they didn't really work
19:41 spinclad push_eh; ... maybe_throw_exception; maybe_resume_here: ... pop_eh;
19:42 pmichaud it's rare to have push_eh in a loop to begin with.
19:42 Croke make use of pop_eh in which way, now?
19:42 Tene spinclad: no need for a label, just invoke the return continuation.
19:42 pmichaud Croke: this only matters in the case of doing multiple push_eh/pop_eh's in a scope
19:42 pmichaud Croke: and I don't think there are many instances of that
19:42 spinclad (right, just naming a place)
19:43 allison spinclad: yes, that the general code order
19:44 allison wrapping up: pmichaud has volunteered to put together a code example of good exception use, and we'll gradually migrate legacy exception code to take responsibility for clearing exception handlers when they're no longer needed
19:44 spinclad (it's the juggling maybe's with pop_eh's i'm unsure of.  if those that matter understand them, good enough)
19:44 pmichaud we'd have to have a case where we do two push_eh instructions, then the second handler is invoked (disabling it, assuming removal), and we later do a pop_eh to remove the first one, and then another exception triggers that.
19:44 pmichaud in other words, it'd be pretty rare.
19:45 pmichaud and that's why we didn't/wouldn't see much breakage from popping a disabled handler, because it probably doesn't happen in practice.
19:46 masak left #parrotsketch
19:46 pmichaud I'll put together the example, post to the list, and also a request for official interface to re-enable a handler (to be documented in pdd23)
19:46 Tene wait, re-enable?  we're sticking with auto-disable?
19:47 allison to re-enable a handler? after the transition, we'll stop auto-disabling
19:47 pmichaud oh, that's correct.
19:47 pmichaud never mind.
19:47 allison (that is, as soon as we can get the tests to pass without auto-disabling)
19:47 pmichaud I'll keep testing that.
19:47 pmichaud I suspect I can have many/most of these cleaned up in just a couple of hours.
19:47 Croke Welp, I'm just as confused about what this means for writing PIR as I was before. =-)
19:48 pmichaud Croke: my example should make it clear.
19:48 Croke I look forward to your email.
19:48 allison IIRC PGE was the biggest source of failures without auto-disabling
19:48 pmichaud right, and PGE is one of the easiest to fix.  :-)
19:48 allison PGE is the biggest user of exceptions in general, so it's a good test case
19:48 Tene particle was talking earlier about a need for a PDS attendees page.
19:48 pmichaud especially since I now know the "correct" approach.
19:48 pmichaud (PDS attendees page)  I'd say just create one.  :-)
19:49 pmichaud it's a wiki.
19:49 Tene If it was THAT easy, ANYONE could do it.
19:49 allison (PDS attendees page) sounds useful, go for it
19:50 pmichaud do we need a deprecation cycle for auto-disable?
19:50 allison pmichaud: yes, just in case outside languages are using it
19:51 pmichaud okay.  I'll make sure it gets into DEPRECATED then.
19:52 pmichaud I'm done.
19:52 NotFound BTW, what is the section in DEPRECATED where PARROT_API functions must go?
19:53 allison NotFound: we haven't been subjecting C functions to the same DEPRECATION requirements as user facing code
19:54 allison NotFound: Possibly we should
19:54 allison s/possibly/probably/
19:54 allison certainly we will after 1.0
19:54 allison so, it's a good habit to start
19:54 chromatic Only if they're marked with PARROT_API.
19:55 chromatic (and we mark too many with PARROT_API)
19:55 particle the three functions in core not marked with PARROT_API are exempt.
19:55 NotFound There is a Functions subsection inside Parrot Compiler Tools section. Is this correct, or is a typo in the heading?
19:56 pmichaud typo somewhere -- possibly a missing =head1
19:57 chromatic donde es mi =cabesa?
19:57 NotFound chromatic: cabeza
19:57 spinclad está
19:57 pmichaud I'd change the =head2 to =head1 for now.
19:58 Croke (outside languages) there are, like, 2 of us. =-)
19:59 allison NotFound: yes, we've randomly listed some functions in particular subsystems, but haven't had a top-level for all deprecated functions. in favor of promoting the header
20:00 allison Croke: yes, but also includes any external users of Parrot
20:04 chromatic Are there any other questions?
20:04 Croke Thanks for providing a release which partcl was able to target.
20:05 chromatic We'll call it a week then.  CLOSE MORE TICKETS (especially Coke's segfaults)
20:16 Croke left #parrotsketch
20:16 jhorwitz left #parrotsketch
20:17 chromatic left #parrotsketch
20:18 cotto left #parrotsketch
20:36 NotFound left #parrotsketch
21:06 PacoLinux left #parrotsketch

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