Lisp in Basic

[JRS]

Mike,

It's not that I'm blowing you off, it's Charles's forum. Just because I have keys doesn't mean I drive. I will always back Charles up if he is sleeping and someone does something grossly outside forum policy. (Aurel has crossed that line in the past)

[RobbeK]

Great Show, Mike,

Well, not through the 1000 page documentation of GFA     -- seems no DirectDraw available (too old ?)  , but it has bitBlt 'ing and OpenGL works too now ,   we'll c
I wonder, you surely know --  those older programming languages do they miss the more modern numeric possibilities from the newer processors ?   (i think to remember GFA died in 2002  )


best, Rob

[Mike Lobanovsky]

Hi Rob,

Thanks for your appreciation. It wasn't a show-off though, it was rather a gentle push forward in the right direction. Since John allows himself such "passes" at you then I just thought why shouldn't I be allowed to do the same, if only from time to time?

DirectDraw is a Windows-only technology and like all their other DirectBlaBla stuff, it is OOP and interface oriented, not low-level enough to my taste, shaky and slippery, and intended primarily for C++ development environments. Fond of MS Windows as I am, I've never used these layers of MS technology for my own work and was more than happy with OpenGL. There's nothing DirectBlaBla can do that OpenGL and its peers can't.

There are basically no new numeric possibilities in i386 CPUs of today as compared to 2002. VB6 is much older than that but it still enjoys all of Windows math-wise functionality there is. It would be another question if GFA can enjoy/employ other benefits of modern CPU architectures such as e.g. multithreading et al. to their fullest, and also how efficient its native code generation is. But here I can't give you any advice because I've absolutely no personal experience with this BASIC except having read a couple of your GFA scripts so far.

[Arnold]

Hello,

I have not yet read all of this thread (page 12 of 65), but I found Mike's Lisp in FSBL and also found the author's website   with the source code and documentation. Inspired by Ruben.o2bas I tried to adapt the listing to Oxygenbasic. I did not expect that this would work.

After I finally succeeded to start the program I noticed that it was incomplete and faulty. Fortunately Mike had already fixed all the errors which I found, I would not have had the patience to do this. So I shamelessly copied his code.

The program works, yet I will not waste more time with it. But would it be possible to create a working executable for Win 64bit?

I will try OxyScheme to learn a bit more about Scheme.


Roland

.

[Mike Lobanovsky]

Hi Roland,

So I shamelessly copied his code...yet I will not waste more time with it

And you did the right thing because, frankly, this code isn't worth any other investigation and/or development. John and I invested much time in having it fixed and running in ScriptBASIC, FBSL, and OxygenBasic in parallel, only to find out that it was conceptually too limited and hopelessly slow. So, we abandoned it in favor of TinyScheme (John and his SB) and nanoscheme/OxyScheme (your humble servant and FBSL/O2), respectively. These implementations are incongruously faster and more versatile than LISP-in-BASIC.

But would it be possible to create a working executable for Win 64bit?

But is it worthwhile anyway?

I will try OxyScheme to learn a bit more about Scheme.

Please do! But Charles has added some improvements to O2 that may have rendered the OxyScheme source that I had posted on this forum inoperative. In fact, I'm waiting for a stable version of O2 to be released and then I'm eager to resume my OxyScheme effort again. I think we need Charles' comment on whether the OxyScheme source is compatible with the current release of O2 and what fixes should be added in case it isn't. I haven't looked into this matter myself yet.

[Charles Pegge]

Hi Roland and Mike,

There is a maintained version of OxyScheme in projectsC. It has a few changes from Mike's original, such as indexbase 0, and some @ pointer returns.

I've had a brief session to make it compatible for 64bit operation. Few changes were required, but it needs a deep debug session or two to get it working.

[Mike Lobanovsky]

Hi Charles,

Thanks for commenting on OxyScheme's current status.

Did you update the assembly macros at the end of the script for 64-bit compatibility? Also, the script relies heavily on C-style setjmp/longjmp functionality that's emulated at the beginning of the script. It is my understanding that this setjmp/longjmp implementation isn't compatible with 64 bits because of the CPU registers involved. Have you been able to also fix this issue?

[Arnold]

Hi Mike,

I have not yet started with OxyScheme, but I noticed that using (quit) will only freeze the console. If I use:

      case OP_QUIT '/* quit */
        print "Bye" cr "Enter..." : waitkey()
        ExitProcess(1)
        'return NIL

the console closes normally and taskmanager does not continue to show gxo2.exe. I can also compile and run the program without problems. But I do not know if there are other aspects which have to be considered.

Roland

[Mike Lobanovsky]

Roland,

Please follow the dedicated OxyScheme thread. I remember John pointing out that bug to me and there was my quick fix to it.

[Arnold]

Hi Mike,

thank you. I was not aware of this thread.

Roland

[Charles Pegge]

Mike,

Yes, I've done those 64 bit things
Any call to  __p__iob() causes instant GPF.

Is there a substitute for obtaining an _iob FILE pointer ?

I'm tracking through the startup sequence, and I'll watch out for the longjmp.

[Mike Lobanovsky]

Charles,

Any call to  __p__iob() causes instant GPF. Is there a substitute for obtaining an _iob FILE pointer ?

AFAIR there are three different foo exports in a 32-bit msvcrt.dll that should be aliases to the same executable code to yield the _iob FILE array pointer. But again AFAIR __p__iob() was actually the only one that did the job while the others seemed to be only stubs yielding zeros.

I'm currently under 32 bits and also I don't remember if I have any utility at hand to inspect a 64-bit DLL's exports to give you any meaningful advice. Again I should look through MinGW/GCC includes to see if there's anything particular mentioned in them for 64-bit compilation. May I reboot and check it all later on? I've got some important interaction with other correspondents at the moment that won't be very convenient to interrupt.

I'm tracking through the startup sequence, and I'll watch out for the longjmp.

Setjmp/longjmp are used to reset/recover the interpreter to its initial state after a failure due to bad Scheme user code or abnormal garbage collection states. At any rate, the #define USE_SETJMP flag can be remmed out, in which case the interpreter will simply abort after any such exception.

[Charles Pegge]

Mike,

As I recall, this complexity arose from coercing MSVCRT route its console outputs through the STDOUT pipeline, so that console output could be redirected when using printf or fprintf

It could be avoided by using sprintf and feeding the strings to the standard console output.

We can let this topic rest, if you prefer. Your dynamic glsl shading idea must take priority

[Mike Lobanovsky]

As I recall, this complexity arose from coercing MSVCRT route its console outputs through the STDOUT pipeline, so that console output could be redirected when using printf or fprintf

Exactly! It is an rXrs requirement that Scheme work with files and ports (evidently it dates back to the prehistoric *nix and tti times), and STDIN/OUT/ERR jugglery that's very easy to implement in C (in fact, it is its integral feature) allows us to abstract and reuse the existing source code to access those devices in all their manifestations. As soon as we decide to deviate, we (or rather I) will get OxyScheme and DynC nanoscheme out of sync. But I'm almost ready for such a sacrifice. I, for one, consider other things, e.g. a solid GUI, much more important for old-timers like LISP, Scheme and BASIC than compliance with ports/terminals/whatever else that's alien to, or unnatural for, the concepts of modern graphics OSes we're working under.

We can let this topic rest, if you prefer. Your dynamic glsl shading idea must take priority

You shot and missed!

I'm currently earning some money under camera and keylogger surveillance by my contractor, that's why I'm somewhat reluctant to interrupt the session (though I'm itching all over to do it a.s.a.p., I must admit).

[Charles Pegge]

Spymaster! 

It occurred to me that, the easiest way to create Scheme with a full GUI framework would be to create a Scheme-->Basic preprocessor. In Oxygen terms, this would take the form of a customised compiler, supporting both static and dynamic compiling. Similarly in FBSL, such a scheme would be firmly linked to FBSL's frameworks and future development path.