Re: Trivial simple OpenGl working example
On Friday, 9 July 2021 at 19:15:44 UTC, H. S. Teoh wrote: On Fri, Jul 09, 2021 at 05:11:06AM +, Виталий Фадеев via Digitalmars-d-learn wrote: [...] [...] [...] [...] Generally, text rendering on OpenGL is a huge pain to implement. This is not specific to D, but to OpenGL in general, because OpenGL itself does not have direct support for text rendering at all. The usual route is to use an existing text-rendering library like FreeType to rasterize your text, then upload it as a texture to the GPU and render it as a quad. [...] Thank, H. S. Teoh!
Re: assert(false) and GC
On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: On 7/9/21 8:44 PM, russhy wrote: On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote: On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to >> define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one > liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). https://run.dlang.io/is/HJVSo0 it allocates That test is possibly showing the wrong thing. You are capturing all allocations, not just the concatenation. Change the assert line to: ```d string s = __FUNCTION__ ~ "This is an error message"; ``` And no GC allocations occur. Even without optimizations turned on. I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve i think you are right
Re: assert(false) and GC
On 7/9/21 8:44 PM, russhy wrote: On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote: On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). https://run.dlang.io/is/HJVSo0 it allocates That test is possibly showing the wrong thing. You are capturing all allocations, not just the concatenation. Change the assert line to: ```d string s = __FUNCTION__ ~ "This is an error message"; ``` And no GC allocations occur. Even without optimizations turned on. I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve
Re: Can I get the time "Duration" in "nsecs" acurracy?
On 7/9/21 5:04 PM, Ali Çehreli wrote:
On 7/9/21 1:54 PM, Paul Backus wrote:
On Friday, 9 July 2021 at 20:43:48 UTC, rempas wrote:
I'm reading the library reference for
[core.time](https://dlang.org/phobos/core_time.html#Duration) and It
says that the duration is taken in "hnsecs" and I cannot understand
if we can change that and choose the precision. Does anyone know if
we can do that?
It is stored internally in "hnsecs", but you can convert it to other
units using the `total` method [1]; for example,
`myDuration.total!"nsecs"`.
[1] https://dlang.org/phobos/core_time.html#.Duration.total
Yes but the resolution seems not to be better than 100 nsecs. A quick
research reveals a better resolution is not possible with common
hardware on at least Linux.
The following program always prints multiples of 100 on my Mint OS:
import std.stdio;
import core.thread;
import std.datetime.stopwatch;
void main() {
auto sw = StopWatch();
sw.start();
foreach (_; 0..10) {
Thread.sleep(0.nsecs);
writefln("%,s", sw.peek.total!"nsecs");
}
}
You can get better than hnsecs resolution with `core.time.MonoTime`,
which can support whatever the OS supports.
However, `Duration` and `SysTime` are stored in hnsecs for a very
specific reason -- range. Simply put, if you have a 64-bit integer, and
you picked nanoseconds as the unit, you can store only 585 years of
range. 10 ns gives you 5850 years, and 100 ns gives you 58k years. That
should be good enough for all but the most esoteric calculations (given
that a `Duration` is signed, this gives a range of roughly -29k years to
29k years).
Note also that hnsecs is the base unit for Windows high precision
clocks, though their epoch is year 1600 instead of year 0.
-Steve
Re: assert(false) and GC
On Friday, 9 July 2021 at 23:34:25 UTC, Ali Çehreli wrote: On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). Ali https://run.dlang.io/is/HJVSo0 it allocates
Re: assert(false) and GC
On 7/9/21 4:12 PM, russhy wrote: >> One way of forcing compile-time evaluation in D is to define an enum >> (which means "manifest constant" in that use). That's all I meant. It was a general comment. > this is very bad, assert are good because they are one liner, making it > 2 line to avoid GC is just poor design, compiler should be smarter There must be a misunderstanding. The one-liner does not allocate either (or @nogc is broken). Ali
Re: assert(false) and GC
On Friday, 9 July 2021 at 22:53:10 UTC, Ali Çehreli wrote:
On 7/8/21 11:11 AM, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at
compile time.
Best regards
One way of forcing compile-time evaluation in D is to define an
enum (which means "manifest constant" in that use). I used
@nogc to prove that there is no GC allocation as well:
@nogc
void main() {
enum msg = __FUNCTION__ ~ "This is an error message";
assert(false, msg);
}
Ali
this is very bad, assert are good because they are one liner,
making it 2 line to avoid GC is just poor design, compiler should
be smarter
Re: assert(false) and GC
On 7/8/21 11:11 AM, DLearner wrote:
Hi
Please confirm that:
`
assert(false, __FUNCTION__ ~ "This is an error message");
`
Will _not_ trigger GC issues, as the text is entirely known at compile
time.
Best regards
One way of forcing compile-time evaluation in D is to define an enum
(which means "manifest constant" in that use). I used @nogc to prove
that there is no GC allocation as well:
@nogc
void main() {
enum msg = __FUNCTION__ ~ "This is an error message";
assert(false, msg);
}
Ali
Re: Can I get the time "Duration" in "nsecs" acurracy?
On Friday, 9 July 2021 at 21:13:02 UTC, rempas wrote: On Friday, 9 July 2021 at 20:54:21 UTC, Paul Backus wrote: On Friday, 9 July 2021 at 20:43:48 UTC, rempas wrote: I'm reading the library reference for [core.time](https://dlang.org/phobos/core_time.html#Duration) and It says that the duration is taken in "hnsecs" and I cannot understand if we can change that and choose the precision. Does anyone know if we can do that? It is stored internally in "hnsecs", but you can convert it to other units using the `total` method [1]; for example, `myDuration.total!"nsecs"`. [1] https://dlang.org/phobos/core_time.html#.Duration.total It doesn't work for me. I have the following code: ``` MonoTime start = MonoTime.currTime(); // Doing stuff MonoTime end = MonoTime.currTime(); Duration dur = end - start; dur = dur.total!"nsecs"; ``` and I get the following error message: "Error: cannot implicitly convert expression \`dur.total()\` of type \`long\` to \`Duration`" You cannot change the precision of `Duration`, it always counts in multiples of 100 nsecs. You can count how many multiples of other units fit into the same `Duration` using `total`, but it will just return a number, not a “converted” `Duration`. `toString` will produce an easy readable string (more or less), as in https://run.dlang.io/is/baqKLG, where “hnsec” is the smallest unit. If you think hectonanosecond is a weird unit, then [you are not alone](https://forum.dlang.org/post/pwotyniksrskdzmea...@forum.dlang.org), and it [has been pointed out](https://forum.dlang.org/post/khppfxsyfefjksvri...@forum.dlang.org) that it does not comply with SI. — Bastiaan.
Re: assert(false) and GC
i think it only allocate when it hit the assert, but program will halt so it's not big deal, even though i feel this is a stupid design to make everything depend on GC... it gives bad impression when you want avoid it here is how i do to detect hidden GC allocations https://run.dlang.io/is/HJVSo0 if you attach a debugged you can see exactly where is the culprit
Re: Can I get the time "Duration" in "nsecs" acurracy?
On Friday, 9 July 2021 at 21:13:02 UTC, rempas wrote: ``` Duration dur = end - start; dur = dur.total!"nsecs"; ``` What are you trying to do, assigning a nanosecond value to a Duration? The Duration already has that many nanoseconds in it. and I get the following error message: "Error: cannot implicitly convert expression \`dur.total()\` of type \`long\` to \`Duration`"
Re: Can I get the time "Duration" in "nsecs" acurracy?
On Friday, 9 July 2021 at 20:54:21 UTC, Paul Backus wrote: On Friday, 9 July 2021 at 20:43:48 UTC, rempas wrote: I'm reading the library reference for [core.time](https://dlang.org/phobos/core_time.html#Duration) and It says that the duration is taken in "hnsecs" and I cannot understand if we can change that and choose the precision. Does anyone know if we can do that? It is stored internally in "hnsecs", but you can convert it to other units using the `total` method [1]; for example, `myDuration.total!"nsecs"`. [1] https://dlang.org/phobos/core_time.html#.Duration.total It doesn't work for me. I have the following code: ``` MonoTime start = MonoTime.currTime(); // Doing stuff MonoTime end = MonoTime.currTime(); Duration dur = end - start; dur = dur.total!"nsecs"; ``` and I get the following error message: "Error: cannot implicitly convert expression \`dur.total()\` of type \`long\` to \`Duration`"
Re: Can I get the time "Duration" in "nsecs" acurracy?
On 7/9/21 1:54 PM, Paul Backus wrote:
On Friday, 9 July 2021 at 20:43:48 UTC, rempas wrote:
I'm reading the library reference for
[core.time](https://dlang.org/phobos/core_time.html#Duration) and It
says that the duration is taken in "hnsecs" and I cannot understand if
we can change that and choose the precision. Does anyone know if we
can do that?
It is stored internally in "hnsecs", but you can convert it to other
units using the `total` method [1]; for example,
`myDuration.total!"nsecs"`.
[1] https://dlang.org/phobos/core_time.html#.Duration.total
Yes but the resolution seems not to be better than 100 nsecs. A quick
research reveals a better resolution is not possible with common
hardware on at least Linux.
The following program always prints multiples of 100 on my Mint OS:
import std.stdio;
import core.thread;
import std.datetime.stopwatch;
void main() {
auto sw = StopWatch();
sw.start();
foreach (_; 0..10) {
Thread.sleep(0.nsecs);
writefln("%,s", sw.peek.total!"nsecs");
}
}
Ali
Re: Can I get the time "Duration" in "nsecs" acurracy?
On Friday, 9 July 2021 at 20:43:48 UTC, rempas wrote: I'm reading the library reference for [core.time](https://dlang.org/phobos/core_time.html#Duration) and It says that the duration is taken in "hnsecs" and I cannot understand if we can change that and choose the precision. Does anyone know if we can do that? It is stored internally in "hnsecs", but you can convert it to other units using the `total` method [1]; for example, `myDuration.total!"nsecs"`. [1] https://dlang.org/phobos/core_time.html#.Duration.total
Can I get the time "Duration" in "nsecs" acurracy?
I'm reading the library reference for [core.time](https://dlang.org/phobos/core_time.html#Duration) and It says that the duration is taken in "hnsecs" and I cannot understand if we can change that and choose the precision. Does anyone know if we can do that?
Re: Trivial simple OpenGl working example
On Fri, Jul 09, 2021 at 05:11:06AM +, Виталий Фадеев via Digitalmars-d-learn wrote: [...] > I using CPU Pentium B970 It is old CPU, but even it contains a > graphics accelerator. > Mesa DRI Intel(R) HD Graphics 2000 (SNB GT1), has 4 conveers on GPU. > Smartphones also contains GPU. > Because OpenGL has high priority. [...] > What about text rendering ? Generally, text rendering on OpenGL is a huge pain to implement. This is not specific to D, but to OpenGL in general, because OpenGL itself does not have direct support for text rendering at all. The usual route is to use an existing text-rendering library like FreeType to rasterize your text, then upload it as a texture to the GPU and render it as a quad. If you want to do a more modern approach, you could use signed distance fields, but that requires some deep knowledge of how shaders work unless you can find an off-the-shelf library that does it for you. You may still end up needing FreeType or equivalent anyway, to get the SDFs in the first place. Here's something to start you off, if you don't already have an approach in mind: https://learnopengl.com/In-Practice/Text-Rendering T -- Chance favours the prepared mind. -- Louis Pasteur
Re: Where is "open" in "core.sys.linux.unistd"?
On Friday, 9 July 2021 at 15:37:41 UTC, Ali Çehreli wrote: On 7/9/21 8:31 AM, rempas wrote: > I searched "fnctl" in the repo [...] Probably made a typo Yes, the typo should be obvious to the non-dyslexic among us. :) fnctl <-- wrong fcntl <-- correct Ali Lol, I'm not dyslexic (or at least I haven't find out) but still some times I just miss those small details. Its probably that in my mind, I never really noticed how it's typed in the first place. I thought "fn" then "ctl" for "control" so "function control" or something idk Anyway yeah nice catch ;)
Re: Where is "open" in "core.sys.linux.unistd"?
On 7/9/21 11:31 AM, Dennis wrote: On Friday, 9 July 2021 at 15:11:38 UTC, Steven Schveighoffer wrote: But reading/writing, closing these file descriptors is always the same. For sockets you'd typically use `recv` and `send` instead or `read` and `write` because the former give extra options and the latter don't work on Windows. But yeah, on Linux `read` and `write` should work universally among file descriptors. I typically only use `send` and `recv` for for connectionless sockets. For TCP sockets, it's generally `read` and `write` for me (and it works fine). Windows is a different story, they have different i/o routines for system calls (yes, there's the shims for Posix file descriptors, but I wouldn't use those anyway). The larger point is that the reason `read`/`write` are separate from descriptor creation is because they are universal, while creation is not. -Steve
Re: Where is "open" in "core.sys.linux.unistd"?
On 7/9/21 8:31 AM, rempas wrote: > I searched "fnctl" in the repo [...] Probably made a typo Yes, the typo should be obvious to the non-dyslexic among us. :) fnctl <-- wrong fcntl <-- correct Ali
Re: Where is "open" in "core.sys.linux.unistd"?
On Friday, 9 July 2021 at 15:31:50 UTC, Dennis wrote: On Friday, 9 July 2021 at 15:11:38 UTC, Steven Schveighoffer wrote: But reading/writing, closing these file descriptors is always the same. For sockets you'd typically use `recv` and `send` instead or `read` and `write` because the former give extra options and the latter don't work on Windows. But yeah, on Linux `read` and `write` should work universally among file descriptors. That's very important! Thanks a lot for the info!
Re: Where is "open" in "core.sys.linux.unistd"?
On Friday, 9 July 2021 at 15:11:38 UTC, Steven Schveighoffer wrote: On 7/9/21 10:51 AM, rempas wrote: The file can be found quickly [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/unistd.d) or in your system if you want. Now the question is, why isn't there an "open" function for the equivalent system call? "close", "write", "read" etc. all exist. Anyone knows what's going on with open? Because file descriptors are created in different ways. For example, `open` exists for files [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/fcntl.d) But opening a socket is done via the `socket` system call [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/socket.d) They don't take the same arguments (nor should they). But reading/writing, closing these file descriptors is always the same. -Steve If I tell you that I searched "fnctl" in the repo and didn't find anything will you believe me? Probably made a typo idk... Anyway thanks a lot your help and I wish you to have an amazing day!
Re: Where is "open" in "core.sys.linux.unistd"?
On Friday, 9 July 2021 at 15:11:38 UTC, Steven Schveighoffer wrote: But reading/writing, closing these file descriptors is always the same. For sockets you'd typically use `recv` and `send` instead or `read` and `write` because the former give extra options and the latter don't work on Windows. But yeah, on Linux `read` and `write` should work universally among file descriptors.
Re: Where is "open" in "core.sys.linux.unistd"?
On Friday, 9 July 2021 at 15:04:32 UTC, rikki cattermole wrote: On 10/07/2021 2:51 AM, rempas wrote: The file can be found quickly [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/unistd.d) or in your system if you want. Now the question is, why isn't there an "open" function for the equivalent system call? "close", "write", "read" etc. all exist. Anyone knows what's going on with open? This is easily explained. open is not declared to be defined in unist.h[0] You may be wanting fopen from stdio.h[1] Or open from fcntl.h[2] [0] https://man7.org/linux/man-pages/man0/unistd.h.0p.html [1] https://man7.org/linux/man-pages/man0/stdio.h.0p.html [2] https://man7.org/linux/man-pages/man0/fcntl.h.0p.html Thanks man, have a nice day
Re: Where is "open" in "core.sys.linux.unistd"?
On 7/9/21 10:51 AM, rempas wrote: The file can be found quickly [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/unistd.d) or in your system if you want. Now the question is, why isn't there an "open" function for the equivalent system call? "close", "write", "read" etc. all exist. Anyone knows what's going on with open? Because file descriptors are created in different ways. For example, `open` exists for files [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/fcntl.d) But opening a socket is done via the `socket` system call [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/socket.d) They don't take the same arguments (nor should they). But reading/writing, closing these file descriptors is always the same. -Steve
Re: Where is "open" in "core.sys.linux.unistd"?
On 10/07/2021 2:51 AM, rempas wrote: The file can be found quickly [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/unistd.d) or in your system if you want. Now the question is, why isn't there an "open" function for the equivalent system call? "close", "write", "read" etc. all exist. Anyone knows what's going on with open? This is easily explained. open is not declared to be defined in unist.h[0] You may be wanting fopen from stdio.h[1] Or open from fcntl.h[2] [0] https://man7.org/linux/man-pages/man0/unistd.h.0p.html [1] https://man7.org/linux/man-pages/man0/stdio.h.0p.html [2] https://man7.org/linux/man-pages/man0/fcntl.h.0p.html
Where is "open" in "core.sys.linux.unistd"?
The file can be found quickly [here](https://github.com/dlang/druntime/blob/master/src/core/sys/posix/unistd.d) or in your system if you want. Now the question is, why isn't there an "open" function for the equivalent system call? "close", "write", "read" etc. all exist. Anyone knows what's going on with open?
Re: Why I'm getting this "Range Violation" error?
On Friday, 9 July 2021 at 11:56:40 UTC, Ali Çehreli wrote: In addition to what others said, you can take advantage of ranges to separate concerns of filtering and iteration. Here are two ways: [...] Of course another help from the legend himself ;) As always thanks a lot and have an amazing day!
Re: to compose or hack?
On Wednesday, 7 July 2021 at 01:44:20 UTC, Steven Schveighoffer
wrote:
But it got me thinking, how often do people roll their own vs.
trying to compose using existing Phobos nuggets?
When there's not an obvious/simple way to do something by
composing ranges, I tend to just give up and write procedural
code instead. Yes, the resulting code is longer and more prone to
logic bugs, but there's no limit to what you can do and it's
easier to see what's going on at a lower level. I also don't tend
to let composed ranges leave the function they were created in, I
rather pass simple arrays around than complex objects depending
on multiple inputs from different sources.
I don't know what the destination of your range is so this might
not be applicable, but I'd probably end up writing a function
with an OutputRange like this:
```D
void putRangeInterleaved(O, R, E)(ref O sink, R range, E
separator) {
import std.range.primitives: put;
if (!range.empty) {
put(sink, range.front);
range.popFront();
}
foreach(ref elem; range) {
put(sink, separator);
put(sink, elem);
}
}
```
I'm not trying to discourage anyone from writing range code, I'm
just presenting this as an alternative in case it's useful.
Re: Why I'm getting this "Range Violation" error?
On 7/9/21 12:21 AM, rempas wrote:
>while (prompt[i] != '{' && i < len) {
In addition to what others said, you can take advantage of ranges to
separate concerns of filtering and iteration. Here are two ways:
import core.stdc.stdio;
import std.algorithm;
// Same as your original
void print(T)(string prompt, T args...) {
prompt
.filter!(c => c != '{')
.each!(c => printf("%c", c));
// If you are not familiar with the shorthand lambda syntax,
// I read c => foo(c) as "given c, produce foo(c)."
//
// Well... 'each' is different because it does not
// produce anything. It its case: "given c, do this."
}
// This one dispatches filtering to another function but
// still uses a 'foreach' loop
void print2(T)(string prompt, T args...) {
foreach (c; prompt.sansCurly) {
printf("%c", c);
}
}
// I used R instead of 'string' in case it will be more useful
auto sansCurly(R)(R range) {
return range.filter!(c => c != '{');
}
void main() {
print("Hello, {world!\n", 10);
print2("Hello, {world!\n", 10);
}
Ali
Re: assign to property 2 values
On Friday, 9 July 2021 at 11:04:23 UTC, Dennis wrote: On Friday, 9 July 2021 at 10:19:59 UTC, Виталий Фадеев wrote: It possible in current version 2.097 ? If you `import std.typecons` you can do: ```D element.border = tuple(1, solid).expand; ``` But it's not pretty. I suggest either calling the function regularly, or combing all settings in a single struct: ```D element.border = Border(/*width:*/ 1, /*solid*/ true); ``` Named arguments are not implemented yet, hence the comments. Thank. But it's not pretty. Yes. Named arguments are not implemented yet, hence the comments. +1
Re: assign to property 2 values
On Friday, 9 July 2021 at 10:19:59 UTC, Виталий Фадеев wrote: It possible in current version 2.097 ? If you `import std.typecons` you can do: ```D element.border = tuple(1, solid).expand; ``` But it's not pretty. I suggest either calling the function regularly, or combing all settings in a single struct: ```D element.border = Border(/*width:*/ 1, /*solid*/ true); ``` Named arguments are not implemented yet, hence the comments.
Re: assign to property 2 values
On Friday, 9 July 2021 at 10:19:59 UTC, Виталий Фадеев wrote:
I want this feature in D:
```
element.border = 1, solid;
struct Element
{
@property
void border( int width, BorderStyle style )
{
this.borderWidth = width;
this.borderStyle = style;
}
}
```
Description:
```
element.border = 1, solid;
```
will rewriten to the
```
element.border(1, solid);
```
This is same as @property.
```
element.color = 0xCCC;
@property void color( uint a ) { this._color = a; }
```
but with 2 arguments, and more.
It possible in current version 2.097 ?
I undestand what
element.border = 1, solid;
is
element.border = 1;
solid();
assign to property 2 values
I want this feature in D:
```
element.border = 1, solid;
struct Element
{
@property
void border( int width, BorderStyle style )
{
this.borderWidth = width;
this.borderStyle = style;
}
}
```
Description:
```
element.border = 1, solid;
```
will rewriten to the
```
element.border(1, solid);
```
This is same as @property.
```
element.color = 0xCCC;
@property void color( uint a ) { this._color = a; }
```
but with 2 arguments, and more.
It possible in current version 2.097 ?
Re: Can I make system calls directly from D?
On Friday, 9 July 2021 at 08:28:25 UTC, Dennis wrote:
On Friday, 9 July 2021 at 08:08:57 UTC, rempas wrote:
I just wonder if I'm able to do system calls directly from D
or If I have to create bindings from "unistd.h" from C
If with directly means 'without calling any C function' you can
use inline assembly:
```D
version(linux)
void rt_sigreturn() {
version(D_InlineAsm_X86_64) asm {
naked;
mov EAX, 15;
syscall;
}
}
```
This is the most "direct" way possible. However I should probably
not mess with assembly at this point and use the built-in D
header file for unistd. Thanks a lot for your time tho, have a
great day!
Re: Can I make system calls directly from D?
On Friday, 9 July 2021 at 08:18:51 UTC, Ferhat Kurtulmuş wrote: On Friday, 9 July 2021 at 08:08:57 UTC, rempas wrote: I just wonder if I'm able to do system calls directly from D or If I have to create bindings from "unistd.h" from C I don't know if it covers what you want but, druntime has those definitions: https://github.com/dlang/druntime/blob/master/src/core/sys/posix/unistd.d import core.sys.posix.unistd; ... do stuff Yep! From my understanding, this is binding from C so at least I don't have to make them on my own. Thanks a lot for your time, have an amazing day!
Re: Can I make system calls directly from D?
On Friday, 9 July 2021 at 08:08:57 UTC, rempas wrote:
I just wonder if I'm able to do system calls directly from D or
If I have to create bindings from "unistd.h" from C
If with directly means 'without calling any C function' you can
use inline assembly:
```D
version(linux)
void rt_sigreturn() {
version(D_InlineAsm_X86_64) asm {
naked;
mov EAX, 15;
syscall;
}
}
```
Re: Error: Outside Unicode code space
On Friday, 9 July 2021 at 03:32:31 UTC, Adam D Ruppe wrote: On Friday, 9 July 2021 at 03:09:52 UTC, Tony wrote: The editor I am using (Code::Blocks) displays the characters just fine. So it seems that the error message should be "Error: Outside the ASCII code space". D supports stuff outside the ASCII code space just fine. Are you sure the file is saved as utf 8? if it is something like Windows 1252 it can still often be displayed but dmd won't know what to make of it. When I checked "Settings->Editor...->Encoding Settings" it was set to WINDOWS-1252. Changing it to UTF-8 fixed the issue. Thanks!
Re: Can I make system calls directly from D?
On Friday, 9 July 2021 at 08:08:57 UTC, rempas wrote: I just wonder if I'm able to do system calls directly from D or If I have to create bindings from "unistd.h" from C I don't know if it covers what you want but, druntime has those definitions: https://github.com/dlang/druntime/blob/master/src/core/sys/posix/unistd.d import core.sys.posix.unistd; ... do stuff
Can I make system calls directly from D?
I just wonder if I'm able to do system calls directly from D or If I have to create bindings from "unistd.h" from C
Re: Why I'm getting this "Range Violation" error?
On Friday, 9 July 2021 at 07:54:44 UTC, zjh wrote:
On Friday, 9 July 2021 at 07:21:06 UTC, rempas wrote:
I have the following code:
`prompt[i]!='{'`,here,i=len.so `array overflow`
Thanks a lot. It seems I have a lot to learn. Have an amazing day!
Re: Why I'm getting this "Range Violation" error?
On Friday, 9 July 2021 at 07:38:50 UTC, Mike Parker wrote:
On Friday, 9 July 2021 at 07:21:06 UTC, rempas wrote:
When I execute it, I'm getting a range violation error. If I
try to set "len" to be the length of the "prompt" minus 1,
then it will work and it will print the "prompt" until the
questionmark. So I cannot find where the error is...
Because you're indexing the prompt with i before you ensure
that i is valid. Swap the operands in your if condition:
```
while (i < len && prompt[i] != '{')
```
Or better yet, use foreach, which exists to avoid this sort of
mistake:
```
foreach(c; prompt) {
if(c != '{') printf("%c", c);
}
```
OMG!!! Yes! I feel bad for not catching it now... Meanwhile I
realized "while" will not work in my example anyway. Thanks for
the man! Have a nice day!
Re: Why I'm getting this "Range Violation" error?
On Friday, 9 July 2021 at 07:21:06 UTC, rempas wrote:
I have the following code:
`prompt[i]!='{'`,here,i=len.so `array overflow`
Re: Why I'm getting this "Range Violation" error?
On Friday, 9 July 2021 at 07:21:06 UTC, rempas wrote:
When I execute it, I'm getting a range violation error. If I
try to set "len" to be the length of the "prompt" minus 1, then
it will work and it will print the "prompt" until the
questionmark. So I cannot find where the error is...
Because you're indexing the prompt with i before you ensure that
i is valid. Swap the operands in your if condition:
```
while (i < len && prompt[i] != '{')
```
Or better yet, use foreach, which exists to avoid this sort of
mistake:
```
foreach(c; prompt) {
if(c != '{') printf("%c", c);
}
```
Why I'm getting this "Range Violation" error?
I have the following code:
```
import core.stdc.stdio;
void print(T)(string prompt, T args...) {
size_t len = prompt.length;
size_t i = 0;
while (prompt[i] != '{' && i < len) {
printf("%c", prompt[i]);
i++;
}
}
void main() {
print("Hello, world!\n", 10);
}
```
When I execute it, I'm getting a range violation error. If I try
to set "len" to be the length of the "prompt" minus 1, then it
will work and it will print the "prompt" until the questionmark.
So I cannot find where the error is...
Re: Trivial simple OpenGl working example
On Friday, 9 July 2021 at 06:16:08 UTC, Ferhat Kurtulmuş wrote: On Friday, 9 July 2021 at 05:17:28 UTC, Виталий Фадеев wrote: [...] [...] Dear Vitaly (Google translates it like that :)), I didn't touch that game for a while. I have just tried to compile and those are the steps to build and run it: [...] You may also need to use the exact version of "bettercmath": "0.3.1".
Re: Trivial simple OpenGl working example
On Friday, 9 July 2021 at 05:17:28 UTC, Виталий Фадеев wrote: On Thursday, 8 July 2021 at 17:20:14 UTC, Ferhat Kurtulmuş wrote: On Thursday, 8 July 2021 at 13:51:51 UTC, Виталий Фадеев wrote: Hi! Each ends with error. Dear Vitaly (Google translates it like that :)), I didn't touch that game for a while. I have just tried to compile and those are the steps to build and run it: Using a Windows 10 x64. (Webassembly build needs crazy efforts, don't try it for now. If you are on a posix system please delete *.a folders from the root folder because they are for webassembly) 1) Open the dub.json or dub.selections.json, and change "bcaa": "~>0.0.5" to "bcaa": "0.0.5" (Recently a contributor and I have made some breaking changes in bcaa). 2) Have those lib and dll files in the root folder of the project: chipmunk.lib // I manually compiled this one libfreetype-6.dl libjpeg-9.dll libpng16-16.dll libtiff-5.dll libwebp-7.dll SDL2_image.dll SDL2_image.lib SDL2_ttf.dll SDL2_ttf.lib SDL2.dll SDL2.lib zlib1.dll basically, those are win 64-bit builds of SDL2, its friends, and their dependencies. If you provide an email, I can send them to you via wetransfer. For posix builds, you will have to figure those out.
