Stéphane Payrard [EMAIL PROTECTED] wrote:
Abstract pmcs should appear in core_pmcs.h and pmctypes.pasm
because one needs them as base pmcs so as to declare
pseudo-registers. This is a prerequisite to add pmc type checking
to imcc.
I don't think that we need the type names of abstract PMCs.
Jonathan Worthington [EMAIL PROTECTED] wrote:
Thanks - and here's a patch.
Applied, thanks
leo
This is a threading proposal, in the form of a collection of notes.
Rationale:
We need to constantly compare parrot to the JVM, and in particular have
a deep understanding of cases where the JVM performs well (or better
than parrot). The reason for this is obvious: the JVM is the product of
At 01:29 -0800 1/12/04, Jeff Clites wrote:
I'll publish some actual benchmarking numbers, with source code,
separately. (They're just sort of interesting to have on hand.)
If you're benchmarking Perl 5 ithreads for memory usage, you might
want to have a look at Benchmark::Thread::Size.
Liz
Luke Palmer [EMAIL PROTECTED] wrote:
This patch re-implements the register backing stacks as PObjs (so they
can be garbage-collected), honors their COW flags, and adds them to the
interpreter context (where they should be, honest!).
As a healthy side-effect, it encapsulates their behavior
# New Ticket Created by Jeff Clites
# Please include the string: [perl #24880]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24880
Here is a patch to add a few more jitted ops to core.jit for ppc (noop,
neg_i,
Has a date been set for the next release?
Are the docs (especially the PDDs) upto date on best practices?
If not, will that be a goal for the next release?
Tim.
Jeff Clites [EMAIL PROTECTED] wrote:
Here is a patch to add a few more jitted ops to core.jit for ppc (noop,
neg_i, neg_n, abs_n, abs_i).
Thanks, applied.
It also modifies build_tools/jit2h.pl slightly to allow for templates
based on other templates (the patch just moves a block of code
Tim Bunce [EMAIL PROTECTED] wrote:
Has a date been set for the next release?
No, not yet. But I can imagine to have a release in February. It of
course depends on progress WRT objects and threads.
Are the docs (especially the PDDs) upto date on best practices?
No. Not much better then as of
I've only got a couple hundred messages to dig through, so this ought
to be fun. :) Don't be too surprised if I end up sending mail on
things that've already been dealt with, since I'm trying not to let
anything get Warnocked this time through. (I fully expect it'll
happen, but at least I can
At 11:52 AM + 1/12/04, Tim Bunce wrote:
Has a date been set for the next release?
Nope. I suppose we could shoot for another holiday release, if
someone's got a good february one.
Are the docs (especially the PDDs) upto date on best practices?
Alas not, no.
If not, will that be a goal for
At 1:11 AM -0700 1/11/04, Luke Palmer wrote:
I was uneasy when the Cnum_eq and Cstr_eq vtable entries were first
proposed. Sure, they get the job done for Perl 5, but Perl 6 is
expanding its notion of context beyond those compiled in. You're
supposed to be able to add, say, nontransitive ring
Picking the last entry in this thread to reply to...
Here's the scoop with register stacks, stacks in general, and continuations.
The pointers to all these stack tops *should* be part of a
continuation, the same as the registers themselves should be. When a
continuation is taken, all the
At 1:02 AM -0500 1/9/04, Michal Wallace wrote:
I changed my compiler to call savetop before every function
call, and that passes my tests but I'm having trouble
visualizing why. Would I ever NOT want to call savetop
before creating a continuation?
Sure. The only reason to call savetop is if you
At 9:05 PM +0100 1/11/04, Leopold Toetsch wrote:
Harry Jackson [EMAIL PROTECTED] wrote:
I am at the point now where I need to know what type of format you want
the data to come out in.
The first question is: how are these data returned in C.
For posgres, that's easy (which is part of the
At 6:03 PM + 1/11/04, Harry Jackson wrote:
Dan Sugalski wrote:
getting back a full row as an array, getting back a full
row as a hash, and stuff like that. Nothing fancy, and nothing that
high-level, but enough to work the basics without quite as manual work
as the current libpg
Dan Sugalski wrote:
At 9:05 PM +0100 1/11/04, Leopold Toetsch wrote:
Harry Jackson [EMAIL PROTECTED] wrote:
I am at the point now where I need to know what type of format you want
the data to come out in.
The first question is: how are these data returned in C.
For posgres, that's easy
Okay, here's a task for the perl 5 proficient. I may have mentioned
this before, but maybe not.
What we need, or at least could really use, is a script that
automatically generates missing vtable methods for PMCs. Not
defaulting, the way we have now, but actual real working entries.
For
Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:22 PM +0100 1/10/04, Stéphane Payrard wrote:
--- classes/parrotobject.pmc.orig 2003-12-06 01:00:29.0 +0100
+++ classes/parrotobject.pmc 2004-01-10 21:09:08.0 +0100
Keen. And, while worth applying, I'm not sure it
should go to
At 3:29 AM -0500 1/9/04, Michal Wallace wrote:
It seems to me that invoke() is doing the right
thing by swapping the context, but that there
needs to be a yield() method (and opcode?) to
balance it out.
Yes, there does need to be one, or rather there needs to be something
to refresh a
Dan Sugalski wrote:
Well...
What I'd like, I think, is something simple and straightforward. Right
now we've got to fetch each column for each row one by one, which is a
pain in the neck if you want to get a full row back. Having a fetchrow
that returned an Array with the value for column one
Tim Bunce wrote:
I see Dan says in his blog Yeah, I know, we should use libffi, and
we may as a fallback, if we don't just give in and build up the
function headers everywhere.
I'm not familiar with libffi so this may be a dumb question,
but why the apparent reluctance to use it?
The
At 8:27 PM + 1/11/04, Ewan Birney wrote:
First off apologies if there is some posting/site which details
this well - I started at www.parrotcode.org and spent a while
fruitlessly wondering why noone had posted at the mailing list
archive nicely html'ified
http://archive.develooper.com/[EMAIL
At 4:07 PM + 1/12/04, Harry Jackson wrote:
Dan Sugalski wrote:
Well...
What I'd like, I think, is something simple and straightforward.
Right now we've got to fetch each column for each row one by one,
which is a pain in the neck if you want to get a full row back.
Having a fetchrow that
On Mon, Jan 12, 2004 at 09:33:57AM -0500, Dan Sugalski wrote:
At 11:52 AM + 1/12/04, Tim Bunce wrote:
Has a date been set for the next release?
Nope. I suppose we could shoot for another holiday release, if
someone's got a good february one.
Valentines day? :-)
[ On a whim I thought
Dan Sugalski [EMAIL PROTECTED] wrote:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
Only one of these is needed (and currently used: used)
struct hunk *upchain;
struct regframe RegisterFrame[FRAMES_PER_HUNK];
I'd rather not have the store
At 4:47 PM + 1/12/04, Tim Bunce wrote:
On Mon, Jan 12, 2004 at 09:33:57AM -0500, Dan Sugalski wrote:
At 11:52 AM + 1/12/04, Tim Bunce wrote:
Has a date been set for the next release?
Nope. I suppose we could shoot for another holiday release, if
someone's got a good february one.
Dan Sugalski wrote:
That works too. If the information's available someone'll build what
they want. Whichever way you're comfortable with. (Though given my
preferences, I'd add in the hash fetch version as part of the low-level
interface)
Roger:
To clarify you want:
1. You want a hash with
Dan Sugalski writes:
Okay, here's a task for the perl 5 proficient. I may have mentioned
this before, but maybe not.
What we need, or at least could really use, is a script that
automatically generates missing vtable methods for PMCs. Not
defaulting, the way we have now, but actual real
At 3:24 PM -0500 1/9/04, Melvin Smith wrote:
:)
Heh. It's not in production yet! Looking darned good, though. Good
enough to stand up in front of the company principals and put on a
non-rigged dog and pony show. (I know, boggle at the prospect, a DP
with no tricks :)
--
And, out of interest, what is the rate limiting step for this (amount of
coffee given to Dan?)
In large part, yes. Communication bandwidth and latency is also an
issue -- there are things that we could clear up in a week if we got
a half-dozen of the interested parties in a room with lots
In no order, but the week's Dan makes up his mind list:
*) Namespaces
*) PMC init params
*) Thread design
As well as getting PDD16 patched up some. Might add more as I dig
back through the backlog (only a few hundred messages left to go...)
--
Dan
On Mon, Jan 12, 2004 at 10:05:51AM +0100, Leopold Toetsch wrote:
Stéphane Payrard [EMAIL PROTECTED] wrote:
Abstract pmcs should appear in core_pmcs.h and pmctypes.pasm
because one needs them as base pmcs so as to declare
pseudo-registers. This is a prerequisite to add pmc type checking
to
Tim Bunce wrote:
The developers _of_ parrot need to keep in mind the needs of those
poised on the edge of developing _in_ parrot.
I think that there are a lot of people who would help but the learning
curve seems to high. I for one am finding it a pretty steep curve at the
moment and am always
On Jan 12, 2004, at 8:07 AM, Harry Jackson wrote:
Dan Sugalski wrote:
Having a fetchrow_hash that returned a Hash where the keys are the
column names and the values are the column values would be most of
the rest.
I read somewhere that accessing a hash was slightly slower than
accessing and
Jeff Clites wrote:
On Jan 12, 2004, at 8:07 AM, Harry Jackson wrote:
Dan Sugalski wrote:
Having a fetchrow_hash that returned a Hash where the keys are the
column names and the values are the column values would be most of
the rest.
I read somewhere that accessing a hash was slightly slower
Harry Jackson wrote:
I think that there are a lot of people who would help but the learning
curve seems too high. I for one am finding it a pretty steep curve at the
moment and am always worried about making an ass of myself when posting.
I decided to hell with it, if you're ain't in you
On Sat, Jan 10, 2004 at 09:42:14PM +, Tim Bunce wrote:
On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I assume the plan is to get on-the-fly building of NCI stubs working
everywhere. Platforms where that works don't need the
Robert Eaglestone wrote:
Yes, I'm a shy lurker.
Are there any more, don't be shy, there might be a lot of barking but no
one bites at least I have not had anyone bite me _yet_.
Is there anyone on the list who wants to help but does not know where to
start. If you are really that shy email me
At 10:13 AM -0600 1/12/04, Garrett Goebel wrote:
Tim Bunce wrote:
I see Dan says in his blog Yeah, I know, we should use libffi, and
we may as a fallback, if we don't just give in and build up the
function headers everywhere.
I'm not familiar with libffi so this may be a dumb question,
but
At 5:01 PM + 1/12/04, Harry Jackson wrote:
Tim Bunce wrote:
and am always worried about making an ass of myself when posting.
Dammit, and here I was trying to lead by example. It's OK! :)
Smoothing the path for newcommers, of both types, is very important.
I spent quite a bit of time
At 4:50 PM + 1/12/04, Harry Jackson wrote:
Dan Sugalski wrote:
That works too. If the information's available someone'll build
what they want. Whichever way you're comfortable with. (Though
given my preferences, I'd add in the hash fetch version as part of
the low-level interface)
Roger:
I'm currently building some docs related modules which will allow us to
create an html tree from the pod, inline stuff included.
I cleaned up all the pod errors last week and was going to report on
that but got sidetracked when I realised that POD::Checker diverged
somewhat from Perl's own pod
Well, one thing that people can contribute that doesn't require much
(if any) knowledge of the internals is tests (whether in PASM, PIR,
or one of the other languages that run on top of Parrot). Tests that
uncover bugs are particularly helpful!
Simon
At 1:26 PM -0500 1/12/04, Simon Glover wrote:
Well, one thing that people can contribute that doesn't require much
(if any) knowledge of the internals is tests (whether in PASM, PIR,
or one of the other languages that run on top of Parrot). Tests that
uncover bugs are particularly helpful!
At 5:47 PM +0100 1/12/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
Only one of these is needed (and currently used: used)
struct hunk *upchain;
struct regframe
Tim Bunce wrote:
Tim Bunce wrote:
I see Dan says in his blog Yeah, I know, we should use libffi, and
we may as a fallback, if we don't just give in and build up the
function headers everywhere.
I'm not familiar with libffi so this may be a dumb question,
but why the apparent
On Sun, Jan 11, 2004 at 07:33:12PM +0100, Stéphane Payrard wrote:
Also the following patch exercises all the variations including
the susmentioned access thru a key pmc that may contain either a
string or an int.
Thanks, applied
Nicholas Clark
Harry Jackson wrote:
If there are any shy lurkers out there please speak now or forever hold
your peace.
Poit. That's me.
On Monday, January 12, 2004, at 04:29 , Jeff Clites wrote:
5) Java seems to use a check-in/check-out model for access to global
data, in which global data lives in a central store, but is copied
back-and-forth to thread-local storage for modification. I don't fully
understand the
On Monday, January 12, 2004, at 11:37 , Dan Sugalski wrote:
At 4:07 PM + 1/12/04, Harry Jackson wrote:
Dan Sugalski wrote:
Well...
What I'd like, I think, is something simple and straightforward.
Right now we've got to fetch each column for each row one by one,
which is a pain in the neck
Gordon Henriksen wrote:
fetchrow_hashref is definitely a very useful, but my favorite (and also
the most efficient) DBI methodology is bind_columns. DBI maintains a
list of references corresponding to columns in the result set, and when
the result set is advanced, stores the values into the
This fixes a rather obvious and silly oversight in my patch.
Luke
Index: src/register.c
===
RCS file: /cvs/public/parrot/src/register.c,v
retrieving revision 1.35
diff -u -r1.35 register.c
--- src/register.c 12 Jan 2004
I have somewhat a predicament. I want to create a continuation, and
have that continuation stored in the register stack that it closes over
(this is how I'm implementing a loop with continuations). Unless I'm
having a major braino, I don't think this is possible at the moment.
I got around this
Luke Palmer writes:
...
goto NEXT();
@@ -84,6 +90,19 @@
$1-vtable-init_pmc_props(interpreter, $1, $3, $4);
goto NEXT();
}
+# }
^
Don't mind that. I thought I saw an extra one, and commented it out to
make sure I wasn't being stupid. Wasn't, and forgot to uncomment.
At 1:00 PM -0700 1/12/04, Luke Palmer wrote:
I have somewhat a predicament. I want to create a continuation, and
have that continuation stored in the register stack that it closes over
(this is how I'm implementing a loop with continuations).
Erm. I don't think this is the right way to do this.
Stéphane Payrard [EMAIL PROTECTED] wrote:
Example:
.sym scalar var
new var, .Perlint # the instance is a substype of Cscalar
.sym pmc var
is as good. There isn't any difference. Its even simpler for compiler
writers.
My understanding is that we already have that. Cnoinit types
At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote:
Stéphane Payrard [EMAIL PROTECTED] wrote:
Example:
.sym scalar var
new var, .Perlint # the instance is a substype of Cscalar
.sym pmc var
is as good. There isn't any difference. Its even simpler for compiler
writers.
Which brings up a
Dan Sugalski wrote:
Which brings up a question. What's the difference between .local and .sym?
I was hoping someone would ask this.
Harry
On Mon, 12 Jan 2004, Luke Palmer wrote:
I have somewhat a predicament. I want to create a continuation, and
have that continuation stored in the register stack that it closes
over (this is how I'm implementing a loop with continuations).
Unless I'm having a major braino, I don't think this
Dan Sugalski wrote:
At 4:50 PM + 1/12/04, Harry Jackson wrote:
done similar to
80 getnext:
81
82 .pcc_begin prototyped
83 .pcc_call fetchrow_hash
84 nextrow:
85 .result rowhash
86 .result answer
87
I'm using Test::xxx as a tool for testing the functioning of a rather
large C program (currently at 112K+ tests). Many of the tests
consist of running combinations of parameters in many nested loops.
Sometimes some of these tests fail. For example, out of a
test-script that has about 8000
You can just do Test::Builder-new to get the Test::Builder object. It will
be the same one used by Test::More because it's a singleton. That way you
should need no patches,
F
On Mon, Jan 12, 2004 at 05:26:59PM +0100, Elizabeth Mattijsen wrote:
I'm using Test::xxx as a tool for testing the
At 16:47 + 1/12/04, Fergal Daly wrote:
On Mon, Jan 12, 2004 at 05:26:59PM +0100, Elizabeth Mattijsen wrote:
So, what I'd like to add for myself is something like:
todo_ok( test,{
1001 = a b c still fails, wonder why,
2345 = d e gf to be investigated,
},ok text );
The conundrum I'm
Harry Jackson wrote:
The following shows roughly what I had to do to display it. I am using a
global HASH called MetaData that stores various bits about the current
statement being executed.
Sorry: missed a bit
The MetData is where I get the TupleData Array and the associated
FieldData Array
On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote:
At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote:
Stéphane Payrard [EMAIL PROTECTED] wrote:
Example:
.sym scalar var
new var, .Perlint # the instance is a substype of Cscalar
.sym pmc var
is as good. There isn't
Nicholas Clark [EMAIL PROTECTED] wrote:
(courtesy of St phane Payrard)
Sté{f,phane} that's still iso_8859_1. Nick, *they* are talking about
unicode operators and code.
,--[ man 7 iso_8859_1 ]
| 351 233 E9 é LATIN SMALL LETTER E
Luke Palmer [EMAIL PROTECTED] wrote:
This fixes a rather obvious and silly oversight in my patch.
+PObj_COW_CLEAR((PObj*)buf);
I don't think that works or better let's say: it's ok 50 percent - for
the new buf chunk, but the old one, which maybe hasn't any refering
COWed copy anymore still
At 10:09 PM +0100 1/12/04, Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
This fixes a rather obvious and silly oversight in my patch.
+PObj_COW_CLEAR((PObj*)buf);
I don't think that works or better let's say: it's ok 50 percent - for
the new buf chunk, but the old one, which
Dan Sugalski [EMAIL PROTECTED] wrote:
Which brings up a question. What's the difference between .local and .sym?
They are equivalent for plain code. *But* C.local was already used for
local labels inside macros of assembler.pl - so is it now - and it was
used for declaring variables in imcc.
$
Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:09 PM +0100 1/12/04, Leopold Toetsch wrote:
I think I'd as soon leave COW-marked buffers as COW forever, or until
they're garbage collected.
I'm thinking of that:
1) main creates and calls sub1 which returns
- sub1 doesn't mess with the Buffer
Dan Sugalski wrote:
At 5:01 PM + 1/12/04, Harry Jackson wrote:
Tim Bunce wrote:
and am always worried about making an ass of myself when posting.
Dammit, and here I was trying to lead by example. It's OK! :)
Smoothing the path for newcommers, of both types, is very important.
I spent
Dan Sugalski writes:
At 10:09 PM +0100 1/12/04, Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
This fixes a rather obvious and silly oversight in my patch.
+PObj_COW_CLEAR((PObj*)buf);
I don't think that works or better let's say: it's ok 50 percent - for
the new buf
Michal Wallace writes:
On Mon, 12 Jan 2004, Luke Palmer wrote:
I have somewhat a predicament. I want to create a continuation, and
have that continuation stored in the register stack that it closes
over (this is how I'm implementing a loop with continuations).
Unless I'm having a major
Hi,
I currently have a file named win32.pasm containing the following:-
saveall
loadlib P1, 'user32'
dlfunc P2, P1, 'MessageBoxA', 'llttl'
store_global 'MessageBox', P2
# MANY MORE LINES LIKE THIS
restoreall
I compile that file to a .pbc file, which works out OK. In then have an imc
file that
Harry~
You have outlined my situation exactly. I completely agree.
Matt
Harry Jackson wrote:
Tim Bunce wrote:
The developers _of_ parrot need to keep in mind the needs of those
poised on the edge of developing _in_ parrot.
I think that there are a lot of people who would help but the
Ping. One quiet lurker here. I'd like to help out, but not really sure
where to start. Given Dan's suggestion, I think I might start looking at
some more abusive-type tests. Destruction and dissection can be fun. I'd
be happy to help out in other newbie-type ways, too.
--Kevin
Harry Jackson
On Mon, 12 Jan 2004, Luke Palmer wrote:
Michal Wallace writes:
On Mon, 12 Jan 2004, Luke Palmer wrote:
I have somewhat a predicament. I want to create a continuation, and
have that continuation stored in the register stack that it closes
over (this is how I'm implementing a loop
Michal Wallace writes:
On Mon, 12 Jan 2004, Luke Palmer wrote:
Michal Wallace writes:
On Mon, 12 Jan 2004, Luke Palmer wrote:
I have somewhat a predicament. I want to create a continuation, and
have that continuation stored in the register stack that it closes
over (this is
On Mon, 12 Jan 2004, Luke Palmer wrote:
Well... A Coroutine is a pausable, resumable continuation, right?
Or basically a closure with a continuation inside it.
Both of those sentences seem wildly redundant to me. I think we might
be stuck on vocabulary. We're surely both understanding
If there are any shy lurkers out there please speak now or forever hold
your peace.
I'll admit to being a shy lurker... (and have rudimentary C knowledge, but a
bit low on the elbow grease atm :-/)
This also gives me an opportunity to mention to anyone with more time (and
possibly ability)
81 matches
Mail list logo
