Symbols missing, unmangle!
It would be nice if, when symbols are missing, they are unmangled! Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go() I know some like to read nonsense for fun, but I don't. Sure, I could learn, but it is a useless skill only good for interpreting link errors, writing compilers, and being the life of the party, none of which I want to do for a living.
Re: Fix D's segfaults!
On Sunday, 20 August 2017 at 18:35:07 UTC, Daniel Kozak wrote: This is not segfault. This is an uncatched exception. So it is your error. You does not do proper error handling. But still IIRC you should be able to see place where things go wrong Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones via Digitalmars-d" : D has a major issue with segfaults! It always reports the fault in the lowest function that it occurs! This is completely useless! std.file.FileException@std\file.d(755): Attempting to rename file X.lib to Y.lib: The system cannot find the file specified. 0x0041015E 0x00402C69 0x004025A3 0x00413ECF 0x00413E93 0x00413D94 0x0040DAD7 0x76D78744 in BaseThreadInitThunk 0x76FD582D in RtlGetAppContainerNamedObjectPath 0x76FD57FD in RtlGetAppContainerNamedObjectPath This tells me nothing about where the error occurred in *my* program! Dmd needs to be modified so that errors try to show from the source code. This should be obvious the reasons, if it is not possible, make it possible! There are no excuses why dmd should make me go on an easter egg hunt when a seg fault occurs. Um, That was just an example, the same type of output occurs with segfaults or any error/crash that D outputs stuff trying to be "helpful". Anyways, your missing the point. You expect me to write try/catches in every level of my program to create the granularity one needs to simply get the location the error occured in? Where is that exactly? How hard is it for dmd to know if std.file.FileException@std\file.d occurs in the code I created or somewhere else? It should be able to say "Hey, that is part of a standard library or other non-user component, let me try to walk back a little and see if I can find a location in the user code that led to this problem". This should be quite easy with a stacktrace, simply walk back until the location is in user code. So, regardless of anything, D telling me stuff like "Hey, your error occurred in phobos" doesn't tell me shit except the error occurred in phobos. I'm still looking for easter eggs, and I don't like easter(which is why I don't capitalize it).
Fix D's segfaults!
D has a major issue with segfaults! It always reports the fault in the lowest function that it occurs! This is completely useless! std.file.FileException@std\file.d(755): Attempting to rename file X.lib to Y.lib: The system cannot find the file specified. 0x0041015E 0x00402C69 0x004025A3 0x00413ECF 0x00413E93 0x00413D94 0x0040DAD7 0x76D78744 in BaseThreadInitThunk 0x76FD582D in RtlGetAppContainerNamedObjectPath 0x76FD57FD in RtlGetAppContainerNamedObjectPath This tells me nothing about where the error occurred in *my* program! Dmd needs to be modified so that errors try to show from the source code. This should be obvious the reasons, if it is not possible, make it possible! There are no excuses why dmd should make me go on an easter egg hunt when a seg fault occurs.
Re: Named multi-imports
On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
On 17.08.2017 23:03, aberba wrote:
On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
This looks really clean for code modularity.
import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;
The following code compiles and the imports are less
confusing.
import io = std.stdio : writeln, write;
import std.stdio : writefln;
void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}
Its more like this:
import oo = {std.stdio : {writeln, write}, std.algorithm:
{filter, map}, …};
oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);
private struct oo{
import std.stdio: writeln, write;
import std.algorithm: filter, map;
// …
}
void main(){
oo.write("result: ");
oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}
Wow, that might solve the problem! A little more verbose but it
does combine everything.
Any downsides?
Thanks.
Re: Named multi-imports
On Thursday, 17 August 2017 at 21:03:33 UTC, aberba wrote:
On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
This looks really clean for code modularity.
import io = std.stdio : {writeln, write}, ...
What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;
The following code compiles and the imports are less confusing.
import io = std.stdio : writeln, write;
import std.stdio : writefln;
void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}
Its more like this:
import oo = {std.stdio : {writeln, write}, std.algorithm:
{filter, map}, …};
oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);
Someone gets it! ;)
Re: New Features [was Named multi-imports]
On Wednesday, 16 August 2017 at 19:05:54 UTC, Jesse Phillips
wrote:
On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole
wrote:
But then that only helps with one specific instance. D is full
of language features, I do not see why everyone is so against
them. Without them, D would be empty, nothing, and no one
would use it. Adding language features should be see as
something good, cause without them, we wouldn't get anywhere.
Its an important challenge of software development, and a
number of articles out there about it.
https://www.google.com/search?q=the+cost+of+features&ie=utf-8&oe=utf-8
At first glance I wasn't finding anything which uniquely
tackles compilers and languages.
Backwards compatibility isn't just for programming languages
but can be more important.
Yes, but you are choosing a side, like most people. What about
the cost of not advancing? How many man hours are wasted because
someone won't implement feature because they "think" it will
cause problems or because they are too lazy or won't get enough
$$$ to do it?
Cost is not a one way street. When you don't do something it is
doing something. The whole problem with backwards compatibility
is that it is based on ignorance. When computers were first
hitting the street, people were doing what I am suggesting, as
that's all they could do. They screwed up a lot of things and
wasted a lot of time. But then 50 years later people use that as
an example, out of ignorance, to suggest that the same mistakes
will occur. They completely neglect the fact that we wouldn't
have what we have without all those mistakes either.
You can argue all you want, until you are purple in the face, but
you cannot deny what I have said as being the truth and your
arguments are baseless for the same reasons you claim mine is.
If one had to do things blindly and ignorantly, then yes, your
arguments are sound. But by using your brain, learning from past
mistakes, and moving forward to make progress, the issues can be
minimized and a balanced can be made.
You cannot apply some general statement to all specific instances
unless that statement is truly general. The backwards
compatibility plague is based on ignorance, e.g., "We don't know
what will be the ramifications of doing X so we will stick with
the status quo!". That is a purely ignorant statement, that is,
it is saying the same as "We are ignorant of what will happen if
we do X so we won't do anything".
When you apply that logic to something that one doesn't have to
be ignorant of, one is missing out on doing X and if X is good
and done and improves things then it is a same and real ignorance
wins again. No progress could ever be made if people didn't try
things. If people try things intelligent then they minimize the
problems that people like you are afraid of.
The best solution is a balance, wouldn't you agree?
When a "feature" offers no foreseeable issues(essentially nearly
mathematically proved to be correct), then it shouldn't be looked
as bad.
Again, as I pointed out, where would anything be if everyone had
the mentality you state?
Would D have mixins? No, because who knows what kinda problems
they could introduce in the language?
Would D have traits? No, because who knows what kinda problems
they could introduce in the language?
etc...
etc..
etc..
etc..
And these cause problems not just in programming but in real
life. No one wants to fix the problems, say, of America because
who knows what kinda problems that will introduce... and given
the track record of those that do the "problem fixing" we can be
pretty sure of the outcome. But the problem is then not the
problem fixing but those that fix the problems.
So, my point is that your argument is baseless and doesn't mean
anything in the real world. It is a guide, a parable about the
past and potentially the future, but people like you seem to like
to make it a law, like gravity, which it is not. The sad fact is
that it slows down real progress. One could make arguments about
and if progress is a good thing or not in and of itself, but that
is a different issue.
A good UI can help a user with complexity. So does consistency.
Adding a syntax for special meaning can be difficult to
remember. My personal example is properties in C#. The syntax
is straight forward and clean, but only recently have I been
able to remember how to write one: ReturnType Name { get {
return a; } set(value) { a = value; } }
As for your specific suggestion I think it would be nice at
times but the complexity you haven't specified is how do deal
with ambiguities if two modules provide the same symbol name.
D may have a number of features which C++ doesn't and visa
versa, the complexity of the language for C++ to have those
features means I work with D and not C++.
Then why are you so against adding features? That is what m
Re: Named multi-imports
On Wednesday, 16 August 2017 at 17:14:49 UTC, jmh530 wrote:
On Wednesday, 16 August 2017 at 14:42:51 UTC, Mike Wey wrote:
Wouldn't that just move the problem?
You then get an package that imports gtk.Window and a other
package that imports gdk.Window, and if you want to use both
you still need to add a renamed import or a static import in
your own file.
I don't know anything about gtkd, but I think he means
something like below.
.\gtkd\package.d
module gtkd;
public import gtk;
public import gdk;
...etc
.\gtkd\gtk\package.d
module gtk;
public import gtk.Window;
...etc
.\gtkd\gdk\package.d
module gdk;
public import gdk.Window;
...etc
So you should then be able to do something like
import gtkd : functionThatDoesntOverlap;
import gtk = gtkd.gtk : functionThatDoesOverlap;
import gdk = gtkd.gdk : functionThatDoesOverlap;
A longer-term solution is for something like
import gtkd;
to only pull in the functions/structs/classes/etc that are
actually used.
Not really, I'm not doing selective imports.
I want to be able to use an import symbol that contains a whole
crapload of imports. Which, the only way now is to create a
separate file and public import all those imports one wants, then
use that file and name it.
test.d
import _gtk = crapload;
import _gdk = crapload2;
crapload.d
public import gtk.TreeView;
public import gtk.Window;
crapload2.d
public import gdk.Window
But this requires creating files for every one group one wants.
It would be much nicer and easier, and it is easy if D added the
language feature, to do
import _gtk = {gtk.TreeView, gtk.Window, ... }
import _gdk = {gdk.Window, ... }
The semantics are the same, it is just a rewrite rule
basically... but all it really solves is not requiring extra
files, which means keeping track of more junk.
It's not necessarily all that useful if one uses such imports all
the time since it would bloat the files, But we could then add
some wildcards:
import _gtk = gtk.*;
import _gdk = gdk.*;
which would be functionally the same but far less verbose.
But as it stands now, there is only one way to do that and that
way is the most verbose and hardest to maintain... that really
isn't acceptable when it is such an easy problem to fix and
doesn't have any downside in implementing it.
Stefan Koch: New CTFE fix
Hi Stefan,
I have a suggestion/request for you for newCTFE:
string do()
{
string x;
x = "adsf";
pragma(msg, x);
return x;
}
fails because the compiler believes that x is not known at
compile time. It obviously is when do is ran as a ctfe. This
makes some types of programming difficult to debug because we
have to duplicate any instance of "do" and cannot output
intermediate values.
But, how can we make this actually work?
One way may be to treat all strings as enums internally and allow
normal string operations on them, effectively creating a
string_enum type.
In fact, maybe a new type would be the easiest way. string_enum
is a string at runtime but an enum with string operations at
compile time. (for memory efficiency they could be more like
string builders)
Another possible way is for the compiler to emit the pragma(msg,
x) as sort of writelns. i.e., ctfe_writeln, which if I recall,
hasn't been added yet.
Then we end up something like
string do()
{
string x;
x = "adsf";
ctfe_writeln(x);
return x;
}
which either could immediately display x if possible, or the
compiler could collect all output then display after the function
is called(issues are that errors might break the output).
I'm sure other solutions are possible. pragma(msg, ) could act
different depending on if it is use on a variable that is used
inside a ctfe vs a compile time "variable" used inside a ctfe.
Maybe your newCTFE already has the ability to do this or make it
easy? It would surely help me because I tend to use a lot of
mixins and generally cannot easily output the results for
debugging purposes(and since mixins already are nearly impossible
to debug like normal code, we need something useful to help us
out).
Import modules too verbose in some cases
Sometimes one doesn't want to import either the whole module nor specify a single function to import. It seems that basically D has all the info to import the function implicitly because it usually gives a nice error message tells us which module to import for the function. e.g., A.B.C() "Did you forget to import module A.B?" and so we have to do import A.B; A.B.C(); Sometimes we still need to specify the fully qualified name due to conflicts with other modules. Rather, how about a new feature were we do not have to import modules at all by specifying the fully qualified name? Since conflicts might occur, how bout using a symbol to express that? #A.B.C(); or @A.B.C(); or $A.B.C(); same as import A.B; A.B.C(); So, for one offs we don't have to write the import statement.
Re: GC operates in LIFO sequence?
On Wednesday, 9 August 2017 at 17:38:15 UTC, Swoorup Joshi wrote: On Wednesday, 9 August 2017 at 15:47:17 UTC, Guillaume Piolat wrote: On Wednesday, 9 August 2017 at 13:46:29 UTC, MGW wrote: Memory allocation and deallocation when an application is being completed in GC operates in FIFO sequence. Is there a possibility to shift GC memory deallocation to LIFO mode? It`s connected with the fact that GUI library (Qt) creates QApplication first, but GC destroys this object first when an application is being completed. This leads to the application failure. If the sequence of memory deallocation on LIFO is shifted, it will essentially simplify the cooperation with C++ libraries. https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors Is garbage collection even useful besides managing memory? Of course! Once a week it is useful! Else things start piling up and getting really smelly! Not very healthy!
Re: ModuleInfo Error
On Wednesday, 9 August 2017 at 22:00:56 UTC, Adam D. Ruppe wrote: On Wednesday, 9 August 2017 at 21:29:07 UTC, Johnson Jones wrote: I routinely get this error when I forget to add a module that I import to the project. You learn it pretty quickly though, don't you? no ;/ I have a memory like a rock. Which is either infinite or zero ;/ I tend to do a lot of things and after months of not seeing something I tend to flush my cache. Specially if I don't program in D for a while. It's one thing when you do something every day but when you do things in squirts, you tend to memorize what you need to know for that purpose then soon forget when you no longer need it. I guess this is due to the fact that the module does not have a library backing and the __ModuleInfo function isn't generated for it so it doesn't exist anywhere? (Just guessing) Yeah, basically. __ModuleInfo isn't a function, rather it is a block of static data telling the runtime where its static ctors, dtors, unittests, etc. are, but same idea. When you compile a .d file, the module info is automatically generated and put in the file with the functions you write. When you import a module, the compiler emits a reference to that moduleinfo so it can run its static ctors, etc., if present in your program. Importing a module without linking in its library or object file causes the error you see. Surely we could get a better error message for this or dmd could somehow try and automatically remedy the situation? So it technically isn't actually dmd generating that error... it happens at the link step, after dmd is done. Though dmd could parse the linker output and replace it with different text... but that is a pretty big pain and like I hinted above, this is the kind of thing you might be slightly baffled by the first time, but quickly learn what it means so the ongoing cost is pretty small. Replacing the text from the linker isn't just a one time implementation either: it'd have to keep up with changes from other linkers or version updates, and would likely break any special output (such as colors) that it tries to do. However... If so, why not keep track of all the modules that have bee used and if this error occurs, compile the module or do whatever needs to be done so the error is not necessary? ...that's what rdmd does. I think it is distributed with the compiler. dmd itself doesn't do that though since a valid use case (and fairly common with dmd's corporate users) is to compile and link separately, like people do with C++, to improve working with their complex build systems (speed, external assets, proprietary libraries, etc. don't work as well with my preferred "dmd *.d" strategy so they make it fancy af), so automatically compiling everything would actually be a step backward for those people. But you might want to try using rdmd. You just pass it the function with main and it figures out the rest by walking the import path, then calls dmd to actually compile. New users to D will be thrown by this error. It is meaningless as far as being helpful and there is virtually no online help for it... It is a FAQ... though cannot easily be found. Maybe you (or someone else) should ask on SO and put an answer up there so we can start linking to that? Well, I use Visual D and not sure if it can use rdmd(I'm sure it can be hacked) . Is there any benefits or downsides to doing this? I guess it's not a huge deal at the end of the day... but stuff like this just shouldn't be an issue. Are we going to be dealing with such things 50 years down the road? (well, not us, but the next generation?) I find most of the problems that we have(not just as programmers, but as human beings) tend to be because people cannot cut ties with the past and learn from their mistakes. Do we even need to separate the linker and compiler? Shouldn't they be able to communicate with each other internally to get the most information they can to make our lives easier? A simple switch could be used to separate linking and compiling. I feel that "modern" programming is still trapped in the past and we all ultimately suffer from it. Most people just don't realize how much better it could be. How many people have quit using D because of all the issues it has or simply because it doesn't have the momentum to carry them through life? I've seen a couple recently simply cut ties. They wouldn't have to do this if they could make a living using D, which means that D is has failed them, which is sad ;/ I don't think the powers at be really comprehend those things as they have don't have to worry nor experience those things to understand... hence, there is no motivation to get D on the right footing so it is not such a problem. An unfortunate set of circumstances. Anyways, I'll just try to remember, ranting about that stuff makes it stick in my mind better I guess, and at least a forum search
ModuleInfo Error
I routinely get this error when I forget to add a module that I import to the project. It throughs me for a loop because the error doesn't really make sense for what is actually wrong(or does it?): Error 42: Symbol Undefined _D9DLLImport12__ModuleInfoZ (DLLImport.__ModuleInfo) Adding DLLImport.d to the project solves the problem. I'm using Visual D so I guess adding the file to the project adds it to the includes on the command line. I guess this is due to the fact that the module does not have a library backing and the __ModuleInfo function isn't generated for it so it doesn't exist anywhere? (Just guessing) Surely we could get a better error message for this or dmd could somehow try and automatically remedy the situation? What is __ModuleInfo? An automatically generated function for a module by dmd when a module is compiled? If so, why not keep track of all the modules that have bee used and if this error occurs, compile the module or do whatever needs to be done so the error is not necessary? New users to D will be thrown by this error. It is meaningless as far as being helpful and there is virtually no online help for it... and one doesn't get this for standard stuff like phobos modules, again, I guess because they have a library that has these functions in it. I'm pretty sure dmd could auto detect this issue and try to resolve it internally. I've gotten it several times in different projects in the past.
Re: Did dmd forget how to read?
On Sunday, 6 August 2017 at 00:22:45 UTC, Cym13 wrote: On Saturday, 5 August 2017 at 23:54:45 UTC, Johnson Jones wrote: main.d(157): Error: no property 'SetCursor' for type 'gdk.Window.Window', did you mean 'getCursor'? um... anyone see bug? It's there, I promise. "setCursor" exists, but "SetCursor" doesn't (or your "bug" depends on code that you wrote and didn't share). I believe as both "setCursor" and "getCursor" are one character away from "SetCursor" dmd took the first one in alphabetic order or something. No need to panic ;) No one is panicking, so you can stop panicking that you think they are panicking. The point is that setCursor is much closer to SetCursor than getCursor. It should prioritize case differences first. SETCURSOR should still match setcursor better than getcursor or getCURSOR or whatever. But I'll get you a ascii star for realizing the issue /\ < > \/
Did dmd forget how to read?
main.d(157): Error: no property 'SetCursor' for type 'gdk.Window.Window', did you mean 'getCursor'? um... anyone see bug? It's there, I promise.
Re: ASCII-ART mandelbrot running under newCTFE
On Friday, 4 August 2017 at 22:50:03 UTC, Stefan Koch wrote: Hey Guys, I just trans-compiled a brainfuck mandelbrot into ctfeable D. newCTFE is able to execute it correctly (although it takes 3.5 minutes to do so). The code is here https://gist.github.com/UplinkCoder/d4e4426e6adf9434e34529e8e1f8cb47 The gist it evaluates the function at runtime since the newCTFE version capable of running this, is not yet available as a preview release. If you want a laugh you can compile the code with ldc and -Oz flag set. LLVM will detect that the function is pure and will try to constant-fold it. I do not know how long this takes though since my patience is limited. Cheers, Stefan Any screenshots? I don't wanna have to install something I won't use but once or twice but would be interested in seeing what is going on since I used to be a fractal freak ;)
Re: Who maintains the D website?
On Friday, 4 August 2017 at 09:13:33 UTC, Mike Parker wrote: On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote: i see you didn't hold your horses... not sure if i should reply again to such an angry rant. i will stay calm and focused though. This guy has a history of insulting nearly everyone who responds to him, even those who help him, as he has just shown again in his last response to you. You can find more of his posts under the handles Mike B. Johnson and FoxyBrown. My advice to you is, if you'd like to help him, that's fine, but don't expect any sort of reasoned debate from him. Long posts in response to anything he says are a waste of your time. He just doesn't respond well to reason. Way to go Mr. Professional. You have a long way to go to grow up. You think your you can veil your attitude but it's clear you are not a professional. A real professional would simply ignore the situation... And if you note, I only have a problems with a few people here. Mainly you and a one or two others... people that think they can write the shittiest software and how it effects others is of no importance. Instead of giving 100%, it's ok to give 25% and reap the benefits while others suffer the consequences. That attitude is BS and as long as you have it I will offend the fuck out of you all I want. If you don't like it simply ignore me, ban me(if you can), or do whatever you want. Until you grow up and stop acting like you are god I won't. You wanna preach but you don't wanna be preached to. I can take your BS but you can't take mine. It's a two way street... and until you can captain retard get that I won't play nice. There are plenty of people on here I respect. I'll give the top two: Adam Ruppe and H S Teoh. I've not seen any unprofessional nor condescending behavior from these guys. They don't pretend to know it all and don't preach their BS to others. They help the best they can and that is all they do... altruistic people. The kinda of human behavior that the world needs, not the kind that is destroying humanity(Which, you might not be at the bottom of the barrel, but your attitude is the same type that politicians, lawyers, and others have). I'm sorry if you can't grow up and act like those guys... maybe you should take notes from them and see how they act. Maybe you will stop being such an ass when you don't realize it because you think your such an intelligent person, authority, or simply too much ego... whatever it is, I'll make a point of pissing you off every time I get until you stop behaving that way. Your actions have consequences. The code you write has consequences. The "help" you give has consequences. When you stop dictating to other people how you *think* things should be and realize that it is just your opinion then we will get a long much better. Until then, later asshole.
Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum
On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote: See - https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce But can a digital wallets/crypto currency ever be secure ? Nope... as long as humans continue to build house of cards on quicksand this sort of stuff will always happen. You do realize it's all fake nonsense? If the only sort of currency that existed was what you could immediately do with your own body, then it would be impossible to ever steal anything(except for slavery, which is essentially still fake). Basically this is how the story goes: Someone comes up with some scheme to gather resources from others. The scheme is complex and designed in such a way that only those that have created the scheme or invested enough time to understand the scheme benefit from all those that don't but were to stupid not to buy in to the scheme. Eventually those at the top win. It's called a pyramid scheme and it exists in all forms of currency, employment, governments, even in most relationships, etc. Only when all participants equally share complete responsibility can the scheme be fair... but that never happens, too much to gain when it becomes unbalanced... and the more unbalanced it becomes the more those that unbalance it get. I wouldn't doubt that most of these people who create these currencies are the ones that ultimately are behind these thefts. After all, they are the ones that know most about it and why else would they spend their time developing it? For the benefit of human kind? Yeah right! What a joke!
Re: Who maintains the D website?
On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote: i see you didn't hold your horses... not sure if i should reply again to such an angry rant. i will stay calm and focused though. How pathetic, you are not worth my time. Seeing how you equate accuracy with typos and insecurity shows just how ignorant you are. Go bait someone else. Sorry that your life is so pathetic... but I'm sure it's your own fault.
Re: Who maintains the D website?
On Friday, 4 August 2017 at 00:52:34 UTC, captaindet wrote: On 2017-08-04 12:13, Johnson Jones wrote: No, sorry. The lead team uses nttp which is old school forum technology. They won't move in to the present and instead insist everyone else stay in the past with them. It's sort of like those guys that drive 1970's camaro's because they think it makes them look cool. I'm sure it's a psychological condition but not much can be done about it. hold your horses! quite a number of users incl myself prefer nttp. nice as the forum web interface is, following a newsgroup with a newsgroup reader like eg the thunderbird built-in is way more comfortable, you should try it one day. eg: you don't have to sign in, can reply immediately, you can customize display/behaviour more thoroughly to your liking, and more. /det It's not! I've used nntp and it crap. You cannot edit your posts, simple as that! You can claim all you want that your method is better but it doesn't make it so. Just based on human nature and the fact that you are saying with an ancient archaic system suggests it's all based in fear of change. The sad part about this is that it forces everyone else to stay in the same broken system. How about this: Dlang.org keeps the old interface like nntp and adds a new one. Anyone that wants to continue to use the old one can and those that one to use the new one can. In a year we can see which one is the most popular and let everyone decide rather than a few old crusty goats. Of course, it won't happen because those in power know the outcome. You can see how nntp is dead. There are few nntp servers and most of the groups are dead and only those that used in in the past still use it. There is not a migration towards nntp but away, and that is fact... which suggests that it is not as good as its opposition. Hence, if I'm right, and I almost surely am(surely you are not going to argue that nntp is becoming more popular, are you?) then those that think that nntp is a great thing and better than the alternatives have psychological issues with change. You can make a forum that behaves similarly(no login), customizable, or whatever else you are saying that you like about nntp. In fact, someone could write a nntp like interface for the forum in D just so to please you guys. I personally have nothing against nntp... while it isn't great it does the job EXCEPT editing. I know people claim that editing posts causes problems but that is rarely the case and the benefits far out weight any negatives. The reasons not to move forward are the same reasons that plague humans in many other areas and it is all psychological/evolutionary reasons rather than based on logic and facts. Familiarity is a prime factor. Many humans, specially older ones, fear change because it is unfamiliar and unknown. Those factors are the same that are at play here and it is unfortunate because I imagine there would be a lot more younger users that have the motivation to help D gain traction that do not participate because they feel like it is a step backwards rather than forwards. One day all the old fogies will die and nntp will be gone.. and some young kid interested in D will start a modern D forum and maybe D will get back on track. Think of it this way: D claims to be this sort of futuristic compiler(it can do thinks "light years" ahead of most other compilers...) yet it uses communications methods that are 50 years old. That's a bit contradictory. It's like a young pretty woman who dresses like a skank and wears so much make up that it makes her look 20 years older than what she is. While she might think she looks good, the people that actually look at her think otherwise. This is sorta what happens with D. It's amazing in some ways but has so much baggage in so many areas that many people are not going to waste their time. The D community can be delusional all they want, but it just works against them instead of allowing D to really shine.
Re: Who maintains the D website?
On Thursday, 3 August 2017 at 23:28:36 UTC, 12345swordy wrote: On Thursday, 3 August 2017 at 00:18:38 UTC, Andrej Mitrovic wrote: Is there a single person who's the main maintainer of the D website..? If not, I have some ideas on how to improve it. Not just ideas, I'd like to give a host at improving it myself, really. Can we gain the ability to edit our own post? I typically make some grammar/spelling mistacks here and there and it would be nice for me to fix this. No, sorry. The lead team uses nttp which is old school forum technology. They won't move in to the present and instead insist everyone else stay in the past with them. It's sort of like those guys that drive 1970's camaro's because they think it makes them look cool. I'm sure it's a psychological condition but not much can be done about it.
