Re: DIP1000: Scoped Pointers
This bit seems odd:
T func(T* t) {
return t; // ok
}
Is there an implicit conversion from T* to T?
On Wed, Aug 10, 2016 at 10:05 PM, rikki cattermole via
Digitalmars-d-announce wrote:
> On 11/08/2016 8:35 AM, Dicebot wrote:
>
>> 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.
>>
>
> Question:
> I see RefCountedSlice example, does this mean if I alias this say like:
>
> struct FooBar;
>
> struct Foo {
> FooBar* v;
>
> scope FooBar* get() { return v; }
> alias this get;
> }
>
> That it will operate correctly in the below case?
>
> func(myFoo);
> void func(scope FooBar*)
>
> If this does work, this is a major addition that I've been waiting for,
> for my managed memory concept! https://github.com/rikkimax/al
> phaPhobos/blob/master/source/std/experimental/memory/managed.d
> After this I'll only need proper ref counting in the language ;)
>
Re: DIP1000: Scoped Pointers
On 11/08/2016 8:35 AM, Dicebot wrote:
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.
Question:
I see RefCountedSlice example, does this mean if I alias this say like:
struct FooBar;
struct Foo {
FooBar* v;
scope FooBar* get() { return v; }
alias this get;
}
That it will operate correctly in the below case?
func(myFoo);
void func(scope FooBar*)
If this does work, this is a major addition that I've been waiting for,
for my managed memory concept!
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/memory/managed.d
After this I'll only need proper ref counting in the language ;)
Re: DIP1000: Scoped Pointers
On 8/10/2016 4:56 PM, Nicholas Wilson wrote: How will the infinite lifetime of ArrayLiteral and ArrayLiteral[constant] interact with LDC's GC to stack promotion pass? I don't know about how that works in LDC, but general such a promotion can only be done if the compiler can prove there are no escaping pointers to the data.
Re: DIP1000: Scoped Pointers
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote: 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. [...] How will the infinite lifetime of ArrayLiteral and ArrayLiteral[constant] interact with LDC's GC to stack promotion pass?
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: Autotesting dub packages with dmd nightly
On Wednesday, 10 August 2016 at 18:35:03 UTC, Sebastiaan Koppe wrote: Yes, but from past experience we know that people don't look at results, if you don't make it part of PR acceptance. So true. Then I will do PR's first. Thinking about it, you could also opt for integrating it with the dmd PR flow - in a similar manner to the autotester or coverage bot: Select a subset (depending on the runtime) of packages and run your dub autotester for every commit and thus save for every commit a list of passing packages. Now for a new PR, search for the master commit hash in your DB of runs and run the dub autotester with those packages. The workflow of the AutoTester [1] is a bit more complicated, because it is throwing away results as soon as the master HEAD changes (to avoid any inconsistencies) and there are often rebases and additional pushes happening, but you could just opt for a simple 80% solution. I imagine shouting at Walter with a Github comment "Hey this PR will break 10% of all packages [of the subset]" could be quite helpful ;-) [1] https://auto-tester.puremagic.com
Re: Autotesting dub packages with dmd nightly
On Wednesday, 10 August 2016 at 10:32:24 UTC, Martin Nowak wrote: We want better ranking of dub packages (mostly by download, but for sure also showing CI results [¹]). I was also thinking about integrating results from CI builds that packages do themselves. But there is some 'impedance mismatch': those CI build are done on the master branch, not on the latest release that is on code.dlang.org. Is it already usable? Short answer: No. I am currently test running it on all packages against the 10 latest dmd releases (I have done 6k packages on and off since 2 days ago). But I am running into vibe.d issues/missing features. Things like not being able to use gzip with requestHttp (let alone with a RestInterfaceClient), invalid internal state with the http client pool on interrupting requests, and some other things. Also, I am writing a PR for vibe.d to send http request to unix sockets. How to deploy then? For the worker it's just a docker container. But until the unix sockets PR is done you do have to setup the docker daemon to listen on the docker0 interface. I need to test https://github.com/dlang/druntime/pull/1602 and otherwise have to resetup my project tester for that. I am using digger to build dmd, so adding in the pull request is trivial. I do need to adjust internals to properly handle it though. But alas, family is coming over so don't expect anything anytime soon. Yes, but from past experience we know that people don't look at results, if you don't make it part of PR acceptance. So true. Then I will do PR's first.
Re: August Boston D users meetup
On 08/10/2016 01:12 PM, Steven Schveighoffer wrote: On 8/1/16 10:11 AM, Steven Schveighoffer wrote: I posted this a while ago, forgot to announce. Please join us if you are in the area! Already 5 going. http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/232865668/ Another ping. Happening tomorrow! -Steve I'll be there! -- Andrei
Re: Beta D 2.071.2-b2
On Tuesday, 9 August 2016 at 15:37:27 UTC, Martin Nowak wrote: Please report any bugs at https://issues.dlang.org I'd appreciate it if someone could have a look at this regression: https://issues.dlang.org/show_bug.cgi?id=16369
Re: D on exercism.io
On 08/09/2016 09:43 AM, celavek wrote: > If anyone has ideas for new exercises please contribute or if the time > is an issue send me > a message with a clear problem statement and a set of unit tests. > > I would like to say that for me the sit worked quite well and it helped > me get started > with the language. > > Thanks Nice one, maybe you can find more ideas at http://rosettacode.org/wiki/Category:D.
Re: Autotesting dub packages with dmd nightly
On 08/08/2016 09:54 AM, Sebastiaan Koppe wrote: > On Sunday, 7 August 2016 at 23:08:34 UTC, Martin Nowak wrote: >> I actually don't think this makes sense. You're not in the position to >> maintain 1K+ packages, it's the library owners that need to test their >> code. > Thanks for taking the time to respond. You're welcome. This is an important topic for us. > I agree with you. Library owners should test their code themselves. But > they don't. 24% of the packages don't build. We want better ranking of dub packages (mostly by download, but for sure also showing CI results [¹]). It's rather trivial to filter out low-quality packages b/c they're hardly used. [¹]: https://trello.com/c/CaYJwtBV/60-integrate-ci-results-with-dub-registry >> Just this short list I'm using for the project tester is hardly >> maintainable. > I don't need to maintain anything besides linker errors. It is quite > simple, I just run `dub test` and see what happens. If that doesn't work > I consider it a failed build. > >> https://github.com/MartinNowak/project_tester (uses Jenkins, no need >> to write yet another CI). > I would argue mine is simpler to deploy and have nodes join. Is it already usable? How to deploy then? I need to test https://github.com/dlang/druntime/pull/1602 and otherwise have to resetup my project tester for that. Adding more servers to Jenkins is trivial as well. >> Once a day is not enough b/c will feel responsible for breakages, we >> really need feedback before merging. > It is just a matter of resources. I choose nightly since it seemed > doable using just my own resources. Yes, but from past experience we know that people don't look at results, if you don't make it part of PR acceptance. >> - Show test results of various CIs on code.dlang.org. Testing a dub >> package on Travis-CI is already a no-brainer. For example the >> following .travis.yml would test a package against all dmd release >> channels. >> >> ```yaml >> language: d >> d: [dmd, dmd-beta, dmd-nightly] >> ``` > Yes, that is quite nice. But that only gets triggered when the repo is > updated. Travis now allows cron scheduling, you still have to ask their support to unlock that. -Martin
