Re: imports in functions
Aaaargh, I've used function imports, completely disregarding that they're not present in 2.053 and now I can't deploy code to github because people won't be able to compile it. Ahh the joys.. Well I'm glad I caught this now before embarrassing myself.
Re: imports in functions
On 6/21/11, Nick Sabalausky wrote: > UFCS barely works at all in D2. Another example: Couple that with the classically buggy 'with' statement and you've got yourself a party! \o/
Re: imports in functions
"Andrej Mitrovic" wrote in message
news:mailman.1030.1308543325.14074.digitalmar...@puremagic.com...
>I think I've just found the first bug:
>
> module test;
> void main()
> {
> }
>
> void foo()
> {
>import std.utf;
>"bla".toUTF16z;
> }
>
> Error: undefined identifier module test.toUTF16z
>
> UFCS doesn't work with function imports. This is a bug, right?
UFCS barely works at all in D2. Another example:
Regression(2.020) Array member call syntax can't find matches in current
class
http://d.puremagic.com/issues/show_bug.cgi?id=4525
Re: imports in functions
On 6/20/11 3:04 PM, Jacob Carlborg wrote: On 2011-06-20 05:18, Ary Manzana wrote: On 6/19/11 5:20 AM, Andrej Mitrovic wrote: This is such a great debugging tool. I mean ddbg is great on its own. But being able to quickly import std.stdio and do a few debug writes in some library function is fantastic. print-debugging is so common... in Ruby you always have "puts" available, no need to require anything. Why not do the same for D? "puts", don't you use "p"? Shorter and prints better information. Ah, yes, you are right. I use it. p "!" is my battle horse.
Re: imports in functions
On 2011-06-20 05:18, Ary Manzana wrote: On 6/19/11 5:20 AM, Andrej Mitrovic wrote: This is such a great debugging tool. I mean ddbg is great on its own. But being able to quickly import std.stdio and do a few debug writes in some library function is fantastic. print-debugging is so common... in Ruby you always have "puts" available, no need to require anything. Why not do the same for D? "puts", don't you use "p"? Shorter and prints better information. -- /Jacob Carlborg
Re: imports in functions
I think I've just found the first bug:
module test;
void main()
{
}
void foo()
{
import std.utf;
"bla".toUTF16z;
}
Error: undefined identifier module test.toUTF16z
UFCS doesn't work with function imports. This is a bug, right?
Re: imports in functions
On 6/19/11 5:20 AM, Andrej Mitrovic wrote: This is such a great debugging tool. I mean ddbg is great on its own. But being able to quickly import std.stdio and do a few debug writes in some library function is fantastic. print-debugging is so common... in Ruby you always have "puts" available, no need to require anything. Why not do the same for D?
Re: imports in functions
This is such a great debugging tool. I mean ddbg is great on its own. But being able to quickly import std.stdio and do a few debug writes in some library function is fantastic.
Re: imports in functions
On 2011-06-12 23:15, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.
This is awesome.
--
/Jacob Carlborg
Re: imports in functions
Well it seems to work fine. :)
Re: imports in functions
On 6/13/2011 8:48 PM, Andrej Mitrovic wrote:
> I'm guessing this is what you're after:
>
> http://codepad.org/TCtG68Fw
> http://codepad.org/65GBDjPS
>
> rdmd main.d
> shared ctor!
> ctor!
> foo.test
> dtor!
> shared dtor!
Actually, not what I was thinking. I was thinking something like this:
file 1:
import std.stdio; // or inside this, not what I'm testing.
static this()
{
writeln("foo");
}
file 2:
void main()
{
import file1;
}
Re: imports in functions
Should DLLs even have module ctors/dtors? I think this is what DLLMain's DLL_PROCESS_ATTACH, DLL_THREAD_ATTACH and their detach counterparts are for.
Re: imports in functions
I'm guessing this is what you're after: http://codepad.org/TCtG68Fw http://codepad.org/65GBDjPS rdmd main.d shared ctor! ctor! foo.test dtor! shared dtor!
Re: imports in functions
And they do run, I've tested it in a non-DLL example.
Re: imports in functions
When I add module ctors/dtors, I get the ModuleInfoZ shenanigans again.
Re: imports in functions
On 6/13/2011 8:28 PM, Andrej Mitrovic wrote:
> Walter, it looks like this addition inadvertently fixes the issue of
> DLLs not linkable due to Phobos imports.
>
> I've had this DLL (alongside with dllmodule.d which had initialization
> calls inside DLLMain):
> module EdrLib;
>
> import std.utf;
>
> pragma(lib, "gdi32.lib");
> pragma(lib, "comdlg32.lib");
> import win32.windef;
> import win32.wingdi;
>
> export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
> {
> SIZE size ;
> GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
> return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
> (prc.bottom - prc.top - size.cy) / 2,
> pString.toUTF16z, pString.length);
> }
>
> The header file produced from this would cause any client code which
> imports the header to look for ModuleInitZ, which wouldn't exist in
> the generated import library since it's an import library and not a
> static library.
>
> But, if I move the phobos import inside the EdrCenterText function:
>
> export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
> {
> import std.utf;
>
> SIZE size ;
> GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
> return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
> (prc.bottom - prc.top - size.cy) / 2,
> pString.toUTF16z, pString.length);
> }
>
> Then it works. My related bug report about this (and its complicated
> to read due to various misunderstanding on my part) is
> http://d.puremagic.com/issues/show_bug.cgi?id=6019.
>
> But it's great that there's an actual workaround now!
This makes me think that there's actually a bug in the function-local imports.
I'm guessing they don't run module-level
ctors and dtors for the imported modules. Would you mind putting together a
test case to check?
Thanks,
Brad
Re: imports in functions
Walter, it looks like this addition inadvertently fixes the issue of
DLLs not linkable due to Phobos imports.
I've had this DLL (alongside with dllmodule.d which had initialization
calls inside DLLMain):
module EdrLib;
import std.utf;
pragma(lib, "gdi32.lib");
pragma(lib, "comdlg32.lib");
import win32.windef;
import win32.wingdi;
export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
SIZE size ;
GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
(prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}
The header file produced from this would cause any client code which
imports the header to look for ModuleInitZ, which wouldn't exist in
the generated import library since it's an import library and not a
static library.
But, if I move the phobos import inside the EdrCenterText function:
export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
import std.utf;
SIZE size ;
GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, &size) ;
return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
(prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}
Then it works. My related bug report about this (and its complicated
to read due to various misunderstanding on my part) is
http://d.puremagic.com/issues/show_bug.cgi?id=6019.
But it's great that there's an actual workaround now!
Re: imports in functions
On Jun 14, 11 03:55, Andrej Mitrovic wrote:
Btw, it's disappointing that I can't call split with a separator at
compile-time:
enum result = split("bla, bla"); // ok
enum result = split("bla, bla", ","); // nope
That's due to (at least) http://d.puremagic.com/issues/show_bug.cgi?id=4047.
Re: imports in functions
Btw, it's disappointing that I can't call split with a separator at
compile-time:
enum result = split("bla, bla"); // ok
enum result = split("bla, bla", ","); // nope
Re: imports in functions
I'm having some fun with this.
import std.array;
void main()
{
with (namespace!("std.stdio std.algorithm std.range"))
{
auto squares = map!("a * a")([2, 4, 6]);
writeln(squares);
}
}
template namespace(string x)
{
mixin(namespaceImpl(x));
}
string namespaceImpl(string x)
{
string result;
auto mods = split(x);
foreach (val; mods)
{
result ~= "import " ~ val ~ ";";
}
return result;
}
Re: imports in functions
On 12/06/2011 22:15, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.
I did notice this - I think it's awesome. So many times when debugging
code I've attempted to write import std.stdio; in the function, then had
to move it away from the code I was debugging - of course this left a
stray import because I forgot about it :3
--
Robert
http://octarineparrot.com/
Re: imports in functions
On 6/12/11 5:08 PM, Andrej Mitrovic wrote: This seems like a way to simulate namespaces in C++, right? I wouldn't know, but it looks similar to that 'using foo' trick. I hope not :o). C++ namespaces are quite lacking. Andrei
Re: imports in functions
On 6/13/11, Jonathan M Davis wrote: < snip> So much for my blurry recollection of C++ features. :-)
Re: imports in functions
On 2011-06-12 15:08, Andrej Mitrovic wrote: > This seems like a way to simulate namespaces in C++, right? I wouldn't > know, but it looks similar to that 'using foo' trick. C++ namespaces are completely different. Everything in a namespace has to be referenced by its namespace explicitly unless you use using. So, without using, you need to do stuff like std::vector v; whereas with using namespace std; vector v; you don't need the std:: tag anymore. Using namespace affects _everything_ after it, which is why it's pretty much verboten in header files (otherwise it would pollute the global namespace). And whether you have a using statement or not, as soon as you #include a file, everything in it is visible in the current file. Namespaces just segregate the names so that they don't clash. D modules are very different. As soon as you import a module, everything in that module is visible (though you can't use anything in it unless it's public or the current module is in the same package and it's package or if you're deriving from class in that module and the symbol in question is protected). You don't have to use the module name when using _any_ of its symbols unless names clash or you imported the module statically. It's kind of like you automatically have a using statement all of the time, except that it's much more sophisticated and handles name clashes much better. By importing within a function, you're saying that only that function has access to the symbols within the module being imported. As for as the rest of the module is concerned, the imported module does not actually exist. You're restricting what can see it. So, I'm not quite sure what you mean by this simulating C++ namespaces. They both deal with how symbols are brought into and viewable in the current file, but they're very different. - Jonathan M Davis
Re: imports in functions
On 13.06.2011 1:15, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in
functions. These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially
when using mixins, versioning and other conditional compilation
constructs.
Also very helpful for unittests, thanks.
--
Dmitry Olshansky
Re: imports in functions
On Sun, 12 Jun 2011 14:15:27 -0700, Walter Bright wrote:
> Nobody seems to have noticed yet, but yesterday I removed the
> restriction preventing import declarations from being used in functions.
> These now work:
>
> void test1()
> {
> import std.c.stdio;
> printf("hello world\n");
> }
>
> void test2()
> {
> static import std.c.stdio;
> std.c.stdio.printf("hello world\n");
> }
>
> https://github.com/D-Programming-Language/dmd/commit/
d5fbd53aa8d8452dce2514944575e654d387477a
>
> I believe this can lead to better encapsulation of code, especially when
> using mixins, versioning and other conditional compilation constructs.
Cool! This is a definite improvement. :)
-Lars
Re: imports in functions
This seems like a way to simulate namespaces in C++, right? I wouldn't know, but it looks similar to that 'using foo' trick.
Re: imports in functions
On 06/12/2011 04:33 PM, Adam D. Ruppe wrote: This is awesome! Another benefit here is code running programs are simplified. For "D script" kind of things, a technique I use is to simply wrap some code inside a main function. Almost every feature worked there - nested functions, structs, classes, etc. Now imports do too! Yay! This bodes well for your "run this online" thing, too. All we need to do is wrap a main() around the example code and it should work. Andrei
Re: imports in functions
This is awesome! Another benefit here is code running programs are simplified. For "D script" kind of things, a technique I use is to simply wrap some code inside a main function. Almost every feature worked there - nested functions, structs, classes, etc. Now imports do too! Yay!
Re: imports in functions
On 06/12/2011 04:15 PM, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.
Fabulous. std.benchmark already uses the feature, and from a mixin no less:
https://github.com/andralex/phobos/commit/c5f2778a0fc393d6bd17ebec4765b28937575c31
One interesting aspect of the feature is that if import is used from
within a template, it's not actually imported unless the template is
instantiated.
Andrei
imports in functions
Nobody seems to have noticed yet, but yesterday I removed the restriction
preventing import declarations from being used in functions. These now work:
void test1()
{
import std.c.stdio;
printf("hello world\n");
}
void test2()
{
static import std.c.stdio;
std.c.stdio.printf("hello world\n");
}
https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a
I believe this can lead to better encapsulation of code, especially when using
mixins, versioning and other conditional compilation constructs.
