# New Ticket Created by Chris Dolan
# Please include the string: [perl #39810]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39810 >
This patch adds a new syntax_errors.t file with some known broken
regexps. This is int
> >
> > PARROT_API void *Parrot_compile_file(Parrot_Interp interpreter,char
> > *fullname, String **error);
>
> I like this interface, except for the return value from Parrot_compile_file.
> Are there other options, such as returning a Sub PMC?
Chip and I have had a chat about other possible A
On Wednesday 12 July 2006 22:02, Vishal Soni via RT wrote:
> This patch also introduces a Parrot API for the calling programs to
> compile the code. Currently pugs uses immc_compile() call into IMCC.
> Ideally Pugs should not be communicating with IMCC but with Parrot. This
> new API will try to h
On Jul 12, 2006, at 10:53 PM, Patrick R. Michaud wrote:
On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:
As simple token containing ":i" causes PGE to crash with an attempted
method call on Undef.
Steps to reproduce:
1) Create a grammar file called "foo.pg" that has one line:
On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:
> As simple token containing ":i" causes PGE to crash with an attempted
> method call on Undef.
>
> Steps to reproduce:
>1) Create a grammar file called "foo.pg" that has one line:
> token foo { :i a }
As I read S05, a modifie
# New Ticket Created by Chris Dolan
# Please include the string: [perl #39809]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39809 >
---
osname= darwin
osvers= 8.0
arch= darwin-thread-multi-2level
cc= cc
---
Flags:
# New Ticket Created by Kevin Tew
# Please include the string: [perl #39808]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39808 >
example:
perl Configure --step=gen::languages
Configure.pl | 12 +++
On Wed, Jul 12, 2006 at 05:29:08PM -0700, [EMAIL PROTECTED] wrote:
> * Apply heuristics that tells
> .loadlib 'perl6_group' # HLL dynamic PMCs
> and
> .loadlib 'dynlexpad'# non-HLL dynamic PMCs
> apart, by locating the '_group" substring inside the library name.
Urque, that's rea
chromatic wrote:
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
Oh, you mean the fact that much of the time it's not loading bytecode at
all? It has crossed my mind, but the irritation hasn't
[EMAIL PROTECTED] wrote:
Modified: trunk/languages/perl6/perl6.pir
==
--- trunk/languages/perl6/perl6.pir (original)
+++ trunk/languages/perl6/perl6.pir Wed Jul 12 17:05:26 2006
@@ -24,9 +24,7 @@
.namespace [ '
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
> load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
I wonder if there could be a variant that evaluates the code with the
appropriate compiler, too:
load_{something} 'file', 'compiler_name'
Leopold Toetsch wrote:
This means, we'd have:
.include "file.pasm/.pir" ... load macros or constants (no code)
>
load_bytecode "file.pbc" ... load a "module"
$P0 = loadlib "file" ... load a shared lib (pmc or ops)
.loadlib "file"... same during compilation
Th
On Wed, Jul 12, 2006 at 12:15:07PM -0700, Chip Salzenberg wrote:
> >- If another HLL wants to create a Perl6Str, how does it do it?
> >- If another HLL wants to create a subclass of Perl6Str...?
I just realized that I misinterpreted these questions. I thought that the
first question was a
Patrick R. Michaud wrote:
IIUC, the loadlib opcode (and the new .loadlib directive) are used
strictly for dynamic libraries...
.include is currently compile-time only, and only works with .pir/.pasm
...
Yes, the suggestion is an extreme reuse of existing syntax. Something
that's good to avoi
Will Coleda wrote:
I would prefer .include to maintain its current meaning. Not everything
you .include is a complete PIR program.
I think the most common case at the moment is stitching together .pir
files generated by PGE/TGE. Which is useful.
Allison
On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote:
> So the type is bound to a number in the .pbc? Isn't this dangerous for
> types that are not built in? Couldn't this number mean something
> different if libraries happen to get loaded in a different order?
The declaration order of PM
On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>Date: Wed, 12 Jul 2006 21:15:44 +0200
>
>On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
>> The perl6 compiler has a custom string type, currently called
>
On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote:
> Leopold Toetsch wrote:
> >
> > Well, there was already one very legitimate usage of compile time
> > loadlib, which is now using C<.loadlib> for that:
>
> We certainly need both compile-time and runtime loading of libraries.
> So,
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 12 Jul 2006 21:15:44 +0200
On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
> The perl6 compiler has a custom string type, currently called
> "Perl6Str". What's the canonically correct mechanism for creating
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote:
> On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> > On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > >
> > > $P0 = new 'Perl6Str'
> >
> > I tend to use:
> >
> > .local int str_type
> > str_t
On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote:
> Leopold Toetsch wrote:
> >
> >Well, there was already one very legitimate usage of compile time
> >loadlib, which is now using C<.loadlib> for that:
>
> We certainly need both compile-time and runtime loading of libraries.
> So, it
On Jul 12, 2006, at 3:18 PM, Allison Randal wrote:
Leopold Toetsch wrote:
Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:
We certainly need both compile-time and runtime loading of
libraries. So, it's just a question of wh
Leopold Toetsch wrote:
Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:
We certainly need both compile-time and runtime loading of libraries.
So, it's just a question of which syntax to use for which case.
chromatic suggests
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote:
> On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> > On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > > The perl6 compiler has a custom string type, currently called
> > > "Perl6Str". What's the canonical
On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
> The perl6 compiler has a custom string type, currently called
> "Perl6Str". What's the canonically correct mechanism for creating
> an object of that type?
>
> $P0 = new 'Perl6Str'
> $P0 = new .Perl6Str
> $P0 = ne
On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > The perl6 compiler has a custom string type, currently called
> > "Perl6Str". What's the canonically correct mechanism for creating
> > an object of that type?
> >
> > $P
On 7/12/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
The perl6 compiler has a custom string type, currently called
"Perl6Str". What's the canonically correct mechanism for creating
an object of that type?
$P0 = new 'Perl6Str'
$P0 = new .Perl6Str
$P0 = new [ 'Perl6Str' ]
At dif
On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> The perl6 compiler has a custom string type, currently called
> "Perl6Str". What's the canonically correct mechanism for creating
> an object of that type?
>
> $P0 = new 'Perl6Str'
> $P0 = new .Perl6Str
> $P0 = new [ 'Perl6S
On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote:
> It occurs to me, after thinking about it overnight, that the .loadlib
> directive shouldn't operate at :immediate time, but at :init time,
> because it's more common to want a library to load when you run the code
> than to load o
On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote:
> It occurs to me, after thinking about it overnight, that the .loadlib
> directive shouldn't operate at :immediate time, but at :init time,
> because it's more common to want a library to load when you run the code
> than to load o
# New Ticket Created by Michal Jurosz
# Please include the string: [perl #39801]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39801 >
Implement spectralnorm shootout benchmark (
http://shootout.alioth.debian.org/sandbox/b
# New Ticket Created by willie
# Please include the string: [perl #39799]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39799 >
fixes the indentation of the pmclass's closing brace and the last
method's closing brace in s
# New Ticket Created by Autrijus Tang
# Please include the string: [perl #39796]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39796 >
Allison and Chip expressed their go-ahead with a .loadlib pragma, to
replace this cur
It occurs to me, after thinking about it overnight, that the .loadlib
directive shouldn't operate at :immediate time, but at :init time,
because it's more common to want a library to load when you run the code
than to load only when you compile the code.
Which leaves us with :immediate for the
On Wed, Jul 12, 2006 at 12:14:21AM -0400, Audrey Tang wrote:
> Allison and Chip expressed their go-ahead with a .loadlib pragma, to
> replace this current use:
>
> .sub foo :immediate
> $I0 = loadlib "XXX"
> .end
>
> With this:
>
> .loadlib "XXX"
Done, r13262.
Actually loading libs matc
On Tue, Jul 11, 2006 at 02:41:19PM -0600, Kevin Tew wrote:
> It parses my simple puts.rb example, but parse time is really slow.. 2
> minutes.
> I'm sure I've made some dumb grammar mistakes that is slowing it down.
Well, the first thing to note is that subrule calls can be comparatively
slow, s
# New Ticket Created by Kevin Tew
# Please include the string: [perl #39802]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39802 >
turning up the warnings levels in gcc as much as we can
=item C<--cage>
[CAGE] compile in
On Mon, Jul 10, 2006 at 12:09:08AM -0500, Vishal Soni wrote:
> -#define N_MACROS 4096
> +#define N_MACROS 8192
Thanks, applied. But we can all see where this is going.
Will no one rid me of this troublesome fixed-size array for macros?
--
Chip Salzenberg <[EMAIL PROTECTED]>
38 matches
Mail list logo
