Thanks.
How can I valgrind my extension? Google isn't bringing up many php
extension topics :/
I can't figure out why I keep getting a seg fault:
typedef struct _foo_object {
zend_object std;
zval *elements;
} foo_object;
static foo_object *foo_object_ptr;
PHP_MINIT_FUNCTION(foo_class)
{
Hi,
2012/4/6 Johannes Schlüter :
> P.P.S. Would anybody mind if we drop TSRM/ZTS? :-)
Ubuntu users and Apache 2.4 users may.
It is working although I prefer non-ZTS.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
2012/4/8 Ángel González :
> On 07/04/12 22:48, Yasuo Ohgaki wrote:
>> Hi,
>>
>> The only valid reason for removing > security.
>>
>> Since the null byte detection for fopen, remote/local script inclusion
>> became much harder than before. However, it's still possible and very
>> easy compare to oth
hi：
You can refer to ext spl array
Thanks
Sent from my iPhone
在 2012-4-8，7:12，Matthew Hernandez 写道：
> Here's what I have so far:
>
> typedef struct _foo_class_object {
> zend_object std;
> zval *elements;
> int size;
> } foo_class_object;
>
> static foo_class_object *foo_class_object_ptr;
>
Hi!
> I have exposed ICU's Calendar API to PHP via the intl extension. It allows
> date calculations with Gregorian, Chinese, Coptic, Ethiopic, Hebrew,
> Indian, Islamic (civil/religious), Japanese, Persian, Taiwan and Thai
> Buddhist calendars. For a broader overview of its functionality, s
Here's what I have so far:
typedef struct _foo_class_object {
zend_object std;
zval *elements;
int size;
} foo_class_object;
static foo_class_object *foo_class_object_ptr;
static zend_class_entry *foo_class_ptr;
ZEND_METHOD(foo_class, __construct) {
foo_class_object_ptr = (foo_class_obj
While anything even resembling censorship naturally makes me cringe, it is
a reasonable expectation I think that this list be a place where people can
suggest ideas without being called "stupid" and childishly berated.
Bullying, it could be argued, is also a form of censorship.
So despite my insti
On 07/04/12 22:48, Yasuo Ohgaki wrote:
> Hi,
>
> The only valid reason for removing security.
>
> Since the null byte detection for fopen, remote/local script inclusion
> became much harder than before. However, it's still possible and very
> easy compare to other languages. Script execution is cr
Hi Johannes,
Yes I just found out that I should extend instead of the approach I was
thinking about.
So I created this:
typedef struct _foo_object {
zend_object std;
zval *array;
int size;
} foo_object;
So the question is how do I correctly pass foo_object around so that I can
manipulate
Hi,
On Sat, 2012-04-07 at 11:23 -0700, Matthew Hernandez wrote:
> This is my first extension I'm working on. I'm trying to make a class
> available to the user space with 1 private property that is an array.
The first question is: Why? - Why add the overhead of creating such an
array if it is pri
Hi,
The only valid reason for removing :
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doesn't change.
On 04/07/2012 01:07 PM, Ángel González wrote:
> On 07/04/12 19:29, Rasmus Lerdorf wrote:
>> On 04/07/2012 10:23 AM, Ángel González wrote:
>>
>>> And I like the idea of providing a function for auto escaping > Turn on your default input filter and all data that comes from the user
>> will automatica
On 07/04/12 19:29, Rasmus Lerdorf wrote:
> On 04/07/2012 10:23 AM, Ángel González wrote:
>
>> And I like the idea of providing a function for auto escaping Turn on your default input filter and all data that comes from the user
> will automatically be escaped.
>
> -Rasmus
I'm not interested in fil
It's probably worth mentioning, to be fair to Reindl, that he can no longer
respond publically to this list..
Thanks,
Kiall
Sent from my phone.
On Apr 7, 2012 8:07 p.m., "Maciek Sokolewicz"
wrote:
> On 07-04-2012 03:10, John Crenshaw wrote:
>
> Seriously, if you're so angry that you can't even
I will. And thanks for your work maintaining gd- I should have mentioned that
earlier.
Sent from my iPhone
On Apr 7, 2012, at 12:47 PM, Pierre Joye wrote:
> hi Tom,
>
>
> On Sat, Apr 7, 2012 at 3:26 PM, Tom Boutell wrote:
>> Now that the flamewar has died down a little I'd like to try to ha
On 07-04-2012 03:10, John Crenshaw wrote:
Seriously, if you're so angry that you can't even type straight you should take
a break before responding. Any argument delivered like this won't be well
received anyway. Take a break, find your place of zen, respond when you can be
civil.
Do you ha
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote:
> On Sat, Apr 7, 2012 at 6:51 PM, Luke Scott wrote:
>
>> I think I understand what you're getting at. So to avoid fragmentation
>> you would have to have two independent memory spaces. Making non
>> persistent memory persistent would require copyin
On Sat, Apr 7, 2012 at 6:51 PM, Luke Scott wrote:
> I think I understand what you're getting at. So to avoid fragmentation
> you would have to have two independent memory spaces. Making non
> persistent memory persistent would require copying from one space to
> another. Is that correct?
Yes, th
On Apr 7, 2012, at 15:26, Tom Boutell wrote:
> * If the CLI sees a .phpc file extension, the parser starts out in PHP
> mode (no opening into HTML mode after that with ?>.
>
> * If a require/include statement sees a .phpc file extension, the
> parser starts out in PHP mode.
I don't think such
On 04/07/2012 10:23 AM, Ángel González wrote:
> And I like the idea of providing a function for auto escaping http://www.php.net/unsub.php
On 07/04/12 16:56, John Bafford wrote:
> On Apr 7, 2012, at 10:00, Tom Boutell wrote:
>> .phpc is then just a convention for naming PHP files that start out
>> with code - a convention that autoloaders should respect, just as they
>> now respect the .php convention. "The user asked for the Monkey c
On 07/04/12 17:22, John Bafford wrote:
> On Apr 7, 2012, at 10:53, John Crenshaw wrote:
>> What if you have just ONE function with a variety of options? Something like:
>>
>> execute_file('path/to/foo.php', array(
>>'require'=>true,
>>'once'=>true,
>>'begin_code'=>'>'shorttags'=>arr
On Apr 7, 2012, at 9:45 AM, Pierre Joye wrote:
> hi,
>
> On Sat, Apr 7, 2012 at 4:59 PM, Luke Scott wrote:
>
>>> The expensive parts here are not the object creation on its own but to
>>> get the data they contain (external, calculation, etc.).
>>
>> With heavy objects, yes. But when you have hu
Hi Tom
2012/4/7 Tom Boutell :
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doesn't change. The parser
On Apr 6, 2012, at 10:41 PM, Stas Malyshev wrote:
> Hi!
>
>> How is memory tracked with emalloc? From my observations anything
>> created with emalloc, with or without a zval wrapper, is freed at the
>> end of the request. Things created with pemalloc, which seems to be a
>> wrapper of malloc, is
hi Tom,
On Sat, Apr 7, 2012 at 3:26 PM, Tom Boutell wrote:
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
Please put that in a R
hi,
On Sat, Apr 7, 2012 at 4:59 PM, Luke Scott wrote:
>> The expensive parts here are not the object creation on its own but to
>> get the data they contain (external, calculation, etc.).
>
> With heavy objects, yes. But when you have hundreds of objects? The
> unseralization process in no more
On Apr 7, 2012, at 9:04 AM, Tom Boutell wrote:
> A thoughtful suggestion. But the trouble with a php.ini setting is that you
> can't tell if it is enabled when writing your class file. That makes it
> impossible to write portable libraries. The keywords would always be
> available. And no one
A thoughtful suggestion. But the trouble with a php.ini setting is that you
can't tell if it is enabled when writing your class file. That makes it
impossible to write portable libraries. The keywords would always be available.
And no one has to type them outside of an auto loader (:
Sent from
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> ...
Tom, sorry! For some reason I thought Tony :). On my phone... Not as
intuitive as my desktop...
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.
>
> .phpc is then
He's done.
On 04/07/2012 08:27 AM, Kiall Mac Innes wrote:
> On Sat, Apr 7, 2012 at 4:22 PM, Derick Rethans wrote:
>
>> You repeatly call people stupid, or "like a child" or "what terrible
>> happened in your life" and that is *not* allowed behaviour here. If you
>> (or anyone else for that matte
On Sat, Apr 7, 2012 at 4:22 PM, Derick Rethans wrote:
> You repeatly call people stupid, or "like a child" or "what terrible
> happened in your life" and that is *not* allowed behaviour here. If you
> (or anyone else for that matter) can't refrain from that, you have no
> place on this list.
>
>
> that leaves the question open what terrible happened in your life between all
> that and the proposals last night which sounded naive like from a child?
> Don't get me wrong and with all respect for the work you have done - that's
> not an excuse for bring out proposals like you did or even ma
On Apr 7, 2012, at 10:53, John Crenshaw wrote:
> I don't like this, but it's closer. I hate the idea of adding a whole mess of
> one-off functions just to support a single coding style feature that doesn't
> seem to have very much support. There are a variety of other ideas that have
> been fl
On Sat, 7 Apr 2012, Reindl Harald wrote:
> Am 07.04.2012 16:07, schrieb Derick Rethans:
> > On Sat, 7 Apr 2012, Reindl Harald wrote:
> >
> >> and no the world is not turning around you or even around PHP
> >
> > I will once more suggest you tune down your language on the
> > mailinglists. It's
Am 07.04.2012 16:23, schrieb Tom Boutell:
> On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald wrote:
>> why do you simply not realize that you have way too few knowledge
>> and tchnical education to partly understand the side effects
>> small changes in a general behavior are having
>
> *Sigh*
>
>
On Apr 7, 2012, at 5:22 AM, Pierre Joye wrote:
> hi,
>
> 2012/4/7 Luke Scott :
>
>> It would be ideal of you could initialize a bunch of objects once and
>> carry them over to the next request. No serialization, no copying. A
>> lot of framework objects would benefit from this.
>
> The expensive
On Apr 7, 2012, at 10:00, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.
Those might be ni
> From: Tom Boutell [mailto:t...@punkave.com]
>
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start out in
> PHP mode.
>
I don't like
On 07/04/12 16:06, Reindl Harald wrote:
> Am 07.04.2012 16:00, schrieb Tom Boutell:
>> That's a good point too.
>>
>> I think this is a better proposal:
>>
>> include_code, require_code, and require_code_once would work just like
>> include, require and require_once, except that the parser would st
Am 07.04.2012 16:07, schrieb Derick Rethans:
> On Sat, 7 Apr 2012, Reindl Harald wrote:
>
>> and no the world is not turning around you or even around PHP
>
> I will once more suggest you tune down your language on the
> mailinglists. It's often rude and offensive. Let this be your last
> war
Hello,
I just added the possibility to distinct XFAIL from FAIL test reports in
http://qa.php.net/reports/ (xfail tests were not reported before)
Then, you should easily see what tests are failing from them only xfailing.
This has been activated a few minutes ago and does not work for all report
On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald wrote:
>
>
> would you please leave this world in peace?
>
> what do you think happens with hundret thousands of existing
> include-files out there which are containing only HTML?
Nothing happens to them whatsoever. They work exactly the way they did
On Sat, Apr 07, 2012 at 04:06:17PM +0200, Reindl Harald wrote:
>
>
> Am 07.04.2012 16:00, schrieb Tom Boutell:
> > That's a good point too.
> >
> > I think this is a better proposal:
> >
> > include_code, require_code, and require_code_once would work just like
> > include, require and require_
On Sat, 7 Apr 2012, Reindl Harald wrote:
> and no the world is not turning around you or even around PHP
I will once more suggest you tune down your language on the
mailinglists. It's often rude and offensive. Let this be your last
warning.
cheers,
Derick
--
PHP Internals - PHP Runtime Devel
Am 07.04.2012 16:00, schrieb Tom Boutell:
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.
would you please lea
That's a good point too.
I think this is a better proposal:
include_code, require_code, and require_code_once would work just like
include, require and require_once, except that the parser would start
out in PHP mode.
.phpc is then just a convention for naming PHP files that start out
with code
On Apr 7, 2012, at 09:39, Tom Boutell wrote:
>> From the viewpoint of someone writing reusable classes, the need to
> start with above it is a silly annoyance they don't experience with other tools.
>
> That said, you are making valid points, I'm not convinced myself that
> "file extensions" ne
Am 07.04.2012 15:43, schrieb Stuart Dallas:
> On 7 Apr 2012, at 14:39, Tom Boutell wrote:
>
>> From the viewpoint of someone writing reusable classes, the need to
>> start with > above it is a silly annoyance they don't experience with other tools.
>>
>> That said, you are making valid points, I
wrote:
> you are not making valid points
> you are proposing DANGEROUS changes!
>
> what happens if PHP 5.4.x will follow your wishes
> (what never will happen) and your file without
> php-version?
>
> what you also do not realize is that the world is not turning
> around your windows machine - i
you are not making valid points
you are proposing DANGEROUS changes!
what happens if PHP 5.4.x will follow your wishes
(what never will happen) and your file without
From the viewpoint of someone writing reusable classes, the need to
> start with above it is a silly annoyance they don't experien
On 7 Apr 2012, at 14:39, Tom Boutell wrote:
> From the viewpoint of someone writing reusable classes, the need to
> start with above it is a silly annoyance they don't experience with other tools.
>
> That said, you are making valid points, I'm not convinced myself that
> "file extensions" neces
>From the viewpoint of someone writing reusable classes, the need to
start with wrote:
> Hello, Tom...
>
> Are you seriously that bothered with ' you serious when talking changing reguire/include behaviour just to satisfy
> your wish?
>
> To be also serious, I would mention the possibility of incl
Hello, Tom...
Are you seriously that bothered with '
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doe
On Sat, Apr 07, 2012 at 09:26:01AM -0400, Tom Boutell wrote:
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default beha
I'm +1 on this.
Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doesn't change. The parser starts out in
Now that the flamewar has died down a little I'd like to try to have a
civil discussion about this idea - *without* my admittedly
inflammatory suggestion to kill .
* If a require/include statement sees a .phpc file extension, the
parser starts out in PHP mode.
* If mod_php and FPM are able to see
hi,
2012/4/7 Luke Scott :
> It would be ideal of you could initialize a bunch of objects once and
> carry them over to the next request. No serialization, no copying. A
> lot of framework objects would benefit from this.
The expensive parts here are not the object creation on its own but to
get
Indeed phpdaemon.net appears to cover this ground, although your idea might
deliver higher performance.
Sent from my iPhone
On Apr 6, 2012, at 7:46 PM, Luke Scott wrote:
> I've spent the last few days pouring over the Zend engine source code. I
> think I have a basic understanding on the memor
Neat idea. I have considered writing persistent php servers that just accept
requests serially. Possibly you could write a fastcgi server in pure php. That
would still delegate most of the grunt work to apache.
Sent from my iPhone
On Apr 6, 2012, at 7:46 PM, Luke Scott wrote:
> I've spent the
Sébatien Durand wrote:
But I was not completely aware of the level of change/break my suggestion
will cause.
I'm grateful the work you do. It was just a usability/cosmetic remark of a
daily PHP user. I can live with it.
You have to bear in mind that many of us have many years of code base inve
62 matches
Mail list logo
