project setup and improvements

[pyx]

Besides the pull request I just created (#2), I can also help you to setup the project structure and installation script:

• setup.py and friends
• dependencies handling, I think the only one right now is cairocffi
• proper command line handling with argparse, thus, a better CLI

• unit testing if needed

  then this parser can be installed and run as simply as:

# make virtualenv, optional
pip install TMDLang
# then, to run
tmd

It should be possible to have it in homebrew this way.

In function Pass1 inside tmd.py, module-level global variables in TMDScanner are being modified, which I think is a BAD idea.

There are also many places that can be improved, and once I understand what the language spec. is, I might be able to help you on the parser as well, but there is no documentation now and reading regular expressions is no fun.

BTW, I cannot run the program (Linux: gentoo, with Python 3.5.2, cairocffi 0.7.2, cairo-1.14.6)

The first problem is that you seemed to switch to CFFI version of python cairo binding from pycairo, but you still referring to pycairo in TMDDrawer.py (import cairo), this one should be easy to fix.

The second one is when I tried it with your work

python src/tmd.py example/三天三夜.tmd

I got something like:

Traceback (most recent call last):
  File "src/tmd.py", line 96, in 
    main()
  File "src/tmd.py", line 92, in main
    TMDDrawer.ChordDrawer(Page, testChordList)
  File "/home/pyx/projects/TMDLang/src/TMDDrawer.py", line 39, in ChordDrawer
    Surface.move_to(Chord[3][0], Chord[3][1])# 2200, 3208 for temp
IndexError: string index out of range

This should be either something wrong with the parsing logic (missing required non-empty string field in ChordList) or feeding erroneous input data to the parser with which it cannot handle gracefully.

[aguai]

thank you so much for reviewing my code... I am still trying to figure out how to merge your branch correct I do have using venv but yet I haven't decide if this should compatible to pypy/python2 or maybe build with nuitka for distribute... most of syntax is by now written in Chinese because this program is some special need like "TV Show Band Numeric Notation" which as I can tell only using in Chinese speaking area... I'm drafting a English version Syntax Spec ASAP (but I really am a pop music producer) (the example file "三天三夜" is one of my famous work so there won't be any copyright trouble...) THANK YOU VERY MUCH for the suggestion....<( )>

[pyx]

I tried to contribute because I think this is an interesting project.

First of all, I have no problem in reading and writing in Chinese, the reason that I used English here it is I believe there will be non-Chinese speaking people interested in this project and might want to help, too. So we should try our best to lower the barriers to entry. BTW, I also know the name of the language/executable (tmd) is an intended pun :)

I also aware that you are a professional composer/producer and mentored in some talent shows.

I've heard that you have the plan to re-implement this in golang later, and you mentioned nuitka here, is it document compiling speed the real concern? From my experience, document compilers, so to speak, usually do not care about this unless the compiler is meant to be used in transforming documents en masse.

Regarding python 2/3 compatibility, if the python 2 you are targeting is no less that 2.7, then, with careful coding and discipline, it is possible to have a single code base that can be run in both 2 and 3, provided you are not using something like async/await and yield from. I've done that before many times, and I can help here, too.

Once I have the time and enough understanding to make this works in my system, I will then add some necessary files to make it pip install-able, if you don't mind.

I've come up with an idea about the language specification as well, and I think it is more suitable to discuss in another issue, I will draft that and open a new issue later on.

[aguai]

ah~~~ so you are capable to read all the stupid note I wrote >///< the idea of golang and nuitka is not really for speed but for distributing it... considering the difficulty to convince my colleges to learn how to use a terminal or command line stuff, I guess the easiest way to install on others computers is to pack it into a simple bottlepy/flask app that runs in localhost(or an Electron Application?) ... what I really want to achieve is to define a format to write down all the details a show/song/program/film/play contains. so that version control can be happened in this old school business...(hard to explain how low efficient they are doing these jobs nowadays...)
but...before all... I am going to try to make the band style numeric notation(樂隊簡譜) part first for running show... and than IPA Lyrics(國際音標註釋歌詞) for coaching singer... hopefully that will be done in a few days if my other jobs schedules keep running on track...Orz it is really pleasure to get help from you. THANKYOU again!!!<_O_>

[pyx]

Haha, your notes are by no means stupid.

I know Apple/Mac OS is ubiquitous in musical industry, now I understand, ease of distribution is of essential here, you have a very valid point, I totally agree.

Providing easy-to-install package is only half the story, so we need a way to invoke this application afterwards, and that should not involve terminal and/or command line, as you mentioned, that means a GUI?

My 2 cents:

• Packaging can be done with something like py2app (packaging to Mac OS), I agree homebrew is NOT a valid choice here. I have not worked with py2app, I will do some research on that and tell you my findings.
• GUI, for desktop oriented design, whether we need a bundled editor or just a file chooser dialog, PySide (python Qt binding) should be a good native-looking cross-platform solution. If mobile-first, kivy is hot now. Web App disguise as platform-native application is another way to go, like you said, bottle.py + html5 + css3.

You make the decision and I will evaluate some possible combinations.

[aguai]

I am thinking electron...(or any atom/vscode ext?)

[pyx]

Electron is a valid option, but then it is better javascript all the way down. Depending on your view, it is either heaven or hell. :)

atom/vscode(or any other editor) extensions only solve part of the problem, rendering should be done with an external executable, to avoid vender lock-in (implementing the renderer in specific editor plugin) or repeated work (written once for each editor we support),

Now that you gave me some insight, I have another idea that I want to discuss with you privately, is your gmail okay?