Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 03:25:39 UTC, H. S. Teoh wrote: On Thu, Feb 03, 2022 at 02:01:34AM +, forkit via Digitalmars-d-learn wrote: [...] would be nice if the compiler told me something though :-( i.e. "hey, dude, you really wanna to that?" Mark your function @safe, and the compiler will stop you from unsafe casts of this nature. That's part of the reason we have @safe. ;-) T so i mark all my modules as @safe, by default. I commented it out though, so I could do the cast. Then realised I didn't need the cast at all, just the .dup now it's @safe again. But @safe or not, nothing good can come from casting an immutable string to a mutable string, and the compiler really should know that ;-)
Re: ldc executable crashes with this code
On Thu, Feb 03, 2022 at 02:01:34AM +, forkit via Digitalmars-d-learn wrote: [...] > would be nice if the compiler told me something though :-( > > i.e. "hey, dude, you really wanna to that?" Mark your function @safe, and the compiler will stop you from unsafe casts of this nature. That's part of the reason we have @safe. ;-) T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
Re: ldc executable crashes with this code
On Wednesday, 2 February 2022 at 23:21:52 UTC, forkit wrote:
Any reason why compiling this with ldc would cause the exe to
crash?
Compiling with DMD (using either declaration of palindrome
works just fine though)
//
module test;
import std;
void main()
{
char[] palindrome = cast(char[])"able was I ere I saw elba";
//char[] palindrome =
['a','b','l','e','w','a','s','I','e','r','e','I','s','a','w','e','l','b','a'];
writeln(palindrome);
// note: The line below causes the exe to crash when
compiled with ldc
// but only if using the first version of palindrome.
writeln(palindrome.reverse);
}
// ---
This segfaults even on `dmd 2.098.0` for me.
Clearly implementation defined behavior.
Re: Can anyone provide an example of how D templates are overridable by global symbols?
On Saturday, 29 January 2022 at 00:52:10 UTC, H. S. Teoh wrote: Trying out what I suggested on different OS's and toolchains will give you a good idea of what's actually out there. I will just reply with a quote from https://forum.dlang.org/post/mailman.400.1643853436.20251.digitalmars-d-le...@puremagic.com : "In any case, just because it worked by chance does not mean it's OK".
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:57:12 UTC, H. S. Teoh wrote: would be nice if the compiler told me something though :-( i.e. "hey, dude, you really wanna to that?"
Re: ldc executable crashes with this code
On Thu, Feb 03, 2022 at 01:39:33AM +, forkit via Digitalmars-d-learn wrote: > On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh wrote: > > On Wed, Feb 02, 2022 at 11:21:52PM +, forkit via Digitalmars-d-learn > > wrote: [...] > > > char[] palindrome = cast(char[])"able was I ere I saw elba"; > > > > String literals are immutable by default. Casting immutable to > > mutable is UB (Undefined Behaviour). > > > > > > [...] > > > writeln(palindrome.reverse); > > > > Especially because .reverse mutates its argument. So you're > > attempting to overwrite immutable data here. That's probably what > > caused the crash: the literal is put in the read-only segment and > > the OS killed the program when it tried to write to data in that > > read-only segment. [...] > that explains ldc perhaps (although i don't really get it. It's cast > to mutable and being assigned to mutable. Assigning the literal to char[] simply creates a mutable slice of the immutable data. That's technically UB. Then .reverse modifies the array in-place, which means you violated immutable. > in any case... ldc doesn't like it, but dmd is fine with this ?? UB doesn't mean a guaranteed crash, it means the result will be implementation-dependent (and likely not what was intended). It's possible that dmd didn't put the literal in a read-only segment, or there may be some other reason. In any case, just because it worked by chance does not mean it's OK to simply cast immutable to mutable and then proceed to mutate it. T -- Let X be the set not defined by this sentence...
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:51:34 UTC, Basile B. wrote:
On Thursday, 3 February 2022 at 01:39:33 UTC, forkit wrote:
On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh
wrote:
[...]
that explains ldc perhaps (although i don't really get it.
It's cast to mutable and being assigned to mutable.
in any case... ldc doesn't like it, but dmd is fine with this
??
your cast from immutable to mutable is an undefined behavior,
this may work or not.
Note that casting away a const qualifier and then mutating is
undefined behavior, too, even when the referenced data is
mutable. This is so that compilers and programmers can make
assumptions based on const alone. For example, here it may be
assumed that f does not alter x:
(from https://dlang.org/spec/const3.html#removing_with_cast)
the D safe way :
```
void main() @safe
{
char[] palindrome = "able was I ere I saw elba".dup;
writeln(palindrome);
writeln(palindrome.reverse);
}
```
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:39:33 UTC, forkit wrote: oops! forgot the .dup char[] palindrome = cast(char[])"able was I ere I saw elba".dup; ;-)
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:39:33 UTC, forkit wrote: On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh wrote: [...] that explains ldc perhaps (although i don't really get it. It's cast to mutable and being assigned to mutable. in any case... ldc doesn't like it, but dmd is fine with this ?? your cast from immutable to mutable is an undefined behavior, this may work or not. Note that casting away a const qualifier and then mutating is undefined behavior, too, even when the referenced data is mutable. This is so that compilers and programmers can make assumptions based on const alone. For example, here it may be assumed that f does not alter x: (from https://dlang.org/spec/const3.html#removing_with_cast)
Re: ldc executable crashes with this code
On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh wrote: On Wed, Feb 02, 2022 at 11:21:52PM +, forkit via Digitalmars-d-learn wrote: [...] char[] palindrome = cast(char[])"able was I ere I saw elba"; String literals are immutable by default. Casting immutable to mutable is UB (Undefined Behaviour). [...] writeln(palindrome.reverse); Especially because .reverse mutates its argument. So you're attempting to overwrite immutable data here. That's probably what caused the crash: the literal is put in the read-only segment and the OS killed the program when it tried to write to data in that read-only segment. T that explains ldc perhaps (although i don't really get it. It's cast to mutable and being assigned to mutable. in any case... ldc doesn't like it, but dmd is fine with this ??
Re: ldc executable crashes with this code
On Wed, Feb 02, 2022 at 11:21:52PM +, forkit via Digitalmars-d-learn wrote: [...] > char[] palindrome = cast(char[])"able was I ere I saw elba"; String literals are immutable by default. Casting immutable to mutable is UB (Undefined Behaviour). [...] > writeln(palindrome.reverse); Especially because .reverse mutates its argument. So you're attempting to overwrite immutable data here. That's probably what caused the crash: the literal is put in the read-only segment and the OS killed the program when it tried to write to data in that read-only segment. T -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth
ldc executable crashes with this code
Any reason why compiling this with ldc would cause the exe to
crash?
Compiling with DMD (using either declaration of palindrome works
just fine though)
//
module test;
import std;
void main()
{
char[] palindrome = cast(char[])"able was I ere I saw elba";
//char[] palindrome =
['a','b','l','e','w','a','s','I','e','r','e','I','s','a','w','e','l','b','a'];
writeln(palindrome);
// note: The line below causes the exe to crash when compiled
with ldc
// but only if using the first version of palindrome.
writeln(palindrome.reverse);
}
// ---
Re: How to make dub recursively build subPackages?
On Wednesday, 2 February 2022 at 19:03:35 UTC, Steven Schveighoffer wrote: On 2/2/22 1:42 PM, Vijay Nayar wrote: Dub is kind of a hot mess in terms of the dependency resolution and ways to specify projects. I would love to see it cleaned up/reimplemented. -Steve For your larger more complex projects, what build system do you use? So far I've been having good luck with dub, but I haven't done any mixed-language projects lately either.
Re: How to make dub recursively build subPackages?
On 2/2/22 1:42 PM, Vijay Nayar wrote: I made this change and it did indeed work correctly, thank you for that! Truthfully, it was not entirely clear to me how dub was deciding where to go to build. I had assumed that this was being done via the `subPackage` lines. Like many things in dub, there are multiple ways to do things. I've done some of the other things in some projects, and I found this works the best for intra-repository dependencies. If you are depending on a subproject from outside the repository, then I think you have to use the version of the parent repository as a specified version, since the whole repo is tagged the same. The examples given in the offical documentation were also using versions, and I was following that: https://dub.pm/package-format-sdl.html#sub-packages Yeah, that example shows a repository which exists purely to combine multiple subprojects into one repo (note the targetType of none). Also note the `version="*"`, which is basically "I don't care, whatever is there". I think you could also do a path as well, but I think even if you use the `*` version, you might have dub trying to fetch the dependency from the internet. I'm more comfortable with the `path` directive, since I know it can't possibly think that it has to go elsewhere to resolve that dependency. Dub is kind of a hot mess in terms of the dependency resolution and ways to specify projects. I would love to see it cleaned up/reimplemented. -Steve
Re: How to make dub recursively build subPackages?
On Wednesday, 2 February 2022 at 14:07:08 UTC, Steven Schveighoffer wrote: On 2/2/22 5:14 AM, Vijay Nayar wrote: If you have them in the same repository, my recommendation is to use path dependencies instead of versions. So, e.g.: ```sdl dependency "funnel:proto" path="./proto" // in main dub.sdl dependency "funnel:proto" path="../proto" // in sibling package ``` Because otherwise, dub is going to try and fetch the appropriate version from an online repository and not use your local files. Honestly, for packages in the same repository, I'm not sure why you would version them separately from the main package. I don't even know if that works. -Steve I made this change and it did indeed work correctly, thank you for that! Truthfully, it was not entirely clear to me how dub was deciding where to go to build. I had assumed that this was being done via the `subPackage` lines. The examples given in the offical documentation were also using versions, and I was following that: https://dub.pm/package-format-sdl.html#sub-packages
Re: How to make dub recursively build subPackages?
On 2/2/22 5:14 AM, Vijay Nayar wrote: Greetings folks, In my project, I have a parent package with several sub-packages, each of which builds into either a library or an executable. I first started observing odd problems when I was running `dub build`, it would complain about different versions of vibe-d present, and it suggested running `dub upgrade`. After doing this, I noticed that most subPackages were not actually being upgraded. The only thing I have found thus far is to manually run each subPackage one at a time, e.g. `dub :proto; dub :common; ...`. Is it possible to get `dub upgrade` to recursively work on all sub-packages? My parent package dub.sdl file: ``` name "funnel" description "An in-memory queryable database for processing extreme loads of current data." authors "Vijay Nayar" copyright "Copyright © 2019, Vijay Nayar" license "proprietary" targetType "none" targetPath "target" dependency "funnel:proto" version=">=0.0.0" dependency "funnel:spout" version=">=0.0.0" dependency "funnel:stem" version=">=0.0.0" dependency "funnel:mouth" version=">=0.0.0" dependency "funnel:common" version=">=0.0.0" subPackage "./common" subPackage "./proto" subPackage "./mouth" subPackage "./stem" subPackage "./spout" ``` Each subPackage is structured in the same way, for example, the common subPackage: ``` authors "Vijay Nayar" copyright "Copyright © 2019, Vijay Nayar" description "Common logic between the mouth and spout components." license "proprietary" name "common" targetType "library" targetPath "target" dependency "funnel:proto" version="*" dependency "poodinis" version="~>8.0.3" dependency "vibe-d" version="~>0.9.4" ``` I mostly followed the dub documentation in setting up my project. https://dub.pm/package-format-sdl.html If you have them in the same repository, my recommendation is to use path dependencies instead of versions. So, e.g.: ```sdl dependency "funnel:proto" path="./proto" // in main dub.sdl dependency "funnel:proto" path="../proto" // in sibling package ``` Because otherwise, dub is going to try and fetch the appropriate version from an online repository and not use your local files. Honestly, for packages in the same repository, I'm not sure why you would version them separately from the main package. I don't even know if that works. -Steve
Re: How to make dub recursively build subPackages?
On Wednesday, 2 February 2022 at 10:14:25 UTC, Vijay Nayar wrote: Greetings folks, In my project, I have a parent package with several sub-packages, each of which builds into either a library or an executable. [...] I should point out there is 1 exception to subPackages not being recursive. The `dub clean` command does recurse, and there is source code for it here: https://github.com/dlang/dub/blob/3abaa4d5b7c3b2c21ab75370cd5330e9ae7bbd12/source/dub/dub.d#L880
How to make dub recursively build subPackages?
Greetings folks, In my project, I have a parent package with several sub-packages, each of which builds into either a library or an executable. I first started observing odd problems when I was running `dub build`, it would complain about different versions of vibe-d present, and it suggested running `dub upgrade`. After doing this, I noticed that most subPackages were not actually being upgraded. The only thing I have found thus far is to manually run each subPackage one at a time, e.g. `dub :proto; dub :common; ...`. Is it possible to get `dub upgrade` to recursively work on all sub-packages? My parent package dub.sdl file: ``` name "funnel" description "An in-memory queryable database for processing extreme loads of current data." authors "Vijay Nayar" copyright "Copyright © 2019, Vijay Nayar" license "proprietary" targetType "none" targetPath "target" dependency "funnel:proto" version=">=0.0.0" dependency "funnel:spout" version=">=0.0.0" dependency "funnel:stem" version=">=0.0.0" dependency "funnel:mouth" version=">=0.0.0" dependency "funnel:common" version=">=0.0.0" subPackage "./common" subPackage "./proto" subPackage "./mouth" subPackage "./stem" subPackage "./spout" ``` Each subPackage is structured in the same way, for example, the common subPackage: ``` authors "Vijay Nayar" copyright "Copyright © 2019, Vijay Nayar" description "Common logic between the mouth and spout components." license "proprietary" name "common" targetType "library" targetPath "target" dependency "funnel:proto" version="*" dependency "poodinis" version="~>8.0.3" dependency "vibe-d" version="~>0.9.4" ``` I mostly followed the dub documentation in setting up my project. https://dub.pm/package-format-sdl.html
