Re: D for BigData: the first BetterC library by Tamediadigital
On Monday, 2 May 2022 at 05:22:07 UTC, test123 wrote: https://forum.dlang.org/post/hngfeheyklalzoxky...@forum.dlang.org On Saturday, 25 February 2017 at 14:32:00 UTC, Ilya Yaroshenko wrote: HyperLogLog++ is advanced cardinality estimation algorithm with normal and compressed sparse representations. It can be used to estimate approximate number of unique elements in an unordered set. hll-d [1, 2] is written in D. It can be used as betterC library without linking with DRuntime. hll-d has C header and C example. Its implementation is based on Mir Algorithm [3] 1. mir.ndslice.topology.bitpack is used for arrays composed of packed 6bit integers 2. mir.ndslice.sorting.sort is used for betterC sorting. [1] Git: https://github.com/tamediadigital/hll-d [2] Dub: http://code.dlang.org/packages/hll-d [3] Mir Algorithm: https://github.com/libmir/mir-algorithm Best regards, Ilya Thanks for the great work. I check the c api, can not figure out how to get the count number for one element. For example if I use it as IP counter, is there a way to know how much count for one IP has been add into set ? No, that's not what this is for. Hyperloglog is useful if you have a big dataset that may contain duplicates and you want to know how many unique items you have (with a reasonnable probability). For example, as a website, this can be used to estimate how many visitors you have without having to store every single IP address to check for duplicates at new connections. The tradeoff is that it's probabilistic: you don't need to store every address so you need much less space and time to get a count of unique ips, but you have to accept a margin of error on that result and you can't know what the IPs were in the first place, just how many of them there are.
Re: I like dlang but i don't like dub
On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote: Dlang includes some good ideas. But dub pulls in so much stuff. Too much for me. I like things which are clean,lean,little,small. But when i use dub it links with so many libraries. Are they really needed ? And how do you compare to pythons pip. Feel free to elaborate. Long story short, dub isn't needed. If you prefer pulling dependencies and compiling them by hand nothing is stopping you. As for comparison to pip, I'd say that dub compares favourably actually. Yes, it does do more than pip, and that used to annoy me. But if you look at it from the stance of a user it makes sense: when you pull dependencies or a package using pip you expect to be able to run them immediately. Python isn't a compiled language, but D is and to get these packages and dependencies to be run immediately it needs to do more than pip: download dependencies, manages their version and compile them. This last part is the reason for most of the added complexity to dub IMHO.
What Mike thinks
On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote: What Mike thinks appears nowhere in my post :-) That's a bit sad. I understand that in your position it may be hard to express a personnal opinion but I think anyone should get the opportunity to do so. Would you like, in no official capacity whatsoever, to provide your personnal take on the matter? I think you should get to express your feelings as well :) But of course I would understand if you don't want to get involved in any particular issue.
Re: I need an Easy example to understand Alias This
On Tuesday, 7 July 2020 at 00:44:32 UTC, Marcone wrote:
On Tuesday, 7 July 2020 at 00:42:40 UTC, Ali Çehreli wrote:
On 7/6/20 5:35 PM, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias
this. I need an Easy example to understand Alias This.
Is the following example useful?
http://ddili.org/ders/d.en/alias_this.html
Ali
I can't undestand it. I need a simple example.
This only scrapes the surface, but it should give an idea of the
core mechanics and why it's regarded as an important concept.
import std.stdio;
struct Fruit {
string name;
}
struct ColoredFruit {
Fruit _fruit;
alias _fruit this;
string color;
}
void printColoredFruit(ColoredFruit f) {
writeln(f.color, " ", f.name);
}
void printGeneralFruit(Fruit f) {
writeln(f.name);
}
void main(string[] args) {
ColoredFruit banana;
banana.color = "yellow"; // It's a normal struct for its
non-alias members
banana.name = "banana"; // We can interact with internal
fields directly
// This function accepts a ColoredFruit so the whole banana
is passed.
printColoredFruit(banana);
// > yellow banana
// This function only doesn't accept a ColoredFruit, but it
does accept a
// Fruit and we have a Fruit alias this so the internal
_fruit is passed.
printGeneralFruit(banana);
// > banana
}
Re: A security review of the D library Crypto
On Saturday, 4 July 2020 at 14:37:41 UTC, H. S. Teoh wrote: I'm not the author, but I'm curious about the D implementation of Botan (https://code.dlang.org/packages/botan) -- how is its security level? I glanced at it before and it seemed OK, but it'd be really nice to have a 3rd party opinion, esp. from someone who's skilled with cryptanalysis. T I can't say much at the moment. Botan is another beast altogether and lots of work is going to be required to get any certitude. What I can say is that it's a nice library, ported from a library that has been audited in the past and is still actively maintained. A cursory shows none of the issues found in Crypto. Everything seems really good. The main issue with Botan from a design standpont may be its completeness. It's great if you are building off an established project or protocol and need specific algorithms. If you're starting a new project from scratch though more options mean more ways to potentially chose a bad one. I mentionned libsodium in a previous answer; this is the kind of opiniated library that is well suited to that type of new projects. But really, it's hard to say anything bad when the project's wiki starts with a list of books and resources to learn cryptography prior to using the library [1]. I don't know the author but at least it seems like he knows what he's messing with. So, to conclude, based on that preliminary look alone I would feel confident about recommending Botan since I don't expect any major issue. But I'll still need to find the time to properly review it someday, be it only for my own peace of mind. [1]: https://github.com/etcimon/botan/wiki
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote: On Wednesday, 1 July 2020 at 07:19:11 UTC, Cym13 wrote: Here's what you should know if you are a user: RSA, as implemented in the library, is still very much broken. I do not recommend using it. The confidentiality and integrity of all messages exchanged using this library must be questionned: if you exchanged sensitive information such as passwords using it I recommend to change them since their security is not guaranteed. [snip] Thanks for the article. IMO it was as clear for non-professionals as crypto can be: Even I (non-crypographer) understood what's the problem with padding with only one byte. Thank you for that feedback. It also illustrates what's the prolem with cryptography: it's like coding without ability to test. Who could even dream to get that right the first or even the second time? I think there a shortcoming in the "don't roll your own crypto" - advice: One could think it only applies to the algorithms, not the implementation. That's what I did when I first heard it. There's one more element missing here: the protocol. Cryptography isn't about encrypting stuff, it's about protecting secrets from start to finish and that includes the protocol used. To take an example, many people can think "Hey, I need encryption between my two servers, I'll use AES" and stop there. But use AES how? What mode (CBC,GCM,...)? Let's say CBC is used, what about message authentication? Can I just modify your stream? How is the key exchanged? How is the key generated? Etc. People tend to focus on encryption, be it algorithm or implementation, but once you've got bricks it's still a pain to put them together in a solid way. Things like TLS or SSH actually combine at least 3 completely different sets of bricks to establish the communication, authenticate it, secure it once established etc. So, in a way, "don't roll your own crypto" means "use TLS as much as possible" :) If one needs to use cryptography, would redundancy help? I mean, encode and decode the message with say three different algorithms from different libraries, so that the attacker would need to find a weakness in all of them? That's a good question. The general answer is: no. The more detail answer is: in some cases it can help (I know of one client for example that doesn't trust national standards and has layered US technology with Russian technology to make sure that at least one layer stands). However in the general case we can prove that the security of the combination is less than or equal to the security of the better of the elements of that combination. In some cases badly choosen algorithm actually counteract each other leading to easier attacks. My general advice is to stay true to well audited implementations of good standards. I like opiniated libraries in that context so I'd say "whatever libsodium implements".
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 07:49:27 UTC, Arafel wrote: As somebody who also was somewhat involved in infosec and cryptography in a previous life, I found your article really interesting. So, first of all, thanks for taking the time to do the review and for publishing the results! I see that you mostly focus on the algorithms, but did you also check for side-channel attacks (for instance, timing attacks), or given the flaws already found it would make little sense to go deeper? Fixing the issues from the article would require a huge amount of code changes, so I saw little point in timing the library as is. It must do the right thing before doing it the right way. I find that following a well-known algorithm is just the easy part when implementing crypto... the hard one is ironing out those pesky "implementation details". That's one of the reasons why I would try to use one of the "big" libraries for cryptography instead of rolling out my own, even if it meant adding an external C/C++ dependency to my project. I can definitely vouch for that.
A security review of the D library Crypto
As some of you may know one of my hobbies is to review open source software for security issues. About a year ago I reviewed the RSA implementation of Crypto[1]: a native D library which, according to dub statistics, is fairly popular. Issues were found and after discussion with the author I decided to wait for them to be fixed. A year later I would like to present the results of an updated review of the library: https://breakpoint.purrfect.fr/article/review_crypto_d.html Here's what you should know if you are a user: RSA, as implemented in the library, is still very much broken. I do not recommend using it. The confidentiality and integrity of all messages exchanged using this library must be questionned: if you exchanged sensitive information such as passwords using it I recommend to change them since their security is not guaranteed. “Is this really the place to have this discussion? Shouldn't this be between the author and you?“ The author was contacted a year ago and although our discussion was kind and productive I have not heard from him since. Most of the issues present today were already present in my first assessment. Some modifications were made, but most recommendations were ignored. After a year without action I feel that the users should know exactly what they are exposed to since they are the ones affected by these security issues. This follows standard vulnerability disclosure processes. For all details and analysis I direct you to the blog post. It is a rather thorough and technical read so I would recommend grabbing a cup of tea first. If you find any mistake or unclear parts I'll be glad to correct it so feel free to point it out. Furthermore if you would like someone to have a look at your project to identify issues I am always glad to help free and open source projects that can't afford security review through traditional means so feel free to reach out. [1] https://code.dlang.org/packages/crypto
Re: Program exited with code -11 when calling
On Wednesday, 1 July 2020 at 05:04:28 UTC, Anthony wrote:
I'm trying to convert this c function:
bson_t *bson_new_from_json (const uint8_t *data, ssize_t len,
bson_error_t *error);
Into a D function. This is my attempt:
extern(C) {
struct bson_t;
struct bson_error_t;
bson_t* bson_new_from_json(const uint8_t* data, long len,
bson_error_t* error);
}
However when I try it, for example:
auto str_utf8 = str.toUTF8();
bson_error_t error
auto bson = bson_new_from_json(cast(const
uint8_t*)str_utf8.ptr, -1, );
I get a "Program exited with code -11" message.
Does anyone know what I'm doing wrong?
Thanks
I don't know the exact function you are trying to use, but -11
means "segmentation fault" on linux. This means that your program
is trying to read or write a memory location that it is not
supposed to. This typically happens during buffer overflows and
similar memory corruption bugs.
One thing that jumps to me is the -1 in your call instead of the
length. Without knowing the C function's implementation I would
expect it to mean either "read before the array" which would be a
buffer overflow or to have the special meaning of "deduce the
string size yourself". In that last case I would expect
bson_new_from_json to expect a NUL-terminated array, but I don't
know if your UTF8 array is NUL-terminated.
Re: Novelate - Visual Novel Engine
On Thursday, 23 January 2020 at 15:19:34 UTC, bauss wrote: Novelate is a visual novel engine written in D. It officially binds to SFML but the engine itself has no direct dependencies on SFML as there's plans for supporting libraries such as SDL etc. in the future too. It's still a work-in-progress but the basics are done as of now and it has reached a point where publishing it as open-source is possible. Preview: https://i.imgur.com/YyoIWkp.png For more information see: Github: https://github.com/Novelate/NovelateEngine Dub: https://code.dlang.org/packages/novelate A website with documentation etc. is coming soon as well! Thank you! Love the initiative, I'll be sure to keep an eye on this!
Re: weekly news?
On Wednesday, 22 January 2020 at 18:53:49 UTC, mark wrote: Is there a "D weekly news" I could do an email subscription to? Or at least a way to get notified by email when a new item appears on https://dlang.org/blog/ ? There's http://dpldocs.info/this-week-in-d/Blog.html which is unofficial but interesting and weekly. AFAIK there's no newsletter but it provides a RSS feed. Otherwise I think the easiest is to use the fact that this forum isn't a forum but a newsgroup (hence available by mail) to subscribe to Announce. Blog entries in particular are announced there.
Re: Speed of Random Numbers
On Saturday, 3 August 2019 at 16:35:34 UTC, Giovanni Di Maria
wrote:
Hi to everybody
I am doing some experiments about random numbers.
I need "extreme speed" for the generation for numbers from 1 to
8.
Generating 500_000_000 numbers with this code:
-
import std.stdio, std.array, std.random;
void main()
{
byte c;
writeln("Start");
for(int k=1;k<=500_000_000;k++)
c=uniform!ubyte() % 8 +1; //<<< === RANDOM
writeln("Stop");
}
-
I get these results:
c=uniform!ubyte() % 8 +1; ==>>> Execution time: 15.563 s
c=cast(byte)uniform(1, 9); ==>>> Execution time: 24.218 s
Do you know other faster functions or methods to generate
random numbers?
For me the "goodness of random" is NOT important.
Thank you very much
GIovanni Di Maria
To what extent isn't the quality of randomness important to you?
Your posts reminds me of the way Doom (the original) did it for
things like enemy behaviour and shot dispersion: they generated a
static table of 256 random numbers once and any time they needed
a random byte they just picked the next in the table. They didn't
have any security or sciency concern and just wanted to provide a
different game each time so that worked well for them. You won't
find anything faster than that I think.
Re: Question on Password Encryption, using stdlib or third party lib
On Monday, 29 July 2019 at 14:37:54 UTC, 0x wrote: On a project I was asked to a- Compute SHA-256 of a password b- Do a BigInteger, convert to Hex String c- Encrypt the key using a public key with the following parameters Entropy: I'm given some numbers Modulus: also given long numbers [encrypt using RSA algorithm] So far I'm familiar with a and b in Dlang. how do I go about c) In Dlang ? Thanks I hope it's for a school project since I wouldn't recommend doing that in production. However you can do c) either by implementing RSA (it's rather easy to badly implement RSA which could be enough at school level) or by using a library (I recommend the library). There are several cryptographic libraries on https://code.dlang.org that implement RSA, botan and crypto for example. I'd trust botan more at the moment though I don't think any D library has received a proper cryptographic audit at the moment.
Re: To learn D
On Friday, 5 July 2019 at 12:00:15 UTC, Binarydepth wrote: I've considering learning full D. I remembered that D is not recommended as a first language, So I read time ago. So my question, is learning C and Python a good intro before learning D? TY Both C and Python provide valuable and complementary experience no matter what you want to do. If your goal is specifically to learn D then I'd learn C up to structures. That way you'll have basic tools and vocabulary that you can reuse in D and you can learn the rest as you go. The things that will be hard if you want to learn D directly: - not as many examples and tutorials on the internet (although there are some very good ones) - lots of concepts and vocabulary (always remember that you *don't* have to know every detail of the language, learn what you need to solve the problem at hand, one thing at a time) - not as many libraries, which means that it can be harder to solve a problem that not many people have had yet (popular things like web applications will be alright) I think D isn't that bad of a first language. Once you've passed the vocabulary barrier you'll get the benefit of having a language that'll fit most of your tasks from little scripting or web applications to low-level programming and big projects. You will be confronted to many concepts and ideas without having to learn a new language each time and this knowledge is useful even if you decide to use another language later on.
Re: A tutorial teaching the basics about multimedia with the arsd library
On Sunday, 30 June 2019 at 23:46:27 UTC, Murilo wrote: Hi everyone, I am writing a tutorial teaching the basics about multimedia programming using the arsd library. This is a library all D programmers should have since it is very useful and easy. In this tutorial I will teach in a fun and easy way how to use it for GUIs, image displays, games, etc... Here is the GitHub link: https://github.com/MuriloMir/arsd_multimedia_tutorial And please join the official facebook Dlang group: https://www.facebook.com/groups/ProgrammingInD/ I really dislike that you use screenshots of code, it makes copy-pasting impossible. There are ways to produce pdfs with colored, copyable source code (like using RST for redaction then rst2pdf for production, but I'm not sure it'll be the easiest for you).
Re: Closures and memory allocation
On Saturday, 22 June 2019 at 19:26:13 UTC, Cym13 wrote: On Saturday, 22 June 2019 at 16:52:07 UTC, Anonymouse wrote: [...] Clearly this is a good time for you to learn about the tools D offers to profile allocations. There is the --profile=gc DMD argument that you can use but here there's something better: DMD's GC has a few hooks that are directly inside druntime and therefore available to any D program. [...] Ooops, sorry I went a bit fast there, --DRT-gcopt gives you the number of collections, not allocations.
Re: Closures and memory allocation
On Saturday, 22 June 2019 at 16:52:07 UTC, Anonymouse wrote: I'm looking into why my thing does so many memory allocations. Profiling with kcachegrind shows _d_allocmemory being called upon entering a certain function, lots and lots of times. It's a function that receives concurrency messages, so it contains nested functions that close over local variables. Think receiveTimeout(0.seconds, , , , ...) with 13 pointers to nested functions passed. When entering the following function, does it allocate: 1. 0 times, because while there are closures defined, none is ever called? 2. 2 times, because there are closures over two variables? 3. 20 times, because there are 20 unique closures? Clearly this is a good time for you to learn about the tools D offers to profile allocations. There is the --profile=gc DMD argument that you can use but here there's something better: DMD's GC has a few hooks that are directly inside druntime and therefore available to any D program. Putting your above code in test.d you can then do: $ dmd test.d $ ./test --DRT-gcopt=profile:1 Number of collections: 2 Total GC prep time: 0 milliseconds Total mark time: 0 milliseconds Total sweep time: 0 milliseconds Max Pause Time: 0 milliseconds Grand total GC time: 0 milliseconds GC summary:1 MB,2 GC0 ms, Pauses0 ms <0 ms And here is your answer: two allocations. More information about --DRT-gcopt there: https://dlang.org/spec/garbage.html
Re: my first kernel in betterC D
On Wednesday, 19 June 2019 at 23:31:40 UTC, Laeeth Isharc wrote: On Wednesday, 19 June 2019 at 13:45:45 UTC, matheus wrote: ... One aspect of that is just showing something is possible. Adam Ruppe's talk at dconf a while back has had a lasting influence on how we approach things, mostly for giving me permission to do what I'm naturally inclined to do anyway. If you're not sure then bet a little time to try - the worst thing that can happen in user code is a segfault and so what. What talk is that exactly?
Re: make C is scriptable like D
On Thursday, 20 June 2019 at 06:20:17 UTC, dangbinghoo wrote:
hi there,
a funny thing:
$ cat rgcc
#!/bin/sh
cf=$@
mycf=__`echo $cf|xargs basename`
cat $cf | sed '1d' > ${mycf}
gcc ${mycf} -o a.out
rm ${mycf}
./a.out
$ cat test.c
#!/home/user/rgcc
#include
int main()
{
printf("hello\n");
}
And then,
chmod +x test.c
./test.c
output hello.
is rdmd implemented similarly?
thanks!
binghoo
Basically, yeah.
Re: Where can find fix length array memory layout document
On Wednesday, 19 June 2019 at 05:27:12 UTC, lili wrote:
On Tuesday, 18 June 2019 at 17:29:49 UTC, Cym13 wrote:
On Tuesday, 18 June 2019 at 17:25:42 UTC, Cym13 wrote:
On Tuesday, 18 June 2019 at 13:05:03 UTC, lili wrote:
On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote:
[...]
Thanks a lot, where is a core.stdcpp.array , How to user it?
I test but get a error
```
auto aa = array!(int, 4); //error
```
Please don't shorten your code or errors to the point where
there's hardly any information left: it's hard to help you if
we can't know what you did and what went wrong.
Forgot to say that it's probably because you don't actually
build an array here, try adding parentheses:
```
auto aa = array!(int, 4)();
```
array!(int,4)(); compile occurs a error say: no overload
matches for array
Did you import it properly?
```
void main() {
import core.stdcpp.array;
auto a = array!(int, 4)();
}
```
compiles and runs without issue for me. You'll have to show your
code if you want people to help you there.
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 17:25:42 UTC, Cym13 wrote: On Tuesday, 18 June 2019 at 13:05:03 UTC, lili wrote: On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote: [...] Thanks a lot, where is a core.stdcpp.array , How to user it? I test but get a error ``` auto aa = array!(int, 4); //error ``` Please don't shorten your code or errors to the point where there's hardly any information left: it's hard to help you if we can't know what you did and what went wrong. Forgot to say that it's probably because you don't actually build an array here, try adding parentheses: ``` auto aa = array!(int, 4)(); ```
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 13:05:03 UTC, lili wrote: On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote: On Tuesday, 18 June 2019 at 12:26:14 UTC, lili wrote: [...] I'm assuming you mean writeln([1].sizeof). An array literal is a slice of a dynamic array (which is length + pointer, so 2*size_t size). A fixed size array has to be declared as a local / member variable, and then the content is on the stack: ``` int[10] a; writeln(a.sizeof); // 40 writeln(a[].sizeof); // 16 on 64-bit or 8 on 32-bit ``` To get a static array literal, you can use the library function staticArray: ``` import std.array; writeln([1, 2, 3].staticArray.sizeof); // 12 ``` Thanks a lot, where is a core.stdcpp.array , How to user it? I test but get a error ``` auto aa = array!(int, 4); //error ``` Please don't shorten your code or errors to the point where there's hardly any information left: it's hard to help you if we can't know what you did and what went wrong.
Re: DConf 2019 Videos
On Wednesday, 5 June 2019 at 02:37:57 UTC, Mike Parker wrote: On Tuesday, 4 June 2019 at 09:58:26 UTC, Mike Parker wrote: I can't predict how long it will take, but when I get the first one uploaded I'll post a notification in this thread so that everyone can follow as they go up. I'll go in the order of the schedule from Day 1 to Day 3. The DConf 2019 playlist is available at: https://www.youtube.com/playlist?list=PLIldXzSkPUXWORGtUrnTo2ylziTHR8_Sq Walter's keynote is up now. Others will be available soon. Again, I can't predict how long until they're all up, but they're coming. I was pretty worried about the videos because of past issues but I must say that those videos are great, the sound is good, it's readable and enjoyable to watch, and they're on time. Thanks everyone for a job well done on that front.
Re: What does ! Stand for in map! and filter! function calls?
On Sunday, 2 June 2019 at 15:48:54 UTC, Rnd wrote: I have recently started using Dlang, hence this basic question. Thanks for your insight. To know more about D you should take the time to do the D tour [1] which provides you with general knowledge of most of D's functionalities and vocabulary. To know more about templates specifically, check out this tutorial [2]. [1]: https://tour.dlang.org/ [2]: http://nomad.uk.net/articles/templates-in-d-explained.html
Re: Why GNU coreutils/dd is creating a dummy file more efficiently than D's For loop?
On Thursday, 23 May 2019 at 09:09:05 UTC, BoQsc wrote:
This code of D creates a dummy 47,6 MB text file filled with
Nul characters in about 9 seconds
import std.stdio, std.process;
void main() {
writeln("Creating a dummy file");
File file = File("test.txt", "w");
for (int i = 0; i < 5000; i++)
{
file.write("\x00");
}
file.close();
}
While GNU coreutils dd can create 500mb dummy Nul file in a
second.
https://github.com/coreutils/coreutils/blob/master/src/dd.c
What are the explanations for this?
If you're talking about benchmarking it's important to provide
both source code and how you use/compile them. However in that
case I think I can point you in the right direction already:
I'll suppose that you used something like that:
dd if=/dev/zero of=testfile bs=1M count=500
Note in particular the blocksize argument. I set it to 1M but by
default it's 512 bytes. If you use strace with the command above
you'll see a series of write() calls, each writting 1M of null
bytes to testfile. That's the main difference between your code
and what dd does: it doesn't write 1 byte at a time. This results
in way less system calls and system calls are very expensive.
To go fast, read/write bigger chunks.
I may be wrong though, maybe you tested with a bs of 1 byte, so
test for yourself and if necessary provide all informations and
not just pieces so that we are able to reproduce your test :)
Re: is there a way to embed python 3.7 code in D program?
On Sunday, 12 May 2019 at 20:06:34 UTC, torea wrote: Hi, I'd like to use D for the "brain" of a small robot (Anki vector) whose API is coded in Python 3.6+. I had a look at Pyd but it's limited to python 2.7... Would there be other ways to call python functions and retrieve the python objects (including camera image) inside a D program? Best regards If pyd doesn't work you still have the option to use python's C interfaces (it has many). Write your D program normally, provide extern(C) functions as an interface and have python call those. There are some caveats but lots of resources exist on calling C from python and calling D from C. I haven't checked but it's also probable that this is how pyd does it, have a look if you want to reproduce its functionalities. Pyd is easier to use, but it's not the only way.
Re: [windows] Can't delete a closed file?
On Friday, 10 May 2019 at 15:06:46 UTC, Temtaime wrote: Lol, you don't have to load and unload the curl dll. std.net.curl have its own lazy libcurl loader. But i'm not sure if it tries to find the dll in the temp directory. If it is the case, then it simply doesn't unload the dll when you have called some function from it. As I said it's more about the general idea of bundling DLLs in than libcurl itself, but even in that case it doesn't search the temp directory for it. Besides, if it did, it would be a pretty important vulnerability.
Re: In what situation can new Struct() return null?
On Friday, 10 May 2019 at 10:11:51 UTC, faissaloo wrote: My program contains the following statement: auto newChildNode = new Node(); In debugging I have found that this pointer evaluates to null, what could cause this? I should have plenty of memory, my only other idea is some sort of heap corruption. Could you share a complete, concise, compilable example demonstrating that bug? One line is rather short to understand what's happening.
Re: [windows] Can't delete a closed file?
On Friday, 10 May 2019 at 07:09:45 UTC, Seb wrote: On Thursday, 9 May 2019 at 13:18:44 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote: On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: [...] You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue. Which C runtime are you using? The old and buggy DigitalMars one or the official MS one? I really don't know, how can I find out? I litterally just used dmd on the script above with no special options then ran the resulting exe.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 15:05:10 UTC, Andre Pany wrote: Can you reproduce the issue with other Dlls or is it only reproducible with curl dll? Does the issue with curl dll also exists if you do not call the curl function? Kind regards Andre I didn't have the time to test with another dll just yet but in that specific case the issue disappears if I don't call its functions. That's interesting.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote: On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote: ... To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result. For reference my windows system is a 64b windows 10. You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote: ... To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result. For reference my windows system is a 64b windows 10.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 11:07:53 UTC, Andre Pany wrote: On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote: Hi, this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file. [...] I can't explain the behaviour, but you could store the temp file name in a string array and remove these file in the module destructor. That's the way how dub handles temp files/folders. https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L98 Kind regards Andre No luck there.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 11:11:56 UTC, Rumbu wrote: Since deploying a dll is a suspect behaviour outside a normal installation process, most probably you have a lock on the file put by windows defender or an antivirus if installed. Thanks for your input but I'm absolutely certain that it's not related to AV since I made sure to test in an AV-free environment (and I'd expect AV to kick in before loading the DLL, but I may be wrong on that). FreeLibrary doesn't guarantee that the dll file is closed, maybe other windows processes are accessing it (like prefetch). Anyway, you are deploying a dll just to read a file, It's over engineering, use WinAPI UrlDownloadToFile instead or any other winapi functions. Well, that's just a test script, it's feature or DLL doesn't matter.
[windows] Can't delete a closed file?
Hi,
this is likely not related to D itself but hopefully someone can
help me with this since I'm rather new to windows programming, I
mainly work on linux. I'm trying to bundle a DLL in a binary,
write it in a temp folder, use it and remove the dangling file.
So far I have the following file:
import std;
void main(string[] args) {
import core.runtime;
static immutable libcurl = import("libcurl.dll");
import std.file: write;
auto libpath = tempDir.buildPath("libcurl.dll");
libpath.write(libcurl);
auto libcurlMem = rt_loadLibrary(libpath.toStringz);
import std.net.curl;
"https://dlang.org/".byLine.count.writeln;
rt_unloadLibrary(libcurlMem);
remove(libpath);
}
Compiled with: dmd.exe -Jlibdir test.d
It almost work, I can write, load and use the library, but when
it comes to
removing it nothing works.
std.file.FileException@std\file.d(1045):
C:\users\cym13\Temp\libcurl.dll: Access denied.
0x00402377 in EntryPoint
0x00413BC7 in EntryPoint
0x00413B49 in EntryPoint
0x004139E3 in EntryPoint
0x0040B77F in EntryPoint
0x7B4754C2 in call_process_entry
0x7B477FC6 in ExitProcess
0x7B4754CE in call_process_entry
I tried using an explicit File handle to explicitely close the
file after
writing to it but that doesn't change anything.
I'm pretty sure I'm missing something basic about the way windows
handles
open files but I don't know what, could someone explain why this
doesn't work
the way I expect it to?
Re: [DCONF] Is the even streamed?
On Wednesday, 8 May 2019 at 07:22:05 UTC, Cym13 wrote: Hi, I haven't found any information related to streaming of the event. Is there any way for non-participant to see these conferences? Also, will they be recorded? (Oops, this was supposed to be in General)
[DCONF] Is the even streamed?
Hi, I haven't found any information related to streaming of the event. Is there any way for non-participant to see these conferences? Also, will they be recorded?
Re: Erasing passwords from ram?
On Monday, 6 May 2019 at 09:34:22 UTC, Dukc wrote: Oops, I forgot to check back this theard. But yes, just the info I was looking for. On Wednesday, 1 May 2019 at 22:14:52 UTC, Cym13 wrote: There are very few relevant threat models where removing a password from RAM is an adequate solution. Not an adequate solution... What else is usually needed? You can't mean hashing, because by definition one would not want to delete the password in the first place, if there weren't hashes made of it. I'd rather focus on mitigating that threat by keeping boundchecking on, writing @safe code etc. I do. I was just curious if doing this trick brings any practical extra safety. (By what I understood from your reply, yes with operating systems or password managers but not generally with servers, unless trying to guard it from it's maintainers) And I'm also going to try to follow Walter's safety tip number 1: never assuming the server won't crash. I'm going to make an automatic restarter process for it. The thing is, the most important concept in security is the threat model: what are you protecting against? There is no security without a threat model, protecting your data without first knowing from what makes absolutely no sense, so that question is paramount. Then we compare the cost of a successful attack and the benefit one gets from that attack: if the attacker can make a profit it's not secure. If the defense cost is greatly superior to the value of your asset it's not well spent and those resources should most likely be spent protecting against something else. From what I understand your threat model is that of a remote attacker finding a vulnerability leaking memory in a heartbleed fashion then finding credentials in that leaked memory providing access to sensitive resources. That's a rather constrained scenario which is good, but it's also a very rare scenario. Very few memory issues lead to memory leakage, especially while providing a way to control what is leaked. Memory corruption vulnerabilities (I include out-of-bound reading) generally either result in a crash or can be exploited for code execution. If an attacker has code execution on your server the impact is bigger than that of memory disclosure and erasing credentials from memory doesn't mitigate that. But those bugs are way more common than controlled memory disclosure. However the solutions to memory corruptions are the same whether you're trying to protect against code execution or memory disclosure. So what I'm trying to say is that, given your threat model, it does not seem relevant to protect against memory disclosure specifically: you want to protect against the larger and more common threat of memory corruptions and that happens to cover your current threat model. Unless what you want to protect is very very sensitive erasing passwords from memory would most likely be wasted time. But that's something that only you can assess.
Re: Erasing passwords from ram?
On Tuesday, 30 April 2019 at 08:15:15 UTC, Dukc wrote: I am currently programming a server. So I got the idea that after I've generated all the hashes I need from a password, I want to erase it from RAM before discarding it, just to be sure it won't float around if the server memory is exposed to spyware by some buffer overflow. Is this wise caution, or just being too paranoid? And if it is worthwhile, do I have to do this: ``` foreach(ref part; cast(ubyte[]) rootPassword) volatileStore(, 0); ``` Or, can I rely on that the compiler won't optimize this out? ``` rootPassword[] = '\0' ``` `rootPassword` is allocated on the heap, but only locally referred to. There are very few relevant threat models where removing a password from RAM is an adequate solution, I'm not sure it's worth the trouble. For comparison one case where it's considered important is removing the master password from a password manager from RAM to prevent another person finding the computer unlocked to recover it by memory inspection (which it would have the rigth to do since the process would be from the same user). That's quite specific and a server isn't nearly as exposed. That said, if you want to remove it, make sure to audit all functions that use it from the moment it enters memory to check that they don't make a copy for some reason (or use a type that doesn't allow copies). It's no use removing it at one place if it's still at another. In particular a pattern I see often is that you have a function that reads the password from a file/stdin/whatever onto the stack and sets on the heap the object you'll use throughout the program then returns. You will think of checking the use of that object, but may forget to clear the setter's buffer before returning leaving it in a stack's frame. You should also make sure that your compiler isn't recognizing that this part of memory isn't used later and optimizing away the overwrite call. This is lots of work for a vulnerability that should not be there and may not lead to memory disclosure even if it is present. I'd rather focus on mitigating that threat by keeping boundchecking on, writing @safe code etc.
Re: Does D have a tool like pySnooper?
On Monday, 22 April 2019 at 16:24:53 UTC, Taylor Hillegeist wrote: Saw this tool and thought D could probably do something like this pretty easily. Is there such a tool out there already? https://github.com/cool-RR/pysnooper Or would this not be easy at all with D? First line of that link: "PySnooper is a poor-man's debugger". I don't think it is possible to do what PySnooper does at runtime without significantly changing the code you write to accomodate it, D and Python are just structured too differently. However I see no advantage in having something like PySnooper either because D has real debuggers. Using gdb you can do everything that pysnooper does, dynamically and with the corresponding lines of code. You also get much much more such as memory inspection, memory modification, disassembly or the magical ability to rewind time from a crash. PySnooper is nice for python, but I fail to see any advantage over a real debugger in D.
Re: Chat using Socket and Thread
On Tuesday, 23 April 2019 at 22:02:59 UTC, Allison wrote: How to make a chat for several users chat? Using socket and thread. First of all, there are many tutorials on the internet covering that exact topic for different languages. I don't think there are many tutorials for D, but you should definitely be able to understand the concepts and translate them, the vocabulary and strategy is the same. It's possible to guide you through the creation of such a chat but it sounds like a school exercise and if so you'll only benefit by trying them yourself as much as possible. So what did you try? What is your strategy? What didn't work? Where are you blocked? Why are you trying to do that in the first place?
Re: Future of D language
On Wednesday, 24 April 2019 at 05:22:35 UTC, Arjunkumar wrote: I am title bit confuse about learning D Lang and is it well good for future point of view. Currently in a market many of language is present, so why people learn D Lang and any site which provide best tutorials for D Lang? The reason I use D is because I like having one language that I can use for most tasks without having to worry that I might have to switch to another language later. If I need something low level I can do C-like programming and interface easily with C libraries. If I need something high level I can do that, if I want more safety guarantees that I'm not writing bugs D can help with that, if I need to port a program from another language D is likely to support its style already so porting is easier, producing executables for linux or windows is very easy, etc. Is it the best at something? I don't know, probably not, but it's good enough at everything that I can use it without worrying too much about the futur of my project. It's not all perfect though, the language itself is quite big and growing, bugs exists (well, what project doesn't have bugs?) and library support is not as extensive as some other langages. But it served me well so far.
DRuntime arguments
Where can I find a list of all druntime arguments supported? Things like --DRT-covopt='merge:1' or --DRT-gcopt='gc:profile=1' are not easy to guess and I can't find any centralized documentation.
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 15:41:51 UTC, Robert M. Münch wrote: I have an AA int[ulong] and would like to traverse the AA from biggest to smallest by value. Is there an elegant way to do this? The only way I can imagine is to create an "reverse" AA of the form ulong[int] and than sort by keys. Traverse this AA and use the value as the lookup key in the orginial array. But this feels all a bit wired... You could use sort to gather the indexes in order then traverse from there: aa.byKey.array.sort!((a, b) => aa[a]With a wrapper caching that order and making it transparent as well as update on insertion (which should be in log(n) since you know have an ordered list of indexes, you can use dichotomy to update the indexes without walking all your AA again) I think you could have a nice little container. However if double entry is necessary maybe a simpler 2D array would be easier to work with?
Re: Darser: A LL(1) to Recursive Decent Parser/AST/Visitor Generator
On Wednesday, 20 March 2019 at 17:20:48 UTC, Robert Schadek wrote: To get graphqld up and running I needed a parser/ast/visitor. Being lazy, I created parser/ast/visitor generated for that. [...] This looks nice! I'm familiar with pegged which uses PEG grammars, could you maybe comment on the differences and possible benefits of Darser in comparison?
Re: Why does D language do not support BigDecimal type?
On Monday, 11 March 2019 at 15:23:34 UTC, BoQsc wrote: There is Money datatype that can be provided by using a third party package: https://code.dlang.org/packages/money But that's only for money, what about math? Why such fundamental as BigDecimal is still not included into the D language itself? There is BigInt. If it is unavoidable to use Floating point, how can I quickly and simply understand the rules of using float to make the least error, or should I just find a third party package for that as well? There is an article on that, but it is not that straight forward: https://dlang.org/articles/d-floating-point.html Basically any thing that I find on Google, that include explaining floating point are badly written and hard to understand for the outsider lacking ability to understand advanced concepts. How much precision is enough in your use case? There's always a limit to how precise you need to be and how precise you can be, be it only because our memory is finite. I've never had a use case for BigDecimal myself, so forgive my ignorance, but wouldn't you get the exact same result by using BigInt? For example, if you need 20 decimals of precisions then any value times 10^20 will be a BigInt on which you can work, it's just a matter of displaying it correctly when outputing the result but it doesn't change the operations you have to perform. Is there anything that can't be done with BigInt really?
Re: Release D 2.085.0
On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote: Glad to announce D 2.085.0, ♥ to the 49 contributors. This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32. http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html ¹: There is a pending Objective-C fix (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will be released with 2.085.1 soon (~1.5 weeks). -Martin In the -preview/-revert it is said: As of now, DMD offers these reverts: -preview=dip25: Reverts DIP25 changes -revert=import: Revert to single phase name lookup Shouldn't that be "-revert=dip25" instead of -preview there?
Re: Executing a D script without an [extension in the filename] leads to an error
On Friday, 1 March 2019 at 11:38:51 UTC, BoQsc wrote: On Friday, 1 March 2019 at 09:27:33 UTC, Cym13 wrote: On Friday, 1 March 2019 at 09:00:43 UTC, BoQsc wrote: I've installed D compiler, and when i try to run a D script with filename without an extension/file type named: program via: ./program I'm getting and error: vaidas@SATELLITE-L855:~/Desktop$ ./program Error: module `program` is in file './program.d' which cannot be read import path[0] = . import path[1] = /snap/dmd/49/bin/../import/druntime import path[2] = /snap/dmd/49/bin/../import/phobos Failed: ["/snap/dmd/49/bin/dmd", "-v", "-o-", "./program.d", "-I."] Now, when I rename my scirpt file : program To: program.d and execute it by: ./program.d I no longer have an error. Is this an intended behaviour? In such questions it's important to show your shebang since that's what runs your script. Given your symptoms I guess you're using the following: #!/bin/env rdmd And indeed rdmd won't call your script if it doesn't have the proper extension. Try using this instead: #!/bin/dmd -run The shebang I used: #!/usr/bin/env rdmd I was visiting Dlang Tour and that's where I've got an example of shebang usage, directly from there: https://tour.dlang.org/tour/en/welcome/run-d-program-locally#/on-the-fly-compilation-with-rdmd The shebang you suggested actually works perfectly: #!/bin/dmd -run "And indeed rdmd won't call your script if it doesn't have the proper extension." Then why does Dlang Tour includes shebang: #!/usr/bin/env rdmd Instead of the one you mentioned, that is fool proof. (#!/bin/dmd -run) Is that an error/mistake in Dlang Tour guide? Frankly using rdmd is closer to being fool-proof, you just haven't hit the corner cases yet :) I'd either get used to having scripts with a .d extension or make an alias or a quick wrapper in shell and call it "program": #!/bin/sh exec rdmd /path/to/program.d "$@" It's not exactly a mistake, it's just not that important to most people I guess. And as your program grows you're likely to take the habit to compile it and work with the binary directly anyway.
Re: Executing a D script without an [extension in the filename] leads to an error
On Friday, 1 March 2019 at 14:50:45 UTC, Jesse Phillips wrote: On Friday, 1 March 2019 at 11:38:51 UTC, BoQsc wrote: "And indeed rdmd won't call your script if it doesn't have the proper extension." Then why does Dlang Tour includes shebang: #!/usr/bin/env rdmd Instead of the one you mentioned, that is fool proof. (#!/bin/dmd -run) Is that an error/mistake in Dlang Tour guide? You may want to change that too: #!/bin/dmd -i -run DMD doesn't automatically compile imported files (at least not until -i came along), rdmd existed to solve that problem... I don't know what value it brings with the -i switch existing. All systems I know only accept one argument in shebang so sadly it's not that simple :)
Re: Executing a D script without an [extension in the filename] leads to an error
On Friday, 1 March 2019 at 09:00:43 UTC, BoQsc wrote: I've installed D compiler, and when i try to run a D script with filename without an extension/file type named: program via: ./program I'm getting and error: vaidas@SATELLITE-L855:~/Desktop$ ./program Error: module `program` is in file './program.d' which cannot be read import path[0] = . import path[1] = /snap/dmd/49/bin/../import/druntime import path[2] = /snap/dmd/49/bin/../import/phobos Failed: ["/snap/dmd/49/bin/dmd", "-v", "-o-", "./program.d", "-I."] Now, when I rename my scirpt file : program To: program.d and execute it by: ./program.d I no longer have an error. Is this an intended behaviour? In such questions it's important to show your shebang since that's what runs your script. Given your symptoms I guess you're using the following: #!/bin/env rdmd And indeed rdmd won't call your script if it doesn't have the proper extension. Try using this instead: #!/bin/dmd -run
Re: hunt-markdown 1.0.0 released,
On Tuesday, 19 February 2019 at 10:36:38 UTC, zoujiaqing wrote:
hunt-markdown is powerfull markdown spec parsing and randering
library for Dlang. It's fast and clean. Api design like java's
commonmark library.
example code:
```import hunt.markdown.node.Node;
import hunt.markdown.parser.Parser;
import hunt.markdown.renderer.html.HtmlRenderer;
Parser parser = Parser.builder().build();
Node document = parser.parse("This is *New*");
HtmlRenderer renderer = HtmlRenderer.builder().build();
renderer.render(document); // "This is New\n"
```
More markdown spec like this:
https://spec.commonmark.org/0.28/
Github reposirory:
https://github.com/huntlabs/hunt-markdown
A cool addition would be a sanatizer to allow processing markdown
provided by users in a secure way. Right now trying to build
something like a forum supporting markdown would only end in lots
of XSS everywhere.
The end developer could probably create a sanatizer himself but:
* security works best when the wheel isn't invented over and over
again, such piece of software is hard to get right[1], better
have a centralized effort
* writting a sanitizer requires building a MD parser so it's
worth baking it into the library (but with a way to disable it
for trusted inputs).
Otherwise, it would be good to mention that this is not fit to
manage user inputs and should be kept server-side.
[1]:
http://danlec.com/blog/hacking-stackoverflow-com-s-html-sanitizer
Re: Process Information
On Saturday, 23 February 2019 at 20:49:49 UTC, r-const-dev wrote: Is there a way to get information about the current process? Memory usage, CPU usage, PID. The PID is easy, from std.process it's a standard function call away: https://dlang.org/phobos/std_process.html#.thisProcessID I don't think there is anything in phobos about memory or cpu usage. If you're on GNU/Linux you can probe /proc/self/stat and /proc/self/status to get that information, I don't know about windows.
Re: Should D file end with newline?
On Sunday, 10 February 2019 at 02:12:43 UTC, Jonathan M Davis wrote: On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via Digitalmars- d-learn wrote: ISO C++ specifies that the C++ file must end with a newline. Should D file end with newline, too? No, there is no need to end D files with a newline. I would guess that the vast majority of D files end with a closing brace. I just looked at a bunch of files in the standard library for the heck of it, and almost all of the ones I looked at ended with a closing brace. And those that didn't ended with something like an enum declaration and not a newline. Personally, I don't leave newlines at the end of files, because it looks messy. I don't even recall doing that in C++, though I do recall that there supposedly be a rule about it. It seems like a pretty bizarre requirement to me, but regardless, I'm quite sure that D does not have that requirement. - Jonathan M Davis If you used a text editor or IDE to write that final closing brace then I'm pretty confident it does add the newline character at the end. That won't result in an empty line on display. Try using an hex editor to check if you're curious.
Re: Prime number
On Thursday, 2 August 2018 at 14:37:56 UTC, Greatsam4sure wrote: On Thursday, 2 August 2018 at 09:35:20 UTC, Cym13 wrote: On Thursday, 2 August 2018 at 08:30:05 UTC, Greatsam4sure wrote: I know D is very powerful from my little experience. What is the idiomatic way to get prime numbers say from 1-30 without using loops(outer and inner loop). Can map, filter, fold etc in algorithm be use. Pls show some code with chain call. I can easily achieve even numberd and odd numbers using filter. But prime numbers I have to use 2loops. I will appreciate any help,just a newbie in D Denis' answer is good but I'd like to add that the idiomatic D solution is to use whatever tool is the most adequate to solve the issue. If two loops is more natural it wouldn't make much sense to force yourself to use range functions (even though I'd obviously understand that stand to learn to use them). Thanks, I like the idea of using helper function from algorithm module to do the magic instead of loops. I want to know How To optimize it to efficient. I will appreciate any help. Computing prime numbers efficiently would require something more complex like an Atkin sieve which I doubt will be very easy to implement without loop. That said, to start optimizing without changing the algorithm you can profile your code with -profile to see where you're spending time that you can shave off and rewrite the code to accelerate those parts. You should really start by changing the algorithm though. I will also appreciate a link to a comprehensive tutorial on the algorithm module. The documentation did not give me all the help I needed Not specifically on the algorithm module but I'd recommend reading [1] for a good intro to D from basics to advanced topics. For algorithms especially, I'd recommend reading on templates [2] and ranges [3]. Especially one thing you should know to understand the concepts behind most range-based functions is that most of them try to work on infinite sequences of things and therefore make assumptions only about the first items and never about the last ones. That's why functions like std.algorithm.find don't just return the element or its position but the sub-sequence starting at that element. There are exceptions though, and this comment may not make much sense at first so feel free to ignore it for the moment, but hopefully it'll come back to you when you need it. [1]: https://ddili.org/ders/d.en/index.html [2]: https://ddili.org/ders/d.en/templates.html [3]: https://ddili.org/ders/d.en/ranges.html
Re: Prime number
On Thursday, 2 August 2018 at 08:30:05 UTC, Greatsam4sure wrote: I know D is very powerful from my little experience. What is the idiomatic way to get prime numbers say from 1-30 without using loops(outer and inner loop). Can map, filter, fold etc in algorithm be use. Pls show some code with chain call. I can easily achieve even numberd and odd numbers using filter. But prime numbers I have to use 2loops. I will appreciate any help,just a newbie in D Denis' answer is good but I'd like to add that the idiomatic D solution is to use whatever tool is the most adequate to solve the issue. If two loops is more natural it wouldn't make much sense to force yourself to use range functions (even though I'd obviously understand that stand to learn to use them).
Re: std.getopt: Unexpected behavior when using incremental options
On Sunday, 29 July 2018 at 09:28:41 UTC, Ky-Anh Huynh wrote: Hi, I am using std.getopt and expect to parse an incremental option with different names: --long, --longer, -l. The sample code is here [...] I think -long is actually taken as -l -o -n -g here. Since you didn't define -o, -n and -g it prints a usage error.
Re: On D in competitive programming
On Sunday, 29 July 2018 at 07:51:00 UTC, Jim Balter wrote: On Saturday, 28 July 2018 at 21:33:04 UTC, Ivan Kazmenko wrote: [snip] 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Yeah, good point, mentioned it now. Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. [snip] While it's certainly not exact I think it's fine, there's no need to rewrite the language specification. Even for the parentheses, once you know they may be dropped in unambiguous cases you are bound to assume that the author didn't start talking of the ! sign for no reason and that you ought to consider that parentheses may be dropped even not knowing all the reasons. The same goes for UFCS, it's made very clear by the article that the functions are chained. Whether they are actually functions, or function templates or methods or something else entirely isn't important. I think the reader can be expected to understand how it works without understanding why. They even know what the program does already so the chaining part isn't hard. Maybe I was wrong that it needed any addition after all. Or maybe the explaination of templates should be more streamlined toward what is in the code like “map here is a template, the ! sign is the equivalent of <> in C++" and no more.
Re: On D in competitive programming
On Saturday, 28 July 2018 at 19:51:08 UTC, Ivan Kazmenko wrote: Hey, I wrote a post with my general reflections on using D in competitive programming. Mostly compared to C++, since that's what more than 90% of people use for it. The post is tailored to cover only the competitive programming specifics. http://codeforces.com/blog/entry/60890 (en+ru, the language switch is at the top) Ivan Kazmenko. Thanks, great read :) I have some minor notes though: 1. Your real name isn't written in the article so the link "with some successes" won't tell much to someone that doesn't already know you 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Also I have a question: I find very nice that some platforms propose D even though not all do, but are they generally keeping it up to date with DMD or stuck at something ancient?
Re: Struct Initialization syntax
On Tuesday, 24 July 2018 at 10:48:40 UTC, Dukc wrote: On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote: What's your take on this? Option 2 won't necessarily cause problems with named funcion arguments: The names of the constructor arguments and members are different anyway, at least usually, letting the compiler to infer the intended call by them. But there might be some corner cases where this would not apply. Do you see any? That argument sounds quite dangerous to me, especially since my experience is on the contrary that constructor arguments are often named the same as the attribute they refer to. And what of mixed cases? I really wouldn't rely on anything like naming conventions for something like that.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 17:10:08 UTC, Cym13 wrote:
PS: Now that I think about it, would something like S{c:3}("a")
be allowed to say “Call the constructor with the string "a" as
argument on the struct of type S initialized with c=3”? I may
have missed it but I don't think that's addressed by the DIP.
I took that last point to GH, no need to discuss it here.
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
I personally prefer option 2, but this might be in conflict to
named arguments which we hopefully see in the near future too.
Hence, I'm leaning forward to proposing Option 1 as the
recommended Option for the DIP (that's also what the PoC DMD PR
implements). What's your take on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
I'm in favour of 3.
Option 2 looks nice but I'm against it because of possible named
arguments. Even though they're not part of the language yet and
may never be we already have too many clunky things not to avoid
a conflict when we can.
Option 1 is clean but a bit strange, I don't like the idea of
doubling the enclosing symbols, in that situation you'd expect
S() and {} to have separate effects, not to combine into a
special effect. It also looks like a constructor while it's not,
which isn't a nice conflation to make. I wouldn't be very
dismayed by it though.
Still, that's why I prefer option 3 which is very similar to
classical struct initialization and has clearly only one effect.
PS: Now that I think about it, would something like S{c:3}("a")
be allowed to say “Call the constructor with the string "a" as
argument on the struct of type S initialized with c=3”? I may
have missed it but I don't think that's addressed by the DIP.
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote: That would work, it's just a really horrible hack and I hate it. Bastiaan's solution to simply change the default value slipped my mind but is really cleaner and in the same line of thought. We're constructing a fictitious domain value that passes our invariants while having zero correspondence to the real world, *just to pass our invariants*. It's an obvious sign of a language issue. I'm not sure I understand, that's what T.init is: a fictitious domain value that just happens to be the default value. It doesn't have to have any meaning and shouldn't be used that way. It's just a value until it has a value. If it happens to be conveniently a useful value, all right, but that's not its first goal IIUC. To present things the other way: you are defining constraints on a type while also defining the default value of that type as not meeting these contraints. No matter how you look at it the default value of a type should be a valid value. How is that not an issue with your own code? Just change the default so that it is within the constraints. Furthermore, while changing the default field value directly is less of a hack the solution to redefine init() entirely actually allows you to do things like making sure the struct is registered in a table somewhere. So I think you do have the option to meet your invariants.
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594 problem with T.init
and toString
https://github.com/dlang/phobos/pull/6619 Nullable can't work
with types where T.init violates invariants
https://github.com/dlang/dmd/pull/8462 A somewhat sketchy PR to
disable invariant on struct ~this
First of all I must point that I would very much like to have
seen a code actually producing an error in that article. Contrary
to what is hinted just taking the struct and putting using it
with Nullable or format() caused no error for me and worked as
expected. Taking .init explicitely was the only thing that
actually caused an error. I'm not saying you didn't experience
these issues, but if you want to demonstrate a problem then
please demonstrate it.
That said, I may be missing something obvious but what prevents
you from overloading the init field?
struct MyDomainData {
string username;
@disable this(); // don't make a MyDomainData() by
accident!
this(string username)
in(!username.empty) // only non-empty usernames please!
do { this.username = username; }
// let's formalise the restriction.
invariant { assert(!username.empty); }
string toString() { ... }
static @property MyDomainData init() {
return MyDomainData("uninitialized");
}
...
}
auto test = MyDomainData.init; // There, no error
Of course that value means nothing but .init isn't meant to
actually mean something anyway, it's just a valid value and
that's what that init is proposing, so it shouldn't cause any
more bugs than empty .init in a normal case.
Re: Dynamic arrays / ~= giving an exception...
On Sunday, 1 July 2018 at 20:55:16 UTC, Robert M. Münch wrote:
I'm a bit puzzled because I think this is pretty straight
forward but doesn't work...
struct mystruct {
myPtr* root;
opApply(...){
myPtr*[] childs;
childs ~= root;
...
}
}
foreach(node; mystruct(myRoot)){
...
}
It compiles but the line with ~= gives the nice "bing" under
Windows and the application hangs...
What doesn't this work?
Could you maybe provide a compilable example?
Re: Zip vs Enumerate
On Wednesday, 20 June 2018 at 04:40:42 UTC, Cym13 wrote: On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote: [...] This sounds like a very limited case: if you're not zipping against a iota(foo) then there's no comparing with enumerate, they simply don't do the same thing at all, and if you are then it sounds like enumerate expresses the purpose of using an index way better than a zipped iota IMHO. Is there anything about your true use case that would be worth mentionning to better understand your situation? My bad, I didn't read your example thoroughly enough.
Re: Zip vs Enumerate
On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote:
Hello,
Idiomatically, I make use of zip, however, when looking to
speed up my program, notice that using enumerate leads to a
20-30% improvement:
void main(){
auto x = iota(1_000).array;
auto y = iota(1_000).array;
auto func1() {
return zip(x,y).map!(a => a[0]+a[1])
.array;
}
auto func2() {
return x.enumerate
.map!(a => a.value + y[a.index])
.array;
}
assert(func1.equal(func2));
import std.datetime.stopwatch;
auto r = benchmark!(func1, func2)(10_000);
// r[0] approx 1794 ms
// r[1] approx 1295 ms
}
Is there anything I can do to improve zip, before I go ahead
and change to the faster but slightly less readable enumerate?
In my particular case, all ranges that I zip are of the same
length, but not sure how I can leverage that information.
Thanks,
Jordan
This sounds like a very limited case: if you're not zipping
against a iota(foo) then there's no comparing with enumerate,
they simply don't do the same thing at all, and if you are then
it sounds like enumerate expresses the purpose of using an index
way better than a zipped iota IMHO.
Is there anything about your true use case that would be worth
mentionning to better understand your situation?
Re: Create a List or Dictionary.
On Tuesday, 19 June 2018 at 05:52:00 UTC, Sunny wrote: On Monday, 18 June 2018 at 13:23:37 UTC, Cym13 wrote: Yes, this is what need, thank you very much for your help. :-) [...] I recommend that you take the D tour if you can, it explains all those fundamental features quite well I think. https://tour.dlang.org/
Re: Create a List or Dictionary.
On Monday, 18 June 2018 at 11:44:43 UTC, Sunny wrote:
Hello, I'm having a problem, how can I create a List or
Dictionary in D?
In C #, I can create a tuple list, example:
var musicList = new List <(string URL, string Artist, string
Title, string Cover, string Duration)> ();
In Google did not find anything, tell me please how to get out
of this situation?
If I read you well it seems the simplest equivalent code would be:
struct MusicItem {
string URL;
string Artist;
string Title;
string Cover;
string Duration;
}
MusicItem[] musicList;
You could technically use tuples to get to the same point but I
don't really
see a point, structs fit that purpose very well.
Then you can:
musicList ~= MusicItem(url, artist, title, cover, duration);
musicList = [musicItem1, musicItem2];
or for dictionnaries:
MusicItem[string] musicDictionnary = [
"shortID1": MusicItem(foo, bar, baz, bak, biz, sub),
"shortID2": MusicItem(foo, bar, baz, bak, biz, sub),
];
etc.
Re: D code obfuscator
On Thursday, 14 June 2018 at 10:39:19 UTC, DigitalDesigns wrote: Wait? Are you sure you are not kidding? Do you want another shot? I won't say that obfuscation is entirely useless, if I have to choose I'll of course take the version with symbols for reverse engineering and there are specific cases where symbols carry way to much information for you to want it disclosed (most common being names of customers or projects etc). But, as someone whose job is to find security issues with softwares (and other stuff) be it with or without source, I can say with professionnal certainty that things like changing all identifiers to single-letter ids don't slow me the slightest in my assignments. That's just the state of things, reversers deal with stripped stuff all the time, identifiers are just nice to have. So instead, here's what would slow a reverse engineer: - Remove strings. Make sure to remove as many as you can, especially debug statements. Hide the rest by encrypting in memory. Even if it is possible to decrypt it or read it at runtime it'll be way harder to correlate things together. - Pack. Have your software decipher itself in memory at runtime, not all at once but only sections at once dynamically. Use random keys automatically generated at compile-time for that, that'll mess up binary diffs. - Include binary tricks to mess up with disassemblers. There are many constructs that common disassemblers interpret badly. - Mess with the structure. If you can remove all conditions and loops. A reverser can often just look at a function's logical graph and know what kind of work it is doing. The movfuscator is a good example. - Add runtime checks based on time deltas between two points of the code in different functions. Generate other output based on that. - Be sure to encrypt all communications of course. In short, do what good malwares do.
Re: Encouraging preliminary results implementing memcpy in D
On Thursday, 14 June 2018 at 02:32:51 UTC, errExit wrote:
Tor is our last line of defence against an Orson Wells future,
where everyones actions are scrutinized by big brother, so that
big brother can use that knowledge to put fear into, control
and manipulate, those that don't conform.
assert("bad tor user" != "all tor users are bad");
(actually there are more bad non-tor users)
Unfortunately, it's becoming increasingly, the norm, to
discriminate against tor users (no doubt those doing that
discrimination are those that are happy to conform, of which
there will be many, sadly).
https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf
Don't mistake spammer management with discrimination. I share
your frustration that TOR isn't more usable than it is today with
CloudFlare etc, but coming with political reasons holds no water
if the reason why it was blacklisted wasn't political in the
first place. It's not false, it just won't work.
Hopefully once that particular user gets discouraged or we find a
way to actually avoid user impersonification, then things will be
able to come back to normal.
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 16:21:53 UTC, Steven Schveighoffer wrote: I won't add much, since I'm using a Mac, and those numbers have already been posted. Reproduction is an important part of the scientific process, please post away ;) Also: memcpyD commit f5fb0fda0dbacc960ced59d7171ff76a95cc2abf on Archlinux native x86_64 4.16.13-2 with Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz and 7681MB of RAM, with dmd and ldc, no flag and optimized. DMD: size memcpyC memcpyD 1 50392 30745 2 50189 33515 4 47493 33456 8 50282 33428 16 36385 36061 32 36212 32142 64 50141 31137 128 52947 52785 256 86422 76346 512 131191 128344 1024 227875 291414 2048 444865 449210 4096 826391 823613 8192 1542429 1545051 16384 3264964 3228990 32768 11644816 11902418 65536 23658237 24026304 size memcpyC memcpyD 1 43209 37462 1 42412 38043 1 42079 38002 2 56503 39923 2 50544 38033 4 47760 37239 4 48910 36976 8 51110 38065 8 53761 36297 4 48201 35548 8 54820 38036 16 39360 35409 DMD -O: core.exception.AssertError@memcpyd.d(9): Assertion failure ??:? _d_assertp [0xc4e79cc5] ??:? pure nothrow @nogc void memcpyd.verify!(real).verify(const(real), const(real)) [0xc4e77c2c] ??:? void memcpyd.test!(real).test() [0xc4e76d60] ??:? _Dmain [0xc4e63ecd] 1 42014 26518 2 46086 26486 4 45984 29272 8 48813 26484 16 34866 18126 32 32036 18107 64 46073 20892 128 45964 27993 256 82344 50250 512 133484 94766 1024 216402 270462 2048 436465 443122 4096 815875 801596 8192 1524872 1530453 16384 3721245 3584620 32768 11776185 11739396 65536 23702074 23589480 size memcpyC memcpyD 1 37755 15424 1 40486 15319 1 40505 15352 2 47097 15653 2 46160 15319 4 43180 18110 4 46041 15321 8 46014 15342 8 46066 15341 4 43277 18105 8 45962 15321 LDC: size memcpyC memcpyD 1 56378 48873 2 59461 49025 4 50481 45299 8 53786 49517 16 46103 39122 32 48100 46139 64 83864 67401 128 83849 90426 256 122471 138309 512 169668 228472 1024 260461 276878 2048 444937 472365 4096 860962 825468 8192 1578929 1567154 16384 3429235 3284611 32768 11941494 11868947 65536 24052536 24112980 size memcpyC memcpyD 1 47853 33403 1 47623 32924 1 48190 33100 2 59752 33146 2 59574 34371 4 53928 35042 4 54131 31991 8 57929 35864 8 57372 32174 4 54901 33253 8 62537 34535 16 52487 38358 LDC -O2: core.exception.AssertError@memcpyd.d(9): Assertion failure ??:? _d_assert [0x7fba47d79b35] ??:? void memcpyd.test!(real).test() [0x5638cb483d6e] ??:? _Dmain [0x5638cb47ea30] size memcpyC memcpyD 1 0 0 2 0 0 4 0 0 8 0 0 16 385 0 32 792 0 64 1542 0 128 2981 0 256 90108 0 512 126316 0 1024 217881 391419 2048 415182 620853 4096 1244805 1240074 8192 2428417 2414095 16384 4863280 4971193 32768 12968909 12966676 65536 26393408 26395410 size memcpyC memcpyD 1 0 0 1 0 0 1 0 0 2 0 0 2 0 0 4 0 0 4 0 0 8 0 0 8 0 0 4 0 0 8 0 0
Re: newCTFE: perliminary delegate support is in!
On Wednesday, 13 June 2018 at 05:57:31 UTC, Stefan Koch wrote:
Good day ladies and gentleman,
it is my distinct please to announce that a new feature just
landed in newCTFE.
!!! DELEGATES !!!
this means the following code will now work:
int square_of_x_plus_x(int x) pure
{
int passThrough(int y) pure
{
assert(x == y);
int y2 = x;
assert(y2 == y);
int fnC() pure
{
auto z = (x * y);
assert(y2 == x);
assert(x == y);
return z;
}
return fnC();
}
return x + passThrough(x);
}
pragma(msg, square_of_x_plus_x(7));
static assert(square_of_x_plus_x(5) == (5*5)+5);
the reason why this was quite tricky to implement is that
in the newCTFE architecture there is no concept of a function
touching
the stack-frame of another function _at all_.
(Infact there is no conventional stack, rather the virtual
registers themselves stack)
Sharing of the stack frames gets emulated via a hidden
parameter and a linked-list structure.
Cheers,
Stefan
That's very nice! Out of curiosity, what was the reason to avoid
a conventional stack? Or was it a consequence more than a design
decision? (If you've explained it before, feel free to just throw
the old post at me)
Re: -J all
On Sunday, 10 June 2018 at 19:10:52 UTC, DigitalDesigns wrote: On Sunday, 10 June 2018 at 14:42:21 UTC, Basile B. wrote: On Sunday, 10 June 2018 at 01:49:37 UTC, DigitalDesigns wrote: Please allow -J to specify that all subdirectories are to be included! I'm having to include all subdirectories of my library with J because I import each file and extract information. It would be better to have something like -JC:\Lib\* rather than -JC:\Lib\Internal -JC:\Lib\Internal\OS -JC:\Lib\API -JC:\Lib\API\V1 -JC:\Lib\API\V1\Templates ... .. . This is opened as an enhancement request now: https://issues.dlang.org/show_bug.cgi?id=18967. IIRC there was a security concern mentioned last time this was proposed, not 100% sure. Yeah, but -J was added for a security concern! So when does the insanity end? There's no contradiction nor insanity, you're saying the same thing he did: -J was added for a security concern. If it's such a big, e.g., to prevent root access then limit asterisk usage to non root and maybe only a depth of 3. After all, if someone wanted access to sensitive areas just do -JC:\Windows\System32. At some point one has to stop policing everything. I'm not entirely sure what the threat model is, but it seems to me that we're not trying to protect against an user exposing sensitive areas. We're trying to protect against code that isn't trusted at compile time. I think the idea is to avoid allowing someone to import your config file with all passwords at compile-time so that it can use it or send it later at runtime to the attacker. It's not a bad risk to consider but I wonder if that's the best solution we can find.
Re: Security point of contact
On Sunday, 10 June 2018 at 00:31:55 UTC, Vladimir Panteleev wrote: On Saturday, 9 June 2018 at 19:03:59 UTC, Cym13 wrote: Who should I contact? I'd very very much like to have something like a secur...@dlang.org for such things, it's not the first and likely not the last time this need arises, and the lack of a clear procedure doesn't encourage coordinated disclosure. Less specifically, it depends on the component / property. There is the https://wiki.dlang.org/People page, which has a list of points of contact. This is the thing exactly, first of all the idea that the main developer of the part of the project impacted should be the one receiving the report is sound but far from obvious. In many countries there is a (stupid) legal risk associated with vulnerability disclosure, so as a researcher you'd rather be sure that you're talking to the right person. Furthermore the list doesn't provide any direct way to contact any of those people, which isn't surprising but adds friction. In the best case the email is visible on their github account, in the worst you need to look at commits and hope the email is still valid and the one the person expects to be contact with. The alternatives are 1) opening a public issue on issues.dlang.org, which I did many times where I judged that it was acceptable given the issue but I'm never at ease doing it, or 2) asking as I just did. I can say with certainty that the current process is a deterrent. In the past I decided not to discuss some issues because of it (hopefully not to important otherwise I'd have pressed the matter and remember what it was about, but judging importance isn't easy). Security is the thing nobody wants to have to think about, but it's important nonetheless, so I think it's worth improving the process on that point. After all, all issues found and disclosed by external people are issues you don't have to find yourself ;)
Re: Security point of contact
On Saturday, 9 June 2018 at 23:19:34 UTC, Cym13 wrote: Thank you, the mail should be in your box already. Well, apparently gmail considered it spam, so it shouldn't be in your box. But I'm sure Sönke or Martin will be able to transfer it.
Re: Security point of contact
On Saturday, 9 June 2018 at 21:52:59 UTC, Seb wrote: On Saturday, 9 June 2018 at 19:03:59 UTC, Cym13 wrote: Yop. I need to discuss an issue related to dub. No need to alarm everyone yet, that only concerns 1.3% of dub projects, but still it's something that shouldn't be taken lightly. Who should I contact? Sönke, Martin und myself. https://github.com/s-ludwig (look in the DUB git log for his email address) https://github.com/MartinNowak https://github.com/wilzbach Thank you, the mail should be in your box already. I'd very very much like to have something like a secur...@dlang.org for such things, it's not the first and likely not the last time this need arises, and the lack of a clear procedure doesn't encourage coordinated disclosure. I will try to get this email address setup. At least we already have an official GPG keyring: https://dlang.org/gpg_keys.html Having the address will be a very good start, thank you. For comparison the PHP project has two things that I enjoyed when disclosing bugs: 1. Security guidelines (https://wiki.php.net/security) that clearly state what they consider a vulnerability and what isn't. I find it very well designed and it could be an inspiration for a D security guideline even though we're not having too many vulnerabilities disclosed right now as far as I know. 2. They configured their bugzilla so that when the category "security" is used the bug is made private and only the proper team is put in copy. I don't know how easy it is so an email address seems more practical right now I think. Note that this is in complement to secur...@php.net which they use mostly for security related talk but not bug reports. Anyway, I'm not sure we need all this right now, but I'd rather start the discussion early.
Security point of contact
Yop. I need to discuss an issue related to dub. No need to alarm everyone yet, that only concerns 1.3% of dub projects, but still it's something that shouldn't be taken lightly. Who should I contact? I'd very very much like to have something like a secur...@dlang.org for such things, it's not the first and likely not the last time this need arises, and the lack of a clear procedure doesn't encourage coordinated disclosure.
Re: WTF! new in class is static?!?!
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I'd expect it to be translated to something like
class B
{
A a;
this()
{
a = new A();
}
}
In C# it is different, can't remember if it is different in
C++. This has caused bugs in my code because the fields are all
pointing to the same data when I expected them to each have
unique data ;/
This method is error prone and the behavior should be reversed,
it should not break the majority of code. If one wants the
current behavior then static new could be used or something
else.
The spec looks pretty clear to me on that point
https://dlang.org/spec/class.html#field-init
Besides, defining behaviour at construction is what constructors
are for, I wouldn't expect anything outside a constructor to
happen when an object is constructed. So while I understand that
other languages may (successfully for them) do things differently
I don't think I'd like a breaking change for that.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 03:57:37 UTC, Suliman wrote: Git was never my favorite VCS. So I hope that this step will open door for project like pijul.org github.com is only site, not religious. So if it will be closed people will move/create to its analogs. Git has nothing to do with github, it's just a technology they happen to use but they have no privilege on it. It won't change a thing on that side.
Re: extend foreach to work on non-arrays
On Friday, 25 May 2018 at 04:31:54 UTC, Neia Neutuladh wrote: I've first-hand experience with moderation on this forum: nothing public, at most a private email from Walter or Andrei. This does a terrible job of setting expectations of community behavior. It makes it look like there is no moderation at all. I have no idea whether the moderation I experienced was unique or standard -- do most people not even get a warning? If someone is rude to me, are they tolerated while I am rebuked? I hope that policy changes. Please note that Mike Parker stepped in for you too. I don't think there's much merit in stirring mud any further.
Re: errno is not nothrow
On Friday, 11 May 2018 at 07:05:12 UTC, Shachar Shemesh wrote: At least under Linux, you cannot get or set the value of errno from a nothrow function. Is this on purpose, or is this a bug? Shachar It seems I can't reproduce with core.stdc.errno, could you please share some code?
Re: unit-threaded v0.7.45 - now with more fluency
On Wednesday, 9 May 2018 at 04:40:37 UTC, Nick Sabalausky (Abscissa) wrote: On 05/08/2018 05:05 AM, Cym13 wrote: [...] No, it really doesn't mean the same thing at all. Not when you look away from the unimportant implementation details and towards the big picture: [...] With UFCS I find that in my code a dot means "function composition" more often than "is a member of". Maybe it's just that I like writting in a functional style, but UFCS chains are very much endorsed by the language, so I wouldn't call it a stretch.
Re: unit-threaded v0.7.45 - now with more fluency
On Tuesday, 8 May 2018 at 07:07:30 UTC, Nick Sabalausky (Abscissa) wrote: On 05/07/2018 11:57 PM, Johannes Loher wrote: On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote: I think I'm siding with Johannes here. Much as the overloads look nice, I don't really see the advantage over `shouldEqual`. Also, what's with `all.these.identifiers`? Any particular reason why you are more fond of them rather than of good ol' pascalCase? Fluent assertions have one major advantage over using pascalCase assertions: There is no ambiuguity about the order of arguments. When using e.g. assertEquals, how do you know wheter is is supposed to be assertEquals(actual, expected), or assertEquals(expected, actual)? The first one is the only one that makes sense wirh UFCS, but it is not clear directly from the API. On top of that, some popular Frameworks (I‘m looking at you, JUnit...) do it exactly the other way round. With fluent assertions, you don‘t have this Problem, it is much more clear that it should be actual.should.equal(expected) and not expected.should.equal(actual), because it fits naturally in the chain of ufcs calls. I don't think that's the issue. At least, it isn't for me. It's not a question of "assert equals" vs "should equal" (Though I am convinced by your argument on that matter). The question is: Why "should.equal" instead of "shouldEqual"? The dot only seems there to be cute. Not that I'm necessarily opposed to any of it (heck, I like cuteness in any sense of the word), it's just that: If the "~" thing is operator abuse, then I don't see how "should.equal", "should.not.be" etc, wouldn't fall into the same category. I wouldn't say it's an abuse, the dot means exactly the same thing as everywhere else in the language. I'm way less fan of overidding ~ since that doesn't have that meaning in any other context. Without having actually used it, I like the composability over pascalCasing here, it looks like it fits nicely in a functional environment with things like aliases and partials I think, defining your own primitives naturally... Nothing one can't do with regular functions and pascalCased assertions, but it sounds like it would be way more verbose. It also sounds like it's easier on the implementation side since you never have to define both a "shouldSomething" and "shouldNotSomething", and that means as a user I can expect less bugs and better maintainance of the library. That said, it'll have to be field-tested to be sure.
Re: Static Analysis / Code Scanning Tool (SAST) for D?
On Saturday, 28 April 2018 at 16:01:44 UTC, Stefan Koch wrote: On Saturday, 28 April 2018 at 15:30:01 UTC, Jonathan M. Wilbur wrote: Does anybody know of a SAST tool that can scan D code for security vulnerabilities? In other words, does anybody know of something that will analyze raw D source code for security vulnerabilities that the human eye may have missed? No. Besides analyzing D code is normally quite useless, as the tool will be blind once it hits the first template. Security vulnerabilities, are usually nothing which can be caught by static analysis on source code. As they are highly dependent on which shape the generate machine code takes. Meh. That's far from true. My experience as a professional with experience in both pentesting, static analysis and reverse engineering is that finding vulnerabilities on compiled code is generally way *way* less efficient, be it only because all vulnerabilities aren't at the same level. It is by far the least efficient of the three when considering the ratio number*criticality/analysis_time. High-level things like missing authentication to access a given resource are much easier to spot by static analysis. Same for crypto mistakes, and about everything really. Some vulnerabilities are easier to find dynamically (a recent use-after-free in a multithreaded context comes to mind), but saying that static analysis can't find useful things is completely false. Besides, as "cool" as memory corruptions and other integer overflow issues may be they're far from being the only important vulnerabilities present in an application. I'll take a /tmp/log.txt over a buffer overflow any day. That said, no, I don't know of any software on the market working with D code, and yeah, templates do make the task harder for an automated tool. Not that I'd trust one over the eye of a professional anyway. They're helpful but not as efficient.
Re: dynamically allocating on the stack
On Sunday, 22 April 2018 at 05:29:30 UTC, Mike Franklin wrote:
On Sunday, 22 April 2018 at 00:41:34 UTC, Nicholas Wilson wrote:
You're not using the C library version of it, the compiler
does the stack space reservation inline for you. There is no
way around this.
I'm not convinced. I did some no-runtime testing and
eventually found the implementation in druntime here:
https://github.com/dlang/druntime/blob/master/src/rt/alloca.d
Mike
The first assertion ("the C library isn't called") is easily
apperent from
that assembly dump. The second is interesting but not so evident.
It might be clearer looking at actual assembly.
The doSomething function starts as such:
; sym._D4test11doSomethingFmZv (int arg_1h);
; prologue, puts the old stack pointer on the stack
0x563d809095ec 55 push rbp
0x563d809095ed 488bec mov rbp, rsp
; allocate stack memory
0x563d809095f0 4883ec20 sub rsp, 0x20
; setup arguments for the alloca call
; that 0x20 in rcx is actually the size of the current stack
allocation
0x563d809095f4 48c745e82000. mov qword [local_18h],
0x20 ; 32
0x563d809095fc 48ffc7 inc rdi
0x563d809095ff 48897de0 mov qword [local_20h],
rdi
0x563d80909603 488d4de8 lea rcx, [local_18h]
; calls alloca
0x563d80909607 e83001 call sym.__alloca
The alloca function works as such:
;-- __alloca:
; Note how we don't create a stack frame by "push rbp;mov
rbp,rsp"
; Those instructions could be inlined, it's not a function
per se
;
; At that point rcx holds the size of the calling functions's
stack frame
; and eax how much we want to add
0x563d8090973c 4889ca mov rdx, rcx
0x563d8090973f 4889f8 mov rax, rdi
; Round rax up to 16 bytes
0x563d80909742 4883c00f add rax, 0xf
0x563d80909746 24f0 and al, 0xf0
0x563d80909748 4885c0 test rax, rax
,=< 0x563d8090974b 7505 jne 0x563d80909752
| 0x563d8090974d b81000 mov eax, 0x10
`-> 0x563d80909752 4889c6 mov rsi, rax
; Do the substraction in rax which holds the new address
0x563d80909755 48f7d8 neg rax
0x563d80909758 4801e0 add rax, rsp
; Check for overflows
,=< 0x563d8090975b 7321 jae 0x563d8090977e
| ; Replace the old stack pointer by the new one
| 0x563d8090975d 4889e9 mov rcx, rbp
| 0x563d80909760 4829e1 sub rcx, rsp
| 0x563d80909763 482b0a sub rcx, qword [rdx]
| 0x563d80909766 480132 add qword [rdx], rsi
| 0x563d80909769 4889c4 mov rsp, rax
| 0x563d8090976c 4801c8 add rax, rcx
| 0x563d8090976f 4889e7 mov rdi, rsp
| 0x563d80909772 4801e6 add rsi, rsp
| 0x563d80909775 48c1e903 shr rcx, 3
| 0x563d80909779 f348a5 rep movsq qword [rdi],
qword ptr [rsi]
,==< 0x563d8090977c eb02 jmp 0x563d80909780
|`-> 0x563d8090977e 31c0 xor eax, eax
| ; Done!
`--> 0x563d80909780 c3 ret
So as you can see alloca isn't really a function in that it
doesn't create a
stack frame. It also needs help from the compiler to setup its
arguments
since the current allocation size is needed (rcx in the
beginning of alloca)
which isn't a parameter known by the programmer. The compiler has
to detect
that __alloca call and setup an additionnal argument by itself.
Alloca then
just ("just") modifies the calling frame.
(I really hope I didn't mess something up)
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 13:30:55 UTC, Cym13 wrote: [...] Nevermind, forgot that shared libraries are put between the two.
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 13:54:14 UTC, H. S. Teoh wrote: On Sat, Apr 21, 2018 at 01:30:55PM +, Cym13 via Digitalmars-d-learn wrote: On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote: [...] > Unbounded allocation on stack is kind of anti-pattern and a > potential DoS vector. I'm having trouble seeing how unbounded heap allocations aren't equally a potential DoS vector. [...] Generally speaking, the heap is much bigger than the stack (often many times so) and so is less prone to overflow. Though it's true, it still does happen if you just blindly allocate memory based on unsanitized external input. T Wait, why? Don't they share the same address space and grow in opposite directions?
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky
wrote:
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack?
I'm looking for something roughly equivalent to the following
C code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
Unbounded allocation on stack is kind of anti-pattern and a
potential DoS vector.
I'm having trouble seeing how unbounded heap allocations aren't
equally a potential DoS vector.
A separate region allocator is exactly as fast and can easily
survive across boundaries of function calls.
I guess if OP wants it on the stack it's because it doesn't need
to survive across boundaries of function calls so this buys
nothing in this case.
Also you probably want something like char[X] = void;
for efficiency if allocating on stack.
Thanks,
Mike
Re: Feature to get or add value to an associative array.
On Monday, 16 April 2018 at 18:59:54 UTC, Giles Bathgate wrote: On Monday, 16 April 2018 at 12:41:07 UTC, JN wrote: It's only one additional "in", but makes the code more explicit and clear. I think in most cases, you will want to check if you are dealing with a fetched object or a default created one, so that will complicate the function even further. You can still use a combination of `in` and the update syntax if you want, this doesn't take that away. In the future, for a concurrent implementation of associative arrays, a way of getting or adding an element as an atomic operation becomes more important. Either way the beauty of hashed based lookups is that they average O(1), seems a shame to double that up for no reason ;) "in" returns a pointer to the object, there'es not double lookup necessary: // if we don't know .get(key, default) exists auto ptr = key in aa; auto value = ptr ? *ptr : default; // to set default value on the fly auto value = ptr ? *ptr : *ptr = default; is a new flag/method really that necessary? In my experience if you have trouble naming it you haven't found its true purpose yet.
Re: Passing directory as compiler argument not finding file
On Friday, 13 April 2018 at 13:39:23 UTC, Tony wrote: On Friday, 13 April 2018 at 12:46:32 UTC, Cym13 wrote: On Friday, 13 April 2018 at 01:27:06 UTC, Tony wrote: I think that the typical model (at least in other languages) is to only compile one D source file at a time. Compile the b.d file with the -c option to create an object file. Then put the object file in a library file (either static (easier) or dynamic). Then you can use the -L compiler option to specify the directory of the library and the -l compiler option to specify the library (library name is shortened - libb.a referenced as -lb). Regardless of whether that would work or not this is the opposite of what's recommended in D. D compilers expect you to compile everything at once, or at least by module. That's where it works best when it comes to optimizations etc. What does "or at least by module" mean? Is it possible to have a module that is made up of more than one source file? Sorry, I really meant "package" here, not module. What information does a D compiler get when you stick a.d and b.d on the command line that it doesn't get if you compile a.d and import b.d ? Hmm. I can't quite remember honnestly. What I do remember is Andrei saying times and times again that D supports compilation by package and not incremental compilation (which is difficult because of CTFE and templates), but on second thought maybe you won't run into issues if compiling each module separately as long as you compile them all. However I'm pretty sure you'll get worse compilation times as the compiler can't make use of symbol cache etc. That may be the main reason why people generally avoid compiling separately each module and just put every file on the command line. AFAIK dmd is designed to be used that way.
Re: Passing directory as compiler argument not finding file
On Friday, 13 April 2018 at 01:27:06 UTC, Tony wrote: I think that the typical model (at least in other languages) is to only compile one D source file at a time. Compile the b.d file with the -c option to create an object file. Then put the object file in a library file (either static (easier) or dynamic). Then you can use the -L compiler option to specify the directory of the library and the -l compiler option to specify the library (library name is shortened - libb.a referenced as -lb). Regardless of whether that would work or not this is the opposite of what's recommended in D. D compilers expect you to compile everything at once, or at least by module. That's where it works best when it comes to optimizations etc.
Re: What Is Python Developer Salary?
On Friday, 13 April 2018 at 10:00:00 UTC, bauss wrote: On Thursday, 12 April 2018 at 21:01:47 UTC, Arnold Blake wrote: I hired a remote developer in the language of the programming python, there was such a question as to how much should I pay him for the work? how many per hour? What kind of salary do they have, are different countries interested, Eastern Europe, India, etc? Depends on their qualifications and what type of work they're going to do. Also who hires someone before they agree on a salary? The real question IMHO is who accepts to be hired before agreeing on a salary ^^
Re: Range length property
On Tuesday, 10 April 2018 at 20:08:14 UTC, Jonathan M Davis wrote: On Tuesday, April 10, 2018 19:47:10 Nordlöw via Digitalmars-d-learn wrote: On Tuesday, 10 April 2018 at 14:34:40 UTC, Adam D. Ruppe wrote: > On Tuesday, 10 April 2018 at 14:25:52 UTC, Nordlöw wrote: >> Should ranges always provide a length property? > > No. > >> If so, in which cases is a length property an advantage or >> a requirement? > > Just provide it whenever it is cheap to do so. If you need > to do complex calculations or especially loop over contents > to figure out the length, do NOT provide it. > > But if it is as simple as returning some value, provide it > and algorithms can take advantage of it for optimizations > etc. as needed. I'm thinking of my own container Hashmap having its range ByKeyValue requiring one extra word of memory to store the iteration count which, in turn, can be used to calculate the length of the remaining range. Is this motivated? That would depend entirely on what you're trying to do, but in general, if a range has length, then some algorithms will be more efficient, and some algorithms do require length. So, if you can provide length, then the range will be more useful, just like a bidirectional range can be more useful than a forward range or a random-access range can be more useful than either. However, if you're not doing anything that ever benefits from it having length, then it doesn't buy you anything. So, it ultimately depends on what you're doing. In a general purpose library, I'd say that it should have length if it can do so in O(1), but if it's just for you, then it may or may not be worth it. The other thing to consider is what happens when the container is mutated. I don't think that ranges necessarily behave all that well when an underlying container is mutated, but it is something that has to be considered when dealing with a range over a container. Even if mutating the underlying container doesn't necessarily invalidate a range, maintaining the length in the manner that you're suggesting probably makes it so that it would be invalidated in more cases, since if any elements are added or removed in the portion that was already popped off the range, then the iteration count couldn't be used to calculate the length in the same way anymore. Now, with a hash map, the range is probably fully invalidated when anything gets added or removed anyway, since that probably screws with the order of the elements in the range, but how the range is going to behave when the underlying container is mutated and how having the length property does or doesn't affect that is something that you'll need to consider. - Jonathan M Davis I find that discussion very interesting as I had never considered that because of design by introspection having a costly length method would lead to unexpected calls by generic algorithms making it a disadventage if present. On the other hand I don't think the end user should have to scratch his head to find the length of a range, especially if it's not trivial to get (say, O(log n) kind of case). Therefore exposing a method in any case seems the best from an API perspective. But to avoid the performance issues mentionned earlier it means it should bear a different name (get/setLength comes to mind). I believe this is the same kind of issue that lead to having "in" for associative arrays but not regular ones. However this also leads to less coherent APIs in contradiction with the principle of least surprise. In retrospect since only "unexpected" calls to such methods cause the issue I wonder if it wouldn't be best to have an UDA saying "Hey, please, this method is costly, if you're a generic template performing introspection you should probably not call me". And writing that Andrei's work on complexity annotations comes to mind. Anyway, I don't think the user should use different names just to alleviate an issue on the library side but the alternative would be costly to put in place... Any thoughts?
Re: Strange Thread Causing Duplicating `writeln`
On Monday, 9 April 2018 at 22:28:45 UTC, Jonathan wrote:
I am totally lost on why this is happening.
I stripped the code down to what appears to be the most minimal
code that still causes the problem.
---
import core.sync.mutex;
import core.thread;
import std.stdio;
__gshared Mutex m;//__gshared just for testing (;
void thread1() {
foreach (i;0..8) {
synchronized(m) {
writeln("a1-",i);
}
writeln("a2-",i);
}
}
void thread2() {
foreach (i;0..8) {
synchronized(m) {
writeln("b1-",i);
}
writeln("b2-",i);
}
}
void main() {
m = new Mutex();
new Thread().start;
new Thread().start;
}
---
The beginning of the output for this code is:
a1-0
a2-0
a2-0
b1-0
b2-0
b2-0
a1-1
a2-1
a2-1
Why is the "a2" and "b2" writeln being repeated?!
I don't know, but I can't reproduce either with dmd or ldc. What
was your compilation line?
Re: What are AST Macros?
On Monday, 9 April 2018 at 15:30:33 UTC, Stefan Koch wrote: On Friday, 6 April 2018 at 21:45:45 UTC, Zach Tollen wrote: I think Walter's reason was that such macros would hide too many idiosyncrasies in how they were programmed, such that a lot of code which seems simple on the surface will actually obfuscate complicated and arbitrary macro-programming patterns. Thus, code that uses them will become much less maintainable, because it is liable to do so many different and hidden things. Also, the tasks for which AST-macros would typically be used are already largely accommodated by templates and other features. Thus, the real need for them isn't that high. I think it's time to revisit this. The reason being that templates are only well suited to very specific types of meta-programs which have a low degree of parameterization and a low degree of abstraction. Using templates to introspect and manipulate types is like using a hammmer's flat back to remove a nail. It _can_ be done but with an absurd amount of work. You just have to remove all of the wall around the nail by pounding it until the wall has around the nail is disintegrated :) This is not an exaggeration. Templates used for introspection (or anything else really that's modestly complex) are equally hard to reason about for compilers and for programmers. I guess programmers have an advantage when it comes to _efficient_ pattern recognition. Wouldn't AST macros require either to standardize (and freeze) AST representation within the compiler or to maintain an equally frozen alternate representation to be exposed? I can't see how that wouldn't make the compiler's development slower since all of a sudden changing the internal representation would impact user code, especially given the low number of breaking changes that are accepted today. I have little experience with AST macros outside Lisp where its homoiconicity avoids the issue almost completely so pardon the naive question.
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:48:51 UTC, jmh530 wrote: On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* [snip] Fantastic. This is so cool, I think it should be featured on the D blog as well (maybe when you get to your goal of having C++ features working consistently). More exposure is better exposure.
Re: Declare and Define Before Use? [rant]
On Wednesday, 4 April 2018 at 19:51:27 UTC, kdevel wrote:
On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
On Wednesday, 4 April 2018 at 18:57:27 UTC, kdevel wrote:
[...]
I think the rules should have been the same everywhere
and if there was an exception to be made, it could be made for
the main function
since the main function is special anyway
The main function of a program corresponds to the final
paragraph of a novel. I never understood why programmers place
this function which possibly depends on all other functions in
the translation unit at the beginning.
BTW: You can't write
void main ()
{
x.writeln;
int x;
}
import std.stdio;
There is no reason why the declaration of x should not be
postponed.
I've never seen the main function at the top but I think it would
be be nice place for it honnestly. Sounds more like a C legacy
than anything.
The reason why I place common imports at the top is because I
read a *lot* of code as my day job is to audit software. While
skimming rapidly through directories looking only at the top of
each file I know what they are about and can quickly infer their
purpose based solely on imports. This file does IO, this one web
stuff, etc (and to debunk quickly a counter argument I've heard
before: no, given how convoluted file names quickly get
especially in languages like java, directory structure isn't
nearly enough).
The same is true for the main function. If your code is clean it
should the main is the place where you orchestrate the whole
program. You should be able to grasp most of the program flow
from it. What it setups, information flow, etc. Of course in
practice people are often trying to burry useful information deep
down in functions (where it's generally too coupled for its own
good, but that's another story). Such burrying makes it harder to
get useful information from the main function, hence maybe why so
many are comfortable putting it at the end (I know I do by habit).
On the other hand, if the main effectively describes the programs
course then putting it at the beggining makes complete sense: it
is what you want to see first to get an idea of what the program
is doing. No function could be better suited for that.
Some points hinted here make me think of
https://www.youtube.com/watch?v=FyCYva9DhsI so maybe it could be
of some interest to you.
Re: Fix transposed ranges
On Monday, 2 April 2018 at 19:45:31 UTC, Steven Schveighoffer wrote: On 4/2/18 3:24 PM, Cym13 wrote: [...] Well, it's tough, because you can compose ranges in infinite ways. All you need to generate the warning is some code like this: [...] That makes sense, thanks.
Re: Fix transposed ranges
On Monday, 2 April 2018 at 18:33:25 UTC, Steven Schveighoffer wrote: On 3/30/18 4:45 PM, Cym13 wrote: On Friday, 30 March 2018 at 20:43:09 UTC, Cym13 wrote: Hi, I've got the following code that takes a list of files as argument and xor them together (demo example sufficient for that discussion). [...] Forgot to mention but I'm also quite annoyed at the need for that ".array" because "transposed" requires the RoR to be assignable. That kills the laziness. I'm very much open to suggestions regarding that point. 1. The .save deprecation may not affect you. It's probably being used by map or fold but may not need to be. Once it's removed, you may just see the warning go away, and everything still works just fine. I'm not 100% sure on this, as I don't know where it's being used. That's good to hear, although I don't realy like warnings on which I have no control. 2. The array is necessary, as map is lazy. what you want is a range of the first byte of each file, then a range of the second byte of each file, etc. mapping to a byte array can't possibly do this, because what would happen is that map would re-open the file, re-read it's contents, and then give you the *second* byte. This is horribly inefficient. While I agree that using an array is ugly, and that I want ranges of first byte (which is why I'm using transposed in the first place), transposed just doesn't let me work with the result of map itself. I suppose it's because its signature stipulates hasAssignableElements. I feel like I'm missing something there but I can't see what. But you can probably reduce the memory requirements by streaming each file's bytes as you need it. Unfortunately, I don't see a 'byByte' method on File, so you may have to look elsewhere for that. -Steve
Re: Optional parameters?
On Monday, 2 April 2018 at 09:31:35 UTC, Timoses wrote:
On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer
wrote:
I currently have a situation where I want to have a function
that accepts a parameter optionally.
I thought maybe Nullable!int might work:
void foo(Nullable!int) {}
void main()
{
foo(1); // error
int x;
foo(x); // error
}
Can somebody enlighten me what this topic is about?
I thought an optional parameter would be as easy as
void foo(int i = 0) { writeln(i); }
void main()
{
int x;
foo(x);
foo(1);
foo();
}
Is the Nullable!int approach because 'i' would always
"optionally" be 0 if not passed with above 'foo'?
Same feeling here, this situation really asks for a Null Object
pattern, not nullable. It's sad that nullable isn't very good in
that situation but trying to force it in place doesn't seem very
reasonnable.
