Re: Recommend: IDE and GUI library
On Wednesday, 1 March 2017 at 23:44:47 UTC, XavierAP wrote: Still I want to be able to be able to work and debug from Visual Studio. The way I did on Windows: 1) get dlangui via dub 2) go to its folder in AppData\roaming\dub\packages and edit dub.json: * find "minimal" configuration * add "USE_WIN32" to "versions-windows", * remove mentions of "derelict-sdl2" and "derelict-gl3" from "dependencies" * remove "ForceLogs" from "versions" (just to avoid logspamming) 3) run "dub build --build=release --config=minimal" 4) use the result .lib file from my VisualD project This way no dependency on OpenGL which causes problems for you.
Re: Recommend: IDE and GUI library
On Wednesday, 1 March 2017 at 23:44:47 UTC, XavierAP wrote: On Wednesday, 1 March 2017 at 20:00:32 UTC, thedeemon wrote: For this I found out how to clone the dependencies, sorry about that... (Only from the command line... Anyone recommends better free Windows Git gui clients than GitHub Desktop?) Import paths seem correctly setup in the project files from the repo, as I would expect. And once the dependency code is in its place it does build, both the library and the example applications. Here [1] is the official git page listing all GUI clients for different plartforms. I use GitExtensions[2] and I like it a lot. It works very well and all the complicated stuff can be done from the GUI interface and also from command line. [1]=https://git-scm.com/download/gui/win [2]=https://gitextensions.github.io/
Re: Getting underlying struct for parseJSON
On Tuesday, 28 February 2017 at 21:21:30 UTC, Adam D. Ruppe wrote: On Tuesday, 28 February 2017 at 20:27:25 UTC, Alexey H wrote: [...] It doesn't actually generate one, it just returns a tagged union (a kind of dynamic type). [...] Superb, Adam, thank you! I need to check out inspector. The std.json will be used solely to generate proper structs. I expect to do all the heavy stuff via http://code.dlang.org/packages/jsonserialized since it uses vibe.d's JSON implementation, my expectations are that it would be faster.
Re: Mixing libraries
On Thursday, 2 March 2017 at 02:27:03 UTC, Jordan Wilson wrote: Ah yes, I think you explain the difference between wrapper/binding in one of the Derelict docs. I'm currently working through a ebook on Game Dev with SFML...the examples are all C++. I don't have any trouble translating it to the equivalent C bindings (so far anyway), but perhaps in the long run using dsfml will be easier (for example, I found using Iup4d easier than the straight C Iup bindings). Yes, that's what wrappers are for :-) Plenty of people have built wrappers on top of the Derelict bindings. I have my own little SDL and GLFW wrappers I use for throw away projects. Makes the code cleaner and easier on the eyes (C APIs can be ugly). Jeremy did a great job with DSFML. When I first implemented DerelictSFML, there was a DMD bug on Linux 64-bit that caused crashes when passing structs to functions by value, which bits of the CSFML API require. That made the binding effectively unusable on Linux. Jeremy implemented his own C binding (DSFML-C) which eliminated the pass-by-value bits and then built DSFML on top of that. IIRC the bug has been fixed since then, so I don't know if DSFML is using CSFML directly now or not.
Re: Recommend: IDE and GUI library
On Wednesday, 1 March 2017 at 23:44:47 UTC, XavierAP wrote: For this I found out how to clone the dependencies, sorry about that... (Only from the command line... Anyone recommends better free Windows Git gui clients than GitHub Desktop?) TortoiseGIT maybe?
Re: Mixing libraries
On Thursday, 2 March 2017 at 01:02:39 UTC, Mike Parker wrote: On Wednesday, 1 March 2017 at 16:12:06 UTC, bauss wrote: There is a better binding. dsfml. You can find it here: http://dsfml.com/ DSFML technically is not a binding (even though it says such on the web site). It's a wrapper that D-ifies the SFML API. The SFML functions are not callable directly, as they are all declared privately. DerelictSFML is strictly a binding, with no attempt to wrap anything. A wrapper like DSFML could be implemented on top of DerelictSFML. So yes, it's better if what you really want is a wrapper. Ah yes, I think you explain the difference between wrapper/binding in one of the Derelict docs. I'm currently working through a ebook on Game Dev with SFML...the examples are all C++. I don't have any trouble translating it to the equivalent C bindings (so far anyway), but perhaps in the long run using dsfml will be easier (for example, I found using Iup4d easier than the straight C Iup bindings).
Re: Alignment of struct containing SIMD field - GDC
On Wednesday, 1 March 2017 at 22:15:59 UTC, Iain Buclaw wrote: On Wednesday, 1 March 2017 at 19:09:24 UTC, Johan Engelen wrote: On Wednesday, 1 March 2017 at 18:34:16 UTC, Iain Buclaw wrote: Simple test case would be: struct vec_struct { bool b2; struct { bool b; int8 field; } } static assert(vec_struct.b.offsetof == 32); static assert(vec_struct.field.offsetof == 64); With explicit align(32), it works: https://godbolt.org/g/3GjOHW - Johan Well obviously, because it adheres to explicit alignment. The compiler just has the wrong idea of how default alignment should work. Raised bug here, and I'm raising a PR now also. https://issues.dlang.org/show_bug.cgi?id=17237 In a dream world where engineers have nothing better to do, it would of course be better to effectively delete the inner anonymous struct so that the two bools could be packed together adjacently. I presume that that is theoretically ok? In contrast, if the sub-struct were named, you could presumably take the address of the entire sub-struct, so the space-inefficient offset to it is something you are just stuck with of course. A noob question: is it illegal to reorder the fields in a struct? (e.g. so as to optimise packing as far as correct alignment allows) - (C compatibility? Would perhaps need to be an _option_?)
Re: Alignment of struct containing SIMD field - GDC
On Wednesday, 1 March 2017 at 22:15:59 UTC, Iain Buclaw wrote: On Wednesday, 1 March 2017 at 19:09:24 UTC, Johan Engelen wrote: On Wednesday, 1 March 2017 at 18:34:16 UTC, Iain Buclaw wrote: Simple test case would be: struct vec_struct { bool b2; struct { bool b; int8 field; } } static assert(vec_struct.b.offsetof == 32); static assert(vec_struct.field.offsetof == 64); With explicit align(32), it works: https://godbolt.org/g/3GjOHW - Johan Well obviously, because it adheres to explicit alignment. The compiler just has the wrong idea of how default alignment should work. Raised bug here, and I'm raising a PR now also. https://issues.dlang.org/show_bug.cgi?id=17237 Thanks for your help Iain. And many thanks btw for all the general good work which is very much appreciated by this particular geriatric asm programmer. I checked the case of XMM alignment, and it's fine. I presume D does not yet support 512-bit zmm vector objects? (I have seen GDC doing a nice job generating auto-vectorised AVX512 code though - thanks.) The same bug would presumably bite again in that case otherwise?
Re: Mixing libraries
On Wednesday, 1 March 2017 at 16:12:06 UTC, bauss wrote: There is a better binding. dsfml. You can find it here: http://dsfml.com/ DSFML technically is not a binding (even though it says such on the web site). It's a wrapper that D-ifies the SFML API. The SFML functions are not callable directly, as they are all declared privately. DerelictSFML is strictly a binding, with no attempt to wrap anything. A wrapper like DSFML could be implemented on top of DerelictSFML. So yes, it's better if what you really want is a wrapper.
Re: Recommend: IDE and GUI library
On Wednesday, 1 March 2017 at 20:00:32 UTC, thedeemon wrote: If you're building your app with VisualD (as opposed to invoking dub externally), make sure you've set up import paths in project settings properly. Thanks. With dub everything works straight forward. I just call it blindly since it's the first time I use dub and I'm not sure everything it's supposed to do. Still I want to be able to be able to work and debug from Visual Studio. For this I found out how to clone the dependencies, sorry about that... (Only from the command line... Anyone recommends better free Windows Git gui clients than GitHub Desktop?) Import paths seem correctly setup in the project files from the repo, as I would expect. And once the dependency code is in its place it does build, both the library and the example applications. The problem I was having after all this was a runtime exception, but it happens only on 32-bit. Switching to 64-bit building and debugging works out of the box (after having cloned the subrepos). Here I have no idea if I have a drive issue, in any case 64-bit is enough for me. BTW the exception is: "derelict.util.exception.SymbolLoadException Failed to load OpenGL symbol [glEnableClientStateiEXT] " Also, if you use "minimal" configuration of DLangUI (which I recommend) you can remove mentions of SDL and GL from its dependencies in its dub.json, this way there are less things for compiler and VisualD to look for. I understand that in order to do this from Visual Studio, according to the instructions at github.com/buggins/dlangui, I should use configurations DebugMinimal instead of Debug, etc. But these configurations are not defined; I wonder if this documentation is out of sync with the current code. Otherwise I also though OpenGL wouldn't be used unless the version identifier USE_OPENGL was defined, but apparently it is not in VS as far as I can see? So in the end I'm not very sure whether OpenGL is kicking in in 64-bit when it works, or in general how to disable it (from Visual Studio instead of dub) -- or what are the consequences for performance or whatever. For now I can work like this and if I have additional problems that prevent me from advancing I will research it further... Thanks also @aberba and everyone.
Re: Alignment of struct containing SIMD field - GDC
On Wednesday, 1 March 2017 at 19:09:24 UTC, Johan Engelen wrote: On Wednesday, 1 March 2017 at 18:34:16 UTC, Iain Buclaw wrote: Simple test case would be: struct vec_struct { bool b2; struct { bool b; int8 field; } } static assert(vec_struct.b.offsetof == 32); static assert(vec_struct.field.offsetof == 64); With explicit align(32), it works: https://godbolt.org/g/3GjOHW - Johan Well obviously, because it adheres to explicit alignment. The compiler just has the wrong idea of how default alignment should work. Raised bug here, and I'm raising a PR now also. https://issues.dlang.org/show_bug.cgi?id=17237
Re: Recommend: IDE and GUI library
On Friday, 24 February 2017 at 22:44:55 UTC, XavierAP wrote: Hi I've looked at wiki.dlang.org/IDEs, and I see that Visual D is linked from dlang.org/download.html. Still I was looking for personal opinions and experiences beyond hard specs, I wonder if one of the IDEs is already dominant at least for each OS for any good reason. My requirements are quite ordinary: make x64, debug, go to definition, manage projects, code completion. My platform is Windows; interested if the choice would be different for Linux, if the same nice, otherwise I'd prefer to use whatever is best on each OS. And second question, is DWT the de facto standard for creating GUIs? Or are there good competitors. Sorry if I'm asking something too obvious, though I've looked around for answers before. And I've also searched the forum but really equivalent questions were over 2 years old and many things may have changed. Thanks! 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
Re: Recommend: IDE and GUI library
On Wednesday, 1 March 2017 at 17:37:02 UTC, XavierAP wrote: I'm trying now DlangUI on Visual D. I'm getting different errors from missing Derelict library dependencies... If you're building your app with VisualD (as opposed to invoking dub externally), make sure you've set up import paths in project settings properly. Two paths must be there: one like C:\Users\...\AppData\Roaming\dub\packages\dlangui-0.9.46\dlangui\src\ and the other like C:\Users\...\AppData\Roaming\dub\packages\dlangui-0.9.46\dlangui\3rdparty\ and in linker tab of project settings make sure you link to the dlangui.lib you should have built beforehand. Also, if you use "minimal" configuration of DLangUI (which I recommend) you can remove mentions of SDL and GL from its dependencies in its dub.json, this way there are less things for compiler and VisualD to look for.
Re: foreach for string[string]AA
On 02/28/2017 07:16 PM, Anton Pastukhov wrote: On Tuesday, 28 February 2017 at 17:16:43 UTC, Daniel Kozák wrote: V Tue, 28 Feb 2017 15:15:00 + Anton Pastukhov via Digitalmars-d-learn napsáno: I can't see the logic in AA foreach order. Consider this code: ... Output: three two one four I was sure output should be one two three four https://forum.dlang.org/post/xbanhtkvrizyqjcib...@forum.dlang.org Thank you for the link, it was informative reading. It's a pity that still there is no ordered AA at least as a library type. I had the same use case in the generator for GtkD, i needed fast lookup while iteration needed to preserve the insertion order. I opted for storing nodes of a linked list in the build in AA. The implementation[1] is currently LGPL to match the rest of the library, but if anyone would find it useful it can be changed to something else. [1] https://github.com/gtkd-developers/GtkD/blob/master/wrap/utils/LinkedHasMap.d -- Mike Wey
Re: Alignment of struct containing SIMD field - GDC
On Wednesday, 1 March 2017 at 18:34:16 UTC, Iain Buclaw wrote: Simple test case would be: struct vec_struct { bool b2; struct { bool b; int8 field; } } static assert(vec_struct.b.offsetof == 32); static assert(vec_struct.field.offsetof == 64); With explicit align(32), it works: https://godbolt.org/g/3GjOHW - Johan
Libharu D binding harud unicode support
How should one use libharu d binding in unicode mode. Consider this basic example. import std.stdio; import harud; import harud.c; void main() { void errorCallback(uint error_number, uint detail_number) { writefln("err %x, %s, (num %x)" , error_number , getErrorDescription(error_number), detail_number); } Doc pdf = new Doc(&errorCallback); /// New pdf document Font helvetica = pdf.getFont("Helvetica"); writeln("build font"); Page page = pdf.addPage(); /// Add a new page to the document writeln("page width:", page.width); auto status = page.setFontAndSize(helvetica, 60); /// Set the current font and size for the page writeln("set font width:", 60, " status", status); status = page.beginText(); /// Begin text mode writeln("begin ", status); status = page.showText("üçÇÜÖöĞğIı"); /// Print text to the page writeln("show ", status); page.endText(); /// End text mode pdf.saveToFile("./hello.pdf"); /// Write to disk } As you'd see I'd like to be able to write some Turkish characters to pdf file using libharu D binding.(a.k.a. harud)
Re: Alignment of struct containing SIMD field - GDC
On Wednesday, 1 March 2017 at 06:04:32 UTC, Cecil Ward wrote: struct vec_struct { alias field this; bool b; int8 field; } In this code when you look at the generated x64 code output by GDC it seems to be doing a nice job, because it has got the offset right for the 256-bit YMM 'field' correct. Does D automatically propagate the alignment restrictions on the field to the allocation of static structs or structs on the stack? In this case: struct vec_struct { bool b2; struct { alias field this; bool b; int8 field; } } it appears that the offset to 'field' is no longer aligned correctly - offset is 40 bytes in GDC. I don't suppose the compiler will use solely unaligned instructions? In any event, I could take the address of field and then pass that to someone expecting to pick up something with guaranteed correct alignment, if I have understood the D docs. Yeah, it looks like the semantic analysis pass is defeating us here. It's adding the anonymous struct offset to the aligned field, ignoring completely the original alignment. Or... the anonymous struct alignment != largest field alignment, which probably is the more likely scenario. Please raise a bug against DMD. Simple test case would be: struct vec_struct { bool b2; struct { bool b; int8 field; } } static assert(vec_struct.b.offsetof == 32); static assert(vec_struct.field.offsetof == 64); Noob q: I notice that the GDC opcodes look a bit odd, for example the compiler generates a 256-bit unaligned fetch followed by an aligned binary operation (I think), eg a movdqu followed by a vpaddd r, ymm ptr blah - is the latter aligned-only? Apologies if I have got this wrong, need to read up. Would someone sanity-check me? The x86 allows unaligned loads. But if this is referencing the above data structure, you shouldn't be seeing this if the fields were correctly aligned.
Re: rdmd with a file with no extension
On Wednesday, 1 March 2017 at 16:06:20 UTC, Colin wrote: When running a small D program through rdmd, it seems the file needs a .d extension to work. It looks like the file extension is enforced: https://dlang.org/dmd-windows.html#switches Looks like a feature rather than a bug... At the command line, both "file" or "file.d" make the compiler look for "file.d". Even "file.c" is understood as "file.c.d"
Re: Recommend: IDE and GUI library
On Tuesday, 28 February 2017 at 06:16:08 UTC, thedeemon wrote: For me Visual-D served well for years, and for GUI on Windows I've used DFL successfully (quite nice lib, very WinForms-like, with a visual editor) and now mostly use DLangUI (on both Windows and Linux). I'm trying now DlangUI on Visual D. I'm getting different errors from missing Derelict library dependencies... I see at github.com these are "subrepos" but after cloning the subrepo directories are still empty. Sorry this is my first time using Git/GitHub (used Mercurial and TortoiseHg at work, which I think would have cloned the subrepos without additional action). What am I missing?
Re: How to enforce compile time evaluation (and test if it was done at compile time)
On Wednesday, March 01, 2017 17:02:37 Dukc via Digitalmars-d-learn wrote: > On Wednesday, 1 March 2017 at 16:43:41 UTC, Jonathan M Davis > > wrote: > > Assert is for program invariants. If the condition is true, > > your program is outright broken. > > Error: He meant that if the condition is FALSE, the program is > faulty. LOL. True. Sorry about that. Invariants must be true, not false. I should have caught that. - Jonathan M Davis
Re: How to enforce compile time evaluation (and test if it was done at compile time)
On Wednesday, 1 March 2017 at 09:19:53 UTC, Christian Köstlin wrote: On 01/03/2017 00:09, Joseph Rushton Wakeling wrote: if (!__ctfe) assert(false); ... might be the best option. That shouldn't be compiled out even in -release builds. thats a nice idea! is this happening because of assert(false) being always part of release builds (as mentioned here: https://dlang.org/spec/contracts.html#assert_contracts) or because the if would have no instructions anymore if this is removed. Yes assert(false) or assert(0) is a special case according to the specification. At least in the DMD implementation it is not removed for -release. If reached it throws an "object.Error@(0): assert(0) or HLT instruction" instead of core.exception.AssertError
Re: How to enforce compile time evaluation (and test if it was done at compile time)
On Wednesday, 1 March 2017 at 16:43:41 UTC, Jonathan M Davis wrote: Assert is for program invariants. If the condition is true, your program is outright broken. Error: He meant that if the condition is FALSE, the program is faulty.
Re: How to enforce compile time evaluation (and test if it was done at compile time)
On Tuesday, February 28, 2017 09:16:47 sarn via Digitalmars-d-learn wrote: > On Tuesday, 28 February 2017 at 07:41:36 UTC, Christian Köstlin > > wrote: > > As I understand the only difference between assert and enforce > > is, that > > assert is not compiled into releases? > > > > Thanks! > > Christian > > Pretty much so. The intention is that assert means something > that's supposed to be true (and can be assumed in release) while > enforce means something you want to be true (but can't guarantee). > > E.g., you can assert that a list is sorted after running heapsort > on it, but you need to enforce that a file is in the correct > format. I'd put it more strongly than that. assert is for program invariants. If the condition is true, your program is outright broken. For performance reasons, assertions are removed in release builds, but many folks think that they should be left in and kill our program if they fail in release (and would be why some folks won't compile with -release even in production). assert(0) _does_ stay in your program in release mode and could be used in conjuction with an if statement (since it doesn't have a condition to test), but it's intended for unreachable code. Normally, assert throws an AssertError on failure (assert(0) becomes an HLT instruction in release), and types derived from Error are intended to kill your program on failure, precisely because they indicate a bug in your program and if they fail, it means that your program is in an undefined state (RangeError, which is use a failed bounds check for an array would be another example of an Error). Exceptions - specifically Exception or any type derived from it - are for general error conditions that occur while a program is running but do not necessarily indicate a bug in the program. Bad user input, stuff on disk, anything in the environment, etc. - i.e. anything over which you have no control - generally would be the sort of thing that triggers an exception when the program hits them. Exceptions are part of the normal operation of your program and are expected to be recoverable (though a typical program that hits no bad input would typically never need to throw an exception). In general, the distinction between assertions and exceptions should be very clear: assertions are for program invariants and exceptions are for when your program encounters bad input or any other error condition that does not indicate a bug in your program. Unfortunately however, the fact that enforce looks the same as assert does seem to confuse some folks. The only place that gets a bit debatable is testing arguments to a function, and that really depends on the function's contract. If the function requires that its input meet some conditions, and it's a bug if the caller does not meet them, then an assertion should be used, whereas if it's not a bug in the program if the caller provides bad input, then an exception is appropriate. And when it should be considered a program bug and when it should just be considered normal program execution depends on exactly what the function is doing as well as your programming style (e.g. some folks prefer that the caller be required to verify the correct input, whereas others prefer that the callee do that; there are pros and cons to both). So, that can get subjective. But ultimately, assertions are still for program bugs, whereas exceptions are for normal error conditions that do not indicate a bug in the program. - Jonathan M Davis
Re: Mixing libraries
On Tuesday, 28 February 2017 at 20:08:25 UTC, Jordan Wilson wrote: Hello, Been trying to learn the Simple Fast Multimedia Library (SFML) using the Derelict bindings, and noticed some functionality is offered by both SFML and the std library (for example, sfClock and sfMutex). Is there a general design principle of, say, use the std library whenever possible and only SFML when I have too? Or should I try to be consistent and use SFML library whenever possible? Thanks, Jordan There is a better binding. dsfml. You can find it here: http://dsfml.com/
rdmd with a file with no extension
When running a small D program through rdmd, it seems the file needs a .d extension to work. ``` $ ./testscript2 Error: module testscript2 is in file './testscript2.d' which cannot be read $ cat testscript2 #!/usr/bin/env rdmd void main(string[] args){ import std.stdio; writeln(args); } ``` Trying the above on OSX if that makes a difference. Any way to get these to work short of renaming it testscript2.d?
Re: foreach for string[string]AA
On Tuesday, 28 February 2017 at 18:16:45 UTC, Anton Pastukhov wrote: On Tuesday, 28 February 2017 at 17:16:43 UTC, Daniel Kozák wrote: V Tue, 28 Feb 2017 15:15:00 + Anton Pastukhov via Digitalmars-d-learn napsáno: I can't see the logic in AA foreach order. Consider this code: ... Output: three two one four I was sure output should be one two three four https://forum.dlang.org/post/xbanhtkvrizyqjcib...@forum.dlang.org Thank you for the link, it was informative reading. It's a pity that still there is no ordered AA at least as a library type. Ordered AA isn't that common a use case, and it's not without overhead. You essentially need to store an array of keys that define iteration order, which requires extra memory allocations (and, depending on implementation, may slow down iteration as well). I come from a Ruby background, so I have found key order useful in the past, but in most cases I probably could've gotten by just fine with an array or set of element pairs. Introduction of a more convenient tuple type into D might make something like this easier.
Re: How to enforce compile time evaluation (and test if it was done at compile time)
On 01/03/2017 00:09, Joseph Rushton Wakeling wrote: > On Tuesday, 28 February 2017 at 00:22:28 UTC, sarn wrote: >>> If you ever have doubts, you can always use something like this to >>> check: >>> >>> assert (__ctfe); >> >> Sorry, "enforce" would more appropriate if you're really checking. > > if (!__ctfe) assert(false); > > ... might be the best option. That shouldn't be compiled out even in > -release builds. thats a nice idea! is this happening because of assert(false) being always part of release builds (as mentioned here: https://dlang.org/spec/contracts.html#assert_contracts) or because the if would have no instructions anymore if this is removed. cK