Sunday, November 7, 2004, 11:25:52 AM, Jens Rieks wrote:
On Sunday 07 November 2004 09:48, Leopold Toetsch wrote:
* where exactly is the mismatch coming from?
Unix uses \n to indicate end-of-line, windows uses \r\n. The problem is,
that the perlhist.txt file is checked in as a text file. I'll
From other threads:
Now we are placing arguments or return values in registers according
to PDD03 and the other end has immediately access to the placed
values, because the register file is in the interpreter.
With the indirect addressing of the register frame, this argument
passing is
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
In Python, semantically you know that you'll end up doing a method call
(or, behaving as though you had), so it's very roundabout to do a
method call by using an op which you know will fall back to doing a
On Fri, 29 Oct 2004 15:03:40 -0700, Adam Thomason [EMAIL PROTECTED] wrote:
Worry not, it's already broken. I've been unable to test the AIX/PPC
JIT since ICU went in. The configuration for ICU (at least as of 2.6)
supports only a 64-bit build, while aix/asm.s is 32-bit only (the
linker
Hello,
(* I'm trying a lot of things out, to figure out each part of the Lua
language. This is Yet Another Question , this time concerning missing
arguments *)
I'm currently figuring out how missing arguments should be handled.
Suppose there is a function foo, that takes 4 parameters. In Lua
Jeff Clites [EMAIL PROTECTED] wrote:
OTOH it doesn't really matter, if the context structure is in the
frame too. We'd just need to skip that gap. REG_INT(64) or I64 is as
valid as I0 or I4, as long as it's assured, that it's exactly
addressing the incoming argument area of the called
Stéphane Payrard [EMAIL PROTECTED] wrote:
There is now a call to set the core and another to set the other
flags. I updated the code and the doc to reflect that.
Thanks, applied.
leo
On Nov 8, 2004, at 12:50 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
In Python, semantically you know that you'll end up doing a method
call
(or, behaving as though you had), so it's very roundabout to do a
method call by
On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
OTOH it doesn't really matter, if the context structure is in the
frame too. We'd just need to skip that gap. REG_INT(64) or I64 is as
valid as I0 or I4, as long as it's assured, that it's exactly
addressing
Klaas-Jan Stol [EMAIL PROTECTED] wrote:
Hello,
I'm currently figuring out how missing arguments should be handled.
[ ... ]
# check on arguments being NULL
isnull a, L1
Don't assume you get NULL or anything for missing arguments. Use the
argument counts:
argcP ... number of P
Adam Thomason [EMAIL PROTECTED] wrote:
It appears that (3) may work after all. ICU 3.0 will build static
32-bit libraries which seem to work with parrot. As Jeff suspected,
the missing Parrot_ppc_jit_restore_nonvolatile_registers caused
trouble, but adding it to aix/asm.s was simple. Patch
I have Active State Perl. I have MSVC. I have the POW version of Parrot.
In the new POW version of Parrot there is no Configure.pl so I can't
compile. Since all I get are Can't find MSVC errors I can't follow
Leo's advice on CPAN.
Nmake has done nothing for me either on the CVS tar.zip I
Jeff Clites [EMAIL PROTECTED] wrote:
No. The binary operations in Python are opcodes, as well as in Parrot.
And both provide the snytax to override the opcode doing a method call,
that's it.
I guess we'll just have to disagree here. I don't see any evidence of
this
UTSL please. The code is
Jeff Clites [EMAIL PROTECTED] wrote:
What pasm is supposed to correspond to this snippet of Python code
(assume this is inside a function, so these can be considered to be
local variables):
a = 7
b = 12
c = a + b
Run it through pie-thon. It should produce some reasonable
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote:
If frames aren't adjacent, normal argument copying can be done anyway.
This would seem to require the same types of runtime checks that you
are objecting to below,
Not runtime. The register allocator
On Mon, Nov 08, 2004 at 12:21:51AM -0600, Christian Lott wrote:
I have Active State Perl. I have MSVC. I have the POW version of Parrot.
What's the POW version of Parrot? This some source for parrot which isn't
cvs.perl.org, or a release on CPAN?
Nicholas Clark
The current MarkSweep collector runs strictly on demand, as well as the
copying collector for buffer memory. Both are triggered, when a lack of
resources is detected and are run immediately, from a probably deeply
nested C function.
This causes several problems:
1) we have to do stack walking
Christian Lott [EMAIL PROTECTED] wrote:
I have Active State Perl. I have MSVC. I have the POW version of Parrot.
What is POW? Parrot on Windows? Who does maintain it?
In the new POW version of Parrot there is no Configure.pl so I can't
compile. Since all I get are Can't find MSVC errors I
On Mon, Nov 08, 2004 at 12:56:50PM +0100, Leopold Toetsch wrote:
Christian Lott [EMAIL PROTECTED] wrote:
I have Active State Perl. I have MSVC. I have the POW version of Parrot.
What is POW? Parrot on Windows? Who does maintain it?
Possily he means http://www.jwcs.net/developers/perl/pow/
I'd like to cleanup eval.pmc and dynamic code compiling a bit. But
before that I'd like to know:
Which granularity do we allow for eval()ed code?
Can that be an expression or statement too or is it always at least an
(anonymous) subroutine?
Does the compiled code see Parrot registers of the
Stephane Payrard [EMAIL PROTECTED] wrote:
Chris wants to flush a string without a newline.
It does not work of MacOSX. Example of program :
getstdout P1
pioctl I0, P1, 3, 0
print Give me an integer number : ¥n
getstdinP0
readline S1,P0
I don't know how reasonable it
Do you hvae msvc (cl.exe) in the path?
No. I thought I did but looks like I don't...
It's at c:\Program Files\Microsoft Visual C++ 2003\bin\cl.exe
How would I set the path without overwriting my previous settings?
set PATH=%PATH%;c:\Program Files\Microsoft Visual C++ 2003\bin\
Possily he means
On Mon, 08 Nov 2004 09:45:06 -0600, Christian Lott wrote:
Do you hvae msvc (cl.exe) in the path?
No. I thought I did but looks like I don't...
It's at c:\Program Files\Microsoft Visual C++ 2003\bin\cl.exe
How would I set the path without overwriting my previous settings?
set
Hello,
in the parrot distribution I would like to have the first line from
the file parrot-0.1.1/languages/perl6/perl6 from
#! perl
changed to
#!/usr/bin/perl
use lib '/parrot_source_dir/parrot-0.1.1/languages/perl6';
So that /usr/bin/perl reflect the perl 5 executable and
On Sun, 07 Nov 2004 22:29:46 -0700, Jack J. Woehr [EMAIL PROTECTED] wrote:
Now on to actually *trying out* Parrot ... as a former ANSForth Technical
Committee
member, think I'll try the Forth first :-)
Hurm. The Forth in CVS has been somewhat abandoned (though
functional). I've been working
Ron Blaschke wrote:
No. Look for a batch file called vcvars32.bat below the Microsoft Visual
C++ 2003 directory, and run it. It'll setup your environment.
dir /s vcvars32.bat
OK. Path set.
Now what?
It just fires up a command prompt with the vcvars32.bat executed.
Ron
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
I've already said no changes to the calling conventions, quite a
while ago. I don't see inconvenience in the register allocation code
as a reason to change it. Got a better reason?
--
Dan
Peter Sinnott [EMAIL PROTECTED] wrote:
On Mon, Nov 08, 2004 at 12:56:50PM +0100, Leopold Toetsch wrote:
Christian Lott [EMAIL PROTECTED] wrote:
I have Active State Perl. I have MSVC. I have the POW version of
Parrot.
What is POW? Parrot on Windows? Who does maintain it?
Possily he means
At 10:29 PM -0700 11/7/04, Jack J. Woehr wrote:
Nicholas Clark wrote:
So I think that deleting the empty directory /usr/local/uplevel for the
duration of the build should solve your problem.
Removed the dir, finished the build, recreated the dir, and make
install worked.
Now on to actually
At 10:45 AM +0100 11/8/04, Klaas-Jan Stol wrote:
Hello,
(* I'm trying a lot of things out, to figure out each part of the
Lua language. This is Yet Another Question , this time concerning
missing arguments *)
Argument counts are there for this purpose.
Named arguments are a separate issue, which
On Mon, 8 Nov 2004 02:38:16 +0100, Stéphane Payrard [EMAIL PROTECTED] wrote:
+#include parrot/parrot.h
#include parrot/embed.h
Unless things have changed far more than I thought, this is very,
very, very, very, very wrong. parrot.h is an internals-only
header--including it exposes all
We now have dedicated PMC* pointers in the context that hold
current_cont, current_sub, and current_object. This is necessary to
create traceback information. But subroutine and return opcodes are not
adapted yet.
We have e.g.:
invoke # implicitely P0 and use P1 for return
At 9:39 AM -0800 11/8/04, Brent 'Dax' Royal-Gordon wrote:
On Mon, 8 Nov 2004 02:38:16 +0100, Stéphane Payrard [EMAIL PROTECTED] wrote:
+#include parrot/parrot.h
#include parrot/embed.h
Unless things have changed far more than I thought, this is very,
very, very, very, very wrong.
Dan Sugalski [EMAIL PROTECTED] wrote:
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
... Got a better reason?
And there is of course:
4) invoke's (and friends) register usage is assymmetrical and ugly. It's
like defining:
set 5 # set I0, 5
Ad
Dan Sugalski [EMAIL PROTECTED] wrote:
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
I've already said no changes to the calling conventions, quite a
while ago.
This doesn't really change calling convention, it changes call opcodes.
It makes register
At 7:17 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
... Got a better reason?
And there is of course:
4) invoke's (and friends) register usage is assymmetrical and ugly.
Dan~
On Mon, 8 Nov 2004 13:23:36 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
Neither of those are sufficient, individually or together.
It feels to me like you are dismissing Leo's
At 1:38 PM -0500 11/8/04, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:23:36 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
Neither of those are sufficient, individually or together.
It
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and implemented... *then* we can consider changes.
Until then,
At 2:15 PM -0500 11/8/04, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and implemented...
No need to modify embed.h.
Patch attached to get a snipped that compileds without the
#include parrot/parrot.h
--
stef--- docs/embed.pod.orig 2004-11-08 10:48:59.0 +0100
+++ docs/embed.pod 2004-11-08 20:42:57.209202168 +0100
@@ -7,7 +7,6 @@
=head1 SYNOPSIS
-#include
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare Cinvoke.
But as that shall not be fixed now,
At 9:39 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare
Having a little trouble with vim.
I think the problem is that imc.vim.in needs to go through ops2vim.
C:\parrot\editorperl ops2vim.pl imc.vim.in imc.vim
Can't open imc.vim: No such file or directory at ops2vim.pl line 8,
line 85.
syn keyword imcOp
C:\parrot\editorperl ops2vim.pl imc.vim
A suggestion about Parrot install:
I thought the --prefix argument was like in Gnu configs, but I find
that --prefix=/usr/local/uplevel results in a lot of Parrot stuff being dumped
unceremoniously
into that very directory instead of only in subdirectories. This install
process should either
Matt Diephouse wrote:
Enjoy (Parrot). :-)
I did ... briefly!
[17:33:55 [EMAIL PROTECTED]:/usr/local/src/PerlSource/parrot_stuff/forth]$
parrot forth.pir
Parrot Forth 0.1
Type `bye` to exit
words
over 2* spaces */ swap 2dup rot drop depth cr 0sp - space words / emit .
On Mon, 08 Nov 2004 18:41:50 -0700, Jack J. Woehr [EMAIL PROTECTED] wrote:
Matt Diephouse wrote:
Enjoy (Parrot). :-)
I did ... briefly!
[ . . . ]
Segmentation Fault (core dumped)
Oops. I forgot to mention that some recent (big) changes to Parrot has
been causing my Forth
Matt Diephouse wrote:
Oops. I forgot to mention that some recent (big) changes to Parrot has
been causing my Forth implementation some trouble. I filed a bug
report earlier today; hopefully it'll get fixed soon (generally
doesn't take long).
No problem ... my interest is tangential at the
Jonathan Worthington wrote:
Peter Sinnott [EMAIL PROTECTED] wrote:
On Mon, Nov 08, 2004 at 12:56:50PM +0100, Leopold Toetsch wrote:
Christian Lott [EMAIL PROTECTED] wrote:
I have Active State Perl. I have MSVC. I have the POW version of
Parrot.
What is POW? Parrot on Windows? Who does maintain
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #32369]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32369
After the new calling scheme was put in place, my Forth implementation
On Nov 8, 2004, at 2:47 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
What pasm is supposed to correspond to this snippet of Python code
(assume this is inside a function, so these can be considered to be
local variables):
a = 7
b = 12
c = a + b
Run it
Perl 6 Summary for 2004-11-01 through 2004-11-08
All~
Welcome to yet another summary, brought to you (once again) with the aid
of the musical stylings of Dar Williams and Soul Coughing and a small
stuffed elephant name Aliya. And, without further ado, I give you Perl 6
# New Ticket Created by Will Coleda
# Please include the string: [perl #32374]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32374
I was talking with Dan on IRC about what we're going to do as a replacement for
Matt Diephouse [EMAIL PROTECTED] wrote:
After the new calling scheme was put in place, my Forth implementation
started having some problems. I've stripped down and attached the files
along with a trace. Here's the input/output:
[EMAIL PROTECTED]:~/parrot/forth$ ../parrot forth.pir
Two
Stéphane Payrard [EMAIL PROTECTED] wrote:
Patch attached to get a snipped that compileds without the
#include parrot/parrot.h
Thanks, applied.
leo
Jeff Clites wrote:
% cat pythonClass.py
class A:
def __add__(x,y) : return boo
Only a few standard methods are implemented. __add__ IIRC isn't.
new P16, 32 # .PerlInt
add P16, P18, P17
That's what worries me, and what prompted the question. You don't know
at
Jack J. Woehr [EMAIL PROTECTED] wrote:
A suggestion about Parrot install:
I thought the --prefix argument was like in Gnu configs, but I find
that --prefix=/usr/local/uplevel results in a lot of Parrot stuff
being dumped unceremoniously into that very directory instead of only
in
57 matches
Mail list logo
