RE: [sqlite] replaced awk mkopcode scripts now perl based
> On 5/23/2005 Doug Henry [mailto:[EMAIL PROTECTED] wrote:
> I have always used awka to convert awk scripts to C code,
> allowing for a native execuatable to be built, seems to be
> the most compatible solution.
>
That's cool! Thanks for the info on http://awka.sourceforge.net/ I'd not
seen that before.
Solaris awk compatibility issues can often be resolved by using "nawk"
(which is installed in the base OS along with awk). I've not tried using
sqlite under Solaris so this is more of a general comment, the SUN awk
is pretty basic. As Tiago pointed out gawk will behave as expected BUT
you do need to go ahead and install it.
Could a Solaris developer/user try using nawk? I just spent a few mins
getting sqlite-3.2.1.tar.gz from http://sqlite.org/download.html and
converted all the "awk" calls into "nawk" calls.
% diff ORIG_Makefile.in HACKED_Makefile.in
225c225
< | awk '{print $$5,$$6}' >last_change
---
> | nawk '{print $$5,$$6}' >last_change
326c326
< sort -n -b +2 opcodes.h | awk -f $(TOP)/mkopcodec.awk >opcodes.c
---
> sort -n -b +2 opcodes.h | nawk -f $(TOP)/mkopcodec.awk
>opcodes.c
329c329
< cat parse.h $(TOP)/src/vdbe.c | awk -f $(TOP)/mkopcodeh.awk
>opcodes.h
---
> cat parse.h $(TOP)/src/vdbe.c | nawk -f $(TOP)/mkopcodeh.awk
>opcodes.h
A quick "./configure ; make" on an old Solaris 2.6 box and I ended up
with an sqlite3 binary that handled a simple create/insert/select piece
of SQL; not conclusive but a good indicator. I don't have TCL so I
wasn't able to run the test suite.
Using nawk (for Solaris) would remove dependencies on extra tools (like
gawk or perl).
Chris
Re: [sqlite] Problem with memory using Tcl-defined SQL functions
Was this only an issue in SQLite3, or is the problem also in 2.8? On 5/20/05, Miguel Munoz Arancon <[EMAIL PROTECTED]> wrote: > > Thank you very much. That was really fast help! > > Miguel Munoz > > > -Original Message- > From: Dan Kennedy [mailto:[EMAIL PROTECTED] > Sent: viernes, 20 de mayo de 2005 10:56 > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Problem with memory using Tcl-defined SQL > functions > > > > > The problem is that, when I send a query that uses a Tcl-defined SQL > > function to the database, it starts allocating memory that is not freed > > afterwards, until I close the Tcl interpreter. > > Memory leak in Tcl interface code. Fixed in cvs now. > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > __ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, > puede contener informacion clasificada por su emisor como confidencial > en el marco de su Sistema de Gestion de Seguridad de la > Informacion siendo para uso exclusivo del destinatario, quedando > prohibida su divulgacion copia o distribucion a terceros sin la > autorizacion expresa del remitente. Si Vd. ha recibido este mensaje > erroneamente, se ruega lo notifique al remitente y proceda a su borrado. > Gracias por su colaboracion. > __ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are addressed. > Any unauthorised copy, disclosure or distribution of this message > is strictly forbidden. If you have received this transmission in error, > please notify the sender immediately and delete it. > __ > -- Ray Mosley
Re: [sqlite] replaced awk mkopcode scripts now perl based
I have always used awka to convert awk scripts to C code, allowing for a native execuatable to be built, seems to be the most compatible solution. On 5/23/05, Tiago Dionizio <[EMAIL PROTECTED]> wrote: > > On 5/23/05, Helmut Tschemernjak <[EMAIL PROTECTED]> wrote: > > Hello, > > > > due to problems that awk is not identical on some UNIX platforms e.g. > > the Solaris 8 awk cannot handle the mkopcode scripts, I re-wrote it > > using perl. Perl is more compatible between platforms and does not need > > other helper tools to work. As a side effect a build on Windows is much > > easier. > > Try using gawk. Worked for me on a Solaris platform. >
Re: [sqlite] Thanks
On 2005-05-23T17:29:14+0200, Joel Rosdahl wrote: > > Looking forward to a python db compliant client for 3.x hitting the > > Debian archives (apsw is nice, I am sure, but not what I want for > > the project that I am working on). > > PySQLite 2.0.2 now exists in Debian unstable: > > http://packages.debian.org/python-pysqlite2 > > I hope it works for you. :-) Installed and in use since yesterday :-) /Allan signature.asc Description: Digital signature
Re: [sqlite] Thanks
[EMAIL PROTECTED] (Allan Wind) writes: > Looking forward to a python db compliant client for 3.x hitting the > Debian archives (apsw is nice, I am sure, but not what I want for > the project that I am working on). PySQLite 2.0.2 now exists in Debian unstable: http://packages.debian.org/python-pysqlite2 I hope it works for you. :-) Regards, Joel -- Joel Rosdahl <[EMAIL PROTECTED]> Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D 8B22 0064 F9FF BB84 5E97
Re: [sqlite] Slow SQL statements
On Sun, 2005-05-22 at 22:02 -0400, D. Richard Hipp wrote: > On Sun, 2005-05-22 at 19:42 -0400, Al Danial wrote: > > then try queries such as > > > > sqlite baseball.db 'select playerid,sb from batting where sb = (select > > max(sb) from batting where playerid in (select playerid from fielding > > where pos = "3B" and lgid = "NL"));' > > > > which tries to answer the question "which National League third > > baseman had the most stolen bases in a season?" Then again, > > the query could be slow because I didn't formulate it correctly. -- Al > > > > The use of double-quotes instead of single-quotes is confusing > the optimizer somehow. (I'm still looking why this is.) This issue has now been resolved. Using the code in CVS, the query above should be quite fast, even without changing the "NL" to 'NL'. -- D. Richard Hipp <[EMAIL PROTECTED]>
[sqlite] Connection String to SQLite3 Database using SQLiteODBC under VB.
Hello, Can anyone tell me how I can use an existing SQLite3 File-DSN under VB to connect to a SQLite3 database. Regards, Sami
Re: [sqlite] replaced awk mkopcode scripts now perl based
On 5/23/05, Helmut Tschemernjak <[EMAIL PROTECTED]> wrote: > Hello, > > due to problems that awk is not identical on some UNIX platforms e.g. > the Solaris 8 awk cannot handle the mkopcode scripts, I re-wrote it > using perl. Perl is more compatible between platforms and does not need > other helper tools to work. As a side effect a build on Windows is much > easier. Try using gawk. Worked for me on a Solaris platform.
[sqlite] replaced awk mkopcode scripts now perl based
Hello,
due to problems that awk is not identical on some UNIX platforms e.g.
the Solaris 8 awk cannot handle the mkopcode scripts, I re-wrote it
using perl. Perl is more compatible between platforms and does not need
other helper tools to work. As a side effect a build on Windows is much
easier.
The perl scripts are attached. A sample makefile rule is listed below as
a reference.
Helmut Tschemernjak
-
$(O-ARCH)/opcodes.h:$(O-ARCH)/parse.h ../lib/vdbe.c mkopcodeh.pl
perl mkopcodeh.pl $(O-ARCH)/parse.h ../lib/vdbe.c >$@
$(O-ARCH)/opcodes.c:$(O-ARCH)/opcodes.h mkopcodec.pl
perl mkopcodec.pl $< >$@
#!/usr/bin/perl -w
#
# $Id: mkopcodeh.pl,v 1.3 2005/05/23 09:29:53 martin Exp $
#
# Generate the file opcodes.h.
#
# This perl script scans a concatenation of the parse.h output file from the
# parser and the vdbe.c source file in order to generate the opcodes numbers
# for all opcodes.
#
# The lines of the vdbe.c that we are interested in are of the form:
#
# case OP_: /* same as TK_b */
#
# The TK_ comment is optional. If it is present, then the value assigned to
# the OP_ is the same as the TK_ value. If missing, the OP_ value is assigned
# a small integer that is different from every other OP_ value.
#
# We go to the trouble of making some OP_ value the same as TK_ values
# as an optimization. During parsing, things like expression operators
# are coded with TK_ values such as TK_ADD, TK_DIVIDE, and so forth. Later
# during code generation, we need to generate corresponding opcodes like
# OP_Add and OP_Divide. By making TK_ADD==OP_Add and TK_DIVIDE==OP_Divide,
# code to translation from one to the other is avoided. This makes the
# code generator run (infinitesimally) faster and more importantly it makes
# the total library smaller.
#
my %tkhash = ();
my %opvalues = ();
my @oplist = (); # array: name, value, comment, nopush
my $opno = 1;
#
# add TK_* values into %tkhash
# add OP names, value and comment into @oplist
# set OP values to zero or TK value if existing
#
while(<>) {
# Remember the TK_ values from the parse.h file
if (/^#define (TK_\w+)\s+(\d+)/) {
$tkhash{$1} = $2;
}
if (/^case (OP_\w+):/) {
my $name = $1;
my $value = 0;
my $comment = "";
my $nopush = 0;
if (/same as (TK_\w+)/) {
$value = $tkhash{$1};
die "$1 not defined" if not $value;
$opvalues{$value} = 1;
$comment = "/* same as $1 */"
}
$nopush = 1 if (/no-push/);
push(@oplist, [$name, $value, $comment, $nopush]);
}
}
#
# assign opcode values for OPs
# avoid duplicate opcode numbers check for existing TK numbers
#
for my $i (@oplist) {
if ($i->[1] == 0) {
while (defined $opvalues{$opno}) {
$opno++;
}
$i->[1] = $opno++;
}
}
print <<'EOF';
/* Automatically generated. Do not edit */
/* See the mkopcodeh.awk script for details */
EOF
for my $i (@oplist) {
printf "#define %-20s %3d %s\n", $i->[0], $i->[1], $i->[2];
}
# Generate the 10 16-bit bitmasks used by function opcodeUsesStack()
# in vdbeaux.c. See comments in that function for details.
#
@nopush = (0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
for my $i (@oplist) {
if ($i->[3] == 1) {
my $n = $i->[1];
my $j = $n % 16;
my $i = ($n - $j)/16;
$nopush[$i] = $nopush[$i] + (2**$j);
}
}
print "\n";
for(my $i = 0; $i < 10; $i++) {
print "#define NOPUSH_MASK_$i\t", $nopush[$i], "\n";
}
exit 0;
#!/usr/bin/perl -w
#
# $Id: mkopcodec.pl,v 1.2 2005/05/23 08:58:01 martin Exp $
#
# This perl script scans the opcodes.h file (which is itself generated by
# another awk script) and uses the information gleaned to create the
# opcodes.c source file.
#
# Opcodes.c contains strings which are the symbolic names for the various
# opcodes used by the VDBE. These strings are used when disassembling a
# VDBE program during tracing or as a result of the EXPLAIN keyword.
#
my @list = ("?");
while(<>) {
if (/^#define OP_(\w+)\s+(\d+)/) {
$list[$2] = $1;
}
}
print <<'EOF';
/* Automatically generated. Do not edit */
/* See the mkopcodec.awk script for details. */
#if !defined(SQLITE_OMIT_EXPLAIN) || !defined(NDEBUG) || defined(VDBE_PROFILE)
|| defined(SQLITE_DEBUG)
const char *const sqlite3OpcodeNames[] = {
EOF
for $i (0 .. $#list) {
my $name = defined($list[$i]) ? $list[$i] : "NotUsed_$i";
printf "\t/* %3d */ \"%s\"%s\n", $i, $name, ($i == $#list ? '' : ',');
}
print <<'EOF';
};
#endif
EOF
exit 0;
[sqlite] Error transfering data from an SQL Database to SQLite database.
Hello, I am trying to insert data using Microsoft's DTS from an SQLBase SQL Database to SQLite database. On some data transformations I get the error: "Query based Insertion or Updating of Blob values can not be supported". What is the cure? Regards, Sami
Re: [sqlite] Slow SQL statements
On Mon, May 23, 2005 at 08:00:22AM +0200, Ludvig Strigeus wrote: > Why doesn't SQL provide a utility function: maxv > > Then you could (almost) write it like this: > SELECT maxv(sb, playerid) FROM batting WHERE playerid IN >(SELECT player FROM fielding WHERE pos='3B' AND lgid='NL')); > > The semantics of maxv(arg, value) would be that it finds the maximum > of arg, but instead of returning arg, it returns value for the record > with the maximum arg. I always thought of that feature as "look-aside", as in, "Find the max of foo, but don't give me that, instead look aside and return me the corresponding value of bar next to it instead." I've wanted that feature for years, and then not long ago discovered, buried in the Oracle docs, that it exists in Oracle 9i and up! Since you want the playerid with the most sb (stolen bases), in Oracle 9.2.x it would be something like this: select max(playerid) keep (dense_rank last order by sb) as top_stealer from batting I don't know whether the SQL Standard includes any such feature, but it sure is fabulously useful. With a simple queries like these you can make it work without that feature, but when you're in the middle of a complex query that's already a page or two long, without this sort of feature, there's often no sane way to do it at all. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
