The attached patch adds 2 Configure.pl options, to help with the
process of getting ICU to build on platforms which are having
difficulties with it:
% perl Configure.pl --help
...
ICU Options:
--icuplatform=(platform) Platform name to pass to ICU's
runConfigureICU
--icuconfigureargs=(ar
On 20 Apr 2004, at 12:53, Dan Sugalski wrote:
So, parrotcode.org's getting a bit crusty in its content (though with
a spiffy-keen new look if you've not looked in a while) and we need to
fix that.
Agreed -- as an effective newcomer to the project (followed it for a
while a year or so ago, but
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> Why does Parrot need this? What's so special about hyper operations that
> makes Parrot want to take them on?
The special thing is optimizing for integers and floats. The bad thing
is overridden »op« for aggregates holding PMCs. These might do whatever
t
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:10 PM +0200 4/20/04, Leopold Toetsch wrote:
[ unused scalar vtables in aggregates ]
>>Aren't the relevant vtable slots for aggregates unused anyway?
> Only because we've not gotten around to writing the code. :)
Do you want to reserve these just fo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Something for people to work on, and something that can be worked on
> piecemeal (which is good). We need to make parrot's build less
> dependent on the flags set in the current perl install, especially
> for things like the C compiler and linker flags.
..
On Tue, 2004-04-20 at 16:30, Dan Sugalski wrote:
> Because they can be overridden separately from the regular version of
> the operation.
Of course.
Quoting A3 (note, syntax has changed, but as far as I know, the content has not):
@a ^* @b
is equivalent to this:
At 4:20 PM -0400 4/20/04, Aaron Sherman wrote:
On Tue, 2004-04-20 at 11:53, Dan Sugalski wrote:
Y'know... let's just go all the way with this, since we're going to have to.
We'll add a hyper version of all the vtable entries.
Another of those darned "I don't get it" posts, but I'll keep this on
On Tue, 2004-04-20 at 1:26PM, Aaron Sherman wrote:
>
> Another of those darned "I don't get it" posts, but I'll keep
> this one short.
>
> Why does Parrot need this? What's so special about hyper
> operations that makes Parrot want to take them on?
I'm not sure I entirely get it myself, but perhap
On Tue, 2004-04-20 at 11:53, Dan Sugalski wrote:
> Y'know... let's just go all the way with this, since we're going to have to.
>
> We'll add a hyper version of all the vtable entries.
Another of those darned "I don't get it" posts, but I'll keep this one
short.
Why does Parrot need this? What'
Something for people to work on, and something that can be worked on
piecemeal (which is good). We need to make parrot's build less
dependent on the flags set in the current perl install, especially
for things like the C compiler and linker flags.
So... if folks would like to take a shot, any a
So, parrotcode.org's getting a bit crusty in its content (though with
a spiffy-keen new look if you've not looked in a while) and we need
to fix that.
Rather than putting this on my essentially infinitely long todo list,
this'd be a good spot for someone who wants to get involved to, well,
get
Joseph E. Sacco <[EMAIL PROTECTED]> wrote:
> ...
> t/pmc/signal# Failed test (t/pmc/signal.t at line 65)
The problem is very likely in the test itself. To verify that you could
run e.g. the first test[1] with a longer sleep and send a SIGHUP
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Here's another tiny patch, to let us fast-fail string_equal if we have
> cached hashval's which don't match.
What about a hash value collision?
leo
At 8:10 PM +0200 4/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
We'll add a hyper version of all the vtable entries. Since this is
going to bloat the hell out of the vtable, we'll do it by adding a
VTABLE *hyper to the main vtable structure and hang it off there.
Aren't
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We'll add a hyper version of all the vtable entries. Since this is
> going to bloat the hell out of the vtable, we'll do it by adding a
> VTABLE *hyper to the main vtable structure and hang it off there.
Aren't the relevant vtable slots for aggregates unu
On Apr 19, 2004, at 2:25 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
This change speeds up the attached benchmark by a factor of 1.86 in
the
optimize case (via --optimize, so -Os), or 3.73 in the unoptimized
case
(on Mac OS X):
Wheee, that's a lot.
Here's another tiny patc
# New Ticket Created by "Joseph E. Sacco, Ph. D."
# Please include the string: [perl #28995]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28995 >
System:
* PPC with dual 533MHz G4 CPU's, 1GB RAM, SCSI disks
* Yellow Do
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:30 AM +0200 4/20/04, Leopold Toetsch wrote:
>>
>>Why I second table? This just adds duplicate code paths and complexity.
>>One constant table ought to be enough.
> Mainly because I was assuming that we were going to separate the
> float, pmc, and stri
At 4:28 PM +0200 4/20/04, Leopold Toetsch wrote:
I've implemented a (rather hackish and incomplete) new opcode called
C. Usage looks like:
ar = new IntList
ar = 100
hyper
ar = 10
or
hyper
ar += 10
The atached tests fill an integer array with one Meg int constants
and
Jens Rieks <[EMAIL PROTECTED]> wrote:
> What does this do now?
> set Px, "str"
Good question:
$ cat set.pasm
new P0, .PerlString
set P0, "str"
set S0, P0
chopn S0, 2
print "str"
print "\n"
end
$ parrot set.pasm
s
:)
We should separate the 2 cases (set_p_sc and set_p_s)
I've implemented a (rather hackish and incomplete) new opcode called
C. Usage looks like:
ar = new IntList
ar = 100
hyper
ar = 10
or
hyper
ar += 10
The atached tests fill an integer array with one Meg int constants and
then increment each value 5 times.
Here are the
At 8:30 AM +0200 4/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The interpreter stuff's simple enough--we teach the ops preprocessor
to handle them the same way that it does string constants, and index
into the PMC constant table. We'll want to put them in a separate
p
On Tuesday 20 April 2004 09:44, Leopold Toetsch wrote:
> set Sx, Sy # alias Sx to Sy
> set Sx, "str" # set Sx to COW copy of "str"
> set Px, Sy # CHANGED make Px refer to Sy
> assign Px, Sy # set Px to COW copy of Sy
What does this do now?
set Px, "str"
jens
Chromatic <[EMAIL PROTECTED]> wrote:
> What's the secret syntax for passing and retriving arrays of things to
> and from NCI? I have this signature:
There is no secret syntax:
,--[ docs/pmc/struct.pod ]-
|Array Size
|The second initiali
> Speaking about parrotbug, are the [EMAIL PROTECTED] addresses
> created? What do they currently do?
parrotbug@ sends to the tracker
status-{ok,nok}@ currently end up in mailboxes that nobody reads
-R
Chromatic <[EMAIL PROTECTED]> wrote:
> I played with making executables today (to no avail; it's having trouble
> with load_bytecode ops, but that's a different issue).
It's likely that this needs some runcore fiddling. Initially compiled
code resides in the executable, while additional code is a
Bernhard Schmalhofer (via RT) wrote:
In Parrot m4 0.0.4 there a couple of new builtin macros. The internal data
structure have been refactored in order to support some more features in the
future. However I haven't yet gotten around to start using objects.
Due to some new PIR syntax I could simpl
I've now checked in some changes WRT these opcodes.
1) Strings - summary
set Sx, Sy# alias Sx to Sy
set Sx, "str" # set Sx to COW copy of "str"
set Px, Sy# CHANGED make Px refer to Sy
assign Px, Sy # set Px to COW copy of Sy
2) PMC summary
set Px, Py# al
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The interpreter stuff's simple enough--we teach the ops preprocessor
> to handle them the same way that it does string constants, and index
> into the PMC constant table. We'll want to put them in a separate
> part of the bytecode file,
Why I second table
What's the secret syntax for passing and retriving arrays of things to
and from NCI? I have this signature:
extern DECLSPEC void SDLCALL SDL_UpdateRects
(SDL_Surface *screen, int numrects, SDL_Rect *rects);
That'd be *very* handy to expose.
(Yeah, Dan, I know you said yo
30 matches
Mail list logo
