[PHP-DEV] Karma request for phpweb

[Joao Prado Maia]

Hello,

I just found a rather bad typo on the 'links.php' page and while trying to
fix it myself it showed up that I don't have enough karma. Can someone
pump my karma up a little bit ?

The username is 'jpm'.

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Contribua com o projeto de tradução do manual online do PHP
http://phpbrasil.com/traducao.php
--


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6

[Joao Prado Maia]

On Tue, 3 Apr 2001, Sascha Schumann wrote:

> > Yes, that's true. I did ask (couple of times) before
> > I committed that patch. And yes, now both & and ; are
> > considered as arg separators.
> >
> > And I'd like to think that it's a feature than bug. ;)
>
> That would be true, if PHP would be some kind of reference
> implementation.  But we don't exist to force standards down
> our users' throats.
>
> It should be optional and default to off.
>

Exactly what I was going to say (well, kind of). I would rather have it as
an optional feature that can be turned off or not on php.ini.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Contribua com o projeto de tradução do manual online do PHP
http://phpbrasil.com/traducao.php
--



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Latest CVS on Linux

[Joao Prado Maia]

On Sat, 12 May 2001, Sebastian Bergmann wrote:

> Sascha Schumann wrote:
> > >   I was refering to the 'unary operator expected' errors.
> >
> > ..which was an effect of your broken installation, as
> > ltmain.sh and ltconfig/libtool.m4 were incompatible, and
> > hence produced spurious errors.
>
>   Oh, and I thought the only effect of my busted libtool-1.4
> installation was the 'ltconfig not found' issue.
>

I have a similar problem with the latest CVS (few minutes ago). When I run
the configure script, it spills out this following message:

Configuring libtool
checking build system type... i686-pc-linux-gnu
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
./ltconfig: ./ltconfig: No such file or directory
configure: error: libtool configure failed

No idea whats wrong. If anyone needs more information on my configuration
or whatever, please let me know.

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11818 Updated: Using the PDF functions after July1st triggers an internal PDFlib error

[Joao Prado Maia]

That is not true at all, if you bundle the PDF library with PHP releases
on the Windows binary it starts being your problem too. I just went to
pdflib.com and it seems to me that binary packages of pdflib for Windows
have a demo / time limit. May I suggest to whoever packaged the Windows
binary version of PHP to compile the source code of pdflib on Windows, so
to create a limit free version of PDFlib ?

Joao


On 1 Jul 2001 [EMAIL PROTECTED] wrote:

> This is not a bug in PHP, but some thing in the PDF library it self. Complain to the 
>pdflib.com guys about this.
>
> Derick
>
> Previous Comments:
> ---
>
> [2001-07-01 03:53:45] [EMAIL PROTECTED]
>
> Ok, I know this sounds unbelievable but its exactly what is happening here. I'm 
>running a script that calls this class which creates a PDF document on the fly, and 
>everything was working perfectly.
>
> Working late at night surprised me when an error that I never saw before appeared on 
>my browser:
>
> Fatal error: PDFlib error: Beta expired - retrieve new version from www.pdflib.com 
>in c:wwwhtdocsboleto.pessoal.orgdocsincludeboletosclass.pdf.php on line 52
>
> I changed my internal Windows clock to May 1st and the script started working again. 
>Is this a known problem ? It seems kinda ridiculous to have a time limit to use a PHP 
>extension.
>
> That line 52 is the line that contains '$pdf = pdf_new();'. I'm not sure if this 
>happens on every operating system, but it is still a serious problem.
>
> Joao Prado Maia
>
> ---
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=11818&edit=2
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11818 Updated: Using the PDF functions after July1st triggers an internal PDFlib error

[Joao Prado Maia]

On Mon, 2 Jul 2001, Joey Smith wrote:

> Surely you are kidding.
>
> I cannot see in any of our packages where we bundle the PDF library with
> our release. If we are, we should probably remove it.
>
> In either case, there is no way we can compile an unencumbered version
> of PDFLib. That would be illegal. PDFLib is not free, in the
> "gratis" sense.
>
> This is like making the fact that Win32 does not come with a free C
> compiler PHP's problem, based on the fact that you need one to compile
> your own binary. It's absolutely ridiculous.
>

Ok, I must be missing something really bad here then. What is this
php_pdf.dll doing on my /extensions/ sub-directory ? Someone must have
compiled that, huh.

I can see from Pdflib.com that you can get the source code for all major
platforms, including Windows (which is what I'm talking about here after
all). Here is the URL for you :
http://www.pdflib.com/pdflib/download/pdflib-4.0.1.zip

I downloaded the latest version of the pre-compiled PDFlib which comes
with the compiled php_pdf.dll file, so it was just a matter of dropping
the file on the /extensions sub-directory, but now I get a huge water mark
with the 'www.pdflib.com' string in it.

Am I still missing something here that you guys could compile the PDF
extension from the Windows source code of PDFlib when making the Windows
binary release of PHP ? Why is this illegal anyway ? I even took my time
to open the license file of PDFlib source and it clearly stated on the
"Alladin Free Public License" that you can re-distribute PDFlib
non-commercially, which is what PHP is doing here.

Why would compiling from source and distributing a version of PDFlib
without that ridiculous water mark be such an issue ?

I might be missing something really bad here, so I apologize if there is
something really obvious that I'm overlooking.

Joao


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11818 Updated: Using the PDF functions after July1st triggers an internal PDFlib error

[Joao Prado Maia]

On Fri, 6 Jul 2001, Joey Smith wrote:

> There are 2 parts that are required to make PDF's using pdflib. There is
> the pdflib code, and the PHP code that makes calls to the pdflib
> code. We can ship our own code, but not pdflib's.
>

And that is what I'm talking about here. Changing only the PHP extension
so this silly watermark string is not seen on the PDF's generated by PHP
scripts. Am I correct that this is only a matter of compiling the PHP
extension from source and creating a php_pdf.dll ?

Of course, I'm supposing in all this that the code to generate the
watermark is inside the PHP extension. Anyway, can this be done for future
releases ?

Joao


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] register_tick_function problems..

[Joao Prado Maia]

Can someone take a look into this bug id and see if anything can be done
to fix this problem ? The current report is tagged as 'analyzed' but maybe
the developers overlooked the problem, as it is kind of old (ok, not too
much).

http://www.php.net/bugs.php?id=11536

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11536 Updated: register_tick_function weirdness

[Joao Prado Maia]

Fine :)

But please someone take a look into this, as I can also reproduce this
problem on Linux / Apache / PHP 4.0.5 and it might be an easy fix
(clueless though). Sinec we are talking about this, did anyone else ever
tried using ticks on Apache under Windows 2000 ?

I get a rather nasty "Program Error" or whatever the little message is
when I run the same script in there. The sample script that I'm trying to
use goes below:

";
}

// Set up a tick handler
register_tick_function("metasearch");

declare(ticks=1) {
1;1;1;1;1;
}
?>

When this error on Windows occurs, nothing shows up on the error_log, so
I still don't know what is going on. Any suggestions are very welcome.

Cheers,
Joao


On 10 Jul 2001 [EMAIL PROTECTED] wrote:

> ID: 11536
> Updated by: derick
> Reported By: [EMAIL PROTECTED]
> Old Status: Analyzed
> Status: Open
> Bug Type: Scripting Engine problem
> Operating System: linux + apache
> PHP Version: 4.0.5 - 4.0.7
> New Comment:
>
> It's not anaylysed, I could only reproduce it.
>
> Derick
>
> Previous Comments:
> 
>
> [2001-06-18 08:26:20] [EMAIL PROTECTED]
>
> I can reproduce this with 4.0.6RC3 and 4.0.7dev. But the repeating is not after 
>every reload.
> My guess is that it is per apache child.
>
> Derick
>
> 
>
> [2001-06-18 08:22:29] [EMAIL PROTECTED]
>
> Hiya,
>
> Try to run the example on 
>http://www.php.net/manual/en/control-structures.declare.php a couple of times
>
> output 1st time:
> [tick i=1] [tick i=2]
>
> output 2nd time:
> [tick i=1] [tick i=2] [tick i=3] [tick i=4]
>
> output 3rd time:
> [tick i=1] [tick i=2] [tick i=3] [tick i=4] [tick i=5] [tick i=6]
>
> You should get the point by now I think :)
>
> Greetz,
>
> Wico
>
> 
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=11536&edit=1
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Is there any value in having functions defined whichdo nothing.

[Joao Prado Maia]

On Tue, 10 Jul 2001, Jeremy Bettis wrote:

> Why is the habit of PHP modules to define functions that might or might not
> work depending on library dependancies.
>
> For example, ImageCopyResampled gives this error if libgd < 2.0:
> "ImageCopyResampled required libgd 2.0"
>
> But that makes this code useless:
>
> if (function_exists('ImageCopyResampled')) {
> // doit the good way
> ImageCopyResampled(.);
> } else {
> ImageCopyResized(.);
> }
>
> My point was to have the php script work regardless of what version of php
> was installed, but even if the function exists, it might not work.  Wouldn't
> it have been better if the function just didn't exist at all?

Thats a very good question. I stumbled across a similar problem a few
weeks ago - I was trying to check for TTF support on the GD module, but
using function_exists() on ImageTTFBBOx for instance showed that the
function was there, but you couldn't use because it was outputting a
warning about the lack of TTF support.

Since this problem is not going away anytime soon, I suggest you check for
the return value of those functions, and then use the alternate one if
needed. Thats what I'm doing right now and it seems to be the most
compatible way as of now.

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS account email address incorrect

[Joao Prado Maia]

I just noticed that the email address that is stored on your databases (or
wherever you keep the information on) is incorrect - [EMAIL PROTECTED]

Can someone with the proper permission please change it to
'[EMAIL PROTECTED]' ?

Thanks,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] md5sum() patch

[Joao Prado Maia]

On Thu, 15 Nov 2001, Markus Fischer wrote:

> $m45sum = md5_file($f);
>
 
I guess you probably meant this:

$md5sum = md5_file('filename');

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] first bug report for 4.1.0 (was [PHP-DEV] Bug #14329:Mail() does not work)

[Joao Prado Maia]

On Mon, 3 Dec 2001, Hartmut Holzgraefe wrote:

> [EMAIL PROTECTED] wrote:
>
> > From: [EMAIL PROTECTED]
> > Operating system: WindowsCE
> > PHP version:  4.1.0
> > PHP Bug Type: *Mail Related
> > Bug description:  Mail() does not work
>
> so here we are :(
>
> i'd still prefere to have the upcomming release called 4.1.1
>

So do I. I get chills when I think on the support / bug emails telling me
that my project doesn't work on 4.1.0. I really don't want to keep
emailing them back asking if 4.1.0 was the  one or the new one?

Just imagine having to explain the confusion with the 4.1.0 release to
everyone... oh my ;)

My .2c, for whatever it's worth.
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re[5]: [PHP-DEV] [NEW EXTENSTION]: templates

[Joao Prado Maia]

On Wed, 5 Dec 2001, Daniel Lorch wrote:

> It's nice having an out-of-the-box solution - everything just works
> fine, just load the module (i.e. uncomment # in php.ini). Nevertheless,
> who actually decides how a module's interface is designed? I know,
> there are some guidelines, but this still ressembles too much to
> anarchy in my eyes. What belongs into PEAR and what has to be done as
> module? IMHO, a programming language gives the user essential basic
> abilities, such as creating sockets, file system access, of course
> providing a syntax, memory mangement etc.. and then it's up to the
> PHP developer to create additional modules. This will provide better
> transparency to the end-developer as he will be able to look at the
> PEAR-sourcecodes and actually /understand/ what is being done. Why
> does every PHP developer has to know C only to understand how such
> modules work?
>
> Too many modules were developed lately. Why not add a daniel-module
> which only serves my needs, but goes into the main CVS tree?
>
> Correct me, if I'm wrong. Your opinions please :)
>

Sure, create your little daniel-module. If it isn't very important it will
probably go into PEAR / PECL. What's the big deal here ?

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [NEW EXTENSTION]: templates

[Joao Prado Maia]

On Wed, 5 Dec 2001, Andrei Zmievski wrote:

> On Wed, 05 Dec 2001, Alexander Wagner wrote:
> > You have a point here, but you're not necessarily right.
> >
> > Smarty templates are more complex than IT[X]/PHPlib-style templates,
> > but still easier than XSL, and not all designers are that dumb.
> >
> > I think IT[X]-style templates are more important, but I wouldn't object
> > to having both.
>
> I once again will say the following, and while I add IMHO here, I have
> been working on Web apps over 5 years now, with and without designers,
> HTML programmers, and other various team members:
>
> Smarty is as easy to use as you want to make it. No one forces you and
> your pixel pushers to use presentation logic. Stick to just variable
> displays and be happy.
>

Exactly. Thats why it is called a feature. It's optional, so just don't
use it if it is too difficult to explain to your designers.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] multiple inheritance ext

[Joao Prado Maia]

On Fri, 7 Dec 2001, Matthew J Gray wrote:

> bind() takes the name of a class and the name of a function and
> "binds" the function to the given class.  This is useful to us when
> the interface class of a library is a subclass of another class in the
> library.
>
> bind() doesn't quite work properly, but multi_extend does and I plan
> on adding it to the machines in our test environment.  Long term,
> however, it would be nice if this sort of multiple inheritance
> functionality was part of php so it could be better maintained and
> developed in more competent hands.
>

Be careful with the function names, as bind() is already being used by the
sockets extension. See:

http://www.php.net/manual/en/function.bind.php

I believe the new sockets extension names it socket_bind(), but anyway..


> I am wondering:
> 1) Are we alone in wanting this sort of functionality?  Would anybody
> else find this useful?
> 2) Could it be better implemented in php using keywords(extends taking
> a list of parent classes) and operators(::) ?
> 3) Why overloaded classes?  It doesn't seem very straight forward from
> a usuability standpoint(maybe I am biased since I has such bad
> experience getting __sleep and __awake to work and would rather never
> use a __* method again).
>

No, you are not alone wanting this sort of functionality. Other people
probably want this as well, but the real problem now is that Zend 2 is
being written and an extension doing this now would be kind of awkward.

I mean, if people start using this new extension with PHP4 and then later
on have to use PHP5 which already has multiple inheritance 'built-in', the
syntax would be different. You probably can imagine the backwards
compatibility problems this could cause.

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP] PHP & XML

[Joao Prado Maia]

On Fri, 7 Dec 2001, benjamin yates wrote:

> > > a way to create the same as a #define macro...  man would that be nice.
> >
> >define()
>
> "
>   define( 'MIN(a,b)', ((a)<(b)?(a):(b)) ); ?  i don't think so... if you
> know a way to do it then you'll be my favorite person for the week :)
> "
>
>   is what i was about to post... then i decided to go try it and omg!
>

WTH, does this really work ? Wow, I would have never guessed it.



Very cool :)

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP] PHP & XML

[Joao Prado Maia]

On Fri, 7 Dec 2001, Rasmus Lerdorf wrote:

> Guys, relax.  No, this does not work.  The only reason your example works
> is because min() is a built-in PHP function already.
>

Hmm, damnit. I hate looking like a fool ;)

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14495: PHP Windows Binary packaged with oldversion of GD

[Joao Prado Maia]

Yes, thats indeed true. I understand the mess with GD 2.0.1 having a lot
of bugs and everything, but if you are supporting GD2 based functions on
4.0.6 and then take it away on the Windows version of 4.1.0, people are
definetely have problems.

I'm one of those unlucky bastards that have to mantain an open-source
project that needs the GD extension to generate images, so I personally
hate when things like this happen. Too much of my time was already wasted
trying to work around problems and inconsistencies between versions of PHP
and its GD extension, and what I got as a reply was basically "tough
luck".

Very annoying indeed. I guess I will have to waste several more hours
trying to build a portable solution across versions one more time, but
this time with the new variable in place - PHP 4.1 on Windows being
different than PHP 4.0.6 on Windows, which was already different than PHP
4.0.5 on Windows.

Joao


On 13 Dec 2001 [EMAIL PROTECTED] wrote:

> From: [EMAIL PROTECTED]
> Operating system: Windows
> PHP version:  4.1.0
> PHP Bug Type: GD related
> Bug description:  PHP Windows Binary packaged with old version of GD
>
> The Windows binary ZIP for PHP 4.0.6 shipped with the GD extension built
> against at least GD 2.0.  For whatever reason the 4.1.0 binary contains the
> extension built against GD 1.6.2.  This means a whole lot of image
> functions that were available to Windows servers in 4.0.6 are suddenly
> gone.
>
> Unfortunately I don't have a Windows build environment to put together my
> own copy of the extension.
> --
> Edit bug report at: http://bugs.php.net/?id=14495&edit=1
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14495: PHP Windows Binary packaged with oldversion of GD

[Joao Prado Maia]

On Fri, 14 Dec 2001, Sander Roobol wrote:

> > There is a bug report: http://bugs.php.net/bug.php?id=11813&edit=1
> > in which I suggested the person whoever builds the binary releases
> > to build two versions of the GD extension..this didn't happen
> > for some reason.
>
> IMO, the simplest solution to this problem is to provide php_gd2.dll in a
> separate package on www.php.net/downloads.php, with a warning saying it's
> still experimental. You'll avoid the newbie users and with them a lot of
> bogus-bugreports, but you'll satisfy the advanced users who require special
> GD2-functions.
>

Not so. As I tried to explain, my application needs GD to generate
graphics and I already had some code in there to work around the quirks of
PHP4.0.5 and PHP4.0.6 that had different GD libraries. Most of the users
of my application don't want to and a lot of times cannot install another
module / extension on the webserver.

Anyway, my point here is to try to get more people to read this thread and
whenever the time for 4.2 comes, we have developers thinking more about
the compatibility issues of the Windows version of PHP. It's kind of hard
to write portable stuff like this, ya know :)

Oh well.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] XMLRPC Bug

[Joao Prado Maia]

On Mon, 17 Dec 2001, Colin Viebrock wrote:

> Is anyone reading this list?  I haven't heard a thing since last week when I
> posted what I think might be a serious bug in the extension (see also
> http://bugs.php.net/?id=14521).
>

I guess people just didn't try the extension yet. I'm also interested in
working with it, but only in a couple of weeks.


> I'm hoping the developers could look into this soon ... I'm eager to start
> using this extension, but want to be fairly sure it works first. :)
>

Yeah, some extra eyes on the extension would definetely help. :)

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Inconsistencies with ImageTTFText() across versions of PHP

[Joao Prado Maia]

Hi everyone,

This problem probably doesn't have any fix (or I think I doesn't anyway),
but maybe this email will be useful for other developers that need to
create portable scripts across a wide range of PHP and GD versions.

What I have found, and Rasmus helped me on that a few times over IRC, is
that GD 1.6.2 / 1.8.4 used a different version of the freetype library
(1.X) and the newer version of GD 2.0.1 actually needs freetype 2.X to
work (please correct me if I'm wrong).

Anyway, as I have said before here PHP 4.1.0 comes with a different
version of the GD DLL on the windows binary than it used to on 4.0.6. I'm
positive that 4.1's GD version is 1.6.2 and 4.0.6's was probably 2.0.1.
I'm not actually sure about 4.0.5, but I believe it was either 1.6.2 or
1.8.4.

In any case, what all of this meant to the graphing functions is that
there is different behavior on different versions of PHP. The windows
version of PHP might use GD 1.6.2 or even GD 2.0.1 (if compiled manually,
which is unprobable but possible).

ImageTTFText() is one of the functions that had its behavior changed, as
passing '10' to it as the font size parameter meant different things on
different versions of the GD library, which I believe is a consequence of
the unlying freetype requirement.

Anyway, all of this is just to warn everyone to be careful about this, as
your graphics will look in a different way than what you expected in some
cases.

Any comments or ideas would be helpful. If anyone knows the inner workings
of the freetype library and its standard for font sizes (ie metrics and
such), that would be great.

Just to give more details on what I needed to do - I actually ended up
parsing the output of phpinfo() with the output buffering functions to be
able to tell reliably which version of GD PHP is really using. This way I
could pass different font sizes to ImageTTFText(). Not very pretty, eh ?
;)

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] CVS Account Request: aditus

[Joao Prado Maia]

On 17 Dec 2001, Johan Persson wrote:

> By suggestion from Rasmus L.
> To house and develop JpGraph. See www.aditus.nu/jpgraph for a detailed description
> of this project.
>

Woohoo!

Maybe putting Jpgraph on PEAR ? That would kick ass :)

Great work on the library by the way, I use it all the time on my
applications.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] CVS Account Request: aditus

[Joao Prado Maia]

On Mon, 17 Dec 2001, Pierre-Alain Joye wrote:

> btw, I see a promised imlib extension for php (http://mmcc.cx/php_imlib/) and seems 
>to be freezed since january. Anyone knows the authors ? I believe it should be a good 
>alternative to gd.
>

Sure, Matt is the author and he is always on #php on irc.openprojects.net
under the handle of Cardinal. You can talk with him in there.

However, Imlib will take a while (if ever) to be a replacement for GD for
reasons that Matt himself told me, as the requirement of some silly
threading library and Xlib (X11 support). He told me that a patch for
losing the requirement of Xlib was sent to rasterman but he never added it
to the distribution (correct me if I'm wrong).

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14583 Updated: GD 1.6.x in PHP4.1.0

[Joao Prado Maia]

I suggest you to try using PNG format for that functionality. Beware that
ImageTTFText() renders 'blocky' text on JPEGs, but seems to work better in
PNGs.

Oh well.

Joao


On 18 Dec 2001 [EMAIL PROTECTED] wrote:

> ID: 14583
> User updated by: [EMAIL PROTECTED]
> Reported By: [EMAIL PROTECTED]
> Status: Bogus
> Bug Type: GD related
> Operating System: Windows
> PHP Version: 4.1.0
> New Comment:
>
> ROLF :D
>
> Well, my Thumbnail-Maker is making ugly JPEGs now,.. some of them looks very funny.
>
> Previous Comments:
> 
>
> [2001-12-18 11:32:35] [EMAIL PROTECTED]
>
> Alright, it's not like anyone cares about the portability of GD based applications, 
>huh ? 
>
> Status -> bogus.
>
> 
>
> [2001-12-18 11:31:54] [EMAIL PROTECTED]
>
> quick respons eh,. :D
>
> I am already signed up at php4win.de
>
> I have tryed using the lastest GD from php4win,... with no success,. :´(
>
> 
>
> [2001-12-18 11:30:01] [EMAIL PROTECTED]
>
> just cancel this,... I found it reported as a Bogus,..
>  - http://bugs.php.net/bug.php?id=14461
>
> 
>
> [2001-12-18 11:29:55] [EMAIL PROTECTED]
>
> That is a good question, and one that I have been ranting about on the php-dev list 
>for a while now.
>
> You can either try to compile PHP with GD 2.0.1 yourself or email Daniel from 
>php4win.de and see if he would provide a php_gd.dll for 2.0.1.
>
> -- Joao
>
> p.s.: I would guess this would be an 'analyzed' entry ?
>
> 
>
> [2001-12-18 11:25:24] [EMAIL PROTECTED]
>
> Why did you backstep to GD1.6.x in PHP4.1.0 ?
>  - PHP4.0.6 came with GD2.0.x and TrueColor,...
>
> 
>
>
>
> Edit this bug report at http://bugs.php.net/?id=14583&edit=1
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14583 Updated: GD 1.6.x in PHP4.1.0

[Joao Prado Maia]

Well, to be fair they are only worthless on the Windows binary version
that comes with GD 1.6.2. You can always try to compile PHP on your own
though.

Don't get me wrong, this is still a mess :)

Joao


On 18 Dec 2001 [EMAIL PROTECTED] wrote:

> ID: 14583
> User updated by: [EMAIL PROTECTED]
> Reported By: [EMAIL PROTECTED]
> Status: Bogus
> Bug Type: GD related
> Operating System: Windows
> PHP Version: 4.1.0
> New Comment:
>
> I meant: ROFL :D
> 
>
> &0149; Added support for GD2 image type for ImageCreateFromString() (Jani)
> &0149; Added ImageCreateFromGD(), ImageCreateFromGD2(), ImageCreateFromGD2part(), 
>ImageGD() and ImageGD2() functions (Jani)
>
> these are worthless without GD2
>
> Previous Comments:
> 
>
> [2001-12-18 11:37:09] [EMAIL PROTECTED]
>
> ROLF :D
>
> Well, my Thumbnail-Maker is making ugly JPEGs now,.. some of them looks very funny.
>
> 
>
> [2001-12-18 11:32:35] [EMAIL PROTECTED]
>
> Alright, it's not like anyone cares about the portability of GD based applications, 
>huh ? 
>
> Status -> bogus.
>
> 
>
> [2001-12-18 11:31:54] [EMAIL PROTECTED]
>
> quick respons eh,. :D
>
> I am already signed up at php4win.de
>
> I have tryed using the lastest GD from php4win,... with no success,. :´(
>
> 
>
> [2001-12-18 11:30:01] [EMAIL PROTECTED]
>
> just cancel this,... I found it reported as a Bogus,..
>  - http://bugs.php.net/bug.php?id=14461
>
> 
>
> [2001-12-18 11:29:55] [EMAIL PROTECTED]
>
> That is a good question, and one that I have been ranting about on the php-dev list 
>for a while now.
>
> You can either try to compile PHP with GD 2.0.1 yourself or email Daniel from 
>php4win.de and see if he would provide a php_gd.dll for 2.0.1.
>
> -- Joao
>
> p.s.: I would guess this would be an 'analyzed' entry ?
>
> 
>
> The remainder of the comments for this report are too long. To view
> the rest of the comments, please view the bug report online at
> http://bugs.php.net/?id=14583
>
>
> Edit this bug report at http://bugs.php.net/?id=14583&edit=1
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Vacation

[Joao Prado Maia]

On Sun, 23 Dec 2001, Björn Schotte wrote:

> * Derick Rethans wrote:
> > I just wanted to say that I'll be doing other things for a while, instead
> > of concentrating on PHP development. This does not mean that I won't
> > follow mail, but every message with 'bug' in the subject will go to my
>
> Did I miss something (somebody said there was a heated
> discussion on engine2, unfortunately I read that list
> with the D-key in the last couple of weeks) or why are
> important PHP developers breaking away?
>

The discussion on engine2 wasn't really all that heated, I've seen worse
ones by Zeev/Sascha and such. I guess people are just burn out of working
24/7 on the project and need a little break from it.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Joao Prado Maia]

On Mon, 31 Dec 2001, Jon Parise wrote:

> On Mon, Dec 31, 2001 at 11:49:02AM -0700, Zak Greant wrote:
>
> > > I think the following "standard" extensions should be moved to
> > > PECL:
> > >
> > > ext/cybercash
> > > ext/icap
> > > ext/pfpro
> > > ext/yaz
> > >
> > > This is definitely not an inclusive list; it's just a start.  I
> > > can't imagine a lot of people using these modules, so they seem
> > > like good candidates for removal from the base PHP distribution.
> > >
> > > Are there any well-founded objections to this (either in practice
> > > or principle)?
> >
> >   We should probably add cybermut to the list as well.
>

What about the 'fribidi' extension then ? ;)

I would think the following extensions should also go to PECL:

filepro
aspell
crack
ctype
cyrus
dio
dotnet
mailparse
midgard
muscat
notes
qtdom
readline
recode
satellite
vpopmail

Joao

p.s.: let the flame wars begin! ;)

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joao Prado Maia]

On Wed, 2 Jan 2002, Zeev Suraski wrote:

> At 16:06 02/01/2002, Björn Schotte wrote:
> >* Zeev Suraski wrote:
> > > Well, I think that the main motivation for separating the modules away was
> > > the release schedule.  I.e., separating the release schedule of each
> > > extension from the release schedule of the PHP core itself.
> >
> >Jep. Just to note: I'm +1 for it.
>
> I'm +1 for separating the less popular ones, but I'm -1 for separating
> everything (look up the archives as to why...)
>

Why not separate everything and then bundle the more popular ones to the
normal PHP distribution on the time of a release ? I would love to be able
to upgrade just the 'GD' extension if there was a bug on the extension on
release PHP4.1.12 and it was fixed on PECL version of the extension
2.1.23.

I would also love to be able to tell the users of my application to just
use the PEAR installer to download and install the bugfix release of the
GD extension instead of telling them to not use a particular buggy / not
compatible version of PHP.

I can understand that it will mean more work to you guys to handle
several release independent extensions, but if you can just use the PEAR
installer to download the stuff from the repository, you will be able to
download the stable releases from PEAR and then build the general PHP
distribution.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joao Prado Maia]

On Wed, 2 Jan 2002, Joe Webster wrote:

> I have something that I am currently dealing with:
>
> Using mod_perl with apache, you can put this in a apache directive
> (vhost, location, directory):
> PerlSetVar somevarname somevarval
> and that would pre-define somevarname equal to somevarval. We are trying
> to move completely to php (we're 1/2 php and 1/2 perl) however, we really
> need to be able to set the vars like this. I did look through the mod_php.c
> and I noticed the php_value, php_flag, php_admin_value, and php_admin_flag,
> but nothing for a variable.
>

I know it is not the same as having it on the httpd.conf (.htaccess too?)
but you can set a 'auto-prepend' PHP script, which could be used to define
any constant or variable. Is this not an option for you guys ?

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Built-in SOAP based Web Services support(wasRe:PHP 5)

[Joao Prado Maia]

On Wed, 2 Jan 2002, Lukas Smith wrote:

> Well the problem is that people will want to grow with the specs and use
> part of the specs now ...
>
> And in the end they will use the tool that they grew with and they will
> use the tool that is not vapourware when the spec is finalized
>
> Anyways SOAP is a good thing (tm)
> So is UDDI and WDSL (I do not see WDSL anywhere far in the near future
> though)
> And even if it turns out to suck, too many people have bet on it to be
> dropped anytime soon
>
> So it would really rock to have SOAP
> There will be people dropping PHP and there will be people not taking
> PHP seriously if it lacks SOAP
>

I know Manuel wants to have the SOAP / Web services support built-in in
PHP, but the XMLRPC extension already has initial support for SOAP. This
initial set of code could be used to develop the support even more.

Since the XMLRPC extension is now bundled with PHP, can we think of it as
'official' support for Web services ? My personal opinion is that it can
be regarded as that, and further work can be done there. If people want to
use SOAP, enable the module at compile time (or even dynamically load it)
and there you go - Web services support in PHP.

Is there anything wrong with this picture ?

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Built-in SOAP based Web Services support(wasRe:PHP 5)

[Joao Prado Maia]

On Wed, 2 Jan 2002, Sebastian Bergmann wrote:

> Lukas Smith wrote:
> > But I think we have pitched the need for SOAP enough now :-)
>
>   What's wrong with the SOAP implementation provided by ext/xmlrpc?
>
>   Rumour has it, by the way, that a nice PEAR class is underway that
>   simplifies the use of this extension.
>

That was exactly my point. It seems they are so involved in discussing
their personal feelings about Microsoft, Web services in general and the
whole Manuel x Zeev war that they just decided to ignore my message ;)

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Joao Prado Maia]

On Thu, 3 Jan 2002, Zak Greant wrote:

> On 2002-3-01 03:39, Lukas Smith wrote:
> > Well PHP and MySQL are a very popular combo .. but I do not see a point
> > in "separating" the API's even further ... DB API's are a major concern
> > for myself right now too
> >
> > It would be really nice to work more in the direction of unifying all of
> > the API's on a "C level"
> >
> > Other than that there is nothing against doing that change .. but I
> > think it would only make sense to do it across the board
>
>   I plan to keep my focus on this very small to avoid distraction. :)
>
>   I am currently working on a PHP based implementation that uses Andrei's
>   overload extension.  Once I this is somewhat stable and users have had a
>   chance to work with it, I plan to implement it in C.
>

My personal opinion is that the OOP layer idea is pretty bad. Instead of
having 7 or 8 set of functions to learn, now the newbie will have 8 set of
functions / APIs. The idea might sound very sexy and everything, but the
real problem is that there is already _some_ talks in PEAR-DEV about
trying to create a unified API for all databases (a new one, not PEAR::DB)
which would be eventually be ported to C.

I really don't feel very good with yet another database abstraction
package, and this time just for MySQL. I say database abstraction not in
the sense that it will abstract everything, but that it gives a thin layer
of abstraction to the underlying database.

In any case, I _really_ hope you will talk with Stig and get to know more
about the latest discussions (flame-wars?) in PEAR-DEV about the upcoming
re-write of PEAR::DB and also about the intention of re-writing it in C
once it is stable.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.1.1 for win

[Joao Prado Maia]

On Thu, 3 Jan 2002, Markus Fischer wrote:

> On Thu, Jan 03, 2002 at 12:10:26PM +0100, Gabor Hojtsy wrote :
> > Hi!
> >
> > As the new year is over now, can someone be so kind
> > to compile and release a PHP 4.1.1 for windows?
> > Please also make the windows file names reflect
> > the "standards".
>
> A plea to whoever builds it, please also include gd2 support.
>

Ditto. This is not a small problem by the way, I could create a huge
flame-war thread (ala Manuel and dirname()) because this is a big deal to
a lot of users. Probably bigger than dirname() :P

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Joao Prado Maia]

On Thu, 3 Jan 2002, Markus Fischer wrote:

> On Thu, Jan 03, 2002 at 03:49:48PM +0100, Lukas Smith wrote :
> > > From: Joao Prado Maia [mailto:[EMAIL PROTECTED]]
> >
> > > My personal opinion is that the OOP layer idea is pretty bad. Instead
> > of
> > > having 7 or 8 set of functions to learn, now the newbie will have 8
> > set of
> > > functions / APIs. The idea might sound very sexy and everything, but
> > the
> > > real problem is that there is already _some_ talks in PEAR-DEV about
> > > trying to create a unified API for all databases (a new one, not
> > PEAR::DB)
> > > which would be eventually be ported to C.
> >
> > yes I second this
> >
> > > From: Phil Driscoll [mailto:[EMAIL PROTECTED]]
> >
> > > feels 'all wrong' and 'not php'. I'm particularly concerned that we
> > > don't create functionality which is only accessible by OO means.
> >
> > Yes I also see a danger there.
> > Procedural is still the method choosen by most newbies and also used a
> > lot of established (php) professionals.
> > So what ever we do, we should always provide atleast the same level of
> > functionality without the OO interface
>
> What tells you that? I see more OO code then procedureal when
> I browser through misc. sources.
>

The real problem here is not about OOP x Procedural programming, but about
duplicating the effort that already began to create a unified database
abstraction layer. The PEAR-DEV guys, especially Stig, are working on this
for quite a while and it seems very bad to suggest the same work to be
started again just because it sounds 'cool'.

I repeat once again, why not work with Stig and the rest of the PEAR-DEV
guys on this new redesigned PEAR::DB (or whatever it ends up being called)
so in the near future we can then think of doing a C port of it ?

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Joao Prado Maia]

On Thu, 3 Jan 2002, Markus Fischer wrote:

> On Thu, Jan 03, 2002 at 10:31:51AM -0500, Joao Prado Maia wrote :
> > I repeat once again, why not work with Stig and the rest of the PEAR-DEV
> > guys on this new redesigned PEAR::DB (or whatever it ends up being called)
> > so in the near future we can then think of doing a C port of it ?
>
> I appriciate Thomas and Stig's effort very much (and of
> course all the others which would take too long to list them
> all). But beside _talking_ about C code I haven't seen
> anything yet.
>

So ? I didn't see any C code from Zak either. If all we are doing right
now is speculating on the creation of a PHP based 'prototype' of this
MySQL-only abstraction thing, why is it more interesting than a existing
package like PEAR::DB ?

Talk is just that - talk. The weird part is that Zak probably know about
PEAR::DB and he might even know about Stig's plan on writing a C port of
a stable version of it. Maybe I'm wrong, but I just don't feel very good
about all this duplication of efforts and even more about a abstraction
class _just_ for MySQL.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Joao Prado Maia]

On Fri, 4 Jan 2002 [EMAIL PROTECTED] wrote:

> Hello,
>
> If everybody had _read_ Zak's initial proposal, they should have noticed
> that he wanted to ADD an OO interface:
>
>Create an OO-based wrapper for the MySQL extension.
>
> Then there would would not have been an useless and endless thread.
> My guess that everybody can do more useful things with their time.
>

Well, you might have the opinion that this an useless thread, but I don't
agree. Lukas was very right in saying that the API's would get even more
different if this OOP form be added. We will have 2 ways of doing the same
thing in MySQL, another set of ways to do the same thing in PostgreSQL
(even being similar, there are differences), another completely different
way of doing things in OCI and so on.

We are talking about keeping the API's as close to each other as possible.
One of the things that I like in the Python development is how it is well
organized - an official database API exists and module developers stick to
it. It doesn't stop just on the DB API, but everywhere on its standard
library and built-in functions.

Please don't tell me that Python is not PHP - I know that. I just wish
things were a little bit more sane in relation to standard APIs across the
board. It seems that everywhere people are afraid of trying to set
standards, like on the case of PEAR standards or on this case the database
related API standard.

Don't get me wrong, I don't have any illusion that this will change any
time soon (if ever). It is still important to talk about this, and it is
definetely not a useless thread to me.

Joao


> Derick
>
>
> On Fri, 4 Jan 2002, Lukas Smith wrote:
>
> > The important thing is to keep at least the same level of functionality
> > for procedural coding
> >
> > This was the entire concern raised about too much OOP form what I
> > gather.
> >
> > There was also the concern raised that your design will be heavily
> > influenced by the possibilities offered by the ZE1, where as the ZE2
> > will allow many new things that will result in a very different design.
> >
> > Also I do not like how different the API's are in some respects as it
> > is. Further diverging them is nit helping imho. People that want an OOP
> > interface can choose one of the major DB abstraction layers (PEAR DB,
> > Metabase, ADODB ...).
> >
> > Then again Zak's proposal is not about abstraction but about giving an
> > OOP interface and if you are going to do it anyways I guess we can
> > postpone the discussion until the code is there :-)
> >
> > Best regards,
> > Lukas Smith
> > [EMAIL PROTECTED]
> > ___
> >  DybNet Internet Solutions GbR
> >  Alt Moabit 89
> >  10559 Berlin
> >  Germany
> >  Tel. : +49 30 83 22 50 00
> >  Fax : +49 30 83 22 50 07
> >  www.dybnet.de [EMAIL PROTECTED]
> > ___
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php and http return status

[Joao Prado Maia]

On Tue, 22 Jan 2002, brad lafountain wrote:

> Maybe this is eaiser than i think.. but..
>
> Does anyone know how to return http 500 status
> from inside an extensiosn or just regular ole
> php script.
>

You mean, besides doing header("500 ") ?

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: Bug #13388 Updated: Could not connect to server

[Joao Prado Maia]

> As I said, too less information, and this is probably not a bug. Please
> try to ask on the [EMAIL PROTECTED] or [EMAIL PROTECTED]
> for support questions.
>

"This is probably not a bug" ? Are you kidding me ? I hope you are not
closing any real nasty bugs because of this reasoning :)


> > How can you determine it is bogus within 2 minutes, please provide your
> > rational.
>
> I just did.
>

Yeah, I guess you did.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

[Joao Prado Maia]

On Wed, 26 Sep 2001, Andi Gutmans wrote:

> I think the key still lies in creating a repository for C extensions where
> each extension can have its own release cycle.
>

That is also true, but we still need a reliable way to check for the
version of specific extensions. Having just bumped into an inconsistency
between GD 1.6.2 and GD 2.01 output, this would help a lot.

However, the problem is already out there and to create code that is truly
portable I couldn't rely on even this new (if it ever comes to life)
feature. This sort of thing really complicates writing portable code. not
just for different platforms but also for different versions of
extensions.

Just a repository wouldn't help much from the programmer's perspective
IMHO, if the current situation continues.

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

[Joao Prado Maia]

On Wed, 26 Sep 2001, Andi Gutmans wrote:

> I agree completely. We need a way to check what version each extension is.
> We have broken BC quite a bit in 4.0.7 so maybe we should add this to 4.0.7
> so that we can get this whole external C extension thing going ASAP?
>

If I could vote on this I would say yes. A lot of good and reliable code
will appear if something like this is implemented.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Followup to the Versioning Scheme discussion

[Joao Prado Maia]

I was just wondering what ended up being decided about the versioning
scheme that Jani proposed and Andi later on re-proposed a different way of
doing it by using a special function.

I also remember Andi or even Zeev talking about implementing this system
before the release of 4.0.8 (I might be mistaken tho). How is
everything in this area ? I would _love_ to see such a feature on PHP.

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Multilpe submits ...

[Joao Prado Maia]

On Fri, 19 Oct 2001, Markus Fischer wrote:

> Anyone with proper access feeling responsible preventing multiple
> submits ? :)
>

Isn't that something that the developer should handle, and not the
language itself ? Do you know if any other language does something like
that ?

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Multilpe submits ...

[Joao Prado Maia]

On Fri, 19 Oct 2001, Derick Rethans wrote:

> Hello,
>
> I think he meant multiple bug report submits here...
>

Duh! Well, on that case I guess Jan Lehnardt already has the code for that
functionality, as described on his last email to the list.

Can someone grant him access to the appropriate cvs repository ?

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] making mail() funtion work without sendmail on UNIXsystems

[Joao Prado Maia]

On Fri, 19 Oct 2001, Rasmus Lerdorf wrote:

> > Don't you think that on some systems (probably with high loads) it might be
> > much more efficient to use SMTP than spanning "mail" via fork()/exec()?
>
> Only in the case of a local smtpd.  But yes, in that scenario I agree.
>

I'm not at all on top of all the implications of implementing this change,
but why not code all this stuff into an specialized extensions and make
the developers of the scripts in charge of using either the default mail()
function or this new functionality ?

I mean, this way we keep the code that we have now in place working the
same way it always did and new features can be used by loading this
extension.

Just my .2c :)

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP Extension Help

[Joao Prado Maia]

Hi,

Before starting up on this email, please be aware that I'm a newbie in C
programming and especially in PHP extension coding. I tried researching
about my doubt (and even talked with Joey Smith) but couldn't really have
a definite answer.

My ultimate goal for my little PHP extension is to try to learn C
programming and also try to create a C extension to replace the use of the
PHPLIB template class. I want to be able to basically create my extension
and then 'plug-in' into my code and have it work as the PHPLIB template
class would work.

At first I tried creating an internal class like 'Directory' and have it
somehow be able to do :

$t = new JTemplate; // or something similar

After speaking with Joey, I learned that you cannot do that (is this
true?) because the 'new' operator doesn't look for built-in functions.

However, I remember PHP-GTK and how you could do something like this:

$win = &new GtkWindow();

Isn't this 'GtkWindow' an example of how to register a built-in class and
then have the code instantiate it normally as you would do it with a
normal PHP based class ? (again, be nice. I'm a newbie :)

Anyway, if someone could answer this simple question it would be very
appreciated.

Cheers,
Joao


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

Re: [PHP-DEV] PHP Extension Help

[Joao Prado Maia]

On Thu, 27 Jun 2002, Alan Knowles wrote:

> this is a good starting place
> http://www.php.net/manual/en/zend.php
>

Yes, I looked on the manual before asking. There isn't a good introduction
on how to do what I want to do in there, and thats why I asked around
before sending the email here.


> although it doesnt cover the class stuff that well (which can be done :
> ming, domxml,  gtk, xmms  - to name a few that do it )
> - for a nice example have a look at the xmms extension
> http://cvs.php.net/cvs.php/pear/PECL/xmms
>

While I see the lines on xmms.c to create and register the new 'xmms'
internal class, I don't see in here:

http://cvs.php.net/co.php/pear/PECL/xmms/xmms.php?r=1.1

the code to actually do:

$xmms = new xmms; // or something like this


> This illustrates class and functional creation,
>
> as a side suggestion it may be worth calling your class HTML_Template_XX
> as this would fit in better with the PEAR naming of classes..
>

Again, what I really wish to do is create a plug-in replacement for
PHPLIB's Template class. I already have a huge codebase that uses PHPLIB'
Template class and would like to create an extension that would make it
possible to just remove the calls to 'include("Template.php")' from my
code and have the code use my C extension class instead.

Since I'm not planning on contributing this to PEAR and that I need the
specific 'Template' class name, your suggestion is not appropriate ;)

Thanks,
Joao


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

Re: [PHP-DEV] PHP Extension Help

[Joao Prado Maia]

Ack, sorry. I just found xmms's implementation of the class on the xmms.c
file. Seems like it is exactly what I was looking for.

Thanks for the pointers, I appreciate it.

Cheers,
Joao


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

Re: [PHP-DEV] New FTP extension functionality

[Joao Prado Maia]

On Tue, 30 Jul 2002, Sterling Hughes wrote:

> > Hi,
> >
> > yesterday I did several commits to the FTP extension. Due to the fact that
> > I do not know how I can document the stuff myself and right now am lacking
> > the time here is a brief instruction:
> >
>
> The work looks quite cool, however this is really not asynchronous i/o,
> but rather non-blocking i/o.
>

So are we going to rename these functions because of this ? It seems kind
of weird of having ftp_async_get() when the function is not really
asynchronous ;)

If what Sterling just said is really accurate, _please_ don't release
4.3.0 with the wrong function names. It just doesn't look professional :)

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro


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