Re: SublimeLinter-contrib-dmd: dmd feedback as you type
On Tuesday, 31 October 2017 at 16:00:25 UTC, Bastiaan Veelo wrote: [...] Out of curiosity, what other plugins from [2] do you use in Sublime Text? How are they integrating with dub? If that question is open to the general public: None, I hacked my own [1] to suit my exact needs. [1] https://github.com/MoritzMaxeiner/sublide
Re: SublimeLinter-contrib-dmd: dmd feedback as you type
On Tuesday, 31 October 2017 at 13:32:34 UTC, SrMordred wrote: Thank you , works perfectly! One idea: Integrating with dub. So you don´t have to manually set lib dirs and flags since its all on 'dub.json' already. You can pretty much copy paste from sublide for this [1] (my own D plugin for ST3). [1] https://github.com/MoritzMaxeiner/sublide/blob/master/dub.py#L40
Re: LDC 1.4.0
On Monday, 11 September 2017 at 23:32:55 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.4.0. The highlights of version 1.4 in a nutshell: * Based on D 2.074.1. [...] Fantastic news, thanks for your work!
Re: D on devdocs
On Monday, 11 September 2017 at 03:23:47 UTC, ANtlord wrote: Hello. I'm not sure that you know, but documentation of D language has become to devdocs.io. It is web service provides offline documentation. We've got a useful tool for documentation viewing and reading. The next step is an implementation of version support. Didn't know about it until it was mentioned in another thread here recently [1], but I do think this is great and I especially like their dark theme (clean, minimal). Do you know how much work would it be to reuse devdocs (I see it is open source) as a basis for hosting dub package docs)? [1] http://forum.dlang.org/thread/mailman.6556.1504522081.31550.digitalmar...@puremagic.com
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven Schveighoffer wrote: On 8/23/17 11:59 AM, Walter Bright wrote: On 8/23/2017 7:37 AM, Steven Schveighoffer wrote: How do dynamic closures work without the GC? They don't allocate the closure on the GC heap. (Or do I have static/dynamic closures backwards?) I thought "closure" means allocating the stack onto the heap so you can return the delegate with its context intact. From https://en.wikipedia.org/wiki/Closure_(computer_programming) : "A language implementation cannot easily support full closures if its run-time memory model allocates all automatic variables on a linear stack. In such languages, a function's automatic local variables are deallocated when the function returns. However, a closure requires that the free variables it references survive the enclosing function's execution. Therefore, those variables must be allocated so that they persist until no longer needed, typically via heap allocation, rather than on the stack, and their lifetime must be managed so they survive until all closures referencing them have are no longer in use." Right, so if we wanted to support closures in betterC (we don't now, as my earlier example shows), they'd need a separate lifetime management implementation. The two straightforward ones are either disable copying of closures in betterC (only moving them), so a single ownership model of their heap allocated context pointer is possible (deallocating the memory once the closure is destroyed), or make them reference counted. The first has the disadvantage that you can't have two closures point to the same heap context (though to be honest, I haven't seen a codebase so far that actually uses that), but it should be trivial to implement. The RC variant is more complex (it would require an analysis if reference cycles can occur), but I think this might be one of the cases where RC is the right solution (and we might even consider using RC in normal D as well, if it works sanely).
Re: D as a Better C
On Wednesday, 23 August 2017 at 15:17:31 UTC, Moritz Maxeiner
wrote:
On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven
Schveighoffer wrote:
On 8/23/17 9:12 AM, Mike Parker wrote:
To coincide with the improvements to -betterC in the upcoming
DMD 2.076, Walter has published a new article on the D blog
about what it is and why to use it. A fun read. And I'm
personally happy to see the love this feature is getting. I
have a project I'd like to use it with if I can ever make the
time for it!
The blog:
https://dlang.org/blog/2017/08/23/d-as-a-better-c/
Reddit:
https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/
How do dynamic closures work without the GC?
Nice article, BTW.
-Steve
They don't (right now, using dmd ~master), because they depend
on druntime:
[...]
Sorry, I screwed up when pasting. Here's what I meant to post:
--- a.c ---
#include
#include
uint32_t foo();
int main(int argc, char** argv)
{
uint32_t x = foo();
printf("%d\n", x);
return 0;
}
---
--- b.d ---
auto test()
{
uint i = 42;
return () {
return i;
};
}
$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
"__d_allocmemory", referenced from:
_D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven
Schveighoffer wrote:
On 8/23/17 9:12 AM, Mike Parker wrote:
To coincide with the improvements to -betterC in the upcoming
DMD 2.076, Walter has published a new article on the D blog
about what it is and why to use it. A fun read. And I'm
personally happy to see the love this feature is getting. I
have a project I'd like to use it with if I can ever make the
time for it!
The blog:
https://dlang.org/blog/2017/08/23/d-as-a-better-c/
Reddit:
https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/
How do dynamic closures work without the GC?
Nice article, BTW.
-Steve
They don't (right now, using dmd ~master), because they depend on
druntime:
--- a.c ---
#include
#include
uint32_t foo();
int main(int argc, char** argv)
{
uint32_t x = foo();
printf("%d\n", x);
}
---
--- b.d ---
auto test()
{
uint i = 42;
return () {
return i;
};
}
oo()
{
auto x = test();
return x();
}
---
$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
"__d_allocmemory", referenced from:
_D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
ld: symbol(s) not found for architecture x86_64extern(C) uint
foo()
{
auto x = test();
return x();
}
---
$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
"__d_allocmemory", referenced from:
_D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:00:34 UTC, Walter Bright wrote:
On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:
I've been mixing C and full D for a while now (on Linux) by
either having the main C program call rt_init/rt_term directly
(if druntime is linked in when building a mixed C/D
application), or have Runtime.initialize/Runtime.terminate be
called from D via some plugin_load/plugin_unload functionality
when using D shared libraries.
Why is this not considered practical?
Because in order to add a D function as trivial as:
int foo() { return 3; }
to a C program, now the C program has to link to druntime, and
the program no longer has a small footprint. One of the reasons
people use C is to get that small footprint. This has been a
large barrier to C programs making use of D.
Thank you, are there other factors involved, or is it only
impractical for people who require minimal application size /
memory footprint, then?
Re: D as a Better C
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is getting. I have a project I'd like to use it with if I can ever make the time for it! The blog: https://dlang.org/blog/2017/08/23/d-as-a-better-c/ Reddit: https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/ Interesting article, though one thing that I'm confused by is Hence D libraries remain inaccessible to C programs, and chimera programs (a mix of C and D) are not practical. One cannot pragmatically “try out” D by add D modules to an existing C program. I've been mixing C and full D for a while now (on Linux) by either having the main C program call rt_init/rt_term directly (if druntime is linked in when building a mixed C/D application), or have Runtime.initialize/Runtime.terminate be called from D via some plugin_load/plugin_unload functionality when using D shared libraries. Why is this not considered practical?
Re: Release D 2.075.0
On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D 2.075.0. This release comes with various phobos additions, a repackaged std.datetime, configurable Fiber stack guard pages (now also on Posix), and optional precise GC scanning for the DATA/TLS segment (static data) on Windows. http://dlang.org/download.html http://dlang.org/changelog/2.075.0.html Sorry for replying so late, but the changelog for 2.075.0[1] incorrectly list issue 14246[2] as solved, when the fix was, in fact, reverted [3]. [1] http://dlang.org/changelog/2.075.0.html#bugfix-list [2] https://issues.dlang.org/show_bug.cgi?id=14246 [3] https://github.com/dlang/dmd/pull/6913
Re: Release D 2.075.0
On Monday, 24 July 2017 at 23:25:50 UTC, Martin Nowak wrote: On Monday, 24 July 2017 at 22:15:16 UTC, Moritz Maxeiner wrote: One thing to watch out for, though, is that if the D frontend starts using features introduced after its conversion to D, we are going to need to explicitly document the bootstrapping path (right now it's still simple enough with `C++ compiler -> D compiler with 2.068.2 frontend (e.g. ldc 0.17.x) -> Latest D compiler`). We're using the latest previous major release line to build releases, so 2.068.x build 2.069.x, builds 2.070.x, ..., builds 2.075.0. That's a sensible choice for the official binary distribution. You might get away with skipping versions, but that's not how the releases were built. When you bootstrap (e.g. on any source based Linux distribution such as Gentoo, Funtoo, ...) you want the path to be as short as feasible (even with dmd's fairly short compile times) and how the official binary releases are/were build isn't part of the consideration, because - unlike them - you don't happen to have a D compiler with D frontend version - 1 ready for use. In any case, all that would be required - if the path ever becomes longer - would be an automatically updated file like this: bootstrap-path: --- 2.068.2 --- An autotester can then check before each release if dmd master can still be build by dmd with the version of the last line in that file, and if not, append the last dmd release to it.
Re: Release D 2.075.0
On Saturday, 22 July 2017 at 21:22:00 UTC, Walter Bright wrote: Putting the entire set in D (C compiler, C++ compiler, C preprocessor, htod converter, optimizer, code generator) makes the whole thing much more tractable, and who knows what we will be able to do with it! One thing to watch out for, though, is that if the D frontend starts using features introduced after its conversion to D, we are going to need to explicitly document the bootstrapping path (right now it's still simple enough with `C++ compiler -> D compiler with 2.068.2 frontend (e.g. ldc 0.17.x) -> Latest D compiler`).
Re: Boston D Meetup: Strawman Structs
On Sunday, 23 July 2017 at 02:15:18 UTC, Steven Schveighoffer
wrote:
struct StrawmanRange(T)
{
...
void popFront() {}
}
How do you deal with ranges where `.popFront` returns the old
front element (`.front` requires copying the front element if the
caller wants to store it, `.popFront` can move it)?
llvm-d 2.2 Dynamic loading (yet again)
In response to a DConf 2017 request regarding this, llvm-d again supports dynamic loading. The API is essentially the same as is was for llvm 1.x, though you have to enable it with D versions. - Single shared library only (e.g. libLLVM-X.Y.Z.so) - Switch from (dynamic/static) linking to dynamic loading by setting the D version LLVM_Load. - Use LLVM.load / LLVM.unload for manual control over which shared library to use - Additionally set D version LLVM_Autoload to try to load a platform appropriate default shared library for LLVM - As compile time introspection is used to generate function pointers dynamic loading has increased compilation time. Special thanks to everyone who provided feedback[1] on how to optimize the cost for the dynamic introspection https://github.com/Calrama/llvm-d/releases/v2.2.0 https://code.dlang.org/packages/llvm-d/2.2.0 - Moritz [1] http://forum.dlang.org/thread/fennfzjwzdlzcbtsj...@forum.dlang.org
llvm-d 2.1 - Support for LLVM 4.0.0
Thanks to foerdi as of the new release 2.1.0, llvm-d supports LLVM 4.0.0.
Re: Beta 2.074.0-b1
On Saturday, 25 March 2017 at 21:56:46 UTC, Jack Stouffer wrote: On Saturday, 25 March 2017 at 21:35:16 UTC, Moritz Maxeiner wrote: On Saturday, 25 March 2017 at 15:56:41 UTC, Jack Stouffer wrote: Yes, it's still not stable so it will be there for the foreseeable future. For example, just three days ago we pulled in a big bug fix that also was a huge breaking change . Could you please provide a link for that? I've glanced over [1] and wasn't able to identify it easily. [1] https://github.com/dlang/phobos/pulls?q=is%3Apr+is%3Aclosed https://github.com/dlang/phobos/pull/5274 Thanks.
Re: Beta 2.074.0-b1
On Saturday, 25 March 2017 at 15:56:41 UTC, Jack Stouffer wrote: Yes, it's still not stable so it will be there for the foreseeable future. For example, just three days ago we pulled in a big bug fix that also was a huge breaking change . Could you please provide a link for that? I've glanced over [1] and wasn't able to identify it easily. [1] https://github.com/dlang/phobos/pulls?q=is%3Apr+is%3Aclosed
Re: DConf 2017 Schedule
On Tuesday, 14 March 2017 at 16:12:56 UTC, Mike Parker wrote: Fresh from the D Foundation HQ, the DConf 2017 schedule [1] is now available for your perusal. If you haven't registered yet, you have just over five weeks to get it done. The registration deadline has been set for April 23, so don't procrastinate. Even better, head over to the registration page [2] and do it now! [1] http://dconf.org/2017/schedule/ [2] http://dconf.org/2017/registration.html Thanks, looks like lots of interesting talks! One thing though: Day 3: Saturday May 6, 2017 Day 4: Saturday May 7, 2017
Re: Typed D allocator based on jemalloc
On Friday, 3 March 2017 at 12:00:05 UTC, Basile B. wrote: Nothing huge here. The package[0] provides the bindings, JEMallocator (like Mallocator) and JEAlignedAllocator (like AlignedAllocator). All of them use jeallocator[1], which is actually the default implementation of malloc in the FreeBSD system. In a future update I may add another D alloc which would be specific to each thread. Another allocator, tcmallocd[2] already does this. [0] http://code.dlang.org/packages/jemallocd [1] https://github.com/jemalloc/jemalloc [2] http://code.dlang.org/packages/tcmallocd Neat. Stupid question, probably, but I don't really know much about jemalloc: Does using the binding yield me significant benefits over just using building blocks the way it's shown under "Sample Assembly" here[1]? [1] https://dlang.org/phobos/std_experimental_allocator_building_blocks.html
Re: Pegged v0.4: longest-match, left-recursion, and expandable parse trees
On Thursday, 2 March 2017 at 20:42:56 UTC, Philippe Sigaud wrote: Hi, Pegged is a parser generator based on Parsing Expression Grammars (PEG) written in D, that aims to be both simple to use and work at compile-time. See: https://github.com/PhilippeSigaud/Pegged [...] Thank you very much for Pegged, if I end up choosing D for the implementation part of my master thesis, Pegged will be very helpful to me.
expat-d 0.1.0
The package[1] is a binding to the Expat XML parser[2] with no high level wrappers, just plain C API. The initial release covers all of expat 2.2.0 and you need to link against the appropriate library yourself. The compile-time versions XML_UNICODE, XML_UNICODE_WCHAR_T, and XML_LARGE_SIZE correspond to the C defines by the same name; use them to match the binding to how expat has been compiled. Rationale as to why this package: I needed a fast, (time) tested XML stream parser to use for XMPP parsing and so far I found no current D package for that. [1] https://code.dlang.org/packages/expat-d [2] http://www.libexpat.org/
Re: DConf 2017 Early Bird Registration expires Monday!
On Sunday, 26 February 2017 at 01:03:39 UTC, Walter Bright wrote: On 2/25/2017 5:25 AM, Moritz Maxeiner wrote: Just registered and was returned to http://dconf.org/2017/thankyou.html afterwards, which yields a 404 error. Not sure if I should laugh or cry. Your registration is confirmed. See you there! Thank you for the confirmation. I'll see you there!
Re: DConf 2017 Early Bird Registration expires Monday!
On Saturday, 25 February 2017 at 07:02:48 UTC, Walter Bright wrote: http://dconf.org/2017/registration.html Don't forget, it goes up to $400 after Monday. Just registered and was returned to http://dconf.org/2017/thankyou.html afterwards, which yields a 404 error. Not sure if I should laugh or cry.
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko
wrote:
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
I use D only privately so far.
2. Does your company uses C/C++, Java, Scala, Go, Rust?
I've seen C, C++, and Java being used.
3. If yes, what the reasons to do not use D instead?
Nobody ever heard of the language (this holds true pretty much in
every discussion I have on the topic)
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
No.
3. If Yes, can Mir community use your company's logo in a
section "Used by" or similar.
N/A
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
I've used asdf for configuration files[1][2], it works very well
for shortening development time.
5. What D misses to be commercially successful languages?
My two cents:
- "Name" backing by a well-known (i.e. internationally famous)
corporation/foundation
- Viral marketing ("spread the D")
- Fix or removal of all the little things that may make someone
go "ugh, wtf?". I'm looking at you, `shared`, and your missing
memory barriers[5], or you, `std.parallelism.taskPool`, and your
non-daemon "daemon" threads[6]. Privately I can work around them
since it's my own time, but I don't expect many people in big
companies (see first point) with a deadline to want to put up
with that.
- Tooling, though that's been getting better
- Phobos without GC (where possible)
- std.experimental.allocator -> std.allocator and promote it as
*the* memory management interface for D. Seriously. With it I can
even allocate and pass delegates to C in an intuitive way (see
[3] and [4]).
6. Why many topnotch system projects use C programming language
nowadays?
Don't know if the premise holds, but if it does I'd wager it's
because people who *do* write topnotch (system) software can do
so in *any* (system) language that's asked of them - since in the
end the topnotch comes from the person writing the code, not the
language ("ignorance (of a language) can be remedied, stupid is
forever") - and C has the de facto corporate monopoly of being
asked to write in.
[1] https://git.ucworks.org/UCWorks/dagobar/tree/master
[2] https://git.ucworks.org/UCWorks/tunneled/tree/master
[3]
https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L125
[4]
https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L159
[5] https://dlang.org/faq.html#shared_guarantees
[6] https://issues.dlang.org/show_bug.cgi?id=16324
llvm-d 2.0
New major release of `llvm-d` with some backwards-incompatible API changes, please read the release message for the details. Cliffnotes: - Just `import llvm` - Remove `LLVM.load`, (dynamically) link against the appropriate library/libraries - Set a D version `LLVM_Target_XyZ' for every LLVM target 'XyZ' you need. https://github.com/Calrama/llvm-d/releases/v2.0.0 https://code.dlang.org/packages/llvm-d/2.0.0 - Moritz
Re: DConf 2016 news: 20% sold out, book signing
On Monday, 7 December 2015 at 17:39:14 UTC, Andrei Alexandrescu wrote: We're over 20% full and seats are going fast! We planned to send an announcement when we're 50% sold out. However, this time around registrations are coming quite a bit quicker than before so we thought we'd keep you posted earlier. [...] A fellow student and me just booked. Looking forward to it quite a bit :) calrama
