I've imported File::Which 0.05 into the parrot tree as r9959 and I've
applied this patch as r9960. If or when there is a workable parrot
'maintainer' bundle on CPAN and an optional module detection mechanism
as part of the configure system r9959 can be backed out.
Cheers,
-J
--
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37673]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37673 >
This transaction appears to have no content- Forwarded message from Fran?ois PERR
[Sorry if this doesn't thread in your reader]
Jonathan Worthington wrote:
> I'm looking to work
> on enabling Parrot to store away HLL debug info - that is, the file name,
> line number, columns etc in the high level language source code. This data
> can then be used to emit useful error message
Jonathan,
My highest priority requests (for use by the Amber compiler
and toolset) are:
1. To store away, for each part of the compiled program:
- the name of the HLL source filename
- the line and column numbers
2. For PIR error messages to be presented using the HLL source
location r
"Will Coleda" <[EMAIL PROTECTED]> wrote:
Storing the information is very good: how do we extract it, again? we
have {get,set}{file,line} opcodes, but if we're going to store more
generic information, we need a more generic way to extract it.
My current thinking on this is that a HLL will defin
[Disclaimer: I've only just started thinking about this in the last
hour, and don't want to appear all knowledgeable or anything!]
On 11/14/05, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> My current thinking on this is that a HLL will define a sub that knows how
> to print errors for that HL
On Mon, 2005-11-14 at 12:31 +, Jonathan Worthington wrote:
> My current thinking on this is that a HLL will define a sub that knows how
> to print errors for that HLL...
The HLL could register a PMC or object class (instead of just a sub),
using the existing "Parrot_register_HLL_type" call (
On 11/14/05, Nick Glencross <[EMAIL PROTECTED]> wrote:
> Jonathan Worthington wrote:
>
> > I'm looking to work
> > on enabling Parrot to store away HLL debug info - that is, the file name,
> > line number, columns etc in the high level language source code. This data
> > can then be used to emit u
On Fri, 11 Nov 2005, Will Coleda wrote:
> On Nov 11, 2005, at 5:15 PM, Joshua Hoblitt wrote:
> > As in my original proposal, Configure.pl would have to set the order
> > that the steps run in. Longer term it'd be nice to build a dependency
> > tree between the steps and execute them in order of
Nick Glencross wrote:
> > Does it make sense to have nestable structures?
Not always. Consider debug info that includes "line number" and
"statement number". You could have multiple statements per line, or
multiple lines per statement.
> Actually the example notation looks quite different from w
Due to new calling scheme this is obsolete.
"Roger Browne" <[EMAIL PROTECTED]> wrote:
> Does it make sense to have nestable structures?
Not always. Consider debug info that includes "line number" and
"statement number". You could have multiple statements per line, or
multiple lines per statement.
Actually the example notation looks qui
Hello,
I'm the maintainer of the parrot Debian packages which are in Debian
unstable now. All Debian packages usually get built by the Debian build
daemon network so binaries for all architectures are available to the
users. This was also done with parrot. The [0] results scared me a bit.
Parrot o
> [pmichaud - Thu Jul 21 02:10:03 2005]:
>
> On Wed, Jul 20, 2005 at 10:25:08AM -0700, Mitchell N Charity wrote:
> > PGE is currently passing all tests, but failing to run a "large" pugs
> > grammar (one for p6 regexps). So I transliterated part of the grammar
> > into a (failing) test. Attach
On Fri, Nov 11, 2005 at 11:23:34AM -0800, Jerry Gay via RT wrote:
> has this been addressed, even partially? it seems that it has, but this
> ticket, nor the related email thread
> (http://www.nntp.perl.org/group/perl.perl6.internals/29394) has been
> updated since may 2005.
The ticket can be clos
> [bernhard - Mon Jun 13 12:16:32 2005]:
> It might be nice to have the SVN revision, or a list of SVN revisions,
> as a keyword of the RT tickets. For example when a bug was reported,
> when a Patch was applied and when a problem was declared to be fixed.
>
yes, it can see it being useful. then a
Roger Browne wrote:
Nick Glencross wrote:
.hll_debug_end line
.hll_debug_begin line 2
I don't think the "end" directives add much. There's almost always going
to be an "end line" before a "begin line", so why not let 'begin line'
to imply the end of any previously-declared line?
On Nov 14, 2005, at 21:06, Nick Glencross wrote:
While nesting one begin/end line number directly inside another
doesn't make much sense, my reasoning for this is for inlining of code
where you nest a new filename/line/column and then these are popped to
get back to the original calling locat
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
* I'm thinking of a PIR syntax along the lines of this:-
The discussion goes forth and back, like all other discussion we
already had WRT syntax, months and years ago.
I'd much more prefer that a compiler (amber anyone ;) just emits PIR
On Mon, 2005-11-14 at 22:33 +0100, Leopold Toetsch wrote:
> I'd much more prefer that a compiler (amber anyone ;) just emits PIR
> with debug syntax so that folks get a feeling how it looks like.
Good idea. I'll do it tomorrow (off to bed now).
Regards,
Roger Browne
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
* I'm thinking of a PIR syntax along the lines of this:-
The discussion goes forth and back, like all other discussion we already
had WRT syntax, months and years ago.
What syntax we parse no
"Will Coleda" <[EMAIL PROTECTED]> wrote:
The actual source code is definitely needed, and is what I thought you
were talking about before. I don't particularly care about where it gets
stored, as either "debug segment" or "source segment" are below the level
I interact with parrot on.
I'
On Nov 14, 2005, at 7:31 AM, Jonathan Worthington wrote:
"Will Coleda" <[EMAIL PROTECTED]> wrote:
Storing the information is very good: how do we extract it, again?
we have {get,set}{file,line} opcodes, but if we're going to store
more generic information, we need a more generic way to extr
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:
> On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
> > $P0 = callframe 1
>
> We already have this kind of introspection: $ grep caller t/pmc/sub.t
OK, the Interpreter PMC interface is certainly flexible enough to
handle the introsp
24 matches
Mail list logo
