Good first features to contribute

[andrei-markeev]

There're now several simple-to-implement standard calls which can significantly improve overall range of supported by TS2C ES3 features. Very good for start. If somebody wanted to contribute to the project, here you go, pick one of these:

• decodeURI
• decodeURIComponent
• encodeURI
• encodeURIComponent
• String.toLowerCase
• String.toUpperCase

Let me know which one you picked in the comments.

Notes:

1. You can use src/standard/string/substring.ts as a reference:
   • implement Resolver
   • implement code template
   • add flag to HeaderFlags in program.ts
   • add function implementation and necessary dependencies to program.ts same as headerFlags.str_substring
2. Read src/README.md
3. Read ES3 spec (no need to read the whole spec, but at least read intently about the function that you're implementing)
4. Remember that ES3 uses UTF-16 encoding and this should be reflected in the implementation. Using ordinary C string operations isn't enough
5. Remember to use only C89 standard features in C implementation (gcc with flags -ansi -pedantic)
6. Create tests under tests/strings

[dhonx]

I am very interested in this project. let me try it and understand the source code. most likely I will contribute to this project. Good work..!!

[pitust]

I'm gonna try to do toLowerCase, toUpperCase and try to add bound checking (to splice() and slice()) and also, I think I'm gonna upgrade ints to 64bit, as js-os proved it doesn't break stuff.

[andrei-markeev]

@pitust please don't hard-update to int64_t, it should be done in a particular TSC target project, definitely not in the core. One of the main goals of this project is to be able to use resulting code on microcontrollers, and there are plenty 16-bit microcontrollers, that's why we're using int16_t as default. But it would be great to make it as some kind of a flag so that we can easily switch between int16_t, int32_t and int64_t.

[pitust]

@andrei-markeev When you target 16-bit you should link libgcc. For example, in my OS, I simply link libgcc and even though the target is x86, no 64-bit math, it works with 64-bit ints. But OK, I'm gonna add compiler switch insted of this.

[andrei-markeev]

I simply link libgcc and even though the target is x86, no 64-bit math, it works with 64-bit ints

I guess it depends on the platform a lot, and basically means that short is actually 64-bit on modern PCs (which makes total sense, anyway modern processors are 64-bit and operations on 64-bit registers are actually faster). But I will not be surprised if other compilers than gcc will treat it differently. Also, there are tons of customized gcc toolchains out there, so you never know 😄

The only thing that is guaranteed about short is that it is capable of containing 16-bit numbers: https://en.wikipedia.org/wiki/C_data_types

So basically we have to use typedef long int32_t and typedef long long int64_t, if we want to guarantee some sort of consistency across different compilers and target platforms.

One simple idea of how to implement it, would be to use number_t instead of int16_t, and typedef it conditionally to be either short, long or long long depending on a command line switch or alternatively some special comment in the source file, like // @int32_t or smth similar.

on the other hand, I feel like having explicit int16_t/int32_t / int64_t in the code makes the transpiled code a bit easier to understand and keep track of, so maybe naming number type explicitly is a good idea.