Re: How to learn Phobos,Phbos hard to used for me.
On Wednesday, 28 August 2019 at 11:34:27 UTC, lili wrote: Hi: Masters who can write a book for Phbos, the dlang doc not friendly to beginner. Have you seen this? http://ddili.org/ders/d.en/index.html It helped me a lot in understanding ranges. Though there is nothing about containers there I don't think.
Re: Is removing elements of AA in foreach loop safe?
On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote: Iterating of some structure and removing elements thereby is always errorprone and should be avoided. But: In case of AA, I've got the feeling, that it might be safe: foreach (k,v;ways) if (v.empty) ways.remove(k); Do you agree? Or is there a better way to achieve this? This should work, due to the keys property returning a dynamic array: foreach (k; ways.keys) { if (ways[k].empty) ways.remove(k); } Jordan
Re: Is removing elements of AA in foreach loop safe?
On Fri, Aug 30, 2019 at 04:45:20PM +, berni via Digitalmars-d-learn wrote: > On Friday, 30 August 2019 at 15:00:59 UTC, Paul Backus wrote: > > Whether you actually get an error at runtime depends on the load > > factor of the AA. If it drops below a certain threshold, the AA will > > be resized [1], and its original memory will be freed [2]. > > It could still work, depending on how the foreach loop is implemented. > If the keys were stored away before starting the loop it would work. > But for one thing, it isn't implemented that way and for the other, > one shouldn't rely on it, because the implementation could change. > What I hoped for, was, that the specs enforce somewhere, that this is > to be implemented in a safe manner. > > I'll replace this loops by something better, e.g. the mentioned > filter. But I've never worked with AAs and filters yet. Will see, if I > manage to do that. Else I'll probably just copy the keys and use them > for an independent loop. In general, modifying a container (of any kind) while iterating over it is a bad idea, because it leads to corner cases with counter-intuitive semantics. In some cases, it can be made to work if the container supports deletion of the *current* element being iterated over. But this requires support from the container. General insertion/deletion during iteration over a container, generally speaking, leads to corner cases with "strange" behaviour. The problem is that iteration order becomes non-obvious once arbitrary changes can happen during iteration. If you're iterating over elements E1, E2, E3, etc., and then somebody inserts a new element E, should the current iteration include E or not? In an unordered container like an AA, this becomes an arbitrary choice (depends on implementation details like the hash function). If inserting/deleting from a container entails reorganization, what happens to the order of the ongoing iteration? Depending on how iteration is implemented, you may end up visiting the an element more than once, inadvertently skipping over some elements, or in rare cases end up iterating forever (if the container reorg moves your current position back while triggering more additions, and iterating over the added elements triggers a similar reorg). The basic problem is that the meaning of "iteration" becomes ill-defined once the container is subject to change in the middle of iteration. The exact semantics become dependent on the implementation details of the container, and you basically have to know exactly how the container works under the hood in order to predict the effects. When the implementation details are not known / should not to be known (encapsulation), this should generally be avoided. It's better to keep a list of changes in a separate list, and finish the current iteration first, then apply the changes in the list to the container. T -- Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton
Re: Is removing elements of AA in foreach loop safe?
On Friday, 30 August 2019 at 15:00:59 UTC, Paul Backus wrote: Whether you actually get an error at runtime depends on the load factor of the AA. If it drops below a certain threshold, the AA will be resized [1], and its original memory will be freed [2]. It could still work, depending on how the foreach loop is implemented. If the keys were stored away before starting the loop it would work. But for one thing, it isn't implemented that way and for the other, one shouldn't rely on it, because the implementation could change. What I hoped for, was, that the specs enforce somewhere, that this is to be implemented in a safe manner. I'll replace this loops by something better, e.g. the mentioned filter. But I've never worked with AAs and filters yet. Will see, if I manage to do that. Else I'll probably just copy the keys and use them for an independent loop.
Re: Is removing elements of AA in foreach loop safe?
On Friday, 30 August 2019 at 13:43:54 UTC, XavierAP wrote: On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote: Iterating of some structure and removing elements thereby is always errorprone and should be avoided. But: In case of AA, I've got the feeling, that it might be safe: foreach (k,v;ways) if (v.empty) ways.remove(k); Do you agree? Or is there a better way to achieve this? It compiles and it runs without throwing any RangeError... So it appears to be safe. Otherwise it'd be a bug that there's not error. Whether you actually get an error at runtime depends on the load factor of the AA. If it drops below a certain threshold, the AA will be resized [1], and its original memory will be freed [2]. [1] https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L631 [2] https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L154
Re: Is removing elements of AA in foreach loop safe?
On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote: Do you agree? Or is there a better way to achieve this? An alternative would be to reassign the AAA to the output of std.algorithm.filter()... but assignment between AAs and Ranges isn't so type-direct.
Re: Is removing elements of AA in foreach loop safe?
On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote: Iterating of some structure and removing elements thereby is always errorprone and should be avoided. But: In case of AA, I've got the feeling, that it might be safe: foreach (k,v;ways) if (v.empty) ways.remove(k); Do you agree? Or is there a better way to achieve this? It compiles and it runs without throwing any RangeError... So it appears to be safe. Otherwise it'd be a bug that there's not error.
Interdependent dub subpackages
I have a project where the source is mixed library, mixed application, and I'd like to separate the two. The code is fairly decoupled as is, but the files are all next to each other in the same namespace. I moved out the library parts and made a new dub package, and it alone compiles fine. Ideally I'd like to separate it further into subpackages in a tree-like structure where some depend on others (but not the other way around). /dub.sdl --- name "lu" targetType "none" dependency "lu:base" version="*" dependency "lu:utils" version="*" subPackage { name "base" targetType "library" sourcePaths "base" } subPackage { name "utils" targetType "library" sourcePaths "utils" } --- /base/dub.sdl --- name "base" targetType "library" sourcePaths "source" --- /utils/dub.sdl --- name "utils" targetType "library" sourcePaths "source" dependency "lu:base" version="*" --- $ dub build Performing "debug" build using /usr/bin/dmd for x86_64. lu:base ~master: building configuration "library"... lu:utils ~master: building configuration "library"... utils/source/config.d(35,12): Error: module `common` is in file 'lu/base/common.d' which cannot be read import path[0] = /usr/include/dlang/dmd /usr/bin/dmd failed with exit code 1. The offending line is naturally `import lu.base.common;`. Is what I'm trying to do not possible? I thought lu:utils would just use the generated liblu_base.a. Am I not understanding it right? I tried adding importPaths "." to the subPackages section in /dub.sdl in hope it would see it but it did nothing. importPaths "base" does nothing either. Do I need to add the source paths for "upstream" subpackages after all? Is that kind of downward dependency tree not possible?
Blog Post #66 - Toolbar Basics
Today we cover one of the basic widgets, namely, the Toolbar which isn't as straightforward to use since the deprecation of so many of GTK's StockIDs. You can find out what's changed and how to get around it right here: https://gtkdcoding.com/2019/08/30/0066-toolbar-basics.html