std.range this._input.opIndex(index) error
Attempting to compile the following from snippet auto r = iota(0, 10, 1); assert(equal(r, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9][])); from the documentation, I encountered following error range.d(1184): Error: this._input.opIndex(index) is not an lvalue Looking at the code I find return _input[index]; on line 1184. The variable _input is defined as R _input in the template Take(R) which is the template instantiated to create iota. Problem is, it is obvious why this doesn't work since the Range data variable _input is accessed the same way on multiple occasions throughout the file, a Range variable can obviously supports random access, and no attempt is being made to modify the range at this point in the code. Any information would be greatly appreciated? Thanks in advance, Andrew
std.range this._input.opIndex(index) error
Attempting to compile the following from snippet auto r = iota(0, 10, 1); assert(equal(r, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9][])); from the documentation, I encountered following error range.d(1184): Error: this._input.opIndex(index) is not an lvalue Looking at the code I find return _input[index]; on line 1184. The variable _input is defined as R _input in the template Take(R) which is the template instantiated to create iota. Problem is, it is not obvious why this doesn't work since the Range data variable _input is accessed the same way on multiple occasions throughout the file, a Range variable can obviously supports random access, and no attempt is being made to modify the range at this point in the code. Any information would be greatly appreciated? Thanks in advance, Andrew
Attribute introspection
Are there ways in D2 to tell if a function has the 'pure' attribute? (To create a parallel_map() function we will want to be sure it takes a pure mapping function as argument). Bye, bearophile
Valgrind D
Hi, has anybody experience with the usage of valgrind and D? We are here using DMD (dmd 1.033/tango 0.997 but also some older versions) and got problems using valgrind on this. It seems that the _d_newarrayT routine or something under it jumps or moves on unitialized value(s). Same with the _adDupT and _d_arrayappendT-method, which all call the _D3gcx3Gcx11fullcollectMFPvZk method. Has anybody the same experiences? Is it a bug within the Compiler or should be something avoided? Stefan [1] attached resource: valgrind-output ==19023== Conditional jump or move depends on uninitialised value(s) ==19023==at 0x85273FF: _D3gcx3Gcx11fullcollectMFPvZk (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x85270F9: _D3gcx3Gcx16fullcollectshellMFZk (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x8525729: _D3gcx2GC12mallocNoSyncMFkkZPv (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x8525646: _D3gcx2GC6mallocMFkkZPv (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x85250B6: gc_malloc (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x8523893: _d_newarrayT (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x85201C1: _aaGet (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x8546035: _D5tango4text5Regex11__T4TDFATwZ4TDFA14epsilonClosureMFC5tango4text5Regex11_ _T4TDFATwZ4TDFA11SubsetStateC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetStat eZC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetState15__foreachbody57MFKC5tan go4text5Regex22__T14TNFATransitionTwZ14TNFATransitionZi (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x8059513: _D5tango4text5Regex68__T4ListTC5tango4text5Regex22__T14TNFATransitionTwZ14TN FATransitionZ4List7opApplyMFDFKC5tango4text5Regex22__T14TNFATransitionTwZ14T NFATransitionZiZi (/home/stefan/workspace/DDev/dev_env/tango/dmd/include/tango/text/Regex.d:28 8) ==19023==by 0x8545E52: _D5tango4text5Regex11__T4TDFATwZ4TDFA14epsilonClosureMFC5tango4text5Regex11_ _T4TDFATwZ4TDFA11SubsetStateC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetStat eZC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetState (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x8544AC7: _D5tango4text5Regex11__T4TDFATwZ4TDFA5_ctorMFC5tango4text5Regex11__T4TNFATwZ 4TNFAZC5tango4text5Regex11__T4TDFATwZ4TDFA (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable) ==19023==by 0x854294B: _D5tango4text5Regex14__T7RegExpTTaZ7RegExpT5_ctorMFAabbbZC5tango4text5Regex1 4__T7RegExpTTaZ7RegExpT (in /home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
Re: Attribute introspection
bearophile wrote:
Are there ways in D2 to tell if a function has the 'pure' attribute?
(To create a parallel_map() function we will want to be sure it takes a pure
mapping function as argument).
Bye,
bearophile
It's easy enough if it's a function pointer or delegate:
int foo(T, U...)(T function(U) pure x) {
return 7;
}
void main()
{
int function(int) pure p=null;
int function(int) q = null;
foo(p); // OK
// foo(q); // won't compile.
}
Re: Valgrind D
Stefan Rohe wrote: Hi, has anybody experience with the usage of valgrind and D? We are here using DMD (dmd 1.033/tango 0.997 but also some older versions) and got problems using valgrind on this. It seems that the _d_newarrayT routine or something under it jumps or moves on unitialized value(s). The last time I looked into this, Valgrind was wrong about these cases--initialization is actually logically guaranteed. You can check for yourself though. See lib/compiler/dmd/lifetime.d.
Re: Valgrind D
Sean Kelly wrote: Stefan Rohe wrote: Hi, has anybody experience with the usage of valgrind and D? We are here using DMD (dmd 1.033/tango 0.997 but also some older versions) and got problems using valgrind on this. It seems that the _d_newarrayT routine or something under it jumps or moves on unitialized value(s). The last time I looked into this, Valgrind was wrong about these cases--initialization is actually logically guaranteed. You can check for yourself though. See lib/compiler/dmd/lifetime.d. I spent a good looking at similar reports a few years ago. The cause, at the time, was that the gc code walks the stack(s) during collections and has to examine every stack slot since it has no way of knowing anything about which slots are valid and which aren't. Valgrind, on the other hand, does know what stack slots have been assigned values and which haven't so can accurately report that the program has looked at memory that hasn't been initialized yet. One 'fix' might be to pre-initialize the stack with 0's upon function entry. I'm not even terribly convinced that'd work. Later, Brad
Re: D1 compile-time check for symbol/function?
On Wed, Apr 22, 2009 at 11:38 PM, Nick Sabalausky a...@a.a wrote: Does D1 have a way to check at compile-time if a particular symbol (specifically a function) is defined? You can use is(typeof(symbol)) to check if a symbol is defined, and you can use other forms of is() to specifically determine that it is a function.
