On Tuesday, 17 May 2022 at 11:59:10 UTC, bauss wrote:
The problem with GC is that the lifetime sometimes exceed
what's expected.
I am not sure if I get the sentence right,
but I've had program crash because GC
in some circumstances collects objects which
where supposed to have 'infinite'
On Tuesday, 17 May 2022 at 11:50:30 UTC, zjh wrote:
On Tuesday, 17 May 2022 at 06:28:10 UTC, cc wrote:
Far better to just keep your house clean every day than let
the trash pile up and wait for the maid to come, IMO.
Right,GC is a bad idea!
As I've already mentioned I think the origin of
On Saturday, 14 May 2022 at 16:08:34 UTC, rikki cattermole wrote:
On 15/05/2022 4:00 AM, eugene wrote:
The more I have studied memory allocators & management
strategies
memory allocators and GC are different things
i've had at some point 'free list' based allocator
and it worked ~3 times
On Saturday, 14 May 2022 at 15:04:55 UTC, rikki cattermole wrote:
Garbage Collectors solve some really hard problems in regards
to memory management.
i've *never* encountered "really hard problems" with manual
memory management in C.
It is a very good base line for memory management when
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
What are you stuck at? What was the most difficult features to
understand? etc.
Garbage collection.
I am not programming languages theorist at at, but my imression
is:
* GC came from purely functional languages where everything
On Thursday, 24 February 2022 at 11:27:56 UTC, Tejas wrote:
Wagner F. et al
Modeling Software with Finite State Machines: A Practical
Approach
I've adopted some ideas from this book to POSIX/Linux API.
see also http://www.stateworks.com/
Thank you so much!
Also there is [very nice
On Thursday, 24 February 2022 at 09:11:01 UTC, eugene wrote:
In my case (I was working with REDIS KVS at the moment)
exact scenario was as follows:
* prog gets EPOLLOUT (write() won't block)
* prog writes()'s data to REDIS ("successfully")
* prog gets EPOLLERR|EPOLLHUP
After this I see that I
On Thursday, 24 February 2022 at 08:46:35 UTC, eugene wrote:
On Saturday, 19 February 2022 at 20:13:01 UTC, Chris Piker
wrote:
3. Update/insert to a postgresql database as data arrive.
I've remembered one not so obvious feature of TCP sockets
behavour.
If the connection is closed on the
On Saturday, 19 February 2022 at 20:13:01 UTC, Chris Piker wrote:
3. Update/insert to a postgresql database as data arrive.
I've remembered one not so obvious feature of TCP sockets
behavour.
If the connection is closed on the server side
(i.e. on the client side the socket is in CLOSE_WAIT
On Thursday, 24 February 2022 at 06:54:07 UTC, eugene wrote:
Wagner F. et al
Modeling Software with Finite State Machines: A Practical
Approach
I've adopted some ideas from this book to POSIX/Linux API.
Ah! I also have EDSM for bare metal (AVR8 to be exact)
There is [some
On Thursday, 24 February 2022 at 06:30:51 UTC, Tejas wrote:
On Wednesday, 23 February 2022 at 09:34:56 UTC, eugene wrote:
On Tuesday, 22 February 2022 at 20:19:39 UTC, Chris Piker
wrote:
[...]
As you might have been already noted,
the key idea is to implement SM explicitly,
i.e we have
On Tuesday, 22 February 2022 at 20:19:39 UTC, Chris Piker wrote:
credit you for the basic ideas
As you might have been already noted,
the key idea is to implement SM explicitly,
i.e we have states, messages, actions, transitions
and extremely simple engine (reactTo() method)
Switch-based
On Tuesday, 22 February 2022 at 20:19:39 UTC, Chris Piker wrote:
On Monday, 21 February 2022 at 07:00:52 UTC, eugene wrote:
On Monday, 21 February 2022 at 04:46:53 UTC, Chris Piker wrote:
On Sunday, 20 February 2022 at 18:00:26 UTC, eugene wrote:
I'm adverse to reading it closely since there
On Monday, 21 February 2022 at 04:46:53 UTC, Chris Piker wrote:
On Sunday, 20 February 2022 at 18:00:26 UTC, eugene wrote:
Yes, here is my engine with example (echo client/server pair):
- [In D (for Linux & FreeBSD)]
The code is terse and clean, thanks for sharing :)
Nice to hear, thnx!
On Monday, 21 February 2022 at 04:48:56 UTC, Chris Piker wrote:
On Sunday, 20 February 2022 at 18:36:21 UTC, eugene wrote:
I often use two connections, one for perform main task
(upload some data and alike) and the second for getting
notifications from PG, 'cause it very incovinient to
do both
On Saturday, 19 February 2022 at 20:13:01 UTC, Chris Piker wrote:
In general it should buffer data in RAM to avoid exerting back
pressure on the input socket and to allow for dropped
connections to the PG database.
If I get it right you want to restore connection
if it was closed by server
On Sunday, 20 February 2022 at 16:55:44 UTC, Chris Piker wrote:
But I would like to return to your idea in a couple months so
that I can try a fiber based implementation instead.
I thougt about implementing my engine using fibers but...
it seemed to me they are not very convinient because
On Saturday, 19 February 2022 at 20:13:01 UTC, Chris Piker wrote:
* general tips on which libraries to examine
Most people will probably say this is crazy,
but as to PG, one can do without libraries.
I am doing so during years (in C, not D) and
did not expierienced extremely complex
On Friday, 7 January 2022 at 21:17:33 UTC, Steven Schveighoffer
wrote:
In C you have one choice (printf), but that choice may not fit
your needs.
There are 2 buffers (RX one and TX one, both of 'reasonable' size)
(it's the effing echo-server, nothing more)
* print content of RX-buffer,
On Friday, 7 January 2022 at 20:40:02 UTC, Adam D Ruppe wrote:
On Friday, 7 January 2022 at 20:33:05 UTC, eugene wrote:
* python guys have memory leaks
* js guys have memory leaks
GC isn't actually there to prevent memory leaks.
Aha, unless you'll build GC into OS core :)
Its main job is
On Friday, 7 January 2022 at 20:08:00 UTC, H. S. Teoh wrote:
So it should be good even for GC-phobic code.
Nice term - "GC-phobic" :)
But looking from my cave - it's not a phobia, it's an
observation.
We've got a huge and complex project at my job, and...
* python guys have memory leaks
*
On Friday, 7 January 2022 at 20:08:00 UTC, H. S. Teoh wrote:
The simplest way to handle a C string from D is just to use
.fromStringz:
yes, this approach was used in some my previous traival
On Sunday, 2 January 2022 at 15:13:06 UTC, Paul Backus wrote:
On Sunday, 2 January 2022 at 09:15:32 UTC, eugene wrote:
```
p1.d(9): Error: cannot cast expression `until(b[], '\x0a',
Flag.yes)` of type `Until!("a == b", ubyte[], char)` to
`char[]`
```
Here's a working version:
```d
On Monday, 3 January 2022 at 02:50:46 UTC, Steven Schveighoffer
wrote:
On 1/2/22 4:15 AM, eugene wrote:
On Sunday, 2 January 2022 at 08:39:57 UTC, eugene wrote:
```d
writefln("'%s, world'", cast(char[])b[].until('\n'));
}
```
You missed a set of parentheses.
That was lack of attention
On Sunday, 2 January 2022 at 08:39:57 UTC, eugene wrote:
```d
import std.stdio;
import std.string;
```
oops...
```d
import std.stdio;
import std.string;
import std.algorithm : until;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\n\0\0" */
On Saturday, 1 January 2022 at 09:34:10 UTC, Jack Applegame wrote:
On Thursday, 30 December 2021 at 18:07:15 UTC, eugene wrote:
On Thursday, 30 December 2021 at 17:52:20 UTC, eugene wrote:
much better than my initial
You can also write
```d
auto s = cast(string)b; // or cast(string)(b)
```
On Friday, 31 December 2021 at 14:45:41 UTC, Steven Schveighoffer
wrote:
Unless I'm misunderstanding:
```d
import std.algorithm : until;
writefln("got '%s' from '%s:%d'",
(cast(char[])ioCtx.buf[]).until('\n'), client.addr,
client.port);
```
```d
import std.stdio;
import std.string;
void
On Thursday, 30 December 2021 at 17:52:20 UTC, eugene wrote:
everything as needed.
Nevertheless, I do have zeroes in the buffer, so:
```d
import std.stdio;
import std.string;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\n\0\0" */
char[]
On Thursday, 30 December 2021 at 17:43:14 UTC, Tejas wrote:
I'm not at my computer anymore, could you please replace the
`0x00` with `0x0A` and tell me if `strip` still doesn't work
for my solution?
Ok.
I think the `fromstringz` is trimming the null bytes for you,
making the `\n` the last
On Thursday, 30 December 2021 at 17:16:10 UTC, Tejas wrote:
I'll need to know the error message
There is none, see example in my prev message
because the following works:
```d
import std;
void main()
{
ubyte[] c ;
c.length = 100;
char[] arr = cast(char[])c[0 .. $];
On Thursday, 30 December 2021 at 16:49:17 UTC, Tejas wrote:
I _think_ the above code is correct, please verify
Self-contained example:
```d
import std.stdio;
import std.string;
void main() {
ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
/* "hello\n\0\0" */
On Thursday, 30 December 2021 at 16:49:17 UTC, Tejas wrote:
```d
char[] s = cast(char[])ioCtx.buf[0 .. $];// please remember
that in `[0 .. $]` last index is automatically `length - 1` but
just buf[$] will be an error since there the actual `length`
will be used
```
I _think_ the above code
On Thursday, 30 December 2021 at 09:34:27 UTC, eugene wrote:
```d
char[] s = cast(char[])ioCtx.buf[0 ..
strlen(cast(char*)ioCtx.buf.ptr) - 1];
// -1 is to eliminate terminating '\n'
writefln("got '%s' from '%s:%d'", s, client.addr, client.port);
```
Is there some more concise/elegant way to do
On Thursday, 30 December 2021 at 16:00:59 UTC, Era Scarecrow
wrote:
The answer i ended up with was a quick conversion to a UTF in
order to print it. Seems you might have to convert to Latin-1.
For a moment I only have symbols from the lower half of ASCII
table.
I meant - can that be done as
I suspect the question was asked somewhere before.
If so just give a link.
Anyway:
```d
class IoContext {
...
ubyte[] buf;
...
this(uint bufSize) {
buf = new ubyte[bufSize];
}
}
```
The buffer contains (ascii) string terminated with '\n'.
In order to print it not
sorry for intervening... :)
On Wednesday, 22 December 2021 at 08:17:03 UTC, rempas wrote:
No garbage collector, no exceptions
GOLDEN WORDS!!!
Yeah, Seriously D's developers and user really underestimate
the fact that the biggest percent of people not using D are
doing so because of the
On Wednesday, 22 December 2021 at 10:05:25 UTC, rempas wrote:
On Wednesday, 22 December 2021 at 09:49:59 UTC, eugene wrote:
It looks strange - leading D compiler is not in Linux/FreeBSD
repos :)
Well no so much.
Well, ok. Now the only thing I can "do" is to wait until
[the
On Wednesday, 22 December 2021 at 00:43:16 UTC, Johan wrote:
When you run `ldc2 -v test.d` (some arbitrary d file), you
should see "predefs" at the top, followed by a bunch of
predefined versions by the compiler. FreeBSD_xx should be on
that list, and the number should correspond to your OS
On Wednesday, 22 December 2021 at 08:41:56 UTC, eugene wrote:
Both these files are just copies from DMD distribution.
Forget to mention...
[installation instructions](https://dlang.org/dmd-freebsd.html)
are complete mess
I just copied right things to right places manually.
On Wednesday, 22 December 2021 at 06:50:00 UTC, rempas wrote:
On Tuesday, 21 December 2021 at 21:09:14 UTC, eugene wrote:
* The ldc installed by 'pkg install ldc' (the old one), does
not have config module
* Most resent ldc (link you indicated), does have condig
module, and it is exactly the
On Tuesday, 21 December 2021 at 21:02:21 UTC, rempas wrote:
On Tuesday, 21 December 2021 at 19:55:13 UTC, eugene wrote:
core/sys/freebsd/config.d and core/sys/freebsd/sys/event.d
are the same as in fresh dmd, so there is not much sense to
try it.
dmd (including phobos) is a reference, and I
On Tuesday, 21 December 2021 at 19:49:26 UTC, Steven
Schveighoffer wrote:
If this is a compiler-supplied version, then I don't think you
are allowed to set it explicitly.
moreover... commented out in condig.d like this:
```d
version (FreeBSD_12) enum __FreeBSD_version = 1202000;
//else
On Tuesday, 21 December 2021 at 19:22:35 UTC, rempas wrote:
Yeah, don't use the "pkg" version as it is outdated. It is very
hard to keep a whole OS (thousands of packages) up to date. So
yeah, uninstall your current ldc and trying with the one from
the link I gave you and tell me the output
On Tuesday, 21 December 2021 at 19:22:35 UTC, rempas wrote:
On Tuesday, 21 December 2021 at 19:00:04 UTC, eugene wrote:
Well, I just installed it by
pkg intstall ldc
Actually, this is my first experience with FreeBSD,
I did not have much to go deeper.
That's nice trying new things ;)
On Tuesday, 21 December 2021 at 19:13:19 UTC, Steven
Schveighoffer wrote:
On 12/21/21 1:50 PM, eugene wrote:
```d
version (FreeBSD_12) enum __FreeBSD_version = 1202000;
else version (FreeBSD_11) enum __FreeBSD_version = 1104000;
else version (FreeBSD_10) enum __FreeBSD_version = 1004000;
On Tuesday, 21 December 2021 at 17:00:06 UTC, Johan wrote:
On Tuesday, 21 December 2021 at 10:28:15 UTC, eugene wrote:
On Monday, 20 December 2021 at 21:19:43 UTC, rempas wrote:
I would recommend you to file an
[issue](https://issues.dlang.org/) just so the developers
themself can notice it.
On Tuesday, 21 December 2021 at 18:42:10 UTC, rempas wrote:
I'm wondering what happens in the latest LDC2 version. Your
version is from 1 year and 4 months ago.
Well, I just installed it by
pkg intstall ldc
Actually, this is my first experience with FreeBSD,
I did not have much to go
On Tuesday, 21 December 2021 at 17:00:06 UTC, Johan wrote:
I think the fix is needed here:
https://github.com/dlang/dmd/blob/ad8412530e607ffebec36f2dbdff1a6f2798faf7/src/dmd/target.d#L362-L372
looks like this.
it is a little bit strange, that in
/usr/include/d/dmd/core/sys/freebsd/config.d
On Tuesday, 21 December 2021 at 18:28:12 UTC, rempas wrote:
I would love to see more full (and correct) support for
FreeBSD, OpenBSD and DragonflyBSD from Dlang! Maybe one day..
My interest was kqueue facility.
I use linux epoll facility a lot in my progs,
and just wanted to do some exersises
On Tuesday, 21 December 2021 at 17:32:44 UTC, rempas wrote:
Yeah, you are right! Please eugene use LDC2 and check confirm
LDC2 stdlib does not have correct struct event_t for 12+ in
/usr/local/include/d/core/sys/freebsd/sys/event.d at all,
only for earlier versions, ie without extension field.
On Tuesday, 21 December 2021 at 17:32:44 UTC, rempas wrote:
Please eugene use LDC2 and check confirm that the behavior is
the same there.
Phobos that shipped with LDC, does not have
core.sys.freebsd.config
So
```d
import std.stdio;
//import core.sys.freebsd.config;
import
On Tuesday, 21 December 2021 at 17:32:44 UTC, rempas wrote:
On Tuesday, 21 December 2021 at 17:00:06 UTC, Johan wrote:
Please add which compiler(s) you have tried in the bug report.
Yeah, you are right! Please eugene use LDC2 and check confirm
that the behavior is the same there.
I have.
On Monday, 20 December 2021 at 21:19:43 UTC, rempas wrote:
I would recommend you to file an
[issue](https://issues.dlang.org/) just so the developers
themself can notice it.
filed an issue, see
https://issues.dlang.org/show_bug.cgi?id=22615
On Monday, 20 December 2021 at 21:19:43 UTC, rempas wrote:
I don't have FreeBSD and I can't check the output and header
I have it VirtualBox
files myself but from what you are saying this seems to me as a
bug. I would recommend you to file an
[issue](https://issues.dlang.org/) just so the
test program:
```d
import std.stdio;
import core.sys.freebsd.config;
import core.sys.freebsd.sys.event;
void main(string[] args) {
writefln("FreeBSD_version = %s", __FreeBSD_version);
writefln("sizeof(kevent_t) = %s", kevent_t.sizeof);
}
```
output:
@bsd:~/d> ./freebsdver
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 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 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 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 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: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 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 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
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
On Wednesday, 22 September 2021 at 12:26:53 UTC, Steven
Schveighoffer wrote:
On 9/22/21 8:22 AM, eugene wrote:
And it follows that programming in GC-supporting languages
*may* be harder than in languages with manual memory
management, right?
I meant my this particular trouble...
I do not want
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven
Schveighoffer wrote:
Once it's on the stack, the GC can see it for the full run of
`main`. This is why this case is different.
Note that Java is even more aggressive, and might *still*
collect it, because it could legitimately set
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven
Schveighoffer wrote:
Here is what is happening.
Many thanks for this so exhaustive explanation!
On Wednesday, 22 September 2021 at 10:05:05 UTC, jfondren wrote:
Nondeterminism in heap collection is a very common complaint,
It is another kind of nondeterminism that is usually complained
about
("*sometime* in the future GC will collect if it wants" or so)
but here we have data is that
On Tuesday, 21 September 2021 at 20:28:33 UTC, jfondren wrote:
Everything is Ok now,
I don't think this is reliably OK. If you're not using Stopper
later in the function, and if there are no other references to
it, then the GC can collect it. It just has no obligation to
collect it, so
On Tuesday, 21 September 2021 at 20:42:12 UTC, H. S. Teoh wrote:
A sufficiently optimizing compiler may determine that since
Main and stopper are independent, it is free to reorder the
code such that the two lifetimes are independent, and therefore
end up with the same situation as the first
On Tuesday, 21 September 2021 at 20:47:41 UTC, H. S. Teoh wrote:
Век живи - век учись. А дураком помрёшь.
:)
"Век живи - век учись, всё равно дураком помрёшь."
is correct version. :)
On Tuesday, 21 September 2021 at 20:47:41 UTC, H. S. Teoh wrote:
And since stopper isn't used anymore after declaration, an
optimizing compiler is free to assume that it's not needed
afterwards, so it's not obligated to keep the reference alive
until the end of the function.
It was not
On Tuesday, 21 September 2021 at 20:17:15 UTC, eugene wrote:
Now, change operation order in the main like this:
Actually, all proposed 'fixes'
- use stopper somehow in the end (writeln(stopper.sg0.number))
- change operation order
- etc
are strange. I mean it's strange (for me) that these
On Tuesday, 21 September 2021 at 19:42:48 UTC, jfondren wrote:
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
There's nothing special about sg0 and sg1, except that they're
part of Stopper. The Stopper in main() is collected before the
end of main() because it's not used later in
On Sunday, 19 September 2021 at 21:10:16 UTC, eugene wrote:
I rearranged the code of main() like this:
Similar rearrangement fixed the echo-client as well.
(I moved creation of Stopper to the very beginning of main())
On Sunday, 19 September 2021 at 20:12:45 UTC, eugene wrote:
On Monday, 13 September 2021 at 17:54:43 UTC, eugene wrote:
full src is here
http://zed.karelia.ru/0/e/edsm-in-d-2021-09-10.tar.gz
I've also made two simple examples, just in case
-
On Sunday, 19 September 2021 at 16:27:55 UTC, jfondren wrote:
This is also a sufficient patch to prevent the segfault:
```
diff --git a/echo_client.d b/echo_client.d
index 1f8270e..0b968a8 100644
--- a/echo_client.d
+++ b/echo_client.d
@@ -39,4 +39,6 @@ void main(string[] args) {
auto md =
On Sunday, 19 September 2021 at 16:27:55 UTC, jfondren wrote:
This is a sufficient patch to prevent the segfault:
```
diff --git a/echo_client.d b/echo_client.d
index 1f8270e..5ec41df 100644
--- a/echo_client.d
+++ b/echo_client.d
@@ -32,7 +32,7 @@ void main(string[] args) {
sm.run();
On Monday, 13 September 2021 at 17:54:43 UTC, eugene wrote:
full src is here
http://zed.karelia.ru/0/e/edsm-in-d-2021-09-10.tar.gz
I've also made two simple examples, just in case
- http://zed.karelia.ru/0/e/edsm-in-d-simple-example-1.tar.gz
Program does nothing, just waits for ^c, does not
On Sunday, 19 September 2021 at 16:27:55 UTC, jfondren wrote:
So the problem here is that ctrl-C causes that message to come
but Stopper's been collected and that address contains garbage.
This is exactly what I was trying to say...
Thanx a lot for your in-depth investigation of the trouble!
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
The instance of Stopper is created in the scope of main():
```d
void main(string[] args) {
auto stopper = new Stopper();
stopper.run();
```
Look...
I have added stopper into an array...
```d
Stopper[] stoppers;
auto
On Saturday, 18 September 2021 at 09:54:05 UTC, jfondren wrote:
On Saturday, 18 September 2021 at 09:39:24 UTC, eugene wrote:
The definition of this struct was taken from
/usr/include/dmd/druntime/import/core/sys/linux/epoll.d
...
If the reason for crash was in EpollEvent alignment,
programs
On Wednesday, 15 September 2021 at 23:07:45 UTC, jfondren wrote:
Yep. This patch is sufficient to prevent the segfault:
Your idea (hold references to all event sources somewhere) is
quite clear,
but it confuses me a bit, since
1) there **are** references to all event sources **already**,
reference-containing struct that vanishes on the return of your
corresponding function
I do not think it's a problem, otherwise **both programs would
not work at all**.
However, echo-server works without any surprises;
echo-client also works, except that EventSources
pointed by sg0 and sg1
On Tuesday, 14 September 2021 at 20:59:14 UTC, Ali Çehreli wrote:
On 9/14/21 9:56 AM, eugene wrote:
> On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
>> The misaligned pointer and the
>> reference-containing struct that vanishes on the return of
your
>> corresponding function
On Tuesday, 14 September 2021 at 18:33:33 UTC, Steven
Schveighoffer wrote:
People are trying to help you here.
Then, answer the questions.
Why those sg0 and sg1 are 'collected'
by this so f... antstic GC?
On Tuesday, 14 September 2021 at 17:02:32 UTC, jfondren wrote:
It doesn't seem like communication between us is possible
and you are wrong, as usual ,)
in the "a five-pound phone won't sell" way.
I am not a 'selling boy'
My suggestion remains: try troubleshooting by making your
program
On Tuesday, 14 September 2021 at 16:43:50 UTC, jfondren wrote:
GC needs to be able to stop your program
nice fantasies...
and find all of the live objects in it. The misaligned pointer
and the reference-containing struct that vanishes on the return
of your corresponding function are both
On Tuesday, 14 September 2021 at 16:07:00 UTC, jfondren wrote:
No. And when was the first one?
here:
On Monday, 13 September 2021 at 18:45:22 UTC, jfondren wrote:
auto p = cast(EpollEvent*) pureMalloc(EpollEvent.sizeof);
What? Allocate struct epoll_event on the heap?
It is a feeble joke
1 - 100 of 128 matches
Mail list logo
