Re: SecureD - A simple cryptography library for D
Adam Wilson wrote: Adam Wilson wrote: rikki cattermole wrote: On 14/11/2016 9:31 AM, Adam Wilson wrote: Jacob Carlborg wrote: On 2016-11-12 21:50, Adam Wilson wrote: I choose OpenSSL because it's a well respected, highly trusted, and it is available everywhere. I despise the license and the API. Sadly, those are not primary concerns when dealing with Cryptograpy libraries. Well, Apple abandoned it years ago because it was difficult to upgrade without breaking applications that are using it. There are also very few core developers working on it, as I understand it. Other companies/organizations have abandoned it as well in favor of other implementations like libressl due to various reasons. Perhaps, if possible, a common API on top of whatever is the "native" cryptographic library on each supported platform. What if we did something with DUB build configurations. You can build the default OpenSSL configuration or build a Botan configuration based on the Botan D port depending on your needs. They would use the same cryptographic primitives and produces the same results, just using different libraries. Would that work? Yup, simple set of versions should do it. I'll take a look at it. Botan should be easier to work with than OpenSSL. This is going to have to wait. The Botan port currently does not build with 2.072.0 due to the removal of std.stream. I've filed a bug here: https://github.com/etcimon/botan/issues/24 The std.stream deprecation has been fixed and I've pushed the code to implement Botan, but the tests fail on a SegFault inside Botan in the PEM export functions. AES/Hash/HMAC/PBKDF2/RNG work. On OSX you need to use LDC or the linker will fail. Tracking issue for the segfault: https://github.com/etcimon/botan/issues/25 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: DIP 1003: remove `body` as a keyword
On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote: DIP 1003 is faddish. It would really be better to have a system that would allow any keyword to be used as identifier. An escape system is the key. It would also guarantee that the DIP would not be accepted. With this DIP I aimed for the smallest possible change that would alleviate the problem of not being able to use `body` as a symbol name, hoping that the smallness of the problem and ease of implementation would make it much more likely to be accepted.
Re: Tutorial: Form upload in vibe.d
On Saturday, 10 December 2016 at 17:39:20 UTC, aberba wrote:
On Thursday, 8 December 2016 at 20:48:52 UTC, NVolcz wrote:
On Tuesday, 6 December 2016 at 22:28:04 UTC, aberba wrote:
[...]
Love the article! Please keep writing tutorials like this :-D.
Feedback:
1.
The upload function is (kind of) vulnerable against path
traversal:
moveFile(file.tempPath, Path("./public/uploads") ~
file.filename);
[...]
Thanks for feedback. Will consider those points raised in
thought. Will add more advanced stuff and security as time goes
on.
Please fix the security vulnerability for this tutorial as well
in case someone copy pastes the code.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote: On Saturday, 10 December 2016 at 20:25:05 UTC, Mike Bierlee wrote: On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters. What are properties if not "getters" and "setters"? From the original post: "It would generate 2 methods "num": one to set num_ and one to get its value." Two methods named "num". No "get" or "set" in sight. I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Yeah, I see, @property seems to bring some additional features. Will think about it. Thanks.
Re: Getters/setters generator
On Saturday, 10 December 2016 at 16:37:53 UTC, Iakh wrote: On Friday, 9 December 2016 at 16:30:55 UTC, Eugene Wissner wrote: On Friday, 9 December 2016 at 12:37:58 UTC, Iakh wrote: Is there possibility to remove affixes in generated accessor names? No, there is no way to manipulate the accessor names. What affixes do you mean? You can remove suffix "_" so "name_" becomes "name". But I like to see genarated accessors "name" for field "m_name" no, it isn't possible. we just hard coded the most simple and the most "d-style" convention.
Re: DIP 1003: remove `body` as a keyword
On Sunday, 11 December 2016 at 11:33:40 UTC, Basile B. wrote: On Sunday, 11 December 2016 at 07:52:28 UTC, Rory McGuire wrote: On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: [...] Why is #line obsolete? I use it a lot in string mixins to make the correct line numbers show. In the compiler it is. Last Fall I asked and I've got for reply that is was useful in the past to debug mixins, in the compiler itself. I didn't know that people use it. Anyway it doesn't change anything. DIP 1003 is faddish. It would really be better to have a system that would allow any keyword to be used as identifier. An escape system is the key. It would also allow to interface to libs written in another language exporting a D keyword as symbol. I have no example here but I can imagine this happening quite easily.
Re: DIP 1003: remove `body` as a keyword
On Sunday, 11 December 2016 at 07:52:28 UTC, Rory McGuire wrote:
On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via
Digitalmars-d-announce < digitalmars-d-announce@puremagic.com>
wrote:
On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:
On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:
On 11/24/2016 05:29 PM, WM.H wrote:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot
wrote:
DIP 1003 is merged to the queue and open for public
informal feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
If you want the change to be approved and have ideas how
to improve it to better match on
https://github.com/dlang/DIPs/ blob/master/GUIDELINES.md
and existing published reviews - please submit new PR with
editorial and ping original author.
This DIP fixes the problem for "body" but not for the other
keywords. After all the problem may exist for other
keywords. Was a new pragma considered ? For example an
identifier alias.
pragma(idAlias, "body", "body_" )
AFAIU, the point of this DIP is that "body" is standing out
from other keywords being used only in one very specific
context and being a very common english word at the same
time. Your proposal has a completely different (and much
more drastic) approach.
Yes. But while it's clear that "body" is a keyword that's
less related to programming languages than the others (i.e
more usable as identifier), it's not actually that mad to
imagine a generic approach. For example Object Pascal has
such a feature:
http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_
for_.26-escaping_of_keywords
which is not well known, as I've myself discovered this just
3 minutes
ago.
In D there would be the "#" token that's not really used,
which could
serve to escape keywords, while still considering them as
identifier when
it's needed, e.g
struct Body{}
Body #body;
writeln("'", #body.stringof, "'");
would output: 'body'
By the way a pragma was a bad idea. Pragmas are optionally
supported by a compiler. An escape symbol is by far better.
Whatever is the compiler we always want the same result.
Any chance to get "Cauterite" thoughts on the option that is
to have a token used to escape a keyword, so that the kw can
be used as identifier ?
The initial DIP is too specialized, however it shows a real
problem:
What if one day someone wants
enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
function Function;
With an escape it would always work
enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
#function Function;
The problem of the suffix "_", as proposed in D style guide,
is that it's
also a valid identifier character, while "#" is not. And the
best is that #
role is already for special token sequences !
- # = token for special token sequence
- body = token
=> #body is a special token sequence.
The only thing to change is that currently a special token
sequence takes a full line...but seriously that's a minor
change (since there's no special token sequence in D... #line
is obsolete and not used anymore).
Why is #line obsolete? I use it a lot in string mixins to make
the correct line numbers show.
In the compiler it is. Last Fall I asked and I've got for reply
that is was useful in the past to debug mixins, in the compiler
itself. I didn't know that people use it. Anyway it doesn't
change anything.
DIP 1003 is faddish. It would really be better to have a system
that would allow any keyword to be used as identifier. An escape
system is the key.
