php-general Digest 14 Sep 2011 21:03:15 -0000 Issue 7478
Topics (messages 314835 through 314857):
Re: What would you like to see in most in a text editor?
314835 by: Johan Lidström
314839 by: Richard Quadling
314840 by: Tim Streater
314841 by: Brad Huskins
314843 by: Richard Quadling
314847 by: Jim Giner
314850 by: Paul M Foster
314851 by: tamouse mailing lists
314852 by: tamouse mailing lists
314856 by: Tim Streater
Re: Stop PHP execution on client connection closed
314836 by: Marco Lanzotti
314848 by: Jim Lucas
314849 by: Marco Lanzotti
314853 by: Alex Nikitin
Re: Querying a database for 50 users' information: 50 queries or a WHERE array?
314837 by: Dotan Cohen
314838 by: Dotan Cohen
314842 by: Eric Butera
314854 by: Alex Nikitin
314857 by: Dotan Cohen
Sort problem
314844 by: Igor Escobar
314845 by: Marc Guay
314846 by: Igor Escobar
Re: Repetitive answers . . .
314855 by: Govinda
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On 13 September 2011 21:56, Brad Huskins <[email protected]> wrote:
> Hello all you php coders out there,
>
> I'm doing an Open Source text editor (just a hobby) that's designed for PHP
> developers and is accessible through the web. This has been stewing for a
> while, and has gotten to the point where I can use it for my own work. I
> would like any feedback on things that people really like/dislike about
> their current editors, as I believe some of these things could be resolved
> in mine.
>
> I currently have username/password protection (with Salted-Hash passwords),
> a file-system browser, file loading/saving, and syntax highlighting -- and
> these things seem to work reasonably well. As well, most things about the
> editor are scriptable with JavaScript. This would seem to imply that in a
> few weeks I would have something useful. So I would like to get some
> feedback on what features people would most want, since I am still at a very
> flexible stage in development.
>
> If you would like to see what I have, you can go to un1tware.wordpress.com.
> You can also peruse the code at github.com/bhus/scriptr. In particular,
> the README on github gives a little bit better rationality for why something
> like this might be useful, and how things are currently structured.
>
> --Brad
>
> [ Yes, this is based on the layout of Linus' original post to
> comp.os.minix. ]
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Refactoring (that is, changing the name or arguments of variables or
functions and have all references to that variable or function
changed accordingly) would be nice to see in an online editor. ^_^
--
"It is not possible to simultaneously understand and appreciate the Intel
architecture" --Ben Scott
--- End Message ---
--- Begin Message ---
On 14 September 2011 01:23, tamouse mailing lists
<[email protected]> wrote:
> On Tue, Sep 13, 2011 at 3:35 PM, Robert Cummings <[email protected]> wrote:
>> I'm a big fan of editors that work in the terminal.
>
> You'll get my emacs when you pry it out of my cold dead hands.
Pah! You and your full screen editor.
EDLIN is the way to go.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--- End Message ---
--- Begin Message ---
On 14 Sep 2011 at 12:40, Richard Quadling <[email protected]> wrote:
> On 14 September 2011 01:23, tamouse mailing lists
> <[email protected]> wrote:
>> On Tue, Sep 13, 2011 at 3:35 PM, Robert Cummings <[email protected]>
>> wrote:
>>> I'm a big fan of editors that work in the terminal.
>>
>> You'll get my emacs when you pry it out of my cold dead hands.
>
> Pah! You and your full screen editor.
>
> EDLIN is the way to go.
Is that more or less terse than TECO?
Back in 1989 when I was at SLAC, they were just getting into unix, and debates
were raging about which editor to standardise on and teach people (emacs, vi,
jove, etc). Because this wasn't settled, I started using notepad (and later,
dxnotepad) and got on with coding. Six months later, the debates were still
raging. I then had an epiphany: I'd been using notepad for six moths & got work
done. It took me 5 minutes to find out how to use it. I didn't need teaching
about it or to have a manual. So IMO, emacs, vi, and all their ilk belong in
the dustbin of history.
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
Thanks Tim.
That is some very useful feedback.
I am aiming to build something that is almost as easy to use as Notepad.
Don't know if I'll be successful or not, but nice to know people value
simplicity.
--Brad.
On 09/14/2011 08:18 AM, Tim Streater wrote:
On 14 Sep 2011 at 12:40, Richard Quadling<[email protected]> wrote:
On 14 September 2011 01:23, tamouse mailing lists
<[email protected]> wrote:
On Tue, Sep 13, 2011 at 3:35 PM, Robert Cummings<[email protected]>
wrote:
I'm a big fan of editors that work in the terminal.
You'll get my emacs when you pry it out of my cold dead hands.
Pah! You and your full screen editor.
EDLIN is the way to go.
Is that more or less terse than TECO?
Back in 1989 when I was at SLAC, they were just getting into unix, and debates were
raging about which editor to standardise on and teach people (emacs, vi, jove,
etc). Because this wasn't settled, I started using notepad (and later, dxnotepad)
and got on with coding. Six months later, the debates were still raging. I then had
an epiphany: I'd been using notepad for six moths& got work done. It took me 5
minutes to find out how to use it. I didn't need teaching about it or to have a
manual. So IMO, emacs, vi, and all their ilk belong in the dustbin of history.
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
On 14 September 2011 13:18, Tim Streater <[email protected]> wrote:
> On 14 Sep 2011 at 12:40, Richard Quadling <[email protected]> wrote:
>
>> On 14 September 2011 01:23, tamouse mailing lists
>> <[email protected]> wrote:
>>> On Tue, Sep 13, 2011 at 3:35 PM, Robert Cummings <[email protected]>
>>> wrote:
>>>> I'm a big fan of editors that work in the terminal.
>>>
>>> You'll get my emacs when you pry it out of my cold dead hands.
>>
>> Pah! You and your full screen editor.
>>
>> EDLIN is the way to go.
>
> Is that more or less terse than TECO?
>
> Back in 1989 when I was at SLAC, they were just getting into unix, and
> debates were raging about which editor to standardise on and teach people
> (emacs, vi, jove, etc). Because this wasn't settled, I started using notepad
> (and later, dxnotepad) and got on with coding. Six months later, the debates
> were still raging. I then had an epiphany: I'd been using notepad for six
> moths & got work done. It took me 5 minutes to find out how to use it. I
> didn't need teaching about it or to have a manual. So IMO, emacs, vi, and all
> their ilk belong in the dustbin of history.
>
> --
> Cheers -- Tim
>
TECO - OUCH.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--- End Message ---
--- Begin Message ---
But why?
"Brad Huskins" <[email protected]> wrote in message
news:[email protected]...
>
> I am aiming to build something that is almost as easy to use as Notepad.
>
--- End Message ---
--- Begin Message ---
On Wed, Sep 14, 2011 at 01:18:00PM +0100, Tim Streater wrote:
> On 14 Sep 2011 at 12:40, Richard Quadling <[email protected]> wrote:
> > On 14 September 2011 01:23, tamouse mailing lists
> > <[email protected]> wrote:
> >> On Tue, Sep 13, 2011 at 3:35 PM, Robert Cummings
> >> <[email protected]>
wrote:
> >>> I'm a big fan of editors that work in the terminal.
> >>
You'll get my emacs when you pry it out of my cold dead hands.
> >
Pah! You and your full screen editor.
EDLIN is the way to go.
>
Is that more or less terse than TECO?
Back in 1989 when I was
> at SLAC, they were just getting into unix, and debates were raging
> about which editor to standardise on and teach people (emacs, vi,
> jove, etc). Because this wasn't settled, I started using notepad (and
> later, dxnotepad) and got on with coding. Six months later, the
> debates were still raging. I then had an epiphany: I'd been using
> notepad for six moths & got work done. It took me 5 minutes to find
> out how to use it. I didn't need teaching about it or to have a
> manual. So IMO, emacs, vi, and all their ilk belong in the dustbin of
> history.
--
Cheers -- Tim
>
I agree with you for the most part. I used to use Nano for this reason,
which tends to be available on any given system. But sometimes Nano
isn't available and/or is difficult to find/install. It offers very
little flexibility and, as far as I know, no capability to do add-ons.
It also doesn't do syntax highlighting, as far as I know.
I resisted Emacs because I'd have arthritis in short order from having
to deal with the plethora of control and alt keystrokes which don't make
mnemonic sense to me. Plus, it can be a massive.
Eventually I switched to Vim (counter-intuitively) because 1) there's no
*unix variant on which it's not available; 2) at some point, you're
probably going to *have* to know how to operate Vi if you move around
among foreign machines and networks; 3) there are many other
applications which use many of the same keystroke patterns which are
fundamental to Vi; 4) most keystroke combinations do not require leaving
the home row, etc.; 5) Vi easily does syntax hilighting and a variety of
other things, depending on add-ons.
The "modal" model of Vi/Vim is sometimes a pain in the ass. And yes, it
can take a long time to know all the features of Vim. But there are a
number of things I can do faster in Vim, than anyone else can do in
other editors, with less effort.
No attempt here to dissuade Emacers or others. Whatever floats your boat
and you're happy with, continue using. Why should you or I care what
someone else uses for an editor?
BTW, my big beef with "online" editors is latency, and it's a *huge*
problem, as far as I'm concerned. Ultimately this is why I wrote blog
software for myself which requires you to compose and edit your posts
locally, and then *upload* them to the blog. That, and the silly idea
that one should store huge masses of text in relation databases; large
masses of text should be stored as what they are-- flat files.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
On Tue, Sep 13, 2011 at 7:56 PM, James Yerge <[email protected]> wrote:
> I'd have to go agree with the exception of s/emacs/vi/ :P
invoke(EditorChoiceReligiousArgument);
--- End Message ---
--- Begin Message ---
On Wed, Sep 14, 2011 at 11:52 AM, Paul M Foster <[email protected]> wrote:
> BTW, my big beef with "online" editors is latency, and it's a *huge*
> problem, as far as I'm concerned. Ultimately this is why I wrote blog
> software for myself which requires you to compose and edit your posts
> locally, and then *upload* them to the blog. That, and the silly idea
> that one should store huge masses of text in relation databases; large
> masses of text should be stored as what they are-- flat files.
^^This.
This is my hugest complaint about using Google Docs. I seem to suffer
from lag a lot, despite having a high speed cable connection. Concerns
about losing work, losing control, losing access, etc.
I don't think I'd like it very much if didn't have the possibility of
working on code and text files while I was not connected to a network.
--- End Message ---
--- Begin Message ---
On 14 Sep 2011 at 17:52, Paul M Foster <[email protected]> wrote:
> Eventually I switched to Vim (counter-intuitively) because 1) there's no
> *unix variant on which it's not available; 2) at some point, you're
> probably going to *have* to know how to operate Vi if you move around
> among foreign machines and networks
Yes, this is entirely valid IMO. I still have my ultrix vi summary card for
such occasions.
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
Il 13/09/2011 20:58, Alex Nikitin ha scritto:
> Correction on Marco's post. You can absolutely stop a mysql query
I know I can stop a query, but I don't know how to realize HTTP client
has closed connection during query execution.
My query count how many records match selected fields in a 50M records
table.
Any query field is indexed and innodb uses 20GB of RAM to store data and
indexes, but some queries take about 30 seconds to run.
When user changes filters and asks for a new count, the old queries
continue to run using DB resurces unnecessarily.
Bye,
Marco
--- End Message ---
--- Begin Message ---
On 9/14/2011 1:04 AM, Marco Lanzotti wrote:
> Il 13/09/2011 20:58, Alex Nikitin ha scritto:
>> Correction on Marco's post. You can absolutely stop a mysql query
>
> I know I can stop a query, but I don't know how to realize HTTP client
> has closed connection during query execution.
>
> My query count how many records match selected fields in a 50M records
> table.
> Any query field is indexed and innodb uses 20GB of RAM to store data and
> indexes, but some queries take about 30 seconds to run.
> When user changes filters and asks for a new count, the old queries
> continue to run using DB resurces unnecessarily.
>
> Bye,
> Marco
Well, from the sounds of that, you really do not have an easy option.
Here is my suggestion.
In your initial script, you could add a unique value to your SQL statement.
You SQL would be something like...
SELECT ... FROM ... WHERE ... AND (1=1 OR 'unique value');
add 'unique value' to your session data and then, when the person changes the
selected fields and starts to execute another query, first, you could search to
see if an SQL statement is running that has your unique value in it. if it
cannot find a matching statement, simply execute the SQL query. If it does find
an SQL statement that matches the unique value, kill it, then issue your SQL
statement.
Read the following to figure out how to find your unique process:
http://dev.mysql.com/doc/refman/5.0/en/show-processlist.html
Read the following to find out how to kill your processes:
http://dev.mysql.com/doc/refman/5.0/en/kill.html
But, it does seem like it would be possible.
--- End Message ---
--- Begin Message ---
Il 14/09/2011 17:35, Jim Lucas ha scritto:
>
> SELECT ... FROM ... WHERE ... AND (1=1 OR 'unique value');
>
> add 'unique value' to your session data and then, when the person changes the
> selected fields and starts to execute another query, first, you could search
> to
> see if an SQL statement is running that has your unique value in it.
Not so clean, but it could work!
Thank you,
Marco
--- End Message ---
--- Begin Message ---
On Wed, Sep 14, 2011 at 4:04 AM, Marco Lanzotti <[email protected]> wrote:
> Il 13/09/2011 20:58, Alex Nikitin ha scritto:
> > Correction on Marco's post. You can absolutely stop a mysql query
>
> I know I can stop a query, but I don't know how to realize HTTP client
> has closed connection during query execution.
>
> My query count how many records match selected fields in a 50M records
> table.
> Any query field is indexed and innodb uses 20GB of RAM to store data and
> indexes, but some queries take about 30 seconds to run.
> When user changes filters and asks for a new count, the old queries
> continue to run using DB resurces unnecessarily.
>
> Bye,
> Marco
>
Marco,
I ran queries on a table that had 12M rows added to it each month with a
year+ worth of data going back, pulling 80-90 thousand records with over a
dozen columns on an older dual dual core box with 8gb ram (so 6 for MySQL)
joining multiple tables for various criteria, matching on various values
with query execution in a second range (depending on load, from under a
second, to under 2 seconds). I think, and i am not trying to sound like
pompous buffoon or to put anyone down or say that you or anyone here don't
know what they are talking about or anything like that, but i think that you
should first look into how you can optimize your database and your query, as
well as maybe the access to this information (volume of information that you
are presenting vs getting, also how you filter it, etc).
Sometimes it's a very simple thing that can make or brake query execution
time, and it's not immediately apparent. I was once tasked to fix a process
in which about 2-300 queries were ran against the database in periodic ajax
calls, they took about a 1/4 second to execute for each query. This ofcourse
means that the refresh took almost a minute to run, which was getting very
annoying, so i glimpsed over the queries and the tables at hand and 5
minutes later issued 2 queries, one to delete a useless index that was
created for the main table, and another to create a new index on the
database that reduced the execution time of those queries from 1/4 sec for
each to 1.4 or 1.6 sec for all 2-300. And most of that time was actually
caused by the network lag for the 2-300 queries, since they were
individually executed from php, i wanted to reduce that whole thing to one
query, but wasn't allowed to. Other times its a lot more complex, and
sometimes blowing a query up from something simple or straight forward to
something more complex can wield similar increases in performance, this
ofcourse has to be with thorough understanding of how the database works.
Perhaps if I, or we can understand your application a little better, we
could suggest better solutions, just remember that you are not the first
person to have to solve these similar issues. I can help you if you want,
glimpse over your database design and queries for a fresh look, i have
fairly extensive php (and many other languages) programming experience, as
well as database design and administration, system development and
administration, optimization, security, caching (many other things, that
don't directly pertain to this) though we should probably keep it off the
list.
- Alex
--
The trouble with programmers is that you can never tell what a programmer is
doing until it’s too late. ~Seymour Cray
--- End Message ---
--- Begin Message ---
On Tue, Sep 13, 2011 at 23:04, Alex Nikitin <[email protected]> wrote:
> Dotan,
>
> IN (the function used in all of the queries above) is not the same as an
> INNER_JOIN, inner join joins 2 tables, as you have already described, IN
> however is a function that return 1 if the value being searched for is in
> the array of its values or 0 if it is not, thus IN is not an inner join, but
> a comparator function, thus if you are using IN, limit will indeed be more
> efficient than it's omission for exactly the reason i have stated in my
> previous post. Because your user array seems to be in php, and implode has
> been a topic of discussion above as well, setting an adequate limit is a
> simple task with the php's count function.
>
Yes, I did realize that after seeing the syntax of IN, which I have
not been exposed to before. My response that you quoted was in
response to a suggestion that a LIMIT clause be used with an INNER
JOIN query, which is wrong on two principles.
> This is all ofcourse void if the user array being pulled from mysql, in
> which case you could simply join the two tables to get your resulting data
> set. The trick there is to use the USING clause which seems to run a lot
> faster than any ON clause, or work on an optimized subselect, especially if
> you are running a cluster.
>
Agreed. In fact I don't know from where the array is coming, that's
not my part of the code! But I agree that if it is coming from mysql
then a join would be preferable.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
On Wed, Sep 14, 2011 at 06:05, chetan rane <[email protected]> wrote:
> Hi,
>
> There are 2 peoblems with subselect
>
> 1. You cant use a limit on the nested select
> 2. Id the number of elements in the in clause exceeds the subselect buffer
> you will run into performance issues ans eventually you query will be
> doomed. Inner joins in,this is the best option for this . You can use a temp
> table for this
>
Thanks Chetan. I will keep that in mind if I ever get around to
learning about subselects.
Have a great day!
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
On Wed, Sep 14, 2011 at 4:12 AM, Dotan Cohen <[email protected]> wrote:
> On Wed, Sep 14, 2011 at 06:05, chetan rane <[email protected]> wrote:
>> Hi,
>>
>> There are 2 peoblems with subselect
>>
>> 1. You cant use a limit on the nested select
>> 2. Id the number of elements in the in clause exceeds the subselect buffer
>> you will run into performance issues ans eventually you query will be
>> doomed. Inner joins in,this is the best option for this . You can use a temp
>> table for this
>>
>
> Thanks Chetan. I will keep that in mind if I ever get around to
> learning about subselects.
>
> Have a great day!
>
> --
> Dotan Cohen
>
> http://gibberish.co.il
> http://what-is-what.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Just out of curiosity, where are these ids coming from? Doing a raw
implode on them like that is a sql injection vuln.
--- End Message ---
--- Begin Message ---
You can use a limit with a nested select, you just can't use it in
some cases, like inside an "IN" statement, but something like this
should work:
SELECT id, data, etc FROM table JOIN (SELECT special_id as id FROM
special_table ORDER BY special_id LIMIT 0, 1000) AS table2 USING (id)
Note: syntax may not be valid, but should be fairly straight forward
to fix, have no time to play with it though...
--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late. ~Seymour Cray
On Wed, Sep 14, 2011 at 4:12 AM, Dotan Cohen <[email protected]> wrote:
>
> On Wed, Sep 14, 2011 at 06:05, chetan rane <[email protected]> wrote:
> > Hi,
> >
> > There are 2 peoblems with subselect
> >
> > 1. You cant use a limit on the nested select
> > 2. Id the number of elements in the in clause exceeds the subselect buffer
> > you will run into performance issues ans eventually you query will be
> > doomed. Inner joins in,this is the best option for this . You can use a temp
> > table for this
> >
>
> Thanks Chetan. I will keep that in mind if I ever get around to
> learning about subselects.
>
> Have a great day!
>
> --
> Dotan Cohen
>
> http://gibberish.co.il
> http://what-is-what.com
--- End Message ---
--- Begin Message ---
On Wed, Sep 14, 2011 at 16:02, Eric Butera <[email protected]> wrote:
> Just out of curiosity, where are these ids coming from? Doing a raw
> implode on them like that is a sql injection vuln.
>
They are in an array. I do of course is_int() them first, plus some
other sanitation including mysql_real_escape_string().
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
Hi Folks!
Anyone know a smart way to order file names?
An example to you guys picture what im saying is:
<?php
$serie[] = "Two And Half Man Season 1";
$serie[] = "Two And Half Man Season 4";
$serie[] = "Two And Half Man Season 2";
$serie[] = "Two And Half Man Season 3";
$serie[] = "Two And Half Man Season 10";
$serie[] = "Two And Half Man Season 9";
sort($serie);
print_r($serie);
?>
The result of this snippet is:
Array
(
[0] => Two And Half Man Season 1 [1] => Two And Half Man Season
10 [2] => Two And Half Man Season 2
[3] => Two And Half Man Season 3
[4] => Two And Half Man Season 4
[5] => Two And Half Man Season 9
)
Anyone knows how to solve this problem?
Regards,
Igor Escobar
*Software Engineer
*
+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar <http://www.twitter.com/igorescobar>
--- End Message ---
--- Begin Message ---
> Anyone know a smart way to order file names?
Nope, but I know a "natural" way:
http://ca.php.net/manual/en/function.natsort.php
--- End Message ---
--- Begin Message ---
Wow!
Thank you! I completely forgot this method!
Regards,
Igor Escobar
*Software Engineer
*
+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar <http://www.twitter.com/igorescobar>
On Wed, Sep 14, 2011 at 12:02 PM, Marc Guay <[email protected]> wrote:
> > Anyone know a smart way to order file names?
>
> Nope, but I know a "natural" way:
> http://ca.php.net/manual/en/function.natsort.php
>
--- End Message ---
--- Begin Message ---
> As for duplicate answers...,
> [snip]
Also newbies may tend to like the multiples answers.. for the different
perspectives, as Dan said, but also when they are exact dupe answers - because
then the newbie knows the answer is definitive.. and then stops asking the
list.. and starts doing what work is called for.
-Govinda
--- End Message ---
