I am currently working on a shell project. I currently have a windows manager component, a process manager component and two applications: an image viewer and a shell to browse and start applications.
The browse application can be used for file manipulation (delete / copy) but that can be extended to rename and move. The image viewer can ofcourse display/resize and rotate images.
For me, this is a hobby project and I consequently crash in to the limitations luaplayer has. For example: I want to move a file from position 1 to position 2. Since Luaplayer does not support a move function I need to binary read the file from 1 place and write it at another place.
My question is, are there people that want to try and help developing it?
You don't need to be a coding pro, just someone that likes to work on this kind of programs.
Cheerio
Framework Project
Moderators: Shine, Insert_witty_name
-
Roland35007
- Posts: 7
- Joined: Sun Jan 07, 2007 11:54 pm
Thanx!youresam wrote:I dont really want to help, but heres how you would move the file. Open the current file in "r" and the new file in "w", then do..
to:write(from:read(100))
until you reach the end of the file
At the end I also remove the from: file. Otherwise it only is a copy ;)
For now it only is a nice hobby project,where I put in time when I have got nothing better to do.
Cheerio
-
Roland35007
- Posts: 7
- Joined: Sun Jan 07, 2007 11:54 pm
I quit
After giving it some considerations (and wines) I decided to quit lua player. Although its a nice product, it is not and never will be a serious development platform. This is the result of some fundamental issues that make me bang my head against walls and limit the scope of Lua. In normal programming languages, its the programmer that defines the scope, the language gives all possibilities.
In this case the developers limited the possibilties of Luaplayer making it a great tool for graphical operations, but the serious functions exposed by the " Kernel" API are not available. Does a developer need these functions? Not from the perspective of the Luaplayer developers. Let the Lua programmer decide! Not the one that creates a programming language. You want these functions? Use the PSPSDK, but C is not everyones piece of cake. I have made great programs with other scripting languages that offered API support.
So what do I mis?
- Serious filemanagement functions, think of copying/moving files and/or directories. File attributes are missing. Why not mount a UMD disk? Perfectly safe, its read-only. Why would you..because we can. (unless some anti-piracy policy is in place here).
- USB is either on or off, but is there USB activity. The 3 versions of the firmware have hostfunctions for the USB port. I can't use that.
- MP3/MOD is flacky in Lua. Modules that support MP3 choke when they don't get there processor time. This happens when you move an object like a window over the screen. This issue also applies to basic .MOD files which played perfectly on 7.68 MHZ amiga 500's. 111 MHZ simply isn't enough for serious programming with Graphics and Audio.
- The processor goes to 333 MHZ as DESIGNED by Sony. This means that all components (including flash) can handle these speeds. Btw what is 333 Mhz compared to the 3.6 GHZ processors these days. 333 MHZ is really low end. In other words: who invented the myth that you could brick a PSP by letting it run at 100% of its designed speed? If flash gets corrupted it's because of a lousy write operation. Not because of the speed.
- Exec(), simple option to chain start a .PBP file or other executables. Lua is limited because they call polling functions 'co-operative multitasking'
- Support for other image formats. If someone can program .BMP support, it can also be integrated in Lua. In less code I suppose.
- Lua is a memory hog. The official(0.2) version only leaves 4 MB after loading. Sony can be blamed for putting 32 MB memory in it. But strip Lua and add #include functionality for anything not standard Lua.
- Direct API functions. This is usually much faster then using a Luawrapper function. C only has functions that work on the system API's.
And most of all, don't be afreight to deviate from the Lua language specification. If you can enhance a language then fork and do it. Its free (unless the Lua license prohibits). Lua was designed as a scripting language for use in C environments: well the why isn't there a ++ operator? This is not a Luaplayer developers issue, but its a good example of how you could change Luaplayer for the better.
What also would make Lua a kick arse development language is a real-time debugging function. Since its a interpreter, its really easy to step through the code and have a program at the other side of the USB port receive information like the value of variables etc. Much better then what we have now.
In other words: Lua is a scripting tool for simple jobs, but lacks serious features. If your line of work is not Graphical related (like needing OS functions) then Lua is no-go.
So until Lua solves all of these issues, I will skip the PSPSDK, which simply won't work on my system) and use my PSP what it was made for: movies, music and games.
Cheerio
In this case the developers limited the possibilties of Luaplayer making it a great tool for graphical operations, but the serious functions exposed by the " Kernel" API are not available. Does a developer need these functions? Not from the perspective of the Luaplayer developers. Let the Lua programmer decide! Not the one that creates a programming language. You want these functions? Use the PSPSDK, but C is not everyones piece of cake. I have made great programs with other scripting languages that offered API support.
So what do I mis?
- Serious filemanagement functions, think of copying/moving files and/or directories. File attributes are missing. Why not mount a UMD disk? Perfectly safe, its read-only. Why would you..because we can. (unless some anti-piracy policy is in place here).
- USB is either on or off, but is there USB activity. The 3 versions of the firmware have hostfunctions for the USB port. I can't use that.
- MP3/MOD is flacky in Lua. Modules that support MP3 choke when they don't get there processor time. This happens when you move an object like a window over the screen. This issue also applies to basic .MOD files which played perfectly on 7.68 MHZ amiga 500's. 111 MHZ simply isn't enough for serious programming with Graphics and Audio.
- The processor goes to 333 MHZ as DESIGNED by Sony. This means that all components (including flash) can handle these speeds. Btw what is 333 Mhz compared to the 3.6 GHZ processors these days. 333 MHZ is really low end. In other words: who invented the myth that you could brick a PSP by letting it run at 100% of its designed speed? If flash gets corrupted it's because of a lousy write operation. Not because of the speed.
- Exec(), simple option to chain start a .PBP file or other executables. Lua is limited because they call polling functions 'co-operative multitasking'
- Support for other image formats. If someone can program .BMP support, it can also be integrated in Lua. In less code I suppose.
- Lua is a memory hog. The official(0.2) version only leaves 4 MB after loading. Sony can be blamed for putting 32 MB memory in it. But strip Lua and add #include functionality for anything not standard Lua.
- Direct API functions. This is usually much faster then using a Luawrapper function. C only has functions that work on the system API's.
And most of all, don't be afreight to deviate from the Lua language specification. If you can enhance a language then fork and do it. Its free (unless the Lua license prohibits). Lua was designed as a scripting language for use in C environments: well the why isn't there a ++ operator? This is not a Luaplayer developers issue, but its a good example of how you could change Luaplayer for the better.
What also would make Lua a kick arse development language is a real-time debugging function. Since its a interpreter, its really easy to step through the code and have a program at the other side of the USB port receive information like the value of variables etc. Much better then what we have now.
In other words: Lua is a scripting tool for simple jobs, but lacks serious features. If your line of work is not Graphical related (like needing OS functions) then Lua is no-go.
So until Lua solves all of these issues, I will skip the PSPSDK, which simply won't work on my system) and use my PSP what it was made for: movies, music and games.
Cheerio