Re: Exceptional coding style
On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote: I really cannot understand the obsession computing people have with using monospace fonts, I just assume it is a hang over from the line printer era which created a mindset that most people do not challange. As soon as computers moved from 80x24 terminals to editors with pixel based accuracy and nice fonts I ditched all use of monospace fonts. It's not strictly a computing thing; I've known a few editors who won't work on manuscripts with a proportional font either. (Though I suspect you're familiar with the classic manuscript style guidelines.) Personally, I find monospace makes it much easier to make glyph distinctions and spot errors.
Re: Exceptional coding style
On Tuesday, 15 January 2013 at 18:10:00 UTC, H. S. Teoh wrote: I shall start a new trend of ultra-high monitors! About time more people showed up to this party... ;) Make sure you're getting a panel with VESA mount; many monitors even at the fairly-high end of the spectrum have cheap stands that don't give rotation and height adjustment. My current layout is with the vertical monitor on the left, but I think I prefer it on the right, more.
Re: PDF spec
On Thursday, 24 January 2013 at 06:26:13 UTC, Andrei Alexandrescu
wrote:
There's quite a bit of work left to do, but the PDF spec
already has 386 pages of goodness and starts to look seriously
cool. Take a peek!
This may just be me, but those margins seem just a _little_ bit
excessive. Can we maybe add something like
\usepackage[margin=3cm]{geometry} % ...or 2 or 3.5 or whatever
looks good
to the top matter? (Though I suppose I can also see the argument
for keeping it at around 75-80cpl for readability.)
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
Would everyone be able to agree to only use @property functions
as properties? This would still allow omittable parens as a
way to make call-chaining and ufcs nicer.
I've been thinking and, while it may just be a side effect of my
code style or my own inexperience, I honestly can't think of a
situation where I'd want I'd want to use a non-@property function
as an lvalue as described here.
The limitation this imposes is that
void foo(int a) {...}
void bar(int a, int b) {...}
cannot be called in this way:
foo = 2;
2.bar = 3;
As a consequence, everyone's favorite
writeln = "lolwut";
does not compile.
Do people really do this with any degree of frequency? None of
the examples I've seen read well to me, and readability of code
is an important consideration when we need to represent semantic
meaning with syntactic saccharides.
Re: Ideas for a brand new widget toolkit
On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote: I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases. As Andrei and I have pointed out, NX does a much better job of things. If nothing else, read the explanation of how it works-- there are perceptual subtleties to this that aren't apparent at first glance: http://www.nomachine.com/documents/NX-XProtocolCompression.php What is the latency or bandwidth threshold that X11 needs? They talk a bit about this in the above link, too. -Wyatt
Re: Ideas for a brand new widget toolkit
On Thursday, 15 August 2013 at 18:52:21 UTC, H. S. Teoh wrote: You need to run ssh -C, otherwise it just goes uncompressed plus the overhead of encrypting/decrypting each packet. SSH compression is something of a worst-case scenario for compressing remote X traffic. As a fun aside, for X forwarding on LAN I find -c arcfour offers better performance. -C just slows things down. But yeah, it's not exactly fast. Definitely can't play FPS's over it. :) This... I was going to say it's pretty much impossible, but thinking about it, I'm not so sure. X forwarding uses indirect rendering, which has never given me good performance, but it MAY be possible on modern hardware with good bandwidth, clever compression, and client-side prediction (Something like Frankensteining NX, GGPO, VirtualGL, and ICER together?). Probably not for FPS, so much, but a lot of other semi-realtime applications. Fundamentally, you have to deal with getting a frame up inside of 33 milliseconds, however you do it, and input latency somewhere in the same apartment block as 50ms (else people hem and haw like you wouldn't believe). OnLive, for how they hilariously over-promised on infrastructural matters, looked to have some pretty interesting tech underneath; but they claim to have relied heavily on custom ASICs to pull it off. -Wyatt
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:53:47 UTC, H. S. Teoh wrote: +1. /snip s/\+1/\+2/ to everything. Might encourage me to get back to my own doc stuff. -Wyatt
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 16:19:51 UTC, Dicebot wrote:
Add the built-in t{} syntax to denote all kind of tuples.
This. With an exception of "I don't care what syntax is".
/snip
What was the general attitude to http://wiki.dlang.org/DIP32 ?
I don't like the "t". I'd prefer just using parentheses, but I
think there were readability problems that caused the DIP to end
up with:
"Basic () syntax, perhaps the cleanest, but can't be used:"
Though there's nothing else written about that.
The DIP itself, though, looks pretty good.
-Wyatt
Re: Can we get a forum section devoted to documentation? [dox]
On 8/16/13 10:56 AM, Dicebot wrote: it. I'd probably favor deleting such obsolete groups (dtl, dwt, debugger?) but it is a different topic. Archive, don't delete. On Friday, 16 August 2013 at 18:25:02 UTC, Andre Artus wrote: I understand were you are coming from. And, while I currently feel that it's a bit of a catch-22 situation, I think it is worth at least trying out your suggestion of marking document related threads with "[dox]". For the future, the convention of most mailing lists I've seen is to put the braced tag at the front so you know what it's about immediately. :) -Wyatt
Re: A Discussion of Tuple Syntax
The pattern #(1, ?, ...) would match the two nested sub-tuples. Or, say, #(1, 2, 3) could be matched by #(1, 2, 3), #(1, ?, 3), #(1, ...), etc. You obviously can't refer to "..." as a variable, so it also becomes a useful way of saying "don't care" for multiple items, e.g., #(a, ...) -> only bind the first item in the tuple. We #(a, ...) looks like to me like it would make a 2-tuple containing a and a tuple of "everything else", because of the ellipsis' use in templated code. I think this is a little unclear, so instead I'd prefer #(a, ? ...) (or whatever ends up used for the discard character) to make it explicit. Assuming the "..." syntax for unpacking, it would be useful to name the captured tail. For example, you could unpack #(1, 3, #(4, 6)) into #(a, b, x...), where a = 1, b = 3, x = #(4, 6). Similarly, #(head, rest...) results in head = 1, rest = #(2, #(4, 6)). I think this would be very useful. As a bonus, explicit discard means a simple comma omission is less likely to completely change the meaning of the statement. Compare: #(a, b, ...) //bind the first two elements, discard the rest. #(a, b ...)//bind the first element to a and everything else to b #(a, b, ? ...) //same as the first #(a, b ? ...) //syntax error Granted, there's this case: #(a, ?, ...) ...but that seems like it would be less common just based on how people conventionally order their data structures. Thought: Is there sufficient worth in having different tokens for discarding a single element vs. a range? e.g. #(a, ?, c, * ...) //bind first and third elements; discard the rest // I'm not attached to the asterisk there. // +, #, or @ would also make some amount of sense to me. - Concatenating tuples with ~. This is nice to have, but not particularly important. What does concatenating a tuple actually do? That is: auto a = #(1,2) ~ 3; //Result: a == #(1,2,3), right? auto b = a ~ #(4,5); //Is b == #(1,2,3,#(4,5)) or is b == #(1,2,3,4,5)? This is the third or fourth time that I know of that tuple syntax has come up, and as of yet, nothing has been done about it. I'd really like to get the ball rolling on this, as I think a good syntax for these tuple operations would do D a world of good. I'm not a compiler hacker, unfortunately, so I can't implement it myself as proof of concept... However, I hope that discussing it and working out all the kinks will help pave the way for an actual implementation. Great! After this, let's fix properties. ;) -Wyatt
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 16:57:35 UTC, Dicebot wrote: Check "Token Strings" in http://dlang.org/lex.html Didn't make it to the end of the paragraph? ;)
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:19:11 UTC, bearophile wrote: The ? of regexes is inside strings, so I think it causes no problems. And I think it doesn't clash with the ternary operator because before the ? wildcard you put a comma, a semicolon or a #(. I was primarily addressing the fact that there aren't many _meanings_ attached to the same character. This was brought up before when someone talked about using an asterisk, but it was pointed out that it would be a bad choice because it's already commonly seen in multiplication, pointers, and exponentiation (**). If anything, I'm inclined to think the regex heritage of the question mark improves its case. -Wyatt
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 09:02:29 UTC, Mr. Anonymous wrote:
Why not just leave an empty space, like php does:
$info = array('coffee', 'brown', 'caffeine');
// let's skip to only the third one
list( , , $power) = $info;
echo "I need $power!\n";
Bad idea. It's a visual thing-- quick! How wide is this tuple!?:
#(,frontvar,)
How long did it take you to be SURE that it's a seven-tuple? You
probably aren't even equipped to measure that so don't worry
about answering, but I'm guessing you start to appreciate why
it's a fairly inhumane solution (how drearily typical for PHP).
Ah, but what if it was supposed to be #(,front,var,)? Does
that change your result, now that you're taking the sixth element
rather than the seventh? All you did was forget a comma! By
contrast:
#(?,front,?,?,?,var,?,?) //at least gives us a better chance of
parsing it correctly.
My point here is we are human and we are fallible. The sooner we
acknowledge and internalise that, the better equipped we are to
make systems that don't suck for humans to use.
In that sense, I don't even really like this format because it's
still not especially resilient. Walter's talk about design that
eliminates patterns of human error resonated with me quite
strongly, you see. But in terms of language consistency it's not
much different from array literals, so I could accept it as a
compromise.
-Wyatt
Re: Why I chose D over Ada and Eiffel
On Monday, 19 August 2013 at 21:19:05 UTC, H. S. Teoh wrote: scope guards. If I were granted a wish for how to lessen the pain of coding in C, one of the first things I'd ask for is scope. A little OT at this point, but C Survival Kit might have you sufficiently covered: https://github.com/chadjoan/C-Survival-Kit/blob/master/survival_kit/feature_emulation/scope.h (Been considering pulling this in at work, too.) -Wyatt
Re: [dox] C++ Interfaces
On Tuesday, 20 August 2013 at 08:00:56 UTC, Atash wrote: This link: http://dlang.org/CPP-Interfaces Is made on this page: http://dlang.org/interface.html And I *think* (not sure) that since whatever it was originally pointing to has disappeared, it should probably end up pointing here: http://dlang.org/cpp_interface.html That looks right. Maybe add an anchor to about halfway down the page, so it'd look more like: http://dlang.org/cpp_interface.html#extern-CPP-interfaces Not quite sure why you'd do this. The cpp_interface.html gets to the example meat fairly quickly. Unless you're talking about turning the "Calling Global D Functions From C++" heading into an anchor? In general, you'll find the docs could stand to have a lot more anchors in general. vast wilds of newbie-dom... "What do?" For the time being, I'd make a pull request that changes the link on the interface page to the correct URI. That's the bare minimum. -Wyatt
Re: Download page needs a tidy up
On Thursday, 22 August 2013 at 03:38:26 UTC, Tyler Jameson Little wrote: Do we really want D1 compilers that easily accessable? Considering D1 has an entire site of its own[0], why are they even there? Move them to where they belong with a BIG RED BANNER saying they're EOL and an "are you sure you want this?" confirmation to download them. -Wyatt [0] http://www.digitalmars.com/d/1.0/
Re: Benchmarking a SIMD implementation of dot product
On Wednesday, 21 August 2013 at 21:11:48 UTC, Andrei Alexandrescu wrote: Loosely related question I've always been curious about: are there people who follow this newsgroup but not the announce group? Hi there. I assumed "announce" was for...well, announcements. Like official releases and such. Looking, I'm even sort of correct. Incidentally, it may be kind of cool to aggregate release announcements of various D-related tools into a sidebar of the "Downloads & Tools" page or similar. -Wyatt
Re: DIP45: fixing the dllimport/dllexport issue
On Friday, 30 August 2013 at 06:23:02 UTC, Rainer Schuetze wrote: On 29.08.2013 21:09, Martin Nowak wrote: References from the data segment use absolute relocations. References from PIC code use the GOT. So an indirection through the GOT is added to every access to a non-static global if you compile with -fPIC? My understanding was references using the GOT have the same number of indirections as in the PLT -- that is, a one-time cost for the dynamic linker to dereference and replace an entry with the absolute address -- and the major difference is PLT is done lazily, while GOT is fixed up in its entirety at runtime. Having said that, now I wonder if I'm misunderstanding the question? -Wyatt
Re: obsolete D libraries/modules
On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: Right now, having no way to actually update that site to add a notice to this effect On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt
Re: Had another 48hr game jam this weekend...
On Monday, 2 September 2013 at 03:47:56 UTC, H. S. Teoh wrote: My guess is that gdb actually uses a superset of Dwarf, with its own idiosyncratic extensions that only gcc knows about. This isn't terribly surprising, though ostensibly it shouldn't be doing that unless you use the -ggdb switches[0] (For C, I do actually use -ggdb3 for the macro expansion). -Wyatt [0] http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 13:26:32 UTC, Manu wrote: The part that irks me most is that I have to have yet-another-account-on-the-internet... Does bugzilla support OpenAuth? Haven't seen one for OAuth, but there's a plugin for OpenID: https://github.com/jalcine/bugzilla-openid -Wyatt
Re: [OT]: Memory & Performance
On Tuesday, 3 September 2013 at 16:15:51 UTC, Chris wrote: If you had the choice between: - 4 GB DDR3 SDRAM at 1600MHz - 1 X 4 GB - 8 GB Dual Channel DDR3 SDRAM at 1600MHz - 2 X 4GB ( + $49.00 ) Is it worth the extra money or is the increase in performance not worth mentioning? Any experience with that. The processor 4th Generation Intel® Core™ i7-4700MQ Processor ( 2.4 GHz 6MB L3 Cache - 4 Cores plus Hyperthreading ) Thanks. That's a little pricey for a 4GB DIMM, but the prospect of living with less than 8GB is unfathomable with my usage habits. Do you run a lot of things? Do you use browser tabs? Do you compile code? If the answer to any of these is "yes", more memory will probably help. If nothing else, you benefit from OS caching to memory and not swapping. That's a nice thing to have. -Wyatt
Re: [OT]: Memory & Performance
On Wednesday, 4 September 2013 at 08:48:52 UTC, Chris wrote: On Wednesday, 4 September 2013 at 06:47:15 UTC, Jacob Carlborg wrote: On 2013-09-03 23:10, Chris wrote: The machine I was looking at is this one: https://www.system76.com/laptops/model/gazp9# A laptop! Buy parts a build your own desktop :) You are actually right. I should look into that possibility too, given the pricing policy most companies have. Thanks for the comment. Do you have any tips or useful links? Yeah, if you don't need portability AND lots of power, I still think a desktop is the way to go. For a laptop, I prioritise battery life and weight above all else, these days; if I need heavy lifting, I'll just SSH into my desktop. Best part is, that portable unit only sets you back about the difference between a high-end laptop and its desktop equivalent. If this isn't an urgent purchase, definitely watch for sales and discounts; play your cards right, and you should be able to get a nice Haswell box for about $600 with a display. You've more-or-less missed the US Labour Day sales, so the next big "events" will probably be Halloween, and then Black Friday (which is completely bonkers). Outside of that, weekly specials are...well, weekly (though usually weak). Outside of the big names, pricewatch [0] and slickdeals [1] are probably still useful for finding low prices, though you'll end up chasing across a bunch of different retailers on that path. Another useful tool is the "Camelizer" [2], to see price history for a potential buy. If you let up know roughly where in the world you are, someone else may have some idea of what retailers will let you dodge overseas shipping costs if it's a pressing concern. On to matters of part selection, since it sounds like your first build, some general tips: - As a rule of thumb, if it's a "generic" brand part, avoid it like the plague. If there's one lesson I've learned, you tend to get what you pay for with computer parts (...up to a point. Those 6-core Xeons aren't really priced to move). If you're unsure, look up reviews on Newegg and Amazon. - Don't get _too_ caught up in the numbers. A couple hundred MHz one way or another on a part won't be world-changing. On the other hand you're probably not going to buy a new machine for a few years and my experience is you won't bother upgrading anything but RAM and maybe GPU. - Do make sure to get a decent power supply. A crappy PSU will cause headaches and instability. Pay special attention to the PFC rating: efficient power delivery is good unless you live in a state where electricity is dirt cheap. Also keep an eye out for "Modular" PSUs, which is a nice perk for keeping internal cable clutter low. - Get a decent power supply even if one comes with whatever case you buy (some people don't like their machines to be a pile of parts on the desk. I call them "uninspired" ;) ). The pack-in PSU tends to be awful (as a rule of thumb, if it's not heavier than it looks, it's rubbish). - I'd avoid motherboards from Foxconn, Biostar, and ECS. Budget manufacturers, and I've had poor reliability from them in the past. - For Linux, particularly pay attention to the network hardware on the motherboard. Buying something with Broadcom is playing with fire. Atheros and Intel are your friends. - If you don't need high-end graphics, the on-die Intel or AMD solution should serve well. (It's too bad the Iris Pro trim isn't available on the Haswell desktop parts; that even stacks up favourably against low-mid tier GPUs). - The stock cooler that comes with a modern CPU is actually fairly decent. No need to get an aftermarket version. - A basic cheapo case is plenty for probably 95% of builds. If you can get one with a removable motherboard tray, that's a nice feature, but not essential. - If you need a discrete GPU and you're using Linux, I'd personally look for some kind of fanless Radeon. I find the general driver situation is just better for AMD cards. - There's a lot of fluctuation in display prices right now, but getting one for under a hundred bucks is probably doable. - You probably don't even need an optical device these days. Just boot from a USB stick. Hope that helps! -Wyatt [0] http://www.pricewatch.com/ [1] http://slickdeals.net/ [2] http://us.camelcamelcamel.com/camelizer
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 22:11:52 UTC, H. S. Teoh wrote: On Fri, Sep 13, 2013 at 09:48:05PM +, Justin Whear wrote: I've introduced a few young developers to Vim and the major hole that they tend to fall into is printing out a list of vim "keyboard shortcuts", because that's how other editors work: you memorize a bunch of arbitrary key combinations. So the thing that I emphasize is learning Vim's *language*. Mmm, I like that description! You're right, it's actually a language, not just a bunch of shortcuts. That's why is far more expressive than a shortcut-based editor. You'd need an exponential number of shortcuts just to keep up with all the possibilities -- clearly impractical. I'm surprised this hasn't come up yet: http://stackoverflow.com/a/1220118/432364 Probably one of the more famous SO answers ever. Also, this cheat sheet is pretty much the best: http://www.viemu.com/vi-vim-cheat-sheet.gif -Wyatt
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. vim. Not vi. Not gvim. vim. With TERM=xterm-256color and a small set of plugins. Sometimes in screen. -Wyatt
Re: Improved Phobos dox
On Sunday, 15 September 2013 at 18:02:10 UTC, Andrei Alexandrescu wrote: Sure. My goal with this upgrade is to get rid of the unsightly bag of words at the top of most pages. A few months ago, I made a prototype that turned the "bag of words" into a boxed out vertical list floating at the left. It worked fairly well at all sorts of browser sizes and required zero Javascript. (It will work even better when all the modules have introductory text as mentioned in another thread.) I wonder if I should resurrect that branch? -Wyatt
Re: Improved Phobos dox
On Monday, 16 September 2013 at 13:33:55 UTC, Andrei Alexandrescu wrote: Probably not. The consensus is to got the ddox way, and Walter and myself are on board with it. We're a bit concerned about switching to new tooling (dependencies, bus factor etc) but we think it's worth it. Well, as long as it works (and works WELL) without Javascript, I guess that's a fine start. Though I have to admit the example linked above hurts my eyes. :( (So. Much. White.) -Wyatt
Re: Improved Phobos dox
On Monday, 16 September 2013 at 14:38:25 UTC, Andrei Alexandrescu wrote: Which example? Are you referring to the extra spacing I added between symbols? Turns out I was looking at the wrong version. The current version here looks all right: http://vibed.org/temp/d-programming-language.org/phobos/std/array.html Though I have numerous concerns with having comments on the doc pages, and ESPECIALLY using an external service for them. -Wyatt
Re: Had another 48hr game jam this weekend...
On Wednesday, 18 September 2013 at 11:45:55 UTC, Manu wrote: ? The problem I've always had with make-based build systems is rebuild dependencies... how do any of those build systems go performing a minimal rebuild, As in "only rebuild the files that changed"? In my experience, that comes with using make. Even really ancient versions. or incremental linking? This is a bit harder. If you're using the Gold linker, -Wl,--incremental sounds like your medicine, though I'm not sure if Gold is ready for primetime, yet. -Wyatt
Re: [OT] Which IDE / Editor do you use?
On Wednesday, 18 September 2013 at 18:20:42 UTC, Nick Sabalausky wrote: Dolphin seems to have fixed it's Vista-like goofiness with the folder view's horizontal scrolling, and it really is pretty good for the most part. Dolphin is pretty nice, though there are cases where Konqueror still runs circles around it. For example, if you want a horizontal split or more than one split. Also, I don't think Dolphin has the file size view plugin, which is nice for finding hidden monsters in your ~. The terminal panel is a brilliant idea (never noticed before - maybe it's new since about 4.5ish?). Hehe, this has been around since...at least KDE 3.4 (Before Dolphin was written). The shortcut is F4. :) As of the latest version, Xfce seems to be about the only DE that can handle my side-mounted taskbar worth a darn. Really? I figured Plasma would probably be able to do a decent job. :/ I guess they still haven't gotten it into shape. Have you tried the 4.11 versions? Mint seems to be the best Debian for a desktop I've been hearing good things about aptosid and Mepis lately, too.
Re: [OT] Which IDE / Editor do you use?
On Thursday, 19 September 2013 at 14:27:14 UTC, H. S. Teoh wrote: On Thu, Sep 19, 2013 at 03:04:44PM +0200, Wyatt wrote: [...] Dolphin is pretty nice, though there are cases where Konqueror still runs circles around it. For example, if you want a horizontal split or more than one split. Also, I don't think Dolphin has the file size view plugin, which is nice for finding hidden monsters in your ~. du ~ | sort -r -n | less That's nice if you want the size of _every_ individual file in your home. In kilobytes. It's much less so for visualising where hotspot directories are, let alone seeing the large divisions within them or getting a sense of their relative magnitude. It's accurate, but data that doesn't end with presentation useful for humans is next to worthless. shopt -s dotglob; du -sm ~/* | sort -rn | less ...is a bit closer, but there's a lot of room for improvement. Even the KDE part isn't really optimal (for example, I think reducing the recursion one level would be a better default), but it plays to the strengths of the human visual system markedly better: http://chrisjrob.files.wordpress.com/2011/02/konqueror-file-size-view.png -Wyatt
Re: [OT] Which IDE / Editor do you use?
On Thursday, 19 September 2013 at 14:49:35 UTC, Adam D. Ruppe wrote: actually, I do want some way to transfer files easily. Using scp and so on is kinda a pain, I would like to just cat file > REMOTE_COMPUTER and be done with it. scp is ok if you have keys set up on both sides and they are unix, but when you're on putty and just want to dump a file over to the Windows side, what I'd love is to hit a command and then get a save as prompt on the receiving end. Or, better yet, run a program right on it too. At the lowest level, you could use netcat for this (and like a million other awesome/silly things). An rsync daemon might also pinch hit here. But it sounds like what you really want is a writable CIFS mount. Or sshfs. -Wyatt
Re: Qt Creator and D
On Friday, 20 September 2013 at 07:16:09 UTC, Manu wrote: [...] It needs a reasonable amount of support from the compiler and presumably cooperation from the debugger too. If people have never heard of it, chances are, it doesn't exist :( Google has been hitting close to this: http://www.youtube.com/watch?v=U98rhV6wONo (slides: http://llvm.org/devmtg/2012-04-12/Slides/Manuel_Klimek.pdf) Lot of potential here, even for a die-hard Vim user like myself. Mmmm, a concept that I've always found completely amazing actually. How is it that Linux - truly an OS for developers (certainly not for end-users) - can consistently be plagued by the worst dev tools out there? Surely someone in the past 30-40 years get's frustrated at some stage, looks at what MS have been doing for over a decade, and think "shit, that's awesome, I'd like that too!". I'm actually amazed that MS managed to invent it in the first place. You'd think that Linux should have gotten to it first... Part of this would seem to be the simple fact that the GNU toolchain is the de facto standard for working in Linux and other Unixen. If you've ever encountered a GNU project's general attitude toward patches and ideas from "outsiders", the concerns presented in this SO answer might offer some clarity as to why it's taken so long: http://stackoverflow.com/a/4440794/432364 In short: getting all the people involved to agree on answers to all these questions is sort of a hard problem. (Though it looks like "Fix-and-continue" was added to the GDB roadmap about a year ago: http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=jkratoch.pdf) I agree, I'm really looking forward to what they bring to the table. I expect it's a lot of work though... they have over a decade of catching up to do. Per the links above, they might be closer than it initially appears. Of course, it's also a matter of integration and coordination across multiple projects. There are, occasionally, advantages to monolithic vertically-integrated dictatorships. -Wyatt
Re: Bartosz Milewski seems to like D more than C++ now :)
On Friday, 20 September 2013 at 13:00:49 UTC, H. S. Teoh wrote: [...] It's unfortunate that due to C++ basically giving you a gun that can shoot you in the foot backwards while you're aiming at something else (all convniently abstracted away behind wrappers so you won't even notice the bleeding) This seems apt: "C lets you shoot yourself in the foot. C++ lets you std::anatomy(std::dim::Directions.DOWN, std::anatomy::digits<5>).shoot(this)" --@eevee -Wyatt
Re: [OT] Which IDE / Editor do you use?
On Friday, 20 September 2013 at 03:47:57 UTC, Nick Sabalausky wrote: I got a good way into the first (before I got distracted and stopped), and I find it very impressive considering it's on a system that competed with the NES. That's some classic 6502 vs. Z80 right there. Master System especially set itself apart by having way more memory and better video hardware. In general, Nintendo won by simply having better games (also, I prefer 2A03 sound to SN76489, though the YM2413 on the Mark III smokes both of them on the games that actually use it). But the real kicker with Phantasy Star in particular, is it came out three days _before_ Final Fantasy, yet if you compare them side-by-side it's not even a fair contest. -Wyatt
Re: [OT] Which IDE / Editor do you use?
On Friday, 20 September 2013 at 14:05:20 UTC, JN wrote: On Linux? hah, bad driver will lock you out of the system, installations regularly break. Closing the system? Oh let me just flash random gibberish that looks like memory corruption, then some log messages where it's "FATAL ERROR" every third line. No thanks, I prefer my stable system. You sound like a Fedora user (in which case, you have my condolences).
Re: Debugging support for D - wiki
On Monday, 23 September 2013 at 22:57:27 UTC, Iain Buclaw wrote: GDB doesn't understand D mangling. We currently leverage the use of setting pretty-print names for debugging purposes, but you require to put the names in 'quotation.marks' - I will fix this sometime this year... maybe. :) Ah, is THAT what was wrong when I fired up my debugger? It would be super awesome if that were documented...somewhere. :/ -Wyatt
Re: Move VisualD to github/d-programming-language ?
On Wednesday, 25 September 2013 at 11:54:22 UTC, Dicebot wrote: Given the way they break API it will make sense to stick to current major branch once it gets relatively stable and just ignore newer releases. Bleeding edge distros will be dissapointed but MonoDevelop guys push it far out of the limits of reasonable bleeding edge. For what it's worth, even our Gentoo maintainers have apparently gotten fed up with their crap. There are two versions in the main Portage tree right now: 2.8.5.1 and 3.0.2-r1. Both are marked stable. Make of that what you will. -Wyatt
Re: D2 is really that stable as it is claimed to be?
On Wednesday, 25 September 2013 at 03:10:20 UTC, Walter Bright wrote: And, dmd users are often dmc users. Are they, still? I can't speak for everyone, but I know I've never used it. I wish I had had it for precisely the feature in question when I was first learning C, even though it would have spoiled me on other compilers until...2013, apparently. :/ Since dmd never had it, and dmc did, wouldn't anyone have suggested "hey, I like this dmc feature, why not put it in dmd?" But nope. In the few compilers I've used that had it, I've never begrudged its existence; it's usually been helpful, and never harmful. You could say I like it because it offers proper visualisation of the data. I didn't realise it was moving from "rare, nice perk" to "in-demand standard feature" until this thread. -Wyatt
Re: dub: should we make it the de jure package manager for D?
On Thursday, 26 September 2013 at 14:20:53 UTC, Bruno Medeiros wrote: To be fair, I don't entirely agree with this. End user distribution/installation doesn't have to be system-specific. I can see many interesting and useful use-cases for a cross-platform user application package manager. It might be a real cool project if done properly. That's CPAN. You just described CPAN. It supports both system and user level package installing, bails properly when build deps are missing, and has enough metadata that we can support it from the system package manager for proper system-level depgraph and file tracking. If there's a wheel we want to steal or reinvent, this is THE one. But I think it's important to remember it would be complete cat puke like ruby packaging if they didn't have PAUSE [0]; clear, moderately-strict submission guidelines [1] (especially for newcomers); and PrePAN, for feedback and discussion BEFORE it goes up. The latter, and community involvement in general, is possibly the most important aspect of this process because the community is ultimately your userbase. (It's not so knock-down/drag-out as Phobos module reviews, but it's a great source of sanity checking.[2]) -Wyatt [0] http://www.cpan.org/modules/04pause.html Recommend reading the whole thing. [1] http://search.cpan.org/~rjbs/perl-5.18.1/pod/perlnewmod.pod [2] http://prepan.org/module/nXWJ8Y9sBtw A good recent example
Re: dub: should we make it the de jure package manager for D?
On Friday, 27 September 2013 at 13:03:20 UTC, Dicebot wrote: On Friday, 27 September 2013 at 13:00:58 UTC, Wyatt wrote: ... afaik CPAN mixes development packages and distribution packages too, which I doubt is desired. It may be unfortunate consequence of Perl interpreted nature though. Unless we're talking about different things, that's denoted in the META.json (I don't recall if the distinction existed in the META.yaml era) with e.g. "release_status" : "stable", or "release_status" : "testing", A proper tool can (and will) filter for this by default. And to be explicitly clear, I'm not saying it's perfect for us as-is (or even perfect in general). They're just the model citizen to take after. -Wyatt
Re: dub: should we make it the de jure package manager for D?
Funny, I started this with a clear mindset, but it ended up more nuanced than I expected. On Friday, 27 September 2013 at 13:43:59 UTC, Dicebot wrote: No, I mean that it does not make any difference between "programs written in perl to be widely used" and "libraries / tools for development in perl". For interpreted languages this distinction hardly makes sense, but for natively compiled ones it is pretty important. That's true, though at some level I wonder if its continued prevalence more comes back to CPAN supporting system and local-to-user installation simultaneously. Users have been adding ~/bin to their $PATH since $EPOCH. And that was kind of the core point of the argument - can language-specific package manager be allowed to manage the former? Not at the system level, it probably shouldn't. Ideally, binary executables and libraries are the exclusive demesne of the system package manager. As a historical footnote, I suspect part of why CPAN works the way it does is it was designed and (I think) released before RPM was even written. (It may even predate the original dpkg.) More important than long precedent, though: Perl is largely self-contained by default, and can be made completely so [0]. In some sense, I _like_ the idea of installing module source to e.g. /usr/lib64/d2/site_d/2.63/ as long as dub is built into a normal install (control env with a config file in ~) and let it update the user's dmd.conf as a value-add [1]. I stand by the point that is a bad practice to provide any functionality that allows it, Jacob has opposite point of view :) I... turns out I have mixed feelings on this. In the general sense, I'm strongly inclined to agree with you. External package management undermines the sysadmin's ability to make good package installation decisions, splits the system dependency graph, and can create file conflicts. But on the other hand, as long as there are sufficient options (preferable), a utility, or an API to interrogate dub for complete useful metadata; I'll refrain from getting too vehement about it. This is only because that means system package managers _can_ properly integrate it, should they choose to do so. (cf. g-cpan [2]) See, I have my standards as a sysadmin, but don't forget policy victims, either: many others are stuck dealing with a CErtaiN Terrible Old diStribution and would probably appreciate a tool that isn't stuck mired in Really HorriblE poLicy when they're trying to get work done. [3] My breaking point is actually the idea of using dub to call the system package manager, which I still think is a Really Bad Idea. [4] -Wyatt [0] Consider the output of perl '-V:.*site.*' and the existence of Perlbrew (http://perlbrew.pl/) [1] As a tangent, a nice separate utility to have might be something like a "dub-config" to help with module paths and maybe linkage (In the vein of all those /usr/bin/*-config things). Like so: dmd `dub-config --moddir vibed` thisLinksVibe.d. [2] http://www.gentoo.org/proj/en/perl/g-cpan.xml [3] Yes, juvenile RHELL potshots make me feel a little better about my situation. [4] https://github.com/rejectedsoftware/dub/issues/52
Re: Can we please kill the hyphenator already?
On Tuesday, 1 October 2013 at 11:58:35 UTC, w0rp wrote: PHP-style documentation in general I look forward to, but I won't push for that. I know Andrei is a busy guy. PHP, the bad language with good documentation. PHP? The language that has a comment peanut gallery on every page? Oh god, no. Please don't tell me people actually want that.
Re: Can we please kill the hyphenator already?
On Tuesday, 1 October 2013 at 20:52:22 UTC, Nick Sabalausky wrote: Heh, yea. But OTOH, it can be a good way for community members to easily point out any errors/omissions/gotchas in the docs. I wish I were as optimistic, but unless the comment system ends up sticking its stuff in some section of the NG it's just going to become a burden (and even then I think it'd be suboptimal). Laundry list of misgivings: - Every doc page will need moderated against spammers and unsavory folk (and they're getting really clever these days). - It fragments the quality help people get from e.g. D.learn, instead placing questions in out-of-the way places where they'll languish for months or years (cf. http://xkcd.com/979/). - It makes it harder to notice trends in the problems people have that hint at language flaws we can address (like TypeTuple). - The questions that do get answered have a decent chance of being answered by someone with an incomplete understanding of the problem space, which will accrete a bunch of non-functioning half-solutions. - The responses become stale over time as the docs change, so you end up with comments that don't mesh with reality fairly easily (we're not stable by a long shot, even semantically). There's the argument that there might be some "really good" comments made, but to me that situation is more of a _bug_ reflecting a deficiency in our docs (a good example: http://www.php.net/manual/en/security.database.sql-injection.php). -Wyatt PS: And if it wasn't clear, the idea of using Disqus or some other external thing should be right out.
Re: Can we please kill the hyphenator already?
On Wednesday, 2 October 2013 at 17:48:13 UTC, Tourist wrote: I don't agree - I often find comments in the PHP documentation helpful, both for clarifying things and for useful snippets. We have D.learn for clarification. Comments clarifying the docs are a bug. You could say snippets go in comments, but in the first place people WILL misuse and abuse them for other things. What are you going to do? Delete the questions? Tell them to go to D.learn? Heaven forbid you ANSWER it! That just encourages them. And what if it goes off-topic? Is there ever a "right time" to discuss array semantics in the std.string.chomp docs? Doesn't matter; it'll happen. But even presuming we keep this a utopian column of code spew... well, take a stroll through stackoverflow. You know what you find? A lot of commenters who don't have much clue on the quality of their snippets. Alas, "Thanks, this worked" and up the vote goes, regardless of whether or not it's incredibly fragile. It's a "blind leading the blind" scenario. (http://i.stack.imgur.com/ssRUr.gif) And again: if it's a solid, clean, idiomatic use case scenario, it should probably be canonised in the docs. That's one big advantage TO switching to a page-per-function model: we can do that and not end up with million-line pages. As for moderation, disqus has a voting system, and displays most voted comments on top by default, which is IMO good enough. Disqus is the worst idea of all because Disqus is external infrastructure under someone else's control. When -- not "if" -- Disqus dies (goes belly-up, or gets acquired, or otherwise fails critically at existence), what do you suppose happens to the people who used it everywhere? Sure, they have an XML export format. I couldn't find their DTD posted anywhere, so have fun making heads or tails of it. Presuming you have the time for exporting. If you don't, well... you're boned, good game, peace out? Not acceptable. Not even remotely. Also, a Javascript monstrosity. Also, voting does not preclude the need for moderation. -Wyatt
Re: dub: should we make it the de jure package manager for D?
On Tuesday, 8 October 2013 at 10:18:03 UTC, Bruno Medeiros wrote: I would only consider a cross-platform user application package manager to be interesting (that is, useful to a significant level) if it's not tied to any particular language (or platform). ...Oh, you're looking for Gentoo Prefix. Got it. Here you go: http://www.gentoo.org/proj/en/gentoo-alt/prefix/ :) -Wyatt
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:29:21 UTC, Craig Dillabaugh wrote: The is also an under construction tutorial: http://beza1e1.tuxen.de/d-tut-0.1/index.html which looks promising, but is far from complete. As an addendum, this one is a neat example of how things can come together in real code: http://wiki.dlang.org/Component_programming_with_ranges Shows off ranges and some other nifty features. -Wyatt
Re: Safe mode in D?
On Friday, 18 October 2013 at 10:03:03 UTC, Maxim Fomin wrote: portable), but you can enable treating nulls as exception in linux if you use etc.linux.memoryerrors. Oh. This exists. Don't suppose there were any plans to document it? -Wyatt
Re: Should we distribute a Dutmite binary in the zipped package?
On Sunday, 20 October 2013 at 12:16:14 UTC, Andrej Mitrovic wrote: ...it's strange how many people don't even know it exists... No it isn't. Look a this page: http://dlang.org/download.html Now, look at all the pages under "Compilers & Tools" here: http://wiki.dlang.org/The_D_Programming_Language How do you expect people to find out about tools if they're not even so much as mentioned in the places you'd go to find tools? People don't know about things that aren't documented. Full stop. -Wyatt
Re: Should we distribute a Dutmite binary in the zipped package?
On Monday, 21 October 2013 at 08:17:49 UTC, Andrej Mitrovic wrote: On 10/21/13, Wyatt wrote: On Sunday, 20 October 2013 at 12:16:14 UTC, Andrej Mitrovic wrote: ...it's strange how many people don't even know it exists... No it isn't. What isn't? I'm just reporting on user experience here. John Colvin got it, but I'll confirm: It's not at all strange or unusual that an undocumented tool isn't well-known. It doesn't matter that it's in the tools repository or tucked away on some non-obvious page of the wiki. If people don't see it in the first two places we expect them to look, then it may as well not exist to a lot of them. I agree it should be added to the release tarball, but even that won't necessarily improve its visibility. How often do you look for new things with strange names added to /usr/bin alongside the binaries you're actually using? So I'll go a little further: not only should it be on the tooling-related pages, it should also be mentioned and linked in any place where we talk about reporting bugs, including the homepage of the bug tracker. -Wyatt
Re: More on C++ stack arrays
On Monday, 21 October 2013 at 15:26:33 UTC, Denis Shelomovskij wrote: So I'd prefer to change default stack allocation size if needed and not confuse user with manual choice. Wouldn't it work to make it optional then? Something like this, I think: auto tempCString(To = char, From, Length = 1024)(in From[] str) if (isSomeChar!To && isSomeChar!From); Choosing a sane default but allowing specialist users an easy way to fine-tune it for their needs while keeping the basic usage simple is something I'd advocate for. (Personally, I think 1K sounds quite high; I'd probably make it 256 (one less than the max length of filenames on a whole bunch of filesystems)). -Wyatt
[dox] What should we do with dsource?
I remember it came up a couple times last month as a point of contention, so I got in touch with Brad about dsource. Graciously, he says he's willing to "entertain just about anything", and left it to the community to decide its fate. This is up to and including passing it off to someone else. It's still very high in D language search results (e.g. there are disadvantages to simply canning it), and it still hosts planet and a lot of other stuff. So, as the topic asks: what should be done with it? -Wyatt
Re: [dox] What should we do with dsource?
On Thursday, 24 October 2013 at 05:13:55 UTC, Jesse Phillips wrote: I'd rather start with more permissions to update the homepage. So for the time being shall we do just that? Something along the lines of Dicebot's suggestion is good as at least a temporary solution (not permanent or comprehensive unless it's on EVERY page). If you're willing, I'll tell Brad to get in touch with you and Mike Parker, and let things proceed from there. -Wyatt
Re: [dox] What should we do with dsource?
On Wednesday, 23 October 2013 at 05:21:19 UTC, Mike Parker wrote: My thinking of what this should entail: 1) take over the dsource.org domain and point it to a new server 2) the new site should provide free forums just as the current one does, but nothing more. 3) existing projects still using the forums at the current site should be migrated. 4) existing projects still actively maintaining a subversion repository at the current site should be encouraged to move to another scc hosting solution of their choice (github, bitbucket, whatever). 5) the new site should maintain a searchable registry of all known open source D projects (just a link and a blurb), regardless of whether or not the project uses the forum. Good medium/long-term plan. For the moment, let's see about cleaning up what we've already got, but I like a lot of this. In other words, a complete overhaul. Of course, the few people still using dsource would need to agree to this. Even if they don't, I think this sort of site should exist. It would be a centralized location for all D projects. I would much prefer it to be under the dsource.org domain, since then all of the dead projects there will eventually fall off of the search engines. This is good, with the caveat that we should avoid inconveniencing the people already there within reason. So in that direction, I'd advocate for Cool URIs [0]-- as few page addresses should change as possible. (Some things are more sacred than others. Hosted project landing pages are very important, but the stuff in the robots.txt is much less likely to be externally linked.) Per a suggestion above, I think it'd be fine to link them from an "archive" or "mothballed" page or something (for things that are no longer active). Of course, I'd be willing to pay for a basic Linode instance, or pitch-in for a more expensive one. Appreciated, but hold that thought for now; it may be unnecessary. I'd also be willing to donate a few hours a week to maintenance in whatever capacity I could. This, on the other hand, will probably be very welcome. -Wyatt [0] http://www.w3.org/Provider/Style/URI.html
Re: [dox] What should we do with dsource?
On Thursday, 24 October 2013 at 13:16:15 UTC, Dicebot wrote: On Thursday, 24 October 2013 at 12:56:53 UTC, Wyatt wrote: Good medium/long-term plan. For the moment, let's see about cleaning up what we've already got, but I like a lot of this. I also wanted to mention that this is long-term development plan for dub registry too (at least Sonke has expressed certain interest in it in private mail discussion), so lets try to avoid effort duplication :) Which points does that cover? And how does that even work? Unless I've missed something, the registry is the package repository. -Wyatt
Re: Empty VS null array?
On Friday, 25 October 2013 at 11:41:38 UTC, Kagamin wrote: That's an implementation detail which has no meaning for business logic. I've no real truck in this, but I do find it pretty bizarre to see _anyone_ using "business logic" as justification for anything here when D's own documentation is pretty explicit about not catering exclusively to that domain. -Wyatt
Re: Everyone who writes safety critical software should read this
On Thursday, 31 October 2013 at 03:27:23 UTC, H. S. Teoh wrote: Wow. No bug tracker?? That's just insane. How do they keep track of anything?? That describes my day job. To answer: we kind of...don't. ¬_¬ I'm in legacy maintenance too, so the lack of documentation of even known issues is incredibly frustrating. I'm trying to change that, but there's a lot of inertia from the people who've been around for 20+ years. Forget testing; just figuring out the maintainer for a tree is an adventure. -Wyatt
Re: ctrl+c and destructors
On Thursday, 31 October 2013 at 22:20:23 UTC, Timon Gehr wrote: I'm not sure. Excerpt from the iTunes EULA: "You also agree that you will not use these products for any purposes prohibited by United States law, including, without limitation, the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons." http://www.apple.com/legal/internet-services/itunes/appstore/dev/stdeula/ I would classify forcing someone to use iTunes as "psychological warfare". Unfortunately, that's not covered by the EULA. ;) -Wyatt
Re: Expanding the horizons of D purity
On Friday, 1 November 2013 at 11:45:23 UTC, Timon Gehr wrote: return (y)pure=x=y; Drifting off topic a little, but how does this expression work? I can't recall having seen the (y)pure thing before. -Wyatt
Re: Everyone who writes safety critical software should read this
On Saturday, 2 November 2013 at 04:06:46 UTC, Walter Bright wrote: On 11/1/2013 6:52 AM, Wyatt wrote: "We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. Although it is tempting to do so, creating a culture of "blame the programmer" for the mistakes he's made also creates a culture of denial of problems. If you want to create quality of software, a far better culture is one that recognizes that people are imperfect, and looks for collaborative ways to engineer the possibility of errors out of the system. That doesn't work if you're trying to pin the blame on somebody. My reading was less that an error should be hauled out as an indictment of the individual who made it and more that we should collectively be more cognizant of our own fallible nature and accept that that affects the work we do. In that vein the _who_ is less important than the explicit understanding that some human (probably me) mucked up. Of course, I tend to read EWD with a fair bit of fabric softener- he was a grumpy old man on a mission. Though even with the more literal interpretation, I'm not sure I agree that necessarily has to be negative. If I'm in error, I honestly _want_ to know. How it's conveyed is a function of the culture that can make it a positive (learning) experience or a negative one. -Wyatt
Maintain notes for D's successor? [Was: Re: Why the @ in @safe? & UDAs]
On Thursday, 7 November 2013 at 22:16:43 UTC, Dicebot wrote: Of course, good stuff is still worth discussing - language design moves forward and D3 is inevitable, whatever Walter intention here is. There are already D derivatives that do experiment in that domain trying to build on D experience foundation in the very same way as D did on top of C/C++. This raises a question for me: should we perhaps take a page from X.org [0] and document all the niggling finer points of what the "next D" should be or not be? It's not gospel (and in the case of X12, may never actually happen), but it's still a useful reflection point and consolidation of the various disparate "should have done" things. Like pure/safe/immutable holes, virtual/final, what the various forks [1] and experiments [2] are and why they exist, etc. These points come up in conversations, but as we eschew breaking changes with ever-greater fervour, we should still make note of them. They don't need to be DIPs (though some of the ones in limbo would be valuable additions [3]), or even extensively described. If nothing else, it'd be a list of issues we're aware of that could be "better" (like the one in the parent thread) to direct people toward. A succinct history "why this one part sucks". -Wyatt [0] http://www.x.org/wiki/Development/X12/ [1] https://github.com/FeepingCreature/fcc [2] https://github.com/VoltLang [3] http://wiki.dlang.org/DIP23 No, I won't ever give up. This is important. :<
Re: Maintain notes for D's successor? [Was: Re: Why the @ in @safe? & UDAs]
On Friday, 8 November 2013 at 14:12:04 UTC, Timon Gehr wrote: See http://wiki.dlang.org/DIP24 (TLDR: The full proposal makes @properties behave like ordinary variables except that their address cannot be taken and there could be more postblit/destructor invocations in a given expression. There is a __traits to get the underlying getter/setter function symbols for properties.) Oh, right, that one. Whoops. DIP23 was just the flashpoint for the most recent braw^w discussion. There were like four, but I just grabbed the link for the one that "looked sorta right" without rereading. My bad. :V The point is properties are a furball and need to be fixed, so I'll keep making noise about it from time to time. -Wyatt
Re: Maintain notes for D's successor? [Was: Re: Why the @ in @safe? & UDAs]
On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote: "Thread hijacking" achievement unlocked ;) Now, now, I changed the title. If this were a proper hijack, I'd be trying to extract a ransom (like fixed AAs). ;) On topic of such wiki page - it is kind of nice to have but lot of potential entries are controversial and need some serious discussion (for example, I'd place optional parens there as damaging mistake but reasonable people will disagree :P) before being documented. It risks being biased to preferences of view editors or turn into edit wards :) I don't know what is a good way to do this without devoting too much efforts. I don't think it needs to be that strict. Optional parentheses are something that there are mixed opinions on, so that should be noted. It may be better to think of it as "things to reconsider in the next version"-- discuss later, once we have a lot more time with the current stuff and it's actually TIME to hash out the future. "Not gospel" means it's okay for things like that to be in there. Heck, compare the vision for X12 with what Wayland [0] is actually shaping up to be: they're...rather different. ;) (I'm aware that being "the next X11" wasn't Kristian's goal and it was originally an experiment to be folded into X.org, but reality is weird.) -Wyatt [0] http://wayland.freedesktop.org/architecture.html
Re: Applications that created on D Programming
On Friday, 8 November 2013 at 06:17:09 UTC, Marcin Mstowski wrote: http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html Torus Trooper, but it is very, very old (D ver. 0.110). I was recently thinking about trying to get that to build in modern D. Might poke at it this weekend if the person I've assigned to remind me about it remembers to remind me. ;) -Wyatt
Re: Thoughts about D package management on Gentoo
I'm falling asleep here, but before I go... On Saturday, 9 November 2013 at 00:38:16 UTC, Marco Leise wrote: "dub" which don't integrate with the official package managers. With the right functionality, we could do this similarly to how we hook CPAN.pm for g-cpan. If nothing else, it could be done a damn sight more reliably than Diego's gem eclass if we get this squared away sooner than later. (This is a weird space, though.) When I decide to install a D application on Gentoo, I want it to just work. For Gentoo that includes the choice of compiler to build it and the used compilation flags. The package manager should handle installing LLVM, the latest stable LDC and required libraries on top of that and finally the application. For a long time, GDC was just a USE flag on GCC. Not sure what the current state is because I've been trying to ignore the sad state of our D packaging in hopes that it would go away. (How many D overlays have we killed at this point anyway?) - Compiler and library are closely coupled and depend on each other. So we'll need a virtual for "the D implementation"? cf. virtual/package-manager and dozens of others. - Each new D point release brings a new, generally incompatible standard library. Unless I've misunderstood completely, the compiler, runtime, and standard library are ostensibly separable, but for the foreseeable future they need to be revbumped in lockstep for this reason. No biggie. cf. kde-base/* - All three major compiler backends are in good shape and use. But their generated code is not exchangeable (as far as I've heard due to ABI differences). Do they? I thought this had been worked out. - Tools tend to expect that "dmd" is available as a command. Which tools? Quantify the problem, and we may be able to fix it. (We have like all of upstream right here...;) To deal with the complexity of package dependency management in this scenario, we need to be able to install multiple versions of D compilers in parallel (similar to what dvm does). Do we really? Not necessarily disagreeing, but I think this needs substantiation. This can be accomplished by so called "slots" for each point release. We can do this for all three compilers and will end up with binaries like "dmd2.064" and "gdc2.063". See, I'd like to avoid the awful version creep we see with GCC-- that only exists because we're trying to provide an upgrade path for lazy people who never upgrade (never mind that it's never really worked well). Thankfully RAP may finally be fixing that, now that Benda is joining the toolchain herd. Next a symlink should be established to the current implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2. This symlink could be managed with an eselect plugin as it is already done for other languages like Python or the Java Runtime. I'm so not fond of those, but it looks like we may not have a choice. Do we have any use for an env.d entry here? Since libraries for D depend not only on druntime/Phobos, but also on the compiler the Gentoo user should be able to setup globally and for each library which compilers it should work with. It's way too early for this shade of bikeshedding. Let's see about actually getting packages in the tree, first. (The approach may or may not be a good fit. I think we should give it some time to settle first, though.) -Wyatt
Re: Thoughts about D package management on Gentoo
On Monday, 11 November 2013 at 05:21:22 UTC, Marco Leise wrote: Does anyone have an idea how to go about GDC, especially once the D front-end is integrated? Since GCC installations are configured with gcc-config, there is a conflict for "eselect dlang". To clarify, gcc-config copies the executables from /usr/x86_64-pc-linux-gnu/gcc-bin//* to /usr/bin/* I guess I should just stick to DMD and LDC for it then? By the way "dc" is already the name of an arbitrary precision expression evaluator and cannot be used for a symlink to the D compiler of choice. :p On this point, it may be time to get on Freenode and hit up #gentoo-dev-help and see what they say. Off the top of my head, EAPI 2 introduced USE deps, so you may be able to get away with specifying sys-devel/gcc[d] as fulfilling your virtual. As far as eselect goes, I would use that only for fixing up the environment and the paths in sc.ini (and the primary compiler symlink, if you choose to go that route). I'm not familiar with the guts of it, but from what I've been told, an eselect module for gcc has been tried several times, but has always met unfortunate circumstances. -Wyatt
Re: Thoughts about D package management on Gentoo
On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:
Yeah, and they hopefully don't use Gentoo... maybe it is time
to drop that version if it causes trouble. I'll try to have
at least an dmd-1.076 ebuild though. It is also a good test
for the whole multiple versions at once idea.
See, this is one of those times where it might have been nice if
D2 had gone with dmd2 for its binary name. Regardless, if you
want to support D1, make it a slot, and mask it for all arches--
we don't exactly want to encourage its use at this point, IMO.
This would be in the same general vein as dev-lang/dmd-bin (in
the main tree, but terribly out-of-date).
Now, if it does get installed...an idea, though not a great one:
If you look at mplayer and mplayer2, they both install roughly
the same stuff to the same locations in their default
distribution. i.e. the binary is called mplayer in both the
original and the fork. So what happens in
media-video/mplayer{,2} is mplayer2's stuff is renamed to match
the $PN and there's an IUSE+=" symlink". The symlink flag causes
portage to install symlinks to the original mplayer stuff for
transparent compatibility with various frontends and other stuff.
Too many smilies, hehe. Well, it should be possible to have at
least one installable version of every package at any time.
Unless that package hasn't been updated for 10 months or so.
I don't want to run into a situation where you can't update
dmd because some application isn't updated or where I do
update dmd early and D programs can't be installed any longer
until they work with that latest version of D.
My understanding was we were fixing the soname versioning for
phobos, so this should theoretically be caught by
@preserved-rebuild or revdep-rebuild. Was I incorrect?
Yep. I thought of it as an opt-in symlink in case dmd isn't
installed, so it could be emulated with gdmd or ldmd2.
/bin/dmd -> /usr/bin/dmd might also be an option for that...
Nah, I'll see what might be required by some tools.
I wonder at what point a d.eclass needs to be made to negotiate
all of this; I'm really not sure. On that note, you may want to
watch out for degenerate cases like packages trying to select a
preferred compiler, just in case.
-Wyatt
Re: Bug in DMD 2.064 RC1. Issue tracking system not very intuitive.
On Monday, 11 November 2013 at 16:47:25 UTC, Tor Einar Tønnessen wrote: Maybe I used a wrong system? I used "https://d.puremagic.com/issues/request.cgi."; Right site, wrong area. :) Up in the top bar, there's a link called "New" (second from the left) that takes you here: https://d.puremagic.com/issues/enter_bug.cgi On the bug tracker home page (https://d.puremagic.com/issues/), there's also a big green button titled "File an Issue" that goes to the same. -Wyatt
Re: DIP 50 - AST macros
On Tuesday, 12 November 2013 at 09:20:07 UTC, Walter Bright wrote:
5. We've said "no" in the past to things like user-defined
tokens, which are closely related.
Regarding this point, I get that arbitrary expansion is out, but
would you be amenable to adding a small, _strictly-defined_ set
of operators that are compile-time errors unless overloaded?
#define BEGIN {
#define END }
macros used in old C code to make it look like Pascal.
A plague o' their houses!
-Wyatt
Re: Build Master: Scheduling
On Thursday, 14 November 2013 at 05:05:39 UTC, Tyro[17] wrote: It's been approximately six months since the release of 2.063 (alright five+: May 28 to Nov 5). I don't think too many of us lost sleep over that. There is nothing ridiculously long about six months. I'm not using HEAD either and its annoying having to wait for updates with useful fixes and changes. Also, longer cycles means more breakage for people who run the "stable" release. What I am proposing is that you get a package every month. That should be enough time to ferry out any regression that may crop up. Use the betas on a monthly basis and you get to ride the bullet train. The problem here is the beta becomes the de facto stable because people want to be able to use the new things that the documentation says they can and the breakage is amortised over months, rather than coming in a huge spike every half year. This really needs to be avoided. If you look at the movement of active projects in the past few years, most seem to be settling on shorter release cycles for similar reasons. -Wyatt
Re: Why UTF-8/16 character encodings?
On Sunday, 26 May 2013 at 21:23:44 UTC, H. S. Teoh wrote: I have been thinking about this idea of a "reprogrammable keyboard", in that the keys are either a fixed layout with LCD labels on each key, or perhaps the whole thing is a long touchscreen, that allows arbitrary relabelling of keys (or, in the latter case, complete dynamic reconfiguration of layout). There would be some convenient way to switch between layouts, say a scrolling sidebar or roller dial of some sort, so you could, in theory, type Unicode directly. I haven't been able to refine this into an actual, implementable idea, though. I've given this domain a fair bit of thought, and from my perspective you want to throw hardware at a software problem. Have you ever used a Japanese input method? They're sort of a good exemplar here, wherein you type a sequence and then hit space to cycle through possible ways of writing it. So "ame" can become, あめ, 雨, 飴, etc. Right now, in addition to my learning, I also use it for things like α (アルファ) and Δ (デルタ). It's limited, but...usable, I guess. Sort of. The other end of this is TeX, which was designed around the idea of composing scientific texts with a high degree of control and flexibility. Specialty characters are inserted with backslash-escapes, like \alpha, \beta, etc. Now combine the two: An input method that outputs as usual, until you enter a character code which is substituted in real time to what you actually want. Example: "values of \beta will give rise to dom!" composes as "values of β will give rise to dom!" No hardware required; just a smarter IME. Like maybe this one: http://www.andonyar.com/rec/2008-03/mathinput/ (I'm honestly not yet sure how mature or usable that one is as I'm a UIM user, but it does serve as a proof of concept).
Re: minifying the website
On Friday, 31 May 2013 at 17:12:11 UTC, Andrei Alexandrescu wrote: Hello, I've been looking through the logs and it looks like the top files in bytes transferred yesterday (even with the deluge of downloads) were a number of Javascript, HTML, and CSS files. There are programs to reduce the size of such files called "minifiers". Should we use some? If so, what would the experts recommend? We'd need ideally some command line utility that we can deploy easily and integrate with the build process. Alternatively, an online service could fit the bill, too. I may be in the minority in this, but I would prefer if some of that were just removed entirely. In particular, the code-running doohickey that doesn't even work needs to die for the pathological behaviour it gives on Firefox. For example http://dlang.org/phobos/std_algorithm.html hung my browser for almost twenty seconds with a blank coloured background. This is on an i5 at work and my i7 at home, with or without extensions. I can't even imagine how my old laptop would cope. To add insult to injury, it displayed the page without the JS for almost a second before disappearing. I'm fine with some light JS that makes the documentation more usable or useful; this makes it practically unusable unless I have access to NoScript.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 05:59:00 UTC, H. S. Teoh wrote: In spite of it all, though, we still sometimes end up hiring people who, 6 months down the road, write code that makes you scratch your head going "huh?! that genius coder we hired wrote *this* junk?!". But maybe some hiring managers are less discerning than others. *shrug* In my (admittedly U.S.-centric) experience: if you're getting people who know how to use external libraries, what a debugger is, more than one programming language (or, indeed, any language other than Java), and any form of source control at all, I'm afraid you're hitting among the cream of the crop as far as CS baccalaureates go. And if you want them to admin a box at the same time, good luck with that. You're often better off with a passionate dropout if you're interested in hiring someone to write code. My hypothesis is this happens because the curricula are heavily skewed toward theoretical aspects of computer science. (In my view, the exemplar for this was OSU before they axed the mandatory RESOLVE/C++ series.) Cheers, Wyatt
Re: Time to split up std.datetime into a package?
On Thursday, 20 June 2013 at 18:54:20 UTC, Jonathan M Davis wrote: IMHO, the obvious split (and what I've wanted to do for some time) is std/datetime/common.d std/datetime/interval.d std/datetime/timepoint.d std/datetime/timezone.d common would primarily have the free functions; interval would have the three interval types and their related range stuff; timepoint would have all four of the time point types (SysTime, DateTime, Date, and TimeOfDay); and timezone would have the time zone types. If possible, I'd like to have a separate submodule for the StopWatch/Benchmarking stuff; that's probably more than 90% of what I use std.datetime for. Even if importing std.datetime.stopwatch ends up pulling most of the rest implicitly, I think the improvement to the documentation alone would be worthwhile. Cheers, Wyatt
Re: top time wasters in DMD, as reported by gprof
On Tuesday, 25 June 2013 at 06:46:54 UTC, Marco Leise wrote: Am Mon, 24 Jun 2013 21:01:36 +0200 schrieb Martin Nowak : On 06/24/2013 08:43 PM, Martin Nowak wrote: > > I can try to install kernel debuginfo that 12% might contain > some useful > information. http://codepad.org/gWrGvm40 Interesting. So to troll a bit, do I see it right, that dmd is mostly a Unicode conversion and memory allocation tool ? Maybe not DMD, so much as GNU ld? Whatever the case, I'm not surprised to see their iconv that high up in the list; in my experience, it's horrifically slow. Ah, and a fun question: does that number change significantly when you modify your locale variables? (I think it should be enough to just export LC_CTYPE="C".) -Wyatt
Re: Feature request: Path append operators for strings
On Tuesday, 2 July 2013 at 22:28:24 UTC, TommiT wrote: On Tuesday, 2 July 2013 at 21:48:54 UTC, Walter Bright wrote: On 7/2/2013 1:47 PM, TommiT wrote: Division operator for strings doesn't make any sense, That's why overloading / to do something completely unrelated to division is anti-ethical to writing understandable code. The classic example of this is the overloading of << and >> for stream operations in C++. I've never thought of it like that. At some point I remember writing a vector type which overloaded its binary * operator to mean dot product (or cross product, I can't remember). So, you can overload an operator, but you can't overload the meaning of an operator. This is something I was discussing with a friend recently, and we agreed it would be cool if there were set of operators with no definition until overloaded, so you could use e.g. (.) for dot product, (*) for cross product, (+) (or maybe [+]?) for matrix add, etc. instead of overloading things that already have specific, well-understood meaning. -Wyatt
Re: Feature request: Path append operators for strings
On Wednesday, 3 July 2013 at 12:45:53 UTC, TommiT wrote: I don't see why we couldn't add the actual unicode ∙ and × characters to the language, make them operators and give them the fixed meaning of dot product and cross product respectively. Wouldn't + be the correct operator to use for matrix addition. What happens when matrices are added is quite different from when real values are added, but the meaning of + is still addition for the both of them. That's also a possibility, I suppose, but the real thrust is it would allow you to have very clear (as in, visually offset by some sort of brace, in this example) operators that handle whatever weird transform you want for any convoluted data structure you care to define one for. That they can be entered with a standard 104-key keyboard without groping about for however people prefer to enter unicode characters is just icing. -Wyatt
Re: UDP enhancement
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote: I believe that the way that this sort of enhancement has typically been suggested Oh hey, I remember the DIP23 madness. Is it that time again already? is to do something like public @property int value; Yes. Please, yes. This kills so much boilerplate. (In fairness, DIP23 was pretty good, aside from the address-of shenanigans and lack of low-hanging operator rewrites.) -Wyatt
Re: Feature request: Path append operators for strings
On Friday, 5 July 2013 at 18:18:14 UTC, H. S. Teoh wrote: It doesn't necessarily have to be ~, as long as it's something other than + (or any other numerical binary operator). Perl uses '.', but in D's case, that would be a bad idea, since you'd have ambiguity in: Perl is my day job and I've come to strongly dislike the period for concatenation. IMO, that the tilde is nice and visible is a strong UX argument in its favour. Periods get used at the end of every sentence. Full stop. :P -Wyatt
Re: Feature request: Path append operators for strings
On Wednesday, 3 July 2013 at 12:24:33 UTC, Wyatt wrote:
This is something I was discussing with a friend recently, and
we agreed it would be cool if there were set of operators with
no definition until overloaded, so you could use e.g. (.) for
dot product, (*) for cross product, (+) (or maybe [+]?) for
matrix add, etc. instead of overloading things that already
have specific, well-understood meaning.
I'd like to clarify this a little with a concrete example I hit
late yesterday. I have a sparse tree-like recursive struct with
an array of children and a single leaf value. I thought it was
fairly simple, but I quickly found the range of common operations
I want to support exceeds the limits of orthogonal operations.
Like my opOpAssign!("~") adds the children of the RHS as children
of LHS, while the opIndexAssign assigns a leaf value to a child
of LHS, and the opIndexOpAssign!("~") makes the entire RHS tree a
child of the LHS. And I'm sure I'm not "done"; but I'm also VERY
reluctant to go any further because it's getting ugly fast. (I
think I may be able to _somewhat_ work around this with multiple
overloads for different types. I haven't tried it, but I think
that works?)
Having some way of differentiating the different semantic
concepts (i.e. operating on trees vs. operating on leaf values)
would be hugely useful for my ability to reason about the code
easily. Not just that, having a way of offsetting them
_visually_ would be useful for me to keep track of them and know,
at-a-glance, that I'm doing something different; something that's
not QUITE like e.g. a concatenation. (As I think I mentioned, I
see this as a major factor in favour of some kind of bracing, if
not parentheses.)
IMO, it's the sort of thing where almost any non-trivial data
structure you manipulate frequently could stand to benefit.
Unfortunately; conversely, I _also_ completely understand that
adding more features to the language at this point is a fairly
tall order. Worse, I think this would require some compiler/spec
changes. Or maybe there's a third path I'm not seeing-- I don't
know.
All that said, does anyone aside from myself and a few others
have strong opinions on this?
-Wyatt
Re: Interesting Research Paper on Constructors in OO Languages
On Tuesday, 16 July 2013 at 13:35:00 UTC, Craig Dillabaugh wrote: How do you envision this working where Name or Age must be set to a value not known at compile time? I'm not sure if it's practical or covers all the bases, but it sounds like you would need to keep track of member initialisation during compilation, and abort if the code attempts to use the object or one of its members as an AssignExpression without initialising the whole thing. Setting aside the fact that there's compiler work mentioned at all, have I missed some nuance of this pattern? I guess there's the situation where you conditionally may or may not assign, or pass it around and accrete mutations, so it might be best to only do it for some properly-annotated (how?) subset of the whole? Not sure. -Wyatt
Re: Deimos need some works
On Thursday, 18 July 2013 at 09:47:27 UTC, bioinfornatics wrote: problem here that is dub is showed to be the universal D way to build and manage packaging. that is really a problem to continue to support D project into offcial linux repository. It really isn't. It may become that if the community decides to adopt it officially, but for the time being, it's third-party code maintained as part of vibe.d. I can package dub and user use it for any reason but i need to be able to build and install a project by following FHS and other linux rules Your job as a distro package maintainer is to package software for your distro; make sure the package interacts well with the system, such as by making sure it builds with the proper CFLAGS, works with --as-needed, installs files to the proper place, etc.; and, within a reasonable degree of certainty, ensure it won't break users' systems. If it's not installing files in the right places, patch it. Then, contact the maintainers to see if you can have that patch upstreamed. It's not a project's job to package software-- those that manage to do it and do it well are fortunate; in my experience, many of them are awful at it (especially LSI). Sometimes you'll need to help them understand what distros need so they can keep distro needs in mind going forward. It's a two-way street. -Wyatt
Re: Proof that D sucks!
On Tuesday, 23 July 2013 at 16:20:46 UTC, Jonathan A Dunlap wrote: O rly?? OMG D sux @ GC! Are you mocking me? Complaining about the GC in any discussion thread where D comes up anywhere has been a thing for years, so probably not.
Re: Article
On Thursday, 25 July 2013 at 15:20:03 UTC, Chris wrote: I don't know where to put it online. Any advice? Well, you could post it here-- we're not strangers to enormous walls of text. ;) Where it goes from there is a community effort. Or if you think there are irreconcilable formatting needs, maybe make a wik page on http://wiki.dlang.org and link it here? -Wyatt
Re: working on the dlang.org website
On Tuesday, 30 July 2013 at 16:18:38 UTC, Kagamin wrote: Anybody gets a timeout in hyphenate.js on http://dlang.org/phobos/core_memory.html ? A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://dlang.org/js/hyphenate.js:55 Yeah. I've seen it. Even though it's supposed to be disabled for Firefox. I'm waiting eagerly for this pull request to get merged so we can end this farce: https://github.com/D-Programming-Language/dlang.org/pull/367 -Wyatt
Re: Article on programming language adoption (x-post from /r/programming)
On Thursday, 1 August 2013 at 16:55:21 UTC, H. S. Teoh wrote: Y'know, one feature I've always wanted is the equivalent of preprocessed C code -- with all mixins expanded, aliases substituted with their final target, templates fully expanded, all syntactic sugar lowered, with the original code lines in comments, so that you can see exactly how your code was translated, and whether it matches what you *think* it does. This would also be invaluable for debugging, as then it will map to the assembly code much better, which will help you trace where things went wrong. Considering how useful that sounds, I'm a little surprised this only has three votes in three years: http://d.puremagic.com/issues/show_bug.cgi?id=5051 -Wyatt
Re: Future of string lambda functions/string predicate functions
On Tuesday, 6 August 2013 at 09:51:07 UTC, bearophile wrote: So my vote is -0. Curse you, flush-to-zero denormal mode! ;) @OP: To be honest, I didn't even know about string lambdas. They don't seem to be a well-advertised, hot-button feature. Just looking at the examples, I rather think they're hard for humans to parse, and wouldn't even notice if they were quietly dragged out back and exorcised. -Wyatt
Re: Evangelizing Your Cool Product
On Tuesday, 6 August 2013 at 23:28:44 UTC, MattCoder wrote: I don't think you should just compare programmers/developers with entrepreneurs like you did. Of course there are programmers who market/promote their own software, but most don't or at least not like an entrepreneur would do. Maybe those weren't great examples, but the underlying message is definitely true. It's pretty clear at this point that promotion is an important part of going indie with games; look at Introversion, Dejobaan, Gaslamp, Positech, Wolfire, and whatever Jon Blow calls his outfit. And how many years was Phil Fish writing about Fez? For the tools side, Adam Saltsman with flixel and Nicolas Cannasse with Haxe are decent examples. Or Mozilla. Ooh man, Mozilla is a good one. How popular do you think Firefox would be without the concentrated campaign to "take back the web" and all that? Writing about your stuff and telling people about your stuff is just super important (even if doing it kind of sucks). -Wyatt
Re: parseJSON bug
On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote: On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications. Then my reading says this really _is_ a bug. At least, according to http://www.ietf.org/rfc/rfc4627.txt, which states and shows only that: "Insignificant whitespace is allowed before or after any of the six structural characters." ..unless there's a different version that supersedes that one? -Wyatt
Re: parseJSON bug
On Thursday, 8 August 2013 at 15:17:40 UTC, Tofu Ninja wrote: A formal grammar can be found here starting on page 202 but I don't know enough about grammars to be able to interpret it. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf Im starting to become less sure if its a bug or not... I don't recogise that exact BNF notation (single colon? New to me.), but unless it's fairly...unique, it's still a bug according to a strict reading. (I feel the RFC version is somewhat more clear, honestly.) -Wyatt
Re: parseJSON bug
On Thursday, 8 August 2013 at 17:37:37 UTC, Tofu Ninja wrote: Just out of curiosity what is this sort of grammar format called or what would one want to try to look up to understand it? I just have seen it around a few times and never really knew what it was about other than some how it describes a language. That'd be some flavour of BNF: https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form Very handy thing to know how to read (though I prefer PEGs). -Wyatt
Re: UFCS for templates
On Friday, 9 August 2013 at 03:29:20 UTC, JS wrote: Um, not really... Do you think that god made some law that requires me to? There's nothing supernatural involved, but there is basic scientific method and engineering rigour. Anyone can throw out ideas about how they think things "ought to be", but if you can't even provide a shred of evidence in your favour, it's not convincing. Specifically, it makes it look like either a) your suggestion doesn't effect any real, tangible change or b) you haven't seriously considered your own proposal or addressed possible shortcomings. Moreover, it shows a lack of respect for the time of others (which is just as finite as your own). In short: the "shotgun" approach you've been taking with your feature requests is not working. It' not my problem is you want the D language to suffer. I would think that if you really cared about the D lang sit here and type up use cases because you are too lazy, don't have the foresight, or don't care to think about the issue. The /snip Fallacy doesn't help anything. Please stop that. I sincerely hope you don't believe belittling and insulting the community you want support from is an endearing trait. At some point something better will come with better features and D will succumb and all the time you invested will be a waste. Sorry, I don't understand this point at all. A waste? Science is the incremental march of progress; each advancement building on the last. How is being one of those stepping stones a waste? I hope we eventually DO have something even better than D2. Like D3 or something. ;) -Wyatt
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 17:20:37 UTC, Nick Sabalausky wrote: rare few who have a monitor that swivels vertically or some Once you go vertical, you never go back! No, really, considering how much nicer it is for _every kind of documentation_ (and most code), it's sad that this standard feature of good Dell monitors for at least five years is rare. -Wyatt
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Monday, 12 August 2013 at 16:29:36 UTC, H. S. Teoh wrote: What do you say? Let's throw together an SConstruct for DMD, druntime,and phobos, and submit a pull for it? I don't care as long as you're willing to maintain whatever you choose. But SCons? Granted it's been a few years since I deigned to look at it, but it's historically caused a lot of packaging headaches. The only downside is that I can predict people will start complaining about the Python dependency. (Which is why I proposed writing a build system in D -- it will be superior to make (anything would be!), and people will have no excuse about what language it's written in.) Do you plan on bundling it or are you expecting people to install it? Does it properly handle library search yet or is it still using naive name-only lookup? How about environment variables like CC and PATH? Has it become resilient against python version changes completely breaking it? etc. Despite how onerous they are, Autotools and CMake have a better track record that I've seen. -Wyatt
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote: Think of this topic as writing letters to Santa, so: what say you ? Aww, you've gone and reminded me of Hybrid [1] again. D1/Tango IIRC, but I think it had good potential. No lazy updates, though, so probably not as useful for ordinary desktop applications. ...I wonder if Tomasz will ever come back? -Wyatt [1] http://h3.gd/code/hybrid/wiki/
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tuesday, 13 August 2013 at 16:11:44 UTC, H. S. Teoh wrote: There's no need to maintain any makefiles once the D build tool is usable. On this note, I've often wondered why D compilers (or dmd, at least) don't just try to infer the necessary files to compile/link for a project based on the modules it imports. Obviously this breaks down once you need to express linkage with external libraries; but figuring out as much as possible automatically would be neat. e.g. Say the top of smallProj.d has: import common.func; import common.data; ...and you have a common/ directory with func.d and data.d, it seems the compiler could accept: dmd smallProj.d ...as a shorthand for: dmd common/func.d common/data.d smallProj.d Given that it doesn't work this way, I'm guessing there's some aspect I've missed that throws it into the same sort of hellscape of agony as every other build system in the world, but I can't figure out what it might be... -Wyatt
Re: Future of string lambda functions/string predicate functions
On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote: more// a > b more!(5)// a > 5 moreEq // a >= b moreEq!(5) // a >= 5 Nitpick, but I'd personally prefer "greater" rather than "more". -Wyatt
Re: Ideas for a brand new widget toolkit
On Wednesday, 14 August 2013 at 14:26:12 UTC, Adam D. Ruppe wrote: Of course, you do want just "blit this image" as a generic fallback, and we can do better than X too, by just making it use png+jpg or something. Boom, transparency (yes, X has this in the render extension) and some big compression boosts. I recall NX does something like this, plus a number of other neat tricks. http://www.nomachine.com/documents/NX-XProtocolCompression.php -Wyatt
Re: Ideas for a brand new widget toolkit
On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote: Sure, but X forwarding is still laggy, as you pointed out. I think that's only because it's a naive, uncompressed implementation. Proper protocol compression pretty much removes that for most use cases. -Wyatt
Re: @property (again)
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote: 3) properties decay to normal functions when they have their address taken Is there some reason why we _need_ to be able to take the address of properties? I've yet to see a good argument in favour of it, and I've seen several against. I think that whole idea is a misfeature that won't be missed. -Wyatt
