#14786 - 21/08/2000 19:04
upload sort order?
|
journeyman
Registered: 21/08/2000
Posts: 62
|
I'm digging through the souce for the emptool program under Linux, trying to make it upload my files in alphabetical order. (I have all my mp3's prefixed by the track number, like 01_song.mp3, 02_song.mp3, etc. If they get uploaded in alphabetical order, they get played in the proper order...)
It seems like all the "bad hoodoo" is happening in the BranchStackList class after the directory gets scanned - it looks like the order in which items are popped off of this Stack (and hence uploaded to the unit) does not necessarily reflect the order in which they are pushed on. In the meanwhile I am digging through the code further to find out how to make the bad things stop happening, does anyone have any advice (or better yet, a quick patch) on getting the uploads/syncs to keep an alphabetical order when they get pushed into the empeg? (I've already changed the call to scandir() to call alphasort() as its sorting function, so the filenames *are* being read off the filesystem in the right order.) Booting Windows to reorder playlists sucks, but so does uploading a file at a time so they stay in proper order. :P
|
|
Top
|
|
|
|
#14787 - 21/08/2000 19:35
Re: upload sort order?
[Re: dglidden]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
I don't understand. I have never seen Emplode screw up the order of the songs. The only thing I've seen screw up the order of the songs is Windows, as you drag a group of files and drop them onto Emplode. Emplode takes the songs in whatever order Windows Explorer serves them up, as detailed by this post. In the case of dropping directories onto Emplode, it takes them in whatever order they exist on the hard disk, verifiable by the DOS "dir" command (and that's rarely alphabetical). But if you weren't talking about Windows and Emplode, um, sorry, I'll shut up now. ___________
Tony Fabris
|
|
Top
|
|
|
|
|
#14788 - 21/08/2000 19:43
Re: upload sort order?
[Re: tfabris]
|
journeyman
Registered: 21/08/2000
Posts: 62
|
No worries. Yeah, I'm talking about using "emptool" under Linux, which is a dramatically different beast than "emplode" under Windows. It's all command-line, and looks a heckuva lot like a bash prompt (or a "C-prompt" for non-UNIX weenies :) except that all your directories and files represent playlists and songs. You upload files by using the absolutely prehistoric method of typing in "upload /mp3/artist/album/*" all by hand. And we UNIX weenies like it like that. :)
And of course, since the source code is available, I can break it any old way I feel like. (I'd just rather not have to re-write a substantial portion of it, but since those BranchStackList things are just all over the place, I have the feeling it might take that kind of effort.)
|
|
Top
|
|
|
|
|
#14789 - 21/08/2000 21:09
Re: upload sort order?
[Re: dglidden]
|
journeyman
Registered: 21/08/2000
Posts: 62
|
My bad, it's not the "BranchStackList" that's returning items out-of-order, its the DirectoryEntryList iterator. Time to read up on STL list iterators I suppose...
|
|
Top
|
|
|
|
|
#14790 - 21/08/2000 21:45
Problem solved
[Re: dglidden]
|
journeyman
Registered: 21/08/2000
Posts: 62
|
In empconsole.cpp ExpandShellGlob I changed the scandir function to use alphasort and around line 1230 now reads:
try {
direntrylist.insert(direntrylist.end(), DirectoryEntry(name, full_path.c_str()));
total ++;
// it++;
}
previously the insert had been written like:
try {
direntrylist.insert(it, DirectoryEntry(name, full_path.c_str()));
total ++;
it++;
}
It's not immediately obvious to me why this way would work, (or why that iterator is in there at all, since nothing else except the insert touches it, I don't know that stepping through the list after an insert by incrementing it is the Right Thing To Do since I don't know what value it would take in relation to the list as it is originally set to a value pointing to the end of an empty list, it's not even necessary to use it as the above code demonstrates, and it gets set to different value as soon as ExpandShellGlob is done) while the changes I've made seem to work for me as expected. Unless someone can explain to me why it was written the way it was, I'm going to pretend it was a bug. :)
|
|
Top
|
|
|
|
|
#14791 - 22/08/2000 08:44
Re: Problem solved
[Re: dglidden]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Unless someone can explain to me why it was written the way it was, I'm going to pretend it was a bug.
The intent was to let you use several filenames, possibly with wildcards, such as 'foo bar* wurdle' and have it process 'foo bar1 bar2 wurdle' in that order. With your changes it would append the wildcard results to the end and result in 'foo wurdle bar1 bar2'. Note that L.insert(L.end(),X) is the same as L.push_back(X).
However, the original code was wrong too. The insert method inserts before the iterator, and insert on lists doesn't move iterators, so the it++ was bogus. Try just removing that...
|
|
Top
|
|
|
|
|
#14792 - 22/08/2000 20:05
Re: Problem solved
[Re: peter]
|
journeyman
Registered: 21/08/2000
Posts: 62
|
Only removing the it++ does in fact work. Thanks! I haven't followed the code around enough to know exactly what's going on yet, and STL didn't exist the last time I worked in C++ so I'm still trying to get up to speed with both the code and STL semantics.
There's another buglet in GetBaseFile that causes segfaults if you upload a directory with a trailing "/". I've only just glanced at it but it looks like when it parses a path/filename with the trailing "/" it returns a pointer to beyond the end of the path string?
|
|
Top
|
|
|
|
|
#14793 - 22/08/2000 23:44
Re: Problem solved
[Re: dglidden]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Argh. If I see one more string pointer/bounds bug...
Okay, question of the day. What would you do if you had a time machine?
Some would go back and play the winning lottery numbers. Others would do historical research and meet their favorite historical figures. Others would try to change history for the better and prevent wars or other tragedies.
Me? I'd go back in time and locate the man responsible for leaving a genuine string data type out of the original C implementation. I'd put a gun to his head and force him to get off his lazy ass and write a string data type with built-in memory management and bounds checking. He wouldn't be allowed to let C out into the wild until he'd done this.
If you counted up all of the crashing bugs in C programs and totaled them, I'd say at least fifty percent of them wouldn't have happened if it weren't for the fact that you must do your own pointer/bounds management for strings in C. I have seen more bugs related to C string pointers than any other bug.
___________
Tony Fabris
|
|
Top
|
|
|
|
|
#14794 - 23/08/2000 10:27
Re: Problem solved
[Re: tfabris]
|
Pooh-Bah
Registered: 09/09/1999
Posts: 1721
Loc: San Jose, CA
|
Don't forget security issues. :) Many exploits have been committed due to bounds overruns lately.
Calvin
|
|
Top
|
|
|
|
|
#14795 - 23/08/2000 10:46
Re: Problem solved
[Re: eternalsun]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Don't forget security issues. :) Many exploits have been committed due to bounds overruns lately.
No kidding! You're right. Although many of those were just Denial of Service attacks which crashed the driver where the overrun landed. But yeah, some crafty guys have inserted jumps into the overrun data. That crap scares me.
___________
Tony Fabris
|
|
Top
|
|
|
|
|
#14796 - 25/08/2000 01:13
Re: Problem solved
[Re: tfabris]
|
addict
Registered: 30/04/2000
Posts: 420
Loc: Sunnyvale, CA, USA
|
Me? I'd go back in time and locate the man responsible for leaving a genuine string data type out of the original C implementation. I'd put a gun to his head and force him to get off his lazy ass and write a string data type with built-in memory management and bounds checking. He wouldn't be allowed to let C out into the wild until he'd done this.
You are barking up the wrong tree, Tony. Don't blame C, blame the incompetent programmers. It's possible to write bad code in any language... If you want automatic string management and bounds checking use Pascal or Java or whatever. C is a low-level language, it allows you to write efficient code but it also allows you to shoot yourself in the foot. Use with care.
Borislav
|
|
Top
|
|
|
|
|
#14797 - 25/08/2000 08:52
Re: Problem solved
[Re: tfabris]
|
member
Registered: 08/06/2000
Posts: 144
Loc: Ft Lauderdale, FL
|
Buffer overflow is the number one vulnerability in most *nix programs. Just ask my (deceased) mp3 server at work.
Thank god for single user mode. Recovered all 21 gigs without a loss...
-Trevor
-----
Mk 2, Green 12GB 080000349
_________________________
-Trevor
-----
Mk 2, Green 12GB, Tuner, 2.0b11, 080000349
|
|
Top
|
|
|
|
|
#14798 - 25/08/2000 09:40
Re: Problem solved
[Re: borislav]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Don't blame C, blame the incompetent programmers.
I knew someone would come back at me with that.
Let he who is without sin cast the first stone. I don't think there's a single C programmer (competent or incompetent) who hasn't trashed a string pointer or overwritten a string bounds.
Sure, every single programmer who's ever made that mistake smacks themselves in the forehead and blames themselves. But think of all the saved foreheads there'd be if C had a proper string data type.
___________
Tony Fabris
|
|
Top
|
|
|
|
|
#14799 - 25/08/2000 10:21
Re: Problem solved
[Re: tfabris]
|
member
Registered: 08/05/2000
Posts: 135
|
In reply to:
Sure, every single programmer who's ever made that mistake smacks themselves in the forehead and blames themselves. But think of all the saved foreheads there'd be if C had a proper string data type.
A modern programmer is one that only uses C when he has to. :) At one time, C was the only language WORTH using.
Large projects in C quickly turn into a bad thing. It is more time consuming, more prone for errors, etc. Using Visual Basic, Delphi or some other higher level language is a much better idea, and creating DLLs or ActiveX components in C to use in VB/Delphi WHEN you need to is a good thing (or at least better).
I personally vouche for using C ONLY when what you are writing is time critical/must run in real time, or if there isn't any other language that will do it appropriately. C strings are good because they are fast (in some cases). A large bloated string class may not be acceptable some times.
Many a project would be much better if they just didn't use C to begin with. Some programmers are more concerned with "which language is better", that they only use C and hurt themselves for their own stupidity.
There is a tool for every kind of product. In modern application programming, C maybe is better used as a tool for creating "building blocks" that other "safe" tools can use.
Anyway, my opinion 
Kureg
|
|
Top
|
|
|
|
|
#14800 - 28/08/2000 02:46
Re: Problem solved
[Re: tfabris]
|
addict
Registered: 30/04/2000
Posts: 420
Loc: Sunnyvale, CA, USA
|
Let he who is without sin cast the first stone. I don't think there's a single C programmer (competent or incompetent) who hasn't trashed a string pointer or overwritten a string bounds.Guilty as charged.  Sure, every single programmer who's ever made that mistake smacks themselves in the forehead and blames themselves. But think of all the saved foreheads there'd be if C had a proper string data type.... and strong typing and array bounds checking, etc. The thing is, there is a need for a language that doesn't have all these features because they carry a performance penalty, C fills this space. I have to agree with Kureg, though, many projects currently written in C are better off using something else... The thing that prompted my initial comment (about the incompetent programmers) is that a lot of those mistakes can be easily avoided (even in C) with good programming discipline. All it takes is to always check your buffer sizes, function return values, etc. Regards, Borislav
|
|
Top
|
|
|
|
|
#14801 - 28/08/2000 08:00
Re: Problem solved
[Re: borislav]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
The thing is, there is a need for a language that doesn't have all these features because they carry a performance penalty...Yeah, they have one. It's called assembly language. Actually, if C had both a string data type as well as char arrays, then you could use the char arrays when you needed the speed, and the string data type when you needed the safety. ___________
Tony Fabris
|
|
Top
|
|
|
|
|
#14802 - 29/08/2000 01:33
Re: Problem solved
[Re: tfabris]
|
pooh-bah
Registered: 13/09/1999
Posts: 2401
Loc: Croatia
|
Yeah, they have one. It's called assembly language.Tony, C is but a structured assembly Dragi "Bonzi" Raos Zagreb, Croatia Q#5196, MkII#80000376, 18GB green
_________________________
Dragi "Bonzi" Raos
Q#5196
MkII #080000376, 18GB green
MkIIa #040103247, 60GB blue
|
|
Top
|
|
|
|
|
|
Previous Topic
Index