On Thursday, 23 September 2021 at 20:32:36 UTC, james.p.leblanc
wrote:
On Thursday, 23 September 2021 at 19:18:11 UTC, james.p.leblanc
wrote:
On Thursday, 23 September 2021 at 19:04:47 UTC, Steven
Schveighoffer wrote:
On 9/23/21 2:20 PM, james.p.leblanc wrote:
```
Produces:
typeid(jj):
Of course! And it's very common. <= lol
Thanks Ali. Much appreciated!
On 9/23/21 3:06 PM, Paul wrote:
> Can I have an associative array with the element type being a struct?
Of course! And it's very common. :)
> ...this
> 26 // simple dual tone key struct
> 27 struct keytones { ushort rowFreq; ushort colFreq; }
> 28
> 29 // keypad associative array
> 30
Can I have an associative array with the element type being a
struct?
..this
26 // simple dual tone key struct
27 struct keytones { ushort rowFreq; ushort colFreq; }
28
29 // keypad associative array
30 keytones[string] keypad;
31 keypad["1"].rowFreq = 697; keypad["1"].colFreq = 1209;
On Thursday, 23 September 2021 at 19:18:11 UTC, james.p.leblanc
wrote:
On Thursday, 23 September 2021 at 19:04:47 UTC, Steven
Schveighoffer wrote:
On 9/23/21 2:20 PM, james.p.leblanc wrote:
Dear D-ers,
Here comes a minor update (small rearrangement in mapping/array
ordering)
for anyone who
On Thursday, 23 September 2021 at 19:32:12 UTC, eugene wrote:
C (more elaborated) variant:
http://zed.karelia.ru/mmedia/bin/edsm-g2-rev-h.tar.gz
Sound, GUI? Easy, see
http://zed.karelia.ru/mmedia/bin/xjiss4.tar.gz
It's computer keyboard 'piano', based on the same engine.
As I've already
On Thursday, 23 September 2021 at 18:53:25 UTC, Steven
Schveighoffer wrote:
On 9/23/21 1:44 PM, eugene wrote:
Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are **blocked**, notifications (POLLIN) are
received via epoll_wait().
Oh interesting! I didn't read the code
On Thursday, 23 September 2021 at 19:04:47 UTC, Steven
Schveighoffer wrote:
On 9/23/21 2:20 PM, james.p.leblanc wrote:
Dear D-ers,
In attempting to cast JSONValues that hold arrays to "native"
How you really do this:
```d
import std.algorithm : map;
auto z5 = jj["ba"] // get the JSONValue
On 9/23/21 2:20 PM, james.p.leblanc wrote:
Dear D-ers,
In attempting to cast JSONValues that hold arrays to "native" array types,
I have hit some issues. Example code:
```d
import std.stdio;
import std.json;
void main(){
JSONValue jj;
jj["d"] = [ 1.234 ]; // a
On 9/23/21 1:44 PM, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven Schveighoffer wrote:
So imagine the sequence:
With ease!
1. ctrl-c, signal handler triggers, shutting down the loop
Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are
On Thursday, 23 September 2021 at 18:43:36 UTC, Steven
Schveighoffer wrote:
With dmd -O -inline, there is a chance it will be collected.
Inlining is key here.
never mind, GC.addRoot() looks more trustworthy, anyway :)
On 9/23/21 2:18 PM, eugene wrote:
On Thursday, 23 September 2021 at 17:16:23 UTC, Steven Schveighoffer wrote:
On 9/23/21 12:58 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven Schveighoffer
wrote:
See more details:
Dear D-ers,
In attempting to cast JSONValues that hold arrays to "native"
array types,
I have hit some issues. Example code:
```d
import std.stdio;
import std.json;
void main(){
JSONValue jj;
jj["d"] = [ 1.234 ]; // a "dummy" double value
jj["ba"] = [ true, false,
On Thursday, 23 September 2021 at 17:16:23 UTC, Steven
Schveighoffer wrote:
On 9/23/21 12:58 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven
Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
On Thursday, 23 September 2021 at 17:53:00 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:49:43 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all
On Thursday, 23 September 2021 at 17:49:43 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's
members
but both
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's
members
but both SIGINT and SIGTERM are still **blocked**,
they just will not reach
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
So imagine the sequence:
With ease!
1. ctrl-c, signal handler triggers, shutting down the loop
Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are **blocked**, notifications (POLLIN) are
On 9/23/21 12:53 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:53:37 UTC, Steven Schveighoffer wrote:
Technically, they should live past the end of main, because it's still
possible to receive signals then.
No, as soon as an application get SIGTERM/SIGINT,
event queue is stopped and
On 9/23/21 12:58 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
"
This method references the obj parameter, making that object ineligible
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven
Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
"
This method references the obj parameter, making that object
ineligible for garbage collection from the start
On Thursday, 23 September 2021 at 15:53:37 UTC, Steven
Schveighoffer wrote:
Technically, they should live past the end of main, because
it's still possible to receive signals then.
No, as soon as an application get SIGTERM/SIGINT,
event queue is stopped and we do not need no
more notifications
On 9/23/21 9:18 AM, eugene wrote:
On Thursday, 23 September 2021 at 12:53:14 UTC, Steven Schveighoffer wrote:
We need to add a better way to do that (similar to C# KeepAlive).
Do you mean some function attribute?..
C# KeepAlive (and Go KeepAlive) are a mechanism to do exactly what you
On 9/23/21 10:55 AM, eugene wrote:
On Thursday, 23 September 2021 at 14:31:34 UTC, jfondren wrote:
Nice. I thought of GC.addRoot several times but I was distracted by
the general solution of using object lifetimes with it, so that a
struct's destructor would call GC.removeRoot. For your case
On Thursday, 23 September 2021 at 14:31:34 UTC, jfondren wrote:
Nice. I thought of GC.addRoot several times but I was
distracted by the general solution of using object lifetimes
with it, so that a struct's destructor would call
GC.removeRoot. For your case just pinning these and forgetting
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
And the most strange thing is this - if using gdc with -Os
flag, the program behaves
exactly as when compiled with fresh dmd - destructors for sg0
and sg1 are called soon after program start.
Now I guess, gdc optimization by size
On Thursday, 23 September 2021 at 14:23:40 UTC, eugene wrote:
On Thursday, 23 September 2021 at 14:00:30 UTC, eugene wrote:
For the moment I am personally quite happy
```d
void main(string[] args) {
import core.memory : GC;
auto Main = new Main();
GC.addRoot(cast(void*)Main);
On Thursday, 23 September 2021 at 14:00:30 UTC, eugene wrote:
For the moment I am personally quite happy
```d
void main(string[] args) {
import core.memory : GC;
auto Main = new Main();
GC.addRoot(cast(void*)Main);
Main.run();
auto stopper = new Stopper();
On Thursday, 23 September 2021 at 13:30:42 UTC, eugene wrote:
So, in C it is MY (potentially wrong) code.
In D, it is NOT MY code, it is GC.
Actually in both cases it is MY+the compiler's code. A very
similar example from C-land (without my digging up the exact
details) is something like
On Thursday, 23 September 2021 at 12:53:14 UTC, Steven
Schveighoffer wrote:
With the caveat, of course, that the recommendation to "leave a
pointer on the stack" is not as easy to follow as one might
think with the optimizer fighting against that. We need to add
a better way to do that
On Thursday, 23 September 2021 at 13:05:07 UTC, Steven
Schveighoffer wrote:
UB in C leaves traps for the programmer, similar to this trap
you have found in the GC. Where code doesn't do what you are
expecting it to do.
There is a difference, though.
As I've already said,
GC is a sort of
On Thursday, 23 September 2021 at 12:53:14 UTC, Steven
Schveighoffer wrote:
Show me these rules!
They are here:
https://dlang.org/spec/interfaceToC.html#storage_allocation
With the caveat, of course, that the recommendation to "leave a
pointer on the stack" is not as easy to follow as one
On 9/23/21 8:10 AM, eugene wrote:
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer
wrote:
I find it interesting how you blame yourself for C's idiosyncrasies
Me? Blaming *myself* for C 'idiosyncrasies'? :) Where?
"When my C program crashes, I'm 100% sure I made
On 9/23/21 3:27 AM, eugene wrote:
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer
wrote:
Your experience is not typical though (clearly, as many of us
long-time D users had no idea why it was happening).
Oh, yeah - I have special trait of bumping against
various low
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
I find it interesting how you blame yourself for C's
idiosyncrasies
Me? Blaming *myself* for C 'idiosyncrasies'? :) Where?
but not for D's ;)
I've been learning D for about 3 months only.
I would say C has far
Yes, the `return` attribute is what should do it. You also need
to compile the code with -dip1000 option.
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
But realize that C has it's share of "shocks" as well
Any language is just an instrument,
most of the 'shocks' come not from
languages themselves, but from the
'enviromment', so to say.
An example that came to
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
In terms of any kind of memory management, whether it be ARC,
manual, GC, or anything else, there will always be pitfalls.
It's just that you have to get used to the pitfalls and how to
avoid them.
100% agree.
I
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
Your experience is not typical though (clearly, as many of us
long-time D users had no idea why it was happening).
Oh, yeah - I have special trait of bumping against
various low probability things :)
But for sure if
39 matches
Mail list logo
