Re: Vision document for H1 2018
On Monday, 12 March 2018 at 03:11:34 UTC, Laeeth Isharc wrote: You don't need to have subsystem for Linux to use bash. Just the standard git client for Windows is enough. Happy to find out about this. It's not like using git bash everyday on Windows to know this by default. sh setup.sh [...] make -> Command error: undefined switch '-C'
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 03:37:11 UTC, Laeeth Isharc wrote: cd test make all -j8 Command error: undefined switch '-j8' Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone). https://wiki.dlang.org/DMD_development Of course, it works without the -j8 switch, but the documentation doesn't say that multiple threads option is only available on Linux.
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 04:54:22 UTC, Jonathan M Davis wrote: On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce wrote: On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: > [...] Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone). When dealing with building on Windows, it would definitely pay to read the instructions and not assume anything about make, since unfortunately, the Windows build uses the digital mars make, which is severely limited in comparison to the BSD make or GNU make. - Jonathan M Davis That's only partially true and the reason for the error. GNU/BSD make is required to run the DMD testsuite. BTW removal of DigitalMars Make has been officially approved since a long time, but it's blocked since it's so hard to make changes to the auto-tester.
[Issue 18133] BitArray constructors are poorly documented.
https://issues.dlang.org/show_bug.cgi?id=18133 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/3609d7233414fbd8a9d0c21313be21aff02d6829 Merge pull request #6112 from byebye/issue_18133 Fix issue 18133 - improve docs and add code examples for BitArray constructors merged-on-behalf-of: Jack Stouffer--
Re: Vision document for H1 2018
On Monday, March 12, 2018 03:31:36 Laeeth Isharc via Digitalmars-d-announce wrote: > If Phobos looks like a mess to C# programmers, so much the worse > for C# programmers. However I doubt they this is true in the > general case. It's better in many ways, but different and > unfamiliar and everything unfamiliar is disconcerting in the > beginning. Yeah, I remember when I was first dealing with D years ago, and the range stuff that was in there was totally unfamiliar, and it annoyed me, because I just wanted the iterators that I was familiar with so that I could easily do what I wanted to do. Granted, it was worse to figure all of that out then, since the documentation was much worse (e.g. at the time, there was a compiler bug that made it so that auto return functions did not show up in the documentation, so all of std.algorithm explicitly listed the return types, making it downright scary), but still, at the time, I just didn't want to deal with figuring out the unfamiliar concept, so it annoyed me. Now, I actually understand ranges and am very glad that they're there, but as a D newbie, they were annoying, because they were unfamiliar. I think that I'd approach it all very differently now, since at the time, I was in college and just generally a far less experienced programmer, but I think that many of us tend to look for what we expect when learning a new language or library, and when that's not what we get, it can be disconcerting to begin with. Phobos is very unique in its approach with ranges, likely making it a major learning experience for anyone from any language, but AFAIK, the only language with a comparable approach in its standard library is C++, and I'd definitely expect it to be somewhat alien to the average C# or Java programmer - at least to begin with. D does things differently, so anyone learning it is just going to have to expect to deal with a learning curve. How steep a curve that is is going to depend on the programmer's experience and background, but it's going to be there regardless. - Jonathan M Davis
Re: Vision document for H1 2018
On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce wrote: > On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: > > On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote: > >> [...] > > > > Yes, I'm the typical lazy convenient Windows user scared of the > > terminal window. > > > >> [...] > > > > I am happy for Posix users. Theoretically the process is the > > same on Windows. > > > >> [...] > > > > This will need Linux subsystem as a Windows feature installed. > > Bash scripts do not work on Windows. Or other third party > > applications that are not listed as prerequisites on wiki. > > > >> [...] > > > > make -fwin32.mak release > > Error: don't know how to make 'release' > > > > Ok, let's skip this, make it without "release". > > > > Now test it: > > > > cd test > > make all -j8 > > Command error: undefined switch '-j8' > > Why are you adding -j8 ? Does it say to do so in the instructions > ? Try without it. (I can't test here as typing from my phone). When dealing with building on Windows, it would definitely pay to read the instructions and not assume anything about make, since unfortunately, the Windows build uses the digital mars make, which is severely limited in comparison to the BSD make or GNU make. - Jonathan M Davis
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. Hey.. I feel your pain.. I like things to be easy too ;-) but I think comparing things in the C# world, to things in the D world, does not make a lot of sense, really. It's like comparing my local corner shop to some worldwide supermarket chain. What's the point in going into the local corner shop and complaing that they don't stock this or that, but the supermarket down the road does. Or complaining that they charge $4 for a loaf of bread, when down the road at the supermarket it only costs $2.50. You have to compare apples with apples, not apples with shiny red toffee apples ;-)
[Issue 18591] DMD should allow access to mixin template declarations
https://issues.dlang.org/show_bug.cgi?id=18591 Simen Kjaeraaschanged: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #2 from Simen Kjaeraas --- Issue example from PR: struct TypeObj { alias This = typeof(this); mixin template MixinTempl() { int value; } } ref TypeObj Obj() { static TypeObj a; return a; } void main() { mixin Obj.This.MixinTempl; // ok mixin Obj.MixinTempl; // error: "MixinTempl!()" is not defined } --
Re: How do you call an eponymous template that has a secondary template arg?
On Sunday, 11 March 2018 at 12:05:56 UTC, aliak wrote: * aliasOf!int!"string" // multiple ! arguments are not allowed * (aliasOf!int)!"string" // error c-style cast * aliasOf!int.aliasOf!"string" // template isAliasOf(alias a) does not have property 'isAliasOf Yeah, that's a little hole in the grammar, but there are ways: // Declare an alias: alias aliasOfInt = aliasOf!int; // And use that: assert(!aliasOfInt!string); Or use std.meta.Instantiate: assert(!Instantiate!(aliasOf!int, string)); -- Simen
Re: core.stdc.stdlib._compare_fp_t and qsort
On Monday, 12 March 2018 at 03:13:08 UTC, Seb wrote: Out of interest: I wonder what's your usecase for using qsort. Or in other words: why you can't use the high-level std.algorithm.sorting.sort? This is only temporary. I will be using std.algorithm.sorting.sort. I was converting a C program and it annoyed me that I couldn't get the qsort invocation past the D compiler.
Re: Question over C++ to D conversion
On Monday, 12 March 2018 at 02:48:17 UTC, Laeeth Isharc wrote: [snip] For conversion of C headers, watch this space. C first, C++ eventually. Might be a talk at Dconf on it. I think I saw a reference to this somewhere else. Sounds pretty darn cool.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote: [...] Yes, I'm the typical lazy convenient Windows user scared of the terminal window. [...] I am happy for Posix users. Theoretically the process is the same on Windows. [...] This will need Linux subsystem as a Windows feature installed. Bash scripts do not work on Windows. Or other third party applications that are not listed as prerequisites on wiki. [...] make -fwin32.mak release Error: don't know how to make 'release' Ok, let's skip this, make it without "release". Now test it: cd test make all -j8 Command error: undefined switch '-j8' Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone).
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote: On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote: And personally, depending on the problem, C# is better to program in than D. I still don't know why C# programmers are willing to give up C# and prefer to use D. C# is vastly surperior for what it does. Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. The problem is that D stagnates and in the same time C# evolves. Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a lot of D concepts were introduced in the language: local functions, '_' as digit separator, binary literals, ref returns, tuples, templates, immutability. Guess what the next version of C# has on the table: slices. In the same time, D delegates new features (and sometime existing ones) to library implementation, instead of assume them in the language syntax. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. It's a good thing not bad that other languages are inspired by what works. Languages aren't in a vicious battle to the death, a Hobbesian war of all against all. If C# gets better, that's great! I don't think D is stagnating at all - on the contrary, it's amazing to see the ecosystem flourishing, no matter where you look - documentation, adoption, libraries, commercial adoption. I think it's reasonable to disagree with the strategic decision made to move capabilities from compiler to libraries. But you really have to make an argument about why you disagree if you are you expect to be persuasive because there is a thought-through argument for the choices made, which I am sure you must be familiar with. I don't think it matters much whether you are right about what happens to C# programmer interest in D dies as soon as C# native cross-platform is ready because D is quite an ambitious language and doesn't need to depend on adoption from any one community to continue growing at an impressive rate. As it happens though, as an empirical matter I doubt it. C# slices look great. I wanted to use them for generating wrappers for our analytics. Not that easy for that purpose, from what I could see. Looks like the primitives are stack only, and I tried to figure out how to use them elsewhere and gave up because it wasn't that easy. If Phobos looks like a mess to C# programmers, so much the worse for C# programmers. However I doubt they this is true in the general case. It's better in many ways, but different and unfamiliar and everything unfamiliar is disconcerting in the beginning.
[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler
https://issues.dlang.org/show_bug.cgi?id=18282 Walter Brightchanged: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |INVALID --- Comment #1 from Walter Bright --- (In reply to Mike Franklin from comment #0) > void main() @safe > { > string foo = "foo"; > scope string*[] ls; > ls ~= > } > > Compile with `-dip1000` > > onlineapp.d(5): Error: reference to local variable foo assigned to non-scope > ls While ls is scope, ls[] is not scope. Scope is not transitive, hence the compiler error. > The compiler doesn't seem to recognize that ls is attributed with `scope`. > However due to the way D's attributes are parsed, I'm not sure if it should > actually be `scope string*[]`, `scope(string*)[]`, or `scope(string*[])`. > Anyway, if you use `scope()` (i.e. with parens) the compiler confuses it > with `scope(exit)` and friends. > > > void main() @safe > { > string foo = "foo"; > scope(string*[]) ls; > ls ~= > } > > Compile with `-dip1000` > > onlineapp.d(4): Error: valid scope identifiers are exit, failure, or > success, not string Scope is a storage class, not a type constructor. (`const`, for example, is a type constructor, and `static` is a storage class.) --
Re: core.stdc.stdlib._compare_fp_t and qsort
On Monday, 12 March 2018 at 02:44:17 UTC, Joe wrote: I saw the extern(C) and I believe I tried it before my previous post, but dismissed it because I saw no difference in compiler behavior. Yeah, the compiler should just tell you what specifically it is complaining about instead of making you hunt. These "no function match" errors are actually my #1 pain point as a daily D user... and as a regular D tech support rep, I see there are very frequent problems for everyone else too. Could you explain or direct me to something that elucidates why the "scope" qualifiers are needed? And is there something else that is necessary inside compar() or are the "scope"s just for decorative purposes? So `scope` means you promise not to escape the reference outside your scope; that you won't store the pointers somewhere else for future use. It is defined here: https://dlang.org/spec/function.html#parameters tho that's pretty light. The compiler only checks it if you throw some random -dipsomething switch. The idea is something similar to Rust's borrow checker. It aims to make it a compile error to sneak out pointers to temporaries through our callback. You wouldn't do that anyway with a compare function, but now it is an error to try ( if the strict enforcement thing is thrown. and i don't remember the name, they are all random dip numbers on the switches) I'm actually mildly against adding these directly to C functions, but this attribute spam is being added to all the druntime definitions. It requires stuff like nothrow and nogc on a bunch of handlers too, ugh, but the idea behind it is to make sure you don't break the C function's documented rules, but here checked by the D compiler without needing any runtime wrappers/checks. But until recently it wasn't checked at all which is why I wasn't sure if that was causing your error. I guess it is required to match the function call even if the strict enforcement isn't thrown now.
Re: dpldocs now has cross-package search (experimental)
I probably released this a bit too soon... it seems to have a memory leak and eventually pushes all other server functions out if I leave it running. So I took the search back down for now until I can debug that, or maybe just rewrite the program to something fundamentally more memory-efficient.
Re: core.stdc.stdlib._compare_fp_t and qsort
On Sunday, 11 March 2018 at 23:12:30 UTC, Joe wrote: I'm getting a compiler error in a qsort() call as follows: qsort(recs, num_recs, (Record *).sizeof, compar); Record is a struct, recs is a fixed array of pointers to Record's and num_recs is a size_t that holds the number of valid records. compar is this: int compar(const void *p1, const void *p2) { import core.stdc.string : strcmp; const Record **rp1 = cast(Record **)p1; const Record **rp2 = cast(Record **)p2; return strcmp((*rp1).name.ptr, (*rp2).name.ptr); } The error is: Error: function testd.compar (const(void*) p1, const(void*) p2) is not callable using argument types () I don't quite understand what those parentheses mean: is it implying "no arguments" and if so, where would one provide arguments? Joe Out of interest: I wonder what's your usecase for using qsort. Or in other words: why you can't use the high-level std.algorithm.sorting.sort?
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. Funnily enough, becoming a significant contributor to the ecosystem - compiler or Phobos - demonstrably does not require even a complete graduation from high school or any industrial programming experience. I know of what I speak, but I don't say who as it's not for me to say. I was in Munich over new year and I asked someone else who has been a star contributor how he got involved. It was really easy for him to start contributing, so he did. But different people find different things easy. You don't need to have subsystem for Linux to use bash. Just the standard git client for Windows is enough. I agree the Windows experience could be easier upfront. Still, it's better than it used to be and next year it will be better again. You can't really compare the C# ecosystem to the D ecosystem because they are organised around different principles. Yes, the pain is upfront with D, and it's not for everyone. However on the basis of rational calculation the pain in learning something new is a small part of the total cost of the technology choice and for some people by far not the most relevant question. And it's an advantage in hiring because the D community filters for people who have a tolerance for discomfort upfront. It would be wonderful to be able to wave a wand and make all of life's little frustrations disappear. But in my experience, that's not what is possible - one picks from the choices available and the new ones one thinks up. People have a tendency to think that leadership has more power to just change things then is actually the case. I'm going to be building standard developer images from scratch programmatically. Transform froma Windows ISO into a VM image.Maybe I could open source those scripts and then it's easier to get to the bottom of any install and build problems and one can replicate difficulties.
[Issue 17961] std.uni does not compile with -unittest -dip1000
https://issues.dlang.org/show_bug.cgi?id=17961 Carsten Blüggelchanged: What|Removed |Added Blocks||18585 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=18585 [Issue 18585] Linker error if compiled with -dip1000 --
[Issue 18585] Linker error if compiled with -dip1000
https://issues.dlang.org/show_bug.cgi?id=18585 Carsten Blüggelchanged: What|Removed |Added Keywords||rejects-valid, safe CC||chi...@posteo.net Depends on||17961 --- Comment #1 from Carsten Blüggel --- The origin of errors seems to be, that std.uni is not -dip1000 compilable currently. Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=17961 [Issue 17961] std.uni does not compile with -unittest -dip1000 --
Re: Question over C++ to D conversion
On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote: The second is that mbed uses C++ class's for it's API most of this is just headers such I was wondering if there are any other ways that are known about for translating C++ into D, or accessing C++ libraries. Many Thanks Richard See Gooberman fork of binderoo. It only worked on Windows and X Box before, but now it should work on Linux. That's for C++ talking to D. C# to follow. For conversion of C headers, watch this space. C first, C++ eventually. Might be a talk at Dconf on it. Also see the tool in Visual D, which I haven't yet used myself.
Re: Question over C++ to D conversion
On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote: There's a couple of outstanding things at the moment though The first is the use of BetterC, although from what I can tell DMD now has support for a minimal runtime feature as part of 2.079.0 https://dlang.org/changelog/2.079.0.html#minimal_runtime so hopefully when this makes it's way into LDC I can then make use of it for an Arm MCU for creating class's without the full runtime. https://github.com/ldc-developers/ldc/pull/2587 I'm hoping for that to land soon as well. The minimal runtime features and -betterC do have some overlap, but there are some specific things -betterC does that the minimal runtime doesn't do. See https://dlang.org/spec/betterc.html. At least one such feature is "assert failures are directed to the C runtime library". The minimal runtime has uses for those wishing to port the druntime to a new platform or architecture and do so incrementally. It's also useful for those that may choose to implement minimal subset of runtime features or provide an alternate implementation of a runtime feature for their application. This is especially useful in the embedded domain where there is typically one process running, and you know upfront what features you will need or not need; and you won't have to do the work of porting everything just to get a build. -betterC, on the other hand, is somewhat of a blunt instrument, and removes certain features of the runtime wholesale. With the minimal runtime features, you will be able to create a betterC-like application by simply avoiding features that you haven not implemented in your port of the runtime. That wasn't possible prior to 2.079.0. I was wondering if there are any other ways that are known about for translating C++ into D, or accessing C++ libraries. I'm sorry I don't know of any reliable tool that can create bindings to C++ libraries automatically. Mike
Re: Date range iteration
On Monday, March 12, 2018 02:11:49 Jordan Wilson via Digitalmars-d-learn wrote: > I wanted to iterate through a date range, so I initially tried: > iota(Date(2016,1,1),Date(2018,1,1),dur!"days"(1)); > > That wouldn't compile, which is fair enough I guess. Maybe iota should be made to work, but as present, it basically wants all three of the types it's given to be the same or implicitly convertible to a single type. It can't handle the step being a completely different type. > So I tried a for loop: > for (auto i = Date(2016,1,1); i < Date(2018,1,1); > i+=dur!"days"(1)){} > > That seemed to work fine, but I remember reading "for loops are > bad" somewhere. for loops are just fine - especially if you're just going to loop through all the values and do something to them - but if you have a range, it's a lot more flexible. > So I looked for a range type mechanism, and I > think it's this: > foreach (i; Interval!Date > (Date(2016,1,1),Date(2018,1,1)).fwdRange ( (a) { return > a+dur!"days"(1); })){} > > My question is if the third way is the proper way of stepping > through a period of time? It just seems quite complicated to me. Well, honestly, the range support in std.datetime isn't very good. The core problem that overcomplicates it is that the Interval needs to know which direction you want to iterate in, and then the helper functions tend to need to know it too in order to work properly. Also, the time point type being used also tends to get duplicated a fair bit. So, you end up with annoyingly repetitive code. The helper function intended for this use case is https://dlang.org/phobos/std_datetime_interval.html#everyDuration So, you'd get something more like auto interval = Interval!Date(Date(2016, 1, 1), Date(2018, 1, 1)); auto range = interval.fwdRange(everyDuration!Date(days(1))); But if you're just going to use the range in a foreach loop, then you might as well just use a for loop. All of this extra machinery only really starts being valuable when you start feeding the ranges into range-based functions. For a simple loop, it's overkill. - Jonathan M Davis
Re: core.stdc.stdlib._compare_fp_t and qsort
On Monday, 12 March 2018 at 01:45:54 UTC, Adam D. Ruppe wrote: I just reformatted it but now the difference should be visible: `extern(C)` is missing on your callback. The scope things might make a difference too, but I know for sure extern(C) is necessary on your callback function. I saw the extern(C) and I believe I tried it before my previous post, but dismissed it because I saw no difference in compiler behavior. In any case declaring extern (C) int compar(const (void *) p1, const (void *) p2) { ... // as before } still gives the error: function core.stdc.stdlib.qsort (scope void* base, ulong nmemb, ulong size, extern (C) int function(scope const(void*), scope const(void*)) @system compar) is not callable using argument types (void*, ulong, ulong, extern (C) int function(const(void*) p1, const(void*) p2)) It only went away with extern (C) int compar(scope const (void *) p1, scope const (void *) p2) Could you explain or direct me to something that elucidates why the "scope" qualifiers are needed? And is there something else that is necessary inside compar() or are the "scope"s just for decorative purposes? Joe
[Issue 18000] [scope] auto-generated opAssign not scope aware
https://issues.dlang.org/show_bug.cgi?id=18000 --- Comment #1 from Walter Bright--- Attributes are inferred for the generated opAssign, the result looks like: @nogc ref return @trusted File opAssign(File p) Not sure why scope is not inferred. In any case, the example has problems as well: scope File f; f = File(); The lifetime of File() is less than that of f, so this example should fail to compile for that reason. https://issues.dlang.org/show_bug.cgi?id=17977 addresses that. --
Re: Question over C++ to D conversion
On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote: I was wondering if there are any other ways that are known about for translating C++ into D, or accessing C++ libraries. If you have access to a Windows box, this might help get you there: http://rainers.github.io/visuald/visuald/CppConversion.html
Date range iteration
I wanted to iterate through a date range, so I initially tried: iota(Date(2016,1,1),Date(2018,1,1),dur!"days"(1)); That wouldn't compile, which is fair enough I guess. So I tried a for loop: for (auto i = Date(2016,1,1); i < Date(2018,1,1); i+=dur!"days"(1)){} That seemed to work fine, but I remember reading "for loops are bad" somewhere. So I looked for a range type mechanism, and I think it's this: foreach (i; Interval!Date (Date(2016,1,1),Date(2018,1,1)).fwdRange ( (a) { return a+dur!"days"(1); })){} My question is if the third way is the proper way of stepping through a period of time? It just seems quite complicated to me. Thanks, Jordan
[Issue 18591] DMD should allow access to mixin template declarations
https://issues.dlang.org/show_bug.cgi?id=18591 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/786bdb338a64fa52b24ab515edf6706b259447de Fix Issue 18591 - Allow getting type from template declarations. --
Re: core.stdc.stdlib._compare_fp_t and qsort
On Mon, Mar 12, 2018 at 01:04:06AM +, Joe via Digitalmars-d-learn wrote: > On Sunday, 11 March 2018 at 23:26:04 UTC, Stefan Koch wrote: > > You have to pass a pointer to the function. > > Otherwise it'll be a parenthsis-less call. > > use : qsort(recs, num_recs, (Record *).sizeof, ); > > After passing a pointer, getting some other error messages, I changed > the call to > > qsort(cast(void *)recs, num_recs, cast(size_t)(Record *).sizeof, > ); > > and the latest error is: > > Error: function core.stdc.stdlib.qsort (scope void* base, ulong nmemb, ulong > size, extern (C) int function(scope const(void*), scope const(void*)) > @system compar) is not callable using argument types (void*, ulong, ulong, > int function(const(void*) p1, const(void*) p2)) > > I fail to see which argument is causing the problem now. [...] I wonder if the problem is because qsort expects a C linkage function (`extern (C) int function(...)`), but you're passing a D linkage (i.e., native) function to it. You can't do that, because the order of arguments in a D linkage function may differ from a C linkage function, and could potentially cause a subtle bug if you're not expecting the arguments in a different order. (I actually ran into this myself, in a different context where there was no type enforcement like there is here, and it took me a long time to track down the problem.) If indeed this is the problem, try adding `extern (C)` to your D function to make it compatible with C linkage, and that should do the trick. I think. T -- If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton
Re: core.stdc.stdlib._compare_fp_t and qsort
On Monday, 12 March 2018 at 01:04:06 UTC, Joe wrote: and the latest error is: D's error messages are so bad and shouldn't be hard to fix. It kills me that basic every-day functionality like this isn't a priority to the core devs. I even wrote a patch myself that would call this out but it didn't fit the code style so rejected. Ugh. But behold: (scope void* base, ulong nmemb, ulong size, extern (C) int function(scope const(void*), scope const(void*)) @system compar) (void*, ulong, ulong, int function(const(void*) p1, const(void*) p2)) I just reformatted it but now the difference should be visible: `extern(C)` is missing on your callback. The scope things might make a difference too, but I know for sure extern(C) is necessary on your callback function.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. As an aside, I had to translate a special-use decompression algorithm from C# to D, and it was a near seamless transition. I'm trying to persuade some of my C# compatriots to try D because of that experience.
Question over C++ to D conversion
Hi, I'm sure this question has been asked a few times before But I'm currently looking at something that will convert Cpp code to D I've recently setup a proof of concept demo which uses mbed for an embedded LPC1769 Arm board This is just a test, but I've recently managed to get debugging working across both C and D files at the same time. This means single stepping code on a remotely attached Arm board in VSCode, while being able to inspect registers with an svd file https://github.com/grbd/GBD.Dlang.MbedBlinkyTest There's a couple of outstanding things at the moment though The first is the use of BetterC, although from what I can tell DMD now has support for a minimal runtime feature as part of 2.079.0 https://dlang.org/changelog/2.079.0.html#minimal_runtime so hopefully when this makes it's way into LDC I can then make use of it for an Arm MCU for creating class's without the full runtime. https://github.com/ldc-developers/ldc/pull/2587 These were also mentioned in a separate thread. * https://bitbucket.org/timosi/minlibd * https://github.com/JinShil/stm32f42_discovery_demo * https://github.com/kubo39/stm32f407discovery The second is that mbed uses C++ class's for it's API most of this is just headers such as DigitalOut.h https://github.com/ARMmbed/mbed-os/blob/master/drivers/DigitalOut.h So ideally I've been looking for something that can translate those headers into Dlang so they can be used there instead. * The first two utils I've found were DStep and htod, however they seem to only hand C https://github.com/jacob-carlborg/dstep * I discovered some examples of libraries over here https://github.com/D-Programming-Deimos * There's CPP2D but the last update was around 2016 https://github.com/lhamot/CPP2D * Calypso seems to be a Fork of LDC, but I think it might be a while before 2.079.0 makes it in. https://github.com/Syniurge/Calypso One possibility I might look into is a D backend for CppSharp if I can figure it out, since I'm familiar with C#. * https://github.com/mono/CppSharp I was wondering if there are any other ways that are known about for translating C++ into D, or accessing C++ libraries. Many Thanks Richard
Re: core.stdc.stdlib._compare_fp_t and qsort
On Sunday, 11 March 2018 at 23:26:04 UTC, Stefan Koch wrote: You have to pass a pointer to the function. Otherwise it'll be a parenthsis-less call. use : qsort(recs, num_recs, (Record *).sizeof, ); After passing a pointer, getting some other error messages, I changed the call to qsort(cast(void *)recs, num_recs, cast(size_t)(Record *).sizeof, ); and the latest error is: Error: function core.stdc.stdlib.qsort (scope void* base, ulong nmemb, ulong size, extern (C) int function(scope const(void*), scope const(void*)) @system compar) is not callable using argument types (void*, ulong, ulong, int function(const(void*) p1, const(void*) p2)) I fail to see which argument is causing the problem now. Joe
[Issue 17959] [DIP1000] Can store scope delegate in non-scope member
https://issues.dlang.org/show_bug.cgi?id=17959 Walter Brightchanged: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- https://github.com/dlang/dmd/pull/8008 --
[Issue 17932] [scope] __traits(compiles, stmt) cannot test scope violations
https://issues.dlang.org/show_bug.cgi?id=17932 Walter Brightchanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Walter Bright --- Adding @safe to the lambda: void test() @safe { int var; scope int* p; static int* escape; static assert(!__traits(compiles, () @safe { escape = p; })); //escape = p; } and it compiles without error. The lambda does not inherit @safe from the function. Perhaps it should, but that would be an enhancement request, and would possibly break existing code. It should be the subject of a separate issue. --
Re: core.stdc.stdlib._compare_fp_t and qsort
On Sunday, 11 March 2018 at 23:12:30 UTC, Joe wrote: I'm getting a compiler error in a qsort() call as follows: qsort(recs, num_recs, (Record *).sizeof, compar); Record is a struct, recs is a fixed array of pointers to Record's and num_recs is a size_t that holds the number of valid records. compar is this: int compar(const void *p1, const void *p2) { import core.stdc.string : strcmp; const Record **rp1 = cast(Record **)p1; const Record **rp2 = cast(Record **)p2; return strcmp((*rp1).name.ptr, (*rp2).name.ptr); } The error is: Error: function testd.compar (const(void*) p1, const(void*) p2) is not callable using argument types () I don't quite understand what those parentheses mean: is it implying "no arguments" and if so, where would one provide arguments? Joe You have to pass a pointer to the function. Otherwise it'll be a parenthsis-less call. use : qsort(recs, num_recs, (Record *).sizeof, );
core.stdc.stdlib._compare_fp_t and qsort
I'm getting a compiler error in a qsort() call as follows: qsort(recs, num_recs, (Record *).sizeof, compar); Record is a struct, recs is a fixed array of pointers to Record's and num_recs is a size_t that holds the number of valid records. compar is this: int compar(const void *p1, const void *p2) { import core.stdc.string : strcmp; const Record **rp1 = cast(Record **)p1; const Record **rp2 = cast(Record **)p2; return strcmp((*rp1).name.ptr, (*rp2).name.ptr); } The error is: Error: function testd.compar (const(void*) p1, const(void*) p2) is not callable using argument types () I don't quite understand what those parentheses mean: is it implying "no arguments" and if so, where would one provide arguments? Joe
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 --- Comment #11 from Rainer Schuetze--- BTW: AFAIK -dip1000 is only supposed to affect @safe code, but there is no @safe in the original test cases. --
Re: How do you call an eponymous template that has a secondary template arg?
On Sunday, 11 March 2018 at 13:44:38 UTC, Basile B. wrote: The first version works here: ``` template aliasOf(T) { enum aliasOf(alias a) = is(typeof(a) == T); } string s; pragma(msg, allSatisfy!(aliasOf!string, s, "string")); ``` I can see that my description was a little confusing, sorry about that, I meant to ask how would you call that without using the allSatisfy meta template. If I were to call it as a stand alone, ie: writeln(aliasOf!stringtemplate?>); I hope that makes it clearer. Now on the fact that what is done is correct is another story. If the literal passed is supposed to be a type then it's clearly wrong. You'd have to mix it: ``` template aliasOf(T) { template aliasOf(alias a) { mixin("alias A = " ~ a ~ ";"); enum aliasOf = is(A == T); } } alias myString1 = string; alias myString2 = string; pragma(msg, allSatisfy!(aliasOf!string, "myString1", "myString2")); ``` Aye, I see what you mean, but it is supposed to be a literal of a specific type. I.e. 3, "some string", SomeType(), etc. So aliasOf!int.aliasOf!3 // true Also, if I define it like this: template aliasOf(T) { auto aliasOf(U)(U) { return is(U == T); } } Then at least I can call it like: writeln(aliasOf!int(3)); // prints true But then I can't do: allSatisfy!(aliasOf!int, 3) I guess because it's a function now and not a template anymore so can't be used by allSatisfy.
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 Rainer Schuetzechanged: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Rainer Schuetze --- I didn't mean to change the status, but reopening is probably appropriate. --
Re: DConf hotel poor QoS
On Friday, 9 March 2018 at 15:26:24 UTC, Luís Marques wrote: I'm not impressed with the conference hotel so far. Here's a summary of my interactions with them: [...] It might as well be your are talking with different employees changing shift. "The nightmare in customer support"... and they don't have a system to track previous discussions easily.
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #9 from ag0ae...@gmail.com --- (In reply to Rainer Schuetze from comment #8) > As with the modified reduced test case with @safe, this is still crashing > for me (Win32 and Win64 with git HEAD). Checking the disassembly for > compiling with -dip1000 it doesn't generate the closure that it is > generating without the switch. If it still crashes, did you mean to reopen this issue? (You changed it from WORKSFORME to FIXED.) --
[Issue 18594] X is not an lvalue should have a better error message
https://issues.dlang.org/show_bug.cgi?id=18594 Sebchanged: What|Removed |Added Summary|constant 1 is not an lvalue |X is not an lvalue should |should have a better error |have a better error message |message | --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 Rainer Schuetzechanged: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #8 from Rainer Schuetze --- > Fixing the code with @safe and @trusted: As with the modified reduced test case with @safe, this is still crashing for me (Win32 and Win64 with git HEAD). Checking the disassembly for compiling with -dip1000 it doesn't generate the closure that it is generating without the switch. --
[Issue 18594] constant 1 is not an lvalue should have a better error message
https://issues.dlang.org/show_bug.cgi?id=18594 --- Comment #1 from Seb--- (PR incoming) --
[Issue 18594] New: constant 1 is not an lvalue should have a better error message
https://issues.dlang.org/show_bug.cgi?id=18594 Issue ID: 18594 Summary: constant 1 is not an lvalue should have a better error message Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com --- void main() { assert(1 = 2); } --- currently errors with "foo.d(2): Error: constant 1 is not an lvalue". The error message should be better: (1) not mention lvalue and (2) suggesting `==`. --
[Issue 17764] [scope][DIP1000] Escape checker defeated by composition transformations
https://issues.dlang.org/show_bug.cgi?id=17764 Walter Brightchanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Walter Bright --- The following remain: --- @safe: struct Context0x0 { char[] str; } struct Parent0x1 { Context0x0 c; } struct Parent0x2 { Context0x0[1] csa; } struct Parent0x3 { Context0x0[] csl; } struct Parent0x4 { Context0x0*cp; } struct Parent0x5 { Parent0x1 p1; } struct Parent0x6 { Parent0x5 p5; } struct Parent0x7 { Parent0x6 p6; } struct Parent0x8 { Parent0x2[1]* p2; } struct Parent0x9 { Parent0x8[1] p8; } struct Parent0xA { Parent0x9[1] p9; } struct Parent0xB { Parent0x4* p4; } struct Parent0xC { Parent0xB* pb; } struct Parent0xD { Parent0xC* pc; } char[] global; void use0x2(scope char[]* arr) { global = *arr; // NG - accepts invalid } void use0x9(scope ref Parent0x4 p) { global = p.cp.str; // NG - accepts invalid } void use0xB(scope ref Parent0xA p) { global = (*p.p9[0].p8[0].p2)[0].csa[0].str; // NG - accepts invalid } void use0xC(scope ref Parent0xD p) { global = p.pc.pb.p4.cp.str; // NG - accepts invalid } --- All of them are instances of transitive scope, but scope is not transitive. Not compiler bugs. --
[Issue 18593] New: std.datetime.stopwatch.benchmark shouldn't optimize away its functions
https://issues.dlang.org/show_bug.cgi?id=18593 Issue ID: 18593 Summary: std.datetime.stopwatch.benchmark shouldn't optimize away its functions Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: pull Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com See: https://github.com/dlang/phobos/pull/5416 --
[Issue 15653] IFTI fails for immutable parameter
https://issues.dlang.org/show_bug.cgi?id=15653 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15653] IFTI fails for immutable parameter
https://issues.dlang.org/show_bug.cgi?id=15653 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d68e181bda060f8e61253620695a3aadf0ad1093 Fix issue 15653 - IFTI fails for immutable parameter https://github.com/dlang/dmd/commit/5fa45d1a355b5bd24caaeddf71b21d94561c3174 Add links to bugzilla for issue 15653 https://github.com/dlang/dmd/commit/25fbcbe2baaf085e679bc281954b208e076d7471 Merge pull request #7977 from JinShil/fix_15653 Fix issue 15653 - IFTI fails for immutable parameter merged-on-behalf-of: Sebastian Wilzbach--
[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.
https://issues.dlang.org/show_bug.cgi?id=17512 --- Comment #5 from Walter Bright--- https://github.com/dlang/dmd/pull/8001 --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 Walter Brightchanged: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Walter Bright --- Fixing the code with @safe and @trusted: --- module test; @safe: struct Event9834 { @safe: void delegate() dg; void set(void delegate() @safe h) pure { dg = h; } // AV occurs void call() { dg(); } } void main() { Event9834 ev; auto a = new class { Object o; this() @safe { o = new Object; ev.set(() @trusted { o.toString(); }); } }; ev.call(); } --- and it compiles and runs without error, with or without -dip1000. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #35 from Walter Bright--- (In reply to Shachar Shemesh from comment #33) > You cannot be notified when the object > moves, and once it does, the global linked list will get completely > corrupted. That is correct, and you are right to be concerned about it. However, from a pragmatic point of view, the compiler cannot move objects that have external pointers to them (unless it can unambiguously find them all and update them). This is why, for example, there is an API in the GC to register pointers to objects that are unknown to the GC. Why was it moving the stack allocated objects in these examples? Because when it went out of scope, it is safe to assume that there are no extant pointers to it. This is why the compiler (now) complains when the code registers a pointer to the stack object. Of course, making the code @trusted enables code like this to be written, leaving it up to the programmer to ensure the safety. But there's another wrinkle. With RVO (Return Value Optimization), if the stack object is returned, and it is not returned in registers, it is actually not returned. It is allocated in the caller's stack frame! and is not moved. This is now the case with all the examples you've provided. So, to guarantee RVO: 1. the object must be returned on the stack, not in registers. This can be tested as shown in the documentation: https://dlang.org/spec/traits.html#isReturnOnStack Generally speaking, a struct that is larger than two registers, or is not POD (Plain Old Data), will return on the stack and not in registers. 2. use only one return statement in the function. Having multiple returns can defeat RVO. 3. do not pass the object as a parameter to other functions, as the compiler may 'move' it onto the parameter stack if there are no more references to the object. If you must pass it as a parameter, pass it by `ref`. Objects can also be constructed directly into their final destination by passing them as `out` parameters. Obviously, I am not familiar with your code and usage patterns. But the above ought to offer some hope (!) for getting your code working properly. If there are more pernicious problems with moving that aren't covered by this, please let me know. Perhaps I can think of a solution. --
[Issue 18024] checkedint.Abort should be @safe
https://issues.dlang.org/show_bug.cgi?id=18024 Sebchanged: What|Removed |Added Summary|checkedint.Warn should be |checkedint.Abort should be |@safe |@safe --
[Issue 17423] pointer assignment to `this` in member function is not accounted for
https://issues.dlang.org/show_bug.cgi?id=17423 --- Comment #8 from Walter Bright--- (In reply to Walter Bright from comment #7) > https://github.com/dlang/dmd/pull/7999 For this to work, -dip1000 must be used. --
[Issue 18519] freebsd 11 + phobos + curl, timing out
https://issues.dlang.org/show_bug.cgi?id=18519 Sebchanged: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Seb --- REOPENED as I just tested the PR with https://github.com/dlang/phobos/pull/6264 and the problem still seems to be existent. --
[Issue 18592] Associative array assignment with a destructor should be @safe if the destructor is @safe
https://issues.dlang.org/show_bug.cgi?id=18592 Sebchanged: What|Removed |Added Keywords||safe --
[Issue 18592] New: Associative array assignment with a destructor should be @safe if the destructor is @safe
https://issues.dlang.org/show_bug.cgi?id=18592 Issue ID: 18592 Summary: Associative array assignment with a destructor should be @safe if the destructor is @safe Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com cat > main.d << EOF void main() @safe { struct ThrowingElement { int i; ~this() { assert(1); } } ThrowingElement[int] aa; aa[0] = ThrowingElement(0); } EOF The problem is that the generated opAssign is @system: ref return @system ThrowingElement opAssign(ThrowingElement p) { (ThrowingElement __swap2 = void;) , __swap2 = this , this = p , __swap2.~this(); return this; } --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 --- Comment #6 from Rainer Schuetze--- > Adding more @safe Makes it compile and run successfully. Your safe code also fails with -dip1000. (tried on Windows/OMF). --
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote: I assume you are using Windows? Yes, I'm the typical lazy convenient Windows user scared of the terminal window. Setup on Posix is really simple. git clone all three repos + run make. I am happy for Posix users. Theoretically the process is the same on Windows. There's also a bash script to automate this: https://github.com/dlang/tools/blob/master/setup.sh This will need Linux subsystem as a Windows feature installed. Bash scripts do not work on Windows. Or other third party applications that are not listed as prerequisites on wiki. From what I heard it's a bit tricky on Windows. I only tried with wine and that worked out-of-the-box for me. Execute the DMD installer, set PATH, DM_HOME and HOST_DC and then run the win32 makefiles work fine. make -fwin32.mak release Error: don't know how to make 'release' Ok, let's skip this, make it without "release". Now test it: cd test make all -j8 Command error: undefined switch '-j8' What could be done from your perspective to make the setup easier? From my perspective I would like to have an working setup, not necessary easier. But if interested, to contribute to C# compiler, you just need to open roslyn.sln in Visual Studio, make your modification, run the test suite, commit, you're done.
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 --- Comment #5 from Rainer Schuetze--- > This is because 'scope' for delegates now means something with dip1000, it > means the delegate must not escape. There is no "scope" in the test cases. I suspect it is falsely inferred. --
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ Wow, we got more than 500 responses so far. A huge thank you already! The survey is still open for a few more days, so if you want to make your opinion count now is the last chance.
[Issue 18549] name gets overwritten in template definition
https://issues.dlang.org/show_bug.cgi?id=18549 Johannes Nordhoffchanged: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #3 from Johannes Nordhoff --- ah, sorry, i get it. sorry --
[Issue 18591] New: DMD should allow access to mixin template declarations
https://issues.dlang.org/show_bug.cgi?id=18591 Issue ID: 18591 Summary: DMD should allow access to mixin template declarations Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com https://github.com/dlang/dmd/pull/7973 --
[Issue 18549] name gets overwritten in template definition
https://issues.dlang.org/show_bug.cgi?id=18549 Johannes Nordhoffchanged: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from Johannes Nordhoff --- > > the compiler was using the same name for multiple > > template-definitions. > > I don't understand what you mean by this. If you still think the compiler > should do something differently here, please feel free to reopen. > yeah, the error message should say: sth.d(11): Error: sth.tmpl called with argument types () matches both: sth.d(6): sth.tmpl!(SS).tmpl() and: sth.d(7): sth.tmpl!(tt).tmpl() but instead it says: sth.d(11): Error: sth.tmpl called with argument types () matches both: sth.d(6): sth.tmpl!(SS).tmpl() and: sth.d(7): sth.tmpl!(SS).tmpl() --
[Issue 18110] most of phobos should be @safe-ly useable
https://issues.dlang.org/show_bug.cgi?id=18110 Issue 18110 depends on issue 18158, which changed state. Issue 18158 Summary: std.file.getcwd should be usable in @safe https://issues.dlang.org/show_bug.cgi?id=18158 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18178] std.path should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18178 Issue 18178 depends on issue 18158, which changed state. Issue 18158 Summary: std.file.getcwd should be usable in @safe https://issues.dlang.org/show_bug.cgi?id=18158 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18158] std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18158] std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/767d1c51d4ae2e24c9d1752db4c1f1b881a3b658 Fix Issue 18158 - std.file.getcwd should be usable in @safe https://github.com/dlang/phobos/commit/ba11d630a02345fa634d098694273f145fc5428f Merge pull request #6252 from JackStouffer/issue18158 Fix Issue 18158 - std.file.getcwd should be usable in @safe merged-on-behalf-of: Jack Stouffer--
[Issue 17819] static foreach segfaults on __traits(allMembers)
https://issues.dlang.org/show_bug.cgi?id=17819 bitter.ta...@gmx.com changed: What|Removed |Added CC||bitter.ta...@gmx.com --- Comment #3 from bitter.ta...@gmx.com --- There's a stack overflow in Dsymbol's _foreach, every time it recurses into a AttribDeclaration (such as the `static foreach') the stack gets deeper until it explodes. --
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). Don't forget that "open source" != non-profit. For the C# compiler there's a dedicated team of full-time developers. Also to be fair, the activity on dmd isn't that low either though the last week was a one with low-traffic: https://github.com/dlang/dmd/pulse Typically ~40 PRs get merged per PR for dmd alone: https://auto-tester.puremagic.com/chart.ghtml?projectid=1 With druntime + phobos, it's a lot more. The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. I assume you are using Windows? Setup on Posix is really simple. git clone all three repos + run make. There's also a bash script to automate this: https://github.com/dlang/tools/blob/master/setup.sh From what I heard it's a bit tricky on Windows. I only tried with wine and that worked out-of-the-box for me. Execute the DMD installer, set PATH, DM_HOME and HOST_DC and then run the win32 makefiles work fine. What could be done from your perspective to make the setup easier?
[Issue 18126] [internal] Reduce number of turned off warnings.
https://issues.dlang.org/show_bug.cgi?id=18126 Iain Buclawchanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- This was implemented in https://github.com/dlang/dmd/pull/7958 --
[Issue 18182] std.uri should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18182 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9d44d7c13fc312bc39669df441f8b931789471c1 Fix Issue 18182 - std.uri should be usable in @safe https://github.com/dlang/phobos/commit/8ec15a80ff844bd3457939cb4662952f736e7f50 Merge pull request #6256 from JackStouffer/issue18182 Fix Issue 18182 - std.uri should be usable in @safe merged-on-behalf-of: Jack Stouffer--
[Issue 18182] std.uri should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18182 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18110] most of phobos should be @safe-ly useable
https://issues.dlang.org/show_bug.cgi?id=18110 Issue 18110 depends on issue 18182, which changed state. Issue 18182 Summary: std.uri should be usable in @safe https://issues.dlang.org/show_bug.cgi?id=18182 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Embedded Linux really needs Dlang for the IOT market
On Friday, 9 March 2018 at 03:09:16 UTC, dangbinghoo wrote: hi all, I think the D community should make more effort to make Dlang more easier to use on embedded Linux(mostly are arm and mips, powerpc). My IOT server works in D. I use it for home heating and also for my room lamp. Single devices (sensor) are written in C but I hope d+better c could replace it.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. I contributed to phobos for the first time for the release 2.079.0. Experience was smooth and also I learnt many new things from the review comments. I was able to follow wiki page to compile phobos or compile one specific module. Please let us know the issue faced, so that wiki can be improved.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos.
Re: Article: Why Const Sucks
On Thursday, 8 March 2018 at 15:13:09 UTC, Steven Schveighoffer wrote: On 3/8/18 9:58 AM, joe wrote: On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: /snip May be not entirely related, but a little gotcha. given: interface XY {} class Foo: XY {} class Bar: XY {} void doSomething(in XY sth) { auto foo = cast(Foo)sth; // error in @safe code } But the compiler doesn't emit a warning that const got cast away in @system code. Since @system is the default setting and casting const away is by definition undefined behavior, there should be some feedback. If you cast away const in C++ you need to be explicit about it by using const_cast, documents the intention rather than D's swiss-army-cast. This is a problem with the cast system, not const. ... I figured. Sorry for off topic. ... D has one cast mechanism, and it's used to: a) dynamic type cast b) hook user-supplied opCast c) enter undefined behavior by casting away const/immutable. I really think we should have a separate mechanism for a and b, as they are far less dangerous than c. std.conv.to does this as well, ... Thanks for pointing this out. ...but the language should have some safeguards against using "safe casting" incorrectly. -Steve yes, that's what I was aiming for :) This one got me because I assumed, with all the improved security in place, D would never silently do such a thing... Assumptions, right? ...the root of all evil. I should know better. haha. Anyways, thanks for the insight and have a nice Sunday.
Re: Inner Classes vs. Inner Structs
On Sunday, March 11, 2018 13:19:39 Mike Franklin via Digitalmars-d-learn wrote: > This works: > > ``` > class S { > int n, m; > int sum() { return n + m; } > Inner!(sum) a; > > class Inner(alias f){ > auto get() { > return f(); > } > } > } > ``` > > This doesn't: > > ``` > struct S { > int n, m; > int sum() { return n + m; } > Inner!(sum) a; > > struct Inner(alias f){ > auto get() { > return f(); // Error: this for sum needs to be type S > not type Inner!(sum) > } > } > } > ``` > > The only difference between the two is one one uses classes, the > other uses structs. My question is, under the current semantics > of D, shouldn't the two work the same? That is, shouldn't the > inner struct in the second example have an implicit context > reference to the outer struct? Is this a bug? No, it's on purpose, and the only reason that non-static, nested classes have access to the class they're declared in is for compatibility with Java, which doesn't have structs. Also, I suspect that if D were being designed now, it would treat nested classes the same as nested structs rather than treating nested structs like it currently does nested classes. Some of D's design has a number of Java-isms because of when D was first started and the fact that it didn't have some of features that it has now. Certainly, if we included the feature at this point if we were redesigning the language, I expect that it would only be to make porting Java code easier. Regardless, changing the current behavior would break code, so I doubt that it's going to change. IIRC, DWT relies on the behavior with classes (since it's code ported from Java), and while I question that all that much D code outside of DWT takes advantage of non-static, nested classes, I suspect that having non-static, nested structs suddenly act differently from static, nested structs would break a fair bit of D code. There is of course no way to know how much code would break with either change, but I doubt that Walter would agree to the potential code breakage in either direction. - Jonathan M Davis
[Issue 18590] New: nothrow constructor call still type-checks destructor for purity
https://issues.dlang.org/show_bug.cgi?id=18590 Issue ID: 18590 Summary: nothrow constructor call still type-checks destructor for purity Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@dawg.eu cat > bug.d << CODE extern(C) int printf(const char*, ...); struct F { static F create() pure nothrow { return F(1); } this(int) pure nothrow { } ~this() { printf("~this\n"); } } CODE dmd -c bug Error: pure function 'bug.F.create' cannot call impure function 'bug.F.~this' Apparently happens because `F(1)` is lowered to `(tmp = F(1)),tmp` internally. https://github.com/dlang/dmd/blob/93804714c4091a8d867c09ca7b5bf332acb34dfb/src/dmd/expression.d#L3931 --
Re: UFCS in generic libraries, silent hijacking, and compile errors.
On Sunday, March 11, 2018 08:39:54 aliak via Digitalmars-d-learn wrote: > On Saturday, 10 March 2018 at 23:00:07 UTC, Jonathan M Davis > > issue in practice. That doesn't mean that it's never a problem, > > but from what I've seen, it's very rarely a problem, and it's > > easy to work around if you run into a particular case where it > > is a problem. > > Ya, it's easy to work around but the caveat there is you need to > realize it's happening first, and add that to that it's "rarely a > problem" and well ... now it seems scary enough for this to > mentioned somewhere I'd say. You're talking about a situation where you used a function whose parameters match that of a member function exactly enough that a member function gets called instead of a free function. That _can_ happen, but in most cases, there's going to be a mismatch, and you'll get a compiler error if the type defines a member function that matches the free function. I don't think that I have ever seen that happen or ever seen anyone complain about it. The only case I recall along those lines was someone who was trying to use a free function that they'd decided to call front instead of something else, and it had parameters beyond just the input range, so that programmer got compilation errors when they tried to use it in their range-based functions. I think that this is really a theoretical concern and not a practical one. Certainly, it's really only going to potentially be an issue in library code that gets used by a ton of folks with completely unexpected types. If it's in your own code, you're usually well aware of what types are going to be used with a generic function, and proper testing would catch the rare case where there would be a problem. If you're really worried about it, then just don't use UFCS, but for better or worse, it seems to be the case that the vast majority of D programmers use UFCS all the time and don't run into problems like this. > > The one case that I am aware of where best practice is to avoid > > UFCS is with put for output ranges, but that has nothing to > > with your concerns here. Rather, it has to do with the fact > > that std.range.primitives.put has a lot of overloads for > > handling various arguments (particularly when handling ranges > > of characters), and almost no one implements their output > > ranges with all of those overloads. So, if you use put with > > UFCS, you tend to run into problems if you do anything other > > than put a single element of the exact type at a time, whereas > > the free function handles more cases (even if they ultimately > > end up calling that member function with a single argument of > > the exact type). We probably shouldn't have had the free > > function and the member function share the same name. > > Oh, can you share a short example here maybe? Not sure I followed > completely > > Is it basically: > > // if r is output range > > r.put(a, b) // don't do this? > > put(r, a, b) // but do this? > > (Cause compilation error) Essentially yes, though you're passing too many arguments to put. There are cases where put(output, foo) will compile while output.put(foo) will not. In particular, std.range.primitives.put will accept both individual elements to be written to the output range and ranges of elements to be written, whereas typically, an output range will be written to only accept an element at a time. It's even more extreme with output ranges of characters, because the free function put will accept different string types and convert them, and even if the programmer who designed the output range added various overloads to put for completeness, it's enough extra work to deal with all of the various character types that they probably didn't. And put also works with stuff like delegates (most frequently used with a toString that accepts an output range), which don't have member functions. So, if you write your generic code to use the member function put, it's only going to work with user-defined types that define the particular overload(s) of put that you're using in your function, whereas if you use the free function, you have more variety in the types of output ranges that your code works with, and you have more ways that you can call put (e.g. passing a range of elements instead of a single element). > How about if it's not part of the overload set, but is looked up > if the function does not exist in the overload set. What would > the problems there be? > > Basically I don't see a reason why we wouldn't want the following > to work: > > struct S { void f() {} } > void f(S s, int i) {} > S().f(3); // error So, are you complaining that it's an error, or you want it to be an error? As it stands, it's an error, because as far as the compiler is concerned, you tried to call a member function with an argument that it doesn't accept. If you want that code to work, then it would have to add the free function to the overload set while somehow leaving out the overloads
Re: D for microservices
On 2018-03-11 12:10, Tamas wrote: Simple Vibe.d app talking to Redis, packed into docker containers: https://github.com/tam4s/hello-redis The takeaway is that I could not use Alpine as a host image, because I could not build the app statically on ubuntu. warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking It's just a warning. If you're not using "dlopen" or any of your dependencies you can just ignore the warning. -- /Jacob Carlborg
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote: I am sure that lots of D members will be quick to point out, that C# is run by a commercial company and D has only open source contributors. Now why did you not contribute! /sarcasm I'd like to point out, that C# is run by a commercial company and D has only open source contributors. For that matter, so is Rust (a 1/2 billion $ organisation, at least), run by sjw's who will 'attack' (as opposed to 'point out') anyone that speaks out against anything. As for cross platform, have you tried running Rust in Windows XP? Anyway.. I'm going back to the sandbox, to play with my own toys.
[Issue 18537] Cannot pass absolute path to coverage options
https://issues.dlang.org/show_bug.cgi?id=18537 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/feb6e9b2f035f2b564765120e6fb794abfd53622 fix Issue 18537 - Cannot pass absolute path to coverage options allow DRT arguments to include '=' or ':', splitting is done by ' ' https://github.com/dlang/druntime/commit/ab14e9af2b9f4bbea00d543fe229047ede4dd909 Merge pull request #2120 from rainers/issue18537 fix Issue 18537 - Cannot pass absolute path to coverage options --
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote: With the usual response here: "Why do you not fix it yourself or pay for it". Maybe because most people who come want to use the tools and be productive and not spend their time fixing up those tools. I've never seen anyone write that. Most likely you saw someone post something that looks similar, but has a dramatically different meaning. The usual response is "If you want something done, you're going to have to do it yourself or pay someone to do it for you, or else it won't get done." Its a mentality issue that some do not get here. In order to grow you need consumers for your product. If you force or whine to them to fix the issues, they leave. When they leave you lose potential growth. That loss in growth means losing potential members that can fix and want to fix the issues. And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for.
Re: Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux
On Sunday, 11 March 2018 at 12:41:28 UTC, Johan Engelen wrote: Kai has been working recently [1] on updating LDC 0.17.x (ltsmaster) to work with LLVM 6, PowerPC, AArch64, ... You may want to take advantage of that activity to get better bootstrap compiler support for your platforms. For example by filing bug reports, or better: helping out with testing and fixing things ;-) Sure thing. Guix can support multiple versions of LLVM and build against those, so you can inject different dependencies (read versions of LLVM) in the dependency graph. I am quite keen to use the latest for my tools.
Re: How do you call an eponymous template that has a secondary template arg?
On Sunday, 11 March 2018 at 12:05:56 UTC, aliak wrote: Eg: template aliasOf(T) { enum aliasOf(alias a) = is(typeof(a) == T); } The use case for this is for std.meta.allSatisfy for variadic args, i.e. template T(values...) if (allSatisfy!(aliasOf!string, values) { ... } But how do you call that template otherwise? I've tries: * aliasOf!int!"string" // multiple ! arguments are not allowed * (aliasOf!int)!"string" // error c-style cast * aliasOf!int.aliasOf!"string" // template isAliasOf(alias a) does not have property 'isAliasOf I can work around this by: template typeOf(T) { enum isAliasedBy(alias a) = is(typeof(a) == T); } and then do: template T(values...) if (allSatisfy!(typeOf!string.isAliasedBy, values) { ... } But I like the readability of the former better if there's a way to achieve it? Cheers - Ali The first version works here: ``` template aliasOf(T) { enum aliasOf(alias a) = is(typeof(a) == T); } string s; pragma(msg, allSatisfy!(aliasOf!string, s, "string")); ``` Now on the fact that what is done is correct is another story. If the literal passed is supposed to be a type then it's clearly wrong. You'd have to mix it: ``` template aliasOf(T) { template aliasOf(alias a) { mixin("alias A = " ~ a ~ ";"); enum aliasOf = is(A == T); } } alias myString1 = string; alias myString2 = string; pragma(msg, allSatisfy!(aliasOf!string, "myString1", "myString2")); ```
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. Most people do not have issues with the core language of D. You can come from any of the above mentioned languages ( like C, C++, Rust, PHP, Python, Nim, ... ) and get going with D. That is what attracted me in the first place. The language looks good but the moment you actually start using D its issue after issue. With the usual response here: "Why do you not fix it yourself or pay for it". Maybe because most people who come want to use the tools and be productive and not spend their time fixing up those tools. Its a mentality issue that some do not get here. In order to grow you need consumers for your product. If you force or whine to them to fix the issues, they leave. When they leave you lose potential growth. That loss in growth means losing potential members that can fix and want to fix the issues. One can call it selfish but every language is based upon this principle. No growth and community of lots of selfish users means no other members to fix the issues. It is the 9 Circles of Hell. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. +1! It has the language mostly right but its everything around it that is simply a mess. When one compares that to Rust. They are not having constant discussion about replacing cargo ( as dub in D has issues ). They do not need to have multiple documentation generators. The cross platform is simple and fast. Same applies to Go. And C# ... Resources simple are more focused and enhance the whole platform as such. D is like a children sandbox where everybody is playing with their own toys. So when other complain about the mess of the playground, the responds by some is just as typical. The problem is that D stagnates and in the same time C# evolves. I am sure that lots of D members will be quick to point out, that C# is run by a commercial company and D has only open source contributors. Now why did you not contribute! /sarcasm Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a lot of D concepts were introduced in the language: local functions, '_' as digit separator, binary literals, ref returns, tuples, templates, immutability. Guess what the next version of C# has on the table: slices. Yep ... Things are moving faster in the .net camp thanks to the focus on .net Core and the RyuJit. Here is a fun one, with Blazer now being part of the official .net. https://github.com/aspnet/blazor Blazer = C# code runable in the browser using WebAssembly. In the same time, D delegates new features (and sometime existing ones) to library implementation, instead of assume them in the language syntax. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. Personally i am waiting to see CoreRT finalized: https://github.com/dotnet/corert -> CppCodeGen/C++ -> RyuJIT codegen -> Webasm Its already working and getting better by the day. Other languages are moving forwards at blazing speeds and D seems to put it priorities on adding new exiting features. Where as a large part of the outcry is the issues with the library, lacking editors support, cross platform issues, ...
Re: Forwarding arguments through a std.algorithm.map
On Saturday, 10 March 2018 at 20:48:06 UTC, Nordlöw wrote: If I have a function bool f(Rs...)(Rs rs) is it somehow possible to map and forward all its arguments `rs` to another function bool g(Rs...)(Rs rs); through a call to some map-and-forward-like-function `forwardMap` in something like bool f(Rs...)(Rs rs) { alias someArbitraryFun = _ => _; return g(forwardMap!(someArbitraryFun)(rs)); } ? What should the definition of forwardMap look like? Does Phobos contain something like this already? there is staticMap.
Inner Classes vs. Inner Structs
This works: ``` class S { int n, m; int sum() { return n + m; } Inner!(sum) a; class Inner(alias f){ auto get() { return f(); } } } ``` This doesn't: ``` struct S { int n, m; int sum() { return n + m; } Inner!(sum) a; struct Inner(alias f){ auto get() { return f(); // Error: this for sum needs to be type S not type Inner!(sum) } } } ``` The only difference between the two is one one uses classes, the other uses structs. My question is, under the current semantics of D, shouldn't the two work the same? That is, shouldn't the inner struct in the second example have an implicit context reference to the outer struct? Is this a bug? Thanks for the help, Mike
[Issue 18519] freebsd 11 + phobos + curl, timing out
https://issues.dlang.org/show_bug.cgi?id=18519 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/b8e5bca94b661c1d1ffb9ec6f7e37b9fa7a0d09d fix issue 18519 freebsd 11 + phobos + curl, timing out stop the TestServer waiting in accept() before thread_joinall https://github.com/dlang/phobos/commit/35e9807bbec392658ecdc8b4ed93d1f6c02f2845 Merge pull request #6234 from rainers/curl_freeze fix issue 18519 freebsd 11 + phobos + curl, timing out merged-on-behalf-of: Petar Kirov--
Re: Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux
On Sunday, 11 March 2018 at 08:43:25 UTC, Pjotr Prins wrote: The GNU package manager updated LDC to 1.7.0 which now provides x86_64-linux, see https://www.gnu.org/software/guix/packages/L/. Runtime dependencies and build are listed at https://hydra.gnu.org/build/2525193#tabs-runtime-deps, including 0.17.4 (bootstrap) and LLVM 3.8.1. LDC 0.17.4 provides x86_64-linux, i686-linux, armhf-linux. We aim to add D compilers for all supported architectures. Kai has been working recently [1] on updating LDC 0.17.x (ltsmaster) to work with LLVM 6, PowerPC, AArch64, ... You may want to take advantage of that activity to get better bootstrap compiler support for your platforms. For example by filing bug reports, or better: helping out with testing and fixing things ;-) -Johan [1] See e.g. https://github.com/ldc-developers/dmd-testsuite/pull/34
Re: Error compiling with DUB (dmd) since yesterday dub update
On Sunday, 11 March 2018 at 07:17:58 UTC, Mario wrote: On Sunday, 11 March 2018 at 07:11:09 UTC, rikki cattermole wrote: On 11/03/2018 8:02 PM, Mario wrote: On Sunday, 11 March 2018 at 06:59:32 UTC, rikki cattermole wrote: On 11/03/2018 7:55 PM, Mario wrote: [...] Are you aware that it is compiling with ldc? Actually, I didn't even realize XD. I'm a newbie in VibeD and DLang, should I change it? Why did compiling work yesterday? Thanks in advance Workaround switch to dmd. Real solution please file a bug for Botan and attach your log in. Thank you, I followed your advice and I created an issue on the GitHub project: https://github.com/etcimon/botan/issues/42 Or simply use the built-in openssl 1.1?
How do you call an eponymous template that has a secondary template arg?
Eg: template aliasOf(T) { enum aliasOf(alias a) = is(typeof(a) == T); } The use case for this is for std.meta.allSatisfy for variadic args, i.e. template T(values...) if (allSatisfy!(aliasOf!string, values) { ... } But how do you call that template otherwise? I've tries: * aliasOf!int!"string" // multiple ! arguments are not allowed * (aliasOf!int)!"string" // error c-style cast * aliasOf!int.aliasOf!"string" // template isAliasOf(alias a) does not have property 'isAliasOf I can work around this by: template typeOf(T) { enum isAliasedBy(alias a) = is(typeof(a) == T); } and then do: template T(values...) if (allSatisfy!(typeOf!string.isAliasedBy, values) { ... } But I like the readability of the former better if there's a way to achieve it? Cheers - Ali
Re: Forwarding arguments through a std.algorithm.map
On Saturday, 10 March 2018 at 20:48:06 UTC, Nordlöw wrote: If I have a function bool f(Rs...)(Rs rs) is it somehow possible to map and forward all its arguments `rs` to another function bool g(Rs...)(Rs rs); through a call to some map-and-forward-like-function `forwardMap` in something like bool f(Rs...)(Rs rs) { alias someArbitraryFun = _ => _; return g(forwardMap!(someArbitraryFun)(rs)); } ? What should the definition of forwardMap look like? Does Phobos contain something like this already? Not sure whether I understand what you are looking for, but std.functional is your friend here I think pipe/compose is the function you are searching for. https://dlang.org/phobos/std_functional.html#forward https://dlang.org/phobos/std_functional.html#partial https://dlang.org/phobos/std_functional.html#pipe
Re: C++ launched its community survey, too
On Sunday, 11 March 2018 at 02:21:30 UTC, Laeeth Isharc wrote: On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition. Watch this space... And we have warp which is a C preprocessor written in D, just saying ;)
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #34 from Eyal--- Walter: Thanks, the RVO fixes are very useful and important - and will be part of any future solution we have! --
Re: D for microservices
On Thursday, 8 March 2018 at 22:53:11 UTC, aberba wrote: On Thursday, 8 March 2018 at 09:35:08 UTC, Andrew Benton wrote: On Thursday, 8 March 2018 at 07:54:29 UTC, Jacob Carlborg wrote: On Thursday, 8 March 2018 at 07:20:53 UTC, Radu wrote: This guys says that vide.d works https://forum.dlang.org/thread/gikoeutmdyvolfshp...@forum.dlang.org Yes, it's pretty straightforward: 1. Build on Ubuntu, or some other dist 2. Statically link the whole binary with LDC, then you don't need to use Musl 3. Run it on Alpine -- /Jacob Carlborg Looks like that works out much nicer than using alpine as the first stage right now. I'm not sure anyone will be too upset about the extra 7MB. Building directly in alpine will simplify automated builds too. Simple Vibe.d app talking to Redis, packed into docker containers: https://github.com/tam4s/hello-redis The takeaway is that I could not use Alpine as a host image, because I could not build the app statically on ubuntu. warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
[Issue 18547] Win32: throwing exception in fiber crashes application
https://issues.dlang.org/show_bug.cgi?id=18547 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/a1a5ad8d70464534228839ad8f1f2a7938cb9524 fix issue 18547 - Win32: throwing exception in fiber crashes application increase the default stack size because exception handling might need up to 16k. The actually used stack can depend on the version of DbgHelp.dll, the existence of debug information and possibly other conditions. https://github.com/dlang/druntime/commit/86cd40a036a67d9b1bff6c14e91cba1e5557b119 Merge pull request #2129 from rainers/issue18547 fix issue 18547 - Win32: throwing exception in fiber crashes application merged-on-behalf-of: Petar Kirov--