[EMAIL PROTECTED] writes:
> On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
>> [EMAIL PROTECTED] writes:
>> >
>> > Why isn't
>> >
>> > if %foo {"key"} {print "Hello 1"}
>> >
>> > equivalent with the perl5 syntax:
>> >
>> > if (%foo) {"key"} {print "Hello 1"}
>> >
>> > Which
On Fri, 12 Apr 2002, Miko O'Sullivan wrote:
> SUMMARY
>
> A way to declare public names for params irrelevant to the internal variable
> names:
>
> sub load_data (-filename $filename_tainted ; 'version' 'ver'
> $version_input / /= 1) {...}
I like it. It's clean (doesn't introduce any wierd op
Hope no one minds me essentially reposting this email. :)
> Am I correct in assuming that the stacks stuff leaks memory? Both stacks.c
> and rxstacks.c allocate memory via mem_allocate_aligned, but never free
> it, relying on the GC for it (code written before the GC existed).
There was a frame
Here it is. You can cut all of the Cola support __* subs
except __strlen or just replace the bsr __strlen with the actual
op.
-Melvin
# Cola (0.0.4) generated
#
_START:
save ""
bsr __Main
__END:
end
__Generate: pushi
pushs
push
At 02:08 PM 4/12/2002 -0400, Dan Sugalski wrote:
>At 12:49 PM +0200 4/12/02, Paolo Molaro wrote:
>>On 04/11/02 Dan Sugalski wrote:
>>> I'm not sure which is worse--the amount of data we're copying around,
>>> or the fact that we eat Mono's lunch while we do so.
>>
>>:-)
>>Could you post the code
SUMMARY
A way to declare public names for params irrelevant to the internal variable
names:
sub load_data (-filename $filename_tainted ; 'version' 'ver'
$version_input / /= 1) {...}
DETAILS
Subroutine variables are like underwear: you don't generally go showing them
to everybody. So, when
Dave Mitchell wrote:
> The top 20 'my $var' declarations in .pm files in the bleedperl
> distribution:
How *dare* you introduce hard data into this discussion!
Next you'll be wanting to deal in actual facts rather than personal
opinion and sheer guesses!!
;-)
Thanks, Dave. Very illuminating.
Allison Randal wrote:
> > In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
> > > $_ becomes lexical
> Sound logic. And it almost did go that way. But subs that access the
> current $_ directly are far too common, and far to useful.
One thing I'm missing is how those common useful sub
Okay, first thing to keep in mind, this hasn't been finally-finalized
yet. Alot was hashed out in the process of proofing E4, but there will
be more to come.
On Fri, Apr 12, 2002 at 07:39:17PM -0400, Trey Harris wrote:
> In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
> > $_ becomes
sorry, the body of that message got lost:
parrot is a cool technology, but it's s buzzword-lacking. well,
here's the solution: xml based assembler!
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There's a crack in everything.
It's how the light gets in.
-Is
On Fri, Apr 12, 2002 at 02:44:38AM -0400, Trey Harris wrote:
> I think I've missed something, even after poring over the archives for
> some hours looking for the answer. How does one write defaulting
> subroutines a la builtins like print() and chomp()? Assume the code:
>
> for <> {
> pr
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
> $_ becomes lexical
> $_ gets aliased to the first topic of a given clause (hence changes
> value more often, but the lexical scoping helps reduce that impact)
Okay. But it sounds like you're saying that C, and C only,
introduces a to
PML.tar.gz
Description: Binary data
Trey Harris wrote:
>
> Oops, caught my own mistake...
> Because $_ is always the topic, which is always the first parameter to a
> block, which in subroutines is @_[0], right? So in a sub, $_ == @_[0].
> The only question I have is if you modify @_ with a shift, does $_
> continue to point at t
On Wed, Apr 10, 2002 at 05:47:01PM -0500, Allison Randal wrote:
> I'm in favor of the standardized variable name. It is a restriction, but
> not an onerous one. I've never used anything but $self, and I'm sure it
> would be easy to adapt to whatever else was chosen. Are there any
> statistics avai
On Thu, Apr 11, 2002 at 08:49:40AM -0700, Larry Wall wrote:
> Aaron Sherman writes:
> : On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
> : > $foo.instancevar = 7;
> :
> : This should not be allowed.
>
> Well, that depends on what you mean by "this". :-)
>
> That is, in fact, calling an access
Dan Sugalski wrote:
> I think perhaps a rewrite of life.pasm into perl with some
> benchmarking would be in order before making that judgement.
Following is a rough perl5 version of life.pasm.
On my system [Pentium 166; linux 2.2.18; perl 5.6.1] this takes 96 to 97
seconds; CVS parrot takes 91 t
Oops, caught my own mistake...
In a message dated Fri, 12 Apr 2002, Trey Harris writes:
> In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
> > sub printRec {
> > my $p = chomp(shift // $_);
> > print ":$_:\n"
> > }
[Should be equivalent to]
> sub printRec {
> my $p = chomp(shi
--
On Fri, 12 Apr 2002 18:27:11
abigail wrote:
>On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
>> [EMAIL PROTECTED] writes:
>> >
>> > Why isn't
>> >
>> > if %foo {"key"} {print "Hello 1"}
>> >
>> > equivalent with the perl5 syntax:
>> >
>> > if (%foo) {"key"} {print "H
On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
> [EMAIL PROTECTED] writes:
> >
> > Why isn't
> >
> > if %foo {"key"} {print "Hello 1"}
> >
> > equivalent with the perl5 syntax:
> >
> > if (%foo) {"key"} {print "Hello 1"}
> >
> > Which keyword is it expecting?
>
> Keyword /el
In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
> Couldn't you do it with old-style Perl5 subs?
>
> sub printRec {
> my $p = chomp(shift // $_);
> print ":$_:\n"
> }
>
> Or am _I_ missing something?
That definitely won't work (aside from the $p/$_ swap which I assume is
unintentional
On Wed, Apr 10, 2002 at 06:29:30PM -0400, Roman Hunt wrote:
> Hey guys:
> Here is what I have so far of the string_nprintf function. As of now it
> only handles C string backslash escape sequences and regular chars
> from the format string. My primary concern is whether I am using
> +
On Fri, 12 Apr 2002, Trey Harris wrote:
> I think I've missed something, even after poring over the archives for
> some hours looking for the answer. How does one write defaulting
> subroutines a la builtins like print() and chomp()? Assume the code:
>
> for <> {
> printRec;
> }
> pr
On Wed, Apr 10, 2002 at 08:47:17PM -0400, Melvin Smith wrote:
> At 08:04 AM 4/11/2002 +1000, Damian Conway wrote:
> >Of course, the problem is then: what should the name of this topicalizer
> >variable be? The main options are:
> >
> > $self
> > $me
> > $I
> > $this
Some while back, I asked the Perk5-porters whether there were any
parts of Perl that could benefit from vector processors (e.g., the
G4 Velocity Engine). The consensus of the respondents ranged from
"probably not" to "I don't want to think about it".
I think that better answers could have been f
At 12:49 PM +0200 4/12/02, Paolo Molaro wrote:
>On 04/11/02 Dan Sugalski wrote:
>> I'm not sure which is worse--the amount of data we're copying around,
>> or the fact that we eat Mono's lunch while we do so.
>
>:-)
>Could you post the code for the sample?
Simon did a one-for-one translation of
At 8:09 AM -0400 4/12/02, Michel J Lambert wrote:
>
>Few things immediately come to mind:
>a) with the current encoding system, we're guaranteed to be slower than
>without it. If we want Parrot to be as fast as Perl5, we're deluding
>ourselves.
I think perhaps a rewrite of life.pasm into perl wit
In a message dated Fri, 12 Apr 2002, Ashley Winters writes:
> Would it would be reasonable to have given default to the caller's topic?
>
> sub printRec {
> given {
> # $_ is now the caller's topic in this scope
> }
> }
>
> Perhaps C would work as well.
Yes, something like that wo
Melvin Smith wrote:
> So we have undef and reallyundef? :)
Seems reasonable, given that we have c and c.
How about:
sub foo ( $a is optional )
{
if exists($a) { ... }
elsif defined($a) { ... }
else { ... }
}
Dave.
- Original Message -
From: "Graham Barr" <[EMAIL PROTECTED]>
> Hm, I wonder if
>
> sub printRec($rec=$_) { ... }
>
> or someother way to specify that the current topic be used
> as a default argument, might be possible
Would it would be reasonable to have given default to the caller'
On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
> [EMAIL PROTECTED] writes:
> >
> > Why isn't
> >
> > if %foo {"key"} {print "Hello 1"}
> >
> > equivalent with the perl5 syntax:
> >
> > if (%foo) {"key"} {print "Hello 1"}
> >
> > Which keyword is it expecting?
>
> Keyword /e
On Fri, Apr 12, 2002 at 04:00:37PM +0100, Piers Cawley wrote:
>
> [EMAIL PROTECTED] writes:
> > As for "cleanness", this is my interpretation of how perl6 is going
> > to work:
> >
> > %foo = ();
> > if %foo {"key"} {print "Hello 1"}
> >
> > %foo = ();
> > if %foo{"key"}
[EMAIL PROTECTED] writes:
> On Fri, Apr 12, 2002 at 04:00:37PM +0100, Piers Cawley wrote:
>>
>> [EMAIL PROTECTED] writes:
>> > As for "cleanness", this is my interpretation of how perl6 is going
>> > to work:
>> >
>> > %foo = ();
>> > if %foo {"key"} {print "Hello 1"}
>> >
>> >
[EMAIL PROTECTED] writes:
> As for "cleanness", this is my interpretation of how perl6 is going
> to work:
>
> %foo = ();
> if %foo {"key"} {print "Hello 1"}
>
> %foo = ();
> if %foo{"key"} {print "Hello 2"}
>
> %foo = ();
> if %foo{"key"}{print "Hello 3"
On Fri, 2002-04-12 at 09:52, Jonathan Scott Duff wrote:
> On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
> > > sub printRec() { printRec($_) } # No args, therefore no new topic.
> > > sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
> >
> > I think was he was s
On Fri, Apr 12, 2002 at 09:26:45AM +0100, Piers Cawley wrote:
> Trey Harris <[EMAIL PROTECTED]> writes:
>
> > I think I've missed something, even after poring over the archives for
> > some hours looking for the answer. How does one write defaulting
> > subroutines a la builtins like print() and
On Fri, 2002-04-12 at 00:37, Melvin Smith wrote:
> At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
> >Notice that we have two different types of defaulting here. The second
> >argument is the file to work on, and we set it to a reasonable default
> >if it is undefined for whatever reason. Howev
On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
> On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
> > Trey Harris <[EMAIL PROTECTED]> writes:
> >
> > > I think I've missed something, even after poring over the archives for
> > > some hours looking for the answer. How does one wri
On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
> Trey Harris <[EMAIL PROTECTED]> writes:
>
> > I think I've missed something, even after poring over the archives for
> > some hours looking for the answer. How does one write defaulting
> > subroutines a la builtins like print() and chomp()? Ass
On Friday 12 April 2002 08:21 am, Michel J Lambert wrote:
> > I thought the point of the discussion was turning off the GC until such
time
> > that it was ready to go. I know what it *does* - what should it *do*?
> >
> > {Rest of the comments snipped.}
>
> I don't know quite what you mean by wh
> I thought the point of the discussion was turning off the GC until such time
> that it was ready to go. I know what it *does* - what should it *do*?
>
> {Rest of the comments snipped.}
I don't know quite what you mean by what 'should it *do*'? *do*, as in
what it should do with my patch? Or *d
> compared to a current CVS version of:
> 5000 generations in 90.813806 seconds. 55.057708 generations/sec
> A total of 32768 bytes were allocated
> A total of 130932 DOD runs were made
> A total of 10930 collection runs were made
> Copying a total of 57801936 bytes
>
> so a 97% decrease in the nu
On Friday 12 April 2002 03:22 am, Michel J Lambert wrote:
> > > So you're saying that the calls to get memory during interpreter
> > > initialization are somehow guaranteed to not require more memory (and
thus
> > > a dod or collection run)? Currently, this guarantee is not expressed in
> >
> > I
On 04/11/02 Dan Sugalski wrote:
> I'm not sure which is worse--the amount of data we're copying around,
> or the fact that we eat Mono's lunch while we do so.
:-)
Could you post the code for the sample? Is it based on the snipped Simon
posted a while ago where it used the pattern:
strin
"Michel J Lambert" wrote:
> Below is a patch which allocates the pools from system memory.
> Unfortunately, it doesn't seem to provide any noticeable speed gains. I
> get anywhere from a -1 to 15 extra generations per second. Current results
Even though we copy large amounts of memory around, ve
> The current design never shrinks the free header pools, and indeed there is
> probably little point in doing so, so nothing seems to be gained from
> including them in the collection process.
>
> Using my favourite 5000-generation life.pasm as an example:
> A total of 10930 collection runs were
The string_grow function (currently used only by string_replace) does not
allocate a new buffer if there are no bytes to be copied from old buffer to
new buffer. Patch below fixes this.
--
Peter Gibbs
EmKel Systems
Index: string.c
=
Trey Harris <[EMAIL PROTECTED]> writes:
> I think I've missed something, even after poring over the archives for
> some hours looking for the answer. How does one write defaulting
> subroutines a la builtins like print() and chomp()? Assume the code:
>
> for <> {
> printRec;
> }
> pri
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for <> {
printRec;
}
printRec "Done!";
sub printRec {
chomp;
print
Michel J Lambert wrote:
> Right. However, that's not to say that memory cannot grow. The interpreter
> allocates the various *_pools from the interpreter's memory_pool, and it
> gets copied with each collection run. This memory can grow and change in
> size as more memory for pools are needed. Cu
> > So you're saying that the calls to get memory during interpreter
> > initialization are somehow guaranteed to not require more memory (and thus
> > a dod or collection run)? Currently, this guarantee is not expressed in
>
> I don't understand the "thus." Nothing states that requesting memory
51 matches
Mail list logo
