On Wednesday, 28 February 2018 at 22:55:19 UTC, Seb wrote:
On Wednesday, 28 February 2018 at 21:47:40 UTC, Cym13 wrote:
On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:
I know Python's `with` statement can be used to have an
automatic close action:
```
with open("x.txt") as fi
On Wednesday, 28 February 2018 at 21:47:40 UTC, Cym13 wrote:
On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:
I know Python's `with` statement can be used to have an
automatic close action:
```
with open("x.txt") as file:
#do something with file
#`file.close()` call
On Wednesday, 28 February 2018 at 22:00:11 UTC, meppl wrote:
On Wednesday, 28 February 2018 at 21:47:40 UTC, Cym13 wrote:
On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:
[...]
Others have discussed that particular case at length, but to
provide a more generic answer the correct
On Wednesday, 28 February 2018 at 21:47:40 UTC, Cym13 wrote:
On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:
[...]
Others have discussed that particular case at length, but to
provide a more generic answer the correct way to translate a
python context manager is to use scope(ou
On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:
I know Python's `with` statement can be used to have an
automatic close action:
```
with open("x.txt") as file:
#do something with file
#`file.close()` called automatically
```
I know D's `with` statement does somethi
On Wed, Feb 28, 2018 at 09:36:33PM +0100, Robert M. Münch via
Digitalmars-d-learn wrote:
[...]
> Yes, that's what the docs state. And I can imagin this. Bit this
> sentence is a bit hard to understand: "If fun is not a
> string, unaryFun aliases itself away to fun." Whatever this means.
[...]
Tha
On Wednesday, 28 February 2018 at 17:34:49 UTC, Enjoys Math wrote:
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0
skipped ==
For some reason, idk why, PyD is a dub source dependency (as
opposed to a library). If you add \path\to\pyd to the include
directory(?) dub variable (
On 2018-02-28 18:25:37 +, Steven Schveighoffer said:
unaryFun is a template that returns a callable item.
That far I made it too :-)
It could be a struct with an opCall, it could be a function template,
it could be an alias to a real function, it could be a function
pointer, delegate, e
On 2018-02-28 18:09:41 +, H. S. Teoh said:
Basically, the `alias f` is a catch-all template parameter that can
bind to basically anything that has a symbol. It's typically used to
bind to functions, delegates, and lambdas.
Aha... ok that makes it a bit more clear. So, if I have:
auto myFu
On 2/28/18 3:00 PM, Kagamin wrote:
On Tuesday, 27 February 2018 at 19:56:44 UTC, Steven Schveighoffer wrote:
cast(void*)1 is likely to be unused.
And since there was a word about class, cast(Class)cast(void*)1 won't
compile :)
Oh, and it has a horrible message! Says you can't cast void * to
On 02/28/2018 11:22 AM, Nordlöw wrote:
On Tuesday, 27 February 2018 at 20:14:01 UTC, Ali Çehreli wrote:
And to be sure, one can have an actual object that represents nullness
and use its pointer. (Similar to "the null object pattern".)
Ali
Are there any pros to this pattern compared to just
On Wednesday, 28 February 2018 at 19:22:12 UTC, Nordlöw wrote:
Are there any pros to this pattern compared to just using
`null` in D?
When null is already used to mean something else.
On Tuesday, 27 February 2018 at 19:56:44 UTC, Steven
Schveighoffer wrote:
cast(void*)1 is likely to be unused.
And since there was a word about class, cast(Class)cast(void*)1
won't compile :)
On 2018-02-28 18:01:50 +, TheFlyingFiddle said:
Testing this with:
auto foo(alias f, A)(auto ref A a) { return f(a); }
I can call foo either like this:
foo!(x => x + x)(1);
or
1.foo!(x => x + x);
but these will give errors
foo(1, x => x + x); //Error
1.foo(x => x + x); // Error
I don't
On Tuesday, 27 February 2018 at 20:14:01 UTC, Ali Çehreli wrote:
And to be sure, one can have an actual object that represents
nullness and use its pointer. (Similar to "the null object
pattern".)
Ali
Are there any pros to this pattern compared to just using `null`
in D?
On Wednesday, 28 February 2018 at 18:23:04 UTC, Jiyan wrote:
Hey,
i thought i had understood postblit, but in my Code the
following is happening (simplified):
struct C
{
this(this){/*Do sth*/}
list!C;
void opAssign(const C c)
{
"Postlbit from C called".writeln;
// Do sth
}
}
Sry of course
On 2/28/18 12:47 PM, Robert M. Münch wrote:
Hi, I'm lost reading some code:
A a;
auto do(alias f, A)(auto ref A _a){
alias fun = unaryFun!f;
return ...
...
}
How is this alias stuff working? I mean what's the type of f? Is it an
anonymous function which then gets checked to be
Hey,
i thought i had understood postblit, but in my Code the following
is happening (simplified):
struct C
{
this(this){/*Do sth*/}
list!C;
void opAssign(const C c)
{
"Postlbit from C called".writeln;
// Do sth
}
}
struct list(T)
{
node* head;
node* last;
size_t size;
struct node
{
T val;
On Wed, Feb 28, 2018 at 06:47:22PM +0100, Robert M. Münch via
Digitalmars-d-learn wrote:
> Hi, I'm lost reading some code:
>
> A a;
>
> auto do(alias f, A)(auto ref A _a){
> alias fun = unaryFun!f;
> return ...
> ...
> }
>
> How is this alias stuff working? I mean what's the t
On Wednesday, 28 February 2018 at 17:47:22 UTC, Robert M. Münch
wrote:
Hi, I'm lost reading some code:
A a;
auto do(alias f, A)(auto ref A _a){
alias fun = unaryFun!f;
return ...
...
}
How is this alias stuff working? I mean what's the type of f?
Is it an anonymous fun
Hi, I'm lost reading some code:
A a;
auto do(alias f, A)(auto ref A _a){
alias fun = unaryFun!f;
return ...
...
}
How is this alias stuff working? I mean what's the type of f? Is it an
anonymous function which then gets checked to be unary? How is it
recognized in the
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0
skipped ==
For some reason, idk why, PyD is a dub source dependency (as
opposed to a library). If you add \path\to\pyd to the include
directory(?) dub variable (or -I\path\to\pyd to dmd/ldc/gdc) it
should hopefully work.
Seems
On Wednesday, 28 February 2018 at 16:58:38 UTC, Mike Parker wrote:
On Wednesday, 28 February 2018 at 16:47:49 UTC, Kayomn wrote:
Yeah, I knew they were deprecated, just weren't aware Derelict
doesn't load them. Thanks though, I'd been up and down the
Derelict docs page and I didn't see anyt
On Wednesday, 28 February 2018 at 16:47:49 UTC, Kayomn wrote:
Yeah, I knew they were deprecated, just weren't aware Derelict
doesn't load them. Thanks though, I'd been up and down the
Derelict docs page and I didn't see anything about this.
Yeah, I decided against documenting the older ver
On Wednesday, 28 February 2018 at 14:02:48 UTC, Mike Parker wrote:
On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote:
import derelict.opengl3.gl3;
Whoa. Just noticed this. That's an older version of DerelictGL3
you're using there. You should really be using the latest
version of
On Wednesday, February 28, 2018 14:28:47 bauss via Digitalmars-d-learn
wrote:
> On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
> > done https://issues.dlang.org/show_bug.cgi?id=18539
>
> I would argue that isn't a regression and that you __should__ use
> the .get and that it's not a w
I would say it is a still regression, but I agree with you, that it should
not work on the first place.
On Wed, Feb 28, 2018 at 3:28 PM, bauss via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
>
>> done https://issues
On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
done https://issues.dlang.org/show_bug.cgi?id=18539
I would argue that isn't a regression and that you __should__ use
the .get and that it's not a workaround, because nullable's
shouldn't be treated like that type they encapsulate.
On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote:
import derelict.opengl3.gl3;
Whoa. Just noticed this. That's an older version of DerelictGL3
you're using there. You should really be using the latest version
of both DerelictGL3 and DerelictGLFW3. The -alpha versions are
what I
On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote:
Is this a DerelictGL3 bug? Am I missing something else that I
should be initializing? Other things like glClear() seem to be
working fine.
No, not a bug. glBegin is one of the deprecated OpenGL functions.
DerelictGL3 these days do
done https://issues.dlang.org/show_bug.cgi?id=18539
Yes it is a regression, please fill a bug report
On Wed, Feb 28, 2018 at 2:16 PM, drug via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> https://run.dlang.io/is/HJxtvw
>
> ```
> import std.stdio, std.typecons, std.math;
> void main()
> {
> auto foo = nullable(2.0);
> a
https://run.dlang.io/is/HJxtvw
```
import std.stdio, std.typecons, std.math;
void main()
{
auto foo = nullable(2.0);
auto bar = nullable(2.0);
assert (foo.approxEqual(bar));
}
```
Comiling gives the following:
Up to 2.067.1: Failure with output:
-
onlineapp.d(4): Error: unde
On Wednesday, 28 February 2018 at 12:36:37 UTC, bauss wrote:
On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote:
[...]
Most likely a library issue. Are you sure that you link to the
libraries correctly etc.?
I'm using DUB for package management and linking and any library
loading
On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote:
Maybe I'm missing something, but whenever I attempt to call
glBegin() with anything my program immediately encounters an
access violation.
I've got a very simple setup, with this being my main:
import base.application;
import dere
Maybe I'm missing something, but whenever I attempt to call
glBegin() with anything my program immediately encounters an
access violation.
I've got a very simple setup, with this being my main:
import base.application;
import derelict.opengl3.gl3;
import derelict.glfw3.glfw3;
int main(string
36 matches
Mail list logo
