BEncode Editor

[jewelisheaven]

[03:58:15] [bDecode] Start: "O:\µTorrent\resume.dat"

[03:59:09] [bDecode] End (54.320 seconds)

[03:59:09] [TreeView Fill] Start

[04:03:42] [TreeView Fill] End (230.571 seconds)

[04:06:36] [bDecode] Start: "O:\µTorrent\Beta\TAS\resume.dat.old"

[04:06:47] [bDecode] End (11.864 seconds)

[04:06:52] [TreeView Fill] Start

[04:07:52] [TreeView Fill] End (55.125 seconds)

TreeView doesn't work as fast/efficient as before (same files). Did you enforce some bounding check? It uses ~ 14-23% less processing power now. For comparison BDecode uses up to 87% and TreeView only uses up to 63%.

Also Ctrl-C takes a couple times to register, and seems to require a right click in the window (which doesn't do a thing) to make it work.

Edit: I'd be happy to test our your streaming as long as I know of an hex editor which deals fine with content. The one I use shows boxes as well as extended ASCII so I don't want to chance corruption. Also pre-existing data like binary keys from the BFE can't be exported because it's already as 0xFFFFFF style, not actual binary data.

Edit: OOOH! I see export, then Ins, raw bencoded, from file... nifty function. How do you want me to stress test it?? The log only show the functions BEncode BDecode and TreeView

[Ultima]

Using accelerator tables has made the hotkeys (sometimes) less responsive (meaning that they don't always work every single time -- it may take several presses).

Yep, I noticed there was an issue. Even though I said it was preferable to the "hacky" nature of global hotkeys, it began to get on my nerves as well. I'm more or less set to revert to global hotkeys again, with the difference now being that before BEncode Editor starts doing something that keeps it busy, I unhook all the hotkeys. It was the alternative I was going to take before I remembered the accelerator table stuff. I'm actually done with the reverting, but I also have one last idea I'd possibly like to mess with before finalizing my decision.

I didn't intentionally make any changes that would cause a slowdown, but as I noted before, implementing the double-click feature has caused a general slowdown in treeview performance. I wouldn't be surprised if implementing accelerator tables slowed things down further because of the way I have to intercept accelerators.

I was planning on adding logger messages for some more things, but forgot to. In the end, there isn't much speed benchmarking needed to be done with those features anyhow, as they should only be as fast (or slow?) as encoding and decoding usually are. I'm just not 100% sure if I implemented everything correctly

As for which hex editor you should use... I'm not sure either, as I don't really do much hex editing (like, ever ). I seriously doubt a display issue would cause data corruption in a hex editor, as hex editors are meant to be used for manipulating a file's raw, uninterpreted bytes.

I'm not really understanding what you mean by export not working for existing data... A simple test shows that it exports data just fine O.o If there's something wrong, more details would be nice

[GTHK]

Some things I noticed, after loading a file, binary strings in a list will show a character count after the edit button is pressed followed by ok, and will also be shown for recently added strings, and using replace all causes the character counts being shown of edited strings to disappear, the reload button also removes character counts.

Also, I found importing bencode data quite handy

[Ultima]

Heh, that's the kind of bug I was expecting, but couldn't really find in my own tests Thanks; I've fixed it in my build

[Ultima]

Another WIP... Hopefully, this will be it.

[snip]

Changes since last WIP...

- log imports/exports too

- fix that funky display bug GTHK noticed (should hopefully not be a problem anymore, since almost everything now uses one function to generate treeview text)

- changed back to global hotkeys, but disable when it's about to perform an operation that might keep it busy

There might also have been some other stuff I forgot, but I'm too lazy to check

In terms of performance difference, I'm not really sure anymore, because I'm getting different (mixed) results between tests. I haven't consciously done anything to affect performance, but I wouldn't be surprised if there are difference (particularly, slowdowns, just because I'm suspicious of my changes' "optimized-ness" ).

Feedback!

[jewelisheaven]

If you've already checked the new build with my resume, there's not much else testing for optimized-ness (What other kind of testing would you like to be done?)

Well I manually save streams ...I'm trying to find a way to USE the raw data... the editor I have doesn't seem to handle CR / LF well when in binary mode

Feature Request: Have exported data save by default as whatever extension you choose.. I manually typed in FILENAME.Bencode (just because ) Also please be changing the version information in all available places. I know .4 doesn't have the Item menu, but pretty please.

[GTHK]

Changing a dictionary into a list or vice-versa wipes the contents of said item . Also, trying to expand/collapse an item too quickly will bring up the edit dialog for the currently selected item. No other problems beside that. Also, what's the difference between the Unicode build and ANSI build? Is one for foreign systems?

That aside, good work .

[Ultima]

Wiping of data is to be expected. I'm not sure how anyone would expect the translation from dictionary-to-list or list-to-dictionary to behave, and honestly, I don't see any reason (really) why one would want to convert a dictionary to a list As for the expand/collapse thing... yep, I know, but there isn't much I can do about it.

Unicode builds can display Unicode characters (like Asian languages), and work only on Windows 2000 and above. ANSI builds can't display Unicode characters properly, but work on Windows 9x and above.

@jewelisheaven: Hm. I was considering stripping the bencoding off of the exported data, but then it would make it kinda hard to re-import while retaining the data type (binary vs integer). I could always add another menu item, but uh, I'm not liking the thought of it (just because).

I'm not really sure what you mean by the extension thing and the version information thing. Finally, regarding the testing... since the performance measures vary from computer to computer, having more people test the differences would be nice. Take my last bit of optimization for example: I only measured a 15% gain, but you (somehow) measured 30-50%.

[GTHK]

It was for the import raw data from file option, I imported a list of trackers but it was in a dictionary instead of a list :X

[jewelisheaven]

... announce-list is a list, not a dictionary.

[GTHK]

I know, that's why I tried to change the dictionary into a list, causing the loss of its contents.

[jewelisheaven]

If the export is adding stuff, that's a bug. Are you sure you only exported the list key?

[GTHK]

I didn't say export, I imported data :/, the main issue being that before import and export where added I created a bencode file with some trackers each in its own tear. However the root dictionary got in the way when I imported the data, so I tried changing it into a list, at which point the editor discarded the data.

[Ultima]

If you create a dedicated bencoded tracker list file, then you better be sure to edit the ROOT item and make it a list instead of a dictionary before you actually start adding the tiers/trackers.

A conversion after the fact is non-obvious and ugly. I actually used to have some warning about the potential data loss when something like this happened (in the readme?)... Meh.

[jewelisheaven]

I went through 3 torrents when I manually tried to hack together my own torrents... uT doesn't handle multi-line comments, and I forgot to put in multiple trackers. When possible ALWAYS let the torrent creator use the primary tracker announce and the tracker list announce-list.... otherwise you have a HIGH likelihood of problems. I'll do some testing speedwise... and with the hotkeys to verify they turn "off"

[Ultima]

Heh, I managed to squeeze another ~20% of performance gains out of treeview filling. If you're curious, you'll find the Unicode build here to play around with.

I really want get 0.5 out the door and off my chest, but don't want to end up fixing more stupid little bugs I may have made in a quick fix build, so I keep holding off the "final" :|

[jewelisheaven]

Is it possible to re-add (or add if I'm thinking of torrentspy.sf.net) the number of sub-ROOT keys to the top? it's useful for a quick check of a resume.dat or whatever... if it was corrupted at the end, or if there's extra keys appended..

0.5.1 - WIP

[09:34:24] [bDecode] Start: "O:\µTorrent\resume.dat"

[09:35:23] [bDecode] End (59.026 seconds)

[09:35:23] [TreeView Fill] Start

[09:38:57] [TreeView Fill] End (176.401 seconds)

[09:49:45] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

[09:49:56] [bDecode] End (10.722 seconds)

[09:50:29] [TreeView Fill] Start

[09:51:02] [TreeView Fill] End (27.728 seconds)

0.5.2 - WIP

[09:30:12] [bDecode] Start: "O:\µTorrent\resume.dat"

[09:31:14] [bDecode] End (62.425 seconds)

[09:31:14] [TreeView Fill] Start

[09:33:06] [TreeView Fill] End (111.096 seconds)

[09:51:38] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

[09:51:48] [bDecode] End (10.664 seconds)

[09:51:48] [TreeView Fill] Start

[09:52:06] [TreeView Fill] End (17.265 seconds)

I was wondering if for the save dialogs you could auto-recommend some extension (I use .bencode since I made that extension associated with BFE for ease of use/import)... that's all

As far as version information.. your exe and all boxes (about for ex) still list this as .5 even though as I've listed above, I consieder the first wip from a month ago to be 0.5.1 and the new build to be 0.5.2.

In any case, yep better filling, and faster load time. I would like to point out something changed as far as inputting the data, you'll see one of them loads the whole file at once, and the other loads it in 1 MiB chunks.

Nice progression in featureset.. are you holdingoff on a "final" .5 becuase you don't plan to revisit it for a while??

[Ultima]

I've never had a count in the [ROOT] key, though I've once considered it. I didn't really felt like adding it, but I'll consider.

A default extension gets a big *shrug* from me (meaning I'm not sure, and that it might take a bit more convincing to get me to add it ). Or maybe a bit more pondering of my own might get me a decision -- I dunno. I don't really like the idea of pushing any particular extension at users (as easily changed as it may be). That then leaves the question of "can you let the user choose then?", in which case I'd shake my head at as well, since I kind want to keep the editor self-contained (meaning no direct Registry or external file access for settings storage).

I'm keeping the version number at 0.5 because I haven't declared 0.5 to be "stable" yet -- otherwise, it'd be on the first post. These WIPs are test builds just the same as alpha/beta/RC builds would be test builds. Just like µTorrent's 1.8 alpha is moving toward a 1.8 stable, these 0.5 WIPs are moving toward a 0.5 stable. I'm not planning on leaving the editor as is by 0.5, but I just feel like I won't be able to predict the amount of free time I'll have, so I want to get 0.5 done right. Well, actually, just because I'm somewhat of a perfectionist (just a bit ;D), I also wouldn't like seeing b0rked 0.5 build being labeled "stable" without some further testing.

So um, even if you consider the previous WIPs to be 0.5.x, I still consider them to simply be 0.5 candidates

This is what my Process Explorer graphs look like when I load your resume.dat:

It's always looked like this between every single version I've checked, so I don't know what to say about it behaving differently each time for you. Just like before, I haven't consciously done anything to affect file reads. It might be the compiler update. Or something. In the end, the update factored in just a little bit in the treeview filling performance improvement over the previous WIPs (probably something along the lines of ~5%), so bleh. The manner in which it's reading the file shouldn't affect much (as long as it's not being retarded and hitting the drive constantly with tiny requests), so I think it can be easily ignored.

[jewelisheaven]

Fair enough Uhm, did you remove the Ctrl-R hotkey? I can only get files to reload (re fill treeview) by clicking the arrow... Ctrl-S on the other hand works no matter where I am, and performs BEncode on the currently open file.

I'm still trying to muck with export / import to see specific steps / behaviours being done which are not desirable... I just like the fact I can post-process my torrents with BFE to give them that extra touch

Is that a new PE?? My graphs aren't opaque <>

[Ultima]

Not really. I'm using Process Explorer v11.04 -- a version released all the way back in November 2007 (the "latest" released version).

@jewelisheaven: F5 was actually another alias for refreshing (it did the same thing as Ctrl+R too). In the end, I decided to remove both hotkeys entirely because the feature itself (reloading) is almost never needed.

So yeah, I killed them a few weeks ago. Regarding Ctrl+S... what do you mean "no matter where [you are]"? It's saving even though you've taken focus off of the editor's main dialog? It certainly shouldn't do that... and it doesn't do that here (hotkeys get unhooked immediately after the editor loses focus).

At any rate, I just made it so that it checks for changes before continuing with a save (so it now shouldn't bother trying to save if nothing has been added/edited/removed). Interesting one to miss... silly me.

[Ultima]

*shrug* I'll interpret the extreme silence as a signal that there's nothing wrong with the test build...

Oh, and exporting binary data now exports the raw binary without the BEncoding.

CHANGELOG:

v0.5.0 (2008-02-14)

+ Feature: "Item" menu with associated keyboard shortcuts

+ Feature: Copy Logger tab items with Ctrl+C

+ Feature: Double-click to edit item

+ Feature: Export data from selected item

+ Feature: Import external file as binary data

+ Feature: Input raw BEncoded data directly or from an external file

~ Change: Add .torrent and .dat to dropdown list in Open/Save dialogs

~ Change: Add line breaks to the Logger tab between file opens

~ Change: Disable hotkeys when busy

~ Change: Don't allow saves when no changes have been made to data

~ Change: Faster bdecoding (~15% improvement over v0.4.1 in tests)

~ Change: Faster treeview filling (~20% improvement over v0.4.1 in tests)

~ Change: Miscellaneous Find/Replace tweaks, fixes, and polish

~ Change: Show type and item count for "[ ROOT ]" item

* Fix: "ITEM -1" when adding child list/dictionary to bottom of list

* Fix: "Reached beginning/end of document" message sometimes shown twice

* Fix: Combobox not showing options in dropdown on pre-XP systems

* Fix: Strings can replace integers in Find/Replace

* Fix: Typo in Logger entry for BEncoding

* Fix: Using "Find Next" sometimes returns focus to wrong window

DOWNLOAD:

v0.5 (Unicode): http://www.zshare.net/download/758590990435c5/

v0.5 (ANSI): http://www.zshare.net/download/758593183bd640/

Edit: v0.5.1 released here.

[rigolos]

Ultima -

thank you so much for this utility, it has saved me today from a severe danger of RSI, when moving a few hundred torrents to a different partition.

FWIW, I used v0.5 (Unicode) with no problems whatsoever.

Thanks again.

[GTHK]

Definitely a good program .

But... I don't know if this should count as a bug report or a feature request, but I noticed that binary keys wont be displayed as a string by default if it contains a "µ", I noticed this while studying PEX related messages :/.

[jewelisheaven]

Do you happen to have the old .2 ANSI or .1 versions? The zshare links don't exist anymore and I can't find my copies.

Not-surprisingly I'm seeing slight improvement between the last WIP speedwise I just wanted to make some data comparisons from inception until now... varying over data with statistical significance.

[Ultima]

Nope, I don't :|

@GTHK: Purely intentional. I opted to make it display ASCII characters only on the treeview just because when I'm displaying the data I can't be sure what's Unicode and what's raw binary data.