* Robin Szemeti <[EMAIL PROTECTED]> [010428 15:50]:
> On Fri, 27 Apr 2001, you wrote:
> > On Fri, 27 Apr 2001, Robin Szemeti wrote:
> > > On Fri, 27 Apr 2001, someone who Robin's attrib to fscked up wrote:
> > >
> > > > [side note: I did just see a bizarre thread in macosx-dev where
> > > > one gu
On Fri, Apr 27, 2001 at 06:50:18PM +0100, Leon Brocard wrote:
> OK, I give you Perl, the Perl debugger, and B::Generate. First one to
> optimise Perl code (maybe replacing bits of Perl with XS on the fly?)
> gets a pat on the back.
I think NI-S is working on it; see recent perl6-language discussi
Friday, April 27, 2001, 2:20:21 PM, Paul Makepeace wrote:
PM> On Fri, Apr 27, 2001 at 01:51:38PM -0500, Mike Jarvis wrote:
>> Sounds much more like a function of the compiler to me. A
>> really good Fortran compiler would turn out faster code than a bad c
>> compiler.
PM> But that isn't saying
On Fri, Apr 27, 2001 at 01:51:38PM -0500, Mike Jarvis wrote:
> Sounds much more like a function of the compiler to me. A
> really good Fortran compiler would turn out faster code than a bad c
> compiler.
But that isn't saying much. People tend not to use really bad things if
they can help it. FW
Friday, April 27, 2001, 1:09:05 PM, Robin Szemeti wrote:
RS> but in the end (assuming that both
RS> codesets use similar basic principles) you will not beat the speed of C
RS> with anything other than hand optimised assembler. Now that is a fact.
Sounds much more like a function of the compiler t
On Fri, 27 Apr 2001, you wrote:
> On Fri, 27 Apr 2001, Robin Szemeti wrote:
> > On Fri, 27 Apr 2001, someone who Robin's attrib to fscked up wrote:
> >
> > > [side note: I did just see a bizarre thread in macosx-dev where
> > > one guy claimed his FFT code was executing faster in Java than C
> > >
Mark Fowler sent the following bits through the ether:
> Don't see why this isn't possible
Indeed. All you need to do this is:
o bytecode and a virtual machine
o some way of instrumenting said VM to save interesting info
o ability to rewrite bytecode on fly
OK, I give you Perl, the Perl
On Fri, 27 Apr 2001, Robin Szemeti wrote:
> On Fri, 27 Apr 2001, someone who Robin's attrib to fscked up wrote:
>
> > [side note: I did just see a bizarre thread in macosx-dev where
> > one guy claimed his FFT code was executing faster in Java than C
> > because its interpreter used runtime info t
On Fri, 27 Apr 2001, you wrote:
> Paul Makepeace sent the following bits through the ether:
>
> > If it was that simple, someone would've done it -- DBI is a very
> > mature and competent module
>
> That's the problem. It seems like people aren't content with writing
> their own, slightly differ
Paul Makepeace sent the following bits through the ether:
> If it was that simple, someone would've done it -- DBI is a very
> mature and competent module
That's the problem. It seems like people aren't content with writing
their own, slightly different, templating system, and have moved onto
ma
On Fri, 27 Apr 2001, you wrote:
> On Fri, Apr 27, 2001 at 09:38:45AM +0100, Robin Szemeti wrote:
> > but of course .. however the topic was (somewhere along the thread)
> > related to portable methods to try and keep from having to change all the
> > SQL between different db version.
>
> Why do t
On Fri, Apr 27, 2001 at 09:38:45AM +0100, Robin Szemeti wrote:
> but of course .. however the topic was (somewhere along the thread)
> related to portable methods to try and keep from having to change all the
> SQL between different db version.
Why do this? Unless you're using the db in a toy cap
On Fri, 27 Apr 2001, you wrote:
> The real answer is since you are using a database you care about speed
> so spend three minutes reading the docs/google for your particular
> database vendor and implement whatever strategy is suggested
> (AUTO_INCREMENT, ROWID, oid, SEQUENCE, before-row-insert t
On Fri, Apr 27, 2001 at 07:57:04AM +0100, Piers Cawley wrote:
> David Cantrell <[EMAIL PROTECTED]> writes:
> > Unfortunately no. You'd have to:
> > LOCK the table
> > SELECT the maximum id currently in use and add one
> > INSERT with that id
> > UNLOCK the table
> > so all your other quer
David Cantrell <[EMAIL PROTECTED]> writes:
> Unfortunately no. You'd have to:
> LOCK the table
> SELECT the maximum id currently in use and add one
> INSERT with that id
> UNLOCK the table
> so all your other queries will block until the table is unlocked.
Create a 'seq' table associated
On Wed, Apr 25, 2001 at 12:50:05PM +0100, Mark Fowler wrote:
> On Wed, 25 Apr 2001, David Cantrell wrote:
>
> > Trouble is, they all have non-standard extensions, which are *really* handy
> > and which you *will* use if you don't know any better. For example, MySQL
> > has AUTO_INCREMENT fields
Mark Fowler sent the following bits through the ether:
> Why you say don't know better, what should I use instead of this. Is
> there any sensible way to do this in bog standard SQL that won't have a
> massive perfomance hit on mysql?
The nice thing about SQL is that there are so many standards
On Wed, 25 Apr 2001, David Cantrell wrote:
>
> Trouble is, they all have non-standard extensions, which are *really* handy
> and which you *will* use if you don't know any better. For example, MySQL
> has AUTO_INCREMENT fields which are dead useful for id fields; the closest
> Oracle equivalent
On Tue, Apr 24, 2001 at 04:27:42PM -0700, Paul Makepeace wrote:
> On Tue, Apr 24, 2001 at 12:28:42PM +0100, Dominic Mitchell wrote:
> > Don't forget that even if you could automatically change the API over,
> > you'd still have to change all the SQL in the API as well. Which is
> > probably just
On Tue, Apr 24, 2001 at 12:28:42PM +0100, Dominic Mitchell wrote:
> Don't forget that even if you could automatically change the API over,
> you'd still have to change all the SQL in the API as well. Which is
> probably just as difficult a task, given how much SQL can vary from
> product to produ
On Tue, Apr 24, 2001 at 12:28:42PM +0100, Dominic Mitchell wrote:
> On Tue, Apr 24, 2001 at 02:58:23AM -0700, Paul Makepeace wrote:
> > Here's a perl question (OK, not really).. Is anyone aware of a
> > compatibility/wrapper library which a developer could use to take an
> > app using the MySQL AP
On Tue, Apr 24, 2001 at 02:58:23AM -0700, Paul Makepeace wrote:
> Here's a perl question (OK, not really).. Is anyone aware of a
> compatibility/wrapper library which a developer could use to take an
> app using the MySQL API and with some (ideally) minimal munging turn
> it into Oracle OCI or Pro
Here's a perl question (OK, not really).. Is anyone aware of a
compatibility/wrapper library which a developer could use to take an
app using the MySQL API and with some (ideally) minimal munging turn
it into Oracle OCI or Pro*C code?
I'm faced with converting a couple of apps that have MySQL sup
23 matches
Mail list logo
