anael-seghezzi/ctoy

Interactive C live coding environment

ctoy's Issues

reserved identifier violation

I would like to point out that identifiers like "_CTOY_H_" and "_M_DIST_T" do eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Clarification of project structure for CMake scripts

It seems that some software components are provided here.

• CToy
• CToy player
• C compiler
• Bundled libraries

How do you think about to express these dependencies better in improved CMake scripts?

• Using an updated command like "project"
• Reuse of the module "ExternalProject"

dyld: Library not loaded: @rpath/libtcc.dylib crash

When i try to run ctoy from mac os High Sierra (after compiling from source code) i got this error.
dyld: Library not loaded: @rpath/libtcc.dylib Referenced from: /Users/Renato/Downloads/CToy/Build/src/./CToy_player Reason: image not found Abort trap: 6

Any ideas why ?

Consider replacing OpenAL by mini_al

My experience: after more than 4 years using OpenAL for raylib, just switched to mini_al library.

It's small, single-file header-only, multiplatform and removed the need of distributing OpenAL32.dll with your programs. I think it can make CToy a more self-contained product.

Help with CToy

Hey,

I'm uncertain if the Github issue tracker should be used like this, but it does seem the most convenient for me.

I'm writing some code with CToy that compiles C files, which it then runs. Similar to one of your samples. I'm getting the following errors about repetition, and I'm wondering if you recognise which part I'm missing?

`In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:845: error: 'stbi_failure_reason' defined twice... may be -fcommon is needed?

In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:876: error: 'stbi_image_free' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:944: error: 'stbi_load' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:968: error: 'stbi_load_from_memory' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:975: error: 'stbi_load_from_callbacks' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:996: error: 'stbi_loadf_from_memory' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1003: error: 'stbi_loadf_from_callbacks' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1011: error: 'stbi_loadf' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1035: error: 'stbi_is_hdr_from_memory' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1049: error: 'stbi_is_hdr' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1072: error: 'stbi_is_hdr_from_callbacks' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1086: error: 'stbi_ldr_to_hdr_gamma' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1087: error: 'stbi_ldr_to_hdr_scale' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1090: error: 'stbi_hdr_to_ldr_gamma' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:1091: error: 'stbi_hdr_to_ldr_scale' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:3708: error: 'stbi_zlib_decode_malloc_guesssize' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:3724: error: 'stbi_zlib_decode_malloc' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:3729: error: 'stbi_zlib_decode_malloc_guesssize_headerflag' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:3745: error: 'stbi_zlib_decode_buffer' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:3756: error: 'stbi_zlib_decode_noheader_malloc' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:3772: error: 'stbi_zlib_decode_noheader_buffer' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:4144: error: 'stbi_set_unpremultiply_on_load' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:4149: error: 'stbi_convert_iphone_png_to_rgb' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:6155: error: 'stbi_info' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:6177: error: 'stbi_info_from_memory' defined twice... may be -fcommon is needed?
In file included from /tmp/web_native/img_util.c:4:
/tmp/web_native/stb_image.h:6184: error: 'stbi_info_from_callbacks' defined twice... may be -fcommon is needed?
/tmp/web_native/img_util.c:7: error: 'm_image_load' defined twice... may be -fcommon is needed?
/tmp/web_native/img_util.c:16: warning: implicit declaration of function 'm_image_create'
/tmp/web_native/img_util.c:16: error: 'M_UBYTE' undeclared
`

`libtcc_hello` sample doesn't work as intended

When I try to run the fourth sample I get this output:

<sample libtcc_hello>
tcc: error: file '/usr/local/lib/tcc/x86-64/libtcc1.a' not found

It seems to be looking for libtcc1.a in the system path instead of using the x86-64 folder located in the root directory, how can I solve this issue? Is this supposed to be the default behavior?

Creating the required route and moving the static library seems to make it work correctly, but this could become a problem when shipping a CToy program with that dependency, since it would not be able to find it there.

OS: Linux Mint 21.3 (based in Ubuntu 22.04 LTS)

Add ability to run any source file through a command line option

Can I opt to remove GLES window?

I want to use CToy for learning algorithms, but it is very annoying to see a black screen that I never needs...

Also, I wish there could be Makefile support so we have can a live-reloading infrastructure in basically anywhere.

Issue with my Linux port

It relies on a system installation of your fork of tcc. I get this error now that I've removed it - "tcc: error: file '/usr/local/lib/tcc/x86-64/libtcc1.a' not found"

I guess this is some RPATH thing. I did readelf -d, and the RPATH entry looks like this:
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/]

libtcc1.a is correctly installed alongside the CToy executable.

I will fix this

CToy crashes with SIGSEGV from libpthead.so, Arch Linux

This wasn't an isssue on my machine with Ubuntu, but my laptop with Arch Linux. It's only relevant for the CToy executable. CToy_player does work, which makes sense because it doesn't compile with the thread stuff.
What is the idea behind these two executables, CToy and CToy_player?

I upgraded my entire system, and I still get the error, meaning that this fails with libpthread version 2.25 and 2.26.

Thread 1 "CToy" received signal SIGSEGV, Segmentation fault.
0x00007ffff768d29e in pthread_join () from /usr/lib/libpthread.so.0
(gdb) bt
#0 0x00007ffff768d29e in pthread_join () from /usr/lib/libpthread.so.0
#1 0x000000000047b7f1 in thrd_join ()
#2 0x0000000000464cbf in ctoy.src_thread_restart ()
#3 0x000000000043c579 in main ()

F*** you!

Why is this only available on 64-bit OS? I don't have any 64-bit PC at hand at the moment, so a port to 32-bit will make me happy. I have had enough with two other free fantasy consoles being only on 64-bit and not having a 32-bit release.

Add a license

I can't find any license information in this project. Would be nice to have a LICENSE file to know if people can contribute.

Missing VCOMP140.dll and VCRuntime140.dll

On a freshly installed Windows 10, downloaded CToy-1.05-WIN-x86_64.zip
When I launch CToy.exe or CToy_player.exe it reports missing dlls from Microsoft Visual C++ 2015 Redistributable

Downloading and installing Redist solves the problem, so it's not a big issue.
https://www.microsoft.com/en-us/download/confirmation.aspx?id=52685

imgui_hello.c sample undefined symbol

I already placed the compiled libcimgui.dll and libcimgui.dll.a on the resources folder where ctoy.exe resides..

The rest of the samples works fine.

tcc: error: undefined symbol 'igGetIO'
tcc: error: undefined symbol 'ImGuiIO_AddInputCharacter'
tcc: error: undefined symbol 'ImFontAtlas_GetTexDataAsRGBA32'
tcc: error: undefined symbol 'igCreateContext'
tcc: error: undefined symbol 'igDestroyContext'
tcc: error: undefined symbol 'igNewFrame'
tcc: error: undefined symbol 'igText'
tcc: error: undefined symbol 'igButton'
tcc: error: undefined symbol 'igInputText'
tcc: error: undefined symbol 'igSliderFloat'
tcc: error: undefined symbol 'igRender'
tcc: error: undefined symbol 'igGetDrawData'

vsync control / frame limiting

Is there any way to control vsync and/or frame limiting? On my computer the hello_world example runs overly fast (at 100 % CPU core usage).

[RFC] A CToy based Linux distro

This is an idea I've had a few days ago and wouldn't mind hearing everybody's opinion on.

I think it would be great to have a small, educational distro that is less focused on performance but more so on learning.

Such a distro would provide many/most (ideally all. Albeit, that might be too fiddly when it comes to coreutils or the web browser. Definitely too cumbersome for Xorg) of its applications as simple folders that contain an application manifest, a README, the CToy executable renamed to the application's name and a src directory with the main.c file and any additional source modules.

The core system would consist (among other things) of:

• A small floating window manager similar to TinyWM.

• A similarly small but extensible terminal emulator.

• A minimalist dock and/or rightclick menu to easily open applications from.

• A "package manager" that would first read the application manifest from the remote, then download/git clone the repository to ~/Apps/ (unlike defined otherwise inside the application manifest).

• A kind of source browser that conveniently scans ~/Apps/ for folders, then represents the names as a tree view, allowing people to conveniently view/edit an application's source code from one centralized hub.

• A polished version of catclock (because every OS needs to have a Kit Kat clock).

• Additional tools, frameworks and beginner-friendly documentation to easily develop additions like XScreensaver modules, docklets/widgets, text or image editors, CLI utilities, demos, games, emulators, et al.

As a main X11 library I'd encourage people to use XCB rather than XLib. While this makes code more verbose, it also teaches a more modern way to approach graphics programming.

The main goal of such a project would be to encourage young (and those young at heart) coders to write and share software.
It would explicitly be a learning tool, not the next macOS™.

[Feature Request] Official RaspberryPi Package

A lot of people are interested in running fantasy consoles on RPi, as an easy way of creating games that will run well on limited hardware. Something similar, based on C, could be popular.

Completion of error handling

Would you like to add more error handling for return values from functions like the following?

• malloc ⇒ m_dist_transform_1d
• read ⇒ ctoy__io_replace

Change when tcc build fail, fallback to previous working copy of program instead of blocking

That behavior allows to edit self code for example through Dear ImGui.

No documentation?

Any plans to make docs for the API?

Complete quoting for parameters of some CMake commands

Some parameters (like "${MTCL_SOURCE_DIR}/3rdparty/glfw/include") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like semicolons.

I would recommend to apply advices from a wiki article.

Compiling on Linux, GLFW Question

Hey,

I've been working on getting this to work on my Linux machine and I had linker issues with the GLFW you had bundled with it. I replaced it with https://github.com/glfw/glfw, and I got past those issues.

Your GLFW directory has less stuff than the original. Is it because you got it from a fork, and if so could you give me a link? Or is it something you cleaned up yourself, in which case could you tell me what stuff I should cut out?

UPDATE: CToy is now compiling & running on my Linux machine

Feature request: Add compatibility with sokol

It would be nice to be able to use sokol with Ctoy beside OpenGL ES2 directly.