Programming in D book, draft of the first print edition and eBook formats
Main page: http://ddili.org/ders/d.en/ 1) For the first time, there are eBook formats: http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.epub http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.mobi I used 'calibre' to generate those alpha quality books. I chose epub and mobi just because I thought that they are the most common formats. Just let me know if you need another format or simply use 'calibre' or another tool yourself. :) 2) There has been a lot of work to make the book ready for its first print edition. (I will spare you the details of countless hours of extra work that went into this eternal final step.) The PDF version finally looks a lot like a real book: * There is a Table of Contents section * There is an Index section * The internal links work 3) There are two new chapters: * Lvalues and Rvalues * Nested Functions, Structs, and Classes 4) There are the following notable additions to existing chapters: * 'pragma' is added to the Templates chapter * Special keywords are added to the Templates chapter (__FILE__, __LINE__, etc.) * Contract inheritance is added to the 'Contract Programming for Structs and Classes' chapter * The .offsetof property and the 'align' atribute are added to the 'Memory Management' chapter 5) I am grateful to Andrej Mitrović, Steven Schveighoffer, and Luís Marques, who accepted to edit the book. However, they are through only less than 10% of the book so far. As always, current or future mistakes are mine. :) Ali
Re: Programming in D book, draft of the first print edition and eBook formats
Awesome!
Re: Programming in D book, draft of the first print edition and eBook formats
Fantastic work.
Re: Programming in D book, draft of the first print edition and eBook formats
Thx, your book's just helped me last night (opSlice template not well explained in the official html). Two questions: - do you know that your website has serious design issue ? - does paper version mean no more free pdf/ebook ?
Re: Programming in D book, draft of the first print edition and eBook formats
This is HUGE! I've gone through many of your chapters, but it was just now, after seeing it as a one 700 pages long book, that I truly realized how much of a work this must have been. Thank you. Can't wait to have it on the shelf... Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: dfix 0.2.0
On Tuesday, 25 November 2014 at 23:58:21 UTC, Brian Schott wrote: On Tuesday, 25 November 2014 at 23:47:07 UTC, Nordlöw wrote: On Tuesday, 25 November 2014 at 23:45:17 UTC, Nordlöw wrote: I guess one solution would be to make warnings non-errors right but that seems dumb concerning what dfix can do for us regarding auto-converting C-style arrays syntax to D-style :) The issue trackers for dfix and libdparse are on github. BTW: How do I specify that a dependency package (libdparse) should be compiled with -wi instead of -w? You can read DUB's documentation here: http://code.dlang.org/package-format It would be nice if we could call DUB either as dub -wi or in a more generic way as dub --dmd-flags=wi,... so I don't have to clone the top-level project and modify its dub.json myself in order to test dfix built using dmd git master. Should I register an DUB issue for this?
Re: dfix 0.2.0
On Wednesday, 26 November 2014 at 13:11:28 UTC, Nordlöw wrote: It would be nice if we could call DUB either as dub -wi or in a more generic way as dub --dmd-flags=wi,... so I don't have to clone the top-level project and modify its dub.json myself in order to test dfix built using dmd git master. Should I register an DUB issue for this? Note that DFLAGS=-wi dub build -v doesn't work here either because -wi is prepended to -w which still results warnings as errors.
Re: Programming in D book, draft of the first print edition and eBook formats
On Wednesday, 26 November 2014 at 10:34:24 UTC, Ali Çehreli wrote: Main page: http://ddili.org/ders/d.en/ 1) For the first time, there are eBook formats: http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.epub http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.mobi I used 'calibre' to generate those alpha quality books. I chose epub and mobi just because I thought that they are the most common formats. Just let me know if you need another format or simply use 'calibre' or another tool yourself. :) 2) There has been a lot of work to make the book ready for its first print edition. (I will spare you the details of countless hours of extra work that went into this eternal final step.) The PDF version finally looks a lot like a real book: * There is a Table of Contents section * There is an Index section * The internal links work 3) There are two new chapters: * Lvalues and Rvalues * Nested Functions, Structs, and Classes 4) There are the following notable additions to existing chapters: * 'pragma' is added to the Templates chapter * Special keywords are added to the Templates chapter (__FILE__, __LINE__, etc.) * Contract inheritance is added to the 'Contract Programming for Structs and Classes' chapter * The .offsetof property and the 'align' atribute are added to the 'Memory Management' chapter 5) I am grateful to Andrej Mitrović, Steven Schveighoffer, and Luís Marques, who accepted to edit the book. However, they are through only less than 10% of the book so far. As always, current or future mistakes are mine. :) Ali Well done, Ali - I will buy the ePub once the book is done. One suggestion: if you can, do what Ivan Ristic does with his SSL/TLS books (https://www.feistyduck.com). Basically, people who buy his books have unlimited access to book updates. Ivan is sending information about book updates whenever there is something new, so we readers can go back to the website and grab the latest version of the book. I think this is a much better approach than book editions, as they may appear years after each other... Sure, it is more complicated, but I think it pays off, and I do not mind book being little bit more expensive if I can access updated version of it. Cheers!
Re: Programming in D book, draft of the first print edition and eBook formats
One more thing - if you have the book in some wiki form, it may be a good idea to transform it into AsciiDoc as it has really nice ePub/PDF/HTML output.
Re: Programming in D book, draft of the first print edition and eBook formats
On 11/26/14 2:34 AM, Ali Çehreli wrote: Main page: http://ddili.org/ders/d.en/ 1) For the first time, there are eBook formats: http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.epub http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.mobi Fantastic! I wanted to mention this on reddit but noticed that (a) http://ddili.org/ders/d.en/ has the left menu in Turkish, and (b) there are no links to the ebooks from that page. Could you please fix that? Thanks, Andrei
Re: Programming in D book, draft of the first print edition and eBook formats
On 11/26/2014 03:42 AM, Anonymous wrote: - do you know that your website has serious design issue ? Of course. :( - does paper version mean no more free pdf/ebook ? My current thinking is that all of the ebook formats should be free but also purchasable. A distributor like Smashwords would reach more readers. However, a person who is interested in D would find the book on my site anyway. (I wonder whether Smashwords would allow me to also provide the book for free on my site?) For the print version, I am thinking about Amazon's CreateSpace mainly because unlike Lulu and many other self-publishing houses they accept more than 440 pages. Ali
Re: Programming in D book, draft of the first print edition and eBook formats
On 11/26/2014 06:27 AM, Dejan Lekic wrote: whenever there is something new, so we readers can go back to the website and grab the latest version of the book. That has always been the case with Programming in D. Although there has been a hiatus of about two months this last time, Luís Marques' edits from this morning have already made it to the site as we speak. ;) I think this is a much better approach than book editions, as they may appear years after each other... Sure, it is more complicated, but I think it pays off It is not complicated at all. I type 'make', copy the generated .zip file to the hosting site, unzip, and the edits are live! :) (Although, the .epub and .mobi formats are not integrated to the Makefile yet.) On 11/26/2014 08:55 AM, Dejan Lekic wrote: One more thing - if you have the book in some wiki form, it may be a good idea to transform it into AsciiDoc as it has really nice ePub/PDF/HTML output. For historical reasons I started with Ddoc. I can investigate converting it to AsciiDoc but honestly I am not motivated much to do that. :) Currently, Ddoc is first converted to HTML and I use the HTML to generate different final formats. Ali
Re: Programming in D book, draft of the first print edition and eBook formats
On 11/26/2014 09:24 AM, Andrei Alexandrescu wrote: I wanted to mention this on reddit That site is fine. but noticed that (a) http://ddili.org/ders/d.en/ has the left menu in Turkish That site sucks! :) and (b) there are no links to the ebooks from that page. I intentionally did not link the alpha-quality stuff. Pictures are missing, chapter numbers vary between -1 and 2, etc. :p Let me deal with it after I eat some Thanksgiving turkey tomorrow. Speaking of which, thank you everybody! :) Ali
Re: Programming in D book, draft of the first print edition and eBook formats
Congrats on (nearly) finishing your book. It's one of the best D resources available and very high quality.
Re: Programming in D book, draft of the first print edition and eBook formats
On Wednesday, 26 November 2014 at 10:34:24 UTC, Ali Çehreli wrote: Main page: http://ddili.org/ders/d.en/ 1) For the first time, there are eBook formats: http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.epub http://ddili.org/ders/d.en/Programming_in_D_Ali_Cehreli.ALPHA.mobi I used 'calibre' to generate those alpha quality books. I chose epub and mobi just because I thought that they are the most common formats. Just let me know if you need another format or simply use 'calibre' or another tool yourself. :) 2) There has been a lot of work to make the book ready for its first print edition. (I will spare you the details of countless hours of extra work that went into this eternal final step.) The PDF version finally looks a lot like a real book: * There is a Table of Contents section * There is an Index section * The internal links work 3) There are two new chapters: * Lvalues and Rvalues * Nested Functions, Structs, and Classes 4) There are the following notable additions to existing chapters: * 'pragma' is added to the Templates chapter * Special keywords are added to the Templates chapter (__FILE__, __LINE__, etc.) * Contract inheritance is added to the 'Contract Programming for Structs and Classes' chapter * The .offsetof property and the 'align' atribute are added to the 'Memory Management' chapter 5) I am grateful to Andrej Mitrović, Steven Schveighoffer, and Luís Marques, who accepted to edit the book. However, they are through only less than 10% of the book so far. As always, current or future mistakes are mine. :) Ali This is great news. I'm excited to have more than TDPL sitting on my shelf.
Re: D/Objective-C 64bit
Why not use a constructor and let the compiler manage the
boilerplate?
this(NSRect frame) [initWithFrame:] {
//my stuff
super(frame);
}
This should emit the same code as the function above (but I
haven't tested). And then you can write:
auto view = new KeyboardView(someFrame);
and have proper type safety.
Thanks Michel, my question was based on a completely wrong
assumption (really sorry, my bad), the code of course works,
which is again really cool about the D/Objective-C bridging.
When I prepare the framework glue headers I usually add both
variations init.. and this(), so the coder who uses it can take
the shortcut if he prefers. I try to stay as close as possible to
the naming conventions of the Cocoa framework, it facilitates
somewhat the documentation lookup in Xcode. Named parameters is
probably the feature I like most about Objective-C, it makes the
code so much more readable and auto-documents, if one is careful.
Re: Programming in D book, draft of the first print edition and eBook formats
On 11/26/2014 11:35 AM, Ali Çehreli wrote: I wonder whether Smashwords would allow me to also provide the book for free on my site? Found the answer to that question: 6c. Free Copies. As administrator of your work, Author may use the Smashwords platform to distribute complimentary copies of the work, or personally email free files to people, even when you are generally charging a fee. However, Smashwords files cannot be mass-distributed via download at blogs, websites or other retailers outside the Smashwords network. https://www.smashwords.com/about/tos Ali
Necht Hob
Necht hob was fitted many years ago and still works perfect. _ [url=http://www.nechtgashob.co.uk]Necht Hob[/url]
Re: Programming in D book, draft of the first print edition and eBook formats
On Wednesday, 26 November 2014 at 23:16:11 UTC, Ali Çehreli wrote: On 11/26/2014 11:35 AM, Ali Çehreli wrote: I wonder whether Smashwords would allow me to also provide the book for free on my site? Found the answer to that question: 6c. Free Copies. As administrator of your work, Author may use the Smashwords platform to distribute complimentary copies of the work, or personally email free files to people, even when you are generally charging a fee. However, Smashwords files cannot be mass-distributed via download at blogs, websites or other retailers outside the Smashwords network. https://www.smashwords.com/about/tos I think you are misinterpreting that clause. I had never heard of Smashwords before, so I just looked at their site and their TOS. What they do is take your book in doc format and generate ebook formats that can be sold online and to other book retailers, as detailed in clause 5 of their TOS: 5. Formats of Digital Conversions. Author shall submit their Work as a Microsoft Word .doc file. Smashwords shall utilize its proprietary Meatgrinder technology to convert the book into multiple ebook formats, and publish the work for use in sampling, distributing and selling the work. The author/publisher is not authorized to independently sell or distribute Smashwords-generated file conversions outside of the Smashwords site or Smashwords distribution network without first receiving written permission from Smashwords (in other words, you cannot use Smashwords as a free file conversion service so you can sell the files elsewhere). You acknowledge that if you violate this requirement, you may forfeit any accrued earnings at Smashwords, and your account may be deleted without notification. I believe both clauses simply says you cannot distribute their converted ebook files: note that 6c says you cannot mass distribute Smashwords files, not the Work, which is how they refer to your book itself. They also say on their site that you are free to use other distributors and retain copyright over your work. Few would fault you for not wanting to give away free copies if you're selling the book, but I don't think Smashwords has a say in the matter.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
when I migrate dfl codes from x86 to 64 bit,modify the drawing.d ,find the 'offset' and 'index',point(x,y),rect(x,y),all be keep with the 'lengh's type, so I don't modify them to size_t,only cast(int)length to int,then it's easy to migrate dfl codes to 64 bit. Ok,then dfl can work on 64 bit now.
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 23:41:51 UTC, Walter Bright wrote: On 11/25/2014 2:26 AM, Robert burner Schadek wrote: On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You mean the second part, about him leaving D because of the discussion about the logger? Yes. Not really, this is the first time I read the name SiCl4. Also google SiCl4 dlang only points to the reddit post.
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 23:41:51 UTC, Walter Bright wrote: On 11/25/2014 2:26 AM, Robert burner Schadek wrote: On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You mean the second part, about him leaving D because of the discussion about the logger? Yes. He wants a better C for system level programming: https://www.reddit.com/r/programming/comments/2n60wv/the_first_enemy_of_c_is_its_past/cmbn1n4 https://www.reddit.com/r/programming/comments/2n60wv/the_first_enemy_of_c_is_its_past/cmb4ows And there is no doubt an open spot between C and C++ for a modernized system level language.
Re: Does RTTI and exceptions work in dlls on windows?
On Wednesday, 26 November 2014 at 07:46:12 UTC, Benjamin Thaut wrote: Am 25.11.2014 21:46, schrieb MrSmith: Is there a bugzilla issue for this? And what is the status of windows dlls? If you want a bit more dll support right now, I suggest that you take a look at these changes and merge them into your own version of druntime: https://github.com/Ingrater/druntime/commit/7e54eac91dd34810913cfe740e709b18cbbc00d6 Kind Regards Benjamin Thaut Thank you very much!
Re: Named parameter builder pattern for template parameters
On Friday, 21 November 2014 at 13:39:43 UTC, monarch_dodra wrote: I trust everyone here knows about the builder pattern (http://en.wikipedia.org/wiki/Builder_pattern)? It can be very useful when the number of (optional) arguments in a function start to run rampant, and you know the user only wants to start setting a subset of these. D has phenomenal meta programming possibilities, and I see more and more templates taking more and more parameters. So I thought to myself, why not have a template builder pattern? I was able to throw this together: http://dpaste.dzfl.pl/366d1fc22c9c Which allows things like: alias MyContainerType = ContainerBuilder!int //.setUseGC!??? //Don't care about GCm use default. .setScan!false .setUSomeOtherThing!true .Type; I think this is hugely neat. I'm posting here both to share, and for peer review feedback. I'm also wondering if there is prior literature about this, and if it's something we'd want more of in Phobos? If D would support getting parameter names(currently does not work for lambdas) of lambdas we could have: someConnect(host = test, port = 7999); Just a random thought :)
[OT] unbelievable: #ifdef _OTHER_LIB_H
So my computer died on me again last week and I had to buy new hardware. I was forced to update the software to run the new hardware... and it is painful. I hate all software and have learned that if I want a job done right, I have to do it myself. Rarely, I find other people's software is OK with some slight modifications, so I try to do that. xterm is one example. I basically like it but it is ugly and stupid so needs a few fixes. As such, I maintain my own private fork of it. I went ahead and compiled that on the new thing today and it failed. wait what?! #ifndef _XLIB_H_ #error Please include X11/Xlib.h before xutf8.h #endif That's in the xterm source code. Yes, it depends on the presence of a particular include guard. The X11 source apparently recently changed to: #ifndef _X11_XLIB_H_ #define _X11_XLIB_H_ thereby breaking xterm... and blackbox... and who knows what else. This one was brought to my attention thanks to the #error directive. But there's certainly other things silently being compiled out now, as the program does not work correctly after fixing this. Unbelievable. Praise D's modules. PS the fonts are all hideous on the new linux too. I should have just bought a Windows license.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wednesday, 26 November 2014 at 20:06:02 UTC, Adam D. Ruppe wrote: xterm is one example. I basically like it but it is ugly and stupid so needs a few fixes. As such, I maintain my own private fork of it. I would hate to hear what you have to say about software that you don't like :o) PS the fonts are all hideous on the new linux too. I should have just bought a Windows license. What is your new linux distro?
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wed, Nov 26, 2014 at 08:06:01PM +, Adam D. Ruppe via Digitalmars-d wrote: So my computer died on me again last week and I had to buy new hardware. I was forced to update the software to run the new hardware... and it is painful. I have a high distrust of brand new *hardware*, because they inevitably are gratuitously incompatible with my current software and require new-fangled OSes bloated with features I never use. Because of this, I only ever upgrade once every 5 years (if not longer). And when I do, I'll be sure to spend plenty of time researching what hardware isn't horribly broken or requires a specific version of a specific OS and doesn't work with anything else. Vendor lock-in is evil. I hate all software and have learned that if I want a job done right, I have to do it myself. Rarely, I find other people's software is OK with some slight modifications, so I try to do that. I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller :-) xterm is one example. I basically like it but it is ugly and stupid so needs a few fixes. As such, I maintain my own private fork of it. You're brave. :-P Me, I've given up on xterm long ago, and use rxvt-unicode these days. At least it supports Unicode Unicode fonts without *too* much pain. But still... Speaking of which, whatever happened with your D-based terminal app from a while back? You did get it to the point where it could support inline images and stuff, which is pretty cool; if you could get it to the point where it works well with Unicode fonts, I'd dump rxvt and use your terminal instead. :-P I went ahead and compiled that on the new thing today and it failed. wait what?! #ifndef _XLIB_H_ #error Please include X11/Xlib.h before xutf8.h #endif That's in the xterm source code. Yes, it depends on the presence of a particular include guard. Whoa. That's ... messed up in more ways than I can name! The X11 source apparently recently changed to: #ifndef _X11_XLIB_H_ #define _X11_XLIB_H_ thereby breaking xterm... and blackbox... and who knows what else. Yeah, that's the downside of maintaining your own fork of stuff. Upstream (presumably) would've taken care of updating these ugly bits of code, but you don't get the benefit of that unless you regularly pull from upstream and merge, which is a lot of work to begin with. This one was brought to my attention thanks to the #error directive. But there's certainly other things silently being compiled out now, as the program does not work correctly after fixing this. Sigh... what else is new. That's the unvaryingly sad story I find with every sufficiently-complex C/C++ program. No matter how well-intentioned you start out and no matter how clean the initial design, it inevitably gravitates towards an incomprehensible patchwork of hacks upon bandages over patches to older hacks, containing hundreds of implicit assumptions (that's been already forgotten since the second last guy took over the codebase). Break any one of these hidden assumptions, and little inscrutable malfunctions start showing up everywhere. Unbelievable. Praise D's modules. Not just D modules, but many other aspects of D tend to keep your program away from sinking into the rathole of patches upon hacks upon bandages over patches, that every C/C++ program inevitably gravitates towards. (Unfortunately, some areas of D haven't been ironed out enough in this respect, and sometimes you do still have to do ugly hacks to make things work. But generally, D does give you the tools to limit the scope of such hacks so that they don't creep and take over program readability.) PS the fonts are all hideous on the new linux too. I should have just bought a Windows license. Shouldn't you be able to just install the good ole fonts and expunge the ugly new ones? Or has Linux desktop code devolved to the point of hard-coding specific font names for everything? soapbox This is one of the reasons I've completely given up on the whole desktop metaphor movement. It has become all glitz and no substance IMNSHO; all about this font vs. that font rather than actually solving real problems. Give me ratpoison and a bare terminal emulator any day, and my productivity gets boosted 300%. Even when I'm using Windows, that purportedly sports better UI design than Linux, I find myself spending more time fighting with the UI than actually getting anything done. The GUI emperor has no clothes, and I'm calling BS on the whole movement! /soapbox T -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous
Re: DMD hackers: pragma(address): Is this possible?
On 25 November 2014 at 19:08, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Johannes Pfau wrote in message news:m5288s$l8$1...@digitalmars.com...
No, unfortunately not. The module where the template is instantiated
needs to be the 'main' module. Or rather toObjfile must have been
called on the function for backend inlining. Unfortunately this seems
to be a complicated task.
Would it make sense to always call toObjfile for always-inline template
functions? That should be harmless...
That depends
There's a bit of a split-brain scenario going on (or maybe catch-42).
In the current architecture of DMD, there are two states, front-end
and back-end. However in GDC, there are four states, front-end (DMD),
front-end (GCC), middle-end and back-end.
But let's ignore the last two, they don't have anything to do with us.
There's just two states we are dealing with here: Front-end (AST of
the source code analysed by DMD), and back-end (AST of the code
generator for compiling down to object file/assembly).
As it stands, the front-end AST holds more information than the
back-end AST. This is because what get sent to the back-end (via
toObjFile) is done for the intention of being written to the final
object/assembly code, no questions asked. For DMD, this I guess is
reasonable because its back-end has limited heuristic analysis. Where
as in GCC we almost an overkill amount of it, to the point were we
must force_by_abi the output of every symbol.
This was not necessarily the intention, but due the preferred method
of compilation (single), and the selective nature when it comes to
template emission under this model; the back-end just cannot be
trusted to make certain (size) optimisations, as 90% of the time it
turns out to be in the wrong because it never gets enough information
in it's callgraph to correctly determine what should and should not be
emitted (we are back to the front-end knowing more information than
the back-end).
What would be ideal is something inbetween. Lets call this middle-end AST.
A middle-end AST is built alongside or immediately after the front-end
AST. Lets say for the most likely scenario, immediately after
semantic3 processing has finished, which is the best time to do such
things. This middle-end AST may allow for certain optimisations or
heuristic analysis to be done that cannot be done in the front-end
semantic processing (think of any warnings or code re-writes that we
must currently do in the back-end - no doubt come with the comments:
HACK, FIXME, or BUG XXX).
The crucial thing to understand though is that the middle-end AST is
just a transitive layer. Nothing done here is guaranteed to be emitted
to the resultant object file unless it lands at toObjFile. At this
point, the middle intermediate representation gets lowered/send it
down for finalising the compilation.
But, I guess we now have visitors for this sort of thing, so
tl;dr
foreach(m; module)
{
m.semantic();
ToBackendVisitor::accept(m); // pre-build back-end AST (doesn't exist)
}
foreach(m; module)
{
if (m in output_modules)
m.toObjFile(); // Now send to object file
}
--
Iain
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wednesday, 26 November 2014 at 20:59:30 UTC, CraigDillabaugh wrote: I would hate to hear what you have to say about software that you don't like :o) hehe What is your new linux distro? Slackware 14.1. I've been a Slackware user for a long time and I still find it less unbearable than the alternatives, but it often annoys me. I should have probably just compiled a new kernel and left everything else the same. On my old system, I deleted all but four of the fonts because I couldn't stand them. Tried to do that here, and X wouldn't start. But I think I have it ok enough now, the text still looks pretty bad, but I'm getting used to it (ugh). I seriously considered putting Windows on though and running linux in a VM. But I don't like the Windows mouse behavior, I like my sloppy focus and especially the lack of click raising windows. And my hotkeys on keys reserved by the system in Windows. On the other hand, I don't like it when it takes a whole day to get basic things working. Argh. But hopefully once it is up it'll give me a lot of use again.
Re: Named parameter builder pattern for template parameters
On Wednesday, 26 November 2014 at 17:42:07 UTC, Robik wrote:
If D would support getting parameter names(currently does not
work for lambdas) of lambdas we could have:
someConnect(host = test, port = 7999);
Just a random thought :)
import std.stdio;
import std.traits;
void main()
{
//Prints a blank line
writeln(ParameterIdentifierTuple!((int n) = n));
}
That's an annoying limitation. I've submitted a bug for it.
https://issues.dlang.org/show_bug.cgi?id=13780
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wed, 26 Nov 2014 21:07:00 + Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: Slackware 14.1. I've been a Slackware user for a long time and I still find it less unbearable than the alternatives, but it often annoys me. ah, now i understand why i like your code so much! ;-) signature.asc Description: PGP signature
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wednesday, 26 November 2014 at 21:02:20 UTC, H. S. Teoh via Digitalmars-d wrote: I have a high distrust of brand new *hardware*, because they inevitably are gratuitously incompatible with my current software and require new-fangled OSes bloated with features I never use. Yeah. My old computer started randomly freezing up though and I don't like that. Lasted only about 4 years. Though I might have solved the problem by disabling the second processor core in it, it went 10 days without trouble after doing that, whereas before it only went 7. But I ordered the new hardware just in case it failed completely, and when it all got here yesterday, I figured might as well give it a try. BTW this is my first computer without a floppy disk drive. I feel naked without one. Thankfully, it has an internal speaker though, I still have my beloved beeps. You're brave. :-P Me, I've given up on xterm long ago, and use rxvt-unicode these days. I never got into rxvt-unicode. I use xterm and plain rxvt together. I put rxvt on the right application menu key (next to right ctrl) to pop it up instantly and I dismiss it just as fast. I sometimes have ten rxvts open though who are only acting as controlling ttys for other applications. The megabyte of virtual space it saves over xterm seems important to me ...though the new box has 16 GB of memory and I've never come close to using even 4 GB before. Speaking of which, whatever happened with your D-based terminal app from a while back? I think I'm going to be using it now. It is working fine on this box whereas xterm is failing on me. I'm sure it has unicode issues though... but if I'm replacing my beloved, reliable xterm with it, I'll be forced to fix those eventually! I think I want to change the color scheme though. I like black xterms and my thing only does white. I think. Maybe I added an option and forgot what it is. The unicode support right now btw looks like I can handle individual code points fine, but not combining characters and surely not more. Individual codepoints are probably good enough for me though. The other part of my terminal emulator was also a gnu screen replacement. I got it to the point where it worked pretty well... but not well enough to break my inertia toward good old screen. Maybe I'll revisit that too though. BTW this system update seems to have changed my mutt too. Tab is bringing it back to the old items (marked O) instead of beeping when I'm out of new items (marked N). I'm not a big fan. Yeah, that's the downside of maintaining your own fork of stuff. Upstream (presumably) would've taken care of updating these ugly bits of code, but you don't get the benefit of that unless you regularly pull from upstream and merge, which is a lot of work to begin with. and it kinda defeats the point: merging from upstream means I'm stuck with their new features too, unless I carefully go through and am really selective about keeping the changes... at which point, I think it is useless. If a bug bothered *me*, I'd fix it myself, so I don't need every bug fix from upstream anyway, you start out and no matter how clean the initial design well, xterm isn't clean anyway :P Not just D modules, but many other aspects of D tend to keep your program away from sinking into the rathole of patches upon hacks upon bandages over patches, that every C/C++ program inevitably gravitates towards. indeed. Shouldn't you be able to just install the good ole fonts and expunge the ugly new ones? I tried that and then X wouldn't start. Part of what annoys me is there isn't an xorg.conf anymore. Perhaps I could add one, but by default there isn't one at all and it tries to auto configure everything. That's great when it works, but I'm not sure what to do when it doesn't. The GUI emperor has no clothes, and I'm calling BS on the whole movement! /soapbox I like guis sometimes. Though much of it is just me wanting to watch a youtube while doing something else in another few windows.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wed, 26 Nov 2014 20:06:01 + Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: xterm is one example. I basically like it but it is ugly and stupid so needs a few fixes. As such, I maintain my own private fork of it. ah, terminal emulators... i ended writing my own after i found that rxvt is effectively dead, mrxvt too, and rxvt-unicode is just a mess. looking back i must say that i'd better adopt rxvt-unicode instead of writing my own emulator, 'cause writing terminal emulator that works with all console software is a PITA. signature.asc Description: PGP signature
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wednesday, 26 November 2014 at 21:34:43 UTC, ketmar via Digitalmars-d wrote: looking back i must say that i'd better adopt rxvt-unicode instead of writing my own emulator, 'cause writing terminal emulator that works with all console software is a PITA. true but I set my sights lower: I just want works for me. After a bunch of guess and checking, I got the two most complex programs I use - mutt and vim - including with or without gnuscreen to work, and that's good enough. If I have to use a complex program that doesn't work right in it, I figure I can always fall back on xterm, rxvt, or the Linux console.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On 11/26/14, Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: That's in the xterm source code. Yes, it depends on the presence of a particular include guard. Oh you should know how much trouble I went through when I was building my C++ wrapping tool (initially just a wxWidgets wrapping tool). The include stuff was 90% of the mess. So much frustration with *order of inclusions*. It's probably *the* reason why I completely burnt-out on continuing working on tool after several months. I can't believe there are brand-new programming languages being developed where the author(s) still insist(s) on textual inclusion. I'm sorry, but the detour you took with that simple decision causes an insane mess for both the tools and the end-user, don't repeat the mistake of C and C++ anymore, please! D's modules are a **massive blessing**.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wed, Nov 26, 2014 at 09:21:21PM +, Adam D. Ruppe via Digitalmars-d wrote: On Wednesday, 26 November 2014 at 21:02:20 UTC, H. S. Teoh via Digitalmars-d wrote: I have a high distrust of brand new *hardware*, because they inevitably are gratuitously incompatible with my current software and require new-fangled OSes bloated with features I never use. Yeah. My old computer started randomly freezing up though and I don't like that. Lasted only about 4 years. Though I might have solved the problem by disabling the second processor core in it, it went 10 days without trouble after doing that, whereas before it only went 7. That's not a good sign at all. Have you considered just replacing the power supply? The second last time (i.e., 10 years ago :-D) I had to replace my computer was when the PSU started to fail, causing random shutdowns, reboots, and freezes. Replacing the power supply brought things back to normal for a few more years. Then my previous PC (~8 years ago :-P) suffered a rather horrible catastrophe: I was out-of-town for a while and had deposited it for safekeeping at my cousin's, and then when I came back I had my roommate fetch it for me. Unfortunately, he left it in the trunk overnight, causing it to accumulate morning dew -- both outside and, unbeknownst to me, also inside. Stupidly thinking that it was good enough to wipe off the dew from the outer casing, I plugged it in and turned it on, and instantly there was the loudest buzzing sound I've ever heard coming from a PC, the apartment blew a fuse, and there was the smell of smoke in the air. I was so traumatized that I didn't dare look inside the chassis until a looong time later. :-P When I did, I saw exploded capacitors inside the PSU along with re-frozen arcs of exploded molten material shooting off in various directions inside the casing, and other such brown blobs of melted PSU components. But here's the funny thing... I took out the motherboard, bought a new chassis and PSU, and plugged it all in, and it booted with no problems Apparently, the PSU took the brunt of the short circuit caused by the moisture, and the mobo was unharmed. You have no idea what a huge sigh of relief I had... and the hardy little mobo continued running until about 4 years ago when I finally replaced it with a newer system because I was doing a lot of image rendering with povray and wanted to take advantage of a multicore CPU (multiple parallel renders) -- so I upgraded from single core to an AMD hexacore. :-D The mobo is probably still functional today -- I just have to find a spare chassis to host it. So yeah, tl;dr, PSU's tend to last shorter than mobo's. You might be lucky that your mobo is still fine, it's just the PSU that's starting to die. But I ordered the new hardware just in case it failed completely, and when it all got here yesterday, I figured might as well give it a try. IME, that's almost a sure setup for disappointment. :-P The first time I got my new mobo, I suddenly realized to my horror that the mobo is incompatible with my old RAM, sound card, AGP video card, and ... hard drives(!). So I had to go out and buy a whole buncha new stuff and adaptors. That'll teach me a lesson on not doing my research properly before shelling out the cash... BTW this is my first computer without a floppy disk drive. I feel naked without one. Thankfully, it has an internal speaker though, I still have my beloved beeps. Haha... right now I'm in the predicament of no longer having a floppy drive, yet my old electronic piano still uses one, so now I can no longer copy my recordings to my PC. :-( But speaker beeps... I hate those!!! I hate them so much, that not only I didn't compile the driver into my custom kernel, I didn't even connect the wires from the mobo to the speaker. :-P I like my PC to be completely mute except when I ask it to make a sound. You're brave. :-P Me, I've given up on xterm long ago, and use rxvt-unicode these days. I never got into rxvt-unicode. I use xterm and plain rxvt together. I put rxvt on the right application menu key (next to right ctrl) to pop it up instantly and I dismiss it just as fast. I sometimes have ten rxvts open though who are only acting as controlling ttys for other applications. The megabyte of virtual space it saves over xterm seems important to me I find xterm far too bloated and quirky for my tastes. I also like to minimize RAM usage where possible. Sadly, RAM usage for Xorg is never controllable, same goes for all browsers except Elinks. If only Elinks supported Javascript and CSS (at least rudimentary CSS), I'd be quite tempted to dump GUI browsers completely for it. ...though the new box has 16 GB of memory and I've never come close to using even 4 GB before. Really?? I would've thought DMD easily soaks up 4GB if you do enough recursive CTFE / template metaprogramming... :-P Speaking of which, whatever happened with your D-based terminal app from
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wed, 26 Nov 2014 14:20:37 -0800 H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: The other part of my terminal emulator was also a gnu screen replacement. I got it to the point where it worked pretty well... but not well enough to break my inertia toward good old screen. Maybe I'll revisit that too though. Ooooh, I'd love that! I do use screen a lot, but some aspects of it annoy me a lot. Like the non-transitivity of terminal settings, so $TERM doesn't get set properly, and even when it does, screen sometimes misinterprets sequences not meant for it. Ideally, screen (or your replacement thereof) should be able to detect the end user's terminal (even if it's proxied via ssh, etc.) and do the Right Thing(tm) on the server end so that applications get the right $TERM settings. i was never big fan of screen and i never used any of it's advanced features, so once i dumped it in favor of dtach. and now i'm really happy, 'cause dtach does exactly what i want: allows me to detach from console program and then attach to it again. it intercepts only one hotkey and doesn't try to mess with escape codes at all. love it. sure, it doesn't keep output history, you have to press something like ctrl+l to redraw the screen in fullscreen app (if that app supports it) and so on, but my, it's nothing compared to constant fighting with 'screen', it's configs, it's habit to steal and reinterpret escapes... now i'm happy dtach user. signature.asc Description: PGP signature
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wed, Nov 26, 2014 at 10:46:08PM +0100, Andrej Mitrovic via Digitalmars-d wrote: On 11/26/14, Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: That's in the xterm source code. Yes, it depends on the presence of a particular include guard. Oh you should know how much trouble I went through when I was building my C++ wrapping tool (initially just a wxWidgets wrapping tool). The include stuff was 90% of the mess. So much frustration with *order of inclusions*. It's probably *the* reason why I completely burnt-out on continuing working on tool after several months. Wow. I've only had the misfortune of having to deal with order-dependent #include's a few times in my life. I must live a sheltered life indeed! :-P I do agree that they are utterly evil, though. Even more evil is header files that compile successfully even if the #include's are wrongly ordered, but behaves differently (yes, I have actually seen this before): // some evil .h file: ... #ifndef someSillyStdLibMacro #define someSillyStdLibMacro myOwnBrokenImpl #endif So if you #include the system header that defines someSillyStdLibMacro, then you get the right behaviour, otherwise, the code still compiles but you end up using myOwnBrokenImpl instead, which inevitably does NOT work properly on your system 'cos, unsurprisingly, it was written for the author's own peculiar environment. Worse yet, the broken implementation only gets used in .c files that have the wrong ordering of #include's. Good luck debugging this nightmare! I can't believe there are brand-new programming languages being developed where the author(s) still insist(s) on textual inclusion. Wow. Textual inclusion is so 80's! Where've they *been* all this time?! I'm sorry, but the detour you took with that simple decision causes an insane mess for both the tools and the end-user, don't repeat the mistake of C and C++ anymore, please! D's modules are a **massive blessing**. Yeah, D's module system saves a LOT of headache, even in spite of its flaws. (Private imported module symbols conflicting with public symbols, anyone? Global scoped imports always being public? Local unscoped imports shadowing local variables (aka local variable hijacking)? Yeah, D modules could be better... but compared with #ifdef hell in C/C++, it's still orders of magnitude better.) T -- Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Thu, Nov 27, 2014 at 12:33:25AM +0200, ketmar via Digitalmars-d wrote: [...] i was never big fan of screen and i never used any of it's advanced features, so once i dumped it in favor of dtach. and now i'm really happy, 'cause dtach does exactly what i want: allows me to detach from console program and then attach to it again. it intercepts only one hotkey and doesn't try to mess with escape codes at all. love it. sure, it doesn't keep output history, you have to press something like ctrl+l to redraw the screen in fullscreen app (if that app supports it) and so on, but my, it's nothing compared to constant fighting with 'screen', it's configs, it's habit to steal and reinterpret escapes... now i'm happy dtach user. Whoa. Just looked up dtach... I like it I think I might start using it in favor of screen, which like you said is just a mess. Thanks for the tip!! T -- I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wednesday, 26 November 2014 at 22:22:43 UTC, H. S. Teoh via Digitalmars-d wrote: Have you considered just replacing the power supply? That was one of my first thoughts, my last computer refit was caused by a PSU failure. I did some measurements on it and everything looked normal in fact, EVERYTHING looked normal, the only time I could consistently reproduce the problem on-demand was running memtest with SMP turned on. That's why I figured the problem was with the dual-core and disabled it. But even now, I'm not 100% convinced that was the problem, maybe it was the power supply, under stress not keeping up. I didn't measure it at higher draw. I figure I'll set up the old computer still - pull my IDE hard drive out of the upstairs storage box to see about booting it though that i think has a 32 bit kernel on it... well, i can tackle that later. Anyway, I figure I'll set it up somewhere and still try to use it and see if the fix actually works in the longer run, but I didn't want to depend on it because these kinds of problems just tend to get worse. But here's the funny thing... I took out the motherboard, bought a new chassis and PSU, and plugged it all in, and it booted with no problems wow, sounds like luck to me :P IME, that's almost a sure setup for disappointment. :-P So is trying anything new. Except cheesecake, I was convinced to make a cheesecake this August and even at a piece myself when there was leftovers... and it was AMAZING. I have one in the oven right now! But mostly: change... bah, humbug. I like my PC to be completely mute except when I ask it to make a sound. That's actually exactly *why* I *like* the speaker. I have ways of making it only work when I want it to (mostly my heavily customized software stack...) and having the separate channel from the main speakers lets me keep a clean separation. I use the PC speaker beeps to quickly and unobstructively* notify me about new events. Emails, instant messages, etc., each has its own beep tone. I can turn off the main audio speakers or use them for different things at various volumes without worrying about my notification beeps coming in nasty. I hate it when I'm cranking some noise and then someone FB messages me and it is like PLUNK and my ear drums explode. The speaker beep is nice and consistent. * One time, I used a computer with a MEGA LOUD BEEP and that drive me nuts. Defeats the whole point to me. But I've been lucky with just-right beeps out of my own desktops. Really?? I would've thought DMD easily soaks up 4GB if you do enough recursive CTFE / template metaprogramming... :-P I run 32 bit dmd, it'd be killed before then :P I like off-white terminals. Better yet, if your terminal could support the xterm 256-color escape sequences... I'm pretty sure it does support these already yeah, line 1437 of terminalemulator.d has it. I implemented a 256 color palette at one point but the case 38 there for xterm 256 colors actually draws in truecolor. There's also palette swap capabilities in there. I went kinda nuts on features in that thing. One of them is also a copy/paste extension that can be forwarded through nested terminals. The Windows version can do clean cut+paste with linux apps! (The Windows versions are cool btw, one is a GUI just like the linux one - like identical, since it uses an embedded font and font renderer too, and the other is a win32 console version, which is surprisingly elegant. I like it a lot. But not enough to kill PuTTY yet (especially since my windows version depends on plink to communicate. It just speaks to a piped process instead of knowing ssh or anything itself.) Shouldn't byGrapheme handle most of that out-of-the-box already? Maybe, I haven't tried. misinterprets sequences not meant for it. Ideally, screen (or your replacement thereof) should be able to detect the end user's terminal (even if it's proxied via ssh, etc.) and do the Right Thing(tm) The approach I took is similar to screen: it intercepts all the escape sequences and handles them itself. My screen replacement has two parts: attach and detachable. You can see the source on my github terminal-emulator project. Attach uses terminal.d to read user input events and forward them down the line. detachable uses the terminal emulator core to maintain an internal screen buffer. When you attach to it, it sends commands to draw itself and a few other state issues. When it changes, it forwards those changes outward. But ultimately, the detachable thing is just a terminal emulator that redraws itself through a unix socket instead of straight to the screen. I have a muttrc that basically completely remaps most of the keys... I kept my muttrc (I didn't copy my whole /home/me directory because I kinda want to clean it out - it has like 2,000 files on the top level - but I copied parts of it to the new one and the old is
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wednesday, 26 November 2014 at 22:39:52 UTC, H. S. Teoh via Digitalmars-d wrote: Whoa. Just looked up dtach... I like it I think I might start using it in favor of screen, which like you said is just a mess. I've tried dtach before but never got into it. There's actually a handful of screen's messier features that I like...
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
Found a bug in the terminal emulator immediately after switching my hotkeys to use it - there was an escape sequence sent to it that the controlling terminal usually responded to and now it didn't have one. And vim apparently changed its auto indent behavior. Thanks, now my habit of hitting enter then tab is breaking the code. So angry, this is stupid beyond belief. vim usually impresses me with its goodness. That makes this BETRAYAL hurt all the more. et tu, vim? et tu? BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Thu, 27 Nov 2014 03:51:58 +
Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote:
BTW @nogc should have an escape hatch at least for assert(0,
allocate_a_message). The program is dying anyway, at least let me
conveniently format a descriptive error message.
hey, but we can hack it!
import std.traits;
auto assumeNoGC(T) (T t) if (isFunctionPointer!T || isDelegate!T) {
enum attrs = functionAttributes!T | FunctionAttribute.nogc;
return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
}
void test () @nogc {
assert(0, assumeNoGC(() { import std.format : format; return
%s.format(hi)~ there!; })()); }
void main () @nogc {
test();
}
signature.asc
Description: PGP signature
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Thursday, 27 November 2014 at 03:51:59 UTC, Adam D. Ruppe wrote: BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message. Ownership would solve this.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Thursday, 27 November 2014 at 05:04:20 UTC, deadalnix wrote: On Thursday, 27 November 2014 at 03:51:59 UTC, Adam D. Ruppe wrote: BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message. Ownership would solve this. Is there any work being done on ownership? @Adam D. Ruppe : Check out st from suckless, it was made because xterm is unmaintainable. Also, consider a distro from this century ;)
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Thu, 27 Nov 2014 05:12:51 + weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: @Adam D. Ruppe : Check out st from suckless, it was made because xterm is unmaintainable. Also, consider a distro from this century ;) heh, that was the base of my own terminal emulator. just because that was the only TE with non-writeonly code. ;-) signature.asc Description: PGP signature
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Thursday, 27 November 2014 at 05:12:52 UTC, weaselcat wrote: On Thursday, 27 November 2014 at 05:04:20 UTC, deadalnix wrote: On Thursday, 27 November 2014 at 03:51:59 UTC, Adam D. Ruppe wrote: BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message. Ownership would solve this. Is there any work being done on ownership? @Adam D. Ruppe : Check out st from suckless, it was made because xterm is unmaintainable. Also, consider a distro from this century ;) I've made some proposal, but it looks like the first stone we want to have is scope.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Wednesday, 26 November 2014 at 21:02:20 UTC, H. S. Teoh via Digitalmars-d wrote: soapbox This is one of the reasons I've completely given up on the whole desktop metaphor movement. It has become all glitz and no substance IMNSHO; all about this font vs. that font rather than actually solving real problems. Give me ratpoison and a bare terminal emulator any day, and my productivity gets boosted 300%. Even when I'm using Windows, that purportedly sports better UI design than Linux, I find myself spending more time fighting with the UI than actually getting anything done. The GUI emperor has no clothes, and I'm calling BS on the whole movement! /soapbox That's because GUIs are not aimed at highly technical power users like you, but for most people, who don't want to memorize a bunch of technical commands and barely know how to type. They would be much slower with ratpoison and a terminal than you are with a GUI. ;) Touch similarly brought computing to a billion more people, while taking another step backwards in interaction bandwidth from the desktop GUI. The cruder you make the tool, the easier it is for people to grasp. However, I'm looking forward to voice recognition and some sort of hand gesture input becoming the dominant interfaces in the coming years. Those will be even easier to use than anything so far, and could be much faster than even your current keyboard-driven software.
Re: [OT] unbelievable: #ifdef _OTHER_LIB_H
On Thu, 27 Nov 2014 06:50:59 + Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: However, I'm looking forward to voice recognition and some sort of hand gesture input becoming the dominant interfaces in the coming years. Those will be even easier to use than anything so far, and could be much faster than even your current keyboard-driven software. i just imagined some sort of i... human standing against the wall, gesticulating like mad and talking nonsense to the void... creepy. i bet that such intefaces will be widespread, but faster and more usable? nope. i can type much faster than i'm talking, i can edit what i typed and... and just won't buy it. but yes, they *seems* to be better than plain old keyboard. signature.asc Description: PGP signature
Error when downloading with +
Hi ppl!
When dub builds the project, he tries to load the
http://code.dlang.org/packages/libevent/2.0.1+2.0.16.zip file,
and dub gives out this error:
Running DUB build
dub build
@ /mnt/hdd2_3/ftp/workspace_eclipse/axt-d-base-application
The following changes will be performed:
Fetch dunit ~master, userWide
Fetch libevent =2.0.1+2.0.16 2.1.0, userWide
Fetch ddbc =0.2.9, userWide
Fetch mysql-d =0.3.0, userWide
Fetch hibernated =0.2.11, userWide
Fetch openssl =1.0.0+1.0.0e, userWide
Fetch libev =4.0.0+4.04 4.1.0, userWide
Fetch mysql-native 0.0.10, userWide
Package dunit ~master (/home/ruzzz/.dub/packages/) is already
present with the latest version, skipping upgrade.
Fetching libevent 2.0.1+2.0.16..
Error executing command build: Failed to download
http://code.dlang.org/packages/libevent/2.0.1%252B2.0.16.zip: 404
Not Found
How to fix it?
dub.json:
{
name : axt-d-base-application,
description : A minimal D bundle.,
homepage: https://axi.su;,
license: GPL-2.0,
targetType: executable,
targetPath: bin,
dependencies : {
hibernated: =0.2.11,
toml-d: =0.3.0,
vibe-d: 0.7.21-beta.4,
ax-static-d: {
version: 0.0.1,
path: ../ax-static-d/
}
},
configurations: [
{
name: MySQL,
versions: [USE_MYSQL],
subConfigurations:
{
hibernated: MySQL
}
},
{
name: SQLite,
versions: [USE_SQLITE],
libs-posix: [sqlite3],
libs-windows: [sqlite3],
subConfigurations:
{
hibernated: SQLite
}
}
],
buildTypes: {
debug: {
buildOptions: [debugMode, debugInfo, optimize]
},
release: {
buildOptions: [releaseMode, optimize]
}
},
versions: [VibeCustomMain, USE_MYSQL]
}
Re: Reducing Pegged ASTs
On Wednesday, 26 November 2014 at 06:09:12 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: IIRC there is a free function in Pegged that does it. What's the name of this function? I did not automate it, because every time I cut down severely a parse tree, I later regret it because I lost information that way. Cutting while still retaining original info (who is this node's ancestor) is more difficult: you would have to store it somewhere anyhow. You cannot create node classes to represent the hierarchy, because of loops in the grammar: an Identifier can have many different ancestors. Note also that Pegged produces parse trees (complete parsing information), not ASTs. ASTs would indeed be much smaller, but we would have to define what are the master nodes in the D grammar. What do you mean with master nodes? If you want to remember the intermediate nodes you cut down, not really, since you still need to store them somehow. I don't quite understand your formulation in English here. Could you elaborate? I think what's consuming memory right now is that I duplicate the matched strings at each level What do you mean with duplicate? Doesn't Pegged use string slices that reference the original source? If this problem is related to (im)mutability and If I understand you correctly you could use something like static if (isImmutable!Source) node.text = source_text[i..j]; else node.text = source_text[i..j].idup; right? Where in Pegged could this logic be injected?
Re: Uninitialized object hangs without warning.
Bear Cherian:
Class MyClass{
this(){}
void someFunction(){
//body
}
}
And in my app I had something like
MyClass classObject;
classObject.someFunction();
When I compile, no warnings or errors.
If you compile that code (with lowercase Class) with -O the
compiler finds the bug:
class MyClass {
this() {}
void someFunction() {
//body
}
}
void main() {
MyClass classObject;
classObject.someFunction;
}
test.d(11,5): Error: null dereference in function _Dmain
But in more complex cases the compiler doesn't.
Bye,
bearophile
Re: Error when downloading with +
This is an issue with your version of dub with a buggy url encoding method. Download the latest at code.dlang.org http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/22266/
Cache Building of Pegged-Generated Parsers in a DUB Project
I want to cache parsers generated by Pegged grammars in a DUB project by writing the generated parser strings to files. Is it possible to add this build logic somewhere in DUB or do I have to resort to SCons for this?
Re: Error when downloading with +
On Wednesday, 26 November 2014 at 10:01:32 UTC, Suliman wrote: This is an issue with your version of dub with a buggy url encoding method. Download the latest at code.dlang.org http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/22266/ thanks, up-dating to version 0.9.22 solved the problem.
Re: Cache Building of Pegged-Generated Parsers in a DUB Project
On Wednesday, 26 November 2014 at 10:26:05 UTC, Nordlöw wrote: I want to cache parsers generated by Pegged grammars in a DUB project by writing the generated parser strings to files. Is it possible to add this build logic somewhere in DUB or do I have to resort to SCons for this? preBuildCommand in check if the files are there if not generate them if yes do nothing
Re: Cache Building of Pegged-Generated Parsers in a DUB Project
On Wednesday, 26 November 2014 at 12:09:34 UTC, Stefan Koch wrote: preBuildCommand in check if the files are there if not generate them if yes do nothing Thanks! Documented here http://code.dlang.org/package-format by searching for preBuildCommands
const class
Hello. I can't find siple way to realization this behavior:
[code]
class A
{
A parent;
void someFunc() const { }
void parentCall() const
{
const(A) cur = this;
while( cur )
{
cur.someFunc();
cur = cur.parent;
}
}
}
[/code]
error: cannot modify const expression cur
how create variable that store const object and can be changed to
other const object?
Re: Cache Building of Pegged-Generated Parsers in a DUB Project
On Wednesday, 26 November 2014 at 12:09:34 UTC, Stefan Koch wrote: On Wednesday, 26 November 2014 at 10:26:05 UTC, Nordlöw wrote: I want to cache parsers generated by Pegged grammars in a DUB project by writing the generated parser strings to files. Is it possible to add this build logic somewhere in DUB or do I have to resort to SCons for this? preBuildCommand in check if the files are there if not generate them if yes do nothing I guess I could right a separate d program that generates the files called by preBuildCommand. But it would be even greater if we could do CTFE-file-io to check whether the evaluation needs to be called at all. As we can import files (generated parser module) into strings and write the generated parser strings at run-time the only thing need is to add some logic that generates a digest every time a parser is generated write that digest to a file and then import that digest at compile time at compare it to the digest of the parser string read at compile time. If they differ (at compile time) using static if the parser enum string is updated. Does my vision hold water? Destroy.
Re: const class
Oleg: how create variable that store const object and can be changed to other const object? Take a look at std.typecons.Rebindable/std.typecons.rebindable. Read all Phobos documentation, it helps. Bye, bearophile
Re: windows linker error
On Wednesday, 26 November 2014 at 04:10:08 UTC, Vlad Levenfeld
wrote:
I'm compiling the latest build from github.
(I normally stay up to date with the current builds on 64bit
Debian and everything works more or less without a hitch there,
but now I need to get some of my tools working in a Windows
environment)
I'm not really sure what my options are regarding the COFF or
what they mean, 64-bit is really the only requirement (mostly
because I can't get the 32-bit stuff to compile).
I've got Visual Studio Premium, I tried to install from the exe
at one point and got Visual D in the process (and this did
work, except that the code I need is built against the latest
dmd/druntime/phobos builds).
I see, so the problem appears to be that you're trying to compile
D from git to produce Win64 builds. COFF is the binary format
used by Microsoft for their MSVC runtime, and dmd only supports
Win64 with COFF, the Microsoft linker, and MSVC. If you're okay
with 32-bit dmd from git, which by default uses the Digital Mars
C runtime, the Digital Mars linker called optlink, and the OMF
binary format, these instructions should work for you, as they
did for me:
http://wiki.dlang.org/Building_DMD#Windows_2
Installing it from the instructions, IIRC, also worked for me,
but again, the version.
So I used the dmd visual studio project to build dmd, then
built druntime and phobos with Digital Mars make;
I had previously tried to use dmc to build dmd but couldn't get
it to work.
Anyway, I manage to build successfully but then I get this
linker error when I try to run dmd on some test.d consisting of
void main (){}.
I've gone into sc.ini and pulled out the ;VC2012 comments to
expose the LIB instruction (to fix a different problem) and
this is the point that I've gotten stuck at.
If you still want to get Win64 from git working, I advise you to
use a release build of dmd from the zip and set it up to get code
compiling for Win64, ie make sure you understand what environment
variables need to be set to use the MSVC runtime and linker.
Then, compile dmd from git using dmc and the instructions linked
above, before using the same Win64 environment variables to
compile your code.
If you still have problems, you may want to look at the scripts
and Win64-specific patches that Brad uses on the auto-tester to
continuously build dmd for Win64:
https://github.com/braddr/d-tester/tree/master/client/src
Re: Uninitialized object hangs without warning.
On Wednesday, 26 November 2014 at 09:38:11 UTC, bearophile wrote:
Bear Cherian:
Class MyClass{
this(){}
void someFunction(){
//body
}
}
And in my app I had something like
MyClass classObject;
classObject.someFunction();
When I compile, no warnings or errors.
If you compile that code (with lowercase Class) with -O the
compiler finds the bug:
class MyClass {
this() {}
void someFunction() {
//body
}
}
void main() {
MyClass classObject;
classObject.someFunction;
}
test.d(11,5): Error: null dereference in function _Dmain
But in more complex cases the compiler doesn't.
Bye,
bearophile
Yes, the capital C was a typo.
I still think this shouldn't be an optimization. Maybe I'm just
used to Java, as this would be a compile error by default.
Compile-Time Memoization of Pegged-Generated Parser
I have working logic for automatic memoization of Pegged-generated parsers from Peg grammars here https://github.com/nordlow/justd/blob/master/firstPegged/source/app.d Now I wonder if this logic could be modularized in some way making it more easy to use (and not so verbose). The key question is if it's possible to somehow replace the module ctor at https://github.com/nordlow/justd/blob/master/firstPegged/source/app.d#L339 that writes the grammar and parser to disk with some automatic registration logic. My plan is to append these to an array of pairs of string at https://github.com/nordlow/justd/blob/master/firstPegged/source/app.d#L52 that contain file and string to persistently memoized. But when uncomment the lines declaring and appending to fileWrites I get a compilation error source/app.d(63): Error: no identifier for declarator fileWrites source/app.d(63): Error: Declaration expected, not '~=' source/app.d(64): Error: no identifier for declarator fileWrites source/app.d(64): Error: Declaration expected, not '~=' Have I missed something? Destroy!
Re: Compile-Time Memoization of Pegged-Generated Parser
On Wednesday, 26 November 2014 at 22:31:04 UTC, Nordlöw wrote: source/app.d(63): Error: no identifier for declarator fileWrites source/app.d(63): Error: Declaration expected, not '~=' source/app.d(64): Error: no identifier for declarator fileWrites source/app.d(64): Error: Declaration expected, not '~=' Have I missed something? Destroy! Update: I guess this means D doesn't allow any statements in global scope. Can/Should I instead use some compile-time reflection to get list of parser strings that should be cached to disk? I guess if I wrap the path-parser-string-pair in a struct, say CachingPeggedParser, defined in global scope I could get a list of all the enum instances of this struct and do something with these in module constructor right? Please tell me if this approach is unneccessary complicated!
Array toHash()
I have a class which contains an int[] and some other stuff. I want to
use my class as the key for an AA, so I am overriding toHash(). But the
int[] is the only part which should produce the hash code. I know that
int[].toHash() is defined somehow, because I can put int[] directly into
an AA without writing any hash functions. But I don't know how to spell
this explicitly or force the compiler to generate it for me so that I
can forward to it in my toHash(). For illustration:
class Foo
{
override
size_t toHash() @trusted pure const nothrow
{
// error: no property 'toHash' for type 'int[]'
return importantStuff.toHash();
}
// override opEquals() too...
int[] importantStuff;
bool notImportant;
int ignoreMe;
}
Any way to avoid re-implementing this hash function?
Dave
Re: Casting in Safe D
On 11/23/2014 3:12 PM, anonymous wrote:
[...]
And even pointer dereferencing is @safe. Invalid ones will fail
with a segfault at run time:
void foo(int* a) @safe {*a = 13;}
Hmm...throwing an exception is a well-defined behavior, but is
segfaulting a well-defined behavior of correct D programs? This seems
like a peculiar definition of safe to me...
Dave
Re: Array toHash()
On 11/26/2014 04:25 PM, David Held wrote:
class Foo
{
override
size_t toHash() @trusted pure const nothrow
{
// error: no property 'toHash' for type 'int[]'
return importantStuff.toHash();
}
The getHash() member function of the particular TypeInfo can be used.
However, it is not currently pure, so you must comment that out from
your toHash:
override
size_t toHash() @trusted /* pure */ const nothrow
{
return typeid(importantStuff).getHash(importantStuff);
}
If a function can safely be casted to pure, you can use the following
yet-missing-in-phobos function template:
import std.traits;
auto assumePure(T)(T t)
if (isFunctionPointer!T || isDelegate!T)
{
enum attrs = functionAttributes!T | FunctionAttribute.pure_;
return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
}
// ...
override
size_t toHash() @trusted pure const nothrow
{
auto func = assumePure((typeid(importantStuff).getHash));
return func(importantStuff);
}
Note that now your toHash can be pure.
Ali
Still not D standard yet ?
I would like to know if something has changed in the plans for the future of D, because I really think it needs some kind of formalization and standardization to be a good investment, especially for medium/large/commercial projects . Thanks.
[Issue 13777] New: Value range propagation faild on array function argument
https://issues.dlang.org/show_bug.cgi?id=13777
Issue ID: 13777
Summary: Value range propagation faild on array function
argument
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code used to work:
---
T select(T)(in size_t idx, T[2] values...)
{
return values[idx];
}
void main()
{
ubyte ub = select(0, 3, 4);
}
---
In case it was an accept-invalid bug, a clear reason to disallow the feature
should be stated as it breaks user code without any deprecation cycle.
--
[Issue 13777] Value range propagation faild on array function argument
https://issues.dlang.org/show_bug.cgi?id=13777 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc --- (In reply to Denis Shelomovskij from comment #0) In case it was an accept-invalid bug, I doubt it was an accept-invalid bug. --
[Issue 13778] New: Flush stream when std.stdio.writeln() is called
https://issues.dlang.org/show_bug.cgi?id=13778 Issue ID: 13778 Summary: Flush stream when std.stdio.writeln() is called Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bruno.do.medeiros+deeb...@gmail.com This is an enhancement request to flush the stdio stream whenever std.stdio.writeln is called (but not for std.stdio.write). The problem this is causing, is for example that when running D programs under Eclipse (which creates its own console), no flushing is done when a newline is received. According to this SO question: http://stackoverflow.com/questions/19498040/eclipse-console-writes-output-only-after-the-program-has-finished , Adam D Ruppe has commented the following: I'm not entirely sure what's going on here, but I think the line buffering only happens if the receiving end is a regular terminal. Otherwise, it gets the same buffering as any other file (because it likely is any other file). With Eclipse, again I'm guessing, it is probably talking to the eclipse process through a pipe, and that isn't registering as an interactive terminal so it goes back to full buffering. As a note of interest, Java's `System.out.println()` has the behavior requested here, it does flushing automatically at the end of the call. --
[Issue 1734] mixins for statements
https://issues.dlang.org/show_bug.cgi?id=1734 Nick Treleaven ntrel-...@mybtinternet.com changed: What|Removed |Added CC||ntrel-...@mybtinternet.com Summary|Inconsistent mixin |mixins for statements |behaviour | --
[Issue 13779] New: gdb can't print variables with Could not find the frame base for function error
https://issues.dlang.org/show_bug.cgi?id=13779 Issue ID: 13779 Summary: gdb can't print variables with Could not find the frame base for function error Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: c...@dawg.eu This only happens when linking with ld.gold. Looks like the problem has something to do with this warning from readelf. readelf: Warning: There are 76 unused bytes at the end of section .debug_loc This is already present in the object file, but sometimes the linking seems to fix it. If it doesn't (only happens with ld.gold) then gdb fails to find a frame base. --
[Issue 13780] New: Empty ParameterIdentifierTuple for function literal
https://issues.dlang.org/show_bug.cgi?id=13780
Issue ID: 13780
Summary: Empty ParameterIdentifierTuple for function literal
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
import std.stdio;
import std.traits;
void main()
{
//Prints a blank line
writeln(ParameterIdentifierTuple!((int n) = n));
}
--
[Issue 13781] New: Tuple assign should be @nogc
https://issues.dlang.org/show_bug.cgi?id=13781
Issue ID: 13781
Summary: Tuple assign should be @nogc
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
void main() @nogc {
import std.typecons: Tuple;
alias T = Tuple!(string,s);
T x;
x = T.init;
}
dmd 2.067alpha:
test.d(5,7): Error: @nogc function 'D main' cannot call non-@nogc function
'std.typecons.Tuple!(string, s).Tuple.opAssign!(Tuple!(string,
s)).opAssign'
--
[Issue 13782] New: gdc - fails to compile. Unrecognized option -plugin
https://issues.dlang.org/show_bug.cgi?id=13782 Issue ID: 13782 Summary: gdc - fails to compile. Unrecognized option -plugin Product: D Version: unspecified Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: make Assignee: nob...@puremagic.com Reporter: ga...@acuratel.com I have installed the following : native_2.065_gcc4.9.0_a8ad6a6678_20140615.tar And when I attempt to compile the hello.d program I get the following. Any suggestions. Thanks, -gary knudsen On Linux : CentOS release 6.5 (Final) Linux big2 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux = gdc hello.d -o hello /usr/bin/ld: unrecognized option '-plugin' /usr/bin/ld: use the --help option for usage information collect2: error: ld returned 1 exit status --
[Issue 13780] Empty ParameterIdentifierTuple for function literal
https://issues.dlang.org/show_bug.cgi?id=13780 sinkuup...@gmail.com changed: What|Removed |Added CC||sinkuup...@gmail.com --
[Issue 13759] VS2010 Win64 linker path wrong
https://issues.dlang.org/show_bug.cgi?id=13759 --- Comment #5 from Manu turkey...@gmail.com --- I just installed DMD+VisualD on another fresh installation with VS2010, and the same problem. It definitely doesn't work on fresh installs with 2010. The linker path just needs to be set to bin/amd64/link.exe instead of bin/link.exe and it's fine. --
[Issue 13779] gdb can't find frame base when using ld.gold
https://issues.dlang.org/show_bug.cgi?id=13779 Martin Nowak c...@dawg.eu changed: What|Removed |Added Summary|gdb can't print variables |gdb can't find frame base |with Could not find the|when using ld.gold |frame base for function| |error | --
[Issue 13779] gdb can't find frame base when using ld.gold
https://issues.dlang.org/show_bug.cgi?id=13779 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #1 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/dmd/pull/4168 --
[Issue 13703] Error 16: Index Range reported incorrectly on windows
https://issues.dlang.org/show_bug.cgi?id=13703 --- Comment #3 from nick nicolas.jincher...@gmail.com --- code was updated with workarounds, and the bug is gone. The last broken commit: https://github.com/bitwise-github/D-Reflection/tree/593993af078d3b3758909cb070c98d0aaf9440bd --
[Issue 13779] gdb can't find frame base when using ld.gold
https://issues.dlang.org/show_bug.cgi?id=13779 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/26fd7e3699d63aa4c8c31bfb024463c9faabfb4b fix Issue 13779 - gdb can't find frame base when using ld.gold - missing relocation addend .debug_info reference to .debug_loc https://github.com/D-Programming-Language/dmd/commit/e7a03fdd3cd0b5acb134edc28f8880a5de1162a8 Merge pull request #4168 from MartinNowak/fix13779 fix Issue 13779 - gdb can't find frame base when using ld.gold --
