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 i
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 you
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 fast
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 GC
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' lifeti
Here is test program (which is using DList aggressively)
```d
import std.stdio : writeln;
import core.sys.posix.unistd : sleep;
//import std.container.dlist; // dmd (v2.097.2)
import std.container: DList; // gdc (4.9.2)
void main() {
auto list = DList!(int)();
int k;
while (true) {
On Friday, 10 September 2021 at 10:20:52 UTC, drug wrote:
It is off-topic a bit
I am newbie - have been learning D for about 2 months or so.
I understand that my question is not about the language itself,
just picked forum for new users.
but I think none can compare gdc 4.9.2 to
same pictur
On Friday, 10 September 2021 at 11:09:10 UTC, bauss wrote:
Here's the specific change:
https://dlang.org/changelog/2.087.0.html#gc_parallel
thanx a lot!
On Friday, 10 September 2021 at 11:09:10 UTC, bauss wrote:
--DRT-gcopt=parallel:2 on the command line. A value of 0
disables parallel marking completely.
but it does not:
make -f Makefile-dmd
dmd --DRT-gcopt=parallel:0 engine/*.d common-sm/*.d server-sm/*.d
pool.d echo_server.d -ofecho-server
On Friday, 10 September 2021 at 11:32:02 UTC, Adam D Ruppe wrote:
You either pass as an argument *to your application*
--DRT-gcopt=parallel:0
oops... :)
On Friday, 10 September 2021 at 11:53:04 UTC, eugene wrote:
On Friday, 10 September 2021 at 11:32:02 UTC, Adam D Ruppe
wrote:
You either pass as an argument *to your application*
--DRT-gcopt=parallel:0
oops... :)
ps xH | grep [e]cho
5727 pts/14 S+ 0:13 ./echo-server --DRT-gcopt=parall
On Friday, 10 September 2021 at 12:10:58 UTC, Adam D Ruppe wrote:
btw why do the threads cause you trouble?
Well... probably it is subjective thing -
just do not 'like' when a program is doing something
that is not explicitly in it's source (I am C coder, you guessed).
More specifically - I ha
On Friday, 10 September 2021 at 12:59:08 UTC, bauss wrote:
It's just used to speed-up the GC.
Yeah, I got the point, but to be absolutely honest,
I (>20 years of C coding) do not like GC as such.
I believe manual free() is not that 'hard'.
And one must still release other resources.
(in C I wri
Code snippets
```d
class Stopper : StageMachine {
enum ulong M0_IDLE = 0;
Signal sg0, sg1;
this() {
super("STOPPER");
Stage init, idle;
init = addStage("INIT", &stopperInitEnter);
idle = addStage("IDLE", &stopperIdleEnter);
init.addReflex("M
On Monday, 13 September 2021 at 17:40:41 UTC, user1234 wrote:
The problems seems to lies in `newSignal()` which "would" not
allocate using the GC.
final Signal newSignal(int signum) {
Signal sg = new Signal(signum);
sg.owner = this;
sg.number = sg_number++;
s
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
And the most strange thing is this
It is echo-server/echo-client pair.
And it is echo-client that crashes upon SIGINT.
echo-server contains very similar code
class Listener : StageMachine {
enum ulong M0_WORK = 0;
enum ulong
On Monday, 13 September 2021 at 17:56:34 UTC, user1234 wrote:
thx, so the problem is not what I suspected to be (mixed
gc-managed and manually managed memory). sorrry...
I am actually C coder and do not have much experience
with GC languages, so I did not even attempt to
try use D without GC ye
On Monday, 13 September 2021 at 18:42:47 UTC, Steven
Schveighoffer wrote:
And you are registering your signals using the `+=` operator.
That was a sort of exercise with operator overloading.
Now, with your stopper code that you showed, it looks like you
are storing the reference to stopper ri
On Monday, 13 September 2021 at 18:45:22 UTC, jfondren wrote:
Instead of using a temporary EpollEvent array in
EventQueue.wait, you could make the array an instance variable
and have registerEventSource populate it directly
Actually, initial version of all that was using array,
allocated in co
On Tuesday, 14 September 2021 at 05:49:58 UTC, Tejas wrote:
Umm is it okay that he declared variables `init` and `idle` of
type `Stage` inside the constructor?
States of a machine are in associative array.
All other machines create their states in constructor,
local variables are for using addR
On Monday, 13 September 2021 at 18:45:22 UTC, jfondren wrote:
```d
auto p = cast(EpollEvent*)
pureMalloc(EpollEvent.sizeof);
```
What? Allocate struct epoll_event on the heap?
It is a feeble joke ;)
```c
static int ecap__add(int fd, void *dptr)
{
struct epoll_event waitfor =
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
Then after pressing ^C (SIGINT) the program gets SIGSEGV, since
references to sg0 and sg1 are no longer valid (they are
"sitting" in epoll_event structure).
... forget to mention, crashes here:
```d
bool wait() {
const i
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven
Schveighoffer wrote:
Though as I have learned helping C converts before, most of the
time things like this have to do with forgetting to store a GC
reference somewhere.
Yeah, in my first version I had
```d
foreach (k; 0 .. nConnections
On Tuesday, 14 September 2021 at 12:13:15 UTC, Steven
Schveighoffer wrote:
On 9/14/21 7:31 AM, eugene wrote:
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
EventSource s = events[k].es;
ulong ecode = s.eventCode(events[k].event_mask);
// < SIGSEGV
Not
On Tuesday, 14 September 2021 at 12:53:27 UTC, Adam D Ruppe wrote:
I had a problem just like this before because I was sending
objects through the pipe.
This reminds my (not very successfull) attempts to implement the
idea in Rust:
```rust
pub struct Edsm {
name: String,
pub states:
On Tuesday, 14 September 2021 at 12:53:27 UTC, Adam D Ruppe wrote:
I had a problem just like this before because I was sending
objects through the pipe. And while they were in the pipe -
```rust
pub fn msg(&self, code: u32) {
let ptr: *const u32 = &code;
let n = unsafe { wri
On Tuesday, 14 September 2021 at 12:52:44 UTC, Steven
Schveighoffer wrote:
But I agree that a superficial reading of your code seems like
it ought to not be collected, and that problem is also worth
figuring out. I have high confidence that it's probably not a
design flaw in the GC, but rather
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven
Schveighoffer wrote:
This project is too big and complex
Really, "too big and complex"?
It's as simple as a tabouret :)
It's just a toy/hobby 'project'.
On Tuesday, 14 September 2021 at 12:09:03 UTC, Steven
Schveighoffer wrote:
This project is too big and complex for me to diagnose by just
reading, it would take some effort
take a look at
https://www.routledge.com/Modeling-Software-with-Finite-State-Machines-A-Practical-Approach/Wagner-Schmuki
On Tuesday, 14 September 2021 at 14:56:00 UTC, jfondren wrote:
You could fix this by having a 128-bit struct and passing C an
index into it
It is another "not so funny joke", isn't it?
Look
```c
typedef union epoll_data {
void *ptr;
int fd;
uint32_t u32;
uin
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 ;)
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 pro
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 @s
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 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 are
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 dat
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**,
they
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 w
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 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!
I'
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 cr
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 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 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
- http://zed.karelia.ru/0/e/edsm-in-d-simple-example-
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 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 t
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
fi
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 obviou
On Tuesday, 21 September 2021 at 20:47:41 UTC, H. S. Teoh wrote:
Век живи - век учись. А дураком помрёшь.
:)
"Век живи - век учись, всё равно дураком помрёшь."
is correct version. :)
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 ex
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 minor
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 ap
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 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 `stoppe
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 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 t
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 cou
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 mind...
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 mo
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 m
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 'envir
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 (similar
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();
GC.addRoot
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 impl
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
ab
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 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 of
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
re
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 t
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 SIGIN
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 ob
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 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 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: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 mentio
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
FreeB
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 de
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 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. S
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 core.sys.freebsd.sy
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 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 w
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
the
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 deepe
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 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;
el
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 ;)
Y
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
c
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 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 d
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 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 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 ver
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 issue](https://i
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 Garb
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 a
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
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: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 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" */
char[
1 - 100 of 128 matches
Mail list logo
