On Thu, 13 Mar 2003, Joe Orton wrote:
Commit of autoconf code cleanups to php4 (4_3 branch) needed
for systems which have system libraries in /usr/lib64 rather
than /usr/lib.
Please post patches.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
On Wed, 12 Mar 2003, Jani Taskinen wrote:
Of about 20 emails today, 6 were posted to wrong mailing
list. And one of those generated a 5 email thread about not
posting to wrong mailing list. (counting this one :)
So I suggest we finally make this list MODERATED.
-1.
On Wed, 12 Mar 2003, Andrey Hristov wrote:
Few minutes ago I found the following behaviour somehow wierd for me :
Known bug, the associativity of the ternary operator has been
broken since ages in the engine. It's on the won't be
fixed sheet, because of BC concerns.
- Sascha
if even that description doesn't work, then nothing would work, not even
changing the name.
Well, it is obvious that some folks don't read that
description and simply move forward, because php-dev sounds
about right. They are PHP developers and so a list called
php-dev makes
Let's ask the mysql guys, they did change the name too. (I think that we
atleast agree that the noise is annoying, right?)
Not really. Maybe I'm more used to skipping noise.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
Aside from renaming the php-dev list, we should remove the 'PHP and Zend
[snip]
Sounds good.
Then another item that might be considered if it is not already done,
allowing posts only from those that have cvs access. A second
conditional list of allowed posters can be added that are
Yes, because getting a cvs account is just *s* hard.
The problem is that you easily lose valuable postings when
you force people to go through some restrictive system.
I'm especially worried about inter-group communication. E.g.
where php-dev is involved in a discussion
You lose:
You lose time for implementing and maintaining this system,
and you lose time for moderating emails. You also reduce the
incentive to contribute.
Again, let's take the less intrusive steps first and leave
the heavy handed ones as a last resort.
- Sascha
--
* trying to build php4 head for two days, only to be told that I
should be building PHP_4_3 or php5 head.
Yes, it should be noted that you can use PHP_4, PHP_4_3 or
php5.
* forgetting about re2c, which is not mentioned anywhere that I could
find, but I found through freshmeat and had
Jani,
1. Rename the list to php-group
bad name for obvious reasons. Georg's suggestion of
internals sounds ok to me. Or hackers from the FreeBSD
community.
2. Separate the list entries in mailing-lists.php [DONE!]
3. Apply the same system as is in use for
I wouldn't consider 3rd one that drastic.
It has worked very well for me, I haven't got any spam
to my php.net addy, but people who really wanted to send me
email got through..
Well, maybe I am an exception, but I usually don't bother to
register myself anywhere,
I would, but the problem is that the snaps are always updated, and the
The constant names are
php4-latest.tar.bz2
php4-STABLE-latest.tar.bz2
php5-latest.tar.bz2
old files deleted, and my QA requires that the sources be always
available at the same URL.
The sources are
# ./flex --version
flex 2.5.27
What does this output?
flex -V -v --version 2/dev/null
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 7 Mar 2003, David Hill wrote:
What does this output?
flex -V -v --version 2/dev/null
- Sascha
# flex-2.5.27/flex -V -v --version 2/dev/null
flex 2.5.27
This should be parsed correctly. What kind of OS and /bin/sh
do you have?
What does
# cvs co -rPHP_4_3 php4
Or for experimental code which should not go into a release
branch like PHP_4_3
$ cvs co -r PHP_4 php4
These are the ONLY useful and up-to-date modules at the moment.
I'm planning on syncing those changes which have been
forgotten to
Can I check this into PHP_4 PHP_4_3 ?
Nope :)
PHP_4 is ok.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Thanks ! That does help some. I don't get the buildconf warnings now,
but I am still getting shell syntax errors in the resulting configure
script. arrrgh :-p
Make sure that autoconf-2.13 is completely reinstalled
(including rm -rf autoconf-2.13). Otherwise, the frozen
files which
Sure, but there is no point in doing that... as there won't be released
from that branch anyway.
Well, that depends on the needs of our users.
Regardless, testing new SAPIs/extensions is quite a burden in the
PHP 5 context, because you have two moving targets then -- the
engine
Please supply 1 as the 6th argument to PHP_NEW_EXTENSION.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 4 Mar 2003, George Schlossnagle wrote:
Interesting.
I don't know what the ISO standard say, but mathematically a a % b will
always return you an integer 0 = a%b b (since there are no negative
numbers in canonical representation of Z/bZ). I guess perl/python/tcl
ddecided to adhere
Yeah, I read that in the bug report and confirmed that as the intended
behavior in C. What I meant was 'regardless of what the ISO standard
says, thats not a standard mathematical definition.'
Well, the standard mathematical definition
r = a mod b = a = floor(a/b) * b + r
So for 4.3.2, we add the OnUpdateLong() and replace
all the calls to OnUpdateInt() to use that instead
and we leave the OnUpdateInt() behaviour same as it was.
This shouldn't cause BC problems then..?
Yes.
And in 5.0.0 we change OnUpdateInt() to use ints.
No,
Don't they have to do that anyway..? :)
No, why? For example, the session extension will be largely
unchanged. The same code works in PHP 4 and 5.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Well, Perl can lean the other way as well actually. Try this:
Is there some documentation why the default is as it is?
You will see it gives you -6. Like I said, it comes down to which way you
truncate. Programmers tend to think that something like (int)(-3.4)
should result in -3. If
On Tue, 4 Mar 2003, Jani Taskinen wrote:
Yup, that was the idea. I'll first change them
all to OnUpdateInteger, and then use your patch
to change the ones that need to be long to use OnUpdateLong.
Is there any specific reason why a single API (OnUpdateLong)
is not
On Mon, 3 Mar 2003, Harald Radi wrote:
sorry for this naive question, i just realized that we have php 4.5.x
snapshots on snaps.php.net, i assume this is the PHP_4 branch. does that mean
that PHP_4_3 and PHP_4 should kept synchronized ?
Yes, general fixes can be committed to the PHP_4
On Mon, 3 Mar 2003, Sebastian Bergmann wrote:
Harald Radi wrote:
PHP_4
But why is the version of the PHP_4 branch 4.5, and not 4.4?
4.4 was used already in HEAD for some time. So we skipped it.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
how do I use PHP_CHECK_FUNC to make it work even when the extension is
shared?
You can manipulate LDFLAGS directly:
php_save=$LDFLAGS
LDFLAGS=-L$dir $LDFLAGS
.. check ..
LDFLAGS=$php_save
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe,
So I think the fix of adding OnUpdateLong() is the correct fix.
I was under the impression that OnUpdateInt was actually
expecting a long. I remember changing some int's to long's
to address 64 bit issues. Do I remember this incorrectly?
- Sascha
--
PHP Development Mailing
No, you are correct but misunderstood me. We should introduce
OnUpdateLong() for ppl using longs and use OnUpdateInt() for ppl who want
to use ints.
Well, and how are you planning to mitigate the BC issues?
Remember that not all extension code is under our direct
control.
-
I think that simply adding OnUpdateLong and deprecating
OnUpdateInt is fine while retaining its current semantics. I
just don't see any value in changing the meaning of
OnUpdateInt; at least that's how I interpreted Andi's
message.
- Sascha
--
PHP Development Mailing
That's also an option but I think OnUpdateInt() is confusing and how do we
stop ppl from using it in new extensions which who's commit messages aren't
followed via php-cvs?
I volunteer to set up a cron job which greps for OnUpdateInt
:-)
The problem with _changing_ the existing
Or more accurately:
PHP5 - co php5
PHP4.3 - co -rPHP_4_3 php4
PHP4 - co -rPHP_4 php4
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
I implemented the native interface - inifile_*() functions - in order to be
able to work with group and name instead of the single key format that
is necessary using the dba interface.
Sounds to me like another issue which could have been easily
solved by using a thin PHP layer.
-
On Sun, 23 Feb 2003, Marcus Börger wrote:
After fixing hopefully last problems in the inifile handler i made
up a patch which introduces a native interface to the inifile handler.
I did this because the [group]name key format is not intuitive.
Care to explain what it does? Does it feed
On Fri, 21 Feb 2003, Jani Taskinen wrote:
I object! :) It should be one function with extra parameter
to decide the action..
Please put this code into ext/completely_unneeded.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
I'm not 100% sure if we want this feature, but perhaps it is worth
revisiting that patch.
Alternatively, I would suggest to teach the submitter of that
patch regarding fopen, fwrite, implode. He might have
overlooked those existing functions.
- Sascha
--
PHP Development
On Fri, 21 Feb 2003, Derick Rethans wrote:
On Fri, 21 Feb 2003, Sascha Schumann wrote:
I'm not 100% sure if we want this feature, but perhaps it is worth
revisiting that patch.
Alternatively, I would suggest to teach the submitter of that
patch regarding fopen, fwrite
I meant a *plain* file_put_contents:
That must be one of the most useless function proposals I've
seen so far.
Now, if the function could atomically replace file contents,
then it would be something entirely different.
But a simple wrapper for a two-line fopen/fputs? Get
n Fri, 21 Feb 2003, Dirkjan Ochtman wrote:
That's like one of those functions I've written myself and have to include
in about every project I write...
I think it's a Good Thing.
Well, I fully understand that. I just disagree with the idea
that this utility function should become
implode) and fclose. However, IMO this wrapper is very useful since it
simplifies commonly used code a great deal and even makes it slightly faster
since the wrapper is in C rather then in PHP.
Oh, come on. Put it into a utility library; this does not
belong into the core of PHP. Or
On Mon, 17 Feb 2003, David Gillies wrote:
OK, I've been using PHP since about six months after
Rasmus decided to share his brainchild with us. Can
someone PLEASE point me to the appropriate mechanism
to contribute my own modules?
Apply for a CVS account first, so that you can
simply
On Thu, 13 Feb 2003, Marcus Börger wrote:
I updated all m4,autoconf libtool AND now i can no longer build php
Anybody help?
Get autoconf-2.13 and m4-1.4 (not 1.4o) from ftp.gnu.org.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
On Fri, 14 Feb 2003, Marcus Börger wrote:
At 01:57 14.02.2003, Jani Taskinen wrote:
On Fri, 14 Feb 2003, Marcus Börger wrote:
AC_PROG_LIBTOOL is defined in libtool.m4,
which should come from libtool installation.
Most likely you've just got mixed up versions in your
On Fri, 14 Feb 2003, Rickard Andersson wrote:
I would very much like a complete list of all functions in PHP 4.3.0. Is
there a way to generate this from the source tree or do I have to go through
it all by hand?
Try http://www.zugeschaut-und-mitgebaut.de/php/
There are also some awk
On Tue, 11 Feb 2003, Hans Prins wrote:
Thx guys,
I'll play around with it some more and see if I can secure it some more :)
Keep in mind that many proxies remove the referrer
information.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
Markus,
here is a patch against the current CVS which
- trims +100 lines of code from spprintf.c
- introduces an overflow detection in STR_TO_DEC
- eliminates dead code (e.g. assert(foo); if (foo) {..})
- removes unused macros from the original code
- simplifies code
Why then this comment? Did you forgot to remove it.
Yes.
Hey cool i just thought about doing that, too. You're really fast
Unfortunatley i haven't yet the time to try it out but it looks good.
Does it have any known problems?
No, but then there are no real test cases which
On Mon, 10 Feb 2003, Justin Erenkrantz wrote:
In the spirit of code rather than discussions that lead nowhere, here is
a contribution that removes the filter code from PHP's sapi layer for
Apache httpd-2.0. Until Zend can cleanly support streamy input, PHP
should probably just use this
On Mon, 10 Feb 2003, Marcus Börger wrote:
Hi,
the current implementation of uniqid set the more entropy default
true for CYGWIN and false for the rest. CYGWIN must use more
entropy because it does not produce new values after usleep(1)
necessarily. However usleep(1) should nowadays be very
On Tue, 11 Feb 2003, Jani Taskinen wrote:
The old Apache seems to puke on that stuff you added
some time ago and now merged to the PHP_4_3 branch.
Apache version: IBM HTTP Server 1.3.19.3 (Apache 1.3.20)
It propably needs some #ifdefs around it?
Thanks for the heads
On Tue, 11 Feb 2003, Jani Taskinen wrote:
The old Apache seems to puke on that stuff you added
some time ago and now merged to the PHP_4_3 branch.
Apache version: IBM HTTP Server 1.3.19.3 (Apache 1.3.20)
For anyone who cares, these packages can be downloaded for
free
Can anyone point me to a possible solution for this?
1. Use SSL.
2. Throw away an existing session id, if a user authenticated
successfully (e.g. destroy the old session, and copy the
data into a new one).
3. Provide a logout button which destroys the session.
-
On Fri, 7 Feb 2003, Uwe Schindler wrote:
I got a CVS account for maintenace of the NSAPI SAPI module.
If I try to commit a change, I get the following error:
CVSROOT=:pserver:[EMAIL PROTECTED]:/repository
Access denied: insufficient karma (thetaphi|php4/sapi/nsapi)
Contact
FYI
- Sascha
-- Forwarded message --
Date: Tue, 04 Feb 2003 21:24:36 -0600
From: Robert Boehne [EMAIL PROTECTED]
To: Lars Hecking [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: To sed or not to sed
Lars,
You're in luck! CVS Libtool goes to great pains to ensure
There should be another version of 'sed' in Solaris which can handle
the long lines though. No idea why they have 2 versions.
IIRC that is due to Solaris' BSD heritage. Solaris 1 (SunOS 4)
was based on BSD (from the University of California,
Berkeley, hence ucb) and they
On Tue, 4 Feb 2003, Melvyn Sopacua wrote:
At 17:29 4-2-2003, you wrote:
btw. It seems like that test I added for the broken
sed is not working on some systems. Any ideas why?
That's the grep -E part :)
Just use `egrep' unless any1 knows of a system that doesn't carry egrep?.
On Fri, 31 Jan 2003, [ISO-8859-15] Kai Schröder wrote:
That can be done, but that means 12 commits a day for a single file. I
dont think that's a good idea.
That's true. Now we have round about 30 commits each day. 12 more will make
less than 5.000 blocks (5MB for 1k-blocks) more disk
How is that possible?
I don't think it is, because it needs to be done at checkout time, not at
build time.
What are you smoking?
That's a one line addition to the snapshot script.
- Sascha, creator, snaps.php.net
--
PHP Development Mailing List http://www.php.net/
To
For manual checkouts that has nothing to do with snapshots, so he
isn't smoking anything.
echo test -r CHECKOUT_TIME || date CHECKOUT_TIME buildconf
would be sufficient for that case. It's not perfect, because
it is conceivable that someone does not run buildconf
It's not actually, as we were just trying to *solve* this problem and
prevent getting test results with the wrong date/time.
So what happens if I do this?
cd php4
cvs upd
and a day later do this?
cd php4/ext/standard
cvs upd
What is the checkout date
I've no idea, do you? I think we just should not allow submissions with
test results if they're not made by a snapshot or our phport.sh thingy
for automatic testing.
If that phport.sh thingy reliably ensures the integrity of
the source files, it could work.
Have CVS $Id$'s been
On Fri, 31 Jan 2003, Derick Rethans wrote:
On Thu, 30 Jan 2003, Sara Golemon wrote:
Only one complaint.
snip
So, we could relegate those VERY few who might've used that fourth parameter
already to the read the changelog or suffer bucket, ornot.
I think this group of people is
I suggest to check out
http://citeseer.nj.nec.com/navarro01fast.html
The presented BNDM algorithm is one of the fastest string
searching algorithm while being easy to implement. Its main
loop is faster than the naive str_replace implementation(*).
Check out a C test
On a related topic, the 'boyer' option of str_replace isn't even
documented. That alternate method of performing str_replaces look like
it's a bit more efficient (no benchmarkes atm) but I'm wondering if
there's a specific reasons why it wasn't documented yet.
The BM algorithm is
One last optimization to save memcpys when needle_len == str_len (thanks
again ilia):
Actual Patch:
http://169.229.139.97/test/str_ireplace.diff-5.txt
Resultant string.c for easy reading:
http://169.229.139.97/test/string-5.c
I've heard enough Ayes over Nays (here, in bugs.php.net, and
files list. It's handy and nice to normalize the path here, but it is
really really expensive!
..only on systems with ultra slow syscall setup procedures
(e.g. Solaris) or lack of directory cache.
Due to our current implementation, if you have a lot of includes, you
really should
Well, take an app that has 30 includes in a directory 5 levels deep.
Just the realpath() call is going to do 180 stats every time that script
is hit. Not sure how that wouldn't show up on the radar regardless of the
OS. You probably don't have anything that has 30 includes, but people out
What are the headers required out here to compile this code
successfully? Libs to link with?
There is a SAPI API call for that (in HEAD, but I intend to
merge it into the 4.3 branch).
SAPI_API int sapi_get_fd(int *fd TSRMLS_DC);
- Sascha
--
PHP Development Mailing List
On Wed, 15 Jan 2003, Vinod Panicker wrote:
Thanks for the quick reply...
But is there something that I can do right now that will allow this code
to work with php 4.2.3?
You could add the necessary code from here:
http://news.php.net/article.php?group=php.cvsarticle=16651
-
On Wed, 15 Jan 2003, Harald Radi wrote:
iirc the reason why i changed it to unsigned was that actually the zend engine
treated it as unsigned everywhere but in that particular struct. i also
remember that i discussed that with andi and that he agreed to change this in
the ze2 cvs module and
On Wed, 15 Jan 2003, Derick Rethans wrote:
On Wed, 15 Jan 2003, Christoph Grottolo wrote:
So why not release a bugfix 4.3.1 not because of a security hole but
just to complete the great work already done on PHP 4.3 - before
definitely jumping to PHP 5?
Who said that we're not going to
you're propably a bit too optimistic, i can hardly imagine that all existing
extensions all over the world compile out of the box against ZE2. i guess only
a handful do this.
Apparently, most of the extensions PHP ships with seem to
work out of the box. I'm under the impression that
On Mon, 13 Jan 2003, Derick Rethans wrote:
So, save versions are 1.28, 1.30 and 1.75 for now? Perhaps restrict
buildconf to check for this?
It's a configure/genfiles-time check as hashed out in an
older thread.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To
On Mon, 13 Jan 2003, Magnus Määttä wrote:
Hi!
I made these two patches so the buildconf script works on
Tru64.
You can simply add
MAKE=gmake
export MAKE
to your .profile (or how it's called on your system).
buildconf will then use GNU make. Although I do wonder why
I might be misunderstanding the problem and I didn't have time to read the
phrack article, but doesn't this mean that leaving it unsigned is better?
It wouldn't pass the length check and thus, memcpy() wouldn't convert a
negative number to something huge.
The problem is that every single
On Sat, 11 Jan 2003, Sebastian Bergmann wrote:
Sascha Schumann wrote:
You removed those files from the PHP 5 branch which you
claimed were supposed to be used in the PHP 5 branch.
ext/com/ are the old files, ext/rpc/com are the new files
Yeah, somehow my brain told me those strings
Greg, don't make that big fuss about it. I fixed the code 15 minutes
after bogusfying your report, so it throws an error, if the input is
bad.
Maybe setting it to bogus was a little bit too unfair, but my
additional comments should have clarified it...
Looks to me like it should have
On Sat, 11 Jan 2003, Ilia A. wrote:
On January 11, 2003 06:03 pm, Moriyoshi Koizumi wrote:
On Sat, Jan 11, 2003 at 11:38:20PM +0100, [EMAIL PROTECTED] wrote:
Sorry but just a thought, in that line:
if (argc 1 (int)Z_STRLEN_P(return_value) len / 2) {
Does this mean we now always
The cause for this is that phanto changed the type of the
string length from a signed type to zend_uint without
providing any kind of justification (zvalue_value).
As many past security advisories have shown, signedness
issues are the frequent cause for severe vulnerabilities
On Sun, 12 Jan 2003, Moriyoshi Koizumi wrote:
On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote:
As many past security advisories have shown, signedness
issues are the frequent cause for severe vulnerabilities in
software (recent examples include MySQL, OpenBSD
On Sun, 5 Jan 2003, Ilia A. wrote:
While converting the functions inside string.c to the new parameter parsing
API and doing some general cleanup, I've come across an interesting
'feature'.
Ilia, there is a consensus that the new (slower) parameter
parsing is only supposed to be used
On Fri, 3 Jan 2003, Anantha Kesari H Y wrote:
hyanantha Fri Jan 3 10:59:02 2003 EDT
Modified files:
/php4/sapi/apache2filter php_apache.h sapi_apache2.c
Log:
Modifications for NetWare.
I need to say it again.
These modifications are *extremely* ugly.
Zeev, you start to bore me. If you didn't notice it yet,
yesterday's email already constituted my EOT contribution.
So, now, explicitly for you, EOT.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, 29 Dec 2002, Zeev Suraski wrote:
At 11:46 29/12/2002, Sebastian Bergmann wrote:
Rasmus Lerdorf wrote:
Sascha, we need to give you something constructive to work on...
-Rasmus (top-posted with lots of quoted text just for you)
If it brings Bad E-Mail Practices to the
As much as it is amusing, tihiye besheket vetafsik lehishtamesh beLatinit.
If that language had interested me, I would have made my
Hebraicum in addition to the Latinum.
[snip off-topic]
If it has not been clear to you or anyone else -- this has
all been about drawing attention
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
Install m4 1.4 rather than 1.4o.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
I've noticed a trend to extreme over-quoting on the php
developer mailing lists. (Not to mention top-posting, but
that's another topic.)
In the latest example, Derick' email could have been 88%
shorter, if he had just cut down the contents to the
essential pieces. While
So, I had a look at whether pure numbers would support the
suggestion that quoting behaviour was not up to speed on this
list.
Considering the last 888 emails to php-dev, the script found
the following quoted/original ratio:
1%: = 17.25
5%: = 6.25
10%: = 3.50
After looking at a few messages again, I noticed that my
script also considered signatures (personal and the mailing
list's) as original lines.
Once these are kicked out, we see a far worse picture (the
ratios almost double):
1%: = 34.60
5%: = 12.50
10%: = 6.75
15%: = 4.50
Only a fool would decry the importance of effective
communication.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
p15104972:/usr/src/packages/SPECS # rpm -qi m4
Try m4 --version. The package version is likely to be
wrong.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
Ah, sorry, I did not really look at the output.
The undefined macros should not be referenced by any of PHP's
config.m4 scripts anymore. If you e.g. copied an old
On Sun, 29 Dec 2002, Zeev Suraski wrote:
Give us a break. And spare me an intelligent explanation about why we're
fools and you roolz, and why we don't deserve a break.
Only a fool would blow such an idiotic thing out of proportion.
I ran a script and posted the results -- why is that
Read back your (as usual) condescending remarks, and the entire
thread. You're a smart guy, figure it out!
Well, I would appreciate an answer on why this thing is
'idiotic' and 'out of proportion'. Please enlighten my poor
soul, dear Zeev!
- Sascha
--
PHP Development
I did my best to enlighten your poor soul in the past, numerous times, but
I at some point I realized it's beyond my reach. Knowing one's limits is a
virtue, and I know mine, so you're on your own!
As enjoyable as always,
- Sascha
--
PHP Development Mailing List http://www.php.net/
On Sat, 28 Dec 2002, George Schlossnagle wrote:
Wow... top 10. And to think my guidance counselor said I would never
amount to anything
And if it has not been obvious, the top 10 should be taken
with a grain of salt.
- Sascha
--
PHP Development Mailing List http://www.php.net/
On Sat, 28 Dec 2002, George Schlossnagle wrote:
Guess I should add visible sarcasm/sarcasm tokens in the future, eh?
Not really, I just wanted to point that out explicitly for
the benefit of the rest.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe,
On Thu, 19 Dec 2002, Zeev Suraski wrote:
Just to somewhat limit my agreement with that statement, I'd rephrase it so
that it's clear that people's opinion does matter. Something along the
lines of 'Too many people think that they're in a position to decide about
PHP'.
There is nothing
I disagree. For instance, if I helped writing the combined module, and
someone separated it without thoroughly making sure that everyone is ok
with this separation, I believe it's upto him to be responsible to merge it
back in.
That surely happens in 0.01% of the cases. My example
1 - 100 of 474 matches
Mail list logo
