Building PHP with bison versions up to 1.75 works fine, but both
bison 1.875 and 1.875a cause a segfault during the startup of PHP.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x081919b4 in ini_parse () at Zend/zend_ini_parser.c:1042
1042YYSTACK_RELOCATE (yys
Hello,
I have not had time to look this in detail so I could not reach a
conclusion.
Is the upcoming object model supporting package level member access
retrictions like in Java?
For those that are not aware of what is that, packages are a group of
independent classes (not like nested classes
On Thu, 2003-03-27 at 21:42, Andi Gutmans wrote:
I get your points. I think I'm gonna shut up for now and try using
ZendEngine2 a bit, to see what it's actually like in the Real World.
Thanks for your time.
--
Best regards,
Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
We
At 09:49 PM 3/27/2003 +, Wez Furlong wrote:
Please lets have exceptions here, otherwise you will render type-hints
useless (they are intended primarily for OO programmers anyway).
I wouldn't call them useless. It's the same as a script compiler where you
would error out if you don't use the sa
At 10:43 PM 3/27/2003 +0100, Marcus Börger wrote:
At 19:13 27.03.2003, Andi Gutmans wrote:
At 06:55 PM 3/27/2003 +0100, Timm Friebe wrote:
On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
> Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>
> Where is there more info on what th
Hey, J2EE/DB2 has a php.ini file? Cool.
This is the wrong list for this question, but you could try using the
PHPRC env var instead to set the location of your php.ini file.
-Rasmus
On Thu, 27 Mar 2003, Mark Striebeck wrote:
> Hi,
>
> we are building PHP with the --with-config-file-path c
Hi,
we are building PHP with the --with-config-file-path compile setting to get our php.ini file from our own location.
Now, in some scenarios we need to run PHP with the -c command line option to get the php.ini file from a different location.
This seems to cause problems!
When using the -c co
On Tue, Mar 25, 2003 at 12:02:16PM +0100, Harald Radi wrote:
> we probably could add a link to the chora diff, e.g.
> http://cvs.php.net/diff.php/adt/php_tree.c?r1=1.30&r2=1.31
>
> that would be an easy to make addition and should satisfy those who want it
> colourful :)
That's what I do for th
Please lets have exceptions here, otherwise you will render type-hints
useless (they are intended primarily for OO programmers anyway).
I'm somewhat concerned that we are implementing a lot of the new OO
features in a half-hearted fashion; I understand that there is a balance
to maintain between e
At 19:13 27.03.2003, Andi Gutmans wrote:
At 06:55 PM 3/27/2003 +0100, Timm Friebe wrote:
On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
> Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>
> Where is there more info on what the type hints do in ZE2. I am
curious as
> I wrot
At 08:08 PM 3/27/2003 +0100, Per Lundberg wrote:
> >Of course, it should not be done in a way to break backward
> >compatibility if at all possible.
> I consider having half of PHP throw errors and the other half as throwing
> exceptions to break BC.
Even though we are talking about functionalites
shalom,
i'm writing php extension for allegro
(http://www.talula.demon.co.uk/allegro/) that hopfeully 'll go somewhere
soon into pecl. allegro is cross platform grafix library so in addition to
the gaming capabilities, we have here chance using it as base to native php
gui.
the problem i have is
i want did the suggested patch there are rejections?
- Original Message -
From: <[EMAIL PROTECTED]>
Newsgroups: php.bugs
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 27, 2003 11:06 AM
Subject: #22904 [Opn]: fwrite is not binary safe for '\0' string
> ID: 22904
> Updated
At 10:27 AM 3/27/2003 -0800, Shane Caraveo wrote:
Andi Gutmans wrote:
At 09:42 AM 3/27/2003 -0800, Shane Caraveo wrote:
Well, if set_error_handler could catch E_ERROR errors (and not bail),
then errors could be changed to exceptions in user space. I already use
this in the soap library to catch
On Thu, 2003-03-27 at 19:07, Andi Gutmans wrote:
> >How about being able to handle errors in a clean and elegant way?
> >Exceptions make this very convenient.
> We have an error handler.
Context-local error handling is much more convenient (not to mention the
elegance of being able to handle error
Andi Gutmans wrote:
At 09:42 AM 3/27/2003 -0800, Shane Caraveo wrote:
Well, if set_error_handler could catch E_ERROR errors (and not bail),
then errors could be changed to exceptions in user space. I already
use this in the soap library to catch invalid parameters, which I
beleive are only war
Stanislav Malyshev wrote:
> stas Thu Mar 27 12:57:48 2003 EDT
>
> Modified files:
> /ZendEngine2 zend_execute.c
> Log:
> fix fetch_class buglet
That did the trick.
Thank you,
Sebastian
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://php
> It should be a runtime or compiletime flag in each extension, not a
> seperate text file that someone needs to read.
In a truely perfect world we would have that compile time flag in the
extension definition structure, and then could do a extension specific
lock (mutex) before calling functions
At 06:20 PM 3/27/2003 +0100, Per Lundberg wrote:
On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:
> At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> >I've implemented an additional feature for type hints that will throw an
> >exception instead of bailing out in case an incorrect type is passed.
>
On Thu, 2003-03-27 at 13:13, Andi Gutmans wrote:
> At 12:37 PM 3/27/2003 -0500, Sterling Hughes wrote:
>
> >Just a note on this. People have avoided OO cause OO sucked.
> >
> >Exceptions themselves are *incredibly* useful, especially when dealing
> >with database code (the majority of php applica
At 06:55 PM 3/27/2003 +0100, Timm Friebe wrote:
On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
> Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>
> Where is there more info on what the type hints do in ZE2. I am curious as
> I wrote the RFC.
Zend/ZEND_CHANGES includes a se
At 12:37 PM 3/27/2003 -0500, Sterling Hughes wrote:
Just a note on this. People have avoided OO cause OO sucked.
Exceptions themselves are *incredibly* useful, especially when dealing
with database code (the majority of php applications), so I think you'll
see that portion of php used quite a bi
At 09:42 AM 3/27/2003 -0800, Shane Caraveo wrote:
Well, if set_error_handler could catch E_ERROR errors (and not bail), then
errors could be changed to exceptions in user space. I already use this
in the soap library to catch invalid parameters, which I beleive are only
warnings. Not being abl
At 06:13 PM 3/27/2003 +0100, Timm Friebe wrote:
On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:
> At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> >I've implemented an additional feature for type hints that will throw an
> >exception instead of bailing out in case an incorrect type is passed.
>
>
On Thu, 2003-03-27 at 12:52, George Schlossnagle wrote:
> On Thursday, March 27, 2003, at 12:10 PM, Timm Friebe wrote:
>
> > On Thu, 2003-03-27 at 18:04, George Schlossnagle wrote:
> >> On Thursday, March 27, 2003, at 11:58 AM, Andi Gutmans wrote:
> > [...]
> >> I think this can(all) be handled
On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
> Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>
> Where is there more info on what the type hints do in ZE2. I am curious as
> I wrote the RFC.
Zend/ZEND_CHANGES includes a section about type hints.
I suggested allowing
On Thursday, March 27, 2003, at 12:10 PM, Timm Friebe wrote:
On Thu, 2003-03-27 at 18:04, George Schlossnagle wrote:
On Thursday, March 27, 2003, at 11:58 AM, Andi Gutmans wrote:
[...]
I think this can(all) be handled with a custom zend_error_cb anyway
(in
an extension - so that it's available
David Hill (php.net) wrote:
Hi,
back on reentrancy I know that with some of the libraries the extensions
depend on are not reentrant (ie. also not thread safe). The imap library cclient comes
to mind (unless something has changed recently) and I know gettext caches data in
global structu
Ok, sorry, I have been off the ZE2 list for a while (just joined back).
Where is there more info on what the type hints do in ZE2. I am curious as
I wrote the RFC.
Brian.
dealnews
- Original Message -
From: "Timm Friebe" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>
Cc: <[EMA
Well, if set_error_handler could catch E_ERROR errors (and not bail),
then errors could be changed to exceptions in user space. I already use
this in the soap library to catch invalid parameters, which I beleive
are only warnings. Not being able to catch exceptions on type hints
will make the
On Thu, 2003-03-27 at 18:32, Brian Moon wrote:
> Has type hinting for functions been implemented in ZE2?
Type hints apply to global functions just as they do for class methods.
utime= $arg < 0 ? time() : $arg;
} else {
$this->utime= strtotime($arg);
}
}
public fun
Has type hinting for functions been implemented in ZE2?
Brian.
dealnews.com
- Original Message -
From: "Timm Friebe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 27, 2003 10:16 AM
Subject: [PHP-DEV] Type hints revisited [IllegalArgumentExceptio
On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:
> At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> >I've implemented an additional feature for type hints that will throw an
> >exception instead of bailing out in case an incorrect type is passed.
> I don't see any major advantage in doing this.
H
On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:
> At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> >I've implemented an additional feature for type hints that will throw an
> >exception instead of bailing out in case an incorrect type is passed.
>
> I don't see any major advantage in doing this.
On Thu, 2003-03-27 at 18:04, George Schlossnagle wrote:
> On Thursday, March 27, 2003, at 11:58 AM, Andi Gutmans wrote:
[...]
> I think this can(all) be handled with a custom zend_error_cb anyway (in
> an extension - so that it's available only if you want it.) Looks
> really simple to implemen
On Thursday, March 27, 2003, at 11:58 AM, Andi Gutmans wrote:
At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
I've implemented an additional feature for type hints that will throw
an
exception instead of bailing out in case an incorrect type is passed.
I don't see any major advantage in doing th
At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
I've implemented an additional feature for type hints that will throw an
exception instead of bailing out in case an incorrect type is passed.
I don't see any major advantage in doing this. I think we should keep PHP
error handling the same as in PHP
Sound like a good idea to me.
Moriyoshi
"David Hill \(php.net\)" <[EMAIL PROTECTED]> wrote:
>
> Hi,
> back on reentrancy I know that with some of the libraries the extensions
> depend on are not reentrant (ie. also not thread safe). The imap library cclient
> comes to mind (unless som
Hi,
back on reentrancy I know that with some of the libraries the extensions
depend on are not reentrant (ie. also not thread safe). The imap library cclient comes
to mind (unless something has changed recently) and I know gettext caches data in
global structures (which would make me wo
I've implemented an additional feature for type hints that will throw an
exception instead of bailing out in case an incorrect type is passed.
Test script:
setLastchange(new Date());
$a->setLastchange(NULL); // Passes
$a->setCreated_at(new Date());
try {
$a->setCreated_at(NULL); //
Hi all,
while trying to understand a test failure on Tru64 I noticed that
ext/standard/parsedate.y is not reentrant. I am assuming that we do care
about this given the effort with ZTS and I care because I build Apache2
multithreaded.
I am not much of a bison expert (other than to say that
On Wed, 26 Mar 2003, Marcus Börger wrote:
>A discussion on irc (german) just reminded me of one of
>my ideas for php 5:
>
>Currently we have PHP_FE and PHP_FALIAS what about
>making another one PHP_OLD_FE which handles those
>names which are old that are incompatible with the naming
>scheme?
>
>We
Michael Sims wrote:
It's not pretty, but you might like it better than
if...elseif...else...
no, please ... as it has a much higher WTF factor ...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 2003-03-27 at 09:42, Marcus Börger wrote:
> At 19:17 26.03.2003, Martin Jansen wrote:
> >On Wed, 2003-03-26 at 15:29, Antony Dovgal wrote:
> > > I just don't see any reasons to include experimental extensions,
> > > that will cause such "security advisories", into the core distribution.
> >
At 19:17 26.03.2003, Martin Jansen wrote:
On Wed, 2003-03-26 at 15:29, Antony Dovgal wrote:
> I just don't see any reasons to include experimental extensions,
> that will cause such "security advisories", into the core distribution.
> Someone can explain this to me, maybe I'm wrong?
The plan is to
45 matches
Mail list logo
