Re: Why many programmers don't like GC?
On Monday, 18 January 2021 at 01:41:35 UTC, James Blachly wrote: Those were not aberba's words, but the author of the first link, in which one does find a conceptual, high level description of GC. I read it, it said nothing of relevance to the D collector. That is not TLDR informative.
Re: native way to tell if output binary is library or executable?
On Monday, 18 January 2021 at 02:24:59 UTC, Jack wrote: I know I can set version but I'd looking for a native way, if any, to do that. Is possible to tell if output binary is library or executable at compile time? then I'd call different version of a function. Add `-version=library` to your compiler flags for the library and `-version=executable` to your compiler flags for the executable. Then, in the code, you can check for `version (library)` and `version (executable)`. Before you ask: no, there is no "more native" way to do this, because there is actually no difference in how the code is compiled between the two versions. The distinction between library and executable is only made when the compiled code is linked.
native way to tell if output binary is library or executable?
I know I can set version but I'd looking for a native way, if any, to do that. Is possible to tell if output binary is library or executable at compile time? then I'd call different version of a function.
Re: Why many programmers don't like GC?
On 1/15/21 4:55 PM, Ola Fosheim Grøstad wrote: On Friday, 15 January 2021 at 21:18:55 UTC, aberba wrote: TL;DR: In summation, the garbage collection system is a robust part of Unreal Engine that affords C++ programmers a lot of safety from memory leaks, as well as convenience. With this high-level discussion, I was aiming to introduce the system at a conceptual level, and I hope I have achieved that. What is your conceptual level? You haven't described what it does, and does not do. But yes, frameworks need that allow "scripting" in some shape or form (compiled or not) has to hide internal structures and intricacies and provide some convenience. Those were not aberba's words, but the author of the first link, in which one does find a conceptual, high level description of GC.
Re: Static constructor
Thanks, as explained I am indeed porting old code.
No on the AA (as noted above). The mutex *is* created on
demand. Every Object can have a mutex, and it's only created
when you synchronize it for the first time.
Yes alright. I think the dev made a design mistake because he
called synchronized( OpenAL.mutex ) when it should be more of a
global, non OpenAL specific, mutex. I mean in the code there were
things like (pseudo-code)
---
System {
private int[] buffer
func() {
synch (openal.mutex)
{
openal.dosmthg (buffer)
buffer.change() // buffer being the member of System
openal.dosmthg(buffer)
}
}
}
---
Basically, it's the entire buffers handling ( the 3 statements)
which should be done the "atomic" way, not just the calls to
openAL. So the mutex should be a member variable of System at
worse. I just replaced
synchronized ( openal.mutex ) {
by
synchronized { // create a global mutex
Of course synchronized (open.mutex) would probably work, but
getting the mutex of an abstract class which is used only in part
of the calls looks like a design error to me!
I would say the AA initialization is standard D. Using the
class as a namespace isn't standard or necessary. If anything,
it should be a struct, or you can use a template. But I can't
see why you can't just use a module.
I replaced the AA entirely (by a switch in a nested function!).
Got rid of the static init() then.
I replaced 'class' by 'struct', which does not oblige me to
change the entire code using the syntax "OpenAL.smthg" . But I
was tempted to go to the next step:
import OpenAL = ...openal; // should not have to change any code
either if it works!
I just have to verify all the imports in the other modules and I
can delete the "struct OpenAL" scope. I don't have enough
experience in D2 to think about the impact of such a change
though, ie from *
---
// openal.d file
module a.b.OpenAL
struct OpenAL{ void dosmthg()}
// another file
import a.b.OpenAL
OpenAL.dosmthg()
---
to ***
---
// openal.d file
module a.b.OpenAL
void dosmthg()
// another file
import OpenAL = a.b.OpenAL
OpenAL.dosmthg()
---
Thanks again for all the info so far. Learning a lot.
Re: Generating documentation help
On Sunday, 17 January 2021 at 21:48:20 UTC, Paul Backus wrote: I recommend using adrdox instead: note you should be able to just dub run adrdox and it will spit out `generated_docs/files...` (assuming i haven't broken that recently)
Re: Template argument deduction not working with template specialization
I just figured out half of my frustration is caused by a
collision between the 'alias this'd template possibillity and the
normal one.
For example:
struct Bar(uint size, V) {
V[size] blup;
alias blup this;
}
void foo(S : T[], T)(S a) {
pragma(msg, "first");
}
void foo(S : Bar!(T, U), uint T, U)(S a) {
pragma(msg, "second");
}
Bar!(2, int) bar;
foo(bar);
Will cause "called with argument types `(Bar!(2u, int))` matches
both:DUB"
(And "undefined identifier `T`DUB", "undefined identifier
`U`DUB", but thats a false positive :/)
While removal of either will make it work fine, as would removal
of the alias.
Templating:
The template picked to instantiate is the one that is most
specialized that fits the types of the TemplateArgumentList.
Alias this:
If an aggregate declaration defines an opCmp or opEquals
method, it will take precedence to that of the aliased this
member.
I was of the impression D only defaulted to the alias when the
original implementation of a (member) function was missing /
disfunctional. Shouldn't aliasing also follow this logic when
using template specializations? (Even though it may not be a
member function)
Re: Generating documentation help
On Sunday, 17 January 2021 at 21:07:31 UTC, Tim wrote: Hi there, I have a couple of (probably) fairly simple questions. First, when I generate documentation files (-Dd docs) for my project, it also generates documentation for the library Mir. How can I fix the compiler pulling in those docs as well? It seems that D won't let me document class constructors. This is a problem as I'd like to be able to document the constructor parameters. If I put the class documentation above the class definition, then ddoc gives an error that the parameters specified can't be found. Thanks DDoc has a number of annoying bugs like this, and as far as I know it isn't really maintained, so they are unlikely to be fixed any time soon. I recommend using adrdox instead: https://code.dlang.org/packages/adrdox
Generating documentation help
Hi there, I have a couple of (probably) fairly simple questions. First, when I generate documentation files (-Dd docs) for my project, it also generates documentation for the library Mir. How can I fix the compiler pulling in those docs as well? It seems that D won't let me document class constructors. This is a problem as I'd like to be able to document the constructor parameters. If I put the class documentation above the class definition, then ddoc gives an error that the parameters specified can't be found. Thanks
Re: Template argument deduction not working with template specialization
On 1/17/21 3:41 PM, Paul wrote: On Sunday, 17 January 2021 at 16:42:27 UTC, Steven Schveighoffer wrote: This works: void TFoo(T : U[], U)(T a) Oh cool, that's surprising to say the least. Thanks! This indeed works with argument deduction :) It's basically saying if T matches the pattern U[] for some U (which is actually defined now inside the function), then it's a match (and preferred over the non-specialized template). -Steve
Re: using dub and -checkaction=context
On 1/17/21 2:27 PM, Anonymouse wrote: On Sunday, 17 January 2021 at 15:41:45 UTC, Steven Schveighoffer wrote: I'm trying to run unittests using `dub test`, and I wanted to use the new -checkaction=context feature to avoid having to instrument my unittests to print out the string comparison failure that's happening. But I tried adding this to my dub.sdl file: dflags "-checkaction=context" platform="dmd" But now I get linker errors: /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/source/vibe/appmain.d:(.text._D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv[_D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv]+0x5c): undefined reference to `_D4core8internal7dassert__T14_d_assert_failVAyaa1_3eTmTiZQBeFNaNbNiNfKxmxiZQBf' https://issues.dlang.org/show_bug.cgi?id=19937 ? Slightly different error message though. Yeah, that's probably it. Hm... this feature isn't very usable if I can't use it with dub. And the bug report you linked to also has an example that fails with straight dmd (even without unittests). -Steve
Re: Template argument deduction not working with template specialization
On Sunday, 17 January 2021 at 16:42:27 UTC, Steven Schveighoffer wrote: I've always hated that aspect of specialization. I don't really understand why it's valid (how can T be T[]?) I totally agree with that, that confuses me as well. This works: void TFoo(T : U[], U)(T a) Oh cool, that's surprising to say the least. Thanks! This indeed works with argument deduction :)
Re: using dub and -checkaction=context
On Sunday, 17 January 2021 at 15:41:45 UTC, Steven Schveighoffer wrote: I'm trying to run unittests using `dub test`, and I wanted to use the new -checkaction=context feature to avoid having to instrument my unittests to print out the string comparison failure that's happening. But I tried adding this to my dub.sdl file: dflags "-checkaction=context" platform="dmd" But now I get linker errors: /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/source/vibe/appmain.d:(.text._D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv[_D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv]+0x5c): undefined reference to `_D4core8internal7dassert__T14_d_assert_failVAyaa1_3eTmTiZQBeFNaNbNiNfKxmxiZQBf' https://issues.dlang.org/show_bug.cgi?id=19937 ? Slightly different error message though.
Re: Template argument deduction not working with template specialization
On 1/17/21 11:22 AM, Paul wrote:
While trying to use template specializations I noticed the argument
deductions do not yield the same version as the ones yielded when being
explicit.
Example:
uint a = 1;
uint[] b = [2];
TFoo(a);
TFoo!(uint[])(b);
void TFoo(T)(T a) {
pragma(msg, "T: " ~ T.stringof);
}
void TFoo(T : T[])(T[] a) {
pragma(msg, "T[]: " ~ T.stringof);
}
I noticed that an automatically deduced TFoo call always yields the
first, while TFoo!(uint[]) yields the array version if present, and
defaults to the first elsewise.
Am I incorrect in expecting the same behavior when (ab)using argument
deduction or does my usage make sense? I tried searching for this
combination (deduction & specialization) but couldn't find another forum
post / documentation example.
I've always hated that aspect of specialization. I don't really
understand why it's valid (how can T be T[]?)
This works:
void TFoo(T : U[], U)(T a)
-Steve
Template argument deduction not working with template specialization
While trying to use template specializations I noticed the
argument deductions do not yield the same version as the ones
yielded when being explicit.
Example:
uint a = 1;
uint[] b = [2];
TFoo(a);
TFoo!(uint[])(b);
void TFoo(T)(T a) {
pragma(msg, "T: " ~ T.stringof);
}
void TFoo(T : T[])(T[] a) {
pragma(msg, "T[]: " ~ T.stringof);
}
I noticed that an automatically deduced TFoo call always yields
the first, while TFoo!(uint[]) yields the array version if
present, and defaults to the first elsewise.
Am I incorrect in expecting the same behavior when (ab)using
argument deduction or does my usage make sense? I tried searching
for this combination (deduction & specialization) but couldn't
find another forum post / documentation example.
using dub and -checkaction=context
I'm trying to run unittests using `dub test`, and I wanted to use the new -checkaction=context feature to avoid having to instrument my unittests to print out the string comparison failure that's happening. But I tried adding this to my dub.sdl file: dflags "-checkaction=context" platform="dmd" But now I get linker errors: /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/source/vibe/appmain.d:(.text._D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv[_D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv]+0x5c): undefined reference to `_D4core8internal7dassert__T14_d_assert_failVAyaa1_3eTmTiZQBeFNaNbNiNfKxmxiZQBf' /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/.dub/build/epoll-$DFLAGS-linux.posix-x86_64-dmd_2093-6D60905058E56B7C24E84CCDF9B29FD3/libvibe_core.a(sync_1456_5e95.o): In function `_D4vibe4core4sync__T22RecursiveTaskMutexImplVbi0ZQBd6unlockMFNeZ9__lambda1MFNbNfZv': /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/source/vibe/core/sync.d:(.text._D4vibe4core4sync__T22RecursiveTaskMutexImplVbi0ZQBd6unlockMFNeZ9__lambda1MFNbNfZv[_D4vibe4core4sync__T22RecursiveTaskMutexImplVbi0ZQBd6unlockMFNeZ9__lambda1MFNbNfZv]+0xb7): undefined reference to `_D4core8internal7dassert__T14_d_assert_failVAyaa1_3eTmTiZQBeFNaNbNiNfKxmxiZQBf' /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/.dub/build/epoll-$DFLAGS-linux.posix-x86_64-dmd_2093-6D60905058E56B7C24E84CCDF9B29FD3/libvibe_core.a(sync_145a_5e95.o): In function `_D4vibe4core4sync__T22RecursiveTaskMutexImplVbi1ZQBd6unlockMFNeZ9__lambda1MFNbNfZv': /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/source/vibe/core/sync.d:(.text._D4vibe4core4sync__T22RecursiveTaskMutexImplVbi1ZQBd6unlockMFNeZ9__lambda1MFNbNfZv[_D4vibe4core4sync__T22RecursiveTaskMutexImplVbi1ZQBd6unlockMFNeZ9__lambda1MFNbNfZv]+0xb7): undefined reference to `_D4core8internal7dassert__T14_d_assert_failVAyaa1_3eTmTiZQBeFNaNbNiNfKxmxiZQBf' /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/.dub/build/epoll-$DFLAGS-linux.posix-x86_64-dmd_2093-6D60905058E56B7C24E84CCDF9B29FD3/libvibe_core.a(typecons_91_11ed.o): In function `_D3std8typecons__T10RefCountedTSQBe9container10binaryheap__T10BinaryHeapTSQCuQBq5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCgS_DQCeQCcQCaQBy3ascFNfKQCzKQDdZbZQEt4DataVEQHjQHi24RefCountedAutoInitializei0ZQIc6__dtorMFNaNbNiZv': /home/steves/.dvm/compilers/dmd-2.093.1/linux/bin/../../src/phobos/std/typecons.d:(.text._D3std8typecons__T10RefCountedTSQBe9container10binaryheap__T10BinaryHeapTSQCuQBq5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCgS_DQCeQCcQCaQBy3ascFNfKQCzKQDdZbZQEt4DataVEQHjQHi24RefCountedAutoInitializei0ZQIc6__dtorMFNaNbNiZv[_D3std8typecons__T10RefCountedTSQBe9container10binaryheap__T10BinaryHeapTSQCuQBq5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCgS_DQCeQCcQCaQBy3ascFNfKQCzKQDdZbZQEt4DataVEQHjQHi24RefCountedAutoInitializei0ZQIc6__dtorMFNaNbNiZv]+0x5c): undefined reference to `_D4core8internal7dassert__T14_d_assert_failVAyaa1_3eTmTiZQBeFNaNbNiNfKxmxiZQBf' How am I supposed to do this? I tried setting DFLAGS and LDFLAGS and still linker errors. What am I doing wrong? -Steve
Re: How to use dguihub package ?
On Sunday, 17 January 2021 at 13:04:33 UTC, Vinod K Chandran wrote: Do i miss something ? Three of those messages include the solution to fix the errors. The fourth one is a missing import (`import std.conv : to`) in dguihub.core.utils. You could fix these yourself and submit a pull request to the project, or submit an issue.
How to use dguihub package ?
Hi all, I would like to use a gui package called "dguihub". So i did these steps. 1. Downloaded source files from Github. 2. Extract it and copy dguihub folder to my project folder. this folder contains all the source files of this package. 3. Write an import statement in my app.d "import dguihub;" 4. Copy paste the code from "hello" in example folder 5. Compiled with "rdmd app.d" And i got this result. dguihub\toolbar.d(103): Deprecation: integral promotion not done for ~TBSTATE_ENABLED, use '-preview=intpromote' switch or ~cast(int)(TBSTATE_ENABLED) dguihub\core\menu\abstractmenu.d(187): Deprecation: variable mi is shadowing variable dguihub.core.menu.abstractmenu.RootMenu.create.mi. Rename the foreach variable. dguihub\core\menu\abstractmenu.d(209): Deprecation: integral promotion not done for ~enabled, use '-preview=intpromote' switch or ~cast(int)(enabled) dguihub\core\utils.d(130): Error: template instance to!wstring template to is not defined Do i miss something ?
foreach, RefCounted and non-copyable range
I'm puzzled why RefCounted and foreach do not work well together, i.e.: ``` auto range = refCounted(nonCopyableRange); // ok foreach(e; range) // Error: struct is not copyable because it is annotated with @disable // do something ``` See https://run.dlang.io/is/u271nK for a full example where I also compared the foreach compiler rewrite and the manual rewrite of foreach to a simple for loop. Somehow foreach makes a copy of the internal payload of RefCounted (run the example and look at the address of the payload/range). Is this a bug and is there any way around it?
Re: Why many programmers don't like GC?
On Saturday, 16 January 2021 at 00:20:16 UTC, Guillaume Piolat wrote: It's certainly true that in team dynamics, without any reward, efficiency can be victim to a tragedy of commons. Well, any software invariant is harder to hold if the shareholders don't care. (be it "being fast", or "being correct", or other invariants). Yes, although for Open Source I think the "mental model" you talked about is more of an issue. How many people working on DMD has good mental model of it? It is a bit easier for programs like Gimp that can be "plugin" style. I guess Phobos is also "plugin" style, so it is easier to improve Phobos than DMD, because of the "mental model" issue. Maybe Open Source projects should be designed more for simple mental models (with "plugins") than for high throughput too. Maybe we can have languages that are better for Open Source by making it easier to make extensions of the software with only local impacts. Maybe it would be better for DMD to move away from "thread local" thinking and instead have a thread pool and stackless actors. Then tie local non-incremental garbage collection to actors. Useful for application development and servers, but not so useful for audio-plugins. So, you would probably not want it...
