SpectateSwamp:

This forum is just getting too long for other searches to bring up quick results

Google has already done the work for you.  Don't have to make large index file.  Just type in Google.  Google filters by site without copy/paste.

There are nine posts in this thread that use the word "performance."  Find them all.  Go!

Done.

GalacticCowboy:

There are nine posts in this thread that use the word "performance."  Find them all.  Go!

Crap, now there are ten.  Or eleven.

Or 62...  :) when I push the "Include omitted results" link...  Congratulations, self, you are your own TRWTF.

SpectateSwamp:

So That is where the next set of video is going. SSDS internals explained. I'll go through the code at the important points. Where and how changes can be made.

Or you could document and clean up the source so it is understandable.

SpectateSwamp:

I might even go over the changes required to make SSDS do a LIVE search of text files. (fiddle with the merge option to redirect the merge info to the logic where SSDS reads from the input file)

Will this include handling multiple folders?

SpectateSwamp:

When you got spaghetti code. You'll need a little help

A lot. Of help.

 

SpectateSwamp:

So That is where the next set of video is going. SSDS internals explained. I'll go through the code at the important points. Where and how changes can be made. I might even go over the changes required to make SSDS do a LIVE search of text files. (fiddle with the merge option to redirect the merge info to the logic where SSDS reads from the input file) It will be slower but that is what people here are screaming for. All on shaky shaky video. Sit close to your monitor for these lessons. When you got spaghetti code. You'll need a little help

 

But nobody wants to make those changes for you.  As far as I can tell, nobody here wants to use your application and nobody wants to help you improve it. There are already plenty of ways to do non-indexed search of text files besides SSDS.  Most of them search through multiple files and directories: jEdit (hypersearch), grep, Microsoft Visual Studio, Windows Search (non-indexed), "find" (Windows command line equivalent of grep; works with Unicode), etc.

And most applications already have a nice interface for searching their own data: e.g. EverNote, Outlook Express, Adobe Acrobat Reader, Thunderbird (mail client), etc.

Why do we need SSDS again?

CodeSimian:

 And explain to me why I wouldn't just use a program like EverNote to organize and search my plain text and web notes.   Explain why people pay money to use EverNote but nobody cares about SSDS?

Thanks for pointing that one out. I'd never seen it before. I'm giving the free version a go. If it turns out to be good, I'll register it (50% discount currently in effect).

EPIC THREAD!!

Full of EPIC FAIL

spenk:

Will this include handling multiple folders?

A list of folders would be cool. Just skip that directory. If it doesn't match one on the list. Currently the program will "merge" all files on c: or c:\search\ etc but a list of selected folders wouldn't be hard to add. I'll probably just do the c:\ or c:\search\ searches first. Might start with an even simpler fix/change. Control.txt element 31 is the hilite_this element. If a match is found in any of the context lines it is hilited in a different color (cmd(29) has the color). It is not searched for or hilited if it is in the match line. How best to fix this minor problem? I'll make the changes before explaining it. None of the other searches have a hilite_this element. One can use the hilite_this element to hide certain words. By setting the hilite color in 29 to MATCH the background color in control element #3 With both cmd(3) and cmd(29) being set to 3 (aqua) any hilite_this strings would appear as blank spaces in the middle of the text. SSDS is a tool to plow through your data. Not just slowly presenting 1 file match at a time.

Another test. 100 matches in 100 files somewhere on c drive and in text. Who would have them up on the screen the fastest. Indexing and merging times included. SSDS presents the text in context. It would be just a matter of hitting enter 100 times after the merge was done. Like in 5 minutes I would be done done done. You would have to tell your indexers which folders to ignore or it would be days and days later. Indexers tell you what files your search string is in. Pick a common one and the list is overwhelming. SSDS will show the matches in context or matching lines only for even faster verification. Indexing searches suck and the showdown will hilite these and other glaring weaknesses.

Search is about the context. Not the file name where the context is. The indexers will show your a few lines from the beginning of the match file and if the string is there hilite it. It can't look any farther otherwise it would slow tremendously.

 

 

SpectateSwamp:

Search is about the context. Not the file name where the context is. The indexers will show your a few lines from the beginning of the match file and if the string is there hilite it. It can't look any farther otherwise it would slow tremendously.

 

 

 

Fine, you want to search text files with context, highlighting, and the ability to press a key (or click a button) to jump to the next match?  Here you go - Notepad++:

http://notepad-plus.sourceforge.net/commun/screenshots/scrsh_findAll.gif

If I wanted to, I could copy and paste all 30+ pages of this thread into a plain text file and use Notepad++ to search it.  Notepad++ is more powerful, easier to use and doesn't require any keyboard commands or shortcuts.  Explain to me why I should use SSDS instead of Notepad++ to do your kind of searching.

Nobody needs your product because there are a million more useful and simpler alternatives.

CodeSimian:

Explain to me why I should use SSDS instead of Notepad++ to do your kind of searching.

Reasons for SSDS? Random. Large font scrolling text. Pause then continue on a page full. HiLite_this element. Masking characters with aqua in cmd(29). I had just reloaded the most recent forum posts. Including the note on aqua. Extracts are a useful (part of the extract-sort-report trio) Multiple sessions of this search with the defaults and search history that apply to that topic or project. 8 or 20 data files instead of TENS of Thousands. Now to me, when documents never get printed again And I Can't scan them in context because I have an indexer. One will seldom looks at files, if it is a problem moving to the next file then the next match in that file search again don't find a match go to the next itsy bitsy file. You won't do that long before you quit searching. For me it's enter search string and enter enter enter everything in context and extremely fast. more than extremely fast even.

SpectateSwamp:

A list of folders would be cool. Just skip that directory. If it doesn't match one on the list. Currently the program will "merge" all files on c: or c:\search\ etc but a list of selected folders wouldn't be hard to add. I'll probably just do the c:\ or c:\search\ searches first. Might start with an even simpler fix/change.

 

Not just a list of one or two folders but entire directory trees.

SpectateSwamp:

Another test. 100 matches in 100 files somewhere on c drive and in text. Who would have them up on the screen the fastest. Indexing and merging times included. SSDS presents the text in context. It would be just a matter of hitting enter 100 times after the merge was done. Like in 5 minutes I would be done done done. You would have to tell your indexers which folders to ignore or it would be days and days later. Indexers tell you what files your search string is in. Pick a common one and the list is overwhelming. SSDS will show the matches in context or matching lines only for even faster verification. Indexing searches suck and the showdown will hilite these and other glaring weaknesses.

Given you currently only support searching one file at a time the claim of a 100 matches in a100 files is nonsense, WDS will happily find search terms in the 36,000+ items I have with virtually no delay whatsoever.

Why would I be waiting days if I didn't ignore folders with an automatic index based search (as opposed to your manual index process) - 36,000 items isn't more than a handfull of hours and it happens quietly in the background without my time being wasted manually merging files...

SSDS shows you the file your search string is in - it is in the file you told it to search. How would it help you to locate the file file(s) that contained the search string?

What on earth does 'show the matches in context' actually mean anyway? 

As to claiming index based searches suck you are missing two vital points - one is many years of development and study have proved that index based searching is quicker and secondly you use an index based search anyway, the only difference is you require the user to build the index themselves, file by file by file.

SpectateSwamp:

CodeSimian:

Explain to me why I should use SSDS instead of Notepad++ to do your kind of searching.

Reasons for SSDS?

<snip> 

8 or 20 data files instead of TENS of Thousands. 

</snip> 

 

You have it all backwards.  SSDS doesn't allow me to have 8 or 20 data files instead of thousands - SSDS forces me to merge all my data into 8 or 20 files.  It's not a feature, it's an onerous requirement.

For the millionth time, NOBODY WANTS TO MERGE ALL THEIR FILES TOGETHER and no other search program forces them to.

SpectateSwamp:

Masking characters with aqua in cmd(29).

 

So it finds the search term in the specified file but then doesn't display it???

SpectateSwamp:

8 or 20 data files instead of TENS of Thousands.

You are forcing me to only have 8 or 20 files regardless of how I want to work. How can I maintain my source code as 8 or 20 files?

SpectateSwamp:

And I Can't scan them in context because I have an indexer. One will seldom looks at files, if it is a problem moving to the next file then the next match in that file search again don't find a match go to the next itsy bitsy file. You won't do that long before you quit searching. For me it's enter search string and enter enter enter everything in context and extremely fast. more than extremely fast even.

Most of that doesn't even make sense. What on earth does scan them in context mean? How can finding the term in the original file be out of context? It isn't a problem moving to the next file either - you just double click on it. Who cares if the file is small, I have source files that just define an interface that may be only one or two kilobytes - that however allows me to organise my source files as I choose to. I would have no benefit merging these into one large file.

 

 

I forgot to mention SSDS doesn't choke or slow down on larger files. ie 2m to over 1Gig. The Itsy-bitsies don't keep lots of clippings in one file. They have to split up on a one per article basic. Their indexing search is just too slow displaying files of any size. Probably by now copernic will take 25 seconds to get a match at the end of this forum up and in context. Try this number Mr Copernic 388205283 The wonderful SSDS search will show it to you in less than a second. Others can verify this quite easily. Does nobody want to try it? Maybe SSDS is even faster and Copernic worse than expected. Do I have to do another video. Another feature is instant search default changes at prompt #2 'ccc' uses the settings in control1.txt instead of control.txt.

When Desktop Search is your only program, It has to have all the options this one has.

SpectateSwamp:

I forgot to mention SSDS doesn't choke or slow down on larger files. ie 2m to over 1Gig.

 

Then explain http://forums.thedailywtf.com/forums/p/7593/144805.aspx#144805

SpectateSwamp:

The Itsy-bitsies don't keep lots of clippings in one file. They have to split up on a one per article basic.

Could you please try to manages sentences - they make reader comprehension so much easier, but what the fuck does 'The Itsy-bitsies' mean? What or who is having to split up on a one per article basis? What does that even mean?

SpectateSwamp:

Their indexing search is just too slow displaying files of any size. Probably by now copernic will take 25 seconds to get a match at the end of this forum up and in context. Try this number Mr Copernic 388205283 The wonderful SSDS search will show it to you in less than a second. Others can verify this quite easily.

You still haven't proved this without cheating, if you are benchmarking SSDS we need to see you do it from a cold boot and without you pre-reading the file in.

SpectateSwamp:

When Desktop Search is your only program, It has to have all the options this one has.

For most people desktop search isn't their only program, it is the program they use to search for files. It isn't even your only program as you rely on media player for your mp3 and video playback.

 

spenk:

I would have no benefit merging these into one large file.

Come on SpenkSwamp do it just to humor me. Merge all your source files (but don't delete the originals) SSDS has no feature to delete merged files. Then start looking for anything that pops into your mind code wise. Let the whole mess flash by, by using the "f" for flash mode at prompt #2. The search will show all text on the screen until a match is found. Enter a number that doesn't exist in the file and all your source code will flash by. Stop and restart it by hitting enter. Play with and examine your source like never before. How many meg of combined source. How many lines of info. What is the elapsed time for a 'y' showing the last screen full of text.

spenk:

And I Can't scan them in context because I have an indexer

I should have used view instead of "scan" ie "scan them visually in context because indexers can't do that at an acceptable speed. They just can't. Swamp search can.

SpectateSwamp:

Come on SpenkSwamp do it just to humor me. Merge all your source files (but don't delete the originals) SSDS has no feature to delete merged files. Then start looking for anything that pops into your mind code wise. Let the whole mess flash by, by using the "f" for flash mode at prompt #2. The search will show all text on the screen until a match is found. Enter a number that doesn't exist in the file and all your source code will flash by. Stop and restart it by hitting enter. Play with and examine your source like never before. How many meg of combined source. How many lines of info. What is the elapsed time for a 'y' showing the last screen full of text.

 

But why? I can happily search my code now without having to merge hundreds of files into one just to watch code flash by. So watching code flash past is examining my code? Admittedly I have never done that before, probably due to the fact I have tools that can do analysis of my code, display meterics about my code, refactor my code, allow me to skip back and fore between declarations and calls. I can even compile it!

What benefit does having two copies one of which is merged into a useless large file give me? 

SpectateSwamp:

Enter a number that doesn't exist in the file and all your source code will flash by.

 

HAHAHAHA so it is going to make you display the whole file even when it doesn't find anything??

Brilliant! Spectate, you seem to be getting dumber by the post...

spenk:

you rely on media player for your mp3 and video playback.

I see no calls to media player in the source code. I see mcisendstring commands that control the video and music. Any OS worth it's salt would have a similar utility.

http://www.telusplanet.net/public/stonedan/source.txt

 

spenk:

if you are benchmarking SSDS we need to see you do it from a cold boot and without you pre-reading the file in.

Can't anybody else take a stab at searching thedailyWTF.txt text file for this thread? I know you can all whip up a batch file that will merge this and that, yappity yap. Just go in and cut and paste 31 times and it will be done. Then do some simple testing to see who can display the data the fastest (SSDS) and Not so fastest (Copernic)

SpectateSwamp:

I see no calls to media player in the source code. I see mcisendstring commands that control the video and music. Any OS worth it's salt would have a similar utility.

 

Do you think MCISendString is invoking some kind of magic?

SpectateSwamp:

Can't anybody else take a stab at searching thedailyWTF.txt text file for this thread? I know you can all whip up a batch file that will merge this and that, yappity yap. Just go in and cut and paste 31 times and it will be done. Then do some simple testing to see who can display the data the fastest (SSDS) and Not so fastest (Copernic)

Nobody here is stupid enough to do this except you. The rest of us have at least the minimal intelligence level to be able to type what we want in the search box and press enter. You can never claim to be faster than that.

Did you do a lot of drugs in your younger years?

 

SpectateSwamp:

spenk:

if you are benchmarking SSDS we need to see you do it from a cold boot and without you pre-reading the file in.

Can't anybody else take a stab at searching thedailyWTF.txt text file for this thread? I know you can all whip up a batch file that will merge this and that, yappity yap. Just go in and cut and paste 31 times and it will be done. Then do some simple testing to see who can display the data the fastest (SSDS) and Not so fastest (Copernic)

 

You are losing it here - you are claiming to out perform copernic with ssds but stacking the deck in your favour and not running a fair test. What this has to do with cut and pasting this forum is beyond me.f you are trying to find the post in question, rather than cut and paste I shall use the forums own search box, don't go away...

 

...and I'm back http://forums.thedailywtf.com/forums/p/7593/147518.aspx#147518 was the link. Your had pre-loaded / pre-configured ssds so it didn't need to open the file and perform a full search. That is not a fair benchmark and no sane person would treat it as one.

 

 

spenk:

due to the fact I have tools that can do analysis of my code, display meterics about my code

If I added up all the tools you people have for doing this and that function better than SSDS. It would be quite a list. Thankfully Swamp search is the tool to search out such info. Very fast to move through mountains of Search Facts like this post.  

SpenkSwamp do us a demo using Cam Studio and settings like I used. So everything is blurry. We'll trust you. Your source code should be your secret. Then a few simple searches on that merged file looking for subroutine calls, error handling, what ever. You will move through your source very fast. How many lines of code do you have? Not nearly enough to cause Swamp search to even pause. I bet.