Re: Encapsulating trust
31.08.2014 17:47, Dmitry Olshansky пишет:
Quite recently a lot of work has been done to make most of Phobos usable
in @safe code.
While a very welcome effort, it caused a number of doubts in particular
due to the boilerplate required to isolate a small amount of unsafe
operations and slap "@trusted" over it.
See e.g. Denis argument:
https://github.com/D-Programming-Language/phobos/pull/2465
There were proposals for language changes along the lines of having
@trusted block alike to debug/version blocks, but nothing ever came out
of them.
Without language support I decided it worth a shot to create a universal
wrappers to establish a consistent convention. A use of such wrapper
should indicate that a @system function call or language feature was
hand-verified.
Names and complete set of primitives are up for debate, but here is the
start:
https://gist.github.com/DmitryOlshansky/bc02f369c8a63818bd07
A bit of usage:
import core.stdc.string;
import trusted;
void main() @safe
{
char[] msg = "Hello!".dup;
char[] msg2 = msg;
import trusted; // may also use static import for absolute clarity
assert(call!memcmp(addrOf(msg[0]), addrOf(msg2[0]), msg.length) == 0);
}
What do you guys think?
The language works fine for me as it is in this aspect. E.g. functions
from `std.file` like `read` should be marked as `@trusted` because this
is what `@trusted` is for, a function operating unsafe stuff and
providing a safe interface to it.
Currently the only problem is with templates like `std.array.Appender`
when we want the compiler to infer attributes from user type and have to
carefully wrap our code in `@trusted` blocks leaving calls to user code
unwrapped.
Yes, my opinion here is the same as Daniel's one.
About related `std.file` pulls:
I wrote my original comment [1] to the pull because it blows the code
size and reduce its readability by using `@trusted` nested functions
(lambdas not used just because they currently can't be inlined, but it's
silly as these functions work with disk and thus slow anyway).
This introduces a bad anti-pattern in the library and should be
reverted. Just imagine a D newbie who just started leaning the language
and is reading `std.file` module to see how easy can he use native API
in D (e.g. I was such newbie). With all these pulls merged (current
HEAD) he will be terrified of the code ugliness and either decide this
is the only way to use native API in D (wrap every native function in
`@trusted` nested function in `@safe` function) or will spend
significant time discovering the history of this module and who is
guilty in such bad design (e.g. I spend a lot of time when learned D
because of `TypeTuple` used with expressions which completely confused me).
[1]
https://github.com/D-Programming-Language/phobos/pull/2465#issuecomment-53950146
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: What about DGui?
15.05.2014 7:58, FrankLike пишет: 1.DFL's Memory Usage is the least than other. winsamp.exe is 2.1M,DFL's example's exe is 2.7M. 2.The size of DFL's example's exe files is the least than other, and only a single file. 3.DFL's source code is the most easy to understand. D need Christopher E. Miller. DFL isn't boost licensed, that's the problem for me. And Christopher didn't answered anything on my proposal to change the license. I'd suggest to put the effort in DGui [1] instead because its author, Antonio Davide Trogu, kindly changed the license to Boost as he want the library to be used. By the way, see DGui examples at Downloads page [2], they are smaller, than DFL ones. Also one of DGui goals was a source code simplicity. ) [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Allocating a wstring on the stack (no GC)?
07.05.2014 22:26, Maxime Chevalier-Boisvert пишет: I have a very specific use case (JIT compiler) in which I have a pre-allocated array of wchar string data stored somewhere in memory. I'd like to be able to create a temporary D wstring object to pass this as a "regular" string to other functions. For performance reasons, it would be preferable not to dynamically allocate or copy any data. Dynamically allocating the strings tends to trigger the D GC which severely impacts the performance. So, my question is, would it be possible for me to allocate a wstring object on the stack, and manually set its string data pointer and length? If so, how? Your wizardly help is much appreciated. If you have a preallocated data, just using slicing will be enough. A result will be `wstring` for immutable data or `const(wchar)[]` for non-immutable, if you respect a typesystem. If a new data is generated but you want it to be put on stack if it's small enough (you can't put big data on stack anyway) you need some allocation facility. E.g. `unstd.memory.allocation.tempAlloc` [1] will do the work. [1] http://denis-sh.bitbucket.org/unstandard/unstd.memory.allocation.html#tempAlloc -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 14:52, FrankLike пишет: On Sunday, 18 May 2014 at 09:22:53 UTC, FrankLike wrote: DFL isn't boost licensed, that's the problem for me. And Christopher didn't answered anything on my proposal to change the license. I'd suggest to put the effort in DGui [1] instead because its author, Antonio Davide Trogu, kindly changed the license to Boost as he want the library to be used. By the way, see DGui examples at Downloads page [2], they are smaller, than DFL ones. Also one of DGui goals was a source code simplicity. ) [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads Why not put it in github.com? Because personally I like Bitbucket (it has side-by-side diff and Github some time ago switched to completely unusable fonts for source code making it unreadable for Windows XP users like me). Thank you. And put it in code.dlang.org. Will do as soon as its Bitbucket support will be restored. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 18:25, FrankLike пишет: *http://denis-sh.bitbucket.org/ Where is the DGui? This dgui is very cool. The link is to my personal page. DGui isn't my library, I only manage it so it can't be listened in "my open-source projects" page. As for x64 support, yes is isn't ready. If it is needed just like any other feature feel free to open an issue. [1] https://bitbucket.org/dgui/dgui/issues -- Денис В. Шеломовский Denis V. Shelomovskij
Re: What about DGui?
18.05.2014 19:14, FrankLike пишет: On Sunday, 18 May 2014 at 14:54:44 UTC, FrankLike wrote: 1.DFL's Memory Usage is the least than other. winsamp.exe is 2.1M,DFL's example's exe is 2.7M. DGui's Memory Usage is 3.2M. [1] https://bitbucket.org/dgui/dgui [2] https://bitbucket.org/dgui/dgui/downloads You will put it in code.dlang.org and github.com? DGui is very cool,the exe's size is a half of DFL's,and it's easy to learn. If It will be used on Linux ,Mac Os X,it will be the coolist of all gui libs. Thank you. Frank And there are some controls are not implement,such as imageButton,GridView,DateTimePick,Socket,DataControl. Thank you. There is no plans for cross-platform porting or adding new controls in near future. Probably the situation may be improved in case developers of DFL unofficial fork [1] will join DGui development. [1] https://github.com/Rayerd/dfl -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Thank you Kenji
23.05.2014 8:11, Martin Nowak пишет: Today at DConf we learned, once again, that people are doing and starting amazing projects using D. A lot of which wouldn't have been possible without your contribution. So I just wanted to say thank you. -Martin Finally a thread to thank the man who fights all these corner cases and bugs. ) Thank you Kenji very much! -- Денис В. Шеломовский Denis V. Shelomovskij
Just curious: who do know current purity rules?
As Kenji Hara just created purity fixing pull [1] we will probably soon
have more intuitive rules so it's interesting who do understand current
purity rules. The following code is proposed to check your understanding:
---
alias F = bool function(int) pure;
alias D = bool delegate(int) pure;
D foo1(immutable F f) pure { return x => (*f)(x); } // ok or error?
D foo2(const F f) pure { return x => (*f)(x); } // ok or error?
D foo1(immutable F* f) pure { return x => (*f)(x); } // ok or error?
D foo2(const F* f) pure { return x => (*f)(x); } // ok or error?
---
Who passes this test? By "pass" I mean completely understand what the
compiler do and why.
By the way, personally I would fail the test. )
[1] [spoiler!] https://github.com/D-Programming-Language/dmd/pull/3626
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Just curious: who do know current purity rules?
06.06.2014 13:05, Kagamin пишет: Do you mean true purity rules or whatever is implemented in the compiler? "whatever is implemented". ) -- Денис В. Шеломовский Denis V. Shelomovskij
