On 05/09/12 18:59, Andrew Faulds wrote:
On 05/09/12 13:48, Morgan L. Owens wrote:
I'm not a core dev, but I would like to add to the notes above that
third parties, such as myself, who want to do things with PHP
source other than run it through a PHP interpreter would also
appreciate such a
Stas Malyshev wrote:
Given many discussions on the list about changing stuff in PHP, I'd like
to bring everybody's attention to comment by Linus Torvalds in this
topic:https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk
It talks about Linux kernel and discussion has next to
Hi,
On Sep 6, 2012, at 1:24, Daniel Convissor dani...@analysisandsolutions.com
wrote:
Hi Johannes:
On Thu, Jan 19, 2012 at 01:50:47PM +0100, Johannes Schlüter wrote:
unsigned long length
The width of the field. This corresponds to the display length,
in bytes.
Hi Dmitry,
On 06/09/12 07:37, Dmitry Stogov wrote:
Hi Nikita,
Personally, I don't see any reason to build AST. As you mentioned
yourself, it will be slower and will require more memory. On the other
hand AST itself would allow to perform only very basic optimizations.
Most of them can be
Hi
The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks, it
Hi!
The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks,
On 06/09/12 10:11, Stas Malyshev wrote:
Hi!
The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode
On 09/06/2012 06:37 AM, Dmitry Stogov wrote:
The only real advantage could be an ability to expose AST to PHP scripts,
but only few people may need it.
Everyone working on static analysis tools for PHP code needs access to
the (canonical) AST. While the number of people behind this everyone
On 2012-09-06 10:39, Stas Malyshev wrote:
Hi!
... and no real
benefit for average PHP user.
Well, apart from perhaps leaving them with a simpler language that
doesn't have the inconsistencies and corner cases that currently exist
(and documented ad nauseum) not because of any design decision
On 09/06/2012 09:11 AM, Stas Malyshev wrote:
As for third-party tools, I do not see why third-party tools need PHP
to change the parser. If PHP's parser is not good enough for those tools,
they can have their own parser.
Nikita is doing an amazing job with PHP_Parser, which is such a
Hi!
Nikita is doing an amazing job with PHP_Parser, which is such a
third-party tool. However, it will always lag behind the canonical
parser. And it will (probably) never match 100% the behavior of the
canonical parser.
Wait, so the arguments that it will be amazingly easy to
On 09/06/2012 10:47 AM, Sebastian Bergmann wrote:
On 09/06/2012 06:37 AM, Dmitry Stogov wrote:
The only real advantage could be an ability to expose AST to PHP scripts,
but only few people may need it.
Everyone working on static analysis tools for PHP code needs access to
the (canonical)
On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Nikita is doing an amazing job with PHP_Parser, which is such a
third-party tool. However, it will always lag behind the canonical
parser. And it will (probably) never match 100% the behavior of the
Hi!
Well, apart from perhaps leaving them with a simpler language that
doesn't have the inconsistencies and corner cases that currently exist
(and documented ad nauseum) not because of any design decision but
because the parser is written that way.
If you think writing new parser gets rid
Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Well, apart from perhaps leaving them with a simpler language that
doesn't have the inconsistencies and corner cases that currently
exist
(and documented ad nauseum) not because of any design decision but
because the parser is written that
Stas,
On Thu, Sep 6, 2012 at 5:25 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Well, apart from perhaps leaving them with a simpler language that
doesn't have the inconsistencies and corner cases that currently exist
(and documented ad nauseum) not because of any design decision
I opened this bug report 2 years ago:
https://bugs.php.net/bug.php?id=52756
Is GD still actively maintained?
If it isn't, then perhaps it's time to start thinking about switching to a
graphics library that is maintained?
Perhaps something more modern with real drawing capabilities and a better
I briefly asked Pierre about a feature in it recently. By the sounds of it, it
is being actively maintained, albeit perhaps slowly.
--
Sent from my Android phone with K-9 Mail.
Andrew Faulds
http://ajf.me/
Rasmus Schultz ras...@mindplay.dk wrote:
I opened this bug report 2 years ago:
On 09/06/2012 10:15 AM, Ferenc Kovacs wrote:
I propose putting together and RFC and a PoC ASAP, and then we can talk
about facts instead of opinions and biased views on the topic.
That would be the reasonable thing to do, yes. But that is easy for me
easy to say as I will not be able to help
Hi, Rasmus,
Just wanted to note that I've tested your script from
http://fontjazz.com/metrics/test.php and couldn't reproduce the bug.
I'm on the Ubuntu 12.04 with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch
Have you tried upgrading your FreeType library and recompiling latest
stable PHP with it?
Am Donnerstag, 6. September 2012 um 15:05 schrieb Alexey Shein:
Hi, Rasmus,
Just wanted to note that I've tested your script from
http://fontjazz.com/metrics/test.php and couldn't reproduce the bug.
I'm on the Ubuntu 12.04 with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch
Have you tried
2012/9/6 Jannik Zschiesche he...@apfelbox.net:
Am Donnerstag, 6. September 2012 um 15:05 schrieb Alexey Shein:
Hi, Rasmus,
Just wanted to note that I've tested your script from
http://fontjazz.com/metrics/test.php and couldn't reproduce the bug.
I'm on the Ubuntu 12.04 with PHP
The good news is that gd is pretty moribund, there isn't a lot to
maintain. But things do come up.
libgd.org has been displaying the same oops crap something happened
notice for... three years? At least? If there is no momentum to fix
that, as the original developer of gd I would be willing to
On Thu, Sep 6, 2012 at 2:53 PM, Sebastian Bergmann sebast...@php.netwrote:
On 09/06/2012 10:15 AM, Ferenc Kovacs wrote:
I propose putting together and RFC and a PoC ASAP, and then we can talk
about facts instead of opinions and biased views on the topic.
That would be the reasonable thing
On Tue, Sep 4, 2012 at 1:15 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Given many discussions on the list about changing stuff in PHP, I'd like
to bring everybody's attention to comment by Linus Torvalds in this
topic: https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk
Basically we shouldn't break any interfaces that are user-facing but
we are free to change things internally as much as we want as long as the
external interface is honored.
So how do you actually go about adding a feature that requires an
interface change?
Take for example the SessionHandler
On Thu, 2012-09-06 at 09:47 +0100, Sebastian Bergmann wrote:
On 09/06/2012 06:37 AM, Dmitry Stogov wrote:
The only real advantage could be an ability to expose AST to PHP scripts,
but only few people may need it.
Everyone working on static analysis tools for PHP code needs access to
On 09/06/2012 11:52 AM, Ivan Enderlin @ Hoa wrote:
Hi Dmitry,
On 06/09/12 07:37, Dmitry Stogov wrote:
Hi Nikita,
Personally, I don't see any reason to build AST. As you mentioned
yourself, it will be slower and will require more memory. On the other
hand AST itself would allow to perform only
hi Rasmus,
On Thu, Sep 6, 2012 at 2:07 PM, Rasmus Schultz ras...@mindplay.dk wrote:
I opened this bug report 2 years ago:
https://bugs.php.net/bug.php?id=52756
Is GD still actively maintained?
yes. Slowly but yes, we will finally merge 2.1 in 5.5 too.
Perhaps something more modern with
On Thu, Sep 6, 2012 at 3:32 PM, Tom Boutell t...@punkave.com wrote:
libgd.org has been displaying the same oops crap something happened
notice for... three years? At least? If there is no momentum to fix
that, as the original developer of gd I would be willing to restore
the classic gd
On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
And if it's impossible to match behavior of the existing parser - do I
get it right that the proposed idea is to actually break real code that
people run now in PHP because it was too hard to parse for people that
On Tue, Sep 4, 2012 at 12:15 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Given many discussions on the list about changing stuff in PHP, I'd like
to bring everybody's attention to comment by Linus Torvalds in this
topic: https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk
On Thu, Sep 6, 2012 at 2:43 PM, Kris Craig kris.cr...@gmail.com wrote:
On Tue, Sep 4, 2012 at 12:15 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Given many discussions on the list about changing stuff in PHP, I'd like
to bring everybody's attention to comment by Linus Torvalds
On Thu, Sep 6, 2012 at 5:30 PM, Mark mark...@gmail.com wrote:
Hi,
I was just using the PHP namespaces for the first time and noticed a
difference that i really didn't expect. (No, i won't start complaining
about the slash based namespace).
In C++ when you type:
using std;
Then you can
On Thu, Sep 6, 2012 at 6:15 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
On Thu, Sep 6, 2012 at 5:30 PM, Mark mark...@gmail.com wrote:
Hi,
I was just using the PHP namespaces for the first time and noticed a
difference that i really didn't expect. (No, i won't start complaining
about
On Fri, Sep 7, 2012 at 3:21 AM, Levi Morrison morrison.l...@gmail.comwrote:
On Thu, Sep 6, 2012 at 6:15 PM, Sherif Ramadan theanomaly...@gmail.com
wrote:
On Thu, Sep 6, 2012 at 5:30 PM, Mark mark...@gmail.com wrote:
Hi,
I was just using the PHP namespaces for the first time and noticed
Hi!
Yes, PHP namespaces are completely different from what you'd be used
to in C++. In all honesty namespaces were never well designed in PHP
and were implemented in a haphazard way, which is why I generally
don't bother using them.
I just love how people assume if something does not fit
Hi!
How about adding ability to import the entire namespace?
This option was explicitly excluded because this defeats the whole idea
of having namespaces - i.e. having names to live in different spaces -
by explicitly bringing unknown set of names into global space. If you
allow global import,
On Thu, Sep 6, 2012 at 8:37 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Yes, PHP namespaces are completely different from what you'd be used
to in C++. In all honesty namespaces were never well designed in PHP
and were implemented in a haphazard way, which is why I generally
don't
Hi!
In C++ when you type:
using std;
Then you can use all methods/classes/whatever is defined in std
without typing std.
so: std::cout becomes just cout.
PHP namespaces do not work like that. In PHP, namespace is a permanent
part of the class/function name. All namespace translations are
On Fri, Sep 7, 2012 at 3:41 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
How about adding ability to import the entire namespace?
This option was explicitly excluded because this defeats the whole idea
of having namespaces - i.e. having names to live in different spaces -
by
Hi!
That's true, but we do got the ability to import only one class from
given namespace and classes aliasing so we can, for example, do
something like:
When you import one name, you see this name in import statement. It's
explicit. Global imports are not.
I really hate to rehash discussion
Hi!
I wasn't assuming. I was outright making a factual statement. I never
made any implications of the intellectual levels of those implementing
the spec. I understand the RFC full well and know why the design is
the way it is. I was answering the ops question. Please read what I
said before
On Thu, Sep 6, 2012 at 9:00 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I wasn't assuming. I was outright making a factual statement. I never
made any implications of the intellectual levels of those implementing
the spec. I understand the RFC full well and know why the design is
the
Jannik,
Thank you - this confirms I'm not crazy, or at least it's evidence to
support that theory ;-)
It may be OS specific - perhaps the Windows and OSX binaries are built
against a different build (or configuration) of FreeType?
Or it could be specific to 32 or 64 bit builds.
I have never
Hi,
On Fri, Sep 7, 2012 at 2:49 AM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
On Fri, Sep 7, 2012 at 3:41 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
How about adding ability to import the entire namespace?
This option was explicitly excluded because this defeats the whole idea
On Fri, Sep 7, 2012 at 3:09 AM, Rasmus Schultz ras...@mindplay.dk wrote:
Jannik,
Thank you - this confirms I'm not crazy, or at least it's evidence to
support that theory ;-)
It may be OS specific - perhaps the Windows and OSX binaries are built
against a different build (or configuration)
47 matches
Mail list logo
