Re: public vs private alias this
On Tuesday, 1 November 2022 at 23:01:57 UTC, Per Nordlöw wrote:
When is it preferrable to use
```d
struct S { private T t; alias t this; }
```
instead of
```d
struct S { public T t; alias t this; }
```
for any given type `T`?
If the `alias this` needs to work outside the module where `S` is
defined, you must make the member variable `public`. So in almost
all cases, the second form is the correct one.
Re: Make IN Dlang
Something to consider: dub can be used as a library. You can add your own logic in main to allow using your build specification to generate a dub file (either in memory or in file system).
Re: Make IN Dlang
On Tuesday, 1 November 2022 at 23:40:22 UTC, Christian Köstlin wrote: Dear dlang-folk, one of the tools I always return to is rake (https://ruby.github.io/rake/). For those that do not know it, its a little like make in the sense that you describe your build as a graph of tasks with dependencies between them, but in contrast to make the definition is written in a normal programming language (in this case ruby) with all features of it. [...] Sounds pretty similar to [tup](https://gittup.org/tup/) Reggae, the build system mentioned by Adam, supports tup as a backend, so you could use that as well
Re: Make IN Dlang
I don't have specific answers to your questions but your goal sounds similar to Atila's reggae project so it might be good for you to take a look at: https://code.dlang.org/packages/reggae
Make IN Dlang
Dear dlang-folk,
one of the tools I always return to is rake
(https://ruby.github.io/rake/). For those that do not know it, its a
little like make in the
sense that you describe your build as a graph of tasks with dependencies
between them, but in contrast to make the definition is written in
a normal programming language (in this case ruby) with all features of
it.
Dlang is also quite expressive, so I thought why not define the build in
Dlang.
The result is mind (https://gitlab.com/gizmomogwai/mind). An example
mindfile looks like this:
```
#!/usr/bin/env dub
/+ dub.sdl:
name "mindfile"
dependency "mind" version="~master"
...further dependencies...
+/
import mind;
import std.stdio : writeln;
import std.format : format;
import std.range : iota;
import std.algorithm : map;
import std.array : array;
import core.thread.osthread : Thread;
import core.time : msecs;
int main(string[] args)
{
description("Do all");
auto all = task("all", null, (t) {});
for (int i=0; i<1000; ++i)
{
auto fileName = "out/file-%s.txt".format(i);
all.enhance(fileName);
description(fileName);
file(fileName, null, (t)
{
Thread.sleep(100.msecs);
sh("touch %s".format(t.name));
},
);
}
return mindMain(args);
}
```
This uses dub's single file feature
(https://dub.pm/advanced_usage#single-file) to get the helper library
and "execution engine" (mind).
The main functions defines a bunch of tasks or file-tasks and finally
forwards to the main function of the library for parallel (if possible)
execution of the tasks.
At the moment this is still in an experimental stage, but has nice
features such as:
- colorized --help (thanks to argparse)
- --tasks to show all defined (and commented tasks)
- parallel execution
I am still trying to find answers to the following questions:
1. Is it somehow possible to get rid of the dub single file scheme, and
e.g. interpret a full dlang script at runtime?
2. How can the program as is made nicer/shorter? (one could just import
std, or make use of https://code.dlang.org/packages/scriptlike)?
3. Does this make sense at all, or should we just use make/rake? (dub
also uses a custom build.d file).
Kind regards,
Christian
public vs private alias this
When is it preferrable to use
```d
struct S { private T t; alias t this; }
```
instead of
```d
struct S { public T t; alias t this; }
```
for any given type `T`?
Re: druntime thread (from foreach parallel?) cleanup bug
On Tuesday, 1 November 2022 at 19:49:47 UTC, mw wrote: On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer wrote: [...] Maybe the hunt library author doesn't know. (My code does not directly use this library, it got pulled in by some other decencies.) [...] Please, if you see anything in the docs that needs to be updated, make a PR right away <3 Documentation saves lives! The times I have thought "I'll do it later" have been too many.
Re: druntime thread (from foreach parallel?) cleanup bug
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer wrote: Oh yeah, isDaemon detaches the thread from the GC. Don't do that unless you know what you are doing. As discussed on discord, this isn't actually true. All it does is prevent the thread from being joined before exiting the runtime. What is *likely* happening is, the runtime shuts down. That thread is still running, but the D runtime is gone. So it eventually starts trying to do something (like let's say, access thread local storage), and it's gone. Hence the segfault. -Steve
Re: druntime thread (from foreach parallel?) cleanup bug
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer
wrote:
And I just noticed, one of the thread trace points to here:
https://github.com/huntlabs/hunt/blob/master/source/hunt/util/DateTime.d#L430
```
class DateTime {
shared static this() {
...
dateThread.isDaemon = true; // not sure if this is
related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like
someone run into this (cleanup) issue already, but unable to
fix it.
Anyway I logged an issue there:
https://github.com/huntlabs/hunt/issues/96
Oh yeah, isDaemon detaches the thread from the GC. Don't do
that unless you know what you are doing.
Maybe the hunt library author doesn't know. (My code does not
directly use this library, it got pulled in by some other
decencies.)
Currently, the `isDaemon` doc does not mention this about this:
https://dlang.org/library/core/thread/threadbase/thread_base.is_daemon.html
Sets the daemon status for this thread. While the runtime will
wait for all normal threads to complete before tearing down the
process, daemon threads are effectively ignored and thus will not
prevent the process from terminating. In effect, daemon threads
will be terminated automatically by the OS when the process exits.
Maybe we should add to the doc?
BTW, what is exactly going wrong with their code?
I saw the tick() method call inside the anonymous `dateThread` is
accessing these two stack variables of shared static this():
https://github.com/huntlabs/hunt/blob/master/source/hunt/util/DateTime.d#L409
Appender!(char[])[2] bufs;
const(char)[][2] targets;
Why does this tick() call work after the static this() finished
in a normal run?
Why the problem only shows up when program finish?
Re: druntime thread (from foreach parallel?) cleanup bug
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer wrote: Oh yeah, isDaemon detaches the thread from the GC. Don't do that unless you know what you are doing. As discussed on discord, this isn't true actually. All it does is prevent the thread from being joined before exiting the runtime. What is *likely* happening is, the runtime shuts down. That thread is still running, but the D runtime is gone. So it eventually starts trying to do something (like let's say, access thread local storage), and it's gone. Hence the segfault. -Steve
Re: druntime thread (from foreach parallel?) cleanup bug
On 11/1/22 1:47 PM, mw wrote:
Can you show a code snippet that includes the parallel foreach?
(It's just a very straight forward foreach on an array; as I said it may
not be relevant.)
And I just noticed, one of the thread trace points to here:
https://github.com/huntlabs/hunt/blob/master/source/hunt/util/DateTime.d#L430
```
class DateTime {
shared static this() {
...
dateThread.isDaemon = true; // not sure if this is related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like someone run
into this (cleanup) issue already, but unable to fix it.
Anyway I logged an issue there:
https://github.com/huntlabs/hunt/issues/96
Oh yeah, isDaemon detaches the thread from the GC. Don't do that unless
you know what you are doing.
-Steve
Re: druntime thread (from foreach parallel?) cleanup bug
Can you show a code snippet that includes the parallel foreach?
(It's just a very straight forward foreach on an array; as I said
it may not be relevant.)
And I just noticed, one of the thread trace points to here:
https://github.com/huntlabs/hunt/blob/master/source/hunt/util/DateTime.d#L430
```
class DateTime {
shared static this() {
...
dateThread.isDaemon = true; // not sure if this is related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like someone
run into this (cleanup) issue already, but unable to fix it.
Anyway I logged an issue there:
https://github.com/huntlabs/hunt/issues/96
Re: druntime thread (from foreach parallel?) cleanup bug
On Tue, Nov 01, 2022 at 10:37:57AM -0700, Ali Çehreli via Digitalmars-d-learn wrote: > On 11/1/22 10:27, H. S. Teoh wrote: > > > Maybe try running Digger to reduce the code for you? > > Did you mean dustmite, which is accessible as 'dub dustmite > ' but I haven't used it. Oh yes, sorry, I meant dustmite, not digger. :-P > My guess for the segmentation fault is that the OP is executing > destructor code that assumes some members are alive. If so, the code > should be moved from destructors to functions to be called like > obj.close(). But it's just a guess... [...] Yes, that's a common gotcha. T -- We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
Re: druntime thread (from foreach parallel?) cleanup bug
On 11/1/22 10:27, H. S. Teoh wrote: > Maybe try running Digger to reduce the code for you? Did you mean dustmite, which is accessible as 'dub dustmite ' but I haven't used it. My guess for the segmentation fault is that the OP is executing destructor code that assumes some members are alive. If so, the code should be moved from destructors to functions to be called like obj.close(). But it's just a guess... Ali
Re: druntime thread (from foreach parallel?) cleanup bug
On Tue, Nov 01, 2022 at 05:19:56PM +, mw via Digitalmars-d-learn wrote:
> My program received signal SIGSEGV, Segmentation fault.
>
> Its simplified structure looks like this:
>
> ```
> void foo() {
> ...
> writeln("done"); // saw this got printed!
> }
>
> int main() {
> foo();
> return 0;
> }
>
> ```
Can you show a code snippet that includes the parallel foreach? Because
the above code snippet is over-simplified to the point it's impossible
to tell what the original problem might be, since obviously calling a
function that calls writeln would not crash the program.
Maybe try running Digger to reduce the code for you?
T
--
Never step over a puddle, always step around it. Chances are that whatever made
it is still dripping.
druntime thread (from foreach parallel?) cleanup bug
My program received signal SIGSEGV, Segmentation fault.
Its simplified structure looks like this:
```
void foo() {
...
writeln("done"); // saw this got printed!
}
int main() {
foo();
return 0;
}
```
So, just before the program exit, it failed. I suspect druntime
has a thread (maybe due to foreach parallel) cleanup bug
somewhere, which is unrelated to my own code. This kind of bug is
hard to re-produce, not sure if I should file an issue.
I'm using: LDC - the LLVM D compiler (1.30.0) on x86_64.
Under gdb, here is the threads info (for the record):
Thread 11 "xxx" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x153df700 (LWP 36258)]
__GI___res_iclose (free_addr=true, statp=0x153dfdb8) at
res-close.c:103
103 res-close.c: No such file or directory.
(gdb) info threads
Id Target Id Frame
1Thread 0x15515000 (LWP 36244) "lt" 0x10af1d2d
in __GI___pthread_timedjoin_ex (threadid=23456246527744,
thread_return=0x0, abstime=0x0, block=) at
pthread_join_common.c:89
* 11 Thread 0x153df700 (LWP 36258) "lt" __GI___res_iclose
(free_addr=true, statp=0x153dfdb8) at res-close.c:103
17 Thread 0x155544817700 (LWP 36264) "lt" 0x10afac70
in __GI___nanosleep (requested_time=0x155544810e90,
remaining=0x155544810ea8) at
../sysdeps/unix/sysv/linux/nanosleep.c:28
(gdb) thread 1
[Switching to thread 1 (Thread 0x15515000 (LWP 36244))]
#0 0x10af1d2d in __GI___pthread_timedjoin_ex
(threadid=23456246527744, thread_return=0x0, abstime=0x0,
block=) at pthread_join_common.c:89
89 pthread_join_common.c: No such file or directory.
(gdb) where
#0 0x10af1d2d in __GI___pthread_timedjoin_ex
(threadid=23456246527744, thread_return=0x0, abstime=0x0,
block=) at pthread_join_common.c:89
#1 0x55fb94f8 in
core.thread.osthread.joinLowLevelThread(ulong) ()
#2 0x55fd7210 in
_D4core8internal2gc4impl12conservativeQw3Gcx15stopScanThreadsMFNbZv ()
#3 0x55fd3ae7 in
_D4core8internal2gc4impl12conservativeQw3Gcx4DtorMFZv ()
#4 0x55fd3962 in
_D4core8internal2gc4impl12conservativeQw14ConservativeGC6__dtorMFZv ()
#5 0x55fc2ce7 in rt_finalize2 ()
#6 0x55fc0056 in rt_term ()
#7 0x55fc0471 in
_D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv ()
#8 0x55fc0356 in _d_run_main2 ()
#9 0x55fc01ae in _d_run_main ()
#10 0x55840c02 in main (argc=2, argv=0x7fffe188) at
//home/zhou/project/ldc2-1.30.0-linux-x86_64/bin/../import/core/internal/entrypoint.d:42
#11 0x10163b97 in __libc_start_main (main=0x55840be0
, argc=2, argv=0x7fffe188, init=,
fini=, rtld_fini=,
stack_end=0x7fffe178)
at ../csu/libc-start.c:310
#12 0x556dccca in _start ()
(gdb) thread 11
[Switching to thread 11 (Thread 0x153df700 (LWP 36258))]
#0 __GI___res_iclose (free_addr=true, statp=0x153dfdb8) at
res-close.c:103
103 res-close.c: No such file or directory.
(gdb) where
#0 __GI___res_iclose (free_addr=true, statp=0x153dfdb8) at
res-close.c:103
#1 res_thread_freeres () at res-close.c:138
#2 0x102de8c2 in __libc_thread_freeres () at
thread-freeres.c:29
#3 0x10af0700 in start_thread (arg=0x153df700) at
pthread_create.c:476
#4 0x10263a3f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 17
[Switching to thread 17 (Thread 0x155544817700 (LWP 36264))]
#0 0x10afac70 in __GI___nanosleep
(requested_time=0x155544810e90, remaining=0x155544810ea8) at
../sysdeps/unix/sysv/linux/nanosleep.c:28
28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or
directory.
(gdb) where
#0 0x10afac70 in __GI___nanosleep
(requested_time=0x155544810e90, remaining=0x155544810ea8) at
../sysdeps/unix/sysv/linux/nanosleep.c:28
#1 0x55fb8c3b in
_D4core6thread8osthread6Thread5sleepFNbNiSQBo4time8DurationZv ()
#2 0x55d9a0c2 in
_D4hunt4util8DateTimeQj25_sharedStaticCtor_L406_C5FZ9__lambda4MFZv () at home/zhou/.dub/packages/hunt-1.7.16/hunt/source/hunt/util/DateTime.d:430
#3 0x55fb89f4 in thread_entryPoint ()
#4 0x10af06db in start_thread (arg=0x155544817700) at
pthread_create.c:463
#5 0x10263a3f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Re: A strange DMD error
This reminds me of an issue i reported last year... https://issues.dlang.org/show_bug.cgi?id=22583
Re: A strange DMD error
On 11/1/22 11:40 AM, Keivan Shah wrote:
Hello,
Today I came across a strange bug while using D with `dmd`. I have still
not been able to figure out under what conditions does it happen but it
seems to be a DMD related bug to me. Here is a reproducible snippet of
the code
```D
import std;
alias DG = void delegate();
class TType
{
}
class MyClass
{
this(TType t1, TType, double, double[2], double, double, DG, TType,
TType,
DG, DG, DG, double, double, double, double, double, ulong,
bool)
{
assert(t1 is null); // I am passing null so should be null!
// NOTE: Seems to work in LDC but fails in DMD.
writeln("No Bug!");
}
}
void main()
{
auto tt = new TType;
new MyClass(null, tt, 0, [0, 0], 0, 0, null, null, null, null,
null, null,
0, 0, 0, 0, 0, 0, false);
}
```
The code gives an assertion failure on the current versions of dmd
(reproducible on [run.dlang.io](https://run.dlang.io) as well) and does
not happen when using LDC. The bug seems to be sensitive to the number
of arguments and their types making it reproducible only in very limited
cases. I have tried my best to reduce it to minimum but still does
require these many arguments. The end results seems to me like variables
are shifted i.e. variable 1 gets value of variable 2 and so on, but
don't have enough proof to support this.
100% this is a bug in DMD. It should be filed.
I ran some more tests, removing almost any of the parameters or changing
their types seems to avoid the problem.
I also added a parameter name for the second parameter, and DMD appears
to be in this case passing the parameters in the wrong order (t1 is
actually tt, t2 is null)
You can also remove the `import std`, just the assert is enough.
Please file if you can: https://issues.dlang.org
-Steve
Re: A strange DMD error
On Tuesday, 1 November 2022 at 15:49:54 UTC, Keivan Shah wrote: On Tuesday, 1 November 2022 at 15:42:43 UTC, Imperatorn wrote: On Tuesday, 1 November 2022 at 15:40:04 UTC, Keivan Shah wrote: Hello, Today I came across a strange bug while using D with `dmd`. I have still not been able to figure out under what conditions does it happen but it seems to be a DMD related bug to me. Here is a reproducible snippet of the code [...] Could be there's some restriction in DMD on number of arguments. May I ask if this was just an experiment? I hope you're not having code like that in the wild Possible, but I think I have had code with more arguments than this and it has worked Unfortunately, not an experiment. Although have replaced the types so seems silly now, this is part of my constructor for a huge co-coordinator class that takes too many configurable start time parameters and so need to pass these many arguments. Keivan Regarding the too many configurable parameters, the general advice is to group all of the params into a `struct` and pass that instead as argument to constructor Pretty wild bug though, definitely a backend thing
Re: A strange DMD error
On Tuesday, 1 November 2022 at 16:06:44 UTC, Imperatorn wrote: Hehe. One simple thing you could do is to create a struct instead for you params and pass that Yeah, can do, thanks for the suggestion. But anyways still want to see if anyone else has seen this issue, or has a clue about what could be happening here. Seems like a rare issue and took up too much of my time so better if it's solved or at least documented somewhere in the meantime. I have filed an issue for this now: https://issues.dlang.org/show_bug.cgi?id=23450
Hipreme's #3 Tip of the day - Changing DMD linker on Windows
The linker used on Windows when installing DMD is pretty much decided on how your PC was setup. - If you had Visual Studio installed on your windows for "Desktop Development with C++" before downloading DMD (from the site and setup), you will pretty have MSVC Linker as a default. - If you installed DMD before Visual Studio without that extension, your default linker will be LLD linker. There is 2 ways to change your linker for DMD: 1. Open a Command Prompt and type `set LINKCMD=path\to\the\linker`. 2. Open your D windows installation folder (usually C:\D\dmd2\windows\bin), and edit `sc.ini`. There will be [Environment]. Below [Environment], you just type the same thing as above. So basically, for my folder system, I can use both: **LLD**: `LINKCMD=C:\D\dmd2\windows\bin\lld-link.exe` **MSVC**: `LINKCMD=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\Hostx86\x64\link.exe` Notice that there is no `""` (string literal), although you can find that on other places, that actually causes an error on windows. This can be useful for making your program link faster (lld is well known for that). But there are cases that you're going to need the MSVC one. Specially today that I was getting the error while trying to build with LLD: Error 0xc7b “Application was unable to start correctly” This was solved after changing my linker back to MSVC.
Re: A strange DMD error
On Tuesday, 1 November 2022 at 15:49:54 UTC, Keivan Shah wrote: On Tuesday, 1 November 2022 at 15:42:43 UTC, Imperatorn wrote: On Tuesday, 1 November 2022 at 15:40:04 UTC, Keivan Shah wrote: [...] Could be there's some restriction in DMD on number of arguments. May I ask if this was just an experiment? I hope you're not having code like that in the wild Possible, but I think I have had code with more arguments than this and it has worked Unfortunately, not an experiment. Although have replaced the types so seems silly now, this is part of my constructor for a huge co-coordinator class that takes too many configurable start time parameters and so need to pass these many arguments. Keivan Hehe. One simple thing you could do is to create a struct instead for you params and pass that
Re: Can't seem to find the relevant documentation for dub.
On Monday, 31 October 2022 at 20:31:11 UTC, ryuukk_ wrote: On Monday, 31 October 2022 at 20:20:49 UTC, WhatMeWorry wrote: I've got a pretty straightforward SDL dub file dependency "bindbc-opengl"version="~>1.0.3" versions "GL_46" dependency "bindbc-glfw" version="~>1.0.1" versions "GLFW_33" dependency "gl3n" version="~>1.4.1" dependency "bindbc-freeimage" version="~>0.1.1" versions "FI_317" Unresolvable dependencies to package bindbc-loader: bindbc-freeimage 0.1.1 depends on bindbc-loader ~>0.2.1 bindbc-freeimage 0.1.1 depends on bindbc-loader ~>0.2.1 bindbc-glfw 1.0.1 depends on bindbc-loader ~>1.0.0 bindbc-glfw 1.0.1 depends on bindbc-loader ~>1.0.0 bindbc-opengl 1.0.3 depends on bindbc-loader ~>1.0.0 ..\duball.exe exited with code 2 How to I tell dub that I want some packages to use different versions of the same package, bindbc-loader, in this case? You are using a very old version of freeimage, i suggest upgrading to the the latest one: 1.0.2 - https://code.dlang.org/packages/bindbc-freeimage Thank you. Specifying the newest freeimage package solved the problem. But now bindbc-assimp wants an older version of bindbc-loader but bindbc-assimp is at the most recent version. So is there a way to specify bindbc-loader ~>0.2.1 just for bindbc-assimp? Unresolvable dependencies to package bindbc-loader: bindbc-assimp 0.0.1 depends on bindbc-loader ~>0.2.1 bindbc-freeimage 1.0.2 depends on bindbc-loader ~>1.0.0 bindbc-glfw 1.0.1 depends on bindbc-loader ~>1.0.0 bindbc-opengl 1.0.3 depends on bindbc-loader ~>1.0.0 ..\duball.exe exited with code 2
Re: A strange DMD error
On Tuesday, 1 November 2022 at 15:42:43 UTC, Imperatorn wrote: On Tuesday, 1 November 2022 at 15:40:04 UTC, Keivan Shah wrote: Hello, Today I came across a strange bug while using D with `dmd`. I have still not been able to figure out under what conditions does it happen but it seems to be a DMD related bug to me. Here is a reproducible snippet of the code [...] Could be there's some restriction in DMD on number of arguments. May I ask if this was just an experiment? I hope you're not having code like that in the wild Possible, but I think I have had code with more arguments than this and it has worked Unfortunately, not an experiment. Although have replaced the types so seems silly now, this is part of my constructor for a huge co-coordinator class that takes too many configurable start time parameters and so need to pass these many arguments. Keivan
Re: A strange DMD error
On Tuesday, 1 November 2022 at 15:40:04 UTC, Keivan Shah wrote: Hello, Today I came across a strange bug while using D with `dmd`. I have still not been able to figure out under what conditions does it happen but it seems to be a DMD related bug to me. Here is a reproducible snippet of the code [...] Could be there's some restriction in DMD on number of arguments. May I ask if this was just an experiment? I hope you're not having code like that in the wild
A strange DMD error
Hello,
Today I came across a strange bug while using D with `dmd`. I
have still not been able to figure out under what conditions does
it happen but it seems to be a DMD related bug to me. Here is a
reproducible snippet of the code
```D
import std;
alias DG = void delegate();
class TType
{
}
class MyClass
{
this(TType t1, TType, double, double[2], double, double, DG,
TType, TType,
DG, DG, DG, double, double, double, double, double,
ulong, bool)
{
assert(t1 is null); // I am passing null so should be
null!
// NOTE: Seems to work in LDC but fails in DMD.
writeln("No Bug!");
}
}
void main()
{
auto tt = new TType;
new MyClass(null, tt, 0, [0, 0], 0, 0, null, null, null,
null, null, null,
0, 0, 0, 0, 0, 0, false);
}
```
The code gives an assertion failure on the current versions of
dmd (reproducible on [run.dlang.io](https://run.dlang.io) as
well) and does not happen when using LDC. The bug seems to be
sensitive to the number of arguments and their types making it
reproducible only in very limited cases. I have tried my best to
reduce it to minimum but still does require these many arguments.
The end results seems to me like variables are shifted i.e.
variable 1 gets value of variable 2 and so on, but don't have
enough proof to support this.
I just wanted some help on the best way to avoid this bug in my
code and maybe some clue on what causes the error in the first
place and how should I go about reporting this.
Keivan
