On Wednesday, 9 April 2014 at 03:05:14 UTC, Brad Roberts wrote:
Tonight at 11pm pacific time, about 3 hours from now, the D
bugzilla is going to go read-only for some much needed
maintenance and upgrading. Assuming all goes well, it will
come back an hour or so later as issues.dlang.org.
Well, my ISP decided that it wanted to take the night off while I was about
half done.
Completed:
- issues.dlang.org should be functional
- bug changes are slow due to mail sending
- github updated to point to new site
Todo:
- old site doesn't redirect yet
- auto tester graphs pull
On Wednesday, 9 April 2014 at 07:59:26 UTC, Brad Roberts wrote:
Well, my ISP decided that it wanted to take the night off while
I was about half done.
Completed:
- issues.dlang.org should be functional
- bug changes are slow due to mail sending
- github updated to point to new site
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
Tonight at 11pm pacific time, about 3 hours from now, the D bugzilla is
going to go read-only for
some much needed maintenance and upgrading.
Interesting. So what's new in this version of bugzilla (or rather what
was the old version and which
On 4/9/14, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
- All links are underlined by default (a little bit ugly, but I can
use a stylish script to override this)
Here's what I use for the Stylish[1] addon:
-
@-moz-document url-prefix('https://issues.dlang.org'),
Not sure what exactly needs to be done about it, but I noticed that
Deskzilla Lite doesn't recognize issues.dlang.org as an open source
installation and thus denies to add the D product with its 12k bugs.
Am 09.04.2014 14:38, schrieb Sönke Ludwig:
Not sure what exactly needs to be done about it, but I noticed that
Deskzilla Lite doesn't recognize issues.dlang.org as an open source
installation and thus denies to add the D product with its 12k bugs.
Also seems like votes are disabled.
Due to some personal events, this release took a lot longer than
anticipated, but now it's ready (with a record number of 120
fixes/additions). Major changes and improvements:
- Implemented SSL certificate validation (mostly important for HTTP
client requests and for the SMTP client) - note
On 4/9/14, 2:38 AM, Andrej Mitrovic wrote:
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
Tonight at 11pm pacific time, about 3 hours from now, the D bugzilla is
going to go read-only for
some much needed maintenance and upgrading.
Interesting. So what's new in this version of bugzilla
On 4/9/14, 5:55 AM, Sönke Ludwig wrote:
Am 09.04.2014 14:38, schrieb Sönke Ludwig:
Not sure what exactly needs to be done about it, but I noticed that
Deskzilla Lite doesn't recognize issues.dlang.org as an open source
installation and thus denies to add the D product with its 12k bugs.
Also
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
As to what the 3.4 to 4.4 changes entail.. I'm sure that list is long as
it's years and many many
versions worth of changes. Best source for that would be to peruse the
bugzilla change logs.
Excellent. Found a few pages listing the new
For the Deskzilla Lite problem, it's because the new URL isn't
currently on their list of open-source project's urls. I just opened
an issue (https://jira.almworks.com/browse/DZO-1187) with them about
it.
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
On 4/9/14, 5:55 AM, Sönke Ludwig wrote:
Wait.. deskzilla, a tool on top of bugzilla, uses Jira to track bugs? There's
irony in that.
On 4/9/14, 11:51 AM, Orvid King wrote:
For the Deskzilla Lite problem, it's because the new URL isn't
currently on their list of open-source project's urls. I just opened
an issue
Almost forgot that the OpenSSL Windows binaries are shipped together
with vibe.d. I've tagged a version with the latest OpenSSL 1.0.1g. Be
sure to use this if you plan on setting up an SSL based server on Windows:
http://code.dlang.org/packages/vibe-d/0.7.19+openssl-1.0.1g
On 03/04/2014 02:55, Andrei Alexandrescu wrote:
A lot of them could apply to us as well.
https://www.youtube.com/watch?v=TS1lpKBMkgg
Andrei
One interesting point near the end. He glossed over it since he was
running out of time, but this was in the slides:
What I'm after
* I don't need
On Wednesday, 2 April 2014 at 04:16:55 UTC, Daniel Murphy wrote:
Jay Norwood wrote in message
news:tsyxasgqmrkmuolmf...@forum.dlang.org...
Is there a test suite that you have to pass to declare it
fully functional?
Not that I know of, but it _almost_ passes the dmd test suite
(3
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
Tonight at 11pm pacific time, about 3 hours from now, the D bugzilla is
going to go read-only for
some much needed maintenance and upgrading.
I've just noticed some new behavior which looks like a bug. When I
click on edit next to the Status
On 4/9/2014 4:21 PM, Bruno Medeiros wrote:
Sure, the language may be the core, and one of the most
important aspects, but the rest of the tool-chain is extremely important
too.
I don't think everyone in the D community (and outside it too) fully
stands behind this idea.
I think a big part
It's moving your focus down to the status block just below the comment textarea. Not a bug, but
also not super obvious.
On 4/9/14, 1:50 PM, Andrej Mitrovic wrote:
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
Tonight at 11pm pacific time, about 3 hours from now, the D bugzilla is
going
On Saturday, 5 April 2014 at 18:47:50 UTC, Walter Bright wrote:
On 4/5/2014 10:10 AM, Timon Gehr wrote:
On 04/03/2014 04:45 AM, Walter Bright wrote:
On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote:
A lot of them could apply to us as well.
https://www.youtube.com/watch?v=TS1lpKBMkgg
at
On Wednesday, 9 April 2014 at 07:59:26 UTC, Brad Roberts wrote:
Well, my ISP decided that it wanted to take the night off while
I was about half done.
Completed:
- issues.dlang.org should be functional
- bug changes are slow due to mail sending
- github updated to point to new site
On 4/9/14, 2:26 PM, Kapps wrote:
On Wednesday, 9 April 2014 at 07:59:26 UTC, Brad Roberts wrote:
Well, my ISP decided that it wanted to take the night off while I was about
half done.
Completed:
- issues.dlang.org should be functional
- bug changes are slow due to mail sending
-
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
It's moving your focus down to the status block just below the comment
textarea. Not a bug, but
also not super obvious.
I know. But it's a total usability anti-pattern. It would be like
hitting the horn in your car and then getting a display
On 4/9/14, 2:47 PM, Andrej Mitrovic wrote:
On 4/9/14, Brad Roberts bra...@puremagic.com wrote:
It's moving your focus down to the status block just below the comment
textarea. Not a bug, but
also not super obvious.
I know. But it's a total usability anti-pattern. It would be like
hitting the
Hello. Here is a programming language that is coded in D. The
documentation is included in the file. It is ment to be used as a
general purpose scripting language. Its name is HarpoScript. It
has enough features for general purpose work at the moment,
however its not exactly efficient. If you
On Wednesday, 9 April 2014 at 17:55:08 UTC, Sönke Ludwig wrote:
Due to some personal events, this release took a lot longer
than anticipated, but now it's ready (with a record number of
120 fixes/additions). Major changes and improvements:
- Implemented SSL certificate validation (mostly
Is there some way to get the severity column back on the search results
page? And make regressions orange again?
On 4/9/14, 9:03 PM, Daniel Murphy wrote:
Is there some way to get the severity column back on the search results page?
And make regressions
orange again?
At the bottom of the search results page there is a 'change columns' button with the ui to control
the columns to display. You'd have
On 04/09/2014 05:31 PM, Harpo wrote:
a programming language that is coded in D.
Congratulations! :)
Another one by a high school student:
https://github.com/Rhodeus/Script
The author had won first place among high school students in TÜBİTAK
competition.
Ali
On 06.04.2014 23:20, Tomer Filiba wrote:
On Sunday, 6 April 2014 at 16:34:02 UTC, safety0ff wrote:
Please post more of the stack trace, it looks like you're allocating
while it is running the destructors / finalization (#11408.)
https://d.puremagic.com/issues/show_bug.cgi?id=11408
Yes, I
On 08/04/14 14:03, David Nadlinger wrote:
On Tuesday, 8 April 2014 at 10:08:24 UTC, Jacob Carlborg wrote:
Is there a reason to not use the same model, or what's required to be
compatible?
In short, the reason not to use the same model (you could argue that
the model is the same, as only the
On Tuesday, 8 April 2014 at 20:07:09 UTC, Brad Roberts wrote:
Most of the areas where DMD is 'odd' are a case of I can't
figure out the right way, so any way is better than no way.
That's particularly true for var args and eh. I'm confident
that pulls that fix these issues can and will be
On Tuesday, 8 April 2014 at 22:19:06 UTC, Iain Buclaw wrote:
Worse, there's even work that is complete for GDC that is
critical for
ARM support, but breaks ABI - in a positive way that means all
targets
behave as expected. However DMD is impeding progress of this
work.
What are you
On Wednesday, 9 April 2014 at 07:19:54 UTC, Jacob Carlborg wrote:
For 64bit, Objective-C uses the same exception handling as C++.
So I need to somehow be able to catch Objective-C exceptions
and Objective-C need to be able to catch D exceptions. Although
I still expect to need to wrap the
On 9 April 2014 08:19, Jacob Carlborg d...@me.com wrote:
On 08/04/14 14:03, David Nadlinger wrote:
On Tuesday, 8 April 2014 at 10:08:24 UTC, Jacob Carlborg wrote:
Is there a reason to not use the same model, or what's required to be
compatible?
In short, the reason not to use the same
On 9 April 2014 09:23, David Nadlinger c...@klickverbot.at wrote:
On Tuesday, 8 April 2014 at 22:19:06 UTC, Iain Buclaw wrote:
Worse, there's even work that is complete for GDC that is critical for
ARM support, but breaks ABI - in a positive way that means all targets
behave as expected.
On Monday, 7 April 2014 at 12:38:55 UTC, Steven Schveighoffer
wrote:
I think using using D's safer syntax of
a[] = b[]
and
a[] = 0;
Is much preferable to using memcpy/memset directly.
They should do the Right Thing, including calling
memcpy/memset when correct.
-Steve
I received a very
On Tuesday, 8 April 2014 at 21:53:58 UTC, Steven Schveighoffer
wrote:
The rule of thumb is, 2 or more references deep does not
implicitly convert. One reference deep is OK.
-Steve
For some reason I was expecting that to rhyme. :P
Anyways thanks all, makes sense now. Are there any
Am Tue, 08 Apr 2014 21:30:08 +
schrieb Colden Cullen coldencul...@gmail.com:
One issue I've had huge amounts of trouble with is casting to and
from shared. The primary problem is that most of phobos doesn't
handle shared values at all.
If there was some inout style thing but for
On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
1. Is the current design damaging enough (= allows enough wrong/buggy
code to pass through) to warrant a breaking tightening?
What I would very much like to see happen is that any time that any operation
is done on a variable of an
Since only functions performing a single operation on a
single shared operand can accept shared variables, it is
practically impossible to use shared mutable data in
generic algorithms.
Assuming that with this premise user code will always use a
mutex to secure access to shared data, developers
Mike wrote in message news:iflykgpsrmdbfhuwz...@forum.dlang.org...
So, my question remains: If I'm porting D to a platform that has no C
library, shouldn't a public, supported function that copies memory be
added in the D Runtime?
What platform doesn't have a C library? And you can always
On Wednesday, 9 April 2014 at 11:36:15 UTC, Marco Leise wrote:
Since only functions performing a single operation on a
single shared operand can accept shared variables, it is
practically impossible to use shared mutable data in
generic algorithms.
Assuming that with this premise user code will
On Wednesday, 9 April 2014 at 11:50:13 UTC, Daniel Murphy wrote:
Mike wrote in message
news:iflykgpsrmdbfhuwz...@forum.dlang.org...
So, my question remains: If I'm porting D to a platform that
has no C library, shouldn't a public, supported function that
copies memory be added in the D
On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis
wrote:
On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
1. Is the current design damaging enough (= allows enough
wrong/buggy
code to pass through) to warrant a breaking tightening?
What I would very much like to see
On Wednesday, April 09, 2014 12:18:23 w0rp wrote:
On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis
wrote:
On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
1. Is the current design damaging enough (= allows enough
wrong/buggy
code to pass through) to warrant a
On Tuesday, 8 April 2014 at 18:38:47 UTC, bearophile wrote:
...
In 2 cases I have had to cast to convert an array length to
type uint to allow the code compile on both a 32 and 64 bit
system, to assign such length to some uint value.
...
Bye,
bearophile
Personally I design my code around
Am Mon, 07 Apr 2014 23:28:02 +
schrieb w0rp devw...@gmail.com:
http://heartbleed.com/
This bug has been getting around. The bug was caused by missing
bounds checking.
I'm glad to be using a language with bounds checking.
Sorry, but wasn't this security risk instead caused by
On Wednesday, 9 April 2014 at 12:12:35 UTC, Mike wrote:
On Wednesday, 9 April 2014 at 11:50:13 UTC, Daniel Murphy wrote:
Mike wrote in message
news:iflykgpsrmdbfhuwz...@forum.dlang.org...
So, my question remains: If I'm porting D to a platform that
has no C library, shouldn't a public,
On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis
wrote:
On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
1. Is the current design damaging enough (= allows enough
wrong/buggy
code to pass through) to warrant a breaking tightening?
What I would very much like to see
Mike wrote in message news:nxretodrkqizyiukw...@forum.dlang.org...
My custom, bare-metal, D-only platform has no C library, nor will it ever.
And, Yes, I know I can cast, but should I?
Ah.
So far, it seems D has only been used on one subset of computer systems
that happen to have a C
monarch_dodra wrote in message
news:pdzhmmnjxclrjtkgu...@forum.dlang.org...
I think arguably, there should be D equivalents of the C runtime
functions, if only for the added safety of slices (for example, memchr
could be 100% certifiably safe), and to avoid the rampant deduplication of
On Wednesday, 9 April 2014 at 12:50:23 UTC, Daniel Murphy wrote:
* Were these methods intentionally omitted from the D Runtime,
or just taken for granted since they were so conveniently
available in the C standard library?
They were _not_ omitted from druntime, they were exposed though
David Nadlinger wrote in message
news:bivyxqzewidjylast...@forum.dlang.org...
Sure, one way to go about this would be to just sit down and implement a
common ABI in GDC and LDC (hackathon at London/Zürich/… anyone?) and then
hope that some random contributor turns up later on and fixes DMD
Mike wrote in message news:ycvyulqzunbsuweip...@forum.dlang.org...
Let me ask you this: From a principled D design point of view, is
core.stdc an interface only for ports with a C library, an implementation
detail of the current druntime that phobos is circumventing, or an
official,
Am Wed, 9 Apr 2014 23:11:08 +1000
schrieb Daniel Murphy yebbliesnos...@gmail.com:
David Nadlinger wrote in message
news:bivyxqzewidjylast...@forum.dlang.org...
Sure, one way to go about this would be to just sit down and implement a
common ABI in GDC and LDC (hackathon at
On 9 April 2014 14:54, Marco Leise marco.le...@gmx.de wrote:
Am Wed, 9 Apr 2014 23:11:08 +1000
schrieb Daniel Murphy yebbliesnos...@gmail.com:
David Nadlinger wrote in message
news:bivyxqzewidjylast...@forum.dlang.org...
Sure, one way to go about this would be to just sit down and
On Thursday, 7 March 2013 at 03:06:48 UTC, bearophile wrote:
Walter Bright:
Happy hacking!
Extra karma points if done blindfolded, using a Braille tablet
:-)
Bye,
bearophile
As far as I know, Walter DOES IT blindfolded, using a Braille
tablet and while he writes 3 other compilers at
Just to be clear, I don't want a default constructor for structs that
gets called implictly by the compiler, like in C++.
Instead I would really love to have a explicit default constructor. E.g.
it could look like this (alternative a new keyword explicit could be
introduced, but introduction
On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote:
Just to be clear, I don't want a default constructor for
structs that gets called implictly by the compiler, like in C++.
Instead I would really love to have a explicit default
constructor. E.g. it could look like this
On 4/9/14, 5:18 AM, w0rp wrote:
On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis wrote:
On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
1. Is the current design damaging enough (= allows enough wrong/buggy
code to pass through) to warrant a breaking tightening?
Am 08.04.2014 21:08, schrieb Andrei Alexandrescu:
(moving http://goo.gl/ZISWwN to this group)
On 4/7/14, 3:41 PM, w0rp wrote:
Yeah, I've seen this happen before. I think we could actually introduce
a little more type safety on enums without a great deal of breakage. It
would be nice to have a
David Nadlinger c...@klickverbot.at writes:
On Tuesday, 8 April 2014 at 18:55:35 UTC, Brad Roberts wrote:
I think, for a mixed language application, that the important part
is proper object lifetime management more than being able to catch
exceptions from different languages. When unwinding
On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote:
What do you think? CC welcome.
Kind Regards
Benjamin Thaut
I haven't read though the entire proposal yet (sorry!), but I'm
in definite agreement that *something* needs to be done to allow
explicit but argument-less
On 4/9/14, 8:44 AM, Benjamin Thaut wrote:
Am 08.04.2014 21:08, schrieb Andrei Alexandrescu:
(moving http://goo.gl/ZISWwN to this group)
On 4/7/14, 3:41 PM, w0rp wrote:
Yeah, I've seen this happen before. I think we could actually introduce
a little more type safety on enums without a great
On 2014-04-09 10:27, David Nadlinger wrote:
So, in the last paragraph, you are specifically referring to DMD on x86_64?
x86_64 yes, not necessarily only for DMD. I thought if DMD, LDC and GDC
all used the same exception handling model and the same as C++ it would
be easier. Especially for
On 2014-04-09 11:52, Iain Buclaw wrote:
The middle-ground would be us handling Objective-C foreign
exceptions in our EH personality function.
Yes, exactly.
--
/Jacob Carlborg
What would this do?
struct SomeStruct
{
this(int i = 10)
{
this.i = i;
}
this(void)
{
this.i = 20;
}
int i;
}
auto s = SomeStruct();
On Tuesday, 8 April 2014 at 21:52:56 UTC, Brad Anderson wrote:
On Tuesday, 8 April 2014 at 21:01:26 UTC, Martin Krejcirik
wrote:
On Tuesday, 8 April 2014 at 20:20:59 UTC, Brad Anderson wrote:
Good point. I think perhaps a -boundscheck is in order if the
What about:
On 2014-04-09 16:59, Benjamin Thaut wrote:
Just to be clear, I don't want a default constructor for structs that
gets called implictly by the compiler, like in C++.
Instead I would really love to have a explicit default constructor. E.g.
it could look like this (alternative a new keyword
On 4/8/14, 3:06 PM, H. S. Teoh wrote:
On Tue, Apr 08, 2014 at 09:46:51PM +, Meta wrote:
On Tuesday, 8 April 2014 at 19:09:55 UTC, Andrei Alexandrescu wrote:
[...]
3. What is the priority of improving enums in the larger picture of
other things we must do?
Enums could stand to be
On Wednesday, 9 April 2014 at 17:07:13 UTC, Jacob Carlborg wrote:
Result in an ambiguity error?
Really? What does this program print using a current version of
DMD?
import std.stdio;
struct SomeStruct
{
this(int i = 10)
{
this.i = i;
}
int i;
On 2014-04-09 18:59, Brian Schott wrote:
What would this do?
struct SomeStruct
{
this(int i = 10)
{
this.i = i;
}
this(void)
{
this.i = 20;
}
int i;
}
auto s = SomeStruct();
Result in an ambiguity error?
--
/Jacob Carlborg
On Wednesday, 9 April 2014 at 16:47:18 UTC, Andrei Alexandrescu
wrote:
Very true. In hhvm, we tried an enum class to avoid bugs with
using wrong indices in a couple of specific arrays. There were
so many darned casts around, we had to revert the change.
There are many ways to get around
On Wednesday, 9 April 2014 at 16:48:54 UTC, Jacob Carlborg wrote:
x86_64 yes, not necessarily only for DMD. I thought if DMD, LDC
and GDC all used the same exception handling model and the same
as C++ it would be easier. Especially for implementing support
for Objective-C exceptions, which is
On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven Schveighoffer
wrote:
This does not sound correct. In NO case should you be able to
remove bounds checking in @safe code.
It is. In fact, that's the very reason why DMD has -noboundscheck
in addition to -release.
David
On Tuesday, 8 April 2014 at 21:23:35 UTC, Andrei Alexandrescu
wrote:
On 4/8/14, 1:07 PM, Martin Krejcirik wrote:
On Tuesday, 8 April 2014 at 19:47:02 UTC, Andrei Alexandrescu
wrote:
For the record, dmd used to remove bounds checking in
-release mode.
I've asked Walter to add a new flag for
On Mon, 07 Apr 2014 12:49:05 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 4/7/2014 10:15 AM, Orvid King wrote:
On Monday, 7 April 2014 at 17:05:46 UTC, Walter Bright wrote:
On 4/7/2014 6:48 AM, asman wrote:
Could be great too if someone run a static analyzer like on dmd
code
On 4/9/14, 10:17 AM, Meta wrote:
On Wednesday, 9 April 2014 at 16:47:18 UTC, Andrei Alexandrescu wrote:
Very true. In hhvm, we tried an enum class to avoid bugs with using
wrong indices in a couple of specific arrays. There were so many
darned casts around, we had to revert the change.
There
On Wednesday, April 09, 2014 08:38:54 Andrei Alexandrescu wrote:
Too restrictive. What is a valid enum value? Would an enum flags need to
ascribe a name to every possible combination?
Why is that too restrictive? I don't see how it even fundamentally makes sense
for
auto result = MyEnum.a
On Wednesday, 9 April 2014 at 18:05:15 UTC, Andrei Alexandrescu
wrote:
That was for C++, and a function vs. a cast didn't improve the
experience much. -- Andrei
The difference being that a function is safe whereas a cast is
not.
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Instead I would really love to have a explicit default constructor. E.g.
it could look like this (alternative a new keyword explicit could be
introduced, but introduction of new keywords is usually avoided if
possible, AFAIK):
struct Foo
{
On Wednesday, 9 April 2014 at 18:18:57 UTC, Meta wrote:
On Wednesday, 9 April 2014 at 18:05:15 UTC, Andrei Alexandrescu
wrote:
That was for C++, and a function vs. a cast didn't improve the
experience much. -- Andrei
The difference being that a function is safe whereas a cast is
not.
When
On 4/9/2014 7:59 AM, Benjamin Thaut wrote:
What do you think? CC welcome.
Or you could use a factory function:
struct Foo {
static Foo factory() { ... }
...
}
auto foo = Foo.factory();
Am 09.04.2014 18:59, schrieb Brian Schott:
What would this do?
struct SomeStruct
{
this(int i = 10)
{
this.i = i;
}
this(void)
{
this.i = 20;
}
int i;
}
auto s = SomeStruct();
Thats easy to answer. What would it do if you replace the
Am 09.04.2014 19:05, schrieb Jacob Carlborg:
What's the advantage over using a static opCall, that it works with new?
That you can use it together with @disable this();
Am 09.04.2014 20:42, schrieb Walter Bright:
On 4/9/2014 7:59 AM, Benjamin Thaut wrote:
What do you think? CC welcome.
Or you could use a factory function:
struct Foo {
static Foo factory() { ... }
...
}
auto foo = Foo.factory();
But I don't want the construction to
On Wednesday, 9 April 2014 at 18:47:41 UTC, Benjamin Thaut wrote:
Thats easy to answer. What would it do if you replace the
struct with class and the void with nothing?
This thread is giving me some fun ideas for static analysis rules.
On 4/9/14, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
E succ(E value);
E succ(E value, E overflow) nothrow;
E pred(E value);
E pred(E value, E overflow) nothrow;
Not to nitpick, but next/prev for the names is easier to understand.
succ is rare, and pred reminds me of predicate.
Am 09.04.2014 20:53, schrieb Brian Schott:
On Wednesday, 9 April 2014 at 18:47:41 UTC, Benjamin Thaut wrote:
Thats easy to answer. What would it do if you replace the struct
with class and the void with nothing?
This thread is giving me some fun ideas for static analysis rules.
Just saying,
Am 09.04.2014 20:33, schrieb Timon Gehr:
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Why not just:
struct Foo{
this(){
// do stuff here
}
}
void main(){
Foo foo1; // error, no init value
auto foo2=Foo(); // ok
}
Because then the user might think, that the
On 04/09/2014 08:53 PM, Benjamin Thaut wrote:
Am 09.04.2014 20:33, schrieb Timon Gehr:
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Why not just:
struct Foo{
this(){
// do stuff here
}
}
void main(){
Foo foo1; // error, no init value
auto foo2=Foo(); // ok
}
On Wednesday, 9 April 2014 at 18:53:20 UTC, Brian Schott wrote:
On Wednesday, 9 April 2014 at 18:47:41 UTC, Benjamin Thaut
wrote:
Thats easy to answer. What would it do if you replace the
struct with class and the void with nothing?
This thread is giving me some fun ideas for static analysis
Hi folks,
first, please excuse my bad English.
Currently I'm using a C++ Dll to inject code into a native
process but since C++ really f***s me up, I'd like to move from
C++ to D.
I have 2 questions, before converting my code.
1) Are there any libraries that provide the hooking
functionality. In
On 4/9/2014 11:10 AM, Orvid King wrote:
As suggested I've posted it as an attachment to an issue,
https://issues.dlang.org/show_bug.cgi?id=12552
Thanks!
When I concatenate arrays like this, I get a strange compile
error:
Error: incompatible types for ((cast(int)a) ~ (cast(int)b)):
'int' and 'int'
Code:
public ubyte[] toArray(ubyte a, ubyte b, ubyte c) {
return a ~ b ~ c;
}
On Wednesday, 9 April 2014 at 19:35:49 UTC, Jeroen Bollen wrote:
When I concatenate arrays like this, I get a strange compile
error:
Error: incompatible types for ((cast(int)a) ~ (cast(int)b)):
'int' and 'int'
Code:
public ubyte[] toArray(ubyte a, ubyte b, ubyte c) {
return a ~ b ~
Am 09.04.2014 21:02, schrieb Timon Gehr:
On 04/09/2014 08:53 PM, Benjamin Thaut wrote:
Am 09.04.2014 20:33, schrieb Timon Gehr:
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Why not just:
struct Foo{
this(){
// do stuff here
}
}
void main(){
Foo foo1; // error, no
I took another swipe at the http://wiki.dlang.org/Debuggers wiki page
and updated the layout, as well as added and cleaned-up some of the info
there.
This was prompted by two users, in recent weeks, reporting problems
trying to use DDT+GDB to debug DMD produced executable on Windows... :S
I
On 2014-04-09 19:27, David Nadlinger wrote:
They don't. GDC and LDC use libunwind, whereas DMD uses its own custom
EH implementation.
That's what I want then, for all implementations to use libunwind.
With GDC and LDC, you'd just need to add your code to handle Objective-C
exceptions to the
1 - 100 of 192 matches
Mail list logo
