Re: OT: Bad translations
On Wednesday, September 26, 2018 11:15:01 PM MDT Ali Çehreli via Digitalmars-d wrote: > A delicious Turkish desert is "kabak tatlısı", made of squash. Now, it > so happens that "kabak" also means "zucchini" in Turkish. Imagine my > shock when I came across that desert recipe in English that used > zucchini as the ingredient! :) Was it any good? ;) - Jonathan M Davis
Re: D IDE
On 09/26/2018 08:23 PM, Nick Sabalausky (Abscissa) wrote: On 09/05/2018 01:34 PM, ShadoLight wrote: I sometimes wonder if the Vim/Emacs 'affectionados' spend so much time mastering their editors (which by all accounts have a steep learning curve), that they forgot that IDE development did not stagnate after they left! I sometimes wonder similar things about Vim/Emacs users, too ;) A lot of people use Vim/Emacs plus a full IDE. I use IntelliJ for work. I also use Vim. Vim is much better when I know my APIs, and it's exceptional at applying transformations to a block of text. IntelliJ is much better when I'm using an API I'm unfamiliar with. Sometimes I'll switch back and forth editing the same file -- I'll hack something together in Vim and then use IntelliJ to quickly find and fix errors. For D, unfortunately, I haven't gotten an IDE to work yet. Not with any appreciable degree of autocomplete. So I stick with Vim pretty much entirely. But don't forget, not all non-IDE people are Vim/Emacs. And just like IDE development, plain-editor development didn't stagnate either. Many non-IDE users (like me) use editors that are far more contemporary than Vim/Emacs and *don't* have that learning curve. Pretty much all advanced features in a text editor have a learning curve. Kind of unavoidable; we're asking text editors to do complex things. GUI editors can offer *less* of a learning curve, and they can offer advice better, but they can't eliminate it entirely. And for that matter, sometimes I get the impression that IDE users think non-IDE editors are far less capable than they really are. For the most part, "IDE" mostly just means: editor + GUI-based buildsystem + debugger. Autocomplete, highlighting errors, semantic code navigation, and displaying extra semantic information are other IDE features that text editors tend to lack. On the other hand, I've seen projects billing themselves as IDEs when they were pretty much just a tree view for files in the project, a GtkSourceView, and a build button.
Re: Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
On Wednesday, 26 September 2018 at 21:25:07 UTC, Steven Schveighoffer wrote: ... Object.factory is a really old poorly supported type of reflection. I would not depend on it for anything. Roger that. Will avoid :) You are better off using your own registration system. As far as choosing the design for your problem, you can use: auto obj = typeid(obj).create(); which is going to work better, and doesn't require a linear search through all modules/classes like Object.factory. How does this work? The language reference states that typeid(Type) returns "an instance of class TypeInfo corresponding to Type". (https://dlang.org/spec/expression.html#typeid_expressions) But then the TypeInfo class doesn't seem to have a .create() method, or at least not one in the documentation: https://dlang.org/phobos/object.html#.TypeInfo It looks like what I want, so it might be very helpful. If it were me, I'd probably instead implement a clone virtual method. This way if any custom things need to occur when copying the data, it can be handled. -Steve I'm thinking I want to avoid the virtual method in this case, for reasons I wrote about in my response to Adam (https://forum.dlang.org/post/zovficijurwhuurrr...@forum.dlang.org). But I think it's probably a good suggestion in most cases; I suspect that most of the time wanting to write a "deepCopy" method is going to be in response to some problem that will respond well to just virtualizing the method. Thanks for the advice!
Re: OT: Bad translations
A delicious Turkish desert is "kabak tatlısı", made of squash. Now, it so happens that "kabak" also means "zucchini" in Turkish. Imagine my shock when I came across that desert recipe in English that used zucchini as the ingredient! :) Ali
Re: Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
On Wednesday, September 26, 2018 10:20:58 PM MDT Chad Joan via Digitalmars- d-learn wrote: > On Wednesday, 26 September 2018 at 23:32:36 UTC, Jonathan M Davis > > wrote: > > On Wednesday, September 26, 2018 3:24:07 PM MDT Adam D. Ruppe > > > > via Digitalmars-d-learn wrote: > >> Object.factory kinda sux and I'd actually like to remove it > >> (among other people). There's no plan to actually do that, but > >> still, just on principle I want to turn people away. > > > > While there may not currently be plans to be remove it, as > > there _are_ plans to add ProtoObject as the new root class > > underneath Object, at some point here, it's likely that a large > > percentage of classes won't have anything to do with Object, so > > relying on Object.factory to be able to construct class Objects > > in general isn't likely to be a viable path in the long term - > > though presumably it would work for a code base that's written > > specifically with it in mind. > > > > Personally, I'm hoping that we eventually get to the point > > where Walter and Andrei are willing to outright deprecate > > Object itself, but I expect that ProtoObject will have to have > > been in use for a while before we have any chance of that > > happening. Either way, I think that it's clear that most code > > bases should go with a solution other than Object.factory if at > > all reasonably possible. > > > > - Jonathan M Davis > > That's interesting! Thanks for mentioning. > > If you don't mind, what are the complaints regarding Object? Or > can you link me to discussions/issues/documents that point out > the shortcomings/pitfalls? > > I've probably run into a bunch of them, but I realize D has come > a long way since that original design and I wouldn't be surprised > if there's a lot more for me to learn here. I can point you to the related DIP, though it's a WIP in progress https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIP.md There are also these enhancement requests for removing the various member functions from Object (though they're likely to be superceded by the DIP): https://issues.dlang.org/show_bug.cgi?id=9769 https://issues.dlang.org/show_bug.cgi?id=9770 https://issues.dlang.org/show_bug.cgi?id=9771 https://issues.dlang.org/show_bug.cgi?id=9772 Basically, the problems tend to come in two areas: 1. Because of how inheritance works, once you have a function on a class, you're forcing a certain set of attributes on that function - be it type qualifiers like const or shared or scope classes like pure or @safe. In some cases, derived classes can be more restricted when they override the function (e.g. an overide can be @safe when the original is @system), but that only goes so far, and when you use the base class API, you're stuck with whatever attributes it has. Regardless, derived classes can't be _less_ restrictive. In fact, the only reason that it's currently possible to use == with const class references in D right now is because of a hack. The free function opEquals that gets called when you use == on two class references actually casts away const so that it can then call the member function opEquals (which doesn't work with const). So, if the member function opEquals mutates the object, you actuall get undefined behavior. And because Object.opEquals defines both the parameter and invisible this parameter as mutable, derived classes have to do the same when they override it; otherwise, they'd be overloading it rather than overriding it. Object and its member functions really come from D1 and predate all of the various attributes in D2 - including const. But even if we could just add all of the attributes that we thought should be there without worrying about breaking existing code, there would be no right answer. For instance, while in the vast majority of cases, opEquals really should be const, having it be const does not work with types that lazily initialize some members (since unlike in C++, D does not have backdoors for const - when something is const, it really means const, and it's undefined behavior to cast away const and mutate the object). So, having Object.opEquals be const might work in 99% of cases, but it wouldn't work in all. The same could be said for other attributes such as pure or nothrow. Forcing a particular set of attributes on these functions on everyone is detrimental. And honestly, it really isn't necessary. Having them on Object comes from a Java-esque design where you don't have templates. With proper templates like D2 has, there normally isn't a reason to operate on an Object. You templatize the code rather than relying on a common base class. So, there's no need to have Object.toString in order have toString for all classes or Object.opEquals to have opEquals for all classes. Each class can define it however it sees fit. Now, once a particular class in a hierarchy has defined a function like opEquals or toString, that affects any classes derived from it, but then only the
Re: Silicon Valley D Meetup - September 27, 2018 - "Introduction to the D Programming Language and Q"
On 09/26/2018 04:50 PM, Nicholas Wilson wrote: the next one is a week too late for me to go to while I'm in town for a conference. Are you saying you can give a status report on October 18? Our schedule is flexible. ;) Let's arrange over email. Ali
Re: Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
On Wednesday, 26 September 2018 at 21:24:07 UTC, Adam D. Ruppe
wrote:
On Wednesday, 26 September 2018 at 20:41:38 UTC, Chad Joan
wrote:
I'm implementing a deep-copy method for a tree of templated
class instances. As part of this, I need some way to copy
each node.
[...]
that isn't already handled by their deepCopy method.
I would strongly suggest just using that virtual method and
having the child classes override it, then you call it from any
of them and get the right result.
The tree nodes are potentially very diverse, but the tree
structure itself will be very homogeneous. I'm writing a parser
generator backend and the tree is expressions of various
operators (Sequence, OrderedChoice, UnorderedChoice, Repetition,
etc). I'm trying to keep it simple: everything is an expression,
and expressions can contain other expressions (though some are
always leaves in the tree). At some level, if I let things
implement their own deepCopy, then it means there are potentially
other classes and state out there to iterate that the rest of the
code doesn't know about. That could be bad, and expressions
shouldn't contain anything besides expressions!
This probably contrasts a lot with other use-cases, like
serialization. And I wouldn't be surprised if things change
later on and I end up with some kind of auxiliary virtual copy
function that does what you suggest, but is specifically for
handling special out-of-band mutable reference data that the
expressions might need to carry someday.
I suppose I've never considered just how hard/impossible it is to
have a generic way to copy things. Well, maybe a little bit at
various points, but not this bad ;) There are so many dimensions
to the problem and it seems like the context and requirements
will always be really important. So it can be made simple under
the right constraints (ex: everything is immutable!), but the
constraints are always different depending on the requirements
(ex: ... but in this hypothetical, we need mutability, so then
it's gotta happen a different way).
Object.factory kinda sux and I'd actually like to remove it
(among other people). There's no plan to actually do that, but
still, just on principle I want to turn people away.
But even as you can see, the implementation is lacking and it
isn't great design anyway - the interface with virtual methods
does better work. It also wouldn't work in ctfe anyway,
object.factory relies on runtime stuff.
Good to know!
I don't think I've even used it much, if at all. I suppose I
won't miss it if it goes ;)
If Object.factory is incapable of this, is there some other
CTFE-friendly way to copy templated class instances?
I think you can copy typeinfo().init and then call
typeinfo().defaultConstructor - this is iirc what
Object.factory does, but once you already have the typeinfo you
can use it directly and bypass the string lookup.
I'm having trouble looking this up. Could you link me to the
docs for this?
But you'd really be better off with a virtual copy method. I
say those string factory things should only be used if you are
starting with a string, like deserialization.
interface Copyable {
Copyable copy();
}
class Whatever(T) : Copyable {
Whatever!T copy() {
auto c = new Whatever!T();
c.tupleof = this.tupleof;
return c;
}
}
that kind of method. the template implements the interface so
little boilerplate and it works and can be customized etc and
fits in well. If you call it from the interface, you get an
instance of the interface (tho note since it is virtual, the
underlying type is still what you need). If you call from the
child static type, you get it right back. Yay, fits liskov and
works!
As above, I think this might be a very clean and effective
solution for a different class of use-cases :) I'll keep it in
mind though.
If I have to, I can probably make these things register
themselves in some list of delegates that can be used to
instantiate the correct class. Or something like that. But I
am hoping that there is a better way that involves less
boilerplate.
that's not a terrible idea if you need delegates keyed to
strings...
Right. At some level I just need a function that I can call like
this:
auto newThing = makeAnother(originalThing);
and perhaps makeAnother(...) can just lookup originalThing's
classname in an associative array of delegates. Or maybe I can
just hash some part of originalThing's type information. I can
put all of the ugly registration boilerplate into a mixin
template and somehow force that to always be mixed-into any
descendant classes. OK, it's probably getting too far into the
weeds now, but it seems doable and I'll reach for that if I need
to.
...
Things at least seem much more clear already. Thanks a bunch!
Re: Silicon Valley D Meetup - September 27, 2018 - "Introduction to the D Programming Language and Q"
On 09/26/2018 05:40 PM, viniarck wrote: > Is there any > chance of future virtual meetups transmissions as well? We've been doing that for some meetups. It works well if the meetup is in presentation format, which not all are. Sometimes we just get together for chat and it doesn't make sense to record those live. But yes, we will do it when it makes sense. Ali
Re: Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
On Wednesday, 26 September 2018 at 23:32:36 UTC, Jonathan M Davis wrote: On Wednesday, September 26, 2018 3:24:07 PM MDT Adam D. Ruppe via Digitalmars-d-learn wrote: Object.factory kinda sux and I'd actually like to remove it (among other people). There's no plan to actually do that, but still, just on principle I want to turn people away. While there may not currently be plans to be remove it, as there _are_ plans to add ProtoObject as the new root class underneath Object, at some point here, it's likely that a large percentage of classes won't have anything to do with Object, so relying on Object.factory to be able to construct class Objects in general isn't likely to be a viable path in the long term - though presumably it would work for a code base that's written specifically with it in mind. Personally, I'm hoping that we eventually get to the point where Walter and Andrei are willing to outright deprecate Object itself, but I expect that ProtoObject will have to have been in use for a while before we have any chance of that happening. Either way, I think that it's clear that most code bases should go with a solution other than Object.factory if at all reasonably possible. - Jonathan M Davis That's interesting! Thanks for mentioning. If you don't mind, what are the complaints regarding Object? Or can you link me to discussions/issues/documents that point out the shortcomings/pitfalls? I've probably run into a bunch of them, but I realize D has come a long way since that original design and I wouldn't be surprised if there's a lot more for me to learn here.
Re: D IDE
On 09/26/2018 10:33 PM, Shachar Shemesh wrote: On 27/09/18 04:54, Nick Sabalausky (Abscissa) wrote: Man, I wish SOO much, that was true of my favorite editor (Programmer's Notepad 2). I love it, but it's a windows thing and has some issues under wine. Can you elaborate on what issues? Merely downloading and installing seem to work fine. The main big one was that the option to use MRU order for Ctrl-Tab file-switching doesn't work. Instead, it ends up being some kind of semi-random order. I know that doesn't sound like a big deal, but it turned out to be a HUGE drain on both my mental focus and my productivity. (I habitually rely *very* heavily on Ctrl-Tabbing between two main documents I'm focusing on - or occasionally three. And the MRU behavior is very deeply ingrained in my muscle memory. Technically, I could save-and-close all other documents, but that also messes with my workflow and mental processes.) I love the program so much that I tried to work through it (and filed bug reports, etc), but ultimately it proved to be too much of a problem. Another, smaller, issue was that it doesn't start up nearly as fast under wine (still WAY faster than most IDEs though.) Although that's admittedly very minor, and not a deal-breaker. Although it's near-instant startup was one of the things I loved about it back on windows. I seem the remember there being one other quirk I ran into (maybe related to find or replace?), but it's been awhile so I don't remember exactly what that was.
Re: D IDE
On 09/05/2018 01:34 PM, ShadoLight wrote: I sometimes wonder if the Vim/Emacs 'affectionados' spend so much time mastering their editors (which by all accounts have a steep learning curve), that they forgot that IDE development did not stagnate after they left! I sometimes wonder similar things about Vim/Emacs users, too ;) But don't forget, not all non-IDE people are Vim/Emacs. And just like IDE development, plain-editor development didn't stagnate either. Many non-IDE users (like me) use editors that are far more contemporary than Vim/Emacs and *don't* have that learning curve. And for that matter, sometimes I get the impression that IDE users think non-IDE editors are far less capable than they really are. For the most part, "IDE" mostly just means: editor + GUI-based buildsystem + debugger. If you are referring to coding where you are developing from scratch, then sure - I agree. You will be doing a lot of coding before building the 1st time. No offence, but if that's how someone's developing a new project, then they're doing things very, VERY wrong. *Always* start a new project with some kind of "Hello world" or some such which builds and runs *right from the start*, and then grow it from there. I'm speaking from decades of experience doing things BOTH ways. Ultimately, any time you do a large amount of coding (writing and/or editing) in between working builds (no matter if it's the beginning or middle of development) then you're just asking for problems. For another example IDEs are also in some ways a 'standard' inside big organizations in a way that any editor cannot be - the lowest barrier of entry to get new members up to speed in a team. And for some languages (Java/C#) you give up a lot by not developing inside an IDE. In fact, for Java and C#, the appeal/power of the languages is in many ways directly related to the IDE! I used to do a lot of Java and C#. I even used to be a big fan of C# back in the day (and I still don't really hate it or anything). But speaking from experience here: It's not so much that the IDEs are a great feature of those languages, it's more like (especially with Java) the IDEs are used as a crutch to help mitigate major faults in the languages. But that said, there are examples of IDEs that really do provide a genuine benefit beyond mitigating language problems. These tend to be domain-specific to at least some extent. Some examples that come to mind are the old "RAD"-style tools for GUI apps (like Delphi and VB6). Or Unity3D for either games or Flash-like multimedia.
Re: D IDE
On 27/09/18 04:54, Nick Sabalausky (Abscissa) wrote: Man, I wish SOO much, that was true of my favorite editor (Programmer's Notepad 2). I love it, but it's a windows thing and has some issues under wine. Can you elaborate on what issues? Merely downloading and installing seem to work fine.
Re: D IDE
On 09/05/2018 01:05 PM, Ecstatic Coder wrote: For instance, even for contract work, I use Geany for all my developments. And a portable IDE like Geany is especially useful when developping *crossplatform* C++ multimedia applications which must be edited and tested both on Windows, MacOS and Linux. Man, I wish SOO much, that was true of my favorite editor (Programmer's Notepad 2). I love it, but it's a windows thing and has some issues under wine. :( Closest I've found since I moved to Linux is a custom-configured KDevelop, but it's still just not as good :( Heck, maybe I'll give Geany a go... Personally I use Geany even for Unity game development, as Unity allows to define which editor should be used to show the erroneous line of C# code when double clicking onto an error message. I didn't know Unity could do that! I've just been manually going to the file/line of the error. I'll have to check into that! (Unity's relative unfriendliness to non-Unity-oriented workflows has always been one of my biggest pain points with it. Most normal IDEs aren't as problematic as Unity in those ways. Even the Unity's own team had to go to some significant lengths just to make automated builds possible, and even then, I'm not sure you can use just any off the shelf CI system. I really hate vertical integration.)
Re: Silicon Valley D Meetup - September 27, 2018 - "Introduction to the D Programming Language and Q"
On Wednesday, 26 September 2018 at 22:56:01 UTC, Ali Çehreli wrote: We are excited to have our first meetup at our new permanent location at MBRDNA: Mercedes-Benz Research and Development North America 309 North Pastoria Avenue Sunnyvale, CA (It the cafeteria at the main entrance.) Pizza and soft drinks will be served. Please RSVP responsibly ;) so that we will know how much food to order. You can start showing up earlier at 6:30pm. (If you don't want to register at Meetup.com, just send me an email at acehr...@yahoo.com) We will have a round table style meetup to talk about anything D but the main topic can be an introduction to the D language. Ali Hi, Ali. First, thanks a lot for all you've done for the D community. Since I'm not based in the US I wish I could attend via Internet. Is there any chance of future virtual meetups transmissions as well? Cheers.
Re: Silicon Valley D Meetup - September 27, 2018 - "Introduction to the D Programming Language and Q"
On Wednesday, 26 September 2018 at 22:57:47 UTC, Ali Çehreli wrote: Link at Meetup: https://www.meetup.com/D-Lang-Silicon-Valley/events/slbvflyxmbkc/ Ali Ah rats, this one is two weeks too early and the next one is a week too late for me to go to while I'm in town for a conference.
Re: Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
On Wednesday, September 26, 2018 3:24:07 PM MDT Adam D. Ruppe via Digitalmars-d-learn wrote: > Object.factory kinda sux and I'd actually like to remove it > (among other people). There's no plan to actually do that, but > still, just on principle I want to turn people away. While there may not currently be plans to be remove it, as there _are_ plans to add ProtoObject as the new root class underneath Object, at some point here, it's likely that a large percentage of classes won't have anything to do with Object, so relying on Object.factory to be able to construct class Objects in general isn't likely to be a viable path in the long term - though presumably it would work for a code base that's written specifically with it in mind. Personally, I'm hoping that we eventually get to the point where Walter and Andrei are willing to outright deprecate Object itself, but I expect that ProtoObject will have to have been in use for a while before we have any chance of that happening. Either way, I think that it's clear that most code bases should go with a solution other than Object.factory if at all reasonably possible. - Jonathan M Davis
Re: Calling nested function before declaration
On 09/26/2018 03:46 PM, Jonathan wrote:
I can't see how the current behavior is at all better or to be preferred
unless it is faster to compile? What is the reason for it being how it is?
void outerFunction()
{
func();
auto lock = acquireLock();
void nested()
{
}
}
Inside `nested`, can you refer to `lock`? It's in lexical scope, so yes.
It hasn't been initialized yet. What value should it have? Presumably
its standard uninitialized value.
This is likely to cause a lot of confusion.
The standard ways of dealing with this:
* Reorder the declarations.
* Make the functions non-nested.
* Get rid of mutual recursion.
* Use a delegate.
* Do a method-to-method-object refactoring.
Re: Silicon Valley D Meetup - September 27, 2018 - "Introduction to the D Programming Language and Q"
Link at Meetup: https://www.meetup.com/D-Lang-Silicon-Valley/events/slbvflyxmbkc/ Ali
Silicon Valley D Meetup - September 27, 2018 - "Introduction to the D Programming Language and Q"
We are excited to have our first meetup at our new permanent location at MBRDNA: Mercedes-Benz Research and Development North America 309 North Pastoria Avenue Sunnyvale, CA (It the cafeteria at the main entrance.) Pizza and soft drinks will be served. Please RSVP responsibly ;) so that we will know how much food to order. You can start showing up earlier at 6:30pm. (If you don't want to register at Meetup.com, just send me an email at acehr...@yahoo.com) We will have a round table style meetup to talk about anything D but the main topic can be an introduction to the D language. Ali
Calling nested function before declaration
This code fails to compile: ("undefined identifier fun")
void main() {
fun();
void fun() {}
}
Having the call after the declaration works:
void main() {
void fun() {}
fun();
}
Is this how it is intended to work?
It seems goofy that this works:
void main() {
void fun2() {}
void fun() {
fun2()
}
fun();
}
But this fails to compile: ("undefined identifier fun2")
void main() {
void fun() {
fun2()
}
void fun2() {}
fun();
}
What if I wanted this?
void main() {
void fun2() {fun();}
void fun() {fun2();}
fun();
}
I can't see how the current behavior is at all better or to be
preferred unless it is faster to compile? What is the reason for
it being how it is?
Re: Updating D beyond Unicode 2.0
On Sunday, September 23, 2018 2:49:39 PM MDT Walter Bright via Digitalmars-d wrote: > There's a reason why dmd doesn't have international error messages. My > experience with it is that international users don't want it. They prefer > the english messages. It reminds me of one of the reasons that Bryan Cantrill thinks that many folks use Linux - they want to be able to google their stack traces. Of course, that same argument would be a reason to use C/C++ rather than switching to D, but having an error be in a format that's more common and therefore more likely to have been posted somewhere where you might be able to find a discussion on it and therefore maybe be able to find the solution for it can be valuable - and that's without even getting into all of the translation issues discussed elsewher in this thread. And it's not like compiler error messages - or programming speak in general - are really traditional English anyway. - Jonathan M Davis
Re: Updating D beyond Unicode 2.0
On 09/26/2018 01:43 PM, Walter Bright wrote: Don't most languages have a Romanji-like representation? Yes, a lot of languages that don't use the Latin alphabet have standard transcriptions into the Latin alphabet. Standard transcriptions into ASCII are much less common, and newer Unicode versions include more Latin characters to better support languages (and other use cases) using the Latin alphabet.
Re: Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
On 9/26/18 4:41 PM, Chad Joan wrote: Hi all, I'm implementing a deep-copy method for a tree of templated class instances. As part of this, I need some way to copy each node. I want to avoid code that does things like casting objects into byte arrays and then copying raw bytes; I want all operations to be memory safe things that I can use at compile-time. So I planned to make all of these have default constructors and use Object.factory to at least create the correct instance type at the destination. The classes can implement auxiliary copy methods if they need to copy anything that isn't already handled by their deepCopy method. But I ran into a problem: Object.factory doesn't seem to be compatible with templated classes. Object.factory is a really old poorly supported type of reflection. I would not depend on it for anything. You are better off using your own registration system. As far as choosing the design for your problem, you can use: auto obj = typeid(obj).create(); which is going to work better, and doesn't require a linear search through all modules/classes like Object.factory. If it were me, I'd probably instead implement a clone virtual method. This way if any custom things need to occur when copying the data, it can be handled. -Steve
Re: Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
On Wednesday, 26 September 2018 at 20:41:38 UTC, Chad Joan wrote:
I'm implementing a deep-copy method for a tree of templated
class instances. As part of this, I need some way to copy each
node.
[...]
that isn't already handled by their deepCopy method.
I would strongly suggest just using that virtual method and
having the child classes override it, then you call it from any
of them and get the right result.
Object.factory kinda sux and I'd actually like to remove it
(among other people). There's no plan to actually do that, but
still, just on principle I want to turn people away.
But even as you can see, the implementation is lacking and it
isn't great design anyway - the interface with virtual methods
does better work. It also wouldn't work in ctfe anyway,
object.factory relies on runtime stuff.
If Object.factory is incapable of this, is there some other
CTFE-friendly way to copy templated class instances?
I think you can copy typeinfo().init and then call
typeinfo().defaultConstructor - this is iirc what Object.factory
does, but once you already have the typeinfo you can use it
directly and bypass the string lookup.
But you'd really be better off with a virtual copy method. I say
those string factory things should only be used if you are
starting with a string, like deserialization.
interface Copyable {
Copyable copy();
}
class Whatever(T) : Copyable {
Whatever!T copy() {
auto c = new Whatever!T();
c.tupleof = this.tupleof;
return c;
}
}
that kind of method. the template implements the interface so
little boilerplate and it works and can be customized etc and
fits in well. If you call it from the interface, you get an
instance of the interface (tho note since it is virtual, the
underlying type is still what you need). If you call from the
child static type, you get it right back. Yay, fits liskov and
works!
If I have to, I can probably make these things register
themselves in some list of delegates that can be used to
instantiate the correct class. Or something like that. But I
am hoping that there is a better way that involves less
boilerplate.
that's not a terrible idea if you need delegates keyed to
strings...
Re: Updating D beyond Unicode 2.0
On 9/26/18 4:43 PM, Walter Bright wrote: But expanding it seems of vanishingly little value. Note that each thing that gets added to D adds weight to it, and it needs to pull its weight. Nothing is free. It may be the weight is already there in the form of unicode symbol support, just the range of the characters supported isn't good enough for some languages. It might be like replacing your refrigerator -- you get an upgrade, but it's not going to take up any more space because you get rid of the old one. I would like to see the PR before passing judgment on the heft of the change. The value is simply in the consistency -- when some of the words for your language can be valid symbols but others can't, then it becomes a weird guessing game as to what is supported. It would be like saying all identifiers can have any letters except `q`. Sure, you can get around that, but it's weirdly exclusive. I claim complete ignorance as to what is required, it hasn't been technically laid out what is at stake, and I'm not bilingual anyway. It could be true that I'm completely misunderstanding the positions of others. -Steve
Re: Updating D beyond Unicode 2.0
On Wednesday, 26 September 2018 at 20:43:47 UTC, Walter Bright wrote: I don't see a scenario where someone would be learning D and not know English. Non-English D instructional material is nearly non-existent. http://ddili.org/ders/d/
Re: Updating D beyond Unicode 2.0
On 9/26/2018 5:46 AM, Steven Schveighoffer wrote: Does this need a DIP? Feel free to write one, but its chances of getting incorporated are remote and would require a pretty strong rationale that I haven't seen yet.
Is there a way to use Object.factory with templated classes? Or some way to construct templated classes given RTTI of an instance?
Hi all,
I'm implementing a deep-copy method for a tree of templated class
instances. As part of this, I need some way to copy each node.
I want to avoid code that does things like casting objects into
byte arrays and then copying raw bytes; I want all operations to
be memory safe things that I can use at compile-time. So I
planned to make all of these have default constructors and use
Object.factory to at least create the correct instance type at
the destination. The classes can implement auxiliary copy
methods if they need to copy anything that isn't already handled
by their deepCopy method.
But I ran into a problem: Object.factory doesn't seem to be
compatible with templated classes.
Here is an example:
import std.stdio;
class Root(T)
{
T x;
}
class Extended(T) : Root!T
{
T y;
}
void main()
{
Root!int foo = new Extended!int();
auto name = foo.classinfo.name;
writefln("foo's name is '%s'", name);
// foo's name is 'main.Extended!int.Extended'
Object obj = Object.factory(name);
writefln("Is obj null? %s", obj is null);
Root!int bar = cast(Root!int)obj; // Still going to be null.
writefln("Is bar null? %s", obj is null);
//bar.x = 3; // crash!
}
I had a look at Object.factory. It seems very simple. Perhaps
too simple. I think this might be a dead end. Have I missed
something? Can it actually handle templates somehow, but I just
don't know how to calculate the correct string to hand it?
If Object.factory is incapable of this, is there some other
CTFE-friendly way to copy templated class instances?
If I have to, I can probably make these things register
themselves in some list of delegates that can be used to
instantiate the correct class. Or something like that. But I am
hoping that there is a better way that involves less boilerplate.
Thanks!
- Chad
Re: Updating D beyond Unicode 2.0
On 9/26/2018 5:46 AM, Steven Schveighoffer wrote: This is a non-starter. We can't break people's code, especially for trivial reasons like 'you shouldn't code that way because others don't like it'. I'm pretty sure Walter would be against removing Unicode support for identifiers. We're not going to remove it, because there's not much to gain from it. But expanding it seems of vanishingly little value. Note that each thing that gets added to D adds weight to it, and it needs to pull its weight. Nothing is free. I don't see a scenario where someone would be learning D and not know English. Non-English D instructional material is nearly non-existent. dlang.org is all in English. Don't most languages have a Romanji-like representation? C/C++ have made efforts in the past to support non-ASCII coding - digraphs, trigraphs, and alternate keywords. They've all failed miserably. The only people who seem to know those features even exist are language lawyers.
Re: Updating D beyond Unicode 2.0
On 9/25/2018 11:50 PM, Shachar Shemesh wrote: This sounded like a very compelling example, until I gave it a second thought. I now fail to see how this example translates to a real-life scenario. Also, there are usually common ASCII versions of city names, such as Cologne for Köln.
Weird compilation error only as static library
Hi! I am getting this error when compiling my code as a static library. It works fine as an executable. I have no idea what's happening. Has someone seen something like this before? What could be different? This is the error: /usr/include/dmd/druntime/import/core/stdc/stdint.d(159,26): Error: undefined identifier cpp_ulong /usr/include/dmd/druntime/import/core/sys/posix/sys/types.d(109,11): Error: undefined identifier c_long ../../../.dub/packages/libuv-1.20.3/libuv/deimos/libuv/uv.d(367,2): Error: mixin `deimos.libuv.uv.uv_stream_s.UV_STREAM_FIELDS!()` error instantiating It's a small library with libuv as the only dependency. It works fine compiling it's own example, but fails when I compile it as a dub dependency.
Re: Natvis, CV8, dAssocArray
On Wednesday, 26 September 2018 at 18:06:48 UTC, Rainer Schuetze wrote: On 26/09/2018 09:45, Void-995 wrote: On Wednesday, 26 September 2018 at 07:37:26 UTC, Rainer Schuetze wrote: [...] Makes sense. I've tried to move them to "member" but they obviously did not point anywhere, which is logical if that is just "typedef". Is there any way to expose real key/values from backend or get them via some Natvis magic? That's basically only thing that stops from using MS C/C++ plug-in for debugging from VS Code. Natvis support may be valuable for Linux and Mac as well, as they've added minimal support for Natvis to GDB and LLDB via their plug-in. Not sure if you can define new structs in NatVis, but the void pointer points to rt.aaA.Impl which contains an array of Buckets, and their entry member points to a std::pair<__key_t,__val_t>. Thanks, I did something like that meanwhile: https://www.dropbox.com/s/h70m4v63jxp79g1/d.natvis?dl=0 Need to take a look at other ideas as well. Of course it won't hurt to clean that up, but this one works.
[Issue 6410] Few common exceptions in std.exception
https://issues.dlang.org/show_bug.cgi?id=6410 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WONTFIX --- Comment #7 from Mathias LANG --- Given the discussion, the nature of the report (enhancement) and the lack of activity, I think it's time to close this one as WONTFIX. --
Re: Natvis, CV8, dAssocArray
On 26/09/2018 09:45, Void-995 wrote:
On Wednesday, 26 September 2018 at 07:37:26 UTC, Rainer Schuetze wrote:
On 25/09/2018 22:08, Void-995 wrote:
I almost finished my -gc for Natvis experiment (to use MS C++
Debugger from VS Code, fully translating type names from what comes
from DMD frontend to valid C++ type name so Natvis works), but then I
encountered dAssocArray, which has form of: void* as CodeView
structure member, KeyType __key_t and ValueType __val_t as nested types.
As for someone who just found about CodeView today: what is nested
type, what is the deal with void*, what to do with __key_t and
__val_t to get values.
Nested types are types declared in another type, e.g. in C++
struct dAssocArray
{
typedef int __key_t;
typedef long __val_t;
void* ptr;
};
The AA data structures are not exposed by the compiler, but the mago
debugger rebuilds them from these types.
Makes sense. I've tried to move them to "member" but they obviously did
not point anywhere, which is logical if that is just "typedef". Is there
any way to expose real key/values from backend or get them via some
Natvis magic? That's basically only thing that stops from using MS C/C++
plug-in for debugging from VS Code. Natvis support may be valuable for
Linux and Mac as well, as they've added minimal support for Natvis to
GDB and LLDB via their plug-in.
Not sure if you can define new structs in NatVis, but the void pointer
points to rt.aaA.Impl which contains an array of Buckets, and their
entry member points to a std::pair<__key_t,__val_t>.
[Issue 19269] New: Cannot throw C++ exceptions from D
https://issues.dlang.org/show_bug.cgi?id=19269
Issue ID: 19269
Summary: Cannot throw C++ exceptions from D
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pro.mathias.l...@gmail.com
When trying to throw `core.stdcpp.exception : exception` from D (the
std::exception definition), DMD complains with:
```
foo.d(2): Error: can only throw class objects derived from Throwable, not type
core.stdcpp.exception.std.exception
```
Code to reproduce:
```
import core.stdcpp.exception;
void main () { throw new exception(); }
```
--
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268 Radu Racariu changed: What|Removed |Added CC||radu.raca...@gmail.com --- Comment #2 from Radu Racariu --- See https://github.com/dlang/dmd/pull/8253 for related discussion. This needs a fix. --
Re: Forums intermittently going down?
On Wed, Sep 26, 2018 at 02:33:27AM +, Vladimir Panteleev via Digitalmars-d wrote: > On Wednesday, 26 September 2018 at 01:52:31 UTC, H. S. Teoh wrote: [...] > > but basically, any column used in a WHERE clause is a candidate for > > indexing. > > Yep, I think we're past that already. > > The last issue I ran into was subscriptions. Some people seem to be > creating subscriptions to collect and email them frequently, sometimes > on every post - not that those work well, because the forum stops > emailing people as soon as they have unread messages in their > subscriptions, but they still get saved to the queue. Still, the > longer the forum was online, the more subscriptions have accumulated, > and every new post resulted in all those subscriptions getting > triggered. Now, every time a subscription with an email action was > triggered, we had to check if there are any unread messages in their > subscription queue, and there can be a lot of messages in there - > thus, this caused something like an O(m*n) database operation (with > the underlying database implementation also not having a constant > execution time of course). I fixed this by limiting the check to the > first unread post instead of reusing a function to count all unread > messages in the subscription queue: [...] Hmm. I wonder if it might help if you separated the subscription queue into its own database. You're right that SQLite locks the entire database when writing, so if there's a lot of write activity going on, readers will be frequently blocked. Separating part of the data into its own DB may help increase the parallelizability of the system. In my experience in working with SQLite, I find that generally you want to design your schema so that writes are as short as possible -- the global DB write lock can be a big bottleneck, as you said, so the less time you spend holding the write lock, the better. If it's possible to split up data for different functionalities into different DBs, that might help improve performance by avoiding waiting for the global write lock on a single DB all the time. Now glancing over your schema, I wonder if it might make a difference if you used the implicit rowId for your 'ID' fields instead of strings. The rowId in SQLite is special, because it exists for every table implicitly, is always unique, and AFAIK allows fast lookups (or faster lookups than strings, AIUI). It may not be practical to do that now, given the large amount of data already stored with string IDs, but it could potentially make a difference. Of course, you may need to map it to strings somewhere, so I'm not sure if the tradeoff is worth it, but it might be instructive to experiment with it in an offline system to see if you could gain some performance that way. T -- We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
Re: Warn on unused imports?
On 09/26/2018 02:51 AM, FeepingCreature wrote: On Wednesday, 26 September 2018 at 08:37:12 UTC, Dejan Lekic wrote: I humbly believe this does not belong to the compiler. These sort of things belong to a static code analyser TOOL. Think of checkstyle/findbugs in Java, or flake8/pep8 in Python world. I can't put it differently than this: you're simply wrong, in my opinion. It's *provably impossible* do do this statically. I think you can do some amount of it statically: * List out the symbols each module exports. * List out the symbols that appear in source code. * If you find that a module doesn't export a symbol that this code uses, recommend its deletion. * If you encounter a mixin in a module that's visible to it, assume that module is required. (Optional: require that mixin to be at module scope.) * If you encounter a mixin in the module you're analyzing, give up. So that's at least 80 modules in Phobos that you might be able to suggest not importing.
Re: Warn on unused imports?
On 27/09/2018 3:53 AM, Neia Neutuladh wrote: On 09/26/2018 12:39 AM, FeepingCreature wrote: On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg wrote: The DMD compiler is available as a library. A linter tool can be based on that. Repeating it here: the library does not have version-tagged releases. For a build system based around reproducible builds, this makes it completely unusable. It means you need to use git submodules and depend on a specific version that way. And that means you can't tell why you chose a particular revision. For those who are unaware, dmd-fe for usage as a library is completely worthless currently. So not having the tags is probably a good thing.
Re: BetterC and CTFE mismatch
On Wednesday, 26 September 2018 at 12:51:57 UTC, Steven Schveighoffer wrote: I'd suggest a bug report if one hasn't been made. -Steve I found https://issues.dlang.org/show_bug.cgi?id=19268 and I have appended my case there.
Re: Warn on unused imports?
On 09/26/2018 12:39 AM, FeepingCreature wrote: On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg wrote: The DMD compiler is available as a library. A linter tool can be based on that. Repeating it here: the library does not have version-tagged releases. For a build system based around reproducible builds, this makes it completely unusable. It means you need to use git submodules and depend on a specific version that way. And that means you can't tell why you chose a particular revision.
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
Sebastiaan Koppe changed:
What|Removed |Added
CC||m...@skoppe.eu
--- Comment #1 from Sebastiaan Koppe ---
I have similar issues. Most things from phobos don't work in CTFE when
compiling with betterC (same error in both dmd and ldc).
---
void main() {
import std.uni : toLower;
pragma(msg,"asdfBsdf".toLower);
}
---
--
[Issue 13683] More precise error message for wrong lambda
https://issues.dlang.org/show_bug.cgi?id=13683 Basile B. changed: What|Removed |Added Hardware|x86 |All OS|Windows |All --
[Issue 14217] Misleading error message: Cannot deduce function
https://issues.dlang.org/show_bug.cgi?id=14217 Basile B. changed: What|Removed |Added Hardware|x86_64 |All OS|Windows |All --
[Issue 14217] Misleading error message: Cannot deduce function
https://issues.dlang.org/show_bug.cgi?id=14217 Basile B. changed: What|Removed |Added CC||b2.t...@gmx.com --
[Issue 13683] More precise error message for wrong lambda
https://issues.dlang.org/show_bug.cgi?id=13683 Basile B. changed: What|Removed |Added CC||b2.t...@gmx.com --
Re: Then new forum moderation
On Wednesday, 26 September 2018 at 09:09:30 UTC, Kagamin wrote: On Tuesday, 25 September 2018 at 15:11:20 UTC, SashaGreat wrote: For example: If a person knows VB/Delphi and now he is trying D and have any doubt, he will need to evolve first to understand ternary before posting something, because ternary in these languages are different. You underestimate delphi programmers if you think they can't learn ternary operator. I didn't say they can't learn, and as quoted I said it's different in these languages (I mean the symbols involved). By the way, since D has inline assembler attribute, why not use it for captchas too? Because according to you: On Tuesday, 25 September 2018 at 07:43:39 UTC, Kagamin wrote: I don't think you can go into programming from absolute zero. The programmer should at least know Assembly, right? S.G.
Re: Updating D beyond Unicode 2.0
On Sunday, 23 September 2018 at 20:49:39 UTC, Walter Bright wrote: On 9/23/2018 9:52 AM, aliak wrote: There's a reason why dmd doesn't have international error messages. My experience with it is that international users don't want it. They prefer the english messages. Yes please. Keep them in english. But please, add an error code too in front of them. I'm sure if you look hard enough you'll find someone using non-ASCII characters in identifiers. It depends on what I'm developing. If I'm writing a public library I'm planning to release on github, I use english identifiers. But of course if is a piece of software for my company or for myself, I use italian identifiers. Andrea
Re: BetterC and CTFE mismatch
On Wednesday, 26 September 2018 at 12:51:57 UTC, Steven Schveighoffer wrote: So anything I do at CTFE has to be betterC as well? That is a bummer. This is an artificial, and not really intended, limitation. Essentially, CTFE has to be a real function. If it's defined, it's expected to be callable from runtime as well as CTFE. But I can't see why, if you don't call from runtime, it should matter. I think this has to do with the places betterC is enforced in the compiler. I'll try to workaround this, but I would like to see this fixed. Is there anything I can do to move this forward? I'd suggest a bug report if one hasn't been made. -Steve https://issues.dlang.org/show_bug.cgi?id=18472 is an open regression on 2.078. Doesn't cover all use cases of what Sebastiaan might want though.
Re: concurrency call to arms
On Thursday, 16 August 2018 at 20:30:26 UTC, John Belmonte wrote: These are novel control structures for managing concurrency. Combining this with cooperative multitasking and explicit, plainly-visible context switching (i.e. async/await-- sorry Olshansky) yields something truly at the forefront of concurrent programming. I mean no callbacks, almost no locking, no explicitly maintained context and associated state machines, no task lifetime obscurity, no manual plumbing of cancellations, no errors dropped on the floor, no shutdown hiccups. I'm able to write correct, robust, maintainable concurrent programs with almost no mental overhead beyond a non-concurrent program. I've written an article which attempts to expand on the ingredients making Trio + async/await effective, in the hope this paradigm can be carried elsewhere. https://medium.com/@belm0/concurrency-made-easy-d3fdb0382c58
Re: OT: Bad translations
On Wednesday, 26 September 2018 at 12:57:21 UTC, ShadoLight wrote: On Wednesday, 26 September 2018 at 02:12:07 UTC, Ali Çehreli wrote: On 09/24/2018 08:17 AM, 0xEAB wrote: > - Non-idiomatic translations of tech terms [2] [snip] English message was something like "No memory left" and the German translation was "No memory on the left hand side" :) Ali Not sure if this was not just some urban legend, but there was a delightful story back in the late 80s/early 90s about the early translation programs. They were in particular not very good at idiomatic translations, so people would play with idiomatic expressions from language X (say english) to language Y, and then back from Y to X - and then see what was returned. Apparently the expression "the spirit is willing but the flesh is weak" translated to Russian and back was returned by one such program as: "The vodka is good but the meat is rotten!" In case you missed it, this was well spreaded in the tech news last month or so: https://translate.google.fr/?hl=fr#so/en/ngoo%20m%20goon%20goob%20goo%20goo%20goo%20mgoo%20goo%20goo%20goo%20goo%20goo%20m%20goo Still progress to do.
Re: OT: Bad translations
On Wednesday, 26 September 2018 at 02:12:07 UTC, Ali Çehreli wrote: On 09/24/2018 08:17 AM, 0xEAB wrote: > - Non-idiomatic translations of tech terms [2] [snip] English message was something like "No memory left" and the German translation was "No memory on the left hand side" :) Ali Not sure if this was not just some urban legend, but there was a delightful story back in the late 80s/early 90s about the early translation programs. They were in particular not very good at idiomatic translations, so people would play with idiomatic expressions from language X (say english) to language Y, and then back from Y to X - and then see what was returned. Apparently the expression "the spirit is willing but the flesh is weak" translated to Russian and back was returned by one such program as: "The vodka is good but the meat is rotten!"
Re: BetterC and CTFE mismatch
On 9/26/18 5:08 AM, Sebastiaan Koppe wrote: On Wednesday, 26 September 2018 at 08:22:26 UTC, Simen Kjærås wrote: This is essentially an arbitrary restriction. The basic reason is if a function is compiled (even just for CTFE), it ends up in the object files, and you've asked for only betterC functions to end up in the object files. -- Simen So anything I do at CTFE has to be betterC as well? That is a bummer. This is an artificial, and not really intended, limitation. Essentially, CTFE has to be a real function. If it's defined, it's expected to be callable from runtime as well as CTFE. But I can't see why, if you don't call from runtime, it should matter. I think this has to do with the places betterC is enforced in the compiler. I'll try to workaround this, but I would like to see this fixed. Is there anything I can do to move this forward? I'd suggest a bug report if one hasn't been made. -Steve
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268 Илья Ярошенко changed: What|Removed |Added Keywords||rejects-valid --
[Issue 19268] BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268 Илья Ярошенко changed: What|Removed |Added Keywords||betterC --
[Issue 19268] New: BetterC turns off DRuntime for CTFE
https://issues.dlang.org/show_bug.cgi?id=19268
Issue ID: 19268
Summary: BetterC turns off DRuntime for CTFE
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ilyayaroshe...@gmail.com
dmd -betterC
mixin(`void foo(){}`.idup);
---
pass in DMD 2.78
fails in DMD >=2.79
/opt/compiler-explorer/dmd-2.079.0/dmd2/linux/bin64/../../src/druntime/import/object.d(4259):
Error: `TypeInfo` cannot be used with -betterC
This cause BetterC regression in mir.bitmanip and mir-cpuid. The workaround for
mir.bitmanip was added to mir-algorithm v2.0.6.
--
Re: Updating D beyond Unicode 2.0
On 9/26/18 5:54 AM, rjframe wrote:
On Fri, 21 Sep 2018 16:27:46 +, Neia Neutuladh wrote:
I've got this coded up and can submit a PR, but I thought I'd get
feedback here first.
Does anyone see any horrible potential problems here?
Or is there an interestingly better option?
Does this need a DIP?
I just want to point out since this thread is still living that there have
been very few answers to the actual question ("should I submit my PR?").
Walter did answer the question, with the reasons that Unicode identifier
support is not useful/helpful and could cause issues with tooling. Which
is likely correct; and if we really want to follow this logic, Unicode
identifier support should be removed from D entirely.
This is a non-starter. We can't break people's code, especially for
trivial reasons like 'you shouldn't code that way because others don't
like it'. I'm pretty sure Walter would be against removing Unicode
support for identifiers.
I don't recall seeing anyone in favor providing technical reasons, save
the OP.
There doesn't necessarily need to be a technical reason. In fact, there
really isn't one -- people can get by with using ASCII identifiers just
fine (and many/most people do). Supporting Unicode would be purely for
social or inclusive reasons (it may make D more approachable to
non-English speaking schoolchildren for instance).
As an only-English speaking person, it doesn't bother me either way to
have Unicode identifiers. But the fact that we *already* support Unicode
identifiers leads me to expect that we support *all* Unicode
identifiers. It doesn't make a whole lot of sense to only support some
of them.
Especially since the work is done, it makes sense to me to ask for the PR
for review. Worst case scenario, it sits there until we need it.
I suggested this as well.
https://forum.dlang.org/post/poaq1q$its$1...@digitalmars.com
I think it stands a good chance of getting incorporated, just for the
simple fact that it's enabling and not disruptive.
-Steve
[Issue 19208] std.bitmanip.swapEndian doesn't support floating point types
https://issues.dlang.org/show_bug.cgi?id=19208 Basile B. changed: What|Removed |Added Keywords||pull --- Comment #1 from Basile B. --- pull: https://github.com/dlang/phobos/pull/6720 --
Re: Updating D beyond Unicode 2.0
On 9/26/18 2:50 AM, Shachar Shemesh wrote: On 25/09/18 15:35, Dukc wrote: Another reason is that something may not have a good translation to English. If there is an enum type listing city names, it is IMO better to write them as normal, using Unicode. CityName.seinäjoki, not CityName.seinaejoki. This sounded like a very compelling example, until I gave it a second thought. I now fail to see how this example translates to a real-life scenario. City names (data, changes over time) as enums (compile time set) seem like a horrible idea. That may sound like a very technical objection to an otherwise valid point, but it really think that's not the case. The properties that cause city names to be poor candidates for enum values are the same as those that make them Unicode candidates. Hm... I could see actually some "clever" use of opDispatch being used to define cities or other such names. In any case, I think the biggest pro for supporting Unicode symbol names is -- we already support Unicode symbol names. It doesn't make a whole lot of sense to only support some of them. -Steve
[Issue 19208] std.bitmanip.swapEndian doesn't support floating point types
https://issues.dlang.org/show_bug.cgi?id=19208 Basile B. changed: What|Removed |Added CC||b2.t...@gmx.com Hardware|x86 |All OS|Windows |All Severity|enhancement |normal --
Re: Warn on unused imports?
26.09.2018 13:00, Anonymouse пишет: On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: Would just like to say that I love the idea and would use it immediately. Currently going through old code that evolved too organically, with imports too far away from where they were originally (but no longer) used. more over during refactoring it can results in recursive template instantiating. And compiler isn't helpful in resolving it.
[Issue 19267] extern(C++) cast from interface to child class returns wrong pointer value
https://issues.dlang.org/show_bug.cgi?id=19267 Atila Neves changed: What|Removed |Added Keywords||C++ --
[Issue 19267] New: extern(C++) cast from interface to child class returns wrong pointer value
https://issues.dlang.org/show_bug.cgi?id=19267
Issue ID: 19267
Summary: extern(C++) cast from interface to child class returns
wrong pointer value
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: atila.ne...@gmail.com
The code at the end with extern(C++) prints:
fooImpl @ 0x7fa6503c1000
foo @ 0x7fa6503c1008
foo @ 0x7fa6503c1008
fooImpl @ 0x7fa6503c1008
If the interface and class are extern(D) it (correctly) prints:
fooImpl @ 0x7fa6503c1000
foo @ 0x7fa6503c1008
foo @ 0x7fa6503c1008
fooImpl @ 0x7fa6503c1000
Casting from the class to the interface works in both cases and adds 8 bytes to
the pointer. Casting back from interface to the class only works for extern(D)
and fails for extern(C++): there's no way to get the original pointer back
except for manually subtracting 8 bytes.
Code to reproduce:
import core.stdc.stdio: printf;
extern(C++) interface Foo {
int foo();
}
extern(C++) class FooImpl: Foo {
override int foo() { return 42; }
}
void main() {
auto fooImpl = new FooImpl;
printf("fooImpl @ %p\n", fooImpl);
Foo foo = fooImpl;
printf("foo @ %p\n", foo);
printf("\n");
takingFoo(foo);
}
void takingFoo(Foo foo) {
printf("foo @ %p\n", foo);
FooImpl fooImpl = cast(FooImpl) foo; // oops
printf("fooImpl @ %p\n", fooImpl);
}
--
Re: Warn on unused imports?
On Wednesday, September 26, 2018 4:46:23 AM MDT Laurent Tréguier via Digitalmars-d wrote: > From dmd's help: > ``` >-dsilently allow deprecated features >-dw show use of deprecated features as warnings > (default) >-de show use of deprecated features as errors > (halt compilation) > ``` > Deprecations are shown as warnings and not simple messages it > seems. But this is probably just a matter of wording here, so not > really relevant I think. It's definitely a matter of wording and thus arguably should be changed. For instance, if they were actually warnings, -w would turn a deprecation message into an error like -de does, and it doesn't. They're frequently called deprecation warnings, so it's no surprise that the flag would be -dw or that the help information would say that, but from the stand point of what flags like -w consider to be warnings, they're not warnings. - Jonathan M Davis
Re: dub configuration for a dependency?
On Wednesday, 26 September 2018 at 10:41:36 UTC, joshuabarnes
wrote:
By default, DerelictODE is configured to load the
double-precision version of ODE. If you want to load the
single-precision version, declare "DerelictODE_Single" as a
version in the build settings of your dub.json.
What does this actually mean?
I have
"dependencies": {
"derelict-glfw3": "~>4.0.0-beta.1",
"derelict-gl3": "~>2.0.0-beta.7",
"imageformats": "~>7.0.0",
"derelict-ode:": "~>3.0.0-b"
}
but have no idea what the above means? sadly the dub
documentation didn't seem to be much help?
From
https://code.dlang.org/package-format?lang=json#configurations
```
{
...
"name": "somepackage",
"configurations": [
{
"name": "metro-app",
"targetType": "executable",
"platforms": ["windows"],
"versions": ["MetroApp"],
"libs": ["d3d11"]
},
{
"name": "desktop-app",
"targetType": "executable",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"libs": ["d3d9"]
},
{
"name": "glut-app",
"targetType": "executable",
"versions": ["GlutApp"]
}
]
}
```
Adding `"versions": ["DerelictODE_Single"]` in your dub file
should do the trick.
Re: Warn on unused imports?
On Wednesday, 26 September 2018 at 09:25:11 UTC, Jonathan M Davis wrote: IMHO, the way that dmd currently handles deprecations works quite well overall. It simply prints a message. It's not a warning, and it's not an error. It's just a message. You can use a compiler flag to make the message go away or to turn it into an error (though in general, I'd advise against it, since then your code breaks as soon as something gets deprecated), but by default, they're just messages. From dmd's help: ``` -dsilently allow deprecated features -dw show use of deprecated features as warnings (default) -de show use of deprecated features as errors (halt compilation) ``` Deprecations are shown as warnings and not simple messages it seems. But this is probably just a matter of wording here, so not really relevant I think. Beyond that I agree with the idea of letting linters and the like point out bad practices or suspicious things such as unused imports; as a compiler's role is to compile, while a linter's role is to lint.
Re: Can I create static c callable library?
On Wednesday, 26 September 2018 at 09:54:22 UTC, John Burton wrote: Is there any documentation anywhere that deals with calling D from C? I could find plenty the other way round. I think I'll give up on the idea though, and rewrite the whole thing in D :) Rewriting it in D is a great idea ;) But for the record, much of what you've read about calling C from D applies the other way, too. You just need to write your D functions as extern(C), following the same approach to function signatures and types as you've read about, then declare the crossover functions and types in C. One gotcha to look out for is when you call a D function that allocates GC memory. In that case, you need to keep a reference to it alive on the D side. If it's only being allocated for use in C, you can call GC.addRoot [1] when you allocate the memory on the D side and GC.removeRoot [2] when you no longer need it. Also keep in mind that D variables thread-local, and if you need to access any of them in C from multiple threads they would better be declared as __gshared in D. [1] https://dlang.org/phobos/core_memory.html#.GC.addRoot [2] https://dlang.org/phobos/core_memory.html#.GC.removeRoot
dub configuration for a dependency?
By default, DerelictODE is configured to load the
double-precision version of ODE. If you want to load the
single-precision version, declare "DerelictODE_Single" as a
version in the build settings of your dub.json.
What does this actually mean?
I have
"dependencies": {
"derelict-glfw3": "~>4.0.0-beta.1",
"derelict-gl3": "~>2.0.0-beta.7",
"imageformats": "~>7.0.0",
"derelict-ode:": "~>3.0.0-b"
}
but have no idea what the above means? sadly the dub
documentation didn't seem to be much help?
Re: BetterC and CTFE mismatch
On Wednesday, 26 September 2018 at 09:08:06 UTC, Sebastiaan Koppe wrote: On Wednesday, 26 September 2018 at 08:22:26 UTC, Simen Kjærås wrote: This is essentially an arbitrary restriction. The basic reason is if a function is compiled (even just for CTFE), it ends up in the object files, and you've asked for only betterC functions to end up in the object files. -- Simen So anything I do at CTFE has to be betterC as well? That is a bummer. I'll try to workaround this, but I would like to see this fixed. Is there anything I can do to move this forward? You can call Non-BetterC function from import path. (not from the source code, but in the import path).
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: Cool that you're working on this!
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: Would just like to say that I love the idea and would use it immediately. Currently going through old code that evolved too organically, with imports too far away from where they were originally (but no longer) used.
Re: Updating D beyond Unicode 2.0
On Fri, 21 Sep 2018 16:27:46 +, Neia Neutuladh wrote:
> I've got this coded up and can submit a PR, but I thought I'd get
> feedback here first.
>
> Does anyone see any horrible potential problems here?
>
> Or is there an interestingly better option?
>
> Does this need a DIP?
I just want to point out since this thread is still living that there have
been very few answers to the actual question ("should I submit my PR?").
Walter did answer the question, with the reasons that Unicode identifier
support is not useful/helpful and could cause issues with tooling. Which
is likely correct; and if we really want to follow this logic, Unicode
identifier support should be removed from D entirely.
I don't recall seeing anyone in favor providing technical reasons, save
the OP.
Especially since the work is done, it makes sense to me to ask for the PR
for review. Worst case scenario, it sits there until we need it.
Re: Warn on unused imports?
On Wednesday, 26 September 2018 at 08:37:12 UTC, Dejan Lekic wrote: I humbly believe this does not belong to the compiler. These sort of things belong to a static code analyser TOOL. Think of checkstyle/findbugs in Java, or flake8/pep8 in Python world. I can't put it differently than this: you're simply wrong, in my opinion. It's *provably impossible* do do this statically.
Re: Can I create static c callable library?
On Tuesday, 25 September 2018 at 12:05:21 UTC, Jonathan M Davis wrote: [...] Thanks everyone. Is there any documentation anywhere that deals with calling D from C? I could find plenty the other way round. I think I'll give up on the idea though, and rewrite the whole thing in D :)
Re: Warn on unused imports?
On Wednesday, September 26, 2018 2:26:20 AM MDT Laurent Tréguier via Digitalmars-d wrote: > On Wednesday, 26 September 2018 at 01:13:11 UTC, Jonathan M Davis > > wrote: > > The way that C++ handles warnings is how I've seen most > > languages handle warnings. IMHO, the only time that anything > > along the lines of a warning makes sense is when the programmer > > is proactively running a tool to specifically ask to be > > informed of a potential type of problem where they will then go > > look at each of them individually and decide whether what the > > tool is telling them is valid or not - at which point, some of > > what the tool says will be followed, and some if it will be > > ignored. It's not something that should be run as part of a > > normal build process. If it is, then inevitably what happens is > > that either all of the warnings get "fixed" (at which point, > > they might as well have all been errors), or they all get > > ignored, meaning that you get a huge wall of them, and they're > > completely useless. As such, I really have nothing good to say > > about having any kind of warnings being built into the > > compiler. As I understand it, on the whole, Walter agrees with > > me and that he only added them in to dmd, because he was > > essentially bullied into it, and I wish that he'd never given > > in. And when you consider features like is(typeof(...)), the > > side effects of having -w are particularly bad. > > > > - Jonathan M Davis > > I would say that at least deprecations make sense as warnings > from the compiler. Deprecated stuff is something the user has to > be warned about, even if they're not using a linter, since it's > going to break at some point but should be supported for a > minimum amount of time to ensure a smooth transition. Errors are things that you _must_ fix, because your code is definitely broken. Warnings are things that you _might_ need to fix or which might actually be perfectly fine (which is why having the compiler tell you about them as part of the normal build is such a problem). Deprecations are basically delayed errors. They're something that you definitely need to fix, but you don't necessarily need to fix right now. Your code isn't broken yet, but it will be once the deprecation period ends. So, having the compiler always tell you about the deprecation isn't a problem and in fact is arguably desirable, since it's a constant reminder that you need to update your code before the deprecation period ends. IMHO, the way that dmd currently handles deprecations works quite well overall. It simply prints a message. It's not a warning, and it's not an error. It's just a message. You can use a compiler flag to make the message go away or to turn it into an error (though in general, I'd advise against it, since then your code breaks as soon as something gets deprecated), but by default, they're just messages. Unfortunately, if your build spits out a bunch of status stuff instead of just printing out actual problems, deprecation messages do sometimes get missed, which I suspect is part of why vibe.d typically does a terrible job of getting updated when something that it uses in Phobos gets deprecated, but there's only so much that can be done about that. Certainly, having deprecations result in errors like they originally did with dmd makes them untenable in general, because then simply deprecating something immediately breaks all code that uses it, and at that point, you basically can't ever deprecate anything. - Jonathan M Davis
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature
wrote:
On Tuesday, 25 September 2018 at 14:15:32 UTC, Dominikus Dittes
Scherkl wrote:
template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}
class TestException(T) : from!"std.format".FormatException?
That should work, but it's kind of a big step. In any case,
I'll never get a weird hacky template like that through code
review :)
That "weird" template is about to be added to phobos.
Since its invention one and a half year ago I use it pretty much
everywhere in my code for parameters that otherwise would require
a global import. I just wasn't sure if it would work in this
place too (that usecase never arose to me).
I don't understand, why a standard template wouldn't pass a
review.
Re: Then new forum moderation
On Tuesday, 25 September 2018 at 15:11:20 UTC, SashaGreat wrote: For example: If a person knows VB/Delphi and now he is trying D and have any doubt, he will need to evolve first to understand ternary before posting something, because ternary in these languages are different. You underestimate delphi programmers if you think they can't learn ternary operator.
Re: BetterC and CTFE mismatch
On Wednesday, 26 September 2018 at 08:22:26 UTC, Simen Kjærås wrote: This is essentially an arbitrary restriction. The basic reason is if a function is compiled (even just for CTFE), it ends up in the object files, and you've asked for only betterC functions to end up in the object files. -- Simen So anything I do at CTFE has to be betterC as well? That is a bummer. I'll try to workaround this, but I would like to see this fixed. Is there anything I can do to move this forward?
Re: Updating D beyond Unicode 2.0
On Wednesday, 26 September 2018 at 07:37:28 UTC, Shachar Shemesh wrote: The other type of answer is "it's being done in the real world". If it's in active use in the real world, it might make sense to support it, even if we can agree that the design is not optimal. Shachar Two years ago, I taked part in implementing a commerical game. It was made in C# (Unity) but I don't think that matters, since D would have faced the same thing, were it used. Anyway, the game has three characters with completely different abilites. The abilites were unique enough that it made sense to name some functions after the characters. One of the characters really has a non-ASCII character in his name, and that meant naming him differently in the code.
Re: is there something like `stm32-rs` in D?
On Wednesday, 26 September 2018 at 05:55:49 UTC, dangbinghoo wrote: On Wednesday, 26 September 2018 at 05:24:08 UTC, Radu wrote: On Wednesday, 26 September 2018 at 03:46:21 UTC, dangbinghoo wrote: hi, https://github.com/adamgreig/stm32-rs looks great, is there something like this in Dlang? thanks! --- dangbinghoo You might take a look at https://github.com/JinShil/stm32f42_discovery_demo and https://github.com/JinShil/stm32_datasheet_to_d thanks, Radu, I knew that there's a minimal D demo on STM32 exist for years. But, what I'm talking about is that rust community is doing a rust library for very production use. If you look at stm32-rs, you will found that stm32-rs is covering the whole STM32 MCU product line and making a promising peripherals library. The library was generated using CMSIS-SVD files which were maintained by MCU vendors. Anyway, I don't know what's the runtime size situation D vs rust. for those kinds of MCU devices, a runtime code size greater than 5KB may even not suitable for L0 lines MCU from ST. It's not quite clear that whether D or rust is valuable for MCU development, but C is really lacking lots of things for quick development, today MCU is interfacing more IoT modules using AT command, and deal with these string things is quite painful in C. Maybe this is an opportunity for D? Thanks! --- dangbinghoo I think you should get in touch with Mike Franklin and see what are his plans with the demo code. I know there were some blocking issues and he was working to solve them. Maybe the tool-chain and language is mature enough to revisit this project and make it production ready. I'm not an MCU expert but maybe you can join in with ideas and some insights and help boot-strap a new project.
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: I humbly believe this does not belong to the compiler. These sort of things belong to a static code analyser TOOL. Think of checkstyle/findbugs in Java, or flake8/pep8 in Python world. I think developing such tool as part of the D Language team group (GitHub) makes more sense than anything else...
Re: Warn on unused imports?
On Wednesday, 26 September 2018 at 01:13:11 UTC, Jonathan M Davis wrote: The way that C++ handles warnings is how I've seen most languages handle warnings. IMHO, the only time that anything along the lines of a warning makes sense is when the programmer is proactively running a tool to specifically ask to be informed of a potential type of problem where they will then go look at each of them individually and decide whether what the tool is telling them is valid or not - at which point, some of what the tool says will be followed, and some if it will be ignored. It's not something that should be run as part of a normal build process. If it is, then inevitably what happens is that either all of the warnings get "fixed" (at which point, they might as well have all been errors), or they all get ignored, meaning that you get a huge wall of them, and they're completely useless. As such, I really have nothing good to say about having any kind of warnings being built into the compiler. As I understand it, on the whole, Walter agrees with me and that he only added them in to dmd, because he was essentially bullied into it, and I wish that he'd never given in. And when you consider features like is(typeof(...)), the side effects of having -w are particularly bad. - Jonathan M Davis I would say that at least deprecations make sense as warnings from the compiler. Deprecated stuff is something the user has to be warned about, even if they're not using a linter, since it's going to break at some point but should be supported for a minimum amount of time to ensure a smooth transition.
Re: BetterC and CTFE mismatch
On Wednesday, 26 September 2018 at 08:06:27 UTC, Sebastiaan Koppe wrote: Right now I am building a betterC application and I would have expected to be able to use the D standard library in CTFE. It seems this is not the case. Can anyone explain why? It seems to be an arbitrary limitation. example: https://run.dlang.io/gist/8ee9456bfae061eba81c931999183e49?args=-betterC This is essentially an arbitrary restriction. The basic reason is if a function is compiled (even just for CTFE), it ends up in the object files, and you've asked for only betterC functions to end up in the object files. -- Simen
BetterC and CTFE mismatch
Right now I am building a betterC application and I would have expected to be able to use the D standard library in CTFE. It seems this is not the case. Can anyone explain why? It seems to be an arbitrary limitation. example: https://run.dlang.io/gist/8ee9456bfae061eba81c931999183e49?args=-betterC
Re: Natvis, CV8, dAssocArray
On Wednesday, 26 September 2018 at 07:37:26 UTC, Rainer Schuetze
wrote:
On 25/09/2018 22:08, Void-995 wrote:
I almost finished my -gc for Natvis experiment (to use MS C++
Debugger from VS Code, fully translating type names from what
comes from DMD frontend to valid C++ type name so Natvis
works), but then I encountered dAssocArray, which has form of:
void* as CodeView structure member, KeyType __key_t and
ValueType __val_t as nested types.
As for someone who just found about CodeView today: what is
nested type, what is the deal with void*, what to do with
__key_t and __val_t to get values.
Nested types are types declared in another type, e.g. in C++
struct dAssocArray
{
typedef int __key_t;
typedef long __val_t;
void* ptr;
};
The AA data structures are not exposed by the compiler, but the
mago debugger rebuilds them from these types.
Makes sense. I've tried to move them to "member" but they
obviously did not point anywhere, which is logical if that is
just "typedef". Is there any way to expose real key/values from
backend or get them via some Natvis magic? That's basically only
thing that stops from using MS C/C++ plug-in for debugging from
VS Code. Natvis support may be valuable for Linux and Mac as
well, as they've added minimal support for Natvis to GDB and LLDB
via their plug-in.
Re: Warn on unused imports?
On Wednesday, 26 September 2018 at 01:13:11 UTC, Jonathan M Davis wrote: IMHO, the only time that anything along the lines of a warning makes sense is when the programmer is proactively running a tool to specifically ask to be informed of a potential type of problem where they will then go look at each of them individually and decide whether what the tool is telling them is valid or not - at which point, some of what the tool says will be followed, and some if it will be ignored. - Jonathan M Davis Yeah, that's exactly how I ended up doing it, as an additional part of the -deps info. See https://github.com/dlang/dmd/pull/8740 .
Re: Updating D beyond Unicode 2.0
On 26/09/18 10:26, Dukc wrote: On Wednesday, 26 September 2018 at 06:50:47 UTC, Shachar Shemesh wrote: The properties that cause city names to be poor candidates for enum values are the same as those that make them Unicode candidates. How so? City names (data, changes over time) as enums (compile time set) seem like a horrible idea. In most cases yes. But not always. You might me doing some sort of game where certain cities are a central concept, not just data with properties. Another possibility is that you're using code as data, AKA scripting. And who says anyway you can't make a program that's designed specificially for certain cities? Sure you can. It's just very poor design. I think, when asking such questions, two types of answers are relevant. One is hypotheticals where you say "this design requires this". For such answers, the design needs to be a good one. It makes no sense to design a language to support a hypothetical design which is not a good one. The other type of answer is "it's being done in the real world". If it's in active use in the real world, it might make sense to support it, even if we can agree that the design is not optimal. Since your answer is hypothetical, I think arguing this is not a good way to code is a valid one. Shachar
Re: Natvis, CV8, dAssocArray
On 25/09/2018 22:08, Void-995 wrote:
I almost finished my -gc for Natvis experiment (to use MS C++ Debugger
from VS Code, fully translating type names from what comes from DMD
frontend to valid C++ type name so Natvis works), but then I encountered
dAssocArray, which has form of: void* as CodeView structure member,
KeyType __key_t and ValueType __val_t as nested types.
As for someone who just found about CodeView today: what is nested type,
what is the deal with void*, what to do with __key_t and __val_t to get
values.
Nested types are types declared in another type, e.g. in C++
struct dAssocArray
{
typedef int __key_t;
typedef long __val_t;
void* ptr;
};
The AA data structures are not exposed by the compiler, but the mago
debugger rebuilds them from these types.
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg wrote: The DMD compiler is available as a library. A linter tool can be based on that. Repeating it here: the library does not have version-tagged releases. For a build system based around reproducible builds, this makes it completely unusable.
Re: Updating D beyond Unicode 2.0
On Wednesday, 26 September 2018 at 06:50:47 UTC, Shachar Shemesh wrote: The properties that cause city names to be poor candidates for enum values are the same as those that make them Unicode candidates. How so? City names (data, changes over time) as enums (compile time set) seem like a horrible idea. In most cases yes. But not always. You might me doing some sort of game where certain cities are a central concept, not just data with properties. Another possibility is that you're using code as data, AKA scripting. And who says anyway you can't make a program that's designed specificially for certain cities?
[Issue 19266] Some source files names are no longer accepted
https://issues.dlang.org/show_bug.cgi?id=19266 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #1 from Rainer Schuetze --- https://github.com/dlang/dmd/pull/8741 --
[Issue 19266] New: Some source files names are no longer accepted
https://issues.dlang.org/show_bug.cgi?id=19266 Issue ID: 19266 Summary: Some source files names are no longer accepted Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: r.sagita...@gmx.de dmd can no longer read files from a network share: dmd \\network\share\test.d ... Error: module `test` is in file '\\network\share\test.d' which cannot be read You can also no longer pass in file names with the extension long file prefix: dmd \\?\c:\tmp\test.d ... Error: module `test` is in file '\\?\c:\tmp\test.d' which cannot be read Redirecting some output to special devices fails, too: dmd \\?\c:\tmp\test.d -deps nul: ... Error: invalid file name 'nul:' Introduced in dmd 2.078 by adding prefix \\?\ to filenames unconditionally. This can also confuse generic file tracking for dependency generation as used by msbuild. --
Re: Updating D beyond Unicode 2.0
On 25/09/18 15:35, Dukc wrote: Another reason is that something may not have a good translation to English. If there is an enum type listing city names, it is IMO better to write them as normal, using Unicode. CityName.seinäjoki, not CityName.seinaejoki. This sounded like a very compelling example, until I gave it a second thought. I now fail to see how this example translates to a real-life scenario. City names (data, changes over time) as enums (compile time set) seem like a horrible idea. That may sound like a very technical objection to an otherwise valid point, but it really think that's not the case. The properties that cause city names to be poor candidates for enum values are the same as those that make them Unicode candidates. Shachar
Re: OT: Bad translations
On Wednesday, 26 September 2018 at 02:12:07 UTC, Ali Çehreli wrote: On 09/24/2018 08:17 AM, 0xEAB wrote: > - Non-idiomatic translations of tech terms [2] This is something I had heard from a Digital Research programmer in early 90s: English message was something like "No memory left" and the German translation was "No memory on the left hand side" :) The K in German was of the same "quality". That happens when the translator is not an IT person himself.
Re: OT: Bad translations
On Wednesday, 26 September 2018 at 02:12:07 UTC, Ali Çehreli wrote: On 09/24/2018 08:17 AM, 0xEAB wrote: > - Non-idiomatic translations of tech terms [2] This is something I had heard from a Digital Research programmer in early 90s: English message was something like "No memory left" and the German translation was "No memory on the left hand side" :) My ex-girlfriend tried to learn SQL from a book that had gotten a prize for its use of Norwegian. As a result, every single concept used a different name from what everybody else uses, and while it may be possible to learn som SQL from this, it made googling an absolute nightmare. Just imagine a whole book saying CHOOSE for SELECT, IF for WHERE, and USING instead of FROM - only worse, since it's a different language. It even used SQL pseudo-code with these made-up names, and showed how to translate it to proper SQL as more of an afterthought. -- Simen
Re: is there something like `stm32-rs` in D?
On Wednesday, 26 September 2018 at 05:24:08 UTC, Radu wrote: On Wednesday, 26 September 2018 at 03:46:21 UTC, dangbinghoo wrote: hi, https://github.com/adamgreig/stm32-rs looks great, is there something like this in Dlang? thanks! --- dangbinghoo You might take a look at https://github.com/JinShil/stm32f42_discovery_demo and https://github.com/JinShil/stm32_datasheet_to_d thanks, Radu, I knew that there's a minimal D demo on STM32 exist for years. But, what I'm talking about is that rust community is doing a rust library for very production use. If you look at stm32-rs, you will found that stm32-rs is covering the whole STM32 MCU product line and making a promising peripherals library. The library was generated using CMSIS-SVD files which were maintained by MCU vendors. Anyway, I don't know what's the runtime size situation D vs rust. for those kinds of MCU devices, a runtime code size greater than 5KB may even not suitable for L0 lines MCU from ST. It's not quite clear that whether D or rust is valuable for MCU development, but C is really lacking lots of things for quick development, today MCU is interfacing more IoT modules using AT command, and deal with these string things is quite painful in C. Maybe this is an opportunity for D? Thanks! --- dangbinghoo
