Re: how to pass -pie flag to dmd(or rdmd or ldc) ?
On 2017-01-26 04:43, Timothee Cour via Digitalmars-d wrote: Can we do this is 1 step? ``` rdmd -offoo.o -c foo.d g++ -o foo foo.o -pie -Wl,--export-dynamic ``` Ideally something like this would be great: ``` rdmd -offoo -extra_flags=-pie foo.d ``` where -extra_flags=flag1,flag2 can takes comma separated options Yeah, I've always wanted to be able to pass flags to the C compiler and not just the linker. -- /Jacob Carlborg
Re: Ddoc specification needed
On 2017-01-25 20:07, Ali Çehreli wrote: What do I need to know to have complete control of the situation? To have _complete_ control you need to redefine all the predefined macros, even if they're exactly the same as the predefined version. Otherwise this can happened at any time again. Fortunately the predefined macros are now in a separate file [1], making it much easier to extract the predefined macros. [1] https://github.com/dlang/dmd/blob/master/res/default_ddoc_theme.ddoc -- /Jacob Carlborg
Re: CTFE Status
On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
newCTFE is green now on all platforms!
I just found an interesting bug just now.
The following code would cause newCTFE to segfault.
char* initPtr()
{
return cast(char*) size_t.max;
}
static assert(cast(size_t)initPtr() == size_t.max);
Because it would try to return the char-value at heap-address
size_t.max;
newCTFE allocates a 16MB heap by default and therefore the
address was hopelessly out-of-bounds.
The reason this was not detected before is because:
`cast(char*) size_t.max;`
does not actually produce a cast expression.
But rather an IntegerLiteral with the type char*.
After dealing with dmd for 7 months, I could figure out this bug
in a day.
If I had run into this earlier I would have been stuck for weeks
:)
Re: Allow static methods and fields for enum?
26.01.2017 09:32, Profile Anaysis пишет: Why not make enum a comparable type to structs and classes? They are static so they can't contain any mutable fields but surely they can contain methods? And especially they should be able to contain static methods!? What prevents you from using UFCS with enum members or templates with enum itself? (not tested)
Allow static methods and fields for enum?
Why not make enum a comparable type to structs and classes? They are static so they can't contain any mutable fields but surely they can contain methods? And especially they should be able to contain static methods!?
how to pass -pie flag to dmd(or rdmd or ldc) ?
Can we do this is 1 step? ``` rdmd -offoo.o -c foo.d g++ -o foo foo.o -pie -Wl,--export-dynamic ``` Ideally something like this would be great: ``` rdmd -offoo -extra_flags=-pie foo.d ``` where -extra_flags=flag1,flag2 can takes comma separated options
Re: A mini D book: Markdown or LaTeX?
On 1/24/2017 6:27 AM, aberba wrote: Which one works well? I'm more concerned about syntax highlighting and line numbering (in some cases). Support for custom fonts. I've used Ddoc to publish a couple of Kindle books.
A better way to deal with overloading?
Many times we pass compound types(non-primitives) as arguments to functions. e.g., void foo(T1 t1, T2 t2, T3, t3); But to call foo with new variables we have to create the arguments. This usually requires extra code to simply initialize the variables. (imagine foo being a constructor). It may be better to use a recursive process where we can specify all the values of the arguments inline. e.g., foo(|a,b,c|,|e|,|f,g,c|). (I am using | but any type of symbolic notation could be used) would be equivalent to foo(T1(a,b,c),T2(e),T3(f,g,c)). When the T's are structs(other wise maybe new, or we can imply new for classes to make it uniform). If T1 has a compound type for the 3rd parameter, we can then call it like foo(|a,b,|c1,c2,3||,|e|,|f,g,c|). this avoids having to do things like auto t1 = T1(a,b,new X(c1,c2,c3)); auto t2 = T2(e); auto t3 = T3(f,g,c); and then f(t1,t2,t3); or other wise simply inline the above. This also cuts down on constructor overloading. This is sort of liked named parameters but the idea is that the compiler simply constructs the type internally as it knows what type to expect and the grouping symbols allow one to specify the contents unambiguously.
Re: foreach over pointers OR foreach that mutates the iterator
On Wednesday, January 25, 2017 16:15:49 Las via Digitalmars-d wrote:
> So the reference says that (when range has the properties)
> `foreach (e; range) { ... }` is equivalent to:
> for (auto __r = range; !__r.empty; __r.popFront())
> {
> auto e = __r.front;
> ...
> }
>
> Though this isn't always true, as when I use this struct:
> struct S {
> int front = 10;
> void popFront() {
> --front;
> }
> @property bool empty() {
> return front == 0;
> }
> }
>
> then I can do this:
> void main() {
> S s;
> auto p = &s;
> p.popFront;
> writeln(p.front);
> }
>
> But not this:
> void main() {
> S s;
> auto p = &s;
> foreach(i; p)
> writeln(i);
> }
>
> x.d(18): Error: invalid foreach aggregate p
> Failed: ["dmd", "-v", "-c",
> "-of/tmp/.rdmd-1000/rdmd-x.d-032B33C4A922C519594F67AF08DBF6C9/objs/x.o",
> "x.d", "-I."]
Given that
static assert(isInputRange!(typeof(&s)));
compiles, the fact that the second foreach doesn't work is arguably a bug.
> Related:
> UFCS does not work on pointers, which matters because of
> std.range.primitives.
It only matters if you're trying to define the range primitives for your
range as free functions for some reason. Just put them on the type itself
and be done with it. The only reason that wouldn't work would be if you
weren't in control of the code for the type in question, and I'm inclined to
think that turning a type that isn't a range into a range using free
functions isn't the best of ideas. You can always wrap the type in another
type though if you really want to turn it into a range and can't just
because you're dealing with a pointer.
- Jonathan M Davis
Re: A safer File.readln
On 01/25/2017 02:12 PM, Jens Mueller wrote: On Wednesday, 25 January 2017 at 14:18:15 UTC, Andrei Alexandrescu wrote: On 01/25/2017 12:58 AM, TheGag96 wrote: On Monday, 23 January 2017 at 13:18:57 UTC, Andrei Alexandrescu wrote: On 1/23/17 5:44 AM, Shachar Shemesh wrote: If, instead of increasing its size by 100%, we increase it by a smaller percentage of its previous size, we still maintain the amortized O(1) cost (with a multiplier that might be a little higher, but see the trade off). On the other hand, we can now reuse memory. Heh, I have a talk about it. The limit is the golden cut, 1.6180339887498948482... The proof is fun. Anything larger prevents you from reusing previously used space. -- Andrei Andrei, could you link this talk? Thanks! Not public. -- Andrei Have you done measurements on the matter? Affirmative. Because I'm not sold on the idea. Wasn't selling anything. To me at this point this is just a theoretical observation. No. There are also arguments indicating it is less useful. That is correct. Any numbers on how it affects e.g. memory usage? Depends on the application. You'd do good to collect your own. Andrei
Re: A mini D book: Markdown or LaTeX?
On Wed, 25 Jan 2017 11:58:45 +, Chris wrote: > On Tuesday, 24 January 2017 at 14:27:15 UTC, aberba wrote: >> Which one works well? I'm more concerned about syntax highlighting and >> line numbering (in some cases). Support for custom fonts. > > I know people who write articles and their Ph.D. > thesis in LaTeX to get maximum control over the layout (to avoid > Word-like surprises). If you are submitting a paper to an academic journal, they will tell you what format they expect. If you sent a paper as a Word document when they require LaTeX, they will reject it with a note telling you to use LaTeX instead. Conversely, if they expect Word documents, they will reject anything in LaTeX. As a PhD student, your advisor will tell you what format to use. This will almost certainly match the most commonly used file format for journal submissions in your field. Regardless, you want *consistency* more than control. If you submit to a CS journal, they will often give you a .sty file -- this sets up page layout and the like, taking control away from the writer of the article. If you submit to a humanities journal, they might have a Word document template. They might also simply give style requirements that you must obey. > The downside is the source code. > It's not very nice to read and you get lost easily. And try to get back > after a year and change something! It's like C++. If you use the same restricted subset that you understand concretely, you shouldn't have a bad time. If you use a different set of packages and macros every document, you're in for a world of hurt. > Also, you have to convert it to PDF > each time you wanna (proof)read it, so you usually deal with two layouts > at the same time (source code and PDF/HTML), which is time consuming and > error prone. It separates the writing / editing process from the proofing process and gives you a significantly different format for proofing. This is helpful for catching errors. I wouldn't use htlatex. Instead of a simple or tag, it produces type things. Which is okay if you just want to throw it up online, but if you want to produce an ebook with maximum compatibility, simpler HTML is better. > A lot of publishers will prefer Word, because they can easily edit it > and if they have their own layout section, they will transform Word to > txt and paste it into say Adobe InDesign. Change tracking and commenting are the huge things publishers use Word for. > I for my part have stopped worrying about it too much. Just write the > text (in Word or an Ascii editor) If it's a few pages, it's painful and error-prone to retro-add formatting once you finished the content. If it's a hundred pages, you might need to spend several weeks to format it. That doesn't seem like a good tradeoff to me.
Re: Ddoc specification needed
On 01/25/2017 11:07 AM, Ali Çehreli wrote: A change in one of the recent compilers broke my use of Ddoc because code sections that are separated by --- now have new XML tags like which my current CSS is unaware of. What do I need to know to have complete control of the situation? Ok, the output of 'strings dmd' shows me the following: D_CODE = $0 Instead of the documented D_CODE = $0 Opened issue: https://issues.dlang.org/show_bug.cgi?id=17121 Ali
Re: A safer File.readln
On Wednesday, 25 January 2017 at 14:18:15 UTC, Andrei Alexandrescu wrote: On 01/25/2017 12:58 AM, TheGag96 wrote: On Monday, 23 January 2017 at 13:18:57 UTC, Andrei Alexandrescu wrote: On 1/23/17 5:44 AM, Shachar Shemesh wrote: If, instead of increasing its size by 100%, we increase it by a smaller percentage of its previous size, we still maintain the amortized O(1) cost (with a multiplier that might be a little higher, but see the trade off). On the other hand, we can now reuse memory. Heh, I have a talk about it. The limit is the golden cut, 1.6180339887498948482... The proof is fun. Anything larger prevents you from reusing previously used space. -- Andrei Andrei, could you link this talk? Thanks! Not public. -- Andrei Have you done measurements on the matter? Because I'm not sold on the idea. To me at this point this is just a theoretical observation. There are also arguments indicating it is less useful. Any numbers on how it affects e.g. memory usage? Jens
Ddoc specification needed
A change in one of the recent compilers broke my use of Ddoc because code sections that are separated by --- now have new XML tags like which my current CSS is unaware of. What do I need to know to have complete control of the situation? Ali
librtlsdr and D
Has anyone tried using librtlsdr from D? Asking for a frie^H^H^H^H^H^Hmyself. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: @safe containers with std.experimental.allocator
On Tuesday, 24 January 2017 at 19:38:31 UTC, bitwise wrote: I would, but I'm not sure I can use these allocators. Ran into this: http://forum.dlang.org/post/akohcwiotlcrodemh...@forum.dlang.org As stated in that thread, I can mark the member instance of the allocator in the container as 'shared', but then, if I use an allocator _without_ 'shared' methods, I get errors as well. I'm not sure if there is a solution for this, but at this point, I try to just avoid 'shared' at all costs. The fact that Mallocator is thread safe should not stop me from using it in a non-thread safe class, but it does. So I guess there is no solution for this? I've written my own allocators at this point, which is not something I did with great joy.
Re: A mini D book: Markdown or LaTeX?
On Wednesday, 25 January 2017 at 16:29:18 UTC, bachmeier wrote: On Wednesday, 25 January 2017 at 14:51:58 UTC, Chris wrote: Nice. How does "bookdown" or any other extension fare regarding fine grained layout control à la LaTeX? It is a layer on top of Pandoc with useful extensions for creating books. Pandoc allows you to add arbitrary LaTeX code to the document, so AFAIK, you should be able to do anything you can do with LaTeX. Most of that would be handled with modifications to the .latex template or with a yaml section at the top of the document. The best of both worlds, in other words.
Re: CTFE Status
On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote: newCTFE is green now on all platforms! Great!
Re: A mini D book: Markdown or LaTeX?
On Wednesday, 25 January 2017 at 14:51:58 UTC, Chris wrote: On Wednesday, 25 January 2017 at 14:37:31 UTC, bachmeier wrote: I see. You were referring to the original Markdown specification, which does not have those features. There are many extensions, though, like https://bookdown.org/ Nice. How does "bookdown" or any other extension fare regarding fine grained layout control à la LaTeX? It is a layer on top of Pandoc with useful extensions for creating books. Pandoc allows you to add arbitrary LaTeX code to the document, so AFAIK, you should be able to do anything you can do with LaTeX. Most of that would be handled with modifications to the .latex template or with a yaml section at the top of the document.
foreach over pointers OR foreach that mutates the iterator
So the reference says that (when range has the properties)
`foreach (e; range) { ... }` is equivalent to:
for (auto __r = range; !__r.empty; __r.popFront())
{
auto e = __r.front;
...
}
Though this isn't always true, as when I use this struct:
struct S {
int front = 10;
void popFront() {
--front;
}
@property bool empty() {
return front == 0;
}
}
then I can do this:
void main() {
S s;
auto p = &s;
p.popFront;
writeln(p.front);
}
But not this:
void main() {
S s;
auto p = &s;
foreach(i; p)
writeln(i);
}
x.d(18): Error: invalid foreach aggregate p
Failed: ["dmd", "-v", "-c",
"-of/tmp/.rdmd-1000/rdmd-x.d-032B33C4A922C519594F67AF08DBF6C9/objs/x.o", "x.d", "-I."]
Why should this work? Because some times I want foreach to modify
the iterator, because some times I like to have an inner foreach
that uses the same iterator as the outer one, to effectively
still iterate over the same range, but change the contents of the
loop.
Bad example:
foreach(i; &range) {
writeln(i);
if(i > 2) foreach(i; &range) {
writeln(i * 3);
if(i < 10)
break;
}
}
This loop would change behavior each time one of the 'if's pass.
An alternative would be to implement a new foreach, perhaps
&foreach, that does this instead:
for (/+ NB: We are not copying the range! +/; !range.empty;
range.popFront())
{
auto e = range.front;
...
}
Related:
UFCS does not work on pointers, which matters because of
std.range.primitives.
Thoughts?
Re: CTFE Status
On Wednesday, 25 January 2017 at 15:26:39 UTC, jmh530 wrote: On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote: newCTFE is green now on all platforms! Congrats. How much work remains? Quite a lot. - Slicing - Appending - || - String support (implying utf conversions) - Floating-Point - classes - exceptions - function pointers - closures and proper handling of more complex types such as arrays of structures
Re: CTFE Status
On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote: newCTFE is green now on all platforms! Congrats. How much work remains?
Re: A mini D book: Markdown or LaTeX?
On Wednesday, 25 January 2017 at 14:37:31 UTC, bachmeier wrote: I see. You were referring to the original Markdown specification, which does not have those features. There are many extensions, though, like https://bookdown.org/ Nice. How does "bookdown" or any other extension fare regarding fine grained layout control à la LaTeX?
Re: A mini D book: Markdown or LaTeX?
On Wednesday, 25 January 2017 at 11:01:14 UTC, Russel Winder wrote: On Tue, 2017-01-24 at 16:38 +, bachmeier via Digitalmars-d wrote: On Tuesday, 24 January 2017 at 15:02:26 UTC, Russel Winder wrote: > I wouldn't use Markdown for such a project. Is there a reason? Unless life has changed, the support for indexing, tables of contents, floating images, tables, etc. is missing from Markdown. I see. You were referring to the original Markdown specification, which does not have those features. There are many extensions, though, like https://bookdown.org/
Re: A safer File.readln
On 01/25/2017 12:58 AM, TheGag96 wrote: On Monday, 23 January 2017 at 13:18:57 UTC, Andrei Alexandrescu wrote: On 1/23/17 5:44 AM, Shachar Shemesh wrote: If, instead of increasing its size by 100%, we increase it by a smaller percentage of its previous size, we still maintain the amortized O(1) cost (with a multiplier that might be a little higher, but see the trade off). On the other hand, we can now reuse memory. Heh, I have a talk about it. The limit is the golden cut, 1.6180339887498948482... The proof is fun. Anything larger prevents you from reusing previously used space. -- Andrei Andrei, could you link this talk? Thanks! Not public. -- Andrei
Re: CTFE Status
On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote: newCTFE is green now on all platforms! <3
Re: CTFE Status
newCTFE is green now on all platforms!
Re: A mini D book: Markdown or LaTeX?
On Wednesday, 25 January 2017 at 11:01:14 UTC, Russel Winder wrote: Or put another way Markdown is a stripped down Asciidoctor (or ReStructuredText) for creating single HTML pages with no complicated content. There are packages out there that can get generate some decent looking output, like Gitbook and Mkdocs. Scrivener also has Markdown support and can compile it to all of its normal output targets (epub, mobi, pdf, html, etc..).
Re: A mini D book: Markdown or LaTeX?
On Tuesday, 24 January 2017 at 14:27:15 UTC, aberba wrote: Which one works well? I'm more concerned about syntax highlighting and line numbering (in some cases). Support for custom fonts. Depends on what you want to achieve. LaTeX has loads of packages that can be installed and you can create professional looking layouts. It is quite impressive. I know people who write articles and their Ph.D. thesis in LaTeX to get maximum control over the layout (to avoid Word-like surprises). LaTeX is accepted by many publishers, printers etc., especially in the tech sector. The downside is the source code. It's not very nice to read and you get lost easily. And try to get back after a year and change something! Also, you have to convert it to PDF each time you wanna (proof)read it, so you usually deal with two layouts at the same time (source code and PDF/HTML), which is time consuming and error prone. From what I can see, Markdown is much nicer to read and you don't need to switch between source code and layout all the time, but it is rather limited in comparison to LaTeX. You wouldn't have the fine grained control over the layout and you would most likely have to convert it to something else before you can send it to a publisher / printer. They don't want to waste time with exotic or lesser known formats, because they have their own infrastructure set up, which leads me to the next point. A lot of publishers will prefer Word, because they can easily edit it and if they have their own layout section, they will transform Word to txt and paste it into say Adobe InDesign. So if you want to publish privately on your homepage or blog, pick whatever you want. If you want to publish on one of those self-publishing websites, check what they support. If you want the old fashioned publisher ask them first what format they want. Believe me, you can safe a lot of time. Imagine you create the perfect layout with LaTeX and then the publisher goes "Thanks, er, can you please send it to me as a Word doc?" I for my part have stopped worrying about it too much. Just write the text (in Word or an Ascii editor) and think about the layout later. It helps you to focus on the content rather than on the optical structure - and if you have to change, add, delete or re-arrange things, it won't cause you any headaches. Write first, design later.
Re: A mini D book: Markdown or LaTeX?
On Wednesday, 25 January 2017 at 10:57:41 UTC, Russel Winder wrote: Asciidoc (and it's continuation Asciidoctor) was invented to be a human usable front end to the DocBook/XML toolchain – and it still works for this. Humans should not have to write XML. Hence Asciidoctor. I might look into Asciidoc at some point then. There are decent grammar-directed XML editors out there, and plain XML is ok too in my opinion. As you mentioned OpenOffice also has some support for docbook filters. Another option is to do your own XML based off HTML5 if HTML is a primary target.
Re: A mini D book: Markdown or LaTeX?
On Tue, 2017-01-24 at 19:34 +, qznc via Digitalmars-d wrote: > On Tuesday, 24 January 2017 at 14:27:15 UTC, aberba wrote: > > Which one works well? I'm more concerned about syntax > > highlighting and line numbering (in some cases). Support for > > custom fonts. > > I used Sphinx here: https://qznc.github.io/d-tut/ > > The syntax "ReStructured Text" is more ugly than Markdown, but > has more features (e.g. different kinds of blocks). Sphinx can > generate HTML, LaTeX, EPub, and more. > > http://www.sphinx-doc.org/ ReStructuredText and Sphinx is used in many places, but much of it is ugly, particularly compared to Asciidoctor (which has it's own warts) and XeLaTeX (which also has some). In the end it all gets tribal, and is down to personal taste. I am sad for the demise of FrameMaker on Solaris. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A mini D book: Markdown or LaTeX?
On Tue, 2017-01-24 at 16:38 +, bachmeier via Digitalmars-d wrote: > On Tuesday, 24 January 2017 at 15:02:26 UTC, Russel Winder wrote: > > > I wouldn't use Markdown for such a project. > > Is there a reason? Unless life has changed, the support for indexing, tables of contents, floating images, tables, etc. is missing from Markdown. > > Many people might choose Asciidoctor. > > When I looked at asciidoc, it looked like markdown with > extensions. Or put another way Markdown is a stripped down Asciidoctor (or ReStructuredText) for creating single HTML pages with no complicated content. Word (or if you are lucky LibreOffice) is the way most publishers want authors to write. XeLaTeX and Asciidoctor (as a front end to a DocBook/XML toolchain) are the route for end-user construction of press PDF. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A safer File.readln
On Sunday, 22 January 2017 at 21:29:39 UTC, Markus Laker wrote: Obviously, we wouldn't want to break compatibility with existing code by demanding a maximum line length at every call site. Perhaps the default maximum length should change from its current value -- infinity -- to something like 4MiB: longer than lines in most text files, but still affordably small on most modern machines. An issue I had with low default buffer limits: they are difficult to discover and usually start to fail only in production where you hit the actual big data, which gets only bigger with time. You find and bump one limit, deploy, only hit another later.
Re: A mini D book: Markdown or LaTeX?
On Wed, 2017-01-25 at 09:21 +, Ola Fosheim Grøstad via Digitalmars- d wrote: > On Tuesday, 24 January 2017 at 14:27:15 UTC, aberba wrote: > > Which one works well? I'm more concerned about syntax > > highlighting and line numbering (in some cases). Support for > > custom fonts. > > If you don't mind XML then you might consider http://docbook.org/ Asciidoc (and it's continuation Asciidoctor) was invented to be a human usable front end to the DocBook/XML toolchain – and it still works for this. Humans should not have to write XML. Hence Asciidoctor. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CTFE Status
On Tuesday, 24 January 2017 at 06:35:56 UTC, Stefan Koch wrote: The blacklisted functions are now down to only two. Those are the bitswap function in druntime. Because the interpreter does handle all values as 64bit internally it tends to miscompile code that uses xor on 32bit values. And the second one is the "to" template from std.conv; Because of the aforementioned UTF issues. NOTE: that the blacklist is by nature transitive meaning a function that calls a blacklisted function will also not be interpreted by newCTFE The blacklisting of bitswap was removed, because we now bailout on bit-level operations on 32bit values. However I did have to add a unittest-specific bailout for fail_compilation/fail14304.d which requires the ctfe interpeter to detect a semantically invalid situation that should have been detected before we ever begin ctfe.
Re: bdb2d and openSUSE
So, the problem: $ cc --version cc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064] Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cc .dub/build/OpenSUSE-debug-linux.posix-x86_64-dmd_2071-186D122990333E297AD7D4BDA72364C7/unde.o -o .dub/build/OpenSUSE-debug-linux.posix-x86_64-dmd_2071-186D122990333E297AD7D4BDA72364C7/unde -g -m64 -Xlinker --no-as-needed -L/usr/local/BerkeleyDB.5.3/lib64/ -lutil -ldb -ldl -L/usr/lib64 -Xlinker --export-dynamic ../../.dub/packages/bdb2d-5.3.28/bdb2d/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-9E956773380BE684D56F8F1619A72458/libdb.a ../../.dub/packages/derelict-ft-1.1.3/derelict-ft/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-C5461FBF3AF191B3583F388641667679/libDerelictFT.a ../../.dub/packages/derelict-sdl2-2.0.2/derelict-sdl2/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-211F2539A3F0A6356A2312EFBC7AF002/libDerelictSDL2.a ../../.dub/packages/derelict-util-2.0.6/derelict-util/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-DAD1CE5EB4AA073E02604396A45B67FE/libDerelictUtil.a -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm -lrt -ldl (with -ldb in the middle) doesn't work $ cc .dub/build/OpenSUSE-debug-linux.posix-x86_64-dmd_2071-186D122990333E297AD7D4BDA72364C7/unde.o -o .dub/build/OpenSUSE-debug-linux.posix-x86_64-dmd_2071-186D122990333E297AD7D4BDA72364C7/unde -g -m64 -Xlinker --no-as-needed -L/usr/local/BerkeleyDB.5.3/lib64/ -lutil -ldb -ldl -L/usr/lib64 -Xlinker --export-dynamic ../../.dub/packages/bdb2d-5.3.28/bdb2d/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-9E956773380BE684D56F8F1619A72458/libdb.a ../../.dub/packages/derelict-ft-1.1.3/derelict-ft/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-C5461FBF3AF191B3583F388641667679/libDerelictFT.a ../../.dub/packages/derelict-sdl2-2.0.2/derelict-sdl2/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-211F2539A3F0A6356A2312EFBC7AF002/libDerelictSDL2.a ../../.dub/packages/derelict-util-2.0.6/derelict-util/.dub/build/library-debug-linux.posix-x86_64-dmd_2071-DAD1CE5EB4AA073E02604396A45B67FE/libDerelictUtil.a -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm -lrt -ldl -ldb (with -ldb at the end) works
Re: A mini D book: Markdown or LaTeX?
On Tuesday, 24 January 2017 at 14:27:15 UTC, aberba wrote: Which one works well? I'm more concerned about syntax highlighting and line numbering (in some cases). Support for custom fonts. If you don't mind XML then you might consider http://docbook.org/
Re: Swift's plan for world domination
On Tuesday, 24 January 2017 at 20:13:21 UTC, Joakim wrote: Just finished listening to an interesting podcast with Chris Lattner, creator of Swift, about what went into the language, including mentioning D as one of its many influences, saying he wants it everywhere from linux servers to systems programming, and explaining their choice of ARC over GC. podcast - http://atp.fm/205 transcript - http://atp.fm/205-chris-lattner-interview-transcript Thanks for the transcript link. :-) I wonder if his work at Tesla involves turning Swift into a system programming language. I found the following quote interesting: «I think it's very likely that Swift will get features for memory-ownership control, which will allow really, really high performance: it will allow solving performance problems with ARC, for example. Unlike Rust, we can't make that be a core part of the type system that everybody has to use. It has to be something that sufficiently smart programmers, when they're solving a specific performance problem, end up using, or an embedded-kernel programmer might want to use, but an application developer can [1:09:30] completely ignore»
