Re: DLP - D Language Processing 0.1.0
On 2019-03-20 14:12, Stefan Koch wrote: Functions without bodies cannot be considered leaf functions as there are declarations which may call. I thought about adding a flag to control if functions without a body should be considered a leaf function or not. This tool is mostly intended for providing a good starting point to where to add attributes. I think this is still true for functions without a body. -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-03-31 13:39, Mihails wrote: Contrary to `install.sh` and DVM approach, DC changes active compiler globally instead of a current shell context only. FYI, DVM allows to set the globally active compiler as well, using "dvm use -d". This is known as the default compiler. These days I don't use the "use" command that often because the compiler is more stable, less reason to pin a project to a given compiler version. Also most of my projects work with the latest version of the compiler. This done intentionally to simplify integration with IDEs and other non-CLI tools - though temporary shell-only switching is also planned once I come with a decent design. DVM has two wrappers that helps with editor and IDE integration in the form of "dvm-current-dc", which always points to the currently active compiler (which actually more is the latest chosen compiler) and "dvm-default-dc" which always points to the default, or global, compiler. Both of these live in "~/.dvm/bin" (on Posix). You can point your editor or IDE to the full path of one of these two wrappers. DVM also provides wrappers for each compiler version in the form of "dmd-" also located in "~/.dvm/bin", if you want to explicitly invoke a given version without switching the active version. -- /Jacob Carlborg
DVM - D Version Manager 0.5.0
I would like to announce a new release of DVM, 0.5.0. This release contains two important bug fixes: making the Dub binary executable and downloading the latest compiler, i.e. the `-l` flag now works again. The release and binaries are available here [1]. I might upload a FreeBSD binary later, if I get that to work. For those not familiar with DVM: DVM allows you to easily download and install D compilers and manage different versions of the compilers. Full changelog: New/Changed Features: * Add a flag to print the version of DVM, `--version` Bugs Fixed: * Fixed installing the latest compiler, that is using the `-l` flag * Issue 44: Make dub executable * Issue 42: Doesn't compile with recent compilers (e.g. dmd-2.074.1) [1] https://github.com/jacob-carlborg/dvm/releases/tag/v0.5.0 -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-03-31 13:39, Mihails wrote: Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction. It is a small utility originally created to fulfill similar purpose to existing `install.sh` script but also with Windows support. It's kind of funny that you decided to release this exactly the same day as I planned to release a new version of DVM [1] :) [1] https://forum.dlang.org/post/q7r3i5$2cdh$1...@digitalmars.com -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-03-31 13:39, Mihails wrote: Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction. As for the destruction: * Saying it's cross-platform and only supporting two platforms is stretching it a bit. * Using the "tar" [1] command line tool is cheating :). It might not be available inside a Docker container, for example. * Regarding `currentProcessBinary` [2]. Phobos has a function for that, which is cross-platform [3]. [1] https://github.com/mihails-strasuns/dc/blob/f314916b04879604e3f8629534a3cf2b1bd4d92c/source/dc/platform/posix.d#L78-L81 [2] https://github.com/mihails-strasuns/dc/blob/f314916b04879604e3f8629534a3cf2b1bd4d92c/source/dc/utils/path.d#L46 [3] https://dlang.org/phobos/std_file.html#.thisExePath -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-04-01 12:31, Mihails wrote: Nice, I must admit I have had my mind set about DVM as something that has existed for years and wasn't quite the right thing. Had no idea you kept improving it lately. Yeah, I thought it was time to fix one or two bugs. -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-04-02 13:49, Bastiaan Veelo wrote: So thank you. You're welcome :) -- /Jacob Carlborg
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On 2019-04-12 08:45, DanielG wrote: These aren't written in D, but they are *for* D (or any other non-C++ language in need of its own canonical, language-native GUI). They export a C API for maximum ease of use. May I ask why? -- /Jacob Carlborg
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On 2019-04-12 11:47, DanielG wrote: - OpenWL/DL aren't designed for games or insane frame rates. I *do* think a smooth, 60fps experience is worth shooting for, but because it's CPU-bound with Quartz2D on Mac, and Cairo on Linux, that will depend entirely on the user's resolution / CPU. (But Direct2D is GPU-accelerated and already crazy fast) "Whenever possible, Quartz 2D leverages the power of the graphics hardware." [1]. [1] https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html -- /Jacob Carlborg
Re: Two New Manpower Initiatives
On 2019-04-15 12:08, Mike Parker wrote: I've just published a post on the blog introducing two new initiatives, the Manpower Share and the Manpower Fund, that came out of our quarterly D Language Foundation meetings. The goal is to help focus energy on getting more effort directed at the issues that fall by the wayside. The blog post has all the details, so I encourage everyone who cares about improving D and its ecosystem to give it a read. Looking at the Ecosystem Task List, I had expected something more specific than just "close as many bugs as possible" for various projects. -- /Jacob Carlborg
Re: Beta 2.086.0
On 2019-04-20 16:16, Martin Nowak wrote: Glad to announce the first beta for the 2.086.0 release, ♥ to the 52 contributors. I just noticed I got a test failure [1] in one of my projects using this version. I haven't investigated yet. Strangely the nightly build passes. [1] https://travis-ci.org/jacob-carlborg/dstep/jobs/522548540 -- /Jacob Carlborg
DStep 1.0.0
I would like to announce a new major release of DStep, 1.0.0. This release is the biggest release since the initial release. It has support for translating some of the preprocessor, like `#define` for contestants and function-like macros. It now supports preserving comments and support for one more platform has been added: Windows. Many more features have been added and bugs have been fixed, too many to mention here. For those not familiar, DStep is a tool for automatically generating D bindings for C and Objective-C libraries. This is implemented by processing C or Objective-C header files and output D modules. DStep uses the Clang compiler as a library (libclang) to process the header files. This release would not have been possible without Wojciech Szęszoł, the Google Summer of Code student that started to work on DStep during the summer of 2016 and still is contributing. For the full changelog (this has been built up for over three years, so I'm sure things are missing), see the release page [1]. Binaries are available for macOS, Linux and Windows [1]. The Linux binary is completely statically linked and should work on any distro. The macOS binary is statically linked with libclang and doesn't have any additional dependencies besides the system libraries. The Windwos binaries require to install libclang. [1] https://github.com/jacob-carlborg/dstep/releases/tag/v1.0.0 -- /Jacob Carlborg
Re: DStep 1.0.0
On 2019-04-22 15:20, Dennis wrote: Huh, I've been using DStep on Windows back in January. I can't remember how I obtained the binary, but it's version 0.2.3-67-gdeabc63. The Windows support was implemented during GSoC 2016. It just has never been a new release since then. I have created a few tags, for various reasons, since then, but no official release. It worked partially, but could not translate C function pointers to D's `function()` syntax, leaving a 'TODO' stub instead. Has that changed? I can't find anything about it in the release notes. Translating function pointers has probably been supported since the first release. There are tests for this. If there's something that is not working, please file a bug at [1]. Ideally with a minimal test case with the C code and the expected D code. [1] https://github.com/jacob-carlborg/dstep/issues -- /Jacob Carlborg
Re: Beta 2.086.0
On 2019-04-21 19:59, Jacob Carlborg wrote: On 2019-04-20 16:16, Martin Nowak wrote: Glad to announce the first beta for the 2.086.0 release, ♥ to the 52 contributors. I just noticed I got a test failure [1] in one of my projects using this version. I haven't investigated yet. Strangely the nightly build passes. [1] https://travis-ci.org/jacob-carlborg/dstep/jobs/522548540 Managed to find a reduced test case: https://github.com/dlang/dub/issues/1681. -- /Jacob Carlborg
Re: DStep 1.0.0 on the Blog
On 2019-04-23 14:10, Mike Franklin wrote: Nice work, Jacob! Very cool! Thanks :) -- /Jacob Carlborg
Re: DStep 1.0.0
On 2019-04-26 10:33, Robert M. Münch wrote: Are there are any functional differences between the platforms? The short answer is yes. Or can I just use the OSX version and use the generated .d files with the DMD Windows version too? The longer answer is that it depends. DStep behaves the same way as the compiler (Clang in this case). That means that there are different predefined macro constants for different platforms. For example: #if _WIN32 #include DWORD foo(); #else int foo(); #endif If you run DStep on Windows it will output: extern (C): DWORD foo(); But on any other platform it will output: extern (C): int foo(); So it's a question if the header files contain any code like the above. The bindings that DStep uses for libclang are generated on macOS but are used unchanged on Windows and Linux as well. But these are the most forgiven headers that I've seen when it comes to create bindings. -- /Jacob Carlborg
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On 2019-05-05 05:45, Mike Franklin wrote: The idea behind the library is that it would not depend on druntime, phobos, C standard library, or anything else but would still offer many of the features that those libraries provide. To utilize the library, one would only need a D compiler. It could be used in bare-metal programming, -betterC builds, or as a fundamental utility library for implementing DMD, druntime, and phobos themselves. Might be interesting to write a tool that enforces the rules. It would use DMD as a library. -- /Jacob Carlborg
Re: Intellij: Support for TextMate Bundled
On 2019-08-01 17:19, Andre Pany wrote: There is an answer from Intellij why there are highlighting issues: https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FIDEA-219012 That's disappointing. Named captures are very useful and makes the grammar easier to read and understand. TextMate uses this regular expression implementation [1]. [1] https://github.com/textmate/Onigmo -- /Jacob Carlborg
Mecca available on macOS
I would like to announce that I've ported Mecca [1] to macOS. It was merged in May but I never bothered to announce it until now. Everything except the file watcher has been ported and is working. Unfortunately the unit tests fail in Travis CI, but they pass locally and in Circle CI. Something related to a timer that is failing. When it comes to the implementation, it's structured so that the new code will work on any Darwin platform (it's only tested on macOS). In this process I also moved some platform specific code for Linux to the `mecca.platform` and `mecca.reactor.platform` packages. This means that all platform specific code lives in these two packages and there are no version blocks outside of these packages (as far as I could find). The version blocks that exist are very few, due the the platform specific code lives in their own files. They're just needed to import the correct platform specific file. I think this turned out really nice compared to the mess that's in druntime, where most files are littered with version blocks. The Darwin implementation uses kqueue, which is available on other platforms as well, like the various BSD flavors. The kqueue specific code is guarded with its own version block to make it possible to reuse on other platforms, if someone wants to port Mecca to a new platform. Some timer related code is implemented using libdispatch on Darwin, but I think this could be implemented using kqueue as well. I think libdispatch is available on *BSD as well, but might not be installed by default. [1] https://github.com/weka-io/mecca -- /Jacob Carlborg
Re: Mecca available on macOS
On 2019-08-07 19:45, Ron Tarrant wrote: I'm not familiar with Mecca. What is a Container/reactor library? I guess it's a reactor library. I see it as a library providing fiber based non-blocking IO. It also provides containers, logging, reflection, serialization and a bunch of other things that are usually found in a standard library. -- /Jacob Carlborg
Re: Five Projects Selected for SAOC 2019
On 2019-08-26 05:55, Andrej Mitrovic wrote: I'm guessing this means we might even be able to use multiple versions of Phobos one day. However before we do that, we will really need to fix the use of globals in Phobos. I don't think that's necessary. All symbols will have the version be part of the mangled name. -- /Jacob Carlborg
Re: Release D 2.088.0
On Tuesday, 3 September 2019 at 10:02:26 UTC, a11e99z wrote: On Tuesday, 3 September 2019 at 07:57:00 UTC, Martin Nowak wrote: This release comes with a new C:\programz\D>dmd --version DMD32 D Compiler v2.088.0-dirty what is ..-dirty? It means the git repository was not clean when the compiler was built. — /Jacob Carlborg
Re: Build your dub packages with Github Actions
On 2019-09-07 00:02, Andre Pany wrote: Hi, Just a small info, building your D application using Github Actions just works out of the box thanks to the install.sh script! This configuration will install a "dub build" pull request voter: https://github.com/andre2007/coding-puzzles/blob/master/.github/workflows/blank.yml Oh, cool. I didn't know about GitHub actions. Of course, there's no D template among the other languages [1] :( [1] https://github.com/actions/starter-workflows/tree/master/ci -- /Jacob Carlborg
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster wrote: https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1 FYI, string is a built-in type. Regarding exercise 2. I would be very careful with deserializing a single character from JSON. First, because JSON doesn't support single characters. Second, you'll run into issues with Unicode. For example, you would need to know the exact JSON content, not just the type, to specify the type that should be deserialized. Example: assert(json.deserialise!char() == '😀'); The above will not work, because the type of '😀' is not `char`, it's `dchar`. The deserialization would need to throw an exception in this case, because '😀' won't fit in a `char`. It's much simpler to just not allow this use case. -- /Jacob Carlborg
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Friday, 1 November 2019 at 11:29:11 UTC, Ethan wrote: string is immutable(char)[], as we all know. Syntactic sugar, not exactly a built in type but treating it like one is often valuable. It's an alias, but what it's aliased to is a built-in type. -- /Jacob Carlborg
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 11:49:20 UTC, Daniel Kozak wrote: Generally no, because Apline use musl libc instead of glibc, so there are some issues with that The correct way is to use static linking and putting only the binary in a Docker image, i.e. "from scratch" [1] ;). But using Alpine and musl will help with building the binary. [1] https://hub.docker.com/_/scratch
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On 2019-11-06 02:02, sarn wrote: And the neat way to do that is with a multi-stage build: one Dockerfile, with an Alpine container building the binary, then copying to a FROM scratch container I've used the "smith" tool as well [1]. It has some additonal help with dynamically linked code. It will use "ldd", recursively, to track dependencies and automatically add those. It will also do a couple of other things, like making the filesystem read only. The musl build is practically necessary because glibc has effectively given up standalone static binary support. So, thanks BPF Korea :) Yeah, it helps. Although it still possible to statically link with glibc, although you might get some warnings. [1] https://github.com/oracle/smith -- /Jacob Carlborg
Re: Release D 2.089.0
On Thursday, 7 November 2019 at 10:25:46 UTC, Ron Tarrant wrote: I follow the steps outlined here: https://github.com/gtkd-developers/GtkD/wiki/Installing-on-Windows And one of those steps (Step #5) says to copy the gtkd libs to the compiler's directory tree. Is that what you mean by "You really shouldn't be doing the former."? And I also edit sc.ini. I recommend that you use Dub instead and add gtk-d [1] as a dependency. [1] https://code.dlang.org/packages/gtk-d -- /Jacob Carlborg
Re: dud: A dub replacement
On 2019-11-11 14:44, Robert Schadek wrote: So dub has some problems, and personally I find its code base very hard to get into. At Symmetry we are a very heavy user of dub, resulting in many wasted hours. So I started to write dud [1]. I kept some boring/nice parts from dub, but most code so far is a complete rewrite. Hmm, that's unfortunate. It happens way too often in the D community, that a project is rewritten from scratch instead of improving the existing one. Especially since the D community is not that big. Although I can understand the choice. Even if you were to contribute there would be no one to merge the pull requests :(. -- /Jacob Carlborg
Re: dud: A dub replacement
On Sunday, 17 November 2019 at 19:10:05 UTC, Sebastiaan Koppe wrote: SDL all the way please. Perhaps this ship has already sail. But YAML would have been a better choice. It's a superset of JSON. All the existing JSON description files would have worked as is. -- /Jacob Carlborg
Re: dud: A dub replacement
On Wednesday, 20 November 2019 at 11:40:19 UTC, Robert Schadek wrote: Here is disagree, to a degree I consider comments a code smell. If I have to write them, I failed to convey the information needed to understand the code in the code. You think this is a code smell: https://dlang.org/phobos/std_array.html ? -- /Jacob Carlborg
Re: Proposal for porting D runtime to WebAssembly
On 2019-11-23 10:51, Sebastiaan Koppe wrote: This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d What will happen to code that uses TLS? Will it be promoted to a global variable or will it fail to compile? -- /Jacob Carlborg
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Tuesday, 12 November 2019 at 09:15:28 UTC, SealabJaster wrote: And if you do allow things such as letting classes have a 'deserialise' member function which can be overloaded, you still need to create or be given an instance of the class beforehand, which brings things back around to the "constructor issue" in the latest post. I don't quite know if there's actually an automatic solution for classes that covers most cases? Anything I can think of places limitations in some form or another. They way I handled this in Orange [1] which allows to (de)serialize third party types which you don't have any control of. First, structs have the same problem as classes: there can be private members. They way this is handled is to use `.tupleof`. `.tupleof` will bypass the protection and allows to read and write private fields: module foo; class Foo { private int a; int getA() { return a; } } module main; import std.stdio; import foo; void main() { auto foo = new Foo; foo.tupleof[0] = 3; assert(foo.getA == 3); assert(foo.tupleof[0] == 3); } `.tupleof` is used both for serialization and deserialization. To create an instance of a class use the same way as the runtime does. This function [2] is called by the compiler when the code contains "new Object" (extracted to Orange here [3]). This will not call a constructor, but that's fine since we will set the fields anyway directly after. Orange also offers a way to tweak the (de)serialization process with hooks. You can define methods in your structs or classes with any of the following UDAs: `onSerializing`, `onSerialized`, `onDeserializing` and `onDeserialized`. These method will be called (if they exist) before/after the (de)serialization process [4]. This allows you do preform some post-processing that might be needed since no constructor has been called on deserialization. When it comes to (de)serializing derived types through a base class reference Orange requires you do register all derived types [5]. Then there's the problem with non-mutable fields and instances as well. But you can just cast away those when deserializing. There's also the issue with circular references [6]. But that's pretty easy to solve by storing all serialized instances to see if they have already been serialized or not. [1] http://github.com/jacob-carlborg/orange [2] https://github.com/dlang/druntime/blob/873fac33014c5af680c4bed69bb74cb0f192198a/src/rt/lifetime.d#L73 [3] https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/util/Reflection.d#L149-L183 [4] https://github.com/jacob-carlborg/orange/blob/master/tests/Events.d [5] https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/serialization/Serializer.d#L241-L262 [6] https://github.com/jacob-carlborg/orange/blob/master/tests/CircularReference.d -- /Jacob Carlborg
Re: LDC 1.20.0
On 2020-02-15 07:17, zoujiaqing wrote: Thanks LDC team! Thanks Jacob for iOS/tvOS/watchOS on AArch64! Thanks :) -- /Jacob Carlborg
Re: DIP 1027---String Interpolation---Format Assessment
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright wrote: I don't know Swift, but this looks like the "generate strings and concatenate them" approach. No, it basically lowers to bunch of method calls. Here's an example of how it could look like with D syntax: auto a = 3; auto b = i"foo $a bar"; Could be lowered to: auto _temp = StringInterpolation(8 /* literal capacity */, 1 /* interpolation count */); _temp.appendLiteral("foo "); _temp.appendInterpolation(a); _temp.appendLiteral(" bar"); auto b = _temp.toString(); There's nothing here that says that this needs to use the GC to allocate the final string. "StringInterpolation" could contain something like OutBuffer from DMD or, if the arguments were passed as template arguments, it could allocate on the stack. -- /Jacob Carlborg
Re: Blog Post #0105: D-specific Stuff for GUI Programming
On Monday, 23 March 2020 at 10:02:48 UTC, Ron Tarrant wrote: Today starts a new series I'm calling Snippets and it's about various D-specific stuff that may come in handy when building a GUI. You can find it right here: https://gtkdcoding.com/2020/03/23/0105-dlang-ui-snippets-i.html If it's enough with CTFE compatible code in the constructor, the following is a much simpler version: class DSingleton { private __gshared DSingleton instance = new DSingleton; DSingleton get() { return instance; } } -- /Jacob Carlborg
Re: Blog Post #0105: D-specific Stuff for GUI Programming
On Monday, 23 March 2020 at 10:26:33 UTC, Jacob Carlborg wrote: If it's enough with CTFE compatible code in the constructor, the following is a much simpler version: class DSingleton { private __gshared DSingleton instance = new DSingleton; DSingleton get() { return instance; } } Or if an immutable instance work, the getter is not necessary and the instance can be exposed directly. class DSingleton { immutable DSingleton instance = new DSingleton; } -- /Jacob Carlborg
Re: Blog Post #0105: D-specific Stuff for GUI Programming
On Monday, 23 March 2020 at 10:41:43 UTC, Jacob Carlborg wrote: class DSingleton { immutable DSingleton instance = new DSingleton; } Should of course be `static`: class DSingleton { static immutable DSingleton instance = new DSingleton; } -- /Jacob Carlborg
Re: Hunt Framework 3.0.0 Released, Web Framework for DLang!
On 2020-05-09 09:02, zoujiaqing wrote: ( hunt library is currently the best performing network io in D languages.) Would be interesting to see how Hunt and Mecca [1] compare. Mecca is quite a basic library, compared to Hunt. It doesn't support anything more high level than TCP sockets. http://github.com/weka-io/mecca -- /Jacob Carlborg
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Sunday, 5 July 2020 at 14:29:22 UTC, IGotD- wrote: It's a resource question again. I'm all for that for example D should have a native alternative to curl including SSL/TLS support. If someone is willing to invest the man hours into such project, I'm all for it. Nim went that way having partial native http support so it isn't impossible. I agree, that would be really nice. Unfortunately it's quite tricky if you want to integrate with the platform provided TLS implementation [1]. Unless you're suggesting to create a crypto library from scratch, which is a whole different beast, and probably a bad idea [2]. [1] https://forum.dlang.org/post/prsrbzoanxwytrtpy...@forum.dlang.org [2] https://forum.dlang.org/post/hsmjcgxzujgwsiegi...@forum.dlang.org -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov [ZombineDev] wrote: What I really wish is we had a single shared codebase for dlang editor support, that could be shared among editor extension writers, instead of having many community members working on competing solutions. That would be really nice. Doesn't Visual Studio (not VSCode) supports LSP these days? -- /Jacob Carlborg
Re: Documentation repository for Hunt Framework !
On Tuesday, 30 June 2020 at 15:40:14 UTC, zoujiaqing wrote: I'm glad we've released the first set of Hunt Framework today. Make it easier for you to use Hunt Framework. Hope more people can work with us to improve the content of the document. https://github.com/huntlabs/hunt-framework-docs Really nice to see some documentation. I would love to see some documentation on the internals, especially related to the event loop, concurrency and similar. -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 05:07:38 UTC, Petar Kirov [ZombineDev] wrote: So, having had to edit both VS *.*proj files and Makefiles manually, I'd say that Makefiles are orders of magnitude more approachable and easier for me. MSBuild is just a giant PITA in my experience. Though I agree that I don't find Makefiles enjoyable either :D, but at least I can more easily track changes to them in VCS. FYI, Visual Studio has native support for CMake projects these days. -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 06:46:53 UTC, Rainer Schuetze wrote: There is an extension using DLS as an LSP: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang It's been some time, but when I tried to use that along side Visual D, it caused problems because both are trying to be a language service for the same language. I was more hoping for the engine in VisualD to be the new DCD or DLS, since it's already using the DMD frontend for some things. Then it can be used by other editors and IDEs, hint hint, wink wink ;) -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 00:39:49 UTC, Manu wrote: Even DMD itself is too large a D project for Code-D to work well with. I have not used Code-D, but I am using TextMate with DCD integrated. It has no problem with the DMD project. But it only supports go-to-definition, autocomplete and showing documentation for symbols. When opening a project which contains a dub.sdl/dub.json file, the editor reads the import paths. Then it opens a new instance of DCD (one per project) and passes the imports paths to it. Code-D often can't even go to the definition of D functions in D code reliably ;) Yeah, VisualD has a huge advantage since it's now using the DMD frontend for these things. For example, DCD does not support UFCS, which is really annoying. -- /Jacob Carlborg
Re: Documentation repository for Hunt Framework !
On Thursday, 9 July 2020 at 16:37:16 UTC, zoujiaqing wrote: I want to improve the documentation for the application layer first. Let more people use the framework quickly. Later, we will improve the underlying documents when the underlying library API is stable. Fair enough. -- /Jacob Carlborg
Re: Release D 2.093.0
On 2020-07-12 11:04, Martin Nowak wrote: Glad to announce D 2.093.0, ♥ to the 54 contributors. I just tried to use this release in a GitHub Action using the "dlang-community/setup-dlang@v1" action. I got an error about the signature is not trusted. I tried 2.092.0, that works fine. Here's the full output: Downloading http://downloads.dlang.org/releases/2.x/2.093.0/dmd.2.093.0.osx.tar.xz 7 Verifying the download with GPG 8 gpg: Signature made Tue Jul 7 13:27:08 2020 UTC 9 gpg:using RSA key 3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8 10 gpg: directory '/Users/runner/.gnupg' created 11 gpg: /Users/runner/.gnupg/trustdb.gpg: trustdb created 12 gpg: Good signature from "Martin Nowak " [unknown] 13 gpg: aka "Martin Nowak " [unknown] 14 gpg: aka "Martin Nowak " [unknown] 15 gpg: WARNING: This key is not certified with a trusted signature! 16 gpg: There is no indication that the signature belongs to the owner. 17 Primary key fingerprint: F46A 10D0 AB44 C3D1 5DD6 5797 BCDD 73FF C3EB 6146 18 Subkey fingerprint: 3AAF 1A18 E61F 6FAA 3B71 93E4 DB8C 5218 B932 9CF8 -- /Jacob Carlborg
Re: Visual D 1.0.1 released
On Tuesday, 25 August 2020 at 20:37:38 UTC, Per Nordlöw wrote: I'm dying to get a semantic engine that supports code navigation to (and completion of) overloaded functions at their call site including UFCS-calls. DCD doesn't support these two features. I have interest in a LSP server based on the DMD frontend as well. There's also a SAoC 2020 project related to DMD as a library [1]. Was there another master thesis (or similar) that would work on a LSP server as well? Either sponsored by Symmetry or related to the University of Bucharest. We should try to work together instead of duplicating the work. Although I've given up on the DMD upstream project and instead, I've forked it [2] to be able to do the necessary changes. [1] https://dlang.org/blog/2020/08/23/symmetry-autumn-of-code-2020-projects-and-participants [2] https://github.com/jacob-carlborg/ddc -- /Jacob Carlborg
Re: Symmetry Investments and the D Language Foundation are Hiring
On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote: Looking for a full-time or part-time gig? Not only is Symmetry Investments hiring D programmers, they are also generously funding two positions for ecosystem work under the D Language Foundation. And they've put up a bounty for a new DUB feature. Read all about it here: https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ As an alternative to use SHA-1 hashing. There's the option to have a daemon running the background listing on filesystem events. BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? -- /Jacob Carlborg
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Thursday, 3 September 2020 at 08:40:32 UTC, aberba wrote: The slack I have no ideas how people get in. I know there's a number of members in there too. Unfortunately you need to be invited. Anyone can do it, if you're interested. We just need an email address. -- /Jacob Carlborg
Re: Beta 2.094.0
On 2020-09-16 19:20, mw wrote: Why it's deprecated? can we revive it? It was deprecated because it's a bad idea to not lock versions. Using `~master` would fetch the latest code from the "master" branch when compiling. You never know which version you get. You don't get reproducible builds. -- /Jacob Carlborg
Re: Beta 2.094.0
On 2020-09-17 12:10, John Colvin wrote: I personally think it's not so bad as long as the commit gets written to the dub.selections.json It doesn't. -- /Jacob Carlborg
Re: Beta 2.094.0
On 2020-09-18 23:14, John Colvin wrote: I know. But it should be. dub.selections.json wasn't available in the initial version. I don't remember if branches were deprecated before or after dub.selections.json was added. -- /Jacob Carlborg
Re: requests 2.0.0 release
On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: Hi, requests 2.0.0 released with single change - support for vibe-d moved to separate subpackage. The goal of this update is to prevent dub from downloading vibe-d packages for optional subConfiguration. Another approach is to check if vibe.d is available using version conditions [1]. This is how the DDB [2] package supports both vibe.d sockets and Phobos sockets. [1] https://github.com/pszturmaj/ddb/blob/97bc3652b05492e7917888c92e59f4576a69dfa8/source/ddb/postgres.d#L189-L216 [2] https://code.dlang.org/packages/ddb -- /Jacob Carlborg
Re: requests 2.0.0 release
On 2020-11-01 11:13, Sönke Ludwig wrote: ddb marks the vibe-d dependency as optional, so it *should* not trigger a download by itself. It does not trigger a download. The downside is that user of the library needs to manually add vibe.d as a dependency. -- /Jacob Carlborg
Re: Preparing for Google Summer of Code 2021
On Monday, 23 November 2020 at 13:34:14 UTC, Petar Kirov [ZombineDev] wrote: Thanks, I've just added the gsoc2020 label for these issues. I will ping someone to give you permissions for the repo ;) Shouldn't it be gsoc2021? We're already past GSoC 2020 ;) -- /Jacob Carlborg
Re: Httparsed - fast native dlang HTTP 1.x message header parser
On 2020-12-14 22:59, tchaloupka wrote: Hi, I was missing some commonly usable HTTP parser on code.dlang.org and after some research and work I've published httparsed[1]. This is awesome. I wanted to use picohttpparser myself and used the C version. But if you already have created a HTTP parser with the same properties in D, that's even better. -- /Jacob Carlborg
DLP - D Language Processing 0.3.0 - infer attributes
I would like to announce a new release of DLP, 0.3.0. For those not familiar with DLP, it's a tool collecting commands/tasks related to processing the D programming language. It uses the DMD frontend as a library to process D code. The major new feature in this release a new command that has been added: `infer-attributes`. This command will print the inferred attributes of all functions that are normally not inferred by the compiler. These are regular functions and methods. Templates, nested functions and lambdas are inferred by the compiler and will not be included by this command. By default, virtual methods are not inferred. Use the flag `--include-virtual-methods` to enable inferring of virtual methods. The attribute inference is enabled only on the file that is currently being processed. This is to avoid the tool outputting attributes that would not be valid unless other files are modified. For example, your code is calling a third-party function. The third-party function is inferred to be `pure`. Now your function is inferred to be `pure` as well. But if you only change your function to be `pure`, it will fail to compile because the third-party function has not been updated. The intention of this command is to help you in adding attributes to your code. You don't have to figure out exactly which attributes you can add to a function, just have the compiler tell you instead. It's recommend to run DLP in an iterative process. Run it on a file, update the file with the new attributes, run it again and repeat the process until the tool doesn't output any more inferred attributes. The release is available here [1]. Pre-compiled binaries are available for macOS, FreeBSD and Linux 64bit and Windows 32bit and 64bit. For the full change log, see [1]. [1] https://github.com/jacob-carlborg/dlp/releases/tag/v0.3.0 -- /Jacob Carlborg
Re: DLP - D Language Processing 0.3.0 - infer attributes
On 2020-12-19 00:26, Dave P. wrote: Looks very useful. Something strange I noticed though, it seems to be doing the analysis in 32 bits? I had some static assertions go off due to this which halted the program. Wow, I haven't noticed that. That's not indented. I've created an issue [1] and I'll take a look at it. [1] https://github.com/jacob-carlborg/dlp/issues/7 -- /Jacob Carlborg
Re: I'm creating a game purely written in D with the arsd library
On 2021-01-02 22:21, H. S. Teoh wrote: Nope. Reverse-engineering is a thing. There's even tools out there to automate this stuff. Or you can try to prevent reverse engineering. This is both an interesting and fun talk [1]. [1] https://www.youtube.com/watch?v=HlUe0TUHOIc -- /Jacob Carlborg
Re: Printing shortest decimal form of floating point number with Mir
On 2021-01-06 03:30, Walter Bright wrote: The baseline Linux target does not have SSE. Other compilers solve this by having a flag to specify the minimum target CPU. -- /Jacob Carlborg
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On 2021-01-06 10:21, Mike Parker wrote: This is the discussion thread for the first round of Community Review of DIP 1039, "Static Arrays with Inferred Length": https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md There's `staticArray` to solve this issue [1]. [1] https://dlang.org/phobos/std_array.html#.staticArray -- /Jacob Carlborg
Re: Printing shortest decimal form of floating point number with Mir
On 2021-01-06 03:30, Walter Bright wrote: The baseline Linux target does not have SSE. What about this changelog entry: https://dlang.org/changelog/2.087.0.html#xmm-linux-changelog ? -- /Jacob Carlborg
Re: Article: Why I use the D programming language for scripting
On Sunday, 31 January 2021 at 20:36:43 UTC, aberba wrote: It's finally out! https://opensource.com/article/21/1/d-scripting FYI, the code will compile faster if you use `dmd -run` instead of `rdmd`. If you have multiple files that need to be compiled you can use `dmd -i -run`. -- /Jacob Carlborg
Re: Windows Bindings v1.1
On 2021-02-20 15:03, Rumbu wrote: - new attributes (currently ignored): RetVal, NullNullTerminated, NotNullTerminated Regarding the ignored attributes. You could always output these as UDAs. It would not add any semantic meaning, but could serve as documentation. In theory, it would be possible to create a separate tool that will perform some semantic checks on these UDAs. -- /Jacob Carlborg
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On 2021-02-24 17:32, Imperatorn wrote: What happened to utiliD? Broken link to gh I think Mike gave up on D. -- /Jacob Carlborg
Cross-compiler targeting macOS
# Docker LDC Darwin I would like to announce a new project I'm working on: docker-ldc-darwin [1]. The project consists of a Dockerfile for building a Docker image which has all the necessary tools to cross-compile D applications targeting macOS x86-64. ## Features * Uses Apple's ld64 linker so all features that are being used when linking on macOS should work. No reliance on custom linkers that need to be kept up to date with the system linker * Ships with the full macOS SDK (for macOS version 10.15.4) * No reliance on hacks like allowing undefined symbols when linking like Zig and Rust does * Minimal Docker image. Only the exact files that are required to run the compiler and linker are included. Not even a shell is included * The Docker image, all tools and resources are fully reproducible and automated. No manual steps involved of uploading to random cloud storage accounts The following tools are included: * dub * ldc2 * ldmd2 * rdmd * ld64 (linker) * clang (C compiler, used for linking) ## Building ### Prerequisites * [git](https://git-scm.com) * [Docker](https://www.docker.com) ### Building the Docker Image Follow the steps below to build the Docker images by running the commands in the terminal: 1. Clone the git repository: ``` git clone https://github.com/d-cross-compiler/docker-ldc-darwin && cd docker-ldc-darwin ``` 1. Build the Docker image: ``` docker build -t ldc-x86_64-apple-macos . ``` ## Usage By default, the `ldc2` compiler will be invoked. ### Compiling Hello World Compile Hello World: ``` $ uname Darwin $ cat < main.d import std; void main() { writeln("Hello World"); } EOF $ docker run --rm -v "$(pwd):/work" ldc-x86_64-apple-macos main.d $ ./main Hello World ``` For more information and examples, see the readme [1]. [1] https://github.com/d-cross-compiler/docker-ldc-darwin -- /Jacob Carlborg
Re: Cross-compiler targeting macOS
On 2021-04-08 18:36, H. S. Teoh wrote: Thanks for this, it is very helpful. You're welcome. I'm glad that it's useful to someone. I just created a tag [1] (no changes yet), if I would like to make some changes in the future. [1] https://github.com/d-cross-compiler/docker-ldc-darwin/tree/v0.0.1 -- /Jacob Carlborg
Re: Cross-compiler targeting macOS
On 2021-04-10 15:50, kinke wrote: Thanks Jacob, I'm sure this was quite a bit of work, and opening up proprietary SDKs for non-native systems is always welcome. Thumbs up! Thanks. -- /Jacob Carlborg
Re: (Oh My) Gentool 0.3.0 released
On 2021-05-05 13:54, user1234 wrote: Thanks for the explanations. BTW I had the same question for LDC backend being c++, I guess the answer would be similar. If I understand correctly, the Zig compiler is implemented partially in Zig. It use the LLVM C API and some wrappers C around the C++ API where the C API is not sufficient. -- /Jacob Carlborg
Re: (Oh My) Gentool 0.3.0 released
On 2021-05-05 12:01, user1234 wrote: Is it possible to use libclang and more generally LLVM c++ api [directly in D](https://dlang.org/spec/cpp_interface.html) or the Cpp interface is too limited ? Was this an option, have you tried ? Yes, it's possible to use libclang. DStep [1] is using that and it fully written in D. Although DStep cannot create bindings for C++ yet so I cannot guarantee that using only libclang will work for C++ code. [1] https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
[Semi-OT] Cross-Platform GitHub Action
# Cross-Platform GitHub Action I would like to announce the first version of a project I've been working on for a while. It's not anything D specific or implemented in D, but it can be used with D projects. This project provides a GitHub action for running GitHub Action workflows on multiple platforms. This includes platforms that GitHub Actions don't natively support. It currently supports FreeBSD and OpenBSD. https://github.com/cross-platform-actions/action ## Features Some of the features that are supported include: * Multiple operating system with one single action * Multiple versions of each operating system * Allows to use default shell or Bash shell * Low boot overhead * Fast execution Compared to [vmactions/freebsd-vm](https://github.com/vmactions/freebsd-vm), the boot time is around a fifth and the full execution time for the same job is around half of freebsd-vm. ## Usage Here's a sample workflow file which will setup a matrix resulting in two jobs. One which will run on FreeBSD 12.2 and one which runs on OpenBSD 6.8. ```yaml name: CI on: [push] jobs: test: runs-on: macos-10.15 strategy: matrix: os: - name: freebsd version: 12.2 - name: openbsd version: 6.8 steps: - uses: actions/checkout@v2 - name: Test on ${{ matrix.os.name }} uses: cross-platform-actions/action@v0.0.1 env: MY_ENV1: MY_VALUE1 MY_ENV2: MY_VALUE2 with: environment_variables: MY_ENV1 MY_ENV2 operating_system: ${{ matrix.os.name }} version: ${{ matrix.os.version }} shell: bash run: | uname -a echo $SHELL pwd ls -lah whoami env | sort ``` I've been using this action for one of my own projects ([DLP](https://github.com/jacob-carlborg/dlp/runs/2759807903)) for now close to a week and it works fine. It's mostly FreeBSD that has been tested. If you're interested in how the sausage is made, read on. Also see the readmes of the builder repositories: https://github.com/cross-platform-actions/freebsd-builder https://github.com/cross-platform-actions/openbsd-builder ## Under the Hood GitHub Actions currently only support the following platforms: macOS, Linux and Windows. To be able to run other platforms, this GitHub action runs the commands inside a virtual machine (VM). macOS is used as the host platform because it supports nested virtualization. The VMs run on the [xhyve][xhyve] hypervisor, which is built on top of Apple's [Hypervisor][hypervisor_framework] framework. The Hypervisor framework allows to implement hypervisors with support for hardware acceleration without the need for kernel extensions. xhyve is a lightweight hypervisor that boots the guest operating systems quickly and requires no dependencies outside of what's provided by the system. The VM images running inside the hypervisor are built using [Packer][packer]. It's a tool for automatically creating VM images, installing the guest operating system and doing any final provisioning. The GitHub action uses SSH to communicate and execute commands inside the VM. It uses [rsync][rsync] to share files between the guest VM and the host. xhyve does not have any native support for sharing files. To authenticate the SSH connection a unique key pair is used. This pair is generated each time the action is run. The public key is added to the VM image and the private key is stored on the host. Since xhyve does not support file sharing, a secondar hard drive, which is backed by a file, is created. The public key is stored on this hard drive, which is then mounted by the VM. At boot time, the secondary hard drive will be identified and the public key will be copied to the appropriate location. To reduce the time it takes for the GitHub action to start executing the commands specified by the user, it aims to boot the guest operating systems as fast as possible. This is achieved in a couple of ways: * By downloading [resources][resources], like xhyve and a few other tools, instead of installing them through a package manager * No compression is used for the resources that are downloaded. The size is small enough anyway and it's faster to download the uncompressed data than it is to download compressed data and then uncompress it. * It leverages `async`/`await` to perform tasks asynchronously. Like downloading the VM image and other resources at the same time * It performs as much as possible of the setup ahead of time when the VM image is provisioned [xhyve]: https://github.com/machyve/xhyve [hypervisor_framework]: https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/index.html [rsync]: https://en.wikipedia.org/wiki/Rsync [resources]: https://github.com/cross-platform-actions/resources [packer]: htt
Re: [Semi-OT] Cross-Platform GitHub Action
On Tuesday, 8 June 2021 at 19:40:01 UTC, kinke wrote: Thx for sharing! Interesting; I've recently worked on something similar, but on Linux hosts and using a kvm/qemu/libvirt stack for running CI jobs in Windows VMs. Yeah, this is running on macOS instead because the Linux and the Windows runners on GitHub actions don't support nested virtualization. The Hypervisor framework is something similar to KVM. The VM images are actually created using QEMU (on Linux hosts), because Packer doesn't have any support for Xhyve. Packer will create a qcow2 VM image. At run time, the qcow2 image will be converted to the "raw" format, which is the only format that Xhyve supports. qcow2 is used up until runtime because it natively supports compression. I do want to support other operating systems going forward, but unfortunately, it's only FreeBSD and OpenBSD that work in Xhyve. For other operating systems I will have to use QEMU. QEMU does support the Hypervisor framework as an accelerator, but I don't think it will be as fast as Xhyve. When QEMU is supported, it will hopefully be trivial to add support for non-native architectures. I've already built the OpenBSD image for ARM64. -- /Jacob Carlborg
Re: [Semi-OT] Cross-Platform GitHub Action
On Tuesday, 8 June 2021 at 20:39:45 UTC, Steven Schveighoffer wrote: I might have a need for it. When I moved mysql-native to github actions, I could no longer run mysql integration tests on MacOS or Windows, since there is no docker support for a mysql instance on those platforms. I can probably install mysql manually at some point, but I haven't looked into it. At least for MacOS, this sounds like a way I can run a mysql instance that the MacOS host can talk to. I don't think that would work. The VM is only running during one step. When the step is done, the VM is terminated. Also, Docker doesn't support FreeBSD or OpenBSD. I don't plan to add platforms which GitHub Actions natively support. On the other hand, it seems pretty straightforward to install MySQL natively on macOS: ``` brew install mysql brew services start mysql ``` There are also several GitHub Actions that will setup MySQL: https://github.com/marketplace?type=actions&query=mysql -- /Jacob Carlborg
Re: Diva - D Language Interface for Versioned Applications
On Saturday, 10 July 2021 at 12:30:43 UTC, Bastiaan Veelo wrote: Thanks for clarifying the differences. Some other differences: * DVM is cross-platform. Diva seems to only run on Ubuntu. * DVM is implemented in D (with a tiny shell script wrapper). Diva depends on Python * DVM does not use symlinks. When invoking the compiler it's the actual executable that's invoked directly * DVM provides a built-in command to install itself and do any setup -- /Jacob Carlborg
Re: OpenBSD DMD package
On Tuesday, 12 October 2021 at 12:42:09 UTC, Brian wrote: I don't think any of the free ones support OpenBSD yet :) There is SourceHut, which does support OpenBSD CI, but I don't think it is free to use. You can use my GitHub action: https://github.com/marketplace/actions/cross-platform-action. -- /Jacob Carlborg
Re: OpenBSD DMD package
On Thursday, 14 October 2021 at 16:14:17 UTC, Brian wrote: Awesome! I will spend some time soon figuring it out. Here are two real world examples: https://github.com/jacob-carlborg/lime/blob/master/.github/workflows/ci.yml https://github.com/jacob-carlborg/dlp/blob/master/.github/workflows/ci.yml -- /Jacob Carlborg
[Semi-OT] Cross-Platform GitHub Action 0.3.0 - NetBSD
# Cross-Platform GitHub Action 0.3.0 I would like to announce a new release of [Cross-Platform GitHub Action](https://github.com/marketplace/actions/cross-platform-action), [0.3.0](https://github.com/cross-platform-actions/action/releases/tag/v0.3.0). For those not familiar with this project, it provides a GitHub action for running GitHub Action workflows on multiple platforms. This includes platforms that GitHub Actions don't natively support (for more information see the original announcement of the project [1]). The major new feature in this release is the support for a new platform: NetBSD. The only supported version so far is 9.2. Other minor features since the last announcement are support for FreeBSD 13 and OpenBSD 6.9. ## Under the Hood For those interested in what's going on under the hood. This release contains some major refactoring to add support for the QEMU hypervisor. Up until now the xhyve hypervisor has been used for the FreeBSD and OpenBSD platforms. Unfortunately NetBSD doesn't run on the xhyve hypervisor, therefore support for QEMU was added. In this release it's only possible to run NetBSD on Linux hosts. The GitHub Linux runners doesn't support hardware accelerated nested virtualization. This unfortunately means that the QEMU hypervisor will be a bit slower than the xhyve hypervisor. [1] https://forum.dlang.org/post/jhasyhuvcxoqhldlb...@forum.dlang.org
Re: [Semi-OT] Cross-Platform GitHub Action 0.3.0 - NetBSD
On Tuesday, 16 November 2021 at 14:38:48 UTC, Sebastiaan Koppe wrote: I was reading https://github.com/marketplace/actions/cross-platform-action#under-the-hood and have to say I am impressed. Looks like a very well done library. Thanks. Yeah, it turned out to be quite complex to support everything. Multiple platforms, multiple hypervisors, multiple hosts platforms etc. -- /Jacob Carlborg
Re: [Semi-OT] Cross-Platform GitHub Action 0.3.0 - NetBSD
On Tuesday, 16 November 2021 at 14:04:12 UTC, Imperatorn wrote: Oh, nice to see support for FreeBSD. I just added a version for it in druntime 4 days ago. Now maybe we can test it lol I can add older versions of FreeBSD (currently 12.2 and 13 are supported) if there's a need for that. /Jacob Carlborg
Re: Z80 Emulation Engine
On 22/04/14 07:57, Manu via Digitalmars-d-announce wrote: Yeah, I understand the license options essentially, but it's more than just the license text, there are license cultures that affect the decision, and people are borderline religious about this sort of thing. I mean, the GPL seems fine to me, but there are many people who see GPL and avoid it like the plague as a matter of superstition or something. I'd prefer to not discourage interest or contribution just because I wrote "GPL" near my code. Then people invented LGPL and in my experience, this makes some of them feel okay with it, and others still don't wanna go near it. What practical reasons are there to avoid GPL if your software is fundamentally open-source? Ideally, I'd like something like GPL, with the option that I can grant someone an exception to the license upon request. If you want to use some library that is not GPL, or incompatible with GPL. Or the opposite. If someone wants to use your code, but not want to use GPL, but still an open source license. BSD, for example, is much more flexible in these cases. -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 23/04/14 15:24, Atila Neves wrote: Like testing with Cucumber? Wish you could call native D code with it? Now you can! http://code.dlang.org/packages/unencumbered https://github.com/atilaneves/unencumbered I especially like registering functions that take the parameters with the types they need from the regexp captures, as well as the compile-time failures that come from that if done incorrectly. Now I just need to use in "real life". This is awesome. I've been thinking several times about implementing something like this. Now I don't have to :) How do I set up the environment to use this? How complicated is it with the server and wire protocol? -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 23/04/14 19:17, Atila Neves wrote: Thanks. :) The examples directory (which actually only contains one example) shows what is the bare minimum needed. You need: 1. A file with the .wire extension with the host and port for cucumber to connect to in features/step_definitions (just like the example). Cucumber automatically finds this 2. An "app" D source file that tells the compiler which modules to look for step definitions in at compile-time. These are passed in as compile-time string parameters to cucumber.server.runCucumberServer (look at examples/source/app.d) 3. Compile the server app with its dependencies by using dub or the build system of choice 4. Run the server, run cucumber in another shell, marvel at the results :P The only thing that may be confusing in the example directory is the fact that the modules that app.d references are themselves in the `tests` directory. The reason being that I actually use them for unit tests too and as we all know, duplication is bad. Aha, their they are. I didn't noticed the step definitions before. Especially confusing since you do have a step_definitions directory. I expect to run the acceptance / feature tests from a shell script that compiles and runs the server, runs cucumber then brings the server down. Now that I think of it it should be possible to do that from Cucumber itself by using `After` and `Before`. I had to do something like that whilst bootstrapping the process and also for some tests I wrote for my MQTT broker. I think this should work but I can't try it right now so don't trust me: Before do @server = IO.popen("./your_server_name") Timeout.timeout(1) do while @socket.nil? begin @socket = TCPSocket.new('localhost', port) rescue Errno::ECONNREFUSED #keep trying until the server is up or we time out end end end end After do @socket.nil? or @socket.close if not @server.nil? Process.kill("INT", @server.pid) Process.wait(@server.pid) end end The reason it should work is that Cucumber supports mixing step definitions in Ruby and over the wire. Which is awesome. Cool. Have you considered embedding Ruby in some executable and call the D functions from Ruby. To avoid the server and wire protocol. -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 24/04/14 09:19, Atila Neves wrote: I did, yeah, that's why I asked that question recently about calling D from Ruby. Right, that was you. I also thought of using Thrift and played about with it but in the end decided that the simplest option is to just use the wire protocol. It even reports back D exception information back, so the only real thing I can see that's missing is the snippet suggestions when the steps aren't defined yet. If Ruby is embedded Cucumber could be embedded as well, perhaps. Then you could get an executable without dependencies. -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 2014-04-23 15:24, Atila Neves wrote: Like testing with Cucumber? Wish you could call native D code with it? Now you can! http://code.dlang.org/packages/unencumbered https://github.com/atilaneves/unencumbered I especially like registering functions that take the parameters with the types they need from the regexp captures, as well as the compile-time failures that come from that if done incorrectly. Now I just need to use in "real life". BTW, why is the description passed as a template argument to the Cucumber keywords. @Given!("foo") instead of @Given("foo")? -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 2014-04-23 15:24, Atila Neves wrote: Like testing with Cucumber? Wish you could call native D code with it? Now you can! http://code.dlang.org/packages/unencumbered https://github.com/atilaneves/unencumbered I especially like registering functions that take the parameters with the types they need from the regexp captures, as well as the compile-time failures that come from that if done incorrectly. Now I just need to use in "real life". It would be very nice to have something like Aruba in D together with this. If you haven't heard of it it's basically a library making it easier to test CLI applications, often used together with Cucumber. I think it's used by Cucumber itself. -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote: After I read the above I wasn't even sure how @Given("foo") would work so I wrote some code and now know that all I need is a struct with a regular string field. I think the documenation on http://dlang.org/attribute.html is severely lacking. What do you mean, it's right there, at the bottom of the first example [1]: @Bar(3) int d; [1] http://dlang.org/attribute.html#UserDefinedAttribute -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote: Ehm... because until now I didn't know that @Given("foo") was possible. In my head I was doing compile-time stuff so everything had to be compile-time, if that makes any sense. After I read the above I wasn't even sure how @Given("foo") would work so I wrote some code and now know that all I need is a struct with a regular string field. I think the documenation on http://dlang.org/attribute.html is severely lacking. BTW, I think it's possible to use a plain function as well, which returns a struct. In this case, "Given" would be the function. -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 2014-04-25 10:31, Atila Neves wrote: Or I could carry on implementing all the Cucumber features and end up with an executable that does everything the Ruby version does. I'm happy with what I've got now though, but the embedding thing is interesting. I just decided that embedding was too much work. I see. A pure D implementation would be even better. -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 2014-04-25 10:32, Atila Neves wrote: Yeah, I know Aruba. Well, for all of about two weeks :) Why would you want Aruba in D, though? You can just use the Ruby version. Sure I can, I already does this. I would be quite nice with mostly pure D tools. People have been almost hostile in my attempts to use D together with Ruby. I was building a package manager that use Ruby for writing the package description files. That was far from popular. Oh, then why are you adding support for D to Cucumber ;) -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 2014-05-02 17:21, Atila Neves wrote: Finally got around to it and now it's @Given("foo") like it should've been. Bumped the version up to v0.2.0. Cool :) -- /Jacob Carlborg
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On 08/05/14 22:43, Nick Sabalausky wrote: I wasn't trying to blame Qt/Gtk (actually, I kinda like Qt stuff - I've heard it's not technically native UI, but hell if I can actually tell the difference. They've done a damn fine job.) I think it's quite easy to tell the difference, on OS X. But that might be a problem with the actual application, that doesn't follow OS X conventions, and not Qt itself. -- /Jacob Carlborg
Re: Livestreaming DConf?
On 2014-05-09 21:48, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 That would be awesome, although I don't know if I'll be able to watch due to time zone differences. -- /Jacob Carlborg
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On 2014-05-11 19:34, Gary Willoughby wrote: I see. I think i have been bitten by this actually. What would be your solution? Without having looked at the code, call GC.addRoot. It will make sure the GC knows about the memory even if there's no other reference to it. -- /Jacob Carlborg
[OT] Travis CI gets multi-OS support
A bit off topic but I think it's important: http://blog.travis-ci.com/2014-05-13-multi-os-feature-available/ -- /Jacob Carlborg
Re: Regal: An SQL relational algebra builder
On 16/05/14 02:29, Dylan Knutson wrote: Hi all, I'd like to announce the initial version of Regal, an SQL relational algebra builder for D. It's intended as a backbone for a relational database ORM, in line with how Arel works with Rails' ActiveRecord, but nearly any project that generates SQL dynamically can benefit from it. The goal of the library is to make programmatically generating queries simple (and more robust than simple string concatenation), and to be database agnostic (it's very easy to write database specific printers for a Regal AST). There are extensive examples available in the Readme about how to use the library, from generating very simple queries (SELECT * FROM users) to multiple chained joins and nested constraints. Here's an example from the documentation: finding a user with ID 1: ``` auto users = new Table( "users", // table name "id",// the rest are columns "name", "created_at", "updated_at"); Does this need to be a class, can it be a struct instead? // SELECT * FROM users WHERE users.id = 1 LIMIT 1 users .where(users.id.eq(1)) .limit(1) .project(new Sql("*")) .to_sql ``` Why is 'new Sql("*")' needed? If you need to have a specific type, could it be a struct instead? The library can be found at: https://github.com/dymk/regal And the dub package: http://code.dlang.org/packages/regal This all looks pretty nice :). Does it work at compile time? -- /Jacob Carlborg
Re: Regal: An SQL relational algebra builder
On 16/05/14 09:58, Dylan Knutson wrote: Ya know, it might be able to be made into a struct; I'll fiddle with it tomorrow. The main reason it was made a class was so .join had to take a Table type as its first parameter, and internally Table implements a Joinable interface (which is needed for chaining .joins and propagating the table name during printing). Can you do compile time introspection, like ranges do? Basically check if it has a "join" method. The Sql class is needed because it's a node in the AST (all nodes inherit from a basic Node class) that just prints out its content verbatim when to_sql is called. All the methods that take a Node would need to be modified/templated to also accept a specialized SQL struct type, which unfortunately isn't feasible. If it was done, it'd probably be implemented using std.variant's Algebraic type, but then CTFE is forfeited. If you know of another way to go about doing this, I'd be really interested in hearing it. It is unfortunate that the library has to make so many small allocations, for sure. I don't know, use structs and compile time introspection. Another option is, you could try using CTFE as much as possible to get the allocations over with at compile time :) -- /Jacob Carlborg
Re: Regal: An SQL relational algebra builder
On 2014-05-19 16:45, Dylan Knutson wrote: I've played around with making things structs a bit more, and have modified regal to have Table and Sql be structs (by having Sql and the generic Node class wrapped in a tagged union). Making Table a struct was just a matter of putting some common methods in a template mixin, and mixin'ing that where appropriate. New version is at ~master on github and code.dlang.org Cool. -- /Jacob Carlborg
Re: Dash: An Open Source Game Engine in D
On 19/05/14 21:50, Colden Cullen wrote: Hi everyone, I’m super excited to be able to announce that the Dash game engine[1] is finally stable and ready for public use! I’m currently the Lead Engine Programmer at Circular Studios[2] (the group behind Dash). We had 14 people working on the team, 6 engine programmers and 8 game developers creating Spectral Robot Task Force, a turn-based strategy game built with Dash. Dash is an OpenGL engine written in the D language that runs on both Windows and Linux. We use a deferred-rendering model in the current pipeline, and a component model for game development and logic. Other major features at the moment include networking, skeletal-animation support, content and configuration loading via YAML, and UI support through Awesomium[3] (though we are in the process of moving over to using CEF[4] itself). Our vision for Dash is to have the programmer-facing model of XNA/Monogame combined with the designer-friendliness of Unity in a fully free and open source engine. We also hope that Dash can help to prove the power and maturity of D as a language, as well as push D to continue improving. We’re open to any feedback you may have, or better yet, we’d love to see pull requests for improvements. This looks awesome :), but no support for OS X :(. What system is used to render windows, custom or something like SDL? -- /Jacob Carlborg
Re: D's timeline
On 20/05/14 10:19, Brad Roberts via Digitalmars-d-announce wrote: I'm working on my presentation for the conference and I'm running out of time. I'd like to ask you guys for some help locating a few dates: 1) When 0.x transitioned from alpha to beta 2) Was there a beta to release candidate transition for 0.x -> 1.x? If so, when? I have the 1.00 release date, that one is easy. 3) When did the 2.x series switch similarly (alpha, beta, rc)? 4) When were the various platforms added to the release bundles? Here is what I found out from the changelog: * Linux 0.63 [1] * OS X 32bit 1.040 [2], 2.025 [8] * FreeBSD 2.053 [3], 1.043 [4] * OS X 64bit 2.053 [3], 1.072 [5] * Linux 64bit 2.052 [6], 1.067 [7] [1] http://www.digitalmars.com/d/1.0/changelog1.html#new063 [2] http://www.digitalmars.com/d/1.0/changelog.html#new1_040 [3] http://dlang.org/changelog.html#new2_053 [4] http://www.digitalmars.com/d/1.0/changelog.html#new1_043 [5] http://www.digitalmars.com/d/1.0/changelog.html#new1_072 [6] http://dlang.org/changelog.html#new2_052 [7] http://www.digitalmars.com/d/1.0/changelog.html#new1_067 [8] http://dlang.org/changelog.html#new2_025 -- /Jacob Carlborg