Jerry Gay (via RT) ha scritto:
i suspect there's trouble with the platform-specific c/h files, given
the nature of the warnings during build. the configure/make output is
below.
the only relevant warning I see is:
config/gen/platform/win32/exec.c: In function `Parrot_Exec_OS_Command':
Allison Randal ha scritto:
We do. Unfortunately we can't rely on Perl 5 for the configure system.
It may seem like an easy way to gain cross-compilation in the short
term, but in the long term it will hurt us.
Miniparrot is the right way to go. It certainly needs work, though. As
you're
jerry gay ha scritto:
On 2/20/07, Aldo Calpini [EMAIL PROTECTED] wrote:
1) does anybody have objections to patching the current build system for
cross-compilation (even yes, but not now because... objections)?
no objection here! this is a long-desired feature, and is currently
unavailable
Joshua Isom ha scritto:
Using perl 5's configure probes also somewhat limits us to how the
vendor distributed perl. It should also be considered that we can't
rely on perl5 being available, especially since we intend to replace
it eventually, so rewriting all the perl to support cross
whoa there!
I've managed to build parrot for the PocketPC. yes, really. I hacked
just a little the Configure process - now it _really_ compiles test
executables, run them on the PDA and gather the result. this wasn't
really hard.
I had a half-written Perl XS extension which uses RAPI to
hello people!
I'm really interested in porting parrot to PDA (well, PocketPC at least).
some days ago I stumbled upon CeGCC (a cross compiler for PocketPC),
which is basically a windows port of gcc (both cygwin and mingw32
flavours) that produces ARM executable code.
I started playing with
Leopold Toetsch wrote:
1) ICU should be optional
If configured --without-icu the Makefile shouldn't contain ICU stuff,
and function calls to ICU (mainly in string_primitives) should be
wrapped inside #if PARROT_HAS_ICU.
I'm gonna take this one (unless Steven Schubiger is already working on
these are the patches of mine which still show as Pending:
(17405) [PATCH] correct make pdb on Win32
(24149) [PATCH] small Makefile patch (rm *.s in realclean instead of clean)
(24205) [PATCH] removing -mno-accumulate-outgoing-args for non x86 arch
the last one was applied by Dan, but the
hello,
I was trying to debug the t/src tests, and realized that doing by hand
what Parrot::Test::c_output_(is|like) does is not really easy.
I wanted to compile the source code embedded in t/src/sprintf.t (the
third test, in my case) to see exactly where and how it was failing, and
possibly have
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #24205]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24205
hello,
currently Configure.pl insists on passing a
-mno-accumulate-outgoing-args
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #24149]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24149
make clean is currently doing an rm *.s, thus removing the asmfun.s
which gets
good day
by chance, I have an Itanium machine under my control. it is a
(rather-old) HP i2000 Workstation with Itanium 1. this is what cat
/proc/cpuinfo says:
processor : 0
vendor : GenuineIntel
arch : IA-64
family : Itanium
model : 0
revision : 6
archrev
Leopold Toetsch wrote:
Probably some INTVAL/opcode_t mismatch. What does
$ cat myconfig
yield on that machine?
here is it, in all its shining gory details :-)
(BTW, in the mean time I've switched to gcc 3.0, but the results seem
to be absolutely the same)
Summary of my parrot 0.0.11.2
Leopold Toetsch wrote:
Attached is a test program, showing an implementations for multiple
timers. GNU/linux only, but implementing the platform interface (and the
sighandler/message queue) shouldn't be too hard.
don't know if it's worth something, but this is how your timer program
could
Robert Spier wrote:
Sorry for a slightly off-topic post, but will Larry's State of the Onion
be posted online soon?
Yes.
sorry to reiterate the argument, but will also a text transcript of
the talk be posted online? the slides are beautiful, but without a few
words of explanation they are
Leopold Toetsch wrote:
There is a nextkey_keyed mentioned in pdd02_vtables.pod, which would
almost be all to implement aggregate iterators. Missing is IMHO how to
reset (start) an iteration.
Also not too long ago, there was some proposal WRT an iterator class.
I was the proposer. I have
Mr. Nobody wrote:
There are some files in parrot that have names common in the first 8
characters. This will cause problems if someone tries to compile Parrot on
DOS. Is DOS an intended target, or should we not worry about this?
my vote is NO. let us bury 8.3 very, very deep in the ground.
Leopold Toetsch wrote:
Appended is a test program that shows timings (i386 w rdtsc) and
the limit, where malloc changes strategy to use mmap and returns
zeroed memory.
I don't know if it helps, but there are the results on my machine,
using Windows XP Pro and Cygwin 1.3.10 and GCC 2.95.3:
#
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #18141]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18141
due to a bug in config/auto/stackdir.pl, Configure.pl
was unable to determine
Andy Dougherty wrote:
but I'm unsure what to put for link_exe_out for each of the three
compilers mentioned in config/init/hints/mswin32.pl, nor for the
compilers used under OS/2 and VMS.
config/init/hints/mswin32.pl already defines what you need. is called
'ld_out' (also see my recent patch
Leopold Toetsch wrote:
Attached is a test program showing some features, how a PMC could look
like in the future.
and where's the attachment?
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Erik Lechak wrote:
Just wondering: What would another documentation style have to
provide to make it an acceptable replacement for pod?
being pod. you gotta love it ;-)
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Erik Lechak wrote:
Yep I cut and pasted it right from my console. I'll download the newest
realease and try it again and try v1.2. If someone could tell me where
to get cvs for windows without all the GUI that would be great.
www.cygwin.com
full-blown command-line CVS. you won't miss *nix
Jürgen Bömmels wrote:
Hi,
When you use pdb and hit just ENTER you get a segfault. Thats
quite anoying especially if you are used to gdbs behaviour.
The attached patch fixes this by just ignoring empty lines.
this doesn't seem to me how pdb is supposed to work.
docs/debugger.pod says:
the tests under t/src currently fail on Win32 (with MSVC++ 6.0).
the first problem is that it needs another build step (make shared)
which is not mentioned anywhere. linking the programs require a
libparrot.lib which is not built by the standard make target.
probably it should be a prerequisite
I couldn't find any example of using a MultiArray PMC.
I tried on my own, but failed miserably.
from what I've seen, it seems that is impossible to
properly initialize a multidimensional MultiArray.
I've tried this:
new P1, .MultiArray, 1000
set P1[0;0], 1
set
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #17405]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17405
this one patches the Makefile to correctly build a
pdb.exe on Win32 (it should
whoever put the parrot logo on www.parrotcode.org,
make your penances, because you are in sin!
you will find attached a replacement for that logo
which doesn't hurt like a kick in the eye, and above
all does s/GIF/PNG/g :-)
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$,
Mattia Barbon wrote:
set P1, P0 # tells P1 that he's going to iterate P0
This looks like a kludge. IMHO the correct way of getting an iterator
is having the aggregate return it (say, using find_method/invoke);
that's a correct assumption, and when find_method/invoke will be
Josef Hook wrote:
It's a fact that we have a problem with pmc's that has custom
functions which dosent fit into the vtable. Therefore i suggest
we add a pointer in pmc struct that points to a function list,
we already have find_method and invoke, they just need to be
implemented :-)
I was
Peter Gibbs wrote:
This version is (hopefully) functionally equivalent to PerlUndef,
i.e. it acts as an uninitialised scalar. When assigned a value,
it changes itself to the appropriate type (PerlInt/PerlNum/
PerlString). The current level of functionality is therefore
sufficient to use it
hello everybody,
here is my rough draft of the documentation for the
Parrot debugger. please review it (expecially the
boilerplate stuff like TITLE, HISTORY, etc. -- I don't
know if I have properly followed convention) (and if there
is one) and tell me if this should be sent as a patch.
I'm
John Porter wrote:
It all depends. :-)
[...]
Perl has to autoviv if it has to drill down.
good point. but since we don't have multidimensional
array access right now (at least AFAIK), this seems
to be a non-issue. I don't know if p6 will autovivify
the way p5 does (and I hope not). IMHO,
Stephen Rawls wrote:
since I want the Tuple pmc to do the same thing in
this respect as the PerlArray pmc.
just my opinion, but I don't want this. it would be
PerlTuple then. let's keep this stuff at a higher level.
the only and one reason I see because one would implement
tuples instead of
take this little assembler program:
new P1, .PerlArray
set P1, 100
bsr GETLEN
set I0, P1[0]
print P1[0]=
print I0
print \n
bsr GETLEN
set I0, P1[1]
print P1[1]=
print I0
Dan Sugalski wrote:
I like this, and want it to go in--I think it's a capability
we should provide. However... Until it works on Win32 we need
to wait. Can someone running a Win box grab this and get a win
version going? When we have that, this can get committed.
I'm a little late on this
Nicholas Clark wrote:
Does Microsoft give you (well, us) a select() implementation that
really does honour the microsecond field of the struct timeval
it's passed?
AFAIK, microseconds are honoured only on sockets, not on filehandles.
I seem to remember reading somewhere that the most
Leon Brocard wrote:
I think ParrotTuple would make a great first project for anyone
who wants to learn more about PMCs. It will also be fairly simple
and small, so if lots of docs were also included it would make
an ideal PMC to learn from in future. Any takers? ;-)
me, time permitting :-)
this is a little tutorial about submitting patches
(should be added to a FAQ, or somewhere where it's handy
for people like me that tend to forget everything :-).
if there's something missing or incorrect, feel free to
let me know:
1. do a diff -u of the file(s) you want to patch
(note: Win32
this is a little tutorial about submitting patches
(should be added to a FAQ, or somewhere where it's handy
for people like me that tends to forget everything :-).
if there's something missing or incorrect, feel free to
let me know:
1. do a diff -u of the file(s) you want to patch
(note:
Josef Höök wrote:
Aldo Calpini ( alias dada on irc ) had a couple of good arguments
why having a key.pmc. I just want this patch in because i need it
for my soon to come matrix.pmc.
that's embarassing, but it must have been someone else.
I only ranted on IRC about tuple.pmc and some other
Markus Laire wrote:
I've been following this list for a month, but havn't yet learned what COW
really means. It's used so often that perhaps it should be added to Parrot
Glossary.
I'll give my try, but I'm no expert at all. feel free to correct me if I'm
wrong.
COW stands for Copy On Write.
hello there,
in one of my endless tours inside the JIT world, I came up with this idea
which seems to give a major speed increase.
basically, I'm substituting the Parrot method for subroutines (push the
current address in the call stack and then jump) with a plain native
x86 ASM call
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode does. it just saves some
push/pop/call/ret
hello,
I've added the following new ops to i386/core.jit:
inc_i
dec_i
inc_i_ic
dec_i_ic
lt_i_ic_ic
lt_i_i_ic
gt_i_ic_ic
gt_i_i_ic
ge_i_ic_ic
ge_i_i_ic
le_i_ic_ic
le_i_i_ic
eq_i_ic_ic
eq_i_i_ic
also fixed buggy definitions for emitm_cmpl_r_m
Jeffrey Goff (via RT) wrote:
I've just patched lib/Parrot/Makefile.PL to check for a Win32 platform,
and if so, use .obj for the default object extension. However I did it
simply by checking $^O for 'Win'. This is probably not as portable as it
could be, but a quick look through
Aldo Calpini wrote:
and now for timings: [...]
em... forgot to include the platform details:
OS: Windows 2000 Advanced Server + Cygwin 1.3.10
CPU: AMD K7 550MHz
RAM: 256 MB
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
hello there (and especially the JIT team),
is anybody working on JIT-enabling the Win32 platform?
I've done some work on this (using MASM as an assembler
and VisualC's DUMPBIN as a disassembler instead of the
GNU as and objdump).
I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that
hello there (and especially the JIT team),
is anybody working on JIT-enabling the Win32 platform?
I've done some work on this (using MASM as an assembler
and VisualC's DUMPBIN as a disassembler instead of the
GNU as and objdump).
I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that
Daniel Grunblatt wrote:
is anybody working on JIT-enabling the Win32 platform?
Yes, the new JIT will work (actually, it works) on Windows, probably you
didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so,
as soon as the the code is in you will be able to use the JIT on
50 matches
Mail list logo
