Handling referencing class parent instances in a GC friendly way.
Hi,
class A{
A parent;
A[] items;
void myDestroy(){
items.each!(i => i.myDestroy);
parent = null;
// after this point I think the GC will release it
automatically, and it will call ~this() too. Am I right?
}
}
I have a hierarchy of class instances forward and backward linked
to its items ant its parent.
What is a proper way to destroy an instance of class A? Is
calling instance.myDestroy sufficient?
Am I right that this kind of uninitialization MUST not go into
the ~this() destructor, because of the references the instance is
holding, the system will never call the ~this()?
Or is there a better way for this type of thing in Dlang?
Thanks in advance!
Re: Handling referencing class parent instances in a GC friendly way.
On Monday, 30 November 2020 at 14:33:22 UTC, realhet wrote:
Hi,
class A{
A parent;
A[] items;
void myDestroy(){
items.each!(i => i.myDestroy);
parent = null;
// after this point I think the GC will release it
automatically, and it will call ~this() too. Am I right?
}
}
I have a hierarchy of class instances forward and backward
linked to its items ant its parent.
What is a proper way to destroy an instance of class A? Is
calling instance.myDestroy sufficient?
Am I right that this kind of uninitialization MUST not go into
the ~this() destructor, because of the references the instance
is holding, the system will never call the ~this()?
Or is there a better way for this type of thing in Dlang?
Thanks in advance!
The GC will release it anyways. The advantage of a GC is that it
is not deterred by cyclic references, so as soon as no more
references into A exist, it will disappear, no matter the parent
pointer.
At least, that's the theory - in practice, since we don't have
precise stack GC, any spurious or leftover pointer to an A can
keep the whole tree alive, so the myDestroy cleanup method is
still valid and recommended. Though you may want to do `items =
null;` too.
Re: Handling referencing class parent instances in a GC friendly way.
On Monday, 30 November 2020 at 14:36:08 UTC, FeepingCreature wrote: On Monday, 30 November 2020 at 14:33:22 UTC, realhet wrote: ... Though you may want to do `items = null;` too. I just forgot 1 of three things, thx for pointing it out. And I also forget to notify the parent to remove the reference from its items list.
Local libraries/packages with dub: How?
How does one set up a dub package so that it contains multiple sublibraries that may or may not depend on these same libraries?(but never co-dependant) So far i've tried using add-local and add-path with subpackage declarations in the root folder's dub.sdl but to no avail. (dub does not complain but silently doesn't add dependencies with -v, dmd just errors out with the standard file not found error "module y is in file y.d which cannot be read", with the path of my libraries absent from import paths.) Alternatively, is there an equivalent of -version= for DUB's build command?(for when a package author didn't add a config that incorporates the desired versions.) Big thanks and my apologies if this is the wrong place for DUB discussion.
Re: Local libraries/packages with dub: How?
dub add-local, adds a directory as a known package that it can use as a
dependency (or to be executed).
You need to specify in the package that depends on the dependency what
dependencies you have.
I.e.
See the dependencies key:
{
"name": "myproject",
"description": "A little web service of mine.",
"authors": ["Peter Parker"],
"homepage": "http://myproject.example.com";,
"license": "GPL-2.0",
"dependencies": {
"vibe-d": "~>0.7.23"
}
}
See[0] how to specify the dependency itself.
To have different sets of dependencies/code you can use sub packages or
configurations. But I would suggest to just focus on one set for now,
while you are getting the hang of the basics.
[0] https://dub.pm/package-format-json#version-specs
Re: Local libraries/packages with dub: How?
On Tuesday, 1 December 2020 at 04:50:03 UTC, rikki cattermole
wrote:
...
What puzzles me is that the dependencies are indeed declared, but
"dub describe" refuses to recognize the dependencies and "dub
build" fails.
"dub list" does recognize the root folder, but trying to get a
subpackage to import another fails because the dependency isn't
imported.(dmd only sees the "source" and phobos/runtime import
paths)
The root dub.sdl roughly contains this :
name "fldr"
dependencies "fldr:spkg1" "fldr:spkg2" "fldr:spkg3" // tried
with and without "fldr:"
subPackage "./spkg1/"
subPackage "./spkg2/"
subPackage "./spkg3/"
targetType "none"
While for example, "spkg3"'s dub.sdl contains this :
name "spkg3"
dependencies "fldr:spkg2"
And its source/*.d file contains this :
import std.stdio, fldr.spkg2; //tried with and without "fldr."
void main() {writeln(«function from spkg2»)}
Re: Selective unittesting in DUB
On Wednesday, 21 December 2016 at 19:49:20 UTC, Jacob Carlborg wrote: On 2016-12-21 19:07, Nordlöw wrote: Is there a way to specify in dub.json (or any other file) that only a subset of the sources compiled and linked to a library or app should have they're unittests enabled? You can use the "unittest" configuration in Dub to add or remove files, but I don't think you can disable some of the unittest blocks in a single module. There's also unit-threaded [1] which allows you to run specific unit tests. [1] https://github.com/atilaneves/unit-threaded I was looking for an answser to that question I am sorry but this should be supported out of the box Nobody should have to download ton of dependencies to make such basic and needed feature to work... i should be able to do: dub test src/module.d ... this is very disappointing
Re: Selective unittesting in DUB
Running .\dawn-test-application.exe 2 modules passed unittests Wich ones? it should print ``` Running tests for target X - src/module_a.d Tests: OK <-- line in green - src/module_b.d Tests: OK - src/module_c.d Tests: OK - src/module_e.d Tests: FAIL <-- line in red 3 modules passed, 1 failed ```
Re: How to bundle a GtkD application for Windows
On Sunday, 29 November 2020 at 20:08:33 UTC, adnan449 wrote: Hello, I would be greatly thankful if I was given an easy guide on how to produce windows executables for GtkD applications. I do not have an access to a windows machine but I need to be able to produce installers/exe files for the windows users. Users should not have to install any dependency manually to be able to install my program. Thank you. A useful tip. Assuming one has a list of dependent dlls. https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer The subfolder gtk-nsis-pack contains a required folder structure if you want to use theme support etc. Simply put your gtkd exe in the bin folder. You can remove redundant dlls from the bin folder to obtain a minimal bundle for your program. The NSIS project structure may also help to create an installer for your program.
Re: Local libraries/packages with dub: How?
On 01/12/2020 7:39 PM, z wrote:
On Tuesday, 1 December 2020 at 04:50:03 UTC, rikki cattermole wrote:
...
What puzzles me is that the dependencies are indeed declared, but "dub
describe" refuses to recognize the dependencies and "dub build" fails.
"dub list" does recognize the root folder, but trying to get a
subpackage to import another fails because the dependency isn't
imported.(dmd only sees the "source" and phobos/runtime import paths)
The root dub.sdl roughly contains this :
name "fldr"
dependencies "fldr:spkg1" "fldr:spkg2" "fldr:spkg3" // tried with and
without "fldr:"
That isn't right.
dependency "fldr:spkg1" version="*"
dependency "fldr:spkg2" version="*"
dependency "fldr:spkg3" version="*"
subPackage "./spkg1/"
subPackage "./spkg2/"
subPackage "./spkg3/"
targetType "none"
That probably isn't what you want. Either library or executable.
Either that, or you shouldn't be adding the dependencies.
While for example, "spkg3"'s dub.sdl contains this :
name "spkg3"
dependencies "fldr:spkg2"
dependency "fldr:spkg2" version="*"
And its source/*.d file contains this :
import std.stdio, fldr.spkg2; //tried with and without "fldr."
void main() {writeln(«function from spkg2»)}
Don't forget to specify the module name. Every file should declare its
module full package + module name.
So in this case ``module fldr.spkg2;``.
Selective unittesting in DUB
https://forum.dlang.org/post/owhmsgkhszkwcjkxl...@forum.dlang.org
On Wednesday, 21 December 2016 at 18:07:23 UTC, Nordlöw wrote:
Is there a way to specify in dub.json (or any other file) that
only a subset of the sources compiled and linked to a library
or app should have they're unittests enabled?
Check this one:
app.d
--
Version ( DoubleBuffer )
{
unittest
{
// ...
}
}
else
{
unittest
{
// ...
}
}
or
unittest
{
Version ( DoubleBuffer )
{
// ...
}
// ...
}
dub.json
{
...,
"buildTypes":
{
"debug":
{
"versions": [ "DoubleBuffer" ]
}
}
}
How to specify "DoubleBuffer" via dub's command line?...
I think you can improve the dub.
Re: Selective unittesting in DUB
On Wednesday, 21 December 2016 at 18:07:23 UTC, Nordlöw wrote:
Is there a way to specify in dub.json (or any other file) that
only a subset of the sources compiled and linked to a library
or app should have they're unittests enabled?
Check this one:
app.d
--
Version ( DoubleBuffer )
{
unittest
{
// ...
}
}
else
{
unittest
{
// ...
}
}
or
unittest
{
Version ( DoubleBuffer )
{
// ...
}
// ...
}
dub.json
{
...,
"buildTypes":
{
"debug":
{
"versions": [ "DoubleBuffer" ]
}
}
}
Or may be "pragma" can help you...
version ( Windows )
{
pragma( lib, "gdi32.lib" );
}
How to specify "DoubleBuffer" via dub's command line?...
