Jonathan Lang writes:
> I've just been rereading the recent discussions, and I noticed something
> that I missed the first time:
>
> Larry Wall wrote:
> > Traits are not definitional but rather operationally defined in the
> > worst way. That's why traits are renegade roles. They don't play by
Perhaps some of you may be interested in this
entry from Miguel de Icaza's web log:
Python running fast on .NET
http://primates.ximian.com/~miguel/archive/2003/Dec-09.html
Wasn't there supposed to be a Python/Parrot challenge this month?
If so, who won and where are the results?
___
Nothing to see here, unless you use Windows, in which case this might
have a chance of working.
Bug reports welcome.
No, wait. I take that back.
Enjoy.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
On Dec 21, 2003, at 5:44 PM, Dan Sugalski wrote:
At 5:31 PM -0800 12/21/03, Jeff Clites wrote:
It sounds like an assumption here is that separate threads get
separate interpreter instances. I would have thought that a typical
multithreaded program would have one interpreter instance and
multipl
At 5:31 PM -0800 12/21/03, Jeff Clites wrote:
It sounds like an assumption here is that separate threads get
separate interpreter instances. I would have thought that a typical
multithreaded program would have one interpreter instance and
multiple threads (sharing that instance). I would think o
It sounds like an assumption here is that separate threads get separate
interpreter instances. I would have thought that a typical
multithreaded program would have one interpreter instance and multiple
threads (sharing that instance). I would think of separate interpreter
instances as the analo
I've just been rereading the recent discussions, and I noticed something
that I missed the first time:
Larry Wall wrote:
> Traits are not definitional but rather operationally defined in the
> worst way. That's why traits are renegade roles. They don't play by
> the rules.
In other words, a
Larry Wall wrote:
> Larry Wall wrote:
> : Jonathan Lang wrote:
> : : Why not do it the same way that namespace scoping collisions are
> : : resolved: the local scope trumps the caller's scope. Rinse, lather,
> : : repeat.
>
> Actually, I didn't see that you said "caller's scope". That would im
# New Ticket Created by Frederick Alexander Thomssen
# Please include the string: [perl #24728]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24728 >
hi,
I ran into troubles when installing perl 5.8.1/5.8.2/5.9.0 on a SuS
"A. Pagaltzis" <[EMAIL PROTECTED]> writes:
> * The Perl 6 Summarizer <[EMAIL PROTECTED]> [2003-12-16 11:57]:
>> bear in mind that the authors of the paper use the term
>> 'trait' for what we're calling a 'role' (We already have
>> traits you see).
>>
>> http://www.cse.ogi.edu/~bla
Allison Randal <[EMAIL PROTECTED]> writes:
> Piers wrote:
>>
>> p6d?
>
> The perl6-documentation list. Started around Nov. 2002, it had about
> 3 months of heavy traffic and not much since. But, we did get a good
> plan for the direction of p6 testing out of it.
I find that the best way to rememb
Elizabeth Mattijsen wrote:
Whenever a PMC gets "shared", it would get changed read and write
function slots of the applicable vtable entries that would add mutexes
around all accesses to that PMC.
Yep. That was my conclusion too. A shared PMC will be a variant of the
plain one, where all vtable
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> At 14:17 +0100 12/21/03, Leopold Toetsch wrote:
>>1) a real global Parrot_base_vtables[] containing pointers to the local
>> *static* temp_base_vtable inside the PMC classes C file.
>>2) another per interpreter vtable array holding all dynamic entr
PerlDiscuss - Perl Newsgroups and mailing lists wrote:
When the official release of Perl 6 is released and I start to write some
Perl 6 programs using Perl 5 modules, will I get any errors? How will this
be handled? Will all of the Perl 5 modules have to be ported over and
converted to Perl 6 code?
At 14:17 +0100 12/21/03, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> Ideally I'd see a COWed structure: a thread startup would not
actually copy the main vtable structure. As soon as something needs
to be specific for the thread, only then needs that structure to be
> I'm currently investigating various issues related to internal
> interpreter data structures and multiple threads.
> Here is one, that need some design decision:
>
> Parrot_base_vtables[] (the master array of all registered vtables) is
> currently a true global. This causes nice errors and seg
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
Hi Liz,
> Please note that these are comments from a Parrot list lurker and
> outsider, but also as someone with some hands on experience with Perl
> threads... ;-) And probably stating the bleedingly obvious.
I'm appreciating your (and of course
Please note that these are comments from a Parrot list lurker and
outsider, but also as someone with some hands on experience with Perl
threads... ;-) And probably stating the bleedingly obvious.
At 11:09 +0100 12/21/03, Leopold Toetsch wrote:
*If* ParrotClasses are per thread (very likely y
When the official release of Perl 6 is released and I start to write some
Perl 6 programs using Perl 5 modules, will I get any errors? How will this
be handled? Will all of the Perl 5 modules have to be ported over and
converted to Perl 6 code? Can I have a basic perl6.pl file while using the
stand
I'm currently investigating various issues related to internal
interpreter data structures and multiple threads.
Here is one, that need some design decision:
Parrot_base_vtables[] (the master array of all registered vtables) is
currently a true global. This causes nice errors and segfaults on
i
20 matches
Mail list logo
