ion is almost identical to the second snippet on this page:
https://developers.google.com/v8/get_started , difference being I'm doing
RETURN_STRING(*ascii, 1).
(If providing a core dump helps, I can do that as well)
Anyone know what could be causing this?
Luke
4.release no longer exists.
>
> What am I doing wrong?
>
> Luke
Was probably super obvious, but install_name_tool is how you fix the issue.
First use the "-id" parameter on the .dylib to fix the dylib. Then recompile
(or fix with -change flag).
Luke
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
ment here, was just my initial thoughts.
When I use get_defined_constants(TRUE); I didn't see any PHP_ constants.
There are many built in constants that don¹t' follow this rule, and follow
their own conventions. T_* for example is reserved for tokens. If this is
indeed a requirement, I don't mind as long as these constants aren't
insanely long. But if it's not a requirement, I'd prefer not to have the
PHP_*. It's a bit redundant.
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
actual cause of the problem. I would love to hear some
> ideas along those lines that don't fundamentally change the nature of
> PHP for somewhat cloudy benefits.
The problem is people are doing that. The solution is they should stop
doing that. Anyone doing this is asking for trouble. The fix is better
education.
In the end while I do support the idea of not allowing "embed mode"
(as a choice when doing require/include), I cannot support the idea
that it somehow makes things more secure.
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
pure";
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param HTTP_ACCEPT_ENCODING "";
fastcgi_param HTTPS $https;
}
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
doing wrong?
Luke
>
>> 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 ou
ts it would be better to used
or'd constants rather than an array.
Luke
>
> On Tue, Apr 10, 2012 at 8:55 AM, Rafael Kassner wrote:
>> IMHO, both parts can be separated. My personal opinion: the require_path
>> with the php mode only can be useful, a mime type or extension fo
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
kly it
isn't a core PHP issue. It's no different than any language with an
eval() statement.
Keep in mind an RFC isn't gospel. And it's still being drafted. We
need to give Tom a chance to finish it.
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
by another
developer before it gets commited. Even my code, and I'm a manager.
This should be done at the very least. Some companies do this and then
have a third party audit the code on top of it.
> They are bad for security if they are enabled by default or mandatory.
Again nothing has
> 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 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
e appropriate ways of getting remote content.
file_get_contents isn't nearly as bad though.
... But any of the above has nothing to do with this RFC.
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 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 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
>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 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
>
>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
> 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..
> 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
>
'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
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 _seems_ like libv8.a is trying to link to something else... but I'm not
sure. My extension compiled fine.
I'm on Mac OS X 10.6.x.
Anyone know what the problem could be?
Luke
> 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
ke that (before loading the actual file
index.php file, similar to the prepend feature)?
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
having existing code work with the
current versions.
To make new code compatible with older versions of PHP you simply
don't use the keyword/constant.
>
> *if ( version_compare(PHP_VERSION*, '5.5', '<') )
> include_once $file;
> else
> require_code($file, array
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
by include without
suppressing warnings/errors by the actual file -- I think we can all
agree @include is counter productive since it does much more that
suppress warnings thrown by include (even parse errors!).
Luke
>
> -ralph
>
>
>
> On 4/9/12 12:23 PM, Tom Boutell wrote:
>
could mean short tags whereas the other leave you
scratching your head.
Luke
>
> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell wrote:
>> I see what you're saying, but you're proposing a new keyword to
>> include code that does what plain old 'require' does
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
>&
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
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
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 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
rability do this anyway.
The only way I see this not working is for PHP short tags where PHP is
used as a template language. A lot of people decide to use other
template engines though, like Twig. I personally avoid short tags on
large projects and use them only on small quick and dirty projects
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
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 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 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
pping zval. A zval would have a persistent flag and a
recount the value inside would be released when the recount reaches
zero or at the end of the request if the persistent flag is zero
But this is something totally different than it is now.
Luke
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
- even if
it involves modifying the Zend engine. Have you guys had any recent
discussions about doing this?
Luke
compatible with 5_3 ?
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Did anyone notice it has been released on the same day as firefox 3.5? See
any similarity in the version numbers?
--
Luke Slater
:O)
In my opinion namespaces should be in 6 not 5.3 but ignoring that:
+1 for Issue 1 option 1
+1 for Issue 2
2008/10/16 Nathan Rixham <[EMAIL PROTECTED]>
> Steph Fox wrote:
>
>> Please can those people who didn't already express a clear and relevant
>> opinion, express it now? We don't have long to
Thanks, I added the comment, and the 4.3.2 patch to the bug report.
Luke
On Mon, Aug 18, 2003 at 04:55:56PM -0500, Luke Ehresman wrote:
> Hi,
>
> A co-worker and I have been working on some intensive timestamp/timezone
> manipulation code for the past week or so, and ran ac
ame code would work on most recent versions of PHP as it
doesn't seem that this function has had much recent development. The
patch can be applied by using the following:
$ cd /usr/local/php-4.3.2
$ patch -p2 < ~/gmmktime-php_4.3.2.patch
Feel free to contact me if you have any quest
52 matches
Mail list logo
