Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added haxe-targets graphviz diagram to intro compiler-targets doc. #348

Open
wants to merge 3 commits into
base: staging
Choose a base branch
from

Conversation

uvtc
Copy link
Contributor

@uvtc uvtc commented Oct 18, 2018

Diagram (started by Brian Tiffin) to show how the different language/platform Haxe targets can reach the different end-user platforms (VM, Browser, Interpreter, Executable).

Still needs work, but @Simn said "looks really good!", so I thought it should go up now and folks can add clarifications later as they come up.

@markknol
Copy link
Member

markknol commented Oct 18, 2018

Nice graph!

Suggestions:

  • Haxe --interp should also point to Interpreter, then it doesnt have to be that lonely there.
  • Arrow From Ecmascript to Browser maybe needs label "JavaScript"
  • Arrow From Ecmascript to Interpreter maybe needs label "node.js"

@uvtc
Copy link
Contributor Author

uvtc commented Oct 18, 2018

Thanks! Thanks to Brian for getting the ball rolling!

Is haxe --interp on the same level as "Interpreter"? Is it used in production? Making an --interp-labeled arrow go straight to Interpreter unfortunately makes the diagram wider and also messier.

img haxe-targets temp

I didn't include "JavaScript" on the arrow from ECMAScript to Browser because it's not a tool that gets from one to the other. My understanding is that ECMAScript is, for nearly all intents and purposes, equivalent to JavaScript. And I see that it's haxe --js, and not haxe --ecma, so maybe I should just change it in the diagram to say "JavaScript".

I didn't include node.js because I didn't include any specific VMs or Interpreters. I think the diagram would become too heavy if we tried to include the JVM,CLR, Node.js, the Python & Lua & PHP interpreters (not sure of the names), Flash player, etc. Add to that, each target language may have multiple VMs/Interpreters.

My thought is that the labels on the arrows are to show what tool gets you from one box to the next (so, maybe I should remove "HL/JIT" and "HL/C"). The viewer already has their own platform and tool-set in mind --- they just need to see that Haxe can get them there.

@markknol
Copy link
Member

markknol commented Oct 18, 2018

Well depends on what you mean by "in production". It can be used in CI, to build tools, to generate stuff on the fly, its used by people, so it should be there.

Maybe you could rotate everything 90 degrees to not have everything horizontally?

     > hashlink  > vm
haxe > c# > executable
     > java > vm
     > .. > etc

@uvtc
Copy link
Contributor Author

uvtc commented Oct 18, 2018

Hm. I don't know how to rotate the diagram, but that's a good idea. Will have to look into that later.

Here's another version where I've put light blue borders on everything that Haxe can generate, and also included a couple of other bytecode boxes so it's easier to see the "bytecode level" below the "source code level":

haxe targets with bytecode

Does it look better with those bytecode boxes in there as well?

@markknol
Copy link
Member

markknol commented Oct 18, 2018

Other notes:

  • I would rename ECMAScript to JavaScript, because thats what we call this target https://haxe.org/manual/target-javascript.html
  • Indeed, you could leave "javascript" as label on arrow out, but from JavaScript to Interpreter "node.js" makes sense to me
  • I would keep "HL/JIT" and "HL/C"

@markknol
Copy link
Member

Yeah I pressed send accidentally while I was typing, didnt mean that.

@uvtc
Copy link
Contributor Author

uvtc commented Oct 18, 2018

:)

Ok, found the left-to-right option, which yields:

Not quite as crazy about it, but it does fit on the page much better.

@markknol
Copy link
Member

As @Simn would say "looks really good!"

@uvtc
Copy link
Contributor Author

uvtc commented Oct 18, 2018

So, better with, or without, the separate bytecode layer? Here it is, left-to-right, without the bytecode layer (and with Haxe -> Interpreter directly, labeled "--interp"):

haxe targets, vertical

@Simn
Copy link
Member

Simn commented Oct 18, 2018

I like the 4 column one more. And yes it should be JavaScript.

@uvtc
Copy link
Contributor Author

uvtc commented Oct 18, 2018

Ok, I committed changes:

  • going left-to-right
  • --interp straight to Interpreter
  • ECMAScript --> JavaScript
  • more informative to keep the extra bytecode column (4-column)
  • kept HL/JIT and HL/C

@uvtc
Copy link
Contributor Author

uvtc commented Oct 18, 2018

Result is:

@Simn
Copy link
Member

Simn commented Oct 18, 2018

Looks good! I can't merge because I'm in Belgium.

@ncannasse
Copy link
Member

I would just remove ActionScript/SWF -> Browser link given Flash is less and less suported in browsers
And --interp should not cross JS->Browser

@uvtc
Copy link
Contributor Author

uvtc commented Oct 18, 2018

Ok. Removed ActionScript -> Browser, and also SWF -> Browser. Hope I understood you correctly. Thanks!

This leaves only one straight path to the Browser: Haxe -> Browser -> JS.

Also, with that change, now "--interp" has been automatically better located! I really like Graphviz! :)

New result:

haxe targets

@andyli
Copy link
Member

andyli commented Oct 19, 2018

Can cppia bytecode be turned into an executable? I think it only runs in the cppia host. Also, is the cppia host a VM or an interpreter?

@uvtc
Copy link
Contributor Author

uvtc commented Jul 6, 2019

I don't know anything about cppia, but on another note, I see now as of 4.0.0-rc3 that there's a direct to JVM bytecode target as well. Yow!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants