Why is Everybody so clueless on the importance of Desktop Search to the Masses?
-
Hi-Lite & Line Wrap - The Heart of Search
@CodeSimian said:
Except you will never be able to "prove" to Spectate that any tool is better than the all-powerful SSDS.
Do a 2 page flowchart of the hi-lite and line wrap logic of a search. Give me the source code to it. Like I have you. Then we will talk about what is better. Search is useless without hi-lite and line wrap (copernic). Can you search for leading and trailing spaces? Is the search case sensitive? Does it allow for data other than the search elements to be hi-lited. (VISUAL keys)
By far the most difficult part of search is layed out here. It works. It is the heart of search. Make that part of the code work and you will have search. Strip out all the other logic and rebuild around the hi-lite and wrap stuff. Searching for elements in strings is easy. Doing the hilite and line wrap is the first hurdle of search. You can do it I know you can.
. Finding 
-
@Spectre said:
SpectateSwamp: Then type gf at prompt 6 quantumleap and schnapps.
Ouch! Laughter pain!
Also, I've a suggestion for a new tag...
-
-
How fast are sequential reads 20,000,000cps & Beyond?
@insta said:
Like my last post said. And I don't like repeating myself. Everybody asks the same questions. I get shit for the same answers so sometimes I spice it up a bit. But anyway back to your search of a random file. Test this out for me. How fast is your computer at reading data from your disk without searching Just reading from start to end of file. Say you just want the last page to display. How fast does it move data. Is it somewhere in the 20,000,000 cps range? If it is then you'll have proved that I'm not Gee Hawing youI know damn well where the text is, the whole point of the exercise is to see if Joe Q Random on TDWTF forums can write a faster sequential file search. I'm trying to find something tangible that we can compete against him on. Of course the search giants are all in cahoots with Microsoft so Windows will make their lookups faster, but VB6 vs VB6 should be pretty clear cut, no?
-
@SpectateSwamp said:
Test this out for me. How fast is your computer at reading data from your disk without searching Just reading from start to end of file. Say you just want the last page to display. How fast does it move data. Is it somewhere in the 20,000,000 cps range? If it is then you'll have proved that I'm not Gee Hawing you
THAT DOESNT EVEN MAKE SENSE YOU RETARD
-
@SpectateSwamp said:
Do a 2 page flowchart of the hi-lite and line wrap logic of a search. Give me the source code to it. Like I have you. Then we will talk about what is better. Search is useless without hi-lite and line wrap (copernic). Can you search for leading and trailing spaces? Is the search case sensitive? Does it allow for data other than the search elements to be hi-lited. (VISUAL keys)
By far the most difficult part of search is layed out here. It works. It is the heart of search. Make that part of the code work and you will have search. Strip out all the other logic and rebuild around the hi-lite and wrap stuff. Searching for elements in strings is easy. Doing the hilite and line wrap is the first hurdle of search. You can do it I know you can.
Hilite and line wrap are not essential to searching, they are helpful in displaying the matches in a single file but not fundamental to searching for files. Why would you search for leading or trailing spaces - normally whitespace is pretty much ignored when searching for words and phrases.
You certainly seem to have some unique concepts regarding what searching means and what makes a good search.
-
SSDS total recall
@CodeSimian said:
Maybe Swamp has ADD? Except his problem is so acute he cannot remember what he was saying 5 minutes ago.
Thats why I keep lots of notes and have a search that can show me them. No matter how large my file gets. So sad the others have size limits. They all do. I have proved that. MPS found a site stating as much. A lapse in memory isn't that much of a problem, if you have a good Search for your notes.
-
@SpectateSwamp said:
MPS found a site stating as much. A lapse in memory isn't that much of a problem, if you have a good Search for your notes.
Yes, and the size of the file would be ridiculously large.
When I make notes, I use outlook or onenote. And they search and perform A LOT better than any plain text search ever will. I can also throw pictures in my notes, or whatever other file I am thinking about when I decide to make a note.
Why don't you try stepping into this decade?
-
@SpectateSwamp said:
Thats why I keep lots of notes and have a search that can show me them. No matter how large my file gets. So sad the others have size limits. They all do. I have proved that. MPS found a site stating as much. A lapse in memory isn't that much of a problem, if you have a good Search for your notes.
You are the only person harping on about size limits, probably because you are the only person who insists on storing everything in one large file. This is probably why you are also the only person who confuses desktop searching with searching a file.
-
@spenk said:
You are the only person harping on about size limits, probably because you are the only person who insists on storing everything in one large file. This is probably why you are also the only person who confuses desktop searching with searching a file.
A lot of the 'common users' I encounter don't even know what a txt file is. "You mean like something in Word?"
-
Net search is not Desktop Search - Ask any Greppler/Searcher
@MasterPlanSoftware said:
Yeah but look at the way he has continually redefined Desktop Search, indexing, etc in this thread.
Not redefined. Net Search is as far as from Desktop Search as you can get. Grep and Vax search were the first desktop search. Net search had to have file size limits or they would run out of space on the first massive site it encountered. They force everybody to keep Itsy Bitsy files. They don't find data in context they find FILES. Most do a very poor job of hi-liting text once they do find it. (a key element of a good search is showing you the data with hi-lites). Searching is about seeing the data. Hearing the data. Viewing the data.
-
@SpectateSwamp said:
Do a 2 page flowchart of the hi-lite and line wrap logic of a search.
Speaking of which, could you re-do the flowcharts? These flowcharts are next to useless because they describe code at low level, not logic or functionality in broad terms - as every programmer knows, diagrams that are essentially duplicates of the code are bloody useless, but diagrams that describe the structure and functionality are heck of a tool for telling people what the code does. Stuff like
II = LEN(AA)is particularly useless because it takes original code with its incomprehensible variable names! The purpose of the diagram is to communicate the code to the others - common sense should tell you that if people find the code confusing, you shouldn't shove it back to their faces with a few lines and boxes drawn around them!So, instead of
MATCH_FLAG="NO"it should say "clear match flag", Instead of massive walls of incomprehensible string chopping, say "spammilate the echidnas and kill a country" or whatever the heck the stuff is supposed to do, etc. If there are variables referenced, there should be a list of them somewhere. You can even use different names than the ones in code as long as you document it: "NoBP is the name of current President of Bolivia (which has quite a lot to do with highlighting the matches, believe it or not). In actual program, we used XXX."Also, hand-written stuff is usually, er, hard to read. There's plenty of free diagram tools out there (Dia, for example, is pretty damn good for flowcharts, and there's a Windows version apparently).
-
Desktop search is searching your computer for a term you enter. Your program doesn't do that. It only searches the file you tell it to.
Therefore, it is not desktop search. As soon as you get that through your thick, rotten melon we might be able to move a little further. Your program doesn't even have the functionality of notepad's find function.
-
@WWWWolf said:
There's plenty of free diagram tools out there (Dia, for example, is pretty damn good for flowcharts, and there's a Windows version apparently).
Visio (MS office) works well.
-
@SpectateSwamp said:
Congratulations Swamp, you've just comprehensively disproved the adage "a picture is worth a thousand words".
Good god man... if your logic is THAT convoluted, it's a pretty safe bet that it's wrong. And that's JUST to work out if a string should be HIGHLIGHTED??? You've even invented your own new letters! WTF???
-
@rc_pinchey said:
<PicSnipped />
@SpectateSwamp said:
Congratulations Swamp, you've just comprehensively disproved the adage "a picture is worth a thousand words".
Good god man... if your logic is THAT convoluted, it's a pretty safe bet that it's wrong. And that's JUST to work out if a string should be HIGHLIGHTED??? You've even invented your own new letters! WTF???
OH MY GOD I can't stop laughing!
-
@SpectateSwamp said:
Grep and Vax search were the first desktop search.
Tools designed primerily for searching inside files, not searching for files.
@SpectateSwamp said:
Net search had to have file size limits or they would run out of space on the first massive site it encountered
Not a relevant point when talking about desktop searching as these tools are not searching or indexing the web.
@SpectateSwamp said:
They force everybody to keep Itsy Bitsy files.
They do not force anyone to do anything, in most cases words and terms searched for are of a high relevance and will often be the document's title or near the start - search terms in excess of 10,000 words into a document is the exception rather than the rule for most people.
@SpectateSwamp said:
They don't find data in context they find FILES.
Well done, you seem to finally realise what a desktop search tools is for - locating files!!!!
@SpectateSwamp said:
Most do a very poor job of hi-liting text once they do find it. (a key element of a good search is showing you the data with hi-lites). Searching is about seeing the data. Hearing the data. Viewing the data.
Err, no - searching for files is about finding the files, highlighting text etc. is a function for a tool that searches inside of files.
-
The ClueLess get more video training.
@MasterPlanSoftware said:
@bstorer said:
It's been over seven hours since his last post. What happened, did someone unplug him?
This usually happens when he is out 'walking the dogs by the creek'.
My theory is he uses the time to stalk (hunt) children.
Even I need a break from talking Desktop Search. I tend to get carried away with some of the dumb questions. I need time to determine what the next video should SHOW off. Be more offensive instead of defensive. Kinda
-
-
SSDS Not having to worry about file names.
@Spectre said:
That new fangled 6 too many changes for me. This is play and we are all learning about Desktop Search here. Some more than others. Some very funny stuff to. Maybe the best video show is FLASH that is the "f" option at prompt #2. set the hilite_this elements and let it rip on thedailyWTF,txt file. You'll see hilites and speed. The pause will be set to very short maybe (.4) I'll show off this wonderful way to show off because I'm a showoff. And because you poor buggers can't look at this thread with any real POWER. You'll see what SSDS can do. You just wait and wait.The game is unfair. The only way to win is not to play.
And, IIRC, Swampy did his abomination in VB5, not 6.
-
@WWWWolf said:
@CodeSimian said:
If the Holy Bible (or Bill of Rights, or Magna Carta, or Declaration of Independence, or <insert you favourite sacred document here>) were a wiki, Swamp would be all over it.
Erm... they are...
Uh...slightly clever. But I meant LITERALLY wikis, not "documents created by collaboration" or "living documents", in the sense Spectate could go and edit them right now, over the Internet.
-
@SpectateSwamp said:
You'll see what SSDS can do. You just wait and wait.
Do you understand that nobody cares?
Maybe it would make more sense if I say it this way: Do you understand understand. Nobody cares cares cares.
-
Swamp gives you the Power over data
@MasterPlanSoftware said:
Just read through any of his longer thread (here, channel 9, etc) you will see it happen constantly.
Some of my best posts are long gone. The video lessons I gave drew a lot of heat. and the discussions were wild. Then they disappeared. Too bad.
If you have a good joke then use it. Maybe even over use it.
-
@SpectateSwamp said:
If you have a good joke then use it. Maybe even over use it.
They are laughing laughing laughing AT you. Not with you
-
@SpectateSwamp said:
Some of my best posts are long gone. The video lessons I gave drew a lot of heat. and the discussions were wild. Then they disappeared. Too bad.
Come on, don't give us that.. I'm sure you must have archived your best material in a gigantic text file.
-
Swamp Search is a Super Greppler
@spenk said:
could any of the 15 even search for a file?
The file info is secondary information that shows up in the form border at the same time matches are hi-lited on the screen.
-
@CodeSimian said:
@WWWWolf said:
@CodeSimian said:
If the Holy Bible (or Bill of Rights, or Magna Carta, or Declaration of Independence, or <insert you favourite sacred document here>) were a wiki, Swamp would be all over it.
Erm... they are...
Uh...slightly clever. But I meant LITERALLY wikis, not "documents created by collaboration" or "living documents", in the sense Spectate could go and edit them right now, over the Internet.Uh, never mind WWWWolf. I just realized what you meant, and I feel pretty stupid. My bad.
-
Re: SSDS Not being able to search for files.
@SpectateSwamp said:
And because you poor buggers can't look at this thread with any real POWER.
So other than seeing this thread in colour, with all graphics intact, being able to search it directly from the top of the page itself, follow the 'In reply to' link to see which post a response is in follow up to, browse tags to narrow down searches, display the posts as a threaded view and also be able to reply directly - what power are we lacking? Or is cutting and pasting 38pages (by hand) into one big file is now defined as power?
@SpectateSwamp said:
The pause will be set to very short maybe (.4) I'll show off this wonderful way to show off because I'm a showoff.
THAT DOESN'T EVEN MAKE SENSE YOU RETARD.
@SpectateSwamp said:
spenk:could any of the 15 even search for a file?The file info is secondary information that shows up in the form border at the same time matches are hi-lited on the screen.
</p><p></blockquote> <br></p><p> THAT DOESN'T EVEN MAKE SENSE YOU RETARD.Or answer my question come to that.<br></p>
-
Swamp Search Shows Off
@Albatross said:
Great I think I can see the 3 main prompts and the error handling at the end. cool. Maybe this isn't the Lazy Forum.
-
@CodeSimian said:
Uh, never mind WWWWolf. I just realized what you meant, and I feel pretty stupid. My bad.
It was entirely my fault, I should have been clearer.
-
Swamp search makes big files small
@fist-poster said:
Since we already know the interesting thing is at the end of the file (and we know that all interesting and sensitive data is at the end of large files) where's the point?
I'll encrypt the data with the cript command at prompt #2. No encription expert in their right mind would look that far. Large files are not so large for Swamp search.
-
Swampy PWNED by his own words and challenge.
@SpectateSwamp said:
I get shit for the same answers so sometimes I spice it up a bit. But anyway back to your search of a random file. Test this out for me. How fast is your computer at reading data from your disk without searching Just reading from start to end of file.
Ok. I generated a file that's exactly 2,388,888,897 bytes long. That's 2.3 gigabytes. It's got a simple format:
This is line XXX. Here's some more text to make the file even bigger, even though this text is repeated every line
where is the actual line number (so it goes "This is line 1...", "This is line 2", etc..).
So here's some info on the file:
File size, the first line, and the last line:
marc@panic:~$ ls -l swamp.txt
-rw-r--r-- 1 marc marc 2388888897 2008-02-14 18:24 swamp.txt
marc@panic:~$ head -1 swamp.txt
This is line 1. Here's some more text to make the file even bigger, even though this text is repeated every line
marc@panic:~$ tail -1 swamp.txt
This is line 20000000. Here's some more text to make the file even bigger, even though this text is repeated every lineI'll assume you mean a page to be 24 lines of text, so here's how long it takes to display the last 24 lines of text in that file:
marc@panic:~$ /usr/bin/time tail -24 swamp.txt
This is line 19999977. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 19999978. Here's some more text to make the file even bigger, even though this text is repeated every line
[... to keep this post short, I'm deleting the next few lines...]
This is line 19999999. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 20000000. Here's some more text to make the file even bigger, even though this text is repeated every line
0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+208minor)pagefaults 0swapsIt took 0.00 seconds to do that. In other words, it's so fast, and the time span so small, you need more than two decimal places to express the number. Of course, that's not a fair test, because tail is smart enough to open the file FROM THE END and count backwards. Let's try something harder...
How about the 24 lines from 1,000,000 to 1,000,024?
marc@panic:~$ /usr/bin/time head -1000024 swamp.txt|tail -24
This is line 1000001. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 1000002. Here's some more text to make the file even bigger, even though this text is repeated every line
[... deleting the middle lines. again, to keep things short ...]
This is line 1000023. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 1000024. Here's some more text to make the file even bigger, even though this text is repeated every line
0.22user 0.12system 0:03.53elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+205minor)pagefaults 0swapsNot bad. 3.53 seconds to scan through the first 1,000,024 lines and display the last 24 of those. That's approximately 114 megabytes of data, in 4 seconds, or around 34,000,000 characters per second. Well above your magical 20,000,000
Now, let's see how long it takes grep to find all lines with the number '9' in it. Note that the time stated will be the time scan the ENTIRE file, and remember that we're looking for '9', so the first hit will be at line 9, and show up instantly.
marc@panic:~$ /usr/bin/time grep 9 swamp.txt|wc -l
4.41user 3.00system 0:52.51elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+247minor)pagefaults 0swaps
10434062So. 52.51 seconds, to find 10,434,062 lines of results. That's 52.51 seconds to scan 2.3gigabytes, or approximately 45,493,980cps, more than DOUBLE your magical 20,000,000cps. Of course, I didn't display all 10 million results and paste them here. That would be stupid. But had I not filtered the results through the 'wc' (word count) program, I would have seen all 10 million lines flash by, just the way you like.
In case you start complaining about me having a faster machine, here's the specs:
AMD Athlon 64 3000+ (2 GHz)
2 gigabytes of ram
IBM 120gigabyte ATA driveAn average machine. It's about 5 years old now, I think. Maybe a bit less. Definitely not "top of the line" anymore. And you'll note that my test file is LARGER than the amount of ram in the system, so there's no way the file could be cached - which means grep and head and tail have to scan the entire thing FROM DISK every time.
@SpectateSwamp said:
Is it somewhere in the 20,000,000 cps range? If it is then you'll have proved that I'm not Gee Hawing you
So, my worst result was around 30,000,000cps, and my "best" result was 45,400,000cps. Is that Gee Hawing you? Or will you finally now admit that you're spewing bullshit through that beard of yours? SSDS is not "the fastest". It's merely the fastest that YOU'VE bothered to test.
Oh, and here's one more test. Call it a freebie. How long does it take grep to find the line with the "12345678" text on it? And display 4 lines of context before and 5 lines of context after it?
marc@panic:~$ /usr/bin/time grep '12345678' -A 5 -B 4 -m 1 swamp.txt
This is line 12345673. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345674. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345675. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345676. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345677. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345678. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345679. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345680. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345681. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345682. Here's some more text to make the file even bigger, even though this text is repeated every line
This is line 12345683. Here's some more text to make the file even bigger, even though this text is repeated every line
1.12user 1.06system 0:31.91elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+252minor)pagefaults 0swaps31.9 seconds, to scan through around 1.4gigabytes of text to find that match, or in other words 46,441,421cps. Wow. a new record. Oh, and it only used 6% of the available CPU power. In other words, this is a disk-bound operation. A faster computer won't help unless you put in a faster harddrive.
Here's the script I used to generate the swamp.txt test file. It's very easy. A VB expert like you can no doubt reproduce it in only a few years:
#!/usr/bin/perl
open($fh, '>swamp.txt');
for $x (1 .. 20000000) {
print $fh "This is line $x. Here's some more text to make the file even bigger, even though this text is repeated every line\n";
}
close($fh);
-
@SpectateSwamp said:
@MasterPlanSoftware said:
Just read through any of his longer thread (here, channel 9, etc) you will see it happen constantly.
Some of my best posts are long gone. The video lessons I gave drew a lot of heat. and the discussions were wild. Then they disappeared. Too bad.
If you have a good joke then use it. Maybe even over use it.
THAT DOESNT EVEN MAKE SENSE YOU RETARD.
-
@SpectateSwamp said:
No encription expert in their right mind would look that far.
Hmm...let's see. So I should hide all my money underneath my bed, because NO BURGLAR IN HIS RIGHT MIND WOULD LOOK THERE.
-
@SpectateSwamp said:
I'll encrypt the data with the cript command at prompt #2. No encription expert in their right mind would look that far. Large files are not so large for Swamp search.
Not only is putting the data at the end of the file stupid, your alleged encyption routine (cript) is woefully inadequate and wouldn't stand up under any serious (or semi serious) attempt to break it. Then again given the cript.txt file and the source code nobody would even need to break your encryption; they already know everything required to decrypt the data.
-
Swamp can do big files
@insta said:
I have another challenge for you. The terms and conditions are very clear.
I'll have to pass on that challenge for a bit. I'm too busy making videos. Like I have said. Search is much more than finding the text. or replacing it. Try the rrr (search and replace) option at prompt #2 yourself. If you win. I'll believe you.@insta said:
I will go as far as mailing you a DVD of the exact data he wants you to search through, as I can understand dialup / some DSL is slow.
Thanks for the offer. But someone out there should be able to search this file with SSDS. If there are any matches in the file they will show. If there are lots of matches in the file they will show up fast, as the matches will be scattered throughout the file.
-
@SpectateSwamp said:
I'll have to pass on that challenge for a bit. I'm too busy making videos. Like I have said. Search is much more than finding the text. or replacing it. Try the rrr (search and replace) option at prompt #2 yourself. If you win. I'll believe you.
Like you passed on all the other challenges....
-
Swamp Search will be big.
@MasterPlanSoftware said:
You have a few search lessons to learn yet. Then maybe we could use you up here at Swamp Shack. You have shown some initiative. Every company could use Swamp search to help them share data. The potential is incredible.Alright Swamp I just finished the project I was working on. I am ready to take on SSDS if you still need help. My normal rates and fees apply. How will you be paying for this?
-
@SpectateSwamp said:
@insta said:
I will go as far as mailing you a DVD of the exact data he wants you to search through, as I can understand dialup / some DSL is slow.
Thanks for the offer. But someone out there should be able to search this file with SSDS. If there are any matches in the file they will show. If there are lots of matches in the file they will show up fast, as the matches will be scattered throughout the file.That's not going to happen, because as far as I'm aware NO-ONE on this forum has yet managed to get SSDS to actually work. This forum, full of professional coders, passionate technophiles, people with a genuine interest in software engineering and a real aptitude with computing, this forum of all forums and no-one can get SSDS to work.
This really should be ringing warning bells somewhere in that beard of yours. It's like taking a new design of dog harness to a sledding race and finding out none of the teams can figure out how to put it on a dog or attach it to the sled.
If you want to prove SSDS works, you will have to either a) tell us how to make it work or b) show us it working. You're incapable of a, and unwilling to try b, which leaves only option c- mercilessly and relentlessly mocking you.
-
@SpectateSwamp said:
Every company could use Swamp search to help them share data. The potential is incredible.
You still did not answer my question: Considering that you worked on IT projects for libraries, how come no library uses SSDS? As of 1993, you worked in "data processing data data processing" for 22 years, right?
Show me one corporate customer who adopted SSDS.
And you still did not acknowledge the link I gave you to the Outlook Express archiver, despite running your mouth off about the need for it.
-
Swamp will crush competition
@CodeSimian said:
And you still did not acknowledge the link I gave you to the Outlook Express archiver, despite running your mouth off about the need for it.
You did good I'll make a comment on my email archiver rather than cut and paste into inmail.txt and outmail.txt I'll use this great extract.Now I can search for anything in the above line and have the information at my fingertips. I don't care how big this file gets. Swamp search just soaks it up.
@CodeSimian said:
Show me one corporate customer who adopted SSDS.
That won't happen untill SSDS has met and Crushed the challenge from GDS CDS WDS and YDS. Then you'll see lots of our little app. People already have it in their hands. I'm sure some of you are far smarter than me and can take this program a long way.
-
@Spectre said:
@insta said:
I know damn well where the text is, the whole point of the exercise is to see if Joe Q Random on TDWTF forums can write a faster sequential file search. I'm trying to find something tangible that we can compete against him on. Of course the search giants are all in cahoots with Microsoft so Windows will make their lookups faster, but VB6 vs VB6 should be pretty clear cut, no?
Unfortunately, the dialog will probably go as follows:
insta: Hey, Swampy, I made this über-cool linear search app, and it searches 3 times faster than SSDS, check it out!
SpectateSwamp: You poor sob. It doesn't. Random Video .Video PlayBack is fun. I can videoin the YellowHead meetings like on a vax.
insta: <Huh? Typity typity typity> OK, it does random video now.
SpectateSwamp: Spectate Search shows scrolling text. Fun. You CONTROL your DATA. Just enter enter enter and you last page and press ql.
insta: <WTF? Typity typity typity> Fine, now it does scrolling text too.
SpectateSwamp: You don't know horseshit. Geeky grepplers. I challenge. DesktopSearch makes it simple. InstaSearch not simple. Not massy enough.
insta: <? Typity typity typity> Now, my search looks and behaves exactly as yours, but actually works.
SpectateSwamp: Don't undersatnd. What Masses need. A visit to Swamp Shack required. Day or two. Then type gf at prompt 6 quantumleap and schnapps. Context. Not willi-nilly indexers. Welcome InstaSwamp.
insta: THAT DOES NOT EVEN MAKE SENSE YOU RETARD
SpectateSwamp: <ignores>
insta: <face'o'table>
The game is unfair. The only way to win is not to play.
And, IIRC, Swampy did his abomination in VB5, not 6.
OMG ROFLMAO! This is absolutely the funniest post in this thread so far! LOL!
-
@SpectateSwamp said:
@Albatross said:
Great I think I can see the 3 main prompts and the error handling at the end. cool. Maybe this isn't the Lazy Forum. *sigh*
"I think I can see the 3 main prompts and the error handling?"
"I think I can see the 3 main prompts and the error handling?"
You know what happened when I fed my latest awful application through an automated code graphvisiuliazion package?
Like they said in... some damn thing (one of those frequently mutated phrases that no one really remember where they came from): "That's not a code diagram. This is a code diagram."
I think I can see the main class, data representation, and UI classes.
(I'm not saying mine is perfect; no associations are show here, for example, and the fields are full of junk you don't need to know about, like all private methods. The code hasn't been cleaned up and probably has some redundancy that I didn't need. I'm in middle of a big refactoring.)
-
Grepplers have speeds up to 45,000,000cps (45 books a second)
@MarcB said:
So, my worst result was around 30,000,000cps, and my "best" result was 45,400,000cps. Is that Gee Hawing you?
I like your numbers. Yours is 2 times faster than mine. When I display the last screen of a file I just read the line with no action then the next and next until the end of file and do it a second time. Starting the display right before the end of file. I can't make it read any faster than that. Check the source.txt. It is just a read in side a loop. How could I possibly be doing anything to slow down my reads by half? How. It sould be nice to see your grep results hi-lited. Those are Great numbers Greps are tremendous No file size limits for Greps. Confirmed and at speeds even faster that 20,000,000
So large file sizes and search speeds are not a problem. For grepplers like MarcSwamp and Me
-
@SpectateSwamp said:
When I display the last screen of a file I just read the line with no action then the next and next until the end of file and do it a second time.
Umm..... what? You physically read each line of a file until you hit the end? Then do it all over again? Do you sit there and hit enter a zillion times to reach the end of the file? Or do you mean you have SSDS read to the end of the file? Either way, if that's how you read the last line in a file, then SSDS will lose the race every single time, because you can't beat 0 seconds.
@SpectateSwamp said:
I can't make it read any faster than that.
Yes, you could. But it would mean changing your precious source code, and invalidate your precious flow charts.
@SpectateSwamp said:
How could I possibly be doing anything to slow down my reads by half?
You're using Visual Basic. And version 5 at that. It's not a "fast" language. Even if it does come as a .exe, it's still interpreted line-by-line by the visual basic runtime (all those .dlls you have to install just to be able to run your .exe). And then your code is, to put it very very mildly, highly unoptimized. Just because you can read a line of text using one line of visual basic code doesn't imply AT ALL that what's happening in the background is efficient. VB is a piece of highly stinky diarrhea for anything that requires high performance. Your one line of code is actually a few hundreds or thousands of lines of code inside VB's guts.
@SpectateSwamp said:
It sould be nice to see your grep results hi-lited.
Why? Is it really so hard to look through one line of results to find the string you were searching for? Particularly in my example file, where the only thing we were looking for is a number, and that occurs near the beginning of the line anyways? If you're searching for someone's email address by the person's name,how is SSDS supposed to know it should highlight the email address? It can't, because you're searching for a name. It'll highlight the name instead, which is THE WRONG DATA.
@SpectateSwamp said:
For grepplers like MarcSwamp and Me
I'm not a greppler, and you're definitely not. SSDS compared to grep is the same as comparing a mosquito to a Boeing 747. They're not anywhere close to being in the same class. I just use whatever tool is appropriate for the task at hand. In this case, grep fit the bill nicely.
Your only tool is a hammer (SSDS), so everything looks like a nail (textfile). I've got an entire toolbox filled with useful stuff, only one of which is a hammer (grep). I use the appropriate tool for the job, so if I've got a screw, I'll use a screwdriver. You'll just pound in the screw with your hammer and claim the screw is really just a nail.
-
@SpectateSwamp said:
So large file sizes and search speeds are not a problem. For grepplers like MarcSwamp and Me
It has been demonstrated several times in this thread (including in MarcB's results) that it can take minutes for grep or SSDS to search for something, while indexed search applications can give results in less than a second. A minute is longer than a second. You would know this if you weren't an idiot.
-
@SpectateSwamp said:
Holy crap! I just endured a project that was "designed" just like that! Are you freelancing random software designs now?
-
@SpectateSwamp said:
You have a few search lessons to learn yet. Then maybe we could use you up here at Swamp Shack. You have shown some initiative. Every company could use Swamp search to help them share data. The potential is incredible.
No thanks then. I offered. Too late.
That was your one and only chance to have ANYONE work on SSDS EVER.
I guarantee.
-
@SpectateSwamp said:
@CodeSimian said:
Show me one corporate customer who adopted SSDS.
That won't happen
Indeed. That is the truth.
-
@MarcB said:
@SpectateSwamp said:
How could I possibly be doing anything to slow down my reads by half?
You're using Visual Basic. And version 5 at that. It's not a "fast" language. Even if it does come as a .exe, it's still interpreted line-by-line by the visual basic runtime (all those .dlls you have to install just to be able to run your .exe). And then your code is, to put it very very mildly, highly unoptimized. Just because you can read a line of text using one line of visual basic code doesn't imply AT ALL that what's happening in the background is efficient. VB is a piece of highly stinky diarrhea for anything that requires high performance. Your one line of code is actually a few hundreds or thousands of lines of code inside VB's guts.
Oh come on! I am hardly a fan of VB5 or 6 but you saying SSDS is slow OR a piece of crap because of VB is just ignorant. SSDS is a piece of crap because an idiot coded it. He could achieve comparable speeds by not 'reading' and processing every line in a file and not having AWFUL code strewn all over like he has.
Anyone here should be able to pick up VB5 or VB6 and write an algorithm with output comparable to your results.
SS never will though. But you cannot blame his hammer. It is his fault that all he knows how to do is hit his thumb.
