In response to the suggestions of Thies and others, I went back through
tidy and made a number of improvements to the API that I think should
make most people happy and make tidy ready for B3. Notable changes are:
Multiple Document Processing
$a = tidy_parse_file("http://www.php.net/";);
Hi there!
What you guys think about make array_reverse() a variable referenced
function. I mean something like:
function new_array_reverse(&$array){
$array = array_reverse($array);
}
Is it possible to make a function work both ways?
$array = array_reverse($array);
and
array
On December 13, 2003 05:52 pm, Moriyoshi Koizumi wrote:
> I haven't denied it. That said, multibyte facility is not so fancy
> as XML, but quite essential so as to enable most applications to work
> well under every environment.
Bullshit. Only application that need to support multibyte strings nee
On 2003/12/14, at 7:33, Ilia Alshanetsky wrote:
Percentages aside you cannot deny the fact that not every application
needs
multibyte support (whether this is a majority or 50/50 does not
matter).
If a user needs to use multibyte they may need to do a little
searching to
find a provider that su
> From: Ian Eure [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 13, 2003 11:23 PM
> I have been developing packages for PEAR, and I would like to keep them in
> a publicly accessible repository.
Err that is not quite how it works.
Your code doesn't have to be finished to make it into PEAR
I have been developing packages for PEAR, and I would like to keep them in a publicly
accessible repository.
Some of my PEAR work can be seen here: http://www.websprockets.com/~ieure/PEAR/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
On December 13, 2003 04:46 pm, Moriyoshi Koizumi wrote:
> > The critical point of this entire discussion is about NOT forcing
> > choices on
> > people who do not want/need them. There is no good reason to force
> > multibyte
> > version of fgetcsv() on every single user, when there are not one but
On 2003/12/14, at 6:46, Moriyoshi Koizumi wrote:
I made is the best portable and the fastest code, it's probable
that there are a far better code.
s/there are/there'd be/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2003/12/14, at 6:19, Ilia Alshanetsky wrote:
On December 13, 2003 03:53 pm, Moriyoshi Koizumi wrote:
Could a quarter be a minority?
Unless the rules of mathematics had changed 25% is still a minority.
You also
forget that there are plenty of people who compile extensions and
never end
up usin
On December 13, 2003 03:53 pm, Moriyoshi Koizumi wrote:
> Could a quarter be a minority?
Unless the rules of mathematics had changed 25% is still a minority. You also
forget that there are plenty of people who compile extensions and never end
up using them.
The critical point of this entire dis
On 2003/12/14, at 5:55, Ilia Alshanetsky wrote:
On December 13, 2003 03:27 pm, Moriyoshi Koizumi wrote:
As a sidenote, this unrealistic statistics appear to be quite unreal.
phpinfo() => 186,000 (pages) [1]
phpinfo() mbstring => 8,330
phpinfo() Server API Configure Command => 16,800
phpinfo() Ser
On December 13, 2003 03:27 pm, Moriyoshi Koizumi wrote:
> As a sidenote, this unrealistic statistics appear to be quite unreal.
>
> phpinfo() => 186,000 (pages) [1]
> phpinfo() mbstring => 8,330
> phpinfo() Server API Configure Command => 16,800
> phpinfo() Server API Configure Command mbstring =>
On 2003/12/13, at 9:36, Ilia Alshanetsky wrote:
There is a good chance you are correct. However my assumption is not
without
bases, please consider the following statistic:
Google finds 185,000 (or so) phpinfo() pages, when mbstring is added
to the
search query only 8150 pages are found. That l
Timm Friebe wrote:
On Thu, 2003-12-11 at 00:29, Alan Knowles wrote:
This has been discussed before on the mailing list, (either this or ZE2)
and rejected. - have a look through the archives
http://zend.com/phorum/read.php?num=6&id=242&loc=0&thread=242
- Timm
THanks for the thread, i
Sara Golemon wrote:
> pollita Sat Dec 13 13:48:40 2003 EDT
>
> Modified files:
> /php-src/main php_streams.h
> /php-src/main/streams streams.c
> Log:
> Fix Win32 Build. mkdir/rmdir are macros
That fixed it, thanks,
Sebastian
--
Sebastian Bergmann
http://seb
Nevermind, I forgot I could just look at the compile log on snaps. Looks
like that's exactly the problem. I'll rename these methods to something
less conflicting.
-Sara
"Sara Golemon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm having to guess on the translation here, but
I'm having to guess on the translation here, but it's sounding like it
doesn't think mkdir is an element of php_stream_wrapper_ops. Although there
seems to be a mention of mkdir/rmdir as macros in there? Perhaps renaming
them to stream_mkdir/stream_rmdir will keep windows happy.
Can you translat
On 2003/12/14, at 1:07, Rasmus Lerdorf wrote:
On Sat, 13 Dec 2003, Jan Schneider wrote:
I have to agree. While in the past it helped mb users to turn on
overloading
if they wanted to use our framework, it will now break it. This is
because
we now explicitely use the str*() function for byte-wise
On Thu, 2003-12-11 at 00:29, Alan Knowles wrote:
> This has been discussed before on the mailing list, (either this or ZE2)
> and rejected. - have a look through the archives
http://zend.com/phorum/read.php?num=6&id=242&loc=0&thread=242
- Timm
--
PHP Internals - PHP Runtime Development Mailing
On Sat, 13 Dec 2003, Jan Schneider wrote:
> With the current implemention and assuming that mbstring overloading is
> turned off, I can. This not documentated, but I'd still consider a change
> of this behaviour an huge bc break.
The documentation states "characters" and nowhere does it say the si
Zitat von Rasmus Lerdorf <[EMAIL PROTECTED]>:
> On Sat, 13 Dec 2003, Jan Schneider wrote:
> > Maybe. Due to PHP lacking byte stream functions, working with str* is
> the
> > only solution atm.
>
> And my contention is that there is no way to do this right now. If you
> rely on a str*() function t
Sara Golemon wrote:
pollita Fri Dec 12 23:07:19 2003 EDT
Modified files:
/php-src/main php_streams.h
/php-src/main/streams streams.c plain_wrapper.c userspace.c
/php-src/ext/standard file.c ftp_fopen_wrapper.c
http_fopen_wrapper.c ph
On Sat, 13 Dec 2003, Jan Schneider wrote:
> Maybe. Due to PHP lacking byte stream functions, working with str* is the
> only solution atm.
And my contention is that there is no way to do this right now. If you
rely on a str*() function to do this your application is broken since you
cannot reas
Zitat von Rasmus Lerdorf <[EMAIL PROTECTED]>:
> On Sat, 13 Dec 2003, Jan Schneider wrote:
> > I have to agree. While in the past it helped mb users to turn on
> overloading
> > if they wanted to use our framework, it will now break it. This is
> because
> > we now explicitely use the str*() functi
Hello Internals,
I´m writing some material about PHP5 and I have
some doubts about destructors. If someone would like
to help me, it can be done in off.
It´s basically how is the order that shutdown
occurs in PHP5:
- When exactaly __destruct() is called?
- What resources still availa
On Sat, 13 Dec 2003, Jan Schneider wrote:
> I have to agree. While in the past it helped mb users to turn on overloading
> if they wanted to use our framework, it will now break it. This is because
> we now explicitely use the str*() function for byte-wise string
> manipulation and their mb_*() equ
Cesare D'Amico wrote:
Alle 16:09, sabato 13 dicembre 2003, Sebastian Bergmann ha scritto:
- Does
interface C implements A, B {}
do what I want?
This syntax sounds strange to me: an interface should'nt _implement_
other interfaces... sounds as nonsense.
That might be part of his
Hi,
for the new windows build system, what version of cscript.exe do I need
(I seem to have 5.6 in C:\winnt\system32, which does not recognize
/nologo as an option)?
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alle 16:09, sabato 13 dicembre 2003, Sebastian Bergmann ha scritto:
> - Does
>
> interface C implements A, B {}
>
> do what I want?
This syntax sounds strange to me: an interface should'nt _implement_
other interfaces... sounds as nonsense.
Ciao
ce
--
Cesare D'Amico - bos
While porting PicoContainer to PHP 5 I noticed that we currently do not
support syntax to have an interface extend more than one parent
interface.
For instance
interface A {}
interface B {}
interface C extends A, B {}
is possible in Java while PHP 5 currently throws a synta
Zitat von Derick Rethans <[EMAIL PROTECTED]>:
> On Sat, 13 Dec 2003, Moriyoshi Koizumi wrote:
>
> > Overloading is evil, because functions like substr() are often
> > used to splice a certain length of octets byte-wise while mb_substr()
> > treats the sequence of octets on a character-basis. And o
Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>:
> > The cool thing that mbstring provides is transparent overloading of
> > some
> > of the common string manipulation functions. This means that at least
> > for
> > a subset of applications, even though they may not have been written
> > with
> >
On Fri, 12 Dec 2003, Ilia Alshanetsky wrote:
> On December 12, 2003 08:54 pm, Moriyoshi Koizumi wrote:
> > And overloading
> > cannot be turned on in scripts, this prevents us from writing portable
> > scripts.
>
> Not entirely true, while you cannot enable it from with a script you can
> enable i
On Fri, 12 Dec 2003, Rasmus Lerdorf wrote:
> We need to move towards a uniform platform that works for everyone without
> putting undue strain on either side.
Sure we do, but not at a 200-250% performance loss.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
On Sat, 13 Dec 2003, Moriyoshi Koizumi wrote:
> Overloading is evil, because functions like substr() are often
> used to splice a certain length of octets byte-wise while mb_substr()
> treats the sequence of octets on a character-basis. And overloading
> cannot be turned on in scripts, this preven
35 matches
Mail list logo
