Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.advocacy > #350996 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2016-04-20 11:37 -0400 |
| Last post | 2016-04-28 05:46 -0400 |
| Articles | 20 on this page of 140 — 16 participants |
Back to article view | Back to comp.os.linux.advocacy
A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-20 11:37 -0400
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-20 08:45 -0700
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-20 11:57 -0400
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-20 09:02 -0700
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-21 01:54 +0000
Re: A maybe interesting code challenge Steve Carroll <fretwizzen@gmail.com> - 2016-04-20 18:57 -0700
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-21 02:45 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-20 23:01 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-21 03:56 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-21 11:06 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-21 16:13 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-21 17:27 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-22 19:07 +0000
Re: A maybe interesting code challenge Steve Carroll <fretwizzen@gmail.com> - 2016-04-20 19:01 -0700
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-22 09:37 +0000
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-22 08:33 -0400
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-22 22:03 +0000
Re: A maybe interesting code challenge Richard King <kingsley651@webby.org> - 2016-04-22 18:22 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-22 19:48 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-22 17:24 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-22 22:18 +0000
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-22 22:26 +0000
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-22 22:43 +0000
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-22 22:50 +0000
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-22 22:57 +0000
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-23 13:07 +0000
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-23 09:58 -0400
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-22 21:48 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-22 17:00 -0400
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-22 21:56 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-22 19:39 -0400
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-23 15:25 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-23 13:14 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-23 18:37 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-23 16:50 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-23 21:15 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-23 18:36 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-23 23:24 +0000
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-22 08:21 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-22 10:04 -0400
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-23 00:09 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-23 00:18 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-23 05:59 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-26 12:46 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-26 19:04 +0000
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-26 20:40 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-26 17:48 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-26 22:14 +0000
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-23 23:15 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-23 23:30 -0400
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-24 08:52 -0400
Re: A maybe interesting code challenge Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-04-24 10:06 -0400
Re: A maybe interesting code challenge Fabian Russell <fb@zen.info> - 2016-04-24 15:59 +0000
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-24 15:45 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-25 10:19 -0400
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-25 20:26 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-25 23:24 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-26 05:03 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-26 11:40 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-25 15:14 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-25 12:05 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-25 18:06 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-26 12:41 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-26 18:03 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-26 17:39 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-27 05:50 +0000
Re: A maybe interesting code challenge chrisv <chrisv@nospam.invalid> - 2016-04-27 06:43 -0500
Re: A maybe interesting code challenge William Poaster <wp@dev.null> - 2016-04-27 13:11 +0100
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-27 13:32 +0000
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-27 07:32 -0700
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-27 15:02 +0000
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-27 08:17 -0700
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-27 16:21 +0000
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-27 09:42 -0700
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-27 21:39 +0000
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-27 23:25 +0000
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-28 05:34 +0000
Re: A maybe interesting code challenge vallor <vallor@cultnix.org> - 2016-04-28 05:37 +0000
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-28 05:42 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-27 11:45 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-27 16:23 +0000
Re: A maybe interesting code challenge Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-27 18:40 +0200
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-27 09:58 -0700
Re: A maybe interesting code challenge Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-27 20:57 +0200
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-27 12:06 -0700
Re: A maybe interesting code challenge Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-04-27 22:44 +0200
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-27 13:38 -0400
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-27 11:07 -0700
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-27 15:51 -0400
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-27 13:30 -0700
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-27 21:38 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-28 11:33 -0400
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-28 09:14 -0700
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-28 14:17 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-28 18:49 +0000
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-29 08:42 -0700
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-29 13:42 -0400
Re: A maybe interesting code challenge Snit <usenet@gallopinginsanity.com> - 2016-04-29 10:54 -0700
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-29 11:20 -0700
Re: Snit digest 214 / 2016-04-29 Melzzzzz <mel@zzzzz.com> - 2016-04-30 00:31 +0200
Re: Snit digest 214 / 2016-04-29 DFS <nospam@dfs.com> - 2016-04-29 19:00 -0400
Re: Snit digest 214 / 2016-04-29 DFS <nospam@dfs.com> - 2016-04-30 10:36 -0400
Re: Snit digest 214 / 2016-04-29 chrisv <chrisv@nospam.invalid> - 2016-05-02 07:54 -0500
Re: Snit digest 214 / 2016-04-29 Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-05-02 15:55 +0200
Re: Snit digest 214 / 2016-04-29 Snit <usenet@gallopinginsanity.com> - 2016-05-02 07:23 -0700
Snit digest 215 / 2016-05-02 Sandman <mr@sandman.net> - 2016-05-02 14:39 +0000
Re: Snit digest 215 / 2016-05-02 Snit <usenet@gallopinginsanity.com> - 2016-05-02 07:54 -0700
Re: Snit digest 214 / 2016-04-29 Sandman <mr@sandman.net> - 2016-05-02 14:36 +0000
Re: Snit digest 214 / 2016-04-29 Snit <usenet@gallopinginsanity.com> - 2016-05-02 07:53 -0700
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-29 11:11 -0700
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-29 14:44 -0700
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-29 17:53 -0400
Re: A maybe interesting code challenge Melzzzzz <mel@zzzzz.com> - 2016-04-29 23:56 +0200
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-29 18:09 -0400
Re: A maybe interesting code challenge Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-04-29 19:09 -0400
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-30 07:31 -0700
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-05-01 08:21 +0000
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-05-01 08:47 -0700
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-05-02 14:54 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-05-02 21:54 -0400
Re: A maybe interesting code challenge GreyCloud <mist@cumulus.com> - 2016-04-28 15:39 -0600
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-29 08:48 -0700
Re: A maybe interesting code challenge GreyCloud <mist@cumulus.com> - 2016-04-29 16:57 -0600
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-27 21:33 -0400
Re: A maybe interesting code challenge Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-04-28 05:45 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-27 21:32 +0000
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-27 21:48 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-27 22:57 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-28 05:44 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-29 16:32 -0400
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-27 23:05 -0400
Re: A maybe interesting code challenge owl <owl@rooftop.invalid> - 2016-04-28 03:20 +0000
Re: A maybe interesting code challenge DFS <nospam@dfs.com> - 2016-04-28 09:52 -0400
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-29 02:46 -0400
Re: A maybe interesting code challenge Steve Carroll <fretwizzer@gmail.com> - 2016-04-29 08:33 -0700
Re: A maybe interesting code challenge Norman Peelman <npeelman@cfl.rr.com> - 2016-04-30 09:31 -0400
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-28 05:42 +0000
Re: A maybe interesting code challenge vallor <vallor@cultnix.org> - 2016-04-28 06:17 +0000
Re: A maybe interesting code challenge Sandman <mr@sandman.net> - 2016-04-28 06:56 +0000
Re: A maybe interesting code challenge Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-04-28 05:46 -0400
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2016-04-25 12:05 -0400 |
| Message-ID | <nflf1s$4s4$1@dont-email.me> |
| In reply to | #351768 |
On 4/25/2016 11:14 AM, Sandman wrote:
> In article <nf87hq$ndh$1@dont-email.me>, DFS wrote:
>
>> Parse a search string composed of 1, 2 or 3 parts, separated by a
>> semicolon, into 2, 4 or 6 variables (field1, value1, etc)
>
>> use 1 part : state=GA
>> use 2 parts: state=GA ; name = Burger King
>> use 3 parts: state=GA ; name = Burger King ; zip like 303*
>
>> The goal is to split it up like this:
>
>> var field1 = 'state'
>> var value1 = 'GA'
>> other vars empty
>
>> var field1 = 'state'
>> var value1 = 'GA'
>> var field2 = 'name'
>> var value2 = 'Burger King'
>> other vars empty
>
>> var field1 = 'state'
>> var value1 = 'GA'
>> var field2 = 'name'
>> var value2 = 'Burger King'
>> var field3 = 'zip'
>> var value3 = '303*'
>
> Seems cumbersome,
The way I described it, maybe. It's really just a simple 'split string
and assign components to variables' routine.
> where is this input coming from?
From the command line, actually.
> I'll feed it from the command line. here's my PHP script:
>
> foreach (preg_split("/\s*;\s*/", join("", array_slice($argv, 1))) as $part){
> list ($field, $qualifier, $value) = preg_split("/\s*(=|like)\s*/", $part,
> 0, PREG_SPLIT_DELIM_CAPTURE);
> print "'$field' $qualifier '$value'\n";
> }
Looks good. Does it work for 1-, 2- and 3-part searches?
1 part : state=GA
2 parts: state=GA ; name = Burger King
3 parts: state=GA ; name = Burger King ; zip like 303*
Fabian Russell gave a 2-line perl splitter that works for all:
$line =~ s/( like )|( = )|( ; )|[=;]/!/ig;
@vals = split /!/, $line;
Then I added a little to get the data into the variables:
$fld1=$vals[0]; $val1=$vals[1];
$fld2=$vals[2]; $val2=$vals[3];
$fld3=$vals[4]; $val3=$vals[5];
> Here's me using it:
>
> /parse.php "state=GA ; name = Burger King ; zip like 303*"
> 'state' = 'GA'
> 'name' = 'Burger King'
> 'zip' like '303*'
>
> Obviously putting them in named variables is a piece of cake:
>
> foreach (preg_split("/\s*;\s*/", join("", array_slice($argv, 1))) as $part){
> list ($field, $qualifier, $value) = preg_split("/\s*(=|like)\s*/",
> $part, 0, PREG_SPLIT_DELIM_CAPTURE);
> $nr++;
> $output[] = ["field" . $nr => $field, "value" . $nr => $value];
> }
> print_r($output);
>
> Output:
>
> /parse.php "state=GA ; name = Burger King ; zip like 303*"
> Array
> (
> [0] => Array
> (
> [field1] => state
> [value1] => GA
> )
>
> [1] => Array
> (
> [field2] => name
> [value2] => Burger King
> )
>
> [2] => Array
> (
> [field3] => zip
> [value3] => 303*
> )
>
> )
That's not quite what I asked for. You're giving me array addresses,
when I wanted 6 discrete variables declared and assigned to:
fld1,val1,fld2,val2,fld3,val3.
> Only, you lose the qualifiers (i.e. you don't get the "=" or "like" which is
> supposedly meaningful.
'supposedly'?
As if being able to do a wildcard search using 'like' isn't a meaningful
feature?
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-25 18:06 +0000 |
| Message-ID | <sandman-80f983cedf5b1ba801ffd374a529b082@individual.net> |
| In reply to | #351771 |
In article <nflf1s$4s4$1@dont-email.me>, DFS wrote:
> > Sandman:
> > I'll feed it from the command line. here's my PHP script:
>
> > foreach (preg_split("/\s*;\s*/", join("", array_slice($argv, 1)))
> > as $part){ list ($field, $qualifier, $value) =
> > preg_split("/\s*(=|like)\s*/", $part, 0,
> > PREG_SPLIT_DELIM_CAPTURE); print "'$field' $qualifier '$value'\n";
> > }
>
> Looks good. Does it work for 1-, 2- and 3-part searches?
Of course:
/parse.php "state=GA ; name = Burger King"
'state' = 'GA'
'name' = 'Burger King'
> 1 part : state=GA
> 2 parts: state=GA ; name = Burger King
> 3 parts: state=GA ; name = Burger King ; zip like 303*
> Fabian Russell gave a 2-line perl splitter that works for all:
> $line =~ s/( like )|( = )|( ; )|[=;]/!/ig;
> @vals = split /!/, $line;
His perl was shite, though, and did nothing but split it up.
> Then I added a little to get the data into the variables:
> $fld1=$vals[0]; $val1=$vals[1];
> $fld2=$vals[2]; $val2=$vals[3];
> $fld3=$vals[4]; $val3=$vals[5];
Which of course is of no need, since you split it up in two parts, not one.
That way you get one split for the semicolons and one for the qualifiers.
It's better to set up what they keys and values are.
> > Obviously putting them in named variables is a piece of cake:
> That's not quite what I asked for. You're giving me array addresses,
> when I wanted 6 discrete variables declared and assigned to:
> fld1,val1,fld2,val2,fld3,val3.
Which, of course, is details. Looking at the code you can easily surmise that
whatever format you'd like it in is equally possible. Saving the values as
keys in an array is far more useful for processing the input than to assign
discrete variables, since it lacks foresight and flexibility.
> > Sandman:
> > Only, you lose the qualifiers (i.e. you don't get the "=" or
> > "like" which is supposedly meaningful.
>
> 'supposedly'?
Yes, why would they otherwise differ?
> As if being able to do a wildcard search using 'like' isn't a
> meaningful feature?
You're misunderstanding. Your example output, and especially Fabians messed
up perl gave no importance to the qualifiers. See the output of my first
script again:
/parse.php "state=GA ; name = Burger King ; zip like 303*"
'state' = 'GA'
'name' = 'Burger King'
'zip' like '303*'
See how I can later process that into a SQL query for instance, where the
"like" is treated differently than the "="'s. So you get this code:
foreach (preg_split("/\s*;\s*/", join("", array_slice($argv, 1))) as $part){
list ($field, $qualifier, $value) = preg_split("/\s*(=|like|!=)\s*/",
$part, 0, PREG_SPLIT_DELIM_CAPTURE);
$sql[] = $qualifier == "like" ? "$field like '" . str_replace("*",
"%", $value) . "'" : "$field $qualifier '$value'";
}
print "select * from where table " . join(" and ", $sql) . "\n";
And you run it like this:
/parse.php "state=GA ; name = Burger King ; zip like 303*"
select * from where table state = 'GA' and name = 'Burger King' and zip like
'303%'
But you can also use:
/parse.php "state=GA ; name != Burger King ; zip like 303*"
select * from where table state = 'GA' and name != 'Burger King' and zip like
'303%'
All in five lines of PHP. Also, it handles different spacing in the formats
as well:
/parse.php "state=GA;name!=Burger King;zip like 303*"
select * from where table state = 'GA' and name != 'Burger King' and zip like
'303%'
--
Sandman
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2016-04-26 12:41 -0400 |
| Message-ID | <nfo5ht$buu$1@dont-email.me> |
| In reply to | #351793 |
On 4/25/2016 2:06 PM, Sandman wrote:
> In article <nflf1s$4s4$1@dont-email.me>, DFS wrote:
>
>>> Sandman:
>>> I'll feed it from the command line. here's my PHP script:
>>
>>> foreach (preg_split("/\s*;\s*/", join("", array_slice($argv, 1)))
>>> as $part){ list ($field, $qualifier, $value) =
>>> preg_split("/\s*(=|like)\s*/", $part, 0,
>>> PREG_SPLIT_DELIM_CAPTURE); print "'$field' $qualifier '$value'\n";
>>> }
>>
>> Looks good. Does it work for 1-, 2- and 3-part searches?
>
> Of course:
>
> /parse.php "state=GA ; name = Burger King"
> 'state' = 'GA'
> 'name' = 'Burger King'
>
>> 1 part : state=GA
>> 2 parts: state=GA ; name = Burger King
>> 3 parts: state=GA ; name = Burger King ; zip like 303*
>
>> Fabian Russell gave a 2-line perl splitter that works for all:
>
>> $line =~ s/( like )|( = )|( ; )|[=;]/!/ig;
>> @vals = split /!/, $line;
>
> His perl was shite, though, and did nothing but split it up.
'Split it up' is half the battle, so I don't see a problem with his lines.
>> Then I added a little to get the data into the variables:
>
>> $fld1=$vals[0]; $val1=$vals[1];
>> $fld2=$vals[2]; $val2=$vals[3];
>> $fld3=$vals[4]; $val3=$vals[5];
>
> Which of course is of no need, since you split it up in two parts, not one.
> That way you get one split for the semicolons and one for the qualifiers.
> It's better to set up what they keys and values are.
Maybe.
>>> Obviously putting them in named variables is a piece of cake:
>
>> That's not quite what I asked for. You're giving me array addresses,
>> when I wanted 6 discrete variables declared and assigned to:
>> fld1,val1,fld2,val2,fld3,val3.
>
> Which, of course, is details.
heh! I think that's 3 responses now that used similar wording. I think
it's not a coincidence that all 3 failed to declare and assign the
variables, even though that was part of the primary requirement, as
stated in the 1st sentence of the 1st post in this thread.
> Looking at the code you can easily surmise that
> whatever format you'd like it in is equally possible. Saving the values as
> keys in an array is far more useful for processing the input than to assign
> discrete variables, since it lacks foresight and flexibility.
Assigning to discrete variables is just how I think most of the time.
Which has something to do with getting the data separated as much as
possible, rather than leaving it in a collection (array) and having to
find it with 'array(0)(1)' and such.
In my "real" program - of which this parse is a part - I split the
address being searched into key-values (in a VBScript dictionary object):
aDict.Add "Name", name
aDict.Add "Street", street
aDict.Add "City", city
aDict.Add "State", state
aDict.ADd "Zip", zip
After considering what you just said, it might also be helpful to store
the search criteria in key-value pairs as well:
sDict.Add "State", "GA"
sDict.Add "Name", "Burger King"
sDict.Add "Zip", "303*"
Because then I can use nested For loops to do a comparison like:
For each key1 in aDict
For each key2 in sDict
If key1 = key2 Then
If aDict(key1) = sDict(key2) Then
'exact match found
End If
End If
Next
Next
and possibly shorten the code.
Edit: just tried it and it worked perfectly - for exact matches. Will
now try to deal with wildcards and the != operator.
How would you do that (compare the contents of 2 dictionary objects) in
php or perl?
>>> Sandman:
>>> Only, you lose the qualifiers (i.e. you don't get the "=" or
>>> "like" which is supposedly meaningful.
>>
>> 'supposedly'?
>
> Yes, why would they otherwise differ?
>
>> As if being able to do a wildcard search using 'like' isn't a
>> meaningful feature?
>
> You're misunderstanding. Your example output, and especially Fabians messed
> up perl gave no importance to the qualifiers.
What's actually happening is you're giving importance to the qualifiers
(I call them operators) when that wasn't required.
> See the output of my first
> script again:
>
> /parse.php "state=GA ; name = Burger King ; zip like 303*"
> 'state' = 'GA'
> 'name' = 'Burger King'
> 'zip' like '303*'
>
> See how I can later process that into a SQL query for instance, where the
> "like" is treated differently than the "="'s. So you get this code:
>
> foreach (preg_split("/\s*;\s*/", join("", array_slice($argv, 1))) as $part){
> list ($field, $qualifier, $value) = preg_split("/\s*(=|like|!=)\s*/",
> $part, 0, PREG_SPLIT_DELIM_CAPTURE);
> $sql[] = $qualifier == "like" ? "$field like '" . str_replace("*",
> "%", $value) . "'" : "$field $qualifier '$value'";
> }
> print "select * from where table " . join(" and ", $sql) . "\n";
>
> And you run it like this:
>
> /parse.php "state=GA ; name = Burger King ; zip like 303*"
> select * from where table state = 'GA' and name = 'Burger King' and zip like
> '303%'
>
> But you can also use:
>
> /parse.php "state=GA ; name != Burger King ; zip like 303*"
> select * from where table state = 'GA' and name != 'Burger King' and zip like
> '303%'
>
> All in five lines of PHP. Also, it handles different spacing in the formats
> as well:
>
> /parse.php "state=GA;name!=Burger King;zip like 303*"
> select * from where table state = 'GA' and name != 'Burger King' and zip like
> '303%'
No db or SQL in this program - code only. But the != operator could be
an interesting feature to add.
Thanks for your code and analysis.
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-26 18:03 +0000 |
| Message-ID | <sandman-12d16528a1215c44f80acc4fd8e897c9@individual.net> |
| In reply to | #351979 |
In article <nfo5ht$buu$1@dont-email.me>, DFS wrote: > > > Fabian Russell gave a 2-line perl splitter that works for all: > > > > > $line =~ s/( like )|( = )|( ; )|[=;]/!/ig; > > > @vals = split /!/, $line; > > > > Sandman: > > His perl was shite, though, and did nothing but split it up. > > 'Split it up' is half the battle, so I don't see a problem with his > lines. I described it though. IT disregarded the qualifiers and just gave a scalar containing all the parts of no knowledge of what part is a field and what part is a value. It's the path of least resistance made by someone not very knowledgeable about programming. > > > DFS: > > > Then I added a little to get the data into the variables: > > > > > $fld1=$vals[0]; $val1=$vals[1]; > > > $fld2=$vals[2]; $val2=$vals[3]; > > > $fld3=$vals[4]; $val3=$vals[5]; > > > > Sandman: > > Which of course is of no need, since you split it up in two parts, > > not one. That way you get one split for the semicolons and one for > > the qualifiers. It's better to set up what they keys and values > > are. > > Maybe. Not maybe, definitely. This is what I do for a living. > > > > Sandman: > > > > Obviously putting them in named variables is a piece of cake: > > > > > > DFS: > > > That's not quite what I asked for. You're giving me array > > > addresses, when I wanted 6 discrete variables declared and > > > assigned to: fld1,val1,fld2,val2,fld3,val3. > > > > Sandman: > > Which, of course, is details. > > heh! I think that's 3 responses now that used similar wording. I > think it's not a coincidence that all 3 failed to declare and assign > the variables, even though that was part of the primary requirement, > as stated in the 1st sentence of the 1st post in this thread. Yes, but parsing the data is the entire point. When you have parsed the data, how you manage that data in memory is exactly just details. It's the process of parsing the data into manageable units that's the trick. I.e. if you read the data into an array, or two arrays, moving that data to discrete variables is as easy as: $field1 = $array["field"][1]; For instance. It's getting the data into whatever format you prefer that's the trick. Maybe moving data to a variable is super tricky in basic, but in every other scripting language, is so easy that it's not deserving of a separate step in the program. Everyone knows it can be done. > > Sandman: > > Looking at the code you can easily surmise that whatever format > > you'd like it in is equally possible. Saving the values as keys in > > an array is far more useful for processing the input than to > > assign discrete variables, since it lacks foresight and > > flexibility. > > Assigning to discrete variables is just how I think most of the > time. Then you need to rethink and up your game. > Which has something to do with getting the data separated as > much as possible, rather than leaving it in a collection (array) and > having to find it with 'array(0)(1)' and such. Which just means that you're writing very inefficient programs with poor flexibility and manageability of the data. > In my "real" program - of which this parse is a part - I split the > address being searched into key-values (in a VBScript dictionary > object): > aDict.Add "Name", name > aDict.Add "Street", street > aDict.Add "City", city > aDict.Add "State", state > aDict.ADd "Zip", zip > After considering what you just said, it might also be helpful to > store the search criteria in key-value pairs as well: > sDict.Add "State", "GA" > sDict.Add "Name", "Burger King" > sDict.Add "Zip", "303*" Which again ignores the qualifier. For verbosity, it should be saved as: $search[] = [ "field" => , $parser[0], "value" => $parser[2], "qualifier" => $parser[1] ]; For instance, so you can then loop through the $search array and collect your search criteria. > Because then I can use nested For loops to do a comparison like: > For each key1 in aDict > For each key2 in sDict > If key1 = key2 Then > If aDict(key1) = sDict(key2) Then > 'exact match found > End If > End If > Next > Next Which means you keep your entire search blob in memory, why oh why aren't you querying a database? > How would you do that (compare the contents of 2 dictionary objects) > in php or perl? Similarly, possibly. Only, I would never keep the searchable data in memory, I'd keep it in a database and use my parsed data to form a sql query. Properly indexed, querying that database will be super fast. > > > DFS: > > > As if being able to do a wildcard search using 'like' isn't a > > > meaningful feature? > > > > Sandman: > > You're misunderstanding. Your example output, and especially > > Fabians messed up perl gave no importance to the qualifiers. > > What's actually happening is you're giving importance to the > qualifiers (I call them operators) when that wasn't required. So why was one "like" and the others "=" if the difference isn't important? Why didn't you use "=" in all your examples? > > And you run it like this: > > > /parse.php "state=GA ; name = Burger King ; zip like 303*" > > select * from where table state = 'GA' and name = 'Burger King' > > and zip like '303%'" > > > But you can also use: > > > /parse.php "state=GA ; name != Burger King ; zip like 303*" > > select * from where table state = 'GA' and name != 'Burger King' > > and zip like '303%' > > > All in five lines of PHP. Also, it handles different spacing in > > the formats as well: > > > /parse.php "state=GA;name!=Burger King;zip like 303*" > > select * from where table state = 'GA' and name != 'Burger King' > > and zip like '303%' > > No db or SQL in this program - code only. So yeah, there's your first problem. -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2016-04-26 17:39 -0400 |
| Message-ID | <nfon0i$jik$1@dont-email.me> |
| In reply to | #352003 |
On 4/26/2016 2:03 PM, Sandman wrote: > In article <nfo5ht$buu$1@dont-email.me>, DFS wrote: > >>>> Fabian Russell gave a 2-line perl splitter that works for all: >>> >>>> $line =~ s/( like )|( = )|( ; )|[=;]/!/ig; >>>> @vals = split /!/, $line; >>> >>> Sandman: >>> His perl was shite, though, and did nothing but split it up. >> >> 'Split it up' is half the battle, so I don't see a problem with his >> lines. > > I described it though. IT disregarded the qualifiers and just gave a scalar > containing all the parts of no knowledge of what part is a field and what > part is a value. You/anyone can NEVER know that. The user could input everything in reverse or jumbled. Which is why I had to write other bloated code to make sure they enter only valid field names (name,street,city,state,zip) > It's the path of least resistance made by someone not very > knowledgeable about programming. ha! I disagree, but I can and will use that against the asshole Fabian Russell. >>>> DFS: >>>> Then I added a little to get the data into the variables: >>> >>>> $fld1=$vals[0]; $val1=$vals[1]; >>>> $fld2=$vals[2]; $val2=$vals[3]; >>>> $fld3=$vals[4]; $val3=$vals[5]; >>> >>> Sandman: >>> Which of course is of no need, since you split it up in two parts, >>> not one. That way you get one split for the semicolons and one for >>> the qualifiers. It's better to set up what they keys and values >>> are. >> >> Maybe. > > Not maybe, definitely. This is what I do for a living. You parse command line input for a living? Hope not, but if so that doesn't mean you're right that the proper methodology is to always store key-value pairs. >>>>> Sandman: >>>>> Obviously putting them in named variables is a piece of cake: >>>> >>>> DFS: >>>> That's not quite what I asked for. You're giving me array >>>> addresses, when I wanted 6 discrete variables declared and >>>> assigned to: fld1,val1,fld2,val2,fld3,val3. >>> >>> Sandman: >>> Which, of course, is details. >> >> heh! I think that's 3 responses now that used similar wording. I >> think it's not a coincidence that all 3 failed to declare and assign >> the variables, even though that was part of the primary requirement, >> as stated in the 1st sentence of the 1st post in this thread. > > Yes, but parsing the data is the entire point. When you have parsed the data, > how you manage that data in memory is exactly just details. It's the process > of parsing the data into manageable units that's the trick. I.e. if you read > the data into an array, or two arrays, moving that data to discrete variables > is as easy as: > > $field1 = $array["field"][1]; That's exactly what my original code does. That's exactly what everybody else has done, too. Do you think you're telling everyone something new? Do you think you're the only one who can do that? > For instance. It's getting the data into whatever format you prefer that's > the trick. Maybe moving data to a variable is super tricky in basic, but in > every other scripting language, is so easy that it's not deserving of a > separate step in the program. Everyone knows it can be done. Bad excuse. >>> Sandman: >>> Looking at the code you can easily surmise that whatever format >>> you'd like it in is equally possible. Saving the values as keys in >>> an array is far more useful for processing the input than to >>> assign discrete variables, since it lacks foresight and >>> flexibility. >> >> Assigning to discrete variables is just how I think most of the >> time. > > Then you need to rethink and up your game. > >> Which has something to do with getting the data separated as >> much as possible, rather than leaving it in a collection (array) and >> having to find it with 'array(0)(1)' and such. > > Which just means that you're writing very inefficient programs with poor > flexibility and manageability of the data. > >> In my "real" program - of which this parse is a part - I split the >> address being searched into key-values (in a VBScript dictionary >> object): > >> aDict.Add "Name", name >> aDict.Add "Street", street >> aDict.Add "City", city >> aDict.Add "State", state >> aDict.ADd "Zip", zip > >> After considering what you just said, it might also be helpful to >> store the search criteria in key-value pairs as well: > >> sDict.Add "State", "GA" >> sDict.Add "Name", "Burger King" >> sDict.Add "Zip", "303*" > > Which again ignores the qualifier. For verbosity, it should be saved as: > > $search[] = [ > "field" => , $parser[0], > "value" => $parser[2], > "qualifier" => $parser[1] > ]; Yeah, I'm toying around with the operators. Being able to use != is a nice-to-have. > For instance, so you can then loop through the $search array and collect your > search criteria. > >> Because then I can use nested For loops to do a comparison like: > >> For each key1 in aDict >> For each key2 in sDict >> If key1 = key2 Then >> If aDict(key1) = sDict(key2) Then >> 'exact match found >> End If >> End If >> Next >> Next > > Which means you keep your entire search blob in memory, why oh why aren't you > querying a database? So I can send anyone in the [Windows] world a VBScript .vbs file and a list of addresses and they can go to town. No db wanted or needed. >> How would you do that (compare the contents of 2 dictionary objects) >> in php or perl? > > Similarly, possibly. Only, I would never keep the searchable data in memory, > I'd keep it in a database and use my parsed data to form a sql query. > Properly indexed, querying that database will be super fast. It's fast enough in code - <0.50 seconds to import 10K addresses, de-dupe them, apply the search criteria, sort the output and save to a file. It happens almost instantaneously onscreen. >>>> DFS: >>>> As if being able to do a wildcard search using 'like' isn't a >>>> meaningful feature? >>> >>> Sandman: >>> You're misunderstanding. Your example output, and especially >>> Fabians messed up perl gave no importance to the qualifiers. >> >> What's actually happening is you're giving importance to the >> qualifiers (I call them operators) when that wasn't required. > > So why was one "like" and the others "=" if the difference isn't important? > Why didn't you use "=" in all your examples? It wasn't important to /this challenge/. >>> And you run it like this: >> >>> /parse.php "state=GA ; name = Burger King ; zip like 303*" >>> select * from where table state = 'GA' and name = 'Burger King' >>> and zip like '303%'" >> >>> But you can also use: >> >>> /parse.php "state=GA ; name != Burger King ; zip like 303*" >>> select * from where table state = 'GA' and name != 'Burger King' >>> and zip like '303%' >> >>> All in five lines of PHP. Also, it handles different spacing in >>> the formats as well: >> >>> /parse.php "state=GA;name!=Burger King;zip like 303*" >>> select * from where table state = 'GA' and name != 'Burger King' >>> and zip like '303%' >> >> No db or SQL in this program - code only. > > So yeah, there's your first problem. If you're relying on a db as a crutch to overcome deficiencies in your skills or language tools, it's YOUR problem.
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-27 05:50 +0000 |
| Message-ID | <sandman-ebbc47e852d0466e10672f028475c38e@individual.net> |
| In reply to | #352037 |
In article <nfon0i$jik$1@dont-email.me>, DFS wrote: > > Sandman: > > I described it though. IT disregarded the qualifiers and just gave > > a scalar containing all the parts of no knowledge of what part is > > a field and what part is a value. > > You/anyone can NEVER know that. The user could input everything in > reverse or jumbled. Which is why I had to write other bloated code > to make sure they enter only valid field names > (name,street,city,state,zip) This is incorrect. By using qualifiers, the user states the placement of the fields, separated by a qualifier. > > Sandman: > > It's the path of least resistance made by someone not very > > knowledgeable about programming. > > ha! I disagree, but I can and will use that against the asshole > Fabian Russell. Whatever, you write basic, so... :) He's a moron either way. > > > > Sandman: > > > > Which of course is of no need, since you split it up > > > > in two parts, not one. That way you get one split for the > > > > semicolons and one for the qualifiers. It's better to set up > > > > what they keys and values are. > > > > > > DFS: > > > Maybe. > > > > Sandman: > > Not maybe, definitely. This is what I do for a living. > > You parse command line input for a living? I parse, interprete, structure, process and handle data for a living, yes. > Hope not, but if so that doesn't mean you're right that the proper > methodology is to always store key-value pairs. It is. > > > DFS: > > > heh! I think that's 3 responses now that used similar wording. I > > > think it's not a coincidence that all 3 failed to declare and > > > assign the variables, even though that was part of the primary > > > requirement, as stated in the 1st sentence of the 1st post in > > > this thread. > > > > Sandman: > > Yes, but parsing the data is the entire point. When you have > > parsed the data, how you manage that data in memory is exactly > > just details. It's the process of parsing the data into manageable > > units that's the trick. I.e. if you read the data into an array, > > or two arrays, moving that data to discrete variables is as easy > > as: > > > $field1 = $array["field"][1]; > > That's exactly what my original code does. That's exactly what > everybody else has done, too. > Do you think you're telling everyone something new? Do you think > you're the only one who can do that? What is wrong with you? I *specifically* stated that I *skipped* any such step because A. it's a moronic way to handle data and B. *everyone* knows this is possible in *any* programming language and as such is not needed as a part to showcase how the task should be done. It's a mere nitpick on your part when you realized that 2 lines of PHP code parsed input data elegantly and easily what took basic some 20+ lines to do > > Sandman: > > For instance. It's getting the data into whatever format you > > prefer that's the trick. Maybe moving data to a variable is super > > tricky in basic, but in every other scripting language, is so easy > > that it's not deserving of a separate step in the program. > > Everyone knows it can be done. > > Bad excuse. *rolleye* > > Sandman: > > Which means you keep your entire search blob in memory, why oh why > > aren't you querying a database? > > So I can send anyone in the [Windows] world a VBScript .vbs file and > a list of addresses and they can go to town. No db wanted or needed. "a list of addresses" *should* be a database. Use a sqlite3 file if you want to and then query it using sqlite3, instead of a plain text file. > > > DFS: > > > How would you do that (compare the contents of 2 dictionary > > > objects) in php or perl? > > > > Sandman: > > Similarly, possibly. Only, I would never keep the searchable data > > in memory, I'd keep it in a database and use my parsed data to > > form a sql query. Properly indexed, querying that database will be > > super fast. > > It's fast enough in code - <0.50 seconds to import 10K addresses, > de-dupe them, apply the search criteria, sort the output and save to > a file. It happens almost instantaneously onscreen. That's very slow indeed. Maybe I'm just used to building solutions where tens of thousands of people are using it at the same time, at which point those slow executions add up. > > Sandman: > > So why was one "like" and the others "=" if the difference isn't > > important? Why didn't you use "=" in all your examples? > > It wasn't important to /this challenge/. If it wasn't important, then don't include it. Luckily, my code took it into account and made the best of it while yours ignored it. > > > DFS: > > > No db or SQL in this program - code only. > > > > Sandman: > > So yeah, there's your first problem. > > If you're relying on a db as a crutch to overcome deficiencies in > your skills or language tools, it's YOUR problem. What. The. Fuck? A DB has fuck all to do with neither skill nor tools and everything to do with *SPEED*. -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | chrisv <chrisv@nospam.invalid> |
|---|---|
| Date | 2016-04-27 06:43 -0500 |
| Message-ID | <ba91ibpdk1itsu0jt95s96jm0kl3cvq02q@4ax.com> |
| In reply to | #352122 |
Sandman wrote: >I parse, interprete, structure, process and handle data for a living, yes. And your hobby is collecting spores, mold, and fungi. 8) -- "At one point, a Windows supercomputer was #58 on the Top 500, leaving 442 Linux supercomputers in the dust." - DumFSck
[toc] | [prev] | [next] | [standalone]
| From | William Poaster <wp@dev.null> |
|---|---|
| Date | 2016-04-27 13:11 +0100 |
| Message-ID | <1tm6vc-vbv.ln1@user-1842.linux.individual.net> |
| In reply to | #352155 |
chrisv wrote: > Sandman wrote: > >>I parse, interprete, structure, process and handle data for a living, yes. > > And your hobby is collecting spores, mold, and fungi. 8) "At one point, a Windows supercomputer was #58 on the Top 500, leaving 442 Linux supercomputers in the dust." - DumFSck DumbFor$ure can't count either! -- openSUSE 13.2 64-bit KDE 4.14.9 Kernel: 4.5.0-10.1.gb98c3d3-desktop #1 SMP PREEMPT Mon Apr 11 x86_64 x86_64 x86_64 GNU/Linux This message is virus free, as absolutely NO Micro$oft products were used in its preparation. "If you do want to clean your computer of malware, the first software to delete is Windows." http://www.gnu.org/proprietary/malware-microsoft.en.html
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-27 13:32 +0000 |
| Message-ID | <sandman-4fbbb3c54aab6d269276a660a96fdbaa@individual.net> |
| In reply to | #352155 |
In article <ba91ibpdk1itsu0jt95s96jm0kl3cvq02q@4ax.com>, chrisv wrote: > > Sandman: > > I parse, interprete, structure, process and handle data for a > > living, yes. > > And your hobby is collecting spores, mold, and fungi. 8) Haha, no :) -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2016-04-27 07:32 -0700 |
| Message-ID | <a6126f2d-d28b-4e7c-85db-dd749a064bdd@googlegroups.com> |
| In reply to | #352122 |
On Tuesday, April 26, 2016 at 11:50:17 PM UTC-6, Sandman wrote: > In article <nfon0i$jik$1@dont-email.me>, DFS wrote: > > > > Sandman: > > > I described it though. IT disregarded the qualifiers and just gave > > > a scalar containing all the parts of no knowledge of what part is > > > a field and what part is a value. > > > > You/anyone can NEVER know that. The user could input everything in > > reverse or jumbled. Which is why I had to write other bloated code > > to make sure they enter only valid field names > > (name,street,city,state,zip) > > This is incorrect. By using qualifiers, the user states the placement of the > fields, separated by a qualifier. > > > > Sandman: > > > It's the path of least resistance made by someone not very > > > knowledgeable about programming. > > > > ha! I disagree, but I can and will use that against the asshole > > Fabian Russell. > > Whatever, you write basic, so... :) > > He's a moron either way. > > > > > > Sandman: > > > > > Which of course is of no need, since you split it up > > > > > in two parts, not one. That way you get one split for the > > > > > semicolons and one for the qualifiers. It's better to set up > > > > > what they keys and values are. > > > > > > > > DFS: > > > > Maybe. > > > > > > Sandman: > > > Not maybe, definitely. This is what I do for a living. > > > > You parse command line input for a living? > > I parse, interprete, structure, process and handle data for a living, yes. > > > Hope not, but if so that doesn't mean you're right that the proper > > methodology is to always store key-value pairs. > > It is. > > > > > DFS: > > > > heh! I think that's 3 responses now that used similar wording. I > > > > think it's not a coincidence that all 3 failed to declare and > > > > assign the variables, even though that was part of the primary > > > > requirement, as stated in the 1st sentence of the 1st post in > > > > this thread. > > > > > > Sandman: > > > Yes, but parsing the data is the entire point. When you have > > > parsed the data, how you manage that data in memory is exactly > > > just details. It's the process of parsing the data into manageable > > > units that's the trick. I.e. if you read the data into an array, > > > or two arrays, moving that data to discrete variables is as easy > > > as: > > > > > $field1 = $array["field"][1]; > > > > That's exactly what my original code does. That's exactly what > > everybody else has done, too. > > > Do you think you're telling everyone something new? Do you think > > you're the only one who can do that? > > What is wrong with you? I *specifically* stated that I *skipped* any such > step because A. it's a moronic way to handle data and B. *everyone* knows > this is possible in *any* programming language and as such is not needed as a > part to showcase how the task should be done. It's a mere nitpick on your > part when you realized that 2 lines of PHP code parsed input data elegantly > and easily what took basic some 20+ lines to do > > > > Sandman: > > > For instance. It's getting the data into whatever format you > > > prefer that's the trick. Maybe moving data to a variable is super > > > tricky in basic, but in every other scripting language, is so easy > > > that it's not deserving of a separate step in the program. > > > Everyone knows it can be done. > > > > Bad excuse. > > *rolleye* > > > > Sandman: > > > Which means you keep your entire search blob in memory, why oh why > > > aren't you querying a database? > > > > So I can send anyone in the [Windows] world a VBScript .vbs file and > > a list of addresses and they can go to town. No db wanted or needed. > > "a list of addresses" *should* be a database. Use a sqlite3 file if you want > to and then query it using sqlite3, instead of a plain text file. > > > > > DFS: > > > > How would you do that (compare the contents of 2 dictionary > > > > objects) in php or perl? > > > > > > Sandman: > > > Similarly, possibly. Only, I would never keep the searchable data > > > in memory, I'd keep it in a database and use my parsed data to > > > form a sql query. Properly indexed, querying that database will be > > > super fast. > > > > It's fast enough in code - <0.50 seconds to import 10K addresses, > > de-dupe them, apply the search criteria, sort the output and save to > > a file. It happens almost instantaneously onscreen. > > That's very slow indeed. Maybe I'm just used to building solutions where tens > of thousands of people are using it at the same time, at which point those > slow executions add up. You're probably mainly doing stuff for the web so, yeah, that's a big consideration (and a DB like MongDB is another option for stuff like this). > > > > Sandman: > > > So why was one "like" and the others "=" if the difference isn't > > > important? Why didn't you use "=" in all your examples? > > > > It wasn't important to /this challenge/. > > If it wasn't important, then don't include it. Luckily, my code took it into > account and made the best of it while yours ignored it. > > > > > DFS: > > > > No db or SQL in this program - code only. > > > > > > Sandman: > > > So yeah, there's your first problem. > > > > If you're relying on a db as a crutch to overcome deficiencies in > > your skills or language tools, it's YOUR problem. > > What. The. Fuck? > > A DB has fuck all to do with neither skill nor tools and everything to do > with *SPEED*. > > -- > Sandman
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-27 15:02 +0000 |
| Message-ID | <sandman-0b04eb649cd63ebc62a4706d1eb970bf@individual.net> |
| In reply to | #352181 |
In article <a6126f2d-d28b-4e7c-85db-dd749a064bdd@googlegroups.com>, Steve Carroll wrote: > > Sandman: > > That's very slow indeed. Maybe I'm just used to building solutions > > where tens of thousands of people are using it at the same time, > > at which point those slow executions add up. > > You're probably mainly doing stuff for the web so, yeah, that's a > big consideration Well, while that's true, designing things intelligently should still apply. While DFS certainly isn't a programmer that deals with large data and usage quantities, that doesn't excuse being lazy. Like I said elsewhere in the post, use sqlite, it's a one-file database you can query a lot like a "real" sql database server. He's still keeping addresses in a text file, why not save them to a sqlite file instead and save both time and resources? :) The time invested in getting acquainted with sqlite is time well spent for any and all future projects of this scope. -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2016-04-27 08:17 -0700 |
| Message-ID | <aa0e913a-2a5b-4820-91c1-424c585f6910@googlegroups.com> |
| In reply to | #352193 |
On Wednesday, April 27, 2016 at 9:02:36 AM UTC-6, Sandman wrote: > In article <a6126f2d-d28b-4e7c-85db-dd749a064bdd@googlegroups.com>, Steve > Carroll wrote: > > > > Sandman: > > > That's very slow indeed. Maybe I'm just used to building solutions > > > where tens of thousands of people are using it at the same time, > > > at which point those slow executions add up. > > > > You're probably mainly doing stuff for the web so, yeah, that's a > > big consideration > > Well, while that's true, designing things intelligently should still apply. > While DFS certainly isn't a programmer that deals with large data and usage > quantities, that doesn't excuse being lazy. Like I said elsewhere in the post, > use sqlite, it's a one-file database you can query a lot like a "real" sql > database server. He's still keeping addresses in a text file, why not save them > to a sqlite file instead and save both time and resources? :) > > The time invested in getting acquainted with sqlite is time well spent for any > and all future projects of this scope. > > -- > Sandman I agree with your premises. Frankly, I don't know if they all apply to DFS here because I haven't followed all that closely. One of his main points seems to be portability, a thing that, in my opinion, is not precluded with the use of a DB... his mileage seems to vary (different worlds, I suppose).
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-27 16:21 +0000 |
| Message-ID | <sandman-7e12a46d2e8ed423f2d517bc344b25da@individual.net> |
| In reply to | #352196 |
In article <aa0e913a-2a5b-4820-91c1-424c585f6910@googlegroups.com>, Steve Carroll wrote: > > Sandman: > > Well, while that's true, designing things intelligently should > > still apply. While DFS certainly isn't a programmer that deals > > with large data and usage quantities, that doesn't excuse being > > lazy. Like I said elsewhere in the post, use sqlite, it's a > > one-file database you can query a lot like a "real" sql database > > server. He's still keeping addresses in a text file, why not save > > them to a sqlite file instead and save both time and resources? :) > > The time invested in getting acquainted with sqlite is time well > > spent for any and all future projects of this scope. -- Sandman > > I agree with your premises. Frankly, I don't know if they all apply > to DFS here because I haven't followed all that closely. One of his > main points seems to be portability, a thing that, in my opinion, is > not precluded with the use of a DB... his mileage seems to vary > (different worlds, I suppose). Well, his portability seems to center around sending different people his search script and his text file with addresses. So sending them a search script that is more flexible, faster and more efficient along with a DB file (that, again, doesn't require an actual DB *server* to be used, it's just one file) is just a better choice. I just posted an example of exactly how that would look and work. -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2016-04-27 09:42 -0700 |
| Message-ID | <b5c47dad-9b5e-4667-ba71-13b02b9b2ac3@googlegroups.com> |
| In reply to | #352207 |
On Wednesday, April 27, 2016 at 10:21:32 AM UTC-6, Sandman wrote: > In article <aa0e913a-2a5b-4820-91c1-424c585f6910@googlegroups.com>, Steve > Carroll wrote: > > > > Sandman: > > > Well, while that's true, designing things intelligently should > > > still apply. While DFS certainly isn't a programmer that deals > > > with large data and usage quantities, that doesn't excuse being > > > lazy. Like I said elsewhere in the post, use sqlite, it's a > > > one-file database you can query a lot like a "real" sql database > > > server. He's still keeping addresses in a text file, why not save > > > them to a sqlite file instead and save both time and resources? :) > > > The time invested in getting acquainted with sqlite is time well > > > spent for any and all future projects of this scope. -- Sandman > > > > I agree with your premises. Frankly, I don't know if they all apply > > to DFS here because I haven't followed all that closely. One of his > > main points seems to be portability, a thing that, in my opinion, is > > not precluded with the use of a DB... his mileage seems to vary > > (different worlds, I suppose). > > Well, his portability seems to center around sending different people his > search script and his text file with addresses. So sending them a search script > that is more flexible, faster and more efficient along with a DB file (that, > again, doesn't require an actual DB *server* to be used, it's just one file) is > just a better choice. I just posted an example of exactly how that would look > and work. I saw your example, good job. Like I said, I haven't followed closely so I'm not sure what he's trying to do... but there is no question in my mind that your example is quite portable. Somewhere he mentioned something about this being part of a larger program, maybe that's a sticking point in his mind?
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-27 21:39 +0000 |
| Message-ID | <sandman-42fc8446b9e29b2d2e0159f03daa118f@individual.net> |
| In reply to | #352215 |
In article <b5c47dad-9b5e-4667-ba71-13b02b9b2ac3@googlegroups.com>, Steve Carroll wrote: > > Sandman: > > Well, his portability seems to center around sending different > > people his search script and his text file with addresses. So > > sending them a search script that is more flexible, faster and > > more efficient along with a DB file (that, again, doesn't require > > an actual DB *server* to be used, it's just one file) is just a > > better choice. I just posted an example of exactly how that would > > look and work. > > I saw your example, good job. Like I said, I haven't followed > closely so I'm not sure what he's trying to do... but there is no > question in my mind that your example is quite portable. Somewhere > he mentioned something about this being part of a larger program, > maybe that's a sticking point in his mind? Dunno, but he is placing a lot of misplaced pride into low-level programming, with tons of "if"'s to handle different kind of input instead of building it organically as a query. Just saying saving and retrieving data in different formats is exactly what databases are for. When I started with perl back in 1994 I wrote my first CGI script as a guestbook on my homepage. It took the form input and saved it to text files, separated by the string "OTTEROTTER" so a guestbook entry could be saved to 1994-03-45_102343.txt and contain: "Steve CarrollOTTEROTTERHelloOTTEROTTERJust wanted to say hiOTTEROTTER1994-03- 45 12:23:43" Looking back it's kind of fun to think about these kind of idiotic things I made when I was new and just learning. That's why I think it's important to tell others that are new to get it right from the start instead of going the long way. -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2016-04-27 23:25 +0000 |
| Message-ID | <fhjgd003a.r@rooftop.invalid> |
| In reply to | #352269 |
Sandman <mr@sandman.net> wrote: > In article <b5c47dad-9b5e-4667-ba71-13b02b9b2ac3@googlegroups.com>, Steve > Carroll wrote: > >> > Sandman: >> > Well, his portability seems to center around sending different >> > people his search script and his text file with addresses. So >> > sending them a search script that is more flexible, faster and >> > more efficient along with a DB file (that, again, doesn't require >> > an actual DB *server* to be used, it's just one file) is just a >> > better choice. I just posted an example of exactly how that would >> > look and work. >> >> I saw your example, good job. Like I said, I haven't followed >> closely so I'm not sure what he's trying to do... but there is no >> question in my mind that your example is quite portable. Somewhere >> he mentioned something about this being part of a larger program, >> maybe that's a sticking point in his mind? > > Dunno, but he is placing a lot of misplaced pride into low-level programming, > with tons of "if"'s to handle different kind of input instead of building it > organically as a query. Just saying saving and retrieving data in different > formats is exactly what databases are for. > > When I started with perl back in 1994 I wrote my first CGI script as a > guestbook on my homepage. It took the form input and saved it to text files, > separated by the string "OTTEROTTER" so a guestbook entry could be saved to > 1994-03-45_102343.txt and contain: > > "Steve CarrollOTTEROTTERHelloOTTEROTTERJust wanted to say hiOTTEROTTER1994-03- > 45 12:23:43" > > Looking back it's kind of fun to think about these kind of idiotic things I > made when I was new and just learning. That's why I think it's important to > tell others that are new to get it right from the start instead of going the > long way. > March 45, 1994. A date which will live in infamy.
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-28 05:34 +0000 |
| Message-ID | <sandman-d6dccaa856099359e345e4855c79d094@individual.net> |
| In reply to | #352294 |
In article <fhjgd003a.r@rooftop.invalid>, owl wrote: > > Sandman: > > In article > > <b5c47dad-9b5e-4667-ba71-13b02b9b2ac3@googlegroups.com>, Steve > > > > > Well, his portability seems to center around sending > > > > different people his search script and his text file with > > > > addresses. So sending them a search script that is more > > > > flexible, faster and more efficient along with a DB file > > > > (that, again, doesn't require an actual DB *server* to be > > > > used, it's just one file) is just a better choice. I just > > > > posted an example of exactly how that would look and work. > > > > > > Steve Carroll: > > > I saw your example, good job. Like I said, I haven't followed > > > closely so I'm not sure what he's trying to do... but there is > > > no question in my mind that your example is quite portable. > > > Somewhere he mentioned something about this being part of a > > > larger program, maybe that's a sticking point in his mind? > > > > Sandman: > > Dunno, but he is placing a lot of misplaced pride into low-level > > programming, with tons of "if"'s to handle different kind of input > > instead of building it organically as a query. Just saying saving > > and retrieving data in different formats is exactly what databases > > are for. > > > When I started with perl back in 1994 I wrote my first CGI script > > as a guestbook on my homepage. It took the form input and saved it > > to text files, separated by the string "OTTEROTTER" so a guestbook > > entry could be saved to 1994-03-45_102343.txt and contain: > > > "Steve CarrollOTTEROTTERHelloOTTEROTTERJust wanted to say > > hiOTTEROTTER1994-03- 45 12:23:43" > > > Looking back it's kind of fun to think about these kind of idiotic > > things I made when I was new and just learning. That's why I think > > it's important to tell others that are new to get it right from > > the start instead of going the long way. > > March 45, 1994. A date which will live in infamy. Yeah, I miss the good old days, when months could go on forever :) -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2016-04-28 05:37 +0000 |
| Message-ID | <dodlssFbe42U2@mid.individual.net> |
| In reply to | #352362 |
On Thu, 28 Apr 2016 05:34:33 +0000, Sandman wrote: > In article <fhjgd003a.r@rooftop.invalid>, owl wrote: > >> > Sandman: >> > In article <b5c47dad-9b5e-4667-ba71-13b02b9b2ac3@googlegroups.com>, >> > Steve >> >> > > > Well, his portability seems to center around sending different >> > > > people his search script and his text file with addresses. So >> > > > sending them a search script that is more flexible, faster and >> > > > more efficient along with a DB file (that, again, doesn't require >> > > > an actual DB *server* to be used, it's just one file) is just a >> > > > better choice. I just posted an example of exactly how that would >> > > > look and work. >> > > >> > > Steve Carroll: >> > > I saw your example, good job. Like I said, I haven't followed >> > > closely so I'm not sure what he's trying to do... but there is no >> > > question in my mind that your example is quite portable. Somewhere >> > > he mentioned something about this being part of a larger program, >> > > maybe that's a sticking point in his mind? >> > >> > Sandman: >> > Dunno, but he is placing a lot of misplaced pride into low-level >> > programming, with tons of "if"'s to handle different kind of input >> > instead of building it organically as a query. Just saying saving and >> > retrieving data in different formats is exactly what databases are >> > for. >> >> > When I started with perl back in 1994 I wrote my first CGI script as >> > a guestbook on my homepage. It took the form input and saved it to >> > text files, separated by the string "OTTEROTTER" so a guestbook entry >> > could be saved to 1994-03-45_102343.txt and contain: >> >> > "Steve CarrollOTTEROTTERHelloOTTEROTTERJust wanted to say >> > hiOTTEROTTER1994-03- 45 12:23:43" >> >> > Looking back it's kind of fun to think about these kind of idiotic >> > things I made when I was new and just learning. That's why I think >> > it's important to tell others that are new to get it right from the >> > start instead of going the long way. >> >> March 45, 1994. A date which will live in infamy. > > Yeah, I miss the good old days, when months could go on forever :) Is it possible that was just the 45th guestbook entry for that day? -- -v "Desktops, workstations and servers are and Microsoft is doing very well. AS well as Linux." -"Slimer"
[toc] | [prev] | [next] | [standalone]
| From | Sandman <mr@sandman.net> |
|---|---|
| Date | 2016-04-28 05:42 +0000 |
| Message-ID | <sandman-1d87384ab291c0e75db15f52f9fbff17@individual.net> |
| In reply to | #352363 |
In article <dodlssFbe42U2@mid.individual.net>, vallor wrote: > > > > Sandman: > > > > In article > > > > <b5c47dad-9b5e-4667-ba71-13b02b9b2ac3@googlegroups.com>, Steve > > > > > > > > > Well, his portability seems to center around sending > > > > > > different people his search script and his text file with > > > > > > addresses. So sending them a search script that is more > > > > > > flexible, faster and more efficient along with a DB file > > > > > > (that, again, doesn't require an actual DB *server* to be > > > > > > used, it's just one file) is just a better choice. I just > > > > > > posted an example of exactly how that would look and work. > > > > > > > > > > Steve Carroll: > > > > > I saw your example, good job. Like I said, I > > > > > haven't followed closely so I'm not sure what he's trying to > > > > > do... but there is no question in my mind that your example > > > > > is quite portable. Somewhere he mentioned something about > > > > > this being part of a larger program, maybe that's a sticking > > > > > point in his mind? > > > > > > > > Sandman: > > > > Dunno, but he is placing a lot of misplaced pride > > > > into low-level programming, with tons of "if"'s to handle > > > > different kind of input instead of building it organically as > > > > a query. Just saying saving and retrieving data in different > > > > formats is exactly what databases are for. > > > > > > > When I started with perl back in 1994 I wrote my first CGI > > > > script as a guestbook on my homepage. It took the form input > > > > and saved it to text files, separated by the string > > > > "OTTEROTTER" so a guestbook entry could be saved to > > > > 1994-03-45_102343.txt and contain: > > > > > > > "Steve CarrollOTTEROTTERHelloOTTEROTTERJust wanted to say > > > > hiOTTEROTTER1994-03- 45 12:23:43" > > > > > > > Looking back it's kind of fun to think about these kind of > > > > idiotic things I made when I was new and just learning. That's > > > > why I think it's important to tell others that are new to get > > > > it right from the start instead of going the long way. > > > > > > owl: > > > March 45, 1994. A date which will live in infamy. > > > > Sandman: > > Yeah, I miss the good old days, when months could go on forever :) > > Is it possible that was just the 45th guestbook entry for that day? Nah, it was me messing up the date when writing an example. :) -- Sandman
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2016-04-27 11:45 -0400 |
| Message-ID | <nfqmk5$6e5$1@dont-email.me> |
| In reply to | #352193 |
On 4/27/2016 11:02 AM, Sandman wrote: > In article <a6126f2d-d28b-4e7c-85db-dd749a064bdd@googlegroups.com>, Steve > Carroll wrote: > >>> Sandman: >>> That's very slow indeed. Maybe I'm just used to building solutions >>> where tens of thousands of people are using it at the same time, >>> at which point those slow executions add up. >> >> You're probably mainly doing stuff for the web so, yeah, that's a >> big consideration > > Well, while that's true, designing things intelligently should still apply. > While DFS certainly isn't a programmer that deals with large data and usage > quantities, that doesn't excuse being lazy. Piss off. For the data quantities (address counts) I'm working with on this throwaway project, using SQLite or any db is absurd. It makes the program more difficult to deploy and write, and slower. > Like I said elsewhere in the post, > use sqlite, it's a one-file database you can query a lot like a "real" sql > database server. He's still keeping addresses in a text file, why not save them > to a sqlite file instead and save both time and resources? :) > > The time invested in getting acquainted with sqlite is time well spent for any > and all future projects of this scope. I know how to use SQLite, programmatically and from the command line. I think it's a /great/ public domain program.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.os.linux.advocacy
csiph-web