Re: Program logic bugs vs input/environmental errors
On 01/10/14 21:57, Steven Schveighoffer wrote: ./progThatExpectsFilename "" -Steve It's the developer's responsibility to make sure a value like that never reaches the "File" constructor. That is, the developer of the "progThatExpectsFilename" application that uses "File". Not the developer of "File". Although, I don't see why you shouldn't be able to pass an empty string to "File". You'll just get an exception, "cannot open file ''". This is exactly what happens in Bash: $ echo "asd" > "" -bash: : No such file or directory -- /Jacob Carlborg
Re: FOSDEM'15 - let us propose a D dev room!!!
On Wednesday, 1 October 2014 at 16:21:37 UTC, Dicebot wrote: Unfortunately, D developer room was rejected: Like every year, we received quite a lot more proposals than we have rooms at our disposal. Unfortunately, we were not able to schedule your proposed room this year. The list of accepted rooms can be found on our website. We hope you'll agree that we have an interesting lineup despite the absence of the room you proposed. If the content you intended to schedule in a dedicated developer room fits in one of the accepted rooms, please submit it there when the CFP is announced. List of accepted developer rooms: https://fosdem.org/2015/news/2014-09-30-accepted-devrooms/ Don't know if something related to D may fit one of accepted devrooms. The more surprising to me is that they scheduled a Smalltalk room.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 02/10/14 01:19, Andrei Alexandrescu wrote: My recollection is that was only talked about. Anyhow, one thing is clear - as of now there are no clear idioms and successful techniques for handling errors with exceptions (including the use of subtyping). -- Andrei I think most error handling is done with "enforce", this will, by default, throw an instance of Exception. I really, really hate this. I think Exception should be an abstract class or an interface. -- /Jacob Carlborg
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 02/10/14 01:19, David Nadlinger wrote: What are you referring to specifically? Compared to Tango, yes, Phobos might have a lot fewer concrete exception types. But I don't recall actually eliminating existing ones. It happens implicitly when using "enforce". By default it will throw an instance of Exception. In most cases I don't think the developer bothers with specifying a specific exception type. I really, really hate this. It makes it basically impossible to do any form of error handling correctly. I think Exception should be an interface or abstract class. -- /Jacob Carlborg
Re: RFC: moving forward with @nogc Phobos
On 01/10/14 19:25, Oren T wrote:
The idea is that the unique property is very short-lived: the caller
immediately assigns it to a pointer of the appropriate policy: either RC
or GC. This keeps the callee agnostic of the chosen policy and does not
require templating multiple versions of the code. The allocator
configured for the thread must match the generated code at the call site
i.e. if the caller uses RC pointers the allocator must allocate space
for the reference counter (at negative offset to keep compatibility).
Can't we do something like this, or it might be what you're proposing:
Foo foo () { return new Foo; }
@gc a = foo(); // a contains an instance of Foo allocated with the GC
@rc b = foo(); // b contains an instance of Foo allocated with the RC
allocator
--
/Jacob Carlborg
Re: [Semi OT] Language for Game Development talk
On 2 October 2014 07:03, po via Digitalmars-d wrote: > >> OOP style and AoS in general does cause cache unfriendly data access. You >> can separate out your hot and cold data but at that point you're not really >> programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. >> for different reasons than cache friendliness. > > > Modern C++ != OO style. > > I'd say modern C++ is more generic + functional than OO. > > He seems to think C++ is about programming in some sort of Java design > pattern inspired way. That's what a post-grad often tends to do...
Re: [Semi OT] Language for Game Development talk
On 2 October 2014 01:17, po via Digitalmars-d wrote: > On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: >> >> Max Klyga: >> >>> https://www.youtube.com/watch?v=TH9VCN6UkyQ >> >> >> A third talk (from another person) about related matters: >> https://www.youtube.com/watch?v=rX0ItVEVjHc >> >> He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and >> lot of other C++ stuff. On the other hand he writes data-oriented code >> manually, the compiler and language give him only very limited help, and the >> code he writes looks twiddly and bug-prone. So why aren't they designing a >> language without most of the C++ stuff they don't use, but with features >> that help them write the data-oriented code they need? >> >> Bye, >> bearophile > > > He (deliberately I'd guess)conflates cache friendly data structures and > access patterns with his particular preference for a C style. > > It is a fallacy that he presents as fact. He uses C style as an aggressive reminder of what you're actually trying to do at all times. We actually did this in our own engine long before he started giving lectures like this. One of the best ways to stop people doing insane shit in C++ is to ban C++. The engine dev's loved this commitment to C, but the game logic programmers hated us ;) There is a middle ground though...
Re: [Semi OT] Language for Game Development talk
On 2 October 2014 00:16, bearophile via Digitalmars-d wrote: > Max Klyga: > >> https://www.youtube.com/watch?v=TH9VCN6UkyQ > > > A third talk (from another person) about related matters: > https://www.youtube.com/watch?v=rX0ItVEVjHc > > He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and > lot of other C++ stuff. On the other hand he writes data-oriented code > manually, the compiler and language give him only very limited help, and the > code he writes looks twiddly and bug-prone. So why aren't they designing a > language without most of the C++ stuff they don't use, but with features > that help them write the data-oriented code they need? Most gamedev's aren't quite as staunch as Mike Acton. The principle is there, ingrained in every gamedev, but that doesn't mean we all love flat C (although lots of us do!). I've never used RTTI, I've never used exceptions, certainly never use multiple inheritance, I rarely use templates (in C++)... but I'm still attracted to D!? I often find this strange... but not really. In D, I still don't use RTTI, I still don't use exceptions, I tend to box use of templates into their own worlds, so I would never use them pervasively (like phobos). You'll notice at one point that he talked about using offline text processing tools to do codegen... this is basically because C's preprocessor sucks, and C++ templates suck. D templates have proven to eliminate a lot of those offline tools for me. The code is kept in the same place, and built using the same tool. I suspect even Acton would appreciate features like CTFE. You'll also notice he made repeated reference to build environment complexity and build times. D also offers potential compiler advantages, purity, immutable, etc, which give the optimiser information which it can use to improve codegen which is awkward in C/C++.
Re: Mike Acton at CppCon (prominent game-dev lecture to non-game-dev's)
Oh, and I totally missed that it was already posted in the other thread! Sorry! >_< (is it just me, or is it getting really hard to keep up with this forum these days!?)
Mike Acton at CppCon (prominent game-dev lecture to non-game-dev's)
I just thought I'd drop this here for peoples interest. It occurred to me that I usually take this sort of thing separately to my interest in D, but since there are few gamedev's here, and I often have trouble attracting sympathy for our industry concerns, this might give some window into the way we think, and tend to approach... basically everything. Mike is a super well known (and outspoken) engine dev, every gamedev knows who he is. What he's presenting here to CppCon is something that we've been doing pervasively for 10-15 years. It's all fairly basic and obvious, but all-too-often ignored. You can see the focus on codegen and low-level performance, and how much attention we tend to pay to it :) This leads into things like, for instance, why I'm so fussy about things like very highly-controlled handling of ref, and final-by-default. https://www.youtube.com/watch?v=rX0ItVEVjHc&feature=youtu.be
Re: [Semi OT] Language for Game Development talk
Am 02.10.2014 01:07, schrieb Max Klyga: On 2014-10-01 22:33:39 +, Paulo Pinto said: Am 02.10.2014 00:11, schrieb po: I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP. Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts. Data encapsulation is not unique to oop. STL is ADT not OOP. STL was ADT when it was initially written in Ada 83, not any longer. First of all it doesn't exist any longer as such. The International Standard ISO/IEC 14882:2014(E) Programming Language C++ has zero occurrences of the word STL. ADT implies using modules, data structures and functions that operate on those functions. Which in C++ is achieved via separate compilation, namespaces and functions. Basically what Ada 83, Mesa and Modula-2, UCSD Pascal offered as abstraction for organizing algorithms and data structures. If a class is being used, then it already uses the first concept of OOP. Aggregation of data and member functions into a type. A module on steroids. The door is also open to inheritance and aggregation. If a class does not forbid inheritance, then it can have derived classes, even if the author did not intend it. Thus inheritance and dynamic polymorphism came into the picture. Two other OOP concepts. Finally, just for the fact that we have objects, member function invocations are now static dispatch. But if virtual methods are declared, then dynamic dispatch comes into play. Both properties of OOP systems. Given the way C++ allows for function overloading, static multi-method dispatch is also possible when used with NVO. Just because inheritance is not used, it doesn't mean something isn't OOP. There are much more concepts at play. When concepts lite come into the language, then C++ gains another way to deal with interfaces. Which will be used a lot in the standard library as well. As I mentioned in another post. I can easily provide examples of the C++ standard library classes and how they use OOP concepts. -- Paulo
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 10/1/14, 4:00 PM, Sean Kelly wrote: On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via Digitalmars-d wrote: If you see "throws Exception" in java code chances are the code is broken, same as if you see "catch (Exception" - this tells you nothing about the exception that happened, and hence you can do nothing with it. So you either swallow (and silently break in many cases) or rethrow (and break for things you needn't have). As mentioned, the standard way to avoid this is to have a parent exception type appropriate to the abstraction in the API, and throw subtypes in the implementation. Among other things, this means you can change the implementation to throw different exceptions without breaking any users (who will already be catching the parent exception). while in Phobos, most of the subtyped exceptions were eliminated a while back in favor of just always throwing Exception. My recollection is that was only talked about. Anyhow, one thing is clear - as of now there are no clear idioms and successful techniques for handling errors with exceptions (including the use of subtyping). -- Andrei
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On Wednesday, 1 October 2014 at 23:00:41 UTC, Sean Kelly wrote: ...while in Phobos, most of the subtyped exceptions were eliminated a while back in favor of just always throwing Exception. What are you referring to specifically? Compared to Tango, yes, Phobos might have a lot fewer concrete exception types. But I don't recall actually eliminating existing ones. David
Re: [Semi OT] Language for Game Development talk
On 2014-10-01 22:33:39 +, Paulo Pinto said: Am 02.10.2014 00:11, schrieb po: I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP. Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts. Data encapsulation is not unique to oop. STL is ADT not OOP.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via Digitalmars-d wrote: If you see "throws Exception" in java code chances are the code is broken, same as if you see "catch (Exception" - this tells you nothing about the exception that happened, and hence you can do nothing with it. So you either swallow (and silently break in many cases) or rethrow (and break for things you needn't have). As mentioned, the standard way to avoid this is to have a parent exception type appropriate to the abstraction in the API, and throw subtypes in the implementation. Among other things, this means you can change the implementation to throw different exceptions without breaking any users (who will already be catching the parent exception). ...while in Phobos, most of the subtyped exceptions were eliminated a while back in favor of just always throwing Exception.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On Wed, Oct 1, 2014 at 7:24 AM, Bruno Medeiros via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > > What has failed is not the concept of checked exceptions per se, but > mostly, the failure of Java programmers to use checked exceptions > effectively, and properly design their code around this paradigm. > > This. I have seen many java programs (and their programmers) fail utterly at using exceptions. Like OO, the design of the system has to leverage it properly, and there are places where people can easily get tripped up - but when used well, can be immensely useful. Error handling is part of an API, and exceptions are error handling, so should be considered when designing API. Checked exceptions are a language-supported way to do this. For those that consider checked exceptions a failure: what other feature(s) would work instead? NB: If you see "throws Exception" in java code chances are the code is broken, same as if you see "catch (Exception" - this tells you nothing about the exception that happened, and hence you can do nothing with it. So you either swallow (and silently break in many cases) or rethrow (and break for things you needn't have). As mentioned, the standard way to avoid this is to have a parent exception type appropriate to the abstraction in the API, and throw subtypes in the implementation. Among other things, this means you can change the implementation to throw different exceptions without breaking any users (who will already be catching the parent exception). Adding/modifying a throws clause is an API-breaking change, so should be avoided however easy it is in the IDE. (Yes, I'm biased to writing libraries consumed by others) NNB: Retrofitting a program to use proper exception handling is much harder than it is to design it the right way from scratch. I'm going to compare to OO again: don't consider OO broken because people use inheritance when they want ownership, and it is painful to fix later.
Re: [Semi OT] Language for Game Development talk
Am 02.10.2014 00:11, schrieb po: I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP. Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts. -- Paulo
Re: [Semi OT] Language for Game Development talk
I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP.
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 23:44, schrieb po: Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. I see lots of it. How many examples do you want? Well Boost might have some, I haven't looked at every library. I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo
Re: [Semi OT] Language for Game Development talk
Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. I see lots of it. How many examples do you want? Well Boost might have some, I haven't looked at every library. I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 23:16, schrieb po: On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote: I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses. Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. I see lots of it. How many examples do you want? C++ jumped off the OOP bandwagon some time ago. That I agree. We have learned to not abuse hierarchies and to take advantage of the multi-paradigm capabilities of the language. -- Paulo
Re: [Semi OT] Language for Game Development talk
Perhaps a (part of) language more fit/helpful/nice for that
purpose/use can be invented.
Bye,
bearophile
It isn't as hard as he pretends to write SoA code in C++. In
fact it is possible to abstract the underlying data you are
operating on, and replace it with vector type
Example resembling his butt ugly code: operates only on 1 float
at a time
struct Vec2{
float x,y;
};
void Add2(Vec2* points, int howMany){
for(int i = 0;i
struct Vec2{
T x,y;
};
typedef Vec2 vec2_8f;
//float8 is a wrapper around AVX256 8 wide float type that
behaves exactly like a //normal float but is actually 8 floats.
void Add2(range points){
for(auto& p:points){
p += 2.0f;
}
}
C++ can abstract away the fact that float8 is actually
implemented using a bunch of AVX intrinsics. Using his approach
he'd be manually writing intrinsics until the cows came home.
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 23:03, schrieb po: OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way. If he is stuck in the late 90's/early 2000's, yes. At what point does he say it's difficult to code in a SoA style in C++? He clearly states he sees no advantage to C++ over C. 1. He references Design patterns during his tirade against C++, who the hell uses design patterns in C++ these days? Those architects, specially the CORBA ones, are nowadays doing J2EE and WPF MVVM applications. And the original design patterns were actually targeted at Smalltalk, with C++ on the side as the language was started to get popular in the industry. 2. He uses Ogre, a 15 year old terrible mess of a rendering engine, written in a nasty Java style, as an example of why C++ is bad I never liked Ogre. A strange mix of OO with too much low level C like stuff still. At least when I looked at it a few years ago. -- Paulo
Re: RFC: moving forward with @nogc Phobos
On 10/1/14, 1:56 PM, "Marc Schütz" " wrote: On Wednesday, 1 October 2014 at 17:13:38 UTC, Andrei Alexandrescu wrote: On 10/1/14, 8:48 AM, Oren Tirosh wrote: Bingo. Have some way to mark the function return type as a unique pointer. I'm skeptical about this approach (though clearly we need to explore it for e.g. passing ownership of data across threads). For strings and other "casual" objects I think we should focus on GC/RC strategies. This is because people do things like: auto s = setExtension(s1, s2); and then attempt to use s as a regular variable (copy it etc). Making s unique would make usage quite surprising and cumbersome. Sure? I already showed in an example how it is possible to chain calls seamlessly that return unique objects. The users would only notice it when they are trying to make a real copy (i.e. not borrowing). Do you think this happens frequently enough to be of concern? I'd think so. -- Andrei
Re: RFC: moving forward with @nogc Phobos
On 10/1/14, 10:51 AM, H. S. Teoh via Digitalmars-d wrote: But Sean's idea only takes strings into account. Strings aren't the only allocated resource Phobos needs to deal with. So extrapolating from that idea, each memory management struct (or whatever other aggregate we end up using), say call it MMP, will have to define MMP.string, MMP.jsonNode (since parseJSON() need to allocate not only strings but JSON nodes), MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ... Nope, still don't see how this could work. Please clarify, kthx. There's management for T[], pointers to structs, pointers to class objects, associative arrays, and that covers everything. -- Andrei
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote: I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses. Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. C++ jumped off the OOP bandwagon some time ago.
Re: [Semi OT] Language for Game Development talk
OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way. At what point does he say it's difficult to code in a SoA style in C++? He clearly states he sees no advantage to C++ over C. 1. He references Design patterns during his tirade against C++, who the hell uses design patterns in C++ these days? 2. He uses Ogre, a 15 year old terrible mess of a rendering engine, written in a nasty Java style, as an example of why C++ is bad
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 17:13:38 UTC, Andrei Alexandrescu wrote: On 10/1/14, 8:48 AM, Oren Tirosh wrote: Bingo. Have some way to mark the function return type as a unique pointer. I'm skeptical about this approach (though clearly we need to explore it for e.g. passing ownership of data across threads). For strings and other "casual" objects I think we should focus on GC/RC strategies. This is because people do things like: auto s = setExtension(s1, s2); and then attempt to use s as a regular variable (copy it etc). Making s unique would make usage quite surprising and cumbersome. Sure? I already showed in an example how it is possible to chain calls seamlessly that return unique objects. The users would only notice it when they are trying to make a real copy (i.e. not borrowing). Do you think this happens frequently enough to be of concern?
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 15:48:39 UTC, Oren Tirosh wrote:
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz
wrote:
One problem with actually implementing this is that using
reference counting as a memory management policy requires extra
space for the reference counter in the object, just as garbage
collection requires support for scanning and identification of
interior object memory range. While allocation and memory
management may be quite independent in theory, practical high
performance implementations tend to be intimately related.
(I'll try to make a sketch on how this can be implemented in
another post.)
Do elaborate!
As a conclusion, I would say that APIs should strive for the
following principles, in this order:
1. Avoid allocation altogether, for example by laziness
(ranges), or by accepting sinks.
2. If allocations are necessary (or desirable, to make the API
more easily usable), try hard to return a unique value (this
of course needs to be expressed in the return type).
3. If both of the above fails, only then return a GCed
pointer, or alternatively provide several variants of the
function (though this shouldn't be necessary often). An
interesting alternative: Instead of passing a flag directly
describing the policy, pass the function a type that it should
wrap it's return value in.
As for the _allocation_ strategy: It indeed needs to be
configurable, but here, the same objections against a template
parameter apply. As the allocator doesn't necessarily need to
be part of the type, a (thread) global variable can be used to
specify it. This lends itself well to idioms like
with(MyAllocator alloc) {
// ...
}
Assuming there is some dependency between the allocator and the
memory management policy I guess this would be initialized on
thread start that cannot be modified later. All code running
inside the thread would need to either match the configured
policy, not handle any kind of pointers or use a limited subset
of unique pointers. Another way to ensure that code can run on
either RC or GC is to make certain objects (specifically,
Exceptions) always allocate a reference counter, regardless of
the currently configured policy.
I don't have all answers to these questions. Still, I'm convinced
this is doable.
A straight-forwarding and general way to convert a unique object
to a ref-counted one is to allocate new memory for it plus the
reference count, move the original object into it, and release
the original memory. This is safe, because there can be no
external pointers to the object, as it is unique. Of course, this
can be optimized if the allocator supports extending an
allocation. It could then preallocate a few extra bytes at the
end to make the extend operation always succeed, similar to your
suggestion to always allocate a reference counter.
I think the most difficult part is to find an efficient and
user-friendly way for the wrapper types to get at the allocator.
Maybe the allocators should all implement an interface (a real
one, not duck-typing). The wrappers (Owned, RC) can then include
a pointer to the allocator (or for RC, embed it next to the
reference count). This would make it possible to specify a
(thread) global default allocator at runtime, which all library
functions use by convention (for example let's call it `alloc`,
then they would call `alloc.make!MyStruct()`). At the same time,
it is safe to change the default allocator at any time, and to
use different allocators in parallel in the same thread.
The alternative is obviously a template parameter to the function
that returns the unique object. But this unfortunately is then
not restricted to just the function, but "infects" the return
type, too. And from there, it needs to spread to the RC wrapper,
or any containers. Thus we'd have incompatible RC types, which I
would imagine would be very inconvenient and restrictive.
Besides, it would probably be too tedious to specify the
allocator everywhere.
Therfore, I think the additional cost of an allocator interface
pointer is worth it. For Owned!T (with T being a pointer or
reference), it would just be two words, which we can return
efficiently. We already have slices doing that, and AFAIK there's
no significantly worse performance because of them.
Re: Program logic bugs vs input/environmental errors
On 10/1/14 3:27 PM, Jacob Carlborg wrote: On 2014-09-29 17:13, Steven Schveighoffer wrote: Is it? I can think of cases where it's programmer error, and cases where it's user error. When would it be a user error? ./progThatExpectsFilename "" -Steve
Re: Program logic bugs vs input/environmental errors
On 10/1/14 3:24 PM, Paolo Invernizzi wrote: On Wednesday, 1 October 2014 at 14:46:50 UTC, Steven Schveighoffer wrote: On 10/1/14 10:36 AM, Bruno Medeiros wrote: This is a grey area that I think reasonable people can correctly call a bug if they so wish, despite the intentions of the developer. Correctly? In a discussion, It's amazing how difficult it is to agree also on simple words meaning: an _intentional programmer behaviour_ a bug? More appropriately, it's not a bug but an incorrect design. I still would call it a bug, and I'm 99% sure the users would report it as a bug :) -Steve
Re: @safe pure nothrow compiler inference
On Wednesday, 1 October 2014 at 15:12:41 UTC, Kagamin wrote: On Monday, 29 September 2014 at 14:40:34 UTC, Daniel N wrote: It can be done, Walter wanted to do it, but there was large resistance, mainly because library APIs would become unstable, possibly changing between every release. Huh? Templates are part of library API too, see std.algorithm. So what's the difference if the API consists of templated or non-templated functions? Why for one part of API it's ok to change with every release and for the other not ok? It's not that "it's OK for templates", it's that you *must* have inference. This was not an argument against having inference for normal functions.
Re: Program logic bugs vs input/environmental errors
On 2014-09-29 17:13, Steven Schveighoffer wrote: Is it? I can think of cases where it's programmer error, and cases where it's user error. When would it be a user error? -- /Jacob Carlborg
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 18:37:50 UTC, Sean Kelly wrote: On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via Digitalmars-d wrote: But Sean's idea only takes strings into account. Strings aren't the only allocated resource Phobos needs to deal with. So extrapolating from that idea, each memory management struct (or whatever other aggregate we end up using), say call it MMP, will have to define MMP.string, MMP.jsonNode (since parseJSON() need to allocate not only strings but JSON nodes), MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ... Nope, still don't see how this could work. Please clarify, kthx. Assuming you're willing to take the memoryModel type as a template argument, I imagine we could do something where the user can specialize the memoryModel for their own types, a bit like how information is derived for iterators in C++. The problem is that this still means passing the memoryModel in as a template argument. What I'd really want is for it to be a global, except that templated virtuals is logically impossible. I guess something could maybe be sorted out via a factory design, but that's not terribly D-like. I'm at a loss for how to make this memoryModel thing work the way I'd actually want it to if I were to use it. If you were to forget D restrictions for a moment, and consider an idealized language, how would you express this? Maybe providing that will trigger some ideas from people beyond what we have seen so far by removing implied restrictions.
Re: Program logic bugs vs input/environmental errors
On Wednesday, 1 October 2014 at 14:46:50 UTC, Steven Schveighoffer wrote: On 10/1/14 10:36 AM, Bruno Medeiros wrote: This is a grey area that I think reasonable people can correctly call a bug if they so wish, despite the intentions of the developer. Correctly? In a discussion, It's amazing how difficult it is to agree also on simple words meaning: an _intentional programmer behaviour_ a bug? Whah ;-P --- /Paolo
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via Digitalmars-d wrote: But Sean's idea only takes strings into account. Strings aren't the only allocated resource Phobos needs to deal with. So extrapolating from that idea, each memory management struct (or whatever other aggregate we end up using), say call it MMP, will have to define MMP.string, MMP.jsonNode (since parseJSON() need to allocate not only strings but JSON nodes), MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ... Nope, still don't see how this could work. Please clarify, kthx. Assuming you're willing to take the memoryModel type as a template argument, I imagine we could do something where the user can specialize the memoryModel for their own types, a bit like how information is derived for iterators in C++. The problem is that this still means passing the memoryModel in as a template argument. What I'd really want is for it to be a global, except that templated virtuals is logically impossible. I guess something could maybe be sorted out via a factory design, but that's not terribly D-like. I'm at a loss for how to make this memoryModel thing work the way I'd actually want it to if I were to use it.
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 17:33:34 UTC, Andrei Alexandrescu wrote: On 10/1/14, 10:25 AM, Oren T wrote: The idea is that the unique property is very short-lived: the caller immediately assigns it to a pointer of the appropriate policy: either RC or GC. This keeps the callee agnostic of the chosen policy and does not require templating multiple versions of the code. The allocator configured for the thread must match the generated code at the call site i.e. if the caller uses RC pointers the allocator must allocate space for the reference counter (at negative offset to keep compatibility). This all... looks arcane. I'm not sure how it can even made to work if user code just uses "auto". -- Andrei At the moment, @nogc code can't call any function returning a pointer. Under this scheme @nogc is allowed to call either code that returns an explicitly RC type (Exception, RCString) or code returning an "agnostic" unique pointer that may be used from either @gc or @nogc code. I already see some holes and problems, but I wonder if something along these lines may be made to work.
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 17:33:34 UTC, Andrei Alexandrescu wrote: On 10/1/14, 10:25 AM, Oren T wrote: The idea is that the unique property is very short-lived: the caller immediately assigns it to a pointer of the appropriate policy: either RC or GC. This keeps the callee agnostic of the chosen policy and does not require templating multiple versions of the code. The allocator configured for the thread must match the generated code at the call site i.e. if the caller uses RC pointers the allocator must allocate space for the reference counter (at negative offset to keep compatibility). This all... looks arcane. I'm not sure how it can even made to work if user code just uses "auto". -- Andrei At the moment, @nogc code can't call any function returning a pointer. Under this scheme @nogc is allowed to call either code that returns an explicitly RC ty
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Oct 01, 2014 at 02:51:08AM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
>29-Sep-2014 14:49, Andrei Alexandrescu пишет:
>>auto setExtension(MemoryManagementPolicy mmp = gc, R1,
>>R2)(R1 path, R2
>>ext)
>>if (...)
>>{
>> static if (mmp == gc) alias S = string;
>> else alias S = RCString;
>> S result;
>> ...
>> return result;
>>}
>
>Incredible code bloat? Boilerplate in each function for the
>win?
>I'm at loss as to how it would make things better.
Sean's idea to make string an alias of the policy takes care
of this
concern. -- Andrei
But Sean's idea only takes strings into account. Strings aren't
the only
allocated resource Phobos needs to deal with. So extrapolating
from that
idea, each memory management struct (or whatever other
aggregate we end
up using), say call it MMP, will have to define MMP.string,
MMP.jsonNode
(since parseJSON() need to allocate not only strings but JSON
nodes),
MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ...
Nope, still don't see how this could work. Please clarify, kthx.
T
MMP.Ref!redBlackTreeNode ?
(where Ref is e.g. a ref-counted pointer type (like RefCounted
but with class support) for RC MMP but plain GC reference for GC
MMP, etc.)
I kinda like this idea, since it might possibly allow
user-defined memory management policies (which wouldn't get
special compiler treatment that e.g. RC may need, though).
Re: How to build phobos docs for dlang.org
On Wed, Oct 01, 2014 at 05:11:47PM +, Mark Isaacson via Digitalmars-d wrote: > On Wednesday, 1 October 2014 at 09:00:51 UTC, Robert burner Schadek wrote: > >On Wednesday, 1 October 2014 at 06:29:46 UTC, Mark Isaacson wrote: > > > >>I hereby volunteer to document whatever answer I am given. > > > >already done http://wiki.dlang.org/Building_DMD#Building_the_Docs > > I saw this yesterday and followed the instructions but was unable to > get it to work. At a minimum, the first 'make' does not do anything > and the 'generated/linux/default' directory does not exist. I see > 'generated/linux/64' instead if I use the posix.mak file. If I proceed > using that directory instead, I end up with the same problem: Now when > I run the phobos html build it does format everything in the dlang.org > colors, but I'm still missing std_container.html. Here's what I do: cd /path/to/dlang.org make -f posix.mak html cp -rf web /path/to/webdir/ cd /path/to/phobos make -f posix.mak html cp -rf ../web /path/to/webdir/ This installs the Phobos docs in /path/to/webdir/web/phobos-prerelease/* (note, by default it does NOT install to ../web/phobos/*). So assuming your webserver root points to /path/to/webdir, you can then point your browser to: http://your.web.server/web/phobos-prerelease/std_container.html Let me know if this still doesn't help. T -- There are three kinds of people in the world: those who can count, and those who can't.
Re: RFC: moving forward with @nogc Phobos
On Wed, Oct 01, 2014 at 02:51:08AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
> >29-Sep-2014 14:49, Andrei Alexandrescu пишет:
> >>auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1 path, R2
> >>ext)
> >>if (...)
> >>{
> >> static if (mmp == gc) alias S = string;
> >> else alias S = RCString;
> >> S result;
> >> ...
> >> return result;
> >>}
> >
> >Incredible code bloat? Boilerplate in each function for the win?
> >I'm at loss as to how it would make things better.
>
> Sean's idea to make string an alias of the policy takes care of this
> concern. -- Andrei
But Sean's idea only takes strings into account. Strings aren't the only
allocated resource Phobos needs to deal with. So extrapolating from that
idea, each memory management struct (or whatever other aggregate we end
up using), say call it MMP, will have to define MMP.string, MMP.jsonNode
(since parseJSON() need to allocate not only strings but JSON nodes),
MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ...
Nope, still don't see how this could work. Please clarify, kthx.
T
--
Sometimes the best solution to morale problems is just to fire all of the
unhappy people. -- despair.com
Re: RFC: moving forward with @nogc Phobos
On 10/1/14, 10:25 AM, Oren T wrote: The idea is that the unique property is very short-lived: the caller immediately assigns it to a pointer of the appropriate policy: either RC or GC. This keeps the callee agnostic of the chosen policy and does not require templating multiple versions of the code. The allocator configured for the thread must match the generated code at the call site i.e. if the caller uses RC pointers the allocator must allocate space for the reference counter (at negative offset to keep compatibility). This all... looks arcane. I'm not sure how it can even made to work if user code just uses "auto". -- Andrei
Re: FOSDEM'15 - let us propose a D dev room!!!
I think I will attend anyway as a casual visitor, can have an informal D meetup at least.
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 17:13:38 UTC, Andrei Alexandrescu wrote: On 10/1/14, 8:48 AM, Oren Tirosh wrote: On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz wrote: [...] I'm convinced this isn't necessary. Let's take `setExtension()` as an example, standing in for any of a class of similar functions. This function allocates memory, returns it, and abandons it; it gives up ownership of the memory. The fact that the memory has been freshly allocated means that it is (head) unique, and therefore the caller (= library user) can take over the ownership. This, in turn, means that the caller can decide how she wants to manage it. Bingo. Have some way to mark the function return type as a unique pointer. I'm skeptical about this approach (though clearly we need to explore it for e.g. passing ownership of data across threads). For strings and other "casual" objects I think we should focus on GC/RC strategies. This is because people do things like: auto s = setExtension(s1, s2); and then attempt to use s as a regular variable (copy it etc). Making s unique would make usage quite surprising and cumbersome. The idea is that the unique property is very short-lived: the caller immediately assigns it to a pointer of the appropriate policy: either RC or GC. This keeps the callee agnostic of the chosen policy and does not require templating multiple versions of the code. The allocator configured for the thread must match the generated code at the call site i.e. if the caller uses RC pointers the allocator must allocate space for the reference counter (at negative offset to keep compatibility).
Re: FOSDEM'15 - let us propose a D dev room!!!
On 1 October 2014 17:21, Dicebot via Digitalmars-d wrote: > Unfortunately, D developer room was rejected: > >> Like every year, we received quite a lot more proposals than we have >> rooms at our disposal. Unfortunately, we were not able to schedule your >> proposed room this year. > > >> The list of accepted rooms can be found on our website. We hope you'll >> agree that we have an interesting lineup despite the absence of the room >> you proposed. If the content you intended to schedule in a dedicated >> developer room fits in one of the accepted rooms, please submit it there >> when the CFP is announced. > > > List of accepted developer rooms: > https://fosdem.org/2015/news/2014-09-30-accepted-devrooms/ > > Don't know if something related to D may fit one of accepted devrooms. I could always gate crash Go's dev room. :o)
Re: How to build phobos docs for dlang.org
On 10/1/14, 10:11 AM, Mark Isaacson wrote: On Wednesday, 1 October 2014 at 09:00:51 UTC, Robert burner Schadek wrote: On Wednesday, 1 October 2014 at 06:29:46 UTC, Mark Isaacson wrote: I hereby volunteer to document whatever answer I am given. already done http://wiki.dlang.org/Building_DMD#Building_the_Docs I saw this yesterday and followed the instructions but was unable to get it to work. At a minimum, the first 'make' does not do anything and the 'generated/linux/default' directory does not exist. I think I fixed that a while ago; "default" was a mistake. I see 'generated/linux/64' instead if I use the posix.mak file. If I proceed using that directory instead, I end up with the same problem: Now when I run the phobos html build it does format everything in the dlang.org colors, but I'm still missing std_container.html. I think for a while now Phobos documentation has been produced as part of building dlang.org (which itself is right now difficult to build without babysitting for unrelated reasons). So building Phobos docs straight from Phobos might have some bit rot. We should sort this out when I get back in a Facebook chat. I recommend you start with phobos/posix.mak and build from there. Take a white box approach - open posix.mak in an editor and see what happens when you build "html". You'll see where the generated docs go (I think in a dir called "web" that is configurable by choosing DOC_OUTPUT_DIR. Doing so is easy from the outside: make html DOC_OUTPUT_DIR=/tmp/wtf Andrei
Re: RFC: moving forward with @nogc Phobos
On 10/1/14, 8:48 AM, Oren Tirosh wrote: On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz wrote: [...] I'm convinced this isn't necessary. Let's take `setExtension()` as an example, standing in for any of a class of similar functions. This function allocates memory, returns it, and abandons it; it gives up ownership of the memory. The fact that the memory has been freshly allocated means that it is (head) unique, and therefore the caller (= library user) can take over the ownership. This, in turn, means that the caller can decide how she wants to manage it. Bingo. Have some way to mark the function return type as a unique pointer. I'm skeptical about this approach (though clearly we need to explore it for e.g. passing ownership of data across threads). For strings and other "casual" objects I think we should focus on GC/RC strategies. This is because people do things like: auto s = setExtension(s1, s2); and then attempt to use s as a regular variable (copy it etc). Making s unique would make usage quite surprising and cumbersome. Andrei
Re: How to build phobos docs for dlang.org
On Wednesday, 1 October 2014 at 09:00:51 UTC, Robert burner Schadek wrote: On Wednesday, 1 October 2014 at 06:29:46 UTC, Mark Isaacson wrote: I hereby volunteer to document whatever answer I am given. already done http://wiki.dlang.org/Building_DMD#Building_the_Docs I saw this yesterday and followed the instructions but was unable to get it to work. At a minimum, the first 'make' does not do anything and the 'generated/linux/default' directory does not exist. I see 'generated/linux/64' instead if I use the posix.mak file. If I proceed using that directory instead, I end up with the same problem: Now when I run the phobos html build it does format everything in the dlang.org colors, but I'm still missing std_container.html.
Re: RFC: moving forward with @nogc Phobos
On 10/1/14, 7:03 AM, Sean Kelly wrote: So let the user supply a scratch buffer that will hold the result? With the RC approach we're still allocating, they just aren't built-in slices, correct? Correct. -- Andrei
Re: RFC: moving forward with @nogc Phobos
On 10/1/14, 6:52 AM, Sean Kelly wrote: On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu wrote: On 9/30/14, 9:10 AM, Sean Kelly wrote: Is this for exposition purposes or actually how you expect it to work? That's pretty much what it would take. The key here is that RCString is almost a drop-in replacement for string, so the code using it is almost identical. There will be places where code needs to be replaced, e.g. auto s = "literal"; would need to become S s = "literal"; So creation of strings will change a bit, but overall there's not a lot of churn. I'm confused. Is this a general-purpose solution or just one that switches between string and RCString? General purpose since your suggested change. -- Andrei
Re: [Semi OT] Language for Game Development talk
Am 01.10.2014 17:40, schrieb currysoup: I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses. C++ does not imply OOP. And the zero overhead abstractions are a culture heritage from C as it was the only way to sell C++ to most C developers. -- Paulo
Re: FOSDEM'15 - let us propose a D dev room!!!
Unfortunately, D developer room was rejected: Like every year, we received quite a lot more proposals than we have rooms at our disposal. Unfortunately, we were not able to schedule your proposed room this year. The list of accepted rooms can be found on our website. We hope you'll agree that we have an interesting lineup despite the absence of the room you proposed. If the content you intended to schedule in a dedicated developer room fits in one of the accepted rooms, please submit it there when the CFP is announced. List of accepted developer rooms: https://fosdem.org/2015/news/2014-09-30-accepted-devrooms/ Don't know if something related to D may fit one of accepted devrooms.
Re: std.experimental.logger formal review round 3
On 10/1/14 11:53 AM, Marco Leise wrote: Am Wed, 01 Oct 2014 15:05:53 + schrieb "Robert burner Schadek" : On Wednesday, 1 October 2014 at 14:24:52 UTC, Marco Leise wrote: Am Wed, 01 Oct 2014 12:49:29 + schrieb "Robert burner Schadek" : maybe I should add a disableGetSysTime switch CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored. good pointer, but what about Win and Mac Windows 2000 had some function that returns 4ms accurate time, I hope it is implemented like CLOCK_REALTIME_COARSE. I think it wouldn't be prudent to explore Windows options until we prove the windows currTime is slow like the Linux version. On Mac, gettimeofday is used. I don't know that it's necessarily slow, but I don't know of a better way to get the wall clock time. -Steve
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Probably because C++ is good enough and already has mature infrastructure.
Re: [Semi OT] Language for Game Development talk
currysoup: At what point does he say it's difficult to code in a SoA style in C++? Perhaps a (part of) language more fit/helpful/nice for that purpose/use can be invented. Bye, bearophile
Re: RFC: moving forward with @nogc Phobos
Oren Tirosh: Bingo. Have some way to mark the function return type as a unique pointer. This does not imply full-fledged unique pointer type support in the language Let's have full-fledged memory zones tracking in the D type system :-) Bye, bearophile
Re: RFC: moving forward with @nogc Phobos
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz wrote:
[...]
I'm convinced this isn't necessary. Let's take `setExtension()`
as an example, standing in for any of a class of similar
functions. This function allocates memory, returns it, and
abandons it; it gives up ownership of the memory. The fact that
the memory has been freshly allocated means that it is (head)
unique, and therefore the caller (= library user) can take over
the ownership. This, in turn, means that the caller can decide
how she wants to manage it.
Bingo. Have some way to mark the function return type as a unique
pointer. This does not imply full-fledged unique pointer type
support in the language - just enough to have the caller ensure
continuity of memory management policy from there.
One problem with actually implementing this is that using
reference counting as a memory management policy requires extra
space for the reference counter in the object, just as garbage
collection requires support for scanning and identification of
interior object memory range. While allocation and memory
management may be quite independent in theory, practical high
performance implementations tend to be intimately related.
(I'll try to make a sketch on how this can be implemented in
another post.)
Do elaborate!
As a conclusion, I would say that APIs should strive for the
following principles, in this order:
1. Avoid allocation altogether, for example by laziness
(ranges), or by accepting sinks.
2. If allocations are necessary (or desirable, to make the API
more easily usable), try hard to return a unique value (this of
course needs to be expressed in the return type).
3. If both of the above fails, only then return a GCed pointer,
or alternatively provide several variants of the function
(though this shouldn't be necessary often). An interesting
alternative: Instead of passing a flag directly describing the
policy, pass the function a type that it should wrap it's
return value in.
As for the _allocation_ strategy: It indeed needs to be
configurable, but here, the same objections against a template
parameter apply. As the allocator doesn't necessarily need to
be part of the type, a (thread) global variable can be used to
specify it. This lends itself well to idioms like
with(MyAllocator alloc) {
// ...
}
Assuming there is some dependency between the allocator and the
memory management policy I guess this would be initialized on
thread start that cannot be modified later. All code running
inside the thread would need to either match the configured
policy, not handle any kind of pointers or use a limited subset
of unique pointers. Another way to ensure that code can run on
either RC or GC is to make certain objects (specifically,
Exceptions) always allocate a reference counter, regardless of
the currently configured policy.
Re: [Semi OT] Language for Game Development talk
I certainly believe C++ style and it's community promote the idea of zero overhead abstractions and the kind of OOP style which _does_ cause cache misses.
Re: std.experimental.logger formal review round 3
Am Wed, 01 Oct 2014 15:05:53 + schrieb "Robert burner Schadek" : > On Wednesday, 1 October 2014 at 14:24:52 UTC, Marco Leise wrote: > > Am Wed, 01 Oct 2014 12:49:29 + > > schrieb "Robert burner Schadek" : > > > >> maybe I should add a disableGetSysTime switch > > > > CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored. > > good pointer, but what about Win and Mac Windows 2000 had some function that returns 4ms accurate time, I hope it is implemented like CLOCK_REALTIME_COARSE. OS X ... oh well. Don't know. Just declare the "fast timer" a hint, I guess. Like when you ask for anti-aliasing in OpenGL and the implementation is free to decide if it can or want's to deliver. So it turns into: "I need a sub-second timestamp, but make it as fast as possible on the target OS". Maybe some day Apple will copy CLOCK_REALTIME_FAST from FreeBSD. > > > > If you disable time completely, what would the LogEntry > > contain as the time stamp? SysTime.init? > > That was my first idea. -- Marco
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 15:17:33 UTC, po wrote: On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact. The key to these type of fast code isn't the C style, it is the contiguous data layout, and cache friendly access patterns, both of which are easily enough to perform in modern C++. OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. At what point does he say it's difficult to code in a SoA style in C++? He clearly states he sees no advantage to C++ over C.
Re: Program logic bugs vs input/environmental errors
On 10/1/14 11:00 AM, Andrej Mitrovic via Digitalmars-d wrote: On 10/1/14, Steven Schveighoffer via Digitalmars-d wrote: No, this is lazy/incorrect coding. You don't want your user to see an indecipherable stack trace on purpose. So when they file a bug report are you going to also ask them to run the debugger so they capture the stack trace and file that to you? Come on. No what I mean is: ./niftyapp badfilename.txt Result should be: Error: Could not open badfilename.txt, please check and make sure the file exists and is readable. Not: std.exception.ErrnoException@std/stdio.d(345): Cannot open file `badfilename.txt' in mode `rb' (No such file or directory) 5 testexception 0x000104fad02d ref std.stdio.File std.stdio.File.__ctor(immutable(char)[], const(char[])) + 97 6 testexception 0x000104f8d735 _Dmain + 69 7 testexception 0x000104f9f771 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().void __lambda1() + 33 8 testexception 0x000104f9f6bd void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 45 9 testexception 0x000104f9f71d void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 45 10 testexception 0x000104f9f6bd void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 45 11 testexception 0x000104f9f639 _d_run_main + 449 12 testexception 0x000104f8d75c main + 20 13 libdyld.dylib 0x7fff8fb2a5fd start + 1 14 ??? 0x0001 0x0 + 1 If it's an error due to *user input*, you should not rely on the exception handling of the runtime, you should have a more user-friendly message. Obviously, if you fail to handle it, the full trace happens, and then you must fix that in your code. It's for your benefit too :) This way you get less nuisance troubleshooting calls since the error message is clearer. -Steve
Re: [Semi OT] Language for Game Development talk
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote: Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact. The key to these type of fast code isn't the C style, it is the contiguous data layout, and cache friendly access patterns, both of which are easily enough to perform in modern C++.
Re: @safe pure nothrow compiler inference
On Monday, 29 September 2014 at 14:40:34 UTC, Daniel N wrote: It can be done, Walter wanted to do it, but there was large resistance, mainly because library APIs would become unstable, possibly changing between every release. Huh? Templates are part of library API too, see std.algorithm. So what's the difference if the API consists of templated or non-templated functions? Why for one part of API it's ok to change with every release and for the other not ok?
Re: std.experimental.logger formal review round 3
On Wednesday, 1 October 2014 at 14:24:52 UTC, Marco Leise wrote: Am Wed, 01 Oct 2014 12:49:29 + schrieb "Robert burner Schadek" : maybe I should add a disableGetSysTime switch CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored. good pointer, but what about Win and Mac If you disable time completely, what would the LogEntry contain as the time stamp? SysTime.init? That was my first idea.
Re: Program logic bugs vs input/environmental errors
On 10/1/14, Steven Schveighoffer via Digitalmars-d wrote: > No, this is lazy/incorrect coding. You don't want your user to see an > indecipherable stack trace on purpose. So when they file a bug report are you going to also ask them to run the debugger so they capture the stack trace and file that to you? Come on.
Re: Program logic bugs vs input/environmental errors
On 10/1/14 10:36 AM, Bruno Medeiros wrote: On 01/10/2014 14:55, Steven Schveighoffer wrote: On 10/1/14 9:47 AM, Bruno Medeiros wrote: On 29/09/2014 19:58, Steven Schveighoffer wrote: Any uncaught exceptions are BY DEFINITION programming errors. Not necessarily. For some applications (for example simple console apps), you can consider the D runtime's default exception handler to be an appropriate way to respond to the exception. No, this is lazy/incorrect coding. You don't want your user to see an indecipherable stack trace on purpose. -Steve Well, at the very least it's bad UI design for sure (textual UI is still UI). But it's only a *bug* if it's not the behavior the programmer intended. Sure, one could also halt a program by reading a null pointer on purpose. This is a grey area that I think reasonable people can correctly call a bug if they so wish, despite the intentions of the developer. -Steve
Re: Program logic bugs vs input/environmental errors
On 01/10/2014 14:55, Steven Schveighoffer wrote: On 10/1/14 9:47 AM, Bruno Medeiros wrote: On 29/09/2014 19:58, Steven Schveighoffer wrote: Any uncaught exceptions are BY DEFINITION programming errors. Not necessarily. For some applications (for example simple console apps), you can consider the D runtime's default exception handler to be an appropriate way to respond to the exception. No, this is lazy/incorrect coding. You don't want your user to see an indecipherable stack trace on purpose. -Steve Well, at the very least it's bad UI design for sure (textual UI is still UI). But it's only a *bug* if it's not the behavior the programmer intended. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [GDC] Evaluation order: Please update the dmd backend
Now I'm working to fix issue 6620 https://issues.dlang.org/show_bug.cgi?id=6620 https://github.com/D-Programming-Language/dmd/pull/4035 Kenji Hara 2014-04-01 20:49 GMT+09:00 Johannes Pfau : > I started fixing GDC bug #8 (*) which is basically that array op > evaluation order currently depends on the target architecture. Consider > this example: > a()[] = b()[] + c()[]; > The order in which c,a,b are called is currently architecture specific. > As stated in that bug report by Andrei we want this to evaluate LTR, so > a() first, then b(), then c(). > > These operations are actually rewritten to calls to extern(C) > functions. Arguments to C function should be evaluated LTR as well, but > dmd currently evaluates them RTL (GDC: architecture dependent). In order > to fix the array op bug in gdc we have to define the evaluation order > for extern(C) function parameters. > > So I've changed extern(C) functions to evaluate LTR in GDC and then had > to change the array op code, cause that assumed extern(C) function > evaluate RTL. Now I'd like to push these array op changes into dmd as we > want to keep as few gdc specific changes as possible and dmd (and ldc) > will need these changes anyway as soon as they implement extern(C) > functions as LTR. This is required by dmd issue #6620 (**) and the > language spec (***). > > However, if we apply only these changes the array op order reverses for > DMD as it evaluates extern(C) function arguments RTL. > > So I need someone with dmd backend knowledge to fix the evaluation > order of extern(C) function parameters to be LTR. > Evaluation order of assignments should also be fixed to be LTR in the > dmd backend. Although not strictly required for the array op changes > it'd be inconsistent to have array op assignments execute LTR but > normal assignments RTL: > a()[] = b()[] + c()[]; //Array op assignment > a() = b() + c(); //Normal assignment > | || > 1 23 > > The frontend changes for dmd are here: > https://github.com/jpf91/dmd/tree/fixOrder > Frontend: > > https://github.com/jpf91/dmd/commit/5d61b812977dbdc1f99100e2fbaf1f45e9d25b03 > Test cases: > > https://github.com/jpf91/dmd/commit/82bffe0862b272f02c27cc428b22a7dd113b4a07 > > Druntime changes (need to be applied at the same time as dmd changes) > https://github.com/jpf91/druntime/tree/fixOrder > > https://github.com/jpf91/druntime/commit/f3f6f49c595d4fb25fb298e435ad1874abac516d > > > (*) http://bugzilla.gdcproject.org/show_bug.cgi?id=8 > (**) https://d.puremagic.com/issues/show_bug.cgi?id=6620 > (***) https://github.com/D-Programming-Language/dlang.org/pull/6 >
Re: Program logic bugs vs input/environmental errors
Bruno Medeiros: But if Walter is fixated on thinking that all the practical uses of D will be critical systems, or simple (ie, single-use, non-interactive) command-line applications, There's still some of way to go for D design to make it well fit for high integrity systems (some people even use a restricted subset of C for such purposes, but it's a bad language for it). Bye, bearophile
Re: std.experimental.logger formal review round 3
Am Wed, 01 Oct 2014 12:49:29 + schrieb "Robert burner Schadek" : > maybe I should add a disableGetSysTime switch CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored. On Linux you can't expect finer resolution than the kernel Hz, for FreeBSD I only found mention of 10ms resolution. If you format log messages with 2 digits time precision anyway, you don't need the precise version. If you disable time completely, what would the LogEntry contain as the time stamp? SysTime.init? -- Marco
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 22:32:26 UTC, Sean Kelly wrote: Would delete on the D side work here? Or the more current destroy()? ie. is release of the memory a crucial part of the equation, or merely finalization? Destruction of an object is *far* more important than releasing memory. Our D code's memory usage is drops in an ocean, but it can potentially hold on to resources that need to be destroyed in special ways depending on middleware/threading usage. Object.destroy() would do the job, but there's also a fragmentation problem that creeps in to a GC solution like the default D implementation the longer you have your application running. We already encounter plenty of cache-incoherent code in other areas of the codebase, and since one of my roles is to evangelise D (so to speak) I'm aiming to keep it running fast and avoiding as many stalls as possible. If I avoid the current implementation's garbage collection, then memory allocated stays in roughly the same region (some work that I did manage to do and intend on submitting a pull request for allows a user to specify a custom set of allocation functions, so all memory from core and phobos goes through our supplied memory allocator). Either way, it still comes down to a function call to free your object which means you're stepping outside of the way the GC natively does things.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 29/09/2014 20:28, Sean Kelly wrote: Checked exceptions are good in theory but they failed utterly in Java. I'm not interested in seeing them in D. That is the conventional theory, the established wisdom. But the more I become experienced with Java, over the years, I've become convinced otherwise. What has failed is not the concept of checked exceptions per se, but mostly, the failure of Java programmers to use checked exceptions effectively, and properly design their code around this paradigm. Like Jeremy mentioned, if one puts catch blocks right around the function that throws an exception, and just swallow/forget it there without doing anything else, then it's totally the programmers fault for being lazy. If one is annoyed that often, adding a throws clause in a function will require adding the same throws clause function to several other functions, well, that is editing work you have to accept for the sake of more correctness. But also one should understand there are ways to mitigate this editing work: First point is that in a lot of code, is better to have a function throw just one generic (but checked) exception, that can wrap any other specific errors/exceptions. If you are doing an operation that can throw File-Not-Found, Invalid-Path, No-Permissions, IO-Exception, etc., then often all of these will be handled in the same user-reporting code, so they could be wrapped under a single exception that would be used in the throws clause. And so the whole function call chain doesn't need to be modified every time a new exception is added or removed. If you're thinking that means adding a "throws Exception" to such functions in Java, then no. Because this will catch RuntimeExceptions too (the unchecked exceptions of Java), and these you often want to handle elsewhere than where you handle the checked exceptions. In this regard, Java does have a design fault, IMO, which is that there is no common superclass for checked Exceptions. (there is only for unchecked exceptions) The second point, is that even adding (or modifying) the throws clause of function signatures cause be made much easier with an IDE, and in particular Eclipse JDT helps a lot. If you have an error in the editor about a checked exception that is not caught or thrown, you can just press Ctrl-1 to automatically add either a throws clause, or a surrounding try-catch block. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Semi OT] Language for Game Development talk
Max Klyga: https://www.youtube.com/watch?v=TH9VCN6UkyQ A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile
Re: Program logic bugs vs input/environmental errors
On 29/09/2014 05:03, Sean Kelly wrote: I recall Toyota got into trouble with their computer controlled cars because of their idea of handling of inevitable bugs and errors. It was one process that controlled everything. When something unexpected went wrong, it kept right on operating, any unknown and unintended consequences be damned. The way to get reliable systems is to design to accommodate errors, not pretend they didn't happen, or hope that nothing else got affected, etc. In critical software systems, that means shut down and restart the offending system, or engage the backup. My point was that it's often more complicated than that. There have been papers written on self-repairing systems, for example, and ways to design systems that are inherently durable when it comes to even internal errors. I think what I'm trying to say is that simply aborting on error is too brittle in some cases, because it only deals with one vector--memory corruption that is unlikely to reoccur. But I've watched always-on systems fall apart from some unexpected ongoing situation, and simply restarting doesn't actually help. Sean, I fully agree with the points you have been making so far. But if Walter is fixated on thinking that all the practical uses of D will be critical systems, or simple (ie, single-use, non-interactive) command-line applications, it will be hard for him to comprehend the whole point that "simply aborting on error is too brittle in some cases". PS: Walter, what browser to you use? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Program logic bugs vs input/environmental errors
On 28/09/2014 00:15, Walter Bright wrote: This issue comes up over and over, in various guises. I feel like Yosemite Sam here: https://www.youtube.com/watch?v=hBhlQgvHmQ0 In that vein, Exceptions are for either being able to recover from input/environmental errors, or report them to the user of the application. When I say "They are NOT for debugging programs", I mean they are NOT for debugging programs. This is incorrect. Yes, the primary purpose of Exceptions is not for debugging, but to report exceptional state to the user (or some other component of the system). But they also have a purpose for debugging, particularly the stack traces of exceptions. Take what you said: "Failure to respond properly to an input/environmental error is a bug. But the input/environmental error is not a bug. If it was, then the program should assert on the error, not throw. " So, some component/function Foo detects an environmental error, and throws and Exception, accordingly. Foo is not responsible for handling these errors, but some other component is. Component/function Bar is the one that should handle such an error (for example, it should display a dialog to the user, and continue the application). But due to a bug, it doesn't do so, and the Exception goes all the way through main(). The programmer notices this happening, and clearly recognizes it's a bug (but doesn't know where the bug is, doesn't know that it's Bar that should be handling it). Now, what is best, to just have the Exception message (something like "File not found") displayed to the programmer - or even an end-user that could report a bug -, or to have the stack trace of the Exception so that the programmer can more easily look at which function should be handling it? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 9:10 AM, Sean Kelly wrote:
Quite honestly, I can't imagine how I could write a template
function in D that needs to work with this approach.
You mean write a function that accepts a memory management
policy, or a function that uses one?
Both, I suppose? A static if block at the top of each function
that must be aware of every RC type the user may expect? What if
it's a user-defined RC type and this function is in Phobos?
As much as I hate to say it, this is pretty much exactly what
C++
allocators were designed for. They handle allocation, sure,
but they
also hold aliases for all relevant types for the data being
allocated.
If the MemoryManagementPolicy enum were replaced with an alias
to a type that I could use to at least obtain relevant
aliases, that would be something. But even that approach
dramatically complicates code that uses it.
I think making MemoryManagementPolicy a meaningful type is a
great idea. It would e.g. define the string type, so the code
becomes:
auto setExtension(alias MemoryManagementPolicy = gc, R1, R2)(R1
path, R2 ext)
if (...)
{
MemoryManagementPolicy.string result;
...
return result;
}
This is a lot more general and extensible. Thanks!
Why do you think there'd be dramatic complication of code?
(Granted, at some point we must acknowledge that some egg
breaking is necessary for the proverbial omelette.)
From my experience with C++ containers. Having an alias for a
type is okay, but bank of aliases where one is a pointer to the
type, one is a const pointer to the type, etc, makes writing the
involved code feel really unnatural.
The thing is, again, we must make some changes if we want D to
be usable without a GC. One of them is e.g. to not allocate
built-in slices all over the place.
So let the user supply a scratch buffer that will hold the
result? With the RC approach we're still allocating, they just
aren't built-in slices, correct?
That would be overreacting :o).
I hope it is :-)
Re: Program logic bugs vs input/environmental errors
On 29/09/2014 19:58, Steven Schveighoffer wrote: Any uncaught exceptions are BY DEFINITION programming errors. Not necessarily. For some applications (for example simple console apps), you can consider the D runtime's default exception handler to be an appropriate way to respond to the exception. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: @safe pure nothrow compiler inference
I wanted to do it for "auto" returning functions, since they require a function body. Is there any good reason to _not_ do it for auto return functions? Atila
Re: Program logic bugs vs input/environmental errors
On 10/1/14 9:47 AM, Bruno Medeiros wrote: On 29/09/2014 19:58, Steven Schveighoffer wrote: Any uncaught exceptions are BY DEFINITION programming errors. Not necessarily. For some applications (for example simple console apps), you can consider the D runtime's default exception handler to be an appropriate way to respond to the exception. No, this is lazy/incorrect coding. You don't want your user to see an indecipherable stack trace on purpose. -Steve
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu wrote: On 9/30/14, 9:10 AM, Sean Kelly wrote: Is this for exposition purposes or actually how you expect it to work? That's pretty much what it would take. The key here is that RCString is almost a drop-in replacement for string, so the code using it is almost identical. There will be places where code needs to be replaced, e.g. auto s = "literal"; would need to become S s = "literal"; So creation of strings will change a bit, but overall there's not a lot of churn. I'm confused. Is this a general-purpose solution or just one that switches between string and RCString?
Re: std.experimental.logger formal review round 3
On Wednesday, 1 October 2014 at 10:50:54 UTC, Kevin Lamonte wrote: 2. We have Tid in the API. What about Fiber and Thread? If we can only pick one, I would vote for Thread rather than Tid, as Tid's currently have no way to be uniquely identified in a logging message. Reference: https://issues.dlang.org/show_bug.cgi?id=6989 In my opinion only solution that scales is to provide same ID as one used by std.concurrency - it can be thread, fiber, process or pretty much anything. There are many possible threading abstractions and all can't be easily supported, makes sense to stick to one considered standard.
Re: Program logic bugs vs input/environmental errors
On 29/09/2014 10:06, Walter Bright wrote: On 9/29/2014 1:27 AM, Johannes Pfau wrote: In a daemon which logs to syslog or in a GUI application or a game an uncaught 'disk full exception' would go completely unnoticed and that's definitely a bug. Failure to respond properly to an input/environmental error is a bug. But the input/environmental error is not a bug. If it was, then the program should assert on the error, not throw. I agree. And isn't that exactly what Teoh said then: "That's why I said, an uncaught exception is a BUG. " I think people should be more careful with the term "uncaught exception" because it's not very precise. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Program logic bugs vs input/environmental errors
On 28/09/2014 23:00, Walter Bright wrote: I can't get behind the notion of "reasonably certain". I certainly would not use such techniques in any code that needs to be robust, On 29/09/2014 04:04, Walter Bright wrote: > I know I'm hardcore and uncompromising on this issue, but that's where I > came from (the aviation industry). Walter, you do understand that not all software has to be robust - in the critical systems sense - to be quality software? And that in fact, the majority of software is not critical systems software?... I was under the impression that D was meant to be a general purpose language, not a language just for critical systems. Yet, on language design issues, you keep making a series or arguments and points that apply *only* to critical systems software. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: std.utf.decode @nogc please
On Wednesday, 1 October 2014 at 10:10:51 UTC, Robert burner
Schadek wrote:
lately when working on std.string I run into problems making
stuff nogc as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
Also I would like a version of decode that takes the string not
as ref.
Something like:
bool decode2(S,C)(S str, out C ret, out size_t strSliceIdx)
if(isSomeString!S && isSomeChar!C) {}
where true is returned if the decode worked and false otherwise.
Ideas, Suggestions ... ? any takers?
Kind of like the "non-throwing std.conv.to": I'm pretty sure that
if you wrote your "tryDecode" function, then you could back-wards
implement the old decode in terms of the new "tryDecode":
dchar decode(ref str)
{
dchar ret;
size_t idx;
enforce(tryDecode(str, ret, idx));
str = str[idx .. $];
return ret;
}
The implementation of tryDecode would be pretty much the old
one's implementation, exceptions replaced in favor of return
false.
Re: std.utf.decode @nogc please
On Wednesday, 1 October 2014 at 10:51:25 UTC, Walter Bright wrote: On 10/1/2014 3:10 AM, Robert burner Schadek wrote: Ideas, Suggestions ... ? any takers? You can use .byDchar instead, which is nothrow @nogc. Being forced out of using exception just to be able to have the magic "@nogc" tag is the real issue here... The original request was mostly for @nogc, not necessarilly for nothrow.
Re: std.experimental.logger formal review round 3
On Wednesday, 1 October 2014 at 10:50:54 UTC, Kevin Lamonte wrote: I haven't tested it yet, but have two questions anyway: 1. I did not see any reference to the use of Clock.currTime(), which on the last round accounted for about 90% of the total time spent in a log call. Reference: https://issues.dlang.org/show_bug.cgi?id=13433 . (This is the difference between logging-and-filtering ~100k logs/sec and ~1M logs/sec for loggers that use criteria other than logLevel for filtering messages.) Same question for this cycle: Does std.logger API need a method for clients or subclasses to change/defer/omit the call to Clock.currTime? Or defer for a change in std.datetime? maybe I should add a disableGetSysTime switch 2. We have Tid in the API. What about Fiber and Thread? If we can only pick one, I would vote for Thread rather than Tid, as Tid's currently have no way to be uniquely identified in a logging message. Reference: https://issues.dlang.org/show_bug.cgi?id=6989 General comment: very nice to see continued progress! I'm gone take a closer look
Re: Program logic bugs vs input/environmental errors
Am Sun, 28 Sep 2014 13:14:43 -0700 schrieb Walter Bright : > On 9/28/2014 12:33 PM, Jacob Carlborg wrote: > > On 2014-09-28 19:36, Walter Bright wrote: > > > >> I suggest removal of stack trace for exceptions, but leaving them in for > >> asserts. > > > > If you don't like the stack track, just wrap the "main" function in a > > try-catch > > block, catch all exceptions and print the error message. > > That's what the runtime that calls main() is supposed to do. Guys, a druntime flag could settle matters in 10 minutes. But this topic is clearly about the right school of thought. I use contracts to check for logical errors, like when an argument must not be null or a value less than the length of some data structure. I use exceptions to check for invalid input and the return values of external libraries. External libraries can be anything from my own code in the same project to OpenGL from vendor XY. They could error out on valid input (if we leave out of memory aside for now), because of bugs or incorrect assumptions of the implementation. If that happens and all I get is: "Library XY Exception: code 0x13533939 (Invalid argument)." I'm at a loss, where the library might have had a hickup. Did some function internally handle a uint as an int and wrapped around? Maybe with std.logger we will see single line messages on the terminal and multi-line exception traces in the logs (which by default print to stderr as well). And then this discussion can be resolved. -- Marco
Re: Creeping Bloat in Phobos
On Sunday, 28 September 2014 at 12:09:50 UTC, Andrei Alexandrescu wrote: On 9/27/14, 4:31 PM, H. S. Teoh via Digitalmars-d wrote: On Sat, Sep 27, 2014 at 11:00:16PM +, bearophile via Digitalmars-d wrote: H. S. Teoh: If we can get Andrei on board, I'm all for killing off autodecoding. Killing auto-decoding for std.algorithm functions will break most of my D2 code... perhaps we can do that in a D3 language. [...] Well, obviously it's not going to be done in a careless, drastic way! Stuff that's missing: * Reasonable effort to improve performance of auto-decoding; * A study of the matter revealing either new artifacts and idioms, or the insufficiency of such; * An assessment of the impact on compilability of existing code * An assessment of the impact on correctness of existing code (that compiles and runs in both cases) * An assessment of the improvement in speed of eliminating auto-decoding I think there's a very strong need for this stuff, because claims that current alternatives to selectively avoid auto-decoding use the throwing of hands (and occasional chairs out windows) without any real investigation into how library artifacts may help. This approach to justifying risky moves is frustratingly unprincipled. As far as I see, backward compatibility is fairly easy. Extract autodecoding modules into `autodecoding` dub package and clean up phobos modules into non-decoding behavior. The phobos code will be simplified: it will deal with ranges as is without specialization, the `autodecoding` dub package will be simple: just wraps strings into dchar range and invokes non-decoding function from phobos, preserves current module interface to keep legacy D code working. Run dfix on your sources, it will replace `import std.algorithm` with `import autodecoding.algorithm` - then the code should work. What do you think? Worth a DIP?
Re: std.utf.decode @nogc please
On Wednesday, 1 October 2014 at 10:51:25 UTC, Walter Bright wrote: On 10/1/2014 3:10 AM, Robert burner Schadek wrote: Ideas, Suggestions ... ? any takers? You can use .byDchar instead, which is nothrow @nogc. thanks, I will try that.
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 09:52:46 UTC, Andrei Alexandrescu wrote: On 9/30/14, 12:10 PM, "Marc Schütz" " wrote: I would argue that GC is at its core _only_ a memory management strategy. It just so happens that the one in D's runtime also comes with an allocator, with which it is tightly integrated. In theory, a GC can work with any (and multiple) allocators, and you could of course also call GC.free() manually, because, as you say, management and allocation are entirely distinct topics. I'm not very sure. A GC might need to interoperate closely with the allocator. -- Andrei It needs to know what to scan (ideally with type info), and which allocator to release memory with, but it doesn't need to be an allocator itself. It certainly helps with the implementation, but ideally there would be a well defined interface between allocators and GCs, so that both can be plugged in as desired, even with multiple GCs in parallel.
Re: std.experimental.logger formal review round 3
I haven't tested it yet, but have two questions anyway: 1. I did not see any reference to the use of Clock.currTime(), which on the last round accounted for about 90% of the total time spent in a log call. Reference: https://issues.dlang.org/show_bug.cgi?id=13433 . (This is the difference between logging-and-filtering ~100k logs/sec and ~1M logs/sec for loggers that use criteria other than logLevel for filtering messages.) Same question for this cycle: Does std.logger API need a method for clients or subclasses to change/defer/omit the call to Clock.currTime? Or defer for a change in std.datetime? 2. We have Tid in the API. What about Fiber and Thread? If we can only pick one, I would vote for Thread rather than Tid, as Tid's currently have no way to be uniquely identified in a logging message. Reference: https://issues.dlang.org/show_bug.cgi?id=6989 General comment: very nice to see continued progress!
Re: std.utf.decode @nogc please
On 10/1/2014 3:10 AM, Robert burner Schadek wrote: Ideas, Suggestions ... ? any takers? You can use .byDchar instead, which is nothrow @nogc.
Re: How to build phobos docs for dlang.org
On Wednesday, 1 October 2014 at 10:14:26 UTC, Robert burner Schadek wrote: Shall we link or copy that to CONTRIBUTING.md? -- Andrei I will create a PR with a link to the "Building DMD" wiki right now. https://github.com/D-Programming-Language/phobos/pull/2575
std.utf.decode @nogc please
lately when working on std.string I run into problems making
stuff nogc as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
Also I would like a version of decode that takes the string not
as ref.
Something like:
bool decode2(S,C)(S str, out C ret, out size_t strSliceIdx)
if(isSomeString!S && isSomeChar!C) {}
where true is returned if the decode worked and false otherwise.
Ideas, Suggestions ... ? any takers?
Re: How to build phobos docs for dlang.org
On Wednesday, 1 October 2014 at 10:03:33 UTC, Andrei Alexandrescu wrote: On 10/1/14, 2:00 AM, Robert burner Schadek wrote: On Wednesday, 1 October 2014 at 06:29:46 UTC, Mark Isaacson wrote: I hereby volunteer to document whatever answer I am given. already done http://wiki.dlang.org/Building_DMD#Building_the_Docs Shall we link or copy that to CONTRIBUTING.md? -- Andrei I will create a PR with a link to the "Building DMD" wiki right now.
Re: How to build phobos docs for dlang.org
On 10/1/14, 2:00 AM, Robert burner Schadek wrote: On Wednesday, 1 October 2014 at 06:29:46 UTC, Mark Isaacson wrote: I hereby volunteer to document whatever answer I am given. already done http://wiki.dlang.org/Building_DMD#Building_the_Docs Shall we link or copy that to CONTRIBUTING.md? -- Andrei
Re: RFC: moving forward with @nogc Phobos
On 9/30/14, 10:46 PM, "Nordlöw" wrote: On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu wrote: Back when I've first introduced RCString I hinted that we have a larger strategy in mind. Here it is. Slightly related :) https://github.com/D-Programming-Language/phobos/pull/2573 Nice, thanks! -- Andrei
Re: RFC: moving forward with @nogc Phobos
On 9/30/14, 6:53 PM, Manu via Digitalmars-d wrote: I generally like the idea, but my immediate concern is that it implies that every function that may deal with allocation is a template. This interferes with C/C++ compatibility in a pretty big way. Or more generally, the idea of a lib. Does this mean that a lib will be required to produce code for every permutation of functions according to memory management strategy? Usually libs don't contain code for uninstantiated templates. If a lib chooses one specific memory management policy, it can of course be non-templated with regard to that. If it wants to offer its users the choice, it would probably have to offer some templates. With this in place, I worry that traditional use of libs, separate compilation, external language linkage, etc, all become very problematic. Pervasive templates can only work well if all code is D code, and if all code is compiled together. Most non-OSS industry doesn't ship source, they ship libs. And if libs are to become impractical, then dependencies become a problem; instead of linking libphobos.so, you pretty much have to compile phobos together with your app (already basically true for phobos, but it's fairly unique). What if that were a much larger library? What if you have 10s of dependencies all distributed in this manner? Does it scale? I guess this doesn't matter if this is only a proposal for phobos... but I suspect the pattern will become pervasive if it works, and yeah, I'm not sure where that leads. Thanks for the point. I submit that Phobos has and will be different from other D libraries; as the standard library, it has the role of supporting widely varying needs, and as such it makes a lot of sense to make it highly generic and configurable. Libraries that are for specific domains can avail themselves of a narrower design scope. Andrei
Re: RFC: moving forward with @nogc Phobos
On 9/30/14, 12:10 PM, "Marc Schütz" " wrote: I would argue that GC is at its core _only_ a memory management strategy. It just so happens that the one in D's runtime also comes with an allocator, with which it is tightly integrated. In theory, a GC can work with any (and multiple) allocators, and you could of course also call GC.free() manually, because, as you say, management and allocation are entirely distinct topics. I'm not very sure. A GC might need to interoperate closely with the allocator. -- Andrei
Re: RFC: moving forward with @nogc Phobos
On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1 path, R2
ext)
if (...)
{
static if (mmp == gc) alias S = string;
else alias S = RCString;
S result;
...
return result;
}
Incredible code bloat? Boilerplate in each function for the win?
I'm at loss as to how it would make things better.
Sean's idea to make string an alias of the policy takes care of this
concern. -- Andrei
