123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|658|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> JSE -> JSE Transpiler?
Thu, 18 Apr 2024, 05:30
Jayenkai

JSE Transpiler?


Oh goodness me, this is going to be far more complex than I had in my head!!!

The Goal


One of the more frequent complaints about JSE is the lack of Compiler.
I don't trust that I should allow code to compile in the browser, and then run in there, because I honestly think that's a massive security issue.
It's one of the things I've been adamant that I'm not changing any time soon.

In order to compile "securely", and in a way that will work suitably well on all systems, the only realistic way of doing it is to send your code to the server, compile it there, then send it back to you. But even that's not super-secure.
This also means everyone's code, whether they want it to or not, will be seen by the server, always and forever.

I'm not a fan of that.
I'm not a fan of the lack of privacy that that creates.
I'm not a fan of the possible security implications involved.
I'm not a fan of the fact that it'd create massive server overheads if someone repeatedly clicks "Compile now...".. ... Kinda like I would!!!

So what's the options, then?

Well, after a long time thinking about it, and a recent struggle to decide on what languages/systems to target for my next framework, I've stumbled upon something of a potential solution to all problems at once.

What if I do what Monkey once did, and have the user's code rewritten into other languages?
I can then spit out a bundle which the user can use to compile for that target, using whatever tools they have at their disposal.
I can even transpile to Javascript, inside the browser, but have it spit out a "MyGame_HTML.zip" that they can then upload to their own server. It's an extra couple of steps, true, but it does end up as a "compiled" Javascript version, and I think that's more than enough for most people.
.. Right!?!

The language can already bundle things into a downloadable .html5 package, but that's still using the parser, and doing things interprettedely.. If I transpiled, the result "should" work that little bit faster.
And if they can then download a "3DS DevkitPro Project", or a "Window Desktop Project" or an "OUYA Project", then I think that's quite a fun goal to aim for.

Right!?!

Now all I have to do is rewrite everything that the user's coded, so that it works with whatever language is being targeted.
"What could possibly go wrong!?"

-=-=-
''Load, Next List!''
Thu, 18 Apr 2024, 05:59
Jayenkai

Day One


I started work on the Transpiler function, this morning.
The goal being to "understand" the user's code and see if I can output it into something workable.
The first target will be Javascript, mostly because I'm going to want to be able to make use of all the functions I've already coded (SetCol, DrawImg, etc) and it'll be easier to start with a framework where I've already done all of that! For every other language, I'm not only going to have to code the transpiler, but also a framework that can handle the transpiled code.
Aaagh...



Stumbling block number one.
On the left, the JSE code.
In the middle, my first test at a Transpiler.
On the right, the parsed edition that JSE works with.

This is the parsed code before it then gets reduced down, even further, to individual steps by the parser.

Space

1. There's no comments in the Parsed edition, nor is there any indentation in either the Transpiled or the Parsed versions.
2. All whitespace is also missing from the Parsed edition.

This leads to a number of complications, right from the off.
If you've heard me grumble about how hard I've made it to get Error Messages out of JSE, then this is one of the many reasons.
A line of code on the parser side is NOT the same line number as that on the JSE side.
And the Transpiler version is a third set of different line numbers.

I think it might be a good idea for me to finally figure out how this bit is supposed to work, so that I can keep track of line numbers as the code is constantly warped between all the various versions that it has to exist in.

As for indentation, I'll probably shift through the Transpiled code once it's all done, and auto-indent everything.
Not sure if I can keep hole of all the whitespace, though.
I'll have to try to keep track of that.

Capitalisation


The command list at the top of JSE is an array of lowercase keywords.
If I'm going to output a better quality of Transpiled code, I'm going to have to rewrite that list so that it outputs "ProperCase" command names.
Definitely something I need to work on.

Similarly, all variables and array names will have to be switched to a specific case style. I couldn't possibly guess at the capitalisation of something like PlayerJumpSpeed.. Maybe I should do something like "Reuse the case of whatever the first instance of the variable name is".. That seems like it'd work.

I might add a vbl_ to all variable names, so there's no cases of people accidentally using a variable name like "clash", and then the target language just happens to have that as a command name or something. Could cause all manner of breaks.

GxextxAxrxrxaxy


You're probably wondering WTF GxextxAxrxrxaxy, and SxextxAxrxrxaxy are, as well as why for and next have become fxor and nxext..
...Don't worry, those are just internal, and were added so there's little or no possibility of me accidentally breaking logic as I go! The parser needs to know when it's parsed For and Next, so I added the x's to symbolise that. GetArray and SetArray are similarly created and then the x's added, as the parser runs through things.
Note that the Transpiled version hasn't got any of those quirks (yet!)

You might also note that the For/Next loop is kinda backwards.

For n=0 to 10 Step -2 : ... : Next
becomes
n=0: For : ... : Next(n,10,0-2)

(Note : I know this code is broken, I'm just testing the parser, here!!!)

This is because JSE works with Repeat:Until logic.
Javascript, however, works with While:Wend logic. And as easy as the For-Next will be to translate back, the Repeat-Until logic might be much harder to convert to working logic. .. I'll have to "+1" everything, or something!!
Hmmm..


Anyhoo, this is day one, and there's a lot to think about, and an awful lot to code.
I wonder how well this will all work out!?!

-=-=-
''Load, Next List!''
Thu, 18 Apr 2024, 06:13
cyangames
 		I had a feeling this was what you were talking about earlier, best of luck Jay, this looks like quite the task!

-=-=-
Web / Game Dev, occasionally finishes off coding games also!
Thu, 18 Apr 2024, 08:23
Pakz
 		Lots of testing too.

I wonder if some kind of automation is possible?
Tue, 23 Apr 2024, 03:12
Jayenkai

This is taking freakin' ages!!! (It's only been 5 days since you started coding this, Jay, don't be so hard on yourself)

Things are looking a little better, now. Bracket City, but the commands are (mostly) being properly capitalised, and things are looking more how they oughta, ready for a few additional steps.

Items of note
  • Brackets Everywhere!!!!
  • //'s are temporarily covered to Rem's, because it's easier to work with "A Command" than it is "Two random division symbols right next to each other for seemingly no reason"
  • Dim isn't Dimming yet. I'll have to convert those specifically for each target language, since everything seems to handle them differently.
  • For/Next isn't done yet, for the same reason.
  • Nor is If/Then
  • All indenting has been stripped away and will have to be re-processed afterwards.

    But other than the insane levels of brackets, that's actually looking a lot like how I'd like it to be.
    I mean, there's still a TON left to do, here, but I feel like I can grapple the code a decent amount, and it might end up actually working at the end of all this, which is nice!

    .. Keep going, Jay!

    -=-=-
    ''Load, Next List!''
    		•
    Tue, 23 Apr 2024, 11:39
    Jayenkai

    A fairly busy day, and a decent amount of important steps.
    For Next's are now looking a bit more sensible, though there's a silly amount of whitespace around them that needs fixing.
    If/Then/Else seems to be working well enough.
    Additionally, I can now toggle between C'y and Blitz'y which currently only impacts the For and If bits, but does indeed work nicely for the two.

    Mmm, nice!

    -=-=-
    ''Load, Next List!''
    Wed, 24 Apr 2024, 05:58
    Jayenkai
         		"Hey, Bing/Claude/Poe/anyone .. How do you think I could Transpile the Goto command into Javascript?"

    *sound of exploding A.I. computers*

    Uhoh!!

    -=-=-
    ''Load, Next List!''
    Thu, 25 Apr 2024, 00:40
    Dan
         		I have tried to think of a solution to this ... from a non goto programming style ...

    No wonder some people call it sphagetti code ... if you're used to program in a gotoless language.

    I guess it could be done if you make, out of each section to which goto jumps into, as a parameterless function.

    Basically convert the code to how you would write it without the goto functionality ... would this be a nightmare to do ? maybe ...

    The easiest solution is to write an interpreter ..
    Thu, 25 Apr 2024, 03:08
    Jayenkai
         		Yeah, I'm currently in the mindset of leaving the Javascript version as-is.
    JSE works ok, right?!
    I might be able to rejig a few bits of the code using what I've learned so far, though, and that might help optimise JSE a teensy bit further, which is never a bad thing.

    I can cobble together a version that *should* work in most versions of C++.. It "does" have a goto, (though some C++'s have stripped it out.. grrr..) and I *think* I can get some form of Gosub working in it, as long as I can "goto Variable".. But I'm not sure I can do that. I'll have to stress test various C++'s's

    Targeting Blitz3D/Max should be easy enough to do, and from there you can compile your own Win/Lin/Mac desktop versions.

    I'd still like to be able to get an OUYA game running from all this, though. .. But, honestly, I haven't the foggiest how that's going to go!!!
    Eeek!

    -=-=-
    ''Load, Next List!''
    Thu, 25 Apr 2024, 11:36
    Jayenkai

    Apparently the C++ compiler will need to be "GCC Compliant", but not even then am I guaranteed to have access to the Goto.

    According to Bing/CoPilot and Poe, that "could" work in some versions of C++, but according to Claude it's utter bollocks.
    I'd also have to store those pointers into a returnStack, so that I can return to "the last gosub".
    Golly gosh...
    I sure do hope I can find a C++ that supports goto!!!

    -=-=-
    ''Load, Next List!''
    Fri, 17 May 2024, 14:04
    Jayenkai

    Good grief, has it almost been a month!?!

    Don't think the silence means nothing's going on, here!
    .. Though, there is an awful lot of nothing going on!!
    I'm still formulating the best, most optimal way to do those Gosubs, but am also reworking a few things in the main engine itself.

    In the meantime, then, I decided to rewrite the GameHandler function. It now has a style not entirely unlike my old "Circular" framework, so is accessible with the extra "Circular" parameter.. The classic GameHandler will be "Flat", and of course "Calendar" is still Calendar.
    There's still tweaks to do, mostly because of the addition of a new Options menu. Oooh!
    Should be available in the next week or so.

    -=-=-
    ''Load, Next List!''