Hello!
And here I am, back with more SAPI questions. Having abandoned my earlier
project as unworkable, I'm trying to build a MUD server in Java...and I
want people from within the MUD server to be able to access functions
written in PHP. Seems like an ideal situation for a SAPI.
At 13:43 20/02/2006, Lukas Smith wrote:
Hartmut Holzgraefe wrote:
Wez Furlong wrote:
I think not many people use it because it's difficult to use.
Having real labels might change that.
Personally, I'd prefer real goto, as I've stated in the past.
Just for the record again, I'm +1 for goto, and
On Mon, 20 Feb 2006, Lukas Smith wrote:
> Hartmut Holzgraefe wrote:
> > Wez Furlong wrote:
> > > I think not many people use it because it's difficult to use.
> > > Having real labels might change that.
> > > Personally, I'd prefer real goto, as I've stated in the past.
> > > Just for the record a
Hartmut Holzgraefe wrote:
> Wez Furlong wrote:
> > I think not many people use it because it's difficult to use.
> > Having real labels might change that.
> > Personally, I'd prefer real goto, as I've stated in the past.
> > Just for the record again, I'm +1 for goto, and +0.5 for labelled
> > bre
On Tue, 21 Feb 2006, Steph Fox wrote:
> > > Hartmut Holzgraefe wrote:
> > > > Wez Furlong wrote:
> > > > > I think not many people use it because it's difficult to use.
> > > > > Having real labels might change that.
> > > > > Personally, I'd prefer real goto, as I've stated in the past.
> > > > >
Hi,
Take a look at sapi/php_embed/
You'll need a good skill in PHP engine this SAPI module is a good example.
- Original Message -
From: "Ben Trafford" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, February 21, 2006 11:31 AM
Subject: [PHP-DEV] Anybody written a Java SAPI?
Hello!
And her
http://phpfi.com/103442
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
In PHP 5.0.x, I can chain function calls like this:
$obj->method()->anotherMethod();
In PHP 5.1.x, this code results in an error:
parse error, unexpected T_OBJECT_OPERATOR in ...
I've looked through the change log for 5.1 but didn't see
anything relevant.
Was this an intentional change?
Thank
In PHP 5.0.x, I can chain function calls like this:
$obj->method()->anotherMethod();
In PHP 5.1.x, this code results in an error:
parse error, unexpected T_OBJECT_OPERATOR in ...
I've looked through the change log for 5.1 but didn't see
anything relevant.
Was this an intentional change?
Thank
Mark Spruiell wrote:
In PHP 5.0.x, I can chain function calls like this:
$obj->method()->anotherMethod();
In PHP 5.1.x, this code results in an error:
parse error, unexpected T_OBJECT_OPERATOR in ...
I've looked through the change log for 5.1 but didn't see
anything relevant.
Was this an int
Mark Spruiell skrev:
In PHP 5.0.x, I can chain function calls like this:
$obj->method()->anotherMethod();
In PHP 5.1.x, this code results in an error:
parse error, unexpected T_OBJECT_OPERATOR in ...
I've looked through the change log for 5.1 but didn't see
anything relevant.
[EMAIL PROTECT
Hi,
In the last days I've exchanged some e-mails with PCRE's author because of
one more bug that appeared in our database about segfaults in PCRE (related
to stack overflows).
PCRE can consume a lot of stack, because of backtracking (thus segfaulting
PHP). Yesterday I've discovered that when u
> Mark Spruiell wrote:
>> In PHP 5.0.x, I can chain function calls like this:
>>
>> $obj->method()->anotherMethod();
>>
>> In PHP 5.1.x, this code results in an error:
>>
>> parse error, unexpected T_OBJECT_OPERATOR in ...
>>
>> I've looked through the change log for 5.1 but didn't see
>> anything
Nuno Lopes wrote:
In the last days I've exchanged some e-mails with PCRE's author because
of one more bug that appeared in our database about segfaults in PCRE
(related to stack overflows).
PCRE can consume a lot of stack, because of backtracking (thus
segfaulting PHP). Yesterday I've discovere
Nuno Lopes wrote:
Hi,
In the last days I've exchanged some e-mails with PCRE's author because
of one more bug that appeared in our database about segfaults in PCRE
(related to stack overflows).
PCRE can consume a lot of stack, because of backtracking (thus
segfaulting PHP). Yesterday I've dis
could you tell me the way you choose to build? I mean steps.
2006/2/22, Sebastian Bergmann <[EMAIL PROTECTED]>:
>
> http://phpfi.com/103442
>
> --
> Sebastian Bergmann http://www.sebastian-bergmann.de/
> GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
I had an issue with an extension that I previously posted to this
list and it was suggested I update to the newer API which might
provide a solution to the problem.
Taking a somewhat safe approach I tackled converting the rrdtool
extension first since it was similar in functionality and pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
[response is at the bottom]
Ilia Alshanetsky wrote:
> Nuno Lopes wrote:
>> In the last days I've exchanged some e-mails with PCRE's author
>> because of one more bug that appeared in our database about segfaults
>> in PCRE (related to stack overf
18 matches
Mail list logo
