php-general Digest 2 Jan 2005 14:29:36 -0000 Issue 3204
Topics (messages 205461 through 205471):
Re: phpMyAdmin w/ winXP - IIS w/PHP 4.3 w/mysql 4.1.8
205461 by: Donny Simonton
205462 by: M. Sokolewicz
205463 by: Robert Cummings
205464 by: Donny Simonton
205465 by: John Nichel
Re: handling large files w/readfile
205466 by: Robin Getz
205467 by: Rasmus Lerdorf
205468 by: Sebastian
205469 by: Robin Getz
Date-development stalled?
205470 by: tmp
205471 by: Matthew Weier O'Phinney
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
The problem is not with phpmyadmin, the problem is with php. If you install
4.3 of php it will not work with mysql 4.1.8 or any version mysql 4.1 or
5.0. It will only work if you turn on the short passwords option in 4.1.
I've not tried it on 5.0 lately. You can get it installed but it takes a
little work. This is not a phpmyadmin bug it's all, it's not really a php,
and it's not a mysql bug. I reported it to both phpmyadmin and php.net over
a year ago.
Think this is a problem, wait until you get a $40k 64 bit machine and try to
install php on it via source because you want to use php 4.3 and mysql 4.1
and you find out you can't install anything because 64 bit installs stuff in
different places than php is expecting it. And the php devel team has no
plans on fix it. So you have to hack the config script to get it to work.
Donny
> -----Original Message-----
> From: GH [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 01, 2005 1:15 PM
> To: Willy Sudiarto Raharjo; php-general; [email protected]
> Subject: Re: [PHP] phpMyAdmin w/ winXP - IIS w/PHP 4.3 w/mysql 4.1.8
>
> It would be nice if phpMyAdmin would kindly note that on their website...
>
> Also, when I run a phpInfo()... it says i have the 3.23.49 could this
> be a contributing factor?
>
> On Sat, 1 Jan 2005 15:55:27 +0700, Willy Sudiarto Raharjo
> <[EMAIL PROTECTED]> wrote:
> > > Has anyone had any problems installing phpMyAdmin with the above
> > > configuration? I get an error about the mySql client and
> > > authentication methods? MySQL Error: 1251 : Client does not support
> > > authentication protocol requested by server
> >
> > MySQL 4.1.x is using a different authentication protocols so it may
> break
> > phpmyadmin functionality. Use 4.0.x if you want to use phpmyadmin
> clearly or
> > maybe you should wait for the next release
> >
> > --
> > Willy Sudiarto Raharjo
> > Registered Linux User : 336579
> > Public-key : http://www.informatix.or.id/willy/public-key.txt
> > Blog : http://willysr.blogspot.com
> > OOo Documentation Project (ID) : http://project.informatix.or.id
> >
> >
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/[EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
Donny Simonton wrote:
The problem is not with phpmyadmin, the problem is with php. If you install
4.3 of php it will not work with mysql 4.1.8 or any version mysql 4.1 or
5.0. It will only work if you turn on the short passwords option in 4.1.
I've not tried it on 5.0 lately. You can get it installed but it takes a
little work. This is not a phpmyadmin bug it's all, it's not really a php,
and it's not a mysql bug. I reported it to both phpmyadmin and php.net over
a year ago.
If you use the mysqli extension with it, it works *fine*. But you need
PHP 5 for that...
Think this is a problem, wait until you get a $40k 64 bit machine and try to
install php on it via source because you want to use php 4.3 and mysql 4.1
and you find out you can't install anything because 64 bit installs stuff in
different places than php is expecting it. And the php devel team has no
plans on fix it. So you have to hack the config script to get it to work.
that has already been fixed a couple of weeks ago...
Donny
-----Original Message-----
From: GH [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 01, 2005 1:15 PM
To: Willy Sudiarto Raharjo; php-general; [email protected]
Subject: Re: [PHP] phpMyAdmin w/ winXP - IIS w/PHP 4.3 w/mysql 4.1.8
It would be nice if phpMyAdmin would kindly note that on their website...
Also, when I run a phpInfo()... it says i have the 3.23.49 could this
be a contributing factor?
On Sat, 1 Jan 2005 15:55:27 +0700, Willy Sudiarto Raharjo
<[EMAIL PROTECTED]> wrote:
Has anyone had any problems installing phpMyAdmin with the above
configuration? I get an error about the mySql client and
authentication methods? MySQL Error: 1251 : Client does not support
authentication protocol requested by server
MySQL 4.1.x is using a different authentication protocols so it may
break
phpmyadmin functionality. Use 4.0.x if you want to use phpmyadmin
clearly or
maybe you should wait for the next release
--
Willy Sudiarto Raharjo
Registered Linux User : 336579
Public-key : http://www.informatix.or.id/willy/public-key.txt
Blog : http://willysr.blogspot.com
OOo Documentation Project (ID) : http://project.informatix.or.id
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
On Sat, 2005-01-01 at 16:48, Donny Simonton wrote:
> Think this is a problem, wait until you get a $40k 64 bit machine and try to
> install php on it via source because you want to use php 4.3 and mysql 4.1
> and you find out you can't install anything because 64 bit installs stuff in
> different places than php is expecting it. And the php devel team has no
> plans on fix it. So you have to hack the config script to get it to work.
Try paying someone on the PHP dev team $40k to fix it. You might find it
fixed the same day. You are, after all, using free and open source
software, the onus is on you to make things work the way you want when
it deviates from the default.
It's funny when someone complains about free software when they have
$40k hardware. Makes me want to cry... NOT!
As a side comment... did you happen to kick back a patch to the PHP team
for the changes you made to the config script?
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Yes, I did send in a patch just like the 3 or 4 other people who had the
same problem. I'm not complaining about php, I was just commenting about
the person complaining that it was a problem with phpmyadmin. I complained
about the problem over a year ago, when I first installed mysql 4.1.0, but
the problem was definitely not with phpmyadmin. It was a combination of php
not working well with mysql 4.1.0.
Why would have pay somebody 40k a year, I can do it myself or anyone of my
other 20 programmers. When php says it's not a bug, then obviously they
don't see it as being a problem. Since all 32 bit servers will be phased
out by mid-May because of the opteron and the new intel procs, I'll just sit
back and watch the bug submissions come in next year as everybody gets their
new hardware in. I won't complain, I know how to fix it.
Donny
> -----Original Message-----
> From: Robert Cummings [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 01, 2005 6:55 PM
> To: Donny Simonton
> Cc: 'GH'; 'Willy Sudiarto Raharjo'; 'php-general'; [email protected]
> Subject: RE: [PHP] phpMyAdmin w/ winXP - IIS w/PHP 4.3 w/mysql 4.1.8
>
> On Sat, 2005-01-01 at 16:48, Donny Simonton wrote:
>
> > Think this is a problem, wait until you get a $40k 64 bit machine and
> try to
> > install php on it via source because you want to use php 4.3 and mysql
> 4.1
> > and you find out you can't install anything because 64 bit installs
> stuff in
> > different places than php is expecting it. And the php devel team has
> no
> > plans on fix it. So you have to hack the config script to get it to
> work.
>
> Try paying someone on the PHP dev team $40k to fix it. You might find it
> fixed the same day. You are, after all, using free and open source
> software, the onus is on you to make things work the way you want when
> it deviates from the default.
>
> It's funny when someone complains about free software when they have
> $40k hardware. Makes me want to cry... NOT!
>
> As a side comment... did you happen to kick back a patch to the PHP team
> for the changes you made to the config script?
>
> Cheers,
> Rob.
> --
> .------------------------------------------------------------.
> | InterJinn Application Framework - http://www.interjinn.com |
> :------------------------------------------------------------:
> | An application and templating framework for PHP. Boasting |
> | a powerful, scalable system for accessing system services |
> | such as forms, properties, sessions, and caches. InterJinn |
> | also provides an extremely flexible architecture for |
> | creating re-usable components quickly and easily. |
> `------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Donny Simonton wrote:
Yes, I did send in a patch just like the 3 or 4 other people who had the
same problem. I'm not complaining about php, I was just commenting about
the person complaining that it was a problem with phpmyadmin. I complained
about the problem over a year ago, when I first installed mysql 4.1.0, but
the problem was definitely not with phpmyadmin. It was a combination of php
not working well with mysql 4.1.0.
How is this a 'problem' with PHP? It was MySQL who changed how
passwords were handled by default. However, it's not even a MySQL
problem...it's not a problem at all. MySQL added in backwards
capabiilty for passwords.
Why would have pay somebody 40k a year, I can do it myself or anyone of my
other 20 programmers. When php says it's not a bug, then obviously they
don't see it as being a problem.
It's not a problem. There is a workaround for it. It's that simple.
Why should the PHP people rewrite the MySQL functions when a) the amount
of people using php v4.x and MySQL >= 4.1.x are small, and b) it will
work if you take the time to read.
Since all 32 bit servers will be phased
out by mid-May because of the opteron and the new intel procs, I'll just sit
back and watch the bug submissions come in next year as everybody gets their
new hardware in.
All phased out by mid-May??? All where? Maybe at Intercosmos (even
though I doubt that), but 32 bit servers will still exist, more that
likely as the majority, long after May. Most companies are not going to
shell out the duckies to 'upgrade' to 64-bit when a) alot of the
software hasn't been battle tested, b) there are no big advantages to it
in the LAMP world, and c) there is no big outcry from the customer
base to make the switch.
I won't complain, I know how to fix it.
And I'll refrain from getting personal.
--
By-Tor.com
...it's all about the Rush
http://www.by-tor.com
--- End Message ---
--- Begin Message ---
Robin Getz wrote:
My next experiment is:
============================
$buff = "0";
while (!feof($fp)) {
$buff = fread($fp, 4096);
print $buff;
}
unset($buff);
fclose ($fp);
============================
Nope that doesn't work either - came back, and saw apache processes that
were +450Meg. Changed it back to apache redirection for now.
If anyone has __any__ suggestions, I am more than happy to try. I would
like to get this figured out.
Thanks
-Robin
--- End Message ---
--- Begin Message ---
Robin Getz wrote:
Robin Getz wrote:
My next experiment is:
============================
$buff = "0";
while (!feof($fp)) {
$buff = fread($fp, 4096);
print $buff;
}
unset($buff);
fclose ($fp);
============================
Nope that doesn't work either - came back, and saw apache processes that
were +450Meg. Changed it back to apache redirection for now.
If anyone has __any__ suggestions, I am more than happy to try. I would
like to get this figured out.
Well, the above code does not use more than 4K of ram plus a bit of
overhead. So if something is causing your processes to grow to 450M you
need to look elsewhere because this code is definitely not the cause.
-Rasmus
--- End Message ---
--- Begin Message ---
well, i really can't confirm what your seeing. but that is why i orginally
started this topic. i will do some tests..
are you setting headers before output? i just ran into another problem..
when downloading a .tar file it just returns an empty .tar file.. seems to
work fine with .exe, .zip, tar.gz, but not .tar
any ideas?
this is what im using:
header('Content-type: application/octet-stream');
header('Expires: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Content-transfer-encoding: binary');
header('Content-Disposition: attachment; filename="' . $file['type'] . '"');
header('Content-Length: ' . filesize($file['path'] . $file['type']));
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
----- Original Message -----
From: "Robin Getz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, January 01, 2005 9:38 PM
Subject: RE: [PHP] handling large files w/readfile
> Robin Getz wrote:
> >My next experiment is:
> >============================
> >$buff = "0";
> >while (!feof($fp)) {
> > $buff = fread($fp, 4096);
> > print $buff;
> >}
> >unset($buff);
> >fclose ($fp);
> >============================
>
> Nope that doesn't work either - came back, and saw apache processes that
> were +450Meg. Changed it back to apache redirection for now.
>
> If anyone has __any__ suggestions, I am more than happy to try. I would
> like to get this figured out.
>
> Thanks
> -Robin
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--- End Message ---
--- Begin Message ---
Rasmus Lerdorf wrote:
>> ============================
>> $buff = "0";
>> while (!feof($fp)) {
>> $buff = fread($fp, 4096);
>> print $buff;
>> }
>> unset($buff);
>> fclose ($fp);
>> ============================
Well, the above code does not use more than 4K of ram plus a bit of
overhead. So if something is causing your processes to grow to 450M you
need to look elsewhere because this code is definitely not the cause.
Well, the test case is:
1) above with big files = big apache processes - machine crashes
2) download big files with:
Header("Location: ".$html_pointer_to_file);
= small apache processes - works great
So, I don't know if it can be anything else but that - so I am open to
suggestions, or tests that anyone wants me to run.
-Robin
--- End Message ---
--- Begin Message ---
It seems that development of Pear::Date has stalled. The package does has
some major bugs when used with php5 - both in the main "Date" class and in
"Date_Span". There has been filled a bug report as early as september
2004, but no fix has been made yet and no response from a developer, other
than setting the "verified"-flag, has been made.
Only solution has been to extend the classes and reimplement fixed
versions of the methods. This is clearly not an optimal way of doing it.
However, the bugs are easy to fix and I would happily do it - if just I
could get in touch with the developers... (It's a matter of manually
cloning function arguments of type "object").
What to do?
Thanks
--- End Message ---
--- Begin Message ---
* Tmp <[EMAIL PROTECTED]>:
> It seems that development of Pear::Date has stalled. The package does has
> some major bugs when used with php5 - both in the main "Date" class and in
> "Date_Span". There has been filled a bug report as early as september
> 2004, but no fix has been made yet and no response from a developer, other
> than setting the "verified"-flag, has been made.
>
> Only solution has been to extend the classes and reimplement fixed
> versions of the methods. This is clearly not an optimal way of doing it.
> However, the bugs are easy to fix and I would happily do it - if just I
> could get in touch with the developers... (It's a matter of manually
> cloning function arguments of type "object").
>
> What to do?
Subscribe to the pear-dev list, find out if any work is being done on
it, and, if not, volunteer to take over maintenance.
--
Matthew Weier O'Phinney | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist | http://www.garden.org
National Gardening Association | http://www.kidsgardening.com
802-863-5251 x156 | http://nationalgardenmonth.org
--- End Message ---
