Re: Questionnaire
Le 08/02/2017 à 19:27, Ilya Yaroshenko a écrit : I can answer for the product on which I am working (Home Design 3D), others are video games made with Unity which is imposed by the editor. On Home Design 3D the development teams have the choice of technologies to use, but we have to convince our boss. There is an history, any developer on previous teams knows the D language, we are now 2 on 6 that having few basics. 1. Why your company uses D? a. D is the best b. We like D c. I like D and my company allowed me to use D d. My head like D e. Because marketing reasons f. Because my company can be more efficient with D for some tasks then with any other system language We don't use D. 2. Does your company uses C/C++, Java, Scala, Go, Rust? C++11, other languages as Java or objective-C can be used for OS specifics (Android and iOS). 3. If yes, what the reasons to do not use D instead? There is a lot of obstacles to migrate to D or at least using it partially in our product or for tools. Here is the list sorted by difficulties: 1. The team isn't enough familiar with the D language 2. It seems too hard to use it with our actual C++ dependencies (QtQuick, boost geometry, and a lot of other C/C++ libraries) 3. We don't have enough feedback on how it can be used on all our targeted platforms (Android, iOS, Windows x86 and x64, MacOS) 4. Due to some differences with the c++ major refactoring will be necessary after a translation to have the same performances (GC will impact a lot the resources management) 5. The quality of the possible integration with a complete production ecosystem is unknown. IDE : Debugging, refactoring Platforms : Compatibility with Stores (and there tools such as crash reporting,...) 6. D isn't as mature as C++, so there is fewer articles on internet that can help on particular subjects. And no body will give code examples in D, so even for test we would have to port it. This will globally impact the productivity. 2. Have you use one of the following Mir projects in production: a. https://github.com/libmir/mir b. https://github.com/libmir/mir-algorithm c. https://github.com/libmir/mir-cpuid d. https://github.com/libmir/mir-random e. https://github.com/libmir/dcv - D Computer Vision Library f. std.experimental.ndslice Nop 3. If Yes, can Mir community use your company's logo in a section "Used by" or similar. 4. Have you use one of the following Tamedia projects in your production: a. https://github.com/tamediadigital/asdf b. https://github.com/tamediadigital/je c. https://github.com/tamediadigital/lincount 5. What D misses to be commercially successful languages? I think that it start with a bigger adoption, but it can be addressed directly, so it have to easy to take into. IMO documentation IDE friendly-ness,... will help newbie to start. After tools necessary to have stable and effective products are critical, debugger (code and memory), profiler,... On this point to IMO the ergonomic is important (not every developer want to use command line and a lot would prefer UI). I also think that it depends who is the target, because Java developers will be certainly more reticent to come to D if tools don't have good UI than C/C++ developers that works mostly under linux. Personally I develop only under Windows and having a great integration between D tools with UI is one of the most important thing. I want an IDE that is ready for use after installation, with dub integrated, unit tests UI, compilers and debuggers configured and ready for cross compilation. 6. Why many topnotch system projects use C programming language nowadays? IMO the fact that C is one of the first language helps a lot, languages that came after few or any are system languages. I find that C/C++ didn't evolve a lot for many years and it start to come better with C++11, 14 and 17. Maybe D have put some pressure. I don't know a lot of languages but I think that D have the potential to be a much better system language than C++, and it should be else nobody will migrate if the win isn't enough. = All my current D project are finished. Probably I will use other languages for production this year, Java/Go/whatever. Mir libraries are amazing and good quality. If you use them this would be a good motivation for us to improve the docs and provide regular updates. Plus, it can be enchanted during the GSoC 2017. Thanks, Ilya
Re: Android LDC in a Container
Le 15/01/2017 à 18:40, Andre Pany a écrit : Hi, on Dockerhub I published a repository which makes it really easy to develop Android applications using LDC and Joakims work. The repository contains Android 1.1.0 beta from https://github.com/joakim-noah/android/releases and also the NDK from google. By using this command, you will have a shell containing all you need to compile the source files: docker run --rm -it -v c:/D/projects:/projects andre2007/ldc-android sh This command will also mount C:\D\projects from your host OS to the container path /projects. On linux / mac you will have to adapt the mount source path. You need the Google Android SDK on your host system installed to build the APK and test the application. More information on building the demo applications you can find here: https://wiki.dlang.org/Build_LDC_for_Android A Wiki update will follow with detailed information. Kind regards André It's really nice to see the Android support progress like that. I hope to see the integration of this with dub, to be able to use Visual to target Android with ldc. Thank you.
Re: DlangUI
Le 17/12/2015 17:12, Vadim Lopatin a écrit : On Wednesday, 16 December 2015 at 13:32:21 UTC, Suliman wrote: Is it's possible to use some native frontend with dlangui instead of drawing all controls with OpenGL? I really dislike how all OpenGL toolkit looks like. OpenGL is just hardware acceleration for drawing. Resulting picture is the same for both OpenGL and software rendering. DlangUI will never use native controls. It draws all widgets itself. But look and feel can be changed by providing custom theme. You can create theme (set of .xml and .png files) to get DlangUI app looking exactly like native one. Is it's possible to make dlangui fully compatibility with QML to be able easy migrate visual components from Qt solution to dlangui? No. It's not planned at least for now. Having a GUI library fully compatible with QML request property binding support. We have it in DQuick, but as we use lua instead of a javascript VM I am not sure about how it can be possible to be compatible. Translating qml files in lua format will certainly not be enough, because their is some gliches in QML. Sadly we don't work a lot on DQuick, but you can take a look at https://github.com/D-Quick/DQuick
Re: Standardpaths library
Le 05/04/2015 11:08, FreeSlave a écrit : I wrote small library for getting standard paths (like Pictures, Music) Here's dub package http://code.dlang.org/packages/standardpaths And github repo https://github.com/MyLittleRobo/standardpaths You can see open issues on github. Please, participate in discussions if you're interested. The biggest problem now is OS X support https://github.com/MyLittleRobo/standardpaths/issues/4 You can generate documentation with dub build --build=docs. Nice, IMO it can have his place in phobos, cause at least all GUI applications have to retrieve one or more of those paths. This kind of API are important to ease fast prototyping applications or scripts.
Re: [GUI-lib] Maybe a better year for DQuick
Le 15/03/2015 22:18, romain a écrit : On Sunday, 15 March 2015 at 01:15:51 UTC, Xavier Bigand wrote: The DML engine is almost finished. This night we worked on the file reloading. This will allow direct update of GUI when modifying lua files without loosing states. For example if you only modify the color property of a Rectangle item it will be the only thing that will be updated (and binded properties will be update). Once the DML engine polished, we'll progress on the render part and the event system. We hope finding more time to work on it this year. https://github.com/D-Quick/DQuick Hi. great news. I think D must have some unifying projects to break through, with tools easing programming. That's probably not the right place to ask, but how to get involved in the project? The todo list is quite old now. how to take part to the project? Thank you Sadly I don't think we are ready to manage external contributions, because some basics are still missing. But seeing people interest already help us a lot with our motivations. IMO we need to finish correctly the core of the library and making it well organized to have a chance receiving working contributions. Once again thanks to helping us to stay motivated.
Re: [GUI-lib] Maybe a better year for DQuick
Le 16/03/2015 08:56, Suliman a écrit : Perfect news! Hope to see first beta to this summer time! Wow you put us under pressure :-) It's hard to tell when we could reach the beta status, cause last months we just didn't push any code on DQuick. So we can't give any release date. I'll put news here about our progress.
[GUI-lib] Maybe a better year for DQuick
The DML engine is almost finished. This night we worked on the file reloading. This will allow direct update of GUI when modifying lua files without loosing states. For example if you only modify the color property of a Rectangle item it will be the only thing that will be updated (and binded properties will be update). Once the DML engine polished, we'll progress on the render part and the event system. We hope finding more time to work on it this year. https://github.com/D-Quick/DQuick
Few DQuick news
My friend Bruno who works on the property binding engine make some progress. After the possibility to use property binding in D (native side) in addition of Lua (script side), he currently finishing the model list implementation. This feature will allow user to create list of items for list views for example. Bruno plans to create his own parser of Lua to simplify the script syntax just like Qt did with QML that is based on a javascript VM. To do this, he will look at the std.lexer module. For my part it doesn't progress a lot cause I have some memory issues that cause me some pain to run unittests. I really want to fix those memory corruptions before coming back on the direct 3D implementation. I hope to be able to progress faster when I'd figured out how to solve it.
