Embedded Null characters and std::string

[SamuraiCrow]

Due to extensive rewrites needed to make Yab compile into C++, I was wondering if rewriting the string handling routines to use the standard template libraries would be an acceptable first step to writing an updated Yab.  (Std::Strings are length terminated and are resistant against embedded null characters screwing things up.)

I've looked at the original YaBasic sources on Linux and it is a terrible mess.  If Yab is to be a permanently deviated fork from the original YaBasic, perhaps I could look into optimizing the source to use the C++ standard template library routines.  I figure that Haiku is written in C++ anyway and it might make things smaller to depend on libStdC++ for the existing runtime libraries built-in to the OS.  (Unlike YaBasic which uses Ruby for its build system and Autoconf and Automake along with Gnu Make and other scripting that those drag in as dependencies.)

Now for the real question:  Will pull requests to bbjimmy's repo be accepted for the C++ enhanced version of Yab?

[bbjimmy]

I think the repo to submit prs to is https://github.com/lorglas/yab as he is most active in yab development at this time. I would certainly be willing to test string handeling changes to the source, but lorglas has been working on the yab packaging more than me recently.

[lorglas]

Yes, 
I am working on the next version 1.8. And I think it's better to change this for yab 2.0. 

@SamuraiCrow

Then it could be a complete rewrite in c ++ so that yab can be free from the original yabasic. Also, yab works with gcc 8 or higher, so we no longer use gcc2. But you can also make a new development and name it differently. 
There is no problem.
 We can have two basic ones. I like your enthusiasm for making changes to this yab and if I understand correctly there will be little left of the original code. Only the command syntax remains the same.

Jan__64 has seid that he comes back if Haiku has reached R1 Status and work again on it. I don't think so. He has say a long time ago, that he think to rewrite yab with lua.

I think your way can be the better way. Did you have Version for testing?

[SamuraiCrow]

Yes, 
I am working on the next version 1.8. And I think it's better to change this for yab 2.0. 

@SamuraiCrow

Then it could be a complete rewrite in c ++ so that yab can be free from the original yabasic. Also, yab works with gcc 8 or higher, so we no longer use gcc2. But you can also make a new development and name it differently. 
There is no problem.
 We can have two basic ones. I like your enthusiasm for making changes to this yab and if I understand correctly there will be little left of the original code. Only the command syntax remains the same.

I was planning on making this backward compatible with GCC 2 with optional wrappers for GCC 8 features (such as unordered_map).  My reason for this is to be able to maintain some degree of detachment between the runtimes and the transpiler.  In this way someone can try to add some cross compatibility to other platforms and therefore add to the source codes compatible with ours.  Haiku will still be the basis for it but I see Haiku as an upgrade path for other OS users from the likes of AmigaOS 4 and AROS.  They have GCC8 compilers like Haiku but their operating systems are single-threaded multitaskers and are dreadfully obsolete as a result.  (They don't have useful multicore support.)

Jan__64 has seid that he comes back if Haiku has reached R1 Status and work again on it. I don't think so. He has say a long time ago, that he think to rewrite yab with lua.

I think your way can be the better way. Did you have Version for testing?

I've worked with another project on my Amiga-like systems called Hollywood that used Lua as the basis for its runtime engine.  Lua is not consistent internally between versions and if LuaJIT is the best anyone can hope for for a compilation strategy then forget it.  I want to make my Yab2Cpp engine statically transpile using GCC as a backend.  I know how to do it but just haven't done it yet.

There are a few commands that don't support static compilation that will have to be dropped from my version:  Eval, Eval$ and Bind.  There may be one more but I hope they are all rare.

So far I'm just taking notes in my notebook about implementation and saw an opportunity to solve an old collection of bugs using GCC string routines and the C++ Standard Template Library.  Replacing all of the linked list implementations with std::list would make the code more maintainable as well, not to mention replacing all of the linear searches with hashes.

@bbjimmy
Thanks for directing me to the more up-to-date repository.  I'll switch to it and continue my observations and changes against the current fork.

[lorglas]

A cross compatibility Version of yab is Flyyab. If i remember right is flyyab working on linux. But i have no programs ported to Linux.

amiga is a good porting Option. I have only old amiga's from 1.3 to 3.5.

I think downwards compatibility to gcc 2.95 is not needed.

[SamuraiCrow]

A cross compatibility Version of yab is Flyyab. If i remember right is flyyab working on linux. But i have no programs ported to Linux.

amiga is a good porting Option. I have only old amiga's from 1.3 to 3.5.

I think downwards compatibility to gcc 2.95 is not needed.

It looks like FLYab hasn't been touched for 7 years.

By the way, check the small pull request for the bug I submitted earlier.

[SamuraiCrow]

It seems now that the extensive rewrite may be easier than I thought. Bison can generate C++ code directly, making a new interpreter easier than I thought. I'll still shift my efforts toward the transpiler first, though.

[lelldorin]

Hello,

iirc the problem with flyyab are that Jan__64 does not found any window system who can make all widgets possible of yab, so he stop to port to linux in the past.

Regards Lelldorin

[SamuraiCrow]

I'll see about it later. If it is totally non-portable, I'll focus on adapting my code-generation framework to other versions of BASIC.