Re: JMH
I can only suspect, but I think they use maven to collect all functions that use @Benchmark. And this leads to the problem the unittest library proposal for phobos had. No that is the job of the Java compiler. Actually, annotations in Java can be both read at runtime or compile time. As far as I know, you cannot hook into the compiler to check for annotations, so most Java frameworks scan for annotations at startup time. Not that it matters much, anyways.
D Cross Platform Status + OpenGL Status ?
Hi, What is the status of cross compiling D to multiple platforms? I know it is possible, but how easy is it? How many issues do you have to mess with on different platforms? What about ARM / Android support? And what about OpenGL support? Is that easy? And does it work easily across platforms?
Re: What are you planning for 2016?
The communication is the easy part. The time consuming part is converting R objects to D objects and vice versa. I've had to learn the internals of R at the same time that I've learned D. I've been working on it in my spare time for more than two years. Would it have been possible to make a D API for data analysis instead? Or is that too big a job?
Re: What are you planning for 2016?
I've just finished with the initial version of my project to embed R inside D. Hopefully now I can convince other economists to use it. I might put together a simple web interface (using D of course) that will improve my research collaboration efforts. The earliest I will have time to work on it will be the summer. How does this work? Do you write R programs which are executed by a D program? Or do you call functions in D which corresponds to R functions?
Re: What are you planning for 2016?
We plan to port a network protocol + binary data format API (IAP Tools) to D from Java.
Re: Proposal: Database Engine for D
You could just target your database at data analysis. Then you don't need to care about ACID, transactions etc. Just load all the data into memory, and start analyzing it. Also, you'd typically be scanning over large parts of the data set for each query, so you may not need to support a full query language. Just what is needed for data analysis. Later you can modify your engine to support ACID, more expressive query language etc. On one of the projects I am working on right now, we will also implement our own database engine. We need it to integrate tightly with the rest our architecture, and the only way to do that is to roll our own. We will also not be using SQL because SQL is so limiting. So, I'd say "go ahead" - you can only learn something from the project. I've "reinvented a lot of wheels" over the years, and each time I came out smarter than before. Not every reinvention was a success, but I always learned something from the process.
Re: Article on D for CVu or Overload
On Monday, 28 December 2015 at 11:40:50 UTC, Russel Winder wrote: Is anyone up for writing an article or two on D for publication in the CVu or Overload journals as an act of D-efiance? There are to be a 1- day D workshop and a keynote session t the conference, it would be good to "leverage" this as part of the campaign to show that C++ is a 20th century language and D a 21st century one. I am happy to co-author if that helps. ASCIIDoctor the only source form usable though. What would the topics be? How long? What are the deadlines?
Re: D Consortium as Book / App Publisher... ?
On Thursday, 24 December 2015 at 17:19:30 UTC, karabuta wrote: On Sunday, 20 December 2015 at 21:09:31 UTC, Jakob Jenkov wrote: Writing a focused book of around 100 pages can be done in 3-6 months. If more people chip in, it might even be faster. There are these books floating around where various programmers actually come together to write them. Each author take charge of a section. They go like: Problem: How to rename all files in a directory. Solution: .. They take advantage of common tasks and make them into a book. These books really sell. D community/Consortium can do similar if is worth it. Wrox Publishing uses this model. Not all their books are really good, but they can be decent. I was thinking the D Language Foundation could do the same. But I guess someone has to take the reigns, make a plan and mobilize people.
D Testable Code
D Testable Code is not detestable code... There is a little holiday "puzzle/joke" for you :-) (I just watched a video from DConf 2013 about unit testing - sorry! )
Re: D Consortium as Book / App Publisher... ?
I really want to put these paid blogging ideas into use one day, but maybe D isn't the place to do it. Or - maybe D is exactly the right use case. D doesn't already have a ton of available material, but still as a decent size community. I'd say the hardest part is to get information about those parts of D which are not documented. I find the D docs for Phobos pretty hard to read. There are very few explanations to the methods and classes. The "read the code" dogma is not very helpful to beginners in a new language or API.
Re: D Consortium as Book / App Publisher... ?
It is all beyond idiotic: it is amazing how long antiquated ideas stick around, only because people cannot imagine anything else. I agree 100%. I published 4 books for Amazon Kindle, then stopped for exactly this reason. You can do so much more advanced stuff on the web than in an ebook. I run http://tutorials.jenkov.com which has a good bit above 1 million page views a month. I do a few videos too. I just publish as I write. I earn a bit of money from the ads, but it's not that much money. The % of people browsing with ad blockers is rising. How would a paid blog work? Subscription? Texts hidden behind a pay wall? Hard to get it into the search engines then...
Re: D Consortium as Book / App Publisher... ?
Simple, a blog that you pay to read. :) It's amazing to me that people still continue to pump out books, such an outdated form, simply because it has an existing payment model in place, rather than trying new paid models online. Simply churning out ebooks or the equivalent is all they do, when so much more is possible online, everything from pay-per-post to comments. The lack of imagination is simply stunning. I agree. A website / blog allows links to videos etc. and it can be expanded over time, and indexed by search engines. Have you considered using LeanPub for this?
Re: D Consortium as Book / App Publisher... ?
All decent ideas- I've been thinking recently about setting up a paid blog for articles by D devs- but without someone to explore and push them, they will go nowhere, ie somebody has to do the work of wrangling the writers and docs. What do you mean by a "paid blog" ?
D Consortium as Book / App Publisher... ?
I was thinking that the D Consortium could function as publisher of D books too, for the following (obvious) reasons: 1) To raise money for the D Consortium (from sales) 2) To increase the available documentation about D 3) Increased amount of documentation might lead to increased adoption. Those in the D community who have experience writing books could chip in with a chapter each. The books could then be put together as EPUB and the D Consortium could self publish them online (e.g. for Amazon Kindle). I have self published a few books on Amazon about programming. It's not that hard to do, once you get the first one done. The books could be smaller with a more narrow scope, to get them done faster. For instance, one book about D collections, one book about D IO etc. The price range could be around $5 - $9.99 . I think that is a fair price - especially if developers know that the profits goes back into the D Consortium. Each sold book on Amazon for $9.99 should be able to give a profit of $7 to the D Consortium. Another option to raise money and increase the documentation for D would be to make an Android / iOS app which collects all the D documentation in one app. The app could work like an e-book. It is possible to charge a subscription fee for apps. Thus, supporters could pay e.g. $1 / month - or $6 a year for the app. The money would go to the D Consortium. In return subscribers would support D, and have all their D documentation gathered in one place. An app would also be able to link to videos, or articles around the web about D. Yes, I know it's a lot of work etc. but it's not impossible. Writing a focused book of around 100 pages can be done in 3-6 months. If more people chip in, it might even be faster.
Re: Redesign of dlang.org
It looks good. A bit more clear than the current one. Not a fan of the drop downs though. Just personal taste. All in all, though, is that design really so much different from the current one? Yes, the frontpage / color scheme looks nicer, but it's not that big of a diff, or? If the D website maintainers are to put an effort into changing its design, would it not be preferable to go "all-in" and jazz it up, e.g. like http://www.scala-lang.org/ ? For instance, I am pretty new to D, and when I entered the D website I was not looking for code samples, but a list of features or core concepts / principles. The code sample on the frontpage did nothing for me. But that's just me. I would rather know what companies use D, and for what - or what big frameworks / tools were available in D etc.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
Thanks for the comments everyone! I learn a lot from this D forum alone. I have been encaged in the Java world for too long. Great to get some input from other languages / eco systems. Not that I'll drop Java immediately, but I can definitely see how D can supplement Java in our systems.
D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
Hi guys, I read from some of the other forum threads that D is being criticized for not being usable for real time / low latency systems because it has a GC. First of all, such system are already being written in Java. Google "Martin Thompson" and LMAX and you will see. Or Aeron (also Java and Martin Thompson). Second, when Java has been used to develop such systems, the GC has been avoided as much as possible - which is even easier to do with D than Java. So, it's a load of BS that D's GC should somehow make it impossible to make real time / low latency software.
Re: Thoughts on a Future Garbage Collector
A little something I've been working on for making into a DIP: http://wiki.dlang.org/User:Alphaglosined/ManagedMemory Would it be to your liking? I don't know - what does it do? I am pretty new to D... !
Re: Thoughts on a Future Garbage Collector
Great to hear! Looking forward to learning more about how this all works!
Thoughts on a Future Garbage Collector
Hi D devs, I read recently that D's garbage collector isn't the fastest, and that you would like a faster one. I have some thoughts on that. I have spent about 16 years with Java, and my experience with the garbage collector typically falls into one of these two categories: Either the speed of the software didn't matter, and thus the garbage collector didn't matter either. Or, the speed of the software mattered, and the garbage collector was never good enough, so you end up designing your software to avoid the garbage collector (using arrays and object pools instead of new'ing objects). Rather than trying to come up with a "perfect" garbage collector for D I would prefer if the memory system could become a first class member of the language / libraries. Make it a component you can access. Make it possible to: - Hint to the memory system where to allocate an object, meaning hinting if it is - shortlived (like within a function), transaction scope (max 60 s life time), - permanent singleton etc. Often you already know at allocation time. Then the object could be allocated directly at the right "generation" heap. - Force the GC to run - ... above, but with a maximum time allowed GC. - Let developers be able to plug in their own garbage collection algorithms. - Allow multiple memory managers into which you can plug different garbage collection strategies, and different heap allocation / deallocation strategies (growing and shrinking the heap of a memory manager). My experience from Java is that one size never really fits all. Open it up instead. Let the community "plug in" and I am sure D will get a wealth of memory management strategies fast. Not just 1 garbage collector, but N garbage collectors.
