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: 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: [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: 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: [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: [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: [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?
[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: 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
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: 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: 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
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: 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 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: 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 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: 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" " 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: 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: 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 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: So what exactly is coming with extended C++ support?
On Wednesday, 15 October 2014 at 06:50:55 UTC, Dan Olson wrote: "Szymon Gatner" 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 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: 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 16:09:31 UTC, Dan Olson wrote: "Chris" 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 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: 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: 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.
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 :(
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 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 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 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 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 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 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 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!
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: 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_stringAllocator>& 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: 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_stringAllocator>& 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: 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: D for Android
On Thursday, 8 May 2014 at 16:16:22 UTC, Joakim wrote: Great to hear! Much appreciated.
