Re: A collection of DIPs
On Saturday, 12 September 2015 at 15:54:53 UTC, Adam D. Ruppe wrote: D programs *never* have a GC thread. Remember, the D GC isn't magic and isn't actually even that complicated, it is just an ordinary function call. That's what I was afraid of :'(
Re: A collection of DIPs
On Friday, 11 September 2015 at 19:30:56 UTC, ponce wrote: Some of us use and need @nogc all the time. The other parts of an application can use the GC: best of both worlds. Is there even a compiler switch to disable GC altogether so the program doesn't have a GC thread? No, I can't see it...
Re: A collection of DIPs
On Saturday, 12 September 2015 at 06:25:45 UTC, NX wrote:
Is there even a compiler switch to disable GC altogether so the
program doesn't have a GC thread? No, I can't see it...
D programs *never* have a GC thread.
The way the D garbage collector works is something like this:
void* GC.allocate(size) {
if(!GC.disabled && existing_memory_usage + size >=
existing_gc_pool) {
GC.collect();
if(existing_memory_usage + size >= existing_gc_pool) {
request_more_memory_from_operating_system();
}
}
if(still_not_enough_room) throw OutOfMemoryError();
existing_memory_usage += size;
return pointer;
}
The GC only collects when GC.collect is called, which runs as a
normal function in the current thread (it pauses other threads it
is aware of so they don't cause race conditions btw). GC.collect
is only called when you explicitly ask for it by calling it
yourself, at program termination, or when you call allocate as
seen in the pseudocode above.
If you never call GC.allocate, the GC never actually does
anything. It will never pause the program and it will never
collect.
That's what @nogc does btw, it doesn't disable the GC since
there's nothing to disable, it just flags any call to GC.allocate
(including hidden ones behind the new expression, etc) as a
compile error.
Remember, the D GC isn't magic and isn't actually even that
complicated, it is just an ordinary function call.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 10:00:10 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 9 September 2015 at 06:13:59 UTC, Dominikus Dittes Scherkl wrote: IMHO "friend" is a misconception, that is only there to compensate for the lack of modules in C++. It can be useful. Say you have a database engine module and an ORM module, you might want to give the ORM special privileges to certain parts of the database engine, but shield it from the rest of the program. That's what the `package` access modifier is for.
Re: A collection of DIPs
On Saturday, 12 September 2015 at 13:48:14 UTC, ZombineDev wrote: That's what the `package` access modifier is for. Then you would have to be in the same package, and that is rather broad? The advantage of "friend" is that you can pinpoint what might be a source for trouble when debugging, it is narrow.
Re: A collection of DIPs
On Saturday, 12 September 2015 at 06:25:45 UTC, NX wrote:
On Friday, 11 September 2015 at 19:30:56 UTC, ponce wrote:
Some of us use and need @nogc all the time. The other parts of
an application can use the GC: best of both worlds.
Is there even a compiler switch to disable GC altogether so the
program doesn't have a GC thread? No, I can't see it...
There are a few levels of 'everything @nogc' you can go - make
`main` @nogc but still have the runtime initalised, link to
`_start @nogc` and intercept it so that it doesn't even start the
runtimes, or (for minimising the binary/going bare metal)
providing a custom null runtime and not linking the D runtime at
all.
From when I tried to make the smallest PE hello world I could for
2.066:
//Level 1
void main() @nogc
{
//Do stuff
}
//Level 2 - no runtime initialisation, runtime still there
though
extern(C) void _start() @nogc
{
//Runtime not started yet - must be initialised before
using much of the standard library
}
//Level 3 - no runtime, trick the linker (it expects runtime
hooks)
extern(C)
{
@nogc:
//Custom runtime/moduleinfo stuff - not very portable in
my experience - YMMV
//Provided so the linker doesn't have any 'runtimeFnHook
missing' errors, but we don't actually include the runtime
__gshared void* _Dmodule_ref;
//Depending on compiler/version, these may have to exist
for the linker
//__gshared void* _d_arraybounds;
//__gshared void* _d_assert;
//__gshared void* _d_unittest;
//May want to provide empty bodies instead if your linker
can remove unused
// / garbage functions
void _d_dso_registry(void* ignore){}
void _start()
{
//Bare metal ready
}
}
I needed a few runtime-affecting compiler (and linker) switches
too, depending on which compiler I was using, although it was
mostly obvious stuff listed in `$(compiler) --help`.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 20:42:35 UTC, Laeeth Isharc wrote: On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: D has zero use in anything time sensitive. You mean, for example, like dealing with data for a billion customers and responding in a few hundred microseconds? ;) https://www.sociomantic.com/technology/ I really wish you would focus on people using the standard runtime and not the single odd one working around a issues using custom implementations. Yes, you can avoid using fork-unfriendly resources in some cases, hire people that makes it possible to use a fork() GC, and write your programs so that you only write to a small set of pages during collection (goodbye refcounting). You can also add lots of memory and an expensive high bandwidth Xeon with 4x higher memory throughput. Does not help people wanting to write iOS applications or games that run on cheap home devices. It's like saying you can do anything in C. Yes, you can. You can do anything in C, C++, Rust, Go, Ada, Modula-3, Java and most other languages if you invest enough resources and limit your program logic. People created great games in BASIC on C64s.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 21:27:02 UTC, deadalnix wrote: You can make a difference. Yes you probably don't have as much experience, but that's a great opportunity to learn. Many here would be willing to mentor you if you want. I can do it if you want to contribute to SDC. I'm sure other would on other projects they are familiar with. Generally, don't underestimate the impact you can have. Everybody think someone else will do it and is more qualified? Turns out that nobody is qualified before having done it for a while. So unless you get started, you'll never be qualified. Aaaannndd, I started reading GC theory books.
Re: A collection of DIPs
On Friday, 11 September 2015 at 01:04:56 UTC, Brandon Ragland wrote: And @nogc is just a band-aid fix. Might as well go back to C or C++ and leave the silly @nogc behind with all it's weird integration rules when working around managed memory. Some of us use and need @nogc all the time. The other parts of an application can use the GC: best of both worlds.
Re: A collection of DIPs
On Friday, 11 September 2015 at 01:04:56 UTC, Brandon Ragland wrote: There was a lovely article by a fellow for his PhD on how D garbage collector was literally killing his JavaScript engine, It was a she :-). Some people have focused on the GC, but you actually need to change the strategy so you look at fewer cachelines, prefetch perfectly and do less work at runtime. I would estimate that you could improve global mark-sweep by 2-4x, but it takes a lot of work, not only on the runtime. And maybe 2-4x improvement is too little anyway. And @nogc is just a band-aid fix. Might as well go back to C or C++ and leave the silly @nogc behind with all it's weird integration rules when working around managed memory. I don't agree. I think D could find a sweet-spot as a cleaned up C/C++ solution, but then you need to change the semantics somewhat. I'm very much in favour of a reduced version of D that keeps, and improves, on the compile time advantage D has. Essentially is a zero-runtime language that is better than C.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: It's slow, really slow, and stopping the entire world is painful, even in trivial user applications. A pause for even half a second or less on the UI makes the application looks "chunky" and broken. If you're having that much serious problems then there is only one thing I can think of: Your computer is survived from 90s The more you don't collect, the more time it takes time to collect; thus, you may want to configure GC to do it's job more often so it doesn't stop significantly, and also manually trigger collection where appropriate... If I had the time and knowledge I would spend them to make D better, but you can't expect a teenager (tip: me) to help making DMD front-end better or to implement a precise GC... I guess? You would be surprised at the number of folks who've made great enhancements, or contributions, to various open source projects over the decades that are not even 18. The beauty of open-source is that talent is no longer defined by your age, gender, or location, and is defined entirely by ability, and sometimes, the ability to conform to that open-sources' project standards / expectations. Age need no part in the equation ;)
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 20:42:35 UTC, Laeeth Isharc wrote: On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: D has zero use in anything time sensitive. You mean, for example, like dealing with data for a billion customers and responding in a few hundred microseconds? ;) https://www.sociomantic.com/technology/ Case closed. SOMEBODY SAVE ME! D's garbage collector is a FAIL, and that makes the rest of the language a FAIL until it get's fixed. Have you tried using EMSI's containers with Andrei's allocator ? They use them in production, I gather. http://www.economicmodeling.com/2015/08/20/nyt-uses-emsi-data-to-help-bust-the-myth-of-the-creative-class-apocalypse/ https://github.com/economicmodeling/containers That's really interesting ;)
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: It's slow, really slow, and stopping the entire world is painful, even in trivial user applications. A pause for even half a second or less on the UI makes the application looks "chunky" and broken. If you're having that much serious problems then there is only one thing I can think of: Your computer is survived from 90s The more you don't collect, the more time it takes time to collect; thus, you may want to configure GC to do it's job more often so it doesn't stop significantly, and also manually trigger collection where appropriate... This might be true, however even small collections, run multiple times, can still sum to the total collection time, even if delayed. In video games, this becomes an issue: lag spikes every 5 seconds, or generally reduced frame-rate from 30 to 20 FPS. It does make a difference in the end game. In time sensitive trading data, there are scenarios in which a 1millisecond delay could cost a few penance, times however many shares you bought. The bottom line, is there's a reason even Java and C# aren't "widely" used in such time sensitive issues, because they're generally slower, than the old CBOL or newer technologies running on C or the likes. However, when once compares Java's or C#'s GC to D, the difference is so dramatic, it makes me say one thing: Is D's garbage collector really from the 90's? That's the level of thought and sophistication that went into it. That of the earliest GC from the 90's and early 2000's era. It's been almost 20 years. It's really time to catch up guys. There's really no excuse why D is still using a GC from an era almost 2 decades ago. The JDK has supported generational GC since 1.2 and parallel GC from (don't quote me) 1.4 or perhaps earlier. Parallel GC has been a feature of most modern languages for close to, if not exceeding, 10 years now. D is still using a basic GC that only saw light of day in Java a decade ago or longer. The more time that goes by, the better Java, C#, Pyhton, etc. get at Garbage Collection, and the changes in D have stalled. We are sinking in a boat fast. There was a lovely article by a fellow for his PhD on how D garbage collector was literally killing his JavaScript engine, using some 100X more GC time than Java would have, and he contemplated switching from D for that reason alone. That article, found on reddit, is what "made" the leadership for D consider a rewrite of the GC. Well one year on, and it still hasn't happened. That's very dismal progress for a very critical part of the puzzle. And @nogc is just a band-aid fix. Might as well go back to C or C++ and leave the silly @nogc behind with all it's weird integration rules when working around managed memory. ~Peace
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 06:13:59 UTC, Dominikus Dittes Scherkl wrote: On Tuesday, 8 September 2015 at 17:07:50 UTC, NX wrote: And, can somebody show me a working example code of how to solve that friend class problem without some horrible hacktic way and agressive template/mixin stuff ? (I doubt it can solved via templates but anyway...) Why would you ever need "friend"? All functions have access to private members if they are declared within the same module, so there "friend" is not needed. And if you need access from outside the module, why do you declare them "private"? IMHO "friend" is a misconception, that is only there to compensate for the lack of modules in C++. Woah! I didn't know about private members are visible in it's module, but to me it feels much cleaner if it was achieved by something similar to what I suggested... Isn't it? never mind...
Re: A collection of DIPs
On Tuesday, 8 September 2015 at 17:07:50 UTC, NX wrote: And, can somebody show me a working example code of how to solve that friend class problem without some horrible hacktic way and agressive template/mixin stuff ? (I doubt it can solved via templates but anyway...) Why would you ever need "friend"? All functions have access to private members if they are declared within the same module, so there "friend" is not needed. And if you need access from outside the module, why do you declare them "private"? IMHO "friend" is a misconception, that is only there to compensate for the lack of modules in C++.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 06:48:45 UTC, NX wrote: Woah! I didn't know about private members are visible in it's module, but to me it feels much cleaner if it was achieved by something similar to what I suggested... Isn't it? never mind... Everything in the same module is friend to everything. That's D take on friendship.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 06:13:59 UTC, Dominikus Dittes Scherkl wrote: IMHO "friend" is a misconception, that is only there to compensate for the lack of modules in C++. It can be useful. Say you have a database engine module and an ORM module, you might want to give the ORM special privileges to certain parts of the database engine, but shield it from the rest of the program.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy! Most of these things I agree with. CamelCase this_case or that-case doesn't matter to me. It's a personal choice and preferences. Technically, you can write all of YOUR code in whatever case you like, in just about any language (though some languages do not support this-case). It would be nice to get rid of the __traits. It's not uncommon to see an underscore before something (I'm a C guy) but I was hoping D made better use of it. Putting two underscores in front of things does seem a bit "paranoid". But I digress, once you know it, you don't care anymore. You just type it the way it is. __traits it is, and will probably always be. As for the Garbage Collector! Please somebody save me! D's Garbage Collector is perhaps the WORSE garbage collector I have ever seen. It's slow, really slow, and stopping the entire world is painful, even in trivial user applications. A pause for even half a second or less on the UI makes the application looks "chunky" and broken. Real world time-sensitive issues you say??, D's GC is so bad, it cannot be used, ever. D has zero use in anything time sensitive. "But you can code with the GC when you don't need it" you say? Well, I can also code in C and C++ and not have to deal with it all, and take advantage of the STL in C++ or a plethora of open-libraries in C and still get what I need, without all the confusing mess around trying to use arrays or pointers without the stupid GC. Seriously, the fact that the GC has gone un-noticied for so long is a HUGE turn off for just about ANY would be C like developer to migrate to D, and even for the managed folks from Java and C# to migrate to D. I'm not against Garbage Collectors, but I AM against TERRIBLE garbage collectors, of which, D's garbage collector is. D could SERIOUSLY use a rewrite or three of the garbage collector. What get's me, is that D is sold as this beautiful evolution of C++ with this wonderful GC, but then once you buy in, you realize: 1. Nobody uses the GC because it sucks. 2. The GC sucks hardcore. 3. You can't use those nice GC features, because the GC sucks. Case closed. SOMEBODY SAVE ME! D's garbage collector is a FAIL, and that makes the rest of the language a FAIL until it get's fixed.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: Seriously, the fact that the GC has gone un-noticied for so long is a HUGE turn off for just about ANY would be C like It has not gone un-noticed, that's how @nogc came about. So people are aware that it is not suitable for interactive use. The key focus seems to be to rewrite Phobos so that you don't need a GC there at all. That approach I know nothing about... Unfortunately, how to do C++-style memory management is still not obvious to me either. And I am also not happy with the library-allocator approach since that will make it more difficult for the compiler to optimize memory allocations. I think memory handling should be part of the language, not a runtime or library issue. So I very much hope for a language spec that takes a more modern approach to address memory management so that we can get something that is better than C++ for interactive applications. D could SERIOUSLY use a rewrite or three of the garbage collector. You actually have to change the language semantics if you want a faster garbage collector. You can only scan so many cache-lines and unfortunately scanning is limited by total memory that can contain pointers and not the size of the GC heap itself... So either you need to group pointers on cache-lines and use advanced static analysis, limit GC memory access or take the toll of a concurrent GC (which would set back progress a couple of years).
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: The more you don't collect, the more time it takes time to collect; thus, you may want to configure GC to do it's job more often so it doesn't stop significantly, and also manually trigger collection where appropriate... Maybe that is true for the current collector since it does finalization, but in general it is the live objects that dominates collection time, not the dead object. Though you might get some other issues like memory fragmentation if you don't collect.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: D has zero use in anything time sensitive. You mean, for example, like dealing with data for a billion customers and responding in a few hundred microseconds? ;) https://www.sociomantic.com/technology/ Case closed. SOMEBODY SAVE ME! D's garbage collector is a FAIL, and that makes the rest of the language a FAIL until it get's fixed. Have you tried using EMSI's containers with Andrei's allocator ? They use them in production, I gather. http://www.economicmodeling.com/2015/08/20/nyt-uses-emsi-data-to-help-bust-the-myth-of-the-creative-class-apocalypse/ https://github.com/economicmodeling/containers
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: It's slow, really slow, and stopping the entire world is painful, even in trivial user applications. A pause for even half a second or less on the UI makes the application looks "chunky" and broken. If you're having that much serious problems then there is only one thing I can think of: Your computer is survived from 90s The more you don't collect, the more time it takes time to collect; thus, you may want to configure GC to do it's job more often so it doesn't stop significantly, and also manually trigger collection where appropriate... If I had the time and knowledge I would spend them to make D better, but you can't expect a teenager (tip: me) to help making DMD front-end better or to implement a precise GC... I guess?
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: If I had the time and knowledge I would spend them to make D better, but you can't expect a teenager (tip: me) to help making DMD front-end better or to implement a precise GC... I guess? You wouldn't know what people have done with D while being students. For example, std.regex.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: If I had the time and knowledge I would spend them to make D better, but you can't expect a teenager (tip: me) to help making DMD front-end better or to implement a precise GC... I guess? You can make a difference. Yes you probably don't have as much experience, but that's a great opportunity to learn. Many here would be willing to mentor you if you want. I can do it if you want to contribute to SDC. I'm sure other would on other projects they are familiar with. Generally, don't underestimate the impact you can have. Everybody think someone else will do it and is more qualified? Turns out that nobody is qualified before having done it for a while. So unless you get started, you'll never be qualified.
Re: A collection of DIPs
On Tuesday, 8 September 2015 at 03:09:20 UTC, Rikki Cattermole
wrote:
On 08/09/15 5:27 AM, Shammah Chancellor wrote:
void main() {
import std.stdio : writeln;
writeln("Hello world!");
}
-Shammah
It's not just an idiomatic way to code with local imports, it's
a compilation performance technique too.
I didn't read the DIP collection thoroughly (yup, D has a some
grotesqueries that would be nice to fix but I doubt will happen)
but local imports are one of the nice features of D (and Ada, and
OCaml) that I wish would be adopted in some other languages, like
Nim and Julia.
I never thought of them as a performance optimization though.
What's the reasoning? Are the observed differences significant?
From my POV restricting the scope of an import makes local
reasoning easier. I'd do it even if it were slightly less
performant!
Re: A collection of DIPs
On 08-Sep-2015 19:09, Brian Rogoff wrote:
On Tuesday, 8 September 2015 at 03:09:20 UTC, Rikki Cattermole wrote:
On 08/09/15 5:27 AM, Shammah Chancellor wrote:
void main() {
import std.stdio : writeln;
writeln("Hello world!");
}
-Shammah
It's not just an idiomatic way to code with local imports, it's a
compilation performance technique too.
I didn't read the DIP collection thoroughly (yup, D has a some
grotesqueries that would be nice to fix but I doubt will happen) but
local imports are one of the nice features of D (and Ada, and OCaml)
that I wish would be adopted in some other languages, like Nim and Julia.
I never thought of them as a performance optimization though. What's the
reasoning? Are the observed differences significant? From my POV
restricting the scope of an import makes local reasoning easier. I'd do
it even if it were slightly less performant!
Optimization comes when combined with templates - if template is not
instantiated then the locals imports are not even read from disk.
--
Dmitry Olshansky
Re: A collection of DIPs
Thanks all your thoughts and criticisms... - I'm fine if DMD ever starts to support multiple `alias this`, just to see if it would be easier for compiler to use opCast for implicit casts. - Those who think ^ would cause problems as it's already used for xor must be forgetting * is widely used multiplication operator and if that's fine, ^ is fine too IMHO... (Or am I missing something?) - When I first started learning D I expected templates to have exact same syntax and struggled about it not being the same. Also, if D use ! for both, then editors can easily understand a template function is being declared so there is a point in that. - About precise GC, you guys are the ones with ultimate knowledge so I don't want to go that much deep as I still a lot to learn (because everytime I learn something, I feel even more uninformed) And, can somebody show me a working example code of how to solve that friend class problem without some horrible hacktic way and agressive template/mixin stuff ? (I doubt it can solved via templates but anyway...)
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:52:21 UTC, Ola Fosheim Grøstad wrote: On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... Thanks for taking the time to write up your ideas. There has been much discussion on the GC in the past and I agree that a GC-tracking mechanism that can enable precise scanning is needed, but to get that level of speed you need some of the mechanisms in Rust. precise GC scanning could be enabled easily if the allocation calls were templates instead of raw C function. RTInfo is just a hack(IMO,) and pretty much ignoring one of the areas D excels in.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:52:21 UTC, Ola Fosheim Grøstad wrote: 1. You need to make sure that pointers to the interior of a GC object are not live when the last pointer to the start of the GC objects disappears. 2. You need to annotate C functions that take pointers with a guarantee that they don't hold on to references through that pointer. Or simply ban C functions from taking GC memory. 3. You need give up on destructors for GC objects too, and not allow them to own heap allocated objects. A reasonable restriction IMHO.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy! OK, here are a few comments on what i agree with or not. The other point simply don't interest me. ## Managed, unmanaged, something between? - pointers You can already create, allocate new class, struct and union instances that are not known by the GC. This is not well known because I've explained this several time on several boards to several people. So this proposal is simply consequence of a lack of knowledge. But, even if... using the '^' symbol, would be bad since it's already used to xor. ## Why need alias this while we have opCast? an "alias this" expression doesn't require to cast. Maybe you don't really see "alias this" as it is widely used: - custom type. - composition. So your proposal to use cast is pointless. ## InExpression is meaningless No it doesn't. :) ## ?? operator Yes, the 'Null coalescing operator' would be great. ## Templates should use exclamation! No, you can clearly differentiate declaration from instantiation thanks to the current syntax. ## friend classes You can put the classes in different modules and then 'private' and 'protected' are sufficient to get something like friend classes.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Destroy! Yea ill admit, i came from C# and i hate underscores. I prefer PascalCase above anything.
Re: A collection of DIPs
On Monday, 7 September 2015 at 15:34:21 UTC, BBasile wrote: You can already create, allocate new class, struct and union instances that are not known by the GC. This is not well known because I've explained this several time on several boards to several people. So this proposal is simply consequence of a lack of knowledge. You have to scan all memory that MAY contain a pointer to a reference chain that contains a pointer to GC heap. That's a lot of cache lines to scan over on today's computers that soon have terrabytes of memory.
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... Thanks for taking the time to write up your ideas. There has been much discussion on the GC in the past and I agree that a GC-tracking mechanism that can enable precise scanning is needed, but to get that level of speed you need some of the mechanisms in Rust. 1. You need to make sure that pointers to the interior of a GC object are not live when the last pointer to the start of the GC objects disappears. 2. You need to annotate C functions that take pointers with a guarantee that they don't hold on to references through that pointer. Or simply ban C functions from taking GC memory. What do you think?
A collection of DIPs
https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy!
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:
https://github.com/NightmareX1337/DX
Don't kill me, I'm just trying to help...
You can report issues and create pull requests :)
Destroy!
Hi NX,
Thanks for the document. A lot of what you say about UDA and
compile time reflection is absolutely true. We should fix it so
it isn't so darn convoluted.
w/ regards to __traits() those are call outs to the compiler and
generally should not be used directly. Thus std.traits, and why
they're prefixed with __. Unfortunately, the current state of
compile time reflection requires that you must use __traits
directly (at least, I've had to)
However, I can't agree with you about alias this, UFCS, or global
functions in phobos. The "idiomatic" way to code in D is use
local named imports. e.g.:
void main() {
import std.stdio : writeln;
writeln("Hello world!");
}
-Shammah
Re: A collection of DIPs
On 08/09/15 5:27 AM, Shammah Chancellor wrote:
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:
https://github.com/NightmareX1337/DX
Don't kill me, I'm just trying to help...
You can report issues and create pull requests :)
Destroy!
Hi NX,
Thanks for the document. A lot of what you say about UDA and compile
time reflection is absolutely true. We should fix it so it isn't so
darn convoluted.
w/ regards to __traits() those are call outs to the compiler and
generally should not be used directly. Thus std.traits, and why they're
prefixed with __. Unfortunately, the current state of compile time
reflection requires that you must use __traits directly (at least, I've
had to)
However, I can't agree with you about alias this, UFCS, or global
functions in phobos. The "idiomatic" way to code in D is use local
named imports. e.g.:
void main() {
import std.stdio : writeln;
writeln("Hello world!");
}
-Shammah
It's not just an idiomatic way to code with local imports, it's a
compilation performance technique too.
Re: A collection of DIPs
On 09/07/2015 08:55 PM, Enamex wrote: - Templates are obvious enough as they are IMHO. It's also obvious that declaration syntax mimicking use syntax would be superior.
Re: A collection of DIPs
> void main()
> {
> std.stdio.writeln("Hello world!"); // Error: undefined identifier 'std'
> }
struct Mod(string B="") {
template opDispatch(string M) {
static if (__traits(compiles, { mixin(`import `~B~"."~M~`;`); }))
mixin(`import opDispatch = `~B~"."~M~`;`);
else
alias opDispatch = Mod!((B!=""?B~".":"")~M);
}
}
alias mod = Mod!"";
alias std = mod.std;
// Could also place above declarations in "object.d".
void main() {
std.stdio.writeln("Hello world!");
mod.core.stdc.stdio.printf("%d\n", 42);
}
SCNR
artur
Re: A collection of DIPs
On Monday, 7 September 2015 at 16:10:31 UTC, Israel wrote: On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Destroy! Yea ill admit, i came from C# and i hate underscores. I prefer PascalCase above anything. 3 of the keys in my keychain are of the same brand, so they are shaped pretty much the same. The pin arrangement is different, of course, but they all have similar blades of the same height and width, and plastic-cased bows of the same rectangular shape. The orange key opens the front door. The yellow key opens the back door. The blue key opens the old bicycle storage room. I prefer the looks of the blue key. The shape is the same, but the color does make a difference - the orange and yellow ones look kinda toyish - the colors "scream" too hard. The blue one looks professional - as much as a key can look professional. Still, I wouldn't want them all to be blue Because then I wouldn't be able to tell the freaking difference! Maybe you think PascalCase is the best case. Maybe you are right, and there is an objectively "best" case, which is better than all the rest. It doesn't matter - the problem is not which single case you choose to rule them all, but that you insist on choosing one and making the convention to use only it for everything you define. At the very least, the convention should specify two cases - for types and for variables(=fields/arguments/scoped variables) - because you want to be able to name variables after their types. This might be considered a bad practice for the built-in types, but with user defined types you can usually get the type specific enough and the scope small enough for this to be the natural choice. The C# standard library is filled with member fields named after their types, and since both type and field use PascalCase, they had to use separate namespaces for types and variables. Now, for a language that has context sensitive keywords having context-sensitive identifier namespaces is not that weird - but I really don't want to see this misfeature in D...
Re: A collection of DIPs
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote: https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy! - Your point against undisciplined UFCS: Completely agree. I'm writing a 'DIP' that I'm probably never gonna submit to add "extension interfaces" (my syntax ATM is leaning towards "alias class/interface") that add callable-with-method-syntax free functions in a way that they're treated as native parts of the supporting type (one case: when passing the type name into a foreign template they're picked up as if they were methods instead of being out-of-scope). In a (very big) way, they're stolen whole-sale and are being adopted to fit from Rust's traits. - Null-coalescing operator: No. Pattern matching and a `std.typecons.Option(T)` would do better IMHO and are more general. - I've stayed away from UDAs but your points make me finally want to stay away a bit more. (except for a small side project but, well, necessities) - Managed~unManaged pointers: needlessly complicated. Just provide a non-GC 'new'. What wouldn't that solve as well as your `type*` vs `type^` pointers? (btw, `^` wouldn't conflict with the xor-operator as I understand it. `!` is already used both as a unary prefix and binary infix operator). - Not sure about `alias this`/`opCast`. I just use `opDispatch` whenever I need something more complicated than alias this (not much at all). - I VERY strongly believe in the inherent superiority of kebab-case compared to CamelCase and snake_case. KEBAB-CASE FOR PRESIDENT! - I hated D's module system at first. I still hate that I have to create separate files just to have a small internal namespace-separation. But I like being able to just go find something in a file in a project based on its compile-time path (granted, good design should enforce this but...). I dunno; on a fence about it. - `__traits(callerName) & __traits(callerChain) & __traits(callerPath)`: I want a `__traits(instanceContext, symbol)` that returns an alias allowing me to access all compile-time info on surrounding symbols to the passed one (which are local to the /instance/ so include imported names and local types and such). That would solve SO MANY THINGS with template adventures. Not sure on what it'd make worse, though. - Partial lock for arrays: Sounds complicated for D's current analysis abilities. But sounds cool. - pragma(inline): ABSOLUTELY. The idea that `pragma(inline)` verbatim tells the compiler precisely nothing hurts my OCD so much. - Old attributes got a space in the keyword list. There were proposals to shift them all to `@` syntax but it stalled early on. - Runtime reflection: Hmmm... Runtime UDA's sound suspiciously like a type-state system. Complicated, interesting. - Templates are obvious enough as they are IMHO. - Friend classes: Um, maybe make a separate MyTypeImpl struct/class that takes a MyType instance and initializes itself with a pointer and through it you can access all the private stuff you want? (MyTypeImpl would be in the same module as MyType, of course.) Good stuff ;)
