Hi Adam - thanks for the info . I've committed the hex editor project under trunk. Thanks again for the contribution
On Mon, May 11, 2009 at 11:28 AM, Adam Pilkington < pilkington.a...@googlemail.com> wrote: > Yes, you are right in that the viewer was an earlier version of the plugin > that subsequently was migrated to an editor. Apologies for not spotting > that > and tidying up the code before submitting. > > In terms of the plugin interactions between the editor and other views, the > basic theory is as follows. You right click on a core file in the navigator > view and then open it with the hex editor. Once the file is loaded you can > jump to a location within the file or search for a known pattern (either as > text or hex). Having found a point of interest, say the VM process > location, > then you add a bookmark for that location. A bookmark is currently a simple > data structure composed of the offset location within the file and a > textual > description. The bookmarks are specific to a given file whereby the view > refreshes itself so that the shown bookmarks are in sync with whichever > editor currently has the focus. The eyecatcher view is designed to > highlight > known byte sequences in the editor to aid in understanding the file > contents, for example it can highlight the magic number which describes a > dump as being in the ELF format. The idea is that you can create > dictionaires of eyecatchers which you can load and apply to a file being > viewed. However this functionality is not yet complete in the code I > contributed. > > The driving force behind the plugin is to not only provide a way of viewing > very large core files (i.e. by providing page views into the dump rather > than attempting to load it all at once as other editors do), but also to > aid > in implementing or debugging JSR 326 implementations via the bookmark and > eyecatcher views. > > I will document this fully in due course, but hopefully this gives you > enough information in the meantime. > > 2009/5/11 Steve Poole <spoole...@googlemail.com> > > > Adam - with respect to the hex viewer. There is a reference to a Raw > Byte > > View in the plugin but the code does not exist. Since you have > implemented > > an editor i assume the viewe is cruft. > > > > Could you confirm that and give me some more info about the hex viewer - > > how > > the other views are supposed to operate? Whats your basic design? > > > > thx > > > > On Fri, May 8, 2009 at 2:17 PM, Steve Poole <spoole...@googlemail.com > > >wrote: > > > > > Thanks Robert - Adam I'm looking at what you've contributed - will > > > probably have some questions soon :-) > > > > > > > > > > > > On Fri, May 8, 2009 at 1:29 PM, Robert Burrell Donkin < > > > robertburrelldon...@gmail.com> wrote: > > > > > >> On Fri, May 8, 2009 at 12:11 PM, Adam Pilkington > > >> <pilkington.a...@googlemail.com> wrote: > > >> > Hi all, > > >> > > >> hi adam > > >> > > >> > as part of the process of familiarising myself with JSR 326 and Kato > > >> > I've created a couple of Eclipse plugins that I would like to > > contribute > > >> to > > >> > the project. > > >> > > >> cool > > >> > > >> > They are usable at the moment, but not quite finished, and I > > >> > would rather have them in a source repository and continue working > > from > > >> > there rather than my hard disk :-). I've signed that Apache CLA and > > >> created > > >> > Jira items for each plugin (granting Apache the rights to the code), > > but > > >> I'm > > >> > not a committer for the Kato project and I'm not exactly sure how > the > > >> > process works from here ... ? > > >> > > >> (i'm a mentor for kato during incubation. this means i try to help > > >> kato develop into a viable self-organised community. usually, one of > > >> the committers would post something similar but IIRC this is first > > >> time so i'm going to jump in) > > >> > > >> if you haven't taken a look yet, > > >> http://www.apache.org/foundation/how-it-works.html is a good place to > > >> start > > >> > > >> hopefully one of the committers will take a look at the patch sometime > > >> soon. they should review and - if they are happy - commit it, perhaps > > >> after making a few changes. > > >> > > >> (reviewing patches promptly is really important for the health of > > >> apache projects. this is the way that new committers are recruited.) > > >> > > >> committers are elected (by the existing committer) based on their > > >> contributions. so, if you continue to submit patches (and learn from > > >> whatever changes happen to be needed) then (on the private list) an > > >> existing committer will propose your name for election. if that vote > > >> passes then you'll be invited to become a committer. > > >> > > >> - robert > > >> > > > > > > > > > > > > -- > Regards > > Adam Pilkington >
