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 tw
> 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, py
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 addre
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 ad
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'
>
> 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 sor
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,
bu
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) {
> -//
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'. Confi
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
> > mem_r
> 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
I would actually further this sort of activity.
I admire micro-kernel-type systems. C and Java give you no functions out of
the box. Keywords are just that, keywords. I believe python is like this
as well. The idea being that everything has to come from a module.. This
limits how much a new de
>sub do_stuff {
>my $self = self;
>$self->{STATE}->{something} = @_;
>}
>
>sub error {
>carp @_ if self->config('VerboseErrors');
>}
I've never really seen anything like this before in other languages (Is that
good or bad?). The closest is Java's odd use o
> >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 langu
> If you want to change STUPID behaviour that should be avoided by current
> programs (such as empty regexes) fine.
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
> >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, an
I like a lot of what is in this RFC. It rings true for me, since my favorite CPAN
modules are OO. The less I need to learn about a package, the happier I tend to be.
Also, powerful objects tend to be slower (though it's getting better).
I haven't seen all of the discussion reguarding this RF
- 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
>
>
> T
- 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/
>
>
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 10:06 PM
Subject: RFC 169 (v1) Proposed syntax for matrix element access and slicing.
> I propose the use of ';' as a separator for index te
>
> 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 { ... };
> More functions from set theory to manipulate arrays
>
> I'd like to use these functions in this way :
>
> @c = union (@a, @b);
> # wich is different from @c = (@a, @b) because union do not duplicate
> same elements
>
> @c = intersection (@a, @b);
> @c = diff(@a, @b);
>
Elements of this ar
- 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
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
debug
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Subject: Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145
(alternate approach))
> How about qy() for Quote Yacc :-) This stuff is starting to look
> more and more like we're trying to fold lex and yacc int
- 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>>|])/;
> The
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Subject: Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145
(alternate approach))
> On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote:
> > What if we added special XML/HTML-parsing ?< and ?> operato
>
> 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
abo
> 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 th
> Ban Perl hooks into regexes
>
> =head1 ABSTRACT
>
> Remove C, C 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 or inside st
> 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 app
> 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 bes
> Ordered bytecode
>
> Bytecode should be structured in such a way that reading and executing
> it can be parallelised.
>
Are you suggesting a threaded VM? I know that the core is being rewritten,
so it's a possibility. If this is the case, then you'll want to reference
some of the other RFC's
> On 25 Sep 2000 20:14:52 -, Perl6 RFC Librarian wrote:
>
> >Remove C, C 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,
>
> /(?
> would only match integ
> 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
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 standa
From: "Hugo" <[EMAIL PROTECTED]>
> :Remove C, C 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 (?{ }).
Basically the code-like
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 no
40 matches
Mail list logo
