Re: Create Windows "shortcut" (.lnk) with D?
On Sunday, 6 March 2016 at 05:00:55 UTC, BBasile wrote: If you don't want to mess with the Windows API then you can dynamically create a script (I do this in CE installer): This might be an option but I'd prefer to use the Windows API directly. I don't know vb script and maintaining such a script inline would just add cognitive overhead I think. If I can't get it working with the Windows API; I'll probably have to do it this way though. Thanks for the suggestion!
Re: Create Windows "shortcut" (.lnk) with D?
On Sunday, 6 March 2016 at 03:13:23 UTC, 岩倉 澪 wrote:
I'm creating a small installation script in D, but I've been
having trouble getting shortcut creation to work! I'm a linux
guy, so I don't know much about Windows programming...
[...]
Any help would be highly appreciated as I'm new to Windows
programming in D and have no idea what I'm doing wrong!
If you don't want to mess with the Windows API then you can
dynamically create a script (I do this in CE installer):
void createLnk(string exeName, string displayName)
{
import std.process: environment, executeShell;
import std.file: remove, exists;
import std.random: uniform;
import std.conv: to;
string vbsName;
do vbsName = environment.get("TEMP") ~ r"\shcsh" ~
uniform(0,int.max).to!string ~ ".vbs";
while (vbsName.exists);
string vbsCode = "
set WshShell = CreateObject(\"WScript.shell\")
strDesktop = WshShell.SpecialFolders(\"Desktop\")
set lnk = WshShell.CreateShortcut(strDesktop +
\"\\%s.lnk\")
lnk.TargetPath = \"%s\"
lnk.Save
";
File vbs = File(vbsName, "w");
vbs.writefln(vbsCode, displayName, exeName);
vbs.close;
executeShell(vbsName);
vbsName.remove;
}
Re: Dub and unit-threaded import problem
On Saturday, 5 March 2016 at 18:01:48 UTC, Atila Neves wrote: On Saturday, 5 March 2016 at 15:05:50 UTC, Casey wrote: Hello, I'm just starting a small project with dub and unit-threaded, but I'm getting an issue where the file "unit_threaded.d" cannot be found. [...] You mispelled "dependencies". Atila Oh, and forgot to mention I like what you did with this new update of unit-threaded. Can't wait to get some code written.
Re: Dub and unit-threaded import problem
On Saturday, 5 March 2016 at 18:01:48 UTC, Atila Neves wrote: On Saturday, 5 March 2016 at 15:05:50 UTC, Casey wrote: Hello, I'm just starting a small project with dub and unit-threaded, but I'm getting an issue where the file "unit_threaded.d" cannot be found. [...] You mispelled "dependencies". Atila Thanks. I knew it had to be something dumb.
Create Windows "shortcut" (.lnk) with D?
I'm creating a small installation script in D, but I've been
having trouble getting shortcut creation to work! I'm a linux
guy, so I don't know much about Windows programming...
Here are the relevant bits of code I have:
import core.sys.windows.basetyps, core.sys.windows.com,
core.sys.windows.objbase, core.sys.windows.objidl,
core.sys.windows.shlobj, core.sys.windows.windef;
import std.conv, std.exception, std.file, std.format, std.path,
std.stdio, std.string, std.utf, std.zip;
//Couldn't find these in core.sys.windows
extern(C) const GUID CLSID_ShellLink = {0x00021401, 0x,
0x,
[0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46]};
extern(C) const IID IID_IShellLinkA = {0x000214EE, 0x,
0x,
[0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46]};
extern(C) const IID IID_IPersistFile = {0x010B, 0x,
0x,
[0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46]};
void main()
{
string programFolder, dataFolder, desktopFolder;
{
char[MAX_PATH] _programFolder, _dataFolder,
_desktopFolder;
SHGetFolderPathA(null, CSIDL_PROGRAM_FILESX86, null, 0,
_programFolder.ptr);
SHGetFolderPathA(null, CSIDL_LOCAL_APPDATA, null, 0,
_dataFolder.ptr);
SHGetFolderPathA(null, CSIDL_DESKTOPDIRECTORY, null, 0,
_desktopFolder.ptr);
programFolder =
_programFolder.assumeUnique().ptr.fromStringz();
dataFolder = _dataFolder.assumeUnique().ptr.fromStringz();
desktopFolder =
_desktopFolder.assumeUnique().ptr.fromStringz();
}
auto inputFolder = buildNormalizedPath(dataFolder,
"Aker/agtoolbox/input");
auto outputFolder = buildNormalizedPath(dataFolder,
"Aker/agtoolbox/output");
CoInitialize(null);
scope(exit)
CoUninitialize();
IShellLinkA* shellLink;
IPersistFile* linkFile;
CoCreateInstance(&CLSID_ShellLink, null,
CLSCTX_INPROC_SERVER, &IID_IShellLinkA, cast(void**)&shellLink);
auto exePath = buildNormalizedPath(programFolder,
"Aker/agtoolbox/agtoolbox.exe").toStringz();
shellLink.SetPath(exePath);
auto arguments = format("-i %s -o %s", inputFolder,
outputFolder).toStringz();
shellLink.SetArguments(arguments);
auto workingDirectory = programFolder.toStringz();
shellLink.SetWorkingDirectory(workingDirectory);
shellLink.QueryInterface(&IID_IPersistFile,
cast(void**)&linkFile);
auto linkPath = buildNormalizedPath(desktopFolder,
"agtoolbox.lnk").toUTF16z();
linkFile.Save(linkPath, TRUE);
}
I tried sprinkling it with print statements and it crashes on
shellLink.setPath(exePath);
This is the full script:
https://gist.github.com/miotatsu/1cc55fe29d8a8dcccab5
I found the values for the missing windows api bits from this:
http://www.dsource.org/projects/tutorials/wiki/CreateLinkUsingCom
I compile with: dmd agtoolbox-installer.d ole32.lib
I got the ole32.lib from the dmd install
Any help would be highly appreciated as I'm new to Windows
programming in D and have no idea what I'm doing wrong!
Re: If stdout is __gshared, why does this throw / crash?
Am Sun, 06 Mar 2016 01:10:58 + schrieb Anon : > I would avoid reassigning `stdout` and friends in favor of using > a logger or manually specifying the file to write to if I were > you. Meh. Too little drama. :p -- Marco
Re: If stdout is __gshared, why does this throw / crash?
Got it now: https://issues.dlang.org/show_bug.cgi?id=15768 writeln() creates a copy of the stdout struct in a non thread-safe way. If stdout has been assigned a File struct created from a file name this copy includes a "racy" increment/decrement of a reference count to the underlying C-library FILE*. In the case that the reference count is erroneously reaching 0, the file is closed prematurely and when Glibc tries to access internal data it results in the observable SIGSEGV. -- Marco
Re: If stdout is __gshared, why does this throw / crash?
On Saturday, 5 March 2016 at 14:18:31 UTC, Atila Neves wrote:
With a small number of threads, things work as intended in the
code below. But with 1000, on my machine it either crashes or
throws an exception:
import std.stdio;
import std.parallelism;
import std.range;
void main() {
stdout = File("/dev/null", "w");
foreach(t; 1000.iota.parallel) {
writeln("Oops");
}
}
Note that `1000.iota.parallel` does *not* run 1000 threads.
`parallel` just splits the work of the range up between the
worker threads (likely 2, 4, or 8, depending on your CPU). I see
the effect you describe with any parallel workload. Smaller
numbers in place of 1000 aren't necessarily splitting things off
to additional threads, which is why smaller numbers avoid the
multi-threaded problems you are encountering.
I get, depending on the run, "Bad file descriptor", "Attempting
to write to a closed file", or segfaults. What am I doing wrong?
Atila
`File` uses ref-counting internally to allow it to auto-close.
`stdout` and friends are initialized in a special way such that
they have a high initial ref-count. When you assign a new file to
stdout, the ref count becomes one. As soon as one of your threads
exits, this will cause stdout to close, producing the odd errors
you are encountering on all the other threads.
I would avoid reassigning `stdout` and friends in favor of using
a logger or manually specifying the file to write to if I were
you.
Re: In language tooling
On Friday, 4 March 2016 at 17:49:10 UTC, jmh530 wrote: I think I've heard him say that tools should be part of the language. However, I haven't watched that video and anyway am not sure how important CTFE would be to this effort. Anyway, D has things like dfix, dfmt, dscanner, dcd, dustmite, digger. I think there was some discussion about including these along with compilers. I recall some comparison to gofmt which will format go code. Maybe that was in Blow's talk... I think you should see the video before further commenting on it, the kind of tooling he is talking about is really quite peculiar. You don't have to watch the full video, I think from 5:00 to 8:00 is enough to get the main idea of what he does.
Re: If stdout is __gshared, why does this throw / crash?
Am Sat, 05 Mar 2016 14:18:31 +
schrieb Atila Neves :
> void main() {
> stdout = File("/dev/null", "w");
> foreach(t; 1000.iota.parallel) {
> writeln("Oops");
> }
> }
First thing I tried:
void main() {
stdout = File("/dev/null", "w");
foreach(t; 1000.iota.parallel) {
stdout.writeln("Oops");
}
}
That does NOT segfault ... hmm.
--
Marco
Re: If stdout is __gshared, why does this throw / crash?
On Saturday, 5 March 2016 at 14:18:31 UTC, Atila Neves wrote:
With a small number of threads, things work as intended in the
code below. But with 1000, on my machine it either crashes or
throws an exception:
import std.stdio;
import std.parallelism;
import std.range;
void main() {
stdout = File("/dev/null", "w");
foreach(t; 1000.iota.parallel) {
writeln("Oops");
}
}
I get, depending on the run, "Bad file descriptor", "Attempting
to write to a closed file", or segfaults. What am I doing wrong?
Atila
Could this be a bug in phobos/compiler?
Re: Backslash escaping weirdness
Am Tue, 01 Mar 2016 05:14:13 + schrieb Nicholas Wilson : > On Tuesday, 1 March 2016 at 04:48:01 UTC, Adam D. Ruppe wrote: > > On Tuesday, 1 March 2016 at 04:18:11 UTC, Nicholas Wilson wrote: > >> What is causing these errors? I'm using \t and \n in string > >> all over the place and they work. > > > > I don't think there's enough context to know for sure... but my > > guess is you forgot to close one of the quotes a couple lines > > above. > > > > So look up for an unpaired " > > It was. Thanks. And then God created syntax highlighting and He saw that it was good. ;) -- Marco
Re: Inline assembly and Profiling
Am Tue, 01 Mar 2016 02:30:04 +
schrieb Matthew Dudley :
> I'm working on a chess engine side-project, and I'm starting to
> get into profiling and optimization.
>
> One of the optimizations I've made involves some inline assembly,
> and I ran across some apparently bizarre behavior today, and I
> just wanted to double-check that I'm not doing something wrong.
>
> Here's the behavior boiled down:
>
> import std.stdio;
> ubyte LS1B(ulong board)
> {
>asm
>{
> bsf RAX, board;
>}
> }
>
> void main()
> {
>auto one = 0x939839FA;
>assert(one.LS1B == 1, "Wrong LS1B!");
> }
>
> If I run this through DMD without profiling on, it runs
> successfully, but with profiling on, the assertion fails. And in
> the actual code, it returns seeming random numbers.
>
> Is the profiling code stomping on my toes here? Am I not allowed
> to just single instruction into RAX like this with profiling on?
> Or is this just a compiler bug?
I didn't check the documentation, but I believe you have to
store RAX into some variable and return that when you use
inline assembly. In any case you should report a bug about
this. If this code is correct, then DMD assumes you implicitly
set the return value inside the asm-block and profiling should
save RAX. If this is not intended, then the function is
missing a return statement.
Alternatively you can turn this into a naked function by
starting your asm-block with "naked" and adding an explicit
"ret" at the end. Naked asm means that the functions only
contains the instructions you have explicitly written down,
circumventing the profiling instrumentation.
Either way functions with DMD-style inline assembly cannot be
inlined at all, which means you are better off looking into
the core.bitops compiler intrinsics.
Also code coverage or profiling (forgot which one) used
to not work in multi-threaded code!
What I typically do is compile on Linux with GDC or LDC and
use an external sampling profiler such as OProfile. You will
need change some optimizations in the compiler (no inlining,
debug information, keep frame pointers) so function call stack
can actually be reasoned about. After a profile run you can
then display the result in various ways. At first these are
confusing, but you'll get the hang of it after a while.
For example you could display sample counts per line of code,
or display a call graph which tells you the time spent in a
function separated by call site.
OProfile being a system profiler is not limited to your
program. It can include time spent in kernel functions or just
profile the whole system at once.
--
Marco
Re: Dub and unit-threaded import problem
On Saturday, 5 March 2016 at 15:05:50 UTC, Casey wrote:
{
"name": "unittest",
"preBuildCommands": [
"dub run unit-threaded -c gen_ut_main -- -f bin/ut.d"
],
"mainSourceFile": "bin/ut.d",
"excludedSourceFiles": ["source/app.d"],
"dependences": {
"unit-threaded": "~>0.6.3"
}
}
If dub is complaining about not finding bin/ut.d, You need a
"importPaths": ["bin"] in there. Dub by default only looks in the
source folder, and it cannot find `bin/ut.d` in `./source`. If
that is the case you also need to remove the `source` part from
the excludedSourceFiles.
Here is a config that works for me
{
"name": "unittest",
"preBuildCommands": ["dub run unit-threaded -c gen_ut_main --
-f bin/ut.d"],
"importPaths": ["bin"],
"mainSourceFile": "bin/ut.d",
"excludedSourceFiles": ["app.d"],
"dependencies": {
"unit-threaded": "~>0.6.3"
}
}
Re: Wrap array into a range.
On Saturday, 5 March 2016 at 16:35:55 UTC, Ilya Yaroshenko wrote: On Saturday, 5 March 2016 at 16:28:51 UTC, Alexandru Ermicioi wrote: I have to pass an array to a function that accepts an input range. Therefore I need to transform somehow array into an input range. Is there a range that wraps an array in standard library? You just need to import std.array. --Ilya I suggest that if the compile complains: T[] has no property front That one should import std.range since it will import std.array publicly. Anyway, std.array provides range free functions that work with the Array type making the compiler think arrays are ranges. Note that this import must be done for the code which checks/utilizes the array, not the code passing the array to a function.
Re: Dub and unit-threaded import problem
On Saturday, 5 March 2016 at 15:05:50 UTC, Casey wrote: Hello, I'm just starting a small project with dub and unit-threaded, but I'm getting an issue where the file "unit_threaded.d" cannot be found. [...] You mispelled "dependencies". Atila
Re: Application with WinMain does not start
On Saturday, 5 March 2016 at 14:08:28 UTC, Mike Parker wrote: On Saturday, 5 March 2016 at 14:01:11 UTC, Mike Parker wrote: If you use WinMain, you do not need that flag. Actually, I need to amend that. It isn't needed with WinMain when using the Microsoft linker, but it is when using OPTLINK. The MS linker recognizes WinMain and treats it as /SUBSYSTEM:WINDOWS by default. Thanks. I removed the WinMain and it worked.
Re: Wrap array into a range.
On Saturday, 5 March 2016 at 16:28:51 UTC, Alexandru Ermicioi wrote: I have to pass an array to a function that accepts an input range. Therefore I need to transform somehow array into an input range. Is there a range that wraps an array in standard library? You just need to import std.array. --Ilya
Wrap array into a range.
I have to pass an array to a function that accepts an input range. Therefore I need to transform somehow array into an input range. Is there a range that wraps an array in standard library?
Dub and unit-threaded import problem
Hello,
I'm just starting a small project with dub and unit-threaded, but
I'm getting an issue where the file "unit_threaded.d" cannot be
found.
Details:
DMD version: DMD64 2.070.0
Dub version: 0.9.24
Dub Config:
{
"name": "pst",
"targetType": "executable",
"targetPath": "bin",
"configurations": [
{
"name": "unittest",
"preBuildCommands": [
"dub run unit-threaded -c gen_ut_main -- -f
bin/ut.d"
],
"mainSourceFile": "bin/ut.d",
"excludedSourceFiles": ["source/app.d"],
"dependences": {
"unit-threaded": "~>0.6.3"
}
}
]
}
I haven't created any tests at this time. It's a bare project.
I just wanted to make sure the dub config worked before I started
coding. I feel I'm missing something very simple. I just don't
see it.
If stdout is __gshared, why does this throw / crash?
With a small number of threads, things work as intended in the
code below. But with 1000, on my machine it either crashes or
throws an exception:
import std.stdio;
import std.parallelism;
import std.range;
void main() {
stdout = File("/dev/null", "w");
foreach(t; 1000.iota.parallel) {
writeln("Oops");
}
}
I get, depending on the run, "Bad file descriptor", "Attempting
to write to a closed file", or segfaults. What am I doing wrong?
Atila
Re: Application with WinMain does not start
On Saturday, 5 March 2016 at 14:01:11 UTC, Mike Parker wrote: If you use WinMain, you do not need that flag. Actually, I need to amend that. It isn't needed with WinMain when using the Microsoft linker, but it is when using OPTLINK. The MS linker recognizes WinMain and treats it as /SUBSYSTEM:WINDOWS by default.
Re: Application with WinMain does not start
On Saturday, 5 March 2016 at 13:16:19 UTC, Minas Mina wrote:
I added a WinMain function to my application because I don't
want it to open a console when running on windows.
But now it doesn't even start...
extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
bool b = true;
while (b)
{
sync(Clock.currTime(utcTimeZone()));
Thread.sleep(getNextTimeToRun() -
Clock.currTime(utcTimeZone()));
}
return 0;
}
And this is my DUB configuration:
name "..."
description "..."
copyright "..."
authors "..."
targetType "executable"
lflags "/SUBSYSTEM:windows" "/EXETYPE:NT" platform="windows"
I got those flags from here: http://wiki.dlang.org/D_for_Win32
Any ideas:
When using WinMain, you are bypassing the DRuntime entry point,
meaning the runtime is never initialized. You need to do it
manually. However, since you're passing /SUBSYSTEM:windows on the
command line, you *don't need* WinMain. That flag is for when you
want to use main, but don't want the console to popup. If you use
WinMain, you do not need that flag. To keep things simple, I
recommend you use the /SUBSYSTEM:windows flag together with a
regular main and drop WinMain completely. You can drop the
/EXETYPE flag as well.
Application with WinMain does not start
I added a WinMain function to my application because I don't want
it to open a console when running on windows.
But now it doesn't even start...
extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
bool b = true;
while (b)
{
sync(Clock.currTime(utcTimeZone()));
Thread.sleep(getNextTimeToRun() -
Clock.currTime(utcTimeZone()));
}
return 0;
}
And this is my DUB configuration:
name "..."
description "..."
copyright "..."
authors "..."
targetType "executable"
lflags "/SUBSYSTEM:windows" "/EXETYPE:NT" platform="windows"
I got those flags from here: http://wiki.dlang.org/D_for_Win32
Any ideas:
Whether there is a same module likt C#'s "Windows.Storage" NameSpace?
Hi,everyone, Whether there is a module, like C#'s "Windows.Storage" NameSpace, you can operate the Android phone or ios phone, you can open the phone's folder on windows7? Thank you . Frank.
