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
4. Win32. I don't know that it's broken, but I'm assuming it is on
general principle.
D:\build\parrotperl 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
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 disk was a
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.
Yes. Our data is perfect and we don't need to check our inputs
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
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 case.
append_filename(, b)
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 something
- 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 mode? I
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/base/
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.
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
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: 'link' :
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
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.
You
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 as 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 GOT to
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 no
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 no
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 the
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
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\parrotnmake
...
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
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 files
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 write:
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/;
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 did
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
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
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.
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:
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.
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
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
This patches touches 22 files and deals with
-DHAVE_COMPUTED_GOTO
-DHAS_JIT
-DGC_IS_MALLOC
prefixing.diff
Description: Binary data
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
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
- Bands, Bors opcodes
- string_bitwise_{or,and} functions in string.c
- minimal tests
Missing:
- Bxors ops
- support for perl scalar PMCs
I'd be glad if someone wants to continue that stuff.
The patch below
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
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
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.
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
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
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
# '
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
D:\build\parrotnmake
[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
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 to
know about how to get a context diff with WinCVS.
Dan wrotes
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 see two
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 in
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
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 your
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 when
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
# 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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23276
OK. I'm starting out a prefixing story and here is
CHAPTER I. The HAS_HEADER_
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.141
diff -r1.141 string.c
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:
Configure::Data-set(
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.
Some defines have the HAVE_ prefix. Should those
D:\build\parrotnmake
[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;
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 download.
If you
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
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. That's
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);
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)
Fdocs/pdds/pdd03_calling_conventions.pod.
I don't get this. Could anybody rephrase it for me?
Later:
=head2 Items in the
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
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 it was
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 such
Yepper.
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
Nono, the problem isn't that python uses *more* registers than
whatever, 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 whatever. Michal
just worried if it would be
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
I'm getting an awful lot of spf_render.c(578) : warning C4761: integral
size mismatch in argument; conversion supplied while making.
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 with I
if you wish to configure the build manually. Once Configure has
finished successfully, type Cmake (or try Cnmake under Win32).
Naw. I can readily use dmake programm to build Parrot under Win32.
IMHO, it shoud say something like this:
... type Cmake(or whatever your Cmake 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
===
- 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 Configure.pl script and it failed.
D:\build\parrotperl configure.pl
[snip
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) :
Hello, I was running the Configure.pl script and it failed.
--- D:\build\parrotperl 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
89 matches
Mail list logo
