On Thursday 21 August 2003 21:40, Brent Dax wrote:
# we're already running with a faster opcode dispatch
Man I wish I had the time to keep up with parrot development. Though, as
others have pointed out, the core archetecture is somewhat solidified by this
point, I thought I'd put in my
On Fri, 15 Feb 2002, Alex Gough wrote:
On Thu, 14 Feb 2002, Dan Sugalski wrote:
To allocate memory that is GCable, call Parrot_allocate(interpreter,
size). Then stash the pointer and size in your buffer header, or
it'll go missing later. To resize a chunk of memory, call
On Fri, 7 Dec 2001, Andy Dougherty wrote:
On Fri, 7 Dec 2001, Bryan C. Warnock wrote:
On Friday 07 December 2001 08:43 am, Andy Dougherty wrote:
Funny you should mention that, because Perl's Configure does things in
order determined by 'Dependency-ish rules, a la make'. Configure is
While your point is taken, it's hardly considered C++ anymore. Many
C-compilers have adopted many such useful features.
On Wed, 28 Nov 2001, Andy Dougherty wrote:
diff -r -u parrot-current/classes/perlnum.pmc parrot-andy/classes/perlnum.pmc
void set_integer (PMC* value) {
-//
I've done a bunch of reading, and though I'm not finished, I'm starting to
look towards the following overall algorithm based on the below specified
assumptions. I'm not _necessarily_ looking for comments at this point,
because I haven't finished evaluating the specifics of several algorithms,
On Mon, 5 Nov 2001, Dan Sugalski wrote:
At 12:23 AM 11/5/2001 -0800, Brent Dax wrote:
Michael L Maraist:
[reordered for clarity]
But I hear that we're not relying on an
integer for
reference counting (as with perl5), and instead are mostly
dependant on the
GC.
You're conflating
On Fri, 19 Oct 2001, Dan Sugalski wrote:
At 01:24 PM 10/19/2001 -0400, Gregor N. Purdy wrote:
James --
Should we have bsr(i|ic, i|ic), that jumps to $1, with the return
address below the $2 arguments? Similarly, should we have ret(i|ic),
that rotates the return address out
On Fri, 19 Oct 2001, Gregor N. Purdy wrote:
Dan --
FWIW, I'd rather not dedicate registers to special uses at the Parrot
level. Jako reserves [INPS]0 for temporaries, but that is at its
discretion, not dictated by Parrot (and I like it that way :). I was
wishing for separate data and
Dan Sugalski wrote:
How does python handle MT?
Honestly? Really, really badly, at least from a performance point of view.
There's a single global lock and anything that might affect shared state
anywhere grabs it.
i.e. not so much 'threaded' as 'stitched up'.
Well, python never
I generally divide signals into two groups:
*) Messages from outside (i.e. SIGHUP)
*) Indicators of Horrific Failure (i.e. SIGBUS)
Generally speaking, parrot should probably just up and die for the first
type, and turn the second into events.
I don't know. SIGHUP is useful to
or have entered a muteX,
If they're holding a mutex over a function call without a
_really_ good reason, it's their own fault.
General perl6 code is not going to be able to prevent someone from
calling code that in-tern calls XS-code. Heck, most of what you do in
perl involves some sort of
From: "Dave Storrs" [EMAIL PROTECTED]
Both \1 and $1 refer to what is matched by the first set of parens in a
regex. AFAIK, the only difference between these two notation is that \1
is used within the regex itself and $1 is used outside of the regex. Is
there any reason not to standardize
On 25 Sep 2000 20:14:52 -, Perl6 RFC Librarian wrote:
Remove C?{ code }, C??{ code } and friends.
I'm putting the finishing touches on an RFC to drop (?{...}) and replace
it with something far more localized, hence cleaner: assertions, also in
Perl code. That way,
/(?!\d)(\d+)(?{$1
There is, but as MJD wrote: "it ain't pretty". Now, semantic checks or
assertions would be the only reason why I'd expect to be able to execute
perl code every time a part of a regex is succesfully parsed. Simply
look at RFC 197: a syntactic extension to regexes just to check if a
number is
Ban Perl hooks into regexes
=head1 ABSTRACT
Remove C?{ code }, C??{ code } and friends.
At first, I thought you were crazy, then I read
It would be preferable to keep the regular expression engine as
self-contained as possible, if nothing else to enable it to be used
either outside Perl
Many mechanisms exist to make perl code and data persistant. They should
be cleaned up, unified, and documented widely within the core
documentation.
But doesn't this go against TMTOWTDI. :)
Different people might have different requirements. Portability would want
all ASCII, large apps
So, we check for the existence of a C.plc file before running a
program; if the C.plc file is newer than the program, we use that
instead. If there isn't a C.plc file or it's older than the program,
recompile and dump the bytecode to a C.plc file. Naturally, this gives
us the best speedup
From: "Hugo" [EMAIL PROTECTED]
:Remove C?{ code }, C??{ code } and friends.
Whoops, I missed this bit - what 'friends' do you mean?
Going by the topic, I would assume it involves (?(cond) true-exp |
false-exp).
There's also the $^R or what-ever it was that is the result of (?{ }).
From: "Simon Cozens" [EMAIL PROTECTED]
A lot of what is trying to happen in (?{..}) and friends is parsing.
That's not the problem that I'm trying to solve. The problem I'm trying
to solve is interdependence. Parsing is neither here nor there.
Well, I recognize that your focus was not on
my/our @array :hashsyntax;
would hide the definition of %array in the same way that
my/our %array
would hide a prior definition of %array. And references to %array
would thenceforth actually be references to the keyed array @array.
I can see massive confusion from this.
This RFC proposes a minimal efficient well-scaling mechanism for
exporting.
Only export of subroutines and tags are supported by this mechanism.
Though I'm not completely sure how the implementation works in other
compiled languages, I rather like the C, Java, Python method where just
about
- Original Message -
From: "Richard Proctor" [EMAIL PROTECTED]
Sent: Tuesday, September 05, 2000 1:49 PM
Subject: Re: RFC 145 (alternate approach)
On Tue 05 Sep, David Corbin wrote:
Nathan Wiger wrote:
But, how about a new ?m operator?
/(?m|[).*?(?M|])/;
There already is a
use Thread;
$thread = new Thread \func , @args;
$thread = new Thread sub { ... }, @args;
async { ... };
$result = join $thread;
$thread = this Thread;
@threads = all Thread;
$thread1 == $thread2 and ...
yield();
critical { ... }; # one thread at
I'll be brief because windows just crashed on me.
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Second, lexically scoped variables will dissapear on subsequent debugger
lines since their scope is wrapped in an eval. For the most part, the
- Original Message -
From: "Perl6 RFC Librarian" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, August 29, 2000 8:59 PM
Subject: RFC 2 (v3) Request For New Pragma: Implicit
Request For New Pragma: Implicit
Good idea, but you have it backwards.. If
- Original Message -
From: "Perl6 RFC Librarian" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, August 29, 2000 10:19 PM
Subject: RFC 171 (v1) my Dog $spot should call a constructor implicitly
my Dog $spot should call a constructor implicitly
The
- Original Message -
From: "Perl6 RFC Librarian" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, August 29, 2000 10:20 PM
Subject: RFC 172 (v1) Precompiled Perl scripts.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1
Simple solution.
If you want to require formats such as m/.../ (which I actually think is
a
good idea), then make it part of -w, -W, -ww, or -WW, which would be a
perl6
enhancement of strictness.
That's like having "use strict" enable mandatory perlstyle compliance
checks, and rejecting
I don't understand this desire to not want anything to change.
You misread.
I sympathise. There are definate goals and focuses that each language is
built around.. Change these too much, and you have a different language,
while at the same time, alienating the people that chose that language
my var; # declaring a scalar
my array[]; # declaring an array
my hash{}; # declaring a hash
Though the declarations seem fine, I assume that you propose this to be
optional at usage time, since variable interpolations such as
"xxx${var1}xxx${var2}xxx" really need the prefix. One of
Personally, I prefer a python, or matlab implementation:
array1 = array2[ start : stop ].
Of course, In perl we have the .. operator. This method has just always
seemed intuitive to me. Granted an explicit function call (or gasp, another
reg-ex like call), aids the newbies eyes. The trick in
31 matches
Mail list logo
