Re: DMD Frontend working in WebAssembly
On Thursday, 14 October 2021 at 22:56:07 UTC, hatf0 wrote: Hi all, I've just managed to get the full DMD front-end to work in WebAssembly (with skoppe's druntime fork). This doesn't do code-gen or anything (but it potentially could?), and has some OS-specific functionality stubbed out. No clue about GC -- haven't run into that issue, haven't thought about it yet! You can find my work here if you're interested: https://github.com/hatf0/dmd-fe-wasm-wrapper This repo also serves as a semi-decent guide on how to get started building files that target WebAssembly (specifically WASI), if you're into that. Oooh -- I totally forgot: for some reason, this doesn't work with the wasmer JS runtime. I haven't done any investigation into it, since it works just fine with the wasmer Rust runtime. More work needs to be done before we can fully bring DMD to the browser, but this could totally open up the idea of having something like Swift Playgrounds within the browser (or perhaps some toys like AST inspection, or whatnot).
DMD Frontend working in WebAssembly
Hi all, I've just managed to get the full DMD front-end to work in WebAssembly (with skoppe's druntime fork). This doesn't do code-gen or anything (but it potentially could?), and has some OS-specific functionality stubbed out. No clue about GC -- haven't run into that issue, haven't thought about it yet! You can find my work here if you're interested: https://github.com/hatf0/dmd-fe-wasm-wrapper This repo also serves as a semi-decent guide on how to get started building files that target WebAssembly (specifically WASI), if you're into that.
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
Re: OpenBSD DMD package
On Thursday, 14 October 2021 at 14:51:57 UTC, Jacob Carlborg wrote: 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 Awesome! I will spend some time soon figuring it out. ~Brian
Re: New library: argparse, for parsing CLI arguments
On 10/13/21 9:13 PM, Andrey Zherikov wrote: On Thursday, 14 October 2021 at 00:35:11 UTC, Bill Baxter wrote: Not sure how much change there is over "classic" gflags, but https://abseil.io/docs/cpp/guides/flags is what google now uses internally. Abseil version suggests not to put flags into multiple .cpp files: - `Allows distributed declaration and definition of flags, though this usage has drawbacks and should generally be avoided` - `Prefer to define flags only in the file containing the binary’s main() function` - `Prefer to reference flags only from within the file containing the binary’s main() function` So I'm a bit confused about supporting this use case Yeah, there is a problem with doing this the D way, and that's with module constructors. You can run into cycles. When I implemented database migrations in my application, I set it up so I could run module ctors that set up each migration near the location where I'm defining the data structures, but I ended up having to put them all into a dedicated `migrations` module to avoid the cycles. D could definitely use a way to specify a no-dependency module ctor/dtor. -Steve
Re: New library: argparse, for parsing CLI arguments
On 10/13/21 7:36 PM, Andrey Zherikov wrote:
On Wednesday, 13 October 2021 at 16:24:52 UTC, Steven Schveighoffer wrote:
The point is that I shouldn't have to tell the library the name of
something that I've already given a name to.
Having them named differently on the command line than the actual
field name should still be a possibility (and required in some cases,
e.g. the `enum` case above), but honestly, the `Params` struct exists
solely to accept command line parameters, there's no compelling need
to use alternate names for the command line and the field name. If the
library automatically does the right thing by default, then your code
becomes simpler and more beautiful.
Not to detract from your library, because I think it's an awesome
design to model using structs (one I use all the time), but the API
developer in me frowns at lack of DRY. Try to focus on requiring the
smallest amount of machinery/attributes possible. Every time you
require extraneous pieces to get things to work, it adds another place
where errors/confusion can happen.
I got your point. Omitting the name is good suggestion and I'll add this.
Regarding the detecting all members and treating them as an arguments, I
see one issues so far: the struct might have other members that are not
used in CLI (it can be even functions).
Having done a lot of stuff with serialization and UDAs, this turns into
a mess if you have multiple systems (serialization is really what you
are doing here) using the same structs. So really, you are likely to
have this `Params` struct be distinctly for parameter parsing. It's OK
to have requirements such as expecting all items to be serialized by
default and in a default way.
Consider the example when the member is renamed but the struct still
provides the old name for backward compatibility:
```d
struct T
{
string name;
@property string label() const { return name; }
}
pragma(msg, __traits(allMembers, T)); // tuple("name", "label")
```
Various ways to solve this:
1. Have an `@ignore` uda
2. UFCS `label`
3. make `label` private (and ensure you check for that in your library code)
So to implement your suggestion correctly, `argparse` should provide a
way to opt-out specific members from CLI.
Possibly. Another possibility is to use WebFreak's idea and just tag
them with `@NamedArgument` without a name, then you can opt-in via
`@NamedArgument:` at the top (or put in a scope).
The way I approach serialization is "how would I serialize this thing if
I wrote the code manually?" and use that as the default implementation.
Then if you want to do things different from the default, use UDAs for that.
In addition to that, each CLI argument usually has its own help text so
in most cases each member will have an UDA with this text which makes
opt-out approach mush less useful. So it sill look like this at the end:
```d
struct T
{
@help("First name")
string firstName;
@help("Last name")
string lastName;
@skip
@property string fullName() const { return firstName~" "~lastName; }
}
```
It's not the UDAs, it's requiring in the UDA a repeat of the name that's
already introspectable. I also prefer having a default handling for
something so UDAs are not needed, but this is not as important.
Also, I'll note for your example, having an explanation for "firstName"
to mean "First Name" is another thing that reasonable people can
disagree on, but IMO, I would just let the name speak for itself.
-Steve
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: New library: argparse, for parsing CLI arguments
On Thursday, 14 October 2021 at 13:51:50 UTC, Paul Backus wrote: On Thursday, 14 October 2021 at 13:37:29 UTC, Andrey Zherikov wrote: Another thing is that I couldn't use `allMembers` without using the module name explicitly, because: `__traits(isModule, __MODULE__)` returns `false` and `__traits(allMembers, __MODULE__)` gives `"mymodule" can't have members, "mymodule" must evaluate to either a module, a struct, an union, a class, an interface or a template instantiation` You can use `__traits(allMembers, mixin(__MODULE__))`. How nice! Thanks!
Re: New library: argparse, for parsing CLI arguments
On Thursday, 14 October 2021 at 13:37:29 UTC, Andrey Zherikov wrote: Another thing is that I couldn't use `allMembers` without using the module name explicitly, because: `__traits(isModule, __MODULE__)` returns `false` and `__traits(allMembers, __MODULE__)` gives `"mymodule" can't have members, "mymodule" must evaluate to either a module, a struct, an union, a class, an interface or a template instantiation` You can use `__traits(allMembers, mixin(__MODULE__))`.
Re: New library: argparse, for parsing CLI arguments
On Thursday, 14 October 2021 at 02:09:35 UTC, Bill Baxter wrote: Yeh, it's definitely a mixed bag. It can be very convenient to be able to put the flag right near point of use without having to do any plumbing. But sometimes it can be frustrating given that "flags" are essentially a single global namespace that people don't always realize is a global namespace. Quite annoying when you go to add something like a "--start_time" flag and find that some random .cc file in a library already defines that flag for their own purposes. --bb I might be wrong but AFAIK D program doesn't have global namespace - it's split between modules. Another thing is that I couldn't use `allMembers` without using the module name explicitly, because: `__traits(isModule, __MODULE__)` returns `false` and `__traits(allMembers, __MODULE__)` gives `"mymodule" can't have members, "mymodule" must evaluate to either a module, a struct, an union, a class, an interface or a template instantiation`
