All BASIC

Message Boards => Translators => JADE => Topic started by: AIR on January 07, 2019, 09:35:46 PM

Title: JadeLib
Post by: AIR on January 07, 2019, 09:35:46 PM
Link to the repository is in the sticky'd post.

Major change is that it now creates libjade, which speeds up compilation etc.

I've also updated the Makefile to support MinGW.

AIR.
Title: Re: JadeLib
Post by: John on January 07, 2019, 11:17:59 PM
Quote
I've also updated the Makefile to support MinGW.

Very kind. Thank You!

I can see a makeover of the C BASIC include file based on your direction but for ANSI C.

I would like to come up with a module maker like to author did for the the JAPI extension module but using C BASIC as well.
Title: Re: JadeLib
Post by: jack on January 08, 2019, 03:29:15 AM
hello AIR
thank you for JadeLib and for the very permissive license
just a couple of notes, I had to comment out the Windows specific equates in the makefile to build the lib using msys2
in the example demo.cc, INSTR(mystring,"is") gives 2 as the answer, where mystring = "This is a string."
FreeBasic and QB64 give 3 as the answer.
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 09:55:41 AM
in the example demo.cc, INSTR(mystring,"is") gives 2 as the answer, where mystring = "This is a string."
FreeBasic and QB64 give 3 as the answer.

It appears that FreeBasic and QB64 are using an index that starts at "1" for their instr command (and other string commands), where as Jade is using a "0" based index.
Title: Re: JadeLib
Post by: John on January 08, 2019, 10:25:25 AM
I can accept zero for a starting array index because SB supports negative indexing. C / C++ shouldn't call an arrary of characters a string.
Title: Re: JadeLib
Post by: John on January 08, 2019, 10:42:59 AM
FYI

Quote
  Hi Johann,

  We eventually build a MacOS binary using GTK. But the experience is bellow normal. GTK works best on Linux, other platforms, including Windows, are not comparable with native applications.

  I'm having some issues with our Mac used to build it, but I hope to have some binaries soon.

  For the future we expect to have a native MacOS driver functional. It is a contribution from Eric Wing, but there is no time frame for a stable release. He needs help by the way.

Best,
Scuri
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 10:47:40 AM
FYI

Quote
  Hi Johann,

  We eventually build a MacOS binary using GTK. But the experience is bellow normal. GTK works best on Linux, other platforms, including Windows, are not comparable with native applications.

  I'm having some issues with our Mac used to build it, but I hope to have some binaries soon.

  For the future we expect to have a native MacOS driver functional. It is a contribution from Eric Wing, but there is no time frame for a stable release. He needs help by the way.

Best,
Scuri

What does this have to do with Jade?  IUP is not in my plans, although you're welcome to contribute something that would work with Jade...
Title: Re: JadeLib
Post by: John on January 08, 2019, 11:05:59 AM
IUP is the only GUI toolkit that is attempting to touch all the bases in a native format using a common API. The reference to needing help must have eluded you.
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 11:19:25 AM
The reference to needing help must have eluded you.

Actually, it didn't.  I didn't want to reiterate the reasons why I don't think this is worth my time.
Title: Re: JadeLib
Post by: John on January 08, 2019, 11:28:09 AM
If I would have ever owned a Apple product I may be more interested in pursuing a usable solution. My hope is what you have shown us with your direction doen't lose interest.

I view IUP and the VB6 OCX forms direction as plugin GUIs I don't have to marry. Independance has its virtue.
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 11:46:26 AM
Cool, but let's keep THIS thread on topic, please....
Title: Re: JadeLib
Post by: John on January 08, 2019, 11:49:39 AM
Sorry!

I had to make one last effort to try and seed your non-IUP interests.  :-X
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 08, 2019, 03:51:43 PM
It appears that FreeBasic and QB64 are using an index that starts at "1" for their instr command (and other string commands), where as Jade is using a "0" based index.

Actually, it appears that every BASIC I am aware of uses 1 as a starting index in its string evaluation functions like Left, Right, Mid, Instr, InstrRev, Tally, etc. with 0 being reserved to indicate the absence of target value in the string being evaluated. Sorry but I would regard a zero based target position in a string a weird abnormality and an unjustifiable deviation from the traditional BASIC syntax in a particular dialect.
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 04:15:37 PM
It appears that FreeBasic and QB64 are using an index that starts at "1" for their instr command (and other string commands), where as Jade is using a "0" based index.

Actually, it appears that every BASIC I am aware of uses 1 as a starting index in its string evaluation functions like Left, Right, Mid, Instr, InstrRev, Tally, etc. with 0 being reserved to indicate the absence of target value in the string being evaluated. Sorry but I would regard a zero based target position in a string a weird abnormality and an unjustifiable deviation from the traditional BASIC syntax in a particular dialect.

Jade isn't BASIC.  ;D
Title: Re: JadeLib
Post by: John on January 08, 2019, 04:33:06 PM
Quote from: AIR@repo
This is a proof of concept using a BASIC-like syntax to program C++.

There is nothing BASIC like with strings starting at zero.
Title: Re: JadeLib
Post by: jack on January 08, 2019, 04:36:44 PM
AIR, often one needs to know if there is no occurrence of the substring, how does your instr function handle that?
Title: Re: JadeLib
Post by: John on January 08, 2019, 04:47:12 PM
undef?
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 08, 2019, 04:48:04 PM
Jade isn't BASIC.  ;D

Probably not but your casual and definitive "Jade is using a "0" based index" raised questions immediately from at least three BASIC-ers. Doesn't that ring the bell? ;D
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 08, 2019, 04:49:24 PM
undef?

John is hopelessly incorrigible. ;D
Title: Re: JadeLib
Post by: John on January 08, 2019, 04:53:15 PM
I'm thinking about changing my last name to Trump.  :)
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 04:57:11 PM
AIR, often one needs to know if there is no occurrence of the substring, how does your instr function handle that?

If you try this, you will see that it returns a '-1'.

Code: C++
  1. include <jade.hpp>
  2.  
  3. MAIN
  4.     STRING blah("This is a string");
  5.     PRINT(INSTR(blah,"or"));
  6. END

AIR.
Title: Re: JadeLib
Post by: John on January 08, 2019, 05:03:41 PM
Quote
If you try this, you will see that it returns a '-1'.

Sure looks like undef to me.
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 05:05:02 PM
Jade isn't BASIC.  ;D

Probably not but your casual and definitive "Jade is using a "0" based index" raised questions immediately from at least three BASIC-ers. Doesn't that ring the bell? ;D

I encourage questions like this, but I also encourage you guys/gals to also try addressing your questions by coding.  I want you to find any issues; unfortunately I don't think zero vs one based indexing is one of them.  It's just different for BASIC-ers.  But not for people using other languages.
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 08, 2019, 05:14:05 PM
But not for people using other languages.

Armando, you telling this to me?! There's been nothing else but C/C++ for me to code in for decades! ;D

Never mind though. If there was at least one solid reason behind such a design decision for you as a (the?) project developer then so be it. :)
Title: Re: JadeLib
Post by: John on January 08, 2019, 05:17:21 PM
Code: [Select]
A$ = ""
IF MID(A$,69,3) = "AIR" THEN

TRUE in JADE returning -1.


Title: Re: JadeLib
Post by: Mike Lobanovsky on January 08, 2019, 05:23:44 PM
Code: [Select]
A$ = ""
IF MID(A$,69,3) = "AIR" THEN

TRUE in JADE returning -1.

 ;D ;D ;D ;D

TRUE = -1 is another BASIC oddity that's been making me dizzy for as long as I can remember.

But seriously, it's a good catch John!

Armando, the ball is on your side... ;)
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 05:25:11 PM
But not for people using other languages.

Armando, you telling this to me?! There's been nothing else but C/C++ for me to code in for decades! ;D

Nah, it was for everyone!!
Title: Re: JadeLib
Post by: John on January 08, 2019, 05:31:06 PM
Actually SB would return an undef for my example. Irritating but something I learned to live with.
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 08, 2019, 05:35:58 PM
John, you don't have to apologize. Armando will have to defend his design decision or admit his defeat.
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 05:42:36 PM
Code: [Select]
A$ = ""
IF MID(A$,69,3) = "AIR" THEN

TRUE in JADE returning -1.

Actually, this would throw an out of bounds error.

I updated MID$ to compare string length to start position.  Update and rebuild the lib.
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 08, 2019, 05:52:46 PM
If the library supports anything that's close to the notion of BASIC "fixed length strings" then comparing the string lengths only isn't sufficient to make John's evaluation fool proof. An empty 3 byte long fixed length string is going to fail the TRUE/FALSE test.

Under similar conditions, the C-language strstr() equivalent returns a NULL pointer that evaluates to FALSE in Boolean logic (that's as far as "other languages" go...)
Title: Re: JadeLib
Post by: AIR on January 08, 2019, 07:17:03 PM
The library uses std::string, which isn't fixed by default.

Mike, can you code me an example of what you mean as far as a "empty 3 byte long fixed length string"?  On the surface, it sound pretty esoteric and outside the norm.  Thanks.
Title: Re: JadeLib
Post by: jack on January 09, 2019, 03:57:35 AM
AIR, I must disagree with your design
Code: [Select]
#include "../include/jade.hpp"


MAIN
  STRING mystring = "This is a string.";
  if ( INSTR(mystring,"not")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"not")));
  END
  if ( INSTR(mystring,"is")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"is")));
  END
  if ( 0 ) THEN
PRINT ("no substring found");
PRINT (STR$(INSTR(mystring,"no")));
  END
  PRINT ();

ENDMAIN
obviously the last IF clause is not going to be executed, it's just for illustration of what the first clause should be
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 09, 2019, 05:16:35 AM
Hi Armando,

A BASIC "fixed length" string is what you'd normally call a "char" or "byte buffer" in "other languages". It's a contiguous chunk (in fact, a one-dimensional array) of bytes allocated in "unmanaged" memory via malloc() or its equivalent outside the scope of C++ std::string. Depending on the platform bitness and Unicode awareness, BASIC would regard such a buffer as a pre-allocated string of CHARs or WCHARs pre-filled with zeros, and would include all operations with the buffer in the category of string functions. Further, depending on the completeness and compliance of its design and implementation, a particular BASIC dialect may also include utility functions to convert (cast) the buffer to other composite data types such as CHAR/WCHAR arrays, UDTs (structures), etc. to enable non-string functions to operate on the buffer natively as well. The advantage of "fixed length" strings over "ordinary" strings preallocated dynamically via the STR()/STRING() allocation functions is that the former normally accept CHR(0) as a valid filler character.

For speed reasons many BASIC dialects, especially interpretative ones, would not at all times rely on literal comparison of string bytes (in fact, CHARs or WCHARs) with zero or each other alone when determining the string lengths or comparing them for (in)equality. A BASIC var structure would normally include a dedicated field to store the string length as set forth/determined at the moment of its creation or assignment. A "fixed length" string would have the buffer capacity (in CHARs or WCHARs) stored precisely in this field of its var structure regardless of the actual CHAR/WCHAR values (possibly zeros) written in the string by allocation, initially, or assignment, thereafter.

Thus, again depending on a particular BASIC dialect implementation, DIM buffer AS STRING * 128: PRINT LEN(buffer) may very well yield 128 regardless of buffer having been filled with zeros initially at allocation time thus being of zero string length as ASCIIZ strings go. When comparing such buffers with "ordinary" strings for whatever purpose, measures should be taken transparently or explicitly by the language developer or the user to resolve possible data type ambiguity (e.g. dynamic string vs. fixed length string) and avoid related pitfalls as in John's example.

Examples of fixed length strings:

-- Visual Basic:        DIM buffer AS STRING  * 128            (128 zero bytes/CHARs)
-- ANSI FreeBASIC:      DIM buffer AS STRING  * 128            (ditto)
-- ANSI PowerBASIC:     DIM buffer AS STRING  * 128            (ditto)
-- Unicode FreeBASIC:   DIM buffer AS WSTRING * 128            (256 zero bytes/128 WCHARs)
-- Unicode PowerBASIC:  DIM buffer AS WSTRING * 128            (ditto)

etc.

I see nothing esoteric in this paradigm. And that's what a BASIC-er would rely upon from their experience, faced with a necessity or challenge to write some BASIC-like code for a language translator program or library. BASIC has no official standard these days and tradition is what we have to rely heavily instead in order to keep on using our favorite "toy" language.

Hopefully this helps to make Jade more predictable and BASIC compliant regardless of the notorious semicolon line endings. :)
Title: Re: JadeLib
Post by: AIR on January 09, 2019, 08:39:53 AM
AIR, I must disagree with your design
Code: [Select]
#
  STRING mystring = "This is a string.";
  if ( INSTR(mystring,"not")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"not")));
  END



Ah, NOW I see!  Thank You, Jack!

AIR.
Title: Re: JadeLib
Post by: AIR on January 09, 2019, 09:55:15 AM
Mike,

Thanks for the explanation.

I don't think this is applicable to std::string, though, which I think you alluded to towards the beginning of your post.

Since std::string doesn't rely on a terminating '\0' and also tracks it's size internally and will dynamically resize when needed I don't think the scenario you've put forth would be an issue.  I may be incorrect; if so please let me know.

The string functions I've thrown together don't take char* as parameters, so they shouldn't be susceptible to the scenario you've described.

Note to all:  There is no BASIC parser with Jade.  It's more of a "snake-oil salesman" approach, in that it's a thin veneer of sorts over CPP.  So, some things may not work as you may be accustomed to with a "proper" BASIC.  When that happens, you need to think more along the lines of how CPP would do something vs BASIC.

For example, Jack's INSTR example would have worked by checking if the return value was zero or greater.  I've addressed this in the latest update so that it works as BASIC-ers expect (1 based vs 0 based indexing - MID$ too) but FWIW it bugs me that I even had to do this, simple as it was to implement.

At any rate, please update and rebuild, and please continue finding areas that need looking at!!

Thanks,

AIR.
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 09, 2019, 11:05:19 AM
Note to all:  There is no BASIC parser with Jade.  It's more of a "snake-oil salesman" approach, in that it's a thin veneer of sorts over CPP.  So, some things may not work as you may be accustomed to with a "proper" BASIC.

I think this note is worth inscribing at the very top of git blurb. It states fairly enough that, unlike BCX or MBC or BC9, Jade is NEITHER BASIC NOR CPP and not even a subset of either of them.

Quote
... you need to think more along the lines of how CPP would do something vs BASIC.

If one knew exactly how CPP would work under particular circumstances, why would one ever need a translator from a non-compliant (i.e. heavily RTFM'ed) and relatively shallow BASIC-like syntax to the incongruously richer C/CPP paradigm in the first place?

However what I'm saying is in no way meant as mockery at your pet project. Have fun! FWIW it may be just a first step to yet another full-fledged BASIC-to-CPP translator on the market. :)
Title: Re: JadeLib
Post by: John on January 09, 2019, 11:08:22 AM
String support for C BASIC has been the primary hold up moving forward with it. My goal with C BASIC is to make building SB extension modules easier. It's not like JADE providing a C helper platform for BASIC programmers.

I plan on using SB's existing string engine / memory manager but making it easier to use.

Title: Re: JadeLib
Post by: AIR on January 09, 2019, 11:50:20 AM

Quote
... you need to think more along the lines of how CPP would do something vs BASIC.

If one new exactly how CPP would work under particular circumstances, why would one ever need a translator from a non-compliant (i.e. heavily RTFM'ed) and relatively shallow BASIC-like syntax to the incongruously richer C/CPP paradigm in the first place?

What would make the most sense for someone coming from a BASIC background?

Code: C++
  1. PRINT(LEFT$(mystring,4));
  2. std::cout << std::string(mystring,0,4) << std::endl;
  3. std::cout << mystring.substr(0,4) << std::endl;

All I'm doing is trying to make it more familiar.  And BTW, Jade IS CPP!!  It's just using defines and a library to somewhat mask things.  It's not translating a thing.

"BASIC-like" does NOT suggest compliance.  Since there is no "official standard", "compliance" is ultimately a subjective thing.  And that's not my goal, anyway.

In the end, what matters is if a given implementation allows you to produce the desired result with the least friction.  Admittedly, Jade has some friction, but that's what happens when you try transitioning from one implementation to another.  Note the non-use of the word "language" here.

Quote
However what I'm saying is in no way meant as mockery at your pet project. Have fun! FWIW it may be just a first step to yet another full-fledged BASIC-to-CPP translator on the market. :)

Most of the translators I've seen only do BASIC-to-C, making it a challenge to interface with CPP Libraries at times.  Even those that allow compiling as CPP usually throw warnings regarding some of the string functions.

Jade actually started as a re-write of MBC, I just thought I'd share what I've come up with towards that end.  Doesn't mean that you have to like or approve of the approach I've taken, you always have a choice!!  ;D

AIR.
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 09, 2019, 12:47:53 PM
What would make the most sense for someone coming from a BASIC background?

Code: C++
  1. PRINT(LEFT$(mystring,4));
  2. std::cout << std::string(mystring,0,4) << std::endl;
  3. std::cout << mystring.substr(0,4) << std::endl;

For someone that's made it into the 21st century together with mature BASICs (you know, pointers and OOP and COM and stuff) rather than died together with Dartmouth and Kemeny in mid-fifties of the last century, both notations are equally understandable if a little too inhuman for a BASIC-er. :)

Quote
"BASIC-like" does NOT suggest compliance.  Since there is no "official standard", "compliance" is ultimately a subjective thing.  And that's not my goal, anyway.

You know, my people say: "One can't possibly have all the women in the world. Still that's something worth striving for". Sounds a little chauvinistic yet true enough from my standpoint,  Freud-wise. ;)

Quote
In the end, what matters is if a given implementation allows you to produce the desired result with the least friction.

That's correct in most cases provided one knows exactly the limitations, incompatibilities and how to avoid them. Some learning curve is unavoidable even for such a relatively straight-forward implementation as Jade.

Quote
Jade actually started as a re-write of MBC, I just thought I'd share what I've come up with towards that end.

And we're thankful for that. :)
Title: Re: JadeLib
Post by: AIR on January 12, 2019, 08:37:31 PM
Commit on 01/12/2019: [master 8db3035] Added BIN$, HEX$, and OCT$ functions

Code: C++
  1. #include <jade.hpp>
  2.  
  3. MAIN
  4.     VAR x = 131917119186620000;
  5.  
  6.     PRINT( x, " = ", HEX$(x));
  7.     PRINT( x, " = ", OCT$(x));
  8.     PRINT( x, " = ", BIN$(x));
  9. END
  10.  

$ ./test_dec_conv
131917119186620000 = 0x1d4a9ebc4e94e60
131917119186620000 = 07245236570472247140
131917119186620000 = 0000000111010100101010011110101111000100111010010100111001100000


AIR.
Title: Re: JadeLib
Post by: John on January 12, 2019, 09:24:18 PM
Looks great!

What did you come up with about the string starting reference?
Title: Re: JadeLib
Post by: AIR on January 12, 2019, 10:13:42 PM
I made the concession for INSTR and MID, but I'm not doing that across the board...
Title: Re: JadeLib
Post by: John on January 12, 2019, 10:29:02 PM
That's fair. We all must keep in mind that JADE isn't a language or a translator. It's a pre-processor include and pre-built function helper library to make C++ resemble BASIC.
Title: Re: JadeLib
Post by: Mike Lobanovsky on January 13, 2019, 10:25:54 AM
My friend Patrice Terrier does the same with his CPP code, and with mine too when I submit my patches.

My eyes bleed. ;D
Title: Re: JadeLib
Post by: John on January 13, 2019, 11:02:08 AM
I've leaned to live with undef not being equal to FALSE.

This is the best way to test if a variable is defined or not.

Code: Script BASIC
  1. IF ISUNDEF(A$) THEN
  2.   PRINT "TRUE\n"
  3. ELSE
  4.   PRINT "FALSE\n"
  5. END IF
  6.  


$ scriba t_undef.sb
TRUE
$



Code: Script BASIC
  1. IF a THEN
  2.   PRINT "undef = FALSE\n"
  3. ELSE
  4.   PRINT "undef = TRUE\n"
  5. END IF
  6.  


$ scriba t_undef.sb
undef = TRUE
$


A good reason to turn declaring variables on in SB. This prevents weird bugs due to an unexpected undef creeping into the code.

Code: Script BASIC
  1. declare option DeclareVars
  2. declare option AutoVars
  3.  

If I can live with that, JADE's zero starting string reference is a walk the park.  ;D
Title: Re: JadeLib
Post by: AIR on January 13, 2019, 08:17:55 PM
John, this thread is about JadeLib.  Please stay on topic.  Thanks.
Title: Re: JadeLib
Post by: John on January 13, 2019, 08:28:35 PM
Okay

Just sharing I'm no stranger to pain.
Title: Re: JadeLib
Post by: AIR on January 13, 2019, 08:37:20 PM
Commit 53004c5ded Added LPAD$, RPAD$, and PAD$ Functions.

Code: C++
  1. #include <jade.hpp>
  2.  
  3. MAIN
  4.     STRING str = "abcd";
  5.  
  6.     PRINT(LPAD$(str,10,'*'));
  7.     PRINT(RPAD$(str,10,'*'));
  8.     PRINT(PAD$(str,10,'*'));
  9. END
  10.  

$ ./pad
**********abcd
abcd**********
**********abcd**********


If the third parameter (padding character) is omitted, spaces are used.

Note that the padding character is a CHAR (single quotes) in this example.  You can also pass the ASCII numeric value instead, without the quotes.

AIR.
Title: Re: JadeLib
Post by: John on January 14, 2019, 10:38:35 PM
AIR,

Would it be possible to use JADE to create a SB extension module?
Title: Re: JadeLib
Post by: AIR on January 14, 2019, 11:29:56 PM
I don't think you can just compile and go, because SB is compiled using C via the build system.




Title: Re: JadeLib
Post by: John on January 14, 2019, 11:41:17 PM
You're right.

I was just thinking JADE might be a nice way to quickly turn a CPU intensive function into an extension module. I think I should put my efforts in this area to C BASIC and attach Peter's existing API macros to BASIC keywords. I do plan to follow much of your JADE flow and style.