Re: Vision
On Thursday, 22 October 2015 at 14:07:17 UTC, Adam D. Ruppe wrote: On Thursday, 22 October 2015 at 13:26:37 UTC, Szymon Gatner wrote: At the moment, simplest integration presented in Adam Ruppe's book does not work on Windows (x64 or x86). Have you tried a C++ class without a virtual destructor too? That's the trickiest part in the first part of the book and maybe that is what broke recently. I haven't tried any of this for like a year now. The other part about mimicing with structs is a fragile thing anyway, I presented it because you can make it work, you're just on your own. No, I just tried your code verbatim (as I do with every new D release). Problem now is casting Animal down to Cat (in freeCat()) on the D side, casting results in null after pointer was passed to C++. I have no idea what is suppose to work in D/C++ interop as there is very little (or outdated) information on the subject.
Re: Vision
On Wednesday, 21 October 2015 at 20:50:29 UTC, Andrei Alexandrescu wrote: Better late than later. http://wiki.dlang.org/Vision/2015H2_(draft) Destroy. After we make this good I'll rename it and make it official. Andrei "C++ integration Progress has been slow." At the moment, simplest integration presented in Adam Ruppe's book does not work on Windows (x64 or x86). I stopped dreaming about things like STL interop as for the last 4 releases just using polymorphic class between languages still isn't fixed.
Re: Vision
On Thursday, 22 October 2015 at 15:09:19 UTC, Jonathan M Davis wrote: On Thursday, 22 October 2015 at 14:39:14 UTC, Rikki Cattermole wrote: On 23/10/15 3:13 AM, Jack Stouffer wrote: [...] And yet projects like dlangui keep on dying. Obviously something is not right with how they are. Projects typically die because they don't have enough people involved (frequently only one) and those who are involved no longer have the time and/or interest. Maybe the color stuff belongs in Phobos. Maybe not. But IMHO, concerns about 3rd party projects dying off is _not_ a good reason to put something in the standard library. I don't think that we want large amounts of code being thrown into Phobos on the theory that the Phobos devs will maintain it and whoever wrote it can stop caring. - Jonathan M Davis I'd say that projects die becaus they don't have users/traction. This is very discouraging to the author as he looses faith that the project makes sense in the first place
Re: Beta D 2.069.0-b1
On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote: On 13.10.2015 21:44, ZombineDev wrote: [...] The library issues are the same for 32-bit and 64-bit. [...] Yes, but there is some magic involved when linking against the VS2015 CRT. To use symbols like snprintf and sscanf, you must also pass legacy_stdio_definitions.lib to the linker, which is done automatically if you use dmd as a frontend to the linker, but not cl. Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted by the compiler if you compile main, WinMain or DllMain. Unfortunately, compiling D's main also generates a C-style main, so it's not so easy to get these symbols if you need main in C/C++. I would currently recommend to write main in D, and call into C/C++ from there. I am trying (as with every new release ;)) to link static D library to existing C++ project and I am having same issue: Error 2 error LNK2019: unresolved external symbol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb C:\Users\Bravo\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj) ConsoleApplication1 _minfo_beg, _minfo_end problems were solved by adding main() to D library so this is only porblem left. I am using Visual Studio 2012
Re: Beta D 2.069.0-b1
On Wednesday, 14 October 2015 at 11:46:27 UTC, ZombineDev wrote: 2) How can I workaround the problem that _minfo* and _deh* are not generated because my main is in C++? Just add a file with int main() in D library to fix this.
Re: Beta D 2.069.0-b1
On Wednesday, 14 October 2015 at 11:39:26 UTC, Szymon Gatner wrote: On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote: [...] I am trying (as with every new release ;)) to link static D library to existing C++ project and I am having same issue: Error 2 error LNK2019: unresolved external symbol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb C:\Users\Bravo\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj) ConsoleApplication1 _minfo_beg, _minfo_end problems were solved by adding main() to D library so this is only porblem left. I am using Visual Studio 2012 Update: Linking with static D library under Visual Studio 2015 works fine (which is great). I do need to make it work under VS 2012 tho. Ideas?
Re: Beta D 2.069.0-b1
On Wednesday, 14 October 2015 at 12:05:28 UTC, Szymon Gatner wrote: On Wednesday, 14 October 2015 at 11:39:26 UTC, Szymon Gatner wrote: On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote: [...] I am trying (as with every new release ;)) to link static D library to existing C++ project and I am having same issue: Error 2 error LNK2019: unresolved external symbol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb C:\Users\Bravo\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj) ConsoleApplication1 _minfo_beg, _minfo_end problems were solved by adding main() to D library so this is only porblem left. I am using Visual Studio 2012 Update: Linking with static D library under Visual Studio 2015 works fine (which is great). I do need to make it work under VS 2012 tho. Ideas? Another Update: a bug I reported many moons ago is still there when mixing C++ with D. I updated the issue: https://issues.dlang.org/show_bug.cgi?id=14327
Re: Beta D 2.069.0-b1
On Wednesday, 14 October 2015 at 12:35:30 UTC, Rainer Schuetze
wrote:
I just noticed that the magic symbol translation _snprintf ->
__snprintf isn't included without linking the internal function
init_msvc (which is normally done by d_run_main which is called
by the generated C main).
The current workaround here is to add
extern "C" void __cdecl init_msvc();
to the C source and call it before rt_init. I think we should
move it into rt_init inside druntime.
This indeed helps, thanks!
There is new problem: creating a class instance on D side, then
passing it to C++ and then back to D causes casting errors. My
Example (based on Adam Ruppe's example):
C++ file:
#include
#include
extern "C" int rt_init();
extern "C" void rt_term();
extern "C++" int sumInD(int a, int b);
extern "C++" void printHelloInD();
class Operation {
public:
virtual ~Operation() {}
virtual int execute(int a, int b) = 0;
};
class Add : public Operation
{
int execute(int a, int b) override
{
return a + b;
}
};
extern "C++" void useOperation(Operation* t);
extern "C++" Operation* getSubtract();
extern "C++" void freeSubtract(Operation* cat);
struct DRuntime
{
DRuntime()
{
if (!rt_init())\
{
throw std::runtime_error("D Initialization failed");
}
}
~DRuntime()
{
rt_term();
}
};
void main()
{
DRuntime druntime;
Add add;
useOperation();
Operation* sub = getSubtract();
auto value = sub->execute(5, 3);
freeSubtract(sub);
}
D library:
module lib;
import std.stdio;
import core.stdc.stdlib;
int main()
{
return 0;
}
extern(C++)
interface Operation {
void _destructorDoNotUse();
int execute(int a, int b);
}
class Subtract : Operation {
extern(C++)
void _destructorDoNotUse() {}
extern(C++)
int execute(int a, int b) {return a - b;}
}
extern(C++)
Operation getSubtract() {
import std.conv;
enum size = __traits(classInstanceSize, Subtract);
auto memory = malloc(size)[0 .. size];
return emplace!Subtract(memory);
}
extern (C++) int sumInD(int a, int b)
{
return a + b;
}
extern (C++) void printHelloInD()
{
writeln("Hello From D!"); << = throws exception (bug
reported)
}
extern(C++)
void freeSubtract(Operation animal) {
auto cat = cast(Subtract) animal; <<== cast yields null
if(cat !is null) {
destroy(cat);
free(cast(void*) cat);
}
}
extern(C++)
void useOperation(Operation t) {
auto res = t.execute(1, 2);
}
Everything works fine except the marked line. Subtract instance
seems to be created correctly on D side as it returns valid
result in the execute() call on C++ side but then when trying to
free the instance on D side again, downcast from Operation to
Subtract fails resulting in null.
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut wrote: On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote: What about 32bit phobos? Last time I checked (2.067) only x64 was distributed. You have to compile it yourself. Use the win64 makefile and replace the arch=64 with arch=32mscoff. For more details see here: http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html Ah so that didn't change. Did you try it? Do you run hybrid C++/D apps on Win (whether 32 or 64)?. Asking because last time I tried it (Win x64 tho) writeln() call from D side crashed app because stdio wasn't properly initialized even tho rt_init() was successful.
Status of Win32 C++ interop
Hi, what is the current status of: - Win x86/32bit/coff32 interop with C++? - improvements for general C++ interop that were suppose to come with 2.068
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 08:58:41 UTC, Benjamin Thaut wrote: On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner wrote: Hi, what is the current status of: - Win x86/32bit/coff32 interop with C++? - improvements for general C++ interop that were suppose to come with 2.068 If you use either the -m64 or -mscoff32 interop should be pretty good. I'm currently using it heavily and its working quite nicely. What about 32bit phobos? Last time I checked (2.067) only x64 was distributed.
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote: On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner wrote: On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut wrote: On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote: What about 32bit phobos? Last time I checked (2.067) only x64 was distributed. You have to compile it yourself. Use the win64 makefile and replace the arch=64 with arch=32mscoff. For more details see here: http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html Ah so that didn't change. Did you try it? Do you run hybrid C++/D apps on Win (whether 32 or 64)?. Asking because last time I tried it (Win x64 tho) writeln() call from D side crashed app because stdio wasn't properly initialized even tho rt_init() was successful. I am running hybrid D/C++ apps. I found it to work best when you give D the control over the main method, e.g. the program entry point should be in D land. Then simply call a C++ function from there to initialize your c++ stuff. I'm currently even running hybrid C++/D apps with dlls. E.g. multiple D dlls + multiple C++ dlls loaded by a c++ main program. But to do that I have heavy compiler + runtime modifications which are not ready yet to do a PR for them. Hmm that is very good to hear, as is promising. In the mean time I tired making tiny Win x64 C++/D app as described by A.Ruppe in his book (I did that also when it was released and stdio was crashing apps) but now using phobos64.lib from 2.068 distribution does not even link properly with VC2015. Oh well, not just yet I suppose. Thanks for your assistance!
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 16:26:51 UTC, Kagamin wrote: On Friday, 4 September 2015 at 15:43:44 UTC, Szymon Gatner wrote: but now using phobos64.lib from 2.068 distribution does not even link properly with VC2015. That's https://issues.dlang.org/show_bug.cgi?id=14849 yup, that looks like it
Re: Interlocked (compare) exchange
On Friday, 17 April 2015 at 11:00:40 UTC, rumbu wrote: On Friday, 17 April 2015 at 10:36:33 UTC, Szymon Gatner wrote: Hi, are there equivalents of Interlocked.Exchange [1] and Interlocked.CompareExchange [2] in D? I can't find it in teh docs? [1] https://msdn.microsoft.com/en-us/library/f2090ex9(v=vs.110).aspx [2] https://msdn.microsoft.com/en-us/library/h7etff8w(v=vs.110).aspx All D equivalents of Interlocked class methods: https://github.com/rumbu13/sharp/blob/master/src/system/threading/package.d Ah, thanks to all you guys!
Interlocked (compare) exchange
Hi, are there equivalents of Interlocked.Exchange [1] and Interlocked.CompareExchange [2] in D? I can't find it in teh docs? [1] https://msdn.microsoft.com/en-us/library/f2090ex9(v=vs.110).aspx [2] https://msdn.microsoft.com/en-us/library/h7etff8w(v=vs.110).aspx
Re: [OT] Regarding most used operating system among devs
On Wednesday, 8 April 2015 at 16:19:44 UTC, weaselcat wrote: Poll has a windows bias due to stackoverflows focus on .NET, which is extremely overrepresented on SO(see: redmonk) Even if there is a bias how large can it be? It is not few % difference in the poll results.
Re: [OT] Regarding most used operating system among devs
On Wednesday, 8 April 2015 at 12:00:35 UTC, Kagamin wrote: http://stackoverflow.com/research/developer-survey-2015#tech-tabsspaces heh Yeah :) huh must be younger devs?
Re: [OT] Regarding most used operating system among devs
On Wednesday, 8 April 2015 at 10:34:19 UTC, Jens Bauer wrote: On Wednesday, 8 April 2015 at 08:59:04 UTC, Szymon Gatner wrote: From StackOverflow's 2015 Developer Survey [1]: Mac appears to have overtaken the Linuxes among active Stack Overflow devs. [1]http://stackoverflow.com/research/developer-survey-2015 If they wanted to have some more reliable numbers, they would make a web-page that shows a little more than an image of the Stackoverflow logo in some Web-browsers... -That's all I see. Works fine in Chrome and IE. I kindof doubt Joel Solsky can't do a wepage right
Re: Which D IDE do you use?(survey)
On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) voted for VisualD
[OT] Regarding most used operating system among devs
From StackOverflow's 2015 Developer Survey [1]: For the third year in a row, we asked respondents which operating system they use the most. Windows maintains the lion's share of the developer operating system market, while Mac appears to have overtaken the Linuxes among active Stack Overflow devs. Linux may be a small player on the consumer market, with just 1.5% of global desktop operating system share, but it's a go-to OS for developers. Interestingly, from the Text editor question we learn that most used ones are NotePad++ and Sublime Text (and not Visual Studio) which I know are favs among webdevelopers that are not used to IDEs (as debugging happens in web browsers). This correlates with with Most popular technologies results too. To sum up: Please give more attention to Windows developers like myself ;) [1]http://stackoverflow.com/research/developer-survey-2015
Re: [OT] Regarding most used operating system among devs
On Wednesday, 8 April 2015 at 12:34:06 UTC, Paulo Pinto wrote: Since then, I always favor spaces over tabs. One space is always one space. Not to start a war but agreed ;) 2 spaces (specifically) FTW!
Re: Language spec in free e-book format
On Wednesday, 8 April 2015 at 21:42:22 UTC, Nick wrote: On Wednesday, 8 April 2015 at 21:34:00 UTC, weaselcat wrote: On Wednesday, 8 April 2015 at 21:29:59 UTC, Nick wrote: Hi, Could you make the language reference available for download in a free e-book format, such as EPUB or FB2? Some people just don't have any app that reads MOBI or Kindle format; they are not very common outside some particular devices. Thanks. -- What's wrong with PDF? It's not the best format for small devices, the heuristical reflow often messes the formatting. Also, the Acrobat app is awful as an e-reader. -- Yup, pdf is terrible ebook format. In fact ebooks often don't even come in pdf
Re: UFCS and overloading
On Tuesday, 7 April 2015 at 14:46:52 UTC, cym13 wrote:
EDIT: mis-formatted previous snippet
import std.algorithm, std.stdio, std.range, std.conv;
void main()
{
stdin
.byLine
.filter!(s = !s.empty s.front != '#’) // Filter
with this lambda function
.map!(s = s.to!double) // Map the strings to doubles
.array // Sorting needs random access
.sort!((a, b) = a b) // Another lambda
.take(10) // Applyable to any range
.writeln;
}
Yup, I get that, still does not explain why UFCS can't extend
overload set. Especially if there would be no conflict wrt to
overload of method vs free function.
Re: UFCS and overloading
On Monday, 6 April 2015 at 17:53:13 UTC, Steven Schveighoffer
wrote:
On 4/6/15 12:23 PM, Szymon Gatner wrote:
Hi,
I am surprised that this doesn't work:
class Foo
{
void bar(string) {}
}
void bar(Foo foo, int i)
{
}
auto foo = new Foo();
foo.bar(123); // === error
causing compilation error:
main.d(24): Error: function main.Foo.bar (string _param_0) is
not
callable using argument types (int)
does UFCS now work with method overloading? I know it is not a
syntax
error because changing the name of int version of bar to bar2
and
calling foo.bar2(123) works fine.
You can't do this. UFCS cannot add overloads, it can only add
whole overload sets (if not already present).
-Steve
Why is that? The use case is to provide a set of convenience
extension methods to a basic interface. Say, given:
interface Subject
{
void add(SomeInterface obj);
}
// and then
void add(Subject a, Type1 v1)
{
a.add(convertToSomeInterface(v1));
}
void add(Subject a, Type2 v2)
{
a.add(convertToSomeInterface(v2));
}
this way client can just implement Subject interface and still
use it with types Type1 and Type2. C# allows that, why D does not?
UFCS and overloading
Hi,
I am surprised that this doesn't work:
class Foo
{
void bar(string) {}
}
void bar(Foo foo, int i)
{
}
auto foo = new Foo();
foo.bar(123); // === error
causing compilation error:
main.d(24): Error: function main.Foo.bar (string _param_0) is not
callable using argument types (int)
does UFCS now work with method overloading? I know it is not a
syntax error because changing the name of int version of bar to
bar2 and calling foo.bar2(123) works fine.
Re: Allegro 5.1 + LDC + iOS Breath Of Life
On Saturday, 4 April 2015 at 08:14:13 UTC, Dan Olson wrote: Seemed worth mentioning before I snooze. My daughter and I just got a little touch app running on an iPad using D and Allegro 5.1. Really nothing major, but it does work. Just dragging some text around the screen with my finger and displaying time via std.datetime. Using latest allegro5 at sourceforge and these: https://github.com/SiegeLord/DAllegro5 5.1 branch https://github.com/smolt/ldc-iphone-dev I'll put something up on github in a week or so when the recipe is cleaned up. My daughter heads off to college this fall to work towards a video game design degree, so I've enlisted her to build an interesting demo as a summer project (my own summer of code). -- Dan Fantastic news! Will try it this weekend.
Re: [OT]: Congrats Andrei!
On Saturday, 28 March 2015 at 01:51:39 UTC, Rikki Cattermole wrote: Lets all give it up for Andrei and his wife Sanda. Who had their second son today (Dan)! Please congratulate them both. Congratz!
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 21:55:53 UTC, Mathias Lang wrote: I just wish D examples didn't include string lambdas. +100
Re: DConf 2015 Schedule published
On Monday, 23 March 2015 at 16:47:30 UTC, Andrei Alexandrescu wrote: Dconf 2015's programme is on! http://dconf.org/2015/index.html I would like to thank everyone who submitted a proposal. We've had very strong proposals this year and a 50% acceptance rate, which made it very difficult to only choose half. Submitters are encouraged to join the conference; we'll have two panels and ample unstructured time during the evenings to keep discussions going. Last but not least, I encourage everyone in the community to register. The strength of any conference is ultimately decided by its attendees. We're operating at a loss to keep registration costs low, and chose a location that is accessible and affordable. Take the schedule to your employer or academic advisor and ask them if you can attend! Andrei Schedule is looking very interesting! Session will be recorded, right? ;)
Re: Release Candidate D 2.067.0-rc1
On Tuesday, 24 March 2015 at 00:26:13 UTC, Daniel Murphy wrote: Szymon Gatner wrote in message news:oofoormyfxkefokvk...@forum.dlang.org... i really try not to be whiny about it but it is sooo frustrating. d advertises itself as easy to integrate with c/c++ and maybe in theory it is but in practice it is not true at all. simplest example from Adam's book I followed crashed miserable so I can only assume that -nobody- is mixing c++ with d on Win. DDMD is mixing D and C++ on all the autotester platforms. It's not that simple, but it should be possible. Honestly, I am not willing to try even less mature compiler (last month it was finished?) to try the feature that does not work in the reference one. Don't get me wrong, we do want to be early adopters, but there is nothing to adopt yet.
Re: Release Candidate D 2.067.0-rc1
On Tuesday, 24 March 2015 at 11:59:19 UTC, Szymon Gatner wrote: On Tuesday, 24 March 2015 at 11:52:51 UTC, Steven Schveighoffer wrote: On 3/24/15 7:48 AM, Szymon Gatner wrote: On Tuesday, 24 March 2015 at 00:26:13 UTC, Daniel Murphy wrote: Szymon Gatner wrote in message news:oofoormyfxkefokvk...@forum.dlang.org... i really try not to be whiny about it but it is sooo frustrating. d advertises itself as easy to integrate with c/c++ and maybe in theory it is but in practice it is not true at all. simplest example from Adam's book I followed crashed miserable so I can only assume that -nobody- is mixing c++ with d on Win. DDMD is mixing D and C++ on all the autotester platforms. It's not that simple, but it should be possible. Honestly, I am not willing to try even less mature compiler (last month it was finished?) to try the feature that does not work in the reference one. Don't get me wrong, we do want to be early adopters, but there is nothing to adopt yet. I think you misunderstand. Daniel is citing DDMD project as an example of C++ and D working together. The output from DDMD should be identical to DMD, so it's not anything new on that side. -Steve Ah, OK. Well, I will try mixing again after 2.067 is released and report back. From the changelog I don't understand what improvements have been made to D to increase C++ interop but that is not so important to us now. Btw, who is responsible for D output for SWIG? I tried with 2.067 and bug persists. Filled a bug report [1] [1] https://issues.dlang.org/show_bug.cgi?id=14327
Re: Release D 2.067.0
On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. This release comes with many improvements. The GC is a lot faster for most use-cases, we have improved C++ interoperability and fixed plenty of bugs. See the changelog for more details. http://dlang.org/changelog.html Download pages and documentation will be updated within the next few hours. http://downloads.dlang.org/releases/2.x/2.067.0/ http://ftp.digitalmars.com/ Until the binaries are mirrored to the official site, you can get them here. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin Congratz! What exactly changed wrt C++ interop (changelog is not really helpful)? Also, as I reported some time ago (as 2.067 changelog is the default from D main page for some time), link (in the Version D 2.067 Mar 1, 2015) is broken
Re: Release Candidate D 2.067.0-rc1
On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call.
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 14:19:34 UTC, Ben Boeckel wrote: On Mon, Mar 23, 2015 at 13:49:53 +, Szymon Gatner via Digitalmars-d-announce wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. At least you get that far; Android doesn't even get there (though those patches to even let people get toolchains up and running are only around a year old). --Ben i really try not to be whiny about it but it is sooo frustrating. d advertises itself as easy to integrate with c/c++ and maybe in theory it is but in practice it is not true at all. simplest example from Adam's book I followed crashed miserable so I can only assume that -nobody- is mixing c++ with d on Win. I need it working on win so we can even start to think about using D for our projects but indeed iOS and Android is very next
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 15:36:42 UTC, Martin Nowak wrote: On 03/23/2015 02:49 PM, Szymon Gatner wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. As a matter of fact we only have few Windows developers, so unless someone with interest in this platform steps up it will hardly improve. Daniel Murphy did a lot of D/C++ integration to get ddmd to work, and apparently, that also works on Windows, so you might ask him for details. https://auto-tester.puremagic.com/?projectid=10 sure I could bug individuals to make things work for me, then discover another problem rinse and repeat. thing is i dont want things to somehow work (possibly only until next release that will breake it) I want to know that this is something that is cared about and can be considered mature (and i am looking for the weakest definition of mature possible)
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:01:51 UTC, John Colvin wrote: On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report? i am typing from my phone so hard to find but i did post it on forums some time ago
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: On Monday, 23 March 2015 at 16:01:51 UTC, John Colvin wrote: On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report? i am typing from my phone so hard to find but i did post it on forums some time ago here: http://forum.dlang.org/thread/hsglkscatlniiuacp...@forum.dlang.org#post-mailman.397.1409844359.5783.digitalmars-d-learn:40puremagic.com
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:11:12 UTC, Kapps wrote: On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: i am typing from my phone so hard to find but i did post it on forums some time ago Posting about something on the forums won't get it fixed, make a bug report if you're encountering a bug. i posted it on forums because i wasnt sure if it was indeed a bug or just me. also it is hard to provide minimal app when mixing code and under msvc as potentially full project is needed. i do get your point tho
Re: Release Candidate D 2.067.0-rc1
On Wednesday, 18 March 2015 at 00:47:20 UTC, Martin Nowak wrote: On 03/18/2015 01:13 AM, Manu via Digitalmars-d-announce wrote: Yes. Has for a while. We're really hanging out for the 32bit COFF libs to ship with DMD. Well, someone should add a build target to https://github.com/D-Programming-Language/phobos/blob/master/win32.mak. How is the phobos.lib called to avoid conflicts? It's a bit late to come up with this, will see if I can find enough time for this. phobos32.lib I suppose? Would be great if it was there. That + struct d-tors would make this release great for those that wait to be able to create C++/D apps for Win32.
Re: Release Candidate D 2.067.0-rc1
On Tuesday, 17 March 2015 at 15:49:48 UTC, Baz wrote: On Monday, 16 March 2015 at 21:38:22 UTC, Martin Nowak wrote: Release Candidate for 2.067.0 http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ You can get the binaries here until they are mirrored. https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/ We fixed the few remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin Thx, i notices some broken links in the local html doc yesterday... https://issues.dlang.org/show_bug.cgi?id=14297 ...surpinsingly they have not been fixed since. Is there a problem ? This kins of problem can be very annoying to new comers. Will 2.067 contain libphobos for linking with 32 bit windows apps (COFF 32)?
Re: Release Candidate D 2.067.0-rc1
On Tuesday, 17 March 2015 at 21:56:57 UTC, Martin Nowak wrote: On Tuesday, 17 March 2015 at 18:07:32 UTC, Szymon Gatner wrote: Will 2.067 contain libphobos for linking with 32 bit windows apps (COFF 32)? No work in that direction of which I know. Can DMD generate COFF for 32-bit now? Yes, AFAIU http://forum.dlang.org/thread/lspuat$um6$1...@digitalmars.com
Re: dfmt options
On Sunday, 15 March 2015 at 10:12:09 UTC, Dicebot wrote: On Sunday, 15 March 2015 at 10:03:15 UTC, Walter Bright wrote: Haven't we all got better things to do than argue about formatting styles? If I was a manager paying programmers , I do not want to pay them to argue about formatting, either. But this is exactly the point! There is a team with already established coding style. Suddenly switching those because of upstream will create inevitable tension and decrease in efficiency until people adapt to new style and form new habits. And this will be investment with exactly 0 resulting benefit. Most likely pragmatical decision would be stick to existing style and ignore dfmt existence. Or fork that tool and add our style if that is small effort. It is also matter of expectation. Until now D was very un-opinionated language, probably even closer to language construction set. If this changes for one case, one may fear more similar decisions may follow. I am very much with Walter on this. 1. There are not many big teams with huge D projects out there yet. 2. Team doesn't have to format their code with dfmt if they don't like its style then they don't have to adapt to anything 3. In my experience there are many programmers that don't care about any style and actually following a team style is tedious for them, they would rather use automatic formatting tool (with a hotkey) to do their job for them and call it a day 4. Consistency is MUCH more important than personal opinions, not just within a team but in whole language ecosystem, as it makes much easier to follow 3rd party libraries for the team members too. and to add oil to the fire ;) Some style opinions are objectively more right then others (for visual reasoning) [1] [1] https://vimeo.com/101084305
Re: Link in the changelog broken
On Thursday, 12 March 2015 at 08:40:50 UTC, Szymon Gatner wrote: Hey, when clicking Change Log on the dlang.org it already says Version D 2.067 Mar 1, 2015 even tho big number on the left menu says 2.066.1. Regardless if this is desired (even if confusing) the link embedded at this header is broken. Still there. Top link to the latest version of D compiler, from the main page Change Log is broken.
Link in the changelog broken
Hey, when clicking Change Log on the dlang.org it already says Version D 2.067 Mar 1, 2015 even tho big number on the left menu says 2.066.1. Regardless if this is desired (even if confusing) the link embedded at this header is broken.
Re: H1 2015 - db access support in Phobos
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote: I would like to propose Java way for implementation of DB access (JDBC - Java DataBase Connectors). Please no. If anything, *any* new library for D should be based on C++ version and then make it nicer with D features. Basing things on Java is major step back even in C++. Next thing we know we will need tons of XML to configure database connections and ORM. This should have happened from the start with logging library too (should have been based on boost.log) and in this case one should look into SOCI (http://soci.sourceforge.net/) and not Java versions.
Re: This Week in D: Issue #4
On Monday, 2 February 2015 at 04:57:10 UTC, Adam D. Ruppe wrote: I can't believe it, but yet another week has already passed, so up late to release this again! http://arsdnet.net/this-week-in-d/feb-01.html Early bird registration open for DConf, 2015 Vision released, GUI and Windows development on the forums. Today's tip is about class destructors, and Project Spotlight makes a return to introduce simpledisplay.d, in the first in what will become a series that walks us through making a bit of a little game in D. (Expect this to not be each week, it takes me a long time to write the project spotlight and I've been very busy lately and expect to continue being busy in the coming weeks. I'll probably try to do it every other week rather than every week.) http://www.reddit.com/r/programming/comments/2uhgzr/this_week_in_d_2015_vision_released_tip_on/ https://twitter.com/adamdruppe/status/562112301248290816 Very nice, once again. Looking forward to next part of simpledisplay tutorial. Goal should be to make it run on iOS in 2015 ;)
Re: 404 on dlang.org
On Thursday, 22 January 2015 at 08:44:31 UTC, Szymon Gatner wrote: Hey, soemthing is wrong with the main page giving 404: https://dl.dropboxusercontent.com/s/vvxlb5mq4oafcp2/dlang_404.jpg?dl=0 still...
404 on dlang.org
Hey, soemthing is wrong with the main page giving 404: https://dl.dropboxusercontent.com/s/vvxlb5mq4oafcp2/dlang_404.jpg?dl=0
dlib help
Hi, I am hoping to use dlib for image manipulation utility program but I can't find any documentation for it. Am I missing something? Any examples at least? (also: dlib from dub does not compile with wcslen import conflict., I managed to find a fix on github but bup packages need updating)
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html In the future, I intend to have it written by Saturday for a weekend release, so if you want something to appear this week, please try to get it to by before then. Fantastic inititive Adam, thanks for donating your time for this. An issue I have tho: // classes are reference types, so they must be // initialized. MyClass c;, unlike in C++, would // leave c as null, causing a segfault when you try // to use it. That is not really true, is it? In C++ MyClass c; is actually THE way to instantiate objects. I know you meant MyClass* but as it is now it is just plain incorrect.
Re: What is the D plan's to become a used language?
On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei Alexandrescu wrote: On 1/14/15 7:19 PM, brian wrote: My point was that there are fewer examples of *how* to do things in D. This will discourage the new user, which will prevent it becoming a more popular language. Yes, it would be great if we could crowdsource a cornucopia of how to topics in D. -- Andrei Adam's D Cookbook kindof does that
Re: This Week in D, issue 1
On Thursday, 15 January 2015 at 10:00:44 UTC, aldanor wrote: On Thursday, 15 January 2015 at 09:46:52 UTC, Szymon Gatner wrote: On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html In the future, I intend to have it written by Saturday for a weekend release, so if you want something to appear this week, please try to get it to by before then. Fantastic inititive Adam, thanks for donating your time for this. An issue I have tho: // classes are reference types, so they must be // initialized. MyClass c;, unlike in C++, would // leave c as null, causing a segfault when you try // to use it. That is not really true, is it? In C++ MyClass c; is actually THE way to instantiate objects. I know you meant MyClass* but as it is now it is just plain incorrect. Eh.. what exactly is incorrect? In C++ MyClass c; stack-allocates the class assuming the default constructor is there (unless of course this is a member declaration in an object that's static or heap-allocated). In D it doesn't, it leaves you with an unitialized reference type. You are right, I missunderstood, I thought he meant that this construct would leave c null in C++. My bad, please disregard.
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 00:33:52 UTC, Andrei Alexandrescu wrote: On 1/11/15 4:33 PM, MattCoder wrote: On Sunday, 11 January 2015 at 23:27:34 UTC, Nick B wrote: Perhaps its better to have a number (average or mean) than no number. Just ask 50 or 100 uers (or more) for their number of downloads for the last 12 or 18 months. This is turn will give you a guess-estimate as to the size of the community. If the number is small, say 4, then this will indicate that the community is near 100,000 users. Interesting for example, in my case I downloaded twice on the last 12 months (2.062 and 2.066). Answers from others would be helpful. Thanks! -- Andrei 3-4 times per release (have 3 windows machines and on mac)
Re: D idioms list
On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? They are really cool, thanks :) Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll);
Re: D idioms list
On Thursday, 8 January 2015 at 11:31:14 UTC, ketmar via Digitalmars-d-announce wrote: On Thu, 08 Jan 2015 11:24:34 + Szymon Gatner via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? They are really cool, thanks :) Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll); it is documented: http://dlang.org/expression.html#ImportExpression it's a nice D habit of overloading keywords. Ah, thanks. Follow up then: can such imported string be used for mixin?
Re: D idioms list
On Thursday, 8 January 2015 at 11:43:30 UTC, ponce wrote: On Thursday, 8 January 2015 at 11:41:43 UTC, Szymon Gatner wrote: Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll); it is documented: http://dlang.org/expression.html#ImportExpression it's a nice D habit of overloading keywords. Ah, thanks. Follow up then: can such imported string be used for mixin? Yes. That is pretty damn cool then.
Re: D Meetup in Berlin
On Friday, 5 December 2014 at 11:35:29 UTC, Ben wrote: Awesome to see so much interest in the meetup! Looking at when people can make it lets set the date for the first meetup as Friday 23rd of January. I will announce the venue and time closer to the date. Already looking forward to it. I'm from Poland and interested also :)
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 18:42:11 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner wrote: On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that was not the full code. I've opened a bug. It has a fully contained sample (that does not, in fact, implement smartptr). https://issues.dlang.org/show_bug.cgi?id=13661 Strictly speaking, your opAssign is wrong, because it doesn't swap source and destination, as it should. This doesn't matter here, but it would for a smartptr. However, that opAssign isn't even called is certainly a bug. Why would opAssign() swap things? This is necessary to make assignment exception safe (in the general case). It's known as the copy-and-swap idiom in C++. Here it's described in the D spec: http://dlang.org/struct#assign-overload For your example code it's not necessary, because there can never be exceptions, but depending on what the smart pointer does, it might throw in one of its members' opAssign, which could lead to a partially copied object. Copy-and-swap in C++ as the name implies requires 1) copy first - a temporary copy-constructed object on created on the stack then 2) trivial/nothrow swap with that temporary. Your suggestion sounded like source and destination of opAssign() were suppose to be swapped. In C++ this is sometimes used when move-assigning.
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 07:31:34 UTC, Shachar Shemesh wrote: For reasons I won't go into (but should be fairly obvious), I am trying to write code that does not rely on the garbage collector. As such, I'm using reference counting structs allocated on a pool. To keep things sane, I'm trying to use RAII semantics, and to that end, a smart pointer that calls incref and decref when appropriate. The SmartPtr struct implements this(T*), this(SmartPtr), this(this), ~this(), opAssign(SmartPtr), opAssign(ref SmartPtr) and opAssign(T*). To the best of my understanding this should be enough to catch all relevant cases. All works fine except one case: Foo foo; SmartPtr!Foo[4] array; array[0] = foo; assert(foo.refcount == 1); array = array.init; assert(foo.refcount == 0, This assert fails); I am compiling this on dmd v2.065 Switching the init line to array[] = SmartPtr!Foo.init makes the second assert pass. To the best of my understanding, array = array.init should always be equivalent to array[] = typeof(array[0]).init for static arrays. Am I missing something? Is this a compiler bug? Thanks, Shachar You have created dynamic array of SmartPtrs. In that case they now live on GS's heap and destructor calls are no longer deterministic (and in fact are not guaranteed at all). That is the very first things that gets C++ programmers coming to D (happened to me too). RAII does not work in D. At least not how C++ would expect it to.
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 09:21:14 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 27 Oct 2014 09:11:33 + Szymon Gatner via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: You have created dynamic array of SmartPtrs. nope. it's stack-allocated array. Right, sorry. Tho I admit I made assumptions since that was not the full code.
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that was not the full code. I've opened a bug. It has a fully contained sample (that does not, in fact, implement smartptr). https://issues.dlang.org/show_bug.cgi?id=13661 Strictly speaking, your opAssign is wrong, because it doesn't swap source and destination, as it should. This doesn't matter here, but it would for a smartptr. However, that opAssign isn't even called is certainly a bug. Why would opAssign() swap things?
Re: OT: Minecraft death by GC
On Friday, 24 October 2014 at 07:42:16 UTC, Kagamin wrote: On Tuesday, 21 October 2014 at 09:07:04 UTC, ROOAR wrote: That company with $2.5 billion can't find competent Java engineers lolz! Or they don't fix problems, which didn't appear. That. Minecraft was never expected to be that big.
Re: Change Tab Sizes in Forum Posts
On Friday, 24 October 2014 at 07:29:24 UTC, tcak wrote: if the CSS is to be updated for let's say 4 spaces for a tab, You surely meant 2 spaces ;)
Re: OT: Minecraft death by GC
On Tuesday, 21 October 2014 at 07:18:28 UTC, ROOAR wrote: So the latest Minecraft apparently runs really really poorly because of the GC. And it is running on Java desktop. The supposedly fast GC of Java can't handle the game anymore-- https://www.reddit.com/r/programming/comments/2jsrif/optifine_dev_minecraft_18_has_so_many_performance/ Take that GC fanatics D needs more action you know. Crazy idea: reach pleayerbase of Minecraft. Hit the same problem with D. Sell it to Microsoft for 2.5B$. Use the money to support D's @nogc ;]
Re: What's the difference between https://github.com/D-Programming-Deimos/glfw and https://github.com/DerelictOrg/DerelictGLFW3
On Tuesday, 21 October 2014 at 06:42:17 UTC, Edn wrote: On Tuesday, 21 October 2014 at 06:41:12 UTC, Edn wrote: On Sunday, 19 October 2014 at 23:57:33 UTC, Mike Parker wrote: On 10/20/2014 4:11 AM, Edn wrote: Hello, what's the difference between https://github.com/D-Programming-Deimos/glfw and https://github.com/DerelictOrg/DerelictGLFW3 thanks in advance The bindings at Deimos have a link-time dependency on GLFW. Whether you want to link with the static library or link with the shared library, you need to with something when compiling your app. All of the bindings in Deimos are like this -- they are /static/ bindings. The Derelict binding has no link-time dependency. You can build your app without having the development version of GLFW on your system. When the app is run, it searches the system path for the GLFW shared library and loads it into memory (you have to call DerelictGLFW3.load() for this to happen). All of the bindings in DerelictOrg are like this -- they are /dynamic/ bindings. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com I'm trying to compile a simple program using D and GLFW. I heard that in order to use Deimos GLFW you will have to compile https://github.com/glfw/glfw using the digitalmars c++ compiler since dmd only supports OMF? I mean for the libraries Is this your beginings with GLFW/OpengGL in D? If yes that I strongly sugest going with dub and Derelict. It all just works without any hustle.
Re: OT: Minecraft death by GC
On Tuesday, 21 October 2014 at 09:37:32 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 21 October 2014 at 09:14:00 UTC, Szymon Gatner wrote: Crazy idea: reach pleayerbase of Minecraft. Hit the same problem with D. Sell it to Microsoft for 2.5B$. Use the money to support D's @nogc ;] Great plan! Make a DIP! or: 1. mobile chat for Africa, sell to Google for $4B. 2. world of geekcraft, sell to Microsoft for $8B. 3. Cobol to D converter, sell to banks for $16B. 3. facebook for stock investors, IPO for $32B. Not quite sure if you mean actual deals (tho 2 mins of googling confirm my suspicion that you are joking ;) but I certainly wasn't: http://www.theguardian.com/technology/2014/sep/15/microsoft-buys-minecraft-creator-mojang-for-25bn With FB I suspect you mean WatsApp for 22B?
Re: OT: Minecraft death by GC
On Tuesday, 21 October 2014 at 10:15:45 UTC, Rikki Cattermole wrote: On 21/10/2014 10:37 p.m., Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 21 October 2014 at 09:14:00 UTC, Szymon Gatner wrote: Crazy idea: reach pleayerbase of Minecraft. Hit the same problem with D. Sell it to Microsoft for 2.5B$. Use the money to support D's @nogc ;] Great plan! Make a DIP! or: 1. mobile chat for Africa, sell to Google for $4B. 2. world of geekcraft, sell to Microsoft for $8B. 3. Cobol to D converter, sell to banks for $16B. I'll just put this right here. https://github.com/rikkimax/Dobol You are not suggesting you sold it for $16B tho, right? ;)
Re: Global const variables
On Tuesday, 21 October 2014 at 08:48:09 UTC, safety0ff wrote:
On Tuesday, 21 October 2014 at 08:25:07 UTC, bearophile wrote:
Minas Mina:
Aren't pure functions supposed to return the same result
every time? If yes, it is correct to not accept it.
But how can main() not be pure? Or, how can't the 'a' array be
immutable?
Bye,
bearophile
There can exist a mutable reference to a's underlying memory:
const int[] a;
int[] b;
static this()
{
b = [1];
a = b;
}
Ant this code works? What is the point of const then if you can
assign it to mutable slice?
Re: So what exactly is coming with extended C++ support?
On Wednesday, 15 October 2014 at 06:50:55 UTC, Dan Olson wrote: Szymon Gatner noem...@gmail.com writes: That is good to hear indeed. In your estimate: how much longer until D is usable on iOS? Depends on your definition of usable Szymon. This would allow a D library to be embedded in an otherwise Objective-C (or maybe Swift?) iOS app. That is my definition :) I would use static D library in C++ iOS application. How about bindings for APIs in the iPhone SDK? I think folks can build those as needed with help from Jacob's dstep tool. It would be nice to have a repository for these bindings somewhere though. Would be nice but much less important for me. It would be cool if by Feb/Mar 2015 a demo app could be submited to the App Store, just to test acceptance. I would gladly do that Then there are all the tool related things that might hinder D use on iOS. Things such as no source level debugging, lack of D/Xcode integration. Right Oh, and compiling to arm64 for newer devices. Knowing Apple that will be mandatory for new apps soon. Thanks for all your work!
Re: So what exactly is coming with extended C++ support?
On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky wrote: On 09/30/2014 04:48 AM, Szymon Gatner wrote: On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: Is that all it would take? Do you also need a GC-free standard library, which seems to be the need of all the others saying do this and I'll switch from C++? Are the tools good enough? Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. The whole Unity3D == Mono thing is a somewhat inaccurate misconception. Unity3D's engine (ie, the real workhorse of any Unity3D game) is written in plain old native C++. So not *necessarily* GC (though they might still use one internally, I wouldn't know). Only the game-specific scripts (and I *think* the Unity3D Editor) actually run on Mono. And even then, the game scripts *are* able to call into C-linkage stuff, which *is* occasionally done to work around performance issues within game scripts. Also, I imagine Mono's GC is probably quite a bit better than D's currently is. All good points. Still, my point was that GC does not mean language is automatically excluded from gamedev.
Re: So what exactly is coming with extended C++ support?
On Tuesday, 14 October 2014 at 16:09:31 UTC, Dan Olson wrote: Chris wend...@tcd.ie writes: iOS/ARM are very important. What's the latest state of affairs? I know some progress has been made but it has been off my radar for a month or two now. The iOS project with LDC has been idle during the windsurfing season :-). Days are geting shorter so I plan to resume work on it. For a start, it needs to be updated to latest LDC version. About 10 phobos unit tests were not passing back in April and most of these were due to floating pointing differences between host (x64) and target (arm). That is good to hear indeed. In your estimate: how much longer until D is usable on iOS?
Re: So what exactly is coming with extended C++ support?
On Tuesday, 14 October 2014 at 23:01:49 UTC, Andrei Alexandrescu wrote: On 10/14/14, 3:53 PM, Meta wrote: On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote: Currently, D supports C++: * function calling * name mangling * namespaces * templates * member functions * single inheritance * basic types that exist in C++ but not D (like 'long') Note that there are no plans to support C++ semantics - the D side will support only D semantic rules. SFINAE, Koenig lookup, etc., have no place in D. C++ interop will require the user to be flexible on both the C++ and D side, and bluntly will require strong knowledge of D and C++ and how they work under the hood to be successful with it. Probably the most tricky thing we're working on is interop with C++ exceptions. Essentially, we're going to see how far we can push interop. To clarify, templates have to be instantiated on the C++ side before being passed to D, right? Is it correct that D can't instantiate a C++ template? Correct. Here's the syntax on the C++ side: http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei Understood, makes sense.
Re: So what exactly is coming with extended C++ support?
On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote: On 9/29/2014 3:00 AM, Szymon Gatner wrote: Hi, recently there is much talk about extending C++ interop in D but it is unclear to me what that means. Functions and virtual class methods are already callable. What else is planned in the near future? Exceptions? Support for C++ templates? (that seems difficult no?). Currently, D supports C++: * function calling * name mangling * namespaces * templates * member functions * single inheritance * basic types that exist in C++ but not D (like 'long') I do understand current situation tho I admit I am not aware of the single inheritance. Does it mean that one can derive in D from a C++ class (don't see it in the docs)? Essentially, we're going to see how far we can push interop. I suppose that is the answer I was looking for, time will tell yes? :)
Re: Despiker 0.1: a GUI real-time profiler for game development
On Sunday, 12 October 2014 at 01:36:15 UTC, Brad Anderson wrote: On Friday, 10 October 2014 at 23:55:03 UTC, Kiith-Sa wrote: -- Announcing Despiker, a GUI real time profiler for game development -- Very cool. Tharsis looks very interesting too. Also, it appears you have a great blog about this and other stuff I'm surprised I've never seen before. Very cool indeed! Will take closer look at it for sure.
Re: Despiker 0.1: a GUI real-time profiler for game development
On Monday, 13 October 2014 at 10:32:54 UTC, Szymon Gatner wrote: On Sunday, 12 October 2014 at 01:36:15 UTC, Brad Anderson wrote: On Friday, 10 October 2014 at 23:55:03 UTC, Kiith-Sa wrote: -- Announcing Despiker, a GUI real time profiler for game development -- Very cool. Tharsis looks very interesting too. Also, it appears you have a great blog about this and other stuff I'm surprised I've never seen before. Very cool indeed! Will take closer look at it for sure. This happens after just adding tharsis-prof: ~0.4.0 to the dependancies and running 'dub' in project directory: C:\Users\bravo\AppData\Roaming\dub\packages\tharsis-prof-0.4.1\source\tharsis\pr of\despikersender.d(309): Error: cannot implicitly convert expression (this.byte sSentPerProfiler_[threadIdx]) of type ulong to uint FAIL C:\Users\bravo\AppData\Roaming\dub\packages\tharsis-prof-0.4.1\.dub\build\l ibrary-debug-windows-x86-dmd_2066-5F4CDB1FE63BE3C80C818C14E6D175D5\ tharsis-prof staticLibrary Error executing command run: dmd failed with exit code 1.
Re: UFCS in C++
On Monday, 13 October 2014 at 09:32:58 UTC, Francesco Cattoglio wrote: On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... Seriously, not even a mention? Ok, I'm mad. Can I be mad? To be fair, it is not a new concept in C++...
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 13:35:55 UTC, Rainer Schuetze wrote: Yes, DMD git HEAD is required. Getting this when trying to build all with Digger: std\uri.d(872): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\uri.d(1166): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\concurrency.d(1352): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1354): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1348): Error: function std.concurrency.FiberScheduler.FiberCondition.wait no return exp; or assert(0); at end of function std\concurrency.d(1395): Error: function expected before (), not this.m_fibers[this.m_pos].state() of type State std\concurrency.d(1971): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(2019): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1822): Error: function std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system).get no return exp; or assert(0); at end of function std\concurrency.d(811): Error: template instance std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) error instantiating std\net\curl.d(1185):instantiated from here: receiveTimeout!(bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 13:35:55 UTC, Rainer Schuetze wrote: Yes, DMD git HEAD is required. Getting this when trying to build all with Digger: std\uri.d(872): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\uri.d(1166): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\concurrency.d(1352): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1354): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1348): Error: function std.concurrency.FiberScheduler.FiberCondition.wait no return exp; or assert(0); at end of function std\concurrency.d(1395): Error: function expected before (), not this.m_fibers[this.m_pos].state() of type State std\concurrency.d(1971): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(2019): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1822): Error: function std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system).get no return exp; or assert(0); at end of function std\concurrency.d(811): Error: template instance std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) error instantiating std\net\curl.d(1185):instantiated from here: receiveTimeout!(bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does
Re: Interview with Andrei Alexandrescu on the D Programming Language
On Saturday, 11 October 2014 at 11:31:12 UTC, Sergei Nosov wrote: On Saturday, 11 October 2014 at 09:21:21 UTC, Walter Bright wrote: https://www.youtube.com/watch?v=tvdoIJaPooI On reddit: https://www.reddit.com/r/programming/comments/2iws85/interview_with_andrei_alexandrescu_on_the_d/ Andrei mentions in this talk, that C++ support is implemented to the extent, when you can pass std::vector from C++ to D and in the opposite direction without friction. Are the any pointers on how I can try it out? Like, is it in git master? Where can I find a documentation or an article about that? I got interested in the very same part.
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 09:21:18 UTC, Rainer Schuetze
wrote:
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all
neccessary repos
from GitHub. As my understanding is that I should not be doing
Build
with Diggger I just opened Windows console, entered druntime
dir and typed:
You have to build dmd, so it should be good starting point to
succeed in building the full chain for win64: dmd, druntime and
win64.
You mean for Win32? Beacause that is what I am after.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when
expecting '{'
Ahh, I thought it would use a compiled dmd by default. You will
have to specify the path to dmd too:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\ DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the
normal path is ../dmd/src/dmd). You'll have to update sc.ini
there, too.
So to build HEAD druntime and Phobos I also need HEAD DMD,
correct? Installation of 2.066 I have now is not sufficent?
Re: struct and default constructor
On Friday, 10 October 2014 at 09:58:54 UTC, Walter Bright wrote: On 11/27/2011 11:53 AM, deadalnix wrote: I wonder why struct can't have a default constructor. TDPL state that it is required to allow every types to have a constant .init . Having a .init instead of a default constructor has all kinds of useful properties: 1. the default object is trivially constructable and cannot fail 2. an easy way for other constructors to not have overlooked field initializers, so they get garbage initialized like in C++ 3. generic code can rely on the existence of trivial construction that cannot fail 4. dummy objects can be created, useful for does this compile semantics 5. an object can be destroyed by overwriting it with .init (overwriting with 0 is not the same thing) 6. when you see: T t; in code, you know it is trivially constructed and will succeed 7. objects can be created using TypeInfo Default constructors are baked into C++. I can't escape the impression that the desire for D default constructors comes from more or less trying to write C++ style code in D. Bit OT: What is The D code style then? It would be very useful for those coming from C++ to have a wiki/article on how to translate C++ idioms and practices to D. I too am writing D code like I do my C++ and often find myself puzzled (deterministic d-tors being perfect example). Missing default struct c-tor is also one of such examples - and adding opCall() feels hacky.
COFF on Win32 how to try?
I would like to try recently merged COFF support on Win32 for a hybrid D/C++ application. Until now I tried that (hybridizing) only with DMD from the official installer and in x64 mode. My question is: how to try the same in 32 bits?
Re: COFF on Win32 how to try?
On Friday, 10 October 2014 at 16:14:56 UTC, Rainer Schuetze wrote:
On 10.10.2014 10:37, Szymon Gatner wrote:
I would like to try recently merged COFF support on Win32 for
a hybrid
D/C++ application.
Until now I tried that (hybridizing) only with DMD from the
official
installer and in x64 mode.
My question is: how to try the same in 32 bits?
You need a recent version of dmd, druntime and phobos from
github: https://github.com/D-Programming-Language
If you have never built these yourself, Digger might be of
great help: https://github.com/CyberShadow/Digger/releases. It
will also fetch these from github and download tools needed for
building. Digger doesn't know about COFF32 yet, though.
Then build druntime inside its directory:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\ target unittest
and phobos:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\
AR=\%VCINSTALLDIR%\bin\lib.exe\
Add a configuration section [Environment32mscoff] to your
sc.ini and add options matching these:
https://github.com/D-Programming-Language/dmd/blob/master/ini/windows/bin/sc.ini#L84
Building is done with option -m32mscoff instead of -m32/-m64.
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all neccessary
repos from GitHub. As my understanding is that I should not be
doing Build with Diggger I just opened Windows console, entered
druntime dir and typed:
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when expecting
'{'
src\core\stdc\stdio.d(861): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(862): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(863): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(864): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(865): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(866): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(867): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(871): Error: asm statements must end in ';'
src\core\stdc\stdio.d(874): Error: found 'private' instead of
statement
src\core\stdc\stdio.d(884): Error: no identifier for declarator
add
src\core\stdc\stdio.d(887): Error: no identifier for declarator
usDone
src\core\stdc\stdio.d(887): Error: Declaration expected, not ':'
src\core\stdc\stdio.d(894): Error: Declaration expected, not '('
src\core\stdc\stdio.d(896): Error: Declaration expected, not
'foreach'
src\core\stdc\stdio.d(896): Error: Declaration expected, not '0'
src\core\stdc\stdio.d(901): Error: no identifier for declarator
__fhnd_info[fd]
src\core\stdc\stdio.d(901): Error: Declaration expected, not '='
src\core\stdc\stdio.d(902): Error: Declaration expected, not
'return'
src\core\stdc\stdio.d(904): Error: unrecognized declaration
--- errorlevel 1
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote: It's good to hear that. Maybe you could write a short article about that once you've moved to D. Porting games to D or something like that. With D you can develop fast due to short compilation times, that's important for testing and prototyping. I actually was planning on something like that. I am still thinking about writing on automatic binding generation between D and Lua using D's compile-time reflection. Add a UDA to a function, class, method a voila! You can call it from Lua. Magic!
Re: So what exactly is coming with extended C++ support?
On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: Is that all it would take? Do you also need a GC-free standard library, which seems to be the need of all the others saying do this and I'll switch from C++? Are the tools good enough? Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. - Especially- that native executable is being built in case of D. I realize AAA's have have their reasons against GC i but in that case one should probably just get UE4 license anyway. Tooling is acceptable for me tbh. Coming from C++ I don't have high expectations anyway. The only good debugger (for C++) is VC++ and so far I'v had surprisingly good experience with VisualD and mixed C++/D application. Stepping into function (between language boundries!) just works. Viewing variable values works properly too whether I in on *.cpp or .d file atm. Overall, can't complain too much especially I am getting all those goodies for free ;) Anyway, I accept that I would be an early adopter and I am OK with some cons that come with it as I see more gains overall. Btw, I think D is THE language to implement gameplay. Compilation times make it on par with scripting languages and since it becomes compiled there are no JIT restrictions on iOS for example. In our case AI will get rewritten from C++/Lua to D as soon as it is practical which s not just yet unfortunately. I don't think anyone is saying C++ interop is unimportant. There are a lot of us already using the language and we don't think C++ interop is the only thing that has value. More important IMO would be releasing a compiler without a bunch of regressions. D is a lot more than a C++ replacement for Facebook or video game developers. Don't get me wrong, I too want all those issue resolved, just saying for myself that (lack) of those features blocks us from adopting at all. And after we're on board I suspect I will join some other unhappy camp :P But for now we can't even get there.
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 10:39:53 UTC, John Colvin wrote: On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner wrote: On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote: It's good to hear that. Maybe you could write a short article about that once you've moved to D. Porting games to D or something like that. With D you can develop fast due to short compilation times, that's important for testing and prototyping. I actually was planning on something like that. I am still thinking about writing on automatic binding generation between D and Lua using D's compile-time reflection. Add a UDA to a function, class, method a voila! You can call it from Lua. Magic! I presume you're familiar with http://code.dlang.org/packages/luad I am, but it is incredible how much of the binding-code can be generated with just few lines of D. Please, does anybody know anything about my original question? :P
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 09:53:41 UTC, Johnathan wrote: On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote: I realize AAA's have have their reasons against GC i but in that case one should probably just get UE4 license anyway. UE4 uses a GC internally. The issue with using D's GC for games is a matter of quality/adaptability. True, but not in the sense that it is using GC-based language. It is custom C++ solution tailored for the purpose. Allocations in games should be rare (and after game startup, should mostly be small objects, if there's any allocations at all), so a GC for games would need minimal pauses and extremely quick small allocations. All true again, pre-allocation can fix lots of pause issues. And simply not using GC in tight loops. While not the greatest fan of Unity, it proved that GC (on top of of VM) is not a concern for (I argue) most of gamedev. Minecraft was originally written in Java for crying out loud yet it didn't stop it from becoming gigantic success.
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 11:46:30 UTC, Chris wrote: Great. I'm interested in Lua-D interaction. Would you share it on GitHub once it's done? Have you had a look at DerelictLua: https://github.com/DerelictOrg/DerelictLua I was thinking about maybe just posting snippets on the blog but GitHub should be doable. I am not much of a blogger tho... Anyway, I would be nothing new to D programmer but I think it would be quite interesting for C++ programmer dealing with variadic marcos and boost.mpl for (the half of) similar result.
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 11:46:30 UTC, Chris wrote: Have you had a look at DerelictLua: https://github.com/DerelictOrg/DerelictLua Forgot to reply to 2nd part: yes I looked at it and in fact I tried my code using it.
Re: So what exactly is coming with extended C++ support?
On Monday, 29 September 2014 at 14:36:10 UTC, Jacob Carlborg wrote: On 29/09/14 12:00, Szymon Gatner wrote: Hi, recently there is much talk about extending C++ interop in D but it is unclear to me what that means. Functions and virtual class methods are already callable. What else is planned in the near future? Exceptions? Support for C++ templates? (that seems difficult no?). Using templates are already supported. Note, they need to instantiated on the C++ side. Ah, cool, but I still have no clue what to expect from ongoing discussion on C++ interop. Does anyone know? [1] https://github.com/D-Programming-Language/dmd/pull/3987 Yup, I saw it and this makes me very happy. iOS run-time is still an issue tho.
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote: It doesn't mention anything about moving C++ into C#. Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower. What are these fundamental design trade offs? Guys I beg you, is there any chance I will get my answers? ;)
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 14:34:49 UTC, Ola Fosheim Grøstad wrote: Guys I beg you, is there any chance I will get my answers? ;) Nope :) I suspected so :P I don't think anyone know what extended C++ actually will look like. Great. Some people say D is going to have std::* support, but that would require someone to keep track of changes in all the c++ compilers D is supposed to support: Clang, G++, and VC++… My thoughts too. Seems like maintenance hell. Some people say they want full support for C++ exceptions, some say it is too difficult… However, you don't need std::* or C++ exceptions for a game? Some aspects of extended C++ support is going to be either wishful thinking or non-portable, so you probably should try to avoid depending on it. What are you missing? I use both std/boost and exceptions when makes sense - game is not just rendering and number crunching after all. Tbh what I -am missing- is proper run-time support for what is already suppose to work (building x64 C++/D app crashes when calling writeln() from D side). Win32 support is coming but I expect similar problems (is nobody really mixing C++ and D using VC++ atm?). It would be great to be able to call non-virtual members of C++ classes from D but I don't really need anything else from the language SPECS to start things going - my question is out of pure curiosity. That being said my biggest fear is that D2 will never be finished... I am lurking on those forums for 2 years now, waiting for the signal to start the transition but I need to be sure that in few months everything I need and the code I write will work as expected (and on iOS too). I am not seeing this unfortunately, language is still being actively discussed on the most basic level (allocators, ARC, auto-decoding of utf strings...). It looks like Phobos might need to be rewritten entirely and soon. I will not give up tho, if I must skip D for one more project (which lasts year or two) then be it, hopefully I will be able to use if for the nest one :(
So what exactly is coming with extended C++ support?
Hi, recently there is much talk about extending C++ interop in D but it is unclear to me what that means. Functions and virtual class methods are already callable. What else is planned in the near future? Exceptions? Support for C++ templates? (that seems difficult no?). Is VS support planned (I think I saw Andrei only asking about GCC support for exceptions/stack unwining)? Atm it does not really work (even building x64 exe with D lib linked). From the PoV of small game developer relying its livelihood on C++ I must say that this is great thing. If I had better support for 2 things now: C++ interop so we could just start writing new code in D and ARM/iOS then we would just move immediately. In short, I am very happy (but only if you remember about VC users!) to hear about this direction. Some people here seem to think that this is not relevant effort but clearly they don't have existing C++ code to maintain and deal with.
Re: Announcing libasync, a cross-platform D event loop
On Wednesday, 24 September 2014 at 13:13:34 UTC, Etienne wrote:
It's finally here: https://github.com/etcimon/libasync
We all know how event loops are the foundation of more popular
libraries Qt and Nodejs.. we now have a natively compiling
async library entirely written in D.
This event library was tested on Win32, Linux x64, Mac OS x64,
with DMD 2.066, offers the more low-level async objects:
timers, file i/o, dns resolver, tcp, udp, listeners, signals
(cross-thread), notifications (same thread), and more recently
(and with great efforts for implementing with OS X / BSD) a
directory watcher.
e.g. You can run a timer with:
import std.datetime; import std.stdio; import libasync.all;
EventLoop evl = new EventLoop;
auto timer = new AsyncTimer(evl);
timer.duration(2.seconds).periodic().run({ writeln(Another 2
seconds have passed); });
while(evl.loop()) continue;
The tests may be most revealing:
https://github.com/etcimon/libasync/blob/master/source/libasync/test.d
A (lightly tested) vibe.d driver using all those async objects
is also available and currently ongoing a pull request:
https://github.com/etcimon/vibe.d/tree/native-events
The incentive was to make vibe.d compile in completely native
D, I'm now moving onto a botan C++ = D wrapper for it, I plan
on moving objects to D over the years until the TLS library can
be completely native. I thank Walter for the efforts on
extern(C++)
Finally, I release this on the basis of an MIT license, looking
forward to seeing our community flourishing with yet more
native libraries. Code on
Do I understand correctly that it is similar library to
boost.asio (EventLoop being equivalent of asio::io_service)?
Re: Interop with C++ library - what toolchain do you use?
On Wednesday, 17 September 2014 at 22:28:44 UTC, Cliff wrote: So I am trying to use a C++ library with D. My toolchain is currently Visual Studio 2013 with Visual D, using the DMD compiler. When trying to link, I obviously ran into the OMF vs. COFF issue, which makes using the C++ library a bit of a trial to say the least (I played around with some lib format converters but perhaps unsurprisingly this led to somewhat unpredictable behavior.) I'd like to fix up my toolchain to avoid having this issue. For those of you who are on Windows and who do D and C++ interop, what toolchain have you had success with? Additionally, I have heard tell that D now allows calling C++ non-virtual class methods but I have not found documentation on how to make this work (how do I define the C++ class layout in D - I know how to do it for vtable entries but not non-virtual methods.) Pointers to docs or samples would be much appreciated. Thanks! I am using Visual Studio 2012 (in x64 bit mode that is). Binary D distribution also comes with phobos64.lib that C++ executable has to link. With VisualD plugin you can just add D static library project to the solution and the link C++ exe to it. It is very easy to make back-and-forth function calls between C++/D. I recommend Adam Ruppe's excellent D Cookbook Integration chapter on the details on how to expose this for cross-lang usage. It does not all work correctly tho. I reported my issues on learn subforum but didn't get much help. In short: it seems not everything in D run-time (Phobos) gets properly initialized even after successful rt_init() call. In my case simple call to writeln() causes a crash because stdout is not properly initialized on D'd side. Happy hybridizing!
Re: Flexible and efficient recursive hashing
On Tuesday, 16 September 2014 at 14:53:52 UTC, bearophile wrote: Among the CppCon 2014 slide packs there is this nice one: Types Don't Know #, by Howard Hinnant: https://github.com/CppCon/CppCon2014/tree/master/Presentations/Types%20Don%27t%20Know%20%23%20-%20Howard%20Hinnant%20-%20CppCon%202014 It shows a nice idea to perform transitive hashing in a flexible and efficient way. Perhaps the idea can be used in D too. It suggests the introduction of a hashAppend standard method. Bye, bearophile Funny thing is that as soon as you have to combine hashes in C++ atm you realize that current way is broken and the way HH proposes is kindof obvious correct design.
Re: Example of the perils of binding rvalues to const ref
On Wednesday, 17 September 2014 at 08:52:58 UTC, Arjan wrote:
On Tuesday, 16 September 2014 at 15:30:49 UTC, Andrei
Alexandrescu wrote:
http://www.slideshare.net/yandex/rust-c
C++ code:
std::string get_url() {
return http://yandex.ru;;
}
string_view get_scheme_from_url(string_view url) {
unsigned colon = url.find(':');
return url.substr(0, colon);
}
int main() {
auto scheme = get_scheme_from_url(get_url());
std::cout scheme \n;
return 0;
}
string_view has an implicit constructor from const string
(see basic_string_view(const basic_stringcharT, traits,
Allocator str) noexcept; in
https://isocpp.org/files/papers/N3762.html). The function
get_url() returns an rvalue, which in turn gets bound to a
Forgive me my ignorance but get_url() returns a std::string
(on the stack), so its address can be token.
And iirc the explainer Scott Meyers explained once iff you can
take its address its not a rvalue its a lvalue. So isn't the
get_scheme_from_url() not simply holding a const ref to
temporary? (which most compiler warn about)
...Or am I missing the point?
reference to const and implicitly passed to string_view's
constructor. The obtained view refers to a dead string.
Andrei
Re: Example of the perils of binding rvalues to const ref
On Wednesday, 17 September 2014 at 08:57:36 UTC, Szymon Gatner
wrote:
On Wednesday, 17 September 2014 at 08:52:58 UTC, Arjan wrote:
On Tuesday, 16 September 2014 at 15:30:49 UTC, Andrei
Alexandrescu wrote:
http://www.slideshare.net/yandex/rust-c
C++ code:
std::string get_url() {
return http://yandex.ru;;
}
string_view get_scheme_from_url(string_view url) {
unsigned colon = url.find(':');
return url.substr(0, colon);
}
int main() {
auto scheme = get_scheme_from_url(get_url());
std::cout scheme \n;
return 0;
}
string_view has an implicit constructor from const string
(see basic_string_view(const basic_stringcharT, traits,
Allocator str) noexcept; in
https://isocpp.org/files/papers/N3762.html). The function
get_url() returns an rvalue, which in turn gets bound to a
Forgive me my ignorance but get_url() returns a std::string
(on the stack), so its address can be token.
And iirc the explainer Scott Meyers explained once iff you
can take its address its not a rvalue its a lvalue. So isn't
the get_scheme_from_url() not simply holding a const ref to
temporary? (which most compiler warn about)
...Or am I missing the point?
reference to const and implicitly passed to string_view's
constructor. The obtained view refers to a dead string.
Andrei
[ Sorry for double posting, i must have double clicked on reply
button accidentally. ]
std::string returned from get_url() is a temporary and hence a
rvalue. In fact it's address cannot be taken. It is often
helpful to think of lvalues as things that can appear on the left
side of assignment expression.
Re: writeln() assertion failed in hybrid x64
On Thursday, 4 September 2014 at 20:57:41 UTC, Kagamin wrote: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L270 well, this sucks. Is there a way I can call module c-tors explicitly? I was under impression that D(dmd) was suppose to work with VisualC++ in x64bit mode.
Re: writeln() assertion failed in hybrid x64
On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 04 Sep 2014 15:10:21 + Jorge A. S. via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here). it's definitely a bug. writeln() should throw, not segfaulting. Shouldn't writeln() work tho instead of throwing or segfaulting?
