Please include the original code as a comment in the transpiled code

[jockm]

To aid in debugging please include the original TS code in the generated C code so you can see where you are in the original source when you are debugging. To use the example in the README:

var obj = { key: "hello" };
obj["newKey"] = "test";
console.log(obj);

the generated code might look something like this:

#include <stdlib.h>
#include <assert.h>
#include <stdio.h>

struct obj_t {
    const char * key;
    const char * newKey;
};

static struct obj_t * obj;
int main(void) {
    // Example.ts, Line 1: var obj = { key: "hello" };
    obj = malloc(sizeof(*obj));
    assert(obj != NULL);
    obj->key = "hello";

    // Example.ts, Line 2: obj["newKey"] = "test";
    obj->newKey = "test";

    // Example.ts, Line 3: console.log(obj);
    printf("{ ");
    printf("key: \"%s\"", obj->key);
    printf(", ");
    printf("newKey: \"%s\"", obj->newKey);
    printf(" }\n");

    free(obj);

    return 0;
}

[andrei-markeev]

I carefully considered this, but I think I would not do it, at least at this point of time. Maybe we can return to this idea later.

Three reasons:

1. ts2c is doing a lot of optimizations so that resulting code related to a certain original js statement, can be spread across the file quite a bit
2. the idea behind ts2c is to make the code as readable as possible, and in this case you wouldn't need to have these comments. if we have problems with readability, let's improve the generation rather than add comments
3. comments might be OK in read-only scenarios, but ts2c could be used for scenarios when you transpile the code, and then start making changes there. in this case comments will quickly loose their relevance and might become a source of confusion and mistakes

[jockm]

I am deeply disappointed in this response and hope you change your mind. If I am debugging the transpiled code, I don't care how readable it is, I need to know where it is in the original as quickly and easily as possible so I can go back, fix, a bug, transpile, recompile, etc

No quality of readability improvements can make going back to the original code faster than knowing what the original code is.

While TS2C can be used in scenarios where you transpile the code and then use that as the basis of a new codebase, that is what command line options to enable/disable are for.

[andrei-markeev]

if it comes, it is going to be a compiler flag, no doubt about that.

however, my main concern is in p.2 above: if reference to the original code will be available too easily, it will be much harder to evaluate resulting readability. now if I see that something is looking horrible (like e.g. temporary strings allocations) and it is hard to tell to which original line it relates, I know that I should fix it if possible. but if there was a comment, then I wouldn't care much...

I mean, it's more like a psychological thing. so by adding such convenience feature, I would actually reduce the quality of the resulting product...

[jockm]

Then you clearly want TS2C to be something different than I need, or that you seem to be describing it as. Unless you can tie directly into my compiler toolchain and include debugging information so I can debug the original JS code, then what I asking for is essential for any code base more than a couple of hundred lines — this isn't hyperbole, it is experience, I have used (and written) tools that transpile to C (or other languages).

TS2C is not the tool for me then

[andrei-markeev]

Hey Jock, I see that you are quite offended by this decision, and I am really sorry about that.

Adding the comments you request isn't hard. In fact, it can be done quite easily (even though as I mentioned, sometimes code is spread across the file so annotating accurately is a bit tricky).

But... currently ts2c is work in progress and cannot really be used for compiling anything more than couple of hundred lines of code. It is simply not ready yet. I tried, and there are just too many issues. So you're correct here: TS2C is not the tool for you... yet.

Let's return to it at least when ES3 coverage is finalized.

[jockm]

I believe you have misread my tone, I am not offended, I am just disappointed and as ts2c stands it isn't suitable for it's purpose to me.

I am not (just disappointed) because I can't use it, it is because your stated reasons make it feel like you haven't thought about what it would be like to actually use ts2c on a large codebase where you use a debugger. Readability and the need to link back to the original source are two completely different things, and one isn't an excuse not to include the other.

Finally a quick note if ts2c isn't ready yet, then you need to communicate that in your readme. Set expectations accordingly, you can always change the wording over time.

On Thu, Sep 3, 2020 at 1:56 PM Andrei Markeev notifications@github.com wrote:

Hey Jock, I see that you are quite offended by this decision, and I am really sorry about that.

Adding the comments you request isn't hard. In fact, it can be done quite easily (even though as I mentioned, sometimes code is spread across the file so annotating accurately is a bit tricky).

But... currently ts2c is work in progress and cannot really be used for compiling anything more than couple of hundred lines of code. It is simply not ready yet. I tried, and there are just too many issues. So you're correct here: TS2C is not the tool for you... yet.

Let's return to it at least when ES3 coverage is finalized.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andrei-markeev/ts2c/issues/73#issuecomment-686760710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE5T7ZAJW3NXAGGZUVMSKDSD77I3ANCNFSM4QLLKVXA .

-- Jock Murphy http://www.jockmurphy.com Photographer Writer Storyteller

[andrei-markeev]

Finally a quick note if ts2c isn't ready yet, then you need to communicate that in your readme. Set expectations accordingly, you can always change the wording over time.

It is stated very clearly in README

[jockm]

I disagree. I see what features are supported or not, but that isn't the same as not being production ready. I routinely use a C compiler that isn't fully C99 compatible, but is production ready. Incomplete coverage isn't the same as fitness for purpose. If I have missed where you say it isn't production ready, then I apologize.

On Thu, Sep 3, 2020 at 2:40 PM Andrei Markeev notifications@github.com wrote:

Finally a quick note if ts2c isn't ready yet, then you need to communicate that in your readme. Set expectations accordingly, you can always change the wording over time.

It is stated very clearly in README

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andrei-markeev/ts2c/issues/73#issuecomment-686778495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE5T76LAEAAS5STA5XI2J3SEAEN5ANCNFSM4QLLKVXA .

-- Jock Murphy http://www.jockmurphy.com Photographer Writer Storyteller

[andrei-markeev]

Readme has "Project status" section that says "Work in progress" in bold: https://github.com/andrei-markeev/ts2c#project-status

I'm not a native english speaker, but I never heard of projects that are WIP and at the same time "Production ready" 🤔

I mean, anyway, I don't even really agree with your statement that I haven't thought of large codebases:

because your stated reasons make it feel like you haven't thought about what it would be like to actually use ts2c on a large codebase where you use a debugger

I strongly believe in readable code, and trying to make ts2c into a transpiler that produces code that doesn't need any comments. Comments are considered harmful for a reason, and I would avoid them whenever possible.

[jockm]

There are lots of open source projects that aren't considered complete but are considered stable enough for production use. The Haiku community is notorious for this. Their OS has been in Alpha for years and years because it wasn't feature complete but was considered highly stable.

Readable code is important, but if I am stepping through code in a debugger and need to refer back to the original JS code then I need to know the line number and what that line said. As for your comment about comments are considered harmful is not universally accepted and further evidence that we have very different philosophies and that TS2C probably isn't a tool for me

On Thu, Sep 3, 2020 at 3:33 PM Andrei Markeev notifications@github.com wrote:

Readme has "Project status" section that says "Work in progress" in bold: https://github.com/andrei-markeev/ts2c#project-status

I'm not a native english speaker, but I never heard of projects that are WIP and at the same time "Production ready" 🤔

I mean, anyway, I don't even really agree with your statement that I haven't thought of large codebases:

because your stated reasons make it feel like you haven't thought about what it would be like to actually use ts2c on a large codebase where you use a debugger

I strongly believe in readable code, and trying to make ts2c into a transpiler that produces code that doesn't need any comments. Comments are considered harmful for a reason, and I would avoid them whenever possible.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andrei-markeev/ts2c/issues/73#issuecomment-686797569, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE5T74ZGOAHUFANZHI7W5DSEAKSLANCNFSM4QLLKVXA .

-- Jock Murphy http://www.jockmurphy.com Photographer Writer Storyteller

[ceremcem]

Reason number 1 in https://github.com/andrei-markeev/ts2c/issues/73#issuecomment-686730153 seems highly convincing to me in a technical aspect:

ts2c is doing a lot of optimizations so that resulting code related to a certain original js statement, can be spread across the file quite a bit

I can't understand why the readability issue became prominent.

Original request is very much like Source Maps in Compile-to-Javascript languages. I personally use LiveScript and even source maps can't help sometimes because LiveScript supports one liners and other cool features which you can't simply put a break point in the middle. When in doubt, I go to http://livescript.net and compile the small piece of code that confuses me, clarify things and then continue coding the main application.

My point is missing the "Source Maps" feature isn't the end of the world if TS2C were stable/complete or when TS2C is stable/complete. Also, if it's not a priority, then it's not a priority. Moreover, inserting related JS code inside C code as comments seems much more harder to me than to create actually a "Source Maps" system that integrates with GNU debugger and Chromium Dev Tools, simply because of the mentioned Reason#1

However, I guess having an active "Source Maps" system will make this project become stable much more faster.

but ts2c could be used for scenarios when you transpile the code, and then start making changes there.

This looks very bad. IMHO, that should never happen. You should never have to modify the generated code because doing that means you will permanently loose your original code, almost "forever". If you modify the generated code, you have to choose one of the following options:

1. You will never change the original code (because you'll loose the changes that you made manually on generated code)
2. You will re-apply the manual changes every time you changed the JS code.

Both are unacceptable.

There are lots of open source projects that aren't considered complete but are considered stable enough for production use.

It's hard to disagree. WIP and "unstable" are two different things. WIP doesn't necessarily mean unstable and unstable doesn't necessarily mean WIP or alpha or beta.

However, both (WIP and unstable) may be used in production at user's own risk. I've also never seen a project that states "Our code is WIP but you can use in production". That would be weird. Users might consider the WIP code suitable for production, but that's the users' decision, not the owners'. Same is true for "unstable" projects. As an example, I use an unstable application (FreeCAD_Assembly3) in the heart of production, at my own risk, of course along with extreme measures. I'm also using BTRFS filesystem for my laptop and servers for more than 2 years now. It's also not considered stable yet, but please see this explanation: https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F

To sum it up, stating the project as WIP actually means "not suitable for production but you can use at your own risk".

[jockm]

@ceremcem You raise some good points, but simply having source maps isn't always enough. I was first drawn to TS2C because I am doing a project for the eZ80 microprocessor. I thought it would be interesting to use transpiled JS code in the project for reasons too boring to mention. Unlike Microchip with their AVR microcontrollers, Zilog isn't using a mainstream C compiler like GGC or LLVM. Hell I don't even know if there is any documentation on their file formats!

So some kind of in code comments (or something similar) would be needed to allow me to map where I am in the debugger back to the original code