Marco wrote:
The same way anything is encouraged in this programming world. Write
killer apps that only work in PHP 5+. This is a thread that will be
more at home on php-general@lists.php.net
How can you write killer apps in php5 when less than 5% of low costs
hosting providers support it? I
>
>
> The same way anything is encouraged in this programming world. Write
> killer apps that only work in PHP 5+. This is a thread that will be
> more at home on php-general@lists.php.net
How can you write killer apps in php5 when less than 5% of low costs
hosting providers support it? Its a
Marco wrote:
>>Is this a crazy idea? Or is it even possible? I guess its not possible to
>>garuantee 100% compatability but even 90 - 95% would be a start.
>>
>
>
> I guess this is a crazy idea since no-one has commented :-) Oh well... does
> anyone have any suggestions on how we can encourage t
>
> Is this a crazy idea? Or is it even possible? I guess its not possible to
> garuantee 100% compatability but even 90 - 95% would be a start.
>
I guess this is a crazy idea since no-one has commented :-) Oh well... does
anyone have any suggestions on how we can encourage the deployment of php
Wez Furlong wrote:
Like this:
http://us2.php.net/manual/en/function.openssl-pkey-get-public.php
or something else?
Close, but I need them in PEM format.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Agreed Unless someone goes ahead and changes the get_line macro and
places that call it, I'll do so when I get to the end of my second leg...
-Sara
- Original Message -
From: ""Wez Furlong"" <[EMAIL PROTECTED]>
Newsgroups: php.internals
To: "Andrei Zmievski" <[EMAIL PROTECTED]>
Cc:
I Like that idea.
- Frank
> I think ZSTR(buf) should not be present in the macro:
>
> #define php_stream_get_line(stream, buf, maxlen, retlen)
>_php_stream_get_line((stream), IS_STRING, (buf), (maxlen), 0,
>(retlen) TSRMLS_CC)
>
> Let the caller apply ZSTR() to the argument manually, if
NULL_ZSTR is not a problem, but when a macro defines ZSTR(buf) and buf is
NULL_ZSTR you get ZSTR(NULL_ZSTR) which is invalid.
- Frank
> What was the problem with NULL_ZSTR?
>
> Dmitry.
>
> > -Original Message-
> > From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April
Hi Steph,
Steph Fox wrote:
Hi Wez,
The problem with moving ext/skeleton is that we'll end up shipping PHP
without an extension template of any kind. Almost every single PHP
book that talks about writing extensions uses ext_skel to do so.
Since when have existing books been a reason not to
Hi Wez,
The problem with moving ext/skeleton is that we'll end up shipping PHP
without an extension template of any kind. Almost every single PHP
book that talks about writing extensions uses ext_skel to do so.
Since when have existing books been a reason not to change something?
Giving PEC
The problem with moving ext/skeleton is that we'll end up shipping PHP
without an extension template of any kind. Almost every single PHP
book that talks about writing extensions uses ext_skel to do so.
Giving PECL_gen some good press is a different issue, and does not
require that we move ext/sk
Petar Nedyalkov wrote:
> This totally breaks the capsulation in the OO paradigm, so I find it the
> right
> behaviour.
This is PHP we're talking about. If you want 100% purist "capsulation"
according to "OO paradigm" you're clearly using the wrong language. Heck
even wrong language class.
What
Petar Nedyalkov wrote:
On Tuesday 25 April 2006 14:30, Edin Kadribasic wrote:
Hi,
I was wondering if someone could enlighten me why it is not possible to
create on-the-fly static properties:
php -r 'class foo{}; foo::$bar = 1;'
Fatal error: Access to undeclared static property: foo::$bar in
On Tuesday 25 April 2006 14:30, Edin Kadribasic wrote:
> Hi,
>
> I was wondering if someone could enlighten me why it is not possible to
> create on-the-fly static properties:
>
> php -r 'class foo{}; foo::$bar = 1;'
> Fatal error: Access to undeclared static property: foo::$bar in Command
> line
I've just applied a bit different patch.
Thanks for the heads up.
On 25.04.2006 14:25, Mike Bretz wrote:
According to recent security alerts I have made a patch against 5.1 CVS
for bug 33605, which is already CLOSED but not fixed.
See attachment for patch and test file.
Somebody can review it
Hi,
I was wondering if someone could enlighten me why it is not possible to
create on-the-fly static properties:
php -r 'class foo{}; foo::$bar = 1;'
Fatal error: Access to undeclared static property: foo::$bar in Command
line code on line 1
Was this not possible because of the engine implement
The problem was the macro expansion (problematic on non-gcc builds):
ZSTR(NULL_ZSTR) --> ZSTR(ZSTR((void*)NULL))
But I agree with Wez and I thing that the ZSTR() should be removed from the
php_stream_get_line() macro.
BTW, I though it wasn't possible to build PHP with gcc 2.95 anymore. At
lea
According to recent security alerts I have made a patch against 5.1 CVS
for bug 33605, which is already CLOSED but not fixed.
See attachment for patch and test file.
Somebody can review it and merge it into 5.1 / HEAD?
mike
--
mike peter bretzmetropolis ag / entwicklun
ext/skeleton is a different beast and I suspect that 99.99% users have
never heard of it.
You mean you only want to move things people have heard of?!
I mean I only want to move things which I consider unsafe.
It's safe to include ext/skeleton as you definitely know what you're doing
when you
On 25.04.2006 13:20, Steph Fox wrote:
On 25.04.2006 11:27, Steph Fox wrote:
I'd add ext/skeleton to that list. Hartmut's PECL_gen project is way
ahead of it, actively supported and very easy to get hold of... and
Hartmut gives it a at every opportunity :)
ext/skeleton is a different beast an
Antony Dovgal wrote:
Hello all.
I'd like to propose yet another bunch of extensions to be moved from
core to PECL.
(Don't worry, this is for 5.2 and HEAD. 5.1 is untouchable atm).
They are:
ext/hwapi
ext/filepro
ext/recode
I would like to make one more proposal: Lets move ALL
unsupported/u
Hi,
I didn't get enough opinions yet to decide if it is worth to work on it further.
http://dev.iworks.at/PATCHES/output/
Thanks,
--
Michael - http://dev.iworks.at/ext-http/http-functions.html.gz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/
Can we add a notice into the configure script in 5.x when using these
extensions and move them into PECL for 6.0? A hint in 5.x will inform
the few people who are using the extensions that they will find them in
PECL in future. Maybe current configure options like "--with-hwapi" will
be kept an
On 25.04.2006 11:27, Steph Fox wrote:
I'd add ext/skeleton to that list. Hartmut's PECL_gen project is way ahead
of it, actively supported and very easy to get hold of... and Hartmut gives
it a at every opportunity :)
ext/skeleton is a different beast and I suspect that 99.99% users have neve
24 matches
Mail list logo
