On Monday, 27 August 2012 at 23:28:31 UTC, SomeDude wrote:
On Saturday, 25 August 2012 at 19:48:33 UTC, Jeff Nowakowski
wrote:
As for the IDE, he mentioned Scala, and there the developers
made an effort to support the IDE in the compiler so that work
wouldn't be duplicated and the IDE would s
dmd2-git is in AUR too, not in main repo.
There are also some people that think that compile time
metaprogramming is the single best thing happened to programming
languages. And, hey, what language will I use if you tear it
apart from D? :P
On Friday, 28 September 2012 at 18:21:32 UTC, Paulo Pinto wrote:
On Friday, 28 September 2012
Reviving old topic.
I've been recently checking few general dlang.org pages like
http://dlang.org/cpptod.html and noticed that there is plenty of
stuff that is either deprecated ( like typedef ) or not really
advised ( like C-style function type declarations ). Probably all
language docs need
On Monday, 1 October 2012 at 16:25:12 UTC, Andrei Alexandrescu
wrote:
The project is not live, it will be within a few days. In the
spirit of having the community actively participate, I'm making
this as transparent as it gets. Please comment:
http://www.kickstarter.com/projects/dlang/11775015
After some gentle preachings I have been asked in my company to
prepare presentation regarding D usage in scope of embedded,
kernel-level development and mobile devices. I am quite starving
to find good project examples for D2 though ( most stuff I am
aware of is D1 ) and do not have enough tim
On Friday, 12 October 2012 at 10:58:04 UTC, Jens Mueller wrote:
mist wrote:
After some gentle preachings I have been asked in my company to
prepare presentation regarding D usage in scope of embedded,
kernel-level development and mobile devices. I am quite
starving to
find good project
On Friday, 12 October 2012 at 12:20:16 UTC, Tim Krimm wrote:
1) Do you consider garbage collection to be an issue in
embedded programming?
2) Are you dealing with hard timing constraints where garbage
collection could be an issue?
I would love a copy of your presentation
===
"not at that stage" means there are some probability-based issues
with codegen or some major blocker that prevents from even
trying? I'd really like to try some kind of proof-of-concept
GDC/ARM kernel-level stuff.
I don't think we're at that stage yet. What would be
appreciated
would be for
It does not ignore, it passes them as an arguments to resulting
program.
On Monday, 22 October 2012 at 12:36:44 UTC, Regan Heath wrote:
I just noticed this slightly odd behaviour from dmd -run and
wondered if it's a "bug"?
[vertest.d]
import std.stdio;
void main()
{
version(TEST) writefln(
There is a serious reason of getting through some registration
issues and pledging via kickstarter - project either gets all
money if it is funded or no at all if it is not (and all pledges
are returned automatically). And, of course, any other means of
supporting won't be counted by kickstarte
Sweet! You may also find my pull request for phobos ( #863,
fullyQualifiedTypename ) useful for adding function signature
once it gets finalised and merged.
On Friday, 2 November 2012 at 17:31:55 UTC, Rob T wrote:
Thanks to input from the D community, I've managed to implement
a reasonable way
On Friday, 2 November 2012 at 18:19:54 UTC, Jacob Carlborg wrote:
On 2012-11-02 18:46, Andrei Alexandrescu wrote:
I should add that I'm also totally behind this. When Walter
jumped into
implementing SIMD support on a hunch, I completely disagreed,
but that
was a great decision.
I can absolu
Regarding delegates - I think deal is that none of this C++ stuff
can automatically capture local function context with delegate,
so there are no _real_ delegates.
On Saturday, 3 November 2012 at 02:08:13 UTC, Mehrdad wrote:
On Friday, 2 November 2012 at 21:53:06 UTC, Walter Bright wrote:
On
http://codepad.org/s38L9tUr
Am I misunderstanding something regarding C++ here?
On Saturday, 3 November 2012 at 02:44:49 UTC, Mehrdad wrote:
On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
Regarding delegates - I think deal is that none of this C++
stuff can automatically capture
Ye, that is exactly what I meant when said C++ has no real
context capture and thus no real delegates here.
On Saturday, 3 November 2012 at 15:04:25 UTC, Paulo Pinto wrote:
On Saturday, 3 November 2012 at 12:56:36 UTC, mist wrote:
http://codepad.org/s38L9tUr
Am I misunderstanding something
Vote for "@( ArgumentList )"
Mostly because of current and yet possible ambiguity issue.
Argument is supposed to be not a string but plain D code. And it
is pretty logical that string literal is a valid compiling D
code, as well as an existing variable name.
On Monday, 17 December 2012 at 10:42:38 UTC, Pavel wrote:
Either I do not understand the work of this feature or it is an
ob
AFAIK those are more like Windows API & ABI reverse engineered
and reimplemented and that is a huge difference.
On Monday, 17 December 2012 at 10:01:35 UTC, Jacob Carlborg wrote:
On 2012-12-17 09:21, Walter Bright wrote:
I know what I'm talking about with this. The only time they
get reverse
I remember having very weird issues with rdmd when module is
called "main". May be this one is similar?
On Friday, 21 December 2012 at 14:52:27 UTC, Andrej Mitrovic
wrote:
On 12/21/12, Walter Bright wrote:
snip
Walter, can you verify if this is or isn't a bug:
.\main.d
.\foo.d
main.d:
m
AFAIK, Google Bot can do some basic JavaScript.
On Saturday, 29 December 2012 at 12:40:13 UTC, Vladimir Panteleev
wrote:
On Saturday, 29 December 2012 at 07:56:15 UTC, F i L wrote:
I don't think it should be collapsed by default (it's less
googlable that way).. just throwing that out there.
Almost all YouTube videos are HTML5-ready.
Really?? I thought youtube still uses Flash. I'm no fan of
youtube, but
it *is* a significant data point, considering that some people
are
actually making a living off homemade videos posted on youtube.
Weird. While I was reading "Next focus: PROCESS" topic and
http://wiki.dlang.org/Proposed_new_D_development_process entries,
I was completely convinced that switch to faster release model is
proposed, so that master replaces staging the very moment one
version is released (and it is the same mo
On Wednesday, 18 January 2012 at 22:15:25 UTC, Adam Wilson wrote:
On Wed, 18 Jan 2012 13:57:58 -0800, Walter Bright
wrote:
On 1/18/2012 1:27 PM, Patrick Stewart wrote:
How about putting equal effort in keeping existing D users?
There is more
than one blogs online of ex D users with some pret
Something similar to Boost::Spirit2 but with sane syntax and
better debugging would have been awesome.
log!(knownCause|unknownEffect|breaksFlow)("This is a severe
message.");
Simply defining log level enum in terms of this bit field would
help a lot.
Like, what is the first thing I do when getting a new log lib?
Checking all
pre-defined log levels and deciding when to use them. And, woah,
here
Ah, boost::multi_index!
I tend to dream that one day this approach (with template mess
cleaned using D capabilities) will find it's way to std.container
So yummy.
Oh, crap.
I wish your message could have appeared a week or two earlier.
Almost smashed my head against the wall trying to figure the hell
out of x64 seg fault.
Ugh, my spare time is rather hindered by trying to follow all
messages in D.announce and D groups ( and googling for all
unknown stuff cool guys are talking about ) - I am afraid that
adding D.learn to this everyday list would have made me a goner..
and you have just named a reason why it shoul
IMHO this is worth D.announce :)
How is D manual memory management any worse than plain C one?
Plenty of language features depend on GC but stuff that is left
can hardly be named "a lousy excuse". It lacks some convenience
and guidelines based on practical experience but it is already as
capable as some of wide-spread solution
There is a rationale for such checks, but I argue that the
place of these checks is not in the compiler itself, but in a
separate tool.
This. Compiler should never issue errors on code that may be
correct (at least in scope of language coding guidelines). And
warnings should just vanish from
tl;dr: more local branches means less need for arcane git
options.
--Ed
AFAIR you can resist the temptation to have a local master branch
at all and just run "git pull --rebase upstream/master" where
upstream is configured to be original D repo.
Sounds like different people have different understanding of
staging concept here and each one is doing minor tweaks to own
direction. I ran through updated wiki and some stuff like "pull
requests against staging" just scares me a lot. Someone really
needs to step up and take this under control
I did not feel competent enough to push for my opinion, I was
just afraid that 3 consecutive iterations of updates from
different people with different ideas in mind will result in
least usable combination of all 3.
But well, if you want my opinion regarding master and staging -
master should
P.S.
This was just another opinion that has no value unless someone of
authority starts making some clear decisions.
And then you're right back where we started; Andrei's original
problem was how to just get a local copy of the latest and
greatest upstream without having merge conflicts, which (if you
don't have a separate local master) means using "git pull
--rebase -s recursive -X ours".
But: "rebase -X
On Thursday, 10 January 2013 at 20:08:36 UTC, bearophile wrote:
Walter Bright:
Any diagnostic that gives false positives should not be in the
compiler.
I generally agree.
So do you think spotting what's discussed here is going to
cause many false positives?
http://d.puremagic.com/issues/sh
ranch when doing pull request
shortly after. Minor details regarding people comfort matter a
lot when they are supposed to work for free.
On Thursday, 10 January 2013 at 15:47:30 UTC, Andrei Alexandrescu
wrote:
On 1/10/13 1:28 AM, mist wrote:
Sounds like different people have different unders
My understanding is that your understanding is somewhat different
from initial proposal but that is where discussion has flow to
since then and that makes me sad :)
They very reason to have staging is to have better replacement to
beta process which simply does not work good enough currently.
Can't download latest zip - 404 not found.
Can't post new topic to newsgroup from web interface - internal
server exception.
Last issue is the reason I am posting here, not at vibed.org, beg
my pardon for the noise.
Thank you.
On Saturday, 12 January 2013 at 20:26:59 UTC, Sönke Ludwig wrote:
Am 12.01.2013 21:15, schrieb mist:
Can't download latest zip - 404 not found.
Can't post new topic to newsgroup from web interface -
internal server exception.
Last issue is the reason I am posting he
On Saturday, 12 January 2013 at 12:30:05 UTC, Johannes Pfau wrote:
Am Fri, 11 Jan 2013 18:54:12 +0100
schrieb "mist" :
Short comment about cherry pick - it is only bad in sense that
it
creates separate untrackable commit with same content, which
may
easily result in merging issues
On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:
Quite a nice read on the coding style used in Doom.
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
That guy has rather weird sense of beauty... My eyes started
bleeding at the "Spacing" sec
On Monday, 14 January 2013 at 22:53:05 UTC, FG wrote:
On 2013-01-14 22:31, mist wrote:
That guy has rather weird sense of beauty... My eyes started
bleeding at the
"Spacing" section.
I sympathize. He posted the worse code excerpt to prove his
point. :)
I am most unple
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:
And extra vertical spaces are like semantic formatting tools
for plain text - can group related blocks perfectly and speed
up reading.
The idea of not wasting lines doesn't go against the idea of
adding blank lines to create code p
On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote:
This generally comes up as an argument in these discussions,
but I don't buy it. Not all development is done on a desktop
with a huge screen. And even then, there is always something to
put on it. What window manager are you using?
Well, probably I am playing "good vision nazi" here, as 12 font
size seems HUGE to me, far beyond the comfort zone.
I'd also like to mention that now video recordings are planned
and thus actual audience is a lot wider than just conference
visitors.
On Tuesday, 15 January 2013 at 15:49:34 UTC, Russel Winder wrote:
On Tue, 2013-01-15 at 15:07 +0100, monarch_dodra wrote:
[…]
I do not know of any editor that does not support "ctrl +
scroll" to change the font sizes on the fly.
Emacs, VIM,…
[…]
Your editor's font size should not be statica
On Tuesday, 15 January 2013 at 16:31:05 UTC, Russel Winder wrote:
On Tue, 2013-01-15 at 17:02 +0100, mist wrote:
[…]
monospaced fonts everywhere to rule them all! :)
Monospace fonts are an aberration of the typewriter era.
All text, including code, should be displayed in proportional
fonts
On Tuesday, 15 January 2013 at 16:22:19 UTC, H. S. Teoh wrote:
On Tue, Jan 15, 2013 at 11:56:34AM +0100, mist wrote:
On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote:
>This generally comes up as an argument in these discussions,
>but I
>don't buy it. Not all developm
On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote:
On Tue, 2013-01-15 at 17:33 +0100, mist wrote:
[…]
:O You are probably the very first programmer I have
encountered so far that prefers proportional fonts for code. I
need some time to even try to imagine how this may look
On Wednesday, 16 January 2013 at 10:42:56 UTC, Philippe Sigaud
wrote:
One day, we could organize a D conference in Europe :)
There seem to be a good number of people from Europe here.
Please do! :) Btw do we have someone from European D community
here, who is familiar with conference organiza
When you have a ton of similar lines of code which need to be
edited in parallel, lining them up lets you edit all of them in
one keystroke. Saves me quite a lot of annoying editing in the
long run, actually.
When you have a ton of similar lines of code, you'd better start
thinking about temp
On Wednesday, 16 January 2013 at 08:18:53 UTC, bearophile wrote:
mist:
Many? Even single possible case is enough. And it has been
mentioned already - generic code gen, i.e. permutations.
Even one case is enough to kill it?
Do you want to add that case in this ER, for future reference
On Wednesday, 16 January 2013 at 11:50:18 UTC, bearophile wrote:
mist:
Yes and this is the very difference between compiler and
static analysis tool, in my opinion. Compiler should never
ever reject valid use cases, it does not matter how small
chance of meeting those is.
In most cases
On Wednesday, 16 January 2013 at 12:05:49 UTC, Jacob Carlborg
wrote:
On 2013-01-16 12:17, mist wrote:
Yes and this is the very difference between compiler and
static analysis
tool, in my opinion. Compiler should never ever reject valid
use cases,
it does not matter how small chance of
On Wednesday, 16 January 2013 at 15:49:14 UTC, Jonathan M Davis
wrote:
On Wednesday, January 16, 2013 13:53:04 mist wrote:
Well, that is probably the only thing I hate in Clang :) Also,
I
can't imagine a single valid use case for unreferenced
variables
in C/C++, so it is a bit diff
On Wednesday, 16 January 2013 at 16:58:13 UTC, David Nadlinger
wrote:
On Wednesday, 16 January 2013 at 12:53:05 UTC, mist wrote:
On Wednesday, 16 January 2013 at 12:05:49 UTC, Jacob Carlborg
wrote:
Clang contains a ton of warnings for code that could contain
common errors. […]
Well, that is
Wow, cool stuff indeed.
Preparing for DConf? :)
On Wednesday, 16 January 2013 at 18:42:38 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
When you have a ton of similar lines of code which need to
be edited in parallel, lining them up lets you edit
On Wednesday, 16 January 2013 at 19:06:47 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:
This is a single template operator in D so it kind of solves
the problem. First is tricky, but is exactly the reason
sometimes types from external libs are used only via
Well, initially it was just a harmless joke about some unique D
features. It is digitalmars.D newsgroup after all, no idea why
you have taken this so seriously.
But well, if you want to take this seriously, then I need to
state that I can't agree with "Only if the increase in ugliness
is wort
Btw, would someone from wiki contributors be interested in doing
the small talk about new planned release & development process?
I'd really like to see it widely recognized.
C++ does not have UFCS. It does matter.
What is best in my opinion - you can start to add tests even to
projects that do not yet have them, without any build system
tweaks or arguments about what unit test library to use. This
makes it a habit - a good habit.
Before D, I never wanted to write unittests. They were
cumbersome,
requir
On Tuesday, 22 January 2013 at 10:20:57 UTC, MMj wrote:
Hello Dennis.
Thanks very much for your guidance.
Yes I'm a C\C++ programmer. Are you an expert in D? Why you
thought C\C++ not good?
Wow, are we looking at C++ programmer who considers C++ good? :)
Short answer: unicode
Long answer is here:
http://dlang.org/phobos/std_range.html#.hasLength , please pay
attention to narrow string paragraph.
(failed constraint is hasLength!char[])
int is >= dchar so no issues for int.
This is a good hint, by the way, that something needs to be done
about constraint error messages or we are risk to fallback to C++
world of pretty template library errors. I usually just go
straight to template sources to save some time but that is hardly
expected from a newcomer.
On Tuesday, 22 January 2013 at 11:09:05 UTC, bearophile wrote:
This "Dynamic dispatch" section of the Clay language
documentation shows a way to avoid some template bloat (that is
common in Clay):
https://github.com/jckarter/clay/wiki/Avoiding-generic-programming-pitfalls
Maybe it's possible
What syntax sugar do you propose? There is hardly anything in the
link that can't be done with current std.variant.Algebraic at
first glance. Only stuff I can think of is some convenient way to
retrieve strongly typed value from Algebraic back, but that is
library update, nothing to do about la
Well, "porting druntime" is not exactly the thing I can call
"support from GDC", it is somewhat orthogonal from compiler.
On Tuesday, 22 January 2013 at 13:55:05 UTC, Freddie Chopin wrote:
On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote:
That's a common misconception. Other plat
Please do, looking forward to watching video about how I am wrong
:)
On Tuesday, 22 January 2013 at 14:29:11 UTC, Iain Buclaw wrote:
On 22 January 2013 14:02, mist wrote:
Well, "porting druntime" is not exactly the thing I can call
"support from
GDC", it is some
On Tuesday, 22 January 2013 at 14:39:58 UTC, bearophile wrote:
mist:
What syntax sugar do you propose?
Maybe some tagging to denote what template arguments should be
autoboxed?
The last piece of code in that page shows two saveClient()
functions. Maybe only one of them is needed, and the
I am probably I minority here but I liked the most strict
-property version and it made a lot of sense to me. Rationale is
simple:
some().ufcs().chaining(); - this is just a minor syntax
inconvenience
anything; - this drives me crazy, there is no way to understand
if this a no-op statement vari
On Thursday, 24 January 2013 at 12:53:45 UTC, Jacob Carlborg
wrote:
On 2013-01-24 13:35, bearophile wrote:
Instead of adding a -property, why wasn't this done since the
beginning?
It would break tons of code.
And yet it must have been done at some point. With some
year-ahead announcement o
On Thursday, 24 January 2013 at 13:34:08 UTC, Artur Skawina wrote:
On 01/24/13 12:50, mist wrote:
But looking at other comments this does not seem popular :(
Language design is not a popularity contest.
artur
Well most discussions seems to flow around simple preference
conflict of
On Thursday, 24 January 2013 at 13:43:41 UTC, Jacob Carlborg
wrote:
On 2013-01-24 14:01, mist wrote:
And yet it must have been done at some point. With some
year-ahead
announcement or anything like that, but it was a horrible
design error
in first place which needs to be fixed.
Yes, it
Googling is so good for necro thread resurrection.
What is idiomatic way in D to initialize static immutable AA to
be accessible in CTFE at the same? static this() won't help here,
unfortunately.
On Wednesday, 9 November 2011 at 10:44:08 UTC, Gor Gyolchanyan
wrote:
I think this is a bug and
You know what? Screw idiomatic. Is there _any_ way to use a
compile-time associative array literal?
On Thursday, 24 January 2013 at 17:49:18 UTC, Andrei Alexandrescu
wrote:
On 1/24/13 6:50 AM, mist wrote:
I am probably I minority here but I liked the most strict
-property
version and it made a lot of sense to me. Rationale is simple:
some().ufcs().chaining(); - this is just a minor syntax
One thing I am interested to hear from ones who think allowing
no-parens calls is fine is the following snippet:
http://dpaste.1azy.net/cd2f759e
import std.stdio;
alias Delegate1 = int delegate();
alias Delegate2 = Delegate1 delegate
Thank you. So simple and so illogical. Looking at your example I
have zero understanding why AA literals just do not work at
compile-time just out of the box.
On Thursday, 24 January 2013 at 19:30:27 UTC, Artur Skawina wrote:
On 01/24/13 19:36, mist wrote:
You know what? Screw idiomatic. Is
On Thursday, 24 January 2013 at 20:00:18 UTC, Andrei Alexandrescu
wrote:
On 1/24/13 1:35 PM, mist wrote:
You see, contrary to UFCS chaining this is not habit or syntax
issue. It
is semantic one - I am loosing an ability to distinct data
access from
function call by simply looking at code
Ah, I get the trick - enum does not really hold an AA, it is just
a copy-paste entity. Change the aa from enum to immutable - and
it won't compile.
Sorry, no offense meant from my side :) I have followed your
attempts on github and do not really feel in shape and competence
to try to add anything there now. I simply could not understand
why assignment to enum works and to immutable - not. Then
remembered they enums are simply replaced with
On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson wrote:
Let's consider what a property really is. It's a data
encapsulation tool. They allow us to expose object internal
data in a safe way. Nuking the idea is a step backwards.
This, this and this again. Reading this thread I sometimes
On Thursday, 24 January 2013 at 20:44:33 UTC, eles wrote:
On Thursday, 24 January 2013 at 20:26:50 UTC, mist wrote:
On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson
wrote:
I think the widest spread use case of a property is:
you start with a variable as memeber of a class, you write
On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
On 1/24/2013 5:42 AM, Jacob Carlborg wrote:
I agree with you but Walter is very afraid of breaking code.
The history of what happens when D code breaks because of
language changes is not a happy one.
Please. Go to http://wik
On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu
wrote:
On 1/24/13 3:58 PM, mist wrote:
Really, all this backwards-compatibility talk is a crap.
There's just a lot of evidence that suggests the contrary.
Clearly we don't want or like to be conservative, but
app
On Thursday, 24 January 2013 at 21:00:49 UTC, Jonathan M Davis
wrote:
Being able to swap out a public variable with a function
without having to
change any code using it is arguably the primary reasons that
property
functions exist in the first place. ...
Yes, but not just any function. Side-
%s/Adam/eles/g
On Thursday, 24 January 2013 at 21:12:41 UTC, H. S. Teoh wrote:
I didn't take any offense. Just stating that AA's as currently
implemented leaves a lot to be desired, and it's not going to
improve
unless *somebody* takes up the challenge to fix it.
Sure. But there are so many yummy bugs and i
On Thursday, 24 January 2013 at 22:45:52 UTC, Walter Bright wrote:
Having a release process does not remove the pain of breaking
changes that make users miserable because their older code no
longer compiles.
Beg my pardon, it is very ignorant position. It assumes user is
some kind of stubborn
On Thursday, 24 January 2013 at 21:23:53 UTC, Andrei Alexandrescu
wrote:
...
Sorry Andrei, with all my due respect, you have a brilliant
talent to answer something without actually stating any own
position on topic.
Please take a look to my answer to Walter:
http://forum.dlang.org/post/lpd
On Friday, 25 January 2013 at 09:49:29 UTC, Don wrote:
...
++
It feels that "breaking code" has become some kind of scary ghost
that is just being afraid of instead of some kind of
analysis-based approach.
Also I need to remind you that we break code all the time with
big fixes, literally every release. And end user does not care
how reasonable breaking it is, they are all the same: time needed
to update the code base.
We need to admit that breaking is inevitable and go forward from
there to fi
On Friday, 25 January 2013 at 05:35:19 UTC, kenji hara wrote:
module abc;
@property int foo(int n);
void main() {
foo = 1; // top-level property setter
1.foo; // property getter with UFCS
}
We cannot distinguish the two usages without adding any new
features.
Kenji Hara
"1.foo" must
On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner Schadek
wrote:
...
Yes, the syntax is legit. It's the semantic that "scares" me.
IMHO it feels strange that assigning a variable resizes a
array. Something like a.resize(10) would make me feel better.
Ye, it was one of the first "Erm w
1 - 100 of 134 matches
Mail list logo
