Re: Get unknown symbol (struct, method, class) tagged with User Defined Attributes
On Tuesday, 12 May 2020 at 04:02:18 UTC, Steven Schveighoffer wrote: In the case of serialization/deserialization, you give an instance of a type to serialize or deserialize. Then the library can search the symbols inside that type to see if any has the UDA you are looking for. In the Rust example, there is a line of code: let p: Person = serde_json::from_str(data)?; I'm assuming that this conversion is detected and figured out (i.e. this is how serde "finds" the type desired). For D, it would look something like: auto p = serde_json.from_str!Person(data); If you want a list of ALL symbols that have the UDA in the application, that would require some form of runtime reflection (like Java). D has very limited support for runtime reflection. In D, you would use some form of registration to tell the system about your symbols. -Steve Thanks for the feedback. I've got a better idea of what is and isn't possible now. I'll see about looking at one or two D JSON libraries to see how they approach things. It should help shed some more light on the subject.
Re: How does a free list work?
On Saturday, 9 May 2020 at 22:48:46 UTC, Simen Kjærås wrote: On Saturday, 9 May 2020 at 19:54:44 UTC, Pavel Shkadzko wrote: [...] The GC keeps a list of roots - that is, objects that are known to be active and should not be collected. The static freelist is one of those - since it's static it should of course never be collected. [...] Thank you for such a detailed answer!
Re: Optional type parameter on a template
On Tuesday, 12 May 2020 at 20:40:35 UTC, Adam D. Ruppe wrote:
A default argument of void is a common way to do it
template foo(T = void) {
static if(is(T == void)) { not given } else { use T }
}
Perfect! Works as I desired.
Re: Optional type parameter on a template
On Tuesday, 12 May 2020 at 20:36:22 UTC, Luis wrote:
I'm trying to make a SparseSet that on function of a optional
type parameter, could alongside the index set, store other
data. So I need a way to declare a optional type template
parameter.
A default argument of void is a common way to do it
template foo(T = void) {
static if(is(T == void)) { not given } else { use T }
}
// trying to use ZeroOrMore() gives error : struct
onlineapp.ZeroOrMore cannot deduce function from argument types
!()(), candidates are: onlineapp.d(12): ZeroOrMore(T = uint,
Types...)
Yeah, a template with default parameters must still be
instantiated, but you do not need to give the arguments. The ! is
a must though (or you could provide some alias but then it has a
separate name)
Optional type parameter on a template
I'm trying to make a SparseSet that on function of a optional
type parameter, could alongside the index set, store other data.
So I need a way to declare a optional type template parameter.
I prototyped this stuff on run.dlang, but I like know if there is
a better way :
https://run.dlang.io/is/Uhy5IT
import std;
struct S {
int x = 0;
string toString()
{
return "S(x="~ x.to!string ~")";
}
}
struct ZeroOrMore(T = uint, Types...)
if (__traits(isUnsigned, T))
{
static assert (Types.length == 0 || Types.length == 1);
T[] _t;
static if (Types.length > 0) {
alias V = Types[0];
V[] _values;
void ins(T t, V val)
{
this._t ~= t;
this._values ~= val;
}
} else {
void ins(T t)
{
this._t ~= t;
}
}
}
void main()
{
auto s = ZeroOrMore!()();
// trying to use ZeroOrMore() gives error : struct
onlineapp.ZeroOrMore cannot deduce function from argument types
!()(), candidates are: onlineapp.d(12): ZeroOrMore(T = uint,
Types...)
s.ins(456);
auto s2 = ZeroOrMore!(uint, S)();
s2.ins(123, S(666));
writeln(s); // ZeroOrMore!uint([456])
writeln(s2); // ZeroOrMore!(uint, S)([123], [S(x=666)])
}
Re: Optional type parameter on a template
Sorry ... wrong link. This is the correct : https://run.dlang.io/is/D2iCP0
Re: D and Async I/O
On 2020-05-12 11:23, Russel Winder wrote: As far as I can tell D has no futures… Future and async in vibe.d [1]. Future in Mecca [2]. [1] https://vibed.org/api/vibe.core.concurrency/async [2] https://github.com/weka-io/mecca/blob/0593a35dd1a9978855d7db349fc1172f04cf8013/src/mecca/reactor/sync/future.d#L23 -- /Jacob Carlborg
Re: Fetching licensing info for all dependencies of a DUB project
On Tuesday, 12 May 2020 at 13:08:01 UTC, Joseph Rushton Wakeling wrote: On Tuesday, 12 May 2020 at 12:59:14 UTC, Paul Backus wrote: You should be able to get this information from the JSON output of `dub describe`. Cool, thanks. Much appreciated :-) Has anyone created any tools to condense that into a licensing report? No worries if not, just curious. Not that I know of. If you end up making one yourself, it might be worth posting in the Announce forum.
Re: Fetching licensing info for all dependencies of a DUB project
On Tuesday, 12 May 2020 at 12:59:14 UTC, Paul Backus wrote: You should be able to get this information from the JSON output of `dub describe`. Cool, thanks. Much appreciated :-) Has anyone created any tools to condense that into a licensing report? No worries if not, just curious.
Re: Fetching licensing info for all dependencies of a DUB project
On Tuesday, 12 May 2020 at 12:44:11 UTC, Joseph Rushton Wakeling wrote: Hello folks, Are there any tools that exist to help prepare a report of all the different software licenses used by dependencies of a DUB project? (This should cover all pulled in dependencies, not just direct dependencies.) Thanks and best wishes, -- Joe You should be able to get this information from the JSON output of `dub describe`.
Fetching licensing info for all dependencies of a DUB project
Hello folks, Are there any tools that exist to help prepare a report of all the different software licenses used by dependencies of a DUB project? (This should cover all pulled in dependencies, not just direct dependencies.) Thanks and best wishes, -- Joe
Re: D and Async I/O
On Tuesday, 12 May 2020 at 09:23:40 UTC, Russel Winder wrote: On Mon, 2020-05-11 at 19:34 +0200, Jacob Carlborg via Digitalmars-d-learn wrote: On 2020-05-11 16:44, Russel Winder wrote: > Crickey, a third option. This wil increase my dithering! ;-) Forth: Mecca [1] :) [1] https://github.com/weka-io/mecca Hummm… it seems everyone who needed async activity and particularly I/O in D has written their own. Mostly along with all their own data structures and algorithms library. Yeah it is a shame, but you see it in almost every language. Probably means concurrency and io isn't a fully solved problem yet. I keep trying to come back to D for GTK+ working, but in the end I keep going back to Python and Rust because D has no futures, and no added extras over GtkD auto translation of the GTK+ API to make it D-y in the way gtk-rs make GTK+ Rust-y. Sorry for the apparent gloom, I just felt the need to tell it how I feel. I think there are a lot of lessons to be learned from all the efforts in the programming community. We should: - get stackless coroutines - get structured concurrency - steal as many idea from the C++'s executors proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r13.html)
Re: D and Async I/O
On Mon, 2020-05-11 at 19:34 +0200, Jacob Carlborg via Digitalmars-d-learn wrote: > On 2020-05-11 16:44, Russel Winder wrote: > > > Crickey, a third option. This wil increase my dithering! ;-) > > Forth: Mecca [1] :) > > [1] https://github.com/weka-io/mecca Hummm… it seems everyone who needed async activity and particularly I/O in D has written their own. Mostly along with all their own data structures and algorithms library. The Rust experience is that there were also many attempts (cf. Tokio and Async_std) but that development and maintenance now seems focused on providing the minimal support for futures in the language (as an API to work with) and the crate futures to provide all the serious stuff, and that all the different event loops are converging on using this – Tokio and Async_std are moving to provide functionality over the std::futures and futures stuff as far as I can tell, indeed Async_std's name tells their story. It isn't pretty in many ways, but it works, and provides a one true Rust-y way of being asynchronous. gtk-rs is working to use the GTK+ async stuff (which is callback based) but provide it in a Tokio/Async_std kind of API based on std::futures and futures crate. This is a huge, huge plus over what D has. GtkD is missing all the added extras that gtk-rs is in the process of providing. As far as I can tell D has no futures… on which to base an equivalent system. I guess the async/.await language syntax will almost certainly never get into D even though it is the choice for Rust and Python – and indeed Kotlin but with a different syntax structure. But is there an alternative, a pure library based way. Clearly yes at the expense of some irritating verbosity that Rust, Python and Kotlin chose not to cope with, but to make language syntax changes instead. Of course this requires effort. Clearly, Rust, Python, and Kotlin have paid people to do all the futures stuff. Firther there is some effort to do this in gtk-rs and I am providing some input with this. If there was effort to add futures to D and extend GtkD in the way gtk-rs is being extended, it would be good for D. D is far, far better than Rust for writing GTK+ code, and could easily replace Vala. However, with the way gtk-rs is developing and GtkD is not, Rust will win out. Well at least people like me will use Rust and gtk-rs instead of D and GtkD because of the language and library evolution in the right direction. Sadly I think that whilst there may or may not be a flurry of activity on this thread, there will not be enough volunteers committed to do the work on futures in D and GtkD to make anything happen. I keep trying to come back to D for GTK+ working, but in the end I keep going back to Python and Rust because D has no futures, and no added extras over GtkD auto translation of the GTK+ API to make it D-y in the way gtk-rs make GTK+ Rust-y. Sorry for the apparent gloom, I just felt the need to tell it how I feel. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D and Async I/O
On Monday, 11 May 2020 at 15:02:59 UTC, bauss wrote: On Monday, 11 May 2020 at 14:02:54 UTC, Russel Winder wrote: OK, so I need to create an asynchronous TCP server (not HTTP or HTTPS, this is a real server ;-) ). I think the normal response is "Use Vibe.d". However, recently I see Hunt is an alternative. Has anyone any way of choosing between the two? vibe.d is much more mature than Hunt, that would be my take on it. Also Hunt lacks documentation etc. I notice that Hunt uses it's own library eschewing all of Phobos. Is this an indicator that Phobos is not suitable for networking activity? std.socket is terrible, so yes that is an indicator. You can't even wrap something up fast in it either. Basically it's low-level while not being low-level at the same time. You have to handle __everything__ yourself pretty much. Have a look also to Martin std.io [1] and Steven iopipes [2], if you need something simple. [1] https://github.com/MartinNowak/io [2] https://code.dlang.org/packages/iopipe
