On 2004/04/12, at 1:33, David Sklar wrote:
Attached is a patch that implements fputcsv() as a complement to
fgetcsv().
There are two things that still need improvement:
- It adds "\n" as a newline onto the end of each line. I think it
would be better to add a platform-specific line ending.
-
On 2004/06/26, at 3:36, Stefan Esser wrote:
I am asking, because this is not properly documented and atleast the
mbstring extension violates this.
mbstring extention doesn't actually use "input filter" stuff, but it
had initially been merged to SAPI as a ugly "hack" long before the input
filter wa
I made a patch for bug #28325.
I'd like to see this one applied by the time PHP5 gets out of the door.
http://www.voltex.jp/patches/bug28325-preliminary.patch.diff
Regards,
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2004/07/01, at 14:25, Andi Gutmans wrote:
Hi Moriyoshi,
The object handle is not a unique identifier. Different object types
(e.g. PHP objects, SimpleXML objects) can have the same object handle.
The real unique identifier is object handle + object handlers array or
more useful in your case,
class can rarely be
recognised wrongly with this code as long as blk (or mmap) call is sane
and it properly maps the physical memory to the VM space.
Moriyoshi
On 2004/07/01, at 16:03, Moriyoshi Koizumi wrote:
On 2004/07/01, at 14:25, Andi Gutmans wrote:
Hi Moriyoshi,
The object handle is not a
On 2004/07/07, at 14:18, Kamesh Jayachandran wrote:
In this case while making a copy og global_class_table to thread
specific class_table in a deep fashion. zend_hash_copy has to do the
double dereferencing which it can't being a generic fuinction.
Sorry, but I don't quite understand what you meant
On 2004/07/08, at 1:04, Kamesh Jayachandran wrote:
My question is very simple.
Please answer the following question.
1)Zend has global_class_table of type HashTable with a key as the class
name ('char*') and value of type 'zend_class_entry**'. True or False?
Keys are just strings and associated val
On 2004/07/08, at 14:41, Kamesh Jayachandran wrote:
The last parameter sizeof(zend_class_entry) of value say 292 to
zend_hash_copy indicate it to dereference the value of one of the
hashtable entry.
This value is of type zend_class_entry** which when dereferenced once
gives rise to zend_class_entry
On 2004/07/08, at 19:16, Kamesh Jayachandran wrote:
Hi Moriyoshi,
Sorry to copy the INIT_DATA macro in the mail.
#define INIT_DATA(ht, p, pData, nDataSize)
if (nDataSize == sizeof(void*)) {
memcpy(&(p)->pDataPtr, pData, sizeof(void *));
(p)->pData = &(p)->pDataPtr;
} else {
(p)
done (VPATH fix applied as well).
Joe Orton wrote:
>I think this file needs to be renamed; the 5.0.0 build fails using
>mbregex and pcre with bundled pcre, for instance, since the bundled pcre
>picks up the wrong php_compat.h and the #define pcre_* aren't picked up.
>
>Renaming it to php_onigurum
On 2004/07/20, at 14:10, Sara Golemon wrote:
Is there any reason there's no safe_pemalloc()?
I once had exactly the same thought. Probably because there'd be no need
for persistence, and stream folks now obviously need it :)
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
ersistent)?free(ptr):efree(ptr))
#define pecalloc(nmemb, size, persistent)
((persistent)?calloc((nmemb), (size)):ecalloc((nmemb), (size)))
#define perealloc(ptr, size, persistent) ((persistent)?realloc((ptr),
(size)):erealloc((ptr), (size)))
On 2004/07/21, at 0:57, Zeev Suraski wrote:
At 16:26 2
On 2004/07/21, at 6:11, Andi Gutmans wrote:
Looks good but why not rename the function to _safe_pemalloc()? (And
of course rename to safe_pemalloc() as you do later on.
Because it's there just for persistent allocation, while pemalloc() can
be used both ways.
Moriyoshi
--
PHP Internals - PHP Ru
Hi,
It seems 4.3.8 patches are not merged to PHP_4_3 yet.
Is there any reason to refrain from doing so?
Regards,
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2004/07/22, at 0:50, Stefan Esser wrote:
What patches are you speaking about?
Those which are likely intended for CAN-2004-0594.
For instance,
hallmark:~/Documents/Sources/php-src-4 moriyoshi$ cvs diff -r
1.512.2.53.2.1 main/main.c
Index: main/main.c
===
Hi,
The package includes a description how the test works. It basicly
consists of compiling PHP on your normal platform: f.e. OpenBSD
Apache2 CGI. You should just add --enable-memory-limit to your
standard configure line and turn register_globals on. The rest is all
explained in the package.
Is
What a stupid question I asked here... Nevermind.
Moriyoshi
On 2004/08/02, at 8:11, Moriyoshi Koizumi wrote:
Hi,
The package includes a description how the test works. It basicly
consists of compiling PHP on your normal platform: f.e. OpenBSD
Apache2 CGI. You should just add --enable-memory
Hi,
On 2004/08/28, at 5:15, Al Baker wrote:
I'm trying to find status on the multibyte support in PHP. The manual
shows the functions in mbstring to be experimental and it's hard to
find
evidence of how stable it really is.
Which manual says that mbstring is still experimental? :) it was marked
"
Hi,
On 2004/08/28, at 8:38, Al Baker wrote:
Thanks for the confirmation. The experimental warning appears on any
of
the individual help files for mbstring (e.g. mb_ereg).
Hmm, warnings seem to persist in manual pages of the multibyte regular
expression functions. I'll remove them later :)
Do you
On 2004/08/28, at 8:17, Sean Coates wrote:
Are these functions in fact non-experimental? If so, I will remove the
warning from the mb_* functions in the manual.
Yep, definitely. Thanks in advance :)
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
Hi,
Thank you for the patch. Cyrus extension is now in PECL
(http://pecl.php.net/) and I'm the primary maintainer of it.
I think the problems you pointed out were already addressed and
fixed in CVS. Please check out the source at
http://cvs.php.net/cvs.php/pecl/cyrus/ and send me a patch
if you sti
Seems like a documentation problem. Since its introduction
the iconv extension has never had such a function that converts the
HTTP queries into those of another encoding, so that setting
is useless at all. But there is the opposite function that
converts the output into another encoding.
Could you
On 2004/10/28, at 0:55, Sara Golemon wrote:
That said libsmb is GPL so any implementation would have to start from
scratch or live outside of php.net
AFAIK FreeBSD's libsmb is released under a BSD-style license.
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/smbfs/lib/smb/
Moriyoshi
--
PHP Inter
On 2004/10/27, at 23:28, Rob Richards wrote:
It adds support for file://localhost/ on all platforms as well as
adding the
file:/// support back under windows.
Other than that it doesnt change how the remote host stuff is handled.
Couldn't file://127.0.0.1/... or file://[::1]/... be valid URL's
for
On 2004/10/28, at 2:24, [EMAIL PROTECTED] wrote:
Moriyoshi Koizumi <[EMAIL PROTECTED]> writes:
AFAIK FreeBSD's libsmb is released under a BSD-style license.
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/smbfs/lib/smb/
That's not libsmb; rather, it's the kernel modul
On 2004/10/28, at 3:28, Rob Richards wrote:
From: Moriyoshi Koizumi
Couldn't file://127.0.0.1/... or file://[::1]/... be valid URL's
for the local resources?
To play it safe I would say no right now. The file uri stuff is being
worked on again:
http://www.ietf.org/internet-drafts/dra
On 2004/10/30, at 21:43, Klaus Reimer wrote:
I think this explains the misbehaviour. If I do a "setlocale(LC_ALL,
'de_DE')" then the PHP function resets LC_NUMERIC to "C". So what
chance have I to get the LC_NUMERIC configuration of a specific locale
now? Well, I think there was a good reason to
On 2004/11/03, at 17:11, Derick Rethans wrote:
It's assigned to me for now... I'll have a look at it this week. Does
somebody remember why we need to mangle the locale anyway by resetting
LC_NUMERIC to "C"?
Good to hear the problem is then going to be addressed.
According to the annotation, the cha
On 2004/11/03, at 18:57, Derick Rethans wrote:
I think a much better solution would be to use our own "strtod"
function
that isn't affected by locales then. I guess we could borrow a BSD
implementatino of it and modify this to our needs.
My +1 if some vote will take place.
See also:
http://marc.th
On 2004/11/03, at 22:31, Andrey Hristov wrote:
$c=array($a,$b);
var_dump($c,$d=serialize($c));
var_dump($e=unserialize($d));
$d[0]->a->prop=1;
var_dump($d);
?>
Did you mean "$e[0]->a->prop" by "$d[0]->a->prop"?
That looks like another issue:
a->prop = 1;
?>
Moriyoshi
--
PHP Internals - PHP Runtime
> > Did you mean "$e[0]->a->prop" by "$d[0]->a->prop"?
>
> Well, when I was writing the test I made a mistake which
> I saw later but my mistake lead to a PHP core dump.
Looks more like I should've read the mail more carefully :)
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing Lis
Hi,
Currently activation functions are called in the following order
on request startup:
1. zend_activate()
2. sapi_activate()
3. php_hash_environment()
4. zend_activate_modules()
Is there any good technical reason behind this order? I don't think
it does make much sense because php_hash_environmen
Hi there,
I'm now looking into the three extract() bugs related to
each other, namely bug #25708, bug #29493 and bug #31213.
It turned out after all that these problems are caused
by a inevitable zval separation on sending arguments
to the function and there seems to be no feasible workaround
for n
On 2005/01/02, at 21:23, Marcus Boerger wrote:
while i tried to improve performance of the array functions i
developed a
new pass type - pass as const which doesn't touch the passed variable
at
all and is compatible with temp vars, too. Maybe your problem here is a
reason to really implement that
On 2005/01/05, at 1:31, Andi Gutmans wrote:
At 06:26 PM 1/4/2005 +0900, Moriyoshi Koizumi wrote:
On 2005/01/02, at 21:23, Marcus Boerger wrote:
while i tried to improve performance of the array functions i
developed a
new pass type - pass as const which doesn't touch the passed
variable a
Now fixed in CVS. Thanks for the good report.
Moriyoshi
On 2005/01/10, at 22:30, Kamesh Jayachandran wrote:
Hi All,
The following script causes a segmentation fault in NetWare but not on
Windows or Linux versions of php-5.0.3
I can not attribute to NetWare instead I could see the defect in our
ext
On 2005/01/12, at 9:24, Andi Gutmans wrote:
Are you sure this is the right fix? After all, last_op->result.u.var
should already have a temporary variable assigned for when the opcode
was generated. When exactly did you find this is not the case?
As far as I checked, at least a temporary variable
On 2005/01/12, at 17:12, Moriyoshi Koizumi wrote:
However, it looks like the rule doesn't apply to the current HEAD.
Copy'n'paste mistake.. This part should have been like
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
LL, NULL, NULL, NULL, "sdot", NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
/* 8912 (0x22d0) */
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
/* 8928 (0x22e0) */
NULL, NULL, NULL
Hi Dmitry,
On 2005/01/12, at 18:28, [EMAIL PROTECTED] wrote:
patch for HEAD is incorrect.
You must not edit zend_vm_execute.h directly. You must edit
zend_vm_def.h and then generate zend_vm_execute.h with zend_vm_gen.php.
See README.ZEND_VM for more details.
Excuse me for my ignorance & thank you f
On 2005/01/13, at 15:21, <[EMAIL PROTECTED]> wrote:
I don't quite agree with you. Indeed it's semantically wrong,
yet I think we leave it to behave as in ZE1, in terms of
backwards compatibility.
I don't think we must make compatibility for bugs.
Users don't consider a certain behaviour that lasts
Ilia,
While your opinion that we shouldn't count on the "filename"
attribute in multiparted queries is quite to the point,
your patch totally disregards the old behaviour.
We must neither use php_basename() for pathes of a spec
different from that defined by the platform which is determined
in comp
I've experienced the same. The following improper change was left
forgotten when Jani applied his fix that is eventually correct.
http://cvs.php.net/diff.php/php-src/acinclude.m4?r1=1.275&r2=1.276&ty=u
Moriyoshi
On 2005/02/09, at 3:55, Christian Stocker wrote:
Hi
After a long look into the configur
On 2005/02/10, at 22:13, Jani Taskinen wrote:
Please blame the correct people, not always by default ME. :)
I never touched this macro, it was andrei:
I didn't blame you, but I just wanted to say you did it right :)
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
On 2005/02/17, at 22:28, Joe Orton wrote:
So it is a bit of a tricky trade-off...
How about #ifdef'ifying it? It's lame though...
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
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.
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
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
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/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
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
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
&
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
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
>&
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.
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
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
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
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,
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
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
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
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
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
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
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
>
>
&
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'
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
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
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
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,
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
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)
>
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
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
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
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
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
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.
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()
>
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 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 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
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 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
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
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
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
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
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
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
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
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
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:
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
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 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
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
1 - 100 of 283 matches
Mail list logo
