Tuesday, January 21, 2014

VOSBASIC! Initial tests successful!

I don't have much time on my hands but I was able to integrate my extended basic source code into the web server last night and get it to serve basic web pages as well as serve for logical processing! You can write and test your script from inside of VOS with proper admin permissions!

I tried doing this with Lua. It is too complicated. Too many includes, too much difficult syntax parsing and too much knowledge of Lua required for beginners. If you know GWBASIC or QUICKBASIC, you can code your own logic and web pages up in minutes! Amongst other things this reduced the executable down to 318K for the code (!), still about 50% of that is initialization data and compiled-in minified javascript!

I have added the following extension keywords to BASIC to facilitate this functionality as simply as possible!
I have not integrated Raphael or SVG drawing from inside the BASIC script yet (this is my next goal), here are the keywords I have added as of last night :

(VOSBasic files end with extension ".VOS" and are stored in general SQLite repository and edited on-the-fly in browser)

IMPORT - includes additional code file streamed from repository 
WEBPRINT - Prints output to current socket with argument parameters and safety checking for overflow conditions
WEBSTYLE - Outputs include statement in HTML for stylesheet
WEBINCLUDE - Outputs HTML for script include for javascript with name
PRINT - Print to standard output with argument parameters, usually current console
LOG - Print to logging output with argument parameters
CGIPARAM - function to get CGI value passed by caller
GETLISTITEM - function that returns value from named list
GETGLOBAL - gets string from global cache from named resource (usually as JSON) 
SETGLOBAL - Sets string in global cache to named resource (usually as JSON) 
DBCREATE - create a new database
DBOPEN - open existing database and return handle
DBQUERY - execute SQL query against database handle and return success or failure
DBFETCH - get row of results from database if exists
DBFETCHNEXT - get next row of results
DBCLOSE - close database and release resources
DATABROWSER - web prints HTML table of browsable database records
DATARECORD - web prints HTML table of editable database information representing one record

One thing I need is an easy way to parse all the JSON tossed around internally inside the VOS Server to represent values from sensors and command calls. Still trying to hammer out the best way to do this as a VOSBASIC expression. Leaning towards something like JSONPARSE(fragment,path) to return the matching value out of the existing JSON and putting it back in a similar fashion. Structured correctly this could allow users to create their own custom AJAX/JSON web services using VOSBASIC script!


Luke said...

318K is nuts. I love your sense of minimalism.

Every time I read about VOS you have made it simpler and more efficient while at the same time adding functionality. The opposite trajectory of most software projects I've seen.

Ted Walther said...

318k... I suggest checking out newLISP again. It includes the functionality you are missing.

samhuih said...

What are those round gauges? Are they Basic, bitmap,?

318K is really small. I'm not sure how you do this. Compressing then uncompressing in memory?

Texas Arcane said...


You are curious, aren't you? How does he do that?

( ;) Sorry I have no life and I am very proud of this stuff)

It works like this :

You upload SVG views or controls on the administrator page and the built-in converter parses them into matching command sequences for Raphael, whereupon they are stored as strings in a table in SQLite. From there they can be attached as views to certain types of sensor data both read/write. The instructions as to how to modify the view to represent a sensor value travel with the drawing code strings, all that really happens is that an AJAX callback does a small value substitution from the real-time sensor data to make the control reflect the current value or send a change back to the server.

The Raphael library can paint amazing graphics using either SVG or VML going back to Internet Explorer 5.5. Most people would not believe what amazing graphics are possible on these older browsers until they have seen it with their own eyes. This is important because Vault-OS is designed to support the ancient thin client devices you can buy on EBay for $1.00 that have onboard browsers of IE 5.5 or 6. These $1.00 devices have MTBF specs equivalent to some of my custom made military grade PC hardware so this is an important thing to remember when designing a system like this.

It takes longer to explain it than it does to actually create a new view and start monitoring sensor data. Seriously. You'll see if I ever get this thing to V1.0 in open source.

Texas Arcane said...

What I was trying to get working last night was simply drag'n'drop and lock position for controls so designing layout views would be trivial.

samhuih said...

That's the craziest thing I've ever heard. I'm amazed. I had to do a little Goggling to see what you were talking about.

I see USB-CAN USB to CAN bus Converter Adapters on ebay for 22.99

Nimadan said...


You've probably seen this already. If not, it's another one for the Making It Up As They Go Along file.

Texas Arcane said...

In 2005 I was wrestling with storing DXF vector files in the background then delivering them to the browser as bitmaps painted on the fly to the server. Looking back now, this system was so crude and so convoluted it was stone age compared to the way I do it now.

I was looking to do modest graphical controls back then static in-between page updates. Nowadays I am aiming for LCARS style graphic interface for all browsers to the shelter server, even on ancient machines ...

samhuih said...

I really wish you would look at REBOL closer. Your hacking together all this huge disapparent libraries and software systems to do what I believe you could do WITHIN rebol. It has networking, database, graphics, vector graphics, message passing. It has been used to program and display the outputs for programmable controllers. It has a full retail store inventory and sales system written you can use for free. Could be modified for inventory and supply usage.

It's the most interesting and DEEP programming language available. It's a LISPy kind of language. Hard to explain. It is also based on Forth. It is basically LISPy that then uses dialects (just like in human language) to limit the domain of what task you are doing at one time. Then when using dialects it becomes more Forth like. The idea being that with small primitives you can get incredibly complex ideas or processes. It's based on human language where small parts can be added to make big ideas and also how words are interpreted different in different situations.
A big part of why I believe you'll like it so much is the basics are so simple yet it's deep, deep, deep. You can get way off into specifying exactly what you want. The first two links below are the links for the basic graphics system. Very very low level. The interface dialects most people use are built on top of the View graphics system. They are called VID (the original), Saphir R3(modded VID), R3GUI(new VID), , , RebGUI(modded VID), Saphirion RebGUI(modded RebGUI). My basic understanding is all the mods are based on VID. ALL are built on the same graphics library(View Graphic).

REBOL/View Graphic System Reference

DRAW Dialect Reference

Here's a better description

Specific intro

REBOL 3.0 Features & Objectives

REBOL 3 Documentation

Here's a couple of tutorial pages that are good.
The Easiest Programming Language: REBOL
Cross Platform App Development with Rebol 3 Saphir

Here's saphirions' page, referenced in the above tutorial. They have different graphics libraries ALL built on the (REBOL/View Graphic System) library above. The different graphics libraries? systems? (really dialects or Domain Specific Language). The Saphir R3 is the latest up to date that the company uses for their own work.


Last but not least. One of the best Rebol programmers is rewriting Rebol. He's calling it Red Programming Language. He's correcting faults he's found and making it compilable. He's separating it into two parts. Red/System which is low level "C" type program written entirely with Rebol. Then he's writing Red which is comparable to Rebol. Which will be interpreted and JIT compiled. He's already written Red/ System. So the language AND compiler is less than 2Mbytes. What's GCC for C and C++. 100 Mbytes? It's big. He's now working on Red by using Red/System to write it.

The bad. Since Rebol 3 is fairly new open sourced it's not finished and neither is Red but both are being used to write applications. Documentation suffers because there are changes in Rebol 3, Rebol 2 and Red where as most of the docs are for Rebol 2. So it does take a little looking around to get the right answers. I can't help but think one tool chain will be better than the five or six you're trying to integrate. Sorry so long but Rebol is so interesting.

PrairieSage07 said...

I am a little behind on the Vault system idea... could you perhaps make a general list of parts needed to assemble a system?

I have a personal library of books on CDROM/DVDROM that is over 700 disks.

Would there be a way to include a method of playing dvds?

Chad father of nine

samhuih said...

Don't mean to be so annoying but this interest me. If you're running vault_os on thin clients. What's vault_os running on? You say it will run on DOS but will Internet Explorer run on DOS? If not what. Linux? QNX?

An added clarification about Rebol I missed. This waa what I was trying to say about the Rebol in my limited way.

Comment on Red vs. Rebol from

[–]reboler 5 points 5 months ago

The author has said that he would prefer not to market Red just yet because it's still in the boot strapping phase, and the information may be mostly understandable to REBOLers, but the gist is:

Red is a 90% clone of the programming language REBOL.

Red was devised, because REBOL was closed source at the time and development of REBOL had nearly stopped.

REBOL is no longer closed source and development is moving again, but this has not affected development of Red.

REBOL is written in C. Red is written in Red/System.

Red/System is syntactically similar to Red, but has C-like performance.

Therefore Red/System code can be inlined with Red code, allowing C-like performance in scripts, something that REBOL cannot do.

Red scripts can be compiled for speed, where REBOL scripts cannot.

As REBOL is an extremely generic programming language for scripting, Red is even more generic. It can therefore provide the full reach from hardware banging to writing 3D engines to high level scripting, using the very same syntax and tool chain. As far as I know, no other language or tool chain does this.

Red/System provides its own, extremely small and clean toolchain (a few kb of scripts) for building Android apps, Windows kernel drivers, executables for win32, OSX, Linux, etc. and supports x86, ARM and soon other CPUs as well as support for multi-core CPUs and full support for cross compilation.

Red and Red/System are being boot strapped at this time, so REBOL is required for compilation. When REBOL is no longer needed, Red is no longer limited to operating systems that REBOL support.

The Red language is not yet completed.
( an aside, Red is clocked at four times slower than "C" at this time with no optimization.)

samhuih said...

One last question. I was going to ask about XMLHttpRequest. I found out about this goggling around trying to figure out how you made the gauges but I forgot the page. Found it again.

It this what you used to feed the data (if feed is the right word)to the web page? I note the page above says,"...XMLHttpRequest is used heavily in AJAX programming..."

samhuih said...

Wow. That LCARS home automation video was radical. So good looking. Closed source for now I read.

Texas Arcane said...


REBOL is interesting but it doesn't support certain platforms I might want to compile for, like
ARM and x86 DOS.

I am going to have a look at it tonight to see what is involved in building a web service with it. Since it has such powerful graphics capabilities including SVG it might make a really good choice as a web server.

Can you point me to somebody who has successfully compiled this for DOS or an embedded platform? I would be much more confident in building on top of it if I could find some example like that.

You are right, it is a very clever platform and very simple.

Texas Arcane said...


I love talking about this stuff.

The amazing thing about XMLHttpRequest is that the capacity to do AJAX proper goes back to IE 5.5 and very early Firefox!! It is the paradigm which has taken people by storm since 2006!

AJAX is fantastic but Javascript is an appallingly bad language for it. You have to work with what you've got.

My architecture produces awesome vector graphic displays on browser so old they fart dust.

When I was designing VOS I asked the question ... where do people get military-grade hardware for the shelter for $1.00 ? So anybody can afford it?

Old thin clients are perfect. They are robust and run very fast for nearly any browsing use.

I foresee one server with a dozen browser clients in a medium sized retreat or shelter. To answer your question, what run on the server?
It's just a reflashed thin client! Almost all models can be burned with a simple tiny version of DOS, Linux or Windows that runs the server code!!

Example : What's the cheapest, sorriest, oldest, crappiest thin client device you can buy! Compaq EVO T30! It's junk! Nobody wants it! It's a boat anchor ... right?

Wrong! Running VOS it will become a super stable robust embedded SCADA control server and full fledged shelter manager supporting dozens of concurrent clients!!!!!

Texas Arcane said...


... and all compiled-in Javascript libraries are stored as .gz compressed files, which turns the JQuery library from a 120K leviathan into a 24K pipsqueak, etc, allowinf for inclusion of some pretty sophisticated and interoperable javascript with a hit about 80K the first time the page is loaded. After this the file is in cache and the actual web logic is 2k-3k at a time written out on the fly at the server, making it incredibly fast compared to something like PHP even with memory caching on a formal disk storage driven server.

Texas Arcane said...


The "memex" in VOS is intended to be a web page driven browser for a reference library which may be stored on external devices. You can associate keywords and ideas with each entry so you can rapidly search your data for reference documentation you may need, like "water purification," "treatment for toothache," etc.

PrairieSage07 said...

this sounds like a simpler solution than my original plan... a few 1T external hard drives some external USB DVD drives, and some netbooks.

samhuih said...

Understand I'm not knocking what you're doing. It's just over my head. Too many systems that I don't understand the variables to. You've done so much programming with these tools that the little stuff doesn't bother you. Think what someone who hasn't would have to do JUST to load all the software and get it not to explode in their face! All the little gotchas you had to learn to work around to get this mess to meld together. The whole software infrastructure is so gobbed together that it's ridiculous. JSON is a big deal why? Because the whole thing is so gobbed together that a simple way to talk between two programs is seen as an advance. Excuse my negativity but I've still got an Amiga 2000 that loads it's operating system on a floppy and I'm not seeing 500MB's worth of advance in new operating systems.

Web server

"...Cheyenne aims to be a full-featured Apache-class web application server..."
Done in Rebol. The guy that built it is coding Red Programming Language.

Rebol 3 micro web server

Part of the problem is Rebol 3(open source) and Red P.L. are in flux. In case you can't tell I'm super excited about this. The only formal programming experience I have is FORTRAN, Assembly on Z80's and programmable logic controllers. I've written a few "C" programs for an exercise and a slight Forth(which is aesthetically pleasing to me). The problem is I don't make a living at this and after reading( or looking through) JAVA, C++ books, etc. it's just hopeless. I'm not going to extend the kind of effort it takes to learn this mindless profusion of hash marks to throw something together every year or so. I liked the idea that Mozilla could be used as an interface until I read how you did it. It's not really clear that's there is an explanation anywhere. Just a memory dump of that all leads back to JAVA, DOM. lots of UHTML and a barrel full of gibberish.I refuse to be abused by JAVA. I'm not going to type for thirty minutes to open a, (useful not Hello World), window.So when I found Rebol, Eureka! The main problem with it is it was originally closed source and wasn't kept up to date. Now it's open source but only a year and it still needs work.

I bet you could make some serious change with Rebol Saphir R3. It so fast to get meaningful results. You could throw together a minimal interface in a few minutes. Sells your clients quick when they can see a window and a couple of buttons. Even though you know that's not the program. They don't and they feel like great progress is being made. Rebol has all the bells and whistles built in but simple stuff is simple. Think of how many people need small inventory/work schedule/hours billing/ customized programs etc. If you could throw them together fast and charge a reasonable price for something the average Sapien could use you could print money. People don't want to program a spreadsheet to add up a few labor jobs. You could provide that in a format they could understand. (1) Brian worked on(2) Jim's Job (3) 4 hours (4) press button (5) total!

samhuih said...

After all this babble I'll answer your question. I have looked for Rebol3 running on DOS. Others have asked also.

It would seem to be a winner since Rebol has a built in interface but right now it's not available. But look here. Red/System for DOS.
RED may soon meet your needs.
I think REDS going to be even better than Rebol. It takes out some of the old crust that had built up in REBOL while saving it's innovative structure. I'm not sure what they're going to do about the graphics. I hope they keep the old VID and other graphic subsystem. I feel fairly certain that they will have some of graphics close to Rebol because of the enthusiasm the RED programmer has for Rebol. I know they have or are working on bindings to gtk. The guy who's doing the gtk bindings says he's using Red/System and Red for commercial work now. He says that you have to watch your memory allocation to do this cause garbage collection is not finished . Since he's writing part of the code for Red he can get away with that.

Linux ARMv5
Linux ARMv6

Raspberry PI
Cross-compiling Rebol for your favorite embedded board

RED Cross-compilation targets:
MSDOS : Windows, x86, console (+ GUI) applications
Windows : Windows, x86, GUI applications
Linux : GNU/Linux, x86
Linux-ARM : GNU/Linux, ARMv5
Darwin : MacOSX Intel, console-only applications
Syllable : Syllable OS, x86
Android : Android, ARMv5
Android-x86 : Android, x86

I wonder what the "(+ GUI) applications" in "MSDOS : Windows, x86, console (+ GUI) applications" means for RED? Maybe it's what I was talking about. You would be more technically savvy than I to answer that question. Please let me know if you find out.

Here's a good RED page that shows the "BIG" plan plus bindings they already have. Looks like GTK+ for graphics. They're also saying HTML5 for graphics/Windows.

Just read the main contributor and founder of RED programming is moving to China. We're doomed. They recognize greatness. He's been surviving off of donations. No one in the West has room for such genius. More Facebook, phones that play angry birds. That's what's important.

Know what I did today? Put out fires. A Negro next to my property burned some trash. Forget he's supposed to put the trash in the trash can in the first place. In a no rain,dry, county declared, "no-burn" situation. He didn't watch the fire, had no hose to put it out, called the landlord,"I can't put the fire out and don't have any hose". Ten firemen, two pumper trucks and a bulldozer to make fire breaks through my property and my neighbors. If you knew how angry I am. If there ever is a serious disaster they're going to need water. I'll have water. I have a creek and a spring. When they step on my property. They're done. No talking. You can't talk to people like this. They are devoid of all reason and responsibility.

Texas Arcane said...


Seriously, you are selling me. I looked at REBOL all weekend long and looked at some of the tutorials.

One thing I searched for and couldn't find was hardware sensors for serial/parallel/SPI etc.

... but I discovered you easily interface to mailslots, like I do in VOS! So I might be able to run my current daemons (stolen from project) and simply intercept mailslots inside of REBOL for a VOS based on REBOL.

It is very intriguing and I am grateful for the information. I am especially interested in the fact I could stop writing boilerplate code and just write VOS in this stuff.

I saw some of the CGI, webserver and even JSON code. There would be nothing stopping me from supporting all webserver functions I do now and I might even find it easier to support some I am currently just dabbling with like UPNP (agnostic automatic identification of other VOS machines running at bootup as well as UIPNPN peripheral devices)

Seriously thinking about it. I might write VOS in a week instead of 12 years if I switched to this. :)

Texas Arcane said...


The DOS port has been less and less important to me, mostly for the purposes of providing for the barest minimum system with FreeDOS for users. I had compiled it to run without even needing DesqView the last time I built a DOS-32 executable.

I have learned over the years how to launch a 2 MB mini-Linux or a 5 MB mini-W98 or a 4 MB FreeBSD which all will run VOS. It seems like REBOL/RED could just as easily be compiled to all platform targets and run the same basic REBOL.

REBOL has tons of sample code how to write REST AJAX services with JSON with much greater ease than I currently enjoy in C code so that makes it pretty attractive as well.

Texas Arcane said...


Found this REST call processor in 70 lines ...

samhuih said...

I'm glad you like this. That's why I kept bugging you about it. I'm not a programmer like you but I've been looking at all type of computer languages for a long time. You don't have to be a genius to see genius work and recognize it. I've always been enamored of Lisp but common Lisp has a gazillion parts. Who can remember all this? Not me. I need something easier. I've also really liked Forth but it failed in doing large things. Rebol is a kind of Lispy-Forth with some conditional "C" type stuff you do in dialects. I don't completely have a handle on it yet or even close. I can see it though. It makes sense to me. Unlike a thousand pages of JAVA which you then use to parse a thousand page manual of HTML or XMTL.

This Rebol link I posted before is important
It covers most of the basics to get the interface going. Networking, mail slots, not so much. The same guy(Nick) that wrote the above link has a very good link of links on this forum. It's in the sticky at the top. Lots of good links. You can also see I(Sam) asked about the GUI and how the different Rebols and RED GUI's are related.

I found a free book. It's based on Rebol_2 but it seems to have really deep in depth coverage of Rebols internals and Rebols reasoning. It's now free. I'm reading now.

Ah found something that may help with low level stuff. Video by the Creator of Rebol on using Rebol "Home Automation With Insteon". Insteon being a X10 compatible device.
Home page with link to video


Also good to watch is RED overview by the guy writing it.

And one more just to show what can be done. Industrial automation with Rebol

samhuih said...

I've been watching the videos I linked and a thought came to me. The last time JAVAscript updated on my computer I think it was something like 18M. I know a lot of this is libraries and it's not all used at one time but think of the power suck. And it's just one small section of code that has to be run. The operating system has to be run too and what if it does need part of JAVAscript that isn't loaded. Read the disk. Glacial. What if all your software could be in memory? Maybe even in the cache on the processor most of the time. A BIG program in Rebol is 200K.

I don't think you're wrong about DOS. Stability is important. I think RED will eventually be usable with DOS but Rebol3 can be used with XP. I noticed a lot of the thin clients ran on XP. XP should be stable enough. I run XP and it's incredibly hard to crash. It mostly just bogs down if you try to do to much at one time. In your situation you would know the load ahead of time and it shouldn't be a problem.

Texas Arcane said...

One of the confusing things about Javascript is its arbitrary name. Javascript has nothing to do with Java, it was just a marketing gimmick timed with the release of Java.

Javascript is a built-in browser language for any browser supporting HTML 1.1 or higher. It is a terrible language, although steps have been made in recent years to improve it and add reasonable debugging. I have written some pretty complex graphic displays with it and I think it is total crap. You work with what you have and almost every thin client you can buy will have a minimal browser on board supporting AJAX and Javascript. If it supports Javascript it can run Raphael and Raphael can create some amazing vector graphics.

If I wrote VOS in REBOL it would still deliver content the same way, as real-time javascript graphics. It is the server that would be different, not the client end.

samhuih said...

I think I understand your wish to display with a browser but step back a minute and think why. Browser as all is the latest "BIG" thing. The browser as display for all is a great idea but is it necessary in this case.

Basic Rebol2 has extensive communication built in. Graphical display of information is easy, easy, easy. Rebol3 may be a little more modern but you might have to fuss with it a little more. If you don't like rebols comm. here's another.

0MQ can talk to RED and Rebol. Red/system can be compiled on PIC's and ARM's and cheap DOS boxes. Arduino's even.

Use Arduinos for data gathering. Network to thin clients or whatever. You're done. Well not really done but it would provide a knowable path to completion.

Then instead of counting how many angels can fit on the head of a pin do something really "Important" like helping to get Rebol3 and RED into a finished form. It would suit your (maybe :) ) excessive need to fuss with everything while providing a great benefit to all humanity. If you hate humanity do it for programmers. Best of all RED will NEVER be finished. If you watched the RED video's, in one he says he is going to add modules to the compiler and linker so they can be modded. Even in real time. Wow! The perfect tool.

Texas Arcane said...

The reason I concentrate on the browser is that for Ma'n'Pa retreats with people of limited means and technical understanding, simply having a big room of discarded thin clients may be the closest they come to having maintenance.

I am trying to make the server as simple as copy an executable (complete) from a floppy or USB and run it. Zero installation, zero configuration. I am trying to make the clients as simple as plug it in, run the browser on the thin client and connect to the server.

So Ma'n'Pa after the apocalypse won't know why after a few years suddenly something stopped working. They won't know how to fix it, or be able to diagnose a flash ram failure, etc.

All they will be able to do is reach in a closet and plug the ethernet cable into another thin client. Bam, whatever the problem was it is fixed now. I have tried to think fo an architecture like an Etch'a'Sketch tablet, too simple to fail and when it does, plug in another tablet. Bam IJW - "It just works." They may not even understand how browsers work or what they do. They just know to plug in a replacement, something somewhere has failed.

For more sophisticated users, all maintenance really consists of is having a few cheap generic x86 machines, thin client/laptop/junk PC with 1992 specs and you're done. VOS is meant to run forever with zero understanding of the internals.

Texas Arcane said...

The only good OSes for VOS are ones that can be compiled as a full install in tandem with the executable. So a mini-Linux in 2 mb or FreeDOS are great choices. Many mini-Linux distributions will automatically recognize 90% of the network boards available so unlike FreeDOS you won't even need a packet driver. You just copy/xcopy and now it runs and works. That's the idea. REBOL might be good if I could make it a seamless part of this tool chain to starting the server.

samhuih said...

I'll leave it alone. By now either your convinced, interested for later or not interested. Just wanted you to be aware of something I thought might be helpful.

Texas Arcane said...


You have converted me to full blown REBOLism. I will probably finish what I have with Vault-OS but I am sure there is a place for me in the REBOL universe in the future.

samhuih said...

Not REBOLism. REBOLution. I read the term REBOLution on a forum and liked the name of it.

I've been reading more about the R3 graphics. I think it's a bit of a mess/ Not sure. The old graphics R2 had as a part?/major? section made up of Anti-Grain Geometry (AGG) graphic library. Interesting library. You might could use it directly. It's very small. Could be of use to you. I wonder if it could not be used in Rebol3 and Red? The graphics libraries for RED they say are going to be native to the platform. Big mistake I think. If they could use a vector library like AGG then FAKE the interface graphically with styles. That way you wouldn't have to keep binding s for so many libraries. Yes it would be difficult to fake these but is it any easier to make a continuing changing binding for the libraries? Maybe I don't know what I'm talking about. Just a notion.

Texas Arcane said...

AGG compiles nearly anywhere. It is in very simple source. It has been compiled with OpenWatcom.

samhuih said...

This is probably not the best way to talk about this. I discovered an old technique to talk to OLDER browsers.

Netscape Plugin Application Programming Interface (NPAPI)

Still looking around. Also found SVG Tiny. A WWW standard that does vector graphics in new browsers.

Hm... very interesting. Make a great simple interface. It's used on phones also .My only problem is I don't know how to call the browser with Rebol or Red. You wouldn't happen to know how I write to the page would you? Especially if it wrote to XMLHttpRequest which would update the page every time I wrote to it. Do you know a link that talks about how to interface without JAVAscript or can I use a small link or piece of J.S. just to get the port?/communication channel?/function? open and write to XMLHttpRequest? Why does it have to be so difficult? Can't they just make an easy way to write xml to XMLHttpRequest and have the browser display it? Such BLOAT everywhere in software. I looked at JQuery library but there doesn't seem to be a way to call it to call the browser. Writing the thing in J.S. would defeat the whole purpose. Any key words I could use to search in Goggle would help narrow it down. I actually understand assembly and HTML/XML while wordy I can handle. The middleware is killing me. :)

samhuih said...

Read your post again. You're talking to the browser in BASIC. How are getting the reference point to start talking to it? I see this page. Makes sense.

Also this code makes sense."GET","ajax_info.txt",true);

My question is how to open the browser and tell it where "ajax_info.txt" is. Does the browser know it's opened at a certain point like,"C:\Program Files\Rebol" then knows where the text if from where the Rebol program opened it? For example if the Rebol program had the file "ajax_info.txt" in it's directory would the browser automatically know this or would I have to give the whole address like"C:\Program Files\Rebol" ?

I like the JSON idea but the less interfacing the better. Could you post the snippet of code that opens up the BASIC script to the browser? Maybe I could figure out the rest.

Texas Arcane said...


JQuery is a javascript library that wraps Ajax calls through XMLHTTPRequest to make it into a simple asynchronous call. You have a little snippet that calls the correct web service address ... which could be almost anything but nowadays generally it would be expecting json format request and would return json.

Through JQuery you make the call and pass the name back of the routine you want to be called with the results. It then happens asynchronously and the Javascript can do other things while waiting for it to come back.

The most common way to set this up is to have a Javascript structure that represents the page data. It can be empty or filled with data and simple updates itself when the async call comes back.

If you go to the JQuery site they have some excellent tiny examples of calling methods through AJAX and getting results back to populate the page.

It is mostly confusing because of course people have now started to tack full frameworks like Angular and Knockout on top of this, requiring you to learn HTML/CSS, Javascript, then JQuery, then finally the next abstract framework on top of that. If you were suggesting that is all overkill I heartily agree.

Some people have been using Javascript compilers like Dart to write their JS in a nice structured language that then compiles out to shonky javascript where the interface is hidden from you for the most part. This is the way I would like to work with Javascript and libraries but most people assume if it is a huge complex framework and it is new then it must be good so that is what they ask me to work with. I find anything that goes beyond JQuery and simple CRUD starts to become unmaintainable.

samhuih said...

"... calls the correct web service address..." BINGO. That's what I want to know. I started searching for that and I think it's going to give me some good links. Thanks for pointing me in the right direction. The idea being, why use Javascript? An address is an address. If you feed it the right structured data does it know it's not JQuery? Of course not. Mind you I don't know .5% of what you know but if I can interface with XMLHTTPRequest I can keep throwing code at it in XML pages until I understand. I don't even know HTML, XML, etc. I've looked at it though. It's just a lot of words with formatting explanations and commands around it. Never had a need for it guess I'll have to learn a little.

I noticed while searching that all you said about formworks was correct. Mass complexity added to simplicity to sell the IT managers. Fancy web pages, newest thing, Bling Bling, win a doll. Argh. Nonsense.

Here's what I'd like to do over the next year or so. Learn to interface Rebol with a browser and feed it Tiny SVG. If that works then maybe work up a dialect that feeds TinySVG XML to web pages.

The reason I've never taken to programming is all the sloth they pile on. I've seen how interfaces are done in C and C++. I won't say I understand them but I could if I put in the effort. But to what end? I don't have anything that I NEED to program but with Rebol if I can work up a little tool to get SVG on a browser I could do a lot of stuff without days of tedious interface work that I refuse to do. I guess it makes it more of an intellectual, hobby, tool pursuit that interest me more. I did like assembly but for interfaces? Please. I've seen code for that and I'd sooner bath with ground pumice every day. Thanks for the excellent pointers.

I wrote the above a day or so ago and have been searching every since. All these frame works depend on JAVAscript. I know somewhere there's an address for XMLHTTPRequest but don't know how to find it. It may even be dynamic. I believe that XMLHTTPRequest like most function names is just a pointer that is placed on the stack or in a register. Then Javascript sets a flag somewhere saying it's there and your program reads the pointer to find the data. Finding the method of passing this, address or pointer seems to be very hard. I guess they don't want you to know so you'll use their monstrosity to do it. I looked at web service addressing and it's a similar story. Looks like the easiest way is to make a local server to pass a page to the browser with XMLHTTPRequest in it and let the Javascript in the browser return the data. Figuring out what it's returning might also be problematical. I wish there was a way to do this without Javascript because I usually keep it turned off with noscript plug-in. Only allowing it when needed. I guess next I'll look at GWBASIC and QUICKBASIC to see how they do it.

A question are you calling the browser with Basic and using XMLHTTPRequest to send and receive data or is there another method to pass page data? I also know another way by placing script tags can be pointed at any URI but I don't like that and bet it will be blocked at some time in the future. I think they also do the same in frames that are invisible but that will probably be blocked at some time too.

Texas Arcane said...


The simplest way to explain it is to think of VOSBASIC as a server side language only. It writes out the page that is delivered.

In addition to being able to print out regular HTML and CSS to send downwind, it can also print out calls to the attached javascript (simple resources loaded as binary .gz like any other URL resource) and even custom snippets of Javascript into the HTML to set up data for those libs.

Once delivered to the browser, it is the browser javascript code that makes the AJAX calls to get real time data and update the vector graphics in Raphael. So the browser does all the drawing of the graphics and then alters the display via calls to the AJAX interface. What the VOSBASIC has sent down to the browser is the addresses of those AJAX calls and the parameters used to draw the display.

samhuih said...

I understand thanks.You may want to look at these. Maybe not. I found this program/frame that helps automate the building of web programs with just the frame work you suggested. It's quite interesting.

Also for kicks a new basic with tutorial by the same guy I linked for the Rebol tutorial.


Learn RFO Basic - The Easiest Way To Create Android Apps
By: Nick Antonaccio

and a link to a RFO Basic! forum topic on developing code for browsers.

A book on using jquery and jqtouch for iphone which is simular for others cause it's run through the browser. Free! Building iPhone Apps with HTML, CSS, and JavaScript
You may know all there is to know about this already but maybe the tool will help you or someone else that reads this.I think I have a good path now. I need to find out how RFO Basic! does it then write or cobble together something in Rebol. Maybe using the jQuery Mobile tool after I get an idea of what to do. I'm guessing the jQuery Mobile automates making all the interface scripts and mark up. Nice to have if it works. Save you lots of head scratching.

samhuih said...

Oops sorry. I just realized I sent you a link you already sent me. :) I looked at the but didn't understand. It was only when I got to the jQuery Mobile that I understood. They don't really make it clear exactly what they're doing on the first page.