Will Coleda wrote:
Right, the hard bit here was that I needed to specify something other
than "file". Just agreeing that we need something other than just
"file/line".
I'd have thought the onus is the other way: justify the use of
"file/line" as the primitive concept.
We're going to have
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...
OK, I've done this.
I have modified the Amber compiler to generate PIR code that contains
debug directives, so that we can discuss a
On Tue, Nov 15, 2005 at 10:25:07AM +0100, Leopold Toetsch wrote:
>
> On Nov 15, 2005, at 10:04, Brent 'Dax' Royal-Gordon wrote:
>
> >Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> >>Because a compiler can emit it right now w/o any change to Parrot.
> >
> >That's an advantage for the week it take
On Nov 15, 2005, at 10:04, Brent 'Dax' Royal-Gordon wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Because a compiler can emit it right now w/o any change to Parrot.
That's an advantage for the week it takes to implement the feature.
For the remaining age of the universe,
Err, I didn'
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> On Nov 15, 2005, at 0:07, Jonathan Worthington wrote:
> > What's the fascination with overloading comment syntax?
>
> Because a compiler can emit it right now w/o any change to Parrot.
That's an advantage for the week it takes to implement the feature.
On Nov 15, 2005, at 0:07, Jonathan Worthington wrote:
What's the fascination with overloading comment syntax?
Because a compiler can emit it right now w/o any change to Parrot.
Jonathan
leo
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 Mon, Nov 14, 2005 at 11:07:55PM -, Jonathan Worthington wrote:
> "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 di
"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'
"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
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
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 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
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?
"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
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
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 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 (
[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
"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
[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
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'm now very confused about what you're prop
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.
As one of the first "here's something extra I need", I need not only
line numbers for file
"Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
.hll_debug file "something.pl"
.hll_debug line 1
# code from something.pl line 1 goes here
Here I meant the PIR (compiled) code for line 1 of the HLL source, which
will very likely in most cases be many PIR instructions.
Also, I should have
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
Hi,
.hll_debug file "something.pl"
.hll_debug line 1
Just
#line 123
#line 789 "file.foo"
looks simpler and well known to me - the latter is already parsed.
But:-
1) Looks just like a co
I'm pretty sure it already is for when pir's compiled to pasm.
Joshua
On Nov 13, 2005, at 7:16 PM, Joshua Hoblitt wrote:
I think it would be better if we didn't overload the meaning of
'\s*#.*'
in PIR.
-J
--
On Mon, Nov 14, 2005 at 01:48:35AM +0100, Leopold Toetsch wrote:
On Nov 14, 2005,
I think it would be better if we didn't overload the meaning of '\s*#.*'
in PIR.
-J
--
On Mon, Nov 14, 2005 at 01:48:35AM +0100, Leopold Toetsch wrote:
>
> On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
>
> >Hi,
>
> > .hll_debug file "something.pl"
> > .hll_debug line 1
>
> Just
>
> #
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
Hi,
.hll_debug file "something.pl"
.hll_debug line 1
Just
#line 123
#line 789 "file.foo"
looks simpler and well known to me - the latter is already parsed. But
actually making it work is more important for me.
Either an integer
Hi,
Writing a compiler for Parrot? I need your input! :-) 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 messages that relate to th
30 matches
Mail list logo
