[Issue 3395] Ambiguous array operations
http://d.puremagic.com/issues/show_bug.cgi?id=3395 --- Comment #5 from Don 2011-11-30 23:03:41 PST --- > > Consider the case where we want y to be > > [ max(x[2][0..$]), max(x[3][0..$]), ... ] > > > > double [][20] x; > > double [10] y; > > > > Brainstorming a few possibilities: > > > > y[] = max(x[2..12]); // (1) looks like scalar assignment > > y[] = max[2..12](x); // (2) > > y[] = max(x[2..12])[]; // (3) > > That's ambiguous - maybe max is a function that returns an array or other type > with an opSlice(). True. But unlike (1), it's still obvious that it's an element-by-element assignment. The nett effect is the same as if it were vectorized. Is that an ambiguity that matters? > > Can we put the [] _before_ the call? y[] = [] max(x); > > y[] = x.[]max; > > Would [](expr) be the empty array's opCall(expr) or the vectorisation of the > function referenced by expr? And [].func be a vectorisation of the global > function func or the empty array's .func method? (Are you envisaging that [] > vectorises a whole subexpression or just the function whose name it > immediately precedes?) I was imagining just the function name. At least, I think it would need to have very high precedence. []a.b is the same as ([]a).b, rather than [](a.b). This, [].func would be the empty array's .func method, since there is no function name before the dot. I think then if you wanted to vectorize .func, you'd do it as: ".[]func". I'm less sure about [](expr) but I think it would just be an opCall. But I'm really just brainstorming. It's a wild idea. Haven't given any thought to if it works with function literals or function pointers. > > FWIW the other week I discovered C++11 variadic templates. I wonder if we can > draw inspiration from the unpacking syntax here > http://lanzkron.wordpress.com/2011/11/05/did-you-pack-that-yourself/ Yeah, that's interesting, it does look quite similar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7039] Posix 2.057 Makefile error breaking 64bit build
http://d.puremagic.com/issues/show_bug.cgi?id=7039 Brad Roberts changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||FIXED --- Comment #2 from Brad Roberts 2011-11-30 21:44:03 PST --- https://github.com/D-Programming-Language/phobos/commit/09c57ffe7580359be33712ddcec7e56e5581b78b -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7040] New: Phobos must use "version/else version" blocks for proper documentation generation
http://d.puremagic.com/issues/show_bug.cgi?id=7040
Summary: Phobos must use "version/else version" blocks for
proper documentation generation
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2011-11-30
17:02:51 PST ---
As reported here:
http://stackoverflow.com/questions/8335202/can-i-rely-on-the-presence-of-shell/8335304#8335304
The real issue is this:
/**
Doc comment..
*/
version (Posix) void test()
{
}
version (Windows) void test()
{
}
If you compile this on Posix, the docs get generated. If you compile it on
Windows, they *don't* get generated (The std.process has the opposite case, on
Windows the docs are generated but not on Posix). You need to use an else
version block instead:
/**
Doc comment..
*/
version (Posix) void test()
{
}
else version (Windows) void test()
{
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7034] Infinite foreach on array
http://d.puremagic.com/issues/show_bug.cgi?id=7034 --- Comment #1 from bearophile_h...@eml.cc 2011-11-30 17:00:40 PST --- Partially related: http://www.digitalmars.com/d/archives/digitalmars/D/learn/Foreach_with_byte_problems_24997.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7018] thrown Error from different thread should lead to program abort
http://d.puremagic.com/issues/show_bug.cgi?id=7018 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #6 from Jonathan M Davis 2011-11-30 16:57:07 PST --- They're Errors, not Exceptions, so they are _not_ expected to be recoverable. The fact that they are exceptions allows you to get more meaningful data on failures (e.g. stack traces), and you _can_ technically recover from them in very controlled circumstances but _only_ in very controlled circumstances where you really know what you're doing and you're very careful to make sure that it's actually safe to do the recovery. In the general case, they are _not_ expected to be recoverable and so are not treated that way. Once an Error is thrown, the program is in an undefined state, so it's questionable that you even _can_ recover except in very controlled circumstances. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7018] thrown Error from different thread should lead to program abort
http://d.puremagic.com/issues/show_bug.cgi?id=7018 Sean Kelly changed: What|Removed |Added CC||s...@invisibleduck.org --- Comment #5 from Sean Kelly 2011-11-30 16:34:21 PST --- If no cleanup should be performed, why is an assertion failure represented as an exception in the first place? And what about the other Errors that can legally be generated within a nothrow block (like OutOfMemoryError) but are technically recoverable? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7039] Posix 2.057 Makefile error breaking 64bit build
http://d.puremagic.com/issues/show_bug.cgi?id=7039 --- Comment #1 from Sascha Heylik 2011-11-30 16:03:46 PST --- Fix: https://github.com/D-Programming-Language/phobos/pull/339 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7039] New: Posix 2.057 Makefile error breaking 64bit build
http://d.puremagic.com/issues/show_bug.cgi?id=7039 Summary: Posix 2.057 Makefile error breaking 64bit build Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: sas...@heylik.at --- Comment #0 from Sascha Heylik 2011-11-30 15:54:46 PST --- The Phobos makefile (posix.mak) does not specify the architecture for building druntime, which defaults to 32bit even on if Phobos is being compiled for 64bit, the result is a broken lib. My fixed Makefile passes the MODEL=64 parameter down to druntime's make process, resulting in nice and working builds on both, 32 and 64bit systems. I will post it in just a sec. Happy hacking on 64 bit systems :P - Sascha Heylik -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 bioinfornatics changed: What|Removed |Added CC||bioinfornat...@gmail.com --- Comment #2 from bioinfornatics 2011-11-30 15:05:37 PST --- Yes it was exactly what i looking i.e => http://lists.puremagic.com/pipermail/digitalmars-d-learn/2011-November/028194.html i vote +1 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6963] pure/nothrow inference doesn't work for function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=6963 Kenji Hara changed: What|Removed |Added Keywords||patch, rejects-valid Platform|Other |All OS/Version|Windows |All --- Comment #2 from Kenji Hara 2011-11-30 14:50:45 PST --- https://github.com/D-Programming-Language/dmd/pull/544 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #5 from Walter Bright 2011-11-30 14:31:30 PST --- (In reply to comment #2) > Yes I know, but the problem occurs even before the called function is > executed: > The PLT is a table containing executable code. If you do an position > independent function call, you call into this PLT code, not directly into your > target function. And these PLT instructions require EBX to be set to the GOT > address. You're right. DMD doesn't do this at the moment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6354] Optimizer bug on x86_64: Bitshift optimized out when foreach and scope(failure) are used
http://d.puremagic.com/issues/show_bug.cgi?id=6354 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright 2011-11-30 13:43:39 PST --- https://github.com/D-Programming-Language/dmd/commit/c468e89347d2f7306a64bfaa46e46fc3bf96b612 https://github.com/D-Programming-Language/dmd/commit/062351c39c6337eb09338a209d8e945c489852de -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #4 from Trass3r 2011-11-30 11:32:10 PST --- Created an attachment (id=1047) my Makefile adjustments I tried it on x64: $ make MODEL=64 -f posix.mak -j2 cc -c -m64 -O -fPIC src/core/stdc/errno.c -oobj/errno_c.o cc -Wa,-noexecstack -c -m64 -O -fPIC src/core/threadasm.S -oobj/threadasm.o cc -c -m64 -O -fPIC src/rt/complex.c -oobj/complex.o ... dmd -c -oflib/ofdrt.o -m64 -O -fPIC -release -inline -nofloat -w -d -Isrc -Iimport src/object_.d [..] gcc -shared -Wl,-export-dynamic,-soname,lib/libdruntime.so.1 -o lib/libdruntime.so.1.0.1 lib/ofdrt.o obj/errno_c.o obj/threadasm.o obj/complex.o /usr/bin/ld: lib/ofdrt.o: relocation R_X86_64_PC32 against symbol `_Dmodule_ref' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7038] New: Type mismatch with const struct
http://d.puremagic.com/issues/show_bug.cgi?id=7038
Summary: Type mismatch with const struct
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO 2011-11-30 09:33:19 PST ---
This code should be compiled:
--
A a;
const struct A { }
A b;
static assert(is(typeof(a) == typeof(b))); // Error: static assert (is(A ==
const(A))) is false
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7037] New: TemplateTypeParameterSpecialization works differently from IsExpression regarding alias this
http://d.puremagic.com/issues/show_bug.cgi?id=7037
Summary: TemplateTypeParameterSpecialization works differently
from IsExpression regarding alias this
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas 2011-11-30 03:15:03
PST ---
struct Foo {}
struct Bar {
Foo f;
alias f this;
}
void works( T )( T value ) if ( is( T : Foo ) ) {}
void doesnotwork( T : Foo )( T value ) {}
void main( ) {
Bar b;
works( b );
doesnotwork( b );
}
The 'works' function runs without problem, 'doesnotwork' does (can you guess?)
not work.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3395] Ambiguous array operations
http://d.puremagic.com/issues/show_bug.cgi?id=3395 --- Comment #4 from Stewart Gordon 2011-11-30 03:02:18 PST --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > These expressions are ambiguous: > > > --- > > > a[].max(n); > > > a[1..4].max(n); > > > --- > > > Does it mean calling the function on the slice or on each item in the > > > slice? > > > > It means calling the function on the slice. Unless I'm mistaken, there > > isn't > > any D syntax at the moment that means calling the function on each element > > of > > the array. > > That's correct. > > > > Possible solution is to change the meaning of empty square brackets from > > > full > > > slice to only a hint for array operation so that a[].max(n) is an array > > > operation and a[1..4].max(n) is max(a[1..4],n). > > > This would get confusing. You might want to apply a function to the whole > > slice [1..4] or to each element of the slice. This applies whether the > > array-property sugar is being used or not. > > > > Perhaps the best solution is to define [] applied to the function identifier > > itself to do an elementwise application. > > > > So max(a, n) or a.max(n) would just call max(a, n) once. > > And max[](a, n) or a.max[](n) would evaluate to an array of max(a[i], n). > > And the same if a is replaced with a[], a[1..4] or some such in each case. > > That looks to me as if max is an array of some struct S which defines an > opCall. > > > Of course, ambiguities can still occur in functions with multiple array > > parameters. Presumably the language would forbid it in these ambiguous > > cases, > > as it does already with ambiguous overload matching. > > Consider the case where we want y to be > [ max(x[2][0..$], max(x[3][0..$], ... ] > > double [][20] x; > double [10] y; > > Brainstorming a few possibilities: > > y[] = max(x[2..12]); // (1) looks like scalar assignment > y[] = max[2..12](x); // (2) > y[] = max(x[2..12])[]; // (3) That's ambiguous - maybe max is a function that returns an array or other type with an opSlice(). > Can we put the [] _before_ the call? y[] = [] max(x); > y[] = x.[]max; Would [](expr) be the empty array's opCall(expr) or the vectorisation of the function referenced by expr? And [].func be a vectorisation of the global function func or the empty array's .func method? (Are you envisaging that [] vectorises a whole subexpression or just the function whose name it immediately precedes?) FWIW the other week I discovered C++11 variadic templates. I wonder if we can draw inspiration from the unpacking syntax here http://lanzkron.wordpress.com/2011/11/05/did-you-pack-that-yourself/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7036] New: Using std.string.format on a shared value throws access violation
http://d.puremagic.com/issues/show_bug.cgi?id=7036
Summary: Using std.string.format on a shared value throws
access violation
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2011-11-30
01:44:10 PST ---
import std.string;
void main()
{
shared int val;
auto x = format("%s", val);
}
object.Error: Access Violation
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3395] Ambiguous array operations
http://d.puremagic.com/issues/show_bug.cgi?id=3395 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #3 from Don 2011-11-30 00:30:12 PST --- (In reply to comment #2) > (In reply to comment #0) > > These expressions are ambiguous: > > --- > > a[].max(n); > > a[1..4].max(n); > > --- > > Does it mean calling the function on the slice or on each item in the slice? > > It means calling the function on the slice. Unless I'm mistaken, there isn't > any D syntax at the moment that means calling the function on each element of > the array. That's correct. > > Possible solution is to change the meaning of empty square brackets from > > full > > slice to only a hint for array operation so that a[].max(n) is an array > > operation and a[1..4].max(n) is max(a[1..4],n). > This would get confusing. You might want to apply a function to the whole > slice [1..4] or to each element of the slice. This applies whether the > array-property sugar is being used or not. > > Perhaps the best solution is to define [] applied to the function identifier > itself to do an elementwise application. > > So max(a, n) or a.max(n) would just call max(a, n) once. > And max[](a, n) or a.max[](n) would evaluate to an array of max(a[i], n). > And the same if a is replaced with a[], a[1..4] or some such in each case. That looks to me as if max is an array of some struct S which defines an opCall. > Of course, ambiguities can still occur in functions with multiple array > parameters. Presumably the language would forbid it in these ambiguous cases, > as it does already with ambiguous overload matching. Consider the case where we want y to be [ max(x[2][0..$], max(x[3][0..$], ... ] double [][20] x; double [10] y; Brainstorming a few possibilities: y[] = max(x[2..12]); // (1) looks like scalar assignment y[] = max[2..12](x); // (2) y[] = max(x[2..12])[]; // (3) y[] = max([] x[2..12]); // (4) y[] = max([] x[2..12])[]; // (5) messy! (2) does looks like an opCall on array called 'max'. (3) looks the most intuitive to me. Not perfect though (I don't think we'd want y[] = max(x[2..12]); to compile and be a scalar). (4) is an interesting possibility. Doesn't look great, but it seems to be a syntax hole. Ambiguous in the one-argument property case: x.max([]) could be: max([] x) or max(x, []) where the [] is an empty array literal. I think that's solvable though. Interestingly it's the case where (2) is cleanest: x.max[]; Can we put the [] _before_ the call? y[] = [] max(x); y[] = x.[]max; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
