www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A collection of DIPs

reply "nx" <nightmarex1337 hotmail.com> writes:
https://github.com/NightmareX1337/DX

Don't kill me, I'm just trying to help...

You can report issues and create pull requests :)


 Destroy!
Sep 07 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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?
Sep 07 2015
next sibling parent "rsw0x" <anonymous anonymous.com> writes:
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.
Sep 07 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 07 2015
prev sibling next sibling parent reply "BBasile" <bb.temp gmx.com> writes:
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.




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.




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.




No it doesn't. :)




Yes, the 'Null coalescing operator' would be great.




No, you can clearly differentiate declaration from instantiation 
thanks to the current syntax.




You can put the classes in different modules and then 'private' 
and 'protected' are sufficient to get something like friend 
classes.
Sep 07 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 07 2015
prev sibling next sibling parent reply "Israel" <robindahoods gmail.com> writes:
On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:

 https://github.com/NightmareX1337/DX


 Destroy!





PascalCase above anything.
Sep 07 2015
parent "Idan Arye" <GenericNPC gmail.com> writes:
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!





 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.


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...
Sep 07 2015
prev sibling next sibling parent reply "Shammah Chancellor" <S S.com> writes:
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
Sep 07 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Sep 07 2015
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
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!
Sep 08 2015
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Sep 08 2015
prev sibling next sibling parent reply "Enamex" <enamex+d outlook.com> writes:
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 ;)
Sep 07 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Sep 07 2015
prev sibling next sibling parent Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
 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
Sep 07 2015
prev sibling next sibling parent reply "NX" <no-reply mail.com> writes:
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...)
Sep 08 2015
parent reply "Dominikus Dittes Scherkl" writes:
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++.
Sep 08 2015
next sibling parent reply "NX" <NightmareX1337 hotmail.com> writes:
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...
Sep 08 2015
parent "ponce" <contact gam3sfrommars.fr> writes:
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.
Sep 09 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 09 2015
parent reply "ZombineDev" <valid_email he.re> writes:
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.
Sep 12 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 12 2015
prev sibling parent reply "Brandon Ragland" <brandon callmemaybe.com> writes:
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.

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.
Sep 09 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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).
Sep 09 2015
prev sibling next sibling parent reply "NX" <nightmarex1337 hotmail.com> writes:
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?
Sep 09 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 09 2015
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
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.
Sep 09 2015
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Sep 09 2015
parent "NX" <nightmarex1337 hotmail.com> writes:
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.
Sep 11 2015
prev sibling next sibling parent "Brandon Ragland" <brandon callmemaybe.com> writes:
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 ;)
Sep 10 2015
prev sibling parent reply "Brandon Ragland" <brandon callmemaybe.com> writes:
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.


"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.


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.


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
Sep 10 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 11 2015
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
Sep 11 2015
parent reply "NX" <nightmarex1337 hotmail.com> writes:
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...
Sep 11 2015
next sibling parent "Edmund Smith" <edmund.pd.smith gmail.com> writes:
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`.
Sep 12 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Sep 12 2015
parent "NX" <nightmarex1337 hotmail.com> writes:
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 :'(
Sep 12 2015
prev sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
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
Sep 09 2015
next sibling parent "Brandon Ragland" <brandon callmemaybe.com> writes:
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 ;)
Sep 10 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 11 2015