Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code

[RazvanN via Digitalmars-d-announce]

On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote:
Hello everyone, My name is Dennis and I’m from Nigeria and I 
want to contribute to the D language, perhaps engage in the 
upcoming Symmetry Autumn of code, and contribute immensely to 
the D language and beyond.
I’m open to anyone directing me on things to work on. I'd 
really appreciate that.


Hi Dennis!

We have a bunch of projects that you could work on, however, 
choosing the right project depends of what you are interested in 
and your experience with the concepts involved. Generally, we 
have multiple fronts that work could be done on: the compiler, 
the runtime library, the standard library, ecosystem tools etc. I 
suggest you pick one of the categories, get the code, try to fix 
the issues (you can find our list of issues here: 
https://issues.dlang.org/ - searching for the keywork "bootcamp" 
will list issues that are considered entry level, but note that 
some of those might be more complicated then you would expect at 
a first glance) and then we can have a chat on projects you can 
work on. How does that sound?


RazvanN

Re: std.string.assumeUTF() silently casting mutable to immutable?

[RazvanN via Digitalmars-d-learn]

On Wednesday, 14 February 2024 at 11:56:29 UTC, Forest wrote:

On Wednesday, 14 February 2024 at 10:57:42 UTC, RazvanN wrote:


This has already been fixed, you just need to use 
-preview=fixImmutableConv. This was put behind a preview flag 
as it introduces a breaking change.


I just tried that flag on run.dlang.org, and although it fixes 
the case I posted earlier, it doesn't fix this one:


```d
string test(const(ubyte)[] arr)
{
import std.string;
return arr.assumeUTF;
}
```

Shouldn't this be rejected as well?


Indeed, that should be rejected as well, otherwise you can modify 
immutable table. This code currently happily compiles:


```d
string test(const(ubyte)[] arr)
{
import std.string;
return arr.assumeUTF;
}

void main()
{
import std.stdio;
ubyte[] arr = ['a', 'b', 'c'];
auto t = test(arr);
writeln(t);
arr[0] = 'x';
writeln(t);
}
```

And prints:

```
abc
xbc
```

However, this seems to be a different issue.

Re: DLF September 2023 Monthly Meeting Summary

[RazvanN via Digitalmars-d-announce]

On Monday, 13 November 2023 at 16:52:06 UTC, Paul Backus wrote:

On Monday, 13 November 2023 at 16:23:05 UTC, Tim wrote:
The visitor can already be `extern(D)`. Only member functions 
overriding those in the base class need to be `extern(C++)`. 
Other member functions can then use paratemers, which would be 
incompatible with `extern(C++)`.


Wow, it really was that simple all along. Thanks for the tip!


That's not a complete solution. If you template the visitor and 
have some member functions that override the extern(C++) base 
class methods, then you will still end up with errors if you use 
any types that use non-mapable C++ types because of the mangling. 
For example:


```d
extern(C++) class DMDVisitor
{
void visit(Expression e) {}
}

class MyVisitor(T) : DMDVisitor
{
T field;
extern(C++) override void visit(Expression e) {}   // 
troubled line

}
```

Instantiating MyVisitor with a string type will issue an error at 
the troubled line because the mangler needs to take into account 
the template instance. Since C++ has no dynamic array 
correspondent you essentially cannot call MyVisitor.visit from 
C++ and therefore the compiler issues an error.


However, if you don't use templated visitors you are fine, you 
can just mark your introducing functions/fields as extern(D) and 
even if the class is extern(C++) it will work.

Re: DLF September 2023 Monthly Meeting Summary

[RazvanN via Digitalmars-d-announce]

On Sunday, 12 November 2023 at 21:55:31 UTC, Paul Backus wrote:

On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote:

https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581


There was a side discussion about how the `extern(C++)` 
interface affects dmd-as-a-library.


Personally, my number-one complaint with dmd-as-a-library is 
that I am forced to use `extern(C++)` when creating my own 
`Visitor` classes.


In [`dmdtags`][1], this requirement has made it necessary for 
me to implement my own C++-compatible [`Span`][2] and 
[`Appender`][3] types, just to avoid the C++ mangling errors 
caused by D's built-in `T[]` slices.


I have no use for overriding AST nodes, but the ability to use 
`extern(D)` visitors with dmd-as-a-library would be a welcome 
improvement.


[1]: https://code.dlang.org/packages/dmdtags
[2]: 
https://github.com/pbackus/dmdtags/blob/v1.1.1/src/dmdtags/span.d
[3]: 
https://github.com/pbackus/dmdtags/blob/v1.1.1/src/dmdtags/appender.d


I have already brought that up to one of our work group meetings 
regarding dmd as a library as I have stumbled upon this also. We 
have a solution for this, I'm going to try to implement it this 
week.


RazvanN

Re: Dlings first release

[RazvanN via Digitalmars-d-announce]

On Monday, 23 January 2023 at 10:21:04 UTC, João Lourenço wrote:



[1] https://github.com/rust-lang/rustlings
[2] https://github.com/iK4tsu/dlings
[3] https://github.com/crazymonkyyy/dingbats


Maybe you can find some inspiration from our D summer school 
exercices[1][2]. Many of them are inspired by Ali's book.


[1] https://github.com/Dlang-UPB/D-Summer-School
[2] https://dlang-upb.github.io/D-Summer-School/

Re: SAOC 2022 Result

[RazvanN via Digitalmars-d-announce]

On Sunday, 5 February 2023 at 16:15:38 UTC, Mike Parker wrote:
We had three participants in SAOC 2022. You may have noticed 
their periodic updates in the General forum. Keeping the 
community informed through those updates is one of the 
requirements of the event each year. They also have to submit 
reports on their progress at the end of each milestone, and 
their mentors send along evaluations at the same time.


[...]


Congratulations to all participants and thank you Symmetry!

Re: Druntime merged into dmd repo

[RazvanN via Digitalmars-d-announce]

On Friday, 15 July 2022 at 05:46:53 UTC, StarCanopy wrote:

On Tuesday, 12 July 2022 at 07:12:25 UTC, RazvanN wrote:
This is not something a user is going to be affected by. But 
it will make it much easier for the compiler/druntime devs to 
do work. DMD and druntime are very strictly coupled and 
sometimes modifying one requires changes in the other. That 
lead to situations where it was practically impossible to 
integrate changes without temporarily breaking the CI. 
Moreover, it was a pain to bisect bugs that were affected by 
both druntime/dmd changes.


Thank you for the elucidation!
I might be wrong, but some time ago, there was talk of 
deprecating druntime or something to that effect, and I 
wondering whether this was step in that direction, but it 
appears that is not the case.


No, there is no talk about deprecating druntime. However, work is 
being done
to templatize druntime as much as possible so that it becomes a 
pay-as-you-go

library.

Re: Druntime merged into dmd repo

[RazvanN via Digitalmars-d-announce]

On Tuesday, 12 July 2022 at 03:36:42 UTC, StarCanopy wrote:

On Saturday, 9 July 2022 at 22:24:45 UTC, max haughton wrote:

Say thank you to Iain, Mathias, Vladimir, and Martin.

This will make D better. More details to come.


I'm ignorant. Why is this significant?


This is not something a user is going to be affected by. But it 
will make it much easier for the compiler/druntime devs to do 
work. DMD and druntime are very strictly coupled and sometimes 
modifying one requires changes in the other. That lead to 
situations where it was practically impossible to integrate 
changes without temporarily breaking the CI. Moreover, it was a 
pain to bisect bugs that were affected by both druntime/dmd 
changes.

Re: Druntime merged into dmd repo

[RazvanN via Digitalmars-d-announce]

On Sunday, 10 July 2022 at 17:17:30 UTC, IGotD- wrote:

On Saturday, 9 July 2022 at 22:24:45 UTC, max haughton wrote:

Say thank you to Iain, Mathias, Vladimir, and Martin.

This will make D better. More details to come.


Does this mean that druntime for LDC and GDC were also moved 
into the same repo? Same branch?


No.

Winners of the April 1st - July 1st 2022 Bugzilla Cycle

[RazvanN via Digitalmars-d-announce]

Hello everyone,

It is my pleasure to announce that the winners of the 2nd 
bugzilla cycle of the year are:


1. BorisCarvajal - 370 points
2. MoonlightSentinel - 135 points
3. FeepingCreature   - 120 points

Congratulations!

The cycle standings are here: 
https://bot.dlang.io/contributor_stats_cycle
The overall standings hierarchy, which counts all the points that 
have been collected since the system was put in place, is here: 
https://bot.dlang.io/contributor_stats


A new bugzilla cycle has started on the 1st of July and will end 
on the 30th of September.


Cheers,
RazvanN

Re: A New Game Written in D

[RazvanN via Digitalmars-d-announce]

On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote:

Hello,

I've been building a game engine in D for the past 2 and a half 
years and have finally reached a point where it's usable in 
day-to-day game development. Earlier this year I decided to 
make a simple shooter game to serve as a tech demo for the 
engine's capabilities, and also just to get a general idea of 
how well it works when used in a real application. I did an 
initial release of the game yesterday on itch.io, you can find 
more information on the product page if you are interested: 
https://kenny-shields.itch.io/untitled-shooter-game


This isn't an open-source project, but I wanted to post this 
here for anyone who might be interested in seeing D used for 
cross-platform game development. Any questions/comments about 
the implementation and design of the game/engine are welcome.


On a side note, I'd like to give special thanks to Walter and 
all of you who who contribute to D to make it what it is today. 
D is a fantastic language and really can't see myself using 
anything else for development at this point. Also, shout-out to 
the LDC developers as well, really great compiler.


Congratulations! Would you consider presenting the game and your 
experience with D in an oral presentation at Dconf? I think this 
sort of material would interest a lot of people in the community. 
All you need to do is put up a small description of the project 
and send it to soc...@dlang.org. If it gets selected you could 
participate to dconf for free + all your expenses regarding the 
trip (flight + accommodation) will be paid by the Foundation. For 
more info check [1]. The deadline should have been 15 May but 
late submissions might be considered too.


Cheers,
RazvanN


[1] https://dconf.org/2022/index.html#schedule

Re: D Language Foundation April Quarterly Meeting and Server Meeting Summaries

[RazvanN via Digitalmars-d-announce]

On Wednesday, 4 May 2022 at 21:31:44 UTC, rikki cattermole wrote:
For me the bug that is potentially limiting me (design wise) 
is: https://issues.dlang.org/show_bug.cgi?id=21416


#dbugfix

Good stuff moving forward and that tool looks interesting to 
try out.


Potential fix: https://github.com/dlang/dmd/pull/14075

Winners of the 1st Jan - 31st March 2022 Bugzilla Cycle

[RazvanN via Digitalmars-d-announce]

Hello everyone,

I am happy to announce that this bugzilla rewarding cycle winners 
are:


1. MoonlightSentinel 830 points
2. ljmf00270 points
3. aG0aep6G  240 points

The prizes that the winners will be getting are 100$, 50$ and 25$ 
Amazon eGift cards. Congrats!


The official standings are here [1].

@aG0aep6G please contact me at razvan.n...@dlang.org so that we 
can discuss the details of how you will receive your gift card. 
@ljmf00 @MoonlightSentinel I have tried contacting you privately, 
but if my messages have not been received, please also contact me.


Cheers,
RazvanN

[1] https://bot.dlang.io/contributor_stats_cycle

Re: Is it possible to do this with a template?

[RazvanN via Digitalmars-d-learn]

On Friday, 17 December 2021 at 07:52:18 UTC, rempas wrote:
I want to use an expression and put it in place inside the `if` 
parentheses. The expression is: `is(typeof(val) == type)`. I 
want to use a template called "is_same" that will take the 
value and a type to place them to the respective places. I have 
tried the following but it doesn't seem to work:


```
mixin template is_same(val, type) {
  is(typeof(val) == type)
}

void main() {
  int val = 10;
  static if (is_same!(val, int)) {}
}
```

When trying to compile, I'm taking the following error message:

```
Error: declaration expected, not `is`
```

Is this a limitation of templates in D or is there a way to 
bypass this?


There is also a compiler trait [1] which can do that for you:

```d
void main()
{
int val = 10;
static if (__traits(isSame, typeof(val), int)) {}
}
```


[1] https://dlang.org/spec/traits.html#isSame

Re: template ctor overload Segmentation fault

[RazvanN via Digitalmars-d-learn]

On Sunday, 12 December 2021 at 11:57:43 UTC, vit wrote:

Hello, why does this code fail to compile?

```d
struct Foo(T){
this(Rhs, this This)(scope Rhs rhs){
}

this(ref scope typeof(this) rhs){
}
}


struct Bar{
Foo!int foo;
}

void main(){
}
```

error: Segmentation fault (core dumped)


PR: https://github.com/dlang/dmd/pull/13427

Re: template ctor overload Segmentation fault

[RazvanN via Digitalmars-d-learn]

On Tuesday, 14 December 2021 at 13:02:16 UTC, Tejas wrote:

On Tuesday, 14 December 2021 at 12:04:36 UTC, RazvanN wrote:

[...]


Then why did my modification work?

```d
struct Foo(T){
this(Rhs, this This)(scope Rhs rhs){
}

this(scope Foo!(T)* rhs){ //replaced typeof(this) with 
Foo!T and ref with pointer. Code still works if I retain 
typeof(this)

}
}


struct Bar{
Foo!int foo;
}

void main(){
import std.stdio:writeln;

Bar bar = Bar();
auto BAR = new Bar();
writeln(bar, "\t", BAR, "\t", *BAR);
}
```

Did my modifications ensure that this is not treated as a copy 
constructor?


Yes, the copy constructor needs to be explicitly defined by 
passing a ref parameter. Since you are expecting an explicit 
pointer, the compiler does not see it as a copy constructor and 
therefore does not try to generate one for Bar.

Re: template ctor overload Segmentation fault

[RazvanN via Digitalmars-d-learn]

On Sunday, 12 December 2021 at 11:57:43 UTC, vit wrote:

Hello, why does this code fail to compile?

```d
struct Foo(T){
this(Rhs, this This)(scope Rhs rhs){
}

this(ref scope typeof(this) rhs){
}
}


struct Bar{
Foo!int foo;
}

void main(){
}
```

error: Segmentation fault (core dumped)


The problem is that the compiler will try to generate an inout 
copy constructor for Bar that looks roughly like this:


```
this(ref scope inout(Bar) p) inout
{
this.foo = p;
}
```

The idea behind this lowering is to try and call the copy 
constructor for Foo object if possible. One issue here is that 
copy constructors have the same symbol name as constructors 
(__ctor), so `this.foo = p` gets lowered to `foo.__ctor(p)`.
Since both the instance and the parameter are inout, the copy 
constructor of Foo cannot be called, so the templated constructor 
is called. After generating the template instance of the 
constructor, you end up with `this(scope inout(Foo)) inout` ; 
that is basically an rvalue constructor. This is not valid code; 
if you write:


```
struct Foo(T){
//this(Rhs, this This)(scope Rhs rhs){}
this(scope inout(Foo!int) rhs) inout {}

this(ref scope typeof(this) rhs){
}
}
```

You will get an error stating that you cannot define both an 
rvalue constructor and a copy constructor. However, since the 
constructor is templated it is impossible for the compiler to 
issue this error before actually instantiating the constructor. I 
see 2 possible fixes for this: (1) either we rename the copy 
constructor symbol to __cpCtor so that it does not clash with the 
normal constructor overload set or (2) when a templated 
constructor is instantiated, we can check whether it is an rvalue 
constructor and issue an error if a copy constructor exists.


When I implemented the copy constructor I thought that it would 
better to have the copy constructor on a different overload set 
than the normal constructors, however, Walter insisted that they 
have the same name. So, I guess (2) is the way to go.


Cheers,
RazvanN

Re: Bugzilla Reward System

[RazvanN via Digitalmars-d-announce]

On Thursday, 16 September 2021 at 14:35:08 UTC, Paul Backus wrote:
On Thursday, 16 September 2021 at 11:56:21 UTC, Mike Parker 
wrote:

https://dlang.org/blog/2021/09/16/bugzilla-reward-system/


From the post:

The scoring is designed to reward contributors based on the 
importance of the issues they fix, rather than the total 
number fixed. As such, issues are awarded points based on 
severity:


In my experience, the only severity settings most people 
actually use when filing issues on Bugzilla are "enhancement", 
"normal", and "regression". And when people do use the other 
settings, there's no consistency to how they get applied. For 
example, the first two search results for priority "blocker", 
issues [22283][] and [22148][], have no indication of what (if 
anything) they block. Meanwhile, issues [14196][] and [13983][] 
are both enhancement requests but have their priority set to 
"major", and issue [22136][] is listed as "critical" even 
though it is actually a regression!


I don't blame anyone who files reports like these. The fact is, 
there is no official guidance anywhere about what distinguishes 
a "minor" issue from a "normal" one, or a "normal" issue from a 
"major" one, so people just guess. But treating the output of 
this guessing process as though it were meaningful data is 
probably a mistake.


[22283]: https://issues.dlang.org/show_bug.cgi?id=22283
[22148]: https://issues.dlang.org/show_bug.cgi?id=22148
[14196]: https://issues.dlang.org/show_bug.cgi?id=14196
[13983]: https://issues.dlang.org/show_bug.cgi?id=13983
[22136]: https://issues.dlang.org/show_bug.cgi?id=22136


Given that points are obtained depending on severity, my 
expectation is that reviewers will pay more attention to it when 
a PR is submitted. In addition, people that try to score as much 
points as possible will be interested in making sure that the 
competition does get the right amount of points. Therefore, I 
think that the rewarding system will improve the status quo with 
regards to labeling bugs.

Re: Bugzilla Reward System

[RazvanN via Digitalmars-d-announce]

On Friday, 17 September 2021 at 01:07:09 UTC, Ali Çehreli wrote:

On 9/16/21 4:56 AM, Mike Parker wrote:

> This was Razvan Nitu's baby from conception to implementation

Thank you, Razvan! Great job and a great article.



Thank you, Ali!

What I missed in the article is whether we are going to reward 
all contributors or whether certain people like Walter are 
excused? :)




Foundation people like Walter and myself are not going to be 
rewarded, however,
unaffiliated titans such as Iain, Vladimir and kinke have the 
opportunity of being rewarded. Of course, it is their decision if 
they do or don't want to participate in the race. Either way, the 
scoring system is going to track everyone's activity and then we 
can exclude foundation members and take into account potential 
prize yields.



Also, if a regression is best fixed by the person who caused it 
in the first place, regressions may become a good thing. ;)




If you are hinting at intentionally introduced regressions, I 
think that it is the burden of the reviewer to catch them at 
review time. If not, it really depends on who has time to fix it. 
I, personally, fixed tons of regressions and only a small part of 
those where introduced by me. I think that we can just assume 
good faith and acknowledge the fact that people make mistakes and 
it's fine to reward them if they fix them.


Cheers,
RazvanN


Ali

Re: D Summer School v3

[RazvanN via Digitalmars-d-announce]

On Friday, 27 August 2021 at 07:45:42 UTC, M.M. wrote:

On Thursday, 26 August 2021 at 14:33:25 UTC, Mike Parker wrote:

Very nice event and blog.



Thanks!

I wonder about the hackathon: did you, Razvan et al., 
pre-selected a list of bugzilla issues to work on?




We do have a keyword, "bootcamp", for simpler issues, but
some of those could be fairly complicated, therefore,
we internally selected a list of 10-20 issues that we
considered trivial.

About the intimidacy of contributing bugfixes: it could be 
worth trying to demonstrate during a lecture how fixing such an 
PR actually works, including the (technical) process of 
submitting a PR, with all the comments, naming conventions, etc.


That's an interesting proposal. It could potentially benefit both 
future
DSS students and first time contributors. Thanks for the 
suggestion.


Cheers,
RazvanN

Re: No rdmd.exe in /bin64 on Windows - is this an issue?

[RazvanN via Digitalmars-d-learn]

On Monday, 12 July 2021 at 23:57:37 UTC, Scotpip wrote:

Hi guys

Just installed the DMD 2.097.0 .exe download for Windows on my 
64 bit Win 10 workstation.


[...]


PR: https://github.com/dlang/installer/pull/484

Re: Cannot call find with haystack elements having a explicit copy constructors

[RazvanN via Digitalmars-d-learn]

On Thursday, 15 July 2021 at 11:08:25 UTC, Per Nordlöw wrote:

The adding of copy construtors to `Service` defined as

```d
@safe struct Service {
this(ref return scope typeof(this) rhs) {}
this(const ref return scope typeof(this) rhs) const {}
}

@safe struct Session {
void openAndGetService(in string key) scope {
import std.algorithm.searching : find;
auto hit = _pairs.find!((x) => x.key == key)();
}
private Pair[] _pairs;
private struct Pair {
string key;
Service service;
}
}
```



struct Pair will have an inout(inout) copy constructor defined 
the following way:


this(inout ref return scope typeof(this) rhs) inout
{
key = rhs.key;
service = rhs.service;
}

`service = rhs.service` will be rewritten to 
service.__cpctor(rhs.service), but since Service does not define 
an inout copy constructor it will fail to typecheck and the 
compiler will annotate it with @disable. Therefore, Pair will 
become uncopyable. This will result in isInputRange failing on 
Pair[] (more specifically, this constraints from isInputRange: 
is(typeof((return ref R r) => r.front)). If the copy constructor 
of Service is inout(inout), the generated copy constructor of 
Pair will be succesfully typechecked and everything will work.


For more context, please see this issue [1] and more 
specifically, this comment [2].


Cheers,
RazvanN

[1] https://issues.dlang.org/show_bug.cgi?id=20876
[2] https://issues.dlang.org/show_bug.cgi?id=20876#c4

Re: A Pull Request Manager's Perspective

[RazvanN via Digitalmars-d-announce]

On Tuesday, 18 May 2021 at 14:28:52 UTC, Dennis wrote:

On Tuesday, 18 May 2021 at 12:58:51 UTC, Mike Parker wrote:

https://dlang.org/blog/2021/05/18/a-pull-request-managers-perspective/



Ths emphasizes the fact that druntime needs more love.


That conclusion is given along with these numbers:

|| dmd | phobos | druntime |
||-||--|
|open bug reports| 3000| 900|   300|
|Pull requests / month   |  85 | 130|30|
|contributors last month |  10 |   5| 4|

To me, that looks like dmd needs more love, given the vast 
amount of bugs (3000) compared to druntime (300).


The opened druntime PRs do not necessarily fix any issues or add 
new features, but rather contain minor refactorings of small, 
unreported, bug fixes. So I would say that there is no 
relationship betweem the number of bugs of a component and the 
number of PRs that are opened.


The fundamental reason why dmd has more opened bugs is because it 
is the oldest codebase among the 3. Also, some bugs are reported 
as belonging to dmd when they're actually druntime bugs, because 
it is difficult to properly identify the component if you are not 
a contributor. I have changed the component part of many dmd bugs 
to druntime over time.

Re: [GSoC] Google Summer of Code 2021: Organization Applications Open

[RazvanN via Digitalmars-d-announce]

On Sunday, 31 January 2021 at 00:45:18 UTC, Ahmet Sait wrote:

Hi everyone!

It's that time of the year again. Google announced that 
mentoring organizations can now apply for summer of code in 
their blog:

https://opensource.googleblog.com/2021/01/google-summer-of-code-2021-is-open-for-applications.html
And in the mailing list:
https://groups.google.com/g/google-summer-of-code-discuss/c/KB8efMmLfhA

[...]


Hi! Thanks for the heads up, we are already working on this. I 
will come back with details about this.


Cheers,
RazvanN

Re: Say Hello to Our Two New Pull-Request/Issue Managers

[RazvanN via Digitalmars-d-announce]

On Wednesday, 13 January 2021 at 11:33:44 UTC, Mike Parker wrote:
I'm very, very happy that I can finally announce the news. Some 
of you may recall the job announcements I put out on the blog 
back in September [1]. Symmetry Investments offered to fund one 
full-time, or two part-time, Pull Request Manager positions, 
the goal being to improve the efficiency of our process 
(prevent pull requests from stagnating for ages, make sure the 
right people see the PRs in need of more than a simple review, 
persuade the right people to help with specific Bugzilla 
issues, etc).


[...]


On Wednesday, 13 January 2021 at 11:33:44 UTC, Mike Parker wrote:

Thanks Mike! And thanks to everyone for your support.

Re: D mentionned in the ARTIBA webzine for an article on Silq

[RazvanN via Digitalmars-d-announce]

On Wednesday, 2 September 2020 at 07:38:01 UTC, JN wrote:

On Wednesday, 2 September 2020 at 00:35:07 UTC, user1234 wrote:

[...]


One thing I always feel this forum is missing is a section for 
work in progress projects, even if they never end up anywhere. 
Right now people are shy about their projects, so the only way 
you learn about them is by finding mentions of them such as 
these, when they're released on DUB repository or when someone 
makes an announcement post on Announce. The problem with 
Announce is that people only use it for official releases - and 
that's good - but we're missing out on all the work in progress 
buzz.


[...]


This sounds like a great idea. +1

Re: DIP1028 - Rationale for accepting as is

[RazvanN via Digitalmars-d-announce]

On Wednesday, 27 May 2020 at 10:40:18 UTC, Walter Bright wrote:

On 5/27/2020 3:07 AM, Johannes Loher wrote:
This is a very specific situation. There are a lot of teams / 
developers
that do not work in this manner. I don't know the numbers so I 
will make
no statement about what is more common but my personal 
experience is a

different one.


I've seen larger companies operate this way. Smaller ones 
cannot afford to.



Also what is the difference between your QA department telling 
you to
correctly annotate C declarations and the compiler telling you 
that?

> If you expect people to ignore what the compiler is telling
them, why do
> you expect them to listen to the QA department?

The QA dept is motivated to not be taken in by greenwashing.

(Back in my days at Boeing, I worked in the design department. 
There was an entirely separate organization call the Stress 
Group. Their job was to sign off on every nitpicky detail. If 
they signed off on something that turned out to be wrong, it 
was bad for their careers. Your designs did not move forward 
without Stress signoff. If you tried to trick Stress, that was 
the end of your career at Boeing.)


So yeah, there's a huge difference between tricking the 
compiler and tricking the QA department.




In my opinion, the
compiler actually _is_ one of the best QA departments.


Indeed it is, and that's the whole point to @safe. My 
motivation here is make suspicious code stand out. @trusted 
code does not stand out so much, because it is required to 
exist.



I'm utterly confused by this.

Trusted code is always suspicious and always stands out because 
it is not formally verified whereas @safe code should be 
bulletproof. Why would anyone bother to manually check code that 
is supposed to be @safe? Trusted code is the villain here; 
wherever you see @trusted you know that the code might contain 
vulnerabilities because it was audited by a human and not by a 
machine.


If you have @safe code that has memory safety issues (from 
callinc C functions) then what's the point of @safe?




Also in my opinion, a competent QA department should carefully 
look at
any @trusted code /declarations. Maybe it is not a "red flag" 
but it is

definitely something that needs to be checked with extra care.


Looking at un-annotated declarations should be the first step. 
If it is annotated with @trusted, at least there's the coffee 
stain on the drawing indicating that somebody looked at it.

Re: Bug?

[RazvanN via Digitalmars-d-learn]

On Tuesday, 5 May 2020 at 05:37:08 UTC, Simen Kjærås wrote:

On Tuesday, 5 May 2020 at 04:02:06 UTC, RazvanN wrote:

[...]


Surely the above code, which silently discards the exception, 
does not print "hello"?


Regardless, I ran your code with writeln inside the catch(), 
and without the try-catch entirely, with and without nothrow on 
K's destructor. I am unable to replicate the issue on my 
computer with DMD 2.091.0, as well as on run.dlang.io. Is 
something missing in your code here?


--
  Simen


Ah sorry! I was on a branch were I had some other modifications. 
Indeed in git master the issue does not manifest.

Bug?

[RazvanN via Digitalmars-d-learn]

truct K
{
~this() nothrow {}
}

void main()
{
static class C
{
this(K, int) {}
}

static int foo(bool flag)
{
if (flag)
throw new Exception("hello");
return 1;
}

try
{
new C(K(), foo(true));
}
catch(Exception)
{
}
}

Result:

object.Exception@test.d(18): hello

If the destructor of K is not marked nothrow the code does not 
throw an exception. Is this a bug or am I missing something?

Re: The Serpent Game Framework - Open Source!!

[RazvanN via Digitalmars-d-announce]

On Thursday, 27 February 2020 at 22:29:41 UTC, aberba wrote:
There's this ongoing open source game framework by Ikey. I knew 
him to be a diehard C guru (from the Solus Project) but is now 
rocking D, hence Serpent.


Check is out and support if you can, please.

I don't know how he does it but Ikey can code stuff like crazy.

https://lispysnake.com/blog/2020/02/02/the-slippery-serpent/


Maybe we should add this project to our CI infrastructure.

Re: GSOC 2020 projects

[RazvanN via Digitalmars-d-announce]

On Monday, 24 February 2020 at 17:43:41 UTC, Panke wrote:

On Monday, 24 February 2020 at 02:52:04 UTC, RazvanN wrote:

On Tuesday, 18 February 2020 at 05:59:47 UTC, RazvanN wrote:

Hello everyone!

In a couple of days we should find out if The Dlang 
Foundation was accepted as a mentoring organization for 
Google Summer of Code 2020. If we get accepted, I think that 
we should have a list of priority projects that we should 
propose to students. I have started tagging what I find the 
most useful projects with the gsoc2020 tag [1]. If you want 
to help in this process you can:


[...]


Unfortunately, Dlang has not been accepted this year as a GSOC 
mentoring organization. Maybe we will have better luck next 
year,


Cheers,
RazvanN


Do we know why?


They simply notify if you have been accepted or not without 
offering any details, but I think that they want to offer a 
chance to everyone. Apart from big organizations that are offered 
spots every year, the small organizations are usually rotated, 
but we can't know for sure if there was something wrong with our 
application or they simply wanted to give someone else a chance.

Re: GSOC 2020 projects

[RazvanN via Digitalmars-d-announce]

On Tuesday, 18 February 2020 at 05:59:47 UTC, RazvanN wrote:

Hello everyone!

In a couple of days we should find out if The Dlang Foundation 
was accepted as a mentoring organization for Google Summer of 
Code 2020. If we get accepted, I think that we should have a 
list of priority projects that we should propose to students. I 
have started tagging what I find the most useful projects with 
the gsoc2020 tag [1]. If you want to help in this process you 
can:


[...]


Unfortunately, Dlang has not been accepted this year as a GSOC 
mentoring organization. Maybe we will have better luck next year,


Cheers,
RazvanN

GSOC 2020 projects

[RazvanN via Digitalmars-d-announce]

Hello everyone!

In a couple of days we should find out if The Dlang Foundation 
was accepted as a mentoring organization for Google Summer of 
Code 2020. If we get accepted, I think that we should have a list 
of priority projects that we should propose to students. I have 
started tagging what I find the most useful projects with the 
gsoc2020 tag [1]. If you want to help in this process you can:


1. Go through the issues in the projects repo [2] and propose a 
specific issue to be tagged for gsoc2020. If one of the proposed 
projects on the repo is important for you and you want to see it 
implemented, create a thread on the General forum so that we can 
discuss the importance of the project and then decide if we tag 
the issue or not.


2. Go through the issues in the project repo and volunteer to 
mentor a specific project that is of interest to you. If you want 
to be a mentor please post a comment stating your intention on 
the project page and email me at razvan.nitu1...@gmail.com .


3. Create new issues on the projects repo [2] detailing what the 
project is, what are the rough milestones and who are the persons 
of contact.


GSOC is a great opportunity to push things forward so let's see 
what are the most important points that we want to see across the 
finish line,


Cheers,
RazvanN


[1] 
https://github.com/dlang/projects/issues?q=is%3Aopen+is%3Aissue+label%3Agsoc2020

[2] https://github.com/dlang/projects

Re: "D for a @safer Linux Kernel" poster presentation at APLAS

[RazvanN via Digitalmars-d-announce]

On Thursday, 3 October 2019 at 17:30:20 UTC, Arun Chandrasekaran 
wrote:

On Thursday, 3 October 2019 at 11:21:41 UTC, RazvanN wrote:

[...]


Good to know. May be you could publish the code on 
GitHub/GitLab and that could attract interest among people who 
care about performance to take a look. It's tricky to measure 
performance at this scale.


The code is public: https://github.com/alexandrumc/d-virtio/pull/1

Re: "D for a @safer Linux Kernel" poster presentation at APLAS

[RazvanN via Digitalmars-d-announce]

On Thursday, 3 October 2019 at 07:13:05 UTC, Arun Chandrasekaran 
wrote:

On Friday, 27 September 2019 at 09:26:22 UTC, RazvanN wrote:

Hello all,

Alexandru Militaru's work "D for a @safer Linux Kernel" [1] 
has just been accepted for a poster presentation at APLAS [2]. 
We hope that this will be good publicity for D,


Cheers,
RazvanN

[1] https://www.youtube.com/watch?v=weRSwbZtKu0
[2] 
https://conf.researchr.org/track/aplas-2019/aplas-2019-posters#About


Nice. Has there been any recent performance improvements? There 
was a similar talk recently at the Linux Security Summit [1] 
yesterday from the Rust community.


[1] https://www.youtube.com/watch?time_continue=1=RyY01fRyGhM


It seems that they are creating a framework for developing kernel 
modules in rust that can be integrated with the linux kernel. 
They haven't tested the performance of a particular rust driver 
compared to a C one. This is a bit different from what we did: we 
directly ported a C driver to D and integrated it with the 
kernel, with negligible performance loss. The 4% performance loss 
that was encountered in some situations is due to the fact that 
we have D wrappers over C function calls and some macros are 
translated as functions that are called at runtime - they are not 
inlined -; one thing we still need to do is to test with the 
recent link time optimizations (LTO) and profile guided 
optimizations (PGO) flags in clang; we are confident that this 
will enhance the performance of the ported driver).

Re: "D for a @safer Linux Kernel" poster presentation at APLAS

[RazvanN via Digitalmars-d-announce]

On Friday, 27 September 2019 at 10:39:42 UTC, M.M. wrote:

On Friday, 27 September 2019 at 09:26:22 UTC, RazvanN wrote:

Hello all,

Alexandru Militaru's work "D for a @safer Linux Kernel" [1] 
has just been accepted for a poster presentation at APLAS [2]. 
We hope that this will be good publicity for D,


Cheers,
RazvanN

[1] https://www.youtube.com/watch?v=weRSwbZtKu0
[2] 
https://conf.researchr.org/track/aplas-2019/aplas-2019-posters#About


Congratulations! Hopefully, you will make a research paper out 
of it as well. That will make the content available to much 
broader audience!


Thanks you! That is our plan also. We hope we will finish the 
paper until late December and we will see where we can submit.

"D for a @safer Linux Kernel" poster presentation at APLAS

[RazvanN via Digitalmars-d-announce]

Hello all,

Alexandru Militaru's work "D for a @safer Linux Kernel" [1] has 
just been accepted for a poster presentation at APLAS [2]. We 
hope that this will be good publicity for D,


Cheers,
RazvanN

[1] https://www.youtube.com/watch?v=weRSwbZtKu0
[2] 
https://conf.researchr.org/track/aplas-2019/aplas-2019-posters#About

Re: The New Bug Bounty System

[RazvanN via Digitalmars-d-announce]

On Saturday, 17 August 2019 at 12:04:46 UTC, Mike Parker wrote:
Thanks to BOS Platform Korea, the new Bug Bounty system is 
live. Anyone willing to seed new bounties or increase the 
existing ones is free to do so. We hope to see the number of 
bounties grow and a few folks make some money from it. The 
details are in the blog post:


https://dlang.org/blog/2019/08/17/bug-bounties-have-arrived/

Reddit:
https://www.reddit.com/r/d_language/comments/crla4a/bug_bounties_have_arrived/

And for those who want to skip the blog post for now and get 
straight to work (read it later, though!):


https://www.flipcause.com/secure/cause_pdetails/NjI2Njg=

I'll see about getting this into the Community menu sometime 
soonish.


Awesome! Now we can fix bugs AND get rich at the same time!

UPB D Summer School

[RazvanN via Digitalmars-d-announce]

Hello,

Edi and myself are glad to announce that the first edition of the 
D Summer School that we organized for the students at the 
University Politehnica of Bucharest has just ended.


We had 8 practical sessions and a hackathon, during which 
students had to work on their project a peer-to-peer client 
implementation using vibe.d). The students were lucky enough to 
actually have Andrei present them the "Design by Introspection" 
course. It goes without saying that they were thrilled.


Our materials can be found here [1] if anybody is interested ( 
big thanks to Ali for his approval on basing our course on his 
book). Photos from the hackathon and Andrei's lecture can be 
found here [2].


We hope that by bringing D bootcamp courses to students we can 
raise awarness on D and increase its popularity and enlarge our 
community.


We have encouraged the graduating students to participate to SAOC 
and also we are in discussions with some of them to initiate them 
into contributing to D.


Cheers,
RazvanN

[1] https://ocw.cs.pub.ro/courses/dss/
[2] 
https://photos.google.com/share/AF1QipMRoQCmOcPh4E9nvn4hL4gGXeebPDYV9lSlH8lMhaZJmL4z6lt6QcCNs8iFvPkmxw?key=WUU3eXY3T05vR09HZlQ3X3ZBTXdidTBNQ3YzU01n

Re: DConf 2019 Livestream

[RazvanN via Digitalmars-d-announce]

On Wednesday, 8 May 2019 at 12:13:18 UTC, Mike Parker wrote:

On Wednesday, 8 May 2019 at 10:13:35 UTC, Ethan wrote:



Good news everyone! A Youtube stream will be arriving after 
the lunch break.


Cheers for your patience.


Now I get to bring the bad news. There's an issue right now 
with YouTube flipping the video horizontally in the livestream 
such that everything is backwards. They've been trying to find 
a solution for it but are so far unable to. As such, we're 
stuck with WebEx for the remainder of the day. They'll try to 
get it sorted this evening so that we can stream on YouTube 
tomorrow.


Sorry for those of you having difficulties with WebEx.


Will the recordings be uploaded somewhere (preferably youtube)?

Re: DIP 1018--The Copy Constructor--Formal Review

[RazvanN via Digitalmars-d-announce]

On Sunday, 24 February 2019 at 10:46:37 UTC, Mike Parker wrote:
Walter and Andrei have requested the Final Review round be 
dropped for DIP 1018, "The Copy Constructor", and have given it 
their formal approval. They consider copy constructors a 
critical feature for the language.


Walter provided feedback on Razvan's implementation. When it 
reached a state with which he was satisfied, he gave the green 
light for acceptance.


The DIP:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md


The implementation:
https://github.com/dlang/dmd/pull/8688


Are there any other concerns regarding the copy constructor DIP? 
Although the debate about the value of const's transitivity is an 
interesting one, it is orthogonal to this proposal.


Regarding the mutability of the copy constructor source: it is 
not mandatory that the source is mutable; you can define it as 
const, it's just that it is not going to work with mutable 
objects that contain indirections. There is no workaround for 
this, and per the current language rules this is not a problem.


As for the *by ref* rvalue DIP, I suggest that the discussion 
should be moved in an other forum thread, as the discussion is 
hijacked from getting feedback for DIP 1018


Cheers,
RazvanN

Re: std.container.rbtree as Interval Tree?

[RazvanN via Digitalmars-d-learn]

On Monday, 4 February 2019 at 22:54:01 UTC, James Blachly wrote:
I tried to implement an interval tree backed by 
std.container.rbtree today and fell flat.


[...]

You can use alias this [1] in your interval element type:

struct IntervalElem
{
size_t start, end;
/* ... other declarations */
alias start this;
}

[1] https://dlang.org/spec/class.html#AliasThis


Q2: Would replacing "Elem" with a generic type "T" in the 
function signatures for upperBound, lowerBound, and various 
related fns like _firstGreater / _firstGreaterEqual solve this 
problem?


[...]
Elem is already a generic type. I don't know how you can make it 
more generic without adding other template parameters to the 
class declaration (which means reimplementing RBTree from 
std.container);



James

[1] https://dlang.org/spec/operatoroverloading.html#eqcmp ("For 
example ... x and y are disjoint sets, then neither x < y nor y 
< x holds, but that does not imply that x == y. Thus, it is 
insufficient to determine equality purely based on opCmp alone. 
")

Re: Segfault when adding a static destructor in druntime/src/rt/sections_elf_shared.d

[RazvanN via Digitalmars-d-learn]

On Thursday, 10 January 2019 at 23:04:37 UTC, Steven 
Schveighoffer wrote:

On 1/10/19 5:12 PM, RazvanN wrote:
On Thursday, 10 January 2019 at 15:04:25 UTC, Steven 
Schveighoffer wrote:

On 1/8/19 7:54 AM, RazvanN wrote:

[...]


That is a thread-local static destructor. Are any shared 
static destructors accessing the array?


No, there aren't. Indeed, the problem is as Johan as said: the 
loadedDSOs should not be wrapped in an array with a destructor 
because it is manually destroyed.


Hm... is this a sign of how things will be once the (necessary 
IMO) change to destroying globals is deployed?


-Steve


At least for this specific situation, yes.

Re: Segfault when adding a static destructor in druntime/src/rt/sections_elf_shared.d

[RazvanN via Digitalmars-d-learn]

On Thursday, 10 January 2019 at 15:04:25 UTC, Steven 
Schveighoffer wrote:

On 1/8/19 7:54 AM, RazvanN wrote:

[...]


That is a thread-local static destructor. Are any shared static 
destructors accessing the array?


No, there aren't. Indeed, the problem is as Johan as said: the 
loadedDSOs should not be wrapped in an array with a destructor 
because it is manually destroyed.
You might be able to determine this by printf debugging between 
calling unshared and shared destructors.


-Steve

Re: Segfault when adding a static destructor in druntime/src/rt/sections_elf_shared.d

[RazvanN via Digitalmars-d-learn]

On Tuesday, 8 January 2019 at 14:30:24 UTC, Johan Engelen wrote:

On Tuesday, 8 January 2019 at 12:54:11 UTC, RazvanN wrote:

[...]


Great!
(I am _extremely_ surprised that dtors are not called for 
globals.)


[...]


Thanks! This is really helpful!

RazvanN

Segfault when adding a static destructor in druntime/src/rt/sections_elf_shared.d

[RazvanN via Digitalmars-d-learn]

Hi all,

I am working on issue 14650 [1] and I would like to implement a 
solution where static destructors are destroying global 
variables. However, I have the following problem in 
druntime/src/rt/sections_elf_shared:


struct ThreadDSO
{
DSO* _pdso;
static if (_pdso.sizeof == 8) uint _refCnt, _addCnt;
else static if (_pdso.sizeof == 4) ushort _refCnt, _addCnt;
else static assert(0, "unimplemented");
void[] _tlsRange;
alias _pdso this;
// update the _tlsRange for the executing thread
void updateTLSRange() nothrow @nogc
{
_tlsRange = _pdso.tlsRange();
}
}
Array!(ThreadDSO) _loadedDSOs;


For this code, I would have to create the following static 
destructor:


static ~this() { _loadedDSOs.__dtor(); }

Because Array defines a destructor which sets its length to 0.

However this code leads to segfault when compiling any program 
with the runtime (betterC code compiles successfully). In my 
attempt to debug it, I dropped my patch and added the above 
mentioned static destructor manually in druntime which lead to 
the same effect. Interestingly, _loadedDSOs.__dtor runs 
successfully, the segmentation fault comes from somewhere higher 
in the call path (outside of the _d_run_main function (in 
rt/dmain2.d)). I'm thinking that the static destructor somehow 
screws up the object which is later referenced after the main 
program finished executing. Does someone well versed in druntime 
has any ideas what's happening?


Cheers,
RazvanN



[1] https://issues.dlang.org/show_bug.cgi?id=14650

Re: Blog post: What D got wrong

[RazvanN via Digitalmars-d-announce]

On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote:

On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves 
wrote:

A few things that have annoyed me about writing D lately:

https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/


That was a really good blog post, however I am strongly 
against the following sentence:


"I think there’s a general consensus that @safe, pure and 
immutable should be default."


It's not at all a general consensus and doing this would 
literally break all the existing D code. Without discussing 
all the technical aspects, this will severely impact the 
adoption rate of D because it will make it very complicated 
for people coming from a C/C++/Java background to accommodate 
with the language. In addition, this is completely against D's 
liberal philosophy where you can program however you want.


My impression is that it's a consensus that it _should_, but 
it's not going to happen due to breaking existing code.


this will severely impact the adoption rate of D because it 
will make it very complicated for people coming from a 
C/C++/Java background to accommodate with the language


How? Rust has immutable and safe by default and it's doing fine.

D and Rust are competing to get the C/C++/Java/Python market 
share. In order to do that they should make it simple for 
developers to convert to the new language. Due to its design, 
Rust is insanely hard to master, which on the long run I think 
will kill the language despite of the advantages it offers. On 
the other side, consider die hard C fans: they are willing to 
accept the possibility of a buffer overflow simply because they 
want more power. Do you honestly think that they will ever take D 
into account if @safe and immutable data will be the default?


this is completely against D's liberal philosophy where you 
can program however you want.


It would be if the change weren't accompanied by adding 
`impure` and some sort of mutable auto. @system already exists. 
It's a question of opting out (like with variable 
initialisation) instead of opting in.


It still is, because the user is imposed to work in certain 
conditions that some might not want to.

Re: Blog post: What D got wrong

[RazvanN via Digitalmars-d-announce]

On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:

A few things that have annoyed me about writing D lately:

https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/


That was a really good blog post, however I am strongly against 
the following sentence:


"I think there’s a general consensus that @safe, pure and 
immutable should be default."


It's not at all a general consensus and doing this would 
literally break all the existing D code. Without discussing all 
the technical aspects, this will severely impact the adoption 
rate of D because it will make it very complicated for people 
coming from a C/C++/Java background to accommodate with the 
language. In addition, this is completely against D's liberal 
philosophy where you can program however you want.

Re: The #dbugfix Campaign Round 1 Report

[RazvanN via Digitalmars-d-announce]

On Tuesday, 6 November 2018 at 11:12:44 UTC, Mike Parker wrote:

On Tuesday, 6 November 2018 at 08:45:13 UTC, RazvanN wrote:
/the_dbugfix_campaign_round_1_report/

[...]


It faded out. It went well in the first round, then I got only 
a handful in the second round (all from two people), then it 
went quiet. There were only two people actively in 
communication with me about volunteering, and the small pool of 
issues that did come in were beyond what they had the time or 
knowledge to fix. So without enough #bugfix posts or tweets 
coming in, I finally gave up.


What I can do, though, is assemble a list of all of the 
#dbugfix tweets and forum posts that I'm aware of and send them 
to you. Then you can choose some to work on and we can do a 
blog post about it. Maybe we can get something going again from 
that.


Sounds good. Thanks!

Re: The #dbugfix Campaign Round 1 Report

[RazvanN via Digitalmars-d-announce]

On Monday, 14 May 2018 at 15:23:41 UTC, Mike Parker wrote:
I planned an extended vacation with my wife around DConf this 
year and, despite my intentions before we left, fell quite far 
behind on my D duties. I'm in the process of getting caught up 
with everything, and that includes publishing the results of 
the first round of the #dbugfix campaign.


As far as I'm concerned, it was a successful run. Now, I'm 
eager to improve upon it. Send some more #dbugfix nominations 
out into the ether and, while you're at it, volunteer to review 
some PRs. The issue queue isn't going to shrink all that much 
until the PR queue gets smaller.


Thanks to everyone who nominated an issue or voiced support for 
a nomination in Round 1, and thanks in advance to those who 
will in the future!


The blog:
https://dlang.org/blog/2018/05/14/the-dbugfix-campaign-round-1-report/

reddit:
https://www.reddit.com/r/d_language/comments/8jcz5n/the_dbugfix_campaign_round_1_report/


Is this still happening? If yes, I am willing to volunteer.

Re: Copy Constructor DIP and implementation

[RazvanN via Digitalmars-d-announce]

On Monday, 8 October 2018 at 10:26:17 UTC, Nicholas Wilson wrote:

On Monday, 8 October 2018 at 10:14:51 UTC, RazvanN wrote:

On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote:

Hi all,

I just pushed another version of the DIP in which the major 
modifications among otthers are removing implicit and use 
copy constructor calls in all situations where a copy is 
made. For more details, please visit [1] and if you have the 
time, please offer some feedback,


Thank you,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129/


I've made all the changes in the code that the DIP includes[1] 
and the tests seem to be all green. I still need to add more 
tests; if you have any tests that you want to make sure the 
implementation takes into account please post them.


Cheers,
RazvanN

[1] https://github.com/dlang/dmd/pull/8688


Both the DIP and the implementation still lack a -dip10xx 
switch.


After discussing with Walter and Andrei we came to the conclusion 
that a flag is not necessary in this case. Immediately after the 
DIP is accepted, the postblit will be deprecated.

Re: Copy Constructor DIP and implementation

[RazvanN via Digitalmars-d-announce]

On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote:

Hi all,

I just pushed another version of the DIP in which the major 
modifications among otthers are removing implicit and use copy 
constructor calls in all situations where a copy is made. For 
more details, please visit [1] and if you have the time, please 
offer some feedback,


Thank you,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129/


I've made all the changes in the code that the DIP includes[1] 
and the tests seem to be all green. I still need to add more 
tests; if you have any tests that you want to make sure the 
implementation takes into account please post them.


Cheers,
RazvanN

[1] https://github.com/dlang/dmd/pull/8688

Re: Copy Constructor DIP and implementation

[RazvanN via Digitalmars-d-announce]

Hi all,

I just pushed another version of the DIP in which the major 
modifications among otthers are removing implicit and use copy 
constructor calls in all situations where a copy is made. For 
more details, please visit [1] and if you have the time, please 
offer some feedback,


Thank you,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129/

Re: `shared`...

[RazvanN via Digitalmars-d]

On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:

struct Bob
{
  void setThing() shared;
}

As I understand, `shared` attribution intends to guarantee that 
I dun

synchronisation internally.
This method is declared shared, so if I have shared instances, 
I can

call it... because it must handle thread-safety internally.

void f(ref shared Bob a, ref Bob b)
{
  a.setThing(); // I have a shared object, can call shared 
method


  b.setThing(); // ERROR
}

Instead of making mutable->shared conversion implicit, you use 
template this parameters:


struct B
{
 void setThing(this T)()
 {
 static if(is(T == shared(B)))
 {
 /* do synchronisation */
 }
 else
 {
/* all other cases */
 }
 }
}


I think that it's great that mutable(T) is not implicitly 
convertible to shared(T) as it makes synchronization bugs a lot 
more obvious.


Cheers,
RazvanN

Copy Constructor DIP and implementation

[RazvanN via Digitalmars-d-announce]

Hello everyone,

I have finished writing the last details of the copy constructor 
DIP[1] and also I have published the first implementation [2]. As 
I wrongfully made a PR for the DIP queue in the early stages of 
the development of the DIP, I want to announce this way that the 
DIP is ready for the draft review now. Those who are familiar 
with the compiler, please take a look at the implementation and 
help me improve it!


Thanks,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688

Re: @betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?

[RazvanN via Digitalmars-d]

On Sunday, 29 July 2018 at 14:21:20 UTC, Seb wrote:
Phobos has recently gotten a primitive way to run betterC tests 
(https://github.com/dlang/phobos/pull/6640).


Now, it would be really cool if we can annotate existing tests 
with e.g. `@betterCTest` and thus ensure that those tests work 
with -betterC (i.e. extract them and run them with a minimal 
test runner.


a) @betterC

Probably too popular and would lead to too many conflicts.


How about @worksWithBetterC? This is specific enough



b) @TestBetterC


This one is good too.


c) @betterCTest || @bettercTest

Would probably be defined a enum somewhere in `std.internal`


Thumb up.



d) @("betterC")

A bit ugly and harder to work with. If we ever want to name the 
unittests in Phobos, this will make it harder.


Thumb down.



At some point we might also want to test whether something runs 
even without any runtime 
(https://github.com/dlang/phobos/pull/6641), so e.g. 
`@baremetalTest` might be defined too.


Why not @noRuntime?

Re: Moving druntime into the DMD repository

[RazvanN via Digitalmars-d]

On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:

This a thread to explore whether it would be feasible to do so.


From my experience, whenever a change in dmd required a change in 
druntime the protocol was pretty straightforward and not at all 
annoying:


-> you make the dmd PR and it causes druntime breakage
-> you make the druntime PR to fix the problem

Problem solved. The only overhead here is :

git checkout -b druntime_fix
git push -f origin druntime_fix

Having druntime and dmd as separate repos makes sense because the 
two are logically separated. If druntime and dmd are merged 
together based on your motivation, there's only a matter of time 
until someone, following the same logic as you did, will propose 
to also merge phobos with dmd + druntime since modifying the 
latter often requires changing the former.


The only situation where your proposal has any benefit is when a 
circular dependency arises: you first need the druntime patch to 
be able to merge the dmd one and at the same time you first need 
the dmd patch to merge the druntime one. I don't even know if 
such a situation is possible, but even so, in this case we can 
just bite the bullet and merge them both at the (pseudo)same time.


RazvanN

Re: Generated opAssign in the presence of a copy constructor

[RazvanN via Digitalmars-d]

Why the memcpy?
This looks inefficient.

Is it in case the constructor throws?
Have a 'nothrow' case where it constructs directly to this?


The copy constructor must be called on an object in the initial 
state,
so it cannot be called directly on this as it is already 
initialized.


__dtor is used as a matter of demonstration. Indeed, xdtor is the 
the alias which points to the generated destructor (__dtor, 
__fieldDtor or __aggregatedDtor)

Generated opAssign in the presence of a copy constructor

[RazvanN via Digitalmars-d]

Hello everyone!

As you probably know, I am working on the copy constructor DIP 
and implementation. So far, I managed to implement 95% of the 
copy constructor logic (as stated in the DIP). The point that is 
a bit of a headache is how/when should opAssign be generated when 
a copy constructor is defined. Now here is what I have (big 
thanks to Andrei for all the ideas, suggestions and brainstorms):


-> mutability of struct fields:

If the struct contains any const/immutable fields, it is 
impossible to use the copy constructor for opAssign, because the 
copy constructor might initialize them. Even if the copy 
constructor doesn't touch the const/immutable fields the compiler 
has to analyze the function body to know that, which is 
problematic in situations when the body is missing. => opAssign 
will be generated when the struct contains only assignable 
(mutable) fields.


-> qualifiers:

The copy constructor signature is : `@implicit this(ref $q1 S 
rhs) $q2`, where q1 and q2 represent the qualifiers that can be 
applied to the function and the parameter (const, immutable, 
shared, etc.). The problem that arises is: depending on the 
values of $q1 and $q2 what should the signature of opAssign be?


A solution might be to generate for every copy constructor 
present its counterpart opAssign: `void opAssign(ref $q1 S rhs) 
$q2`. However, when is a const/immutable opAssign needed? There 
might be obscure cases when that is useful, but those are niche 
situations where the user must step it and clarify what the 
desired outcome is and define its own opAssign. For the sake of 
simplicity, opAssign will be generated solely for copy 
constructors that have a missing $q2 = ``.


-> semantics in the presence of a destructor:

If the struct that has a copy constructor does not define a 
destructor, it is easy to create the body of the above-mentioned 
opAssign: the copy constructor is called and that's that:


void opAssign(ref $q1 S rhs)// version 1
{
S tmp = rhs;// copy constructor is called
memcpy(this, tmp);  // blit it into this
}

Things get interesting when a destructor is defined, because now 
we also have to call it on the destination:


void opAssign(ref $q1 S rhs)   // version 2
{
   this.__dtor;   // ensure the dtor is called
   memcpy(this, S.init)   // bring the object in the initial state
   this.copyCtor(rhs);// call constructor on object in .init 
state

}

The problem with the above solution is that it does not take into 
account the fact
that the copyCtor may throw and if it does, then the object will 
be in a partially initialized state. In order to overcome this, 
two temporaries are used:


void opAssign(ref $q1 S rhs)// version 3
{
S tmp1 = rhs;// call copy constructor
void[S.sizeof] tmp2 = void;

// swapbits(tmp1, this);
memcpy(tmp2, this);
memcpy(this, tmp1);
memcpy(tmp1, tmp2);

tmp1.__dtor();
}

In this version, if the copy constructor throws the object will 
still be in a valid state.


-> attribute inference for the generated opAssign:

For version 1: opAssign attributes are inferred based on the copy 
constructor attrbiutes.
For version 2: opAssign attributes are inferred based on copy 
constructor and destructor attributes
For version 3: the declaration of the void array can be put 
inside a trusted block and then attributes are inferred based on 
copy constructor and destructor attributes


If the copy constructor is marked `nothrow` and the struct 
defines a destructor, then version 2 is used, otherwise version 3.


What are your thoughts on this?

RazvanN

Re: Disabling struct destructor illegal?

[RazvanN via Digitalmars-d-learn]

On Thursday, 19 July 2018 at 09:50:32 UTC, Jim Balter wrote:

On Thursday, 19 July 2018 at 08:50:15 UTC, RazvanN wrote:

struct A
{
int a;
@disable ~this() {}
}

void main()
{
A a = A(2);
}

Currently, this code yields:

Error: destructor `A.~this` cannot be used because it is 
annotated with @disable


I was expecting that disabling the destructor would make it as 
if the struct does not have a destructor


Why? That's not the semantics of @disable. And why would you 
want that? What are you actually trying to achieve?


I just don't understand why you would ever mark the destructor of 
a struct with @disable. When is that useful? If it's not, why not 
just forbit it?

Disabling struct destructor illegal?

[RazvanN via Digitalmars-d-learn]

struct A
{
int a;
@disable ~this() {}
}

void main()
{
A a = A(2);
}

Currently, this code yields:

Error: destructor `A.~this` cannot be used because it is 
annotated with @disable


I was expecting that disabling the destructor would make it as if 
the struct does not have a destructor, instead it makes the 
program not compile. I find this behavior odd: why not make it 
illegal to disable the destructor if disabling it will surely 
result in errors wherever the struct is used. The only situation 
where the code will compile is A is never used directly. To make 
matters even more confusing, this code compiles:


class A
{
int a;
@disable ~this() {}
}

void main()
{
A a = new A();
}


So, is this a bug or am I missing something?

Yoroshiku onegaishimasu,
RazvanN

Re: Copy Constructor DIP

[RazvanN via Digitalmars-d]

In a post-blit world, with no opAssign specified, postblit 
will call
for copy construction AND for assignment, thereby assignment 
is always

correct.
Once postblit is swapped for a copy-constructor, absence of 
opAssign

will result in invalid behaviour on assignment.


Indeed, but this was the source of the problem also, because you 
could

modify immutable fields that way.

Introduction of copy constructor breaks default assignment, it 
needs
to address it somehow. I think my suggestion is the only 
practical

solution.


Affirmative. The DIP needs to specify how assignment is handled 
if no opAssign is present but a copy ctor is present. Thanks!


The difference between a copy constructor and opAssign is how the 
type checking
is performed. This leads to situations where a copy constructor 
is not suitable as an assignment operator. However, if a copy 
constructor is defined in a way that is correctly type checked 
both as a constructor and as a normal function, then there is no 
problem in using the copy constructor for assignments:


struct A
{
immutable int b;
int c;
@implicit this(ref A rhs)
{
this.c = rhs.c;
}
}

struct B
{
immutable int b;
int c;
@implicit this(ref A rhs)
{
this.b = rhs.b;
this.c = rhs.c;
}
}

void main()
{
A a, c;
A b = a;
b = c;   // no problem in calling copy constructor, 
immutable is

 // not modified
B d, e;
B f = d;
f = d;   // cannot use copy constructor because it will 
modify immutable
 // field B.b; for this situation you need an 
opAssign to specify

 // how the assignment is dealt with.
}

The problem with this approach is that some copy constructors 
will also be used as assignment operators while others will not, 
but with good error messages it could be handled (error on line 
`f = d` : opAssign not specified and the copy constructor is not 
suitable for assignments because it modifies immutable field `b`).


What are your opinions on this?

Re: Copy Constructor DIP

[RazvanN via Digitalmars-d]

The above code contains a typo. The parameter type of the second 
copy constructor is meant to be B not A

Re: Copy Constructor DIP

[RazvanN via Digitalmars-d]

That's my point; so this is a compile error then:
S b = S(a); // <- explicit construction of copy? ie, explicit 
call to

stated `@implicit` function


Consider this code:

import std.stdio : writeln;

struct S
{

this(this)
{
writeln("postblit");
}
int a;
this(int a)
{
this.a = a;
}

this(ref S another)
{
writeln("calling this");
}

}


void main()
{
S a;
S b = S(a);
}

In this situation, the constructor is called; if `this(ref S 
another)` is commented the code will result in a compilation 
error "constructor S.this(int) is not callable using argument 
types (S)", so the postblit is NOT called. In my opinion this is 
the desired behavior and should be implemented by the copy 
constructor also. If you are doing `S b = S(a)` then you are 
explicitly trying
to call a constructor; if it doesn't exist, then it's an error; 
if you wanted to call the copy constructor then you would have 
done `S b = a;`. Using S(a) states the intention of explicitly 
calling a constructor while the copy constructor can

only be called implicitly.

Re: Copy Constructor DIP

[RazvanN via Digitalmars-d]

What's wrong with:
struct S {
  this(ref S copyFrom);
}

That looks like a perfectly good copy constructor declaration 
;) I'm just saying, the DIP needs to explain this.


That is actually a valid constructor, according to today's 
compiler. There
might be code out there that uses this syntax for the constructor 
and overnight

it will be turned into a copy constructor.

I agree that the current syntax is lacking. This was Andrei's 
proposition
and I was initially against it, but he said to put it in the DIP 
so that

we can discuss it as a community. Maybe this syntax is better:

@this(ref S a another)

It looks like the c++ copy constructor but the `@` makes it 
different from

a constructor, so we're good. What do you think?


Right. This is all obvious and intuitive.
What I'm hearing is that under this proposal, copy constructors 
and
assignment operators DO come in pairs (just like in C++), but 
that's
not mentioned here in this DIP. Since this proposal will 
introduce

that recommended pattern from C++, it may be worth mentioning.


If by "come in pairs" you mean that you can define them both, 
then yes,

that is the case. Will add a paragraph in the DIP to specify this.

You mentioned that it's terrible that the assignment operator
and the copy constructor come in pairs. Why is that? Would you 
rather
have a copy constructor that is used also as an assignment 
operator?

Re: Copy Constructor DIP

[RazvanN via Digitalmars-d]

But there's a super explicit `@implicit` thing written right 
there... so should we expect that an *explicit* call to the 
copy constructor is not allowed? Or maybe it is allowed and 
`@implicit` is a lie?


The @implicit is there to point out that you cannot call that 
method
explicitly; it gets called for you implicitly when you construct 
an object

as a copy of another object.

Re: Copy Constructor DIP

[RazvanN via Digitalmars-d]

On Tuesday, 10 July 2018 at 20:58:09 UTC, Manu wrote:
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d 
 wrote:


Hi everyone!

I managed to put together a first draft of the DIP for adding 
the copy constructor to the language [1]. If anyone is 
interested, please take a look. Suggestions and comments about 
technical aspects and wording are all welcome.


Thanks,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129


I feel there's some things missing.

1. Explain the need and reasoning behind `@implicit`... that's 
weird


It is a simple way of defining a copy constructor without the 
need of

adding new keywords and with minimal additions to the parser.


and I don't like it at face value.
2. It looks like copy constructors are used to perform 
assignments
(and not constructions)... but, there is also opAssign. What 
gives?

Eg:
  S b = a; // <- copy construction? looks like an 
assignment.

And not:
  S b = S(a); // <- actually looks like a construction, but 
this
syntax seems to not be intended (and rightly so, it's pretty 
terrible)
3. In C++, copy constructors and copy assignment operators come 
in
pairs (which is totally lame!), but we don't see that same 
pattern

extend here, and it's not clear at all why.
4. Given the special rules where assignments are lifted to
constructions, I want to know when that occurs (maybe that is 
already

spec-ed wrt postblit?)

- Manu


Copy construction is used solely when the object was not 
initialized and it

cannot be used otherwise. Consider this example:

struct A
{
immutable int a = 7;
@implicit this(ref A another)
{
 this.a = A.a;  // first assignment over .init state 
- ok

}

void opAssign(A rhs)
{
this.a = rhs.a;
}
}

void main()
{
A a = A(2);
A b = a; //  initialization -> calls copy 
constructor
b = a;   // cannot call copy constructor because 
it will

 // modify immutable; call opAssign.
}

The first assignment of b calls the copy constructor and the 
immutable field is
initialized; later assignments to b.a will result in "modify 
immutable" error.
The second assignment of b cannot call the copy constructor 
because it would then modify an initialized immutable field. 
However, with opAssign the compiler knows that A.a cannot be 
modified because it is immutable.

Copy Constructor DIP

[RazvanN via Digitalmars-d]

Hi everyone!

I managed to put together a first draft of the DIP for adding the 
copy constructor to the language [1]. If anyone is interested, 
please take a look. Suggestions and comments about technical 
aspects and wording are all welcome.


Thanks,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129

Re: Class qualifier vs struct qualifier

[RazvanN via Digitalmars-d-learn]

Honestly, from what I understand of how this works, what I find 
weird is the struct case. immutable on classes does _not_ make 
the class itself immutable. It just makes all of its members 
immutable - hence the error about trying to allocate new Foo 
instead of new immutable Foo. So, that is exactly what I would 
expect. And honestly, being able to write Foo and have it imply 
immutable Foo would get _really_ confusing when reading and 
debugging code.


Maybe it has something to do with structs being value types and 
classes
being reference types. If you declare an immutable struct then 
you cannot
modify it's value, while if you declare a class, the pointer to 
the class
is mutable, while the class fields are not. This kind of makes 
sense, however
the thing is that in both situations you are not able to mutate 
any of the
class/struct fields no matter how you instantiate it, so it is 
really redundant

to use `immutable` when creating the instance.

What's bizarre is that marking the struct with immutable would 
affect anything other than its members.


Bar b;

should not claim that typeof(b) is immutable(Bar). b was not 
marked as
immutable. It was listed as Bar, not immutable Bar. So, b 
shouldn't be

immutable.

- Jonathan M Davis

Class qualifier vs struct qualifier

[RazvanN via Digitalmars-d-learn]

Hello,

I'm having a hard time understanding whether this inconsistency 
is a bug or intended behavior:


immutable class Foo {}
immutable struct Bar {}

void main()
{
import std.stdio : writeln;
Foo a;
Bar b;

writeln("typeof(a): ", typeof(a).stringof);
writeln("typeof(b): ", typeof(b).stringof);
}

prints:

typeof(Foo): Foo
typeof(Bar): immutable(Bar)


It seems like the class storage class is not taken into account 
which leads to some awkward situations like:


immutable class Foo
{
this() {}
}

void main()
{
Foo a = new Foo(); // error: immutable method `this` is not 
callable using a

   // mutable object
}

To make it work I have to add immutable to both sides of the 
expression : immutable Foo a = new immutable Foo(); this is a 
wonder of redundancy. I already declared the class as immutable 
so it shouldn't be possible to have mutable instances of it (and 
it isn't), however I am forced to write the immutable twice even 
though it is pretty obvious that the class cannot be mutated.

Constructor qualifiers; bug or expected behavior?

[RazvanN via Digitalmars-d-learn]

Hi all,

Let's say we have this code:

struct B
{
int a;
this(int a) immutable
{
this.a = 7;
}

this(int a)
{
this.a = 10;
}
}

void main()
{
B a = immutable B(2);
writeln(a.a);
a.a = 4;

immutable B a2 = immutable B(3);
writeln(a2.a);
a2.a = 3;// error : cannot modify
}

Both a and a2 will be constructed using the immutable 
constructor, however a is not immutable (a.a = 4 will compile 
fine). Is this the intended behavior? Shouldn't the compiler warn 
me that I'm trying to create a mutable object using the 
constructor for an immutable object? I couldn't find any 
documentation about this.

Postblit documentation

[RazvanN via Digitalmars-d-announce]

Hi all,

I've been documenting how the postblit works [1] and discovered 
that it has some major issues when used with qualifiers. I will 
try to come up with an alternative design, but until then, anyone 
interested please take look and modify/add anything you find 
suitable.


Cheers,
RazvanN

[1] https://dlang.org/spec/struct.html#struct-postblit

Re: CTFE ^^ (pow)

[RazvanN via Digitalmars-d]

On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:
What is so hard about implementing a pow intrinsic that CTFE 
can use?

It's ridiculous that we can't CTFE any non-linear function...
It's one of those blocker bugs that's been there almost 10 
years.


Well, there is this PR : https://github.com/dlang/dmd/pull/8071

Re: Understanding the AST...

[RazvanN via Digitalmars-d-learn]

On Thursday, 22 February 2018 at 13:21:04 UTC, joe wrote:

On Monday, 12 February 2018 at 08:47:58 UTC, RazvanN wrote:

Hi Joe,

/SNIP

On Tuesday, 6 February 2018 at 12:03:06 UTC, joe wrote:

[...]


The FuncDeclaration node contains all the information for that.
For example, you can access fd.parent to see if the function is
declared at top-level (in which case, the parent is going to 
be a module
declaration ) or if it is a nested function (in a class, in a 
struct, in a function).
Every AST node contains information about the position in the 
AST, all you
have to do is find how to get that information: which field to 
access or which

member function to call.

/SNIP

Cheers,
RazvanN


Follow up question...

Why is *.parent always null?
e.g.:

extern(C++) class MyVisitor(AST): ParseTimeTransitiveVisitor!AST
{
  override void visit(AST.Import i)
  {
assert(i.parent is null); // always true
  }

  override void visitFuncBody(AST.FuncDeclaration f)
  {
assert(f.parent is null); // always true
  }
}


Indeed, @Stefan is right. The ParseTimeVisitor only contains 
information available at parse time. If you are interested in the 
parent you have 2 options: either (1) use the ParseTimeVisitor 
and implement the AST traversal logic yourself or (2) you can use 
the SemanticTimeTransitiveVisitor in which case the parent is not 
going to be null. In the case of (2) you need to also do some 
semantic analysis (so you need the whole dmd library, not just 
the parsing one). Here's an example on using the dmd library 
(including semantic) [1]. You can copy paste that example and add 
a few lines of code where you instantiate your visitor (which 
will inherit SemanticTimeTransitiveVisitor).


[1] 
https://github.com/dlang/dmd/blob/master/test/dub_package/frontend.d


RazvanN

Re: How to check if aggregate member is static templated method?

[RazvanN via Digitalmars-d-learn]

On Thursday, 15 February 2018 at 13:51:41 UTC, drug wrote:

15.02.2018 16:50, drug пишет:

https://run.dlang.io/is/zHT2XZ
I can check againts if member is either static function or 
template. But I failed to check if it both static and templated.


The best I could come up with is:

struct Foo
{
static staticMethod()
{
}

static templatedStaticMethod(T)(T t)
{
}
}

void main()
{
static if(__traits(isTemplate, Foo.templatedStaticMethod) &&
  __traits(isStaticFunction, 
Foo.templatedStaticMethod!int))

{
 writeln("win");
}
}

It seems like a templated method can be queried if it is static 
only after it's instantiation. Hope this helps.


Cheers,
RazvanN

Re: Understanding the AST...

[RazvanN via Digitalmars-d-learn]

Hi Joe,

I suggest you watch this video which explains how the parse time 
visitors work: https://www.youtube.com/watch?v=tK072jcoWv4 .


On Tuesday, 6 February 2018 at 12:03:06 UTC, joe wrote:

Hello everybody!

Last week end I found this post ( 
https://dlang.org/blog/2017/08/01/a-dub-case-study-compiling-dmd-as-a-library/ ) on the Blog and thought to myself awesome.


So I built the library and everything went smooth. Thanks for 
the effort of all the involved people who made that possible!


I've had a look at the 2 examples, too, the avg. function lines 
( https://github.com/dlang/dmd/blob/master/src/examples/avg.d ) 
and the import ( 
https://github.com/dlang/dmd/blob/master/src/examples/impvisitor.d ) ones and for a start I decided to make a program that prints the outline of a module.


Turns out I don't really understand how to access the data in 
the AST.
For everything there's a visitor method and overriding a few of 
them to print return statements and some such works as 
advertised.


However, I have no idea where I am in the tree when any of 
those methods are called.
Like for example in 
FunctionLengthVisitor(AST).visitFuncBody(AST.FuncDeclaration 
fd).
I have a function declaration object which tells me everything 
about what's inside the function, but how do I know what or 
where this function belongs to, where can I get that 
information ? I don't see anything about UDAs either, nor the 
doc comment.




The FuncDeclaration node contains all the information for that.
For example, you can access fd.parent to see if the function is
declared at top-level (in which case, the parent is going to be a 
module
declaration ) or if it is a nested function (in a class, in a 
struct, in a function).
Every AST node contains information about the position in the 
AST, all you
have to do is find how to get that information: which field to 
access or which

member function to call.

I understand when visitor.getAvgLen is called with the parsed 
module, the accept function calls a visitor overload for each 
member.
But this sounds to me like I'd have to do a lot of book keeping 
in my visitor to keep track of things which are already present 
in the AST.


The function average length visitor inherits a transitive visitor
which means that the AST traversal logic is already implemented 
for you.
All you have to do is override the visiting methods of interest 
and do
whatever suits you : print stuff, alter the ast, stop the 
visitation or

continue the visitation (by calling super.visit(ASTnode)).



Any insight to this would be much appreciated :)


I know that my explanations might not be very explicit, but if 
you have an example please post it and we can work on it.


Cheers,
RazvanN

Re: Who can make Phobos faster to import?

[RazvanN via Digitalmars-d]

On Tuesday, 26 December 2017 at 15:38:14 UTC, Joakim wrote:

On Tuesday, 26 December 2017 at 13:27:38 UTC, RazvanN wrote:

On Thursday, 21 December 2017 at 03:31:16 UTC, Joakim wrote:
On Wednesday, 20 December 2017 at 18:21:33 UTC, Andrei 
Alexandrescu wrote:
A tool (call it depend - heh) to automate that would be 
awesome. For example, this run would make all imported names 
explicit:


depend --explicit *.d

This run would push all imports down to the innermost scope 
of usage:


depend --pushdown *.d


Andrei


I'm on it.  I tried using a version of Seb's frontend library 
yesterday but with the standard dmd main and tried running it 
on std.stdio, but it asserted in asmSemantic because of an 
asm block somewhere in druntime, so I'm back to using a 
tweaked full dmd with the backend simply disabled again:


I ran into the same issue. The problem was that currently the 
frontend
doesn't set the version identifiers. There's a PR which tries 
to fix it [1],
but if you want to go back at using the compiler library via 
Seb's interface
you just have to call this method [2] in the initialization 
step.


I doubt that's it, as I noted I was running the standard dmd 
main from mars.d.  More likely it tries to run asmSemantic on 
an asm block in core.atomic and asserts because that function's 
stubbed out when there's no backend.


Anyway I am working on this sort of tool also, so maybe we can 
unite our efforts.


As in the `depend` import-scoping tool that Andrei wanted 
above?  If so, that'd be great, as you know the frontend much 
better than me.  I've been meaning to investigate how to 
extract a scope tree from the frontend, as I've never done much 
with dmd.


Let me know how far you've gotten and what you want it to do 
initially, and maybe I can pitch in with your effort.


Yes, that was the tool I was talking about. I was thinking that 
the first
version of the tool just outputs for each import what the used 
symbols are;
for example : if you import std.stdio and use 3 symbols from it, 
the tool will output "std.stdio: sym1, sym2, sym2" and then the 
programmer can update the code accordingly. After developing this 
initial version we can think on how to improve it.


For now, my tool only identifies imported non-templated 
functions, but I plan on adding support variables, types etc.


We can chat on slack more about this if you are interested.

Re: Who can make Phobos faster to import?

[RazvanN via Digitalmars-d]

On Thursday, 21 December 2017 at 03:31:16 UTC, Joakim wrote:
On Wednesday, 20 December 2017 at 18:21:33 UTC, Andrei 
Alexandrescu wrote:

On 12/15/2017 02:10 PM, Seb wrote:

[...]


Dmitry wrote a nice PR for that, and I wrote two:

https://github.com/dlang/phobos/pull/5942
https://github.com/dlang/phobos/pull/5931
https://github.com/dlang/phobos/pull/5948

My approach has been the following:

* First I tried to clarify which module imports what by means 
of replacing "import std.xxx;" with "import std.xxx : yyy, 
zzz, ...;" That has been of tremendous help in assessing each 
module's dependency liability.


* Then I tried to figure which imports are most costly. I 
inserted __EOF__ in the module at different parts and measure 
how long it takes to just import that module. After a few 
attempts it becomes clear which imports are heaviest.


* Then I pushed those heavy imports down where they're needed. 
An import placed in a function will not be opened while that 
function's module gets imported. Same goes about template 
types, but not structs or classes. (That should be fixed; see 
Seb's comment in my last PR.)


Not only such work reduces import times, but it's illuminating 
for maintenance because it represents dependencies in a 
simple, fine-grained matter.


A tool (call it depend - heh) to automate that would be 
awesome. For example, this run would make all imported names 
explicit:


depend --explicit *.d

This run would push all imports down to the innermost scope of 
usage:


depend --pushdown *.d


Andrei


I'm on it.  I tried using a version of Seb's frontend library 
yesterday but with the standard dmd main and tried running it 
on std.stdio, but it asserted in asmSemantic because of an asm 
block somewhere in druntime, so I'm back to using a tweaked 
full dmd with the backend simply disabled again:


I ran into the same issue. The problem was that currently the 
frontend
doesn't set the version identifiers. There's a PR which tries to 
fix it [1],
but if you want to go back at using the compiler library via 
Seb's interface

you just have to call this method [2] in the initialization step.

Anyway I am working on this sort of tool also, so maybe we can 
unite our efforts.

Ping me if you wish so,

[1] https://github.com/dlang/dmd/pull/7524
[2] https://github.com/dlang/dmd/blob/master/src/dmd/mars.d#L1314


https://github.com/dlang/dmd/pull/7425
https://github.com/dlang/dmd/blob/master/src/dmd/gluelayer.d#L47
https://gist.github.com/joakim-noah/09cf49bee3d82b03a54f

Once I have something basic working, I'll put it up on github, 
so others who are interested can play with it and pitch in to 
make it a real tool.


Best regards,
RazvanN

Re: ddox empty public methods/interfaces etc

[RazvanN via Digitalmars-d-learn]

On Thursday, 9 November 2017 at 14:21:52 UTC, Steven 
Schveighoffer wrote:

On 11/8/17 10:45 PM, Andrey wrote:


I just added to dub.json this:


"-ddoxFilterArgs": [
    "--min-protection=Public"
]


i.e. without --only-documented option, in this way ddox will 
generate documentation for all public methods, even if there 
is no docstring.


Interesting. I misunderstood then how ddox works. I thought the 
json it gets is the output from the ddoc generator, but now I 
realize it's the output from the parser itself.


So sure, this makes sense. Sorry for the misinformation!

-Steve


I don't want to open a new forum thread for this, but if you guys 
have more experience with ddox can you please explain me how does 
it work? I expected you can simply run ddox on a .d file and it 
will output the documentation in some sort of form (json, html or 
whatever), but from what I saw, you need to pass it the json if 
you want to use serve-html/generate-html/filter and you have to 
use dmd to generate the json. Looking on the source code only 
passing serve-test actually parses the .d file, but the 
serve-test doesn't seem to be a public parameter.


Thanks in advance,
RazvanN

Re: std.concurrency.setMaxMailboxSize

[RazvanN via Digitalmars-d-learn]

On Wednesday, 11 October 2017 at 11:26:11 UTC, rikki cattermole 
wrote:

On 11/10/2017 12:09 PM, RazvanN wrote:

Hi all,

I have seen that the concurrency api has this method specified 
in $title [1] and I was wondering what is the use of it? 
Enabling threads to modify the message box of other threads 
doesn't seem to be a good idea and I can't think of any real 
use case.


Best regards,
RazvanN

[1] 
https://dlang.org/phobos/std_concurrency.html#.setMaxMailboxSize


Main controlling thread setting child threads?

Otherwise I don't remember the last time it was mentioned, so 
I'd say leave it be :)


Shouldn't the thread be in charge of its mailbox size? Otherwise, 
main can pass the max size in the constructor.

std.concurrency.setMaxMailboxSize

[RazvanN via Digitalmars-d-learn]

Hi all,

I have seen that the concurrency api has this method specified in 
$title [1] and I was wondering what is the use of it? Enabling 
threads to modify the message box of other threads doesn't seem 
to be a good idea and I can't think of any real use case.


Best regards,
RazvanN

[1] 
https://dlang.org/phobos/std_concurrency.html#.setMaxMailboxSize

Default hashing function for AA's

[RazvanN via Digitalmars-d]

Hi all,

We in the UPB dlang group have been having discussions about the 
hashing functions of associative arrays. In particular, we were 
wondering why is the AA implementation in druntime is not using 
the hash function implemented in 
druntime/src/core/internal/hash.hashOf for classes that don't 
define toHash().


For us, that seems to be a very good default hashing function.

Best regards,
On behalf of the UPB Dlang group

Re: [your code here]

[RazvanN via Digitalmars-d]

On Thursday, 7 September 2017 at 04:01:21 UTC, Lionello Lunesu 
wrote:

Thought this code ended up really concise and readable:

https://gist.github.com/lionello/60cd2f1524c664d4d8454c01a05ac2c8

Suitable for dlang.org?

L.


The best way to find out it to make a pull request [1]

[1] 
https://gist.github.com/lionello/60cd2f1524c664d4d8454c01a05ac2c8

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

[RazvanN via Digitalmars-d]

On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
See - 
https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce


[...]


I don't think the problem was with the blockchain here. It is 
usually a bad idea to have turing-complete scripts over 
blockchains. From what I've seen the bug was that there was 
issued a library call based on a user-provided string. That could 
have never happened if they would have used D with @safe

Codecov and CyberShadow failure

[RazvanN via Digitalmars-d]

I've noticed a couple of days ago that the 2 components mentioned 
in $title aren't working when making PRs. I don't have any 
experience with this, so what is there to be done?


RazvanN

Re: D bindings for TensorFlow

[RazvanN via Digitalmars-d-learn]

On Friday, 6 January 2017 at 13:22:28 UTC, llaine wrote:
Did anyone used Tensorflow with D ? I would be really 
interesting to know if some libs allows it right now.


I read an old thread about TS on the forum, but since then 
nothing ...


At the moment there is no support in D to use TensorFlow directly 
(the only way is to create the bindings yourself). There has been 
a discussion, a month ago, about creating a D library which would 
be binded to the C++ implementation, but at the moment no 
conclusion was reached.


Hope this answers your question.

RazvanN

Re: Swap front for char[] input ranges

[RazvanN via Digitalmars-d-learn]

On Monday, 19 December 2016 at 20:26:26 UTC, Ali Çehreli wrote:

On 12/19/2016 06:09 AM, RazvanN wrote:
> [...]
wrote:
>> [...]
InputRanges.
>> [...]
following
> [...]
char[]
> [...]
function, so
> [...]
http://dlang.org/phobos/std_algorithm_mutation.html#bringToFront

[...]


No need to mention it. It is an honor to be able contribute
to this great language.


[...]


That is right, I am working on that particular bug. After talking 
with AndreiA,
I submitted this PR [1]. It treats the case of char[], but I am 
not really sure how the constraints should be applied to the 
function since it seems there are

a lot of combinations (especially if char[] is supported).

[1] https://github.com/dlang/phobos/pull/4970

Re: Swap front for char[] input ranges

[RazvanN via Digitalmars-d-learn]

On Monday, 19 December 2016 at 12:25:02 UTC, Ali Çehreli wrote:

On 12/19/2016 02:41 AM, RazvanN wrote:
> [...]

As your comments make it clear below, they cannot be 
InputRanges.


> [...]
swapping code
>  [...]

Obivously, tmp1 and tmp2 are unusued there. :)

> [...]
passed.
> [...]
state
> [...]
is:
> [...]
input ranges
> [...]

Not possible... It's ok to use something similar to the 
following template constraint:


void foo(R1, R2)(R1 r1, R2 r2)
if ((hasSwappableElements!R1 && hasSwappableElements!R2) ||
(hasLvalueElements!R1 && hasLvalueElements!R2)) {
// ...
}

Ali


In this case, the bringToFront function [1] should not accept 
char[]
as parameters? Or a special path should be added in the function, 
so that char[] are treated specially?


[1] 
http://dlang.org/phobos/std_algorithm_mutation.html#bringToFront

Swap front for char[] input ranges

[RazvanN via Digitalmars-d-learn]

Hi,

I have a function which accepts 2 input Ranges and swaps the 
first element in Range1 with the first element in Range2. The 
swapping code looks something like this :


 static if (is(typeof(swap(r1.front, r2.front
 {
 swap(r1.front, r2.front);
 }
 else
 {
 auto t1 = moveFront(r1), t2 = moveFront(r2);
 auto tmp1 = r1.front;
 auto tmp2 = r2.front;
 r1.front = move(t2);
 r2.front = move(t1);
 }

This code works for most cases, except when 2 char[] are passed.
In that case, the compilation fails with error messages which 
state

that r1.front and r2.front are not Lvalues. So, my question is:
how can I swap the 2 elements since in the case of char[] input 
ranges

the front property does not return a reference?

Range of uncopyable elements

[RazvanN via Digitalmars-d-learn]

Hi,

I am trying to create a range with uncopyable elements. My 
thought process was the following:


1.I have created a struct :

struct S
{
int a;

@disable this(this);
}

2. I declared an array :

S[] arr = [S(1), S(2), S(3)];

expecting that arr will be a range like, for example, an int[].
I was surprised to see that isInputRange!arr is false.

So, is there any possibility to create a range with uncopyable 
elements?

Re: Char representation

[RazvanN via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 14:23:28 UTC, Jonathan M Davis 
wrote:
On Tuesday, November 22, 2016 13:29:47 RazvanN via 
Digitalmars-d-learn wrote:

[...]


You misunderstand. char[] is a dynamic array of char, wchar[] 
is a dynamic array of wchar[], and dchar[] is a dynamic array 
of dchar. There is nothing funny going on with the internal 
representation. Rather, the problem is with the range API and 
the traits that go with it. And it's not a bug; it's a design 
mistake.


[...]


Thank you very much for this great explanation. Things are 
starting to make sense now.


Razvan Nitu

Char representation

[RazvanN via Digitalmars-d-learn]

Given the following code:

 char[5] a = ['a', 'b', 'c', 'd', 'e'];
 alias Range = char[];
 writeln(is(ElementType!Range == char));

One would expect that the program will print true. In fact, it 
prints false and I noticed that if Range is char[], wchar[], 
dchar[], string, wstring, dstring
Unqual!(ElementType!Range) is dchar. I find it odd that the 
internal representation for char and string is dchar. Is this a 
bug?

Re: The return of std.algorithm.find

[RazvanN via Digitalmars-d-learn]

On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote:
The find function which receives an input haystack and a needle 
returns the haystack advanced to the first occurrence of the 
needle. For normal ranges this is fine, but for

sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 
7]. This is in terms with the general policy of the find 
function, but is weird. Since we know the range is sorted, 
shouldn't the result be [1, 2, 4]?


The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 
7]), 4). And the result is

the whole range [1, 2, 4, 5, 6, 7].

The return of std.algorithm.find

[RazvanN via Digitalmars-d-learn]

The find function which receives an input haystack and a needle 
returns the haystack advanced to the first occurrence of the 
needle. For normal ranges this is fine, but for

sorted ranges (aka SortedRange) it is a bit odd. For example:

find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 
7]. This is in terms with the general policy of the find 
function, but is weird. Since we know the range is sorted, 
shouldn't the result be [1, 2, 4]?

Re: Concatenate 2 ranges

[RazvanN via Digitalmars-d-learn]

On Friday, 11 November 2016 at 13:33:20 UTC, Vladimir Panteleev 
wrote:

On Friday, 11 November 2016 at 13:30:17 UTC, RazvanN wrote:
I know that I can use the .array property, but I think that 
this iterates through all of my elements. Using 
assumeSorted(chain(r1, r2).array) will return a SortedRange, 
but I am not sure what the complexity for this operation is.


.array allocates, so it's going to be O(n), but the allocation 
will probably be more expensive.


Is there a way to concatenate 2 ranges (SortedRange in my 
case) in O(1) time?


assumeSorted(chain(a, b)) ?

This works for me:

auto r = assumeSorted(chain([1, 2, 3].sort(), [1, 2, 
3].sort()));


It does work, the problem is that [1, 2, 3].sort() is of type 
SortedRange(int[], "a < b") while r is of type 
SortedRange(Result, "a < b"). This is a problem if you want to 
return r in a function which has return type SortedRange(int[], 
"a < b").

Concatenate 2 ranges

[RazvanN via Digitalmars-d-learn]

I am trying to concatenate 2 ranges of the same type (SortedRange 
in my case). I have tried merge, join and chain, but the problem 
is that the result is not an object of the type of the initial 
ranges. For example:


1. If I use chain(r1, r2), the result will be an object of type 
Result which I cannot cast to my specific type (SortedRange).


2. If I use merge(r1, r2), the result will be an object of type 
Merge!(typeof(r1), typeof(r)).


I know that I can use the .array property, but I think that this 
iterates through all of my elements. Using assumeSorted(chain(r1, 
r2).array) will return a SortedRange, but I am not sure what the 
complexity for this operation is.


Is there a way to concatenate 2 ranges (SortedRange in my case) 
in O(1) time?

Re: is operator and SortedRange

[RazvanN via Digitalmars-d-learn]

On Friday, 11 November 2016 at 12:02:10 UTC, ketmar wrote:

On Friday, 11 November 2016 at 11:49:25 UTC, RazvanN wrote:

[...]



template isSortedRange(T) {
  private import std.range : SortedRange;
  static if (is(T : SortedRange!TT, TT)) {
enum isSortedRange = true;
  } else {
enum isSortedRange = false;
  }
}


void main () {
  import std.algorithm : sort;
  int[] a;
  a ~= [1, 6, 3];
  auto b = a.sort;
  pragma(msg, typeof(b));
  pragma(msg, isSortedRange!(typeof(a))); // false
  pragma(msg, isSortedRange!(typeof(b))); // true
}


Thank you! Worked like a charm

is operator and SortedRange

[RazvanN via Digitalmars-d-learn]

I am a bit confused about how the is operator works. I have a 
function which receives an InputRange and a predicate. Now I need 
to be able to test if the InputRange is actually a SortedRange. I 
don't care about how the datatypes behind the SortedRange or the 
predicate, I just need to see if the object is a SortedRange. I 
have tried the following test:


static if(is(typeof(haystack) == SortedRange!(T, _pred), T, 
_pred))


where haystack is the InputRange, but the test fails. Is there a 
way to test if the InputRange is a SortedRange without having to 
explicitly pass the primitive tupe on top of which the 
SortedRange is built?

Obtain predicate from SortedRange

[RazvanN via Digitalmars-d-learn]

Given a SortedRange object, is there a way to obtain the 
predicate which was used for it to be sorted?

Re: typeof(SortedRange) and is operator

[RazvanN via Digitalmars-d-learn]

On Tuesday, 8 November 2016 at 13:59:19 UTC, Nicholas Wilson 
wrote:

On Tuesday, 8 November 2016 at 13:22:35 UTC, RazvanN wrote:
Sorry, I accidentally posted the above message and I don't 
know how to erase it.


You can't, this is a mailing list not a forum.


The following post is the complete one:

Given the following code:

int[] arr = [1, 2, 9, 4, 10, 6];
auto r= sort(arr);

if(is(typeof(r) == SortedRange!(int[], "a expression` lambdas don't work 
at all in template expressions.


`SortedRange!(int[], "a