Re: It's "Nicolas", not "Nicholas", unless it's non-gov, in which case it's "Nick"
On Wednesday, 14 September 2022 at 04:50:14 UTC, Nick Sabalausky (Abscissa) wrote: If it REALLY MUST be long-form, just think about sticking a bullshit "h" into this guys name: https://en.wikipedia.org/wiki/Nicolas_Cage Turns out it is not bullshit but rather history: https://en.wikipedia.org/wiki/Nicholas. Seems that in english, Nicolas is usually spelled with ch as Nicholas since 16th century. It is sad that name is misspelled in your case, though. Best regards, Alexandru.
It's "Nicolas", not "Nicholas", unless it's non-gov, in which case it's "Nick"
I took a time-warp and googled my name. Found this page calling me "Nicholas": https://wiki.dlang.org/Articles (Yes, I was previously a regular here in a past life.) I'm middle-aged and I've spent my entire life putting up with people who clearly can't even fucking read calling me "Nicholas". I expect that from common every-day morons. But I expect basic literacy from programmers. (And for that matter, it's always been "Nick", never "Nich?olas" outside of government bullshit) I can't even get my worthless piece-of-shit union to get my goddamn name right. I'd expect people here could manage to not fuck up a basic memcpy. If it REALLY MUST be long-form, just think about sticking a bullshit "h" into this guys name: https://en.wikipedia.org/wiki/Nicolas_Cage
Re: Introducing alid
On Wednesday, 14 September 2022 at 02:58:07 UTC, rikki cattermole wrote: Of course you are free to lie and say its mutable, but you can't lie to the cpu. It'll error if you try to write to it, resulting in the end of a process. I agree with what you said. Moreover, I sign it as an electronics engineer. However, we have to perform write protection with our own types. Anyway, I don't want to get into the discussions that are full of pages. SDB@79
Re: Introducing alid
On 14/09/2022 2:48 PM, Salih Dincer wrote: I'm far from making a solid recommendation. Immutable with const still doesn't make sense to me. I claim we can live without them. Immutable confuses me a lot. I think we should take control by creating our own types. D Language should be unornamented. We have to have immutable. You need a way in a systems language to say that a given chunk of memory is read only to prevent accidental writes. Of course you are free to lie and say its mutable, but you can't lie to the cpu. It'll error if you try to write to it, resulting in the end of a process.
Re: Introducing alid
On Tuesday, 13 September 2022 at 15:24:20 UTC, Ali Çehreli wrote:
On 9/12/22 22:24, Salih Dincer wrote:
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:
```d
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))`
I'm far from making a solid recommendation. Immutable with const
still doesn't make sense to me. I claim we can live without
them. Immutable confuses me a lot.
I think we should take control by creating our own types. D
Language should be unornamented.
SDB@79
Re: Inochi2D - Realtime 2D Animation written in D
On Monday, 12 September 2022 at 18:28:05 UTC, Luna wrote: Thanks for all of the kind words! I've just gotten [nightly builds](https://github.com/Inochi2D/inochi-creator/releases/tag/nightly) working for Inochi Creator this evening. Tak
Re: Introducing alid
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
On Tuesday, 13 September 2022 at 07:25:18 UTC, SDB@79 wrote: Is it the same with the new D versions? Now I replaced the cycle() to the leftward and tried it with the current version. It works great! ```d 0.iota!double(1,.1).cycle.cached.take(30).writeln; // [0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9] ``` Surely it's a useless implementation for cycle() I guess? SDB@79
