Re: getopt short-options documentation
Are you sure? Can you show me an example? I always forgot on this limitation and somtimes it cause really nesty things :D On Thu, Nov 29, 2018 at 6:05 PM Antonio Corbi via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > Hi! > > Reading through the `getopt` documentation at one point it says: > >"Forms such as -t 5 and -timeout=5 will be not accepted." > > But I'm able to to use short options like '-t 5' (with spaces > between the 't' and the '5'). It seems that this limitation has > been eliminated and it just-works-now, is it so? > > Thx! >
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote: When I was first playing with D, I managed to create a segfault What's the reasoning for allowing this? 100 % agree that there should be non-nullable class references, they're my main missing feature in D. Likewise, I'm astonished that only few D users wish for them. I understand that it's very hard to get @safely right, without code-flow analysis that Walter prefers to keep at minimum throughout D. I'm concerned about the clarity of usercode. I would like to ensure in my function signatures that only non-null class references are accepted as input, or that only non-null class references will be returned. All possibilities in current D have drawbacks: a) Add in/out contracts for over 90 % of the class variables? This is nasty boilerplate. b) Check all arguments for null, check all returned values for null? This is against the philosophy that null should be cost-free. Also boilerplate. c) Declare the function as if it accepts null, but segfault on receiving null? This looks like a bug in the program. Even if c) becomes a convention in the codebase, then when the function segfaults in the future, it's not clear to maintainers whether the function or the caller has the bug. I discussed some ideas in 2018-03: https://forum.dlang.org/post/epjwwtstyphqknavy...@forum.dlang.org -- Simon
Re: D & C++ class question
On Thursday, 29 November 2018 at 16:24:58 UTC, bauss wrote: Are there no support for references with mangling in D? Like what about int&? Of course, that's `ref int`. But a `ref CppClass` is C++-mangled as `CppClass* &`.
Re: D & C++ class question
On Thursday, 29 November 2018 at 17:12:28 UTC, kinke wrote: On Thursday, 29 November 2018 at 16:24:58 UTC, bauss wrote: Are there no support for references with mangling in D? Like what about int&? Of course, that's `ref int`. But a `ref CppClass` is C++-mangled as `CppClass* &`. I was hoping for that and glad to know that was the only issue.
Re: How to debug FinalizeError?
On Thursday, 29 November 2018 at 14:51:40 UTC, Steven
Schveighoffer wrote:
You need to compile druntime in debug mode. One thing you can
do is implement the function locally, and then break on it
(it's a C linkage, so I think the linker will grab your copy
instead of the one in druntime)
i.e. in your code, do:
extern(C) void onFinalizeError(TypeInfo info, Throwable e,
string file = __FILE__, size_t line = __LINE__)
{
import core.stdc.stdio;
printf("break here\n");
}
Big thanks, Steve. I will try it. Every night will do debugging
and maybe at one night it will happen again :-)
Re: gcc 9 vs. dmd?
On Friday, 30 November 2018 at 00:43:59 UTC, Andrew Pennebaker wrote: Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported? Or perhaps have its guts incorporated completely into gcc? DMD doesn't really require GCC, GCC is in theory used for compatibility with modules compiled with gcc according to dmd(1), and in practice used for linking. The linking step could be done with ld alone if you know what to type, and it's honestly pretty complicated, and you still need components from gcc, for various reasons: LIBGCCDIR=$(cc -print-file-name=) CRTDIR=/usr/lib/$(cc -dumpmachine) ld -L $LIBGCCDIR $CRTDIR/Scrt1.o $CRTDIR/crti.o $LIBGCCDIR/crtbeginS.o \ YOUROBJECT.o -E --push-state -static -lphobos2 --pop-state \ -lpthread -lm -lrt -ldl -lc -lgcc -lgcc_s $LIBGCCDIR/crtendS.o $CRTDIR/crtn.o
gcc 9 vs. dmd?
Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported? Or perhaps have its guts incorporated completely into gcc?
Re: gcc 9 vs. dmd?
On Friday, 30 November 2018 at 00:43:59 UTC, Andrew Pennebaker wrote: Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported? dmd will continue to be supported.
Re: Why pow() won't go beyond 2^31?
On Thursday, 29 November 2018 at 07:07:06 UTC, Murilo wrote:
I am using the function pow() from std.math but if I try pow(2,
32) it returns 0, it doesn't compute beyond the maximum value
of an int(2^31) and I am working with long. What should I do?
what exactly is your input?
´´´
import std.stdio;
import std.experimental.all;
void main()
{
long u = 2;
assert(pow(u,32) == 4294967296);
assert(pow(2UL,32) == 4294967296);
}
´´´
Re: Function signature as string
On Thursday, 29 November 2018 at 21:31:57 UTC, Neia Neutuladh
wrote:
On Thu, 29 Nov 2018 21:11:06 +, John Chapman wrote:
Is there any way to get a string representing a function's
exact signature as declared in the source? I can generate it
myself using reflection but it might not be 100% verbatim so
wanted to know if there's anything built in?
foreach (m; __traits(allMembers, T)) {
alias member = __traits(getMember, T, m);
string signature = // Call some function to get "member"'s
signature as a string
}
typeof().stringof should do it:
void bar(string s, ref Foo!int i) {}
void main()
{
writeln(typeof().stringof);
}
prints: void function(string s, ref Foo!int i)
That does the trick - thanks.
Function signature as string
Is there any way to get a string representing a function's exact
signature as declared in the source? I can generate it myself
using reflection but it might not be 100% verbatim so wanted to
know if there's anything built in?
foreach (m; __traits(allMembers, T)) {
alias member = __traits(getMember, T, m);
string signature = // Call some function to get "member"'s
signature as a string
}
Re: Function signature as string
On Thu, 29 Nov 2018 21:11:06 +, John Chapman wrote:
> Is there any way to get a string representing a function's exact
> signature as declared in the source? I can generate it myself using
> reflection but it might not be 100% verbatim so wanted to know if
> there's anything built in?
>
>foreach (m; __traits(allMembers, T)) {
> alias member = __traits(getMember, T, m);
> string signature = // Call some function to get "member"'s
> signature as a string
>}
typeof().stringof should do it:
void bar(string s, ref Foo!int i) {}
void main()
{
writeln(typeof().stringof);
}
prints: void function(string s, ref Foo!int i)
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Monday, 19 November 2018 at 21:23:31 On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote: I'm not the only one who has done this. I can't find it right now, but I've seen at least one person open a bug report because they misunderstood this as a bug in dmd. I have been told a couple of times that this isn't something that needs to be patched in the language, but I don't understand. It seems like a very easy way to generate a segfault (and not a NullPointerException or whatever). I love Null in an empty class variable and I use it very often in my code. It simplifies a lot. What would be a better way? (practical not theoretical) Regards Ozan
Re: gcc 9 vs. dmd?
On Friday, 30 November 2018 at 01:31:12 UTC, mawk wrote: On Friday, 30 November 2018 at 00:43:59 UTC, Andrew Pennebaker wrote: Given that gcc v9 should have built-in support for compiling D code, and that dmd requires gcc, will dmd continue to be supported? Or perhaps have its guts incorporated completely into gcc? DMD doesn't really require GCC, GCC is in theory used for compatibility with modules compiled with gcc according to dmd(1), and in practice used for linking. The linking step could be done with ld alone if you know what to type, and it's honestly pretty complicated, and you still need components from gcc, for various reasons: LIBGCCDIR=$(cc -print-file-name=) CRTDIR=/usr/lib/$(cc -dumpmachine) ld -L $LIBGCCDIR $CRTDIR/Scrt1.o $CRTDIR/crti.o $LIBGCCDIR/crtbeginS.o \ YOUROBJECT.o -E --push-state -static -lphobos2 --pop-state \ -lpthread -lm -lrt -ldl -lc -lgcc -lgcc_s $LIBGCCDIR/crtendS.o $CRTDIR/crtn.o gcc is currently required for dmd on FreeBSD, as dmd links to libstdc++.
Re: Why pow() won't go beyond 2^31?
On Thu, Nov 29, 2018 at 8:10 AM Murilo via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > I am using the function pow() from std.math but if I try pow(2, > 32) it returns 0, it doesn't compute beyond the maximum value of > an int(2^31) and I am working with long. What should I do? > if you look at doc: https://dlang.org/phobos/std_math.html#.pow.2 you will see that return type is infered from pow arguments, so if both arguments are int for example the return value would be int too https://run.dlang.io/is/FMVJhY so if you want to have long as output one of your args should be (u)long or you can enforce that by pow!long(2,32); https://run.dlang.io/is/WlDfsE
Re: How to debug FinalizeError?
On 11/29/18 2:07 AM, unDEFER wrote:
No I'm not preallocating any exceptions. It was idea, but I removed all
calls which can make throw.
I'm using very old dmd 2.074.1, so as I have patched it for my text
editor with IDE functions. I had a year break in development, so now I
need to rewrite all my patches.
But exactly the output of my program looks like this:
core.exception.FinalizeError@src/rt/lifetime.d(1407): Finalization error
=== Bypassed ===
BerkeleyDB exceptions mixed with output of destructors
||
core.exception.InvalidMemoryOperationError@src/core/exception.d(696):
Invalid memory operation
It means that "Invalid memory operation" occurred earlier than
"Finalization error"?
The line on which shows the pointer src/rt/lifetime.d(1407) is exactly:
onFinalizeError(*pc, e);
Why gdb doesn't see this function?
You need to compile druntime in debug mode. One thing you can do is
implement the function locally, and then break on it (it's a C linkage,
so I think the linker will grab your copy instead of the one in druntime)
i.e. in your code, do:
extern(C) void onFinalizeError(TypeInfo info, Throwable e, string file =
__FILE__, size_t line = __LINE__)
{
import core.stdc.stdio;
printf("break here\n");
}
My program (the text editor) had run test all night under gdb with break
on InvalidMemoryOperationError and didn't fall. So it is very-very-very
hard to reproduce.
And I haven't ideas where maybe this throw. At least I don't see any
throw in explicit form.
These are unfortunately really tough to debug. You get very little info,
and the stack trace is generally useless.
-Steve
Re: How to center dlangui Window on screen
On Thursday, 29 November 2018 at 13:42:28 UTC, greatsam4sure wrote: Which class in dlangui is use to obtain the screen height and width? A Windom of dimension 280 x 445 in dlangui is the same as a Windom of 350 x 550 in Javafx and adobe air. What could be responsible for this wide difference? A window of 350 x 550 in adobe air is the same as a window of 350 x 550 in javafx. So why is dlangui window bigger? Note that I am using w x h for my window dimension and I am on windows 10 That looks like DPI scaling is in effect: 280 pixels + 125% DPI = 350. There's an example of how to get the screen size here (look for getScreenDimensions): https://github.com/buggins/dlangui/blob/60159c61e27d86012fbf8f205c75d30196fc0e52/src/dlangui/platforms/windows/winapp.d
Re: How to center dlangui Window on screen
On Thursday, 29 November 2018 at 05:54:37 UTC, bauss wrote: On Wednesday, 28 November 2018 at 23:07:50 UTC, greatsam4sure wrote: On Wednesday, 28 November 2018 at 17:23:21 UTC, Edgar Huckert wrote: On Wednesday, 28 November 2018 at 08:55:11 UTC, greatsam4sure wrote: [...] For a little bit of information look at: https://github.com/buggins/dlangui/pull/372 Without going into depth I have tested this under Linux/GTK with dlangui: WindowState state; Rectrect; rect.left = 800; rect.top= 10; rect.bottom = 600; rect.right = 1000; bool bRet= window.setWindowState(state, false, rect); window.show(); This changed the position and size of my initial window. Edgar Huckert This help a little but not what I am looking for. I want to calculate the width and window of the screen so as to center my window on screen I also notice that a window of 350 x 550 appear bigger compare to the same Widow dimension in Havana and adobe air. Why is it so? Plz help! Thanks in advance To center horizontal: l = left s = screen width w = window width l = (s / 2) - (w / 2) To center vertical: t = top s = screen height h = window height t = (s / 2) - (h / 2) And about the window size. It has probably to do with the type of Window you're rendering, like whether it has borders or not. Borders are not calculated in the width / height, so they take up extra space. Adobe usually never uses the native GUI for borders etc. so the border size (if there is one) is included in their width / height. Which class in dlangui is use to obtain the screen height and width? A Windom of dimension 280 x 445 in dlangui is the same as a Windom of 350 x 550 in Javafx and adobe air. What could be responsible for this wide difference? A window of 350 x 550 in adobe air is the same as a window of 350 x 550 in javafx. So why is dlangui window bigger? Note that I am using w x h for my window dimension and I am on windows 10
Re: LDC2 win64 calling convention
On Wednesday, 28 November 2018 at 21:58:16 UTC, kinke wrote: You're not using naked asm; this entails a prologue (spilling the params to stack etc.). Additionally, LDC doesn't really like accessing params and locals in DMD-style inline asm, see https://github.com/ldc-developers/ldc/issues/2854. You can check the final asm trivially online, e.g., https://run.dlang.io/is/e0c2Ly (click the ASM button). You'll see that your params are in R8, RDX and RCX (reversed order as mentioned earlier). Hi again. I just tried a new debugger: x64dbg. I really like it, it is not the bloatware I got used to nowadays. It turns out that LDC2's parameter/register handling is really clever: - Register saving/restoring: fully automatic. It analyzes my asm and saves/restores only those regs I overwrite. - Parameters: Reversed Microsoft x64 calling convention, just as you said. Parameters in the registers will be 'spilled' onto the stack no matter if I'm using them by their names or by the register. Maybe this is not too clever but as I can use the params by their name from anywhere, it can make my code nicer. - Must not use the "ret" instruction because it will take it literally and will skip the auto-generated exit code. In conclusion: Maybe LDC2 generates a lot of extra code, but I always make longer asm routines, so it's not a problem for me at all while it helps me a lot.
Re: D & C++ class question
On Wednesday, 28 November 2018 at 13:42:43 UTC, Nicholas Wilson wrote: On Wednesday, 28 November 2018 at 13:13:40 UTC, bauss wrote: Well unfortunately I cannot control the C++ side of things, but I assume that it'll work properly with extern(C++) so I guess I will just go ahead and try and see if everything works out. I have access to the C++ source so at the very least I can see how it's used there and if it's possible in the way I want it to. I don't hope I have to have a separate C++ "bridge" to make it work. Its mostly a magling problem, if the C++ API uses class& that you have to interface with then you have a problem that would require a shim. Are there no support for references with mangling in D? Like what about int&?
getopt short-options documentation
Hi! Reading through the `getopt` documentation at one point it says: "Forms such as -t 5 and -timeout=5 will be not accepted." But I'm able to to use short options like '-t 5' (with spaces between the 't' and the '5'). It seems that this limitation has been eliminated and it just-works-now, is it so? Thx!
