home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / misc / volume39 / sybperl / part03 / BUGS next >
Encoding:
Text File  |  1993-09-25  |  4.4 KB  |  160 lines
  1.     @(#)BUGS    1.1    9/2/93
  2.     
  3.     The Sybase DB-Library - Perl savestr() conflict
  4.     ------------------------------------------------
  5.  
  6.  
  7.     Ah! The joys of tying different packages together!
  8.  
  9.     Both Perl and DB-Library have a function called savestr(). The
  10.     DB-Library version is used in dbcmd() to add an SQL command to the
  11.     list of commands pointed to by dpproc->dbcmdbuf, and in dbuse() as
  12.     well. Now there are several ways to work around this problem.
  13.  
  14.     1) Compile sybperl.c with -DBROKEN_DBCMD. I've written some code
  15.        that emulates calls to dbcmd() and dbuse(). This works OK on my
  16.        machine/OS/Version of Perl/Version of DBlib, but it relies on
  17.        the internal storing method used by DBlib, and that might
  18.        change in the future.
  19.  
  20.     2) Recompile Perl (specifically, uperl.o in the Perl source
  21.        directory) with some suitable flags (eg -Dsavestr=p_savestr).
  22.        This does not create any compatibility problems, but is a
  23.        lengthy procedure.
  24.  
  25.     3) Do something like:
  26.        cc -c sybperl.c
  27.        ld -r -o sybperl2.o sybperl.o -lsybdb
  28.        [edit sybperl2.o and replace `_savestr' with something like `_savest1']
  29.        cc -o sybperl uperl.o sybperl2.o
  30.        This is not a bad solution, but won't work if you have shared
  31.        library versions of libsybdb.a
  32.  
  33.     4) Edit uperl.o and replace savestr with something else. This is
  34.        the solution I've chosen as the default. It is relatively fast,
  35.        does not rely on any internal knowledge of DB-Library, and does
  36.        not require Perl to be recompiled.
  37.  
  38.     The Makefile gives some information on how to achieve these
  39.     different options.
  40.        
  41.     Thanks to Teemu Torma for providing the initial input on this problem.    
  42.  
  43.  
  44.  
  45.     Sybperl Memory Usage
  46.     --------------------
  47.  
  48.     The general format of a Sybperl script usually looks somewhat like
  49.     this:
  50.  
  51.     #!/usr/local/bin/sybperl
  52.  
  53.     &dbcmd( query text );
  54.     &dbsqlexec;
  55.     &dbresults;
  56.  
  57.     while(@data = &dbnextrow)
  58.     {
  59.        process data
  60.     }
  61.  
  62.  
  63.     If you are using a version of Perl prior to release 4, patchlevel
  64.     35, then this method will result in a rather important memory
  65.     leak. There are two ways around this problem:
  66.  
  67.     1) Upgrade to Perl 4, patchlevel 35 :-)
  68.  
  69.     2) Write a subroutine that calls &dbnextrow and stores the returned
  70.        array to a local variable, and which in turn returns that array to
  71.        the main while() loop, like so:
  72.  
  73.     sub getRow
  74.     {
  75.         local(@data);
  76.  
  77.     @data = &dbnextrow;
  78.  
  79.     @data;
  80.     }
  81.  
  82.     while(@data = &getRow)
  83.     {
  84.        etc.
  85.     }
  86.  
  87.  
  88.     This technique should keep the memory usage of Sybperl to a
  89.     manageable level.
  90.  
  91.  
  92.  
  93.     Perl packages / usersubs bug
  94.     ----------------------------
  95.  
  96.     The following is bug that was uncovered by Jeff Wong:
  97.  
  98. ------ begin excerpt -------
  99.  
  100. a: sybperl script z.pl has some *.pl required scripts.  Let's call
  101.    them x.pl and y.pl for convenience.
  102.  
  103. b: z.pl looks like this (basic structure):
  104.  
  105.    ...
  106.    require "sybperl.pl";
  107.    require "x.pl";
  108.    require "y.pl";
  109.    ...
  110.  
  111. c: x.pl looks like this (basic structure):
  112.  
  113.    ...
  114.    package x;
  115.    ...
  116.    < Sybperl functions with main package dereferencing, e.g. &main'dbcancel(), >
  117.    < &main'dbcancel( $dbproc ), &main'dbnextrow(), ...                        >
  118.    ...
  119.    package main;
  120.    ...
  121.  
  122. d: y.pl looks like x.pl or perhaps like other required packages (in format).
  123.  
  124. e: Bug surfaces in x.pl in that it suddenly cannot locate the sybperl
  125.    functions.
  126.  
  127. My guess is that the bug is caused by the way that usersub functions
  128. are treated by the "require" and "package" operators.  I say this because:
  129.  
  130.    - Usersub functions look very much like perl built-in functions, except that
  131.      usersub functions require an ampersand character in front of their names.
  132.  
  133.    - Built-in functions are global to all packages.
  134.  
  135.    - Perl user-defined functions are local to the package which contains their
  136.      name definition (i.e. where the namespace is).
  137.  
  138.    - When I don't use the x.pl style package construct, the problem disappears.
  139.  
  140. ------ end excerpt -------
  141.  
  142.  
  143.     The way around this bug is to compile Sybperl with the PACKAGE_BUG
  144.     macro defined. When this is done, sybperl.pl creates a number of
  145.     'glue' routines (see lib/sybdb_redefs.pl') which bypass the bug.
  146.  
  147.     It's not the cleanest of solutions, but it works...
  148.  
  149.  
  150.  
  151.     
  152.     Please let me know if you find any other problems with Sybperl so
  153.     that I can look into it.
  154.  
  155.     Thank you.
  156.  
  157.     Michael Peppler    <mpeppler@itf.ch>
  158.  
  159.  
  160.