The regex and bf compilers are again passing all tests with 0.3.1
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
Applied as r9954.
-J
--
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
On Sun, Nov 13, 2005 at 11:58:39AM -1000, Joshua Hoblitt wrote:
> I started a thread about this a couple of weeks ago. I really think
> that bison 1.75c should be the minimum requirement.
Note also that bison < 1.24 has licencing issues, in that the generated
output files are GPLed.
--
Art is a
On Sun, Nov 13, 2005 at 10:45:32PM +0100, Leopold Toetsch wrote:
> ... which has bison 1.28 installed (not quite state of the art)
>
> *) tried apt-cache search bison
>- most recent package reported is 1.35 - that's ancient too
>- canceled
I started a thread about this a couple of weeks a
... which has bison 1.28 installed (not quite state of the art)
*) tried apt-cache search bison
- most recent package reported is 1.35 - that's ancient too
- canceled
*) installed bison 2.1 into ~/bison from source (actually
--prefix=/Users/lt/bison)
- works despite of slightly older
:outer("foo") now basically works, there is also a new Sub method
C.
There is one limitation though: the subroutine referenced by :outer must
be already compiled, that is: it must be in the same sourcefile [1] and
it's source code has to appear before the sub referencing it [2].
[1] can for
On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
{ First, let's have a little applause for Leo for implementing the new
lexical scheme in, what, a week? He says it was only a half-day's
work, too. Nice work, dude! }
It was just half a day. The rest of the week was spent on unicode
improvem
15 matches
Mail list logo
