|
|
The Icon Bar: Programming: A Scripting framework for RISC OS
| |
A Scripting framework for RISC OS |
| |
Paolo Zaino (23:03 3/9/2003)
ninj (16:41 10/9/2003)
Paolo Zaino (17:40 10/9/2003)
john (18:19 10/9/2003)
Paolo Zaino (16:47 11/9/2003)
Phlamethrower (21:43 11/9/2003)
john (23:18 11/9/2003)
ninj (18:25 17/9/2003)
davidb (19:08 17/9/2003)
Paolo Zaino (20:28 18/9/2003)
davidb (01:18 19/9/2003)
Paolo Zaino (19:20 19/9/2003)
pfj (22:08 27/9/2003)
Paolo Zaino (11:33 29/9/2003)
|
| |
|
Paolo Fabio Zaino |
Message #46159, posted by Paolo Zaino at 23:03, 3/9/2003 |
Member
Posts: 61
|
Hi guys...
I am working on a little framework for RISC OS that use a C-Style programming language, full multitask and multithread library.
I would like to know if somebody is interessed in to test it (when it will be done) and wich features would you like to see on it.
Thanks to everybody. |
| |
 [ Log in to reply ] |
| |
|
ninjah |
Message #46377, posted by ninj at 16:41, 10/9/2003, in reply to message #46159 |
Member
Posts: 288
|
What sort of scope are you aiming at? A full general purpose programming language? A rapid application development scripting language for GUIs? A GUI framework which can be used from any programming language?
I'm a little confused. |
| |
[ Log in to reply ] |
| |
|
Paolo Fabio Zaino |
Message #46379, posted by Paolo Zaino at 17:40, 10/9/2003, in reply to message #46377 |
Member
Posts: 61
|
Well, first i am sorry for be so "not" explicit 
I didn't explained more because it need a lot of space and i don't think the forum is the right place, but i am preparing a little series of articles (that i will send to iconbar) where i explain the structure of RISC OS compared to other operating systems and why a great solution of many "problems" could be a complete framework.
Basicaly the goals of a risc os framework should be:
a) Hide multitasking development details to not experienced programmers.
b) Make them able to develop multithreaded programs in a "easy" way (i am thinking about how java manage its threads).
c) Concerned about C language structure for let unexperienced programmers learn that language, but i am studing also BBC Basic, so , maybe, it could be possible to implement a language indipendent framework.
d) Develop it in a GNU license so, if RISC OS Ltd and Castle are not interessed into give it as a standard feature of the system, users will be able to obtain it for free.
Other than this, if there is some developer interessed, i want to share my code and all "know how" for work togeter and build it as much faster as we can.
Anyway, makeing a good structured framework, we shouldn't need to modify a lot RISC OS core for have new features.
Other than this, "just" recompiling the framework it could be possible to use frameworked applications on new versions of RISC OS and on future embended version of it.
Basicaly what Microsoft is doing with their .net, they made experience into this when they developed windows NT for more platforms than just pentiums and they "discovered" that nobody was recompiling applications for MIPS processors etc... this is one of the "why" they developed .net.
.net will never be available on other operating systems it is needed for develop Windows 2003 or future versions of windows on other platforms without recompiling existing softwares.
Thanks and sorry for a so long answer |
| |
[ Log in to reply ] |
| |
|
John D |
Message #46381, posted by john at 18:19, 10/9/2003, in reply to message #46379 |
Member
Posts: 261
|
Sounds great, but it looks a bit like something which you'd need to start and then get other people interested in. It sounds like an awful lot of work, and I'm wondering how fast it would be. Anyway, as I say, it's best to do a plan and work out loads of goals etc before you get people interested. I'm also not sure how many potential developers it would have. |
| |
[ Log in to reply ] |
| |
|
Paolo Fabio Zaino |
Message #46391, posted by Paolo Zaino at 16:47, 11/9/2003, in reply to message #46381 |
Member
Posts: 61
|
You are right john.
Anyway i said i wish to develop it as a GPL software so, of course, it will need a lot of time just because it is not commercial.
I made other frameworks on other operating systems and usually i work by my self, it should need arround a year of work, but some test algoritms are already done. Anyway thanks to the working on it i am re-building my GNU Studio IDE makeing it work good on RISC OS and for GNU compilers so it is helping to work on the IDE.
If users are most interessed in to a language indipendent framework it should need more time, specially for debuging, but i am not so interessed into it.
Cheers |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #46397, posted by Phlamethrower at 21:43, 11/9/2003, in reply to message #46391 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Sounds like an interesting idea - good luck with it! |
| |
[ Log in to reply ] |
| |
|
John D |
Message #46401, posted by john at 23:18, 11/9/2003, in reply to message #46391 |
Member
Posts: 261
|
It sounds great, it's nice to have things developed to make it easier to writ software because then we get even more software as a by product. Just one language will be fine, it looks very interesting, and as the other poster says, good luck :)
________
|
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #46527, posted by ninj at 18:25, 17/9/2003, in reply to message #46401 |
Member
Posts: 288
|
The things that I found awkward years back about coding a (very simple) WIMP app was handling the save dialogue. I'd imagine that if my app were any more complex, I'd have had trouble handling redraw requests too.
I think at least the latter of those problems has since been solved by the toolbox. I suspect the documentation for toolbox is a little lacking in the 'getting started' stakes. I also expect the fact that you have to pay for it also puts a lot of people off.
So those are the things I'd like to see - good documentation for people new to the framework, and it being free. You've already got the second part sorted!
Oh, and it must always be possible to drop down to the Toolbox or WIMP SWIs for anything your framework can't do. People developing apps always end up wanting to add things they'd never considered at the start, and those things may not always be possible in any given wrapper framework. |
| |
[ Log in to reply ] |
| |
|
David Boddie |
Message #46535, posted by davidb at 19:08, 17/9/2003, in reply to message #46527 |
Member
Posts: 147
|
The things that I found awkward years back about coding a (very simple) WIMP app was handling the save dialogue. I'd imagine that if my app were any more complex, I'd have had trouble handling redraw requests too. The problem is implementing all the ways in which the saving mechanism is supposed to work. Ideally, a library or framework would support all the various data transfer mechanisms (clipboard, drag and drop, etc.) and these would work transparently in applications written using that library. Unfortunately, there are many "incomplete" libraries available and very few, if any, which support all the niceties which users expect.
I think at least the latter of those problems has since been solved by the toolbox. I suspect the documentation for toolbox is a little lacking in the 'getting started' stakes. I also expect the fact that you have to pay for it also puts a lot of people off. It's a fairly undemocratic framework, partly as a result of those issues you mention, but it's probably also due to the tools required to extend it. |
| |
[ Log in to reply ] |
| |
|
Paolo Fabio Zaino |
Message #46556, posted by Paolo Zaino at 20:28, 18/9/2003, in reply to message #46535 |
Member
Posts: 61
|
About the documentation i'll try to do my best... 
About the data-transfer problem, you are very right David and you know that this means to build a complete base support library for the framework and that is a things not very easy to do... (also because it needs time for project, time for implement, time for develop)
about SWI calls... well (for now and only for now) i am thinking about a access model based on a false object oriented structure as it follows:
example of a possible call (1)
System.SInt (&code or "name" ,r1,r2,r3 etc... to myvar1, myVar2...)
example of possible call (2)
System.WriteC (r1,r2,r3 etc... to myvar1,myvar2...)
Where System identifies the system library.
in the example (1) &code or "name" identify the SWI called
in the example (2) the call name is stored in a call data structure used by the framework for identify wich swi you was calling.
The first example will be faster during the code parsing, but not easy to use, the second will be slower during the code parsing but more easy to use because if you make a mistake like:
System.WiteC
the framework could answer to you with an error message and not make you crash the system (specialy if you used a wrong &code calling another SWI).
But for now i am still working on the data-structures so, before to implement the swi calls it still need time...
[Edited by Paolo Zaino at 20:29, 18/9/2003] |
| |
[ Log in to reply ] |
| |
|
David Boddie |
Message #46558, posted by davidb at 01:18, 19/9/2003, in reply to message #46556 |
Member
Posts: 147
|
Take a look at the swi module for RISC OS Python. It uses an interface like
os_version, task_handle = swi.swi('Wimp_Initialise', 'iisb;ii', 300, 0x4b534154, task_name, message)
where "message" is a swi.block object (effectively an array of integers) and "task_name" is a string. If a particular register isn't meant to be supplied then the string contains a '.' in the appropriate place. For example, if the above SWI didn't require the awful integer representing the "TASK" string then you might have
os_version, task_handle = swi.swi('Wimp_Initialise', 'i.sb;ii', 300, task_name, message)
The characters after the ';' are the return values obtained from registers. In the above example, they are returned as integers.
It certainly makes using Font_ScanString and friends marginally more bearable. |
| |
[ Log in to reply ] |
| |
|
Paolo Fabio Zaino |
Message #46568, posted by Paolo Zaino at 19:20, 19/9/2003, in reply to message #46558 |
Member
Posts: 61
|
Yes it is very interesting...
But the big problem for now is to project a good structure for the "managed code"...
Imagine something like that:
__________________________________________________
#include "mylib.h" // a C-like header
Using System; // a internal library
Using Wimp; // idem
Using GraphPlot3d; // a (for example) python
// or basic library
main {
...
}
etc...
_________________________________________________
Where the directive #include will join the library "mylib.h" to your code memory area in a JIT way.
Using command will start a new "CLI-internal tasks" (in a different memory area) that will expose only their "public" functions to other CLI-tasks.
Basicaly the idea is to make a "single language" CLI (ex C based syntax) and different languages parsers and JIT compilers (into the CLI)...
With a good-made Common Types Structure it could be possible to mix and use various libraries made in different languages (for now only procedural languages as basic, pascal, c, fortran etc...) calling their exposed functions by:
lib_name.func_name(parameters) (lib_name is used as a name-space).
The CLI will provide to the JIT conversion of the right type and will pass them to the other internal task and will execute the exposed funtion returning the value (always in the right type) to the internal task caller.
Basicaly it is a "not complete" COM model for make software development under RISC OS faster and easy, but i am still thinking arround its internal structure.
How the CLI execute the various internal tasks is based on an internal scheduler that works useing a Wimp_pollIdle structure.
[Edited by Paolo Zaino at 19:27, 19/9/2003] |
| |
[ Log in to reply ] |
| |
|
Paul F. Johnson |
Message #46724, posted by pfj at 22:08, 27/9/2003, in reply to message #46568 |
Member
Posts: 54
|
Using System; // a internal library
Using Wimp; // idem
Using GraphPlot3d; // a (for example) python
looks like you're trying to use a C# or Java model here, especially using the JIT system.
now, it would not be impossible to do (for the above, you could use System(); Wimp(); etc to instantate a set of system and wimp classes), the problem would be the JIT compiler.
A far simpler solution would be for the code generator to generate p-code rather than anything else (in the same way as WimpBASIC does) which is then processed via a module. That way it makes blow all difference as to the language used as the pcode would be same.
Even nicer is that pcode generators are not that hard to write. Okay, the system for converting pcode to WIMP is a bit tougher, but none-the-less doable (this is seen as it's what is used with WimpBASIC)
In other words, if you remember a system called BASICODE which was used in the early 1980s by the BBC where they broadcast the equivalent of pcode and each home micro would have their own decoder, you won't go far wrong. |
| |
[ Log in to reply ] |
| |
|
Paolo Fabio Zaino |
Message #46738, posted by Paolo Zaino at 11:33, 29/9/2003, in reply to message #46724 |
Member
Posts: 61
|
Well...
The model im am trying to develop is based on ECMA Standard CLI (that, of course, compose .NET framework and so C# model) and Java model.
Basicaly ZCLI (that is the framework name, for now and if you have better ideas them are very welcome!) should give to RISC OS users most of the ECMA CLI features and Java features but based on a mid-level programming structure (read not a complete virtual machine).
The reason why i am following this way is:- Realize a complete virtual machine should needs a lot of work time (and i don't have all that time to work on a free software).
- On old computers like RiscPC with ARM600 etc... perform a pure virtual machine should look like very slow.
- RISC OS is not pre-emptive task so develop a pure virtual machine that perform its own tasks and not disturb external classic-style tasks means a lot of work arround the poll management.
So what i am try to do is an interpretative-architecture that gives: 1 ) C-style mid-level language interpretation (it will make easier to develop JIT for other languages)
2 ) Hide multitasks details to programmers for 2 reasons:
2.1) Begginners will be able to develop their software in a easier way
2.2) Expert programmers will be able to develop their own applications and solutions in a faster way concentrating their resources on the problem solving and jumping many architeture details. (This should also make another benefit to RISC OS market that is: putting down software prices for commercial applications)
3 ) The mid-level C-Style language will support all classic data types as:
3.1) Int
3.2) Char
3.3) Float
3.4) Double
3.5) String (not limited to 256 characters!)
with their own variant as 'Long', 'register' etc..., a c-style interpret should also make ZCLI have good software scenario using old C sources code.
4 ) Data-structures will be completely dynamic that means that ZCLI will implement a garbage collector for:
4.1) not used variables
4.2) not used threads*
4.3) not used processes*
*for processes and threads i mean it own internal processes and threads
5 ) Code cryptography for develop professional applications protected by copyright
6 ) A base COM-like structure for code re-using also between different languages (and for use also public functions and variables exposed by cryptated code)
7 ) Not supporting OOP model (for now) 'cause it needs more time to work on and basically it will be implemented only (and if only) the ZCLI will have success and it will work in a C++ Style (or maybe in a commercial version of the ZCLI).
8 ) Internal libraries for support:
8.1) System SWI
8.2) Wimp API
8.3) BBC BASIC, PASCAL and FORTRAN JITs
8.4) Graphics primitives as lines, boxes, circles etc... completely based on FLOATING POINT processors
8.5) ODBC driver for easy and standard access to databases made on RISC OS or on other systems
8.6) WEB DEVELOPMENT for use the ZCLI as PHP
9 ) INTERNAL PROCESSES MEMORY PROTECTION for:
9.1) internal protected processes
9.2) protected variables
9.3) protected functions and procedures
10 ) file name abstraction, it will be possible to access ADFS structures useing UNIX nameing, RISC OS nameing, MS DOS nameing. That's all specifics (for now) where i am working on.
Any help, informations and new ideas are very welcome!
[Edited by Paolo Zaino at 12:00, 29/9/2003] |
| |
[ Log in to reply ] |
| |
|
The Icon Bar: Programming: A Scripting framework for RISC OS | |
|
