Re: GDC talk at GNU Cauldron 2018
On Tuesday, 31 July 2018 at 08:47:21 UTC, Iain Buclaw wrote: Noticed that there is a GDC talk by Iain Buclaw at the GNU Cauldron 2018. Apologies if this is old news. https://gcc.gnu.org/wiki/cauldron2018 It's happening in Manchester UK, and attendance is free (just send an email ahead of time to register your participation). Just in case anyone else is interested in coming along, or is nearby. Walter & Andrei, Getting D into GCC would be a huge deal in my opinion. Perhaps one of you could join Iain in this GCC meeting (the main annual event I think) to push the case? Regards Dibyendu
Re: GDC talk at GNU Cauldron 2018
On Tuesday, 31 July 2018 at 08:47:21 UTC, Iain Buclaw wrote: Noticed that there is a GDC talk by Iain Buclaw at the GNU Cauldron 2018. Apologies if this is old news. https://gcc.gnu.org/wiki/cauldron2018 It's happening in Manchester UK, and attendance is free (just send an email ahead of time to register your participation). Just in case anyone else is interested in coming along, or is nearby. It wasn't clear to me from the schedule what date your talk is - is that to be decided? Regards Dibyendu
GDC talk at GNU Cauldron 2018
Hi, Noticed that there is a GDC talk by Iain Buclaw at the GNU Cauldron 2018. Apologies if this is old news. https://gcc.gnu.org/wiki/cauldron2018 Regards Dibyendu
Re: C's Biggest Mistake on Hacker News
https://sqlite.org/whyc.html Personally I think D team should try to convince some well known project to switch from C to D. Not many projects are written in C these days though ... but SQLite is amongst the few.
Re: Tiny D suitable for embedded JIT
On Wednesday, 30 May 2018 at 00:05:52 UTC, rikki cattermole wrote: https://github.com/dlang/dmd/blob/master/src/dmd/glue.d Hi - not really as I don't know what this does. In any case my understanding is the interface between the front-end and GDC/LDC is at the level of ASTs. The input is the AST, the output to the backend is some form of IR in essence. It just maps one understanding of the code to another form, that's all. Okay - I was trying to understand if there was some sort of IR that is intermediate stage before codegen - but I couldn't see this. Also the code is quite hard to follow without enough documentation of what's going on. Plus lots of global state I think which is fine for a command line tool but not a JIT engine. But really I looked only for a short while so please correct me if I am wrong. I decided to use a cut-down version of Eclipse OMR - the backend is much smaller than LLVM, although not as small as I would like. But I hope to create a more trimmed version in due course. (https://github.com/dibyendumajumdar/nj) Regards
Re: Tiny D suitable for embedded JIT
On Monday, 28 May 2018 at 19:24:58 UTC, MrSmith wrote: You may like the project of a compiler I am doing https://github.com/MrSmith33/tiny_jit TLDR: fully in D. No dependencies. Currently for amd64 + Win64 calling convension. Cool - I will keep an eye on it. Regards
Re: Tiny D suitable for embedded JIT
On Thursday, 24 May 2018 at 22:14:50 UTC, Jonathan Marler wrote: Sad to hear. Was interested to see if this was feasible. I don't have much experience with the backend but if you're still up for the task, take a look at `dmd/glue.d`. I don't know how much of the glue layer this includes but it would be a good start. DMD does have a common "glue layer" shared by DMD, LDC and GDC, so you'd basically need to find the API to build this glue layer and that's what you would use. https://github.com/dlang/dmd/blob/master/src/dmd/glue.d Hi - not really as I don't know what this does. In any case my understanding is the interface between the front-end and GDC/LDC is at the level of ASTs. Regards
Re: Tiny D suitable for embedded JIT
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar wrote: The ultimate goal is to have JIT library that is small, has fast compilation, and generates reasonable code (i.e. some form of global register allocation). The options I am looking at are a) start from scratch, b) hack LLVM, or c) hack DMD. I have been looking at DMD code (mainly the backend stuff) for this ... I think it will be too difficult for me to try to modify it :-( Regards Dibyendu
Re: Tiny D suitable for embedded JIT
On Thursday, 24 May 2018 at 02:39:18 UTC, Joakim wrote: I don't know if this does exactly what you want, but have you seen it? https://forum.dlang.org/thread/bskpxhrqyfkvaqzoo...@forum.dlang.org Hi - thanks I hadn't seen it. It is based on LLVM - I already use LLVM and it isn't a small / or fast compiling JIT engine. Regards
Re: Tiny D suitable for embedded JIT
On Wednesday, 23 May 2018 at 20:08:53 UTC, Jonathan Marler wrote: I've recently been looking into how QEMU works and it uses something called TCG (Tiny Code Generator). QEMU works by taking code from another platform/cpu and translates it to TCG, which then gets "jitted" to the instructions for the host. From what I understand, TCG is fairly small. I think it aims to be simple rather than highly optimized, unlike LLVM which allows more complexity for the sake of performance. TCG: https://git.qemu.org/?p=qemu.git;a=blob_plain;f=tcg/README;hb=HEAD Thank you for pointing me to this - I wasn't aware of it. I already use something similar - a little more complex product that supports floating points too - NanoJIT. However to my knowledge most of these products do register allocation locally within a basic block - and spill registers when jumping across blocks. This basically results in unacceptable performance in any code that has branching or loops. I could enhance NanoJIT but its written in a way that makes changes difficult (i.e. too many low level optimizations in the code). It seems there is a lack of something in between LLVM and these implementations - either you get all powerful optimizations or you get very little ... my intention is to create something that is small but also has at least some form of global (actually per function) register allocator. I thought of hacking DMD as it favours speed of compilation and simplicity - but what I am not sure about is how easy / difficult it would be to modify DMD (mostly remove stuff). Regards Dibyendu
Tiny D suitable for embedded JIT
Now that D has a better C option I was wondering if it is possible to create a small subset of D that can be used as embedded JIT library. I would like to trim the language to a small subset of D/C - only primitive types and pointers - and remove everything else. The idea is to have a high level assembly language that is suitable for use as JIT backend by other projects. I wanted to know if this is a feasible project - using DMD as the starting point. Should I even think about trying to do this? The ultimate goal is to have JIT library that is small, has fast compilation, and generates reasonable code (i.e. some form of global register allocation). The options I am looking at are a) start from scratch, b) hack LLVM, or c) hack DMD. Regards Dibyendu
Re: Maybe D is right about GC after all !
On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright wrote: On 12/22/2017 7:23 AM, Russel Winder wrote: I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it. Maybe it is. But that is not because D isn't up to the task. I've converted a large program from C to D (Digital Mars C++'s front end) with -betterC and it really is a zero cost abstraction. The memory safety benefits are there (DIP 1000), RAII is there, nested functions, array bounds checking, template metaprogramming, CTFE, etc. D as betterC really is a game changer, for anyone who cares to give it a try. I think D's great strength compared to Rust is that it is much easier to code in D. How easy is it write a simple linked list in Rust - without using library features? Rust makes even simple tasks hard to write. D as a language combines best features of C, C++ and Java which is great in my view. And the better C option makes it really viable for creating shared libraries that can be easily used in other projects. Trying to replace C is really not the right goal for D I think. In my experience, C and C++ have already been replaced by Java, C# or Go in application development except where the code is legacy and is just being kept "alive". And nothing beats C for systems developers who want a high level assembler rather than abstractions and safety features. In my view, D should be D - the main issue with D is not the language, but the tooling. It needs to "just work" on the major platforms and needs good IDE support. Regards Dibyendu
Re: Fantastic exchange from DConf
On Sunday, 14 May 2017 at 21:01:40 UTC, Jack Stouffer wrote: On Sunday, 14 May 2017 at 10:10:41 UTC, Dibyendu Majumdar wrote: b) If you want to do things that C allows you to do, then Rust is no more safer than C. That's the entire bloody point isn't it? Maybe you shouldn't be doing a lot of the things that C allows you to do. Hi, I think you are missing the point. I am talking here about things you need to do rather than writing code just for the heck of it.
Re: Fantastic exchange from DConf
On Sunday, 14 May 2017 at 01:30:47 UTC, Jack Stouffer wrote: On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote: (a) Trust the programmer. That's the first and most deadly mistake. Buffer overflows and null pointers alone have caused hundreds of millions of dollars of damages. I think we can say that this trust is misplaced. I should have added that the C11 charter also says: 12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work. In real terms though tools like ASAN and Valgrind if used from the start usually allow you to catch most of the issues. Most likely even better tools for C will come about in time. But I don't see how languages like D or Rust can replace C for certain types of use cases. Maybe you can argue for the use of C in embedded systems and in OS's, although I see no reason why Rust can't eventually overtake C there. I think Rust is a promising language but I don't know enough about it to comment. My impression about Rust is that: a) Rust has a steep learning curve as a language. b) If you want to do things that C allows you to do, then Rust is no more safer than C. Regards
Re: Fantastic exchange from DConf
On Sunday, 14 May 2017 at 02:11:36 UTC, bachmeier wrote: On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote: (a) Trust the programmer. I don't understand this point. C doesn't offer the programmer much to work with. If you trust the programmer, shouldn't that mean you provide a large set of tools and let them decide which parts to use? C is pretty much "here are some pointers, go have fun". Hi - I think this point really is saying that the type system in C is for convenience only - ultimately if you as a programmer want to manipulate memory in a certain way then C assumes you know what you are doing and why. As I said C is really a high level assembler. Regards
Re: Fantastic exchange from DConf
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote: Walter: I believe memory safety will kill C. Hi, I think that comparing languages like D to C is not appropriate. C is a high level assembler and has different design goals. A useful document to refer to is: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1250.pdf In particular: (although note the addition of facet f, which echoes the sentiment that security is important) Keep the spirit of C. The Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. For the Cx1 revision there is consensus to add a new facet f to the original list of facets. The new spirit of C can be summarized in phrases like: (a) Trust the programmer. (b) Don't prevent the programmer from doing what needs to be done. (c) Keep the language small and simple. (d) Provide only one way to do an operation. (e) Make it fast, even if it is not guaranteed to be portable. (f) Make support for safety and security demonstrable. Proverb e needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine. I think Linus Torvalds makes an important observation - he says in one of his talks is that the reason he likes C is that when he write C code he can visualize what the machine code will look like. My feeling is that the C has traditionally been used in contexts where probably it should not be used - i.e. as a general purpose application development language. But I don't see how languages like D or Rust can replace C for certain types of use cases. Regards Dibyendu
Re: Walter and Andrei and community relationship management
On Thursday, 6 April 2017 at 07:24:28 UTC, Nick B wrote: But, it seems that while Walter and Andrei are prepared to put a proposal out on the newsgroup, and then discuss it with the community, and then LATER, if its any good, state they will formally document it into a DIP. For the community, it seems different rules apply. In-depth news-groups discussions for new proposals are firstly encouraged and then later discouraged, with the ultimate response that the proposal MUST be in the form of a time-consuming DIP, to be considered, even if it will ultimately wastes everyone time, and cause resentment in the community. Hi, I am only familiar with the Lua world from a language design point of view - in that world, only the Lua core team decide what features can go into the language. In fact they don't even accept code contributions - everything is coded by the core team - even when they accept an idea. I don't think a language can be designed by a committee. My impression is that Walter is very decent about replying to criticisms, even though there is no need in my view for him to do so. I would in fact urge the D team to make it explicit that D language design rests solely Walter and Andrei - and while others can make suggestions as to what should go in, only Walter and Andrei decide what actually goes in. Regards Dibyendu
Re: D future ...
On Tuesday, 20 December 2016 at 12:43:38 UTC, Andrei Alexandrescu wrote: On 12/20/16 3:41 AM, Benjiro wrote: [snip] Thanks for the rant. Though it was pretty awesome, I too feel the focus was missing in the sense that I'm unclear on what steps we can take to alleviate your pain points. Do you want more or less in the language and the standard library? Do you want me to get on things like editor integration I have no expertise in? Hi, As a long time D observer and someone who tried to use D earlier this year, I hope following is constructive. D's reason for existence I think the landscape of programming languages has changed somewhat in recent years - we have new languages like Go, Swift, Rust, and even an existing language like C# is becoming cross platform. It seems that D started out as better C++ but C++ is also evolving and taking many of the ideas from D. So I think that D has to have a clear charter similar to say the charter for C (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm). And this needs to clarify how D is different from its competition and which use cases it is best for. Is it better C? Is it better C++? Is it better some other language? Project Management - It is a bit painful to watch how D's development is managed. In my view, the whole of the D team (including volunteers) need to be very narrowly focussed on very small set of defined priorities. Secondly the goal has to be a measurable delivery within strict timescales. It seems that too many avenues are being chased while there are too few people to handle the workload. Why not have a much more restricted scope and focus everyone on that. And when this is achieved move to the next scope. It is also important to keep the scope small and achievable in a short time (3-6 months). Real world needs - As a potential user of D, here are the things I looked at: 1) Can I successfully build my project? 2) Can I expose my D modules as reusable C ABI compatible shared libraries for use in a heterogenous environment? 3) Can I debug my programs easily? 4) Is there an IDE I can use for development? 5) Is the performance going to match C or C++? 6) Will the third party libraries I need to use work with D? Note that in all of above, language features and D libraries did not count! In production usage being able to deliver counts most. D fell short in these areas compared to a combination of C++ and C#. Final thoughts -- I wish I could help, as I really like D as a language. But unfortunately I have to focus on getting my own work done (survival reasons), and I chose to use C++ and C# for my project (after giving up the idea of using D). I could potentially help in project management in my spare time ... but feel that it needs a mind set change in the D team ... and I fear this is unlikely. Apologies for being one of those who offers advice but no action. Regards Dibyendu
Re: Eclipse OMR project provides a reusable Garbage Collector
On Saturday, 3 December 2016 at 02:23:13 UTC, Dibyendu Majumdar wrote: IBM has open sourced the J9 Garbage Collector as part of Eclipse OMR project. Perhaps D could use this. It is claimed that the GC implementation is relatively straight forward to reuse. https://github.com/eclipse/omr BTW the .Net Core CLR also appears to be reusable - and maybe even easier to integrate. There is a standalone sample - and the integration interface seems well defined. https://github.com/dotnet/coreclr/tree/master/src/gc
Re: Eclipse OMR project provides a reusable Garbage Collector
On Saturday, 3 December 2016 at 10:29:02 UTC, Dibyendu Majumdar wrote: That said, let's look at the API: omrobjectptr_t OMR_GC_Allocate(OMR_VMThread * omrVMThread, uintptr_t allocationCategory, uintptr_t size, uintptr_t allocateFlags); omrobjectptr_t OMR_GC_AllocateNoGC(OMR_VMThread * omrVMThread, uintptr_t allocationCategory, uintptr_t size, uintptr_t allocateFlagss); omr_error_t OMR_GC_SystemCollect(OMR_VMThread* omrVMThread, uint32_t gcCode); First parameter is a pointer to an OMR thread. I'd have to rewrite core.thread to use OMR's thread system, or maybe I could fake OMR threads with enough effort. That's another barrier. I think all GCs need to interact with threads so there has to be some linkage between the thread sub-system and GC. I saw a slide deck or some docs that explained the requirements to use OMR GC. Unfortunately I did not save a link and cannot locate this now. I will post a link if I find it again. It said that the OMR expects objects to be allocated on 8-byte aligned memory and it requires one GC byte - which is assumed to be at the start of the allocated object but can be changed if required. Here is the video that describes how to use the GC. Says initial integration should take <100 lines of code! GC details are about 30 minutes into the talk. https://developer.ibm.com/open/videos/eclipse-omr-tech-talk/
Re: Eclipse OMR project provides a reusable Garbage Collector
On Saturday, 3 December 2016 at 06:26:22 UTC, Chris Wright wrote: On Sat, 03 Dec 2016 02:23:13 +, Dibyendu Majumdar wrote: IBM has open sourced the J9 Garbage Collector as part of Eclipse OMR project. Perhaps D could use this. It is claimed that the GC implementation is relatively straight forward to reuse. That's awesome! Unfortunately, it looks like incorporating it would take a fair bit of effort, and upstreaming it will not happen. I'm going to take a deeper look this weekend, but it's not looking good so far. I would imagine that some effort is necessary ... but the payoff is huge isn't it ? To have a robust GC would change the game for D. That said, let's look at the API: omrobjectptr_t OMR_GC_Allocate(OMR_VMThread * omrVMThread, uintptr_t allocationCategory, uintptr_t size, uintptr_t allocateFlags); omrobjectptr_t OMR_GC_AllocateNoGC(OMR_VMThread * omrVMThread, uintptr_t allocationCategory, uintptr_t size, uintptr_t allocateFlagss); omr_error_t OMR_GC_SystemCollect(OMR_VMThread* omrVMThread, uint32_t gcCode); First parameter is a pointer to an OMR thread. I'd have to rewrite core.thread to use OMR's thread system, or maybe I could fake OMR threads with enough effort. That's another barrier. I think all GCs need to interact with threads so there has to be some linkage between the thread sub-system and GC. I saw a slide deck or some docs that explained the requirements to use OMR GC. Unfortunately I did not save a link and cannot locate this now. I will post a link if I find it again. It said that the OMR expects objects to be allocated on 8-byte aligned memory and it requires one GC byte - which is assumed to be at the start of the allocated object but can be changed if required. Regards Dibyendu
Re: Eclipse OMR project provides a reusable Garbage Collector
On Saturday, 3 December 2016 at 02:23:13 UTC, Dibyendu Majumdar wrote: IBM has open sourced the J9 Garbage Collector as part of Eclipse OMR project. Perhaps D could use this. It is claimed that the GC implementation is relatively straight forward to reuse. https://github.com/eclipse/omr The documentation is a bit sparse but here is some additional info: http://www.slideshare.net/craiglehmann/the-omr-gc-talk-ruby-kaigi-2015
Eclipse OMR project provides a reusable Garbage Collector
Hi Not sure if I am repeating information already known here - if so I do apologise! IBM has open sourced the J9 Garbage Collector as part of Eclipse OMR project. Perhaps D could use this. It is claimed that the GC implementation is relatively straight forward to reuse. https://github.com/eclipse/omr Regards Dibyendu
Re: Official compiler
On Friday, 26 February 2016 at 22:20:09 UTC, Walter Bright wrote: I am referring to this thread: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html Thanks for the pointer. If anyone wants to chip in on that thread, feel free! Hi Walter, Should LLVM move to an Apache License would that help in migrating to an LLVM backend as the standard backend? Regards Dibyendu
Re: Official compiler
On Friday, 26 February 2016 at 11:35:04 UTC, Dibyendu Majumdar wrote: On Friday, 26 February 2016 at 06:19:27 UTC, Walter Bright wrote: [...] I recall there was a thread in the LLVM mailing list last year about moving to a different license. So maybe that is on the cards, and the D community could chip on that conversation. I am referring to this thread: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
Re: Official compiler
On Friday, 26 February 2016 at 06:19:27 UTC, Walter Bright wrote: I wish LLVM would switch to the Boost license, in particular removing this clause: "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimers in the documentation and/or other materials provided with the distribution." Reading it adversely means if I write a simple utility and include a few lines from LLVM, I have to include that license in the binary and a means to print it out. If I include a bit of code from several places, each with their own version of that license, there's just a bunch of crap to deal with to be in compliance. Hi Walter, I recall there was a thread in the LLVM mailing list last year about moving to a different license. So maybe that is on the cards, and the D community could chip on that conversation. I feel that by moving an LLVM backend D will gain the help / expertise of a large number of companies that are working on LLVM including Microsoft & Google. Isn't Clang's claim that it is much faster than gcc when it comes to compiling? So maybe the speed of compilation using LLVM is not such an issue as presumably a lot of the cost in C++ compilation is in the front-end and with D the same issues won't arise? In any case with scarce resources it seems wasteful to have people working on multiple backends - it would make more sense to converge to one backend - and LLVM being non-GPL and having a lot of momentum may be the best option. I also feel that a lot of the C++ interfacing could be done by using the Clang libraries - again for similar reasons that you will gain from work already being done. Regards Dibyendu
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I wrote recently that I am looking at an alternative to C++ for a project currently being coded in C++. I am pleased to say based on preliminary investigations I have chosen D over Go, Rust, and Swift. 1. D appears to give me all the power of C++ - and in particular even greater power with templates. 2. D code is cleaner, more traditional (Java and C like), and easier to read and understand than some of the alternatives. Go is simpler of course and also easy to follow - but that is because it is a small language. I dislike the new syntax of Rust as it seems gratuitously different and (in my view) hard to read. 3. D gives me all the low level control while at the same time giving me the ability to write code at a higher level. C++ is similar but the other languages are all restrictive in some way or other. Hi - just to give you an update. After trying to get some simple tests working for the past few days I have concluded that while D is the best choice for my project (after C++) - D's implementation and tooling is not mature enough yet for me to spend effort on a port. So I will defer the move to D to a future time - but my intention is to do other work in D related to my OpenSource projects around Lua. I really want to use D as a better C / C++ so am looking forward to library developments that better support a style of programming that relies less on GC. Its not that I don't like GC - but I feel that the reasons for my using a language like D or C++ is control - else I would use Java or Swift or Go. Regards Dibyendu
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote: A revision of D that wasn't constrained by backwards compatibility would almost certainly either require all attributes to be prefixed by @, or change the grammar such that attribute names could be reused as identifier names without introducing ambiguities. It seems to me that '@' could be allowed as optional prefix to attributes that currently don't have it without breaking code - or am I being naïve?
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:08:07 UTC, Brad Anderson wrote: On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar wrote: I am puzzled as to why there is @nogc on the one hand and simply nothrow on the other? Why are some attributes prefixed with '@' while others aren't? For historical reasons, basically. There have been some calls to make it uniform but nothing has really happened. I see. And which approach is considered better? Personally don't see why the '@' prefix is necessary. Regards
Why do some attributes start with '@' while others done't?
I am puzzled as to why there is @nogc on the one hand and simply nothrow on the other? Why are some attributes prefixed with '@' while others aren't? Regards
Re: DMD - issue building shared library
On Monday, 18 January 2016 at 23:53:45 UTC, Dibyendu Majumdar wrote: Thanks - that worked, but I had to write it this way: import std.c.windows.windows; import core.sys.windows.dll; mixin SimpleDllMain; I noticed that above modules are documented in the library reference so I assume that this template is not supported? Sorry meant to say 'not' documented.
Re: DMD - issue building shared library
On Monday, 18 January 2016 at 05:58:38 UTC, bitwise wrote: On Sunday, 17 January 2016 at 22:12:44 UTC, Dibyendu Majumdar wrote: Presumably there is no compiler flag to auto generate this? There's no compiler flag, but you can use this: https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/dll.d#L473 Bit Thanks - that worked, but I had to write it this way: import std.c.windows.windows; import core.sys.windows.dll; mixin SimpleDllMain; I noticed that above modules are documented in the library reference so I assume that this template is not supported? Regards Dibyendu
Re: DMD - issue building shared library
On Sunday, 17 January 2016 at 19:10:16 UTC, bitwise wrote: On Sunday, 17 January 2016 at 16:10:01 UTC, Dibyendu Majumdar wrote: LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup _DllMainCRTStartup: D shared libs on windows still require a DllMain. If you follow this post here[1] to create one, it should solve some of your problem. [1] http://wiki.dlang.org/Win32_DLLs_in_D Ok thanks - wasn't aware of that. Presumably there is no compiler flag to auto generate this? Regards
DMD - issue building shared library
Hi I have an existing C shared library that I am trying to link to a D shared library. The D shared library at present only has a binding (extern (C)) definition, nothing else. When I try to create the shared library using the DMD command line I get link errors. Platform is Windows 10 64-bit. The command I am using is: dmd -m64 -shared -v -L/LIBPATH:c:\ravi\lib -Lravimatrix.lib source\matrix.d Partial output from DMD follows: binaryC:\D\dmd2\windows\bin\dmd.exe version v2.069.2 configC:\D\dmd2\windows\bin\sc.ini parse matrix importall Dmatrix importobject (C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d) importstd.stdint (C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdint.d) importcore.stdc.stdint (C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\stdint.d) ... importcore.stdc.string (C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\string.d) semantic2 Dmatrix semantic3 Dmatrix code Dmatrix C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\x86_amd64\link.exe /NOLOGO matrix /DLL /LIBPATH:c:\ravi\lib ravimatrix.lib /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\8.1\\lib\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\10.0.10240.0\ucrt\x64" legacy_stdio_definitions.lib matrix.obj : error LNK2001: unresolved external symbol _D3std5stdio12__ModuleInfoZ matrix.obj : error LNK2001: unresolved external symbol _D15TypeInfo_Struct6__vtblZ matrix.obj : error LNK2019: unresolved external symbol _d_assert referenced in function _D7Dmatrix8__assertFiZv matrix.obj : error LNK2019: unresolved external symbol _d_unittest referenced in function _D7Dmatrix15__unittest_failFiZv matrix.obj : error LNK2019: unresolved external symbol _d_arraybounds referenced in function _D7Dmatrix7__arrayZ LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup matrix.dll : fatal error LNK1120: 6 unresolved externals --- errorlevel 1120
Re: dmd installation question
On Sunday, 17 January 2016 at 03:27:29 UTC, Mike Parker wrote: On Saturday, 16 January 2016 at 22:04:58 UTC, Dibyendu Majumdar wrote: It seems that the sc.ini is modified by the installer - and in doing so it loses the group "Users" assignment so that no one other than the administrator can access it. I'm unable to reproduce this with the 2.069.2 installer. I completely removed my previous installation and installed from scratch. All of my projects compile fine. Are you using 2.069.2 or the beta? I used 2.069.2. Are you sure you are attempting to build from a non-administrative user? The issue log previously noted does show others are getting the same error.
Re: Premake officially gains D support
On Friday, 15 January 2016 at 21:13:22 UTC, Dibyendu Majumdar wrote: On Tuesday, 2 June 2015 at 08:23:08 UTC, Manu wrote: Perhaps of interest, I have been maintaining D support in Premake for years (as an extension). It was finally merged into mainline... so Premake now officially supports D out-of-the-box. Huzzah! Hi - Thanks for this; I currently use CMake for C/C++ projects, but due to lack of support for D in CMake, planning to migrate to premake. Unfortunately I find that premake doesn't support DMD correctly on Windows 64-bit - it attempts to use the D linker rather than the MS Linker. Regards
Re: dmd installation question
On Saturday, 16 January 2016 at 11:53:07 UTC, Dibyendu Majumdar wrote: Probably this: https://issues.dlang.org/show_bug.cgi?id=15456 I'm going to try to get around to fixing that and making an installer for LDC this weekend. Reading more carefully it may not be the same bug. It seems that the sc.ini is modified by the installer - and in doing so it loses the group "Users" assignment so that no one other than the administrator can access it.
Re: dmd installation question
On Saturday, 16 January 2016 at 02:10:44 UTC, Brad Anderson wrote: On Saturday, 16 January 2016 at 02:07:13 UTC, Brad Anderson wrote: On Saturday, 16 January 2016 at 01:16:22 UTC, Dibyendu Majumdar wrote: [...] Probably this: https://issues.dlang.org/show_bug.cgi?id=15456 I'm going to try to get around to fixing that and making an installer for LDC this weekend. Reading more carefully it may not be the same bug. I did not run the uninstaller - it was a first time install. So the problem appears to be in the installer. I downloaded the compressed archive and extracted - this doesn't appear to have the problem.
dmd installation question
Hi I have downloaded and installed DMD on a Windows 10 64-bit machine. When I try to build my app in Visual Studio - I am getting an error: Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. config file: C:\D\dmd2\windows\bin\sc.ini Specify path to file 'object.d' with -I switch Upon investigating it appears that the sc.ini file is not readable by the user. If I log in as Administrator then the build works. What am I doing wrong? Regards
Re: dmd installation question
On Saturday, 16 January 2016 at 01:16:22 UTC, Dibyendu Majumdar wrote: I have downloaded and installed DMD on a Windows 10 64-bit machine. When I try to build my app in Visual Studio - I am getting an error: Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. config file: C:\D\dmd2\windows\bin\sc.ini Specify path to file 'object.d' with -I switch I used the Installer by the way.
Re: Premake officially gains D support
On Tuesday, 2 June 2015 at 08:23:08 UTC, Manu wrote: Perhaps of interest, I have been maintaining D support in Premake for years (as an extension). It was finally merged into mainline... so Premake now officially supports D out-of-the-box. Huzzah! Curious to know if anyone here uses Premake, or cares...? Hi - Thanks for this; I currently use CMake for C/C++ projects, but due to lack of support for D in CMake, planning to migrate to premake. Regards Dibyendu
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 20:33:50 UTC, Dibyendu Majumdar wrote: Another example of what I think ought to be easily accessible is Andrei's response to following: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why BTW I hadn't seen above before I wrote my reasons - just read it now ... which is my point.
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 17:10:34 UTC, Jack Stouffer wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. http://dlang.org/overview.html Nice - but it is under Getting Started? So it assumes people already want to get started in D? Why not put the first few sections on the main page. Another example of what I think ought to be easily accessible is Andrei's response to following: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why Anyway, I am glad that there is material out there and that I was able to find what I needed! Regards Dibyendu
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 17:04:35 UTC, Ali Çehreli wrote: On 01/14/2016 05:47 AM, Dibyendu Majumdar wrote: > I had to go through many articles, video presentations etc. to > form my conclusions - it would have been nice if there was a > single page on the D website that explained why D should be > chosen over the other competing languages Can you please write that article while it's fresh on your mind. ;) Ali I will probably write something when I feel more confident about things (i.e. have validated my impressions), but right now that's not a priority for me. Regards
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 14:35:27 UTC, bachmeier wrote: Are you familiar with https://github.com/dlangscience https://gitter.im/DlangScience/public Thank you for pointing me to above. Regards
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 14:40:05 UTC, bachmeier wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. Do you have specific suggestions for improvements? The difficulty is predicting where someone will look for that information. I think a prominent Link saying - Why choose D? on the home page. and maybe initially this could take to another page with links to articles, videos etc. But longer term it would better to have a more structured presentation of the benefits. Example - show with examples what can be done with D templates that is hard or not possible with C++. And similarly with other languages. I would suggest very aggressive 'marketing' of D advantages. Regards
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 14:02:58 UTC, Joakim wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: Hi I wrote recently that I am looking at an alternative to C++ for a project currently being coded in C++. I am pleased to say based on preliminary investigations I have chosen D over Go, Rust, and Swift. I have yet to write a line of D code so I will give you an update after I do some coding but here are my reasons: [...] What is it you're actually trying to write? Hi - apologies I am unable to discuss, as it is not an OpenSource project. But let's say it requires lot of numeric computing.
Choosing D over C++, Go, Rust, Swift
Hi I wrote recently that I am looking at an alternative to C++ for a project currently being coded in C++. I am pleased to say based on preliminary investigations I have chosen D over Go, Rust, and Swift. I have yet to write a line of D code so I will give you an update after I do some coding but here are my reasons: 1. D appears to give me all the power of C++ - and in particular even greater power with templates. 2. D code is cleaner, more traditional (Java and C like), and easier to read and understand than some of the alternatives. Go is simpler of course and also easy to follow - but that is because it is a small language. I dislike the new syntax of Rust as it seems gratuitously different and (in my view) hard to read. 3. D gives me all the low level control while at the same time giving me the ability to write code at a higher level. C++ is similar but the other languages are all restrictive in some way or other. I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. I will provide an update as I start coding in D. Thanks and Regards Dibyendu
Re: Unclear about the benefits of D over C++ and Java
Hi, I am looking to choose between D, Swift and Rust for a project that I am currently coding in C++. So far D seems the alternative but I guess I won't know until I try out a few things. Is this the right forum to ask questions or should questions be sent to another forum? Regards Dibyendu
Re: Unclear about the benefits of D over C++ and Java
On Saturday, 2 January 2016 at 11:31:24 UTC, Dibyendu Majumdar wrote: I am a long time observer of D but have never done any coding in D. I have considered using D several times but have ended up either going with C++ or Java. I feel that for someone like me it is not clear what significant advantages D has over C++ or Java to make a switch. I cannot afford to experiment with a language unless I know for certain the benefits of using it. My post here was triggered after watching a video by Andrei where he talked about how D generics are different from C++ templates - I think stuff like that needs to be explained in the front page of D website. To clarify - the reason for my post here is to raise that the benefits of D over C++ or Java should be explained right up-front on D website in real world terms (i.e. with examples and benchmarks) to help people like me. Regards Dibyendu
Unclear about the benefits of D over C++ and Java
Hi, I am a long time observer of D but have never done any coding in D. I have considered using D several times but have ended up either going with C++ or Java. I feel that for someone like me it is not clear what significant advantages D has over C++ or Java to make a switch. I cannot afford to experiment with a language unless I know for certain the benefits of using it. For instance I would like to know: * Do D compilers generate more efficient code compared to C++ compilers? Are there performance benchmarks comparing D implementation against C and C++? * Can D generics do everything C++ templates can (are they Turing complete for instance) - and what additional capabilities does D have that would make a significant difference to the way templates are used in C++? * How does D's performance compare with Java when it comes to concurrent applications or garbage collection? * How stable is D? Can one use it without fear that the next version will significantly change the language and therefore one would have to rewrite? I feel that the D website could do more to explain why someone should move from C++ or Java to D - and this has to be explained in terms of real world benefits in terms of: * Performance * Quality of implementation For someone like me - cool language features don't count that much unless they lead to real world benefits. My post here was triggered after watching a video by Andrei where he talked about how D generics are different from C++ templates - I think stuff like that needs to be explained in the front page of D website. Regards Dibyendu http://ravilang.org http://simpledbm.org
