> Brian , What did you decide to work on next? LCP class. If Roger is game it looks like there are Java things in the list he could take on. Maybe Juan? (Eclipse plugin)
> What would you like me to work on next? Apart from fixing bugs and making > things more robust, I am thinking of working on 6 and 7. Yes, I think a persistant text menu that allows you to upload to it and delete files would be the most important thing to aim for at the moment. (If the menu can delete files, do you still need an explorer interface on the PC?) Making it understandable to users how to upload the menu - are we going to treat this as part of firmware? Maybe a batch file that gets the "firmware" (menu etc...) on the brick. One thing I'm wondering about is, does the Official LEGO firmware reside in Flash memory or in the 64 kb RAM area? If not 64 kb area, what do they use that for then? It would be nice to use that area for what ammounts to our firmware (menu system, LCP, etc...) but I assume it isn't persistant memory. > Do you have any thoughts on how to use iCommand for this sort of thing. > Should we include the iCommand jar file and the third party jar files and > dlls with lejos NXJ. We have this issue for both the file explorer and > command line utilities. If we can help it, let's not go there yet. iCommand has issues with using RXTX and other third party COMM programs that I don't want to get into now. We'll need to research options so users don't have to download other classes to make leJOS work. And I really don't want to get into USB support for iCommand for the next release. Our priority should be to get the persistant menu system, consolidate those changes and do a release. > What restrictions /limits does File currently have? Is it: > 1. All file entries must fit in the first page? Yes, but I'm planning on increasing page size for entries. It's limited to about 10 files now if you use ~12 chars for file names. > 2. Only one file open at a time? Yes. Nothing is synchronized and the File class shares the byte [256] buff object for obvious reasons. If they didn't share buff you could read multiple files now, but there is no way each File object should waste 256 bytes. If we get a GC someday we can improve this aspect. > 3. Max of 30 files (but currently limited by (1)). > 4. Maximum filename length is 30 characters. > 5. Space used by deleted files is not reclaimed unless all files are > deleted, or last file created is deleted. > 6. No append to a file. > 7. Overwriting a file with a longer file not supported (must delete and > recreate). > 8. Filenames must only contain ascii characters > 9.Maximum of 894 256-byte pages for files. This may reduce when we have a > bigger menu program. > Do you have any plans to reclaim the space from deleted files? We could > have a File.defrag() method. Yes, I'll have it autodefrag. It will lock files that are open/executing so they don't get defragged. > What do you currently expect to happen if I keep creating files until the > first page is full. Will it crash with an array out of bounds exception? Something like that. I'm not worrying too much about it at this stage. If you want lots of files, use small filenames like 5 chars in size. > When you start using 2 pages for the file table, I calculate that the > average filename length will need to be about 9 characters in order to fit > 30 file table entries in 2 pages. Do you think that is OK? You could > reduce the file length field to 2 or 3 bytes. Eventually (when we have GC) if we want no limits we could have it so the file table expands itself to new pages. There's no reason why it has to be the first few pages of memory. It could occupy any pages in flash by storing the locations of individual table pages. - Brian ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Lejos-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lejos-discussion
