Re: DFL is the best UIcontrols for D,compare it to dwt, tkd,dtk,dlangui,anchovy......
On Tuesday, 13 May 2014 at 00:10:15 UTC, FrankLike wrote: 1.DFL's Memory Usage is the least than other. winsamp.exe is 2.1M,DFL's example's exe is 2.7M. 2.The size of DFL's example's exe files is the least than other, and only a single file. 3.DFL's source code is the most easy to understand. DFL is just a thin wrapper around Win32, no surprise. I've found my apps written using DFL work quite fine in Linux via Wine, so I use them from both OSes.
Re: Are there desktop appications being developed in D currently?
On Saturday, 9 August 2014 at 00:34:43 UTC, Puming wrote: Yes, rust is a more infantile language compared to D, but people are already using them to create complicate applications like browser! Heh, Rust was initially created exactly to create a browser. Servo project is its main driver and purpose. I see the current hotspot of D are compilers、libs、http-server and game area, but haven't encountered an application project such as an editor, music player, etc. We've got some. Photo processing app: http://www.infognition.com/blogsort/ Disk space visualizer and redundancy searcher: http://www.infognition.com/undup/ A tool for watching some folders and processing video files there: http://www.infognition.com/VideoEnhancer/autovideoenhance.html And we're going to make the next major version of Video Enhancer itself in D too. All the apps were made with DFL - D Forms Library, a nice equivalent of .NET's WinForms.
Re: Are there desktop appications being developed in D currently?
On Sunday, 10 August 2014 at 04:41:45 UTC, Puming wrote: Photo processing app: Disk space visualizer and redundancy searcher: A tool for watching some folders and processing video files there... Interesting :-) Unfortunately they are all windows only apps, I don't have a windows machine. If you have Linux they work fine via Wine. Can I link them on my bookmarks about D projects? https://github.com/zhaopuming/awesome-d I'm not in position to decide if they're awesome or not. :) Not sure they fit into that list, but if you want to include a mention, I don't mind for sure.
Re: Recursive data-types
On Saturday, 27 September 2014 at 11:40:19 UTC, Rikki Cattermole wrote: These definitions can't work since Function and Atom need each other in this recursive definition. How to get out of this trap? Do I have to drop Algebraic and go back to manual tagged unions? Converting Function to a class. No where near ideal. But it'll work. Interesting, I didn't expect this to work... Got a longer workaround using some category theory and higher kinded types: http://www.infognition.com/blog/2014/recursive_algebraic_types_in_d.html
Re: A hash table implementation benchmark
On Wednesday, 1 October 2014 at 21:40:01 UTC, Ali Çehreli wrote: Are you motivated enough to compare D's associative arrays with those results? :) Here's another benchmark: D AAs vs. Vibe.d's open addressing hashes vs. Robin Hood hashing: http://www.infognition.com/blog/2014/on_robin_hood_hashing.html There's a link to a table with timings, meaning of which described in the post. Also compared a bit with C++'s CAtlMapint, int in MSVC 10 which I was told was pretty good. Generated 10 million random ints from range of 1 million, made a histogram and then read it. Exactly same data for both implementations (CAtlMap and Robin Hood in D). With default settings CAtlMap makes histo in 2.19 sec, reads it in 1.19 sec. Robin Hood in D makes same histo in 1.27 sec, reads in 1.09 sec (and it's DMD 32-bit!). After adding Rehash() between making and reading the histogram, CAtlMap makes histo in 2.37 sec, reads in 0.92.
Re: Obedient threads
Just use non-blocking receives in main thread's event loop. When you get a message from child thread that it's finished playing and you decide you don't need that thread anymore, send a message to child you're dismissed. The child should also have some loop to check for incoming messages non-blockingly. Upon receiving such message it should exit.
Re: Hunting down rogue memory allocations?
On Thursday, 2 October 2014 at 20:16:56 UTC, Gary Willoughby wrote: Say i have created a program written in D, what tools are available for me to track memory allocations? I wrote a tiny module trackallocs.d that inserts a GC proxy and outputs to log file (or stdout) all the allocations, gathering some stats. You can turn tracking on and off in any place of your code. Used it before 2.066 where @nogc appeared to check whether my code was allocation-free. Current version works in both 2.066 and earlier versions. Find it here: https://bitbucket.org/infognition/dstuff/src/ Inside it uses one hack based on knowledge of D runtime internals, so in future versions of D runtime, if Proxy struct changes again, it may need to be changed as well.
Re: Hunting down rogue memory allocations?
On Friday, 3 October 2014 at 09:27:50 UTC, Kiith-Sa wrote: https://bitbucket.org/infognition/dstuff/src/ Mind if I use some parts of it in my profiler? (there's no license) Sure, it's in public domain (as noted in readme).
Re: Exception thrown while trying to read file
On Friday, 3 October 2014 at 11:30:02 UTC, Matt wrote: I am building a PE-COFF file reader file.seek(0x3c, SEEK_SET); file.readf(%d, offs); // this is the problem line Does anyone else see whatever it is that I'm doing wrong? readf is for reading text, it expects to see some digits. You're reading a binary file, not a text, so no ASCII digits are found in that place. Use rawRead instead of readf.
Re: What is a sink delegate?
On Friday, 10 October 2014 at 03:06:33 UTC, Joel wrote:
How do you use that toString? Maybe an example?
void main() {
Try t = Try(Joel, 35);
t.toString(s = writeln(s));
}
Re: String created from buffer has wrong length and strip() result is incorrect
On Friday, 17 October 2014 at 06:29:24 UTC, Lucas Burson wrote:
// This is where things breaks
{
ubyte[] buff = new ubyte[16];
buff[0..ATA_STR.length] = cast(ubyte[])(ATA_STR);
// read the string back from the buffer, stripping
whitespace
string stringFromBuffer =
strip(cast(string)(buff[0..16]));
// this shows strip() doesn't remove all whitespace
writefln(StrFromBuff is '%s'; length %d,
stringFromBuffer, stringFromBuffer.length);
// !! FAILS. stringFromBuffer is length 15, not 3.
assert(stringFromBuffer.length == strip(ATA_STR).length);
Unlike C, strings in D are not zero-terminated by default, they
are just arrays, i.e. a pair of pointer and size. You create an
array of 16 bytes and cast it to string, now you have a 16-chars
string. You fill first few chars with data from ATA_STR but the
rest 10 bytes of the array are still part of the string, not
initialized with data, so having zeroes. Since this tail of
zeroes is not whitespace (tabs or spaces etc.) 'strip' doesn't
remove it.
Re: String created from buffer has wrong length and strip() result is incorrect
You fill first few chars with data from ATA_STR but the rest 10 bytes of the array are still part of the string Edit: you fill first 5 chars and have 11 bytes of zeroes in the tail. My counting skill is too bad. ;)
Re: Does the grammar allow an alias statement without a semicolon?
On Saturday, 18 October 2014 at 00:52:23 UTC, Solomon E wrote: Hi, everyone, first post here. I'm trying to learn to parse D code. Just in case, I'll remind these two projects that might be helpful: https://github.com/Hackerpilot/libdparse https://github.com/Hackerpilot/DGrammar
Re: Really in need of help with std.container.array.d
Speaking of this module, since I cannot currently login to bugtracker, I'd like to note here that there are two major bugs in one little function: Array.Payload.length setter. One is this https://issues.dlang.org/show_bug.cgi?id=13619 and the other is reallocating without notifying GC of the pointers, which leads to having dangling pointers in the array after a GC cycle.
Re: Really in need of help with std.container.array.d
On Tuesday, 21 October 2014 at 04:22:37 UTC, thedeemon wrote: Speaking of this module, since I cannot currently login to bugtracker, I'd like to note here that there are two major bugs in one little function: Array.Payload.length setter. One is this https://issues.dlang.org/show_bug.cgi?id=13619 and the other is reallocating without notifying GC of the pointers, which leads to having dangling pointers in the array after a GC cycle. Submitted the second one here: https://issues.dlang.org/show_bug.cgi?id=13642
Re: Pointer across threads
On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote: I'm still curious, though, how D handles this internally, because data.data is still mutable while the other reference to the same address (tmp) is not. What if I change data.data while the other thread is being executed? immutable is part of the static type system, it's a label that only exists and makes sense at compile time, for compiler and the programmer. Casting a mutable data pointer to immutable data pointer is a no-op, just a copy of pointer. Address stays the same, data stays the same. So if you mutate the data it will lead to immutable data being changed just because it's not really immutable, you've just fooled yourself when doing the cast.
Re: Access Violation Tracking
On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote: Is there any way to track down access violations, instead of me having to look through my source code manually. I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run. So if there is a way to catch an access violation and find out where it occured it would be appreciated! What OS are you using? Did you run any debugger?
Re: How to turn this C++ into D?
On Wednesday, 5 November 2014 at 17:45:00 UTC, luminousone wrote:
abstract class foo {
static DList!foo foo_list;
~this(){ foo_list.remove(this); }
One note: when your program exits the runtime does a final GC
cycle and collects those things calling destructors/finalizers,
however the static data can easily be already
collected/destructed at this moment, so attempting to access it
from object's finalizer will crash. One should not ever access
any reference types and data outside the object itself from a
destructor/finalizer.
Re: Easy way to monitor gc activity?
On Wednesday, 12 November 2014 at 10:43:32 UTC, Tofu Ninja wrote: What is an easy way to monitor gc activity? Here's mine: https://bitbucket.org/infognition/dstuff/src/ A little module that allows you to track all GC allocations.
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 11:50:18 UTC, Ivan Kazmenko wrote: Hi! I'm unsure what is the Russian equivalent for the term range, as in D range, the generalization of a pair of iterators. I think последовательность (sequence) is the most appropriate, because the defining characteristic of an input range (most common one) is ability to provide data sequentially. Also, afaik, some languages like F# and Clojure use this term (often shortened to 'seq') for the same thing that D calls ranges.
Re: Destructor/Finalizer Guarantees
On Tuesday, 11 November 2014 at 22:31:17 UTC, Maxime Chevalier-Boisvert wrote: I've made it so they unregister themselves in their destructor. ... However, this only works if I can assume that the GC will first call the destructor on an object, then free the object, that this is done in a predictable order. This order is not really predictable now. In general in destructor you can't access anything outside the object's value typed fields. Any reference may point to a dead object at this moment, any external or global object may be destroyed already.
Re: Destructor/Finalizer Guarantees
On Wednesday, 12 November 2014 at 04:06:11 UTC, Algo wrote:
Could this work?
class VM {
static List[VM*] _gcRootLists;
List* gcRootList;
~this() {
_gcRootLists.remove(this);
No. Hash-table operations may try to allocate or free memory
which is not allowed during a GC cycle where the destructors are
called. It will just cause InvalidMemoryOperationError and the
program will exit abnormally.
Re: std.array oddness
On Saturday, 13 December 2014 at 06:40:41 UTC, ketmar via Digitalmars-d-learn wrote: .map!a.idup That can be just .map!idup.
Re: Call of rmdir in destructor causes InvalidMemoryOperationError
On Thursday, 1 January 2015 at 15:14:41 UTC, Timo Gransch wrote: Hi, I have a class which unzips an archive into a temporary directory below the system temp folder. I want to delete this temporary directory in the class's destructor, but when I call rmdir there, I get an core.exception.InvalidMemoryOperationError@(0) Destructors are usually called by GC, during a GC cycle, so allocating and deallocating memory is not allowed there. If some function allocates, reallocates or deallocates, it will cause this very error. This means you shouldn't use any functions in a destructor that are not @nogc. Solution in this case: call rmdir not from destructor.
Re: Constructing a tuple dynamically
On Tuesday, 3 February 2015 at 10:32:47 UTC, Pena wrote:
How can I use this code or something similar to dynamically
construct a tuple containing types of fields marked as
@Cloneable?
import std.traits, std.typetuple;
template CloneableTypes(S) {
template IsCloneable(string M) {
enum IsCloneable = staticIndexOf!(Cloneable,
__traits(getAttributes, __traits(getMember, S, M))) = 0;
}
template FieldType(string M) {
alias FieldType = typeof(__traits(getMember, S, M));
}
alias CloneableTypes = staticMap!(FieldType,
Filter!(IsCloneable, __traits(allMembers, S)));
}
Then CloneableTypes!Foo is a TypeTuple (int, string).
Re: Is there websocket client implementation for D
On Tuesday, 24 March 2015 at 17:55:38 UTC, Ilya Korobitsyn wrote: Hello! Is there any websocket client implementation in D? There's some WebSocket stuff here: https://github.com/adamdruppe/arsd/blob/master/cgi.d It's for server side, but probably contains stuff you need for client too.
Re: Speed of horizontal flip
std.algorithm.reverse uses ranges, and shamefully DMD is really bad at optimizing away range-induced costs.
Re: problem with parallel foreach
On Tuesday, 12 May 2015 at 14:59:38 UTC, Gerald Jansen wrote: The output of /usr/bin/time is as follows: Lang JobsUser System Elapsed %CPU Py 2 79.242.16 0:48.90 166 D 2 19.41 10.14 0:17.96 164 Py 30 1255.17 58.38 2:39.54 823 * Pool(12) D 30 421.61 4565.97 6:33.73 1241 The fact that most of the time is spent in System department is quite important. I suspect there are too many system calls from line-wise reading and writing the files. How many lines are read and written there?
Re: What wrong?
On Saturday, 2 May 2015 at 02:51:52 UTC, Fyodor Ustinov wrote: Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ What I'm doing wrong? Try using class instead of struct. Last time I played with std.concurrency it used Variants to store the messages, so when something bigger than a little basic value or a reference, like a class object, is sent it behaves unpredictably: can crash or shit garbage. Trying to send structs larger than ~20 bytes usually caused problems.
Re: The analogue of fill-pointer in D
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote: No, afraid not. Function capacity is not an analogue of fill-pointers! It's exactly the same. Lisp-programmer explains the usefulness of fill-pointers as follows: Fill pointer cuts the tail of the vector. In D: .length cuts the tail of the vector. For example, vector elements 100, but if you set the fill pointer equal to 3, the length of the array (returned by length) will be equal to 3. The remaining elements are not visible. In D: vector elements 100, but if you set the .length equal to 3, the length of the array (returned by length) will be equal to 3. The remaining elements are not visible. .capacity tells you real size of the buffer while .length is like that fill pointer.
Re: -vgc Info ok?
On Monday, 18 May 2015 at 14:30:43 UTC, Chris wrote: Why is _accessing_ an assoc treated as indexing it? Are you sure you understand indexing as we do? It's not like indexing of databases, it's just accessing by index i.e. using myarray[some_index].
Re: problem with parallel foreach
On Tuesday, 12 May 2015 at 20:50:45 UTC, Gerald Jansen wrote: Your advice is appreciated but quite disheartening. I was hoping for something (nearly) as easy to use as Python's parallel.Pool() map(), given that this is essentially an embarassingly parallel problem. Avoidance of GC allocation and self-written buffered IO functions seems a bit much to ask of a newcomer to a language. You're right, these are issues of D's standard library that are not easy for a newcomer to tackle. In case of Python's parallel.Pool() separate processes do the work without any synchronization issues. In case of D's std.parallelism it's just threads inside one process and they do fight for some locks, thus this result.
Re: problem with parallel foreach
On Wednesday, 13 May 2015 at 06:59:02 UTC, Ali Çehreli wrote: In case of Python's parallel.Pool() separate processes do the work without any synchronization issues. In case of D's std.parallelism it's just threads inside one process and they do fight for some locks, thus this result. Right. To do the same in D, one must use fibers. No, to do the same one must use separate OS processes. Fibers won't help you against parallel threads fighting for GC IO locks.
Re: C++ to D - recursion with std.variant
On Friday, 3 April 2015 at 16:46:08 UTC, Dennis Ritchie wrote: Hi, Is it possible to write on D recursion using std.variant? Using Algebraic from std.variant and some additional templates: http://dpaste.dzfl.pl/65afd3a7ce52 (taken from this thread: http://forum.dlang.org/thread/yidovyrczgdiveqba...@forum.dlang.org?page=1 )
Re: More type-flexible arrays?
On Sunday, 14 June 2015 at 06:12:30 UTC, Ozan wrote: Is it possible to create arrays which has more then one type, f. ex. array[0] = 1; array[1] = z; array[2] = new clazz(), Probably tuples are what you really need here. http://dlang.org/phobos/std_typecons.html#.Tuple
Re: DFL background tasks
On Wednesday, 10 June 2015 at 22:18:21 UTC, Scroph wrote: client.perform; while(!client.isStopped) I don't think this will work as you expect. perform is a synchronous call, it will not return until the download finishes, as I understand, so your while loop is too late. I think you should insert message processing stuff inside onProgress, though it's also suboptimal (if no progress for long time - no joy). Proper design will require more thought...
Re: How to implement immutable ring buffer?
This whole idea sounds self-contradictory. Ring buffer is a mutable-array-based implementation of something, for example of a queue. You can ask about immutable implementations of a queue, but that would be another question, not involving a ring buffer. What do you want to do with this buffer, what do you need it for?
Re: drastic slowdown for copies
On Friday, 29 May 2015 at 07:51:31 UTC, thedeemon wrote: Above was on Core 2 Quad, here's for Core i3: 4 ints 5 ints -release by ref: 67 by ref: 66 by copy: 44 by copy: 142 by move: 45 by move: 137 -release -O by ref: 29 by ref: 29 by copy: 41 by copy: 141 by move: 40 by move: 142 -release -O -inline by ref: 16 by ref: 20 by copy: 83 by copy: 104 by move: 83 by move: 104
Re: drastic slowdown for copies
On Thursday, 28 May 2015 at 21:23:11 UTC, Momo wrote: Ah, actually it's more complicated, as it depends on inlining a lot. Indeed, without -O and -inline I was able to get by_ref to be slightly slower than by_copy for struct of 4 ints. But when inlining turns on, the numbers change in different directions. And for 5 ints inlining influence is quite different: 4 ints: 5 ints: -release by ref: 53 by ref: 53 by copy: 57 by copy: 137 by move: 54 by move: 137 -release -O by ref: 38 by ref: 34 by copy: 54 by copy: 137 by move: 49 by move: 137 -release -O -inline by ref: 15 by ref: 20 by copy: 72 by copy: 91 by move: 72 by move: 91
Re: drastic slowdown for copies
On Thursday, 28 May 2015 at 21:23:11 UTC, Momo wrote: I'm currently investigating the difference of speed between references and copies. And it seems that copies got a immense slowdown if they reach a size of = 20 bytes. This is processor-specific, on different models of CPUs you might get different results. Here's what I see running your program with 4 and 5 ints in the struct: C:\prog\Ddmd copyref.d -ofcopyref.exe -release -O -inline 16u C:\prog\Dcopyref.exe by ref: 18 by copy: 85 by move: 84 C:\prog\Dcopyref.exe by ref: 18 by copy: 72 by move: 72 C:\prog\Dcopyref.exe by ref: 16 by copy: 72 by move: 72 C:\prog\Ddmd copyref.d -ofcopyref.exe -release -O -inline 20u C:\prog\Dcopyref.exe by ref: 23 by copy: 98 by move: 91 C:\prog\Dcopyref.exe by ref: 20 by copy: 91 by move: 102 C:\prog\Dcopyref.exe by ref: 23 by copy: 91 by move: 91 I see these digits on an old Core 2 Quad and very similar on a Core i3. So your findings are not reproducible.
Re: problem with gc?
On Wednesday, 27 May 2015 at 05:48:13 UTC, zhmt wrote: What happened when the code changes a little? Who will give an explaination,Thanks a lot? Yes, on the first sight it looks like your allocations in the loop make GC spend too much time. I don't think scope does anything here. Try adding delete str; to the end of the loop, it should do what your scope meant. I know it's deprecated but sometimes it's just right.
Re: incorrect data when returning static array in place of dynamic
On Sunday, 5 July 2015 at 18:57:46 UTC, sigod wrote: Why does function return incorrect data? Using `.dup` in return expression or using `ubyte[20]` as return type fixes problem, but why? Because sha1Of() returns ubyte[20], this is a stack-allocated array, a value type. If you put correct return type there, it will be returned by value and everything's fine. If your return type is ubyte[] (a reference type), a slice of stack-allocated array is returned which creates a reference to stack data that doesn't exist anymore.
Re: Checking template parameter types of class
On Monday, 25 May 2015 at 04:15:00 UTC, tcak wrote: main.d(243): Error: class main.FileResourceList(T) if (is(T : FileResource)) is used as a type The error message is not indicating directly this, though logically it is still correct. Compiler means template is used as a type which is an error since templates are not types. I guess adding the word template to that message would make it more clear.
Re: How to provide this arg or functor for algorithm?
On Monday, 17 August 2015 at 09:51:47 UTC, anonymous wrote: Huh. I think func being a template is the key here. When the original code is put in a template, it works too (with 2.068): Nope, it works only because r is unreferenced and gets thrown out. Just try using r.front there, for example, and the error returns.
Re: How to provide this arg or functor for algorithm?
On Monday, 17 August 2015 at 12:38:05 UTC, anonymous wrote:
auto func()(uint[] arr, uint delegate(uint) pure @nogc d) @nogc
{
return arr.map!(d);
}
void main() @nogc
{
uint[3] arr = [1,2,3];
uint context = 2;
auto c = Caller(context);
auto d = c.method;
auto r = func(arr[], d);
import std.algorithm: equal;
import std.range: only;
assert(equal(r, only(2, 4, 6)));
}
I've just checked with my runtime GC hook. Here the call to
func() allocates 12 bytes via gc_malloc, and it's the same for a
4-elements array, so it's not for the array itself, it's for a
closure, I think.
Re: GC and MMM
On Thursday, 20 August 2015 at 17:13:33 UTC, Ilya Yaroshenko wrote: Hi All! Does GC scan manually allocated memory? Only if you ask GC to do it - by calling core.memory.addRange.
Re: How to provide this arg or functor for algorithm?
On Monday, 17 August 2015 at 16:18:50 UTC, thedeemon wrote: I've just checked with my runtime GC hook. Here the call to func() allocates 12 bytes via gc_malloc, and it's the same for a 4-elements array, so it's not for the array itself, it's for a closure, I think. Also, compiling with -vgc says nothing, compiler (2.068) seems to miss this allocation.
Re: Thread communication
On Tuesday, 4 August 2015 at 15:19:51 UTC, Chris wrote: I want to stop (and abort) the worker as soon as new input arrives. However, while executing the function that contains the foreach-loop the worker thread doesn't listen, because it's busy, of course. I think this is a matter of architecture. If you want to use message-passing and you want the worker to react quickly to new events, this means it needs to check for new messages (via receiveTimeout) often enough, there's no way around it.
Re: Why my app require MSVCR120.dll?
On Sunday, 8 November 2015 at 05:11:50 UTC, suliman wrote: On Sunday, 8 November 2015 at 04:50:49 UTC, thedeemon wrote: On Saturday, 7 November 2015 at 10:03:58 UTC, Suliman wrote: I am using DMD. -m64 or -m32mscoff ? Without any keys. I use dub for building I suspect your issue is caused by botan library on which vibe-d depends: http://code.dlang.org/packages/botan It says it needs MS linker on Windows and so most probably depends on MSVC runtime. Usually when you build something with DMD without -m64 or -m32mscoff it makes a binary without such dependencies, it uses its own C library (snn.lib) statically linked.
Re: Why my app require MSVCR120.dll?
On Saturday, 7 November 2015 at 10:03:58 UTC, Suliman wrote: I am using DMD. -m64 or -m32mscoff ?
Re: Tell GC to use shared memory
On Thursday, 8 October 2015 at 09:25:36 UTC, tcak wrote: On Thursday, 8 October 2015 at 05:46:31 UTC, ketmar wrote: On Thursday, 8 October 2015 at 04:38:43 UTC, tcak wrote: Is it possible to modify GC (without rebuilding the compiler), so it uses a given shared memory area instead of heap for allocations? sure. you don't need to rebuild the compiler, only druntime. Any better solution? Like overriding GC class, etc. You can install your own GC proxy, see module gc.proxy in druntime, the struct Proxy and functions gc_getProxy, gc_setProxy. No need to recompile druntime. Here's an example where I install my own GC proxy to do all allocations in my arena: https://bitbucket.org/infognition/dstuff/src/97cef6d4a0438f9a9f4ff0d18f819262b8a74888/gcarena.d?at=default=file-view-default
Re: Working Windows GUI library?
On Friday, 4 September 2015 at 13:54:25 UTC, Andre Polykanine wrote: Hello thedeemon, tvDdl> Yes, DFL! tvDdl> https://github.com/Rayerd/dfl Sounds good. but still... I can't find any examples or documentation :( Here's some original docs and examples: http://wiki.dprogramming.com/Dfl/Tutorial http://wiki.dprogramming.com/Dfl/HomePage Documentation is a bit scarce, but if you're familiar with WinForms (from .NET) you'll recognize everything immediately and will feel at home with DFL. Here's a real world sample - an app I made for our clients: https://bitbucket.org/thedeemon/autovideoenhance For instance, a simple typical form (window) code: https://bitbucket.org/thedeemon/autovideoenhance/src/b0259ca763577cb50169eaa7ee99f074da21724d/folderform.d?at=default (most of the big setup code is generated by Entice Designer, not written manually)
Re: spawn X different workers & wait for results from all of them
On Thursday, 3 September 2015 at 16:50:21 UTC, Robert M. Münch wrote: Hi, I'm not sure how to best implement the following: 1. I have 4 different tasks to do. 2. All can run in parallel 3. Every task will return some result that I need Now how to best do it? I think the Task and taskPool from std.parallelism are a good fit. Something like: auto task1 = task!fun1(params1); auto task2 = task!fun2(params2); auto task3 = task!fun3(params3); auto task4 = task!fun4(params4); taskPool.put(task1); taskPool.put(task2); taskPool.put(task3); taskPool.put(task4); auto res1 = task1.workForce(); auto res2 = task2.workForce(); auto res3 = task3.workForce(); auto res4 = task4.workForce(); //here we have all the results, they were calculated in parallel
Re: interprocess communication and sharing memory
On Thursday, 3 September 2015 at 02:52:00 UTC, Laeeth Isharc wrote: On Thursday, 3 September 2015 at 01:27:15 UTC, j55 wrote: This is my first attempt at a project in D, so pardon me if I'm overlooking something obvious: I'm using libasync to create an eventloop, to set up something like a server/daemon process. This part works very well. We'll call this Server A. Now I'd like to write another process (running on the same computer), we'll call Client B, and pass signals in to Server A. It's probably a stupid idea, but until someone with experience answers: what happens if you declare the memory as shared or __gshared and send a pointer to it via message passing or a pipe? Pointer from one process doesn't make any sense in another process, they point to different data in different address spaces, and most probably in the second process memory at this "address" isn't even allocated by the app, so it would be an access violation.
Re: Working Windows GUI library?
On Thursday, 3 September 2015 at 15:46:28 UTC, Andre Polykanine wrote: So my question is: is there any reliable GUI library implementing native Windows controls? Yes, DFL! https://github.com/Rayerd/dfl It's a thin wrapper over WinAPI so all controls are native. I've built several apps with it and quite happy with this library. It comes with a graphical interface builder called Entice Designer which is rather old but still works fine. Also, with this lib your app is just a single binary less than 1 MB, no additional DLLs required.
Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?
On Monday, 21 September 2015 at 15:00:24 UTC, ponce wrote: All in the title. DMD 64-bit links with the VS linker. Do users need to install the VS redistributable libraries? I think they don't. Generated .exe seems to depend only on kernel32.dll and shell32.dll, i.e. things users already have.
Re: Can I check if a value is convertible to a valid value of an enum?
On Friday, 25 September 2015 at 03:12:20 UTC, French Football wrote: ...without having to loop over the enum? writeln( test( valid_value ) ); //prints true Since `value` is known only at run time, some checks need to be performed at run time anyway. One way of doing it without iterating over all variants is to create a static hash table bool[string] valid_strings; and populate it in static constructor, then in your function you can just write if (value in valid_strings) ...
Re: How is D doing?
On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote: Google Trends shows something interesting: https://google.com/trends/explore#q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q%2C%20C%2B%2B=q=Etc%2FGMT-2 Today I Learned C++ is most interested by in Ethiopia. ;)
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote: So far I've been implementing windowing and image libraries for Phobos. Right now windowing works on Windows minice eventing. Once eventing is done it is ready for the first stage of feedback. I don't understand something about this project. Having existing GtkD, DFL, DlangUI, SimpleDisplay, DQuick and probably a few others, creating windows on different platforms and eventing seems to be a solved problem, multiple times solved. But your project is lasting for years at this little stage. And this makes me wonder what it is about.
Re: Make Simple Things Hard to Figure out
On Monday, 21 December 2015 at 13:51:57 UTC, default0 wrote: As this isn't really a question for Learn I'm not sure if it fits here. This is more of a "This is how I went about trying to learn X. These are the problems I encountered. Ideas to improve?" but I guess I might as well post it here. Thanks for sharing! Obviously Phobos documentation could and should be improved, people are working on it but unlike some other languages there's nobody in D community working full time on documentation and articles. And D user base is still quite small, so Stack Overflow is not quite overflown with D-related answers. Out of curiosity I looked into "D Cookbook" to check if it contains your particular case but the only mention of Base64 there is about encoding some data into Base64, not the other way around.
Re: How to use D parallel functions/library
On Tuesday, 24 November 2015 at 18:49:25 UTC, Bishop120 wrote:
I figured this would be a simple parallel foreach function with
an iota range of sizeX and just making int X declared inside
the function so that I didnt have to worry about shared
variable but I cant get around the alive++ reduction and I dont
understand enough about D's reduction/parallel library.
Any ideas? Thanks in advance for yalls patience and assistance!
Incrementing often the same variable from different parallel
threads is a very bad idea in terms of performance. I would
suggest counting number of alive cells for each row independently
(in a local non-shared variable) and storing it to an array (one
value per row), then after the loop sum them up.
auto aliveCellsPerRow = new int[N];
foreach(i; iota(N).parallel) {
int aliveHere;
//...process a row...
aliveCellsPerRow[i] = aliveHere;
}
alive = aliveCellsPerRow.sum;
Then everything will be truly parallel, correct and fast.
Re: Accessing COM Objects
On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote:
Cool. Oleview gives me the idl files. How to convert the idl
files to d or possibly c?
There are ready tools idl2d:
https://github.com/dlang/visuald/tree/master/c2d
and tlb2idl:
https://github.com/dlang/visuald/tree/master/tools
I've used this idl2d and it works pretty well (although not
perfect, sometimes manual editing still required).
Example of real-world DirectShow interfaces translated:
https://gist.github.com/thedeemon/46748f91afdbcf339f55da9b355a6b56
Would I just use them in place of IUnknown once I have the
interface?
If you have the interface defined AND you know its IID, you can
request it from CoCreateInstance and then use as ordinary D
object.
You might want to look at this wrapper that takes most of COM
machinery:
https://gist.github.com/thedeemon/3c2989b76004fafe9aa0
Then you just write almost as in C#, something like
auto pGraph = ComPtr!IGraphBuilder(CLSID_FilterGraph,
"pGraph").require;
ComPtr!ICaptureGraphBuilder2 pBuilder =
ComPtr!ICaptureGraphBuilder2(CLSID_CaptureGraphBuilder2).require;
pBuilder.SetFiltergraph(pGraph);
...
auto CLSID_NullRenderer =
Guid!("C1F400A4-3F08-11D3-9F0B-006008039E37"); //qedit.dll
auto pNullRendr = ComPtr!IBaseFilter(CLSID_NullRenderer,
"nulrend");
pGraph.AddFilter(pNullRendr, "Null Renderer"w.ptr);
...
auto imf = ComPtr!IMediaFilter(pGraph);
imf.SetSyncSource(null);
All the CreateInstance, QueryInterface, AddRef/Release etc. is
taken care of. And even HRESULT return codes are automatically
checked.
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 07:01:30 UTC, Joerg Joergonson wrote: It seems idl2d from VD is not easily compilable? I don't remember problems with that, anyway here's the binary I used: http://stuff.thedeemon.com/idl2d.exe
Re: ARSD PNG memory usage
On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote: Hi, so, do you have any idea why when I load an image with png.d it takes a ton of memory? I've bumped into this previously. It allocates a lot of temporary arrays for decoded chunks of data, and I managed to reduce those allocations a bit, here's the version I used: http://stuff.thedeemon.com/png.d (last changed Oct 2014, so may need some tweaks today) But most of allocations are really caused by using std.zlib. This thing creates tons of temporary arrays/slices and they are not collected well by the GC. To deal with that I had to use GC arenas for each PNG file I decode. This way all the junk created during PNG decoding is eliminated completely after the decoding ends. See gcarena module here: https://bitbucket.org/infognition/dstuff You may see Adam's PNG reader was really the source of motivation for it. ;)
Re: Accessing COM Objects
On Wednesday, 15 June 2016 at 21:06:01 UTC, Joerg Joergonson wrote: Ok, I've tried things like uncommenting Document Open(BSTR Document, VARIANT As, VARIANT AsSmartObject); void Load(BSTR Document); /*[id(0x70537673)]*/ BSTR get_ScriptingVersion(); /*[id(0x70464D4D)]*/ double get_FreeMemory(); /*[id(0x76657273)]*/ BSTR get_Version(); and everything crashes with bad reference. ... My thinking is that CoCreateinstance is suppose to give us a pointer to the interface so we can use it, if all this stuff is crashing does that mean the interface is invalid or not being assigned properly or is there far more to it than this? First of all, you can't just comment/uncomment parts of COM interface descriptions. Each COM interface has some specific layout of its functions, and if you list them in wrong order or skip some of them the virtual methods table gets completely screwed up, so you think you call one method but end up calling another, because you intended to call method #12 and instead called method #4. COM interface definitions in D must match their definitions in IDL exactly. One omission of a method, one mistake in its type, and you're fucked.
Re: Registration-free COM client
On Monday, 27 June 2016 at 21:17:52 UTC, Thalamus wrote:
Hi everyone,
I've succeeded in using D as a client for regular (registered)
COM servers in the past, but in this case, I'm building the
server as well. I would like to avoid registering it if
possible so XCOPY-like deployment remains an option. Can a
registration-free COM client be built in D? If so, how can the
code be setup to consume the manifest file, or alternately, is
there a way to just point D to the correct assembly directly in
code?
To load load a COM object from a given file (DLL or AX) without
having it registered, just load the file with CoLoadLibrary() and
use its DllGetClassObject() function to get IClassFactory which
will give you any kind of object in this library.
Here's how I do it (in my case the requested object has
"IBaseFilter" COM interface):
IBaseFilter createDSFilterFromFile(GUID guid, string dir, string
fname) {
auto curdir = getcwd();
scope(exit) chdir(curdir);
chdir(dir); // in case the lib depends on other dlls nearby
auto hinst = CoLoadLibrary( cast(wchar*) buildPath(dir,
fname).toUTF16z, TRUE);
enforce!COMException(hinst);
auto fnGetClassObject = cast(LPFNGETCLASSOBJECT)
GetProcAddress(hinst, "DllGetClassObject");
enforce!COMException(fnGetClassObject);
IClassFactory factory;
auto iid = IID_IClassFactory;
fnGetClassObject(, ,
cast(void**)).checkHR("fnGetClassObject failed");
enforce!COMException(factory);
IBaseFilter ibf;
factory.CreateInstance(null, _IBaseFilter,
cast(void**)).checkHR("factory.CreateInstance");
return ibf;
}
Re: Things that keep D from evolving?
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise & fast GC implementations? Unions and easy type casting prevent precise GC. Lack of write barriers for reference-type fields prevent fast (generational and/or concurrent) GC. Some more detailed explanations here: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
Re: Things that keep D from evolving?
On Tuesday, 9 February 2016 at 17:41:34 UTC, NX wrote: I would want it to be solved rather than being worked on... which requires design change which is probably not going to happen. There is still room for improvement though. Right. I think there are at least two things that can improve current GC without any changes in design: parallel marking and lazy sweeping. Currently (at least last time I checked) GC pauses the world, then does all the marking in one thread, then all the sweeping. We can do the marking in several parallel threads (this is much harder to implement but still doable), and we can kick the sweeping out of stop-the-world pause and do the sweeping lazily: when you try to allocate some memory it will not just look in free lists, it will try to collect some unused unswept memory from the heap first. This way allocations become a bit slower but GC pause time reduces significantly. Concurrent sweeping is another possibility. Of course, it's all easier said than done, without an actual hero who would code this, it remains just talk.
Re: Functions that return type
On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote: I guess the constraints are that of a static language. (This is not true.) I'm playing with the design of such a language myself. Basically, anything can create/use/return type objects This is usually possible in dependently typed languages such as Idris, Agda or Coq. Check out Idris, it's rather small but very nice and interesting.
Re: D Book page 402 Concurrency FAIL
On Sunday, 14 February 2016 at 22:54:36 UTC, Brother Bill wrote:
Please provide full replacement of this toy program that works
with D version 2.070.0
This one works fine for me in Windows with VisualD and DMD
2.070.0:
--
import std.concurrency, std.stdio, std.exception;
void main() {
auto low = 0,
high = 100;
auto tid = spawn();
foreach (i; low .. high) {
writeln("Main thread: ", i);
tid.send(thisTid, i);
enforce(receiveOnly!Tid() == tid);
}
}
void writer() {
scope(failure) return;
for (;;) {
auto msg = receiveOnly!(Tid, int)();
writeln("secondary thread: ", msg[1]);
msg[0].send(thisTid);
}
}
--
Just one line added to writer() in order to catch OwnerTerminated
exception and end the thread silently. Original version produced
an error when main thread finished before the writer thread.
Re: Photoshop programming
On Sunday, 14 February 2016 at 09:48:54 UTC, Patience wrote:
Photoshop has the ability to be controlled by scripts and
programming languages. For example, C# can be used to access
photoshop by adding the appropriate reference and using
directives. I believe it is COM based but I am not totally sure.
I've tried reading the docs but it's not making much sense.
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf
links at the bottom are down.
It says one has to create a wrapper, but then talks like it can
be done automatically. I assume that is what project does? But
then one has to create an idl, not sure what that is ;\
Any info on how to do this stuff properly?
Unfortunately the project mentioned in that presentation seems to
be unavailable.
In order to work with COM objects from D you need to have
definitions of their interfaces translated to D. Initially they
are often described in IDL files (Interface Definition Language)
or TLB files (type library), and there are nice tools like
tlb2idl.exe and idl2d.exe that can convert them to .d files. You
can find them in the VisualD project tree. And if original
definitions are in C++, in many cases Ctrl-C-Ctrl-V is all you
need to convert to D. ;)
Then you may work with them directly or you might want a wrapper
that will call Release() for you when appropriate. I'm using a
wrapper like this:
https://gist.github.com/thedeemon/3c2989b76004fafe9aa0
Originally taken from VisualD source but then modified to my
needs.
For example, I need to use IAMVfwCompressDialogs interface from
Microsoft SDK. It's defined in axextend.idl file in the SDK and
looks like this:
[
object,
local,
uuid(D8D715A3-6E5E-11D0-B3F0-00AA003761C5),
pointer_default(unique)
]
interface IAMVfwCompressDialogs : IUnknown
{
// Bring up a dialog for this codec
HRESULT ShowDialog(
[in] int iDialog, // VfwCompressDialogs enum
[in] HWND hwnd
);
// Calls ICGetState and gives you the result
HRESULT GetState(
[out, size_is(*pcbState),
annotation("__out_bcount_part(*pcbState, *pcbState)")] LPVOID
pState,
[in, out, annotation("__inout")] int *pcbState
);
// Calls ICSetState
HRESULT SetState(
[in, size_is(cbState),
annotation("__in_bcount(cbState)")] LPVOID pState,
[in] int cbState
);
// Send a codec specific message
HRESULT SendDriverMessage(
[in] int uMsg,
[in] long dw1,
[in] long dw2
);
}
I use idl2d.exe and get following D code (minus some comments):
const GUID IID_IAMVfwCompressDialogs = IAMVfwCompressDialogs.iid;
interface IAMVfwCompressDialogs : IUnknown
{
static const GUID iid = { 0xD8D715A3,0x6E5E,0x11D0,[
0xB3,0xF0,0x00,0xAA,0x00,0x37,0x61,0xC5 ] };
// Bring up a dialog for this codec
HRESULT ShowDialog(
in int iDialog, // VfwCompressDialogs
enum
in HWND hwnd
);
// Calls ICGetState and gives you the result
HRESULT GetState(
LPVOID pState,
int *pcbState
);
// Calls ICSetState
HRESULT SetState(
in LPVOID pState,
in int cbState
);
// Send a codec specific message
HRESULT SendDriverMessage(
in int uMsg,
in int dw1,
in int dw2
);
}
Then in my D code I just write
enum { VfwCompressDialog_Config = 0x01,
VfwCompressDialog_About = 0x02 }
...
auto vfw = ComPtr!IAMVfwCompressDialogs(pg.vcodec);
if (vfw) vfw.ShowDialog(VfwCompressDialog_Config, hwnd);
where pg.vcodec is my variable of type ComPtr!IBaseFilter I
created earlier. Here the ComPtr wrapper uses internally
QueryInterface() to get pointer to desired interface, and when my
vfw variable goes out of scope, Release() will be called
automatically. Moreover, if ShowDialog here returns a bad value a
COMException will be generated automatically (this is my own
addition to ComPtr behavior).
To create some COM object in the first place, knowing its CLSID,
I do like this:
auto CLSID_NullRenderer =
Guid!("C1F400A4-3F08-11D3-9F0B-006008039E37"); //qedit.dll
auto pNullRendr = ComPtr!IBaseFilter(CLSID_NullRenderer,
"null renderer");
Here IBaseFilter is just some COM interface from Microsoft SDK I
need.
ComPtr constructor understands what to do depending on whether
it's given some GUID or a pointer to some object.
Moral of this story, if you have the COM interfaces defined in D,
you can have wrappers to do resource management, interface
querying and error checking automatically, but first you need to
translate (often using
Re: Memory Efficient HashSet
On Wednesday, 9 March 2016 at 22:31:50 UTC, Nordlöw wrote:
consumes 842.m MiB on my Ubuntu.
Here's mine:
https://bitbucket.org/infognition/robinhood/src
(you just need one file rbhash.d to use in your apps)
The following test takes ~130 MB and can take less with some
tweaks in the settings:
import std.stdio, rbhash;
alias Set(T) = RHHash!(T, void);
void main() {
auto set = new Set!uint;
foreach(i; 0..10_000_000)
set.add(i);
writeln(set.contains(444));
readln;
}
It's a GC-free Robin Hood hash table implementation with special
treatment for void as value type, i.e. sets.
Re: GC scan for pointers
On Wednesday, 9 March 2016 at 15:14:02 UTC, Gerald Jansen wrote:
I've studied [1] and [2] but don't understand everything there.
Hence these dumb questions:
Given
enum n = 100_000_000; // some big number
auto a = new ulong[](n);
auto b = new char[8][](n);
struct S { ulong x; char[8] y; }
auto c = new S[](n);
will the large memory blocks allocated for a, b and/or c
actually be scanned for pointers to GC-allocated memory during
a garbage collection? If so, why?
I've just tested it with my GC tracker (
https://bitbucket.org/infognition/dstuff ), all 3 allocations go
with flags APPENDABLE | NO_SCAN which means these blocks will not
be scanned.
But if you define S as
struct S { ulong x; char[] y; }
so there is some pointer inside, then it gets allocated with just
APPENDABLE flag, i.e. it will be scanned then.
Re: Use of GUID constants
On Thursday, 10 March 2016 at 15:48:14 UTC, Mike Parker wrote: Personally I would just declare one immutable value in module scope and be done with it. It really just doesn't matter. Unless you're following some sort of style guide, personal preference rules the day. I don't know if Rainers has a special reason for what he did with the Visual D code or if it was personal preference. There is one good reason for doing it VisualD way. It defines and uses smart pointers ComPtr(ISomething) where you can just write auto x = ComPtr!ISomeInterface(someObject); and if someObject has a different COM type this constructor will QueryInterface() for the proper interface, and to do this it needs to know its IID, so a common way to get IID knowing just an interface type is really helpful.
Re: Can DUB --combined builds be faster?
On Monday, 14 March 2016 at 11:50:38 UTC, Rene Zwanenburg wrote: When building in release mode the call to foo() gets inlined just fine without --combined. How does it work? Is it because the source of foo() is visible to the compiler when producing the result?
Re: Something wrong with GC
On Sunday, 20 March 2016 at 07:49:17 UTC, stunaep wrote: The gc throws invalid memory errors if I use Arrays from std.container. Those arrays are for RAII-style deterministic memory release, they shouldn't be freely mixed with GC-allocated things. What happens here is while initializing Array sees it got some GC-ed value type (strings), so it tells GC to look after those strings. When your program ends runtime does a GC cycle, finds your Test object, calls its destructor that calls Array destructor that tries to tell GC not to look at its data anymore. But during a GC cycle it's currently illegal to call such GC methods, so it throws an error. Moral of this story: try not to store "managed" (collected by GC) types in Array and/or try not to have Arrays inside "managed" objects. If Test was a struct instead of a class, it would work fine.
Re: Something wrong with GC
On Tuesday, 22 March 2016 at 13:46:41 UTC, stunaep wrote: So what am I do to? Just learn more about available containers and their semantics. Maybe you don't need Array!T when there is a simple T[]. If you think you do need Array, then think about memory management: where are you going to allocate the data - in the GC heap or outside it. Depending on your answers there are different approaches. It's all solvable if you pause and think what exactly you're trying to do.
Re: How do you use D to launch/open a window?
On Friday, 22 April 2016 at 21:13:31 UTC, anonymousuer wrote:
What code is needed to tell D to open a window? Thank you in
advance.
import dlangui;
mixin APP_ENTRY_POINT;
extern (C) int UIAppMain(string[] args) {
Window window = Platform.instance.createWindow("Window
caption", null);
window.mainWidget = parseML(q{
TextWidget {text: "hi!"}
});
window.show();
return Platform.instance.enterMessageLoop();
}
Re: DlangUI translations
On Saturday, 23 April 2016 at 15:44:22 UTC, stunaep wrote: I am wondering how to use other languages and how to NOT use other languages. Did you see example1 from examples folder in dlangui? It has two languages and allows switching at runtime via menu.
Re: Generation of AST for semantic rule checking
On Sunday, 22 May 2016 at 04:33:44 UTC, Chris Katko wrote: Basically, I want compile-time enforcement of semantic rules. So the question is: Is there a way to get LDC2 to generate AST or similar, and if not, any other way to go about this? I think one popular approach to the task is to use linters / static analysis tools before compiling, as a build step or separately. There is this project: https://github.com/Hackerpilot/Dscanner that uses a D parser to get AST and applies different semantic checks, you could use that as a base and just add your own checks and conditions.
Re: .array changes the order
On Thursday, 12 May 2016 at 10:17:19 UTC, xtreak wrote: Thanks a lot. Can you kindly elaborate a little more on File.byLine with an example of the scenario so that I don't get bitten by it. File.byLine.array works as expected for me. A little more explanation on the permutations will also be helpful since joiner.map!array converts the subranges to arrays, so does joiner work by mutating state if so how does it do. With some ranges the value they return by .front is only valid until the next call to popFront(). For example, File.byLine() reuses its buffer so after popFront() is called the buffer contains different data and if you had references to the contents of previously returned value they become invalid. This is why byLineCopy() was added. In the same vein permutations() returns a range that has a mutable array of indices inside, which changes every time popFront() is called, and since every value returned by its .front refers to that indices array, if you collect such permutations they will all use the same array of indices and show the same order of elements, the same permutation. Because of this mutable nature of some ranges it's important to understand in which order calls to .front and .popFront() happen. The array() function calls popFront on its input in a loop, consuming the mutable ranges, while map() does not. So in r.map!f.array function f will receive different valid values, before they get invalidated in the loop of array(). But if they contain references to something mutable, it makes sense to make copies before the thing they refer to mutates.
Re: DlangIDE Themes
On Wednesday, 11 May 2016 at 12:55:13 UTC, Chris wrote: Is there a way I can add my own themes? I've created a theme file and added it to views/resources.list However, it doesn't show up. "Default" and "Dark" seem to be hardwired somewhere in the source code. Indeed they are, just grep for "ide_theme_dark" and you'll find those two places (settings.d, idesettings.d).
Re: DlangIDE Themes
On Thursday, 12 May 2016 at 09:17:24 UTC, Chris wrote: They shouldn't be hardwired. Best would be to load them dynamically with their respective names encoded in the xml file. In this way people could add their own themes as they see fit. I wouldn't mind creating themes and adding them to DlangIDE as a humble contribution. Don't forget that contents of all those files in resources.list is also "hardwired" into the executable, so there's not much difference between mentioning something in such list file and in the source code. Of course, dynamic loading would be a nice thing to do, in addition to what there is now.
Re: .array changes the order
On Thursday, 12 May 2016 at 09:44:39 UTC, xtreak wrote: I came across the issue where using .array after .joiner caused the changes to the output. The program is at https://dpaste.dzfl.pl/0885ba2eddb4 . I tried to debug through the output but I couldn't get the exact issue. It will be helpful if someone confirms this as a bug. It's not a bug per se, just probably documentation being not clear enough. Essentially it's the same issue as with File.byLine: a range that mutates its state, so it's ok to consume lazily but if you just store references (as array() does) you get references to the same mutated value as result. Quick fix: r.chunks(2).map!permutations.joiner.map!array.array.writeln; i.e. copy each permutation to separate array before it's gone.
Re: Compiler or Interpreter or Hybrid
On Thursday, 21 April 2016 at 02:06:00 UTC, newB wrote: How is D implemented? (Compiler, Interpreter and Hybrid). Can you please explain why? Generally D is a compiled language: you give the compiler some source code and it produces executable binary with native machine code. Then you can distribute and run this binary without having to have any source code. However inside the compiler there is also an interpreter for most of D, it's used during the compilation to perform some compile-time computations and decisions, including ability to generate more D code that gets further interpreted or compiled.
Re: Hooking into GC
On Wednesday, 29 June 2016 at 02:18:27 UTC, MMJones wrote: I read somewhere that one can modify the D files from phobos and runtime to supply a stub for the GC. I would like to add some logging features to the GC. You don't need to recompile anything, a stub can be installed from your program. See an example (which can do logging) here: https://bitbucket.org/infognition/dstuff/src/97cef6d4a0438f9a9f4ff0d18f819262b8a74888/trackallocs.d?fileviewer=file-view-default
Re: Commit size and Page fault's very large for simple program
On Monday, 4 July 2016 at 11:56:14 UTC, Rene Zwanenburg wrote: On Monday, 4 July 2016 at 11:42:40 UTC, Rene Zwanenburg wrote: ... I forgot to mention: If you're on Windows compilation defaults to 32 bit, false pointers can be a problem with D's current GC in 32 bit applications. This isn't an issue for the sample application though, since you're not putting random numbers in the allocated arrays. It is an issue here. It doesn't matter what numbers are in the arrays, what matters is if some random values on stack look like pointers pointing inside those arrays, which often happens with large arrays. Essentially it means in 32 bits we shouldn't GC-allocate anything larger than a few KBs, the larger the thing you allocate the more chances are it won't be collected due to false pointers on the stack and other data.
Re: GC question
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote: - Automatic but conservative. Can leak at any time. You have to implement manual management (managed heaps) to avoid leaks. Leaks are hard to find as any heap value may be causing it. By "managed heap" I just meant the GC heap, the one used by "new" operator. Besides it, there are already other allocators and container libraries available, don't need to implement this stuff manually. the worst of both worlds. It may look so from a distance. But in my experience it's not that bad. In most software I did in D it did not matter really (it's either 64-bit or short lived programs) and the control D gives to choose how to deal with everything makes it all quite manageable, I can decide what to take from both worlds and hence pick the best, not the worst.
Re: GC question
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC rather than a precise one, I've never worked with a conservative GC before. Are there any disallowed memory operations? Can I break things by not following some unchecked rules etc. ? How often does it leak? Do I need to be careful with some operations to avoid leaks? Here's some practical perspective from someone who released a 32-bit video processing app in D with thousands of users. When developing with GC in D you need to keep in mind 3 key things: 1) The GC will treat some random stack data as possible pointers, and some of those false pointers will accidentally point to some places in the heap, so for any object in GC heap there is a probability that GC will think it's alive (used) even when it's not, and this probability is directly proportional to the size of your object. 2) Each GC iteration scans the whole GC heap, so the larger your managed heap, the slower it gets. Main consequence of 1 and 2: don't store large objects (images, big file chunks etc.) in the GC heap, use other allocators for them. Leave GC heap just for the small litter. This way you practically don't leak and keep GC pauses short. 3) GC will call destructors (aka finalizers) for the objects that have them, and during the GC phase no allocations are allowed. Also, since you don't know in which order objects are collected, accessing other objects from a destructor is a bad idea, those objects might be collected already. Main consequence of 3: don't do silly things in destructor (like throwing exceptions or doing other operations that might allocate), try avoiding using the destructors at all, if possible. They may be used to ensure you release your resources, but don't make it the primary and only way to release them, since some objects might leak and their destructors won't be called at all. If you follow these principles, your app will be fine, it's not hard really.
Re: Serializer class
On Wednesday, 22 February 2017 at 18:34:26 UTC, houdoux09 wrote:
void Read(T)(T value)
{
foreach(i, mm; value.tupleof)
{
writeln(__traits(identifier, value.tupleof[i]), " = ",
mm);
if(isArray!(typeof(mm)))
{
Read(mm[0]); //Error
}
}
}
You need to use "static if" here inside foreach. Otherwise the
body of your "if" gets compiled for all the different fields of
"value" and of course fails for the fields that are not arrays.
Re: Thread will get garbage collected?
On Monday, 16 January 2017 at 22:08:56 UTC, JN wrote: Am I correctly understanding, that after going out of scope, it's possible for GC to destroy my thread before the file finishes loading? How to prevent GC from destroying my thread before it finishes and make sure the file is loaded completely? As far as I know, GC never kills threads.
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. I don't think there is anything dominant, different people tend to make different choices. 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).
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: D code optimization
On Thursday, 22 September 2016 at 16:09:49 UTC, Sandu wrote: const int n = 252; double[] call = new double[n+1]; ... //delete call; // since D is has a garbage collector, explicit deallocation of arrays is not necessary. If you care about speed, better uncomment that `delete`. Without delete, when allocating this array 1 times you'll trigger GC multiple times without good reason to do so. With delete, the same memory shall be reused and no GC triggered, run time should be much better.
Re: how to debug memory errors
On Monday, 7 November 2016 at 02:22:35 UTC, Steven Schveighoffer wrote: OP: it's not legal to destroy or even access GC allocated members in a destructor. The GC may have already destroyed that data. Isn't destroy() fine there? It doesn't call destructors for already destroyed objects, so I guess it should be safe. (assuming the destructors don't do any allocations)
Re: how to debug memory errors
On Tuesday, 8 November 2016 at 05:36:22 UTC, Era Scarecrow wrote: Hmmm.. I had the impression that if something was referenced by another object, then it couldn't be collected, Another *live* object, i.e. reachable from globals and stack. If you have a big tree and it becomes unreachable (you only had a pointer to its root and you nulled it), then this whole tree becomes garbage, and its nodes and leafs will be collected in unpredictable order, with destructors being run in unpredictable order, even when these dead nodes reference each other.
Re: Memory allocation failed. Why?
On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote: core.exception.OutOfMemoryError@src\core\exception.d(693): Memory allocation failed Simple program and error. Why? Windows 7 (32) dmd 2.072.0 Making a 100 million bytes array by appending one byte at a time creates a lot of intermediate-size arrays. Ideally these should be garbage collected away but GC in D is not only slow but also leaky. In 32 bits if you have 1000 random int values on the stack or data segment, with uniform distribution, this is 1000 random locations in memory pinned and seen by GC as live, i.e. one per 4 MB of address space. Which means if your array is 4 MB or larger it's almost doomed to be never collected by GC in this scenario. Your program creates a lot of large arrays and they don't get collected because of false pointers and not precise enough GC. Moral of the story: in 32 bits don't allocate anything big (1 MB or more) in GC heap, otherwise there are good chances it will create a memory leak. Use std.container.array or something similar.
Re: Auto recursive function
On Wednesday, 11 January 2017 at 19:23:10 UTC, Razvan Nitu wrote:
Hi,
I am currently trying to create a function
makeMultidimensionalArray which allocates memory for a
multidimensional array.
You were very close to the answer:
auto makeMultidimensionalArray(int N, T, Allocator)(auto ref
Allocator alloc, size_t[N] lengths)
{
static if (lengths.length == 1)
{
return makeArray!T(alloc, lengths[0]);
}
else
{
alias E = typeof(makeMultidimensionalArray!(N-1,T)(alloc,
lengths[1..$]));
auto ret = makeArray!E(alloc, lengths[0]);
foreach (ref e; ret)
e = makeMultidimensionalArray!(N-1, T)(alloc,
lengths[1..$]);
return ret;
}
}
The key point is that return type depends on length of "lengths"
array (dimensionality), so if this length is only known at
runtime this is a dependent type, something D lacks (you'll need
Idris or Agda for those). In D return type must be known at
compile time and hence the length of "lengths" must be a compile
time argument. With such argument everything compiles smoothly.
Re: writeln and ~
On Saturday, 14 January 2017 at 17:42:05 UTC, Ignacious wrote: writeln(x ~ " ok"); Just write writeln(x, " ok"); Any number of arguments, no unnecessary allocations. Do you really need ~?
Re: Impressed with Appender - Is there design/implementation description?
On Sunday, 4 December 2016 at 20:03:37 UTC, Jon Degenhardt wrote: I've been using Appender quite a bit recently, typically when I need append-only arrays with variable and unknown final sizes. I had been prepared to write a custom data structure when I started using it with large amounts of data, but very nicely this has not surfaced as a need. Appender has held up quite well. I haven't actually benchmarked it against competing data structures, nor have I studied the implementation. I'd be very interested in understanding the design and how it compares to other data structures. Are there any write-ups or articles describing it? --Jon It's rather simple, just take a look at its source code in std.array. It's an ordinary linear array partially filled with your data. When your data fills it up, it gets resized to make more space. Just two interesting points: 1. When it needs to grow it uses a formula like k = 1 + 10 / log2(newsize) for the growth factor (but with a limit of k <= 2), which means up to 16 KB it doubles the size each time, then tries to grow by a factor of 2/3, then by lower and lower factors. 2. Up until 4 KB it reallocates when growing, but after 4 KB the array lives in a larger pool of memory where it can often grow a lot without reallocating, so in many scenarios where other allocations do not interfere, the data array of appender grows in place without copying any data, thanks to GC.extend() method.
