CalderaD - SDL2 Vulkan renderer for windows, linux, and android
Dear all, I'm proud to announce CalderaD, yet another SDL2 Vulkan renderer in the D Programming Language. However, this one will work on Windows, Linux, and even Android. The current 'engine' is based on the excellent vulkan-tutorial.com, and uses SDL2 via the bindbc-sdl bindings for cross-platform support. Vulkan support is provided by using the ErupteD binding for Vulkan. Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD The name CalderaD, comes from the word caldera a large cauldron-like hollow that forms shortly after a volcanic eruption. The term comes from Spanish caldera, and Latin caldaria, meaning "cooking pot". I hope this project can help others cook up some nice android apps, and will show that a language like D has something to offer on the mobile platform. Danny
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD You can set up platform filters in dub to automatically match target platforms without specifying configuration for build. See this https://github.com/Superbelko/android-sdl-d/blob/master/dub.json P.S. No idea why you choose GPL, I usually don't bother with GPL libraries because of license, and I think this is also the majority of people on this forum.
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 17:29:13 UTC, evilrat wrote: On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD You can set up platform filters in dub to automatically match target platforms without specifying configuration for build. See this https://github.com/Superbelko/android-sdl-d/blob/master/dub.json P.S. No idea why you choose GPL, I usually don't bother with GPL libraries because of license, and I think this is also the majority of people on this forum. Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? I think: "license": "proprietary" also doesn't sound very inviting Any suggestions license-wise ? Thanks for the configuration tip
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? GPL is a perfectly fine license. If people don't want to use it because of that, their loss, not your problem.
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? I think: "license": "proprietary" also doesn't sound very inviting It's a WIP tutorial project. It is not finished yet. It needs more details where needed and have everything re-checked. Any suggestions license-wise ? zlib, Boost, BSD/MIT, anything will do, its just the GPL itself. I don't think it is allowed to copy-paste any part of it at all. Licensing is pain and I usually avoid it, so please refer to special web sites that will help pick the license that suit your intentions. Or at least make it LGPL so it is possible to be used as a library without licensing headache.
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: On Friday, 14 May 2021 at 17:29:13 UTC, evilrat wrote: On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD You can set up platform filters in dub to automatically match target platforms without specifying configuration for build. See this https://github.com/Superbelko/android-sdl-d/blob/master/dub.json P.S. No idea why you choose GPL, I usually don't bother with GPL libraries because of license, and I think this is also the majority of people on this forum. Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? I think: "license": "proprietary" also doesn't sound very inviting Any suggestions license-wise ? Thanks for the configuration tip To complete the subject, A GPL licence imply that any software that use your library have to be a GPL like licence. Usually for a library we use a LGPL licence. That is a non viral licence bases on GPL. Below a list if compatible licence : https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Dear all, I'm proud to announce CalderaD, yet another SDL2 Vulkan renderer in the D Programming Language. However, this one will work on Windows, Linux, and even Android. The current 'engine' is based on the excellent vulkan-tutorial.com, and uses SDL2 via the bindbc-sdl bindings for cross-platform support. Vulkan support is provided by using the ErupteD binding for Vulkan. [...] Nice! Is it on dub as well?
Til, a command language written in D
Hey, folks, how you doing? 2 months ago I started playing with a small personal project: creating a simple programming language / interpreter, both for fun and for learning more about... you know... creating a programming language / interpreter. :-) Now, *I'm not exactly a Walter Bright*, so I decided to start with a **dynamic, Tcl-like language: command-based and without much "syntax"**. I tried to avoid the "*everything is a string*" concept and even played for some time with "*everything is a list*" (almost like Lisp, but with fewer parentheses) and even "*everything is a forward range*" - the results, then, were **horrible**, but, anyways... I've learned interesting lessons (specially: how important, powerful and versatile a simple STACK is). [Til](https://github.com/til-lang/) is now mature enough, IMHO, to the point I'm spending more time writing documentation and "spreading the word" than coding that much. I published two packages on Dub (the language itself and a module) and created a [Github-Pages-Website](https://til-lang.github.io/til/), already. I'm not pretentious in any form (I know it's just "*yet another language*"), but I'm actually very happy with the results: I can write programs in a interpreted language (I appreciate the power and development speed it gives me) and can extend it with another very nice (and powerful) language - D. (Most other languages still follow the formula "extend it with C" and, although I consider myself a "C friendly" guy, that usually doesn't appeal that much to me..) Anyway: the last thing I was working was **loading dynamic libraries as "modules"** and I stumbled across the potential problem of having two different GCs running independently. This article, https://dlang.org/articles/dll-linux.html , talks about linking the results (both the interpreter and the shared library) with `libphobos2.so` -- but it's nowhere to be found on my (Void) Linux system (and neither on FreeBSD). So I have some questions: 1- Should I compile a `libphobos2.so` "by hand"? Should I use `libphobos2-ldc-shared.so`??? 2- Is the GC really going to run on my shared library after loading it? (I think that's maybe a "silly question", but also believe it's worth clarifying the matter.) I appreciate any help. (Furthermore, I'd like to thank to all people helping to make D a language (and ecosystem and community) even more amazing each day. :-) (FurtherEvenMore: I'm new to the forum, so I hope I choose the right place to post this message...)
Re: Til, a command language written in D
On Friday, 14 May 2021 at 22:10:38 UTC, Cléber Zavadniak wrote: Hey, folks, how you doing? Good. Hope you are doing good too. [Til](https://github.com/til-lang/) is now mature enough, IMHO, to the point I'm spending more time writing documentation and "spreading the word" than coding that much. I published two packages on Dub (the language itself and a module) and created a [Github-Pages-Website](https://til-lang.github.io/til/), already. Nice. Pretty clean syntax, and the implementation. I am not a fan of Tcl, but the Erlang influences are definitively cool. I like sub processes and the piping. Do you have some example of running external processes / commands. with `Til`? Composing pipes between external processes, and also between internal ones (maybe by some adapter that splits pipe data by lines?). A good alternative to bash is always welcome ;D
Re: Til, a command language written in D
On Friday, 14 May 2021 at 22:18:50 UTC, Witold Baryluk wrote:
Nice. Pretty clean syntax, and the implementation.
Thanks! I'm relatively new to D itself, I'll confess. Suggestions
of improvements to the code are welcomed.
I am not a fan of Tcl, but the Erlang influences are
definitively cool.
I myself find Tcl awesome. But it has a lot of flaws, too. I'm
kind of trying to fix some of its issues, as well (the first
versions of Til were labeled "a better Tcl").
(Also: a Tcl-based has the advantage that I can use its syntax
highlighting satisfactorily on most of the cases.)
I like sub processes and the piping.
Do you have some example of running external processes /
commands.
with `Til`? Composing pipes between external processes, and
also between internal ones (maybe by some adapter that splits
pipe data by lines?).
The module I published on Dub is
[til_exec](https://code.dlang.org/packages/til_exec) and it runs
commands and returns status and output, for now.
(I'm trying to avoid the "giant standard library included" path,
so I prefer to release modules separately.)
There's a lot of things lacking right now, for sure: you can
`exec` commands but there's no way, yet (future readers: please
pay attention to the timestamp of this post. Thanks), of breaking
the command output in multiple lines.
(An example I can think would be the following, but
`string.split` is the lacking part, currently:)
```tcl
exec ls / | string.split "\n" | foreach line {
io.out $line
}
```
Interestingly, Til *pipes* were not born actually focused on
handling external commands I/O, unix-shell-style, despite the
obvious similarity. The first pipes implementation was an attempt
to avoid Tcl sometimes-weird nested-commands syntax (used a lot
for indexing) for instance, like `set parts [file split [file
rootname $file_path]]`. But it evolved to be a way of handling
**data** in general, while function parameters were supposed to
define mostly **behavior**.
A good alternative to bash is always welcome ;D
Yeah... I don't know... Not following this goal right now. `bash`
is still out there for some very good reasons, as far as I can
see. Some things are just expected in a shell, like expanding
`*`, and usually general-purpose programming languages just feel
weird handling "shell things".
(But... who knows?...)
