[brailleblaster] Re: Start of Editor

  • From: "Sina Bahram" <sbahram@xxxxxxxxx>
  • To: <brailleblaster@xxxxxxxxxxxxx>
  • Date: Sat, 13 Nov 2010 08:54:46 -0500

Memory compaction can actually happen for free depending on what technologies 
we use. Also, I wouldn't worry too much about this
because these kinds of optimizations can be performed once the product is 
complete.

Don't forget the entropy in this data is so low so as to almost be considered 
partially ordered E.G. more than 50% compression
ratios on any arbitrary subsection.

Take care,
Sina

-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx 
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
Sent: Saturday, November 13, 2010 2:11 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Start of Editor

What I want to do is make the value of the index attribute more compact before 
it is incorporated into the DOM tree. Take the
following example. 
Suppose we have a paragraph for which the braille translation is 500 characters 
long. For each of these characters we have a decimal
number followed by a comma. Taking only the characters above position 100, each 
will correspond to four characters iin the attribute
value. Each of these four characters will be translated into a 16-bit (two 
byte) character in the string representing the value.
This will result in 400
* 4 * 2 bytes needed to represent this attribute. I've been entertaining the 
possibly wild idea of converting the decimal number at
each position to a short and then putting all these shorts together into a new 
string which would replace the old. This would
require only 800 bytes. 
Subsequent processing would also be easier, since the program would need to 
only convert the string into a char array and athen
index through it. 
Of course, such a string would have to be reconverted to the original on output.

I'm perhaps overly concerned about memory usage. My estimate is that an 
ordinary document could take over 100 MB of memory. Large
ones might take twice that. Compaction of the index attribute would reduce this 
by maybe two-thirds. If we don't compact we should
assign about 400 MB to the JVM.

John
 
On Fri, Nov 12, 2010 at 08:48:22PM -0500, Sina Bahram wrote:
> Modifying that code is not how you'd want to go about doing this.
> 
> You'd want to either hook in externally, through published and 
> accepted means, or simply do the processing on the dom where such semantics 
> are more clearly available anyways.
> 
> Take care,
> Sina
> 
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx 
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. 
> Boyer
> Sent: Friday, November 12, 2010 8:24 PM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Start of Editor
> 
> Thanks for the info. I'm still just a beginning Java programmer, so i 
> have some wild ideas. What I was thinking of was using Sax to modify 
> some things before JDOM builds the parse tree. For example, putting the value 
> of the index attribute on the <brl> tag in a more
compact and easily-processed form.
> 
> John
> 
> On Fri, Nov 12, 2010 at 08:08:26AM -0800, Chris von See wrote:
> > I would be interested to hear more about why you want to modify JDOM.   
> > I've built many parse trees and other similar structures using the 
> > SAX callbacks documented in the "org.xml.sax" package in the JDK; if 
> > you're using Java 6 you can also use the stream-oriented StAX 
> > classes in the "javax.xml.stream" package, which may be a bit easier 
> > to deal with.  In both cases you'd be using SAX or StAX to read the 
> > input tree and JDOM to build your parse tree instead of modifying 
> > the tree built by JDOM, which is a little bit more work but IMO much 
> > cleaner and easier to maintain.
> > 
> > Cheers
> > Chris
> > 
> > 
> > 
> > On Nov 12, 2010, at 12:27 AM, John J. Boyer wrote:
> > 
> > >A few weeks ago I sent the eclipse.swt TextEditor as an attachment. 
> > >On this message I am attaching SAXBuilderDemo.java from the JDOM 
> > >samples directory. I also resending TextEditor.java for your 
> > >convenience. I think that we can combine these two to get a start on our 
> > >editor.
> > >
> > >One thing I would like advice on is the copyright notice that 
> > >should appear at the beginning of each class. I could copy the 
> > >liblouis copyright notice with appropriate changes, but you will 
> > >notice that the authors already have some conditions that they wish 
> > >respected. We will be modifying their code, of course. We may also 
> > >want to dig down to the SAX level so we can modify the parse tree 
> > >as it is being built. This will mean modifying a few classes in 
> > >JDOM itself. Eclipse may also have some conditions on the reuse of their 
> > >code.
> > >
> > >Please give your comments and suggestionsj regarding the copytight 
> > >issue.
> > >
> > >Thanks,
> > >John B.
> > >
> > >--
> > >John J. Boyer; President, Chief Software Developer Abilitiessoft, 
> > >Inc.
> > >http://www.abilitiessoft.com
> > >Madison, Wisconsin USA
> > >Developing software for people with disabilities
> > >
> > ><SAXBuilderDemo.java><TextEditor.java>
> > 
> > 
> 
> --
> My websites:
> GodTouches Digital Ministry, Inc. http://www.godtouches.org 
> Abilitiessoft, Inc. http://www.abilitiessoft.com
> Location: Madison, WI, USA
> 
> 

--
John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities



Other related posts: