Re: handful and interval
On Sunday, 2 September 2012 at 14:49:34 UTC, Andrei Alexandrescu
wrote:
On 9/2/12 4:22 PM, Andrei Alexandrescu wrote:
[snip]
The alternative would be to simply define these as functions:
if (a.among("struct", "class", "union")) { ... }
if (b.between(1, 100)) { ... }
Andrei
I prefer this.
There doesn't seem to be a clear vision for the 'in' operator.
Let's not make the situation more complicated before we've
figured that out. How do we know which uses of 'in' are abuse,
and which are merely exploiting intuition justifiably?
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 06:25:19 UTC, Tommi wrote: On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote: A function which uses __ctfe should probably do essentially the same thing at both runtime and compile time, but it _has_ __ctfe, because the runtime implementation won't work at compile time, and it's up to the programmer to make sure that the function does what it's supposed to at both compile time and runtime. The compiler can't possibly enforce that. Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners. The only real problem here is that you wrote a function called pow2 that effectively returns 6 unconditionally. I doubt your math professor would be particularly impressed. If you had used __ctfe properly, it would return the same value both at compile-time and runtime. At present, __ctfe is a necessary evil as CTFE can be severely crippled without it.
Re: Idea: Introduce zero-terminated string specifier
On Monday, 1 October 2012 at 09:17:52 UTC, Piotr Szturmaj wrote: Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen wrote: Also this reminds me of the utter uselessness of the current behavior of "%s" and a pointer - it prints the address. Why not specialize current "%s" for character pointer types so it will print null terminated strings? It's always possible to cast to void* to print an address. It's not safe to assume that pointers to characters are generally null terminated.
Re: Idea: Introduce zero-terminated string specifier
On Tuesday, 2 October 2012 at 21:30:35 UTC, Andrej Mitrovic wrote: On 10/2/12, Walter Bright wrote: On 9/30/2012 11:31 AM, deadalnix wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; Since %zs is inherently unsafe, it hides such unsafety in a commonly used library function, which will infect everything else that transitively calls writefln with unsafety. This makes %zs an unacceptable feature. How does it hide anything if you have to explicitly mark the format specifier as %zs? It would be documented, just like it's documented that passing pointers to garbage-collected memory to the C side is inherently unsafe. writefln cannot be @safe if it has to support an unsafe format specifier. It's "hidden" because it affects every call to writefln, even if it doesn't use the unsafe format specifier.
Re: Idea: Introduce zero-terminated string specifier
On Wednesday, 3 October 2012 at 05:04:01 UTC, H. S. Teoh wrote:
Yes that's what I mean. If the format string is known at
compile-time
and known to involve only @safe code, then this would work.
Something
like this might work if CTFE is used to parse the format string
piecemeal (i.e., translate something like writefln("%d %s",x,y)
into
write!int(x); write!string(" "); write!string(y)). The safe
instances of
write!T(...) will be marked @safe.
It doesn't matter if the argument is known at compile-time or
not, because there's no way to know that without receiving the
format string as a template parameter, in which case it must
*always* be known at compile-time (runtime format string would
not be supported), and then the syntax is no longer writefln("%d
%s", x, y). Obviously, such a change is not acceptable.
I suppose we could just use @trusted
and call it a day.
No, that would be abusing @trusted. The function would no longer
be safe, *because it contains possibly unsafe code*. @trusted is
for safe functions that the compiler cannot prove safe.
Re: Proposal: clean up semantics of array literals vs string literals
On Thursday, 4 October 2012 at 07:57:16 UTC, Bernard Helyer wrote: On Tuesday, 2 October 2012 at 15:14:10 UTC, Andrei Alexandrescu wrote: First, I think zero-terminated strings shouldn't be needed frequently enough in D code to make this necessary. My experience has been much different. Interfacing with C occurs in nearly every D program I write, and I usually end up passing a string literal. Anecdotes! Agreed. I'm always happy when I find that the particular C API I am working with supports passing strings as a pointer/length pair :) Anyway, toStringz (and the wchar and dchar equivalents in std.utf) needs to be fixed regardless - it currently does a dangerous optimization if the string is immutable, otherwise it unconditionally concatenates. We cannot rely on strings being GC allocated based on mutability. Memory is outside the scope of the D type system - we cannot make assumptions about memory based on types.
Re: The sorry state of the D stack?
On Saturday, 6 October 2012 at 14:50:08 UTC, Adam D. Ruppe wrote: IIRC it is very easy to do this on Windows as there's no need to change the console mode. Windows already has getch() in one of its system libraries or C runtime, and I'm fairly sure it has kbhit() somewhere too. The easiest thing to do would just be to link with those.
Re: Preliminary submission - std.rational and std.typelist
On Sunday, 7 October 2012 at 07:36:08 UTC, Philippe Sigaud wrote:
On Sat, Oct 6, 2012 at 8:32 PM, Dmitry Olshansky
wrote:
Your current code may have some bad impact on performance:
return "(" ~ to!string(res.numerator) ~ "/" ~
to!string(res.denominator) ~
")";
Allocates 4 times. ~ operator is convenient shortcut to get
job done but
it's unsuitable for building strings and formatted output.
And the solution is?
Appender and formattedWrite can do this with a minimal amount of
memory allocations.
The best solution is of course the writeTo function from DIP9
[1], which hasn't been accepted yet for some reason.
[1] http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
Re: Preliminary submission - std.rational and std.typelist
On Sunday, 7 October 2012 at 09:27:54 UTC, Dmitry Olshansky wrote:
Ehem.. I've been pushing for DIP9 a lot of time. But then I
find out that it is already here (and been for some time).
Like I said use a special overload of toString that is exactly
writeTo.
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);
}
Nice! I didn't know that. I thought this toString signature was
only used by BigInt, and not taken advantage of by other routines.
To implement it fully we would still want to change toString for
classes, and probably do something like providing a UFCS function
in object.toString or some other relevant location for
convenience and backwards compatibility.
Re: Preliminary submission - std.rational and std.typelist
On Sunday, 7 October 2012 at 09:58:54 UTC, Jonathan M Davis wrote: Well, considering that we're looking at removing toString, toHash, opCmp, and opEquals from Object entirely, that probably won't be necessary. But that particular plan hasn't gotten past the initial discussions AFAIK, so who knows exactly how it's going to go or when it's going to happen. - Jonathan M Davis This is definitely something I would like to happen.
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: 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: 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: 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
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
On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij wrote: As I said, give us a runnable failing test suite. Here's a reduced plugin with VisualD project files and all dependencies. http://filesmelt.com/dl/bugdist.rar It uses the standard DllMain, and the only thing xchat_plugin_init contains is this line: xchat_printf(ph, "test = %p:%d", test.ptr, test.length); Where 'test' is a TLS variable of type string[] with no explicit initializer.
Re: Windows DLLs and TLS
On Tuesday, 9 October 2012 at 08:41:46 UTC, Jakob Ovrum wrote: On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij wrote: As I said, give us a runnable failing test suite. Here's a reduced plugin with VisualD project files and all dependencies. http://filesmelt.com/dl/bugdist.rar It uses the standard DllMain, and the only thing xchat_plugin_init contains is this line: xchat_printf(ph, "test = %p:%d", test.ptr, test.length); Where 'test' is a TLS variable of type string[] with no explicit initializer. The printed garbage value is the same when DllMain is empty. (BTW, to test this, build the DLL and drop it in folder>/addons. The line will then print on startup in the first available chat window)
Re: Windows DLLs and TLS
On Tuesday, 9 October 2012 at 10:21:58 UTC, Regan Heath wrote: On Mon, 08 Oct 2012 19:32:40 +0100, Jakob Ovrum wrote: XChat uses gmodule - part of glib - to load plugins. I looked at gmodule's Windows implementation, and it uses LoadLibraryW. Does your dummy C host application also use gmodule to load the dll.. that might be a useful experiment perhaps. R I tried this, and the results are illuminating. I added gmodule support to the C host, enabling switching between using gmodule and direct WinAPI at the switch of a preprocessor define. When the WinAPI is used directly, they get their correct initializers like before (I included some variables with explicit initializers too, like void* test3 = cast(void*)1). When gmodule is used, the test TLS variables contain garbage! The garbage values are different every time the program runs. I'll look closer at what gmodule is doing.
Re: Windows DLLs and TLS
On Tuesday, 9 October 2012 at 10:21:58 UTC, Regan Heath wrote:
Does your dummy C host application also use gmodule to load the
dll.. that might be a useful experiment perhaps.
R
The problem has now been reduced to these two palatable programs.
bug.dll
---
import core.stdc.stdio;
string[] test;
void* test2;
void* test3 = cast(void*)1;
void* test4;
// This is here so that the next function
// becomes exported as "init" instead of "_init".
// The first exported symbol gets a preceeding underscore
// (Windows "system" convention) when using DMD/OPTLINK
// for some reason.
export extern(C) void _systemconvdummy() {}
export extern(C) void init()
{
printf("test = %p:%d\n", test.ptr, test.length);
printf("test2 = %p, test3 = %p, test4 = %p\n", test2, test3,
test4);
}
---
DllMain is as posted before. It can initialize the runtime or be
empty - the result is the same.
rundll.exe
---
#include
// Comment this out to use the WinAPI directly.
#define USE_GLIB
#ifdef USE_GLIB
#include
#else
#include
#endif
int main()
{
void (*init)();
#ifdef USE_GLIB
GModule* handle = g_module_open("bug.dll", 0);
#else
HMODULE handle = LoadLibrary(L"bug.dll");
#endif
printf("handle: %p\n", handle);
#ifdef USE_GLIB
g_module_symbol(handle, "init", &init);
#else
init = (void(*)())GetProcAddress(handle, "init");
#endif
printf("init: %p\n", init);
init();
return 0;
}
---
The glib headers and binaries all come from the GTK+ distribution
[1]. I'll try reducing it further by not using gmodule to see
exactly what the problem is, but it would be awesome if someone
could try to reproduce this on their machines.
[1] http://www.gtk.org/download/win32.php
Re: Windows DLLs and TLS
On Tuesday, 9 October 2012 at 14:09:52 UTC, Andrej Mitrovic wrote: On 10/9/12, Jakob Ovrum wrote: The problem has now been reduced to these two palatable programs. I get garbage values via LoadLibrary on both XP and Win7 (both x32). I haven't tried glib's version but I don't think it does anything differently. See _g_module_open and _g_module_symbol: http://www.koders.com/c/fidFBB7F65EF7D9F5843153A8CCFE31696E66DED44A.aspx Thanks a lot for testing. Does it make a difference with and without the canonical DllMain [1]? Yeah, the reason I didn't bother trying gmodule at first was because of the seemingly trivial implementations those two functions. However, what you are looking at is an outdated version. The GTK+ distribution uses a more recent version that looks like this [2]. The only notable difference as far as I can tell is that it has Unicode support for _g_module_open. [1] http://pastebin.com/rg9uUQMe [2] http://pastebin.com/BirJM1uz
Re: OutputRange should be infinite?
On Tuesday, 9 October 2012 at 14:03:36 UTC, monarch_dodra wrote: I tend to disagree with your examples, because, you are mixing the notion of run-time failure with logic error. For example: "new" New can fail. And you don't know unless you try. But new will throw an exception to tell you it failed.. An appender, as you say, is finite in memory, and will end up throwing an exception, yes. You also have a chance to try to catch it and react. Over-putting into a finite slice, on the other end, will *assert*. Game over. It is a catch 22: You can't know unless you try, you crash if you do. Actually, OutOfMemoryError and AssertError are the same class of Throwable - namely Error. They're both non-recoverable exceptions. I agree that AssertError is not an appropriate type to throw if an OutputRange is full, though.
Re: Windows DLLs and TLS
On Tuesday, 9 October 2012 at 17:45:07 UTC, Denis Shelomovskij
wrote:
In your `bugdist.rar` bug.dll is fully in this {c|t}rap:
http://d.puremagic.com/issues/show_bug.cgi?id=8130
And I have already mentioned it, but you answered "I am using a
.def file".
Sorry, I was under the impression that VisualD automatically
generated and included a .def file, but indeed it doesn't. Adding
the barebones .def file fixed the problem. Thanks!
Re: Windows DLLs and TLS
On Wednesday, 10 October 2012 at 01:31:35 UTC, dnewbie wrote: You can try compiling it with GDC! Please check this thread: http://forum.dlang.org/thread/nowjthaqnjfrcvqeu...@forum.dlang.org The latest version of TDM MinGW doesn't seem to include all the required utility binaries required by GDC. i.e. I copied the GDC distribution onto the latest TDM MinGW64 release (using the bundle installer), and it still complains about missing libgmp-3.dll and libppl_c-4.dll. The former DLL is quite easy to find in MinGW's download repository, but I can't find the latter DLL anywhere.
Re: dlang.org slow?
On Friday, 26 October 2012 at 04:59:07 UTC, H. S. Teoh wrote: Is it just me, or has dlang.org been really slow today? Is something wrong with the site that needs our attention? It takes almost 2 whole minutes to load a page -- at first I thought my office network screwed up again, but now I'm at home and it's still like that. T It's being very slow for me at times too. I think the NG server is suffering too, though I only use it through the forum.dlang.org front-end (getting a variety of HTTP error messages and timeouts).
Re: Can't use a C++ class from a DLL
On Monday, 29 October 2012 at 12:11:11 UTC, Denis Shelomovskij wrote: const char* getLastError(); const char* getDetail(char* detail); These return values should be const(char)* and the method shouldn't be const.
Re: Procedure for submitting a new Deimos project?
On Thursday, 1 November 2012 at 04:58:36 UTC, Nick Sabalausky wrote: What is the procedure for submitting a new Deimos project? A lot of repositories have been opened by Walter just by posting the project name and description on this forum, so I suggest posting that information in this thread.
Re: Slicing static arrays should be @system
On Sunday, 4 November 2012 at 05:31:41 UTC, Jonathan M Davis
wrote:
I just thought that I should bring greater attention to
http://d.puremagic.com/issues/show_bug.cgi?id=8838
As it stands, I think that the slicing static arrays being
considered @safe is
a major hole in SafeD's safety, and I think that it's one that
many of us
aren't aware of. But there seems to be some resistance to
outright making the
slicing of static arrays @system within that bug report, and I
recall similar
resistance in the thread that prompted that bug report
(unfortunately, I don't
remember what thread it was - somewhere in D.Learn I think).
So, I was wondering what the general consensus on this was.
Should slicing
static arrays be considered @system? I honestly don't see how
we could do
otherwise without the compiler being way, way smarter at
detecting escaping
references than is ever going to happen.
Also, I really think that if we're agreed that this change
needs to be made
that it should then be made sooner rather than later, because
it's going to
break code which actually tries to use @safe.
- Jonathan M Davis
Just as a note, if slicing static arrays cannot be @safe, then
type-safe variadic functions can't be @safe either, as it
essentially does the same thing, just implicitly:
void foo(int[] a...)
{
// 'a' is a slice of stack memory when foo *isn't* called
with an explicit array.
}
The compiler does perform its simple escape analysis on such
parameters, but as we know, it's not very smart.
I guess another solution to this particular case is to make it
generate a dynamic array when foo is @safe, but I don't think
anyone is excited about this option...
Then there's the scope parameter storage class. The compiler
isn't very smart about scope parameters either.
So what do we do about all these related issues?
Re: Slicing static arrays should be @system
On Sunday, 4 November 2012 at 05:58:20 UTC, Jonathan M Davis wrote: I think that anything that the compiler can't absolutely gurantee is @safe must be @system. If that's annoying in some places, then that's life, because we can't compromise on SafeD just because a few things that we use a lot can't be @safe. Now, if we can make further improvements that make it so that the compiler _can_ determine that something is actually @safe when before it couldn't, then that's great. So, in at least some cases, compiler improvements could be used to reduce the annoyance factor, but I don't think that we can compromise on this. - Jonathan M Davis I completely agree, but I don't think we should decide what should be guaranteed and what cannot by the current state of the compiler. We need a properly specified goal that programmers can rely on, and implementers work towards.
Re: version(deprecated)?
On Sunday, 4 November 2012 at 15:48:28 UTC, monarch_dodra wrote: We've currently implemented "version(assert)" and "version(debug)". Do you think we should request having a "version(deprecated)"? I think it would be very helpful. Thoughts? We also have version(unittest). version(deprecated) seems like a natural addition.
Re: Generic and fundamental language design issue
On Sunday, 4 November 2012 at 17:35:09 UTC, Tommi wrote: I wonder if it would be possible in D to let the compiler allocate dynamic arrays on stack when it can statically guarantee that it's safe to do so (no dangling references, never increasing the size of the array, etc). David Nadlinger was talking about how LDC does an optimization exactly like this, quite recently.
Re: How do you remove/insert elements in a dynamic array without allocating?
On Tuesday, 6 November 2012 at 01:11:08 UTC, Malte Skarupke wrote: I want something similar to the stl vector, which only re-allocates once your array grows past a certain size, not on every append. std.container.Array is similar to a shared_ptr>.
Re: [ ArgumentList ] vs. @( ArgumentList )
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote: No hitting below the belt! Let the games begin! I think that [] is sufficiently distinct from built-in attributes, unlike @(), but sadly, there's no nice way to parse it at statement scope. There are in fact a couple of ambiguous cases in the parser already; let's not introduce any more, lest we lose the ability to call D easy to parse. @(foo) looks too similar to built-in attributes. And let's face it; these annotations are actually quite different (I too prefer the more accurate name, 'annotations') from built-in attributes, the former cannot replace the latter any time soon. I want to hear what people think about [] at declaration scope and @[] at statement scope. Too complicated to remember?
Re: [ ArgumentList ] vs. @( ArgumentList )
On Wednesday, 7 November 2012 at 05:53:35 UTC, Jakob Ovrum wrote: I want to hear what people think about [] at declaration scope and @[] at statement scope. Too complicated to remember? This is quite bad for a variety of reasons, I'll change my vote for purely having @[] then.
Re: Getting rid of dynamic polymorphism and classes
On Thursday, 8 November 2012 at 17:27:42 UTC, Tommi wrote: ..and it got me thinking, couldn't we just get rid of dynamic polymorphism and classes altogether? Doesn't static polymorphism through the use of duck typing and member function delegates provide all that we need? For a lot of programs (or parts of programs) that currently use runtime polymorphism, the answer seems to be yes, and Phobos is very good at helping D programmers do their polymorphism at compile-time. But dynamic polymorphism is special in that it is just that - dynamic. You can decide which implementation to use at runtime rather than having to do it at compile-time. When this runtime component is necessary, there is no replacement for runtime polymorphism. As for function pointers and delegates, class-based polymorphism provides a couple of additional niceties: for one, vtables are created at compile-time. Secondly, it provides a lot of syntax and structure to the system that you don't have with arbitrary function pointers or delegates. Emulating OOP (no, not Object *Based* Programming) with function pointers is a real pain. Without classes, we'd only be marginally better off than C in this area, thanks to delegates.
Re: Pyd thread
On Saturday, 10 November 2012 at 06:22:57 UTC, Rob T wrote: I'm also gambling that the dll issue will be resolved in a reasonable amount of time, as the apps I'm building in D will require it. I'll need ddl's that are dynamically linked, and ddl's used as plugins that are dymaically loaded. I'm currently working on Linux almost exclusively, which also has the same problem. Unfortunately, I'm very new to D, so I doubt at this stage I can lend a hand to help solve problems like the dll issue. The best I can do for now is report on compiler bugs that I'm finding. Although I've only tested on Windows, I have a working DLL module example in LuaD [1][2]. The problems with DLLs are not as relevant for modules like these, and I don't imagine Python modules having too different needs. [1] https://github.com/JakobOvrum/LuaD/tree/master/example/dmodule [2] https://github.com/JakobOvrum/LuaD/blob/master/example/bin/module.lua
Re: WinAPI for druntime and OpenGL for deimos.
On Friday, 23 November 2012 at 21:15:00 UTC, Walter Bright wrote: On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote: I hope the deimos folks make a repo soon, so that people can use those modules as soon as possible, because I'll finish translating them today. https://github.com/D-Programming-Deimos/OpenGL This repo is a poor idea. Statically linking OpenGL is not the recommended way of linking OpenGL in a given application. Then again, Deimos is a poor idea to begin with, the only benefit is the unified source package name "deimos", which doesn't warrant the D-Programming-Deimos Github organization at all. A list of links to repositories following the Deimos guidelines would not only be sufficient, but much more efficient.
Re: WinAPI for druntime and OpenGL for deimos.
On Saturday, 24 November 2012 at 18:53:27 UTC, Manu wrote: There already exists a library to do what you're talking about, it's called glew. And if I were you I'd port that to D aswell, and leave it named as it is. People already know what glew does and have lots of existing code written to use it. It's perfectly good how it is. How about GLES? That's pretty important these days. I haven't seen a binding for that yet. DerelictGL does exactly what GLEW does, it's pretty much the whole point of Derelict. I think the other Derelict libraries were added later to take advantage of the runtime linking infrastructure put in place for OpenGL.
Re: Help!
On Monday, 26 November 2012 at 17:06:14 UTC, Manu wrote: When you say 'anything' though, does that include alias parameters? Will bar[0] be the equivalent of template foo(alias bar) if called with a symbol? Yes. D's inbuilt tuples can have both "expressions" and types. Tuples with only the former are called expression tuples. Tuples with only the latter are called type tuples (which is why people complain about the name of std.typecons.TypeTuple - it doesn't just take types).
A new web newsreader
Great work, been using it for the past few days, and I'm extremely happy with it - thanks again! :) Uses space very efficiently on my netbook - no need for a bulky mail client when on the move. For me, this was the biggest hurdle in the way of regularly reading the NG. I also happen to be one of the people who prefer reading threads linearly in typical web forum fashion, and this interface gets it just right. With a quality web bridge like this, there should be no need for a separate web forum community, which would be a disaster in terms of building a cohesive D community. I would definitely recommend promoting this interface on the official website.
Re: SDC & ddmd
On Saturday, �� December 2011 at 05:48:18 UTC, dolive wrote: Why do need to re-create a new compiler not participate in the maintenance ddmd ? What better features than ddmd ? I assume you are comparing SDC and DDMD on the basis that they're both written in D. While being written in D is a main point for SDC, it's not the only one. SDC is written from scratch with no other dependency than LLVM. Like LDC, it uses LLVM for the back-end, but unlike LDC, it doesn't use the DMD front-end. GDC and LDC inherit all the advantages and disadvantages of the DMD front-end. They get the whole language, or at least as far as the reference compiler implements it, up front. But they also get all the baggage of DMD: bugs, legacy code, etc. The SDC front-end is written with only D2 in mind and inherits no code from any C++ or D1 compiler, while DMD was built incrementally while D was a moving target. Due to all of this, the design of the codebase is fundamentally different from DMD. On the other hand, DDMD is a massive project in its own right. First you have to convert all of DMD's sources to D, then you can get onto the real task: turning the new code into idiomatic D instead of "C++ with a D compiler". And you have to keep it up to date with DMD development until DDMD is ready to take over. It's not yet clear which approach is "better", only time will tell. But the SDC project has already reaped benefits from its approach, and the design allows for many improvements as the project moves forward. Do note that as an SDC dev, I do have a bias in this comparison, but feel free to come up with some actual arguments for DDMD :)
Re: Why D const is annoying
On Saturday, 10 December 2011 at 12:15:14 UTC, David Nadlinger wrote: So, could you please at least elaborate why you think the current behavior is correct, and what advantages it has to outweigh the massive confusion it causes? This. I don't see how it makes any sense from a design perspective.
Re: If I had my way
On Sunday, 11 December 2011 at 22:01:06 UTC, Jonathan M Davis wrote: And if we're going to really try and get the const issues sorted out, Walter really should look at Michel Fortin's changes which replace Rebindable. And we definitely need to sort out what we want to be doing with const- correctness and object. Kenji did some pull requests related to that, but there were some issues, and I'm not quite sure where that all stands at the moment. It _is_ a major element in fixing const though. - Jonathan M Davis I concur, these two are major const issues. Fixing Rebindable seems instrumental in fixing Variant if I understand the situation correctly. Fixing Variant is instrumental to fixing std.concurrency. A lot of issues are solved by going down this path. As for Object - this week on IRC I had to explain to someone relatively new to D that the error he encountered was due to Object not being const-correct yet. Which surely sounds like a trivial problem to fix, but at least I could link to the discussion in the pull request to clarify that it isn't entirely straight-forward. This is definitely another source of frustration when working with const.
Re: Fixing const arrays
On Monday, 12 December 2011 at 12:24:53 UTC, torhu wrote: On 11.12.2011 22:24, Jonathan M Davis wrote: ... It was debated some time ago, and it ended up being a property. The fact that save is an action verb and not a noun automatically disqualifies it as a property IMHO, but it was made into a property, and we're pretty much stuck with it at some point. As far as what the function does, I don't think that it's a problem that it's a property, but it's not named like a property, so the situation with regards to save is not ideal, but it's too late now. I really don't get this. When D has 10,000 programmers using it professionally, it's too late. But now it's more like 5 or 10. And they are all presumably aware that D2 is still undergoing some polish. So are the maybe a few hundred people that are using D for hobby projects. They are early adopters, and they know what that entails. I call bogus on the backwards compatibility argument. There's not a lot to be compatible with at this stage. Not compared to what D2 wants to become. As for Andrei's book using save with the parentheses: If D2 gains traction, I'm sure there will be a second edition of that book. And you already want to have the errata handy when using the book. I don't see what the big deal is, at least not compared to letting this stay in the language forever. save being a property is a stupid inconsistency. It's easy to fix, the cost is relatively low. The people using D2 now are all part of a community that want D to succeed, as am I. It's a change for the better, which I'm sure most current D2 users would agree with. How hard can it be? Furthermore, there weren't even a way to enforce the property syntax until lately, and it's still not enabled by default. If we change it right now, people still have time to adapt before the backwards-compatibility argument even kicks in (no matter how weak it is).
Re: Second Round CURL Wrapper Review
On Monday, 12 December 2011 at 12:24:26 UTC, jdrewsen wrote: I think it should have curl in the name. I do not believe that a native D network library should have the same API as this module. It is limited by the design of libcurl and should be improved by a native D net library. I agree with this, it's pointless to limit ourselves to an interface that was designed with the limitations of curl in mind. Using a generic name for this module gains us absolutely nothing.
Re: Fixing const arrays
On Monday, 12 December 2011 at 14:46:17 UTC, Andrei Alexandrescu wrote: On 12/12/11 6:49 AM, Manu wrote: I think every opportunity should be taken to make important breaking changes while the community is as small as it is. Changing from r.save to r.save() is NOT an important change. It makes no semantic difference, marks no progress, and has no consequence. Insisting on the current property semantics was a sizeable mistake of this community, and I am sorry we gave into it. Andrei The whole point of a property to begin with is to make it look like a field, which has two important implications: improves interchangeability with function access vs a field, and exploits the user's intuition associated with accessing fields. It is in light of the second consequence that it makes a difference. This is nothing new; the style guides for properties in C# operate on the same basic principle: if it looks like field access, it should behave like field access. If the programmer sees just "r.save", he doesn't know whether it's a field or a property, and he shouldn't need to know, it should be fast and cheap, and return a consistent value. As far as I know, this isn't always true for save, which means it breaks with the user's intuition. I don't know whether or not this is an important change, but it *does* have consequence, and the current property semantics (as enforced with -property) are definitely meaningful. The old situation where you could write complete nonsense code like `std.file.read = "foo.txt";` is far worse.
Re: Fixing const arrays
On Monday, 12 December 2011 at 15:16:56 UTC, Adam D. Ruppe wrote: On Monday, 12 December 2011 at 15:07:16 UTC, Jakob Ovrum wrote: The old situation where you could write complete nonsense code like `std.file.read = "foo.txt";` is far worse. If we start removing features because someone can use them when deliberately obfuscating their code, we might as well just abandon the whole idea of programming languages. Firstly, no feature is removed, it is changed, unless you consider calling completely property-unrelated functions with this syntax a feature. Secondly, it is an extreme example, more commonly occurring examples would be conflating property access with calling a member function with non-trivial complexity. With enforced @property, the compiler helps the user write the most readable code for himself and more importantly, others.
Re: Fixing const arrays
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:07 AM, Jakob Ovrum wrote: If the programmer sees just "r.save", he doesn't know whether it's a field or a property, and he shouldn't need to know, it should be fast and cheap, and return a consistent value. As far as I know, this isn't always true for save Why? Save does behave like a field for the vast majority of structs. Andrei But save is an abstract interface function, its signature should reflect all possible implementations.
Re: Fixing const arrays
On Monday, 12 December 2011 at 15:21:31 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:07 AM, Jakob Ovrum wrote: The old situation where you could write complete nonsense code like `std.file.read = "foo.txt";` is far worse. We could have defined a system much better than both. Andrei I definitely agree. I think the current situation sucks. But I also think the previous situation sucks much, much more. (Unrelated side-note: I am using the web interface and I'm not well seasoned with using newsgroups, is there a better way to reply to multiple small posts than replying to each individually like I just did? I apologize if I'm being spammy.)
Re: Fixing const arrays
On Monday, 12 December 2011 at 15:29:26 UTC, Jakob Ovrum wrote: On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:07 AM, Jakob Ovrum wrote: If the programmer sees just "r.save", he doesn't know whether it's a field or a property, and he shouldn't need to know, it should be fast and cheap, and return a consistent value. As far as I know, this isn't always true for save Why? Save does behave like a field for the vast majority of structs. Andrei But save is an abstract interface function, its signature should reflect all possible implementations. Adding on this: I have no problem with save being a property if it's meant/designed to be cheap etc. like with most struct ranges and slices. I also don't think the name is a problem; if you want to be really pedantic, "save" is actually a noun as well :P
Re: A benchmark, mostly GC
On Monday, 12 December 2011 at 16:00:04 UTC, Manu wrote: Totally off topic... I have a question. If I pass a pointer to a C library... how does the GC know when it's safe to collect? It doesn't, you should add it to the GC with GC.addRoot or GC.addRange unless you're absolutely sure the pointer is never taken off the stack (the call stack is shared between the C and D code). Once you're sure the memory is no longer referenced on the C heap, you can remove the root or range with GC.removeRoot and GC.removeRange.
Re: Fixing const arrays
On Monday, 12 December 2011 at 16:09:03 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:29 AM, Jakob Ovrum wrote: On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote: On 12/12/11 9:07 AM, Jakob Ovrum wrote: If the programmer sees just "r.save", he doesn't know whether it's a field or a property, and he shouldn't need to know, it should be fast and cheap, and return a consistent value. As far as I know, this isn't always true for save Why? Save does behave like a field for the vast majority of structs. Andrei But save is an abstract interface function, its signature should reflect all possible implementations. Same goes for many properties. Andrei This is true, and many functions marked @property arguably shouldn't be. I think it's a little like the reason std.container.SList doesn't have a `length` property: the O(n) complexity doesn't match the interface `length` exposes (although formalised only in documentation/convention, not code). If the standard library is allowed to assume `r.save` is a cheap operation, in the same fashion it's allowed to assume this(this) is cheap, then by all means, it makes sense as a property. The only remaining arguments against it are purely about the name, and I actually don't think that's relevant. And just like you can still make a computationally expensive this(this) when absolutely necessary, you can do the same with save. If most reasonable uses of save have trivial performance, it might as well be a property. I'm still a beginner with ranges, but by my understanding and by what some people made it sound like, reasonable uses of save include some which are non-trivial. If this is true, then removing @property from save encourages people to think more about what using it might mean for the code they are writing, which is definitely important.
Re: Fedora 17 will include support for the D programming language
On Wednesday, 14 December 2011 at 11:11:20 UTC, Mattbeui wrote: On Wednesday, 14 December 2011 at 10:24:37 UTC, Andrei Alexandrescu wrote: On 12/13/11 5:47 PM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/ The news seems to have been accepted quite positively. Andrei D1 or D2? D1 won't will be discontinued on December 31, 2012? Why they don't move on directly to D2? D1 has been in Fedora for a while. This piece of news is about D2.
Re: dfeed
On Thursday, 15 December 2011 at 02:16:29 UTC, zhaopuming wrote: By no means Twitter fan here, but I disagree. For Walter and myself Twitter is an app - a convenient means to disseminate brief announcements to those interested. Something to note, twitter is blocked by the government in China , and dlang.org home page can not be fully loaded now due to this twitface app. So IMHO it's not necessarily convenient at least to Chinese D'evelopers (well, it's D Developers). It's the Chinese government to blame, but I surely hope this problem can be dealt with. After all, we were able to load dlang.org home page before twitter is integrated! Wouldn't the iframe solution fix this too? By the way, another problem with the twitter feed: it looks like utter crap on netbooks. http://filesmelt.com/dl/anotherproblem.png
Re: dfeed
On Thursday, 15 December 2011 at 06:39:31 UTC, Walter Bright wrote: On 12/14/2011 9:09 PM, Jakob Ovrum wrote: By the way, another problem with the twitter feed: it looks like utter crap on netbooks. http://filesmelt.com/dl/anotherproblem.png I tried it on my ipod, and it works fine. I also tried it on my kindle eink, and it works fine there, too! It does scale correctly, but the actual page content, the text in the center, is what gets compromised. I wish I could press a button to hide the feed to the right, leaving more space for the text, making it much more comfortable to read. It's not actually a problem for me as the main page is aimed at beginners to D, while I make use of the other pages on the site. But imagine someone on a netbook hearing about D and accessing the site to read about it - I would most certainly want to easily be able to hide the sidebar if that person was me.
Re: 64-bit DMD for windows?
On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors.
Re: 64-bit DMD for windows?
On Friday, 16 December 2011 at 12:14:50 UTC, a wrote: Jakob Ovrum Wrote: On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: > considering that there are no x86 chips sold these days > which aren't x86_64, I find it rather baffling that > Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors. New laptops and netbooks don't. Even recent (less than two years old) versions of intel atom are x86_64. The keyword here is "sold", and besides, IA32 is still extremely common on cheap netbooks and laptops, even some recent models. The Atom line having 64 bit models doesn't mean a whole lot for the present reality. 32-bit x86 is definitely disappearing, but there is a long road ahead and 32 bit x86 is still ubiquitous. And I bet if you counted all the offices using Windows around the world, you'd find the vast majority of them using 32-bit hardware. There's no reason Microsoft shouldn't offer upgrade opportunities for that userbase as long as their new OS' work fine on old hardware.
Re: Second Round CURL Wrapper Review
The docs for onReceiveHeader, http://freeze.steamwinter.com/D/web/phobos/etc_curl.html#onReceiveHeader explicitly says that the const string parameters are not valid after the function returns. This is all well and good; but a minor improvement would be to change the signature to: @property void onReceiveHeader(void delegate(in char[] key, in char[] value) callback); to add `scope` to the parameters. This documents the fact that the constant strings shouldn't be escaped as-is in both code and documentation. I suspect many other instances of `const(char)[]` could be changed to `in char[]` to better document how they use the parameters (I also personally think it looks better as it is more concise).
Re: Second Round CURL Wrapper Review
On Saturday, 17 December 2011 at 11:56:04 UTC, jdrewsen wrote: AutoConnect sounds like a command to connection automatically which might be confusing since that is not what it does. Therefore I went with AutoConnection which I still believe is better. How about something completely different then, like URLInfer? Also, some instances in the docs of "url" in lowercase should probably be changed to uppercase.
Re: Program size, linking matter, and static this()
On Saturday, 17 December 2011 at 21:02:58 UTC, so wrote:
On Sat, 17 Dec 2011 21:20:33 +0200, Andrei Alexandrescu
wrote:
On 12/17/11 6:34 AM, so wrote:
If you are using singleton in your C++/D (or any other M-P
language)
code, do yourself a favor and trash that book you learned it
from.
---
class A {
static A make();
}
class B;
B makeB();
---
What A.make can do makeB can not? (Other than creating
objects of two
different types :P )
Singleton has two benefits. One, you can't accidentally create
more than one instance. The second, which is often overlooked,
is that you still benefit of polymorphism (as opposed to
making its state global).
Andrei
Now i am puzzled,
"makeB" does both and does better. (better as it doesn't expose
any detail to user)
Both of your examples are the singleton pattern if `make` returns
the same instance every time, and arguably (optionally?) A or B
shouldn't be instantiable in any other way.
I suspect that the reason a static member function is prevalent
is because it's easy to just make the constructor private (and
not have to mess with things like C++'s `friend`). In D, there's
no real difference because you can still use private members as
long as you're in the same module.
The only difference between them I can see is that the
module-level function doesn't expose the class name directly when
using the function, which is but a minor improvement.
Re: Second Round CURL Wrapper Review
On Saturday, 17 December 2011 at 22:25:10 UTC, jdrewsen wrote: On Saturday, 17 December 2011 at 20:38:46 UTC, Jakob Ovrum wrote: On Saturday, 17 December 2011 at 11:56:04 UTC, jdrewsen wrote: AutoConnect sounds like a command to connection automatically which might be confusing since that is not what it does. Therefore I went with AutoConnection which I still believe is better. How about something completely different then, like URLInfer? Also, some instances in the docs of "url" in lowercase should probably be changed to uppercase. Will change case. Don't know if the URLInfer name is better though. /Jonas Andrei is right, a noun is better. I'm with InferredProtocol.
Re: Program size, linking matter, and static this()
On Sunday, 18 December 2011 at 08:56:56 UTC, so wrote: You have to expose either way no? "A.make" instead of "makeA" Yeah, in most sane code, I would imagine so. But still, the original example was just `make` version `A.make`. They could both obscure their return type through various means (like auto), but imo it makes less sense to do so for the static member function - I would be surprised to call `A.make` and not get a value of type `A`. But it would only be a tiny improvement and I don't think it's really relevant to the singleton pattern.
Re: Program size, linking matter, and static this()
On Sunday, 18 December 2011 at 09:26:58 UTC, Jakob Ovrum wrote: On Sunday, 18 December 2011 at 08:56:56 UTC, so wrote: You have to expose either way no? "A.make" instead of "makeA" Yeah, in most sane code, I would imagine so. But still, the original example was just `make` version `A.make`. They could both obscure their return type through various means (like auto), but imo it makes less sense to do so for the static member function - I would be surprised to call `A.make` and not get a value of type `A`. But it would only be a tiny improvement and I don't think it's really relevant to the singleton pattern. Sorry, I'm wrong, that wasn't the case at all. The original example was indeed `A.make` versus `makeB`.
Re: List of updated libraries
On Monday, 19 December 2011 at 06:03:08 UTC, Henrik Nordvik wrote: There's a page on the wiki: http://prowiki.org/wiki4d/wiki.cgi?AllLibraries That wasn't very updated. I checked a sample of the links, and a lot were dead, from 2003, 2004, 2006 etc. With so many dead project I get the feeling that D is dead. I fact, I have found almost no active projects. Most active projects are on Github, I think.
Re: DI Generation Needs your Help!
On Monday, 19 December 2011 at 08:11:26 UTC, Adam Wilson wrote: Let me know what you think! Nice work! I think this is going to be more and more relevant now that the situation with shared libraries is getting more interesting in D. I would argue that anything that can't be moved to a different library, like templates, manifest constants etc. must be kept in as-is. D interface generation isn't just useful for hiding source code; some people just want to put as much as possible in a shared library, speed up compilation or hide as much as possible with the restriction of keeping the code working as usual. If people want to hide their source code at all cost, they can make this do a pass to easily identify what needs to be moved to a different module, then do the rest manually (which of course, only needs to be done once).
Re: DI Generation Needs your Help!
On Monday, 19 December 2011 at 12:11:32 UTC, so wrote: On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson wrote: Everything else is left alone. Templates and mixins are not addressed with this code and *should* not be modified. That's where I need your help, the test cases I have written cover some basic scenarios but I don't have the capability to test these changes with the diverse code base that the community has created. I am not exactly sure about your problem with templates and mixins but i'll give it a try regardless :) Since with templates there is no distinction between definition and decleration, exposing them IMO should be solely based on thier module access signatures. private struct A() // hide public struct B() // expose Now if B or some another exposed structure in ".di" should call A, compiler will take care of it by outputting an error as usual. And if the public template tries to access the private one? Private module members must be treated like any other unless the compiler can prove it removed all references to the private member.
Re: DI Generation Needs your Help!
On Monday, 19 December 2011 at 21:04:28 UTC, so wrote:
On Mon, 19 Dec 2011 22:24:18 +0200, Adam Wilson
wrote:
So the consensus is to keep all private members/imports/etc?
Ideally to get most out of the auto generation of di files (by
definition of module system) we need to strip ALL private stuff.
Only this way we can say the automation is on par with
handcrafting.
But if it does not look doable somehow, we can always handcraft
them (which i'll generally prefer),
Private members can still be used from public templates and
whatnot. You can't take them out unless you can statically proved
all references within the same .di to that private member was
removed in the stripping process.
foo.d
--
private i = 42;
// Is a public template, has to be left in
void bar()()
{
/* Uses 'i' */
}
void baz()
{
/* Also uses 'i' */
}
--
foo.di
--
void bar()()
{
/* Still uses 'i', where did it go!? */
}
void baz(); // Fine, no longer need 'i'
--
Also, on a side note, function parameters can use types from
private imports too. Be it function, data or import, it has to be
left in even if private.
Re: Program size, linking matter, and static this()
On Wednesday, 21 December 2011 at 02:10:30 UTC, Jonathan M Davis wrote: On Tuesday, December 20, 2011 17:32:53 Andrei Alexandrescu wrote: On 12/20/11 2:58 PM, Marco Leise wrote: > Am 19.12.2011, 19:08 Uhr, schrieb Walter Bright > > : >> On 12/16/2011 2:55 PM, Walter Bright wrote: >>> For example, in std.datetime there's "final class Clock". >>> It >>> inherits >>> nothing, >>> and nothing can be derived from it. The comments for it >>> say it is >>> merely a >>> namespace. It should be a struct. >> >> Or perhaps it should be in its own module. > > When I first saw it I thought "That's how _Java_ goes about > free > functions: Make it a class." :) Same here. If I had my way I'd rethink the name of those functions. Having a cutesy prefix "Clock." is hardly justifiable. It's not the only place in Phobos which uses a class as a namespace. I believe that both std.process and std.windows.registry are doing the same thing. In this case, it nicely group all of the functions that are grabbing the time in one form or another. They're all effectively grabbing the time from the system clock, so they're grouped on Clock. - Jonathan M Davis Sounds like the perfect candidate for its own module.
Re: DI Generation Needs your Help!
On Wednesday, 21 December 2011 at 16:42:59 UTC, Adam Wilson wrote: Oops! I mean't a pull on dmd for the new DI code. Sorry for the confusion! Pull requests are always appreciated! :) Remember, it's more like "please-review-and-pull-if-of-acceptable-quality request" :P
Re: Carmack about static analysis
On Saturday, 24 December 2011 at 15:33:04 UTC, Andrei
Alexandrescu wrote:
Anyhow, is there anything you have in mind that we have the
chance of improving at this point?
Thanks,
Andrei
For one, we should follow up on:
foo!(a => a * 2)(bar);
vs.
foo!((a) { return a * 2; })(bar);
Re: Proposal for custom time string formatting in std.datetime
On Sunday, 25 December 2011 at 14:00:58 UTC, Jacob Carlborg wrote: On 2011-12-25 04:05, zhang wrote: On Fri, 23 Dec 2011 02:21:37 -, Walter Bright wrote: On 12/22/2011 11:25 AM, Piotr Szturmaj wrote: I wish D could support partial modules - partial as analogy to C#'s partial classes. module std.datetime-unit1; import std.datetime-unit2; // dash allowed only in submodules with the same module name ... module std.datetime-unit2; import std.datetime-unit1; ... // then module whatever; import std.datetime; // as usual I have no idea why anyone would want this. (Is it because the file is too big to fit on a floppy disk?) As for big module, my solutions are: 1) put related modules into a package (or directory) 2) add a module named all.d into the directory, and this module will import all the other modules publicly 3) now just import the *all* module when needed Here we have yet another example of some one who wants to use "import foo.*;". I agree it would be nice to have a proper way to do this. Providing .all modules feels hacky and they need to be manually maintained - it also doesn't look as good. The _really important thing_ to note here is, there are at least two kinds of D libraries when it comes to this issue. Some libraries, including Phobos, prefer putting a lot of stuff in one module rather than splitting it up into a package. But many other libraries prefer splitting a library over multiple modules and using the package system to tie them together. Arguing over which approach is better comes down to a wide range of arguments, many quite subjective. I do not believe either approach is always better than the other. But I do believe it's important not to disregard the package approach, because it has advantages and adherents as well. Right now, the language favours the single module approach. When packages are used instead, it's clunky to provide a convenient interface to the entire library, and it's not very intuitive to look for a ".all" module, which could be named anything. I really like the idea of simply adding "import myPackage;", behaving like your average ".all" module. Doing it this way solves at least three problems: No more clunky maintenance of convenience modules, big modules can later be split up into a package without breaking any client code, and we don't have to worry about a ".all" module for Phobos anymore (which is a suggestion that has been on the table several times).
Re: Ants AI, language matters
On Sunday, 25 December 2011 at 17:07:46 UTC, bearophile wrote: It's usually better to think of pre/post increments as returning void, and avoid code like this (but there is _far_ worse C/D code around): lokeLars = path[index--]; I agree that one should *generally* avoid this kind of code, but this example here is a very common C/C++ idiom, it should be fairly recognizable to anyone.
Re: A nice way to step into 2012
On Tuesday, 27 December 2011 at 10:57:35 UTC, Peter Alexander wrote: On 27/12/11 10:51 AM, deadalnix wrote: Le 27/12/2011 05:25, Andrei Alexandrescu a écrit : https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc Andrei Maybe I'll seem bitter, but I do not think this changement was really that important. This is nice, ok, but we have some other really serious flaw, like shared not doing what it is supposed to do. You seem bitter :-) Seriously though, it's a fair point, but the syntax of lambdas is fairly important and this appears to be a simple change so the cost/benefit ratio is particularly high in this case. This. You can let people play around with it, test it and provide feedback with just a small patch. And it is indeed very important. It's one of the few syntax woes we have to deal with in D, it would be a shame to let the benefits of std.algorithm and any other functional D code be overshadowed by the powerful but often excessive syntax of anonymous functions. It's important when presenting D to initiates that high-level code looks nice.
Re: A nice way to step into 2012
On Tuesday, 27 December 2011 at 04:25:00 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc Andrei Finally, it's here! I'll be able to use std.algorithm stuff without tons of named, nested functions now :)
Re: string is rarely useful as a function argument
On Wednesday, 28 December 2011 at 16:27:15 UTC, Andrei Alexandrescu wrote: So immutable(char)[] is the best choice for a correct string abstraction compared against both char[] and const(char)[]. In fact it's in a way good that const(char)[] takes longer to type, because it also carries larger liabilities. Also, 'in char[]', which is conceptually much safer, isn't that much longer to type. It would be cool if 'scope' was actually implemented apart from an optimization though.
Re: string is rarely useful as a function argument
On Wednesday, 28 December 2011 at 20:49:54 UTC, Jonathan M Davis wrote: On Wednesday, December 28, 2011 19:25:15 Jakob Ovrum wrote: Also, 'in char[]', which is conceptually much safer, isn't that much longer to type. It would be cool if 'scope' was actually implemented apart from an optimization though. in char[] is _not_ safer than immutable(char)[]. I didn't say it was. Please read more closely.
Re: string is rarely useful as a function argument
On Thursday, 29 December 2011 at 06:08:05 UTC, Andrei Alexandrescu wrote: On 12/28/11 11:36 PM, Walter Bright wrote: On 12/28/2011 8:32 PM, Adam D. Ruppe wrote: On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei Alexandrescu wrote: If we have two facilities (string and e.g. String) we've lost. We'd need to slowly change the built-in string type. Have you actually tried to do it? I've seen the damage done in C++ with multiple string types. Being able to convert from one to the other doesn't help much. This. The only solution is to explain Walter no other programmer in the world codes UTF like him. Really. I emulate that sometimes (learned from him) but I see code from hundreds of people day in and day out - it's never like his. Once we convince him, he'll be like "ah, I see what you mean. Requiring .rep is awesome. Let's do it." Andrei I don't think this is a problem you can solve without educating people. They will need to know a thing or two about how UTF works to know the performance implications of many of the "safe" ways to handle UTF strings. Further, for much use of Unicode strings in D you can't get away with not knowing anything anyway because D only abstracts up to code points, not graphemes. Imagine trying to explain to the unknowing programmer what is going on when an algorithm function broke his grapheme and he doesn't know the first thing about Unicode. I'm not claiming to be an expert myself, but I believe D offers Unicode the right way as it is.
Re: CURL Wrapper: Congratulations Next up: std.serialize
On Thursday, 29 December 2011 at 07:07:10 UTC, Brad Anderson wrote: Forgive me if this is a silly question but a conversation in IRC got me wondering if compiler could check for shared/__gshared use (and any other thread unsafe operation) in each unittest and run those that aren't using them concurrently? Obviously not all at once but at least more than one at a time (perhaps set through user configuration). Regards, Brad The unittest code can ultimately call into both C and D code which source is not known. Such code would need to cause the unittest to be excluded from concurrent execution, in light of this I think it's questionable if such an analysis would be worth implementing. Perhaps look at some example unittest suites that take a long time and look at whether these examples can be proven to be thread-safe.
Re: CURL Wrapper: Congratulations Next up: std.serialize
On Thursday, 29 December 2011 at 12:49:55 UTC, Jacob Carlborg
wrote:
For example:
import orange.test.UnitTester;
int sum (int x, int y)
{
return x * y;
}
unittest ()
{
describe("sum") in {
it("should return the sum of the two given arguments")
in {
assert(sum(1, 2) == 3);
}
}
}
void main ()
{
run;
}
If a test fails the framework will print out the context, the
stack trace and a snippet from the failing test, something like
this:
sum
- should return the sum of the given arguments
Failures:
1) sum should return the sum of the given arguments
# main.d:44
Stack trace:
tango.core.Exception.AssertException@main(44): Assertion
failure
describe("sum") in {
it("should return the sum of the given arguments") in {
assert(sum(1, 2) == 3);
};
};
1 test, 1 failure
Operator overloading abuse, ahoy!
Re: The problem with 'const'/'immutable' -- what is the _plan_ for fixing this (if we had infinite time to implement it)?
On Thursday, 29 December 2011 at 15:04:18 UTC, Mehrdad wrote: Given that D does *not* plan to support head-const or tail-const, and given that a detailed plan is the most important thing (otherwise there isn't a goal to look forward to), I guess the question is: _What is the current plan (in *detail*) for fixing these problems?_ Tail-const works for everything but classes, and for them, this proposal: https://github.com/D-Programming-Language/dmd/pull/3 Seems to have been settled on. Walter's reply at least hints at this being planned for inclusion. The proposed solution is better than Rebindable because std.concurrency can understand it correctly (Rebindable breaks the type system to do what it does), which seems to be important for Variant to be usable with std.concurrency.
Re: string is rarely useful as a function argument
On Friday, 30 December 2011 at 19:55:45 UTC, Timon Gehr wrote: I think the way we have it now is optimal. The only reason we are discussing this is because of fear that uneducated users will write code that does not take into account Unicode characters above code point 0x80. But what is the worst thing that can happen? 1. They don't notice. Then it is not a problem, because they are obviously only using ASCII characters and it is perfectly reasonable to assume that code units and characters are the same thing. 2. They get screwed up string output, look for the reason, patch up their code with some functions from std.utf and will never make the same mistakes again. I have *never* seen an user in D.learn complain about it. They might have been some I missed, but it is certainly not a prevalent problem. Also, just because an user can type .rep does not mean he understands Unicode: He is able to make just the same mistakes as before, even more so, as the array he is getting back has the _wrong element type_. I strongly agree with this. It would be nice to have everything be simple, work correctly *and* efficiently at the same time, but I don't believe the proposed changes make a definite improvement. In the end, if you don't want to use the standard library or other UTF-aware string libraries, you'll have to know the basics of UTF to write the correct code. I too wish it was harder to write it incorrectly, but the current solution is simply the best one to appear yet.
Re: The Right Approach to Exceptions
On Saturday, 18 February 2012 at 23:26:14 UTC, Andrei Alexandrescu wrote: (b) all real code does one thing. Andrei No. It's conceivable that *most* cases simply log the exception (e.g. by printing it) then either move back or move on (!). But it's most definitely not *all* and it's when you have a meaningful fall-back or recovery mechanism that exceptions shine and it's what they're designed for (because you are basically arguing against exceptions here, not their proper use, which should be obvious from how they function). The more complex your program becomes, the farther away from uncontrollable factors like user input and otherwise unexpected environments you get, and this is when interesting catch blocks are born. Even so, exceptions are still useful in shallow parts of your program too - you could catch a GetOptException (more specific exception types than this with attached data would be even better, as noted by everyone before me) and re-query the user for new input (not very Unix-y, but that's irrelevant). You can't do that with just an Exception - what if the exception came from one of the callbacks you passed to getopt, or from a bug in std.getopt? All that said, I don't think std.getopt is a good example because it's comparatively trivial code. std.file would be a much better area to examine for examples of interesting catch blocks.
Re: Type inference for delegates/lambdas as regular parameters?
On Wednesday, 29 February 2012 at 16:50:11 UTC, Alex Rønne
Petersen wrote:
(Didn't have much luck posting this on dmd-internals, so I'm
posting here.)
Hi,
Consider this code:
bool contains(T)(T[] arr, scope bool delegate(T) dg)
in
{
assert(dg);
}
body
{
foreach (i; arr)
if (dg(i))
return true;
return false;
}
import std.stdio;
void main()
{
writeln(contains([1, 2, 3], x => x == 2));
}
This doesn't compile with 2.058; the type of x in the lambda
expression cannot be deduced. Specifying the type explicitly
works
fine.
This works:
bool contains(alias dg, T)(T[] arr)
{
foreach (i; arr)
if (dg(i))
return true;
return false;
}
import std.stdio;
void main()
{
writeln(contains!(x => x == 2)([1, 2, 3]));
}
Wasn't there supposed to be type inference for delegates passed
as
regular parameters in 2.058?
Regards,
Alex
The type inference scenario that didn't work, was supposed to be
implemented, and was ultimately added for 2.058 is,
Given this function:
bool contains(int[] arr, scope bool delegate(int) dg);
You should be able to call it like this:
contains(arr, x => x == 2);
// Alternatively,
contains(arr, (x) { return x == 2; });
This was not previously possible, you had to make the parameter
types of those delegates explicit.
There is a bug that sometimes makes this inference crash even
with 2.058 though, but I think it might have been fixed for the
next release already (I got the same error message as one I saw
in a bug report for a recently fixed bug).
Now, it would be nice to have the inference you ask for as well,
but I don't believe it's what was talked about.
Of course, you might be referring to conversations I missed...
Where did the specification ebook go?
There is a link to a file `dlangspec.mobi` on this page: http://dlang.org/spec.html The ebook link is dead. I tried building an ebook myself using the makefile, but to no avail; kindlegen encountered dozens of problems with the generated dlangspec.html. Anyway, spec.html is not even reachable through any links on the site as far as I can tell. Shouldn't "Language Reference" in the sidebar link to that page? It currently sends you to lex.html. "Library Reference" links to an (incomplete!) overview of Phobos; it's probably a good idea to have the two links behave the same, even if that means "Library Reference" linking to, say, /phobos/object.html. I see that there is also an ebook sold on Amazon linked from that page; not sure what I think about monetizing an open source site like that, even if the copyrights of contributors are technically yielded to Walter. I'm thinking there might be some good reason here, though. By the way, why does the makefile look for \kindlegen\kindlegen by default? For one, those are Windows specific path separators, and shouldn't it look for just "kindlegen" in the PATH environment variable?
Re: Where did the specification ebook go?
On Sunday, 4 March 2012 at 06:29:06 UTC, Walter Bright wrote: On 3/3/2012 9:25 PM, Jakob Ovrum wrote: There is a link to a file `dlangspec.mobi` on this page: http://dlang.org/spec.html The ebook link is dead. I tried building an ebook myself using the makefile, but to no avail; kindlegen encountered dozens of problems with the generated dlangspec.html. Anyway, spec.html is not even reachable through any links on the site as far as I can tell. Shouldn't "Language Reference" in the sidebar link to that page? It currently sends you to lex.html. "Library Reference" links to an (incomplete!) overview of Phobos; it's probably a good idea to have the two links behave the same, even if that means "Library Reference" linking to, say, /phobos/object.html. I see that there is also an ebook sold on Amazon linked from that page; not sure what I think about monetizing an open source site like that, even if the copyrights of contributors are technically yielded to Walter. I'm thinking there might be some good reason here, though. Amazon's minimum price for an ebook is $.99 (after all, Amazon is entitled to make some money off of their system). The Digital Mars cut of this "monetization" works out to $.35 per copy. I can assure you that nobody is getting rich off of that. But if that still offends anyone, that's why it is linked to on the web site. It seems to have suffered bit rot in the transfer of the site to dlang.org, and simply having a number of people working on the text. It needs fixing. I have attempted to donate it to the local government library, but they ignore my repeated emails and phone messages (I suspect that nobody actually works there). I attempted to add it to Amazon's free lending library, but Amazon refused it because the book is not exclusive to Amazon. Ah, I suspected the reason was something like that, I think that's great :) Sorry if it sounded like an attack, and thank you for clearing that up for me. For these and other bit rot issues with the ebook, please add a pull request to github to fix them. Right, just making sure I wasn't doing something wrong. So, does anyone have any thoughts on whether "Language Reference" should link to spec.html or keep its current behaviour?
Re: Interesting Memory Optimization
On Friday, 16 March 2012 at 12:24:45 UTC, Kevin Cox wrote: On Mar 16, 2012 7:45 AM, "Alex Rønne Petersen" wrote I don't see any reason why c couldn't point to element number 3 of b, and have its length set to 3... -- - Alex And the previous examples were language agnostic. In D and other languages where the length of a string is stored we can nest strings anywhere inside other strings. const char[] a = "foofoo"; const char[] b = "oof"; Those can't be nested in null terminated strings, bit they can where strings have an explicit length. All compile-time generated strings (like literals) in D are (guaranteed to be?) null-terminated as well.
Re: Documentation Layout
On Wednesday, 28 March 2012 at 06:20:57 UTC, James Miller wrote: In another thread (http://forum.dlang.org/thread/CAMfGmZsNX3GsOFVyUaCX79E4H8eTBXqDmUJtm41JSzRNtME=r...@mail.gmail.com) I raged about std.container's documentation, then Teoh pointed out that a lot of Phobos documentation needs improving. While he was talking about content, it got me thinking about the actual presentation of Phobos's documentation. Now, I have an interest in UX and I am a web developer my trade, so here's what I think it wrong with general layout+design right now and what could be done to fix it. -snip- There is a simple project called cuteDoc (name comes from the old candyDoc theme) which has a demo using the Phobos documentation: http://robik.github.com/phobos/ Project home page: https://github.com/robik/cuteDoc It has some rudimentary JavaScript for a module list and a generated jump-to table. I would love to see the Phobos documentation on dlang.org do something similar; there's so much low-hanging fruit for D's documentation that I wish someone with some web savvy would pick up on. It's pretty baffling to think that some Phobos modules have *manually maintained* table headers, what the heck were people thinking? What happened to automation?
Re: Documentation Layout
On Thursday, 29 March 2012 at 05:41:30 UTC, James Miller wrote: On 29 March 2012 18:26, Jakob Ovrum wrote: There is a simple project called cuteDoc (name comes from the old candyDoc theme) which has a demo using the Phobos documentation: http://robik.github.com/phobos/ Project home page: https://github.com/robik/cuteDoc It looks ok, still a little too cluttered for my liking. Also, serif fonts on a web page... I think the theme has a long way to go. There are a lot of weird choices of colour and such, and I think it has too many boxes. I think it would look better if the style was toned down a little. It's merely an example of how little effort is required to make DDoc better. Issues with DDoc itself aside, the current state of dlang.org is hardly representative of DDoc's full potential, when it should be striving to be just that.
Re: Small Buffer Optimization for string and friends
On Monday, 9 April 2012 at 14:55:16 UTC, Andrei Alexandrescu wrote: 3. There are patterns that attempt to optimize by e.g. using .ptr, but end up pessimizing code because they trigger multiple memory allocations. Andrei It's important to note that this pattern is probably most common in glue code to C libraries, not bounds-checking related optimizations. There are countless of C library functions which receive the equivalent of an array by taking a pointer and a length, and implicit allocation on `foo.ptr` is completely unacceptable in these cases. It's also common to avoid the `toStringz` function for strings you know are zero-terminated, using `.ptr` directly instead, as the toStringz function unconditionally appends a zero these days (and for good reasons, its previous optimization was extremely optimistic about its input).
Re: Small Buffer Optimization for string and friends
On Monday, 9 April 2012 at 15:37:37 UTC, Andrej Mitrovic wrote: On 4/9/12, Jakob Ovrum wrote: The one taking (const(char)[] s) does this, but not the other overload taking (string s). Whether or not that's safe I don't really know. I've had an argument over this on github, but I don't know if it was about toStringz or maybe toUTF16z. I haven't got the link to the discussion. You're right, I just confirmed the optimization is still in place for the `string` version. The documentation is identical for both functions. I think this is a mistake. It assumes that the string is either a compiler-generated literal or a GC allocated string, while the documentation does not mention such assumptions. With all the focus on manual memory management and pluggable allocators going on, I think the optimization must be removed or the documentation for the `string` overload changed. This optimization can always be put back in without narrowing the scope of the `string` overload once the above conditions can be reliably checked. Another option is to add a known-bug section to the `string` overload informing users that the function may fail on custom-allocated strings.
Re: foreach and filter
On Wednesday, 11 April 2012 at 16:08:25 UTC, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable
here, why I
have to use const.
An array/slice has indirection, you can't implicitly convert it
to immutable.
(IIRC, there is actually an exception for the return type of
strongly pure functions, but your instantiation of 'array' is
evidently not pure enough)
Question 2 is why I can't do:
const a = filter! ... ;
foreach ( i ; a ) { ... }
if I try this I get messages along the lines of:
./signatures_sequential.d(33): Error: function
signatures_sequential.main.filter!(delegate @system bool(string
item)
{
return isDir(cast(const(char[]))item);
}
).filter!(const(immutable(char)[])[]).filter.Result.empty () is
not callable using argument types ()
./signatures_sequential.d(33): Error: function
signatures_sequential.main.filter!(delegate @system bool(string
item)
{
return isDir(cast(const(char[]))item);
}
).filter!(const(immutable(char)[])[]).filter.Result.popFront ()
is not callable using argument types ()
./signatures_sequential.d(33): Error: function
signatures_sequential.main.filter!(delegate @system bool(string
item)
{
return isDir(cast(const(char[]))item);
}
).filter!(const(immutable(char)[])[]).filter.Result.front () is
not callable using argument types ()
which, it has to be said, isn't exactly informative to the user.
Ranges are iterated in-place. You can't mutate a const range,
hence you cannot advance it by one (`popFront`), which is
required by the lowering of foreach using the range interface.
Thanks.
You should be using the D.learn group for these questions.
Re: foreach and filter
On Wednesday, 11 April 2012 at 16:33:42 UTC, Simen Kjaeraas wrote:
On Wed, 11 Apr 2012 18:08:14 +0200, Russel Winder
wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable
here, why I
have to use const. Question 2 is why I can't do:
const a = filter! ... ;
foreach ( i ; a ) { ... }
The answer to #1 is easy. Nothing is implicitly castable to
immutable.
Value types with no indirection are implicitly convertible to
immutable.
---
void main()
{
int a = 2;
immutable int b = a;
}
---
Re: foreach and filter
On Wednesday, 11 April 2012 at 17:00:43 UTC, bearophile wrote:
Jakob Ovrum:
Value types with no indirection are implicitly convertible to
immutable.
---
void main()
{
int a = 2;
immutable int b = a;
}
---
And far more, even with immutable reference types, in this
program 'a' has to be immutable, no just const:
-snip-
I mentioned this as a side-note in my other reply in the thread.
It's a truly neat feature which I feel has much potential, I hope
to see some compelling use-cases with standard library functions
in the future as Phobos becomes more pure-correct.
If the parameter to `array` in the original problem had presented
a pure interface, he should have been able to get an immutable
result like he tried initially thanks to this feature and pure
inference, which is exciting to think about.
Of course, it's useless in this particular case as his parameter
to `array` cannot have a pure interface (it's lazily evaluated,
right?), and secondly, an immutable range is not usable with
foreach.
Re: D Compiler as a Library
On Friday, 13 April 2012 at 13:08:51 UTC, deadalnix wrote: SDC have a lot of theses, and I proposed a similar stuff for its evolution. I think it is easier for SDC than it is for dmd considering the codebase of both. I think we've got the lexer and parser completely separate from most of the rest of the codebase (like the codegen), due to repeated requests from people who wanted to use these parts for IDEs and other tools. I've yet to see anyone actually go through with using it though, possibly because there is no documentation for a lot of it. Documenting these parts fully into something of a public API and then putting it online is definitely on the todo list. Perhaps there would be more motivation to do this rather than work on something else if someone actually tried using SDC in their project instead of just talking about it, so it's kind of a catch-22. That said, the parser is currently evolving alongside the codegen. When we want to start implementing new parts of the language, we iteratively add it to the parser, hence it's not complete. It's very easy to work with though and it's mostly a menial task (although it's kind of fun to produce beautiful parser errors :P). Anyway, for anyone interested, you can find us on Github and #d.sdc on FreeNode.
Re: Definitive list of storage classes
On Saturday, 14 April 2012 at 17:50:39 UTC, Jonathan M Davis wrote: That's clearly not the list, since it includes const, immutable, and shared, which are type qualifiers rather than storage classes. It also has stuff like init in it, which isn't even vaguely a storage class. All of the storage classes may be in that list, but I don't know how you'd figure out which ones they are from that list. Obviously D has inherited the term "storage class" from C and C++, but then expanded use of the term to a point where it's not always meaningful any more. I agree that the term needs some work. `const`, `immutable` and `shared` actually can affect the storage of variables in specific situations (e.g. an immutable module variable declaration), but we know they are also type qualifiers, beyond any doubt. I don't think it would be a stretch to say they are both storage classes and type qualifiers, and this is in fact how the specification presents it. I personally think that it's meaningless to classify them as both and would prefer their storage class classification be dropped from the specification text. If I had to guess I'd say 'storage class' meant something much more specific in C than it does in D, where it seems to mean properties of a declaration that do not affect the type. Except that both Walter and Andrei seem to talk about type qualifiers/constructors and storage classes as if they meant essentially the same thing as in C/C++. If Walter and/or Andrei have made an executive decision about what is and what isn't a storage class, I suggest they submit a pull request to dlang.org clarifying its new meaning. I have a feeling not a lot of thought has gone into this issue though, and Walter denying that immutable is a storage class (in his Lang.NEXT talk) probably means one of two things, 1) immutable is not a storage class in the context he presented, or 2) he was wrong and it is both a storage class and a type qualifier/constructor (per the specification). TDPL _does_ sort of try and define it, but not really. It pretty much just lists certain modifiers as being storage classes without giving a full list or explaining exactly what constitutes a storage class. The closest thing that it gives to a definition "Each function parameter (base and exponent in the example above) has, in addition to its type, an optional storage class that decides the way that arguments are passed to the function when invoked." would seem indicate that static (which it later says is a storage class) isn't a storage class at all, since storage classes would only apply to function parameters (which would also disqualify synchronized as a storage class, which would be at odds with the online docs). He is referring to the *parameter storage classes*, and he's actually wrong on one point: a parameter can have multiple parameter storage classes as long as they are compatible. List from the specification on functions: "Parameter storage classes are in, out, ref, lazy, const, immutable, shared, inout or scope." One point of interest is that you can define a function like: void foo(const scope int a); With the `const` before the `scope` like that. This has to be taken into consideration if the definition of a storage class is to be revisited. So, I'd like an official definition of storage class with a list of what qualifies as a one in D. But it wouldn't surprise me at all if Walter's the only one who can do that. Anyone making such a list would probably be making rather arbitrary on-the-spot decisions if we don't provide a solid definition of what a storage class is in D. As long as we have a good definition, anyone could fix the lists.
Re: D Compiler as a Library
On Monday, 16 April 2012 at 06:37:00 UTC, Jacob Carlborg wrote: On 2012-04-16 04:35, Ary Manzana wrote: On 4/13/12 9:10 PM, deadalnix wrote: SDC have a lot of theses, and I proposed a similar stuff for its evolution. I think it is easier for SDC than it is for dmd considering the codebase of both. Cool! SDC is the way to go. Let's focus our efforts on that project. :-) I noticed that SDC is licensed under the GPL license :( That is not compatible with, for example, EPL used by Eclipse. We are changing the license soon, with BSD/MIT in mind. I am really just waiting for Bernard to make the change, we've gotten permission from all contributors as far as I know.
Re: Docs: Section on local variables
On Friday, 20 April 2012 at 01:22:53 UTC, Andrej Mitrovic wrote:
Can we remove this section from the D docs, in the functions
section? :
"
Local Variables
It is an error to use a local variable without first assigning
it a
value. The implementation may not always be able to detect these
cases. Other language compilers sometimes issue a warning for
this,
but since it is always a bug, it should be an error.
It is an error to declare a local variable that is never
referred to.
Dead variables, like anachronistic dead code, are just a source
of
confusion for maintenance programmers.
"
I don't think this will ever be implemented, or that it should
be for
that matter. The first paragraph is quite extreme.
Many other languages have this restriction on local variables and
I would love to see DMD do the same kind of analysis. You can't
force programmers to write readable code, but you should at least
discourage it; the current way of default-initializing local
variables and using that as an excuse to not have flow analysis
is extremely weak and just reflects an unwillingness of the DMD
developers to take on this task, affecting the design of the
language.
I have seen this one in the wild before:
for(size_t i; i < arr.length; i++) {
...
}
This shouldn't be correct D code, and I think it's one of D's few
weaknesses that it is. Removing this paragraph from the
specification would be designing the language around DMD instead
of the other way around, and I really don't want to see that.
As for the second one, think about how often you use temporary
variables just to test
something out, you wouldn't want to have a compilation error
just
because you've temporarily left an unused variable inside a
function.
That's my experience anywho..
I think GDC has warnings for this, and I think that's the way to
go. Unused local variables is a plague on readability and we
should strive to eliminate them; but at the same time, a
compilation error for all circumstances may be a little tedious.
I think these features probably belong to some lint-type tool
and not
the compiler.
If I remember correctly, one of the goals of D according to
Walter is to reduce the need for such external tools.
Re: Docs: Section on local variables
On Friday, 20 April 2012 at 09:55:04 UTC, Nick Sabalausky wrote: It's funny, I once argued strongly in favor of this *against* Walter. I lost of course ;) IIRC, his argument was that it would require perfect flow analysis and that's too difficult and expensive. My argument was that it didn't need to be, and perhaps even *shouldn't* be, perfect. He felt that would end up being a PITA with false errors, and I felt that C# demonstrates it isn't a PITA. Meh, I don't want to re-debate it though. Yeah, I am aware of Walter's previous statements on this. I think it's ridiculous that he wants his language inferior to virtually every one of its modern contemporaries in this aspect based on implementation issues. I like D's well-defined default-initialization and I think it's great for global storage, TLS and class/struct fields, but I think local variables require a hybrid approach. It doesn't matter if the implementation isn't perfect; it's better than the alternative, which is our current abysmal situation.
Re: [off-topic] Sony releases PS Vita SDK
On Friday, 20 April 2012 at 06:43:51 UTC, Paulo Pinto wrote: D names itself a system programming language, but I am yet to see any OS coded on it. Without system programming examples, it becomes just another application level language. The XOmB project has been around since forever: https://github.com/xomboverlord/xomb
Re: Partial classes & forward declarations
On Friday, 20 April 2012 at 14:19:25 UTC, Jacob Carlborg wrote: Don't know if it helps but you can get the name of the arguments of a function: https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L29 I don't think that function handles delegate/function parameters. This function is too naive, it's incredibly easy to break. void foo(immutable(int) a);
