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 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 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
> > 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
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 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
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
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
19 matches
Mail list logo
