Re: UDAs on enum members
On Wednesday, 13 July 2016 at 11:57:21 UTC, Tomer Filiba wrote:
It would be really nice if I could put UDAs on enum members as
well, e.g.,
enum MyEnum {
@("SOM") SomeMember,
@("ANO") AnotherMemberWithAVeryLongName,
}
I can think of many reasons why that would be desired, but the
concrete one is the following: I have an interchangeable data
format, and my enum might gain members over time. I don't care
about the value of the member, so I don't want to number them
myself, but I can't control where users would choose to place
the new member, so they might cause renumbering of existing
members, breaking the interchangeable format.
So what I wanted is to assign each member a "short stable name"
that would be used to serialize the value (using my own
dump/load functions)... But I had to resort to a long, ugly
switch statement, mapping members to their names and vice
versa. The dumping function uses final-switch, so you won't
forget to update it, but the loading one can't (it takes a
string) so it would be easy to people to forget.
Given that UDAs can be used practically everywhere (including
struct/union members), is there an objection to make them legal
on enum members as well?
And while we're on the subject, why can't enums have methods?
At the risk of sounding as if I like Java (I don't :) ), it's a
really nice language feature. Back to our example:
enum MyEnum {
@("SOM") SomeMember,
@("ANO") AnotherMemberWithAVeryLongName;
string dump() {
... // `this` is a value, not a ref here
}
static MyEnum load(string name) {
...
}
}
Basically just allow a semicolon at the end of the members,
after which methods could appear. Adding members or whatever
else Java has is an overkill -- just use a struct for that. But
instead of lots of dumpMyEnum(MyEnum e)/loadMyEnum(string s)
pairs, you could write myMember.dump()/MyEnum.load(s)
-tomer
Here how I implement it
struct EnumArray(E, V)
{
nothrow @safe:
public:
struct Entry
{
E e;
V v;
}
private:
enum isEntryType(T) = is(Entry == T);
enum size = EnumMembers!E.length;
V[size] _values;
public:
this(T...)(T aValues)
if (allSatisfy!(isEntryType, T))
{
foreach (ref Entry i; aValues)
_values[i.e] = i.v;
}
V opIndex(E aEnum) const
{
return _values[aEnum];
}
V opIndexAssign(V aValue, E aEnum)
{
return _values[aEnum] = aValue;
}
V opDispatch(string aEnumName)() const
{
import std.conv : to;
enum e = aEnumName.to!E;
return _values[e];
}
version (none)
V opDispatch(string aEnumName)(V aValue)
{
import std.conv : to;
enum e = aEnumName.to!E;
return _values[e] = aValue;
}
E getEnum(V aValue, E aDefault = E.min)
{
foreach (i; EnumMembers!E)
{
if (_values[i] == aValue)
return i;
}
return aDefault;
}
@property:
size_t length() const
{
return size;
}
}
unittest // EnumArray
{
enum EnumTest
{
one,
two,
max
}
alias EnumTestInt = EnumArray!(EnumTest, int);
EnumTestInt testInt = EnumTestInt(
EnumTestInt.Entry(EnumTest.one, 1),
EnumTestInt.Entry(EnumTest.two, 2),
EnumTestInt.Entry(EnumTest.max, int.max)
);
assert(testInt.one == 1);
assert(testInt.two == 2);
assert(testInt.max == int.max);
assert(testInt[EnumTest.one] == 1);
assert(testInt[EnumTest.two] == 2);
assert(testInt[EnumTest.max] == int.max);
assert(testInt.getEnum(1) == EnumTest.one);
assert(testInt.getEnum(2) == EnumTest.two);
assert(testInt.getEnum(int.max) == EnumTest.max);
assert(testInt.getEnum(3) == EnumTest.one); // Unknown ->
return default min
alias EnumTestString = EnumArray!(EnumTest, string);
EnumTestString testString = EnumTestString(
EnumTestString.Entry(EnumTest.one, "1"),
EnumTestString.Entry(EnumTest.two, "2"),
EnumTestString.Entry(EnumTest.max, "int.max")
);
assert(testString[EnumTest.one] == "1");
assert(testString[EnumTest.two] == "2");
assert(testString[EnumTest.max] == "int.max");
assert(testString.getEnum("1") == EnumTest.one);
assert(testString.getEnum("2") == EnumTest.two);
assert(testString.getEnum("int.max") == EnumTest.max);
assert(testString.getEnum("3") == EnumTest.one); // Unknown
-> return default min
}
Pham
Working without GC
Here's my ADPCM/etc. codec library: https://github.com/ZILtoid1991/libPCM I have an intent to keep a mostly GC version (where the codecs are still noGC for minimal CPU overhead, so the best of both worlds), I'm planning an embedded version without the file operations, and one that has the file operations but don't depend on the GC. I had some attempt at this, but gave up due to the complexity of working with multiple pointers (and with pointers to pointers). Some suggestions on it? Also feel free to either suggest new codecs (G726 will be my next target).
Re: UDAs on enum members
On Sunday, 17 July 2016 at 20:51:42 UTC, Walter Bright wrote:
On 7/13/2016 4:57 AM, Tomer Filiba wrote:
It would be really nice if I could put UDAs on enum members as
well, e.g.,
enum MyEnum {
@("SOM") SomeMember,
@("ANO") AnotherMemberWithAVeryLongName,
}
Not a bad idea. It's been asked for before.
And while we're on the subject, why can't enums have methods?
At the risk of
sounding as if I like Java (I don't :) ), it's a really nice
language feature.
Back to our example:
enum MyEnum {
@("SOM") SomeMember,
@("ANO") AnotherMemberWithAVeryLongName;
string dump() {
... // `this` is a value, not a ref here
}
static MyEnum load(string name) {
...
}
}
Basically just allow a semicolon at the end of the members,
after which methods
could appear. Adding members or whatever else Java has is an
overkill -- just
use a struct for that. But instead of lots of dumpMyEnum(MyEnum
e)/loadMyEnum(string s) pairs, you could write
myMember.dump()/MyEnum.load(s)
struct MyEnum {
@("SOM") enum SomeMember = 0;
@("ANO") enum AnotherMemberWithAVeryLongName = 1;
string dump() {
... // `this` is a value, not a ref here
}
static MyEnum load(string name) {
...
}
}
Not as nice, but gets the job done. But adding a new aggregate
type comes with a lot of baggage. I'm not convinced the
complexity is worth the benefit, which seems minor.
If it's a simple rewrite rule then there is no complexity. I
don't see how adding UDA's to enums is a new aggregate type(it's
still an enum).
The problem with such rewrites by the user is that the structs do
not behave as enums and so all the mechanisms that enums have
won't work. This creates problems, bugs, kludges, etc.
Maybe the problem is that the implementation of UDA's is not
expressive enough to modify in a simple way? So fixing the code
to make it do what it should have done in the first place is
where the complexity lies?
Having UDA's are as useful as having them. How do you know how
useful they can be until it is done? I have several perfectly
valid use cases for them, and the hacks are 10x much work and may
break some code that depends them actually being enum's.
You should realize that what you see as minor is not necessarily
minor and what you think is not beneficial is only your relative
opinion about yourself. What would be more helpful is for you to
state what criteria you would need to actually put in the effort
to implement the new features rather than stating opinions that
only shut down progress.
Just remember there are at least 10's of thousands of D users and
your experiences with writing D code is only one small aspect.
Many D users that come from different backgrounds will have
different understandings and different approaches to how they
will write *their* code and what they expect. While you owe them
nothing, it would be nice to at least acknowledge their view as
relevant. If something is a theoretical contradiction, that is
one thing, and it must be proved so... but is something is simply
not done out of priority, laziness, convenience, etc then that is
another.
If dmd is properly written then the complexity of adding new
features should be compartmentalized and relatively localized.
While one can never predict the ramifications of adding new
features(both good and bad), I think this is why there are
experimental versions of dmd? New features should not be looked
upon with disdain but be welcomed. The potential issues and
complexity that seem to be brought up can be mitigated with the
proper approaches.
Re: Editor recommendations for new users.
On Thursday, 31 August 2017 at 23:20:52 UTC, Jerry wrote: On Wednesday, 30 August 2017 at 22:42:40 UTC, Moritz Maxeiner wrote: On Wednesday, 30 August 2017 at 21:30:44 UTC, Jerry wrote: The install requirement is arbitrary, and why 20MB? It just seems like you are trying to advertise that program for some reason. Because of the programs recommended until that post nothing was below that while meeting the other requirements (there were others in the same range, vim being one). The (later) DlangIDE recommendation, however, lowered that to about ~5MB (beating both my recommendation and vim in the process). It's one of the most useless requirements in that list though. That depends on OP's use case. The only reason people mention install size is to boast about it. I disagree. I think he just didn't want to install something like Visual Studio which takes 10+ GB. I don't know and don't want to speculate. My personal implicit assumption is only that as this is the general NG, not the learn NG, that OP has good reasons as to why that's a requirement (on the learn NG I would've asked for the reasons first before recommending anything myself, though that's beside the point). It is relevant, shit, even with a shitty laptop you can upgrade the hdd and then it becomes a non-issue anyways. Your argument implicitly assumed a specific reason (albeit a generally sensible one) as to why low install size was a (must) requirement (physical storage limitations being only one possible reason; shared devices with fixed disk quotas or devices owned by the university with certain policies being other possibilities). That is why I didn't (and don't) think it as relevant to the specific point about being as low as possible I was making. Fancy way of agreeing with me, not sure what you are even going on about anymore if you agree. I provided an explanation why I dismissed your argument as irrelevant to the point I was making. That does not mean I agree with you.
Re: Editor recommendations for new users.
On Wednesday, 30 August 2017 at 22:42:40 UTC, Moritz Maxeiner wrote: On Wednesday, 30 August 2017 at 21:30:44 UTC, Jerry wrote: On Sunday, 27 August 2017 at 18:08:52 UTC, Moritz Maxeiner wrote: The requirements are rather vague, you can interpret it in a number of ways. The sensible interpretation imho is "as low an install footprint as possible while still fulfilling the other requirements". I'm not aware of anything below ~20MB install footprint that fulfills the other requirements, but I'd be interested if you know any. The install requirement is arbitrary, and why 20MB? It just seems like you are trying to advertise that program for some reason. Because of the programs recommended until that post nothing was below that while meeting the other requirements (there were others in the same range, vim being one). The (later) DlangIDE recommendation, however, lowered that to about ~5MB (beating both my recommendation and vim in the process). It's one of the most useless requirements in that list though. The only reason people mention install size is to boast about it. I think he just didn't want to install something like Visual Studio which takes 10+ GB. I wouldn't consider 200MB gigantic in comparison to 20MB cause there is literally no difference of use for me. The thread is about OP's requirements. So replace me with anyone. You'd have to have a really shitty laptop for it to be an issue. Not relevant. It is relevant, shit, even with a shitty laptop you can upgrade the hdd and then it becomes a non-issue anyways. Your argument implicitly assumed a specific reason (albeit a generally sensible one) as to why low install size was a (must) requirement (physical storage limitations being only one possible reason; shared devices with fixed disk quotas or devices owned by the university with certain policies being other possibilities). That is why I didn't (and don't) think it as relevant to the specific point about being as low as possible I was making. Fancy way of agreeing with me, not sure what you are even going on about anymore if you agree.
Re: Compiler scalability. Question inspired by OOM errors seen by Crystal language
On Thursday, 31 August 2017 at 17:39:35 UTC, H. S. Teoh wrote: This is just one example off the top of my head; I'm sure there are plenty of others that we can come up with once we break free of the C++ mold of thinking of templates as "copy-n-paste except substitute X with Y". Another example that just occurred to me is the various recursive templates in std.meta for manipulating AliasSeq's. There is actually no need for the compiler to instantiate anything at all, except perhaps for the final result. By treating the AliasSeq as an in-compiler data type with compile-time operations performed on it, the compiler ought to be able to evaluate the template without needing to instantiate anything past the first level of recursion. T That is a good example and it is one where we could maybe deduce what is doing on. However the classification of a template (rather the deduction of unused intanciations) actually requires us to instantiate the template. Because we cannot predict to what it might evaluate given specific parameters. For this to work we have to produce all possible instantiation behaviors of a template, and deduplicate this set. Which happens to be infinite, in most cases. Even predicting if the set of instantiations can be finite is essentially an instance of the halting problem. I've worked on this for some time until I realized that I was fighting without gaining ground. It would end up a myriad of special cases and would be impossible to maintain. Considering that the current template system which does not try anything smart is already fiendishly complicated, it'd rather not introduce an even more complicated template-instance-shape-predictor which will probably only work on the simplest of cases and is not guaranteed to bring wins that would justify the time it'll take to implement it. TL;DR The change to optimize certain groups of templates will require MASSIVE amounts of work and is unlikely to pay for itself.
Re: Events in D
On Thursday, 31 August 2017 at 19:36:00 UTC, kinke wrote:
On Wednesday, 30 August 2017 at 15:35:57 UTC, bitwise wrote:
-What if I want an event to lock a shared mutex of the
enclosing object, without storing a pointer to that mutex
inside the event itself (and every single other event in the
object)?
-What if I want an event to call a method of the enclosing
object when a handler is added (without keeping a pointer to
it inside the actual event)?
So in essence, you'd like something like this to work, right?
struct Event(alias __parent, Handler) {
enum parentHasLock = __traits(compiles, __parent.lock());
...
void opCall()(Parameters!Handler args)
{
static if (parentHasLock)
__parent.lock();
...
}
}
struct Host1 {
Event!Handler onChanged;
Event!Handler onClosed;
}
and have the compiler internally instantiate something like
Event!(/* parent type */ Host1, /* .offsetof in parent in order
to deduce the __parent address from Event's &this */ 0, Handler)
Event!(Host1, N, Handler)
Something like that ;)
I played around with this idea while trying to create a library
implementation of properties for C++. `offsetof` in C++ is unsafe
though, which I think was due to how multiple inheritance works.
It was only recently allowed by the standard, with limitations
that make it all but useless:
See restrictions on "standard layout class"
http://www.cplusplus.com/reference/cstddef/offsetof/
IMO though, this path is still fraught with peril, even if it
works in D. The declaration of an event would have to be very
noisy, and full of extra template parameters that only existed to
supplement the underlying hack. And it still wouldn't allow
invocation of host object code, without even more painful bloat.
Interesting performance changes over time in Kostyas benchmarks
Kostya has updated his benchmarks today and moved from: gdc 5.2.0 to 6.3.0 LDC 0.15.2 beta1 to 1.4.0-beta1 (LLVM 4.0.1) https://github.com/kostya/benchmarks/commit/73e0cb0e755f8e45d79fd2083b217d107e1185a9 The results are interesting to see as there over a year and half development between versions. LDC seems to have slowed slightly in some benchmarks. GDC shows a more steady improvement. The most noticeable jumps are the Json encoding what is a direct result from the library improvements, where we see results drop van 25 -> 8 and 27 -> 7 ( but a large increase in memory usage ). Brainfuck v2.0 -| D Gdc | 3.05| 1.4 | +| D Gdc | 2.61| 1.4 | -| D Ldc | 2.02| 0.9 | +| D Ldc | 2.85| 1.0 | mandel.b -| D Gdc | 29.49 | 2.4 | +| D Gdc | 27.40 | 2.4 | -| D Ldc | 24.90 | 1.4 | +| D Ldc | 31.21 | 1.8 | Base64 -| D Gdc | 2.52| 33.3| +| D Gdc | 3.04| 54.1| -| D Ldc | 3.14| 53.1| +| D Ldc | 2.01| 54.4| Json -| D Gdc Fast | 0.34| 226.7 | +| D Gdc Fast | 0.35| 234.1 | -| D Gdc | 25.86 | 926.1 | +| D Gdc | 8.89| 1357.2 | -| D Ldc | 27.23 | 919.6 | +| D Ldc | 7.13| 1357.0 | Matmul -| D Gdc | 2.33| 73.0| +| D Gdc | 2.30| 73.0| -| D Ldc | 2.01| 68.9| +| D Ldc | 2.17| 73.0| Havlak -| D Gdc | 31.79 | 197.6 | +| D Gdc | 24.98 | 451.6 | -| D Ldc | 25.15 | 214.9 | +| D Ldc | 22.41 | 467.9 | As we see with the json results, massive speed differences can be hiding ( in exchange for more memory consumption ). Unfortunately, he has not updated DMD but i expect that we may see the same jump in the Json test. The Havlok results stand out a lot with twice the increase in memory but a relative low gain ( vs the memory increase ). The LLVM results surprised with LLVM 4.0.1 not showing much improvement and resulting in noticeable slower times in several tests.
Re: Events in D
On Wednesday, 30 August 2017 at 15:35:57 UTC, bitwise wrote:
-What if I want an event to lock a shared mutex of the
enclosing object, without storing a pointer to that mutex
inside the event itself (and every single other event in the
object)?
-What if I want an event to call a method of the enclosing
object when a handler is added (without keeping a pointer to it
inside the actual event)?
So in essence, you'd like something like this to work, right?
struct Event(alias __parent, Handler) {
enum parentHasLock = __traits(compiles, __parent.lock());
...
void opCall()(Parameters!Handler args)
{
static if (parentHasLock)
__parent.lock();
...
}
}
struct Host1 {
Event!Handler onChanged;
Event!Handler onClosed;
}
and have the compiler internally instantiate something like
Event!(/* parent type */ Host1, /* .offsetof in parent in order
to deduce the __parent address from Event's &this */ 0, Handler)
Event!(Host1, N, Handler)
Re: Compiler scalability. Question inspired by OOM errors seen by Crystal language
On Thu, Aug 31, 2017 at 04:36:41PM +, Stefan Koch via Digitalmars-d wrote: > On Wednesday, 30 August 2017 at 16:34:13 UTC, H. S. Teoh wrote: > > > > The CTFE problem will be fixed soon, once Stefan Koch finishes his > > newCTFE engine. > > > > Templates are still an area where a lot of improvement can be made. > > But Stefan has indicated interest in visiting this area in the > > compiler after the newCTFE project is done. So eventually we'll get > > there. > > > > > > T > > Yes that is true. > However since I've just taken a full-time job I cannot say when it > will be finished. > > As for templates I have chosen to work around the issue entirely and > integrate type-manipulation and introspection abilities with ctfe. > (Which is inherently more scalable then templates) I think D's conception of templates, which IMO goes beyond C++'s (conceptually, anyway, the current implementation is not too different fundamentally), can be implemented in a much better way that makes it more scalable. C++ sees templates as code stencils to be instantiated with the given template arguments, i.e., copy-n-paste the stencil and substitute template parameters with the given arguments. D's templates for the most part still retains that, and certainly the current implementation essentially just follows the C++ model. But IMO there's an important conceptual difference: D sees template parameters not so much as parameters for code stencils to be copy-n-pasted, but as *compile-time* parameters to a function / set of declarations. I.e., they are parameters that are known at compile-time rather than runtime. The distinction is subtle but IMO important, because it allows us to break out of the C++ mold of copy-n-paste-this-stencil that is one of the causes of template scalability problems (pass too many different template arguments, and you get massive code bloat, one copy per instantiation). By treating template arguments as arguments known at compile-time instead, the compiler can get smarter with when to copy-n-paste a declaration, and when to just evaluate the template with the argument without actually instantiating anything (no copying of AST nodes, etc.). A common example is a templated linked-list container, where much of the linked-list pointer manipulation code is actually independent of the type of the contained data. The compiler really only needs to generate distinct copies of the code when the data itself is being manipulated; all the other code can be shared between template instantiations. This is just one example off the top of my head; I'm sure there are plenty of others that we can come up with once we break free of the C++ mold of thinking of templates as "copy-n-paste except substitute X with Y". Another example that just occurred to me is the various recursive templates in std.meta for manipulating AliasSeq's. There is actually no need for the compiler to instantiate anything at all, except perhaps for the final result. By treating the AliasSeq as an in-compiler data type with compile-time operations performed on it, the compiler ought to be able to evaluate the template without needing to instantiate anything past the first level of recursion. T -- "How are you doing?" "Doing what?"
Re: Events in D
On Tuesday, 29 August 2017 at 05:10:25 UTC, bitwise wrote:
I needed some C# style events, so I rolled my own.
The following is my current event implementation. I was able to
make it thread safe by including an optional spin-lock. Of
course, that extra spinlock has to be included in every single
event, which has a pointlessly high memory cost, even when no
handlers are attached to the event. Also, having this event call
it's host class back when events are added/removed would require
even MORE wasted memory by storing extra delegates. I've
thoroughly explored the idea of a library-implemented event, and
the downsides are not fixable.
struct Event(Handler, bool atomic = false)
if(is(Handler == delegate) && is(ReturnType!Handler == void))
{
Handler[] _handlers;
static if(atomic)
{
Spinlock _lock;
@disable this(this);
}
ref auto opOpAssign(string op, H)(H handler)
if(op == "+")
{
static if(atomic) auto lk = lock(_lock);
_handlers ~= toDelegate(handler);
return this;
}
ref auto opOpAssign(string op, H)(H handler)
if(op == "-")
{
static if(atomic) auto lk = lock(_lock);
auto del = toDelegate(handler);
foreach(ref handler; _handlers)
{
if(handler == del) {
_handlers = _handlers.remove(&handler -
_handlers.ptr);
break;
}
}
return this;
}
void opCall()(Parameters!Handler args)
{
static if(atomic)
{
Handler[] tmp;
if(_handlers.length <= 64)
{
auto lk = lock(_lock);
size_t sz = _handlers.length * Handler.sizeof;
tmp = cast(Handler[])(alloca(sz)[0..sz]);
tmp[] = _handlers[];
}
else
{
auto lk = lock(_lock);
tmp = _handlers.dup;
}
foreach(ref handler; tmp)
handler(args);
}
else
{
foreach(ref handler; _handlers)
handler(args);
}
}
bool opCast(T : bool)() {
static if(atomic) auto lk = lock(_lock);
return _handlers.length != 0;
}
void clear() {
static if(atomic) auto lk = lock(_lock);
_handlers.length = 0;
}
bool empty() {
static if(atomic) auto lk = lock(_lock);
return _handlers.length == 0;
}
}
Re: Compiler scalability. Question inspired by OOM errors seen by Crystal language
On Wednesday, 30 August 2017 at 16:34:13 UTC, H. S. Teoh wrote: The CTFE problem will be fixed soon, once Stefan Koch finishes his newCTFE engine. Templates are still an area where a lot of improvement can be made. But Stefan has indicated interest in visiting this area in the compiler after the newCTFE project is done. So eventually we'll get there. T Yes that is true. However since I've just taken a full-time job I cannot say when it will be finished. As for templates I have chosen to work around the issue entirely and integrate type-manipulation and introspection abilities with ctfe. (Which is inherently more scalable then templates)
Re: newCTFE Status August 2017
On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote: [ ... ] Hi Guys, many stabilty fixed have happened and as a result the new preview-build is green on the auto-tester and project tester. However it might still produce !!invalid code!! if a certain combination of features triggers a case I have overlooked! -- you have been warned :) (then again that is the case with every compiler . (except maybe CompCert ?)) the preview builds are available here: https://nightlies.dlang.org/dmd-newCTFE/
Re: Symbols missing, unmangle!
On Thursday, 31 August 2017 at 14:51:59 UTC, Mike Wey wrote: On 30-08-17 23:51, Moritz Maxeiner wrote: 2) Try to get demangling of D symbols into upstream of the currently common linkers (GNU linker, gold, lld, etc.) The GNU linker and gold support demangling D symbols, so if you are on linux try adding `-L--demangle=dlang` to the dmd commandline. Neat, thanks!
Re: Symbols missing, unmangle!
On 30-08-17 23:51, Moritz Maxeiner wrote: 2) Try to get demangling of D symbols into upstream of the currently common linkers (GNU linker, gold, lld, etc.) The GNU linker and gold support demangling D symbols, so if you are on linux try adding `-L--demangle=dlang` to the dmd commandline. -- Mike Wey
Re: enum pointers or class references limitation
On 08/31/2017 01:52 AM, Nicholas Wilson wrote: I think Timon is referring to: enum int[] foo = [1,2,3]; auto bar = foo; auto baz = foo; assert(!(bar is baz)); // Passes Even better: enum int[] foo = [1,2,3]; assert(!(foo is foo)); // Passes Ali
Re: getting dcd completions for dub installed modules
On Thursday, 31 August 2017 at 13:07:22 UTC, user123 wrote: I'm using "Coedit". http://bbasile.github.io/Coedit/features_dcd.html I haven't used it in a while, but I had tried it in the past and thought it was good.
Re: getting dcd completions for dub installed modules
On Thursday, 31 August 2017 at 13:05:36 UTC, user123 wrote: On Monday, 28 August 2017 at 12:00:43 UTC, Fra Mecca wrote: On Sunday, 27 August 2017 at 14:33:24 UTC, user123 wrote: On Sunday, 27 August 2017 at 14:26:20 UTC, Fra Mecca wrote: Hi all, I was wondering how do you get dcd-server to import packages installed from dub in ~/.dub The most generic way is to use the config file: https://github.com/dlang-community/DCD#configuration-files but your editor may have a system that does the same. The one i use does this automatically for the projects lelvel 1 deps and has also a GUI to edit the path that are known by DCD. Which one are you using? I'm using "Coedit". http://bbasile.github.io/Coedit/features_dcd.html
Re: getting dcd completions for dub installed modules
On Monday, 28 August 2017 at 12:00:43 UTC, Fra Mecca wrote: On Sunday, 27 August 2017 at 14:33:24 UTC, user123 wrote: On Sunday, 27 August 2017 at 14:26:20 UTC, Fra Mecca wrote: Hi all, I was wondering how do you get dcd-server to import packages installed from dub in ~/.dub The most generic way is to use the config file: https://github.com/dlang-community/DCD#configuration-files but your editor may have a system that does the same. The one i use does this automatically for the projects lelvel 1 deps and has also a GUI to edit the path that are known by DCD. Which one are you using? I'm using "Coedit".
Re: getting dcd completions for dub installed modules
On Monday, 28 August 2017 at 12:00:43 UTC, Fra Mecca wrote: On Sunday, 27 August 2017 at 14:33:24 UTC, user123 wrote: On Sunday, 27 August 2017 at 14:26:20 UTC, Fra Mecca wrote: Hi all, I was wondering how do you get dcd-server to import packages installed from dub in ~/.dub The most generic way is to use the config file: https://github.com/dlang-community/DCD#configuration-files but your editor may have a system that does the same. The one i use does this automatically for the projects lelvel 1 deps and has also a GUI to edit the path that are known by DCD. Which one are you using? I maintain an Emacs package that handles things automatically: https://github.com/atilaneves/ac-dcd Atila
Re: D Tour is down
On Tuesday, 29 August 2017 at 08:37:23 UTC, Petar Kirov [ZombineDev] wrote: Try clearing your browser cache and try again. Yesterday I experienced the same problem, but after I cleared my cache it was gone. Can confirm, Chromium 60 on Windows and something less on Linux. On a related note, where can I make the official request to allow specifying command-line arguments when running snippets? Optionally also text via stdin. dpaste has this but is obviously being superseded.
Re: enum pointers or class references limitation
On Thursday, 31 August 2017 at 08:40:03 UTC, Dmitry Olshansky wrote: On Wednesday, 30 August 2017 at 12:28:10 UTC, Timon Gehr wrote: On 30.08.2017 11:36, Dmitry Olshansky wrote: The subj is not (any longer) supported by compiler. In fact it used to produce wrong code sometimes and now it just plainly rejects it. [..] I think the underlying reason why it does not work is that dynamic array manifest constants are messed up. I.e. class reference `enum`s are disallowed in order to avoid having to make a decision for either inconsistent or insane semantics. Well from my point of view enum is just evaluate this expression at the usage site. So any array or class instance will be created anew at the point of usage. What are the problems with enums and dynamic arrays? I think Timon is referring to: enum int[] foo = [1,2,3]; auto bar = foo; auto baz = foo; assert(!(bar is baz)); // Passes
Re: enum pointers or class references limitation
On Wednesday, 30 August 2017 at 12:28:10 UTC, Timon Gehr wrote: On 30.08.2017 11:36, Dmitry Olshansky wrote: The subj is not (any longer) supported by compiler. In fact it used to produce wrong code sometimes and now it just plainly rejects it. [..] I think the underlying reason why it does not work is that dynamic array manifest constants are messed up. I.e. class reference `enum`s are disallowed in order to avoid having to make a decision for either inconsistent or insane semantics. Well from my point of view enum is just evaluate this expression at the usage site. So any array or class instance will be created anew at the point of usage. What are the problems with enums and dynamic arrays?
Re: C++ / Why Iterators Got It All Wrong
31.08.2017 09:50, Robert M. Münch пишет: On 2017-08-29 13:23:50 +, Steven Schveighoffer said: ... In Phobos, find gives you a range where the first element is the one you searched for, and the last element is the end of the original range. But what if you wanted all the data *up to* the element instead? What if you just wanted to look at that specific element? So we need several functions that do this, and it's not always clear how to do it correctly, and it's difficult to compose one function from the other. I'm a big fan of Rebol (yes, it's far from mainstream and a dead-end these days but it has a lot of very nice ideas) and it uses the idea of a series datatype. Fruther information here: http://www.rebol.com/docs/core23/rebolcore-6.html There you do something like: 1. Return the first hit and the rest of the series my-series: "abcdefg" == "abcdefg" find my-series "b" == "bcdefg" 2. Return only the hit first find my-series "b" == #"b" 3. Return everything before the first hit copy/part my-series find my-series "d" == "abc" If you ever got used to such a thinking, writing & using more non-functional approaches, really hurts. Interesting. How is it comparable with iterators and ranges ideas?
