On Mon, 2014-08-18 at 23:12 +, Laeeth Isharc via Digitalmars-d-learn
wrote:
[…]
For me, NumPy has some serious problems despite being the
accepted norm for computational work.
If not too offtopic, do you have a link describing, or would you
briefly summarize these problems? I am
On Tue, 2014-08-19 at 00:53 +, bachmeier via Digitalmars-d-learn
wrote:
[…]
I'm not sure which computational work he is referring to, but for
statistical analysis, R dominates by a wide margin (although
statistical analysis done in Silicon Valley, the type you read
about on Hacker News,
On Monday, 18 August 2014 at 17:47:21 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 18 Aug 2014 13:51:12 +
nrgyzer via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
When I try to compile this sample application I'm getting the
following error:
sample.d(7): Error:
On Tue, 19 Aug 2014 08:04:54 +
nrgyzer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
goto-instruction. The same regards the scoping... it's simply to
much overhead.
it's a matter of taste, i think. i myself find 'scope(exit)' excellent,
'cause i'm always keep forgeting
nrgyzer:
Sure, I can also use nested functions, but in my opinion it
results in dirty and complex code. It's totally overkilled
compared to a simple if and goto-instruction.
Often nested functions are less complex, more clean and simpler
code compared to using gotos. I suggest to start
On Monday, 18 August 2014 at 20:50:55 UTC, Nordlöw wrote:
On Monday, 18 August 2014 at 12:42:25 UTC, monarch_dodra wrote:
If you are using a string, the only thing helpful in there is
`byCodeunit`. The rest is only useful if you have actual
ranges.
Actual ranges of...characters and strings?
On Tuesday, 19 August 2014 at 08:23:53 UTC, monarch_dodra wrote:
You could define your own range of chars, for example, a
rope. Or, you want to store your string in a deterministic
container (Array!char). These would produce individual code
units, but you'd still need them to be interpreted
On Tuesday, 19 August 2014 at 00:55:24 UTC, Idan Arye wrote:
On Tuesday, 19 August 2014 at 00:54:25 UTC, Idan Arye wrote:
On Monday, 18 August 2014 at 21:17:11 UTC, Jonathan M Davis
wrote:
On Monday, 18 August 2014 at 21:02:09 UTC, Gary Willoughby
wrote:
In the new D release there have been
On Tuesday, 19 August 2014 at 16:04:15 UTC, Gary Willoughby wrote:
This kind of makes sense for `dup` because that could be
applied across types but what about rehash, byKey, byValue,
keys, values, etc of AA's? Surely these will only be used by
AA's? Is this more about speed optimisation?
I
On Monday, 18 August 2014 at 21:17:11 UTC, Jonathan M Davis wrote:
On Monday, 18 August 2014 at 21:02:09 UTC, Gary Willoughby
wrote:
In the new D release there have been some changes regarding
built-in types.
http://dlang.org/changelog.html?2.066#array_and_aa_changes
I would like to learn
On 08/19/2014 01:04 AM, nrgyzer wrote:
On Monday, 18 August 2014 at 17:47:21 UTC, ketmar via
but why do you need gotos at the first place? i'm not saying that you
must avoid gotos at all costs!, but D has some nice features like
scope(exit), scope(success), scope(failure) and nested
shared int[] foo;
auto bar() {
foo ~= 42;
return foo.idup;
}
Error: cannot implicitly convert element type shared(int) to
immutable in foo.idup
Is this not correct? If I instead dup'd an array of ints (or some
other non-reference elements) and cast to immutable, would I be
in
Hi,
i'm trying to create a dynamic vertex format for opengl, defined
at compiletime by a struct
e.g. struct Vertex {float[3] position, float[3] normal}
i can get the name of all members with this:
auto b = [ __traits(allMembers, VertexType) ];
but i can't iterate them at compiletime because
On Tue, 19 Aug 2014 18:15:33 +, ddos wrote:
since i need to setup vertexpointers for opengl at runtime my next
question? - is it possible to evaluate the traits also at runtime? but
i'd also like to know how i can iterate them at compiletime
thx in advance :)
Take a look at this
On Tuesday, 19 August 2014 at 18:25:24 UTC, Justin Whear wrote:
On Tue, 19 Aug 2014 18:15:33 +, ddos wrote:
since i need to setup vertexpointers for opengl at runtime my
next
question? - is it possible to evaluate the traits also at
runtime? but
i'd also like to know how i can iterate
A foreach becomes compile-time whenever the aggregate is a purely compile-
time construct such as a tuple.
Yeah, I think you transformed it into a runtime array by using [ ...
]. Tuples with compatible types can be 'downgraded' to arrays that
way. But there is no need to: tuples are iterable,
On Tuesday, 19 August 2014 at 17:56:31 UTC, Low Functioning wrote:
shared int[] foo;
auto bar() {
foo ~= 42;
return foo.idup;
}
Error: cannot implicitly convert element type shared(int) to
immutable in foo.idup
Is this not correct? If I instead dup'd an array of ints (or
some
On Tuesday, 19 August 2014 at 16:28:54 UTC, monarch_dodra wrote:
Actually, the new free functions *are* properties. All that you
just declared is valid, but we never got around to doing it.
Walter (If I remember correctly) was opposed.
So right now, even if dup is a free function,
On Tuesday, 19 August 2014 at 19:00:49 UTC, Marc Schütz wrote:
On Tuesday, 19 August 2014 at 17:56:31 UTC, Low Functioning
wrote:
shared int[] foo;
auto bar() {
foo ~= 42;
return foo.idup;
}
Error: cannot implicitly convert element type shared(int) to
immutable in foo.idup
Is
On Monday, 18 August 2014 at 13:51:14 UTC, nrgyzer wrote:
Hi all,
I've the following code snipped:
import std.bigint;
void main(string[] args)
{
BigInt i = 12345;
if (args.length 1)
{
goto Exit;
}
i = BigInt(67890);
Exit:
On Tuesday, 19 August 2014 at 03:56:38 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 19 Aug 2014 03:37:23 +
Vladimir Panteleev via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
And Windows. Since, apparently, pragma(lib) is only supported
by COFF and OMF.
nope,
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like
On Wednesday, 20 August 2014 at 01:38:53 UTC, uri wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
I have another similar example illustrating this problem at
semantic level.
import std.stdio, std.typecons;
struct Test
{
//ref
Nullable!int prop() @property
{
return _value;
}
private Nullable!int _value = 10;
}
void
24 matches
Mail list logo
