John Porter <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Juergen Boemmels <[EMAIL PROTECTED]> writes:
>> > But how do I represent them at parrot-level.
>>
>> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
>
> Etc.
> The point being, we're building these things into par
Juergen Boemmels <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> writes:
>
>
> [...]
>
>> >> Cool, applied. How far from "real" scheme are we?
>> >
>> > I think its quite far.
>> > The first thing is symbols and strings. But how do I represent them at
>> > parrot-level. PerlString
> I'm talking about just in the same namespace, how
> do we keep rules from messing with file-scoped
> (or any-scoped, for that matter) lexicals or globals.
> How do we get rule- or closure-scoped lexicals
> that are put into $0?
How about something like the following rework of
the capture/hypoth
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #17109]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17109 >
Hi,
the next patch to languages/scheme. It implements the quote and a
first cut of d
imcc (0.0.9) has an integrated parrot interpreter and tries to write out
a PBC file too. Running code succeeds currently for ~95 % of perl6
tests (in half the time ;-).
But I've problems in writing out the .pbc, especially Const_Table, type
PFC_KEY / PARROT_ARG_SC (and _NC if one would use t
Luke Palmer fretted:
> This is terrible. Calling foo which calls bar mysteriously overwrites
> $date? "Why is $date changing?" the programmer asks. He does an
> exhaustive search through his code and finally says "ohh," and has to
> change all references to the inner $date to something
On Mon, 9 Sep 2002, Will Coleda wrote:
> Nicholas Clark wrote:
> > On Mon, Sep 09, 2002 at 03:02:55PM -0400, Andy Dougherty wrote:
> > For development and testing, I believe that we should exercise (and then
> > exorcise) all the bugs in all the languages we can find.
> Any particular reason no
"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests
(including t/compiler/8_5.p6) now correctly, _if_ GC is turned off.
$ perl6 --test # run through assembler / parrot
All tests successful, 2 subtests skipped.
Files=17, Tests=72, 1 wallclock secs ( 0.16 cusr + 0.04 c
The Perl 6 Summary for the Week Ending 20020908
Well, what a week it's been eh people? Larry's been telling the Slashdot
crowd about quantum god and big knobs, there's been a call for Perl 6
programmers on Perlmonks (http://makeashorterlink.com/?L51631EB1), and
the Octarine parrot
Piers Cawley wrote:
>
> >> Juergen Boemmels <[EMAIL PROTECTED]> writes:
> >> > But how do I represent them at parrot-level.
>
> Thanks for that John. I always relish being patronized.
You're welcome, but that wasn't for you, that was for Juergen
and anyone else who might have been wondering the
John Porter <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>>
>> >> Juergen Boemmels <[EMAIL PROTECTED]> writes:
>> >> > But how do I represent them at parrot-level.
>>
>> Thanks for that John. I always relish being patronized.
>
> You're welcome, but that wasn't for you, that was for Juerge
So, I'm almost done and ready to cut the Builtins patch, but the
following problem has come up:
I get no warnings or errors while it reads and parses the Builtins, but
then Tree.pm throws a number of uninitialized value warnings and then
Context.pm throws an error about not being able to find "ct
On 10 Sep 2002, Aaron Sherman wrote:
> So, I'm almost done and ready to cut the Builtins patch, but the
> following problem has come up:
>
> I get no warnings or errors while it reads and parses the Builtins, but
> then Tree.pm throws a number of uninitialized value warnings and then
> Context.pm
On Tue, 2002-09-10 at 09:35, Sean O'Rourke wrote:
> On 10 Sep 2002, Aaron Sherman wrote:
>
> > So, I'm almost done and ready to cut the Builtins patch, but the
> > following problem has come up:
> >
> > I get no warnings or errors while it reads and parses the Builtins, but
> > then Tree.pm throw
On Mon, 9 Sep 2002, Andy Dougherty wrote:
> 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> INTVAL='long long'. This configuration used to work quite recently.
The immediate culprit was config/gen/core_pmcs.pl, which now puts out
prototypes of
extern void Parrot
On Mon, 9 Sep 2002, Andy Dougherty wrote:
> On Mon, 9 Sep 2002, Andy Dougherty wrote:
>
> > 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> > INTVAL='long long'. This configuration used to work quite recently.
>
> I've at least figured out why it core dumps -- do_panic(
Attached is a sample implementation of a minor subset of
pack/unpack functionality. Code is not optimised in any way,
and error checking is basically non-existent.
Opcodes are:
convert Sx, Iy, Iz - pack integer Iy into string Sx per type Iz
convert Ix, Sy, Iz - unpack integer Ix from
On Tue, 2002-09-10 at 12:01, Peter Gibbs wrote:
> Attached is a sample implementation of a minor subset of
> pack/unpack functionality. Code is not optimised in any way,
> and error checking is basically non-existent.
>
> Opcodes are:
> convert Sx, Iy, Iz - pack integer Iy into string Sx pe
On Tue, Sep 10, 2002 at 06:01:23PM +0200, Peter Gibbs wrote:
> Attached is a sample implementation of a minor subset of
> pack/unpack functionality. Code is not optimised in any way,
> and error checking is basically non-existent.
>
> Opcodes are:
> convert Sx, Iy, Iz - pack integer Iy into
Graham Barr wrote:
> As well as supporting big/little endian specifically, should we support
"native"
> ie packed in the same endian as the machine the code is being run on.
Certainly. I think we would want also want native sizes, so we can
ask for short, int, long etc and get the platform's siz
--- Ramesh Ananthakrishnan <[EMAIL PROTECTED]> wrote:
> Is it possible to write networking code in Parrot?
Not yet. Someday there will probably be a Sockets extension for parrot (not
really used enough to justify being in the core)
__
Yahoo! - We R
The following two lines of Perl 6 causes the compiler to recurse
infinitely, which shows off Perl 5's recursion detection quite nicely :)
my $x = 1;
$x = +$x;
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Piers Cawley <[EMAIL PROTECTED]> writes:
[...]
> > There is already a ScratchPadPMC. Where is it? It's not in classes/,
> > is it. As a first implementation a PerlHash is sufficent, (I actually
> > have a patch doing exactly this, it just needs a little polish. Maybe
> > I will submit it tomorr
If I want to tell Configure.pl that it needs to look in /foo/bar for
some extra include files, is there a way to convince Configure to
append that to $Config{ccflags} other than hacking config/init/data.pl?
I did this, but it is quite ugly
perl Configure.pl --ccflags="`perl -MConfig -e 'print $
Juergen Boemmels <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> writes:
[...]
>> typeof is a *really* bad idea. Let the 'Object' PMC handle the
>> multilevel vtable look up (in exactly the same way that one does
>> lexical lookup in the environment chain) and method invocation. So,
On Tue, Sep 10, 2002 at 07:26:58PM +0200, Peter Gibbs wrote:
> Graham Barr wrote:
>
> > As well as supporting big/little endian specifically, should we support
> "native"
> > ie packed in the same endian as the machine the code is being run on.
>
> Certainly. I think we would want also want nati
On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote:
> This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since
> the prototypes are hidden in the C file, not in a shared header file, the
> compiler doesn't warn about them.) Upon reflection, however, since the
extern
Another bug. This injects a stringified reference into the IMC:
sub xyz(*@rest) { }
xyz([1,2]);
xyz([]); # This one is probably the same
Got a chance to narrow this one down while I was in a meeting :)
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Sorry if this comment is out of context, I am behind but catching
up. The patch in [perl #16797] adds a scratchpad pmc (among other
things). Hopefully it is not too far out of date to apply. I
believe Melvin is looking into it ...
--
Jonathan Sillito
On Tue, 10 Sep 2002, Piers Cawley wrote:
> J
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17120]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17120 >
The following patch removes two no-longer-needed hints files.
They are remnants of th
I am not the best one to answer these questions, but I will
make some comments anyway, though Dan is/was planning to give
us an authoritative position doc on some of these issues.
I have done some work on some of this, but my latest code
submission has not been accepted yet.
On 9 Sep 2002, Juerg
This short bit of code does a good job of pointing out two bugs. One is
that the C<*@y> sucks up ALL of the arguments, not just C<@_[1..@_]>,
and also that C<"\$x"> prints a lone backslash.
Please correct me if I've misused these operators. Thanks!
sub abc($x,*@y) {
die "Why is \
Here's my latest bug, which I will work on tracking down. It's a pretty
huge blocker for everything I've been working on, so there's no sense in
spending my time elsewhere:
sub def ($arg) {
return $arg;
}
$o = 25;
$q = def($o);
die "Why is return value $q?" unless
On 10 Sep 2002, Aaron Sherman wrote:
>
> Here's my latest bug, which I will work on tracking down. It's a pretty
> huge blocker for everything I've been working on, so there's no sense in
> spending my time elsewhere:
>
> sub def ($arg) {
> return $arg;
> }
> $o = 25;
>
On 10 Sep 2002, Aaron Sherman wrote:
> This short bit of code does a good job of pointing out two bugs. One is
> that the C<*@y> sucks up ALL of the arguments, not just C<@_[1..@_]>,
> and also that C<"\$x"> prints a lone backslash.
>
> Please correct me if I've misused these operators. Thanks!
>
35 matches
Mail list logo
