Re: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Alexander Wagner wrote: > You have a point here, but you're not necessarily right. > > Smarty templates are more complex than IT[X]/PHPlib-style templates, > but still easier than XSL, and not all designers are that dumb. > > I think IT[X]-style templates are more important

Re: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Björn Schotte wrote: > It should be self-evident that most things are "IMHO". > So I don't see the reason why you're trying to make a > problem out of that. One thing I try to avoid is making assumptions, because most of the world's problems come from that. -Andrei The main

Re: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Björn Schotte wrote: > * Andrei Zmievski wrote: > > I am sorry, but *that* is your opinion. > > Sebastian asked for my opinion. Where's the problem? It would have been nice to add "IMHO" at the end of your statement then. -Andrei The chur

Re: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Björn Schotte wrote: > Web designers and pixel movers are yet too dumb to > check how XSL(T) works. So they prefer template > solutions like PHPLIB/IT[X], as Smarty is only usable > for programmers (and as Kris said, a template engine > should not be a full fledged turing engi

Re: [PHP-DEV] Porter extension cleaned up

On Wed, 05 Dec 2001, J Smith wrote: > > After seeing my name in lights on the weekly PHP summary, I decided to go > back into that Porter extension I had wrote about earlier and clean things > up a bit. > > I stripped out all of the C++ stuff to make it a bit of an easier fit with > PHP's C

Re: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Kristian Köhntopp wrote: > Because that is the way PHP works. PHP is like the borg: If there is a > C call somewhere out there in the kernel or some obscure library, > somebody will wrap it in PHP and provide an interface to it. This > makes for an extremely rich, some would s

Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, James Moore wrote: > +1, the only exception I might make would be Smarty as it is well designed > and a lot of people use it but I dont think even smarty has a place in the > PHP Distribution. Perhaps in PEAR, but you are correct. -Andrei Complexity in the mind is not cause

Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, [EMAIL PROTECTED] wrote: > I agree with Andrei here. If an templating extension is bundled with PHP, > it becomes the 'defacto supported' template engine. In other words, we > will say that this is the best template engine, because it is bundled with > PHP. Yes, and it will h

Re: Re[5]: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Björn Schotte wrote: > * Andrei Zmievski wrote: > > on there. At the end we agreed that no default template solution would > > be bundled with PHP. > > In fact you did that with IT[X] in PEAR. :-) I have nothing to do with IT[X}. :) -Andrei The ma

Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Björn Schotte wrote: > * Andrei Zmievski wrote: > > > I suggest ext/template being extemely important. > > Sorry, but I am completely against it. > > Why? See my previous message. -Andrei "When I get a little money, I buy books; and if any i

Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Björn Schotte wrote: > I suggest ext/template being extemely important. Sorry, but I am completely against it. -Andrei For society, it's probably a good thing that engineers value function over appearance. For example, you wouldn't want engineers to build nuclear power pla

Re: Re[5]: [PHP-DEV] [NEW EXTENSTION]: templates

On Wed, 05 Dec 2001, Daniel Lorch wrote: > Hi, > > It's nice having an out-of-the-box solution - everything just works > fine, just load the module (i.e. uncomment # in php.ini). Nevertheless, > who actually decides how a module's interface is designed? I know, > there are some guidelines, but th

Re: [PHP-DEV] php-patches@lists.php.net?

On Tue, 04 Dec 2001, Thies C. Arntzen wrote: > i'm going to be on all lists anyhow;-) - so it doesn't make any > difference for me. personally i think it would make sense to > keep all CVS, bugdb and -dev talk on one single list. I must work more on my sarcasm. :) -Andrei What's har

Re: [PHP-DEV] php-patches@lists.php.net?

On Tue, 04 Dec 2001, Thies C. Arntzen wrote: > On Tue, Dec 04, 2001 at 09:04:29PM +0900, Yasuo Ohgaki wrote: > > How about to have *new* list for sending patch for PHP? > > PostgreSQL has list for that. It seems the list is working great > > for them. > > php-dev is perfect for sending patche

Re: [PHP-DEV] Array vs Hashes

On Mon, 03 Dec 2001, Daniel Lorch wrote: > Hi, > > I don't know whether this was already discussed before, but .. > > have you ever though about the fact that PHP is not very cleanly > designed when looking at Arrays and Hashes? How can I predict whether > a array/hash is sorted by it's INTEGER

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Constants

On Mon, 03 Dec 2001, Andi Gutmans wrote: > Because some of the keys are case-insensitive and some aren't. Case > insensitive hashes don't work if you want to mix the keys. > In any case, I think the solution above is a good one because there are > only 5 constants in the Zend Engine which are ca

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Constants

On Mon, 03 Dec 2001, Andi Gutmans wrote: > Personally I wouldn't write code which gives FOO_BAR and Foo_BAR two > different meanings but I think you are right that it'd be better and I have > an idea on how to do it which I'll lay out. > We are only talking about global constants defined with de

Re: [PHP-DEV] Constants

On Mon, 03 Dec 2001, Andi Gutmans wrote: > Hi, > > I'm trying to wrap up the class wide constants in ZE2. I implemented them > so that class wide constants are case-sensitive. I think in general, > although ZE1 allows you to define case-insensitive constants it's better > for performance and f

Re: [PHP-DEV] Class Struggle

On Tue, 27 Nov 2001, l0t3k wrote: > > im having a tough time getting PHP to execute a method of a function defined > in an extension. the extension compiles fine, shows up in phpinfo(), and > calling get_declared_classes() returns the class names as expected. > > in addition, calling get_class_m

Re: [PHP-DEV] Server-Wide Persistent objects in PHP?

On Mon, 26 Nov 2001, Andrei Zmievski wrote: > Yeah, it's already built and it's called Zend Encoder. Sorry, Zend Cache or Zend Accelerator, not sure what the current name is. -Andrei "Freedom comes when you learn to let go. Creation comes when y

Re: [PHP-DEV] Server-Wide Persistent objects in PHP?

Yeah, it's already built and it's called Zend Encoder. On Mon, 26 Nov 2001, Yermo M. Lamers wrote: > > Markus, > > Yea, that's the problem. In my application, just loading the class files > on each page adds quite a bit of overhead. (1000's of lines of code). > > I've taken a look through the

Re: [PHP-DEV] CVS Account Request: moh

On Sun, 25 Nov 2001, Egon Schmid wrote: > If you get an CVS account, please wait or ask Cornelia Boenigk > [EMAIL PROTECTED] first. There is a part already translated into > German in the book by Sterling and Andre[j]i. Andrei I´m very sorry, > that your first name was changed from Andrei to Andre

Re: [PHP-DEV] ext/imagick update (fwd)

On Wed, 21 Nov 2001, Sterling Hughes wrote: > > Well it's taken several years but finally you posted > > something I don't agree with. :) > > > Wow, several years, that almost seems too long :) Yes, didn't you still walk under the table when it all started? :) -Andrei "The most exciting p

Re: [PHP-DEV] strange crash

On Wed, 21 Nov 2001, Chris Newbill wrote: > Bingo! > > What is happening is I have PHP code that will eventually be pulled from > a database, and some of them need to import the global scope (although I > have changed this for security reasons). Only way to do this (easily) > when eval'ing code

Re: [PHP-DEV] ext/magick

On Mon, 19 Nov 2001, Christian Stocker wrote: > Hi > > I wrote in the last few days my first php-extension. It's an extension for > the ImageMagick library. It can't do much at the moment, more or less only > converting from one image-format to another (but since ImageMagick > supports a lot of t

Re: [PHP-DEV] Bug #14077 Updated: it is an easter egg in all PHP pages

On Fri, 16 Nov 2001, Hartmut Holzgraefe wrote: > Andrei Zmievski wrote: > > >This should go into FAQ. > > well, then it wouldn't be an easter egg anymore, would it? Yeah but answering "those are breadsticks actually" is getting old really fast. :) -Andrei

Re: [PHP-DEV] Bug #14077 Updated: it is an easter egg in all PHP pages

This should go into FAQ. On Fri, 16 Nov 2001, [EMAIL PROTECTED] wrote: > ID: 14077 > Updated by: sniper > Reported By: [EMAIL PROTECTED] > Old Status: Open > Status: Bogus > Bug Type: Unknown/Other Function > Operating System: win 98 > PHP Version: 4.0.6 > New Comment: > > They're bread sticks :

Re: [PHP-DEV] md5sum() patch

On Thu, 15 Nov 2001, Hartmut Holzgraefe wrote: > because i realy like function overloading ;) I need to use some holy water on you. -Andrei A room without books is like a body without a soul. -- Marcus Tullius Cicero (106-43 B.C.) -- PHP Development Mailing List

Re: [PHP-DEV] md5sum() patch

On Thu, 15 Nov 2001, [EMAIL PROTECTED] wrote: > That is a possibility, better then having a new function. Although it > makes it a bit obscure IMO. But I can live with it :) Why is it better than having a new function? What's wrong with having a new function? Name it md5_file() and it's pretty cl

[PHP-DEV] PHP Conference pics

Did anyone take pics at the conference in Frankfurt and if so, are they available online? -Andrei Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. -- PHP Development Mailing List To unsubscribe,

Re: [PHP-DEV] 4.1.0

On Mon, 12 Nov 2001, Zeev Suraski wrote: > The one symptom Rasmus pointed out (which was quite specific for > mbstring-xlation+zlib-compression) was MFH'd, so I think there are no big > showstoppers left. I'm ++1 for releasing current branch ASAP. -Andrei The main reason Santa is so jolly is

Re: [PHP-DEV] 4.1.0

On Mon, 12 Nov 2001, James Moore wrote: > Putting out a release we arnt happy with is worse than not putting a release > out at all. Just wondering what in the current branch people aren't happy with. -Andrei * http://www.zend.com/comm_person.php?id=24 * -- PHP Development Mailing List

Re: [PHP-DEV] PHP Module in source dist?

On Fri, 09 Nov 2001, James Moore wrote: > Its just a question of finding someone to commit the code for you or getting > a cvs account yourself after discussion on php-dev but remeber the libary > needs to be compatible with the PHP License before we can distribute the > source code with PHP.. Ac

Re: [PHP-DEV] PHP Module in source dist?

On Fri, 09 Nov 2001, John Lange wrote: > I've written a module for PHP which I believe would be a valuable add-on > for users of PHP. > > What is the feasibility of getting the module included in the source > distribution of PHP and how should I begin this process? > > I can't seem to find any F

Re: [PHP-DEV] Stack overflow in ext/pcre

On Fri, 02 Nov 2001, Sebastian Bergmann wrote: > Andrei Zmievski wrote: > > No. This is a limitation of the PCRE library, which manifests itself > > when you work with very long strings and fairly complex patterns. > > Can't we catch this in our extension? Crashes

Re: [PHP-DEV] cvsclean script

On Fri, 02 Nov 2001, Markus Fischer wrote: > I'd expect running cvsclean cleans up the source tree in a > way it *works like* a fresh cleanout. But I don't want my private > files floating in the tree (like some private testing c sources, > some diffs and what else) to be deleted when they don

Re: [PHP-DEV] Stack overflow in ext/pcre

On Fri, 02 Nov 2001, Sebastian Bergmann wrote: > Alexander Merz wrote: > > set mem_limit to high value ( >32MB), running PHPDoc over PEAR is a > > hardcore test... > > Nevertheless, I would expect a PHP warning instead of a crash, no? No. This is a limitation of the PCRE library, which manife

Re: [PHP-DEV] Benjamin Kromann

On Thu, 01 Nov 2001, Frank Kromann wrote: > Hi, > > It is getting late now in CA, but I have to tell you all about Benjamin Kromann, our >new son :-) > > He was born last night at 11:23pm and he is a healthy boy 50 cm long and he weighs >3550 g. Mis mom is doing very well allthough we all need

Re: [PHP-DEV] sytanx again

At 04:34 AM 10/27/01 +0200, Zeev Suraski wrote: >At 14:39 26/10/2001, Jani Taskinen wrote: > >>I'd rather see these magic hacks to be removed altogether.. >>+1 for removing short-tags and the hacks. > >+1 for kicking Jani in the PHP congress :) I can't be there, so you'll have to do the job for b

Re: [PHP-DEV] include and extra newline

On Thu, 25 Oct 2001, [EMAIL PROTECTED] wrote: > Uh, are you sure? How did you create a.txt? Try: > od -c a.txt Hmm, you are right. False alarm. -Andrei "The secret of flying is to throw yourself at the ground, and miss." -- Douglas Adams -- PHP Development Mailing List

[PHP-DEV] include and extra newline

'include' seems to put an extra newline after the included file. Example: a.php - start::end a.txt - middle The output is: start:middle :end Note that there is no newline at the end of 'middle' in a.txt, yet PHP puts one in anyway. This screws up Smarty, so I'd like to find out why th

Re: [PHP-DEV] Current CVS + Apache2 on Linux

On Thu, 25 Oct 2001, Hartmut Holzgraefe wrote: > diff -u2 -b -w -B Uh, what do these options do? They aren't documented in my version of CVS (1.11). -Andrei "The galaxy is, in other words, an immensely, intrinsically, and inexhaustibly interesting place." -- Iain M. Banks -- PHP Developme

Re: [PHP-DEV] For Wez : Stream Abstraction over a String

On Tue, 23 Oct 2001, l0t3k wrote: > > Perhaps I'm missing something, but can you explain how this is better > > than what we have now? > the power of abstraction Yes, but abstraction is not always necessary, wouldn't you agree? > i'll give you an example of why i want it. im working on resultse

Re: [PHP-DEV] For Wez : Stream Abstraction over a String

On Tue, 23 Oct 2001, Wez Furlong wrote: > Yep, or something like it. > > In some other code that I an using to test my streams idea, I have > implemented something a bit like a TMemoryStream that can do more or > less what you need - off the top of my head it looks sth like this; > > str = strea

[PHP-DEV] TODO-4.1.txt

We might want to rename this file.. :-> -Andrei -- PHP Development Mailing List 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] overload extension

On Fri, 19 Oct 2001, Edin Kadribasic wrote: > I was playing with it and it works as advertised. One question: what is the > meaning of return value in __set()? You are supposed to return true if you were able to set property successfully, false otherwise. Right now it doesn't do much, since Zend

Re: [PHP-DEV] Converting to new parameter parsing API

On Fri, 19 Oct 2001, Jason Greene wrote: > Don't worry I am planning on that, I have one function down : ) Not worrying, just hoping that people will start doing that. It really simplifies the parameter parsing in most cases and standardizes error messages. -Andrei "Man, if you gotta ask, you'l

[PHP-DEV] Converting to new parameter parsing API

I have started to convert ext/standard to use new parameter parsing API, as you may have noticed from commit messages. It would be nice if every extension author could take time and do the same for their extension. -Andrei * Programming is an art form that fights back. * -- PHP Development Mail

[PHP-DEV] overload extension

So, has anyone given the overload extension a try? I'm just looking for feedback. -Andrei * Unix is user friendly, it is just chooses its users selectively. * -- PHP Development Mailing List To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL

Re: [PHP-DEV] making mail() funtion work without sendmail on UNIX systems

For the record, I agree with Rasmus on this one. It sounds silly to reinvent the wheel on UNIX. On Fri, 19 Oct 2001, Rasmus Lerdorf wrote: > On Fri, 19 Oct 2001, Hartmut Holzgraefe wrote: > > > Rasmus Lerdorf wrote: > > > > > I am really not a big fan of putting smtp code into PHP on UNIX. Th

[PHP-DEV] Re: [PHP-GTK-DEV] Re: [PHP-DEV] Re: [PHP-GTK-DEV] Help - Merging Resource into a call_function array

On Thu, 18 Oct 2001, Alan Knowles wrote: > Probably worth continuing on php-gtk-dev only... > > I was getting a bit further with > MAKE_STD_ZVAL(myresource); > ZVAL_RESOURCE(myresource, gs) ; > /*ZEND_REGISTER_RESOURCE(myresource, gs, le_gtkhtmlstream); */ > now the functi

Re: [PHP-DEV] Help - Merging Resource into a call_function array

I don't understand the problem, can you rephrase? On Thu, 18 Oct 2001, Alan Knowles wrote: > Can someone help me out with this one, - I'm sure that I've not acheived what I was >aiming at - adding the Resource, myresource to the array prior to calling the >callback function > > the code be

Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems

On Thu, 18 Oct 2001, Brian Moon wrote: > Ok, > > I played with the code in zend_compile.c last night and came up with this > solution. The attached file will only issue a NOTICE for duplicate > functions from the same line and file. It will still issue an ERROR for > duplicate functions of a di

[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Tue, 02 Oct 2001, Jason Greene wrote: > 01 a-tag > 05 a-open-tagpic x(3) value ' 05 pic x(3) value 'href' > 05 a-hrefpic x(50) > 05 a-close-open-tag pic x(1) value '>' > 05 a-display pic x(20) >

[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Tue, 02 Oct 2001, Jason Greene wrote: > by then we might as well use English words as operators : ) PHP-COBOL, anyone? -Andrei * We are not a clone. * -- PHP Development Mailing List To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROT

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

On Tue, 02 Oct 2001, Jason Greene wrote: > Well you got me there, > > If you took a look at my message headers, you would see > what evil client I am using at this moment. I try not to rely > so much in my client because I am not always at a console > with my mail client of choice (reason I shou

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

On Tue, 02 Oct 2001, Jason Greene wrote: > Don't worry I am not saying that I won't read bug mails, I still do. > Its just that sometimes an important discussion topic will hit php-dev > and it will be sandwiched between 50 bug updates( not just bugs), and I miss it. > Now I use filters and everyt

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

On Tue, 02 Oct 2001, Rasmus Lerdorf wrote: > > i joined this group to read about php-development, not about bugs. > > The two are joined at the hip. Well said. -Andrei "Computers are useless. They can only give you answers." --Pablo Picasso -- PHP Development M

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

On Tue, 02 Oct 2001, Chris Gardner wrote: > Well, I do have an email filter applied. I do see your point about > the discussions being severely related, but if you seperate the two > with an email filter anyways, then you're seperating the > converastions. If you seperate the group, the conversa

[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Tue, 02 Oct 2001, Jason Greene wrote: > This easy to understand, efficient (no time consuming code to interpret whether > a class was intended), no backwards compatibility issues, > no ambiguity, and its not the first 3 symbol operator to hit php. Yeah, I wonder what we'll be saying when 4- an

[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Mon, 01 Oct 2001, Harald Radi wrote: > yes, but how do you define them ? > > if it's like this: > > namespace Foo; > define("CONSTANT", 123); > > it won't be a problem either because then a class can't contain such a > definition (yet) and there won't be any ambiguities too. That's how I wa

Re: [PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Mon, 01 Oct 2001, Harald Radi wrote: > i don't either, but how else will you bind constants to a class / > namespace ? echo Foo::CONSTANT; -Andrei "Try to spend the next 30 seconds not thinking about a blue-eyed polar bear." -Feodor Dostoevsky -- PHP Development Mailing List

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Mon, 01 Oct 2001, Harald Radi wrote: > why ? > > > class Foo { > final $BAR = "blah"; > } > > namespace Foo; > > class Bar { > static function bar() { > echo $Foo::BAR; > } > } > > > if (Foo::Bar::bar() === $Foo::BAR) { > echo "juhuuu"; > } else { > echo "damn"; > } > > > you hav

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Mon, 01 Oct 2001, Chuck Hagenbuch wrote: > As do I... Andi, Zeev - are there technical problems with this? We already have > static class methods; having static class variables and static class-specific > constants seems like a logical extension of this to me, and it gives you a > class-is-a

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity

On Mon, 01 Oct 2001, Markus Fischer wrote: > On Mon, Oct 01, 2001 at 04:36:44PM +0200, Zeev Suraski wrote : > > Stupid suggestion, is ::: (three colons) pushing it? > > For me better than anything else which came up (smileys, > arithmetical operators, comments). I step away from the computer

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/cpdf cpdf.c /ext/dba...

On Thu, 27 Sep 2001, Stig Sæther Bakken wrote: > ["Jeroen van Wolffelaar" <[EMAIL PROTECTED]>] > > jeroen Tue Sep 25 18:48:46 2001 EDT > > > > Modified files: > > /php4/ext/cpdf cpdf.c > > /php4/ext/dba dba.c dba_db2.c dba_db3.c dba_dbm.c dba_gdbm.c > >

Re: [PHP-DEV] Forking

On Wed, 26 Sep 2001, mike wrote: > Hi all, > > I have written an online MP3 jukebox that streams the currently playing > MP3 to winamp / xmms / macamp etc. It would be *very* useful if > I could fork PHP processes from within a script - are there any plans to > implement a fork() in PHP? > > BTW

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

On Tue, 25 Sep 2001, Jani Taskinen wrote: > Like Zeev said, we release new versions too often anyway. I think we're doing just fine. -Andrei The main reason Santa is so jolly is because he knows where all the bad girls live. -- George Carlin -- PHP Development Mailing List

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

On Tue, 25 Sep 2001, Stig Sæther Bakken wrote: > I think we should be flexible to make this practical, the core of the > idea is that you should not get any surprises when upgrading just "b", > and no API surprises when upgrading "m". > > There's a question about whether the API should be defined

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

On Mon, 24 Sep 2001, Jani Taskinen wrote: > 2. General rules for PHP, Zend and PEAR/C-extensions > > > v.m.b (e.g. 4.0.8) > > v = Functions removed, function behaviour changed, API changes, > major parts rewritten. (BC might be broke

[PHP-DEV] ZEND_INIT_MODULE_GLOBALS problem

I've run into the following problem recently: PHP_MINIT(foo) { ZEND_INIT_MODULE_GLOBALS(foo, NULL, NULL); } If ZTS is not defined then the compilation aborts with "called object is not a function" because ZEND_INIT_MODULE_GLOBALS tries to call NULl as a function name. How should this be

Re: [PHP-DEV] preg_* functions not working as expected (as in perl) 4.0.6

I assure you that PHP preg_* functions are working properly. You are experiencing an issue with escaping -- please try using this expression: /('(([^']*')*)([^']*)') On Tue, 18 Sep 2001, Grzegorz Prokopski wrote: > Hi ! > > I found that following regular expression patern: > /('(([^']*\\')*

Re: [PHP-DEV] PHP 3.0 Bug Summary Report

It might have.. On Tue, 18 Sep 2001, Stig Sæther Bakken wrote: > What's up? Did the 4.0 bug summary report grow too big for the list > again? > > - Stig > > -- > Stig Sæther Bakken <[EMAIL PROTECTED]> > Fast Search & Transfer ASA, Trondheim, Norway > > -- > PHP Development Mailing List

Re: [PHP-DEV] Simple wildcard matching

On Thu, 13 Sep 2001, Hartmut Holzgraefe wrote: > Alexander Wagner wrote: > > RTM ;-) > > http://php.net/preg_quote > > but then i'm the ereg sort of person ... quotemeta() -Andrei "I think it would be a good idea." -- Mahatma Gandhi, when asked what he thought of Western civilization... -- P

Re: [PHP-DEV] Woah

On Fri, 07 Sep 2001, Cristopher Daniluk wrote: > Again, as mentioned before, this is suitable: > > function _($string) { return gettext($string); } > > once in your code. Voila, now you can still have your short cut, and we can > still have our consistent naming structure. Sure, it would be an a

Re: [PHP-DEV] Woah

On Sat, 08 Sep 2001, Zeev Suraski wrote: > Again, by deprecating it now, the immediate action would be removing any > reference to it from the documentation (the very little there is). There > are a hell of a lot PHP users to come than there are existing users of PHP, > so we might as well lim

Re: [PHP-DEV] zend_parse_parameters

On Sat, 08 Sep 2001, Andi Gutmans wrote: > Anyway, performance aside, there is also the point of conventions. Up to > now, PHP has been pretty much a functional language with an argument list. > It might make sense for big certificates to be passed as arrays. But > instead of going ahead and di

Re: [PHP-DEV] Woah

At 05:33 AM 9/8/01 +0300, Zeev Suraski wrote: >That's unfortunate. IMHO, it should be phased out. I'm against it. _() has been around forever as part of gettext package and people who expect to find it in PHP will be pretty disappointed. -Andrei -- PHP Development Mailing List

Re: [PHP-DEV] zend_parse_parameters

On Fri, 07 Sep 2001, Wez Furlong wrote: > How about a new zend function that will parse values, much like > zend_parse_parameters does, except that it operates on a hash and allows > you to specify the keys of the hash: > > my_zval = array( > "firstname" => "fred", > "lastname" => "bloggs", >

Re: [PHP-DEV] Better shell scripting

On Fri, 07 Sep 2001, Boian Bonev wrote: > i can see just one reason - most people use the same php binary both for cgi > and shell scripting. if this change is to be introduced in php then at least > three builds will be performed - for shell, cgi and web server module. btw > what happened with th

Re: [PHP-DEV] Better shell scripting

On Fri, 07 Sep 2001, Stig Sæther Bakken wrote: > What if we introduced a -p option to PHP that starts the Zend parser > in "PHP mode"? For any other files (include/require), it starts in > "HTML mode" though. How about we have a separate sapi backend that really does all this stuff properly with

[PHP-DEV] bonsai fixed

I have fixed the bonsai.php.net so that all the checkins are visible. Sorry that it didn't quite work before. -Andrei Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. -- PHP Development Mailing List

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c

On Thu, 06 Sep 2001, Zeev Suraski wrote: > I don't think I ever said they're slower. I asked Andrei if he ever tested > their performance, and he said he didn't. So we don't know :) Well, obviously they are slower than the simple zend_get_parameters_* functions, due to the simple reason that t

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c

On Wed, 05 Sep 2001, Sterling Hughes wrote: > Ok, I'm sold... I understand the basics of the format and the > function, but is the following possible?:: > > In the situation of rand() when its that are two arguments are > mandatory, or no arguments are mandatory? I failed to par

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c

On Wed, 05 Sep 2001, Sterling Hughes wrote: > sterling Wed Sep 5 16:52:45 2001 EDT > > Modified files: > /php4/ext/standardrand.c > Log: > a bit of api cleanup... move range stuff into a macro (properly :) I have to ask once again. Why not use zend

Re: [PHP-DEV] Returning a string from an executed script?

On Wed, 29 Aug 2001, Zeev Suraski wrote: > We could improve zend_execute_scripts() to take an optional zval * to hold > the return value, it's already quite ready for this kind of thing. Good idea. -Andrei * If it's never finished, you can't prove it doesn't work. * -- PHP Development Mailing

Re: [PHP-DEV] API Thoughts?

At 07:29 PM 8/26/01 -0400, Sterling Hughes wrote: > Hey, > > Currently working on the Binary Tree implementations for the ADT > extension and was wondering what people thought as more intuitive, > something like: > > $tree = tree_new(AVL_TREE); > tree_insert($tree, $element

Re: [PHP-DEV] for the php-gtk people

On Fri, 24 Aug 2001, Sterling Hughes wrote: > Some people prefer having all applications on the same platform look > the same. ie, GTK programs look a bit odd, compared to your normal > win32 apps (or on KDE for example). You are right, but look at it from this perspective. An applic

Re: [PHP-DEV] for the php-gtk people

On Fri, 24 Aug 2001, Sterling Hughes wrote: > My understanding is that it provides "native" support -- ie, you > write for wxWindows and then when compiling for Win32 systems, it > will use the native win32 interface (unlike GTK programs -- which > look the same on win32 and linux)

Re: [PHP-DEV] zend_parse_parameters

On Fri, 24 Aug 2001, Wez Furlong wrote: > I understand, and yes, they would. > > It just seems a shame to have to declare those ints when they are not > used. If you come up with a solution that covers both fronts, I promise we'll consider it. :) > zend_parse_parameters does a great job of redu

Re: [PHP-DEV] zend_parse_parameters

On Fri, 24 Aug 2001, Wez Furlong wrote: > When parsing strings from parameters with zend_parse_parameters, it is > required that the programmer pass in an int to receive the length of the > string. > > Could we relax this and allow a NULL instead if we do not need the length > of the string? It

Re: [PHP-DEV] for the php-gtk people

On Fri, 24 Aug 2001, Marc Boeren wrote: > I've been looking at crossplatform gui-development, and one of the > things that is easily found is the wxWindows tools (www.wxwindows.org). > > This looks to be sort of the same as php-gtk, but it does windows, motif > os/2 and mac as well (aside from g

Re: [PHP-DEV] Re: Bug #12929 Updated: crash in array_map with associative arrays

They won't be preserved if you work with more than 1 array. > >I can fix the crash, but what should be done with the keys? Should they be > >just ignored? I think it only makes sense to preserve them if you are > >mapping a single arrays, in case there are 2 or more, the keys are > >useless..

Re: [PHP-DEV] Branching ext/standard?

On Wed, 22 Aug 2001, Zeev Suraski wrote: > 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 > committed to the main branch, and f

Re: [PHP-DEV] pif

On Wed, 22 Aug 2001, Zeev Suraski wrote: > It's not about possible symbol clashes... > When debugging (or when reading code), it helps to know what's a part of > the API and what isn't. It also makes different types of prefix-based > searching (e.g., gdb's completion, or emacs' search feature)

Re: [PHP-DEV] pif

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 > php_mysql_do_connect()). Explain what the point is, then. I would

Re: [PHP-DEV] pif

On Wed, 22 Aug 2001, Jeroen van Wolffelaar wrote: > > 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,

Re: [PHP-DEV] pif

On Wed, 22 Aug 2001, Jeroen van Wolffelaar wrote: > > 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 wa

Re: [PHP-DEV] object to string convertion patch

On Wed, 22 Aug 2001, Jeremy Bettis wrote: > I changed php (current CVS) to add another magic method to Objects, > __toString(). Whenever an object needs to be converted to a string, then it > will first try to call __toString() and if it can't, then it will just > return "Object" like now. Good

Re: [PHP-DEV] pif

On Wed, 22 Aug 2001, Jeroen van Wolffelaar wrote: > anyway, I was thinking about helper-functions, which you only want to use > straight from an other function. Mostly this will be the set of functions > which are not PHP_FUNCTION or PHP_API. > > A example in math.c: > _php_math_number_format ->

<    1   2   3   4   5   6   >