Re: Of the use of unpredictableSeed
On Sun, Mar 26, 2017 at 11:46:44PM +, Yuxuan Shui via Digitalmars-d wrote: > On Sunday, 26 March 2017 at 17:55:20 UTC, Nick Sabalausky (Abscissa) wrote: > > > > 2. Maybe the std.random docs need to be more clear, right up top, > > that it's not for anything security-related. > > Agreed. Like what Python did here: > https://docs.python.org/3/library/random.html https://github.com/dlang/phobos/pull/5306 T -- I see that you JS got Bach.
Re: Beta 2.074.0-b1
On Sunday, 26 March 2017 at 04:53:37 UTC, steven kladitis wrote: It is not downloadable from the dlang.com download page although it say it is. I get permission denied on all of them Unfortunately, missing docs means we couldn't build the packages, just the tar archives. Should get fixed with the next beta. You can use the install.sh script for now. curl -fsS https://dlang.org/install.sh | bash -s dmd-beta
OpenSSL to switch licenses to Apache 2.0
Hi Everyone, I know that the licensing around OpenSSL has been a somewhat controversial topic around the D world. So I though that you might find this bit of news interesting: https://www.openssl.org/blog/blog/2017/03/22/license/ -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: really why module declarations?
On Sunday, March 26, 2017 20:51:01 XavierAP via Digitalmars-d-learn wrote:
> I've perused both the spec[1] and Andrei's book, and I the idea I
> get is that module declarations are optional, recommended only in
> case of file names not being valid D names. But in the community
> (and Phobos) I see it's strongly recommended and used throughout.
>
> What's the reason? If the declaration overrides the path
> (provided the file is found) rather than enforcing path
> consistency by outputting a compile error, then what's the
> benefit of module declarations, if we have to be disciplined to
> keep it consistent with paths anyway?
>
> I'm busy starting my first big multi file D project, thanks for
> any feedback!
>
>
> [1] https://dlang.org/spec/module.html#ModuleDeclaration
What it really comes down to is that if you don't give the module name, the
compiler infers it, and it doesn't infer packages. So, if you have
foo/bar.d
where bar.d's contents are
==
void main()
{
pragma(msg, __MODULE__);
}
==
and you compile with dmd foo/bar.d, you're going to see
bar
printed, whereas if you have
==
module foo.bar
void main()
{
pragma(msg, __MODULE__);
}
==
then you'll see
foo.bar
printed. So, if all you're ever doing is one file programs, then it really
doesn't matter, but if you're doing anything with packages, you have to use
module declarations. You also have to use them if you want to document a
module.
As for "overiding" the path... the compiler and other tools use the module
path as the path on disk to look for the files - e.g. if you tell the
compiler that /usr/local/include/dlang/ is an import directory, it'll start
looking for modules in there, and if it's looking for foo.bar, that means
that it's looking for /usr/local/include/dlang/foo/bar.d. On some level, it
is possible to give a module name or package name that doesn't match the
exact file or folder names on disk, but really, that's just asking for
trouble. It'll work in some basic cases, but it'll fall flat on its face in
real projects.
rdmd goes a step further and will compile additional modules based on what's
imported (i.e. if a module is imported but wasn't previously compiled, it'll
compile it), and when a tool does something like that, it makes it that much
worse if your module path isn't equivalent to the path on disk.
- Jonathan M Davis
Re: const(Class) is mangled as Class const* const
On Sunday, March 26, 2017 18:31:52 Jerry via Digitalmars-d wrote: > On Sunday, 26 March 2017 at 15:29:02 UTC, Jonathan M Davis wrote: > > Personally, I don't think that the fact that you can't use > > const for head-const in D is really a loss, since it's almost > > never what you want. Tail-const is _way_ more useful. But it is > > true that by making D's const fully transitive, there are > > variations of constness that C++ can do that D can't. immutable > > pretty much forces that though, and it does simplify the > > language. > > There are quite a few things wrong with const, it's so bad phobos > isn't even const-correct when it should be. In cmp() for example, > if you pass a lambda that takes the parameters by reference. You > will be modifying temporary values that cmp() created on the > stack. These should be const, but then what if it is a pointer? > It is a different situation and you don't really want const cause > you are going to be modifying the correct struct (the one pointed > to). It is just easier to not use const in D cause it makes your > code more difficult to actually use. That's exactly what Phobos > does, it ignores const for the most part because it is easier not > to use it. There are significant pros and cons when comparing C++ and D's const, but they usually relate to the ability to get around const in C++ and the lack of ability to do so in D. The ability to create a const pointer to a mutable element is occasionally something that someone wants to do, but in my experience, it's pretty useless. I'm not sure that I've ever used it in C++ (and I've programmed professinally primarily in C++), and when I was learning Java and found out that that's what Java's final did, I decided that all it was good for was constants of built-in types, and I think that that's mostly what I've seen other folks do with it. Having a pointer/reference that can't change while what it points to can just isn't very useful. It's having a mutable pointer to const that's useful. Now, as for const in D in general and how it compares to C++, that's a rather difficult question and highly debatable (and it's been debated here on many occasions). C++'s const is little more than documentation. It prevents accidental mutation, but there are so many ways around it that it's borderline meaningless. It only works as well as it does, because it's a convention that programmers _usually_ hold to. But it gurantees almost nothing. For instance, it's perfectly possible to have a class where all of its members are const but where all of them mutate the state of the object. The fact that that doesn't normally happen is simply because fortunately, programmers normally choose to behave themselves with mutable and casting away const. But they don't have to, and the compiler doesn't enforce it. D's const, on the other hand, has strong guarantees about something that's const never being mutated unless something elsewhere in the code has access to a mutable reference and changes the data that way. The const reference is never able to change the data without violating the type system. So, D's const actually means something. It provides real guarantees. But the reality of the matter is that that's so restrictive that pretty quickly you simply can't use const. There are too many idioms that require backdoors to const - mutexes, memory management, lazy initializaiton, etc. So, the end result is that in C++, you don't have much in the way of guarantees, but you're able to use what you do have all over the place. Accidental mutation is prevented and programmer intention is conveyed, but not much of anything is really guaranteed. Whereas with D, you have the strong guarantees, and you can use const in certain circumstances, but you're quickly forced to use it in only very restricted circumstances - especially if user-defined types or templates are involved. Too much simply doesn't work with true const. What most code really needs is logical const, and the compiler can't guarantee that. As to whether C++ or D did a better job with const, I really don't know. I find C++'s const to be pretty terrible from the standpoint of what it really protects, and I only recall one time in my entire programming career that it's actually caught a bug for me, but it's still nice to be able to indicate that a function doesn't mutate its arguments, even if it's not actually guaranteed, since it's usually true. The fact that D's const provides the stronger guarantees is fantastic, but it's also so restrictive that it borders on useless. So, ultimately, I'm not very happy with either solution, and I don't know what the best one would be. Arguably, immutable is what's truly useful - though obviously, code has to be written with it in mind, because a lot of code won't work with it without that - but for it to do its job, D's const pretty much has to be the way it is. Even if we wanted C++'s const in D, we couldn't have it unless it didn't interoperate
Re: how to define my own traits
On Sunday, 26 March 2017 at 23:25:49 UTC, XavierAP wrote:
I've looked into Phobos to emulate it when defining my own
trait template, and when I see this:
module std.range.primitives;
// ...
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront; // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
I wonder, why that unused parameter (inout int = 0)?
`git blame` is your friend. It's all documented in the commit
logs:
The original version does not have that parameter [1]. Then, to
fix using isInputRange on an inout argument [2] a dummy parameter
was introduced to force the delegate inside isInputRange to be
typed as inout as well [3].
Later, the dummy parameter's name was dropped [4].
In my project () { /* ... */ } works the same for a custom
trait.
Have you tried it without the dummy parameter on the example
given in the bug report [2]?
[1]
https://github.com/dlang/phobos/commit/49f646271bf6c843fcdd90249baa875bf43be0a1#diff-b7fc67b6fcb7d1a521918d06ffe03587R50
[2] https://issues.dlang.org/show_bug.cgi?id=7824
[3]
https://github.com/dlang/phobos/commit/ed00f6c28c602bd5c3b197e555c44d3b53ef76ba
[4]
https://github.com/dlang/phobos/commit/db1d909d7adb1b28ec0ba1895f56da0cc01a937b
Re: Of the use of unpredictableSeed
On Sunday, 26 March 2017 at 17:55:20 UTC, Nick Sabalausky (Abscissa) wrote: 2. Maybe the std.random docs need to be more clear, right up top, that it's not for anything security-related. Agreed. Like what Python did here: https://docs.python.org/3/library/random.html
how to define my own traits
I've looked into Phobos to emulate it when defining my own trait
template, and when I see this:
module std.range.primitives;
// ...
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront; // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
I wonder, why that unused parameter (inout int = 0)?
In my project () { /* ... */ } works the same for a custom trait.
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 22:29:56 UTC, deadalnix wrote: It is clear that you won't be able to express 100% of C++ in D, that would require to important all the weird parts of C++ into D, but if we are doing so, why use D in the first place ? Note that using const Class* in C++ is essentially useless. The class remains mutable and the reference is local the the callee anyway, so it doesn't change anything for the caller. Such a pattern is most likely indicative of a bug on the C++ side, or at least of code that do not do what the author intend to. For `const Class*` the Class is not mutable. It is the case of `Class* const` that Class is mutable. I see a lot of people in D say similar things about it. Saying it is a bug, saying it's a good thing that a const pointer with mutable type isn't in D. Yet they always tend to be the people that have never actually used C++. As is indicative of not even knowing the correct syntax to use in C++. A common matter in C++ is to use templates, you may have seen it, it's a really common pattern, `const T&`. The magic that makes this work is that you read it like this: `T const &`. They both mean the samething but I find makes more sense, conceptually to read it like that. Now substitute a type for T, `int* const &`. You see here that int is mutable for this template. You can see my other post about cmp(), and how Phobos avoids usages of const as it just makes writing generic code difficult.
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 17:41:57 UTC, Benjamin Thaut wrote: On Sunday, 26 March 2017 at 14:30:00 UTC, deadalnix wrote: It's consistent. D's const is transitive, and D doesn't allow you to specify const on the indirection of a reference type. So there is no problem on the C++ mangling side of things, but, arguably, there is one in D's sementic, that isn't new. I disagree. When binding C++ code to D I don't care about D's const rules. I care about the C++ const rules. There are thousands of C++ libraries out there that can't be bound to D because they use const Class* instead of const Class* const. So in my eyes there is definitly something wrong with the C++ mangling of D. It is clear that you won't be able to express 100% of C++ in D, that would require to important all the weird parts of C++ into D, but if we are doing so, why use D in the first place ? Note that using const Class* in C++ is essentially useless. The class remains mutable and the reference is local the the callee anyway, so it doesn't change anything for the caller. Such a pattern is most likely indicative of a bug on the C++ side, or at least of code that do not do what the author intend to.
Re: really why module declarations?
On Sunday, 26 March 2017 at 22:10:07 UTC, XavierAP wrote: I was curious but I guess it's long to explain the different things that can go wrong if one doesn't declare module names. You'll just get a name conflict eventually. Either two modules with the same name, or "module `foo` must be imported as `foo.bar`" errors when stuff fails to line up, then you'll need to go in and change all the imports to fix it. Real hassle to do later, real easy to do now. Followup question: if I am inside module myproj.pack1.mod1 and want to import myproj.pack1.mod2... should I import myproj.pack1.mod2; or import mod2; ? Always use the full module name in import. If you want to abbreviate it, do module something = myproj.pack.mod2; then you can refer to it as `something` throughout the usage points in that file.
Re: really why module declarations?
On Sunday, 26 March 2017 at 20:58:24 UTC, Adam D. Ruppe wrote: Module declarations are only optional in the most trivial case that is rarely useful in real world code. I recommend you ALWAYS use them (and always put a ddoc comment on them!), and moreover that you avoid top name modules (use `myproject.modname` instead of `modname`) to avoid conflicts. OK I was already doing it all this in the multi-file project. I was curious but I guess it's long to explain the different things that can go wrong if one doesn't declare module names. Followup question: if I am inside module myproj.pack1.mod1 and want to import myproj.pack1.mod2... should I import myproj.pack1.mod2; or import mod2; ?
Re: Howto catch SocketOSException?
On Sunday, 26 March 2017 at 18:50:13 UTC, bauss wrote:
On Sunday, 26 March 2017 at 11:46:39 UTC, Jolly James wrote:
[...]
Chances are it's invoked in another thread and thus you can't
catch it like that.
To sum it up.
Ex.
void thisFunctionThrows() { ... }
void ableToCatch() {
try {
thisFunctionThrows();
}
catch (Exception e) {
// We can catch the exception ...
}
}
void notAbleToCatch() {
try {
spawn();
}
catch (Exception e) {
// We cannot catch the exception ...
}
}
void ableToCatchToo() {
spawn(); // We're able to handle the exception,
because the try/catch is handled in the thread that calls the
function that throws.
}
If you want try to help me, mabye this helps you:
https://github.com/CyberShadow/ae/blob/master/net/asockets.d#L1237
Re: Loading assimp
On 03/26/2017 11:31 PM, Dlearner wrote:
SDL_Surface* surface = IMG_Load(filename.ptr);
if (surface is null) {
writeln("surface is null: ", to!string(IMG_GetError()));
} else {
writeln(filename);
}
From console:
surface is null: Couldn't open Models/Nanosuit/helmet_diff.png Ç2ÿ
I'm assuming the previous textures didn't experience this, but I have no
idea what could be the problem here, especially as the filename seems
fine when I writeln it.
:(
How do you construct `filename`? Looks like it's not properly
null-terminated.
If you followed my (short-sighted) `dup` advice, that doesn't do
null-termination. Since the original strings are null-terminated, just
slicing one more character should do the trick. I'd put an assert that
verifies that the last character is '\0'.
I.e.:
string z = x.data[0 .. x.length + 1].idup;
assert(z[$ - 1] == '\0');
Generally, don't pass just the pointer of a string unless you know for
sure that it's properly null-terminated.
If you're using a slice directly, without `dup`-ing, then the original
aiString would seem to be broken already.
Re: Loading assimp
On Sunday, 26 March 2017 at 12:40:42 UTC, Dlearner wrote:
...
About half the textures seem to load fine. Some progress!
I don't know why, but when I get to the 8th texture, the filename
has some garbage attached.
SDL_Surface* surface = IMG_Load(filename.ptr);
if (surface is null) {
writeln("surface is null: ", to!string(IMG_GetError()));
} else {
writeln(filename);
}
From console:
surface is null: Couldn't open Models/Nanosuit/helmet_diff.png Ç2ÿ
I'm assuming the previous textures didn't experience this, but I
have no idea what could be the problem here, especially as the
filename seems fine when I writeln it.
:(
Re: really why module declarations?
On Sunday, 26 March 2017 at 20:51:01 UTC, XavierAP wrote: I've perused both the spec[1] and Andrei's book, and I the idea I get is that module declarations are optional, recommended only in case of file names not being valid D names. Module declarations are only optional in the most trivial case that is rarely useful in real world code. I recommend you ALWAYS use them (and always put a ddoc comment on them!), and moreover that you avoid top name modules (use `myproject.modname` instead of `modname`) to avoid conflicts. If you don't, you are depending on implicit magic and just hoping that there's no conflict from third party libraries, and those lead to problems, almost guaranteed before long. if we have to be disciplined to keep it consistent with paths anyway? That's false, the path is irrelevant to the D language, ONLY the module declaration gives the canonical name. The path is just a helper for automatic tools to find the module given an import, but my preference is to ditch those things and actually just list your modules by name anyway. Then everything works reliably and consistently.
really why module declarations?
I've perused both the spec[1] and Andrei's book, and I the idea I get is that module declarations are optional, recommended only in case of file names not being valid D names. But in the community (and Phobos) I see it's strongly recommended and used throughout. What's the reason? If the declaration overrides the path (provided the file is found) rather than enforcing path consistency by outputting a compile error, then what's the benefit of module declarations, if we have to be disciplined to keep it consistent with paths anyway? I'm busy starting my first big multi file D project, thanks for any feedback! [1] https://dlang.org/spec/module.html#ModuleDeclaration
Re: Cityhash in D?
On Wednesday, 15 March 2017 at 13:26:45 UTC, Ethan Watson wrote: Does anyone know of a D implementation of Google's Cityhash? https://github.com/Remedy-Entertainment/cityhash-d 64-bit functions only for now. I'll add the 32-bit functions at some point, likely when I need them.
Re: Howto catch SocketOSException?
On Sunday, 26 March 2017 at 11:46:39 UTC, Jolly James wrote:
On Sunday, 26 March 2017 at 11:35:00 UTC, Jolly James wrote:
[...]
Found out something: You cannot catch any exception thrown in
the listen()-method in general.
■ Original code:
[...]
■ Modified one:
[...]
■ Not working try-catch:
[...]
Chances are it's invoked in another thread and thus you can't
catch it like that.
To sum it up.
Ex.
void thisFunctionThrows() { ... }
void ableToCatch() {
try {
thisFunctionThrows();
}
catch (Exception e) {
// We can catch the exception ...
}
}
void notAbleToCatch() {
try {
spawn();
}
catch (Exception e) {
// We cannot catch the exception ...
}
}
void ableToCatchToo() {
spawn(); // We're able to handle the exception,
because the try/catch is handled in the thread that calls the
function that throws.
}
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 15:29:02 UTC, Jonathan M Davis wrote: Personally, I don't think that the fact that you can't use const for head-const in D is really a loss, since it's almost never what you want. Tail-const is _way_ more useful. But it is true that by making D's const fully transitive, there are variations of constness that C++ can do that D can't. immutable pretty much forces that though, and it does simplify the language. There are quite a few things wrong with const, it's so bad phobos isn't even const-correct when it should be. In cmp() for example, if you pass a lambda that takes the parameters by reference. You will be modifying temporary values that cmp() created on the stack. These should be const, but then what if it is a pointer? It is a different situation and you don't really want const cause you are going to be modifying the correct struct (the one pointed to). It is just easier to not use const in D cause it makes your code more difficult to actually use. That's exactly what Phobos does, it ignores const for the most part because it is easier not to use it.
Re: Of the use of unpredictableSeed
On 03/24/2017 02:56 PM, H. S. Teoh via Digitalmars-d wrote: Yeah, why is it that people still keep thinking unpredictableSeed(), or indeed, the whole of the current std.random, is useful for *anything* related to crypto?? Seems there's two issues there: 1. The name "unpredictableSeed" is highly misleading, if not outright false. 2. Maybe the std.random docs need to be more clear, right up top, that it's not for anything security-related.
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 14:30:00 UTC, deadalnix wrote: It's consistent. D's const is transitive, and D doesn't allow you to specify const on the indirection of a reference type. So there is no problem on the C++ mangling side of things, but, arguably, there is one in D's sementic, that isn't new. I disagree. When binding C++ code to D I don't care about D's const rules. I care about the C++ const rules. There are thousands of C++ libraries out there that can't be bound to D because they use const Class* instead of const Class* const. So in my eyes there is definitly something wrong with the C++ mangling of D.
Re: const(Class) is mangled as Class const* const
On Sunday, March 26, 2017 14:51:28 Namespace via Digitalmars-d wrote:
> On Sunday, 26 March 2017 at 14:30:00 UTC, deadalnix wrote:
> > On Sunday, 26 March 2017 at 10:43:11 UTC, Benjamin Thaut wrote:
> >> As you see from the above example D mangles the getClassConst
> >> as a "Class const * const" instead of a "Class const *"
> >> ("YAQEBV" vs "YAPEBV"). Is this expected behavior?
> >
> > It's consistent. D's const is transitive, and D doesn't allow
> > you to specify const on the indirection of a reference type. So
> > there is no problem on the C++ mangling side of things, but,
> > arguably, there is one in D's sementic, that isn't new.
> >
> > Something like differentiating "const(C) i" and "const C i" may
> > be a good idea.
>
> After reading your post, I wonder: How could I translate the
> following C++ code to D?
>
>
> int a = 2;
> int* const p =
>
You don't. Once part of a type is const, everything inside it is const. So,
if a pointer is const, everything it points to is const. You can have the
outer part be mutable with the inner part be const, but not the other way
around. D's const can do tail-const, but it can't do head-const.
Now, while you can't use const to make the pointer const and what it points
to mutable, you _can_ make the the pointer read-only while still having what
it points to be fully mutable by putting it in a struct which restricts
write-access to the pointer. I believe that that's essentially what
std.experimental.typecons.Final is supposed to do.
Personally, I don't think that the fact that you can't use const for
head-const in D is really a loss, since it's almost never what you want.
Tail-const is _way_ more useful. But it is true that by making D's const
fully transitive, there are variations of constness that C++ can do that D
can't. immutable pretty much forces that though, and it does simplify the
language.
- Jonathan M Davis
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 14:30:00 UTC, deadalnix wrote:
On Sunday, 26 March 2017 at 10:43:11 UTC, Benjamin Thaut wrote:
As you see from the above example D mangles the getClassConst
as a "Class const * const" instead of a "Class const *"
("YAQEBV" vs "YAPEBV"). Is this expected behavior?
It's consistent. D's const is transitive, and D doesn't allow
you to specify const on the indirection of a reference type. So
there is no problem on the C++ mangling side of things, but,
arguably, there is one in D's sementic, that isn't new.
Something like differentiating "const(C) i" and "const C i" may
be a good idea.
After reading your post, I wonder: How could I translate the
following C++ code to D?
int a = 2;
int* const p =
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 10:43:11 UTC, Benjamin Thaut wrote:
As you see from the above example D mangles the getClassConst
as a "Class const * const" instead of a "Class const *"
("YAQEBV" vs "YAPEBV"). Is this expected behavior?
It's consistent. D's const is transitive, and D doesn't allow you
to specify const on the indirection of a reference type. So there
is no problem on the C++ mangling side of things, but, arguably,
there is one in D's sementic, that isn't new.
Something like differentiating "const(C) i" and "const C i" may
be a good idea.
Re: Gnome Builder IDE
On Wednesday, 22 March 2017 at 20:31:01 UTC, helxi wrote: On Wednesday, 4 May 2016 at 13:51:13 UTC, WebFreak001 wrote: ok I asked in the IRC right now. There is a plugins directory where it dynamically loads it from. However nobody in there actually knew how to do it with anything else than Python. Gonna try to get it to work somehow Have you made any progress lately? It'd be really great if builder actually worked with Dlang (DCD, Dfmt and Dscanner) Not much aside the basic syntax highlighting that comes with gsourceview. Builder is more like the defacto Linux IDE now.
[Issue 17277] New: Member and aggregate alignment semantics
https://issues.dlang.org/show_bug.cgi?id=17277
Issue ID: 17277
Summary: Member and aggregate alignment semantics
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ki...@gmx.net
Code:
*
struct S
{
byte[5] bytes;
struct {
byte byte1;
align(1) int int1;
}
}
pragma(msg, "S.int1.offsetof: ", S.int1.offsetof);
pragma(msg, "S.alignof: ", S.alignof);
pragma(msg, "S.sizeof: ", S.sizeof);
*
Result:
S.int1.offsetof: 9LU
S.alignof: 4LU
S.sizeof: 16LU
I expected { 6, 1, 10 }. `byte1` has an implicit alignment of 1 as it's a byte,
`int1` has an explicit alignment of 1. I'd expect the anonymous struct's
implicit alignment to be max(1, 1) = 1 (maximum of all member alignments). As
the `bytes` array has an implicit alignment of 1 too, I'd expect S to have an
implicit alignment of max(1, 1) = 1 too. And so both the anonymous struct and S
aren't padded.
Just for clarifiction, in this modified version:
struct S
{
byte[5] bytes;
struct {
byte byte1;
align(2) int int1;
}
}
I'd expect { 8, 2, 12 } with 2 padding bytes at offsets 5 and 7.
-
When adding an explicit align(1) for both anonymous struct and S:
align(1) struct S
{
byte[5] bytes;
align(1) struct {
byte byte1;
align(1) int int1;
}
}
you still don't come up with { 6, 1, 10 }. It's { 6, 4, 10 }. I.e., S's
alignment is 4, but it's size is 10. Which means that every odd element in an
array of S structs is **guaranteed** NOT to be aligned on a 4-bytes-boundary.
Note that LDC uses these alignments as optimization hints for LLVM codegen, and
platforms such as ARM don't forgive unaligned memory access.
--
Re: Loading assimp
On Sunday, 26 March 2017 at 11:10:55 UTC, ag0aep6g wrote: On Sunday, 26 March 2017 at 10:34:21 UTC, Dlearner wrote: I came back to this project and realised my mistakes (Importer is a class for the C++ API, and we're using the C API). So I fixed all my errors, but now I get an access violation. As far as I can tell, it seems to be an issue with `aiGetMaterialTexture`. It is meant to return an aiString with a filename (default value of "$texture.png"), I believe. But I get: aiString(13, x"67 6C 61 73 73 5F 64 69 66 2E 70 6E 67 00 FF FF FF ... FF"c) [shortened for brevity] The data is "glass_dif.png", followed by a null terminator, followed by a bunch of 0xFFs. 13 is the length of "glass_dif.png". Judging from the definition of aiString [1], the 0xFFs are just unused space. So, this looks good. I'm meant to add this on to a directory string so I can load an image, but obviously this wouldn't work. To convert an aiString to a D string, it should be possible to slice the data with the length: aiString x; const(char)[] y = x.data[0 .. x.length]; You have to be cautiots of lifetime requirements, of course. If needed, you can make a copy with dup (mutable copy) or idup (immutable copy): const(char)[] y = x.data[0 .. x.length].dup; string z = x.data[0 .. x.length].idup; [1] http://www.assimp.org/lib_html/structai_string.html Ahh this did help! I practically followed your advice, then fixed a somewhat unrelated range violation, and got a similar "object.Error@(0): Access Violation". But in the console I got: filename: Models/Nanosuit/glass_dif.png filename: Models/Nanosuit/leg_dif.png filename: Models/Nanosuit/leg_showroom_spec.png filename: Models/Nanosuit/hand_dif.png filename: Models/Nanosuit/hand_showroom_spec.png filename: Models/Nanosuit/arm_dif.png filename: Models/Nanosuit/arm_showroom_spec.png filename: Models/Nanosuit/helmet_diff.png About half the textures seem to load fine. Some progress!
Re: Howto catch SocketOSException?
On Sunday, 26 March 2017 at 11:35:00 UTC, Jolly James wrote:
On Sunday, 26 March 2017 at 02:41:46 UTC, Adam D. Ruppe wrote:
On Sunday, 26 March 2017 at 02:24:56 UTC, Jolly James wrote:
You can ignore the loop()-method. It is not called as the
application will never reach this statement, because it
cannot, because it crashes already in the listen()-method in
consequence of the exception that does not get caught by the
try-catch block.
Try putting it in the try anyway and see what happens.
It is an async socket library, they can do weird things.\
Unfortunately not working either. I should not forget to
mention that the exception also raises when the code does not
contain the loop()-call.
Found out something: You cannot catch any exception thrown in the
listen()-method in general.
■ Original code:
auto addressInfos = getAddressInfo(addr, to!string(port),
AddressInfoFlags.PASSIVE, SocketType.STREAM, ProtocolType.TCP);
■ Modified one:
AddressInfo[] addressInfos;
try
{
addressInfos = getAddressInfo(addr, to!string(port),
AddressInfoFlags.PASSIVE, SocketType.STREAM, ProtocolType.TCP);
}
catch(SocketOSException e)
{
throw new Exception("Invalid address: " ~ addr, e);
}
■ Not working try-catch:
try
{
tcp.listen(2345, "127.0.0.1c");
socketManager.loop();
}
catch (Exception e)
{
return;
}
Re: Howto catch SocketOSException?
On Sunday, 26 March 2017 at 02:41:46 UTC, Adam D. Ruppe wrote: On Sunday, 26 March 2017 at 02:24:56 UTC, Jolly James wrote: You can ignore the loop()-method. It is not called as the application will never reach this statement, because it cannot, because it crashes already in the listen()-method in consequence of the exception that does not get caught by the try-catch block. Try putting it in the try anyway and see what happens. It is an async socket library, they can do weird things.\ Unfortunately not working either. I should not forget to mention that the exception also raises when the code does not contain the loop()-call.
Re: Loading assimp
On Sunday, 26 March 2017 at 10:34:21 UTC, Dlearner wrote: I came back to this project and realised my mistakes (Importer is a class for the C++ API, and we're using the C API). So I fixed all my errors, but now I get an access violation. As far as I can tell, it seems to be an issue with `aiGetMaterialTexture`. It is meant to return an aiString with a filename (default value of "$texture.png"), I believe. But I get: aiString(13, x"67 6C 61 73 73 5F 64 69 66 2E 70 6E 67 00 FF FF FF ... FF"c) [shortened for brevity] The data is "glass_dif.png", followed by a null terminator, followed by a bunch of 0xFFs. 13 is the length of "glass_dif.png". Judging from the definition of aiString [1], the 0xFFs are just unused space. So, this looks good. I'm meant to add this on to a directory string so I can load an image, but obviously this wouldn't work. To convert an aiString to a D string, it should be possible to slice the data with the length: aiString x; const(char)[] y = x.data[0 .. x.length]; You have to be cautiots of lifetime requirements, of course. If needed, you can make a copy with dup (mutable copy) or idup (immutable copy): const(char)[] y = x.data[0 .. x.length].dup; string z = x.data[0 .. x.length].idup; [1] http://www.assimp.org/lib_html/structai_string.html
const(Class) is mangled as Class const* const
Consider the following C++ and D source:
class Class
{
virtual ~Class(){}
};
// mangles as ?getClass@@YAPEAVClass@@XZ
Class * getClass() { return nullptr; }
// mangles as ?getClassConst@@YAPEBVClass@@XZ
const Class * getClassConst() { return nullptr; }
// mangles as ?getClassConstConst@@YAQEBVClass@@XZ
const Class * const getClassConstConst() { return nullptr; }
extern(C++)
{
class Class
{
void _cppDtor() {}
}
// Mangles as ?getClass@@YAPEAVClass@@XZ
Class getClass() {return null;}
// Mangles as ?getClassConst@@YAQEBVClass@@XZ
const(Class) getClassConst() {return null;}
}
As you see from the above example D mangles the getClassConst as
a "Class const * const" instead of a "Class const *" ("YAQEBV" vs
"YAPEBV"). Is this expected behavior? The core problem is that D
can not express one of the two. Either const(Class) becomes
"Class const *" or "Class const * const". I've never seen C++
code that returns const pointers to const classes so I think the
default should be "Class const *". Either way its rather bad that
we can only represent one or the other. Sooner or later someone
will hit this problem again wanting the other option or both. Any
idea how we can avoid changing C++ source code in order to bind
it to D? Using pragma(mangle,) works but is kind of ugly.
Especially because the string to pragma(mangle,) can't be
genearted using CTFE.
Should I open a bug for this?
Re: Loading assimp
I came back to this project and realised my mistakes (Importer is
a class for the C++ API, and we're using the C API).
So I fixed all my errors, but now I get an access violation.
As far as I can tell, it seems to be an issue with
`aiGetMaterialTexture`. It is meant to return an aiString with a
filename (default value of "$texture.png"), I believe. But I get:
aiString(13, x"67 6C 61 73 73 5F 64 69 66 2E 70 6E 67 00 FF FF FF
... FF"c)
[shortened for brevity]
I'm meant to add this on to a directory string so I can load an
image, but obviously this wouldn't work.
I thought it might be a problem with converting from D-strings to
C-strings. I sent a string to `aiImportFile` as
`toStringz(path)`.
I tested this with some writeln debugging:
```
auto temp = path.toStringz;
writeln("toStringz: ", temp);
writeln("string: ", temp.to!string);
```
This gave:
toStringz: 4770B6
string: Models/Nanosuit/nanosuit.obj
So maybe this is a problem with using aiStrings? I'm quite
confused. Sorry if this is more of an assimp question than a D
question, but I don't know if it's me misusing D language
features or not.
Re: union.sizeof
On Sunday, 26 March 2017 at 07:18:14 UTC, ketmar wrote: i.e. what compiler does (roughly) is inserting anonymous fields of the appropriate size *into* the container. for "inner" aligning compiler inserts anonymous fields *between* other fields. for "outer" aligning compiler just appends anonymous field at the *end* of a data type, so data type size will met align requirements. Big thank!!
Re: union.sizeof
zabruk70 wrote: On Sunday, 26 March 2017 at 06:45:13 UTC, ketmar wrote: yes. you have a typo in second `writefln`: S1 instead of S2. ;-) thank you. another question, related to my first post: why size of S2.b1 and S2.b2 still 3, not 4? am i right: then align applied to members, compiler not change size of members, just make padding, so CONTAINER size changes? yes. compiler is not allowed to mess with data types of the known size. ;-) and you are right: it doesn't have to. it just inserts dummy anonymous (and unused) bytes into struct/union to satisfy alignment requirements. if so (because size of S2.b1 and S2.b2 still is 3 in my code), then adding align(1) outside of union must not change zise of union, but size of some comainer more upper level. nope, it changes size of the union itself. padding bytes *are* included in union, so `myunion.sizeof` includes 'em too. i.e. what compiler does (roughly) is inserting anonymous fields of the appropriate size *into* the container. for "inner" aligning compiler inserts anonymous fields *between* other fields. for "outer" aligning compiler just appends anonymous field at the *end* of a data type, so data type size will met align requirements.
Re: foreach, is and pointer
On 26/03/2017 7:52 AM, helxi wrote: What's the difference between 1. string x = "abcd"; foreach(character; x) write(character); and string x = "abcd"; foreach(character; x[0..$]) write(character); Hopefully the compiler is smart enough to ignore that slice (since its identical in purpose). 2. is and == is: bit for bit comparison ==: "magic" comparison logic, supports e.g. opEquals on classes. 3. pointer and address and reference? pointer: a place in memory! or hdd.. or well pretty much anywhere the kernel maps it to, just assume that there is some data there that you may be able to do some, all or none of these things read, write, execute. May also be invalid aka null aka 0. reference: pointer + some other pointer generally, e.g. class instance data pointer + typeinfo reference + vtable.
Re: union.sizeof
On Sunday, 26 March 2017 at 06:45:13 UTC, ketmar wrote: yes. you have a typo in second `writefln`: S1 instead of S2. ;-) thank you. another question, related to my first post: why size of S2.b1 and S2.b2 still 3, not 4? am i right: then align applied to members, compiler not change size of members, just make padding, so CONTAINER size changes? if so (because size of S2.b1 and S2.b2 still is 3 in my code), then adding align(1) outside of union must not change zise of union, but size of some comainer more upper level.
foreach, is and pointer
What's the difference between 1. string x = "abcd"; foreach(character; x) write(character); and string x = "abcd"; foreach(character; x[0..$]) write(character); 2. is and == 3. pointer and address and reference?
Re: union.sizeof
On Sunday, 26 March 2017 at 06:38:59 UTC, zabruk70 wrote: oh sorry sorry - mistyping ok. DMD use padding, so for real container.sizeof i should use lastMemeber.offsetof+lastMemeber.sizeof
Re: union.sizeof
zabruk70 wrote: On Sunday, 26 March 2017 at 05:09:15 UTC, ketmar wrote: most of the time either location or padding will work the same. hmm.. you ruined my expirence.. i made another experiment. whould you please explain me S2 size 6? thank you for you time. yes. you have a typo in second `writefln`: S1 instead of S2. ;-)
Re: union.sizeof
On Sunday, 26 March 2017 at 05:09:15 UTC, ketmar wrote:
most of the time either location or padding will work the same.
hmm.. you ruined my expirence..
i made another experiment.
whould you please explain me S2 size 6?
thank you for you time.
https://dpaste.dzfl.pl/9a31b6e370a0
struct S1 //sizeof=6
{
align(1):
byte[3] b1; //offsetof=0, sizeof=3
byte[3] b2; //offsetof=3, sizeof=3
}
struct S2 //sizeof must be 7, but DMD say 6
{
align(4):
byte[3] b1; //offsetof=0, sizeof=3
byte[3] b2; //offsetof=4, sizeof=3
}
Re: Recommend: IDE and GUI library
On Wednesday, 1 March 2017 at 20:23:57 UTC, aberba wrote:
On Friday, 24 February 2017 at 22:44:55 UTC, XavierAP wrote:
[...]
Gtkd is obviously defacto for Linux ONLY, dlangui for cross
platform app without native feel. But if you want something
easy and flexible with native look and feel on all platforms,
well tested, use LibUI (http://code.dlang.org/packages/libuid).
Look inside the "examples" folder in their Github repository to
see example usage.
More like:
auto hbox = new Box(false).setPadded(1);
vbox.append(hbox);
hbox.append(new Button("Button"))
.append(new Checkbox("Checkbox"))
...
Examples:
https://github.com/mogud/libuid/blob/master/examples/example1.d
https://github.com/mogud/libuid/blob/master/examples/example2.d
I second this. I've been playing with this recently and it's
really easy to use.
