Re: Static foreach bug?
On Thursday, 6 September 2018 at 15:56:50 UTC, Jonathan M Davis wrote: However, since attributes are applied to functions, and __gshared is for variables, it really wouldn't make sense to have @gshared, and by that same token, it wouldn't make sense to have @ctlocal. I don't see any reason why @gshared/@ctlocal (with or without '@')could not be restricted to variables, just like @nogc is restricted to functions. Regards, Dechcaudron
Re: Static foreach bug?
On Wednesday, 5 September 2018 at 11:39:31 UTC, Jonathan M Davis wrote: Conceptually, what Timon is talking about doing here is to add an attribute to symbols declared within a static foreach where that attribute indicates that the symbol is temporary (or at least scoped to a particular iteration of the loop). So, saying that it's "local" as __local would makes perfect sense. It's local to that iteration of the loop. And there may very well be other syntaxes which would be better, but trying to overload the meaning of static even further by using it in this context would risk code breakage and would be _very_ confusing for most people. You are right, using "static" would be confusing I guess. I'm just against starting to use __keywords reserved to the compiler that maybe shouldn't be. I know we already have __gshared, though. Just what is the criteria to prepend the double underscore to a keyword? Why now just use an @attribute instead? @gshared and @ctlocal would fit better in the D style, IMO. Rgds, Dechcaudron
Re: Static foreach bug?
On Wednesday, 5 September 2018 at 10:45:20 UTC, Jonathan M Davis wrote: Too many people already think that the point of static is to just make something be done at compile time (which is actually a pretty terrible reason to use static) without adding that sort of thing into the confusion. Well, "static" in English means something that does not change (so do constant and immutable, but that's another story). One could argue that using static for function-scope variables with extended lifespan and for variables shared between instances of a class is more misleading. But since virtually every language out there uses them for that purpose, I understand we want to go with it. But then again, "static if" and "static foreach" make sense to me. And since all enums are compile time constants by definition, "static enum" may be a good way to tell them apart, although I do agree that it is far from ideal. I understand that the syntax for CT if and foreach blocks is not going to be changed for good reasons now, but was something like "CTif" considered at the time? I know it doesn't "look" good as is, but maybe some small variation could have done the trick. Rgds, Dechcaudron
Re: Static foreach bug?
On Tuesday, 4 September 2018 at 19:50:27 UTC, Timon Gehr wrote: The only blocker is finding a good syntax. How does "static enum" sound?
ExpressionTuple is referenced in the specs, but doesn't seem to be defined
See, for instance, definition https://dlang.org/spec/class.html#class_properties. If it is defined anywhere, I cannot seem to find it.
Re: Having trouble compiling D on Ubuntu 16.10
On Sunday, 30 October 2016 at 11:40:01 UTC, Mike Parker wrote: On Sunday, 30 October 2016 at 11:25:30 UTC, Dechcaudron wrote: Anybody has any idea why this is happening? Is the only solution to downgrade to Ubuntu 16.04 to be able to work in the meantime? Thanks beforehand :) Try adding `-fPIC -defaultlib=libphobos2.so` to your dmd.conf. And see the following links: http://forum.dlang.org/thread/tppsgztsbsdrtkpcb...@forum.dlang.org https://issues.dlang.org/show_bug.cgi?id=5278 Thanks Mike, changing dmd.config did the trick. I'll learn the details from the discussion you linked.
Having trouble compiling D on Ubuntu 16.10
Hey there community, some weeks ago I upgraded from 16.04 to 16.10, but it wasn't until now that I realized I can't develop with D anymore due to an error in the linking stage of the compilation process. dmd seems to be doing its job just fine, compiling with the -c flag does not produce any warnings or errors that should not be there. But when I move on to the linking stage with the instruction that dmd uses itself: cc app.o -o app -m64 -L/usr/lib/x86_64-linux-gnu -Xlinker --export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm -lrt -ldl I get a neverending ocean of errors that look pretty much all like these: /usr/bin/ld: app.o: relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24b_55a.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24c_3b4.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24f_4a2.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC Anybody has any idea why this is happening? Is the only solution to downgrade to Ubuntu 16.04 to be able to work in the meantime? Thanks beforehand :)
Re: struct dynamic allocation error
On Thursday, 15 September 2016 at 21:21:12 UTC, Steven
Schveighoffer wrote:
You need to destroy structs by passing them by reference.
Passing a pointer just destroys the pointer.
In this example, you can destroy what b points at (and call its
destructor) via:
destroy(*b);
However, this will not fix the issue. This is because the
memory block is not marked as being destroyed already (so it
will run the dtor again). Class instances have a feature
whereby when you call destroy it marks the memory block as
already having the destructor run. Structs do not have this
feature. Classes can afford to store extra metadata, structs
cannot.
So the true fix here is to avoid allocating in the destructor
(which is a no-no for heap-allocated items). This may work, it
may not:
writefln("a is %s", a);
That makes it work. Thanks a lot! I thought the GC knew what had
already been destroyed, though. Thanks for letting me know that
only works for classes, that'll spare me a lot of trouble. Having
the destructor be run twice can be a bit of a hassle, but it's
nothing I can't find a workaround for.
Thank you all who replied! I'm sorry I chose the General room
instead of the Learn one. I really thought this was some kind of
bug (although it's pretty obvious it would've been reported by
someone else if it was).
struct dynamic allocation error
I believe there is some kind of weird issue that won't allow for
struct instances to be dynamically allocated in a proper way via
the 'new' keyword. It does actually allocate them and return a
valid pointer to operate the instances, but whenever the program
is exited I get the following exception:
core.exception.InvalidMemoryOperationError@src/core/exception.d(693): Invalid
memory operation
Calling 'destroy' on the returned pointer only seems to set it to
null, but it definitely doesn't call the destructor, neither does
it prevent said exception from being raised. Code to reproduce:
```
import std.conv;
import std.stdio;
struct Foo
{
int a;
this(int a)
{
this.a = a;
}
~this()
{
writeln("a is " ~ to!string(a));
}
}
void main()
{
Foo a = Foo(5);
Foo* b = new Foo(10);
writeln("Allocation complete");
destroy(b); //Does nothing
//Destructor for a is called
}
```
Re: Google's code ownership
On Wednesday, 29 June 2016 at 20:06:18 UTC, Seb wrote: How about doing something similar for Phobos? On a related note Facebook open-sourced it's "mention-bot" [2] that could be helpful in case no owners are defined. I second it. Hopefully this will turn out in a shorter review process for Phobos' PRs
Re: Telegram Supergroup as an alternative to IRC
On Friday, 17 June 2016 at 12:53:49 UTC, sigod wrote: I think it's wrong to suggest to replace IRC with Telegram. Instead, let's use Telegram as other means of communication. Sure, that's what I meant. Also, does anyone knows who has control over @dlang (https://telegram.me/dlang) channel? No idea. It's dead, sadly. We can probably contact the admin if we push hard enough.
Re: Telegram Supergroup as an alternative to IRC
On Thursday, 16 June 2016 at 17:22:47 UTC, Adam D. Ruppe wrote: What clients are you using? You might look into another one and there's also the bots on the D irc that can help with other things, like ".note somebody the bot will give them this message when they are next active" I think chat things accumulate too many features though... they lose their value if they aren't simple, I prefer email for anything more complex than throw-away lines. Telegram is dead simple. Things like straight mentioning a user, "complex" in IRC if you don't have a proper client, can be done in telegram with a right click. I understand many of you won't be interested. For the rest, the supergroup is already up. Just enter https://telegram.me/dlangTelegram We're only two people so far, but don't push it, these things take time. For me, it's way more convenient to use Telegram than any IRC. Cheers!
Telegram Supergroup as an alternative to IRC
Hey there community, I've been using D for the last couple of months already. I usually have to drop by the IRC to ask some fast questions and so on, but IRC and its clients' limitations make it kind of a pain to communicate through it. If anybody uses Telegram around here, its Desktop client would prove an amazing alternative and its supergroups can host up to 5000 people. I understand there are some major differences, but all in all I understand the advantages outweight the cons. Mentions, for example, are way easier to use, as well as replies, link and media sharing... So, anybody willing to join me? Even if it's 3 people in the beggining, it'll be alright. Just send a message to @Dechcaudron from Telegram and I'll answer so we can assemble the group :D
