On Tuesday, 30 June 2020 at 12:18:14 UTC, Steven Schveighoffer
wrote:
I can see where it would be confusing, and it could probably
contain an example and clarification.
https://issues.dlang.org/show_bug.cgi?id=20997
On Wednesday, 1 July 2020 at 05:47:16 UTC, Anthony wrote:
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(con
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,
&error);
You have a wrong declaration for bson_error_t too.
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,
&error);
I get a "Program
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 d
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) {
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,
> &error);
>
>
> I get a "Program exited with code -11" message.
> Does anyone know
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* bso
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,
bson_error_
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 easy
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, w
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 definition
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 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?
wri
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 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: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
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, in
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 NonEmptyOrScopeBlo
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 = [1,
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
>
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 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 thin
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 set
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 cod
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 (w
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 sh
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 f
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 P
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 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 mysel
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
> spaw
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 C
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 core.thre
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 they
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 i
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 ini
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 cal
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 ScopeGuardSta
41 matches
Mail list logo
