Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread Tommy Pham
On Sat, Mar 12, 2011 at 2:40 AM, David Hutto  wrote:
>>
>> As I mentioned below, if PHP is sluggish, shouldn't it be brought up
>> to the PHP developers instead?  Why would you try include more
>> complexity?
>
> I'm sure it has, it's called benchmarks. And they can't top C or
> Fortran, last I saw. But that is not the point. And did you not see my
> point about how it's just an initial usage of C to put out php and
> html/css/js, and that 'complexity' must be as simple as a printf
> function in another language. Why don't you snatch your nose out of
> php's asshole for a second to realize it's not the center of a
> multilanguage project, and sometimes neither is C, or any other
> language It's the consumers, or the designers, or yours.
>

Then you obviously didn't read my example fully.  Isn't
Javascript/Flash a language?  Javascript/Flash provides what PHP
lacks, client side.  If PHP has performance issues, you're introducing
complexity by adding C into the mix when the performance issues should
be brought to the PHP developers' attention, as stated before.  If you
really have issues with PHP's performance, why even bother to include
PHP then?  Why not just do C to crank out HTML, JS, and CSS since
portability isn't a concern as you've stated?  My nose isn't in PHP's
asshole.  I code in C# (ASP.NET and Winforms) when my need is there.
In some of those instances, I had to use PInvoke because C# didn't
provide the functionality I need.  So I don't have problems using
multi-language solution.  To me, your proposal just add complexity
into something that should have been properly addressed in the first
place.  This brings right along with the discussion about PHP
implementing threads.  If you need threads for better performance and
since PHP doesn't provide it, then I do see use for C.  Other than
that, I don't ATM.

>>

 Just a case scenario.  If C is included to 'to spit out the above in
 html/php/js/css' and should you happen to be out town/country on
 vacation, the other developer(s) doesn't know C and the application
 requires some minor bug fix or minor addition.  The problem is now
 that modification required is in C.
>>>
>>> No, the problem lies in the error message, which lies in the
>>> underlying language.
>
> If you don't know step by step function programming, or debugging,
> then why are you arguing with me?
>

Are you reading it correctly?  The 'No, the problem lies in the error
...' isn't my comment...

> And familiarity with work is in properly
>>> commented and documented code. If the company isn't willing to
>>> maintain that throughout the course of development, then your
>>> misunderstanding is money out of their pocket.
>
> Nah, just your clients, and that should have been accounted for in
> your project bid.
>
>>>
>>>
>>>   Do you want your vacation
 disturbed?
>>>
>>> For money, I comment and document, but disturbed isn't a problem, as
>>> long as it's a guaranteed under the contract.
>>>
>>> Except in the case of an emergency, I don't. :)
>>>
>>> But does the contract end at consumer misuse, or your discretion, and
>>> do they decide, or you? And then when does that end, when you're too
>>> important to respond, or had a better offer?
>>>
>>>  Not to
 mention if where you're vacationing at have a fast internet
 connection, or even an internet connection at all.  While this
 approach may mean job stability in this situation, I could see it
 opposite as it causes more down time for the business as being unable
 to adapt quickly to the ever changing needs required by the economy
 and/or customers/clients.  In the end, if the business can't stay in
 business, you're out of a job.  In one of my recent job experience, I
 was in a 3 person IT team.  d
>>>
>>> You mean you and a few guys/gals got together, and threw together an app?
>>>
>>>
>>> We have a DBA, developer (also the
 manager), and I'm the system/network/telecom admin.
>>>
>>> You probably got a thesaurus, and small business guide to success too.
>>>
>>
>> No, the DBA is needed because the amount of the data that our site
>> handles for the customers specific to local region.  The manager just
>> happens to be a software developer.
>
> Did he tell you that, or provide credentials? That;s what most project
> heads do, I assume.
>

Yes, he showed me his coursework and tried to get the PhD.  Due to a
family emergency, he couldn't complete it at that time.  Yes, we all
saw each other's resume and CV.  And cross trained to provide support
in the areas where anyone of us lacks the basics so we could provide
full 24/7 support in the event that there are 2 of 3 IT members
available for _any reason_: vacation, family emergency, etc...

> We only wrote codes because we
>> needed some functionality to improve efficiency of the site.  Prior to
>> writing the code, we had submitted a BRD to corporate for them to
>> provide us that functionality.  They said it's not necessary with

Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
>
> As I mentioned below, if PHP is sluggish, shouldn't it be brought up
> to the PHP developers instead?  Why would you try include more
> complexity?

I'm sure it has, it's called benchmarks. And they can't top C or
Fortran, last I saw. But that is not the point. And did you not see my
point about how it's just an initial usage of C to put out php and
html/css/js, and that 'complexity' must be as simple as a printf
function in another language. Why don't you snatch your nose out of
php's asshole for a second to realize it's not the center of a
multilanguage project, and sometimes neither is C, or any other
language It's the consumers, or the designers, or yours.

>
>>>
>>> Just a case scenario.  If C is included to 'to spit out the above in
>>> html/php/js/css' and should you happen to be out town/country on
>>> vacation, the other developer(s) doesn't know C and the application
>>> requires some minor bug fix or minor addition.  The problem is now
>>> that modification required is in C.
>>
>> No, the problem lies in the error message, which lies in the
>> underlying language.

If you don't know step by step function programming, or debugging,
then why are you arguing with me?

And familiarity with work is in properly
>> commented and documented code. If the company isn't willing to
>> maintain that throughout the course of development, then your
>> misunderstanding is money out of their pocket.

Nah, just your clients, and that should have been accounted for in
your project bid.

>>
>>
>>   Do you want your vacation
>>> disturbed?
>>
>> For money, I comment and document, but disturbed isn't a problem, as
>> long as it's a guaranteed under the contract.
>>
>> Except in the case of an emergency, I don't. :)
>>
>> But does the contract end at consumer misuse, or your discretion, and
>> do they decide, or you? And then when does that end, when you're too
>> important to respond, or had a better offer?
>>
>>  Not to
>>> mention if where you're vacationing at have a fast internet
>>> connection, or even an internet connection at all.  While this
>>> approach may mean job stability in this situation, I could see it
>>> opposite as it causes more down time for the business as being unable
>>> to adapt quickly to the ever changing needs required by the economy
>>> and/or customers/clients.  In the end, if the business can't stay in
>>> business, you're out of a job.  In one of my recent job experience, I
>>> was in a 3 person IT team.  d
>>
>> You mean you and a few guys/gals got together, and threw together an app?
>>
>>
>> We have a DBA, developer (also the
>>> manager), and I'm the system/network/telecom admin.
>>
>> You probably got a thesaurus, and small business guide to success too.
>>
>
> No, the DBA is needed because the amount of the data that our site
> handles for the customers specific to local region.  The manager just
> happens to be a software developer.

Did he tell you that, or provide credentials? That;s what most project
heads do, I assume.


We only wrote codes because we
> needed some functionality to improve efficiency of the site.  Prior to
> writing the code, we had submitted a BRD to corporate for them to
> provide us that functionality.  They said it's not necessary without
> further explanation.  In the end, we all left the company because
> upper management didn't seem to be really business & economic aware.
> Even the site manager left the company too.  For me, when the CEO
> gives a presentation about outlook for the company, he said that
> 'we're still trying to figure out why the company didn't meet last
> year projections'.  This was 6 months in the new fiscal year.  I lost
> all respect for upper management.  In all my job experiences, except
> that company, all of the upper management are very concerned about how
> on track is the company with the projections on a month by month
> basis.  They all wanted daily, weekly, and monthly reports.  That
> company didn't ask for any.
>
>>
>>   We all have cross
>>> discipline experience and train ourselves in areas we lack for basic
>>> support.
>>
>> Not going to argue there, see my response from experience above.
>>
>>  Every one of us don't have a problem taking a month vacation
>>
>>
>> Vacation in IT is an oxymoron, and so is intellectual unavailability,
>> especially with the current interconnectivity.
>>
>
> Is it?  In one of my job experience, a director once asked me why he
> didn't see any problems from my area.  I simply told him that if he
> did, then I wasn't be doing my job.

Maybe by 'problems' he meant other than what you think are problems.
ANd maybe he thinks your job is to report maybe employee unhapiness,
instead of employee misbehavior, maybe the miscommunication is in
terminology of the word "problem"

  That being said.  Doing your job
> means that you should still have a peace of mind to take a vacation or
> sleep better at night.

But how does the client take peace of mind when you're unavailable?




>
>>> out

Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread Tommy Pham
On Sat, Mar 12, 2011 at 1:31 AM, David Hutto  wrote:
> On Sat, Mar 12, 2011 at 4:10 AM, Tommy Pham  wrote:
>> On Sat, Mar 12, 2011 at 12:06 AM, David Hutto  wrote:
>>> On Sat, Mar 12, 2011 at 2:59 AM, Tommy Pham  wrote:
 On Fri, Mar 11, 2011 at 11:39 PM, David Hutto  wrote:
> On Sat, Mar 12, 2011 at 2:34 AM, Tommy Pham  wrote:
>> On Fri, Mar 11, 2011 at 11:26 PM, David Hutto  
>> wrote:
>>> On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
 On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  
 wrote:
> Although, right now, if I were going to be using all of those
> languages in unison(and I am), then I'd go with C, and spit them out
> to the browser for lower level control, as well as, to remain familiar
> with some of the main languages being used currently.
>

 But then how portable is your app?

>>>
>>> I'd have to refer to your reply:
>>>
>>> "This would depend on the original application design & code."
>>>
>>> If the original app is meant for specific hardware, and a specific
>>> company, then portability is null point.
>>>
>>
>> If that's the case why even bother with PHP?  Why not just do it in C
>> for pure speed?
>
> Speed wasn't the point- Multiple technology usage was the point. And
> if you're going to poise a browser for multiple intercepts(in terms of
> languages), then C *seems* to be the best was to move toward the
> displayment of it's descendants.
>
> If it's going to be a multi-language project, then it needs to be
> addressed with a multilanguage source to stem from, and C would seem
> like the optimum epicenter for propagation of this.
>
>
> I thought one of the major points of PHP is 'develop
>
>
>> anywhere and deploy anywhere'.
>>
>

 In the OP's case, where would C fit in when you have HTML, JS, and PHP
 - PHP would produce the resultant text in addtion to JS & HTML.  What
 would be the 'specific need' to do work in C where PHP, its many
 extensions and library (PECL & PEAR), and lots of the other PHP code
 based libraries/frameworks out there already to do the job?  The way I
 look at it, if too many languages are involved then most likely the
 application design is over complicated.
>>>
>>> Because you've been taught that C is over complicated in an
>>> optimization standpoint. Just to spit out the above in html/php/js/css
>>> in a C framework is simpler than you think. A little printf. And you
>>> speak of optimization, but lack the prethought for implementation for
>>> these optimizations.
>>>
>>> How can you move toward a lower level if you don't start on one. You
>>> seem stuck on the PHP portion of this, rather than the whole outlook
>>> of using multiple languages and technologies through a centralized
>>> means to accomplish a specific end, which can be easily optimized.
>>>
>>
>> I thought the whole objective of higher level language is to provide
>> an easier application design and coding, in addition to shorter
>> development & maintenance time.  Why go back to lower level, isn't
>> that defeating the purpose?
>
> That was the point of the term 'prototyping'. A language used to
> prototype, but built on a framework of optimization, in which the
> prototype language can be eliminated for the lower level performance
> bottlenecks.
>

As I mentioned below, if PHP is sluggish, shouldn't it be brought up
to the PHP developers instead?  Why would you try include more
complexity?

>>
>> Just a case scenario.  If C is included to 'to spit out the above in
>> html/php/js/css' and should you happen to be out town/country on
>> vacation, the other developer(s) doesn't know C and the application
>> requires some minor bug fix or minor addition.  The problem is now
>> that modification required is in C.
>
> No, the problem lies in the error message, which lies in the
> underlying language. And familiarity with work is in properly
> commented and documented code. If the company isn't willing to
> maintain that throughout the course of development, then your
> misunderstanding is money out of their pocket.
>
>
>   Do you want your vacation
>> disturbed?
>
> For money, I comment and document, but disturbed isn't a problem, as
> long as it's a guaranteed under the contract.
>
> Except in the case of an emergency, I don't. :)
>
> But does the contract end at consumer misuse, or your discretion, and
> do they decide, or you? And then when does that end, when you're too
> important to respond, or had a better offer?
>
>  Not to
>> mention if where you're vacationing at have a fast internet
>> connection, or even an internet connection at all.  While this
>> approach may mean job stability in this situation, I could see it
>> opposite as it causes more down time for the business as being unable
>> to adapt quickly to the ever changing needs required by 

Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
On Sat, Mar 12, 2011 at 4:31 AM, Tommy Pham  wrote:
> On Sat, Mar 12, 2011 at 12:22 AM, David Hutto  wrote:
>> This isn't a C/PHP question, or optimization, it's a matter of PHP
>> isn't always the center of attention, in terms of a development
>> process. In each language there are advocates, and it's admirable, but
>> ignorant in sight that what you're saying eliminates the rational, and
>> logical thought that there are other languages that can be utilized as
>> the center of development, and have higher level optimization in mind.
>>
>> If you use C, then as optimization, and software evolution occurs, you
>> can move toward elimination the higher level prototyping languages,
>> and move it toward the C (lower level)implementation. You start with
>> just the spit out portion of C, and use the higher levels to
>> prototype...then remove the higher level as you eliminate the
>> inefficient portions, and replace with lower level, C,
>> implementations of these higher level/platform dependent prototyped
>> functions.
>>
>
> Isn't this true for every other languages such Python, Perl, and Java?
>  They were written in C at the core.  If the language in use can't
> provide the functionality needed, then yes, I see the need for C.  If
> using C just for optimization, then aren't selling yourself short for
> longer development and maintenance time when too many languages
> involved?

Not C just for opto, but basic C for the later project utilization.
It's just a quick spit out of the other languages which are
interpolated to C string on the page.

A simple C string with everything else you want in the higher level
languages. But then you decide a few php results are slow, so you use
a C function. Then you decide a few python functions are slow when
returning a js mouseover, so you use a js or C function.

It's just a simple platform to use the higher level 'prototype' languages on.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
probably so, but it it's just another discussion we should have just
for evolutions sake. Each time it takes place, new info is added by
someone.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread Tommy Pham
On Sat, Mar 12, 2011 at 12:22 AM, David Hutto  wrote:
> This isn't a C/PHP question, or optimization, it's a matter of PHP
> isn't always the center of attention, in terms of a development
> process. In each language there are advocates, and it's admirable, but
> ignorant in sight that what you're saying eliminates the rational, and
> logical thought that there are other languages that can be utilized as
> the center of development, and have higher level optimization in mind.
>
> If you use C, then as optimization, and software evolution occurs, you
> can move toward elimination the higher level prototyping languages,
> and move it toward the C (lower level)implementation. You start with
> just the spit out portion of C, and use the higher levels to
> prototype...then remove the higher level as you eliminate the
> inefficient portions, and replace with lower level, C,
> implementations of these higher level/platform dependent prototyped
> functions.
>

Isn't this true for every other languages such Python, Perl, and Java?
 They were written in C at the core.  If the language in use can't
provide the functionality needed, then yes, I see the need for C.  If
using C just for optimization, then aren't selling yourself short for
longer development and maintenance time when too many languages
involved?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
On Sat, Mar 12, 2011 at 4:10 AM, Tommy Pham  wrote:
> On Sat, Mar 12, 2011 at 12:06 AM, David Hutto  wrote:
>> On Sat, Mar 12, 2011 at 2:59 AM, Tommy Pham  wrote:
>>> On Fri, Mar 11, 2011 at 11:39 PM, David Hutto  wrote:
 On Sat, Mar 12, 2011 at 2:34 AM, Tommy Pham  wrote:
> On Fri, Mar 11, 2011 at 11:26 PM, David Hutto  
> wrote:
>> On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
>>> On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  
>>> wrote:
 Although, right now, if I were going to be using all of those
 languages in unison(and I am), then I'd go with C, and spit them out
 to the browser for lower level control, as well as, to remain familiar
 with some of the main languages being used currently.

>>>
>>> But then how portable is your app?
>>>
>>
>> I'd have to refer to your reply:
>>
>> "This would depend on the original application design & code."
>>
>> If the original app is meant for specific hardware, and a specific
>> company, then portability is null point.
>>
>
> If that's the case why even bother with PHP?  Why not just do it in C
> for pure speed?

 Speed wasn't the point- Multiple technology usage was the point. And
 if you're going to poise a browser for multiple intercepts(in terms of
 languages), then C *seems* to be the best was to move toward the
 displayment of it's descendants.

 If it's going to be a multi-language project, then it needs to be
 addressed with a multilanguage source to stem from, and C would seem
 like the optimum epicenter for propagation of this.


 I thought one of the major points of PHP is 'develop


> anywhere and deploy anywhere'.
>

>>>
>>> In the OP's case, where would C fit in when you have HTML, JS, and PHP
>>> - PHP would produce the resultant text in addtion to JS & HTML.  What
>>> would be the 'specific need' to do work in C where PHP, its many
>>> extensions and library (PECL & PEAR), and lots of the other PHP code
>>> based libraries/frameworks out there already to do the job?  The way I
>>> look at it, if too many languages are involved then most likely the
>>> application design is over complicated.
>>
>> Because you've been taught that C is over complicated in an
>> optimization standpoint. Just to spit out the above in html/php/js/css
>> in a C framework is simpler than you think. A little printf. And you
>> speak of optimization, but lack the prethought for implementation for
>> these optimizations.
>>
>> How can you move toward a lower level if you don't start on one. You
>> seem stuck on the PHP portion of this, rather than the whole outlook
>> of using multiple languages and technologies through a centralized
>> means to accomplish a specific end, which can be easily optimized.
>>
>
> I thought the whole objective of higher level language is to provide
> an easier application design and coding, in addition to shorter
> development & maintenance time.  Why go back to lower level, isn't
> that defeating the purpose?

That was the point of the term 'prototyping'. A language used to
prototype, but built on a framework of optimization, in which the
prototype language can be eliminated for the lower level performance
bottlenecks.

>
> Just a case scenario.  If C is included to 'to spit out the above in
> html/php/js/css' and should you happen to be out town/country on
> vacation, the other developer(s) doesn't know C and the application
> requires some minor bug fix or minor addition.  The problem is now
> that modification required is in C.

No, the problem lies in the error message, which lies in the
underlying language. And familiarity with work is in properly
commented and documented code. If the company isn't willing to
maintain that throughout the course of development, then your
misunderstanding is money out of their pocket.


  Do you want your vacation
> disturbed?

For money, I comment and document, but disturbed isn't a problem, as
long as it's a guaranteed under the contract.

Except in the case of an emergency, I don't. :)

But does the contract end at consumer misuse, or your discretion, and
do they decide, or you? And then when does that end, when you're too
important to respond, or had a better offer?

 Not to
> mention if where you're vacationing at have a fast internet
> connection, or even an internet connection at all.  While this
> approach may mean job stability in this situation, I could see it
> opposite as it causes more down time for the business as being unable
> to adapt quickly to the ever changing needs required by the economy
> and/or customers/clients.  In the end, if the business can't stay in
> business, you're out of a job.  In one of my recent job experience, I
> was in a 3 person IT team.  d

You mean you and a few guys/gals got together, and threw together an app?


We have a DBA, developer (also the
> manager), and I'm the sys

Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread Tommy Pham
We're going way off-topic.  Perhaps start a new thread? :)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread Tommy Pham
On Sat, Mar 12, 2011 at 12:06 AM, David Hutto  wrote:
> On Sat, Mar 12, 2011 at 2:59 AM, Tommy Pham  wrote:
>> On Fri, Mar 11, 2011 at 11:39 PM, David Hutto  wrote:
>>> On Sat, Mar 12, 2011 at 2:34 AM, Tommy Pham  wrote:
 On Fri, Mar 11, 2011 at 11:26 PM, David Hutto  wrote:
> On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
>> On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  
>> wrote:
>>> Although, right now, if I were going to be using all of those
>>> languages in unison(and I am), then I'd go with C, and spit them out
>>> to the browser for lower level control, as well as, to remain familiar
>>> with some of the main languages being used currently.
>>>
>>
>> But then how portable is your app?
>>
>
> I'd have to refer to your reply:
>
> "This would depend on the original application design & code."
>
> If the original app is meant for specific hardware, and a specific
> company, then portability is null point.
>

 If that's the case why even bother with PHP?  Why not just do it in C
 for pure speed?
>>>
>>> Speed wasn't the point- Multiple technology usage was the point. And
>>> if you're going to poise a browser for multiple intercepts(in terms of
>>> languages), then C *seems* to be the best was to move toward the
>>> displayment of it's descendants.
>>>
>>> If it's going to be a multi-language project, then it needs to be
>>> addressed with a multilanguage source to stem from, and C would seem
>>> like the optimum epicenter for propagation of this.
>>>
>>>
>>> I thought one of the major points of PHP is 'develop
>>>
>>>
 anywhere and deploy anywhere'.

>>>
>>
>> In the OP's case, where would C fit in when you have HTML, JS, and PHP
>> - PHP would produce the resultant text in addtion to JS & HTML.  What
>> would be the 'specific need' to do work in C where PHP, its many
>> extensions and library (PECL & PEAR), and lots of the other PHP code
>> based libraries/frameworks out there already to do the job?  The way I
>> look at it, if too many languages are involved then most likely the
>> application design is over complicated.
>
> Because you've been taught that C is over complicated in an
> optimization standpoint. Just to spit out the above in html/php/js/css
> in a C framework is simpler than you think. A little printf. And you
> speak of optimization, but lack the prethought for implementation for
> these optimizations.
>
> How can you move toward a lower level if you don't start on one. You
> seem stuck on the PHP portion of this, rather than the whole outlook
> of using multiple languages and technologies through a centralized
> means to accomplish a specific end, which can be easily optimized.
>

I thought the whole objective of higher level language is to provide
an easier application design and coding, in addition to shorter
development & maintenance time.  Why go back to lower level, isn't
that defeating the purpose?

Just a case scenario.  If C is included to 'to spit out the above in
html/php/js/css' and should you happen to be out town/country on
vacation, the other developer(s) doesn't know C and the application
requires some minor bug fix or minor addition.  The problem is now
that modification required is in C.  Do you want your vacation
disturbed?  Except in the case of an emergency, I don't. :)  Not to
mention if where you're vacationing at have a fast internet
connection, or even an internet connection at all.  While this
approach may mean job stability in this situation, I could see it
opposite as it causes more down time for the business as being unable
to adapt quickly to the ever changing needs required by the economy
and/or customers/clients.  In the end, if the business can't stay in
business, you're out of a job.  In one of my recent job experience, I
was in a 3 person IT team.  We have a DBA, developer (also the
manager), and I'm the system/network/telecom admin.  We all have cross
discipline experience and train ourselves in areas we lack for basic
support.  Every one of us don't have a problem taking a month vacation
out of the country when the other 2 to provide 24/7 support for the
facility.  Folks at other sites worries even if they try to take 2
weeks vacation and that's not even leaving country.  How fast and well
do you someone can be cross trained to learn C?  Even if just basic
support?

As for printf, PHP has that and print.  Regarding learning and using
C, I had only 1 quarter of it in college and that was back in the
early '90s.  I don't remember C as an 'over complicated in an
optimization standpoint', IIRC, I just had problems with memory
optimization, but that's another issue.  But I haven't used it since
other than scanning the some source code for compilations W(A/I)MP x64
stack.  About optimization, isn't it more in terms of modular design
then including more languages than is necessary?  If PHP is sluggish,
wouldn't be best to bring it up to the PHP develo

Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
This isn't a C/PHP question, or optimization, it's a matter of PHP
isn't always the center of attention, in terms of a development
process. In each language there are advocates, and it's admirable, but
ignorant in sight that what you're saying eliminates the rational, and
logical thought that there are other languages that can be utilized as
the center of development, and have higher level optimization in mind.

If you use C, then as optimization, and software evolution occurs, you
can move toward elimination the higher level prototyping languages,
and move it toward the C (lower level)implementation. You start with
just the spit out portion of C, and use the higher levels to
prototype...then remove the higher level as you eliminate the
inefficient portions, and replace with lower level, C,
implementations of these higher level/platform dependent prototyped
functions.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
On Sat, Mar 12, 2011 at 3:03 AM, Tommy Pham  wrote:
> On Fri, Mar 11, 2011 at 11:59 PM, David Hutto  wrote:
>> Optimization also becomes a more manipulative, due to the stem point
>> of your further language utilization. If you divide your languages,
>> and disperse them through a C framework, you can utilize the languages
>> in their refined form, and if any portion of an individual language
>> gives optimization problems, you move that particular segment toward a
>> more optimized C implementation.
>>
>
> Seems to me you're going in circle.  Portability is null.

Are you still stuck in developing for the masses? Because jobs are
limited there. Development for corps requires development for specific
hardware not a mass of consumers.


> Multi-language support and yet 'toward a more optimized C
> implementation'?

Did you forget the term "epicenter" of an app/site?

  Going back to my previous question then, 'what's the
> point of PHP' in all of this when you're trying to achieve an
> optimized C application?
>

PHP is just a portion of the ripple from C, which can got to php(e.g.
echo "html"), and then js in the html, and css in the html, but either
can be used in the html with interpolation of strings. Thhe C acts as
the pivot point, intertwining the languages above. You can use each
one individually. You could do this from a php
standpoint/python/html/etc. C becomes the root and the others just
branches and leaves woven together with %whatever.


-- 
According to theoretical physics, the division of spatial intervals as
the universe evolves gives rise to the fact that in another timeline,
your interdimensional counterpart received helpful advice from me...so
be eternally pleased for them.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
On Sat, Mar 12, 2011 at 2:59 AM, Tommy Pham  wrote:
> On Fri, Mar 11, 2011 at 11:39 PM, David Hutto  wrote:
>> On Sat, Mar 12, 2011 at 2:34 AM, Tommy Pham  wrote:
>>> On Fri, Mar 11, 2011 at 11:26 PM, David Hutto  wrote:
 On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
> On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  
> wrote:
>> Although, right now, if I were going to be using all of those
>> languages in unison(and I am), then I'd go with C, and spit them out
>> to the browser for lower level control, as well as, to remain familiar
>> with some of the main languages being used currently.
>>
>
> But then how portable is your app?
>

 I'd have to refer to your reply:

 "This would depend on the original application design & code."

 If the original app is meant for specific hardware, and a specific
 company, then portability is null point.

>>>
>>> If that's the case why even bother with PHP?  Why not just do it in C
>>> for pure speed?
>>
>> Speed wasn't the point- Multiple technology usage was the point. And
>> if you're going to poise a browser for multiple intercepts(in terms of
>> languages), then C *seems* to be the best was to move toward the
>> displayment of it's descendants.
>>
>> If it's going to be a multi-language project, then it needs to be
>> addressed with a multilanguage source to stem from, and C would seem
>> like the optimum epicenter for propagation of this.
>>
>>
>> I thought one of the major points of PHP is 'develop
>>
>>
>>> anywhere and deploy anywhere'.
>>>
>>
>
> In the OP's case, where would C fit in when you have HTML, JS, and PHP
> - PHP would produce the resultant text in addtion to JS & HTML.  What
> would be the 'specific need' to do work in C where PHP, its many
> extensions and library (PECL & PEAR), and lots of the other PHP code
> based libraries/frameworks out there already to do the job?  The way I
> look at it, if too many languages are involved then most likely the
> application design is over complicated.

Because you've been taught that C is over complicated in an
optimization standpoint. Just to spit out the above in html/php/js/css
in a C framework is simpler than you think. A little printf. And you
speak of optimization, but lack the prethought for implementation for
these optimizations.

How can you move toward a lower level if you don't start on one. You
seem stuck on the PHP portion of this, rather than the whole outlook
of using multiple languages and technologies through a centralized
means to accomplish a specific end, which can be easily optimized.


>
> SQL = back end data storage
> PHP = processing input/output, including back end data
> HTML/XML = document layout for nice hierarchical format
> JS/Flash = client side effects and processing to offload some server load
>
> Each already designed and made to do the the specific function and are
> nicely coupled together.  From the above, I've yet to see the need to
> write C code for the PHP based application - with the exception of
> threads, and let's not get into it again... lol.
>

It's not a 'hard coded' C, it's just a print to the page with C as the
conveyor for each. You can then utilize C to partition each language
for refinement in the overall.


-- 
According to theoretical physics, the division of spatial intervals as
the universe evolves gives rise to the fact that in another timeline,
your interdimensional counterpart received helpful advice from me...so
be eternally pleased for them.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread Tommy Pham
On Fri, Mar 11, 2011 at 11:59 PM, David Hutto  wrote:
> Optimization also becomes a more manipulative, due to the stem point
> of your further language utilization. If you divide your languages,
> and disperse them through a C framework, you can utilize the languages
> in their refined form, and if any portion of an individual language
> gives optimization problems, you move that particular segment toward a
> more optimized C implementation.
>

Seems to me you're going in circle.  Portability is null.
Multi-language support and yet 'toward a more optimized C
implementation'?  Going back to my previous question then, 'what's the
point of PHP' in all of this when you're trying to achieve an
optimized C application?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread David Hutto
Optimization also becomes a more manipulative, due to the stem point
of your further language utilization. If you divide your languages,
and disperse them through a C framework, you can utilize the languages
in their refined form, and if any portion of an individual language
gives optimization problems, you move that particular segment toward a
more optimized C implementation.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-12 Thread Tommy Pham
On Fri, Mar 11, 2011 at 11:39 PM, David Hutto  wrote:
> On Sat, Mar 12, 2011 at 2:34 AM, Tommy Pham  wrote:
>> On Fri, Mar 11, 2011 at 11:26 PM, David Hutto  wrote:
>>> On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
 On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  wrote:
> Although, right now, if I were going to be using all of those
> languages in unison(and I am), then I'd go with C, and spit them out
> to the browser for lower level control, as well as, to remain familiar
> with some of the main languages being used currently.
>

 But then how portable is your app?

>>>
>>> I'd have to refer to your reply:
>>>
>>> "This would depend on the original application design & code."
>>>
>>> If the original app is meant for specific hardware, and a specific
>>> company, then portability is null point.
>>>
>>
>> If that's the case why even bother with PHP?  Why not just do it in C
>> for pure speed?
>
> Speed wasn't the point- Multiple technology usage was the point. And
> if you're going to poise a browser for multiple intercepts(in terms of
> languages), then C *seems* to be the best was to move toward the
> displayment of it's descendants.
>
> If it's going to be a multi-language project, then it needs to be
> addressed with a multilanguage source to stem from, and C would seem
> like the optimum epicenter for propagation of this.
>
>
> I thought one of the major points of PHP is 'develop
>
>
>> anywhere and deploy anywhere'.
>>
>

In the OP's case, where would C fit in when you have HTML, JS, and PHP
- PHP would produce the resultant text in addtion to JS & HTML.  What
would be the 'specific need' to do work in C where PHP, its many
extensions and library (PECL & PEAR), and lots of the other PHP code
based libraries/frameworks out there already to do the job?  The way I
look at it, if too many languages are involved then most likely the
application design is over complicated.

SQL = back end data storage
PHP = processing input/output, including back end data
HTML/XML = document layout for nice hierarchical format
JS/Flash = client side effects and processing to offload some server load

Each already designed and made to do the the specific function and are
nicely coupled together.  From the above, I've yet to see the need to
write C code for the PHP based application - with the exception of
threads, and let's not get into it again... lol.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread David Hutto
On Sat, Mar 12, 2011 at 2:34 AM, Tommy Pham  wrote:
> On Fri, Mar 11, 2011 at 11:26 PM, David Hutto  wrote:
>> On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
>>> On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  wrote:
 Although, right now, if I were going to be using all of those
 languages in unison(and I am), then I'd go with C, and spit them out
 to the browser for lower level control, as well as, to remain familiar
 with some of the main languages being used currently.

>>>
>>> But then how portable is your app?
>>>
>>
>> I'd have to refer to your reply:
>>
>> "This would depend on the original application design & code."
>>
>> If the original app is meant for specific hardware, and a specific
>> company, then portability is null point.
>>
>
> If that's the case why even bother with PHP?  Why not just do it in C
> for pure speed?

Speed wasn't the point- Multiple technology usage was the point. And
if you're going to poise a browser for multiple intercepts(in terms of
languages), then C *seems* to be the best was to move toward the
displayment of it's descendants.

If it's going to be a multi-language project, then it needs to be
addressed with a multilanguage source to stem from, and C would seem
like the optimum epicenter for propagation of this.


I thought one of the major points of PHP is 'develop


> anywhere and deploy anywhere'.
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread Tommy Pham
On Fri, Mar 11, 2011 at 11:26 PM, David Hutto  wrote:
> On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
>> On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  wrote:
>>> Although, right now, if I were going to be using all of those
>>> languages in unison(and I am), then I'd go with C, and spit them out
>>> to the browser for lower level control, as well as, to remain familiar
>>> with some of the main languages being used currently.
>>>
>>
>> But then how portable is your app?
>>
>
> I'd have to refer to your reply:
>
> "This would depend on the original application design & code."
>
> If the original app is meant for specific hardware, and a specific
> company, then portability is null point.
>

If that's the case why even bother with PHP?  Why not just do it in C
for pure speed?  I thought one of the major points of PHP is 'develop
anywhere and deploy anywhere'.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread David Hutto
On Sat, Mar 12, 2011 at 2:22 AM, Tommy Pham  wrote:
> On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  wrote:
>> Although, right now, if I were going to be using all of those
>> languages in unison(and I am), then I'd go with C, and spit them out
>> to the browser for lower level control, as well as, to remain familiar
>> with some of the main languages being used currently.
>>
>
> But then how portable is your app?
>

I'd have to refer to your reply:

"This would depend on the original application design & code."

If the original app is meant for specific hardware, and a specific
company, then portability is null point.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread Tommy Pham
On Fri, Mar 11, 2011 at 10:34 PM, David Hutto  wrote:
> Although, right now, if I were going to be using all of those
> languages in unison(and I am), then I'd go with C, and spit them out
> to the browser for lower level control, as well as, to remain familiar
> with some of the main languages being used currently.
>

But then how portable is your app?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread Tommy Pham
On Fri, Mar 11, 2011 at 10:31 PM, David Hutto  wrote:
> On Sat, Mar 12, 2011 at 1:21 AM, Tommy Pham  wrote:
>> I think the OP is having both PHP & JS codes mixed and scattered all
>> over the page.  If chunked-encoding used without any ob*
>> implementation, then that's the problem he'll experience.
>>
>> Richard,
>>
>> I recommend to put the $(document).ready() and any JS scriptlets
>> within  tags at the very bottom of the HTML document just
>> right before .  This would allow the mixed PHP/HTML to finish
>> without creating problems for your JS code(s).
>
> Why not separate them all, i.e. js, php, html, and if it was in there,
> css. If you can use them all, then separating them out should be
> *easy*(I still would have to use references for that many languages).
> Think of it as an expository writing, with the includes being the main
> topics, the content being composed of these higher ideas, and the
> conclusion, just closing it out.
>
> Pick the focus, I'd say php, and echo the rest out. Or html, and
> include the php, css and js.
>

This would depend on the original application design & code.  The
solution you're proposing is ideal which, for the most part, would
probably require the app redesign/rewrite.  However, if Richard isn't
one of the originator(s) of the app's developers or he's only
experiencing the problem on a very few limited pages, moving the JS
codes to the bottom would be a faster fix.  In the end, it all depends
on his environment and immediate need.

>
>
>  The other solution is
>> implement output buffer using ob* functions.
>>
>> Regards,
>> Tommy
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
> According to theoretical physics, the division of spatial intervals as
> the universe evolves gives rise to the fact that in another timeline,
> your interdimensional counterpart received helpful advice from me...so
> be eternally pleased for them.
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread David Hutto
On Sat, Mar 12, 2011 at 1:21 AM, Tommy Pham  wrote:
> I think the OP is having both PHP & JS codes mixed and scattered all
> over the page.  If chunked-encoding used without any ob*
> implementation, then that's the problem he'll experience.
>
> Richard,
>
> I recommend to put the $(document).ready() and any JS scriptlets
> within  tags at the very bottom of the HTML document just
> right before .  This would allow the mixed PHP/HTML to finish
> without creating problems for your JS code(s).

Why not separate them all, i.e. js, php, html, and if it was in there,
css. If you can use them all, then separating them out should be
*easy*(I still would have to use references for that many languages).
Think of it as an expository writing, with the includes being the main
topics, the content being composed of these higher ideas, and the
conclusion, just closing it out.

Pick the focus, I'd say php, and echo the rest out. Or html, and
include the php, css and js.



 The other solution is
> implement output buffer using ob* functions.
>
> Regards,
> Tommy
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
According to theoretical physics, the division of spatial intervals as
the universe evolves gives rise to the fact that in another timeline,
your interdimensional counterpart received helpful advice from me...so
be eternally pleased for them.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread David Hutto
Although, right now, if I were going to be using all of those
languages in unison(and I am), then I'd go with C, and spit them out
to the browser for lower level control, as well as, to remain familiar
with some of the main languages being used currently.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-11 Thread Tommy Pham
I think the OP is having both PHP & JS codes mixed and scattered all
over the page.  If chunked-encoding used without any ob*
implementation, then that's the problem he'll experience.

Richard,

I recommend to put the $(document).ready() and any JS scriptlets
within  tags at the very bottom of the HTML document just
right before .  This would allow the mixed PHP/HTML to finish
without creating problems for your JS code(s).  The other solution is
implement output buffer using ob* functions.

Regards,
Tommy

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-06 Thread Ellis Antaya
Also, the $(document).ready() is triggered when the DOM is ready to be
manipulated.
I dont know why you would consider alter the behavior of this event, maybe
what you want is to create yourself a custom event handler ...

On Sun, Mar 6, 2011 at 21:43, Ellis Antaya  wrote:

> i'm not sure i understand your problem ?!?
>
> php runs on the server, delivers html code and/or javascript to the browser
> and only from there the jQuery will execute it's main loop and start trigger
> some events such as the ready event.  So the php script is always finish
> when javascript start to execute ...
>
>
> On Fri, Mar 4, 2011 at 12:18, Nathan Rixham  wrote:
>
>> Richard Sharp wrote:
>>
>>> I have been banging my head trying to figure out how to delay
>>> $(document).ready() command until my php script finish running and load
>>> data into a csv file.  Any ideas
>>>
>>
>> *which* PHP script? are you returning an HTML document then keeping the
>> script going in the background, /or/ are you requesting another script (by
>> js, clicking a link, posting a form), /or/?
>>
>> I know it's a jQuery question, but it might be a PHP related gotcha.
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> Ellis
> 110010100001
>
> twitter.com/floverdevel
> facebook.com/ellis.antaya
> google.com/profiles/ellis.antaya
> linkedin.com/in/ellisantaya
>
>


-- 
Ellis
110010100001

twitter.com/floverdevel
facebook.com/ellis.antaya
google.com/profiles/ellis.antaya
linkedin.com/in/ellisantaya


Re: [PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-06 Thread Ellis Antaya
i'm not sure i understand your problem ?!?

php runs on the server, delivers html code and/or javascript to the browser
and only from there the jQuery will execute it's main loop and start trigger
some events such as the ready event.  So the php script is always finish
when javascript start to execute ...


On Fri, Mar 4, 2011 at 12:18, Nathan Rixham  wrote:

> Richard Sharp wrote:
>
>> I have been banging my head trying to figure out how to delay
>> $(document).ready() command until my php script finish running and load
>> data into a csv file.  Any ideas
>>
>
> *which* PHP script? are you returning an HTML document then keeping the
> script going in the background, /or/ are you requesting another script (by
> js, clicking a link, posting a form), /or/?
>
> I know it's a jQuery question, but it might be a PHP related gotcha.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Ellis
110010100001

twitter.com/floverdevel
facebook.com/ellis.antaya
google.com/profiles/ellis.antaya
linkedin.com/in/ellisantaya


[PHP] Re: Delaying $(document).ready() in jQuery until php script finish

2011-03-04 Thread Nathan Rixham

Richard Sharp wrote:

I have been banging my head trying to figure out how to delay
$(document).ready() command until my php script finish running and load
data into a csv file.  Any ideas


*which* PHP script? are you returning an HTML document then keeping the 
script going in the background, /or/ are you requesting another script 
(by js, clicking a link, posting a form), /or/?


I know it's a jQuery question, but it might be a PHP related gotcha.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php