Re: Warning for anyone who was at DConf.

[Ali Çehreli via Digitalmars-d-announce]

I came here to report the same: I have my first positive Covid test, 
apparently from DConf.


So far, mild flu-like muscle pain for me.

Ali

On 9/2/23 13:41, Dukc wrote:
Just a while ago I was hit by some sort of a violent ailment. I first 
noticed it like an hour ago, and I'm shivering as I stand in a 
well-heated house, despite having had a sauna just a while ago. 
Temperature already high.


I wouldn't rule out having contracted it at DConf, and could well be the 
Covid. Please watch your health for a few days if you were at DConf or 
related events.

Re: A New Era for the D Community

[Ali Çehreli via Digitalmars-d-announce]

On 5/3/23 05:08, Mike Parker wrote:

On Wednesday, 3 May 2023 at 11:37:31 UTC, Nicholas Wilson wrote:

From memory that was merely an AGM at DConf, but sure, I'll take 
credit for that (despite knowing next to nothing about management)!


The AGM was your idea, but so were the regular meetings. You pushed it 
to Ali in 2018. I have a second-hand email record!


Wow! I wouldn't have remembered but it's an email I wrote on November 3, 
2018, which starts with "Nicholas Wilson visited the Bay Area for an 
LLVM conference and I had a couple of chances to see him."


Good old days! :)

Ali

Re: DConf '23 August 29th - September 1 --- Early-Bird Registration is Open!

[Ali Çehreli via Digitalmars-d-announce]

On 3/25/23 04:41, Ikey Doherty wrote:

>> Do a talk and get tickets/hotel paid for :)
>
> Walked into that one, didn't I. :)

You had already walked into that one when you posted about your Serpent 
OS work. ;)


Ali

Re: Release D 2.102.0

[Ali Çehreli via Digitalmars-d-announce]

On 2/2/23 10:29, jmh530 wrote:
> On Thursday, 2 February 2023 at 17:22:46 UTC, Ali Çehreli wrote:
>> [snip]
>>
>>   https://issues.dlang.org/show_bug.cgi?id=17378
>>
>>
>
> Looks like your bug report is for assert and static assert, but the PR
> only handles static assert.

I've noticed that as well.

> You might want to file a separate one for assert.

I am a little hesitant after long philosophical (to me) discussions on a 
tangential topic. That forum discussion is linked from this bug:


  https://issues.dlang.org/show_bug.cgi?id=17226

The forum discussion:

  https://forum.dlang.org/thread/qwixdanceeupdefyq...@forum.dlang.org

I still agree with myself :) in that discussion here:

  https://forum.dlang.org/post/tlqcjq$usk$1...@digitalmars.com

And I think this code is how 17226 should be fixed as:

  https://forum.dlang.org/post/tldrrs$qn$1...@digitalmars.com

Ali

Re: Release D 2.102.0

[Ali Çehreli via Digitalmars-d-announce]

On 2/2/23 04:30, Iain Buclaw wrote:

> Glad to announce D 2.102.0, ♥ to the 40 contributors.

Thanks indeed! Two issues that I had some interest in are fixed. Yay!

  https://issues.dlang.org/show_bug.cgi?id=17378

  https://issues.dlang.org/show_bug.cgi?id=23561

I am aware how complex unicode collation is[1] but I somehow find it 
very wrong to list Ömer at the end. :)


[...]
> Steven Schveighoffer
> Vladimir Panteleev
> Walter Bright
> Ömer Faruk IRMAK

Obviously because I am used to the Turkish alphabet but in any case 
because Ö is very much related to O, I find it universally better to 
list Ö right after O. (The same should be for all latin based characters.)


I see there is std.uni.icmp which uses

  dmd/std/internal/unicode_tables.d

but it doesn't help because the array fullCaseTable in there seems to be 
about equivalence (e.g. of ß and ss). I think we need a "mostly correct" 
collation for latin based characters.


I have a hacky[2] solution only for Turkish, which I used for the Index 
section of my book:



https://bitbucket.org/acehreli/ddili/src/4c0552fe8352dfe905c9734a57d84d36ce4ed476/src/alphabet.d#lines-50

Ali

[1] https://www.unicode.org/reports/tr10/

[2] The comment about the hacky treatment of 'I' in there is another 
example of how difficult collation is. This may not fit everybody's 
preference but as a result and as I desired, the entries "IDE" and 
"InputRange" appear under 'İ' in the index (instead of 'I'):


  http://ddili.org/ders/d/ix.html

Re: D Language Foundation Monthly Meeting Summary for December 2022

[Ali Çehreli via Digitalmars-d-announce]

On 1/23/23 12:06, H. S. Teoh wrote:

> `.parallel` -- it's basically zero cost.  And for script-like helper
> utilities, .parallel is just the thing you need to get the job done in
> the shortest amount of time possible.  No need for anything more
> elaborate.

Yes! :)

As a heads up to those who haven't tried it yet, there are cases that 
may benefit from reducing the work unit size from its default value of 100.


Especially when it's about file processing and there are a few files 
that take disproportionate amount of processing time, then the thread 
that is working on the largest file(s) would be holding on to 99 others 
to process them later in serial fashion. This may happen when the other 
e.g. 20 threads have already finished their tasks.


So, I recommend experimenting with smaller work unit sizes; I currently 
use 1 for such file processing. Something like this:


  auto tp = new TaskPool(totalCPUs / 2);   // Thread count
  foreach (e; tp.parallel(elements, 1)) {  // Work unit size
// ...
  }
  tp.finish(); // Don't forget

as seen here:

  https://youtu.be/dRORNQIB2wA?t=1692

Ali

Re: D Community Conversations: Walter Bright on the Origins of D Part 2

[Ali Çehreli via Digitalmars-d-announce]

On 10/12/22 17:52, ItIsEncapsulatedOrItisNot wrote:
> On Thursday, 13 October 2022 at 00:46:09 UTC, ItIsEncapsulatedOrItisNot
> wrote:

Creative new name. However, although access rights are related to 
encapsulation, they don't provide it. Encapsulation is encapsulation.


> My programs are now clearer than ever, has less bugs, and still work,
> just fine.

If you removed all private keywords from your programs absolutely 
nothing would change.


Ali

Re: Ali introduced D at Northeastern University

[Ali Çehreli via Digitalmars-d-announce]

On 10/8/22 16:11, Walter Bright wrote:

Just posted it in the "New" section of HackerNews



On the front page at the moment.

Ali

Ali introduced D at Northeastern University

[Ali Çehreli via Digitalmars-d-announce]

DConf 2022 speaker Mike Shah[1] had invited me to give a presentation 
for the computer science students at Northeastern University.


I was there this past Friday having a great time not only presenting but 
also meeting with the students, drinking non-virtual beer bought by 
Steven Schveighoffer. :)


Mike has just posted the video on his YouTube channel:

  https://www.youtube.com/watch?v=0JL9uT_XGZE

Ali

[1] https://dconf.org/2022/#mikes

Re: D + Qt + QtDesigner

[Ali Çehreli via Digitalmars-d-announce]

On 10/1/22 17:31, Willian wrote:

> How can I use CopperSpice with Qt + Dlang?

Normally, one needs D bindings for C and C++ libraries.

Barbara offered help to work with people experienced in D to produce 
such bindings.


Ali

Re: D + Qt + QtDesigner

[Ali Çehreli via Digitalmars-d-announce]

On 9/27/22 16:21, Vladimir Marchevsky wrote:

> Considering licensing model of Qt and political decisions of Qt
> Foundation

Those were the reasons why my friends Barbara and Ansel started CopperSpice:

  https://www.copperspice.com

Ali

Re: Introducing alid

[Ali Çehreli via Digitalmars-d-announce]

On 9/15/22 02:18, Salih Dincer wrote:

On Thursday, 15 September 2022 at 02:30:43 UTC, Ali Çehreli wrote:

On 9/14/22 12:08, Ali Çehreli wrote:
  import alid;  // WRONG - Could not make it work
  import alid.alid; // Worked with package.d file


What's objection with combining all the code in the package into one 
module?


SDB@79


As a general principal, we don't want to include more than necessary. 
One reason can be compilation speed and binary size: 'import std;' 
compiles slow and (likely) adds and initializes module variable my 
program does not need.


Ali

Re: Introducing alid

[Ali Çehreli via Digitalmars-d-announce]

On 9/14/22 12:08, Ali Çehreli wrote:

>- Subpackage design (thinking about it...)

Ok, I think I fixed that one as well.

I think my main problem was trying to import 'alid':

  import alid;  // WRONG - Could not make it work
  import alid.alid; // Worked with package.d file

I think subpackages work as well:

  import alid.cached;
  // etc.

(Yes, I used many "I think"s. :) )

Ali

Re: Introducing alid

[Ali Çehreli via Digitalmars-d-announce]

On 9/12/22 02:15, Ali Çehreli wrote:
> I am happy to publish on code.dlang.org for the first time:
>
>https://code.dlang.org/packages/alid

I've fixed 2 of the 3 issues reported here:

  - Removed gratuitous function attributes

  - Fixed Salih's .cycle use case

  - Subpackage design (thinking about it...)

Let's continue with the issues at a more appropriate place:

  https://github.com/acehreli/alid/issues

Thanks! :)

Ali

Re: Introducing alid

[Ali Çehreli via Digitalmars-d-announce]

On 9/12/22 09:34, rikki cattermole wrote:

> dub.json
> errornogc/alid/errornogc.d
> circularblocks/alid/circularblocks.d

Considering I may want to let the users import the entire package as 
well with


  import alid;

how can I achieve my goal of subpackages? Telling me to forget about 
subpackages altogether :) is an option because I've already spent hours 
trying to find my way through different directory structures, random 
dub.json edits, experimenting with ways of stopping dub from fetching 
and using the bad version of the repo repeatedly, and many other random 
things...


The main problem is likely I don't have an accurate mental model of the 
whole thing. For example, I don't know whether dub will take the state 
of my local directory as-is or will it copy from the committed state of 
the local repo? I ask because the add-local command puts a commit hash 
as well. If that's the case, I wouldn't want to commit every little 
change before seeing it's effect.


Yes, I did the path override thing as well...

Ali

Re: Introducing alid

[Ali Çehreli via Digitalmars-d-announce]

On 9/12/22 22:24, Salih Dincer wrote:

> `source.CachedRange!(ElementCache!(Result)).CachedRange.front` is not
> callable using a `const` object

This exposes at least two issues:

1) The error was because I did not define cached's front as const 
because it has to expand the underlying buffer (a member) as needed. (I 
would have marked the buffer 'mutable' but we don't have that in D.)


This can be solved in some ways, crudest of which is the following:

(cast()this).expandAsNeeded(id, 1);

Which is technically undefined behavior because the 'cached' range 
object could really be on read-only memory but since we are talking 
about a range, and such objects are supposed to be mutated, it becomes 
an interesting discussion at that point.


(There must be other ways like casting just the buffer but it is related 
to the discussion below.)


After fixing it that way (not pushed to github), I hit another 
compilation error.


2) This point is about a topic that I brought up recently: Types gain a 
'const' eagerly (and they have to, understandably).


For example, in your example you are caching an 'int', but my code sees 
const(int) just because std.range.Cycle.front chose to put a 'const' on 
itself. (With all good intentions: Cycle.front really does not mutate a 
Cycle object.)


However, as my range picks the element type with ElementType!T, I see 
const(int) as well. Again, all good so far... And here is my opApply 
funtion:


int opApply(int delegate(ref EC.ET) func) scope
{
while(!empty)
{
auto f = front;

int result = func(f);// ERROR
if (result)
{
return result;
}
popFront();
}

return 0;
}

ERROR: delegate `func(ref int)` is not callable using argument types 
`(const(int))`


Oh! See: I am passing an int... oh! by ref...  I guess I shouldn't 
expect my users to use 'const' in their foreach parameters. (I am not 
trying to see whether it is possible.)


So instead, I should have decided on my storage type as int (not 
const(int)) in this case. It can be done like this:


static if (hasIndirections!(EC.ET))
{
// Use the exact type
alias StorageT = T;
}
else
{
alias StorageT = Unqual!T;
}

But... Do I have the right to choose my storage type as 'int' even 
though I am caching const(int)? Perhaps I shouldn't because as discussed 
earlier in the general forum, my choice changes function overloading for 
my users. So, perhaps I should really store const(int)... (?)


I have to digest these issues more before jumping to a solution. :/

Ali

P.S. Related, I had to provide an opApply function because of this reason:

/**
Support for `foreach` loops
 */
// This is needed to support foreach iteration because although
// RefCounted!CachedRange implicitly converts to CachedRange, which would be
// a range, the result gets copied to the foreach loop. Unfortunately, this
// type does not allow copying so we have to support foreach iteration
// explicitly here.
int opApply(int delegate(ref EC.ET) func) scope
{
// ...
}

See that 'ref' there? Maybe I should have provided different opApply() 
functions to cover all cases. I am thinking... :)


Or maybe I should use something else other than RefCounted... Still 
thinking...

Re: Introducing alid

[Ali Çehreli via Digitalmars-d-announce]

On 9/12/22 07:43, rikki cattermole wrote:

Looks pretty well tested, nice!


Thanks! Proud with 100% coverage. :)

But in other less nice things, I take it you did not test with GDC? GDC 
does not support cli args with the same names as dmd. One of these is -mv.


So far, I started learning by copying arsd's dub.json. (Thank you, Adam! 
The misunderstandings are mine. :) )


The file structure of subPackage/alid/subPackage will not require it and 
you will not have the cross import issues, where if you depend on 
errornogc you can also import (and then get linker errors) for 
circularblocks.


If I understand you correctly, the directory structure need to be the 
following (also introducing src, which is clearly missing :)):


alid/src/errornogc/alid/errornogc.d
 .../circularblocks/alid/circularblocks.d
[...]

Can I add a CI step to catch all such issues? It would be awesome if dub 
provided that.


Ali

P.S. Another issue is function attributes seemingly used inaccurately 
but I asked that question on the 'learn' newsgroup already. Ping! ;)

Introducing alid

[Ali Çehreli via Digitalmars-d-announce]

I am happy to publish on code.dlang.org for the first time:

  https://code.dlang.org/packages/alid

Thanks to everyone who made registering a dub package so easy! :)


1) Currently, the main module in `alid` is `cached`, which

- caches range elements to ensure each is executed once (most
  useful with generator ranges that use e.g. `map`),

- as a result, elevates InputRanges to ForwardRanges (plus
  opIndex).

2) But I like `errornogc` as well, which helps throw Error
   objects from @nogc code.


Copying from the README:

* `cached` is for executing elements only once while not holding
  on to already popFront'ed elements for too long. `cached` was
  the main topic of Ali's DConf 2022 lightning talk.

* `circularblocks` was written for storing range elements by
  cached. It can be used independently.

* `blockreusable` was written as storage blocks for
  circularblocks. It can be used independently.

* `errornogc` was needed for throwing Errors from @nogc code. It
  can be used independently.

* `test` contains some helper utilities for unit testing.

Ali

Re: Walter's Edited DConf Talk Video -- Feedback Request

[Ali Çehreli via Digitalmars-d-announce]

On 9/8/22 08:02, Steven Schveighoffer wrote:

> I've seen other conference streams where the image of the speaker is
> very narrow, and therefore they can consume most of the screen with the
> slides. I think that's ideal.
>
> -Steve

I agree that the slides should take more room. The speaker can get more 
space at the start, at the end, and occasionally as he/she is not 
talking directly on any slide.


Other than that, I think Mike is overdoing a great work! ;)

Ali

Re: importC | Using D with Raylib directly | No bindings | [video]

[Ali Çehreli via Digitalmars-d-announce]

On 8/8/22 07:54, jmh530 wrote:

> It says:
> "Otherwise the cpp preprocessor will be used."
>
> You mean the default system cpp preprocessor, correct?

I think it means the 'cpp' program that exists on (almost?) all Linux 
systems.


Ali

Re: Adding Modules to C in 10 Lines of Code

[Ali Çehreli via Digitalmars-d-announce]

On 6/5/22 22:01, forkit wrote:

> I have no doubt that many in the D community would also love to remove
> the class abstraction from the langauge, completely, and then they could
> force people into thinking 'the D way'.

I must accept that "you have no doubt" but that claim is baseless.

> I guess they want us to be grateful, that they have provided us with a
> pseudo class type. How nice of them.

Now, that is trolling.

Ali

Re: A New Game Written in D

[Ali Çehreli via Digitalmars-d-announce]

On 5/20/22 16:24, Kenny Shields wrote:

> an update that addresses the crashing

Anything interesting there? Why was it crashing?

Ali

Re: Release: serverino - please destroy it.

[Ali Çehreli via Digitalmars-d-announce]

On 5/8/22 17:25, H. S. Teoh wrote:

> somebody should make a dmd
> fork that introduces write barriers, plus a generational GC (even if
> it's a toy, proof-of-concept-only implementation) to see if the
> performance hit is really as bad as believed to be.

Ooh! DConf is getting even more interesting. :o)

Ali

Re: Release: serverino - please destroy it.

[Ali Çehreli via Digitalmars-d-announce]

On 5/8/22 16:10, Adam Ruppe wrote:
> On Sunday, 8 May 2022 at 22:09:37 UTC, Ali Çehreli wrote:
>> That effectively uses multiple GCs. I always suspected that approach
>> would provide better latency.
>
> My cgi.d has used some fork approaches for a very long time since it is
> a very simple way to spread this out, it works quite well.

While we are on topic :) and as I finally understood what generational 
GC is[1], are there any fundamental issues with D to not use one?


Ali

[1] Translating from what I wrote in the Turkish forum, here is my 
current understanding: Let's not waste time checking all allocated 
memory at every GC cycle. Instead, let's be smarter and assume that 
memory that survived through this GC cycle will survive the next cycle 
as well.


Let's put those memory blocks aside to be reconsidered only when we 
really have to. This effectively makes the GC only play with short-lived 
objects, reducing the amount of memory touched. This would make some 
objects live forever, but GC never promises that all finalizers will be 
executed.

Re: Release: serverino - please destroy it.

[Ali Çehreli via Digitalmars-d-announce]

Congratulations! :) Looking forward to watching your presentation at 
DConf... ;)


On 5/8/22 14:32, Andrea Fontana wrote:

> Every request is processed by a worker running in an isolated process,
> no fibers/threads, sorry (or thanks?)

That effectively uses multiple GCs. I always suspected that approach 
would provide better latency.


> sending opened file descriptors between processes thru sockets

Sweet!

Ali

Re: Beerconf April 2022

[Ali Çehreli via Digitalmars-d-announce]

On 4/29/22 10:22, Adam D Ruppe wrote:

On Friday, 29 April 2022 at 17:07:27 UTC, rikki cattermole wrote:

Password: `dub4life`


I see you are gatekeeping to keep a certain clique out!


I did not type it; just copy-pasted. Phew... :)

Ali

Re: Adding Modules to C in 10 Lines of Code

[Ali Çehreli via Digitalmars-d-announce]

On 4/17/22 13:12, Walter Bright wrote:

https://nwcpp.org/

An online presentation.

Monday at 7PM PST.


(My earlier post disappeared.)

April 20 is Wednesday.

Ali

Re: Reducing Template Compile Times

[Ali Çehreli via Digitalmars-d-announce]

On 3/24/22 07:54, Mike Parker wrote:


The blog:
https://dlang.org/blog/2022/03/24/reducing-template-compile-times/


There is an opportunity for a minor optimization where the following 
code is introduced in the article.


To reduce code compiled for the non-unittest binary, I sometimes define 
types and import declarations needed only by unittests, inside 
version(unittest) blocks:


version (unittest) {// <-- ADDED

import some_unittest_utils; // <-- Added example

struct JustInt
{
  int x;
}

}   // <-- ADDED

static foreach(_; 0..5)
{
  unittest
  {
JustInt value;
value.send;
  }
}

Ali

Re: RESCHEDULED - Silicon Valley D Meetup - March 18, 2022 - "D's new ImportC for easier C library usage"

[Ali Çehreli via Digitalmars-d-announce]

On 3/17/22 07:25, matheus wrote:

> Any chance this will be available for watch later?

As always, it wasn't in presentation style; rather, my pointing at what 
is possible in source code. I will write something up and make example 
code available.


Ali

Re: RESCHEDULED - Silicon Valley D Meetup - March 18, 2022 - "D's new ImportC for easier C library usage"

[Ali Çehreli via Digitalmars-d-announce]

Please note the new times:

On 3/15/22 14:51, Ali Çehreli wrote:
> I am not an expert on ImportC but I managed to get an example working.
> So it qualifies for a meetup topic! :)
>
>https://www.meetup.com/D-Lang-Silicon-Valley/events/284263151/
>
> It will be on March 18, 7pm Pacific time, which translates to the next
> day in UTC: March 19, 2am (02:00).
>
> I will be at the following link at that time:
>
>https://meet.jit.si/DLangSiliconValleyMeetup

Bonus: I will demonstrate how ImportC effectively adds modules to C.

Ali

Silicon Valley D Meetup - March 17, 2022 - "D's new ImportC for easier C library usage"

[Ali Çehreli via Digitalmars-d-announce]

I am not an expert on ImportC but I managed to get an example working. 
So it qualifies for a meetup topic! :)


  https://www.meetup.com/D-Lang-Silicon-Valley/events/284263151/

It will be on March 17, 7pm Pacific time, which translates to the next 
day in UTC: March 18, 2am (02:00).


I will be at the following link at that time:

  https://meet.jit.si/DLangSiliconValleyMeetup

Ali

Re: trash-d version 15

[Ali Çehreli via Digitalmars-d-announce]

On 3/8/22 08:25, Adam D Ruppe wrote:

> use at last two names: `module mystuff.bar;` instead of `module bar;`,

I strongly agree.

Ali

"D Programlama Dili" is available

[Ali Çehreli via Digitalmars-d-announce]

It is the Turkish (and original) version of "Programming in D". I've 
been sitting on it for a long time because I didn't think there would be 
much interest for it. But friends at the Turkish forum convinced me that 
they would love to see some physical copies. Me too! :) So, here it is:



https://www.amazon.com/Programlama-Dili-Temelden-Bilgisayar-Programc%C4%B1l%C4%B1%C4%9F%C4%B1/dp/1087933064

It is supposed to have the "Look Inside" feature but I don't see it yet. (?)

Ali

P.S. As a reminder, all books are freely available here:

  http://ddili.org/

And the printed book is exactly the same thing as the PDF version there 
with three exceptions: It is on paper, it has a cover, and the book is 
black-and-white.


P.P.S. The $34 that I currently see is waaay too expensive for the 
Turkish market. So, I'm looking for a printer in Turkey (or somewhere 
else) that can bring the price down.

Re: All Community Discord channels are now being bridged to Matrix

[Ali Çehreli via Digitalmars-d-announce]

On 2/12/22 15:31, Arun wrote:
> On Monday, 17 January 2022 at 06:59:40 UTC, bauss wrote:

>> Everything literally exist for emacs
>
> Yeah, emacs is a fine operating system in need of a good editor. ;)

It would be awesome if someone wrote an editor that runs inside Emacs. 
Oh! It kind of exists: M-x shell and start vi in there. :)


Ali

Re: Added copy constructors to "Programming in D"

[Ali Çehreli via Digitalmars-d-announce]

On 2/9/22 18:11, Meta wrote:
> Why do we even bother with `in` when we can do:
>
> alias In(T) = const scope T;
>
> void test(In!int n) {
>  pragma(msg, typeof(n));
> }
>
> ?
>
> onlineapp.d(3): Deprecation: storage class `scope` has no effect in type
> aliases
> const(int)
>
> ...oh

I didn't know that but 'in' is underrated. There is heavy mental load on 
deciding parameter types:


// Silly const:
void foo(const(int));

// Too much information to the user (why
// do they need to know that I will mutate the parameter):
void foo(int);

// When I know that copying is expensive
// (which excludes rvalues; oops):
void foo(ref const(ExpensiveToCopy));

// When I know that the type is non-copyable,
// I have to use 'ref':
void foo(ref const(NonCopyable));

What if foo is a template? ref or const or by-value? Or inout? Always or 
sometimes?


Enough already! :)

All I want to say is "I want to use this parameter as input." I don't 
care if its rvalue or expensive to copy or impossible to copy. I will 
define it as 'ref' if that's what I want but I shouldn't be thinking 
about any of the above for function inputs.


I am happy to raise awareness of the new 'in':

  https://dlang.org/spec/function.html#in-params

'in' allows passing rvalues by ref! 'in' eliminates unwanted 
side-effects just because a function wants to use an object. 'in' passes 
non-copyable types by reference. Wow! That's engineering to my ears. :)


Having said that, there is one thing that bothers me with 'in' or 
'const'. Let's assume I want to mutate a copy of the parameter:


void foo(in int i) {
  ++i;// ERROR
}

So I must make a copy:

  auto j = i;
  ++j;// ERROR

Because 'auto' is too safe and takes 'const'. One more try:

  int j = i;
  ++j;

Or perhaps in some generic code:

  import std.traits : Unqual;
  Unqual!(typeof(i)) j = i;
  ++j;

Ok, fine.

One more thing remains: Although 'i' may be the most logical name for 
the parameter, I cannot name 'j' as 'i' so I can mangle the parameter 
name just to prevent using 'i' in the function by accident:


void foo(in int i_);

That's not good because it changes what my callers see of my function.

I can use 'i_' in the body (instead of 'j') but then I am open to the 
same mistake of using 'i' instead of 'i_' in the body. (Obviously not 
when mutating but when actually using.)


Yeah, that issue bugs me a little.

Ali

Re: Added copy constructors to "Programming in D"

[Ali Çehreli via Digitalmars-d-announce]

On 2/9/22 02:15, Anonymouse wrote:

On Saturday, 8 January 2022 at 02:07:10 UTC, Ali Çehreli wrote:
2) The other noteworthy change in the book is my now-different stance 
on variables: Now I recommend 'const' over 'immutable' for variables.


I'm curious, could you elaborate a bit on this? I skimmed through the 
page on Immutability but I didn't find anything explaining it.


To make sure we are looking at the same version, the new content has the 
following section:



in parameters

As we will see in the next chapter, in implies const and is more useful 
with the ‑preview=in command line switch. For that reason, I recommend 
in parameters over const parameters.



  http://ddili.org/ders/d.en/const_and_immutable.html

In short, in the past, under the influence of "stronger guarantee" 
clearly sounding better, I was recommending immutable for variables:


  immutable i = 42;

Realizing that I don't do that in my own code, now I recommend const:

  const i = 42;

Further, now that we have -preview=in (thanks to Mathias Lang), I 
recommend 'in' over const for parameters. (Actually, I had always 
recommended 'in' and did use it in some of the examples in the book 
(inconsistently) but I wasn't using it in my own code.)


But the whole thing is complicated. :) So, I asked for and received 
opinions on this thread:


  https://forum.dlang.org/thread/sig2d4$657$1...@digitalmars.com

I don't find the common description helpful:  "immutable provides 
stronger guarantee." That's true and sounds better than mere "strong" 
but it does not help a programmer with deciding on which one to use. 
Rather, I like the following distinction:


- const is a promise

- immutable is a requirement

Now, that helps me decide which one to use when. Let's start with a 
function:


void foo(in A a, immutable B b) {
  // ...
}

There, foo "promises" to not mutate 'a' ('in' implies 'const') and 
"requires" that 'b' is not mutated by any other code.


With that understanding, it is silly to "require" that no other code 
mutates a local variable:


void x() {
  immutable b = B();  // Really? Who can mutate it?
  // ...
}

So, the following is logical (and shorter :) ):

void x() {
  const b = B();
  // ...
}

Now, if I need to pass it to a function that "requires" immutable, of 
course I will have to define it as immutable to satisfy that requirement:


void x() {
  immutable b = B();
  foo(A(), b);
  // ...
}

Aside: One of the confusions is that 'const' would work there as well 
*if* B did not have any indirection. But if it's defined as e.g.


struct B {
  int[] arr;
}

then, x() will not compile with 'const b'.

In summary:

Variables: 'const' by default, 'immutable' as needed (because somebody 
requires it)


Parameters: 'in' by default, 'immutable' if required

That's my view. I think there are others who disagree with parts of it 
and that's why this issue is surprisingly complicated.


Ali

Re: Added copy constructors to "Programming in D"

[Ali Çehreli via Digitalmars-d-announce]

On 1/8/22 05:23, Imperatorn wrote:
> On Saturday, 8 January 2022 at 02:07:10 UTC, Ali Çehreli wrote:
>> 1) After about three years, I finally added copy constructors:
>>
>> 
http://ddili.org/ders/d.en/special_functions.html#ix_special_functions.copy%20constructor 



> Will the physical book also be updated?

Yes, now all copies are updated:

- Hardcopy by IngramSpark

- Paperback by IngramSpark and KDP (I checked on Amazon, the "Look 
Inside" feature shows the new content (at least the COpyright page))


- Ebooks on KDP, GumRoad, and Draft2Digital

There are three years' worth of corrections and edits as well. I've also 
removed the "First Edition" misnomer from the book; it is obviously 
continuosly updated.


An of course, everything is free here:

  http://ddili.org/ders/d.en

I have a minor update to that page as well, which should be live soon.

Aside: The D Language Foundation has an Amazon Associate link to the book:

  https://www.amazon.com/dp/1515074609?=dlang-20

And many other ways to take donations:

  https://dlang.org/foundation/donate.html

Ali

Re: From the D Blog: The Binary Language of Moisture Vaporators

[Ali Çehreli via Digitalmars-d-announce]

On 1/24/22 13:57, Moth wrote:

>> Reddit:
>> 
https://www.reddit.com/r/programming/comments/sbn7n6/the_binary_language_of_moisture_vaporators/ 



> first: how exactly does assembly output relate to moisture vaporators?

Someone answered that question on the ycombinator thread. They included 
this video link:


  https://www.youtube.com/watch?v=eUH2_n8jE70=0m30s

> second: what on earth is an ""alpha programmer""? i do hope walter has
> not subscribed to the pseudoscientific views of mysogynists.

I am not aware of any association between "alpha" and "man" because I 
hear both "alpha male" and "alpha female" in e.g. nature documentaries.


Ali

Aside: There was a thread on these forums where somebody was unhappy 
with the word "female" in "female programmers". I think they thought it 
was not a word suitable for humans. Well, I live in California and I can 
report that "female" is what these people use everywhere to mean 
"woman". Of course we can still argue whether it's suitable but it's in 
at least Californian English as of today.

Re: All Community Discord channels are now being bridged to Matrix

[Ali Çehreli via Digitalmars-d-announce]

On 1/15/22 16:53, Paul Backus wrote:


there is a Matrix client for emacs:


I am not surprised at all. :)

Matrix sounds very promising:

  https://matrix.org/

Ali

Re: All Community Discord channels are now being bridged to Matrix

[Ali Çehreli via Digitalmars-d-announce]

On 1/15/22 15:49, rikki cattermole wrote:

> If you don't use Matrix, you can ignore this.

I use Emacs. Is that Matrix? :o)

Ali

Re: All Community Discord channels are now being bridged to Matrix

[Ali Çehreli via Digitalmars-d-announce]

On 1/15/22 10:45, WebFreak001 wrote:

> we have now bridged all the Discord rooms to Matrix rooms.

What does all that mean? Is that something that only Discord users 
should understand be interested in? :)


Ali

Re: Added copy constructors to "Programming in D"

[Ali Çehreli via Digitalmars-d-announce]

On 1/8/22 5:49 AM, Stanislav Blinov wrote:

>> Of course, now I stress that postblit is discouraged.
>
> Bit early, methinks. Copy ctors aren't even fully supported by the
> runtime yet.

Thanks. The spec discourages postblit as well. What's the best of saying 
it then? Something like "There are still limitations of copy 
constructors as of this writing." Or there are just bugs?


Ali

Added copy constructors to "Programming in D"

[Ali Çehreli via Digitalmars-d-announce]

1) After about three years, I finally added copy constructors:


http://ddili.org/ders/d.en/special_functions.html#ix_special_functions.copy%20constructor

Of course, now I stress that postblit is discouraged.

2) The other noteworthy change in the book is my now-different stance on 
variables: Now I recommend 'const' over 'immutable' for variables. And I 
favor 'in' for parameters over 'const'. (Unfortunately, not all code in 
the book follow those guidelines.)


And I recommend the -preview=in command line switch:


http://ddili.org/ders/d.en/function_parameters.html#ix_function_parameters.in,%20parameter

3) I've updated all electronic formats: PDF, EPUB, AZW3, and MOBI:

  http://ddili.org/ders/d.en/

I had some trouble with ebooks in the past: The fonts would not work and 
table of contents would not be generated. Please let me know if you see 
something wrong.


WARNING: The paper book publishers are not updated yet. If you order a 
paper book now, you will get the old book. (I think from December 2020.)


Ali

Re: On the D Blog -- Teaching D from Scratch: Is it a viable first language?

[Ali Çehreli via Digitalmars-d-announce]

On 12/23/21 5:11 PM, zjh wrote:

On Thursday, 23 December 2021 at 14:48:43 UTC, zjh wrote:


every time I visit `https://dlang.org`,it crashes.


`wrong`,`https://dlang.org/blog`.



Does the site crash e.g. with an error code or does the browser crash? 
More information may help debug it.


Ali

Re: DConf Online 2021 Links

[Ali Çehreli via Digitalmars-d-announce]

On 11/19/21 2:10 AM, Mike Parker wrote:


See you there!


Reminder: DConf Online 2021 is on now.

Ali

Re: D Language Foundation Quarterly Meeting, October 2021

[Ali Çehreli via Digitalmars-d-announce]

Thank you, Mike. I love these digests.

On 11/5/21 4:57 AM, Mike Parker wrote:

> One of the things
> [Petar Kirov] would like to do is use DLang Tour to make all of the 
examples in

> Ali's book runnable.

(That discussion must have happened when I had to leave to for another 
meeting.)


Interesting... Perhaps I can link from the chapters like "run this code 
on DLang Tour."


> For example, a `RangeError` on an invalid array index should
> report what the number was that caused the problem; failed asserts
> should report the offending expression; etc.

There is great progress there already:

auto foo(int[] arr) {
  return arr[42];
}

void main() {
  foo([1, 2]);
}

core.exception.ArrayIndexError@deneme.d(1755): index [42] exceeds array 
of length 2


Awesome! :)

> ### The fate of `-preview=in`

> Martin, Petar, and Ali voiced strong support for the feature. Some of
> their arguments in favor:

Another argument was "intent". As in, the programmer means "this is an 
input to this function" and the compiler does the rest. Today, both of 
the following are input parameters:


void foo(ref const(Foo) a) {}
void foo(Foo a) {}

But wait... the latter may not be an input because it may be a struct 
that has indirections that I may modify through?


How about the following "input" parameter:

void foo(const(Foo) a) {}

That 'const' has no meaning and no place there if Foo is purely a value 
type (e.g. int). Why should the knowledge of the implementation's not 
modifying that copy leak out to the interface?


I think all of that can be fixed with in(tent). ;)

void foo(in Foo a) {}

Done. In other words, dear compiler, you deal with it! :)

> `-preview=in` will not be killed. It needs to be changed such that:

Yay!

Ali

Re: On the Blog: DLang News for September/October 2021

[Ali Çehreli via Digitalmars-d-announce]

On 10/31/21 12:26 PM, Mike Parker wrote:


The video version is done and is available here:

https://youtu.be/jX9grHMTGAU



WOW! That's amazing! :)

Ali

Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)

[Ali Çehreli via Digitalmars-d-announce]

On 10/3/21 2:24 PM, James Blachly wrote:

> Cons: Potential association with silicon valley phrase "move fast and
> break things".

I am going off-topic but I feel I have to make a correction there.

As a person who worked and lived in Silicon Valley since 1996 (since 
1994 in the greater Bay Area), I can safely claim that that phrase has 
never been a Silicon Valley phrase. It was used by Facebook in their 
less enlightened days (a business that may arguably be associated with 
Silicon Valley by their postal address).


Ali

Re: Bugzilla Reward System

[Ali Çehreli via Digitalmars-d-announce]

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.

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


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


Ali

Re: SAOC 2021 Projects Summarized

[Ali Çehreli via Digitalmars-d-announce]

On 8/30/21 5:47 AM, Mike Parker wrote:

> Ahmet Sait KoC’ak

Being a fellow Turkish, I am curios why his last name is spelled that 
way. Unless it was sepecially requested by him, I would use the 
following obviously correct spelling:


 Ahmet Sait Koçak

Ali

Re: dmdtags 1.0.0: an accurate tag generator for D source code

[Ali Çehreli via Digitalmars-d-announce]

On 8/27/21 2:38 PM, Paul Backus wrote:

> `dmdtags` is a tags file generator for D source code that uses the DMD
> compiler frontend for accurate parsing.

Thanks! I had stopped using tags files with Emacs for the reasons you 
give. With this, I will be more efficient. :)


And, I will be a happy puppy once Vladimir Panteleev finishes his D mode 
for Emacs, which he is writing from scratch.


Ali

Re: D Language Foundation Quarterly Meeting Summary -- July 23, 2021

[Ali Çehreli via Digitalmars-d-announce]

On 7/28/21 4:34 PM, zjh wrote:

On Wednesday, 28 July 2021 at 16:46:49 UTC, Ali Çehreli wrote:

On 7/28/21 12:07 AM, zjh wrote:

On Wednesday, 28 July 2021 at 06:37:56 UTC, Mike Parker wrote:



Impressive! :) Is that abbreviated or all of it?

Ali



I translated it directly without asking you for permission . I'm sorry.
All.



No permission required. Here is the license:

  https://creativecommons.org/licenses/by-nc-sa/3.0/us/

Thank you for *not* involving me. :)

Ali

Re: D Language Foundation Quarterly Meeting Summary -- July 23, 2021

[Ali Çehreli via Digitalmars-d-announce]

On 7/28/21 12:07 AM, zjh wrote:

On Wednesday, 28 July 2021 at 06:37:56 UTC, Mike Parker wrote:

### Background



I have translated `Programming in D` in chinese. Here [用d编程] 
(https://fqbqrr.blog.csdn.net/article/details/104605383)




Impressive! :) Is that abbreviated or all of it?

Ali

Re: "Let's Learn D Programming Game Dev!" by Ki Rill on YouTube

[Ali Çehreli via Digitalmars-d-announce]

On 6/16/21 2:03 PM, Ali Çehreli wrote:
This was mentioned in an earlier post but I don't remember seeing a 
separate announcement.


   https://www.youtube.com/playlist?list=PLgM-lc_kSqFQPF0UXgmFZpZalqcrSofe-

Ali


In case your client does not include the last '-' in the URL, here is 
another attempt:





Ali

"Let's Learn D Programming Game Dev!" by Ki Rill on YouTube

[Ali Çehreli via Digitalmars-d-announce]

This was mentioned in an earlier post but I don't remember seeing a 
separate announcement.


  https://www.youtube.com/playlist?list=PLgM-lc_kSqFQPF0UXgmFZpZalqcrSofe-

Ali

Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand

[Ali Çehreli via Digitalmars-d-announce]

On 6/16/21 9:15 AM, Tejas wrote:

On Wednesday, 16 June 2021 at 15:48:07 UTC, Vladimir Panteleev wrote:
Replying for the benefit of forum.dlang.org users, for whom the tags 
were not visible due to Markdown.


Thank you so much :D
Also, what other ways exist to visit this news group?




I follow with Thunderbird but any other NNTP client should work:

Server: www.digitalmars.com
Port: 119

The groups I follow:

Name: digitalmars.D
Location: news://www.digitalmars.com:119/digitalmars.D

Name: digitalmars.D.announce
Location: news://www.digitalmars.com:119/digitalmars.D.announce

Name: digitalmars.D.learn
Location: news://www.digitalmars.com:119/digitalmars.D.learn

Name: digitalmars.D.turkish.duyuru
Location: news://www.digitalmars.com:119/digitalmars.D.turkish.duyuru

Name: digitalmars.D.turkish.genel
Location: news://www.digitalmars.com:119/digitalmars.D.turkish.genel

Ali

Re: From the D Blog -- Interfacing D with C: Strings Part One

[Ali Çehreli via Digitalmars-d-announce]

On 5/25/21 9:00 PM, Виталий Фадеев wrote:

>  immutable(char)* toStringz( ref string s )
>  {
>  if ( s.capacity <= s.length )
>  s.reserve( s.length + 1 );
>
>  char* cptr = cast( char* ) s.ptr; // C ptr
>  char* zptr = cptr + s.length; // zero ptr
>  *zptr = '\0';

That's undefined behavior because that location does not belong to the 
string. Here is an example that defeats the proposed toStringz:


void main()
{
string s;
s = "D string";

auto c_string = toStringz( s );

auto other = s;
other ~= 'X';// <-- Seemingly unrelated operation

// ...
}

puts accesses that unrelated 'X' and more bytes after that:

  C string: D stringX1^


Ali

Re: Silicon Valley D Meetup - May 20, 2021 - "IPC with DLang using pipes and shared memory on Linux"

[Ali Çehreli via Digitalmars-d-announce]

On 5/20/21 9:36 AM, Gavin Ray wrote:

>> [1] https://www.meetup.com/D-Lang-Silicon-Valley/events/kmqcvqycchbbc/
>
> Hey Ali, as a courtesy wanted to say I have planned on coming tonight =)

Thanks for letting me know. Looking forward to meeting you (and others! 
;) ).


Ali

Silicon Valley D Meetup - May 20, 2021 - "IPC with DLang using pipes and shared memory on Linux"

[Ali Çehreli via Digitalmars-d-announce]

Zoom link:

  https://us04web.zoom.us/j/2248614462?pwd=VTl4OXNjVHNhUTJibms2NlVFS3lWZz09

May 20, 2021
Thursday
19:00 Pacific Time

We will look at some experimental code written to transmit data between 
two processes on Linux.


- std.process.pipeProcess for communication

- std.mmfile.MmFile for transferring large payloads

- A simple protocol between processes

A polished version of this code ended up being used in production.

This will be an informal code walk-through as an anchoring point, which 
is expected to start conversations. (This will not be a "presentation 
with slides".)


This meetup[1] will not be recorded.

Ali

[1] https://www.meetup.com/D-Lang-Silicon-Valley/events/kmqcvqycchbbc/

Re: Destroy All Memory Corruption

[Ali Çehreli via Digitalmars-d-announce]

On 4/22/21 8:35 AM, angel wrote:

> MS Teams works fine on Linux.

I failed after spending 35 minutes for that. I ended up creating at 
least two accounts (even though I already had a Skype account, which 
sounded to be sufficient). Many special codes sent to my phone and 
email. The whole thing is badly designed and felt buggy.


In the end, contrary to how the download started for "my platform" 
(Linux Mint) it said at some point that MS Teams was not available for 
my platform. (There is an MS Teams program on my system which starts 
fine but thinks I am not signed in. (?)) So I decided to use it in the 
browser, which turned out not working with Firefox. Luckily I had Chrome 
and it worked.


> And I'm actually not sure you would need an MS account

It requires one. I could not find a way through their flow to use my 
existing Skype account.


Ali

Re: Destroy All Memory Corruption

[Ali Çehreli via Digitalmars-d-announce]

On 4/19/21 6:12 PM, Walter Bright wrote:
I'll be doing a reprise of my DConf 2020 talk on Destroy All Memory 
Corruption on April 21, 2021 at 7PM PST.


https://nwcpp.org/

Except this time it'll be live, not prerecorded.

All are welcome!


This is happening in half an hour. It requires MS Teams, which requires 
a MS (or Skype) account.


Ali

Re: Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"

[Ali Çehreli via Digitalmars-d-announce]

On 4/17/21 10:14 AM, Gavin Ray wrote:

>> [1] https://www.meetup.com/D-Lang-Silicon-Valley/events/kmqcvqyccgbtb/
>
> Ali are these recorded by chance?

We've recorded only a couple of these meetups years ago when we had 
presentation-style meetups.


Although we could record these meetings, this and the last one were so 
unstructured that I don't think it's worth recording. On the other hand, 
I understand how they would still be valuable. Still, being on the 
record would take away the candidness of these "local" meetings by a 
small number of individuals.


> Now that I know will try to make it next month

I apologize for not giving advance notice but I really couldn't. :) This 
is how it happened: I attended the Silicon Valley C++ meetup where Sean 
Baxter presented Circle, his very powerful language based on C++:


  https://github.com/seanbaxter/circle

It turns out, Circle is full of compile-time magic that we already enjoy 
with D: proper compile time function execution, the equivalents of 
'static if' that can inject declarations, 'static foreach' that can 
inject case clauses, etc. etc.


There was so much overlap between D features and Circle that I came up 
about my meetup topic during that C++ meetup and announced it at the end 
of it. As always, I hoped that CTFE would just be the main theme and we 
would talk about other compile-time features of D.


To my surprise, such a short-notice brought just one participant and 
that was Sean Baxter himself! How fortunate I was! :) He said he had 
never heard of D before and was nodding his head to most D features that 
I showed. There was strong agreement with D's 'static if' (and Circle's 
equivalent feature).


One big difference between D and Circle, and one that he heard many 
concerns about is the fact that Circle allows file I/O at compile time. 
Other than the import expression, D does not.


I heard about safety issues around allowing full I/O during compilation 
but then the following points kind of convinced me:


- If I am compiling a program, my goal is to execute that program 
anyway. What difference does it make whether the program's compilation 
is harmful vs. the program itself.


- If we don't allow file I/O during compilation, then the build system 
has to take that responsibility and can do the potential harm then anyway.


Related, the following code fails with an unfriendly error message with dmd:

int foo() {
  import std.stdio;
  auto file = File("some_file");
  return 42;
}

pragma(msg, foo());

/usr/include/dmd/phobos/std/stdio.d(4352): Error: `fopen64` cannot be 
interpreted at compile time, because it has no available source code
/usr/include/dmd/phobos/std/stdio.d(392): Error: `malloc` cannot be 
interpreted at compile time, because it has no available source code


Sean thought this should be easy to fix. Well, we have to allow it to 
begin with I guess.


Anyway, that's my short summary. :)

Ali

Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"

[Ali Çehreli via Digitalmars-d-announce]

We will talk about compile time function execution (CTFE).

Although this is announced on Meetup[1] as well, you can connect directly at

  https://us04web.zoom.us/j/2248614462?pwd=VTl4OXNjVHNhUTJibms2NlVFS3lWZz09

April 15, 2021
Thursday
19:00 Pacific Time

Ali

[1] https://www.meetup.com/D-Lang-Silicon-Valley/events/kmqcvqyccgbtb/

Re: Silicon Valley D Meetup - March 18, 2021 - "Templates in the D Programming Language" by Ali Çehreli

[Ali Çehreli via Digitalmars-d-announce]

On 3/19/21 2:45 AM, data pulverizer wrote:

> I have to say that I got an enormous amount out of it!

Thank you for attending and steering the discussion to interesting 
places. It turned out to be much different from a "beginner-friendly" 
presentation. :)


It was interesting to understand some code by Andrei:


https://gist.github.com/andralex/0d85df38be2d9ffbe89cf1fb51c44213#file-reify-d-L164

It was interesting to realize that the selected line above can be an 
example of a use case for nested templates. Instead of the following 
line where the first template parameter is implicitly the "needle" and 
the rest are the "haystack"


  static assert(staticIndexOf!( byte, byte, short, int, long) ==  0);

we can use nested templates to have more readable code:

  static assert(staticIndexOf!byte.among!(byte, short, int, long) ==  0);

(Assuming 'among' is a nested template inside 'staticIndexOf'.)

> I feel energised for what I learned.

It is too nerdy to say but I could not go to sleep easily due to some 
adrenaline rush! Ha ha! :D


> There was one other person who made a useful comment that
> helped my understanding whose name I don't recall - thank you
> too.

That must be Jon Degenhardt. Jon mentioned how PR 7678 reduced the 
performance of std.regex.matchOnce. After analyzing the code we realized 
that the performance loss must be due to two delegate context allocations:



https://github.com/dlang/phobos/pull/7678/files#diff-269abc020de3a951eaaa5b8eca5a0700ba8b298767c7a64f459e74e1531a80aeR825

One delegate is 'matchOnceImp' and the other one is the anonymous 
delegate created on the return expression.


We understood that 'matchOnceImp' could not be a nested function because 
of an otherwise useful rule: the name of the nested function alone would 
*call* that function instead of being a symbol for it. That is not the 
case for a local delegate variable, so that's why 'matchOnceImp' exists 
as a delegate variable there.


Then there is the addition of the 'pure' attribute to it. Fine...

After tinkering with the code, we realized that the same effect can be 
achieved with a static member function of a static struct, which would 
not allocate any delegate context. I add @nogc to the following code to 
prove that point. The following code is even simpler than Jon and I came 
up with yesterday.


void foo(ref int i) pure @nogc @safe {
  // Another local variable that will be used by the static
  // function of the static struct
  double d = 0.0;

  /* Instead of a lambda variable like this:

 auto bar = () @trusted {
   // ...
 };

 We use a static member function of a static struct:
   */
  static struct S {
static auto bar(ref int j, double e) pure @trusted @nogc {
  // Doing something unsafe inside this trusted function
  *(cast(int*)cast(long*)) += 42 + e;

  // Totally unrelated: It is a shame that the 'double'
  // expression on the right-hand side is added to an 'int'
  // on the left-hand side but we know that. :/
}
  }

  // Pass needed variables instead of using them from a delegate
  // context
  return ()(i, d);

  /* The following more convoluted method works as well but seems
   * unnecessary:

  alias T = typeof();
  enum attrs = functionAttributes!T | FunctionAttribute.pure_ ;

  return (() @trusted @nogc => (cast(SetFunctionAttributes!(T,
  functionLinkage!T, attrs)) ))()(i, d);
  */
}

void main() {
  int i = 0;
  foo(i);
  assert(i == 42);
}

There: we injected @trusted code inside a @nogc @safe function.

Question to others: Did we understand the reason for the convoluted code 
in that PR fully? Is the above method really a better solution?


Ali

Re: Silicon Valley D Meetup - March 18, 2021 - "Templates in the D Programming Language" by Ali Çehreli

[Ali Çehreli via Digitalmars-d-announce]

On 3/18/21 6:34 AM, matheus wrote:

> But another reason that I pointed youtube
> re-transmission, is that at least where I live this service has no
> "buffering" for live streaming, while other services use to be pretty
> bad in this regard.

Understood.

Mike Parker contacted me about potentially recording this as well but 
unfortunately, there is no structure at all and I can't come up with 
anything that is worth recording in a few hours now. Let's skip this 
occasion and I promise I will put some slides and a recording later.


So, this meeting will be more like a chat anchored on templates.

Ali

Re: Silicon Valley D Meetup - March 18, 2021 - "Templates in the D Programming Language" by Ali Çehreli

[Ali Çehreli via Digitalmars-d-announce]

On 3/17/21 8:07 PM, matheus wrote:

> Is there a way to have a Youtube re-transmission live too? -
> Unfortunately I can't access this site, and I am interested in this talk.
>
> Matheus.

This will be as informal as meetups get: There aren't even slides 
(yet?). :) Would jitsi work for you? If so, we may decide to move over 
there and I would post the meeting link and the password here at 18:55 
Pacific Time, as Iain does for BeerConf.


Ali

Silicon Valley D Meetup - March 18, 2021 - "Templates in the D Programming Language" by Ali Çehreli

[Ali Çehreli via Digitalmars-d-announce]

I will explain templates in a beginner-friendly way.

Although this is announced on Meetup[1] as well, you can connect directly at

  https://us04web.zoom.us/j/2248614462?pwd=VTl4OXNjVHNhUTJibms2NlVFS3lWZz09

March 18, 2021
Thursday
19:00 Pacific Time

Ali

[1] https://www.meetup.com/D-Lang-Silicon-Valley/events/kmqcvqyccfbxb/

Re: Beerconf February 2021

[Ali Çehreli via Digitalmars-d-announce]

On 2/26/21 6:55 AM, Steven Schveighoffer wrote:

> A reminder to everyone

Thank you very much for all who is involved organizing Beerconf.

> this is happening starting tomorrow.

Whose tomorrow? :) For some reason I need exact times for this. Is it 
all weekend hours anywhere on the world or specific UTC times?


Ali

Re: Beerconf February 2021

[Ali Çehreli via Digitalmars-d-announce]

On 2/13/21 7:49 PM, Steven Schveighoffer wrote:

ancient version of firefox.
I don't think my Firefox is ancient but I still can't use it for 
Beerconf. Google Chrome works for me.


Ali

Re: Printing shortest decimal form of floating point number with Mir

[Ali Çehreli via Digitalmars-d-announce]

On 12/23/20 10:05 AM, 9il wrote:

> It was a mockery executed by Atila

For those who read the above comment but do not want to read the rest of 
this long thread, the linked PR discussion does not contain mockery:


> https://github.com/dlang/dmd/pull/9778#issuecomment-498700369

Ali

Victor Porton's book "D, the Best Programming Language, for Former Python Developers"

[Ali Çehreli via Digitalmars-d-announce]

I've come across the book on D Wiki Books. Amazon link:


https://www.amazon.com/Programming-Language-Former-Python-Developers/dp/B08M83X6N8

Ali

Re: Our community seems to have grown, so many people are joining the Facebook group

[Ali Çehreli via Digitalmars-d-announce]

On 12/28/20 9:31 AM, Murilo wrote:

> they thought a Facebook group was unnecessary,

Not only unnecessary but divisive as well. For example, because I will 
never have a Facebook account I would never be a part of that group. So, 
can the open source community be a part of Facebook groups *without* a 
Facebook account? Even if the groups would be open to the public, why 
would advertisements be a part of a D group? (I don't want to go more 
off-topic here but I would love to discuss Facebook over your favorite 
drink.)


> but what is the biggest social media in the world? Facebook!

Good for them. :)

Ali

Turkish newsgroups are on forum.dlang.org

[Ali Çehreli via Digitalmars-d-announce]

The old Turkish forums at ddili.org are retired. Thanks to Walter 
Bright, Vladimir Panteleev, and Jan Knepper, we are now on 
forum.dlang.org alongside the English newsgroups.


As a reminder, all newsgroups ("forums") can be accessed by a program 
that supports NNTP (Thunderbird, Outlook, etc.) as well:


  Server: www.digitalmars.com
  Port: 119

Future work:

- Post old Turkish threads after converting from BBCode to Markdown

- Localize the forum interface

Ali

Conor Hoekstra's upcoming presentation (may) mentions D

[Ali Çehreli via Digitalmars-d-announce]

Conor is a friend from the Silicon Valley C++ (and D) meetups. A friend 
showed me the following tweet of his:


  https://twitter.com/code_report/status/1324816311105540100?s=11

Ali

Re: DConf Online 2020 Schedule

[Ali Çehreli via Digitalmars-d-announce]

On 10/14/20 6:25 PM, Andrej Mitrovic wrote:

> The D Language Foundation is very pleased to announce that DConf Online
> 2020 (not DConf 2020 Online!) is taking place November 21 and 22, 2020.
>
> What exactly is the difference between the naming?

This one is not the online version of DConf that has been canceled this 
year. We will have two conferences from now on:


 - May (June?): DConf
 - November: DConf Online

Ali

Re: DConf Online 2020 Schedule

[Ali Çehreli via Digitalmars-d-announce]

On 10/14/20 7:07 AM, Ezneh wrote:

> "Parallelism, message passing concurrency, nested functions, […]"
> -> Missing a comma between 'message passing' and 'concurrency'?

It should be "message-passing concurrency" but it's fine with the comma 
as well.


Ali

Re: DConf Online 2020...

[Ali Çehreli via Digitalmars-d-announce]

On 10/3/20 4:12 PM, Walter Bright wrote:

What's the hashtag? #dconf2020 ?


Me not know hashtag but Mike has been saying that this is not a DConf 
but a "DConf Online". Two different yearly events... :)


Ali

Re: DConf Online 2020 Submission Deadline Extended

[Ali Çehreli via Digitalmars-d-announce]

On 9/4/20 9:01 PM, Mike Parker wrote:

I've gotten one more submission. We'll need more than that. Let's go, 
folks!


I have a couple of ideas as well but this virus has changed not only 
routines but motivation as well. I am so much behind on so many things. :/


Luckily, there is still a lot of time... hours even... :o)

Ali

Re: Reading IDX Files in D, an introduction to compile time programming

[Ali Çehreli via Digitalmars-d-announce]

On 8/21/20 1:33 PM, H. S. Teoh wrote:

> On Fri, Aug 21, 2020 at 01:18:30PM -0700, Ali Çehreli via 
Digitalmars-d-announce wrote:


> Generally, I don't expect directory traversal to ever be
> allowed at compile-time, since it opens the door to a huge can o'
> security worms. :-P

I've heard that before. So, if directory traversal is only for import 
expressions then it should be fine because importing two files cannot be 
less safe than importing one file. So, we need to let the compiler know 
that we will import, nothing fancy:


  // Mapping from file name -> content
  string[string] contents = static import("my/dir");

Note the clever :o) use of 'static' which means "directory" in this 
case. :o) Now we have all contents as an AA, ready to be parsed, 
mixed-in, etc. But I this is not important at all. Build step is just fine.


Ali

Re: Reading IDX Files in D, an introduction to compile time programming

[Ali Çehreli via Digitalmars-d-announce]

On 8/21/20 8:04 AM, data pulverizer wrote:
I have written an article targeted at people new to D on compile-time 
programming: 
https://www.active-analytics.com/blog/reading-idx-files-in-d/ and 
tweeted it here: 
https://twitter.com/chibisi/status/1296824381088440320?s=20


Comments welcome.

Thanks in advance.


Great article. (There are other typos in there; I would be happy to 
review your next articles. :) )


I use "import expressions" for parsing files at compile time as well but 
your article gave me some ideas where I may be able to parse types of 
fields very similar to your example.


In my case I found a limitation: I cannot "iterate a directory" and 
import all file contents in there (the limitation is related to a C 
library function not having source code so it cannot be evaluated). So, 
I use a build step to generate the file that contains all files in my 
directory. So, I first import the file list then 'static foreach' that 
list to import and parse contents of other files.


For the record, here is an example of code that does not work at compile 
time:


import std.file;

void main() {
  static foreach (entry; dirEntries(".", SpanMode.shallow)) {
  }
}

Error: `fakePureCalloc` cannot be interpreted at compile time, because 
it has no available source code


(I think the error message is different in dmd 2.084 where my project 
currently uses.)


Ali

Re: The ABC's of Templates in D

[Ali Çehreli via Digitalmars-d-announce]

On 7/31/20 6:46 AM, Mike Parker wrote:


The blog:
https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/


An excellent article and the ideas are delivered expertly, in a very 
natural way.


And there are almost no typos. ;)

comfusing ->
confusing

a normal a function ->
a normal function

declare first declare ->
first declare

implemnted ->
implemented

Ali

Re: tsv-utils 2.0 release: Named field support

[Ali Çehreli via Digitalmars-d-announce]

On 7/27/20 7:32 AM, aberba wrote:

> Goes to show most of us will do just fine with GC code. Our job is to
> learn how to use it well.

Exactly. My programs sometimes run for minutes on dozens of gigabytes of 
files. Compared to that, the number of and the total time spent for 
garbage collections is comically low.[1]


Ali

[1] Michael Parker shows how to profile the GC here:

  https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

Spoiler: It's as simple as passing the --DRT-gcopt=profile:1 command 
line option to any compiled program.

Re: Article: the feature that makes D my favorite programming language

[Ali Çehreli via Digitalmars-d-announce]

On 7/25/20 7:47 AM, aberba wrote:
> On Saturday, 25 July 2020 at 13:28:34 UTC, Adam D. Ruppe wrote:
>> oh I hate it when people do that though, it just looks off to me at
>> that point.
>
> Ha ha. If you're writing idiomatic D code, why not not all in on it?

I agree with Adam and others on this. My reasoning is, writeln's first 
parameter is not special compared to its other parameters. In other 
words, I can't see writeln as a special operation on its first argument. 
Except, when there is just one thing... Meh... I don't like it. :)


Ali

Re: From the D Blog: A Pattern for Head-mutable Structures

[Ali Çehreli via Digitalmars-d-announce]

On 6/26/20 2:30 AM, aberba wrote:

> I'm curious what's happening in those D meetups. Are they still
> happening (online)?

Our Silicon Valley meetups are still going on:

  https://www.meetup.com/D-Lang-Silicon-Valley/events/kmqcvqybcjbxb/

However, without dedicated effort to line up speakers, it dwindled to a 
social gathering of very few people.


Ali

Re: Talk by Herb Sutter: Bridge to NewThingia

[Ali Çehreli via Digitalmars-d-announce]

On 6/29/20 8:45 AM, Dagmar wrote:

> I am a C++ developer.

I used to be a C++ developer; luckily, I primarily write in D these 
days. (I can still code in C++ and will have to do so again soon.)


> I do want to move to a modern language, but there
> is no one that fits my needs.
[...]
> Go is just an oversimplified language. No generics/teplates in 2020,
> seriously?

+1 And it's fascinating how they sold all the shortcomings as benefits. 
Amazing!


> D has a GC.

Coming from C++, I was a die-hard "deterministic destruction" guy and it 
took me a long time to embrace GC. Now I know GC is pure help. GC is no 
more issue than any other engineering decisions.


> If you turn it off you lose dynamic/associative arrays,
> classes, probably something else.

Then don't turn it off. :)

I understand there are programs where an undeterministic delay in 
processing is unacceptable but those programs all run on real-time 
operating systems anyway, right? ;)


> Why would I even want to use such
> language at all?

For practicality. For getting things done.

> It's much easier to stay with C++ this way, since it
> has lots of C/C++ libraries, IDEs, tools, broad community, support of
> big companies.

It requires a strong C++ mindset to take GC as a liability and accept 
C++ complexities like the following one as manageable:


OOPS: :) I fail to find a reference table that explains implicitly or 
explicitly deleted or defaulted fundamental C++ operations like the copy 
constructor.


Yeah, accepting that kind of complexity but rejecting the GC is 
interesting. (I am not directing this to you but to most C++ programmers.)


> Of course, since D doesn't look like a mature language. I've been
> following it for many years and it doesn't really improve. It looks just
> like a bunch of different things/concepts put together.

That may be true for many languages but when it comes to getting things 
done I find D much more productive, manageable, easier, etc. etc. 
compared to C++. C++ has only one thing over D: Many smart people are 
already using C++.


> Many things are
> stalled without of any progress because there is no consensus.
> The entire DIP process is not good. There is no way to find the current
> DIP status, no way to learn when and whether it's going to be
> implemented or not. Have you noticed such questions in the forum 
recently?

> The current status of the language is unclear. Sometimes there is only
> one way to find out why it behaves like it does: to ask in this forum.
> And you may not like the answers.

> D has transitive const, but what if I
> should lazy evaluate/cache a value or use a mutex?

Although I agree that transitive const is the correct feature, I too 
find it difficult.


> If I shouldn't use
> const, how should I emphasize the intention to pass a pointer only for
> reading? How can I be sure that my class invariant is not compromised?
> Also, there is the shared attribute, but it isn't designed nor
> implemented well. Lots of questions, no solutions. D is intended to be a
> C++ replacement, but it doesn't explain to C++ programmers how to change
> their way of thinking.

There is this dated document:

  https://dlang.org/articles/cpptod.html

Although dated, that document should be sufficient to jump to D from C++. :)

> Maintainers don't like to make breaking changes when they are required.
> Come on guys, it's called an evolution.

Interestingly, one of the criticism D gets is how it evolves with 
breaking changes. :)


> That's why C++ is so
> overcomplicated right now. It tries to keep backward compatibility at
> all costs. I hope you don't want D to get into the same situation? Any
> modern language requires a chance to evolve. Sometimes you just have to
> break something. And making it once in a year (or 2-3 years) doesn't
> look like a bad option to me.

I agree.

Ali

Re: DIP 1028 "Make @safe the Default" is dead

[Ali Çehreli via Digitalmars-d-announce]

On 5/28/20 9:53 PM, Walter Bright wrote:

The subject says it all.

If you care about memory safety, I recommending adding `safe:` as the 
first line in all your project modules, and annotate individual 
functions otherwise as necessary. For modules with C declarations, do as 
you think best.


For everyone else, carry on as before.


Thank you! Which meme did it? :o)

Ali

Re: "Programming in D" on Educative.io

[Ali Çehreli via Digitalmars-d-announce]

On 5/13/20 12:25 PM, welkam wrote:

On Thursday, 7 May 2020 at 09:18:04 UTC, Ali Çehreli wrote:

Because D is a re-engineering of C++


I thought it was re-engineering of C


Thanks. I will have it fixed.

Ali

Re: "Programming in D" on Educative.io

[Ali Çehreli via Digitalmars-d-announce]

On 5/7/20 5:53 AM, M.M. wrote:> On Thursday, 7 May 2020 at 09:18:04 UTC, 
Ali Çehreli wrote:


> Nice initiative with the online course. I will have a look soon; I am
> thinking of introducing D to my university students...

It's always exciting to see D used in teaching! :) Alex Ortiz, my 
contact at Educative.io, has student discounts. He say:



Please have them reach out if they'd like to use this course as part of 
the curriculum.


Maybe those students can avail themselves of Educative-related 
resources. We're part of the GitHub Student Education
Pack , through which college students 
can avail themselves of a free 6-month subscription to our courses. We 
also sometimes have special scholarships in place on our side. Finally, 
we can offer university students specifically of your course a 
discounted rate or somesuch.


In any case, the professor can in the future email *supp...@educative.io 
*, explain that they're a
professor who wants to use your course(s) in their university 
curriculum, and ask what we have in place to help their

students.



Ali

Re: "Programming in D" on Educative.io

[Ali Çehreli via Digitalmars-d-announce]

On 5/12/20 3:05 AM, Pavel Shkadzko wrote:

On Thursday, 7 May 2020 at 09:18:04 UTC, Ali Çehreli wrote:
I'm happy to announce that the first part of "Programming in D" is 
available on Educative.io:


[...]


This is great! Finally, a D course. It is a shorter than "Programming in 
D" book version though. But for the introductory course I think it's fine.


Educative.io decided to provide the book in two parts. They are still 
working on the second part.


Ali

"Programming in D" on Educative.io

[Ali Çehreli via Digitalmars-d-announce]

I'm happy to announce that the first part of "Programming in D" is 
available on Educative.io:


  https://www.educative.io/courses/programming-in-d-ultimate-guide

(They will offer the second half later as a separate course.)

Educative.io offers interactive courses, mostly on technology and 
programming topics and they are looking for more D authors:


  https://www.educative.io/authors

I hope you will find the platform easy to work with and port your 
existing texts there or write new material. They added a D compiler to 
their platform for this book; so you're good to go. :)


This was the first professional editing of the book where *everything* 
was handled by their team. (So don't blame me e.g. if you don't like the 
book's subtitle. ;) ) They took my content and ported to their platform, 
which allows the reader to edit and compile code samples. There are some 
added quizes as well.


It is a paid course but as a reminder, the book will always be free as well:

  http://ddili.org/

And I am grateful to Educative.io for understanding that some books want 
to be free. In fact, they told me that books that are also available for 
free do sell more. Yay! :)


Ali

Re: dmdcache

[Ali Çehreli via Digitalmars-d-announce]

On 4/25/20 5:30 AM, John Colvin wrote:

> how does this differ from just using make?

make is great and I love it (really) but it works at a coarser level. 
There is no way for it to know that a particular command will produce 
the same output.


As I understand it, dmdcache is supposed to be similar to ccache, which 
we already use with make to speed up our C++ compilations:


  https://ccache.dev/

Ali

Re: dmdcache

[Ali Çehreli via Digitalmars-d-announce]

On 4/25/20 9:01 AM, bauss wrote:

> On Saturday, 25 April 2020 at 10:35:49 UTC, Stefan Koch wrote:

>> The main problem with this is that it does not take string imports
>> into account

[...]

> Yeah, doesn't look like it which means it might not be useful in
> projects that does a lot of compile-time stuff.
>
> There is no way to determine the import statements either as those
> themselves can be generated at compile-time.

Luckily, dmd gives all of that information with both -v and -X command 
line switches.


However, currently dmdcache doesn't seem to look for string imports; 
opportunity for improvement. :)


Ali

Re: dmdcache

[Ali Çehreli via Digitalmars-d-announce]

On 4/25/20 4:39 AM, Johan wrote:

On Saturday, 25 April 2020 at 10:17:50 UTC, Ali Çehreli wrote:
A colleague of mine has written dmdcache which may be very useful for 
some projects:


  https://github.com/seeraven/dmdcache

It drops our build time

  from 8 minutes
  to 45 seconds


Hey Ali,
   Did you also try with LDC's built-in object file caching (asm codegen 
caching) ?


Cheers,
   Johan



That sounds very promising. Time to introduce ldc to the project.

Ali

dmdcache

[Ali Çehreli via Digitalmars-d-announce]

A colleague of mine has written dmdcache which may be very useful for 
some projects:


  https://github.com/seeraven/dmdcache

It drops our build time

  from 8 minutes
  to 45 seconds

on a particular build environment for about half a dozen D programs, one 
of which ends up being a 2G executable! WAT! :) And the total cache size 
is 5.5G. Wow!


This build is with dmd 2.084.1 and that one particular application uses 
tons of template instantiations most of which are in generated source 
code. If I remember correctly, 2.084.1 does not contain template symbol 
name improvements and that may be the reason for the large size.


Enjoy!

Ali

Re: DConf 2020 Canceled

[Ali Çehreli via Digitalmars-d-announce]

On 3/7/20 1:58 PM, Adam D. Ruppe wrote:
Let's do a little online thing instead! We could do a chat room, 
livestream, blog, you know stuff like that.


That's what I been thinking as well. It looks like we are forced into 
trying out a live conference this year.


Ali

Re: Blog post on calling C from Python via D

[Ali Çehreli via Digitalmars-d-announce]

On 2/26/20 6:51 AM, Atila Neves wrote:


My followup:

https://atilaoncode.blog/2020/02/26/seriously-just-use-d-to-call-c-from-python/ 



Could someone please post this on Reddit and Hacker News. Thanks...

Ali

Re: Blog post on calling C from Python via D

[Ali Çehreli via Digitalmars-d-announce]

On 2/19/20 8:30 AM, Atila Neves wrote:


https://news.ycombinator.com/item?id=22365166



Awesome!

And thanks for linking directly to the article on ycombinator. If 
they're still penalizing articles for direct links, they should realize 
already that links are a thing on the internet.


Ali

DConf 2019 Pictures

[Ali Çehreli via Digitalmars-d-announce]

This one is Laeeth introducing Andrei at Symmetry Investments:

  http://acehreli.org/photo/dconf_2019/DSC04839.html

Ali

Re: When will you announce DConf 2020?

[Ali Çehreli via Digitalmars-d-announce]

On 11/06/2019 11:20 AM, bachmeier wrote:

> While I encourage you to submit a talk,

I encourage everyone to submit a proposal.

> I'll point out that there were
> only six regular talks per day this year, and a lot of those were core
> contributors

A major part of that outcome was the low number of total proposals. The 
core contributors and others kind of chipped in to save the day. We want 
tons of proposals.


Ali

Re: Silicon Valley C++ Meetup - August 28, 2019 - "C++ vs D: Let the Battle Commence"

[Ali Çehreli via Digitalmars-d-announce]

On 09/02/2019 01:06 AM, a11e99z wrote:

>> I'm not talking about your pronunciation

I understand. I was trying to be funny with an additional failure report.

>> No subtitles for 3 parts currently set - 1,2,4.

I don't think I can do anything else because I did select English for 
all of them.


Ali