In /parrot/docs/jit.pod:
"For moving registers from processor to parrot and vv, the
B functions have to be implemented."
what does "vv" stand for?
Hello, I was running the Configure.pl script and it failed.
--- D:\build\parrot>perl configure.pl
Hello, I'm Configure. My job is to poke and prod your system to figure out
how to build Parrot. The process is completely automated, unless you passed
in
[snip]
Determining what pmc files should
> - Original Message -
> From: "Vladimir Lipskiy" <[EMAIL PROTECTED]>
> To: "perl6-inrenals" <[EMAIL PROTECTED]>
> Sent: Friday, July 25, 2003 2:53 AM
> Subject: Configure.pl failed
>
>
> > Hello, I was running the Configur
As far as I can get, Parrot_WIN32_HANDLE, Parrot_OFF_T
haven't been implemented yet, because the better I got on Win32 is:
cl -nologo -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -I./includ
e -DHAS_JIT -DI386 -Foexceptions.obj -c exceptions.c
exceptions.c
./include\parrot/io.h(123) :
Index: jit.pod
===
RCS file: /cvs/public/parrot/docs/jit.pod,v
retrieving revision 1.13
diff -r1.13 jit.pod
249c249
< In general, prefixing an identifier with I<&> yields the address of the
---
> In general, prefixing an identifier wit
> if you wish to configure the build manually. Once Configure has
> finished successfully, type C (or try C under Win32).
Naw. I can readily use dmake programm to build Parrot under Win32.
IMHO, it shoud say something like this:
... type C(or whatever your C programm is).
BTW, what's about dmake?
Has anybody tried to make Parrot with it?
I just discovered Yet Another Copyrights in disassemble.pl.
They read this: "The Parrot Team". On the contrary, assemble.pl
doesn't have copyrghts at all like many other files I've skipped through,
though.
Index: disassemble.pl
===
R
> Nono, the problem isn't that python uses *more* registers than
> , but rather, that it doesn't use registers at all. Instead,
> it uses a stack. So, for example, python's add instruction might get
Nobody said Python used more registers than . Michal
just worried if it would be problematic to d
Heck! Leo is getting :)
D:\Perl\5.6.1\bin\MSWin32-x86-multi-thread\perl.exe pmc2c.pl env.pmc
Scanning D:/build/parrot/classes/env.pmc...
ologo -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -I../inclu
de -Foenv.obj -c env.c
env.c
env.pmc(29) : warning C4047: 'return' : 'struct parro
I'm getting an awful lot of "spf_render.c(578) : warning C4761: integral
size mismatch in argument; conversion supplied" while making.
> Jonathan Worthington:
> > LIB : fatal error LNK1181: cannot open input file "jit_cpu.obj"
> > NMAKE : fatal error U1077: 'lib' : return code '0x49d'
> > Stop.
>
> There *is* code in config/auto/jit.pl to disable JIT on Win32, so I'm not
> sure why Parrot's trying to compile it. I *do* know that
> Echoing all compiler flags clutters the screen too much, so that
> warnings easily can get missed.
> Earlier I used to run "make -s" which silents "make".
> Still better would be:
> - echo compiler flags once
> - echo filenames only
> - let the work depending on "-s" was given to "make" or not or
> > > There *is* code in config/auto/jit.pl to disable JIT on Win32, so I'm
not
> > > sure why Parrot's trying to compile it. I *do* know that it was
working
> > > fine before the exec stuff went in--perhaps looking at the diffs on
jit.pl
> > > will be enlightening. Unfortunately, I'm away from m
> >> if (-e "jit/$cpuarch/core.jit" and $osname ne 'MSWin32') {
Yeah, you're right. Thanks.
Index: jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.18
diff -r1.18 jit.pl
71c71
< if (-e "jit/$cpuarch
> Vladimir Lipskiy wrote:
> > Run the Configure script with "--jitcapable=0 --execcapable=0"
>
> That helped, but shouldn't this be recognized by Configure.pl?
It's a short term workaround.
Run the Configure script with "--jitcapable=0 --execcapable=0"
or find the line
if (-e "jit/$cpuarch/core.jit") {
in config/auto/jit.pl and replace it with this
if (-e "jit/$cpuarch/core.jit" and $osname ne 'MSWin32') {
>LIB: fatal error LNK1181: Input file "jit_cpu.obj" can not be opened
I cited this out of subs.pod:
"Parrot comes with different subroutine and alike classes which implement
CPS (Continuation Passing Style) and PCC (Parrot Calling Conventions)
F."
I don't get this. Could anybody rephrase it for me?
Later:
=head2 Items in the Subs Context
Subtype Controlstack
Q1: Suppose I have the following call into a sub named "foo":
foo($var1, $var2, $var3);
What should I set in I1? Is it 3?
And here:
foo($var1, @arr2, %hash3);
Is it still 3, since these aren't gonna be flattened?
Q2: I'm calling without prototyping
foo($var1, $var2, $var3, ... , $var23);
He
> First of all, are you targeting PASM or PIR? For the latter, its done
> automatically.
I mean PASM
> > Q2: I'm calling without prototyping
>
> > foo($var1, $var2, $var3, ... , $var23);
>
> > Here, what should I place in I2? Is it 11 (as we have P5-P15) or
> > 23 (considering the P3 register)
I don't think I was reading pdd03_calling_conventions.pod
in a slipshod manner and I swear that this place in the pod
>=item I1
>
>The number of items pushed onto the parameter list.
is the personification of confusion.
> I1 ... Number of items in the overflow/parameter array P3.
Hell yeah. Tha
> At 8:48 PM +0200 8/4/03, Valery A.Khamenya wrote:
> >Hi All,
> >
> > are there any info on getting ready-to-try
> > Parrot for win32 as stand-alone distribution?
>
> Not that I know of. If someone's got a working build and can put
> together a tarball or zip file, we can get it up for downloa
D:\build\parrot>nmake
[snip]
imcparser.c
imcparser.c
imcc.y(527) : warning C4761: integral size mismatch in argument; conversion
supplied
imcc.y(590) : warning C4761: integral size mismatch in argument; conversion
supplied
imcc.y(666) : warning C4761: integral size mismatch in argument; conversio
> According to Vladimir Lipskiy:
> > The patch below implements the missing XORS ops.
>
> Context diffs preferred, I think.
Sure.
Index: string.c
===
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.1
> I've committed a würgaround.
LMAO!
> Seems to be related with the multiple freeing reported by Michael.
I thought his name was Michal (:>8
> Is it as simple as checking whether the OS is Windows, and setting
%options
> to contain appropriate paths, e.g.
It's no use while checking if the OS is Windows, 'cause the distribution is
intended
for only Win 32 users. So you should predefine the hash below.
> %options = ( buildprefix => '',
OK. I'm starting out a prefixing story and here is
CHAPTER I. The HAS_HEADER_ defines.
prefixing.diff
Description: Binary data
> >Under cygwin, ./Configure.pl fails with the message:
> >
> >Determining some sizes...Linker failed (see test.ldo) at
> >lib/Parrot/Configure/Step.pm line
>
> Try to add this line
>
> link => 'gcc',
>
> to config/init/hints/cygwin.pl
>
> As a result, it must be in the following way:
>
> Conf
> At 9:21 PM +0300 8/8/03, Vladimir Lipskiy wrote:
> > > So, the project. Someone needs to go through the configure procedure
> >> and the headers and throw a PARROT_ prefix in front of all the HAS_
> >> defines we define, so we can avoid this problem.
> >
&
The attached patch removes these warnings:
io/io_win32.c(312) : warning C4028: formal parameter 4 different from
declaration
io/io_win32.c(312) : warning C4029: declared formal parameter list different
from definition
io/io_win32.c(358) : warning C4113: 'long (__cdecl *)(struct Parrot_Interp
*,str
# A note about building shared libraries: Perl5 uses the 'ld2' tool, which
# is installed as part of the perl5 installation. So far, it appears
# parrot can get by with simply using gcc -shared, so we override the
# perl5 Configure defaults and use 'gcc -shared' instead of 'ld2'.
# If this later
# New Ticket Created by "Vladimir Lipskiy"
# Please include the string: [perl #23276]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23276 >
OK. I'm starting out a prefixing story and here is
CHAPTER
> This is a missing implementation of fdopen on windows.
> Its not clear to me how this call should behave. PIO_win32_fdopen
> takes a Parrot_WIN32_Handle which is actually a void*.
To my mind the imlementation is fine.
> Using the numbers 0,1,2 in this call does not seem right
> here. Especially
> I have checked in some functionality for string bitwise ops.
> - vtable
> - B, B opcodes
> - string_bitwise_{or,and} functions in string.c
> - minimal tests
>
> Missing:
> - B ops
> - support for perl scalar PMCs
>
> I'd be glad if someone wants to continue that stuff.
The patch below implements
Recently I found some logic redundancy in string_bitwise_or
and this seems like I quite forgot to correct that in my just now
sent patch. Sorry.
Index: string.c
===
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.141
di
This patch touches ten files and deals with
HAS_POSIX_MEMALIGN
HAS_SOME_MEMALIGN
HAS_MEMALIGN
HAS_SOME_MEMALIGN
BROKEN_ISREG
HAS_JIT_FCOMIP
VA_TO_VAPTR
HAS_SIGACTION
HAS___SIGHANDLER_T
HAS_SETITIMER
HAS_SOME_SYS_TIMER
HAS_SETENV
HAS_UNSETENV
Coming soon ...
-DHAS_JIT
-D$jitcpuarch
-DHAVE_COMPUTE
> What in $DEITY's name is *that*? It sure isn't a context diff.
> A context diff is what you get from "diff -u" or "diff -c".
What you saw was the context diff I provided myself (~:
I doubt it's possible to provide a context diff WinCVS.
Though, I could be mistaken.
>Executable distro, I plan that you will just unzip it
> where you want it.
Shucks, my bad (~: For a moment, I was totally convinced
that we did need to make install the distro (~: Sorry.
>Sorry, looks like I've caused confusion. That bit of my email was about
>getting "make install" to work wh
> This is a missing implementation of fdopen on windows.
> Its not clear to me how this call should behave. PIO_win32_fdopen
> takes a Parrot_WIN32_Handle which is actually a void*.
Yup. I've alredy peeped in io.h, io_win32.c. And as soon as
I get more familiar with PIO, I'll try to say what the f
> interpreter.c:25: parrot/oplib/core_ops_cg.h: No such file or directory
> interpreter.c:26: parrot/oplib/core_ops_cgp.h: No such file or directory
> make: *** [interpreter.o] Error 1
>
> Could it be that your source contains traces of your #define patches?
I deleted all changes that I made and
> Could it be that your source contains traces of your #define patches?
I've found a blunder in my patch. I'll fix it in a minute.
headers.pl
Description: Binary data
classes2.diff
Description: Binary data
> Puts #ifdefs as per the rest of i386/jit_emit.h.
Good land! How did he compute that? It works!!!
> The current implementation of find_lex (by_name) is suboptimal. A linear
> scan over the list of lexical names is performed
> (s. sub.c:lexicals_get_position()).
>
> A better way would be to provide a list of lexicals plus a name hash,
> where hash values are indices into the list.
What would be
> A test for seek and tell is added to t/pmc/io.t
>
> All tests pass for Linux/i386 and MacOS X (thanks Dan)
>
> Windows is untested but I hope i got the things right.
t/pmc/io...NOK 3# Failed test (t/pmc/io.t at line 37)
# got: 'fdopen failed
# '
# expected: 'ok
# '
t
>Leo already applied this suggestion.
Yups. I found out that when I was sending my patch (~:
>Sometimes he is faster than light.
/me gets out a lightning-rod as me says: "Yes. He is all like that"
> Doesn't compile. Its seems to be the #ifdef vs #if issue.
Seems. I've fixed it. Try to compile the patch one more time,
please.
prefixing.diff
Description: Binary data
>This only happens on Windows. On Linux i can build pdb and step
>through the pasm code. This smells like makefile problems. Can you try
>the attached patch?
WORKS! I'm out of English words; I just run mandel.pbc in pdb
and it printed out such a cool Mandel bug or whatever(or maybe
even Leon Broca
d:\build\parrot\include\parrot\interpreter.h(40) : error C2040:
'Parrot_Interp' : 'struct Parrot_Interp *' differs in levels of indirection
from 'struct Parrot_Interp'
My compiler doesn't like the following:
typedef struct Parrot_Interp *Parrot_Interp;
in interpreter.h. It's a blame practice jus
headers.diff
Description: Binary data
> in a non clean tree the generated files are picked up also.
Yepper. I'll prepare the FINAL EDITION of that patch.
> Non-generated headers should be found in MANIFEST so using maniread
> might help here
..
Thanks, Joergen.
> Done that, thanks for your suggestion.
PoWwoW! It's unfair. He passed ahead of me.
> can people please test, if the program below compiles cleanly now:
It doesn't. MSVC++ aint' happy when * is at back of a name.
> static const char PCONCAT(name,_cstring) * = cstring;
this
static const char *PCONCAT(name,_cstring) = cstring;
would be okay.
D:\build\parrot>nmake
[snip]
Microsoft (R) Library Manager Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
rem blib/lib/libparrot_s.lib
link -out:parrot.exe -nologo -nodefaultlib -debug -pdb:none-machine:
x86 test_main.obj blib/lib/libparrot_s.lib
Leo wrote:
>>Its seems to be the #ifdef vs #if issue.
In theory that issue should only occur to the JIT_CAPABLE
defines and not to the HAVE_COMPUTED_GOTO ones,
I seem now. Because we have three places in the Configure
script where we define
-DHAS_JIT in jit.pl,
> -DHAVE_COMPUTED_GOTO
>
> So we shoudn't have any appearance of that issue, as we doesn't
> ever do following
>
> #define HAVE_COMPUTED_GOTO ${cgoto}
Nevermind. I didn't consider that a compiler set up -Dflag
as flag=1.
>We have missing dependencies. E.g. classes/* isn't rebuilt, when some
>parrot include files change.
This patch deals with only classes/*.pmc dependies. And I have no idea
how to search out other missing dependies.
headers.pl needs putting into the config/init directory
headers.pl
Description:
Wouldn't it be us anything if we had have replaced some functions
in string.c with its macroed versions. The candidates for to be
macroed are sring_length, string_compute_strlen, string_copy,
string_from_cstring, string_max_bytes, string_from_num,
string_cstring_free.
Though I know that those are
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
Sent: Thursday, August 07, 2003 12:51 PM
Subject: TWEAKS: Takers Wanted - Effort And Knowledge Sought
> Platform code
> -
>We need some functions to deal with paths and files like File::Spec.
>For loading include
D:\build\parrot>nmake
...
cl -nologo -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT
I../include -Focsub.obj -c csub.c
csub.c
csub.pmc(47) : error C2039: 'ptrs' : is not a member of '__unnamed'
../include\parrot/pobj.h(38) : see declaration of '__unnamed'
NMAKE : fatal erro
> Headerfiles may be protected with
>
>#ifdef __cplusplus
>extern "C" {
>#endif
Good idea, indeed. It will help us to solve the C/C++ naming convention
issue and thus to avoid the "_name@@decoration" unresolved external error.
I wonder at whether we should do
$su Dan
#
and protect the headers in
This patches touches 22 files and deals with
-DHAVE_COMPUTED_GOTO
-DHAS_JIT
-DGC_IS_MALLOC
prefixing.diff
Description: Binary data
I decide to lay out warnings I get while building Parrot.
this might be Leo's property:
packfile.c(1225) : warning C4700: local variable 'num_segs' used without
having been initialized
And this, to learn from Simon, is Brent's one
spf_render.c(578) : warning C4761: integral size mismatch in argum
> At 1:35 AM +0300 8/8/03, Vladimir Lipskiy wrote:
> > > What in $DEITY's name is *that*? It sure isn't a context diff.
> >> A context diff is what you get from "diff -u" or "diff -c".
YAY! Thanks Chip for you caustic remark -- it made me
> ITYM:
>
> > my @headers=(
> > sort
> > map { m{^$inc/(.*\.h)\z} }
> > keys %{maniread()}
> > );
>
> Otherwise, someone might at some future date, write:
>
>langauges/mylang/include/parrot/oops.txt
>
> And that would get picked up ;)
Or he might even
I just peeped in headers.pl and alighted on that you had forgotten
to put ^ in front of $inc according to Benjamin's advice(if you had
meant that advice, of course) .
s/$inc/^$inc/;
D:\Perl\5.6.1\bin\MSWin32-x86-multi-thread\perl.exe
t/harness --gc-debug
--running-make-test
t/op/gcNOK 2# Failed test (t/op/gc.t at line 14)
# got: '1'
# expected: '0'
t/op/gcok 8/8# Looks like you failed 1 tests of 8.
t/op/gcdubious
Test returned stat
> Sorting out make install on Win32 wasn't as simple as I'd first guessed,
but
> I'm getting there. I've now got it outputting 'correct' paths etc for
Win32
> to the makefile, and "tools/dev/install_files.pl" piping to "command"
rather sh
Wait a minute. Could we pipe to anything under dos?
>I s
>Under cygwin, ./Configure.pl fails with the message:
>
>Determining some sizes...Linker failed (see test.ldo) at
>lib/Parrot/Configure/Step.pm line
Try to add this line
link => 'gcc',
to config/init/hints/cygwin.pl
As a result, it must be in the following way:
Configure::Data->set(
link =>
> So, the project. Someone needs to go through the configure procedure
> and the headers and throw a PARROT_ prefix in front of all the HAS_
> defines we define, so we can avoid this problem.
Some defines have the HAVE_ prefix. Should those be also prefixed?
I wrote:
> >While configuring we generate 3 header files: config.h, has_header.h,
> >feature.h.
Plus I forgot to mention of specific cc flags like -DHAS_JIT, -D$jitcpuarch,
-DHAVE_COMPUTED_GOTO, -DGC_IS_MALLOC which we set up
in jit.pl, cgoto.pl, gc.pl respectively. I think the flags could settle
> So, the project. Someone needs to go through the configure procedure
> and the headers and throw a PARROT_ prefix in front of all the HAS_
> defines we define, so we can avoid this problem.
I have a look at the configure procedure and didn't find anything that
could have set up something like HA
It fails here:
system("$link $linkflags test$o ${cc_exe_out}test$exe $libs >test.ldo
$redir_err") and die "Linker failed (see test.ldo)";
Most likely one of the variables($link, $linkflags and so forth) isn't set
up or is set up incorrectly by this step.
Therefore, could you send me a dump of yo
> io/io_win32.c
> io_win32.c
> io/io_win32.c(212) : error C2371: 'PIO_win32_flush' : redefinition;
> different basic types
> io/io_win32.c(49) : see declaration of 'PIO_win32_flush'
> NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2'
> Stop.
I succeeded in fixing it(io_
Leo wrote:
> Albeit File::Spec is using catfile and catdir, I don't like the function
> names ("cat file" is on *nix what "type file" is on Win*). Maybe
> concat_pathname and concat_filename is better.
Yes, indeed. I'm for having concat_pathname only since this patch or
the File::Spec module makes
Leo wrote:
> Albeit File::Spec is using catfile and catdir, I don't like the function
> names ("cat file" is on *nix what "type file" is on Win*). Maybe
> concat_pathname and concat_filename is better.
Yes, indeed. I'm for having concat_pathname only since this patch or
the File::Spec module makes
This patch adds a new item to the must part of pdd7.
Pdd7's still missing:
A. Solving the problem of typedef struct a *a
Summarizng Leo's, Juergen's, and Brent's ideas,
I propose the following:
To have an underscore prepended to the stuct ParrotInterp.
To use ParrotInterp defined as typedef str
> Though I haven't been following this thread, it seems you're coming up
> with some File::Spec-like thing for Parrot?
Exactly.
> I'd recommend looking at Ken Williams' excellent Path::Class module
Surely, I will.
> So yes, you must distinguish between concatenating directories and files.
>
>
> > C. #if defined/undefined vs 0/1 issue
> >
> > I'm for ifdef/ifndef.
>
> For complex combinations of conditionals you have to write things like
>
> #if defined(A) || defined (B)
Sure. But I didn't precisely mean ifdef/ifndef. I was and am for
defined/undefined and used ifdef/ifndef there just a
Amir Karger <[EMAIL PROTECTED]> wrote:
> I got my fifteen bytes of fame in the P6 summary ...
Geewhillikins ... But you can always get more: Convert it into
Unicode (~:
_VL_
"But how can we do it if we don't know what it is?"
"Why, blame it all, we've GO
me wrote:
> libparrot_s.lib(io_buf.obj) : error LNK2001: unresolved external symbol
> _PIO_win
> 32_getblksize
> libparrot_s.lib(io_buf.obj) : error LNK2001: unresolved external symbol
> _PIO_win
> 32_isatty
> parrot.exe : fatal error LNK1120: 2 unresolved externals
> NMAKE : fatal error U1077: 'li
> Hi,
Hi
> Now, the file is certainly there. So what gives? I eventually traced the
> problem down to PIO_win32_open, where I found this:-
No, CreateFile is okay. The problem is in languages/imcc/main.c
> According to:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b
> I believe this patch has yet to be applied.
Don't think so. Juergen is engaged in improving
fdopen semantics and can't sync the source to
apply the patch, probably. Leo thinks that it should
be done by Juergen since now he got commit
privs.
Here is a new variant of File Spec for the Parrot internals.
I've changed implementation. Made some alternations concerning
with function names. catdir and catfile have become concat_dirnames
and append_filename respectively. Now it will work properly
on Windows, UNIX, VMS, Mac, cygwin, and OS/2(?)
> Shouldn't that be "."?
>
> > append_filename("a", "") = ""
>
> "a"
Umm. Don't think so. At least it will be that
way until you convince me that it must be
another way
>
> What about
>
> append_filename("", "b") ?
>
> Would that be an error?
No. It's okay. I just forgot to mention that ca
Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Why wouldn't appending no filename onto a directory result in the
directory
> being returned? Unless append_filename() guarantees that it will always
> return a filepath ending in a filename?
Yes. And it guarantees to return a "", when you do someth
- Original Message -
From: "Arthur Bergman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, September 11, 2003 7:14 PM
Subject: Embedding interface to PMCs
> Hi,
>
> Is there any documentation, or code I can read to figure out how use
> PMCs in embedded m
Thursday, September 11, 2003 11:36 PM
Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 11, 2003 at 08:36:02PM +0300, Vladimir Lipskiy wrote:
> > > Famous last words: "Our data is perfect, we don't need to check our
> > inputs."
> >
> >
> Are you saying:
>
> concat_dirnames("C:\foo", "bar") == error?
Yes. Even if the file spec tool was smart enough just like you and me
it would never be able to unriddle what output it would have to produce
as a result of the following call on Mac:
concat_dirnames("disk:dir_a", "dir_b");
if "dis
> 4. Win32. I don't know that it's broken, but I'm assuming it is on
> general principle.
D:\build\parrot>perl Configure.pl
[snip]
Probing for C headers...done.
Determining some sizes...Linker failed (see test.ldo) at
lib/Parrot/Configure/St
ep.pm line 170.
The code
# 'link' needs to be link
> Dan spoke too soon, we have just confirmed that PIERS_C =
> 2.04739336492890995260663507109 * BRENT_D
Brent isn't adult? Gosh!
BRENT_D = 36/2.04739336492890995260663507109 = appr. 17 ages and 296 days
92 matches
Mail list logo
