Re: Handling big FP numbers
On Saturday, 9 February 2019 at 02:12:29 UTC, Murilo wrote: Why is it that in C when I attribute the number 991234307654329925.7865 to a double it prints 991234299470108672. and in D it prints 9912342990. ? Apparently both languages cause a certain loss of precision(which is part of converting the decimal system into the binary system) but why is it that the results are different? Do you want to learn D programming then check http://letsfindcourse.com/d-programming-courses Here you will find the best D programming tutorials recommended by programming community.
Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible
On Sunday, 17 December 2017 at 17:15:57 UTC, ParticlePeter wrote: On Sunday, 17 December 2017 at 16:40:46 UTC, John wrote: Yah the sc.ini file is wrong for Environment64. [Environment64] LIB="%@P%\..\lib64" . . . ; Windows installer uncomments the version detected LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe Thanks! Is this a known, reported bug? I don't think so, all that would need to be changed is this line: https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53 Not very many people use it I guess if it's been there for 8 months lol.
Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible
On Sunday, 17 December 2017 at 15:57:08 UTC, ParticlePeter wrote: I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile a mixed c++/d project (DMD links to one c++ lib). Here is the full error message: fatal error C1905: Front end and back end not compatible (must target same processor). LINK : fatal error LNK1257: code generation failed Error: linker exited with status 1257 dmd failed with exit code 1257. No such problems with my previous DMD version. What has changed with linking since then? (Skimmed through changelogs but found nothing). I found a workaround with specifying LINKCMD64 to my VS 2017 linker, but this is not a viable solution. The project must build with DMD on any system with VS installed without me knowing its exact location. What can I do to make it run out of the box and without the link command specified? Yah the sc.ini file is wrong for Environment64. [Environment64] LIB="%@P%\..\lib64" . . . ; Windows installer uncomments the version detected LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe
Re: LDC 1.7.0-beta1
On Sunday, 10 December 2017 at 18:11:46 UTC, Suliman wrote: On Sunday, 10 December 2017 at 17:33:34 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.7. The highlights of this version in a nutshell: * Based on D 2.077.1. * Catching C++ exceptions supported on Linux and Windows. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0-beta1 Thanks to all contributors! Is it's possible to produce x64 binaries on Windows x64 without installing Visual Studio? DMD do not have linker for x64. You can install just the C++ build tools from VS.
Mangling C++ Functions?
Does anyone have any solutions around the problem of linking to C++ functions from D that use types that D can't represent? Such as "float* const"? I don't want to just stick the symbol name in a pramga(mangle, "...") as that won't be portable. Possibly implementing mangling for extern(C++) for core.mangleFunc but somehow allow for the pointers to be modified. I'm not sure what a good interface for that would look like. As you can have a bunch of pointers to pointers "float" with each indirection being able to be const or not independent of each other. The most common use case would propbably be either one or two indirections, I am thinking of when a function has the following definition: "void func(float param[])" "void func(float* param[])" Which results in the definition for the parameter being "float* const" or "float** const".
Re: Attributes on Enum Members: Call for use cases.
On Wednesday, 29 November 2017 at 21:46:51 UTC, Timon Gehr wrote:
On 29.11.2017 20:49, Steven Schveighoffer wrote:
On 11/29/17 2:01 PM, Timon Gehr wrote:
OK, now I get what you are saying. In the same vein, I tested
applying attributes to functions themselves:
@("a") int fun() { return 0; }
pragma(msg, typeof()); // int function()
@("b") int gun() { return 1; }
pragma(msg, typeof()); // int function()
void main()
{
auto f =
f = // works
}
Given that, it seems attributes play no part in the type
itself, they are just metadata in the compiler.
Well, I think the case of UDAs on parameters is closer to:
struct S{
@("a") int x1;
@("b") int x2;
}
The attributes on x1 and x2 are indeed part of the type S, even
if the attributes on S itself are not.
If we go with "UDAs on parameters are not part of the function
type", how to you get the UDAs of the parameters of some
function?
The function would have to be passed directly to __traits() to
get the UDA. If passed to a function, it would have to be via
alias:
void func(@attr int param) { }
void test(alias f)()
{
writeln(getParameterAttr!(f, 0)); // or however to implement
getting the attribute
}
test!func(); // prints @attr
Re: Thoughts about D
On Tuesday, 28 November 2017 at 05:18:42 UTC, Adam D. Ruppe wrote: On Tuesday, 28 November 2017 at 04:52:52 UTC, bauss wrote: You're not measuring what you think for the Java program. Did you calculate the runtime and JIT initialization time and subtracted that from the actual execution time? Otherwise your benchmark isn't sufficient. For small programs, startup time is fair to consider since the end user still has to deal with that too. But for larger programs, I suspect it would disappear too. Not when the startup time is in milliseconds. If it was a large program taking minutes to startup, but that's not the case at all. A user will barely even be able to tell the difference between 50ms.
Re: UDAs on Enum Members: Does it require a DIP?
On Tuesday, 28 November 2017 at 01:49:19 UTC, Jonathan M Davis wrote: On Tuesday, November 28, 2017 00:15:24 John via Digitalmars-d wrote: On Monday, 27 November 2017 at 17:48:35 UTC, Andrei Alexandrescu wrote: > Hi Mike, this forum is not an appropriate place for > requesting official answers. We don't scan the forums > looking for matters that need attention. Feel free to send > email to Walter and myself, and that will get answered. > Thanks! -- Andrei Someone seems to disagree with you in that regard. https://forum.dlang.org/post/ouqgln$1chr$1...@digitalmars.com Not only did it get your attention but you didn't even bother addressing it! There is a definite difference between posting stuff in the newsgroup to get attention brought to something and posting in the newsgroup to get an official answer on something from Walter or Andrei. - Jonathan M Davis Not really, they can post the official answer on the github issue, that was brought to their attention through the forums. Him asking for an official answer is kind of irrelevant. Something was being neglected, and attention has been brought to it.
Re: Thoughts about D
On Monday, 27 November 2017 at 23:13:00 UTC, Walter Bright wrote: On 11/27/2017 7:16 AM, Steven Schveighoffer wrote: On 11/26/17 9:56 PM, Walter Bright wrote: I have recently finished converting the Digital Mars C++ compiler front end from "C with classes" to D. I did a double-take on this. Are we to see an article about it soon? I suppose I should write one :-) It was a very satisfying project. I'm looking at converting all my C projects still in use (like 'make') to D. BetterC has removed the last barriers to it. Should add optlink to that list, would love to see it converted to D!
Re: Thoughts about D
On Tuesday, 28 November 2017 at 02:26:34 UTC, Neia Neutuladh wrote: On Monday, 27 November 2017 at 17:35:53 UTC, Ola Fosheim Grostad wrote: On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh wrote: I last used C++ professionally in 2015, and we were still rolling out C++11. std::string_view is part of C++17. You're calling me stupid for not having already known about it. (Yes, yes, you were sufficiently indirect to have a fig leaf of deniability.) I'n not talking about you obviously. I am talking about using languages stupidly... You can ask your local HR representative how much better it is to say "your ideas are stupid" than "you are stupid". Could ask Linus about that, think I recall something about baby sloth dropped on it's head retardation level, or something. C++ is very much batteries not included... Which is good for low level programming. So you're saying that having a body of well tested code that does what you want already but *might* be making performance tradeoffs that don't work for your use case, is *worse* than not having it. Well, it's a heterodox opinion to be sure. For C++ that's boost. Most people avoid it cause of all the bloat anyways. It is often useful to talk about real-world workloads when discussing performance. Well, in that case Java was sufficiently fast, so all languages came out the same... You might try reading my first post. Java: 140ms to print "Hello world" D: 50ms to turn a 400kb subtex document into an epub Were you including startup times? Then that's not a very fair comparison. Lots of applications aren't just start and stop frequently. These benchmarks are all but pointless for performance anyways. Like when someone updated the D sort functions, they made an article about how much faster sorting was in D than C++. Well no shit, you just spent a bunch of time optimizing it based on some tiny stupid test. Anyways if you think that's a valid comparison of performance you have no idea what's going on.
Re: UDAs on Enum Members: Does it require a DIP?
On Monday, 27 November 2017 at 17:48:35 UTC, Andrei Alexandrescu wrote: Hi Mike, this forum is not an appropriate place for requesting official answers. We don't scan the forums looking for matters that need attention. Feel free to send email to Walter and myself, and that will get answered. Thanks! -- Andrei Someone seems to disagree with you in that regard. https://forum.dlang.org/post/ouqgln$1chr$1...@digitalmars.com Not only did it get your attention but you didn't even bother addressing it!
Re: @property Incorrectly Implemented?
On Saturday, 17 September 2016 at 10:55:59 UTC, Ethan Watson
wrote:
On Friday, 16 September 2016 at 20:52:37 UTC, John wrote:
Your comment was out of place, saying properties don't need to
be changed is like saying @property shouldn't even be a D
feature cause you can create the same functional program in
C++, which does not have the property feature.
Stop reading rubbish that isn't there.
And pay attention. MSVC has the __declspec( property )
extension.
MSVC != C++
I'm not going to pay attention to a feature that isn't standard
and only Microsoft's compiler seems to have.
Since you brought it up though, it's a good chance to look at how
it behaves.
struct Test
{
int p;
int& prop()
{
return p;
}
__declspec(property(get = prop, put = prop)) int& magic;
};
void main()
{
Test test;
test.p = 10;
if( == )
{
std::cout << << '\n' << << '\n'
<< "magic";
}
}
I'll give you a hint, it prints magic. Imagine that.
You also made a reference to C#, which doesn't even allow you
take address of
And? Properties in C# are a massive example of a comparable
feature where executed code is syntactically treated in some
ways to a variable.
Yes, you can't take the address of a property in C#, with or
without unsafe on.
So I don't know what you mean by that's how I want to play,
when you instigated said argument.
I indicated you're taking it personally. Which you are.
I wasn't until you indicated that you were taking it personally
with that statement.
It's not really that important. What it allows is returning
references. You can make a comparison to any other language
that has properties it doesn't really matter. This is how D
was implemented. If they wanted to be like every other
language then it shouldn't have been allowed to even return a
reference. But it is does, that's how it's implemented and
odds are it probably won't change now to not allow it. D also
has the "&" implemented, what I am discussing is whether it
was implemented correctly or not. Honestly it is no
implemented correctly. To the point I would actually rather
they remove the functionality so that you can't take the
address of a property. If they are not willing to change it to
function in a different way.
Taking the address of a property and getting a function type is
important.
Did you know that this C++ class:
class SomeObject
{
virtual int getSomeValue() const;
virtual int setSomeValue( int value );
};
Matches up exactly to this D class:
extern( C++ ) class SomeObject
{
@property SomeValue() const;
@property SomeValue( int value );
}
You have "get" and "set" in the C++ function, so no it doesn't
match it exactly. Semantics aside, you shouldn't be referencing
behavior of properties in a language that doesn't even have
properties. It's simply a way to emulate properties. If C++ had
properties, I would imagine they would behave like the above MSVC
implementation does. Shouldn't be held back by C++ for such a
reason, you can easily take off those property attributes and
that would probably be the saner solution. So that it actually
functions the same, in that you need the use the paranethese to
set and get the variable. That aside I doubt you ever take the
pointer of those getters and setters in C++ either.
Anyways a bitfield can't actually represent a single, there's
no type for a bit. The smallest type is a byte, which is 8
bits. So even if it wasn't a property there's no way you can
take the address of a bit. So that's the first issue, you are
trying to use an example that doesn't make sense even outside
the concept of properties. The second issue is, this is
defined behavior. You can't take the address of a rvalue,
there's an ideone link in my previous post show this if you
missed it. So taking the address of a property would return an
error if it didn't return a reference.
What you're suggesting, and why I brought up the example, is to
change the implementation details of properties for *one* use
case. This has wide ranging implications that you've clearly
not thought of. Like if I was to take the address of that
property for the purposes of exposing a function to C++. You
want to make it so I don't get that function? Or that there's
some extra convoluted method of getting it solely because you
think a property should be something that it's not?
One use case is better than the zero use case it current holds..
And using it to identify whether a member is a property is a
misuse and i'd actually count that as a negative. So negative one
use case.
Well that's how it is currently implemented actually.
struct S
{
@property int prop() { return 0; }
}
writeln(typeof(S.prop).stringof) // prints "int", not
"delegate"
Read further. I have suggested that the property resolution
order gets changed so
Re: @property Incorrectly Implemented?
On Sunday, 11 September 2016 at 12:02:29 UTC, Ethan Watson wrote:
On Sunday, 11 September 2016 at 07:19:54 UTC, John wrote:
You can't really take one sentence out of context, I didn't
say it in the sense that it was completely broken to the point
of being useless.
There's nothing out of context about it. Would it have made you
feel better had I quoted your entire message knowing that I
wouldn't have changed a word of the response?
But if that's how you want to play.
Your comment was out of place, saying properties don't need to be
changed is like saying @property shouldn't even be a D feature
cause you can create the same functional program in C++, which
does not have the property feature. You also made a reference to
C#, which doesn't even allow you take address of So I don't know
what you mean by that's how I want to play, when you instigated
said argument.
The part I'm asking to be changed, you probably didn't even
ever use. C# is a managed language, I don't think you can even
take the pointer of anything unless you enable the unsafe
switch.
You're not showing a good grasp at all as to what a property
is. In C# and in D, a property has *never* guaranteed the
existence of a variable. In both cases, they allow syntactic
sugar for letting the getter/setter pattern established by C++
look like variables.
This is important.
No, really.
Take std.bitmanip for an example of what I was talking about.
It autogenerates properties for a bitfield. The types each
property returns and lets you set are not at all indicative of
the datatype underneath as it's literally just a bunch of bits.
The property functions transform the data types given/return
to/from a bitfield. What exactly do you suggest
return if it was to return a char starting at bit 13 of a
bitfield?
It's not really that important. What it allows is returning
references. You can make a comparison to any other language that
has properties it doesn't really matter. This is how D was
implemented. If they wanted to be like every other language then
it shouldn't have been allowed to even return a reference. But it
is does, that's how it's implemented and odds are it probably
won't change now to not allow it. D also has the "&" implemented,
what I am discussing is whether it was implemented correctly or
not. Honestly it is no implemented correctly. To the point I
would actually rather they remove the functionality so that you
can't take the address of a property. If they are not willing to
change it to function in a different way.
This has been brought up by someone else. I honestly don't
understand why it's such a hard concept. Maybe you don't come
from C++ and thus don't use a language that provides a way to
take the address of things. That's why it keeps being brought up.
Anyways a bitfield can't actually represent a single, there's no
type for a bit. The smallest type is a byte, which is 8 bits. So
even if it wasn't a property there's no way you can take the
address of a bit. So that's the first issue, you are trying to
use an example that doesn't make sense even outside the concept
of properties. The second issue is, this is defined behavior. You
can't take the address of a rvalue, there's an ideone link in my
previous post show this if you missed it. So taking the address
of a property would return an error if it didn't return a
reference.
But we can go one further. __traits( allMembers, Type ) and
__traits( getMember, Type ). Let's say you're writing an
auto-serialisation library (or take std.json as an example).
Assuming a property is a stand-in for another variable then
what happens there when you're checking for the type of a
member is the delegate type, and later on you'll get the actual
variable. Now change it so that the type of a property returns
the actual type. Now you're serialising a piece of data twice.
But what if our @property function increments another variable
inside a class whenever you access it? That's pretty dangerous
if you start treating the property as an actual type instead of
a function/delegate.
Well that's how it is currently implemented actually.
struct S
{
@property int prop() { return 0; }
}
writeln(typeof(S.prop).stringof) // prints "int", not
"delegate"
I'm only talking about taking the address of a property. That
does no way infer that there shouldn't be some way to identify
that it is a property at compile time. The way you should check
if a member is a property shouldn't be by taking the address of
it. That's not as clear as having a trait or other implementation
such that you could do "isProperty". That is much more clearer.
If the only way to identify a property is by checking the
typeof() a member for when you take it's address, then that's a
hack and a better way to identify a property should be
implemented.
Thus, your example:
// returns "ref int delegate()"
() //
Re: @property Incorrectly Implemented?
On Tuesday, 6 September 2016 at 19:37:26 UTC, Jonathan M Davis wrote: On Tuesday, September 06, 2016 19:18:11 John via Digitalmars-d wrote: Currently it seems that @property isn't implemented correctly. For some reason when you try to get the pointer of a property it returns a delegate for some reason. This just seems plain wrong, the whole purpose of a property is for a function to behave as if it weren't a function. There's also some inconsistencies in the behavior, "get" is implemented one way and then "set" is implemented another. http://ideone.com/ZgGT2G // returns "ref int delegate()" () // ok returns "int*", but defeats purpose of @property &(t.j = 10) // shouldn't this return "ref int delegate(int)" ? It would be nice to get this behavior fixed, so that it doesn't become set in stone. I think returning a delegate pointer is not what people would except nor is there really any use case for it. Okay. How would it work to safely get a pointer to anything but the @property function when taking its address? () is just going to give you the address of the return value - which in most cases, is going to be a temporary, so if that even compiles in most cases, it's a bit scary. Sure, if the @property function returns by ref, then it can work, but an @property function which returns by ref isn't worth much, since you're then giving direct access to the member variable which is what an @property function is usually meant to avoid. If you wanted to do that, you could just use a public member variable. So, given that most @property functions are not going to return by ref, how does it make any sense at all for taking the address of an @property function to do anything different than give you a delegate? Sure, that's not what happens when you take the address of a variable, but you're not dealing with a variable. You're dealing with an @property function which is just trying to emulate a variable. The reality of the matter is that an @property function is _not_ a variable. It's just trying to emulate one, and that abstraction falls apart _really_ fast once you try and do much beyond getting and setting the value - e.g. passing by ref falls flat on its face. We could do better than currently do (e.g. making += lower to code that uses both the getter and the setter when the getter doesn't return by ref), but there are some areas where a property function simply can't act like a variable, because it isn't one. There isn't even a guarantee that an @property function is backed by memory. It could be a completely calculated value, in which case, expecting to get an address of a variable when taking the address of the @property function makes even less sense. - Jonathan M Davis I don't see how that would be a problem, you can't take the address of an rvalue... The problem you describe would be true for functions as well. What's not true is that it is compilable (see: http://ideone.com/MXhkXC ). Any problem you can conjure up about references, temporary values and pointers, all of that would be true for a regular function as well. Obviously it is not a variable, but if you use a function and it returns a reference and you take the address of it. What you get is the address of the returned value not of the function. int v = obj.prop; if you look at that "prop" is a called function pretending to be a variable. If you take the address of a called function, you get the address of the returned variable, not the function. If you take the address of a variable, you get the address of the variable. On Wednesday, 7 September 2016 at 07:44:05 UTC, Ethan Watson wrote: On Tuesday, 6 September 2016 at 19:18:11 UTC, John wrote: It would be nice to get this behavior fixed. Disagree. I've used properties before in C# to transform to and from data sets required for network multiplayer. It works functionally the same way in D. Behaviour is as I would expect for the wider implications of how properties can work. You can't really take one sentence out of context, I didn't say it in the sense that it was completely broken to the point of being useless. The part I'm asking to be changed, you probably didn't even ever use. C# is a managed language, I don't think you can even take the pointer of anything unless you enable the unsafe switch. On Tuesday, 6 September 2016 at 19:34:59 UTC, ag0aep6g wrote: On 09/06/2016 09:18 PM, John wrote: &(t.j = 10) // shouldn't this return "ref int delegate(int)" ? `` should and does. With `= 10`, it's definitely a call, just like `()`. It would be nice to get this behavior fixed, so that it doesn't become set in stone. Unfortunately, it already kinda is. Just flipping the switch would break circa all D code in existence. That's deemed unacceptable by the leadership, as far as I know. Don'
@property Incorrectly Implemented?
Currently it seems that @property isn't implemented correctly. For some reason when you try to get the pointer of a property it returns a delegate for some reason. This just seems plain wrong, the whole purpose of a property is for a function to behave as if it weren't a function. There's also some inconsistencies in the behavior, "get" is implemented one way and then "set" is implemented another. http://ideone.com/ZgGT2G // returns "ref int delegate()" () // ok returns "int*", but defeats purpose of @property &(t.j = 10) // shouldn't this return "ref int delegate(int)" ? It would be nice to get this behavior fixed, so that it doesn't become set in stone. I think returning a delegate pointer is not what people would except nor is there really any use case for it.
Re: Dealing with unicode
On Friday, 29 July 2016 at 06:32:24 UTC, Fabian wrote: I'm trying to add support for unicode to my app in D and having issues. string str = "Pokémon No"; writeln(str); this outputs: Pok├®mon No what I want to do is change the funky character such that the string reads: Pok\u00e9mon No as \u00e9 == é how can i do this in D? Strings are UTF-8 in D - but the console might need to be configured to display them correctly. If you're on Windows, this will do it: SetConsoleOutputCP(CP_UTF8);
Re: counting characters
On Tuesday, 19 July 2016 at 09:34:11 UTC, celavek wrote: Hi, I am trying to count characters in a string like: const string dna_chain = "AGCCATTCTGACTGCAACGGGCAATATGTCTCTGTGTGGATTAAAGAGTGTCTGATAGCAGC"; counts['A'] = countchars!(dna_chain, 'A'); countchars(dna_chain, "A");
Re: Passing a single tuple or multiple values
On Tuesday, 19 July 2016 at 01:22:01 UTC, jmh530 wrote:
import std.typecons : isTuple, tuple;
import std.stdio : writeln;
auto foo(T...)(T x)
{
T[0] y;
foreach (i, e; x)
{
y += e;
}
return y;
}
auto bar(T)(T x)
{
static if (isTuple!T)
{
return foo(x.expand);
}
}
auto bar(T...)(T x)
{
return foo(x);
}
auto bar(T...)(T x)
{
static if (T.length == 1 && isTuple!(T[0]))
return foo(x.expand);
else
return foo(x);
}
void main()
{
auto x = tuple(1, 2);
auto y = bar(x);
auto z = bar(x.expand);
writeln(y);
writeln(z);
}
Re: Convert delegate or function type to other.
On Monday, 18 July 2016 at 18:49:22 UTC, Rufus Smith wrote: Suppose I have the following: alias func = void function(int); Is there a way to convert it automatically to something the same type except of delegate: alias del = toDel(func) = void delegate(int);? import std.traits; alias del = ReturnType!func delegate(Parameters!func);
Re: C++ interface vs D and com
On Wednesday, 13 July 2016 at 20:28:40 UTC, Adam Sansier wrote:
On Wednesday, 13 July 2016 at 19:22:44 UTC, Kagamin wrote:
On Wednesday, 13 July 2016 at 16:48:53 UTC, Adam Sansier wrote:
There's a lot of misinformation on the net.
Nope, it's just you. COM support in D and in general works
fine for everyone else.
For anyone else having similar problems please ignore. COM
doesn't work perfectly regardless of what some nobody says and
I'm not the only one having problems. There are others and a
search shows this.
http://forum.dlang.org/thread/iovu2e$2d3d$1...@digitalmars.com
I notice you are the last one to say "COM uses stdcall
convention. Everything else is not COM." Spreading your lies
and disinformation. People like you are a source of problems,
not a solution. Please learn that you don't know everything and
your generalization about how everything works is simply wrong.
http://www.digitalmars.com/d/archives/digitalmars/D/learn/thiscall_calling_convention_4943.html
Regardless of why the problems exist, or if they are subtle or
only in certain scenarios, they exist and some imbecile
claiming they don't just makes more trouble for those trying to
solve their problems.
If you don't like my attitude, stop acting like the world is
perfect and when someone has a problem that it just might be
legitimate. If you don't actually feel like helping, simply
don't reply, it's that easy.
The problem is that ASIO deviates from the standard way of
implementing COM. Other languages like Delphi expect COM to use
stdcall too, so the problem is not unique to D. Putting
"extern(C++):" before the interface method declarations should
allow it to work...
interface IASIO : IUnknown {
extern(C++):
HRESULT SomeMethod();
}
Re: C++ interface vs D and com
On Wednesday, 13 July 2016 at 07:31:57 UTC, Adam Sansier wrote: void** ptr = null; auto res = CoCreateInstance(_ID, cast(IUnknown)null, CLSCTX_INPROC_SERVER, _ID, cast(void**)); How are you casting your "ptr" variable (which BTW should be just void* or usually IUnknown) to your interface? A common mistake if you're used to C++ is using cast(ISomeInterface*)ptr - which would cause access violations - instead of cast(ISomeInterface)ptr.
Re: adding toString to struct
On Tuesday, 12 July 2016 at 14:51:43 UTC, Adam Sansier wrote: On Tuesday, 12 July 2016 at 14:27:49 UTC, Adam D. Ruppe wrote: On Tuesday, 12 July 2016 at 05:16:30 UTC, Adam Sansier wrote: Is there a way to do this? write a new function that prints them and call that This doesn't work to display them in visual D though. Requires a lot of hoops just to see a stupid string of the data. OutputDebugString works in Visual Studio, so might work in Visual D as well.
Re: How to get current time as long or ulong?
On Tuesday, 5 July 2016 at 18:16:31 UTC, Charles Hixson wrote: I've been reading std.datetime documentation backwards and forwards, but if the information is there, I've been missing it. How do I get the current time as a long? Clock.currTime() returns a SysTime, and while currently I can convert that to a long, this is because I looked into the code. What's the supported way? All the documentation seems to be based around auto, which is great if you don't need to store it in memory with a defined number of bits allocated...but lousy if you do. (E.g., I don't want to store a time zone, just the UTC time. What I'm looking for is the opposite of the "FromUnixTime" function. Clock.currTime.stdTime
Re: Registration-free COM client
On Wednesday, 29 June 2016 at 14:51:10 UTC, Thalamus wrote: I was hoping there would be a code-only solution, and I'm glad to see one is possible. It isn't quite working for me yet, though. I can get the HINSTANCE in the CoLoadLibrary call, but GetProcAddress for DllGetClassObject fails, with ERROR_PROC_NOT_FOUND. I've never written a COM server before (only clients), so I must be building the C# assembly incorrectly. I'm just not sure how. Everything across the board is built as 64-bit, and I've selected "Register for COM interop". The C# is pretty simple: A little research reveals that C# COM servers don't export DllGetClassObject, or any of the COM server plumbing. "Registering for COM interop" merely adds the registry entries - which is the step you're trying to avoid by loading the DLL dynamically. Then you'd run regasm on it to generate a type library. https://msdn.microsoft.com/en-us/library/aa645738(v=vs.71).aspx
Re: Registration-free COM client
On Wednesday, 29 June 2016 at 17:55:27 UTC, John wrote:
On Wednesday, 29 June 2016 at 14:51:10 UTC, Thalamus wrote:
and the D code (mostly unchanged from your example):
interface ITestInterface
{
int Identifier();
}
ITestInterface needs to derive from IUnknown.
I realise that doesn't address your question, but the other thing
is I'm pretty sure C# will transform the ITestInterface
definition into something more like this:
interface ITextInterface : IUnknown {
HRESULT Identifier(int* result);
}
And when it comes to calling it:
int result;
checkHR(instance.Indentifier());
Re: Registration-free COM client
On Wednesday, 29 June 2016 at 14:51:10 UTC, Thalamus wrote:
and the D code (mostly unchanged from your example):
interface ITestInterface
{
int Identifier();
}
ITestInterface needs to derive from IUnknown.
Re: Registration-free COM client
On Monday, 27 June 2016 at 21:17:52 UTC, Thalamus wrote: Hi everyone, I've succeeded in using D as a client for regular (registered) COM servers in the past, but in this case, I'm building the server as well. I would like to avoid registering it if possible so XCOPY-like deployment remains an option. Can a registration-free COM client be built in D? If so, how can the code be setup to consume the manifest file, or alternately, is there a way to just point D to the correct assembly directly in code? You just deploy the manifest in the same folder as your client.
Re: Getting the template name of a template instantiation
On Monday, 27 June 2016 at 17:14:23 UTC, John wrote:
On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:
If I have a template parameter
E = S!int
where
struct S(T) { S x; }
how can I extract the template name part `S` from E`?
Something like:
static assert(is(templateName!(S!int) == S));
Is this already in Phobos somewhere?
import std.traits;
__traits(identifier, TemplateOf!(S!int));
Scratch that, this is what you want:
import std.traits;
static assert(__traits(isSame, TemplateOf!(S!int), S));
Re: Getting the template name of a template instantiation
On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:
If I have a template parameter
E = S!int
where
struct S(T) { S x; }
how can I extract the template name part `S` from E`?
Something like:
static assert(is(templateName!(S!int) == S));
Is this already in Phobos somewhere?
import std.traits;
__traits(identifier, TemplateOf!(S!int));
Re: static switch/pattern matching
On Saturday, 25 June 2016 at 12:35:39 UTC, Lodovico Giaretta wrote: On Saturday, 25 June 2016 at 12:30:22 UTC, Lodovico Giaretta wrote: If you want this to work, you need your lambdas to take the casted value as a parameter: Thanks.
Re: Does D has any support for thunks?
On Saturday, 25 June 2016 at 13:44:48 UTC, Andre Pany wrote:
Hi everyone,
I have some issue with win32 function SetWindowsHookEx. For
this specific funtion there is no possibility to pass extra
data (pointer to a class instance to be called) to the callback
function.
The general solution seems to use thunks. I found s.th. for c++:
http://www.codeproject.com/Articles/16785/Thunking-in-Win-Simplifying-Callbacks-to-Non-sta
Does D/Phobos has any support for thunks?
Kind regards
André
This will only work on X86:
version(X86)
struct FunctionPtr(TDelegate) if (is(TDelegate == delegate)) {
import std.traits;
alias TResult = ReturnType!TDelegate;
alias TParameters = Parameters!TDelegate;
private struct ThunkCode {
align(1):
ubyte mov_eax;
void* this_ptr;
ubyte mov_ecx;
void* func_ptr;
ubyte mov_edx;
void* cb_ptr;
ushort jmp_edx;
}
this(TDelegate method) {
this = method;
}
auto ref opAssign(TDelegate method) {
extern(Windows)
TResult callback(TParameters parameters) {
TDelegate dg = void;
asm {
mov [dg], EAX;
mov [dg + 4], ECX;
}
return dg(parameters);
}
if (auto thunk = cast(ThunkCode*)VirtualAlloc(null,
ThunkCode.sizeof,
MEM_COMMIT, PAGE_EXECUTE_READWRITE)) {
with (thunk) {
mov_eax = 0xB8;
this_ptr = method.ptr;
mov_ecx = 0xB9;
func_ptr = method.funcptr;
mov_edx = 0xBA;
cb_ptr =
jmp_edx = 0xE2FF;
}
FlushInstructionCache(GetCurrentProcess(), thunk,
ThunkCode.sizeof);
ptr = cast(typeof(ptr))thunk;
}
else {
assert(false);
}
return this;
}
~this() {
if (ptr) {
VirtualFree(ptr, ThunkCode.sizeof, MEM_DECOMMIT);
ptr = null;
}
}
extern(Windows)
TResult function(TParameters) nothrow ptr;
alias ptr this;
}
alias HookProc = FunctionPtr!(LRESULT delegate(int, WPARAM,
LPARAM));
LRESULT hookProc(int code, WPARAM wparam, LPARAM lparam) {
return 0;
}
HookProc hook =
SetWindowsHookEx(WH_KEYBOARD, hook, GetModuleHandle(null), 0);
Re: static switch/pattern matching
On Saturday, 25 June 2016 at 09:12:12 UTC, Lodovico Giaretta
wrote:
On Saturday, 25 June 2016 at 09:07:19 UTC, Lodovico Giaretta
wrote:
Instead of passing functions to match!, pass pairs of
arguments, like this:
match!(T,
int, writeln("Matched int"),
is(T : SomeObject), writeln("Derives from SomeObject");
);
Now, in the implementation, foreach pair of arguments, if the
first member is a type that matches your target, perform that
branch; otherwise, if the first member is a boolean value, and
it is true, perform the branch.
Of course I meant:
match!(T,
int, () {writeln("Matched int");},
is(T : SomeObject), () {writeln("Derives from
SomeObject");}
);
Thanks for the help, both. This appeared to work, until I
realised the lambda isn't static:
void match(T, cases...)() {
static if (cases.length == 1) cases[0]();
else static if (cases.length > 2) {
static if (is(typeof(cases[0]) == bool)) {
static if (cases[0]) cases[1]();
else match!(T, cases[2 .. $]);
}
else static if (is(T == cases[0])) cases[1]();
else match!(T, cases[2 .. $]);
}
}
void test(T)(T value) {
int i;
string s;
match!(T,
int, () => i = value,
string, () => s = value
);
}
test(1);
test("A string");
The compiler complains about not being able convert an int to a
string and vice versa.
static switch/pattern matching
Writing a long series of "static if ... else" statements can be
tedious and I'm prone to leaving out the crucial "static" after
"else", so I was wondered if it was possible to write a template
that would resemble the switch statement, but for types.
Closest I came up to was this:
void match(T, Fs...)() {
foreach (F; Fs) {
static if (isFunctionPointer!F) {
alias Ps = Parameters!F;
static if (Ps.length == 1) {
static if (is(Ps[0] == T)) F(Ps[0].init);
}
}
}
}
void test(T)(T t) {
match!(T,
(int _) => writeln("Matched int"),
(string _) => writeln("Matched string")
);
}
But that's pretty limited and I'd like to be able to match on
whether a type derives from T as well. I just can't figure it out.
Something like this would be ideal...
match!(T,
int => writeln("Matched int"),
is(T : SomeObject) => writeln("Derives from SomeObject")
);
Anyone able to improve on it?
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 21:06:01 UTC, Joerg Joergonson
wrote:
My thinking is that CoCreateinstance is suppose to give us a
pointer to the interface so we can use it, if all this stuff is
crashing does that mean the interface is invalid or not being
assigned properly or is there far more to it than this?
The problem is Photoshop hasn't provided an interface with
methods that can be called directly. They don't exist on the
interface, hence them being commented out. It's a mechanism known
as late binding (everything is done at runtime rather than
compile time). You need to ask the interface for the method's ID,
marshal the parameters into a specific format, and then "invoke"
the method using that ID.
And you're not going to like it. Here's an example just to call
the "Load" method:
// Initialize the Photoshop class instance
IDispatch psApp;
auto iid = IID__Application;
auto clsid = CLSID_Application;
assert(SUCCEEDED(CoCreateInstance(, null, CLSCTX_ALL,
, cast(void**;
scope(exit) psApp.Release();
// Get the ID of the Load method
auto methodName = "Load"w.ptr;
auto dispId = DISPID_UNKNOWN;
iid = IID_NULL;
assert(SUCCEEDED(psApp.GetIDsOfNames(, , 1, 0,
)));
// Put the parameters into the expected format
VARIANT fileName = {
vt: VARENUM.VT_BSTR,
bstrVal: SysAllocString("ps.psd"w.ptr)
};
scope(exit) VariantClear();
DISPPARAMS params = {
rgvarg: ,
cArgs: 1
};
// Finally call the method
assert(SUCCEEDED(psApp.Invoke(dispId, , 0, DISPATCH_METHOD,
, null, null, null)));
tlb2d only outputs the late-bound methods as a hint to the user
so they know the names of the methods and the expected parameters
(well, it saves looking them up in OleView). Had Photoshop
supplied a compile-time binding, you could have just called
psApp.Load(fileName) like you tried.
It's possible to wrap that ugly mess above in less verbose code
using native D types, and the Juno COM library mentioned earlier
enabled that, but the code is quite ancient (and is part of and
depends on a larger library). I've been slowly working on a more
modern library. You'd be able to just write this:
auto psApp = makeReference!"Photoshop.Application"();
psApp.Load("ps.psd");
But I don't know when it'll be ready.
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 18:35:42 UTC, Joerg Joergonson wrote: On Wednesday, 15 June 2016 at 06:09:33 UTC, thedeemon wrote: On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote: [...] There are ready tools idl2d: https://github.com/dlang/visuald/tree/master/c2d [...] I can't seem to get ComPtr to work. auto ps = ComPtr!_Application(CLSID_PS).require; Where CLSID_PS is the Guid from the registry that seems to work with CoCreate. _Application was generated from tbl2d. See my other post for a more(not much) complete description of the issues files. Ensure you are calling CoInitialize before anything else.
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 18:32:28 UTC, Joerg Joergonson
wrote:
import core.sys.windows.com, core.sys.windows.oaidl;
Thanks. Should these not be added to the generated file?
The problem is that other type libraries will probably require
other headers to be imported, and there's no way to work out
which, so I've left that up to the user for now.
Also, could you add to it the following:
const static GUID iid =
Guid!("5DE90358-4D0B-4FA1-BA3E-C91BBA863F32");
inside the interface (Replace the string with the correct guid)?
This allows it to work with ComPtr which looks for the iid
inside the interface, shouldn't hurt anything.
I could add that as an option.
In any case, I haven't got ComPtr to work so...
GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 chars
long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~
str[9..13] ~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" ~
str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x"
~ str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";
return mixin(GUIDstring);
}
also tried CoCreateInstance and getting error 80040154
Not sure if it works.
Changed the GUID to another one found in the registry(not the
one at the top of the generated file) and it works. Both load
photoshop
Oops. The one at the top of the file is the type library's ID,
not the class ID. I should just omit it if it causes confusion.
int main(string[] argv)
{
//auto ps = ComPtr!_Application(CLSID_PS).require;
//const auto CLSID_PS =
Guid!("6DECC242-87EF-11cf-86B4-44455354"); // PS 90.1 fails
because of interface issue
const auto CLSID_PS =
Guid!("c09f153e-dff7-4eff-a570-af82c1a5a2a8"); // PS 90.0
works.
auto hr = CoInitialize(null);
auto iid = IID__Application;
_Application* pUnk;
hr = CoCreateInstance(_PS, null, CLSCTX_ALL, ,
cast(void**));
if (FAILED(hr))
throw new Exception("ASDF");
}
The photoshop.d file
http://www.filedropper.com/photoshop_1
So, I guess it works but how to access the methods? The
photoshop file looks to have them listed but they are all
commented out.
They're commented out because Photoshop seems to have only
provided a late-binding interface and you have to call them by
name through IDispatch.Invoke. It's possible to wrap all that in
normal D methods, and I'm working on it, but it won't be ready
for a while.
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 16:45:39 UTC, Joerg Joergonson wrote: Thanks. When I ran it I got a d file! when I tried to use that d file I get undefined IID and IDispatch. I imagine these interfaces come from somewhere, probably built in? Any ideas? Add the following after the module name: import core.sys.windows.com, core.sys.windows.oaidl;
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 08:21:06 UTC, John wrote: OK, adding the return type to the signature should fix that. So: private static Parameter getParameters(MethodImpl method) Sorry, I meant the getParameter methods should return be: private static Parameter[] getParameters(MethodImpl method) and private static Parameter[] getParameters(MethodImpl method, out Parameter returnParameter, bool getReturnParameter)
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 06:56:59 UTC, Joerg Joergonson
wrote:
When I try to compile your code I get the following errors:
main.d(953): Error: function
core.sys.windows.objbase.CoTaskMemAlloc (uint) is not callable
using argument types (immutable(ulong))
main.d(970): Error: can only slice tuple types, not _error_
main.d(974): Error: can only slice tuple types, not _error_
coTaskMemAlloc is defined with ULONG in the objbase.d file...
so I have no idea what's going on there.
immutable bufferSize = (funcDesc.cParams + 1) *
(wchar*).sizeof;
auto names = cast(wchar**)CoTaskMemAlloc(bufferSize);
Looks like bufferSize just needs to be cast to uint. Didn't get
that error in DMD.
The other two I also don't know:
params ~= new Parameter(method, (name[0 ..
SysStringLen(name)]).toUTF8(),
If I run it in ldc I get the error
Error: forward reference to inferred return type of function
call 'getParameters'
private static getParameters(MethodImpl method) {
Parameter dummy;
return getParameters(method, dummy, false);
}
It does compile in DMD though.
OK, adding the return type to the signature should fix that. So:
private static Parameter getParameters(MethodImpl method)
When running I get the error
Error loading type library/DLL.
The IDL file is in the same directory
Did you try to pass it an IDL file? No wonder it didn't work -
you pass in the type library instead, which is a binary file such
as a DLL, EXE or TLB file. You can get the file's path from
OleView by highlighting the library on the left (eg Photoshop)
and on the right it will show a tree with the path beside "win32".
Re: Accessing COM Objects
On Monday, 13 June 2016 at 19:26:08 UTC, Incognito wrote: On Monday, 13 June 2016 at 19:11:59 UTC, John wrote: On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote: Cool. Oleview gives me the idl files. How to convert the idl files to d or possibly c? Would I just use them in place of IUnknown once I have the interface? In OleView you can save the IDL file, then run another tool, midl.exe, on the IDL file. That will generate the C headers. But you'd then have to translate that to D by hand. I have written a tool that takes a COM type library and automatically converts it to a D source file. I could finish it off over the next few days and put the source on GitHub if you're interested. That would be great! With it I might be able to put a nice wrapper around Photoshop for use with D. Others mind find it useful too as other programs still use COM. It's up: https://github.com/jsatellite/tlb2d/tree/master/src/tlb2d There's probably a few bugs, and type libraries have a tendency to re-define existing types so you'll have to comment those out. Also it doesn't generate dependencies, but it does list them at the top of the generated module so you can run the tool on those type libraries manually.
Re: Accessing COM Objects
On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote: Cool. Oleview gives me the idl files. How to convert the idl files to d or possibly c? Would I just use them in place of IUnknown once I have the interface? In OleView you can save the IDL file, then run another tool, midl.exe, on the IDL file. That will generate the C headers. But you'd then have to translate that to D by hand. I have written a tool that takes a COM type library and automatically converts it to a D source file. I could finish it off over the next few days and put the source on GitHub if you're interested.
Re: Accessing COM Objects
On Monday, 13 June 2016 at 01:22:33 UTC, Incognito wrote:
I've been reading over D's com and can't find anything useful.
It seems there are different ways:
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf
which is of no help and requires an idl file, which I don't
have.
Then theres this
http://wiki.dlang.org/COM_Programming
which is also of no help:
import std.stdio;
import std.stdio, core.sys.windows.com,
core.sys.windows.windows, std.exception, std.meta, std.traits;
import std.utf, core.stdc.stdlib, core.sys.windows.objidl,
core.sys.windows.ole2;
pragma(lib, "ole32.lib");
GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 chars
long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~
str[9..13] ~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" ~
str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x"
~ str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";
return mixin(GUIDstring);
}
int main(string[] argv)
{
// Adobe Photoshop App 9.0 CLSID
{c09f153e-dff7-4eff-a570-af82c1a5a2a8}
// Adobe Photoshop App 9.1 CLSID
{6DECC242-87EF-11cf-86B4-44455354}
auto CLSID_DOMDocument60 =
Guid!("6DECC242-87EF-11cf-86B4-44455354");
auto iid = IID_IUnknown;
void* pUnk;
auto hr = CoCreateInstance(_DOMDocument60, null,
CLSCTX_ALL, , );
if (FAILED(hr))
throw new Exception("Error!");
writeln("Hello D-World!");
return 0;
}
Maybe my CLSID's are wrong. Got them from the registry. The
exception triggers each time. Even if it worked, I wouldn't
know how to use it.
I can do this stuff in C# by simply dragging and dropping a dll
into the references and it works fine but is a bit slow. I was
hoping I could speed things up using D but it seems like COM
isn't really supported, despite what several references say.
COM is supported in D. The difference is that C# hides all the
plumbing behind nice classes.
You're going to need Photoshop's COM interface to do anything
with it. If you don't have a C header that you can translate into
D, you could use a tool included in the Windows SDK called
OleView. It will peek inside COM libraries and give you the
interface definitions.
As to why CoCreateInstance isn't working, make sure you're
calling CoInitialize or CoInitializeEx beforehand. If it's still
failing, use std.windows.syserror.sysErrorString(hr) to see if it
gives you a reason. Otherwise, CLSCTX_ALL might be the culprit -
try using CLSCTX_SERVER instead.
Re: foo => "bar" key/value literals in D!
On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev wrote:
This is by far the most appealing way to implement named
arguments that I've seen so far:
https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d
Another cool thing this enables: object initializers.
T init(T, Args...)() {
import std.traits : FunctionTypeOf;
static struct DummyType {}
static if (is(T == class)) T r = new T;
else T r;
foreach (arg; Args) {
alias fun = arg!DummyType;
static if (is(FunctionTypeOf!fun PT == __parameters)) {
enum name = __traits(identifier, PT);
foreach (m; __traits(allMembers, T)) {
static if (name == m) __traits(getMember, r, m) =
fun(DummyType.init);
}
}
}
return r;
}
struct Point {
int x, y;
}
void main() {
auto pt = init!(Point, x => 123, y => 456);
assert(pt.x == 123 && pt.y == 456);
}
Re: Implicit conversion of struct to bool for if (s) operation ?
On Monday, 6 June 2016 at 15:23:50 UTC, chmike wrote:
Hello,
I have a structure with two fields ad defined as
struct Info {
this(int value, Category category)
{
category_ = category;
value_ = category ? value : 0;
}
// This converts implicitly to bool.
T opCast(T : bool)() {
return category_ !is null;
}
...
private:
Category category_ = null;
int value_ = 0;
}
I would like an implicit conversion of Info to bool that return
false if category_ is null so that I can write
Info s = foo();
if (s) {
...
}
and where
Info s2;
assert(!s2);
See the inserted code above.
Re: Request assistance binding to Windows dsound.{lib, dll}
Additionally, remove QueryInterface, AddRef and Release from the definition of IDirectSound. Also, interfaces are already references, so the definition of LPDIRECTSOUND should be: alias LPDIRECTSOUND = IDirectSound; Note there should be no *. Regarding any linking errors, it's easier to either grab the .lib files from the Windows SDK and convert them with coffimplib, or use the m32mscoff switch so you can link with the SDK .lib files directly.
Re: C#7 features
On Monday, 9 May 2016 at 00:44:09 UTC, Peter Häggman wrote:
Their tuples seem to be a complete DIY:
https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx
C# 7's tuples are something different though. They don't even map
to System.Tuple. The syntax is:
(int x, int y) GetPoint() {
return (500, 400);
}
var p = GetPoint();
Console.WriteLine($"{p.x}, {p.y}");
Specialized template in different module
If I define a template in one module, and specialize it in a
second module, the compiler doesn't like it when I try to call a
function using the template.
module one;
struct Test(T) {}
void testing(T)(Test!T t) {}
module two;
struct Test(T : int) {}
void main() {
Test!int i;
testing!int(i);
}
Output:
error : testing (Test!int t) is not callable using argument
types (Test!int)
If I put everything in the same module it works. So are template
specializations limited to the same module?
Re: Trying to build a Scheme interpreter in D
On Wednesday, 9 March 2016 at 20:30:44 UTC, Guillaume Piolat wrote: On Tuesday, 8 March 2016 at 18:11:24 UTC, John wrote: You can go with Algebraic. I used to do that in scheme-d. Then I switched to a tagged union by hand to avoid a compiler regression. Algebraic was OK. 2x speed difference between DMD and LDC is common. You can build with -g and use Instruments. Thank you for your advice.
Trying to build a Scheme interpreter in D
Hi,
I'm currently reading "Programming in D" and in order to get
accustomed to D and it's syntax, I've decided to implement
(actually port) a simple (and naive) Scheme interpreter from C to
D. The original interpreter (in C) is described in a series of
posts here:
http://peter.michaux.ca/articles/scheme-from-scratch-introduction
I've followed the tutorials and implemented various versions of
the interpreter in different languages, and now I've decided to
make a port to D. My source code resides in:
https://bitbucket.org/jfourkiotis/deimos
The basic object in my (naive, I repeat again) implementation, is
the following:
alias Object = Algebraic!(
long , /* numbers */
bool , /* #t or #f */
char , /* characters*/
string, /* symbols */
char[], /* strings */
EmptyList , /* Nil */
ConsCell ,
void function(This*, This*), /* primitive procedures */
CompoundProc); /* compound procedures */
where the following type definitions hold:
struct EmptyList {}
class ConsCell {
Object car;
Object cdr;
this(Object car, Object cdr)
{
this.car = car;
this.cdr = cdr;
}
}
So, I have the following questions:
* For this kind of implementation, is the Algebraic type a good
choice ? Is a simple union perhaps better ?
* I've defined the (recursive) Fibonacci function, for which DMD
takes 30sec to calculate Fibonacci(30) and LDC takes 10sec. Is
this a reasonable difference between the two compilers?
* I find it very difficult (actually impossible) to profile code
in Mac OS X. There is no output for options -profile. Are there
any other profiling/debugging tools for the Mac OS X ? My other
ports (C++, Scala) run interpret the same example in under 2sec,
so I would like to detect where my bottlenecks are.
Thanks.
ps: Any advice to make my code "better" (and more D-compliant)
are appreciated.
Re: Create Windows "shortcut" (.lnk) with D?
On Sunday, 6 March 2016 at 03:13:23 UTC, 岩倉 澪 wrote: IShellLinkA* shellLink; IPersistFile* linkFile; Any help would be highly appreciated as I'm new to Windows programming in D and have no idea what I'm doing wrong! In D, interfaces are references, so it should be: IShellLinkA shellLink; IPersistFile linkFile;
Re: @property not available for classes?
On Friday, 1 January 2016 at 10:14:58 UTC, Shriramana Sharma
wrote:
Hello. I'm trying the following code:
import std.stdio;
class TimeSpan
{
immutable double start, end;
@property double length() { return end - start; }
}
void main()
{
auto p = TimeSpan(1, 2);
writeln(p.length);
}
...and I'm getting the error:
Error: no property 'opCall' for type '.TimeSpan'
If I change the class to struct the @property is callable
without parens but I need TimeSpan to be a class since I need
to inherit from it.
http://dlang.org/property.html and
http://dlang.org/spec/function.html#property-functions don't
say anything about @property not being applicable for classes.
Am I stuck with having to use the () for this even in D?
The error is actually referring to the lack of a suitable
constructor. It thinks TimeSpan should define opCall because of
the way you're trying to create an instance your main function.
It's nothing to do with the @property attribute. So you need to
define a constructor. Also, use "new" when creating instances.
Alternatively, make it a struct and it will work as is without
further changes.
Re: Moving forward with work on the D language and foundation
On Thursday, 27 August 2015 at 16:01:54 UTC, BBasile wrote: That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. The lifespan has been steadily increasing. Andrew could work for another 50 years! That means he is very young right now and free to do anything he wants.
Re: Moving forward with work on the D language and foundation
On Monday, 31 August 2015 at 23:27:40 UTC, John wrote: The lifespan has been steadily increasing. Andrew could work for another 50 years! That means he is very young right now and free to do anything he wants. Sorry for misspelling Andrei's name.
Re: "Programming in D" paper book is available for purchase
On Wednesday, 19 August 2015 at 00:57:32 UTC, Ali Çehreli wrote: I am very happy! :) It will be available on many other distribution channels like Amazon in a few days as well but the following is the link that pays me the most royalty: https://www.createspace.com/5618128 Awesome! Congratulations!! I'll order that.
Re: New D book available for pre-order: D Web Development
On Wednesday, 22 July 2015 at 15:29:20 UTC, Kai Nacke wrote: my book D Web Development, available now for pre-order: https://www.packtpub.com/web-development/d-web-development Thanks! I have pre-ordered your book though I'm currently playing with Rust and Go. The performance of D is pulling me back all the time. So I'll buy and read every single D book out there! :)
Re: Rant after trying Rust a bit
On Tuesday, 28 July 2015 at 15:39:13 UTC, John wrote: I wish all the D related posts go under the sub-reddit https://www.reddit.com/r/dlang dlang is a familiar name due to the dlang.org itself. Also, the pattern is easy to guess, like the golang. You may be having tens of sub-reddits for D but they all look non-standard and confusing at best. To make my point more clear, the other language groups post their announcements to their respective sub-reddits like r/rust, r/golang etc, while D group tries to post *everything* directly to the r/programming. This is what makes them call it a spam.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 20:50:53 UTC, simendsjo wrote: If I'm not mistaken, people of the D community have tried to market the language quite heavily. I don't know why more people haven't joined, and it's even more baffeling to see the comments on Reddit calling D related posts spam and speaking negatively of the marketing on a site where upvotes dictates the ranking on the front page. I wish all the D related posts go under the sub-reddit https://www.reddit.com/r/dlang dlang is a familiar name due to the dlang.org itself. Also, the pattern is easy to guess, like the golang. You may be having tens of sub-reddits for D but they all look non-standard and confusing at best.
Calling D Code from Assembly
Is there a way I can call D code from assembly without declaring functions as extern(C) and and doing it the C way?
Re: Calling D Code from Assembly
On Sunday, 12 July 2015 at 04:30:58 UTC, John wrote: Is there a way I can call D code from assembly without declaring functions as extern(C) and and doing it the C way? SOLVED: Found the calling convention description. http://dlang.org/abi.html
Re: Martin Nowak's talk cancelled
On Tuesday, 26 May 2015 at 21:45:26 UTC, Adam D. Ruppe wrote: If worse comes to worst, I can probably improvise something to fill the time... don't expect slides though :P LOL :D
Using arrays of function pointers in D
I've been rewriting one of my emulators in D and am fairly new to the language. I'm having trouble finding documentation on creating/initializing/use of arrays of function pointers in D. If anyone has a code example I'd appreciate it!
Re: Using arrays of function pointers in D
On Thursday, 21 May 2015 at 16:25:24 UTC, Adam D. Ruppe wrote: Start with a function type declaration: void function() func_ptr; Then make an array out of it: void function()[] func_ptr_array; It works like other arrays, just the [] might be a little harder to see since it is a much longer type signature. But it is still in there, right after it, similarly to int[]. Then the array is indexed and set like normal. You can change length on it (auto initializes all members to null), ~= my_func to append, etc. You can also do associative arrays of function pointers btw. Thanks! Holy moly you guys are quick in here.
Re: 2015 H1 Vision
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu wrote: Hello, Walter and I have been mulling for a while on a vision for the first six months of 2015. http://wiki.dlang.org/Vision/2015H1 This is stuff we consider important for D going forward and plan to work actively on. We encourage the D community to focus contributions along the same lines. This is great, thanks! Btw, people usually search for Dlang roadmap. Please use the word roadmap somewhere to make it searchable. Also, a generic link would be nice, without that 2015H1 in the url.
Re: [OT?] C compiler written form scratch in D
On Monday, 15 December 2014 at 12:37:18 UTC, Stefan Koch wrote: New videos are online :) part 1: https://www.youtube.com/watch?v=_YAUfd41URA part 2: https://www.youtube.com/watch?v=RGLgiPhwskM please give me feedback in this thread I have watched the videos in speed 2 (double speed) and they look pretty good, thanks.
Re: [OT?] C compiler written form scratch in D
On Monday, 8 December 2014 at 19:35:54 UTC, Stefan Koch wrote: On Monday, 8 December 2014 at 17:26:59 UTC, John Colvin wrote: On Monday, 8 December 2014 at 16:28:24 UTC, Stefan Koch wrote: First two videos are up think of them as beta quality! https://www.youtube.com/watch?v=aeBSsuCCRFo and https://www.youtube.com/watch?v=crQk929crCE The quality is completely shot for both audio and video. The text is very fuzzy even in 720p and the audio has been subject to some extreme lossy compression. The audio-input is very bad! what you are hearing are not compression artifacts it's the noise filter hard at work. You may have to either pause when you need to cough and sneeze or just edit that out. I am interested in this topic but the horrible quality of audio video made me puke.
Re: Programming in D book, draft of the first print edition and eBook formats
Cool!
Re: Programming Language for Games, part 3
On Saturday, 1 November 2014 at 20:14:15 UTC, Walter Bright wrote: Jonathan is reinventing D with a somewhat different syntax. Some points on the video: May be you should have a couple of beers with him too, just like you did with Andrei a long time ago! :)
Need assistance translating this C++ template
Howdy,
I stumbled across a tiny NES emulator written in C++
(http://bisqwit.iki.fi/jutut/kuvat/programming_examples/nesemu1/nesemu1.cc)
that I feel compelled to make even tinier with some D magic. I am
having trouble with a nested template in the code.
The C++ code:
// Bitfield utilities
templateunsigned bitno, unsigned nbits=1, typename T=u8
struct RegBit
{
T data;
enum { mask = (1u nbits) - 1u };
templatetypename T2
RegBit operator=(T2 val)
{
data = (data ~(mask bitno)) | ((nbits 1 ? val
mask : !!val) bitno);
return *this;
}
operator unsigned() const { return (data bitno) mask; }
RegBit operator++ () { return *this = *this + 1; }
unsigned operator++ (int) { unsigned r = *this; ++*this;
return r; }
};
My D implementation thus far:
// To avoid type confusion...
alias u8 = uint_least8_t;
alias u32 = uint_least32_t;
template RegBit(uint bitno, uint nbits = 1, T = u8) {
T data;
enum { mask = (1u nbits) - 1u }
// FIXME: Nested template frustration here... HELP
void opAssign(T2 val)
{
data = (data ~(mask bitno)) | ((nbits 1 ? val
mask : !!val) bitno);
return *this;
}
auto opCall() { return (data bitno) mask; }
ref RegBit opUnary(string s)() if (s == ++) { return *this
= *this + 1; }
ref RegBit opUnary(string s)(int) if (s== ++) { uint r =
*this; ++*this; return r; }
}
Any push in the right direction would be greatly appreciated. I'm
just trying to get a D implementation up and running before I
start making this smaller and more intuitive.
Re: Need assistance translating this C++ template
On Monday, 27 October 2014 at 23:19:42 UTC, anonymous wrote:
On Monday, 27 October 2014 at 22:43:23 UTC, John wrote:
The C++ code:
// Bitfield utilities
templateunsigned bitno, unsigned nbits=1, typename T=u8
struct RegBit
{
[...]
templatetypename T2
RegBit operator=(T2 val)
[...]
};
My D implementation thus far:
[...]
template RegBit(uint bitno, uint nbits = 1, T = u8) {
You're missing the struct here. Add some (template) parameters
to
a struct, and it becomes a struct template:
struct RegBit(uint bitno, uint nbits = 1, T = u8)
[...]
// FIXME: Nested template frustration here... HELP
void opAssign(T2 val)
Similarly, add another set of (template) parameters to a
function/method, before the runtime parameters, and it becomes a
function/method template:
void opAssign(T2)(T2 val)
[...]
}
Those slap another set of parameters on, and it's a template
syntaxes, are sugar for the longer eponymous member variant:
struct Foo(T) {}
is equivalent to
template Foo(T)
{
struct Foo /* same name as the template */
{
/* ... */
}
}
Works with structs, classes, functions, etc.
So if you wanted to spell the templates out, it would look like
this:
template RegBit(uint bitno, uint nbits = 1, T = u8)
{
struct RegBit
{
/* ... other members of RegBit ... */
template opAssign(T2)
{
void opAssign(T2 val)
{
/* ... implementation of opAssign ... */
}
}
/* ... other members of RegBit ... */
}
}
Much appreciated! I saw I didn't even make it a struct shortly
after posting, time to take a nap and restrain the caffeine
intake. And thanks for the missing parameter, Justin.
Re: D in my trashbin
On Friday, 24 October 2014 at 02:42:13 UTC, frustrated wrote: Two days later and I still cant get a 'Hello World' to compile. It is far beyond me how a project can exist for so many years and still not have a straightforward installation that works out of the box. Yes.. read the forums and search google for solutions that may or may not work depending on the phases of the moon, I have to ask you: Why bother ? Why would anybody trust a compiler written by people who regard making it run out of the box an after-thought ? It does run out of the box. May be you were in a bad mood. Please try the D.learn group.
Re: D on TV - FLOSS Weekly 311
On Wednesday, 8 October 2014 at 22:26:36 UTC, Walter Bright wrote: alias the Walter Andrei show! http://twit.tv/show/floss-weekly/311 Interesting talk! I wish you had some lighting on you. You are hardly visible!
How can I use AVX instructions in D inline asm?
Hi.
Now I try to use SSE/AVX instructions in D inline asm.
I have a trouble about this.
In http://dlang.org/iasm.html ,
AVX seems to be supported according to SIMD section in the paeg.
But there is no AVX opcodes, like vaddps, in Opcodes section in
the page.
So I have assumed addps can be used as vaddps with AVX registers,
and I compile the following three code.
//1
asm
{
addps XMM0, XMM1;
}
//2
asm
{
addps YMM0, YMM1;
}
//3
asm
{
vaddps YMM0, YMM1;
}
1 - OK
2 - undefined identifier YMMx (??? I expect OK or invalid
operands.)
3 - unkown opcode 'vaddps'(reasonable)
I have used ldc2 with llvm 3.5 and the compile following command.
ldc2 test.d -m64 -mcpu=core-avx2
My CPU supports AVX too.
Please point out what's wrong.
Thank you.
Re: LDC 0.14.0 released!
On Wednesday, 20 August 2014 at 04:48:02 UTC, Kai Nacke wrote: I managed to get mentioned in LLVM Weekly again. (http://llvmweekly.org/issue/33) LLVM weekly is a newsletter with high attention in the LLVM world. Regards, Kai Cool!
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 17:06:31 UTC, Walter Bright wrote: On 8/22/2014 1:18 AM, Daniel Murphy wrote: There are two reason it's not better documented: 1. I hate writing documentation. I really really hate it. Join the club :-) 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us. LOL! That's a hilarious comment! :)
const int vs. int const
This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works
Re: const int vs. int const
On Friday, 15 August 2014 at 17:16:45 UTC, Sean Kelly wrote: On Friday, 15 August 2014 at 17:05:55 UTC, John wrote: This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works It is intentional, and I think this best practice idea doesn't apply to D in the same was as C/C++. The reason this is an issue in C/C++ is because const char * is equivalent to char const *, but once typedefs and templates enter the picture things start to get confusing. Since D allows the const qualifier to use parens to specify what part of the type it applies to, we don't need to support the C style syntax. Ok, thanks for reply.
Re: const int vs. int const
On Friday, 15 August 2014 at 17:05:55 UTC, John wrote: This may be a silly issue, but I recently read the better practice is to begin with the variable type followed by const keyword, but that order doesn't work in D. Is that intentional? int const minWage = 11; //Error: no identifier for declarator int //const int minWage = 11; //works btw, it works either way if I use auto auto const minWage = 11; //works const auto minWage = 11; //works The same flexibility is missing when the actual type is used.
Re: Programming in D book is 100% translated
On Thursday, 24 July 2014 at 08:11:01 UTC, Ali Çehreli wrote: I have completed the translation of the book. Phew... :) However, there is still more work, like adding a UDA chapter and working on many little TODO items. The following was the final chapter, which actually only scratches the surface of the very broad topic: * Memory Management As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali Congratulations! And thank you for writing this book!
Re: Looking to hire: 2-3 programmers, candidates will likely need to learn D.
On Monday, 21 July 2014 at 02:43:51 UTC, Vic wrote: (I hope OK to post:) Location: Silicon Valley /San Jose, CA/ or Dallas TX. Current 'app' version is mostly Java/Tomcat, so will need to maintain that while writing a new version, likely mostly D ( possibly Qt depending on GC ). (Also a few lines assembly, C, IOS Objective C, Andorid as clients) OS will be Gentoo flavor. There is some fun data structures and some boring HTTP in the project, I'll have to tell you more if you ping us, some of it is fun tech but I don't want it public. The company is a 7 digit funded start up, a bit more about the project - http://ceocfointerviews.com/interviews/Apakau14.htm Ideal candiate is a career programmer/developer, prolific coder would be supper. Experience prefered, a few years out of school might be considered. Company culture is tech friendly/introvert (as opposed to marketing/business type orgs). Market rate salary, but first few hire we don't have much for reloaction budget(not looking for remote for first year+). Of course 30 monitor, Xeon workstation, good vacation time, gym and more, of course D conference or similar is company expense. There are some trade secrets to keep. To have a phone chat, please email me your resume/bio to vic (at) apakau.com. Likely we will be done hiring in a week or 2. (I plan to cross post on Qt and Vibe.d forums) You might want to post to D.announce group. Some D users claim they only check D.announce
Re: DConf 2014: Adam D Ruppe's amazing slideless talk on x86 Bare Metal and Custom Runtime Programming
On Friday, 18 July 2014 at 08:35:07 UTC, Puming wrote: I've added an indirect link to my awesome-d github page Your awesome-d is awesome! Keep up the good work! :D I didn't know this concept using github. Now I started exploring the other awesome pages of less than awesome languages too. Thanks.
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
On Tuesday, 15 July 2014 at 19:00:35 UTC, Walter Bright wrote: On 7/15/2014 11:28 AM, John wrote: At the end of this video, it sounds like it ends abruptly.. While answering a question, Walter says.. 'it turns out..' and the video ends there. That's when my time ran out and I vanished in a puff of greasy black smoke. :D
Re: GCs in the news
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote: It's not about acceptance, it's about the reality that a GC is not a universal solution to memory management. Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern. If D came without GC, it would have replaced C++ a long time ago!
Re: Weird…
On Wednesday, 16 July 2014 at 17:47:09 UTC, Nick Sabalausky wrote: On 7/15/2014 3:56 PM, Robert burner Schadek wrote: On Tuesday, 15 July 2014 at 18:28:14 UTC, Walter Bright wrote: Even more amazing, Germans all have D plastered on their cars! So we don't forget were we are :D That's always been my preferred explanation for Americans posting US flags on their houses and cars. :) Uhh, yes, I'm well aware what country I'm in. I'm not THAT drunk... :D
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
On Tuesday, 15 July 2014 at 16:20:34 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/ https://www.facebook.com/dlang.org/posts/885322668148082 https://twitter.com/D_Programming/status/489081312297635840 Andrei Thanks for posting these videos. At the end of this video, it sounds like it ends abruptly.. While answering a question, Walter says.. 'it turns out..' and the video ends there.
Re: DMD v2.066.0-b2
On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote: If nothing is identified, I will abandon the idea of providing point releases. Managing multiple Alpha or Beta builds with a1, a2 .. or b1, b2 etc look good. Adding another point-number to the 2.066 like 2.066.1 is a needless confusion, unless you have already released 2.066 and coming up with an intermediate release before 2.067
Re: Smile, you're on Wired
On Tuesday, 8 July 2014 at 14:29:31 UTC, Adam D. Ruppe wrote: The reddit response is really positive too it looks like, cool. That is as exciting as the article itself!
Re: Smile, you're on Wired
On Tuesday, 8 July 2014 at 15:44:26 UTC, Iain Buclaw via Digitalmars-d-announce wrote: On 8 July 2014 15:29, Adam D. Ruppe via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: The reddit response is really positive too it looks like, cool. Just goes to show that when it comes from a source that people may consider trustworthy, they genuinely take notice and listen. :) +1
Re: Worrying attitudes to the branding of the D language
On Tuesday, 1 July 2014 at 18:02:16 UTC, Gary Willoughby wrote: On Tuesday, 1 July 2014 at 17:49:57 UTC, w0rp wrote: No. This is the attitude i am expressly writing about. I guess everybody has some attitude problems. For example, you won't capitalize the i in your writings, no matter how many people told you that it's odd and distracting while reading your posts or articles.
Time to rename D to @D !?
The @ symbols used on all those attributes like @nogc @nothrow @pure @safe make the D code look ugly. If possible, please get rid of those @ symbols. The attributes look good without the @ symbols.
Re: Thanks for the bounty!
On Thursday, 19 June 2014 at 22:27:58 UTC, Andrej Mitrovic via Digitalmars-d wrote: I claimed a bounty recently, and I just wanted to say thanks to Andrei and his company for backing the bounty. I won't be able to take any future bounties from Facebook due to internal competition policies, but that's ok as I'm now a paid programmer anyway. :) It was fun to win something while coding! Cheers! Congratulations!
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
On Tuesday, 17 June 2014 at 22:09:06 UTC, Joakim wrote: Nobody paid attention to ruby for a decade, until David Hansson built rails with it. I am hoping the vibe.d will do that magic to D. I need support for MS SQL Server to use it in production though.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 18:50:14 UTC, Meta wrote: I wonder where he got the idea that D isn't high performance... Perhaps the fact that it has a GC? He probably went to http://dlang.org/ and clicked the Run button on the code example there.
Re: A Perspective on D from game industry
On Monday, 16 June 2014 at 21:00:59 UTC, John wrote: On Sunday, 15 June 2014 at 18:50:14 UTC, Meta wrote: I wonder where he got the idea that D isn't high performance... Perhaps the fact that it has a GC? He probably went to http://dlang.org/ and clicked the Run button on the code example there. It would be nice if it shows how long the executable ran to get the results.
Re: DGui newsgroup in Dlang
On Thursday, 12 June 2014 at 19:38:06 UTC, André wrote: Hi, Is it possible to add a newsgroup for DGui on this forum? It would be great to have a communication platform and also advertising this really great Windows ui toolkit. With an easy to use and powerful native D ui toolkit like DGui a lot of new D developers can be reached and attracted. Kind regards André It's a good idea to start a D.gui group and let all the gui developers and their users discuss their stuff there.
dlang website: remove that quick try editor
dlang.org website has a quick try editor with D code example. Please remove that feature (at least the buttons to run it) as it takes ages to run the example and leaves an impression that D is very slow!! This is only good if it can run quickly like the similar feature available on the golang website. If you love this feature and refuse to remove it, at least please move it to another page. You don't want to lose people within minutes of their first visit to D website with a total misunderstanding of the purpose and power of the D language.
Re: dlang website: remove that quick try editor
On Sunday, 8 June 2014 at 21:46:15 UTC, Martin Nowak wrote: Yeah, it's really slow right now. Please contact the DPaste people and help to find out why. http://dpaste.dzfl.pl/home Thanks for the link. I wrote to them through the message option on their contact page: Hi guys, I understand you are responsible for the D quick try example editor on the dlang.org It is running very slow.. please either speed it up or remove that feature from dlang website. It is turning off new visitors from exploring D any further, leaving an impression that D language itself is very slow!! I have been randomly watching it for the past one year and I can say it is always been slow to very slow. No good if you compare it to the similar feature available on the golang website that runs pretty quick. Thanks, John
Re: [OT] Extra time spent
On Wednesday, 4 June 2014 at 19:04:19 UTC, H. S. Teoh via Digitalmars-d wrote: It's strange, I find that even ambient music distracts me, yet the loud noise of an occasional passing train doesn't. Similarly, even whispers will distract me, but birds chirping, trees rustling, etc., don't. It's something about intelligible sounds that engage my brain somehow, that non-intelligible sounds don't have. So far, I haven't found anybody else who experiences the same thing. Me too! I think it's pretty much the default human nature through evaluation! We keep filtering / ignoring the usual noises so that we can pick up on new ones, just like our noses ignoring an existing smell to be able to recognize a new smell. Similarly, it is easy to hear own name despite all the noise in a crowded room.
zip with fieldTuple
So let's say I'm trying to create a really simple ORM. I have a
struct:
struct foo {
int a;
float b;
}
I can iterate over the struct elements with the traits
FieldTypeTuple!foo, I can iterate over the the string that
represents the elements I want to shove in the struct, but when I
try to loop over *both* of these at the same time with zip(...) I
get an error. Code:
void main() {
string test = 1,2.0;
foreach (t, value; zip(FieldTypeTuple!foo, test.split(,))) {
writeln(to!t(value));
}
}
Error:
src\orm.d(13): Error: template std.range.zip does not match any
function template declaration
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range.d(3808): Error:
template std.range.zip cannot deduce template function from
argument types !()((int, float),string[])
I get what the error message is saying, but I have no idea how to
fix the code to do what I want. I tried to look up what the
FieldTypeTuple actually returns but it's calling a method on the
generic type T called tupleOf(), which I can't seem to find (in
that file or as a general function on object). I'm not sure if
it's actually a range? I assumed it would be a range of some
kind, and each of the elements would have a supertype of
something like 'type' since that's what they are. It could infer
that now you have two ranges, one of 'type' and one of 'string'.
If I'm able to foreach over two things, shouldn't I be able to
foreach over the paired ranges with zip? It seems so simple...
Re: zip with fieldTuple
On Friday, 6 June 2014 at 22:27:38 UTC, bearophile wrote: John: I can iterate over the struct elements with the traits FieldTypeTuple!foo, In such iteration you are using a static foreach. Types are compile-time constructs in D. If you need run-time entities you need to get their typeinfo. I don't want to do that lookup at runtime though. Clearly my intent is to rewrite this foreach zip expression as: auto s = test.split(,); writeln(to!int(s[0])); writeln(to!float(s[1])); or maybe: auto s = test.split(,); writeln(to!int(s.front)); s.popFront(); writeln(to!float(s.front)); But I don't want to actually hand write that each time. I can iterate over the the string that represents the elements I want to shove in the struct, This is a dynamic (regular) foreach. Yes. but when I try to loop over *both* of these at the same time with zip(...) I get an error. zip only works on run time values. So you can't zip a built-in typetuple of types with a range of values. Conceptually that is what I want to do though. I want to pair the type with the string that I'm going to convert. I'm not sure if it's actually a range? I assumed it would be a range of some kind, It's not a range. FieldTypeTuple returns a built-in typetuple that in this case is really a built-in of types, that are purely compile-time entities. I get that. and each of the elements would have a supertype of something like 'type' since that's what they are. They are types (and they aren't other things like uninstantiated templates that in D are another kind), but not even in our dreams there is a supertype for them :-) It could infer that now you have two ranges, one of 'type' and one of 'string'. Nope. If I'm able to foreach over two things, shouldn't I be able to foreach over the paired ranges with zip? It seems so simple... If you turn the built-in typetuple of types into an array or lazy range of typeinfo, then you can zip them. But I don't think this is a good idea. It's better to forget the zipping and use a static foreach on the types, using also an index, and use such index to access the second array of run time values. I had already considered a workaround like that, but it's just that. A workaround. You already do unrolling for templates, this isn't much different (at least conceptually). You could basically do exactly what you're describing in the library, no? Have zip loop over all the static/compile time fields (assuming you can separate them in the template from the runtime ranges), and index into (or pop range) the runtime ranges with length checks. The compiler would unroll the compile time ranges (or whatever you want to call them) creating essentially exactly what you've described, the other poster mentioned, and precisely what I put above. Is that not possible? Bye, bearophile
Re: Swift is based LLVM,what will the D's LDC do?
On Thursday, 5 June 2014 at 06:40:17 UTC, Walter Bright wrote: On 6/4/2014 9:25 AM, Iain Buclaw via Digitalmars-d wrote: This likewise gdc too. All you need to do is look at the downloads page on dlang.org ! It still says nothing about doing: sudo apt-get install gdc on Ubuntu! Why keep it a secret? :-) Cool! I wish installing ldc is this easy too!
