OxyScheme (Scheme Interpreter in O2)

[Mike Lobanovsky]

At this stage of the project, I'm inclined to regard OxyScheme interop value primarily from its own standpoint rather than that of its vis-a-vises, whatever these may be. In other words, I'm more concerned about its own versatility as a language implementation than about how, say, OxygenBasic could interoperate with such an interpreter. O2 is already a mature language with lots of possibilities to communicate with its environment and siblings. So the immediate task is to grow OxyScheme's own value to such an extent that it can handle its surroundings with competitive ease. Then the two languages will find natural ways and means to benefit from each other's capabilities.

OxyScheme is not a mere extension to OxygenBasic; it is rather a different language implementation in its own right. It's like the relationship between OxygenBasic and FreeBASIC that the former is written in, or thinBasic and PowerBASIC, for that matter. So, the richer OxyScheme becomes as a language, the more points of contact with OxygenBasic will it have to the benefit of the end user.
   

[JRS]

I very happy for you and Charles that a comprehensive implementation of the language has been created. DLLC is another such effort in the making. I really thought Eros would have come around by now. He must really love Power BASIC.

@Mike & @Petr - "Romania is just third in the world after the US and UK on the standard of living for IT people."

Is that spilling over into your lives?

[Mike Lobanovsky]

@Mike & @Petr - "Romania is just third in the world after the US and UK on the standard of living for IT people."

Is that spilling over into your lives?

Hehe,

Mike lives in Belarus, and Petr lives in the Czech Republic.

Well, no John, it isn't. I think Romania's policy is just an indication of how badly is that country in need of qualified IT personnel. But Romania was one of the poorest agrarian regions in the former Eastern Block, and its status is still very close to that in many respects despite its aspiration to join the EU shorty. It is also very close geographically to the self-proclaimed Transnistria region, unrecognized by the European community, that remains yet another hot spot on the map of Europe similar to Eastern Ukraine, due to Russian aggression back in 1990/91.

The Republic of Belarus ranks the 13th among the world's leading IT countries, and three of our local IT companies are in the list of the top 100 world's largest companies in this industry. Belarusian Wargaming.net is one of the world's leading companies in the modern computer game industry:



The monthly salary (bonuses excluded) of a post-graduate junior developer here would start at about $1K, which is roughly 4 times the median salary in this country, and a typical project lead's annual income (bonuses excluded) would be on the order of 35 kilobucks and more. A guru senior developer can earn as much as $50K per annum not counting the bonuses. Exactly half of the 15th floor in this building is my elder son's company office:




That said, there's absolutely no point for Belarusian programmers and other IT specialists to move to Romania, which would for all intents and purposes be considered as going to exile. However many thousands of them preferred to move directly to Silicon Valley during the past decade escaping the oppressive economic realities of Europe's last dictatorial regime.

[JRS]

However many thousands of them preferred to move directly to Silicon Valley during the past decade escaping the oppressive economic realities of Europe's last dictatorial regime.

In the Silicon Valley you can bring your dog to work when times are good and the employee lounges of some of these companies rival Disneyland.

[JRS]

Mike,

I know this may not be of interest now but I thought I would share the find with you anyways. I ran into a nice Commands & Functions list Peter Verhas did and noticed this command I was unaware of.

POP

Pop off one value from the GOSUB/RETURN stack. After this command a RETURN will return to one level higher and to the place where it was called from. For more information see the documentation of the command GOSUB and RETURN.

I wonder if it would have helped with the SBLisp version of your efforts?

[Mike Lobanovsky]

Nice finding John,

It seems it is an equivalent to that QB4.5 functionality that was used to bail out of its error handler. But the bad news is that in order to employ it, we need to keep an exact count and vector of all the levels of app recursion throughout its entire lifetime. (remember the innumerous i_something += 1 statements?)

Such in-/decrementation kills whatever speed SB's interpretative environment has to offer. My last version of the code that I was trying to port to O2 before I switched to nanoscheme eliminated the need to use this pop-and-jump and in-/decrement method completely. I think I'd better stick with my latest version when I'm back to finishing off the SBLisp project code.

[Mike Lobanovsky]

Hi all,

Coming back to OxyScheme's console interaction with its projected GUI, I'd appreciate your feedback on the following idea of mine.

The Windows console is an odd job that's both crude aesthetically and rather restrictive functionally. Putting it in a non-blocking mode of operation can cure to some extent the latter drawback but it can't alter the former one in any way. So what if we design an altogether custom GUI-based "console" rather than beating about the bush with the system "command prompt" window?

The "console" will be just an ordinary GUI window within the same message pipe as (an)other output window(s) in OxyScheme's common GUI environment, thus making the entire setup much more flexible and less susceptible to possible bottlenecks of true console-to-GUI interface. Moreover, OxyScheme's graphical output can even be redirected to this very "console" persistently (i.e. made not susceptible to erasure by overlapping windows), if needed, which is impossible with MS Windows' true command prompt whose message pipe is programmatically absolutely inaccessible for the user.

To cut the story short, here's a very rough mockup of what such a "console" might look like. It currently supports:

• transparency of both non-client and client areas (the feature that I admire immensely in modern Linux GUIs) adjustable from total transparency to total opaqueness;
• hue (tint) adjustable smoothly within 360 degrees;
• custom-coded aero blur of non-client areas adjustable in 10 steps from crisp glass to deeply frosted glass independently of the actual Windows platform the app is running on. Currently this feature is supported on XP thru Windows 10 in Basic and Classic modes and is automatically switched off in true Aero modes (that's because I don't know yet how to bit-blit transparent GDI+ images from memory to on-screen layered window canvases );
• Vista-style dynamic "reflection" on the main monitor in sinle- and multi-monitor configurations.

The mockup is even functional, more or less, under OSX and Linux Wine except for its blur feature, apparently due to some deficiencies in GDI+/layered window re-implementation in Wine's GUI.

With a little more effort the "console" may be extended to support:

• ordinary caption buttons;
• ordinary resize by window borders;
• ordinary menu bar for file/run/options/help/etc. menu operations.

What would you say to that, guys?

.

[Aurel]

That is very fine and nice Mike..far far better than ordinary console app...
semi transparency with shadow effect is excellent 
I like it.
Only thing is that i cannot grab capture of window with my fastStone viewer..
all in all very well 

[Charles Pegge]

Hi Mike,

The concept of a graphical console has great potential - can you make translucent console windows with OpenGl?

Most of my recent graphical work, including Chain-Shot, has used this kind of GUI. Editable line inputs can be a little complicated, but well worth the effort to be able to blend interactive text and graphics, and to display data outputs in graphical form:

projectsA/OpenglCns/

In the example below, the title and the graph can be moved, rotated or stretched for optimal viewing and snapshots.

.

[Mike Lobanovsky]

Evening Charles,


Not only can I make a translucent standalone window in OpenGL but I can also create a translucent OpenGL overlay within an OpenGL-compatible variable-translucency GDI+ window similar to the one implemented in the mockup!

A beautiful piece of such interactive GDI+/OpenGL compatibility originally implemented in PowerBASIC is attached below. It is just one sample among a ton of amazing submissions written by Patrice Terrier and available at José Roca's site on its GDImage and other relevant subforums.

Patrice's graphical engine however has some serious license restrictions IIRC. On the other hand, OxyScheme is a Public Domain project and I would like it to remain as such. My mockup doesn't use nor mimic a single code line in Patrice's works though of course the basic principles utilized in both approaches are similar and are built around MS Windows' inner workings.

Using OpenGL to implement relatively slow (CPU-wise) textual input-output would IMHO be like using a sledgehammer to crack a nut. The same can effectively be done using GDI+ alone. GDI+ is a system library on every MS platform starting with XP Sp3. The mockup's rendering part is written entirely in FBSL's unoptimized interpretative BASIC except for its highly efficient stack blur procedure that must be as fast as possible at all times and therefore was written in JIT DynC in this implementation.

(Stack blur is a Public Domain adjustable high-performance image blurring algo that of course isn't as good as genuine Gaussian blur but is much better visually and also much, much faster than its direct competitor, the box blur algo. It is in fact so fast that it can even be used for harware unassisted quality blurring of relatively small areas in real time as shown in this mockup.)

Further, GDI+ allows any number of screen windows to be rendered simultaneously in a single process. OTOH OpenGL allows only one physical window to be rendered per process. This effectively means that if we want to use a separate window for OxyScheme's graphical output, we won't be able to do that because OpenGL would already be busy rendering our "console".

But again, if we would prefer to render (some) OpenGL into the "console" window proper, there would be nothing to prevent us from creating an (optionally translucent) OpenGL overlay for the "console" window region where we would like to render to. Then again, the number of yet other possible concurrent GDI+ windows in the process would remain unlimited.

And finally, using a common set of background bitmaps and common skinning/rendering engine for all the windows in the process regardles of their number would create a visually uniform yet adjustable GUI system pleasant to the eye.


Your move, sir.

.

[JRS]

It is just one sample among a ton of amazing submissions written by Patrice Terrier ...

Patrice in his spare time created the Script BASIC logo years ago. I have used Patrice for other projects on a fee basis.

[Mike Lobanovsky]

Yes John, the SB logo is an absolutely professional piece of art. In fact, I've never had any doubt you had to pay cash to have it designed for you.

Yes, I know Patrice has a sorta IT atelier and is likely to make a good deal of his living off of it. I admire almost all of his works very much. He's an artist in the first place and a solid and creative developer too.

[JRS]

I've never had any doubt you had to pay cash to have it designed for you.

The SB logo Patrice did was his contribution to the open source project. I hired him for artwork for client projects in the past.

[Mike Lobanovsky]

Does that change in any way the subject of his being an artist or his z-whatever rendering engine being under a restrictive license? I'm glad though that you managed to save a coupla bucks for better uses.

P.S. And by the way, can you provide any feedback on the subject matter of my graphical "console" proposition? Even if MS Windows is not your preferred environment.



@Robbek:

I would like to hear your opinion on OxyScheme and its graphical "console" too, if possible. I haven't seen a single message of yours in this thread so far. Or are you not interested in the subject?

[Mike Lobanovsky]

... can you make translucent console windows with OpenGl?

Oh Charles,

I just thought that perhaps I misunderstood your question. If you mean whether we can apply OpenGL to Windows genuine console window, either in its non-client or client parts, then I'd say no, we can't. The genuine console's main callback is inaccesseble in the user space nor can it be subclassed. The only two things one can do is get the console hWnd and its graphics hDC for occasional non-persistent GDI drawing. Every other activity on the user side is totally blocked by the system except for ordinary access to its input/output and screen buffers.