[PHP-DEV] PHP compiler

2003-08-14 Thread Jeremy S. Johnstone
After seeing the conversation on the PHP archive idea (having a PHP
equivalent of a jar file), it reminded me of an idea I had a long time
ago. Has anyone ever thought of writing a PHP compiler which would
compile a PHP script into native machine code? If you have thought of
it, what stopped you from building it? I would be highly interested in
joining a team which wanted to push the limits of PHP by doing something
like this. I think this is the next logical step in the PHP for
anything and everything goal.
 
Jeremy


RE: Re[4]: [PHP-DEV] PHP compiler

2003-08-14 Thread Jeremy S. Johnstone
PS: I am one of the last people you should be complaining at about php
isn't intended for that; perhaps you should study your PHP history
before you make your next post.

That is why I apologized if I came off rude. I snapped back without
realizing who had actually made the post I was responding to.

Jeremy

-Original Message-
From: Wez Furlong [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 06, 2003 11:11 AM
To: Jeremy S. Johnstone
Cc: [EMAIL PROTECTED]
Subject: Re: Re[4]: [PHP-DEV] PHP compiler


Damn, and I was just about to respond suggesting that you cancel your
cvs account too ;-)

It's easy to think that PHP can and should be applied to everything that
you might want to do, ranging from your web pages to managing the power
on your ACPI laptop and so on, but you do need to keep sight of the fact
that PHP was designed for The Web Problem, and that The Web Problem
will always be the primary focus of PHP.

Anything that *really* doesn't fit with that just isn't going to get
into the core.

However, quite often, you can extend or otherwise modify PHP to suit
your own needs - it is OpenSource after all.

--Wez.



- Original Message -
From: Jeremy S. Johnstone [EMAIL PROTECTED]
To: 'Wez Furlong' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, August 06, 2003 4:54 PM
Subject: RE: Re[4]: [PHP-DEV] PHP compiler


 I apologize if I sounded rude at all, it's just that I am sick of 
 people telling me php isn't intended for that, when I come up with 
 new ideas. I ask those same people what they think PHP is for, and 
 inevitably I get some variation on LAMP. If PHP is only intended to 
 ever be a web programming language and has no plans of branching out

 in the future, I think PHP is grossly limiting itself.

 Jeremy

 -Original Message-
 From: Jeremy S. Johnstone [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, August 06, 2003 10:42 AM
 To: 'Wez Furlong'
 Subject: RE: Re[4]: [PHP-DEV] PHP compiler


 Okay, so you want to arbitrarily limit PHP's use to simple web 
 applications? With attitudes like this, maybe I should just cancel my 
 CVS account at php.net and go join a Microsoft ASP team somewhere. If 
 myself and other person who started the Java-alike thread want to 
 discuss PHP having internal support for features such as this, I think

 we are well entitled to. Of course that doesn't mean the core 
 programmers have to head our desires and actually allow it to be 
 included, but it doesn't stop us from discussing the merits of such a 
 solution.

 Jeremy


 -Original Message-
 From: Wez Furlong [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, August 06, 2003 10:30 AM
 To: Simeon Koptelov; [EMAIL PROTECTED]
 Subject: Re: Re[4]: [PHP-DEV] PHP compiler


 This isn't really an internals matter, and isn't going to happen in 
 the core (for various reasons). It is something you can implement 
 yourself using your own extension and the streams API.

 Can we please drop this thread (and related Java-alike threads) now 
 and replace them with more technical issues actually related to the 
 internals of PHP ? :-)

 --Wez.






-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: Re[2]: [PHP-DEV] PHP compiler

2003-08-14 Thread Jeremy S. Johnstone
The only problem with that approach is that you have to distribute the
php executable and your program is loaded using a command line similar
to:

Php -par someapp.par

Instead of simply:

./someapp

I know this is a small difference, but it makes a big difference when
you are dealing with customers who are, how should I say this, not as
computer savy as they should be.

Jeremy

-Original Message-
From: Simeon Koptelov [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 06, 2003 10:37 AM
To: [EMAIL PROTECTED]
Subject: Re[2]: [PHP-DEV] PHP compiler


Hello Jeremy,

Wednesday, August 6, 2003, 8:16:49 PM, you wrote:

JSJ No that is not what I meant. What I meant is so when you write an 
JSJ application using PHP-GTK you could distribute a single executable 
JSJ instead of the current method. Personally the current method 
JSJ doesn't bother me, but to a laymen user it is not what they are 
JSJ used to and causes issues. I am not looking for a speed improvement

JSJ really, just a useability improvement for those who choose PHP is 
JSJ equally as suited to desktop applications as it is to web 
JSJ applications.

JSJ Jeremy

Then the jar-like archives is all that we really need :) And in web apps
this will be very handy too.

There's no need in PHP code compilation in this case -- you simply pack
all package files and dirs in one archive using tar+bz2 or zip or
something else.

-- 
Best regards,
 Simeonmailto:[EMAIL PROTECTED]


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] [Proposal] Idea for Application level variables

2003-08-14 Thread Jeremy S. Johnstone

I noticed something which you said, and forgive me if this part may be
obvious, but you mentioned across instances of applications? Do you mean
something like a shared memory between all web connections to the
server? One issue I could forsee if this is the case, what happens when
there is no connections to the server for an extended period of time
(extended being even as short as a few minutes)? Should PHP store this
superglobal's value indefinitely, or perform some type of garbage
collection? If PHP should clean up after itself, what criteria would you
expect to be followed for deciding if something is no longer useful? I
don't think you would want this criteria configurable in a ini setting
for example, because hosting companies all do something different. If a
developer were to use this feature, they would need a standardized
timeframe that the values would last. This is just a couple things I
think would need to be considered before implementing something like
this. If I am way out in left field, I apologize.

-Jeremy

-Original Message-
From: Davey [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 07, 2003 8:15 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] [Proposal] Idea for Application level variables


Andrey,

  // masv = my application shared vars. This is the name of the shared
var.   // Only the first 4 chars are used to calculate memory address.
 $_APPLICATION = new Shm_Protected_Var(masv, 1024 /*memory*/);  
$_APPLICATION-start_section()   var_dump($_APPLICATION-getVal());
  $_APPLICATION-end_section();

This isn't quite as transparent as $_SESSION is and $_APPLICATION would 
also not be a superglobal. What I would like to see at the end of this 
is a $_APPLICATION variable (or $_APP? some poeple complained that 
$_APPLICATION is too long) that behaves *exactly* like $_SESSION (in 
assignment etc)  except that its values are available not across 
sessions but across applications and instances of applications.

- Davey

Andrey Hristov wrote:

  Hi Davey,
 I don't know whether this will be implemented in an extension but
 there are sollutions in userland : to use sysvshm+sysvsem or shmop. 
 The sysvshm+sysvsem extension exposes the C api. I know for 2 wrappers

 around this API to make the use of shared memory (and thus something 
 like application wide variables) easy to implement in userspace:
 1)

http://www.php-tools.de/site.php?PHPSESSID=b4a4ab7142b7d3209c7eee976912
0cba
 file=patMisc/shmc.xml
 2)http://www.hristov.com/andrey/projects/php_stuff/shm.php.gz
 
 The second one is written according to PEAR CS. It exposes 4 classes.
 Shm_Protected_Var is what is needed to implement $_APPLICATION:
 
 // masv = my application shared vars. This is the name of the shared
 var. // Only the first 4 chars are used to calculate memory address. 
 $_APPLICATION = new Shm_Protected_Var(masv, 1024 /*memory*/);
 $_APPLICATION-start_section() var_dump($_APPLICATION-getVal());
 $_APPLICATION-end_section();
 
 Regards,
 Andrey
 
 
 - Original Message -
 From: Davey [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Thursday, August 07, 2003 3:36 PM
 Subject: [PHP-DEV] [Proposal] Idea for Application level variables
 
 
 
Hey,

I'm quite new to this, so please don't shoot this down too harshly. If
I don't explain something clearly enough, please ask me.

Because Application variables are pretty much shared session
variables, I wonder if perhaps the session code can be modified to 
handle these variables.

In userland, the implementation would be similar to sessions, and can
work on two levels, for a single file or for a group of files.

Userland usage examples:

// cross file (i.e. an entire website)
application_vars_start('my_website'); // my_website is used as the SID

$_APPLICATION['website_users'] += 1;

// single file
application_vars_start(); // uses filename based SID, see below
$_APPLICATION['page_users'] += 1;

I figured that by using the following in place of the user-input SID,
you can easily have page-wide application vars, and by using the arg 
for
application_var_start() in the the place of
SG(request_info).path_translated you can have it across whatever you
like, problem is when you have multiple sites on the same server,
someone else might choose the same name

PHP_MD5_CTX context;
PHP_MD5Init(context);
PHP_MD5Update(context, SG(request_info).path_translated,
strlen(SG(request_info).path_translated));
PHP_MD5Final(key, context);

I don't know if this is clear enough, but in my head at least, it
seems a inexpensive solution to something PHP is (in some peoples 
opinion) lacking. (Note: SRM seems like overkill just for this).

Another nice thing about this, as it'll be using the Session
infrastructure it could use the session handlers aswell (sqlite, mm 
etc)

one problem that has been mentioned is multi-threaded situations, but
I would assume that either the current session code doesn't suffer 
from this (and therefore neither will this) or that the session code 
will need to be 

RE: Re[4]: [PHP-DEV] PHP compiler

2003-08-10 Thread Jeremy S. Johnstone
I apologize if I sounded rude at all, it's just that I am sick of people
telling me php isn't intended for that, when I come up with new ideas.
I ask those same people what they think PHP is for, and inevitably I get
some variation on LAMP. If PHP is only intended to ever be a web
programming language and has no plans of branching out in the future, I
think PHP is grossly limiting itself.

Jeremy

-Original Message-
From: Jeremy S. Johnstone [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 06, 2003 10:42 AM
To: 'Wez Furlong'
Subject: RE: Re[4]: [PHP-DEV] PHP compiler


Okay, so you want to arbitrarily limit PHP's use to simple web
applications? With attitudes like this, maybe I should just cancel my
CVS account at php.net and go join a Microsoft ASP team somewhere. If
myself and other person who started the Java-alike thread want to
discuss PHP having internal support for features such as this, I think
we are well entitled to. Of course that doesn't mean the core
programmers have to head our desires and actually allow it to be
included, but it doesn't stop us from discussing the merits of such a
solution.

Jeremy


-Original Message-
From: Wez Furlong [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 06, 2003 10:30 AM
To: Simeon Koptelov; [EMAIL PROTECTED]
Subject: Re: Re[4]: [PHP-DEV] PHP compiler


This isn't really an internals matter, and isn't going to happen in the
core (for various reasons). It is something you can implement yourself
using your own extension and the streams API.

Can we please drop this thread (and related Java-alike threads) now and
replace them with more technical issues actually related to the
internals of PHP ? :-)

--Wez.






-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] user contributed notes

2003-07-14 Thread Jeremy S. Johnstone

I have been doing cleanups of the SNMP area over the past couple days. I
am planning on bringing the documentation fully up to date with the
source code. I also cleaned up some of the notes which had broken links
or violated note policies. In regards to user notes, I am simply
following the guidelines outlined in
http://www.php.net/manual/howto/chapter-user-notes.html.

-Jeremy

-Original Message-
From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 14, 2003 3:08 PM
To: [EMAIL PROTECTED]
Cc: Harrie Hazewinkel
Subject: [PHP-DEV] user contributed notes


Hi,

Could someone explain what the purpose is of 'User Contributed Notes. I
noticed some notes as part of snmpget.php which are not notes, but
questions for help. http://www.php.net/manual/en/function.snmpget.php

Not sure what to do with them, and if I can delete the questions??

regards,

Harrie


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php





-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] xml_set_element_handler and xml_parse

2003-06-28 Thread Jeremy S. Johnstone
I am running into a strange problem which goes in direct opposition to
what is said in the documentation. I need to know what is the correct
behaviour before I update the documentation.

Problem is this:

With the function xml_set_element_handler, if you don't set an actual
end element handler (you set it to  or FALSE) the function xml_parse
will return the following error:

Xml_parse(): Unable to call handler () in /path/to/script on line ##

The documentation explicitely states that If a handler function is set
to an empty string, or FALSE, the handler in question is disabled. 

If I create a dummy function which actually does absolutely nothing and
put it's name as the end element handler I do not get the above error
message.

Am I doing something wrong, is this a bug, or should I update the
documentation for this function?

PHP version: 4.3.2
XML expat version: 1.95.4

 ,,,
   (Ô Ô)
===oOO==(_)==Ooo===
 Jeremy Johnstone
 [EMAIL PROTECTED]
.oooO Oooo.
==( )=( )==
  \ ( ) /
  \_) (_/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php