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[-
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
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 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
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 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
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 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.
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 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, 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 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
[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
> > 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
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
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
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
(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
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
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
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
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 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 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 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 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 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 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
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
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
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
"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
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
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
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
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?
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
[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
38 matches
Mail list logo
