RE: class introspection and extention
> From: max demmelbauer [mailto:[EMAIL PROTECTED] [...] > i am new to this list. > i wrote a small web-framework called webtek ( http://max.xaok.org/ > webtek ) in perl 5.8 and try now to port this to perl6 (inspired by Unfortunately I only know very few German words, but webtek looks very interesting. Is (http://max.xaok.org/webtek/wiki) part of webtek? > the speak from juerd at the austrian perl workshop :). but i have Juerd++ > i read the lists and docs and i found some solutions, but none of > this worked for me in pugs... hmm.. If you don't get all your questions answered here after a day or two, then you should ask on the #perl6 IRC channel. (Juerd also uses it.) I put some information about #perl6 in the "Perl 6 Users FAQ": (http://perl.net.au/wiki/Perl_6_Users_FAQ). The developers on #perl6 can also tell you for sure what is implemented and what is working. I'm sure they would be very happy to help you. (By the way, the newest Pugs release is almost ready.) Best regards, Conrad Schneiker http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6 Wiki.) www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)
Re: [perl #38788] make test results
SVN r12936 fails for me while compiling. cc -c -DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.5/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -pipe -I/usr/local/include -DPIC -fPIC -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -mno-accumulate-outgoing-args -Wno-shadow -falign-functions=16-DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -o subproxy.o -I/home/ryan/devel/parrot/include -I/home/ryan/devel/parrot/src/pmc subproxy.c subproxy.pmc: In function `Parrot_SubProxy_invoke': subproxy.pmc:42: error: structure has no member named `root_namespace' subproxy.pmc:42: error: structure has no member named `root_namespace' I also get many, many warnings. Will Coleda via RT wrote: Can you do me a favor and double check against r12926 or later? Regards. [EMAIL PROTECTED] - Wed Mar 22 19:53:28 2006]: I just checked out revision 11994 from SVN and a few of the tests failed (FreeBSD 5.3 I386). The summary is below. I am happy to provide more information if desired (please copy me directly, I am not on the list). Failed 5/229 test scripts, 97.82% okay. 30/4559 subtests failed, 99.34% okay. Failed Test Stat Wstat Total Fail Failed List of Failed -- - t/dynoplibs/dan.t 7 1792 77 100.00% 1-7 t/dynoplibs/myops.t 7 1792 77 100.00% 1-7 t/dynpmc/dynlexpad.t6 1536 66 100.00% 1-6 t/dynpmc/foo.t 8 2048 98 88.89% 1-5 7-9 t/dynpmc/sub.t 2 512 22 100.00% 1-2 (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and 390 subtests skipped. --- Ryan Hinton [EMAIL PROTECTED] -- --- Ryan Hinton [EMAIL PROTECTED]
Re: A question about .begin_eh
[ Note to p6c: This thread is about the proposed and only partially
specified ".begin_eh"/".end_eh" directives that would specify exception
handling as a static property of a range of opcodes in a subroutine,
rather than the current dynamic approach of C etc. I'm
including p6c in case Lisp isn't the only language with potential issues
here. See also docs/pdds/clip/pdd23_exceptions.pod.]
On Mon, Jun 12, 2006 at 08:24:55PM -0400, Bob Rogers wrote:
>From: Chip Salzenberg <[EMAIL PROTECTED]>
>Date: Mon, 12 Jun 2006 06:54:24 -0700
>
>On Sun, Jun 11, 2006 at 11:52:14AM -0400, Bob Rogers wrote:
>>I notice the following paragraph, vintage late May, in
>> pdd23_exceptions.pod:
>>
>> A C<.begin_eh> directive marks the beginning of a span of
>> opcodes which the programmer expects to throw an exception. If
>> an exception occurs in the execution of the given opcode span,
>> Parrot will transfer control to I.
>>
>> I assume this means that you intend to replace the current methodology
>> of searching for an Exception_Handler object on the control stack when
>> an error is thrown with a search through sub metadata.
>
>That's the plan. The upside is that on the non-exceptional case, nothing
> at
>all needs to be done. I just couldn't see the value in making the VM
>allocate and free memory blocks on the control stack, over and over, when
>no exceptions are occurring.
>
> Yes, that's nice. The downside, though, is that you have to do more
> work when it's time to throw, but I agree that this is likely to happen
> less often, at least for most error-handling situations. (There's also
> a load-time cost, I imagine, but it can't be very large.)
I think we're seeing the same thing.
>Unfortunately, this is a step backwards from my perspective, as it is
> already problematic to use Parrot as it exists now to implement ANSI
> Common Lisp error signalling semantics, and any approach based on
> metadata (being static) will make it more so. However, I can still
> implement ANSI semantics using dynamic binding, C, and
> continuations that respect both (which they currently do not), though
> the result won't interoperate with error handling in the rest of Parrot.
{{ Please read the rest of the message before answering this paragraph.
It may be moot. }}
OK, maybe I don't understand CL or your implmentation strategy, but: Aren't
you planning on -compiling- the CL to PIR? When the form that does
exception handling is compiled to PIR, why can't you translate it to (among
other things) a .eh block?
Separately, what do you mean by "respecting" pushaction in the continuation
implementation?
>> How do you envision this interacting with C, e.g.?
> Currently,
>> it is straightforward for find_exception_handler to DTRT WRT other
> control
>> stack entries. Would the metadata also contain information about
>> C and such?
>
>I hadn't decided either way about C. Seems to me that either
>way will work though. Could you spell out a little more of what you see
>as being bad (or harder)?
>
> Actions are dynamic state that must nest properly with respect to error
> handlers. So you have to know how many actions to pop & invoke when
> unwinding the stack before invoking a given error handler. So it seems
> to me that you would also have to lexicalize actions in order to give
> find_exception_handler a clue.
Ah, well, that's fine then. In fact we are going to lexicalize actions, in
the form of an optional I on .begin_eh:
.begin_eh [ I ] [ , I ]
A 'finally' label gets called on the way out of an exception block whether
or not the departure was the result of an exception. To handle the non-
exception case, I imagine PIR will just emit "call my_finally" when it
encounters the ".end_eh" directive.
On the other hand, since static exception blocks haven't been implemented
yet, it's not too late to ditch the whole change as a bad job, if that's
the right decision for Lisp and other languages. Lispers are people too. :-)
> But you can't lexicalize actions completely without removing the ability
> to invoke a closure as a cleanup action!
Not at all. It just makes you emit the call instruction yourself. For
example:
.sub example
.local pmc my_cleanup
my_cleanup =
.begin_eh ,my_finally
# body of subroutine here
.end_eh
.return ()
my_finally:
call my_cleanup
ret
.end
The implications of throwing an exception from a 'finally' label need to be
specified clearly, of course. But once that's done, making sure that
exception handling code calls all the right 'finally' labels in the right
order is a Simple Matter Of Programming.
> Dynamic bindings in particular require runtime dynamic state (namely, the
> saved values), so there still needs to be something on the control stack
> to capture it.
I think the 'finally' feature is pretty much what you need for this.
resumable exceptions
Are Parrot exceptions now, in fact, resumable? If they are, is that important? Is anyone actually resuming execution after exception handlers are called? I think we _can_ keep resumability, but I'm not sure I want us to, and I definitely don't want to bother if no one wants it. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: A question about .begin_eh
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Wed, 14 Jun 2006 12:05:29 -0700
[ Note to p6c: This thread is about the proposed and only partially
specified ".begin_eh"/".end_eh" directives that would specify exception
handling as a static property of a range of opcodes in a subroutine,
rather than the current dynamic approach of C etc. I'm
including p6c in case Lisp isn't the only language with potential issues
here. See also docs/pdds/clip/pdd23_exceptions.pod.]
On Mon, Jun 12, 2006 at 08:24:55PM -0400, Bob Rogers wrote:
>
> . . .
>
>Unfortunately, this is a step backwards from my perspective, as it is
> already problematic to use Parrot as it exists now to implement ANSI
> Common Lisp error signalling semantics, and any approach based on
> metadata (being static) will make it more so. However, I can still
> implement ANSI semantics using dynamic binding, C, and
> continuations that respect both (which they currently do not), though
> the result won't interoperate with error handling in the rest of Parrot.
{{ Please read the rest of the message before answering this paragraph.
It may be moot. }}
In fact, it's central, and meet to be mooted (in the oldest sense of the
word. ;-)
OK, maybe I don't understand CL or your implmentation strategy, but:
Aren't you planning on -compiling- the CL to PIR?
Yes, of course.
When the form that does exception handling is compiled to PIR, why
can't you translate it to (among other things) a .eh block?
CL handlers are functions (typically closures) that are invoked by ERROR
or SIGNAL in order to decide how to handle the condition [1]. The first
handler that effects a nonlocal exit is considered to have handled the
condition. If no handlers bite, and the condition was signalled by
ERROR, then the debugger is entered; otherwise, SIGNAL just returns --
both still at the point the condition was signalled, with its context
intact. Even if the condition is handled somewhere, returning to a .eh
block isn't quite correct, as then the handler body is running in the
handler's bind-time environment, rather than the dynamic environment of
the error.
Essentially, I don't see how to implement a reasonable facsimile of
ANSI semantics without handlers-as-functions.
In fact, I had thought that this was where the "early draft of
exceptions PDD" thread was going last April. So I proposed essentially
the Lisp model on 29-April, but I never heard back, so I assumed that it
was considered too radical. It would certainly cost an instruction or
two more than the current implementation to establish an error handler.
Separately, what do you mean by "respecting" pushaction in the
continuation implementation?
Currently, invoking a continuation will unwind the stack past actions
without invoking them, since the unwinding is implicit in the way
continuations re-establish the control stack. The fix is not difficult,
but neither is it completely straightforward, especially as there are
other related bugs in that code. (There is also the semantic issue of
whether an action should be invoked for a given kind of continuation; I
intend to propose [2] that the action should decide.) So I haven't
tried to fix this one yet because I assume it would be easier to clobber
them all at once when implementing related control stack changes for
dynamic binding [2].
> Actions are dynamic state that must nest properly with respect to error
> handlers. So you have to know how many actions to pop & invoke when
> unwinding the stack before invoking a given error handler. So it seems
> to me that you would also have to lexicalize actions in order to give
> find_exception_handler a clue.
Ah, well, that's fine then. In fact we are going to lexicalize actions, in
the form of an optional I on .begin_eh:
.begin_eh [ I ] [ , I ]
A 'finally' label gets called on the way out of an exception block whether
or not the departure was the result of an exception. To handle the non-
exception case, I imagine PIR will just emit "call my_finally" when it
encounters the ".end_eh" directive.
Sounds good to me. Several questions/thoughts:
1. By "call", do you mean "jsr" (or "bsr" -- I don't grok the
distinction)? I notice that your example below (which I snipped) uses
"ret" at the end of the 'finally' block, but it's not clear how that
translates into a resumption of stack-unwinding.
2. Since the CL features that would use this construct are
independent, I would never need to emit code that uses both. Instead,
it would be either
.begin_eh I
or
.begin_eh ,I
So it might be clearer to have a separate ".begin_finally" and
".end_finally" for the latter. (But of course this is a merely a
trifling question of syntax.)
3. FWIW, the Scheme dynamic-wind feature requires an action to be
invoked when re-entering the context as well as leaving it
Perl++ Wiki (was: RE: Perl++ Wikicosm (was: OT: wiki engine architecture))
Matt Todd wrote:
> [Lots of stuff]
General comment: It's much easier to comprehend posts in mail lists or
reading through the archives if you quote something of what you're
responding to.
> Now, to the requirements talk: how important is the availability of
> revision history in this bare-bones wiki?
Seems important to me, but I'm not a wiki expert.
> What kind of authorship and administration
> would
> you (the granter or whomever, really) prefer? Every writer must have
> an account? Are there any accounts other than an administrator? I
> won't even get into admins, moderators, readers, editors, etc.
IMHO, it's good social sanity check to require author accounts.
> Text formatting is
> important
> (if relatively easy to hook up), but is being discussed,
> implementation-wise.
An extension of Perl6 POD would be interesting. As an option. And
maybe crazy.
> How
> about RSS feeds (which is usually more appropriate for versioned
> pages, et al, but is useful even for recently-updated pages)?
Don't know.
I like seeing Pugs svn commits on comp.perl6.language. Probably
doesn't scale well in the long run, but it seems to be a very good
idea to begin with.
> Do you
> want it to work with the concept of pages/topics or is there another
> way you want to represent the data?
Seems to work well enough for documentation purposes.
It would be very cool if the Pugs svn doc tree was mirrored in a
subsection of (the) Perl++ (Wiki), and could be {authored, edited}
through Perl++. I think that {simplification, convenience} would
greatly expand participation in generating Perl 6 documentation.
Interesting side note: "perl++" on Google shows this link as the 3rd
hit: (www.nntp.perl.org/group/perl.perl6.users).
Later on, a mechanism that made it feasible for smart IDEs to find
relevant Perl 6 Cookbook descriptions in Perl++ and lift code samples
would be very cool.
> What kind of categorization do
> you
> want to support?
Not sure I understand question.
> What kind of control do you want over the visual
> aspects (CSS, HTML, et al)? Did you have something in mind other
> than
> a web administration interface?
Not at the moment.
> What kind of moderation privileges
> would you like?
Omnipotent and clairvoyant. :-) But I'd settle for the minimum needed
to thwart religious editing wars, spamming, and so on.
> What basic actions do you want to perform for a page
> (or whatever)?
Don't know.
How about whatever twiki does? It's perl-ish and appears to be a
pretty substantial offering:
(http://en.wikipedia.org/wiki/Comparison_of_wiki_software).
> That's a lot to answer, I know.
I'm sure others can provide better answers.
Just $perl6.say # Needs work. JAPH needs to be updated. :-)
Best regards,
Conrad Schneiker
http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)
www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)
