Re: version: multiple conditions
On 2015-06-16 22:59, Walter Bright wrote:
#define BEGIN {
#define END }
Freedom! Freedom! Freedom!
https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
And the current approach to operator overload is s much better,
preventing all abuse:
struct Int
{
int a;
int opBinary(string s)(Int rhs) if (s == "+")
{
return a - rhs.a;
}
}
--
/Jacob Carlborg
Re: PHP verses C#.NET verses D.
On 2015-06-16 01:53, Nick B wrote: Looking to the future, as volumes grow, they could: 1. Stay with PHP & C#.net, and bring on servers as volumes grow. 2. Migrate to C#.net in time 3. Migrate to D in time. Any comments or suggestions on the above? Anything would be better than PHP. You can't go wrong picking either D or C# over PHP. -- /Jacob Carlborg
Re: version: multiple conditions
On 2015-06-16 22:36, Jonathan M Davis wrote: Sounds like it's preventing an abuse of operator overloading to me... :) Sounds like it's preventing a perfectly good use case. Or do you prefer AST macros instead :) -- /Jacob Carlborg
Re: std.container: fork in the road
On 17/06/2015 6:08 p.m., Andrei Alexandrescu wrote: Took a fresh look at std.container from a Design by Introspection perspective, and my assessment is as follows: * The current design of std.container is adequate but requires rather verbose implementations because it predates UFCS. For example, containers that define "stableRemove" must also alias "remove" to it etc. It's quite tedious to define complete containers. * It is possible to make things a lot better by taking advantage of DbI and UFCS. This does break client code, but only really odd cases that use advanced introspection to inspect methods of containers. * Things could and should be taken further to manage memory better. However, that's liable to produce subtle code breakages. Consider e.g. "SList!T.clear()". Right now it's O(1) and only reassigns the root to point to no element, thus leaving all elements to be collected. Moreover, if there are ranges iterating the now cleared list, they'll just continue wandering in the desert as if nothing happened. What I think SList should do is first switch to a refcounted implementation. Then, clear() should call destroy() for payloads of all nodes, safely invalidate all ranges, and deallocate memory allocated for all nodes. Even if we implement the change to be memory-safe, there's still changes in semantics (e.g. the behavior of orphan ranges changes). And even if we change behavior that wasn't specified explicitly in the docs, it's still a change in behavior. The same goes for other functions that remove elements from containers. Oh, and one more thing I noticed: * The documentation is appallingly bad, making std.container worse than non-existent. We have a liability squared to deal with here. I've pretended to myself I hadn't implemented SList and it was nigh impossible to use it competently from documentation alone, let alone understand the deeper architectural underpinnings that apply to other containers. This is another manifestation of the systemic problem of our community that's been discussed here in the past - there are matters that greatly affect negatively the uptake of D, yet they stay unresolved for literally months and years in spite of being trivially simple. For a potential user who sees today "std.container" in the library offering list, the subsequent click will lead almost by necessity to a vote of non-confidence. Regarding compatibility, I see three possibilities: 1. Just keep the current spec and deal with it. Some containers are and will remain garbage collected because they started as such. Add new containers that are better alongside them. 2. Do break compatibility of containers, mainly by taking advantage of them being under-documented. In a way we wouldn't break much because not much has been specified. There are, however, parts where we'd need to change specification. 3. Leave std.container alone and move forward with std.experimental.collection. I am confident the language and its endorsed idioms have reached enough maturity to not make this addition into a regular event. Andrei 2 please. At least to me they feel just unfinished. They should also support std.allocator. This is a biggy. As well as reserving of elements. Things have changed as you said since it was originally written. We now have new requirements.
Re: Phobos addition formal review: std.experimental.allocator
On 2015-06-16 22:29, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/commit/319f3297418c515a6d2e52e6e52d0f3f5895f587 changes .it to .instance for all allocators. -- Andrei Awesome, thanks. -- /Jacob Carlborg
Re: osx shared libraries.
On 2015-06-17 01:19, bitwise wrote:
Heh... trying ;)
Here, there seems to be a function to put things in ctors/dtors, but it
looks like it was copy pasted from the Elf code:
https://github.com/D-Programming-Language/dmd/blob/c718790165c3124c61e510d8352b9cb9d8ae0198/src/backend/machobj.c#L1532
I've rewritten the first line as follows, but still working on what I
need to do to actually put the function in there.
IDXSEC seg = s->Sseg = MachObj::getsegment("__mod_init_func", "__DATA",
2, S_MOD_INIT_FUNC_POINTERS);
I think the S_COALESCED flag could be added to the above to allow a
definition in every obj file like Martin's approach, but I would rather
have an explicit DllMain and put the init code in that one obj file. It
seems more intuitive to me.
So if I get Obj::staticctor and Obj::staticdtor working on osx, that's
half the problem solved... I think.
Obj::staticctor does not seem to be used for setting up the runtime.
This is the code that generates the runtime initialization [1], I
believe, at least it calls "_d_dso_registry". There's a lot more code
there than I first hoped.
[1]
https://github.com/D-Programming-Language/dmd/blob/c718790165c3124c61e510d8352b9cb9d8ae0198/src/backend/elfobj.c#L3183
--
/Jacob Carlborg
std.container: fork in the road
Took a fresh look at std.container from a Design by Introspection perspective, and my assessment is as follows: * The current design of std.container is adequate but requires rather verbose implementations because it predates UFCS. For example, containers that define "stableRemove" must also alias "remove" to it etc. It's quite tedious to define complete containers. * It is possible to make things a lot better by taking advantage of DbI and UFCS. This does break client code, but only really odd cases that use advanced introspection to inspect methods of containers. * Things could and should be taken further to manage memory better. However, that's liable to produce subtle code breakages. Consider e.g. "SList!T.clear()". Right now it's O(1) and only reassigns the root to point to no element, thus leaving all elements to be collected. Moreover, if there are ranges iterating the now cleared list, they'll just continue wandering in the desert as if nothing happened. What I think SList should do is first switch to a refcounted implementation. Then, clear() should call destroy() for payloads of all nodes, safely invalidate all ranges, and deallocate memory allocated for all nodes. Even if we implement the change to be memory-safe, there's still changes in semantics (e.g. the behavior of orphan ranges changes). And even if we change behavior that wasn't specified explicitly in the docs, it's still a change in behavior. The same goes for other functions that remove elements from containers. Oh, and one more thing I noticed: * The documentation is appallingly bad, making std.container worse than non-existent. We have a liability squared to deal with here. I've pretended to myself I hadn't implemented SList and it was nigh impossible to use it competently from documentation alone, let alone understand the deeper architectural underpinnings that apply to other containers. This is another manifestation of the systemic problem of our community that's been discussed here in the past - there are matters that greatly affect negatively the uptake of D, yet they stay unresolved for literally months and years in spite of being trivially simple. For a potential user who sees today "std.container" in the library offering list, the subsequent click will lead almost by necessity to a vote of non-confidence. Regarding compatibility, I see three possibilities: 1. Just keep the current spec and deal with it. Some containers are and will remain garbage collected because they started as such. Add new containers that are better alongside them. 2. Do break compatibility of containers, mainly by taking advantage of them being under-documented. In a way we wouldn't break much because not much has been specified. There are, however, parts where we'd need to change specification. 3. Leave std.container alone and move forward with std.experimental.collection. I am confident the language and its endorsed idioms have reached enough maturity to not make this addition into a regular event. Andrei
Re: PHP verses C#.NET verses D.
On 17/06/2015 5:40 p.m., Nick B wrote: On Wednesday, 17 June 2015 at 04:51:44 UTC, Rikki Cattermole wrote: On 17/06/2015 6:41 a.m., Nick B wrote: On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole Oh please say Christchurch! sorry for the confusion. Its Wellington. Ahh right right.
Re: PHP verses C#.NET verses D.
On Wednesday, 17 June 2015 at 04:51:44 UTC, Rikki Cattermole wrote: On 17/06/2015 6:41 a.m., Nick B wrote: On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole Oh please say Christchurch! sorry for the confusion. Its Wellington.
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 20:57:03 UTC, Walter Bright wrote: Use of expression templates in C++ to implement DSLs is probably some of the most awful code ever conceived. Whereas string mixins allow us to do all kinds of crazy stuff with DSLs if you want to - but they're clearly confined in strings where you're not going to mistake them for normal D code. It's _very_ cool how Pegged is able to take a grammar in normal, PEG format, and generate a parser from it. But attempting anything like that with expression templates would have been horrible. - Jonathan M Davis
Re: PHP verses C#.NET verses D.
On 17/06/2015 6:41 a.m., Nick B wrote: On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole wrote: On 16/06/2015 11:53 a.m., Nick B wrote: Hi. There is a startup in New Zealand that I have some dealings with at present. Any comments or suggestions on the above? Hello follow Kiwi! Hello kiwi from the south Island. :) Oh please say Christchurch!
Re: PHP verses C#.NET verses D.
On Tuesday, 16 June 2015 at 08:47:40 UTC, John Colvin wrote: On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote: Hi. Any comments or suggestions on the above? Both C# and D sound like good fits there. It depends on whether it's the sort of team who like to innovate and explore new possibilities or whether they want a completely fleshed out, stable ecosystem. Is anyone else able to comment on the comparisions/differences between C#.Net & D ?? Any comments on cost ? Any comments on getting bugs fixed ?
Re: version: multiple conditions
On 6/16/2015 6:06 PM, Daniel Murphy wrote: "Walter Bright" wrote in message news:mlorvv$1nb6$1...@digitalmars.com... On 6/14/2015 9:53 AM, bitwise wrote: > What if I need AndroidOrWP8, and I > also need Win32OrWin64? This can quickly become a much larger pita. If you need those, the design is wrong. It is better to think about what the code is trying to do with Android or WP8, and label *that* a version. This works well until the code that needs to be versioned is split over many source files, and now each one needs to duplicate the version setting code. If this is resulting, you're doing it wrong. Abstract the concept into a template or function, and put that in a separate module. (Much like how Port:: works.)
Re: version: multiple conditions
On 6/16/2015 6:04 PM, Daniel Murphy wrote: Keeping this feature simple and limited just pushes the complexity into user code. I simply don't believe that. It does take some work to redesign and refactor to find a better way, but the result should not be more complicated.
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 22:31:38 UTC, Etienne Cimon wrote: Yeah, I'm going to make a personal branch and develop a GC thread-local, and ensure memory/vtbl is left intact during collection/finalization, it's a good experiment and I believe it will be a way to solve the issue in the near future. Of course, no support for moving shared objects in a foreign thread anymore.. like that was any useful in the first place :P My libraries run fine on a TLS GC so far: https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac Only error was with a signal handler trying to allocate on the GC. I think it'll be worth it for me to use this from now on. There's no locking and possibly no stop the world.
Re: Martin Nowak is officially MIA
On Wednesday, 17 June 2015 at 02:16:37 UTC, Andrei Alexandrescu wrote: Hello, Martin has not replied to any communication for more than two weeks now, and I'm starting to fear something might have happened to him. If anyone in Berlin could get in touch with him and let me/us know he's alright, I'd appreciate it. It's https://github.com/MartinNowak?tab=activity I see a message from 5 days ago here. I think he's fine but probably got tangled up in something else at the moment.
Martin Nowak is officially MIA
Hello, Martin has not replied to any communication for more than two weeks now, and I'm starting to fear something might have happened to him. If anyone in Berlin could get in touch with him and let me/us know he's alright, I'd appreciate it. It's okay if he's bothered about missing his flight to DConf or anything related, but the perspective of a more serious problem is worrisome. We are therefore looking for a new release czar. Two would be even better to avoid similar problems in the future. Please let everybody know if interested. Thanks, Andrei
Re: std.(experimental.)logger voting manager wanted
On 6/16/15 12:12 PM, Robert burner Schadek wrote: On Saturday, 13 June 2015 at 15:43:58 UTC, Andrei Alexandrescu wrote: I'd say we hold off on this until we finalize reference counting. Right now std.logger requires GC. -- Andrei for thread safety and performance we need to allocate strings. what happened to RCstring? RCString is on my list. Right now I'm having an unbelievably good time with std.container. -- Andrei
Re: version: multiple conditions
"Walter Bright" wrote in message news:mlorvv$1nb6$1...@digitalmars.com... On 6/14/2015 9:53 AM, bitwise wrote: > What if I need AndroidOrWP8, and I > also need Win32OrWin64? This can quickly become a much larger pita. If you need those, the design is wrong. It is better to think about what the code is trying to do with Android or WP8, and label *that* a version. This works well until the code that needs to be versioned is split over many source files, and now each one needs to duplicate the version setting code.
Re: version: multiple conditions
"Walter Bright" wrote in message news:mloslo$1o7v$1...@digitalmars.com... I have yet to see a single case of "needing" boolean versions that could not be refactored into something much more readable and maintainable that did not use such. Over time, I've gotten rid of most of that stuff from the dmd source code, and the result has been quite pleasing. The numerous remaining cases in dmd are why ddmd uses static if instead of version. It's almost always easier to just use the more powerful 'static if' than to refactor the code to use D's crippled 'version'. Keeping this feature simple and limited just pushes the complexity into user code.
Re: osx shared libraries.
On Tuesday, 16 June 2015 at 23:52:26 UTC, bitwise wrote: I would like to try LDC, so I'll probably give it a go next release. It looks like the runtime for LDC would need some work too though. In particular, it doesn't seem to support dynamic loading: https://github.com/ldc-developers/druntime/blob/ldc/src/rt/sections_ldc.d#L379 Well, this is the old LDC-specific implementation for all platforms that have not been converted to the new scheme yet. You'd probably want to base your implementation on sections_linux, which we use on Linux. The code that emits the global constructors/destructors is here: https://github.com/ldc-developers/ldc/blob/33befca6d72fe267ee8e4179ba670513993e2eb7/gen/module.cpp#L348-L546 - David
Re: version: multiple conditions
On Tue, 16 Jun 2015 16:59:36 -0400, Walter Bright
wrote:
On 6/16/2015 1:46 PM, rsw0x wrote:
You call it abuse, I call it developer freedom.
#define BEGIN {
#define END }
Freedom! Freedom! Freedom!
https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
I take it I should just skip my next suggestion ;)
Bit
Re: osx shared libraries.
On Tue, 16 Jun 2015 17:45:52 -0400, David Nadlinger wrote: I can help you with codegen questions if you want to try LDC. I actually tried to compile my library with LDC a week or two ago, and got ICEd. I would like to try LDC, so I'll probably give it a go next release. It looks like the runtime for LDC would need some work too though. In particular, it doesn't seem to support dynamic loading: https://github.com/ldc-developers/druntime/blob/ldc/src/rt/sections_ldc.d#L379 You'll have to drop down to the compiler level to influence the visibility in either case, though. Yeah... I'm still trying to figure out how dmd exports, and decides when to export, functions. In Martin's code, it looks like he's manually outputting assembly as bytecodes, but I was hoping for a simpler solution. Ideally, I would like to copy this approach: https://github.com/D-Programming-Language/dmd/blob/c718790165c3124c61e510d8352b9cb9d8ae0198/src/mars.c#L228 Then, add some special cases to put the generated function into the right section and ensure the symbols are not exported. Anyways, your Dconf presentation was helpful to explain a few things, so thanks for that =D Bit
Re: osx shared libraries.
On Tue, 16 Jun 2015 15:50:32 -0400, Jacob Carlborg wrote:
On 2015-06-16 16:56, bitwise wrote:
If anyone is willing to point me in the right direction here, it would
be much appreciated ;)
Looking at Martin's github, it doesn't appear that he's back in business
yet.
Why don't you just do what Martin did for Linux, or is that what you
would like to avoid? The code was a bit more than I first thought it
would be. You could try doing the same for OS X and see what happens :).
Just replace the segments and section names with the appropriate OS X
names and similar stuff.
Heh... trying ;)
Here, there seems to be a function to put things in ctors/dtors, but it
looks like it was copy pasted from the Elf code:
https://github.com/D-Programming-Language/dmd/blob/c718790165c3124c61e510d8352b9cb9d8ae0198/src/backend/machobj.c#L1532
I've rewritten the first line as follows, but still working on what I need
to do to actually put the function in there.
IDXSEC seg = s->Sseg = MachObj::getsegment("__mod_init_func", "__DATA", 2,
S_MOD_INIT_FUNC_POINTERS);
I think the S_COALESCED flag could be added to the above to allow a
definition in every obj file like Martin's approach, but I would rather
have an explicit DllMain and put the init code in that one obj file. It
seems more intuitive to me.
So if I get Obj::staticctor and Obj::staticdtor working on osx, that's
half the problem solved... I think.
Bit
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 22:21:28 UTC, Steven Schveighoffer wrote: If you want to manage memory from a GC'd object, you can use C malloc and C free. Or, you can write your own GC that solves this problem that Sun/Oracle couldn't :) In all seriousness, you could potentially have exceptions to this rule, but it would take a lot of cajoling of druntime and some funky @UDA magic. -Steve Yeah, I'm going to make a personal branch and develop a GC thread-local, and ensure memory/vtbl is left intact during collection/finalization, it's a good experiment and I believe it will be a way to solve the issue in the near future. Of course, no support for moving shared objects in a foreign thread anymore.. like that was any useful in the first place :P
Re: Workaround for typeid access violation
On 6/16/15 4:30 PM, Etienne wrote: On Tuesday, 16 June 2015 at 20:08:36 UTC, rsw0x wrote: You're attempting to use GC for a problem that they don't solve because you don't have other tools to fix it. When all you have is a hammer, everything looks like a nail. Well no, I have plenty of tools. I use a memory library that does a wide range of everything I need https://github.com/etcimon/memutils .. It's not like I'm reliant only on it, like it's my hammer and I only see nails.. Finalizers cannot access external GC memory. period. It's just not supported. http://dlang.org/class.html#destructors "This means that when the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references may no longer be valid. This means that destructors cannot reference sub objects." If you want to manage memory from a GC'd object, you can use C malloc and C free. Or, you can write your own GC that solves this problem that Sun/Oracle couldn't :) In all seriousness, you could potentially have exceptions to this rule, but it would take a lot of cajoling of druntime and some funky @UDA magic. -Steve
Re: osx shared libraries.
On Tuesday, 16 June 2015 at 14:56:35 UTC, bitwise wrote:
On Mon, 15 Jun 2015 23:56:14 -0400, bitwise
wrote:
It actually appears that __attribute__((visibility("hidden"))
is redundant and making it a constructor already hides it.
derp.. no it's not. Its the fact they were marked static in the
C code that made them hidden.
If anyone is willing to point me in the right direction here,
it would be much appreciated ;)
Looking at Martin's github, it doesn't appear that he's back in
business yet.
I can help you with codegen questions if you want to try LDC. The
implementation I did there for Linux was based on Martin's work
(but I contributed fixes to a couple of the shared problems and
made it work with --gc-sections).
You'll have to drop down to the compiler level to influence the
visibility in either case, though.
- David
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 21:10:50 UTC, rsw0x wrote:
On Tuesday, 16 June 2015 at 21:09:40 UTC, rsw0x wrote:
On Tuesday, 16 June 2015 at 20:59:35 UTC, Walter Bright wrote:
On 6/16/2015 1:46 PM, rsw0x wrote:
You call it abuse, I call it developer freedom.
#define BEGIN {
#define END }
Freedom! Freedom! Freedom!
https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
#define PROGRAM main() BEGIN
ah, now we're getting somewhere.
wow, that got mangled by my touchscreen :(
https://gist.github.com/jcromartie/238308
Re: static foreach considered
On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu wrote:
I'm trying to collect together motivating examples and to
figure out the semantics of the feature.
I was just playing around with something and I thought being able
to do a loop over an enum at compile time would be convenient.
The motivation is when you have a function that works a little
differently for arrays than for scalers, but it works the same
way for all sizes of arrays (i.e. 1d/2d/3d all the same).
template GenArrayMathFunction(string function_name, string
array_string)
{
const char[] GenArrayMathFunction =
"real" ~ array_string ~ " " ~ function_name ~"(real" ~
array_string ~ " x) {\n" ~
"\treal" ~ array_string ~" result = x.map!(a => " ~
function_name ~ "(a)).array;\n" ~
"\treturn result;\n" ~
"}";
}
private enum array_dimension
{
Dim1 = "[]",
Dim2 = "[][]",
Dim3 = "[][][]"
}
static foreach(i; array_dimension)
{
mixin(GenArrayMathFunction!(f, i));
}
Basically, the first part generates a string representing a
function that uses map to apply a function to some input. The
type of the input depends on a string representing the kind of
array. The enum represents a string for 1/2/3-dimensional arrays.
Finally, I would want to loop through the enums and use mixin to
create a function for each.
The foreach loop doesn't work right now. Right now, I've just
written out each of the three functions and put in
array_dimension.Dim1, etc.
Re: static foreach considered
On Tuesday, 16 June 2015 at 20:39:44 UTC, Daniel N wrote:
Or is there a better way to accomplish the above?
Daniel
Sorry for the noise, ofc there's a better way...
struct weird(T)
{
static if(T.sizeof<=8)
{
void proto_val(T val);
alias U = ParameterTypeTuple!proto_val;
}
else
{
void proto_ref(const ref T val);
alias U = ParameterTypeTuple!proto_ref;
}
void zzz(U x)
{
}
}
Daniel
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 21:09:40 UTC, rsw0x wrote:
On Tuesday, 16 June 2015 at 20:59:35 UTC, Walter Bright wrote:
On 6/16/2015 1:46 PM, rsw0x wrote:
You call it abuse, I call it developer freedom.
#define BEGIN {
#define END }
Freedom! Freedom! Freedom!
https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
#define PROGRAM main() BEGIN
ah, now we're getting somewhere.
wow, that got mangled by my touchscreen :(
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 20:59:35 UTC, Walter Bright wrote:
On 6/16/2015 1:46 PM, rsw0x wrote:
You call it abuse, I call it developer freedom.
#define BEGIN {
#define END }
Freedom! Freedom! Freedom!
https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
#define PROGRAM main() BEGIN
ah, now we're getting somewhere.
Re: version: multiple conditions
On 6/16/2015 1:46 PM, rsw0x wrote:
You call it abuse, I call it developer freedom.
#define BEGIN {
#define END }
Freedom! Freedom! Freedom!
https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
Re: version: multiple conditions
On 6/16/2015 1:36 PM, Jonathan M Davis wrote: On Tuesday, 16 June 2015 at 19:55:21 UTC, Jacob Carlborg wrote: On 2015-06-16 12:05, Walter Bright wrote: Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593 Sounds like it's preventing an abuse of operator overloading to me... :) Yup, it's doing its job! Use of expression templates in C++ to implement DSLs is probably some of the most awful code ever conceived.
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 20:36:20 UTC, Jonathan M Davis wrote: On Tuesday, 16 June 2015 at 19:55:21 UTC, Jacob Carlborg wrote: On 2015-06-16 12:05, Walter Bright wrote: Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593 Sounds like it's preventing an abuse of operator overloading to me... :) - Jonathan M Davis You call it abuse, I call it developer freedom.
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 20:30:50 UTC, Etienne wrote: On Tuesday, 16 June 2015 at 20:08:36 UTC, rsw0x wrote: You're attempting to use GC for a problem that they don't solve because you don't have other tools to fix it. When all you have is a hammer, everything looks like a nail. Well no, I have plenty of tools. I use a memory library that does a wide range of everything I need https://github.com/etcimon/memutils .. It's not like I'm reliant only on it, like it's my hammer and I only see nails.. It's simply easier to manage the lifetime of objects through the GC because sometimes I have them referred to as delegates at a lower level. I like having finalizers because those objects may hold thread-local containers. A GC is not for managing an object's lifetime. There are no guarantees from the GC. Isn't that what we'd want? To use the GC only when it's important and manual memory management at other times? What happens when you need the two and your manually allocated objects are tracked by a GC-allocated object? The correct answer would be for the GC object to be upgraded to an RCO because the resource's lifetime is now bound to the GC object. I think you're the one who's actually looking at everything like a nail wrt improving performance in benchmarks. No, I'm looking at correctness and not piling hack upon hack that will fall apart at the first sneeze to the GC codebase. Performance just happens to be a side effect of correctness.
Re: static foreach considered
On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu wrote:
I'm trying to collect together motivating examples and to
figure out the semantics of the feature.
Andrei
Could something like this fly?
struct weird
{
void xxx()(T val) if(T.sizeof <= 8);
void xxx()(const auto ref T val) if(T.sizeof > 8);
// would require something similar to getOverloads but for
templates...?
static foreach(decl; __traits(getTemplates, typeof(this),
"xxx"))
{
// impl xxx only once
}
}
Or is there a better way to accomplish the above?
Daniel
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 19:55:21 UTC, Jacob Carlborg wrote: On 2015-06-16 12:05, Walter Bright wrote: Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593 Sounds like it's preventing an abuse of operator overloading to me... :) - Jonathan M Davis
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 20:08:36 UTC, rsw0x wrote: You're attempting to use GC for a problem that they don't solve because you don't have other tools to fix it. When all you have is a hammer, everything looks like a nail. Well no, I have plenty of tools. I use a memory library that does a wide range of everything I need https://github.com/etcimon/memutils .. It's not like I'm reliant only on it, like it's my hammer and I only see nails.. It's simply easier to manage the lifetime of objects through the GC because sometimes I have them referred to as delegates at a lower level. I like having finalizers because those objects may hold thread-local containers. Isn't that what we'd want? To use the GC only when it's important and manual memory management at other times? What happens when you need the two and your manually allocated objects are tracked by a GC-allocated object? Well I'm experimenting a solution here, or am I wrong to do so? I know the behavior is undefined in the docs, but I didn't post this in D.learn did I? I think you're the one who's actually looking at everything like a nail wrt improving performance in benchmarks.
Re: Phobos addition formal review: std.experimental.allocator
On Saturday, 13 June 2015 at 19:08:26 UTC, Jacob Carlborg wrote: On 2015-06-12 13:06, Dicebot wrote: The legendary allocator package by Andrei Alexandrescu has arrived at your doorsteps and kindly asks to let it into Phobos http://wiki.dlang.org/Review/std.experimental.allocator Docs: http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html Code: https://github.com/andralex/phobos/tree/allocator/std/experimental/allocator I think "IAllocator", "theAllocator" and "it" are really bad names. I recommend renaming those symbols to: IAllocator -> Allocator theAllocator -> currentAllocator or tlsAllocator it -> allocator or instance. Even better if a static "opDispatch" could be used to forward all methods to the instance. https://github.com/D-Programming-Language/phobos/commit/319f3297418c515a6d2e52e6e52d0f3f5895f587 changes .it to .instance for all allocators. -- Andrei
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 16:28:54 UTC, Etienne wrote: On Tuesday, 16 June 2015 at 15:39:06 UTC, rsw0x wrote: destructors as they are shouldn't exist at all, they are incredibly bug prone. Bye. To be fair, everything is bug prone until you understand them. No, they are just bug prone. GC finalization is done in a single lock, none of the memory is re-used, so objects can have their own "destroyed" flags and destroy eachother fine if the typeinfo issue isn't there. Implementation-defined behavior. On the other hand, by keeping the GC destructors, we must agree that all the destructors are declared this way: shared @nogc nothrow ~this() Only then can we count it in as having predictable behavior. Still not predictable, as they can be ran in any thread, in any order, and be ran parallel. I can't really agree on removing finalizers, I'd really love to master GC destructors in D so that I can return plain class objects from my functions with data allocated elsewhere, like in any managed language out there. It's really the only way. Don't get me wrong, I allocate and free on a freelist or pool everywhere I can, but the GC has its advantages and I'd really like to put it to work (safely) to build more convenient APIs. You're attempting to use GC for a problem that they don't solve because you don't have other tools to fix it. When all you have is a hammer, everything looks like a nail.
Re: version: multiple conditions
On 2015-06-16 12:05, Walter Bright wrote: Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593 -- /Jacob Carlborg
Re: osx shared libraries.
On 2015-06-16 16:56, bitwise wrote: If anyone is willing to point me in the right direction here, it would be much appreciated ;) Looking at Martin's github, it doesn't appear that he's back in business yet. Why don't you just do what Martin did for Linux, or is that what you would like to avoid? The code was a bit more than I first thought it would be. You could try doing the same for OS X and see what happens :). Just replace the segments and section names with the appropriate OS X names and similar stuff. -- /Jacob Carlborg
Re: PHP verses C#.NET verses D.
On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote: Looking to the future, as volumes grow, they could: 1. Stay with PHP & C#.net, and bring on servers as volumes grow. 2. Migrate to C#.net in time 3. Migrate to D in time. Any comments or suggestions on the above? Don't mess up a working solution. Don't mess it up. Go with this logic: will it mess up the existing software? Choose the solution that will not mess it up. This being said, you start a new project with spare money or spare time. Migrations are 99.9% of the time not worth it.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Tuesday, 16 June 2015 at 16:34:59 UTC, Laeeth Isharc wrote: On Tuesday, 16 June 2015 at 08:54:01 UTC, Chris wrote: So the implication that use of the nonstandard form would lead to confusion is pure pedantry." Yes, indeed. Much of the difficulty with discussions of language in the modern world comes from not making a distinction between its denotative and connotative aspects. The former relates to what is actually being said, and the latter to all the other thoughts and impressions that are evoked by saying it in that way. Modern people emphasize excessively the denotative aspects, whereas connotations do matter since - as the neuroscience tells us - there are subtle priming effects and there are consequences from shifting the brain into different modes. That's perhaps also in part why people do care about syntax in computer languages, even though at one level anything precise might be felt to do the job. Back to your point, many non-Western cultures have different kinds of speech according to the social context. That's because wanting to do so is a human group thing, not a DWEM thing. Of course in the past years there was a relaxation of standards of formality due to concerns over it creating a noxious and unwarranted exclusivity. That may have been a good thing in some ways. But I think every human group will ultimately need to retain distinctions between different registers of speaking and writing... My point was not so much formal vs non-formal speech but the fact that a lot of these decisions are linguistically (not socially) arbitrary, often counter intuitive, and made by people who want to draw a line between their own (privileged) group and others they do not deem worthy of the same privileges. Again in the words of Pinker: "Perhaps most importantly, since prepscriptive rules are so psychologically unnatural that only those with access to the right schooling can abide by them, they serve as shibboleths, differentiating the elite from the rabble." I couldn't put it better myself. There's no linguistic reason why double negatives shouldn't be in the standard varieties of English. (Greek logic != linguistic logic)
Re: std.(experimental.)logger voting manager wanted
On Saturday, 13 June 2015 at 15:43:58 UTC, Andrei Alexandrescu wrote: I'd say we hold off on this until we finalize reference counting. Right now std.logger requires GC. -- Andrei for thread safety and performance we need to allocate strings. what happened to RCstring?
Re: PHP verses C#.NET verses D.
On Tuesday, 16 June 2015 at 06:29:46 UTC, Rikki Cattermole wrote: On 16/06/2015 11:53 a.m., Nick B wrote: Hi. There is a startup in New Zealand that I have some dealings with at present. Any comments or suggestions on the above? Hello follow Kiwi! Hello kiwi from the south Island. :)
Re: version: multiple conditions
On 6/16/2015 6:28 AM, David Nadlinger wrote: On Tuesday, 16 June 2015 at 09:55:34 UTC, Walter Bright wrote: On 6/13/2015 6:51 PM, Steven Schveighoffer wrote: Just use the static if trick. Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary. Are you referring to this? https://github.com/D-Programming-Language/druntime/commit/54ca71b154fd9476520a63e30a50980af8927a56 If yes, I would claim that this is hardly relevant to this discussion, but I couldn't find any other druntime commits where you changed static ifs. - David No, there was another one, but I don't remember the details.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Tuesday, 16 June 2015 at 08:54:01 UTC, Chris wrote: So the implication that use of the nonstandard form would lead to confusion is pure pedantry." Yes, indeed. Much of the difficulty with discussions of language in the modern world comes from not making a distinction between its denotative and connotative aspects. The former relates to what is actually being said, and the latter to all the other thoughts and impressions that are evoked by saying it in that way. Modern people emphasize excessively the denotative aspects, whereas connotations do matter since - as the neuroscience tells us - there are subtle priming effects and there are consequences from shifting the brain into different modes. That's perhaps also in part why people do care about syntax in computer languages, even though at one level anything precise might be felt to do the job. Back to your point, many non-Western cultures have different kinds of speech according to the social context. That's because wanting to do so is a human group thing, not a DWEM thing. Of course in the past years there was a relaxation of standards of formality due to concerns over it creating a noxious and unwarranted exclusivity. That may have been a good thing in some ways. But I think every human group will ultimately need to retain distinctions between different registers of speaking and writing...
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 15:39:06 UTC, rsw0x wrote: destructors as they are shouldn't exist at all, they are incredibly bug prone. Bye. To be fair, everything is bug prone until you understand them. GC finalization is done in a single lock, none of the memory is re-used, so objects can have their own "destroyed" flags and destroy eachother fine if the typeinfo issue isn't there. On the other hand, by keeping the GC destructors, we must agree that all the destructors are declared this way: shared @nogc nothrow ~this() Only then can we count it in as having predictable behavior. I can't really agree on removing finalizers, I'd really love to master GC destructors in D so that I can return plain class objects from my functions with data allocated elsewhere, like in any managed language out there. It's really the only way. Don't get me wrong, I allocate and free on a freelist or pool everywhere I can, but the GC has its advantages and I'd really like to put it to work (safely) to build more convenient APIs.
Re: DIP74 & GC Destructors
On Tuesday, 16 June 2015 at 15:48:18 UTC, rsw0x wrote: On Monday, 15 June 2015 at 16:20:56 UTC, Marc Schütz wrote: I hope we won't get builtin RC, but that's off-topic. I disagree, that's entirely on topic. I believe every modern implementation of Ada relies solely on RC(while having GC hooks.) Nobody really seems to have an issue with RC there. I personally believe that immediate RC and GC solve completely different issues of deterministic vs non-deterministic resource management. Trying to shoehorn them into the same thing gets you a broken, slow implementation(see: C++'s shared_ptr. It's dog slow and _way_ overused IMO.) Note that I'm all for supporting good RC, I'm just against adding special support for it _in the language_. Instead, the remaining obstacles for efficient and safe library-based RC should be solved, which from my POV mostly means implementing some version of the `scope` feature. In any case, there has been talk about introducing finalizers instead of destructors for GC managed objects. rt_attachDisposeEvent() already exists and is used by std.signal for weak references, but it's a hack, it needs to be formalized. These finalizers can then have much more restricted semantics than destructors, e.g. they must be callable on any thread, are generally un-@safe if they access members with indirections, and so on. I'm honestly curious of examples where finalizers are needed. Well, as I already mentioned, weak references, e.g. for a signal/slot mechanism, or for maintaining a cache that doesn't keep its contents alive. Apart from that, I don't see much use in them either. OTOH, weak references _are_ important, so there needs to be some mechanisms for implementing them. I guess finalizers are the easiest way to do it. The one exception I can think of is managing non-GC objects, as in C#. But that *still* seems like a bad idea because there's zero guarantee the destructor will ever run - i.e, a GC implementation that decides to just never call destructors is a valid implementation. Agreed. http://dlang.org/class.html#destructors "The garbage collector is not guaranteed to run the destructor for all unreferenced objects. " D has more than one issue here, from combining "finalizer" and "destructor" into the same term to destructors being incredibly bug-prone and almost useless as defined by the standard. I hope this gets looked at. Agreed, too.
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 14:00:55 UTC, Etienne wrote: There is a bug regarding unordered object collection in the GC. My finalizer accesses another GC-allocated object Well, theoretically you can replace GC, which will allow you do that. But that's hardly practical, the behavior you're asking for is unsound anyway.
Re: DIP74 & GC Destructors
On Monday, 15 June 2015 at 16:20:56 UTC, Marc Schütz wrote: I hope we won't get builtin RC, but that's off-topic. I disagree, that's entirely on topic. I believe every modern implementation of Ada relies solely on RC(while having GC hooks.) Nobody really seems to have an issue with RC there. I personally believe that immediate RC and GC solve completely different issues of deterministic vs non-deterministic resource management. Trying to shoehorn them into the same thing gets you a broken, slow implementation(see: C++'s shared_ptr. It's dog slow and _way_ overused IMO.) In any case, there has been talk about introducing finalizers instead of destructors for GC managed objects. rt_attachDisposeEvent() already exists and is used by std.signal for weak references, but it's a hack, it needs to be formalized. These finalizers can then have much more restricted semantics than destructors, e.g. they must be callable on any thread, are generally un-@safe if they access members with indirections, and so on. I'm honestly curious of examples where finalizers are needed. The one exception I can think of is managing non-GC objects, as in C#. But that *still* seems like a bad idea because there's zero guarantee the destructor will ever run - i.e, a GC implementation that decides to just never call destructors is a valid implementation. http://dlang.org/class.html#destructors "The garbage collector is not guaranteed to run the destructor for all unreferenced objects. " D has more than one issue here, from combining "finalizer" and "destructor" into the same term to destructors being incredibly bug-prone and almost useless as defined by the standard. I hope this gets looked at. Bye.
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 14:00:55 UTC, Etienne wrote:
There is a bug regarding unordered object collection in the GC.
My finalizer accesses another GC-allocated object and the
application *sometimes* crashes here:
void _d_invariant(Object o)
{ ClassInfo c;
//printf("__d_invariant(%p)\n", o);
// BUG: needs to be filename/line of caller, not library
routine
assert(o !is null); // just do null check, not invariant
check
c = typeid(o);
^- this is the crash location
The culprit seems to be these operations:
7ff6`881f324b 488b4510mov rax,qword ptr
[rbp+10h]
7ff6`881f324f 488b10 mov rdx,qword ptr [rax]
7ff6`881f3252 488b1a mov rbx,qword ptr [rdx]
ds:`=
The vtable lookup wants to dereference a null entry. Not sure
how I can fix this, but in the meantime I think typeid could
actually add a small check on RDX and return null if that's
what it is. Any input?
This is undefined behavior, the only solution is "don't do it"
see my thread
http://forum.dlang.org/post/vcpcjujvkbuoswyzy...@forum.dlang.org
destructors as they are shouldn't exist at all, they are
incredibly bug prone.
Bye.
Re: osx shared libraries.
On Mon, 15 Jun 2015 23:56:14 -0400, bitwise wrote:
It actually appears that __attribute__((visibility("hidden")) is
redundant and making it a constructor already hides it.
derp.. no it's not. Its the fact they were marked static in the C code
that made them hidden.
If anyone is willing to point me in the right direction here, it would be
much appreciated ;)
Looking at Martin's github, it doesn't appear that he's back in business
yet.
Thanks,
Bit
Re: Workaround for typeid access violation
On Tuesday, 16 June 2015 at 14:32:45 UTC, Steven Schveighoffer wrote: On 6/16/15 10:00 AM, Etienne wrote: There is a bug regarding unordered object collection in the GC. My finalizer accesses another GC-allocated object Don't do that. Nothing is guaranteed in order of destruction. Note that after calling the destructor of an object, the vtable pointer is nulled. -Steve Obviously the debugger shows that the object's destructor wasn't called. I have the class set as final and all the locals are there. Somehow its vtable is destroyed before though. When I comment out the _d_invariant part at this point until the end, I can do a crazy amount of requests (this is a webserver) and there will be no crash at all. So with the proper flags, its obviously possible to access a "final class" object locals during destruction, isn't this why the GC isn't re-entrant in the first place?
Re: Workaround for typeid access violation
On 6/16/15 10:00 AM, Etienne wrote: There is a bug regarding unordered object collection in the GC. My finalizer accesses another GC-allocated object Don't do that. Nothing is guaranteed in order of destruction. Note that after calling the destructor of an object, the vtable pointer is nulled. -Steve
Workaround for typeid access violation
There is a bug regarding unordered object collection in the GC.
My finalizer accesses another GC-allocated object and the
application *sometimes* crashes here:
void _d_invariant(Object o)
{ ClassInfo c;
//printf("__d_invariant(%p)\n", o);
// BUG: needs to be filename/line of caller, not library
routine
assert(o !is null); // just do null check, not invariant check
c = typeid(o);
^- this is the crash location
The culprit seems to be these operations:
7ff6`881f324b 488b4510mov rax,qword ptr [rbp+10h]
7ff6`881f324f 488b10 mov rdx,qword ptr [rax]
7ff6`881f3252 488b1a mov rbx,qword ptr [rdx]
ds:`=
The vtable lookup wants to dereference a null entry. Not sure how
I can fix this, but in the meantime I think typeid could actually
add a small check on RDX and return null if that's what it is.
Any input?
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 13:16:40 UTC, Ola Fosheim Grøstad wrote: Unfortunately not true, you're adding multiple alias this… Excuse me for what I am trying to avoid overquoting :) You probably refer to CLOS and not proper Lisp. CLOS was adopted as part of the standard ANSI Common Lisp. What is interesting to know ANSI Common Lisp is wrong? C++ has multiple inheritance and "solves" it, but most C++ programmers try to avoid multiple inheritance anyway. So why would D be better with it? In different languages rhombus problem is solved in different ways. And C++ is not the best case in point, where the problem is solved well. Of course, most of the C++-programmers avoid multiple inheritance, but the other part, which uses it at least a little, what a tie that does not use it. D - this is not the language of minimalist (for example, Go) :) We had to implement multiple inheritance, without relying on C++. IMO.
Re: Current D grammar
Iain Buclaw via Digitalmars-d wrote: > https://github.com/Hackerpilot/DGrammar If the grammar is truely generated automatically, then there are some quirks in it. For example is declarator defined as a list of attributes only. -manfred
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 09:55:34 UTC, Walter Bright wrote: On 6/13/2015 6:51 PM, Steven Schveighoffer wrote: Just use the static if trick. Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary. Probably because of this forward referencing bug with "static if," which I've run into myself: https://issues.dlang.org/show_bug.cgi?id=3743 I agree with you about using version and I applaud your attempt to centralize such version logic, just pointing out that bugs in the implementation of "static if" are not a good way to enforce this. ;)
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 09:55:34 UTC, Walter Bright wrote: On 6/13/2015 6:51 PM, Steven Schveighoffer wrote: Just use the static if trick. Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary. Are you referring to this? https://github.com/D-Programming-Language/druntime/commit/54ca71b154fd9476520a63e30a50980af8927a56 If yes, I would claim that this is hardly relevant to this discussion, but I couldn't find any other druntime commits where you changed static ifs. - David
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 10:39:48 UTC, Dennis Ritchie wrote: On Tuesday, 16 June 2015 at 10:05:05 UTC, Walter Bright wrote: It does not allow multiple inheritance. Unfortunately not true, you're adding multiple alias this… I have often heard from Lisp programmers that the rejection of multiple inheritance is a weakness. They believe that it's well implemented in Lisp, and developers of other languages can not solve the problem of the diamond. You probably refer to CLOS and not proper Lisp. C++ has multiple inheritance and "solves" it, but most C++ programmers try to avoid multiple inheritance anyway. So why would D be better with it?
Re: version: multiple conditions
On Tuesday, 16 June 2015 at 10:05:05 UTC, Walter Bright wrote: It does not allow multiple inheritance. I have often heard from Lisp programmers that the rejection of multiple inheritance is a weakness. They believe that it's well implemented in Lisp, and developers of other languages can not solve the problem of the diamond.
Re: version: multiple conditions
On 6/14/2015 4:03 AM, ketmar wrote: honestly, if i'll want to have a limited language, i'll take Go. Go doesn't have conditional compilation. > removing a power only 'cause it can be abused is not in a "spirit of D", Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. It does not allow multiple inheritance. It does not allow structs to have virtual functions. (All of these deliberate limitations have had their proponents.)
Re: version: multiple conditions
On 6/15/2015 7:51 AM, Jonathan M Davis wrote: > [...] I have yet to see a single case of "needing" boolean versions that could not be refactored into something much more readable and maintainable that did not use such. Over time, I've gotten rid of most of that stuff from the dmd source code, and the result has been quite pleasing.
Re: version: multiple conditions
On 6/14/2015 9:53 AM, bitwise wrote: What if I need AndroidOrWP8, and I also need Win32OrWin64? This can quickly become a much larger pita. If you need those, the design is wrong. It is better to think about what the code is trying to do with Android or WP8, and label *that* a version.
Re: version: multiple conditions
On 6/13/2015 6:51 PM, Steven Schveighoffer wrote: Just use the static if trick. Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary. You can use it in your own code if you like, but I strongly recommend against that and suggest instead the one of the myriad ways I've suggested before for straightforwardly adapting to versions.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Sunday, 14 June 2015 at 09:38:02 UTC, Alix Pexton wrote: On 12/06/2015 12:48 PM, Chris wrote: "man" is still used as a gender neutral pronoun in German, however, for some reason it's frowned upon these days, just like "one" in English. It's considered "arrogant" and old fashioned, but it's effin useful and solves a lot of problems. Mind you, decisions made by those who compile dictionaries and "standards" are not at all based on the reality of a given language. Double negation exists in English (and many other languages), but it's stigmati(s|z)ed as being "incorrect". The vote was 5 to 4 when this decision was made in England. The official reasoning behind it was that minus + minus = plus, i.e. "I don't have no money" would mean "I do have money", which is complete horsesh*t. Of course it means "I don't have money". The real reason, of course, was class snobbery and elitism: double negation was and still is commonly used in working class English in England (and the US, I think). Ironically enough, double negation is obligatory in standard French, while it is not used in colloquial French. This shows you how arbitrary these standards are. Don't take them too seriously, and don't start religious wars about some eggheads' decisions ;) The same goes for "ain't". There's no reason why "ain't" should be "bad English". "I ain't got no money" is perfectly fine, although it might make the odd Oxbridge fellow cringe and spill his tea. But what the Dickens, old chap! I must be rare, cos I ain't posh n' well educated but I deplore the use of double negatives in English. I might be heard t'say "I ain't got n' money" (cos it be true) but in that case the "n'" is the local dialect contraction of "any". Other areas of the UK can't use the same excuse, maybe they got it from us but didn't understand what we were say'n, which is very common, but am more inclined to blame ignorance. Don't know anything about double negative usage in French, but I do know that they are a way making super polite requests in Japanese. Lets all not not stop arguing the minutia. A... Then generations of music fans were baffled by lyrics like "I ain't got no money to show" (Double trouble), "I can't get no satisfaction". To use "any" ain't no better, because it still is a double negative. I'll give you Pinker's explanation: "At this point, defenders of the standard are likely to pull out the notorious double negative, as in I can't get no satisfaction. Logically speaking, the two negatives cancel each other out, they teach; Mr. Jagger is actually saying that he is satisfied. The song should be entitled "I Can't Get Any Satisfaction." But this reasoning is not satisfactory. Hundreds of languages require their speakers to use a negative element somewhere within the "scope," as linguists call it, of a negated verb. The so-called double negative, far from being a corruption, was the norm in Chaucer's Middle English, and negation in standard French—as in Je ne sais pas, where ne and pas are both negative—is a familiar contemporary example. Come to think of it, Standard English is really no different. What do any, even, and at all mean in the following sentences? I didn't buy any lottery tickets. I didn't eat even a single French fry. I didn't eat fried food at all today. Clearly, not much: you can't use them alone, as the following strange sentences show: I bought any lottery tickets. I ate even a single French fry. I ate fried food at all today. What these words are doing is exactly what no is doing in nonstandard American English, such as in the equivalent I didn't buy no lottery tickets—agreeing with the negated verb. The slim difference is that nonstandard English co-opted the word no as the agreement element, whereas Standard English co-opted the word any ; aside from that, they are pretty much translations. And one more point has to be made. In the grammar of standard English, a double negative does not assert the corresponding affirmative. No one would dream of saying I can't get no satisfaction out of the blue to boast that he easily attains contentment. There are circumstances in which one might use the construction to deny a preceding negation in the discourse, but denying a negation is not the same as asserting an affirmative, and even then one could probably only use it by putting heavy stress on the negative element, as in the following contrived example: As hard as I try not to be smug about the misfortunes of my adversaries, I must admit that I can't get no satisfaction out of his tenure denial. So the implication that use of the nonstandard form would lead to confusion is pure pedantry." http://www.sp.uconn.edu/~sih01001/english/fall2007/TheLanguageMavens.pdf
Re: PHP verses C#.NET verses D.
On Monday, 15 June 2015 at 23:53:06 UTC, Nick B wrote: Hi. There is a startup in New Zealand that I have some dealings with at present. They have build most of their original code in PHP, (as this was quick and easy) but they also use some C#.net for interfacing to accounting appls on clients machines. The core PHP application runs in the cloud at present and talks to accountings applications in the cloud. They use the PHP symfony framework. High speed in not important, but accuracy, error handling, and scalability is, as they are processing accounting transactions. They have a new CEO on board, and he would like to review the companies technical direction. Their client base is small but growing quickly. I know that PHP is not a great language, and my knowledge of D is reasonable, while I have poor knowledge of C#.net. Looking to the future, as volumes grow, they could: 1. Stay with PHP & C#.net, and bring on servers as volumes grow. 2. Migrate to C#.net in time 3. Migrate to D in time. Any comments or suggestions on the above? Both C# and D sound like good fits there. It depends on whether it's the sort of team who like to innovate and explore new possibilities or whether they want a completely fleshed out, stable ecosystem. D can make boring work interesting: endless boiler-plate can be neatly abstracted and many models* can be expressed JustRight™ as opposed to being shoehorned in to a standard abstraction. C# is also pretty good at this (sometimes), but D has a significant edge.
Re: PHP verses C#.NET verses D.
First off I would stress that architecture and process are more important than which of those 3 languages you choose, i.e. good testing (I prefer test driven), continuous integration, and a solid architecture that you are confident will provide the reliability, correctness and uptime that you require. Having said that I would then personally be conservative and choose to standardise on C# for its maturity, expressiveness and great tooling. It also has a good ecosystem (libraries etc.) which will prove very useful in business related tasks. D has better expressiveness and probably would run faster but given all the other factors I would be concerned right now about its slight lack of maturity and under-developed ecosystem.
Re: Extern Linkage Type
implib works for C calling convention only.
Re: Current D grammar
On 06/14/2015 08:05 PM, Manfred Nowak wrote: With my favorite LALR-CompilerCompiler I analyzed the current D grammar. After preliminary eliminating the RR-conflicts around 1800 states remained, from which around 100 states are still contaminated with SR-conflicts. Two possibilities: 1) Those ambiguities are not in DMD but introduced by excerpting the grammar from DMD 2) Those ambiguities do exist in DMD. Which one do you prefer? Is the grammar usable? Although I don't recall details, when I attempted it a few years back, I came to the conclusion that getting a correct grammar for D (and likely other non-trivial C-family languages) that was realistically useful is essentially impossible in LALR(1). I'm sure you'd be able to do it if you upgraded to GLF though (or maybe LALR(k) might work, though I'm not sure). The problem I found with LR is that totally separate branches of the grammar will easily conflict with each other (whereas in LL separate branches are completely independent). That leads to tree patterns that work fine in LL but make LR/LALR barf unless you do major contortions to get around the conflicts. GLR looked like it should be able to overcome those conflicts with ease (although I don't know how the efficiency would compare to LL). With LR and LALR, you can *theoretically* you can get around all those conflicts for the academic sake of "Does this input satisfy the grammar or not? Yes or no?". But again, it requires contorting the grammar. And unfortunately, the more you have to contort it, the less useful the parse tree becomes for real-world purposes beyond just "The input satisfies/doesn't satisfy the grammar".
