Re: Really easy optimization with std.experimental.allocator
On Sunday, 18 September 2016 at 01:44:10 UTC, Ryan wrote: I think it works because each time you call dispose it tells the GC to mark that memory as available, without the GC needing to do a collection sweep. This could be a really useful tip in the allocators section, as I see converting to IAllocator with the GC as the first step in testing optimizations with allocators. A bit more than that - because you dispose and allocate same amount of memory, you effectively reuse same memory block in GC pools over and over again. It is hardly surprising that this is much faster than "honest" allocation of lot of memory across different pools (CPU memory cache access pattern alone will make a huge difference).
Re: Rust-like collect in D
On Thursday, 6 October 2016 at 16:56:26 UTC, Nordlöw wrote:
Is there a way to do this, or do we need something similar to
`collect` in Phobos? Something like
import std.container.array : Array;
0.iota(n).collect!Array
You mean semantics like this?
Container collect(Container, Range) (Range r)
if(isOutputRange!Container)
{
Container container;
r.copy(container);
return container;
}
Re: Rust-like collect in D
On Thursday, 6 October 2016 at 14:32:44 UTC, Nordlöw wrote: Is there a concept in D similar to Rust's `collect`: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.collect If not, I'm eager to implement it to support D-style containers. What would the desired interface look like? Perhaps: 0.iota(n).collect!Array Or can/should we just overload `std.conv.to` as 0.iota(n).to!Array eventhough the element type is not explicit in the expression `to.!Array`? If an entity (i.e. container) implements OutputRange API, you can already do it: 0.iota(n).copy(container);
Re: dmd -o- option meaning changed recently? Now not creating OBJ but also not creating EXE
On Sunday, 2 October 2016 at 21:05:25 UTC, A D dev wrote: One last point: If that was always the behavior (in all versions from 2010 - or earlier), i.e. -o- generates neither .OBJ nor .EXE, then what is the purpose of the option? does it act as just a syntax check? Purpose is to skip code generation and only do syntax/semantic validation. Very helpful when testing compiler because: a) it takes less time speeding up overall test suite b) doesn't require runtime static library to succeed, thus simplifying setup
Re: mutable destructor? WAT???
And this segfaults (on Linux):
void main() @safe
{
auto s = const(S)("abcd");
foo(s);
}
I'd call it a clear bug. Most obvious fix would be to require
const destructor if non-default destructor is present AND
immutable/const instance is attempted to be created.
Re: mutable destructor? WAT???
Looks correct to me. This const annotation does not prevent you
from deleting memory or free'ing external resources - but it does
ensure no transitive mutations for data reachable from struct
fields. If it allowed destroying with mutable destructor, type
system hole like this would be legal:
struct S
{
char[] str;
~this() { str[0] = 'a'; }
}
auto s = new const S("abcd");
destroy(s); // mutates immutable literal
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Saturday, 27 August 2016 at 21:23:04 UTC, Illuminati wrote: On Saturday, 27 August 2016 at 17:27:19 UTC, Dicebot wrote: On Friday, 26 August 2016 at 23:38:02 UTC, Illuminati wrote: Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ Surely you would think that with the power D has such things would exist by now? There doesn't seem to be much demand for that as concurrency trend keeps moving from making shared access transparent to minimizing or even removing it completely. And for many remaining cases locking is acceptable and more simple. Thus I am not very surprised no one has bothered to work on lock-free data structures seriously so far. This is not a solution. D doesn't even seem to any have proper concurrent storage structures. It is not a solution indeed, it is explanation why no one has considered writing one important so far (which you seemed to be surprised about in the first post). Same for concurrent data storage structures or anything else that implies "casual" concurrency - it is too rarely needed. I am afraid most likely you will need to write your own if this is a must :(
Re: How to avoid ctRegex (solved)
On Saturday, 27 August 2016 at 17:35:04 UTC, cy wrote: On Wednesday, 24 August 2016 at 05:29:57 UTC, ag0aep6g wrote: The plain regex function doesn't have such a requirement. It also works with a pattern that's generated at run time, e.g. from user input. But you can use it with a compile time constant, too. And it works in CTFE then, but it does not "generate optimized native machine code". It's not using it with a compile time constant that struck me as weird. It's using it to assign a global variable that struck me as weird. But actual value of that Regex struct is perfectly known during compile time. Thus it is possible and fine to use it as initializer. You can use any struct or class as initializer if it can be computed during compile-time.
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Friday, 26 August 2016 at 23:38:02 UTC, Illuminati wrote: Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ Surely you would think that with the power D has such things would exist by now? There doesn't seem to be much demand for that as concurrency trend keeps moving from making shared access transparent to minimizing or even removing it completely. And for many remaining cases locking is acceptable and more simple. Thus I am not very surprised no one has bothered to work on lock-free data structures seriously so far.
Re: Linux and htod
On Thursday, 16 June 2016 at 12:23:09 UTC, fbmac wrote: How people use it on Linux, if htod is required to import C libraries and windows only?f People don't use htod. https://github.com/jacob-carlborg/dstep is best what one can be for plain binding generation.
Re: `return ref`, DIP25, and struct/class lifetimes
There is also another counter-obvious bit regarding current
implementation - it only tracks lifetime of actual references.
Check this example:
ref int wrap ( return ref int input )
{
return input;
}
int badWrapper()
{
int z;
{
int x = 42;
z = wrap(x);
}
return z;
}
it looks obvious that this compiles OK with dip25 check because
once value assignment happens, there is no more reference to
track. However it is very common to expect different semantics if
return type contains reference types - probably because it would
be very useful and because Rust has changed expectations of what
lifetime control can do :) And yet it will still work exactly the
same with no warnings from compiler, creating false sense of
correctness.
Re: `return ref`, DIP25, and struct/class lifetimes
tl; dr: DIP25 is so heavily under-implemented in its current
shape it can be considered 100% broken and experimenting will
uncover even more glaring holes.
To be more precise, judging by experimental observation,
currently dip25 only works when there is explicitly a `ref`
return value in function or method. Any escaping of reference
into a pointer confuses it completely:
ref int wrap ( return ref int input )
{
return input;
}
ref int badWrapper()
{
int x = 5;
return wrap(x); // Error: escaping reference to local
variable x
}
void main()
{
auto badWrap = badWrapper();
}
vs
struct S
{
int* ptr;
}
S wrap ( return ref int input )
{
return S();
}
S badWrapper()
{
int x = 5;
return wrap(x); // OK!
}
void main()
{
auto badWrap = badWrapper();
}
vs
struct S
{
int* ptr;
}
ref S wrap ( return ref int input )
{
static S tmp; // spot another hole :)
tmp = S();
return tmp;
}
ref S badWrapper()
{
int x = 5;
return wrap(x); // Error: escaping reference to local
variable x
}
void main()
{
auto badWrap = badWrapper();
}
You can probably spot the pattern here - compiler matches `return
ref` in parameter declaration to `ref` in return value and
enforces identical lifetime for those. No `ref` in return value -
no enforcing, but it will also happily accept nonsense `return
ref` annotations.
Theoretically it was supposed to be protected by `@safe`
attribute as one can't take address of local variable in safe
code. But there isn't any way to write such wrapper struct
without using pointers AFAIK.
In your actual example putting `return` on `get` method
annotation is additionally very misleading because it only
implies ensuring result does not outlive struct instance itself -
but it gets passed around by value anyway.
Re: Async or event library
On Tuesday, 10 May 2016 at 13:34:36 UTC, chmike wrote: My initial question is if there is a working group I could join to work on this pure D async library. I'm interested in working on the subject. Considering libasync is only native D async library supported by vibe.d right now, focusing on improving it is likely to be best course of action as it has highest chance of ending up base of Phobos std.async
Re: parameter pack to inputRange
On Monday, 9 May 2016 at 12:36:00 UTC, Ali Çehreli wrote:
On 05/09/2016 03:44 AM, Dicebot wrote:
> Ali version generates a compile-time switch for index
I think it's a run-time switch, generated by a compile-time
foreach:
E front() {
final switch (index) {// <-- RUNTIME
/* static */ foreach (i, arg; Args) { // <-- COMPILE
TIME
case i: // <-- RUNTIME
return arg; // <-- RUNTIME
}
}
}
Quite confusing. :)
It becomes even more confusing if you keep in mind that it is a
final switch on an index range known at compile-time - which
means that as long as whole template can be inlined and actual
index is know at CT, compiler can eliminate all runtime indexing
checks and just replace it with matching literal/symbol.
Re: parameter pack to inputRange
On Sunday, 8 May 2016 at 23:48:01 UTC, Erik Smith wrote: Thanks! The static array version works for me too. It would be good to understand more about what is going on. It looks like the cost of the static array is an extra copy for each element. Maybe there is still a way to avoid that. The difference is quite simple: my latest version does save copy of arguments in static array which means you can freely pass it around with referenced data being valid. But it may become expensive to copy with large argument lists if compiler can't optimize it away. Ali version generates a compile-time switch for index that returns either literals or external variables by referencing their symbol directly. If this gets used to reference external stack variables which later get out of scope, range may either start iterating over garbage memory or silently allocate a closure (don't remember which is the case for latest compiler). In practice, if you use good inlining compiler, like LDC, I'd say static array version is strictly better. It is guaranteed to be safe and RVO allows compiler to completely get rid of additional stack copies if usage scope is limited.
Re: parameter pack to inputRange
On Sunday, 8 May 2016 at 14:11:31 UTC, Ali Çehreli wrote:
E front() {
final switch (index) {
/* static */ foreach (i, arg; Args) {
case i:
return arg;
}
}
}
AFAIK, this will do funny things with referencing stack if
arguments are variables and not literals.
Re: parameter pack to inputRange
On Sunday, 8 May 2016 at 14:11:31 UTC, Ali Çehreli wrote:
On 05/05/2016 11:08 PM, Dicebot wrote:
> Unless parameter list is very (very!) long, I'd suggest to
simply copy
> it into a stack struct. Something like this:
>
> auto toInputRange (T...) (T args)
> {
> struct Range
> {
> T args;
> size_t index;
>
> T[0] front () { return args[index]; }
> void popFront () { ++index; }
> bool empty () { return index >= args.length; }
> }
>
> return Range(args, 0);
> }
I wanted this syntax to work but when I tested I saw that T
It does (and it must). I have just tested it and noticed another
issue though, one I have not foreseen initially. When accessing
variadic variable list, one must use compile-time known index
because variables are not guaranteed to be of same size. It can
be fixed by using static array (and CommonType is a right call of
course):
auto toInputRange (T...) (T args) @nogc
{
import std.traits : CommonType;
alias E = CommonType!T;
struct Range
{
E[T.length] args;
size_t index;
E front () { return args[index]; }
void popFront () { ++index; }
bool empty () { return index >= args.length; }
}
Range range;
foreach (i, ref arg; args)
range.args[i] = arg;
return range;
}
void main ( )
{
import std.stdio;
writeln(toInputRange(1, 2, 3));
}
This version is checked to work on my machine.
Re: Async or event library
On Thursday, 5 May 2016 at 09:21:04 UTC, rikki cattermole wrote: Event loops needs to be thread local not per process. So many API's such as WinAPI for e.g. GUI's have this requirement in it that its just not worth fighting over. It is implementation detail. You can have global event loop and internally distribute work between per-thread event loops - only event callbacks defined within existing task need to be bound to same worker thread. From the developer convenience PoV scheduler / event loop abstraction has to be process-global, I wouldn't consider anything else.
Re: Async or event library
On Thursday, 5 May 2016 at 08:19:26 UTC, chmike wrote: At the bottom of the wiki page there is an innocent question regarding TLS which is quite devastating. A worker thread pool system would not support affinity between threads and callback context. Unfortunately, D relies on Thread Local Storage for semi global data. This would be error prone. I saw such error case with people using TLS with Corba. It is possible to set thread CPU affinity. Usage of TLS is also crucial in high performance fiber-based async systems (as soon as you have multiple threads) - for example, to implement lock-free TLS cache for all fibers running on that worker thread.
Re: parameter pack to inputRange
On Friday, 6 May 2016 at 06:08:24 UTC, Dicebot wrote:
Unless parameter list is very (very!) long, I'd suggest to
simply copy it into a stack struct. Something like this:
auto toInputRange (T...) (T args)
{
struct Range
{
T args;
size_t index;
T[0] front () { return args[index]; }
void popFront () { ++index; }
bool empty () { return index >= args.length; }
}
return Range(args, 0);
}
(note that you can actually make it random access range and not
just input range, I simply have not defined required methods)
Re: parameter pack to inputRange
Unless parameter list is very (very!) long, I'd suggest to simply
copy it into a stack struct. Something like this:
auto toInputRange (T...) (T args)
{
struct Range
{
T args;
size_t index;
T[0] front () { return args[index]; }
void popFront () { ++index; }
bool empty () { return index >= args.length; }
}
return Range(args, 0);
}
Re: Is there a way to disable 'dub test' for applications?
On Monday, 18 April 2016 at 18:19:32 UTC, Jon D wrote:
On Monday, 18 April 2016 at 11:47:42 UTC, Dicebot wrote:
On Monday, 18 April 2016 at 04:25:25 UTC, Jon D wrote:
I have an dub config file specifying a targetType of
'executable'. There is only one file, the file containing
main(), and no unit tests.
When I run 'dub test', dub builds and runs the executable.
This is not really desirable. Is there a way to set up the
dub configuration file to disable running the test?
configuration "unittest" {
excludedSourceFiles "path/to/main.d"
}
Very nice, thank you. What also seems to work is:
configuration "unittest" {
targetType "none"
}
Then 'dub test' produces the message:
Configuration 'unittest' has target type "none". Skipping
test.
Those two option do different things. My proposal excludes file
with `main` function from tested sources but keeps actual test
target (so if you have unittest blocks in other modules, those
will be checked). Your version completely disabled test target.
I wasn't sure which option you want but glad it helped.
Re: Is there a way to disable 'dub test' for applications?
On Monday, 18 April 2016 at 04:25:25 UTC, Jon D wrote:
I have an dub config file specifying a targetType of
'executable'. There is only one file, the file containing
main(), and no unit tests.
When I run 'dub test', dub builds and runs the executable. This
is not really desirable. Is there a way to set up the dub
configuration file to disable running the test?
configuration "unittest" {
excludedSourceFiles "path/to/main.d"
}
Re: Fiber and Thread Communication
On Friday, 8 April 2016 at 20:25:11 UTC, Ali Çehreli wrote: On 04/08/2016 01:16 PM, Dicebot wrote: On Friday, 8 April 2016 at 19:46:17 UTC, tcak wrote: On Friday, 8 April 2016 at 15:33:46 UTC, Dicebot wrote: On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote: So a TId can represent either a thread or a fiber? AFAIR, yes (I haven't used std.concurrency in a long while, telling all from memory only). yes what? Thread or Fiber. Yes both :) Tid represent abstract execution context, with no implications about underlying executor. Thanks Dicebot. I don't think the included std.concurrency.FiberScheduler has support for message passing because FiberScheduler.spawn does not return a Tid. If so, I don't see how it's possible to send messages between fibers. Ali Looks like a (funny) oversight. Note that you get it for get fiber via https://github.com/D-Programming-Language/phobos/blob/master/std/concurrency.d#L1337 (and FiberScheduler specifically extends Fiber to add ThreadInfo to it) but there is no clear way to pass that info to spawn host. I have a feeling that if that code is patched to simply provide Tid, message passing will just magically work. Needs to be checked though.
Re: Fiber and Thread Communication
On Friday, 8 April 2016 at 19:46:17 UTC, tcak wrote: On Friday, 8 April 2016 at 15:33:46 UTC, Dicebot wrote: On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote: So a TId can represent either a thread or a fiber? AFAIR, yes (I haven't used std.concurrency in a long while, telling all from memory only). yes what? Thread or Fiber. Yes both :) Tid represent abstract execution context, with no implications about underlying executor.
Re: Fiber and Thread Communication
On Friday, 8 April 2016 at 14:08:39 UTC, Nordlöw wrote: So a TId can represent either a thread or a fiber? AFAIR, yes (I haven't used std.concurrency in a long while, telling all from memory only).
Re: Fiber and Thread Communication
On Friday, 8 April 2016 at 11:18:11 UTC, Nordlöw wrote: On Friday, 8 April 2016 at 11:01:21 UTC, Dicebot wrote: Doesn't std.concurrency support both right now? I remember seeing PR that adds message box support to fibers ages ago. See https://issues.dlang.org/show_bug.cgi?id=12090 and https://github.com/D-Programming-Language/phobos/pull/1910 for relevant code (as you can see it was merged several releases ago) 1. What functions provide message box communication? The same ones as thread ones. API is completely transparent. 2. But Fibers cannot currently be moved between threads right? Yes, and this is by design. It harms performance of concurrent apps.
Re: @nogc inconsistent for array comparison depending on mutability of elements
On Friday, 8 April 2016 at 12:45:59 UTC, Xinok wrote: On Friday, 8 April 2016 at 10:15:10 UTC, Dicebot wrote: On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote: Semantically, array literals are always allocated on the heap. In this case, the optimizer can obviously place the array on the stack or even make it static/global. So @nogc is enforced by the optimizer? Yes, sadly. What? O_o I stated that it's not and explained why doing so would be a bad idea. It is not enforced by _backend_ optimizer as all relevant checks are done by frontend but the fact of will you get error or not does depend on semantics that are currently defined as optional optimizations. Like putting array literal on stack.
Re: Fiber and Thread Communication
On Friday, 8 April 2016 at 10:51:49 UTC, Nordlöw wrote: Are there any plans to unite fiber-to-fiber communication with thread-to-thread communication in Phobos? Does vibe.d give any solutions here? Doesn't std.concurrency support both right now? I remember seeing PR that adds message box support to fibers ages ago.
Re: @nogc inconsistent for array comparison depending on mutability of elements
On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote: Semantically, array literals are always allocated on the heap. In this case, the optimizer can obviously place the array on the stack or even make it static/global. So @nogc is enforced by the optimizer? Yes, sadly. To make it sane one would need to make a list of all optimization DMD makes in that regard and put them into spec as mandatory for all compilers.
Re: Picking specific D compiler with rdmd
--compiler
Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?
Maybe LDC uses dynamic linking by default and DMD static one, same as on Linux?
Re: Unexpected behavior when casting away immutable
On Wednesday, 23 September 2015 at 14:34:07 UTC, bachmeier wrote: I was not aware that you could "violate" immutable. In that case, it's not immutable. You can violate absolutely everything in a system language with casts and pointers. That is exactly what makes it system language. But you do so only by intentionally and explicitly abandoning type system and domain of well-defined behaviour. Compiler could as well decide to put it in RO section of executable resulting in app crash at runtime (that happens with string literals on Linux). Any cast means "I know what I am doing and I am fully prepared to get burned".
Re: Combining Unique type with concurrency module
On Monday, 14 September 2015 at 00:11:07 UTC, Ali Çehreli wrote: There is a misconception. Unique guarantees that the object will not be copied. It does not provide any guarantee that only one thread will access the object. It is possible to write a type that acquires a lock during certain operations but Unique isn't that type. By intention Unique means more than just "no copies" - it also means "only one reference at a single point of time" which, naturally, leads to implicit moving (not sharing!) between threads. However, AFAIK there are still ways to break that rule with existing Unique implementation and, of course, std.concurrency was never pacthed for special Unique support (it should).
Re: Combining Unique type with concurrency module
On Monday, 14 September 2015 at 00:11:07 UTC, Ali Çehreli wrote: send(childTid2, cast(shared(Unique!S*))); And yeah this violates the idea of Unique. Sadly, I am not aware of any way to prohibit taking address of an aggregate.
Re: const-correct structs, best practices?
On Friday, 21 August 2015 at 15:00:04 UTC, Nick Sabalausky wrote: Is there a good posting somewhere that summarizes the current best practices for making const-correct (ie works for all of mutable/const/immutable) structs? - mark methods const - avoid reference type fields ;)
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 13:04:25 UTC, Atila Neves wrote:
On Wednesday, 12 August 2015 at 12:29:46 UTC, Dicebot wrote:
More info about what gets placed where please.
I have special dev layout on my system that co-exists with
system-wide installation of dmd. It is as simple as having
~/dlang/{dmd|druntime|phobos}, linking ~/dlang/dmd/src/dmd to
~/bin/dmd-dev and placing dmd.conf in ~/bin which adds all
those paths as -I and -L flags. Works just fine.
There's no system-wide installation (since I don't have root),
I just downloaded the zip for 2.068 and added dmd2/linux/bin64
to my PATH.
Atila
Yeah I have meant that it works _even_ if you also have
system-wide installation. No idea what dmd.conf they put into zip
- I never use it.
Re: dmd.conf... again
More info about what gets placed where please.
I have special dev layout on my system that co-exists with
system-wide installation of dmd. It is as simple as having
~/dlang/{dmd|druntime|phobos}, linking ~/dlang/dmd/src/dmd to
~/bin/dmd-dev and placing dmd.conf in ~/bin which adds all those
paths as -I and -L flags. Works just fine.
Re: Concurrency Confusion
On Tuesday, 4 August 2015 at 10:29:57 UTC, 岩倉 澪 wrote: On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote: auto output = receiveOnly!(immutable(Bar)[]); Won't message passing like this result in an expensive copy, or does the cast to immutable via assumeUnique avoid that? immutable data is implicitly shared and doesn't need to be duplicated - as it won't ever be modified, it is perfectly fine to do concurrent reads for that from multiple references. std.concurrency does by-value message passing (in this case just ptr+length), it never deep copies automatically
Re: Concurrency Confusion
import std.concurrency;
import std.typecons : Unique;
import std.exception : assumeUnique;
struct Foo { }
struct Bar { }
void bar_generator (Tid ownerTid)
{
receive(
(shared(Foo)* input) {
auto output = new Bar[100];
// compute output ..
// .. and cast to immutable via assumeUnique when
// finished as it won't be mutated anymore and no
// other pointers exist
send(ownerTid, assumeUnique(output));
}
);
}
void main ()
{
auto generator = spawn(bar_generator, thisTid);
// must be shared or immutable to be passed between threads
auto input = new shared Foo;
send(generator, input);
// in real app use `receiveTimeout` to do useful stuff until
// result message is received
auto output = receiveOnly!(immutable(Bar)[]);
import std.stdio;
writeln(output.length);
}
Re: Concurrency Confusion
On Tuesday, 4 August 2015 at 11:33:11 UTC, 岩倉 澪 wrote: On Tuesday, 4 August 2015 at 10:37:39 UTC, Dicebot wrote: std.concurrency does by-value message passing (in this case just ptr+length), it never deep copies automatically I assumed that it would deep copy (in the case of mutable data) since the data being sent is thread-local (unless I am misunderstanding something) It is heap-allocated and in there is no thread-local heap currently in D - only globals and static variables. std.concurrency never deep copies - if you are trying to send data which contains indirections (pointers/arrays) _and_ is not marked either immutable or shared, it will simply not compile.
Re: Thread communication
receiveTimeout
Re: Struct that destroys its original handle on copy-by-value
On Monday, 3 August 2015 at 08:54:32 UTC, Kagamin wrote: On Saturday, 1 August 2015 at 11:47:29 UTC, Joseph Rushton Wakeling wrote: Yea, but that's not what I'm trying to achieve. I know how I can pass something to `take` so as to e.g. obtain reference semantics or whatever; what I'm trying to achieve is a range that _doesn't rely on the user knowing the right way to handle it_. Wrapping a reference to a stack-allocated struct is also unsafe, so no way for the user to not know about it. It is now verified as safe by `return ref`.
Re: Struct that destroys its original handle on copy-by-value
On Saturday, 1 August 2015 at 17:50:28 UTC, John Colvin wrote: I'm not sure how good an idea it is to totally enforce a range to be non-copyable, even if you could deal with the function call chain problem. Even in totally save-aware code, there can still be valid assignment of a range type. I'm pretty sure a lot of phobos ranges/algorithms would be unusable. This is exactly why I proposed to Joe design with destructive copy originally - that would work with any algorithms expecting implicit pass by value but prevent from actual double usage. Sadly, this does not seem to be implementable in D in any reasonable way.
Re: Struct that destroys its original handle on copy-by-value
On Friday, 31 July 2015 at 18:13:04 UTC, Ali Çehreli wrote: To make sure, I didn't mean that I know of structs in Phobos that behave that way. Although, it would be interesting to identify them. :) Ali Things like Unique, Scoped, RefCounted - pretty much everything which wraps reference type with additional semantics.
Re: Struct that destroys its original handle on copy-by-value
On Friday, 31 July 2015 at 18:23:39 UTC, H. S. Teoh wrote: It seems that what the language (originally) defines structs to be, is not entirely consistent with how it has come to be used (which also entailed later extensions to the struct definition), and this has been a source of problems. Yes, and it wasn't because people started to misuse structs - it was because certain designs would be simply impossible otherwise. The very language design assumption that structs should always be dumb copyable values was not practical. It may come from times when GC, heaps and classes were considered good enough for everyone and RAII intended to be completely replaces by scope(exit). Which didn't work.
Re: Struct that destroys its original handle on copy-by-value
On Friday, 31 July 2015 at 17:21:40 UTC, Ali Çehreli wrote: On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: is this design idea even feasible in principle, or just a bad idea from the get-go? As I understand it, it is against one of fundamental D principles: structs are value types where any copy can be used in place of any other. I expect there are examples where even Phobos violates it but the struct documentation still says so: A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient. I believe this restriction should be banned. Considering classes have inherent reference + heap semantics (and you can only bail out of that with hacks) saying struct can't be anything but data bags makes impossible to implement whole class of useful designs. The fact that Phobos has to violate it itself to get stuff done is quite telling.
Re: Why hide a trusted function as safe?
I remember doing something like that in druntime because of objects - you can't override @safe method prototype with @trusted one.
Re: static opCall not working?
On Sunday, 19 July 2015 at 10:26:04 UTC, TC wrote: What is wrong here? Docs or behavior? Tested it on asm.dlang.org where it fails with all compiler versions. Docs are wrong here. `static opCall` was never intended to be used as constructor and I consider it a bad style in general. This is simply a workaround that people unhappy with lack of default struct constructor used but language actively resists such misusage (`auto s = new S(42)` won't work too btw) and it only causes confusion.
Re: Why aren't Ranges Interfaces?
On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote: How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable? It can be huge difference if you take inlning in mind. LDC is capable of flattening most simple range-based pipelines into simple in-place loop during optimization - something you can't do with interfaces unless some sort of runtime profiling optimization is involved.
Re: Typed Message Passing between D Processes
std.concurrency was supposed to be able to handle that by design but it is impossible to do without any sort of standard serialization utility in Phobos (and, ideally, very fast binary serialization utility)
Re: Does anyone get line numbers in stack traces on Linux?
druntime has never had support for file/line info in traces on Linux AFAIR gdb usually saves the day
Re: pthread and GC
On Wednesday, 13 May 2015 at 07:04:39 UTC, tcak wrote: I am using pthread somewhere in program, and it creates an object. After a while, I see core.thread.scanAllTypeImpl error on gdb. Does this mean that pthread and GC are incompatible? Any solution without making too much code changes? Does http://dlang.org/phobos/core_thread.html#.thread_attachThis help?
Re: vibed: how to use pure HTML instead of template engine?
On Wednesday, 6 May 2015 at 20:45:10 UTC, John Colvin wrote: On Wednesday, 6 May 2015 at 14:28:26 UTC, Adam D. Ruppe wrote: On Wednesday, 6 May 2015 at 14:23:27 UTC, Chris wrote: Especially this: http://vibed.org/templates/diet#embedded-code I think that's a misfeature... if I used vibe.d, I'd want to avoid the diet too. I quite like them. Obviously one can get too carried away, but overall they've been useful for me, especially when I'm working to very tight deadlines. I agree that this is misfeature but mostly because it makes impossible switching template generation to runtime during development for faster edit/compile cycles.
Re: CTFE template predicates
On Sunday, 3 May 2015 at 21:46:11 UTC, Robert M. Münch wrote: 3. TupleType is a very missleading name when you are learning these things, because the tuple can hold values as well. Or is there a more extensive explanation for the name I don't get? Legacy we are trying to get rid of. See also: https://github.com/D-Programming-Language/phobos/pull/3128 https://github.com/D-Programming-Language/dlang.org/pull/986
Re: User defined properties signatures
On Tuesday, 21 April 2015 at 13:27:48 UTC, Marc Schütz wrote: On Monday, 20 April 2015 at 20:22:40 UTC, Jonathan M Davis wrote: There may be languages out there which take the the return type into account when overloading, but I've never seen one. Rust does, as far as I know. And this is incredibly frustrating approach that harms both readability and maintainability (you can't cut/paste RHS of an expression anymore without additional changes to the context). I have actually mentioned that when doing first impressions post about Rust.
Re: User defined properties signatures
This isn't about type system per se but about preferred style of syntax. Original example that caused my hatred looked like this: `let i : uint = from_str(42)`. Fortunately this has been deprecated in favor of `parse` but same principle applies - Rust authors encourage you to use declaration for type deduction instead of expression. Same thing can be rewritten as `let i = from_str::uint(42)` without compromising any type strictness Rust is proud of. In this form RHS expression has clear unambiguous type and can be copied anywhere. But this is discouraged form. More than that, when I was pointing out ugly template syntax, I got some comments that it is OK exactly because you are always supposed to put type on LHS. This is purely matter of style decisions and it sucks hard.
Re: Linking C++ standard library works with GDC... but not DMD. (Linux)
On Thursday, 16 April 2015 at 12:39:07 UTC, Jacob Carlborg wrote: On 2015-04-16 11:56, Dicebot wrote: Simple issue but unpleasant fix. You always must use C++ library that matches base C++ compiler. For GDC it is GCC (which is used by default). For DMD it is DMC (Digital Mars C compiler). For LDC it is whatever Clang standard library is called. All those are incompatible because rely on different compiler built-ins. The title says (Linux), where DMD uses GCC and not DMC. Does DMD also use GCC conventions on Linux when compiling extern(C++) code? I didn't know that.
Re: Linking C++ standard library works with GDC... but not DMD. (Linux)
On Thursday, 16 April 2015 at 08:51:15 UTC, TheGag96 wrote: Hi, I've got this project that requires me to link into a C++ backend. It works just fine when using GDC: gdc *.d [client libraries] However, this command using DMD does not work: dmd -L-lstdc++ *.d [client libraries] I still get errors involving the standard library not being added like: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) What do I need to do to make this work? Thanks. Simple issue but unpleasant fix. You always must use C++ library that matches base C++ compiler. For GDC it is GCC (which is used by default). For DMD it is DMC (Digital Mars C compiler). For LDC it is whatever Clang standard library is called. All those are incompatible because rely on different compiler built-ins.
Re: Make a type tuple from an array
On Saturday, 11 April 2015 at 09:05:19 UTC, Nordlöw wrote: On Saturday, 11 April 2015 at 07:18:26 UTC, John Colvin wrote: Why not use isStaticArray instead of isInputRange here? Because that would be completely different. Static arrays aren't even input ranges... Ahh, my mistake. Could somebody explain when this feature is needed? Code generation. Doing string mixin for each element of the array (won't work with plain foreach over array as it does runtime iteration)
Re: D1 - D2 Code converter
On Monday, 6 April 2015 at 20:25:39 UTC, jicman wrote: Greetings! Has anyone written any quick program to convert d1 code to d2? I believe it will be a fine piece of program. :-) Thanks. josé It is surprisingly difficult, to the point of being almost impossible, to write such program. Problem is there are no simple 1-to-1 replacements for some of D1 concepts (like const storage class or array stomping) and adding const qualifiers automatically would require to effectively implement D1 compiler semantic stage with full code flow analysis. Combined, those 2 issues make creating such program hardly feasible. I will speaker about it in details in my DConf presentation (http://dconf.org/2015/talks/strasuns.html)
Re: using vibe.d to parse json
On Thursday, 26 March 2015 at 00:41:50 UTC, Laeeth Isharc wrote: Yeah, it is not very intuitive. But it works. Thanks. Next question - how can I correctly deal with inconsiderately chosen JSON field names like 'private' (which conflict in a struct declaration with D language keywords). A hack is to do a search and replace on the JSON before presenting it to vibe.d, but I wondered if there was a better way. Incidentally, vibe doesn't seem to like my replacing private with private_ - whereas privateX works. Laeeth. index-based access still should work, right? Like obj[private]
Re: Looking for MQTT client library
If it isn't on http://code.dlang.org it is unlikely to exist in easy to use form. Starting with C bindings is probably the easiest approach - you may want to check out https://github.com/jacob-carlborg/dstep if you haven't already.
Re: New package behaviour in 2.067
Looks like bug, investigating.
Re: New package behaviour in 2.067
https://issues.dlang.org/show_bug.cgi?id=14275
Re: D : dmd vs gdc : which one to choose?
On Thursday, 19 February 2015 at 08:46:11 UTC, Mayuresh Kathe wrote: How do I (a newbie to D) figure out which compiler set to use? I am running Ubuntu 14.10, and intend to stick with it in the long term. Should I choose DMD or go with GDC? I would like to know the rationale for suggestions for either. Thanks. GDC: + generates faster code + supports many of low-level GCC flags for code generation tuning + more platforms (ARM, MIPS) - slow compilation - updates to latest language version with considerable delay DMD: + very fast edit/compile cycle + reference compiler - ancient code generation backend - not many ways to affect generated code (outside of -O -inline) It is common to use DMD for development and GDC for building actual release binaries.
Re: Is this possible in D?
Most practical approach I am currently aware of is wrapping
actual implementation (in most restrictive version):
class Test {
private static void foo_() {}
version (Static)
{
static void foo() { foo_(); }
}
else
{
void foo() { foo_(); }
}
private void bar_() shared
{
}
version (Shared)
{
void bar() shared { bar_(); }
}
else
{
void bar() { (cast(shared Test)this).bar_(); }
}
}
But this relies on very careful code review because of casual
casts for certain attributes (static and public/private are easy
in that regard)
Re: GC deadlocks on linux
Any chance you are using gdm-3.12.x? I was so mad when I have encountered this: https://issues.dlang.org/show_bug.cgi?id=4890
Re: To write such an expressive code D
On Tuesday, 10 February 2015 at 08:40:38 UTC, Dennis Ritchie wrote: Because I was arguing with one quiet a stubborn person who does not like D, on this forum: http://www.cyberforum.ru/holywars/thread1367892-page13.html He asked me to write such a program using only the language features and functions sin(). If someone makes stupid demands like this one to justify his dislike for the language, such person is either deliberate troll or has strong enough prejudice no never like language anyway, arguments or not. Language features don't magically appear from nowhere - those come at cost of extra code in compiler and/or runtime library making it very hard to use language with smaller runtime (D is actually guilty of that). It is a common practice to treat standard language library as part of language. Both C and C++ include detailed spec on standard library in official language spec for example. As such making any distinction between two is impractical.
Re: core.exception.InvalidMemoryOperationError@(0)
On Monday, 26 January 2015 at 15:54:12 UTC, Bayan Rafeh wrote: I apologize, I thought the point of invariant was to ensure correctness of the object's state It is simply matter of internal correctness vs in-program correctness. Sorry, documentation should probably mention that explicitly. I have created a documentation PR : https://github.com/D-Programming-Language/dlang.org/pull/851
Re: vibe.d Subdirectory?
On Thursday, 15 January 2015 at 14:38:16 UTC, Steven Schveighoffer wrote: Pardon me for asking kind of a side question, but is there any online information on how to do this? I am contemplating migrating my in-house php-based application to vibe.d, but I wondered if I have to do it whole-sale (not much gratification until the whole thing is done) or piecemeal (then some parts are php, some are vibe.d, until whole thing is ported). I thought I could do the latter, but I don't know how to interact apache/php with vibe.d. The biggest question I have is how vibe.d and php can share session data. But I also have no idea which server should be in front, and how to call one another ;) Thanks -Steve Generally easiest way is to make Apache forward some of URLs to vibe.d process (acting as HTTP proxy) while keeping to serve remaining PHP scripts. The more gets implemented in vibe.d process, the more URLs can be forwarded. I am not sure about session data part though. Quite likely you will need to implement session storage as a dedicated persistent process that gets queried by both vibe.d and PHP script. But this is not my domain of knowledge.
Re: Tuple/Typedef question
I use this Typedef implementation instead:
/// one with non-default initializer
template Typedef(T, istring name, T initval)
{
static assert (name.length, Can't create Typedef with an
empty identifier);
enum Typedef =
(struct ~ name ~
{ ~
T.stringof ~ value = ~ initval.stringof ~ ;
~
alias value this; ~
});
}
/// basic overload
template Typedef(T, istring name)
{
static assert (name.length, Can't create Typedef with an
empty identifier);
enum Typedef =
(struct ~ name ~
{ ~
T.stringof ~ value; ~
alias value this; ~
});
}
unittest
{
mixin(Typedef!(int, MyInt1));
mixin(Typedef!(int, MyInt2));
static assert (!is(MyInt1 : MyInt2));
}
Re: Any chance of a linux dtoh?
On Tuesday, 6 January 2015 at 14:22:54 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 06 Jan 2015 14:08:30 + Laeeth Isharc via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I realize Walter has far better things to work on, but value of having a translation tool is considerable, since it opens up easy access to an enormous range of libraries. It is not much work to do the translation oneself, but in the world as it is small frictions cumulatively have large consequences. Access to libraries is a big advantage of python, and the like. Once you have the wrapper in place, I find D as productive as python, but for now it is still a bit of work first. i bet that the only realistic way to do something like that is to take some existing C/C++ parser and write the tool from scratch. Which is exactly what dstep is.
Re: Any chance of a linux dtoh?
On Tuesday, 6 January 2015 at 14:14:28 UTC, Laeeth Isharc wrote: On Tuesday, 6 January 2015 at 14:11:19 UTC, Dicebot wrote: dstep is your only realistic chance currently. htod is completely unmaintained, even on Windows. Please report any issues found with it in relevant issue tracker. I got it the wrong way around - yes, I meant htod. I have reported the issue, and author doesn't know what is wrong. You must be referring to https://github.com/jacob-carlborg/dstep/issues/33 You mention using DMD beta there. Please don't. Use last currently available public release. This specific beta is especially harmful being left-over from unfinished beta cycle.
Re: Any chance of a linux dtoh?
dstep is your only realistic chance currently. htod is completely unmaintained, even on Windows. Please report any issues found with it in relevant issue tracker.
Re: Unittest in a windows app
Can it be because Windows main wrapper consumes exceptions or spawn a separate thread for that or something like that?
Re: Memoizing methods
On Friday, 19 December 2014 at 02:45:13 UTC, kyle wrote: If you memoize a method inside a class definition using std.functional.memoize is caching done in a per-object manner, or do all objects of this class share cached return values? Thank you. Memoize uses one hash table per symbol it is applied to - all objects
Re: DUB build questions
On Saturday, 20 December 2014 at 04:15:00 UTC, Rikki Cattermole wrote: b) Can I do parallel builds with dub. CMake gives me Makefiles so I can make -j does dub have a similar option? No Worth noting that it is not actually a dub problem as much, it is simply not worth adding parallel builds because separate compilation is much much slower with existing D front-end implementation and even doing it in parallel is sub-optimal compared to dump-it-all-at-once.
Re: core.bitop.bt not faster than ?
Having quick read through the http://en.wikipedia.org/wiki/Word_%28computer_architecture%29 may help re-calibrating the way you thing about bit operations and optimization.
Re: Why do std.traits use template foo(args...) instead of foo(alias arg) ?
On Thursday, 18 December 2014 at 15:48:02 UTC, Mathias LANG wrote: An exemple being fullyQualifiedName: https://github.com/D-Programming-Language/phobos/blob/master/std/traits.d#L415 I don't get this pattern. Is it documented somewhere ? Full pattern looks like this: template foo(T...) if (T.length == 1) This is a way to workaround D template argument limitation - you can't have any parameter that accepts both types and symbols (`alias T` and `T` at once) other than variadic parameter. Limit variadic length to 1 and you emulate such accepts anything parameter.
Re: Why do std.traits use template foo(args...) instead of foo(alias arg) ?
On Thursday, 18 December 2014 at 17:20:28 UTC, Mathias LANG wrote: Thanks for the precision. Is it something that is going to be fixed, or is it by design ? It is something that most likely would have been designed differently if we had another chance (aka D3) but unlikely to change in D2 as existing pattern works good enough in practice. It is confusing but usually only needed for power user libraries thus learning curve impact is low.
Re: Garbage collector collects live objects
It may happen if only reference to an object is stored in memory block marked as data-only (using ubyte[] for a buffer is probably most common reason I have encountered)
Re: Does the compiler always semantically analyze everything in a project?
Apart from unused templates - yes. In abscence of .di files separate compilation only affects generated object files
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 14:52:56 UTC, Kagamin wrote: I was thinking about list comprehension, which is what programming on ranges is. Isn't it? No, not really. It only applies to specific subset of ranges and specific interpretation of list term. There is no straightforward equivalence here.
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:00:56 UTC, Ivan Kazmenko wrote: The suggested translations диапазон (diapason), список (list), последовательность (sequence), набор (collection) all have something in common with the range concept, but all of them seem to have a defined meaning in either maths or computer science. Maybe it's inevitable, just like range is itself an overloaded term in English. Yes, this is pretty much the case. One can't find translation for a range that won't have any additional connotations because range is itself heavily overloaded word in English. In my opinion: диапазон is ok to describe a finite forward range последовательность is solid generic term if you are not afraid of making mathematicians mad I don't like список or набор because they don't necessarily imply iteration which is the most crucial aspect of range concept. In practice I think it is OK to use any of those terms if you use it consistently within a book / article and explain its meaning somewhere in the very beginning.
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:09:06 UTC, ketmar via Digitalmars-d-learn wrote: набор ручек для писания, for example, as set of pens from which one pen can be taken and used (or another pen added to be used later). pretty similar to what range in D is, methinks. Only if http://en.wikipedia.org/wiki/Axiom_of_choice is believed to be correct :)
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:14:10 UTC, Chris wrote: Does that entail the concept that ranges (in D) are homogeneous (i.e. every member/item is of the same type)? Yes (if you mean static type) ElementType!Range is used extensively in Phobos
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 18:39:09 UTC, Ali Çehreli wrote: The separate concepts collection and range better have separate words. Ali This is especially important because collection tends to have certain connotation with container and confusion between ranges and containers is a common mistake among D newbies.
Re: Destructor/Finalizer Guarantees
As for guarantees for class destructors - you have hard guarantees that if memory is reclaimed, destructor was called before. But no guarantees memory will actually be reclaimed.
Re: Destructor/Finalizer Guarantees
There is an issue with structs that are directly allocated on heap - destructors are never called for those. You will want to change those into classes for GC to do at least something about it. See also this bug report : https://issues.dlang.org/show_bug.cgi?id=2834
Re: Strictness of language styling
Hard styling rules only apply to Phobos contributions. Any other project can have their own, for example, vibe.d requires own style which is incompatible with Phobos. For ported 3d party library value of minimizing the diff is indeed more important than styling.
Re: Reason for mypackage/package.d instead of mypackage.d
On Monday, 10 November 2014 at 21:25:32 UTC, Jonathan Marler wrote: I was perusing a PR for phobos where std/range.d was split into submodules and std/range.d was moved to std/range/package.d I was wondering why a package module had to be called package.d instead of just being the package name. For example, instead of moving std/range.d to std/range/package.d, why doesn't modifying std/range.d to contain the public imports of the submodules work just as well? My first thought was that maybe it let's the compiler know that all package modifiers are visible to all the modules in the same package, and the only way the compiler knows about what modules are in a package are if they are imported in the package.d file...is this one of the reasons? Also are there other reasons? Thanks in advance. You can't have both module and package of the same name AFAIR. Thus std/range.d + std/range/something.d simply won't work
Re: Pointer across threads
There is assumeUnique which effectively does cast to immutable but is more clear to the reader in a sense why breaking type system was considered legit. I recommend using it over raw cast.
Re: object hijacked ?
I think this is an issue with the import resolution, not module system. The way it is implemented right now DMD stops searching for object.d / object.di once it has found one. So while your module name is not interpreted as object _original_ object.di does not get imported and you get lot of different issues from missing declarations.
Re: D1: Error: duplicate union initialization for size
On Sunday, 31 August 2014 at 03:06:48 UTC, Dicebot wrote: My guess is that it hasn't been ported to the D1 compiler yet. Dicebot or any other people who work for Sociomantic should be most helpful. At this point, I recommend that you ask on the main D forum. Ali I have not encountered such issue in our D1 codebase but I will forward this question to our internal chat on Monday Have asked, no immediate recognition, sorry.
Re: alias and mixin
On Sunday, 31 August 2014 at 12:01:43 UTC, evilrat wrote: On Sunday, 31 August 2014 at 11:43:03 UTC, ketmar via Digitalmars-d-learn wrote: On Sun, 31 Aug 2014 11:26:47 + evilrat via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: alias myint = mixin(int); // - basic type expected blah blah mixin(alias myint = ~int~;); ? wow, it works. i don't even think inverting it O_o you saved my day, thanks. It is basically just an annoying grammar limitation that does not allow to use mixin / __traits as an identifier.
Re: alias and mixin
On Sunday, 31 August 2014 at 14:46:00 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
It is basically just an annoying grammar limitation that does
not allow to
use mixin / __traits as an identifier.
The usual helper template:
```
alias helper(alias a) = a;
```
helps for aliasing __traits and anonymous function templates (x
=
x+1), but I don't see an easy solution for mixin inside the
current
language, apart from pushing the mixin outside.
I recommend slightly more generic form:
template Alias(T...)
if (T.length == 1)
{
alias Alias = T[0];
}
it is quite helpful in templated code to be able to alias
_anything_
But yeah, no fun for mixins :(
Re: D daemon GC?
I had similar issues. Thing is D compiler places runtime cleanup initialization code into binary constructor sections (fini_array) which is needed to support shared libraries properly. But the same code gets triggered when you run `exit` in a fork resulting in attempt to terminate other process GC. There is an alternative _Exit function that should be used in forks instead. This is a link on topic given to me earlier by Martin Nowak : http://unix.stackexchange.com/questions/5364/why-should-a-child-of-a-vfork-or-fork-call-exit-instead-of-exit I am not 100% this is what causes your problems but seems possible.
Re: D daemon GC?
On Saturday, 30 August 2014 at 19:52:24 UTC, JD wrote: I tested it again, and it works fine in both 2.065 and 2.066. Be aware that you should comment out: // close(STDOUT_FILENO); // close(STDERR_FILENO); A daemon normally detaches itself from the terminal by closing the STD* files. All D's runtime exception messages will not appear in that case. At least theoretically, whatever happens in the parent should not affect the child, so I don't really believe it has something to do with the way exit() works. You can actually test this by making the parent not exit immediately, but sleep for some time. Good point. I'll try that. And just to be sure: have you tested your program without the call to daemonize? Yes, it writes a dot to the logfile every 2 seconds :-) Last snippet works for me, dots get printed to the logfile as expected.
Re: D1: Error: duplicate union initialization for size
On Sunday, 31 August 2014 at 02:53:35 UTC, Ali Çehreli wrote: On 08/30/2014 06:05 PM, jicman wrote: Really is or how one can fix it? This is the only time that I have found myself without answers with D. Strange. Maybe folks are not that into D1, but D1 was before D2. Any thoughts would be greatly appreciated. Even from Walter. :-) Thanks. I still think this is the same bug that I have linked before: https://issues.dlang.org/show_bug.cgi?id=8902 My guess is that it hasn't been ported to the D1 compiler yet. Dicebot or any other people who work for Sociomantic should be most helpful. At this point, I recommend that you ask on the main D forum. Ali I have not encountered such issue in our D1 codebase but I will forward this question to our internal chat on Monday
