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

Embed R in TIC-80 as an additional scripting language #2688

Draft
wants to merge 61 commits into
base: main
Choose a base branch
from

Conversation

bryce-carson
Copy link

R is my favourite langauge, and it isn't embedded in many (if any) applications that don't focus on simply providing a front-end to R for R. This pull request is intended to fully embed R as a new scripting language in TIC-80.

I have worked on this for a couple days now.

At the moment I am working on getting GitHub Actions setup so that my fork will have its own GitHub Pages website containing the exported HTML document of the literate Org source file I'm doing my development work in. I'll also work, eventually, on getting GitHub Actions to automatically tangle the source file r.c from the Org file and check that into the repository's src/api folder.

Code review and advice on embedding is greatly appreciated, and eventually I'd love for this to become an official language and not simply exist in my experimental fork.

- Use Org babel instead for literate programming; works just fine as an
alternative and is more popular.

- Update the r.org file beyond its translation from r.nw
@bryce-carson
Copy link
Author

@bryce-carson
Copy link
Author

It makes sense to use https://github.com/wch/r-source as a Git submodule.

@bryce-carson
Copy link
Author

At the moment my HTML file which should be relocated to the root directory as index.html exists at src/c/TIC-80/src/api/r.html

@bryce-carson
Copy link
Author

The literate document will help the maintainer of TIC-80 review the code, and offer guidance on its development. 🤷 I think.

The only build-time error encountered is the following, now:

/home/bryce/src/c/TIC-80/src/api/r.c:175:10: fatal error: ../build/assets/rdemo.tic.dat: No such file or directory
  175 | #include "../build/assets/rdemo.tic.dat"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/r.dir/build.make:76: CMakeFiles/r.dir/src/api/r.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:283: CMakeFiles/r.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
@bryce-carson
Copy link
Author

I am at the point of conducting my first informal integration tests. I was able to resolve all of my compile-time issues except the issue quoted in the last commit. I will reproduce that quotation in this comment for easier viewing.

/home/bryce/src/c/TIC-80/src/api/r.c:175:10: fatal error: ../build/assets/rdemo.tic.dat: No such file or directory
  175 | #include "../build/assets/rdemo.tic.dat"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/r.dir/build.make:76: CMakeFiles/r.dir/src/api/r.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:283: CMakeFiles/r.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

@bryce-carson
Copy link
Author

https://github.com/nesbox/TIC-80/tree/0e34eaaa50bfdefa546988edc0c8efa1bf280130/build/tools

I had seen these tools before, but had no idea what they were used for, and I couldn't compile the bin2txt.

/usr/bin/ld: /tmp/ccYrGMuK.o: in function `main':
bin2txt.c:(.text+0x139): undefined reference to `compress2'
collect2: error: ld returned 1 exit status

I have zlib-devel installed on Fedora, so I should have zlib.h and compress2 should be defined.

I only realized what the tools were used for after seeing this file, which given it is a BAT file won't run except on Windows. Another PR I may or may not open could address that by writing operating-system agnostic CMake scripts to identify all demo and benchmark files and run the necessary tools on them at build time, automatically (mark in place of benchmark is a bad naming convention in my opinion). That will make updating these files much easier.

@bryce-carson
Copy link
Author

https://github.com/nesbox/TIC-80/tree/0e34eaaa50bfdefa546988edc0c8efa1bf280130/build/tools

I had seen these tools before, but had no idea what they were used for, and I couldn't compile the bin2txt.

/usr/bin/ld: /tmp/ccYrGMuK.o: in function `main':
bin2txt.c:(.text+0x139): undefined reference to `compress2'
collect2: error: ld returned 1 exit status

I have zlib-devel installed on Fedora, so I should have zlib.h and compress2 should be defined.

I only realized what the tools were used for after seeing this file, which given it is a BAT file won't run except on Windows. Another PR I may or may not open could address that by writing operating-system agnostic CMake scripts to identify all demo and benchmark files and run the necessary tools on them at build time, automatically (mark in place of benchmark is a bad naming convention in my opinion). That will make updating these files much easier.

Ideally, actually, none of these DAT files would be present in the repository and the required DAT files would be built at compile-time only.

@bryce-carson
Copy link
Author

r.html.tar.gz

This compressed HTML file is the exported literate document in which I wrote my work.

This was my first real C project, I'm still learning the language after studying Narain Gehani's C: an Advanced Introduction.

I was able to sort out the DAT files, and I was able to compile and link my code into TIC-80.

The application doesn't crash on start, which is good, but anything related to R simply doesn't work. When I run new r an R cartridge isn't created, a Lua cartridge is created, and I cannot find rdemo.tic or rmark.tic when browsing the directories from within TIC-80.

I think at this point I will need some hand-holding to complete this PR, learn what I need to, and advance in my understanding of complex C software.

Regards and thanks!

@bryce-carson bryce-carson marked this pull request as ready for review September 26, 2024 05:50
@bryce-carson bryce-carson marked this pull request as draft September 26, 2024 05:52
@bryce-carson
Copy link
Author

A couple of notes:

  • When no languages are defined the new command will inform the user of that, but if the user tries to create a cartridge of a language not properly integrated---or not integrated at all---then TIC-80 will simply create a Lua cartridge.
  • Sometimes the build will include the Lua langauge despite -DBUILD_WITH_LUA=OFF.

@bryce-carson
Copy link
Author

@sthilaid, would you mind looking at this pull request and telling me if I've missed a number of big steps? I'm beginning to really struggle with this language integration and I'd love to hear about your experience integrating Scheme. I'll update this PR with r.c so you can look at that directly.

if(NOT BUILD_STATIC)
include("cmake/renv.cmake")

set(R_LIB_DIR "/usr/include/R")
Copy link

@aitap aitap Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of hard-coding the paths, it's better to run the particular R you would like to link with and ask it about its include path, something like Rscript -e 'cat(R.home("include"))'.

There is a number environment variables documented in ?R.home which will have to be exported using calls to R.home(). For $R_HOME there's the R RHOME / R --print-home shortcut.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the paths I determined with R CMD config --cppflags and R CMD config --ldflags. I had much difficulty with CMake, despite reading some of the manual and beginning the tutorial until I felt comfortable to try again (after linking against a library in one of the introductory tutorial steps).

I have written an additional CMake file to generate a header which I can include to set the environment variables appropriately during runtime when they aren't set otherwise. At the moment I want to focus on getting a working integration running on my own system before I worry further about making it portable; it was a struggle to get where I am now.

I do know about the need for environment variables, libraries, etc. that R is dependent upon for its operation. I'll focus on them again later.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the paths I determined with R CMD config --cppflags and R CMD config --ldflags.

By this I mean that I'm aware of the commands and will use them later. For now, hard-coding was a troubleshooting methodology to simply ensure that they're there.

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.

2 participants