Re: D2 port of Sociomantic CDGC available for early experiments
On Friday, 17 October 2014 at 05:38:05 UTC, thedeemon wrote: Gentlemen, do I understand correctly that you're trying to find a Windows-friendly switch to something that will never see the light on Windows (because of being based on fork)? No we want general runtime configuration, not only for the forking GC. https://github.com/D-Programming-Language/druntime/pull/986
Re: D2 port of Sociomantic CDGC available for early experiments
On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
Regan Heath, el 14 de October a las 11:11 me escribiste:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very windows friendly/like solution.
As mentioned you don't have to use a unique cross-platform solution, you
can have different solutions for different OSs. No need to lower down to
the worse solution.
You've got it backwards. I'm looking for a *better* solution than
environment variables, which are a truly horrid way to control runtime
behaviour IMHO. Something built into the language or runtime itself.
And, better yet would be something that is more generally useful - not
limited to GC init etc.
Wouldn't it be more generally useful to have another function like
main() called init() which if present (optional) is called
before/during initialisation. It would be passed the command line
arguments. Then a program can chose to implement it, and can use it
to configure the GC in any manner it likes.
Seems like this could be generally useful in addition to solving
this issue.
It is nice, but a) a different issue, this doesn't provide
initialization time configuration.
I don't follow. You want to execute some code A before other code B
occurs. This meets that requirement - assuming init() is called at the
point you need it to be called.
Think of development vs. devops. If
devops needs to debug a problem they could potentially re-run the
application activating GC logging, or GC stomping. No need to recompile,
no need to even have access to the source code.
./application -gclog
./application -gcstomp
..code..
init(string[] args)
{
if ..
}
Not need to recompile.
Some GC options might make sense for all D applications, in that case the
compiler default init() could handle those and custom init() functions
would simply call it, and handle any extra custom options.
Other GC/allocation options might be very application specific i.e.
perhaps the application code cannot support RC for some reason, etc.
And b) where would this init() function live? You'll have to define it
always
Surely not.
, even if you don't want to customize anything, otherwise the
compiler will have to somehow figure out if one is provided or not and
if is not provided, generate a default one. Not a simple solution to
implement.
Sounds pretty trivial to me.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: SDC-32bit
New backend why ?
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 17 de October a las 10:55 me escribiste: Regan Heath, el 14 de October a las 11:11 me escribiste: I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) As mentioned this is not a very windows friendly/like solution. As mentioned you don't have to use a unique cross-platform solution, you can have different solutions for different OSs. No need to lower down to the worse solution. You've got it backwards. I'm looking for a *better* solution than environment variables, which are a truly horrid way to control runtime behaviour IMHO. OK, then this is now a holly war. So I'll drop it here. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Mi infancia fue en un loft, bien al costado del río Cazabamos correcaminos y lo asábamos en el fogón Después? Después me vine grande y la ciudad me deslumbró Jugando al tejo en Lavalle me hice amigo del bongó
Re: D2 port of Sociomantic CDGC available for early experiments
Marginally related: Page fault handling in user space. http://lwn.net/Articles/615086/ Maybe this can be used as an alternative to forking.
Re: Mono-D v2.5 - dub buildTypes
On Thursday, 16 October 2014 at 23:32:22 UTC, Alexander Bothe wrote: Hi everyone, just gave the second drop down box in Xamarin Studio a use: Selection of build types for dub projects. Furthermore, please don't rage silently somewhere - tell me about issues with Mono-D on github or in #d.mono-d on freenode! http://wiki.dlang.org/Mono-D https://github.com/aBothe/Mono-D/issues Cheers thanks to everyone, Alex Sweet
Re: CUDA bindings
On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote: More APIs could be implemented if the interest happens to be non-null. Interest non-null, this is awesome.
Re: Mono-D v2.5 - dub buildTypes
On Thursday, 16 October 2014 at 23:32:22 UTC, Alexander Bothe wrote: Cheers thanks to everyone, Alex What a hardwork are you doing, Alex! Kudos!
Re: CUDA bindings
On 10/17/14, 7:58 AM, Tofu Ninja wrote: On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote: More APIs could be implemented if the interest happens to be non-null. Interest non-null, this is awesome. Let it ride! http://www.reddit.com/r/programming/comments/2jiv21/derelictcuda_dynamic_bindings_to_the_cuda_library/ https://twitter.com/D_Programming/status/523135615521415171 Andrei
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 17 de October a las 15:43 me escribiste: You've got it backwards. I'm looking for a *better* solution than environment variables, which are a truly horrid way to control runtime behaviour IMHO. OK, then this is now a holly war. So I'll drop it here. I think you've mistook my tone. I am not religious about this. I just think it's a bad idea for a program to alter behaviour based on a largely invisible thing (environment variable). It's far better to have a command line switch staring you in the face. But it's not the same. I don't mean to be rude, but all you (and Walter) are saying about environment is evidence of not knowing how useful they are in POSIX OSs, what's the history in those OSs and what people expect from them. All these fear about how this can obscurely affect programs is totally unfunded. That just does not happen. Not at least commonly enough to ignore all the other advantages of it. If you keep denying it usefulness and how they are different from command-line arguments, we'll keep going in circles. Plus as Walter mentioned the environment variable is a bit like a shotgun, it could potentially affect every program executed from that context. We have a product here which uses env vars for trace flags and (without having separate var for each process) you cannot turn on trace for a single process in an execution tree, instead each child inherits the parent environment and starts to trace. So, your example is a D program, that spawns other D programs, so if you set an environment variable to affect the behaviour of the starting program, you affect also the behaviour of the child programs. This is a good example, and I can argue for environment variables for the same reason. If I want to debug this whole mess, using command-line options there is no way I can affect the whole execution tree to log useful debug information. See, you proved my point, environment variables and command-line arguments are different and thus, useful for different situations. And.. when some of those flags have different meanings in different processes it gets even worse. Why would they? Don't create problems where there are any :) Especially if one of those flags prints debugging to stdout, and the process is run as a child where input/output are parsed.. it just plain doesn't work. It's a mess. If you write to stdout (without giving the option to write to a log file) then what you did is just broken. Again, there is no point in inventing theoretical situations where you can screw anything up. You can always fabricate those. Let's stay on the domain of reality :) In all the years I've been working in Linux I never, EVER came across problems with environment variables being accidentally set. I find it very hard to believe this is a real problem. On the other hand, they saved my ass several times (LD_PRELOAD I LOVE YOU). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Le pedí que me enseñe a usar el mouse Pero solo quiere hablarme del Bauhaus Le pregunté si era chorra o rockera Me dijo Gertrude Stein era re-tortillera Me hizo mucho mal la cumbiera intelectual
Re: D2 port of Sociomantic CDGC available for early experiments
On 10/17/14, Leandro Lucarella via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: In all the years I've been working in Linux I never, EVER came across problems with environment variables being accidentally set. I find it very hard to believe this is a real problem. On the other hand, they saved my ass several times (LD_PRELOAD I LOVE YOU). Slightly OT, but having to use Linux for the past 5 months and using almost exclusively Windows before that for the better part of the last ~20 years, I have to say I've become a massive fan of the OS and the way things work. I've come to even hate anything GUI (except maybe the editor), I'd hate to even think about browsing the file system with a mouse anymore. Of course, all of this functionality was available on Windows as well, but what I'm saying is a switch in one's environment (pardon the pun :p) can make them realize that they may have been doing things the slow or inefficient way. So it's not so much about OS A vs OS B, but how used you are to doing things one way. Maybe that's why there's this aversion towards using environment variables. Anyway those were my 2 eurocents..
Re: SDC-32bit
On Friday, 17 October 2014 at 10:39:15 UTC, Temtaime wrote: New backend why ? Because I want to code a backend. I want output C or maybe even Cool ... generating UML via a backend would also be nice.
Endovena: a dependency injection framework.
Hi all, I'd like to announce the initial version of endovena, a dependency injection framework. It's based on dejector, a great work by Jakub Stasiak, with some new features borrowed from dryioc (C# IoC) I would be glad to see any feedback, Thank you. * [endovena] https://github.com/o3o/endovena Boost License 1.0 * [dejector](https://github.com/jstasiak/dejector) * [dryioc](https://bitbucket.org/dadhi/dryioc)
Re: D2 (Debian) + MSSQL
Any help?
Re: Consistent bugs with dmd -O -inline in a large project
On 16 Oct 2014 23:01, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thu, 16 Oct 2014 21:53:40 + Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: I had planned to use GDC/LDC too, but GDC is 2.064 GDC is 2.065. And soon to be 2.066 as soon as I apply the last 244 patches between May and the final release date. Iain.
Re: D2 (Debian) + MSSQL
Sorry, everything turned out simply, I'm very inattentive ...
Re: Program logic bugs vs input/environmental errors
No, right now one can affect the way tests are run by simply replacing the runner to a custom one and it will work for any amount of modules compiled in. Beauty of `unittest` block approach is that it is simply a bunch of functions that are somewhat easy to discover from the combined sources of the program - custom runner can do pretty much anything with those. Or it could if not the issue with AssertError and cleanup. Is cleaning up in a unittest build a problem? I'd say no, if it the tests fail it doesn't make much sense to clean up unless it affects the reporting of tests failing. I catch assertion errors in unit-threaded exactly to support the standard unittest blocks and can't see why I'd care about clean-up. At least in practice it hasn't been an issue, although to be fair I haven't used that functionality a lot (of using unit-threaded to run unittest blocks). Atila
Re: GCC Undefined Behavior Sanitizer
On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ Bye, bearophile The sad thing about this tools is that they are all about fixing the holes introduced by C into the wild. So in the end when using C and C++, we need to have compiler + static analyzer + sanitizers, in a real life example of Worse is Better, instead of fixing the languages. At least, C++ is on the path of having less undefined behaviors, as the work group clearly saw the benefits don't outweigh the costs and is now the process of cleaning the standard in that regard. As an outsider, I think D would be better by having only defined behaviors. -- Paulo
Re: Consistent bugs with dmd -O -inline in a large project
On Thursday, 16 October 2014 at 22:01:37 UTC, ketmar via Digitalmars-d wrote: On Thu, 16 Oct 2014 21:53:40 + Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: I had planned to use GDC/LDC too, but GDC is 2.064 GDC is 2.065. But why does it say 2.064 here http://dlang.org/download.html? Andrei mentioned that DMD built programs are only around 10% slower than GDC/LDC builds it depends of the task. my voxel renderer runs with miserable 15 FPS with dmd -O -inline, yet with much more appropriate 40 FPS with gdc -O2. but it's a specific task, many other software can work with reasonable speed.
Re: Consistent bugs with dmd -O -inline in a large project
On Friday, 17 October 2014 at 07:02:53 UTC, Iain Buclaw via Digitalmars-d wrote: On 16 Oct 2014 23:01, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thu, 16 Oct 2014 21:53:40 + Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: I had planned to use GDC/LDC too, but GDC is 2.064 GDC is 2.065. And soon to be 2.066 as soon as I apply the last 244 patches between May and the final release date. Iain. Thanks. Good to know.
Re: Consistent bugs with dmd -O -inline in a large project
On 17 October 2014 09:53, Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thursday, 16 October 2014 at 22:01:37 UTC, ketmar via Digitalmars-d wrote: On Thu, 16 Oct 2014 21:53:40 + Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: I had planned to use GDC/LDC too, but GDC is 2.064 GDC is 2.065. But why does it say 2.064 here http://dlang.org/download.html? dlang.org is not like a wiki. If I were to send a PR to change that to 2.065, the site probably won't be updated until the 2.067 release, by which point that information will be wrong again. Iain
core.thread.memcpy conflicts with core.stdc.string.memcpy
When I read that error I wondered why anyone would define a
function for threads with the same name as a well established
C function. On a closer look it revealed to be just another
name for the same extern(C) memcpy to avoid the import of
core.stdc.string in core.thread:
private
{
import core.sync.mutex;
import core.atomic;
//
// from core.memory
//
extern (C) void gc_enable();
extern (C) void gc_disable();
extern (C) void* gc_malloc(size_t sz, uint ba = 0);
//
// from core.stdc.string
//
extern (C) void* memcpy(void*, const void*, size_t);
//
// exposed by compiler runtime
//
extern (C) void rt_moduleTlsCtor();
extern (C) void rt_moduleTlsDtor();
alias void delegate() gc_atom;
extern (C) void function(scope gc_atom) gc_atomic;
}
Well, it is mildly annoying. `private` doesn't really help in
the way the author expected it to work here.
--
Marco
C++ Ranges proposal for the Standard Library
I saw [this][0] proposal for adding ranges to C++'s standard library. The [paper][1] looks at D style ranges, but concludes: Since iterators can implement D ranges, but D ranges cannot be used to implement iterators, we conclude that iterators form a more powerful and foundational basis. What do you guys think? [0]: https://isocpp.org/blog/2014/10/ranges [1]: https://ericniebler.github.io/std/wg21/D4128.html
Re: GCC Undefined Behavior Sanitizer
Am Fri, 17 Oct 2014 08:38:11 + schrieb Paulo Pinto pj...@progtools.org: On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ Bye, bearophile The sad thing about this tools is that they are all about fixing the holes introduced by C into the wild. So in the end when using C and C++, we need to have compiler + static analyzer + sanitizers, in a real life example of Worse is Better, instead of fixing the languages. At least, C++ is on the path of having less undefined behaviors, as the work group clearly saw the benefits don't outweigh the costs and is now the process of cleaning the standard in that regard. As an outsider, I think D would be better by having only defined behaviors. -- Paulo I have a feeling back then the C designers weren't quite sure how the language would work out on current and future architectures, so they gave implementations some freedom here and there. Now that C/C++ is the primary language for any architecture, the table turned and the hardware designers build chips that behave as expected in some cases that C/C++ left undefined. That in turn allows C/C++ to become more restrictive. Or maybe I don't know what I'm talking about. What behavior is undefined in D? I'm not kidding, I don't really know of any list of undefined behaviors. The only thing I remember is casting away immutable and modifying the content is undefined behavior. Similar to C/C++ I think this is to allow current and future compilers to perform as of yet unknown optimizations on immutable data structures. Once such optimizations become well known in 10 to 20 years or so, D will define that behavior, too. Just like C/C++. -- Marco
Re: So what exactly is coming with extended C++ support?
On Thursday, 16 October 2014 at 05:45:00 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 16 October 2014 at 03:53:53 UTC, Daniel N wrote:
There's no impact, we already support it since the template is
instantiated from C++ side.
But you don't know the return type of the templated function
until you know which combination of templates it instantiated?
Yes, but this is true already today for enable_if?
templatetypename T
std::enable_if_tstd::is_sameT, int::value, float
fun(const T f)
{
return f;
}
templatetypename T
std::enable_if_tstd::is_sameT, float::value, int
fun(const T f)
{
return f;
}
// Explicit Template Instantiation
template float fun(const int);
template int fun(const float);
Re: Consistent bugs with dmd -O -inline in a large project
On Friday, 17 October 2014 at 09:15:37 UTC, Iain Buclaw via Digitalmars-d wrote: On 17 October 2014 09:53, Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thursday, 16 October 2014 at 22:01:37 UTC, ketmar via Digitalmars-d wrote: On Thu, 16 Oct 2014 21:53:40 + Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: I had planned to use GDC/LDC too, but GDC is 2.064 GDC is 2.065. But why does it say 2.064 here http://dlang.org/download.html? dlang.org is not like a wiki. If I were to send a PR to change that to 2.065, the site probably won't be updated until the 2.067 release, by which point that information will be wrong again. Iain I see, I see. But that should really be updated on the D homepage. After all it's the first port of call for D programmers. If I cannot trust the information there ...
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 08:38:12 UTC, Paulo Pinto wrote:
As an outsider, I think D would be better by having only
defined behaviors.
Actually, this is the first thing I would change about D and make
it less dependent on x86. I think a system level language should
enable max optimization on basic types and rather inject
integrity tests for debugging/testing or support debug-exceptions
where available.
The second thing I would change is to make whole program analysis
mandatory so that you can deduce and constrain value ranges. I
don't believe the argument about separate compilation and
commercial needs (and even then augmented object code is a
distinct possibility). Even FFI is not a great argument, you
should be able to specify what can happen in a foreign function.
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour. The correct
thing to do is to inject overflow checks in debug mode and let
overflow in results (that are accessed) be undefined. Otherwise
you end up giving the compiler a difficult job:
uint y=x+1;
if (x y){…}
Should be optimized to:
{…}
In D (and C++) you would get:
if (x ((x+1)0x)){…}
As a result you are encouraged to use signed int everywhere in
C++, since unsigned ints use modulo-arithmetic. Unsigned ints in
C++ are only meant for bit-field stuff. And the C++ designers
admit that the C++ library is ill-specified because it uses
unsigned ints for integers that cannot be negative, while that is
now considered a bad practice…
In D it is even worse since you are forced to use a fixed size
modulo even for int, so you cannot do 32 bit arithmetic in a 64
bit register without getting extra modulo operations.
So, undefined behaviour is not so bad, as long as you qualify
it. You could for instance say that overflow on ints leads to an
unknown value, but no other side effects. That was probably the
original intent for C, but compiler writers have taken it a step
further…
D has locked itself to Pentium-style x86 behaviour. Unfortunately
it is very difficult to have everything be well-defined in a low
level programming language. It isn't even obvious that a byte
should be 8 bits, although the investments in creating UTF-8
resources on the Internet probably has locked us to it for the
next 100 years… :)
Re: GCC Undefined Behavior Sanitizer
On 16 October 2014 22:00, bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ *cough* GDC *cough* :o)
Re: C++ Ranges proposal for the Standard Library
Am Fri, 17 Oct 2014 09:17:51 +
schrieb ZombineDev valid_em...@he.re:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot be
used to implement iterators, we conclude that iterators form a
more powerful and foundational basis.
What do you guys think?
[0]: https://isocpp.org/blog/2014/10/ranges
[1]: https://ericniebler.github.io/std/wg21/D4128.html
True. Iterators are more foundational, ranges are more
neat-o. ;)
When you look at this C++ function as part of a signal
processing home work you know why you don't want to see them
in top level code:
// C++
double mittelwert(const vectordouble vektor)
{
vectordouble::const_iterator it;
double summe = 0;
for (it = vektor.begin(); it != vektor.end(); ++it)
{
summe += *it;
}
return summe / vektor.size();
}
// D (removing iterators)
double mittelwert(in double[] vektor)
{
double summe = 0;
foreach (wert; vektor)
{
summe += wert;
}
return summe / vektor.length;
}
// D (using range sum function)
double mittelwert(in double[] vektor)
{
return sum(vektor) / vektor.length;
}
--
Marco
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
Am Fri, 17 Oct 2014 09:17:51 +
schrieb ZombineDev valid_em...@he.re:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot
be used to implement iterators, we conclude that iterators
form a more powerful and foundational basis.
What do you guys think?
[0]: https://isocpp.org/blog/2014/10/ranges
[1]: https://ericniebler.github.io/std/wg21/D4128.html
True. Iterators are more foundational, ranges are more
neat-o. ;)
When you look at this C++ function as part of a signal
processing home work you know why you don't want to see them
in top level code:
// C++
double mittelwert(const vectordouble vektor)
{
vectordouble::const_iterator it;
double summe = 0;
for (it = vektor.begin(); it != vektor.end(); ++it)
{
summe += *it;
}
return summe / vektor.size();
}
// D (removing iterators)
double mittelwert(in double[] vektor)
{
double summe = 0;
foreach (wert; vektor)
{
summe += wert;
}
return summe / vektor.length;
}
// D (using range sum function)
double mittelwert(in double[] vektor)
{
return sum(vektor) / vektor.length;
}
No, the equivalent implementation in C++ is this:
double mittelwert(const vectordouble vektor)
{
double summe = 0;
for(auto x : vektor)
{
summe += x;
}
return summe / vektor.size();
}
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 10:10:23 UTC, Olivier Grant wrote:
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
Am Fri, 17 Oct 2014 09:17:51 +
schrieb ZombineDev valid_em...@he.re:
No, the equivalent implementation in C++ is this:
double mittelwert_accumulate(const vectordouble vektor)
{
return accumulate(vektor.begin(), vektor.end(), 0.0) /
vektor.size();
}
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 09:46:49 UTC, Ola Fosheim Grøstad wrote: On Friday, 17 October 2014 at 08:38:12 UTC, Paulo Pinto wrote: The second thing I would change is to make whole program analysis mandatory so that you can deduce and constrain value ranges. Nice idea, but how to persuade libraries to play that game?
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 10:30:14 UTC, eles wrote: On Friday, 17 October 2014 at 09:46:49 UTC, Ola Fosheim Grøstad wrote: The second thing I would change is to make whole program analysis mandatory so that you can deduce and constrain value ranges. Nice idea, but how to persuade libraries to play that game? 1. Provide a meta-language for writing propositions that describes what libraries do if they are foreign (pre/post conditions). Could be used for asserts too. 2. Provide a C compiler that compiles to the same internal representation as the new language, so you can run the same analysis on C code. 3. Remove int so that you have to specify the range and make typedefs local to the library 4. Provide the ability to specify additional constraints on library functions you use in your project or even probabilistic information. Essentially it is a cultural thing, so the standard library has to be very well written. Point 4 above could let you specify properties on the input to a sort function on the call site and let the compiler use that information for optimization. E.g. if one million values are evenly distributed over a range of 0..10 then a quick sort could break it down without using pivots. If the range is 0..1000 then it could switch to an array of counters. If the input is 99% sorted then it could switch to some insertion-sort based scheme. If you allow both absolute and probabilistic meta-information then the probabilistic information can be captured on a corpus of representative test-data. You could run the algorithm within the measured probable range and switch to a slower algorithm when you detect values outside it. Lots of opportunities for improving state-of-the-art.
Re: GCC Undefined Behavior Sanitizer
On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ Bye, bearophile Not every software bug has as serious consequences as seen in the Ariane 5 rocket crash. if ubsan detects any problem, it outputs a “runtime error:” message, and in most cases continues executing the program. The latter won't really solve the former...
Re: Consistent bugs with dmd -O -inline in a large project
LDC is 2.065 Already 2.066 in the repo.
Re: So what exactly is coming with extended C++ support?
On Friday, 17 October 2014 at 09:39:27 UTC, Daniel N wrote: On Thursday, 16 October 2014 at 05:45:00 UTC, Ola Fosheim Grøstad wrote: But you don't know the return type of the templated function until you know which combination of templates it instantiated? Yes, but this is true already today for enable_if? That sounds right, but I think the combination of auto + concepts will make it easy to do and it might turn into a common paradigm… Composing the most efficient return object based on some constraints generally sounds like a good idea when people get used to using auto for capturing return types. After having watched some of the cppcon videos I am getting the impression that C++ will be more and more difficult to interface with without building clang into the compiler.
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 10:17:38 UTC, eles wrote:
double mittelwert_accumulate(const vectordouble vektor)
{
return accumulate(vektor.begin(), vektor.end(), 0.0) /
vektor.size();
}
templatetypename T
auto mittelwert_accumulate(const T vektor){
return accumulate(cbegin(vektor), cend(vektor), 0.0) /
distance(cbegin(a), cend(a))
}
(not tested :^)
Re: Postblit bug
Am Fri, 17 Oct 2014 00:42:24 + schrieb IgorStepanov wa...@mail.ru: OK, I've run into the same problem and there is no line number, just: Error: immutable method Lib.Sys.File.File.~this is not callable using a mutable object Error: mutable method Lib.Sys.File.File.~this is not callable using a immutable object haha! I should start from scratch. -- Marco
Re: template constraint diagnostics
On Fri, 17 Oct 2014 08:00:03 +0200 Marco Leise via Digitalmars-d digitalmars-d@puremagic.com wrote: ketmar gtfo ... oh wait, that's a great idea actually! ;-) signature.asc Description: PGP signature
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 11:44:29 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 17 October 2014 at 10:17:38 UTC, eles wrote:
(not tested :^)
templatetypename T
auto mittelwert_accumulate2(const T vektor) -typename
T::value_type
{
return accumulate(vektor.cbegin(), vektor.cend(),
static_casttypename T::value_type(0)) /
distance(vektor.cbegin(), vektor.cend());
}
(gcc does not yet support std::cbegin() and std::cend()).
(tested :^)
Re: Postblit bug
Am Fri, 17 Oct 2014 14:42:53 +0200
schrieb Marco Leise marco.le...@gmx.de:
Am Fri, 17 Oct 2014 00:42:24 +
schrieb IgorStepanov wa...@mail.ru:
OK, I've run into the same problem and there is no line
number, just:
Error: immutable method Lib.Sys.File.File.~this is not callable using a
mutable object
Error: mutable method Lib.Sys.File.File.~this is not callable using a
immutable object
haha! I should start from scratch.
Here is a reduced test case, that I wish I had before I
tried to make 1000 lines of code work with immutable:
struct B {
~this() { /* some cleanup */ }
}
struct C {
immutable B b;
}
void main() {
C(immutable B());
}
That's pretty much it. You cannot use compose a mutable struct
out of immutable ones with dtors.
--
Marco
Re: GCC Undefined Behavior Sanitizer
On Fri, 17 Oct 2014 09:46:48 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour.
do you know any widespread hardware with doesn't work this way?
yet i know very widespread language which doesn't care. by a strange
coincidence programs in this language tend to have endless problems
with overflows.
The correct
thing to do is to inject overflow checks in debug mode and let
overflow in results (that are accessed) be undefined.
the correct thing is to not turning perfectly defined operations to
undefined ones.
Otherwise
you end up giving the compiler a difficult job:
uint y=x+1;
if (x y){…}
Should be optimized to:
{…}
no, it shouldn't. at least not until there will be something like
'if_carry_set'.
In D (and C++) you would get:
if (x ((x+1)0x)){…}
perfect. nice and straightforward way to do overflow checks.
In D it is even worse since you are forced to use a fixed size
modulo even for int, so you cannot do 32 bit arithmetic in a 64
bit register without getting extra modulo operations.
why should i, as programmer, care? what i *really* care about is
portable code. having size of base types not strictly defined is not
helping at all.
So, undefined behaviour is not so bad
yes, it's not bad, it's terrible. having undefined behavior in
language is like saying hey, we don't know what to do with this, and
we don't want to think about it. so we'll turn our problem into your
problem. have a nice day, sucker!
You could for instance say that overflow on ints leads to an
unknown value, but no other side effects. That was probably the
original intent for C, but compiler writers have taken it a step
further…
how is this differs from the current interpretation?
D has locked itself to Pentium-style x86 behaviour.
oops. 2's complement integer arithmetic is pentium-style x86 now... i
bet x86_64 does everything in ternary, right? oh, and how about
pre-pentium era?
Unfortunately
it is very difficult to have everything be well-defined in a low
level programming language. It isn't even obvious that a byte
should be 8 bits
it is very easy. take current hardware, evaluate it's popularity, do
what most popular hardware does. that's it. i, for myself, don't need
a language for future hardware, i need to work with what i have now.
if we'll have some drastic changes in the future... well, we always can
emulate old HW to work with old code, and rewrite that old code for new
HW.
signature.asc
Description: PGP signature
Re: Consistent bugs with dmd -O -inline in a large project
On Fri, 17 Oct 2014 08:02:42 +0100 Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote: GDC is 2.065. And soon to be 2.066 as soon as I apply the last 244 patches between May and the final release date. yay! you're my hero, do you know that? ;-) signature.asc Description: PGP signature
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 13:27:37 UTC, eles wrote: (gcc does not yet support std::cbegin() and std::cend()). (tested :^) Thanks ;) Like your new version, but I don't think it will work with regular arrays and maybe the accumulator will overflow if you sum a large number of ubytes? I think C++14 will make stuff easier. :-)
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 09:17:52 UTC, ZombineDev wrote:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot be
used to implement iterators, we conclude that iterators form a
more powerful and foundational basis.
What do you guys think?
[0]: https://isocpp.org/blog/2014/10/ranges
[1]: https://ericniebler.github.io/std/wg21/D4128.html
One problem with C++ style iterators is composition, and their
exponential growth, due to their pair approach. Indeed, more
often than not, proper iteration *requires* the it *already*
know where the underlying iterator ends. For example, a stride
adapter iterator would look like this:
template typename It
struct StrideIt
{
It current;
It end;
void operator++()
{
++current;
if (current != end)
++current;
}
}
Then you combine it with:
StrideIdIt sit (it,itend);
StrideIdIt sitend(itend, itend);
for ( ; ++it ; it != itend)
...
As you can see, it quickly becomes bloated and cumbersome. In
particular, it takes *tons* of lines of code, traits and what not
to compose. C++11's auto make things somewhat simpler, but it
is still bloated.
Another issue is that iterators model a *pointer* abstraction.
Iterators *must* have reference_t. ranges are more generic in
the sense that they simply model iteration.
*THAT SAID*, as convenient as ranges are, they do suffer from the
shrink but can't grow issue. In particular, you can't really
cut a range the way you can with iterators: first, middle,
last. If you are using RA ranges with slicing, it doesn't show
too much. However, if you are using generic bidir ranges, on
containers such as DList, you really start to feel the pain.
My personal feeling (IMO):
- Consuming, adapting, producing data: Ranges win hands down.
- Managing, shuffling or inserting elements in a container: To be
honest, I prefer iterators.
Given how C++'s STL is container-centric, whereas D's phobos is
range centric, I can totally understand both sides' position.
Re: Postblit bug
On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via Digitalmars-d wrote: On Fri, 17 Oct 2014 00:42:24 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: Can someone comment this code? Should I think that it's a bug. it's just an anomaly. const postblit can do alot of things besides adjusting struct fields, and it's logical that compiler cannot call non-const methods for const objects. yet it's still on of those unforseen consequences that arises from conjunction of different features. i don't think that it's a bug, but i think that this must be discussed anyway, and then documented. AFAIK, Kenji has submitted a DIP, and has begun working on fixing the const/immutable/inout posblit issue. However, there are some very subtle corner cases, so (afaik) work is slow. To be honest, I think people use const way too much in D. It's *not* the C++ head const you can use anywhere. It's really just the base attribute between mutable and immutable data. In particular, due to the transitive nature of const, any time you use const it means you can't modify this, or anything produced or acquired from this, ever. It's usually not what people think they are signing for... When it makes little sense to have your type as immutable, then I don't think you should bother much
Re: How to iterate over const(RedBlackTree)?
On Friday, 17 October 2014 at 01:09:00 UTC, John McFarlane wrote: On Friday, 3 January 2014 at 07:22:32 UTC, monarch_dodra wrote: On Thursday, 2 January 2014 at 14:59:55 UTC, Adam D. Ruppe wrote: On Thursday, 2 January 2014 at 13:30:06 UTC, monarch_dodra wrote: Currently, this is not possible. Or if it was, it would have a *very* high code cost inside RBT. It is possible in theory; RBT returns a separate Range type with opSlice that is implemented in terms of pointers to node. (This is hidden by an alias RBNode!Elem* Node, which gets in the way, but if those were inout(RBNode)* or const()* it'd work). We can have mutable pointers to const data, which would work with the range. So opSlice returns a mutable range that points back to const data. But in this case, none of the functions in rbtree use const nor inout, and there's some caching (e.g. _left and _right) that I'm not sure can work with it at all anyway. In a const node, the left and right properties won't work.. Right. Doable, but not trivially so :/ Array might be able to pull it off more easily. That said, it would only solve the const container = Range issue, but the const range problem itself would remain :( I'm trying to get to grips with D, coming from a C++ background and const correctness is tough thing to get comfortable with. I've got a member variable that's RedBlackTree and I'd like to examine its contents inside an invariants() block. Is this possible at all right now? Obviously, this would be trivial to achieve using std::set::const_iterator so is it the language or the library that poses the difficulty for me? Thanks. Currently, D containers don't offer ConstRange opSlice() const (which would be the equivalent of const_iterator). This could be a good solution the the issue. But to answer your question: Both the language and library that are making your life difficult. For starters, the D language does not use const the way C++ does, so this usually confuses the zealous newcomers that want to be const correct. The library is also getting in your way in that it does not provide support for const(container/range) nor container of const.
Re: Will D ever get optional named parameters?
They are discussing about named arguments for C++: http://www.reddit.com/r/cpp/comments/2jiai2/n4172_named_arguments/ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm Bye, bearophile
Re: Postblit bug
On Fri, 17 Oct 2014 14:18:30 + monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote: To be honest, I think people use const way too much in D. It's *not* the C++ head const you can use anywhere. It's really just the base attribute between mutable and immutable data. In particular, due to the transitive nature of const, any time you use const it means you can't modify this, or anything produced or acquired from this, ever. It's usually not what people think they are signing for... When it makes little sense to have your type as immutable, then I don't think you should bother much const is a nice way to make sure that your data will not be modified. it needs some time to adjust your head to the fact that const is const all way down to the bytes, but then it's nice. yet i still missing c++-like const, which will not try to eat everything underneath. i.e. a way to tell compiler this field cannot be modified, but the data it points to can be changed. this will let me to get rid of annoying getters. signature.asc Description: PGP signature
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 13:44:24 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 09:46:48 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour.
do you know any widespread hardware with doesn't work this way?
Yes, the carry flag is set if you add with carry. It means you
SHOULD add to another hi-word with carry. :P
You can also add with clamp with SSE, so you clamp to max/min.
Too bad languages don't support it. I've always thought it be
nice to have clamp operators, so you can say x(+)y and have the
result clamped to the max/min values. Useful for stuff like DSP
on integers.
if (x ((x+1)0x)){…}
perfect. nice and straightforward way to do overflow checks.
Uh, so you want slow? If you want this you should also check the
overflow flag so that you can catch overflows and throw an
exception.
But then you have a high level language. All high level languages
should do this.
In D it is even worse since you are forced to use a fixed size
modulo even for int, so you cannot do 32 bit arithmetic in a
64 bit register without getting extra modulo operations.
why should i, as programmer, care? what i *really* care about is
portable code. having size of base types not strictly defined
is not
helping at all.
So you want to have lots of masking on your shiny new 64-bit
register only CPU, because D is stuck on promoting to 32-bits by
spec?
That's not portable, that is portable.
So, undefined behaviour is not so bad
yes, it's not bad, it's terrible. having undefined behavior in
language is like saying hey, we don't know what to do with
this, and
Nah, it is saying: if your code is wrong then you will get wrong
results unless you turn on runtime checks.
What D is saying is: nothing is wrong even if you get something
you never wanted to express, because we specify all operations to
be boundless (circular) so that nothing can be wrong by
definition (but your code will still crash and burn).
That also means that you cannot turn on runtime checks, since it
is by definition valid. No way for the compiler to figure out if
it is intentional or not.
D has locked itself to Pentium-style x86 behaviour.
oops. 2's complement integer arithmetic is pentium-style x86
now... i
bet x86_64 does everything in ternary, right? oh, and how about
pre-pentium era?
The overhead for doing 64bit calculations is marginal. Locking
yourself to 32bit is a bad idea.
it is very easy. take current hardware, evaluate it's
popularity, do
what most popular hardware does. that's it. i, for myself,
don't need
a language for future hardware, i need to work with what i
have now.
My first computer had no division or multiply and 8 bit registers
and was insanely popular. It was inconceivable that I would
afford anything more advanced in the next decade. In the next 5
years I had two 16 bit computers, one with 16x RAM and GPU… and
at a much lower price…
if we'll have some drastic changes in the future... well, we
always can
emulate old HW to work with old code, and rewrite that old code
for new
HW.
The most work on a codebase is done after it ships.
Interesting things may happen on the hardware side in the next
few years:
- You'll find info on the net where Intel has planned buffered
transactional memory for around 2017.
- AMD is interested in CPU/GPU intergration/convergence
- Intel has a many core co-processor
- SIMD registers are getting wider and wider… 512 bits is a lot!
etc...
Re: Postblit bug
On Friday, 17 October 2014 at 14:18:31 UTC, monarch_dodra wrote: On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via Digitalmars-d wrote: On Fri, 17 Oct 2014 00:42:24 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: Can someone comment this code? Should I think that it's a bug. it's just an anomaly. const postblit can do alot of things besides adjusting struct fields, and it's logical that compiler cannot call non-const methods for const objects. yet it's still on of those unforseen consequences that arises from conjunction of different features. i don't think that it's a bug, but i think that this must be discussed anyway, and then documented. AFAIK, Kenji has submitted a DIP, and has begun working on fixing the const/immutable/inout posblit issue. However, there are some very subtle corner cases, so (afaik) work is slow. To be honest, I think people use const way too much in D. It's *not* the C++ head const you can use anywhere. It's really just the base attribute between mutable and immutable data. In particular, due to the transitive nature of const, any time you use const it means you can't modify this, or anything produced or acquired from this, ever. It's usually not what people think they are signing for... When it makes little sense to have your type as immutable, then I don't think you should bother much What happends if we will ignore const/immutable modifier for postblits? Is it create any holes?
Re: template constraint diagnostics
On Friday, 17 October 2014 at 13:22:26 UTC, ketmar via Digitalmars-d wrote: On Fri, 17 Oct 2014 08:00:03 +0200 Marco Leise via Digitalmars-d digitalmars-d@puremagic.com wrote: ketmar gtfo ... oh wait, that's a great idea actually! ;-) it is! ketmar ctfb
Re: C++ Ranges proposal for the Standard Library
On 10/17/14, 2:17 AM, ZombineDev wrote: I saw [this][0] proposal for adding ranges to C++'s standard library. The [paper][1] looks at D style ranges, but concludes: Since iterators can implement D ranges, but D ranges cannot be used to implement iterators, we conclude that iterators form a more powerful and foundational basis. What do you guys think? [0]: https://isocpp.org/blog/2014/10/ranges [1]: https://ericniebler.github.io/std/wg21/D4128.html Yeah, it's true and somewhat self-evident in the sense that structure build upward (more structure from less). In the same vein pointers are more powerful than slices and untyped data more powerful than typed data. Andrei
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. Neither does failed transaction. I already approved that: When the part fails, you discard it and continue operation. In software it works by rolling back a failed transaction. Trying to bend the imprecise language I use into meaning the opposite doesn't change that. Do you think I question that? I don't. I agree discarding a failed part is ok, and this is what traditional multithreaded server software already do: rollback a failed transaction and continue operation, just like airplane: loosing a part doesn't lose the whole.
Re: GCC Undefined Behavior Sanitizer
On 10/17/14, 2:53 AM, Iain Buclaw via Digitalmars-d wrote: On 16 October 2014 22:00, bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ *cough* GDC *cough* :o) Do you mean ubsan will work with gdc? -- Andrei
Re: C++ Ranges proposal for the Standard Library
On 10/17/14 10:13 AM, monarch_dodra wrote: My personal feeling (IMO): - Consuming, adapting, producing data: Ranges win hands down. - Managing, shuffling or inserting elements in a container: To be honest, I prefer iterators. Dcollections solves this. -Steve
Re: GCC Undefined Behavior Sanitizer
On 10/17/14, 3:51 AM, eles wrote: On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ Bye, bearophile Not every software bug has as serious consequences as seen in the Ariane 5 rocket crash. if ubsan detects any problem, it outputs a “runtime error:” message, and in most cases continues executing the program. The latter won't really solve the former... Still a step forward. -- Andrei
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote: True. Iterators are more foundational, ranges are more neat-o. ;) Python is more accurate, succinct and generic :-) Fraction(Fraction(sum(a)),len(a)) or Fraction(sum([Fraction(n) for n in a]),len(a))
Re: GCC Undefined Behavior Sanitizer
On Fri, 17 Oct 2014 14:38:29 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour.
do you know any widespread hardware with doesn't work this way?
Yes, the carry flag is set if you add with carry. It means you
SHOULD add to another hi-word with carry. :P
i was writing about 'if_carry_set'. yes, i really-really-really want
either propagating carry if 'if_carry_flag_set', or a way to tell the
compiler do overflow check on this expression and throw exception on
overflow.
You can also add with clamp with SSE, so you clamp to max/min.
Too bad languages don't support it. I've always thought it be
nice to have clamp operators, so you can say x(+)y and have the
result clamped to the max/min values. Useful for stuff like DSP
on integers.
it's good. but this not justifies the decision to make 2's complement
overflow undefined.
if (x ((x+1)0x)){…}
perfect. nice and straightforward way to do overflow checks.
Uh, so you want slow? If you want this you should also check the
overflow flag so that you can catch overflows and throw an
exception.
i want a way to check integer overflows. i don't even want to think
about dirty C code to do that ('cause, eh, our compilers are very smart
and they, eh, know that there must be no overflows on ints, and they,
eh, just removing some checks 'cause that checks is no-ops when there
are no overflows, and now we, eh, have to cheat the compiler to...
screw it, i'm going home!)
So you want to have lots of masking on your shiny new 64-bit
register only CPU, because D is stuck on promoting to 32-bits by
spec?
yes. what's wrong with using long/ulong when you need 64 bits? i don't
care about work CPU must perform to execute my code, CPU was created to
help me, not vice versa. yet i really care about 'int' being the same
size on different architectures (size_t, you sux! i want you to go
away!).
That's not portable, that is portable.
it's portable. and portable is when i should making life of some
silicon crap easier instead of silicon crap making my life easier.
Nah, it is saying: if your code is wrong then you will get wrong
results unless you turn on runtime checks.
...and have a nice day, sucker!
What D is saying is: nothing is wrong even if you get something
you never wanted to express, because we specify all operations to
be boundless (circular) so that nothing can be wrong by
definition (but your code will still crash and burn).
perfect!
That also means that you cannot turn on runtime checks, since it
is by definition valid. No way for the compiler to figure out if
it is intentional or not.
if you want such checks, you have a choice. you either can do such
checks manually or use something like CheckedInt. this way when i see
CheckedInt variable i know programmer's intentions from the start. and
if programmer using simple 'int' i know that compiler will not
optimize away some checking code.
The overhead for doing 64bit calculations is marginal. Locking
yourself to 32bit is a bad idea.
did you noticed long/ulong types in D specs? and reserved 'cent' type
for that matter?
My first computer had no division or multiply and 8 bit registers
and was insanely popular. It was inconceivable that I would
afford anything more advanced in the next decade. In the next 5
years I had two 16 bit computers, one with 16x RAM and GPU… and
at a much lower price…
that's why you don't use assembler to write your code now, aren't you?
i was trying to use C for Z80, and that wasn't a huge success that
days. why do you want to make my life harder by targeting D2 to some
imaginary future hardware instead of targetting to current one? by
the days when future hardware will become current hardware we will
have D5 or so. nobody using KR C now, right?
The most work on a codebase is done after it ships.
porting to another arch, for example. where... ah, FSCK, int is 29 bits
there! shit! or 16 bits... portable by rewriting, yeah.
Interesting things may happen on the hardware side in the next
few years:
- You'll find info on the net where Intel has planned buffered
transactional memory for around 2017.
(looking at 'date' output) ok, it's 2014 now. and i see no such HW
around. let's talk about this when we'll have widespreaded HW with this
feature.
- AMD is interested in CPU/GPU intergration/convergence
and me not. but i'm glad for AMD.
- Intel has a many core co-processor
and?..
- SIMD registers are getting wider and wider… 512 bits is a lot!
and i must spend time to make some silicon crap happy, again? teach
compilers to transparently rewrite my code, i don't want to be a slave
to CPUs.
signature.asc
Description: PGP signature
Re: GCC Undefined Behavior Sanitizer
On Fri, 17 Oct 2014 08:08:34 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: Do you mean ubsan will work with gdc? -- Andrei as far as i can understand, ubsan is GCC feature. not GCC C compiler, but GNU Compiler Collection. it works on IR representations, so GDC should be able to use ubsan almost automatically, without significant efforts from Iain. at least it looks like this. signature.asc Description: PGP signature
Re: Postblit bug
On Fri, 17 Oct 2014 14:41:36 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: What happends if we will ignore const/immutable modifier for postblits? Is it create any holes? it will break const promise. i.e. const/immutable data is not really immutable now, it can be modified. signature.asc Description: PGP signature
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 15:10:33 UTC, Andrei Alexandrescu wrote: On 10/17/14, 3:51 AM, eles wrote: On Thursday, 16 October 2014 at 21:00:18 UTC, bearophile wrote: Just found with Reddit. C seems one step ahead of D with this: Still a step forward. -- Andrei While I agree, IIRC, Ariane was never tested in that particular flight configuration that caused the bug (which was not a Heisenbug, as it was easy to reproduce but, you know, *afterwards*). Now, imagine that Ariane in space encountering a runtime error. Go back to Earth, anyone?... I specifically referred to the crash itself.
Re: core.thread.memcpy conflicts with core.stdc.string.memcpy
Its a holdover from when we were trying to eliminate imports in druntime because of the associated overhead. I'd submit a bugzilla about it.
Re: D2 (Debian) + MSSQL
On 2014-10-17 07:24, Sergey wrote: Or if I already have a byte string in cp1251 how to translate it into a normal string? Doesn't Sql Server uses UC2? -- /Jacob Carlborg
Re: So what exactly is coming with extended C++ support?
On 2014-10-16 17:21, Dan Olson wrote: Specifically here I mean LDC targeted to arm-ios. The linker complains about the generated debug info and I end up stepping through D in arm assembly. Oh, right. I was mostly thinking about OS X applications. -- /Jacob Carlborg
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 15:17:12 UTC, ketmar via Digitalmars-d wrote: it's good. but this not justifies the decision to make 2's complement overflow undefined. If you want a circular type, then call it something to that effect. Not uint or int. Call it bits or wrapint. yes. what's wrong with using long/ulong when you need 64 bits? What is wrong and arbitrary is promoting to 32-bits by default. did you noticed long/ulong types in D specs? and reserved 'cent' type for that matter? If you want fixed width, make it part of the name: i8, i16, i24, i32, i64… Seriously, if you are going to stick to fixed register sizes you have to support 24 bit and other common register sizes too. Otherwise you'll get 24bit wrapping 32bit ints. i was trying to use C for Z80, and that wasn't a huge success that days. How did you manage to compile with it? ;-) The first good programming tool I had was an assembler written in Basic… I had to load the assembler from tape… slooow. And if my program hung I had to reset and reload it. Patience… Then again, that makes you a very careful programmer ;) have D5 or so. nobody using KR C now, right? ANSI-C is pretty much the same, plenty of codebases are converted over from KR. With roots in the 70s… :-P around. let's talk about this when we'll have widespreaded HW with this feature. That goes real fast, because is probably cheaper to have it built into all CPUs of the same generation and just disable it on the ones that have to be sold cheap because they are slow/market demand. and i must spend time to make some silicon crap happy, again? If you want a high level language, no. If you want a system level language, yes!!
Re: GCC Undefined Behavior Sanitizer
On 17 October 2014 16:08, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 10/17/14, 2:53 AM, Iain Buclaw via Digitalmars-d wrote: On 16 October 2014 22:00, bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: Just found with Reddit. C seems one step ahead of D with this: http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ *cough* GDC *cough* :o) Do you mean ubsan will work with gdc? -- Andrei It doesn't out of the box, but adding in front-end support is a small codegen addition for each plugin you wish to support. The rest is taken care of by GCC. Iain.
Re: Program logic bugs vs input/environmental errors
On 2014-10-16 21:35, Walter Bright wrote: Ok, but why would 3rd party library unittests be a concern? They shouldn't have shipped it if their own unittests fail - that's the whole point of having unittests. They will have asserts in contracts and other parts of that code that is not unit tests. -- /Jacob Carlborg
Re: Program logic bugs vs input/environmental errors
On 2014-10-17 10:26, Atila Neves wrote: Is cleaning up in a unittest build a problem? I'd say no, if it the tests fail it doesn't make much sense to clean up unless it affects the reporting of tests failing. I have used files in some of my unit tests. I would certainly like those to be properly closed if a tests failed (for whatever reason). Now, some of you will argue that one shouldn't use files in unit tests. But that would only work in a ideal and perfect world, which we don't live in. -- /Jacob Carlborg
Re: Program logic bugs vs input/environmental errors
On 2014-10-16 20:50, Walter Bright wrote: I don't understand why unittests in druntime/phobos are an issue for users. We don't release a DMD unless they all pass - it should be moot for users. There are asserts elsewhere in the code. -- /Jacob Carlborg
Re: Program logic bugs vs input/environmental errors
On 2014-10-16 21:31, Walter Bright wrote: Contract errors in Phobos/Druntime should be limited to having passed it invalid arguments, which should be documented That doesn't mean it won't happen. -- /Jacob Carlborg
Re: Postblit bug
On Friday, 17 October 2014 at 15:20:50 UTC, ketmar via Digitalmars-d wrote: On Fri, 17 Oct 2014 14:41:36 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: What happends if we will ignore const/immutable modifier for postblits? Is it create any holes? it will break const promise. i.e. const/immutable data is not really immutable now, it can be modified. It's just common words=) I meant that when postblit is called when new object is being creating and doesn't exists for user code. E.g. const S v1 = v2; Ok, v1 _will_ be const when it will be _created_. However postblit can think that object is mutable, because it called before the first accessing to the object from user code. Thus I ask about case when postblit may mutate a const object, which created before postblitted object and may been accessed from user code before this postblitting.
Re: GCC Undefined Behavior Sanitizer
On Fri, 17 Oct 2014 15:58:02 + via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 17 October 2014 at 15:17:12 UTC, ketmar via Digitalmars-d wrote: it's good. but this not justifies the decision to make 2's complement overflow undefined. If you want a circular type, then call it something to that effect. Not uint or int. Call it bits or wrapint. it would be nice. but i'm still against integral wrapping is undefined. define it! either specify the result, or force program to crash. yes. what's wrong with using long/ulong when you need 64 bits? What is wrong and arbitrary is promoting to 32-bits by default. 64-bit ARMs aren't so widespread yet. oh, wait, are we talking about x86-compatible CPUs only? but why? did you noticed long/ulong types in D specs? and reserved 'cent' type for that matter? If you want fixed width, make it part of the name: i8, i16, i24, i32, i64… i have nothing against this either. but i have alot against integral with arbitrary size type. Seriously, if you are going to stick to fixed register sizes you have to support 24 bit and other common register sizes too. Otherwise you'll get 24bit wrapping 32bit ints. nope. if int is 32 but, and it's behavior is defined as 2's complement 32-bit value, it doesn't matter what register size HW has. it's compiler task to make this int behave right. i was trying to use C for Z80, and that wasn't a huge success that days. How did you manage to compile with it? ;-) it was... painful. even with disk drive. having only 64KB of memory (actually, only 48K free for use) doesn't help much too. Then again, that makes you a very careful programmer ;) that almost turned me to serial killer. around. let's talk about this when we'll have widespreaded HW with this feature. That goes real fast, because is probably cheaper to have it built into all CPUs of the same generation and just disable it on the ones that have to be sold cheap because they are slow/market demand. i don't buying that we'll made that pretty soon PR. first they making it widespreaded, then i'll start caring, not vice versa. and i must spend time to make some silicon crap happy, again? If you want a high level language, no. If you want a system level language, yes!! this is a misconception. low level language is not one that pleases CPU down to bits and registers, it's about *conceptions*. for example, good high-level language doesn't need pointers, yet low-level one needs 'em. good high-level language makes alot of checks automatically (range checking, overflow checking and so on), goot low-level language allows programmer to control what will be checked and how. good high-level language can transparently use bigints on overflow, good low-level language has clearly defined semantic of integer overflow and defined sizes for integral types. and so on. going low-level is not about pleasing CPU (it's not assembler), it's about writing low-level code -- one with pointers, manual checks and such. signature.asc Description: PGP signature
Re: GCC Undefined Behavior Sanitizer
On Friday, 17 October 2014 at 16:26:08 UTC, ketmar via Digitalmars-d wrote: i have nothing against this either. but i have alot against integral with arbitrary size type. Actually it makes a lot of sense to be able to reuse 16-bit library code on a 24-bit ALU. Like for loading a sound at 16-bit then process it at 24-bit. nope. if int is 32 but, and it's behavior is defined as 2's complement 32-bit value, it doesn't matter what register size HW has. it's compiler task to make this int behave right. And that will result in slow code. Then again, that makes you a very careful programmer ;) that almost turned me to serial killer. Yeah, IIRC I cracked it and put it on a diskette after a while… i don't buying that we'll made that pretty soon PR. first they making it widespreaded, then i'll start caring, not vice versa. C++ has a workgroup on transactional memory with expertise… So, how long can you wait with planning for the future before being hit by the train? You need to be ahead of the big mover if you want to gain positions in multi-threading (which is the most important area that is up for grabs in system level programming these days). this is a misconception. low level language is not one that pleases CPU down to bits and registers, it's about *conceptions*. for example, good high-level language doesn't need pointers, yet low-level one needs 'em. Bad example. Low level languages need pointers because the hardware use 'em. If you have a non-standard memory model you need deal with different aspects of pointers too (like segments or bank switching). If you cannot efficiently compute existing libraries on 24-bit, 48-bit or 64-bit ALUs then the programming language is tied to a specific CPU. That is not good and it will have problems being viewed as a general system level programming language. A system level language should not force you to be overly abstract in a manner that affects performance or restricts flexibility.
Re: C++ Ranges proposal for the Standard Library
Am 17.10.2014 um 17:14 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote: True. Iterators are more foundational, ranges are more neat-o. ;) Python is more accurate, succinct and generic :-) Fraction(Fraction(sum(a)),len(a)) or Fraction(sum([Fraction(n) for n in a]),len(a)) And slrrr
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 17:14:24 UTC, Paulo Pinto wrote: And slrrr Accurate is slower, but not this: sum(a)/len(a)
Re: GCC Undefined Behavior Sanitizer
On Fri, 17 Oct 2014 16:49:10 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
i have nothing against this either. but i have alot against
integral with arbitrary size type.
Actually it makes a lot of sense to be able to reuse 16-bit
library code on a 24-bit ALU. Like for loading a sound at 16-bit
then process it at 24-bit.
and this is perfectly doable with fixed-size ints. just use 16-bit
library when you can and write new code when you can't.
nope. if int is 32 but, and it's behavior is defined as 2's
complement
32-bit value, it doesn't matter what register size HW has. it's
compiler task to make this int behave right.
And that will result in slow code.
i prefer slow code over incorrect code. if i'll find that some code is
a real bottleneck (using profiler, of course, almost noone can make a
right guess here ;-), i'll write arch-dependant assembler part to
replace slow code. but i prefer first to get it working after
recompiling, and then starting to optimize. what i don't want is to
think each time what if int will have different size here? that's why
i'm using types from stdint.h in my C code instead of just int,
long and so on.
i don't buying that we'll made that pretty soon PR. first
they making
it widespreaded, then i'll start caring, not vice versa.
C++ has a workgroup on transactional memory with expertise… So,
how long can you wait with planning for the future before being
hit by the train?
indefinitely long if language guarantees that my existing code will
continue to work as expected.
You need to be ahead of the big mover if you want to gain
positions in multi-threading (which is the most important area
that is up for grabs in system level programming these days).
i don't care about positions. what i care about is language with
defined behavior. besides, threads sux. ;-)
anyway, it's not hard to add transaction {} block (from the language
design POV, not from the implementor's POV). ;-)
for example, good high-level language doesn't need pointers, yet
low-level one needs 'em.
Bad example. Low level languages need pointers because the
hardware use 'em.
i really can't imagine hardware without pointers.
If you have a non-standard memory model you
need deal with different aspects of pointers too (like segments
or bank switching).
this must be accessible, but hidden from me unless i explicitly ask
about gory details.
If you cannot efficiently compute existing libraries on 24-bit,
48-bit or 64-bit ALUs then the programming language is tied to a
specific CPU.
are you saying that 32-bit operations on 64-bit CPUs sux? than those
CPUs sux. throw 'em away. besides, having guaranteed and well-defined
integer sizes and overflow values is what making using such libs on
different architectures possible. what *really* ties code to CPU is
int size depends of host CPU, overflow result depends of host CPU
and other such things.
That is not good and it will have problems being
viewed as a general system level programming language.
nope. this is the problem of HW designers and compiler writers, not
language problem. i still can't understand why i must write my code to
please C compiler. weren't compilers invented to please *me*? i'm not
going to serve the servants.
A system level language should not force you to be overly
abstract in a manner that affects performance or restricts
flexibility.
system level language must provide ability to go to CPU level if
programmer want that, but it *must* abstract away unnecessary details
by default. it's way easier to have not superefficient, but working
code first and continually refine it than trying to write it the hard
way from the start.
signature.asc
Description: PGP signature
Re: Postblit bug
On Friday, 17 October 2014 at 16:19:47 UTC, IgorStepanov wrote:
It's just common words=)
I meant that when postblit is called when new object is being
creating and doesn't exists for user code.
E.g.
const S v1 = v2;
Ok, v1 _will_ be const when it will be _created_.
However postblit can think that object is mutable, because it
called before the first accessing to the object from user code.
Thus I ask about case when postblit may mutate a const object,
which created before postblitted object and may been accessed
from user code before this postblitting.
That's way too many words for a single sentence for me to
understand ;)
But maybe this answers your question?
import std.stdio;
struct S
{
int* p;
this(this)
{
++*p;
}
}
void main()
{
immutable i = 0;
auto s1 = immutable(S)(i);
auto s2 = s1;
assert(*i == 0);
}
Re: Postblit bug
On Fri, 17 Oct 2014 16:19:46 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 17 October 2014 at 15:20:50 UTC, ketmar via Digitalmars-d wrote: On Fri, 17 Oct 2014 14:41:36 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: What happends if we will ignore const/immutable modifier for postblits? Is it create any holes? it will break const promise. i.e. const/immutable data is not really immutable now, it can be modified. It's just common words=) I meant that when postblit is called when new object is being creating and doesn't exists for user code. E.g. const S v1 = v2; Ok, v1 _will_ be const when it will be _created_. However postblit can think that object is mutable, because it called before the first accessing to the object from user code. Thus I ask about case when postblit may mutate a const object, which created before postblitted object and may been accessed from user code before this postblitting. what if compiler knows 'v2' value at compile time? compiler can put 'v1' in read-only section, and then postblitter will try to mutate 'v1'... ah, segfault. yet postblitter can do some other things, like, for example, registering 'v1' in some king of runtime storage, so it can't be optimized away. and then the programmer changes postblitter to mutate some fields. it all compiles fine and segfaults. const promises can't be dropped that easy. yes, the compiler doesn't do such things *now*, but it's ok for it to do it later and... kaboom! previously working code is not working anymore. signature.asc Description: PGP signature
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 17:16:29 UTC, Ola Fosheim Grøstad wrote: Accurate is slower, but not this: sum(a)/len(a) Forgot to point out that the original point with mentioning Python in the thread is: 1. Compiled static languages still have a long way to go with expressiveness. 2. Generic operations on double will lead to wrong results. What happens if your first value is very large? You loose the accumulation of the smaller values, in the worst case you only get the first value. Thus you will have to sort the values by exponent before accumulating or convert it into a different format. So yes, C++ iterators and D ranges are kind of cool, but cannot beat a well engineered library and a good mapping to it on the language side. (Python is of course not optimal in any way.)
Parallax Propeller Microcontroller
I made some research, though couldn't have found any article about it. Is there any work that has been/is being done for Parallax Propeller Microcontroller with D Language? Any library, linker etc. As far as I see on wikipedia (http://en.wikipedia.org/wiki/Parallax_Propeller), there are ports to microcontroller's assembler for C, Java, Pascal, Fortran. Note: For those who don't have knowledge about it, this microcontroller is 32 bit, and has 8 cores on it.
Re: RFC: std.json sucessor
On 8/21/14, 7:35 PM, Sönke Ludwig wrote: Following up on the recent std.jgrandson thread [1], I've picked up the work (a lot earlier than anticipated) and finished a first version of a loose blend of said std.jgrandson, vibe.data.json and some changes that I had planned for vibe.data.json for a while. I'm quite pleased by the results so far, although without a serialization framework it still misses a very important building block. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ DUB: http://code.dlang.org/packages/std_data_json Destroy away! ;) [1]: http://forum.dlang.org/thread/lrknjl$co7$1...@digitalmars.com Once its done you can compare its performance against other languages with this benchmark: https://github.com/kostya/benchmarks/tree/master/json
BareBones VersionCondition identifier for druntime
Hi all, Following up on the very fun work of Adam Ruppe, Mike (JinShil)'s Cortex M howto, XomB, and of course the D Bare Bones tutorial on wiki.osdev.org, I have started a brand-new kernel in D over at: https://github.com/klamonte/cycle At the moment I am running on i386 (qemu), but aiming for arch independence. I started on GDC but am using DMD now. The current kernel image does little more than allocate/free memory and emit strings to VGA memory, BUT it can use D-language templates, structs, enums, and (some) classes, all in less than 50k overhead. For the runtime, I am using a very minimal 2.065 druntime in the kdruntime directory (k is for kernel, not my name :) ). I think that kdruntime is (seriously) less than 100 functions away from being capable of supporting almost all of the functionality described in the D Language Reference, except for: Garbage Collection, Vector Extensions, and Interfacing to C++. I further think that the deviations from druntime are in total not that large, and that at some future date druntime could be de-coupled from libc/posix/windows (if one is willing to re-implement threads/synchronized). *** I am not asking anyone else to do any new work or change course on anything right now. Rather, I would like to ask the druntime devs if there is interest in defining a VersionCondition identifier, what I am currently calling BareBones. *** BareBones loosely means druntime without posix or windows. Other words that could be used to capture similar ideas: * Affirmative definitions: BareMetal, Baseline -- a short list of these features/functions are the absolute minimum required to support D2 syntax, after which one could build the rest. * Negative definitions: NoLibC, NoThreads, NoGC -- everything currently in druntime minus these things. If we had a word like BareBones now, then later on people working on kernels (or embedded, or games, or ...) could start offering pull requests to druntime to make the job of new mini-runtimes much easier. druntime itself would NOT be expected to compile or link with BareBones set. Most of druntime could be protected from invasive changes with just static asserts in modules like core.stdc.*, to prevent accidental inclusion in BareBones systems. Other spots that handle platform-specific stuff (like sections.d importing sections_linux.d) could import the non-existent sections_barebones.d. New runtimes could be born simply by cloning druntime, setting BareBones, removing all the files that static assert fail, and then implementing all the functions that aren't found during link. In the near-to-mid term, very little would change for druntime. In the longer term, one or more BareBones-version runtimes could emerge to put D in new places. What do y'all think? Would you be comfortable with saying to people implementing new runtimes, please version your differences from druntime in this particular way ?
Re: C++ Ranges proposal for the Standard Library
Am 17.10.2014 um 19:46 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Friday, 17 October 2014 at 17:16:29 UTC, Ola Fosheim Grøstad wrote: Accurate is slower, but not this: sum(a)/len(a) Forgot to point out that the original point with mentioning Python in the thread is: 1. Compiled static languages still have a long way to go with expressiveness. 2. Generic operations on double will lead to wrong results. What happens if your first value is very large? You loose the accumulation of the smaller values, in the worst case you only get the first value. Thus you will have to sort the values by exponent before accumulating or convert it into a different format. So yes, C++ iterators and D ranges are kind of cool, but cannot beat a well engineered library and a good mapping to it on the language side. (Python is of course not optimal in any way.) I don't think I would have those issues with ML languages. -- Paulo
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 14:01:46 UTC, Ola Fosheim Grøstad wrote: On Friday, 17 October 2014 at 13:27:37 UTC, eles wrote: (gcc does not yet support std::cbegin() and std::cend()). (tested :^) Thanks ;) Like your new version, but I don't think it will work with regular arrays and maybe the accumulator will overflow Just replace static_casttypename T::value_type with static_castU, U being a second template argument that defaults to T::value_type. Then, you can control the size of the result, but you need to explicitely instantiate the templae with types. A more general and pleasant solution would be to use D ;)
Re: Parallax Propeller Microcontroller
Am 17.10.2014 um 20:06 schrieb tcak: I made some research, though couldn't have found any article about it. Is there any work that has been/is being done for Parallax Propeller Microcontroller with D Language? Any library, linker etc. As far as I see on wikipedia (http://en.wikipedia.org/wiki/Parallax_Propeller), there are ports to microcontroller's assembler for C, Java, Pascal, Fortran. Note: For those who don't have knowledge about it, this microcontroller is 32 bit, and has 8 cores on it. You forgot to provide the link for the best use case that Parallax Propeller is being used for. :) http://www.xgamestation.com/view_product.php?id=33 -- Paulo
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 17:14:24 UTC, Paulo Pinto wrote: Am 17.10.2014 um 17:14 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote: And slrrr And it has tbs! :((
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 19:07:26 UTC, Paulo Pinto wrote: I don't think I would have those issues with ML languages. That's probably true, ML has had some generic support for 40+ years?
Re: Postblit bug
On Friday, 17 October 2014 at 17:25:47 UTC, monarch_dodra wrote:
On Friday, 17 October 2014 at 16:19:47 UTC, IgorStepanov wrote:
It's just common words=)
I meant that when postblit is called when new object is being
creating and doesn't exists for user code.
E.g.
const S v1 = v2;
Ok, v1 _will_ be const when it will be _created_.
However postblit can think that object is mutable, because it
called before the first accessing to the object from user code.
Thus I ask about case when postblit may mutate a const object,
which created before postblitted object and may been accessed
from user code before this postblitting.
That's way too many words for a single sentence for me to
understand ;)
Yes, my english is so bad:)
But maybe this answers your question?
Yes, I've understood.
TBH, I have got this error while I am working on new AA, and I
want to fix it as posdible faster (one way or another).
I have the next code:
struct AssociativeArray(Key, Value)
{
...
struct Entry
{
Key key;
Value value;
...
}
}
If key or value is a const struct with postblit I have got a
error.
I don't need an any postblit in Entry.
Thus I suggest another solution:
Do not generate helper functions like __fieldPostBlit, if struct
has a @disabled this(this);
Destroy it.
Re: Postblit bug
On Fri, 17 Oct 2014 19:39:39 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: Thus I suggest another solution: Do not generate helper functions like __fieldPostBlit, if struct has a @disabled this(this); Destroy it. `@disable this (this);` means that struct can't be copied. it's irrelevant what code compiler generates behind our backs, it will not be executed anyway, 'cause compiler will complain: Error: struct XXX is not copyable because it is annotated with @disable. signature.asc Description: PGP signature
Re: C++ Ranges proposal for the Standard Library
On Friday, 17 October 2014 at 19:11:48 UTC, eles wrote: On Friday, 17 October 2014 at 17:14:24 UTC, Paulo Pinto wrote: Am 17.10.2014 um 17:14 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote: And slrrr And it has tbs! :(( Tabs, in and out of themselves, aren't bad. Arguably, they are better than spaces. In a perfect world, everyone would use tabs everywhere, and each individual would set their editor to their prefered indent size (personally, I like too. It's concise) However, once you start working with people who can't be arsed to keep a consistent style, then you have to lower your standard to the lowest common denominator. That's mostly the reason people tend to opt for spaces everywhere. I just read this though: Python 3 disallows mixing the use of tabs and spaces for indentation. Fucking WIN. A compiler that will *refuse* to compile your code because it is too ugly? Mind BLOWN.
Re: C++ Ranges proposal for the Standard Library
On Fri, 17 Oct 2014 19:49:06 + monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote: I just read this though: Python 3 disallows mixing the use of tabs and spaces for indentation. Fucking WIN. A compiler that will *refuse* to compile your code because it is too ugly? Mind BLOWN. they're still reinventing whitespace language. signature.asc Description: PGP signature
Re: Postblit bug
On Friday, 17 October 2014 at 19:45:43 UTC, ketmar via Digitalmars-d wrote: On Fri, 17 Oct 2014 19:39:39 + IgorStepanov via Digitalmars-d digitalmars-d@puremagic.com wrote: Thus I suggest another solution: Do not generate helper functions like __fieldPostBlit, if struct has a @disabled this(this); Destroy it. `@disable this (this);` means that struct can't be copied. it's irrelevant what code compiler generates behind our backs, it will not be executed anyway, 'cause compiler will complain: Error: struct XXX is not copyable because it is annotated with @disable. This error will be raised if I try to copy the my struct. But I don't want to do it. Now the error raised when I define the struct.
Re: Segmented stack
On Friday, 17 October 2014 at 04:23:40 UTC, Ola Fosheim Grøstad wrote: They don't have much of a choice since AMD64 does not provide a segmented memory model. Ack, I misinterpreted. The OP probably talks about split-stacks, stacks a linked list of memory segments. I thought it was about trapping out-of-stack situations. A historical note: I think Simula, Beta, Self and maybe early versions of Java allocated activation records on the gc-heap rather than using a stack. Allowing for high levels of concurrency with little wasted memory, but I have no references at hand…
code.dlang.org down
and vibed.org and forum.rejectedsoftware.com what up with your servers Sönke?
Re: code.dlang.org down
On Friday, 17 October 2014 at 21:15:47 UTC, John Colvin wrote: and vibed.org and forum.rejectedsoftware.com what up with your servers Sönke? and the dub repository itself...
Re: Parallax Propeller Microcontroller
On Friday, 17 October 2014 at 19:12:52 UTC, Paulo Pinto wrote: You forgot to provide the link for the best use case that Parallax Propeller is being used for. :) http://www.xgamestation.com/view_product.php?id=33 -- Paulo Wow! I didn't know that really. Checking the games now.
Re: Segmented stack
On Thursday, 16 October 2014 at 19:46:42 UTC, Shucai wrote: I am doing research on segmented stack mechanisms, and in addition to academic papers, I am surveying whether segmented stack mechanism is still useful on 64-bit machines. On 64 bit machines, why they don’t just use a big enough stack, for example, 1GB or even larger? Are segmented stacks only useful for 32 bit machines? Are there other reasons for segmented stacks on 64 bit machines? Any response is appreciated, thanks, Shucai While the implementation isn't guaranteed, I think that Java mandates that the VM behave like every function receives a fresh stack. I imagine that the advantage of this was that it allows the VM to supply only the minimal necessary memory for a function to operate, at any given time. On small devices, it can swap the stack out to disk. On large devices, it can just keep everything in memory. Optimization for size/speed is handled for you, making your code more portable. (Theoretically.) Another possibility is that, while I can't think of the application, being able to preserve discarded chunks of the stack might be useful in some way. In a traditional stack arrangement, a new function entry will generally cause the data from the previous function entry to be overwritten. If you're allocating each new entry as its own thing, then all of the old functions continue to sit around to be processed by another thread, until you're ready to completely get rid of them.
Re: Parallax Propeller Microcontroller
On Friday, 17 October 2014 at 18:06:26 UTC, tcak wrote: I made some research, though couldn't have found any article about it. Is there any work that has been/is being done for Parallax Propeller Microcontroller with D Language? Any library, linker etc. As far as I see on wikipedia (http://en.wikipedia.org/wiki/Parallax_Propeller), there are ports to microcontroller's assembler for C, Java, Pascal, Fortran. Note: For those who don't have knowledge about it, this microcontroller is 32 bit, and has 8 cores on it. I haven't seen any work in this community specifically for this platform, however, thanks to GCC, I don't think it would be too far out of reach. If you have the hardware, I recommend you give it try and write a wiki about it. Here's how I would a approach it. 1. Download the Propeller GCC source code [1]. 2. Clone the GDC repository for the specific GCC version that best matches the GCC version of the PropellerGCC 3 Read and try to understand the instructions for building a GDC cross-compiler [2]. Ask questions on the D.GNU forum [3] if you run into trouble. 4. Adapt the instructions for the Parallax Propeller 5. If you're successful, post your instructions as a subpage if the GDC cross-compiler wiki 6. Make a minimal D runtime as described in the Adam Ruppe's D for Kernel Coding chapter in the D Cookbook or similar to the ARM Cortex-M Hello World on the D wiki 7. Make a hello world program and post your instructions on the D wiki 8. Bask in the pride and admiration of a job well done. Mike [1] PropellerGCC: https://sites.google.com/site/propellergcc/ [2] GDC Cross-compiler instructions: http://wiki.dlang.org/GDC/Cross_Compiler [3] D.GNU forum: http://forum.dlang.org/group/D.gnu [4] D Cookbook: http://wiki.dlang.org/Books [5] ARM Cortex-M Hello World: http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22
Re: Parallax Propeller Microcontroller
On Saturday, 18 October 2014 at 01:42:38 UTC, Mike wrote: 2. Clone the GDC repository for the specific GCC version that best matches the GCC version of the PropellerGCC Forgot the most important link, the GDC source code: https://github.com/D-Programming-GDC/GDC Mike
