Aaron Sherman wrote:
> On Sat, 2002-09-07 at 14:22, Smylers wrote:
>
> > Should that C<+> be there? I would expect chomp only to remove a
> > single line-break.
>
> Note that this is in paragraph (e.g. C<$/=''>) mode
Ah, yes. I quoted the wrong case above. The final branch deals with
t
So, the new rule for blocks and when the need semicolons seems to be
"You don't need a semicolon if the block is the last argument of a
subroutine which expects a block as its last argument", which is all
very well and all, but where does that leave:
sub foo ( &block ) {...}
...
$wibb
The op_code() function in op_lib_t does look up an op_info_table entry
by the op's full_name. To accomplish this, the current implementation
builds via ops2c.pl basically a static hash table, which get's appended
to core_ops.c and core_ops_prederef.c.
My proposal is: build a hash table at runt
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17143]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17143 >
This patch make predereferenced run mode working again (all perl6 tests
are ok, whe
On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote:
> The op_code() function in op_lib_t does look up an op_info_table entry
> by the op's full_name. To accomplish this, the current implementation
> builds via ops2c.pl basically a static hash table, which get's appended
> to core_o
While I'm already at oplib, interpreter and predereferenced code, I've
another one:
Currently we have 3 incarnations of one core.ops:
- core_ops.c
- core_ops_cg.c
- core_ops_prederef.c
While the 1st and the the 3rd have an op_info_table (and and op lib
descriptor, core_ops_cg.c doesn't has the
Nicholas Clark wrote:
> On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote:
> I like this idea. (but I've no idea of the subtle implications)
There are only PDB_eval, pxs.c and imcc as users currently, I can't
really see subtle implications whatsoever.
> Where you thinking of b
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17158]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17158 >
This patch eliminates identical function bodies in core_ops_prederef.*
thus saving
# New Ticket Created by Leon Brocard
# Please include the string: [perl #17159]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17159 >
There is a problem building imcc under Mac OS X at the moment,
but I'm afraid I don't k
Leon Brocard (via RT) wrote:
> # New Ticket Created by Leon Brocard
> # Please include the string: [perl #17159]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17159 >
>
>
> There is a problem building imcc under Mac
Piers Cawley wrote:
> So, the new rule for blocks and when the need semicolons seems to be
> "You don't need a semicolon if the block is the last argument of a
> subroutine which expects a block as its last argument", which is all
> very well and all, but ... Ah... hang on, that's *expression* no
This is for everyone: < Piers Cawley wrote:
>
> > So, the new rule for blocks and when the need semicolons seems to be
> > "You don't need a semicolon if the block is the last argument of a
> > subroutine which expects a block as its last argument", which is all
> > very well and all, but ... Ah.
Luke Palmer wrote:
> This is for everyone: <
>... put a semicolon after do {} or eval {} when it looks like a
>complete statement?"
>
>Well, in Perl 6, you don't, if the final curly is on a line by
>itself.
>
> To me, this looks like it has answers to all these questions.
Luke Palmer <[EMAIL PROTECTED]> writes:
> This is for everyone: <
>In Perl, this problem comes up most often when people say "Why do I
>have to put a semicolon after do {} or eval {} when it looks like a
>complete statement?"
>
>Well, in Perl 6, you don't, if the final c
> Luke Palmer wrote:
> > [quote from A4]
> > To me, this looks like it has answers to all these questions.
>
> Up to a point. Look at the discussion of given/when in the same
> Apocalypse. Here's some example code from A4:
>
>
> given $! {
> when Error::Overflow { ... }
> wh
Luke Palmer wrote:
[Piers wrote:]
> > Look, closing braces, ending statements, not on a line by
> > themselves. There's code like this all through the apocalypse and
> > its associated Exegesis, so it looks to me like C<< rx/\} \s* \n/ >>
> > is the regex for 'end of statement'. Either that or w
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Leon Brocard (via RT) wrote:
>> # New Ticket Created by Leon Brocard # Please include the string:
>> [perl #17159]
>> # in the subject line of all future correspondence about this
>> issue. # http://rt.perl.org/rt2/Ticket/Display.html
On Tue, Sep 10, 2002 at 07:53:10PM +0100, Nicholas Clark wrote:
> On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote:
> > This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since
> > the prototypes are hidden in the C file, not in a shared header file, the
> > compiler
Kevin Falcone wrote:
>>"LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
>>
>
> LT> Leon Brocard (via RT) wrote:
>
>>># New Ticket Created by Leon Brocard # Please include the string:
>>>[perl #17159]
> LT> Either remove -fno-common or do something like this:
>
> Apple's perl5.6.0
19 matches
Mail list logo
