Hey Greg,
This looks very promising. Great to see that you took those feedbacks
and really attacked them leading to a huge improvement in phar (should I
say night and day :) I think you've really accomplished a lot in these
few months.
Are there any docs which describe the transparent fron
> That part is completely different. That's at the display level.
> Replacing it in the backend makes no sense to me. Don't use
> utf8_decode. Use iconv() so you know what the heck is going on.
:)
iconv() will stop on conversion error and return partial string or empty
string. It will require
Peter Brodersen wrote:
> http://php.net/xml also documents this replacement:
> ==
> If PHP encounters characters in the parsed XML document that can not be
> represented in the chosen target encoding, the problem characters will be
> "demoted". Currently, this means that such characters are replace
On Mon, 28 Jan 2008 17:26:48 -0800, in php.internals [EMAIL PROTECTED]
(Rasmus Lerdorf) wrote:
>It would be a horrendously bad idea to replace invalid chars with some
>other valid char. Way worse than returning nothing. Think about what
>would happen in a regex, for example, if a user was able t
On Mon, 28 Jan 2008 17:26:48 -0800, in php.internals [EMAIL PROTECTED]
(Rasmus Lerdorf) wrote:
>php -r '$a="abcd".chr(0xE0);echo
>iconv("utf-8","utf-8",$a)."\n".utf8_decode($a);' | od -t x1
>
>00061 62 63 64 0a 61 62 63 64 03
By the way, the 03 in your result is a bit spurious. F
On Mon, 28 Jan 2008 17:26:48 -0800, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>> On the other hand utf8_decode() also expects the input to be UTF-8
>> encoded, but it replaces incomplete sequences with the character "?".
>
>utf8_decode() doesn't replace invalid chars with a ?
>
>e
Peter Brodersen wrote:
> On Fri, 25 Jan 2008 14:22:52 -0800, in php.internals [EMAIL PROTECTED]
> (Stanislav Malyshev) wrote:
>
>>> Should really theses functions discard the whole string for a single
>>> incomplete sequence ?
>> I think since it is not possible to recover true content of the str
Pierre Joye wrote:
>>> for ext/zip, or zip64, but zip64 would also be trivial to add to phar,
>
> It is already implemented. We are working on portability issues.
> That's why I put the custom stream support as the top priority, it is
> the way to go to solve almost portability issues.
Which is?
On Fri, 25 Jan 2008 14:22:52 -0800, in php.internals [EMAIL PROTECTED]
(Stanislav Malyshev) wrote:
>> Should really theses functions discard the whole string for a single
>> incomplete sequence ?
>
>I think since it is not possible to recover true content of the string,
>it is ok to return failu
I am trying to cross compile PHP 5.2.5. I have tried many combinations
of parameters
to configure, but find that the build keeps wanting to use native tools
or link with native
libraries. Has anyone been successful in cross compiling for ARM. I
intend to use PHP
on an embedded web server and wou
On Jan 28, 2008 10:30 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > However I find your actual positions confusing and each mails bring
> > opposing arguments about the shared work between other archives
> > extension and phar. Can you clarify your view please?
>
> Essential: nothing
> Optional: bz2
However I find your actual positions confusing and each mails bring
opposing arguments about the shared work between other archives
extension and phar. Can you clarify your view please?
Essential: nothing
Optional: bz2, spl, zlib
Completely different and nothing whatever to do with phar: ext/zip
On Jan 28, 2008 9:38 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> Pierre Joye wrote:
> > Hi Greg,
> >
> > On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> >
> >>> Current status of phar addresses most of these criticisms:
> >>>
> >> Looks impressive, great work!
> >>
> >>
Pierre Joye wrote:
> Hi Greg,
>
> On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
>>> Current status of phar addresses most of these criticisms:
>>>
>> Looks impressive, great work!
>>
>>
>>> phar implements zip support with native PHP code, enabling some fea
On Jan 28, 2008 8:56 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > I think it is a good thing to require ext/phar even for the read
> > operations. It certainly allows a shit load of optimization and tricks
> > that will never be possible otherwise. But Greg or Marcus will give us
> > a better answe
I think it is a good thing to require ext/phar even for the read
operations. It certainly allows a shit load of optimization and tricks
that will never be possible otherwise. But Greg or Marcus will give us
a better answer :)
? It's a < 7kb add-in stub to make it open-access.
- Steph
--
PHP In
Hi Steph,
On Jan 28, 2008 8:38 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > Exactly and I'm rather surprised to see this post given the recent
> > efforts to export the Zip symbols to allow any extension to share the
> > zip features.
>
> I think until the zip features were shared the library's l
Hi Pierre,
Exactly and I'm rather surprised to see this post given the recent
efforts to export the Zip symbols to allow any extension to share the
zip features.
I think until the zip features were shared the library's limitations hadn't
been too obvious.
Most of the discussions have been
Hi Greg,
On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Current status of phar addresses most of these criticisms:
>
> Looks impressive, great work!
>
> > phar implements zip support with native PHP code, enabling some features
>
> I am a bit confused about native PHP c
Stanislav Malyshev wrote:
>> Current status of phar addresses most of these criticisms:
>
> Looks impressive, great work!
>
>> phar implements zip support with native PHP code, enabling some features
>
> I am a bit confused about native PHP code here - we are talking baout
> an extension, right? So
On Jan 28, 2008 2:09 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > phar's zip support. The tests simply need to be modified to create the
> > zips using pecl/phar and copy the filename to one phar doesn't already
> > know about, and the failures will go away.
>
> I thought you wanted 'pure' zips fo
phar's zip support. The tests simply need to be modified to create the
zips using pecl/phar and copy the filename to one phar doesn't already
know about, and the failures will go away.
I thought you wanted 'pure' zips for the tests - that told me!
So how do I create a zip with ext/phar then, o
Marcus Boerger wrote:
> Hello Steph,
>
> so you mean we do not have to confuse our uses by solution 2a becasue we
> only have the minimum subset of zip in phar that ohar actually needs?
>
>
Although phar can be used to create and read any zip archive, it will
automatically add the file ".ph
Hi Marcus,
so you mean we do not have to confuse our uses by solution 2a becasue we
only have the minimum subset of zip in phar that ohar actually needs?
Yep. But Greg can explain better.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
Current status of phar addresses most of these criticisms:
Looks impressive, great work!
phar implements zip support with native PHP code, enabling some features
I am a bit confused about native PHP code here - we are talking baout an
extension, right? So what exactly is meant here?
Also, a
Hello Steph,
so you mean we do not have to confuse our uses by solution 2a becasue we
only have the minimum subset of zip in phar that ohar actually needs?
marcus
Monday, January 28, 2008, 7:01:42 PM, you wrote:
> Hi Marcus,
>> 1. include phar in core
>> 2.a. add ext/zip compatible funct
Hi Marcus,
1. include phar in core
2.a. add ext/zip compatible functions and replace ext/zip
2.b. change ext/zip to use zip lib of pahr and add stream support
3. drop ability to disable spl
I have no preference between 2a or 2b. Though technically I guess that 2a
is probably much faster to
Hello Gregory,
My point of view is this action list:
1. include phar in core
2.a. add ext/zip compatible functions and replace ext/zip
2.b. change ext/zip to use zip lib of pahr and add stream support
3. drop ability to disable spl
I have no preference between 2a or 2b. Though technically
Marcus,
Thanks for looking in more detail.
> I checked it out in more detail and it is indeed broken as in it is not
> consistent:
> [EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { protected static $p=1; } class
> B extends A { protected static $p=2; } ReflectionClass::Export("B");'
> -> works =
Hi all,
I have been working hard on pecl/phar to address several issues raised
last May when it was first mentioned on the list, and would like to
summarize where phar stands today with regards to those criticisms:
Criticisms:
* non-standard file format
* limited introspection
* no support fo
Marcus Boerger schreef:
Hello Robin,
I checked it out in more detail and it is indeed broken as in it is not
consistent:
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { protected static $p=1; } class B extends A
{ protected static $p=2; } ReflectionClass::Export("B");'
-> works == 2 properties
Hello Robin,
I checked it out in more detail and it is indeed broken as in it is not
consistent:
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { protected static $p=1; } class B
extends A { protected static $p=2; } ReflectionClass::Export("B");'
-> works == 2 properties
-> but should fail because
Hi All,
A property can share it's value with it's parent but methods need to call
parent::$method() and this is not done by default that is why the behavior
is different. Is that the right behavior?! I really don't know. I think the
inheritance of the static methods as two distinct methods is righ
Hi Marcus,
Thanks for the prompt reply and explanation. I have some further
questions though:
> If the base class had the property defined as private
> then the property is private to that specific class and not directly
> accessible by derived classes that is it's name gets prefixed with the cla
Hello Robin,
expected behavior. The static property is inherited to the sub class. As
that subclass repeats the declaration with a different visibility you simply
change the visibility. If the base class had the property defined as private
then the property is private to that specific class and
Hi all,
If a protected static property is overridden by a public static
property, both properties share the same value:
This behaviour feels strange to me, because:
1. It only applies to that specific combination of visibility
modifiers. If you change A::$a to public OR B::$a to protected, the
Hei,
I've been deliberating looking at all the comments regarding PDO2 and the
CLA proposal to allow for some more thinking-before-writing. My first
impression was not much unlike Pierre's though. Now that I have spend some
time thinking about it, I am replying with my thoughts and comments. They
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (63 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
43884 Open Object model
43885
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (631 total including feature requests)
===[*Compile Issues]==
43389 Open configure ignoring --without-cdb flag
===[Apa
39 matches
Mail list logo
