> 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)
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 understand
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
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 implement
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 wr
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 learni
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 s
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 havin
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 - fo
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 <[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 B
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
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, whic
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
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
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 C
> >
> > .sym pmc var
> >
> >is as g
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 f
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 .pcc_end
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 thi
Dan Sugalski wrote:
Which brings up a question. What's the difference between .local and .sym?
I was hoping someone would ask this.
Harry
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 C
.sym pmc var
is as good. There isn't any difference. Its even simpler for compiler
writers.
Which brings up a quest
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> Example:
>.sym scalar var
>new var, .Perlint # the instance is a substype of C
.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. C types
> define m
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. Be
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 uncomm
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
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 09:50:2
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 vari
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 i
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 performan
Harry Jackson wrote:
If there are any shy lurkers out there please speak now or forever hold
your peace.
Poit. That's me.
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
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
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 RegisterFram
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!
Abso
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
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
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:
To
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 fishin
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 w
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 off
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
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 y
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 t
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 ar
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 wo
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 check
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 con
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
---
> >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
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 D&P
with no tricks :)
--
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
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
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.
Valen
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 t
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 func
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 thou
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 re
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 tes
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 PR
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?
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 i
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 continuation
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 g
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 exampl
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 (w
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 require
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 probl
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 wan
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 frames
At 1:11 AM -0700 1/11/04, Luke Palmer wrote:
I was uneasy when the C and C 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" context if yo
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.pmc2004-01-10 21:09:08.0 +0100
Keen. And, while worth applying, I'm not sure it
should go to parrotobject. (Or, rather, I think
it ou
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 th
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 t
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 o
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
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.
# New Ticket Created by Jeff Clites
# Please include the string: [perl #24880]
# in the subject line of all future correspondence about this issue.
# 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, neg_n, ab
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 behavio
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
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
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> Thanks - and here's a patch.
Applied, thanks
leo
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 PMC
82 matches
Mail list logo
