On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
> I tried that as well, it spits out identical PASM each time but on the
> odd occasion I need to use CTRL-C to get back to the shell.
I'm seeing the same thing on Linux PPC -- odd hangs from time to time
when running PIR, while running the PASM
Thus wrate Dan Sugalski:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Short version: I was originally going to argue for fully hierarchical
namespaces, identified as above, but after turning this over in my
head for a while, I came to the conclusion that namespaces are not
conceptually hierarch
At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote:
Melvin Smith writes:
> My email was concerned with storing/retrieving multiple variables
> with a single lookup, not with hinting to the compiler.
Okay. Can you show an example of this optimization. I'd rather see it
in a HLL talking about PIR, as o
On Thu, Jan 15, 2004 at 05:15:05PM -0500, Dan Sugalski wrote:
> At 2:39 PM -0500 1/15/04, Dan Sugalski wrote:
> >At 8:31 PM +0100 1/15/04, Michael Scott wrote:
> >>Is this relevant?
> >>http://oss.software.ibm.com/icu/userguide/formatNumbers.html
> >>
> >>I'm still not clear in my mind what the pl
At 06:13 PM 1/15/2004 -0500, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
Comments & questions welcome.
Why am I thinking of the "register" keyword in C?
I have no idea and I can't see the relationship. :)
I just realized m
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 15, 2004 8:09 PM
Subject: Unicode, internationalization, C++, and ICU
> Now, assuming there's still anyone left reading this message...
>
> We've been threatening to build ICU in
Melvin Smith writes:
> At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
> >Why am I thinking of the "register" keyword in C?
>
> I have no idea and I can't see the relationship. :)
>
> With Parrot's architecture, we have overhead of storing and retrieving
> globals, lexicals and package va
On Thu, 2004-01-15 at 15:02, Michael Scott wrote:
> So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
> all the pod errors and done a rudimentary html tree.
Do you have patches to fix the errors in CVS or are they even necessary?
-- c
At 18:13 -0500 1/15/04, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
It might also be more useful to have it more granular than
16, maybe in 4s or 8s. By doing life analysis and some
weighting, IMCC might be able to turn mul
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
IMCC could analyze a module, decide if the optimization makes
sense, and place commonly used values (constants or
variables) in a pre-packaged register frame. (or more than 1)
This is done at compile
So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
all the pod errors and done a rudimentary html tree. The state of
parrot pod can be seen here
http://homepage.mac.com/michael_scott/Parrot/docs/html/. That's every
file that has pod in it. Obviously there are a few files such
I'm still trying to get my head wrapped around most of parrot but I'll work
on whatever projects need doing. I've been programming C/C++ since 1997 with
experience in various other languages as I find need to use them.
-Richard Holden
On Wed, Jan 14, 2004 at 10:28:25PM -0800, Jeff Clites wrote:
> You might be right, but that's not exactly how I read it, because later
> it says, "A use action (by a thread) transfers the contents of the
> thread's working copy of a variable to the thread's execution engine.
> This action is per
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
> I don't see any advantage of such a model. The more as it doesn't
> gurantee any atomic access to e.g. long or doubles. The atomic access to
> ints and pointers seems to rely on the architecture but is of course
> reasonable.
You *
On Thu, Jan 15, 2004 at 12:45:16PM -0500, Dan Sugalski wrote:
>
> What I'd like is for a volunteer or two to manage the todo queue.
> Nothing fancy, just be there to assign todo list items to the folks
> that volunteer, make sure they're closed out when done, and reassign
> them if whoever's ha
Dan Sugalski wrote:
Folks,
I got reminded the other day that we have a full, working RT
installation (as everyone's probably noticed with the tickets that fly
past on occasion) and, well, we ought to use it. What I'm going to start
doing is putting in tickets for the tasks that need doing, that
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #24916]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24916 >
Need to define the encoding, character set, and language vtable APIs,
better document t
At 2:39 PM -0500 1/15/04, Dan Sugalski wrote:
At 8:31 PM +0100 1/15/04, Michael Scott wrote:
Is this relevant?
http://oss.software.ibm.com/icu/userguide/formatNumbers.html
I'm still not clear in my mind what the plan is with regard to ICU.
Is it intended eventually to be:
a) an always-there pa
At 10:34 PM +0100 1/15/04, Michael Scott wrote:
Well I did originally have this in mind, but the more I looked into
it the more I thought it needed someone with unicode experience.
It seems to me that the unicode world is full of "ah but in North
Icelandic Yiddish aleph is considered to be an in
Well I did originally have this in mind, but the more I looked into it
the more I thought it needed someone with unicode experience.
It seems to me that the unicode world is full of "ah but in North
Icelandic Yiddish aleph is considered to be an infinitely composite
character" and other such
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Unifying the user and control stacks make sense. I don't see any
> point in unifying the pad stack with anything, since it's not really
> a stack as such, or at least ought not be, and it's got a more
> complex linking structure anyway.
Sorry for the uncl
At 15:51 -0500 1/15/04, Melvin Smith wrote:
IMCC could analyze a module, decide if the optimization makes
sense, and place commonly used values (constants or
variables) in a pre-packaged register frame. (or more than 1)
This is done at compile / load time of course. If it were all
constants, compil
While sitting on IRC with Dan and Jonathan discussing how to
optimizer a certain construct with how we handle globals/package
variables, etc. I came to the conclusion that it would be valuable
to not have to fetch each and every global, lexical or package
variable by name, individually, but instead
Now, assuming there's still anyone left reading this message...
We've been threatening to build ICU into parrot, and it's time for
that to start happening. Unfortunately there's a problem--it doesn't
work right now. So, what we need is some brave soul to track ICU
development and keep us reason
At 8:31 PM +0100 1/15/04, Michael Scott wrote:
Is this relevant? http://oss.software.ibm.com/icu/userguide/formatNumbers.html
I'm still not clear in my mind what the plan is with regard to ICU.
Is it intended eventually to be:
a) an always-there part of parrot, or
b) just a sometimes-there thi
Is this relevant?
http://oss.software.ibm.com/icu/userguide/formatNumbers.html
I'm still not clear in my mind what the plan is with regard to ICU. Is
it intended eventually to be:
a) an always-there part of parrot, or
b) just a sometimes-there thing that gets linked in if you mess with
unico
And now for something reasonably trivial...
I'm going to start in on Parrot's COBOLish chunks, in this case
numeric formatting.
Now, I'm already painfully aware of some of the locale issues that
are involved in formatting numbers and money. (What's the currency
symbol, what's the decimal indic
> -Original Message-
> From: Jeff Clites [mailto:[EMAIL PROTECTED]
> Sent: Thursday January 15, 2004 01:28
> To: Gordon Henriksen
> Cc: [EMAIL PROTECTED]
> Subject: Re: JVM as a threading example (threads proposal)
>
>
> On Jan 12, 2004, at 10:03 AM, Gordon Henriksen wrote:
>
> > On Mon
At 01:08 PM 1/15/2004 -0500, Dan Sugalski wrote:
At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
Could you be a bit more verbose about that. I've now checked out the
branch "imcc1final", which switched the whole tree to u
At 1:17 PM -0500 1/15/04, Melvin Smith wrote:
At 10:27 AM 1/15/2004 -0500, Melvin Smith wrote:
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit m
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
>> Here are some notes on namespaces, picking up a thread from about a month ago:
>>
>>> That does, though, argue that we need to revisit the global access
>>> opcodes. If we're goin
At 10:27 AM 1/15/2004 -0500, Melvin Smith wrote:
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out t
At 6:16 PM +0100 1/15/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
If that's living in an managedstruct, then accessing the struct
elements should be as simple as:
set I0, P20['bar']
set S1, P20['plugh']
set P20['baz'], 15
That's mostly done, except for name
At 11:05 AM +0100 1/15/04, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out the
branch "imcc1final", which switched the whole
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Here are some notes on namespaces, picking up a thread from about a month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
opcodes. If we're going hierarchic, and we want to sepa
Folks,
I got reminded the other day that we have a full, working RT
installation (as everyone's probably noticed with the tickets that
fly past on occasion) and, well, we ought to use it. What I'm going
to start doing is putting in tickets for the tasks that need doing,
that way they don't get
At 11:07 AM +0100 1/13/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ stack layout ]
I'd rather not have the store statically inside the hunk:
- small objects code currently has an upper limit for sized header pools
Doesn't mean we have to use them, honestly. A separate ar
Okay, since folks are diving into IMCC (assuming we can keep a fight
from breaking out) it's time to address bytecode loading.
We've got the need to have subs that get executed when a code segment
is loaded, a need to have a 'main' sub that gets executed as mainline
code, and subs that get exec
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If that's living in an managedstruct, then accessing the struct
> elements should be as simple as:
> set I0, P20['bar']
> set S1, P20['plugh']
> set P20['baz'], 15
That's mostly done, except for named keys (I used arrays). If you like
named k
At 04:17 PM 1/15/2004 +, Jonathan Worthington wrote:
From: "Melvin Smith" <[EMAIL PROTECTED]>
> I'd like to get imcc1 working as correct as possible and frozen
> within a couple of weeks, then I'll start on the really major rework
> for imcc2 (including all the deprecation that is going to mak
The NCI interface slings these around and uses them to wrap things
returned from external functions. They're handy things, but they're
also opaque -- there's no good way to directly build up structs to
pass into functions, and there's no good way to retrieve the data
from the bits of the struct
From: "Melvin Smith" <[EMAIL PROTECTED]>
> I'd like to get imcc1 working as correct as possible and frozen
> within a couple of weeks, then I'll start on the really major rework
> for imcc2 (including all the deprecation that is going to make everyone
> mad at me.) ;)
Any chance of a list of wha
At 3:56 PM + 1/13/04, Tim Bunce wrote:
On Tue, Jan 13, 2004 at 10:01:32AM +0100, Leopold Toetsch wrote:
Michal Wallace <[EMAIL PROTECTED]> wrote:
> Here's my guess:
[lots of good stuff from leo]
Is there a "Parrot Architecture Overview" document that summarises
this kind of high-level view
At 1:46 PM -0500 1/13/04, Melvin Smith wrote:
At 11:18 PM 1/12/2004 -0500, Michal Wallace wrote:
On Mon, 12 Jan 2004, Luke Palmer wrote:
A continuation is one snapshot -- it never changes, it never runs.
To invoke the continuation is to take you back to that snapshot and
start running from there
At 10:28 AM 1/15/2004 +, you wrote:
On Thu, Jan 15, 2004 at 02:21:56AM -0500, Melvin Smith wrote:
> I'd like to get imcc1 working as correct as possible and frozen
> within a couple of weeks, then I'll start on the really major rework
> for imcc2 (including all the deprecation that is going to
At 11:05 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out the branch
I would not checkout the branch into th
At 11:20 AM 1/15/2004 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
>
> For some reason 1 test in pcc.t is failing (the nci call)
Off by one error caused by:
> -for (j = 0; j < 4; j++) {
> +for (set = 0; set < REGSET_MAX; set++) {
As most loo
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hello
> When running this I would expect the 2 files to
> look the same, but they don't.
Additionally to the reported bug these seem to be broken:
1) Turning off buffering:
open P1, S0
find_method P10, P1, "setbuf"
set P5, P
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hello
> When running this I would expect the 2 files to
> look the same, but they don't.
Very likely a bug in the buffering code:
$ cmp a_file b_file
a_file b_file differ: char 8192, line 84
and
# define PIO_BLKSIZE 8192
> /Stefan
leo
Hello
When running this I would expect the 2 files to
look the same, but they don't.
new P0, .PerlArray # PMC creation
set I10, 1 # wanted numbers. this fails, 1000 works
set P0, I10# set array size
set P0[0], 2 # set
# New Ticket Created by Matt Fowles
# Please include the string: [perl #24913]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24913 >
All~
This patch is similar in concept to the first one I sent; however, it is
based off
Melvin Smith <[EMAIL PROTECTED]> wrote:
>
> For some reason 1 test in pcc.t is failing (the nci call)
Off by one error caused by:
> -for (j = 0; j < 4; j++) {
> +for (set = 0; set < REGSET_MAX; set++) {
As most loops inside Parrot use the former scheme, I'd rather
Melvin Smith wrote:
Feel free to checkout branch imcc1final to test with.
The command should be:
cvs checkout -r imcc1final parrot
Could you be a bit more verbose about that. I've now checked out the
branch "imcc1final", which switched the whole tree to use that sticky
tag. Into which branch
Jeff Clites <[EMAIL PROTECTED]> wrote:
[ threaded var access: read -> load -> use ... ]
> In any case, I thought this sounded like an interesting model,
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints
I'm freezing imcc as version 1 except for bug fixes.
I'm working on fixing the PCC code emitter before
freezing it.
Besides the bugs concerning non-scalability of the register
allocator, I'm interested in any bug reports (for IMCC only) that may
have been Warnocked until now.
I'd like to get imcc1
55 matches
Mail list logo