Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
On 7/20/14, 5:57 AM, bearophile wrote:
In those slides as other member of the sum type they have used an
enumeration of possible error conditions (or at first even just strings
of the error messages), sometimes augmented with more information, like:
| EmailNotValid of EmailAddress
| DbAuthorizationError of ConnectionString * Credentials
| SmtpTimeout of SmtpConnection
| SmtpBadRecipient of EmailAddress
No, those would be stored with the exception (possibly as part of its
dynamic type). That's the obvious way to achieve that in D; we don't
want to copy verbatim what's most appropriate for other languages.
template bind(alias fun) { ... }
such that given a function e.g.
int fun(string a, double b);
bind!fun is this function:
Expected!int bind!fun(Expected!string a, Expected!double b) {
if (a.sux || b.sux) return composeExceptions(a, b);
return fun(a.rox, b.rox);
}
There would also be bindNothrow:
Expected!int bindNothrow!fun(Expected!string a, Expected!double b) {
if (a.sux || b.sux) return composeExceptions(a, b);
try return fun(a.rox, b.rox);
catch (Exception e) return e;
}
One of the main points of using those two railways is to avoid exceptions.
Avoid exceptions as control flow, not as means of passing error
information around. I think D's exception chains are very good at the
latter. We should use them.
Andrei
DMD v2.066.0-b5
The v2.066.0-b5 binaries are now available: http://wiki.dlang.org/DMD_v2.066.0-b5
DConf 2014 Lightning Talks
Now available from youtube by default. http://www.reddit.com/r/programming/comments/2bbklj/dconf_2014_lightning_talks/ https://twitter.com/D_Programming/status/491299147015012352 https://www.facebook.com/dlang.org/posts/888753774471638 Andrei
Re: DConf 2014 Lightning Talks
On Monday, 21 July 2014 at 19:13:55 UTC, Andrei Alexandrescu wrote: Now available from youtube by default. http://www.reddit.com/r/programming/comments/2bbklj/dconf_2014_lightning_talks/ https://twitter.com/D_Programming/status/491299147015012352 https://www.facebook.com/dlang.org/posts/888753774471638 Andrei This video is private.
Re: DConf 2014 Lightning Talks
On 07/21/2014 12:13 PM, Andrei Alexandrescu wrote: Now available from youtube by default. http://www.reddit.com/r/programming/comments/2bbklj/dconf_2014_lightning_talks/ https://twitter.com/D_Programming/status/491299147015012352 https://www.facebook.com/dlang.org/posts/888753774471638 Andrei Ali Çehreli's (first speaker) slides are at http://acehreli.org/AliCehreli_assumptions.pdf Ali
Re: DConf 2014 Lightning Talks
Hi, Brian's talk is enjoyable. I's an evidence that D people are in touch with ground... rolling and laughing... Please keep some PRs open and save some WATs for next year. Also, we still need more explosions and planes in presentations! But seriously, thanks Brian and others for your work. Cheers Piotrek
Re: DConf 2014 Lightning Talks
On Monday, 21 July 2014 at 21:39:52 UTC, Ali Çehreli wrote: Ali Çehreli's (first speaker) slides are at http://acehreli.org/AliCehreli_assumptions.pdf Ali Hi, Assume meme was great too. Cheers, Piotrek
Re: DConf 2014 Lightning Talks
On 07/21/2014 02:51 PM, Piotrek wrote: On Monday, 21 July 2014 at 21:39:52 UTC, Ali Çehreli wrote: Ali Çehreli's (first speaker) slides are at http://acehreli.org/AliCehreli_assumptions.pdf Ali Hi, Assume meme was great too. Cheers, Piotrek Thanks! I will wait at least another year before watching the video. I don't think I can stand seeing myself cramming 26 slides in 10 minutes! :) Ali
Re: DConf 2014 Lightning Talks
On Monday, 21 July 2014 at 22:04:58 UTC, Ali Çehreli wrote: Thanks! I will wait at least another year before watching the video. I don't think I can stand seeing myself cramming 26 slides in 10 minutes! :) Ali I know how you feel. I don't want to watch my talk either.
Re: DConf 2014 Lightning Talks
On Monday, 21 July 2014 at 22:08:26 UTC, Brian Schott wrote: On Monday, 21 July 2014 at 22:04:58 UTC, Ali Çehreli wrote: Thanks! I will wait at least another year before watching the video. I don't think I can stand seeing myself cramming 26 slides in 10 minutes! :) Ali I know how you feel. I don't want to watch my talk either. I did watch mine and I'm a cocky son of a . that will not look in the mirror for a week. But IMO it is a good tool for self-reflection. I learned that my voice is annoying and that I had to much food lately. @Brian and @Ali you're fine, don't worry.
Re: DConf 2014 Lightning Talks
Brian WAT slides were absolutely brilliant, I have totally enjoyed watching those for the second time now :)
Re: DConf 2014 Lightning Talks
On 7/21/2014 3:59 PM, Robert burner Schadek wrote: On Monday, 21 July 2014 at 22:08:26 UTC, Brian Schott wrote: On Monday, 21 July 2014 at 22:04:58 UTC, Ali Çehreli wrote: Thanks! I will wait at least another year before watching the video. I don't think I can stand seeing myself cramming 26 slides in 10 minutes! :) Waiting never helps! I can never stand to watch the videos of myself. I know how you feel. I don't want to watch my talk either. I did watch mine and I'm a cocky son of a . that will not look in the mirror for a week. But IMO it is a good tool for self-reflection. I learned that my voice is annoying and that I had to much food lately. @Brian and @Ali you're fine, don't worry. True. I used to be in the dance business. The coach would never videotape his students until he knew they were hooked. Otherwise, they'd be devastated and quit. How you think you look and how you actually look are very different things. Videotape is the harshest, and most effective, training tool.
Re: static opCall 'hidden' by incompatible constructors
On 19/07/2014 10:32, Kagamin wrote: Try to define a constructor with parameters, then compiler won't generate the default constructor, so the parameterless opCall won't be hidden. That only works for classes, not structs.
Re: Software Assurance Reference Dataset
On Sunday, 20 July 2014 at 06:06:16 UTC, bearophile wrote: Andrew Godfrey: 2) Annotations about when a function does not expect re-entrancy to be possible based on call-graph analysis. I don't understand. Assuming I know tAhis (http://en.wikipedia.org/wiki/Reentrancy_%28computing%29 ) can you show an example? Sorry, by re-entrancy I just meant a statement of whether it is possible for the function to be re-entered (not whether it would be correct to do so). Thanks for the reminder, so I can exclude the complication of ISR's from my point. In the codebase I work on - application code - there are no ISR's, but a common cause of unexpected re-entrancy we have is: functions that call a Windows API which pumps messages. This produces unexpectedly deep call stacks and threatens stack overflow. But that's a complicated case that may not be feasible for the compiler to help with. So, a simpler example... The general idea here is that you've convinced yourself you need to do something which stresses usage of stack space, and you believe it is safe to do because of *something*. Ideally you can express that something so that if anyone tries to change it later, the compiler catches that. So, for example you've allocated a buffer on the stack, and your function 'A' builds up data into it, then calls another function 'X' to 'send' that data in some way. Function 'A' definitely doesn't expect to be re-entered. (It may or may not be re-entrant, in the definition of the wiki page. Doesn't matter for this.) Now the first step probably doesn't need language help: call it assertIAmNotReentered(). I think any solution probably still needs this as a backup. I say assert (i.e. runtime check that you'd remove in a release build) because I'm assuming that if you use it a lot you wouldn't want to pay for all those checks in a release build. Now: Suppose 'X' is a Phobos function, and 'A' doesn't call anything else. Then it seems feasible (but a lot of work) to provide an annotation (or combination of annotations) that mean: Compiler, I am not called by an ISR. You don't have to verify that. But given that, I claim that I am not re-entered. Please verify. This is a lot of work - and potentially error-prone - because when Phobos calls the C runtime or OS API's, humans would need to make decisions about whether those functions 'may callback'. For this reason I don't think we'd want to eliminate assertIAmNotReentered(). By this process, Phobos functions which may call a 'callback' back into user code (whether directly or indirectly) would be distinguished from ones which cannot (let's call it NoCallback, since I can't think of a non-terrible name right now). And then the annotation above can be enforced at least in those terms (i.e. the compiler ensures that 'X' only calls NoCallback-annotated functions). I think this is valuable, and not just to avoid stack overflow. The message-pumping case often violates higher-level correctness.
Passing static array to C variadic function
Hi,
I have a C variadic function (passed from C code into my D code via
function pointer) that I need to call with a static array.
So according to the D documentation, static arrays are passed by value
in D2 and by reference in C and D1.
(Even though http://dlang.org/abi.html claims Static arrays are passed
as pointers to their first element. - I guess this just wasn't updated
for D2)
For normal functions http://dlang.org/interfaceToC.html tells me to
add a ref in the function signature, to tell D to pass it by reference
(couldn't this be implicit for extern (C) functions?) - But I obviously
can't to this for vararg function arguments.
So let's imagine the following code:
extern (C) alias funPtr_t = ptrdiff_t function( ptrdiff_t arg, ... );
funPtr_t fun = ...; // is assigned somewhere..
void bla( float[3] v ) {
fun( 42, v );
}
This produces the following compiler error (DMD 2.065 linux amd64):
Error: cannot pass static arrays to extern(C) vararg functions
/However/, if I typedef a float[3] type, the compiler does not complain
(not sure if the code behaves like expected, though, or if it's still
passed by value instead of by reference as expected by the C code):
typedef float[3] vec3_t;
void bla( vec3_t v ) {
fun( 42, v );
}
Then again, if I use alias instead of the deprecated typedef:
alias vec3_t = float[3];
I again get Error: cannot pass static arrays to extern(C) vararg
functions.
Is there a proper way to make this work?
If not, any ideas for a viable workaround?
Cheers,
Daniel
Re: Passing static array to C variadic function
On Sunday, 20 July 2014 at 16:00:41 UTC, Daniel Gibson wrote:
Hi,
I have a C variadic function (passed from C code into my D code
via function pointer) that I need to call with a static array.
So according to the D documentation, static arrays are passed
by value in D2 and by reference in C and D1.
(Even though http://dlang.org/abi.html claims Static arrays
are passed as pointers to their first element. - I guess this
just wasn't updated for D2)
For normal functions http://dlang.org/interfaceToC.html tells
me to add a ref in the function signature, to tell D to pass
it by reference (couldn't this be implicit for extern (C)
functions?) - But I obviously can't to this for vararg function
arguments.
So let's imagine the following code:
extern (C) alias funPtr_t = ptrdiff_t function( ptrdiff_t
arg, ... );
funPtr_t fun = ...; // is assigned somewhere..
void bla( float[3] v ) {
fun( 42, v );
}
This produces the following compiler error (DMD 2.065 linux
amd64):
Error: cannot pass static arrays to extern(C) vararg functions
/However/, if I typedef a float[3] type, the compiler does not
complain (not sure if the code behaves like expected, though,
or if it's still passed by value instead of by reference as
expected by the C code):
typedef float[3] vec3_t;
void bla( vec3_t v ) {
fun( 42, v );
}
Then again, if I use alias instead of the deprecated typedef:
alias vec3_t = float[3];
I again get Error: cannot pass static arrays to extern(C)
vararg functions.
Is there a proper way to make this work?
If not, any ideas for a viable workaround?
Cheers,
Daniel
C functions takes arrays by pointer to first element. fun(42,
v.ptr) should work.
Re: function default arguments depending on other arguments
On 7/20/14, 2:22 AM, Tove wrote:
On Friday, 18 July 2014 at 17:40:23 UTC, Timon Gehr wrote:
On 07/18/2014 12:00 AM, Trass3r wrote:
void foo(int a, int b = a)
{
}
is illegal in C++ because order of evaluation is undefined.
But since D defines the order to be left to right couldn't it also allow
this?
It could, and I think it is an unnecessary limitation that it
currently does not. (This can also be useful if that parameter is the
hidden 'this' reference.)
This request keeps popping up, I've seen it at least 3 times before and
there's even an enhancement request for it:
https://issues.dlang.org/show_bug.cgi?id=8075
IIRC:
Walter's stance was that he needs compelling examples, which proves the
utility of this new feature.
The classic example is injecting alloca downstream:
auto fun(size_t s, void[] buffer = alloca(s)[0 .. s])
{
...
}
Andrei
Re: Review: std.logger
Pros The lighning talk about the std.logger proposal at DConf 2014 had a positive impact. We were able to change the Current D Use entry of our company from Uses D2 / Phobos, Tango (log, xml) to Uses D2 / Phobos, Tango (xml). (We got rid of tango.util.log; we still rely on the fast tango.text.xml.) Cons 1. I am not happy with the (reverse) hungarian-style naming At least in the code of our company, logging a formatted string is the basic use case. The function for the basic use case should not require a suffix letter. The consistency argument, that 'infof' is like 'writef', does not fully apply: neither 'infoln' nor 'infofln' make sense. (In my opinion, half consistent is inconsistent.) Currently, suffix 'c' is used for conditional logging. But, how will future extensions like glog's LOG_EVERY_N or LOG_FIRST_N be named? With suffix 'e'? Suffix 'f' is already assigned! The suffix letter sequence seems to be the road to confusion. I would prefer the explicit naming of the previous std.log proposal: log.when(condition)(...) However, there is only a small advantage over if (condition) log(...) 2. No support for 24/7 (server) applications In my opinion, I really need logging for applications that possibly run forever. With the FileLogger, the file will grow forever. That's why most other frameworks provide something like a RollingFileLogger or some logrotate-aware FileLogger. By the way: Instead of what I really need, I get a NullLogger. I have no clue, why I never ever missed such an oddity. 3. Implementation is hidden behind 'mixin' expressions When I tried to look at the implementation, I found long sequences of lines like this: mixin(buildLogFunction(true, false, false, LogLevel.info)); Nowadays, this changed into: mixin(freeLog.format( info, info, info, info, info, info, info, info, info, info, info, info, info, info, info, info)); This is much better, but I still think, it's a complicated solution for a simple problem. And it would be a shame for D, if there is no simple solution. Small stuff --- 4. FileLogger needs flush It's annoying when the events that caused a crash have been logged, but they never have been written to the file. 5. Suspect use of '__gshared' The FileLogger has a field private __gshared File file_; In this case, __gshared is equivalent to static. This means that all FileLogger instances share the same file! 6. Bad naming of StdIOLogger Like 'std.stdio.StdioException', the 'io' should be lower case. If the 'StdIOLogger' logs to 'stdout', 'StdoutLogger' would be preferable. 7. No need for StdIOLogger 'stdout' (and 'stderr') are Files, so a FileLogger should be able to handle them. A second constructor should do the trick. 8. Log levels Many frameworks mix the types log level and set of log levels (for filtering). While 'trace', ..., 'fatal' are log levels, 'all' and 'off' (better: 'none'?) are sets of log levels. (I have no idea about the type of 'unspecific'.) A clean separation would avoid confusion: why is there 'info(...)' but not 'all(...)'? Also, it would be easier to log for example 'trace' and 'info' to 'stdout'. 9. Bad naming of std.logger The focus of this proposal is on the log/logging API; the loggers are only examples. The recommended use should be import log = std.logger; Then, the name std.log (of the previous proposal) would be more appropriate. Counter Proposal As a consequence of these issues, I once decided to spend a weekend to prepare a counter proposal: http://code.dlang.org/packages/log The design goal was simplicity. So: - conditional logging is not supported - no suffix letter sequences - there is no NullLogger - there is no MultiLogger (this functionality is implicit) - there is no need to provide a name for a logger I prefer 'alias' over 'mixin': 'info' is just an alias for 'log(arg)' as well as for 'log(fmt, args)' at log level 'info'. Sets of log levels are implemented as (bit) sets of log levels. A helper function lets you select the traditional = filtering: LogLevel.info.orHigher For convenience, 'stdoutLogger' and 'stderrLogger' are factory functions that create 'FileLogger' instances. Of course, a RollingFileLogger as well a a RotatingFileLogger (that reopens the log file on SIGHUP) are provided. By now, this simple solution is in use in tens of thousands lines of commercial code. (Where it outperforms the previously used tango.util.log implementation.)
Re: Naming of new lazy versions of existing Phobos functions
On Sunday, 20 July 2014 at 10:19:10 UTC, Jonathan M Davis wrote: Do we really want to be naming functions which aren't properties with adjectives instead of verbs? Yes. We have parens for denoting functions. Oh wait.
Re: Implicit conversion to base interface doesn't work inside initialization of AA of objects
I posted in the wrong thread.
Re: Passing static array to C variadic function
Daniel Gibson: For normal functions http://dlang.org/interfaceToC.html tells me to add a ref in the function signature, to tell D to pass it by reference (couldn't this be implicit for extern (C) functions?) I don't know why D isn't adapting such things to the needs of C. Bye, bearophile
Re: Implicit conversion to base interface doesn't work inside initialization of AA of objects
On Thursday, 17 July 2014 at 17:27:37 UTC, bearophile wrote: Uranuz: OK. Thanks. Using casts everywhere for such case us quite annoying. I've tested it for plain array it doesn't work too. However issue is marked as solved for it. It's not exactly the same issue. Issue 3543 seems more fitting. In D interfaces and classes are not the same thing. Bye, bearophile OK. I'll try to use beta version of 2.066 until release happens
Re: GCs in the news
On Friday, 18 July 2014 at 09:25:46 UTC, Chris wrote: On Thursday, 17 July 2014 at 18:19:04 UTC, H. S. Teoh via Digitalmars-d wrote: On Thu, Jul 17, 2014 at 05:58:14PM +, Chris via Digitalmars-d wrote: On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via Digitalmars-d wrote: [...] AFAIK some work still needs to be done with std.string; Walter for one has started some work to implement range-based equivalents for std.string functions, which would be non-allocating; we just need a bit of work to push things through. DMD 2.066 will have @nogc, which will make it easy to discover which remaining parts of Phobos are still not GC-free. Then we'll know where to direct our efforts. :-) T That's good news! See, we're getting there, just bear with us. This begs the question of course, how will this affect existing code? My code is string intensive. I don't think it will affect existing code (esp. given Walter's stance on breaking changes!). Probably the old GC-based string functions will still be around for backwards-compatibility. Perhaps some of them might be replaced with non-GC versions where it can be done transparently, but I'd expect you'd need to rewrite your string code to take advantage of the new range-based stuff. Hopefully the rewrites will be minimal (e.g., pass in an output range as argument instead of getting a returned string, replace allocation-based code with a UFCS chain, etc.). The ideal scenario may very well be as simple as tacking on `.copy(myBuffer)` at the end of a UFCS chain. :-P T That sounds good to me! This gives me time to upgrade my old code little by little and use the new approach when writing new code. Phew! By the way, my code is string intensive and I still have some suboptimal (greedy) ranges here and there. But believe it or not, they're no problem at all. The application (a plugin for a screen reader) is fast and responsive* (according to user feedback) like any other screen reader plugin, and it hasn't crashed for ages (thanks to GC?) - knock on wood! I use a lot of lazy ranges too plus some pointer magic for work intensive algorithms. Plus D let me easily model the various relations between text and speech (for other use cases down the road). Maybe it is not a real time system, but it has to be responsive. So far, GC hasn't affected it negatively. Once the online version will be publicly available, I will report how well vibe.d performs. Current results are encouraging. As regards Java, the big advantage of D is that it compiles to a native DLL and all users have to do is to double click on it to install. No please download JVM nightmare. I've been there. Users cannot handle it (why should they?), and to provide it as a developer is a waste of time and resources, and it might still go wrong which leaves both the users and the developers angry and frustrated. * The only thing that bothers me is that there seems to be a slight audio latency problem on Windows, which is not D's fault. On Linux it speaks as soon as you press Enter. Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package. -- Paulo
Re: Integer overflow and underflow semantics?
On Sunday, 20 July 2014 at 11:09:45 UTC, Tobias Müller wrote:
Marc Schütz schue...@gmx.net wrote:
On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
Can't it simply generate code as is? Seems wasteful to spend
compilation time on this.
Not if you want fast code, consider a template with:
if (a.length+M b.length+N) {}
then you alias b = a in the template instantiation:
if(a.length+M a.length+N){}
you want this reduced to:
if (MN){
}
which can be resolved at compile time.
Yes, but that is the optimizer's job. The front-end doesn't
need to spend
time on it, if the back-end then anyway does the same
optimization again.
I don't think anyone has said that the frontend does that.
I do ;-) This is how I interpret Kagamin's post.
Re: Software Assurance Reference Dataset
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote: Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Traditional FP languages don't have loops, and so must do recursion. D has loops, even in pure functions, there's no reason not to use them. Another use case is so-called threaded code interpreter, that can be done with either computed gotos (and bunch of labels) or forced tail calls (and bunch of functions). In both cases computed jump or tail call is indirect. http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables/ The computed goto is faster for two reasons, according to the article: 1.The switch does a bit more per iteration because of bounds checking. 2.The effects of hardware branch prediction. (1) is eliminated with final switch. I know this optimization is not done with dmd, but D doesn't need a new language feature because of that. (2) with a bit more work, this could also be implemented as a compiler optimization. Both of these are worthy of bugzilla enhancement requests. I'd much rather implement improvements as better code generation rather than more language features.
Re: Passing static array to C variadic function
Am 20.07.2014 18:37, schrieb bearophile: Daniel Gibson: For normal functions http://dlang.org/interfaceToC.html tells me to add a ref in the function signature, to tell D to pass it by reference (couldn't this be implicit for extern (C) functions?) I don't know why D isn't adapting such things to the needs of C. Bye, bearophile Yeah, IMHO it would indeed make sense to make extern (C) functions behave more like C. They already are different to D functions (different name mangling and, more visibly to the user, varargs behave differently), so why not do it properly? As far as I see it, passing static arrays by value to C functions is never what you want because C just doesn't support it, so why not make it implicit? This also goes the other way round: if I implement an extern (C) function in D (vs just having a function pointer or a declaration of a function implemented in C), D thinks it's getting a static array by value when it's really just getting a ref.. And for the varargs case (where I can't just add ref), it's totally non-obvious that I have to pass staticArr.ptr instead, so here it would be even more desirable to have that done implicitly. So what I (naive as I am) would expect extern (C) to do to functions is: * C name mangling (that's done) * C-style varargs (also done) * passing stuff to the function is done as C expects it (not done, also: are there other cases than the static array one that are different?) * Disallowing template arguments (because how would I declare and call that function in C?) (not done) * /Maybe/ disallowing types as arguments/return types that are not supported by C (D classes; not done)? (OTOH, one the C side one could just handle them as void* and pass instances around opaquely) Cheers, Daniel
Re: [Dangerously OT] Re: D logo copyright
On Sunday, 20 July 2014 at 09:21:13 UTC, Alix Pexton wrote: others. I have not been able to discover if Germany is one of those countries or not. It doesn't matter. The Bern convention requires that you give foreign works the same protection as local works. So if you publish globally you have to follow ALL copyright legislation in all countries you are addressing. The origin does not matter, it is where you publish that matters.
Re: Naming of new lazy versions of existing Phobos functions
Do we really want to be naming functions which aren't properties with adjectives instead of verbs? That seems very wrong to me. I'd much rather see stuff like setExt or setExtLazy than withExtension or extensionSet. Function names are supposed to be verbs unless they're emulating variables. They _do_ something, even if it's lazy. - Jonathan M Davis I think it is appropiate to use adjectives for lazy functions. The Use verbs for functions-rule holds no ground in lazy evaluation, except you want to call them wrapInExtensionSetter or something like that.
Re: [OT] Empire
On 7/19/2014 11:06 PM, Meta wrote: I have to ask now, what features of other games (probably tabletop based, given the time) did YOU take inspiration from for the first version of Empire, Walter? Mainly Risk.
Re: Software Assurance Reference Dataset
On 7/20/2014 1:50 PM, Walter Bright wrote: Both of these are worthy of bugzilla enhancement requests. Amazingly, these suddenly appeared: https://issues.dlang.org/show_bug.cgi?id=13169 https://issues.dlang.org/show_bug.cgi?id=13170
Re: Software Assurance Reference Dataset
Walter Bright: https://issues.dlang.org/show_bug.cgi?id=13169 https://issues.dlang.org/show_bug.cgi?id=13170 Are such optimizations portable and guaranteed on all D compilers? If the answer is negative, then they can't replace a _standard_ D syntax for computed gotos. Bye, bearophile
Re: Software Assurance Reference Dataset
On 7/20/2014 3:10 PM, Dmitry Olshansky wrote: The computed goto is faster for two reasons, according to the article: 1.The switch does a bit more per iteration because of bounds checking. Now let's consider proper implementation of thread-code interpreter. where *code pointer points to an array of addresses. We've been through this before and it turns out switch is slower because of an extra load. a) Switch does 1 load for opcode, 1 load for the jump table, 1 indirect jump to advance (not even counting bounds checking of the switch) b) Threaded-code via (say) computed goto does 1 load of opcode and 1 indirect jump, because opcode is an address already (so there is no separate jump table). True, but I'd like to find a way that this can be done as an optimization. I'm certain that forced tail call would work just fine instead of computed goto for this scenario. In fact I've measured this with LDC and the results are promising but only work with -O2/-O3 (where tail call is optimized). I'd gladly dig them up if you are interested. I'm pretty reluctant to add language features that can be done as optimizations.
Re: Software Assurance Reference Dataset
21-Jul-2014 00:50, Walter Bright пишет: On 7/20/2014 3:27 AM, Dmitry Olshansky wrote: Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Traditional FP languages don't have loops, and so must do recursion. D has loops, even in pure functions, there's no reason not to use them. Another use case is so-called threaded code interpreter, that can be done with either computed gotos (and bunch of labels) or forced tail calls (and bunch of functions). In both cases computed jump or tail call is indirect. http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables/ Actually that blog entry is wrong about it. Computed goto won't help when used as direct replacement of switch and you are correct in that the said code could be easily optimized with final switch. What would help a lot is thread-code interpreter, that is bytecode contains direct addresses used in computed goto. The computed goto is faster for two reasons, according to the article: 1.The switch does a bit more per iteration because of bounds checking. Now let's consider proper implementation of thread-code interpreter. where *code pointer points to an array of addresses. We've been through this before and it turns out switch is slower because of an extra load. a) Switch does 1 load for opcode, 1 load for the jump table, 1 indirect jump to advance (not even counting bounds checking of the switch) b) Threaded-code via (say) computed goto does 1 load of opcode and 1 indirect jump, because opcode is an address already (so there is no separate jump table). I'm certain that forced tail call would work just fine instead of computed goto for this scenario. In fact I've measured this with LDC and the results are promising but only work with -O2/-O3 (where tail call is optimized). I'd gladly dig them up if you are interested. -- Dmitry Olshansky
Re: Software Assurance Reference Dataset
On 7/20/2014 2:38 PM, bearophile wrote: Are such optimizations portable and guaranteed on all D compilers? If the answer is negative, then they can't replace a _standard_ D syntax for computed gotos. C'mon, bearophile. Optimizations are always implementation dependent. People rely on them for fast code. This isn't any different.
Phobos PR 2266 blocked by ICE 12057
Phobos pull request 2266 [1] has been blocked by an ICE (issue 12057
[2]) for almost a month now. I'm wondering if somebody more familiar
with dmd internals can help fix it. I've managed to reduce the code
down to a minimal (or close to minimal) test case:
// Compile with: dmd -O
bool prop(real x) { return false; }
double f(real) { return double.init; }
void main()
{
real fc = f(real.init);
if (fc == 0 || fc.prop) {}
}
The bug goes away if -O is not specified. Looks like an optimizer bug.
However, I don't know enough about the backend to be able to proceed
from here. Can somebody help?
[1] https://github.com/D-Programming-Language/phobos/pull/2266
[2] https://issues.dlang.org/show_bug.cgi?id=12057
T
--
Give me some fresh salted fish, please.
Looking to hire: 2-3 programmers, candidates will likely need to learn D.
(I hope OK to post:) Location: Silicon Valley /San Jose, CA/ or Dallas TX. Current 'app' version is mostly Java/Tomcat, so will need to maintain that while writing a new version, likely mostly D ( possibly Qt depending on GC ). (Also a few lines assembly, C, IOS Objective C, Andorid as clients) OS will be Gentoo flavor. There is some fun data structures and some boring HTTP in the project, I'll have to tell you more if you ping us, some of it is fun tech but I don't want it public. The company is a 7 digit funded start up, a bit more about the project - http://ceocfointerviews.com/interviews/Apakau14.htm Ideal candiate is a career programmer/developer, prolific coder would be supper. Experience prefered, a few years out of school might be considered. Company culture is tech friendly/introvert (as opposed to marketing/business type orgs). Market rate salary, but first few hire we don't have much for reloaction budget(not looking for remote for first year+). Of course 30 monitor, Xeon workstation, good vacation time, gym and more, of course D conference or similar is company expense. There are some trade secrets to keep. To have a phone chat, please email me your resume/bio to vic (at) apakau.com. Likely we will be done hiring in a week or 2. (I plan to cross post on Qt and Vibe.d forums)
Re: Software Assurance Reference Dataset
On 07/20/2014 10:50 PM, Walter Bright wrote: On 7/20/2014 3:27 AM, Dmitry Olshansky wrote: Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Traditional FP languages don't have loops, and so must do recursion. Uh... D has loops, even in pure functions, So does Haskell. import Control.Monad import Control.Monad.ST import Data.STRef factorial :: Integer - Integer factorial n = runST $ do r - newSTRef 1 forM_ [1..n] $ \i- modifySTRef r (*i) readSTRef r main = print $ factorial 5 -- 120 there's no reason not to use them. ... But of course there are reasons to use tail calls.
Re: Software Assurance Reference Dataset
On 7/20/2014 8:15 PM, Timon Gehr wrote: On 07/20/2014 10:50 PM, Walter Bright wrote: On 7/20/2014 3:27 AM, Dmitry Olshansky wrote: Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Traditional FP languages don't have loops, and so must do recursion. Uh... D has loops, even in pure functions, So does Haskell. import Control.Monad Uh-oh! Monad! :-)
Re: Passing static array to C variadic function
Daniel Gibson wrote in message news:lqh3vb$c2b$1...@digitalmars.com... * passing stuff to the function is done as C expects it (not done, also: are there other cases than the static array one that are different?) Dynamic arrays. D used to allow passing static and dynamic arrays to C varargs with no problems. This lead to nasty segfaults, especially with this code: printf(Hello %s\n, segfault); which looks perfectly valid in D but certainly isn't. What you actually meant to pass is up to you to specify. It would not make a lot of sense for C functions to have a different set of implicit conversion rules to other functions. * Disallowing template arguments (because how would I declare and call that function in C?) (not done) This is probably worth reporting, I doubt it works correctly. * /Maybe/ disallowing types as arguments/return types that are not supported by C (D classes; not done)? (OTOH, one the C side one could just handle them as void* and pass instances around opaquely) Yes, this is why they are not disallowed. This is just too damn useful. printf(Pointer: %p\n, new Class());
Re: DIP65: Fixing Exception Handling Syntax
On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote: Walter Bright: The fear of breaking code should NOT freeze our brains in terror. For each sigh of broken code could exist one thousand sighs caused by broken designs that will keep causing troubles forever. +1 --- Paolo
Re: DIP65: Fixing Exception Handling Syntax
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
Did you see my response?
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration().
I just want to point out that this special case is lacking, and
will inevitably cause someone a headache when they try to do
something like:
catch(typeof(foo)) {
...
}
Which is currently valid (as I'd expect).
Re: Software Assurance Reference Dataset
On 7/20/14, 8:15 PM, Timon Gehr wrote: On 07/20/2014 10:50 PM, Walter Bright wrote: On 7/20/2014 3:27 AM, Dmitry Olshansky wrote: Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Traditional FP languages don't have loops, and so must do recursion. Uh... D has loops, even in pure functions, So does Haskell. import Control.Monad import Control.Monad.ST import Data.STRef factorial :: Integer - Integer factorial n = runST $ do r - newSTRef 1 forM_ [1..n] $ \i- modifySTRef r (*i) readSTRef r main = print $ factorial 5 -- 120 And that doesn't look awkward at all :o). -- Andrei
Re: Integer overflow and underflow semantics?
Marc Schütz schue...@gmx.net wrote:
On Sunday, 20 July 2014 at 11:09:45 UTC, Tobias Müller wrote:
Marc Schütz schue...@gmx.net wrote:
On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad wrote:
On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
Can't it simply generate code as is? Seems wasteful to spend
compilation time on this.
Not if you want fast code, consider a template with:
if (a.length+M b.length+N) {}
then you alias b = a in the template instantiation:
if(a.length+M a.length+N){}
you want this reduced to:
if (MN){
}
which can be resolved at compile time.
Yes, but that is the optimizer's job. The front-end doesn't need to
spend
time on it, if the back-end then anyway does the same optimization again.
I don't think anyone has said that the frontend does that.
I do ;-) This is how I interpret Kagamin's post.
Hm I interpreted it the other way round, it's wasteful to spend time for
such optimizations, just.
But my english is probably not as good as yours.
Tobi
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
Jacob Carlborg: Error: AA key type TagIndex now requires equality rather than comparison Hashing protocol has being finally fixed. What exactly do I need to define to have a struct with two ints working as a key in an associative array? opEquals and opHash. But if your struct has only two ints as fields, it should work even if you don't define both methods. Bye, bearophile
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
Am 21.07.2014 16:34, schrieb bearophile: Ary Borenszweig: Wat? Hash methods should be automatic for simple structs. Bye, bearophile That would be too much magic = special cases one has to know about. Cheers, Daniel
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
Daniel Gibson:
That would be too much magic = special cases one has to know
about.
What special cases? It works for POD structs. If you want a
different hashing behavior (example: you want to ignore some
fields), you define the two methods.
struct Foo {
double x;
int y;
string s;
}
void main() {
import std.stdio;
bool[Foo] aa;
aa[Foo(1.0, 2, hello.idup)] = true;
aa[Foo(1.0, 1, hello.idup)] = false;
aa[Foo(1.0, 2, hello.idup)] = false;
aa.writeln;
}
Outputs:
[Foo(1, 1, hello):false, Foo(1, 2, hello):false]
This was a very old large bug of D. Now it's fixed. Rejoice.
Bye,
bearophile
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
Ary Borenszweig: Wat? Hash methods should be automatic for simple structs. Bye, bearophile
Re: GCs in the news
On Sunday, 20 July 2014 at 12:30:02 UTC, Mike wrote: Yes, I believe you are correct. I also believe there is even a GCStub in the runtime that uses malloc without free. What's missing is API documentation and examples that makes such features accessible. The existing functions should be understandable, so you can document them yourself. If you want to standardize the API, you can write a small wrapper library, which will account for possible internal API changes and map them to your standard API. Examples are up to you, since nobody knows, what features you will implement in your GC implementation and what API they should have. You have gcstub as an example with GC proxy substitution API. In short, IMO, D should not embrace one type of automatic memory management, they should make it extensible. In time two ore three high quality memory managers will prevail. It's a matter of writing an appropriate library and providing it as a dub module. Do you know the best, what you want, you are the one to make your wish come to life.
Re: Integer overflow and underflow semantics?
Basile Burg:
If you still feel ok today then dont read this:
-
module meh;
import std.stdio;
//https://stackoverflow.com/questions/24676375/why-does-int-i-1024-1024-1024-1024-compile-without-error
static shared immutable int o = 1024 * 1024 * 1024 * 1024;
void main(string args[])
{
writeln(o);
}
-
See:
https://issues.dlang.org/show_bug.cgi?id=4835
https://github.com/D-Programming-Language/dmd/pull/1803
Bye,
bearophile
Re: Integer overflow and underflow semantics?
On Wednesday, 16 July 2014 at 21:26:41 UTC, Gary Willoughby wrote:
This was asked a few years ago and i could find a definitive
answer.
http://forum.dlang.org/thread/jo2c0a$31hh$1...@digitalmars.com
On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen
wrote:
I don't think the language really makes it clear whether
overflows and underflows are well-defined. Do we guarantee
that for any integral type T, T.max + 1 == T.min and T.min - 1
== T.max?
What is the current situation of integer overflow and underflow?
If you still feel ok today then dont read this:
-
module meh;
import std.stdio;
//https://stackoverflow.com/questions/24676375/why-does-int-i-1024-1024-1024-1024-compile-without-error
static shared immutable int o = 1024 * 1024 * 1024 * 1024;
void main(string args[])
{
writeln(o);
}
-
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
On 7/21/14, 9:49 AM, bearophile wrote: But if your struct has only two ints as fields, it should work even if you don't define both methods. Wat?
Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
What's up with associative arrays, opCmp, opEquals and toHash in 2.066.0-b4. I'm trying to compile Tango with the latest beta and I'm getting this error: Error: AA key type TagIndex now requires equality rather than comparison Four months ago opCmp was added to TagIndex to fix some compile error in 2.065.0 and now it complains on opCmp being defined. If I add opEquals it complains that I need to define toHash. What exactly do I need to define to have a struct with two ints working as a key in an associative array? -- /Jacob Carlborg
Re: Looking to hire: 2-3 programmers, candidates will likely need to learn D.
On Monday, 21 July 2014 at 02:43:51 UTC, Vic wrote: (I hope OK to post:) Location: Silicon Valley /San Jose, CA/ or Dallas TX. Current 'app' version is mostly Java/Tomcat, so will need to maintain that while writing a new version, likely mostly D ( possibly Qt depending on GC ). (Also a few lines assembly, C, IOS Objective C, Andorid as clients) OS will be Gentoo flavor. There is some fun data structures and some boring HTTP in the project, I'll have to tell you more if you ping us, some of it is fun tech but I don't want it public. The company is a 7 digit funded start up, a bit more about the project - http://ceocfointerviews.com/interviews/Apakau14.htm Ideal candiate is a career programmer/developer, prolific coder would be supper. Experience prefered, a few years out of school might be considered. Company culture is tech friendly/introvert (as opposed to marketing/business type orgs). Market rate salary, but first few hire we don't have much for reloaction budget(not looking for remote for first year+). Of course 30 monitor, Xeon workstation, good vacation time, gym and more, of course D conference or similar is company expense. There are some trade secrets to keep. To have a phone chat, please email me your resume/bio to vic (at) apakau.com. Likely we will be done hiring in a week or 2. (I plan to cross post on Qt and Vibe.d forums) You might want to post to D.announce group. Some D users claim they only check D.announce
Re: Naming of new lazy versions of existing Phobos functions
On Friday, 18 July 2014 at 20:35:33 UTC, Walter Bright wrote: On 7/18/2014 12:40 PM, Tourist wrote: Are you planning to deprecate the non-lazy functions at some (maybe very distant) point? No. Phobos has already gone through multiple rounds of renaming/deprecation, all at considerable disruption. Each one was supposed to be worth it and the last time. It needs to stop. Is an alternate module an option? std.string.lazy, etc.
Re: Encouraging memory efficiency
On 19/07/2014 01:31, Timon Gehr wrote:
auto createBuffer(T,alias size)(T[]
buf=(cast(T*)alloca(size))[0..size]){ return buf; }
alloca(T.sizeof * size)
'package'
I'm having all sorts of visibility problems. I have this: app/system/... app/system/widgets/... The 'system'/manager should be able to access all the widgets internals, but things outside the system shouldn't be able to touch the internals. This is what 'package' is supposed to be for, except 'package' in widgets only allows access to other widgets, 'system' level modules have no access... Is there a workaround for this case? I'm not sure what to do. I guess the trouble is that 'package' specifies sibling modules and below, but nothing above... but this isn't always the module structure. I'm thinking 'package' needs to know the top level that can access internals. Perhaps this would solve my problem elegantly: module app.system.widgets.widget; // - module is beneath 'widgets' package(app.system): ... internal stuff that 'app.system' (ie, the 'package') and below can access ... Or is there an existing solution that I can't find?
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
On 2014-07-21 14:49, bearophile wrote: opEquals and opHash. But if your struct has only two ints as fields, it should work even if you don't define both methods. If the struct already has opCmp I need to defined opEquals and toHash? -- /Jacob Carlborg
Re: GC on Unreal Engine
On Sunday, 20 July 2014 at 10:01:27 UTC, Paulo Pinto wrote: Since this theme keeps being discussed. Here is some info how Unreal Engine makes use of GC in C++. https://wiki.unrealengine.com/Garbage_Collection_Overview -- Paulo If that wiki page is up-to-date (and I don't see why it shouldn't be) then GC functionality inside of Unreal Engine is so much limited it's not even funny
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
Jacob Carlborg: If the struct already has opCmp I need to defined opEquals and toHash? From what I know, the new hash protocol requires toHash and opEquals. I think that now opCmp is not used by hashing. I don't know if you define just toHash and opCmp it uses opCmp as fallback. Bye, bearophile
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
On 7/21/14, 11:39 AM, Daniel Gibson wrote: Am 21.07.2014 16:34, schrieb bearophile: Ary Borenszweig: Wat? Hash methods should be automatic for simple structs. Bye, bearophile That would be too much magic = special cases one has to know about. Cheers, Daniel Ah, good. I though it only worked for structs with two ints :-P
Re: 'package'
On Monday, 21 July 2014 at 17:32:53 UTC, Manu via Digitalmars-d wrote: I'm having all sorts of visibility problems. I have this: app/system/... app/system/widgets/... The 'system'/manager should be able to access all the widgets internals, but things outside the system shouldn't be able to touch the internals. This is what 'package' is supposed to be for, except 'package' in widgets only allows access to other widgets, 'system' level modules have no access... Is there a workaround for this case? I'm not sure what to do. I guess the trouble is that 'package' specifies sibling modules and below, but nothing above... but this isn't always the module structure. I'm thinking 'package' needs to know the top level that can access internals. Perhaps this would solve my problem elegantly: module app.system.widgets.widget; // - module is beneath 'widgets' package(app.system): ... internal stuff that 'app.system' (ie, the 'package') and below can access ... Or is there an existing solution that I can't find? https://github.com/D-Programming-Language/dmd/pull/3651
Re: Phobos PR 2266 blocked by ICE 12057
H. S. Teoh via Digitalmars-d wrote in message news:mailman.32.1405963928.32463.digitalmar...@puremagic.com... Phobos pull request 2266 [1] has been blocked by an ICE (issue 12057 [2]) for almost a month now. I'm wondering if somebody more familiar with dmd internals can help fix it. I've managed to reduce the code down to a minimal (or close to minimal) test case: It looks like fixresult87 (which makes sure the result of an expression is in the correct register) sees you wanted a comparison result (mPSW) and that your value is not already in mPSW. It then asserts it's in ST0, which it isn't, presumably because it's in an xmm reg, and gives up. You could try just removing that assert (line 925) or modifying it to accept xmm regs, it looks like the line below at least considers them a possibility so who knows, it might work. If that doesn't work you could try checking for xmm regs and calling fixresult87 with 'retregs' modified to point to an xmm reg, so it tries to do a cross-bank copy. This is a crime against nature but it might work. Really only Walter knows how that stuff should work.
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
On Mon, Jul 21, 2014 at 04:42:34PM +, bearophile via Digitalmars-d wrote: Jacob Carlborg: If the struct already has opCmp I need to defined opEquals and toHash? From what I know, the new hash protocol requires toHash and opEquals. I think that now opCmp is not used by hashing. Yes, finally that has been fixed. I don't know if you define just toHash and opCmp it uses opCmp as fallback. [...] I'm inclined to say, file a regression bug. If opCmp is defined but opEquals isn't, the compiler should auto-generate opEquals (as opCmp(...)==0). Requiring the user to implement a separate opEquals when opCmp is already there is nonsensical, and opens the door to stupid bugs due to increased boilerplate. (Of course, if the user also defines opEquals manually, that's fine. But if he doesn't, the compiler should do the Right Thing(tm).) In any case, if either opCmp or opEquals (or both) is defined, then toHash must be defined, since obviously the user doesn't want the default POD comparison implementation, and toHash must always be consistent with opCmp/opEquals otherwise the AA will break. T -- 640K ought to be enough -- Bill G., 1984. The Internet is not a primary goal for PC usage -- Bill G., 1995. Linux has no impact on Microsoft's strategy -- Bill G., 1999.
Re: Encouraging memory efficiency
On 7/17/2014 9:27 AM, Tero wrote: Just watched Don's DConf 2014 talk where he said D has to be ruthless about memory inefficiency. Here's one thing that I think could help avoid unnecessary garbage: built-in syntax for this: import core.stdc.stdlib : alloca; ubyte[] buffer = (cast(ubyte*) alloca(bufsize)) [0 .. bufsize]; Often bufsize is not known at compile-time but it won't change after the buffer allocation. So there's no reason to create garbage other than the *inconvenience* of using alloca. Allocating in the stack seems ideal so I'd encourage that by a clean syntax. I keep missing this feature. You might be interested in std.internal.scopebuffer.
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
A rule I learned from writing Java is that if you implement equality, you must also implement hashing, and if you implelement hashing you must implement equality. I believe this is actually a general truth of programming in any language, and now D has the right kind of semantics. On an off topic note, I noticed your signature, H.S. Teoh. 640K ought to be enough -- Bill G., 1984. That quote is well known for being fabricated. The year varies wildly. There's no evidence of Bill ever saying it which isn't someone saying, Trust me, I heard him say it once.
Re: GCs in the news
On Sun, 2014-07-20 at 16:40 +, Paulo Pinto via Digitalmars-d wrote: […] Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package. Also, it is not entirely clear that AOT optimization can beat JIT optimization, at least on the JVM. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
On Mon, Jul 21, 2014 at 06:28:48PM +, w0rp via Digitalmars-d wrote: A rule I learned from writing Java is that if you implement equality, you must also implement hashing, and if you implelement hashing you must implement equality. I believe this is actually a general truth of programming in any language, and now D has the right kind of semantics. This should generally be obvious, since the AA has to hash the object, then distinguish between objects with the same hash by comparing them with some kind of comparison operator. Obviously, if the hash function is inconsistent with this comparison operator, then you're going to get inconsistent behaviour out of the AA. Now, one *could* argue that in some cases, you could implement custom equality but use the default hash function, because you know that your custom equality is consistent with it, but I'd say this is a risky assumption because if it turns out that it's actually *not* consistent, then you end up with a very hard-to-trace bug. So in general, requiring that either you use default equality and hash, or redefine both, seems to be the most logical approach. On an off topic note, I noticed your signature, H.S. Teoh. 640K ought to be enough -- Bill G., 1984. That quote is well known for being fabricated. The year varies wildly. There's no evidence of Bill ever saying it which isn't someone saying, Trust me, I heard him say it once. Funny, your reply prompted me to search for the attribution, and I came across this: http://imranontech.com/2007/02/20/did-bill-gates-say-the-640k-line/ Of course, most of my quotes are meant to be humorous in some way, so they shouldn't be taken 100% seriously. So I just changed it to: 640K ought to be enough -- Bill G. (allegedly), 1984. The Internet is not a primary goal for PC usage -- Bill G., 1995. Linux has no impact on Microsoft's strategy -- Bill G., 1999. ;-) T -- Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.
Re: Associative arrays, opCmp, opEquals and toHash in 2.066.0-b4
On 2014-07-21 20:17, H. S. Teoh via Digitalmars-d wrote: I'm inclined to say, file a regression bug. If opCmp is defined but opEquals isn't, the compiler should auto-generate opEquals (as opCmp(...)==0). Requiring the user to implement a separate opEquals when opCmp is already there is nonsensical, and opens the door to stupid bugs due to increased boilerplate. (Of course, if the user also defines opEquals manually, that's fine. But if he doesn't, the compiler should do the Right Thing(tm).) Filed as https://issues.dlang.org/show_bug.cgi?id=13179 -- /Jacob Carlborg
Re: GC on Unreal Engine
Am 21.07.2014 18:05, schrieb fra: On Sunday, 20 July 2014 at 10:01:27 UTC, Paulo Pinto wrote: Since this theme keeps being discussed. Here is some info how Unreal Engine makes use of GC in C++. https://wiki.unrealengine.com/Garbage_Collection_Overview -- Paulo If that wiki page is up-to-date (and I don't see why it shouldn't be) then GC functionality inside of Unreal Engine is so much limited it's not even funny Did you followed the links? C++ semantics are not GC friendly, but it seemed kind of ok to me. Anyway, I just skimmed through it. -- Paulo
Re: Integer overflow and underflow semantics?
On 07/21/14 16:32, bearophile via Digitalmars-d wrote: https://github.com/D-Programming-Language/dmd/pull/1803 Disallowing integer overflow just at CT is not (sanely) possible in a language with D's CTFE capabilities. (Would result in code that compiles and works at runtime, but is not ctfe-able) artur
Re: Integer overflow and underflow semantics?
On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via Digitalmars-d wrote: Disallowing integer overflow just at CT is not (sanely) possible in a language with D's CTFE capabilities. (Would result in code that compiles and works at runtime, but is not ctfe-able) I'd like to see compile time _constants_ be unbounded rational numbers with explicit truncation. It is when you assign it to an in-memory location that you need to worry about bounds. The same goes for calculations that doesn't do division. No need to copy the bad parts of C.
Re: Software Assurance Reference Dataset
On Sunday, 20 July 2014 at 07:27:36 UTC, Walter Bright wrote: What about the @continuation (http://en.wikipedia.org/wiki/Continuation-passing_style )? I doubt they'll want to use that attribute, either. Especially if that can be done with AST macros :D
Re: GCs in the news
On Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via Digitalmars-d wrote: On Sun, 2014-07-20 at 16:40 +, Paulo Pinto via Digitalmars-d wrote: […] Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package. Also, it is not entirely clear that AOT optimization can beat JIT optimization, at least on the JVM. They probably aren't mutually exclusive.
Stack trace linux/windows why the difference
Hello !
When getting runtime errors the stack trace on terminal is a lot
confuse and hard to work with simple tools like scite text
editor, also there is a difference between windows/linux, windows
get a bit better/clean stack trace and includes line numbers,
where is this info generated to try improve it ?
Chhers !
=windows
D:\tutorialdmd -gs -gc testStackTrace.d
D:\tutorialtestStackTrace.exe
finally: func2
object.Exception@testStackTrace.d(12): on func2
0x004020E4 in void testStackTrace.func2() at
D:\tutorial\testStackTrace.d(12)
0x0040210C in void testStackTrace.func3() at
D:\tutorial\testStackTrace.d(18)
0x00402118 in _Dmain at D:\tutorial\testStackTrace.d(22)
0x00403188 in void rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).runAll().void __lambda1()
0x0040315B in void rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).runAll()
0x00403074 in _d_run_main
0x00402A98 in main
0x00419C91 in mainCRTStartup
0x7598A55E in BaseThreadInitThunk
0x77E48F03 in RtlInitializeExceptionChain
0x77E48ED9 in RtlInitializeExceptionChain
=
=linux
$:~/dev/d/tutorial$ dmd -gs -gc testStackTrace.d
$:~/dev/d/tutorial$ ./testStackTrace
finally: func2
object.Exception@testStackTrace.d(12): on func2
./testStackTrace(void testStackTrace.func3()+0x9) [0x434ef1]
./testStackTrace(_Dmain+0x9) [0x434f01]
./testStackTrace(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f)
[0x438a4f]
./testStackTrace(void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x4389a2]
./testStackTrace(void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll()+0x30) [0x438a08]
./testStackTrace(void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x4389a2]
./testStackTrace(_d_run_main+0x193) [0x438923]
./testStackTrace(main+0x25) [0x435acd]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)
[0x7f9227bfe76d]
=
=testStackTrace.d
import std.stdio;
void func1()
{
//int x, z = 2/x;
}
void func2()
{
try { func1(); }
catch(Exception e) { writeln(catch %s, e.msg);}
finally {writeln(finally: func2); throw new Exception(on
func2);}
}
void func3()
{
func2();
}
void main()
{
func3();
}
=
Re: Stack trace linux/windows why the difference
After writing this post I found the place and the why: - druntime/src/core/runtime.d - Window implementation has extra code that search for more info to display - Linux only make calls to execinfo functions and dump what it gets On linux more work should be done to get line infos, I'm investigating how to get then. Cheers !
Re: Integer overflow and underflow semantics?
On 07/21/14 21:53, via Digitalmars-d wrote:
On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via Digitalmars-d
wrote:
Disallowing integer overflow just at CT is not (sanely) possible
in a language with D's CTFE capabilities. (Would result in code
that compiles and works at runtime, but is not ctfe-able)
I'd like to see compile time _constants_ be unbounded rational numbers with
explicit truncation. It is when you assign it to an in-memory location that
you need to worry about bounds. The same goes for calculations that doesn't
do division.
No need to copy the bad parts of C.
Actually, C/C++ could get away with treating overflow during constant
folding as an error (or at least emitting a warning) because of the
lack of CTFE (and no templates in C's case). The code will either
compile or it won't.
For D that is not possible -- if an expression is valid at run-time
then it should be valid at compile-time (and obviously yield the same
value). Making this aspect of CT evaluation special would make CTFE
much less useful and add complexity to the language for very little gain.
Trying to handle just a subset of the problem would make things even
worse -- /some/ code would not be CTFE-able and /some/ overflows wouldn't
be caught.
int f(int a, int b) { return a*b; }
enum v = f(100_000, 100_000);
artur
Re: Software Assurance Reference Dataset
Andrew Godfrey x...@y.com wrote: 1) A function annotation that means I will call myself recursively, and when I do, I expect the tail recursion optimization. I have seen code which allocates something big on the stack and depends on the optimization. So this intent should be expressible. Wouldn't it be more useful to have a modified/annotated return statement for that? Tail-recursiveness is an implementation detail, for the user of the function it's not really interesting. Except for the fact that it has bounded stack size which is a useful property by itself and not only for tailrecursive functions. Tobi
Re: Software Assurance Reference Dataset
Tobias Müller: Wouldn't it be more useful to have a modified/annotated return statement for that? I don't know. Tail-recursiveness is an implementation detail, for the user of the function it's not really interesting. Yes, in theory a @tailrec annotation doesn't change the mangling of the function. But D has exceptions and stack traces. A stack trace for an annotated function is different because there are less stack frames... Except for the fact that it has bounded stack size which is a useful property by itself and not only for tailrecursive functions. Yes, that's why I have said that a @continuation is a more general solution than @tailrec. Bye, bearophile
Re: Stack trace linux/windows why the difference
On linux more work should be done to get line infos, I'm investigating how to get then. Cheers ! That's the spirit!
Re: Software Assurance Reference Dataset
On 07/21/2014 06:40 AM, Andrei Alexandrescu wrote: On 7/20/14, 8:15 PM, Timon Gehr wrote: On 07/20/2014 10:50 PM, Walter Bright wrote: On 7/20/2014 3:27 AM, Dmitry Olshansky wrote: Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Traditional FP languages don't have loops, and so must do recursion. Uh... D has loops, even in pure functions, So does Haskell. import Control.Monad import Control.Monad.ST import Data.STRef factorial :: Integer - Integer factorial n = runST $ do r - newSTRef 1 forM_ [1..n] $ \i- modifySTRef r (*i) readSTRef r main = print $ factorial 5 -- 120 And that doesn't look awkward at all :o). -- Andrei Indeed. This just creates a variable, modifies it 'n' times in a loop and then reads the result.
Re: Software Assurance Reference Dataset
On 07/21/2014 06:56 AM, Walter Bright wrote: On 7/20/2014 8:15 PM, Timon Gehr wrote: On 07/20/2014 10:50 PM, Walter Bright wrote: On 7/20/2014 3:27 AM, Dmitry Olshansky wrote: Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Traditional FP languages don't have loops, and so must do recursion. Uh... D has loops, even in pure functions, So does Haskell. import Control.Monad Uh-oh! Monad! :-) The example just uses the ST Monad which is quite similar to weakly pure statements in D.
Re: Software Assurance Reference Dataset
Andrei Alexandrescu: And that doesn't look awkward at all :o). -- Andrei A related thread: http://stackoverflow.com/questions/6622524/why-is-haskell-sometimes-referred-to-as-best-imperative-language Bye, bearophile
Re: Review: std.logger
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote: Pros The lighning talk about the std.logger proposal at DConf 2014 had a positive impact. We were able to change the Current D Use entry of our company from Uses D2 / Phobos, Tango (log, xml) to Uses D2 / Phobos, Tango (xml). (We got rid of tango.util.log; we still rely on the fast tango.text.xml.) I didn't expect to hear from you about this, after you did not reply to my email about this topic. If xml is problem for you, where is the PR? Cons 1. I am not happy with the (reverse) hungarian-style naming At least in the code of our company, logging a formatted string is the basic use case. The function for the basic use case should not require a suffix letter. The consistency argument, that 'infof' is like 'writef', does not fully apply: neither 'infoln' nor 'infofln' make sense. (In my opinion, half consistent is inconsistent.) so we have gone full circle now Currently, suffix 'c' is used for conditional logging. But, how will future extensions like glog's LOG_EVERY_N or LOG_FIRST_N be named? That's an easy one. ``` auto a = LOG_FIRST_N(1337); logc(a, Hello world); auto b = WHAT_EVERY_THE(); logc(b, Hello world again); ``` With suffix 'e'? Suffix 'f' is already assigned! what is 'e'? The suffix letter sequence seems to be the road to confusion. I would prefer the explicit naming of the previous std.log proposal: log.when(condition)(...) However, there is only a small advantage over if (condition) log(...) ... 2. No support for 24/7 (server) applications In my opinion, I really need logging for applications that possibly run forever. With the FileLogger, the file will grow forever. That's why most other frameworks provide something like a RollingFileLogger or some logrotate-aware FileLogger. By the way: Instead of what I really need, I get a NullLogger. I have no clue, why I never ever missed such an oddity. That was a user request, through github. Where I asked you to submit PRs and issues. Have you tried subclassing Logger? I asked for PRs in the email I wrote to you at least twice. 3. Implementation is hidden behind 'mixin' expressions When I tried to look at the implementation, I found long sequences of lines like this: mixin(buildLogFunction(true, false, false, LogLevel.info)); Nowadays, this changed into: mixin(freeLog.format( info, info, info, info, info, info, info, info, info, info, info, info, info, info, info, info)); This is much better, but I still think, it's a complicated solution for a simple problem. And it would be a shame for D, if there is no simple solution. Yes please, suggestions? Small stuff --- 4. FileLogger needs flush It's annoying when the events that caused a crash have been logged, but they never have been written to the file. I will fix that in the next session. 5. Suspect use of '__gshared' The FileLogger has a field private __gshared File file_; In this case, __gshared is equivalent to static. This means that all FileLogger instances share the same file! I missed that, thank you 6. Bad naming of StdIOLogger Like 'std.stdio.StdioException', the 'io' should be lower case. If the 'StdIOLogger' logs to 'stdout', 'StdoutLogger' would be preferable. easy fix 7. No need for StdIOLogger 'stdout' (and 'stderr') are Files, so a FileLogger should be able to handle them. A second constructor should do the trick. It is a special file, I wanted to have that clear. two different classes does the trick for me. 8. Log levels Many frameworks mix the types log level and set of log levels (for filtering). While 'trace', ..., 'fatal' are log levels, 'all' and 'off' (better: 'none'?) are sets of log levels. (I have no idea about the type of 'unspecific'.) A clean separation would avoid confusion: why is there 'info(...)' but not 'all(...)'? unspecific is about to be removed, all and off are pretty easy to understand but than Also, it would be easier to log for example 'trace' and 'info' to 'stdout'. not if you want to have that logged somewhere else. 9. Bad naming of std.logger The focus of this proposal is on the log/logging API; the loggers are only examples. The recommended use should be import log = std.logger; you got that wrong, you can do it like that, nobody will force you and properly people will do it different. You can also create a module wide global logger and use that Again, std.logger is not the solution that works for every special case anybody comes up with out of the box. It is a set of ideas that enable you to have the logging tailored to your needs easily. On top of that, it allows you very fast access to basic logging that can be extend later on easily and seamlessly. Then, the name std.log (of the previous proposal) would be more appropriate. Counter Proposal As a
Re: Software Assurance Reference Dataset
On 07/22/2014 12:10 AM, bearophile wrote: Except for the fact that it has bounded stack size which is a useful property by itself and not only for tailrecursive functions. Yes, that's why I have said that a @continuation is a more general solution than @tailrec. Bye, bearophile (Continuations and a tail calls are not the same kind of thing.) http://en.wikipedia.org/wiki/Continuation#First-class_continuations http://en.wikipedia.org/wiki/Delimited_continuation http://en.wikipedia.org/wiki/Tail_call
Re: Stack trace linux/windows why the difference
On Monday, 21 July 2014 at 21:06:54 UTC, Domingo Alvarez Duarte wrote: After writing this post I found the place and the why: - druntime/src/core/runtime.d - Window implementation has extra code that search for more info to display - Linux only make calls to execinfo functions and dump what it gets On linux more work should be done to get line infos, I'm investigating how to get then. Cheers ! Worth looking at: https://github.com/bombela/backward-cpp
Re: Integer overflow and underflow semantics?
On Monday, 21 July 2014 at 14:32:38 UTC, bearophile wrote:
Basile Burg:
If you still feel ok today then dont read this:
-
module meh;
import std.stdio;
//https://stackoverflow.com/questions/24676375/why-does-int-i-1024-1024-1024-1024-compile-without-error
static shared immutable int o = 1024 * 1024 * 1024 * 1024;
void main(string args[])
{
writeln(o);
}
-
See:
https://issues.dlang.org/show_bug.cgi?id=4835
https://github.com/D-Programming-Language/dmd/pull/1803
Bye,
bearophile
oOPS...I've just missed an oportunity to shut up my
mouth...However, I'm glad to see that someone else noticed that
the real issue is that it's a const.
Re: Software Assurance Reference Dataset
On 7/21/2014 3:25 PM, Timon Gehr wrote: The example just uses the ST Monad which is quite similar to weakly pure statements in D. D doesn't have weakly pure statements - it has weakly pure functions.
Re: Integer overflow and underflow semantics?
On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via
Digitalmars-d wrote:
For D that is not possible -- if an expression is valid at
run-time
then it should be valid at compile-time (and obviously yield
the same
value). Making this aspect of CT evaluation special would make
CTFE
much less useful and add complexity to the language for very
little gain.
CT and runtime give different results for floats.
Overflow in the end result without explicit truncation should be
considered a bug. Bugs can yield different results.
Overflow checks on add/sub expressions mess up reordering
optimizations. You only care about overflows in the end result.
Exact, truncating, masking/wrapping or saturating math results
should be explicit. (It is a flaw to use the same div operator
for floats and ints.) It should be the programmers resposibility
to provide the proofs or turn on extra precision in debug mode.
Turning off reordering optimizations and add checks ought to be
the rare case for both ints and floats.
Ideally all ctfe would be done as real intervals with rational
bounds, then checked against the specified precision of the end
result (or numerically solving the whole expression to the
specified precision).
Trying to handle just a subset of the problem would make things
even
worse -- /some/ code would not be CTFE-able and /some/
overflows wouldn't
be caught.
int f(int a, int b) { return a*b; }
enum v = f(100_000, 100_000);
NUMBER f(NUMBER a, NUMBER b) ...
Re: Can't Link DWT in Linux 64-bit
On 2014-07-20 01:40, Mike wrote: Interesting! How was the original port from SWT to DWT done? Was some utility used? It's manually ported. There was a try to create a tool [1] to automatically port the code but that required a too big part of the Java standard library to be ported as well. [1] http://dsource.org/projects/tioport -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-20 15:52, Jacob Carlborg wrote: It's manually ported. There was a try to create a tool [1] to automatically port the code but that required a too big part of the Java standard library to be ported as well. It might be worth investigation to try and do an automatic port again. I had a look and saw that in Java 6 there's an API for parsing Java. It would be really nice to have completely automatic tool for porting. It could be hard coded for SWT, I think Tioport tried to be usable for other Java projects. -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On Sunday, 20 July 2014 at 19:33:35 UTC, Jacob Carlborg wrote: On 2014-07-20 15:52, Jacob Carlborg wrote: It's manually ported. There was a try to create a tool [1] to automatically port the code but that required a too big part of the Java standard library to be ported as well. It might be worth investigation to try and do an automatic port again. I had a look and saw that in Java 6 there's an API for parsing Java. It would be really nice to have completely automatic tool for porting. It could be hard coded for SWT, I think Tioport tried to be usable for other Java projects. Well, what's the GUI future of D? Does DWT have a role to play? Mike
Re: Can't Link DWT in Linux 64-bit
On 21/07/14 03:00, Mike wrote: Well, what's the GUI future of D? Does DWT have a role to play? If we could make the process completely automatic (or nearly automatic) to make it easy to keep up with SWT. And also create a GUI builder then I think DWT is in a very good position. -- /Jacob Carlborg
Re: Can't Link DWT in Linux 64-bit
On 2014-07-21 11:52, Mike wrote: Or, is there a utility out there that can dump Java source to xml or something more consumable by D? Then I might have some hope. No, not that I know of. You might be able to find a Java grammar for some parser generator that could be used. But, as I wrote in the other post, I think semantic analyze is required to do this well enough. -- /Jacob Carlborg
mixin assembler does not work?
Hey guys. Can someone explain me, why this code does only works
with the inline assembler version but not with the mixin?
Thanks in advance!
Code:
import std.stdio : writeln;
import std.conv : to;
template Vala(uint count, alias arr) {
immutable string c = to!string(count);
enum Vala = asm { sub ESP, ~ c ~ ; mov ~ arr.stringof ~ ,
~ c ~ ; mov ~ arr.stringof ~ + 4, ESP; };
}
void main() {
ubyte[] a;
writeln(a.length);
static if (false) {
asm {
sub ESP, 1000; // Reserve 1000 bytes
mov a, 1000;// Set a.length = 1000
mov a + 4, ESP; // Set a[0] to reserved bytes
}
} else {
mixin Vala!(1000, a);
}
writeln(a.length);
}
Re: mixin assembler does not work?
sigod: , but I see few mistakes in your code: What's unfortunate is the silence of the compiler about that programmer mistake :-) Bye, bearophile
Re: mixin assembler does not work?
For clarification: how would that work without mixin + string?
Re: mixin assembler does not work?
enum Vala(uint count, alias arr) = format(
asm {
sub ESP, %d; // Reserve 'count' bytes
mov %s, %d; // Set a.length = 'count'
mov %s + 4, ESP; // Set a[0] to reserved bytes
}, count, arr.stringof, count, arr.stringof);
I'd like to write that more like this:
enum Vala(uint count, alias arr) = format(
asm {
sub ESP, %%(count); // Reserve 'count' bytes
mov %%(arr.stringof), %%(count); // Set a.length = 'count'
mov %%(arr.stringof) + 4, ESP; // Set a[0] to reserved
bytes
});
See:
http://fslang.uservoice.com/forums/245727-f-language/suggestions/6002107-steal-nice-println-syntax-from-swift
Bye,
bearophile
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:44:07 UTC, sigod wrote:
On Sunday, 20 July 2014 at 14:18:58 UTC, Foo wrote:
template Vala(uint count, alias arr) {
immutable string c = to!string(count);
enum Vala = asm { sub ESP, ~ c ~ ; mov ~ arr.stringof ~
,
~ c ~ ; mov ~ arr.stringof ~ + 4, ESP; };
}
...
mixin Vala!(1000, a);
I'm not sure how to do it, but I see few mistakes in your code:
1. You declaring it as a string. (Or your intend to use
`mixin()`?)
2. You trying to use `template` as a [`mixin template`][0].
[0]: http://dlang.org/template-mixin
Yeah, it now works with mixin(Vala!(1000, a)); I thought that
both are the same.
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:46:32 UTC, bearophile wrote:
enum Vala(uint count, alias arr) = format(
asm {
sub ESP, %d; // Reserve 'count' bytes
mov %s, %d; // Set a.length = 'count'
mov %s + 4, ESP; // Set a[0] to reserved bytes
}, count, arr.stringof, count, arr.stringof);
I'd like to write that more like this:
enum Vala(uint count, alias arr) = format(
asm {
sub ESP, %%(count); // Reserve 'count'
bytes
mov %%(arr.stringof), %%(count); // Set a.length =
'count'
mov %%(arr.stringof) + 4, ESP; // Set a[0] to
reserved bytes
});
See:
http://fslang.uservoice.com/forums/245727-f-language/suggestions/6002107-steal-nice-println-syntax-from-swift
Bye,
bearophile
It seems that your code doesn't work with 2.065.
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:55:00 UTC, Foo wrote:
For clarification: how would that work without mixin + string?
I tried this:
mixin template Vala2(uint count, alias arr) {
asm {
sub ESP, count;
mov arr, count;
mov arr + 4, ESP;
}
}
but I get several errors. Unfortunately it seems that asm cannot
be used in mixin templates?!
