[EMAIL PROTECTED] (John Siracusa) writes:
> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
> and runs.
It *could* do this, but loading bytecode in Perl 5 is slower than loading
and compiling source, so there's not really much point. What's so magic
about bytecode, anyway
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> The only issue I see atm is if parrot wants to call the callback it-
> self while in the "waiting for callback loop", mean it would run into
> some race conditions if for some reasons parrot invokes the callback,
> and somebody triggers the callback via g
Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 04, 2004 at 09:47:29AM +0200, Leopold Toetsch wrote:
>: Honestly I don't see the point why all "normal" array usage should be
>: slowed down just for the sake of some rare usage patterns.
> Does it have to? Couldn't it have a different vtable?
As it stands, though, perl6-internals isn't about perl, but Parrot ...
so of the two lists, language is arguably more appropriate...
On Sun, 5 Sep 2004 22:37:04 -0400, Matt Diephouse <[EMAIL PROTECTED]> wrote:
> I may be completely off base here, but I think this whole discussion
> would be bette
On Sat, 2004-09-04 at 17:59, John Siracusa wrote:
> Actually, the other day I was thinking about how I tend to create any useful
> perl program that I plan to distribute in the form of a big, monolithic
> script. Take the distribution out of the equation and I'd write a series of
> generic module
Taking this to p6i, in order to get Parroty for a few
On Thu, 2004-09-02 at 19:47, Larry Wall wrote:
> =head1 Overview
>
> This synopsis summarizes the non-existent Apocalypse 9, which
> discussed in detail the design of Perl 6 data structures.
[...]
> =head1 Sized types
>
> Sized low-leve
"Joe Gottman" <[EMAIL PROTECTED]> writes:
> In perl 6, the statement
>
> @foo = (1.. 5) ;
>
> is equivalent to
>
> @foo = (1, 2, 3, 4, 5);
>
>
>
> Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? I know you can
> go
>
> @foo = reverse (1
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> this patch adds a POD section on top of 'src/nci_test.c'. I also tried to
> make 'nci_test.c' more conformant to the coding standards from 'pdd07'.
Thanks, applied.
leo
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> The gcc check should come *after* choosing the compiler, and optimizer flags
> should only be chosen after you actually have a compiler. The patch
> below fixes these things.
Thanks, applied. This fixes bug ticket #31446 too.
> Alas, there's a problem
The Perl 6 Summary for the week ending 2004-09-03
Another week, a free weekend, and still I haven't started writing the
summary until Monday. Still, I don't actually start at college 'til next
week, so that's all right then.
We start with perl6-internals.
Compile op with return
On Sun, 5 Sep 2004, Clayton O'Neill wrote:
> This adds support for setting triggers on specific config variables.
> The basic idea is that you can register a named callback for any
> specific config variable. When that variable is set, all the
> callbacks registrered for that variable will be cal
On Mon, 6 Sep 2004 11:48:59 +, Herbert Snorrason <[EMAIL PROTECTED]> wrote:
> As it stands, though, perl6-internals isn't about perl, but Parrot ...
> so of the two lists, language is arguably more appropriate...
perl6-internals is about perl the implementation (which is parrot).
perl6-languag
On 9/6/04 3:48 AM, Simon Cozens wrote:
> [EMAIL PROTECTED] (John Siracusa) writes:
>> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
>> and runs.
>
> It *could* do this, but loading bytecode in Perl 5 is slower than loading
> and compiling source, so there's not really m
On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote:
> Finally, platform independent execution of any packaged or precompiled
> single file will *require* cooperation (core support) from the perl
> executable itself. PAR is neat, but it doesn't even match up that well with
> JAR, which
On Sun, Sep 05, 2004 at 10:40:24AM -0400, John Siracusa wrote:
> 3. The single-file, platform independent, non-source executable (P6exe).
> This is bytecode or some other platform neutral representation of the SDoF.
> I just don't see how to do this at all without core support. (Well, I
> suppose
On 9/6/04 12:13 PM, Nicholas Clark wrote:
> On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote:
>> Finally, platform independent execution of any packaged or precompiled
>> single file will *require* cooperation (core support) from the perl
>> executable itself. PAR is neat, but it does
On 9/6/04 12:21 PM, Nicholas Clark wrote:
>> I think packaging has the same characteristics. But unlike CPAN, packaging
>> does require some minimum amount of core support to meet what I consider to
>> be the minimum standard of elegance.
>
> I think that this is true. I'm not sure what the minim
On Mon, Sep 06, 2004 at 12:28:16PM -0400, John Siracusa wrote:
> Hm, well, features of the perl6 executable itself aren't really fodder for
> the parrot lists (are they?)...although I forget where they've been
> discussed in the past. Anyway, the long-suffering internals guys are still
> hashing
Right now configure.pl pulls a bunch of configuration information
straight out of the current perl configuration. We need to stop that,
and this is as good a time as any.
If someone could go through and make a list of what info configure.pl
pulls from perl, I'll start writing (or snagging :) th
Hi all,
there are now two new examples:
examples/sdl/lcd/clock.imc, which uses a simple SDL LCD object and
examples/sdl/minesweeper/mines.imc, a full functional minesweeper clone with
nice graphics (taken over from KMines screenshots).
Minesweeper freezes after you have created some new fields
(not on the list, please Cc me in replies.)
On Sun, Sep 05, 2004 at 08:49:20PM -0400, John Siracusa wrote:
> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
> and runs. It's closest to item #2 in my feature list, but it's something
> very different than compiling down to
On Mon, Aug 30, 2004 at 12:17:57PM -0500, Abhijit Mahabal wrote:
> Another example to clarify what I am getting at:
>
> Role Log2File [: $filename] { method do_the_logging {...}; ... }
> Role Log2Email [: $address ] { method do_the_logging {...}; ... }
> Role Log2Tk[: $widget ] { method do
Leopold Toetsch wrote:
> So first:
> - do we keep these opcodes?
>If yes some permutations are missing.
> - if no,ยด we should either not include experimental.ops in the default
> opcode set or move it to dynops.
I have not used them yet, but I think that they can be useful.
Has anyone else exce
Leopold Toetsch wrote:
> I think, we could use that as well generically. classes/fixedpmcarray
> and some others have it implemented in invoke()
Why not generally use the class'es invoke method to create new PMCs/objects?
$P0 = getclass 'Foo'
obj = $P0( arg1, arg2, arg3... )
.name
> > int1
> > int2
> > int4
> > int8
> > int16
> > int32 (aka int on 32-bit machines)
> > int64 (aka int on 64-bit machines)
>
> Ok, so Parrot doesn't have those. Parrot has "int".
I think it should have those, but I'm not a Parrot developer, I've jused
used PI
[EMAIL PROTECTED] (John Siracusa) writes:
> Don't you think it's preferable to temp-expanding and compiling at runtime?
Not if it's slower, no. The choice was made not to go with bytecode because
of a deficiency in Perl. If that deficiency wasn't there, then sure, go
with bytecode.
But you're mis
On Mon, 2004-09-06 at 12:42, Dan Sugalski wrote:
> Right now configure.pl pulls a bunch of configuration information
> straight out of the current perl configuration. We need to stop that,
> and this is as good a time as any.
>
> If someone could go through and make a list of what info configure
On Mon, Sep 06, 2004 at 10:13:56AM +0200, Leopold Toetsch wrote:
: A different vtable implies some kind of a derived class. The question
: is, if an "of shape" or "is shape" already causes a new class of
: arrayish objects.
: The question probably is: how much of this class code is done directly
:
On Sat, Sep 04, 2004 at 09:47:29AM +0200, Leopold Toetsch wrote:
: Honestly I don't see the point why all "normal" array usage should be
: slowed down just for the sake of some rare usage patterns.
Another possibility is that .[] always forces the "normal" view of an
array as 0-based, and if you w
On Mon, 2004-09-06 at 18:29, Aaron Sherman wrote:
> On Mon, 2004-09-06 at 12:42, Dan Sugalski wrote:
> > If someone could go through and make a list of what info configure.pl
> > pulls from perl, I'll start writing (or snagging :) the probing code
> > to do it ourselves, so we can be perl-free,
On Mon, 2004-09-06 at 18:29, Aaron Sherman wrote:
> I think right now that info is all in config/init/data.pl, and it's
Scratch that. I was grepping through the tree for "Config{" which turns
out to not catch the way %Config is used in most of the tree... I'll
have a look and get you the details.
Mattia Barbon recently implemented the capability to group multiple
dynamic PMCs into a single library. It took me a while, but the correct
way of using it finally percolated through my thick skull. One remaining
problem is that the build process is very platform-dependent. This
patch doesn't fix
On Sep-06, Jens Rieks wrote:
> Leopold Toetsch wrote:
> > So first:
> > - do we keep these opcodes?
> >If yes some permutations are missing.
> > - if no,? we should either not include experimental.ops in the default
> > opcode set or move it to dynops.
> I have not used them yet, but I think th
On Mon, Sep 06, 2004 at 12:42:16PM -0400, Dan Sugalski wrote:
> Right now configure.pl pulls a bunch of configuration information
> straight out of the current perl configuration. We need to stop that,
> and this is as good a time as any.
>
> If someone could go through and make a list of what inf
On Sun, 5 Sep 2004, Matt Diephouse wrote:
> Am I the only one that thinks that -1st should return the last element
> in an array under the nth scheme? 1st should mean the first element.
> -1st should mean the first element of the reversed array.
>
> Don't say -1st is the "first from last". If last
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> I think, we could use that as well generically. classes/fixedpmcarray
>> and some others have it implemented in invoke()
> Why not generally use the class'es invoke method to create new PMCs/objects?
> $P0 = getclass 'Foo'
>
On Tue, Sep 07, 2004 at 07:26:22AM +0200, Robert Schwebel wrote:
> If I can help testing cross compilation stuff please tell me.
> Unfortunately I don't know enough of the Perl/Parrot internals to be
> really useful for coding, but anyway.
Would autoconf/automake be an option for the C part of par
John Williams writes:
> On Sun, 5 Sep 2004, Matt Diephouse wrote:
>
> > Don't say -1st is the "first from last". If last is the opposite of
> > first, I would expect 1st to mean "first from first," which would
> > mean the second. Say "first from the end".
>
> It matches up with perl5 C<$array[-
38 matches
Mail list logo
