Re: Google Auth API
On Tuesday, 18 June 2024 at 01:38:04 UTC, Vahid wrote: Hi, Has anyone here had experience implementing the Google Auth Library in DLang? Specifically, I am looking for guidance on handling OAuth 2.0 using JWT. Are there any current libraries available for this purpose? You may reference https://forum.dlang.org/post/nqkaaemzsheljxnif...@forum.dlang.org You may reach out to Adam, he most likely have code for this somewhere.
Re: Google Auth API
On Tuesday, 18 June 2024 at 01:38:04 UTC, Vahid wrote: Hi, Has anyone here had experience implementing the Google Auth Library in DLang? Specifically, I am looking for guidance on handling OAuth 2.0 using JWT. Are there any current libraries available for this purpose? This is why I can't use D for work. Working with cloud services is a major challenge without these SDKs.
Re: Call an external program from CTFE
On Sunday, 23 June 2024 at 16:33:54 UTC, realhet wrote: Hi, Is there a way to call an external program from CTFE? Use case: Inside a module I want to put some GLSL code. I also want to generate that GLSL code using CTFE. And when it's done, it would be nice if I was able to save that GLSL code into a temp file and call the glsl compiler on it. The goal is that the compiled version of the module would contain also the compiled version of that GLSL shader. And the time of the GLSL compilation could be the exact same time of the EXE compilation. This sounds a bit of hacking, but from viewing from a multi-target build perspective, it can make sense. Calling a compiler from another compiler... Why not? :D The nearest thing I've found is the "include file contents" 'macro', that can be enabled with a command line parameter. (Maybe it's already deprecated, I'm not sure.) My other way to do this would be an automation inside my IDE. But if something could be done on the language level it's always better than doing it by using external tools. ctfe is intentionally hobbled "for safety"; while theres bugs and edge cases I dont think anyone has a sane way to escape to full execution realistically you should just write a build script with two stages fun thought experiment time, if you found a programmable "FUSE"(file system api) database of some sort, mixed `-J` and `-mixin`, I think you may be able to call a compiler
Re: Call an external program from CTFE
On 24/06/2024 4:33 AM, realhet wrote: Hi, Is there a way to call an external program from CTFE? No. This is on purpose due to "security" and reproducibility concerns. The nearest thing I've found is the "include file contents" 'macro', that can be enabled with a command line parameter. (Maybe it's already deprecated, I'm not sure.) See above why the string imports was designed that way.
Call an external program from CTFE
Hi, Is there a way to call an external program from CTFE? Use case: Inside a module I want to put some GLSL code. I also want to generate that GLSL code using CTFE. And when it's done, it would be nice if I was able to save that GLSL code into a temp file and call the glsl compiler on it. The goal is that the compiled version of the module would contain also the compiled version of that GLSL shader. And the time of the GLSL compilation could be the exact same time of the EXE compilation. This sounds a bit of hacking, but from viewing from a multi-target build perspective, it can make sense. Calling a compiler from another compiler... Why not? :D The nearest thing I've found is the "include file contents" 'macro', that can be enabled with a command line parameter. (Maybe it's already deprecated, I'm not sure.) My other way to do this would be an automation inside my IDE. But if something could be done on the language level it's always better than doing it by using external tools.
Re: importC Error: undefined identifier `__atomic_thread_fence`
On Friday, June 21, 2024 12:39:44 PM MDT mw via Digitalmars-d-learn wrote: > Looks like `__atomic_thread_fence` is a GCC built-in function, so > how to make importC recognize it? dmd cannot handle it. gcc or ldc might, but dmd generally needs standard C code. Stuff like gcc built-ins basically has to be removed from the file (either literally or via a #define). Unfortunately, since I haven't really done anything with importC, I can't give good info on how to do that properly (outside of simply removing it from the file). Looking over https://dlang.org/spec/importc.html this section might be useful: https://dlang.org/spec/importc.html#_builtins So, you can probably edit that file to make it work, though what you should probably do is open a bug report for it - https://issues.dlang.org/ - and if the correct solution is indeed to edit that file, then that will hopefully lead to the file being updated (and if you're feeling particularly motivated, you can always open a pull request - https://github.com/dlang/dmd/). - Jonathan M Davis
