Re: as long as we are discussing 'nice to have's...
On Monday 23 July 2001 14:05, Dave Storrs wrote: > No, I do not mean something like Devel::DProf; that is a > module. I mean something that is in the core binary, the same way that > the perl debugger is in the core binary. Except that the perl debugger is not in the perl binary. There are hooks in the binary that a program may use for debugging, profiling, and such. perl -d simply invokes one of those programs by default. In some sense, these hooks could simply be replaced by the previously mentioned (BEGIN|END) (BLOCK|STATEMENT) structure - since that is mainly what they are. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: as long as we are discussing 'nice to have's...
[EMAIL PROTECTED] wrote: > On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote: > >>I discovered today that I had forgotten to put 'use strict' at the top of >>one of my modules...it was in the script that _used_ the module, but not >>in the module itself. Putting it in instantly caught several annoying >>bugs that I'd been trying to track down. > > A better way might be something which simply detects if you forgot to > use strict. Stick that in your Makefile.PL and it will scan your > libraries everytime and report back stupid mistakes. > > I'm working on something like that, just having a little trouble > nailing down how to detect 'use strict' from the B compiler. It's > possible, I know that much. > >>It would be nice if there was a >> >> use strict 'recursive'; >> >>option that you could set in a script or module (package, whatever) which >>would force all the modules it used to operate under strict. How about something similar to PERL5OPT that, instead of inserting stuff onto the command line, inserted stuff into every package defined? That way, you wouldn't worry about people shipping code with it defined; it would only be useful as a development aid. (I've run across the same problem many times. "Hey! Why didn't use strict catch this? ...oh, not again!")
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001 14:47:43 -0700 (PDT), Dave Storrs wrote: >I discovered today that I had forgotten to put 'use strict' at the top of >one of my modules...it was in the script that _used_ the module, but not >in the module itself. Putting it in instantly caught several annoying >bugs that I'd been trying to track down. > >It would be nice if there was... No. Your script should not be responsible for debugging modules. Modules are supposed to be debugged already, and are the responsibility of the module author, not the script writer. -- Bart.
Re: as long as we are discussing 'nice to have's...
At 02:47 PM 7/21/2001 -0700, Dave Storrs wrote: >Second topic: > >The debugger API PDD that I submitted a couple of days ago suggested that >we incorporate a profiler into the core. What do people think of this >idea? A simple version will probably be included--I expect to hack one together for my own purposes, so I don't see why a cleanish version of it ought not go into the core distribution. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: as long as we are discussing 'nice to have's...
On Mon, Jul 23, 2001 at 10:56:41AM -0700, Dave Storrs wrote: > A good point. There should definitely be a clean API so that > other people can develop their own profilers which could then be plugged > in. This still leaves the question though...should core provide a default > profiler? What do you mean by "core" here? There is already a profiler provided as one of the standard modules (which will presumably be part of perl6). Are you suggesting that there should be language hooks for profiling built into perl rather than as a module? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: as long as we are discussing 'nice to have's...
On Sun, 22 Jul 2001, Johan Vromans wrote: > Dave Storrs <[EMAIL PROTECTED]> writes: > > > I discovered today that I had forgotten to put 'use strict' at the top of > > one of my modules...it was in the script that _used_ the module, but not > > in the module itself. Putting it in instantly caught several annoying > > bugs that I'd been trying to track down. > > > > It would be nice if there was a > > > > use strict 'recursive'; > > Good reasoning, although this occurs to me as trying to kill a fly > with a nuclear bomb. Ah, but note that, while using a nuke as a flyswatter may be massive overkill, it is also very _effective_. :> > The essence of modules is that they are independent, and are > unaffected by outside pragmata. This is what makes them reusable. > A 'recursive' pragma would break that. True, a recursive pragma would break a module's ability to manage its own internals as it pleases. However, if I _want_ them to be affected, there is no reason they shouldn't be...it's like any other powerful technique; if I misapply it, I am responsible for the consequences. Dave
Re: as long as we are discussing 'nice to have's...
> "DS" == Dave Storrs <[EMAIL PROTECTED]> writes: DS> A good point. There should definitely be a clean API so that DS> other people can develop their own profilers which could then be DS> plugged in. This still leaves the question though...should core DS> provide a default profiler? it should provide a core API HOOK for debugger and profiler like stuff. and prolly a standard profiler module would be in the distro. but a normal program would not load the profiler so it is not in the core (by that def of core). it should be in the standard lib uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001 [EMAIL PROTECTED] wrote: > On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote: > > > It would be nice if there was a > > > > use strict 'recursive'; > > > > option that you could set in a script or module (package, whatever) which > > would force all the modules it used to operate under strict. > > HUGE MASSIVE PROBLEM HERE! This might be useful if *all* the modules > you use and *all* the modules which are then used are *all* under your > control and that none of them are have elected to *not* use strict for > some reason (like Exporter, which would be silly to use strict > 'refs'). Otherwise, you're just causing unnecessary bugs. Please note that I addressed this in my original post. This was the specific reason that I suggested the "exclude" option. > > Second topic: > > > > The debugger API PDD that I submitted a couple of days ago suggested that > > we incorporate a profiler into the core. What do people think of this > > idea? > > You mean like Devel::DProf, the profiler that's already in the core? > ;) And is this new debugger API like the current debugger API, DB.pm? > (Actually, I hope it isn't. Just making sure you're aware of what's > already there.) No, I do not mean something like Devel::DProf; that is a module. I mean something that is in the core binary, the same way that the perl debugger is in the core binary. Perhaps I should have made a distinction between 'core' meaning "inside the perl binary" and 'core' meaning "distributed in the default bundle which includes the perl binary and a whole slew of Perl- and/or XS-based modules." I agree that it should be possible to use any debugger and/or profiler you choose. I am simply asking if we should provide a default profiler, in the core binary, which will be invoked when no other profiler is specified. Dave
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001, Dan Brian wrote: > > The debugger API PDD that I submitted a couple of days ago suggested that > > we incorporate a profiler into the core. What do people think of this > > idea? > > I think that with a clean API, many third-party profilers could and would > be created. I am skeptical of the value of putting it in the core, when a > well-designed API would exist specifically with the end of getting some of > that work out of the porter's pockets, and instead allow the World to > develop their own, much as it currently happens with Java. A good point. There should definitely be a clean API so that other people can develop their own profilers which could then be plugged in. This still leaves the question though...should core provide a default profiler? Dave
Re: as long as we are discussing 'nice to have's...
Dave Storrs <[EMAIL PROTECTED]> writes: > I discovered today that I had forgotten to put 'use strict' at the top of > one of my modules...it was in the script that _used_ the module, but not > in the module itself. Putting it in instantly caught several annoying > bugs that I'd been trying to track down. > > It would be nice if there was a > > use strict 'recursive'; Good reasoning, although this occurs to me as trying to kill a fly with a nuclear bomb. The essence of modules is that they are independent, and are unaffected by outside pragmata. This is what makes them reusable. A 'recursive' pragma would break that. -- Johan
Re: as long as we are discussing 'nice to have's...
> "DS" == Dave Storrs <[EMAIL PROTECTED]> writes: DS> Second topic: DS> The debugger API PDD that I submitted a couple of days ago suggested that DS> we incorporate a profiler into the core. What do people think of this DS> idea? only if it can be shut off with no penalty. that may mean a variant op code loop that is run when you profile. just having runtime flags for that may be too slow. i will bring it up at the op code bof. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: as long as we are discussing 'nice to have's...
On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote: > I discovered today that I had forgotten to put 'use strict' at the top of > one of my modules...it was in the script that _used_ the module, but not > in the module itself. Putting it in instantly caught several annoying > bugs that I'd been trying to track down. A better way might be something which simply detects if you forgot to use strict. Stick that in your Makefile.PL and it will scan your libraries everytime and report back stupid mistakes. I'm working on something like that, just having a little trouble nailing down how to detect 'use strict' from the B compiler. It's possible, I know that much. > It would be nice if there was a > > use strict 'recursive'; > > option that you could set in a script or module (package, whatever) which > would force all the modules it used to operate under strict. HUGE MASSIVE PROBLEM HERE! This might be useful if *all* the modules you use and *all* the modules which are then used are *all* under your control and that none of them are have elected to *not* use strict for some reason (like Exporter, which would be silly to use strict 'refs'). Otherwise, you're just causing unnecessary bugs. Attempting to apply blanket compile-time style requirements recursively runs into massive problems like this. It's all or nothing. Taint mode currently has the same problem, its all or nothing. You turn on taint, and every single module you use has to behave. This might be good for security, but it makes it really, really hard to use for all practical purposes. The basic problem is any sort of C boils down "I am going to enforce my style upon every piece of code I run into, whether or not I wrote it" and that rapidly gets nasty. Taint has this same problem, but it's supposed to be paranoid. strict isn't. > Second topic: > > The debugger API PDD that I submitted a couple of days ago suggested that > we incorporate a profiler into the core. What do people think of this > idea? You mean like Devel::DProf, the profiler that's already in the core? ;) And is this new debugger API like the current debugger API, DB.pm? (Actually, I hope it isn't. Just making sure you're aware of what's already there.) -- Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Re: as long as we are discussing 'nice to have's...
> The debugger API PDD that I submitted a couple of days ago suggested that > we incorporate a profiler into the core. What do people think of this > idea? I think that with a clean API, many third-party profilers could and would be created. I am skeptical of the value of putting it in the core, when a well-designed API would exist specifically with the end of getting some of that work out of the porter's pockets, and instead allow the World to develop their own, much as it currently happens with Java.
