Leopold Toetsch wrote:
Dan Sugalski wrote:
At 11:13 AM +0200 10/28/04, Leopold Toetsch wrote:
1) use frame pointer relative addressing:
+ prederefed code is usable by different threads too
- ~4 times increase in code size of core_ops_*.{c,o} [1]
I've now committed this case 1) as a fix for
Kj [EMAIL PROTECTED] wrote:
Hello,
I tried to experiment with dynamic ops, but I didn't get the test running.
Is this a known problem?
Seems to be broken, likely because of the changed dynamic load sequence,
specifically the split between init_lib and load_lib.
$ make -C dynoplibs
...
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
* the temp_base_vtable should be const.
Patch attached.
Thanks, applied - with s/clone/vt_clone/ to avoid a warning about a
shadowed global.
+clone-whoami = string_make(interp,
$classname,
At 11:12 AM +0100 11/1/04, Leopold Toetsch wrote:
Leopold Toetsch wrote:
Or 3) Toss the prederef stuff entirely.
Well, the prederefed function core (parrot -P) is for sure not necessary.
Patches welcome to remove the plain prederefed function core
Fops/core_ops_prederef.*.
At least for now? Because I need to get strings working right, so I'm
going to be implementing the encoding/charset library stuff, which is
going to cause some major disruptions. (This'll probably touch the
packfile stuff too, which ought to be fun...)
--
Dan
Will Coleda [EMAIL PROTECTED] wrote:
I think we should be building dynclasses by default.
Before applying it, some response from various platforms might be
helpful. Please folks either apply that patch, or run the make
command manually:
+ cd dynclasses $(MAKE)
Do we have some tests
Will Coleda via RT [EMAIL PROTECTED] wrote:
[coke - Sat Jan 24 19:32:16 2004]:
It would be helpful if IMCC complained about duplicate .local labels,
so that the attached wouldn't compile, rather than dying at runtime.
A naive pass at this is:
+if (_get_sym(cur_unit-hash,fullname)) {
Leopold Toetsch wrote:
+clone-whoami = string_make(interp,
$classname, @{[length($classname)]}, iso-8859-1,
PObj_constant_FLAG|PObj_external_FLAG);
Is there a specific reason that dynamically loaded libs don't use
CONST_STRING()?
At the moment, each
Dan Sugalski [EMAIL PROTECTED] wrote:
At least for now?
Yep. A minute ago the last patch WRT indirect register addressing
changes went in. What's still missing is now some optimization for
reusing discarded chunks. But that's mostly restricted to register.c.
... Because I need to get strings
Dan Sugalski [EMAIL PROTECTED] wrote:
While I want to keep the switch core, I'm still not seeing the need
for prederef with it. I'm presuming this crept in at some point and
just needs un-creeping?
Using prederef for switch has one advantage: it's a bit faster. Before
the indirect register
Dan Sugalski [EMAIL PROTECTED] wrote:
Or 3) Toss the prederef stuff entirely.
And here is, why I want to keep the CGP core:
sub_i_i_i
0x81bbef0 cgp_core+33488: mov0x4(%esi),%ecx
0x81bbef3 cgp_core+33491: mov0x8(%esi),%edx
0x81bbef6 cgp_core+33494: mov0xc(%esi),%eax
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
+clone-whoami = string_make(interp,
$classname, @{[length($classname)]}, iso-8859-1,
PObj_constant_FLAG|PObj_external_FLAG);
Is there a specific reason that dynamically loaded libs don't use
I'm considering adding in some new ops and a command-line switch to
help debug parrot code, but before I did I figured I'd better throw
it out to the list for some debugging. (This seems like something
which could be of good general use, and as such I'd like to hash it
out, do it once, and do
Dan Sugalski wrote:
I'm considering adding in some new ops and a command-line switch to
help debug parrot code, but before I did I figured I'd better throw it
out to the list for some debugging. (This seems like something which
could be of good general use, and as such I'd like to hash it out,
At 4:57 PM +0100 11/1/04, KJ wrote:
Dan Sugalski wrote:
I'm considering adding in some new ops and a command-line switch to
help debug parrot code, but before I did I figured I'd better throw
it out to the list for some debugging. (This seems like something
which could be of good general use,
Dan Sugalski wrote:
I'm considering adding in some new ops and a command-line switch to help
debug parrot code, but before I did I figured I'd better throw it out to
the list for some debugging. (This seems like something which could be
of good general use, and as such I'd like to hash it out,
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS dprinterr [PISN]x - Like printerr, but only when running in debug mode
DS ifdebug label - If debug's on, branch to label
DS unlessdebug label - branch to label unless debugging's on
DS debugbsr label - do a bsr to the label if
FWIW the CGP sub_i_i_i opcode on the PowerBook
0x001048d4 cgp_core+35652:lwz r0,8(r30)
0x001048d8 cgp_core+35656:lwz r2,12(r30)
0x001048dc cgp_core+35660:lwzxr0,r27,r0
0x001048e0 cgp_core+35664:lwzxr2,r27,r2
0x001048e4 cgp_core+35668:lwz r9,4(r30)
Dan Sugalski [EMAIL PROTECTED] wrote:
dprinterr [PISN]x - Like printerr, but only when running in debug mode
ifdebug label - If debug's on, branch to label
unlessdebug label - branch to label unless debugging's on
debugbsr label - do a bsr to the label if debugging's on
Ok.
(I'm
Kj [EMAIL PROTECTED] wrote:
Maybe a bit off-topic (as it concerns pir syntax), but wouldn't it be
usefull if we had multi-line comments?
=for comment
=cut
leo
On Monday 01 November 2004 10:17 am, Sam Ruby wrote:
Dan Sugalski wrote:
I'm considering adding in some new ops and a command-line switch to help
debug parrot code, but before I did I figured I'd better throw it out to
the list for some debugging. (This seems like something which could be
All~
My work has a really useful macro trace that expands as followed
#define trace(name_str, format_str, ...); \
{ \
static bool traceMe = DO_WE_TRACE_THIS(name_str); \
if(traceMe) { \
DO_THE_TRACING(name_str, format_str, __VA_ARGS__); \
} \
}
Where DO_WE_TRACE_THIS can use whatever
At 11:14 AM -0500 11/1/04, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS dprinterr [PISN]x - Like printerr, but only when running in debug mode
DS ifdebug label - If debug's on, branch to label
DS unlessdebug label - branch to label unless debugging's on
DS
Hello,
Just getting back to parrot.
[Leo]* alloca() isn't portable and not available everywhere
[Dan] Yep. This is a gcc-ism. Use Parrot's memory allocation functions instead.
reg_alloc.c uses malloc(). I saw alloca() used in the CVS tree
earlier, but it's gone now. What is the correct way to
At 11:17 AM -0500 11/1/04, Sam Ruby wrote:
Dan Sugalski wrote:
I'm considering adding in some new ops and a command-line switch to
help debug parrot code, but before I did I figured I'd better throw
it out to the list for some debugging. (This seems like something
which could be of good general
At 10:23 AM -0700 11/1/04, Bill Coffman wrote:
Hello,
Just getting back to parrot.
[Leo]* alloca() isn't portable and not available everywhere
[Dan] Yep. This is a gcc-ism. Use Parrot's memory allocation
functions instead.
reg_alloc.c uses malloc(). I saw alloca() used in the CVS tree
earlier,
On 04/11/01 11:17 -0500, Sam Ruby wrote:
But either at startup or dynamically, individual loggers can be
enabled to start (or stop) outputing messages that exceed a given
threshhold (debug, info, warn, error, fatal).
One thing that I really miss in this kind of logging framework is to
At 7:17 PM +0100 11/1/04, Jerome Quelin wrote:
On 04/11/01 11:17 -0500, Sam Ruby wrote:
But either at startup or dynamically, individual loggers can be
enabled to start (or stop) outputing messages that exceed a given
threshhold (debug, info, warn, error, fatal).
One thing that I really
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #32270]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32270
Throwing the trace switch on makes parrot leak. A *lot*. Processes
that top out
Dan Sugalski [EMAIL PROTECTED] wrote:
This allows for example to run all your code with fatal threshold and
then, when running into sub-that-is-supposed-to-be-all-bugged, you just
activate debug level, and return to fatal after leaving it. This way you
only get the traces you wanted - instead of
Bill Coffman [EMAIL PROTECTED] wrote:
[ Dan answered already, so I'll provide just a few additional notes ]
reg_alloc.c uses malloc().
Yep, there are still a few malloc()s around, they should be
mem_sys_allocate(), which is just a macro for malloc() mostly, but leaves
us the chance to do our
We need more vtables.
* INTVAL hash()
To properly support Python, we need:
- a hash PMC that isn't restricted to STRING* keys - low level hash code
has AFAIK already all the necessary stuff, or mostly. I don't know, how
much Python specific it really is, but Perl5's hashing objects as
strings
At 9:03 PM +0100 11/1/04, Leopold Toetsch wrote:
We need more vtables.
* INTVAL hash()
To properly support Python, we need:
- a hash PMC that isn't restricted to STRING* keys - low level hash
code has AFAIK already all the necessary stuff, or mostly. I don't
know, how much Python specific it
Leopold Toetsch wrote:
We need more vtables.
* INTVAL hash()
To properly support Python, we need:
- a hash PMC that isn't restricted to STRING* keys - low level hash code
has AFAIK already all the necessary stuff, or mostly. I don't know, how
much Python specific it really is, but Perl5's
At 11:45 AM +0200 10/29/04, Leopold Toetsch wrote:
We now have since quite a time the current subroutine and the
current continuation in the interpreter context structure. With that
at hand, we should now be able to generate function tracebacks in
error case and we need the call chain too, to
On Mon, Nov 01, 2004 at 08:24:34PM +0100, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Sounds like a job for pre and post handlers for subs and methods
Pah. Sounds like a debug variable in the interpreter context (what we
already have for errors and warnings - we might
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #32265]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32265
The disassembler compiles but doesn't work.
[EMAIL PROTECTED]:~/parrot$ make
At 8:57 AM -0800 11/1/04, Matt Diephouse (via RT) wrote:
The disassembler compiles but doesn't work.
[EMAIL PROTECTED]:~/parrot$ make disassemble
src/disassemble.c
echo ast/ast.y -d -o ast/astparser.c -p AST
ast/ast.y -d -o ast/astparser.c -p AST
/usr/bin/perl -e 'open(A,qq{$_}) or die foreach
# New Ticket Created by James deBoer
# Please include the string: [perl #32278]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32278
There are a number of .pl files within parrot/config.
Some of them have a
On Mon, 1 Nov 2004 16:50:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Erm... .pir isn't bytecode. What happens when you run the
disassembler on the bytecode you get if you compile forth.pir?
d'oh! insert obligatory comment about mondays.
Anyway, it still doesn't work:
[EMAIL
James deBoer [EMAIL PROTECTED] wrote:
There are a number of .pl files within parrot/config.
Some of them have a she-bang line at the beginning of the script, others
do not.
This patch simply adds '#! perl -w' to the top of any script that didn't
have this line already.
These scripts can
Fair enough.
Here is a [longer] patch to remove all of the she-bang lines, then.
- James
Brent Royal-Gordon via RT wrote:
James deBoer [EMAIL PROTECTED] wrote:
There are a number of .pl files within parrot/config.
Some of them have a she-bang line at the beginning of the script, others
do not.
On Nov 1, 2004, at 6:14 AM, Dan Sugalski wrote:
Because I need to get strings working right, so I'm going to be
implementing the encoding/charset library stuff, which is going to
cause some major disruptions.
Please tag cvs before checking this in.
Thanks,
JEff
Perl 6 Summary for 2004-10-23 through 2004-11-01
All~
Welcome to another summary, this one being slightly delayed by
Halloween. Before I start off with perl6-language, let me remind all
American readers to vote tomorrow. Non-American readers should also
vote, but it seems
Matt Fowles [EMAIL PROTECTED] wrote:
Parrot on AMD64
Brent 'Dax' Royal-Gordon managed to find an AMD64 for himself. Not only
am I jealous, but Parrot passes all expected tests on it when one adds
--ccflags=':add{ -fPIC }'.
I then patched Parrot so that Configure would
45 matches
Mail list logo
