[brailleblaster] Re: Start of Editor
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Sat, 13 Nov 2010 15:21:56 -0800
Hi John,
Thanks for getting back to me so quickly.
No problem. I am not worried.
I just meant that it should be kept on the radar that some machines that are
becoming popular among blind people has relatively low specs. That is all.
I did however not read the rest of the thread when I had sent my message and
the later messages in this thread clarified things.
Regards,
Alex,
On 2010-11-13, at 2:46 PM, John J. Boyer wrote:
> We will look at using less memory as development continues. After we get
> a fairly complete version of tghe editor we will have a better
> understanding of just how much memory is needed. There are also memory
> compactgion techniques which have been mentioned on this thread. Not to
> worry for now.
>
> John
>
> On Sat, Nov 13, 2010 at 02:35:35PM -0800, Alex Jurgensen wrote:
>> Hi John,
>>
>> Notmachine to bring down the party or anything, but these kinds of specs may
>> just bring down one of my testing machines just because the default
>> configuration of this unit only has 512 MB. Since a lot of blind users I
>> know have a machine with this configuration, do you think hat we can set a
>> maximum limit lower on a per-machine-type basis when when package it? I have
>> seen machines with 256 MB of RAM work exceptionally well for screen readers,
>> but those are fading quickly from the market place. However, the
>> configuration I speak of, with 512 MB, may continue to be a standard
>> measurement of computing power for some blind individuals and I would be
>> concerned that the program would be able to drag these machines down. I
>> don't mean that they would crash or anything, but that memory may become
>> scarce and therefore not be efficient to use with Braille Blaster unless a
>> lower limit can be set for these machines.
>>
>> I'm not sure if I am being clear.
>>
>> Regards,
>> Alex,
>>
>>
>> On 2010-11-13, at 6:24 AM, John J. Boyer wrote:
>>
>>> After thinking some more, I agree with you. In our scripts which call
>>> the Java runtime we can simply specify minimum memory as 200 MB and
>>> maximum memory as 500 MB.
>>>
>>> John
>>>
>>> On Sat, Nov 13, 2010 at 08:54:46AM -0500, Sina Bahram wrote:
>>>> 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
>>>>
>>>>
>>>>
>>>
>>> --
>>> My websites:
>>> GodTouches Digital Ministry, Inc. http://www.godtouches.org
>>> Abilitiessoft, Inc. http://www.abilitiessoft.com
>>> Location: Madison, WI, USA
>>>
>>>
>>
>> Alex Jurgensen,
>> VoiceOver Trainer,
>> ASquared21@xxxxxxxxxxxxxxxxx
>>
>> Visit us on the web at: www.vipbc.org
>>
>
> --
> My websites:
> GodTouches Digital Ministry, Inc. http://www.godtouches.org
> Abilitiessoft, Inc. http://www.abilitiessoft.com
> Location: Madison, WI, USA
>
>
Alex Jurgensen,
VoiceOver Trainer,
ASquared21@xxxxxxxxxxxxxxxxx
Visit us on the web at: www.vipbc.org
Other related posts:
