[PHP-DEV] Re: Sybase Stored Procedures

2001-10-02 Thread Daniel Andersson

we are using sybase stored procedures with no problems what so ever.

just basic procedures but can't see any problem with advanced sp's.

/ d

Thomas Janke [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 hello,

 I would like to use sybase stored procedures and need to know, in what
 way they are supportet in PHP. In the manual, one can read that stored
 procedures are not yet fully supported. Does anybody have any newer
 information on what Sybase features can be used with PHP4?

 Thank you very much for your help.

 Yours
 Thomas



-- 
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]




Re: [PHP-DEV] Possibility of moving bugs to another list?

2001-10-02 Thread Daniel Andersson

sounds logical, BUT what about making one or two people maintainers/owners
of every topic, so that a bug is reported to php-bugs or something like that
_AND_ sent off to this/these person/people?

i joined this group to read about php-development, not about bugs.

yeah, i could do filters, but.. i'm lazy ;o)

/ d


Andi Gutmans [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 I think that being part of the developer forum means bearing the burden of
 receiving the bug emails.
 We've discussed this many times in the past and we always came to the same
 conclusion. We need developers to look at the bug reports and there's more
 chance if they get sent to the developers list (I know they can always be
 filtered out and ignored but I still think it's better).

 Andi

 At 09:57 AM 10/2/2001 -0500, Jason Greene wrote:
 I am sure I am probably rehashing an old issue that I wasn't around for,
 but I have noticed that it has been incredibly hard to follow php-dev
 (especially
 lately since I haven't had as much free time as I normally do). When of
 the things I noticed is that I commonly miss a php-dev post because of
 all the bug mailings. I did set up a filter in my mail client; however,
 IMO , if
 everyone is having to use a mail filter, wouldn't it be more logical to
 create a php-bugs list?
 
 What do you guys think?
 
 -Jason




-- 
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]




Re: [PHP-DEV] Possibility of moving bugs to another list?

2001-10-02 Thread Daniel Andersson

true, but then create a new group called something like php-future where i
can read about stuff that might happen and stuff you want to add and
feature-requests etc.. ?

/ d


Rasmus Lerdorf [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
  i joined this group to read about php-development, not about bugs.

 The two are joined at the hip.

 -Rasmus




-- 
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]




[PHP-DEV] Re: Bug #13424: imagecreatetruecolor() or imagecopyresampled()

2001-09-25 Thread Daniel Andersson

you forgot to compile --with-gd ?

/ d

[EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 From: [EMAIL PROTECTED]
 Operating system: mandrake 8
 PHP version:  4.0.6
 PHP Bug Type: PHP options/info functions
 Bug description:  imagecreatetruecolor()  or imagecopyresampled()

 i use imagecreatetruecolor()  or imagecopyresampled() and i have an fatal
 error caused by undefined function but i use verison 2.0.1 of GD.. on my
 windows box this work well but in linux the same code don't work

 answer quick.. thats urgent

 thanks
 --
 Edit bug report at: http://bugs.php.net/?id=13424edit=1




-- 
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]




[PHP-DEV] Re: Bug #13400: ftp functions are sometimes REALLY slow

2001-09-22 Thread Daniel Andersson

could it be that once in a while proftpd tries to resolve the ip of the
connecting machine?

and if it fails, it keeps this fail in a cache, for a while.. until it wants
to try again?


when my ftp'ing has been slow it's been because of resolving..

/ d

[EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 From: [EMAIL PROTECTED]
 Operating system: Red Hat Linux 7.1
 PHP version:  4.0.6
 PHP Bug Type: Performance problem
 Bug description:  ftp functions are sometimes REALLY slow

 I lately installed ProFTPD. This is on of the fastest FTP daemons I know.
 I've made a site which heavily uses FTP connections to a computer in the
 same subnet (100Mbit connection between the two). It's really strange.
 Sometimes the ftp functions (especially ftp_nlist and ftp_rawlist) work
 fine, sometimes it takes like 5 minutes before the call to the function
 ends with an empty array as a result... this is really annoying. I've
 searched user submitted notes about this problem, but couldn't find
 anything. I don't know if this is a known issue, or maybe it's just a
 configuration problem on one of the two involved Linux PC's. What I do
know
 is when I restart httpd, the slowdown is always over immediately. I DO
 close every ftp connection I make!


 Please help...
 --
 Edit bug report at: http://bugs.php.net/?id=13400edit=1




-- 
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]




[PHP-DEV] Re: Rand

2001-09-03 Thread Daniel Andersson

i'm not even close to being a phpdeveloper, so i should really shut up.

but i won't.

i read the interesting stuff on php-dev (!bugs that is) and i find this
rand-story quite childish.


jeroen, you've done everything one would expect someone committing something
new/changing to do.

the rest of you, STOP MOANING.
either moan _BEFORE_ the commit OR give him CONSTRUCTIVE feedback OR shut
up.


i thought the whole php-dev-group was mature.
guess i was wrong.

/ d


[EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 I am really furious now, and this is why:

 * People here seem to read things here VERY selectively. On August 4th I
 submitted a first proposal, and Rasmus (and ONLY Rasmus) had some problems
 with it, being that this would break BC if ppl rely on the reproducibilty
of
 rand() sequences. THAT WAS THE ONLY COMMENT I GOT.

 * On August 16th, I submitted a second proposal, which *IMHO* adressed
this
 issue. It went a bit more complex of course, but I was hoping to get that
 out of the code ASAP, i.e. with the next compatibility breaking PHP.
 The code also IMPROVED because there was now, unlike the first proposal, a
 PORTABLE and CLEAR and EXPLICIT way of getting a reproducable sequence of
 'random' numbers.
 Noone commented, even after multiple reminders. By means of (sometimes
 personal) mails with some phpdev, I got the idea that those ppl agreed
with
 me.

 * On August 22th, I announced to branch ext/standard to start implementing
 the changes. IF SOMEONE HAD PROBLEMS WITH THE CHANGES AN-SICH, HE SHOULD
 HAVE SAID IT AT THAT MOMENT. You couldn't have missed the announcment,
since
 there was a small discussion with Zeev about the branching.

 * On August 26th, (subject rand() redesign - please read) I announced
that
 the code was alread looking like something, i.e. the general idea was
 already clear. I also referred AGAIN to my second proposal.
 Again, nobody had problems with it.

 * On September 3rd, I merged it into MAIN. And now, suddenly everybody has
 problems with both semantics and implementation. I'm stunned. And angry.

 All the time from August 22th until September 3rd, you also could have
seen
 CVS-commit messages on PHP-CVS.



 If people are TOO LAZY to read ANY of these mails, they LOOSE IMO the
right
 to comment to the code as it is today on a way that is done now. I have NO
 PROBLEM at all when ppl say something like On line 123 of rand.c, you do
 something like this-and-this, wouldn't that-and-that be more
 efficient/better/elegant/whatever. But I DO HAVE PROBLEMS with the
reaction
 I got so far.


 So. I suggest people go read and read again the things I referred to above
 when they want to have something to say about the changes. And only then
 submit your comments to php-dev. The next few days I won't be able to read
 mail a lot, so please don't be inpatient - there's a life outside PHP (at
 least for me).

 I also suggest we act like there were no mails sent after the merge.

 Jeroen
 (and I *definitely* also need some positive reactions otherwise you
probably
 won't see any more patches from me (some people won't care maybe, but
that's
 their problem))

 PS: Egon, go read my reply when you asked that the first time. Wasn't I
 clear? It was in plain English though...




-- 
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]




[PHP-DEV] Re: Bug #12914: SMP compile failure

2001-08-23 Thread Daniel Andersson

make -j

works fine here
(not specifying the maximum number of jobs)

/ d

[EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 From: [EMAIL PROTECTED]
 Operating system: Linux/Slackware 8
 PHP version:  4.0.6
 PHP Bug Type: *Compile Issues
 Bug description:  SMP compile failure

 Whenever compiling PHP using make -j 2 causes errors (makefile not
properly
 ordered?).  Using make regularly works just fine.
 --
 Edit bug report at: http://bugs.php.net/?id=12914edit=1




-- 
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]




Re: [PHP-DEV] Re: rand_str

2001-08-05 Thread Daniel Andersson

i would say so, yes.

and if you do md5(microtime()) you have to do a substr() on the result to
get the desired length.

easy done, yes. but still..

maybe something for PEAR instead of the core?

/ d


- Original Message -
From: Cynic [EMAIL PROTECTED]
To: Daniel Andersson [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, August 05, 2001 3:41
Subject: Re: [PHP-DEV] Re: rand_str


 is it that much more useful than md5(microtime()) ?
 ah-oh, you want to be able to specify the set of characters...

 At 04:28 8/5/2001, Daniel Andersson wrote the following:
 --
 sounds useful and cool, me thinks :o)
 
 / d
 
 [EMAIL PROTECTED] wrote in message
 [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
  Hi,
 
  I'm thinking about a new function: [mt_]rand_str
 
  Syntax:
  string [mt_]rand_str(minlen,maxlen[,charlist]);
 
  where charlist is in addcslashes (and now also [l|r]trim) syntax.
  Charlist defaults to 0..9a..zA..Z
 
 
  IMHO, this would be a very useful function.
 
  Any comments? Maybe not minmaxlen, but simply a fixed len? (since
  randomness on the length is ambigious to implement, there are less
  possibilities with shorter strings, which raises some issues).
 
  As an extension, the function could also accept an array as charlist,
  containing small strings, to produce pronouncable strings.
 
  Jeroen
 
 
 
 
 
 
 
 --
 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]
 --end of quote--


 [EMAIL PROTECTED]
 -
 And the eyes of them both were opened and they saw that their files
 were world readable and writable, so they chmoded 600 their files.
 - Book of Installation chapt 3 sec 7



-- 
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]




Re: [PHP-DEV] Re: rand_str

2001-08-05 Thread Daniel Andersson

yes, totally agree.

but why not put it into PEAR?

/ d

- Original Message -
From: Cynic [EMAIL PROTECTED]
To: Daniel Andersson [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, August 05, 2001 13:52
Subject: Re: [PHP-DEV] Re: rand_str


 I think that new functions should be added on basis of
 usefulness, not the coolness factor. IMNSHO this function
 isn't very useful, and it is extremely easy to implement in
 userland:

 function str_rand()
 {
 $len = func_num_args() ? func_get_arg(0) : 32 ;
 return substr(md5(microtime()),0,$len);
 }

 At 13:57 8/5/2001, Daniel Andersson wrote the following:
 --
 i would say so, yes.
 
 and if you do md5(microtime()) you have to do a substr() on the result to
 get the desired length.
 
 easy done, yes. but still..
 
 maybe something for PEAR instead of the core?
 
 / d
 
 
 - Original Message -
 From: Cynic [EMAIL PROTECTED]
 To: Daniel Andersson [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Sunday, August 05, 2001 3:41
 Subject: Re: [PHP-DEV] Re: rand_str
 
 
  is it that much more useful than md5(microtime()) ?
  ah-oh, you want to be able to specify the set of characters...
 
  At 04:28 8/5/2001, Daniel Andersson wrote the following:
  --
  sounds useful and cool, me thinks :o)
  
  / d
  
  [EMAIL PROTECTED] wrote in message
  [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
   Hi,
  
   I'm thinking about a new function: [mt_]rand_str
  
   Syntax:
   string [mt_]rand_str(minlen,maxlen[,charlist]);
  
   where charlist is in addcslashes (and now also [l|r]trim) syntax.
   Charlist defaults to 0..9a..zA..Z
  
  
   IMHO, this would be a very useful function.
  
   Any comments? Maybe not minmaxlen, but simply a fixed len? (since
   randomness on the length is ambigious to implement, there are less
   possibilities with shorter strings, which raises some issues).
  
   As an extension, the function could also accept an array as
charlist,
   containing small strings, to produce pronouncable strings.
  
   Jeroen
  
  
  
  
  
  
  
  --
  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]
  --end of quote--
 
 
  [EMAIL PROTECTED]
  -
  And the eyes of them both were opened and they saw that their files
  were world readable and writable, so they chmoded 600 their files.
  - Book of Installation chapt 3 sec 7
 
 
 
 --
 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]
 --end of quote--


 [EMAIL PROTECTED]
 -
 And the eyes of them both were opened and they saw that their files
 were world readable and writable, so they chmoded 600 their files.
 - Book of Installation chapt 3 sec 7



-- 
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]




Re: [PHP-DEV] Re: rand_str

2001-08-05 Thread Daniel Andersson

heh.. possibly. ;)

forwarded.

/ d

- Original Message -
From: Cynic [EMAIL PROTECTED]
To: Daniel Andersson [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, August 05, 2001 15:59
Subject: Re: [PHP-DEV] Re: rand_str


 I'm not against putting it into pear. ask the pear guys
 what they think... but there's no Strings class AFAIK, and
 I think they'll hesitate to create a top-level class for just
 one function. :)

 At 16:47 8/5/2001, Daniel Andersson wrote the following:
 --
 yes, totally agree.
 
 but why not put it into PEAR?
 
 / d
 
 - Original Message -
 From: Cynic [EMAIL PROTECTED]
 To: Daniel Andersson [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Sunday, August 05, 2001 13:52
 Subject: Re: [PHP-DEV] Re: rand_str
 
 
  I think that new functions should be added on basis of
  usefulness, not the coolness factor. IMNSHO this function
  isn't very useful, and it is extremely easy to implement in
  userland:
 
  function str_rand()
  {
  $len = func_num_args() ? func_get_arg(0) : 32 ;
  return substr(md5(microtime()),0,$len);
  }
 
  At 13:57 8/5/2001, Daniel Andersson wrote the following:
  --
  i would say so, yes.
  
  and if you do md5(microtime()) you have to do a substr() on the result
to
  get the desired length.
  
  easy done, yes. but still..
  
  maybe something for PEAR instead of the core?
  
  / d
  
  
  - Original Message -
  From: Cynic [EMAIL PROTECTED]
  To: Daniel Andersson [EMAIL PROTECTED];
[EMAIL PROTECTED]
  Sent: Sunday, August 05, 2001 3:41
  Subject: Re: [PHP-DEV] Re: rand_str
  
  
   is it that much more useful than md5(microtime()) ?
   ah-oh, you want to be able to specify the set of characters...
  
   At 04:28 8/5/2001, Daniel Andersson wrote the following:
   --
   sounds useful and cool, me thinks :o)
   
   / d
   
   [EMAIL PROTECTED] wrote in message
   [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Hi,
   
I'm thinking about a new function: [mt_]rand_str
   
Syntax:
string [mt_]rand_str(minlen,maxlen[,charlist]);
   
where charlist is in addcslashes (and now also [l|r]trim) syntax.
Charlist defaults to 0..9a..zA..Z
   
   
IMHO, this would be a very useful function.
   
Any comments? Maybe not minmaxlen, but simply a fixed len?
(since
randomness on the length is ambigious to implement, there are
less
possibilities with shorter strings, which raises some issues).
   
As an extension, the function could also accept an array as
 charlist,
containing small strings, to produce pronouncable strings.
   
Jeroen



-- 
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]




[PHP-DEV] Re: rand_str

2001-08-04 Thread Daniel Andersson

sounds useful and cool, me thinks :o)

/ d

[EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 Hi,

 I'm thinking about a new function: [mt_]rand_str

 Syntax:
 string [mt_]rand_str(minlen,maxlen[,charlist]);

 where charlist is in addcslashes (and now also [l|r]trim) syntax.
 Charlist defaults to 0..9a..zA..Z


 IMHO, this would be a very useful function.

 Any comments? Maybe not minmaxlen, but simply a fixed len? (since
 randomness on the length is ambigious to implement, there are less
 possibilities with shorter strings, which raises some issues).

 As an extension, the function could also accept an array as charlist,
 containing small strings, to produce pronouncable strings.

 Jeroen







-- 
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]




Re: [PHP-DEV] Bug #12464: IIS5.0 header problems

2001-07-30 Thread Daniel Andersson

hiyya people

[EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 Hi j.gray!
 On Mon, 30 Jul 2001, [EMAIL PROTECTED] wrote:

  From: [EMAIL PROTECTED]
  Operating system: win 2k
  PHP version:  4.0.6
  PHP Bug Type: Session related
  Bug description:  IIS5.0 header problems
 
  The below message is getting spewed from an IIS5.0 win2k PHP 4.06 MySQL
  3.23.39a App. when it shouldn't
 
 
  HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Mon, 30 Jul 2001
10:24:55
  GMT Content-type: text/html X-Powered-By: PHP/4.0.6 Expires: Thu, 19 Nov
  1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate,
  post-check=0, pre-check=0 Pragma: no-cache

Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0 Pragma: no-cache

to me this looks like you have activated something like anticaching or
nocache in IIE.
(and that's why it's sending out an expire date with a date dating back some
years)

but it's just a guess.

/ d

 
  See the line
  PHP/4.0.6 Expires: Thu, 19 Nov 1981
  what is with that. To me it looks like it is sending expired headings
 
  If I turn off keep alives all is well. This isn't caused by proxies or
  firewalls.
 
 I can confirmed it happened to me several times:
 Linux/Apache 1.3.17/PHP4.0.6 (using output buffering)/Netscape4.7

 namely, some headers of the response appeared on the page in NS.

 -- teodor



-- 
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]