I've spent the last few days pouring over the Zend engine source code. I
think I have a basic understanding on the memory management. Likely what I
say may be incorrect, so I apologize in advance.
What I'm trying to do is write an extension to persist PHP variables past
the end of the request in t
On Apr 6, 2012, at 5:16 PM, Stas Malyshev wrote:
Hi!
>From what I've gathered thus far, it is impossible to do without copying the
non-persistent memory into persistent memory, and then back again. I'm
assuming this is because all the memory associated with PHP variables use
emalloc, which p
On Apr 6, 2012, at 5:23 PM, "Johannes Schlüter" wrote:
> Hi,
>
> On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote:
>>
>>
>> From what I've gathered thus far, it is impossible to do without
>> copying the non-persistent memory into persistent m
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 benefi
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
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,
.
Luke
(Sorry, I keep forgetting to hit reply all)
>
> On Apr 7, 2012, at 11:46 AM, Luke Scott wrote:
>
>> On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
>>
>>> That's a good point too.
>>>
>>> I think this is a better proposal:
>>>
&
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
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.).
>>
>>
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 me
Tom,
As I've said before I don't think new keywords are the answer. They
will just pollute the language even further.
I also don't think an ini setting is a bad thing either. It is often
used in PHP as a way to transition from way of doing things to
another. First you introduce it with it being o
as adding a keyword as it is what keyword you're adding.
I hope the way I've explained things makes sense.
Luke
>
> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott wrote:
>> Tom,
>>
>> As I've said before I don't think new keywords are the answer. They
>&
now (assuming
>> it's not a nice clean class file that is being included). Which means
>> that valid code today is busted code once this feature comes out. That
>> seems like a very hard sell.
>>
>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott wrote:
>>> On
>>> I see what you're saying, but you're proposing a new keyword to
>>> include code that does what plain old 'require' does now (assuming
>>> it's not a nice clean class file that is being included). Which means
>>> that valid code toda
On Apr 9, 2012, at 12:27 PM, "Ángel González" wrote:
> On 09/04/12 19:36, Luke Scott wrote:
>> On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote:
>>> Also, your objection - that 'require_code' is confusing - would most
>>> likely be an issue for a han
On Apr 9, 2012, at 12:16 PM, "Ángel González" wrote:
> On 09/04/12 20:23, Chris Stockton wrote:
>> Hello,
>> Although I am not very interested in this feature, if it is
>> implemented I like the idea of flags instead of introducing new
>> keywords. Maintaining backwards compatibility would be gre
on include/require with APC, with file_exists you cannot.
Perhaps that belongs in a different RFC... But if we're thinking of
using constants it would be a nice thing to mention.
Luke
>
> On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott wrote:
>> On Apr 9, 2012, at 10:44 AM, Ralph Schi
On Apr 9, 2012, at 7:49 AM, Flavius Aspra wrote:
> On 04/07/2012 05:21 AM, Luke Scott wrote:
>> From what I've gathered thus far, it is impossible to do without copying the
>>
>> non-persistent memory into persistent memory, and then back again.
>
> Hi, glad to
Pierre,
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote:
> Something I have been discussed in the past with a couple of persons
> is to have a mechanism to automatically instantiate objects on request
> start. That's not persistent objects but that could already boost a
> little it the base foot
> Obviously, it would need to be at the top of the PHP file (whitespace
> notwithstanding). Since we don't want any BC breaks, we at very least need
> it to start with " mean to be parsed. So how about we keep it simple and just use a single,
> " would be allowed after that.
> Anything before tha
I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
but the implementation is quite different.
I'm having trouble linking the v8 library to my extension. When I run a PHP
script via CLI I get:
dyld: lazy symbol binding failed: Symbol not found: __ZN2v86String3NewEPKci
Tom,
On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>My original goal was to stop typing includes at the top. I think it's entirely reasonable to achieve it
>with an option to the require keywords for this purpose and a naming
>convention to be followed by autoloaders. Keep in mind how rarely you
>have
't know about .phpc files, what are they
>anyway... google google... aha, I need PHP 5.x and an updated
>autoloader. Grumble. Okay."
>
>This is a much safer outcome.
>
>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 3:17 PM, &qu
> On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>>
>>> >My original goal was to stop typing >> >includes at the top. I think it's entirely reasonable to achieve it
>
> I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
> but the implementation is quite different.
>
> ...
>
> Anyone know what the problem could be?
>
> Luke
I figured out that v8 was being compiled in 32 bit mode... Apparently it
thinks "native" means 32 bit... Recom
>
>On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott wrote:
>> On 4/9/12 3:53 PM, "Tom Boutell" wrote:
>>
>>>I see why you want to allow >>mode,' rather than disallowed in code mode. But your purpose is to
>>>allow legacy code to be autoloaded wi
On 4/9/12 5:38 PM, "Tom Boutell" wrote:
>On Mon, Apr 9, 2012 at 8:27 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 4:47 PM, "Tom Boutell" wrote:
>>
>>>Let me be very clear about that... I am NOT proposing that >>the top be manda
>I'd totally be open to an alternative to the scrutiny, but so far I haven't seen one. And absent that, there's no way
>I
>could support this, which really sucks because at least conceptually I
>think it's a really good idea.
If the default is "template mode
On Apr 9, 2012, at 6:22 PM, Tom Boutell wrote:
> On Mon, Apr 9, 2012 at 9:11 PM, Luke Scott wrote:
>> Given that an autoloader just has the class name with the attached
>> namespace, how is it to know whether or not to load a .php file or a .phpc
>> file? I'm not
On Apr 9, 2012, at 6:22 PM, Kris Craig wrote:
If the default is "template mode" and the " top) in "code" mode there shouldn't be any problems.
>
> We don't need to change or leave out the tag entirely.
>
> Is there a problem with people being able to choose "template mode" or
> "code mode" as the
On Apr 9, 2012, at 7:44 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/10 Luke Scott :
>>>>> That said, allowing the skipping of an initial >>>> the file probably wouldn't be a big deal to implement in code mode.
>>>>
>>>>
>>>&g
On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
> Please don't repeat mistakes for allow_url_include or allow_url_include.
> If admin would like to enforce programmer not to change php.ini.
> They should use Apache httpd and admin_flag/admin_value.
>
> Programmers should have as much control as p
On Apr 9, 2012, at 8:26 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/10 Luke Scott :
>> On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
>>
>>> Please don't repeat mistakes for allow_url_include or allow_url_include.
>>> If admin would like to enforc
> It's easy to say "write correct code. don't write stupid code", but
> we cannot enforce it in real world.
>
> I'm concerning both arbitrarily script execution and arbitrarily
> information disclosure. Good example is LFI and SQL injection
> attack.
Uh yeah there is. I won't employ someone who i
On Apr 9, 2012, at 9:08 PM, Yasuo Ohgaki wrote:
>> I would actually suggest that require/include stop supporting remote
>> files all together. But that can be a different RFC.
>>
>> This "security problem" isn't a problem with common sense.
>
> Requiring/Including remote file is not bad, just lik
On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki wrote:
> I strongly discourage settingallow_url_include=on, too.
Good.
> Enabling it only when it is needed is okay.
No it's not. There is no reason to do so other than backwards
compatibility for very old code.
> I think you are concerned about secur
On Apr 10, 2012, at 12:24 AM, Flavius Aspra wrote:
> On 04/09/2012 10:30 PM, Luke Scott wrote:
>> Yeah it would be. He also mentioned something about preloading
>> framework classes.. Would like to hear his thoughts on that!
>
> I also subscribe to the opinion of object
Tom,
On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote:
> The "second part" in the RFC is just a suggested filename convention,
> it is not a hardcoded requirement. I'm not sure that's what you're
> talking about here.
>
> The RFC I'm referring to does not propose completely removing the
> availabi
>
>> I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
>> but the implementation is quite different.
>>
>> ...
>>
>> Anyone know what the problem could be?
>>
>> Luke
>
> I figured out that v8 was being compiled in 32 bit mode... Apparently it
> thinks "native" means
I'm using the line:
PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD)
Where the path is /phpdev/lib. But my extension is actually linking to
/v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even
though /v8/out/x64.release no longer exists.
What am I doing
On 4/10/12 4:53 PM, "Tom Boutell" wrote:
>Please see:
>
>https://wiki.php.net/rfc/source_files_without_opening_tag
>
>After following the discussion I have updated the RFC with the
>following major changes:
>
>* Forbade the use of ?> entirely in "pure PHP" files (without
>restricting it at all in
On Apr 10, 2012, at 6:59 PM, Tom Boutell wrote:
> On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott wrote:
>> - I would like to see an INCLUDE_SILENT method to prevent warnings from
>> being thrown with include/include_once statements. Currently doing
>> something like @inclu
Hey Rasmus,
Here are my thoughts:
On Apr 11, 2012, at 7:09 AM, Rasmus Lerdorf wrote:
> On 04/11/2012 12:59 AM, Stas Malyshev wrote:
>>> Therefore, it should not be misunderstood as perfect LFI
>>> countermeasure even if I stressed on security meanings.
>>> I'm stressing security because this ac
bc on that one! I have been
programming for 10 years and that one still confuses me! Most people
just add parentheses to "fix" the problem. I wish someone would write
an RFC to change this to right associative like every other language!
*hint hint*
Luke Scott
On Apr 10, 2012, at 9:2
On 4/11/12 11:27 AM, "Chris Stockton" wrote:
>Hello,
>
>On Wed, Apr 11, 2012 at 11:14 AM, Tom Boutell wrote:
>> On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton
>> wrote:
>>> I have read the RFC and I although from what I gather it seems that
>>> .phpp is a recommendation and not a requirement,
On Apr 11, 2012, at 12:02 PM, Chris Stockton wrote:
> Hello,
>
> On Wed, Apr 11, 2012 at 11:47 AM, Luke Scott wrote:
>>
>> The .php extension really isn't used by PHP, but it's used by a web server
>> to identify PHP code and send it to the interpreter. Any
> I'm using the line:
>
> PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD)
>
> Where the path is /phpdev/lib. But my extension is actually linking to
> /v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even though
> /v8/out/x64.release no longer exists.
>
I'm writing an extension that uses Google's V8 engine. I'm getting a
segfault after my module has been unloaded.
Here is what I get when running PHP:
DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 /phpdev/bin/php -f
/Server/www/localhost/test.php
dyld: loaded: /phpdev/lib/php/extensions/debug-zts-20090626/v8
48 matches
Mail list logo
