On Fri, Mar 12, 2004 at 08:12:52PM -0500, Dan Sugalski wrote:
: Okay, so I'm fiddling around in the guts of the object system getting
: the groundwork laid for some speed increases (I hope--we're just
: barely faster than perl 5 when doing the equivalent of perl's tie
: with the base object type
At 11:24 AM +0100 3/14/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... --should we have the
base object system participate in multimethod dispatch? That is, if
someone does an:
add P1, P2, P3
and P2 is a parrot object, should that add vtable method
automatically r
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... --should we have the
> base object system participate in multimethod dispatch? That is, if
> someone does an:
> add P1, P2, P3
> and P2 is a parrot object, should that add vtable method
> automatically redispatch to MMD if the vtable method can't
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
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
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
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
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: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
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
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
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. If that's a
defined structure, I'd overlay this structure with an UnManagedStruct
PMC and then acc
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 requires.
OK.
I am at the poi
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 requires.
OK.
I am at the point now where I need to k
Dan Sugalski wrote:
At 1:02 PM + 12/27/03, Harry Jackson wrote:
Being fairly new to parrot and probably naive I can see a few different
ways of doing this.
A C wrapper ie: parrot/classes/parrotdbi.pmc etc
A C wrapper ie: parrot/dynclasses/parrotdbi.pmc etc
A loadable pasm function library that
At 1:02 PM + 12/27/03, Harry Jackson wrote:
Dan Sugalski wrote:
Dunno if I replied, but... Next step is a higher level wrapper, if
you're up for fiddling with Postgres itself. Stuff like a single
call > to connect (right now you have to make the connect call and
poll over
and over again),
On Sat, Dec 27, 2003 at 01:02:34PM +, Harry Jackson wrote:
> Dan Sugalski wrote:
> >
> > Dunno if I replied, but... Next step is a higher level wrapper, if
> > you're up for fiddling with Postgres itself. Stuff like a single call
> > to connect (right now you have to make the connect call and
Dan Sugalski wrote:
>
> Dunno if I replied, but... Next step is a higher level wrapper, if
> you're up for fiddling with Postgres itself. Stuff like a single call
> to connect (right now you have to make the connect call and poll over
> and over again),
I did some benchmarks using your original l
At 11:10 PM + 12/18/03, Harry Jackson wrote:
Dan Sugalski wrote:
It's util/ncidef2pasm.pl, actually. build_nativecall builds the
stub routines for the interpreter if a JIT isn't available. The
definitions of the characters are the same, but ncidef2pasm's a bit
better documented. (There's emb
At 11:10 PM + 12/18/03, Harry Jackson wrote:
Dan Sugalski wrote:
It's util/ncidef2pasm.pl, actually. build_nativecall builds the
stub routines for the interpreter if a JIT isn't available. The
definitions of the characters are the same, but ncidef2pasm's a bit
better documented. (There's emb
Dan Sugalski wrote:
It's util/ncidef2pasm.pl, actually. build_nativecall builds the stub
routines for the interpreter if a JIT isn't available. The definitions
of the characters are the same, but ncidef2pasm's a bit better
documented. (There's embedded POD) Invocation is:
perl util/ncidef2pas
At 9:47 PM + 12/11/03, Harry Jackson wrote:
Dan Sugalski wrote:
Yep, though that's a big part of it. postgres.pasm is generated
from postgres.declarations, FWIW--there's a script in the library
somewhere.
Is /parrot/build_tools/build_nativecall.pl the script in question and if
so whats its us
Dan Sugalski wrote:
Yep, though that's a big part of it. postgres.pasm is generated from
postgres.declarations, FWIW--there's a script in the library somewhere.
Is /parrot/build_tools/build_nativecall.pl the script in question and if
so whats its usage.
I have done postgres.declarations, please se
At 4:28 PM + 12/10/03, Harry Jackson wrote:
Dan Sugalski wrote:
If someone'd like to take a shot at making a nice OO wrapper for
Postgres, especially if they'd like to upgrade the postgres
interface to 7.4, I would very much appreciate it. It'd be a nice
demo, and a good start on a DBI modul
Dan Sugalski wrote:
If someone'd like to take a shot at making a nice OO wrapper for
Postgres, especially if they'd like to upgrade the postgres interface to
7.4, I would very much appreciate it. It'd be a nice demo, and a good
start on a DBI module for us. (And yeah, there's an element of "do m
On Dec 3, 2003, at 12:03 PM, Dan Sugalski wrote:
At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> *) Exceptions we're happy with
Create an Exception class hierarchy?
I'm not 100% sure I want to go with a real OO style of exceptions, but
that might jus
Michal Wallace <[EMAIL PROTECTED]> wrote:
> What is the _return_cc attribute on an
> exception? Can I use it to resume the
> code as if the exception never happened?
When an exception is resumable, you can return by invoking this return
continuation. But details (i.e. is C<_return_cc> put into P1
On Wed, 3 Dec 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
>
> >>Create an Exception class hierarchy?
>
> > I'm not 100% sure I want to go with a real OO style of exceptions,
> > but that might just be the neo-luddit
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
>>Create an Exception class hierarchy?
> I'm not 100% sure I want to go with a real OO style of exceptions,
> but that might just be the neo-luddite in me.
It probably depends what HLL want to have. Anywa
At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The code definitely needs some looking at and cleanup. It's not
perfect and I expect it's flawed in a number of places. I'm just
happy to get the damn stuff into the repository so the bytecode tests
can s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The code definitely needs some looking at and cleanup. It's not
> perfect and I expect it's flawed in a number of places. I'm just
> happy to get the damn stuff into the repository so the bytecode tests
> can start.
I've put in a first test. Needed some c
36 matches
Mail list logo
