Re: Real implicitly converts to float?
On Friday, 24 June 2016 at 20:10:16 UTC, Tofu Ninja wrote: I am glad I was not the only one who thought that sounded a little crazy... I thought D was supposed to be type safe. I think I will make a bug report and see where that goes. It is one of those cases where it made sense in C because it puts the burden on the programmer and the C-convention is to have the type in the name so it is "somewhat explicit" in C. C++ compilers solve this by having warning-options for float->double and also double->float conversions. The conversion becomes rather problematic if you use Infinity to mean an open-ended interval. It means that a closed interval can implicitly be converted into an open-ended interval... :-/
Re: Is there a dmd.exe x86_64 out there?
On 25/06/2016 5:57 AM, Dlangofile wrote: Hi all, I'm building a Docker Alpine linux image with wine, for being able to forge Windows executable from my laptop, without having to dual boot. With my disappointment, I'm not able to run 32bit executable from the container right now, so the easy way is running a win64 dmd.exe: someone can point me to a pre-build executable, based on the latest version? Thanks Umm, x86_64 is backwards compatible with x86. So if 32bit build of dmd doesn't work, you have bigger problems.
Re: Error: module ctype is in file 'std/ctype.d' which cannot be read - when running dmd
On Friday, 24 June 2016 at 21:06:30 UTC, cym13 wrote: On Friday, 24 June 2016 at 21:01:11 UTC, Roman wrote: I should probably add that only importing std.ctype causes the error. I have a bunch of other imports: import std.stdio, std.string, std.algorithm, std.conv, std.ctype, std.regex, std.range; If I remove std.ctype, it compiles just fine. std.ctype (as well as other c-specific bindings) was moved to core.stdc so just replace std.ctype by core.stdc.ctype and it should work as intended. Thank you, that worked.
Re: Error: module ctype is in file 'std/ctype.d' which cannot be read - when running dmd
I should probably add that only importing std.ctype causes the error. I have a bunch of other imports: import std.stdio, std.string, std.algorithm, std.conv, std.ctype, std.regex, std.range; If I remove std.ctype, it compiles just fine.
Re: Error: module ctype is in file 'std/ctype.d' which cannot be read - when running dmd
On Friday, 24 June 2016 at 21:01:11 UTC, Roman wrote: I should probably add that only importing std.ctype causes the error. I have a bunch of other imports: import std.stdio, std.string, std.algorithm, std.conv, std.ctype, std.regex, std.range; If I remove std.ctype, it compiles just fine. std.ctype (as well as other c-specific bindings) was moved to core.stdc so just replace std.ctype by core.stdc.ctype and it should work as intended.
Error: module ctype is in file 'std/ctype.d' which cannot be read - when running dmd
I've just tried to compile a program with `rdmd`, but get the following error: count_words.d(1): Error: module ctype is in file 'std/ctype.d' which cannot be read import path[0] = . import path[1] = /home/roman/dlang/dmd-2.071.0/linux/bin64/../../src/phobos import path[2] = /home/roman/dlang/dmd-2.071.0/linux/bin64/../../src/druntime/import The error is due to the `import std.ctype` statement that I have. If I remove everything else from the file and leave just that, the error persists, so it's clearly the only reason why I'm getting this error. A quick Google search led me to this old thread: http://forum.dlang.org/thread/imn3fg$2nve$1...@digitalmars.com, however it seems the issues wasn't resolved for that person. It looks like I'm having the same issue. To further explain the situation: 1. I'm on Ubuntu 16.04 2. I've installed D with the installation script `curl -fsS https://dlang.org/install.sh | bash -s dmd` from here https://dlang.org/download.html 3. I've followed the installation script suggestion and ran `source ~/dlang/dmd-2.071.0/activate` 4. Both dirs that show up in the error output do exist and contain files and other dirs. I haven't changed anything, the installation script put it there. And it doesn't work. Would appreciate any help.
Re: Real implicitly converts to float?
On Friday, 24 June 2016 at 20:10:16 UTC, Tofu Ninja wrote: I am glad I was not the only one who thought that sounded a little crazy... I thought D was supposed to be type safe. I think I will make a bug report and see where that goes. https://issues.dlang.org/show_bug.cgi?id=16202
Re: Real implicitly converts to float?
On Friday, 24 June 2016 at 08:52:48 UTC, Ola Fosheim Grøstad wrote: This is so wrong. _especially_ when you have parameter overloading/templates. It means that you accidentally can trash a computation by getting the wrong function. That is not type-safe in my book. Jonathan's max-value example is a good one. The distinction between infinity and a large actual value is an important one. I am glad I was not the only one who thought that sounded a little crazy... I thought D was supposed to be type safe. I think I will make a bug report and see where that goes.
Re: GTKD - CSS class color "flash" delay
On Friday, 24 June 2016 at 16:44:59 UTC, Gerald wrote:
Other then the obvious multi-threaded, using glib.Timeout to
trigger the reversion of the color change could be an option.
http://api.gtkd.org/src/glib/Timeout.html
Thanks! I tried this so far:
private void letButtonsFlash(){
foreach(Button btn;bArr){
btn.setSensitive(false);
}
for(int i = 0; i < level; i++){
Button currentButton = bArr[rndButtonBlink[i]];
ListG list =
currentButton.getStyleContext().listClasses();
string CSSClassName =
to!string(cast(char*)list.next().data);
currentButton.getStyleContext().addClass(CSSClassName
~ "-flash");
writeln(CSSClassName);
Timeout t = new Timeout(&timeout_delay,1,true);
currentButton.getStyleContext().removeClass(CSSClassName ~
"-flash");
}
foreach(Button btn;bArr){
btn.setSensitive(true);
}
}
bool timeout_delay(){
Thread.sleep(dur!("seconds")(5));
return false;
}
and it is "working" to the extend that at least the CSSClassName
gets written in the console but the UI again just pops up after 5
sec. Could you give me a tip?
Re: Get calling this, if exists
On 06/24/2016 10:19 AM, Smoke Adams wrote:
> We have __FUNCTION__ so, __THIS__ seems somewhat natural. Null for
> outside of objects is fine.
Would the following work, where you check the first argument?
import std.stdio;
void Log(string filename = __FILE__, T...)(T args)
{
static if (is (T[0] == typeof(null))) {
writefln("working without an object for %s", args[1 .. $]);
} else static if (is (T[0] == class)) {
writefln("working with object %s and %s", args[0], args[1 .. $]);
} else {
// Recurse
import std.meta : AliasSeq;
return Log!filename(AliasSeq!(null, args));
}
}
class C {
}
void main() {
Log(42, "hello");
auto c = new C();
Log(c, "cool");
c.Log("breeze");
}
The output:
working without an object for 42
working with object deneme.C and cool
working with object deneme.C and breeze
Ali
Is there a dmd.exe x86_64 out there?
Hi all, I'm building a Docker Alpine linux image with wine, for being able to forge Windows executable from my laptop, without having to dual boot. With my disappointment, I'm not able to run 32bit executable from the container right now, so the easy way is running a win64 dmd.exe: someone can point me to a pre-build executable, based on the latest version? Thanks
Re: Get calling this, if exists
On 6/24/16 1:19 PM, Smoke Adams wrote:
The problem with UFCS is that I am using variadic parameters. The
logging function isn't designed to accept the first parameter as this.
Then you would need to change it?
It would be much easier to simply have the compiler "insert" it using
__THIS__. Just because it isn't constant isn't really that big of a deal
to the compiler. It could just manually add the parameter at the end of
of the arguments.
Yes, easier for you not having to do anything. It's only the compiler
writers who have to figure out how to add this feature for you :)
I would also have to convert all the calls to this.log.
This becomes problematic because not not all calls are inside objects.
Possibly you can use overloads. In any case, I think there is some work
you need to do to get what you want.
We have __FUNCTION__ so, __THIS__ seems somewhat natural. Null for
outside of objects is fine.
__FUNCTION__ is still a compile-time constant.
Have you considered a mixin or opDispatch to help you out? (untested)
mixin template addLog()
{
log(this This, T...)(T args)
{
return .log(cast(This)this, args);
}
}
class MyBaseObj
{
mixin addLog;
}
class MyObj : MyBaseObj
{
void foo()
{
log(1, 2, 3); // calls .log(cast(MyObj)this, 1, 2, 3)
}
}
-Steve
Re: Get calling this, if exists
On Friday, 24 June 2016 at 15:35:57 UTC, Steven Schveighoffer
wrote:
On 6/24/16 11:15 AM, Smoke Adams wrote:
On Friday, 24 June 2016 at 03:16:58 UTC, Meta wrote:
On Friday, 24 June 2016 at 03:10:51 UTC, Mike Parker wrote:
Oh, perhaps I misunderstood your question. Do you meant this:
class Foo() {
void bar() { Log(); } // Pass reference to Foo instance
}
void doSomething() { Log(); } // Null reference
If so, the answer is no. And I don't see how that could work
as a
compile time parameter, given that the reference itself is a
runtime
value.
It actually is possible. You just have to be explicit.
void log(alias self)(string s)
{
pragma(msg, self.stringof);
}
struct Test
{
void test(string s)
{
log!this(s);
}
}
void main()
{
Test t;
t.test("asdf");
}
I don't want to be explicit! One can be explicit with __FILE__
too but
one doesn't have to be.
__FILE__ is a constant, so is __LINE__. __THIS__ would not be,
so this is somewhat different.
With UFCS, you can get close:
void log(T)(T obj, string s)
{
...
}
struct Test
{
void test(string s)
{
this.log(s);
}
}
But I believe you have to call with explict 'this'.
Perhaps an opDispatch can help, but seems an awful lot to avoid
explicit passing of this variable.
-Steve
The problem with UFCS is that I am using variadic parameters. The
logging function isn't designed to accept the first parameter as
this.
It would be much easier to simply have the compiler "insert" it
using __THIS__. Just because it isn't constant isn't really that
big of a deal to the compiler. It could just manually add the
parameter at the end of of the arguments.
I would also have to convert all the calls to this.log.
This becomes problematic because not not all calls are inside
objects.
We have __FUNCTION__ so, __THIS__ seems somewhat natural. Null
for outside of objects is fine.
Re: GTKD - CSS class color "flash" delay
On Friday, 24 June 2016 at 12:38:37 UTC, TheDGuy wrote: The color changing part works fine but if i use some kind of delay the program just starts delayed but no color changing happens. I am wondering why, because everything is executed in one thread, so the execution order looks like this to me: 1. Start GUI 2. Change Button Color to flash color 3. Wait 2 sec 4. Change Button Color back to standard Everything in GTK runs in the same thread, if your delay is a blocking one (i.e. putting the thread to sleep for 2 seconds) none of the GTK events will fire to redraw the button since the thread is occupied with your delay. I hope i can get around it without getting into multithreading? Other then the obvious multi-threaded, using glib.Timeout to trigger the reversion of the color change could be an option. http://api.gtkd.org/src/glib/Timeout.html
Re: Get calling this, if exists
On 6/24/16 11:15 AM, Smoke Adams wrote:
On Friday, 24 June 2016 at 03:16:58 UTC, Meta wrote:
On Friday, 24 June 2016 at 03:10:51 UTC, Mike Parker wrote:
Oh, perhaps I misunderstood your question. Do you meant this:
class Foo() {
void bar() { Log(); } // Pass reference to Foo instance
}
void doSomething() { Log(); } // Null reference
If so, the answer is no. And I don't see how that could work as a
compile time parameter, given that the reference itself is a runtime
value.
It actually is possible. You just have to be explicit.
void log(alias self)(string s)
{
pragma(msg, self.stringof);
}
struct Test
{
void test(string s)
{
log!this(s);
}
}
void main()
{
Test t;
t.test("asdf");
}
I don't want to be explicit! One can be explicit with __FILE__ too but
one doesn't have to be.
__FILE__ is a constant, so is __LINE__. __THIS__ would not be, so this
is somewhat different.
With UFCS, you can get close:
void log(T)(T obj, string s)
{
...
}
struct Test
{
void test(string s)
{
this.log(s);
}
}
But I believe you have to call with explict 'this'.
Perhaps an opDispatch can help, but seems an awful lot to avoid explicit
passing of this variable.
-Steve
Re: Get calling this, if exists
On Friday, 24 June 2016 at 03:16:58 UTC, Meta wrote:
On Friday, 24 June 2016 at 03:10:51 UTC, Mike Parker wrote:
Oh, perhaps I misunderstood your question. Do you meant this:
class Foo() {
void bar() { Log(); } // Pass reference to Foo instance
}
void doSomething() { Log(); } // Null reference
If so, the answer is no. And I don't see how that could work
as a compile time parameter, given that the reference itself
is a runtime value.
It actually is possible. You just have to be explicit.
void log(alias self)(string s)
{
pragma(msg, self.stringof);
}
struct Test
{
void test(string s)
{
log!this(s);
}
}
void main()
{
Test t;
t.test("asdf");
}
I don't want to be explicit! One can be explicit with __FILE__
too but one doesn't have to be.
I don't care if it's null.
GTKD - CSS class color "flash" delay
Hello,
i would like to flash some buttons with CSS. My current approach:
for(int i = 0; i < level; i++){
Button currentButton = bArr[rndButtonBlink[i]];
ListG list =
currentButton.getStyleContext().listClasses();
string CSSClassName =
to!string(cast(char*)list.next().data);
currentButton.getStyleContext().addClass(CSSClassName
~ "-flash");
writeln(CSSClassName);
//some kind of delay
currentButton.getStyleContext().removeClass(CSSClassName ~
"-flash");
}
The color changing part works fine but if i use some kind of
delay the program just starts delayed but no color changing
happens. I am wondering why, because everything is executed in
one thread, so the execution order looks like this to me:
1. Start GUI
2. Change Button Color to flash color
3. Wait 2 sec
4. Change Button Color back to standard
but instead it looks like this:
1. Wait 2 sec
2. Start GUI
3. Change Button Color to flash color
4. Change Button Color back to standard
Now because a delay is missing the change between the colors
happens unnoticeable fast.
I hope i can get around it without getting into multithreading?
Re: Real implicitly converts to float?
On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer wrote: On 6/23/16 11:16 AM, Tofu Ninja wrote: On Thursday, 23 June 2016 at 13:57:57 UTC, Steven Schveighoffer wrote: Whenever you work with floating point, the loss of precision must be expected -- a finite type cannot represent an infinite precision number. The loss in precision should still be a warning. If I am using reals then I obviously needed a certain level of precision, I don't want to accidentally lose that precision somewhere because the compiler decided it was not important enough to warn me about it. I disagree. I've used languages where converting floating point types is not implicit, and it's painful. Most of the time, the loss in precision isn't important. This is so wrong. _especially_ when you have parameter overloading/templates. It means that you accidentally can trash a computation by getting the wrong function. That is not type-safe in my book. Jonathan's max-value example is a good one. The distinction between infinity and a large actual value is an important one.
