Simon Glover (via RT) wrote:
# New Ticket Created by Simon Glover
# Please include the string: [perl #22867]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22867 >
Based on the documentation in core.ops, I would expect t
Shouldn't Perl make this determination at compile time based upon the
subroutine's signature? Doesn't seem to me that it is in any way a
decision for the assembler.
On Tuesday, July 1, 2003, at 04:00 , K Stol wrote:
This is taken from this week's summary, but I thought this post would
fit
best
In Perl this is possible (because of the syntax of Perl). But what about languages in
which it cannot be expressed?
I know, Parrot is mainly for Perl, but not *only* for Perl. Wouldn't it be nice to
have Parrot supporting this?
klaas-jan
- Original Message -
From: Gordon Henriksen
JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> The standard filedescriptors stdin, stdout and stderr are protected
> from closing by the PMC_destroy function by marking them as
> PIO_F_SHARED. Don't know if this is a right solution.
The 3 standard IO PMCs should probably live inside interpreter->p
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Ok, as there are no problems reported, I've applied it.
Here is again a short summary:
> Attached is a minimum patch to build imcc as the parrot executable
> - renames orig parrot to test_main
> - renames imcc to parrot
> As the current build process ne
Index: embed.c
===
RCS file: /cvs/public/parrot/embed.c,v
retrieving revision 1.70
diff -u -r1.70 embed.c
--- embed.c 1 Jul 2003 18:22:01 - 1.70
+++ embed.c 2 Jul 2003 09:59:39 -
@@ -319,8 +319,8 @@
/* No JIT here--make su
At 11:43 PM +0200 6/29/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
[ stack implementations ]
Well... we only really have three.
Control, User & Pad have the same stack engine. The register backing
stacks and rxstack sum up to 5 more.
Pads shouldn't really be stacks, they should be plain linked
At 3:57 PM +0100 7/1/03, Nicholas Clark wrote:
On Tue, Jul 01, 2003 at 10:04:41AM -0400, Andy Dougherty wrote:
The problem is that with a clean build tree, there are no *.o files
down in languages/imcc/ at the point when that target is reached.
Hence make doesn't have anything to expand *.o as,
At 11:56 AM +0200 6/30/03, Leopold Toetsch wrote:
So I'd like to generate a new directory hierarchy e.g.
runtime/parrot/include
/parrot/libs # N/Y
and place files, containing such constant definitions in
F.
Works for me.
--
Dan
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> I still missed one of the PIO_fprintf -> PIO_eprintf.
Applied, thanks,
leo
Here's the failure stuff from the build process:
gcc -o parrot -L/usr/local/lib test_main.o blib/lib/libparrot.a -lnsl
-ldl -lm -lpthread -lcrypt -lutil
blib/lib/libparrot.a(jit_cpu.o)(.text+0x2ce0): In function
`Parrot_jit_restart_op':
: undefined reference to `Parrot_end_jit'
collect2: ld retu
Dan Sugalski wrote:
Unfortunately given what the code does we can't use mutexes, since
they're not interrupt-safe, which I'm not particularly happy about. The
queues in question are thread-specific, though, which takes some of the
danger out of things. I fully expect to have to do more work tha
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> I suggest you disable signals during the queue operations, take
AB> out the lock, do the work, drop the lock then reenable signals.
that is just how the kernel does interrupt handling. i did the same in
an rtos eons ago. drivers coul
This patch implements optional arguments for the longopt subsystem,
and modifies imcc to use them.
Luke
Index: longopt.c
===
RCS file: /cvs/public/parrot/longopt.c,v
retrieving revision 1.4
diff -u -r1.4 longopt.c
--- longopt.c 27
Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> Here's the failure stuff from the build process:
> gcc -o parrot -L/usr/local/lib test_main.o blib/lib/libparrot.a -lnsl
> -ldl -lm -lpthread -lcrypt -lutil
> blib/lib/libparrot.a(jit_cpu.o)(.text+0x2ce0): In function
> `Parrot_jit_restart_op':
>: und
Leo --
After doing a make realclean:
$ find . -type f -exec grep -l 'end_jit' {} ';'
./include/parrot/jit_emit.h
./jit/i386/jit_emit.h
./t/src/basic_2
./t/src/intlist_1
./t/src/exit_1
./t/src/intlist_2
./t/src/exit_2
./t/src/intlist_3
./t/src/intlist_4
./t/src/list_1
./t/src/sprintf_1
./t/src/spr
Luke Palmer wrote:
This patch implements optional arguments for the longopt subsystem,
and modifies imcc to use them.
Thanks, applied and ...
+if (dex+1 < argc && argv[dex+1][0] && argv[dex+1][0] != '-') {
changed that to if (dex+2 < argc ...
So "parrot -d file.pasm" work
At 4:01 PM +0100 7/2/03, Alan Burlison wrote:
Dan Sugalski wrote:
Unfortunately given what the code does we can't use mutexes, since
they're not interrupt-safe, which I'm not particularly happy about.
The queues in question are thread-specific, though, which takes
some of the danger out of thin
Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> Which file do you think has the implementation of
> this function?
All Parrot_*_jit functions are *generated* out of jit/*/core.jit. They
finally are in jit_cpu.c. This file includes then jit_emit.h, where the
prototype of the file is too.
Just Config
Leo --
My jit_cpu.c doesn't have a Parrot_jit_end() in it:
$ grep end_jit jit_cpu.c
My jit_cpu.c tells me where it came from (I'll attach the
whole file to the message):
$ head jit_cpu.c
/*
* !!! DO NOT EDIT THIS FILE !!!
*
* This file is generated automatically from 'jit/i386/
At 8:55 AM +0200 7/2/03, Leopold Toetsch wrote:
Simon Glover (via RT) wrote:
# New Ticket Created by Simon Glover # Please include the string:
[perl #22867]
# in the subject line of all future correspondence about this
issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=22867 >
Based on
On Wed, Jul 02, 2003 at 08:55:37AM +1000, Iain Truskett wrote:
> * Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]:
> > Iain Truskett <[EMAIL PROTECTED]> writes:
>
> > > Not the only one. And with Parrot being able to execute
> > > Z-code, it might be sane to port Inform to Parro
Simon Glover <[EMAIL PROTECTED]> writes:
> On Tue, 1 Jul 2003, Dan Sugalski wrote:
>
> > This dies on 9 tests on OS X, and I think from the complaints that
> > valgrind will also be very unhappy, but I'm putting it in so it can
> > be thumped by other folks as well as me.
>
> I think I might ha
Gregor N. Purdy wrote:
Leo --
My jit_cpu.c doesn't have a Parrot_jit_end() in it:
$ grep end_jit jit_cpu.c
Wasn't here recently (~weeks) a report about a broekn Perl and
DeadRat^WRedHat?
leo
Index: cpu_dep.c
===
RCS file: /cvs/public/parrot/cpu_dep.c,v
retrieving revision 1.7
diff -u -r1.7 cpu_dep.c
--- cpu_dep.c 1 Jun 2003 00:17:43 - 1.7
+++ cpu_dep.c 2 Jul 2003 21:50:53 -
@@ -57,6 +57,9 @@
# ifdef HAS_HEADER_SE
Leo --
Daniel and I are on the trail...
On Wed, 2003-07-02 at 17:47, Leopold Toetsch wrote:
> Gregor N. Purdy wrote:
>
> > Leo --
> >
> > My jit_cpu.c doesn't have a Parrot_jit_end() in it:
> >
> > $ grep end_jit jit_cpu.c
>
> Wasn't here recently (~weeks) a report about a broekn Perl and
>
OK.
Daniel and I drilled into it and we discovered that a
small change to two regexps in jit2h.pl solved the
problem.
I have checked in the change.
Regards,
-- Gregor
On Wed, 2003-07-02 at 18:02, Gregor N. Purdy wrote:
> Leo --
>
> Daniel and I are on the trail...
>
> On Wed, 2003-07-02 at
Andy Dougherty wrote:
>
> On Tue, 1 Jul 2003, Leopold Toetsch wrote:
>
> > Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > > On Mon, 30 Jun 2003, Leopold Toetsch wrote:
> >
> > >> Attached is a minimum patch to build imcc as the parrot executable
> >
> > >languages/imcc/*.o
> >
>
All --
I just checked in some changes to Jako that bring rudimentary
module support. Its rudimentary because for now, modules are
not referenced from separate files, but simply form handy
named groups of symbols within the single source file being
compiled.
Of course, this really becomes useful o
29 matches
Mail list logo
