On 2013-03-27 22:54, nazriel wrote:
Requesting user to edit code first, add main(){} block or fix invalid D
code and then run example itself is unacceptable.
RDMD already has a --main flag and DMD will soon too.
--
/Jacob Carlborg
On Wednesday, 27 March 2013 at 19:43:13 UTC, Dmitry Olshansky
wrote:
27-Mar-2013 23:14, Peter Alexander пишет:
On Wednesday, 27 March 2013 at 14:48:32 UTC, Andrei
Alexandrescu wrote:
Found this:
http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-st
I think it's too fragile to require examples inside docs to be
runnable. A better way would be to expose those examples in the code
(ie outside of comments). That way, they'll be guaranteed to have
correct syntax, be properly syntax highlighted, and stay in sync with
code.
here's a simple possibil
On 2013-03-27 16:34, Vidar Wahlberg wrote:
- I find myself in a world of pain when I want to share data more
complex than the basic data types (int, char, byte, etc) across threads.
Seemingly the magic trick is to "cast(shared) foo" (or
"cast(immutable)") when passing objects/references to anoth
On 03/27/2013 12:08 PM, Steven Schveighoffer wrote:
On Wed, 27 Mar 2013 11:34:19 -0400, Vidar Wahlberg
wrote:
- When casting a value to an enum, there's no checking that the value
actually is a valid enum value. Don't think I ever found a solution on
how to check whether the value after castin
On 03/27/2013 03:47 PM, Steven Schveighoffer wrote:
On Wed, 27 Mar 2013 14:09:07 -0400, Nick Sabalausky
wrote:
On Wed, 27 Mar 2013 14:07:27 -0400
Nick Sabalausky wrote:
On Wed, 27 Mar 2013 13:08:19 -0400
>
> I just tested it, it works on enum *strings*, but not enum *values*
>
> For example
On 03/27/2013 04:54 PM, nazriel wrote:
[snip]
The options I've gathered so far:
1) Make all examples valid D code by hand. Make JavaScript assume that
all code examples in Phobos documentation should be wrapped in void
main() {} blocks. Add default set of includes + the module we are on.
Explicit
On 03/28/2013 04:18 AM, deadalnix wrote:
On Wednesday, 27 March 2013 at 18:20:49 UTC, Andrei Alexandrescu wrote:
On 3/27/13 1:23 PM, Timon Gehr wrote:
- Function that never return are inferred void. I would have preferred
typeof(null) as void lead to many static and repetitive code for
nothing
On Thursday, 28 March 2013 at 10:34:35 UTC, Timon Gehr wrote:
On 03/28/2013 04:18 AM, deadalnix wrote:
On Wednesday, 27 March 2013 at 18:20:49 UTC, Andrei
Alexandrescu wrote:
On 3/27/13 1:23 PM, Timon Gehr wrote:
- Function that never return are inferred void. I would
have preferred
typeof(nul
Hi,
DMD (I'm using v2.060) seems to evaluate conditions in static
if's from top to bottom (at least in a given scope). For example,
consider the following program:
module test;
const bool x = true;
const bool y = true;
struct S {
static assert(y);
static if(x)
stati
On 03/28/2013 06:29 AM, "Artur Zawłocki" " wrote:
Hi,
DMD (I'm using v2.060) seems to evaluate conditions in static if's from
top to bottom (at least in a given scope). For example, consider the
following program:
module test;
const bool x = true;
const bool y = true;
struct S {
static asser
On Thursday, 28 March 2013 at 11:29:49 UTC, Artur Zawłocki wrote:
Hi,
DMD (I'm using v2.060) seems to evaluate conditions in static
if's from top to bottom (at least in a given scope). For
example, consider the following program:
module test;
const bool x = true;
const bool y = true;
On Thursday, 28 March 2013 at 11:52:26 UTC, Don wrote:
On Thursday, 28 March 2013 at 11:29:49 UTC, Artur Zawłocki
wrote:
Hi,
DMD (I'm using v2.060) seems to evaluate conditions in static
if's from top to bottom (at least in a given scope). For
example, consider the following program:
modul
On Thursday, 28 March 2013 at 11:50:58 UTC, 1100110 wrote:
On 03/28/2013 06:29 AM, "Artur Zawłocki"
" wrote:
Hi,
DMD (I'm using v2.060) seems to evaluate conditions in static
if's from
top to bottom (at least in a given scope). For example,
consider the
following program:
module test;
cons
On Thursday, 28 March 2013 at 11:52:26 UTC, Don wrote:
Yes, it currently evaluates it top to bottom.
As long as all the static if's in question are in a single scope.
Here dmd evaluates the second (nested) static if before the first
one:
static if (S.a) static assert (S.a);
struct S {
On 03/28/2013 08:15 AM, "Artur Zawłocki" " wrote:
On Thursday, 28 March 2013 at 11:50:58 UTC, 1100110 wrote:
On 03/28/2013 06:29 AM, "Artur Zawłocki" "
wrote:
Hi,
DMD (I'm using v2.060) seems to evaluate conditions in static if's from
top to bottom (at least in a given scope). For example, con
On 03/28/2013 07:04 AM, deadalnix wrote:
On Thursday, 28 March 2013 at 11:52:26 UTC, Don wrote:
On Thursday, 28 March 2013 at 11:29:49 UTC, Artur Zawłocki wrote:
Hi,
DMD (I'm using v2.060) seems to evaluate conditions in static if's
from top to bottom (at least in a given scope). For example,
An interesting question:
http://stackoverflow.com/questions/15669592/what-are-the-differences-between-concepts-and-template-constraints
I plan an answer, but don't have a bunch of time right now. Feel free to
chime in!
Andrei
On 03/28/2013 07:18 AM, Jacob Carlborg wrote:
On 2013-03-27 22:54, nazriel wrote:
Requesting user to edit code first, add main(){} block or fix invalid D
code and then run example itself is unacceptable.
RDMD already has a --main flag and DMD will soon too.
Yes, DMD trunk already does that
back to the original, will d compile to asm.js?
On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
Maybe you remember the NaCl or PNaCl plug-in from Google, that
allows to safely run code at near native speed on the browser
(only 10-30% speed loss, in a probably safe sandbox). Thi
On 03/28/2013 07:46 AM, Timothee Cour wrote:
I think it's too fragile to require examples inside docs to be
runnable. A better way would be to expose those examples in the code
(ie outside of comments). That way, they'll be guaranteed to have
correct syntax, be properly syntax highlighted, and st
On 03/28/2013 09:53 AM, 1100110 wrote:
I'll work on 1. and see if we can't come up with something better!
The code snippets are pretty much necessary IMO. They just need to be
fixed.
int[] a = ...;
static bool greater(int a, int b)
{
return a > b;
}
sort!(greater)(a); // predicate a
On Wednesday, 27 March 2013 at 16:04:49 UTC, bearophile wrote:
Vidar Wahlberg:
[cut]
That static arrays are value types while dynamic arrays are
reference types may not be obvious for those with primarily
Java background.
Java has a semantics more limited compared to a system language
as D/
On 03/28/2013 12:09 PM, nazriel wrote:
On 03/28/2013 09:53 AM, 1100110 wrote:
I'll work on 1. and see if we can't come up with something better!
The code snippets are pretty much necessary IMO. They just need to be
fixed.
int[] a = ...;
static bool greater(int a, int b)
{
return a > b;
}
On 03/28/2013 02:34 PM, "Artur Zawłocki" " wrote:
On Thursday, 28 March 2013 at 11:52:26 UTC, Don wrote:
Yes, it currently evaluates it top to bottom.
As long as all the static if's in question are in a single scope. Here
dmd evaluates the second (nested) static if before the first one:
s
Am Wed, 27 Mar 2013 22:54:21 +0100
schrieb "nazriel" :
> Greetings.
>
> I would like to finish Phobos runnable examples case. But I need
> help in picking one strategy for implementation details.
>
With the recent unittest-as-example changes I'd say make runnable
examples work with those and p
On 03/28/2013 12:52 PM, Don wrote:
...
Yes, it currently evaluates it top to bottom. An algorithm has been
discussed which would remove that restriction;
I'm not sure that restriction is the correct word. There is not always a
well-defined top-to-bottom order.
your example would then comp
On Thu, Mar 28, 2013 at 07:25:07PM +0100, Johannes Pfau wrote:
> Am Wed, 27 Mar 2013 22:54:21 +0100
> schrieb "nazriel" :
>
> > Greetings.
> >
> > I would like to finish Phobos runnable examples case. But I need
> > help in picking one strategy for implementation details.
> >
>
> With the rece
On 03/28/2013 01:25 PM, Johannes Pfau wrote:
> Greetings.
>
> I would like to finish Phobos runnable examples case. But I need
> help in picking one strategy for implementation details.
>
Good point, I forgot about that.
On 03/28/2013 04:47 PM, Kirill wrote:
back to the original, will d compile to asm.js?
...
Eventually.
What do you think about this idea:
http://d.puremagic.com/issues/show_bug.cgi?id=9825
I was working on a project earlier today that stores IP addresses
in a database as a uint. For some reason though, some addresses
were coming out as 0.0.0.0, despite the fact that if(ip == 0)
return; in the only place it actually saves them (which was my
first attempted quick fix for the bug).
On 28-03-2013 21:03, Adam D. Ruppe wrote:
I was working on a project earlier today that stores IP addresses in a
database as a uint. For some reason though, some addresses were coming
out as 0.0.0.0, despite the fact that if(ip == 0) return; in the only
place it actually saves them (which was my
To follow up with some new woes I'm currently struggling with:
I'm storing some various values in an ubyte array. I discovered
that it's probably std.bitmanip I wish to use in order to
"convert" i.e. an int to 4 bytes (although I went first to
std.conv looking for this feature).
So I have "ubyt
On Thu, Mar 28, 2013 at 09:24:49PM +0100, Vidar Wahlberg wrote:
> To follow up with some new woes I'm currently struggling with: I'm
> storing some various values in an ubyte array. I discovered that it's
> probably std.bitmanip I wish to use in order to "convert" i.e. an int
> to 4 bytes (althoug
On 03/28/2013 03:24 PM, Vidar Wahlberg wrote:
To follow up with some new woes I'm currently struggling with:
I'm storing some various values in an ubyte array. I discovered that
it's probably std.bitmanip I wish to use in order to "convert" i.e. an
int to 4 bytes (although I went first to std.con
On Thursday, 28 March 2013 at 20:24:50 UTC, Vidar Wahlberg wrote:
To follow up with some new woes I'm currently struggling with:
I'm storing some various values in an ubyte array. I discovered
that it's probably std.bitmanip I wish to use in order to
"convert" i.e. an int to 4 bytes (although I
On Thu, 28 Mar 2013 21:03:07 +0100
"Adam D. Ruppe" wrote:
>
> which then got truncated by the database,
While I won't necessarily disagree with the rest, that right there is
"the real WTF". A database that silently alters data is unreliable,
and therefore fundamentally broken as a database. It sh
On Thursday, 28 March 2013 at 20:24:50 UTC, Vidar Wahlberg wrote:
that it's probably std.bitmanip I wish to use in order to
"convert" i.e. an int to 4 bytes (although I went first to
std.conv looking for this feature).
Ah, I reread it a couple of times and realized what you mean now.
You want
On Thursday, 28 March 2013 at 21:16:32 UTC, Chris Cain wrote:
I am completely confused as to why you're doing what you are
doing ... std.conv does work (and in the case you've listed, is
unnecessary anyway). Try this:
import std.stdio, std.conv;
void main() {
ubyte[] buffer;
buffer ~=
On Thursday, 28 March 2013 at 21:29:55 UTC, Nick Sabalausky wrote:
Is this MySQL, by any chance?
Yes, and no on strict mode, I didn't even know it had one!
Adam D. Ruppe:
if (arg == typeid(uint)) {
int e = va_arg!uint(_argptr);
a = to!string(e);
}
See, I copy/pasted it from the int check, but didn't update the
type on the left hand side. So it correctly pulled a uint out
of the varargs, but then assigned it to an int, which the
On 03/28/2013 09:03 PM, Adam D. Ruppe wrote:
I was working on a project earlier today that stores IP addresses in a
database as a uint. For some reason though, some addresses were coming
out as 0.0.0.0, despite the fact that if(ip == 0) return; in the only
place it actually saves them (which was
On Thu, Mar 28, 2013 at 09:03:07PM +0100, Adam D. Ruppe wrote:
> I was working on a project earlier today that stores IP addresses in
> a database as a uint. For some reason though, some addresses were
> coming out as 0.0.0.0, despite the fact that if(ip == 0) return; in
> the only place it actuall
On Thursday, 28 March 2013 at 22:22:49 UTC, Chris Cain wrote:
---
ubyte[T.sizeof] toUbytes(T)(T val) @safe {
ubyte[T.sizeof] buf;
std.bitmanip.append!T(buf[], val);
return buf;
}
---
This should be:
ubyte[T.sizeof] toUbytes(T)(T val) @safe {
ubyte[T.sizeof] buf;
import std.
On Thursday, 28 March 2013 at 20:24:50 UTC, Vidar Wahlberg wrote:
A bit on the side: It seems to me as importing std.bitmanip
somehow adds new properties to my array (".read()" and
".write()", for example). Not necessarily a bad thing, more of
"I've not seen this before, I was expecting that I
On Thursday, 28 March 2013 at 22:22:49 UTC, Chris Cain wrote:
Sorry about the repeated postings ... I'm trying to read &
answer it while also dealing with the norovirus :x
Been there. Not amusing, I wish you well.
"why is this done like this, couldn't it be done much easier?".
Maybe. What
On Friday, March 29, 2013 00:38:25 Vidar Wahlberg wrote:
> I don't get why you need to drag in std.array.appender() for
> std.bitmanip.append(), when you don't need it for read() and
> write().
Because read and write operate in place, and append doesn't. read and write
operate on input ranges - r
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
> Maybe it's time to introduce cast(signed) or cast(unsigned) to the
> language, as bearophile suggests?
It's not terribly pretty, but you can always do this
auto foo = cast(Unsigned!(typeof(var))var;
or
auto bar = to!(Unsigned!(typeof(var)
On Friday, 29 March 2013 at 01:18:03 UTC, Jonathan M Davis wrote:
It's not terribly pretty, but you can always do this
We could also do more C++ looking:
unsigned_cast!foo or IFTI or whatever;
On Friday, March 29, 2013 02:19:49 Adam D. Ruppe wrote:
> On Friday, 29 March 2013 at 01:18:03 UTC, Jonathan M Davis wrote:
> > It's not terribly pretty, but you can always do this
>
> We could also do more C++ looking:
>
> unsigned_cast!foo or IFTI or whatever;
It would be pretty trivial to add
On Thursday, 28 March 2013 at 22:12:57 UTC, H. S. Teoh wrote:
Also, I don't like repeating types, precisely for this reason;
if that second line had been written:
Yeah, I usually don't either, but apparently I did here. Murphy's
law at work perhaps!
On Thursday, 28 March 2013 at 21:58:05 UTC, bearophile wrote:
I didn't write a Bugzilla request to remove the implicit
uint==>int assignment. (I think the signed-unsigned comparisons
are more dangerous than those signed-unsigned assignments. But
maybe too is a problem with no solution).
Oh ma
On Thursday, 28 March 2013 at 22:04:36 UTC, Timon Gehr wrote:
- Copypasta & edit instead of string mixins / static foreach.
Part of why I did it this way was the annoyance that I can't do a
variadic template in an interface. I'd REALLY prefer to do it
that way so there wouldn't be a list of t
Just wondering what's the status of the new std.uni. Isn't it supposed
to be going through review right now? Or was it merged and I missed it?
I'd *really* like to have it in the next release. Can we kickstart its
review and inclusion in Phobos ASAP?
T
--
The peace of mind---from knowing that v
Definitely need to add some updates to the docs. Long story:
D provides an iterable interface called a Range. There are two
base forms, inputRange and outputRange.
Dynamic Arrays have the privilege of being, a inputRange,
outputRange, and a container.
An array however doesn't operate as you
On Thursday, March 28, 2013 19:05:49 H. S. Teoh wrote:
> Just wondering what's the status of the new std.uni. Isn't it supposed
> to be going through review right now? Or was it merged and I missed it?
> I'd *really* like to have it in the next release. Can we kickstart its
> review and inclusion i
On Friday, March 29, 2013 03:11:08 Jesse Phillips wrote:
> The write function seems a little odd as it uses random access
> (indexing).
>
> Instead of assigning to front like append does it assigns at
> index buffer[0]...
That's because it's operating on multiple bytes at a time (e.g. writing the
On Friday, 29 March 2013 at 01:13:36 UTC, Jonathan M Davis wrote:
In either case, I'd suggest reading this if you want to know
more about
ranges:
http://ddili.org/ders/d.en/ranges.html
Thank you, I will read that (when the time is not 0400).
I feel I need to stress that this is something that
On Friday, March 29, 2013 04:01:40 Vidar Wahlberg wrote:
> Or is it
> unthinkable that I mistook arrays and Ranges for being
> interchangeable when the examples pass an array to a function
> that takes a Range?
I don't think that it's unthinkable at all (and arrays _are_ ranges; it's just
that in
On Thursday, 28 March 2013 at 18:24:19 UTC, Timon Gehr wrote:
Yes; DMD is buggy and the specification is insufficient.
Currently the meaning of D code as interpreted by DMD may
depend on the order the modules are passed to the compiler on
the command line.
Can you have a look at http://wiki
On Friday, 29 March 2013 at 01:18:03 UTC, Jonathan M Davis wrote:
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
Maybe it's time to introduce cast(signed) or cast(unsigned) to
the
language, as bearophile suggests?
It's not terribly pretty, but you can always do this
auto foo = cast(U
import core.thread;
import core.time;
import std.datetime;
import std.stdio;
void main()
{
StopWatch sw;
sw.start();
Thread.sleep(dur!"seconds"(1));
Thread.sleep(dur!"msecs"(200));
Thread.sleep(dur!"usecs"(800));
sw.stop();
TickDuration time = sw.peek();
long secs
There are many many time formats. Do you want them all readily
supported?
On 3/28/2013 6:17 PM, Jonathan M Davis wrote:
On Thursday, March 28, 2013 15:11:02 H. S. Teoh wrote:
Maybe it's time to introduce cast(signed) or cast(unsigned) to the
language, as bearophile suggests?
It's not terribly pretty, but you can always do this:
http://dlang.org/phobos/std_traits.h
On Thursday, 28 March 2013 at 06:13:17 UTC, js.mdnq wrote:
I would like to get into writing apps for android and would
like to choose D for this if it is mature enough.
What is the D progress on the android?
I see that at least others are interested but not finding a ton
of information:
htt
66 matches
Mail list logo
