Re: DIP1028 - Rationale for accepting as is
On Wednesday, 27 May 2020 at 13:47:46 UTC, Claude wrote:
On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic
wrote:
Is the actual problem those `@trusted:` declarations at the
top of C headers?
There could be a simple solution to that:
Ban `@trusted:` and `@trusted { }` which apply to multiple
symbols. Only allow `@trusted` to apply to a single symbol. For
IMO, it makes things worse. Because the careless programmer
will slap @trusted to every declaration (maybe with a script or
find/replace macro of his editor). So now, we don't know if the
annotation is greenwashing or careful examination of the
definition.
At least with "@trusted:" and "@trusted { }", the greenwashing
is obvious.
the problem here ist: we are talking about careless programmers.
for those of us who actually care about safety it will be like:
1. ok lets write an extern(c) function.
2. forget to annotate it by accident.
3. hit compile
4. a) get an compiler error the hints that we missed that
annotation
or b) no error at all and we now have silently added unsafe code
to our codebase.
also, you can never trust that an @trusted function is actually
memory safe.
even if it was evaluated in the past. the addition of new code
(and even completely @safe code) can break any assumptions that
@trusted fun was relying on.
so a competent QA team _has_ to either check all @trusted code
fragments.
or with this dip check all @trusted and all extern functions.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote: On 25/05/2020 10:29 PM, Zoadian wrote: you complain about @trusted losing it's meaning, but @safe was ment to mean "mechanically verified memory safety". it should be forbidden to add @safe to any function that can not be verified by the compiler. It is meant to mean that at some point it has been mechanically checked by the compiler. Either during current compilation or a prior one. Which means it has to be valid on function declarations without bodies so i.e. .di file generation works correctly which is just a generated D file, nothing special syntax of semantics wise. .di files _could_ just use @trusted instead of @safe. but for extern(D) we could at least add it to the name mangling. it's still not 100% safe, but at least you'd have to work hard to get it wrong.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote: On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote: [..] But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion. [..] The alternative, not making extern @safe, would result in more untrustworthy @trusted code we have to worry about. It's a vicious circle. I try to relax my view on extern annotations. They are @system. We *should* go ahead and diligently mark with @trusted. From experience, it doesn't normally happen. I don't like @safe extern, but it seems like the lesser evil. Walter got a lot of flak. I tried to retrace his thoughts and see the merits. there is no such thing as a trustworthy @trusted. not with how the whole safety system work now. you can break previously verified @trusted code by just writing @safe code today.
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 09:25:52 UTC, Johannes T wrote: On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote: [..] After thinking about it, Walter ultimately made the right decision, leading to overall higher safety and code quality. We all agree that making extern C @safe is incorrect. It's also meaningless. Even if you were to verify the safety of a specific version of your binding, it can't be known what's loaded at runtime. It's not the compiler's concern. @safe extern shall be an error. We might additionally make an exception and make all extern C @system. It would be correct for the declarations, but inconsistent in regard to default safety. It doesn't affect the outcome. Let's say we'll go with @system, it gives us a bit more freedom. We hit compile, our now safe wrappers are errors. We are most likely to do one of two things, depending on the module failing to compile. If it mostly wrappers, we slap @trusted: at the top. If there are just a few functions calling C, we only annotate those with @trusted. Let's be real, we probably won't begin checking and annotating the trustworthiness of the C functions. An individual programmer might, but not on average. We are formally correct, but @trusted can't be trusted at this point. It has lost its meaning. We now have to check all foreign @trusted code, which we probably won't. We could have moved the problem one level down and slapped @trusted: on top of the @system declarations. Now there is a bunch of safe code using them. It doesn't change much. @trusted: is easier to grep, but we won't put everything down and begin trustworthily annotate extern C. So yeah, I do believe Walter was right. @safe on extern is formally incorrect but leads to safer code because @trusted still has its power. you complain about @trusted losing it's meaning, but @safe was ment to mean "mechanically verified memory safety". it should be forbidden to add @safe to any function that can not be verified by the compiler. the compiler should do it's best to alert you of any mistakes you might make. if the compiler does silently add @safe or @trusted to extern(C) functions you are are to miss annotating it. that is a bad thing for everyone that actually cares about safety. you can't prevent programmers from doing stupid things. but you can at least warn them.
Re: wiki tutorial: D on esp32/esp8266(llvm-xtensa+ldc) and how to get started
On Tuesday, 26 November 2019 at 08:57:49 UTC, dangbinghoo wrote: hi, I just added a simple tutorial to running D betterC on the popular ESP32/esp8266 IoT chip. referenced with the Rust community's Rust on ESP32. https://wiki.dlang.org/D_on_esp32/esp8266(llvm-xtensa%2Bldc)_and_how_to_get_started As esp32 IDF is using newlib as it's libc, the druntime and phobos just simply won't build. But betterC seems working, I didn't do with a very strong test(actually I don't know if there's betterC test case exists), so, just for fun with your own risk! And, Can we do some work to support druntime building against with newlib? If this is true, many MCU would have(newlib supports many MCUs) a `real D` running on it. --- Binghoo Dang I'm also interested in a esp32/esp8266 port of druntime/phobos. If you want to join forces ping me on discord or irc. -Zoadian
Re: Private variables accessible from outside class
On Thursday, 8 August 2019 at 15:51:45 UTC, Drobet wrote:
I'm having a weird issue, where after defining my classes
variables as private, they can still be modified and looked at
from the outside. That leads to this code compiling with no
issues.
import std.stdio;
class Vector3
{
this(double _x = 0.0, double _y = 0.0, double _z = 0.0)
{
x = _x;
y = _y;
z = _z;
}
private:
double x, y, z;
}
int main()
{
Vector3 vec = new Vector3(5, 5, 5);
vec.x = 10;
writeln(vec.x);
getchar();
vec.destroy();
return 0;
}
My question is if this is intended behavior, and if yes, why?
private means module private in D.
see: https://dlang.org/spec/attribute.html#visibility_attributes
Re: How do you debug @safe @nogc code? Can't figure out how to print.
debug {
import std.stdio;
writeln(args);
}
Re: Automatic variable declaration
On Wednesday, 15 August 2018 at 14:58:40 UTC, Everlast wrote:
Many times one must create a variable before a function call:
int x = 3;
foo(x);
writeln(x);
[...]
check this out:
void main() {
import std.stdio;
writeln = 4;
}
https://run.dlang.io/is/0wgWtw
Re: std.signals non-object delegates
On Tuesday, 12 June 2018 at 15:21:49 UTC, Jacob Shtokolov wrote: On Tuesday, 12 June 2018 at 14:33:57 UTC, Steven Schveighoffer wrote: [...] Thank you Steve! Then I'll try to fire a bug report and propose my own solution to this problem. Probably there is no need to track down the non-object dispose events. Good to hear that not so many people are affected by this i remember someone was working on a std.signals replacement a few years ago. don't know where that went. it might be this: https://wiki.dlang.org/Review/std.signal https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d
Re: Sealed classes - would you want them in D? (v2)
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote: I propose an idea, for discussion (robust discussion even better ;-) Add an new attribute to class, named 'sealed'. If class level protection is added, please do not call it sealed. People from c++ might be suprised by 'private' already. We do not have to confuse those c#ies too. Module level protection is enough to hide implementation details though. So while i do understand why you want this in D, i don't think it is worth it to complicate the language for something you can work around easily by putting the classes in their own modules. I'm also not convinced think that your 'sealed' would be used much, because accessing private state in the module is actually extremly useful (e.g. unittests). That beeing said, if you are convinced it would be a good addition, please write a DIP. Even if it will not be accepted it will at least force a decision. And we can point to the reasons it got accepted/rejected in the future.
Re: Favorite GUI library?
On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote: On Monday, 23 April 2018 at 11:26:30 UTC, Chris wrote: On Monday, 23 April 2018 at 09:50:21 UTC, Zoadian wrote: i'm happy with: vibe.d + CEF + vue.js Good point. I've been thinking about vibe.d + HTML/JS based UIs too. I think that's where UIs are increasingly moving towards: HTML+CSS + some sort of web-based backends. That's definitely what I'm trying to avoid... I feel those kinds of interfaces are 99% of the time mega bloated for what they are. Discord is the only one that seemed big enough for the britches of an entire browser instance. Absolutely not a fan of Electron and the like. If we are talking binary size: then yes, I agree. But it is a lot easier to maintain & write than QT-Widgets/GTK based code.
Re: Favorite GUI library?
On Monday, 23 April 2018 at 06:12:33 UTC, TheGag96 wrote: Heya guys. For my projects that use a GUI library, I've tried both tkd and DlangUI. Both I feel have their drawbacks, and I'd like to know if any of you are using anything you find better. In my case, my ideal choice would be: - Nice bindings/API, friendly to idiomatic D - Cross platform - Can compile to a standalone binary (no shared libraries or extra files) - Reasonably efficient - Support for a good amount of well-working widgets Although quite a cool library, my biggest issue with DlangUI was that it was a little mind-bending at times to keep track of multiple widgets that view/modify the same data without screwing things up. I saw QtE5 recently and have been thinking about trying it out. What do you all recommend? Thanks! i'm happy with: vibe.d + CEF + vue.js
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 00:53:16 UTC, psychoticRabbit wrote: It should have gone to the Java developers - cause they deserved it. C++ is the worst thing to have ever come out of computer science! yes c++ is not the greatest language (thats why i use D). but java is the worst language i've ever used.
Re: Beta 2.079.0
On Thursday, 22 February 2018 at 10:42:33 UTC, Jonathan M Davis wrote: On Thursday, February 22, 2018 10:30:44 psychoticRabboit via Digitalmars-d- announce wrote: On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote: > I'm going to a) never write these imports and b) pretend this > feature doesn't exist. > > Atila what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution. Honestly, I'm against importing multiple modules on a single line just like I'm against putting multiple variable declarations on a single line. They're harder to read and easier to screw up. - Jonathan M Davis +1 I agree 100%
Re: Vulkan
On Friday, 16 February 2018 at 22:58:30 UTC, Ivan Trombley wrote: On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote: What [does] it mean to say they don't work? Have you reported any issues? I don't see any in the DerelictVulkan repo. If something's broken, please report it so it can be fixed. Derelict-vulkan is Windows only ATM. Actually someone added posix support. Just forgot to flag a new release. (I did not test posix support myself yet). If there are other issues please file them on GitHub.
Re: Thoughts about D
On Monday, 27 November 2017 at 09:07:10 UTC, Nicholas Wilson wrote: On Monday, 27 November 2017 at 07:58:27 UTC, IM wrote: On Monday, 27 November 2017 at 03:01:24 UTC, Jon Degenhardt wrote: Forum discussions are valuable venue. Since you are in Silicon Valley, you might also consider attending one of the Silicon Valley D meetups (https://www.meetup.com/D-Lang-Silicon-Valley). It's hard to beat face-to-face conversations with other developers to get a variety of perspectives. The ultimate would be DConf, if you can manage to attend. Thanks. I intend to attend some of their meetup events. I'll be giving a presentation on Thursday evening on using D for (among other things) GPGPU, hope you can make it! Any chance it gets recorded? I'd be highly interested!
Re: D, ZeroMQ, Nanomsg
On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote: Hi, I see that some people have wrapped in various different ways ZeroMQ. Was this manually, or using DStep? Has anyone wrapped Nanomsg? If yes, was this manually or using DStep. derelict_extras-nanomsg was converted manually
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Please report your CPU (GitHub/Gist): my results for Intel Core i7-6700K CPU @ 4.00GHz rev.2 (the one with sgx) https://gist.github.com/Zoadian/f53d818e714a849ba7f34bbec2f3339a awesome!
Re: OT: Vulkan released
On Tuesday, 16 February 2016 at 14:20:51 UTC, Ola Fosheim Grøstad wrote: https://www.khronos.org/vulkan/ OS-X Metal is kinda like a C++ derivative => GPU compilation. With Vulkan/SPIR other languages should be able to come up with something similar for other platforms. finally. I'll write derelict bindings.
Re: Iterating over modules
On Thursday, 4 February 2016 at 15:45:03 UTC, Satoshi wrote: Hi, is there any way how to iterate over every module/submodule? I have project like Rikarin Rikarin/AppKit Rikarin/Drawing Rikarin/Runtime etc. In every directory, I have package.d file where I include every .d file from the dir. And the think what I want to do is to define UDA's like @Action, @Outlet, etc. for methods and generate runtime info for them. I know I can use something like mixin(generate!...); in every file where I used that UDA's, but its not the best idea for me. disclaimer: I don't know if this works. enum fileContent = import(__FILE__); parse imports and repeat this recursivly for all found imports
Re: Logo for D
On Monday, 18 January 2016 at 22:48:52 UTC, Brad Anderson wrote: Doesn't it look so much better: http://i.imgur.com/QlrbCou.png +1
Re: [dlang.org] new forum design - preview
On Wednesday, 13 January 2016 at 13:41:00 UTC, Bubbasaur wrote: May I suggest one thing? Could you put the page numbers on top instead of bottom? Because this is a common style in many pages, I think It would be nice if it was right bellow of (Log in,Settings,help), because currently, if I want to go to page 50, I need to scroll down 5 times. +1
Re: AST like coding syntax. Easy upgrade!
On Sunday, 6 September 2015 at 19:32:58 UTC, Prudence wrote:
template X(Y)
{
string X = Y.stringof;
}
[...]
as you'd have to write a parser for other languages why not just
use strings? you can already do this:
template X(string Y)
{
enum X = Y;
}
auto s = X!q{int 3;};
obviously X has to be a compiletime js->d compiler.
Re: else if for template constraints
On Monday, 17 August 2015 at 16:57:33 UTC, Zoadian wrote: wouldn't is(typeof(replace(array, from, to, stuff))) better be a static if inside the first version? nevermind, I missed that the first constraint is negated. In that case I agree, else if would be nice.
Re: else if for template constraints
On Monday, 17 August 2015 at 13:18:43 UTC, Steven Schveighoffer
wrote:
void replaceInPlace(T, Range)(ref T[] array, size_t from,
size_t to, Range stuff)
if(isDynamicArray!Range
is(Unqual!(ElementEncodingType!Range) == T)
!is(T == const T)
!is(T == immutable T))
{ /* version 1 that tries to write into the array directly */ }
void replaceInPlace(T, Range)(ref T[] array, size_t from,
size_t to,
Range stuff)
else if(is(typeof(replace(array, from, to, stuff
{ /* version 2, which simply forwards to replace */ }
looks much better IMO. Can we do something like this? I'm not a
compiler guru, so I defer to you experts out there.
-Steve
wouldn't is(typeof(replace(array, from, to, stuff))) better be a
static if inside the first version?
Re: Wait, what? What is AliasSeq?
On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote: Some of the proposals do not even make any sense. Come on, all people that got into this know how newcomer react to the Tuple name noticed the same reaction. Yet, there is a large crow of idiots (sorry if you are in that crowd, on that one you ARE an idiot) that will send that proposal in again and again. Anyone that proposed that name at this point should only be laughed at, as it is clearly the manifestation of someone that have not deal first hand with the problems of the historical name and is serving as a living example of Dunning Kruger. i get that TypeTuple is confusing as it is not _limited_ to types, but why is it not a tuple?
Re: Wait, what? What is AliasSeq?
On Tuesday, 21 July 2015 at 16:54:54 UTC, H. S. Teoh wrote: On Tue, Jul 21, 2015 at 04:06:11PM +, Zoadian via Digitalmars-d wrote: On Tuesday, 21 July 2015 at 06:49:10 UTC, deadalnix wrote: Some of the proposals do not even make any sense. Come on, all people that got into this know how newcomer react to the Tuple name noticed the same reaction. Yet, there is a large crow of idiots (sorry if you are in that crowd, on that one you ARE an idiot) that will send that proposal in again and again. Anyone that proposed that name at this point should only be laughed at, as it is clearly the manifestation of someone that have not deal first hand with the problems of the historical name and is serving as a living example of Dunning Kruger. i get that TypeTuple is confusing as it is not _limited_ to types, but why is it not a tuple? Because, among other things, it auto-expands. T I agree that auto-expansion is a bit unexpected (documentation does not even mention it...). But by that logic it's not a 'Sequence', 'List' or 'Pack' either. Can't we just call it Unpack!() then?
Re: Wait, what? What is AliasSeq?
It is a compiletime tuple so i'd vote for: CtTuple
Re: 0 is not a power of 2
On Tuesday, 19 May 2015 at 18:04:49 UTC, Marco Leise wrote:
Am Mon, 18 May 2015 22:16:47 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
But that has branches in it. So I came up with:
bool isPowerOf2(uint x)
{
return (x (x - 1) | !x) == 0;
}
which has no branches at least with dmd, see
http://goo.gl/TVkCwc.
Any ideas for faster code?
Thanks,
Andrei
Any faster ?! This is already minimal assembly code with
pretty looks!
While you are at it, you might also need round pointer up to
and round pointer down to, which can be implemented with bit
ops for power-of-2 multiples.
Its the kind of stuff that's not really a std.algorithm
candidate, but still somewhat common in memory management code.
Often these and other little helpers end up in everyones
stdlib_extensions.d which I suppose don't look all that
different. Who has some of these in their code?:
- isPowerOf2, nextLargerPowerOf2
- roundUp/Down to multiple of X
- increment with wraparound at X
- clamp value (low, high or both ends)
- check if numerical value is in between two others
- compile time iota
- format an argument as it would appear in source code
(i.e. add quotes around strings)
+1 ;)
all except the last one
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 10:34:32 UTC, bearophile wrote: Ola Fosheim Grøstad: Yes, but what is a strict mode. I agree with most of what is said about D and Go in the top post, but is there a market for yet another high level language that isn't high level enough? Strict mode is a D2 with immutable+@safe+pure by default, something like a var keyword to denote mutable values, no comma operator, static full tracking of memory ownership, less implicit casts (because now we have the safe int(x) sytnax), and few other small changes that make the language less bug prone and more strict. And I'd still like built-in tuple syntax in D. Bye, bearophile +1
Re: 2D game engine written in D is in progress
On Tuesday, 3 February 2015 at 16:30:27 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/VDP-engine Alpha release. Very basic functionality at the moment, will be expanded later. had a quick look: public class Color This is probably going to be slow. you want to read about 'cache friendliness'. And for a game/graphics engine also google 'data oriented design'.
