Gnimuc
commented
3 years ago Hi,
As written in the README:
This package provides several macros for making life easier when translating C code to Julia.
so you might find those lightweight helper macros in this package useful if you're frequently porting C code to Julia. This usually happens when you've wrapped a C library and would like to translate a C example to Julia.
It seems needed/useful some of it e.g. for static, but I'm thinking is there a good usecase for some of the C for syntax, such as its"for"? Are you just aiming for some completeness? To me it seems like inferior syntax to what Julia has (I like how Julia's for at least can be neutral, work for 1-based and 0-based arrays), so I'm conflicted about this part of the package, in case people might adopt.
Your package is probably going to be used mostly for porting C code, or C interop, and C "for" may slightly help for the former. I see you have "C2Julia.jl" now archived. A transpiler may be valuable and slightly simpler with this package.
Yes. The C-for syntax is for C2Julia.jl, I never use it in any other projects.
As of C2Julia.jl, the main challenge is how to handle C macros. Since Julia is a rather high-level language, it's hard to generate readable Julia code and it turned out that it was even easier to directly read the original C code and do a rewriting manually than to start with the auto-generated Julia code. Anyway, it's one of my toy projects for exploring Clang.
I went looking for who uses the package and besides you only one public user @IanButterworthIan's which may be depending on it needlessly: ... ... I'm puzzled why it fixed back TimeZones, might have to how to do with LazyArtifacts, but as your package only depends on neither, only CEnum, and it on none, it's a mystery.
Well. That's indeed a mystery. :) I guess there is something wrong with your package environment, maybe you can give it a retry in a clean environment.
Is your package mainly a proof-of-concept (like PythonSyntax.jl) or an exercise for you?
No. If you take a look at the implementations of those helper macros provided by this package, you will find that they are just 20~50-lines-simple-naive-helper macros. The purpose of this package is merely for making life easier when translating C code to Julia, not anything else. It's a stable package with no heavy dependency(see #1 for why I refused to integrate those packages) and every Julia user with a basic understanding of Julia macros can quickly debug the package if something goes wrong or tweak the behavior for their own use case.
FYI (one of packages, that may overlap with your usecase): https://github.com/analytech-solutions/CBinding.jl
Are you talking about the old CBinding.jl or the new one?
The goal of the CBinding.jl is to provide a new easy-to-use Julia-C interop interface. The only part that overlaps with CSyntax.jl is CEnum. Besides, as it's a new solution, it overlaps Julia's ccall and @ccall macro for calling vararg functions.
The main functionality of CBinding.jl(both the old one and the new one) and the issues it aims to solve are documented in this post. The problem is solved by using macros at the lowering level. Another package with a similar use case is Cxx.jl. It solves the problem at the LLVM-IR level and hence is more generic. Clang.jl workarounds the problem and does trade-offs at the Julia code level, so one may need to use the generated macro-free Julia code along with the helper macros in CSyntax.jl to save time.
In practice, all of these packages have their own use cases and I don't find there are any use cases overlapped.
Hi,
First I want to say you're doing awesome work, elsewhere, and with this package, at least partially, as it puzzles me.
It seems needed/useful some of it e.g. for static, but I'm thinking is there a good usecase for some of the C for syntax, such as its"for"? Are you just aiming for some completeness? To me it seems like inferior syntax to what Julia has (I like how Julia's for at least can be neutral, work for 1-based and 0-based arrays), so I'm conflicted about this part of the package, in case people might adopt.
I went looking for who uses the package and besides you only one public user @IanButterworthIan's which may be depending on it needlessly: https://github.com/IanButterworth/SpinnakerGUI.jl/blob/dea3b0adef3dbe53da32219470807082a94d8279/Project.toml#L7
Installing it I get lots of downgrades:
I know why such happens, that's not the question in this case, I get when then installing your package (only) one upgrade:
I'm puzzled why it fixed back TimeZones, might have to how to do with LazyArtifacts, but as your package only depends on neither, only CEnum, and it on none, it's a mystery.
In his package I can't even seen it used, only indirectly (if that?):
I thought of making a PR there to drop these lines and the dependency, but it seems to not slow down except at most to a tiny degree.
Is your package mainly a proof-of-concept (like PythonSyntax.jl) or an exercise for you?
Your package is probably going to be used mostly for porting C code, or C interop, and C "for" may slightly help for the former. I see you have "C2Julia.jl" now archived. A transpiler may be valuable and slightly simpler with this package.
FYI (one of packages, that may overlap with your usecase): https://github.com/analytech-solutions/CBinding.jl