Re: Matrix-type-friendly syntax and more
Suddenly, I had a talk with an Fortran guy at previous weekend and have wrote something like Fortran arrays in D last week. I had an idea of adding it into Phobos, but just had no time for review of my code. Draft version is in attachment. rarray.d - something like Fortran array main.d - example of using rarray module output.txt - main.d output My usable draft example of multidimensional rectangular arrays (source looks working stable and usable but still isn't ready): http://deoma-cmd.ru/d/docs/src/my/rarray.html Posted now just for illustrating existed syntax abilities. IMHO, it is not too bad: adding `R[]` isn't a big overhead.
Re: D-thrift package detects regressions since 2.061, where is the regression suite located?
13.08.2013 21:49, glycerine пишет: Grrr... Apparently nobody has been testing the D - Apache Thrift bindings since 2.061, and dmd has since accumulated multiple regressions that affect the correctness of the Thrift implementation. I emailed with David N. and he said that this was quite common for each release of dmd, and that while he used to religously evaluate each new dmd release on the Thrift bindings, he had simply not had the time for more recent recents to test each thoroughly. Serialization: this is fundamental. This really isn't the kind of thing that should ever be allowed to break. Hence it really isn't something that should be tested manually. It should be an automatic part of the automatic regression detection test suite. Where is the regression suite for D located, and how can I add to it? There used to be github issue tracking, but I don't see it any more... is it hiding under their new interface perhaps...? Thanks. - glycerine By the way, the ability to add costume projects to D autotester is already proposed without any response: http://forum.dlang.org/thread/kqm4ta$m7f$1...@digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: D2 is really that stable as it is claimed to be?
21.09.2013 21:41, Zhouxuan пишет: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. Should I continue? Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. A year or two ago it was a lot of wrong-code bugs with lambdas and nested functions making e.g. `std.algorithm` almost unusable. But it's only the beginning. OPTLINK bug causing random linking failures thus making the whole language unusable for real projects was fixed only about half a year ago. And all this time I liked D except "the language is stable" words. And when half a year ago D become fully usable I become happy. For me "enough stability" is an ability to grab my copy of tool-chain and work with it without random failures. Since then I had not any real problems with breaking changes or regressions. Generally regressions are fixed quickly and as for me the more breaking changes the better language we get. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Bug 6186
02.10.2013 23:03, Benjamin Thaut пишет: Am 02.10.2013 20:56, schrieb H. S. Teoh: On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: Well thats the problem with volenteer work. People usually pick something they interrested in. (Kenji beeing an exception to this rule) The most annoying struct lifetime bug for me is the following: http://d.puremagic.com/issues/show_bug.cgi?id=8360 So Kenji rapidly (as often) did https://github.com/D-Programming-Language/dmd/pull/2620 Let's be astonished by his response time! -- Денис В. Шеломовский Denis V. Shelomovskij
What endiannesses do D support?
Some of druntime/phobos code assumes it is one of little/big endianness others have `static assert(0)` for third case. Lets clear the situation and make a decision. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What endiannesses do D support?
04.10.2013 15:00, Alex Rønne Petersen пишет: On Friday, 4 October 2013 at 10:59:05 UTC, Denis Shelomovskij wrote: Some of druntime/phobos code assumes it is one of little/big endianness others have `static assert(0)` for third case. Lets clear the situation and make a decision. Little endian and big endian must be supported. Little endian PowerPC, for example, is extremely rare (if not entirely extinct), so just supporting little endian is not enough. Of course. The question is about "a third case". -- Денис В. Шеломовский Denis V. Shelomovskij
Re: My thoughts & experiences with D so far, as a novice D coder
28.03.2013 0:28, Andrei Alexandrescu пишет: On 3/27/13 3:18 PM, H. S. Teoh wrote: Which is what Denis' multidimensional array implementation does. As does my implementation as well. This seems to be quite a common use-case; we should put this into Phobos IMO. Agree. Do you (or Denis) have something in reviewable form? Andrei No. The module is 2 years old and I only made changes on dmd requests. But if such functionality is really needed I will be happy to revise API and prepare my implementation for review. P.S. It's an accident I have seen this post. I think in the case of such questions it is obligatory to e-mail the author or there is a big risk the question will bot be delivered. -- Денис В. Шеломовский Denis V. Shelomovskij
Rectangular multidimensional arrays for D
I accidentally discovered Andrei wrote [1] multidimensional array implementation is needed. If it really is, I will work to revise the API and prepare my implementation [2] for review if nobody is doing it already. Also as Kenji's "multidimensional indexing and slicing" pull [3] still not merged the only way is to use hacks like this: --- // first two rows and three columns of the second matrix array2d = matrices[1, R[0 .. 2], R[0 .. 3]]; --- [1] http://forum.dlang.org/post/kivkp0$csp$1...@digitalmars.com [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimensionalarray.html [3] https://github.com/D-Programming-Language/dmd/pull/443 --- Previous related topics --- At least the ones I participated in: * October 09, 2011: Kenji Hara proposes "Matrix-type-friendly syntax and more". His dmd pull #443 still isn't merged. http://forum.dlang.org/thread/j6sp68$2a7k$1...@digitalmars.com https://github.com/D-Programming-Language/dmd/pull/443 * October 25, 2011: Original "Multidimensional arrays for D" post. No response from Phobos developers. http://forum.dlang.org/thread/j864es$2gi0$1...@digitalmars.com * June 17, 2012: A request for "template that can simulate a rectangular array". http://forum.dlang.org/thread * June 30, 2012: A request for "fixed size multidimensional array at runtime". http://forum.dlang.org/thread/ldjzfqvnjltbbiovq...@forum.dlang.org -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Rectangular multidimensional arrays for D
09.10.2013 7:55, Nick B пишет: On Tuesday, 8 October 2013 at 17:26:46 UTC, Stefan Frijters wrote: andrei wrote: I too are interesteed in this area as well. Dennis do you only plan to focus on multidimensional arrays only, or will you incorporate the above matrices as well ?? What features are you proposing ? I propose stuff for "multidimensional arrays only" as you noted. And I plan just to revise my existing API [1] without cardinal changes. I.e. all I propose is rectangular multidimensional arrays slicing and iterating. For matrix and math specific tasks see DScience [2] and SciD [3]. The latter started as a fork of DScience but became a separate project and is in development. See its wiki [4]. Also such math oriented libraries have to be partially (and the are) wrapper around LAPACK. Also it will be interest to see features you (Stefan and Nick) need e.g. as examples of code you want to compile with comments if needed. Write down at least basic features for now. [1] http://denis-sh.bitbucket.org/unstandard/unstd.multidimensionalarray.html [2] https://github.com/dscience-developers/dscience [3] https://github.com/kyllingstad/scid [4] https://github.com/kyllingstad/scid/wiki -- Денис В. Шеломовский Denis V. Shelomovskij
[Proposal] Weak reference implementation for D
--- Proposal --- The proposal is to add weak reference functionality based on `unstd.memory.weakref`. It can be placed e.g. in `core.memory`. Source code: https://bitbucket.org/denis-sh/unstandard/src/HEAD/unstd/memory/weakref.d Documentation: http://denis-sh.bitbucket.org/unstandard/unstd.memory.weakref.html Enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4151 --- Reasons --- Reasons, why we do need weak reference functionality in D (Issue 4151 [1]): 1. It has a general use. I suppose no question here. 2. It's hard to implement correctly. As a proof here are incorrect implementations written by experienced developers: * Weak reference functionality in `std.signal` implementation: https://github.com/D-Programming-Language/phobos/blob/7134b603f8c9a2e9124247ff250c9b48ea697998/std/signals.d * Alex's one from MCI: https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d * Robert's one from his new `std.signals` implementation proposal: https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d * My implementation (fixed now, I hope): https://bitbucket.org/denis-sh/unstandard/src/cb9a835a9ff5/unstd/memory/weakref.d Everybody can check his knowledge of concurrent programming and D GC by trying to understand what exactly every implementation does and where are race conditions. It's recommended to read implementations in the order provided here going to the next one as soon as you see why previous one is incorrect. For now the only [probably] fixed implementation is mine so one can see spoiler here: https://bitbucket.org/denis-sh/unstandard/history-node/HEAD/unstd/memory/weakref.d (the first and the most fixing (spoiling you joy to understand everything yourself) commit is 6f59b33) 3. It's hard to create a good API design for it. No jokes. E.g. there are two different behaviours of .NET weak references and even more in Java library. 4. It is needed for correct signals implementation in D. The lack of correct signals implementation is one of [major?] disadvantages of D. Bug report: http://d.puremagic.com/issues/show_bug.cgi?id=9606 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 12:55, Sönke Ludwig пишет: Am 13.10.2013 09:47, schrieb Denis Shelomovskij: Just to reassure, the following race-condition doesn't exist, right? It looks like "GC.addRoot()" makes guarantees by taking the GC lock or something similar? time -> thread1: GC collection | | run finalizer | thread2: paused| lock weak ref | | access object All public GC API uses same mutex. So right, no races here. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 12:36, Benjamin Thaut пишет: Will rt_attachDisposeEvent also work with std.allocator? Or does it rely on the GC running? What exactly do you mean? `rt_attachDisposeEvent` adds delegate to `object.__monitor.devt` array which is called from `rt_finalize2 -> _d_monitordelete -> _d_monitor_devt`. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 22:19, Walter Bright пишет: On 10/13/2013 12:47 AM, Denis Shelomovskij wrote: --- Proposal --- Please post as a DIP: http://wiki.dlang.org/DIPs The trouble with it as a n.g. posting is they tend to scroll off and be forgotten. Why? There is already enhancement request 4151 to no forget and review queue to add it into. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
13.10.2013 21:36, Robert пишет: * Robert's one from his new `std.signals` implementation proposal: https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d Obviously I don't see it, otherwise I would have fixed it. Maybe you could elaborate a bit on your claim? Your implementation uses an entirely different technique for hiding the reference so a direct comparison is quite hard. 1. Have you read `gc.gc.fullcollect`, I mean a general function structure, not every line? If not, read it or you have no idea how collection performs. 2. I'm surprised you do think your implementation is correct as calling code twice (`foreach(i; 0..2)`) is an obvious hack to decrease a variety of undesired threads execution order (as it have to execute in this order twice). - Explanation - 1. Race condition In every moment GC thread can be paused in state it already marked all dead blocks and ready to collect. So before `GC.addrOf` (which will have to wait for the end of the collection as it uses same mutex) call it can collect your object (the object can be on stack or whatever, doesn't matter). Also an new object can be created occupying the same memory and `GC.addrOf` will return non-null. 2. Incorrect assumption `o = GC.addrOf(tmp.address)` is just incorrect as you assume the object is placed at the base address of its memory block which is not guaranteed. Yes, it may be true for now (I haven't read GC sources enough to be definite here) in general case but what about some e.g. tricky user defined class instance sequences which user may create? Yes, never heard about it and just invented it, but it doesn't make this or similar case impossible. Also it's rather bad to do any needless assumption about internal stuff. - P.S. - I have to say you have a big problem especially for a programmer: you think you are competent in area you aren't and it can play a trick on you later. Please don't be angry with me, we all like to think so but we all have to look at ourselves as critically as possible to prevent problems in future. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
14.10.2013 13:04, robert пишет: Why would I be angry with a stranger who insults me in public? I don't understand your concerns. No insults assumed! Just ugly truth about all of us. ) If you are more experienced in this area I am glad if you share your insights and Walter and Andrei often do silly mistakes. Can we suppose we are more experienced than they? Of course no, they just don't have enough time to think and check. Here the situation can be the same. I probably just have enough time to investigate the problem and solve it. if you think something is wrong, I am glad to discuss it and fix it if you are right, but just saying your implementation is wrong, does not really help. It implies that you are obviously right and everyone who does not see this is obviously a moron, if someone has a bit of a problem with his ego, I don't think it is me. Easy, man. I have never met morons here, except, probably, myself. Concurrent programming is fun so I just don't want to spoil the pleasure of investigation. And yes, I'm also lazy. ) Now about your code. First, I was completely incorrect about it, sorry for that. My mistake. I didn't even think the code containing such loop can be "so much correct". But, and this is the second, the code can't be "more or less" correct. It is either correct or not correct. It remembers me our (Russian) recent Moscow mayoral elections when we tried to change something in our country (we failed, yes) and after government won officials said: "It was the most honest elections of all preceding." ) So you code is incorrect and lets show it. When you give your code for eating to the compiler, it can does whatever it want but guarantee your program will work as you have written it (except special cases like copy construction elimination) and it doesn't assume every variable can be accessed from other threads. E.g. here is you code with unwinded loop in SSA (static single assignment) form: ``` auto tmp1 = atomicLoad(_obj); void* o1 = tmp1.address; if(o1 is null) return null; void* o2 = GC.addrOf(tmp1.address); auto tmp2 = atomicLoad(_obj); void* o3 = tmp2.address; if(o3 is null) return null; void* o4 = GC.addrOf(tmp2.address); if(o4) return cast(Object) o4; return null; ``` `o1` is only used once and `o2` is never used so the compiler is free to discard the former and ignore the latter. So your code equals to this code: ``` auto tmp1 = atomicLoad(_obj); if(tmp1.address is null) return null; GC.addrOf(tmp1.address); auto tmp2 = atomicLoad(_obj); if(tmp2.address is null) return null; void* o4 = GC.addrOf(tmp2.address); if(o4) return cast(Object) o4; return null; ``` So the second iteration gives nothing except decreasing (squaring to be precise) a variety of undesired threads execution order. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
14.10.2013 17:42, robert пишет: Damn it, you are right I did not think this through, somehow thought the use in addrOf is enough, which is of course crap. Thank's a lot for your time, I'll fix this ASAP. So, here are your revised version: https://github.com/phobos-x/phobosx/blob/1f0016c84c2043da0b9d2dafe65f54fcf6b6b8fa/source/phobosx/signal.d Sorry, but you are making the same mistake again. Lets start from the hardware. Just like a compiler CPU is free to do whatever it wants with passed instructions but guarantee result state will be the same as if it is executed sequentially. And it doesn't assume access from other threads by default (see e.g. "out-of-order execution"). So memory barriers (memory fences) are needed to ensure loads/stores before the barrier are performed and no loads/stores after the barrier are executing. This is what `core.atomic.atomicFence` does and it can be used in e.g. in mutex implementations. As your operations with `_obj` are already atomic no `atomicFence` call is needed. Now let's assume without loss of generality `InvisibleAddress.address` returns `cast(void*) ~_addr`, inline the `address` call, and remove redundant `atomicFence` call: ``` auto tmp = atomicLoad(_obj); auto o = cast(void*) ~tmp._addr; if(o is null) return null; GC.addrOf(o); auto tmp1 = atomicLoad(_obj); if(o is cast(void*) ~tmp1._addr) return cast(Object) o; assert(cast(void*) ~tmp1._addr is null); return null; ``` As I mentioned above you are making the same incorrect assumption that you know what machine instructions a compiler will generate. Never make such assumptions. Here is an example of how your code can be rewritten by a compiler: ``` auto tmp = atomicLoad(_obj); if(tmp._addr == -1) return null; GC.addrOf(cast(void*) ~tmp._addr); auto tmp1 = atomicLoad(_obj); if(tmp._addr == tmp1._addr) return cast(Object) cast(void*) ~tmp._addr; assert(tmp1._addr == -1); return null; ``` -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
16.10.2013 3:20, Sean Kelly пишет: On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote: The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems. Gotcha. Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive. Why not work on a DIP to get them built in? For example, one option might be to have the GC perform certain types of finalization while the world is stopped. This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime. But someone have to do it. And I can only see it will save one of two GC lock/unlock pairs. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
16.10.2013 3:20, Sean Kelly пишет: On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote: The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems. Gotcha. Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive. Why not work on a DIP to get them built in? For example, one option might be to have the GC perform certain types of finalization while the world is stopped. This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime. What about this: https://github.com/D-Programming-Language/druntime/pull/639 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Weak reference implementation for D
17.10.2013 12:09, Martin Nowak пишет: On 10/13/2013 09:47 AM, Denis Shelomovskij wrote: * Alex's one from MCI: https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d I remember talking about this with Alex. He wanted to add some functions to the GC and this is what I came up with based on the current implementation. It uses the synchronized GC.addrOf to check whether the loaded pointer is still valid. Still looks correctly synchronized to me. https://gist.github.com/dawgfoto/2852438 In fact the load!(msync.acq) could be made load!(msync.raw) too. The only thing we need from `GC.addrOf` here is a "GC barrier" i.e. `lock`/`unlock` pair so runtime changes are necessary for performance. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: add -allinst compiler switch
18.10.2013 11:17, Walter Bright пишет: Explained here: http://d.puremagic.com/issues/show_bug.cgi?id=11284 It's a bit complicated, and important. BTW, I hate the name of the switch, but haven't thought of anything better. Links to user complains are needed or the issue sounds not evident. E.g. the only issues with dmd object generation change after dmd pull #2550 [1] I have seen are compiler bugs when it incorrectly detects instantiating module (e.g. issues 11069 [2] and 4 [3]). Also personally I against supporting incorrect user actions just because it was supported before just like we do every release with fixing "accept-invalid" bugs. [1] https://github.com/D-Programming-Language/dmd/pull/2550 [2] http://d.puremagic.com/issues/show_bug.cgi?id=11069 [3] http://d.puremagic.com/issues/show_bug.cgi?id=4 -- Денис В. Шеломовский Denis V. Shelomovskij
Petition to chime in Issue 1553 - foreach_reverse is allowed for delegates
`foreach_reverse` is allowed for delegates and do what `foreach` do thus causing dangerous confusion. Walter Bright is the only one for some obscure reason definitely for not deprecating this feature and WONTFIX-ed the issue. And yes, no big red note in docs about it. As always, this is even more error-prone for highly templated language like D (i.e. one can expect in template `foreach_reverse` will not compile if reverse iteration isn't supported). Petition for all not indifferent to language misfeatures to chime in and show in this thread we all are for deprecating it (if we really are). Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=1553 Thanks. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Petition to chime in Issue 1553 - foreach_reverse is allowed for delegates
20.10.2013 15:29, Denis Shelomovskij пишет: `foreach_reverse` is allowed for delegates and do what `foreach` do thus causing dangerous confusion. Walter Bright is the only one for some obscure reason definitely for not deprecating this feature and WONTFIX-ed the issue. And yes, no big red note in docs about it. As always, this is even more error-prone for highly templated language like D (i.e. one can expect in template `foreach_reverse` will not compile if reverse iteration isn't supported). Petition for all not indifferent to language misfeatures to chime in and show in this thread we all are for deprecating it (if we really are). Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=1553 Thanks. Also the funny thing is according to Andrei [1] about `foreach_reverse` over ranges from February 2010: "Gone, that is. Walter agreed to remove it." [1] http://forum.dlang.org/post/hl8345$2b1q$1...@digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
20.10.2013 18:25, bearophile пишет: More discussions about variable-sized stack-allocated arrays in C++, it seems there is no yet a consensus: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf I'd like variable-sized stack-allocated arrays in D. I'd say the most common case one need a stack-allocated array is a temporary allocation which isn't going to survive end of scope. Even more in such cases for too large for stack data one want to allocate from thread local heap instead of shared one to prevent needless locking. `unstd.memory.allocation.tempAlloc` [1] will do the job. As the one of the most common subcases is a temporary C string creation `unstd.c.string.tempCString` will help here. [1] http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc [2] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html#tempCString -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
21.10.2013 14:30, Manu пишет: System interface functions that pass zero-terminated strings through to the OS are the primary offender, needless garbage, those should be on the stack. I like to use alloca too where it's appropriate. I'd definitely like if D had a variable-sized static array syntax for pretty-ing alloca. I thought about something similar using alloca via a mixin template, but that feels really hackey! No hacks needed. See `unstd.c.string` module from previous post: http://forum.dlang.org/thread/lqdktyndevxfcewgt...@forum.dlang.org?page=2#post-l42evp:241ok7:241:40digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
21.10.2013 18:04, dennis luehring пишет: "...Implementation note: For small strings tempCString will use stack allocated buffer, for large strings (approximately 1000 characters and more) it will allocate temporary one from unstd.memory.allocation.threadHeap..." does that mean that tempCString reserves minimum 1000 bytes on stack else using heap? if so i would prefer a template based version where i can put in the size Yes, `tempCString` allocates `1024 * To.sizeof` bytes on the stack. Note that it doesn't initialize the data so it is O(1) operation which will just do ~1 KiB move of stack pointer. As function stack frame can easily eat 50-100 bytes it is like 10-20 function calls. IIRC typical stack size is ~1 MiB and `tempCString` isn't expected to be used in some deep recursion or be ~1000 times used in one function. So I'd prefer to change default stack allocation size if needed and not confuse user with manual choice. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: More on C++ stack arrays
23.10.2013 1:05, Lionello Lunesu пишет: Careful! Alloca doesn't get cleaned up when used in loops! And I don't use `alloca`. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Tristate - wanna?
27.10.2013 4:08, Timon Gehr пишет: On 10/26/2013 05:42 PM, Andrei Alexandrescu wrote: While messing with std.allocator I explored the type below. I ended up not using it, but was surprised that implementing it was quite nontrivial. Should we add it to stdlib? Theory: http://en.wikipedia.org/wiki/Three-state_logic "The term tri-state[1] should not be confused with ternary logic (3-value logic)." So this thread is about a three-valued logic with same truth tables as in Kleene's and Priest's logics. See: * http://en.wikipedia.org/wiki/Many-valued_logic * http://en.wikipedia.org/wiki/Three-valued_logic -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Expanding the horizons of D purity
01.11.2013 0:05, H. S. Teoh пишет: [I actually came up with this idea last week, but decided to postpone bringing it up until all the furor about Andrei's new allocator design has settled a little. ;-)] One of the neatest things about purity in D is that traditionally impure operations like mutation and assignment can be allowed inside a pure function, as long as the effect is invisible to the outside world. This, of course, describes strong purity. Weak purity takes it one step further, by allowing mutation of outside state via references to mutable data passed in as function arguments. I'd like to propose extending the scope of weak purity one step further: allow weakly-pure functions to call (not necessarily pure) delegates passed as a parameter. That is, the following code should work: // N.B. This is a (weakly) pure function. void func(scope void delegate(int) dg) pure { // N.B. This calls an *impure* delegate. dg(1); } Before you break out the pitchforks, please allow me to rationalize this situation. The above code is essentially equivalent to: void func(void *context, scope void function(void*,int) dg) pure { dg(context, 1); } That is to say, passing in a delegate is essentially equivalent to passing in a mutable reference to some outside state (the delegate's context), and a pointer to a function that possibly mutates the outside world through that context pointer. In a sense, this is not that much different from a weakly pure function that directly modifies the outside world via the context pointer. But, I hear you cry, if func calls an *impure function* via a function pointer, doesn't that already violate purity??! Well, it certainly violates *strong* purity, no question about that. But consider this code: int stronglyPure(int x) pure { int[] scratchpad; scratchpad.length = 2; // This is an impure delegate because it closes over // scratchpad. auto dg = (int x) { scratchpad[x]++; }; // Should this work? func(dg); return scratchpad[1]; } Think about it. What func does via dg can only ever affect a variable local to stronglyPure(). It's actually impossible for stronglyPure() to construct a delegate that modifies a global variable, because the compiler will complain that referencing a global is not allowed inside a pure function (verified on git HEAD). Any delegate that stronglyPure() can construct, can only ever affect its local state. The only way you could sneak an impure delegate into func() is if stronglyPure() itself takes an impure delegate as parameter -- but if it does so, then it is no longer strongly pure. IOW, if stronglyPure() is truly strongly pure, then it is actually impossible for the call to func() to have any effect outside of stronglyPure()'s local scope, no matter what kind of delegate stronglyPure() passes to func(). So such a call should be permitted! Now let's consider the case where we pass a delegate to func() that *does* modify global state: int global_state; void main() { func((int x) { global_state = x; }); } In this case, func being marked pure doesn't really cause any issues: main() itself is already impure because it is constructing a delegate that closes over a global variable, so the fact that the actual change comes from calling func no longer matters. It's always OK for impure code to call pure code, after all. It's no different from this: void weaklyPure(int* x) pure { *x = 1; // OK } int global_state; void main() { weaklyPure(&global_state); } That is to say, as long as the code that calls func() is marked pure, then the behaviour of func() is guaranteed never to affect anything outside the local scope of the caller (and whatever the caller can reach via mutable reference parameters). That is, it is (at least) weakly pure. If the caller is strongly pure (no mutable indirections in parameters -- and this includes delegates), then func() is guaranteed to never cause side-effects outside its caller. Therefore, it should be permissible to mark func() as pure. // Why is this important? Well, ultimately the motivation for pushing the envelope in this direction is due to functions of this sort: void toString(scope void delegate(const(char)[]) dg) { dg(...); } By allowing this function to be marked pure, we permit it to be called from pure code (which I proved in the above discussion as actually pure). Or, put another way, we permit template functions that call toString with a delegate that updates a local variable to be inferred as pure. This allows more parts of std.format to be pure, which in turn expands the usability of things like std.conv.to
Re: Expanding the horizons of D purity
01.11.2013 21:12, H. S. Teoh пишет: On Fri, Nov 01, 2013 at 08:59:29PM +0400, Denis Shelomovskij wrote: 01.11.2013 0:05, H. S. Teoh пишет: [...] So, in a nutshell, my proposal is: - Functions that, besides invoking a delegate parameter, are pure, should be allowed to be marked as pure. - Template functions that, besides invoking a delegate parameter, perform no impure operations should be inferred as pure. - A function that takes a delegate parameter cannot be strongly pure (but can be weakly pure), unless the delegate itself is pure. (Rationale: the delegate parameter potentially involves arbitrary references to the outside world, and thus cannot be strongly pure.) T The code you like to make working looks good but I'm against the language change. I'd say the issue is nested pure functions aren't allowed to access outer function variables. Filed as Issue 11412. [...] No, that's not good enough. What if you need to pass an impure delegate to toString()? Sure, std.format can be made to use only pure delegates, but you can't predict other code that needs to use toString. Forcing toString to take only pure delegates makes it unusable with output ranges that need to perform impure operations. With my proposal, toString will work with *both* pure and impure delegates -- basically, the pure qualifier becomes a dependent purity ("purity of this function depends on the delegate parameter, body of function is pure besides the invocation of the delegate"). T I'd say `@safe`, `pure`, and `nothrow` are in the same boat here and the solution should work for them all. Probably we will need a delegate attributes wildcard. Something like this: --- // a single wildcard for all: void f(void delegate() @attr_wildcard del) @attr_wildcard; --- or better: --- // `f` is `@safe`, it also `pure` and `nothrow` if `del` is: void f(void delegate() @safe pure? nothrow? del) @safe pure? nothrow?; --- Also, do you disagree with the proposal in Issue 11412 [1]? [1] http://d.puremagic.com/issues/show_bug.cgi?id=11412 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Copy elision by spec
04.11.2013 11:02, Lars T. Kyllingstad пишет: My question is therefore, is this by design? Can I rely on this to work in the future, and on all compilers? If this is the case, it really should be added to the spec. This is Issue 10372 [1]. [1] https://d.puremagic.com/issues/show_bug.cgi?id=10372 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Expanding the horizons of D purity
01.11.2013 0:05, H. S. Teoh пишет: I'd like to propose extending the scope of weak purity one step further: allow weakly-pure functions to call (not necessarily pure) delegates passed as a parameter. Unacceptable. It will break strongly purity. Your mistake is strongly pure function can easily get an impure delegate: --- int i; struct S { void g() { ++i; } } void impureCaller(scope void delegate() del) pure { del(); } void f() pure // strongly pure, will modify `i` { S s; impureCaller(&s.g); } --- So issues 11469 [1] & 11412 [2] are the only way I see to solve our problems. [1] http://d.puremagic.com/issues/show_bug.cgi?id=11469 [2] http://d.puremagic.com/issues/show_bug.cgi?id=11412 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Expanding the horizons of D purity
07.11.2013 21:41, H. S. Teoh пишет: On Thu, Nov 07, 2013 at 09:22:47PM +0400, Denis Shelomovskij wrote: 01.11.2013 0:05, H. S. Teoh пишет: I'd like to propose extending the scope of weak purity one step further: allow weakly-pure functions to call (not necessarily pure) delegates passed as a parameter. Unacceptable. It will break strongly purity. Your mistake is strongly pure function can easily get an impure delegate: [...] It will not. My proposal only applies to weakly pure functions. Strongly pure functions cannot call impure delegates because you cannot guarantee anything about what the delegate will do. So basically, once a pure function takes a non-pure delegate parameter, it is no longer strongly pure, only weakly pure. (I stated this at the end of my post where strongly pure functions are not allowed to call impure delegates.) T Let me repeat my code again: --- int i; struct S { void g() { ++i; } } void impureCaller(scope void delegate() del) pure { del(); } void f() pure // strongly pure, will modify `i` { S s; impureCaller(&s.g); } --- Currently the only error is in `impureCaller` body. You propose to make `impureCaller`'s body valid thus making the code compilable. Do you also propose some breaking changes to make `f` body invalid? I see no "breaking changes" notes in you "nutshell" at the end. Looks like you either didn't think enough about such cases or you propose to make it impossible to detect whether the function is strongly pure by it's signature. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: std.templatecons ready for comments
10.11.2013 19:30, Ilya Yaroshenko пишет: Hello, All! std.templatecons: Functional style template constructors. Documentation: http://9il.github.io/phobosx/std.templatecons.html Source: https://github.com/9il/phobosx/blob/master/std/templatecons.d Note: dmd >= 2.64 required Please destroy! I am sorry for my English in sources/docs. Best Regards, Ilya No more plain modules, please. Call it `std.meta.`. I'm against of including a few range-like (i.e. like `std.range` and `std.algorithm` stuff) templates like `RepeatExactly`, `templateStaticMap`, and `templateFilter`. First these are generic tuple manipulation templates belong to `std.meta.generictuple` (or how it's called now). Second I'd like to see one-to-one analog of all (most) applicable range operation functions for generic tuples in Phobos by merging in e.g. [1] As for `std.functional`-like template I can't tell much as the only ones http://denis-sh.bitbucket.org/unstandard/unstd.templates.html [1] http://denis-sh.bitbucket.org/unstandard/unstd.generictuple.html -- Денис В. Шеломовский Denis V. Shelomovskij
Re: std.templatecons ready for comments
12.11.2013 0:33, Denis Shelomovskij пишет: 10.11.2013 19:30, Ilya Yaroshenko пишет: Hello, All! std.templatecons: Functional style template constructors. Documentation: http://9il.github.io/phobosx/std.templatecons.html Source: https://github.com/9il/phobosx/blob/master/std/templatecons.d Note: dmd >= 2.64 required Please destroy! I am sorry for my English in sources/docs. Best Regards, Ilya No more plain modules, please. Call it `std.meta.`. I'm against of including a few range-like (i.e. like `std.range` and `std.algorithm` stuff) templates like `RepeatExactly`, `templateStaticMap`, and `templateFilter`. First these are generic tuple manipulation templates belong to `std.meta.generictuple` (or how it's called now). Second I'd like to see one-to-one analog of all (most) applicable range operation functions for generic tuples in Phobos by merging in e.g. [1] As for `std.functional`-like template I can't tell much as the only ones http://denis-sh.bitbucket.org/unstandard/unstd.templates.html [1] http://denis-sh.bitbucket.org/unstandard/unstd.generictuple.html Sorry, accidental Ctrl+Enter. So let me continue: As for `std.functional`-like template I can't tell much as the only ones I really use are `unaryFun`/`binaryFun` and its string-to-function abilities which I also need for templates and which I also want to have in Phobos (see [2]). [2] http://denis-sh.bitbucket.org/unstandard/unstd.templates.html -- Денис В. Шеломовский Denis V. Shelomovskij
Re: std.templatecons ready for comments
12.11.2013 2:19, John Colvin пишет: On Monday, 11 November 2013 at 22:18:27 UTC, John Colvin wrote: On Monday, 11 November 2013 at 20:33:37 UTC, Denis Shelomovskij wrote: 10.11.2013 19:30, Ilya Yaroshenko пишет: Hello, All! std.templatecons: Functional style template constructors. Documentation: http://9il.github.io/phobosx/std.templatecons.html Source: https://github.com/9il/phobosx/blob/master/std/templatecons.d Note: dmd >= 2.64 required Please destroy! I am sorry for my English in sources/docs. Best Regards, Ilya No more plain modules, please. Call it `std.meta.`. I'm against of including a few range-like (i.e. like `std.range` and `std.algorithm` stuff) templates like `RepeatExactly`, `templateStaticMap`, and `templateFilter`. First these are generic tuple manipulation templates belong to `std.meta.generictuple` (or how it's called now). Second I'd like to see one-to-one analog of all (most) applicable range operation functions for generic tuples in Phobos by merging in e.g. [1] As for `std.functional`-like template I can't tell much as the only ones http://denis-sh.bitbucket.org/unstandard/unstd.templates.html [1] http://denis-sh.bitbucket.org/unstandard/unstd.generictuple.html How would you feel about me cannibalising parts of that for my attempt at making a proper std.meta module? Conveniently it seems that we use similar core ideas, but have implemented disjoint sets of functionality. *somewhat disjoint Use it as you wish. Also feel free to e-mail me with questions/functionality requests (or open issues for Unstandard project). Just in case you want we also could make `unstd.meta` and then push to Phobos. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Is there any plans to make working signals in D?
24.04.2013 12:47, deadalnix пишет: On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote: 19.04.2013 11:45, deadalnix пишет: On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote: Another try to describe the problem: When I get a delegate, I'd like to use it unless it become invalid. How does using an object solve that ? Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed); --- I still see many possibilities without changing the language. For instance, allowing to attach dispose event to something else than an object. Thus making that "something else" almost class but not class and I don't see why not just use class instead of creating a new entity. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: clear() causes crash?
30.04.2013 1:04, "Luís Marques" " пишет: This crashes in the last line of main: class A { void foo() {} } void main() { A a = new A(); a.foo(); clear(a); assert(a !is null); a.foo(); // crashes } As far as I understand from TDPL book, this should not crash, but it does (DMD64 v2.062, OS X). Am I misunderstanding clear()? BTW, why not make clear also change 'a' to null? Ideally is should throw with pretty message but it isn't implemented. See Issue 8139 - Make objects really disposable by addition of "Object finalized" assertion [1]. IMO, also `destroy` (renamed `clear`) looks like the worst mistake in D runtime and I'd recommend to not use it (or better recompile druntime+phobos without it for your own use). See Issue 9139 - `destroy` is dangerous and inconsistent [2]. Use `unstd.lifetime.finalizeClassInstance` [3] and friends for user-defined lifetime implementation to avoid serious problems. [1] http://d.puremagic.com/issues/show_bug.cgi?id=8139 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9139 [3] http://denis-sh.github.io/phobos-additions/unstd.lifetime.html#finalizeClassInstance -- Денис В. Шеломовский Denis V. Shelomovskij
Re: I wrote a JSON library
07.05.2013 11:29, w0rp пишет: I wasn't quite satisfied with std.json or the JSON libraries in frameworks. The standard library doesn't make it easy enough to create JSON objects, and my primary objection for the framework solutions is that they seem to depend on other parts of the frameworks. (I'd rather not depend on a host of libraries I won't be using just to use one I will.) So, desiring an easy-to-use and atomic library, I took to writing my own from scratch. https://github.com/w0rp/dson/blob/master/json.d I would love to hear some comments on my implementation. Criticism is mostly what I am after. It's hard for me to self-criticise. Perhaps the most obvious criticism to me is that I seem to write too damn many unit tests. Good luck as my personal attempt to improve std.json to at least this: https://github.com/D-Programming-Language/phobos/pull/1206#issuecomment-14826562 got stuck on even this simple pull: https://github.com/D-Programming-Language/phobos/pull/1263 -- Денис В. Шеломовский Denis V. Shelomovskij
Any plans to fix Issue 9044? aka Language stability question again
As those of you who do write some non-toy projects in D know, from time to time you projects become unbuildable because of Issue 9044 [1] an you have to juggle with files and randomly copy/move functions from one library to another to "detrigger" the issue creating mess marked "Issue 9044 workaround". It become really annoying when your one-file project using an external library fails as it forcing you to juggle with that library files (e.g. VisualD's `cpp2d` project which triggers the issue randomly). I'd never complain about such things but the language is tend to be self-called stable by main maintainers and I'd like to finally see an official definition of this "stability" as it obviously contradicts my personal very loyal definition (e.g. I have noting against breaking changes if they are in good direction). [1] http://d.puremagic.com/issues/show_bug.cgi?id=9044 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Discussion of TypeTuple naming
27.05.2013 15:36, Diggory пишет: I gather this has been discussed before and even a potential solution submitted (https://github.com/D-Programming-Language/phobos/pull/780) However it was dismissed due to too much existing code being broken. I'd like to suggest a slightly less severe change which should still fix the issues with TypeTuple: https://github.com/D-Programming-Language/phobos/pull/1309 It introduces a new template, StaticTuple which can store any template parameters. The two templates are exactly equivalent except that TypeTuple checks that its parameters are actually types, so StaticTuple!(int, float) == TypeTuple!(int, float). Reasons for the change: - Tuples seem to confuse everyone trying to learn D, the inconsistency in TypeTuples is a big part of that. Naming the new type "StaticTuple" makes it abundantly clear that the built in "Tuple" type is for storing multiple values together at runtime while a "StaticTuple" is a similar construction but for compile time. It then follows directly that "TypeTuple" is a particular type of "StaticTuple" for dealing with types. - The current functionality of using TypeTuples with non-types is extremely useful and yet completely undocumented. This change means that if some code expects a StaticTuple we can be safe to assume that passing it non-types will be fine, and it also opens of the doors for other specialized versions of StaticTuple such as ExpressionTuple. I have avoided doing anything other than the most basic addition of StaticTuple in this pull request as further improvements are a separate issue that can be dealt with later. - Unless we plan to stick to the current absurd and confusing naming for TypeTuple forever, it's better to make the change sooner rather than later. Reasons why this change is not detrimental: - The result of the change is zero existing code actually failing to compile. TypeTuple will simply show a deprecation warning if used with non-types. - If even a deprecation warning is too much an arbitrarily large existing code-base can be fixed using a one off find and replace. - The new template is also still in the "std.typetuple" module. This is not ideal but it is also not a problem - it's common for a module to contain related types in addition to the one it's named after. - Any code that does use non-types with TypeTuple is using undocumented behaviour. Making undocumented behaviour deprecated is a very reasonable change even in the most stable of languages, so arguing that D is supposed to be stable and that this breaks too much is not a very convincing argument. - Almost all uses of TypeTuple are for dealing with types and so will be completely unaffected by the change. - There's no necessity to ever actually completely remove the deprecated behaviour, the deprecation warning is enough. It's not like code only has X amount of time to change its behaviour to the new system. Good luck from the heart as I've failed with almost every proposal to change/add something in Phobos or in a language. For generic tuple lovers (like me) I'd suggest just to use my `unstd.generictuple` [1] as it has rather good code quality and I will keep it up-to-date with language changes. [1] http://denis-sh.github.io/phobos-additions/unstd.generictuple.html -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Need some opinions for a GUI editor
29.05.2013 1:25, Flamaros пишет: Hi, I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library. In this way, we'll see which features are need. My concern is about how the editor have to works, we see two different ways to do it : 1) Classic editor external to the user applications a) Good : - Lightweight (easy to deploy and test) - No need to modify application code - Stable due to isolation of application - Real-time edition but limited on one view (bad to preview menus transitions) b) Bad : - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items) 2) Integrated editor (launch with the user application in a second Window) a) Good : - Preview is the final result with real data - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview) - Full real-time edition (can preview menus transitions,...) - User can customize the editor b) Bad : - Intrusive in the application code - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system) - Less stable editor? The second solution is commonly used in the video game industry, but is the best choice for a larger usage? What do you think about? As for me, a GUI editor is completely unneeded. Currently I'm using GTK+ for my apps so I tried to use Glade a long time ago but finished manually writing all the code as it: 1. It is not complicated and not time-wasted at all. 2. It gives you more control on the application. 3. It saves you time (!) as you can use you own functions for common widgets creation/location patterns. So if your library isn't that silly one where you have to manually specify widget location/size in parent don't waste your time on GUI editor. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Any plans to fix Issue 9044? aka Language stability question again
25.05.2013 14:07, Denis Shelomovskij пишет: As those of you who do write some non-toy projects in D know, from time to time you projects become unbuildable because of Issue 9044 [1] an you have to juggle with files and randomly copy/move functions from one library to another to "detrigger" the issue creating mess marked "Issue 9044 workaround". It become really annoying when your one-file project using an external library fails as it forcing you to juggle with that library files (e.g. VisualD's `cpp2d` project which triggers the issue randomly). I'd never complain about such things but the language is tend to be self-called stable by main maintainers and I'd like to finally see an official definition of this "stability" as it obviously contradicts my personal very loyal definition (e.g. I have noting against breaking changes if they are in good direction). [1] http://d.puremagic.com/issues/show_bug.cgi?id=9044 So now the issue is marked as duplicate of Issue 6461 [1]. The issue have no votes. There is no official answers about when it will be fixed. Am I the only one who meet it in almost every project at least at age about dozen days of development? [1] http://d.puremagic.com/issues/show_bug.cgi?id=6461 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: about "with statement"
09.06.2013 14:11, khurshid пишет: D language have like Pascal/Delphi "with statement", which very useful for writing readable code. http://dlang.org/statement.html#WithStatement Maybe I'm wrong, but, I never saw where using this statement in phobos source codes, what problem using this statement? Note, that for now you can't instantiate templates in with statement, see Issue 6196 [1]. [1] http://d.puremagic.com/issues/show_bug.cgi?id=6196 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: std.signals regressions
14.06.2013 18:31, David пишет: This code currently fails with a RangeError (used to work in 2.062) // http://dpaste.dzfl.pl/332a71ec import std.stdio; import std.signals; struct X { mixin Signal!(); } class O { void m() {} } void main() { O o = new O(); X[string] aa; aa["o"] = X.init; aa["o"].connect(&o.m); /*{ // 20 X x = aa["o"]; }*/ } If you take the uncomment the "block" at line 20 you end up with a segmentation fault, also worked in 2.062. Both times the problem is in the __dtor (segfault happens in the call to "_d_toObject(stor.ptr)". Changing "struct" to "class" and "X.init" to "new X()" it seems to work as it should. Is this worth a bugreport or was the old behaviour never intended? This bug (I consider it one) broke quite a few lines of code... If the old behaviour was never intended, why wasn't it documentated then... oh well I am drifting into another D rant here... http://dlang.org/phobos/std_signals.html#Signal "Mixin to create a signal within a class object." So your `X` must be a class. Also don't use std.signals - it's an incorrect and dangerous mess (see bug tracker). -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DIP42 - Add enum E(T) = expression; eponymous template support
26.06.2013 1:31, Walter Bright пишет: http://wiki.dlang.org/DIP42 What about enhancement 7364 [1] (from [2] discussion)? As we still have such cases: --- static if (...) enum fullyQualifiedNameImplForTypes = ...; else static if (...) enum fullyQualifiedNameImplForTypes = ...; else static if (...) ... --- which will look better this way: --- static if (...) enum template = ...; else static if (...) enum template = ...; else ... --- Also note current syntax is error-prone as one can easily make a typo or copy paste mistake which will lead to cryptic template errors. [1] http://d.puremagic.com/issues/show_bug.cgi?id=7364 [2] http://forum.dlang.org/thread/jfh7po$3b$1...@digitalmars.com?page=1 -- Денис В. Шеломовский Denis V. Shelomovskij
What about to add costume projects to D autotester?
As dmd is actively developed approximately every 2 weeks (since May) I have to find a cause for a regression which takes few hours and is a bit annoying as it looks like a needless job. What about to introduce some benefit criteria (regressions discovered by the project e.g.) relying on which a project is considered to be useful and can is added to autotester? This will help dmd developers to see bugs in their pulls immediately and will save D users time. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DIP42 - Add enum E(T) = expression; eponymous template support
26.06.2013 20:35, Andrej Mitrovic пишет: On 6/26/13, Denis Shelomovskij wrote: which will look better this way: --- static if (...) enum template = ...; else static if (...) enum template = ...; else ... --- Yeah I agree, this is more important than DIP42's shortened syntax for simple templates. It's the more complicated templates that are the problem. It's rather strange that enhancement 7364 isn't implemented yet (and even not discussed) as it's an easy-to-implement change with big pros and no cons. -- Денис В. Шеломовский Denis V. Shelomovskij
Add static code analyzing to dmd
IMHO it's an important enhancement as I see no reasons for the compiler to not inform about may-be-an-error situations if the user asks as it will save a lot people time. Original issue: http://d.puremagic.com/issues/show_bug.cgi?id=9811 Description: There are things which may or may not indicate and error. Current compiler behavior is: "I'm a compiler, I can't even give a warning if there is a chance for false positive, there are only warnings and errors". But it looks inconsistent with the fact a compiler tries to help the developer by doing code coverage, documentation etc. Static code analyzing is an essential task a compiler could also do and do good. Also, IMHO, compilers should do static analyzing instead of external tools. So I propose to add "-diagnostic" flag to the compiler for things Walter is "a bit uncomfortable in declaring it as always wrong" and also for things that are definitely not always wrong. There also could be different levels of such analyzing and ability to treat diagnostic warnings as errors. See also: [1] Interview of Walter Bright by Andrey Karpov http://www.viva64.com/en/b/0182/ [2] NG thread about the interview http://forum.dlang.org/thread/nnzzbsafuwwzuotvl...@forum.dlang.org -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Feature request: assert expressions should live inside version(assert)
07.07.2013 17:12, Tommi пишет: On Sunday, 7 July 2013 at 12:30:28 UTC, Andrej Mitrovic wrote: On 7/7/13, Tommi wrote: Sometimes you need to have some extra data to check against in the assert expression. That data isn't needed in release mode when assertions are ignored. Therefore, you put that extra data inside a version(assert). But then those assertions fail to compile in release mode because the symbol lookup for that extra data fails. For this reason, assert statements should live inside version(assert) blocks by default. I've ran into an issue when implementing this feature back in February (see the pull request): http://d.puremagic.com/issues/show_bug.cgi?id=9450 https://github.com/D-Programming-Language/dmd/pull/1614 Oh, should have searched bugzilla before posting this. But would it be possible to implement it something like: During a release build, even though version(assert) blocks are compiled out of existence, the compiler would keep a separate list of symbols (and other info) of the things declared inside those version(assert) blocks. Then, when parsing assert expressions, if an undefined symbol is found, the compiler would check that separate list of symbols that it has been keeping, and if the symbol is found there and use of the symbol is syntactically correct, the compiler would just keep on going instead of spewing an "unidentified identifier" error. That way we'd make sure that things like: assert(this_identifier_doesnt_exist < 12); ...wouldn't compile. It's always a bad idea to add special cases like this one for `version(assert)`. Anyway one will get into huge troubles trying to implement such stuff as I even can't imagine how it can be implemented consistently. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Strict aliasing in D
27.07.2013 12:59, Walter Bright пишет: On 7/27/2013 1:57 AM, David Nadlinger wrote: On Saturday, 27 July 2013 at 06:58:04 UTC, Walter Bright wrote: Although it isn't in the spec, D should be "strict aliasing". This is because: 1. it enables better code generation 2. there are ways, such as unions, to get the other aliasing that doesn't break strict aliasing We need to carefully formalize this then, and quickly. The problem GCC, Clang and others are facing is that (as you are probably aware) 2. isn't guaranteed to work for type-casting pointers either by the specs, but people want to be able to do this nonetheless. Thus, they both accept pointer aliasing through union types, trying to optimize as much as possible while avoiding to break people's expectations and existing code. This is a very unfortunate situation for both compiler developers and users; just search for something like "gcc strict aliasing" on StackOverflow for examples. There is already quite a lot of D code out there that violates the C-style strict aliasing rules. I agree. Want to do an enhancement request on bugzilla for it? So is enhancement request filed? -- Денис В. Шеломовский Denis V. Shelomovskij
Re: scoped allocations
27.11.2013 3:33, Namespace пишет: First of all: I apologize for my bad english. In the last few weeks I searched for a way to allocate nicely temporary buffer of unknown lengths. You can use `unstd.memory.allocation.tempAlloc` [1]. Also there is `unstd.c.string.tempCString` [2] for common case of temporary C strings. [1] http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc [2] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html#tempCString -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Duplicate keys in array literals?
28.11.2013 15:23, bearophile пишет: Is it a good idea to silently statically accept duplicated keys in both dynamic array literals and in associative array literals? void main() { int[] a = [0:10, 0:20]; int[int] aa = [0:10, 0:20]; } I don't remember having ever had the need for this, and on the other hand I have had some mistakes like this in my D code not caught statically by the compiler. --- Note that in this post I am not discussing about inserting multiple times a key-pair in an associative array, this is normal and useful: void main() { int[int] aa; aa[0] = 10; aa[0] = 20; } Bye, bearophile File the issue please. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: How do you deal with scoped allocations?
08.12.2013 2:32, Namespace пишет: Since my last thread doesn't get much attention I like to ask here: How did you deal with temporary memory? The algorithm is always this: 1. Use function stack frame for small allocations. 2. Use thread local stack allocator if temporary allocations corresponds LIFO principle and use thread local heap otherwise. As for usability it must be a single function call and D type system have to rest. And what do you use? As I answered in previous thread: http://forum.dlang.org/thread/nxrxojbzbrfwv...@forum.dlang.org#post-l77th1:24icc:241:40digitalmars.com -- Денис В. Шеломовский Denis V. Shelomovskij
Finally full multidimensional arrays support in D
Multidimensional arrays indexing and slicing syntax is finally added [1] (thanks to Kenji Hara). So it was a good cause to update my multidimensional arrays library implementation and add support for the new syntax. So here we are: [2]. Also should we add it to the standard library? [1] https://github.com/D-Programming-Language/dmd/pull/443 [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Finally full multidimensional arrays support in D
17.03.2014 21:39, Denis Shelomovskij пишет: Multidimensional arrays indexing and slicing syntax is finally added [1] (thanks to Kenji Hara). So it was a good cause to update my multidimensional arrays library implementation and add support for the new syntax. So here we are: [2]. Also should we add it to the standard library? [1] https://github.com/D-Programming-Language/dmd/pull/443 [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html An important note: My proposal is just a sliceable multidimensional array implementation, a try to provide the same effort we have for simple arrays for multidimensional ones. It isn't aimed to be a dedicated matrix / linear algebra module. -- Денис В. Шеломовский Denis V. Shelomovskij
[Proposal] Add module for C-strings support in Phobos
It's filed as enhancement 12418 [2]: C-strings processing is a special and common case so: 1. C-strings should be supported with both performance and usability. 2. There should be a dedicated module for C-strings (instead of adding such functions here and there in other modules). Current state: there is no good support for C-strings in Phobos, there is slow and broken `toStringz` (Issue 12417 [3]), and no standard way to make many common operations, like converting returned C-string to string and releasing its memory or creating a C-string from string using an allocation function. So I propose to add `unstd.c.string` [1] module to Phobos which include all use-cases I have seen implementing (correct and fast in contrast to existing ones like GtkD (yes, it's both incorrect and slow because of tons of GC allocations)) C library wrappers. [1] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html [2] https://d.puremagic.com/issues/show_bug.cgi?id=12418 [3] https://d.puremagic.com/issues/show_bug.cgi?id=12417 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Add module for C-strings support in Phobos
20.03.2014 13:20, Rikki Cattermole пишет: On Thursday, 20 March 2014 at 08:24:30 UTC, Denis Shelomovskij wrote: It's filed as enhancement 12418 [2]: C-strings processing is a special and common case so: 1. C-strings should be supported with both performance and usability. 2. There should be a dedicated module for C-strings (instead of adding such functions here and there in other modules). Current state: there is no good support for C-strings in Phobos, there is slow and broken `toStringz` (Issue 12417 [3]), and no standard way to make many common operations, like converting returned C-string to string and releasing its memory or creating a C-string from string using an allocation function. So I propose to add `unstd.c.string` [1] module to Phobos which include all use-cases I have seen implementing (correct and fast in contrast to existing ones like GtkD (yes, it's both incorrect and slow because of tons of GC allocations)) C library wrappers. [1] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html [2] https://d.puremagic.com/issues/show_bug.cgi?id=12418 [3] https://d.puremagic.com/issues/show_bug.cgi?id=12417 Looks like it wouldn't be really useful with Windows API. Given that wstrings are more common there. You misunderstand the terminology. C string is a zero-terminated string. Also looks like you didn't even go to docs page as the second example is WinAPI one. Another thing that would be nice to have is a wrapper struct for the pointer that allows accessing via e.g. opIndex and opSlice. Ext. Use case: Store the struct on D side to make sure GC doesn't clean it up and still be able to access and modify it like a normal string easily. I don't understand the use-case. If you did implemented some C library wrappers and have a personal experience, I'd like to hear your opinion on C functions calling problem and your proposal to solve it, if you dislike mine. Also with examples, please, where my solution fails and your one rocks. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Finally full multidimensional arrays support in D
18.03.2014 1:35, Christof Schardt пишет: I looked to the doku-page and expected to see, how some basic matrix-operations could be performed. Like e.g. (basic syntax) this: Dim a(10,12) a(3,4) = 7 a(i,j) = a(j,i) * 12 Instead I found exotic assignments and calculations. Did I expect the wrong thing? Sorry for that. Do you mead there is a lack of simple indexing examples or lack of some matrix functionality? The latter case is if you meant "transpose and multiply by 12" with `a(i,j) = a(j,i) * 12`. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [Proposal] Add module for C-strings support in Phobos
20.03.2014 13:52, Rikki Cattermole пишет: On Thursday, 20 March 2014 at 09:32:33 UTC, Denis Shelomovskij wrote: 20.03.2014 13:20, Rikki Cattermole пишет: On Thursday, 20 March 2014 at 08:24:30 UTC, Denis Shelomovskij wrote: It's filed as enhancement 12418 [2]: C-strings processing is a special and common case so: 1. C-strings should be supported with both performance and usability. 2. There should be a dedicated module for C-strings (instead of adding such functions here and there in other modules). Current state: there is no good support for C-strings in Phobos, there is slow and broken `toStringz` (Issue 12417 [3]), and no standard way to make many common operations, like converting returned C-string to string and releasing its memory or creating a C-string from string using an allocation function. So I propose to add `unstd.c.string` [1] module to Phobos which include all use-cases I have seen implementing (correct and fast in contrast to existing ones like GtkD (yes, it's both incorrect and slow because of tons of GC allocations)) C library wrappers. [1] http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html [2] https://d.puremagic.com/issues/show_bug.cgi?id=12418 [3] https://d.puremagic.com/issues/show_bug.cgi?id=12417 Looks like it wouldn't be really useful with Windows API. Given that wstrings are more common there. You misunderstand the terminology. C string is a zero-terminated string. Also looks like you didn't even go to docs page as the second example is WinAPI one. I understand how c strings work. It would be nice to have more unittests for dstring/wstring, because it looks more geared towards char/string. Which is why it looks on the offset that it is less going to work. I'd say must unittests do test UTF-16 & UTF-32 versions. As for documentation, function signatures contain template parameter for character but probably there is a lack of ddoc unittests and/or documentation. Another thing that would be nice to have is a wrapper struct for the pointer that allows accessing via e.g. opIndex and opSlice. Ext. Use case: Store the struct on D side to make sure GC doesn't clean it up and still be able to access and modify it like a normal string easily. I don't understand the use-case. If you did implemented some C library wrappers and have a personal experience, I'd like to hear your opinion on C functions calling problem and your proposal to solve it, if you dislike mine. Also with examples, please, where my solution fails and your one rocks. ) I don't dislike your approach at all. I just feel that it needs to allow for a little more use cases. Given the proposal is for phobos. What you have done looks fine for most cases to c libraries. I'm just worried that it has less use cases then it could have. I'm just nitpicking so don't mind me too much :) Thanks. So the algorithm is like this: find C library which needs more love and file me an issue [1]. As I just added all common use-cases I have seen. [1] https://bitbucket.org/denis-sh/unstandard/issues -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Handling invalid UTF sequences
21.03.2014 12:25, monarch_dodra пишет: On Thursday, 20 March 2014 at 23:34:02 UTC, Brad Anderson wrote: I'm a fan of this approach but Timon pointed out when I wrote about it once that it's rather trivial to get an invalid string through slicing mid-code point so now I'm not so sure. It's just as easy to slice mid-codepoint as it is to access a range out of bounds. In both cases, it's a programming error. The only excuse I see for throwing an exception for slicing mid-codepoint, is that 1. programmers are less aware of the issue, so it's more forgiving in a released program (nobody likes a crash). 2. arguably, it's not the *program* state that's bad. It's the *data*. Well, in regards to "2", you could argue that program state and data state is one and the same. I think I'm still in favor of it because you've obviously got a logic error if that happens so your program isn't correct anyway (it's not a matter of bad user input). If I remember correctly, with a specially written UTF string, it *was* possible to corrupt program state. I think. I need to double check. I didn't give it much thought then ("it should virtually never happen"), but it could be used as deliberate security vulnerability. Almost nothing to add here. We already have `-noboundscheck` which can dramatically increase performance, throwing `UTFError` should either use same mechanics (`-noutfcheck`?) or just be stripped in release. Personally I'd choose the latter as there are lots of (sometimes very slow) assertions stripped with `-release` in real programs, which indicates same critical data corruption. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Cross Platform GUI Development
23.03.2014 16:34, Jeroen Bollen пишет: Are there any tools to do this at all in Digitalmars D? All current libraries seem to be outdated, but GTKD. GTK on it's end is a pain to bundle which is enough to not consider it cross platform at all. First, I don't understand what is the problem with GTK? Also there is DWT, but I already have spent some time on it and I'd like to suggest to not use it as its sources is a mess. As for cross-platform GUI app, I'd suggest to use own native GUI library for every platform as it looks like an easiest and the most convenient for the user of your program approach. The problem is it's too common to connect application login and GUI, so for my personal purposes I created MetaUI [1] which allow such intermediate layer and you only create native GUI elements, place it somewhere and connect with logic elements from MetaUI, see examples. As a native GUI I use GTK (mainly my own fast, correct and very usable bindings [2]) over MetaUI for now, but when I will have more time I will use DGui on Windows just to decrease program installation size. The only problem is a Mac OS X for which I don't know working GUI library (I don't target it for now, GTK may work but with PITA), but with MetaUI it shouldn't be a problem to use some C one as the only thing you need is a way to connect C widgets to D logic controls. [1] https://bitbucket.org/denis-sh/metaui [2] https://bitbucket.org/denis-sh/gtkd [3] https://bitbucket.org/dgui/dgui -- Денис В. Шеломовский Denis V. Shelomovskij
Re: ICE for x[] + x[]
23.03.2014 22:10, "Nordlöw" пишет: Just noticed that const x = [1]; assert(x[] + x[]); causes gives ICE Internal error: e2ir.c 1893 Bugzilla reference anyone? People are expected to search such things themselves: https://d.puremagic.com/issues/query.cgi -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Cross Platform GUI Development
24.03.2014 0:03, Jeroen Bollen пишет: On Sunday, 23 March 2014 at 19:56:47 UTC, Denis Shelomovskij wrote: 23.03.2014 16:34, Jeroen Bollen пишет: Are there any tools to do this at all in Digitalmars D? All current libraries seem to be outdated, but GTKD. GTK on it's end is a pain to bundle which is enough to not consider it cross platform at all. First, I don't understand what is the problem with GTK? ... The main problem I have with GTK is that it's a mess to setup on Windows for the end user. And you shouldn't ever do it. Just bundle GTK with your program and be happy. Here is what I use (~4 MiB): http://deoma-cmd.ru/files/other/GTK-3-redist.7z (if you are OK with third GTK version) These files just should be in your target installation directory. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Cross Platform GUI Development
24.03.2014 13:04, Gary Willoughby пишет: On Sunday, 23 March 2014 at 20:04:00 UTC, Jeroen Bollen wrote: The main problem I have with GTK is that it's a mess to setup on Windows for the end user. The only real problem is the actual installation of GTK onto the Windows user's machine as some people ask "why do i need to install this weird GTK thing for this app to work?". But... you can 'hide' the installation of GTK on Windows as part of the main application's installer because the Windows version of GTK has a silent install options. http://gtk-win.sourceforge.net/home/index.php/Main/EmbeddingGTK Note different programs may require different GTK versions and GTK isn't backward compatible on Windows because of some bugs (e.g. 2.16 is the last one with working OpenGL using GtkGLExt from 2.x), so it's usually just copied in application's folder. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Table lookups - this is pretty definitive
01.04.2014 22:35, Walter Bright пишет: Try this benchmark comparing various classification schemes: - import core.stdc.stdlib; import core.stdc.string; import std.algorithm; import std.array; import std.ascii; import std.datetime; import std.range; import std.stdio; import std.traits; bool isIdentifierChar0(ubyte c) { return isAlphaNum(c) || c == '_' || c == '$'; } bool isIdentifierChar1(ubyte c) { return ((c >= '0' || c == '$') && (c <= '9' || c >= 'A') && (c <= 'Z' || c >= 'a' || c == '_') && (c <= 'z')); } immutable bool[256] tab2; static this() { for (size_t u = 0; u < 0x100; ++u) { tab2[u] = isIdentifierChar0(cast(ubyte)u); } } bool isIdentifierChar2(ubyte c) { return tab2[c]; } /*/ int f0() { int x; for (uint u = 0; u < 0x100; ++u) { x += isIdentifierChar0(cast(ubyte)u); } return x; } int f1() { int x; for (uint u = 0; u < 0x100; ++u) { x += isIdentifierChar1(cast(ubyte)u); } return x; } int f2() { int x; for (uint u = 0; u < 0x100; ++u) { x += isIdentifierChar2(cast(ubyte)u); } return x; } void main() { auto r = benchmark!(f0, f1, f2)(10_000); writefln("Milliseconds %s %s %s", r[0].msecs, r[1].msecs, r[2].msecs); } Some regular benchmark notes: 1. The first one passed to `benchmark` is always slower (e.g. pass `f2` and see). 2. Unexpected program behaviour changes: Let's use `benchmark!(f1, f1, f1)(1_000_000)`: Milliseconds 928 889 888 Then copy `isAlphaNum` in file (benchmark still shows same results) and change `dchar c` to `ubyte c`, result changes: Milliseconds 849 815 827 The difference is sufficient but `isAlphaNum` not called in benchmark. Also `f0` is faster than `f1`, benchmark!(f0, f0, f0)(1_000_000): Milliseconds 731 694 702 And `f2` wins, it's the only obvious thing, benchmark!(f2, f2, f2)(1_000_000): Milliseconds 227 184 184 Compiler used: dmd -O -inline -release -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Table lookups - this is pretty definitive
01.04.2014 23:22, Denis Shelomovskij пишет: 01.04.2014 22:35, Walter Bright пишет: Try this benchmark comparing various classification schemes: - import core.stdc.stdlib; import core.stdc.string; import std.algorithm; import std.array; import std.ascii; import std.datetime; import std.range; import std.stdio; import std.traits; bool isIdentifierChar0(ubyte c) { return isAlphaNum(c) || c == '_' || c == '$'; } bool isIdentifierChar1(ubyte c) { return ((c >= '0' || c == '$') && (c <= '9' || c >= 'A') && (c <= 'Z' || c >= 'a' || c == '_') && (c <= 'z')); } immutable bool[256] tab2; static this() { for (size_t u = 0; u < 0x100; ++u) { tab2[u] = isIdentifierChar0(cast(ubyte)u); } } bool isIdentifierChar2(ubyte c) { return tab2[c]; } /*/ int f0() { int x; for (uint u = 0; u < 0x100; ++u) { x += isIdentifierChar0(cast(ubyte)u); } return x; } int f1() { int x; for (uint u = 0; u < 0x100; ++u) { x += isIdentifierChar1(cast(ubyte)u); } return x; } int f2() { int x; for (uint u = 0; u < 0x100; ++u) { x += isIdentifierChar2(cast(ubyte)u); } return x; } void main() { auto r = benchmark!(f0, f1, f2)(10_000); writefln("Milliseconds %s %s %s", r[0].msecs, r[1].msecs, r[2].msecs); } Some regular benchmark notes: 1. The first one passed to `benchmark` is always slower (e.g. pass `f2` and see). 2. Unexpected program behaviour changes: Let's use `benchmark!(f1, f1, f1)(1_000_000)`: Milliseconds 928 889 888 Then copy `isAlphaNum` in file (benchmark still shows same results) and change `dchar c` to `ubyte c`, result changes: Milliseconds 849 815 827 The difference is sufficient but `isAlphaNum` not called in benchmark. Also `f0` is faster than `f1`, benchmark!(f0, f0, f0)(1_000_000): Milliseconds 731 694 702 And `f2` wins, it's the only obvious thing, benchmark!(f2, f2, f2)(1_000_000): Milliseconds 227 184 184 Compiler used: dmd -O -inline -release Few more words about `dmd`: "Hey, silly, you still use `== x` to compare with `x`? Use table lookups! And never cast `size_t` to `ubyte`! See: --- import std.datetime; import std.stdio; immutable bool[256] tab2; static this() { foreach(size_t u; 0 .. 0x100) tab2[u] = u == '_'; } /*/ int f0() { int x; foreach(uint u; 0 .. 0x100) x += u == '_'; return x; } int f2() { int x; foreach(uint u; 0 .. 0x100) x += tab2[cast(ubyte)u]; return x; } int f2plus() { int x; foreach(size_t u; 0 .. 0x100) x += tab2[u]; return x; } void main() { auto r = benchmark!(f0, f0, f0)(1_000_000); writefln("Milliseconds %s %s %s (f0)", r[0].msecs, r[1].msecs, r[2].msecs); r = benchmark!(f2, f2, f2)(1_000_000); writefln("Milliseconds %s %s %s (f2)", r[0].msecs, r[1].msecs, r[2].msecs); r = benchmark!(f2plus, f2plus, f2plus)(1_000_000); writefln("Milliseconds %s %s %s (f2plus)", r[0].msecs, r[1].msecs, r[2].msecs); } --- Milliseconds 323 274 281 (f0) Milliseconds 185 185 185 (f2) Milliseconds 105 97 105 (f2plus) --- P.S. I don't want to say anything with these results. I just have no idea what happens here and I don't want to investigate dmd's way of optimizing things now. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Encapsulating trust
31.08.2014 17:47, Dmitry Olshansky пишет: Quite recently a lot of work has been done to make most of Phobos usable in @safe code. While a very welcome effort, it caused a number of doubts in particular due to the boilerplate required to isolate a small amount of unsafe operations and slap "@trusted" over it. See e.g. Denis argument: https://github.com/D-Programming-Language/phobos/pull/2465 There were proposals for language changes along the lines of having @trusted block alike to debug/version blocks, but nothing ever came out of them. Without language support I decided it worth a shot to create a universal wrappers to establish a consistent convention. A use of such wrapper should indicate that a @system function call or language feature was hand-verified. Names and complete set of primitives are up for debate, but here is the start: https://gist.github.com/DmitryOlshansky/bc02f369c8a63818bd07 A bit of usage: import core.stdc.string; import trusted; void main() @safe { char[] msg = "Hello!".dup; char[] msg2 = msg; import trusted; // may also use static import for absolute clarity assert(call!memcmp(addrOf(msg[0]), addrOf(msg2[0]), msg.length) == 0); } What do you guys think? The language works fine for me as it is in this aspect. E.g. functions from `std.file` like `read` should be marked as `@trusted` because this is what `@trusted` is for, a function operating unsafe stuff and providing a safe interface to it. Currently the only problem is with templates like `std.array.Appender` when we want the compiler to infer attributes from user type and have to carefully wrap our code in `@trusted` blocks leaving calls to user code unwrapped. Yes, my opinion here is the same as Daniel's one. About related `std.file` pulls: I wrote my original comment [1] to the pull because it blows the code size and reduce its readability by using `@trusted` nested functions (lambdas not used just because they currently can't be inlined, but it's silly as these functions work with disk and thus slow anyway). This introduces a bad anti-pattern in the library and should be reverted. Just imagine a D newbie who just started leaning the language and is reading `std.file` module to see how easy can he use native API in D (e.g. I was such newbie). With all these pulls merged (current HEAD) he will be terrified of the code ugliness and either decide this is the only way to use native API in D (wrap every native function in `@trusted` nested function in `@safe` function) or will spend significant time discovering the history of this module and who is guilty in such bad design (e.g. I spend a lot of time when learned D because of `TypeTuple` used with expressions which completely confused me). [1] https://github.com/D-Programming-Language/phobos/pull/2465#issuecomment-53950146 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
15.05.2014 7:58, FrankLike пишет: 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. D need Christopher E. Miller. DFL isn't boost licensed, that's the problem for me. And Christopher didn't answered anything on my proposal to change the license. I'd suggest to put the effort in DGui [1] instead because its author, Antonio Davide Trogu, kindly changed the license to Boost as he want the library to be used. By the way, see DGui examples at Downloads page [2], they are smaller, than DFL ones. Also one of DGui goals was a source code simplicity. ) [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Allocating a wstring on the stack (no GC)?
07.05.2014 22:26, Maxime Chevalier-Boisvert пишет: I have a very specific use case (JIT compiler) in which I have a pre-allocated array of wchar string data stored somewhere in memory. I'd like to be able to create a temporary D wstring object to pass this as a "regular" string to other functions. For performance reasons, it would be preferable not to dynamically allocate or copy any data. Dynamically allocating the strings tends to trigger the D GC which severely impacts the performance. So, my question is, would it be possible for me to allocate a wstring object on the stack, and manually set its string data pointer and length? If so, how? Your wizardly help is much appreciated. If you have a preallocated data, just using slicing will be enough. A result will be `wstring` for immutable data or `const(wchar)[]` for non-immutable, if you respect a typesystem. If a new data is generated but you want it to be put on stack if it's small enough (you can't put big data on stack anyway) you need some allocation facility. E.g. `unstd.memory.allocation.tempAlloc` [1] will do the work. [1] http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 14:52, FrankLike пишет: On Sunday, 18 May 2014 at 09:22:53 UTC, FrankLike wrote: DFL isn't boost licensed, that's the problem for me. And Christopher didn't answered anything on my proposal to change the license. I'd suggest to put the effort in DGui [1] instead because its author, Antonio Davide Trogu, kindly changed the license to Boost as he want the library to be used. By the way, see DGui examples at Downloads page [2], they are smaller, than DFL ones. Also one of DGui goals was a source code simplicity. ) [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads Why not put it in github.com? Because personally I like Bitbucket (it has side-by-side diff and Github some time ago switched to completely unusable fonts for source code making it unreadable for Windows XP users like me). Thank you. And put it in code.dlang.org. Will do as soon as its Bitbucket support will be restored. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 18:25, FrankLike пишет: *http://denis-sh.bitbucket.org/ Where is the DGui? This dgui is very cool. The link is to my personal page. DGui isn't my library, I only manage it so it can't be listened in "my open-source projects" page. As for x64 support, yes is isn't ready. If it is needed just like any other feature feel free to open an issue. [1] https://bitbucket.org/dgui/dgui/issues -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 19:14, FrankLike пишет: On Sunday, 18 May 2014 at 14:54:44 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. DGui's Memory Usage is 3.2M. [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads You will put it in code.dlang.org and github.com? DGui is very cool,the exe's size is a half of DFL's,and it's easy to learn. If It will be used on Linux ,Mac Os X,it will be the coolist of all gui libs. Thank you. Frank And there are some controls are not implement,such as imageButton,GridView,DateTimePick,Socket,DataControl. Thank you. There is no plans for cross-platform porting or adding new controls in near future. Probably the situation may be improved in case developers of DFL unofficial fork [1] will join DGui development. [1] https://github.com/Rayerd/dfl -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Thank you Kenji
23.05.2014 8:11, Martin Nowak пишет: Today at DConf we learned, once again, that people are doing and starting amazing projects using D. A lot of which wouldn't have been possible without your contribution. So I just wanted to say thank you. -Martin Finally a thread to thank the man who fights all these corner cases and bugs. ) Thank you Kenji very much! -- Денис В. Шеломовский Denis V. Shelomovskij
Just curious: who do know current purity rules?
As Kenji Hara just created purity fixing pull [1] we will probably soon have more intuitive rules so it's interesting who do understand current purity rules. The following code is proposed to check your understanding: --- alias F = bool function(int) pure; alias D = bool delegate(int) pure; D foo1(immutable F f) pure { return x => (*f)(x); } // ok or error? D foo2(const F f) pure { return x => (*f)(x); } // ok or error? D foo1(immutable F* f) pure { return x => (*f)(x); } // ok or error? D foo2(const F* f) pure { return x => (*f)(x); } // ok or error? --- Who passes this test? By "pass" I mean completely understand what the compiler do and why. By the way, personally I would fail the test. ) [1] [spoiler!] https://github.com/D-Programming-Language/dmd/pull/3626 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Just curious: who do know current purity rules?
06.06.2014 13:05, Kagamin пишет: Do you mean true purity rules or whatever is implemented in the compiler? "whatever is implemented". ) -- Денис В. Шеломовский Denis V. Shelomovskij