On Monday, 29 June 2020 at 22:47:16 UTC, Steven Schveighoffer
wrote:
Yes. The return statement is inside the scope of the function,
so it runs before the scope is exited. Are you saying the spec
doesn't say that?
Thanks for the assurance. The spec does state it like this:
```
The
On Saturday, 27 June 2020 at 14:49:34 UTC, James Gray wrote:
I have produced something which essentially reproduces my
problem.
What is the problem? Do you have a leak or you want to know how
GC works?
On Monday, 29 June 2020 at 19:55:59 UTC, Steven Schveighoffer
wrote:
Yep, for sure. I'll file an issue. Anyone know why the calling
convention would differ?
It's easier to enforce left to right evaluation order this way:
arguments are pushed to stack as they are evaluated, which is
pascal
On 6/30/20 2:56 AM, Arjan wrote:
On Monday, 29 June 2020 at 22:47:16 UTC, Steven Schveighoffer wrote:
Yes. The return statement is inside the scope of the function, so it
runs before the scope is exited. Are you saying the spec doesn't say
that?
Thanks for the assurance. The spec does state
On Tuesday, 30 June 2020 at 00:33:41 UTC, Ali Çehreli wrote:
On 6/29/20 4:34 PM, aberba wrote:
> So with this, without the Thread.sleep() to block main from
exiting, the
> spawned thread will terminate immediately.
You can call core.thread.thread_joinAll at the end of main.
So I tried that
On 6/30/20 3:00 AM, Kagamin wrote:
On Monday, 29 June 2020 at 19:55:59 UTC, Steven Schveighoffer wrote:
Yep, for sure. I'll file an issue. Anyone know why the calling
convention would differ?
It's easier to enforce left to right evaluation order this way:
arguments are pushed to stack as
On Tuesday, 30 June 2020 at 12:22:15 UTC, Steven Schveighoffer
wrote:
(i.e. one cannot use extern(D) functions for C callbacks).
I don't think that's a big issue. Honestly, I don't think it's an
issue at all.
BTW, the order of arguments is not the only thing. Variadic
functions in D and
On Tuesday, 30 June 2020 at 13:44:38 UTC, aberba wrote:
On Tuesday, 30 June 2020 at 12:48:32 UTC, Simen Kjærås wrote:
On Tuesday, 30 June 2020 at 08:15:54 UTC, aberba wrote:
On Tuesday, 30 June 2020 at 00:33:41 UTC, Ali Çehreli wrote:
On 6/29/20 4:34 PM, aberba wrote:
> So with this, without
On Tuesday, 30 June 2020 at 08:15:54 UTC, aberba wrote:
On Tuesday, 30 June 2020 at 00:33:41 UTC, Ali Çehreli wrote:
On 6/29/20 4:34 PM, aberba wrote:
> So with this, without the Thread.sleep() to block main from
exiting, the
> spawned thread will terminate immediately.
You can call
On Tuesday, 30 June 2020 at 12:48:32 UTC, Simen Kjærås wrote:
On Tuesday, 30 June 2020 at 08:15:54 UTC, aberba wrote:
On Tuesday, 30 June 2020 at 00:33:41 UTC, Ali Çehreli wrote:
On 6/29/20 4:34 PM, aberba wrote:
> So with this, without the Thread.sleep() to block main from
exiting, the
>
On 6/30/20 10:15 AM, Simen Kjærås wrote:
On Tuesday, 30 June 2020 at 13:44:38 UTC, aberba wrote:
On Tuesday, 30 June 2020 at 12:48:32 UTC, Simen Kjærås wrote:
On Tuesday, 30 June 2020 at 08:15:54 UTC, aberba wrote:
On Tuesday, 30 June 2020 at 00:33:41 UTC, Ali Çehreli wrote:
On 6/29/20 4:34
On 6/30/20 9:44 AM, aberba wrote:
On Tuesday, 30 June 2020 at 12:48:32 UTC, Simen Kjærås wrote:
So I guess the error is elsewhere, but I'm not sure where and how.
Yeah, you're right. I changed receiveTimeout() to receive() to try
something and forgot to change it back.
Jeez, I hate
On Tue, Jun 30, 2020 at 04:50:07PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Tuesday, 30 June 2020 at 16:41:50 UTC, JN wrote:
> > I like my code to be explicit, even at a cost of some extra typing,
> > rather than get bitten by some unexpected implicit behavior.
>
> I agree, I
On Tuesday, 30 June 2020 at 16:37:12 UTC, Steven Schveighoffer
wrote:
That's a feature. I don't think it's going away. The problem of
accidental assignment is probably not very common.
-Steve
What is the benefit of this feature? I feel like D has quite a
few of such "features". I like my
On Tuesday, 30 June 2020 at 16:41:50 UTC, JN wrote:
I like my code to be explicit, even at a cost of some extra
typing, rather than get bitten by some unexpected implicit
behavior.
I agree, I think ALL implicit slicing of static arrays are
problematic and should be removed. If you want to
On Tuesday, 30 June 2020 at 12:18:14 UTC, Steven Schveighoffer
wrote:
On 6/30/20 2:56 AM, Arjan wrote:
On Monday, 29 June 2020 at 22:47:16 UTC, Steven Schveighoffer
wrote:
[...]
Thanks for the assurance. The spec does state it like this:
```
The ScopeGuardStatement executes
On Tue, Jun 30, 2020 at 04:22:57PM +, JN via Digitalmars-d-learn wrote:
> Spent some time debugging because I didn't notice it at first,
> essentially something like this:
>
> int[3] foo = [1, 2, 3];
> foo = 5;
> writeln(foo); // 5, 5, 5
>
> Why does such code compile? I don't think this
On 6/30/20 12:37 PM, Steven Schveighoffer wrote:
On 6/30/20 12:22 PM, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be
On 6/30/20 12:22 PM, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be permitted,
because it's easy to make a mistake
On 6/30/20 2:22 PM, H. S. Teoh wrote:
On Tue, Jun 30, 2020 at 02:06:13PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 6/30/20 12:37 PM, Steven Schveighoffer wrote:
[...]
I take it back, I didn't realize this wasn't something that happened
with dynamic arrays:
int[] dyn =
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be
permitted, because it's easy to make a mistake (when you wanted
foo[index] but
On Tue, Jun 30, 2020 at 02:06:13PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 6/30/20 12:37 PM, Steven Schveighoffer wrote:
[...]
> I take it back, I didn't realize this wasn't something that happened
> with dynamic arrays:
>
> int[] dyn = [1, 2, 3];
>
> dyn = 5; // error
>
Hi, I was looking the PR in DMD and I found this one:
https://github.com/dlang/dmd/pull/11353/
One of the changes was:
-loc.linnum += incrementLoc;
+loc.linnum = loc.linnum + incrementLoc;
I usually do the former and I particularly hate the later, so my
question is,
On Tuesday, 30 June 2020 at 20:01:43 UTC, Stanislav Blinov wrote:
On Tuesday, 30 June 2020 at 19:58:05 UTC, matheus wrote:
+loc.linnum = loc.linnum + incrementLoc;
This works because it was declared:
void linnum(uint rhs) { _linnum = rhs; }
Right?
Almost. Given these
On Tuesday, 30 June 2020 at 19:42:57 UTC, matheus wrote:
in this case this was more a style thing than anything else
right? Or is there something I'm not able to see?
Before the change, linnum and charnum are public variables, one
can do a += on them. After the change, they become properties
On Tuesday, 30 June 2020 at 19:55:56 UTC, matheus wrote:
On Tuesday, 30 June 2020 at 19:46:35 UTC, Stanislav Blinov
...
@safe @nogc pure @property
{
const uint linnum() { return _linnum; }
const uint charnum() { return _charnum; }
void linnum(uint rhs) { _linnum
On Tuesday, 30 June 2020 at 19:46:35 UTC, Stanislav Blinov wrote:
On Tuesday, 30 June 2020 at 19:42:57 UTC, matheus wrote:
in this case this was more a style thing than anything else
right? Or is there something I'm not able to see?
Before the change, linnum and charnum are public variables,
Given -preview=nosharedaccess on the command line, "hello world"
fails to compile (you are referred to core.atomic ...).
What is the idiomatic way to get writeln style output from a
nosharedaccess program?
Is separate compilation the way to go?
On Tuesday, 30 June 2020 at 19:58:05 UTC, matheus wrote:
+loc.linnum = loc.linnum + incrementLoc;
This works because it was declared:
void linnum(uint rhs) { _linnum = rhs; }
Right?
Almost. Given these definitions:
@safe @nogc pure @property
{
const uint linnum() { return
On 6/30/20 3:56 PM, Bruce Carneal wrote:
Given -preview=nosharedaccess on the command line, "hello world" fails
to compile (you are referred to core.atomic ...).
What is the idiomatic way to get writeln style output from a
nosharedaccess program?
Is separate compilation the way to go?
On Tuesday, 30 June 2020 at 20:04:33 UTC, Steven Schveighoffer
wrote:
The answer is -- update Phobos so it works with -nosharedaccess
:)
Yeah... and dip1000. And dip1008. And dip... :)
On Tuesday, 30 June 2020 at 20:12:59 UTC, Stanislav Blinov wrote:
On Tuesday, 30 June 2020 at 20:04:33 UTC, Steven Schveighoffer
wrote:
The answer is -- update Phobos so it works with
-nosharedaccess :)
Yeah... and dip1000. And dip1008. And dip... :)
Didn't want to be snippity but, yeah,
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be
permitted, because it's
On Monday, 29 June 2020 at 10:44:16 UTC, kinke wrote:
On Monday, 29 June 2020 at 06:29:38 UTC, Anthony wrote:
What does "__initZ" refer to?
Does this refer to automatic initialization like "this()"?
Almost, it's the static initializer for that struct, which is
omitted because you apparently
On Wednesday, 1 July 2020 at 05:33:48 UTC, H. S. Teoh wrote:
On Wed, Jul 01, 2020 at 05:04:28AM +, Anthony via
Digitalmars-d-learn wrote: [...]
auto str_utf8 = str.toUTF8();
bson_error_t error
auto bson = bson_new_from_json(cast(const
uint8_t*)str_utf8.ptr, -1,
);
I get a "Program
bson_t* bson_new_from_json(in char* data, long len, bson_error_t*
error);
string str_utf8 = "{\"a\":1}";
bson_error_t error;
auto bson = bson_new_from_json(str_utf8.ptr, str_utf8.length,
);
You have a wrong declaration for bson_error_t too.
On Wednesday, 1 July 2020 at 05:09:47 UTC, Cym13 wrote:
On Wednesday, 1 July 2020 at 05:04:28 UTC, Anthony wrote:
I'm trying to convert this c function:
bson_t *bson_new_from_json (const uint8_t *data, ssize_t len,
bson_error_t *error);
Into a D function. This is my attempt:
extern(C) {
I'm trying to convert this c function:
bson_t *bson_new_from_json (const uint8_t *data, ssize_t len,
bson_error_t *error);
Into a D function. This is my attempt:
extern(C) {
struct bson_t;
struct bson_error_t;
bson_t* bson_new_from_json(const uint8_t* data, long len,
On Wednesday, 1 July 2020 at 05:04:28 UTC, Anthony wrote:
I'm trying to convert this c function:
bson_t *bson_new_from_json (const uint8_t *data, ssize_t len,
bson_error_t *error);
Into a D function. This is my attempt:
extern(C) {
struct bson_t;
struct bson_error_t;
bson_t*
On Wed, Jul 01, 2020 at 05:04:28AM +, Anthony via Digitalmars-d-learn wrote:
[...]
> auto str_utf8 = str.toUTF8();
> bson_error_t error
>
> auto bson = bson_new_from_json(cast(const uint8_t*)str_utf8.ptr, -1,
> );
>
>
> I get a "Program exited with code -11" message.
> Does anyone know what
40 matches
Mail list logo
