Author Topic: FileSyst (Read 21649 times)

Xeda112358 · « **Reply #45 on:** January 26, 2013, 09:57:29 am »

I have modified the program a bit so input is no longer case-sensitive. New files will be created case senstive, though, so you can create Partex2.gram and refer to it as PARTEX2.GRAM. This will hopefully be useful to those who don't want to activate lowercase or use lowercase.

Do you think that converting the file extensions to lowercase is a good idea? I think it looks nicer and it wouldn't be much of a hassle to convert uppercase to lowercase. You could still refer to files using uppercase file extensions, but when you use GETD(), it will return the extensions as lowercase if I do this.

I am also going to add in a new command that I was supposed to do last week. It will be an eBASIC command similar to one that already exists. It basically returns variable names in the OS VAT so that the other folks using FileSyst can easily get the names of all the vars in the OS and create appropriate folders with all the shortcuts. The differences between this and the GetVar command that already exists:

The command that already exists uses the OS routine _FindAlphaUp and happens to slow down significantly.
The OS routine ignores variables hidden from menu's. One of the developers, roguebantha, uses a "." to begin the names of his subprograms, so these get ignored, otherwise
The routine I made searches the VAT alphabetically, too, so I have no idea why it is so much faster than TI's o_O

Once I modify the code to be more flexible (it currently only searches for appvars), I will probably post it in the Useful Routines thread.

Xeda112358 · « **Reply #46 on:** April 28, 2013, 12:26:07 pm »

Update!

There was a pretty bad bug that I ran into a while ago while modifying the program and I wasn't sure what caused it. I finally tracked it to the root of the problem today by luck because I had no idea what to look for. It turned out that four bytes of code that I commented out were actually needed in a certain rare situation.

So that is fixed, and I added the NEW() command so that folders and files could be created whenever they were needed. As well, I added the SINSRT() command to insert a string of data into a file. It is not complete as it only inserts at the beginning of the file, but it is the start of a set of commands that I have been planning on working on. As well, you can now use the OS Ans variable, if it is a string, in place of string arguments and you can use OS String variables.
Here is an example:

Code: [Select]

:Input "Name:",Str1
:dim(-1             ;start a block of FileSyst code
:CD(Game/Str)
:NEW( Name.str)
:SINSRT( Name.str,Str1)
:Return             ;Exit the block of FileSyst code

That will create the file Name.str in folder Game/Str and fill it with the contents of Str1.

I am sure there are still bugs, so take care, but the download is here. I also updated the example program a little bit, but not much. In particular, renaming files seems to have problems and I haven't looked to see if that is a problem in FileSyst or prgmGUI.

EDIT: I added in the DELB() command to delete a given number of bytes from a file at a given offset. It properly handles when the offset is beyond the file data, when the number of bytes deleted would go beyond the file and other potential issues. I also added an offset argument to the SINSRT() command and it handles when the offset goes beyond the file by simply appending the string to the file. I won't be back for 5 or 6 hours, but if I am not too tired, I will try to add in commands for line reading/writing/overwriting. I will then want to add the ability to parse FileSyst code directly from archive and have user defined functions. I already have a bunch of other things planned, though, so I should try not to get too far ahead of myself

Needless to say, the commands and a few of the routines that I added today have been on my To Do list since week 1.

Joshuasm32 · « **Reply #47 on:** April 28, 2013, 06:42:13 pm »

Huuraay!

TheMachine02 · « **Reply #48 on:** April 29, 2013, 11:57:07 am »

this is a very great program

good job

Xeda112358 · « **Reply #49 on:** April 29, 2013, 12:39:38 pm »

The meeting actually lasted a lot longer than I expected, so I was too tired last night. So instead, I will just upload what I have and hope for more time later

willrandship · « **Reply #50 on:** June 03, 2013, 05:39:36 pm »

How have I not seen this project until now?

Request if it's not already there: Archive support.

By the way, don't be surprised that your code runs faster than TI-OS. There are many areas where their code could be optimized heavily.

Xeda112358 · « **Reply #51 on:** June 05, 2013, 10:21:54 am »

When you say Archive support, do you mean having the ability to keep files and folders in archive? Currently,if you make any OS pointers, then the OS vars can be archived. An example is if you have prgmSUB01 archived, this will still work:

Code: [Select]

CD(Sub)         ;open the folder Sub.
VPTR(prgmSUB01, 01)   ;create an OS pointer to prgmSUB01 named 01 stored in folder Sub.
OPEN(Sub/ 01)      ;use the OPEN() command to open the file. The file type is auto detected and opened with the appropriate routines.

I use this technique to keep sub programs in archive. As well, you can have some sub-programs that require different parser hooks, so if prgmSUB01 is a regular BASIC program, but prgmSUB02 needs Celtic 3, prgmSUB03 needs BatLib, and prgmSUB04 needs DoorsCS7, you could do:

Code: [Select]

CD(Sub)
VPTR(prgmSUB01, 01)
VPTR(prgmSUB02, 02.c3)
VPTR(prgmSUB03, 03.batb)
VPTR(prgmSUB04, 04.dcs7)

As long as the appropriate apps are on the calculator,the programs will run. For a Celtic 3 program, FileSyst first checks if the Celtic 3 app is on the calculator, if it isn't, it checks if DoorsCS7 is on the calculator. If one of them is on, then FileSyst will try to install their hooks and then run the program. From the readme:

Code: [Select]

/==============================================================\
|     OPEN(File)                                               |
\==============================================================/
|  This can be used to open files based on its file extension. |
|If it does not have a file association, FileSyst will try to  |
|open it as a nostub assembly program or BASIC program. Built  |
|in file types and the programs that open them are:            |
+======+=======================================================+
|Assoc:| Programs (In descending order of priority)            |
+======+=======================================================+
| ION  | DoorsCS7,DoorsCS6                                     |
| MOS  | DoorsCS7,DoorsCS6                                     | 
| DCS  | DoorsCS7,DoorsCS6                                     |
| DOC7 | DoorsCS7+DocDE7                                       |
| BAT  | BatLib                                                |
| BATB | BatLib                                                |
| C3   | DoorsCS7,Celtic 3                                     |
| XLIB | DoorsCS7,Celtic 3,xLIB                                |
| DCS6 | DoorsCS6,DoorsCS7                                     |
| DCS7 | DoorsCS7                                              |
| DCSB | DoorsCS7                                              |
| OMNI | Omnicalc                                              |
| GRAM | Grammer                                               |
+======+=======================================================+
|  For example, if you try to run an xLIB program, FileSyst    |
|first searches for DoorsCS7, if that isn't available, it tries|
|Celtic 3 and then xLIB.                                       |
|  Further, xLIB and Omnicalc don't have any actual installers |
|aside from manual installation. If FileSyst has to install    |
|these, it uses a method that should only work on specific     |
|versions, xLIB v.602b and Omnicalc v1.26 and v1.26MP.         |
|  Now, for some example code:                                 |
|     CD(Zeda/Games)                   ;Change the directory.  |
|     VPTR(prgmDK5ION, DonkeyKong.ION) ;Makes an OS shortcut.  |
|     OPEN( DonkeyKong.ION)            ;Run DonkeyKong.        |
|                                                              |
|  OPEN() should return to the program properly, but there is  |
|always a chance that it won't if an assembly program doesn't  |
|quit properly (or if a BASIC program uses Stop).              |
\==============================================================/

Xeda112358 · « **Reply #52 on:** July 04, 2013, 11:15:30 am »

Hey! I was trying to come up with ideas for things that I could add today. I added in a command called OSNEW() that creates an OS variable with an optional size argument. I was thinking of adding in a complicated method for handling variables specific to FileSyst. Basically, here is the idea and I think it is too complicated and I won't add it:

-Create a special type of hidden folder with the name of the main program being run.
-Have a command to define a subroutine
-This creates a folder with the name of the subroutine, and the relative location in the variable for quick lookup
-Inside this folder, will contain named variables used by the routine such as floats, ints, and strings.

This means that if I add an ability to SUB(LBL), or whatever, they can have local variables (and possibly access variables in other subroutines). This could also mean that such a language would be slower than TI-BASIC since variables can have custom names and they are located in folders (then again, this could potentially be faster than the OSes VAT lookup).

So yeah, just some food for thought

tr1p1ea · « **Reply #53 on:** July 04, 2013, 05:55:13 pm »

You know, Xeda, you should just get it over with and write a whole Operating System

.

Xeda112358 · « **Reply #54 on:** July 04, 2013, 07:17:03 pm »

The problem is that I still don't understand Flash protocol and USB protocol. I am not sure, though, but I think SirCmpwn released a template for an operating system, so I could probably use that.

DrDnar · « **Reply #55 on:** July 05, 2013, 01:40:57 am »

Quote from: Xeda112358 on July 04, 2013, 07:17:03 pm

The problem is that I still don't understand Flash protocol and USB protocol. I am not sure, though, but I think SirCmpwn released a template for an operating system, so I could probably use that.

Raw flash commands are documented on the Wiki. BrandonW is the only documentation for USB.

Sorunome · « **Reply #56 on:** July 05, 2013, 03:39:31 am »

erm, what is the file extention then if you use xlib, celtic3 AND picarc all in one file?
Would it be DCSB as you need DCS7 to run?

Xeda112358 · « **Reply #57 on:** July 05, 2013, 07:55:20 am »

You could use a .C3 extension since Celtic 3 supports all of those. An extension of .C3 will look for DCS7 first, since DCS7 has the most complete and bug-free^{[citation needed]} version, else it will look for Celtic 3, and if that isn't available, then it won't execute.

EDIT:Also, thanks DrDnar!

Sorunome · « **Reply #58 on:** July 05, 2013, 08:04:01 am »

Oh cool! (On a side note, i never saw the C3 app anywhere, lol, same with picarc)
And yeah, let's all just hope that DCS8 will have a broader omnicalc support like the play command

Xeda112358 · « **Reply #59 on:** July 08, 2013, 06:34:44 pm »

I am starting to change some things around, like the look-up routine to find a function. To speed up the search a little in most cases, I had the names stored alphabetically. Now I have a 52-byte LUT to jump to a given spot in the table based on the first letter of the function.

I was also thinking that it might be a good idea to store folders and files alphabetically. While that may sound like a pain to actually code, I realised earlier that it should actually be quite easy and it would make searches faster. Instead of checking every file in the folder to find out it doesn't exist, it only needs to start where the first letter matches and go until the first letter no longer matches. This will mean that users can get an alphabetically sorted list of names. This should make it possible to have folders indexed in a similar way as how the function list is indexed. These all together should make lookup speed a bit faster than the system that TI uses and long program lists will be able to load just as quickly as short ones.
(tl;dr : files and folders can be accessed faster and new files can be created faster -- the code is already there)

I also wrote the brunt of a routine to tokenise source codes. This doesn't help much for speed, yet, but if control structures like loops are implemented later, this should greatly improve speed (by a gazillion-fold).

Hopefully all of this will make it easier to add variable support

Author Topic: FileSyst (Read 21649 times)

Xeda112358

Re: FileSyst

Xeda112358

Re: FileSyst

Joshuasm32

Re: FileSyst

TheMachine02

Re: FileSyst

Xeda112358

Re: FileSyst

willrandship

Re: FileSyst

Xeda112358

Re: FileSyst

Xeda112358

Re: FileSyst

tr1p1ea

Re: FileSyst

Xeda112358

Re: FileSyst

DrDnar

Re: FileSyst

Sorunome

Re: FileSyst

Xeda112358

Re: FileSyst

Sorunome

Re: FileSyst

Xeda112358

Re: FileSyst