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':
conf
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 think
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 compilin
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 curre
back in 2004, Dan Sugalski wrote:
http://www.nntp.perl.org/group/perl.perl6.internals/2004/09/msg25521.html
nowadays my effort of porting Parrot to the PocketPC platform, as you
may have suspected, force me to reopen the question.
there is, I know, a lot of work to be done. and this will sure
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 comm
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 i
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 o
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 Status
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.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24205 >
hello,
currently Configure.pl insists on passing a
-mno-accumulate-
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #24149]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24149 >
make clean is currently doing an rm *.s, thus removing the asmfun
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
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:
> 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
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:
#
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
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #18141]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18141 >
due to a bug in config/auto/stackdir.pl, Configure.pl
was unable
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 *n
Jürgen Bömmels wrote:
> Hi,
>
> When you use pdb and hit just 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 f
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #17405]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17405 >
this one patches the Makefile to correctly build a
"pdb.exe&qu
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 P1[0;1],
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,$, hacker,,print
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
i
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 us
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). IMH
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 afr
Dan Sugalski wrote:
> At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
>>fetching an element out of bound changes the
>>length of the array. but should this really happen?
>
> Because that's the way Perl's arrays work. Joys of
> autovivification.
I have to disag
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
Stephen Rawls wrote:
> Also of note, instead of having TUPLE1 + TUPLE2 act as
> arrays, and return the sum of their sizes, I am
> treating it like this: (a1, a2, ... , an) + (b1, b2,
> ... , bn) = (a1 + b1, a2 + b2, ... , an + bn)
makes sense to me (and certainly adds some spice to
the cause of t
Mr. Nobody wrote:
> The windows 9x command.com shell dosen't recognize
> 2>&1 so it ends up passing "2" as an argument to the
> compiler, which fails because there's no such file.
this is no news. you can't even build Perl on 9x.
IMHO, *build* platform targets should not include 9x.
build it on N
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
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 por
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
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: Win3
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
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 :-
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
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 instruction
Daniel Grunblatt wrote:
> Don't implement any print op yet, if I didn't understood wrong they are
> going to be updated to use the IO system.
ok, I draw back them then.
but I found another use for the emit_call_abs() function to implement some
string stuff in JIT. as I already said, the speed in
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 instruct
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
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;
hi there,
the Examples page on www.parrotcode.org states this about subroutines:
The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch
and do not have to be preserved by the callee.
this seems to be false for *recursive* subroutines. this is my PASM
code fibo.pasm (it calcu
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 ExtUtils::
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 JI
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
generat
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
genera
56 matches
Mail list logo
