Milscvaer writes:
> Running the old Perl5 interpretor and the Parrot in the same process
> is not a great solution, since this would mean that there would be two
> completely seperate interpretor codebases to support. A big part of
> Parrot is to allow several languages to use the same interpretor,
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 pr
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
...
my
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
F. F is
still needed as an abstract base class o
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 tes
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->has
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 string
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 : mov0x4(%esi),%ecx
0x81bbef3 : mov0x8(%esi),%edx
0x81bbef6 : mov0xc(%esi),%eax
0x81bbef9 : add$0x10,%esi
0x8
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 registe
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
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 i
Hello,
I imagine that many of you develop Perl with real world constraints--
deadlines and budgets. Whether you deliver your work internally or to an
external client, a good estimate plays an important role in the ultimate
quality of the software.
You may well have experienced working on a proj
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, d
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, an
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, d
> "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 la
FWIW the CGP sub_i_i_i opcode on the PowerBook
0x001048d4 :lwz r0,8(r30)
0x001048d8 :lwz r2,12(r30)
0x001048dc :lwzxr0,r27,r0
0x001048e0 :lwzxr2,r27,r2
0x001048e4 :lwz r9,4(r30)
0x001048e8 :subfr0,r2,r0
0x001048ec :stwxr0,r27,r9
0x001048f0 :
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 coul
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.
> (
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 heirachica
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
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 a
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, b
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 t
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 m
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #32270]
# in the subject line of all future correspondence about this issue.
# 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 at 1
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 - in
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"
--- Mark Stosberg <[EMAIL PROTECTED]> wrote:
> So, what resources are recommended to consult to make great
> estimates?
> What habits to develop?
/me puts on his "economics" hat.
It's widely reported that the majority of "large" software projects
fail. I won't cite anything here as this is easy
--- Ovid <[EMAIL PROTECTED]> wrote:
> --- Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > So, what resources are recommended to consult to make great
> > estimates?
> > What habits to develop?
And all that writing only to notice that I only peripherally touched on
your question :)
Whoops,
Ovid
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 real
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 "hashin
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 op
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
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #32265]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32265 >
The disassembler compiles but doesn't work.
[EMAIL PROTECTED]:~/parrot$ make disas
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 @A
[Mark == [EMAIL PROTECTED] on Mon, 1 Nov 2004 15:45:34 + (UTC)]
Mark> So, what resources are recommended to consult to make great
Mark> estimates? What habits to develop?
Estimate only what you know. My preferred model is to "bid" on only
"one phase at a time". During kickoff, I'll giv
On Mon, 2004-11-01 at 07:45, Mark Stosberg wrote:
> So, what resources are recommended to consult to make great estimates?
> What habits to develop?
I have two primary rules:
1) Don't make an estimate for something I haven't done before.
2) Don't make an estimate for anything that'll take longer
# New Ticket Created by James deBoer
# Please include the string: [perl #32278]
# in the subject line of all future correspondence about this issue.
# 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 she-bang l
Estimate with severe granularity. All estimates are a collection of
subestimates.
If you say "I can do that in 8 days", but that 8 day estimate is just
gut feel, why should the customer believe you? Why should YOU believe
you? "Well, it'll be 2 days for this, 3 days for that, and 3 days for
Hello List (I'm new - met Andy at the WebGUI conference in Chicago and
got inspired to signup!).
We've been pushing down to 8 hours as the max estimate, but I like
Andy's idea of pushing down to 4 hours. The 8 hours came because we
don't believe someone can accurately estimate a task of more t
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! .
Anyway, it still doesn't work:
[EMAIL PROTECTED]:~/parrot$ ./disassemble forth/forth.pbc
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 scri
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 unlik
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 auto
53 matches
Mail list logo
