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
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.
For
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't
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 discussion we
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 takes to implement
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
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 aset
[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 messages
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
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 define a
[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 HLL.
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 (or
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 useful error
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 quite
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?
While
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
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
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 now
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 extract
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
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 or
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
#line 123
#line
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,
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 comment.
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
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
27 matches
Mail list logo
