You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/04/04 03:05:47 UTC
adding usage to all XS wrappers
[moving to the dev list]
Nick Tonkin wrote:
[...]
> Working on finishing the rewrite of porting.pod. In the above example, the
> error mesage emitted is:
>
> [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] p is not of type
> APR::Pool at /home/debug/www/_perl/NPT/MyTest.pm line 9.
>
> This would be much improved if it said:
>
> [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] Usage:
> APR::URI->parse($pool, $uri): first argument is not of type APR::Pool at
> /home/debug/www/_perl/NPT/MyTest.pm line 9.
Agreed. However this is not simple todo, because parse() is implemented as a
thin wrapper mpxs_ and its args are automatically converted and the error is
generated by the conversion macros. These have no clue about the usage patterns.
This is an issue with all mpxs_ wrappers which explicitly specify its
arguments, rather than use ... (e.g. see mpxs_Apache__RequestRec_print in
xs/Apache/RequestIO/Apache__RequestIO.h) or write a full XS wrapper (e.g.
MPXS_Apache__Directive_lookup in xs/Apache/Directive/Apache__Directive.h). The
first case works only for a few APIs, the second case requires a fully blown
XS code.
Though I agree that the user experience is the most important thing, so
eventually we might rewrite these thin wrappers to less-thin ones, with
explicit conversion code and error checking, enabling usage printing. Or even
better improve WrapXS to allow usage patterns which will be printed in the
case of the error, in addition to the errors whatever they are.
I think this can be implemented as a new field in the map files and used in
case of errors. How does it sound?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: adding usage to all XS wrappers
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Fri, 4 Apr 2003, Stas Bekman wrote:
> Nick Tonkin wrote:
> > On Fri, 4 Apr 2003, Stas Bekman wrote:
> >
> >
> >>[moving to the dev list]
> >>
> >>Nick Tonkin wrote:
> >>[...]
> >> > Working on finishing the rewrite of porting.pod. In the above example, the
> >> > error mesage emitted is:
> >> >
> >> > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] p is not of type
> >> > APR::Pool at /home/debug/www/_perl/NPT/MyTest.pm line 9.
> >> >
> >> > This would be much improved if it said:
> >> >
> >> > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] Usage:
> >> > APR::URI->parse($pool, $uri): first argument is not of type APR::Pool at
> >> > /home/debug/www/_perl/NPT/MyTest.pm line 9.
> >>
> >>Agreed. However this is not simple todo, because parse() is implemented as a
> >>thin wrapper mpxs_ and its args are automatically converted and the error is
> >>generated by the conversion macros. These have no clue about the usage patterns.
> >>
> >>This is an issue with all mpxs_ wrappers which explicitly specify its
> >>arguments, rather than use ... (e.g. see mpxs_Apache__RequestRec_print in
> >>xs/Apache/RequestIO/Apache__RequestIO.h) or write a full XS wrapper (e.g.
> >>MPXS_Apache__Directive_lookup in xs/Apache/Directive/Apache__Directive.h). The
> >>first case works only for a few APIs, the second case requires a fully blown
> >>XS code.
> >>
> >>Though I agree that the user experience is the most important thing, so
> >>eventually we might rewrite these thin wrappers to less-thin ones, with
> >>explicit conversion code and error checking, enabling usage printing. Or even
> >>better improve WrapXS to allow usage patterns which will be printed in the
> >>case of the error, in addition to the errors whatever they are.
> >>
> >>I think this can be implemented as a new field in the map files and used in
> >>case of errors. How does it sound?
> >
> >
> > I'm not sure how that is all implemented, but it sounds like a standard error
> > message component consisting of a usage pattern would be a Good Thing.
> > It would be a string, right? Like "Usage: APR::URI->parse($pool, $uri)" or
> > similar?
>
> A string yes, but how to plug it is not trivial. Unless someone has a cool
> idea how to implement it, I'll the issue to the STATUS file to be resolved in
> the future.
>
> > It would just be important to make sure that the error message regarding usage
> > was only emitted when the error is actually caused by bad usage!
>
> Certainly, just like other Usage: messages we have for selected xs subs.
>
> > (See the recent
> > patch to TT2 improving handling of parse errors.)
>
> Dunno what you are talking about, URL?
Not important based on your answer above ...
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: adding usage to all XS wrappers
Posted by Stas Bekman <st...@stason.org>.
Nick Tonkin wrote:
> On Fri, 4 Apr 2003, Stas Bekman wrote:
>
>
>>[moving to the dev list]
>>
>>Nick Tonkin wrote:
>>[...]
>> > Working on finishing the rewrite of porting.pod. In the above example, the
>> > error mesage emitted is:
>> >
>> > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] p is not of type
>> > APR::Pool at /home/debug/www/_perl/NPT/MyTest.pm line 9.
>> >
>> > This would be much improved if it said:
>> >
>> > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] Usage:
>> > APR::URI->parse($pool, $uri): first argument is not of type APR::Pool at
>> > /home/debug/www/_perl/NPT/MyTest.pm line 9.
>>
>>Agreed. However this is not simple todo, because parse() is implemented as a
>>thin wrapper mpxs_ and its args are automatically converted and the error is
>>generated by the conversion macros. These have no clue about the usage patterns.
>>
>>This is an issue with all mpxs_ wrappers which explicitly specify its
>>arguments, rather than use ... (e.g. see mpxs_Apache__RequestRec_print in
>>xs/Apache/RequestIO/Apache__RequestIO.h) or write a full XS wrapper (e.g.
>>MPXS_Apache__Directive_lookup in xs/Apache/Directive/Apache__Directive.h). The
>>first case works only for a few APIs, the second case requires a fully blown
>>XS code.
>>
>>Though I agree that the user experience is the most important thing, so
>>eventually we might rewrite these thin wrappers to less-thin ones, with
>>explicit conversion code and error checking, enabling usage printing. Or even
>>better improve WrapXS to allow usage patterns which will be printed in the
>>case of the error, in addition to the errors whatever they are.
>>
>>I think this can be implemented as a new field in the map files and used in
>>case of errors. How does it sound?
>
>
> I'm not sure how that is all implemented, but it sounds like a standard error
> message component consisting of a usage pattern would be a Good Thing.
> It would be a string, right? Like "Usage: APR::URI->parse($pool, $uri)" or
> similar?
A string yes, but how to plug it is not trivial. Unless someone has a cool
idea how to implement it, I'll the issue to the STATUS file to be resolved in
the future.
> It would just be important to make sure that the error message regarding usage
> was only emitted when the error is actually caused by bad usage!
Certainly, just like other Usage: messages we have for selected xs subs.
> (See the recent
> patch to TT2 improving handling of parse errors.)
Dunno what you are talking about, URL?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: adding usage to all XS wrappers
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Fri, 4 Apr 2003, Stas Bekman wrote:
> [moving to the dev list]
>
> Nick Tonkin wrote:
> [...]
> > Working on finishing the rewrite of porting.pod. In the above example, the
> > error mesage emitted is:
> >
> > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] p is not of type
> > APR::Pool at /home/debug/www/_perl/NPT/MyTest.pm line 9.
> >
> > This would be much improved if it said:
> >
> > [Thu Apr 03 06:43:24 2003] [error] [client 192.168.0.33] Usage:
> > APR::URI->parse($pool, $uri): first argument is not of type APR::Pool at
> > /home/debug/www/_perl/NPT/MyTest.pm line 9.
>
> Agreed. However this is not simple todo, because parse() is implemented as a
> thin wrapper mpxs_ and its args are automatically converted and the error is
> generated by the conversion macros. These have no clue about the usage patterns.
>
> This is an issue with all mpxs_ wrappers which explicitly specify its
> arguments, rather than use ... (e.g. see mpxs_Apache__RequestRec_print in
> xs/Apache/RequestIO/Apache__RequestIO.h) or write a full XS wrapper (e.g.
> MPXS_Apache__Directive_lookup in xs/Apache/Directive/Apache__Directive.h). The
> first case works only for a few APIs, the second case requires a fully blown
> XS code.
>
> Though I agree that the user experience is the most important thing, so
> eventually we might rewrite these thin wrappers to less-thin ones, with
> explicit conversion code and error checking, enabling usage printing. Or even
> better improve WrapXS to allow usage patterns which will be printed in the
> case of the error, in addition to the errors whatever they are.
>
> I think this can be implemented as a new field in the map files and used in
> case of errors. How does it sound?
I'm not sure how that is all implemented, but it sounds like a standard error
message component consisting of a usage pattern would be a Good Thing.
It would be a string, right? Like "Usage: APR::URI->parse($pool, $uri)" or
similar?
It would just be important to make sure that the error message regarding usage
was only emitted when the error is actually caused by bad usage! (See the recent
patch to TT2 improving handling of parse errors.)
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org