Steve Fink wrote:
I replied to ticket #16941 a while back but I don't think I had RT
actually send any mail to anybody. Anyone have an opinion on the patch
I put in it? (I'm trying to clean out some local changes so I can
apply other people's patches more easily.)
Thanks.
I don't like it very
If memory serves me right, Leopold Toetsch wrote:
> Yep, you are right - I did miss this point sometimes. We have to do a
> _save_registers before calling code, that might throw an exception.
Excuse me for butting in ... But how are the parameters to a C code being
passed .. I assume that would u
On Sun, Oct 06, 2002 at 10:26:23PM +0100, Tim Bunce wrote:
> On Wed, Oct 02, 2002 at 12:28:57PM -0400, Dan Sugalski wrote:
> > At 12:15 PM +0100 10/2/02, Tim Bunce wrote:
> > >On a related note, are there any good tools for static code analysis
> > >around? The usual cross-reference stuff would be
- first chunk of last JIT patch was not really testing for signed range
(reverted)
- mapped registers are now ebx,edi,esi,edx. The first 3 are callee
saved. Prior ecx was used, which was only by chance not failing in
tests, which used shift operations, because, when shifting a register
mapped t
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
Yep, you are right - I did miss this point sometimes. We have to do a
_save_registers before calling code, that might throw an exception.
Excuse me for butting in ... But how are the parameters to a C code being
passed .. I ass
If memory serves me right, Leopold Toetsch wrote:
> pusha/popa is overkill. The called functions always save bp and bx,di,si
> when used. ax is the return value, remaining is dx (cx is used by
> shifts) - i386 of course.
Ok ... push_necessary() ;-) ...
> > Speaking about debugging calls fro
If memory serves me right, Tim Bunce wrote:
> "CCured is a source-to-source translator for C, which
> analyzes the program to determine the smallest number of
> run-time checks that must be inserted in the program to
> prevent all memory safety violations."
Yow ! .. the ou
On 11/15/02 Gopal V wrote:
> It is possible ... JIT generated code looks just like loaded code to
> gcc ... Typically gdb should only need access to a symfile to correctly
> allow debugging ... So an .o file of the JIT'd code should be correctly
> generated with all the trimmings.
>
> $ gdb parr
Steve,
Thanks! Was there a problem applying the patch? I just checked out a new cvs
images and the file t/op/lexicals.t has not been updated. As a result, a few
tests are failing. Should I resubmit the part of the patch that updates
t/op/lexicals.t?
--
Jonathan Sillito
> -Original Message---
From: chromatic [mailto:chromatic@;wgz.org]
>
> Brent Dax had a nice suggestion for Perl 6 test organization.
> I like it tremendously.
isn't it missing: t/var/list/...?
Per Apocalpyse 2, RFC 175:
>
> [1,2,3]
>
> is syntactic sugar for something like:
>
> scalar(list(1,2,3));
>
> Depe
If memory serves me right, Paolo Molaro wrote:
> You can find the complete examples of how the jit debugging features
> work in the mono tarball (mono/doc directory):
Same old lupus I never realized I had a wolf pack hunting me :-)
> the above was a partial cut&paste with s/mono/parrot/ :-)
Paolo Molaro wrote:
On 11/15/02 Gopal V wrote:
It is possible ... JIT generated code looks just like loaded code to
gcc ... Typically gdb should only need access to a symfile to correctly
allow debugging ... So an .o file of the JIT'd code should be correctly
generated with all the trimmings.
# New Ticket Created by Jonathan Sillito
# Please include the string: [perl #18419]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18419 >
The attached patch makes subs closures and does a couple simple cleanups. It
also st
From: Leopold Toetsch [mailto:lt@;toetsch.at]
> Garrett Goebel wrote:
> > From: chromatic [mailto:chromatic@;wgz.org]
> >
> >>Brent Dax had a nice suggestion for Perl 6 test organization.
> >>I like it tremendously.
> >
> > isn't it missing: t/var/list/...?
>
> *All* (parrot as well as perl6) t
Garrett Goebel wrote:
From: chromatic [mailto:chromatic@;wgz.org]
Brent Dax had a nice suggestion for Perl 6 test organization.
I like it tremendously.
isn't it missing: t/var/list/...?
*All* (parrot as well as perl6) tests are currently a grown unorganized
mess - though working.
If this
On Nov-15, Jonathan Sillito wrote:
> Steve,
>
> Thanks! Was there a problem applying the patch? I just checked out a new cvs
> images and the file t/op/lexicals.t has not been updated. As a result, a few
> tests are failing. Should I resubmit the part of the patch that updates
> t/op/lexicals.t?
On Nov-15, Jonathan Sillito wrote:
> Steve,
>
> Thanks! Was there a problem applying the patch? I just checked out a new cvs
> images and the file t/op/lexicals.t has not been updated. As a result, a few
> tests are failing. Should I resubmit the part of the patch that updates
> t/op/lexicals.t?
I'm prepared to start checking in Perl 6 tests on behalf of the Perl 6
documentation folks. These should be considered functional tests -- they are
exploring the behavior we expect from Perl 6. Anything that's not yet
implemented will be marked as a TODO test, and we'll figure out a way to extrac
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jonathan Sillito) wrote:
> Steve,
>
> Thanks! Was there a problem applying the patch? I just checked out a new cvs
> images and the file t/op/lexicals.t has not been updated. As a result, a few
> tests are failing. Should I resubmit the part of
19 matches
Mail list logo
