[PHP] Found the problem...

2007-07-26 Thread Rob Adams
Found the problem.  The piece of code was outside of a block where $db had 
been created, so it was a non-object the whole time... Easily fixed, but a 
hard error to find when I'm assuming it's my brand new class that's the 
problem.


 -- Rob


""Rob Adams"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I need to test a bunch of code that extensively uses a mysql database (both 
selects and inserts), and I want to do it without actually writing to the 
database..  Instead of commenting out all of the $db->query($insert_query) 
statements and echoing $insert_query, I thought I'd make the following 
object:


class TestDB {
   var $realDB;
   function TestDB(&$o)
   {
   echo $o;
   $this->realDB = &$o;
   echo $this->realDB;
   }
   function query($q)
   {
   echo $q;
   }
   function getOne($q)
   {
   return $this->realDB->getOne($q);
   }
   function getRow($q)
   {
   return $this->realDB->getRow($q);
   }
   function &resetDB()
   {
   return $this->realDB;
   }
}

Then, in my code, I instantiate it like so:

   $tmp = new TestDB($db);
   $db = &$tmp;

But this doesn't work, and I can't figure out why.  When I try to call 
$db->getRow($q) I was getting an error that said that I couldn't call a 
member function of a non-object.  I've changed things around now, and I'm 
just not getting anything.  Any idea why I would get the non-object error? 
Thanks. 


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Found the problem with the libmcrypt.....

2002-10-10 Thread Scott Fletcher

Hello Tom!

Oh yea, I tried the '--with-mcrypt=../mcrypt-2.6.3' option and the PHP's
'./configure' stopped accepting the mcrypt stuffs.  After compiling and
installing it.  PHP got messed up and didn't work too well.  It took me many
times to find the workaround to it but they don't work.  So, I had no
choices but to go back to the default libmcrypt where PHP's '.configure'
accept the libmcrypt.  The problem is with the PHP './configure'.

I noticed on the PHP Manual, it stresses and make some point that libmcrypt
is to be used.  From the look of hte problem, I get the impression that PHP
is moving away from mcrypt and instead, lean toward the libmcrypt.  Well,
PHP developer have hell of a lot of work to do to fix the problem.  There's
nothing I can do about it because when I filed the bug report, the PHP
developer said it's not a bug and that I need to use the php.ini.  Problem
is php.ini didn't fix the problem too well.

So, I have no idea what am I suppose to do about it.  PHP Developer had some
choices and they choose to be slient on this issue,.so who am I to complain
about?  I also found that some other PHP users had some problem with the
'--with-mcrypt' features, so we're 'stuck on the log' and it will be that
way for a while.  I did get to read the PHP course code, mcrypt.h which is
found in the 'php-4.2.3/ext/mcrypt' directory.  Noticed that there's some
problem with the programming there because it listed some features that
should work on the machine but it didn't.  It also explain why phpinfo()
stopped working when trying to display the mcrypt information.  So, it is
obviously an PHP issues with the developer but they said it isn't, so what
am I gonna do about it?  It's their problem, not mine!


"Tom Rogers" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hi,
>
> Thursday, October 10, 2002, 5:35:12 AM, you wrote:
> SF> Found the problem with libmcrypt-2.5.3.  When I configured PHP using
> SF> the --with-mcrypt option and the PHP configuration found libmcrypt
without a
> SF> problem.  After compiling and installing it.
>
> SF> Once I fired up Apache.  I checked the PHP Info using phpinfo()
function.
> SF> The mcrypt showed up but there is no support ciphers (algorithms &
modes).
> SF> So, I had to use the php.ini as the PHP Manual stated on
> SF> 'http://php.net/mcrypt'.  So, I added the two lines as shown in the
clipping
> SF> where libmcrypt was installed in.
>
> SF> --clip--
> SF> mcrypt.algorithms_dir = /usr/local/lib/libmcrypt
> SF> mcrypt.modes_dir = /usr/local/lib/libmcrypt
> SF> --clip--
>
> SF> That is when PHP Info showed the 'mcrypt.algorithms_dir' and
> SF> 'mcrypt.modes_dir' with data in it.  But the problem is I still get
the
> SF> error message when I tried any mcrypt function, the error message
range from
> SF> being unable to initalize the module to whatever the other error
messages
> SF> are.  I assumed there's a bug and filed a bug report to PHP but was
rejected
> SF> because I was told that I had the php.ini incorrect.  That doesn't
make
> SF> sense.  It took me a long time to find some clues to the problem.
What I
> SF> found is that with any files in the "/usr/local/lib/libmcrypt" that
end with
> SF> *.a and *.la, they don't work.  There is no *.c and *.h files in that
> SF> directory.
>
> SF> I discovered that when I set the php.ini to point to the untarred
libmcrypt
> SF> directory where *.c and *.h are found in both
> SF> '/usr/local/src4/libmcrypt-2.5.3/modules/algorithms' and
> SF> '/usr/local/src4/libmcrypt-2.5.3/modules/modes'.  That's when the
mcrypt
> SF> function start working without a problem.  The problem is PHP doesn't
work
> SF> with the *.la and *.a files.  Again, I saw the OpenSSL directory where
*.c
> SF> and *.h files are found in both the algorithms and modes directory of
the
> SF> '/usr/local/ssl/include/openssl/' directory, it work just fine too.
>
> SF> This had lead me to question of whether is there a bug in libmcrypt or
php.
> SF> You be the judge of it.  It would be so nice if this problem can be
> SF> resolved.  I'm not sure if I'm allowed to use the open source code
instead
> SF> of the compiled codes.
>
> You dont normally need to specify anything in php.ini for it to work
> just make sure you have
>
> --with-mcrypt=/usr/src/mcrypt-2.6.x (thats where it was untarred)
>
> when you configure php. I have it working with nothing set in php.ini
>
> --
> regards,
> Tom
>



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Found the problem with the libmcrypt.....

2002-10-09 Thread Tom Rogers

Hi,

Thursday, October 10, 2002, 5:35:12 AM, you wrote:
SF> Found the problem with libmcrypt-2.5.3.  When I configured PHP using
SF> the --with-mcrypt option and the PHP configuration found libmcrypt without a
SF> problem.  After compiling and installing it.

SF> Once I fired up Apache.  I checked the PHP Info using phpinfo() function.
SF> The mcrypt showed up but there is no support ciphers (algorithms & modes).
SF> So, I had to use the php.ini as the PHP Manual stated on
SF> 'http://php.net/mcrypt'.  So, I added the two lines as shown in the clipping
SF> where libmcrypt was installed in.

SF> --clip--
SF> mcrypt.algorithms_dir = /usr/local/lib/libmcrypt
SF> mcrypt.modes_dir = /usr/local/lib/libmcrypt
SF> --clip--

SF> That is when PHP Info showed the 'mcrypt.algorithms_dir' and
SF> 'mcrypt.modes_dir' with data in it.  But the problem is I still get the
SF> error message when I tried any mcrypt function, the error message range from
SF> being unable to initalize the module to whatever the other error messages
SF> are.  I assumed there's a bug and filed a bug report to PHP but was rejected
SF> because I was told that I had the php.ini incorrect.  That doesn't make
SF> sense.  It took me a long time to find some clues to the problem.  What I
SF> found is that with any files in the "/usr/local/lib/libmcrypt" that end with
SF> *.a and *.la, they don't work.  There is no *.c and *.h files in that
SF> directory.

SF> I discovered that when I set the php.ini to point to the untarred libmcrypt
SF> directory where *.c and *.h are found in both
SF> '/usr/local/src4/libmcrypt-2.5.3/modules/algorithms' and
SF> '/usr/local/src4/libmcrypt-2.5.3/modules/modes'.  That's when the mcrypt
SF> function start working without a problem.  The problem is PHP doesn't work
SF> with the *.la and *.a files.  Again, I saw the OpenSSL directory where *.c
SF> and *.h files are found in both the algorithms and modes directory of the
SF> '/usr/local/ssl/include/openssl/' directory, it work just fine too.

SF> This had lead me to question of whether is there a bug in libmcrypt or php.
SF> You be the judge of it.  It would be so nice if this problem can be
SF> resolved.  I'm not sure if I'm allowed to use the open source code instead
SF> of the compiled codes.

You dont normally need to specify anything in php.ini for it to work
just make sure you have

--with-mcrypt=/usr/src/mcrypt-2.6.x (thats where it was untarred)

when you configure php. I have it working with nothing set in php.ini

-- 
regards,
Tom


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP] Found the problem with the libmcrypt.....

2002-10-09 Thread Scott Fletcher

Found the problem with libmcrypt-2.5.3.  When I configured PHP using
the --with-mcrypt option and the PHP configuration found libmcrypt without a
problem.  After compiling and installing it.

Once I fired up Apache.  I checked the PHP Info using phpinfo() function.
The mcrypt showed up but there is no support ciphers (algorithms & modes).
So, I had to use the php.ini as the PHP Manual stated on
'http://php.net/mcrypt'.  So, I added the two lines as shown in the clipping
where libmcrypt was installed in.

--clip--
mcrypt.algorithms_dir = /usr/local/lib/libmcrypt
mcrypt.modes_dir = /usr/local/lib/libmcrypt
--clip--

That is when PHP Info showed the 'mcrypt.algorithms_dir' and
'mcrypt.modes_dir' with data in it.  But the problem is I still get the
error message when I tried any mcrypt function, the error message range from
being unable to initalize the module to whatever the other error messages
are.  I assumed there's a bug and filed a bug report to PHP but was rejected
because I was told that I had the php.ini incorrect.  That doesn't make
sense.  It took me a long time to find some clues to the problem.  What I
found is that with any files in the "/usr/local/lib/libmcrypt" that end with
*.a and *.la, they don't work.  There is no *.c and *.h files in that
directory.

I discovered that when I set the php.ini to point to the untarred libmcrypt
directory where *.c and *.h are found in both
'/usr/local/src4/libmcrypt-2.5.3/modules/algorithms' and
'/usr/local/src4/libmcrypt-2.5.3/modules/modes'.  That's when the mcrypt
function start working without a problem.  The problem is PHP doesn't work
with the *.la and *.a files.  Again, I saw the OpenSSL directory where *.c
and *.h files are found in both the algorithms and modes directory of the
'/usr/local/ssl/include/openssl/' directory, it work just fine too.

This had lead me to question of whether is there a bug in libmcrypt or php.
You be the judge of it.  It would be so nice if this problem can be
resolved.  I'm not sure if I'm allowed to use the open source code instead
of the compiled codes.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php