Re: compiler does not detect accessing on null class object.
On Monday, 27 May 2019 at 15:13:00 UTC, dangbinghoo wrote:
hello,
code below:
-
class a {
string a1;
}
a a1;
writeln(a1.a1);
-
compiles and produce "core dump" or "segfault", does this fit
the original D design? why the compiler does not detect for
accessing a null object and refused to compile?
And, 2nd question: where can I find the Subset spec of SafeD?
Thanks!
--
binghoo dang
1.)
Yes this is by design. It is not easy to detect this at compile
time.
It does not break safety
2.)
https://dlang.org/spec/function.html#function-safety
https://dlang.org/spec/memory-safe-d.html
https://dlang.org/articles/safed.html#safed-subset
compiler does not detect accessing on null class object.
hello,
code below:
-
class a {
string a1;
}
a a1;
writeln(a1.a1);
-
compiles and produce "core dump" or "segfault", does this fit the
original D design? why the compiler does not detect for accessing
a null object and refused to compile?
And, 2nd question: where can I find the Subset spec of SafeD?
Thanks!
--
binghoo dang
Re: Example of append & rectangualar arrays?
On Saturday, 25 May 2019 at 14:17:43 UTC, Robert M. Münch wrote: Does anyone has an example using Appender with a rectangual array? Appender!(T[][]) can append rows of type T[]. It does not check their lengths, the T[][] is an array of arrays, not a matrix. To append columns one needs an array of Appenders, Appenders!(T[])[]. T[][] can be converted to Slice!(T*, 2) (ndslice matrix) using the mir.ndslice.fuse module [1]. Then the matrix can be transposed. Zero cost transposition can be found in the second example at [1]. `ndarray` function can be used [2] to convert matrix back to an array of array. http://mir-algorithm.libmir.org/mir_ndslice_fuse.html#.fuse http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#ndarray
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote: On 5/16/19 4:27 PM, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: What's an hnsec anyways? Hecto-nano-second, the smallest representable unit of time in SysTime and Duration. The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns. -Steve It's 100ns. 10ns = 1dans = 1 deka-nano-second. deka = 10, hecto = 100 [1] [1] https://www.nist.gov/pml/weights-and-measures/metric-si-prefixes
Re: Meson build system user learning D.
On Thursday, 23 May 2019 at 06:14:11 UTC, Russel Winder wrote: On Thu, 2019-05-23 at 04:21 +, Mike Brockus via Digitalmars-d-learn wrote: […] That is cool that Atila was kind enough to accept the meson.build file. But how do I use the written meson.build that is apparently in the subdirectory directory "build"? Just asking because normally I see a meson.build in the root of the project. Having the meson.build in the project root directory is the norm, and that was where I put it originally. However, Atila chose to leave only the Dub build in the root directory and place all other build-related files in the build directory. This is not a problem since Meson is entirely happy with that structure. I have my clone of unit-threaded in ~/Repositories/Git/Fork/Unit_Threaded and I build in ~/BuildArea/Unit_Threaded. My meson command in the build directory is: meson --prefix=$HOME/Built ~/Repositories/Git/Fork/Unit_Threaded/built and this works fine. I then build and install using Ninja. To date it all works for me. If you try this and something goes wrong put an issue on the unit-threaded GitHub project area and email me in case I don't get a notification from the issue system. I tried that custom command voodoo then I tried to use 'dub' as a method for hunting down dependencies. Basically got something like this. ''' Found DUB: /usr/local/bin/dub (DUB version 1.15.0, built on May 4 2019) Dependency unit-threaded found: NO meson.build:71:0: ERROR: Dependency "unit-threaded" not found '''
Re: Meson build system user learning D.
On Mon, 2019-05-27 at 16:13 +, Mike Brockus via Digitalmars-d-learn wrote: > […] > > I tried that custom command voodoo then I tried to use 'dub' as a > method for hunting down dependencies. Basically got something > like this. Apologies but I am not sure what you have tried. Installing unit- threaded as a shared library is so as to build a D project without dub at all. What I didn't say in the previous email is that if you are installing libraries not to the standard place you have to set some environment variables. In my case, consistent with the build instructions I gave for my case: PKG_CONFIG_PATH=.:/home/users/russel/Built/share/pkgconfig:/home/users/russel/Built/lib/pkgconfig LD_LIBRARY_PATH=.:/home/users/russel/Built/lib Having . in the paths is not something everyone does though. > ''' > Found DUB: /usr/local/bin/dub (DUB version 1.15.0, built on > May 4 2019) > Dependency unit-threaded found: NO > > meson.build:71:0: ERROR: Dependency "unit-threaded" not found > ''' This seems like you are using Dub from within the Meson/Ninja build, this is not something I do. I know you can use Dub from Meson to deal with dependencies, but this is not something I do. I build all the dependencies and then build the application without Dub. If using Dub from Meson to handle dependencies becomes the de facto standard I'll give it a whirl. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Linking a .h file
On Saturday, 25 May 2019 at 12:59:50 UTC, Timur Gafarov wrote:
bindbc-nuklear expects nuklear.so in /usr/local/lib. Or you can
compile Dagon without optional libraries, using "Minimal"
subconfiguration in your dub.json:
"subConfigurations": {
"dagon": "Minimal"
}
Fonts and GUI will be unavailable then. You can also use
"NoNuklear" and "NoFreetype" subconfigurations.
That is what the documentation says, but that doesn't seem to
work for me.
I'm using an dub.sdl file rather than a dub.json, and using
```
dependency "dagon" version="0.10.0"
subConfigurations {
"dagon" "Minimal"
}
```
but then I get
Error: Nuklear library is not found. Please, install Nuklear.
Program exited with code 1
I'll try with a dub.json but my understanding is both sdl and
json should produce the same thing?
Re: [OT] Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Tuesday, 21 May 2019 at 02:12:10 UTC, Les De Ridder wrote:
On Sunday, 19 May 2019 at 12:24:28 UTC, Patrick Schluter wrote:
On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote:
On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter
wrote:
* hurrah for French keyboard which has a rarely used µ key,
but none for Ç a frequent character of the language.
That's the lowercase ç. The uppercase Ç is not directly
composable,
No, note that I said and not . Using Lock> it
outputs a 'Ç' for me (at least on X11 with the French layout).
Does not work on Windows. and it gives 9. I tested
also on my Linux Mint box and it output lowercase ç with lock>.
There are 2 other characters that are not available on the
french keyboard: œ and Œ. Quite annoying if you sell beef
(bœuf) and eggs (œufs) in the towns of Œutrange or Œting.
It seems those are indeed not on the French layout at all.
Might I
suggest using the Belgian layout? It is AZERTY too and has both
'œ'
and 'Œ'.
No, it hasn't.
I indeed prefer the Belgian keyboard. It has more composable
deadkey characters accents, tildas. Brackets [{]} and other
programming characters < > | etc, are better placed than on the
French keyboard.
Btw æ and Æ are missing also, but there it's not very important
as there are really only very few words in French that use them
ex-æquo, curriculum vitæ, et cætera
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 18:02:04 UTC, kdevel wrote: On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer [...] hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term. Agreed, which is why Duration.toString shouldn't be used to present durations to users. Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms. "hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds". [1] "Prefixes may not be used in combination." https://en.wikipedia.org/wiki/Metric_prefix Exactly it really does not exist. Just try to search it on net. No one know what is it. Only few people from D world use it. Every time I need to work with D and time it takes hours to find out what hnsecs is.
Re: Linking a .h file
On Saturday, 25 May 2019 at 12:59:50 UTC, Timur Gafarov wrote: bindbc-nuklear expects nuklear.so in /usr/local/lib. That's important! I changed my symlink in `/usr/local/lib` from `libnuklear.so` to `nuklear.so` and it works now.
Re: Reuse/reset dynamic rectangular array?
On Saturday, 25 May 2019 at 16:17:40 UTC, Robert M. Münch wrote: On 2019-05-25 14:28:24 +, Robert M. Münch said: How can I reset a rectangualr array without having to loop through it? int[][] myRectData = new int[][](10,10); myRectData.length = 0; myRectData[].length = 0; myRectData[][].length = 0; They all give: slice expression .. is not a modifiable lvalue. My question was unprecise: I want to keep the first dimension and only reset the arrays of the 2nd dimension. So that I can append stuff again. myRectData[] = null;
Re: compiler does not detect accessing on null class object.
On Monday, 27 May 2019 at 15:29:32 UTC, Daniel Kozak wrote: On Monday, 27 May 2019 at 15:13:00 UTC, dangbinghoo wrote: hello, 1.) Yes this is by design. It is not easy to detect this at compile time. It does not break safety 2.) https://dlang.org/spec/function.html#function-safety https://dlang.org/spec/memory-safe-d.html https://dlang.org/articles/safed.html#safed-subset thanks a lot. so, The SafeD Subset consists of [function-safety, memory-safety].
Re: rdmd takes 2-3 seconds on a first-run of a simple .d script
On Monday, 27 May 2019 at 07:16:37 UTC, BoQsc wrote: On Sunday, 26 May 2019 at 20:37:36 UTC, Jon Degenhardt wrote: [...] The desktop computer I'm testing this on contains Solid State Drive, a Windows 10 Home Operating system and about 7-9 years old of hardware. But remember, we are living in a 21 century, the hardware performance is great, even for the old hardware that is 10 years old, especially the desktops. I tried to disable Windows Defender real-time protection, it didn't helped to speed up rdmd. However until I test it on Linux, I can't be sure if Windows do not have other less obvious quirks that could slow down third party programs such as D compiler or rdmd. I can confirm, without measuring the exact timing, "dmd -run test.d" feels much faster than "rdmd test.d". I would say 1 second instead of 2 seconds. Kind regards André
Re: rdmd takes 2-3 seconds on a first-run of a simple .d script
On Sunday, 26 May 2019 at 20:37:36 UTC, Jon Degenhardt wrote: On Saturday, 25 May 2019 at 22:18:16 UTC, Andre Pany wrote: On Saturday, 25 May 2019 at 08:32:08 UTC, BoQsc wrote: I have a simple standard .d script and I'm getting annoyed that it takes 2-3 seconds to run and see the results via rdmd. Also please keep in mind there could be other factors like slow disks, anti virus scanners,... which causes a slow down. I have seen similar behavior that I attribute to virus scan software. After compiling a program, the first run takes several seconds to run, after that it runs immediately. I'm assuming the first run of an unknown binary triggers a scan, though I cannot be completely sure. Try compiling a new binary in D or C++ and see if a similar effect is seen. --Jon The desktop computer I'm testing this on contains Solid State Drive, a Windows 10 Home Operating system and about 7-9 years old of hardware. But remember, we are living in a 21 century, the hardware performance is great, even for the old hardware that is 10 years old, especially the desktops. I tried to disable Windows Defender real-time protection, it didn't helped to speed up rdmd. However until I test it on Linux, I can't be sure if Windows do not have other less obvious quirks that could slow down third party programs such as D compiler or rdmd.
Re: Instantiate templated class at runtime
On Sunday, 26 May 2019 at 17:51:37 UTC, Aphex wrote:
1. Is it possible to have a runtime class and struct creator
function that can deal with templates. It doesn't seem like it
should be that big a deal. One only needs to actually know the
size of class and that will depend on the template parameter
sizes, which if they are known then everything is known?
The root problem is described in
https://issues.dlang.org/show_bug.cgi?id=2484. In short, the D
runtime keeps track of all class types and lets you search
through them and instantiate them if you wish. Sadly, this
doesn't cover templated classes, in part because an instantiation
of a templated class is not necessarily in the module that
defined it, and because there may be multiple identical
instantiations across multiple modules.
Now, templated classes still have .classinfo members, and these
can be used with _d_newclass to create new instances of the
class. I filed an issue with Orange for this:
https://github.com/jacob-carlborg/orange/issues/57
2. Is the output or Orange for templated classes correct?
"Issue1.Y!string.Y" or should it be "Issue1.Y!string"? Else
this is a bug that I'll need to track down and fix.
The name Issue1.Y!string.Y is correct - 'class Y(T) {}' is short
for 'template Y(T) { class Y {} }'.
--
Simen
Adding a payload to a type
I have some types I've declared and I'd like to magically extend them and add data. The problem is I inheriting from them them is bad news. Suppose, for example, I have an image type that is used in an application. For a small part of the application it needs to associate with each image type an xy coordinate type that adds a coordinate to the image to be used by the part of the app that needs to have coordinates for the image. The rest of the app does not care or need the xy coordinates. Inheritance solves this problem in some sense except it doesn't. If I want to add new data then it breaks. class image; class xy : image; // can only add an image. class z : ??; ?? could be xy, image, or something else Inheritance is not the correct thing to do here. I only want to associate data with an object. The hierarchy does not matter. I could add a payload type to image but this causes problems since it would have to be void or of a singular type. Mainly it causes problems with the serializer I'm using since it can't handle voids(I might be able to get it to work with a special type but it will not be easy). I could, of course, add a parallel struct that somehow associates the image it's extra data but to keep them in sync will not be easy since it will have to persist between runs(so the address could not be used). One could think of what I'm trying to do is create a tuple that holds the image and any other data. tuple(tuple(image, xy), z) // the outer tuple may occur later without knowing that the image has been "wrapped". How does one normally handle this? It seems like something really simple to do(attach data) but it has no real programmatic way to do naturally that works with oop. The main thing is that attaching different data should "stack" and not effect the base type or break the type hierarchy. If something takes an image it should take any extended object. I feel like the only way to do this is to create a special type that can be serialized properly and is part of the base class... I'll have to do it for all the classes. Hopefully someone has some better ideas?
Re: Adding a payload to a type
On Monday, 27 May 2019 at 08:40:45 UTC, Amex wrote:
I have some types I've declared and I'd like to magically
extend them and add data. The problem is I inheriting from them
them is bad news.
Suppose, for example, I have an image type that is used in an
application. For a small part of the application it needs to
associate with each image type an xy coordinate type that adds
a coordinate to the image to be used by the part of the app
that needs to have coordinates for the image. The rest of the
app does not care or need the xy coordinates.
Inheritance solves this problem in some sense except it
doesn't. If I want to add new data then it breaks.
class image;
class xy : image; // can only add an image.
class z : ??; ?? could be xy, image, or something else
Inheritance is not the correct thing to do here. I only want to
associate data with an object. The hierarchy does not matter.
I could add a payload type to image but this causes problems
since it would have to be void or of a singular type. Mainly it
causes problems with the serializer I'm using since it can't
handle voids(I might be able to get it to work with a special
type but it will not be easy).
I could, of course, add a parallel struct that somehow
associates the image it's extra data but to keep them in sync
will not be easy since it will have to persist between runs(so
the address could not be used).
One could think of what I'm trying to do is create a tuple that
holds the image and any other data.
tuple(tuple(image, xy), z) // the outer tuple may occur later
without knowing that the image has been "wrapped".
How does one normally handle this? It seems like something
really simple to do(attach data) but it has no real
programmatic way to do naturally that works with oop.
The main thing is that attaching different data should "stack"
and not effect the base type or break the type hierarchy. If
something takes an image it should take any extended object.
I feel like the only way to do this is to create a special type
that can be serialized properly and is part of the base
class... I'll have to do it for all the classes. Hopefully
someone has some better ideas?
There's of course many different ways to skin a cat. Here's my
first idea:
class Image {
// regular image stuff
Metadata[] metadata;
T getMetadata(T : Metadata)() {
foreach (e; metadata) {
if (cast(T)e !is null) {
return cast(T)e;
}
}
return null;
}
}
abstract class Metadata {}
class Coordinates : Metadata {
int x, y;
this(int x, int y) {
this.x = x;
this.y = y;
}
}
unittest {
auto img = new Image();
img.metadata ~= new Coordinates(1,2);
auto coords = img.getMetadata!Coordinates;
assert(coords.x == 1);
assert(coords.y == 2);
}
This could easily be extended to support multiple metadata of the
same type by adding a name field or such.
--
Simen
Re: Does slicing have an effect?
On Tuesday, 21 May 2019 at 20:44:49 UTC, rikki cattermole wrote: On 22/05/2019 8:31 AM, Dennis wrote: Does slicing have an effect I'm not aware of, or is this a bug? It could have an effect if a was a struct/class via operator overloads. But in this case it should probably be a bug. It doesn't look right, even for custom types; because D (and in particular Walter) is against changing the meaning of operators when overloading (e.g. << in C++). At least unofficially, although I may recall it is enforced at a few places elsewhere. Going back to the original question, it may be a bug (for arrays). And if so and if D wants to enforce consistent operator semantics when possible, it may be considered a bug for any type.
