What is the license? I don't see it at a glance.
MIT It's placed in README
4coder editor is now fully open source
81–90 of 108 posts
Re: 4coder editor is now fully open source
#82Re: 4coder editor is now fully open source
#83Earlier quoted context omitted.
> : I would just like to add that I saw the author left several comments about the state of the code in the Readme that imply the code is very unstable. I dunno, I'm looking at their "4coder_base_types.h" header [0] and redefining basic types and builtin keywords for personal preference (yeah I know, static is overloaded) is a serious eyebrow raiser. [0] https://github.com/Dion-Systems/4coder/blob/62fe17699a99f7d2...
You can just hover over the keyword with an IDE and instantly see that it's just a typedef for static. There's nothing wrong with doing something like this, especially since it wasn't meant to be OSS and more of a personal project until now. In addition, i32 is not an ambiguous typedef. It's way clearer that this is a 32 bit integer than `int` is. Finally, big libraries do this as well. Freetype is notorious for type…
Assuming you're browsing in an IDE, and that the IDE understands your build system. Github for example doesn't detect that it's a typedef for static. There's also the fact that the keyword `internal` is overloaded, and not in a standard way. For example, does it mean that it's not exported (a la dllexport in msvc).
> In addition, i32 is not an ambiguous typedef. It's way clearer that this is a 32 bit integer than `int` is.
but that's not what the typedef is to, the typedef is to int32_t which is a standard type that is guaranteed to be 32 bits.
> If the big open source libraries can do it, what's wrong with a small one doing it too?
typedef'ing FT_POS is totally different - FT_POS is not redefining a basic type to be used all over the project, it's defining the types used to refer to coordinates. Freetype is also written in C, and is almost 30. You also better hope that when you're using these typedefs that any third party libraries (e.g. free type) also use the same aliases.
Re: 4coder editor is now fully open source
#84I get that the whole handmade shtick is to avoid existing libraries to allow for better software, but when you see things like [0], you realise what cmake is for... [0] https://github.com/Dion-Systems/4coder/tree/master/bin
Those scripts are incredibly simple, and super easy to write and maintain. It's a breath of fresh air compared to other build systems. But I won't defend the cpp, and neither does the author really.
Re: 4coder editor is now fully open source
#85Re: 4coder editor is now fully open source
#86I feel like a couple of posts on HN the past few months have been "X is going open source". It makes me question why projects that aren't open source when they initially release switch over to open source later. I understand keeping a repo private before having a working/stable product, but why release a product as closed source and then open it up later? Why not just keep the product off the market until it is ready to be released and make it open source before or at launch time?
I totally have space that I'm just crazy but as someone who tries to keep my stack as open source as possible I find myself not really interested in products that start closed source and eventually open up. Is it just me?
Just to reiterate: I'd rather a project go open source later vs never.
EDIT: I just realized the context for 4Coder was that it was a "we're ending this product so here's the source for anyone who wants it" -- I am super grateful for closed-source products that do this. But my question is still relevant for other projects that have done what I described above.
Re: 4coder editor is now fully open source
#87Earlier quoted context omitted.
Those scripts are incredibly simple, and super easy to write and maintain. It's a breath of fresh air compared to other build systems. But I won't defend the cpp, and neither does the author really.
But the scripts don't work without the cpp - you can't really excuse the build system without excusing the cpp file. All of the actual logic for the build system is in the cpp file, and at least on windows it fails at the first hurdle - it blindly assumes cl.exe is in your path which is not as common on windows as it is on linux for example.
I had already skimmed the cpp (at least the `build` functions). It’s not necessary for what they’re doing. It could be easily replaced with a shell script. I know because I’ve done something very similar, supporting I think even more build variants and compilers. This is mostly copied from a real script, except I mocked up `build` somewhat, since the real one is slightly more complicated.
build() (mkdir -p "$1" && cd "$1" && shift && “$@“ ; )
...
declare -a gcc=(-std=c89 -g -D_GNU_SOURCE -fpie -pie -fno-strict-aliasing -Wall -Wextra -Wformat=2 -Wstrict-aliasing=2 -Werror)
declare -a clang=(-std=c89 -g -D_GNU_SOURCE -fpie -pie -fno-strict-aliasing -Weverything -Wno-unused-macros -Wno-used-but-marked-unused -Werror)
declare -a debug=(-O1 -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -fno-optimize-sibling-calls)
declare -a asan=("-fsanitize=address,undefined,leak")
declare -a msan=(-fsanitize=memory)
declare -a isan=(-fsanitize=integer)
...
build "$build/x86_64-linux-gnu-gcc-addrsan-debug" gcc "${gcc[@]}" "${debug[@]}" "${asan[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-debug" clang "${clang[@]}" "${debug[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-addrsan-debug" clang "${clang[@]}" "${debug[@]}" "${asan[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-memsan-debug" clang "${clang[@]}" "${debug[@]}" "${msan[@]}" -o example "$src/example.c"
build "$build/x86_64-linux-gnu-clang-intsan-debug" clang "${clang[@]}" "${debug[@]}" "${isan[@]}" -o example "$src/example.c"
...
Very easy to write a powershell version for Windows.If you know the compiler flags you want, nothing beats literally just writing them all down in a script, when it comes to debugging issues.
Re: 4coder editor is now fully open source
#88Earlier quoted context omitted.
You can just hover over the keyword with an IDE and instantly see that it's just a typedef for static. There's nothing wrong with doing something like this, especially since it wasn't meant to be OSS and more of a personal project until now. In addition, i32 is not an ambiguous typedef. It's way clearer that this is a 32 bit integer than `int` is. Finally, big libraries do this as well. Freetype is notorious for type…
> You can just hover over the keyword with an IDE and instantly see that it's just a typedef for static Assuming you're browsing in an IDE, and that the IDE understands your build system. Github for example doesn't detect that it's a typedef for static. There's also the fact that the keyword `internal` is overloaded, and not in a standard way. For example, does it mean that it's not exported (a la dllexport in msvc).…
Re: 4coder editor is now fully open source
#89Earlier quoted context omitted.
> I wonder how do people come to a decision that it's a good idea to start their own text editor when vim and emacs exist. It's really a smaller decision compared with the point of view that text files as source code are "holding back our tools - https://dion.systems/dion_format.html So these guys are really thinking big.
If text files are holding you back. Smalltalk exists...
Re: 4coder editor is now fully open source
#90Earlier quoted context omitted.
But the scripts don't work without the cpp - you can't really excuse the build system without excusing the cpp file. All of the actual logic for the build system is in the cpp file, and at least on windows it fails at the first hurdle - it blindly assumes cl.exe is in your path which is not as common on windows as it is on linux for example.
It’s perfectly legitimate to say “run the script from a shell where the environment is set up”. In fact, it’s preferable, and you should only attempt to be “smart” and search for that type of thing if you really need it — why use any search logic at all, if it can be avoided. vcvars and its modern incarnations exist to facilitate this. I had already skimmed the cpp (at least the `build` functions). It’s not necessary…
But that's the standard for how to do things on Windows. That's how it works. Sure you might not like it, but personally I don't like the implicit assumption that everything is configured and "there" that your scripts and the OPs scripts assume.
Here's the alternative in cmake though:
cmake_minimum_required(VERSION 3.10)
project(hello_world)
add_executable(app main.cpp)
All of a sudden you have support for all major platforms, the workflow is the same (meaning you don't have platform dependent scripts like build_win and build_linux), it works out of the box with all major IDEs/editors, supportd optimised and stripped builds easily, and abstracts that away across platforms (-O2 Vs /O2, /Z7 instead of objcopy +strip). These are problems that have been solved for 30 years, and makeshift bash/batch scripts only make it harder for people to understand what's going on.