[Issue 14612] typeid(interface) returns TypeInfo_Class object
https://issues.dlang.org/show_bug.cgi?id=14612
--- Comment #4 from Rainer Schuetze r.sagita...@gmx.de ---
And you can do the latter behavior by typeid(cast(Object)obj).
I feel that syntactic cost is enough small.
cast(Object) creates a call into the runtime (_d_interface_cast) and is pretty
expensive. It could be optimized to the series of indirections by the compiler,
though.
In short, the orthogonality may have been priority than the intuitive, but
complex behavior.
The complex behaviour costs just an additional reading of an offset to the
object base address, very much what a thunk does when calling a virtual
function.
I guess the current behaviour could be described as typeid(I) evaluates to the
most derived interface that is implemented by the object and that inherits from
the static type.
But most derived is not well defined when it comes to inheriting from
multiple interfaces:
import std.stdio;
interface I {}
interface J : I {}
interface K : I {}
class E : J, K {}
void main()
{
E e = new E;
J j = e;
K k = e;
I ij = j;
I ik = k;
writeln(typeid(ij)); // prints 'test.J' !?
writeln(typeid(ik)); // prints 'test.K' !?
}
--
Re: LDC for iOS prebuilt binaries
On Friday, 10 July 2015 at 05:38:47 UTC, Dan Olson wrote: Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com writes: [...] [...] http://www.itoolchain.com/ or iPhone toolchain on cygwin
Re: Initial feedback for std.experimental.image
On Friday, 10 July 2015 at 05:27:21 UTC, rikki cattermole wrote: What we need is a unsigned integer type of word size that can have an out of bounds value aka negative. While also supporting calculations that is both signed and unsigned. So basically a unsigned integer behaving like a signed one. Now wouldn't that solve the problem we have? Yeah we have those, they are called signed integers... But for real, you are way over complicating the problem, just use an int.
Re: Wait, what? What is AliasSeq?
On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote: I personally think this auto-expanding argument is overrated. I don't have any particular expectation regarding auto-expansion towards the concept tuple. But he's right that we have auto-expanding and non-expanding tuples, so having a different term for the auto-expanding one would help a bit.
Re: Wait, what? What is AliasSeq?
On Wednesday, 8 July 2015 at 16:44:13 UTC, Jonathan M Davis wrote:
On Wednesday, 8 July 2015 at 14:45:55 UTC, Xiaoxi wrote:
On Wednesday, 8 July 2015 at 14:18:20 UTC, Jonathan M Davis
wrote:
And renaming TypeTuple to Aliases is just going to increase
confusion.
- Jonathan M Davis
It's basically just __VA_ARGS__ on steroids, thus 'Arguments'
is good, there's precedence in C(Args).
LOL. Then what about when you use it for _parameters_ rather
than arguments? Or when you use it areas that have _nothing_ to
do with functions - e.g.
foreach(S; TypeTuple!(string, char[], wstring, dstring))
{
//...
}
Naming it Arguments gives the impression that it's specifically
related to arguments, and that's just one small area that it
gets used in. And that's part of what's so hard about naming
it. It just does way too many things to name easily.
- Jonathan M Davis
You just made the argument for calling it Arguments by arguing
against its name being Arguments.
arguments and parameters are both basically the same thing and so
is the example where you use it as the arguments to a foreach
loop.
Most of the suggestions are too low level, fact is its a Tuple :D
Re: Wait, what? What is AliasSeq?
On Thursday, 9 July 2015 at 19:10:39 UTC, Jonathan M Davis wrote: On Thursday, 9 July 2015 at 18:45:56 UTC, Marc Schütz wrote: Interestingly, it goes on by saying: An n-tuple is defined inductively using the construction of an ordered pair. Although not stated explicitly, this implies (a kind of) auto expanding! = Fits more than perfectly :-P No one who has ever seriously used tuples in any programming language I've ever heard of would expect tuples to auto expand. Auto expansion makes them _considerably_ less useful. In the case of TypeTuple/AliasSeq, the situation is a bit different, because we're not really talking about tuples here. Real tuples nest, and they don't auto expand. But my quote above that they _don't_ nest and _do_ auto-expand, how else could you construct n-tuples from pairs? TypeTuple/AliasSeq is the _only_ case I've ever seen where someone tried to claim that something was a tuple when it didn't nest, or it auto-expanded. Folks have been consistently confused about the differences between TypeTuple and std.typecons.Tuple and the fact that TypeTuples auto expand. No one expects it - because tuples just don't do that in any actual programming languages. I question the validity of your interpretation of the theory as well, but even if it's valid, it doesn't match what's done in actual programming languages. I personally think this auto-expanding argument is overrated. I don't have any particular expectation regarding auto-expansion towards the concept tuple. Sure, it may be surprising, but that doesn't stop an auto expanding tuple from being a tuple, just like Perl arrays being auto-expanding doesn't stop them from being arrays.
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Friday, 10 July 2015 at 03:18:23 UTC, Mike Parker wrote: You should just be able to replace `[4]` with `*` in the arguments. [1]http://dlang.org/interfaceToC.html Great! One more thing: How shall my call to `avg_image_copy()` (from D) look then? Is the slicing syntax `[0 .. 4]` I use above as av_image_copy(target.data[0 .. 4], target.linesize[0 .. 4], source.data[0 .. 4], source.linesize[0 .. 4], format, source.width, source.height); the best way?
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Friday, 10 July 2015 at 03:18:23 UTC, Mike Parker wrote: [1]http://dlang.org/interfaceToC.html Is there any tool out there that automatically creates D wrappers from C headers`?
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Friday, 10 July 2015 at 08:42:06 UTC, Per Nordlöw wrote: On Friday, 10 July 2015 at 03:18:23 UTC, Mike Parker wrote: [1]http://dlang.org/interfaceToC.html Is there any tool out there that automatically creates D wrappers from C headers`? https://github.com/jacob-carlborg/dstep ?
Re: Wait, what? What is AliasSeq?
On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote: On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote: I personally think this auto-expanding argument is overrated. I don't have any particular expectation regarding auto-expansion towards the concept tuple. But he's right that we have auto-expanding and non-expanding tuples, so having a different term for the auto-expanding one would help a bit. Only minimally. We also have different kinds of ranges, but their names are all just XxxRange. I can of course only speak for myself, but having a `Tuple` and an `AliasTuple`, one auto-expanding and the other not, doesn't confuse me.
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Friday, 10 July 2015 at 08:54:57 UTC, Andrea Fontana wrote: Is there any tool out there that automatically creates D wrappers from C headers`? https://github.com/jacob-carlborg/dstep ? Great! I'll try that!
Re: Extend D's switch statement?
On Thursday, 9 July 2015 at 22:50:37 UTC, Vlad Levenfeld wrote:
On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:
On 07/09/2015 04:17 PM, Timon Gehr wrote:
On 07/09/2015 02:54 PM, rsw0x wrote:
...
someone was willing to produce.
Someone is often willing to produce awkward language quirks,
so I think
being critical of new additions has some value.
E.g.
Note: Cannot swap values by tuple assignment.
int x = 1, y = 2;
{x, y} = {y, x};
// Lowered to:
// x = y, y = x;
assert(y == 2);
assert(x == 2);
No, please.
Couldn't this could be detected at compile-time and temporary
variables created?
Yes, but there needs to be a complete aliasing analysis, e.g.
int* x, y;
// ...
{*x, *y} = {*y, *x};
It's probably safer to create the temporaries by default and
elide them when the elements are provably non-aliasing.
Re: Wait, what? What is AliasSeq?
On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote: But he's right that we have auto-expanding and non-expanding tuples, so having a different term for the auto-expanding one would help a bit. This unpacking is called splatting in some other PLs that have a splat operator. Maybe we can use that to describe the unpackedness, e.g. AliasSplat.
Re: Binding Nested C Structs
On 2015-07-10 05:38, Craig Dillabaugh wrote:
I am trying to bind to a C union with a number of nested structs
declared as follows:
typedef union {
int Integer;
struct {
int nCount;
int *paList;
} IntegerList;
struct {
int nCount;
GIntBig *paList;
} Integer64List;
} OGRField;
According to http://wiki.dlang.org/D_binding_for_C#Nested_Structs
I should attempt to write something like (last example shown):
extern(C) union OGRField
{
int Integer;
struct {
int nCount;
int* paList;
}
struct {
int nCount;
GIntBig* paList;
}
}
But that is obviously not going to work. Does anyone know the right way
to handle nested C structs of that form.
I think it will work but the API would be different.
--
/Jacob Carlborg
[Issue 13596] permutations range
https://issues.dlang.org/show_bug.cgi?id=13596 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords||pull CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Wrote something like this before finding this issue: https://github.com/D-Programming-Language/phobos/pull/3482 --
[Issue 13596] permutations range
https://issues.dlang.org/show_bug.cgi?id=13596 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Priority|P1 |P3 Hardware|x86 |All OS|Windows |All --
Re: Voting for std.experimental.allocator
Yes!
[Issue 7753] Support opIndexCreate as part of index operator overloading in user-defined types
https://issues.dlang.org/show_bug.cgi?id=7753 Puneet Goel pun...@coverify.org changed: What|Removed |Added CC||pun...@coverify.org --
Re: DIP-74 Reference Cycles
On Thursday, 9 July 2015 at 08:58:22 UTC, deadalnix wrote: The escape analysis needs to be in the compiler. Proposed DIPs do a poor job at it as they require a bag of tricks instead of a principled approach IMO. The part where refcount is done can be done via library (and should IMO). Right, there are a number of proposals to make a library implementation powerful enough. http://wiki.dlang.org/DIP69#Scope_Function_Returns http://wiki.dlang.org/DIP77
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 09:27:19 UTC, Nordlöw wrote: How do I tell `dub build` where to find libraries in non-standard directories? From the command line that is...
DUB Build Linker Library Search Path
My DUB building of dstep on Ubuntu 15.04 fails because it can't find the libclang which is placed in /usr/lib/llvm3-6/lib/libclang.so.1 How do I tell `dub build` where to find libraries in non-standard directories?
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 09:27:19 UTC, Nordlöw wrote: How do I tell `dub build` where to find libraries in non-standard directories? You're missing the development package libclang-dev, which should come with a pkg-config.
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 09:29:49 UTC, Martin Nowak wrote: On Friday, 10 July 2015 at 09:27:19 UTC, Nordlöw wrote: How do I tell `dub build` where to find libraries in non-standard directories? You're missing the development package libclang-dev, which should come with a pkg-config. I've already installed libclang-dev. The problem is that I can't find a way (from the command line) (by reading the DUB docs) to tell DUB that it's placed in /usr/lib/llvm-3.6/lib/libclang.so.1 I don't what to have to modify the dub.json (lflags variable) as I want automation. Aren't all DUB the variables somehow modifiable in shell call?! Further `pkg-config --list-all |grep clang` shows nothing.
Re: DUB Build Linker Library Search Path
On 10/07/2015 9:34 p.m., Nordlöw wrote: On Friday, 10 July 2015 at 09:29:49 UTC, Martin Nowak wrote: On Friday, 10 July 2015 at 09:27:19 UTC, Nordlöw wrote: How do I tell `dub build` where to find libraries in non-standard directories? You're missing the development package libclang-dev, which should come with a pkg-config. I've already installed libclang-dev. The problem is that I can't find a way (from the command line) (by reading the DUB docs) to tell DUB that it's placed in /usr/lib/llvm-3.6/lib/libclang.so.1 I don't what to have to modify the dub.json (lflags variable) as I want automation. Aren't all DUB the variables somehow modifiable in shell call?! Further `pkg-config --list-all |grep clang` shows nothing. LFLAGS=... dub build
Re: Phobos addition formal review: std.experimental.allocator
On Friday, 12 June 2015 at 11:06:43 UTC, Dicebot wrote: The legendary allocator package by Andrei Alexandrescu has arrived at your doorsteps and kindly asks to let it into Phobos Sorry for being late, I wanted to restate an idea that could be crucial for optimizations. https://github.com/D-Programming-Language/druntime/pull/1183#issuecomment-77065554 This reminds me of the fact, that the IAllocator interface (std.allocator) should also have a strongly pure allocate function. This might allow the compiler to optimize allocations even with a dynamic dispatch allocator, because it assumes that an allocation doesn't have a side-effect and always returns fresh unaliased memory. Chandler Carruth was talking about this problem at the last CppCon. https://www.youtube.com/watch?v=fHNmRkzxHWst=3950 https://www.youtube.com/watch?v=fHNmRkzxHWst=4037 Now putting pure onto the allocate function of IAllocator would be a very harsh constraint for any implementation. So maybe we could employ a compiler hack, marking any IAllocator.allocate implementation as pure. This optimization is really important, b/c it allows the compiler to ellide allocations when it can compute something using a temporary buffer. It'd probably require a magic free as well, so that the compiler knows the lifetime and sees that data isn't escaped.
Re: Wait, what? What is AliasSeq?
On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote: I personally think this auto-expanding argument is overrated. I don't have any particular expectation regarding auto-expansion towards the concept tuple. Sure, it may be surprising, but that doesn't stop an auto expanding tuple from being a tuple, just like Perl arrays being auto-expanding doesn't stop them from being arrays. You know there a thing scientific do that is called experiment. In this case the experiment of calling this a tuple has been made, and it confused the hell out of everybody for years. You can argue against reality all you want. The fact is, people expect tuples to not autoexpand.
Re: Wait, what? What is AliasSeq?
On Friday, 10 July 2015 at 10:05:19 UTC, deadalnix wrote: On Friday, 10 July 2015 at 08:37:56 UTC, Marc Schütz wrote: I personally think this auto-expanding argument is overrated. I don't have any particular expectation regarding auto-expansion towards the concept tuple. Sure, it may be surprising, but that doesn't stop an auto expanding tuple from being a tuple, just like Perl arrays being auto-expanding doesn't stop them from being arrays. You know there a thing scientific do that is called experiment. In this case the experiment of calling this a tuple has been made, and it confused the hell out of everybody for years. You can argue against reality all you want. The fact is, people expect tuples to not autoexpand. the reason tuple was confusing is because it's already used by another completely distinct type.
Re: Difference between __gshared and shared.
On Thursday, 9 July 2015 at 14:57:56 UTC, Márcio Martins wrote: On Thursday, 9 July 2015 at 14:03:18 UTC, Jonathan M Davis wrote: On Thursday, 9 July 2015 at 12:39:00 UTC, Márcio Martins wrote: [...] Well, the compiler is free to assume that a variable that is not marked as shared is thread-local. So, it's free to make optimizations based on that. So, for instance, it can know for a fact that [...] But this is what a C/C++ compiler would do, unless you your data is qualified as volatile. I believe __gshared also implies the volatile behavior, right? I wouldn't make sense any other way. So basically, __gshared is like saying I want the C/C++ behavior, and I accept I am all on my own as the compiler will not help me. If you think volatile is going to help you with concurency, you gonna have bad time. The only thing volatile does is to prevent register promotion of the variable. It is usefull for MMIO, it doesn't provide guarantee for multithreading.
Re: Wait, what? What is AliasSeq?
On Friday, 10 July 2015 at 09:05:10 UTC, Martin Nowak wrote: On Friday, 10 July 2015 at 08:42:44 UTC, Martin Nowak wrote: But he's right that we have auto-expanding and non-expanding tuples, so having a different term for the auto-expanding one would help a bit. This unpacking is called splatting in some other PLs that have a splat operator. Maybe we can use that to describe the unpackedness, e.g. AliasSplat. http://www.infoq.com/presentations/functional-pros-cons
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 09:37:42 UTC, Rikki Cattermole wrote: On 10/07/2015 9:34 p.m., Nordlöw wrote: On Friday, 10 July 2015 at 09:29:49 UTC, Martin Nowak wrote: On Friday, 10 July 2015 at 09:27:19 UTC, Nordlöw wrote: How do I tell `dub build` where to find libraries in non-standard directories? You're missing the development package libclang-dev, which should come with a pkg-config. I've already installed libclang-dev. The problem is that I can't find a way (from the command line) (by reading the DUB docs) to tell DUB that it's placed in /usr/lib/llvm-3.6/lib/libclang.so.1 I don't what to have to modify the dub.json (lflags variable) as I want automation. Aren't all DUB the variables somehow modifiable in shell call?! Further `pkg-config --list-all |grep clang` shows nothing. LFLAGS=... dub build LDFLAGS=-L/usr/lib/llvm-3.6/lib dub build --compiler=/usr/bin/dmd -v has not effect: /usr/bin/dmd -of.dub/build/default-debug-linux.posix-x86_64-dmd_2067-0E9173B3A2F733029144DC3F174B9E99/dstep -debug -g -version=Have_dstep -version=Have_dstack -version=Have_mambo -version=Have_tango -Idstep -Iclang -I../../.dub/packages/dstack-0.0.3 -I../../.dub/packages/mambo-0.0.4 -I../../.dub/packages/tango-1.0.1_2.067 -Jresources clang/Compiler.d clang/Cursor.d clang/Diagnostic.d clang/File.d clang/Index.d clang/SourceLocation.d clang/TranslationUnit.d clang/Type.d clang/Util.d clang/Visitor.d clang/c/CXErrorCode.d clang/c/CXString.d clang/c/Index.d dstep/config/Configuration.d dstep/core/Exceptions.d dstep/driver/Application.d dstep/driver/DStep.d dstep/translator/Declaration.d dstep/translator/Enum.d dstep/translator/IncludeHandler.d dstep/translator/Output.d dstep/translator/Record.d dstep/translator/Translator.d dstep/translator/Type.d dstep/translator/objc/Category.d dstep/translator/objc/ObjcInterface.d ../../.dub/packages/dstack-0.0.3/libdstack.a ../../.dub/packages/mambo-0.0.! 4/libmambo.a ../../.dub/packages/tango-1.0.1_2.067/libtango.a -L-lclang -L-rpath -L. -L-L. -L-lbz2 -vcolumns ../../.dub/packages/mambo-0.0.4/mambo/util/Traits.d(154,39): Deprecation: typedef is removed ../../.dub/packages/mambo-0.0.4/mambo/util/Traits.d(182,30): Deprecation: typedef is removed /usr/bin/ld: error: cannot find -lclang Using export as export LDFLAGS=-L/usr/lib/llvm-3.6/lib; dub build --compiler=/usr/bin/dmd doesn't work either. Adding -L-L/usr/lib/llvm3-6/lib to the call to dmd works. What's wrong with my call to DUB? I'm sitting on DUB git master.
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 12:04:53 UTC, Nordlöw wrote: Should be LFLAGS=-L/usr/lib/llvm-3.6/lib dub build --compiler=/usr/bin/dmd but still fails I can't find any place in the DUB sources that reads `LFLAGS` from the environment. Only one place when `DFLAGS` is read. A regression? Do you want me to add this?
Re: Import module
On Friday, 10 July 2015 at 03:11:25 UTC, Mike Parker wrote:
On Friday, 10 July 2015 at 00:53:38 UTC, codenstuff wrote:
The path is ${HOME}/d_apps/steering/steering/game_object.d
[...]
First, because you are importing sterring.game_object, then you
can't pass -I/home/real/d_apps/steering to the compiler -- this
will cause it to look for
/home/real/d_apps/steering/sterring/game_object.d. You have to
pass the parent of the steering directory, i.e. -I/home
real/d_apps. Then it will be able to find the import.
He said The path is
${HOME}/d_apps/steering/steering/game_object.d, so
-I/home/real/d_apps/steering should be correct.
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 11:56:23 UTC, Nordlöw wrote: fails aswell: Should be LFLAGS=-L/usr/lib/llvm-3.6/lib dub build --compiler=/usr/bin/dmd but still fails
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Thursday, 2 July 2015 at 12:22:31 UTC, Atila Neves wrote:
On Wednesday, 1 July 2015 at 19:38:20 UTC, Jacob Carlborg wrote:
On 01/07/15 10:40, Atila Neves wrote:
[...]
You could write shouldBe.gt(value).
[...]
In every project I have used RSpec I have added custom
matchers/assertions. Just a couple of days ago I added a
custom matcher to one of my projects:
[...]
Ah, makes sense. I think I'm convinced now. The UFCS as an
extension mechanism could indeed be handy.
Atila
So... unconvinced again. I tried implementing it and it started
getting to be a right royal pain, and then I realised that
there's nothing to prevent a user from writing their own matchers
right now. From your example:
void shouldBeParsedAs(Code code, ASTNode node) { //I don't
really know what the types should be
if(...) {
throw new UnitTestException(...);
}
}
And... done. No need for a `Should` struct, no need for the
complications I faced trying to use one. I think the design is as
good as it can be.
Atila
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 11:02:16 UTC, Nordlöw wrote: What's wrong with my call to DUB? I'm sitting on DUB git master. Found DFLAGS=-L-L/usr/lib/llvm-3.6/lib dub build --compiler=/usr/bin/dmd to work but that's a bit ugly.
Re: Import module
On Friday, 10 July 2015 at 10:22:39 UTC, anonymous wrote:
On Friday, 10 July 2015 at 00:53:38 UTC, codenstuff wrote:
On Friday, 10 July 2015 at 00:24:44 UTC, anonymous wrote:
[...]
[...]
The path is ${HOME}/d_apps/steering/steering/game_object.d
Compile command is
dmd map/map.d main_visual.d -ofmain_visual -H -gc -unittest
-L-lDgame -L-lDerelictUtil -L-lDerelictGL3 -L-lDerelictSDL2
-L-ldl -I/home/real/d_apps/dgame/source
-I/home/real/d_apps/derelict_util/source
-I/home/real/d_apps/derelict_gl3/source
-I/home/real/d_apps/derelict_sdl2/source
-I/home/real/d_apps/steering
Compiler message is same
The error message doesn't list any of your import paths. So I
still think that the message doesn't belong to that command.
Maybe try reducing things to a smaller, self-contained test
case.
ok thanks that worked
Re: Extend D's switch statement?
On Friday, 10 July 2015 at 21:37:10 UTC, Timon Gehr wrote:
On 07/10/2015 12:50 AM, Vlad Levenfeld wrote:
On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:
On 07/09/2015 04:17 PM, Timon Gehr wrote:
On 07/09/2015 02:54 PM, rsw0x wrote:
...
someone was willing to produce.
Someone is often willing to produce awkward language quirks,
so I think
being critical of new additions has some value.
E.g.
Note: Cannot swap values by tuple assignment.
int x = 1, y = 2;
{x, y} = {y, x};
// Lowered to:
// x = y, y = x;
assert(y == 2);
assert(x == 2);
No, please.
Couldn't this could be detected at compile-time and temporary
variables
created?
Oh, it certainly is simple to fix, it's just that we don't want
this sort of thing to make it into the language specification.
Why not? Tuple handling seems like it should be a 1st class
language feature... the disconnect between Tuple and TypeTuple
always bothered me on a philosophical (and syntactic) level.
Re: Initial feedback for std.experimental.image
On Friday, 10 July 2015 at 23:21:02 UTC, ketmar wrote: On Thu, 09 Jul 2015 23:35:00 +, Vladimir Panteleev wrote: On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole wrote: I've been sold on the unsigned vs signed type issue for and only for the x and y coordinates. The first version of ae.utils.graphics had unsigned coordinates. As I found out, this was a mistake. A rule of thumb I discovered is that any numbers you may want to subtract, you should use signed types. Otherwise, operations such as drawing an arc with its center point off-canvas (with negative coordinates) becomes unreasonably complicated. giving that `int` and `uint` are freely interchangeable... `uint` is better, as it allows only one bound check in `if`, and without casts. ;-) That's a poor reason. Optimizing x=0 x100 to an unsigned check is such a basic optimization, even DMD can do it.
Re: Initial feedback for std.experimental.image
On Friday, 10 July 2015 at 23:23:32 UTC, ketmar wrote: On Fri, 10 Jul 2015 03:59:29 +, Tofu Ninja wrote: On Friday, 10 July 2015 at 03:00:57 UTC, Rikki Cattermole wrote: getPixel/putPixel or a variation of such? This is the most common name for such functions. Fine by me. This is honestly just nitpicking, but I see setPixel more than putPixel I think. i'm using `setPixel` to change pixel unconditionally (think of it as set rgb), and `putPixel` to blend pixel (think of it as do rgba color mix). Wouldn't that better be called blendPixel?
Re: Initial feedback for std.experimental.image
On Fri, 10 Jul 2015 03:59:29 +, Tofu Ninja wrote: On Friday, 10 July 2015 at 03:00:57 UTC, Rikki Cattermole wrote: getPixel/putPixel or a variation of such? This is the most common name for such functions. Fine by me. This is honestly just nitpicking, but I see setPixel more than putPixel I think. i'm using `setPixel` to change pixel unconditionally (think of it as set rgb), and `putPixel` to blend pixel (think of it as do rgba color mix). signature.asc Description: PGP signature
Re: Stable partition3 implementation
On 07/11/2015 02:32 AM, Xinok wrote: On Friday, 10 July 2015 at 21:26:50 UTC, Timon Gehr wrote: I think this method is likely to be less practically relevant than the one they improve upon. (log* n really is constant for all practical purposes, it is the number of times one needs to iteratively take the logarithm until a number below 1 is obtained.) log* n grows fast for small inputs, No, it does not. It has no space to grow. With base e, it is 3 or 4 for all input sizes that matter: http://www.wolframalpha.com/input/?i=plot+IteratedLog+from+0+to+2^8 http://www.wolframalpha.com/input/?i=plot+IteratedLog+from+0+to+2^32 http://www.wolframalpha.com/input/?i=plot+IteratedLog+from+0+to+2^64 http://www.wolframalpha.com/input/?i=IteratedLog%282^2^2^2^2%29 so we can't simply ignore it. There is a priori no practical difference between a O(n) algorithm and a O(n*log*(n)) algorithm. It all depends on the constants, and it is hence not clear-cut that the O(n) algorithm will run faster. I'm just saying that this should be taken into consideration. For example, if n = 2^16 = 65536, then n*lg(n) = 16*2^16 = 2^20 = 1048576. ... The algorithm runs in O(n*log*(n)). It's not n log(n). That paper appears to be available here: https://github.com/lispc/lispc.github.com/raw/master/assets/files/situ.pdf No idea what the constant is though, I have not read the paper (yet). I don't know if there is anything relevant but that paper focuses on a different problem involving sorting. No, it focuses on a few closely related problems, and the O(n*log*(n))-algorithms solves a problem that is a straightforward generalization of the problem you are looking at. Stable three way partition is stable sorting where there are only three distinct values (smaller, equal, greater). The paper you provided builds on top of this algorithm. It is the main reference and part (ii) of the Algorithm B part of the O(n)/O(1) algorithm does not occur in the paper you provided, but only in that other paper, so yes, it is relevant. :-)
Re: Stable partition3 implementation
On 7/9/15 5:57 PM, Xinok wrote: I wanted to get some feedback on a stable partition3 implementation for Phobos before I work on a pull request. I wrote this implementation which is in-place (zero memory allocations) but runs in O(n lg n) time. http://dpaste.dzfl.pl/e12f50ad947d I found this paper which describes an in-place algorithm with O(n) time complexity but it's over my head at the moment. http://link.springer.com/article/10.1007%2FBF01994842 It is trivial to implement an algorithm with O(n) time complexity and O(n) space complexity, but that requires allocating memory. Furthermore, using a buffer requires the range to have assignable elements. Any thoughts? I'd say both would be nice (not to mention the one in the paper) so how about both are present selectable with a policy ala Yes.tightMemory or something. -- Andrei
Re: Extend D's switch statement?
On 07/11/2015 12:50 AM, Vlad Levenfeld wrote:
On Friday, 10 July 2015 at 21:37:10 UTC, Timon Gehr wrote:
On 07/10/2015 12:50 AM, Vlad Levenfeld wrote:
On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:
On 07/09/2015 04:17 PM, Timon Gehr wrote:
On 07/09/2015 02:54 PM, rsw0x wrote:
...
someone was willing to produce.
Someone is often willing to produce awkward language quirks, so I
think
being critical of new additions has some value.
E.g.
Note: Cannot swap values by tuple assignment.
int x = 1, y = 2;
{x, y} = {y, x};
// Lowered to:
// x = y, y = x;
assert(y == 2);
assert(x == 2);
No, please.
Couldn't this could be detected at compile-time and temporary variables
created?
Oh, it certainly is simple to fix, it's just that we don't want this
sort of thing to make it into the language specification.
Why not? Tuple handling seems like it should be a 1st class language
feature... the disconnect between Tuple and TypeTuple always bothered me
on a philosophical (and syntactic) level.
..?
We don't want the /broken/ thing, which I cited, to make it into the
language specification.
Re: Initial feedback for std.experimental.image
On Thu, 09 Jul 2015 23:35:00 +, Vladimir Panteleev wrote: On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole wrote: I've been sold on the unsigned vs signed type issue for and only for the x and y coordinates. The first version of ae.utils.graphics had unsigned coordinates. As I found out, this was a mistake. A rule of thumb I discovered is that any numbers you may want to subtract, you should use signed types. Otherwise, operations such as drawing an arc with its center point off-canvas (with negative coordinates) becomes unreasonably complicated. giving that `int` and `uint` are freely interchangeable... `uint` is better, as it allows only one bound check in `if`, and without casts. ;-) signature.asc Description: PGP signature
Re: Stable partition3 implementation
On Friday, 10 July 2015 at 21:26:50 UTC, Timon Gehr wrote: I think this method is likely to be less practically relevant than the one they improve upon. (log* n really is constant for all practical purposes, it is the number of times one needs to iteratively take the logarithm until a number below 1 is obtained.) log* n grows fast for small inputs, so we can't simply ignore it. For example, if n = 2^16 = 65536, then n*lg(n) = 16*2^16 = 2^20 = 1048576. That paper appears to be available here: https://github.com/lispc/lispc.github.com/raw/master/assets/files/situ.pdf No idea what the constant is though, I have not read the paper (yet). I don't know if there is anything relevant but that paper focuses on a different problem involving sorting.
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On 11-Jul-2015 00:26, Joakim wrote: On Friday, 10 July 2015 at 20:42:02 UTC, Dmitry Olshansky wrote: On 10-Jul-2015 23:34, Joakim wrote: On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/ Answered. Never knew it was there at all. Oh, he's probably reacting to these two quotes: In the end, it turned out that UTF decoding had become the bottleneck and it's soon to be removed. The key one is to remove decoding of UTF and match directly on the encoded chars On second thought should have said it like match directly on encoded characters _as if decoding_ them w/o actually going for decoded code point values. Still confusing I guess. -- Dmitry Olshansky
Re: Stable partition3 implementation
On Saturday, 11 July 2015 at 00:00:47 UTC, Andrei Alexandrescu wrote: On 7/9/15 5:57 PM, Xinok wrote: ... Any thoughts? I'd say both would be nice (not to mention the one in the paper) so how about both are present selectable with a policy ala Yes.tightMemory or something. -- Andrei I'm hesitant to add yet another template parameter; IMHO, it's bad enough that we have to manually write the predicate just to reach the swap strategy. There's a fourth option I didn't think to mention. It's easy to utilize a small buffer which would be used to partition small sublists instead of insertions. partition3 would not allocate it's own memory so would be in-place by default, but the user could provide their own buffer and pass it as an extra function argument. For example: int[] arr = iota(0, 10).array; int[] buf = new int[100]; partition3!(...)(arr, 1000, buf); Interestingly, for some constant k, if you implement this algorithm to use O(n/k) space, then it runs in O(n lg n) time because it performs at most O(lg k) rotations. Regarding the algorithm in the paper, I don't have it completely figured out yet because it refers to algorithms in other papers which I can't find.
Re: Initial feedback for std.experimental.image
On Sat, 11 Jul 2015 00:49:25 +, Meta wrote: i'm using `setPixel` to change pixel unconditionally (think of it as set rgb), and `putPixel` to blend pixel (think of it as do rgba color mix). Wouldn't that better be called blendPixel? as Tofu said, `blendPixel` should then be parameterized with blending mode. and for `putPixel` i know blending mode, as it is fixed. anyway, that was only a suggestion and (poor) reasoning for it, i'm not insisting on that scheme. signature.asc Description: PGP signature
Re: Extend D's switch statement?
On Friday, 10 July 2015 at 22:58:44 UTC, Timon Gehr wrote: We don't want the /broken/ thing, which I cited, to make it into the language specification. Ok, I misunderstood. What's broken, if the temporaries are created (and elided following some compiler analysis)?
Re: Initial feedback for std.experimental.image
On Sat, 11 Jul 2015 01:51:41 +, Vladimir Panteleev wrote: giving that `int` and `uint` are freely interchangeable... `uint` is better, as it allows only one bound check in `if`, and without casts. ;-) That's a poor reason. Optimizing x=0 x100 to an unsigned check is such a basic optimization, even DMD can do it. but `if (x 100)` is less typing than `if (x = 0 x 100)`! signature.asc Description: PGP signature
Re: std.concurrency: The fate of unmatched messages
On Fri, 10 Jul 2015 19:39:24 +, E.S. Quinn wrote:
the documentation i can find for std.concurrency mentions what happens
when one receive() call gets a message it doesn't understand.
that `receive()` will not get such a message. `receive()` scans the whole
mailbox to find the message it can process, and process only that,
leaving other messages in mailbox.
And if the latter, is there any way to actually give a single thread
multiple mailboxes?
why do you want that? you can receive any message with `receive`, see the
documentation[1]:
If a delegate that accepts a std.variant.Variant is included as the last
argument to receive, it will match any message that was not matched by an
earlier delegate. If more than one argument is sent, the Variant will
contain a std.typecons.Tuple of all values sent.
receive(
(int i) { writeln(Received an int.); },
(float f) { writeln(Received a float.); },
(Variant v) { writeln(Received some other type.); }
);
this way your `receive` will get all messages. simply do nothing in
`Variant` handler to drop messages you don't want to process.
[1] http://dlang.org/phobos/std_concurrency.html#.receive
signature.asc
Description: PGP signature
Re: std.concurrency: The fate of unmatched messages
On Sat, 11 Jul 2015 01:52:23 +, E.S. Quinn wrote: On Friday, 10 July 2015 at 23:39:30 UTC, ketmar wrote: this way your `receive` will get all messages. simply do nothing in `Variant` handler to drop messages you don't want to process. [1] http://dlang.org/phobos/std_concurrency.html#.receive The thing is, I want to do receive() in two separate places, and I want each receive() call to leave the other's messages alone, not drop them. so simply don't receive the messages you don't need right now. as i said, `receive()` doesn't look to top message only, it scans the whole mailbox, trying to find a message that matches. you can use `receiveTimeout()` to do nothing if there are no suitable messages. you can also adjust mailbox size and mode. signature.asc Description: PGP signature
Re: std.concurrency: The fate of unmatched messages
On Friday, 10 July 2015 at 23:39:30 UTC, ketmar wrote: this way your `receive` will get all messages. simply do nothing in `Variant` handler to drop messages you don't want to process. [1] http://dlang.org/phobos/std_concurrency.html#.receive The thing is, I want to do receive() in two separate places, and I want each receive() call to leave the other's messages alone, not drop them.
Re: Great Rust tutorial that D could really benefit from.
On Friday, 10 July 2015 at 19:43:06 UTC, Marcin Szymczak wrote:
Hello dear D community.
While browsing reddit i stumbled upon a very nice tutorial for
Rust programming language
(http://nbaksalyar.github.io/2015/07/10/writing-chat-in-rust.html). I have to admit that it is very good, providing the reader with a real-life example of language usage, explains the ideology and proper style of programming in said language and most of all, teaches how to write good idiomatic code.
I think that D community could really benefit from creating
something similar, a real-life project tutorial, which is able
to show off great D capabilities, introduce to idiomatic and
proper way of coding and spread the word to the greater
audience.
It looks well done. Us D beginners could definitely benefit from
more tutorials like this illustrating some of the cooler things
you can do. There were a number of things I don't think I really
understood until I started looking at the code in std.range and
std.algorithm.
One cool thing you can do in Rust is return an rvalue from a { }
scope. The only problem is then things start getting a little
confusing about when to use a semi-colon or not (I'd prefer just
re-using return).
Re: Initial feedback for std.experimental.image
On Saturday, 11 July 2015 at 00:49:27 UTC, Meta wrote: Wouldn't that better be called blendPixel? Also wouldn't a blendPixel need to know the blending scheme, alpha, premultiplied, additive, ect...
Re: Stable partition3 implementation
On 7/10/15 8:55 PM, Xinok wrote: I'm hesitant to add yet another template parameter; IMHO, it's bad enough that we have to manually write the predicate just to reach the swap strategy. Then give them different names. -- Andrei
why adding extern(C) cause a runtime error?
win7 x86 dmd2.067.1 ok
ubuntu x64 dmd2.067.1 error
-
import std.stdio;
import std.socket;
extern(C)
void recv()
{
writeln(recv...);
}
extern(C)
void send()
{
writeln(send...);
}
int main(string[] argv)
{
//copy from std.socket unittest
immutable ubyte[] data = [1, 2, 3, 4];
auto pair = socketPair();
scope(exit) foreach (s; pair) s.close();
pair[0].send(data);
auto buf = new ubyte[data.length];
pair[1].receive(buf);
assert(buf == data);
return 0;
}
--
send...
recv...
core.exception.AssertError@a.d(27): Assertion failure
./a() [0x43d61f]
./a(_Dmain+0xcc) [0x43d1bc]
./a(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f)
[0x4400fb]
./a(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x44004e]
./a(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()+0x30) [0x4400b4]
./a(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x44004e]
./a(_d_run_main+0x1dc) [0x43ffc8]
./a(main+0x17) [0x43d637]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
[0x7f5fabd8fec5]
Re: Voting for std.experimental.allocator
On 11-Jul-2015 01:51, Andrei Alexandrescu wrote: On 7/10/15 4:29 PM, Alex Parrill wrote: On Friday, 10 July 2015 at 18:32:04 UTC, Andrei Alexandrescu wrote: On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei It leaks. http://forum.dlang.org/post/itmcarskypkuospvf...@forum.dlang.org I see. Could you or someone with Windows expertise create a PR for my branch? -- Andrei This one? :) https://github.com/andralex/phobos/pull/17 -- Dmitry Olshansky
Re: Implement the unum representation in D ?
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote: Hi everyone. John Gustafson Will be presenting a Keynote on Thursday 27th February at 11:00 am The abstract is here: http://openparallel.com/multicore-world-2014/speakers/john-gustafson/ There is also a excellent background paper, (PDF - 64 pages) which can be found here: FYI John Gustafson book is now out: It can be found here: http://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239868/ref=sr_1_1?s=booksie=UTF8qid=1436582956sr=1-1keywords=John+Gustafsonpebp=1436583212284perid=093TDC82KFP9Y4S5PXPY Here is one of the reviewers comments: 9 of 9 people found the following review helpful This book is revolutionary By David Jefferson on April 18, 2015 This book is revolutionary. That is the only way to describe it. I have been a professional computer science researcher for almost 40 years, and only once or twice before have I seen a book that is destined to make such a profound change in the way we think about computation. It is hard to imagine that after 70 years or so of computer arithmetic that there is anything new to say about it, but this book reinvents the subject from the ground up, from the very notion of finite precision numbers to their bit-level representation, through the basic arithmetic operations, the calculation of elementary functions, all the way to the fundamental methods of numerical analysis, including completely new approaches to expression calculation, root finding, and the solution of differential equations. On every page from the beginning to the end of the book there are surprises that just astonished me, making me re-think material that I thought had been settled for decades. The methods described in this book are profoundly different from all previous treatments of numerical methods. Unum arithmetic is an extension of floating point arithmetic, but mathematically much cleaner. It never does rounding, so there is no rounding error. It handles what in floating point arithmetic is called overflow and underflow in a far more natural and correct way that makes them normal rather than exceptional. It also handles exceptional values (NaN, +infinity, -infinity) cleanly and consistently. Those contributions alone would have been a profound contribution. But the book does much more. One of the reasons I think the book is revolutionary is that unum-based numerical methods can effortlessly provide provable bounds on the error in numerical computation, something that is very rare for methods based on floating point calculations. And the bounds are generally as tight as possible (or as tight as you want them), rather than the useless or trivial bounds as often happens with floating point methods or even interval arithmetic methods. Another reason I consider the book revolutionary is that many of the unum-based methods are cleanly parallelizable, even for problems that are normally considered to be unavoidably sequential. This was completely unexpected. A third reason is that in most cases unum arithmetic uses fewer bits, and thus less power, storage, and bandwidth (the most precious resources in today’s computers) than the comparable floating point calculation. It hard to believe that we get this advantage in addition to all of the others, but it is amply demonstrated in the book. Doing efficient unum arithmetic takes more logic (e.g. transistors) than comparable floating point arithmetic does, but as the author points out, transistors are so cheap today that that hardly matters, especially when compared to the other benefits. Some of the broader themes of the book are counterintuitive to people like me advanced conventional training, so that I have to re-think everything I “knew” before. For example, the discussion of just what it means to “solve” an equation numerically is extraordinarily thought provoking. Another example is the author’s extended discussion of how calculus is not the best inspiration for computational numerical methods, even for problems that would seem to absolutely require calculus-based thinking, such as the solution of ordinary differential equations. Not only is the content of the book brilliant, but so is the presentation. The text is so well written, a mix of clarity, precision, and reader friendliness that it is a pure pleasure to read, rather then the dense struggle that mathematical textbooks usually require of the reader. But in addition, almost every page has full color graphics and diagrams that are completely compelling in their ability to clearly communicate the ideas. I cannot think of any technical book I have ever seen that is so beautifully illustrated all the way through. I should add that I read the Kindle edition on an iPad, and for once Amazon did not screw up the presentation of a technical book, at least for this platform. It is beautifully produced, in full color and
Re: LDC for iOS prebuilt binaries
Jack Stouffer j...@jackstouffer.com writes: Does this have any way to call the iOS Obj-C libraries for UI rendering and the like? Or is that a separate project? It is a separate project and is gradually getting pulled into DMD: http://forum.dlang.org/post/mnm1sf$kp8$1...@digitalmars.com For now, you can write UI part in Objective-C and rest as D. From D you could call any of the C-based graphics APIs (e.g. CGContextFillRect) but you'd have to write declarations - or try out Dstep: https://github.com/jacob-carlborg/dstep Another approach is using a framework with D bindings like Allegro5. http://forum.dlang.org/post/m2sicg48ff@comcast.net This looked promising but I have not pursed beyond that post. -- Dan
Re: Import module
On Friday, 10 July 2015 at 00:53:38 UTC, codenstuff wrote:
On Friday, 10 July 2015 at 00:24:44 UTC, anonymous wrote:
On Thursday, 9 July 2015 at 22:05:23 UTC, codenstuff wrote:
I am trying to import module and compile.
The compiler produces message
map/map.d(9): Error: module game_object is in file
'steering/game_object.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
make: *** [main] Error 1
[...]
The path is ${HOME}/d_apps/steering/steering/game_object.d
Compile command is
dmd map/map.d main_visual.d -ofmain_visual -H -gc -unittest
-L-lDgame -L-lDerelictUtil -L-lDerelictGL3 -L-lDerelictSDL2
-L-ldl -I/home/real/d_apps/dgame/source
-I/home/real/d_apps/derelict_util/source
-I/home/real/d_apps/derelict_gl3/source
-I/home/real/d_apps/derelict_sdl2/source
-I/home/real/d_apps/steering
Compiler message is same
The error message doesn't list any of your import paths. So I
still think that the message doesn't belong to that command.
Maybe try reducing things to a smaller, self-contained test case.
Re: DUB Build Linker Library Search Path
On 10/07/2015 11:02 p.m., Nordlöw wrote: On Friday, 10 July 2015 at 09:37:42 UTC, Rikki Cattermole wrote: On 10/07/2015 9:34 p.m., Nordlöw wrote: On Friday, 10 July 2015 at 09:29:49 UTC, Martin Nowak wrote: On Friday, 10 July 2015 at 09:27:19 UTC, Nordlöw wrote: How do I tell `dub build` where to find libraries in non-standard directories? You're missing the development package libclang-dev, which should come with a pkg-config. I've already installed libclang-dev. The problem is that I can't find a way (from the command line) (by reading the DUB docs) to tell DUB that it's placed in /usr/lib/llvm-3.6/lib/libclang.so.1 I don't what to have to modify the dub.json (lflags variable) as I want automation. Aren't all DUB the variables somehow modifiable in shell call?! Further `pkg-config --list-all |grep clang` shows nothing. LFLAGS=... dub build LDFLAGS=-L/usr/lib/llvm-3.6/lib dub build --compiler=/usr/bin/dmd -v has not effect: /usr/bin/dmd -of.dub/build/default-debug-linux.posix-x86_64-dmd_2067-0E9173B3A2F733029144DC3F174B9E99/dstep -debug -g -version=Have_dstep -version=Have_dstack -version=Have_mambo -version=Have_tango -Idstep -Iclang -I../../.dub/packages/dstack-0.0.3 -I../../.dub/packages/mambo-0.0.4 -I../../.dub/packages/tango-1.0.1_2.067 -Jresources clang/Compiler.d clang/Cursor.d clang/Diagnostic.d clang/File.d clang/Index.d clang/SourceLocation.d clang/TranslationUnit.d clang/Type.d clang/Util.d clang/Visitor.d clang/c/CXErrorCode.d clang/c/CXString.d clang/c/Index.d dstep/config/Configuration.d dstep/core/Exceptions.d dstep/driver/Application.d dstep/driver/DStep.d dstep/translator/Declaration.d dstep/translator/Enum.d dstep/translator/IncludeHandler.d dstep/translator/Output.d dstep/translator/Record.d dstep/translator/Translator.d dstep/translator/Type.d dstep/translator/objc/Category.d dstep/translator/objc/ObjcInterface.d ../../.dub/packages/dstack-0.0.3/libdstack.a ../../.dub/packages/mambo-0.0.4/libmambo.a ../../.dub/packages/tango-1.0.1_2.067/libtango.a -L-lclang -L-rpath -L. -L-L. -L-lbz2 -vcolumns ../../.dub/packages/mambo-0.0.4/mambo/util/Traits.d(154,39): Deprecation: typedef is removed ../../.dub/packages/mambo-0.0.4/mambo/util/Traits.d(182,30): Deprecation: typedef is removed /usr/bin/ld: error: cannot find -lclang Using export as export LDFLAGS=-L/usr/lib/llvm-3.6/lib; dub build --compiler=/usr/bin/dmd doesn't work either. Adding -L-L/usr/lib/llvm3-6/lib to the call to dmd works. What's wrong with my call to DUB? I'm sitting on DUB git master. No no, LFLAGS not LDFLAGS. It's basically lflags from dub file but in environment args.
Re: DUB Build Linker Library Search Path
On Friday, 10 July 2015 at 11:21:34 UTC, Rikki Cattermole wrote: No no, LFLAGS not LDFLAGS. It's basically lflags from dub file but in environment args. No, doesn't work: LFLAGS=-L-L/usr/lib/llvm-3.6/lib dub build --compiler=/usr/bin/dmd fails aswell: Target tango 1.0.1+2.067 is up to date. Use --force to rebuild. Target mambo 0.0.4 is up to date. Use --force to rebuild. Target dstack 0.0.3 is up to date. Use --force to rebuild. Building dstep ~master configuration default, build type debug. Running /usr/bin/dmd... ../../.dub/packages/mambo-0.0.4/mambo/util/Traits.d(154,39): Deprecation: typedef is removed ../../.dub/packages/mambo-0.0.4/mambo/util/Traits.d(182,30): Deprecation: typedef is removed /usr/bin/ld: error: cannot find -lclang
Is it legal to have a function taking two aliased slices?
Example:
void process(float[] input, float[] output)
{
// do stuff
}
I'd like to sometimes have overlapping slices, and don't want the
compiler to assume they do not overlap.
LDC for iOS prebuilt binaries
On Thursday, 9 July 2015 at 06:32:28 UTC, Dan Olson wrote: Only 32-bit devices currently; arm64 work starts next month when I acquire an iPhone 6. The download should have everything needed to run on an OS X build host in the same fashion as LDC downloads. Great work. D will get a huge boost in popularity if it can work on mobile devices. Does this have any way to call the iOS Obj-C libraries for UI rendering and the like? Or is that a separate project?
Re: Extend D's switch statement?
On 07/09/2015 12:26 AM, Dmitry Olshansky wrote: In the worst case just if-else chain collided items per hash value? Given that in this case it may use the full range of size_t I won't expect high collision rates. There is a readymade tool (gperf) to generate code for perfect hash switches. http://linux.die.net/man/1/gperf
Re: Is it legal to have a function taking two aliased slices?
On Friday, 10 July 2015 at 13:54:47 UTC, Steven Schveighoffer
wrote:
On 7/10/15 9:20 AM, ponce wrote:
Example:
void process(float[] input, float[] output)
{
// do stuff
}
I'd like to sometimes have overlapping slices, and don't want
the
compiler to assume they do not overlap.
Yes, it's legal, and the compiler doesn't assume anything about
the two slices, including whether they overlap or not.
-Steve
Cool, thanks!
Re: Is it legal to have a function taking two aliased slices?
On 7/10/15 9:20 AM, ponce wrote:
Example:
void process(float[] input, float[] output)
{
// do stuff
}
I'd like to sometimes have overlapping slices, and don't want the
compiler to assume they do not overlap.
Yes, it's legal, and the compiler doesn't assume anything about the two
slices, including whether they overlap or not.
-Steve
Re: Extend D's switch statement?
On 10-Jul-2015 16:43, Martin Nowak wrote: On 07/09/2015 12:26 AM, Dmitry Olshansky wrote: In the worst case just if-else chain collided items per hash value? Given that in this case it may use the full range of size_t I won't expect high collision rates. There is a readymade tool (gperf) to generate code for perfect hash switches. http://linux.die.net/man/1/gperf Does it work for any UDTs? I guess strings only. -- Dmitry Olshansky
Re: Voting for std.experimental.allocator
On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei
Re: goroutines vs vibe.d tasks
Am 01.07.2015 um 20:09 schrieb Mathias Lang:
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks.
Compilers
go: go version go1.4.2 linux/amd64
vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23
Code
go: http://pastebin.com/2zBnGBpt
vibe.d: http://pastebin.com/JkpwSe47
go version build with go build test.go
vibe.d version built with dub build --build=release test.d
Results on my machine:
go: 168.736462ms (overhead ~ 68ms)
vibe.d: 1944ms (overhead ~ 1844ms)
Why creating of vibe.d tasks is so slow (more then 10 times)???
In your dub.json, can you use the following:
subConfigurations: {
vibe-d: libasync
},
dependencies: {
vibe-d: ~0.7.24-beta.3
},
Turns out it makes it much faster on my machine (371ms vs 1474ms). I
guess it could be a good thing to investigate if we can make it the
default in 0.7.25.
This sounds like the event_del() + event_add() sequence that is done in
the libevent driver causes this slowdown. If anyone knows of a faster
way to rearm a timer for libevent that would be great. Otherwise I don't
really know what to do about this (other than using a different driver).
As for libasync, making it the default is maybe still a little too
early, but we should definitely think about how to make it more
prominent for testing (maybe even still for 0.7.24).
Last - but not least! - two DConf talks
Spread the word! https://www.youtube.com/watch?v=bxSPCmwqgYs https://www.youtube.com/watch?v=jNQF3m5e2l0 Andrei
Re: goroutines vs vibe.d tasks
Am 01.07.2015 um 09:55 schrieb Daniel Kozák: On Wed, 01 Jul 2015 03:28:01 + rsw0x anonym...@anonymous.com wrote: how do they compare if you replace the sleep with yield? Same problem still extreamly slow Hm, this is strange. I'll have to find some time to profile this. More or less all that yield() does is to call Fiber.yield() and then once processes pending events.
Scriptlike v0.9.2
Minor update, Scriptlike v0.9.2: https://github.com/Abscissa/scriptlike - Fixed: Properly flush all command echoing output (ie, in yap and yapFunc). - Enhancement: Add a no-build configuration for projects that need to import/depend on Scriptlike through DUB, but use their own buildsystem.
Re: clayers - Update 1.1.0
On Tuesday, 7 July 2015 at 19:09:05 UTC, Wyatt wrote:
Hey! I appreciate the feedback you've given!
Thoughts/ideas/suggestions:
* I think everyone working on this problem ends up making
coordinate types. ~_~;; I definitely recommend defining XCoord
and YCoord as separate types so a common inversion bug is
prevented-- that's saved me a number of times. In my
experience, a straight alias was vexingly insufficient so I use
a struct (though it's still not where I want it).
I don't really understand what you mean by this point, could you
elaborate?
The reason to why I have my own XY struct is mainly because I
often felt like I needed two varaibles, so simply making one felt
like an good idea.
* Make a no-args init that detects terminal dimensions. It's
just nicer that way.
Yes, I totally agree. Before I even released v1.0.0 this was how
the program functioned... until I tested it on OS X. For some
reason, there standard way on POSIX didn't work on OS X (see
https://github.com/vladdeSV/clayers/issues/2). And while I would
want an auto-size to be, it could be hard for developers to make
a game where the window size is relative. (Come to think of it,
it might actually not be.)
But yeah, the dimensions should be auto-set!
* I like the two-corner constructor for ConsoleLayer. I can't
remember why I didn't go that route myself. It may have been
that I was just trying to make it work instead of make it
nice, but there could be something more. I forget.
If I understood you correctly, you are wrong :P. If you mean I
set location (5,0) and size(10,10), it doesn't create a layer
with those two as corners, rather the size adds to the location,
so the rightmost location is at (15, 0 .. 10). A two point corner
system would be very nice though, and it might happen in the
future.
* Relative (percentage-based) dimensions seem like they could
be really handy, but I've never figured out how to make them
feel good. Maybe you can do better.
I've never really tried with relative dimensions, just a hard set
that main window goes to 50, and sidebar starts at 50. If you
would like to expand on feel good that'd be very much
appreciated. (I know my self that the feel often can't be
explained, so no worries if you don't :) )
* Simplify bordered windows. I feel pretty strongly that that
should be abstracted into the ConsoleLayer, honestly. If not
as part of the constructor, then as a property you can set.
Default to nothing and allow setting it to a character (#) or
to a manifest constant that tells it to use unicode box drawing
characters. (Or maybe the property is an enum BORDER {NONE,
UNICODE, CHAR}, and the character is separate? I don't know.)
Oh my, you don't know how much problems I've had with borders.
Buggy borders have been in the code pre-v1 (introduced here:
https://github.com/vladdeSV/clayers/commit/70a0547288aec8008d033c419ad3c387315c2125 and removed here: https://github.com/vladdeSV/clayers/commit/7249b9ed2a00a59a2867dd79861cf4bdee580f64). I've had many thoughts about borders, and to be honest, I didn't quite get how to make border work properly while at the same time make it user friendly. I had problems with writing to the layers as well, where text would overwrite borders and what not.
And if I made a layer 10x10 with a border, could I then write at
(0,0)? Would that be at the border, or the position inside the
border? And then the width/height? Would it return the whole
width, or the width where you could write. And then, what if
someone wants a border that is two characters wide, how would
that work? At the time I had no idea, and with the code I had
then, I felt it was more worth it to get a working engine rather
than fancy borders.
Generally speaking, they did less good than bad.
However, as you mention below, adding a second layer that is
inside the border would actually work, since my code (currently)
allows layers to have sub-layers (which can have more sub-layers,
which in turn can have... you get the idea. That's why sub-layers
still are a maybe).
* A method to get the current layer order is probably worth
considering. And a way to get the priority index for a layer.
And even relative reordering; e.g. layerA.moveAbove(layerB);
I have also considered getting the layer order, but ,how,
exactly? Would I get an ID of some sort? Would I need to set a
custom ID for each layer? What happens if two layers have the
same ID? Relative layers however seem like a nice thing to have,
and I'm pretty sure I could add that with little to no problems
:).
* There's no way to move or resize a layer? Is the the idea to
just destroy and recreate the layer with the new origin/size?
Resize and moving layers are things I've never though about. As
I've developed clayers, I've never once felt the need to move or
resize a layer. It is definitely possible to add these features,
however, things I do not know how to handle, such as if
std.concurrency: The fate of unmatched messages
I'm putting together a program that uses std.concurrency to handle two child threads from the main thread; The kicker here is that both the children do very different things. And I would like to handle receive() calls for them in separate locations. But from what I can tell, each thread has only one mailbox. And none of the documentation i can find for std.concurrency mentions what happens when one receive() call gets a message it doesn't understand. Are unmatched messages left in the Mailbox, or are they discarded? (I am admittedly strongly hoping it is the former) And if the latter, is there any way to actually give a single thread multiple mailboxes?
Great Rust tutorial that D could really benefit from.
Hello dear D community. While browsing reddit i stumbled upon a very nice tutorial for Rust programming language (http://nbaksalyar.github.io/2015/07/10/writing-chat-in-rust.html). I have to admit that it is very good, providing the reader with a real-life example of language usage, explains the ideology and proper style of programming in said language and most of all, teaches how to write good idiomatic code. I think that D community could really benefit from creating something similar, a real-life project tutorial, which is able to show off great D capabilities, introduce to idiomatic and proper way of coding and spread the word to the greater audience.
[Issue 13650] std.algorithm.copy doesn't work with char/wchar
https://issues.dlang.org/show_bug.cgi?id=13650 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13650] std.algorithm.copy doesn't work with char/wchar
https://issues.dlang.org/show_bug.cgi?id=13650 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/1f0f8ef77267465b503bb7766c7939fd507623fe Fix Issue 13650 - Rebased https://github.com/D-Programming-Language/phobos/commit/5d17edc745e953988a574411a9f351bfb9d525d3 Merge pull request #2799 from Poita/Issue13650 Fix Issue 13650 - Cannot copy (w)char[] into (w)char[] --
New ldc2-0.15.2-beta2 Linux suitable for Travis-CI
Hi all! I re-created the Linux binaries. They should now work in Travis-CI again. 2457af89b39d89a237d9bda560c8b5a8 ldc2-0.15.2-beta2-linux-x86.tar.gz b5f1514d52082ac5e6220c23287f799b ldc2-0.15.2-beta2-linux-x86.tar.xz 642ad38c7bf25d8d932e7a00e46c9734 ldc2-0.15.2-beta2-linux-x86_64.tar.gz 18e4d0aec88ebbc58365bdc67b15cc7c ldc2-0.15.2-beta2-linux-x86_64.tar.xz (I did not test this with Travis-CI but I checked that I really statically linked libstdc++.) Regards, Kai
Re: DUB 0.9.24 beta 2
For anyone using Sublime Text, I've created a simple syntax highlighting module: https://packagecontrol.io/packages/SDLang For other editors, any C language family syntax highlighting also works pretty well as far as DUB's use of SDL is concerned.
Re: Extend D's switch statement?
On Friday, 10 July 2015 at 09:07:21 UTC, Marc Schütz wrote:
On Thursday, 9 July 2015 at 22:50:37 UTC, Vlad Levenfeld wrote:
On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:
On 07/09/2015 04:17 PM, Timon Gehr wrote:
On 07/09/2015 02:54 PM, rsw0x wrote:
...
someone was willing to produce.
Someone is often willing to produce awkward language quirks,
so I think
being critical of new additions has some value.
E.g.
Note: Cannot swap values by tuple assignment.
int x = 1, y = 2;
{x, y} = {y, x};
// Lowered to:
// x = y, y = x;
assert(y == 2);
assert(x == 2);
No, please.
Couldn't this could be detected at compile-time and temporary
variables created?
Yes, but there needs to be a complete aliasing analysis, e.g.
int* x, y;
// ...
{*x, *y} = {*y, *x};
It's probably safer to create the temporaries by default and
elide them when the elements are provably non-aliasing.
Yeah true. I really wish we had this. I've got .tuple and
TypeTuple and .expand proliferating throughout the code I write,
and I've got a bunch of helper functions for converting between
them it would be really awesome to get rid of that and unify
everything with this DIP32.
Re: LDC for iOS prebuilt binaries
On Friday, 10 July 2015 at 20:38:16 UTC, Rishub Nagpal wrote: On Thursday, 9 July 2015 at 06:32:28 UTC, Dan Olson wrote: I've made a set of binaries and universal libs for the LDC iOS cross-compiler. It is based on LDC 0.15.1 (2.066) and LLVM 3.5.1. https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.15.1-150708 Only 32-bit devices currently; arm64 work starts next month when I acquire an iPhone 6. The download should have everything needed to run on an OS X build host in the same fashion as LDC downloads. But I may have missed something. Feedback appreciated. Good Work! I'd like to help get D to work on android, but I do not know much about llvm and arm compilers to be of much help. Last I heard there was an issue with exception handling and TLS, is that still so? That's funny, because I was just thinking about putting my Android patches for ldc online and trying to get more people to chip in on working through the remaining tests to be fixed for Android/ARM. I got TLS working a month and a half ago (http://forum.dlang.org/post/imkgasjuvbbasyghd...@forum.dlang.org) and exception-handling seems to be working since this fix I ferreted out last week (http://forum.dlang.org/post/qsfaussopqwwjuljd...@forum.dlang.org). Now it's just codegen issues, with about half of phobos modules' tests failing somewhere, though many of those modules only have a handful of tests that fail. For example, only three unit test blocks fail in std.stdio and one in std.path. Common causes appear to be problems with ranges and functions from std.random. I'm going through each module and commenting out failing tests and checking backtraces, a time-consuming process that's got me thinking about hacking the test runner, so that failing tests in one unit test block won't stop other test blocks from the same module from running, as is the case now. If you or anybody else is interested in chipping in, reply in the Android thread (first link above) and I'll put some patches and build info online. Unfortunately, to really fix any of these issues, you'll probably have to know something about ARM assembly, LLVM IR, and be comfortable stepping through the binary with gdb but without debug info, although simply triaging the tests to figure out what works and what doesn't could probably be done by almost anyone.
Re: Stable partition3 implementation
On 07/09/2015 11:57 PM, Xinok wrote: I found this paper which describes an in-place algorithm with O(n) time complexity but it's over my head at the moment. http://link.springer.com/article/10.1007%2FBF01994842 It is trivial to implement an algorithm with O(n) time complexity and O(n) space complexity, but that requires allocating memory. Furthermore, using a buffer requires the range to have assignable elements. Any thoughts? I think this method is likely to be less practically relevant than the one they improve upon. (log* n really is constant for all practical purposes, it is the number of times one needs to iteratively take the logarithm until a number below 1 is obtained.) That paper appears to be available here: https://github.com/lispc/lispc.github.com/raw/master/assets/files/situ.pdf No idea what the constant is though, I have not read the paper (yet).
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On Friday, 10 July 2015 at 20:42:02 UTC, Dmitry Olshansky wrote: On 10-Jul-2015 23:34, Joakim wrote: On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/ Answered. Never knew it was there at all. Oh, he's probably reacting to these two quotes: In the end, it turned out that UTF decoding had become the bottleneck and it's soon to be removed. The key one is to remove decoding of UTF and match directly on the encoded chars
Re: Great Rust tutorial that D could really benefit from.
On Friday, 10 July 2015 at 19:43:06 UTC, Marcin Szymczak wrote: Hello dear D community. While browsing reddit i stumbled upon a very nice tutorial for Rust programming language (http://nbaksalyar.github.io/2015/07/10/writing-chat-in-rust.html). I have to admit that it is very good, providing the reader with a real-life example of language usage, explains the ideology and proper style of programming in said language and most of all, teaches how to write good idiomatic code. I think that D community could really benefit from creating something similar, a real-life project tutorial, which is able to show off great D capabilities, introduce to idiomatic and proper way of coding and spread the word to the greater audience. Bearophile, I feel like you could do a weekly TWiD series, breaking down one of your numerous Rosetta Code entries every week.
Re: incorrect data when returning static array in place of dynamic
On Monday, 6 July 2015 at 10:20:28 UTC, anonymous wrote:
On Monday, 6 July 2015 at 07:48:17 UTC, sigod wrote:
Aren't compiler smart enough to prevent it?
```
ubyte[] test1()
{
auto b = sha1Of();
return b; // Error: escaping reference to local b
}
ubyte[] test2()
{
return sha1Of(); // works, but returns incorrect data
}
```
Looks more like a bug to me.
dmd 2.068.0 catches this. You can get the beta here:
http://downloads.dlang.org/pre-releases/2.x/2.068.0/
That's good to know.
Re: Extend D's switch statement?
On 07/10/2015 12:50 AM, Vlad Levenfeld wrote:
On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:
On 07/09/2015 04:17 PM, Timon Gehr wrote:
On 07/09/2015 02:54 PM, rsw0x wrote:
...
someone was willing to produce.
Someone is often willing to produce awkward language quirks, so I think
being critical of new additions has some value.
E.g.
Note: Cannot swap values by tuple assignment.
int x = 1, y = 2;
{x, y} = {y, x};
// Lowered to:
// x = y, y = x;
assert(y == 2);
assert(x == 2);
No, please.
Couldn't this could be detected at compile-time and temporary variables
created?
Oh, it certainly is simple to fix, it's just that we don't want this
sort of thing to make it into the language specification.
Re: incorrect data when returning static array in place of dynamic
On Monday, 6 July 2015 at 14:56:38 UTC, Marc Schütz wrote: On Monday, 6 July 2015 at 10:20:28 UTC, anonymous wrote: dmd 2.068.0 catches this. You can get the beta here: http://downloads.dlang.org/pre-releases/2.x/2.068.0/ ... and it already contains a std.digest.hmac module :-) Yes, thanks. I know that. But I don't really want to use pre-release version on server.
Re: Voting for std.experimental.allocator
On Friday, 10 July 2015 at 18:32:04 UTC, Andrei Alexandrescu wrote: On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei It leaks. http://forum.dlang.org/post/itmcarskypkuospvf...@forum.dlang.org
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/
Re: LDC for iOS prebuilt binaries
On Thursday, 9 July 2015 at 06:32:28 UTC, Dan Olson wrote: I've made a set of binaries and universal libs for the LDC iOS cross-compiler. It is based on LDC 0.15.1 (2.066) and LLVM 3.5.1. https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.15.1-150708 Only 32-bit devices currently; arm64 work starts next month when I acquire an iPhone 6. The download should have everything needed to run on an OS X build host in the same fashion as LDC downloads. But I may have missed something. Feedback appreciated. Good Work! I'd like to help get D to work on android, but I do not know much about llvm and arm compilers to be of much help. Last I heard there was an issue with exception handling and TLS, is that still so? anyway, good job!
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On 10-Jul-2015 23:34, Joakim wrote: On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/ Answered. Never knew it was there at all. -- Dmitry Olshansky
Re: Stable partition3 implementation
On 07/10/2015 03:48 AM, Nick B wrote: On Friday, 10 July 2015 at 00:39:16 UTC, Xinok wrote: On Thursday, 9 July 2015 at 21:57:39 UTC, Xinok wrote: I found this paper which describes an in-place algorithm with O(n) time complexity but it's over my head at the moment. ... stable 0-1 sorting is possible in O(n) time and O(1) extra space. Note how /they/ don't mention complexity. This is because algorithms don't have complexities. Problems do. (Sorry, pet peeve of mine.)
Re: bigint compile time errors
On Tuesday, 7 July 2015 at 22:19:22 UTC, Paul D Anderson wrote: On Sunday, 5 July 2015 at 20:35:03 UTC, Kai Nacke wrote: On Friday, 3 July 2015 at 04:08:32 UTC, Paul D Anderson wrote: On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote: On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote: [...] Should be plusTwo(in BigInt n) instead. Yes, I had aliased BigInt to bigint. And I checked and it compiles for me too with Windows m64. That makes it seem more like a bug than a feature. I'll open a bug report. Paul The point here is that x86 uses an assembler-optimized implementation (std.internal.math.biguintx86) and every other cpu architecture (including x64) uses a D version (std.internal.math.biguintnoasm). Because of the inline assembler, the x86 version is not CTFE-enabled. Regards, Kai Could we add a version or some other flag that would allow the use of .biguintnoasm with the x86? Paul biguintx86 could import biguintnoasm. Every function would need to check for CTFE and if yes then call the noasm function. Should work but requires some effort. Regards, Kai
