ss->do();
---
could be made easier and more readable:
---
$class=new class;
with($class)
{
do_something();
do_more();
do();
}
---
greetings
Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
h Schindler" <[EMAIL PROTECTED]>
To: "Sebastian" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, October 10, 2007 6:08 PM
Subject: Re: [PHP-DEV] new feature -> with()
>
>> ---
>> $class=new class;
>>
>> with($class)
>&g
it would be better to remove the Boolean check feature and
make it a simple ifsetor() without the E_NOTICE again.
For those of you who have not heard of it heres an example:
Greetings
Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Plus as it is a constant it's value cannot be changed in the context of the
object.
However you could implement a method for this, e.g. get_status(); which then
returns an array. But the final keyword would be more comfortable....
"Sebastian Schneider" <[EMAIL PROT
8... just something to think about.
Regarding Rasmus' first post, I am:
+1 removal of register globals
+1 removal of magic_quotes
+1 removal of really old deprecated functions
and have nutral feelings about the rest. I'm happy with whichever
provides the most simplicity and best perfo
sson
from Perl on this one. Here is how we turn on/off warnings, lexically:
use warnings;
- sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wow, it'll be just like perl! this is so great.
On 10/28/05, James Crumpton <[EMAIL PROTECTED]> wrote:
> Andi Gutmans wrote:
> > I don't think it's a matter of giving the engine a try. I think we first
> need
> > to make a decision what the best way to go is and then we can discuss
> > impleme
Lexical variables would be nice.
On 10/28/05, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Hi Cristiano,
>
> Alex sent a patch to the list a while ago which forces the memory
> allocator to return memory to the system. However, in your case, I
> think you might be just having PHP variables "leaking".
Gutmans <[EMAIL PROTECTED]> wrote:
> What do you mean?
>
> At 06:50 PM 10/28/2005, Sebastian wrote:
> >Lexical variables would be nice.
> >
> >On 10/28/05, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > > Hi Cristiano,
> > >
> > > Ale
I still think // and //= would be the most reasonable. They involve
the least amount of syntax and // looks similar to ||
On 10/29/05, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Sara Golemon wrote:
> >>> Evaluating an idea based on it's syntactic similarities to other
> >>> languages is complete and
whoops, forgot about comments.
On 10/29/05, David Zülke <[EMAIL PROTECTED]> wrote:
> You are joking, aren't you?
>
> - David
>
>
> > -Original Message-
> > From: Sebastian [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, October 30, 2005 12
Given that // is not acceptable, as others sarcastically reminded me,
and that this introduces new sytax, I think it might be best just to
add more functions. I don't think something like
> $d = first-existing: $a, $b, $c;
is any better than first_existing($a, $b, $c), and the former happens
at t
But what about the use of ? as an infix operator? that wouldn't work
out so well because of the ternary ?:
On 10/29/05, Arpad Ray <[EMAIL PROTECTED]> wrote:
> For the assign-if-not-set operator, I like the idea of:
>
> $foo ?= 'bar';
>
> ? implies a condition, and the = immediately following will
What about a similar construct for checking truth? eg,
$foo = first_true($bar, $baz, $bang);
returns the value of the first variable that passes the if(isset($var)
&& !empty($var)) test.
On 10/31/05, Ford, Mike <[EMAIL PROTECTED]> wrote:
> On 29 October 2005 22:56, Greg Beaver wrote:
>
> > For
It's used for shell execution stuff.
Perl did something similar and quickly regretted it
On 11/28/05, Marian Kostadinov <[EMAIL PROTECTED]> wrote:
> Is ` (back quote) suitable for namespace separator? I cannot remember
> just now if it was used somewhere.
>
> 2005/11/28, Ron Korving <[EMAIL PROTE
ew
On 11/28/05, Bart de Boer <[EMAIL PROTECTED]> wrote:
> I'm sorry if I say stupid stuff. My previous post actually was the first
> post I've ever made to a newsgroup! Please bare with me while I adjust
> to the etiquettes. :)
>
> Anyway. Somebody has probably already suggested this. But how abou
> The PHP soap implementation is very fast by the way ... my benchmarks
> indicated 3-4ms request times on the LAN (without doing anything useful
> inside the request). This compares to over 30ms for the
> mod_perl/Soap::Lite implementation (and I haven't tested Java or .Net)
Can you provide code
hi,
why isn't it possible to assign class constants like this:
class test
{
const
DIR='dirname'.DIRECTORY_SEPARATOR.'anotherdirname'.DIRECTORY_SEPARATOR;
}
is there some performance issue?
anyone ever tried this or was there a discussion about it? i would find this
very useful.
hi,
PHP6 still replaces "." with an underscore in variables from outside. this
is an old behavior forced by register globals so i would say its a bug since
"." is valid in array keys.
for sample:
call a script like http://www.example.com/?my.var=1
now $_GET will look like this:
Array ( [my_v
Hi,
i just found it's really annoying that you can't throw exception in the
context of __toString(). This makes it nealy impossible to work with
__toString() because you'll have to watch not to throw exceptions (which is
even more annoying..). Could this be adressed?
Greetings
--
PHP Inte
new features its "just" an
rewrite of version 1. alas, an exception is a direct break of code
execution, so i actually cant understand the limitations. it should at least
go to next years "summer of code" of google. would be interesting.
thanks.
Sebastian
""Guilhe
On 10/16/2014 09:44 AM, Dmitry Stogov wrote:
The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
+1
I second that emotion; +1.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:/
Am 25.10.2014 um 13:00 schrieb Weinand Bob:
> It’s known that all the development currently is going on in
> krakjoe/phpdbg github repo.
Why is that, exactly? I find it weird that something that is shipped
with official releases of PHP is not developed alongside the rest of
PHP.
--
PHP Inter
Am 25.10.2014 um 20:20 schrieb Stas Malyshev:
> somewhat relaxed rules there, but even then introducing new debugging
> protocol into PHP core seems to be something that warrants some
> notification.
That would have been my next question. I think it does not only
warrant notification but adheren
Hi!
Do we have a page that lists the versions of PHP that are currently
supported and when their support expires? If not, why not?
What I am looking for is basically a page that lists the information
shown in the examples used in https://wiki.php.net/rfc/releaseprocess
Thanks!
Sebastian
On 10/27/2014 10:45 AM, Peter Cowburn wrote:
> The closest we have, at the moment, is probably http://php.net/eol.php
> which details the versions which are no longer supported.
We need the inverse of that :)
> Good question.
Should we start http://php.net/supported-versions.php then?
--
PHP
On 10/27/2014 10:48 AM, Andrea Faulds wrote:
> We should copy it.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10/28/2014 03:35 AM, Trevor Suarez wrote:
> Great job on this Adam. You whipped this up pretty quickly and it looks
> good!
I second that emotion: great work, Adam! Thank you for your work!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
>
The example is a little bit misleading: Instead of a new concept you can
use functions, right?
Regards,
Sebastian
> My motivation is to further expand class support to add modifiers (PPP -
> public, protected, private). I added this change to initially segregate
> grammar rules. I
2014-11-28 2:13 GMT+01:00 Bostjan Skufca :
> Hello everyone,
>
> this is a proposal to add new function to PHP core: spl_object_id()
>
>
> The story:
>
> Recently I was debugging some larger libraries and sorely missed a function
> that would return an object ID. A function called spl_obj
good situation to be incompatible
with current versions of essential tools such as bison.
Best,
Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
$ git status
On branch PHP-5.6
Your branch is up-to-date with 'origin/PHP-5.6'.
nothing to commit, working directory clean
$ ./configure --disable-all
.
.
.
Thank you for using PHP.
config.status: error: cannot find input file: `php7.spec.in'
$ git status
On branch PHP-5.6
Your bran
Am 12.12.2014 um 09:47 schrieb Julien Pauli:
> In the worst scenario, there is also: downgrade your Bison.
I have done that for now, of course. What worries me is the reliance
on outdated and unsupported tools.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Am 14.12.2014 um 19:35 schrieb Andrea Faulds:
> Thoughts?
+1 for consistency :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 17.12.2014 um 15:54 schrieb Zeev Suraski:
> I’m opposed to having a 5.7 release that has new features on
> top of 5.6.x.
Same here; 5.7 should only add deprecations etc. and must not add new
features.
> I also think we should minimize any new work on 5.6.x as much as
> possible, and focus al
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
> bugs going as far back as to PHP4.
Bug reports for PHP version that are not supported anymore [1]
should IMHO be bulk-closed. The message should ask to reopen if
the bug is reproducible with a supported version of PHP. IMHO :)
--
[1] htt
Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
> Parameter type hints for PHP’s scalar types
Please use the term "type declaration for arguments" (or "type
declaration for parameters") instead of "type hints". If it's used
then it's not a hint.
--
PHP Internals - PHP Runtime Development Maili
Am 25.08.2014 um 19:39 schrieb Nikita Popov:
> I don't know if I will be implementing that ext myself. In any case, before
> that can happen I will have to create another RFC for converting parse
> errors into exceptions and making sure we don't leak memory on failed parse
> - I think thats a prere
Am 11.01.2015 um 09:03 schrieb Ferenc Kovacs:
> There is https://github.com/nikic/php-ast
Aha! Thanks for the pointer, Ferenc. Can we get this bundled with
PHP 7 (and enabled by default)?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
Am 17.01.2015 um 15:02 schrieb Dan Ackroyd:
> class constructors
PHP does not have class constructors (static method automatically
invoked when a class is initialized). It only supports object
constructors (method automatically invoked when an object is
created).
> Several classes in PHP
Am 18.01.2015 um 09:40 schrieb Matteo Beccati:
> what's the plan, if any?
Remove it?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 19.01.2015 um 10:49 schrieb Dmitry Stogov:
> Despite of PEAR, I also found few other apps, from my usual test list,
> broken - Typo3, Xoops, SugarCRM.
> Magento is broken long time ago by "unified variable syntax".
The vendors of these applications have time to become compatible
with PHP 7 un
Am 19.01.2015 um 10:49 schrieb Dmitry Stogov:
> Despite of PEAR, I also found few other apps, from my usual test list,
> broken - Typo3, Xoops, SugarCRM.
> Magento is broken long time ago by "unified variable syntax".
The vendors of these applications have time to become compatible
with PHP 7 un
Am 19.01.2015 um 07:58 schrieb Stanislav Malyshev:
> Can't we just fix it? As I understand, it's just making this:
>
> function initializeConfig(&$config)
>
> into this:
>
> static function initializeConfig(&$config)
>
> In PEAR/Installer/Role.php but I'm not sure where to commit the pa
Am 19.01.2015 um 17:42 schrieb Tony Marston:
> has already been pointed out that there are a large number of PEAR
> libraries which were written with PHP 4 constructors and have never been
> updated.
So? If that code is still valuable to people they will update it. Or
rather would have updated i
Am 21.01.2015 um 20:39 schrieb Rasmus Lerdorf:
> Log:
> Slightly modify and merge PR#105 from @MegaManSec
>
> Bugs:
> https://bugs.php.net/105
I think the commit email script needs to be updated to handle PR#NNN
"links".
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Am 22.01.2015 um 18:05 schrieb Rasmus Lerdorf:
> It would be really useful if we got more eyes on this. Install php7,
> then install any random app and see how it goes.
It's even easier to check whether a component or framework has issues
with PHP 7: simply run the respective test suite with PHP
Nut sure whether this is an issue or not but I see it a lot while
compiling master:
Zend/zend_alloc.h:57:236: warning: unknown attribute 'alloc_size'
ignored [-Wunknown-attributes]
__attribute__ ((visibility("default"))) void* _emalloc(size_t size,
const char *__zend_filename, const
Am 25.01.2015 um 17:17 schrieb Andi Gutmans:
> Can you provide more info re: operating system and version?
> Compiler version?
$ cat /etc/issue
Fedora release 21 (Twenty One)
$ clang --version
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
Am 26.01.2015 um 11:14 schrieb Ferenc Kovacs:
> Commit:cfd7f5c8a3745097e0c3c3e627f6df10f2a2acdf
> Author:Ferenc Kovacs Mon, 26 Jan 2015 11:09:53
> +0100
> Parents: 8aa146b810108bde3353d9d2f8cf05a9dd012f6d
> Branches: master
>
> Link:
> http://git.php.net/?p=php-src.git;
Am 26.01.2015 um 11:31 schrieb Tony Marston:
>> PHP 7 would be a good time to cut the ties between the PHP core
>> and PEAR. Why not get rid of it completely?
>
> Because a lot of sites still use it, and you haven't provided an
> alternative which allows modules be to added/updated/deleted through
Am 26.01.2015 um 13:51 schrieb Ferenc Kovacs:
> and bundling our own installer is only temporary, as I mentioned in the PR
> probably there will be more BC breaks until php7 is frozen, and it would
> be clunky if we have to always wait for the official PEAR release so that
> the pear installer of t
Am 26.01.2015 um 13:56 schrieb Lester Caine:
> how would YOU propose to replace it?
I am not talking about replacing but removing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 26.01.2015 um 18:03 schrieb Ferenc Kovacs:
> imo we can't ship php without a tool to install additional pecl
> extensions.
I disagree and would argue that most people do not want to build
extensions themselves and instead prefer binary packages provided by
their OS distribution.
But even i
Am 27.01.2015 um 07:40 schrieb Matteo Beccati:
> The warning is certainly annoying, but making it default to UTC or a wrong
> timezone because the right one can't be guessed is a major WTF.
Couldn't agree more; -1 for removing the warning.
--
PHP Internals - PHP Runtime Development Mailing List
Am 27.01.2015 um 10:00 schrieb Lester Caine:
> composer has not even managed to get added to some distributions yet
This is not about PEAR Installer vs. Composer or something else. This
is about the PHP core getting untangled from third-party software that
impedes the development of PHP itself.
Am 27.01.2015 um 10:52 schrieb Lester Caine:
> On 27/01/15 09:42, Sebastian Bergmann wrote:
>> PEAR has served its purpose, it provided value for the PHP
>> ecosystem for a time, but now it should be retired.
>
> So what happens to http://pear.php.net ?
That is a good q
Am 27.01.2015 um 21:13 schrieb Pierre Joye:
> However there is one thing we do need to care, and this is 3rd party
> extensions. This is all I care about and why I initiated pickle.
It just that I am not convinced that the problem you are trying to solve
with a tool such as pickle exists. From m
Am 04.02.2015 um 06:44 schrieb Dmitry Stogov:
> What do you think about using only lowercase type names for scalar type
> hints? In this case we won't have to introduce any limitations.
This would be inconsistent with the rest of PHP being case-insensitive
and only lead to confusion.
--
PHP I
Am 04.02.2015 um 08:25 schrieb Dmitry Stogov:
> The idea of that RFC was an ability to have zero-cost assert().
But an assert() is still in the body of a function or method and
not part of its signature. That is what I want scalar type
declarations for.
--
PHP Internals - PHP Runtime Develop
Am 04.02.2015 um 10:25 schrieb Dmitry Stogov:
> Do you like the proposal with declare() switch?
No, I do not like that.
We are talking about adding support for scalars (string, integer, ...)
to the list of optional type declarations already supported (array,
callable, interface name, class na
On 02/04/2015 04:32 PM, Dan Ackroyd wrote:
> btw For your exact example `sin((float)$x).` this is actually a case
> where another scalar type of 'number' which is satisfiable by either a
> float or an int would be useful, but that's definitely a step too far
> before we have any scalar type hints.
On 02/06/2015 10:22 PM, Nikita Popov wrote:
> After much initial reluctance, I've voted in favor of this RFC.
After reading your email, Nikita, I deleted my vote (it was no before).
I will review the RFC again, with your arguments (and others) in mind
and maybe I'll come to a different conclusi
Am 07.02.2015 um 02:08 schrieb Sebastian Bergmann:
> After reading your email, Nikita, I deleted my vote (it was no before).
> I will review the RFC again, with your arguments (and others) in mind
> and maybe I'll come to a different conclusion.
I have voted (no) again.
I still
Am 09.02.2015 um 15:50 schrieb Pierre Joye:
> Not strict? You loose me here.
I want support for scalar types in signatures. I want these type
declarations to be strictly enforced. This is not wanted and not
proposed by the RFC. Hence my vote.
--
PHP Internals - PHP Runtime Development Mailing
Am 17.02.2015 um 10:51 schrieb Lester Caine:
> It seems not even running distclean clears down everything that needs
> removing for some of the changes currently going through. ./vcsclean
I stopped using distclean / vcsclean a while ago. "git clean -xdf"
does the trick for me.
--
PHP Internals
While working on PHPUnit today I noticed one test of its own test
suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
this can be found at
https://github.com/sebastianbergmann/phpunit/issues/1630
Florian Margaine reduced the problem to the following minimal,
self-contained
Am 27.02.2015 um 09:14 schrieb Remi Collet:
> Hmmm http://3v4l.org/QST64
No clue why PHP 5.6.5 seems to have worked for that reproducing script
here earlier. Tried it again and, of course, it also fails with "my"
PHP 5.6.5.
Looks the like the reproducing script was not the right one. :-/
--
Am 27.02.2015 um 09:30 schrieb Xinchen Hui:
> maybe related to your own build?
The test in the PHPUnit test suite fails with
PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with Xdeb
Am 27.02.2015 um 09:53 schrieb Xinchen Hui:
> I noticed different version of xdebug, could you try without it?
Thank you for bringing Xdebug to my attention. You are right, it
appears to be related to Xdebug.
Without Xdebug
$ php -v
PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29)
Copyr
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
> Voting on the engine exceptions RFC, which proposes to convert existing
> fatal and recoverable fatal errors into exceptions, has opened:
>
> https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
>
> The primary vote requires a 2/3 majority, a
Am 27.02.2015 um 16:12 schrieb Anthony Ferrara:
> Thank you for sharing your code. I look forward to playing with it.
>
> Perhaps after 7 stabilizes (and ships) you could write up your
> thoughts around it? Why decisions were made and the findings that you
> have?
What Joe and Anthony said :-) T
Am 27.02.2015 um 01:29 schrieb Matthew Weier O'Phinney:
> - PHPUnit passes a boolean false to `debug_backtrace()`... which is documented
> as expecting an integer! (There are actually several constant values it
> accepts, all of which are integer values.) In this case, PHPUnit is relying
> on
Am 28.02.2015 um 01:57 schrieb Larry Garfield:
> The RFC is currently in voting, so editing it directly is a no-no. A new,
> short RFC, please. (Exception implements Throwable, Error implements
> Throwable sounds good to me. Should we ask about SomeUserspaceClass
> implements Throwable, or will
Am 04.03.2015 um 09:52 schrieb Nikita Popov:
> So, tl;dr: I think the patch is too risky. Even if we can make sure that
> we've covered all the current edge-cases and don't regress anything, I'm
> afraid that this will cause complications with future changes. This ends up
> replicating too many par
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
> Voting is open until 2015-03-08.
Voting ends today and it looks like the RFC will be accepted. How
should we proceed with regards to the comments I made in
Message-ID: <54f07fc7.8050...@php.net>
Date: Fri, 27 Feb 2015 15:31:35 +0100
Guilher
Am 09.03.2015 um 09:44 schrieb Matteo Beccati:
> I like the approach. I'm no lexer expert but the new PR seems much nicer.
> Moreover, I like the feature itself but previously voted no on the
> implementation. I've therefore switched my vote to a "yes".
Dito.
--
PHP Internals - PHP Runtime Deve
Am 09.03.2015 um 12:40 schrieb Dan Ackroyd:
> So even though I hope we can clean up the exception hierarchy, merging
> the engine exceptions is the right choice imo.
Sounds reasonable to me. I'm wondering, though, whether we really need
an additional RFC for the change I suggested as nobody spok
Am 27.02.2015 um 15:47 schrieb Jordi Boggiano:
> quickly draft another RFC to amend that part
So who will draft the RFC for
* Introduce a Throwable interface
* Let Exception implement the Throwable interface
* Introduce an Error class that implements the Throwable interface
* Use Err
Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann:
> So who will draft the RFC for
>
>* Introduce a Throwable interface
>* Let Exception implement the Throwable interface
>* Introduce an Error class that implements the Throwable interface
>* Use Error class
What is the minimum version of GCC required to build PHP?
I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related
to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann:
> I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related
> to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA).
Over in Room 11, Michael just pointed out that this could be related
to php_stdint.h.
--
PHP Int
Am 15.03.2015 um 16:36 schrieb Sebastian Bergmann:
> Over in Room 11, Michael just pointed out that this could be related
> to php_stdint.h.
Okay, this does not seem to be related to the GCC version but rather
to the fact that some int types etc. are not defined on/for my platform.
If
Am 16.03.2015 um 07:41 schrieb Xinchen Hui:
> what is the link problems?
http://pastebin.com/Tk1kaipQ
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, April 17, 2007 9:55 am, Dmitry Stogov wrote:
> The float formatting algorithms were changed because of
> licensing issues and new ones are not 100% compatible with
> previous ones.
Could you please provide more details on that?
- Sebastian
--
PHP Internals - PHP Runtime De
e that raised
this discussion shows.
- Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on exakt the same
machine with different PHP versions and I get different results with
these different versions, I expect that to be documented.
Best regards,
Sebastian Nohn
--
Sebastian Nohn · Wolfstraße 29 · 53111 Bonn · Germany
+49-170-4718105 · http://nohn.net/ · [EMAIL PROTEC
Dmitry Stogov wrote:
> It is bad practice to use echo $float or var_dump($float)
> because they depends on php.ini settings.
> You should use printf() of number_format() for deterministic result.
PHP 5.2.1:
-1689934592
2147483647
PHP 5.2.2:
-1689934592
6
- Sebastian
--
PHP
Antony Dovgal wrote:
> On 04/17/2007 10:16 PM, Sebastian Nohn wrote:
>> Dmitry Stogov wrote:
>>
>>> It is bad practice to use echo $float or var_dump($float)
>>> because they depends on php.ini settings.
>>> You should use printf() of number_format() for d
Sebastian Nohn wrote:
> $c = $a."";
> $d = (string)$a;
Forget that.
- Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
On Thu, April 19, 2007 11:33 am, Antony Dovgal wrote:
> On 04/15/2007 11:05 AM, Sebastian Nohn wrote:
>> > $a = 69;
>> var_dump($a);
>> $b = "A is: ".$a;
>> var_dump($b);
>> ?>
>>
>> 5.2.1 output is:
>>
>>
he former) would be usefull, IMHO.
--
Sebastian Bergmann http://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
k that this commit is responsible for
http://bugs.php.net/bug.php?id=41361.
--
Sebastian Bergmann http://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, visi
confirm that segfault?
Best regards,
Sebastian Nohn
--
Sebastian Nohn · Wolfstraße 29 · 53111 Bonn · Germany
+49-170-4718105 · http://nohn.net/ · [EMAIL PROTECTED]
http://pgpkeys.pca.dfn.de:11371/pks/lookup?op=get&fingerprint=on&search=0xD47D55E0
--
PHP Internals - PHP Runtime Development
Wez Furlong wrote:
> I'm going to say it one last time: there are other maintainers.
> I'm temporarily too busy, but we have other maintainers.
> Please assign bugs to the other maintainers.
Maybe per-extension aliases (such as [EMAIL PROTECTED]) could
help here? This way it would be possible to
Stut wrote:
> This thread has nothing to do with me, (except with regards to my
> interest in PHP6) but in my experience when a task is assigned to a
> group not an individual there is no accountability and no incentive to
> either get it done or pass it to someone who can. IMHO it's better to
> le
Antony Dovgal wrote:
> On 19.05.2007 14:27, Sebastian Nohn wrote:
>> Hi,
>>
>> I currently get segfaults with 5.2.3-dev when running the the Zend
>> Framework
>> 0.8.0 Unit Tests:
>>
>> ok 1860 - testHandleAnonymousArgFunction(Zend_Rest_Server
Antony Dovgal wrote:
>>> Any chance to get GDB backtrace?
>
> Aha.. I see..
> Could you please try the patch attached?
Works.
Best regards,
Sebastian Nohn
--
Sebastian Nohn · Wolfstraße 29 · 53111 Bonn · Germany
+49-170-4718105 · http://nohn.net/ · [EMA
Antony Dovgal wrote:
> On 20.05.2007 12:15, Sebastian Nohn wrote:
>> Antony Dovgal wrote:
>>
>>>>> Any chance to get GDB backtrace?
>>>
>>> Aha.. I see..
>>> Could you please try the patch attached?
>>
>> Works.
>
&g
Antony Dovgal wrote:
> Hello Sebastian.
Hello Antony,
> What's the status of this?
> Do you have anything working?
back in February/March when I first posted about this, I discussed this
with Marcus. The conclusion was that we wanted to rewrite run-tests.php
based on the Itera
1 - 100 of 1415 matches
Mail list logo
