Re: toString refactor in druntime
On Saturday, 1 November 2014 at 05:27:16 UTC, Jonathan Marler wrote: No need for the extra function, just call: x.toString(&(outputRange.put)); That doesn't work for a wide variety of possible cases, notably when `put` is a function template or when the code depends on std.range.put or some other UFCS `put` function. As such, it should be avoided in generic code, and then you might as well avoid it in general, lest your algorithm unnecessarily ends up breaking with output ranges you didn't test for after refactoring. (Note that parantheses are not required in your example)
Re: DIP67: Associative Ranges
On Sat, Nov 01, 2014 at 12:04:16AM +, Jakob Ovrum via Digitalmars-d wrote: > On Tuesday, 28 October 2014 at 22:44:32 UTC, Freddy wrote: > >http://wiki.dlang.org/DIP67 > >Abstraction over the build-in associative array(one type of range > >for containers and another type for dynamic generators). > >Plese criticize. > > Any examples of what this actually accomplishes? Maybe an example of > an algorithm that can do something useful with these primitives? A > rationale for why these are the chosen primitives? > > As the proposed "associative range" isn't consumable like other > ranges, this seems more like a specific kind of *container*, not a > *range*; indeed the text of the DIP seems to conflate the concepts, > but they are separate by necessity. > > Note that opIndex and opBinaryRight are already container primitives > (see std.container). There's also the additional relevant primitive > `removeKey`. Beyond that though, associative containers could need > some more fleshing out in the container concept. > > As it is, I think this proposal suffers both from lack of substance > and confusing terminology. I think a better name would be "associative array concept" rather than "associative range". Basically, this DIP is proposing a set of primitives that can be used to identify some given type as AA-like, so that generic code that expect AA-like objects would be able to work with any type that implements the expected interface. Ostensibly, one could then implement generic algorithms that work with AA-like objects. It's not a bad idea, really, except perhaps for the name. And the API could use more careful thought to boil it down to the essentials, rather than throwing in everything current AA syntax supports, just because AA syntax supports it. If we can boil down AA's and AA-like types into a small but expressive set of primitive operations, it could turn out to be a very useful abstraction that generic code could use. The current AA syntactic sugar can then be implemented in terms of the minimal primitives, and one could easily build AA-like objects by implementing the primitives, and automatically get all the syntactic sugar "for free" via UFCS and so on. T -- Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway
Re: toString refactor in druntime
On Friday, 31 October 2014 at 22:13:31 UTC, Jakob Ovrum wrote:
On Friday, 31 October 2014 at 19:09:28 UTC, H. S. Teoh via
Digitalmars-d wrote:
Besides, the sink version basically allows encapsulation of an
output
range -- instead of calling x.toString(outputRange) you just
write:
x.toString((const(char)[] data) { outputRange.put(data); });
In recent compiler versions we can just write:
x.toString(data => outputRange.put(data));
No need for the extra function, just call:
x.toString(&(outputRange.put));
Re: Program logic bugs vs input/environmental errors
On Saturday, 1 November 2014 at 03:39:02 UTC, Walter Bright wrote: Those are environmental errors, not programming bugs, and asserting for those conditions is the wrong approach. The point is this: what happens in the transaction engine matters, what happens outside of it does not matter much. Asserts do not belong in release code at all...
Re: Program logic bugs vs input/environmental errors
On 10/31/2014 5:38 PM, "Ola Fosheim Grøstad" " wrote: Transactions roll back when there is contention for resources and/or when you have any kind of integrity issue. That's why you have retries… so no, it is not only something wrong with the input. Something is temporarily wrong with the situation overall. Those are environmental errors, not programming bugs, and asserting for those conditions is the wrong approach.
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 21:43:26 UTC, eles wrote: it would seem to make sense to make them all const by default, and one would have to specifically mark as mutable those that would be changed. Yes, I think that would be interesting. I also thought about the possibility of putting all mutable parameters to the left of a dot-operator, but it takes some time getting used to (not sure if I could get used to it): (arr1,arr2).swap_range(10,20); arr1.merge(arr2); //merge by copy (arr1,arr2).merge; // merge by moving -- Why not make all pointer declarations as constant by default? Then, you explicitely ask for a mutable reference (hell, you could even limit the number of mutable references that could be asked for, if you want). Just reformulate to say: I think immutable/const by default is the best option. It is primarily in loops that mutable is needed and since mutables are more likely to cause bugs it would be nice to have some attention drawn to them.
Re: Program logic bugs vs input/environmental errors
On Friday, 31 October 2014 at 21:33:22 UTC, H. S. Teoh via Digitalmars-d wrote: You're using a different definition of "component". An inconsistency in a transaction is a problem with the input, not a problem with the program logic itself. If something is wrong with the input, the program can detect it and recover by aborting the transaction (rollback the wrong data). Transactions roll back when there is contention for resources and/or when you have any kind of integrity issue. That's why you have retries… so no, it is not only something wrong with the input. Something is temporarily wrong with the situation overall.
Re: DIP67: Associative Ranges
On Saturday, 1 November 2014 at 00:04:18 UTC, Jakob Ovrum wrote: On Tuesday, 28 October 2014 at 22:44:32 UTC, Freddy wrote: http://wiki.dlang.org/DIP67 Abstraction over the build-in associative array(one type of range for containers and another type for dynamic generators). Plese criticize. Any examples of what this actually accomplishes? Maybe an example of an algorithm that can do something useful with these primitives? A rationale for why these are the chosen primitives? As the proposed "associative range" isn't consumable like other ranges, this seems more like a specific kind of *container*, not a *range*; indeed the text of the DIP seems to conflate the concepts, but they are separate by necessity. Note that opIndex and opBinaryRight are already container primitives (see std.container). There's also the additional relevant primitive `removeKey`. Beyond that though, associative containers could need some more fleshing out in the container concept. As it is, I think this proposal suffers both from lack of substance and confusing terminology. The pull request has already been denied. I didn't know about std.container's definitions. They can't be consumable, built-in associative arrays overload foreach(key,value;array) adding input range primitives would conflict.
Re: DIP67: Associative Ranges
On Saturday, 1 November 2014 at 00:04:18 UTC, Jakob Ovrum wrote: ... opIndex and opBinaryRight are already container ... Correction: opBinaryRight!"in"
Re: DIP67: Associative Ranges
On Tuesday, 28 October 2014 at 22:44:32 UTC, Freddy wrote: http://wiki.dlang.org/DIP67 Abstraction over the build-in associative array(one type of range for containers and another type for dynamic generators). Plese criticize. Any examples of what this actually accomplishes? Maybe an example of an algorithm that can do something useful with these primitives? A rationale for why these are the chosen primitives? As the proposed "associative range" isn't consumable like other ranges, this seems more like a specific kind of *container*, not a *range*; indeed the text of the DIP seems to conflate the concepts, but they are separate by necessity. Note that opIndex and opBinaryRight are already container primitives (see std.container). There's also the additional relevant primitive `removeKey`. Beyond that though, associative containers could need some more fleshing out in the container concept. As it is, I think this proposal suffers both from lack of substance and confusing terminology.
Re: Program logic bugs vs input/environmental errors
On 10/31/2014 2:31 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Oct 31, 2014 at 09:11:53PM +, Kagamin via Digitalmars-d wrote: On Friday, 31 October 2014 at 20:33:54 UTC, H. S. Teoh via Digitalmars-d wrote: You are misrepresenting Walter's position. His whole point was that once a single component has detected a consistency problem within itself, it can no longer be trusted to continue operating and therefore must be shutdown. That, in turn, leads to the conclusion that your system design must include multiple, redundant, independent modules that perform that one function. *That* is the real answer to system reliability. In server software such component is a transaction/request. They are independent. You're using a different definition of "component". An inconsistency in a transaction is a problem with the input, not a problem with the program logic itself. If something is wrong with the input, the program can detect it and recover by aborting the transaction (rollback the wrong data). But if something is wrong with the program logic itself (e.g., it committed the transaction instead of rolling back when it detected a problem) there is no way to recover within the program itself. Pretending that a failed component can somehow fix itself is a fantasy. Traditionally a failed transaction is indeed rolled back. It's more a business logic requirement because a partially completed operation would confuse the user. Again, you're using a different definition of "component". A failed transaction is a problem with the data -- this is recoverable to some extent (that's why we have the ACID requirement of databases, for example). For this purpose, you vet the data before trusting that it is correct. If the data verification fails, you reject the request. This is why you should never use assert to verify data -- assert is for checking the program's own consistency, not for checking the validity of data that came from outside. A failed component, OTOH, is a problem with program logic. You cannot recover from that within the program itself, since its own logic has been compromised. You *can* rollback the wrong changes made to data by that malfunctioning program, of course, but the rollback must be done by a decoupled entity outside of that program. Otherwise you might end up causing even more problems (for example, due to the compromised / malfunctioning logic, the program commits the data instead of reverting it, thus turning an intermittent problem into a permanent one). This is a good summation of the situation.
Re: toString refactor in druntime
On Fri, Oct 31, 2014 at 02:57:58PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 10/31/14 2:11 PM, H. S. Teoh via Digitalmars-d wrote: > >On Fri, Oct 31, 2014 at 02:01:50PM -0700, Walter Bright via Digitalmars-d > >wrote: > >>On 10/31/2014 12:07 PM, H. S. Teoh via Digitalmars-d wrote: > >>>On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via Digitalmars-d > >>>wrote: > On 10/27/2014 12:42 AM, Benjamin Thaut wrote: > >I'm planning on doing a pull request for druntime which rewrites > >every toString function within druntime to use the new sink > >signature. That way druntime would cause a lot less allocations > >which end up beeing garbage right away. Are there any objections > >against doing so? Any reasons why such a pull request would not > >get accepted? > > Why a sink version instead of an Output Range? > >>> > >>>To allow toString to be a virtual function, perhaps? > >> > >>Output ranges can be virtual functions. All an output range is is a > >>type with a "put" method. > > > >The problem is that you don't know the type of the output range in > >advance. So you'd have to templatize toString. Which means it can no > >longer be virtual. > > Yah, for such stuff a delegate that takes a const(char)[] comes to > mind. -- [...] Which is what the sink version of toString currently does. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: toString refactor in druntime
On Friday, 31 October 2014 at 19:09:28 UTC, H. S. Teoh via
Digitalmars-d wrote:
Besides, the sink version basically allows encapsulation of an
output
range -- instead of calling x.toString(outputRange) you just
write:
x.toString((const(char)[] data) { outputRange.put(data); });
In recent compiler versions we can just write:
x.toString(data => outputRange.put(data));
Re: toString refactor in druntime
On 10/31/14 2:11 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Oct 31, 2014 at 02:01:50PM -0700, Walter Bright via Digitalmars-d wrote: On 10/31/2014 12:07 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via Digitalmars-d wrote: On 10/27/2014 12:42 AM, Benjamin Thaut wrote: I'm planning on doing a pull request for druntime which rewrites every toString function within druntime to use the new sink signature. That way druntime would cause a lot less allocations which end up beeing garbage right away. Are there any objections against doing so? Any reasons why such a pull request would not get accepted? Why a sink version instead of an Output Range? To allow toString to be a virtual function, perhaps? Output ranges can be virtual functions. All an output range is is a type with a "put" method. The problem is that you don't know the type of the output range in advance. So you'd have to templatize toString. Which means it can no longer be virtual. Yah, for such stuff a delegate that takes a const(char)[] comes to mind. -- Andrei
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 13:42:53 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 31 October 2014 at 13:16:17 UTC, eles wrote:
Something that I read here:
https://news.ycombinator.com/item?id=7650917
My feeling too.
If you need more owners for a resource, then explicitly ask
for.
Thank you for sharing, a very interesting discussion topic.
Just skimming over this:
http://dlang.org/const-faq.html#const-parameters
it would seem to make sense to make them all const by default,
and one would have to specifically mark as mutable those that
would be changed. The problems with this are:
It would be a huge break from past D practice, and practice
in C, C++, Java, C#, etc.
-- Actually, this is the sole reason, but the breakage would be
far less that the breakage introduced by Rust & co. The two
reasons that follow are almost hypocrisy to justify the fear in
point 1.
It would require a new keyword, say mutable.
-- Big deal. C++ has mutable too.
And worst, it would make declarations inconsistent:
void foo(int* p)
{
int* q;
...
}
p points to const, and q points to mutable. This kind of
inconsistency leads to all sorts of mistakes. It also makes it
very hard to write generic code that deals with types.
-- Why not make all pointer declarations as constant by default?
Then, you explicitely ask for a mutable reference (hell, you
could even limit the number of mutable references that could be
asked for, if you want). Just reformulate to say:
"p points to const, and q points to const. This kind of
consistency leads to all kind of great code. It also makes it
very easy to write generic code that deals with types."
Re: Less Code Bloat from Templates
On Friday, 31 October 2014 at 20:06:57 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Oct 31, 2014 at 07:47:29PM +, deadalnix via Digitalmars-d wrote: That is basically generic à la java. I'd like to see what can be done in term of library on that front as I suspect that we can get quite far. What would be more interesting IMO, is to explore ways of automating this so that a fully-generic template can be factored out into type-dependent parts and type-independent parts. While type erasure is advantageous in some circumstances, they are problematic in other circumstances. Similarly, while D's full templating system works well where type erasure is lacking, it also suffers from template bloat. Ideally, the best of both worlds should lie somewhere in between. T Compiler have some capability to merge identical IR, and linker identical codegen. But that tend to be expensive, and going the type erasure road is a worthwhile option in many cases.
Re: Program logic bugs vs input/environmental errors
On Fri, Oct 31, 2014 at 09:11:53PM +, Kagamin via Digitalmars-d wrote: > On Friday, 31 October 2014 at 20:33:54 UTC, H. S. Teoh via Digitalmars-d > wrote: > >You are misrepresenting Walter's position. His whole point was that > >once a single component has detected a consistency problem within > >itself, it can no longer be trusted to continue operating and > >therefore must be shutdown. That, in turn, leads to the conclusion > >that your system design must include multiple, redundant, independent > >modules that perform that one function. *That* is the real answer to > >system reliability. > > In server software such component is a transaction/request. They are > independent. You're using a different definition of "component". An inconsistency in a transaction is a problem with the input, not a problem with the program logic itself. If something is wrong with the input, the program can detect it and recover by aborting the transaction (rollback the wrong data). But if something is wrong with the program logic itself (e.g., it committed the transaction instead of rolling back when it detected a problem) there is no way to recover within the program itself. > >Pretending that a failed component can somehow fix itself is a > >fantasy. > > Traditionally a failed transaction is indeed rolled back. It's more a > business logic requirement because a partially completed operation > would confuse the user. Again, you're using a different definition of "component". A failed transaction is a problem with the data -- this is recoverable to some extent (that's why we have the ACID requirement of databases, for example). For this purpose, you vet the data before trusting that it is correct. If the data verification fails, you reject the request. This is why you should never use assert to verify data -- assert is for checking the program's own consistency, not for checking the validity of data that came from outside. A failed component, OTOH, is a problem with program logic. You cannot recover from that within the program itself, since its own logic has been compromised. You *can* rollback the wrong changes made to data by that malfunctioning program, of course, but the rollback must be done by a decoupled entity outside of that program. Otherwise you might end up causing even more problems (for example, due to the compromised / malfunctioning logic, the program commits the data instead of reverting it, thus turning an intermittent problem into a permanent one). T -- By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth
Re: Program logic bugs vs input/environmental errors
On Friday, 31 October 2014 at 20:33:54 UTC, H. S. Teoh via Digitalmars-d wrote: You are misrepresenting Walter's position. His whole point was that once a single component has detected a consistency problem within itself, it can no longer be trusted to continue operating and therefore must be shutdown. That, in turn, leads to the conclusion that your system design must include multiple, redundant, independent modules that perform that one function. *That* is the real answer to system reliability. In server software such component is a transaction/request. They are independent. Pretending that a failed component can somehow fix itself is a fantasy. Traditionally a failed transaction is indeed rolled back. It's more a business logic requirement because a partially completed operation would confuse the user.
Re: toString refactor in druntime
On Fri, Oct 31, 2014 at 02:01:50PM -0700, Walter Bright via Digitalmars-d wrote: > On 10/31/2014 12:07 PM, H. S. Teoh via Digitalmars-d wrote: > >On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via Digitalmars-d > >wrote: > >>On 10/27/2014 12:42 AM, Benjamin Thaut wrote: > >>>I'm planning on doing a pull request for druntime which rewrites > >>>every toString function within druntime to use the new sink > >>>signature. That way druntime would cause a lot less allocations > >>>which end up beeing garbage right away. Are there any objections > >>>against doing so? Any reasons why such a pull request would not get > >>>accepted? > >> > >>Why a sink version instead of an Output Range? > > > >To allow toString to be a virtual function, perhaps? > > Output ranges can be virtual functions. All an output range is is a > type with a "put" method. The problem is that you don't know the type of the output range in advance. So you'd have to templatize toString. Which means it can no longer be virtual. T -- Дерево держится корнями, а человек - друзьями.
Re: Program logic bugs vs input/environmental errors
On Fri, Oct 31, 2014 at 08:23:04PM +, Kagamin via Digitalmars-d wrote: > On Friday, 24 October 2014 at 18:47:59 UTC, H. S. Teoh via Digitalmars-d > wrote: > >Basically, if you want a component to recover from a serious problem > >like a failed assertion, the recovery code should be in a *separate* > >component. Otherwise, if the recovery code is within the failing > >component, you have no way to know if the recovery code itself has > >been compromised, and trusting that it will do the right thing is > >very dangerous (and is what often leads to nasty security exploits). > >The watcher must be separate from the watched, otherwise how can you > >trust the watcher? > > You make process isolation sound like a silver bullet, but failure can > happen on any scale from a temporary variable to global network. You > can't use process isolation to contain a failure of a larger than > process scale, and it's an overkill for a failure of a temporary > variable scale. You're missing the point. The point is that a reliable system made of unreliable parts, can only be reliable if you have multiple *redundant* copies of each component that are *decoupled* from each other. The usual unit of isolation at the lowest level is that of a single process, because threads within a process has full access to memory shared by all threads. Therefore, they are not decoupled from each other, and therefore, you cannot put any confidence in the correct functioning of other threads once a single thread has become inconsistent. The only failsafe solution is to have multiple redundant processes, so when one process becomes inconsistent, you fallback to another process, *decoupled* process that is known to be good. This does not mean that process isolation is a "silver bullet" -- I never said any such thing. The same reasoning applies to larger components in the system as well. If you have a server that performs function X, and the server begins to malfunction, you cannot expect the server to fix itself -- because you don't know if a hacker hasn't rooted the server and is running exploit code instead of your application. The only 100% safe way to recover, is to have another redundant server (or more) that also performs function X, shutdown the malfunctioning server for investigation and repair, and in the meantime switch over to the redundant server to continue operations. You don't shutdown the *entire* network unless all redundant components have failed. The reason you cannot go below the process level as a unit of redundancy is because of coupling. The above design of failing over to a redundant module only works if the modules are completely decoupled from each other. Otherwise, you have end up with the situation where you have two redundant modules M1 and M2, but both of them share a common helper module M3. Then if M1 detects a problem, you cannot be 100% sure it's not caused by a problem with M3, so in this case if you just switch to M2, it will also fail in the same way. Similarly, you cannot guarantee that while malfunctioning, M1 may have somehow damaged M3, and thereby also making M2 unreliable. The only way to be 100% sure that failover will actually fix the problem, is to make sure that M1 and M2 are completely isolated from each other (e.g., by having two redundant copies of M3 that are isolated from each other). Since a single process is the unit of isolation in the OS, you can't go below this granularity: as I've already said, if one thread is malfunctioning, it may have trashed the data shared by all other threads in the same process, and therefore none of the other threads can be trusted to continue operating correctly. The only way to be 100% sure that failover will actually fix the problem, is to switch over to another process that you *know* is not coupled to the old, malfunctioning process. Attempting to have a process "fix itself" after detecting an inconsistency is unreliable -- you're leaving it up to chance whether or not the attempted recovery will actually work, and not make the problem worse. You cannot guarantee the recovery code itself hasn't been compromised by the failure -- because the recovery code exists in the same process and is vulnerable to the same problem that caused the original failure, and vulnerable to memory corruption caused by malfunctioning code prior to the point the problem was detected. Therefore, the recovery code is not trustworthy, and cannot be relied on to continue operating correctly. That kind of "maybe, maybe not" recovery is not what I'd want to put any trust in, especially when it comes to critical applications that can cost lives if things go wrong. T -- English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan
Re: toString refactor in druntime
On 10/31/2014 12:07 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via Digitalmars-d wrote:
On 10/27/2014 12:42 AM, Benjamin Thaut wrote:
I'm planning on doing a pull request for druntime which rewrites
every toString function within druntime to use the new sink
signature. That way druntime would cause a lot less allocations which
end up beeing garbage right away. Are there any objections against
doing so? Any reasons why such a pull request would not get accepted?
Why a sink version instead of an Output Range?
To allow toString to be a virtual function, perhaps?
Output ranges can be virtual functions. All an output range is is a type with a
"put" method.
Besides, the sink version basically allows encapsulation of an output
range
The point of an output range is to encapsulate and abstract. Putting another
wrapper around it just gives the impression we don't know what we're doing.
-- instead of calling x.toString(outputRange) you just write:
x.toString((const(char)[] data) { outputRange.put(data); });
Most of the time, you don't even need to bother with this, because given
an output range, formattedWrite("%s"...) will automatically figure out
which overload of toString to call and what arguments to pass to it.
What I object to with the sink design is there is no consistency in design - we
cannot preach ranges as a best practice and then use some other methodology.
BTW, just to be clear, I applaud fixing druntime to remove unnecessary GC
allocations, and agree that with proper design most of the allocations can go
away. It's just that sink and output ranges are both designed to solve the same
problem in pretty much the same way. The difference appears to be little more
than tomayto tomahto.
Re: toString refactor in druntime
On Friday, 31 October 2014 at 11:42:05 UTC, Steven Schveighoffer wrote: On 10/31/14 4:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: On Thursday, 30 October 2014 at 20:15:36 UTC, Steven Schveighoffer wrote: I think the above result is deceptive, and the test isn't very useful. The RuntimeString toString isn't a very interesting data point -- it's simply a single string. Not many cases are like that. Most types have multiple members, and it's the need to *construct* a string from that data which is usually the issue. But I would caution, the whole point of my query was about data on the platforms of which Manu speaks. That is, platforms that have issues dealing with virtual calls. x86 doesn't seem to be one of them. OTOH, ArrayOfStrings shows that allocating is worse by several orders of magnitudes. This will not change on any architecture. And the simple sink variant is still faster than the rest by almost an order of magnitude, this may also be unlikely to be much different on these architectures. I find it hard to believe that the delegate version is going to be slower than the memory version on any architecture also. But I must defer to Manu as the expert in those architectures. This is why I asked for a test. The presented data is useful, but not for the purpose of my query. I need to know if it performs bad on these platforms, not how it performs on x86. We should be willing to entertain other proposals for how toString should work, but not if it's proven that what we have will suffice. It should be possible to perform such a test without D support. In any case, I think there is still room for improvement inside the implementations of toString as has been mentioned. -Steve I wrote a Windows CE app to run on our printers here at HP to test what the Microsoft ARM compiler does with virtual function calls. I had to do an operation with a global volatile variable to prevent the compiler from inlining the non-virtual function call but I finally got it to work. Calling the function 100 million times yielded the following times: Windows Compiler on ARM (Release) --- NonVirtual: 0.537000 seconds Virtual : 1.281000 seconds Windows Compiler on x86 (Release) --- NonVirtual: 0.226000 seconds Virtual : 0.226000 seconds Windows Compiler on x86 (Debug) --- NonVirtual: 2.94 seconds Virtual : 3.204000 seconds Here's the link to the code: http://marler.info/virtualtest.c
Re: Program logic bugs vs input/environmental errors
On Fri, Oct 31, 2014 at 08:15:17PM +, Kagamin via Digitalmars-d wrote: > On Thursday, 16 October 2014 at 19:53:42 UTC, Walter Bright wrote: > >On 10/15/2014 12:19 AM, Kagamin wrote: > >>Sure, software is one part of an airplane, like a thread is a part > >>of a process. When the part fails, you discard it and continue > >>operation. In software it works by rolling back a failed > >>transaction. An airplane has some tricks to recover from failures, > >>but still it's a "no fail" design you argue against: it shuts down > >>parts one by one when and only when they fail and continues > >>operation no matter what until nothing works and even then it still > >>doesn't fail, just does nothing. The airplane example works against > >>your arguments. > > > >This is a serious misunderstanding of what I'm talking about. > > > >Again, on an airplane, no way in hell is a software system going to > >be allowed to continue operating after it has self-detected a bug. > >Trying to bend the imprecise language I use into meaning the opposite > >doesn't change that. > > To better depict the big picture as I see it: > > You suggest that a system should shutdown as soon as possible on first > sign of failure, which can affect the system. > > You provide the hospital in a hurricane example. But you don't praise > the hospitals, which shutdown on failure, you praise the hospital, > which continues to operate in face of an unexpected and uncontrollable > disaster in total contradiction with your suggestion to shutdown ASAP. > > You refer to airplane's ability to not shutdown ASAP and continue > operation on unexpected failure as if it corresponds to your > suggestion to shutdown ASAP. This makes no sense, you contradict > yourself. You are misrepresenting Walter's position. His whole point was that once a single component has detected a consistency problem within itself, it can no longer be trusted to continue operating and therefore must be shutdown. That, in turn, leads to the conclusion that your system design must include multiple, redundant, independent modules that perform that one function. *That* is the real answer to system reliability. Pretending that a failed component can somehow fix itself is a fantasy. The only way you can be sure you are not making the problem worse is by having multiple redundant units that can perform each other's function. Then when one of the units is known to be malfunctioning, you turn it off and fallback to one of the other, known-to-be-good, components. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: Program logic bugs vs input/environmental errors
On Friday, 24 October 2014 at 18:47:59 UTC, H. S. Teoh via Digitalmars-d wrote: Basically, if you want a component to recover from a serious problem like a failed assertion, the recovery code should be in a *separate* component. Otherwise, if the recovery code is within the failing component, you have no way to know if the recovery code itself has been compromised, and trusting that it will do the right thing is very dangerous (and is what often leads to nasty security exploits). The watcher must be separate from the watched, otherwise how can you trust the watcher? You make process isolation sound like a silver bullet, but failure can happen on any scale from a temporary variable to global network. You can't use process isolation to contain a failure of a larger than process scale, and it's an overkill for a failure of a temporary variable scale.
Re: Program logic bugs vs input/environmental errors
On Thursday, 16 October 2014 at 19:53:42 UTC, Walter Bright wrote: On 10/15/2014 12:19 AM, Kagamin wrote: Sure, software is one part of an airplane, like a thread is a part of a process. When the part fails, you discard it and continue operation. In software it works by rolling back a failed transaction. An airplane has some tricks to recover from failures, but still it's a "no fail" design you argue against: it shuts down parts one by one when and only when they fail and continues operation no matter what until nothing works and even then it still doesn't fail, just does nothing. The airplane example works against your arguments. This is a serious misunderstanding of what I'm talking about. Again, on an airplane, no way in hell is a software system going to be allowed to continue operating after it has self-detected a bug. Trying to bend the imprecise language I use into meaning the opposite doesn't change that. To better depict the big picture as I see it: You suggest that a system should shutdown as soon as possible on first sign of failure, which can affect the system. You provide the hospital in a hurricane example. But you don't praise the hospitals, which shutdown on failure, you praise the hospital, which continues to operate in face of an unexpected and uncontrollable disaster in total contradiction with your suggestion to shutdown ASAP. You refer to airplane's ability to not shutdown ASAP and continue operation on unexpected failure as if it corresponds to your suggestion to shutdown ASAP. This makes no sense, you contradict yourself. Why didn't you praise hospital shutdown? Why nobody wants airplanes to dive into ocean on first suspicion? Because that's how unreliable systems work: they often stop working. And reliable systems work in a completely different way, they employ many tricks, but one big objective of these tricks is to have ability to continue operation on failure. All the effort put into airplane design with one reason: to fight against immediate shutdown, defended by you as the only true way of operation. Exactly the way explicitly rejected by real reliable systems design. How an airplane without the tricks would work? It would dive into ocean on first failure (and crash investigation team diagnoses the failure) - exactly as you suggest. That's safe: it could fall on a city or a nuclear reactor. How a real airplane works? Failure happens and it still flies, contrary to your suggestion to shutdown on failure. That's how critical missions are done: they take a risk of a greater disaster to complete the mission, and failures can be diagnosed when appropriate. That's why I think your examples contradict to your proposal.
Re: Less Code Bloat from Templates
On Fri, Oct 31, 2014 at 07:47:29PM +, deadalnix via Digitalmars-d wrote: > That is basically generic à la java. > > I'd like to see what can be done in term of library on that front > as I suspect that we can get quite far. What would be more interesting IMO, is to explore ways of automating this so that a fully-generic template can be factored out into type-dependent parts and type-independent parts. While type erasure is advantageous in some circumstances, they are problematic in other circumstances. Similarly, while D's full templating system works well where type erasure is lacking, it also suffers from template bloat. Ideally, the best of both worlds should lie somewhere in between. T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Friday, 31 October 2014 at 13:57:40 UTC, Ola Fosheim Grøstad wrote: On Friday, 31 October 2014 at 13:50:30 UTC, Andrea Fontana wrote: I wonder how linux was written in c. I think it's a rather big project to do without partial keyword. Finns are hardcore. They drink a lot. They swear a lot. And they bathe in snow after taking a whipping. Naked… And they like it… Only Linus can create Linux without partial. They are out of control https://www.youtube.com/watch?v=VWHfiEKK3zw
Re: Less Code Bloat from Templates
That is basically generic à la java. I'd like to see what can be done in term of library on that front as I suspect that we can get quite far.
Re: toString refactor in druntime
On Friday, 31 October 2014 at 19:04:29 UTC, Walter Bright wrote: On 10/27/2014 12:42 AM, Benjamin Thaut wrote: I'm planning on doing a pull request for druntime which rewrites every toString function within druntime to use the new sink signature. That way druntime would cause a lot less allocations which end up beeing garbage right away. Are there any objections against doing so? Any reasons why such a pull request would not get accepted? Why a sink version instead of an Output Range? I guess because it's for druntime, and we don't want to pull in std.range?
Re: toString refactor in druntime
On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via Digitalmars-d wrote:
> On 10/27/2014 12:42 AM, Benjamin Thaut wrote:
> >I'm planning on doing a pull request for druntime which rewrites
> >every toString function within druntime to use the new sink
> >signature. That way druntime would cause a lot less allocations which
> >end up beeing garbage right away. Are there any objections against
> >doing so? Any reasons why such a pull request would not get accepted?
>
> Why a sink version instead of an Output Range?
To allow toString to be a virtual function, perhaps?
Besides, the sink version basically allows encapsulation of an output
range -- instead of calling x.toString(outputRange) you just write:
x.toString((const(char)[] data) { outputRange.put(data); });
Most of the time, you don't even need to bother with this, because given
an output range, formattedWrite("%s"...) will automatically figure out
which overload of toString to call and what arguments to pass to it.
T
--
The only difference between male factor and malefactor is just a little
emptiness inside.
Re: toString refactor in druntime
On 10/27/2014 12:42 AM, Benjamin Thaut wrote: I'm planning on doing a pull request for druntime which rewrites every toString function within druntime to use the new sink signature. That way druntime would cause a lot less allocations which end up beeing garbage right away. Are there any objections against doing so? Any reasons why such a pull request would not get accepted? Why a sink version instead of an Output Range?
Re: DIP66 - Multiple alias this
On Tuesday, 28 October 2014 at 22:58:53 UTC, Ola Fosheim Grøstad wrote: You should rethink implementing multiple alias this. D is increasingly becoming a poorly typed language. "alias this" is basically static prototype-based programming. http://en.wikipedia.org/wiki/Prototype-based_programming Self had multiple inheritance based on prototypes and removed it because it was not much used and lead to problems when figuring out which methods were called. No. D is as poorly typed as one wants is to be and multiple alias this is a necessary tool to achieve strong static typing without sacrificing expressiveness.
Re: Deimos library interfaces needed for these
On Tuesday, 28 October 2014 at 11:39:45 UTC, John Colvin wrote: Isn't the "official" stamp worth something? If they all connected up to dub anyway it seems like a win-win, if we can get pulls merged quickly. I can hardly imagine where I'd care about such official status. Either bindings work or they don't - and with the way Deimos currently works you are more likely to expect working ones in dub. Any setup were binding author can't do all necessary changes himself is sub-optimal and too slow to be considered practical.
Re: D wrapper classes leak memory. Next steps?
On Fri, 31 Oct 2014 12:56:58 + via Digitalmars-d wrote: > Oh drat, someone is squatting my would-be website… > http://www.aa.org/ ah. just wait until they got drunk and buy it in exchange for one more shot. signature.asc Description: PGP signature
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Fri, 31 Oct 2014 13:45:37 + Wyatt via Digitalmars-d wrote: > On Friday, 31 October 2014 at 12:54:30 UTC, FrankLike wrote: > > > >> No human uses partial classes in .NET land other than the > >> tools themselves. > >> > > > > Very good,It makes your code look very simple ， nice and cool. > > > Does the inverse of the Turing test have a name? How am I > supposed to react when a human passes it? ;) just show him IOCCC. he will never return. ;-) signature.asc Description: PGP signature
Re: Slides about profiling (on Linux)
On Friday, 31 October 2014 at 15:46:45 UTC, Kiith-Sa wrote: Slides and sample code: http://defenestrate.eu/2014/10/31/profiling_on_linux.html Nice. Thanks.
Slides about profiling (on Linux)
I've been planning to write a blog post about profiling D on Linux for a while, and... while I still didn't get around to writing an actual post, I recently gave a talk/workshop about profiling/optimizing on Linux at local hackerspace. While it's aimed at the local C/C++ audience, a lot of it is relevant to D (especially perf, which works well with D - except for name mangling - I keep hearing about people using valgrind/callgrind with D but never got it to work myself). Slides and sample code: http://defenestrate.eu/2014/10/31/profiling_on_linux.html
Re: std.experimental.logger formal review round 3
On Tuesday, 28 October 2014 at 22:03:18 UTC, Martin Nowak wrote: 2nd iteration of that idea. For me it looks like the cure is worse than the disease. Simply not distributing precompiled libraries with log level force-reduced (or at least not exposing it in provided .di files) feels like a more practical approach than proposed API complication.
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Friday, 31 October 2014 at 14:03:04 UTC, eles wrote: Caught in the act... http://www.freogan.org/wp-content/uploads/2009/12/linus-torvald-speedo-300x255.jpg Nice! He's got a sauna at home too. And he does "management by cursing": http://en.wikipedia.org/wiki/Management_by_perkele
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
I work on a big C# project with forms and controls designed in both ways: some are split into partial classes, some mix generated code with user code. Can't remember any issue with it, and difference is visible only when you realize, that the code is indeed in the same file, which may or may not happen.
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Friday, 31 October 2014 at 13:57:40 UTC, Ola Fosheim Grøstad wrote: On Friday, 31 October 2014 at 13:50:30 UTC, Andrea Fontana wrote: I wonder how linux was written in c. I think it's a rather big project to do without partial keyword. Finns are hardcore. They drink a lot. They swear a lot. And they bathe in snow after taking a whipping. Naked… Caught in the act... http://www.freogan.org/wp-content/uploads/2009/12/linus-torvald-speedo-300x255.jpg
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Friday, 31 October 2014 at 13:50:30 UTC, Andrea Fontana wrote: I wonder how linux was written in c. I think it's a rather big project to do without partial keyword. Finns are hardcore. They drink a lot. They swear a lot. And they bathe in snow after taking a whipping. Naked… And they like it… Only Linus can create Linux without partial.
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Wednesday, 29 October 2014 at 12:55:01 UTC, FrankLike wrote: The same thing in D should be done,now.Otherwise，no big projects can be done like C#. Add another keyword,and update the compiler. FrankLike I wonder how linux was written in c. I think it's a rather big project to do without partial keyword.
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Friday, 31 October 2014 at 12:54:30 UTC, FrankLike wrote: No human uses partial classes in .NET land other than the tools themselves. Very good,It makes your code look very simple ， nice and cool. Does the inverse of the Turing test have a name? How am I supposed to react when a human passes it? ;) -Wyatt
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 13:16:17 UTC, eles wrote: Something that I read here: https://news.ycombinator.com/item?id=7650917 My feeling too. If you need more owners for a resource, then explicitly ask for. Thank you for sharing, a very interesting discussion topic. I am increasingly thinking that it might be possible to have a system level language where you can do progressive refinement from a garbage collection supported sketch to a hardcore real time app. Basically have different compilation modes where you start out in executable pseudo-code and gradually turn on more switches which give you performance/ownership etc warnings (integrated in the IDE). Kinda a like starting out with Python and ending up with C. D supports this a little bit, but has not been designed for it (I think).
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 10:06:51 UTC, Ola Fosheim Grøstad wrote: On Friday, 31 October 2014 at 09:58:41 UTC, ketmar via Digitalmars-d wrote: if you have something concrete in mind, write ER or forum post, so we can destroy it. ;-) - make uniqe_ptr a language builtin I would go with this by default for all pointers/references. Something that I read here: https://news.ycombinator.com/item?id=7650917 My feeling too. If you need more owners for a resource, then explicitly ask for.
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 12:31:25 UTC, Ola Fosheim Grøstad wrote: On Friday, 31 October 2014 at 12:22:56 UTC, ketmar via Digitalmars-d wrote: i bet you can find a nicely looking hieroglyph too. that would be cool for graffiti. Good point. So the logo would be "Å", it is spelled "AA", pronounced "Awe" and sorted both first and last in listings. It has to be a very minimalistic language: http://en.wikipedia.org/wiki/Angstrom Oh drat, someone is squatting my would-be website… http://www.aa.org/
Re: Is 2.066.1 released?
On 2014-10-31 13:35, Martin Nowak wrote: Andrei didn't get got to this, though I wonder why he is the one that needs to update the website. http://forum.dlang.org/post/544c4554.9070...@dawg.eu He has access to the machine? -- /Jacob Carlborg
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
No human uses partial classes in .NET land other than the tools themselves. It is a language feature introduced to simplify how Visual Studio supports round-trip editing of UI code in its designers, instead of relying in metadata files. -- Paulo Very good,It makes your code look very simple ， nice and cool. Frank
Re: Is 2.066.1 released?
On Friday, 31 October 2014 at 11:43:39 UTC, Dragos Carp wrote: github and http://downloads.dlang.org/releases/2014/ say YES, but http://dlang.org/ and http://forum.dlang.org/group/digitalmars.D.announce say NO... Andrei didn't get got to this, though I wonder why he is the one that needs to update the website. http://forum.dlang.org/post/544c4554.9070...@dawg.eu
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 12:22:56 UTC, ketmar via Digitalmars-d wrote: i bet you can find a nicely looking hieroglyph too. that would be cool for graffiti. Good point. So the logo would be "Å", it is spelled "AA", pronounced "Awe" and sorted both first and last in listings. It has to be a very minimalistic language: http://en.wikipedia.org/wiki/Angstrom
Re: D wrapper classes leak memory. Next steps?
On Fri, 31 Oct 2014 12:09:27 + via Digitalmars-d wrote: > On Friday, 31 October 2014 at 10:21:47 UTC, ketmar via > Digitalmars-d wrote: > > On Fri, 31 Oct 2014 10:06:50 + > > via Digitalmars-d wrote: > > > > p.s. and title that "Z", as "the last language you'll need > > ever. in all meanings." ;-) > > Indeed, for the english speaking world, but as a patriotic > scandinavian I'm inclined to think there are three more letters. > And I cannot have that, can I? > > In Denmark and Norway the alphabet ends with : Z, Æ, Ø, Å… > And in Sweden: Z, Å, Ä, Ö… > > So the name of the ultimate language has to be one of: > > ZÅÖ > ZÖÅ > ÅZÖ > ÅÖZ > ÖZÅ > or > ÖÅZ > > Hm… i bet you can find a nicely looking hieroglyph too. that would be cool for graffiti. signature.asc Description: PGP signature
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 12:09:29 UTC, Ola Fosheim Grøstad wrote: ZÅÖ ZÖÅ ÅZÖ ÅÖZ ÖZÅ or ÖÅZ Hm… On second thought I think I should stick to the Norwegian alphabet, but resort to old spelling rules. That will make the name of the ultimate language: "AA", pronounced "Awe": http://www.youtube.com/watch?v=BX5W8gXcAW4 And, as a bonus it will be listed first in programming language listings, such as Rosetta Code. OK. That's it. I am from now on working on a new system level programming language called "AA", pronounced "Awe" which should be sorted first in all english listings, and sorted last in all scandinavian listings. No more patches. I'm speccing!
Re: BNF grammar for D?
On 1/11/2014 12:35 a.m., Bruno Medeiros wrote: On 27/10/2014 22:35, Jeremy Powers via Digitalmars-d wrote: An interesting path to take for an intellij plugin would be to use his DCD/libdparse for all the heavy lifting, with the plugin just farming out the work to external daemon process(es). That would avoid having yet another lexer/parser implementation to keep up to date. Integrating DCD might work well, because autocompletion is used sporadically (and is invoked explicitly by the user). But parsing is probably invoked quite often by IntelliJ, and as such it could be tricky to integrate with libdparse (because you'd have to invoke an external process all the time) From my small test file with my attempt at this, its fine to call e.g. DScanner to grab the ast. Its actually pretty fast which I was a little shocked about.
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 10:21:47 UTC, ketmar via Digitalmars-d wrote: On Fri, 31 Oct 2014 10:06:50 + via Digitalmars-d wrote: p.s. and title that "Z", as "the last language you'll need ever. in all meanings." ;-) Indeed, for the english speaking world, but as a patriotic scandinavian I'm inclined to think there are three more letters. And I cannot have that, can I? In Denmark and Norway the alphabet ends with : Z, Æ, Ø, Å… And in Sweden: Z, Å, Ä, Ö… So the name of the ultimate language has to be one of: ZÅÖ ZÖÅ ÅZÖ ÅÖZ ÖZÅ or ÖÅZ Hm…
Re: BNF grammar for D?
V Fri, 31 Oct 2014 11:41:58 + Bruno Medeiros via Digitalmars-d napsáno: > On 27/10/2014 22:06, landaire wrote: > > I'm trying to make a plugin for IntelliJ IDEA to support D > > (https://github.com/landaire/intelliD is what I have now utilizing > > DDT's lexer) but a lot of what's required to add advanced features > > like code folding, code completion, etc. is generally autogenerated > > by JetBrains's Grammar Kit plugin which only generates that stuff > > from a BNF grammar. > > Nice to hear someone re-using DDT's DTool code for another tool. > (it's called DTool BTW, not plugin_tooling - that's just the > directory :P ) > > From https://github.com/landaire/intelliD: > "Backported to JDK 6 as the module made heavy use of JDK 7 and JDK 6 > or lower is required for IntelliJ plugin development" > > WUT?? That is so backwards... I even have a hard time believing that. > (I'm no IntelliJ expert so I don't know for sure what is the case). > But JDK 6 is getting quite old, 7 has been out for some time now, and > is already superseded by 8 (and 9 is being concocted as we speak - > the pace of Java changes has picked up now that Oracle took charge) > > Are you really *sure* you can't write IntelliJ plugins with Java code > using JDK 7 and above? IntelliJ is supposed to be Java IDE that is > all fresh and up-to-date! (As opposed to Eclipse, whose code base has > stagnated, I readily admit that, ;'( ) > You can write intellij idea plugins with JDK 7 or even JDK 8, but that plugins will only work with IDEA running on same version of JDK. You must use same version for IDEA SDK and for IDEA itself. Currently IDEA and all plugins are compatible with JDK 6, so this is why JDK 6 is recommended. At the moment many LTS linux distros has JDK 6 (ubuntu 12.04 LTS, RedHat/CentOS 6). But ubuntu 14.04 and readhat/centos 7 are here now, so maybe jdk7 will became recommended version soon.
Re: Is 2.066.1 released?
On Friday, 31 October 2014 at 11:53:12 UTC, Joakim wrote: On Friday, 31 October 2014 at 11:43:39 UTC, Dragos Carp wrote: github and http://downloads.dlang.org/releases/2014/ say YES, but http://dlang.org/ and http://forum.dlang.org/group/digitalmars.D.announce say NO... Heh, I was wondering about that too, looks like the latter two haven't been updated for whatever reason. I believe you can submit a pull request for the homepage. Never mind, the pull request was merged two weeks ago, the site just hasn't been updated since then: https://github.com/D-Programming-Language/dlang.org/pull/675
Re: Is 2.066.1 released?
On Friday, 31 October 2014 at 11:43:39 UTC, Dragos Carp wrote: github and http://downloads.dlang.org/releases/2014/ say YES, but http://dlang.org/ and http://forum.dlang.org/group/digitalmars.D.announce say NO... Heh, I was wondering about that too, looks like the latter two haven't been updated for whatever reason. I believe you can submit a pull request for the homepage.
Re: toString refactor in druntime
On 10/31/14 4:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: On Thursday, 30 October 2014 at 20:15:36 UTC, Steven Schveighoffer wrote: I think the above result is deceptive, and the test isn't very useful. The RuntimeString toString isn't a very interesting data point -- it's simply a single string. Not many cases are like that. Most types have multiple members, and it's the need to *construct* a string from that data which is usually the issue. But I would caution, the whole point of my query was about data on the platforms of which Manu speaks. That is, platforms that have issues dealing with virtual calls. x86 doesn't seem to be one of them. OTOH, ArrayOfStrings shows that allocating is worse by several orders of magnitudes. This will not change on any architecture. And the simple sink variant is still faster than the rest by almost an order of magnitude, this may also be unlikely to be much different on these architectures. I find it hard to believe that the delegate version is going to be slower than the memory version on any architecture also. But I must defer to Manu as the expert in those architectures. This is why I asked for a test. The presented data is useful, but not for the purpose of my query. I need to know if it performs bad on these platforms, not how it performs on x86. We should be willing to entertain other proposals for how toString should work, but not if it's proven that what we have will suffice. It should be possible to perform such a test without D support. In any case, I think there is still room for improvement inside the implementations of toString as has been mentioned. -Steve
Re: Less Code Bloat from Templates
Microsoft's linker can reduplicate templates, they call it identical comdat folding.
Is 2.066.1 released?
github and http://downloads.dlang.org/releases/2014/ say YES, but http://dlang.org/ and http://forum.dlang.org/group/digitalmars.D.announce say NO...
Re: BNF grammar for D?
On 27/10/2014 22:06, landaire wrote: I'm trying to make a plugin for IntelliJ IDEA to support D (https://github.com/landaire/intelliD is what I have now utilizing DDT's lexer) but a lot of what's required to add advanced features like code folding, code completion, etc. is generally autogenerated by JetBrains's Grammar Kit plugin which only generates that stuff from a BNF grammar. Nice to hear someone re-using DDT's DTool code for another tool. (it's called DTool BTW, not plugin_tooling - that's just the directory :P ) From https://github.com/landaire/intelliD: "Backported to JDK 6 as the module made heavy use of JDK 7 and JDK 6 or lower is required for IntelliJ plugin development" WUT?? That is so backwards... I even have a hard time believing that. (I'm no IntelliJ expert so I don't know for sure what is the case). But JDK 6 is getting quite old, 7 has been out for some time now, and is already superseded by 8 (and 9 is being concocted as we speak - the pace of Java changes has picked up now that Oracle took charge) Are you really *sure* you can't write IntelliJ plugins with Java code using JDK 7 and above? IntelliJ is supposed to be Java IDE that is all fresh and up-to-date! (As opposed to Eclipse, whose code base has stagnated, I readily admit that, ;'( ) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: toString refactor in druntime
On Tuesday, 28 October 2014 at 23:06:32 UTC, Manu via Digitalmars-d wrote: Video games consoles are very real, and very now. What architecture/platform? The indirect function call argument seems a bit displaced for toString. This puts the burden on the caller to ensure enough space is allocated. Or you have to reenter the function to finish up the output. Neither of these seem like acceptable drawbacks. Well that's why I open for discussion. I'm sure there's room for creativity here. Well the obvious alternative is a printf style return, that tells you how much space is needed. It doesn't seem that unreasonable to reenter the function to me actually, I'd prefer a second static call in the rare event that a buffer wasn't big enough, Second virtual call ;).
Re: BNF grammar for D?
On 27/10/2014 22:35, Jeremy Powers via Digitalmars-d wrote: An interesting path to take for an intellij plugin would be to use his DCD/libdparse for all the heavy lifting, with the plugin just farming out the work to external daemon process(es). That would avoid having yet another lexer/parser implementation to keep up to date. Integrating DCD might work well, because autocompletion is used sporadically (and is invoked explicitly by the user). But parsing is probably invoked quite often by IntelliJ, and as such it could be tricky to integrate with libdparse (because you'd have to invoke an external process all the time) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Friday, 31 October 2014 at 09:30:26 UTC, Dejan Lekic wrote: On Wednesday, 29 October 2014 at 12:55:01 UTC, FrankLike wrote: The same thing in D should be done,now.Otherwise，no big projects can be done like C#. Add another keyword,and update the compiler. This certainly made me laugh... I work on a very big project (Java / JBoss / Swing) and we do not use C#'s partial as Java does not have it. :) Even if it does we would not use it as we prefer our classes to be in a single file. In D apps I work on I prefer all my classes in a single module, as is common "D way", or shall I call it "modular way"? No human uses partial classes in .NET land other than the tools themselves. It is a language feature introduced to simplify how Visual Studio supports round-trip editing of UI code in its designers, instead of relying in metadata files. -- Paulo
Re: BNF grammar for D?
On 27/10/2014 22:53, landaire wrote: On Monday, 27 October 2014 at 22:43:55 UTC, Jeremy Powers via Digitalmars-d wrote: From my mucking about before, I think you'll get more mileage from using libdparse directly than trying to (re)implement a parser for the plugin. For one, you save yourself all the pain of fixing weird edge cases and keeping up to date. I agree, but integrating something external with IntelliJ's platform seems like kind of a PITA. It looks like a lot of stuff makes heavy use of PSI trees (see: https://confluence.jetbrains.com/display/IDEADEV/Developing+Custom+Language+Plugins+for+IntelliJ+IDEA#DevelopingCustomLanguagePluginsforIntelliJIDEA-ImplementingaParserandPSI) I'm no expert in developing IntelliJ plugins either though... Have you considered the option of creating a Psi parser than creates PsiElements from the AST parsed by DDT's DTool ? That would should be fairly straightforward. With of a fork of DDT/Dtool, you can even easily modify the DDT/Dtool parser to generate those PsiElements directly. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: toString refactor in druntime
On Tuesday, 28 October 2014 at 21:32:14 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 28 Oct 2014 08:37:43 -0400
I think a few simple functions can suffice for druntime's
purposes. We don't need a kitchen sink function (pun intended).
ah, those famous last words... ;-) from my observations it's
enough to
implement '%[+-]width[.maxlen]s' and the same for '%x'. i also
added
codes to skip arguments and to print all what's left ('%*').
i'm sure
that it can be done in <10KB, and it will be very handy to have.
druntime doesn't do alot of printing and string conversions
anyway. and
phobos is already ridden with templates and CTFE.
https://github.com/D-Programming-Language/druntime/pull/662
Re: toString refactor in druntime
On Monday, 27 October 2014 at 07:42:30 UTC, Benjamin Thaut wrote: Any reasons why such a pull request would not get accepted? I did that for the exception hierarchy and sure would accept that for TypeInfo. Not so sure about Object itself, as it would nail down the API.
Re: C++ developer choices in open source projects
3.0_miles vs 3.0_km Sure you could have done it this way instead: miles(3.0) vs km(3.0) But people don't, so providing literals is a good addition for C++. (And no, string processing at compile time is not a good idea! It suffers from the same problems as macros.) UDL is a nice feature yah
Re: D wrapper classes leak memory. Next steps?
On Fri, 31 Oct 2014 10:06:50 + via Digitalmars-d wrote: p.s. and title that "Z", as "the last language you'll need ever. in all meanings." ;-) signature.asc Description: PGP signature
Re: D wrapper classes leak memory. Next steps?
On Fri, 31 Oct 2014 10:06:50 + via Digitalmars-d wrote: > On Friday, 31 October 2014 at 09:58:41 UTC, ketmar via > Digitalmars-d wrote: > > if you have something concrete in mind, write ER or forum post, > > so we can destroy it. ;-) > > Sure! > > - dump the gc > > - make uniqe_ptr a language builtin > > - ditch c malloc > > - make compiler 100% memory management aware > > - make thread aware high speed class allocators a builtin > > - ditch emplace > > - default pointers to non-nullable > > - do a complete redesign of phobos > > I'm sure there is more… send your patches! ;-) signature.asc Description: PGP signature
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 09:58:41 UTC, ketmar via Digitalmars-d wrote: if you have something concrete in mind, write ER or forum post, so we can destroy it. ;-) Sure! - dump the gc - make uniqe_ptr a language builtin - ditch c malloc - make compiler 100% memory management aware - make thread aware high speed class allocators a builtin - ditch emplace - default pointers to non-nullable - do a complete redesign of phobos I'm sure there is more…
Re: D wrapper classes leak memory. Next steps?
On Fri, 31 Oct 2014 10:53:27 +0100 Marco Leise via Digitalmars-d wrote: > Am Fri, 31 Oct 2014 10:51:04 +0200 > schrieb ketmar via Digitalmars-d : > > > On Fri, 31 Oct 2014 09:46:54 +0100 > > Marco Leise via Digitalmars-d wrote: > > > > > Can't blame the author when there is no other choice in the > > > language than to use tracing GC with inheritance. > > there are alot of choices. i'm succesfully using wrapper classes with > > reference counting in my i/o streams library, for example. they are GC > > roots, and they are freed in the same moment when their reference count > > becomes zero. > > I meant obvious, clean, idiomatic choices. It's clear that D's > expressiveness makes pretty much anything work if you put a > week's worth of time into it. What I'm saying is, the language > should offer something to use external resources in class > hierarchies, because it is a common need. Something that comes > with so little friction that you don't think twice. if you have something concrete in mind, write ER or forum post, so we can destroy it. ;-) > > > Which prompts the question again how to deal > > > with exceptions in dtors. > > class dtors should not throw any exceptions. stack-allocated struct > > dtors can do what they want, just catch that and you'll got "nothrow" > > function. what's the problem here? > > E-he, stack sounds nice, but those are in D's "parameter > scope". You cannot wrap their destruction in try-catch. there is no problem that can't be solved by introducing one more wrapper. ;-) signature.asc Description: PGP signature
Re: D wrapper classes leak memory. Next steps?
Am Fri, 31 Oct 2014 10:51:04 +0200 schrieb ketmar via Digitalmars-d : > On Fri, 31 Oct 2014 09:46:54 +0100 > Marco Leise via Digitalmars-d wrote: > > > Can't blame the author when there is no other choice in the > > language than to use tracing GC with inheritance. > there are alot of choices. i'm succesfully using wrapper classes with > reference counting in my i/o streams library, for example. they are GC > roots, and they are freed in the same moment when their reference count > becomes zero. I meant obvious, clean, idiomatic choices. It's clear that D's expressiveness makes pretty much anything work if you put a week's worth of time into it. What I'm saying is, the language should offer something to use external resources in class hierarchies, because it is a common need. Something that comes with so little friction that you don't think twice. > > Which prompts the question again how to deal > > with exceptions in dtors. > class dtors should not throw any exceptions. stack-allocated struct > dtors can do what they want, just catch that and you'll got "nothrow" > function. what's the problem here? E-he, stack sounds nice, but those are in D's "parameter scope". You cannot wrap their destruction in try-catch. -- Marco
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Fri, 31 Oct 2014 09:30:25 + Dejan Lekic via Digitalmars-d wrote: > On Wednesday, 29 October 2014 at 12:55:01 UTC, FrankLike wrote: > > > > The same thing in D should be done,now.Otherwise，no big > > projects can be done like C#. Add another keyword,and update > > the compiler. > > This certainly made me laugh... I work on a very big project > (Java / JBoss / Swing) and we do not use C#'s partial as Java > does not have it. :) Even if it does we would not use it as we > prefer our classes to be in a single file. > > In D apps I work on I prefer all my classes in a single module, > as is common "D way", or shall I call it "modular way"? each new generation of programmers tend to believe that there will be no success to languages other than that one they learned unless other languages becomes feature-to-feature clones of The One Language. it's ok, they will learn other languages sooner or later and will start to hate them all. ;-) signature.asc Description: PGP signature
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
On Wednesday, 29 October 2014 at 12:55:01 UTC, FrankLike wrote: The same thing in D should be done,now.Otherwise，no big projects can be done like C#. Add another keyword,and update the compiler. This certainly made me laugh... I work on a very big project (Java / JBoss / Swing) and we do not use C#'s partial as Java does not have it. :) Even if it does we would not use it as we prefer our classes to be in a single file. In D apps I work on I prefer all my classes in a single module, as is common "D way", or shall I call it "modular way"?
Re: C++ developer choices in open source projects
On Thursday, 30 October 2014 at 20:06:30 UTC, H. S. Teoh via Digitalmars-d wrote: D had it right by moving all these user-defined literals into strings that are parsed at compile-time. Much more powerful than the crippled stuff operator""() can accept, and far less dangerous and lightyears more maintainable. I believe there are examples of system software going wrong because one library used SI units and another one did not. So being able to typecast doubles into something more restricted is useful: 3.0_miles vs 3.0_km Sure you could have done it this way instead: miles(3.0) vs km(3.0) But people don't, so providing literals is a good addition for C++. (And no, string processing at compile time is not a good idea! It suffers from the same problems as macros.)
Re: Increasing D's visibility
On Thursday, 30 October 2014 at 17:11:40 UTC, First Try wrote: On Thursday, 30 October 2014 at 16:48:23 UTC, Gary Willoughby wrote: On Thursday, 30 October 2014 at 13:04:26 UTC, First Try wrote: 1.) ADD Windows import of the C headers. 2.) ADD libraries such as Database and Gui 3.) Get a Scanner/Parser Generator going such as Antlr or Coco/r For now I had to deinstall 'D' again and i guess a lot of other people will do the same. These are all already available. If it wouldn't be impolite, i'd say that you are full of shit. You are betraying people into believing that crap and because of people like you, they will waste a lot of time. All to be found is half-baked stuff - most of it abandoned and as for the windows header files of D, they are utterly incomplete and not usable for 64 bit (Dsource). Ignore Dsource. Look at http://code.dlang.org/ http://code.dlang.org/search?q=windows http://code.dlang.org/search?q=gui (does not match GtkD, though) http://code.dlang.org/search?q=database http://code.dlang.org/search?q=parsing If not found there, ask in the D.learn forum.
Re: C++ developer choices in open source projects
It's probably a good thing they don't know what C++11 is, otherwise they might start writing even more horrendous code using operator""(). I suppose I've been a frog in the well, but it was only yesterday when I discovered that C++11 allows user-defined literals via operator""(). Skimming over the docs for that today, I couldn't help but shake my head at just how wrong the whole conception of it is. It's just *asking* to be abused for writing inscrutable, unreadable, unmaintainable code. I honestly have trouble imagining any sane use case for it apart from submitting obfuscated code contest entries. But hey, what's one more nail in a coffin already crawling with monstrosities like Boost.Xpressive? Yeah, who cares about language extensibility or useful features. These all beg to be abused. Let's all use Go instead.
Re: D wrapper classes leak memory. Next steps?
On Fri, 31 Oct 2014 09:46:54 +0100 Marco Leise via Digitalmars-d wrote: > Can't blame the author when there is no other choice in the > language than to use tracing GC with inheritance. there are alot of choices. i'm succesfully using wrapper classes with reference counting in my i/o streams library, for example. they are GC roots, and they are freed in the same moment when their reference count becomes zero. > Which prompts the question again how to deal > with exceptions in dtors. class dtors should not throw any exceptions. stack-allocated struct dtors can do what they want, just catch that and you'll got "nothrow" function. what's the problem here? signature.asc Description: PGP signature
Re: toString refactor in druntime
On Thursday, 30 October 2014 at 20:15:36 UTC, Steven Schveighoffer wrote: I think the above result is deceptive, and the test isn't very useful. The RuntimeString toString isn't a very interesting data point -- it's simply a single string. Not many cases are like that. Most types have multiple members, and it's the need to *construct* a string from that data which is usually the issue. But I would caution, the whole point of my query was about data on the platforms of which Manu speaks. That is, platforms that have issues dealing with virtual calls. x86 doesn't seem to be one of them. OTOH, ArrayOfStrings shows that allocating is worse by several orders of magnitudes. This will not change on any architecture. And the simple sink variant is still faster than the rest by almost an order of magnitude, this may also be unlikely to be much different on these architectures.
Re: D wrapper classes leak memory. Next steps?
Am Fri, 31 Oct 2014 06:44:48 +0200 schrieb ketmar via Digitalmars-d : > On Fri, 31 Oct 2014 05:38:48 +0100 > Marco Leise via Digitalmars-d wrote: > > > GtkD wraps all the objects in Gtk. In callbacks like "onDraw", > > when they are called often, this creates heaps of tiny wrapper > > objects around huge data from C libraries. Eventually system > > memory is exhausted and the computer slows down and eats into > > swap. So should we add a "run garbage collector" button to > > every application to clean those up? Seems rather silly. > > > > The GC should stick to its own memory and not try to manage > > resources it doesn't understand. Reference counting applies to > > external and system resources much better. To date neither the > > language nor Phobos can ref count classes. And even with > > library support it is not likely that it will get used widely, > > because plain classes are so much easier (also on the eyes). > > > > The extent of this is pretty huge. There are many D wrapper > > libraries that build on classes and mimic what is available > > for C++ or Python. Issues like this make D appear like a toy > > language. How would one write a big desktop application when > > a simple animation can exhaust system memory in seconds ? > why do you blaming GC for what seems to be a library author's fault? > that was the library author who chooses to wrap externally-managed > objects in GC objects, and creating alot of throwaway classes for that. Can't blame the author when there is no other choice in the language than to use tracing GC with inheritance. > alas, we haven't Skynet at the hand to guess what author really wants. > > p.s. i was never using GtkD, so i don't know if it's really doing the > things you wrote or not, i'm just assuming that you are right. To be fair there is an overload for addOnDraw that takes a delegate that has a Scoped!Context as parameter, but I cannot use that with delegates marked as nothrow since Scoped's dtor isn't nothrow. Which prompts the question again how to deal with exceptions in dtors. All D delegates called from the C side have to be nothrow though, because neither can druntime deal with GCC's amd64 stack (omit-frame-pointer) nor is the C side necessarily prepared for exceptions. -- Marco
Re: D wrapper classes leak memory. Next steps?
On Friday, 31 October 2014 at 04:28:47 UTC, Marco Leise wrote: How would one write a big desktop application when a simple animation can exhaust system memory in seconds ? Yep, it can be a long way from PoC to a quality implementation. Write GtkD 2.0 with careful approach w.r.t. resource management. Though, reference counting may not be a silver bullet, it still requires you to not forget to clear unneeded resources. And it's of no use if the reference is in an GC-managed object. Also you can still create big resources too eagerly instead of on demand, and hold onto them for longer than needed.
Re: Increasing D's visibility
On Thursday, 30 October 2014 at 17:11:40 UTC, First Try wrote: If it wouldn't be impolite, i'd say that you are full of shit. You are betraying people into believing that crap and because of people like you, they will waste a lot of time. All to be found is half-baked stuff - most of it abandoned and as for the windows header files of D, they are utterly incomplete and not usable for 64 bit (Dsource). You ought to be ashamed of yourself. Dsource is woefully out of date and deprecated. Everything you listed have many libraries available, they work well and fully maintained. If only you had politely asked instead of shooting your mouth off, maybe somebody would of shown you where they are.
Re: Increasing D's visibility
On Thursday, 30 October 2014 at 13:04:26 UTC, First Try wrote: 1.) ADD Windows import of the C headers. 2.) ADD libraries such as Database and Gui 3.) Get a Scanner/Parser Generator going such as Antlr or Coco/r Actually, with DFL and Pegged I'm easily building Windows GUI apps now that use some parsing inside, no major problems there.
