November 25, 2021

On Wednesday, 24 November 2021 at 10:40:39 UTC, IGotD- wrote:

>

On Wednesday, 24 November 2021 at 10:23:22 UTC, Gleb wrote:

>

There are no full-fledged signals --- slots with the ability to exchange
data between threads (in the style of Qt) => whole familiar sections
immediately drop out.

D has a native message system between threads. Qt signals is a special case as it also can be used in the same thread and then it is just a function call. Also there are syntax sugar for declaring Qt signals in C++.

I don't know any language that natively implements signals as Qt does.

Delphi and .NET events.

November 25, 2021

On Wednesday, 24 November 2021 at 14:13:35 UTC, Per Nordlöw wrote:

>

On Wednesday, 17 November 2021 at 07:25:46 UTC, Robert Schadek wrote:

>

Also you can not have string interpolation without dynamic memory.

With dynamic memory I presume you mean GC-allocated memory. dynamic memory allocation is broader term and covers cases such

Yes I mean GC-allocated memory

November 25, 2021
On Thursday, 25 November 2021 at 02:32:41 UTC, max haughton wrote:
> the key thing with this scope transformation isn't stack allocation but rather moving the allocation anywhere other than the GC.

I am not quite sure what you are saying.  Are you saying that:

1. The problem is moving the allocation somewhere other than the gc, including potentially to the stack, or to an alternate heap, or to somewhere else; or,

2. Converting allocations from gc to the stack is fine; but moving them anywhere else is problematic

In either case, this compiles currently and produces GC-free code:

@nogc:
void f(scope int[] x);
void g(int x, int y) { f([x, y]); }

I'm not sure where you would want to move scope allocations to aside from the stack, as scope guarantees LIFO, and so is the perfect fit for a stack.  Perhaps an alternate stack (cf 'brk') managed in druntime, to avoid stack overflow?  That would be good, but is hardly a challenging transformation if you can already produce regular stack allocation.
November 25, 2021
On Thursday, 25 November 2021 at 09:29:49 UTC, Elronnd wrote:
> On Thursday, 25 November 2021 at 02:32:41 UTC, max haughton wrote:
>> the key thing with this scope transformation isn't stack allocation but rather moving the allocation anywhere other than the GC.
>
> I am not quite sure what you are saying.  Are you saying that:
>
> 1. The problem is moving the allocation somewhere other than the gc, including potentially to the stack, or to an alternate heap, or to somewhere else; or,
>
> 2. Converting allocations from gc to the stack is fine; but moving them anywhere else is problematic
>
> In either case, this compiles currently and produces GC-free code:
>
> @nogc:
> void f(scope int[] x);
> void g(int x, int y) { f([x, y]); }
>
> I'm not sure where you would want to move scope allocations to aside from the stack, as scope guarantees LIFO, and so is the perfect fit for a stack.  Perhaps an alternate stack (cf 'brk') managed in druntime, to avoid stack overflow?  That would be good, but is hardly a challenging transformation if you can already produce regular stack allocation.

Just use malloc and free. If you want to be clever stick a branch in there or forward to a tuned allocator. The fact that the stack is LIFO makes absolutely no difference compared to the cost of calling into the GC and even worse potentially causing a collection.
November 25, 2021
On Thursday, 25 November 2021 at 09:29:49 UTC, Elronnd wrote:
> On Thursday, 25 November 2021 at 02:32:41 UTC, max haughton wrote:
>> the key thing with this scope transformation isn't stack allocation but rather moving the allocation anywhere other than the GC.
>
> I am not quite sure what you are saying.  Are you saying that:
>
> 1. The problem is moving the allocation somewhere other than the gc, including potentially to the stack, or to an alternate heap, or to somewhere else; or,
>
> 2. Converting allocations from gc to the stack is fine; but moving them anywhere else is problematic
>
> In either case, this compiles currently and produces GC-free code:
>
> @nogc:
> void f(scope int[] x);
> void g(int x, int y) { f([x, y]); }
>
> I'm not sure where you would want to move scope allocations to aside from the stack, as scope guarantees LIFO, and so is the perfect fit for a stack.  Perhaps an alternate stack (cf 'brk') managed in druntime, to avoid stack overflow?  That would be good, but is hardly a challenging transformation if you can already produce regular stack allocation.

Moving an unbounded allocation to malloc and free is fine. LIFO is totally irrelevant.

The point is avoiding putting pressure on the GC. If you want to be clever you can probably come up with some hybrid arrangement that tries to use the stack if it can or has a buffer somewhere.

November 25, 2021
On Thursday, 25 November 2021 at 15:42:28 UTC, max haughton wrote:
> Moving an unbounded allocation to malloc and free is fine. LIFO is totally irrelevant.
>
> The point is avoiding putting pressure on the GC. If you want to be clever you can probably come up with some hybrid arrangement that tries to use the stack if it can or has a buffer somewhere.

LIFO is a useful property that you can take advantage of.  Why would you _want_ to allocate on the heap when you could allocate on [some kind of] stack?

Re GC pressure, you get the same amount of pressure (amortized, assuming bounded allocation size and call-stack depth) if you allocate with the gc and then GC.free at the end of the scope.
November 25, 2021

On Tuesday, 16 November 2021 at 21:00:48 UTC, Robert Schadek wrote:

>

A Long Term Vision for the D programming language

The casual D user, when he finds a bug, will never report it we he has to
create a special account on our bugzilla.

That's true. Last year I found a bug in a process related function. Actually, I didn't know it was a bug. When Mr. M Parker happened to see my code and he said it was a bug. Then I asked him what to do next. He said, report it. I said "Okay" and then I forget it.

November 25, 2021
On Thursday, 25 November 2021 at 20:41:07 UTC, Elronnd wrote:
> On Thursday, 25 November 2021 at 15:42:28 UTC, max haughton wrote:
>> Moving an unbounded allocation to malloc and free is fine. LIFO is totally irrelevant.
>>
>> The point is avoiding putting pressure on the GC. If you want to be clever you can probably come up with some hybrid arrangement that tries to use the stack if it can or has a buffer somewhere.
>
> LIFO is a useful property that you can take advantage of.  Why would you _want_ to allocate on the heap when you could allocate on [some kind of] stack?
>
> Re GC pressure, you get the same amount of pressure (amortized, assuming bounded allocation size and call-stack depth) if you allocate with the gc and then GC.free at the end of the scope.

Because it's overly complicated. You can have a parallel stack if you want but KISS.

The GC could collect at the first allocation. The point is to avoid the GC entirely, more of a latency thing than throughput. Assuming the analysis is reliable in the frontend this also allows the function to be @nogc without forcing the programmer to do the memory allocation themselves.
November 26, 2021

On Wednesday, 24 November 2021 at 14:55:39 UTC, Ola Fosheim Grøstad wrote:

> >

functionality like Qt provide (non-GUI part). So methods that good lies to sig-slot paradigm can not be simply expressed in D. Sadly...

>

But if you want to improve on it, you probably could. So it is really up to you, if you are interested.

Well, yes ... No, I can't.
The message loop is a basic feature and should be designed by the founders of the library. Is not it so?

It seems to me that now is the time to postpone a little any new changes in the language, and focus on the applied aspect. And, suddenly, compatibility.

January 05, 2022

On Tuesday, 16 November 2021 at 21:00:48 UTC, Robert Schadek wrote:

>

This can be fixed quite easily as well:

private auto someFunIR(R)(R r) { ... }

private auto someFunRAR(R)(R r) { ...  }

auto somFun(R)(R r) {
	static if(isInputRange!R) {
		someFunIR(r);
	} else static if(isRandomAccessRange!R) {
		someFunRAR(r);
	} else {
		static assert(false, "R should be either be an "
				~ "InputRange but " ~ inputRangeErrorFormatter!R
				~ "\n or R should be an RandomAccessRange but "
				~ randomAccessRangeErrorFormatter!R
				~ "\n therefore you can call " ~ __FUNCTION__);
	}
}

Actually done and announced here
https://forum.dlang.org/thread/clyiounnxlnupinbafpy@forum.dlang.org

3 4 5 6 7 8 9 10 11 12 13
Next ›   Last »