On Sat, Oct 06, 2001 at 08:19:16AM -0400, Michael Fischer wrote:
> Why were they there?
Because 'l!' does exactly the right thing on Perl version 5.6.0 and
above, and 'l' is not guaranteed to do exactly the right thing.
--
It starts like fascination, it ends up like a trance
You've gotta use
On Saturday 06 October 2001 02:04 am, Gibbs Tanton - tgibbs wrote:
> I think that changing from a function based implementation to a switch
> based implementation will help on many platforms. Someone did a patch on
> that, maybe we could update it and commit it. Having to go through two
> indire
Hello there,
Sorry to disrupt your discussion with some loosely related
question... Could anyone help me determine which development
tools/IDEs are to be used when hacking at Parrot?
As you'd have guessed it, I'm relatively new to this project...
;-). However, I do want to help out with the eff
I think that changing from a function based implementation to a switch based
implementation will help on many platforms. Someone did a patch on that,
maybe we could update it and commit it. Having to go through two
indirections and two array accesses to access a register probably doesn't
help mu
I've done some VERY minor cleanup of a couple of files, removing unused
variables and such from Opcode.pm, removing an unused typedef print from
make_op_header.pl and changing intval to op in disassemble.pl. I also fixed
a typo I did in Assembler.pm.
Tanton
I'll look into bonsai, that will take some work on the cvs server end and
some more effort all the way around, it needs to be done though.
Thanks for the url fixes.
In terms of the renaming, I'll need to hack some stuff in the scripts so you
can still use it the way it was, I'll be at the Apple
On Oct 05, Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> took up a keyboard and
banged out
> As 0.0.3 will be about PMC's, we might as well start hashing out the
> details.
>
> I'd like to take a small example and look at how it should work.
>
> add P1, P2, P3
>
> This should take the PMC in regis
On Fri, 5 Oct 2001, Zach Lipton wrote:
> Wow, great!
>
> I'm not sure about the nohup issue, but I'm looking into it.
>
> We really could use some windows clients and some rare platforms (vms? Etc)
I'll see about setting up cygwin in a bit.
I also changed the urls a bit and made http://tinde
Holding steady.
As a lark, I wrote the functionality of test.pasm (the time test) in Perl,
and ran it under 5.6.1. (Keep it mind, you've got variables that you're
fetching and storing to.)
Parrot Assembler (with the time_n patch, since the elapsed time is so small.
The comma delimeters are
As 0.0.3 will be about PMC's, we might as well start hashing out the
details.
I'd like to take a small example and look at how it should work.
add P1, P2, P3
This should take the PMC in register P2 and add it to the PMC in register P3
and store the result in register P1. To do this, it needs t
On Fri, 5 Oct 2001, Sam Tregar wrote:
> Am I correct that '@' in the assembly syntax is undocumented?
Sounds like it. What's the thing do?
> I think a patch to docs/parrot_assembly.pod would be appropriate. Sound
> good?
Probably the place at the moment. (It really needs to be split into a u
Wow, great!
I'm not sure about the nohup issue, but I'm looking into it.
We really could use some windows clients and some rare platforms (vms? Etc)
Any help you can give would be great. I'll put out a call for clients on
perl-qa as well.
Zach
On 10/5/01 6:53 PM, "Ask Bjoern Hansen" <[EMAIL P
On Fri, 5 Oct 2001, Zach Lipton wrote:
> Also, I don't see any clients running yet, if you are having a problem,
> please let me know so I can fix it!
uh, it didn't work for me when I nohup'ed it (it made blank
reports).
other than that, then I have clients on Linux and FreeBSD
going. Mac OS X
I have committed the two patches I posted recently.
Unfortunately, I was stupid and forgot to do make before make test;
therefore I thought it didn't work, freaked out, and undid the commit.
Then, I figured out my mistake and recommitted the patch.
Here are the comments from the cvs log
This p
Am I correct that '@' in the assembly syntax is undocumented? The only
place I could find it was in source comments in Parrot::Assembler. I had
to search for @ to find it. Believe me, the last thing you want to search
for in a Perl module is @.
I think a patch to docs/parrot_assembly.pod would
On 10/5/01 5:58 PM, "Michael G Schwern" <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 05, 2001 at 05:18:07PM -0700, Zach Lipton wrote:
>> Because the need for a tinderbox testing platform is fairly urgent right now
>> for perl6, I am releasing my (place your favorite adjective in the blank
>> here) ti
On 10/5/01 5:58 PM, "Michael G Schwern" <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 05, 2001 at 05:18:07PM -0700, Zach Lipton wrote:
>> Because the need for a tinderbox testing platform is fairly urgent right now
>> for perl6, I am releasing my (place your favorite adjective in the blank
>> here) ti
On Fri, Oct 05, 2001 at 05:18:07PM -0700, Zach Lipton wrote:
> Because the need for a tinderbox testing platform is fairly urgent right now
> for perl6, I am releasing my (place your favorite adjective in the blank
> here) tinderbox client for perl6 ahead of the near-rewrite that I am working
> on
>From the .02 version, downloaded 8pm EST
||vanveen@parrot|| assemble.pl t/test.pasm > test.pbc
Invalid type in pack: '!' at Parrot/Types.pm line 50.
BEGIN failed--compilation aborted at Parrot/Assembler.pm line 36.
BEGIN failed--compilation aborted at ./assemble.pl line 9.
Removing the '!'s fro
Because the need for a tinderbox testing platform is fairly urgent right now
for perl6, I am releasing my (place your favorite adjective in the blank
here) tinderbox client for perl6 ahead of the near-rewrite that I am working
on to use Devel::Tinderbox::Reporter (which was just written) and
Test:
Grant --
> Explain to me again why we can't move the Test directory so that "make test"
> works on Cygwin? Can't we just 'use lib'? What's the dependency?
> Grant M.
I would love to see both Test and Parrot move under a new directory
lib, so that if we find cause to add more modules that don't s
Explain to me again why we can't move the Test directory so that "make test"
works on Cygwin? Can't we just 'use lib'? What's the dependency?
Grant M.
At 03:07 PM 10/5/2001 -0700, Brent Dax wrote:
>(Dan, did you see my e-mail about this
>patch and haven't replied yet, or did you miss it?)
I saw it, but it fell into the bottomless pit that is my in-box. I'll try
and look at it tonight or tomorrow.
Dan
-
Patch below my sig does three things:
*makes sure that *all* the VMS-specific stuff is in the VMS hints file
*makes test.c return a chunk of eval-able code
*makes test.c return several more sizeof() results (for types like
int, double...)
I especially need the VMS bits tested, as I don't ha
Dan --
> > > > * push_c_i_i_i_v has to be a varop (see my recent posting with
> > > > print_s_v.
> > >
> > > Nope. No vararg ops! :)
> >
> >It might help forestall future flamewars if you explained why.
>
> *) Sheer personal preference, which I realize is a lousy reason. (But
> better to
> We'll be introspective, but probably differently. We at least need to do
> things in ways both perl and python can easily stomach, and I think that's
> going to end up looking different than this will.
>
And ruby ;-)
Benoit
Uri --
> NT> Dan Sugalski writes:
> >> > * push_c_i_i_i_v has to be a varop (see my recent posting with
> >> > print_s_v.
> >>
> >> Nope. No vararg ops! :)
>
> NT> It might help forestall future flamewars if you explained why.
>
> this has been covered several times before. f
Dan --
> > * Registers C0-C31 contain code (CV's)
>
> At the moment I'm not leaning towards special registers for code. Subs will
> just be another type of PMC, and use the PMC registers.
Special C* regs or P* regs with CV values both work fine for what
I'm talking about (I refuse to actuall
At 01:33 PM 10/5/2001 -0600, Nathan Torkington wrote:
>Dan Sugalski writes:
> > > * push_c_i_i_i_v has to be a varop (see my recent posting with
> > > print_s_v.
> >
> > Nope. No vararg ops! :)
>
>It might help forestall future flamewars if you explained why.
*) Sheer personal preference, w
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Dan Sugalski writes:
>> > * push_c_i_i_i_v has to be a varop (see my recent posting with
>> > print_s_v.
>>
>> Nope. No vararg ops! :)
NT> It might help forestall future flamewars if you explained why.
this has b
Dan Sugalski writes:
> > * push_c_i_i_i_v has to be a varop (see my recent posting with
> > print_s_v.
>
> Nope. No vararg ops! :)
It might help forestall future flamewars if you explained why.
> We'll be introspective, but probably differently. We at least need
> to do things in ways bot
At 12:40 PM 10/5/2001 -0400, Gregor N. Purdy wrote:
> * Registers C0-C31 contain code (CV's)
At the moment I'm not leaning towards special registers for code. Subs will
just be another type of PMC, and use the PMC registers.
> * push_c_i_i_i_v has to be a varop (see my recent posting with
>
At 12:05 AM 10/5/2001 -0400, Bryan C. Warnock wrote:
>On Thursday 04 October 2001 11:40 pm, Gibbs Tanton - tgibbs wrote:
> > >Well, that obviously should be MAX_whatever and MIN_whatever.
> > >But sufficient for now, since that's probably a configure thing.
> >
> > Yes and No. If our inline const
At 12:47 PM 10/5/2001 -0400, Bryan C. Warnock wrote:
>[1] Except floats are horrendously non-portable anyway, so that's probably a
>very bad example.
Horrendously non-portable. I think I've docs for at least a half-dozen
different formats... :(
Dan
-
All --
Here's the details from the commit log:
* Compiler:
* User-defined subroutines.
* Generates assembly code with the Jako code in comments.
* "end;" no longer required at the end of programs.
* Better handling of const-reg and reg-const.
* Opti
On Friday 05 October 2001 12:02 pm, Gibbs Tanton - tgibbs wrote:
> Bryan wrote --
>
> >The header portion may need some work
>
> I'm a little confused by what this means...is this something the patch can
> address?
Oh, sorry, no. Just thinking aloud about how the header information - from
t
All --
In the interest of completely twisting your brain...
Imagine what this piece of code could do:
clear C1
const C1, I1, "Hello, "
const C1, I2, "world!\n"
const C1, I3, ":CORE"
const C1, I4, "print_sc"
const C1, I5, "ret"
push C1, I6, I3, I4, I1
push
Bryan wrote --
>The header portion may need some work
I'm a little confused by what this means...is this something the patch can
address?
Tanton
Dan --
> Well, your patch has this:
>
> + gettimeofday(&t);
>
> but the man page I have handy (Solaris 5.something) says:
>
> int gettimeofday(struct timeval *tp, void * );
D'Oh!
OK. Updated patch attached.
Re: Portability, I suppose for now we could make a test for the
presence of getti
At 11:12 AM 10/5/2001 -0400, Bryan C. Warnock wrote:
>Is it safe to say that all the data (the values themsevles - the opcodes and
>opcode arguments (registers, constants, constant table lookups, jump
>offsets, etc)) within the bytecode are exactly and invariably 32 bit, but
>the size of the type
At 11:17 AM 10/5/2001 -0400, Andy Dougherty wrote:
> >but the man page I have handy (Solaris 5.something) says:
> >
> > int gettimeofday(struct timeval *tp, void * );
> >
> >and:
> >
> > The second argument to gettimeofday() and settimeofday()
> > should be a pointer to NULL.
>
>(we
>but the man page I have handy (Solaris 5.something) says:
>
> int gettimeofday(struct timeval *tp, void * );
>
>and:
>
> The second argument to gettimeofday() and settimeofday()
> should be a pointer to NULL.
(wearing my portability hat here . . . ) And, of course, note that
getti
Is it safe to say that all the data (the values themsevles - the opcodes and
opcode arguments (registers, constants, constant table lookups, jump
offsets, etc)) within the bytecode are exactly and invariably 32 bit, but
the size of the type that they're stored in may be whatever is comfortable
At 08:25 AM 10/5/2001 -0400, Gregor N. Purdy wrote:
>Anyone else out there that finds this odd? Better still, anyone out
>there that can shed some light on this one?
Well, your patch has this:
+ gettimeofday(&t);
but the man page I have handy (Solaris 5.something) says:
int gettimeofday(str
I just uploaded a new version of Parrot::Smoke to CPAN.
Changes:
0.02 Fri Oct 05 06:57:20 2001
- support for sending mail through Net::SMTP
- autonfiguration through Makefile.PL should work
on Win32
- eliminated --define/--defaults from output
Regards
Mattia
All --
I was toying with the test.pasm benchmarking file while working with
the Jako compiler. I tried to change time_n to use gettimeofday() to
achieve sub-second resolution. The patch is trivial, but applying it
here causes t/op/time.t to fail on the time_n test.
I copied the test in question
Ask --
> would anyone object to moving parrot/little_languages/* to
> parrot/languages/jako/? Then we can add the beginnings of the other
> compilers to parrot/languages/{perl|ruby|python|Foo|C}
I'd appreciate it if this didn't happen until I commit my latest
Jako changes, which Simon has asked
On Fri, Oct 05, 2001 at 01:46:44AM -0700, Ask Bjoern Hansen wrote:
> (uh, and of course: I would move them directly in the cvs repository
> as to preserve the revision history properly).
Go for it.
--
It can be hard to tell an English bigot from a monoglot with an
inferiority complex, but one c
[EMAIL PROTECTED] (Ask Bjoern Hansen) writes:
> would anyone object to moving parrot/little_languages/* to
> parrot/languages/jako/? Then we can add the beginnings of the other
> compilers to parrot/languages/{perl|ruby|python|Foo|C}
>
> Of course they should have their own repositories at some
would anyone object to moving parrot/little_languages/* to
parrot/languages/jako/? Then we can add the beginnings of the other
compilers to parrot/languages/{perl|ruby|python|Foo|C}
Of course they should have their own repositories at some point, but
right now it seems like they are more for pa
50 matches
Mail list logo
