At 10:21 PM 7/10/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 12:02 AM 7/10/2001 +0200, Paul Johnson wrote:
>
> >> And ultimately it's going to be possible to directly manipulate the
> >> optree, even while a program is running, right?
>
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 12:02 AM 7/10/2001 +0200, Paul Johnson wrote:
>> And ultimately it's going to be possible to directly manipulate the
>> optree, even while a program is running, right?
DS> Absolutely.
hmm, how does that work with the idea of
At 12:02 AM 7/10/2001 +0200, Paul Johnson wrote:
>On Mon, Jul 09, 2001 at 04:30:08PM -0400, Dan Sugalski wrote:
> > At 03:30 PM 7/9/2001 -0400, Uri Guttman wrote:
> > >definitely insert special opcodes only when asked for by a compiler
> > >option. stuff like profiling, tracing, fine grained singl
On Mon, Jul 09, 2001 at 04:30:08PM -0400, Dan Sugalski wrote:
> At 03:30 PM 7/9/2001 -0400, Uri Guttman wrote:
> >definitely insert special opcodes only when asked for by a compiler
> >option. stuff like profiling, tracing, fine grained single step (op
> >code) debugging should be supported with s
At 03:30 PM 7/9/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> PJ> Done by what? Adding opcodes at all conceivable positions could
> PJ> be unnecessarily expensive for most applications, and you're bound
> PJ> to miss something that someone wants.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> well, i am sorta pushing for more work to be done on actually
>> implementing some early core stuff. i proposed work on the event system
>> even as a learning project to get a portable event system up in perl5.
DS> Cool--so... got
At 02:25 AM 7/9/2001 -0400, Uri Guttman wrote:
> > "PJ" == Paul Johnson <[EMAIL PROTECTED]> writes:
>
> >> how would you propose those callbacks be attached without op codes to do
> >> the callback? :)
>
> PJ> Well I was specifying requirements rather than proposing
> PJ> solutions, bu
At 09:58 PM 7/7/2001 -0400, Uri Guttman wrote:
> > "PJ" == Paul Johnson <[EMAIL PROTECTED]> writes:
>
> PJ> Some method of attaching a callback function to arbitrary opcodes would
> PJ> be very useful.
>
>how would you propose those callbacks be attached without op codes to do
>the callbac
> "PJ" == Paul Johnson <[EMAIL PROTECTED]> writes:
>> how would you propose those callbacks be attached without op codes to do
>> the callback? :)
PJ> Well I was specifying requirements rather than proposing
PJ> solutions, but with this being the internals list I suppose I
PJ> shou
On Sat, Jul 07, 2001 at 09:58:54PM -0400, Uri Guttman wrote:
> > "PJ" == Paul Johnson <[EMAIL PROTECTED]> writes:
>
> PJ> Some method of attaching a callback function to arbitrary opcodes would
> PJ> be very useful.
>
> how would you propose those callbacks be attached without op codes t
At 12:13 AM 7/8/2001 +0100, Simon Cozens wrote:
>On Sat, Jul 07, 2001 at 05:51:00PM -0500, Jarkko Hietaniemi wrote:
> > A basic block is a sequence of consecutive statements
> > in which flow of control enters at the beginning and
> > leaves at the end without halt or possibility
> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
RC> I suggested something similar in 1997:
RC> The message proposed a tasking package that would dispatch atomic
RC> chunks of code. I eventually wrote one in Perl; it's on the CPAN
RC> as POE. In the Perl version, code atoms are j
On Sat, Jul 07, 2001 at 05:51:00PM -0500, Jarkko Hietaniemi wrote:
> > Not that innovative, really. :) Will basic blocks ever be different
> > from scopes?
>
> The Book of the Red Dragon sayeth, p 528 in my copy:
>
> A basic block is a sequence of consecutive statements
> in which fl
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> Basic-blocks are a useful unit both for code generation and for code
JH> profiling.
and in optimization. you can compare basic blocks and do loop invariant
detection and related loop optimizations.
a basic block is just a seq
> "PJ" == Paul Johnson <[EMAIL PROTECTED]> writes:
PJ> Some method of attaching a callback function to arbitrary opcodes would
PJ> be very useful.
how would you propose those callbacks be attached without op codes to do
the callback? :)
PJ> For example, in a code coverage tool a callb
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> On Sat, Jul 07, 2001 at 03:07:52PM -0400, Dan Sugalski wrote:
>> At 01:00 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
>> >Would it make sense / be useful to have also distinct "between
>> >statements" callbacks?
>>
>> Yu
On Sun, Jul 08, 2001 at 12:13:27AM +0100, Simon Cozens wrote:
> On Sat, Jul 07, 2001 at 05:51:00PM -0500, Jarkko Hietaniemi wrote:
> > A basic block is a sequence of consecutive statements
> > in which flow of control enters at the beginning and
> > leaves at the end without halt or po
On Sat, Jul 07, 2001 at 05:51:00PM -0500, Jarkko Hietaniemi wrote:
> A basic block is a sequence of consecutive statements
> in which flow of control enters at the beginning and
> leaves at the end without halt or possibility of
> branching except at the end.
Oh, I know wh
> Not that innovative, really. :) Will basic blocks ever be different
> from scopes?
The Book of the Red Dragon sayeth, p 528 in my copy:
A basic block is a sequence of consecutive statements
in which flow of control enters at the beginning and
leaves at the end without h
On Sat, Jul 07, 2001 at 11:23:07PM +0100, Simon Cozens wrote:
> On Sat, Jul 07, 2001 at 05:10:03PM -0500, Jarkko Hietaniemi wrote:
> > BLB = block begin
> > BBB = basic block begin
>
> enter
>
> > SE = statement end
>
> nextstate
>
> > BBE = basic block end
> > BLE = block end
>
> leave
>
>
On Sat, Jul 07, 2001 at 05:10:03PM -0500, Jarkko Hietaniemi wrote:
> BLB = block begin
> BBB = basic block begin
enter
> SE = statement end
nextstate
> BBE = basic block end
> BLE = block end
leave
Not that innovative, really. :) Will basic blocks ever be different
from scopes?
--
"Don't
> For example, in a code coverage tool a callback would be desirable not
> only at the exit (or entry) of a block, or more accurately a linear code
> sequence, but also at various points throughout a conditional, so that
> it is possible to determine not only the truth value of the conditional,
>
On Sat, Jul 07, 2001 at 02:49:48PM -0500, Jarkko Hietaniemi wrote:
> On Sat, Jul 07, 2001 at 03:35:04PM -0400, Dan Sugalski wrote:
> > At 02:23 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
> > >On Sat, Jul 07, 2001 at 03:07:52PM -0400, Dan Sugalski wrote:
> > > > At 01:00 PM 7/7/2001 -0500, Jarkko
On Sat, Jul 07, 2001 at 03:35:04PM -0400, Dan Sugalski wrote:
> At 02:23 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
> >On Sat, Jul 07, 2001 at 03:07:52PM -0400, Dan Sugalski wrote:
> > > At 01:00 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
> > > >Would it make sense / be useful to have also disti
At 02:23 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
>On Sat, Jul 07, 2001 at 03:07:52PM -0400, Dan Sugalski wrote:
> > At 01:00 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
> > >Would it make sense / be useful to have also distinct "between
> > >statements" callbacks?
> >
> > Yup. For the debugger
On Sat, Jul 07, 2001 at 03:07:52PM -0400, Dan Sugalski wrote:
> At 01:00 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
> >Would it make sense / be useful to have also distinct "between
> >statements" callbacks?
>
> Yup. For the debugger if nothing else, and it's a good place to put cleanup
> code,
At 01:00 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote:
>Would it make sense / be useful to have also distinct "between
>statements" callbacks?
Yup. For the debugger if nothing else, and it's a good place to put cleanup
code, so... I expect we'll have an "end of statement" opcode
>(Which reminds m
Would it make sense / be useful to have also distinct "between
statements" callbacks?
(Which reminds me of a clever hack Abigail once concocted to have code
executed at *block* exits...)
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
On Fri, 6 Jul 2001, Dan Sugalski wrote:
> > > You've pretty much got it. The flag-checking will be hardwired, but
> > > there's no reason that the function called can't be user-defined.
> > > Being able to install an arbitrary number of user-defined inter-opcode
> > > (and inter-statement) functi
At 11:44 AM 7/6/2001 -0500, David M. Lloyd wrote:
>On Fri, 6 Jul 2001, Dan Sugalski wrote:
>
> > At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
> >
> > >It would be nice to be able to tell the interpreter to call a user-defined
> > >C function between opcodes. This could make it easier to impl
On Fri, 6 Jul 2001, Dan Sugalski wrote:
> At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
>
> >It would be nice to be able to tell the interpreter to call a user-defined
> >C function between opcodes. This could make it easier to implement
> >debuggers, profilers, etc. as well as providing a m
At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
>Here's a feature suggestion for Perl 6.
>
>It would be nice to be able to tell the interpreter to call a user-defined
>C function between opcodes. This could make it easier to implement
>debuggers, profilers, etc. as well as providing a method of
Here's a feature suggestion for Perl 6.
It would be nice to be able to tell the interpreter to call a user-defined
C function between opcodes. This could make it easier to implement
debuggers, profilers, etc. as well as providing a method of safely using
asynchronous callbacks that certain C lib
33 matches
Mail list logo
