Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 16:26:49 UTC, Stanislav Blinov wrote: On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: "It takes care of itself --- When writing a throwaway script... ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance. What this means is that whenever I have disregarded a block of information, say removed an index from an array, then that memory is automatically cleared and freed back up on the next sweep. While the process of collection and actually checking Which is just as easily achieved with just one additional line of code: free the memory. Don't be a computer. Do more with GC. Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. The "power" of GC is in the language support for non-trivial types, such as strings and associative arrays. Plain old arrays don't benefit from it in the slightest. What a bunch of nonsense! I used to talk like this some 20 years ago when all I saw in the computing world was C and C++... Sure garbage collection is not for every project, depends what industry you are in I guess... In my case (business applications/services) I have never had the need to turn off garbage collection! However, someone in the gaming industry, embedded or realtime systems would indeed need to turn off the GC...
Re: Passing $ as a function argument
On Thursday, 11 October 2018 at 06:58:08 UTC, Simen Kjærås wrote:
unittest {
auto x = fun($); // What does it even mean?
}
After some reading through the whole thread I think his "$ idea"
can only be applied to a RandomAccessRange (and similar) where
the size can be known...
Re: Please don't do a DConf 2018, consider alternatives
On Wednesday, 3 October 2018 at 16:21:45 UTC, Joakim wrote: Like most of the responses in this thread, I have no idea why you're stumping for in-person interaction, when all my suggestions were geared around having _more in-person interaction_. If you're still not sure what I mean, read this long post I wrote fisking Adam's similar post: https://forum.dlang.org/post/eoygemytghynpogvl...@forum.dlang.org Perhaps you did not get my point? - I have nothing against core D team having web-conferences as much as they please. It is up to them (and they may already have them?) how they want to communicate. What I argued about was that, just because some antisocial geek argues that conferences are "dead" because we have web-conferencing and similar means of communication does not mean we all share that opinion... Everyone can record a "talk" with slides and put it on some video streaming site like Vimeo or YouTube, but I personally see that as ANOTHER way to reach the community, certainly NOT an alternative to a well-organised conference! Do not get me wrong, I have nothing against the proposal - I think D community can have both good, annual conference, AND what web-conferencing between core D devs, and people who would record talks in their rooms or offices and make them public...
Re: Warn on unused imports?
On Thursday, 27 September 2018 at 18:35:58 UTC, Nick Sabalausky (Abscissa) wrote: On 09/26/2018 04:37 AM, Dejan Lekic wrote: On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: I humbly believe this does not belong to the compiler. These sort of things belong to a static code analyser TOOL. Think of checkstyle/findbugs in Java, or flake8/pep8 in Python world. It amounts to the same thing. What you're talking about ultimately boils down to nothing more than the trivial distinction between: toolx ... toola --do-x ... And if you still prefer the former, that can be trivially created via shell alias or a one-liner script. OTOH, If you're talking about whether action X should be taken by default, than that's an entirely orthogonal matter to whether or not it can be included in the compiler. IDK, I prefer things done in the UNIX way - do one thing and do it right. Compiler should do what its name says - COMPILE, while some other tool should be made for these kind of code checks. The code will compile no matter whether there are some unused imports or not, right?
Re: Please don't do a DConf 2018, consider alternatives
On Tuesday, 2 October 2018 at 06:26:30 UTC, Joakim wrote: I'm sure some thought and planning is now going into the next DConf, so I'd like to make sure people are aware that the conference format that DConf uses is dying off, as explained here: https://marco.org/2018/01/17/end-of-conference-era It is a matter of personal preference, and a view of a modern-day geek, in my humble opinion... I _highly disagree_. People go to conferences for different reasons. You know, even though we "computer people" tend to be branded as antisocial, there are still many of us who prefer to see someone in person, talk to him/her, meet new people, speak to them too, build the network, exchange phone numbers, etc... As usual with conferences not all people are happy - you will ALWAYS have people who prefer more technical stuff, and people who prefer more business side - people who try to promote their products and services. - Conferences are brilliant places for them. Another group of people interested in conferences and meetups are recruiters. My company found few new colleagues this way... Yet another group are people who also want to see the town where the conference is held - it is a form of tourism if you like. Yes, you can have all that interaction with some internet-conferencing software, but not at the level when people interact with each other directly!
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: I humbly believe this does not belong to the compiler. These sort of things belong to a static code analyser TOOL. Think of checkstyle/findbugs in Java, or flake8/pep8 in Python world. I think developing such tool as part of the D Language team group (GitHub) makes more sense than anything else...
Re: Mobile is the new PC and AArch64 is the new x64
On Wednesday, 12 September 2018 at 08:09:46 UTC, Joakim wrote: I contacted one of the few companies putting out RISC-V dev boards, Sifive, a couple weeks ago with the suggestion of making available a paid RISC-V VPS, and one of their field engineers got back to me last week with a note that they're looking into it. I think their model of having an open ISA with proprietary extensions will inevitably win out for hardware, just as a similar model has basically won already for software, but that doesn't mean that RISC-V will be the one to do it. Someone else might execute that model better. I could not agree more - look at Parallella! Their model is the same yet it ultimately failed (unfortunately as I think Exynos is seriously good stuff)! :(
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. ... I mostly agree with you, Joakim. I own a very nice (but now old) ODROID U2 (check the ODROID XU4 or C2!) so ARM support is important for me... Also, check this: https://www.hardkernel.com/main/products/prdt_info.php?g_code=G152875062626 HOWEVER, I think Iain is right - PPC64 and RISC-V are becoming more and more popular nowadays and may become more popular than ARM in the future but that future is unclear.
Re: What changes to D would you like to pay for?
On Wednesday, 5 September 2018 at 07:00:49 UTC, Joakim wrote: The D foundation is planning to add a way for us to pay for changes we'd like to see in D and its ecosystem, rather than having to code everything we need ourselves or find and hire a D dev to do it: I would donate again to DFoundation towards the administration and proper handling of the development process. Let me clarify - I expect D Foundation to oversee the D development process in the same fashion the JCP (Java Community Process) works. - That is an example of how professionals handle these things. The D Foundation should, in my humble opinion, start the design (and perhaps the development) of commonly used APIs that may or may not be part of Phobos (APIs yes, the implementation should be separate library). The following APIs come first to my mind: - Crypto API - Networking API (supporting all major protocols, and giving nice set of interfaces to implement own - look at protocol handlers in Java, or similar) - Graphics (2D and 3D) - GUI API (a rock-solid, scene based like JavaFX) - Database API - TUI (console UI) - Security API (Role-base Access, etc) - VFS API (Look at Apache Commons VFS) Again Phobos should only contain interfaces - refecence implementation should be in the libphobos- (example: libphobos-crypto.so) The design and the development (or coordinating the development) of these APIs should be the D Foundation responsibility. Also future improvements should be part of the the improvement process that is also governed by the D Foundation (look at Python PEPs)... I talked about this on IRC many times with other D programmers. Rich set of APIs is why languages like Java, Python, JavaScript, Go, etc gained so much popularity. The more I see the D Foundation do these things, the more I will be willing to donate.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote: I've been working with Java recently and although it is not an exciting language, it does the job and it does it well. You can rely on it to get the job done - and get it done fast. And you know that your code will still work next week, month or in 5 years. In everyday programming life you don't care about the latest fancy features. Imo, D should slow down, take inventory, do some spring cleaning and work on useful libraries and a sound ecosystem. I don't care what color the bike shed is as long as there are bikes in there that actually work. Atm, I'm not considering D for any important and or big projects. There is exactly where I am - I am using Java (and more recently Python) for serious stuff. I am however in favour of D moving fast (that is why many Java programmers moved to Kotlin/Scala!). The only problem with D is that there should be stable release of D2 (two times a year, like Fedora for an example), and this stable release gets only security updates and bug-fixes! I know this would require someone to maintain all this (it is a full-time job!)...
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 10:55:27 UTC, kinke wrote: Phobos. I understand the separate 'minimal runtime' need for bare metal (no Type- and ModuleInfos etc.), but I can't help myself in seeing betterC as, nicely put, worseD. I acknowledge I *completely* agree. However, I have nothing against betterC as long as people like me, who do enterprise software, are guaranteed to see "-betterD" option (here I actually mean - as long as the "regular" D is improving)...
Re: D on top of Hacker News!
On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: Is D really a top 20 language? I don't remember seeing it anywhere close to the top 20. https://www.tiobe.com/tiobe-index/ has them in 31 Top comment is kind of depressing. The right place to look is https://www.tiobe.com/tiobe-index/d/ I agree with other comments regarding TIOBE - they are constantly changing how they do statistics so they are not relevant source at all. Just look where Kotlin is there and that should pretty much tell you everything. I know at least 10 large companies that are moving from Java/Scala to Kotlin, yet Kotlin is at the bottom 50 table... Ridiculous...
Re: Is D releasing too often?
On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote: There have been 6 major releases of dmd over the last year, with ldc trying to keep pace, currently only one release behind. This is a big jump up from the previous release schedule, I see 2 major releases in 2014, 3 in 2015, and 3 in 2016. There are obviously pros and cons to each pace, and this has been debated internally before, with one of the ldc devs again posting to the Internals mailing list today questioning the current speed. I thought I'd open it up to the community: now that you've experienced this faster pace, as a user of the D compilers, how do you like it? Would you prefer a slower release schedule, say 3-4 major releases a year? I thought 6/year was an ambitious schedule when announced and I wonder if it isn't putting too much strain on our few release maintainers, maybe 3-4 releases/year would be a more gradual bump up. I have nothing against releasing that often as long as there is a LTS version, and that is where the problem lies - we do not have it. So what I do is simply base my production code on particular release, and every few months allocate few days job to try to bring the code up-to-date with latest DMD.
Re: dmd -unittest= (same syntax as -i)
On Wednesday, 14 March 2018 at 22:04:50 UTC, Adam D. Ruppe wrote: On Wednesday, 14 March 2018 at 21:22:01 UTC, Timothee Cour wrote: would a PR for `dmd -unittest= (same syntax as -i)` be welcome? so when this came up on irc earlier (was that you?) this was the first thought that came to my mind. I'd support it, tho I'm no decision maker. I guess it was me talking about it two days ago on IRC... Almost exclusively I need to run unittests only in the module I currently work on and it really makes no sense to run other unittests at that point of time (unless I explicitly want to). I would even go further to say that we basically need to be able to run particular unittest. What I do at the moment is that I developed this kind of practice to have a test_runner.d top-level module in every D project of mine that contains tests I do during the development of particular feature TDD style, and then once I am done, I move this code to appropriate unittest blocks in my final module... There are bunch of issues with existing support for unittests that could be solved to make unit-testing a really pleasant activity.
Re: DConf 2018 Logo
On Wednesday, 15 November 2017 at 14:56:53 UTC, Andrei Alexandrescu wrote: Hello, for all of you with expertise in graphics, we'd be in your debt if you could create a logo for DConf 2018. Proposals would be appreciated! Thanks, Andrei Why a new logo? The last year's one is superb and should be used in all future DConfs, IMHO.
Re: Project Elvis
On Tuesday, 7 November 2017 at 09:42:50 UTC, Satoshi wrote: I strongly agree with you. As I wrote earlier int this thread. Kotlin has the `?.` operator for the same reason. I honestly can't think of a more obvious operator for that purpose...
Re: Project Elvis
On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote: Walter and I decided to kick-off project Elvis for adding the homonym operator to D. Razvan Nitu has already done a good part of the work: https://github.com/dlang/dmd/pull/7242 https://github.com/dlang/dlang.org/pull/1917 https://github.com/dlang/dlang.org/pull/1918 Is it going to be something similar (or the same) as in Kotlin? (Reference: https://kotlinlang.org/docs/reference/null-safety.html#elvis-operator ) I see from comments that different people think of it in a different way. I suggest them to read this section from Kotlin docs to understand the reasoning behind the elvis operator.
Re: Note from a donor
On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei Alexandrescu wrote: A person who donated to the Foundation made a small wish list known. Allow me to relay it: * RSA Digital Signature Validation in Phobos * std.decimal in Phobos * better dll support for Windows. Andrei First two are in my wish list too!
Re: Replacing Make for the DMD build
On Friday, 16 June 2017 at 06:30:01 UTC, Russel Winder wrote: A direct question to Walter and Andrei really. If someone, let us say Russel Winder, create a CMake/Ninja and/or Meson/Ninja build for DMD, is there any chance of it being allowed to replace the Make system? If the answer is no, then Russel will obviously not waste his time doing something that will not be accepted. Why? Why replacing a rock-stable Make with build-system-X that most likely adds another dependency. I am with Walter on this one. - We should continue using Make unless there is a real need for something else. DMD's makefiles are really simple!
Re: sqlite3 vs. sqlite-d
On Thursday, 8 June 2017 at 13:37:41 UTC, Russel Winder wrote: Exactly my point. Using SQLAlchemy made me actually enjoy writing database code. Which I did last year having avoided it Using ORM like SQLAlchemy certainly has benefits but like any other ORM, it generates hideous SQL code, sometimes terribly slow...
Re: Thoughts from newcommer
On Wednesday, 12 April 2017 at 09:38:49 UTC, Russel Winder wrote: On Tue, 2017-04-11 at 20:07 +, Stefan Koch via Digitalmars-d wrote: […] At the risk of starting a flame war: The memory safety is currently in the works. We just have one std-lib now. GC is slow, yes. I don't care, it doesn't impact the programs I write, and the GC means I can be a little profligate with memory. The short-term solution is to avoid it. But only if you have to, if you don't have to don't worry. Oh and measure do not guess. (All gc-ed langauges recommend static preallocation :P) Absolute ### Amen to that!
Re: pImpl in D
On Tuesday, 4 April 2017 at 12:05:15 UTC, Satoshi wrote:
Hi,
do someone have any experience with pImpl and inheritance in D?
Some parts of Phobos use it. Example:
https://github.com/dlang/phobos/blob/master/std/stdio.d
Have a look at the struct ByLine
It has something like:
struct ByLine(Char, Terminator)
{
private:
import std.typecons : RefCounted,
RefCountedAutoInitialize;
/* Ref-counting stops the source range's Impl
* from getting out of sync after the range is copied,
e.g.
* when accessing range.front, then using std.range.take,
* then accessing range.front again. */
alias PImpl = RefCounted!(Impl,
RefCountedAutoInitialize.no);
PImpl impl;
RFC: patch statement
I know people her do not like to see proposals that change (add
stuff to) the language. However, I strongly feel that for the
testing purposes D should provide means to patch any object (no
matter whether it is final or not!). Therefore I wonder what
people think of adding a `patch(obj) {}` or perhaps change the
semantics of the `with(obj) {}` so unittest writers can modify
the object and set values.
The patch keyword would work ONLY inside unittest {} blocks AND
inside functions annotated with @test annotation.
Imagine we have:
int myFun(Person person) { /* some logic here */ }
unittest {
auto p = new Person() /* does not really matter which
constructor we use */
patch(p) {
// here we can modify ANY attribute, no matter whether it is
private or public
p.fname = "Nikola"
p.sname = "Tesla"
}
auto res = myFun(p)
// do some assertions here
}
Similarly:
@test
void test_myFun() {
// same code as in the unittest above.
}
I do not even know if patch() {} statement is even possible, that
is the whole point of writing this, so people can enlighten me...
:)
As I said in the introduction paragraph, for this purpose the
semantics of the with statement could be changed, but I prefer a
different keyword (patch) to be honest.
Re: Databases and the D Standard Library
On Sunday, 1 January 2017 at 03:24:31 UTC, Adam Wilson wrote: Hi Everyone, I've seen a lot of talk on the forums over the past year about the need for database support in the D Standard Library and I completely agree. At the end of the day the purpose of any programming language and its attendant libraries is to allow the developer to solve their problems quickly and efficiently; and a large subset of those solutions require some form of structured data store. To my mind, this makes some form of interface(s) to a data-store an essential component of the D Standard Library. And since this is something that my particular problem spaces also need, I thought it would be useful to attempt to do something about it. The only thing I want, database related, in the standard library is the API! - Nothing else! There should be a standard implementation of that API (libd-db.so for an example), but it should be separated from Phobos. In general, Phobos should only contain the APIs in my humble opinion. We should handle XML processing the same way (API in Phobos, libd-xml.so for the reference implementation), Image processing the same way, GUI, etc... Why? Phobos is enormous already!
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 08:33:55 UTC, Daniel Kozák wrote: ? I am on fedora and I have dmd, so it is not true :P Dejan Lekic via Digitalmars-d napsal St, pro 21, 2016 v 6∶36 : On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway! What I meant is that LDC is the only D compiler in the official Fedora/CentOS repositories.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway!
[RFC] Runtime, interfaces and implementations.
I have mentioned this on IRC quite few times in the past years, as well here on the newsgroups... I really think the D runtime should have a std.api package containing what I call "module interfaces" (something similar to how Modula-3 treats interfaces and modules), and all existing std modules would "implement" these interfaces. As pointed out in one of the threads where we touched this topic, we already have this in gc.gcinterface and gc.impl.manual.gc ! https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d https://github.com/dlang/druntime/blob/master/src/gc/impl/manual/gc.d I would even go to the next level, and extend the D language to support this via something like: module mylib.foo extends api.bar; where api.bar is somewhere in ../api/bar.di file that starts with: module interface api.bar; Naturally, there is tight relation with "module interface" and the .di extension...
Re: Wait-free queue
On Tuesday, 18 October 2016 at 18:03:58 UTC, Andrei Alexandrescu wrote: Interesting work: http://concurrencyfreaks.blogspot.com/2016/10/crturn-queue-first-mpmc-memory.html -- Andrei I could not help but paste something from the paper: "We chose C++14 because it is a native language that is supported by most recent compilers and has a well defined memory model and atomics API, which makes the code portable across different architectures without any modification and without introducing CPU specific memory fences." Conclusion: D needs a serious document (specification) explaining the memory model!
Re: gdc in Linux distros recommended?
On Tuesday, 18 October 2016 at 23:02:28 UTC, Ali Çehreli wrote: I have a friend who has started writing a library in D. Although I recommended that he should use a recent dmd or ldc, he thinks gdc is a better candidate because it's "available to the masses" through Linux distros similar to how gcc is. Although he has a good point, the gdc that came with his distro does not even support @nogc. Thoughts? Can you please tell him to change his mind! :p Ali For an example, Fedora's default repository ONLY has LDC, because GDC is not yet merged into GCC. The reason why Ubuntu does is because they have relaxed policy regarding GCC. I think LDC is in most major distros, GDC is not, so LDC is the clear winner here. I build GDC myself and use it on Fedora, it is pretty straightforward, but I would recommend LDC to beginners. Once GDC is merged into GCC, it is a no-brainer - GCC/GDC all the way!
Re: Go's march to low-latency GC
On Saturday, 9 July 2016 at 23:14:38 UTC, ZombineDev wrote: https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d https://github.com/dlang/druntime/blob/master/src/gc/impl/manual/gc.d What else do you need to start working on a new GC implementation? That is actually the only case that I know of that an interface was provided to be implemented by 3rd parties... My reply was about Phobos in general. To repeat again - Phobos should provide the API (interfaces) *and* reference implementations of those.
Re: Why I am switching to Go
...I could care less why you are switching to Go...
Re: ISO D
On Wednesday, 17 August 2016 at 12:57:59 UTC, TencoDK wrote: I dropped D once about a year ago because the new DMD version has broken backward compatibility. Some libraries have stopped You could have used STABLE DMD (v1), right? Assuming that you *intentionally* used the unstable (v2) DMD, I would say it is unfair to complain...
Re: Go's march to low-latency GC
On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu wrote: I wish we could amass the experts able to make similar things happen for us. I humbly believe it is not just about amassing experts, but also making it easy to do experiments. Phobos/druntime should provide set of APIs for literally everything so people can do their own implementations of ANY standard library module(s). I wish D offered module interfaces the same way Modula-3 did... To work on new GC in D one needs to remove the old one, and replace it with his/her new implementation, while with competition it is more/less implementation of few interfaces, and instructing compiler to use the new GC...
Re: Where is the D deep learning library?
On Monday, 27 June 2016 at 14:10:15 UTC, Guillaume Piolat wrote: With the latest popularity of Machine Learning, and all the achievement we see, where is the D alternative in this area? C++'s offering makes lot of use of meta-programming already: https://www.reddit.com/r/programming/comments/4py875/dlib_190_clean_c11_deep_learning_api/?ref=share&ref_source=link Surely a touch of DbI and D's meta power could help! Thanks for reminding me why I stopped doing C++ programming... When I saw that... using LeNet = loss_multiclass_log< fc<10, relu max_pool<2,2,2,2,relu max_pool<2,2,2,2,reluinputchar>>; ... I got a headache...
Re: Anybody still using the chm docs
What's the main difference between it and just pointing your browser at the downloaded html files? Search and index? Well, seach and index are not the only operations you need. One of the common operation with every CHM viewer is to bookmark something for an example. I've just checked the Zeal application and realised it does not have this simple feature (or I could not find it). Also, I want it to open at the same place I was last time I used the viewer... Simply run KChmViewer and open the CHM document from DMD package with it, and compare it with any other similar solution...
Re: Anybody still using the chm docs
On Thursday, 16 June 2016 at 02:32:05 UTC, Jack Stouffer wrote: On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote: So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? For offline browsing, Windows and Linux users can use Zeal [1] which is FOSS, and macOS users can use Dash[2], which is free as in beer. Both of which can use this D docset [3]. So no, there's no reason to maintain the chm docs. [1] https://zealdocs.org/ [2] https://kapeli.com/dash [3] https://github.com/Kapeli/Dash-User-Contributions/tree/master/docsets/D#readme Thanks for the Zeal, I did not know about it. Both Gnome and KDE have their "help" tools that more/less do the same.
Re: Anybody still using the chm docs
I still use CHM document as it is absolutely the best solution compared to anything else. I think it is a mistake to compare CHM with PDF... They are made for different things... I forgot to mention - I use CHM on Linux. It is not my fault that opensource community could not come up with a better or/and standardised solution... The only standard solution for this that Linux has are man pages - clearly not suitable this purpose! Other, better solutions are there, but are not adopted by all - Gnome has one format, KDE another, etc... CHAOS. Therefore, I decided to use CHM.
Re: Anybody still using the chm docs
On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote: It's a huge maintenance effort for us to produce the chm files. We no longer generate documentation on Windows, but just for the chm generation we have dedicated tools [¹] to create an index (from a json generated via ddoc) and copy the html files. So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? https://github.com/dlang/dlang.org/pull/1374 [¹]: https://github.com/dlang/dlang.org/blob/7cc6e938154f90aa49fa6451a85b13e35ab2de99/chmgen.d I still use CHM document as it is absolutely the best solution compared to anything else. I think it is a mistake to compare CHM with PDF... They are made for different things... If people want to get rid of PDF, then I propose we start providing ePub instead of CHM. That could be the only sane alternative to the CHM we have.
Re: stc.experimental.ndslice -> sci.ndslice
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote: We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years. https://github.com/dlang/phobos/pull/4207 As I have said many times on both IRC and NG, I would prefer to have `stdx` instead of ridiculously long (4x) `std.experimental`. Then you would have a nice package named `stdx.sci`. PS. this is not my "invention" - Java community has `javax` for similar (but different, as nothing in javax is experimental) purpose!
Re: Could we reserve void[T] for builtin set of T ?
On Thursday, 31 March 2016 at 19:24:14 UTC, deadalnix wrote: Pretty much as per title. I has that in the back of my mind for a while. Would that work ? I am not sure about that... I would rather have a completely new type (`set`) for this purpose.
Re: Oh, my GoD! Goroutines on D
On Monday, 28 March 2016 at 10:49:28 UTC, Jacob Carlborg wrote: It would be useful with a wiki page, or similar, that describes and compares different ways of doing concurrency in D, both built-in and third party libraries like this and vibe.d. Also compare against other languages like Go, Erlang, Scala and so on. +1 Wiki is absolutely the best solution to this, I agree. Plus, we already have a wiki so he should just go there and start writing. The community will incorrect grammar/syntax and typos.
Re: Walter, I need a __trait please.
On Wednesday, 16 March 2016 at 04:47:05 UTC, cy wrote: I'd honestly worry more about the compiler hiding implementation, that could have been used to make things easier for programmers. You worry too much.
Re: C++ UFCS update
On Wednesday, 2 March 2016 at 15:57:41 UTC, Piotrek wrote: On Wednesday, 2 March 2016 at 13:29:03 UTC, Dejan Lekic wrote: I am not sure I agree with this. "->" will make it *visible* what is going on, while "." can mean many things, and I would have to investigate what .something in part of a chain does. Right? Are you sure that "->" is obvious in C++? I ask because it can mean many things, not mentioning it can be overloaded! Piotrek Who is talking about C++?? `->` I was talking about is completely different thing from what `->` in C++. It would/should be semantically different from `.` in D and `->` in C++.
Re: Why don't you use the Github issue system?
On Wednesday, 2 March 2016 at 23:59:49 UTC, Seb wrote: Hey, I am just curious whether you have already considered moving from Bugzilla to the Github issue system and where your current opinion is. GitHub issues is okay for one-man projects or small teams that do not want to bother much with bugs, issues, support requests, etc. For anything serious I suggest you forget GitHub issues... A common problem is that you have a project that spans multiple repositories (a library, a service, etc). You want a *single place* to deal with issues, not multiple places (each repository has own issues)! As people already mentioned, Bugzilla is a robust, feature-rich system. Use it (or something similar)!
Re: std.database
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote: I'm back to actively working on a std.database specification & implementation. It's still unstable, minimally tested, and there is plenty of work to do, but I wanted to share an update on my progress. I suggest you call the package stdx.db - it is not (and may not become) a standard package, so `std` is out of question. If it is supposed to be *proposed* as standard package, then `stdx` is good because that is what some people have used in the past (while others used the ugly std.experimental. for the same purpose). I humbly believe that this effort **must** be collaborative as such package is doomed to fail if done wrong.
Re: C++ UFCS update
On Sunday, 21 February 2016 at 10:16:19 UTC, Jonathan M Davis wrote: As for a pipe operator, I expect that it wouldn't really help any. It would be a lot like . vs -> in that it's an unnecessary complication, but it would actually probably be worse. If | I am not sure I agree with this. "->" will make it *visible* what is going on, while "." can mean many things, and I would have to investigate what .something in part of a chain does. Right?
Re: std.xml2 (collecting features)
If you really want to be serious about the XML package, then I humbly believe implementing the commonly-known DOM interfaces is a must. Luckily there is IDL available for it: https://www.w3.org/TR/DOM-Level-2-Core/idl/dom.idl . Also, speaking about DOM, all levels need to be supported! Also, I would recommend borrowing the Tango's XML pull parser as it is blazingly fast. Finally, perhaps integration with signal/slot module should perhaps be considered as well.
Re: C++ UFCS update
On Tue, 16 Feb 2016 08:08:46 +, Ola Fosheim Grøstad wrote: > On Tuesday, 16 February 2016 at 07:59:49 UTC, w0rp wrote: >> Personally, I find this proposal for C++ to be laughable. It's like >> hitch hiking from New York to California, and only getting as far as >> Texas and calling it good. >> >> The great thing about our UFCS is the left-to-right chaining of >> algorithms. >> >> x.map!(...).filter!(...).reduce!(...) >> >> It beats the Hell out of... >> >> reduce!(...)(filter!(...)(map!(...)(x))) >> >> This proposal will encourage non member functions, which is good, but >> will never reach the "aha" moment D had which gave us UFCS chaining. > > Ugh, that syntax is abusing the implied semantics of dot-notation; > member-access. Better to have a pipeline operator. > > Such syntax abuse is common in other languages too, so I don't get the > "aha". It is more a case of "ugh, repeated mistake"... > > Explicit extension methods is a much better alternative. +1 !! I *completely* agree with this. UFCS is OK in some places but not everywhere like people do lately. What you said about abusing the dot- notation is on the spot. It is not uncommon nowadays to see D code that I have absolutely no idea what it does, because of UFCS. I have to go through each piece separated by dots to understand what it is... -- Dejan Lekic ✉ dejan.lekic (at) gmail.com ➚ http://dejan.lekic.org
Re: Another new io library
Steven, this is superb! Some 10+ years ago, I talked to Tango guys when they worked on I/O part of the Tango library and told them that in my head ideal abstraction for any I/O work is pipe and that I would actually build an I/O library around this abstraction instead of the Channel in Java or Conduit in Tango (well, we all know Tango borrowed ideas from Java API). Your work is precisely what I was talking about. Well-done!
Re: Official compiler
Lots of programmers out there use and love languages that are far slower than any code DMD produces (think JavaScript, Python, Ruby). So I see no point here. If someone is learning D, and they know there are different compilers available, they would find out what are the differences. OpenJDK's JVM is not the best JVM in the world, yet millions of people use it. What I find in having DMD being a *reference compiler* useful is to have a compiler which has latest language changes.
Re: OT: 'conduct unbecoming of a hacker'
I am sure nobody will disagree with this post. Thing is, whenever there are people, there will be disagreements. I remember "final by default" vs "virtual by default" thread. I remember people whining and leaving the D community for X various reasons. What made me personally stick to D is that I humbly believe people who drive the project have clear ideas where do we go. I know some will disagree with me, but I will say it anyway: IT community, especially developers, are known for poor social skills... People tend to forget that...
Re: An IO Streams Library
I think this is a huge task and requires a (huge) DIP, and collaborative effort of coming up with a good, really good, API for BOTH synchronous and asynchronous IO. As mentioned in the previous messages, there is already an asyncio library, although I am not sure it is good enough to be in Phobos... I know people may not like Boost, but Boost.Asio is amazing and we should perhaps use it as a guide, if not copy the whole API...
Video record from the last London D Meetup (January 20)
It was quite interesting! Take a look: https://skillsmatter.com/skillscasts/7185-london-d-meetup Thanks Ross!
Re: TIOBE February 2016.... 15 ?!
On Wednesday, 3 February 2016 at 07:06:47 UTC, cym13 wrote: It's all true, D rose up 6 positions: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html I don't quite know what the leading factor for that change was but it sure will be great for its image. Well, people who observe TIOBE index knew this is going to happen. Did we? :)
Re: C++17
Finding a balance is hard, and I humbly believe having all the features C++ has in D will help... Correction: ...WILL NOT help...
Re: C++17
I humbly believe D should not care about C++ any more. It should take own path, and attract developers not just from the C++ camp. No matter from which camp someone comes, that person will complain about something. Obviously, C/C++ programmers complain about GC because they are used to manage the memory manually. People from JVM (this is where I belong even though I use D for over 10 years) and .NET worlds can rightfully complain about many things especially in the area of business applications and systems, distributed systems (90% of big-data solutions run on Spark, Hadoop or Storm). People from functional worlds will complain about OOP approach in the standard library. People from OOP world will complain about modules in the standard library that are done in more functional way... Finding a balance is hard, and I humbly believe having all the features C++ has in D will help...
Re: DIP 88: Simple form of named parameters
On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg wrote: This is mostly to prevent ugly hacks like Flag [1]. http://wiki.dlang.org/DIP88 [1] https://dlang.org/phobos/std_typecons.html#.Flag I already see confusing code like: foo(10, 20, width: ((big) ? 600 : 200), height: ((big) ? 800 : 480)); I know many people, especially those who are coming from the Python world, want named parameters, but I am not entirely sure we want that in D. I would rather use the Builder pattern instead, because that typically what people do with named parameters...
Re: Mockup of my doc dream ideas
Adam, I wonder could we also have information since what Phobos version particular symbol is available from. For an example, from which version of Phobos we have findSkip() ??
Re: Is there a FIX engine written in D?
https://github.com/libtrading/libtrading/blob/master/docs/quickstart.md Nice project - I did not know about it! Thanks! Major problem in writing a library which implements FIX protocols is lack of a good XML package. Yes, we have std.xml but it is far from good, and as we all know, it needs a replacement. Also, problem with FIX is that it may become redundant. There is a lot of criticism about it, and many exchanges decided to abandon it...
Re: Lifetime study group
I suggest we do not try to reinvent the wheel. Simply take a look how existing, large communities do this kind of work. Example: https://jcp.org/en/jsr/all For each large feature (a good example in the D case would be pattern matching, allocators, reference counting, additional garbage collectors, etc) a special working group should be formed. With initial working group owner who manages the group (adds other owners, collaborators, or some other types of users). Each group would work at own pace until they come up with a good design, and after that the group does the implementation as well. Each group would have own repository where they commit their work. Organising such groups can be uniform (something I think is better), or each group organises itself. Naturally, it is probably a full-time job for someone to coordinate with groups, does overall monitoring, etc. Each group can, and probably will, gain interest of the academic world, something we should encourage, and help PhD/MSc students jump in relevant groups to the benefits of both. Also, each working group can be tied to a GSoC project, mentored by people from the community. This will add an extra level of seriousness to the D project as I prefer to call it.
Re: Slack discussion group?
Just imagine a Slack channel with 100+ people where every second someone posts a code snippet, a picture, etc. :) Brr, I had that picture in my hear for few seconds and it looked scary. No, Slack is not for large communities (IRC), but for small, private teams.
Re: Moving back to .NET
Who cares? - Good luck in the .NET world.
Re: D and microservices
On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote: Has anyone got a small example of microservices using D, with Vibe.d or otherwise, that I can make use of? I need some examples of small microservices for a session at μCon 2015. As far as I know, there is no implementation of microservices as we see in the Java world. IMHO, D community should come up with a good microservices architecture. As you pointed out, it could be based on vibed.
Re: Nested public imports - bug or feature?
On Thursday, 13 August 2015 at 16:22:04 UTC, Dicebot wrote: On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis wrote: You can get that behavior with static imports in D, but having to use the whole import path while referencing symbols gets ugly fast. Check example again, you are only required to use the plain module name, not fully qualified one. With D syntax: import std.stdio; writeln(); // not good stdio.writeln(); // good std.stdio.writeln(); // also good, but not required Thank God, D does it the "not good" way. But I guess that is subjective thing. Some people like it one way, others like it the other way. I humbly belive D's way is good. Compiler should issue a warning when conflicts arrive. This is not Python for Haven's sake!
Re: D needs a programming blog and some house keeping
You will not believe how many D programming related blogs are out there...
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On Wednesday, 24 June 2015 at 16:10:44 UTC, Iain Buclaw wrote: http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ Which means that (strictly speaking), in 3 weeks time, there will be *no* operating system that supports CodeView debugging. This is an elongated way of asking "Can I remove -gc yet?" But as I'm not a Windows user, I'll have to ask how you guys deal with debugging, and if you still rely on CV being emitted from DMD, you must hurry up to implement an alternative! Iain. I do not know about others, but I am using XP, and have no plan to move to something else any time soon. However, I am using it rarely, in a VM, whenever I need to test something on Windows. I have no plan of buying a newer Windows. I am sure there are many developers who do the same, or similar. :)
Re: Suggested enhancement: New basic datatype: 'dec'.
I must admit I only quickly read the post - I think this can relatively easily be done as a template, and (depending on the quality of that template) it could go into Phobos.
Re: Negation of attributes (DIP 79)
On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
I am working on dip which will try to addressed negation of
attributes issue.
http://wiki.dlang.org/DIP79
You propose to add extra difficulty to the language and the
only reason is "If you need add few methods which are virtual
or variables, you are forced to put them before final:. This is
too limiting.".
I think it's a bad idea.
I agree.
On top of that, we have final { /* your final methods here */ }
as a good alternative already.
Finally, as far as I know, D will change the behaviour to final
by default. What happened with that? Anything decided?
Re: Any plans to support STL value types?
On Friday, 15 May 2015 at 19:51:09 UTC, anonymous wrote: On Friday, 15 May 2015 at 19:44:29 UTC, Jonathan M Davis wrote: On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote: Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend? Given that the inheritance they have is actually undesirable when they are treated as value types, I doubt that there's much need. If you're using inheritance in C++, you're putting your class on the heap and accessing it via pointers, in which case, accessing them in D as classes makes sense. And if you're using these STL types as value types on the stack, then they can be treated as value types. Doing otherwise just risks object slicing, which is not desirable in the least. So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it. - Jonathan M Davis rust does it just fine without slicing, and supports both static dispatch and dynamic dispatch through the same interface. http://blog.rust-lang.org/2015/05/11/traits.html honestly, this is one of the worst parts of D. Being forced to code a certain way because it might be misused is the equivalent of digital socialism. How is this a "digital socialism"? :) Nobody forces you anything. The community made Phobos - if you do not like it, use something else. :) There is Tango/D2 project too, if that one does not fit your need, use OR create something else! Second, what do you mean when you say (type) "D"? D community, D programming language, or what? If by D you refer to D as a programming language (and that is what I think when you say D) - sorry to break it up to you, but EVERY SINGLE language (not just programming) forces specific rules upon programmer! Back to the topic - nobody stops anyone from writing a module which provides what the original question was about. Is there any value in having STL value types? - I do not see them, but that does not mean someone else may see it differently.
Re: Request for Features/Ideas: A std.archive package
On Sunday, 17 May 2015 at 16:32:31 UTC, Liam McSherry wrote: Phobos currently has packages for working with various archives (Zlib/Gzip, Zip), and it's probably reasonable to expect that support for more archive formats will be added in future. Before any more are added, it would probably be beneficial to define an interface that any modules adding support for archives should obey, and having archive related modules under std.archive for organisational purposes probably wouldn't hurt. I saw a suggestion for improved archive support on the D wiki's wish list, and the code link 'std.archive' module in the review queue now 404s, so it looks to be the case that there isn't currently an effort to implement an archiving package for Phobos. What I would propose for such a package is: - Split archives in to two categories: stream-based (Gzip, Zlib, Bzip, etc) and file-based (Zip, Tar). - Make support for creating archives optional (e.g. by having IStreamArchive and IWritableStreamArchive). - Make compression-related functionality separate (e.g. through an ICompressableArchive(T) interface, where T is an enum specifying algorithms). I'm not sure on this one, so ideas are especially welcome for it. - A hierarchy of exceptions for implementations under std.archive rather than the current Phobos norm of everything having its own exceptions. I'd like to know whether there would be demand for such a package, and what the community would want in terms of the API and features. I haven't yet written any code for the package as the API is going to be one of the most important parts, and I thought it would be best to have agreement on what is wanted before starting on it. We need two things actually: 1) compress package with set of commonly used compression algorithms. std.alg.compress comes to mind as package name. 2) VFS module/package with set of interfaces and reference implementations for as many formats as possible. 3) It would be extremely useful to have something like Java SPI (http://en.wikipedia.org/wiki/Service_provider_interface) in D. All the VFS implementations would then follow this standard and give us truly runtime-replaceable components. More about this: http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf
Re: Good examples of value types
On Tuesday, 5 May 2015 at 20:40:59 UTC, Luís Marques wrote: Hi, For a comparison with the Java language, I'm trying to come up with some good examples of custom types that should be value types (but that must be ref types in Java). I think the most obvious ones are numeric types. So BigNum, MyNum, etc. are good examples because programmers are used to numeric types being value types, and having them suddenly become a ref type just because it's MyNum instead of long is really annoying. Still, could you come up with some type that would really benefit from being a value type but that isn't numeric (or otherwise similar)? Thanks for your help! Luís To add to what others have said - whenever you think you will benefit from stack-allocation. Read this article: http://www.ibm.com/developerworks/library/j-jtp09275/ Java is good at escape analysis. But I find it really useful to be able to specify a type that will always be allocated on the stack (unless you really want it on the heap).
Re: Fun project - faster associative array algorithm
On Tuesday, 7 April 2015 at 17:25:00 UTC, Walter Bright wrote: The current D associative array algorithm https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aaA.d uses an array of buckets with a linked list attached to the buckets to resolve collisions. Linked lists are perhaps the worst (i.e. slowest) data structure possible on modern CPUs with memory caches. A possible cache-friendly replacement would be an array of buckets with local probing to resolve collisions. D programs are often heavily dependent on associative arrays, so this could be a big win for us. And it's a fun project, too. Any takers? Interestingly, https://github.com/D-Programming-Language/dmd/blob/master/src/root/stringtable.c uses quadratic probing instead of linked lists, but this is not cache friendly, either. Every now and then I think how nice it would be for Phobos to be just a bunch of "module interfaces" along with default implementations of them. Unfortunately, or fortunately, D does not have module interfaces like, say, Modula-3. It would make things much easier for someone who wants to work on a different implementation of a certain module (or even whole package) implementation. I wonder what other people think about this.
Re: Novel list
On Wednesday, 25 March 2015 at 09:29:40 UTC, Russel Winder wrote: http://hammerprinciple.com/therighttool/statements/this-language-is-best-for-very-large-projects Nice one - I wonder what people answered to "PROGRAMS WRITTEN IN THIS LANGUAGE WILL USUALLY WORK IN FUTURE VERSIONS OF THE LANGUAGE" ??? :) We all know the answer to that question regarding the D programming language. :D
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Tuesday, 24 March 2015 at 14:17:26 UTC, Dejan Lekic wrote: On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. I could take this task, with help of Brian's scanner I could easily find that methods to document... Let me know should I take it or not. Actually, I just realised what the issue is... :) I apologise. I thought the task is to document those functions that are not yet documented. Why would you want DDoc to issue those errors? I would rather setup a git hook which is using Brian's dfmt, or implement something similar to Checkstyle in Java world, and use it in git hook to prevent undocumented functions creeping into the D code...
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. I could take this task, with help of Brian's scanner I could easily find that methods to document... Let me know should I take it or not.
Re: const as default for variables
On Saturday, 14 March 2015 at 20:15:30 UTC, Walter Bright wrote: I've often thought, as do many others here, that immutability should be the default for variables. [This is a long term issue. Just thought maybe it's time for a conversation about it.] Because immutable is transitive, declaring variables as immutable by default would be problematic. A more practical way would be to make them const. As it is now: 1.int x = 1; // mutable 2.auto x = 1; // mutable 3.const x = 1; // const 4.immutable x = 1; // immutable Case (1) is what I'm talking about here. If it is made const, then there are a couple ways forward in declaring a mutable variable: a) Introduce a new storage class, called 'var' or 'mut'. (Please, no bikeshedding on names at the moment. Let's stay on topic.) b) Use 'auto' as meaning 'mutable' if the initializer is also mutable. Extend 'auto' to allow an optional type, auto T t = initializer; There may be some ambiguity issues with 'auto ref', haven't thought it through. Once there is a non-default way to declare variables as mutable, a compiler switch can be added to change the default to be const. Eventually, the language can default to them being const, with a legacy switch to support the mutable default. I definitely think this is a good idea. And if someone wants mutable variable, we simply use proposed 'var' storage class. Brilliant!
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 06:57:29 UTC, Russel Winder wrote: On Thu, 2015-03-12 at 20:24 -0700, Walter Bright via Digitalmars-d wrote: […] There's no doubt about it, people like simple languages. We should very much keep that in mind when evaluating proposals for new features. How about lining up some features for removal. C++, Fortran, and Java are big, complicated languages, that keep getting bigger and more complicated because of the obsession with backward compatibility. D is already a big, complicated language. If people like straightforward (not necessarily simple) languages, then the inference is quite easy. Java big, complicated language?? :) I do not agree with that statement at all. Java *is* there where it is because it is SIMPLE language, and equally hated for being simple language. We can't satisfy everybody. D can be super-simple too - people do not have to use fancy features of the language. I think most tutorials/articles tell readers too much about D, and it may scare them away.
Re: Standard GUI framework inspired by Qt
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote: Hi all I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented. In that duscussion many participants agreed that Qt would be a good foundation, but had very restrictive license. Things have changed since then, and Qt now is available under LGPL, which, to my undestanding, makes it suitable for the purpose of standard GUI library (please correct me if I am wrong on this). The license, of course, may change in the future, preventing us from using their updates for our drawing engine. But if we are able to start using the engine now, in the future we can maintain the updates ourselves. Now, how I envision the library's design: The library will be mostly implemented in D, except for drawing engine and event loop, which are system-dependent. Those two parts will be extracted from Qt into a separate library which will be linked to by the rest of framework either statically or dynamically. There will be bindings for sending drawing instructions to drawing engine, as well as for retrieving system and GUI events from event loop. The system-independent part will mimic architecture of Qt. However, for maximum flexibility and customizability, GUI will utilize QML+CSS approach, and Qt's layout manager classes will be dropped completely. Also there is no need to port classes that are available in D, such as collections and strings. If there is no standard GUI for D yet, and if LGPL license fits our purpose, then I am looking for 2-3 Qt experts to join me and build the framework. Thanks, Aram I would rather have a GUI framework inspired by JavaFX, plus some features that could be added on top of it, that are related to the fact that D programmers can utilize hardware directly. JavaFX is in my humble opinion one of the best designed GUI APIs in existence today. Similar D API would be smaller because we would get rid of typical Java bloat.
Re: What's missing to make D2 feature complete?
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote: Just wondering what the general sentiment is. For me it's these 3 points. - tuple support (DIP32, maybe without pattern matching) - working import, protection and visibility rules (DIP22, 313, 314) - finishing non-GC memory management There is no "feature complete" language. What makes mainstream languages more likely candidates for future software projects is the fact that they are properly maintained by a team of professionals language community trusts. I can give Java and C++ as perfect examples. (I am doing this mostly because these two are what I used most of the time in my professional career) - None of them is "feature complete", yet they are most likely candidate languages for many future software projects. Why? I believe the major reason why is that there is a well-defined standardization process, and what is more important, there are companies behind these languages. Naturally, this makes the new features come to the language *extremely slowly* (we talk 10+ years here). Perhaps the best course of action is to extract the stable features that D has now, and fork a stable branch that is maintained by people who are actually using that stable version of D in *their products*. This is crucial because it is in their own interest to have this branch as stable as possible. "Problem" with D is that it is pragmatic language, and this "problem" is why I love D. The reason I say it is a problem is because there are subcommunities and people with their own view on how things "should be". Examples are numerous: GC vs noGC, functional vs OOP, pro- and anti- heavily templated D code. Point is - it is hard to satisfy all.
Re: 2 types of D users, both can live together happily if we adjust
Saying that there are "2 types of D users" is the same as saying "I see the world black and white". :) - It is far from reality. D community has lots of "groups" if you look closely. Examples: 1) OOP vs functional/declarative group. 2) system programming vs business programming group. 3) no-GC vs GC group. (related to #2). 4) Stable D spec group vs unstable D spec group (what you call "experimental"). Etc. 5) web UI vs "native" UI (based library X where X = Qt, Gtk, FLTK, SDL etc) Finally, there is "stable D" (D1) but ironically it is not supported as far as I know. There is no D2 version that can be considered stable. - There would be, if D team was organised properly and decided to maintain a stable D2 branch that is free of "things in motion". What are alternatives? - Make the abovementioned "stable D" branch by yourself, and maintain it in-house. It is really hard to do all this in a truly open project because maintaining this stable branch is IMHO a full-time job.
Re: Need help deciphering posix.mak
On Friday, 28 November 2014 at 08:45:30 UTC, Jacob Carlborg wrote: There's usually no problems with Python on Posix, but on Windows, I really don't want that. I really like that DMD has so few dependencies. Same here. I prefer the current situation where we build DMD and runtime using Make.
Re: Need help deciphering posix.mak
I never liked SCons for some reason. I prefer CMake over it. Waf is IMHO better than SCons too. Maybe it is more fair to compare SCons and Waf as they both are Python-based. Anyhow, use whatever works for you. :)
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Wednesday, 29 October 2014 at 12:55:01 UTC, FrankLike wrote: The same thing in D should be done,now.Otherwise，no big projects can be done like C#. Add another keyword,and update the compiler. This certainly made me laugh... I work on a very big project (Java / JBoss / Swing) and we do not use C#'s partial as Java does not have it. :) Even if it does we would not use it as we prefer our classes to be in a single file. In D apps I work on I prefer all my classes in a single module, as is common "D way", or shall I call it "modular way"?
Re: Blaming the D language
On Wednesday, 22 October 2014 at 08:14:24 UTC, Ola Fosheim Grøstad wrote: 2. Easy to write ugly code: It suffers from the same issues as macros. It is easy to write ugly code in D without string mixins. Just take a look at the (ab)use of UFCS...
`Reconsidering Custom Memory Allocation`
Yesterday I stumbled upon this excellent research paper: Reconsidering Custom Memory Allocation - (PDF: http://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf ) It got the "Most Influential OOPSLA Paper Award" in 2012. Abstract (for those lazy to read it): "Custom memory management is often used in systems software for the purpose of decreasing the cost of allocation and tightly controlling memory footprint of the software. Until 2002, it was taken for granted that application-specific memory allocators were superior to general purpose libraries. Berger, Zorn and McKinley’s paper demonstrated through a rigorous empirical study that this assumption is not well-founded, and gave insights into the reasons why general purpose allocators can outperform handcrafted ones. The paper also stands out for the quality of its empirical methodology."
Re: Looking to hire: 2-3 programmers, candidates will likely need to learn D.
On Monday, 21 July 2014 at 02:43:51 UTC, Vic wrote: (I hope OK to post:) Location: Silicon Valley /San Jose, CA/ or Dallas TX. Current 'app' version is mostly Java/Tomcat, so will need to maintain that while writing a new version, likely mostly D ( possibly Qt depending on GC ). (Also a few lines assembly, C, IOS Objective C, Andorid as clients) OS will be Gentoo flavor. There is some fun data structures and some boring HTTP in the project, I'll have to tell you more if you ping us, some of it is fun tech but I don't want it public. The company is a 7 digit funded start up, a bit more about the project - http://ceocfointerviews.com/interviews/Apakau14.htm Ideal candiate is a career programmer/developer, prolific coder would be supper. Experience prefered, a few years out of school might be considered. Company culture is tech friendly/introvert (as opposed to marketing/business type orgs). Market rate salary, but first few hire we don't have much for reloaction budget(not looking for remote for first year+). Of course 30" monitor, Xeon workstation, good vacation time, gym and more, of course D conference or similar is company expense. There are some trade secrets to keep. To have a phone chat, please email me your resume/bio to vic (at) apakau.com. Likely we will be done hiring in a week or 2. (I plan to cross post on Qt and Vibe.d forums) Vic, I posted the job to the D Developer Network at LinkedIn: https://www.linkedin.com/groups/Looking-hire-2-3-programmers-3923820%2ES%2E5911023777222787073?trk=groups%2Finclude%2Fitem_snippet-0-b-ttl Good luck!
Re: Is there a native function to detect if file is UTF encoding?
On Friday, 22 August 2014 at 13:53:04 UTC, MacAsm wrote: To call decode() from std.encoding I need to make sure it is an UTF (may ne ASCII too) otherwise is will skyp over ASCII values. Is there any D native for it or I need to check byte order mark and write one myself? You may want to take a look at http://dlang.org/phobos/std_stream.html#.EndianStream.readBOM . Note that this module is scheduled for depreciation...
Re: What's going on with std.experimental.lexer?
Please no. See: javax Spelling out 'experimental' is probably the best, for all those reasons already stated. What's wrong with javax?
Re: Need review: explicit package protection
I'd call this "INVALID WON"T FIX" :) D module system is defined to have strong 1-to-1 matching with file system. Any attempt to circumvent that in favor of personal preferences is asking for trouble and is not worth supporting. I can only agree with this, but fact is that D allows flattened project structure (all modules in all packages in a single directory)... It should be noted that people who prefer such structure are on their own. I myself prefer to have a directory per-package, as it is IMHO more clear and organised.
Re: dlang website: remove that quick try editor
John wrote: > dlang.org website has a quick try editor with D code example. > Please remove that feature (at least the buttons to run it) as it > takes ages to run the example and leaves an impression that D is > very slow!! > > This is only good if it can run quickly like the similar feature > available on the golang website. > > If you love this feature and refuse to remove it, at least please > move it to another page. You don't want to lose people within > minutes of their first visit to D website with a total > misunderstanding of the purpose and power of the D language. I hope you did not expect something on the web ba faster than a native application... :) -- http://dejan.lekic.org
Re: What's going on with std.experimental.lexer?
On Thursday, 5 June 2014 at 10:57:37 UTC, Dicebot wrote: On Wednesday, 4 June 2014 at 21:12:25 UTC, Brian Schott wrote: I've been looking at ways to optimize the D lexer's operation using SIMD instructions. I'm not yet sure if I'll need to change the lexer generator's API to do this. I'm going to wait until I have my proof-of-concept code and some benchmark results before asking for a voting thread or creating a pull request. I still thing we should use it more like `std.staging` - once your updates are ready, go through review/voting and keep module in `std.experimental` for at least one DMD release before adding to Phobos core. This also means relaxing API requirements a lot for initial inclusion. I am more for "stdx", which is what some developers already use as package name for experimental stuff.
Re: Free wildcard SSL certificates for OS projects
Dicebot wrote: > Have just found https://www.globalsign.com/ssl/ssl-open-source/ , > states to provides certificates (including wildcard ones) for > free if your project complies to: > > - Must be licensed with a license approved by the Open Source > Initiative > - Project must be actively maintained > - Order must meet all vetting requirements > - Follow industry best practices in configuring your SSL and get > an "A" when tested with the SSL Checker > - Agree to the standard Subscriber Agreement > - Not be a site that is also used for commercial purposes > > Have anyone tried it? Might be of interest for some D projects. Thanks for the info! I will definitely need it! :) -- http://dejan.lekic.org
Re: Need review: explicit package protection
On Sunday, 8 June 2014 at 15:37:06 UTC, Dicebot wrote:
Finally got to cleanup and submit this PR:
https://github.com/D-Programming-Language/dmd/pull/3651
While proposed change is very small (and backwards-compatible)
and not worth separate DIP, it is still a language change and
needs community approval.
Copy of description:
Currently there is no way to use package protection attribute
with deeply nested package hierarchy, forcing to either use flat
one or public protection. This is one of blocking issues for
further usage of package.d in Phobos and one of reasons why
namespace hacks are so popular.
For example, if helpers in std.internal will be marked as
package, only std.internal will be able to access those, but not
rest of std. This PR fixes it by allowing package()
syntax to explicitly define owning package.
This new syntax will work:
---
module std.internal.mod1;
package(std) void foo() {}
module std.mod2;
---
import std.internal.mod2;
void bar() { foo(); }
Exact semantics can are described by added "protection" tests to
test/compilable (last commit in this PR).
Plain package behavior is unchanged and thus no breaking changes
introduced.
+1
Definitely worth merging!
However, package module still have few issues.
Issue #1)
Few times I asked myself "what am i importing, package or a
module?" when I used package module, so whenever I import a
package, I add a short comment, something like:
// assuming I have
import foo.bar.baz; // package import
Issue #2)
Package module is not possible in projects with flat structure
(projects whose authors did not reserve directories for packages.
Example:
Imagine developer has *all* his D sources in
/home/dejan/src/d/myawesomeproject because he does not like big
directory structures. Say his project has two packages foo.bar
and foo.baz . And has following files in his project directory:
tools.d // module foo.bar.tools;
control.d // module foo.bar.control;
screen.d // module foo.baz.screen;
window.d // module foo.baz.window;
package.d // can be only one 'package.d' within a single
directory!
main.d
So, we have to rename the file into something else. Most likely
developer would try with foo_bar_package.d and foo_baz_package.d,
but it is not possible to do module foo.bar; // conflicts with
previous modules
or
module foo.bar.package; // package is a reserved word
So in this case package module is not possible, and developer has
to use classic approach if he/she wants to import all modules
within foo.bar or foo.baz packages.
Re: Fedora DMD package
Russel Winder via Digitalmars-d wrote: > Is there a good reason why the dmd Fedora 20 package pulls in the > following as dependencies: > > cyrus-sasl-libi686 2.1.26-14.fc20fedora > 152 k > glibc-devel i686 2.18-12.fc20 updates > 1.0 M > libcurl i686 7.32.0-10.fc20updates > 225 k > libidni686 1.28-2.fc20 fedora > 209 k > libssh2 i686 1.4.3-9.fc20 updates > 133 k > nspr i686 4.10.5-1.fc20 updates > 124 k > nss i686 3.16.1-1.fc20 updates > 878 k > nss-softokn i686 3.16.1-1.fc20 updates > 311 k > nss-util i686 3.16.1-1.fc20 updates > 68 k > openldap i686 2.4.39-2.fc20 updates > 335 k > > OK, I can perhaps see why glibc-devel, but the rest? And why i686 > packages on an x86_64 machine? > > Thanks. > glibc-devel.i686 is needed by DMD to successfully build 32bit executables. The rest is probably there because someone made a mistake. libcurl should be the only other dependency there, I think. -- http://dejan.lekic.org
Re: D Grammar in BNF Text Form?
On Friday, 6 June 2014 at 12:05:36 UTC, Robert Schadek via Digitalmars-d wrote: On 06/06/2014 12:29 PM, Tom Browder via Digitalmars-d wrote: Can anyone point me to a text version of the D grammar in some kind of BNF or EBNF format? The D lang web site's info is close, but it's buried in html which I'ld rather not have to wrestle with. My purpose is to attempt to write a D language parser in Perl using Damian Conway's Regex::Grammars module (on CPAN). Thanks. Best regards, -Tom The site says it creates recursive decent parser. D does not even fit into lalr1. So it will not work, unless you can inject handwritten parse function for the critical parts Dscanner project has ANTLR grammer for D. It is unpolished, but works. It is on Github.
[OT] C++ the Clear Winner In Google's Language Performance Tests
Slashdot thread: http://developers.slashdot.org/story/11/06/15/0242237/c-the-clear-winner-in-googles-language-performance-tests Research paper: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf I wonder what would be situation if they included D, Rust and even Ur in that benchmark... :)
Re: SurveyMonkey for D users OS - Results
One 'other' vote was spoiled. It turns out that the free SurveyMonkey account only allows 100 votes max, but the profile has been much the same since 50 votes so I think the ratios are clear. Perhaps you should try http://www.surveygalaxy.com . That is what I use when I need a survey.
Re: [OT] Extra time spent
On Wednesday, 4 June 2014 at 17:57:16 UTC, Nick Sabalausky wrote: On 6/4/2014 7:59 AM, Dejan Lekic wrote: I humbly believe programmer who does not spend spare time reading literature related to his/her work is most likely going to lose the job at some point, as people who DO spend time in their self-education will take the place. I know from direct observational experience that, depending on the company, keeping one's job (or even getting one in the first place) is not always dependent on one's ability to actually do the job at all. (Heck, I've tutored CS 101 students, and even still: the worst code I've ever seen by far was NOT beginners, but was production code written by professionals whose jobs were nowhere near the chopping block.) Well, we both know that circumstances can be pretty chaotic in any company. I am not going to defend professionals who write bad code, but I am just saying that I can understand the stress, and all that goes together, especially if the person is senior. A typical scenario is when (top-level) manager (M) want thing yesterday, and tell senior engineer (SE) M: How long will it take? SE: Well, we did not even analyse the requirements for this feature. Let's spend some time brainstorming this first, and then I will be able to do better estimation. M: We have no time for that, and I think you already have all you need. SE: OK, 3 days. M: What??? We need this thing yesterday! SE: Well, I could do a quick hack... It will take 1 day, but we will not have time to test, no time for code quality, etc. M: DO IT!!! (that "quick hack" code stays there because next week another urgent thing came, and SE never had time to make the code better) Moral of the story: it is not SE whom we have to blame for bad code, it can easily be the management who made deliberate decision for that... That said, you're certainly right that continual self-education is very important (even if one's job isn't on the line).
Re: Swift is based LLVM,what will the D's LDC do?
On Wednesday, 4 June 2014 at 09:45:21 UTC, Temtaime wrote: I think too that main branch of D should be LDC. Proprietary backend is one big mistake. No matter how I like LDC, I disagree. People obviously forget the fact that DMD is a REFERENCE IMPLEMENTATION of a D compiler. - Nobody has to use it, and most likely you will not use it in production! You will use a compiler with better optimizer, such as GCC with D enabled (GDC) or LDC. FUD won't help anyone, so do not spread it further. We have discussed this matter for over a decade here on this very newsgroup. There is a valid reason why the backend is proprietary, learn to live with it. Some linux distributives doesn't want to include dmd because of backend's license. Also backend has several codegen bugs. And it cannot optimize almost at all. We are all perfectly aware of this. I've spent hours talking with Fedora guys on IRC, and asked what can we do to have DMD RPMs (you can find the project here: https://gitorious.org/dejan-fedora/dejan-fedora ). LLVM is tested in time as Clang. It has great optimizations. And if one speak about compilation time... Yes dmd compiles faster than ldc but the difference is not so great. And who cares about compilation time when one write the code ? Every serious developer does. Once your project takes a minute to compile you will treasure every second... Sure for the release you will use a better compiler, but during the development you really want compiler that does it fast.
Re: [OT] Extra time spent
On Friday, 30 May 2014 at 11:35:19 UTC, Chris wrote: Reading through Adam's book at home made me think about how much time I've spent reading / learning / thinking about programs outside the office. I read TDPL in my spare time. I checked out things in the D Cookbook in my spare time and applied them the next day, like loads of other things about programming and actual programs. I guess most people here have similar experiences. The issue is that most employers don't really appreciate this. Are we mad or just passionate? I humbly believe programmer who does not spend spare time reading literature related to his/her work is most likely going to lose the job at some point, as people who DO spend time in their self-education will take the place. Surely, there is an exception - when company actually INVESTS in the education of employees. Unfortunately not all companies do this. Most big ones do, smaller companies most likely won't have resources for education of employees. Furthermore, they think the work itself will educate. Sure it will, to a certain level. But work won't teach us new technologies and techniques. - This is something we learn ourselves. Here is reason why it is always good to have a geek who spends another 8h a day at home learning new, exciting stuff - because that geek typically shares that knowlege at work as well.
