Re: pragma lib doesn't support static libraries?
On Sunday, 30 July 2023 at 05:53:55 UTC, Mike Parker wrote: On Sunday, 30 July 2023 at 05:28:32 UTC, ryuukk_ wrote: I should have explained exactly what i am doing.. Looks like it doesn't work when i compile in 2 step - compile with: ``dmd -c of=bin/game.o`` - link with: ``dmd bin/game.o`` When doing it this way, then it doesn't work However, when compiling/linking in one ``dmd`` invocation (without ``-c``), then it all works So it looks like the pragma is not passed on the linked when it was compiled with ``-c`` Is this a bug? should i report it?, or is that the expected behavior? It's expected behavior. There's no link step in the first command, so the pragma is meaningless there. And I'm unaware of any mechanism for embedding static library names in an object file for a linker to read later. Oh ok, i'll stick to a one command invocation then, it'll further simplify my build script
Re: pragma lib doesn't support static libraries?
On Sunday, 30 July 2023 at 05:28:32 UTC, ryuukk_ wrote: I should have explained exactly what i am doing.. Looks like it doesn't work when i compile in 2 step - compile with: ``dmd -c of=bin/game.o`` - link with: ``dmd bin/game.o`` When doing it this way, then it doesn't work However, when compiling/linking in one ``dmd`` invocation (without ``-c``), then it all works So it looks like the pragma is not passed on the linked when it was compiled with ``-c`` Is this a bug? should i report it?, or is that the expected behavior? It's expected behavior. There's no link step in the first command, so the pragma is meaningless there. And I'm unaware of any mechanism for embedding static library names in an object file for a linker to read later.
Re: pragma lib doesn't support static libraries?
I should have explained exactly what i am doing.. Looks like it doesn't work when i compile in 2 step - compile with: ``dmd -c of=bin/game.o`` - link with: ``dmd bin/game.o`` When doing it this way, then it doesn't work However, when compiling/linking in one ``dmd`` invocation (without ``-c``), then it all works So it looks like the pragma is not passed on the linked when it was compiled with ``-c`` Is this a bug? should i report it?, or is that the expected behavior?
pragma lib doesn't support static libraries?
Hello, I'm trying to simplify my build script, i have this library that i statically link OS: linux ``dmd app.d mongoose/bin/linux/mongoose.a`` becomes: ``` package mongoose; pragma(lib, "mongoose/bin/linux/mongoose.a"); ``` However, it no longer compile, and it complains about ``undefined reference to `` the functions from that lib I tried different paths, even the full path to that file, nothing works So my question: does prama lib support static libraries? - if yes, then what i am doing wrong? - if no, then what should i do to make it support static libs? Thanks for reading me!
How do we display Unicode in Visual D console output?
Right now, fresh install of VS and Visual D, all up-to-date. Can't display ∈, so how can we fix this? There is no project setting for Unicode chars. Thanks! EnjoysMath
Re: dub Fetches Wrong Package Version
On Saturday, 29 July 2023 at 16:47:34 UTC, Ruby The Roobster wrote: Dub refuses to fetch the ~master branch of a package, even when dub.json tells it to. Is there any workaround to this? Delete dub.selections.json, which locks in dependency versions until you explicitly upgrade.
dub Fetches Wrong Package Version
Dub refuses to fetch the ~master branch of a package, even when dub.json tells it to. Is there any workaround to this?
Re: Make a function available under different names.
There are 2 ways you can solve your problem
```d
string returnExecutableName(string[] arguments) {
// if you compile with `-debug` it'll run this block
debug {
write("Debug mode is enabled.\n");
write(" Executable_Name: " ~ arguments[0] ~ "\n");
}
return arguments[0];
}
```
```d
string returnExecutableName(string[] arguments) {
// if you compile with `-version=VERBOSE` it'll run this block
version (VERBOSE) {
write("Debug mode is enabled.\n");
write(" Executable_Name: " ~ arguments[0] ~ "\n");
}
return arguments[0];
}
```
You don't even need that function at this point
```d
import std.stdio;
void main(string[] args) {
debug {
write("Debug mode is enabled.\n");
write(" Executable_Name: " ~ args[0] ~ "\n");
}
}
```
There, it's cleaner without indirections
Re: Make a function available under different names.
And here is my latest evolution of the code I've shared
previously.
```
module utilities;
import std.stdio : write;
string returnExecutableName(string[] arguments, bool
debugging=false) {
if (debugging == true){
write("Debug mode is enabled.\n");
write(" Executable_Name: " ~ arguments[0] ~ "\n");
}
return arguments[0];
}
auto debugExecutableName(string[] arguments){
return returnExecutableName(arguments, true);
}
alias printExecutableName = debugExecutableName;
alias getExecutableName = debugExecutableName;
```
### Possible new syntax for D Alias?
In this recent version of my code I noticed that it would be nice
to have a new syntax for `alias` declaration.
Syntax I would need in D language.
`alias printExecutableName = getExecutableName =
debugExecutableName;`
In this syntax it would be easier to **declare multiple alias**
that point to the same origin.
Not sure if it would be a good idea, but an idea nonetheless.
Re: Make a function available under different names.
Here is some more updated code that works.
```
module utilities;
import std.stdio : write;
string returnExecutableNameFromMainFunction(string[] arguments,
bool debugging=false) {
if (debugging == true){
write("Debug mode is enabled.\n");
write(" Executable_Name: " ~ arguments[0] ~ "\n");
}
return arguments[0];
}
auto debugExecutableNameFromMainFunction(string[] arguments){
return returnExecutableNameFromMainFunction(arguments, true);
}
alias printExecutableNameFromMainFunction =
debugExecutableNameFromMainFunction;
alias getExecutableNameFromMainFunction =
debugExecutableNameFromMainFunction;
```
Re: Make a function available under different names.
On Saturday, 29 July 2023 at 14:26:17 UTC, 4 wrote:
Let's say I have these two functions:
They have duplicate functionality.
```
string getExecutableNameFromMainFunction(string[] arguments){
write("Executable_Name: " ~ arguments[0] ~ "\n");
write("Debug mode is enabled.\n");
return arguments[0];
}
string printExecutableNameFromMainFunction(string[] arguments){
write("Executable_Name: " ~ arguments[0] ~ "\n");
write("Debug mode is enabled.\n");
return arguments[0];
}
```
How can I easily and in simple way make
`printExecutableNameFromMainFunction` as function
where `getExecutableNameFromMainFunction` would share
functionality or simply point to
`printExecutableNameFromMainFunction`.
Seems to be working
```
alias printExecutableNameFromMainFunction =
getExecutableNameFromMainFunction;
string getExecutableNameFromMainFunction(string[] arguments){
write("Executable_Name: " ~ arguments[0] ~ "\n");
write("Debug mode is enabled.\n");
return arguments[0];
}
```
Make a function available under different names.
Let's say I have these two functions:
They have duplicate functionality.
```
string getExecutableNameFromMainFunction(string[] arguments){
write("Executable_Name: " ~ arguments[0] ~ "\n");
write("Debug mode is enabled.\n");
return arguments[0];
}
string printExecutableNameFromMainFunction(string[] arguments){
write("Executable_Name: " ~ arguments[0] ~ "\n");
write("Debug mode is enabled.\n");
return arguments[0];
}
```
How can I easily and in simple way make
`printExecutableNameFromMainFunction` as function
where `getExecutableNameFromMainFunction` would share
functionality or simply point to
`printExecutableNameFromMainFunction`.
Re: Getting __COLUMN__ of source code location.
On Thursday, 27 July 2023 at 16:17:28 UTC, IchorDev wrote:
I'm not aware of any way to do that exact thing. Measuring what
column a line is on would be quite subjective.
When I compile(LDC2) a something with an error and using the
--vcolumns argument I get this:
onlineapp.d(14,5): Error: found `}` when expecting `;` following
statement
The error is on Line 14, Column 5.
(I don't care how much it counts the TAB character, as long as it
is unique.)
So the information is accessible in the compiler.
I just can't access from the language.
```
I can access __LINE__ but I can't access something like __COL__.
```
I just hope there is other ways to get this, maybe with an LDC
specific traits or something.
But you'd have to provide a unique ID manually anyway if, for
instance, you create UI elements in a for loop:
```d
for(size_t i=0; i<10; i++){
button();
}
```
I'd suggest using something more like Dear ImGui's ID system
instead.
Thanks for suggesting I've checked.
As I see it is using an ID stack.
I do something similar with a 32bit hash and using XOR operation
to simulate a stack. Also for debugging and critical stuff there
is an option to store this id stack in a string with meaningful
names.
So I can modify the id directly, when I pit the button() in a for
loop.
All the Controls automatically modifying the id by their type,
source module and source line number (just a hash or a meaningful
string for debug).
```
line 15:with(player){ if(Btn("Play")) play; if(Btn("Stop"))
stop; }
```
So the 2 id's for the buttons will be the same: [Btn,module,15]
and [Btn,module,15] <- that's a duplicated id.
But if I'd have access to sourcecolumn, that would be so cool:
[Btn,module,15,22] and [Btn,module,15,34]
Here are the 2 workarounds right now:
```
line 15:with(player){ if(Btn("Play"), genericId(1)) play;
if(Btn("Stop"), genericId(1)) stop; }
```
```
line 15:with(player){ if(Btn("Play")) play;
line 16: if(Btn("Stop")) stop; }
```
It's not a critically important feature, it's just helping the UI
and the code that generates the UI being in the same visual
layout: horizontal in this case.
