Re: Is it possible to make an Linux Executable Binary using a Windows Operating System? [compiling and linking]
You will also need crt1.o, crti.o, crtn.o and libc.a
Re: array index out of bound may not throw exception?
On Friday, 21 July 2023 at 23:40:44 UTC, mw wrote: Is there a way to let it report on the spot when it happens? On linux if you catch an exception and call abort, the debugger will show you where abort was called, on windows you can call DebugBreak function, the debugger will show where it was called.
Re: AA vs __gshared
On Friday, 28 July 2023 at 03:54:53 UTC, IchorDev wrote: I was told that using `__gshared` is quite a bit faster at runtime than using `shared`, but I also don't really know anything concrete about `shared` because the spec is so incredibly vague about it. The difference between them is purely formal if you're not on an old gdc, where shared was synchronized like C# volatile. If the crashes are frequent, can you reproduce a crash with a minimal amount of code, start many threads and access the locked AA concurrently.
Re: AA vs __gshared
On Thursday, 27 July 2023 at 21:31:02 UTC, Jonathan M Davis wrote: Now, as to what's happening in your code that's causing segfaults, the most likely culprit would be that you're accessing the AA without actually having done anything to prevent other threads from accessing it at the same time (or your protections were inadequate). I use a shared Mutex from `core.sync.mutex`. The AA itself and the `final class` that it's a member of is only ever accessed by one thread for now. The code inside that `final class` that accesses the AA is called by a function from another `final class`, and that other `final class` is used by multiple threads, but it's fully guarded by Mutex locks—I haven't had any issues with the millions of non-atomic reads and writes on its data I've performed from the two threads. Both objects are "static" (declared at module scope) if that matters at all. if the AA were shared, the only sections of code where you would have to worry about thread-local references escaping would be in the sections of code where you've cast away shared after locking the relevant mutex. So, similar to what happens with @safe and @trusted, using shared allows you to limit the code that you have to examine to find the problem. I was told that using `__gshared` is quite a bit faster at runtime than using `shared`, but I also don't really know anything concrete about `shared` because the spec is so incredibly vague about it.
Re: Unicode in strings
On Thursday, 27 July 2023 at 22:35:00 UTC, Adam D Ruppe wrote: On Thursday, 27 July 2023 at 22:15:47 UTC, Cecil Ward wrote: How do I get a wstring or dstring with a code point of 0xA0 in it ? note that you don't need wstring and dstring to express all unicode strings. I realised that I was probably generating UTF8 and only one byte, so I switched to \u00A0, I think. Must have got that wrong too because I was still getting the error message. I’ll try it again carefully.
Re: Unicode in strings
On Thursday, 27 July 2023 at 22:15:47 UTC, Cecil Ward wrote: How do I get a wstring or dstring with a code point of 0xA0 in it ? note that you don't need wstring and dstring to express all unicode strings.
Re: Unicode in strings
On Thu, Jul 27, 2023 at 10:15:47PM +, Cecil Ward via Digitalmars-d-learn wrote: > How do I get a wstring or dstring with a code point of 0xA0 in it ? > That’s a type of space, is it? I keep getting a message from the LDC > compiler something like "Outside Unicode code space" in my unittests > when this is the first character in a wstring. I’ve tried all sorts of > escape sequences but I must simply be misunderstanding the docs. I > could always copy-paste a real live one into a double quoted string > and be done with it, I suppose. D strings are assumed to be encoded in UTF-8 / UTF-16 / UTF-32. So if you wrote something like `\xA0` in your string will likely generate an invalid encoding. Try instead `\u00A0`. T -- Ph.D. = Permanent head Damage
Re: AA vs __gshared
On Thursday, July 27, 2023 9:57:51 AM MDT IchorDev via Digitalmars-d-learn wrote: > I've been getting a lot of segfaults from using associative > arrays recently. The faults happen seemingly at random, and from > pretty mundane stuff like `if(auto x = y in z)` that run very > often: > ``` > Segmentation fault. > #0 0x55670f4a in rt.aaA.Impl.findSlotLookup(ulong, scope > const(void*), scope const(TypeInfo)) inout () > #1 0x55661662 in _aaInX () > ``` > > I suspect that this is because they've all been placed inside > `__ghared` structs. Are DRuntime's AAs simply incompatible with > `__gshared`? Do they need to be marked as `shared` to prevent > these shenanigans? Strictly speaking, __gshared is really only intended for stuff like C globals (which can't be shared due to name-mangling issues). Using it on anything else can at least potentially cause problems due to the fact that the compiler will assume that the variable is thread-local. So, I would strongly advise against using __gshared in a case like this. In practice, you can often get away with it, because the compiler doesn't do much in the way of optimizing stuff based on objects being thread-local right now, but it's definitely risking problems with the type system if you used __gshared when you're not trying to do something like bind to a C global. What should normally be happening is that you use shared, and then when you've protected the object so that you know that it can only be accessed on the current thread by the section of code that you're in (e.g. by locking a mutex), you temporarily cast away shared to operate on the object via a thread-local reference. Then, before exiting that section of code and removing the protections that are preventing other threads from accessing the object (e.g. by unlocking the mutex), you make sure that you've gotten rid of all of the thread-local references to the object so that only the shared reference exists. That way, you don't accidentally mutate the object while it's not protected from access by other threads. Now, as to what's happening in your code that's causing segfaults, the most likely culprit would be that you're accessing the AA without actually having done anything to prevent other threads from accessing it at the same time (or your protections were inadequate). And because the object is being treated as thread-local by the compiler, it would be easy to have accidentally let a reference to it leak somewhere that wasn't being protected by whatever mutex you're using, whereas if the AA were shared, the only sections of code where you would have to worry about thread-local references escaping would be in the sections of code where you've cast away shared after locking the relevant mutex. So, similar to what happens with @safe and @trusted, using shared allows you to limit the code that you have to examine to find the problem. - Jonathan M Davis
Re: Syntax for Static Import of User Define Attributes
On Thursday, 27 July 2023 at 21:19:08 UTC, Vijay Nayar wrote:
Attempted Fix 2: Enclose the entire attribute name in
parenthesis.
```
static import vibe.data.serialization;
class ChatCompletionFunctions {
@(vibe.data.serialization.name)("name")
...
}
```
Try:
```D
@(vibe.data.serialization.name("name"))
```
Re: Syntax for Static Import of User Define Attributes
On Thursday, 27 July 2023 at 21:19:08 UTC, Vijay Nayar wrote:
Attempted Fix 2: Enclose the entire attribute name in
parenthesis.
```
static import vibe.data.serialization;
class ChatCompletionFunctions {
@(vibe.data.serialization.name)("name")
...
}
```
You almost had it. The correct syntax is to enclose the entire
attribute (not just the name) in parentheses:
```
class ChatCompletionFunctions {
@(vibe.data.serialization.name("name"))
string name;
}
```
Re: What is a dchar ?
On Wednesday, 26 July 2023 at 01:56:28 UTC, Richard (Rikki) Andrew Cattermole wrote: The spec says they are unsigned, so if ldc is using sign extension, that is probably a bug. My fault, I reread the code and the sign-extension applies to something else, coincidentally right where I was looking at this. It uses signed 32-bit displacements in a case/switch table of offsets into the code segment, and that was what mislead me. It could have used unsigned displacements but then all the labels in the code would have to be above the reference base point, and this allows +/- offsets to anywhere. So my apologies.
Re: Getting __COLUMN__ of source code location.
I'm not aware of any way to do that exact thing. Measuring what
column a line is on would be quite subjective. How wide is a tab
space? Technically, it could be any number of columns depending
on the display configuration used.
On Sunday, 23 July 2023 at 15:01:51 UTC, realhet wrote:
Why is this important?
- I have an immediate GUI which is using this __MODULE__LINE__
data to generate a unique ID. And I must put every GUI control
creation command on a different line or provide a unique ID
manually.
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.
Re: AA vs __gshared
On Thursday, 27 July 2023 at 15:57:51 UTC, IchorDev wrote: The faults happen seemingly at random, and from pretty mundane stuff like `if(auto x = y in z)` that run very often: Are you accessing the AA from multiple threads?
AA vs __gshared
I've been getting a lot of segfaults from using associative arrays recently. The faults happen seemingly at random, and from pretty mundane stuff like `if(auto x = y in z)` that run very often: ``` Segmentation fault. #0 0x55670f4a in rt.aaA.Impl.findSlotLookup(ulong, scope const(void*), scope const(TypeInfo)) inout () #1 0x55661662 in _aaInX () ``` I suspect that this is because they've all been placed inside `__ghared` structs. Are DRuntime's AAs simply incompatible with `__gshared`? Do they need to be marked as `shared` to prevent these shenanigans?
Who can give me some advice about importC?
Sorry, my English is not very good. I rely entirely on the translator to translate. I used the DMD compiler on the WINDOWS platform to try IMPORT C. I tried GLFW,YOGA, added a predefined part, precompiled it into an I file with cl.exe, then compiled it with dll, and then imported it into the I file by importing the d file. This approach is successful, but it always conflicts with libcurt symbols when compiling directly in lib mode. I don't know how to solve it. I don't know what will happen to the I file and lib file in this way, please give me some suggestions.
