general question about riscos.

But how would we access the interface from the back-end i.e. in BASIC?

Why BASIC? Use RiscLua. See LuaKit
for example, or this .

aaaaa

aaaaa

Then ok you don’t have the fancy tags with

Hum hum… what you describe is basically NetSurf :)

aaaaa

I always seem to come to the conclusion the best bet would be to write a new browser for RISC OS from scratch.
The reality is that it’s a far better option/the only option at the moment to support netsurf.
We just don’t have enough interest/development muscle

aaaaa

The reality is that it’s a far better option/the only option at the moment to support netsurf.

Don’t forget that NetSurf was a browser for RISC OS made from scratch :)

Another very important point in favour of continuing RISC OS development of NetSurf is that the work on the core is not being done by programmers who might otherwise by doing other RISC OS development. i.e. for a comparatively small time investment in the RISC OS front end, we get a lean quick browser. If enough RISC OS developers get the itch to work on a new RISC OS browser then the work for that which I can’t see it needing less than 10 times that of continuing RO support for NetSurf could continue without significantly slowing the new browser.

aaaaa

aaaaa

but CORBA is made for this 300% originally.

I’m a RISC OS user, not a CORBA user :)

RISC OS is not perfect, but it’s my OS of choice.

The same with ELF (see other thread): DDE is my compiler, so find other ways (heu, I mean, not you).

and they solved many problem very efficiently

IMHO, we should continue like that and not just implement technologies coming from other OSes. If someone wants a Linux application, hey, he can use Linux. Now good ideas can also be good ideas for RISC OS :)

but it need a good web server who can serve multiple request in the same time, able to serve big file, potentially either videos, textures, objects, while still being reactive to js/ajax/android/web page request, have good connectivity with remote file system etc.

HTTPServ is pretty good. For file I/O, I use a lot layerfs, but I really would love some cachefs (each time you read from cache:someresources, the equivalent content of sdfs:someresources, will be cached in DA for later use). Like a read only copy in RAM, just for read operations. Could be a fork of layerfs, or an evolution of layerfs.

Today, I emulate this with Memphis, a copy of my files at boot in RamDisc, then LayerFS. Problem: I must synchronised all again when I modify a file, and start-up is slow. I would prefer to use LayerFS only for union of different file systems, and CacheFS to cache the LayerFS content.

For scripting, I use a lot ABC. I really would like if ROOL could provide the source code to Rick for some evolutions :) Things as ‘no library’ or ‘no eval’ (even a cut down version?) or ‘no fp’ or ‘no new modes and slow graphics’ are really, really annoying.

Nota: ABC could be the base of a cool commercial package. Doc + ABC + some IDE or RAD tool. A BBC Basic pro :)
I can help on this one (for free of course).

aaaaa

aaaaa

HTTPServ handle cgi and php ?

Yep. And it evolves fast.

you want them to run on as many potential target machine/system as possible.

Or not :) IMHO, we just focus to much on generic solutions. But I’m agree on Corba benefits.

image filing

Image filing under RISC OS in incredibly powerful, but really not well documented.

Some frameworks would be needed. An integrated Image FS for photos would be great, with some options to make plug-ins in C (I have a lot of code for this, and could even get access to Xnview code to add some commercial add-ons). For generic files, add-ons could be provided to manipulate data (compression, soft linking, dedup, crypto, etc.). The same for compression methods linked to a compression tool. It’s really easy code to add. The problem is the FS code itself :)

Perhaps that ROOL could provide more entry points for non system developers. Just to add functionalities to RISC OS with simple templates. There is not even good examples to make a screensaver in Basic or a connected application. In a way, that’s what I try to achieved with the BBC Basic contest (still opened!).

For scripting, I use a lot ABC. I really would like if ROOL could provide the source code to Rick for some evolutions :) Things as ‘no library’ or ‘no eval’ (even a cut down version?) or ‘no fp’ or ‘no new modes and slow graphics’ are really, really annoying.

Hmm! If ABC has such shortcomings, and these are not all by a long way, why use it? “Just BASIC” is really fast on current processors, let alone the enhancements you can make to it.

Anyway:

‘no library’: you cannot use the LIBRARY keyword – loading libraries a run-time would make no sense. But you can create library modules with the LIBRARY directives, and then they are shared resources.

‘no eval’ (even a cut down version?): to quote the manual – “EVAL would require the compiled program to have access to the complete source text of the program during execution and the means to decode it. […] not a viable option”. I can conceive an EVAL that would just deal with expressions and the Resident Integers, but what would your ‘cut down version’ do?

‘no fp’: ABC only uses the FPA for floats. What is misssing?

ABC could be the base of a cool commercial package. Doc + ABC + some IDE or RAD tool. A BBC Basic pro :)

I had to look up ‘RAD tool’. I now realise that as an amateur, I have been doing RAD forever. ;-)

Currently, my IDE is ResEd and my RAD tool is Basalt. Simple application prototypes up and running in minutes rather than hours and then refined as necessary – spiral RAD if you like.

Hmm! If ABC has such shortcomings, and these are not all by a long way, why use it? “Just BASIC” is really fast on current processors, let alone the enhancements you can make to it.

ABC is much much faster. And for CGI this feature counts. BTW, they were some limits that becomes now legion (because BBC Basic evolves, and ABC not).

’no library’: you cannot use the LIBRARY keyword – loading libraries a run-time would make no sense.

To load arbitrary libraries at runtime, yes, it has no sense. But if their name is known, ABC could load and compile them. So no need to have two version of your code.

but what would your ‘cut down version’ do?

Calculation + handling of variables. What every other version of Eval do :)

Currently, my IDE is ResEd and my RAD tool is Basalt. Simple application prototypes up and running in minutes rather than hours and then refined as necessary – spiral RAD if you like.

Yep, great tool. But I was more thinking of something like RealBasic, much more advanced than everything else when you need to make some GUI application (even than VB). Here we talk of minutes even for a client server application.

aaaaa

ABC is much much faster. And for CGI this feature counts.

More of my confusion. Mentioning CGI and GUI together put me on the wrong track. For CGI as you mean, what particularly is slow in pure BASIC compared to ABC? A long way back, when ABC was new, I tried out a lot of things with it. Apart from increasing frustration with its limitations I found the speed increase to be marginal in many cases, very good in others and sometimes slower. Hence my later path and a principle that, for a given algorithm, a specialised keyword beats compiled code¹. This is best illustrated by whole array operations, where BASIC beats ABC hands down.

BBC Basic evolves, and ABC not

There has not been much evolution in BASIC, but I suspect that the graphics changes that have been necessary for new machines are where you see the difference.

[Libraries] ABC could load and compile them.

What you want is a linker. Several have been written, but I do not know if any work on current machines. I think there is one in the Dr Wimp package.

[Cut down EVAL] Calculation + handling of variables. What every other version of Eval do :)

EVAL takes an arbitrary string as its parameter. The contents of this string cannot be known at compile time. The names of variables, their values and the operations on them are not known. The string could contain a FN call that would execute whole sections of the program. It is not ‘Calculation + handling of variables’. ;-)

I was more thinking of something like RealBasic

There has been no RealBasic since 2010 – do you mean Xojo? Yes, that is highly developed and very OO. Do you really see RO as a target for it?

¹ That is BASIC, not optimised C compilers.

I have very bad memories of my experiences with ABC. The code produced was not much faster than interpreted BBC Basic at least since StrongARM, sometimes even slower. It didn’t even try to improve BBC Basic, but was even less powerful.

Porting a mature BASIC compiler would probably be the best bet. FreeBASIC comes to my mind, ISTR that there is now an ARM backend for it. Would need a fair bit of RISC OS integration of course (e.g. adding the system specific BBC Basic keywords and allowing ARM inline assembler).

I guess one reason also why it’s hard to find example it’s because once you get how it works, it looks so simple that it doesn’t need documentation, and all the function are already there to make plenty of things.

Then some templates or bridges to generic code?

I found the speed increase to be marginal in many cases, very good in others and sometimes slower

All the benchmarks referenced here are much faster once compiled with ABC, but chapeau2, because of very very slow graphics routines.

http://www.riscos.fr/basic/riscosfr_en.html

What you want is a linker.

Just an automatic insertion of the library code before compilation. Something that will work with unchanged code.

EVAL takes an arbitrary string as its parameter. The contents of this string cannot be known at compile time. The names of variables, their values and the operations on them are not known. The string could contain a FN call that would execute whole sections of the program. It is not ‘Calculation + handling of variables’. ;-)

I repeat: A cut down version of EVAL just for basic calculations. Not a full EVAL.
And yes, ABC will needs to add a small expressions interpreter to the binary. That’s really not a big deal.

Frankly, what we really need is a way to (re)define keywords. Then it would be much easier to optimise or change things (always my idea of bridging to generic code, to avoid all the internal mess around the compiler’s code).

There has been no RealBasic since 2010 – do you mean Xojo?

I know. I used it for my work. Daily. I was speaking of RB, because it’s much more KISS.

Yes, that is highly developed and very OO. Do you really see RO as a target for it?

Not at all. I repeat: “but I was more thinking of something like RealBasic.” I did not talk of Xojo and did not talk of a port of RB.

aaaaa

I really would like if ROOL could provide the source code to Rick for some evolutions :)

I just wanted to play with it, see if I could add in some of the more recent features of BASIC since it is, well, quite out of date; plus maybe some “value added features” (mystring$ = LOWER(mystring$) and the like) that I miss from other systems, but no crowd pleasers as the corresponding code wouldn’t be able to be run on plain BASIC.

A better overall solution might be to open source it, then everybody with an interest can work together. Or argue together, as may be the case. ;-)

Things as ‘no library’

I’m not sure LIBRARY would make sense with a compiled program. I guess ABC programs are not APCS compliant, so wouldn’t be able to be linked with DDE style libraries, so…?

or ‘no eval’ (even a cut down version?)

I wouldn’t even attempt that. There are OS routines to convert strings to numbers and such. The many varied and sometimes freaky uses of EVAL means that the best option is to just not support it. ;-)

or ‘no fp’

I thought it supported FPE? But, yes, it would be better to have options like:

• FPE (generic, slow)
• VFP
• NEON (fast, lower accuracy)
• Autodetect

The last one wiring in code for all of the FP types and trying to see which ones are supported at runtime (so a program is not tied to a specific architecture).

or ‘no new modes and slow graphics’ are really, really annoying.

Yes, that was one of the things I was going to look at.

Hence my later path and a principle that, for a given algorithm, a specialised keyword beats compiled code1. This is best illustrated by whole array operations, where BASIC beats ABC hands down.

Either Sophie is working some especially evil magic, or the ABC compiler is… in need of some attention. If you compile a program you remove the tedious, slow, and inefficient “interpret every line bit by bit” part of the equation so the result must by necessity be faster. That it is not is…peculiar. Has anybody looked at the code generated? It doesn’t “do stuff, stack everything, call a library function (for a BASIC keyword), unstack everything, do more stuff” does it?

I repeat: A cut down version of EVAL just for basic calculations. Not a full EVAL.

What’s wrong with: meh% = this% + that% OR (here% << there%)
It’s a line of BASIC that the interpreter (and hopefully ABC) can understand, no EVAL needed. I don’t think I’ve used EVAL…since the BBC Micro.

aaaaa