On Monday, 7 September 2015 at 09:06:05 UTC, Nordlöw wrote:
Is there a range in Phobos for accessing all unordered
combinations of a range as:
foreach (const i, const a; r)
{
for (auto j = i + 1; j < r.length; ++j)
{
const b = r[j];
// Use a and b
}
}
excluding
Let's say I have two dub packages: A and B.
A is a library. B is library or application (does not matter) and
depends on A.
A has several configurations in dub.json.
How to build the B package that way it will use non-default
configuration of A?
I encountered a runtime error in my code and all I can get (even
in debug mode) is the following stacktrace:
object.Error@(0): Access Violation
0x0051C308 in const(nothrow @trusted uint function(const(void*)))
object.TypeInfo_Interface.getHash
0x0058D2C0 in
On Monday, 7 September 2015 at 03:55:01 UTC, Meta wrote:
The name validator_t is not idiomatic in D. Something like
ValidatorFun should be preferred. Same for intReader_t;
ReadIntFun is probably preferred, or even IntReader (but that
would imply that it's a struct/class in my mind).
Noted.
On Sunday, 6 September 2015 at 15:15:03 UTC, chris stevens wrote:
I guess you're right it wouldn't be too difficult to do it all
using strings. The code generation I'd done before in c# I'd
used some 3rd person library where you build up an object model
rather than using strings.
Maybe with
On Saturday, 5 September 2015 at 01:43:43 UTC, Prudence wrote:
Any ideas?
See how vibe does it.
Is there a range in Phobos for accessing all unordered
combinations of a range as:
foreach (const i, const a; r)
{
for (auto j = i + 1; j < r.length; ++j)
{
const b = r[j];
// Use a and b
}
}
excluding self-pairs, that is i != j
It seems to me a good practice to mark all functions that I write
as `pure` and define all the variables as `immutable`, unless
there is a reason not to.
I can see some serious advantages of this, most notable of which
is minimum side-effect and predictability of the code. However I
suppose
On Monday 07 September 2015 13:12, Bahman Movaqar wrote:
> I was under the impression that when a variable, that is declared
> as `immutable`, is passed to a function, a copy of the value is
> passed.
>
> However based on "marks" I can imagine that since the data is
> marked as `immutable`
On 9/6/15 3:34 AM, ParticlePeter wrote:
I am working on a struct vector. The data is stored in a member static
array and I want to be able to forward all array properties except
length to vector.
Reason is I have free functions f that take vector(s) as arguments, such
that f(vector) and vector.f
I am working on a simple project created with DUB[1].
When unit tests the output reads really cryptic to me; for
example:
$ dub test
Generating test runner configuration '__test__library__' for
'library' (library).
Target dunit 1.0.11 is up to date. Use --force to rebuild.
On Monday, 7 September 2015 at 12:16:14 UTC, anonymous wrote:
On Monday 07 September 2015 14:12, Bahman Movaqar wrote:
Thanks. This is indeed helpful. OT but where can I view the
documentation for `unittest` and `assert`?
unittest: http://dlang.org/unittest.html
assert:
On Monday 07 September 2015 13:57, Bahman Movaqar wrote:
> I am working on a simple project created with DUB[1].
> When unit tests the output reads really cryptic to me; for
> example:
>
> $ dub test
[...]
> core.exception.AssertError@source/e002.d(111): unittest
> failure
[...]
>
>
On Monday, 7 September 2015 at 11:49:32 UTC, anonymous wrote:
void f(int a) {}
void g(int* a) {}
void main()
{
int xm;
immutable int xi;
f(xm); /* ok, obviously */
f(xi); /* ok */
int* ym =
immutable int* yi =
g(ym); /* ok, obviously */
g(yi); /* doesn't
On Monday, 7 September 2015 at 11:57:25 UTC, Bahman Movaqar wrote:
I am working on a simple project created with DUB[1].
When unit tests the output reads really cryptic to me; for
example:
Try using DUnit, it gives you much more readable fail messages:
https://github.com/nomad-software/dunit
On Monday, 7 September 2015 at 09:12:53 UTC, cym13 wrote:
There is an open bug for that
https://issues.dlang.org/show_bug.cgi?id=6788
Thanks.
So I construct a pairwise range with two implementation cases one
for RandomAccessRange and one for InputRange
On Monday 07 September 2015 12:40, Bahman Movaqar wrote:
> It seems to me a good practice to mark all functions that I write
> as `pure` and define all the variables as `immutable`, unless
> there is a reason not to.
I agree.
> I can see some serious advantages of this, most notable of which
On Monday, 7 September 2015 at 08:55:31 UTC, Fra wrote:
I encountered a runtime error in my code and all I can get
(even in debug mode) is the following stacktrace:
object.Error@(0): Access Violation
0x0051C308 in const(nothrow @trusted uint
function(const(void*)))
On Monday, 7 September 2015 at 10:55:13 UTC, anonymous wrote:
On Monday 07 September 2015 12:40, Bahman Movaqar wrote:
I can see some serious advantages of this, most notable of
which is minimum side-effect and predictability of the code.
However I suppose it's going to impact the performance
On Monday, 7 September 2015 at 12:06:09 UTC, anonymous wrote:
On Monday 07 September 2015 13:57, Bahman Movaqar wrote:
$ dub test
[...]
core.exception.AssertError@source/e002.d(111): unittest
failure
[...]
From that one line I left intact above, you should also be able
to figure
On Monday, 7 September 2015 at 12:58:58 UTC, Gary Willoughby
wrote:
On Monday, 7 September 2015 at 11:57:25 UTC, Bahman Movaqar
wrote:
I am working on a simple project created with DUB[1].
When unit tests the output reads really cryptic to me; for
example:
Try using DUnit, it gives you much
Hi.
Is there a more elegant way to write the template arg
restrictions for display?
Thanks.
Laeeth
import std.stdio;
import std.traits;
struct Bar(bool test)
{
double a;
static if(test)
double b;
}
void display(T)(T a)
if (__traits(isSame, TemplateOf!(T),
On Sunday, 6 September 2015 at 23:05:29 UTC, Jonathan M Davis
wrote:
[...] which makes treating some of this stuff in a
cross-platform fashion quite difficult.
And even more with ACLs that it could be:
On windows, to know properly if something is readable or writable
the attributes are not
On Monday 07 September 2015 17:51, Laeeth Isharc wrote:
> Is there a more elegant way to write the template arg
> restrictions for display?
[...]
> void display(T)(T a)
> if (__traits(isSame, TemplateOf!(T), Bar))
> {
> writefln("%s",a);
> }
if (isInstanceOf!(Bar, T))
On Sunday, 6 September 2015 at 23:05:29 UTC, Jonathan M Davis
wrote:
http://dlang.org/phobos/std_file.html#.getAttributes will get
you all of the file attributes for a file, though you'll have
to look at the Windows and POSIX documentation to know how to
interpret that.
- Jonathan M Davis
On Sunday, 6 September 2015 at 20:40:04 UTC, Gary Willoughby
wrote:
Are there any Phobos functions to check file permissions on
Windows and Posix? For example, I want to check if a file is
readable and/or writable in a cross-platform fashion. Does
anyone have an example?
Call fopen and check
I need some help understand the behaviour of my code[1].
Specifically I have trouble with `add` method on line 79.
My impression is that since it returns `this`, multiple
invocations can be chained like `obj.add(X).add(Y).add(Z)`.
However the test on line 92 fails and if I do a `writeln`,
On 2015-09-07 16:44, Bahman Movaqar wrote:
Does this mean that in the following piece of code, what is passed to
`add` is actually a copy of `rec1`?
auto rec1 = SalesRecord("p10", 1.0, 10);
coll.add(rec1);
Yes. structs have value semantics. If you want reference semantics you
might
On Monday, 7 September 2015 at 14:54:04 UTC, Jacob Carlborg wrote:
On 2015-09-07 16:44, Bahman Movaqar wrote:
Does this mean that in the following piece of code, what is
passed to
`add` is actually a copy of `rec1`?
auto rec1 = SalesRecord("p10", 1.0, 10);
coll.add(rec1);
Yes.
On Monday, 7 September 2015 at 14:12:25 UTC, Bahman Movaqar wrote:
I need some help understand the behaviour of my code[1].
Specifically I have trouble with `add` method on line 79.
My impression is that since it returns `this`, multiple
invocations can be chained like
On Monday, 7 September 2015 at 14:26:57 UTC, mzf wrote:
On Monday, 7 September 2015 at 14:12:25 UTC, Bahman Movaqar
wrote:
struct is a value type,you can convert to ref type by "ref":
struct Test
{
int a;
Test add1()
{
a++;
return
On Monday, 7 September 2015 at 14:12:25 UTC, Bahman Movaqar wrote:
I need some help understand the behaviour of my code[1].
Specifically I have trouble with `add` method on line 79.
My impression is that since it returns `this`, multiple
invocations can be chained like
On Monday, 7 September 2015 at 14:28:06 UTC, Namespace wrote:
On Monday, 7 September 2015 at 14:12:25 UTC, Bahman Movaqar
wrote:
Structs are value types and therefore you return only a copy
currently.
Does this mean that in the following piece of code, what is
passed to `add` is actually a
On that note, is there also any generic translation software for
code that you can program a set of simple "rules"(matching and
arranging) to translate source code?
e.g., match("const WM_", ";")->WM.add(%1 + ",")).
The above should be obvious but essentially it matches the first
string until
On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote:
const WM_* -> add to enum WM;
else WM_* -> WM.*
I'm against that. The documentation all says WM_* and we
shouldn't muck with it.
const -> enum is a good idea though. These headers were all
written way back when when const and
Windows headers contain a ton of global const's for the various
messages. Seems like a very bad way to go about this.
Could one not simply put all these in an enum? e.g., enum WM {
WM_CREATE = 1, etc... }?
If so, because there are so many and so many references to them,
this can't be done
On Monday, 7 September 2015 at 16:27:21 UTC, anonymous wrote:
On Monday 07 September 2015 17:51, Laeeth Isharc wrote:
Is there a more elegant way to write the template arg
restrictions for display?
[...]
void display(T)(T a)
if (__traits(isSame, TemplateOf!(T), Bar))
{
On Monday, 7 September 2015 at 20:55:25 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:
It's called encapsulation. It prevents namespace pollution and
identifier collision.
This is already provided by the D module system. Even if you
were to define a
On Monday, 7 September 2015 at 22:21:28 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:
Oh, and who says you couldn't keep both systems?
Nobody. There's absolutely nothing stopping you from defining
your one constants and bindings. I think you should
On Monday, 7 September 2015 at 23:11:36 UTC, Prudence wrote:
I asked is there is an easy way to do it, and you replied that
essentially that it shouldn't be changed because it would
change things.
I also said:
I guessing one would need a D or C parser to deal with all
this?
hackerpilot's
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:
Again, it's called progress. Why keep using the same defunct
system for endless years simply because that's the way it was
done?
Any C library binding should maintain the same interface as the C
library as much as possible. That
Fixed it by changing into:
```
import std.conv : text;
string json =
File("../languages.json","r").byLineCopy().joiner.text;
auto ls = json.parseJSON();
```
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote:
Oh, and who says you couldn't keep both systems?
Nobody. There's absolutely nothing stopping you from defining
your one constants and bindings. I think you should actually do
it and see for yourself the pros and cons in practice.
On Mon, 2015-09-07 at 02:56 +, Charles via Digitalmars-d-learn
wrote:
> […]
>
> x = float[imax][jmax]; //x is about 8 GB of floats
> for(j = 0; j < jmax; j++){
> //create some local variables.
> for(i = 0; i < imax; i++){
> x[j][i] = complicatedFunction(i, x[j-1], other, local,
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:
It's called encapsulation. It prevents namespace pollution and
identifier collision.
This is already provided by the D module system. Even if you were
to define a WM_CREATE in your code, it would not cause a major
problem with the
On Sunday, 6 September 2015 at 22:04:55 UTC, Namal wrote:
oh, sorry. But I found out what I have been doing wrong besides
that.
arr.sort.uniq;
uniq(arr) or arr.sort.uniq; compiles but doesn't store it in
the arr array, I need to store it in a new one.
Right, it's like
int x = 3;
// x + 5;
On Monday, 7 September 2015 at 10:25:09 UTC, deed wrote:
writeln(x);// or you can pass it to a function.
I meant `writeln(x + 5)`
On Monday 07 September 2015 14:12, Bahman Movaqar wrote:
> Thanks. This is indeed helpful. OT but where can I view the
> documentation for `unittest` and `assert`?
unittest: http://dlang.org/unittest.html
assert: http://dlang.org/expression.html#AssertExpression (I don't know why
it's
On Monday, 7 September 2015 at 12:16:14 UTC, anonymous wrote:
On Monday 07 September 2015 14:12, Bahman Movaqar wrote:
Thanks. This is indeed helpful. OT but where can I view the
documentation for `unittest` and `assert`?
unittest: http://dlang.org/unittest.html
assert:
On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote:
because it is confusing and hard for you to understand over
Nope, I'm saying it is a pointless change. If you do that, EVERY
time you want to look something up, you need to rewrite WM.* into
WM_* since that's what the docs say. And
On Monday 07 September 2015 21:06, Prudence wrote:
> If you think mentally changing a . to a _ is a hassle then your
> in trouble! An apple a day simply won't help!
[...]
> Oh well, some people
> just don't like progress! Do you want to go back to using wooden
> wheels too?
[...]
> Get out of
07.09.2015 21:37, Benjamin Thaut пишет:
snip
So far I haven't found a situation where I couldn't make it work the way
I wanted. Its just some work to write the D headers for the C++ classes
and vise versa, because you have to duplicate everything once more. An
automated tool for this would be
On Friday, 4 September 2015 at 16:19:49 UTC, Laeeth Isharc wrote:
Hi Benjamin
Would you be able to give a little more colour on what the
limits are of interoperability for C++ with DMD master or
release ? As I understand it destructors and constructors
don't work, and obviously it will get
On Monday, 7 September 2015 at 17:59:43 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote:
const WM_* -> add to enum WM;
else WM_* -> WM.*
I'm against that. The documentation all says WM_* and we
shouldn't muck with it.
huh?
Are you saying you don't
On Monday, 7 September 2015 at 18:58:08 UTC, Adam D. Ruppe wrote:
On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote:
because it is confusing and hard for you to understand over
Nope, I'm saying it is a pointless change. If you do that,
EVERY time you want to look something up, you
55 matches
Mail list logo
