Re: ddox documentation generator
Am 10/7/2012 11:33 PM, schrieb Nick Sabalausky: Server overloaded? Trying to connect to 'vibed.org' just hangs (without actually timing out, at least not yet). Yeah.. it always has to happen when something gets announced and at night (running for months without any problem). The proxy process hung, only reacting to KILL.
Re: ddox documentation generator
Am 10/8/2012 9:29 AM, schrieb Sönke Ludwig: Am 10/7/2012 11:33 PM, schrieb Nick Sabalausky: Server overloaded? Trying to connect to 'vibed.org' just hangs (without actually timing out, at least not yet). Yeah.. it always has to happen when something gets announced and at night (running for months without any problem). The proxy process hung, only reacting to KILL. Btw. I have some serious memory consumption problems during compilation and swap was not enabled on the server. I noticed that somtimes processes got killed while the compiler was run. I hope this was the reason for the hanging process as well - at least I recompiled several times around the time when this happened.
Re: Remus
On Sunday, 7 October 2012 at 20:54:28 UTC, Tove wrote: On Sunday, 7 October 2012 at 19:41:30 UTC, Jacob Carlborg wrote: On 2012-10-07 19:32, Namespace wrote: amazing, good work...! what license is this under, is it allowed to be used commercially? LGPL or zlib (but then with copyleft as addtion), isn't clear right now.
Re: ddox documentation generator
Am 10/8/2012 9:29 AM, schrieb Sönke Ludwig: Am 10/7/2012 11:33 PM, schrieb Nick Sabalausky: Server overloaded? Trying to connect to 'vibed.org' just hangs (without actually timing out, at least not yet). Yeah.. it always has to happen when something gets announced and at night (running for months without any problem). The proxy process hung, only reacting to KILL. It turned out that this was due to a workaround I made to get std.zlib.UnCompress work reliably (well, not quite, obviously). http://d.puremagic.com/issues/show_bug.cgi?id=8779
Re: SQL working [ was Re: The sorry state of the D stack? ]
On 2012-10-07 21:53, denizzzka wrote: So, I do not know is it possible to make a universal interface. And why it may need in real life? ActiveRecord provides a universal interface for all databases. But you can't do all things with a fancy DSL. Sometimes you need to drop down to raw SQL if you want to execute some weird SQL function or similar. -- /Jacob Carlborg
Re: Preliminary submission - std.rational and std.typelist
On 2012-44-08 06:10, Arlen arlen...@gmx.com wrote: On Sat, Oct 6, 2012 at 1:32 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: Cool, does it work with BigInt? No it doesn't work with BigInt, but I did look into it today briefly. There are issues with BigInt that I'm not sure what to do about: 1. To convert a BigInt to floating-point one needs to convert it to the built-in integer types first. If you go beyond the limits of the built-in types (long), then what's the point? You might as well be using int or long. I thought (part of) the point of Rational was to use it when it would be more fitting than floating-point. If it's only there to be converted to floating-point, I don't know what it's there for. As for a workaround, right-shift num and den to reasonable values (which fit in a long), divide to get a float, and multiply by 2.0^^(log2(num)-log2(den)). Oughta work. 2. The functions in std.math don't support BigInt, and most likely never will. Even if they did, you would still need multi-precision floating point to store the irrational numbers. If you decided to use the built-in types, then again what's the point? You might as well go with int or long. The only function you use from std.math is abs, right? That should be fairly easy to implement for BigInt. It'd mean you'd have to specialize a bit for BigInt, though (just create your own abs function that calls the correct one). Another option: lobby for BigInt support in std.math. :p Also, irrational numbers? How'd you get those in a *Rational* library? :p -- Simen
Re: SQL working [ was Re: The sorry state of the D stack? ]
On 2012-10-07 18:54, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? I think that a uniform database interface with support for different database drivers, a DSL, an ORM wrapper and a couple of database drivers would be too much to have in Phobos. -- /Jacob Carlborg
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote: On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough) There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC) So, I do not know is it possible to make a universal interface. And why it may need in real life? At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo
Re: Preliminary submission - std.rational and std.typelist
On Mon, Oct 08, 2012 at 09:08:57AM +0200, Simen Kjaeraas wrote: On 2012-44-08 06:10, Arlen arlen...@gmx.com wrote: On Sat, Oct 6, 2012 at 1:32 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: Cool, does it work with BigInt? No it doesn't work with BigInt, but I did look into it today briefly. There are issues with BigInt that I'm not sure what to do about: 1. To convert a BigInt to floating-point one needs to convert it to the built-in integer types first. If you go beyond the limits of the built-in types (long), then what's the point? You might as well be using int or long. I thought (part of) the point of Rational was to use it when it would be more fitting than floating-point. If it's only there to be converted to floating-point, I don't know what it's there for. I'd like to chime in to state that I'd love to have Rational support BigInt. If necessary, use an arbitrary-width floating point format for floating point conversions (BigFloat?). [...] It'd mean you'd have to specialize a bit for BigInt, though (just create your own abs function that calls the correct one). Another option: lobby for BigInt support in std.math. :p +1. Also, irrational numbers? How'd you get those in a *Rational* library? :p [...] Ironically enough, if Rational supports BigInt, then it makes it possible to implement a representation of quadratic irrationals in a straightforward way (by storing them in the form a+b*sqrt(r) where a and b are Rationals and r is a square-free Rational). The reason BigInt is necessary is that while these things are closed under field operations, any non-trivial work with them tends to overflow built-in integer types very quickly. BigInt becomes even more necessary if you want to represent quadratic irrationals of *two* distinct square roots, which can be represented as a+b*sqrt(r)+c*sqrt(s)+d*sqrt(rs), where a,b,c,d are Rationals and r,s are square-free Rationals. Believe it or not, these little monsters are also closed under field operations. But they also overflow built-in integers *very* fast. With BigInt support, however, you can do *exact* arithmetic with these irrational numbers, something very useful for applications in computational geometry, where the lack of exact arithmetic makes many problems intractible or prone to wrong results. T -- I'm still trying to find a pun for punishment...
Re: Preliminary submission - std.rational and std.typelist
On Sun, Oct 07, 2012 at 01:15:50PM +0400, Dmitry Olshansky wrote:
[...]
Just define method with this signature:
void toString(scope void delegate(const(char)[]) sink)
And bingo! It's used in all of formatting stuff like write(f)(ln),
format, formattedWrite etc.
e.g. before posting I played with this:
import std.stdio, std.format;
struct A{
int k;
void toString(scope void delegate(const(char)[]) sink)
{
formattedWrite(sink, [%d], k);
}
}
void main(){
A a = A(90);
writeln(a);
}
[...]
+1. This is much more powerful and useful, not to mention more efficient
in many cases (by avoiding the need to create multiple string buffers),
than the current toString(). I like this.
T
--
We are in class, we are supposed to be learning, we have a teacher... Is
it too much that I expect him to teach me??? -- RL
Re: Feature request: extending comma operator's functionality
On 05/10/12 18:58, H. S. Teoh wrote:
On Fri, Oct 05, 2012 at 05:23:40PM +0200, Don Clugston wrote:
[...]
My feeling is that do{}while() is a fairly useless concept, and
this is part of the reason.
In my experience genuine do-while loops are extremely rare, and it
only takes a slight change to the loop to force a different
structure to be used.
Conditional loops which don't follow the while(){...} pattern
normally follow the loop-and-a-half pattern, also known as
begin-while-repeat (I think that's the name Knuth used). I'll call
it 'super do':
super do {
foo();
while(cond);
bar();
}
which in D is better modelled by:
for (;;)
{
foo();
if (!cond) break;
bar();
}
This isn't super do, it's just loop, the way nature intended. ;-)
I've always been an advocate of this construct:
loop {
// initial part of loop body
} while(cond) { // exit point
// trailing part of loop body
}
Looks OK, except that the scopes look wrong. I would hope than a
variable declared in the initial part of the body is also visible in the
trailing part. The {} don't work properly.
Regardless of the syntax, I think it is _the_ fundamental loop
construct, and I've always found it odd that most languages don't
include it. I first found encountered it in Forth, and have missed it
ever since.
To some extent, D (and C/C++)'s for-loops exhibit a similar structure:
for (X; Y; Z) {}
The trailing part of the loop body corresponds with Z; the condition
corresponds with Y.
Yes. C got 'for' loops right.
To avoid the introduction of a new keyword, we may fuse the do-loop and
the while-loop together:
do {
...
} while (cond) {
...
}
The current do-loop is simply a special case of this construct where the
second {...} is replaced with a ;, and the while-loop is a special case
of this construct where the initial part of the loop is elided.
I argue that this generalized construct is much more useful than the
do-loop or while-loop individually, plus it doesn't break any existing
code.
I agree that it's more useful. But that code was legal until a couple of
releases ago, because a trailing ; was not required on do-while loops.
do { xxx; } while(cond) { yyy; }
means:
do {
xxx;
}
while(cond);
yyy;
Even without that, it puts a huge significance on that semicolon. So I
don't think that works. How about:
do { ... do while (cond); ... }
?
This is technically already legal too, although 'do while(cond);' is
currently either a no-op, or an infinite loop.
Re: object states
On Sunday, 7 October 2012 at 20:46:09 UTC, Henning Pohl wrote:
On Sunday, 7 October 2012 at 20:18:15 UTC, Ali Çehreli wrote:
Sounds good.
Thanks.
You haven't mentioned the invariant keyword, so perhaps you
are not aware of that feature?
http://dlang.org/class.html#Invariant
http://dlang.org/dbc.html
Although the docs seem to favor classes, invariant is
available for structs as well.
Ali
How would you resolve the issue I wrote in my first post using
invariants? You cannot add/remove checks from invariants while
using the object. That's what I made different. But there are
still some limits given by the language. Look at point 7 for
instance.
The problem about contract programming in general is you cannot
use it in public library code. Distinction between logic and
user input is a very important thing, we really need to improve
this. You may have noticed that I did not make use of either
assert or enforce. I didn't want to specify this.
You can create a wrapper struct that includes an invariant:
import std.stdio;
struct Image
{
int width;
void doSomething()
{
}
void modifiesWidth()
{
--width;
}
}
void func(Image img)
{
struct ImgWrapper
{
Image* img;
this(ref Image img)
{
this.img = img;
}
invariant()
{
assert(img.width == 512);
}
void opDispatch(string s)()
{
mixin(img.~s~(););
}
}
auto wrapper = ImgWrapper(img);
wrapper.doSomething();
wrapper.modifiesWidth(); // assertion failure
}
void main()
{
Image img = { 512 };
func(img);
}
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 22:08:45 UTC, Nick Sabalausky wrote: Not necessarily: Steve Teale's mysqln is a native D MySQL driver that connects to the DB server directly and bypasses MySQL's official client lib entirely. Teale has inexplicably disappeared off the face of the internet, but Vibe.d has adapted the lib for use with Vibe.d, and this guy has also made some updates: https://github.com/simendsjo/mysqln/tree/misc-cleanups I'm using that with Vibe.d and it seems to be working pretty well. (I'm not sure if the simendsjo version or the Vibe.d version is more up-to-date, though.) The important updates (compile on x64) is incorporated in vibe. The other updates in my repo is just code cleanups, but it's a WIP, and I don't think I'll finish it unless I need to use MySQL+D.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote: On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote: On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough) There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC) So, I do not know is it possible to make a universal interface. And why it may need in real life? At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo For this to work you need to implement an independent way to create queries that would work on all database engines the same way. I believe that this problem is in principle much more complicated than it would have been implemented interfaces to databases in separate libs.
Re: SpanMode uses incorrect terminology (breadth)
On Tuesday, 18 September 2012 at 15:19:08 UTC, Andrei Alexandrescu wrote: On 9/18/12 10:25 AM, David Piepgrass wrote: Actually I prefer breadth-first search when searching the file system. When I search an entire volume, inevitably the (depth-first) search gets stuck in a few giant, deep directories like the source code of Mono or some other cave of source code, you know, something 12 directories deep with 100,000 files in it. A breadth-first search would be more likely to find the thing I'm looking for BEFORE going spelunking in these 12-deep caves. Yes, that was my intent too. Andrei I just wanted to point out, BFS is generally a pretty BAD idea for searching a file system. You instead probably want to implement DFS, and then alter it slightly to use iterative deepening instead of doing plain breadth-first search. That way you won't be keeping open a million OS file handles.
Re: object states
On Monday, 8 October 2012 at 08:53:39 UTC, simendsjo wrote:
You can create a wrapper struct that includes an invariant:
import std.stdio;
struct Image
{
int width;
void doSomething()
{
}
void modifiesWidth()
{
--width;
}
}
void func(Image img)
{
struct ImgWrapper
{
Image* img;
this(ref Image img)
{
this.img = img;
}
invariant()
{
assert(img.width == 512);
}
void opDispatch(string s)()
{
mixin(img.~s~(););
}
}
auto wrapper = ImgWrapper(img);
wrapper.doSomething();
wrapper.modifiesWidth(); // assertion failure
}
void main()
{
Image img = { 512 };
func(img);
}
There is a difference between invariants and what I call states.
States clear things up when you actually need to do a runtime
check and when not. Invariants are always checked, because you
don't care about performance in debug mode. A Numberpositive is
positive already and will stay positive while you can access it.
De facto you cannot change a Numberpositive to a negative
number.
Re: RFC: DConf 2013
On 7 October 2012 22:41, mist n...@none.none wrote: On Monday, 1 October 2012 at 16:25:12 UTC, Andrei Alexandrescu wrote: The project is not live, it will be within a few days. In the spirit of having the community actively participate, I'm making this as transparent as it gets. Please comment: http://www.kickstarter.com/projects/dlang/1177501541?token=df96761a Your feedback and suggestions are welcome. Thanks, Andrei How about any special online materials for backers that can't really attend? :) ( Those Europe-to-USA tickets do not tolerate poor students :( ) I could probably give minimal aid to one or two students living round Brighton UK - or the general Sussex/Kent/London area. ;-) Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: DMD 2.060
On Sun, 07 Oct 2012 12:39:59 +0200, Walter Bright newshou...@digitalmars.com wrote: A list of relevant bugzilla entries would be illuminating. There's a regression in 2.060 which affects my project. Was first reported here: http://d.puremagic.com/issues/show_bug.cgi?id=4192 The corresponding fix: http://dsource.org/projects/dmd/changeset/498 -- My D Compiler: http://code.google.com/p/dil
Windows DLLs and TLS
I have a bug in one of my programs that I find particularly hard to reduce. I am writing a Windows DLL plugin for the IRC chat client HexChat (aka XChat). Problem is, all TLS variables, regardless of type, appear to be initialized to complete rubbish values. Reading them does not cause an access violation or anything, but the initial values are garbage. I am initializing the runtime using the helpers found in core.sys.windows.dll [1]. I wrote a dummy host application in C mimicking the loading behaviour of HexChat - the TLS variables are initialized correctly in this case, even though the DLL file is exactly the same. What is it that a host application can do to break the TLS of a D plugin it loads? [1] http://pastebin.com/rg9uUQMe
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Monday, 8 October 2012 at 10:26:35 UTC, denizzzka wrote: On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote: On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote: On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough) There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC) So, I do not know is it possible to make a universal interface. And why it may need in real life? At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo For this to work you need to implement an independent way to create queries that would work on all database engines the same way. I believe that this problem is in principle much more complicated than it would have been implemented interfaces to databases in separate libs. Sure. That is why on top of a DB driver layer, usually you have some kind of SQL adaptation layer. On the TCL/C abstraction layer we implemented for a product during the 1999-2001 timeframe, we used standard SQL '92 for all data queries, regardless of hand-written or generated from our TCL ORM. Then there was a translation layer that transformed SQL '92 into DB specific SQL, before giving it to the corresponding driver. The only two parts of the application that had DB specific code were the SQL transformation layer, and the .so/.dll with the DB specific driver. With the added benefit that any DB fully SQL '92 compliant did not need any adaptations in the transformation layer. -- Paulo
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 11:44:28 UTC, Jakob Ovrum wrote: I have a bug in one of my programs that I find particularly hard to reduce. I am writing a Windows DLL plugin for the IRC chat client HexChat (aka XChat). Problem is, all TLS variables, regardless of type, appear to be initialized to complete rubbish values. Reading them does not cause an access violation or anything, but the initial values are garbage. I am initializing the runtime using the helpers found in core.sys.windows.dll [1]. I wrote a dummy host application in C mimicking the loading behaviour of HexChat - the TLS variables are initialized correctly in this case, even though the DLL file is exactly the same. What is it that a host application can do to break the TLS of a D plugin it loads? [1] http://pastebin.com/rg9uUQMe Did you already went through this howto? http://dlang.org/dll.html
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 11:55:24 UTC, Paulo Pinto wrote: On Monday, 8 October 2012 at 11:44:28 UTC, Jakob Ovrum wrote: I have a bug in one of my programs that I find particularly hard to reduce. I am writing a Windows DLL plugin for the IRC chat client HexChat (aka XChat). Problem is, all TLS variables, regardless of type, appear to be initialized to complete rubbish values. Reading them does not cause an access violation or anything, but the initial values are garbage. I am initializing the runtime using the helpers found in core.sys.windows.dll [1]. I wrote a dummy host application in C mimicking the loading behaviour of HexChat - the TLS variables are initialized correctly in this case, even though the DLL file is exactly the same. What is it that a host application can do to break the TLS of a D plugin it loads? [1] http://pastebin.com/rg9uUQMe Did you already went through this howto? http://dlang.org/dll.html Of course. I've written many DLLs before, and again, TLS works in the exact same DLL when a different host program is used, hence why it's so difficult to reduce. Besides, there's nothing relevant in that article.
Re: Running test suites under Windows 7
On Sat, 06 Oct 2012 13:05:32 +0100, Walter Bright newshou...@digitalmars.com wrote: On 10/6/2012 2:25 AM, Paulo Pinto wrote: On the other hand it can lead to such scenarios if the applications are not properly coded to work with file locking mechanisms. Both Optlink and Windows link fail with this :-) (The error code Optlink gets from Windows when it tries to create the EXE file is something along the lines of the EXE file is in use by another application.) It's odd that these fail because many/most virus scanners are written using file system filter drivers which operate in the IO stack, blocking CreateFile/open to scan the file, meaning most user processes don't even notice them (except for a very brief pause on CreateFile/open). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Preliminary submission - std.rational and std.typelist
On Mon, 08 Oct 2012 09:28:37 +0200, H. S. Teoh hst...@quickfur.ath.cx wrote: I'd like to chime in to state that I'd love to have Rational support BigInt. If necessary, use an arbitrary-width floating point format for floating point conversions (BigFloat?). Incidentally, I would very much need a BigFloat class/struct, written in D and independent of any C library. I'm trying to write one myself, but it seems to be rather tricky. Could this be implemented in a short amount of time by someone with more knowledge about this topic? -- My D Compiler: http://code.google.com/p/dil
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 12:00:00 UTC, Jakob Ovrum wrote: On Monday, 8 October 2012 at 11:55:24 UTC, Paulo Pinto wrote: On Monday, 8 October 2012 at 11:44:28 UTC, Jakob Ovrum wrote: I have a bug in one of my programs that I find particularly hard to reduce. I am writing a Windows DLL plugin for the IRC chat client HexChat (aka XChat). Problem is, all TLS variables, regardless of type, appear to be initialized to complete rubbish values. Reading them does not cause an access violation or anything, but the initial values are garbage. I am initializing the runtime using the helpers found in core.sys.windows.dll [1]. I wrote a dummy host application in C mimicking the loading behaviour of HexChat - the TLS variables are initialized correctly in this case, even though the DLL file is exactly the same. What is it that a host application can do to break the TLS of a D plugin it loads? [1] http://pastebin.com/rg9uUQMe Did you already went through this howto? http://dlang.org/dll.html Of course. I've written many DLLs before, and again, TLS works in the exact same DLL when a different host program is used, hence why it's so difficult to reduce. Besides, there's nothing relevant in that article. Sorry, just thought it might be helpful.
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 15:52:12 UTC, Paulo Pinto wrote: Sorry, just thought it might be helpful. No, I'm sorry, I shouldn't have replied in the tone that I did. I truly appreciate the help.
Re: Preliminary submission - std.rational and std.typelist
On Mon, Oct 8, 2012 at 2:08 AM, Simen Kjaeraas simen.kja...@gmail.com wrote: On 2012-44-08 06:10, Arlen arlen...@gmx.com wrote: 1. To convert a BigInt to floating-point one needs to convert it to the built-in integer types first. If you go beyond the limits of the built-in types (long), then what's the point? You might as well be using int or long. I thought (part of) the point of Rational was to use it when it would be more fitting than floating-point. If it's only there to be converted to floating-point, I don't know what it's there for. Some computations with rational numbers produce irrational numbers, and to store irrational numbers you need real numbers. What do we do in those cases? As for a workaround, right-shift num and den to reasonable values (which fit in a long), divide to get a float, and multiply by 2.0^^(log2(num)-log2(den)). Oughta work. 2. The functions in std.math don't support BigInt, and most likely never will. Even if they did, you would still need multi-precision floating point to store the irrational numbers. If you decided to use the built-in types, then again what's the point? You might as well go with int or long. The only function you use from std.math is abs, right? That should be fairly easy to implement for BigInt. It'd mean you'd have to specialize a bit for BigInt, though (just create your own abs function that calls the correct one). Yes, std.math.abs and std.numeric.gcd are very easy to implement for BigInt, but I'm not talking about those. I'm talking about things like std.math.pow(), and std.math.log().
Re: SQL working [ was Re: The sorry state of the D stack? ]
I've been thinking about writing an interface inspired by ActiveRecord. It would probably be relatively simple and lightweight, but it should be enough for simple REST applications, and the interface would (hopefully) be extremely nice to use. Of course, with all the other projects I want to do, I'm not sure how long this will live :).
What is the case against a struct post-blit default constructor?
So this has been brought up many times
(http://www.digitalmars.com/d/archives/digitalmars/D/Struct_no-arg_constructor_173172.html
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Default_constructor_for_structs_20997.html
http://www.digitalmars.com/d/archives/digitalmars/D/struct_and_default_constructor_150016.html)
However there was never a good answer.
I would like a struct default constructor. My expected behavior
for it is that the struct gets initialized to .init, then my
destructor gets called so that I can do additional things if I
want.
This destructor always gets called when my struct is created
without arguments.
So for example
struct S
{
this()
{
assert(bar == 10);
foo = [5].ptr;
}
int * foo;
int bar = 10;
}
S s;
assert(*s.foo == 5);
Possible cases against it:
- It would be slower than just initializing to .init. My
proposed solution: Make the default constructor optional. If I
have a struct that doesn't define a default constructor, it is
just intialized to .init. So I can have the speed if I want to.
Also always run it post-blit (blitted from .init). Meaning I only
need to use it for things that can only be initialized at runtime.
- There already is a solution in @disable this(); static
opCall() {...}. This is hacky and working against the language.
It also makes it so that you can not allocate your struct on the
heap.
- Structs should be simple. I haven't heard this argument, but
I could imagine someone making it. I think structs should not be
simple. They are much too useful for that. Also them having copy
constructors and opAssign indicates that structs aren't expected
to be simple.
- There would be a way around it by doing S s = S.init; I don't
think that's a problem. If users want to shoot themselves in the
foot, let em. The important part is that they have to go out of
their way to do it. You could also handle that case in the copy
constructor or assignment operator. (which is an improvement to
the current behavior where you have to handle that case in every
single member function, see for example std.typecons.RefCounted)
So I really can't think of a reason for why you wouldn't want
this. Yet this discussion has happened several times already.
There is clear demand for it and very good reasons, such as those
mentioned in all the linked discussions.
So why is this being rejected?
Cheers,
Malte
Re: Windows DLLs and TLS
It is also (apparently) possible to load a DLL without using LoadLibrary: http://www.codeproject.com/Tips/430684/Loading-Win32-DLLs-manually-without-LoadLibrary Lets hope XChat is not doing anything quite that crazy.. R
Re: Windows DLLs and TLS
On Mon, 08 Oct 2012 12:26:29 +0100, Jakob Ovrum jakobov...@gmail.com wrote: I have a bug in one of my programs that I find particularly hard to reduce. I am writing a Windows DLL plugin for the IRC chat client HexChat (aka XChat). Problem is, all TLS variables, regardless of type, appear to be initialized to complete rubbish values. Reading them does not cause an access violation or anything, but the initial values are garbage. I am initializing the runtime using the helpers found in core.sys.windows.dll [1]. I wrote a dummy host application in C mimicking the loading behaviour of HexChat - the TLS variables are initialized correctly in this case, even though the DLL file is exactly the same. What is it that a host application can do to break the TLS of a D plugin it loads? [1] http://pastebin.com/rg9uUQMe Could XChat be loading your dll using: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx and the flag DONT_RESOLVE_DLL_REFERENCES, or similar. To debug, I would write a debug file using *C* IO functions from DllMain, check it loads/runs/outputs to the file from your dummy C host application, then try again with XChat and see what you get. You could also alter the dummy C host application to call LoadLibraryEx and pass DONT_RESOLVE_DLL_REFERENCES and see what happens. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Windows DLLs and TLS
On 10/8/2012 1:26 PM, Jakob Ovrum wrote: I have a bug in one of my programs that I find particularly hard to reduce. I am writing a Windows DLL plugin for the IRC chat client HexChat (aka XChat). Problem is, all TLS variables, regardless of type, appear to be initialized to complete rubbish values. Reading them does not cause an access violation or anything, but the initial values are garbage. I am initializing the runtime using the helpers found in core.sys.windows.dll [1]. I wrote a dummy host application in C mimicking the loading behaviour of HexChat - the TLS variables are initialized correctly in this case, even though the DLL file is exactly the same. What is it that a host application can do to break the TLS of a D plugin it loads? [1] http://pastebin.com/rg9uUQMe What OS are you running? Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results).
Re: Windows DLLs and TLS
08.10.2012 15:26, Jakob Ovrum пишет: I have a bug in one of my programs that I find particularly hard to reduce. I am writing a Windows DLL plugin for the IRC chat client HexChat (aka XChat). Problem is, all TLS variables, regardless of type, appear to be initialized to complete rubbish values. Reading them does not cause an access violation or anything, but the initial values are garbage. I am initializing the runtime using the helpers found in core.sys.windows.dll [1]. I wrote a dummy host application in C mimicking the loading behaviour of HexChat - the TLS variables are initialized correctly in this case, even though the DLL file is exactly the same. What is it that a host application can do to break the TLS of a D plugin it loads? [1] http://pastebin.com/rg9uUQMe What OS do you use? This problem should be related to Windows XP/Server 2003. Does you dummy host application in C use implicit TLS? Do C and D DLLs attached to this post behave differently for you regarding to TLS initialisation (load and call `getTLSIndex` and `getTLSVarValue`)? I'll try to help but I need full test suit to see where is the difference between C and D DLLs. -- Денис В. Шеломовский Denis V. Shelomovskij DLL tests.7z Description: application/7z-compressed
Re: The sorry state of the D stack?
On Sun, Oct 7, 2012 at 10:39 AM, jerro a...@a.com wrote: Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all. No, I think he'd just been busy. I've seen him around here a few times lately. Are you sure about that? There is a guy named Brad Anderson posting here, but he doesn't seem to be the Brad Anderson that dsource.org is registered to. Yeah, I'm not the same guy as the Brad Anderson who runs dsource. Someone may want to email him directly. Regards, Doppelganger
[OT] Re: Windows DLLs and TLS
08.10.2012 21:47, Rainer Schuetze пишет: Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). Here you are! Just want to mention that I'm currently managed to publish my (continuation of your) TLS fix I did half a year before. It will finally solve this XP/Sever 2003 problem. It is available here but isn't finished now (fill be in few days): https://github.com/denis-sh/hooking/tree/master/tlsfixer I hope you aren't against it is based on your work? -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 17:20:03 UTC, Regan Heath wrote: Could XChat be loading your dll using: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx and the flag DONT_RESOLVE_DLL_REFERENCES, or similar. To debug, I would write a debug file using *C* IO functions from DllMain, check it loads/runs/outputs to the file from your dummy C host application, then try again with XChat and see what you get. You could also alter the dummy C host application to call LoadLibraryEx and pass DONT_RESOLVE_DLL_REFERENCES and see what happens. R Upon loading the application, which is when plugins are loaded, DLL_PROCESS_ATTACH is invoked once. Subsequently, DLL_THREAD_ATTACH is invoked 4 times. Then after about a second, still during startup, DLL_THREAD_DETACH is invoked twice. DLL_PROCESS_DETACH is then invoked once when closing the application. XChat uses gmodule - part of glib - to load plugins. I looked at gmodule's Windows implementation, and it uses LoadLibraryW. Despite finding all this, I still tried modifying the dummy host to use LoadLibraryEx out of curiosity. An access violation occurs in some druntime exception handling code as soon as I call into the plugin's init function.
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 18:05:31 UTC, Rainer Schuetze wrote: What OS are you running? Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). I'm running Windows 7, and I'm not using any static initializers either :(
Re: Windows DLLs and TLS
08.10.2012 22:35, Jakob Ovrum пишет: On Monday, 8 October 2012 at 18:05:31 UTC, Rainer Schuetze wrote: What OS are you running? Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). I'm running Windows 7, and I'm not using any static initializers either :( As I said, give us a runnable failing test suite. As you are running Windows 7 the only reason I see is this nasty trap: http://d.puremagic.com/issues/show_bug.cgi?id=8130 Are you aware of it? -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Windows DLLs and TLS
On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij wrote: As I said, give us a runnable failing test suite. I am working on it, but as I said, it's proving very difficult to replicate outside the XChat environment. I'll try to produce a reduced plugin though. As you are running Windows 7 the only reason I see is this nasty trap: http://d.puremagic.com/issues/show_bug.cgi?id=8130 Are you aware of it? I am using a .def file, and my exported functions are being called. That's how I can tell that TLS is not working properly in the first place.
Re: Windows DLLs and TLS
08.10.2012 23:06, Jakob Ovrum пишет: On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij wrote: As I said, give us a runnable failing test suite. I am working on it, but as I said, it's proving very difficult to replicate outside the XChat environment. I'll try to produce a reduced plugin though. As you are running Windows 7 the only reason I see is this nasty trap: http://d.puremagic.com/issues/show_bug.cgi?id=8130 Are you aware of it? I am using a .def file, and my exported functions are being called. That's how I can tell that TLS is not working properly in the first place. To reduce called stuff try not to call D runtime initializers as it isn't required to set up TLS on Windows 6.x (as in test libs from my post in this thread). -- Денис В. Шеломовский Denis V. Shelomovskij
Re: core.simd woes
On 7 October 2012 13:12, Manu turkey...@gmail.com wrote:
On 5 October 2012 14:46, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 October 2012 11:28, Manu turkey...@gmail.com wrote:
On 3 October 2012 16:40, Iain Buclaw ibuc...@ubuntu.com wrote:
On 3 October 2012 02:31, jerro a...@a.com wrote:
import core.simd, std.stdio;
void main()
{
float4 a = 1, b = 2;
writeln((a + b).array); // WORKS: [3, 3, 3, 3]
float4 c = [1, 2, 3, 4]; // ERROR: Stored value type does
// not match pointer operand type!
// [..a bunch of LLVM error code..]
float4 c = 0, d = 1;
c.array[0] = 4;
c.ptr[1] = 4;
writeln((c + d).array); // WRONG: [1, 1, 1, 1]
}
Oh, that doesn't work for me either. I never tried to use those, so I
didn't
notice that before. This code gives me internal compiler errors with
GDC
and
DMD too (with float4 c = [1, 2, 3, 4] commented out). I'm using DMD
2.060
and a recent versions of GDC and LDC on 64 bit Linux.
Then don't just talk about it, raise a bug - otherwise how do you
expect it to get fixed! ( http://www.gdcproject.org/bugzilla )
I've made a note of the error you get with `__vector(float[4]) c =
[1,2,3,4];' - That is because vector expressions implementation is
very basic at the moment. Look forward to hear from all your
experiences so we can make vector support rock solid in GDC. ;-)
I didn't realise vector literals like that were supported properly in
the
front end yet?
Do they work at all? What does the code generated look like?
They get passed to the backend as of 2.060 - so looks like the
semantic passes now allow them.
I've just recently added backend support in GDC -
https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
The codegen looks like so:
float4 a = 2;
float4 b = [1,2,3,4];
==
vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
==
movaps .LC0, %xmm0
movaps %xmm0, -24(%ebp)
movaps .LC1, %xmm0
movaps %xmm0, -40(%ebp)
.align 16
.LC0:
.long 1073741824
.long 1073741824
.long 1073741824
.long 1073741824
.align 16
.LC1:
.long 1065353216
.long 1073741824
.long 1077936128
.long 1082130432
Perfect!
I can get on with my unittests :P
I fixed them again.
https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];
===
movss -16(%rbp), %xmm0
movss -12(%rbp), %xmm1
Regards
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: [OT] Re: Windows DLLs and TLS
On 10/8/2012 8:13 PM, Denis Shelomovskij wrote: 08.10.2012 21:47, Rainer Schuetze пишет: Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). Here you are! Just want to mention that I'm currently managed to publish my (continuation of your) TLS fix I did half a year before. It will finally solve this XP/Sever 2003 problem. It is available here but isn't finished now (fill be in few days): https://github.com/denis-sh/hooking/tree/master/tlsfixer Will this fix both issues (not being able to unload and that imperfect simulation of DLL_THREAD_ATTACH for existing threads)? That would be very cool. I hope you aren't against it is based on your work? Sure, no problem. It's boost licensed, isn't it? ;-)
Re: Preliminary submission - std.rational and std.typelist
On 10/08/2012 07:56 AM, Aziz K. wrote: Incidentally, I would very much need a BigFloat class/struct, written in D and independent of any C library. I'm trying to write one myself, but it seems to be rather tricky. Could this be implemented in a short amount of time by someone with more knowledge about this topic? Wasn't Paul D. Anderson working on a BigFloat?
Re: core.simd woes
On 8 October 2012 23:05, Iain Buclaw ibuc...@ubuntu.com wrote:
On 7 October 2012 13:12, Manu turkey...@gmail.com wrote:
On 5 October 2012 14:46, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 October 2012 11:28, Manu turkey...@gmail.com wrote:
On 3 October 2012 16:40, Iain Buclaw ibuc...@ubuntu.com wrote:
On 3 October 2012 02:31, jerro a...@a.com wrote:
import core.simd, std.stdio;
void main()
{
float4 a = 1, b = 2;
writeln((a + b).array); // WORKS: [3, 3, 3, 3]
float4 c = [1, 2, 3, 4]; // ERROR: Stored value type does
// not match pointer operand type!
// [..a bunch of LLVM error code..]
float4 c = 0, d = 1;
c.array[0] = 4;
c.ptr[1] = 4;
writeln((c + d).array); // WRONG: [1, 1, 1, 1]
}
Oh, that doesn't work for me either. I never tried to use those,
so I
didn't
notice that before. This code gives me internal compiler errors
with
GDC
and
DMD too (with float4 c = [1, 2, 3, 4] commented out). I'm using
DMD
2.060
and a recent versions of GDC and LDC on 64 bit Linux.
Then don't just talk about it, raise a bug - otherwise how do you
expect it to get fixed! ( http://www.gdcproject.org/bugzilla )
I've made a note of the error you get with `__vector(float[4]) c =
[1,2,3,4];' - That is because vector expressions implementation is
very basic at the moment. Look forward to hear from all your
experiences so we can make vector support rock solid in GDC. ;-)
I didn't realise vector literals like that were supported properly in
the
front end yet?
Do they work at all? What does the code generated look like?
They get passed to the backend as of 2.060 - so looks like the
semantic passes now allow them.
I've just recently added backend support in GDC -
https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
The codegen looks like so:
float4 a = 2;
float4 b = [1,2,3,4];
==
vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
==
movaps .LC0, %xmm0
movaps %xmm0, -24(%ebp)
movaps .LC1, %xmm0
movaps %xmm0, -40(%ebp)
.align 16
.LC0:
.long 1073741824
.long 1073741824
.long 1073741824
.long 1073741824
.align 16
.LC1:
.long 1065353216
.long 1073741824
.long 1077936128
.long 1082130432
Perfect!
I can get on with my unittests :P
I fixed them again.
https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];
===
movss -16(%rbp), %xmm0
movss -12(%rbp), %xmm1
Errr, that's not fixed...?
movss is not the opcode you're looking for.
Surely that should produce a single movaps...
Re: core.simd woes
Iain Buclaw wrote: I fixed them again. https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201 float a = 1, b = 2, c = 3, d = 4; float4 f = [a,b,c,d]; === movss -16(%rbp), %xmm0 movss -12(%rbp), %xmm1 Nice, not even DMD can do this yet. Can these changes be pushed upstream? On a side note, I understand GDC doesn't support the core.simd.__simd(...) command, and I'm sure you have good reasons for this. However, it would still be nice if: a) this interface was supported through function-wrappers, or.. b) DMD/LDC could find common ground with GDC in SIMD instructions I just think this sort of difference should be worked out early on. If this simply can't or won't be changed, would you mind giving a short explanation as to why? (Please forgive if you've explained this already before). Is core.simd designed to really never be used and Manu's std.simd is really the starting place for libraries? (I believe I remember him mentioning that)
Re: core.simd woes
On 8 October 2012 22:18, Manu turkey...@gmail.com wrote:
On 8 October 2012 23:05, Iain Buclaw ibuc...@ubuntu.com wrote:
On 7 October 2012 13:12, Manu turkey...@gmail.com wrote:
On 5 October 2012 14:46, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 October 2012 11:28, Manu turkey...@gmail.com wrote:
On 3 October 2012 16:40, Iain Buclaw ibuc...@ubuntu.com wrote:
On 3 October 2012 02:31, jerro a...@a.com wrote:
import core.simd, std.stdio;
void main()
{
float4 a = 1, b = 2;
writeln((a + b).array); // WORKS: [3, 3, 3, 3]
float4 c = [1, 2, 3, 4]; // ERROR: Stored value type does
// not match pointer operand type!
// [..a bunch of LLVM error code..]
float4 c = 0, d = 1;
c.array[0] = 4;
c.ptr[1] = 4;
writeln((c + d).array); // WRONG: [1, 1, 1, 1]
}
Oh, that doesn't work for me either. I never tried to use those,
so I
didn't
notice that before. This code gives me internal compiler errors
with
GDC
and
DMD too (with float4 c = [1, 2, 3, 4] commented out). I'm using
DMD
2.060
and a recent versions of GDC and LDC on 64 bit Linux.
Then don't just talk about it, raise a bug - otherwise how do you
expect it to get fixed! ( http://www.gdcproject.org/bugzilla )
I've made a note of the error you get with `__vector(float[4]) c =
[1,2,3,4];' - That is because vector expressions implementation is
very basic at the moment. Look forward to hear from all your
experiences so we can make vector support rock solid in GDC. ;-)
I didn't realise vector literals like that were supported properly in
the
front end yet?
Do they work at all? What does the code generated look like?
They get passed to the backend as of 2.060 - so looks like the
semantic passes now allow them.
I've just recently added backend support in GDC -
https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
The codegen looks like so:
float4 a = 2;
float4 b = [1,2,3,4];
==
vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
==
movaps .LC0, %xmm0
movaps %xmm0, -24(%ebp)
movaps .LC1, %xmm0
movaps %xmm0, -40(%ebp)
.align 16
.LC0:
.long 1073741824
.long 1073741824
.long 1073741824
.long 1073741824
.align 16
.LC1:
.long 1065353216
.long 1073741824
.long 1077936128
.long 1082130432
Perfect!
I can get on with my unittests :P
I fixed them again.
https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];
===
movss -16(%rbp), %xmm0
movss -12(%rbp), %xmm1
Errr, that's not fixed...?
movss is not the opcode you're looking for.
Surely that should produce a single movaps...
I didn't say I compiled with optimisations - only -march=native. =)
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: What is the case against a struct post-blit default constructor?
+1 to all of that. If the only issue is performance, I think the best solution is just to Document with a warning against using default constructors in performance critical structs.
Re: core.simd woes
On 9 October 2012 00:18, F i L witte2...@gmail.com wrote: Iain Buclaw wrote: I fixed them again. https://github.com/D-**Programming-GDC/GDC/commit/** 9402516e0b07031e841a15849f5dc9**4ae81dccdc#L4R1201https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201 float a = 1, b = 2, c = 3, d = 4; float4 f = [a,b,c,d]; === movss -16(%rbp), %xmm0 movss -12(%rbp), %xmm1 Nice, not even DMD can do this yet. Can these changes be pushed upstream? On a side note, I understand GDC doesn't support the core.simd.__simd(...) command, and I'm sure you have good reasons for this. However, it would still be nice if: a) this interface was supported through function-wrappers, or.. b) DMD/LDC could find common ground with GDC in SIMD instructions I just think this sort of difference should be worked out early on. If this simply can't or won't be changed, would you mind giving a short explanation as to why? (Please forgive if you've explained this already before). Is core.simd designed to really never be used and Manu's std.simd is really the starting place for libraries? (I believe I remember him mentioning that) core.simd just provides what the compiler provides in it's most primal state. As far as I'm concerned, it's just not meant to be used directly except by library authors. It's possible that a uniform suite of names could be made to wrap all the compiler-specific names (ldc is different again), but that would just get wrapped a second time one level higher. Hardly seems worth the effort.
Re: core.simd woes
On 8 October 2012 22:18, F i L witte2...@gmail.com wrote: Iain Buclaw wrote: I fixed them again. https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201 float a = 1, b = 2, c = 3, d = 4; float4 f = [a,b,c,d]; === movss -16(%rbp), %xmm0 movss -12(%rbp), %xmm1 Nice, not even DMD can do this yet. Can these changes be pushed upstream? On a side note, I understand GDC doesn't support the core.simd.__simd(...) command, and I'm sure you have good reasons for this. However, it would still be nice if: a) this interface was supported through function-wrappers, or.. b) DMD/LDC could find common ground with GDC in SIMD instructions I just think this sort of difference should be worked out early on. If this simply can't or won't be changed, would you mind giving a short explanation as to why? (Please forgive if you've explained this already before). Is core.simd designed to really never be used and Manu's std.simd is really the starting place for libraries? (I believe I remember him mentioning that) I'm refusing to implement any intrinsic that is tied to a specific architecture. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: core.simd woes
On 9 October 2012 00:29, Iain Buclaw ibuc...@ubuntu.com wrote:
On 8 October 2012 22:18, Manu turkey...@gmail.com wrote:
On 8 October 2012 23:05, Iain Buclaw ibuc...@ubuntu.com wrote:
On 7 October 2012 13:12, Manu turkey...@gmail.com wrote:
On 5 October 2012 14:46, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 October 2012 11:28, Manu turkey...@gmail.com wrote:
On 3 October 2012 16:40, Iain Buclaw ibuc...@ubuntu.com wrote:
On 3 October 2012 02:31, jerro a...@a.com wrote:
import core.simd, std.stdio;
void main()
{
float4 a = 1, b = 2;
writeln((a + b).array); // WORKS: [3, 3, 3, 3]
float4 c = [1, 2, 3, 4]; // ERROR: Stored value type does
// not match pointer operand type!
// [..a bunch of LLVM error code..]
float4 c = 0, d = 1;
c.array[0] = 4;
c.ptr[1] = 4;
writeln((c + d).array); // WRONG: [1, 1, 1, 1]
}
Oh, that doesn't work for me either. I never tried to use those,
so I
didn't
notice that before. This code gives me internal compiler errors
with
GDC
and
DMD too (with float4 c = [1, 2, 3, 4] commented out). I'm
using
DMD
2.060
and a recent versions of GDC and LDC on 64 bit Linux.
Then don't just talk about it, raise a bug - otherwise how do you
expect it to get fixed! ( http://www.gdcproject.org/bugzilla )
I've made a note of the error you get with `__vector(float[4]) c =
[1,2,3,4];' - That is because vector expressions implementation is
very basic at the moment. Look forward to hear from all your
experiences so we can make vector support rock solid in GDC. ;-)
I didn't realise vector literals like that were supported properly
in
the
front end yet?
Do they work at all? What does the code generated look like?
They get passed to the backend as of 2.060 - so looks like the
semantic passes now allow them.
I've just recently added backend support in GDC -
https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
The codegen looks like so:
float4 a = 2;
float4 b = [1,2,3,4];
==
vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
==
movaps .LC0, %xmm0
movaps %xmm0, -24(%ebp)
movaps .LC1, %xmm0
movaps %xmm0, -40(%ebp)
.align 16
.LC0:
.long 1073741824
.long 1073741824
.long 1073741824
.long 1073741824
.align 16
.LC1:
.long 1065353216
.long 1073741824
.long 1077936128
.long 1082130432
Perfect!
I can get on with my unittests :P
I fixed them again.
https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];
===
movss -16(%rbp), %xmm0
movss -12(%rbp), %xmm1
Errr, that's not fixed...?
movss is not the opcode you're looking for.
Surely that should produce a single movaps...
I didn't say I compiled with optimisations - only -march=native. =)
Either way, that code is wrong. The prior code was correct (albeit with the
redundant store, which I presume would have gone away with optimisation
enabled)
Re: core.simd woes
On 9 October 2012 00:29, Iain Buclaw ibuc...@ubuntu.com wrote:
On 8 October 2012 22:18, Manu turkey...@gmail.com wrote:
On 8 October 2012 23:05, Iain Buclaw ibuc...@ubuntu.com wrote:
On 7 October 2012 13:12, Manu turkey...@gmail.com wrote:
On 5 October 2012 14:46, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 October 2012 11:28, Manu turkey...@gmail.com wrote:
On 3 October 2012 16:40, Iain Buclaw ibuc...@ubuntu.com wrote:
On 3 October 2012 02:31, jerro a...@a.com wrote:
import core.simd, std.stdio;
void main()
{
float4 a = 1, b = 2;
writeln((a + b).array); // WORKS: [3, 3, 3, 3]
float4 c = [1, 2, 3, 4]; // ERROR: Stored value type does
// not match pointer operand type!
// [..a bunch of LLVM error code..]
float4 c = 0, d = 1;
c.array[0] = 4;
c.ptr[1] = 4;
writeln((c + d).array); // WRONG: [1, 1, 1, 1]
}
Oh, that doesn't work for me either. I never tried to use those,
so I
didn't
notice that before. This code gives me internal compiler errors
with
GDC
and
DMD too (with float4 c = [1, 2, 3, 4] commented out). I'm
using
DMD
2.060
and a recent versions of GDC and LDC on 64 bit Linux.
Then don't just talk about it, raise a bug - otherwise how do you
expect it to get fixed! ( http://www.gdcproject.org/bugzilla )
I've made a note of the error you get with `__vector(float[4]) c =
[1,2,3,4];' - That is because vector expressions implementation is
very basic at the moment. Look forward to hear from all your
experiences so we can make vector support rock solid in GDC. ;-)
I didn't realise vector literals like that were supported properly
in
the
front end yet?
Do they work at all? What does the code generated look like?
They get passed to the backend as of 2.060 - so looks like the
semantic passes now allow them.
I've just recently added backend support in GDC -
https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
The codegen looks like so:
float4 a = 2;
float4 b = [1,2,3,4];
==
vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
==
movaps .LC0, %xmm0
movaps %xmm0, -24(%ebp)
movaps .LC1, %xmm0
movaps %xmm0, -40(%ebp)
.align 16
.LC0:
.long 1073741824
.long 1073741824
.long 1073741824
.long 1073741824
.align 16
.LC1:
.long 1065353216
.long 1073741824
.long 1077936128
.long 1082130432
Perfect!
I can get on with my unittests :P
I fixed them again.
https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];
===
movss -16(%rbp), %xmm0
movss -12(%rbp), %xmm1
Errr, that's not fixed...?
movss is not the opcode you're looking for.
Surely that should produce a single movaps...
I didn't say I compiled with optimisations - only -march=native. =)
Either way, that code is wrong. The prior code was correct (albeit with the
redundant store, which I presume would have gone away with optimisation
enabled)
Re: core.simd woes
On 9 October 2012 00:30, Iain Buclaw ibuc...@ubuntu.com wrote: On 8 October 2012 22:18, F i L witte2...@gmail.com wrote: Iain Buclaw wrote: I fixed them again. https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201 float a = 1, b = 2, c = 3, d = 4; float4 f = [a,b,c,d]; === movss -16(%rbp), %xmm0 movss -12(%rbp), %xmm1 Nice, not even DMD can do this yet. Can these changes be pushed upstream? On a side note, I understand GDC doesn't support the core.simd.__simd(...) command, and I'm sure you have good reasons for this. However, it would still be nice if: a) this interface was supported through function-wrappers, or.. b) DMD/LDC could find common ground with GDC in SIMD instructions I just think this sort of difference should be worked out early on. If this simply can't or won't be changed, would you mind giving a short explanation as to why? (Please forgive if you've explained this already before). Is core.simd designed to really never be used and Manu's std.simd is really the starting place for libraries? (I believe I remember him mentioning that) I'm refusing to implement any intrinsic that is tied to a specific architecture. GCC offers perfectly good intrinsics anyway. And they're superior to the DMD intrinsics too.
Re: core.simd woes
On 8 October 2012 22:34, Manu turkey...@gmail.com wrote: On 9 October 2012 00:30, Iain Buclaw ibuc...@ubuntu.com wrote: On 8 October 2012 22:18, F i L witte2...@gmail.com wrote: Iain Buclaw wrote: I fixed them again. https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201 float a = 1, b = 2, c = 3, d = 4; float4 f = [a,b,c,d]; === movss -16(%rbp), %xmm0 movss -12(%rbp), %xmm1 Nice, not even DMD can do this yet. Can these changes be pushed upstream? On a side note, I understand GDC doesn't support the core.simd.__simd(...) command, and I'm sure you have good reasons for this. However, it would still be nice if: a) this interface was supported through function-wrappers, or.. b) DMD/LDC could find common ground with GDC in SIMD instructions I just think this sort of difference should be worked out early on. If this simply can't or won't be changed, would you mind giving a short explanation as to why? (Please forgive if you've explained this already before). Is core.simd designed to really never be used and Manu's std.simd is really the starting place for libraries? (I believe I remember him mentioning that) I'm refusing to implement any intrinsic that is tied to a specific architecture. GCC offers perfectly good intrinsics anyway. And they're superior to the DMD intrinsics too. Provided that a) the architecture provides them, and b) you have the right -march/-mtune flags turned on. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Preliminary submission - std.rational and std.typelist
Arlen: Yes, std.math.abs and std.numeric.gcd are very easy to implement for BigInt, Don doesn't agree regarding the gcd. To compute the gcd efficiently on large numbers you need not easy algorithms. See: http://d.puremagic.com/issues/show_bug.cgi?id=7102 Bye, bearophile
Avoiding some template bloat?
Maybe someone someday will want to implement two Phobos printing
functions usable like this:
writecfln!%d %s(10, hello);
writecf!%d %s(10, hello);
They accept a format string as template argument (format strings
are often compile-time constants and sometimes they are
computable on the fly at compile-time), verifies at compile time
(calling another CTFE function in its template constraint) that
the format string matches with the type tuple of the arguments,
and then just call writefln()/writef() with the format string and
arguments.
This variable-length-templated function avoids format string
errors at run-time. This in my opinion means taking advantage of
the static typing of D to avoid some bugs. In my opinion it's
silly to use a language with static typing, unlike Python, and
then _not_ use such static knowledge where it's usable and useful.
Using %s everywhere in writefln/writef is an option, but it's
not always usable, like when you want to use the advanced new
formatting syntax for arrays.
writecfln() and writecf() just call writefln/writef, so they are
very light, in the binary they just call another function. But if
there are many different format strings you get many similar
useless little functions in the binary (maybe inlined).
Is it possible for the D compiler to avoid the (small amount of?)
template bloat caused by writecfln/writecf? Is it useful to
introduce some kind of annotation to tell the compiler to
avoid/remove any bloat for similar functions turning them
essentially into just compile-time tests for writefln/writef? Or
is it enough to rely on the inliner of the compiler?
Beside writecfln()/writecf() I have other use cases for such
ideas. When I write certain kind of matrix code that use
fixed-sized 2D matrices, they enforce the correct sizes at
compile-time, but then they just call functions that use run-time
sized arrays, to avoid template bloat (if necessary slicing the
fixed sized matrix into a dynamic array of dynamic arrays). In
this case too I'd like to minimize or remove template bloat and
just have compile-time tests on data that is then managed with
run-time sizes (so it's not actually templated on the size of the
matrix).
Here you see a little example, regarding matrix multiplication
(here it doesn't call another function with run-time sizes, so
this is really templated):
template TMMul(M1, M2) { // helper
alias Unqual!(typeof(M1[0][0]))[M2[0].length][M1.length]
TMMul;
}
void matrixMul(T, T2, size_t k, size_t m, size_t n)
(in ref T[m][k] A, in ref T[n][m] B,
ref T2[n][k] result) pure nothrow
if (is(T2 == Unqual!T)) {
T2[m] aux;
foreach (j; 0 .. n) {
foreach (k, row; B)
aux[k] = row[j];
foreach (i, ai; A)
result[i][j] = dotProduct(ai, aux);
}
}
A third use case for such need is a poor's man homemade
management of integer-indexed dependent types. In such cases you
use the compile-time known sizes and values to enforce
compile-time sanity constraints, but then you use normal run-time
not-templated functions to avoid useless template bloat. This
means the compile-time values are meant to be used just by the
type system to verify things, but the functions are not actually
templated. Similar ghost types and other types that vanish are
commonly used in functional languages, like OCaML. Avoiding any
template bloat when you do such things is kind of needed, unless
you want to produce large binaries that do little at run time.
Bye,
bearophile
Re: DMD 2.060
On 07/10/2012 11:39, Walter Bright wrote: On 10/7/2012 3:12 AM, Alex Rønne Petersen wrote: On 07-10-2012 11:11, Russel Winder wrote: Any news on the regressions relating to threads in the 2.059 → 2.060 change? Is a 2.061 with fixes pending? I'm still not clear on what these regressions are? A list of relevant bugzilla entries would be illuminating. Not sure I can come up with a list, but here's one that affects me: http://d.puremagic.com/issues/show_bug.cgi?id=8621
Re: Struct polymorphism?
Error: function expected before (), not
'this.polyBase.opDispatch!(orig)'
I think this is a compiler bug. It complains about calling
opDispatch, however it doesn't complain if you explicitly call
'this'. Should adding 'this' be required? I am using the
-property switch so it's a little more strict, but that doesn't
seem to change the results. I can't just start adding 'this' to
all my function as outside normal functions/variables won't ever
be seen.
struct S {
Something polyBase;
alias polyBase this; //opDispatch
string callsOrig() {
return orig;//works but misleading
return orig(); //breaks
return orig(1); //breaks too
return this.orig(); //works
}
}
struct Something {
auto ref opDispatch(string fun, Args ...)(auto ref Args args)
@property;
}
My experiments concentrating on this part rather than with
arguments, those will come later when this works.
Re: Avoiding some template bloat?
(if necessary slicing the fixed sized matrix into a dynamic
array of dynamic arrays).
It's not hard to convert a fixed sized matrix into this run-time
value that requires no templating on the sizes and requires no
slicing and no heap allocations inside the template function that
performs just the compile-time tests:
struct Mat2D(T) {
T* ptr;
size_t nrows, ncols;
// + indexing methods
}
Using something like that the matrix multiplication function I've
shown becomes just a shell that calls a function that accepts two
Mat2D and is templated only on T.
Bye,
bearophile
Re: Will the D GC be awesome?
On 06/10/2012 04:03, Chad J wrote: Try to do array slicing in Java or C#. You probably won't be able to do it. You'll get string /copies/ and this will incur heap allocations in the GC heap. Those languages /need/ good garbage collection to be performant because they abuse the poor GC heavily. In fairness to Java, it does share the inner char array between strings when you request a substring. (Inside the String class you'll find a reference to a char array, and 'start' and 'count' ints.) The String object itself though (which is small and wraps the char array reference) is allocated new each time. Java's GC is rather good though, so it totally gets away with it.
Re: core.simd woes
On Monday, 8 October 2012 at 20:23:50 UTC, Iain Buclaw wrote:
float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];
===
movss -16(%rbp), %xmm0
movss -12(%rbp), %xmm1
The obligatory me too post:
LDC turns
---
import core.simd;
struct T {
float a, b, c, d;
ubyte[100] passOnStack;
}
void test(T t) {
receiver([t.a, t.b, t.c, t.d]);
}
void receiver(float4 f);
---
into
---
_D4test4testFS4test1TZv:
0: 50 push rax
1: 0f 28 44 24 10 movaps xmm0,XMMWORD PTR [rsp+0x10]
6: e8 00 00 00 00 call b
_D4test4testFS4test1TZv+0xb
b: 58 poprax
c: c3 ret
---
(the struct is just there so that the values are actually on the
stack, and receiver just so that the optimizer doesn't eat
everything for breakfast).
David
Re: core.simd woes
Iain Buclaw wrote:
I'm refusing to implement any intrinsic that is tied to a
specific architecture.
I see. So the __builtin_ia32_***() functions in gcc.builtins are
architecture agnostic? I couldn't find much documentation about
them on the web. Do you have any references you could pass on?
I guess it makes sense to just make std.simd the lib everyone
uses for a base-line support of SIMD and let DMD do what it
wants with it's core.simd lib. It sounds like gcc.builtins is
just a layer above core.simd anyways. Although now it seems that
DMD's std.simd will need a bunch of 'static if (architectureX) {
... }' for every GDC builtin... wounder if later that shouldn't
be moved to (and standerized) a 'core.builtins' module or
something.
Thanks for the explanation.
Re: core.simd woes
On 9 October 2012 00:38, F i L witte2...@gmail.com wrote:
Iain Buclaw wrote:
I'm refusing to implement any intrinsic that is tied to a specific
architecture.
I see. So the __builtin_ia32_***() functions in gcc.builtins are
architecture agnostic? I couldn't find much documentation about them on the
web. Do you have any references you could pass on?
I guess it makes sense to just make std.simd the lib everyone uses for a
base-line support of SIMD and let DMD do what it wants with it's core.simd
lib. It sounds like gcc.builtins is just a layer above core.simd anyways.
Although now it seems that DMD's std.simd will need a bunch of 'static if
(architectureX) { ... }' for every GDC builtin... wounder if later that
shouldn't be moved to (and standerized) a 'core.builtins' module or
something.
Thanks for the explanation.
gcc.builtins does something different depending on architecure, and
target cpu flags. All I do is take what gcc backend gives to the
frontend, and hash it out to D. What I meant is that I won't
implement a frontend intrinsic that...
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: core.simd woes
On Monday, 8 October 2012 at 21:36:08 UTC, F i L wrote: Iain Buclaw wrote: float a = 1, b = 2, c = 3, d = 4; float4 f = [a,b,c,d]; === movss -16(%rbp), %xmm0 movss -12(%rbp), %xmm1 Nice, not even DMD can do this yet. Can these changes be pushed upstream? No, the actual codegen is compilers-specific (and apparently wrong in the case of GDC, if this is the actual piece of code emitted for the code snippet). On a side note, I understand GDC doesn't support the core.simd.__simd(...) command, and I'm sure you have good reasons for this. However, it would still be nice if: a) this interface was supported through function-wrappers, or.. b) DMD/LDC could find common ground with GDC in SIMD instructions LDC won't support core.simd.__simd in the forseeable future either. The reason is that it is a) untyped and b) highly x86-specific, both of which make it hard to integrate with LLVM – __simd is really just a glorified inline assembly expression (hm, this makes me think, maybe it could be implemented quite easily in terms of a transformation to LLVM inline assembly expressions…). Is core.simd designed to really never be used and Manu's std.simd is really the starting place for libraries? (I believe I remember him mentioning that) With all due respect to Walter, core.simd isn't really designed much at all, or at least this isn't visible in its current state – it rather seems like a quick hack to get some basic SIMD code working with DMD (but beware of ICEs). Walter, if you are following this thread, do you have any plans for SIMD on non-x86 platforms? David
Re: Will the D GC be awesome?
On Thursday, 4 October 2012 at 05:33:21 UTC, Walter Bright wrote:
On 10/3/2012 2:26 PM, DypthroposTheImposter wrote:
* OpCmp returning an int is fugly I r sad
How else would you return a 3 state value?
Via enums.
enum CmpValues { lessThan = -1, equal = 0, greaterThan = 1}
But then again, the enum is convertible to int :P. I think ints
(or size_t) are just fine and do their job.
Re: Preliminary submission - std.rational and std.typelist
On Mon, Oct 8, 2012 at 4:37 PM, bearophile bearophileh...@lycos.com wrote:
Arlen:
Yes, std.math.abs and std.numeric.gcd are very easy to implement for
BigInt,
Don doesn't agree regarding the gcd. To compute the gcd efficiently on large
numbers you need not easy algorithms.
See:
http://d.puremagic.com/issues/show_bug.cgi?id=7102
Bye,
bearophile
gcd() is very easy to implement:
BigInt _gcd(BigInt a, BigInt b)
{
enforce(a = 0 b =0);
while (b != 0) {
auto t = b;
b = a % b;
a = t;
}
return a;
}
It's not going to be the fastest or the most efficient, but it does
produce correct results, and that's the most important thing when
implementing mathematical functions IMO. You can always improve the
performance later. Implementing pow(), on the other hand, is very
difficult and complex.
Re: Struct polymorphism?
On Sunday, 7 October 2012 at 10:04:57 UTC, Era Scarecrow wrote: What are the possibilities of struct polymorphism? What would be the issues with it? What if we wanted to use it in a limited sense? Currently I'm experimenting with it since classes are too bulky for what I need, yet I really need some type of behavior/dynamic polymorphism. So far I have a working model. It takes the following limitations: A question of efficiency comes up. If at compile-time we can confirm only a couple branches/possibilities, then only those are considered during run-time. During optimization is that code just inlined to where it is called rather than the jump to opDispatch? Seems like it should if it's small enough, especially if there's only 1 possibility. Now I guess a question out there for you all. Who would be interested in an implementation and how would you use it? Does it seem like a good idea? How many levels would you want to use? One? Several levels allowing class-like inheritance?
Re: Avoiding some template bloat?
On Tue, Oct 9, 2012 at 12:13 AM, bearophile bearophileh...@lycos.com wrote: Maybe someone someday will want to implement two Phobos printing functions usable like this: writecfln!%d %s(10, hello); writecf!%d %s(10, hello); They accept a format string as template argument (format strings are often compile-time constants and sometimes they are computable on the fly at compile-time), verifies at compile time (calling another CTFE function in its template constraint) that the format string matches with the type tuple of the arguments, and then just call writefln()/writef() with the format string and arguments. IIRC, I did that as an example in my template tutorial: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true (section 32, on page 167) Code in https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/templates_examples.tex#L2000 and below.
Re: Any sample for DFL library?
No, win32 only. It didn't seem relevant in first post, but I am screen reader user and GTK is totally inaccessible / unusable on Windows. Dňa 7. 10. 2012 21:18 Michael wrote / napísal(a): gtkD ?
Re: Any sample for DFL library?
Thank you. Dňa 7. 10. 2012 21:26 Andrej Mitrovic wrote / napísal(a): On 10/7/12, Lubos Pintes lubos.pin...@gmail.com wrote: Hi, There are at least two interesting GUI libraries for Windows: DGUI and DFL. But there seems to be no sample code for DFL. Does someone have any samples for DFL? And yes, I know about DWT, but it is a bit heavy-weight. There are older ones here: http://www.dprogramming.com/dfl/snapshots/dfl-20110523.zip Look in packages/dfl/examples. I don't know why they're not on the new github page yet https://github.com/Rayerd/dfl
Re: Any sample for DFL library?
I fixed that for myself after checkout, it only needed some cast(WNDPROC) etc. on some places. Don't know however if it doesn't have another problems, I ran some random samples and from screen reader's point of view, it worked fine. (besides owner-drawn labels, which are not so fine. :-)) Dňa 7. 10. 2012 22:47 Mike James wrote / napísal(a): Lubos Pintes wrote in message news:k4skro$n6q$1...@digitalmars.com... Hi, There are at least two interesting GUI libraries for Windows: DGUI and DFL. But there seems to be no sample code for DFL. Does someone have any samples for DFL? And yes, I know about DWT, but it is a bit heavy-weight. DGUI doesn't compile with the latest D compiler - it's not been updated for nearly a year.
Unicode encodings and string literals
Hi, I am playing with samples from Petzold's Programming Windows converted by Andrej Mitrovic. Many thanks, Andrej. :-) My question is about string conversion. There is a function in virtually every sample named toUTF16z, which if I understand properly, converts string to UTF-16, so that they can be sent to various Windows API functions. But string literals, for example in MessageBox, are fine, no conversion is needed. I don't understand the magic, what is converted, and when? If some variable was used e.g. appName.toUTF16z, and not Error.toUTF16z
Re: Unicode encodings and string literals
On 2012-10-08 10:06, Lubos Pintes wrote: Hi, I am playing with samples from Petzold's Programming Windows converted by Andrej Mitrovic. Many thanks, Andrej. :-) My question is about string conversion. There is a function in virtually every sample named toUTF16z, which if I understand properly, converts string to UTF-16, so that they can be sent to various Windows API functions. But string literals, for example in MessageBox, are fine, no conversion is needed. I don't understand the magic, what is converted, and when? If some variable was used e.g. appName.toUTF16z, and not Error.toUTF16z Without looking at the code, this is my guess: The toUTF16z function converts a D string, of any Unicode encoding, to UTF-16 and converts that to a C string. String literals in D have a trailing null character \0 included making them compatible with functions expecting C strings. String variables on the other do not have the trailing null character and therefore needs a conversion. -- /Jacob Carlborg
Growing multidimensional dynamic arrays
Hi all,
This seems like something that should be possible: how do I grow
multidimensional arrays?
I want something like this:
struct X{ ... };
X*[][] listOfLists;
foreach ( x ; otherListOfX ) {
if ( newListForArbitraryReason ) {
listOfLists ~= new X*[];
}
listOfLists[$] ~= x;
}
Now, this doesn't compile, because I _have_ to give a size to new
X*[](arbitrary_number), and the listOfLists[$] ~= x; line never
works (hangs at runtime).
So, how would I go about doing this? My apologies if this is
something really obvious.
CFTE+DevIL=?
Hi! I need to load some textures for my game,but I woud like to do it in compile time. I know that CTFE imposes restrictions on functions.So can I execute some DevIL(Derelict3) functions?
Re: Growing multidimensional dynamic arrays
On 10/08/2012 06:12 AM, KillerSponge wrote:
Hi all,
This seems like something that should be possible: how do I grow
multidimensional arrays?
I want something like this:
struct X{ ... };
X*[][] listOfLists;
foreach ( x ; otherListOfX ) {
if ( newListForArbitraryReason ) {
listOfLists ~= new X*[];
}
listOfLists[$] ~= x;
}
Now, this doesn't compile, because I _have_ to give a size to new
X*[](arbitrary_number), and the listOfLists[$] ~= x; line never works
(hangs at runtime).
So, how would I go about doing this? My apologies if this is something
really obvious.
I don't see the need for 'new' nor the use of a pointer, so I will not
use them (yet): :)
import std.stdio;
struct X
{
int i;
}
void main()
{
X[][] listOfLists;
auto otherListOfX = [ X(1), X(2), X(3) ];
auto newListForArbitraryReason = true;
foreach (x; otherListOfX) {
if (newListForArbitraryReason) {
X[] newList = [ x ];
listOfLists ~= newList;
}
}
writeln(listOfLists);
}
The body of foreach can be shorter:
listOfLists ~= [ x ];
Also note that
- There is no need for the semicolon at the end of the struct definition.
- $ is not a valid index value. The last element is indexed by $-1.
Ali
--
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Re: CFTE+DevIL=?
Zhenya wrote: Hi! I need to load some textures for my game,but I woud like to do it in compile time. I know that CTFE imposes restrictions on functions.So can I execute some DevIL(Derelict3) functions? CTFE can only evaluate D functions that have their bodies available. It means that external code coming from C or D external library can't be evaluated.
Re: Growing multidimensional dynamic arrays
On Monday, 8 October 2012 at 13:56:00 UTC, Ali Çehreli wrote:
I don't see the need for 'new' nor the use of a pointer, so I
will not use them (yet): :)
import std.stdio;
struct X
{
int i;
}
void main()
{
X[][] listOfLists;
auto otherListOfX = [ X(1), X(2), X(3) ];
auto newListForArbitraryReason = true;
foreach (x; otherListOfX) {
if (newListForArbitraryReason) {
X[] newList = [ x ];
listOfLists ~= newList;
}
}
writeln(listOfLists);
}
The body of foreach can be shorter:
listOfLists ~= [ x ];
Also note that
- There is no need for the semicolon at the end of the struct
definition.
- $ is not a valid index value. The last element is indexed by
$-1.
Ali
Ah, that works great (even with pointers ;)! Thanks a lot! :) It
seems so obvious now.
And the use of $ was indeed a stupid mistake on my part. I guess
I was confused because of the way it is often used in slicing. I
really should pay attention to that :)
Re: Struct polymorphism?
Perhaps someone can help explain this mystery. I've got a
working system, except when it's coming to an unknown function
inside my structs.
Perhaps to note opDispatch is added via a mixin template, not
sure if that makes a difference.
Error: function expected before (), not
'this.polyBase.opDispatch!(orig)'
struct Base {
PolyMorph polyBase;
alias polyBase this;
string callsOrig() {
return orig(); //dies here
}
}
//opDispatch signature
auto ref opDispatch(string fun, Args ...)(auto ref Args args);
Re: ddoc - documenting private variables
On 10/07/2012 12:33 PM, Adam D. Ruppe wrote:
On Sunday, 7 October 2012 at 19:36:39 UTC, Charles Hixson wrote:
FWIW, I have absolutely NO knowledge of JSON, except that it's
something to do with web pages (well, and it's a language or possibly
a library).
I haven't actually used that project (I just saw the link and figured it
might help) but you can make json with dmd. Run dmd -X -D yourfile.d and
it spits out yourfile.json.
But another option might be to just modify your copy of dmd to output
private things too. Open the file dmd2/src/dmd/doc.c and search for the
term PROTprivate. Simply comment that part so it doesn't return. For
example:
void EnumDeclaration::emitComment(Scope *sc)
{
if (prot() == PROTprivate)
return;
Just comment that out and repeat for each time you see it. I count six
occurrences of that in the dmd source. And then there's this:
void Declaration::emitComment(Scope *sc)
{
//printf(Declaration::emitComment(%p '%s'), comment = '%s'\n, this,
toChars(), comment);
//printf(type = %p\n, type);
if (protection == PROTprivate || !ident ||
(!type !isCtorDeclaration() !isAliasDeclaration()))
return;
And you can probably just comment that protection clause there too.
Then recompile the dmd (make -f posix.mak on linux and I think make -f
win32.mak on windows) and use your customized compiler.
That seems, to me, a much more reasonable solution. I'm going to flag
this important. But I'll probably use DOxygen, because I don't like the
on-going maintenance, and because ddoc comments are too verbose (more in
vertical space than in horizontal space). I'll certainly keep that
option in mind, however, in case I run into too many limits with DOxygen.
Re: CFTE+DevIL=?
On 2012-10-08 15:24, Zhenya wrote: Hi! I need to load some textures for my game,but I woud like to do it in compile time. I know that CTFE imposes restrictions on functions.So can I execute some DevIL(Derelict3) functions? What you can do is importing the textures into the executable, at compile time, if that helps: http://dlang.org/expression.html#ImportExpression -- /Jacob Carlborg
VisualD: Is keyboard navigation in project properties broken?
Hi, I installed VisualD, together with VS Shell, because I have only express versions of VS 2008 on my system, win 7 64 bit. As a screen reader user, I heavily depend on keyboard. I successfully set up a testing project, dependend on windows api bindings. I needed to set a version identifier, so I went to project properties, set configuration to all, and platform to win32. Then I went to the options tree view, expanded the Compiler/General and I was unable to tab to options I could possibly set. Only Ok, Cancel, Configuration combo box etc. was available... So is this a bug? Or something weird only on my system?
Re: Using inout in delegates
On 10/05/2012 04:09 PM, Ali Çehreli wrote:
...
This workaround makes the compiler happy:
void foo (inout(int)[] arr)
{
auto a = (inout int) { auto b = arr[0]; };
}
But probably not what you want. :/
IIRC, inout has bugs and incomplete implementation. I think this should
be in the bug database.
Ali
The original behaviour is to be expected and the workaround exploits a
compiler bug.
The correct way to get rid of the compile error is:
void foo(inout(int)[] arr){
auto a = { const b = arr[0]; } // or int b = arr[0];
}
Re: Struct polymorphism?
On Monday, 8 October 2012 at 15:23:58 UTC, Era Scarecrow wrote:
Error: function expected before (), not
'this.polyBase.opDispatch!(orig)'
I think this is a compiler bug. It complains about calling
opDispatch, however it doesn't complain if you explicitly call
'this'. Should adding 'this' be required? I am using the
-property switch so it's a little more strict, but that doesn't
seem to change the results. I can't just start adding 'this' to
all my function as outside normal functions/variables won't ever
be seen.
struct S {
Something polyBase;
alias polyBase this; //opDispatch
string callsOrig() {
return orig;//works but misleading
return orig(); //breaks
return orig(1); //breaks too
return this.orig(); //works
}
}
struct Something {
auto ref opDispatch(string fun, Args ...)(auto ref Args args)
@property;
}
My experiments concentrating on this part rather than with
arguments, those will come later when this works.
Re: Struct polymorphism?
On 10/08/2012 03:19 PM, Era Scarecrow wrote: On Monday, 8 October 2012 at 15:23:58 UTC, Era Scarecrow wrote: Error: function expected before (), not 'this.polyBase.opDispatch!(orig)' I think this is a compiler bug. It complains about calling opDispatch, however it doesn't complain if you explicitly call 'this'. Should adding 'this' be required? I don't know all of the design decisions behind opDispatch, but I would be happier to have to type this. when inside the struct. Otherwise, any struct that defined opDispatch would miss out on compiler's static name checking. What if orig() has actually been a mistyped free-standing function name? Being forced to type this.orig() makes it explicit. And to me, this seems even better: return polyBase.orig(1); I can't just start adding 'this' to all my function as outside normal functions/variables won't ever be seen. Sorry, I can't understand the problem that you describe in that sentence. Ali
Re: Struct polymorphism?
On Monday, 8 October 2012 at 22:57:04 UTC, Ali Çehreli wrote:
I don't know all of the design decisions behind opDispatch, but
I would be happier to have to type this. when inside the
struct. Otherwise, any struct that defined opDispatch would
miss out on compiler's static name checking.
What if orig() has actually been a mistyped free-standing
function name? Being forced to type this.orig() makes it
explicit. And to me, this seems even better:
return polyBase.orig(1);
Yes likely this is what will happen.. Just seems like it isn't
needed.
I can't just start adding 'this' to all my function as outside
normal functions/variables won't ever be seen.
Sorry, I can't understand the problem that you describe in that
sentence.
Hmmm added a this.writeln() and it worked fine without calling
opDispatch. How odd. Still seems like a compiler bug to me.
The idea behind that i'm experimenting with is in reality the
struct contained two functions. So..
struct S {
Something polyBase;
alias polyBase this; //opDispatch
string orig() {
return some string;
}
string callsOrig() {
return orig();
}
}
With that everything is happy. Now if I rename orig to
Poly_orig, then callsOrig complains and the issue comes up. The
polyBase will check among the rules it has and adds Poly_ to the
functions while it's checking them (among other ones), before
finally calling S.Poly_orig() with all it's arguments.
So it will look something like this.
struct Data {
string msg;
}
struct Something {
Data data; //shared data
auto ref opDispatch(string op, Args ...)(auto ref Args args) {
static if (op == orig) {
return (cast(S) data).Poly_orig();
} else {
static assert(0, op ~ - Not found); //205
}
}
}
struct S {
Something polyBase;
alias polyBase this; //opDispatch
//string orig() {//statically assigned
string Poly_orig() { //opDispatch calls now
return some string;
}
string callsOrig() {
return orig(); //220
return this.orig();
return polyBase.orig();
}
string oddball() {
//asserts can't find blarg or Poly_blarg in opDispatch
return blarg(); //227
return this.blarg(); //228
}
}
test.d(220): Error: function expected before (), not
'this.polyBase.opDispatch!(orig)'
test.d(227): Error: function expected before (), not
'this.polyBase.opDispatch!(blarg)'
test.d(205): Error: static assert blarg - Not found
test.d(228):instantiated from here: opDispatch!(blarg,)
I'd rather have where once I get my code debugged for a struct
that I don't have to suddenly add this. or polyBase to all my
functions after I rename the functions to Poly_. If it's a
necessary evil than I'll accept it.
Re: CFTE+DevIL=?
On Monday, 8 October 2012 at 18:07:49 UTC, Jacob Carlborg wrote: On 2012-10-08 15:24, Zhenya wrote: Hi! I need to load some textures for my game,but I woud like to do it in compile time. I know that CTFE imposes restrictions on functions.So can I execute some DevIL(Derelict3) functions? What you can do is importing the textures into the executable, at compile time, if that helps: http://dlang.org/expression.html#ImportExpression That can bring the image into the app as an array of bytes. Then at runtime, you can use DevIL to load the image data from the byte array. I've got a blog post[1] about doing this very thing (with SDL rather than DevIL, but it's all the same). [1] http://www.gamedev.net/blog/1140/entry-2254294-compiling-data-into-a-d-executable/
Re: std.algorithm.skipOver broken / misbehaving?
On Friday, 5 October 2012 at 08:53:22 UTC, Era Scarecrow wrote: Mmmm glancing at the notes again, maybe I misread it and it only skips if the beginning equals, rather than if it contains... Kinda annoying since it sounds like what I wanted would work... Pretty sure the semantics you want are in, findSkip.
[Issue 8779] New: std.zlib.UnCompress needs a way to detect end-of-stream
http://d.puremagic.com/issues/show_bug.cgi?id=8779 Summary: std.zlib.UnCompress needs a way to detect end-of-stream Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: slud...@outerproduct.org --- Comment #0 from S�nke Ludwig slud...@outerproduct.org 2012-10-08 02:24:53 PDT --- The return value of the inflate() call is currently not distinguished between Z_OK and Z_STREAM_END. However, this information is necessary if the size of the inflated stream is unknown. UnCompress either needs to return a status with each uncompress() call, or, probably better, get an empty() property that is set accordingly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8780] New: std.traits.ReturnType of overloaded functions
http://d.puremagic.com/issues/show_bug.cgi?id=8780
Summary: std.traits.ReturnType of overloaded functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: luka8...@owave.net
--- Comment #0 from luka8088 luka8...@owave.net 2012-10-08 03:29:06 PDT ---
module program;
import std.stdio;
import std.traits;
int f1 () { return 1; }
string f1 () { return 2; }
void main () {
ReturnType!(f1) v1;
writeln(typeid(typeof(v1))); // int
// chould this lead to unexpected behavior ?
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8780] std.traits.ReturnType of overloaded functions
http://d.puremagic.com/issues/show_bug.cgi?id=8780
--- Comment #1 from luka8088 luka8...@owave.net 2012-10-08 03:44:04 PDT ---
module program;
import std.stdio;
import std.traits;
class a {}
class b {}
int f1 (a o) { return 1; }
string f1 (b o) { return 2; }
void main () {
a a1 = new a();
b b1 = new b();
writeln(a1.f1()); // 1
writeln(b1.f1()); // 2
typeof(a1.f1()) v1; // int
typeof(b1.f1()) v2; // string
ReturnType!(a1.f1) v2; // Error: no property 'f1' for type 'program.a'
// Error: ReturnType!(__error) is used as a type
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8780] std.traits.ReturnType of overloaded functions
http://d.puremagic.com/issues/show_bug.cgi?id=8780 --- Comment #2 from luka8088 luka8...@owave.net 2012-10-08 04:04:34 PDT --- I am sorry for such bad description but it seems to me that there are multiple bugs here and I am not sure where the problem is - or even if there is one. Free free to provide a better description =) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8782] D lexer do not understand unicode char … for variadic
http://d.puremagic.com/issues/show_bug.cgi?id=8782
--- Comment #1 from bioinfornatics bioinfornat...@gmail.com 2012-10-08
04:32:24 PDT ---
(In reply to comment #0)
D lexer do not understand unicode char … for variadic.
from some keayboard layout is faster to write … than ...
import std.stdio;
import std.algorithm;
import std.array;
void main( ){
immutable int[] a = [4, 6, 1, 2,];
immutable int[] b = cast(immutable) a.dup
.sort!( (x,y) = x y )
.array;
writeln( b );
}
oops bad paste sorry
import std.stdio;
void foo( int[] params … ){
foreach( param; params )
writeln( praram );
}
void main(){
foo( 1, 2, 3, 4 );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7065] align() refused for struct defined inside functions
http://d.puremagic.com/issues/show_bug.cgi?id=7065 --- Comment #2 from github-bugzi...@puremagic.com 2012-10-08 04:44:27 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d04348f37e3bfb9e7976f2c360c5c06b4d6f62fd Issue 7065 - align() refused for struct defined inside functions https://github.com/D-Programming-Language/dmd/commit/381eec8240dcc8eeacd9d81285b77f4324f32090 Merge pull request #562 from 9rnsr/fix6534 Issue 6534 7065 7172 - Parser improvements for inner aggregates -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6534] const struct definition inside functions too
http://d.puremagic.com/issues/show_bug.cgi?id=6534 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #7 from yebblies yebbl...@gmail.com 2012-10-08 22:44:52 EST --- https://github.com/D-Programming-Language/dmd/commit/381eec8240dcc8eeacd9d81285b77f4324f32090 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7065] align() refused for struct defined inside functions
http://d.puremagic.com/issues/show_bug.cgi?id=7065 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #3 from yebblies yebbl...@gmail.com 2012-10-08 22:44:59 EST --- https://github.com/D-Programming-Language/dmd/commit/381eec8240dcc8eeacd9d81285b77f4324f32090 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6534] const struct definition inside functions too
http://d.puremagic.com/issues/show_bug.cgi?id=6534 --- Comment #6 from github-bugzi...@puremagic.com 2012-10-08 04:44:21 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0adbdc1d860a1d718d36fc6a982aaeb7667ed1d8 Issue 6534 - const struct definition inside functions too https://github.com/D-Programming-Language/dmd/commit/381eec8240dcc8eeacd9d81285b77f4324f32090 Merge pull request #562 from 9rnsr/fix6534 Issue 6534 7065 7172 - Parser improvements for inner aggregates -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7172] nested class with additional attributes is not supported
http://d.puremagic.com/issues/show_bug.cgi?id=7172 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #3 from yebblies yebbl...@gmail.com 2012-10-08 22:45:07 EST --- https://github.com/D-Programming-Language/dmd/commit/381eec8240dcc8eeacd9d81285b77f4324f32090 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8782] D lexer do not understand unicode char … for variadic
http://d.puremagic.com/issues/show_bug.cgi?id=8782 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2012-10-08 04:46:17 PDT --- The idea of using unicode glyphs in source code is interesting, and I think the now dead Fortress shows it's useful if done well. But introducing such change in D, and requiring a smart editor, just for a single symbol is a bit too much for too much little. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6174] Initialize const fixed-size array in constructor
http://d.puremagic.com/issues/show_bug.cgi?id=6174
--- Comment #9 from Kenji Hara k.hara...@gmail.com 2012-10-08 05:35:43 PDT ---
(In reply to comment #8)
Is this expected? Do you want me to put this in a new bug report?
struct Foo {
int[1] bar;
}
const Foo[1] foos;
static this() {
foreach (i; 0 .. foos.length)
foos[i].bar[i] = 1; // OK
foreach (i, ref f; foos)
f.bar[i] = 1; // Error
}
void main() {}
Hmm, it's interesting. The accessed memory through the reference 'f' would
specify a part of the constructed fields, and compiler would be able to detect
it in statically.
Please put in a new report.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8773] [CTFE] foreach ref element doesn't work well at compile time.
http://d.puremagic.com/issues/show_bug.cgi?id=8773 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2012-10-08 06:02:34 PDT --- Duplicate of bug 7658? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
