Re: I'm the new package maintainer for D on ArchLinux
On Thursday, 10 August 2017 at 15:36:54 UTC, Wild wrote: And of course congratulations for becoming a TU! :) Thanks, and while I have you here, is there any reason why all the dtools programs have 'dtools-' as a prefix? Some of them have very common names (like "detab") and I was concerned that it may eventually clash with binary name of some other totally unrelated utility from a different package. And for convenience more commonly used / uniquely named ones like rdmd also provide shorter symlink.
Re: I'm the new package maintainer for D on ArchLinux
On Thursday, 10 August 2017 at 14:42:43 UTC, Wild wrote: On Thursday, 10 August 2017 at 14:26:41 UTC, Jacob Carlborg wrote: That's great. Do you want to maintain the package for DStep as well as Dicebot did? I could do that, but what I can see Dicebot still maintains it https://aur.archlinux.org/packages/dstep/ But it could just be that he has forgot to orphan it. Thanks for bringing my attention to it, I have disowned both it and dstep-git. Note though that you could take it over anyway if you intend to move it to [community] as a TU - contacting original author is only matter of politeness. And of course congratulations for becoming a TU! :)
Re: Call for arms: Arch Linux D package maintenance
On Thursday, 2 February 2017 at 10:01:04 UTC, qznc wrote: In another thread [0] Snap packages are discussed. What is the view of Arch? If Snap wins, there would be only one package to maintain for all distros. [0] https://forum.dlang.org/post/mzklrdgeyymuwmtqz...@forum.dlang.org There is snapd daemon available in Arch repositories but with zero support and guarantees for any actual snap packages. I am not aware of any discussions about in TU mail list either.
Re: Call for arms: Arch Linux D package maintenance
On Wednesday, 1 February 2017 at 18:32:48 UTC, Rory McGuire wrote: I use arch and D every day. I'm willing to volunteer. I keep up to date with all releases and keep multiple dmd versions. If I'm maintaining the packages I'd use them (if I can still switch versions of dmd). Are you familiar with the PKGBUILD system? Please ping me via pub...@dicebot.lv
Call for arms: Arch Linux D package maintenance
As I have previously announced (http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com), I am stepping down from maintaining Arch Linux packages for D. That means there are 3 possibilities: - No one will adopt them and all packages will be moved to AUR - Some existing Trusted User decided to adopt them - Someone from D community decides to become Trusted User and adopts them First option is definitely the worst one and I don't see any enthusiasm regarding second option from existing TUs. Is there anyone willing to volunteer for the option three? I promise all the guidance and help in submitting TU application and figuring out maintenance process but there does need to be a volunteer ;) signature.asc Description: OpenPGP digital signature
Re: Release D 2.073.0
On 01/30/2017 12:38 AM, Walter Bright wrote: > ... Please, don't waste your time. You mentioned being curious about what is wrong with that PR - I have explained. Let's just stop here before you write another 20 posts presuming that I only disagree with your development methodology because I don't understand it. signature.asc Description: OpenPGP digital signature
Re: Release D 2.073.0
On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote: On 1/27/2017 3:12 AM, Dicebot wrote: And also stuff like https://github.com/dlang/druntime/pull/1740 I'm curious what is wrong with that? You have been pushing for premature merged of `return scope` under a premise that it will be hidden behind a switch and won't affect anyone yet. Now you rush to adjust druntime to use it and require the same from any druntime contributors.
Re: Release D 2.073.0
On 01/27/2017 01:29 PM, Nordlöw wrote: > On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote: >> And also stuff like https://github.com/dlang/druntime/pull/1740 - I >> think the story behind `return scope` is the critical point for me. It >> is worst technical disaster that has happened to compiler in years, >> and I am going to blame Walter personally for it. > > So what would the alternative be? Alternative would be to implement new functionality like a responsible developer - keep it in sync with specification document, design set of acceptance tests and do all the development in a separate branch until is verified to both have desired semantics and don't cause any breakage in existing projects. And don't rush into forcing usage of half-done feature inside standard library the very moment it got released. signature.asc Description: OpenPGP digital signature
Re: Release D 2.073.0
And also stuff like https://github.com/dlang/druntime/pull/1740 - I think the story behind `return scope` is the critical point for me. It is worst technical disaster that has happened to compiler in years, and I am going to blame Walter personally for it.
Re: Release D 2.073.0
https://issues.dlang.org/show_bug.cgi?id=17123 Can I have my "I told you so" badge please?
Re: Pry v0.3.1 is out!
On Sunday, 15 January 2017 at 13:14:45 UTC, Dmitry Olshansky wrote: I could have wasted time by creating nodes and assigning values in the map functions but if you just want the result of calculation it's all moot. Thanks for explanation! This is indeed very promising and much in spirit of D selling point of zero-overhead convenience abstractions.
Re: Pry v0.3.1 is out!
Sounds intriguing! On 01/15/2017 01:26 AM, Dmitry Olshansky wrote: > - versatility, generating some goofy parse tree is not a goal, the goal > is extraction of data the way the user specifies Can you show an example of what you have in mind for this? signature.asc Description: OpenPGP digital signature
Re: DIP 1003: remove `body` as a keyword
On Saturday, 31 December 2016 at 01:14:23 UTC, Arun Chandrasekaran wrote: On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote: DIP 1003 is merged to the queue and open for public informal feedback. PR: https://github.com/dlang/DIPs/pull/48 Initial merged document: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md If you want the change to be approved and have ideas how to improve it to better match on https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing published reviews - please submit new PR with editorial and ping original author. Bump, if that makes sense. I have asked DIP author if he plans any last moment modifications and will try to schedule it for review in January.
Re: Beta D 2.072.2-b1
On Tuesday, 27 December 2016 at 14:24:11 UTC, Steven Schveighoffer wrote: Missing from the changelog is the cycle detection deprecation path that I added here: https://github.com/dlang/druntime/pull/1720 This should give people more breathing room to remove detected cycles by next release. My understanding is that there is still a lot of manual labor in changelog generation thus making separate PR to adjust https://github.com/dlang/dlang.org/blob/stable/changelog/2.072.2_pre.dd may help.
Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool
After some tweaking and playing have finally uploaded Arch Linux packages for GDC using 6.2.1 gcc base and https://github.com/D-Programming-GDC/GDC/releases/tag/v2.068.2_gcc6 Now also includes new "libpghobos" package providing shared library only (though I haven't tested this part). signature.asc Description: OpenPGP digital signature
Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool
On 12/25/2016 09:41 PM, Johannes Pfau wrote: > Happy holidays everybody, > > I'm happy to finally announce the release of new GDC binaries at > https://gdcproject.org/downloads . GDC is the GNU D Compiler, a D > compiler using GCC as the compiler backend. A lot of great stuff! Got few questions when trying to update Arch Linux package though, could you please advice? 1) There is `gdc_include_dir` variable now, what is intended way to override it to custom path? `gcc/configure gdc_include_dir=/usr/include/dlang/gdc` doesn't seem to work 2) As far as I can see phobos is now built as shared library by default. What flags affect it? I'd like to build either static one, or both at the same time if possible. signature.asc Description: OpenPGP digital signature
Re: DIP1004: Inherited Constructors
On 11/29/2016 12:04 PM, Arafel wrote:
> I think I might be a bit late to the party, and I'm still quite new in
> D... but wouldn't a variadic template constructor work? The usual rules
> of templates would still let you override a constructor if needed.
>
> ---
> class A {
> this() { }
> this(int a) { }
> }
> class B : A {
> // Here we inherit all of A's constructors.
> this(Args...)(Args args) {
> super(args);
> }
> this(string s) { }
> }
> void main() {
> B b1 = new B(42);
> B b2 = new B("foo");
> }
> ---
>
> I've been playing with it, and the only problems I can see are with
> specialization and casting (i.e. B defines this(float), but you want to
> call A's this(int), the int will be promoted to float and B's version
> will be used). A way of disabling them would be needed, though...
> perhaps assert(0)?
Have just answered a similar question in a PR thread:
https://github.com/dlang/DIPs/pull/42#issuecomment-263562276
signature.asc
Description: OpenPGP digital signature
Re: DIP1004: Inherited Constructors
On 11/28/2016 04:57 AM, rikki cattermole wrote:
> On 28/11/2016 3:38 PM, Dicebot wrote:
>> DIP 1004 is merged to the queue and open for public informal feedback.
>>
>> PR: https://github.com/dlang/DIPs/pull/42
>>
>> Initial merged document:
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
>>
>> If you want the change to be approved and have ideas how to improve it
>> to better match on
>> https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing
>> published reviews - please submit new PR with editorial and ping
>> original author.
>
> A few errors like this are in it:
>
> class ParseException : Exception { }
> {
Would you mind a PR? :) I am afraid my eyes are too sloppy after
re-reading the text too many times.
signature.asc
Description: OpenPGP digital signature
DIP1004: Inherited Constructors
DIP 1004 is merged to the queue and open for public informal feedback. PR: https://github.com/dlang/DIPs/pull/42 Initial merged document: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md If you want the change to be approved and have ideas how to improve it to better match on https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing published reviews - please submit new PR with editorial and ping original author. signature.asc Description: OpenPGP digital signature
Re: DIP 1003: remove `body` as a keyword
On 11/24/2016 05:29 PM, WM.H wrote: > On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote: >> DIP 1003 is merged to the queue and open for public informal feedback. >> >> PR: https://github.com/dlang/DIPs/pull/48 >> Initial merged document: >> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md >> >> If you want the change to be approved and have ideas how to improve it >> to better match on >> https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing >> published reviews - please submit new PR with editorial and ping >> original author. > > This DIP fixes the problem for "body" but not for the other keywords. > After all the problem may exist for other keywords. Was a new pragma > considered ? For example an identifier alias. > > pragma(idAlias, "body", "body_" ) AFAIU, the point of this DIP is that "body" is standing out from other keywords being used only in one very specific context and being a very common english word at the same time. Your proposal has a completely different (and much more drastic) approach. signature.asc Description: OpenPGP digital signature
Re: DIP 1003: remove `body` as a keyword
On 11/21/2016 01:33 PM, Sönke Ludwig wrote: > For this whole proposal to work out, though, I think the old syntax will > have to stay supported without deprecations, because the amount of > breakage (the deprecation path won't change that) will otherwise > probably be huge. Making "body" optional + contextual seems to be the > way to go. Can you please elaborate on this? Deprecations don't break anything, using -de flag for any stable project is a bug and misuse of compiler. If we define deprecation term for contextual keyword to be several years, the breakage will almost non-existent, much less than a regular "bug fix breakage" from usual releases. signature.asc Description: OpenPGP digital signature
Re: Formal review of DIP1002
On 11/18/2016 06:09 PM, pineapple wrote: > There should be no need for me to repeat the arguments against the DIP > process already made by others. I will be submitting no more DIPs or > engaging in the process in any way unless and until it is significantly > changed. There seems to be a recurring misconception that submitting a DIP is somehow doing language developers a service. It is exactly other way around - the whole DIP process is designed to help those who are willing to commit hard and selfless work to get something into language. There is hardy any lack of ideas about language improvements at any time. I consider DIP process to fail when one of specific case happens: there is someone willing to commit but that person doesn't get deserved feedback. That was very clearly said in my explanations of the rationale which got published on dlang blog and yet seems to come as surprise. signature.asc Description: OpenPGP digital signature
DIP 1003: remove `body` as a keyword
DIP 1003 is merged to the queue and open for public informal feedback. PR: https://github.com/dlang/DIPs/pull/48 Initial merged document: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md If you want the change to be approved and have ideas how to improve it to better match on https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing published reviews - please submit new PR with editorial and ping original author.
Re: DIP document maintenance
On 11/17/2016 04:36 PM, Andrei Alexandrescu wrote: > On 11/17/2016 09:16 AM, Dicebot wrote: >> 2) It is a regular update. In that case revision number is simply git >> history. For example DIP1002 is currently at revision 7 (git log >> --pretty=oneline DIPs/DIP1002.md | wc -l). >> >> Same goes for update of reviews - everything is tracked in git history. >> At any given point of time you simply throw away everything old and keep >> only most recent versions. > > OK, so we're just using git for versioning, which should work fine. The > one potential issue I see with it is the version number is not > indicative of how many review cycles have been passed. E.g. DIP1002 is > already at revision 7, which is an irrelevant number to the casual > reader. "What do you think of DIP2749?" "Which revision you mean?" "Well > it's revision 38." "Would that be before or after the third review?" etc. Hm, my understanding was that there are not supposed to be multiple formal reviews. Either DIP is marked with "Information Requested" and mentions informal checklist of improvements to be done, or it actually undergoes final judgment and there is only way to "Approved" or "Rejected" from there. If you want to incorporate multiple iterations, some adjustments may indeed be necessary. > I'd like to have a simple tag a la DIP2749 v1 for the first review > round, DIP2749 v2 for the second review round, and so on. So then people > can refer to "DIP2749 v3" in casual conversation. Is this feasible? Yes. Assuming you do want multiple review iterations support, I can imagine something like this: - new "review candidate #" field is added to the header - it is set to 0 on initial merge and to 1 after incorporating initial NG feedback - it also references specific DIP version hash matching time of incrementing the version - changes to DIP are made in a regular manner. When author is done, rc # is incremented and hash gets updated - included reviews refer to specific rc # If that sounds good, I'll make a PR to update README and ping you from there. signature.asc Description: OpenPGP digital signature
Re: Formal review of DIP1002
On Thursday, 17 November 2016 at 15:26:21 UTC, John Colvin wrote: Regardless of the outcome, I just want to commend whoever wrote the rejection text* on doing such a clear and comprehensive job. I'm sure it must be disappointing for a DIP author to have it rejected, but detailed, constructive criticism like this would - for me at least - make the experience worthwhile and encourage further contributions of higher quality. * I see dicebot committed, but I'm presuming Walter &| Andrei had a lot of input and I think i detect recent exposure to the academic review process... The text was sent to me by Andrei, though I presume Walter did take part in making the decision :) Hopefully such high quality and detailed feedback will provide a much more clear picture about expectations from DIP content and overall chances for various kinds of proposals to be approved.
DIP document maintenance
On 11/17/2016 03:20 PM, Andrei Alexandrescu wrote: > On 11/17/2016 06:37 AM, Dicebot wrote: >> Disposition: REJECT. A proposal for a similar or identical feature would >> need to be include qualitatively new motivation/evidence of usefulness. >> >> Please follow the link for the full review text / rationale: >> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review > > Thanks Dicebot for carrying the process through. I think we need a > versioning mechanism for DIPs. In the general case we'll have the > disposition "Changes Requested", which will prompt the DIP authors to > revise the DIP. The DIP will keep its number but will receive a new > revision (either a newer commit or, more likely, an entirely new > document). That revision will receive a new, separate review etc. -- Andrei Don't think I understand the process you have in mind. Right now there are two possible cases for updating DIP: 1) It was rejected and someone wants to submit a drastically different proposal on same topic. This has to come as brand new DIP document with own number. 2) It is a regular update. In that case revision number is simply git history. For example DIP1002 is currently at revision 7 (git log --pretty=oneline DIPs/DIP1002.md | wc -l). Same goes for update of reviews - everything is tracked in git history. At any given point of time you simply throw away everything old and keep only most recent versions. Am I missing something in your requirements? signature.asc Description: OpenPGP digital signature
Formal review of DIP1002
Disposition: REJECT. A proposal for a similar or identical feature would need to be include qualitatively new motivation/evidence of usefulness. Please follow the link for the full review text / rationale: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review signature.asc Description: OpenPGP digital signature
Formal review of DIP1001
Disposition: REJECT. A proposal for a similar or identical feature would need to be include qualitatively new motivation/evidence of usefulness. Please follow the link for the full review text / rationale: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md#review signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On 11/11/2016 09:36 PM, Nick Sabalausky wrote: > On 11/11/2016 08:30 AM, Dicebot wrote: >> On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote: >>> Run the new dmd. If it fails, either fix your code or go temporarily >>> go back to the old dmd until you can fix your code. >> >> D will never be considered production ready as pong as this attiude >> remaind. Your described scenario in practice works like this: >> >> - You decide to delay fix until you have time to investigate > > I've gone through a lot of compiler upgrades on a lot of D projects, and > in my experience, this "investigate and fix for the new dmd" has always > been trivial (aside from one instance where Phobos's standard function > deprecation policy wasn't followed). Speaking of Sociomantic experience, practice has shown that any breaking change that requires 5 min fix for any given project can easily take from weeks to months (!) before all maintained interdependent projects are updated. With deprecations it is not a problem at all because everyone moves on using own schedule caring only about hard time limit. With _any_ sort of immediate breakage it is pain because now upgrade both becomes urgent and needs to be explicitly synced between all developers. It is simply another side of "nine women can't make a baby in one month" thing. Best way to scale large teams is to split them so that amount of people involved in any specific process is minimal, otherwise even trivialities escalate exponentially under weight of communications. And with software development "large" starts pretty small. > Some things should certainly have a smooth transition path (like above, > when replacing a Phobos function with a different one), but really, not > everything needs to be. > >> - Half of users of your library you (or your colleagues) complain that >> they can't upgrade their projects because you areso slow >> - You desperately find time to do required fix which proves bavkwards >> incompatible > > AFAICT, That's not the case with this particular cycle detection matter. Yes, but this is mentality I am talking about. In vast majority of cases providing smooth deprecation path is trivial - replacing `error` call with `deprecation` call in DMD patch, marking symbol as deprecated before removing in Phobos. In some of PRs I have found while checking last breakage, amount of time spent on discussion if it is OK to make a change was 10x more than amount of time that adding deprecations would take. It is waste of everyone's time! We need to establish attitude were doing deprecations is a no-brainer, like providing unittests for new functionality already is. Not because some weird corporate ass demands it but because it is simple and benefits the whole dub ecosystem. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On 11/12/2016 02:20 PM, Basile B. wrote: > On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: >> Glad to announce D 2.072.0. >> >> http://dlang.org/download.html >> >> This is the release ships with the latest version of dub (v1.1.0), comes >> with lots of phobos additions and native TLS on OSX. >> See the changelog for more details. >> >> http://dlang.org/changelog/2.072.0.html >> >> -Martin > > Sorry another regression: > > https://issues.dlang.org/show_bug.cgi?id=16682 > > I don't know if it's a real regression, maybe the PR that breaks dfmt is > legit but at least > - you (you == dlang team as an entity) could start a deprecation period. > - the community could detect that before. Thank you for the report! Will add that to required reverts in a moment. Both points you have mentioned indeed can and should be addressed. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On 11/11/2016 03:46 PM, Steven Schveighoffer wrote: >> ... or one can spend one extra hour to implement deprecation path and >> the issue disappears completely. > > There is a misunderstanding that the new cycle detection is an "upgrade" > of some kind. It's a bug fix. There is no difference between a bug fix and "upgrade" in context of deprecation path expectations. It affects robustness of package ecosystem in the same way. > There is a path to use new DMD with your buggy code, just use > --DRT-oncycle=ignore. It's just not the default. Well, this is the reason why I haven't filed it as a regression. It is bad, but being able to ignore detection if rt flag makes it tolerable. I am still going to look into keeping both algorithms for this release but don't view it as blocking regression. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote: Run the new dmd. If it fails, either fix your code or go temporarily go back to the old dmd until you can fix your code. D will never be considered production ready as pong as this attiude remaind. Your described scenario in practice works like this: - You decide to delay fix until you have time to investigate - Half of users of your library you (or your colleagues) complain that they can't upgrade their projects because you areso slow - You desperately find time to do required fix which proves bavkwards incompatible - Now the other half of your users (colleagues) complain that your rush to upgrade forces them to switch to immature compiler .. or one can spend one extra hour to implement deprecation path and the issue disappears completely.
Re: Link Time Optimization in LDC
On Thursday, 10 November 2016 at 16:20:33 UTC, Johan Engelen wrote: Hi all, Yesterday I merged LTO capability into LDC. Here a short article about it: https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html For the folks building LDC themselves: let me know your issues :) cheers, Johan Does that mean that cross-module/cross-package inlining with separate compilation now works?
Re: Release D 2.072.0
On 11/05/2016 06:04 AM, Soulsbane wrote:
> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>> Glad to announce D 2.072.0.
>>
>> http://dlang.org/changelog/2.072.0.html
>>
>> -Martin
>
> I've run into a problem with code using ctRegex that fails to compile
> only in release build.
Can't reproduce:
$ cat sample.d
unittest
{
import std.regex;
static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}
$ dmd-dev -release -O -inline -unittest -main -run sample.d
Can you provide more details?
signature.asc
Description: OpenPGP digital signature
Re: Release D 2.072.0
On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote: This is not possible. Old behavior DID detect some cycles. The new algorithm detects ALL cycles, and handles them all in the same way. What you are asking is for cycles detected by old algorithm to fail, but ones that wouldn't have been detected to pass. Not to mention that the order of ctor execution is not guaranteed to be the same (i.e. some latent bug may be hiding there). Only possibility is just to ignore ALL cycles, and print them if any are detected. I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? The PR for this was here: https://github.com/dlang/druntime/pull/1668 Thanks! I'll have to check the code first :)
Re: Release D 2.072.0
On 11/03/2016 05:51 PM, Steven Schveighoffer wrote: > On 11/3/16 10:49 AM, Johan Engelen wrote: >> On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: >>> On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... >>> >>> Maybe after this: >>> >>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 >>> >>> >>> >>> ddmd.attribs was removed >>> >>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 >>> >>> >>> >>> and it was also part of the cycle. >> >> Thanks for the detective work. >> I wonder where the bug is: in 2.071 or in 2.072 :) > > Any cycles that are "newly discovered" were already there. What was > happening is that the runtime did not detect the cycle, and was > arbitrarily choosing an order for initializing these modules. It does not justify immediate breaking change. What should have been done instead: - Keep old behavior by default by default but print non-fatal runtime message that cycles are detected. - Provide options both to make cycle detection fatal and to suppress message completely. - Make fatal one the default one release later I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
Sadly, because of overwhelming project breakage I have to revert Arch Linux dmd package version back to 2.071.2 until 2.072.1 is out :( Going to look into known regressions later this week, at least some of them look easily fixable to become deprecations. signature.asc Description: OpenPGP digital signature
Re: Release D 2.072.0
On 10/31/2016 03:27 AM, Martin Nowak wrote: > Glad to announce D 2.072.0. NB: Current release notes are outdated and wrong about `-transition=safe` flag. It was completely repurposed in stable branch (https://github.com/dlang/dmd/pull/6183) but somehow changes to release notes there do not propagate to released changelog. signature.asc Description: OpenPGP digital signature
Re: Battle-plan for CTFE
On 10/30/2016 11:19 PM, Stefan Koch wrote: > Oh shoot! > I did not enable the new call system :( > This computed by the old interpreter. > > The new engine fails :( Stefan, would you mind creating a dedicated topic in main D newsgroup to report your development progress? Bumping the thread in announce NG like that is rather distracting, we should aim for posting only most important/relevant info there. signature.asc Description: OpenPGP digital signature
Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.
On 10/11/2016 04:13 PM, Joakim wrote:
> On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek wrote:
>> http://code.dlang.org/packages/dstatsd
>>
>> StatsD allows to collect statistics about any application by using
>> counters, gauges and more through UDP.
>>
>> Usage:
>>
>> auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd server
>>
>> s(Counter("Foo")); // increment counter "Foo"
>> s.inc("Bar"); // increment counter "Foo"
>>
>> s(Counter("Args"), // send stats to Args, H, and timeA
>> Counter("H", someIntValue), // in one UDP message
>> Timer("timeA", someTimeInMS)
>> );
>>
>> {
>> auto a = ScopeTimer("args", s); // automatic time collection
>> }
>
> Never heard about this either, I ignore node.js stuff. I was just
> reading this interesting post on tracing/profiling a couple days ago: is
> it efficient enough to find some of these tail latency issues?
Stats aggregation usually has nothing to do with fine tuned performance
profiling - it is application defined way to monitor relevant metrics of
runtime behavior. For example, one can aggregate metrics for web app
request processing latencies to monitor if those stay within expected
margin - but if issue is spotted, it won't help much in debugging _why_
it has happened.
signature.asc
Description: OpenPGP digital signature
Re: Beta 2.072.0-b2
On Sunday, 9 October 2016 at 22:01:31 UTC, Martin Nowak wrote: On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote: Which branch changelog content is generated from? Stable, the changelog is also included in the docs that are in the packages. I do merge stable back into master to publish them though. I am confused in that case. What shall I do to replace http://dlang.org/changelog/2.072.0.html#dash_safe with my changes from https://github.com/dlang/dmd/blob/stable/changelog.dd ?
Re: Beta 2.072.0-b2
Which branch changelog content is generated from?
Re: Munich D Meetup
On Sunday, 25 September 2016 at 20:49:47 UTC, Stefan wrote: On Tuesday, 2 August 2016 at 18:33:02 UTC, Stefan wrote: Topic is "D's Gems: Ranges" Speakers are Mario (Author of dunit and duml) and Dragos (Author of asynchronous). We did the first Meetup. Roughly 20 people have been there, with very interesting questions during the whole Meetup. (Hopefully this will continue in such numbers!). Wow, that is quite an impressive participation!
Re: Beta D 2.071.2-b3
On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote: On Wednesday, 31 August 2016 at 09:56:17 UTC, Johan Engelen wrote: (I can only think of complicated stuff that requires pretty much whole-program analysis to prove validity, and in that case adding `private` doesn't help any more) Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls. There are enough ways to leak access to private entity (alias, template argument, taking address, some compile-time introspection) to make such optimizations impossible without extensive program analysis.
DIP1001: DoExpression
http://forum.dlang.org/post/nqem7g$1hm6$1...@digitalmars.com signature.asc Description: OpenPGP digital signature
Re: Beta D 2.071.2-b3
On 08/31/2016 02:08 AM, Martin Nowak wrote: > On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote: >> I'm a bit sad to see that >> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored >> to fix issue 15907. Another decision could have been to break the >> visibility for the traits allMember, getMember, derivedMember and >> getOverloads. > > Well there was reasoning to choose that solution instead of the other > (https://github.com/dlang/dmd/pull/6078) and the fact that private > members aren't accessible (set/get) is a good indication that nobody > needs this. > Adding an unsafe facility to access private members is a separate > problem, but please see the changelog for how to achieve this already by > mixing in templates. I think such change is not appropriate in a point release, not matter if it is going to happen or not. signature.asc Description: OpenPGP digital signature
Re: The D Language Foundation is now a tax exempt non-profit organization
On 08/30/2016 05:25 PM, Andrei Alexandrescu wrote: > Unless we have a sort of branch in other countries, I don't see what we > can do here. -- Andrei EU branch of D foundation would be interesting but I think it is much premature to think about that :) signature.asc Description: OpenPGP digital signature
Re: [GSoC] Improvements for dstep
On 08/27/2016 10:23 PM, ciechowoj wrote: > Hi. > > I would like to publish a report of my work for this year GSoC. Over the > last few months, I've been making improvements and fixing bugs for dstep. > > You can check out the changes I've made by following this link: > > https://github.com/ciechowoj/dstep/commits/master?author=ciechowoj > > ... I have been following dstep improvements ciechowoj did and I must say it is a great job! The tool has become both smarter in terms of supported features and more reliable in terms of C headers it is capable of converting. Keep rocking and good luck! signature.asc Description: OpenPGP digital signature
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 20:54:02 UTC, Walter Bright wrote: On 8/27/2016 9:04 AM, Dicebot wrote: Please never reply to that person unless you are his other account. Not in an announce threads at least. If the post is reasonably professional, it's ok to. Abusive posts just get deleted. There have never been a single professional or at least constructively fashioned post from that account and tolerating that harms D public image. I have learned not to argue about this but I am very unhappy that you not only allow but encourage both off-topic and flamebait derailing of _announcement_ threads.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote: ... Please never reply to that person unless you are his other account. Not in an announce threads at least.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 06:37:58 UTC, Andrej Mitrovic wrote: On 8/21/16, Dicebot via Digitalmars-d-announce wrote: This week I had a tele-meeting with Andrei and Walter regarding the fate of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) Trivia question: why is it named DIP 1000? We've had less than 100 DIPs before https://github.com/dlang/DIPs was opened, the jump seems very arbitrary to me (and it makes it appear as if we had a thousand DIPs already to the outsiders) To clearly disambugate all new DIPs from all old ones by the number only.
Re: On the future of DIP1000
On 08/22/2016 09:44 AM, Jacob Carlborg wrote: > It would be nice to have the whole picture now, before implementing > DIP1000. Then it's possible to review them together, making sure the end > goal is actual possible to achieve. Now we just have to trust Andrei and > Walter that all features will come together making the end goal > possible. We've already seen in the past that some features don't play > well together. My understanding is that those are not supposed to be related in any direct way and danger of @trusted destructor is inherent to DIP1000 design (it should be better clarified in document itself though, see https://github.com/dlang/DIPs/pull/35) > I'm also not a big fan that the DIP is approved right from the start. > Then it's not a DIP, it's more of a FYI. It makes the whole process kind > of pointless since Andrei and Walter can choose to ignore the feedback. By its design definition DIP process is for approving communitty proposals by Walter/Andrei thus there is no point in pretending they can't ignore the feedback. Only reason it is even processed in the same queue is so that developers can track all major proposed changes in one place. I would personally prefer to see more of a commitee approach for validating such changes but that concept is far beyond available resources and community engagement. If both language authors agree that certain issue is urgent to solve than, in absence of formally written counter-proposals, there is no other way but to move ahead. Again, the DIP process is not for Walter or Andrei - it is for everyone else wanting to get their attention and submit good quality technical proposal. I hope authors of already submitted DIPs will improve them to required content bar and we will see how the process actually work but that is still to come. Note that during the meeting I did go through the list of all comments submitted through the community feedback to ensure that nothing was simply missed or forgotten and every issue is acknowledged. But all the decision making is 100% for Andrei/Walter in the end and I don't see how it can be different with existing state of affairs. signature.asc Description: OpenPGP digital signature
Re: On the future of DIP1000
On 08/22/2016 12:46 AM, John Colvin wrote: > On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: >> - scope is @safe only > > Why? I might have @system code that could still benefit from scope. Because it can't provide expected guarantees within feature set allowed by @system - it is too permissive for such simple system. Probably actual scope semantics will remain in @system but it won't guarantee anything. signature.asc Description: OpenPGP digital signature
On the future of DIP1000
This week I had a tele-meeting with Andrei and Walter regarding the fate of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) and intented way to move forward with it. This is a short summary of the meeting. Approval of DIP1000 --- DIP1000 is going to be approved as the basis of the idea but exact specification may change during implementation and as a result of incorporating some ideas from feedback threads (http://forum.dlang.org/thread/pqsiqmkxenrwxoruz...@forum.dlang.org and http://forum.dlang.org/thread/rwxcfapvpfiqmfsui...@forum.dlang.org). Core principles that are sure to stay at this point: - scope is a storage class - scope is non-transitive - scope is @safe only - responsibility of implementing complicated scope-using types is on developer, compiler magic is intended to be minimal Any changes in intended DIP1000 spec will be reflected in original document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). Implementation of DIP1000 - Walter is currently working on implementing the support via https://github.com/dlang/dmd/pull/5972, which will take some time. Once it is more feature complete I'll contact Martin for possible out-of-release preview compiler builds from that branch to try it out easily. About that time we will start another feedback thread in the NG with a more practical focus - featuring more code examples and design idioms. Life after DIP1000 -- It is acknowledged that DIP1000 itself does not allow to implemented completely @safe reference counting, primarily because of an issue with @trusted destructor and re-assignment. Intention is to follow up with another proposal (not directly related) to address the issue from another angle - but this will only become in focus after DIP1000 is finished.
Re: DIP1000: Scoped Pointers
On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
> That will just leave one hole in conjunction with the @trusted
> destructor, which is (presumably) not easy to fix without much larger
> changes to the type system, as well as to how container types are built.
> It is still vulnerable to artificial shortening of the elements'
> lifetime, e.g. by using opAssign() or destroy():
>
> @safe {
> RefCountedSlice!int s = ...;
> scope int* el;
> el = &s[0];
> s = RefCountedSlice.init;
> *el = 12; // oops
> }
I asked Walter about this in more details and right now plan is to
address it in a separate DIP that provides more integration between
reference counting and compiler. Within DIP1000 terms such destructor
must not be marked as @safe - essentially, it will only enable @safe
usage of stack allocated data in its initial form.
> A similar issue affects the library implementation of isolated memory
> that I did a while ago:
>
> @safe {
> class C { int* x; }
>
> // c is guaranteed to be only reachable through this variable
> Isolated!C c = makeIsolated!C();
>
> // c.x is a @property that returns a specially wrapped reference to
> // the actual C.x field - with this DIP this is similar to a 'scope'
> // return, but acts transitively
> Scoped!(int*) x = c.x;
>
> // one of the benefits of Isolated!T is that it allows @safe
> // conversion to immutable:
> immutable(C) ci = c.freeze();
> // c gets cleared by freeze() to disallow any further modifications
>
> // but, oops, x is still there and can be used to modify the now
> // immutable contents of ci.x
> *x = 12;
> }
>
> Disallowing the assignment of scope return references to local scope
> references (either by default, or using some form of additional
> inference/annotation) would solve this particular issue, but not the
> issue in general (the assignment/destruction could for example happen in
> a nested function call).
Note that using scope return in its most basic form will exactly prevent
the assigning of reference to a variable because it limits lifetime to
expression.
signature.asc
Description: OpenPGP digital signature
Re: DIP1000: Scoped Pointers
On 08/17/2016 04:01 AM, Chris Wright wrote: > On Tue, 16 Aug 2016 18:55:40 +0000, Dicebot wrote: >> You need to add one more level of indirection for things to start going >> complicated. > > Presumably scope is transitive, so things shouldn't get horribly complex. It is not transitive and it is not a type qualifier. signature.asc Description: OpenPGP digital signature
Re: DIP1000: Scoped Pointers
On 08/17/2016 10:53 AM, Mike wrote:
> On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:
>>
>>> If DIP1000 is implemented, it will change that behavior, so the
>>> allocation will instead be on the GC heap, but the compiler will do some
>>> flow-control analysis to prevent escaping references. Is that right?
>>>
>>> Mike
>>>
>>
>> Not correct, the class would still be on the stack so we can have
>> reference semantics during assignment etc, but the instance is on the
>> stack so its faster and the function the code is inside can optionally
>> be nogc.
>>
>> DIP1000 will just make the compiler check that a stack instance does
>> not escape its scope (though it doesn't cover all cases).
>>
>> struct Astruct {} // - on stack by default
>> class Aclass {} // - on heap by default
>> void main() {
>> Astruct a = new Astruct; // override, now Astruct is on the heap
>> (because of "new")
>> Aclass c = new Aclass; // on the heap as per-usual
>> scope Aclass c1 = new Aclass; // override, now class is on the stack
>> (most obvious use: to make all references use the same instance)
>> }
>
> Got it! Thank you! But it still appears that what's illustrated on the
> deprecations page is not being deprecated.
>
> Mike
Yes, it will have to be updated - but I didn't want to adjust it before
DIP1000 spec is finalized. Rationale that was driving deprecation of
scope storage class is becoming obsolete with DIP1000 implemented but
not before.
signature.asc
Description: OpenPGP digital signature
Re: DIP1000: Scoped Pointers
On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote:
On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
Same as far as I understand, because "from a lifetime analysis
viewpoint, a struct is considered a juxtaposition of its direct
members"
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#aggregates). You need to add one more level of indirection for things to start going complicated.
Ah no, sorry, I have missed that you allocate struct on heap.
Yes, this is simplified problem case indeed. Intention is that
such struct can be made @safe by making all pointer fields
private and adding scope semantics in getter methods but it is
hard to reason about details at this point.
Re: DIP1000: Scoped Pointers
On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
Same as far as I understand, because "from a lifetime analysis
viewpoint, a struct is considered a juxtaposition of its direct
members"
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#aggregates). You need to add one more level of indirection for things to start going complicated.
Re: DIP1000: Scoped Pointers
On 08/16/2016 07:26 PM, Patrick Schluter wrote:
> What happens in that case ?
>
> void test() {
> scope rnd = new Rnd; // reference semantic and stack allocated
> Rnd rnd2;
> rnd2 = rnd;
> some_sneaky_function_that_saves_global_state(rnd);
> }
>
> or is that not even possible ? (sorry I'm still a noob in D).
If `Rnd` is supposed to be a class, it won't compile because it would
mean escaping scope reference to non-scope variable (with DIP1000). If
it is a struct, it won't compile because you are trying to assign `Rnd*`
(pointer) to `Rnd` (value) :)
signature.asc
Description: OpenPGP digital signature
Re: DIP1000: Scoped Pointers
On 08/15/2016 04:54 PM, Rory McGuire via Digitalmars-d-announce wrote:
> okay nice, so that code would not compile but code such as:
> void test() {
> scope rnd = new Rnd; // reference semantic and stack allocated
> auto rnd2 = rnd;
> some_sneaky_function_that_saves_global_state(rnd);
> }
> would still not be checked. And would crash inexplicably at the point
> the global was accessed?
some_sneaky_function_that_saves_global_state would have to be declared
as `some_sneaky_function_that_saves_global_state(scope Rnd rnd)` to be
allowed to use rnd as argument which prevents escaping to globals.
What would still be the problem is if `Rnd` contains reference to
another class internally (which gets manually destroyed when Rnd is
destroyed) and `some_sneaky_function_that_saves_global_state` saves it
instead - because by current design `scope` is a storage class and not
transitive.
signature.asc
Description: OpenPGP digital signature
Re: DIP1000: Scoped Pointers
On 08/15/2016 03:41 PM, Rory McGuire via Digitalmars-d-announce wrote: > scope rnd = new Rnd; // reference semantic and stack allocated > auto rnd2 = rnd; > > rnd.i = 2; > assert(rnd2.i == 2); > return rnd2; Point is that that would become illegal if DIP1000 is implemented thus giving scope class concept more justification. It would still have @safe holes though because proposed `scope` does not work through many indirection levels - but better than existing situation when nothing is checked. signature.asc Description: OpenPGP digital signature
Re: DIP1000: Scoped Pointers
On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote: When was it deprecated? I use it a lot and DMD 2.071.1 gives no warning. It was planned for removal because it was very un-@safe (no escaping checks whatsoever) and as such was not better than library implementation. Quite likely with DIP1000 implemented there will be no point in deprecating it anymore.
DIP1000: Scoped Pointers
The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback. Essentially, it is an attempt to solve reference lifetime problem by extending implementation of `scope` keyword. Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md Few notes: - Please submit pull requests to adjust the markdown document if you want to propose any improvements (mentioning @WalterBright and @andralex for confirmation). - The proposal refers to a number of other documents and it is recommended to become familiar at least briefly with all of them. - At this point the question I'd personally suggest to be evaluated is "does this proposal enable enough useful designs?". A good check would be to try taking some of your projects and see if having DIP1000 approved and implemented could improve them.
Re: Dreams come true: Compiling and running linux apps on windows :)
On Sunday, 7 August 2016 at 03:06:27 UTC, Martin Nowak wrote: On Saturday, 6 August 2016 at 17:34:14 UTC, Andre Pany wrote: The build script is working fine: curl -fsS https://dlang.org/install.sh | bash -s dmd Good news, I'm really not that keen to write a powershell script. What OS does it detect and download? AFAIK embedded linux support is based on Ubuntu
Re: Codebuilder with line info insertion
How much of compile-time overhead does it add compared to naive string concatenation?
Re: Announcing new DIP handling process
I have added new "tips" section to the process readme (https://github.com/dlang/DIPs#advices-for-writing-great-dips) to make potential DIP authors less excited and more prepared to real work awaiting ahead :)
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote: Hi everyone (= I've just added a new proposal to add a new attribute to ensure TCO is applied. The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it. The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6) -- Dietrich In the future I'd recommend to delay announcing DIP until it get to the point of being merged into the queue (I'd do it myself at that point). Right now there are quite some boring technical details to be fleshed out before it becomes a complete proposal - asking for community feedback is likely to be time-inefficient. And sorry for some of the inadequate responses you got here. D language authors don't want to enforce any code of conduct or moderation in the newsgroup which means certain personas have to be simply ignored. In the end only thing that should matter is a good technical document to be merged into the queue.
Re: Announcing new DIP handling process
On 07/09/2016 09:11 PM, ZombineDev wrote: > Can the new DIP process be used to evaluate library proposals? That way > a high level design could be fleshed out and approved before the > contributor goes too far with implementing a design which would be > rejected. It is quite hard. To reasonably evaluate library proposal one has to have at least proof of concept implementation showing intended API. It isn't easy to fit into abstract DIP format. I can't advise much on this part because I have been trying to stay away from Phobos affairs for a long time and don't know existing status quo about it.
Announcing new DIP handling process
After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here: https://github.com/dlang/DIPs ## Rationale There are two main goals for going this way: 1) Ensure communication between language authors and DIP authors, establish better sense of actually contributing as opposed to simply throwing ideas into the black box. 2) Improve overall quality of DIP documents to the point where language authors can reasonably review them without spending too much time on trivialities. Additional benefit I am hoping for is to have a centralized place to subscribe to learn about all coming major changes coming to language for those who can't keep up with NG regularly. ## Old DIPs Right now https://github.com/dlang/DIPs repository contains archive folder with already implemented proposals imported from wiki (please tell me if there are any other already implemented DIPs that were not marked as such in wiki). All authors of existing DIPs who want to keep pursuing the idea will have to re-submit them as a pull requests towards new repo. This is required so that we can filter abandoned proposals and focus on documents that have active authors backing them. ## DIP manager I will act as a DIP manager for the time being. Please note that role of DIP manager does not imply any decision power regarding DIP approval, it remains an exclusive domain of language authors.
Re: First dmd nightly shipping with dub
On Friday, 8 July 2016 at 09:13:08 UTC, Martin Nowak wrote: What would be the use-case for those? Using newer dub versions with an older compiler? Or simply using dub with ldc/gdb without also installing dmd.
Re: Button: A fast, correct, and elegantly simple build system.
On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote: This actually sounds nice. Main problem that comes to my mind is that there is no cross-platform shell script. Even if it is list of plain unconditional commands there are always differences like normalized path form. Of course, one can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution. I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either. This should actually be pretty easy to implement. Will plain sh script script also work for MacOS / BSD flavors? Committing just two scripts is fine but I wonder how it scales.
Re: Button: A fast, correct, and elegantly simple build system.
On Saturday, 18 June 2016 at 08:05:18 UTC, Jason White wrote: I realize you might be playing devil's advocate a bit and I appreciate it. Yeah, I personally quite like how Button looks and would totally consider it, probably with some tweaks of own taste. But not for most public projects for a reasons mentioned. Let me propose another idea where maybe we can remove the extra dependency for new codebase collaborators but still have access to a full-blown build system: Add a sub-command to Button that produces a shell script to run the build. For example, `button shell -o build.sh`. Then just run `./build.sh` to build everything. I vaguely recall either Tup or Ninja having something like this. This actually sounds nice. Main problem that comes to my mind is that there is no cross-platform shell script. Even if it is list of plain unconditional commands there are always differences like normalized path form. Of course, one can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution.
Re: Button: A fast, correct, and elegantly simple build system.
On 06/17/2016 06:20 PM, H. S. Teoh via Digitalmars-d-announce wrote: >> If you happen to be unlucky enough to work on a project so large you >> need to watch the file system, then use the tup backend I guess. > [...] > > Yes, I'm pretty sure that describes a lot of software projects out there > today. The scale of software these days is growing exponentially, and > there's no sign of it slowing down. Or maybe that's just an artifact of > the field I work in? :-P Server-side domain is definitely getting smaller beause micro-service hype keeps growing (and that is one of hypes I do actually support btw).
Re: Button: A fast, correct, and elegantly simple build system.
However, I question the utility of even doing this in the first place. You miss out on the convenience of using the existing command line interface. And for what? Just so everything can be in D? Writing the same thing in Lua would be much prettier. I don't understand this dependency-phobia. It comes from knowing that for most small to average size D projects you don't need a build _tool_ at all. If full clean build takes 2 seconds, installing extra tool to achieve the same thing one line shell script does is highly annoying. Your reasoning about makefiles seems to be flavored by C++ realities. But my typical D makefile would look like something this: build: dmd -ofbinary `find ./src` test: dmd -unittest -main `find ./src` deploy: build test scp ./binary server: That means that I usually care neither about correctness nor about speed, only about good cross-platform way to define pipelines. And for that fetching dedicated tool is simply too discouraging. In my opinion that is why it is so hard to take over make place for any new tool - they all put too much attention into complicated projects but to get self-sustained network effect one has to prioritize small and simple projects. And ease of availability is most important there.
Re: LDC 1.0.0 has been released!
Was there anything changed regarding -od / -op / -oq behaviour? I am getting DCD build errors with new LDC because object files are emitted to a different place it expects.
Re: LDC 1.0.0 has been released!
NB: update of Arch package is delayed because of https://github.com/ldc-developers/ldc/issues/1544
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 1 June 2016 at 04:34:23 UTC, Jason White wrote: Why is having dependencies so damaging for build systems? Does it really matter with a package manager like Dub? If there is another thread that answers these questions, please point me to it. Rephrasing one famous advice, "every added tooling dependency in an open-source project reduces amount of potential contributors by half" :) Basically, one can expect that anyone working with D will have dmd/phobos and, hopefully, dub. No matter how cool Button is, if it actually needs to be installed in contributor system to build a project, it is very unlikely to be widely used. That issue can be reduced by making Button itself trivially built from plain dmd/phobos/dub install and configuring the project to bootstrap it if not already present - but that only works if you don't also need to install bunch of additional tools like sqlite or make. From that perspective, the best build system you could possibly have would look like this: ``` #!/usr/bin/rdmd import std.build; // define your build script as D code ```
Re: Button: A fast, correct, and elegantly simple build system.
Can it be built from just plain dmd/phobos install available? One of major concernc behind discussion that resulted in Atila reggae effort is that propagating additional third-party dependencies is very damaging for build systems. Right now Button seems to fail rather hard on this front (i.e. Lua for build description + uncertain amount of build dependencies for Button itself).
Re: Release DUB 0.9.25, new logo and updated website design
On Monday, 23 May 2016 at 15:13:56 UTC, Russel Winder wrote: My need is two write a Python program that queries the running Dub repository. So I am guessing this is an HTTP-based protocol. I guess I will have to read the Dub code and deduce/infer/guess the necessary protocol. Not a problem, but it would have been easier for me not to have to do this but to have the API. Is there a repository with the beginnings of something that I might contribute to? Here is the declaration of REST API : https://github.com/dlang/dub-registry/blob/master/source/dubregistry/api.d#L21-L39 For example: http://code.dlang.org/api/packages/dub/info
Re: To all DConf speakers: please upload slides!
On Wednesday, 11 May 2016 at 13:00:39 UTC, Vladimir Panteleev wrote: On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote: To do the editing of HD videos we need presentation slides which are currently scattered over different places. It would help a lot to have them all in github.com/dlang/dlang.org repo - please submit pull requests asap! I think you mean the https://github.com/dlang/dconf.org repo :) I have a related pull request: https://github.com/dlang/dconf.org/pull/134 Correct and thanks! :)
Re: Looking for D developers, Saint-Petersburg
On Wednesday, 11 May 2016 at 09:40:43 UTC, Suliman wrote: On Wednesday, 11 May 2016 at 09:23:13 UTC, Dicebot wrote: FYI: хотя сама вакансия меня не интересует, могу помочь отдельными консультациями, если возникнет такая необходимость. Санкт-Петербург довольно близок от Риги. А в Риге вакансии связанные с Ди есть?) Насколько мне известно, нет. Знаю несколько маленьких компаний, которые экспериментируют с D, но не более того. Кстати, ты сам оттуда или переехал? Просто в последнее время слышу, что в прибалтику куча ИТшников переезжает. Я здесь родился.
Re: Looking for D developers, Saint-Petersburg
FYI: хотя сама вакансия меня не интересует, могу помочь отдельными консультациями, если возникнет такая необходимость. Санкт-Петербург довольно близок от Риги.
To all DConf speakers: please upload slides!
To do the editing of HD videos we need presentation slides which are currently scattered over different places. It would help a lot to have them all in github.com/dlang/dlang.org repo - please submit pull requests asap!
Re: Live streaming of DConf 2016: confirmed
On Wednesday, 4 May 2016 at 08:33:47 UTC, Joakim wrote: There appears to be a problem with the sound on Ustream with Android, at least for me: there is none. I've tried it on a Sony phone and a Samsung tablet, both with the HTML5 player in the browser and the Android app. All other streams work, which suggests it's a problem with the Dconf stream. My guess is that the Dconf stream is using an audio codec that Ustream doesn't support on Android, and it's silently failing, in more ways than one. If anyone else can reproduce this and maybe try to fix it by changing the audio codec, if possible, that'd be great. Have reported it to A/V team, will see if they can fix it timely.
Re: Proposed: start DConf days one hour later
On 04/28/2016 12:31 PM, Guillaume Chatelet wrote: > But hey they'll be > recorded right? Yep.
Re: Live streaming of DConf 2016: confirmed
On Tuesday, 26 April 2016 at 14:01:56 UTC, Dmitry wrote: On Thursday, 21 April 2016 at 17:24:43 UTC, Dicebot wrote: Have just got a confirmation that there will both live stream and high quality recording for later publishing during DConf 2016 @ Berlin - not being able to attend is not a reason to not participate! ;) Any chance for subtitles? For live stream - don't think so. For high quality recordings publishes later shouldn't be a problem.
Re: XDG-APP and D
On 04/22/2016 02:57 PM, John Colvin wrote: > On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote: >> For those not familiar, xdg-app is a Linux virtualization system >> targeted at desktop apps, it's been under pretty heavy development and >> is available for use in Gnome 3.20. >> >> Mathias Clausen recently wrote a blog entry about creating his first >> xdg-app and the application he chose to play with was Terminix, a >> terminal emulator, which is written in D. He had some D specific >> challenges to deal with which may be interesting to others looking to >> support xdg-app. >> >> You can read his blog entry here: >> >> https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app. > > Can someone explain to me how xdg-app provides a significantly different > experience to static linking (in a language like C or D)? I guess > there's the old "what about libc?". https://wiki.gnome.org/Projects/SandboxedApps explains it pretty well. Think of it as immutable filesystem snapshot that gets used for sandboxed app instead of real host filesystem. Not only all dependency code is included but all file resources too,: "A runtime provides a well-defined environment that an app can run in. Examples would be "GNOME 3.14" or "KDE 5.6". A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr." (c) that link It also includes facilities for limiting sandboxes app access to host: "The xdg-app run command sets up an isolated environment before exec()ing the application. Among other things, it - mounts the files/ directory of the application under /app (readonly) - mounts the files/ directory of the runtime under /usr (readonly) - mounts the data/ directory of the application under /var (writable) - if access to the host filesystem is required, it gets mounted at / (writable) - if access to the home directory is required, it gets mounted at its usual place (writable) - if access to neither the home directory or the host filesystem is required, /var/home gets mounted in its place (writable) - if the runtime has extension points, and matching runtimes are installed, mount them (readonly)" So in the end each app will bundle all its dependency and just work no matter what the host is. Which is cool. But it will also bundle all its dependencies and you'd better accept size of your total system installation (and its RAM consumption).
Re: XDG-APP and D
On 04/21/2016 11:30 PM, Karabuta wrote: > This whole sandbox apps seem interesting. Canonical also talking about > snaps :) Meh, I can see why this concept is tempting for desktop systems but it makes me feel that 5 years from now I'll have to build my own Linux-From-Scratch distro to preserve kind of user experience I initially loved Linux for (minimal overhead, running same system on both your tiny media server and power desktop). "A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr." :(
Live streaming of DConf 2016: confirmed
Have just got a confirmation that there will both live stream and high quality recording for later publishing during DConf 2016 @ Berlin - not being able to attend is not a reason to not participate! ;) I will also forward any questions asked online to speakers (if time allows). To make sure your question gets noticed please submit it (when the time comes) either via Twitter using #askdconf hash tag or via official D IRC channel (#d @ irc.freenode.net), preferrably mentioning the same hash tag. Only bit that is still decided upon is platform choice for primary stream source - will update this topic when it gets settled. See you soon in Berlin!
Re: Command line utilities for tab-separated value files
On 04/13/2016 09:48 PM, Jon D wrote: > Right. So, partly what I'm wondering is if during the normal dub > fetch/run cycle there might be an opportunity to print a message the > user with some info to help them add the tools to their path. I haven't > used dub much, so I'll have to look into it more. But there should be > some way to make it reasonably easy and clear. It'll probably be a few > days before I can get to this, but I would like to get them in the > package registry. This is wrong direction. Users of those tools should not even ever need to have dub installed or know about it existence - dub is strictly a developer tool. Instead, whoever distributes the utils should use dub to build them and use generated artifacts to prepare distribution package.
Re: Command line utilities for tab-separated value files
On Wednesday, 13 April 2016 at 17:21:58 UTC, Jon D wrote: You don't need to put anything on path to run utils from dub packages. `dub run` will take care of setting necessary envionment (without messing with the system): dub fetch package_with_apps dub run package_with_apps:app1 --flags args These are command line utilities, along the lines of unix 'cut', 'grep', etc, intended to be used as part of unix pipeline. It'd be less convenient to be invoking them via dub. They really should be on the path themselves. Sure, that would be beyond dub scope though. Making binary packages is independent of build system or source layout (and is highly platform-specific). The `dun run` feature is mostly helpful when you need to use one such tool as part of a build process for another dub package.
Re: Command line utilities for tab-separated value files
On Wednesday, 13 April 2016 at 16:34:16 UTC, Jon D wrote: Thanks Rory, Puming. I'll look into this and see how best to make it fit. I'm realizing also there's one additional capability it'd be nice to have in dub for tools like this, which in an option to install the executables somewhere that can be easily be put on the path. Still, even without this there'd be benefit to having them fetched via dub. You don't need to put anything on path to run utils from dub packages. `dub run` will take care of setting necessary envionment (without messing with the system): dub fetch package_with_apps dub run package_with_apps:app1 --flags args
Re: Release D 2.071.0
On Monday, 11 April 2016 at 19:20:50 UTC, Marco Leise wrote: Am Thu, 07 Apr 2016 10:13:35 + schrieb Dicebot : It is second time git tag for DMD release refers to commit with VERSION file content which doesn't match the tag. May indicate something is wrong in release procedure. Or maybe something is wrong with source based Linux distributions in this time and age. I don't know. But I'm glad that you fire proof the source bundles first, before I move my lazy ass to update DMD packages for Gentoo. I hope to start from a good, clean 2.071.0/2.071.1 tar ball. :D :) I must admit I took the easy path and simply added `echo $pkgver > ../VERSION` to package build script instead of making upstream PR.
Re: Release D 2.071.0
On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote: Glad to announce D 2.071.0. http://dlang.org/download.html This release fixes many long-standing issues with imports and the module system. See the changelog for more details. http://dlang.org/changelog/2.071.0.html -Martin It is second time git tag for DMD release refers to commit with VERSION file content which doesn't match the tag. May indicate something is wrong in release procedure.
Re: Blog article on new import changes
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Worth mentioning that -transition=checkimports may slow down compilation notably which is why it isn't the default.
Re: DConf 2016 announces programme, general registration opened thrugh April 22
On 03/29/2016 04:50 AM, Adam D. Ruppe wrote: > I just realized today that a live stream is not going to be enjoyable > for us who are still in the US. > > Any chance that we can have a *scheduled* delay rebroadcast right when > it ends? So basically starting at like 11am Eastern time, 8am Pacific. > > Heck, we might even play it a third time for people on the other side of > the world too, but I'm asking for myself so jut the ne is good. > > > I want this coordinated and announced because then we can all be on > together and have "live" chat without being up in the middle of the > night to be live with the folks in Germany. I am not sure this has much value. The main benefit of live stream is that everyone can ask questions online and those will be forwarded to speakers. Isn't it better to simply wait for recorded high quality videos otherwise? P.S. devs from Europe did indeed have to stay awake through the night to watch previous dconfs ;)
Re: unit-threaded v0.6.3 - now even easier to use / opt-in
On 02/29/2016 02:00 PM, Sebastiaan Koppe wrote: > On Monday, 29 February 2016 at 09:37:51 UTC, Atila Neves wrote: >> http://code.dlang.org/packages/unit-threaded >> >> Enjoy! >> >> Atila > > Really nice. > > Wow, didn't know dub could build and run a dependency. Note: only if it has a configuration with an `application` target defined. It is effectively a way to make tools from dub registry usable from other dub projects without messing with system-wide state.
Re: Qt's MOC getting replicated in D for Calypso
On 02/22/2016 12:20 PM, Dicebot wrote: > The very reason why Calypso doesn't work with C++ so well is also the > reason why you won't be able to generate bindings easily - it calls C++ > code directly without creating intermediate D interface in any form. Typo: "very reason why Calypso DOES work with C++ so well"
Re: Qt's MOC getting replicated in D for Calypso
On 02/22/2016 01:30 AM, bachmeier wrote: > On Sunday, 21 February 2016 at 22:23:10 UTC, Kagamin wrote: >> On Sunday, 21 February 2016 at 17:21:51 UTC, Brad Roberts wrote: >>> Is there anything preventing Calypso from turning into a code and >>> interface generator? Making it an application that is part of the >>> build rather than a plug in to ldc would make it available to both >>> dmd and gdc users, no? >> >> That's DStep: https://github.com/jacob-carlborg/dstep > > I don't think that works for C++, and it's not complete. The very reason why Calypso doesn't work with C++ so well is also the reason why you won't be able to generate bindings easily - it calls C++ code directly without creating intermediate D interface in any form.
