Ok, I'll try to fix that part. Thanks for the correction.
Moriyoshi
On Sun, Apr 1, 2012 at 11:29 AM, Rasmus Lerdorf wrote:
> On Mar 31, 2012, at 6:59 PM, Moriyoshi Koizumi wrote:
>
>> Hi,
>>
>> I wrote a RFC that proposes removal of PHP tags. There is actually
&
Hi,
I wrote a RFC that proposes removal of PHP tags. There is actually
strong public demand for it, and I also think it is necessary to
leverage PHP to a genuine, modern scripting language.
http://wiki.php.net/rfc/nophptags
Regards,
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing
On Mon, Jun 20, 2011 at 8:39 PM, Derick Rethans wrote:
>> 8. Cli web server. Built-in mini-HTTP server run directly from PHP binary.
>> Assigned: Moriyoshi Koizumi
>
> I'd really like to see that one. I thought the patch was already
> committed?
Not yet. I'm gon
. Does not include any new JSON-like syntax, etc. - just making
> '[' be 'array(' and ']' be ')' in that context.
>
> 7. "Disable POST data processing" INI option.
> Assigned: Gustavo Lopes
>
> 8. Cli web server. Built-in mini-
Hmm, it has already supported through ZEND_HANDLE_STREAM. So then, changing
the interface of fopen_function to return zend_stream instead of FILE* should
be fine.
Moriyoshi
On 2011/03/05, at 3:05, Moriyoshi Koizumi wrote:
> It looks like the only solution is define a new stream type
It looks like the only solution is define a new stream type for zend_stream
that delegates stream operations to user-defined callbacks.
Moriyoshi
On 2011/03/04, at 10:26, Stas Malyshev wrote:
> Hi!
>
> I try to do some complex code with custom streams and I have discovered the
> following pro
On Fri, Mar 4, 2011 at 11:17 AM, Christopher Jones
wrote:
>
>
> On 03/02/2011 12:55 PM, Moriyoshi Koizumi wrote:
>>
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help
Hi,
2011/3/3 Ángel González :
> Moriyoshi Koizumi wrote:
>>> Regarding the patch (https://gist.github.com/835698):
>>> I don't see a switch to disable the internal parse on configure.
>> I don't see any obvious reason it should be able to be turned off
&
Hi,
On Thu, Mar 3, 2011 at 3:35 PM, Alexey Zakhlestin wrote:
> On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
try Stogov wrote:
> Hi Moriyoshi,
>
> OK, I thought the email was lost, so ignore the email I just resent.
>
> In general I like your patch and I would glad to see it fixed.
>
> I already tried to make some fixes.
> See the attached patch.
>
> Thanks. Dmitry.
>
> O
2011/3/3 Ángel González :
> Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers. That would be handy for development purpose.
>>
Hi,
Just to let you know that I wrote a RFC about built-in web server
feature with which PHP can serve contents without a help of web
servers. That would be handy for development purpose.
If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .
Regards,
Moriyoshi
--
PHP Intern
Hey,
I think I can fix it somehow. Please don't be haste with it. I am
going to look into it.
Moriyoshi
On Tue, Mar 1, 2011 at 11:35 PM, Dmitry Stogov wrote:
> Hi,
>
> I'm going to revert Moriyoshi patch from December and some following fixes.
>
> I like the idea of the patch, but it just doe
On Tue, Dec 7, 2010 at 5:57 AM, Dmitry Stogov wrote:
> On 12/06/2010 08:25 PM, Moriyoshi Koizumi wrote:
>>
>> On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov wrote:
>>>
>>> Hi Moriyoshi,
>>>
>>> On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
&
Hi,
The patch almost looks good to me, but we should be more careful about
introducing a set of hook points into the API. I think it'd be great
if the multipart parser portion was rewritten so that it would only
call the Zend multibyte API's despite a slight performance drawback.
Regards,
Moriyo
On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov wrote:
> Hi Moriyoshi,
>
> On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
>>
>> Hi,
>>
>> How about using the value of mbstring.script_encoding to determine
>> whether to enable the encoding conversion featur
Hi,
How about using the value of mbstring.script_encoding to determine
whether to enable the encoding conversion feature? If the value is
the same as that of mbstring.internal_encoding, then no conversion
should be needed in the first place. Besides we can define some
singular value like "none"
Hi,
I am under the impression that we have to provide an alternative to
htmlspecialchars() that incorporates the following ideas:
- Shorter function name
html_escape() for example. _h() would be much more preferable in
terms of preventing XSS ;-p
- Using default_charset as the default encoding
Hey,
Just to let you know about a new RFC for adding autoboxing feature in PHP.
Look at http://wiki.php.net/rfc/autoboxing .
Regards,
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Apr 5, 2010 at 7:17 PM, Alexey Zakhlestin wrote:
>
> On 05.04.2010, at 13:46, Moriyoshi Koizumi wrote:
>
>> I used to play with TSRM days ago and successfully implemented
>> userland threading support using GNU Pth. It's just a proof of
>> concept and I
I used to play with TSRM days ago and successfully implemented
userland threading support using GNU Pth. It's just a proof of
concept and I did it for fun.
If interested, check out
http://github.com/moriyoshi/php-src/tree/PHP_5_3-threading/ and
read
http://github.com/moriyoshi/php-src/blob/PHP_5
Hi,
On Thu, Mar 25, 2010 at 8:41 AM, Stanislav Malyshev wrote:
> Hi!
>
>> Wouldn't it suffice to add a field for the hash value and a flag that
>> indicates its validity to zval instead of appending zend_literal
>> everywhere?
>
> Enlarging zval would be costly (the engine uses tons of zvals) and
Hi,
Wouldn't it suffice to add a field for the hash value and a flag that
indicates its validity to zval instead of appending zend_literal
everywhere?
Moriyoshi
On Wed, Mar 24, 2010 at 11:12 PM, Zeev Suraski wrote:
> Hi,
>
> Over the last few weeks we've been working on several ideas we had for
On Mon, Mar 15, 2010 at 6:25 AM, Herman Radtke wrote:
>> Oh no .. another dangerous topic. Again we have been there even before the
>> switch. The idea is to keep the centralized repo on svn, because the masses
>> know how it works, the tools are widely available and we have plenty of
>> experi
On Sun, Mar 14, 2010 at 11:23 PM, Jordi Boggiano wrote:
> On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev wrote:
>> UTF8 also takes 4 bytes for representing characters in the higher bit
>> planes, as quite a lot of bits are lost for every char in order to describe
>> how long the code point is, a
On Sun, Mar 14, 2010 at 1:57 AM, Derick Rethans wrote:
> - in the meanwhile, start working on patching in back Unicode support,
> but in small steps. Exactly which things, and how we'd have to find
> out. But I do think it needs to be a *core* language feature, and not
> simply solved by exten
It looks like I stripped off too much. Attached is the right one.
Moriyoshi
On Sun, Mar 14, 2010 at 12:41 AM, Moriyoshi Koizumi wrote:
> Surprisingly, It can be done quite easily with the current object
> handler infrastructure.
>
> Moriyoshi
>
> On Sun, Mar 14, 2010 at 12:
Surprisingly, It can be done quite easily with the current object
handler infrastructure.
Moriyoshi
On Sun, Mar 14, 2010 at 12:08 AM, Pierre Joye wrote:
> On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi wrote:
>
>> I don't totally agree with what is being said here, but I
On Sat, Mar 13, 2010 at 6:07 PM, Chen Ze wrote:
> I think unicode should only care for string handling. Formatting
> numbers should not be the thing that unicode cares. Unicode is a
> standard for text, not for text or number formatting.
>
> Back to the days we don't have unicode, the number forma
On Sat, Mar 13, 2010 at 8:09 PM, Lester Caine wrote:
> Handling unicode CONTENT is not the problem here. People nowadays expect to
> be able to use their own language to write code, and create functions using
> words that they recognize. In databases, table and field names are now
> expected to su
make a serious
internaltionalized application.
Moriyoshi
On Sat, Mar 13, 2010 at 3:34 AM, Derick Rethans wrote:
> On Fri, 12 Mar 2010, Hannes Magnusson wrote:
>
>> On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi wrote:
>> > I'd love to see my brand-new mbstrin
I'd love to see my brand-new mbstring implementation in the release.
Dropping mbstring completely won't be any good because lots of
applications rely on it, but I don't really want to maintain the funky
library bundled with it.
Moriyoshi
On Fri, Mar 12, 2010 at 2:22 AM, Rasmus Lerdorf wrote:
> A
2010/2/1 KITAZAKI Shigeru :
> * php_syslog.patch
> syslog() function cannot properly send UTF-8 strings to event log on
> Windows. This patch changes the internal API. We, however, must set
> UTF-8 on 'mbstring.internal_incoding'.
> In addition, this changes the severity of 'LOG_ERR' from event
Kitazaki-san,
First thank you for your effort. But, I am under the impression that
the conversion table looks too huge to include in a distribution
(>30MB). Is there any way to get this more compressed?
BTW, I created an extension that is near-compatible with mbstring and
based on ICU that of co
On Tue, Aug 4, 2009 at 2:47 AM, Stanislav Malyshev wrote:
>> And yes, it's worth providing separate conversion system. You might
>> not be aware of it, but there are several sets of different character
>> sets, each of which is often represented with a specific encoding
>> scheme. Shift_JIS is o
On Sat, Aug 1, 2009 at 9:02 AM, Stanislav Malyshev wrote:
> Hi!
>
>> They calculate the total width of a string based on "east asian width"
>> property, which is still valid to give a rough measurement of the
>> rendered string.
>
> OK, I guess if it's some kind of special calculation that doesn't
Hi,
On Sat, Aug 1, 2009 at 1:37 AM, Stanislav Malyshev wrote:
> Hi!
>
>>> mb_str* - shouldn't you in 6 just convert them to unicode and do all
>>> string
>>> operations with Unicode strings? Also, in 5 isn't there some intersection
>>> with grapheme_* functions?
>>
>> mb_strwidth() and mb_strimwid
On Fri, Jul 31, 2009 at 5:24 PM, Moriyoshi Koizumi wrote:
>> mb_str* - shouldn't you in 6 just convert them to unicode and do all string
>> operations with Unicode strings? Also, in 5 isn't there some intersection
>> with grapheme_* functions?
>
> mb_strwidth() a
On Fri, Jul 31, 2009 at 2:37 AM, Stanislav Malyshev wrote:
> Hi!
>
>> Aren't there any interests on this? If you think PHP 6 is gonna cover
>> all of the functionality that allegedly-cruft mbstring currently
>> provides, that is almost wrong :-p
>
> Could you please explain why PHP6 doesn't provide
On Thu, Jul 30, 2009 at 8:05 PM, Niel Archer wrote:
>> Implemented functions:
>>
>> - mb_ereg()
>> - mb_ereg_replace()
>
> as ereg functions are deprecated in 5.3, are these still needed?
mb_ereg_XXX() have nothing to do with the plain ereg functions. They
are named so purely for the historical re
On Thu, Jul 30, 2009 at 7:21 PM, Alexey Zakhlestin wrote:
> 2009/7/26 Moriyoshi Koizumi :
>
>> - mb_ereg_search(), mb_ereg_search_getpos(), mb_ereg_search_getregs(),
>> mb_ereg_search_init(), mb_ereg_search_pos(), mb_ereg_search_regs() and
>> mb_ereg_search_setpos()
>
Aren't there any interests on this? If you think PHP 6 is gonna cover
all of the functionality that allegedly-cruft mbstring currently
provides, that is almost wrong :-p
Moriyoshi
On Tue, Jul 28, 2009 at 5:41 PM, Moriyoshi Koizumi wrote:
> I set up a RFC page for this in wiki.php.net.
I set up a RFC page for this in wiki.php.net. Here it goes:
http://wiki.php.net/rfc/altmbstring
Moriyoshi
2009/7/26 Moriyoshi Koizumi :
> Hi there,
>
> I almost finished an alternative implementation of mbstring that uses
> ICU instead of the exotic libmbfl in hope of replacing the
Incorporating the changes and merges across the branches into one
commit under a sparse-layouted local copy doesn't do the book-keeping
against svn:mergeinfo. That's why I suppose it is not a good idea.
Moriyoshi
On Tue, Jul 28, 2009 at 7:44 AM, Gwynne Raskind wrote:
> On Jul 27, 2009, at 6:31 P
That is a test that is involved in the iconv's transilteration
feature, the behavior of which may vary by the platform you use. I
guess we don't actually need to test it then.
Moriyoshi
On Tue, Jul 28, 2009 at 12:27 PM, Rasmus Lerdorf wrote:
> Moriyoshi, or someone who knows CP932 and EUC-JP, co
Just to be sure, is there any consensus on this? I thought I should
use svn merge.
Moriyoshi
On Tue, Jul 28, 2009 at 12:30 AM, David Soria Parra wrote:
> On 2009-07-27, Takeshi Abe wrote:
>> Log:
>> MFH: fixed #48732 (TTF Bounding box wrong for letters below baseline) and
>> #48801 (Problem wit
Hi there,
I almost finished an alternative implementation of mbstring that uses
ICU instead of the exotic libmbfl in hope of replacing the current one
for 5.4 (and possibly, 6.0.)
Although there are admittingly some known incompatibilities that need
extra libraries to resolve them besides a numbe
On Fri, May 15, 2009 at 12:31 PM, Farley Knight wrote:
> zend_hash_internal_pointer_reset(Z_ARRVAL(zhash));
>
> printf("This hash table has %d entries\n",
> zend_hash_num_elements(Z_ARRVAL(zhash)));
>
> int current = 0;
>
> while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)&value)
>
While I am stil wondering why we could not stop this kind of mess
before the release, we should also revert the default for 5.3. There's
no point making the behavior different between releases.
Moriyoshi
On Fri, May 15, 2009 at 5:10 AM, Andrei Zmievski wrote:
> Ilia Alshanetsky wrote:
>>
>> Andr
Ilia, do you still see any problem merging this to 5.2?
Moriyoshi
On Sat, Apr 11, 2009 at 6:16 PM, Hannes Magnusson
wrote:
> Ilia?
>
> I guess the chances of getting this merged Moriyoshi will increase by
> 100% if you have a testcase..
>
> -Hannes
>
> On Tue, Mar 17,
a number of crucial fixes and if your comments are
> validated via user feedback we can adjust the values with 5.2.10 that can be
> repackaged fairly rapidly. IMHO the current functionality is desired and is
> acceptable.
>
> Ilia Alshanetsky
>
>
>
>
> On 26-Feb-09, at 1:5
Isn't it better to avoid any behaviour-changing #define's in a header
file? I mean the following series of lines in php_embed2.h:
/* we control char* lifetime of smart_str as we allow it to cross
request boundaries */
#define SMART_STR_USE_REALLOC 1
/* we use bigger numbers than default as script
i Moriyoshi,
>
> Moriyoshi Koizumi wrote:
>>
>> Hi,
>>
>> I got a bug report on the Japanese PHP user's list that states free()
>> aborts within the timer signal handler due to reentrance to the
>> function when max_execution_time takes effect and the signal
Hi,
I got a bug report on the Japanese PHP user's list that states free()
aborts within the timer signal handler due to reentrance to the
function when max_execution_time takes effect and the signal occurs
within the same libc function. The reporter also states he uses
apache2handler, which doesn'
as
> possible as it introduces a number of crucial fixes and if your comments are
> validated via user feedback we can adjust the values with 5.2.10 that can be
> repackaged fairly rapidly. IMHO the current functionality is desired and is
> acceptable.
>
> Ilia Alshanetsky
>
>
&
On Fri, Feb 27, 2009 at 3:58 AM, Moriyoshi Koizumi wrote:
> 1. array_unique() has never been supposed to handle values other than
> strings. That's how bug #10658 is handled.
That's not what I really wanted to mean. I should have said "not
supposed to handle valu
Robin Burchell wrote:
> On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi wrote:
>> So, in what point do you guys think of this change as valid?
>>
>> Moriyoshi
>
> Is there any known examples of code broken by this, or is it a more
> academic than practical p
So, in what point do you guys think of this change as valid?
Moriyoshi
On Thu, Feb 26, 2009 at 11:36 PM, Antony Dovgal wrote:
> On 26.02.2009 17:19, Ilia Alshanetsky wrote:
>> Let's reach a conclusion by end of day (EST time) so release can either be
>> made or
>> delayed.
>
> +0
>
> Just go ah
Last call: any more objections?
Moriyoshi
On Thu, Feb 19, 2009 at 11:52 AM, Moriyoshi Koizumi wrote:
> On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski
> wrote:
>> Moriyoshi Koizumi wrote:
>>>
>>> As I said earlier, the function is never supposed to be used w
Robin Burchell wrote:
> On Thu, Feb 19, 2009 at 10:24 PM, Andrei Zmievski
> wrote:
>> Can someone explain why ext/sockets and also stream socket functions care
>> about FD_SETSIZE?
>
> They care, because they use the select(2) syscall, which cares about
> FD_SETSIZE.
>
select(2) itself can ha
That's because struct fd_set, which is manipulated by FD_SET, is a
struct that contains a fixed-size array.
Moriyoshi
Andrei Zmievski wrote:
> Can someone explain why ext/sockets and also stream socket functions
> care about FD_SETSIZE?
>
> # define PHP_SAFE_FD_SET(fd, set) do { if (fd < FD_SE
On Thu, Feb 19, 2009 at 3:14 PM, Ian Eure wrote:
> On Feb 18, 2009, at 6:52 PM, Moriyoshi Koizumi wrote:
>
>> On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski
>> wrote:
>>>
>>> Moriyoshi Koizumi wrote:
>>>>
>>>> As I said earlier,
On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski wrote:
> Moriyoshi Koizumi wrote:
>>
>> As I said earlier, the function is never supposed to be used with
>> objects. Therefore, we cannot declare it to be broken, and any change
>> to the behavior anyway leads to a hu
merged, then bug #46701 should be
reverted from the 5.2 branch.
Moriyoshi
On Wed, Feb 18, 2009 at 8:28 PM, zoe wrote:
> Moriyoshi Koizumi wrote:
>>>>> I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was
>>>>> changed by the fix for bug #42868, rig
In addition, we should look at similar comparison-involved array
functions such as array_intersect, array_diff and so on, otherwise
it's gonna be a mess.
Moriyoshi
On Wed, Feb 18, 2009 at 11:43 AM, Moriyoshi Koizumi wrote:
> On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski
On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski wrote:
> SORT_STRING can only reliably deal with strings - its behavior on non-string
> type is basically broken. Unless we agree that PHP is Tcl (strings are the
> only type), then SORT_REGULAR makes much more sense to me, and evidently
> others.
Anyone's thoughts on this?
I'm thinking of re-reverting in 48 hours without further objections.
Moriyoshi
On Sun, Feb 15, 2009 at 11:48 PM, Moriyoshi Koizumi wrote:
> Ilia Alshanetsky wrote:
>> I've discussed this issue with Andrei at least a month ago (if not
>&
Moriyoshi
>
> On 14-Feb-09, at 9:12 PM, Moriyoshi Koizumi wrote:
>
>> So, what are RM's thoughts on this? My points are:
>>
>> 1. Making SORT_REGULAR default *actually* broke existing code.
>> 2. Adding the second argument addressed the problem enough that th
ess this issue?
>
>
> On 12-Feb-09, at 3:56 PM, Moriyoshi Koizumi wrote:
>
>> See the results of the following on 5.2.6, 5.2.9rc2 and 5.3:
>>
>> php -r '$a[1e100] = 1; var_dump($a);'
>>
>> 5.2.6:
>> array(1) {
>> [-2147483648]=>
&
what we expect, and this
problem should be addressed in 5.3 with the 5.2's behavior unchanged.
Moriyoshi
On Fri, Feb 13, 2009 at 1:48 AM, Moriyoshi Koizumi wrote:
> Hey,
>
> I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was
> changed by the fix for bug #42
Hey,
I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was
changed by the fix for bug #42868, right?
If so, this patch shouldn't be MFH'ed as the #42868 patch was not
merged although I didn't remember any discussion on this.
See also: http://marc.info/?l=php-internals&m=12079972092
Hi,
This behavior seems strange, but the rationale of this function is that
the (east asian) width of the resulting string does not exceed the
specified value so that it would fit to a fixed sized box when rendered
in the browser, assuming the string would be displayed with a monospace
font.
Please redirect your question to me. Boost.PHP is not an official part
of the PHP project.
Moriyoshi
On Wed, Nov 19, 2008 at 2:13 AM, Chris Jiang <[EMAIL PROTECTED]> wrote:
> Hi all, it's been a while since my last thread. I've been playing around
> with Boost.PHP these days, and find it pretty m
Hey,
Don't forget to have a look at Boost.PHP :)
http://github.com/moriyoshi/boost.php/wikis
Moriyoshi
On Sun, Nov 16, 2008 at 12:11 AM, Chris Jiang <[EMAIL PROTECTED]> wrote:
> Hi all, it's my first time posting in this mailing list.
>
> I've been trying to make a PHP extension for my project,
On Thu, Nov 13, 2008 at 4:14 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> 1) ext/mhash in 5.3.
> I) enable ext/hash by default
+1
> II) remove ext/mhash
+1
> 2) deprecate ereg*.
+1
> 3) resource constants (choose one)
> a) Should we deprecate constant resources (mostly used to emulate STDIN
Stanislav Malyshev wrote:
Hi!
language syntax, whereas the "use" construct after the argument list
is inconsistent with the ordinary function definition unless my proposal
Because it is _not_ an ordinary function definition. It's like saying
'+' is "inconsistent" with '-' because $a+$b=$b+$
Stanislav Malyshev wrote:
Hi!
What a nitpicking :) So would I say that the global statement is
inconsistent with static because it doesn't allow assignments within
the statement :p
Sure it is. That's just another thing to show all this "consistency"
talk is blown way out of proportion long
Stanislav Malyshev wrote:
Hi!
function ($arg) { use $a, &$b;
Note that neither static not global allow & inside definitions, so from
"consistency" point of view it doesn't work.
What a nitpicking :) So would I say that the global statement is
inconsistent with static because it doesn't al
Larry Garfield wrote:
On Tuesday 05 August 2008 12:48:37 am Moriyoshi Koizumi wrote:
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
--
Moriyoshi Koizumi <[EMAIL P
entation had "lexical" keyword which worked as you are
suggesting, but it was much unclear.
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
--
Moriyoshi Koizum
think the point is that PHP doesn't have the concept of compilation
units unlike major namespaced programming languages such as C++ and
Java. PHP so far chose to differentiate grammatical contexts with braces
or blocked statements, so should namespace.
Moriyoshi
--
Moriyoshi Koizu
in this case.
Moriyoshi
--
Moriyoshi Koizumi <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
suggest we disallow multiple namespace per file.
And there is no technical reason and surely no other reason whatsoever to
not have curly braces. If there is then we either fix that or went with the
wrong approach.
3) __invokable, see Etiene's mail
Best regards,
Marcus
--
Moriyoshi K
Hi,
Antony Dovgal wrote:
Extensions enabled by default in 5.3:
ctype
date
dom
ereg
fileinfo - new, untested.
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
Phar - new, untested
posix
Reflection
session
SimpleXML
SPL
SQLite
sqlite3 - new, untested
standard
tokenizer
xml
xmlreader
xmlwriter
--
Hi Marcus,
Really? I haven't heard anything like that.
MOriyoshi
On 2008/07/30, at 16:19, Marcus Boerger wrote:
Hello Stefan,
which doesn't belong there either.
marcus
Wednesday, July 30, 2008, 9:14:07 AM, you wrote:
Marcus Boerger schrieb:
Hello Moriyoshi,
actually you should pl
Nope, but I'm thinking of proposing it as soon as I finish the
documentation.
Moriyoshi
On 2008/07/29, at 23:00, troels knak-nielsen wrote:
On Tue, Jul 29, 2008 at 2:58 PM, Moriyoshi Koizumi
<[EMAIL PROTECTED]> wrote:
Hi folks,
I created a library that may draw some attention
Hi folks,
I created a library that may draw some attention. Boost.PHP is a set
of macros and C++ classes that wrap around common Zend Engine structs
that allow you to create a PHP extension in C++, in a very efficient
way. Most notably, you no longer need most of the ZE macros and APIs
li
I would like to keep this as a RFC page in wiki.php.net. Are there
any conventions or rules that I should keep in mind? (or just-not-
supposed-to-do-that-because-your-proposal-is-stupid-and-will-never-be-
accepted?)
Moriyoshi
On 2008/07/18, at 8:23, Moriyoshi Koizumi wrote:
Hi,
Attached
On 2008/07/18, at 19:06, Richard Quadling wrote:
2008/7/18 Moriyoshi Koizumi <[EMAIL PROTECTED]>:
running test1.php ends up with two lines of "bar", surprisingly.
This is somewhat confusing, but surely one of the things that could
not ever be done. This might be a great h
That's one of the motivations for the patch. I never liked the new
syntax, but if it was given a go, it should also be made consistent
with the another part of the syntax. Oh, I just got one important
thing in mind to mention;
test1.php:
test2.php:
running test1.php ends up with two lin
Hi,
Attached are the patches that allow the "use" statement that was
introduced with closures to appear within every function statement
except method definitions. I think this feature is a good addition
because it resolves inconsistency between closures and unticked
functions. In a nutshe
Marcus Boerger wrote:
> Hello Moriyoshi,
>
> (just for Derick answered here)
> I never liked this. So imo we can simply get rid of this switch and enable
> mbregex as soon as there is mbstring to begin with and regex stuff.
Me neither. As far as I know, the switch exists just for historical
reaso
Hi there,
(Yeah, it's been a long time.. Many of you might well have thought
I'm dead :)
This time I want to revisit the following issue:
http://article.gmane.org/gmane.comp.php.devel/50681
Is there any point to disable mbregex alone instead of disabling the
whole mbstring stuff? Unless the deci
On 2005/03/19, at 6:14, Derick Rethans wrote:
On Sat, 19 Mar 2005, Moriyoshi Koizumi wrote:
We already have an optimisation in the 5.x branches.
I think it is appliable to the 4.3 branch.
4.3 is only for bugfixes!
It didn't mean that the fix should be in the 4.3. What was it
that excited y
On 2005/03/19, at 3:41, Alexander Valyalkin wrote:
I've posted patch last summer
http://www.zend.com/zend/week/pat/pat5.txt
which imporves performance of implode() function in PHP4, but nobody
doesn't
commit it yet. Can anybody explain the reason?
Because convert_to_string_ex() modifies the conte
On 2005/03/17, at 21:52, Lukas Smith wrote:
Derick Rethans wrote:
On Thu, 17 Mar 2005, Moriyoshi Koizumi wrote:
That's expected behaviour. Have a look at http://bugs.php.net/20993 .
Sorry, but this is not expected - it's a bug.
I would also like to disagree. I think this is a huge inc
That's expected behaviour. Have a look at http://bugs.php.net/20993 .
The problem can also be prevented by the following hack:
// modifying and assining branch causes unexpexted results to
$this->tree
$metatree[$object_id] = (array)unserialize(serialize($branch));
Regards,
Moriyoshi
On 2005/03/17
Hi,
I modified your patch so it can capture the position where the
supposed data begins into the constant __HALT_PHP_PARSER__.
There may be a problem with my patch if more than one require()'d /
include()'d script contain __HALT_PHP_PARSER__, but it'd be
quite handy if such an issue is resolved.
esn't make any sense if it doesn't
work perfectly and we better deprecate it until some unicode-aware
case folding function is available.
Moriyoshi
Rob
Moriyoshi Koizumi wrote:
On 2005/03/11, at 10:24, Marcus Boerger wrote:
Hello moriyoshi or any other XMLer,
please verify the --EXPECT-- d
On 2005/03/11, at 10:24, Marcus Boerger wrote:
Hello moriyoshi or any other XMLer,
please verify the --EXPECT-- data in test ext/xml/tests/bug32001.phpt
i am quite sure there are several mistakes in it.
Excuse me if I'm just missing something, what kind of mistake do
you want to address?
Moriyosh
1 - 100 of 283 matches
Mail list logo