Menu
▾
▴
applecommander-devel — AppleCommander development discussion list
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(16) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: John B. M. <tra...@gm...> - 2009-09-01 19:45:20
|
With Oliver's permission, begin forwarded message: > From: Oliver Schmidt <ol.sc@we...> > Date: August 31, 2009 4:35:56 PM EDT > To: "John B. Matthews" <matthewsj@us...> > Subject: AppleCommander > > Hi John, > > As you might be aware I'm maintaining two of the projects mentioned in > the section 'Projects' on http://www.cc65.org/links.php : Contiki and > NanoVM. > > Like I did with Contiki already quite some time ago I now added a > 'disk' goal to the NanoVM build - of course ;-) using AppleCommander > in http://nanovm.cvs.sourceforge.net/viewvc/nanovm/nanovm/vm/build/cc65/Makefile > > Just for your records... > > Best, Oliver |
|
From: John B. M. <mat...@us...> - 2009-02-25 19:33:54
|
David: Sorry, I overlooked your Gutenberg commits. Everything builds OK. I've bumped the minor revision number to 1.3.5.5 and posted a new interim release: <http://sites.google.com/site/drjohnbmatthews/applecommander> Let me know of any regressions. John On Dec 26, 2008, at 3:49 PM, David Schmidt wrote: > I ran across a pile of data disks from the Gutenberg word processor. > They have a proprietary disk format and (of course) data format. I > implemented a disk translation for it as well as text/HTML/RTF word > processing formatters. > > I implemented the "export as..." feature a little differently than the > AppleWorks from the UI perspective. It seems that AppleWorks was a > two-step process: select your formatting, then say "go." I just did > it > all in one step... picking the format initiates the save action. > > To do 1: I may need to do some more checking to make absolutely sure a > disk is in Gutenberg format to lessen the chances of falsely > identifying > it as such. > > To do 2: The Gutenberg "export as..." context menu item should > probably > lose the bounding separators it inherited from AppleWorks. They're > not > really necessary. > > To do 3: Integrate Gutenberg into the Export Wizard. But maybe not... > it's pretty busy now, and Gutenberg is likely very obscure. > > Comments welcome, as always. > > - David > > ------------------------------------------------------------------------------ > _______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: David S. <da...@at...> - 2008-12-26 20:49:20
|
I ran across a pile of data disks from the Gutenberg word processor. They have a proprietary disk format and (of course) data format. I implemented a disk translation for it as well as text/HTML/RTF word processing formatters. I implemented the "export as..." feature a little differently than the AppleWorks from the UI perspective. It seems that AppleWorks was a two-step process: select your formatting, then say "go." I just did it all in one step... picking the format initiates the save action. To do 1: I may need to do some more checking to make absolutely sure a disk is in Gutenberg format to lessen the chances of falsely identifying it as such. To do 2: The Gutenberg "export as..." context menu item should probably lose the bounding separators it inherited from AppleWorks. They're not really necessary. To do 3: Integrate Gutenberg into the Export Wizard. But maybe not... it's pretty busy now, and Gutenberg is likely very obscure. Comments welcome, as always. - David |
|
From: John B. M. <mat...@us...> - 2008-12-20 04:25:36
|
David: Sounds good. I'll get out a new release candidate, anon. I was stymied by how to handle names and directories and hex dumps. I look forward to your solution. John On Dec 19, 2008, at 10:53 PM, David Schmidt wrote: > Gents - > > I have added something John and I had been talking about for a while, > but we didn't arrive at a agreement as to what it should actually look > like. I needed a way to automatically extract all files from a > zillion > disk images, so that formed my use case for this particular thing. :-) > > So, what I've done is added a new option to ac called "-x" that will > extract all files to the current (or explicitly specified) directory: > > -x <imagename> [<directory>] export all files from image to current > working or specified directory. > > The code takes all files on an image and applies its default file > translator, then emits the files to the directory (with the preferred > file extension and everything), without regard to overwriting. > > A user still has to wrap this in a script to recurse through > directories > and/or images, but at least that user doesn't have to write an inner > loop to explicitly list and extract all files from each image. It > should save lots of java invocations. > > I'm perfectly open to feedback, and I am the first to admit my > implementation style is utilitarian when compared to Rob and John's > elegance. If this is way out of line, it's easy to pull back out. > This > is where I was headed with the "-x" idea, though. All changes are > isolated to ac.java. > > - David > > ------------------------------------------------------------------------------ > _______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel John -- mat...@us... http://sourceforge.net/users/matthewsj |
|
From: David S. <da...@at...> - 2008-12-20 03:53:17
|
Gents - I have added something John and I had been talking about for a while, but we didn't arrive at a agreement as to what it should actually look like. I needed a way to automatically extract all files from a zillion disk images, so that formed my use case for this particular thing. :-) So, what I've done is added a new option to ac called "-x" that will extract all files to the current (or explicitly specified) directory: -x <imagename> [<directory>] export all files from image to current working or specified directory. The code takes all files on an image and applies its default file translator, then emits the files to the directory (with the preferred file extension and everything), without regard to overwriting. A user still has to wrap this in a script to recurse through directories and/or images, but at least that user doesn't have to write an inner loop to explicitly list and extract all files from each image. It should save lots of java invocations. I'm perfectly open to feedback, and I am the first to admit my implementation style is utilitarian when compared to Rob and John's elegance. If this is way out of line, it's easy to pull back out. This is where I was headed with the "-x" idea, though. All changes are isolated to ac.java. - David |
|
From: John B. M. <mat...@us...> - 2008-12-16 18:19:45
|
On Dec 16, 2008, at 12:30 AM, David Schmidt wrote: > Team - > > I had the opportunity to integrate a viewer/exporter for Apple /// > Business BASIC. It's in CVS now. I built a new release candidate, 1.3.5.3 and posted it: <http://sites.google.com/site/drjohnbmatthews/applecommander> I had a small problem with the latest javadoc complaining about non- source files, which are now excluded in build.xml. Let me know if I broke anything. John -- mat...@us... http://sourceforge.net/users/matthewsj |
|
From: David S. <da...@at...> - 2008-12-16 05:30:21
|
Team - I had the opportunity to integrate a viewer/exporter for Apple /// Business BASIC. It's in CVS now. - David |
|
From: John B. M. <mat...@us...> - 2008-08-24 10:32:39
|
Team: It seems that file and volume names were getting truncated in the create wizard. As I understand it, a Text Listener sees the name _before_ the event is processed, so the last character wasn't getting appended. I also preserve names across panes, echo uppercase, and require initial-alpha on ProDOS & Pascal volume names: <http://applecommander.cvs.sourceforge.net/applecommander/ AppleCommander/src/com/webcodepro/applecommander/ui/swt/wizard/ diskimage/DiskImageNamePane.java?view=markup> I also added David's suggestion on DOS scripting to the command-line guide: <http://applecommander.cvs.sourceforge.net/applecommander/ AppleCommander/web/acguide.html?view=markup> I bumped the minor revision number to 1.3.5.2. If I haven't broken it too badly, I'll push a build out to the release candidate site. John -- mat...@us... http://sourceforge.net/users/matthewsj |
|
From: Rob G. <gr...@ch...> - 2008-08-14 11:37:49
|
Too late, but sounds fine to me too. Just for the record. ;-) -Rob -----Original Message----- From: app...@li... [mailto:app...@li...] On Behalf Of David Schmidt Sent: Monday, August 11, 2008 8:52 PM Cc: app...@li... Subject: Re: [AppleCommander-devel] Web site I'd say update it. It's convenient for folks to have. - David John B. Matthews wrote: > Team: > > In the last release, I added a link to a Google site where I put > release candidates for testers that don't care to build from cvs. > Google is telling me to transition from "googlepages" to "sites": > > Old: <http://trashgod.googlepages.com/ac> > > New: <http://sites.google.com/site/drjohnbmatthews/applecommander> > > I'm torn between updating the link or excising it. The new one is > longer but clearer. At the same time, I'm not trying to promote my > site. It's just a convenience. > > I defer to you: update or excise? > > John > -- > John B. Matthews > trashgod at gmail dot com > http://home.woh.rr.com/jbmatthews/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ AppleCommander-devel mailing list App...@li... https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: John B. M. <mat...@us...> - 2008-08-14 00:30:31
|
Done! I updated the index page on SourceForge _in_situ_ rather than overwriting the whole web archive. CVS is up to date. [Sorry about the duplicate message.] John On Aug 11, 2008, at 9:52 PM, David Schmidt wrote: > I'd say update it. It's convenient for folks to have. > > - David > > John B. Matthews wrote: >> Team: >> >> In the last release, I added a link to a Google site where I put >> release candidates for testers that don't care to build from cvs. >> Google is telling me to transition from "googlepages" to "sites": >> >> Old: <http://trashgod.googlepages.com/ac> >> >> New: <http://sites.google.com/site/drjohnbmatthews/applecommander> >> >> I'm torn between updating the link or excising it. The new one is >> longer but clearer. At the same time, I'm not trying to promote my >> site. It's just a convenience. >> >> I defer to you: update or excise? |
|
From: David S. <da...@at...> - 2008-08-12 01:52:17
|
I'd say update it. It's convenient for folks to have. - David John B. Matthews wrote: > Team: > > In the last release, I added a link to a Google site where I put > release candidates for testers that don't care to build from cvs. > Google is telling me to transition from "googlepages" to "sites": > > Old: <http://trashgod.googlepages.com/ac> > > New: <http://sites.google.com/site/drjohnbmatthews/applecommander> > > I'm torn between updating the link or excising it. The new one is > longer but clearer. At the same time, I'm not trying to promote my > site. It's just a convenience. > > I defer to you: update or excise? > > John > -- > John B. Matthews > trashgod at gmail dot com > http://home.woh.rr.com/jbmatthews/ |
|
From: John B. M. <mat...@us...> - 2008-08-12 01:00:02
|
Team: In the last release, I added a link to a Google site where I put release candidates for testers that don't care to build from cvs. Google is telling me to transition from "googlepages" to "sites": Old: <http://trashgod.googlepages.com/ac> New: <http://sites.google.com/site/drjohnbmatthews/applecommander> I'm torn between updating the link or excising it. The new one is longer but clearer. At the same time, I'm not trying to promote my site. It's just a convenience. I defer to you: update or excise? John -- John B. Matthews trashgod at gmail dot com http://home.woh.rr.com/jbmatthews/ |
|
From: John B. M. <mat...@us...> - 2008-07-04 15:35:52
|
Gents:
Here's a (primitive) script I use to back up repositories:
#!/bin/sh
DEST=/Volumes/HD2
LOCAL=ver
REMOTE1=rcsvn
REMOTE2=accvs
# Local
tar -zcvf "${DEST}"/versvn.tgz -C ~ "${LOCAL}"
# Remote1
if [ ! -d "${REMOTE1}" ]
then mkdir -p "${REMOTE1}"
fi
rsync -av robotchase.svn.sourceforge.net::svn/robotchase/* "${REMOTE1}"
tar -zcvf "${DEST}"/"${REMOTE1}".tgz "${REMOTE1}"
rm -rf "${REMOTE1}"
# Remote2
if [ ! -d "${REMOTE2}" ]
then mkdir -p "${REMOTE2}"
fi
rsync -av rsync://applecommander.cvs.sourceforge.net/cvsroot/
applecommander/* "${REMOTE2}"
tar -zcvf "${DEST}"/"${REMOTE2}".tgz "${REMOTE2}"
rm -rf "${REMOTE2}"
Watching the AppleCommander rsync reminds me: sorry about the
binaries in cvs.:-)
John
--
mat...@us...
http://sourceforge.net/users/matthewsj
|
|
From: Rob G. <Rob...@us...> - 2008-06-26 02:28:30
|
Ah, missed that! :-P -Rob -----Original Message----- From: app...@li... [mailto:app...@li...] On Behalf Of John B. Matthews Sent: Wednesday, June 25, 2008 8:59 PM To: app...@li... Subject: Re: [AppleCommander-devel] devel list anomalies; cvs v svn Is that the Mailman admin interface? I was able to log in as a regular user, but changes to my Mailman account settings don't stick. No new mail has made it to the site since 17-Jun-08, but at least we're getting turn around. They did do cvs->svn conversions for you until recently: "Due to issues with remotely running cvs2svn for end-users, we had to remove the import from SF.net CVS repostiory and CVS tarball." On Jun 25, 2008, at 6:19 PM, Rob Greene wrote: > I've noticed that the mailing list at Source Forge seem to be > stalled in > their web interface also. Not sure what's up with that. > > That's interesting that they don't convert anymore. Wonder what > the story > is there... oh, after a little looking, maybe they never did the > cvs2svn > before! Huh. > > Let me know if you need anything. We've been doing the same type > of process > at work. > -Rob > > -----Original Message----- > From: app...@li... > [mailto:app...@li...] On > Behalf Of > John B. Matthews > Sent: Wednesday, June 25, 2008 1:18 PM > To: app...@li... > Subject: [AppleCommander-devel] devel list anomalies; cvs v svn > > Gents: > > Sorry if this email has to be approved. I was surprised to see that > email from my sourceforge address bounce. I tried subscribing again, > in case the address was broken, but the list said I was already > subscribed. > > I was also hoping to be able to read threads on sourceforge, instead > of saving them locally. The latter may just be hysteresis in the > system. I see stats are broken since the move to Chicago, and there > was a spurious ssl certificate floating around, too. > > I synch'd to Rob's latest ShrinkIt changes, and eclipse easily merged > Rob's and my (non-conflicting) changes on update. Eclipse has saved > me from the vagaries of cvs more than once. I looked at moving to > svn, but they stopped doing the conversion for you, and the converter > from Tigris requires a later python than I can build. Looks like my > old PowerPCs are slated to get Ubuntu:-) ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ AppleCommander-devel mailing list App...@li... https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: John B. M. <mat...@us...> - 2008-06-26 01:58:47
|
Is that the Mailman admin interface? I was able to log in as a regular user, but changes to my Mailman account settings don't stick. No new mail has made it to the site since 17-Jun-08, but at least we're getting turn around. They did do cvs->svn conversions for you until recently: "Due to issues with remotely running cvs2svn for end-users, we had to remove the import from SF.net CVS repostiory and CVS tarball." On Jun 25, 2008, at 6:19 PM, Rob Greene wrote: > I've noticed that the mailing list at Source Forge seem to be > stalled in > their web interface also. Not sure what's up with that. > > That's interesting that they don't convert anymore. Wonder what > the story > is there... oh, after a little looking, maybe they never did the > cvs2svn > before! Huh. > > Let me know if you need anything. We've been doing the same type > of process > at work. > -Rob > > -----Original Message----- > From: app...@li... > [mailto:app...@li...] On > Behalf Of > John B. Matthews > Sent: Wednesday, June 25, 2008 1:18 PM > To: app...@li... > Subject: [AppleCommander-devel] devel list anomalies; cvs v svn > > Gents: > > Sorry if this email has to be approved. I was surprised to see that > email from my sourceforge address bounce. I tried subscribing again, > in case the address was broken, but the list said I was already > subscribed. > > I was also hoping to be able to read threads on sourceforge, instead > of saving them locally. The latter may just be hysteresis in the > system. I see stats are broken since the move to Chicago, and there > was a spurious ssl certificate floating around, too. > > I synch'd to Rob's latest ShrinkIt changes, and eclipse easily merged > Rob's and my (non-conflicting) changes on update. Eclipse has saved > me from the vagaries of cvs more than once. I looked at moving to > svn, but they stopped doing the conversion for you, and the converter > from Tigris requires a later python than I can build. Looks like my > old PowerPCs are slated to get Ubuntu:-) |
|
From: Rob G. <Rob...@us...> - 2008-06-25 22:20:12
|
I've noticed that the mailing list at Source Forge seem to be stalled in their web interface also. Not sure what's up with that. That's interesting that they don't convert anymore. Wonder what the story is there... oh, after a little looking, maybe they never did the cvs2svn before! Huh. Let me know if you need anything. We've been doing the same type of process at work. -Rob -----Original Message----- From: app...@li... [mailto:app...@li...] On Behalf Of John B. Matthews Sent: Wednesday, June 25, 2008 1:18 PM To: app...@li... Subject: [AppleCommander-devel] devel list anomalies; cvs v svn Gents: Sorry if this email has to be approved. I was surprised to see that email from my sourceforge address bounce. I tried subscribing again, in case the address was broken, but the list said I was already subscribed. I was also hoping to be able to read threads on sourceforge, instead of saving them locally. The latter may just be hysteresis in the system. I see stats are broken since the move to Chicago, and there was a spurious ssl certificate floating around, too. I synch'd to Rob's latest ShrinkIt changes, and eclipse easily merged Rob's and my (non-conflicting) changes on update. Eclipse has saved me from the vagaries of cvs more than once. I looked at moving to svn, but they stopped doing the conversion for you, and the converter from Tigris requires a later python than I can build. Looks like my old PowerPCs are slated to get Ubuntu:-) John -- mat...@us... http://sourceforge.net/users/matthewsj ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ AppleCommander-devel mailing list App...@li... https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: John B. M. <mat...@us...> - 2008-06-25 18:18:16
|
Gents: Sorry if this email has to be approved. I was surprised to see that email from my sourceforge address bounce. I tried subscribing again, in case the address was broken, but the list said I was already subscribed. I was also hoping to be able to read threads on sourceforge, instead of saving them locally. The latter may just be hysteresis in the system. I see stats are broken since the move to Chicago, and there was a spurious ssl certificate floating around, too. I synch'd to Rob's latest ShrinkIt changes, and eclipse easily merged Rob's and my (non-conflicting) changes on update. Eclipse has saved me from the vagaries of cvs more than once. I looked at moving to svn, but they stopped doing the conversion for you, and the converter from Tigris requires a later python than I can build. Looks like my old PowerPCs are slated to get Ubuntu:-) John -- mat...@us... http://sourceforge.net/users/matthewsj |
|
From: Rob G. <Rob...@us...> - 2008-06-24 03:01:09
|
I like that idea. Maybe something about NuFX too? "NufxLzwOneInputStream"? -Rob -----Original Message----- From: app...@li... [mailto:app...@li...] On Behalf Of David Schmidt Sent: Monday, June 23, 2008 5:46 AM To: app...@li... Subject: Re: [AppleCommander-devel] LZW/1 support added! Rob Greene wrote: > Good news! Very much so. > Finally, the Lzw1InputStream (note the "1") The one thing I would comment on from a code review standpoint... it's probably worth spelling out "One" here to make a better visual distinction from LzwInputStream. - David ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ AppleCommander-devel mailing list App...@li... https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: Rob G. <Rob...@us...> - 2008-06-23 21:39:07
|
Yes, there is one "test" that, well, umm, ... isn't working. More of a mess up on my part since I think I just need to pad it out (need to confirm it though). -Rob -----Original Message----- From: app...@li... [mailto:app...@li...] On Behalf Of John B. Matthews Sent: Monday, June 23, 2008 12:56 PM To: app...@li... Subject: Re: [AppleCommander-devel] LZW/1 support added! Excellent! Please use/modify CRC16 any way you need. I was hoping that it might be possible to have LzwInputStream extend CheckedInputStream (instead of InputStream), passing CRC16 in as the the cksum argument to the CheckedInputStream constructor. Then all read operations would automatically update the sum. Looks like that may not work:-) I tried to change a pair of Arrays.copyOf to System.arraycopy, but I get a JUnit AssertionFailedError in testLzwDecoder(): "Expecting end of stream expected:<-1> but was:<0>." Was it by any chance doing that before? I attached my patch, if you happen to see where I went astray. John On Jun 23, 2008, at 12:17 AM, Rob Greene wrote: > Good news! I finally started making headway with the various LZW > schemes in the ShrinkIt/NuFX format. It's actually very very > simple, but as a first time compression guy, it twisted me up for a > bit. It is pretty cool though. > > In general, as John suggested, I've been using the layered > InputStream approach which is intrinsic to Java. Seems to work > well, so far. Ironically, I haven't done that with the CRC16 > itself, as I might have to switch between data streams as a file is > decompressed. > > At the lowest level, the LittleEndianByteInputStream handles > retrieving words and the date/time format as well as the basic > byte. Yes, new name nominations will be accepted. it's a mouthful! > > Then, there is the RleInputStream and LzwInputStream the handle > compression. I created a separate BitInputStream to handle pulling > the 9-bit to 12-bit LZW codes from the wrapped InputStream. > > Finally, the Lzw1InputStream (note the "1") handles the vagaries of > the LZW/1 format (there are byte headers between each chunk of > data, etc). It actually juggles four different InputStreams as the > compression might vary between none, LZW, RLE, and LZW+RLE. > > I haven't hit a file size > 4096 bytes yet, and haven't started on > the LZW/2 format. I think the "tough" stuff has been tacked, though!! > > -Rob > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/ > index.php_______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ AppleCommander-devel mailing list App...@li... https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: John B. M. <mat...@us...> - 2008-06-23 18:23:31
|
Oh, I forgot the patch! On Jun 23, 2008, at 1:56 PM, John B. Matthews wrote: > Excellent! Please use/modify CRC16 any way you need. > > I was hoping that it might be possible to have LzwInputStream extend > CheckedInputStream (instead of InputStream), passing CRC16 in as the > the cksum argument to the CheckedInputStream constructor. Then all > read operations would automatically update the sum. Looks like that > may not work:-) > > I tried to change a pair of Arrays.copyOf to System.arraycopy, but I > get a JUnit AssertionFailedError in testLzwDecoder(): "Expecting end > of stream expected:<-1> but was:<0>." Was it by any chance doing that > before? I attached my patch, if you happen to see where I went astray. > > John > > On Jun 23, 2008, at 12:17 AM, Rob Greene wrote: > >> Good news! I finally started making headway with the various LZW >> schemes in the ShrinkIt/NuFX format. It’s actually very very >> simple, but as a first time compression guy, it twisted me up for a >> bit. It is pretty cool though. >> >> In general, as John suggested, I’ve been using the layered >> InputStream approach which is intrinsic to Java. Seems to work >> well, so far. Ironically, I haven’t done that with the CRC16 >> itself, as I might have to switch between data streams as a file is >> decompressed. >> >> At the lowest level, the LittleEndianByteInputStream handles >> retrieving words and the date/time format as well as the basic >> byte. Yes, new name nominations will be accepted… it’s a mouthful! >> >> Then, there is the RleInputStream and LzwInputStream the handle >> compression. I created a separate BitInputStream to handle pulling >> the 9-bit to 12-bit LZW codes from the wrapped InputStream. >> >> Finally, the Lzw1InputStream (note the “1”) handles the vagaries of >> the LZW/1 format (there are byte headers between each chunk of >> data, etc). It actually juggles four different InputStreams as the >> compression might vary between none, LZW, RLE, and LZW+RLE. >> >> I haven’t hit a file size > 4096 bytes yet, and haven’t started on >> the LZW/2 format. I think the “tough” stuff has been tacked, >> though!! >> >> -Rob >> >> --------------------------------------------------------------------- >> - >> --- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/ >> index.php_______________________________________________ >> AppleCommander-devel mailing list >> App...@li... >> https://lists.sourceforge.net/lists/listinfo/applecommander-devel > > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: John B. M. <mat...@us...> - 2008-06-23 17:59:13
|
Excellent! Please use/modify CRC16 any way you need. I was hoping that it might be possible to have LzwInputStream extend CheckedInputStream (instead of InputStream), passing CRC16 in as the the cksum argument to the CheckedInputStream constructor. Then all read operations would automatically update the sum. Looks like that may not work:-) I tried to change a pair of Arrays.copyOf to System.arraycopy, but I get a JUnit AssertionFailedError in testLzwDecoder(): "Expecting end of stream expected:<-1> but was:<0>." Was it by any chance doing that before? I attached my patch, if you happen to see where I went astray. John On Jun 23, 2008, at 12:17 AM, Rob Greene wrote: > Good news! I finally started making headway with the various LZW > schemes in the ShrinkIt/NuFX format. It’s actually very very > simple, but as a first time compression guy, it twisted me up for a > bit. It is pretty cool though. > > In general, as John suggested, I’ve been using the layered > InputStream approach which is intrinsic to Java. Seems to work > well, so far. Ironically, I haven’t done that with the CRC16 > itself, as I might have to switch between data streams as a file is > decompressed. > > At the lowest level, the LittleEndianByteInputStream handles > retrieving words and the date/time format as well as the basic > byte. Yes, new name nominations will be accepted… it’s a mouthful! > > Then, there is the RleInputStream and LzwInputStream the handle > compression. I created a separate BitInputStream to handle pulling > the 9-bit to 12-bit LZW codes from the wrapped InputStream. > > Finally, the Lzw1InputStream (note the “1”) handles the vagaries of > the LZW/1 format (there are byte headers between each chunk of > data, etc). It actually juggles four different InputStreams as the > compression might vary between none, LZW, RLE, and LZW+RLE. > > I haven’t hit a file size > 4096 bytes yet, and haven’t started on > the LZW/2 format. I think the “tough” stuff has been tacked, though!! > > -Rob > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/ > index.php_______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: David S. <da...@at...> - 2008-06-23 10:46:51
|
Rob Greene wrote: > Good news! Very much so. > Finally, the Lzw1InputStream (note the “1”) The one thing I would comment on from a code review standpoint... it's probably worth spelling out "One" here to make a better visual distinction from LzwInputStream. - David |
|
From: Rob G. <Rob...@us...> - 2008-06-23 04:17:34
|
Good news! I finally started making headway with the various LZW schemes in the ShrinkIt/NuFX format. It's actually very very simple, but as a first time compression guy, it twisted me up for a bit. It is pretty cool though. In general, as John suggested, I've been using the layered InputStream approach which is intrinsic to Java. Seems to work well, so far. Ironically, I haven't done that with the CRC16 itself, as I might have to switch between data streams as a file is decompressed. At the lowest level, the LittleEndianByteInputStream handles retrieving words and the date/time format as well as the basic byte. Yes, new name nominations will be accepted. it's a mouthful! Then, there is the RleInputStream and LzwInputStream the handle compression. I created a separate BitInputStream to handle pulling the 9-bit to 12-bit LZW codes from the wrapped InputStream. Finally, the Lzw1InputStream (note the "1") handles the vagaries of the LZW/1 format (there are byte headers between each chunk of data, etc). It actually juggles four different InputStreams as the compression might vary between none, LZW, RLE, and LZW+RLE. I haven't hit a file size > 4096 bytes yet, and haven't started on the LZW/2 format. I think the "tough" stuff has been tacked, though!! -Rob |
|
From: Rob G. <Rob...@us...> - 2008-06-20 03:20:47
|
I most definitely could. I have it in the ByteSource class, and I was beginning to wonder why I didn't just make it extend InputStream since it already implements the abstract read method. Just haven't quite gotten there. (I did implement the RLE as RleInputStream... and the LZW's make sense to also be an InputStream.) -Rob -----Original Message----- From: app...@li... [mailto:app...@li...] On Behalf Of John B. Matthews Sent: Thursday, June 19, 2008 9:50 PM To: app...@li... Subject: Re: [AppleCommander-devel] CRC16 on-line calculator Rob: Good catch. I see now those are both widening conversions with automatic sign extension; and none of my test cases included UTF-8 in the "negative" range, \u0080 to \u00FF. I implemented the Checksum interface, mostly because CRC32 did so, too. Can you use CRC16 in a CheckedInputStream? John On Jun 19, 2008, at 10:11 PM, Rob Greene wrote: > I've verified the computed CRC against some shrinkit files I've > been using. > Made a minor correction (those stupid bytes are *signed* and it, > er, bytes > me every time) and it seems good to go. I also updated the unit > test to > catch the problem. > > I've got RLE decompression functional and am looking at the LZW/1. > Which is > new to me, but I've got it figured out on paper now, so I'll start > implementing it. LZW/2 should be a minor tweak from there. In all my > archives, I didn't see any of the other compression formats, so I'm > not > going to worry about them yet. > > -Rob > > -----Original Message----- > From: app...@li... > [mailto:app...@li...] On > Behalf Of > John B. Matthews > Sent: Thursday, June 19, 2008 3:40 AM > To: app...@li... > Subject: [AppleCommander-devel] CRC16 on-line calculator > > For reference, I found this on-line calculator that gets the same > result as our CRC16: > > <http://zorc.breitbandkatze.de/crc.html> > > Parameters: order 16, poly 1021, initial value 0, final xor 0, no > reverse data or result. > > John > -- > mat...@us... > http://sourceforge.net/users/matthewsj > > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel > > > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel John -- mat...@us... http://sourceforge.net/users/matthewsj ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ AppleCommander-devel mailing list App...@li... https://lists.sourceforge.net/lists/listinfo/applecommander-devel |
|
From: John B. M. <mat...@us...> - 2008-06-20 02:50:02
|
Rob: Good catch. I see now those are both widening conversions with automatic sign extension; and none of my test cases included UTF-8 in the "negative" range, \u0080 to \u00FF. I implemented the Checksum interface, mostly because CRC32 did so, too. Can you use CRC16 in a CheckedInputStream? John On Jun 19, 2008, at 10:11 PM, Rob Greene wrote: > I've verified the computed CRC against some shrinkit files I've > been using. > Made a minor correction (those stupid bytes are *signed* and it, > er, bytes > me every time) and it seems good to go. I also updated the unit > test to > catch the problem. > > I've got RLE decompression functional and am looking at the LZW/1. > Which is > new to me, but I've got it figured out on paper now, so I'll start > implementing it. LZW/2 should be a minor tweak from there. In all my > archives, I didn't see any of the other compression formats, so I'm > not > going to worry about them yet. > > -Rob > > -----Original Message----- > From: app...@li... > [mailto:app...@li...] On > Behalf Of > John B. Matthews > Sent: Thursday, June 19, 2008 3:40 AM > To: app...@li... > Subject: [AppleCommander-devel] CRC16 on-line calculator > > For reference, I found this on-line calculator that gets the same > result as our CRC16: > > <http://zorc.breitbandkatze.de/crc.html> > > Parameters: order 16, poly 1021, initial value 0, final xor 0, no > reverse data or result. > > John > -- > mat...@us... > http://sourceforge.net/users/matthewsj > > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel > > > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > AppleCommander-devel mailing list > App...@li... > https://lists.sourceforge.net/lists/listinfo/applecommander-devel John -- mat...@us... http://sourceforge.net/users/matthewsj |
