Re: code.dlang.org package list
On Monday, 10 September 2018 at 11:20:55 UTC, bauss wrote: I'm sorry, but it's not even close to accurate, because some libraries has documents on additional websites that has examples and no examples directly in the source code using "standard unittests" - This is true for most big libraries / frameworks. Having checked out recent versions of all dub projects... 1300 dub projects with at least one release. 631 projects have example or test files / folders. 723 have unittests. (Or at least mention unittests somewhere in their source code. A `version (unittest) static assert(0)` would have counted. Or a comment saying that this project really should have at least one unittest. It's the thought that counts, right?) 452 have a file or directory with 'test' in the name. 352 have a file or directory with 'example' in the name. 953 have unittest or tests or examples. That's about 19 out of every 26 packages. You can't really measure such a thing accurately. It's quite possible that every package that lacks an example or test project instead has an external test suite. That's very unlikely, though. It's rather likely that about 25% of dub packages with at least one release have no tests. Probably quite a lot of the untested packages have only one release and no readme.
Re: rund users welcome
On Tuesday, 11 September 2018 at 01:02:30 UTC, Vladimir Panteleev wrote: On Sunday, 9 September 2018 at 04:32:32 UTC, Jonathan Marler wrote: - -od (e.g. for -od.) Hmmm, yeah it looks like rund is currently overriding this. I've attempted a fix but it's hard to cover all the different combinations of -of/-od/etc. I'll need to fill out the rest of the tests soon. Thanks. Looks like there's a problem on Posix systems: With -od., the binary file doesn't have the executable bit set. This fixes it: std.file.copy(from, to, std.file.PreserveAttributes.yes); I wasn't able to reproduce this issue on my ubuntu box. But, this might not be an issue anymore because I've implemented your next suggestion... Why not just get the compiler to create the file at the correct location directly, and avoid the I/O of copying the file? https://github.com/marler8997/rund/pull/3 (Remove extra rename/copy when user gives -of) Reviews welcome
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: That's why PC sales keep dropping while mobile sales are now 6-7X that per year: This shouldn't be misunderstood as such, which I think you as misunderstanding it. The reason mobile sales are so high is because of planned obsolescence and the walled garden that these devices are built around. I've gone through maybe 3-4 phones in the time that I've had my Desktop, and I use my desktop every single day. I don't need to buy a new one cause it runs perfectly fine, there aren't operating system updates that purposely cause the CPU to run slower to "save battery life" when a new device and OS come out. That's not to say it isn't insignificant but the sales numbers are exacerbated.
[Issue 18939] Wrong order slice lengths in array length mismatch error message
https://issues.dlang.org/show_bug.cgi?id=18939
Heromyth changed:
What|Removed |Added
CC||bitwo...@qq.com
--- Comment #1 from Heromyth ---
Here is another test:
__gshared string[] zeros;
shared static this() {
zeros[] = new string[64]; // There is no callstatck info.
// It just give these error:
// object.Error@(0): Array lengths don't match for copy: 64 != 0
// If I have a big source file, it really hard to locate the error.
}
void main()
{
// zeros[] = new string[64]; // Can get the callstatck info
}
--
Re: extern(C++, ns) is wrong
On Mon, 10 Sep 2018 at 13:40, Carl Sturtivant via Digitalmars-d wrote: > > On Wednesday, 5 September 2018 at 13:53:15 UTC, Jonathan M Davis > wrote: > > On Wednesday, September 5, 2018 7:03:26 AM MDT Nicholas Wilson > > via Digitalmars-d wrote: > >> [...] > > > > Based on everything Walter said in the previous thread, it > > honestly seems to me to be primarily like he just can't give up > > on the idea that D has to worry about modeling C++ namespaces. > > Pretty much all of the extra complications that come from the > > current approach stem from insisting on modeling namespaces in > > D instead of just treating the namespace as part of the > > information that you give to the compiler to indicate what the > > symbol in D is supposed to correspond to in C++ when the > > compiler goes to mangle it. > > > > [...] > > I wholeheartedly agree. C++ namespaces are a C++ language idea > that D has discarded in favor of much simpler facilities. > Injecting that back into D when linking to > C++ is polluting D with needless complexity at odds with that > gain in simplicity. The name collision problem with two > namespaces containing the same name can be resolved with much > simpler facilities. For example, at the point of the extern > declaration, the name of the linked entity could be provided as > an optional third parameter so that the name in D could be > different. I'm sure many other simple schemes could be invented, > more consistent with D's approach. This is a problem that doesn't need a solution. Just use modules; this is precisely what they're for. I, for one, have faith in the module design.
[Issue 8841] Missing line numbers in stack trace?
https://issues.dlang.org/show_bug.cgi?id=8841 Heromyth changed: What|Removed |Added CC||bitwo...@qq.com --- Comment #9 from Heromyth --- It seems fixed. --
Re: John Regehr on "Use of Assertions"
On Monday, 10 September 2018 at 19:44:22 UTC, H. S. Teoh wrote: It's high time we distinguished between the various flavors of assert, preferably with new words to avoid the baggage that has accumulated around 'assert'. Perhaps we can take some cues from Vigil, the eternally morally vigilant programming language, and use 'implore' for preconditions (aborts on new strict mode, throws by default) and 'swear' for other contracts?
Re: More fun with autodecoding
On Monday, 10 September 2018 at 20:44:46 UTC, Andrei Alexandrescu wrote: On 9/10/18 12:46 PM, Steven Schveighoffer wrote: On 9/10/18 8:58 AM, Steven Schveighoffer wrote: I'll have to figure out why my specialized range doesn't allow splitting based on " ". And the answer is: I'm an idiot. Forgot to define empty :) Also my slicing operator accepted ints and not size_t. I guess a better error message would be in order. https://github.com/dlang/DIPs/pull/131 will help narrow down the cause.
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. [...] Oh, I reported the AArch64 release of LDC to this blog a month ago, and I just saw that they wrote up an entry about it last week: https://www.worksonarm.com/blog/woa-issue-65/
Re: rund users welcome
On Sunday, 9 September 2018 at 04:32:32 UTC, Jonathan Marler wrote: - -od (e.g. for -od.) Hmmm, yeah it looks like rund is currently overriding this. I've attempted a fix but it's hard to cover all the different combinations of -of/-od/etc. I'll need to fill out the rest of the tests soon. Thanks. Looks like there's a problem on Posix systems: With -od., the binary file doesn't have the executable bit set. This fixes it: std.file.copy(from, to, std.file.PreserveAttributes.yes); Why not just get the compiler to create the file at the correct location directly, and avoid the I/O of copying the file?
Re: John Regehr on "Use of Assertions"
On Monday, 10 September 2018 at 20:25:21 UTC, Jonathan M Davis wrote: I propose: - 'assume': aborts on false condition in debug builds, not checked in release builds, used as optimizer hint; - 'insist': aborts on false condition in debug builds, aborts on false condition in release builds, used as optimizer hint; - 'uphold': aborts on false condition in debug builds, aborts on false condition in release builds, NOT used as optimizer hint; - 'allege': logs error and aborts on false condition in debug builds, logs error and continues on false condition in release builds, NOT used as optimizer hint; Honestly, that seems like total overkill I'm pretty sure that was sarcasm on H. S. Teoh's part. Of course, I can't tell for sure due to Poe's Law.
Re: John Regehr on "Use of Assertions"
On Monday, 10 September 2018 at 20:25:21 UTC, Jonathan M Davis wrote: On Monday, September 10, 2018 1:44:22 PM MDT H. S. Teoh via Digitalmars-d wrote: [...] Honestly, that seems like total overkill, and I think that you would have a _very_ hard sell to get much of anyone to try to use four variants of assert, regardless of what they were. [...] FWIW I agree that maybe all those is a bit much - would be quite confusing to figure out the nuances between assert/enforce/assume/insist/uphold/allege. But, I do see the value in adding an assert flavour that [also] aborts in release mode and allows optimizations. And I think the proposed assume is a reasonable name for it. And if people want it to be left out of release builds they can call "debug assume(...)" (compiler is still free to still optimize). Cheers, - Ali
Re: More fun with autodecoding
On 9/10/18 12:46 PM, Steven Schveighoffer wrote: On 9/10/18 8:58 AM, Steven Schveighoffer wrote: I'll have to figure out why my specialized range doesn't allow splitting based on " ". And the answer is: I'm an idiot. Forgot to define empty :) Also my slicing operator accepted ints and not size_t. I guess a better error message would be in order.
Re: extern(C++, ns) is wrong
On Wednesday, 5 September 2018 at 13:53:15 UTC, Jonathan M Davis wrote: On Wednesday, September 5, 2018 7:03:26 AM MDT Nicholas Wilson via Digitalmars-d wrote: [...] Based on everything Walter said in the previous thread, it honestly seems to me to be primarily like he just can't give up on the idea that D has to worry about modeling C++ namespaces. Pretty much all of the extra complications that come from the current approach stem from insisting on modeling namespaces in D instead of just treating the namespace as part of the information that you give to the compiler to indicate what the symbol in D is supposed to correspond to in C++ when the compiler goes to mangle it. [...] I wholeheartedly agree. C++ namespaces are a C++ language idea that D has discarded in favor of much simpler facilities. Injecting that back into D when linking to C++ is polluting D with needless complexity at odds with that gain in simplicity. The name collision problem with two namespaces containing the same name can be resolved with much simpler facilities. For example, at the point of the extern declaration, the name of the linked entity could be provided as an optional third parameter so that the name in D could be different. I'm sure many other simple schemes could be invented, more consistent with D's approach.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 19:19:56 UTC, 0xEAB wrote: On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh wrote: It blindly takes the results of dub build and dub test. Another question: How does it deal with targetType set to "sourceLibrary"? As of five minutes ago, for source libraries, the test result is copied to the build result. Moreover, a future feature could be build logs, so one could check why something failed to build. I'm hesitant to do much in this regard because I don't want people to treat this as a CI system. It would certainly be useful for finding bugs in the tester, though.
Re: Process in parallel and output result to stdout theread-safely
On Saturday, 8 September 2018 at 14:26:45 UTC, ag0aep6g wrote:
On 09/03/2018 08:13 PM, Dr.No wrote:
But it in the middle of output, I got output like this:
outjson = {"barCode":"20","ade":"20"}♪◙outjson =
{"barCode":"X21","ade":"21"}
also there's that extra ♪◙ character. Thos sounds memory
violation somewhere.
This only happens when using parallel. Any guess what's
possibily happeing?
If that only ever happens at line breaks, then that doesn't
necessarily look like memory corruption to me.
Yes, it does only happens at line breaks. I hadn't realized that
until you mentioned. It does gets in place of \r and \n, that's
why there's all in one line when this happens. Thankfor for the
notice.
I looked around a bit and found code page 437 [1]. It has those
characters at 0xD and 0xA which is where ASCII has \r and \n.
So it might be that code page 437 is used when displaying that
particular entry. Why that would happen, I have no idea.
So I guessed that something changed the console code page. I've
tried to call call chcp 65001 at program's start up. Not worked.
Tried inside the main loop. Also not worked.
To get better help, you should post a complete test case that
people can just copy/paste. That includes imports, a `main`
function, and the command you use to compile. Also add
information about your environment (OS, compiler version).
I made a reduced version where you can do just dmd -run hello.d.
The application does convert alot of PDF files to text then do
some parsing (I've removed this not needed part). In my code, at
iteration 28 I got those character (♪◙), which is the error. I
hope you can reproduce this error on your machine as well. I got
some PDF files and duplicated them just for testing purpose. If
for some reason you didn't get the same error immediately, try
duplicate the PDFs and try again. I believe this can reproduce
the erro.
Here's the resources to compile the application:
source code: https://pastebin.com/RwrUikQS
PDF files + pdf to text application:
https://drive.google.com/file/d/1uKjJX4pQIEWVK4vujUsm0ln2yHS7z5ZZ/view?usp=sharing
OS: Windows 10 64-bit
compiler: DMD32 D Compiler v2.080.0 (same issue happens on ldc)
command line: dmd -run hello.d
Thank you very much for your time.
Re: John Regehr on "Use of Assertions"
On Monday, September 10, 2018 1:44:22 PM MDT H. S. Teoh via Digitalmars-d wrote: > On Sun, Sep 09, 2018 at 12:27:52AM -0600, Jonathan M Davis via > Digitalmars-d wrote: [...] > > > IIRC, Weka has different types of assertions to differentiate between > > these two approaches - one for the cases which absolutely must not > > happen in production, and one that's purely for catching problems > > during developement. And really, I think that that's probably the > > right approach. > > [...] > > On Sun, Sep 09, 2018 at 09:20:11PM +, John Carter via Digitalmars-d > wrote: [...] > > > > > Let's face it, the term "assert" has been poisoned by decades of > > > > ambiguity. > > [...] > > > I beg humanity to give up on that word "assert" and come up with > > others words and define explicit the intent and meaning and > > implications. > > > > So much pain will be avoided. > > Indeed. D already distinguishes between assert (for catching > programming errors) and enforce (for catching runtime conditions like > bad user input). It's high time we distinguished between the various > flavors of assert, preferably with new words to avoid the baggage that > has accumulated around 'assert'. > > I propose: > > - 'assume': aborts on false condition in debug builds, not checked in > release builds, used as optimizer hint; > > - 'insist': aborts on false condition in debug builds, aborts on false > condition in release builds, used as optimizer hint; > > - 'uphold': aborts on false condition in debug builds, aborts on false > condition in release builds, NOT used as optimizer hint; > > - 'allege': logs error and aborts on false condition in debug builds, > logs error and continues on false condition in release builds, NOT > used as optimizer hint; Honestly, that seems like total overkill, and I think that you would have a _very_ hard sell to get much of anyone to try to use four variants of assert, regardless of what they were. Also, why on earth would you suggest _not_ using it as optimizer hint in the case when it _aborts_ if it's false in both debug and release? At that point, it's guaranteed to be true if the code gets passed that point. There's a halfway decent chance that the compiler would end up using that information for optimizations even without it understanding anything special about the keyword, simply because it could guarantee that the condition was true for the code that followed just by seeing that the code aborted if it was false. If we were really going to do something to change the situation with assertions, I'd probably simply argue for adding a function to std.exception called something like require which was like enforce except that instead of throwing an exception on failure, it hit assert(0). The compiler should then be able to safely optimize based on that, and it would provide a standard way to require that a condition be true regardless of -release. At that point, there should be no need to optimize based on assertions, and they can be left as they have been (and as most people expect them to be) as a simple tool for catching problems during developement. If someone then wants to be paranoid and leave the assertions in by not compiling with -release, but that's their choice. Either way, I think that trying to do away with assertions based on the idea that there isn't always agreement on how they should be used is overkill, and I think that switching to having something like four different versions of assertions with new names is definitely overkill. IMHO, the biggest problem here is simply that optimizing based on assertions is dangerous if assertions aren't always left in, and since assertions are normally explained and used as a tool for catching bugs in development, most people use them with the idea that they're going to be removed in production with -release. So, they're not going to be left in production, and optimizing based on them is just going to be dangerous. That's what needs to be prevented here. We don't need a bunch of different types of assertions to solve that problem. We simply need to _not_ optimize based on assertions, and it would be a bonus to provide a standard way for people to put checks in their code that stay with -release, but such a function could trivially be written right now by anyone who wants it. We don't actually need to do anything special with the compiler, and we certainly shouldn't need to add separate helper functions to druntime or Phobos for every stray scenario of leaving checks in or not that we think someone might want. - Jonathan M Davis
Re: libmir: recent updates
On Monday, 10 September 2018 at 17:42:16 UTC, jmh530 wrote: [snip] mir-algorithm and lubeck do not interact well right now on run.dlang.org as lubeck depends on the earlier API. The maintainer of that might consider adding an older version of mir-algorithm until the situation is resolved. Hmm, it looks like all you have to do just change the dependency to whatever works with lubeck and it works fine. Maybe it can be temporarily adjusted so that adding lubeck as a dependency adds the correct version of mir algorithm by default?
Re: John Regehr on "Use of Assertions"
On Sun, Sep 09, 2018 at 12:27:52AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...] > IIRC, Weka has different types of assertions to differentiate between > these two approaches - one for the cases which absolutely must not > happen in production, and one that's purely for catching problems > during developement. And really, I think that that's probably the > right approach. [...] On Sun, Sep 09, 2018 at 09:20:11PM +, John Carter via Digitalmars-d wrote: [...] > > > Let's face it, the term "assert" has been poisoned by decades of > > > ambiguity. [...] > I beg humanity to give up on that word "assert" and come up with > others words and define explicit the intent and meaning and > implications. > > So much pain will be avoided. Indeed. D already distinguishes between assert (for catching programming errors) and enforce (for catching runtime conditions like bad user input). It's high time we distinguished between the various flavors of assert, preferably with new words to avoid the baggage that has accumulated around 'assert'. I propose: - 'assume': aborts on false condition in debug builds, not checked in release builds, used as optimizer hint; - 'insist': aborts on false condition in debug builds, aborts on false condition in release builds, used as optimizer hint; - 'uphold': aborts on false condition in debug builds, aborts on false condition in release builds, NOT used as optimizer hint; - 'allege': logs error and aborts on false condition in debug builds, logs error and continues on false condition in release builds, NOT used as optimizer hint; T -- You are only young once, but you can stay immature indefinitely. -- azephrahel
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 16:09:41 UTC, rjframe wrote: On Mon, 10 Sep 2018 13:43:46 +, Joakim wrote: Despite all this, D may never do very well on mobile or AArch64, even though I think it's well-suited for that market. But at the very least, you should be looking at mobile and AArch64, as they're taking over the computing market. I was talking with a local businessperson the other day who noted that there are young people walking around right now that never have (and likely never will) own a laptop. That's exactly whats happening in Africa. The continent is leapfrogging from nothing to a smart phone thanks to China. Many don'[t know how to even use a PC. Especially the young and upcoming generation. The smart phone market is really significant.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh wrote: It blindly takes the results of dub build and dub test. Another question: How does it deal with targetType set to "sourceLibrary"? Moreover, a future feature could be build logs, so one could check why something failed to build.
Re: John Regehr on "Use of Assertions"
On Sunday, 9 September 2018 at 21:20:11 UTC, John Carter wrote: ie. Yes, everybody knows the words, everybody can read the code, everybody can find somebody who agrees with his intent and meaning but get a large enough group together to try agree on what actions, for example, the optimiser should take that are implied by that meaning... and flames erupt. Well, it has less to do with "assert" than with how semantics are assigned to something that should never occur. But it isn't really optimal to hardcode failure semantics in the source code... Even simple semantics, like whether tests should be emitted in release builds is possibly context dependent, so not really possible to determine with any level of certainty when writing a library reused across many projects.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh wrote: midi-gamepad has no releases. It has 0.1.1-alpha So it doesn't test pre-release versions. Thanks for clarification.
Re: Will the core.stdc module be updated for newer versions of C?
On Saturday, 8 September 2018 at 01:12:30 UTC, solidstate1991 wrote: While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s). While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too. dpp has worked for most C headers I tried and if not then file a GitHub issue and we will fix it. I think C++ will come step by step in time, though it's quite a lot of work.
Re: libmir: recent updates
On Monday, 10 September 2018 at 14:33:11 UTC, 9il wrote: On Monday, 10 September 2018 at 12:55:01 UTC, Arredondo wrote: On Sunday, 9 September 2018 at 17:24:49 UTC, 9il wrote: Mir Algorithm http://mir-algorithm.dub.pm - v2.0.0, new ndslice API, Does new API mean that it's not backwards compatible? if so, where can we find the documentation for this new API? Arredondo. http://docs.algorithm.dlang.io - docs for recent Mir Algorithm release. The main difference is that Slice definition is changed to struct mir_slice(Iterator_, size_t N_ = 1, SliceKind kind_ = Contiguous) alias Slice = mir_slice; The parameters order was reversed, last two params are optional now. For example, see the PR for ndslice API update for old main Mir repo. https://github.com/libmir/mir/pull/397/files#diff-399a70373923e55f87a86928eb3cc731L43 Similar situation with Series definition. mir-algorithm and lubeck do not interact well right now on run.dlang.org as lubeck depends on the earlier API. The maintainer of that might consider adding an older version of mir-algorithm until the situation is resolved.
Re: Will the core.stdc module be updated for newer versions of C?
On Monday, 10 September 2018 at 07:43:52 UTC, Jonathan M Davis wrote: Historically, most of the Win32 API has been missing from druntime, and many of the symbols were in the wrong place (they should really be in modules corresponding to the C headers that the symbols come from, but many of them were just put in core.sys.windows.windows as if everything were in windows.h). Most folks doing serious stuff with the Win32 API used to use an external project that had a much more thorough version of the bindings (though I can't find it at the moment, looking around for D projects with Win and API in the name, so I don't know what happened to it). However, looking over what's in druntime for Windows now, it looks like Vladimir added a ton of bindings back in 2015 (probably from that external project). So, it would appear that the situation for the Windows bindings in druntime is _way_ better than it used to be. Regardless, if you find that a particular binding is missing, feel free to create a PR for it. Usually, such bindings only get added when someone wants to use a particular C function and then discovers that the binding is missing, so they create a PR to add it. It's not like we have a system for discovering all of the bindings that are supposed to be there, and while occasionally, someone will make an effort to make the bindings more comprehensive, it's not something that's regularly worked on. - Jonathan M Davis I don't remember what API I was thinking about using and didn't find in druntime, but as far as I can recall I ended up using another API anyway. I just pulled up a Bash for Windows prompt: $ cd /mnt/b/Program\ Files/D/dmd2/src/druntime/src/core/sys/windows $ ls *.d | wc -l 165 $ cd /mnt/c/Program\ Files\ \(x86\)/Windows\ Kits/10/Include $ ls 10.0.17134.0/um/*.h | wc -l 1443 I think that perhaps I see know why the bindings aren't going get an overhaul and be up to date just like that... I'll be sure to make a PR whenever I stumble upon missing ones I feel like using though.
Re: More fun with autodecoding
On 9/10/18 8:58 AM, Steven Schveighoffer wrote: I'll have to figure out why my specialized range doesn't allow splitting based on " ". And the answer is: I'm an idiot. Forgot to define empty :) Also my slicing operator accepted ints and not size_t. -Steve
[Issue 19239] New: Fix unsafe casting away of const in hashOf(const Object)
https://issues.dlang.org/show_bug.cgi?id=19239 Issue ID: 19239 Summary: Fix unsafe casting away of const in hashOf(const Object) Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com `Object.toHash` is not const. Since a struct's `toHash` needs to be const, usually a struct will just cast away const-ness of an Object and hope that this violation of the type system doesn't cause a catastrophe. This happens to be okay for objects that don't override `toHash` because the base implementation is based on the object's address and is logically const even though it doesn't have the `const` attribute. We can make this sound by performing a runtime check to see if it uses the address-based Object.toHash. (It would be even better if we could perform a runtime check to see if its overridden with a const function, but I don't believe that is a way to do this.) Doing this will let us legitimately call `const(Object).toHash()` in `@trusted` code. --
Re: Mobile is the new PC and AArch64 is the new x64
On Mon, 10 Sep 2018 13:43:46 +, Joakim wrote: > Despite all this, D may never do very well on mobile or AArch64, > even though I think it's well-suited for that market. But at the very > least, you should be looking at mobile and AArch64, as they're taking > over the computing market. I was talking with a local businessperson the other day who noted that there are young people walking around right now that never have (and likely never will) own a laptop.
Re: Do we need Mat, Vec, TMmat, Diag, Sym and other matrix types?
On Tuesday, 20 March 2018 at 12:10:08 UTC, Nordlöw wrote: On Tuesday, 13 March 2018 at 03:37:36 UTC, 9il wrote: I have a lot of work for next months, but looking for a good opportunity to make Mat happen. Sounds great. In which repo will these changes happen? It is planned to be in mir-algorithm, though
Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2
On Tuesday, 27 February 2018 at 09:23:49 UTC, kerdemdemir wrote: I need a classifier in my project. Since it is I believe most easy to implement I am trying to implement logistic regression. [...] Mir Random v1.0.0 has new `range` overloads that can work NdRandomVariable. Example: https://run.dlang.io/is/jte3gx
Re: More fun with autodecoding
On 9/8/18 8:36 AM, Steven Schveighoffer wrote:
On 8/9/18 2:44 AM, Walter Bright wrote:
On 8/8/2018 2:01 PM, Steven Schveighoffer wrote:
Here's where I'm struggling -- because a string provides indexing,
slicing, length, etc. but Phobos ignores that. I can't make a new
type that does the same thing. Not only that, but I'm finding the
specializations of algorithms only work on the type "string", and
nothing else.
One of the worst things about autodecoding is it is special, it *only*
steps in for strings. Fortunately, however, that specialness enabled
us to save things with byCodePoint and byCodeUnit.
So it turns out that technically the problem here, even though it seemed
like an autodecoding problem, is a problem with splitter.
splitter doesn't deal with encodings of character ranges at all.
For instance, when you have this:
"abc 123".byCodeUnit.splitter;
What happens is splitter only has one overload that takes one parameter,
and that requires a character *array*, not a range.
So the byCodeUnit result is aliased-this to its original, and surprise!
the elements from that splitter are string.
Next, I tried to use a parameter:
"abc 123".byCodeUnit.splitter(" ");
Nope, still devolves to string. It turns out it can't figure out how to
split character ranges using a character array as input.
Hm... I made some erroneous assumptions in determining these problems.
1. There is no alias this for the source in ByCodeUnitImpl. I'm not sure
how it was working when I tested before, but byCodeUnit definitely
doesn't have it, and doesn't compile with the no-arg splitter call.
2. The .splitter(" ") does actually work and return a range of
ByCodeUnitImpl elements.
So some of my analysis must have been based on bad testing.
However, the issue with the no-arg splitter is still there, and I still
think it should be fixed.
I'll have to figure out why my specialized range doesn't allow splitting
based on " ".
-Steve
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 15:06:46 UTC, Claude wrote: On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: Despite all this, D may never do very well on mobile or AArch64, even though I think it's well-suited for that market. But at the very least, you should be looking at mobile and AArch64, as they're taking over the computing market. Coming from ARM system programming for embedded systems, I'm also looking into AArch64. Having done some x86 assembly, ARM assembly was a bliss, and AArch64 looks even better! I also wish D will do well for embedded systems. Radu has done good work getting D working with uClibc, for example with OpenWRT: https://github.com/ldc-developers/ldc/issues/2810 yshui added a Musl port too, which can be used with the Alpine build of ldc available at the above ldc 1.11 link. There have been a couple reports of companies trying to use ldc for this, but there are likely still bugs that need to be ironed out.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 13:58:37 UTC, 0xEAB wrote: May I ask why some packages are missing (e.g. `midi-gamepad`)? midi-gamepad has no releases. It has 0.1.1-alpha, which is a prelease version, and ~master, which is a branch, and I can't rely on ~master being consistent in successive builds. A question, how this it currently handle link libraries? It blindly takes the results of dub build and dub test.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 10:50:16 UTC, Joakim wrote: Nice work. I wonder about some of your results, as it says that dub itself doesn't build with all of the dmd versions, but somehow the tests pass sometimes (shouldn't be possible if you can't build dub itself). I just tested with `dub fetch dub; dub build dub` with the dub 1.10 that comes alongside dmd 2.081.1 on linux/x64 and it built the latest dub 1.11 without a problem. Thank you, fixed. For some reason, libcurl was being linked in only with dub build, and despite the fact that the test harness itself uses libcurl, dub build couldn't find it. I cleared out all failed builds just to be certain -- about six hours lost total, and I'll trade six hours for bad data any day. Regardless, you should talk to Sonke about getting this integrated with code.dlang.org and to Mike about putting up a funding target to pay for both permanent server resources and your time coding this up. I've already said I'd donate towards such a target: Thank you.
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: Despite all this, D may never do very well on mobile or AArch64, even though I think it's well-suited for that market. But at the very least, you should be looking at mobile and AArch64, as they're taking over the computing market. Coming from ARM system programming for embedded systems, I'm also looking into AArch64. Having done some x86 assembly, ARM assembly was a bliss, and AArch64 looks even better! I also wish D will do well for embedded systems. Most of the system developers I know program in C, and do very little C++ for it becomes unmaintainable (unless you enforce strict coding rules: like using it like "C with class" with very little template). C is straigthforward and gets the job done (ie. Vulkan - as a quite recent API - was written in C, not C++. So D would do so good! That's why I think "BetterC" is a good strategic move (in the long run) even though I understand people coming from Java/Python background might not get it at all. If we have a BetterConst (I'm referring to Jonathan Davis article: http://jmdavisprog.com/articles/why-const-sucks.html ), I think D would be even greater.
[Issue 19219] Could not CTFE with std.math.exp from 2.082.0
https://issues.dlang.org/show_bug.cgi?id=19219 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19219] Could not CTFE with std.math.exp from 2.082.0
https://issues.dlang.org/show_bug.cgi?id=19219 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/081d5e8d27b44d71cb81265fd18b4654fc61c293 Fix Issue 19219 - Could not CTFE with std.math.exp https://github.com/dlang/dmd/commit/09c657a75f874fa42e8493e46ad71798c9e05c3c Merge pull request #8660 from kinke/exp_ctfe [stable] Fix Issue 19219 - Could not CTFE with std.math.exp merged-on-behalf-of: Jacob Carlborg --
Re: More fun with autodecoding
On 9/8/18 8:36 AM, Steven Schveighoffer wrote: I'll work on adding some issues to the tracker, and potentially doing some PRs so they can be fixed. https://issues.dlang.org/show_bug.cgi?id=19238 https://github.com/dlang/phobos/pull/6700 -Steve
Re: libmir: recent updates
On Monday, 10 September 2018 at 12:55:01 UTC, Arredondo wrote: On Sunday, 9 September 2018 at 17:24:49 UTC, 9il wrote: Mir Algorithm http://mir-algorithm.dub.pm - v2.0.0, new ndslice API, Does new API mean that it's not backwards compatible? if so, where can we find the documentation for this new API? Arredondo. http://docs.algorithm.dlang.io - docs for recent Mir Algorithm release. The main difference is that Slice definition is changed to struct mir_slice(Iterator_, size_t N_ = 1, SliceKind kind_ = Contiguous) alias Slice = mir_slice; The parameters order was reversed, last two params are optional now. For example, see the PR for ndslice API update for old main Mir repo. https://github.com/libmir/mir/pull/397/files#diff-399a70373923e55f87a86928eb3cc731L43 Similar situation with Series definition.
Re: Meson support for Mir and Lubeck
[ Replying to lots of stuff in one message - evil, I know... ;-) ] On Sunday, 9 September 2018 at 21:22:42 UTC, 9il wrote: On Sunday, 5 August 2018 at 02:36:29 UTC, Matthias Klumpp wrote: [...] Looks like that only betterC projects are good enough to become Debian packages. Generally because of the have stable C ABI that does not depend on D compiler version at all. Having a stable API/ABI is a *huge* plus, but we can also deal with pretty much any D library and D project in Debian, as long as it's build process is able to discover local dependencies and doesn't do evil stuff (like connecting to the network or writing to HOME). It also has to build with LDC or have no D library dependencies and build with GDC (that's a bit oversimplified though). In practice this means we can have dub projects with zero dependencies (except for the standard library) that build only executables in Debian packages with a bunch of hacks, or have any D project that uses Makefiles/Meson/CMake/Automake. Mir has the latter now, so that's fine. On Monday, 10 September 2018 at 06:31:44 UTC, Russel Winder wrote: On Sun, 2018-09-09 at 21:22 +, 9il via Digitalmars-d-announce wrote: [...] Many Debian packages depend on specific versions of things like GCC runtime or LLVM. The Debian packaging system allows for many versions of libraries to co-exists. Thus supporting multiple versions of Druntime and Phobos is possible. It is possible, but heavily discouraged, and also not something I would ever even try to do. Debian carries *one* version of Phobos/DRuntime per compiler that we support and that all D code in the archive has to build with. There may be occasions where multiple versions are in the archive, but that happens only briefly during transitions. For security reasons (only one thing to patch in stable) and maintainability reasons (the less to maintain the better) anything that doesn't build with the current version of D/Phobos will either be patched upstream or in Debian or dropped from Debian entirely. So far this case has never happened though, all breakage of D code in Debian was usually addressed pretty quickly - except for strange compiler bugs on less common architectures. […] > I only worry about potential name clashes with Mir (the > display server) in Ubuntu ^^ This is going to be a naming problem. Debian has many of these sort of naming clash and usually it is best for the smaller, newer project to accept that they need to choose a non-clashing name. Recent example the Mu editor, but there are many instances of this. D's Mir needs to choose a name that doesn't clash with Canonical's Mir. This was more meant as a joke from my side ;-) Technically, nobody from Canonical bothered to upload a "mir" package to Debian yet, so technically the name is free to grab for us. However, introducing a src:mir package into Debian would either force Ubuntu to adapt and rename their display server source package (to mir-display-server) or not have D's mir for quite a while. Socially I think claiming the src:mir name isn't the best idea, therefore - it's unfriendly to a derivative. However, src:libmir is free and that's what we could go with as a pretty good compromise. As for the binary package names, none of the D-mir names clash with Ubuntu's mir, so that's a non-issue. On Monday, 10 September 2018 at 07:25:07 UTC, 9il wrote: On Monday, 10 September 2018 at 06:31:44 UTC, Russel Winder wrote: On Sun, 2018-09-09 at 21:22 +, 9il via [...] Interesting, maybe we can go forward with D specific libraries in the future. Is there any D library that is used by application packages? Quite a few. Debian uses GDC and LDC for compiling its D packages. LDC on the amd64, arm64, armhf and i386 architectures and GDC on all other archs. The respective default D compiler is set via the default-d-compiler metapackage[1]. This means that whenever there's a new compiler release, ABI gets broken "thanks" to D's unstable ABI. Fortunately all new compilers also come with a new Phobos shared library that has had its SONAME bumped. Which means we can track which D compiler a package was built with via the phobos/druntime libraries they link to. This enables us to rebuild dependencies in order via a regular library transition, coincidentally one is going on right now. See[2] and tick "Good" to see all D packages that are part of this transition. This results in the fun conundrum though that as soon as we have D code that *doesn't* link against druntime or phobos, we can't track whether it was rebuilt with the latest compiler and it might fall through the cracks. I wonder how much of an issue this is - other languages implemented hacks to deal with this issue by depending on artificial virtual ABI packages denoting the current compiler version. Mir Optim can be easily used by other libraries and languages, developers don't need to know D at all as well as
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 14:00:43 UTC, Iain Buclaw wrote: On 10 September 2018 at 15:43, Joakim via Digitalmars-d wrote: LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. I've just got back from a conference where AArch64 was declared a disaster Why? and the future is now PPC64 and RISC-V. If you're not joking, it still stands that AArch64 is the _present_, as the currently most widely-deployed CPU arch used for personal computing, ie in mobile devices. Those other two arches are a joke right now, but you never know in the future. ARM was a joke compared to Intel a couple decades ago too. ;)
[Issue 19238] New: no-arg splitter should work on ranges of characters
https://issues.dlang.org/show_bug.cgi?id=19238
Issue ID: 19238
Summary: no-arg splitter should work on ranges of characters
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
Currently, std.algorithm.iteration.splitter has an overload that works just
with character arrays and takes no parameters. This special overload is
different from the other versions of splitter in that:
1. it only works with *arrays* of characters
2. the inferred separator is any run of whitespace, as opposed to the other
splitter overloads where the separator is a fixed length.
It's currently impossible to use the other overloads of splitter to mimic this
behavior with a non-array range, such as byCodeUnit.
However, there's nothing inherently special about character arrays that makes
it incorrect to use on arbitrary code unit ranges.
In other words, this should compile:
auto range = "helloworld".byCodeUnit.splitter;
static assert(is(typeof(range.front()) == typeof("hello".byCodeUnit()));
assert(range.equals(["hello".byCodeUnit, "world".byCodeUnit]);
--
Re: Mobile is the new PC and AArch64 is the new x64
On 10 September 2018 at 15:43, Joakim via Digitalmars-d wrote: > LDC recently added a linux/AArch64 CI for both its main branches and 64-bit > ARM, ie AArch64, builds have been put out for both linux and Android. It > does not seem that many are paying attention to this sea change that is > going on with computing though, so let me lay out some evidence. > I've just got back from a conference where AArch64 was declared a disaster, and the future is now PPC64 and RISC-V.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh wrote: Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/. The current backfill is taking the three most recent versions of each package on the ~40 most recent versions of dmd, using a list of dub packages from a couple days ago. Each compiler version takes about six hours, so the backfill will be finished in about ten days. The report should update automatically every 100 builds. Once that's done, I'll extend the backfill to handle all package versions, have it get new package versions from dub, and get it to discover and download new DMD versions automatically. This shouldn't be a huge change. My respect, neat. May I ask why some packages are missing (e.g. `midi-gamepad`)? A question, how this it currently handle link libraries?
Re: traits getOverload of a template method
On Monday, 10 September 2018 at 13:46:08 UTC, aliak wrote: On Monday, 10 September 2018 at 12:57:25 UTC, Timoses wrote: How to "select" one? Can you either: alias myPeek = () => peek!(int, Endian.bigEndian, immutable(ubyte)[])(); Or alias myPeek = (size_t *index) => peek!(int, Endian.bigEndian, immutable(ubyte)[])(index); ?? With the Range arg as well of course.
Re: traits getOverload of a template method
On Monday, 10 September 2018 at 12:57:25 UTC, Timoses wrote: On Thursday, 6 February 2014 at 23:06:03 UTC, QAston wrote: [...] Is there any way to "select" overloaded template functions? I require to select one of `std.bitmanip.peek` import std.bitmanip : peek; import std.system : Endian; alias myPeek = peek!(int, Endian.bigEndian, immutable(ubyte)[]); Error: template std.bitmanip.peek matches more than one template declaration: /dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3269): peek(T, Endian endianness = Endian.bigEndian, R)(R range) if (canSwapEndianness!T && isForwardRange!R && is(ElementType!R : const(ubyte))) and /dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3306): peek(T, Endian endianness = Endian.bigEndian, R)(R range, size_t* index) if (canSwapEndianness!T && isForwardRange!R && hasSlicing!R && is(ElementType!R : const(ubyte))) How to "select" one? Can you either: alias myPeek = () => peek!(int, Endian.bigEndian, immutable(ubyte)[])(); Or alias myPeek = (size_t *index) => peek!(int, Endian.bigEndian, immutable(ubyte)[])(index); ??
Mobile is the new PC and AArch64 is the new x64
LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. At my workplace six years ago, the developers were all allocated a core i5 ultrabook- likely with 4 GBs of RAM and a 128 GB SSD, though I don't remember those specs- and a 27" 2560X1440 display with which to get our work done. I was pretty happy with the display, the best I'd ever used to that point. I'm guessing the setup cost my employer a couple thousand dollars per developer. I picked up an Android/AArch64 smartphone earlier this year, with 6 GBs of RAM, 128 GBs of flash, a Snapdragon 835 octa-core CPU, and a 5.5" 2560X1440 display. This is the fastest computer I've ever owned, and it fits in 6 cubic inches and weighs a little more than a third of a pound. It cost me approximately $700. That is a stunning change in mobile capabilities in just six years, where what used to be a mobile developer workstation now comes packed into a smartphone at a fraction of the cost. If you think the phone doesn't actually perform, I borrowed a 2015-model Macbook Air with a core i5 and 4 GBs of RAM and built the last pure C++ version of ldc, 0.17, using both cores with `-ninja -j5`. It took two minutes with clang from Homebrew, the same amount of time it takes me to build the same source on my smartphone with clang by running `ninja -j9`. This phone has been my development hardware since early this year, by pairing it with a $30 bluetooth keyboard and a $5 stand to hold it up. I'm typing this long forum post up on it now. Tech companies are starting to realize this and going after the desktop/laptop PC markets with various 64-bit ARM products: https://www.engadget.com/2018/08/09/samsung-galaxy-note-9-dex/ https://arstechnica.com/gadgets/2018/08/samsungs-tab-s4-is-both-an-android-tablet-and-a-desktop-computer/ https://youtube.com/watch?v=uLvIAskVSUM https://www.anandtech.com/show/13309/lenovo-yoga-c630-snapdragon-850-windows That last link notes 25 hours of battery life with a Windows/AArch64 laptop, one of the key benefits of ARM, which is why even Microsoft has come around. Yes, I know, these devices won't replace your quad-core Xeon workstation with 32-64 GBs of RAM anytime soon, but most people don't need anywhere near that level of compute. That's why PC sales keep dropping while mobile sales are now 6-7X that per year: https://www.businessinsider.com/PC-sales-are-continuing-to-slump-fewer-are-sold-now-than-when-the-iPhone-launched/articleshow/62547330.cms https://www.androidauthority.com/smartphone-sales-idc-2018-871363/ Most of those mobile devices running iOS have AArch64 CPUs, and google said last December that "over 40% of Android devices coming online have 64-bit support," which is why they're requiring apps with native libraries to support it by next fall: https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html D now has mostly working AArch64 support, with the ldc 1.11 release last month: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0 That is the result of years of intermittent AArch64 patches added by the core teams of ldc and gdc- David, Iain, Kai, Johannes, Dan, and others- to which I recently added some Android patches. You too can pitch in with the few remaining issues or try out the AArch64 support with your own D code. This company provides a free linux/AArch64 CI for OSS projects, LDC uses it: http://blog.shippable.com/shippable-arm-packet-deliver-native-ci-cd-for-arm-architecture Despite all this, D may never do very well on mobile or AArch64, even though I think it's well-suited for that market. But at the very least, you should be looking at mobile and AArch64, as they're taking over the computing market.
Re: libmir: recent updates
On Sunday, 9 September 2018 at 17:24:49 UTC, 9il wrote: Mir Algorithm http://mir-algorithm.dub.pm - v2.0.0, new ndslice API, Does new API mean that it's not backwards compatible? if so, where can we find the documentation for this new API? Arredondo.
Re: traits getOverload of a template method
On Thursday, 6 February 2014 at 23:06:03 UTC, QAston wrote:
How do i get aliases to overloads of a template method like
Class A
{
int a(T)(T tq,T tw);
int a(T)(T tq);
}
__traits(getOverloads, A, "a(int)")doesnt work
Is there any way to "select" overloaded template functions?
I require to select one of `std.bitmanip.peek`
import std.bitmanip : peek;
import std.system : Endian;
alias myPeek = peek!(int, Endian.bigEndian,
immutable(ubyte)[]);
Error:
template std.bitmanip.peek matches more than one template
declaration:
/dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3269):
peek(T, Endian endianness = Endian.bigEndian, R)(R range) if
(canSwapEndianness!T && isForwardRange!R && is(ElementType!R :
const(ubyte)))
and
/dlang/dmd/linux/bin64/../../src/phobos/std/bitmanip.d(3306):
peek(T, Endian endianness = Endian.bigEndian, R)(R range, size_t*
index) if (canSwapEndianness!T && isForwardRange!R &&
hasSlicing!R && is(ElementType!R : const(ubyte)))
How to "select" one?
Re: Will the core.stdc module be updated for newer versions of C?
On 9/7/18 6:12 PM, solidstate1991 wrote: While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s). It will be updated when you update it ;) There is just so much in the stdc libraries that it's difficult to achieve 100% coverage. The intention is for any time you have a #include for some C standard header, you can do import core.stdc.someFilePath in D. If there are missing functions, and they aren't OS specific, please file a bug report, and if you're up to it, add the function in a PR. -Steve
Re: More fun with autodecoding
On 9/10/18 1:45 AM, Chris wrote: After a while your code will be cluttered with absurd stuff like this. `.byCodeUnit`, `.byGrapheme`, `.array` etc. Due to my experience with `splitter` et. al. I tried to create my own parser to have better control over every step. I considered that, but I'm still trying to make this buffer reference thing work. Phobos just needs to be fixed. This is actually not as hopeless as I once thought. But what needs to happen is all of Phobos algorithms need to be tested with byCodeUnit et. al. After a few *minutes* of testing things I ran into this bug [1] that didn't get fixed till early 2018. I never started to write my own step-by-step parser. I'm glad I didn't. It actually was fixed accidentally in 2017 in this PR: https://github.com/dlang/druntime/pull/1952. The bug was closed in 2018 when someone noticed the code no longer failed. Essentially, the whole string switch algorithm was replaced with a completely rewritten better approach. This is a great example of why we should be moving more of the compiler magic into the library -- it's just easier to write and understand there. I wish people began to realize that string handling is a basic necessity and that the correct handling of strings is of utmost importance. Please keep us updated on how things work out (or not) for you. Absolutely, D needs to have great support for string parsing and manipulation. The potential is awesome. I will keep it up, what I'm trying to fix is the fact that using std.algorithm to extract pieces from a buffer, but then using the position in that buffer to determine things (i.e. parsing) is really difficult without some stupid requirements like pointer math. [Please, nobody answer my post pointing out that a) we don't understand Unicode and b) that it's an insult to the Universe to draw attention to flaws that keep pestering us on an almost daily basis - without trying to fix them ourselves stante pede. As is clear from Steve's efforts, the Universe doesn't seem to care.) I don't characterize it as the universe not caring. Phobos has a legacy problem with string handling, and it needs to somehow be addressed -- either by painfully extracting the problem, or painfully working around it. I don't think anyone here thinks there isn't a problem or that it's insulting to bring it up. But anything that needs to be done is painful either way, which is why it's not happening very fast. -Steve
Re: This is why I don't use D.
On Sunday, 9 September 2018 at 14:28:11 UTC, Guillaume Piolat wrote: I don't manage to find x-module search again, perhaps disabled. Yeah, there's a memory leak in it so leaving it up would kill the box to build actual docs. And the last couple months have been crazy IRL, but I scheduled some time this week to work on the code again (last week, pushed up a new parser with the uda on params support, etc btw). I think my solution is going to be to dump the search index in a rdbms and let it manage the memory lol (though it is an immutable binary tree, why it leaks is kinda beyond me, probably just sloppy code somewhere like "foo" ~ desc).
[Issue 15321] std.format.format is impure for doubles
https://issues.dlang.org/show_bug.cgi?id=15321 Timoses changed: What|Removed |Added CC||timos...@gmail.com --- Comment #1 from Timoses --- Duplicate of 17628 ? --
Re: code.dlang.org package list
On Monday, 10 September 2018 at 00:56:37 UTC, void wrote: On Sunday, 9 September 2018 at 06:32:39 UTC, Jonathan M Davis wrote: On Saturday, September 8, 2018 8:36:26 PM MDT void via Digitalmars-d wrote: On Sunday, 9 September 2018 at 01:30:14 UTC, Neia Neutuladh wrote: > On Sunday, 9 September 2018 at 00:20:04 UTC, void wrote: >> [...] > > https://code.dlang.org/packages/index.json > > https://code.dlang.org/api/packages/[package name]/info Thanks. I downloaded 100 packages from code.dlang.org and search for "*doc*" and "*example*" The results: 13 packages with "*doc*" 41 packages with "*example*" 55 packages with neither 8 packages with both What would you expect that to tell you? ddoc doesn't require any kind of doc folder (though some projects would have one for custom ddoc files that then affect how the documentation looks), and usually, the best way to handle examples is to use ddoc-ed unittest blocks. So, while in some cases, it would be appropriate to have some sort of additional documentation or examples separate from the source code, in general, there isn't much need for it. So, I don't know what information anyone would expect to get from whether or not a project has any folders with doc or example in their name. - Jonathan M Davis Script updated now searches for the string "unittest" on package directory (*.d files only). Result: 48 packages with "unittest" That means there is ~= 50% chance an user should read the library source in order to use it. To be fair I should manually check if README.md is decent enough. I'm sorry, but it's not even close to accurate, because some libraries has documents on additional websites that has examples and no examples directly in the source code using "standard unittests" - This is true for most big libraries / frameworks. You can't really measure such a thing accurately.
Re: libmir: recent updates
On Monday, 10 September 2018 at 04:50:37 UTC, Shigeki Karita wrote: [snip] great. numir (numpy like helper functions library) also supports mir-algorithm v2 today https://github.com/libmir/numir/releases Glad to hear it. I hope the v2 API helps with explaining mir.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh wrote: On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote: To me, this strongly suggests the following idea: - add *all* dlang.org packages to our current autotester / CI infrastructure. - if a particular (version of a) package builds successfully, log the compiler version / git hash / package version to a database and add a note to dlang.org that this package built successfully with this compiler version. Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/. The current backfill is taking the three most recent versions of each package on the ~40 most recent versions of dmd, using a list of dub packages from a couple days ago. Each compiler version takes about six hours, so the backfill will be finished in about ten days. The report should update automatically every 100 builds. Once that's done, I'll extend the backfill to handle all package versions, have it get new package versions from dub, and get it to discover and download new DMD versions automatically. This shouldn't be a huge change. Nice work. I wonder about some of your results, as it says that dub itself doesn't build with all of the dmd versions, but somehow the tests pass sometimes (shouldn't be possible if you can't build dub itself). I just tested with `dub fetch dub; dub build dub` with the dub 1.10 that comes alongside dmd 2.081.1 on linux/x64 and it built the latest dub 1.11 without a problem. Regardless, you should talk to Sonke about getting this integrated with code.dlang.org and to Mike about putting up a funding target to pay for both permanent server resources and your time coding this up. I've already said I'd donate towards such a target: https://forum.dlang.org/post/acxedxzzesxkyomrs...@forum.dlang.org
Re: code.dlang.org package list
On Monday, 10 September 2018 at 00:56:37 UTC, void wrote: On Sunday, 9 September 2018 at 06:32:39 UTC, Jonathan M Davis wrote: I downloaded 100 packages from code.dlang.org and search for "*doc*" and "*example*" Script updated now searches for the string "unittest" on package directory (*.d files only). Result: 48 packages with "unittest" Ok, this is really a scary result. Is really more than half the packages around not using unittests?!? I can't believe it...
[Issue 19237] New: string mixin struct initializer doesn't compile
https://issues.dlang.org/show_bug.cgi?id=19237
Issue ID: 19237
Summary: string mixin struct initializer doesn't compile
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: radu.raca...@gmail.com
The following, will not compile
```
struct S
{
int i;
}
void main()
{
S s = mixin(`{1}`);
}
```
Error:
found } when expecting ; following statement
app.d-mixin-8(8): Error: found End of File when expecting } following compound
statement
But this will compile:
```
struct S
{
int i;
}
void main()
{
S s = mixin(`S(1)`);
}
```
I think the initializer should compile, as array initializers are allowed in
the mixin, for example this works:
```
struct S
{
int i;
}
void main()
{
S[] s = mixin(`[S(1), S(2)]`);
}
```
--
dub doesn't work with dmd 1:2.082.0-1.0?
dub was working nice until I updated my system (I run ArchLinux32) just now. dmd was updated from version 1:2.081.2-1.0 to 1:2.082.0-1.0 (according to pacman package manager). After that, I couldn't invoke dub for anything. Here is the attempt to run `dub --vverbose`: ``` Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/superprower/.dub/packages/local-packages.json Try to load local package map at /home/superprower/.dub/packages/local-packages.json iterating dir /home/superprower/.dub/packages/ iterating dir /home/superprower/.dub/packages/ entry ncurses-master iterating dir /home/superprower/.dub/packages/ entry local-packages.json iterating dir /home/superprower/.dub/packages/ entry d-profile-viewer-1.1.3 No package found in current working directory. Failed to invoke the compiler /usr/bin/dmd to determine the build platform: Error: missing or null command line arguments Full exception: object.Exception@source/dub/compilers/compiler.d(127): Failed to invoke the compiler /usr/bin/dmd to determine the build platform: Error: missing or null command line arguments ??:? pure @safe bool std.exception.enforce!().enforce!(bool).enforce(bool, lazy const(char)[], immutable(char)[], uint) [0xa744bd] ??:? dub.platform.BuildPlatform dub.compilers.compiler.Compiler.probePlatform(immutable(char)[], immutable(char)[][], immutable(char)[]) [0x80759e] ??:? dub.platform.BuildPlatform dub.compilers.dmd.DMDCompiler.determinePlatform(ref dub.compilers.buildsettings.BuildSettings, immutable(char)[], immutable(char)[]) [0x81323f] ??:? [0x810de2] ??:? void dub.commandline.PackageBuildCommand.setupPackage(dub.dub.Dub, immutable(char)[], immutable(char)[]) [0x910e46] ??:? int dub.commandline.GenerateCommand.execute(dub.dub.Dub, immutable(char)[][], immutable(char)[][]) [0x92b158] ??:? int dub.commandline.RunCommand.execute(dub.dub.Dub, immutable(char)[][], immutable(char)[][]) [0x92b0ab] ??:? int dub.commandline.runDubCommandLine(immutable(char)[][]) [0x9f87e3] ??:? _Dmain [0x9fe3bf] ``` I downgraded dmd for now, but what may be the cause of this? I couldn't find anything related to this particular error (`missing or null command line arguments`).
Re: Small @nogc experience report
On 10/09/2018 9:11 PM, Kagamin wrote: On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: There is no other choice when the runtime is disabled but to have @nogc. It's a fantastic peace of mind for high-performance to be able to _enforce_ something will not allocate. You can't have a working GC allocation with disabled runtime, can you? Yes. GC.disable
DlangUI and android
Is there an emulator that can run the apks? Android emulator does not work, I suppose, because it isn't java. Complains about a missing classes.dex file. I'd rather have an emulator version if possible for quicker dev.
Re: More fun with autodecoding
On Monday, September 10, 2018 2:45:27 AM MDT Chris via Digitalmars-d wrote: > After a while your code will be cluttered with absurd stuff like > this. `.byCodeUnit`, `.byGrapheme`, `.array` etc. Due to my > experience with `splitter` et. al. I tried to create my own > parser to have better control over every step. After a few > *minutes* of testing things I ran into this bug [1] that didn't > get fixed till early 2018. I never started to write my own > step-by-step parser. I'm glad I didn't. > > [1] https://issues.dlang.org/show_bug.cgi?id=16739 > > [snip] I suspect that that that didn't get found sooner simply because using Unicode in a switch statement is rare. Usually, Unicode characters are found in program input and not in the program itself. And grammars typically only involve ASCII characters (even D, which supports Unicode characters in identfiers, doesn't have any Unicode in any of its symbols). So, while I completely agree that using Unicode in switch statements should work, it doesn't really surprise me that it was broken. That's really a large part of the Unicode problem. Regardless of how a particular language or library attempst to make using Unicode sane, a large percentage of programmers don't ever do anything with Unicode characters (even if their programs are often used in environments where they will end up processing Unicode characters), and even when a programmer's native tongue requires Unicode characters, their programs frequently do not. So, it becomes very easy to write code that doesn't work properly with Unicode and have no clue that it doesn't. Fortunately, D does provide better tools than many languages for handling Unicode, but the auto-decoding mess has made it considerably worse. Still, even if we'd gotten it right, some portion of the code out there have to have something like byCodeUnit, byCodePoint, or byGrapheme, because efficient Unicode processing requires that you deal with all of that mess. The code that doesn't have to do any of that is generally code that treats strings as opaque data. Once you actually have to do string processing, you're pretty much screwed. Doing everything at the grapheme level would eliminate most of the problems with regards to user-friendliness, but it would kill efficiency. So, as far as I can tell, there really isn't a great solution to be had. Unicode is simply too complicated and messy by its very nature. Now, we've definitely made mistakes with Phobos that make it worse, but the only programs that are going to avoid this whole mess either do so by not dealing with Unicode, handling it incorrectly, or by handling it inefficiently. I think that it's pretty much a pipe dream to be able to have completely sane and efficient string handling using Unicode as its currently defined. Regardless, we need to do a better job of it in D than we have been. - Jonathan M Davis
Re: Small @nogc experience report
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: There is no other choice when the runtime is disabled but to have @nogc. It's a fantastic peace of mind for high-performance to be able to _enforce_ something will not allocate. You can't have a working GC allocation with disabled runtime, can you?
Re: More fun with autodecoding
On Saturday, 8 September 2018 at 15:36:25 UTC, Steven
Schveighoffer wrote:
On 8/9/18 2:44 AM, Walter Bright wrote:
So it turns out that technically the problem here, even though
it seemed like an autodecoding problem, is a problem with
splitter.
splitter doesn't deal with encodings of character ranges at all.
For instance, when you have this:
"abc 123".byCodeUnit.splitter;
What happens is splitter only has one overload that takes one
parameter, and that requires a character *array*, not a range.
So the byCodeUnit result is aliased-this to its original, and
surprise! the elements from that splitter are string.
Next, I tried to use a parameter:
"abc 123".byCodeUnit.splitter(" ");
Nope, still devolves to string. It turns out it can't figure
out how to split character ranges using a character array as
input.
The only thing that does seem to work is this:
"abc 123".byCodeUnit.splitter(" ".byCodeUnit);
After a while your code will be cluttered with absurd stuff like
this. `.byCodeUnit`, `.byGrapheme`, `.array` etc. Due to my
experience with `splitter` et. al. I tried to create my own
parser to have better control over every step. After a few
*minutes* of testing things I ran into this bug [1] that didn't
get fixed till early 2018. I never started to write my own
step-by-step parser. I'm glad I didn't.
I wish people began to realize that string handling is a basic
necessity and that the correct handling of strings is of utmost
importance. Please keep us updated on how things work out (or
not) for you.
[Please, nobody answer my post pointing out that a) we don't
understand Unicode and b) that it's an insult to the Universe to
draw attention to flaws that keep pestering us on an almost daily
basis - without trying to fix them ourselves stante pede. As is
clear from Steve's efforts, the Universe doesn't seem to care.)
[1] https://issues.dlang.org/show_bug.cgi?id=16739
[snip]
Re: Meson support for Mir and Lubeck
On Mon, 2018-09-10 at 07:25 +, 9il via Digitalmars-d-announce wrote: […] > Interesting, maybe we can go forward with D specific libraries in > the future. Is there any D library that is used by application > packages? Obvious example is Tilix and GtkD. They are compiled with a given version of LDC (and hence Phobos and Druntime). Even if LDC is upgraded, as it just has been, the Druntime and Phobos required by Tilix and GtkD are still there so nothing breaks. This doesn't mean it is all plain sailing: trying to use the updated LDC with the not yet updated GtkD leads to two versions of Phobos seeming to be required. Code still works though. > Mir Optim can be easily used by other libraries and languages, > developers don't need to know D at all as well as depend on > DRuntime and D compiler. > > The problem with Compiler/DRuntime version that it seems like > that if, for example one man released library A that is depend on > DRuntime v1, and other man released library B that depends on > DRuntime v2, how can I use them in my project together if this > DRuntimes are not compatible at ABI level? Maybe we can link > dynamically them together, but how GC will work then (in case of > non BetterC library)? Pass. All I have evidence for is that I am compiling D code with LDC 1.11.0 which requires Phobos and Druntime 2.082 linking with GtkD which required Phobos 2.078 and it all just works. > If a solution of this issue exist, I would be very surprised if > it is easy to go solution. betterC libraries with fixed ABI, and > C/C++ API looks to me like a right way to develop D packages for > Debian. Possibly, but much better to go with what is simplest and most efficacious for the purpose in the context. Libraries destined for use by many different languages clearly need to use the C linkage of the moment. It is mooted that some currently C implemented libraries may be reimplemented in Rust, but will offer a C linkage as nothing else makes sense. […] > > We can choose other library prefix for packages instead of "mir", > say "mirmodule", so it would be libmirmodule-optim. Would this > work? I don't have resource to rename all mir and dependencies. I wonder if this is all a storm in a teacup. As far as I can tell there is no libmir, libmir-optim, libmir-dev, or libmir-optim-dev on Debian, so get in there quick before something changes. On Ubuntu the libraries for Mir the Canonical display server are libmiral… or libmirclient… so there is no actual clash of package name as yet. -- 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: More fun with autodecoding
On Saturday, September 8, 2018 9:36:25 AM MDT Steven Schveighoffer via
Digitalmars-d wrote:
> On 8/9/18 2:44 AM, Walter Bright wrote:
> > On 8/8/2018 2:01 PM, Steven Schveighoffer wrote:
> >> Here's where I'm struggling -- because a string provides indexing,
> >> slicing, length, etc. but Phobos ignores that. I can't make a new type
> >> that does the same thing. Not only that, but I'm finding the
> >> specializations of algorithms only work on the type "string", and
> >> nothing else.
> >
> > One of the worst things about autodecoding is it is special, it *only*
> > steps in for strings. Fortunately, however, that specialness enabled us
> > to save things with byCodePoint and byCodeUnit.
>
> So it turns out that technically the problem here, even though it seemed
> like an autodecoding problem, is a problem with splitter.
>
> splitter doesn't deal with encodings of character ranges at all.
>
> For instance, when you have this:
>
> "abc 123".byCodeUnit.splitter;
>
> What happens is splitter only has one overload that takes one parameter,
> and that requires a character *array*, not a range.
>
> So the byCodeUnit result is aliased-this to its original, and surprise!
> the elements from that splitter are string.
>
> Next, I tried to use a parameter:
>
> "abc 123".byCodeUnit.splitter(" ");
>
> Nope, still devolves to string. It turns out it can't figure out how to
> split character ranges using a character array as input.
>
> The only thing that does seem to work is this:
>
> "abc 123".byCodeUnit.splitter(" ".byCodeUnit);
>
> But this goes against most algorithms in Phobos that deal with character
> ranges -- generally you can use any width character range, and it just
> works. Having a drop-in replacement for string would require splitter to
> handle these transcodings (and I think in general, algorithms should be
> able to handle them as well). Not only that, but the specialized
> splitter that takes no separator can split on multiple spaces, a feature
> I want to have for my drop-in replacement.
>
> I'll work on adding some issues to the tracker, and potentially doing
> some PRs so they can be fixed.
Well, plenty of algorithms don't care one whit about strings specifically
and thus their behavior is really dependent on what the element type of the
range is (e.g. for byCodeUnit, filter would filter code units, and sort
would sort code units, and arguably, that's what they should do). However, a
big problem with with a number of the functions in Phobos that specifically
operate on ranges of characters is that they tend to assume that a range of
characters means a range of dchar. Some of the functions in Phobos have been
fixed to be more flexible and operate on arbitrary ranges of char, wchar, or
dchar, but it's mostly happened because of a bug report about a particular
function not working with something like byCodeUnit, whereas what we really
need to happen is to have tests added for all of the functions in Phobos
which specifically operate on ranges of characters to ensure that they do
the correct thing when given a range of char, wchar, dchar - or graphemes
(much as we talk about graphemes being the correct level for a some types of
string processing, nothing in Phobos outside of std.uni currently does
anything with byGrapheme, even in tests).
And of course, with those tests, we'll inevitably find that a number of
those functions won't work correctly and will need to be fixed. But as
annoying as all of that is, it's work that needs to be done regardless of
the situation with auto-decoding, since these functions need to work with
arbitrary ranges of characters and not just ranges of dchar. And for those
functions that don't need to try to avoid auto-decoding, they should then
not even care whether strings are ranges of code units or code points, which
should then reduce the impact of auto-decoding. And actually, a lot of the
code that specializes on narrow strings to avoid auto-decoding would
probably work whether auto-decoding was there or not. So, once we've
actually managed to ensure that Phobos in general works with arbitrary
ranges of characters, the main breakage that would be caused by removing
auto-decoding (in Phobos at least) would be any code that used strings with
functions that weren't specifically written to do something special for
strings, and while I'm not at all convinced that we then have a path towards
removing auto-decoding, it would minimize auto-decoding's impact, and with
auto-decoding's impact minimized as much as possible, maybe at some point,
we'll actually manage to figure out how to remove it.
But in any case, the issues that you're running into with splitter are a
symptom of a larger problem with how Phobos currently handles ranges of
characters. And when this sort of thing comes up, I'm reminded that I should
take the time to start adding the appropriate tests to Phobos, and then I
never get around to it - as with too many things. I really should fix that.
:|
- Jonathan
Re: GTKD for android?
On Saturday, 8 September 2018 at 02:59:48 UTC, Josphe Brigmo wrote: I have an app I'm writing using GtkD on windows. Eventually I'd like to port it to android. Since I have never been able to actually get anything to work on android I'm curious if there are any demos with gtkD for android? I'm wondering if I just scrap the idea of using it because it won't port without a ton of work. Ideally I'd like to just cross compile and it all work out except for a few bugs. The GtkD maintainer said a couple years ago he might try it when the Android support was better: https://forum.dlang.org/post/o4rq0i$dur$1...@digitalmars.com I don't think anyone's tested it yet, do you know if Gtk supports Android well? The DlangUI maintainer did get his GUI library working on Android, as James mentioned: https://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org
Re: Bug with writeln?
On Sunday, September 9, 2018 8:30:12 AM MDT Saurabh Das via Digitalmars-d- learn wrote: > Thank you for explaining all this. > > It is frustrating because the behaviour is very counterintuitive. > > I will use a workaround for now. Ranges are fantastic, and the basic concept is solid, but a number of the implementation details really weren't worked out well enough in the beginning, which means that there's a lot of stuff that works reasonably well with ranges but falls apart on some level in certain circumstances - and what happens when ranges get copied is a big part of that. On some level, it's what we get for being the first language to really implement ranges as part of its standard library. As I understand it, Andrei didn't create the concept, but AFAIK, it wasn't implemented on any real scale by anyone prior to them being added to Phobos. And when you're the first to implement something, you often screw it up on some level. With many things, D was able to learn from C++ and improve, but this is an area where we got to make new mistakes. The result is something that's extremely useful and largely works but which has some problematic corner cases that really shouldn't be there. - Jonathan M Davis
Re: Will the core.stdc module be updated for newer versions of C?
On Sunday, September 9, 2018 11:37:54 AM MDT Laurent Tréguier via Digitalmars-d wrote: > On Saturday, 8 September 2018 at 01:12:30 UTC, solidstate1991 > > wrote: > > While for the most part it still works very well, however when > > porting Mago I found a few functions that are not present in > > C99 (most notably wcsncpy_s). > > > > While I can write my own functions to do the same (already done > > this with C++'s array since a few classes inherited from > > std::vector, hopefully I don't need to fiddle too much with it > > on the Debug engine to limit reliance on GC) I think it would > > be a good idea to do some updates on the runtime library in > > this regard, especially as it's a very easily available @nogc > > library too. > > I thought the same after having to use Windows-specific functions > from `core.sys.windows`, some (presumably newer) functions are > missing from the definitions. > At that time I thought about trying to get my hands dirty on > this, but I don't know how much time it would take to do that > though. Historically, most of the Win32 API has been missing from druntime, and many of the symbols were in the wrong place (they should really be in modules corresponding to the C headers that the symbols come from, but many of them were just put in core.sys.windows.windows as if everything were in windows.h). Most folks doing serious stuff with the Win32 API used to use an external project that had a much more thorough version of the bindings (though I can't find it at the moment, looking around for D projects with Win and API in the name, so I don't know what happened to it). However, looking over what's in druntime for Windows now, it looks like Vladimir added a ton of bindings back in 2015 (probably from that external project). So, it would appear that the situation for the Windows bindings in druntime is _way_ better than it used to be. Regardless, if you find that a particular binding is missing, feel free to create a PR for it. Usually, such bindings only get added when someone wants to use a particular C function and then discovers that the binding is missing, so they create a PR to add it. It's not like we have a system for discovering all of the bindings that are supposed to be there, and while occasionally, someone will make an effort to make the bindings more comprehensive, it's not something that's regularly worked on. - Jonathan M Davis
Re: Will the core.stdc module be updated for newer versions of C?
On Friday, September 7, 2018 7:12:30 PM MDT solidstate1991 via Digitalmars-d wrote: > While for the most part it still works very well, however when > porting Mago I found a few functions that are not present in C99 > (most notably wcsncpy_s). > > While I can write my own functions to do the same (already done > this with C++'s array since a few classes inherited from > std::vector, hopefully I don't need to fiddle too much with it on > the Debug engine to limit reliance on GC) I think it would be a > good idea to do some updates on the runtime library in this > regard, especially as it's a very easily available @nogc library > too. If you need a specific C function, it's trivial to create the binding in your own code. So, just because a binding is missing from druntime doesn't mean that you have to write your own solution rather than using the C solution. druntime contains the stdc and OS bindings for convenience and because some of them are necessary for druntime, Phobos, and dmd, but a binding doesn't have to actually be there for you to be able to use a C stdc function. It's just more convenient that way. In any case, if you find that a particular stdc function has no bindings in druntime, feel free to create a PR. The same goes for OS functions (though those are more of a mess - especially on Windows). While occasionally, someone will go to a lot of effort to improve or update some portion of the bindings, for the most part, they only get changed when someone figures out that they need to be updated, or there's a particular binding that they want that isn't there. Those bindings aren't usually very actively maintained in the sense that someone is regularly taking the time to ensure that every binding that should be there is there or that they're all up-to-date. Most of the symbols involved change very rarely, so they don't need to be updated often, but because no one is really focusing on them, pretty much the only way that a new symbol is gets added is because someone wants to use it, figures out that it's missing, and creates a PR for it. - Jonathan M Davis
Re: Meson support for Mir and Lubeck
On Monday, 10 September 2018 at 06:31:44 UTC, Russel Winder wrote: On Sun, 2018-09-09 at 21:22 +, 9il via Digitalmars-d-announce wrote: […] Looks like that only betterC projects are good enough to become Debian packages. Generally because of the have stable C ABI that does not depend on D compiler version at all. I do not follow the logic here at all. Any and all projects with a CMake, Meson, SCons, even Make build be Debian packages. Many Debian packages depend on specific versions of things like GCC runtime or LLVM. The Debian packaging system allows for many versions of libraries to co-exists. Thus supporting multiple versions of Druntime and Phobos is possible. Interesting, maybe we can go forward with D specific libraries in the future. Is there any D library that is used by application packages? Mir Optim can be easily used by other libraries and languages, developers don't need to know D at all as well as depend on DRuntime and D compiler. The problem with Compiler/DRuntime version that it seems like that if, for example one man released library A that is depend on DRuntime v1, and other man released library B that depends on DRuntime v2, how can I use them in my project together if this DRuntimes are not compatible at ABI level? Maybe we can link dynamically them together, but how GC will work then (in case of non BetterC library)? If a solution of this issue exist, I would be very surprised if it is easy to go solution. betterC libraries with fixed ABI, and C/C++ API looks to me like a right way to develop D packages for Debian. […] > I only worry about potential name clashes with Mir (the > display server) in Ubuntu ^^ This is going to be a naming problem. Debian has many of these sort of naming clash and usually it is best for the smaller, newer project to accept that they need to choose a non-clashing name. Recent example the Mu editor, but there are many instances of this. D's Mir needs to choose a name that doesn't clash with Canonical's Mir. We can choose other library prefix for packages instead of "mir", say "mirmodule", so it would be libmirmodule-optim. Would this work? I don't have resource to rename all mir and dependencies.
Re: Is there websocket client implementation for D
On Tuesday, 24 March 2015 at 17:55:38 UTC, Ilya Korobitsyn wrote: Hello! Is there any websocket client implementation in D? I know there is WS server as a part of vibe.d, but it does not seem to include client. Maybe there are some library bindings that I've missed? We just implemented one in D. See https://github.com/huntlabs/hunt-http/tree/master/examples/WebSocketDemo
Re: [vibe-d/dub] Lin
On Friday, 7 September 2018 at 16:37:18 UTC, MamoKupe wrote: On Friday, 7 September 2018 at 16:20:40 UTC, MamoKupe wrote: marcinan@marcinan-PC ~/Pulpit/d $ dub init bibe Package recipe format (sdl/json) [json]: d Invalid format, "d", enter either "sdl" or "json". Package recipe format (sdl/json) [json]: Name [bibe]: Description [A minimal D application.]: Author name [Marcin]: License [proprietary]: Copyright string [Copyright © 2018, Marcin]: Add dependency (leave empty to skip) []: vibe-d Added dependency vibe-d ~>0.8.4 /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto collect2: error: ld returned 1 exit status Error: linker exited with status 1 /usr/bin/dmd failed with exit code 1. On linux Mint with DUB version 1.11.0, built on Sep 1 2018 sudo apt-get install libssl-dev Solved linking problem for now. Yes, but this should be detected by dub before compilation as a missing dependency not after. Someone told, that is is possible by adding the right params to dub.sdl/.json. As an traditional error most "lets try vibe.d"-people see, I would like to ask for changing this. Regards mt.
Re: Meson support for Mir and Lubeck
On Sun, 2018-09-09 at 21:22 +, 9il via Digitalmars-d-announce wrote: > […] > Looks like that only betterC projects are good enough to become > Debian packages. Generally because of the have stable C ABI that > does not depend on D compiler version at all. I do not follow the logic here at all. Any and all projects with a CMake, Meson, SCons, even Make build be Debian packages. Many Debian packages depend on specific versions of things like GCC runtime or LLVM. The Debian packaging system allows for many versions of libraries to co-exists. Thus supporting multiple versions of Druntime and Phobos is possible. > […] > > I only worry about potential name clashes with Mir (the display > > server) in Ubuntu ^^ > This is going to be a naming problem. Debian has many of these sort of naming clash and usually it is best for the smaller, newer project to accept that they need to choose a non-clashing name. Recent example the Mu editor, but there are many instances of this. D's Mir needs to choose a name that doesn't clash with Canonical's Mir. -- 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
