Rasmus Schultz wrote:
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?
Rasmus
Something that is also worth bearing in min
Stas Malyshev 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 way it is. I was answering the ops question. Please read
On Fri, Sep 7, 2012 at 3:09 AM, Rasmus Schultz 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) of FreeType?
Hi,
On Fri, Sep 7, 2012 at 2:49 AM, Yahav Gindi Bar wrote:
> On Fri, Sep 7, 2012 at 3:41 AM, Stas Malyshev wrote:
>
>> 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.
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 bui
On Thu, Sep 6, 2012 at 9:00 PM, Stas Malyshev 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 way it is. I
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 be
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 discussio
On Fri, Sep 7, 2012 at 3:41 AM, Stas Malyshev wrote:
> 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 un
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
On Thu, Sep 6, 2012 at 8:37 PM, Stas Malyshev 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 bother using th
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,
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
On Fri, Sep 7, 2012 at 3:21 AM, Levi Morrison wrote:
> On Thu, Sep 6, 2012 at 6:15 PM, Sherif Ramadan
> wrote:
> > On Thu, Sep 6, 2012 at 5:30 PM, Mark wrote:
> >> Hi,
> >>
> >> I was just using the PHP namespaces for the first time and noticed a
> >> difference that i really didn't expect. (No,
On Thu, Sep 6, 2012 at 6:15 PM, Sherif Ramadan wrote:
> On Thu, Sep 6, 2012 at 5:30 PM, Mark 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).
>>
>
On Thu, Sep 6, 2012 at 5:30 PM, Mark 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 use all me
On Thu, Sep 6, 2012 at 2:43 PM, Kris Craig wrote:
> On Tue, Sep 4, 2012 at 12:15 AM, Stas Malyshev >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.go
On Tue, Sep 4, 2012 at 12:15 AM, Stas Malyshev 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
>
> It talks about
On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev 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
> write add-on tools to
On Thu, Sep 6, 2012 at 3:32 PM, Tom Boutell 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 documentation the
hi Rasmus,
On Thu, Sep 6, 2012 at 2:07 PM, Rasmus Schultz 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 real drawing c
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
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 t
> 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 SessionHandl
On Tue, Sep 4, 2012 at 1:15 AM, Stas Malyshev 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
>
> It talks abou
On Thu, Sep 6, 2012 at 2:53 PM, Sebastian Bergmann wrote:
> 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,
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 r
2012/9/6 Jannik Zschiesche :
> 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 S
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
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?
G
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
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 wrote:
I opened this bug report 2 years ago:
https://bugs.php.net/bug.ph
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
Stas,
On Thu, Sep 6, 2012 at 5:25 AM, Stas Malyshev 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
Stas Malyshev 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 way".
>
>I
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 get
On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev wrote:
> 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 par
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 (cano
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 imp
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
third-pa
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 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 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 ca
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 hack
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
wi
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 eas
Hi,
On Sep 6, 2012, at 1:24, Daniel Convissor
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.
>>
>>The serv
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 nothing
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
49 matches
Mail list logo
