On Sat, 19 May 2001, Hartmut Holzgraefe wrote:
Jani Taskinen wrote:
Do not close any bug reports before the possible bug is REALLY
fixed.
so you claim it has *not* been fixed by the latest updates that kk
made to phpdoc/en/language/oop.xml ??? ;)
I'd almost say: RTFM :-D
Jeroen van
The patch is attached, for line-breaking reasons.
I also noted a probably-wrong if-statement, added a comment about that,
but didn't fix it. Would someone have a look at it.
IMPORTANT: did *not* test the patch, as I doen't have the equip here to
compile.
Greetz,
Jeroen
Jeroen van Wolffelaar
Hi,
I've rewritten the pow(base,exp) function. It is attached.
In stead of a mere call to the c-lib function pow, this one actually does
something more smart. This is to protect those people not knowing that there
is huge difference between raising to an integer power and raising to a
IMPORTANT: I didn't test it yet, I'm not even sure there are no compile
errors.
(My linux machine doesn't have libtool 1.4 :-(( )
Hey, I can now compile :)
And there is an error, so ignore this for now :(
Please use proper Z_* macros, that is Z_LVAL_PP(exp) instead of
Z_LVAL(*exp).
You use *_PP variants for ** pointers, and _P for * pointers.
k.
I've now fixed the compile problems, it will compile now.
Even better: it works :-)
See attachment.
Greetz,
Jeroen
new_pow_func.c
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
And try to use ZEND_NUM_ARGS() wherever possible. Like here:
zend_get_parameters_ex(ZEND_NUM_ARGS(),zbase,zexp);
I'm fairly new to C, and surely new to the php-implementation, so I took
this from many, many other functions, where it was done that way... I
haven't noticed any function
Hi,
I've fixed some bugs in the function, and believe it is now correct. It's
best to come up with a whole bunch of tests, since there are 25 conditional
expressions in it, for 25 different cases... This is due to the nature of
pow(), and the fact it is now overloaded. pow(0,0) is now fixed to
Has anyone idea's for a good syntax?
I think there are enough classes for mime-mail handling, maybe someone
could get one into PEAR...
Hm, so you don't think it'd be a good think to get in PHP itself? There are
numerous functions that are less common-used, and can be
written very well in
, please drop me a line (and of course also
when they don't)
Greetz,
Jeroen
Jeroen van Wolffelaar [EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
Index: math.c
===
RCS file: /repository/php4/ext/standard/math.c,v
retrieving
!
To reply, use the web interface found at
http://bugs.php.net/?id=11962edit=1
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Hi,
I've made a patch for 10721, based on justin's, and it now works
correctly.
Andi/Zeev, would you please commit this?
Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
Index: zend_builtin_functions.c
How about having some 'reject' button/link on the bug pages? Just like with
the notes: The sender gets a default mail with: read bugs do and don't,
include sample, ask php-general first, etc. And the bug gets bogusfied
automatically with a default comment if none is supplied.
I think it'd be
I've said it before, but I *really* am convinced now, that we should:
- At least allow $str{index} (while _deprecating_ the array $str[ ] indices)
- _possibly_ also allowing $str{start..end}
- and if the above is allowed, then I think you should also allow
$str{..end} and $str{start..}
But
- Right now this also effects things like opening php.ini. It'll now
always
check in the current working directory for php.ini. I think this
doesn't
screw up todays behavior.
Isn't this a huge security risk? When there is something wrong so that
php.ini can't get read where it
I don't have access to the PHP CVS at the moment (note to self: get a C
compiler)... but I wanted to ask how this will affect (or will it?) HTML
generated from within included PHP files. Eg. A is at web root and
includes
B in a subdirectory X. B generates HTML that calls for image C.gif in
The mail() function can be used to send email with attachments
and special types of content. This is accomplished via MIME-encoding
- for more information, see
http://www.zend.com/zend/spotlight/sendmimeemailpart1.php;
Just a wild idea, but maybe we should add a real
I am sending this patch to the php-dev list for your
consideration. Attached are the listing produced with
cvs diff -u, and listed below is a test file to
check the changes.
Basically I just added some more math funcs from the C
library (hyperbolics and exponentials).
Hyporbolic
It might be that. Just implemented the functions
taking advantage of their presence in the standard set
of math functions of the C library, so the C people
might be more familiar that the rest I guess.
Agreed, but I'm not certain this is worth the extra
bloath of relatively unneeded
log(a) / log(n) is not that much harder, and its the right way, imho.
Yes, you're right that it is the right way. But for example,
for tan(x), the right way is sin(x)/cos(x).
(Not such a good example, but anyway)
log($bla,2) is cleaner, IMO, than log($bla)/log(2), not mentioning the
possible
There is a possibility that GSL will be implemented in PHP, but that's in
GSL: GNU Scientific Library, http://sources.redhat.com/gsl/
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To
At 01:53 AM 8/4/2001 +0200, Jeroen van Wolffelaar wrote:
log(a) / log(n) is not that much harder, and its the right way, imho.
Yes, you're right that it is the right way. But for example,
for tan(x), the right way is sin(x)/cos(x).
(Not such a good example, but anyway)
As you said
See some messages I had on php-dev back around the first week of January,
2001 on this topic. FWIW, I would like to change it.
On http://marc.theaimsgroup.com/?w=4r=1s=trachtenbergq=a ,
I could only find messages about break/continue in switch statements...
Am I overlooking something? Of did
Please don't. Ini settings that change semantics are a bother, and
people should be able to choose their random function.
Both function families are the same in syntax returning, only the
algorithm is different. I.e.: the semantics is the same. The algorithm - if
correct - shouldn't bother,
but why not put it into PEAR?
PEAR can be useful, but the power of PHP is, that is has so many helpful
build-in functions. And with pear, it will always be longer.
I think that new functions should be added on basis of
usefulness, not the coolness factor. IMNSHO this function
isn't very
Both function families are the same in syntax returning, only the
algorithm is different. I.e.: the semantics is the same. The algorithm -
if
correct - shouldn't bother, and shouldn't be the concern of the
programmer,
but rather the system maintainer (specific cases excluded, but than
and it is extremely easy to implement in
userland:
That is not true,
So how about this?
function str_rand($len=8)
{
$retval = strtr(md5(microtime()), chr(0x30), chr(0x4F));
return substr($retval,0,$len);
}
for($i=0; $i10; $i++){
echo str_rand(), \n;
}
I find
Hi Jeroen,
I think we're not on the same page. :) I consider both versions
of str_rand() I posted trivial...
Agree. But they are not what rand_str could do. The result has
16 different chars, just because md5 happens to have that much.
Implementing something that has NOT that limitation, is
- Original Message -
From: Andy [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, August 05, 2001 9:47 PM
Subject: Re: PHP Notes
confirmation would be even worse, then I'd (we'd)
STILL have to go through all of the notes
(and this time
Can't post to php-cvs :-(
jeroen Sun Aug 5 16:27:04 2001 EDT
Modified files:
/php4/ext/standard math.c
Log:
Bugfix in abs(), abs(LONG_MIN) was bogus
---AND---
- Replaced the pow(LONG_MIN,1) fix for a better one
- Removed bogus left-over comment in pow()
--
Implementing something that has NOT that limitation, is far less trivial.
function str_rand($len = 8, $class = 'a-zA-Z1-9')
{
static $init = 1;
if(1 == $init){
mt_srand((double) microtime() * 100);
$init = 0;
}
$chars = array();
for($i = 0; $i
Patch attached
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Thursday, August 09, 2001 1:12 AM
Subject: Bug #12245 Updated: gettype(true true) returns integer!
ID: 12245
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status:
What about $_TAINTED ?
for non-english ppl REQUEST is a more familiar word that TAINTED. I only
encountered it when studying JS security.
+1, tainted? I needed a dictionary for that...
-- teodor
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
Now you assume that you need to pass arguments to these functions.
Which is not the case. Here's the proto:
/* {{{ proto int rand([int min, int max])
Returns a random number */
So revert that patch. mt_rand() / rand() accecpt either 2 parameters or
none at all. It was at least LESS
Hi,
About a month ago there was a discussion on the Engine 2 mailing list, about
a possible RFC-proces for the more imporant PHP-issues. In the end, there
was some consensus that it would be good if such a system exists.
I'm simply writing to get some comments, to hear what the general opinion
Just poit them to php-dev and keep bringing it up until there is some
decent
comment on it, at the moment there is no democratic process in PHP, people
just do what they want and someone normally knows some part of PHP better
than anyother, IE if you have a sessions thing speak to sascha (via
On the other hand, the latter one could be named 'RFC process', since it
hasn't yet been defined what the heck it is precisely...
RFC.. Request For Comments, its as simple as that someone posts a document
outlining what they want changed/want to do, calls it an RFC and is
litterally
The work on Zend Engine 2 has now started, _without_ a proper definition
of
it. IMHO, that's not the ideal situation, since this could lead to
strange
inconsequences, because the precise behaviour is decided during
implementation.
Umm what about the white paper that was prepaired
With what end in mind is an RFC to be created for? In the IETF, RFC's are
typically long, complex, and authoritative. They are often referenced for
years
after their inception.
Do you honestly think we could (or want to) achieve this
with PHP feature RFC's? Or will they be used only before
Hi,
[Impact and relevance: all functions that use randomness (including
array_shuffleco)]
After the previous discussion, I've been thinking, and I think I've got a
way which has only a neglectible BC problem (unlike my first proposal),
while still keeping the following in mind:
Probably 99% or
As I read it in CVS, chroot() will work even in safe-mode. Isn't this a
bad
idea(tm), or am I wrong?
If users can chroot in safe-mode, Apache won't serve any more pages
after
all children have been chrooted to an empty dir?
uhm, where have you read that? [ curious ]
I just reasoned
Zeev Suraski [EMAIL PROTECTED] wrote in message
5.1.0.14.2.20010822013439.02e0c498@localhost">news:5.1.0.14.2.20010822013439.02e0c498@localhost...
At 23:14 21-08-01, [EMAIL PROTECTED] wrote:
What about using the pif_ prefix for php's internal functions,
analogously
to zif? This makes them more
What's wrong with php_ prefix?
Nothing. It is just the same prefix as for PHPAPI functions, and the purpose
was to diffentiate in the name between helper functions and API-functions.
But starting it with an underscore is also a good way of achieving that, on
second thought.
-Andrei
Jeroen
I'm against that. Usually underscore-prefixed symbols are used by system
libraries and OS and we don't need to go in that direction. I'm also
against using pif_, because it's not an internal function that you are
naming, but rather, a helper one.
I don't really have an opinion on this
At 23:09 22-08-01, Andrei Zmievski wrote:
On Wed, 22 Aug 2001, Zeev Suraski wrote:
How about phf_, for PHP Helper Function?
I see a point in differentiating language level API functions (e.g.
like
output buffering) and module-specific helper functions (e.g., like
At 23:37 22-08-01, [EMAIL PROTECTED] wrote:
Hi,
I've got an experimental beginning of the new rand functions ready. I
think
it's good if others can comment on it before it is finished, because the
course can be changed now quite easily, but when it's all done, I don't
feel
much about
If it's such a far reaching change, I suggest you simply send the diff the
php-dev. It should be enough to be a basis for a discussion on the
proposed changes. If we decide to go through with it, it should be
At this time, it's merely a big move-around with code, no single thing of
What I would do in your case is:
(a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or
whatever)
(b) Commit your move-around changes
(c) Commit the real changes (can be done immediately after (b), as long as
it's separate)
The real changes are not ready... and I didn't
(a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or
whatever)
(b) Commit your move-around changes
I really think a lot of people will set ext/standard to PRE_RAND_REDESIGN
then, because they want to work on other parts, and don't want a broken
build. That's the other
Execute - in ext/standard:
cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c
rand_mt.c crypt.c
And check it out... (I didn't branch whole ext/standard, so it's needed to
name the necessary files... sorry)
Jeroen
--
PHP Development Mailing List http://www.php.net/
To
Execute - in ext/standard:
cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c
rand_mt.c crypt.c
Update: changed my mind, and branched whole ext/standard. It seems that it
doesn't cause any overhead or whatever.
So
% cvs update -rRAND_REDESIGN ext/standard
will do.
Better question is, do we really want to do this?
This doesn't fix anything. It only breaks things.
Second, this will make writing portable scripts harder.
Yet another ini setting to be checked for..
No! PLEASE read my propasal, this is a WRONG assumption. Even better: IF wou
want a portable
+; Default random number generator. Specify here which random number
generator
+; you want to use for the PHP-rand() function. Usually MT (Mersenne
Twister,
+; see http://www.php.net/manual/en/function.mt-rand.php) is the best
choice.
+; It is thread-safe, fast, and, quite important, mod
[Changed subject, I missed this thread until now because of it...]
I assume this difference between 12 and 3 is _strictly_ performance, and
_nothing_ else?
And a note for others: You don't need TSRML* in every function, but you do
need it if you use:
- Global variables, like BG(...) co.
- Use
See attachment. I tested it, and I'm sure it works.
--jeroen
fix_for_12245.diff
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
I think the problem is the fact that we read all of the file into Memory
That seems like a bad idea to me... it doesn't get in PHP directly, only
after specific request. So you mean that PHP read's the whole file, than
writes it to /tmp (or c:\temp), and then clears the memory again?
If that's
Hi,
I'm sure there's some simple (stupid?) error, which an experienced
C-programmer can see immediately... But I don't.
You're missing a variable name (you only put a type), and the line is not
in the beginning of a code block (there's a statement before it).
php_randgen_entry is (supposed
Also, I ask again: Why didn't you just add new function random()
instead of changing all this and breaking BC.
I DID NOT BREAK BC.
Sorry, but this has been discussed dozens of times...
--jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
I was waiting for you to tell that now the branch works and I could
test it and say 'good, this works you can merge'. I'm sure everybody
else waited for same.
You do NOT need the implementation to know how it is going to be. I
explained that multiple times, and everybody (though silently)
(and *yes* I'm angry, and *yes* I'm talking to someone in particular).
And I'm now going to sleep before it gets worse.
Good night,
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To
PS: Egon, go read my reply when you asked that the first time.
Wasn't I
clear? It was in plain English though...
I have only asked you, why have you deleted the comments.
It was in my mail:
- I DID NOT REMOVE THEM
Ich habe den nicht weggeholt!!!
I just MOVED them. That was
description: ++, -- operators does not conert the type of variable.
The attached patch should cure it. jeroen, are you on it or should I
commit this patch?
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
--
PHP Development Mailing List http://www.php.net
I *NEVER* have anything to say until I have seen the code. Otherwise,
it's just a bunch of castles in the air.
Okay, that's a point. That is not the custom where I learnwork, actually,
there is a saying that design planning is 67% of the job, implementing
just 33%. That is if you want a good
:[EMAIL PROTECTED]...
On Wed, 05 Sep 2001, Jeroen van Wolffelaar wrote:
Just look at the algorithm and you'll see at once it is bogus. Only in
the
special case that one single key is requested it is correct.
Proving it's bogus is trivial, so I'll leave that as an exercise to
the
reader
Resent
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
Sent: Wednesday, September 05, 2001 11:21 PM
Subject: Re: The rand() can of worms
Bad points:
1) Leaks
2) Inconsistent style
3) Really bizzare macros, etc.
Let's put one thing straigt: I merged it
I'm very sorry for whatever I wrote yesterday, I happend to got a quite
drunk because of the closing of the introduction. I shouldn't have gone
online in that state. I now redraw whatever I said, because I'm afraid it
wasn't all that neat.
For today I'm not going to write anything either, since
Stig wrote:
Wow. :)
[[EMAIL PROTECTED]]
(...) I'll keep it short.
You were referring to this? Yes, I realized it after I sended it... I
(obviously) wrote that before I finished the mail...
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
At 01:24 09-09-01, Jeroen van Wolffelaar wrote:
Exactly the same goes for ?= unless you happen to stumble across the
one-line footnote on the php.net/echo page.
So that's a documentation bug. It clearly belongs in the
documentation
about PHP's various special tags, just next
sterling Wed Sep 5 16:52:45 2001 EDT
Modified files:
/php4/ext/standard rand.c
Log:
a bit of api cleanup... move range stuff into a macro (properly :)
Yeah yeah... I know by now...
+#define RAND_RANGE(__n, __min, __max) \
+ (__min) + (int)((double)(__max) - (__min) + 1.0) *
People interested in rand can still visit
http://www.A-Eskwadraat.nl/~jeroen/rand ,
but if you have something interesting to say you can of course also mail to
php-dev!
World Wide Web Cie [EMAIL PROTECTED] wrote:
Note added by jmoore:
My vote: ±1 :)
Suggestions/remarks:
I think that PHP
Note added by joey,
text:
My vote: +0
Suggestions/remarks:
I'll take the proposal one piece at a time:
Good idea :-)
float random() / int random(min, max):
If I understand correctly, the only way you'll know what kind of
return the user is expecting is by counting args. That means if
No number is truly random. That is the nature of computers. You
can only generate a sequence of numbers, based on a seed.
True (of course, I knew that already long ago...), but
1) You can obscure that by using time-varying seeds in order to get
seemingly random numbers
2) You can
Is there anyone out there who uses on negative numbers?
There is the discussion on the engine2 list about whether to
make an unsigned right shift, or to introduce a new operator
.
In my opinion, and should consider integers as a row of bits, thus do
not treat the msb differently... I
FWIW:
Signed shift seems to make little sense to me personally, since we are
just dealing with a row of bits, and if you really want to do a quick
multiplication/division, you might just as well use a * or / operator -
it is not going to hurt that much:).
I completely agree
*However*,
then why does this work in version 4.0.4 ?
It was an implementation side-effect. It was not intentionally.
The same issue as that, for example, you can specify a variable violating
the naming rules by using:
$GLOBALS[0a\n] = Some value;
because it would be bad for performance to check for
How can I add the function array_sum() to older php core installations?
Grep though the current source with 'array_sum', and add the three things
that come up to your 4.0.3-source: a proto in a .h-file, a PHP_FE entry, and
the PHP_FUNCTION itself.
It should work... but why not simply upgrade?
Hi all,
There has been a bit of discussion about rand(). I really appreciate that,
though I would have preferred if it was held BEFORE the changes I (tried to)
make.
Okay, back to business.
By special request, as short as possible:
(I assume you've read the latest proposal, if not, go to
On Tue, 18 Sep 2001, lo-tek @pb1.pair.com cshmoove wrote:
suppose i have a function which returns a pointer to a variable in
thread
local storage
foo_t *get_global_foo()
{
TSRMLS_FETCH();
return (foo_t *)BAR_G(foo);
}
void fubar()
{
foo_t *foo =
Jeroen,
then i have one more question. The real problem im trying to solve is
Would some one please answer this question, because this is getting
somewhere (mutexs) I don't know much of. And not much is nearly nothing
in this case ;-)
--Jeroen
--
PHP Development Mailing List
How can you determine it is bogus within 2 minutes, please provide your
rational.
(...)
This is probably not a bug ? Are you kidding me ? I hope you are not
closing any real nasty bugs because of this reasoning :)
From http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Give the
I posted a bug-update 5 minutes ago, and from the mail headers:
Date: 22 Sep 2001 10:34:57 -
It is now GMT/UTC 21 sep 2001 22:30 or something.
That means that bugs.php.net is off-time by 12 hours, which is very
annoying. (chronology of posts is completely wrong).
Can someone please fix
FYI,
I mailed the authors of that virus program, and they replied the following:
- Original Message -
From: H+BEDV Datentechnik GmbH [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Sent: Friday, September 21, 2001 11:42 AM
Subject: Re: False positive in PHP-distribution
Is it currently possible to undefine user functions or classes at
runtime? Although not a newbie ;) I'm unsure if its possible
right now.
No, you can't do that in PHP-userland (in the C code it can be done, see
implementation of create_function).
And IMHO that should remain so.
If not,
Hi,
For a scripting language, integers should IMHO be bounded by a number that
will reasonally not be bound by numbers that will be used in normal scripts.
That is currently not the case, 4 bytes are insufficient IMHO. Why not make
sure PHP uses 8 bytes at least? Or are there platforms not
Hi,
For a scripting language, integers should IMHO be bounded by a number that
will reasonally not be bound by numbers that will be used in normal
scripts.
That is currently not the case, 4 bytes are insufficient IMHO. Why not
make
sure PHP uses 8 bytes at least? Or are there platforms not
how much slower it is.
Anyway, it would be nice if someone with expericence with changing to 8
byte integers could share his experiences...
--Jeroen
Andi
At 09:13 PM 9/23/2001 +0200, Jeroen van Wolffelaar wrote:
Hi,
For a scripting language, integers should IMHO be bounded by a number
I would be very worried about making numbers 8 bytes by default, unless
the CPU supports them natively. There are a lot of consequenses involved
with something like that.
Assuming a 32 bit register system (x86) integers will no longer fit in
registers. This changes EVERYTHING, from passing
This subject is being crossposted to [EMAIL PROTECTED] and
[EMAIL PROTECTED]
This mail was only on engine2 (let's keep everyting at least on phpdev):
-- Forwarded message --
Date: Sun, 23 Sep 2001 22:41:45 +0200 (CEST)
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Stig
indeed. The question was
wether all compilers on 32bit platforms DO have long long support at
all, in other words: is it true that all compilers for which PHP needs
to compile have a C-type which is 64bit (native or not)?
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl
for the macro's... Unsubscribe from php-cvs while you still
can ;-)
(just kidding... I hope)
Jeroen
- Markus
On Mon, Sep 24, 2001 at 09:13:35AM +0200, Jeroen van Wolffelaar wrote :
On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote:
Hey, it's open source, go for it dude. Let us know.
:-)
I
that IF it is going to be implemented, it should be a compiler
option to choose what the type of integer needs to be: long, long long,
or something else... With proper use of macro's that would mean 1 single
#define.
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
--
PHP
./ltconfig: ./ltconfig: No such file or directory
configure: error: libtool configure failed
(indeed, 'ltconfig' doesn't exist)
Also note that I didn't ever succesfully build PHP directly from CVS - I
didn't have libtool 1.4 till yesterday
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A
- Original Message -
From: [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Cc: PHP Development List [EMAIL PROTECTED]
Sent: Tuesday, September 25, 2001 7:46 PM
Subject: Re: [PHP-DEV] Bug in autoconf report
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote:
[jeroen
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote:
snip
Note: after I solved that warning about automake libtool not being in
the same dir, the error remainded the same. (I copied the automake
executable to the same dir as the libtool executable)
Ok, but it's still a problem
Fixed
- Original Message -
From: Holger Schopohl [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Wednesday, September 26, 2001 10:51 AM
Subject: zip ext compile problem
Hi,
in the current cvs tree the zip extension
have problems to compile with zziplib 0.10.27
of my Autotools - will try again when that is done.
--zak
On September 25, 2001 11:53 am, Jeroen van Wolffelaar wrote:
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote:
snip
Note: after I solved that warning about automake libtool not
being in the same dir, the error remainded
Does anyone object to me modifying the anoncvs.php webpage to include
the following note? Does anyone have anything to add - Jeroen? :)
There's a typo in it, but that's not what you meant :-)
I wouldn't name that SuSE thing, it's way to specific for indicating that
something DOESN'T work. I'd
Resent. The discussion isn't closed yet, and this is important, since it
will be already in 4.1.0
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: PHP cvs [EMAIL PROTECTED]
Sent: Wednesday, October 10, 2001 8:46 PM
Subject
Resent due to lack of feedback.
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
Sent: Wednesday, October 10, 2001 5:28 PM
Subject: heredoc: change of behavoiur?
Currently, heredoc as a bit of strange behaviour in syntax of terminating
it.
I think it's a good idea to
Resent due to lack of feedback.
Objections against me changing it to the behaviour I described below?
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: PHP Developers Mailing List [EMAIL PROTECTED]
Sent: Monday, October 15, 2001 9:45 PM
Subject: Re: Bug
?
Additionally, a notice is a good idea here, just like what happens on
division by zero: the most natural result is returned, and a notice is
issued.
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 02, 2001 2:39 AM
Subject
1 - 100 of 116 matches
Mail list logo
