James Ryley wrote:
>
> Hi,
>
> I was wondering if anything ever became of the comments at
> http:[EMAIL PROTECTED]/msg00318.html?
>
> I have an application that would benefit from double interpolation. Of
> course I can work around it, but double interpolation would be so much
> cleaner. Was
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote:
>
> How about we instead declare that all subs have One True Entry Point,
> and the sub does whatever is needed there? Normal subs can just set up
> scoping and jump to the beginning of the sub's body; coroutines retrieve
> their context
pdd06 has a section with op-codes for object oriented things.
parrot-0.0.4 doesnt seem to have an implementation of this.
Would it be safe to assume that ParrotVM has/will-have JVM
style handling of objects? Specifically will be
like JVM and will it be applicable to arbitrary objects.
Also wi
> Should strings in parrot be mutable or immutable? Right now we've a
> mix, and that's untenable.
I've improved (read: got working) 2 C++ string libraries in the past, both
with mutable strings. As performance was a primary consideration on both
systems that used these libraries, I chose to co
> I've no strong opinions on how it's done, but I do believe that
> it's *very* important that subroutine calls be as fast as possible
> (and significantly faster than perl5). This must be a priority.
>
> To my mind that means that a subroutine should be responsible for
> setting up whatever _it_
On Wed, Apr 24, 2002 at 04:04:14PM -0700, Robert Spier wrote:
> >Without knowing too much about it, I still have to wonder what is
> >wrong with cons? I thought it was a fully functional all-perl make
> >replacement.
>
> One reason not to use cons is that we will have to port it to
> parrot/perl6
SUMMARY
A proposal for a set of loop structures that simplify code that is based on
loop iterations.
foreach my $var (@arr) { ... }
before { ... } # run before first iteration, only if there is at least
one iteration
between { ... } # run between iterations, not before first or after l
(note: this repsonse arrived just in my mailbox, not to the list, but I
thought I'd post my response to the list. -Miko)
> Okay, that's if you can store the results somewhere all at once, but
> so was your example. Iteration objects could be used to optimize for
> the case where you can't (or d
> foreach my $var (@arr) { ... }
You mean
foreach @arr -> $var {...}
> before { ... } # run before first iteration, only if there is at
>least one iteration
> after { ... } # run after last iteration, only if there is at least
> one iteration
> noloo
- Renames KEY/KEY_PAIR to KEY/KEY_ATOM where KEY is now a linked list
of KEY_ATOM
- Reimplements hashes (based heavily on the implementation in key.c, but
with the fancy multilevel stuff that I didn't understand removed.)
- Creates a UnionVal type that is used in place of the PMC cache un
Okay, here are a few tasks for the interested.
1) We need to have a set of 'new stack frame' ops that close out the
current stack frames and start new ones. Should take an optional size
that presizes the stacks.
2) We need a pure-integer stack
3) The stack chunks need to be decoupled from the
On Thu, Apr 25, 2002 at 01:58:29PM -0400, Dan Sugalski wrote:
> 2) We need a pure-integer stack
I volunteer Brent Dax for that one. Hey, he's done already! :-)
rxstacks.c has exactly that. It just needs a rename.
Hm. And maybe a memory management checkup.
At 4:42 PM -0700 4/22/02, Steve Fink wrote:
>On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
>> G'day all.
>>
>> On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
>>
>> > 3) We're having a new rule--you may *not* take a continuation from
>> > within an opcode func
I can't find any clear description of how memory allocation is
supposed to work. I see bits and pieces in pdd09_gc.pod, resources.c,
etc., but I still haven't been able to wrap my head around it all.
Here's a hypothesis. Could someone correct me where I'm wrong?
There are two kinds of memory: un
At 1:19 PM -0700 4/25/02, Steve Fink wrote:
>I can't find any clear description of how memory allocation is
>supposed to work. I see bits and pieces in pdd09_gc.pod, resources.c,
>etc., but I still haven't been able to wrap my head around it all.
>
>Here's a hypothesis. Could someone correct me wh
Thank you! I think I more or less understand things now. Once you make
your changes and I'm convinced that I really do know what's going on,
I'll try to find time to write things up properly.
But it does seem like there's something missing: general fixed size
tracked objects. They would only have
At 2:17 PM -0700 4/25/02, Steve Fink wrote:
>Thank you!
No, thank you, for a rather entertaining and depressingly dead-on message. :)
>I think I more or less understand things now. Once you make
>your changes and I'm convinced that I really do know what's going on,
>I'll try to find time to writ
At 10:03 AM -0500 4/25/02, Fisher Mark wrote:
> > I've no strong opinions on how it's done, but I do believe that
>> it's *very* important that subroutine calls be as fast as possible
>> (and significantly faster than perl5). This must be a priority.
>>
>> To my mind that means that a subrouti
Miko O'Sullivan wrote:
>
> SUMMARY
>
> A proposal for a set of loop structures that simplify code that is based on
> loop iterations.
>
> foreach my $var (@arr) { ... }
> before { ... } # run before first iteration,
> # only if there is at least one iteration
Larry
In a message dated Thu, 25 Apr 2002, Luke Palmer writes:
> > before { ... } # run before first iteration, only if there is at
> >least one iteration
> > after { ... } # run after last iteration, only if there is at least
> > one iteration
> > noloop { ... }
In a message dated Fri, 26 Apr 2002, Damian Conway writes:
> Larry is still considering allowing a C block that would do this.
> It would go inside the loop block.
> [...]
> This will be called a C block. It goes inside the loop block.
> [...]
> This will be called a C block. It goes inside the lo
Trey Harris wrote:
> So:
>
> for $results.get_next() {
> FIRST { print "Results:"; }
> print $_;
> NEXT { print ""; }
> LAST { print "Done."; }
> } else {
> print "No results.";
> }
>
> Do I have that right?
Yes. Presuming Larry decides in favour of C and C.
Note too that the NAMED
G'day all.
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote:
> > How about we instead declare that all subs have One True Entry Point,
> > and the sub does whatever is needed there? Normal subs can just set up
> > scoping and jump to the beginning of the sub's body; coroutines retrieve
Steve Fink wrote:
>
> I'm not worried about your new make system being a bad idea. I do
> wonder if it's a wheel that's been invented before, but that's not my
> real concern. My real concern is that it sounds like this is slowing
> the introduction of the new assembler, and *that* is blocking mu
> > And "" won't be printed before "Done."?
>
> It *will* be printed there, according to the current design. A C is
> *always* called when the iteration leaves the block (whether it's coming
> around again or not). By analogy, C is a terminator, not a
separator.
Darn, we're so close. I understand
25 matches
Mail list logo
